Re: Amba bus definition (amba/bus.h)

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Mon, Nov 10, 2008 at 02:32:33PM +0100, Nick.Thompson@xxxxxxxxxxxx wrote:
> > No, drivers can have multiple consumers, and some chips do.  OMAP for
> > instance has one 'ick' and one 'fck' per peripheral device.
> >
> > Most primecells actually have two clock inputs - the bus clock and the
> > function clock.  In all cases so far, the bus clock isn't visible to
> > software, so we ignore it.
> >
> > So it's not universally true that there is a one-to-one relationship
> > between struct device and struct clk.
> 
> This seems counter intuitive to your intention to make AMBA device
> drivers pass a NULL id to get_clk().

Where there is only one clock per device, the ID is redundant.  So passing
a driver unique ID just means that we're encouraging the wrong approach
for clk_get() - encouraging implementations which are contary to the
API documentation.

> Are you not creating a inconsistency between AMBA devices and other
> devices which also call get_clk()?

No, because the API already calls for the device and the consumer ID.

> > If they were to have to pass in the clock names via platform data,
> > they'd be having to create lots of platform_data structures for each
> > device to pass the clock names in, and then they've got to maintain:
> >
> > 1. a list of struct clk's.
> > 2. a set of platform devices.
> > 3. a set of platform device data for every platform device to specify
> >    which clks to use.
> >
> > So, why have the additional names for struct clks and additional
> > structures that require manual maintanence when you already have a
> > set of static names for devices and can match by those names instead?
> 
> Great, but then the get_clk() code has to maintain a list of device name
> to clk struct mappings. I wouldn't necessarily expect to have device
> related data, arguably hidden, in the clock code.

They already maintain a consumer ID name to clk mapping.  It's just a
different (but more correct) string.

> The device definition seems like a natural place to put data about
> device connectivity information, just like irq numbers and device
> bus addresses (chip select connectivity). Clock usage just seems
> to me like similar connectivity data for the device.

So you want to see drivers contain code like I've showed you in my
previous mail?

> Having this info in the device allows for the device definitions to
> change as the SoC evolves, quite possibly without recompiling the
> kernel.

You mean like the mess which OMAP has ended up with.

> The devices can be recompiled and dynamically loaded or the irq and
> clk data even set as module parameters.

That's quite insane actually - that means that userspace needs to be
configured, or even the boot loader with platform specific information
which is also kernel specific as well.  So, when you update the kernel
you could well be facing having to also update the boot loader and the
filesystem together.

The vast majority of people are scared of touching the boot loader!

> The clock code would only change if the clock architecture changed.
> Even new devices, not accounted for in get_clk, could be added
> without recompiling or even rebooting the kernel.

I don't that the the clk API stands in the way of that at present.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php