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>
> >
> >> +static int hdmi_panel_probe(struct omap_dss_device *dssdev)
> >> +{
> >> + DSSDBG("ENTER hdmi_panel_probe\n");
> >> +
> >> + dssdev->panel.config = OMAP_DSS_LCD_TFT |
> >> + OMAP_DSS_LCD_IVS | OMAP_DSS_LCD_IHS;
> >> +
> >> + /*
> >> + * Initialize the timings to 1920 * 1080
> >> + * This is only for framebuffer update not for TV timing setting
> >> + * Setting TV timing will be done only on enable
> >> + */
> >> + dssdev->panel.timings.x_res = 1920;
> >> + dssdev->panel.timings.y_res = 1080;
> >
> > This will cause the framebuffer to be initialized to 1920x1080,
> > regardless of the timings the hdmi driver will select.
>
> 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.
> > 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.
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
