* Tero Kristo <t-kristo@xxxxxx> [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 -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
