[alsa-devel] [RFC PATCH] ASoC: pcm512x: enable set_sysclk callback

[Pierre-Louis Bossart]

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.