RE: [RESEND][PATCH v2] OMAP: DSS: Adding two APIs for panel-taal: check_timings and set_timings

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

On Thu, 2011-02-17 at 02:50 -0600, Janorkar, Mayuresh wrote:
> Tomi,
> 

<snip>

> > If so, I think the change should be in the omapfb driver. Perhaps the
> > omapfb driver should:
> > 
> > 1. check if check_timings & set_timings exist
> > 2. if they do exist, do the same thing as the code does now
> > 3. if they don't, use get_timings to verify that the given resolution is
> > correct
> 
> But that would lead to a situation in which you would set the bits-per-pixel without checking if panel supports it.

You are mixing up the panel's color depth and the framebuffer's color
depth. The panel has a certain color depth, and that is not changed.

The fb parameter sets up the framebuffer color depth. DISPC will convert
that input color depth to 24bpp internally, and then again convert it to
16/18/24 bpp when outputting it to the panel. So fb and panel color
depths are independent.

> > That wouldn't be perfect either, but I guess it should do the job. But
> > this is again something where FB framework and OMAP HW do not quite
> > match, and we end up with hacky solution, no matter what we do. But we
> > can try to keep the hacks in the omapfb driver =).
> 
> 
> OMAPFB depends a on the attached panel for configuring FB parameters.
> panel-generic-dpi.c it has an API dpi_check_timings which checks whether timings are supported or not.
> How about adding a similar API for dsi_check_timings? We would call it from panel-taal.
> (I do understand that timings required by taal are only xres and yres much less compared to dpi)

For command mode panels the xres and yres are hardcoded, you cannot
change them. I don't see a reason to have a set or check function for
that. Omapfb should not try to change the values, if they cannot be
changed.

I think in this case omapfb should just check if the given xres/yres is
correct, and use the given bpp for the framebuffer.

 Tomi