Re: [PATCH 05/32] OMAPDSS: fix dss_get_ctx_loss_count for DT

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

On 30/05/13 19:36, Kevin Hilman wrote:
> Tomi Valkeinen <tomi.valkeinen@ti.com> writes:
> 
>> When using DT, dss device does not have platform data. However,
>> dss_get_ctx_loss_count() uses dss device's platform data to find the
>> get_ctx_loss_count function pointer.
>>
>> To fix this, dss_get_ctx_loss_count() needs to be changed to get the
>> platform data from the omapdss device, which is a "virtual" device and
>> always has platform data.
> 
> Dumb question (since the DSS device model has always been beyond my
> grasp): how/why does the virtual device still have platform_data on a DT
> boot?

The virtual device will be created in generic omap arch code for DT boot
also.

The omapdss virtual device is an old relic. Originally we only had the
omapdss device, not the sub-devices for HW block like we have now. After
adding the sub-devices, omapdss device was still left, as it provided
useful functionality. It wasn't strictly needed anymore, but I've just
never had time to start refactoring code to remove it.

Now, with DT, it was just an easy way around to pass the func pointers.
Note that we also pass set_min_bus_tput, and a version identifier for
the DSS HW. The PM funcs could perhaps be handled some other way, but
I'm not sure how I could pass the DSS HW version.

> Also, this context_loss_count and DT boot is starting to get cumbersome,
> and there's currently no (good) way of handling the context loss in a
> generic way without pdata function pointers.
> 
> I'm starting to think we should move towards dropping this OMAP-specific
> context loss counting, and just assume context is always lost.  If there
> are performance problems, runtime PM autosuspend timeouts can be used to
> avoid the transitions.
> 
> Or, on some devices, I suspect comparing a few registers against their
> power-on reset values might be a quicker way of detecting lost context
> and would avoid having to call into platform code all together.

Hmm, true. I'll look at this. Maybe I won't need get_ctx_loss in omapdss
at all.

How about omap_pm_set_min_bus_tput(), can that be handled in some
generic manner? Although, we currently use that in a bit hacky case.
What we're doing is not really setting min bus tput, but we're just
preventing OPP50.

The DSS clocks have different maximums on OPP50 than on OPP100, and we
need to keep the core in OPP100 to keep DSS working. So what I'd rather
use is "prevent_opp50()" than setting arbitrarily high min bus tput.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]