GSoC 2014 #0 status report - Improving Allwinner SoC support

GSoC 2014 #0 status report - Improving Allwinner SoC support

[Emilio López]

Hi everyone,

As some of you may know, I'm currently participating in Google Summer of 
Code under the Linux Foundation, working on a proposal titled "Improve 
Allwinner SoCs support on mainline Linux". There is a great quantity of 
devices out there that are powered by Allwinner processors, including 
but not limited to the various Cubieboards, OLinuXinos, STBs, Tablets 
and ?Mini PCs?. However, to date, support on mainline Linux is not yet 
feature complete. My proposal on particular focuses on DMA and analog 
audio on the earlier SoCs, and improved A23 support.

The idea here is to make a weekly status report of the project. As we 
are starting mid-program, this one will be a bit different and I'll 
outline what has been worked on so far since the beginning.

To date, I have been mainly working on the DMA driver for sun4i, sun5i 
and sun7i. Despite having completely different drivers on SDK kernels, 
the hardware block looks and behaves the same, so we are using a single 
driver for these three SoC families. I have sent a series of patches[1] 
as well as a follow-up v2[2], and I will keep iterating over it until 
it's accepted. I have also sent two trivial patches[3][4] as a side-effect.

The main challenges while writing this driver can be summarized as a 
lack of documentation. First of all, it took me a bit to get to know 
DMAEngine. As there is not much documentation on it, most of my learning 
took place by reading pre-existing drivers and consulting with my 
mentor. Secondly, as the Allwinner documentation is mostly a register 
list with bitfield details, I also had to read the SDK drivers and do 
some trial and error testing to discover magic values and understand others.

Lately, I have also been working on the audio part, now that I have a 
working DMA driver. After implementing cyclic DMA transfers and some 
clock code, and armed with a Buildroot image with mpg123 and an OpenBSD 
release track[5] in mp3 format, I've been trying to get some sound out 
of my Cubietruck's headphone jack, but without much success so far. I 
have verified my userspace stack and hardware by running these same 
binaries on top of the linux-sunxi 3.4 kernel, and it worked fine. I 
have since then been dumping relevant registers with devmem and 
comparing them, resolving issues as I see them - hopefully this will 
yield some audible results.

Interestingly enough, Allwinner themselves do not seem to be using 
cyclic DMA transfers on their driver[6]. I hope this is not a sign of a 
hardware bug that's not documented.

To give some closure to this status report, I'd like to thank Maxime for 
his mentoring so far, Ezequiel for letting me pick his brain, and the 
Linux Foundation and Google for giving me this opportunity, as well as 
everyone on the kernel and sunxi communities who have come forward to 
review and test patches. You can expect a new report soon, in about a 
week's time or less.

Emilio

[1] http://www.spinics.net/lists/dmaengine/msg01148.html
[2] http://www.spinics.net/lists/arm-kernel/msg344766.html
[3] https://lkml.org/lkml/2014/5/11/166
[4] https://lkml.org/lkml/2014/7/1/486
[5] http://www.openbsd.org/lyrics.html, maybe I should consider using 
some other song for better luck
[6] 
https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L1137

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

[Hans de Goede]

Hi Emilio,

On 07/10/2014 05:41 AM, Emilio L?pez wrote:
> Hi everyone,
> 
> As some of you may know, I'm currently participating in Google Summer of Code under the Linux Foundation, working on a proposal titled "Improve Allwinner SoCs support on mainline Linux". There is a great quantity of devices out there that are powered by Allwinner processors, including but not limited to the various Cubieboards, OLinuXinos, STBs, Tablets and ?Mini PCs?. However, to date, support on mainline Linux is not yet feature complete. My proposal on particular focuses on DMA and analog audio on the earlier SoCs, and improved A23 support.

I did not know you were working on this as part of gsoc, good to hear!

Keep up the good work.

Regards,

Hans

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

[jonsmirl at gmail.com]

