On Thu, Dec 7, 2017 at 5:21 PM, Code Kipper <codekipper@xxxxxxxxx> wrote: > On 4 December 2017 at 08:34, Vasily Khoruzhick <anarsoul@xxxxxxxxx> wrote: >> I'd keep it sun50i_a64_acodec_i2s, since other 3 I2S modules aren't >> compatible with this one, but similar to H3. > > Well I wouldn't and the description of it is usage is clearly stated > in the devicetree > for the dai. >> >> On Sun, Dec 3, 2017 at 10:42 PM, Code Kipper <codekipper@xxxxxxxxx> wrote: >>> On 3 December 2017 at 21:41, Vasily Khoruzhick <anarsoul@xxxxxxxxx> wrote: >>>> From: Marcus Cooper <codekipper@xxxxxxxxx> >>>> >>>> The I2S block used for the audio codec in the A64 is very similar >>>> to what is used by the A10(sun4i) devices. However, its TX FIFO is >>>> located at a different address. >>>> >>>> [vasilykh: - added fixed_wss and wss_value to A64 quirks, >>>> - changed compatible to 'allwinner,sun50i-a64-acodec-i2s, >>>> since A64 has 3 more I2S blocks that are not compatible >>>> with audio codec I2S] > This needs to be investigated more...I'm suspicious of the > SUN8I_I2S_FMT0_LRCK_PERIOD value which is hardcoded to 0x1f. > I've made this following change > https://github.com/codekipper/linux-sunxi/commit/4c5fe5f5576cfbb2e1e94a99cd19dfdc9403ea50 > which seems to work for me but I would like to look at it with a logic > analyser and test other sample depths. > CK Another good reason not to have hard-coded values for things that are rightly configurable. :) ChenYu _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
