On Wednesday, January 13, 2016 at 6:49:03 AM UTC+1, Andrea Venturi wrote:
> hello,
>
>
> i've tested the experimental github branch for I2S DAI mainline linux driver
> on:
> https://github.com/mripard/linux/tree/sunxi/wip/a20-i2s
>
>
>
> my HW setup actually is:
> an Olimex A20-SOM with EValuation Board:
> https://www.olimex.com/Products/SOM/A20/A20-SOM-EVB/the Audio DAC is a
> PCM5102x based low cost device:
> http://www.aliexpress.com/item/PCM5102-DAC-Decoder-I2S-Player-Assembled-Board-32Bit-384K-Beyond-ES9023-PCM1794/32579339671.html
> let me state in advance i've no economic interest at all in these specific
> vendors or products! :-)
>
>
> BTW the PCM510x DAC is a pretty simple device with no cfg at all on the
> software side (there's no I2C or SPI bus [*]) and it does need only three
> wires on the I2S side (BITCLK, LRCLK and DATAIN) as the local system clock is
> "generated" internally with some kind of PLL.
>
>
> so, as technically speaking, the "simple sound card" need two entries for the
> two "legs" (DAI+CODEC) of an audio connection, i had to put in place a pretty
> simple "stub" driver of the PCM codec (patch 0001); this PCM510x codec driver
> needs to be enabled in kernel config for module creation. (also the I2S sunxi
> DAI has to be enabled there)
>
>
> then in patch 0004 there are the DTS entries for the A20-OLIMEX-SOM EVB
> entries enabling the I2S DAI based audio card (the patched DTS enables also
> the analog audio codec here)
>
>
> at this point, as per my tests,we could alreay have a bitstream when doing a
> playback with aplay but with wrong clocks (slower) on BITCLK and LRCLK pins.
>
>
> AFAICS this is happening for two reasons:
> the 4 clock (PLL2x1 .. PLL2x8) entries in DTSI about i2s0 on the clk
> compatible = "allwinner,sun4i-a10-mod1-clk" are reversed , look at others clk
> entries for spdif/ac97 to see they do not match (patch 0002)
> the mod1_clk clock composite driver was not able to set parent rate for a
> missing flag (patch 0003), thanx to mripard for the hint on IRC.
> after these four patches applied, the playback is working "flawlessly" (a
> part of some "scratching frames" in the playback start.. some kind of audio
> muting would be useful at start).
>
>
> a (not so subtle) issue come to mind if both analog audio codec and I2S DAI
> try to playback two streams with incompatible sample rate (44100 and 48000
> for example), i suppose the latest starting would reprogram the PLL2 in a way
> not compatible with the first one. some kind of locking preventing this issue
> would be needed in the long run..
>
>
> i post this mail for further consideration and tests from the linux-sunxi
> community; as i've been told by Maxime Ripard, we are still far from having a
> mainlining of this driver because it would need a proper submission to
> relevant linux group of interests and maintainers (Alsa and ARM i suppose),
> and that's something i'm actually not really ready to properly tackle! :-)
>
>
> me, i'm actually considering to test and implement also the "I2S slave mode"
> where clocks come from "codec" (with a different HW codec, of course and
> report if something useful comes out..)
>
>
> hope this is useful for someone, anyway. that's all, bye
>
>
> Andrea
>
>
> [*] technically speaking there's a "jumper" on the DAC board (selecting from
> "I2S" formatted to LEFT justified I2S data) that is "statically" forced to
> one level (actually i tested I2S only) and i suppose it could be configured
> with an additional GPIO line between SOC and DAC board as selectable on the
> fly at startup or maybe runtime too, but i don't see it a compelling or
> missing feature at all. who carez! :-)
What would be the best way tot test this for me ?
--
You received this message because you are subscribed to the Google Groups
"linux-sunxi" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to linux-sunxi+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
