> The problem is that you've got a chip which has a clock tree of its own > which could benefit from using the clock API internally (in this case > because it helps generalisation to the case where it's on the CPU for > the MMC block to be able to just use the clock API for its clocks).
I see. > Ideally the MFD core for the tmio would be able to extend the clock tree > so that the MMC driver can work without knowing what sort of device it's > part of. Having the platform know about the clocks in the MFD means > teaching each platform that might use the chip about the clocking > structure of the chip in some way. However, there's a concern about > making the clock API too heavyweight for the on-SoC clocks that are the > major application. Things like per-clock memory consumption are an > issue on bigger chips. Right. Well, my proposal of linkage of clock providers via the device-tree would definitely solve that problem for us at least, provided the various parts of the chip are represented as nodes in the DT. > > Having more "generic" clock providers for off-SoC clock chips is an idea > > that went through my mind but you may be right that it's not necessarily > > something we need to cater for initially, it can be handled by platform > > for now easily enough. > > So long as that's clear to device tree users that should be fine. That's my thought too. Cheers, Ben. _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
