[U-Boot] [PATCH] arch: ifc: update the IFC IP input clock

[Scott Wood]

On 09/22/2016 03:55 AM, Prabhakar Kushwaha wrote:
> Hi Scott,
> 
> Sorry for late reply on this thread
> 
> 
>> -----Original Message-----
>> From: Scott Wood
>> Sent: Friday, September 09, 2016 7:30 AM
>> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; york sun
>> <york.sun at nxp.com>; u-boot at lists.denx.de
>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>
>> On 09/08/2016 08:46 PM, Prabhakar Kushwaha wrote:
>>>
>>>> -----Original Message-----
>>>> From: Scott Wood
>>>> Sent: Friday, September 09, 2016 6:05 AM
>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; york sun
>>>> <york.sun at nxp.com>; u-boot at lists.denx.de
>>>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>>>
>>>> On 09/08/2016 07:05 PM, Prabhakar Kushwaha wrote:
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: york sun
>>>>>> Sent: Thursday, September 08, 2016 9:22 PM
>>>>>> To: Prabhakar Kushwaha <prabhakar.kushwaha at nxp.com>; u-
>>>>>> boot at lists.denx.de; Scott Wood <scott.wood at nxp.com>
>>>>>> Subject: Re: [PATCH] arch: ifc: update the IFC IP input clock
>>>>>>
>>>>>> On 09/08/2016 02:33 AM, Prabhakar Kushwaha wrote:
>>>>>>
>>>>>> <snip>
>>>>>>
>>>>>>>>> So better to print IP clock to avoid any confusion.
>>>>>>>>> IFC output clock will be printed when it is actually being used during
>>>>>>>> synchronous NOR, syn NAND.
>>>>>>>>
>>>>>>>> I am not against changing it to internal clock. But what are you going
>>>>>>>> to print on the console? I think it is confusing to say IFC or local bus
>>>>>>>> internal clock speed. Please also check how this clock is used and make
>>>>>>>> sure arch.lbc_clk is still correct, after passing to Linux.
>>>>>>>>
>>>>>>> arch.lbc_clk is only being used for eLBC for device tree fixup.
>>>>>>> And I checked the Linux eLBC driver. Looks like it is not using used.
>>>>>>>
>>>>>>
>>>>>> If this clock is not used, can we drop it completely?
>>>>>>
>>>>>
>>>>> From my point of view Yes.
>>>>>
>>>>> Scott, Please advice
>>>>
>>>> Well, there is that patch from Matt Weber that is trying to guess the
>>>> IFC frequency in order to use NWAIT...  Not sure if we'll end up
>>>> actually using NWAIT
>>> (Prabhakar, can you answer my question of whether
>>>> there is a better opcode to use with RNDOUT?) or ever sending a real
>>>> RNDOUT, or if we'll ever care about these newer NAND chips on eLBC, but
>>>> if U-Boot is currently writing the clock frequency into the device tree
>>>> I don't see why we'd rip it out.
>>>>
>>>
>>> IFC frequency means IP clock or IP output clock?
>>
>> External bus clock.  Which is currently being written to the device tree?
>>
>>> If IP clock then other patch for eLBC still valid.
>>
>> What other patch?
>>
>>>
>>> For IFC: Code needs to be added for device tree fixup for PowerPC, ARM SoC.
>>> It is missing for now :(
>>
>> No, we don't want to introduce new clock-frequency fixups.  If we need
>> this on IFC we should add a clocks property.  But if we already have
>> clock-frequency on eLBC then no reason not to use that if needed.
>>
> I am not against keeping " bus-frequency" on eLBC.   (U-boot fixup bus-frequency not clock-frequncy)
> 
> But the  value which is getting assigned to " bus-frequency" is not right.
> Currently, it is setting SYSCLK/LCRR i.e. output clock where eLBC run at CCB or CCB/2.
> So, if we want to have  " bus-frequency " on eLBC then it needs to be corrected.

If the fixup is not correct then just remove it.

-Scott