linux-toradex.git/include/drm/drm_fourcc.h, branch v3.4.73

drm: Add multi buffer plane pixel formats

2011-12-29T02:21:42+00:00

Multi buffer plane pixel format has seperated memory spaces for each
plane. For example, NV12M has Y plane and CbCr plane and these are in
non contiguous memory region. Compared with NV12, NV12M's memory shape
is like following.
NV12  : ______(Y)(CbCr)_______
NV12M : __(Y)_ ..... _(CbCr)__

Signed-off-by: Seung-Woo Kim 
Signed-off-by: Inki Dae 
Signed-off-by: Kyungmin Park

drm: fourcc: Use __u32 instead of u32

2011-12-20T10:02:18+00:00

drm_fourcc.h can be included from user space so use the appropriate types.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Dave Airlie

drm: Redefine pixel formats

2011-12-01T14:16:10+00:00

Name the formats as DRM_FORMAT_X instead of DRM_FOURCC_X. Use consistent
names, especially for the RGB formats. Component order and byte order are
now strictly specified for each format.

The RGB format naming follows a convention where the components names
and sizes are listed from left to right, matching the order within a
single pixel from most significant bit to least significant bit.

The YUV format names vary more. For the 4:2:2 packed formats and 2
plane formats use the fourcc. For the three plane formats the
name includes the plane order and subsampling information using the
standard subsampling notation. Some of those also happen to match
the official fourcc definition.

The fourccs for for all the RGB formats and some of the YUV formats
I invented myself. The idea was that looking at just the fourcc you
get some idea what the format is about without having to decode it
using some external reference.

Signed-off-by: Ville Syrjälä 
Signed-off-by: Dave Airlie

drm: add an fb creation ioctl that takes a pixel format v5

2011-11-15T19:53:23+00:00

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
    update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
    pull in Ville's fix for the memcpy in drm_plane_init
    apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä 
Acked-by: Alan Cox 
Reviewed-by: Rob Clark 
Signed-off-by: Jesse Barnes 
Signed-off-by: Dave Airlie