On Wed, Jul 9, 2014 at 11:41 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
> Hi everyone,
>
> As some of you may know, I'm currently participating in Google Summer of
> Code under the Linux Foundation, working on a proposal titled "Improve
> Allwinner SoCs support on mainline Linux". There is a great quantity of
> devices out there that are powered by Allwinner processors, including but
> not limited to the various Cubieboards, OLinuXinos, STBs, Tablets and ?Mini
> PCs?. However, to date, support on mainline Linux is not yet feature
> complete. My proposal on particular focuses on DMA and analog audio on the
> earlier SoCs, and improved A23 support.
>
> The idea here is to make a weekly status report of the project. As we are
> starting mid-program, this one will be a bit different and I'll outline what
> has been worked on so far since the beginning.
>
> To date, I have been mainly working on the DMA driver for sun4i, sun5i and
> sun7i. Despite having completely different drivers on SDK kernels, the
> hardware block looks and behaves the same, so we are using a single driver
> for these three SoC families. I have sent a series of patches[1] as well as
> a follow-up v2[2], and I will keep iterating over it until it's accepted. I
> have also sent two trivial patches[3][4] as a side-effect.
>
> The main challenges while writing this driver can be summarized as a lack of
> documentation. First of all, it took me a bit to get to know DMAEngine. As
> there is not much documentation on it, most of my learning took place by
> reading pre-existing drivers and consulting with my mentor. Secondly, as the
> Allwinner documentation is mostly a register list with bitfield details, I
> also had to read the SDK drivers and do some trial and error testing to
> discover magic values and understand others.
>
> Lately, I have also been working on the audio part, now that I have a
> working DMA driver. After implementing cyclic DMA transfers and some clock
> code, and armed with a Buildroot image with mpg123 and an OpenBSD release
> track[5] in mp3 format, I've been trying to get some sound out of my
> Cubietruck's headphone jack, but without much success so far. I have
> verified my userspace stack and hardware by running these same binaries on
> top of the linux-sunxi 3.4 kernel, and it worked fine. I have since then
> been dumping relevant registers with devmem and comparing them, resolving
> issues as I see them - hopefully this will yield some audible results.
>

Check out the last commit in this branch. It is based on your current
DMA branch.
https://github.com/jonsmirl/lpc31xx/tree/linus

I am getting noise out of the codec but it is not the right noise.
Plus the cyclic transfer falls over when the buffer wraps. There is no
need to use the CONT bit on the Allwinner DMA hardware to implement
cyclic.

The DMA interrupt routine should directly program in the next transfer
in the promise chain when the previous one completes. Doing it from
the tasklet opens a window where kernel task swap delays can cause DMA
underrun.




> Interestingly enough, Allwinner themselves do not seem to be using cyclic
> DMA transfers on their driver[6]. I hope this is not a sign of a hardware
> bug that's not documented.
>
> To give some closure to this status report, I'd like to thank Maxime for his
> mentoring so far, Ezequiel for letting me pick his brain, and the Linux
> Foundation and Google for giving me this opportunity, as well as everyone on
> the kernel and sunxi communities who have come forward to review and test
> patches. You can expect a new report soon, in about a week's time or less.
>
> Emilio
>
> [1] http://www.spinics.net/lists/dmaengine/msg01148.html
> [2] http://www.spinics.net/lists/arm-kernel/msg344766.html
> [3] https://lkml.org/lkml/2014/5/11/166
> [4] https://lkml.org/lkml/2014/7/1/486
> [5] http://www.openbsd.org/lyrics.html, maybe I should consider using some
> other song for better luck
> [6]
> https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L1137
>
> --
> 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

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

[jonsmirl at gmail.com]

On Thu, Jul 10, 2014 at 8:32 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Wed, Jul 9, 2014 at 11:41 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
>> Hi everyone,
>>
>> As some of you may know, I'm currently participating in Google Summer of
>> Code under the Linux Foundation, working on a proposal titled "Improve
>> Allwinner SoCs support on mainline Linux". There is a great quantity of
>> devices out there that are powered by Allwinner processors, including but
>> not limited to the various Cubieboards, OLinuXinos, STBs, Tablets and ?Mini
>> PCs?. However, to date, support on mainline Linux is not yet feature
>> complete. My proposal on particular focuses on DMA and analog audio on the
>> earlier SoCs, and improved A23 support.
>>
>> The idea here is to make a weekly status report of the project. As we are
>> starting mid-program, this one will be a bit different and I'll outline what
>> has been worked on so far since the beginning.
>>
>> To date, I have been mainly working on the DMA driver for sun4i, sun5i and
>> sun7i. Despite having completely different drivers on SDK kernels, the
>> hardware block looks and behaves the same, so we are using a single driver
>> for these three SoC families. I have sent a series of patches[1] as well as
>> a follow-up v2[2], and I will keep iterating over it until it's accepted. I
>> have also sent two trivial patches[3][4] as a side-effect.
>>
>> The main challenges while writing this driver can be summarized as a lack of
>> documentation. First of all, it took me a bit to get to know DMAEngine. As
>> there is not much documentation on it, most of my learning took place by
>> reading pre-existing drivers and consulting with my mentor. Secondly, as the
>> Allwinner documentation is mostly a register list with bitfield details, I
>> also had to read the SDK drivers and do some trial and error testing to
>> discover magic values and understand others.
>>
>> Lately, I have also been working on the audio part, now that I have a
>> working DMA driver. After implementing cyclic DMA transfers and some clock
>> code, and armed with a Buildroot image with mpg123 and an OpenBSD release
>> track[5] in mp3 format, I've been trying to get some sound out of my
>> Cubietruck's headphone jack, but without much success so far. I have
>> verified my userspace stack and hardware by running these same binaries on
>> top of the linux-sunxi 3.4 kernel, and it worked fine. I have since then
>> been dumping relevant registers with devmem and comparing them, resolving
>> issues as I see them - hopefully this will yield some audible results.
>>
>
> Check out the last commit in this branch. It is based on your current
> DMA branch.
> https://github.com/jonsmirl/lpc31xx/tree/linus
>
> I am getting noise out of the codec but it is not the right noise.
> Plus the cyclic transfer falls over when the buffer wraps. There is no
> need to use the CONT bit on the Allwinner DMA hardware to implement
> cyclic.
>
> The DMA interrupt routine should directly program in the next transfer
> in the promise chain when the previous one completes. Doing it from
> the tasklet opens a window where kernel task swap delays can cause DMA
> underrun.


