On Wednesday 16 May 2012 10:54 AM, Rajendra Nayak wrote:
On Wednesday 16 May 2012 03:52 AM, Kevin Hilman wrote:
"Cousson, Benoit"<b-cousson@xxxxxx> 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@xxxxxx>
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.
I just went back and looked at Vaibhavs patch which adds am33xx
hwmod data and I think none of what I said above is a problem.
I think we can safely mark the few blocks on OMAP4 which do
not have a valid context_reg with -1 or USHRT_MAX as you suggested
and mark all OMAP2/3 blocks with this at registration.
Benoit/Paul, does that sound good?
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
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
