Hi Vaibhav, On Thu, Mar 10, 2011 at 3:09 PM, Hiremath, Vaibhav <hvaibhav@xxxxxx> wrote: > >> -----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. > yes I agree , so as Tomi also suggested i'm now setting it to VGA FB , But it would be nice to have a sysfs to do the same, ie FB should be able to look for the resolution of the driver it is connected to and realloc if enough memory is present else default to original , if there is a change in the manager. Just a nice to have intelligence i would think. Thanks and regards, Mythri. > 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