This commit is my WIP code.
https://github.com/jonsmirl/lpc31xx/commit/dcbab1749af5fd82a65d72670a7a77f7ee734ba8

Where is yours? I don't see it in your repo.


>
>
>
>
>> Interestingly enough, Allwinner themselves do not seem to be using cyclic
>> DMA transfers on their driver[6]. I hope this is not a sign of a hardware
>> bug that's not documented.
>>
>> To give some closure to this status report, I'd like to thank Maxime for his
>> mentoring so far, Ezequiel for letting me pick his brain, and the Linux
>> Foundation and Google for giving me this opportunity, as well as everyone on
>> the kernel and sunxi communities who have come forward to review and test
>> patches. You can expect a new report soon, in about a week's time or less.
>>
>> Emilio
>>
>> [1] http://www.spinics.net/lists/dmaengine/msg01148.html
>> [2] http://www.spinics.net/lists/arm-kernel/msg344766.html
>> [3] https://lkml.org/lkml/2014/5/11/166
>> [4] https://lkml.org/lkml/2014/7/1/486
>> [5] http://www.openbsd.org/lyrics.html, maybe I should consider using some
>> other song for better luck
>> [6]
>> https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L1137
>>
>> --
>> 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



-- 
Jon Smirl
jonsmirl at gmail.com

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

[jonsmirl at gmail.com]

On Thu, Jul 10, 2014 at 8:38 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Jul 10, 2014 at 8:32 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Wed, Jul 9, 2014 at 11:41 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
>>> Hi everyone,
>>>
>>> As some of you may know, I'm currently participating in Google Summer of
>>> Code under the Linux Foundation, working on a proposal titled "Improve
>>> Allwinner SoCs support on mainline Linux". There is a great quantity of
>>> devices out there that are powered by Allwinner processors, including but
>>> not limited to the various Cubieboards, OLinuXinos, STBs, Tablets and ?Mini
>>> PCs?. However, to date, support on mainline Linux is not yet feature
>>> complete. My proposal on particular focuses on DMA and analog audio on the
>>> earlier SoCs, and improved A23 support.
>>>
>>> The idea here is to make a weekly status report of the project. As we are
>>> starting mid-program, this one will be a bit different and I'll outline what
>>> has been worked on so far since the beginning.
>>>
>>> To date, I have been mainly working on the DMA driver for sun4i, sun5i and
>>> sun7i. Despite having completely different drivers on SDK kernels, the
>>> hardware block looks and behaves the same, so we are using a single driver
>>> for these three SoC families. I have sent a series of patches[1] as well as
>>> a follow-up v2[2], and I will keep iterating over it until it's accepted. I
>>> have also sent two trivial patches[3][4] as a side-effect.
>>>
>>> The main challenges while writing this driver can be summarized as a lack of
>>> documentation. First of all, it took me a bit to get to know DMAEngine. As
>>> there is not much documentation on it, most of my learning took place by
>>> reading pre-existing drivers and consulting with my mentor. Secondly, as the
>>> Allwinner documentation is mostly a register list with bitfield details, I
>>> also had to read the SDK drivers and do some trial and error testing to
>>> discover magic values and understand others.
>>>
>>> Lately, I have also been working on the audio part, now that I have a
>>> working DMA driver. After implementing cyclic DMA transfers and some clock
>>> code, and armed with a Buildroot image with mpg123 and an OpenBSD release
>>> track[5] in mp3 format, I've been trying to get some sound out of my
>>> Cubietruck's headphone jack, but without much success so far. I have
>>> verified my userspace stack and hardware by running these same binaries on
>>> top of the linux-sunxi 3.4 kernel, and it worked fine. I have since then
>>> been dumping relevant registers with devmem and comparing them, resolving
>>> issues as I see them - hopefully this will yield some audible results.
>>>

Residue is not calculated correctly...  it is bytes left, not bytes transmitted.

 * @residue: the remaining number of bytes left to transmit
 * on the selected transfer for states DMA_IN_PROGRESS and
 * DMA_PAUSED if this is implemented in the driver, else 0

list_for_each_entry(promise, &contract->demands, list) {
bytes += promise->len;
}

