On Tue, 2012-10-09 at 13:37 -0700, Kevin Hilman wrote: > Hi Tomi, > > Tomi Valkeinen <tomi.valkeinen@xxxxxx> writes: > > > 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 <tomi.valkeinen@xxxxxx> > > Cc: Tony Lindgren <tony@xxxxxxxxxxx> > > [...] > > 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
Attachment:
signature.asc
Description: This is a digitally signed message part
