From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Wed, 16 May 2018 11:21:32 -0400 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-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: <20180516152132.GG3424@bill-the-cat.ec.rr.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 Wed, May 16, 2018 at 11:04:18AM +0200, 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 ? We should certainly re-evaluate the situation once hwmod finally gets replaced in the kernel. That's a long-standing and slowly-but-surely happening thing. -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: