From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759781AbbBIIRW (ORCPT ); Mon, 9 Feb 2015 03:17:22 -0500 Received: from axentia.se ([87.96.186.132]:40818 "EHLO EMAIL.axentia.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1759542AbbBIIRV convert rfc822-to-8bit (ORCPT ); Mon, 9 Feb 2015 03:17:21 -0500 From: Peter Rosin To: Bo Shen , Mark Brown , "Peter Rosin" CC: "alsa-devel@alsa-project.org" , Liam Girdwood , Jaroslav Kysela , Takashi Iwai , "linux-kernel@vger.kernel.org" , "linux-arm-kernel@lists.infradead.org" Subject: RE: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates Thread-Topic: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates Thread-Index: AQHQQrBJaDfIYjPLzUyzv+RS0aaePJzk/QWQgAKXqwCAAFbl4P//+ymAgAAUWXA= Date: Mon, 9 Feb 2015 08:17:27 +0000 Message-ID: <66d42d03e3fd43f79c782d91b3f9ee4e@EMAIL.axentia.se> References: <1423050745-6372-1-git-send-email-peda@lysator.liu.se> <20150206230951.GL31311@finisterre.sirena.org.uk> <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se> <54D8243C.6090902@atmel.com> <54D86911.2040302@atmel.com> In-Reply-To: <54D86911.2040302@atmel.com> Accept-Language: en-US, sv-SE Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [217.210.101.82] x-gfi-smtp-submission: 1 x-gfi-smtp-hellodomain: EMAIL.axentia.se x-gfi-smtp-remoteip: 192.168.2.5 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Bo Shen wrote: > Hi Peter, > > On 02/09/2015 03:35 PM, Peter Rosin wrote: > > Bo Shen wrote: > >> Hi Peter, > > > > Hi! > > > >> 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. > > > > No problem! > > > >>> off base, and the SSC is doing this completely differently? > >> > >> What you mean here? I am not sure I fully understand. > > > > The SSC spec list a maximum rate (which varies with the direction of > > various signals, ignoring that for the sake of this explanation). Lets > > assume that this maximum rate is 11MHz, derived from the peripheral > > clock which might be 66MHz. If you then try to input an 11MHz signal > > derived from some unrelated xtal you might think it should work. My > > theory was that the rate limit would be broken if the peripheral clock > > wasn't really 66MHz, but instead a few ppm lower than nominal, and the > > unrelated xtal was a few ppm higher than nominal. > > > > If this matters or not depends on how the SSC is implemented. > > This is to let the user to know the clock limitation, am I right? Yes, sort of, to prevent the user from even attempting to go too near the nominal limit. > And at the same time deal with the un-precise clock which come to SSC? > If this case, I think we should trust the clock come to SSC. Ok, I'll just kill the 500ppm thing for the next round. I'll wait a bit for the discussion in the other branch to fade out though. :-) Cheers, Peter > > There might be other reasons for not caring all that much about this > > fringe case, and just trust the nominal rates and limits. > > > >>> 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 > > Best Regards, > Bo Shen