lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Thu, 16 Feb 2017 17:33:14 -0800 From: Steve Longerbeam <slongerbeam@...il.com> To: Philipp Zabel <p.zabel@...gutronix.de> Cc: robh+dt@...nel.org, mark.rutland@....com, shawnguo@...nel.org, kernel@...gutronix.de, fabio.estevam@....com, linux@...linux.org.uk, mchehab@...nel.org, hverkuil@...all.nl, nick@...anahar.org, markus.heiser@...marIT.de, laurent.pinchart+renesas@...asonboard.com, bparrot@...com, geert@...ux-m68k.org, arnd@...db.de, sudipm.mukherjee@...il.com, minghsiu.tsai@...iatek.com, tiffany.lin@...iatek.com, jean-christophe.trotin@...com, horms+renesas@...ge.net.au, niklas.soderlund+renesas@...natech.se, robert.jarzmik@...e.fr, songjun.wu@...rochip.com, andrew-ct.chen@...iatek.com, gregkh@...uxfoundation.org, shuah@...nel.org, sakari.ailus@...ux.intel.com, pavel@....cz, devicetree@...r.kernel.org, linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, linux-media@...r.kernel.org, devel@...verdev.osuosl.org, Steve Longerbeam <steve_longerbeam@...tor.com> Subject: Re: [PATCH v4 18/36] media: Add i.MX media core driver On 02/16/2017 05:02 AM, Philipp Zabel wrote: > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote: <snip> >> + >> +- Clean up and move the ov5642 subdev driver to drivers/media/i2c, and >> + create the binding docs for it. > > This is done already, right? I cleaned up ov5640 and moved it to drivers/media/i2c with binding docs, but not the ov5642 yet. > >> +- The Frame Interval Monitor could be exported to v4l2-core for >> + general use. >> + >> +- The subdev that is the original source of video data (referred to as >> + the "sensor" in the code), is called from various subdevs in the >> + pipeline in order to set/query the video standard ({g|s|enum}_std) >> + and to get/set the original frame interval from the capture interface >> + ([gs]_parm). Instead, the entities that need this info should call its >> + direct neighbor, and the neighbor should propagate the call to its >> + neighbor in turn if necessary. > > Especially the [gs]_parm fix is necessary to present userspace with the > correct frame interval in case of frame skipping in the CSI. Right, understood. I've added this to list of fixes for version 5. What a pain though! It means propagating every call to g_frame_interval upstream until a subdev "that cares" returns ret == 0 or ret != -ENOIOCTLCMD. And that goes for any other chained subdev call as well. I've thought of writing something like a v4l2_chained_subdev_call() macro to do this, but it would be a big macro. > >> +- At driver load time, the device-tree node that is the original source >> + (the "sensor"), is parsed to record its media bus configuration, and >> + this info is required in various subdevs to setup the pipeline. >> + Laurent Pinchart argues that instead the subdev should call its >> + neighbor's g_mbus_config op (which should be propagated if necessary) >> + to get this info. However Hans Verkuil is planning to remove the >> + g_mbus_config op. For now this driver uses the parsed DT mbus config >> + method until this issue is resolved. >> + >> diff --git a/drivers/staging/media/imx/imx-media-dev.c b/drivers/staging/media/imx/imx-media-dev.c >> new file mode 100644 >> index 0000000..e2041ad >> --- /dev/null >> +++ b/drivers/staging/media/imx/imx-media-dev.c > [...] >> +static inline u32 pixfmt_to_colorspace(const struct imx_media_pixfmt *fmt) >> +{ >> + return (fmt->cs == IPUV3_COLORSPACE_RGB) ? >> + V4L2_COLORSPACE_SRGB : V4L2_COLORSPACE_SMPTE170M; >> +} > > This ... > > [...] >> +int imx_media_mbus_fmt_to_pix_fmt(struct v4l2_pix_format *pix, >> + struct v4l2_mbus_framefmt *mbus, >> + const struct imx_media_pixfmt *cc) >> +{ >> + u32 stride; >> + >> + if (!cc) { >> + cc = imx_media_find_format(0, mbus->code, true, false); >> + if (!cc) >> + return -EINVAL; >> + } >> + >> + stride = cc->planar ? mbus->width : (mbus->width * cc->bpp) >> 3; >> + >> + pix->width = mbus->width; >> + pix->height = mbus->height; >> + pix->pixelformat = cc->fourcc; >> + pix->colorspace = pixfmt_to_colorspace(cc); > > ... is not right. The colorspace should be taken from the input pad > colorspace everywhere (except for the IC output pad in the future, once > that supports changing YCbCr encoding and quantization), not guessed > based on the media bus format. Ok, will fix this to assign pix->colorspace to mbus->colorspace, after all the subdevs assign colorspace values to their pads. Steve
Powered by blists - more mailing lists