On Fri, Dec 06, 2013 at 02:29:22PM +0100, Lucas Stach wrote: > Am Freitag, den 06.12.2013, 14:14 +0100 schrieb Thierry Reding: > > On Thu, Dec 05, 2013 at 07:28:06PM +0100, Denis Carikli wrote: > > [...] > > > diff --git a/drivers/staging/imx-drm/ipu-v3/ipu-dc.c b/drivers/staging/imx-drm/ipu-v3/ipu-dc.c > > [...] > > > @@ -155,6 +156,8 @@ static int ipu_pixfmt_to_map(u32 fmt) > > > return IPU_DC_MAP_BGR666; > > > case V4L2_PIX_FMT_BGR24: > > > return IPU_DC_MAP_BGR24; > > > + case V4L2_PIX_FMT_RGB666: > > > + return IPU_DC_MAP_RGB666; > > > > Why is this DRM driver even using V4L2 pixel formats in the first place? > > > Because imx-drm is actually a misnomer. The i.MX IPU is a multifunction > device, which as one part has the display controllers, but also camera > interfaces and mem-to-mem scaler devices, which are hooked up via the > V4L2 interface. > > The generic IPU part, which is used for example for programming the DMA > channels is using V4L2 pixel formats as a common base. We have patches > to split this out and make this fact more visible. (The IPU core will be > placed aside the Tegra host1x driver) Have you considered splitting thing up further and move out the display controller driver to DRM and the camera driver to V4L2? I mean, if that is even possible with a reasonable amount of work. Is the "mem-to-mem" the same as the "DMA channels" you mentioned? If it only does DMA, why does it even need to worry about pixel formats? Thierry
Attachment:
pgpYsQQmKWQES.pgp
Description: PGP signature
