From: Alexandre Belloni <alexandre.belloni@bootlin.com>
To: Vladimir Zapolskiy <vz@mleia.com>
Cc: Gregory CLEMENT <gregory.clement@bootlin.com>,
linux-arm-kernel@lists.infradead.org
Subject: Re: LPC3250 periph clock at 13MHz instead of 10.4MHz
Date: Thu, 11 Apr 2019 11:15:21 +0200 [thread overview]
Message-ID: <20190411091521.GJ3578@piout.net> (raw)
In-Reply-To: <20190410141805.GE3578@piout.net>
On 10/04/2019 16:18:05+0200, Alexandre Belloni wrote:
> On 10/04/2019 15:44:43+0200, Alexandre Belloni wrote:
> > Hi Vladimir,
> >
> > On 13/02/2019 19:21:44+0200, Vladimir Zapolskiy wrote:
> > > > Am I missing something?
> > > >
> > >
> > > I think I encountered quite a similar issue previously, but under another
> > > circumstances, when I begin to modify HCLK PLL clock rate, can you check
> > > my comment at https://lore.kernel.org/linux-clk/56D685F6.5060400@mleia.com/
> > > and verify if it's about the same problem?
> > >
> > > Since the problem hits you also, I plan to spend some time on this weekend
> > > to capture more details, fortunately there is a known workaround to pin
> > > UART input clock rate to 13MHz, it might be desired to carve it in the code.
> > >
> >
> > I'm pretty sure this is the same issue and that it doesn't only affect
> > the UARTs but also timers.
> >
> > The 2.6.27.8 kernel code would indicated that the timers are only driven
> > by sysclk, that is either 13MHz from the oscillator or 13.008896 from
> > PLL397. I'm wondering how many other peripherals are affected.
> >
>
> You'll note that this is also true for the watchdog, the driver has:
>
> // NOTE - the driver only uses this value if it can't get the clock rate from the clk_ drivers
> #define WDOG_COUNTER_RATE 13000000 /*the counter clock is 13 MHz fixed */
>
Ok, I went further. We have test points for tst_clk1 and tst_clk2 so
I've put periph_clk on test_clk2. It is definitively running at 13MHz. I
only have access to a 100MHz oscilloscope so measuring hclk is not great
but it seems to be around 125MHz (I would guess 130MHz then) So I had a
look at SCK on an i2c bus that is supposed to be running at 100kHz. It
is actually at 120kHz.
My conclusion is that switching from 260MHz to 208MHz is not working as
expected, I don't know why yet.
--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
prev parent reply other threads:[~2019-04-11 9:15 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-12 16:52 LPC3250 periph clock at 13MHz instead of 10.4MHz Alexandre Belloni
2019-02-13 17:21 ` Vladimir Zapolskiy
2019-04-10 13:44 ` Alexandre Belloni
2019-04-10 14:18 ` Alexandre Belloni
2019-04-11 9:15 ` Alexandre Belloni [this message]
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=20190411091521.GJ3578@piout.net \
--to=alexandre.belloni@bootlin.com \
--cc=gregory.clement@bootlin.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=vz@mleia.com \
/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;
as well as URLs for NNTP newsgroup(s).