On Tuesday 27 November 2012 06:01 PM, Tero Kristo wrote:
On Tue, 2012-11-27 at 14:21 +0200, Tomi Valkeinen wrote:
On 2012-11-27 13:56, Archit Taneja wrote:
On Tuesday 27 November 2012 04:53 PM, Tomi Valkeinen wrote:
Hmm, well this feels like a hack. DISPC driver doesn't know how the DSS
modules are arranged, which module belongs to which power domain, etc.
If it cannot be fixed in the arch code, I guess we could just have
dss_get_ctx_loss_count(void) function which always returns the
dss_core's ctx loss count, and define that on all the platforms omapdss
is used, the dss_core's ctx loss count is the same as ctx loss count for
all the dss submodules.
Well the context lost count we are interested in isn't the "omapdss"
platform device in core.c, it's the "omapdss_dss" platform device in dss.c
I was considering moving the dss_get_ctx_lost_count() to dss.c, as it
needs the "omapdss_dss" platform_device. It looks better in core.c, but
we would need a dirty way to give it the "omapdss_dss". What do you think?
Archit
I think the above is true for all OMAPs. But it feels like a hack too,
but not as bad as the above patch.
Yes, a function taking in no platform device in dss's core.c would be
less hacky. I guess we would need this for now, because a solution in
omap_hwmod would be more complex and it may not be ready by the merge
window.
Ok. Can you cook up a patch and test it?
PM guys, does the above sound like an acceptable work-around?
This sounds like a good approach to me at least.
-Tero
--
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
