On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote:
Hi Tomi,
Tomi Valkeinen [off-list ref] writes:
quoted
This patch converts vrfb library into a platform device, in an effort to
remove omap dependencies.
The platform device is registered in arch/arm/plat-omap/fb.c and
assigned resources depending on whether running on omap2 or omap3.
The vrfb driver will parse those resources and use them to access vrfb
configuration registers and the vrfb virtual rotation areas.
Signed-off-by: Tomi Valkeinen <redacted>
Cc: Tony Lindgren <tony@atomide.com>
[...]
I was having a quick look at this for the context save/restore piece in
order to understand how this driver's context is being saved/restored.
Looking at mainline, I don't see where omap_vrfb_restore_context() is
being called currently. Am I missing something?
No, the driver is missing something. I noticed the same thing. It seems
ctx restore for vrfb has never been functional in mainline. I don't
really have any recollection if this was left out intentionally from
mainline (possibly because we didn't have a good way to handle it at
that point), or was it just a mistake.
Nobody has complained about it, though, so it can't be a major problem
=).
Vrfb is a platform device/driver after this patch. Do you see any
problem with handling the context restore in runtime PM's runtime_resume
callback? Hmm, I guess then we could have a problem if omapdss and
omapfb are resumed before vrfb.
Any way to manage the suspend/resume ordering of unrelated (i.e. no
parent/child relation) devices?
Tomi