From: Bo Shen <voice.shen@atmel.com>
To: Peter Rosin <peda@axentia.se>, Mark Brown <broonie@kernel.org>,
Peter Rosin <peda@lysator.liu.se>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Takashi Iwai <tiwai@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Liam Girdwood <lgirdwood@gmail.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Date: Mon, 9 Feb 2015 11:06:36 +0800 [thread overview]
Message-ID: <54D8243C.6090902@atmel.com> (raw)
In-Reply-To: <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se>
Hi Peter,
On 02/07/2015 06:51 PM, Peter Rosin wrote:
> Mark Brown wrote:
>> On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote:
>>
>>> One thing remains a bit unclear, and that is the 500ppm deduction. Is
>>> that really warranted? The number was just pulled out of my hat...
>>
>> I don't really get what this is supposed to be protecting against.
>>
>>> + case SND_SOC_DAIFMT_CBM_CFS:
>>> + case SND_SOC_DAIFMT_CBM_CFM:
>>> + t.min = 8000;
>>> + t.max = ssc_p->mck_rate / mck_div / frame_size;
>>> + /* Take away 500ppm, just to be on the safe side. */
>>> + t.max -= t.max / 2000;
>>> + t.openmin = t.openmax = 0;
>>> + t.integer = 0;
>>> + ret = snd_interval_refine(i, &t);
>>
>> As I understand it this is a straight divider rather than something that's doing
>> dithering or anything else more fancy. Given that it seems as well just to
>> trust the clock rate we've got - we don't do any error tracking with the clock
>> API (perhaps we should) and for many applications some degree of
>> divergence from the nominal rate is not
>> *too* bad for audio systems (for application specific values of "some"
>> and "too" of course). If it is just dividers I'm not sure the situation is really
>> improved materially by knocking off the top frequency.
>>
>> If we are doing something more fancy than divididing my analysis is off base
>> of course.
>
> I'm thinking that the SSC samples the selected BCK pin using the (possibly
> divided) peripheral clock. Getting too near the theoretical rate limit would
> be bad, if these two independent clocks drift the wrong way. At least that
> is my take on it, but I don't know the internal workings of the SSC, so...
>
> I was hoping that someone from Atmel could chime in? Maybe I'm totally
Sorry for late response.
> off base, and the SSC is doing this completely differently?
What you mean here? I am not sure I fully understand.
> In our application, we're not near the limit. Therefore, it really doesn't
> matter much to us.
>
> Should I resend w/o the 500ppm deduction?
>
> Cheers,
> Peter
>
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: voice.shen@atmel.com (Bo Shen)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Date: Mon, 9 Feb 2015 11:06:36 +0800 [thread overview]
Message-ID: <54D8243C.6090902@atmel.com> (raw)
In-Reply-To: <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se>
Hi Peter,
On 02/07/2015 06:51 PM, Peter Rosin wrote:
> Mark Brown wrote:
>> On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote:
>>
>>> One thing remains a bit unclear, and that is the 500ppm deduction. Is
>>> that really warranted? The number was just pulled out of my hat...
>>
>> I don't really get what this is supposed to be protecting against.
>>
>>> + case SND_SOC_DAIFMT_CBM_CFS:
>>> + case SND_SOC_DAIFMT_CBM_CFM:
>>> + t.min = 8000;
>>> + t.max = ssc_p->mck_rate / mck_div / frame_size;
>>> + /* Take away 500ppm, just to be on the safe side. */
>>> + t.max -= t.max / 2000;
>>> + t.openmin = t.openmax = 0;
>>> + t.integer = 0;
>>> + ret = snd_interval_refine(i, &t);
>>
>> As I understand it this is a straight divider rather than something that's doing
>> dithering or anything else more fancy. Given that it seems as well just to
>> trust the clock rate we've got - we don't do any error tracking with the clock
>> API (perhaps we should) and for many applications some degree of
>> divergence from the nominal rate is not
>> *too* bad for audio systems (for application specific values of "some"
>> and "too" of course). If it is just dividers I'm not sure the situation is really
>> improved materially by knocking off the top frequency.
>>
>> If we are doing something more fancy than divididing my analysis is off base
>> of course.
>
> I'm thinking that the SSC samples the selected BCK pin using the (possibly
> divided) peripheral clock. Getting too near the theoretical rate limit would
> be bad, if these two independent clocks drift the wrong way. At least that
> is my take on it, but I don't know the internal workings of the SSC, so...
>
> I was hoping that someone from Atmel could chime in? Maybe I'm totally
Sorry for late response.
> off base, and the SSC is doing this completely differently?
What you mean here? I am not sure I fully understand.
> In our application, we're not near the limit. Therefore, it really doesn't
> matter much to us.
>
> Should I resend w/o the 500ppm deduction?
>
> Cheers,
> Peter
>
Best Regards,
Bo Shen
WARNING: multiple messages have this Message-ID (diff)
From: Bo Shen <voice.shen@atmel.com>
To: Peter Rosin <peda@axentia.se>, Mark Brown <broonie@kernel.org>,
"Peter Rosin" <peda@lysator.liu.se>
Cc: "alsa-devel@alsa-project.org" <alsa-devel@alsa-project.org>,
Liam Girdwood <lgirdwood@gmail.com>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.de>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates
Date: Mon, 9 Feb 2015 11:06:36 +0800 [thread overview]
Message-ID: <54D8243C.6090902@atmel.com> (raw)
In-Reply-To: <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se>
Hi Peter,
On 02/07/2015 06:51 PM, Peter Rosin wrote:
> Mark Brown wrote:
>> On Wed, Feb 04, 2015 at 12:52:25PM +0100, Peter Rosin wrote:
>>
>>> One thing remains a bit unclear, and that is the 500ppm deduction. Is
>>> that really warranted? The number was just pulled out of my hat...
>>
>> I don't really get what this is supposed to be protecting against.
>>
>>> + case SND_SOC_DAIFMT_CBM_CFS:
>>> + case SND_SOC_DAIFMT_CBM_CFM:
>>> + t.min = 8000;
>>> + t.max = ssc_p->mck_rate / mck_div / frame_size;
>>> + /* Take away 500ppm, just to be on the safe side. */
>>> + t.max -= t.max / 2000;
>>> + t.openmin = t.openmax = 0;
>>> + t.integer = 0;
>>> + ret = snd_interval_refine(i, &t);
>>
>> As I understand it this is a straight divider rather than something that's doing
>> dithering or anything else more fancy. Given that it seems as well just to
>> trust the clock rate we've got - we don't do any error tracking with the clock
>> API (perhaps we should) and for many applications some degree of
>> divergence from the nominal rate is not
>> *too* bad for audio systems (for application specific values of "some"
>> and "too" of course). If it is just dividers I'm not sure the situation is really
>> improved materially by knocking off the top frequency.
>>
>> If we are doing something more fancy than divididing my analysis is off base
>> of course.
>
> I'm thinking that the SSC samples the selected BCK pin using the (possibly
> divided) peripheral clock. Getting too near the theoretical rate limit would
> be bad, if these two independent clocks drift the wrong way. At least that
> is my take on it, but I don't know the internal workings of the SSC, so...
>
> I was hoping that someone from Atmel could chime in? Maybe I'm totally
Sorry for late response.
> off base, and the SSC is doing this completely differently?
What you mean here? I am not sure I fully understand.
> In our application, we're not near the limit. Therefore, it really doesn't
> matter much to us.
>
> Should I resend w/o the 500ppm deduction?
>
> Cheers,
> Peter
>
Best Regards,
Bo Shen
next prev parent reply other threads:[~2015-02-09 3:07 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-02-04 11:52 [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates Peter Rosin
2015-02-04 11:52 ` Peter Rosin
2015-02-06 23:09 ` Mark Brown
2015-02-06 23:09 ` Mark Brown
2015-02-07 10:51 ` Peter Rosin
2015-02-07 10:51 ` Peter Rosin
2015-02-09 3:06 ` Bo Shen [this message]
2015-02-09 3:06 ` Bo Shen
2015-02-09 3:06 ` Bo Shen
2015-02-09 7:35 ` Peter Rosin
2015-02-09 7:35 ` Peter Rosin
2015-02-09 8:00 ` Bo Shen
2015-02-09 8:00 ` Bo Shen
2015-02-09 8:17 ` Peter Rosin
2015-02-09 8:17 ` Peter Rosin
2015-02-09 3:09 ` Bo Shen
2015-02-09 3:09 ` Bo Shen
2015-02-09 3:09 ` Bo Shen
2015-02-09 8:09 ` Peter Rosin
2015-02-09 8:09 ` Peter Rosin
2015-02-09 8:37 ` Bo Shen
2015-02-09 8:37 ` Bo Shen
2015-02-09 8:37 ` Bo Shen
2015-02-09 9:07 ` Peter Rosin
2015-02-09 9:07 ` Peter Rosin
2015-02-09 9:07 ` Peter Rosin
2015-02-09 9:41 ` Bo Shen
2015-02-09 9:41 ` Bo Shen
2015-02-09 10:25 ` Peter Rosin
2015-02-09 10:25 ` Peter Rosin
2015-02-09 10:37 ` Bo Shen
2015-02-09 10:37 ` Bo Shen
2015-02-09 14:50 ` Peter Rosin
2015-02-09 14:50 ` Peter Rosin
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=54D8243C.6090902@atmel.com \
--to=voice.shen@atmel.com \
--cc=alsa-devel@alsa-project.org \
--cc=broonie@kernel.org \
--cc=lgirdwood@gmail.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=peda@axentia.se \
--cc=peda@lysator.liu.se \
--cc=tiwai@suse.de \
/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.