[U-Boot] [PATCH 01/12] ARM: socfpga: Sync A10 clock manager binding parser

[Marek Vasut]

On 05/18/2018 10:53 AM, Chee, Tien Fong wrote:
> On Fri, 2018-05-18 at 10:42 +0200, Marek Vasut wrote:
>> On 05/18/2018 10:39 AM, Chee, Tien Fong wrote:
>>>
>>> On Fri, 2018-05-18 at 09:50 +0200, Marek Vasut wrote:
>>>>
>>>> On 05/18/2018 06:41 AM, Chee, Tien Fong wrote:
>>>>>
>>>>>
>>>>> On Thu, 2018-05-17 at 11:38 +0200, Marek Vasut wrote:
>>>>>>
>>>>>>
>>>>>> On 05/17/2018 10:44 AM, Chee, Tien Fong wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 2018-05-17 at 10:24 +0200, Marek Vasut wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 05/17/2018 06:38 AM, Chee, Tien Fong wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Sat, 2018-05-12 at 22:30 +0200, Marek Vasut wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The A10 clock manager parsed DT bindings generated by
>>>>>>>>>> Quartus
>>>>>>>>>> the
>>>>>>>>>> bsp-editor to configure the A10 clocks. Sadly, those
>>>>>>>>>> DT
>>>>>>>>>> bindings
>>>>>>>>>> changed at some point. The clock manager patch used
>>>>>>>>>> the
>>>>>>>>>> old
>>>>>>>>>> ones,
>>>>>>>>>> this patch replaces the bindings parser with one for
>>>>>>>>>> the
>>>>>>>>>> new
>>>>>>>>>> set.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Marek Vasut <marex at denx.de>
>>>>>>>>>> Cc: Chin Liang See <chin.liang.see at intel.com>
>>>>>>>>>> Cc: Dinh Nguyen <dinguyen at kernel.org>
>>>>>>>>>> ---
>>>>>>>>>>  arch/arm/mach-socfpga/clock_manager_arria10.c      | 
>>>>>>>>>> 158
>>>>>>>>>> ++++++++++++++-------
>>>>>>>>>>  .../include/mach/clock_manager_arria10.h           |
>>>>>>>>>>    2
>>>>>>>>>> +-
>>>>>>>>>>  2 files changed, 111 insertions(+), 49 deletions(-)
>>>>>>>>>>
>>>>>>>>>> diff --git a/arch/arm/mach-
>>>>>>>>>> socfpga/clock_manager_arria10.c
>>>>>>>>>> b/arch/arm/mach-socfpga/clock_manager_arria10.c
>>>>>>>>>> index 4ee6a82b5f..defa2f6261 100644
>>>>>>>>>> --- a/arch/arm/mach-socfpga/clock_manager_arria10.c
>>>>>>>>>> +++ b/arch/arm/mach-socfpga/clock_manager_arria10.c
>>>>>>>>>> @@ -9,6 +9,9 @@
>>>>>>>>>>  #include <dm.h>
>>>>>>>>>>  #include <asm/arch/clock_manager.h>
>>>>>>>>>>  
>>>>>>>>>> +static const struct socfpga_clock_manager
>>>>>>>>>> *clock_manager_base =
>>>>>>>>>> +	(struct socfpga_clock_manager
>>>>>>>>>> *)SOCFPGA_CLKMGR_ADDRESS;
>>>>>>>>>> +
>>>>>>>>>>  static u32 eosc1_hz;
>>>>>>>>>>  static u32 cb_intosc_hz;
>>>>>>>>>>  static u32 f2s_free_hz;
>>>>>>>>>> @@ -64,89 +67,150 @@ struct perpll_cfg {
>>>>>>>>>>  	u32 cntr8clk_cnt;
>>>>>>>>>>  	u32 cntr8clk_src;
>>>>>>>>>>  	u32 cntr9clk_cnt;
>>>>>>>>>> +	u32 cntr9clk_src;
>>>>>>>>> Why add this? I believe this is not exist.
>>>>>>>> It exists in the altera sources and it matches the
>>>>>>>> pattern.
>>>>>>>> What
>>>>>>>> do
>>>>>>>> you
>>>>>>>> mean by "this is not exist" ?
>>>>>>>>
>>>>>>> we don't have cntr9clk_src in perpll.
>>>>>> https://github.com/altera-opensource/u-boot-socfpga/blob/socf
>>>>>> pga_
>>>>>> v201
>>>>>> 4.10_arria10_bringup/arch/arm/cpu/armv7/socfpga_arria10/clock
>>>>>> _man
>>>>>> ager
>>>>>> .c#L229
>>>>>>
>>>>> That is the bug, and i have already fixed it in mainstream
>>>>> http://git.denx.de/?p=u-boot.git;a=blob;f=arch/arm/mach-socfpga
>>>>> /clo
>>>>> ck_m
>>>>> anager_arria10.c;h=4ee6a82b5f75215d6930d488aa39c572d1610073;hb=
>>>>> HEAD
>>>>> #l11
>>>>> 4
>>>> So the hardware really isn't symmetric in that way ? (why is this
>>>> not
>>>> fixed in the old altera for of u-boot then?)
>>>>
>>> I have no idea why the HW was designed in that way. But the latest
>>> hps.xml handoff file which is generated from qsys and quartus tools
>>> based on our golden system reference design, the
>>> i_clk_mgr_perpllgrp.cntr9clk.cnt is listed inside the file.
>>>
>>> Our priority is getting the things fixed in mainstream, unless the
>>> bugs
>>> in old altera impacts the functionality and board booting up. In
>>> the
>>> end, we will get everything upstream and encouraging user to use
>>> mainstream.
>>>>
>>>> The a10_5v4 doesn't even list clock 9 at all. Why ?
>>>>
>>> This infomation is missing inside the document. Our internal
>>> register
>>> mapping document has this listed.
>> Er, since you say it is listed internally, then the cntr9clk_src
>> exists?
>> I am confused here, really.
>>
> cntr9clk_src is not exists, but cntr9clk_cnt is exists.

Where is that documented and why is every single source file I find
telling me something different ?

-- 
Best regards,
Marek Vasut