[RFC V1 0/8] CPUFreq: create platform-dev for DT based cpufreq drivers
arnd at arndb.de
Mon Dec 1 06:59:14 PST 2014
On Monday 01 December 2014 20:18:10 Viresh Kumar wrote:
> On 1 December 2014 at 19:35, Arnd Bergmann <arnd at arndb.de> wrote:
> > I guess a string would be better here, the idea here was to
> > have a different bool property per driver, which would also
> > work.
> Hmm, I will prefer string as we don't need to define any more bindings then
> for new drivers.
Right. You'd still need to define the known values though, so in
effect it's not much of a difference. I have no problem with
a string property though.
> >> > @@ -367,29 +404,19 @@ static int dt_cpufreq_probe(struct platform_device *pdev)
> >> > if (!IS_ERR(cpu_reg))
> >> > regulator_put(cpu_reg);
> >> >
> >> > - dt_cpufreq_driver.driver_data = dev_get_platdata(&pdev->dev);
> >> > -
> >> We still need this, and its about how clocks are shared between CPUs.
> > I didn't see where this comes from. Who is setting up this platform
> > data?
> Mvebu is using it to communicate that all CPUs have separate
> clock lines.
I still don't see where it does that. All I see for mvebu is
platform_device_register_simple("cpufreq-dt", -1, NULL, 0);
without any platform data. I see this patch
on the mailing list, but it's not in linux-next, and it obviously
would not work any more with the patch I proposed. Instead I suppose
you would use a different string to match against for the case of
More information about the linux-arm-kernel