From mboxrd@z Thu Jan 1 00:00:00 1970 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= Subject: Re: [PATCH 1/4] drm: Move drm_format_num_planes() to drm_crtc.c Date: Fri, 20 Apr 2012 16:49:08 +0300 Message-ID: <20120420134907.GC13065@intel.com> References: <1333650918-16919-1-git-send-email-ville.syrjala@linux.intel.com> <20120420122341.GA13065@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by gabe.freedesktop.org (Postfix) with ESMTP id 4B9FCA0EB7 for ; Fri, 20 Apr 2012 06:49:11 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: Rob Clark Cc: dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org On Fri, Apr 20, 2012 at 07:48:07AM -0500, Rob Clark wrote: > On Fri, Apr 20, 2012 at 7:29 AM, Dave Airlie wrote: > > On Fri, Apr 20, 2012 at 1:23 PM, Ville Syrj=E4l=E4 > > wrote: > >> On Fri, Apr 20, 2012 at 12:43:03PM +0100, Dave Airlie wrote: > >>> On Thu, Apr 5, 2012 at 7:35 PM, =A0 wr= ote: > >>> > From: Ville Syrj=E4l=E4 > >>> > > >>> > 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.int= el.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=E4l=E4 Intel OTC