[linux-sunxi] GSoC 2014 #1 status report - Improving Allwinner SoC support

[jonsmirl at gmail.com]

On Tue, Jul 22, 2014 at 6:22 AM, Chen-Yu Tsai <wens at csie.org> wrote:
> On Sun, Jul 20, 2014 at 12:18 PM, Chen-Yu Tsai <wens at csie.org> wrote:
>> Hi Emilio,
>>
>> On Sun, Jul 20, 2014 at 3:41 AM, Emilio López <emilio at elopez.com.ar> wrote:
>>> Hi everyone,
>>>
>>> Here's this week's update on my GSoC project; if you missed the first issue
>>> or you want a refresher of what this is about, you can read it on the list
>>> archives[0]
>>>
>>> A couple of days after the last report, and with the help of Jon Smirl, I
>>> got the hardware working on mainline Linux, first on only 16 bit stereo
>>> mode, then mono as well, and later on, also on 24 bit mode. The first thing
>>> I had to do was rework the cyclic DMA code to make it perform decently and
>>> avoid underruns. The rest took a bit of playing with values and reading the
>>> Allwinner documentation. There is one unresolved issue with 24 bit audio
>>> still - for some reason, the volume is really low compared to the same track
>>> played on 16 bit. Unfortunately the SDK driver doesn't support 24 bit, so
>>> it's hard to compare with anything else.
>>
>> So I have not experimented on this, it's just a hunch:
>> Could it be that the 24bit audio samples you're sending to the audio codec
>> is aligned incorrectly? So the sample is actually seen as down-shifted by
>> 8 bits, resulting in the low volume?
>
> So the user manual says that 24 bit samples should be right justified,
> or in the most significant bytes. The way to do it in ASoC is to declare
> support 32 bit, instead of 24 bit, audio, and also set .sig_bits to 24.
>
> See: http://www.spinics.net/lists/alsa-devel/msg40846.html
>
> This makes ALSA send 32bit data, and the hardware will drop the lower 8
> bits. S24_LE denotes 24bit in the lower bits, and thus we cannot use it.
>
> However, there is something puzzling about the FIFO modes. The manual
> says that with TX FIFO modes 00/10, 16 bit audio should take the most
> significant 2 bytes of the FIFO as the audio sample to convert. However
> the DMA engine looks like it's writing the least significant 2 bytes.
> I know the code as it is now works, but still I think we should get
> this straightened out.

Are you getting any underrun errors? We both got them.

>
> As a side note, the code still needs some cleaning up. I see some
> duplicate codec/dais.

I initially copied dummy-codec into the source file. It needs to be
removed and the driver should use the dummy-codec provided by ALSA.
The driver should not use simple-audio-card since there is nothing to
bind.

The routing="" in the DTS is to allow you to specify which jacks are
implemented in your hardware. That code is not complete.  Once it is
complete board the Cubietruck DTS could specify only LINEOUT. Then all
of the unneeded ALSA controls will drop out of the UI.

Looks like some sort of clock callback is need to lock the PLL2 rate.
You don't want to have something playing on the codec and then have a
another device reprogram PLL2 in the middle of the song.

No one has tried capture yet. Cubieboard2 has MICIN. I don't have one of those.

>
>> I'll grab your tree and test 24bit tomorrow. (Good thing I have 24 bit
>> music files.) :)
>
> I now have my CubieTruck singing nicely with 24 bit music. Either the
> player or ALSA will extend the 24 bits to 32 bits. The only downside
> is you cannot specify S24_LE when streaming directly to the hardware
> device.
>
>
> Cheers
> ChenYu
>
>>> Aside from the audio stuff, I worked a bit on the DMA driver, after
>>> realizing memcpy could be optimized a fair bit. By using proper alignment
>>> and choosing the best bus width and as big a burst as possible, I was able
>>> to go from a totally unscientifically measured ~3MB/s to ~13MB/s on a single
>>> thread, single channel, 1000 iterations dmatest run with noverify=0. I will
>>> be sending a v3 with these new changes as well as addressing comments I
>>> received in the next few days.
>>
>> This still seems quite slow? I think there was a discussion about this
>> on IRC, you included? Any followups there?
>>
>>> To round up on this week's developments, I also worked on the audio clock
>>> representation, involving PLL2, the codec clock gate and "module 1" clocks
>>> (AC97, SPDIF, IIS) to enable Jon to work on IIS. Patches for these clocks
>>> will be out in the list soon as well.
>>
>> Thanks! I look forward to them.
>>
>>
>> Cheers
>> ChenYu
>>
>>> You can expect the next status report in about a week's time.
>>>
>>> Cheers!
>>>
>>> Emilio
>>>
>>> [0]
>>> http://lists.infradead.org/pipermail/linux-arm-kernel/2014-July/271150.html
>
> --
> 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+unsubscribe at googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



-- 
Jon Smirl
jonsmirl at gmail.com