Tomi Valkeinen wrote:

2010/11/30 Tomi Valkeinen [off-list ref]:

On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote:

quoted

quoted

-----Original Message-----
From: Paul Mundt [mailto:lethal@linux-sh.org]
Sent: Tuesday, November 30, 2010 12:10 PM
To: Ville Syrj?l?
Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux-
fbdev@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote:

<snip>

OMAP has user writeable shadow registers and hidden real registers for
display controller. The shadow registers are latched to real registers
on VFP, but only if GO bit has been set. The GO bit is cleared by the HW
when latching has been done.

If the GO bit is set, we cannot touch the shadow registers because we
don't know when the VFP  will happen. That's why there's additionally a
SW cache for the config, so that we don't need to block when the GO bit
is up and the user wants to change the config. The driver "flushes" the
SW config to real registers in VSYNC interrupt handler.

Does the driver flush the config to real register directly not a shadow register
in VSYNC ISR? Does it mean display controller use the config flushed
to the real register from the VSYNC ?

I don't know OMAP in detail. But as I know other SoCs also work like it.

Can Go bit is cleared by SW ? And does each overlay(FB) have its own Go bit ?
If Go bit can be cleared by SW, how do you think about the following scheme ?

When user wants to change the config, clear the Go bit
although Go bit has been already set.
And set the config shadow register and then re-set the go bit.
It can make one Vsync delay for the first user who has wanted to
change the config.
But it can reduce the delay for the second user. And WAITFORGO can be removed.

BTW as I know, Android also uses WAITFORVSYNC for multiple buffering.

<snip>

--
To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

BRs,