From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754649AbbBGKvQ (ORCPT ); Sat, 7 Feb 2015 05:51:16 -0500 Received: from axentia.se ([87.96.186.132]:46443 "EHLO EMAIL.axentia.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752199AbbBGKvO convert rfc822-to-8bit (ORCPT ); Sat, 7 Feb 2015 05:51:14 -0500 From: Peter Rosin To: Mark Brown , Peter Rosin CC: "alsa-devel@alsa-project.org" , Bo Shen , 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/QWQ Date: Sat, 7 Feb 2015 10:51:15 +0000 Message-ID: <9f35349d2e6d47ae977e3e119c5175c6@EMAIL.axentia.se> References: <1423050745-6372-1-git-send-email-peda@lysator.liu.se> <20150206230951.GL31311@finisterre.sirena.org.uk> In-Reply-To: <20150206230951.GL31311@finisterre.sirena.org.uk> Accept-Language: en-US, sv-SE Content-Language: sv-SE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.1] 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 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 off base, and the SSC is doing this completely differently? 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