linux-omap.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
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
>


  reply	other threads:[~2012-05-16  5:25 UTC|newest]

Thread overview: 29+ 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 ` [PATCHv4 1/8] ARM: OMAP4: suspend: Program all domains to retention 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 ` [PATCHv4 3/8] ARM: OMAP4460: Workaround for ROM bug because of CA9 r2pX gic control register change 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-23 15:52   ` Jon Hunter
2012-04-24 14:46     ` Tero Kristo
2012-04-24 17:14       ` Cousson, Benoit
2012-05-15 22:22         ` Kevin Hilman
2012-05-16  5:24           ` Rajendra Nayak [this message]
2012-05-16  5:45             ` Rajendra Nayak
2012-05-22 14:20               ` Tero Kristo
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 ` [PATCHv4 6/8] ARM: OMAP4: PM: support ret_logic/mem_off_counters Tero Kristo
2012-05-02  8:45   ` Bedia, Vaibhav
2012-05-02  9:20     ` Tero Kristo
2012-05-02  9:55       ` Bedia, Vaibhav
2012-05-08  0:19   ` Kevin Hilman
2012-05-08  8:03     ` Tero Kristo
2012-05-08  8:36     ` Tero Kristo
2012-05-08  8:57       ` Rajendra Nayak
2012-05-08  9:09         ` Tero Kristo
2012-05-08  9:15           ` Rajendra Nayak
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 ` [PATCHv4 8/8] ARM: OMAP4: PM: Added option for enabling OSWR Tero Kristo
2012-05-03 11:03   ` Jean Pihet
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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).