Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932388AbbBIIAv (ORCPT ); Mon, 9 Feb 2015 03:00:51 -0500 Received: from eusmtp01.atmel.com ([212.144.249.243]:2831 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932355AbbBIIAt (ORCPT ); Mon, 9 Feb 2015 03:00:49 -0500 Message-ID: <54D86911.2040302@atmel.com> Date: Mon, 9 Feb 2015 16:00:17 +0800 From: Bo Shen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0 MIME-Version: 1.0 To: Peter Rosin , 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 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> In-Reply-To: Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [10.168.5.13] Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3533 Lines: 94 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? 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. > 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/