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

[InKi Dae]

2012년 4월 20일 오후 11:22, Rob Clark <rob.clark at linaro.org>님의 말:
> On Fri, Apr 20, 2012 at 8:49 AM, Ville Syrjälä
> <ville.syrjala at linux.intel.com> wrote:
>> 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
>
> yeah, that is a good idea
>
>> 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.
>
> well, was more just thinking from the point of view of clashes if we
> add more standard names later but some driver somewhere was already
> using that new fourcc name
>
> Possibly I'm over-thinking this.. but seemed like a reasonable thing
> to separate standard and non-standard formats before a bunch of driver
> specific formats start cropping up.
>
> BR,
> -R

we just wanted to use multi-planar format in same way as v4l2 side and
I am not still sure that it's good way to add some codes to identify
them. anyway for now, I'm ok.

Thanks,
Inki Dae.

>
>> --
>> Ville Syrjälä
>> Intel OTC
>> _______________________________________________
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel