Stephen Boyd <[email protected]> writes: > On 08/03/2015 11:22 PM, Robert Jarzmik wrote: >> Stephen Boyd <[email protected]> writes: >> >>> On 08/03/2015 12:58 PM, Robert Jarzmik wrote: >>>> Clocks 0 to 31 are on CKENA, and not CKENB. The clock register names >>>> 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 <[email protected]> >>>> --- >>> Did you want a fixes tag to send this back to stable? >> Ah yes, good point, v2 on its way. >> >> Stephen and Mike, do you think this can still get in -rc6 ? >> > > It's not a new regression for v4.2 so we'll leave it to v4.3. I'll apply it to > clk-next. Euh how so, not "new" ?
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 ? -- Robert [1] Commit triggering the error commit 7448adca9361 Merge: e3abcb25d2ae 64227114c676 Author: Arnd Bergmann <[email protected]> Date: Fri May 15 17:40:15 2015 +0200 Merge tag 'pxa-for-4.2' of https://github.com/rjarzmik/linux into next/soc Merge "pxa changes for v4.2 cycle" from Robert Jarzmik: The main and only feature is the conversion of all pxa variants to clock framework. This encompasses pxa25x, pxa27x and pxa3xx, for all boards. This should be a disruptive cycle in the normally quiet pxa history, as the change can break any platform, and the test were performed on only 4 boards (lubbock, zylonite, mioa701, cm-x300). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