/*
* The hardware is configured to return the remaining byte
* quantity. If possible, replace the first listed element's
* full size with the actual remaining amount
*/
promise = list_first_entry_or_null(&contract->demands,
  struct sun4i_dma_promise, list);
if (promise && pchan) {
bytes -= promise->len;
if (pchan->is_dedicated)
bytes += readl(pchan->base + DDMA_BYTE_COUNT_REG);
else
bytes += readl(pchan->base + NDMA_BYTE_COUNT_REG);
}

exit:

dma_set_residue(state, bytes);


-- 
Jon Smirl
jonsmirl at gmail.com

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

[jonsmirl at gmail.com]

On Thu, Jul 10, 2014 at 12:13 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Thu, Jul 10, 2014 at 8:38 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>> On Thu, Jul 10, 2014 at 8:32 AM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
>>> On Wed, Jul 9, 2014 at 11:41 PM, Emilio L?pez <emilio@elopez.com.ar> wrote:
>>>> Hi everyone,
>>>>
>>>> As some of you may know, I'm currently participating in Google Summer of
>>>> Code under the Linux Foundation, working on a proposal titled "Improve
>>>> Allwinner SoCs support on mainline Linux". There is a great quantity of
>>>> devices out there that are powered by Allwinner processors, including but
>>>> not limited to the various Cubieboards, OLinuXinos, STBs, Tablets and ?Mini
>>>> PCs?. However, to date, support on mainline Linux is not yet feature
>>>> complete. My proposal on particular focuses on DMA and analog audio on the
>>>> earlier SoCs, and improved A23 support.
>>>>
>>>> The idea here is to make a weekly status report of the project. As we are
>>>> starting mid-program, this one will be a bit different and I'll outline what
>>>> has been worked on so far since the beginning.
>>>>
>>>> To date, I have been mainly working on the DMA driver for sun4i, sun5i and
>>>> sun7i. Despite having completely different drivers on SDK kernels, the
>>>> hardware block looks and behaves the same, so we are using a single driver
>>>> for these three SoC families. I have sent a series of patches[1] as well as
>>>> a follow-up v2[2], and I will keep iterating over it until it's accepted. I
>>>> have also sent two trivial patches[3][4] as a side-effect.
>>>>
>>>> The main challenges while writing this driver can be summarized as a lack of
>>>> documentation. First of all, it took me a bit to get to know DMAEngine. As
>>>> there is not much documentation on it, most of my learning took place by
>>>> reading pre-existing drivers and consulting with my mentor. Secondly, as the
>>>> Allwinner documentation is mostly a register list with bitfield details, I
>>>> also had to read the SDK drivers and do some trial and error testing to
>>>> discover magic values and understand others.
>>>>
>>>> Lately, I have also been working on the audio part, now that I have a
>>>> working DMA driver. After implementing cyclic DMA transfers and some clock
>>>> code, and armed with a Buildroot image with mpg123 and an OpenBSD release
>>>> track[5] in mp3 format, I've been trying to get some sound out of my
>>>> Cubietruck's headphone jack, but without much success so far. I have
>>>> verified my userspace stack and hardware by running these same binaries on
>>>> top of the linux-sunxi 3.4 kernel, and it worked fine. I have since then
>>>> been dumping relevant registers with devmem and comparing them, resolving
>>>> issues as I see them - hopefully this will yield some audible results.
>>>>
>
> Residue is not calculated correctly...  it is bytes left, not bytes transmitted.

Scratch that, I see hardware reports bytes left, not transmitted. So
problem I am getting from ALSA with residue calc must be somewhere
else.

>
>  * @residue: the remaining number of bytes left to transmit
>  * on the selected transfer for states DMA_IN_PROGRESS and
>  * DMA_PAUSED if this is implemented in the driver, else 0
>
> list_for_each_entry(promise, &contract->demands, list) {
> bytes += promise->len;
> }
>
> /*
> * The hardware is configured to return the remaining byte
> * quantity. If possible, replace the first listed element's
> * full size with the actual remaining amount
> */
> promise = list_first_entry_or_null(&contract->demands,
>   struct sun4i_dma_promise, list);
> if (promise && pchan) {
> bytes -= promise->len;
> if (pchan->is_dedicated)
> bytes += readl(pchan->base + DDMA_BYTE_COUNT_REG);
> else
> bytes += readl(pchan->base + NDMA_BYTE_COUNT_REG);
> }
>
> exit:
>
> dma_set_residue(state, bytes);
>
>
> --
> Jon Smirl
> jonsmirl at gmail.com



-- 
Jon Smirl
jonsmirl at gmail.com

GSoC 2014 #0 status report - Improving Allwinner SoC support

[Maxime Ripard]

Hi,

