From: Peter Ujfalusi <peter.ujfalusi@ti.com>
To: Jarkko Nikula <jarkko.nikula@bitmer.com>
Cc: liam.r.girdwood@linux.intel.com, alsa-devel@alsa-project.org,
linux-omap@vger.kernel.org, broonie@kernel.org,
Jyri Sarha <jsarha@ti.com>
Subject: Re: [PATCH] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size
Date: Tue, 3 Mar 2015 14:45:28 +0200 [thread overview]
Message-ID: <54F5ACE8.2050702@ti.com> (raw)
In-Reply-To: <20150303122208.GA28158@bitmer.com>
On 03/03/2015 02:22 PM, Jarkko Nikula wrote:
> On Tue, Mar 03, 2015 at 01:41:21PM +0200, Peter Ujfalusi wrote:
>> On 03/03/2015 01:28 PM, Jyri Sarha wrote:
>>> sDMA support only transfer elements with 1, 2, and 4 byte physical
>>> size. Initialize the pcm driver accordingly.
>>
>> Acked-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
>>
>>>
>>> Signed-off-by: Jyri Sarha <jsarha@ti.com>
>>> ---
>>> sound/soc/omap/omap-pcm.c | 21 ++++++++++++++++++++-
>>> 1 file changed, 20 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/sound/soc/omap/omap-pcm.c b/sound/soc/omap/omap-pcm.c
>>> index f4b05bc..e49ee23 100644
>>> --- a/sound/soc/omap/omap-pcm.c
>>> +++ b/sound/soc/omap/omap-pcm.c
>>> @@ -39,7 +39,7 @@
>>> #define pcm_omap1510() 0
>>> #endif
>>>
>>> -static const struct snd_pcm_hardware omap_pcm_hardware = {
>>> +static struct snd_pcm_hardware omap_pcm_hardware = {
>>> .info = SNDRV_PCM_INFO_MMAP |
>>> SNDRV_PCM_INFO_MMAP_VALID |
>>> SNDRV_PCM_INFO_INTERLEAVED |
>>> @@ -53,6 +53,24 @@ static const struct snd_pcm_hardware omap_pcm_hardware = {
>>> .buffer_bytes_max = 128 * 1024,
>>> };
>>>
>>> +/* sDMA supports only 1, 2, and 4 byte transfer elements. */
>>> +static void omap_pcm_limit_supported_formats(void)
>>> +{
>>> + int i;
>>> +
>>> + for (i = 0; i < SNDRV_PCM_FORMAT_LAST; i++) {
>>> + switch (snd_pcm_format_physical_width(i)) {
>>> + case 8:
>>> + case 16:
>>> + case 32:
>>> + omap_pcm_hardware.formats |= (1LL << i);
>>> + break;
>>> + default:
>>> + break;
>>> + }
>>> + }
>>> +}
>>> +
>
> I wonder why these are set in a loop instead of setting formats statically
omap-pcm as such can work with any formats which has 1, 2 or 4 bytes layout in
memory (and not only S16_LE, S32_LE).
sDMA can not handle 3byte words so we can not handle those with omap-pcm. In
contrast eDMA for example can handle 1, 2, 3 and 4 w/o issue.
> and why this is needed after commit 60e21d287344 ("ASoC: omap: Don't set
> unused struct snd_pcm_hardware fields")?
Hrm, interesting. We also have:
2d38df128321 (ASoC: generic-dmaengine-pcm: Prepare formats mask for valid
physical sample sizes)
Which does the same thing for the generic dmaengine pcm users.
Actually the information from the omap_pcm_hardware is copied to runtime.hw
via snd_soc_set_runtime_hwparams() call, so it is not ignored.
We need this masking to be done here since the omap-pcm is still mostly custom
code and do not plug easily to the generic code (ie, not at all).
--
Péter
next prev parent reply other threads:[~2015-03-03 12:45 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-03 11:28 [PATCH] ASoC: omap-pcm: Allow only formats with 1, 2, and 4 byte physical size Jyri Sarha
2015-03-03 11:41 ` Peter Ujfalusi
2015-03-03 12:22 ` Jarkko Nikula
2015-03-03 12:45 ` Peter Ujfalusi [this message]
2015-03-03 12:51 ` Jyri Sarha
2015-03-04 17:29 ` Mark Brown
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=54F5ACE8.2050702@ti.com \
--to=peter.ujfalusi@ti.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=jarkko.nikula@bitmer.com \
--cc=jsarha@ti.com \
--cc=liam.r.girdwood@linux.intel.com \
--cc=linux-omap@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).