All of lore.kernel.org
 help / color / mirror / Atom feed
From: jonsmirl@gmail.com (jonsmirl at gmail.com)
To: linux-arm-kernel@lists.infradead.org
Subject: [linux-sunxi] GSoC 2014 #1 status report - Improving Allwinner SoC support
Date: Sat, 12 Mar 2016 08:41:07 -0500	[thread overview]
Message-ID: <CAKON4Owup+zT6YS9b24u1SO49g1yGWQOO-FriuMf+ZUOr-pWMg@mail.gmail.com> (raw)
In-Reply-To: <CAGb2v655fUaEf=fqhTAkdiDtRN9h9drsFtMiWDv79biQC-vCTw@mail.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

  reply	other threads:[~2016-03-12 13:41 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-10  3:41 GSoC 2014 #0 status report - Improving Allwinner SoC support Emilio López
2014-07-10 10:46 ` [linux-sunxi] " Hans de Goede
2014-07-10 12:32 ` jonsmirl at gmail.com
2014-07-10 12:38   ` jonsmirl at gmail.com
2014-07-10 16:13     ` jonsmirl at gmail.com
2014-07-10 16:23       ` jonsmirl at gmail.com
2014-07-10 20:39 ` Maxime Ripard
2014-07-10 22:40   ` [linux-sunxi] " jonsmirl at gmail.com
2014-07-10 22:55     ` Russell King - ARM Linux
2014-07-12  4:17   ` Emilio López
     [not found] ` <53CAC9ED.9080302@elopez.com.ar>
2014-07-20  4:18   ` [linux-sunxi] GSoC 2014 #1 " Chen-Yu Tsai
2014-07-22 10:22     ` Chen-Yu Tsai
2014-07-22 13:11       ` jonsmirl at gmail.com
2014-07-22 13:17         ` Chen-Yu Tsai
2014-07-23  5:15       ` Chris Moore
2014-07-23  5:19         ` Chen-Yu Tsai
2016-03-12 13:41           ` jonsmirl at gmail.com [this message]
2014-07-20  9:06   ` Julian Calaby
     [not found]   ` <53DFFA5B.1040006@elopez.com.ar>
2014-08-07 11:33     ` GSoC 2014 #2 " Maxime Ripard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKON4Owup+zT6YS9b24u1SO49g1yGWQOO-FriuMf+ZUOr-pWMg@mail.gmail.com \
    --to=jonsmirl@gmail.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.