LPC3250 periph clock at 13MHz instead of 10.4MHz

LPC3250 periph clock at 13MHz instead of 10.4MHz

[Alexandre Belloni]

Hi,

I've been observing a mismatch between the reported periph clock
frequency and the actuall periph clock frequency on a custom board.

clk_summary gives:

 xtal                                 1        1        1    13000000          0     0  50000
    osc                               2        2        1    13000000          0     0  50000
       sys                            1        1        0    13000000          0     0  50000
          hclk_pll                    3        3        0   208000000          0     0  50000
             hclk_div_periph          1        1        0    10400000          0     0  50000
                sysclk_periph_mux       1        1        0    10400000          0     0  50000
                   pclk               4        4        0    10400000          0     0  50000
                      uart5           1        1        0    10400000          0     0  50000
                      timer0          1        1        0    10400000          0     0  50000
                      timer1          1        1        0    10400000          0     0  50000


And this seems quite right when reading the registers using devmem.

But, I observed that the input clock for UART5 seems to be 13MHz. At
9600 bauds, the calculated UnDLM:UnDLL is 68 (which would give
10400000/(16*68) = 9558 bauds) but at the oscilloscope, I see that the
UARt is running close to 12kHz. Forcing the frequency to 13MHz, gives a
divisor of 85 and solves the issue.

Note that this issue will not be seen right away at 115200 bauds because
the divisor is then quite close (6 for 10.4MHz and 7 for 13MHz).

Similarily using an i2c RTC, I can see that the timer is quite off:

# hwclock; sleep 10; hwclock
Tue Feb 12 16:53:09 2019  0.000000 seconds
Tue Feb 12 16:53:17 2019  0.000000 seconds

This is what is expected if the 13MHz input clock is mistaken as 10.4MHz
as 10*10.4/13 = 8s.

This leads me to think that pclk is actually running at 13MHz.

PWR_CTRL is set to 0x16 so the pclk parent should be hclk_div and not
sysclk.

Am I missing something?

-- 
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

Re: LPC3250 periph clock at 13MHz instead of 10.4MHz

[Vladimir Zapolskiy]

Hi Alexandre,

On 02/12/2019 06:52 PM, Alexandre Belloni wrote:
> Hi,
> 
> I've been observing a mismatch between the reported periph clock
> frequency and the actuall periph clock frequency on a custom board.
> 
> clk_summary gives:
> 
>  xtal                                 1        1        1    13000000          0     0  50000
>     osc                               2        2        1    13000000          0     0  50000
>        sys                            1        1        0    13000000          0     0  50000
>           hclk_pll                    3        3        0   208000000          0     0  50000
>              hclk_div_periph          1        1        0    10400000          0     0  50000
>                 sysclk_periph_mux       1        1        0    10400000          0     0  50000
>                    pclk               4        4        0    10400000          0     0  50000
>                       uart5           1        1        0    10400000          0     0  50000
>                       timer0          1        1        0    10400000          0     0  50000
>                       timer1          1        1        0    10400000          0     0  50000
> 
> 
> And this seems quite right when reading the registers using devmem.
> 
> But, I observed that the input clock for UART5 seems to be 13MHz. At
> 9600 bauds, the calculated UnDLM:UnDLL is 68 (which would give
> 10400000/(16*68) = 9558 bauds) but at the oscilloscope, I see that the
> UARt is running close to 12kHz. Forcing the frequency to 13MHz, gives a
> divisor of 85 and solves the issue.
> 
> Note that this issue will not be seen right away at 115200 bauds because
> the divisor is then quite close (6 for 10.4MHz and 7 for 13MHz).
> 
> Similarily using an i2c RTC, I can see that the timer is quite off:
> 
> # hwclock; sleep 10; hwclock
> Tue Feb 12 16:53:09 2019  0.000000 seconds
> Tue Feb 12 16:53:17 2019  0.000000 seconds
> 
> This is what is expected if the 13MHz input clock is mistaken as 10.4MHz
> as 10*10.4/13 = 8s.
> 
> This leads me to think that pclk is actually running at 13MHz.
> 
> PWR_CTRL is set to 0x16 so the pclk parent should be hclk_div and not
> sysclk.
> 
> 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.

Thank you for report.

--
Best wishes,
Vladimir

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: LPC3250 periph clock at 13MHz instead of 10.4MHz

[Alexandre Belloni]

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.


-- 
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

Re: LPC3250 periph clock at 13MHz instead of 10.4MHz

[Alexandre Belloni]

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 */


-- 
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

Re: LPC3250 periph clock at 13MHz instead of 10.4MHz

[Alexandre Belloni]

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