Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933543AbbBIJHW (ORCPT ); Mon, 9 Feb 2015 04:07:22 -0500 Received: from axentia.se ([87.96.186.132]:8637 "EHLO EMAIL.axentia.se" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932678AbbBIJHR convert rfc822-to-8bit (ORCPT ); Mon, 9 Feb 2015 04:07:17 -0500 From: Peter Rosin To: Bo Shen , Peter Rosin , "alsa-devel@alsa-project.org" CC: Liam Girdwood , Mark Brown , 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: AQHQRBXaaDfIYjPLzUyzv+RS0aaePJzn7d5ggAAAnYCAABJroA== Date: Mon, 9 Feb 2015 09:07:19 +0000 Message-ID: <5c8e49d8b0b3491b856eae50f4594f4f@EMAIL.axentia.se> References: <1423050745-6372-1-git-send-email-peda@lysator.liu.se> <54D824F8.9030804@atmel.com> <896ef5e9484a494e9e50cbed38919c5f@EMAIL.axentia.se> <54D871E7.40902@atmel.com> In-Reply-To: <54D871E7.40902@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 Content-Length: 2968 Lines: 69 Bo Shen wrote: > Hi Peter, > > On 02/09/2015 04:09 PM, Peter Rosin wrote: > > [Snip] > > >>> > >>> /*-------------------------------------------------------------------------*\ > >>> * DAI functions > >>> @@ -200,6 +290,7 @@ static int atmel_ssc_startup(struct > snd_pcm_substream *substream, > >>> struct atmel_ssc_info *ssc_p = &ssc_info[dai->id]; > >>> struct atmel_pcm_dma_params *dma_params; > >>> int dir, dir_mask; > >>> + int ret; > >>> > >>> pr_debug("atmel_ssc_startup: SSC_SR=0x%u\n", > >>> ssc_readl(ssc_p->ssc->regs, SR)); @@ -207,6 +298,7 @@ > static > >>> int atmel_ssc_startup(struct snd_pcm_substream *substream, > >>> /* Enable PMC peripheral clock for this SSC */ > >>> pr_debug("atmel_ssc_dai: Starting clock\n"); > >>> clk_enable(ssc_p->ssc->clk); > >>> + ssc_p->mck_rate = clk_get_rate(ssc_p->ssc->clk) * 2; > >> > >> Why the mck_rate is calculated in this form? > > > > What did you have in mind? Add another clock to the ssc node in the > > device tree? > > > > IIUC, the device tree (at least normally) has the ssc clk as the > > peripheral clock divided by 2, but the ssc specifies (when capturing > > in the CBM/CFS > > case) the rate limit as the peripheral clock divided by 3 (i.e. ssc clk / 1.5). > > Since the SSC spec expresses the rate limit in terms of the peripheral > > clock, this was what I came up with. I didn't want to require dt changes... > > You make a misunderstand for the mck for ssc peripheral. The mck here is > not the system mck, it only related with the ssc, it is the PMC output. > For example, in device tree, the ssc clock divided by 2, then the pmc output > for ssc is "system mck / 2", so the ssc mck is "system mck / 2". > If divided by 4, then the ssc mck is "system / 4" I think the reason for my misunderstanding might be that in the 3.10-at91 tree, the ssc clk is twice the rate compared to what it is in the 3.18-at91 tree. This made me assume that the ssc clk had been changed to mean the rate after the fixed divider by two that is activated as soon as the ssc clock divider (given by SSC_CMR) is activated, and that it was a simple matter of multiplying by two to get to the MCK rate. I further assumed that "Master Clock" in the "Serial Clock Ratio Considerations" section was this MCK. Maybe the mistake was to involve the peripheral clock at all? Ok, so I may have misunderstood, but in that case what does that mean in terms of finding the "Master Clock" rate that is mentioned in the "Serial Clock Ratio Considerations" section? Is it perhaps the rate of the parent clock of the given ssc clk? Or, given the above explanation, is it correct to simply multiply by two as I have done? [snip] Cheers, Peter -- 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/