On Tue, Jan 12, 2010 at 10:48:34PM +0000, Mark Brown wrote: > On Tue, Jan 12, 2010 at 10:03:51PM +0000, Ben Dooks wrote: > > > I'm not sure that clkdev will do what we need, we have a situatio where > > our platform-device names change depending on the system and thus we > > would have to either change the clk array at init time or do our own > > thing. > > Surely this is exactly the sort of use case that clkdev is designed to > handle? Essentially all it does is provide a remapping layer so that > the data associated with the struct clk doesn't have to bear any direct > relationship to the device and name used to look it up. This means that > the SoC specific code can just define its clock tree in some way that > looks good for the hardware and then easily layer a mapping to what the > drivers expect without the two jobs having to interfere with each other. For the first thing this ends up allocating more memory at run time when we've already got a list of our clocks created from the compile time structures that describe them. I could certainly see that we could use clkdev to deal with this, but I would like to schedule looking at this until after the current round of SoC code cleanups and the addition of the s5p6440 SoC. > > I will certainly eliminate the driver's use of clk_get(dev, "name") to get > > their default bus clock. > > I don't understand what the problem is with that? That's exactly what > I'd expect to see a driver doing (possibly with NULL instead of a > specific name). >From what I've looked at, the driver _should_ use clk_get(dev, NULL) for the bus clock, and use named clocks only for extra clocks it may need such as a codec clock for an audio device. I belive this is what Russell's initial complaint about the implementation is. -- Ben Q: What's a light-year? A: One-third less calories than a regular year. -- To unsubscribe from this list: send the line "unsubscribe linux-samsung-soc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
 |