From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jean-Jacques Hiblot Date: Wed, 16 May 2018 15:53:19 +0200 Subject: [U-Boot] [PATCH v5 4/9] board: ti: dra7xx-evm: turn on USB clocks in late init stage In-Reply-To: References: <1525444491-24324-1-git-send-email-jjhiblot@ti.com> <1525444491-24324-5-git-send-email-jjhiblot@ti.com> <94cee3cd-3e4a-9e7b-174d-0eba1f52b9c2@ti.com> <63cc1a70-416f-1198-b69a-8ba6da966077@denx.de> <170cd2a6-b143-aa78-872a-18f729855be4@ti.com> <5482bf79-ea10-9489-e987-35d7185420db@ti.com> <2c95d761-c22f-48cc-012b-172f131be0f5@denx.de> Message-ID: <08fb1069-afd2-0d8a-404f-15f7beee6a7e@ti.com> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 16/05/2018 11:04, Marek Vasut wrote: > On 05/16/2018 11:00 AM, Jean-Jacques Hiblot wrote: >> >> On 16/05/2018 00:13, Marek Vasut wrote: >>> On 05/15/2018 06:10 PM, Jean-Jacques Hiblot wrote: >>>> Hi Marek, >>>> >>>> >>>> On 04/05/2018 21:06, Marek Vasut wrote: >>>>>>>>> Shouldnt the driver turn this on? >>>>>>>> AFAIK there is no clock driver for the OMAP. So we have to do it >>>>>>>> before >>>>>>>> the driver is probed. >>>>>>> Maybe it's time to implement it instead of piling up those hacks ? >>>>>> I was thinking along the same lines at some point but then I realized >>>>>> that it will make the SPL really big. And we are already tight on some >>>>>> platforms like am335x. >>>>> But this is not only SPL , right ? And yes, for SPL you might need to >>>>> poke registers or something. >>>> IMHO having 2 different ways to enable the clocks in SPL and in u-boot >>>> is an not improvement over the current situation. >>>> In any case, This is a subject that can be discussed. >>> Do you have a better idea ? >> I would keep it as it is today. >> >> After studying the clock management in Linux, I believe that >> implementing the clock drivers in u-boot won't be an easy task and >> moreover won't make things much cleaner. >> The way clocks are handled in Linux for the omap platforms is not >> completely standard. There are a lot of clocks that are handled by the >> clock framework (pll, mux, some gates, ...) but most of the clock gating >> for peripherals is handled the HWMOD subsystem which automatically >> enables/disables the clocks of the peripherals. Parameters for this >> subsystem are hard-coded in platform code (in >> arch/arm/mach-omap2/omap-hwmod_xxx_data.c) not in the DTS. It also >> handle clock and power domains. >> HWMOD is probably going to go away some day, I'm not sure that we want >> to implement it in u-boot. Until hwmod has completely replaced by more >> generic frameworks, I would stick to platform code to enable clocks in >> u-boot. > But if this keeps going on, eventually we will regress to where we were > years ago -- having huge platform specific list of registers to poke to > set a platform up and that'd be it ? For omap clocks that would be status quo but the rest is moving toward DM