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