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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@xxxxxxxxxxxxxxxx
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
