> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of K, Mythri P > Sent: Thursday, March 10, 2011 3:03 PM > To: Valkeinen, Tomi > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: [PATCH v4 6/9] OMAP4 : DSS2 : HDMI: HDMI panel driver > addition in the DSS > > Hi Tomi, > > On Thu, Mar 10, 2011 at 2:49 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> > wrote: > > On Thu, 2011-03-10 at 03:00 -0600, K, Mythri P wrote: > >> Hi Tomi, > >> > >> On Thu, Mar 10, 2011 at 1:22 PM, Tomi Valkeinen <tomi.valkeinen@xxxxxx> > wrote: > >> > On Wed, 2011-03-09 at 05:45 -0600, K, Mythri P wrote: > >> >> The panel driver(hdmi_omap4_panel.c) in omap2/dss acts as a > controller > >> >> to manage the enable and disable requests and synchronize audio and > video. > >> >> > >> >> Signed-off-by: Mythri P K <mythripk@xxxxxx> > >> > > >> > <snip> > >> > <snip> > >> > >> I have set it to VGA , But anyways we need to fix FB to take the > >> feedback from the driver > >> for the timing , atleast when you disable the overlay set manager and > >> enable it again. > > > > No, the FB cannot do anything with that information. FB driver can't > > change the resolution by itself. It has to happen on some upper level, > > in the user space. > > > > The only case when the FB can select the resolution is when the driver > > is loading. At that point nobody is using the framebuffer, as it didn't > > even exist earlier. That's why I suggested reading the EDID in the > > probe. > > Reading the EDID during probe is not feasible , > 1. To read EDID we have to enable clocks and configure HDMI , which > may not be intended - as probe does not mean > that the user would want to enable HDMI. > 2. If HDMI is not connected at boot up , but the cable is plugged in > later on we will run into issues. > There are mechanisms in v4l2 to reconfigure the overlay size and its > own parameters , Even if a notification is sent there is no > mechanism today in FB to do it. > What happens if FB is switched from one manager to other with > resolution ? [Hiremath, Vaibhav] Isn't we get interrupt on HDMI connection back to CPU? > There is not neat way to do it today, So i think a more reasonable way > is to find a way to atleast > let the user space change the virtual size of FB dynamically given > there is enough VRAM allocated. > [Hiremath, Vaibhav] I think let default VRAM allocation be minimal and let user configure omapfb.vram using bootargs (or IOCTL) based on his requirement. Thanks, Vaibhav > > > > >> > I think you should either probe the display here to find what it > >> > supports, and initialize the size accordingly, or if the display is > not > >> > connected, use some safe resolution most of the displays should > support. > >> > VGA probably. > >> > > >> > And the timings selected here should also be used by the hdmi driver. > >> > What happens now with my monitor is that I get a fb of 1920x1028, but > >> > the hdmi driver doesn't like the modes my monitor gives via EDID, and > >> > falls back to VGA -> messed up display. > >> > > >> > Also, I'm getting "timeout waiting for EVSYNC" when I load or unload > the > >> > driver. > >> > > >> This is ok, I have not seen any issue because of this warning, > > > > It's an error, it's not ok =). > > > >> Also we need to understand the rationale as to why the wait_timeout was > added > >> in the code "dispc_enable_digit_out", It seems more like a hack, and > >> not necessarily needed? > > > > When disabling, the point is to wait until the DISPC has really turned > > off the output. For VENC this needed waiting for EVSYNC_EVEN and ODD. I > > don't remember why the same code is ran when enabling. > > > > HDMI may work differently, so it is possible that the function needs to > > be fixed. But I wonder why it gives timeouts when enabling HDMI also... > > Shouldn't the EVSYNCs happen with HDMI too? > > > > We can look at that later, presuming the timeout doesn't cause any > > problems. > > > HDMI is not dependent on the EVSYNC_ODD , but on EVSYNC EVEN, > it has never needed to wait and has not caused any issue for last 8-10 > months it is being used :). > Why the same function was used ? Because it is a generic digit_out > function to do a TVENABLE. > > > Tomi > > > > > > > -- > 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 -- 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
