[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c

Ville Syrjälä ville.syrjala at linux.intel.com
Fri Apr 20 06:49:08 PDT 2012

On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote:
> On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie <airlied at gmail.com> wrote:
> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
> > <ville.syrjala at linux.intel.com> wrote:
> >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote:
> >>> On Thu, Apr 5, 2012 at 7:35 PM,  <ville.syrjala at linux.intel.com> wrote:
> >>> > From: Ville Syrjälä <ville.syrjala at linux.intel.com>
> >>> >
> >>> > There will be a need for this function in drm_crtc.c later. This
> >>> > avoids making drm_crtc.c depend on drm_crtc_helper.c.
> >>>
> >>> Hi Ville,
> >>>
> >>> I've applied these 4 patches, but I might have lost some others for
> >>> you, let me know if there is some other stuff I should be reviewing
> >>> for -next.
> >>
> >> IIRC only one patch fell through the cracks:
> >> Subject: [PATCH] drm: Unify and fix idr error handling
> >> Message-Id: <1331834311-30757-1-git-send-email-ville.syrjala at linux.intel.com>
> >
> > Thanks I'll take a look at that,
> >
> >>
> >> BTW you never gave any statement wrt. removing NV12M and YUV420M from
> >> drm_fourcc.h. I can send a patch if you agree, and if not, well then
> >> someone has to actually change the code to treat them exactly the same
> >> as NV12 and YUV420.
> >
> > I'm probably not qualified, if you and jbarnes and say one other
> > non-Intel person agree, then send the patch with R-b and I'll apply
> > it.
> I agree that they seem like the same thing (as their non-M
> counterparts) to me..  maybe the one exception is if there was hw that
> somehow *only* supported discontiguous multi-planar.

The way things are currently, anyone can feed the driver either
contiguous or discontiguous planes using either format.

As a hint to userspace the M version might work, except it still
doesn't tell you anything on how you need to allocate or align the
planes. Since memory allocation is driver specific anyway, I see no
point in overloading the pixel formats with that information. Some
other mechanism to communicate such information would be needed if
there is a desire to make it generic.

> I can't really
> tell if this is the case in current exynos, it seems to only advertise
> XRGB8888 (but possibly I'm looking in the wrong place).
> For drivers that have weird requirements, I'd suggest they use the non
> 7-bit ascii space (ie. one or more of bytes in fourcc is non-ascii, so
> as to not conflict with potential future standard fourcc's) driver
> specific format values.

We could define a DRM_FORMAT_DRIVER_SPECIFIC bit just like we have
DRM_FORMAT_BIG_ENDIAN. We still have three bits to choose from. OTOH
I'm not too worried about standard fourccs since we already differ
from the standard names anyway.

Ville Syrjälä
Intel OTC

More information about the dri-devel mailing list