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

[<Nick.Thompson@xxxxxxxxxxxx>]

> -----Original Message-----
> From: Russell King - ARM
> Subject: Re: Amba bus definition (amba/bus.h)
>
> As for interrupt flags, all AMBA based systems have never needed to
> specify such details.  Do you have a requirement for that?  If so,
> let's do the job properly and not make these kinds of things
> conditional.

Well maybe not, I do need some more entropy sources though - It seems logical, to me at least, that the device should be able to specify how the interrupt is used - shared or not, entropy source or not, high or low level, edge, etc. - since that is system level, information rather than driver specific.

I can capture default interrupt conditioning in the PIC setup code I suppose (that doesn't seem ideal), but I can't see how to capture shared and random sampling IRQF settings without changing the driver at present. I guess I can just reconfigure the interrupt later as a work around, but that is fragmenting my device description and requires device specific code, of which I require none right now.

>
> > I then changed the mmci driver to use these new fields:
> >
> > -    host->clk = clk_get(&dev->dev, "MCLK");
> > +    host->clk = clk_get(&dev->dev, dev->clk);
>
> NAK.
>
> I'm going to make all the AMBA drivers pass 'NULL' to clk_get() for
> the next kernel; they're just not necessary in drivers where only one
> clock exists.  As is documented, what must be used is the struct device.

If I understand correctly, you (and the docs) are suggesting that get_clk can use the struct device pointer as an identifier and return the appropriate clock details based on that? Since each driver can only have one clock consumer, the name passed is irrelevant?

Fair enough, though it seems to create unnecessary coupling between the clock code and the device definition, as well as extra conditional code in the get_clk implementation. Given the current clock consumer convention, that seems unavoidable. I'll change my clock code to ignore the consumer name and live with it - it's not critical.

Thanks for the pointers.

Nick.

-------------------------------------------------------------------
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