Hi Geert,
On Tuesday, January 24, 2017, Geert Uytterhoeven wrote:
> > Therefore, before I start firing off patches to remove runtime PM for
> RZ/A, does anyone have an opinion one way of the other????
>
> Please have a look at Section 55.3.5 ("Module Standby Function"), which I
> had never read myself, apparently...
>
> Seem like there is some kind of status register, the STBCR register
> itself:
>
> Canceling Module Standby Function:
> 1. Clear the MSTP bit to 0.
> 2. After that, dummy-read the same register.
>
> Does it help if you add the dummy read when enabling the clock?
Already tried that. And put a barrier() call just to make sure
everything was done.
It seems that might be enough for the RSPI, but the RIIC still has issues.
>From what I can tell, that makes the register space readable...but the IP block
is not fully functional unless you delay a little.
> However, that section reveals another complicating factor for some
> modules:
> if the module has a bit in a STBREQn/STBACKn register, a module standy
> request must be sent to the module before stopping the module clock.
>
> Looks like you're gonna need a whole new RZ/A1-specific clock driver to
> handle all those details...
There are only a couple IP blocks called out in the STBREQn/STBACKn registers,
and I think they are not really crucial for runtime pm (Ethenret, LCD,
Coresight, etc..).
So in my opinion it's not worth a new driver just yet.
But, I think I'd like to disable runtime pm for RZ/A1 in the drivers for now
Because 'functional' is better than 'lower-power-but-broken'
Chris
