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

Archit Taneja archit at ti.com
Wed May 7 23:02:58 PDT 2014

On Tuesday 06 May 2014 07:56 PM, Tony Lindgren wrote:
> * Archit Taneja <archit at ti.com> [140505 22:24]:
>> Hi,
>> On Monday 21 April 2014 08:40 PM, Tony Lindgren wrote:
>>> * Archit Taneja <archit at ti.com> [140420 22:16]:
>>>> Hi,
>>>> On Friday 18 April 2014 10:48 PM, Tony Lindgren wrote:
>>>>> * Archit Taneja <archit at 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



More information about the linux-arm-kernel mailing list