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

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

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@gmail.com> wrote:
> > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrjälä
> > <ville.syrjala@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@linux.intel.com> wrote:
> >>> > From: Ville Syrjälä <ville.syrjala@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@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