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.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.
If the fixup is not correct then just remove it. -Scott _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot