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>
>> >
>> >> +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.
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 ?
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.
>
>> > 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
