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.
