[PATCHv4 05/33] CLK: omap: add DT duplicate clock registration mechanism
Tony Lindgren
tony at atomide.com
Fri Aug 2 03:22:21 EDT 2013
* Tero Kristo <t-kristo at ti.com> [130801 08:37]:
> On 08/01/2013 06:24 PM, Nishanth Menon wrote:
> >On 08/01/2013 10:18 AM, Tero Kristo wrote:
> >>On 08/01/2013 05:25 PM, Nishanth Menon wrote:
> >>>On 07/31/2013 05:07 AM, Tero Kristo wrote:
> >>>>On 07/30/2013 09:40 PM, Nishanth Menon wrote:
> >>>>>On 07/23/2013 02:20 AM, Tero Kristo wrote:
> >[..]
> >>>if we can get rid of usage of omap_hwmod_get_main_clk by catching them
> >>>with [1], then we can force the drivers to pick up based on device node
> >>>clocks= property.
> >>>
> >>>It might be easier to fix 1 driver - timer, rather than introduce am33x,
> >>>omap4, omap5 dra7 specific "SoC clk driver".
> >>>
> >>>with that this entire patch becomes redundant.
> >>
> >>It is not that simple. Looking at the architectures this set supports, I
> >>see clock alias nodes at least for following drivers:
> >>
> >>- GPT timer
> >>- USB
> >>- DCAN
> >>- EMAC
> >>- VPFE
> >>- UART
> >>- SSI
> >>- DSS
> >>- security
> >>- MMC
> >>- MCBSP
> >>- MCSPI
> >>
> >>I am _not_ going to fix all of these during the initial phase. :P
> >>
> >>But yes, eventually these should go away.
> >
> >How many of these are needed to boot? what functionality do we expect
> >with the series -> we can constraint saying that remaining drivers
> >should fix themselves the right way, else dont have the feature -
> >example cpufreq- fix it the right way, or wont see the feature enabled.
> >
> >introducing a "way out" for all of these just invites more guys to screw
> >around claiming "it was done before - see here"..
> >
> >lets just fix the darned basic ones, refuse to provide "way out" and let
> >the others fix themselves.
> >
>
> Yea, that would be one way. I guess someone like Tony should comment
> on this.
Well how about add some dev_warns so we can keep things working and
know which ones to fix? Otherwise it seems that things will not work
properly for many devices.
Regards,
Tony
More information about the linux-arm-kernel
mailing list