2018-04-27 10:55 GMT+02:00 Arnd Bergmann <arnd@xxxxxxxx>: > On Fri, Apr 27, 2018 at 10:29 AM, Sekhar Nori <nsekhar@xxxxxx> wrote: >> On Friday 27 April 2018 01:22 PM, Arnd Bergmann wrote: >>> On Fri, Apr 27, 2018 at 4:28 AM, David Lechner <david@xxxxxxxxxxxxxx> wrote: >>>> On 04/26/2018 12:31 PM, Rich Felker wrote: > >>> >>> I haven't seen the discussion about your clock drivers, but I know that >>> usually only a very small subset of the clocks on an SoC are needed >>> that 'early', and you should use a regular platform driver for the rest. >> >> Its true that the subset is small, but they are either PLL bypass clocks >> or clocks derived out of the main clock gate controller on the Soc >> (DaVinci PSC). So we need some non-platform-device based initialization >> support in the two main clock drivers used on mach-davinci anyway. >> >>> Can you elaborate on which devices need to access your clocks before >>> you are able to initialize the clk driver through the regular platform_driver >>> framework? Do any of these need complex interactions with the clk >>> subsystem, or do you just need to ensure they are turned on? >> >> Its just the timer IP. There is no complex interaction, just need to >> ensure that the clock is registered with the framework and also switched >> on when there is a gate clock. >> >> The latest attempt by David for this was posted last night here: >> >> https://lkml.org/lkml/2018/4/26/1093 > > Ok, so the workaround in that series is to set up the timer clk manually > in the SoC specific code (dm365_init_time etc) and register it to the > clk subsystem, right? > > That seems to be a much more appropriate workaround than adding > back early_platform devices. We can always try to do something better > later, but for now I'm happy with that as a workaround. > Just to clarify: this is not bringing back the hacky early platform devices from before. It's a new approach that actually uses the linux platform driver model (unlike the current mechanism which only uses the same data structures). Thanks, Bart -- 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
