[U-Boot] [PATCH v5 4/9] board: ti: dra7xx-evm: turn on USB clocks in late init stage

[Jean-Jacques Hiblot]

On 16/05/2018 17:21, Tom Rini wrote:
> 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.
I understand it is frustrating to merge this kind of platform code when
a generic framework exists, but it is  one step in having DM_USB
support which in the end will remove more platform code.

>