Message-ID: <c4a88896e7914c0ab1a06271878152a8@EMAIL.axentia.se>
Date:	Mon, 9 Feb 2015 14:50:43 +0000
From:	Peter Rosin <peda@...ntia.se>
To:	Bo Shen <voice.shen@...el.com>, Peter Rosin <peda@...ator.liu.se>,
	"alsa-devel@...a-project.org" <alsa-devel@...a-project.org>
CC:	Liam Girdwood <lgirdwood@...il.com>,
	Mark Brown <broonie@...nel.org>,
	Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>
Subject: RE: [PATCH v2] ASoC: atmel_ssc_dai: Allow more rates

Bo Shen write:
> Hi Peter,

Hi!

[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
> >>
> >> I think maybe you didn't use the latest linux-3.10-at91 code. In that
> >> code, we also divided by 2 in device tree.
> >
> > That's a rather confusing statement. The clock tree isn't even managed
> > by the device tree in linux-3.10-at91. Sure, there's the 12MHz system
> > master clock in sama5d3.dtsi, but that's about it. The rest of the
> > clocks are in arch/arm/mach-at91/sama5d3.c. And the part about
> > ssc0/ssc1 hasn't been updated since it was added in 3.9. What am I missing?
> 
> I am not sure what the kernel you are talking about now.
> 
> In linux-3.10-at91 branch on github.com/linux4sam/linux-at91. In the
> <arch/arm/mach-at91/sama5d3.c>
> 
> --->8---
> static struct clk ssc0_clk = {
>          .name           = "ssc0_clk",
>          .pid            = SAMA5D3_ID_SSC0,
>          .type           = CLK_TYPE_PERIPHERAL,
>          .div            = AT91_PMC_PCR_DIV2,
> };
> static struct clk ssc1_clk = {
>          .name           = "ssc1_clk",
>          .pid            = SAMA5D3_ID_SSC1,
>          .type           = CLK_TYPE_PERIPHERAL,
>          .div            = AT91_PMC_PCR_DIV2,
> };
> ---8<---

That's the same code I'm looking at. This has always worked as
expected for me in the linux-3.10-at91 kernel. However, in the
linux-3.18-at91 kernel, I definitely recall getting half the rate
when querying the ssc0 clock. I thought "the 3.18 way" was
the future, and adjusted. However, I don't get that difference
now, and I can't really explain what has changed. Strange.
Anyway, thanks for setting me straight!

> That means, the clock output from PMC is "system clock / 2" which will be fed
> to ssc (here we call it SSC peripheral clock = "system clock / 2").
> 
> >>> 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?
> >>
> >> The "Master Clock" actually is the same as "Peripheral clock".
> >>
> >> Thanks for your information, I will send this to our datasheet team
> >> to update this part.
> >
> > You are still not saying how to get to the "Master Clock" rate (i.e.
> > the "Master Clock" that is mentioned in the "Serial Clock Ratio
> Considerations"
> > section. You are only implying that multiplying the ssc clock rate
> > with 2 is wrong for some reason.
> 
> I mean in that section you mentioned. The "Master Clock" is the same as
> "Peripheral Clock". So, you get the SSC peripheral clock is what the clock
> ("Master Clock") you try to get ( clk_get_rate(ssc_p->ssc->clk)).
> 

Yes, I see now. I'll resend with the *2 (and the 500ppm discussed in the
other thread) removed.

> > Are you saying that the ssc clock is supposed to be this "Master Clock"?
> >
> > Cheers,
> > Peter
> >
> 
> Best Regards,
> Bo Shen
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists