Linux clock framework development
 help / color / mirror / Atom feed
From: Stefan Wahren <stefan.wahren@i2se.com>
To: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Michael Turquette" <mturquette@baylibre.com>,
	"Stephen Boyd" <sboyd@codeaurora.org>,
	"Fabio Estevam" <fabio.estevam@nxp.com>,
	"Shawn Guo" <shawnguo@kernel.org>,
	"Krummsdorf Michael" <Michael.Krummsdorf@tq-group.com>
Cc: linux-clk@vger.kernel.org, kernel@pengutronix.de
Subject: Re: [PATCH] clk: mxs: ensure that i.MX28's ref_io clks are not operated too fast
Date: Thu, 26 Jul 2018 16:50:07 +0200	[thread overview]
Message-ID: <10f5e651-caf4-3fe0-87c0-fe42ccdc6349@i2se.com> (raw)
In-Reply-To: <20180726143232.ds22exgxiv6zlsn5@pengutronix.de>

Hi Uwe,

no new insights from my side.

Am 26.07.2018 um 16:32 schrieb Uwe Kleine-König:
> On Wed, May 03, 2017 at 08:56:25PM +0200, Uwe Kleine-König wrote:
>> Since commits 7d81397cd93d ("clk: mxs: add clock support for imx28") and
>> 64e2bc413047 ("clk: mxs: imx28: decrease the frequency of ref_io1 for
>> SSP2 and SSP3") the frequencies for ref_io0 and ref_io1 are initialized
>> to 288 MHz because the initial frequency "seems too high to be ssp clock
>> source directly". However this isn't enough to ensure that the frequency
>> isn't increased later again. In fact this happens on my machine as the
>> mxs-spi driver calls clk_set_rate(ssp->clk, 160000000) with ssp being
>> ssp2 which is resolved to
>>
>> 	ref_io1.rate = 320 MHz
>> 	ssp2_sel.parent = ref_io1
>> 	ssp2_div.divider = 2
>>
>> . The observed effect is that reading MISO reliably fails: Instead of
>> the least significant bit the second least significant bit is reported
>> twice. This is probably related to the reports
>>
>> 	https://community.nxp.com/thread/290209
>> 	https://community.nxp.com/thread/310434
>> 	https://community.nxp.com/thread/385546
>>
>> So additionally to initializing ref_io0 and ref_io1 to 288 MHz ensure
>> that their frequency is never set to something bigger later on. This is
>> done by adding a parameter min_frac to clk-ref and use that instead of
>> the hard coded 18 to limit the valid values for FRAC. For all ref clocks
>> but ref_io0 and ref_io1 18 is used and so there is no functional change
>> for those.
>>
>> Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
> Back in 2017 this patch made the issue disappear on a customer's machine
> (using TQ's TQMa28). Now the problem is back on a variant of the machine
> (using TQMa28L). Back then Stefan had the problem with my patch on a
> Duckbill, too.
>

I only want to note that we are using this ugly hack for Duckbill to 
avoid this issue:

https://github.com/I2SE/linux/commit/e457d5e0309c07e30e8dd8b17c32f7b3cbdd9547

Best regards
Stefan

  reply	other threads:[~2018-07-26 14:50 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-03 18:56 [PATCH] clk: mxs: ensure that i.MX28's ref_io clks are not operated too fast Uwe Kleine-König
2017-05-03 19:53 ` Fabio Estevam
2017-05-04 12:25   ` Stefan Wahren
2017-05-05  7:25     ` Uwe Kleine-König
2017-05-05  7:49       ` Stefan Wahren
2017-05-05 15:49         ` Stefan Wahren
2017-05-05 20:10           ` Uwe Kleine-König
2017-05-07 11:51             ` Stefan Wahren
2017-05-08  8:24               ` Uwe Kleine-König
2017-05-10 13:39                 ` Stefan Wahren
2017-05-10 14:13                   ` Uwe Kleine-König
2017-05-10 20:26                 ` Uwe Kleine-König
2017-05-08  9:53             ` AW: " Krummsdorf Michael
2017-05-08 10:14               ` Uwe Kleine-König
2017-05-10 18:05             ` Uwe Kleine-König
2017-05-26 12:06   ` Uwe Kleine-König
2017-05-29 21:06     ` Stefan Wahren
2017-05-29 21:21 ` Fabio Estevam
2017-05-30  6:54   ` Uwe Kleine-König
2017-05-30  8:04     ` Stefan Wahren
2017-05-30 11:13     ` Fabio Estevam
2018-07-26 14:32 ` Uwe Kleine-König
2018-07-26 14:50   ` Stefan Wahren [this message]
2018-07-26 15:02     ` Fabio Estevam
2018-08-01  9:31       ` Uwe Kleine-König
2018-08-02  8:33         ` Uwe Kleine-König
2018-08-03  9:09           ` Uwe Kleine-König
2018-08-08  8:23         ` Stefan Wahren
2018-08-08  9:09           ` Uwe Kleine-König
2018-07-26 15:04   ` Fabio Estevam
2018-07-26 15:18     ` Fabio Estevam
2019-03-22 21:51 ` Uwe Kleine-König
2019-05-02 12:37   ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=10f5e651-caf4-3fe0-87c0-fe42ccdc6349@i2se.com \
    --to=stefan.wahren@i2se.com \
    --cc=Michael.Krummsdorf@tq-group.com \
    --cc=fabio.estevam@nxp.com \
    --cc=kernel@pengutronix.de \
    --cc=linux-clk@vger.kernel.org \
    --cc=mturquette@baylibre.com \
    --cc=sboyd@codeaurora.org \
    --cc=shawnguo@kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox