From: Rajendra Nayak <rnayak@ti.com>
To: Kevin Hilman <khilman@ti.com>
Cc: "Cousson, Benoit" <b-cousson@ti.com>,
t-kristo@ti.com, Jon Hunter <jon-hunter@ti.com>,
linux-omap@vger.kernel.org, paul@pwsan.com,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
Date: Wed, 16 May 2012 10:54:57 +0530 [thread overview]
Message-ID: <4FB33A29.4030404@ti.com> (raw)
In-Reply-To: <87pqa5axuo.fsf@ti.com>
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
> "Cousson, Benoit"<b-cousson@ti.com> writes:
>
>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>>> Hi Tero,
>>>>
>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>
>>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>>> OMAP3 and earlier, we relyed on the power domain level context status.
>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>>> hwmods already have a valid 'context_offs' populated in .prcm structure.
>>>>
>>>> Is it necessary to add another flag? Can't we just check if context_offs
>>>> is non-zero? Would save adding a lot more lines to an already large file
>>>> :-)
>>>
>>> Actually one of the older versions of this patch was just checking
>>> against a non-zero value, but it was decided to be changed as
>>> potentially the context_offs can be zero even if it is a valid offset.
>
> Potentially? Is that the case on OMAP4/5 today? I don't see any for
> OMAP4 in mainline.
No, we don;t have any such cases today in either OMAP4 or OMAP5.
>
> If zero really is a valid offset somewhere (where?), then we could use
> -1 (or USHRT_MAX in this case.)
This makes sense for OMAP4 and beyond (and same with having a flag
to indicate the *lack* of having the feature) as it will mean just
adding a few entries in hwmod data files to indicate IP blocks (very
few) which do not support this feature.
However since none of OMAP2/3 varients (except I guess the AMxxxx
family) support this, it would also mean we mark
*most* blocks in OMAP2/3 to indicate they *lack* this feature, which
would mean bloating the OMAP2/3 data files, but your
comment below about doing it for all IPs during hwmod registration
makes sense at least for OMAP2 since *all* blocks can be marked at
registration. OMAP3 would probably need more data files to be updated
to indicate which ones support and which ones don't.
Having said that I also see 'context_reg' being defined inside
omap_hwmod_omap4_prcm would need to be fixed if we have to
support this for SoCs which fall as OMAP3 varients.
>
>> Yeah, but still, every OMAP4 IPs are supporting that except two of
>> them I guess, so it is a pity to add that to every IPs.
>>
>> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
>> supporting that. Since OMAP 2& 3 does not have this feature at all,
>> we can check on the cpu revision.
>>
>> I think the issue raised by Rajendra was about AM35xx that looks like
>> an OMAP3 variant but does have these registers like an OMAP4
>> variant:-(
>
> If AM335x is missing it for *all* IPs, that's easy enough to solve
> without bloating the data file: just set .context_offs field (or flag)
> to the magic value for all IPs during hwmod registration.
>
> Paul/Benoit should make the call whether to use a special value in the
> .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I
> agree with Benoit that it should indicate the *lack* of the feature,
> since having the feature is the norm.
>
> Kevin
>
WARNING: multiple messages have this Message-ID (diff)
From: rnayak@ti.com (Rajendra Nayak)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status
Date: Wed, 16 May 2012 10:54:57 +0530 [thread overview]
Message-ID: <4FB33A29.4030404@ti.com> (raw)
In-Reply-To: <87pqa5axuo.fsf@ti.com>
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
> "Cousson, Benoit"<b-cousson@ti.com> writes:
>
>> On 4/24/2012 4:46 PM, Tero Kristo wrote:
>>> On Mon, 2012-04-23 at 10:52 -0500, Jon Hunter wrote:
>>>> Hi Tero,
>>>>
>>>> On 04/20/2012 04:19 AM, Tero Kristo wrote:
>>>>> From: Rajendra Nayak<rnayak@ti.com>
>>>>>
>>>>> On OMAP4 most modules/hwmods support module level context status. On
>>>>> OMAP3 and earlier, we relyed on the power domain level context status.
>>>>> Identify all such modules using a 'HWMOD_CONTEXT_REG' flag, all such
>>>>> hwmods already have a valid 'context_offs' populated in .prcm structure.
>>>>
>>>> Is it necessary to add another flag? Can't we just check if context_offs
>>>> is non-zero? Would save adding a lot more lines to an already large file
>>>> :-)
>>>
>>> Actually one of the older versions of this patch was just checking
>>> against a non-zero value, but it was decided to be changed as
>>> potentially the context_offs can be zero even if it is a valid offset.
>
> Potentially? Is that the case on OMAP4/5 today? I don't see any for
> OMAP4 in mainline.
No, we don;t have any such cases today in either OMAP4 or OMAP5.
>
> If zero really is a valid offset somewhere (where?), then we could use
> -1 (or USHRT_MAX in this case.)
This makes sense for OMAP4 and beyond (and same with having a flag
to indicate the *lack* of having the feature) as it will mean just
adding a few entries in hwmod data files to indicate IP blocks (very
few) which do not support this feature.
However since none of OMAP2/3 varients (except I guess the AMxxxx
family) support this, it would also mean we mark
*most* blocks in OMAP2/3 to indicate they *lack* this feature, which
would mean bloating the OMAP2/3 data files, but your
comment below about doing it for all IPs during hwmod registration
makes sense at least for OMAP2 since *all* blocks can be marked at
registration. OMAP3 would probably need more data files to be updated
to indicate which ones support and which ones don't.
Having said that I also see 'context_reg' being defined inside
omap_hwmod_omap4_prcm would need to be fixed if we have to
support this for SoCs which fall as OMAP3 varients.
>
>> Yeah, but still, every OMAP4 IPs are supporting that except two of
>> them I guess, so it is a pity to add that to every IPs.
>>
>> We'd better add a HWMOD_NO_CONTEXT_REG to the few IPs that are not
>> supporting that. Since OMAP 2& 3 does not have this feature at all,
>> we can check on the cpu revision.
>>
>> I think the issue raised by Rajendra was about AM35xx that looks like
>> an OMAP3 variant but does have these registers like an OMAP4
>> variant:-(
>
> If AM335x is missing it for *all* IPs, that's easy enough to solve
> without bloating the data file: just set .context_offs field (or flag)
> to the magic value for all IPs during hwmod registration.
>
> Paul/Benoit should make the call whether to use a special value in the
> .context_offs field (0 or -1) or add a new flag. If a flag is chosen, I
> agree with Benoit that it should indicate the *lack* of the feature,
> since having the feature is the norm.
>
> Kevin
>
next prev parent reply other threads:[~2012-05-16 5:25 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-04-20 9:19 [PATCHv4 0/8] ARM: OMAP4: core retention support Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 1/8] ARM: OMAP4: suspend: Program all domains to retention Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 2/8] TEMP: ARM: OMAP4: hwmod_data: Do not get DSP out of reset at boot time Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 4/8] ARM: OMAP4: hwmod: flag hwmods/modules supporting module level context status Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-23 15:52 ` Jon Hunter
2012-04-23 15:52 ` Jon Hunter
2012-04-24 14:46 ` Tero Kristo
2012-04-24 14:46 ` Tero Kristo
2012-04-24 17:14 ` Cousson, Benoit
2012-04-24 17:14 ` Cousson, Benoit
2012-05-15 22:22 ` Kevin Hilman
2012-05-15 22:22 ` Kevin Hilman
2012-05-16 5:24 ` Rajendra Nayak [this message]
2012-05-16 5:24 ` Rajendra Nayak
2012-05-16 5:45 ` Rajendra Nayak
2012-05-16 5:45 ` Rajendra Nayak
2012-05-22 14:20 ` Tero Kristo
2012-05-22 14:20 ` Tero Kristo
2012-05-22 14:29 ` Cousson, Benoit
2012-05-22 14:29 ` Cousson, Benoit
2012-04-20 9:19 ` [PATCHv4 5/8] ARM: OMAP: hwmod: Add support for per hwmod/module context lost count Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-05-02 8:45 ` Bedia, Vaibhav
2012-05-02 8:45 ` Bedia, Vaibhav
2012-05-02 9:20 ` Tero Kristo
2012-05-02 9:20 ` Tero Kristo
2012-05-02 9:55 ` Bedia, Vaibhav
2012-05-02 9:55 ` Bedia, Vaibhav
2012-05-08 0:19 ` Kevin Hilman
2012-05-08 0:19 ` Kevin Hilman
2012-05-08 8:03 ` Tero Kristo
2012-05-08 8:03 ` Tero Kristo
2012-05-08 8:36 ` Tero Kristo
2012-05-08 8:36 ` Tero Kristo
2012-05-08 8:57 ` Rajendra Nayak
2012-05-08 8:57 ` Rajendra Nayak
2012-05-08 9:09 ` Tero Kristo
2012-05-08 9:09 ` Tero Kristo
2012-05-08 9:15 ` Rajendra Nayak
2012-05-08 9:15 ` Rajendra Nayak
2012-05-08 9:49 ` Tero Kristo
2012-05-08 9:49 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 7/8] ARM: OMAP4: PM: Add next_logic_state param to power_state Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-04-20 9:19 ` [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR Tero Kristo
2012-04-20 9:19 ` Tero Kristo
2012-05-03 11:03 ` Jean Pihet
2012-05-03 11:03 ` Jean Pihet
2012-05-03 16:14 ` Tero Kristo
2012-05-03 16:14 ` Tero Kristo
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=4FB33A29.4030404@ti.com \
--to=rnayak@ti.com \
--cc=b-cousson@ti.com \
--cc=jon-hunter@ti.com \
--cc=khilman@ti.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-omap@vger.kernel.org \
--cc=paul@pwsan.com \
--cc=t-kristo@ti.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.