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
next prev parent 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