[alsa-devel] [PATCH 1/2] ASoC: pcm5102a: Add support for PCM5102A codec

[Emmanuel Fusté]

Le 24/05/2016 à 16:44, Ricard Wanderlof a écrit :
>
> On Mon, 23 May 2016, Emmanuel Fusté wrote:
>
>> /* pcm5102a in HW mode with external SCK (4wire mode)
>>  * at 128fs, 192fs or 256fs
>>  */
>> 	pcm5102a-4w: pcm5102a {
>> 		compatible = "simple-i2s-codec";
>> 		rate = <SNDRV_PCM_RATE_8000_192000>;
>> 		format = < SNDRV_PCM_FMTBIT_S16_LE
>> 			|SNDRV_PCM_FMTBIT_S24_LE
>> 			|SNDRV_PCM_FMTBIT_S32_LE>;
>> 	};
>> or
>> /* pcm5102a in HW mode with PLL on BCK (3wire mode)
>>  * 16to384khz but only with bck rate of 64fs
>>  */
>> 	pcm5102a-4w: pcm5102a {
>> 		compatible = "simple-i2s-codec";
>> 		rate = <SNDRV_PCM_RATE_8000_192000
>> 			^ SNDRV_PCM_RATE_8000>;
>> 		format = <SNDRV_PCM_FMTBIT_S32_LE>;
>> 	};
>> Or
>> /* ES9023 in asynchronous mode mclk > 37Mhz
>>  * I did not try bck rate <64fs as the sabre family did not generally
>>  * support it.
>>  */
>> 	es9023: es9023 {
>> 		compatible = "simple-i2s-codec";
>> 		rate = <SNDRV_PCM_RATE_8000_192000>;
>> 		format = <SNDRV_PCM_FMTBIT_S32_LE>;
>> 	};
>>
>> We could use I2S friendly property instead of "format" :
>> 		bckrates = <48, 64>;
>>
>>
>> With two or tree more property (gpio for mute, de-emphasis and filter
>> selection), you could cover 98% of I2S DAC with hardware only interfaces. It
>> cover too startup mode of most hifi I2C or SPI controllable DAC. Which is a
>> good starting point for chip for which a driver is not already written.
>
> It seems to me that this only covers the cases where the is codec running
> in slave mode with MCLK derived from the BCLK, but not cases where the
> codec is master and needs to have its MCLK configured appropriately (in
> terms of device-specifc clock source and PLL settings), or am I missing
> something?
>
> /Ricard
>

It not a codec but a simple I2S DAC.
No I2S master mode.
Like most DAC before the CODEC era and all the big mess around them.
In the ES9023 case, the MCLK could either have no frequency an no phase 
relationship with the I2S clocks.
In this case, the MCLK is surely derived from a clock of the Rpi SOC so 
you are right, and the whole HifiBerry driver should be rewritten with 
proper abstraction like Mark suggested : Clock binding etc ...
But now as Mark say too, clock api integration is a goal, but not there.
The proposed hw param rules is a start to not have to write specific 
machine driver because of clocking constraints.
It is the second time I am scratching my head because of clocking 
constraints and because I want to do something better than writing 
another trivial machine driver.
In my case (BBB or other Ti soc using mcasp) I will have to had 
mux/clk_set_parent switching action and/or clk_set_rate action. But I am 
not persuaded that is it the way to go.

That why, by the time we get proper clock api integration with proper 
constraint and constraint description mechanism, a simple DT 
configurable codec driver in which we push the resulting constraint 
(DAC+SOC+design choice) was appealing.

But you are all right. This is not the long term proper way. And the 
actual ultra simple PCM510xA driver could evolve to support all GPIO and 
later properly express all his clock constraints independently of the 
implementation choices.

Thank your for your patience.

Emmanuel.