On Thu, Nov 20, 2014 at 2:12 PM, Ulf Hansson <ulf.hansson@xxxxxxxxxx> wrote: >>> According to earlier comments in this thread, device's clocks are >>> split into "functional" and "PM" clocks. >>> >>> If I understand correctly, a typical platform driver will enable it's >>> "functional" clocks during ->probe() and you want the PM domain to >>> take care of the "PM" clocks, when the device changes runtime PM >>> status. >>> >>> How will you describe these different set of device clocks in DT? >> >> True :( You can dig deeper in the history of this series if you wish. >> - first Geert Uytterhoeven proposed to use CLK_RUNTIME_PM there >> https://lkml.org/lkml/2014/11/6/319 >> - second I proposed to introduce smth. like "clkops-clocks", "pm-clocks" there >> https://lkml.org/lkml/2014/6/12/436 >> or "fck-clocks"/"opt-clocks" later. >> >> ^failed. >> >> So, this implementation picks up all clocks for each device, which is ok for >> Keystone 2 and, because it's platform specific. >> >>>> >>>> Yes, it would definitely solve the problem that I see with the infrastructure >>>> code that the current version adds into the platform directory. >>>> >>>> The exact binding of course should be reviewed by the pmdomain and >>>> DT maintainers, to ensure that it is done the best possible way, because >>>> I assume we will end up using it a lot, and it would be a shame to get >>>> it slightly wrong. >>>> >>>> One possible variation I can think of would be to just use "simple-pmdomain" >>>> as the compatible string, and use properties in the node itself to decide >>>> what the domain should control, e.g. >>>> >>>> clk_pmdomain: pmdomain { >>>> compatible = "simple-pmdomain"; >>>> pmdomain-enable-clocks; >>>> #power-domain-cells = <0>; >>>> }; >>>> clk_regulator_pmdomain: pmdomain { >>>> compatible = "simple-pmdomain"; >>>> pmdomain-enable-clocks; >>>> pmdomain-enable-regulators; >>>> #power-domain-cells = <0>; >>>> }; >>>> >>>> and then have each device link to one of the nodes as the pmdomain. >>>> >>> >>> That's seems like a good approach to me. >> >> Yes, but your previous comment is still actual :( > > Agree! > > So I really think we need to decide on how to address the split of the > device clocks. Before that's done, I don't think it make sense to add > a "simple-pmdomain" compatible, since it will likely not be that many > SoC that can use it. > > So, does anyone have a suggestion on how to deal with the split of the > device clocks into "functional" clocks and into "PM" clocks? That's indeed the tricky part. On shmobile, we just use the "NULL" clock, i.e. the first clock, for historical reasons. Using clock-names (e.g. "fck" and "pm") will conflict with existing bindings for devices that already mandate specific clock names. As the clock being a "PM" clock is a property of the clock provider (at last on shmobile), I originally came up with not handling it in DT, but advertising it in the clock provider driver: > > - first Geert Uytterhoeven proposed to use CLK_RUNTIME_PM there > > https://lkml.org/lkml/2014/11/6/319 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@xxxxxxxxxxxxxx In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
