Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes:
On 08/03/2015 11:22 PM, Robert Jarzmik wrote:Euh how so, not "new" ?
Stephen Boyd <sboyd@xxxxxxxxxxxxxx> writes:It's not a new regression for v4.2 so we'll leave it to v4.3. I'll apply it to
On 08/03/2015 12:58 PM, Robert Jarzmik wrote:Ah yes, good point, v2 on its way.
Clocks 0 to 31 are on CKENA, and not CKENB. The clock register namesDid you want a fixes tag to send this back to stable?
were inadequately inverted. As a consequence, all clock operations were
happening on CKENB, because almost all but 2 clocks are on CKENA.
As the clocks were activated by the bootloader in the former tests, it
escaped the testing that the wrong clock gate was manipulated. The error
was revealed by changing the pxa3xx-and driver to a module, where tupon
unloading the wrong clock was disabled in CKENB.
Signed-off-by: Robert Jarzmik <robert.jarzmik@xxxxxxx>
---
Stephen and Mike, do you think this can still get in -rc6 ?
clk-next.
The clock switch for pxa architecture happens just now, on v4.2, see [1]. So the
regression wasn't here on v4.1, but is introduced in v4.2
I know I'm terribly late, but isn't it still possible to have it in v4.2 ?