[PATCHv9 00/43] ARM: TI SoC clock DT conversion

[Nishanth Menon]

On 10/31/2013 08:55 AM, Nishanth Menon wrote:
> On 10/31/2013 04:10 AM, Tero Kristo wrote:
>> On 10/30/2013 10:10 PM, Nishanth Menon wrote:
>>> On 10/30/2013 10:00 AM, Nishanth Menon wrote:
>>>> On 10/30/2013 03:23 AM, Tero Kristo wrote:
>>>>> On 10/29/2013 06:19 PM, Nishanth Menon wrote:
>>>>>> On 10/25/2013 10:56 AM, Tero Kristo wrote:
>>>>>> <snip>
>>>>>>> Testing done:
>>>>>>> - omap3-beagle: boot + suspend/resume (ret + off)
>>>>>>> - omap4-panda-es: boot + suspend/resume
>>>>>>> - omap5-uevm: boot
>>>>>>> - dra7-evm: boot
>>>>>>> - am335x-bone: boot
>>>>>>>
>>>>>>> Test branches available:
>>>>>>>
>>>>>>> tree: https://github.com/t-kristo/linux-pm.git
>>>>>>
>>>>>> <snip>
>>>>>>> Fully functioning test branch: 3.12-rc6-dt-clks-v9
>>>>>>>
>>>>>> ^^ I tested this branch (boot testing):
>>>>>> Beagle-XM: http://pastebin.com/50A1qtFq (crashes + clkdm issues, dpll5
>>>>>> failed to transition)
>>>>>
>>>>> I just sent you a private email with a patch to try out, should fix the
>>>>> boot crash at least hopefully. Basically I forgot to convert one part of
>>>>> the kernel to the new regmap stuff for omap36xx.
>>>>
>>>> it does bootup yes.
>>>>>
>>>>> clkdm issues are caused by wrong data in omap_hwmod_3xxx_data.c, USB
>>>>> nodes are listing l3_init_clkdm for them, but this only exists on
>>>>> omap4+. Seems like some copy paste bug introduced by someone.
>>>>>
>>>>> dpll5 part I am not too sure, can you check if the same happens with
>>>>> non-dt boot?
>>>>
>>>> no-dt: http://pastebin.com/bYP9fTzH
>>>> dt: http://pastebin.com/xHup4L9Y
>>>>
>>>> dpll5 warning seems to be only in dt-boot?
>>>>
>>>
>>> Tracked this down: you were missing the following - looks like the
>>> conversion script might be missing converting the flags clock data
>>> over to dts?
>>>
>>> diff --git
>>> a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
>>> b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
>>> index 7e37e3e..c9b77c8 100644
>>> --- a/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
>>> +++ b/arch/arm/boot/dts/omap36xx-am35xx-omap3430es2plus-clocks.dtsi
>>> @@ -30,6 +30,7 @@
>>>                  compatible = "ti,omap3-dpll-clock";
>>>                  clocks = <&sys_ck>, <&sys_ck>;
>>>                  reg = <0x0d04>, <0x0d24>, <0x0d34>, <0x0d4c>;
>>> +               ti,low-power-stop;
>>>          };
>>>
>>>          dpll5_m2_ck: dpll5_m2_ck {
>>>
>>>
>>>
>>
>> Yea, seems I introduced the problem with the conversion script changes. 
>> The valid fix for this is actually at the end of this mail (this fixes 
>> both of the problems introduced, and also completes the fix you did), I 
>> will add the fixes to the next rev. 
> 
> One debug feedback:
> reg = <0x0d04>, <0x0d24>, <0x0d34>, <0x0d4c>;
> clocks = <&sys_ck>, <&sys_ck>;
> 
> we used indexing for varied register and clocks. however the register
> meaning per index changes based on type of DPLL. This was one painful
> thing to track down when debugging. the only robust option to debug
> was to use prints as part of register write/reads to ensure that right
> sequence was being followed.
> 
> I understand based on review comments for dtb size, we have removed
> the names, but we lost sane debug capability as well with that.
> 

I dont have any further feedback at this point beyond what is already
shared and so far my minimal tests have been good..

I have the following warnings:
sparse build warnings: http://pastebin.com/HZ1TWzyh
kernel-doc warnings: http://pastebin.com/JQwFEuaC

Hopefully, the next rev will not introducing nothing newer that what
we have in mainline.


-- 
Regards,
Nishanth Menon