Re: [PATCH v3] ARM: kirkwood: extend the kirkwood i2s driver for DT usage

[Russell King - ARM Linux <linux@arm.linux.org.uk>]

On Tue, Jul 23, 2013 at 04:01:50PM +0100, Mark Brown wrote:
> On Tue, Jul 23, 2013 at 03:30:57PM +0200, Sebastian Hesselbarth wrote:
> > On 07/23/13 15:20, Mark Brown wrote:
> 
> > >Why would this be required?  The driver is already asking for multiple
> > >clocks...
> 
> > The driver is asking for multiple *DT based* clocks. Legacy
> > platform_data has never been updated to reflect that. Mainly because
> > multiple clocks are only supported on Dove, which has no active non-DT
> > board in mainline.
> 
> Why would platform data have anything to do with this?  To repeat again
> the way the clocks are mapped should be totally transparent to the
> driver requesting them, if it isn't then the driver is not using the API
> properly.

Total rubbish.  Of course the driver needs to know what the clocks are,
so that it can program its hardware accordingly.

What you have here is an audio block which has two clock inputs.  One
clock is the system clock, whose rate can be adjusted but has a massive
impact on the rest of the system.  The other clock input is via an
external pin.

Internally, in one of the audio blocks registers is a set of control bits
which select which clock is to be used to generate the internal timing
for the block, and a divisor on that input.

>From that description, anyone can see that it is absolutely required for
the driver to know which clock is which, so it can program the clock
input selection bit appropriately.

In this case, it has always been the rule with the clock API that it
shall be used as:

	clk_get(device, "internal");

to get the internal clock, and:

	clk_get(device, "external");

to get the external clock - or whatever names are appropriate to name the
clock _inputs_.