Problem with the clock framework

Problem with the clock framework

[Matthias Klein]

  Hello,

I have a problem with the linux clock framework on an i.MX537 with an 
3.4.47-rt62 kernel (with freescale patches).

I writing a special driver for the ECSPI interface with support for 
automatic transmissions with the RDY signal.

When the board comes up, the clocks of the ECSPI interface are disabled. 
I tried to use the linux clock framework
with clk_get() and clk_enable() to enable these clocks. Basically it 
works, but a lot of transmissions get discontinuous:
after the first 32 bit the SPI clock stops, with a low chip select line, 
and after some milliseconds the remaining bits are transmitted.

It I use the following code to enable these clocks instead of 
clock_enable() everything works:

  volatile unsigned int *v_adr = 0;
  v_adr = ioremap_nocache(0x53FD4078, 4); // CCM Clock Gating Register 4 
(CCM_CCGR4)
  *v_adr |= 0xF << 18; // Enable CG9 + CG10
  iounmap(v_adr);

For me it looks like that some type of power managment disables the 
ECSPI clock periodically.

Is there a default behavior for power managment and these clocks, or 
does it depend on the board specific implementation ?
Can you give me some tips for analyze the problem ?


Best regards,

Matthias

Re: Problem with the clock framework

[Sebastian Andrzej Siewior]

* Matthias Klein | 2013-07-11 05:51:03 [+0000]:

> Hello,
Hi Mathias,

>disabled. I tried to use the linux clock framework
>with clk_get() and clk_enable() to enable these clocks. Basically it
>works, but a lot of transmissions get discontinuous:
>after the first 32 bit the SPI clock stops, with a low chip select
>line, and after some milliseconds the remaining bits are transmitted.

Is this -RT releated or do you see the same kind of problem without -RT?
If so you might want to try the arm/spi mailing list.

>It I use the following code to enable these clocks instead of
>clock_enable() everything works:
>
> volatile unsigned int *v_adr = 0;
> v_adr = ioremap_nocache(0x53FD4078, 4); // CCM Clock Gating Register
>4 (CCM_CCGR4)
> *v_adr |= 0xF << 18; // Enable CG9 + CG10
> iounmap(v_adr);
>
>For me it looks like that some type of power managment disables the
>ECSPI clock periodically.
>
>Is there a default behavior for power managment and these clocks, or
>does it depend on the board specific implementation ?

If the driver is using runtime_pm then it might "put" the device which
in turn might disable clocks. This often does not happen right away but
after a while to avoid frequent enable/disable of the device.

>Can you give me some tips for analyze the problem ?

Enable debugging under kernel hacking and maybe some locking / sleeping
while atomic message pop up.

>Best regards,
>
>Matthias

Sebastian