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.kushw...@nxp.com>; york sun
> <york....@nxp.com>; u-boot@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.kushw...@nxp.com>; york sun
> >> <york....@nxp.com>; u-boot@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.kushw...@nxp.com>; u-
> >>>> b...@lists.denx.de; Scott Wood <scott.w...@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.

--prabhakar


_______________________________________________
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot

Reply via email to