On Thu, Jul 10, 2014 at 12:41:03AM -0300, Emilio L?pez wrote:
> Hi everyone,
> 
> As some of you may know, I'm currently participating in Google
> Summer of Code under the Linux Foundation, working on a proposal
> titled "Improve Allwinner SoCs support on mainline Linux". There is
> a great quantity of devices out there that are powered by Allwinner
> processors, including but not limited to the various Cubieboards,
> OLinuXinos, STBs, Tablets and ?Mini PCs?. However, to date, support
> on mainline Linux is not yet feature complete. My proposal on
> particular focuses on DMA and analog audio on the earlier SoCs, and
> improved A23 support.
> 
> The idea here is to make a weekly status report of the project. As
> we are starting mid-program, this one will be a bit different and
> I'll outline what has been worked on so far since the beginning.
> 
> To date, I have been mainly working on the DMA driver for sun4i,
> sun5i and sun7i. Despite having completely different drivers on SDK
> kernels, the hardware block looks and behaves the same, so we are
> using a single driver for these three SoC families. I have sent a
> series of patches[1] as well as a follow-up v2[2], and I will keep
> iterating over it until it's accepted. I have also sent two trivial
> patches[3][4] as a side-effect.

Yep, thanks a lot for that good work.

Hopefully, it will be merged rather soon, as it looks quite nice
already.

> The main challenges while writing this driver can be summarized as a
> lack of documentation. First of all, it took me a bit to get to know
> DMAEngine. As there is not much documentation on it, most of my
> learning took place by reading pre-existing drivers and consulting
> with my mentor. Secondly, as the Allwinner documentation is mostly a
> register list with bitfield details, I also had to read the SDK
> drivers and do some trial and error testing to discover magic values
> and understand others.

I feel your pain :)

> Lately, I have also been working on the audio part, now that I have
> a working DMA driver. After implementing cyclic DMA transfers and
> some clock code, and armed with a Buildroot image with mpg123 and an
> OpenBSD release track[5] in mp3 format, I've been trying to get some
> sound out of my Cubietruck's headphone jack, but without much
> success so far. I have verified my userspace stack and hardware by
> running these same binaries on top of the linux-sunxi 3.4 kernel,
> and it worked fine. I have since then been dumping relevant
> registers with devmem and comparing them, resolving issues as I see
> them - hopefully this will yield some audible results.

What have you been working on? A new driver from scratch, tried to
take Allwinner's code and then cleant it up, or used the recently
published driver Jon made?

> Interestingly enough, Allwinner themselves do not seem to be using
> cyclic DMA transfers on their driver[6]. I hope this is not a sign
> of a hardware bug that's not documented.

So they just implement a cyclic-like behaviour in software?

> To give some closure to this status report, I'd like to thank Maxime
> for his mentoring so far, Ezequiel for letting me pick his brain,
> and the Linux Foundation and Google for giving me this opportunity,
> as well as everyone on the kernel and sunxi communities who have
> come forward to review and test patches. You can expect a new report
> soon, in about a week's time or less.

Keep up the good work.

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140710/5b8b35cc/attachment.sig>

[linux-sunxi] Re: GSoC 2014 #0 status report - Improving Allwinner SoC support

[jonsmirl at gmail.com]

On Thu, Jul 10, 2014 at 4:39 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Thu, Jul 10, 2014 at 12:41:03AM -0300, Emilio L?pez wrote:
>> Hi everyone,
>>
>> As some of you may know, I'm currently participating in Google
>> Summer of Code under the Linux Foundation, working on a proposal
>> titled "Improve Allwinner SoCs support on mainline Linux". There is
>> a great quantity of devices out there that are powered by Allwinner
>> processors, including but not limited to the various Cubieboards,
>> OLinuXinos, STBs, Tablets and ?Mini PCs?. However, to date, support
>> on mainline Linux is not yet feature complete. My proposal on
>> particular focuses on DMA and analog audio on the earlier SoCs, and
>> improved A23 support.
>>
>> The idea here is to make a weekly status report of the project. As
>> we are starting mid-program, this one will be a bit different and
>> I'll outline what has been worked on so far since the beginning.
>>
>> To date, I have been mainly working on the DMA driver for sun4i,
>> sun5i and sun7i. Despite having completely different drivers on SDK
>> kernels, the hardware block looks and behaves the same, so we are
>> using a single driver for these three SoC families. I have sent a
>> series of patches[1] as well as a follow-up v2[2], and I will keep
>> iterating over it until it's accepted. I have also sent two trivial
>> patches[3][4] as a side-effect.
>
> Yep, thanks a lot for that good work.
>
> Hopefully, it will be merged rather soon, as it looks quite nice
> already.
>
>> The main challenges while writing this driver can be summarized as a
>> lack of documentation. First of all, it took me a bit to get to know
>> DMAEngine. As there is not much documentation on it, most of my
>> learning took place by reading pre-existing drivers and consulting
>> with my mentor. Secondly, as the Allwinner documentation is mostly a
>> register list with bitfield details, I also had to read the SDK
>> drivers and do some trial and error testing to discover magic values
>> and understand others.
>
> I feel your pain :)
>
>> Lately, I have also been working on the audio part, now that I have
>> a working DMA driver. After implementing cyclic DMA transfers and
>> some clock code, and armed with a Buildroot image with mpg123 and an
>> OpenBSD release track[5] in mp3 format, I've been trying to get some
>> sound out of my Cubietruck's headphone jack, but without much
>> success so far. I have verified my userspace stack and hardware by
>> running these same binaries on top of the linux-sunxi 3.4 kernel,
>> and it worked fine. I have since then been dumping relevant
>> registers with devmem and comparing them, resolving issues as I see
>> them - hopefully this will yield some audible results.
>
> What have you been working on? A new driver from scratch, tried to
> take Allwinner's code and then cleant it up, or used the recently
> published driver Jon made?
>
>> Interestingly enough, Allwinner themselves do not seem to be using
>> cyclic DMA transfers on their driver[6]. I hope this is not a sign
>> of a hardware bug that's not documented.
>
> So they just implement a cyclic-like behaviour in software?

