[PATCH] clk: pxa: pxa3xx: fix CKEN register access

[PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Robert Jarzmik]

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 <robert.jarzmik@free.fr>
---
 drivers/clk/pxa/clk-pxa3xx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/clk/pxa/clk-pxa3xx.c b/drivers/clk/pxa/clk-pxa3xx.c
index c677b9ab5367..4af4eed5f89f 100644
--- a/drivers/clk/pxa/clk-pxa3xx.c
+++ b/drivers/clk/pxa/clk-pxa3xx.c
@@ -126,7 +126,7 @@ PARENTS(pxa3xx_ac97_bus) = { "ring_osc_60mhz", "ac97" };
 PARENTS(pxa3xx_sbus) = { "ring_osc_60mhz", "system_bus" };
 PARENTS(pxa3xx_smemcbus) = { "ring_osc_60mhz", "smemc" };
 
-#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? &CKENA : &CKENB)
+#define CKEN_AB(bit) ((CKEN_ ## bit > 31) ? &CKENB : &CKENA)
 #define PXA3XX_CKEN(dev_id, con_id, parents, mult_lp, div_lp, mult_hp,	\
 		    div_hp, bit, is_lp, flags)				\
 	PXA_CKEN(dev_id, con_id, bit, parents, mult_lp, div_lp,		\
-- 
2.1.4

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Stephen Boyd]

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 <robert.jarzmik@free.fr>
> ---

Did you want a fixes tag to send this back to stable?

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Robert Jarzmik]

Stephen Boyd <sboyd@codeaurora.org> 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 <robert.jarzmik@free.fr>
>> ---
>
> 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 ?

Cheers.

-- 
Robert

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Stephen Boyd]

On 08/03/2015 11:22 PM, Robert Jarzmik wrote:
> Stephen Boyd <sboyd@codeaurora.org> 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 <robert.jarzmik@free.fr>
>>> ---
>> 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.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Robert Jarzmik]

Stephen Boyd <sboyd@codeaurora.org> writes:

> On 08/03/2015 11:22 PM, Robert Jarzmik wrote:
>> Stephen Boyd <sboyd@codeaurora.org> 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 <robert.jarzmik@free.fr>
>>>> ---
>>> 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 <arnd@arndb.de>
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).

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Stephen Boyd]

On 08/04/2015 11:33 AM, Robert Jarzmik wrote:
> Stephen Boyd <sboyd@codeaurora.org> writes:
>
>> On 08/03/2015 11:22 PM, Robert Jarzmik wrote:
>>> Stephen Boyd <sboyd@codeaurora.org> 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 <robert.jarzmik@free.fr>
>>>>> ---
>>>> 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 ?
>

Ah ok. I wasn't aware that we switched on CCF for PXA this time around. 
Did the commit text mean to mention the pxa3xx-nand driver? I can fix 
that up when applying.

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Re: [PATCH] clk: pxa: pxa3xx: fix CKEN register access

[Robert Jarzmik]

Stephen Boyd <sboyd@codeaurora.org> writes:

> On 08/04/2015 11:33 AM, Robert Jarzmik wrote:
>> Stephen Boyd <sboyd@codeaurora.org> writes:
>>
>>> On 08/03/2015 11:22 PM, Robert Jarzmik wrote:
>>>> Stephen Boyd <sboyd@codeaurora.org> 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 <robert.jarzmik@free.fr>
>>>>>> ---
>>>>> 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 ?
>>
>
> Ah ok. I wasn't aware that we switched on CCF for PXA this time around. Did the
> commit text mean to mention the pxa3xx-nand driver? I can fix that up when
> applying.
Oh yes please, it's indeed pxa3xx-nand driver.

Thanks.

-- 
Robert