From: archit@ti•com (Archit Taneja)
To: linux-arm-kernel@lists•infradead.org
Subject: [RFC 2/4] ARM: dts: Add ctrl-core DT node for DRA7
Date: Thu, 8 May 2014 11:32:58 +0530 [thread overview]
Message-ID: <536B1E12.1080304@ti.com> (raw)
In-Reply-To: <20140506142606.GA18474@atomide.com>
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
Archit
Archit
next prev parent reply other threads:[~2014-05-08 6:02 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-16 13:14 [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 Archit Taneja
2014-04-16 13:14 ` [RFC 2/4] ARM: dts: Add ctrl-core DT node " Archit Taneja
2014-04-18 17:18 ` Tony Lindgren
2014-04-21 5:15 ` Archit Taneja
2014-04-21 15:10 ` Tony Lindgren
2014-05-06 5:22 ` Archit Taneja
2014-05-06 14:26 ` Tony Lindgren
2014-05-08 6:02 ` Archit Taneja [this message]
2014-05-08 7:53 ` Tero Kristo
2014-05-08 8:16 ` Archit Taneja
2014-04-16 13:14 ` [RFC 3/4] ARM: dts: Add dss_deshdcp clock node under dra7-ctrl-core Archit Taneja
2014-04-16 13:14 ` [RFC 4/4] CLK: TI: Enable dss_deshdcp clock in dra7xx_clk_init Archit Taneja
2014-05-08 1:19 ` [RFC 1/4] ARM: OMAP2+: Add CTRL_MODULE_CORE as a master clock provider for DRA7 Paul Walmsley
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=536B1E12.1080304@ti.com \
--to=archit@ti$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox