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 _______________________________________________ devicetree-discuss mailing list devicetree-discuss@lists.ozlabs.org https://lists.ozlabs.org/listinfo/devicetree-discuss