>From what I can tell the Allwinner hardware will just cycle on a
single buffer.  Cyclic DMA for the kernel needs to cycle on the
equivalent of a scatter/gather list (in most cases the buffers are
sequential periodic splits of a single buffer).  And as each segment
completes it needs to signal the DMA subsystem.  Allwinner chips don't
support hardware scatter gather but that isn't a major problem.

I have this kind of working in my version of the DMA driver. But I'd
rather be working on audio code than DMA so I will switch as soon as
there is a better option. My goal is to get I2S going and the on-chip
codec is just a stepping stone.

I do think the DMA driver needs to be modified so that as the promise
completes the next promise is programmed into the channel inside the
ISR instead of dropping back to the tasklet.  There is a hard
real-time deadline on when that FIFO will empty. With 192K audio that
deadline is around 50us.  All of the other DMA drivers I have looked
at program in the next segment from the ISR.


>
>> To give some closure to this status report, I'd like to thank Maxime
>> for his mentoring so far, Ezequiel for letting me pick his brain,
>> and the Linux Foundation and Google for giving me this opportunity,
>> as well as everyone on the kernel and sunxi communities who have
>> come forward to review and test patches. You can expect a new report
>> soon, in about a week's time or less.
>
> Keep up the good work.
>
> Maxime
>
> --
> Maxime Ripard, Free Electrons
> Embedded Linux, Kernel and Android engineering
> http://free-electrons.com



-- 
Jon Smirl
jonsmirl at gmail.com

[linux-sunxi] Re: GSoC 2014 #0 status report - Improving Allwinner SoC support

[Russell King - ARM Linux]

On Thu, Jul 10, 2014 at 06:40:42PM -0400, jonsmirl at gmail.com wrote:
> On Thu, Jul 10, 2014 at 4:39 PM, Maxime Ripard
> <maxime.ripard@free-electrons.com> wrote:
> > So they just implement a cyclic-like behaviour in software?
> 
> From what I can tell the Allwinner hardware will just cycle on a
> single buffer.  Cyclic DMA for the kernel needs to cycle on the
> equivalent of a scatter/gather list (in most cases the buffers are
> sequential periodic splits of a single buffer).  And as each segment
> completes it needs to signal the DMA subsystem.  Allwinner chips don't
> support hardware scatter gather but that isn't a major problem.

With cyclic DMA, there is no requirement in DMAengine to strictly report
each period completion (due to the behaviour of tasklets.)  However,
ASoC requires one of two things, either:

1. One callback per completed period
2. A report of the current position in the cyclic DMA cycle (via the
   number of bytes remaining to the end of the buffer.)

Either will do, and if you have to implement something which counts
how many callbacks you need to do to satisfy (1), you might as well
implement (2) instead - it's much more efficient that way.

Internally, ALSA prefers (2) because each time you issue the callback,
snd_pcm_period_elapsed() will be called.  This does a load of
processing, including reading where the DMA pointer is so that ALSA
can calculate the appropriate position in the buffer.

That really only needs to happen once per "service" - as per the
documentation for snd_pcm_period_elapsed() on the net.

So, if you find that you've completed two periods, your choices either
to report: "one period completed, one period completed" and have two
runs through snd_pcm_period_elapsed(), or "update DMA residue, period(s)
completed".

I switched imx-sdma.c to use (2) because I was seeing problems with
(1) - see "imx-sdma: update cyclic handling to report residue".

I'd encourage everyone to use (2) rather than (1) - in fact, I'd
suggest that the first method is deprecated and removed.  If the
DMAengine driver knows how many times to make the callback, it can
implement the residue too and not need to play that game.

