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

[Jean-Jacques Hiblot <jjhiblot@ti.com>]

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