Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-17 Thread Philipp Zabel
On Thu, 2017-02-16 at 17:33 -0800, Steve Longerbeam wrote:
> 
> On 02/16/2017 05:02 AM, Philipp Zabel wrote:
> > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> 
> >> +
> >> +- 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.

Ok, thanks.

> >> +- 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.

Not at all. Since the frame interval is a property of the pad, that had
to be propagated downstream by media-ctl along with media bus format,
frame size, and colorimetry earlier.

regards
Philipp



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-17 Thread Philipp Zabel
On Thu, 2017-02-16 at 17:33 -0800, Steve Longerbeam wrote:
> 
> On 02/16/2017 05:02 AM, Philipp Zabel wrote:
> > On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> 
> >> +
> >> +- 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.

Ok, thanks.

> >> +- 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.

Not at all. Since the frame interval is a property of the pad, that had
to be propagated downstream by media-ctl along with media bus format,
frame size, and colorimetry earlier.

regards
Philipp



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Steve Longerbeam



On 02/16/2017 05:02 AM, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:



+
+- 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 000..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



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Steve Longerbeam



On 02/16/2017 05:02 AM, Philipp Zabel wrote:

On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:



+
+- 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 000..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



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Steve Longerbeam



On 02/16/2017 02:27 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:

Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.


Missed these obviously, fixed.

Steve



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Steve Longerbeam



On 02/16/2017 02:27 AM, Russell King - ARM Linux wrote:

On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:

Add the core media driver for i.MX SOC.

Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.


Missed these obviously, fixed.

Steve



Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Russell King - ARM Linux
On Thu, Feb 16, 2017 at 02:02:03PM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > +- imx-csi subdev is not being autoloaded as a kernel module, probably
> > +  because ipu_add_client_devices() does not register the IPU client
> > +  platform devices, but only allocates those devices.
> 
> As Russell points out, this is an issue with the ipu-v3 driver, which
> needs to be fixed to stop setting the ipu client devices' dev->of_node
> field.

>From my local testing (albiet the shambles that is bits of v4l2) setting
dev->of_node is not necessary for imx-drm - imx-drm comes up fine without.

Fixing _this_ code for that is not too difficult - it's a matter of:

priv->sd.of_node = pdata->of_node;

in imx_csi_probe().  However, the difficult bit is the poor state of
code in v4l2, particularly the v4l2-async crap.  Right now, fixing the
module autoloading will oops the kernel, so it's best that module
autoloading remains broken for the time being.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Russell King - ARM Linux
On Thu, Feb 16, 2017 at 02:02:03PM +0100, Philipp Zabel wrote:
> On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> > +- imx-csi subdev is not being autoloaded as a kernel module, probably
> > +  because ipu_add_client_devices() does not register the IPU client
> > +  platform devices, but only allocates those devices.
> 
> As Russell points out, this is an issue with the ipu-v3 driver, which
> needs to be fixed to stop setting the ipu client devices' dev->of_node
> field.

>From my local testing (albiet the shambles that is bits of v4l2) setting
dev->of_node is not necessary for imx-drm - imx-drm comes up fine without.

Fixing _this_ code for that is not too difficult - it's a matter of:

priv->sd.of_node = pdata->of_node;

