[PATCH 1/3] drm/omap: drm API update: addfb2

[Ville Syrjälä]

On Tue, Dec 20, 2011 at 05:58:41PM -0600, Rob Clark wrote:
> On Tue, Dec 20, 2011 at 5:30 PM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
> > On Tue, Dec 20, 2011 at 04:58:51PM -0600, Rob Clark wrote:
> >> +static const struct format formats[] = {
> >> +     /* 16bpp [A]RGB: */
> >> +     { OMAP_DSS_COLOR_RGB16,       DRM_FORMAT_RGB565,   {{2, 1}}, false }, /* RGB16-565 */
> >> +     { OMAP_DSS_COLOR_RGB12U,      DRM_FORMAT_RGBX4444, {{2, 1}}, false }, /* RGB12x-4444 */
> >> +     { OMAP_DSS_COLOR_RGBX16,      DRM_FORMAT_XRGB4444, {{2, 1}}, false }, /* xRGB12-4444 */
> >> +     { OMAP_DSS_COLOR_RGBA16,      DRM_FORMAT_RGBA4444, {{2, 1}}, false }, /* RGBA12-4444 */
> >> +     { OMAP_DSS_COLOR_ARGB16,      DRM_FORMAT_ABGR4444, {{2, 1}}, false }, /* ARGB16-4444 */
> >                                                 ^^^^^^^^
> >
> > Should be ARGB4444, no?
> 
> yes, you are right.. I got that backwards
> 
> > BTW I took a quick gander at the format specifications in the OMAP4 TRM
> > and it has a funny bug.
> >
> > xRGB16-1555 and ARGB16-1555 are listed like this:
> >
> > 31       ...          0
> > U  R1 G1 B1 U  R0 B0 G0
> > A1 R1 G1 B1 A0 R0 B0 G0
> >
> > So every second pixel has B and G swapped around. That would be some
> > interesting hardware to use :D
> >
> > It's possible the TRM I had lying around was an old one though and the
> > issue is fixed in later revisions.
> 
> It is still like this in the version of TRM that I have..  I've never
> really used those formats, so can't really if that is a documentation
> bug or just a weird format.  Maybe I should remove those from the
> table too until I have a chance to verify.

I was going to say that I tested them on OMAP3 when I was still @nokia,
but now that I checked again OMAP3 doesn't support the 1555 formats. It
was the 4444 formats I tested, and even exposed to users via Xv on the
N9.

-- 
Ville Syrjälä
syrjala at sci.fi
http://www.sci.fi/~syrjala/