From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759212AbbBIDHM (ORCPT ); Sun, 8 Feb 2015 22:07:12 -0500 Received: from eusmtp01.atmel.com ([212.144.249.242]:18490 "EHLO eusmtp01.atmel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753236AbbBIDHK (ORCPT ); Sun, 8 Feb 2015 22:07:10 -0500 Message-ID: <54D8243C.6090902@atmel.com> Date: Mon, 9 Feb 2015 11:06:36 +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> In-Reply-To: <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se> 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 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