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.