On 2/23/16 9:32 PM, Mark Brown wrote:
On Wed, Feb 24, 2016 at 12:08:31AM +0100, Heiko Stuebner wrote:
Am Dienstag, 23. Februar 2016, 08:50:04 schrieb Pierre-Louis
Bossart:
This patch assumes that the information on mclk comes from
DeviceTree. The mclk may also be enabled/disabled in the machine
driver with an explicit transition to use an internal clock when
the codec is not used. I hope this patch doesn't preclude such
usages or there will be a conflict with the patches we are about
to upstream for Baytrail/cht devices.
As you can see, the clock property itself is optional and the
clk_get below acts accordingly of also continuing if the clock is
not present. So it won't affect any users doing it otherwise.
That said we really do need x86 to transition to use the clock API
in order to integrate with external devices, where the machine driver
does manage clocks we want that to move to being done using the clock
API rather than custom APIs.
For Baytrail audio we have a single platform clock that can be turned
on/off and set to 19.2 MHz or 25 MHz. No other controls are available,
no multipliers or complicated dependencies on other clocks, parents or
children and no other users for this clock but the audio subsystem.
I looked at the clock framework and couldn't figure out how it would
simply map the hardware so for now the use of the MCLK is only enabled
with an on/off or set-rate(19.2|25) custom API. I am not an expert here
so if this clock framework becomes a requirement to upstream code I
would appreciate any pointers to do the right thing. I really couldn't
find a simple example with 'Put your code here' comments to use this
framework.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