Another point here is if you are implementing cyclic behaviour in
software, then you need to deal with the cyclic stuff in the hardware
interrupt function, not in the tasklet.  There's too much latency with
getting to the tasklet, especially if you have USB devices (which
chew lots of interrupt time.)

-- 
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.

GSoC 2014 #0 status report - Improving Allwinner SoC support

[Emilio López]

Hi,

El 10/07/14 17:39, Maxime Ripard escribi?:
>> Lately, I have also been working on the audio part, now that I have
>> a working DMA driver. After implementing cyclic DMA transfers and
>> some clock code, and armed with a Buildroot image with mpg123 and an
>> OpenBSD release track[5] in mp3 format, I've been trying to get some
>> sound out of my Cubietruck's headphone jack, but without much
>> success so far. I have verified my userspace stack and hardware by
>> running these same binaries on top of the linux-sunxi 3.4 kernel,
>> and it worked fine. I have since then been dumping relevant
>> registers with devmem and comparing them, resolving issues as I see
>> them - hopefully this will yield some audible results.
>
> What have you been working on? A new driver from scratch, tried to
> take Allwinner's code and then cleant it up, or used the recently
> published driver Jon made?

I've been working on top of Jon's codec patches. Seeing that the last 
series Jon published on his github produces some sound, I got a fresh 
copy of it today, and with some changes on DMAEngine, it's playing nicely.

As cyclic transactions are special (eg, they don't become empty) I 
rewrote the cyclic support Jon had, making it issue subsequent transfers
directly from the interrupt request, and minimizing the number of times 
this needs to be done. If we use the half done interrupt, we can get 
away with one hardware programming per two periods.

It's rather late now and I still need to clean up the code a bit, but 
I'll push a branch with these changes on my repo during the weekend.

>> Interestingly enough, Allwinner themselves do not seem to be using
>> cyclic DMA transfers on their driver[6]. I hope this is not a sign
>> of a hardware bug that's not documented.
>
> So they just implement a cyclic-like behaviour in software?

Yep, they have this code to cycle through the buffer

https://github.com/linux-sunxi/linux-sunxi/blob/sunxi-3.4/sound/soc/sunxi/sunxi-codec.c#L648

Cheers!

Emilio

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

[Chen-Yu Tsai]

Hi Emilio,

On Sun, Jul 20, 2014 at 3:41 AM, Emilio L?pez <emilio@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?

I'll grab your tree and test 24bit tomorrow. (Good thing I have 24 bit
music files.) :)

> 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

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

[Julian Calaby]

Hi Emilio,

On Sun, Jul 20, 2014 at 5:41 AM, Emilio L?pez <emilio@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.

It might be worth trying to generate some 24 bit audio samples that
only exercise one bit, then check that playing them produces output,
because it sounds to me (and Chen-Yu) that there's something in your
code that's shifting or clipping the samples.

Thanks,

-- 
Julian Calaby

Email: julian.calaby at gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

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

[Chen-Yu Tsai]

On Sun, Jul 20, 2014 at 12:18 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi Emilio,
>
> On Sun, Jul 20, 2014 at 3:41 AM, Emilio L?pez <emilio@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.

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

> 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

[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@csie.org> wrote:
> On Sun, Jul 20, 2014 at 12:18 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> Hi Emilio,
>>
>> On Sun, Jul 20, 2014 at 3:41 AM, Emilio L?pez <emilio@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

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

[Chen-Yu Tsai]

Hi,

On Tue, Jul 22, 2014 at 9:11 PM, jonsmirl at gmail.com <jonsmirl@gmail.com> wrote:
> On Tue, Jul 22, 2014 at 6:22 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> On Sun, Jul 20, 2014 at 12:18 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> Hi Emilio,
>>>
>>> On Sun, Jul 20, 2014 at 3:41 AM, Emilio L?pez <emilio@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.

Any way to tell? The audio doesn't sound choppy or anything.

>> 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.

I see. Let us know when the code is cleaned up.

> 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.

I haven't seen this.

> 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.

The common clock framework has support for this. I can't remember
the option off the top of my head, but I've used it in the GMAC clock.

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

I believe it's LINE IN actually. Anyway, I have one, and I can test it
if the code is there.

>>> 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

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

[Chris Moore]

Le 22/07/2014 12:22, Chen-Yu Tsai a ?crit :
> So the user manual says that 24 bit samples should be right justified,
> or in the most significant bytes.

I understand "right justified" to mean "in the *least* significant bits".

Cheers,
Chris

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

[Chen-Yu Tsai]

On Wed, Jul 23, 2014 at 1:15 PM, Chris Moore <moore@free.fr> wrote:
> Le 22/07/2014 12:22, Chen-Yu Tsai a ?crit :
>
>> So the user manual says that 24 bit samples should be right justified,
>> or in the most significant bytes.
>
> I understand "right justified" to mean "in the *least* significant bits".

Ah yes. Pardon me. Sticking to "most significant bits" is better. :)


