[PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c
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.
More information about the dri-devel