On 6/4/18 5:40 AM, Mark Brown wrote:
On Fri, Jun 01, 2018 at 04:26:43PM -0500, Pierre-Louis Bossart wrote:
For codec master mode, the current pcm512x code relies on the clock API.
Simple boards such as Hifiberry DAC+ PRO rely on 2 local oscillators
to generate 44.1 or 48kHz multiples, with the clock selection being
handled by the machine driver toggling GPIOS.
The RaspberryPi kernel exposes a "hifiberry,dacpro-clk" clock driver
which does nothing but tell the codec driver what rate is set by the
machine driver [1][2]
This patch suggests an alternate fallback solution to let the codec
driver know what the sysclk is based on the existing .set_sysclk
callback.
I'm not seeing a great advantage in this - we want to have more adoption
of standard APIs for clocking rather than less. As that Pi board shows
it's easy to create static clocks in the clock API so why not just do
that?
What I find odd is the selection between the two static clocks. I have
nothing against the clock API, I just find that the Pi solution isn't
terribly elegant. The machine driver selects the 44.1 or 48kHz
oscillator by configuring GPIO using registers exposed by the codec
driver, the clock API implementation does nothing related to hardware,
so we have three entities involved to flip 2 GPIOs.
And even if I use this solution, I still don't know how to tell the
codec driver which sclk to use in an ACPI environment (this is to enable
HiFiberry cards on Up/Up^2). At the moment the code does
pcm512x->sclk = devm_clk_get(dev, NULL);
and I don't have a moral equivalent for ACPI. I can add information for
the codec driver to get from the DSDT, I'd need however a agreed
solution based on _DSD or some property, and the thread with AMD on
their 'mclk_name' topic for DA7219 didn't go anywhere, did it?
Bottom line there is an 'easy' solution for this specific case and a
more complicated one but potentially more generic based on the clock API
- hence the RFC.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