ChenYu

GSoC 2014 #2 status report - Improving Allwinner SoC support

[Maxime Ripard]

Hi Emilio,

On Mon, Aug 04, 2014 at 06:25:47PM -0300, Emilio L?pez wrote:
> Hi everyone,
> 
> Here's a status update on my GSoC project for these last two weeks;
> you can find the two previous updates on the list archives[0][1]
> 
> First of all, I have started to prepare for university exams, so
> that has taken some of the time I was using to work on the project.
> I have not stopped working on this though - you will still see
> progress and receive some more of these emails :)
> 
> On the sound side, we now have normal volume 24 bit audio after
> Chen-Yu noticed it was an alignment problem and that we could get
> around it by using S32LE with 24 significant bits. I have also been
> working on rewriting the driver to use DAPM, and I can now manage
> several parts of the codec with it already. If no further obstacles
> show up, I expect to get it completed soon and in shape for a
> initial submission before the end of GSoC.

When I was working on this, this script from Arnaud Patard helped me a
lot to debug the DAPM states:
http://code.bulix.org/ps99ew-86717

> During this period I also sent some patches for the clock support we
> need for the codec and other audio blocks. I firstly did a RFC[2],
> as the PLL2 is different on the A10 revision A, and we'd need some
> sort of quirk handling for that. After settling for a DT-based
> handling, I sent a refreshed series implementing it[3], which is
> currently under review. This quirk handling is also going to be
> needed for the codec driver, as there's a couple of quirks there as
> well.
> 
> I've also sent an updated version[4] of the DMA engine driver
> addressing the comments I got on v2 and including the performance
> and cyclic improvements I mentioned on the previous report - they
> say third time's the charm, so hopefully I can get a review from the
> DMA maintainers this round :)
> 
> You can expect the next status report in about a week's time. There
> are two GSoC weeks remaining until the hard deadline, so that leaves
> time for another weekly report and a wrap-up one.

Thanks a lot for this report, I'm eagerly waiting for the followups :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20140807/d5f53811/attachment.sig>

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

[jonsmirl at gmail.com]

So a long later I think I might have stumbled onto the explanation for
this in the Freescale ASOC driver (fsl_dma.c).

/**
 * fsl_dma_hw_params: continue initializing the DMA links
 *
 * This function obtains hardware parameters about the opened stream and
 * programs the DMA controller accordingly.
 *
 * One drawback of big-endian is that when copying integers of different
 * sizes to a fixed-sized register, the address to which the integer must be
 * copied is dependent on the size of the integer.
 *
 * For example, if P is the address of a 32-bit register, and X is a 32-bit
 * integer, then X should be copied to address P.  However, if X is a 16-bit
 * integer, then it should be copied to P+2.  If X is an 8-bit register,
 * then it should be copied to P+3.
 *
 * So for playback of 8-bit samples, the DMA controller must transfer single
 * bytes from the DMA buffer to the last byte of the STX0 register, i.e.
 * offset by 3 bytes. For 16-bit samples, the offset is two bytes.
 *
 * For 24-bit samples, the offset is 1 byte.  However, the DMA controller
 * does not support 3-byte copies (the DAHTS register supports only 1, 2, 4,
 * and 8 bytes at a time).  So we do not support packed 24-bit samples.
 * 24-bit data must be padded to 32 bits.
 */

/* Due to a quirk of the SSI's STX register, the target address
* for the DMA operations depends on the sample size.  So we calculate
* that offset here.  While we're at it, also tell the DMA controller
* how much data to transfer per sample.
*/
switch (sample_bits) {
case 8:
mr |= CCSR_DMA_MR_DAHTS_1 | CCSR_DMA_MR_SAHTS_1;
ssi_sxx_phys += 3;
break;
case 16:
mr |= CCSR_DMA_MR_DAHTS_2 | CCSR_DMA_MR_SAHTS_2;
ssi_sxx_phys += 2;
break;
case 32:
mr |= CCSR_DMA_MR_DAHTS_4 | CCSR_DMA_MR_SAHTS_4;
break;
default:
/* We should never get here */
dev_err(dev, "unsupported sample size %u\n", sample_bits);
return -EINVAL;
}



On Wed, Jul 23, 2014 at 1:19 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> On Wed, Jul 23, 2014 at 1:15 PM, Chris Moore <moore@free.fr> wrote:
>> Le 22/07/2014 12:22, Chen-Yu Tsai a ?crit :
>>
>>> So the user manual says that 24 bit samples should be right justified,
>>> or in the most significant bytes.
>>
>> I understand "right justified" to mean "in the *least* significant bits".
>
> Ah yes. Pardon me. Sticking to "most significant bits" is better. :)
>
>
> ChenYu
>
> --
> 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