Messages in this thread | | | Date | Mon, 17 Jun 2013 10:20:45 +0530 | From | Tushar Behera <> | Subject | Re: [PATCH 2/2] clk: exynos4: Add alias for cpufreq related clocks |
| |
On 06/11/2013 12:23 AM, Tomasz Figa wrote: > On Monday 10 of June 2013 09:13:11 Tushar Behera wrote: >> On 06/08/2013 05:20 PM, Tomasz Figa wrote: >>> On Thursday 06 of June 2013 16:52:28 Tushar Behera wrote:
[ ... ]
>>>> MUX_A(mout_core, "mout_core", mout_core_p4210, >>>> >>>> - SRC_CPU, 16, 1, "mout_core"), >>>> + SRC_CPU, 16, 1, "moutcore"), >>> >>> IMHO those typo corrections are not part of this patch. >> >> But the older drivers (before migration to CCF) were using the clock >> "moutcore" (not "mout_core"). > > I mean, this should be placed in a separate patch, as this change is not > "adding alias for cpufreq related clocks", but rather fixing a typo. >
Is it ok if I split this patch into 2, one adding clock alias 'mout_apll' and another one fixing the alias names 'mout_mpll', 'moutcore' and 'armclk'?
[ ... ]
>>> Basically I don't like the idea of those global aliases, which IMHO >>> should be completely dropped. Someone might not like it, but I'd go >>> with the conversion of our cpufreq drivers to platform drivers >>> instead, which could receive things like clocks and regulators using >>> DT-based lookups. >> I agree. Migration of exynos-cpufreq driver as a platform driver is the >> best solution. But unless someone picks up that work, cpufreq support >> for EXYNOS4 based systems is broken because of the incorrect clock >> aliases. > > We have patches for this in our internal tree. I will clean them up a bit > and submit soon. >
If you are going to submit the cpufreq driver patches for v3.11, then we can ignore this patchset. Otherwise, I would prefer to get these patches merged for v3.11 to get cpufreq working. Once the driver changes are incorporated, we can very well modify these later.
Thanks. -- Tushar Behera
| |