Re: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7

[Tero Kristo <t-kristo@ti.com>]

On 05/08/2014 09:02 AM, Archit Taneja wrote:
> On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote:
>> * Archit Taneja <archit@ti.com> [140505 22:24]:
>>> Hi,
>>>
>>> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
>>>> * Archit Taneja <archit@ti.com> [140420 22:16]:
>>>>> Hi,
>>>>>
>>>>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>>>>> * Archit Taneja <archit@ti.com> [140416 06:20]:
>>>>>>> Add DT node for the ctrl-core sub module of the DRA7 control
>>>>>>> module. We map the
>>>>>>> CTRL_MODULE_CORE address region up to 0x4a002d60, this region
>>>>>>> contains register
>>>>>>> fields which configure clocks. The remainder of the registers are
>>>>>>> related to
>>>>>>> pad configurations or cross-bar configurations, and therefore
>>>>>>> aren't mapped.
>>>>>>
>>>>>> Can you please check if this can just use the existing
>>>>>> regmap syscon mapping:
>>>>>>
>>>>>> syscon = <&dra7_ctrl_general>;
>>>>>>
>>>>>> See how the drivers/regulator/pbias-regulator.c is using the
>>>>>> syscon to initialize a regulator and then omap_hsmmc.c just does
>>>>>> the standard regulator calls.
>>>>>
>>>>> The thing is that this bit needs to be set before the the DSS
>>>>> hwmods are
>>>>> reset, and that happens very early. If we don't do this, DSS won't
>>>>> reset
>>>>> properly, and not get back to an idle state.
>>>>>
>>>>> I am not sure where I can configure the syscon register early
>>>>> enough that it
>>>>> happens before the hwmods are reset. With a syscon mapping, I guess
>>>>> we would
>>>>> access the register when the DSS driver is probed. But that's too
>>>>> late for
>>>>> us.
>>>>>
>>>>> Ideally, it would be much better to have a syscon mapping. Do you
>>>>> have any
>>>>> suggestions how this can be achieved very early in boot?
>>>>
>>>> It's best to move the reset and initialization of DSS happen later.
>>>> I believe
>>>> we already are resetting only some of the hwmods early on.
>>>>
>>>
>>> I looked at this in some more detail. With the current hwmod
>>> flags(HWMOD_INIT_NO_RESET/NO_IDLE), we still try to enable the IP,
>>> it's just
>>> the reset part(ocp reset/custom reset and sysc register) or the
>>> disable part
>>> that is skipped. hwmod still tries to enable the IP.
>>>
>>> This again results in the same issue.
>>>
>>> One thing which wasn't clear was that why do we enable a hwmod in the
>>> first
>>> place, if we know that we are going to skip reset?
>>
>> Probably to configure the idle bits. In general, we should configure the
>> modules lazily as the driver probes as requested, and then idle the
>> unused modules with a late_initcall.
>
> Okay, we were thinking of changing the hwmod code to skip enable for
> hwmods(which have the HWMOD_INIT_NO_RESET flag) altogether. But that
> doesn't seem like a viable option.
>
> I can't think of any other way of getting around this, besides making
> control module a clock provider.
>
> Paul said that it's not that bad to make DRA7 CTRL module a clock
> provider, but outside of PRCM code. I guess that would involve having
> something along the lines of of_prcm_init() in mach-omap2/control.c

That sounds like pretty much one of the things I have done here:

https://github.com/t-kristo/linux-pm/tree/3.14-rc4-cm-prm-driver-wip

The patches in their current form haven't been posted yet though, as 
they are waiting for some of the pre-reqs, but feel free to re-use 
something from here.

-Tero

>
> Archit
>
>
> Archit
>