in imx_csi_probe().  However, the difficult bit is the poor state of
code in v4l2, particularly the v4l2-async crap.  Right now, fixing the
module autoloading will oops the kernel, so it's best that module
autoloading remains broken for the time being.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Philipp Zabel
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/v4l-drivers/imx.rst   | 542 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/imx/Kconfig |   7 +
>  drivers/staging/media/imx/Makefile|   6 +
>  drivers/staging/media/imx/TODO|  36 ++
>  drivers/staging/media/imx/imx-media-dev.c | 487 +++
>  drivers/staging/media/imx/imx-media-fim.c | 471 +++
>  drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++
>  drivers/staging/media/imx/imx-media-of.c  | 267 
>  drivers/staging/media/imx/imx-media-utils.c   | 701 
> ++
>  drivers/staging/media/imx/imx-media.h | 297 +
>  include/media/imx.h   |  15 +
>  include/uapi/linux/v4l2-controls.h|   4 +
>  14 files changed, 3185 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/imx.rst
>  create mode 100644 drivers/staging/media/imx/Kconfig
>  create mode 100644 drivers/staging/media/imx/Makefile
>  create mode 100644 drivers/staging/media/imx/TODO
>  create mode 100644 drivers/staging/media/imx/imx-media-dev.c
>  create mode 100644 drivers/staging/media/imx/imx-media-fim.c
>  create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
>  create mode 100644 drivers/staging/media/imx/imx-media-of.c
>  create mode 100644 drivers/staging/media/imx/imx-media-utils.c
>  create mode 100644 drivers/staging/media/imx/imx-media.h
>  create mode 100644 include/media/imx.h
> 
> diff --git a/Documentation/media/v4l-drivers/imx.rst 
> b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 000..f085e43
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,542 @@
> +i.MX Video Capture Driver
> +=
> +
> +Introduction
> +
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlacing or Combining Block (VDIC)
> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths. During transfer, the IDMAC is also capable of vertical
> +image flip, 8x8 block transfer (see IRT description), pixel component
> +re-ordering (for example UYVY to YUYV) within the same colorspace, and
> +even packed <--> planar conversion. It can also perform a simple
> +de-interlacing by interleaving even and odd lines during transfer
> +(without motion compensation which requires the VDIC).
> +
> +The CSI is the backend capture unit that interfaces directly with
> +camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing (downscaling and
> +upscaling), horizontal flip, and 90/270 degree rotation operations.
> +
> +There are three independent "tasks" within the IC that can carry out
> +conversions concurrently: pre-process encoding, pre-process viewfinder,
> +and post-processing. Within each task, conversions are split into three
> +sections: downsizing section, main section (upsizing, flip, colorspace
> +conversion, and graphics plane combining), and rotation section.
> +
> +The IPU time-shares the IC task operations. The time-slice granularity
> +is one burst of eight pixels in the downsizing section, one image line
> +in the main processing section, one image frame in the rotation section.
> +
> +The SMFC is composed of four independent FIFOs that each can transfer
> +captured frames from sensors directly to memory concurrently via four
> +IDMAC channels.
> +
> +The IRT carries out 90 and 270 degree image rotation operations. The
> +rotation operation is carried out on 8x8 pixel blocks at a time. This
> +operation is supported by the IDMAC which handles the 8x8 block transfer
> +along with block reordering, in coordination with vertical flip.
> +
> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process viewfinder task for further conversions. The VDIC also
> +contains a Combiner that combines two image planes, with alpha blending
> +and color keying.
> +
> +In addition to the IPU internal subunits, there are also two units
> 

Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Philipp Zabel
On Wed, 2017-02-15 at 18:19 -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 
> ---
>  Documentation/media/v4l-drivers/imx.rst   | 542 +
>  drivers/staging/media/Kconfig |   2 +
>  drivers/staging/media/Makefile|   1 +
>  drivers/staging/media/imx/Kconfig |   7 +
>  drivers/staging/media/imx/Makefile|   6 +
>  drivers/staging/media/imx/TODO|  36 ++
>  drivers/staging/media/imx/imx-media-dev.c | 487 +++
>  drivers/staging/media/imx/imx-media-fim.c | 471 +++
>  drivers/staging/media/imx/imx-media-internal-sd.c | 349 +++
>  drivers/staging/media/imx/imx-media-of.c  | 267 
>  drivers/staging/media/imx/imx-media-utils.c   | 701 
> ++
>  drivers/staging/media/imx/imx-media.h | 297 +
>  include/media/imx.h   |  15 +
>  include/uapi/linux/v4l2-controls.h|   4 +
>  14 files changed, 3185 insertions(+)
>  create mode 100644 Documentation/media/v4l-drivers/imx.rst
>  create mode 100644 drivers/staging/media/imx/Kconfig
>  create mode 100644 drivers/staging/media/imx/Makefile
>  create mode 100644 drivers/staging/media/imx/TODO
>  create mode 100644 drivers/staging/media/imx/imx-media-dev.c
>  create mode 100644 drivers/staging/media/imx/imx-media-fim.c
>  create mode 100644 drivers/staging/media/imx/imx-media-internal-sd.c
>  create mode 100644 drivers/staging/media/imx/imx-media-of.c
>  create mode 100644 drivers/staging/media/imx/imx-media-utils.c
>  create mode 100644 drivers/staging/media/imx/imx-media.h
>  create mode 100644 include/media/imx.h
> 
> diff --git a/Documentation/media/v4l-drivers/imx.rst 
> b/Documentation/media/v4l-drivers/imx.rst
> new file mode 100644
> index 000..f085e43
> --- /dev/null
> +++ b/Documentation/media/v4l-drivers/imx.rst
> @@ -0,0 +1,542 @@
> +i.MX Video Capture Driver
> +=
> +
> +Introduction
> +
> +
> +The Freescale i.MX5/6 contains an Image Processing Unit (IPU), which
> +handles the flow of image frames to and from capture devices and
> +display devices.
> +
> +For image capture, the IPU contains the following internal subunits:
> +
> +- Image DMA Controller (IDMAC)
> +- Camera Serial Interface (CSI)
> +- Image Converter (IC)
> +- Sensor Multi-FIFO Controller (SMFC)
> +- Image Rotator (IRT)
> +- Video De-Interlacing or Combining Block (VDIC)
> +
> +The IDMAC is the DMA controller for transfer of image frames to and from
> +memory. Various dedicated DMA channels exist for both video capture and
> +display paths. During transfer, the IDMAC is also capable of vertical
> +image flip, 8x8 block transfer (see IRT description), pixel component
> +re-ordering (for example UYVY to YUYV) within the same colorspace, and
> +even packed <--> planar conversion. It can also perform a simple
> +de-interlacing by interleaving even and odd lines during transfer
> +(without motion compensation which requires the VDIC).
> +
> +The CSI is the backend capture unit that interfaces directly with
> +camera sensors over Parallel, BT.656/1120, and MIPI CSI-2 busses.
> +
> +The IC handles color-space conversion, resizing (downscaling and
> +upscaling), horizontal flip, and 90/270 degree rotation operations.
> +
> +There are three independent "tasks" within the IC that can carry out
> +conversions concurrently: pre-process encoding, pre-process viewfinder,
> +and post-processing. Within each task, conversions are split into three
> +sections: downsizing section, main section (upsizing, flip, colorspace
> +conversion, and graphics plane combining), and rotation section.
> +
> +The IPU time-shares the IC task operations. The time-slice granularity
> +is one burst of eight pixels in the downsizing section, one image line
> +in the main processing section, one image frame in the rotation section.
> +
> +The SMFC is composed of four independent FIFOs that each can transfer
> +captured frames from sensors directly to memory concurrently via four
> +IDMAC channels.
> +
> +The IRT carries out 90 and 270 degree image rotation operations. The
> +rotation operation is carried out on 8x8 pixel blocks at a time. This
> +operation is supported by the IDMAC which handles the 8x8 block transfer
> +along with block reordering, in coordination with vertical flip.
> +
> +The VDIC handles the conversion of interlaced video to progressive, with
> +support for different motion compensation modes (low, medium, and high
> +motion). The deinterlaced output frames from the VDIC can be sent to the
> +IC pre-process viewfinder task for further conversions. The VDIC also
> +contains a Combiner that combines two image planes, with alpha blending
> +and color keying.
> +
> +In addition to the IPU internal subunits, there are also two units
> +outside the IPU that are also 

Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Russell King - ARM Linux
On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.


Re: [PATCH v4 18/36] media: Add i.MX media core driver

2017-02-16 Thread Russell King - ARM Linux
On Wed, Feb 15, 2017 at 06:19:20PM -0800, Steve Longerbeam wrote:
> Add the core media driver for i.MX SOC.
> 
> Signed-off-by: Steve Longerbeam 

Just as I reported on the 30th January:

Applying: media: Add i.MX media core driver
.git/rebase-apply/patch:614: new blank line at EOF.
+
.git/rebase-apply/patch:626: new blank line at EOF.
+
.git/rebase-apply/patch:668: new blank line at EOF.
+

These need fixing.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.