On 5/22/2012 4:20 PM, Tero Kristo wrote:
On Wed, 2012-05-16 at 11:15 +0530, Rajendra Nayak wrote:
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-cous...@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<rna...@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.
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?
Any comments to this? This is blocking v6 for this set.
That's OK for me.
Also, who is going to generate the hwmod data?
Well, in that case, only two entries have to be changed I guess, but
I'll update anyway the scripts to populate the missing one with the
macros you will create.
Benoit
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
