Re: Time for a v4l-utils 1.12 release

[Hans Verkuil]

On January 16, 2017 8:42:59 PM GMT+01:00, Gregor Jasny  
wrote:
>On 16/01/2017 09:10, Gregor Jasny wrote:
>> I'd like to do a new v4l-utils release before the Debian freeze. Is
>> master in a releasable state? Or should I wait for some more patches
>to
>> land?
>
>Mauro, could you please check the pot files? It looks like they need a
>re-build and translation of some strings.
>
>Thanks,
>Gregor
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media"
>in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at  http://vger.kernel.org/majordomo-info.html

Mauro is on vacation until January 21st.

Regards, 

Hans 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

cron job: media_tree daily build: ERRORS

[Hans Verkuil]

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Jan 17 05:00:16 CET 2017
media-tree git hash:40eca140c404505c09773d1c6685d818cb55ab1a
media_build git hash:   3c6ce4ff75f19adf45869e34b376c5b9dee4d50a
v4l-utils git hash: bc29784e7a3d27f996f7134ad1117985adf103d7
gcc version:i686-linux-gcc (GCC) 6.2.0
sparse version: v0.5.0-3553-g78b2ea6
smatch version: v0.5.0-3553-g78b2ea6
host hardware:  x86_64
host os:4.8.0-164

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-multi: OK
linux-git-arm-pxa: OK
linux-git-blackfin-bf561: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: WARNINGS
linux-3.3.8-i686: WARNINGS
linux-3.4.27-i686: WARNINGS
linux-3.5.7-i686: WARNINGS
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: WARNINGS
linux-3.11.1-i686: OK
linux-3.12.67-i686: OK
linux-3.13.11-i686: WARNINGS
linux-3.14.9-i686: WARNINGS
linux-3.15.2-i686: WARNINGS
linux-3.16.7-i686: WARNINGS
linux-3.17.8-i686: WARNINGS
linux-3.18.7-i686: WARNINGS
linux-3.19-i686: WARNINGS
linux-4.0.9-i686: WARNINGS
linux-4.1.33-i686: WARNINGS
linux-4.2.8-i686: WARNINGS
linux-4.3.6-i686: WARNINGS
linux-4.4.22-i686: WARNINGS
linux-4.5.7-i686: WARNINGS
linux-4.6.7-i686: WARNINGS
linux-4.7.5-i686: WARNINGS
linux-4.8-i686: OK
linux-4.9-i686: OK
linux-4.10-rc3-i686: OK
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: WARNINGS
linux-3.3.8-x86_64: WARNINGS
linux-3.4.27-x86_64: WARNINGS
linux-3.5.7-x86_64: WARNINGS
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: WARNINGS
linux-3.11.1-x86_64: OK
linux-3.12.67-x86_64: OK
linux-3.13.11-x86_64: WARNINGS
linux-3.14.9-x86_64: WARNINGS
linux-3.15.2-x86_64: WARNINGS
linux-3.16.7-x86_64: WARNINGS
linux-3.17.8-x86_64: WARNINGS
linux-3.18.7-x86_64: WARNINGS
linux-3.19-x86_64: WARNINGS
linux-4.0.9-x86_64: WARNINGS
linux-4.1.33-x86_64: WARNINGS
linux-4.2.8-x86_64: WARNINGS
linux-4.3.6-x86_64: WARNINGS
linux-4.4.22-x86_64: WARNINGS
linux-4.5.7-x86_64: WARNINGS
linux-4.6.7-x86_64: WARNINGS
linux-4.7.5-x86_64: WARNINGS
linux-4.8-x86_64: OK
linux-4.9-x86_64: OK
linux-4.10-rc3-x86_64: OK
apps: WARNINGS
spec-git: ERRORS
sparse: WARNINGS

Detailed results are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.log

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/index.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Request API: stateless VPU: the buffer mechanism and DPB management

[Randy Li]

Hello all:
  I have recently finish the learning of the H.264 codec and ready to 
write the driver. Although I have not get deep in syntax of H.264 but I 
think I just need to reuse and extended the VA-API H264 Parser from 
gstreamer. The whole plan in userspace is just injecting a parsing 
operation and set those v4l2 control in kernel before enqueue a buffer 
into OUTPUT, which would keep the most compatible with those stateful 
video IP(those with a firmware).
  But in order to do that, I can't avoid the management of DPB. I 
decided to moving the DPB management job from userspace in kernel. Also 
the video IP(On2 on rk3288 and the transition video IP on those future 
SoC than rk3288, rkv don't have this problem) would a special way to 
manage the DPB, which requests the same reference frame is storing in 
the same reference index in the runtime(actually it is its Motion Vector 
data appended in decoded YUV data would not be moved). I would suggest 
to keep those job in kernel, the userspace just to need update the list0 
and list1 of DPB. DPB is self managed in kernel the userspace don't need 
to even dequeue the buffer from CAPTURE until the re-order is done.
  The kernel driver would also re-order the CAPTURE buffer into display 
order, and blocking the operation on CAPTURE until a buffer is ready to 
place in the very display order. If I don't do that, I have to get the 
buffer once it is decoded, and marking its result with the poc, I could 
only begin the processing of the next frame only after those thing are 
done. Which would effect the performance badly. That is what chromebook 
did(I hear that from the other staff, I didn't get invoke in chromium 
project yet). So I would suggest that doing the re-order job in kernel, 
and inform the the userspace the buffers are ready when the new I 
frame(key frame) is pushed into the video IP.
  Although moving those job into kernel would increase the loading, but 
I think it is worth to do that, but I don't know whether all those 
thought are correct and high performance(It is more important than API 
compatible especially for those 4K video). And I want to know more ideas 
about this topic.
  I would begin the writing the new driver after the coming culture new 
year vacation(I would go to the Europe), I wish we can decide the final 
mechanism before I begin this job.

--
Randy Li
The third produce department

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Request API: stateless VPU: the buffer mechanism and DPB management

[Randy Li]

Hello all:
  I have recently finish the learning of the H.264 codec and ready to 
write the driver. Although I have not get deep in syntax of H.264 but I 
think I just need to reuse and extended the VA-API H264 Parser from 
gstreamer. The whole plan in userspace is just injecting a parsing 
operation and set those v4l2 control in kernel before enqueue a buffer 
into OUTPUT, which would keep the most compatible with those stateful 
video IP(those with a firmware).
  But in order to do that, I can't avoid the management of DPB. I 
decided to moving the DPB management job from userspace in kernel. Also 
the video IP(On2 on rk3288 and the transition video IP on those future 
SoC than rk3288, rkv don't have this problem) would a special way to 
manage the DPB, which requests the same reference frame is storing in 
the same reference index in the runtime(actually it is its Motion Vector 
data appended in decoded YUV data would not be moved). I would suggest 
to keep those job in kernel, the userspace just to need update the list0 
and list1 of DPB. DPB is self managed in kernel the userspace don't need 
to even dequeue the buffer from CAPTURE until the re-order is done.
  The kernel driver would also re-order the CAPTURE buffer into display 
order, and blocking the operation on CAPTURE until a buffer is ready to 
place in the very display order. If I don't do that, I have to get the 
buffer once it is decoded, and marking its result with the poc, I could 
only begin the processing of the next frame only after those thing are 
done. Which would effect the performance badly. That is what chromebook 
did(I hear that from the other staff, I didn't get invoke in chromium 
project yet). So I would suggest that doing the re-order job in kernel, 
and inform the the userspace the buffers are ready when the new I 
frame(key frame) is pushed into the video IP.
  Although moving those job into kernel would increase the loading, but 
I think it is worth to do that, but I don't know whether all those 
thought are correct and high performance(It is more important than API 
compatible especially for those 4K video). And I want to know more ideas 
about this topic.
  I would begin the writing the new driver after the coming culture new 
year vacation(I would go to the Europe), I wish we can decide the final 
mechanism before I begin this job.


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] cxd2820r: fix gpio null pointer dereference

[Antti Palosaari]

Chris and Håkan, test please without Kconfig CONFIG_GPIOLIB option. I 
cannot test it properly as there seems to quite many drivers selecting 
this option by default.


regards
Antti


On 01/17/2017 01:29 AM, Antti Palosaari wrote:

Setting GPIOs during probe causes null pointer deference when
GPIOLIB was not selected by Kconfig. Initialize driver private
field before calling set gpios.

It is regressing bug since 4.9.

Fixes: 07fdf7d9f19f ("[media] cxd2820r: add I2C driver bindings")
Reported-by: Chris Rankin 
Cc:  # v4.9+
Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2820r_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 95267c6..f6ebbb4 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -615,6 +615,7 @@ static int cxd2820r_probe(struct i2c_client *client,
}

priv->client[0] = client;
+   priv->fe.demodulator_priv = priv;
priv->i2c = client->adapter;
priv->ts_mode = pdata->ts_mode;
priv->ts_clk_inv = pdata->ts_clk_inv;
@@ -697,7 +698,6 @@ static int cxd2820r_probe(struct i2c_client *client,
memcpy(>fe.ops, _ops, sizeof(priv->fe.ops));
if (!pdata->attach_in_use)
priv->fe.ops.release = NULL;
-   priv->fe.demodulator_priv = priv;
i2c_set_clientdata(client, priv);

/* Setup callbacks */



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] cxd2820r: fix gpio null pointer dereference

[Antti Palosaari]

Setting GPIOs during probe causes null pointer deference when
GPIOLIB was not selected by Kconfig. Initialize driver private
field before calling set gpios.

It is regressing bug since 4.9.

Fixes: 07fdf7d9f19f ("[media] cxd2820r: add I2C driver bindings")
Reported-by: Chris Rankin 
Cc:  # v4.9+
Signed-off-by: Antti Palosaari 
---
 drivers/media/dvb-frontends/cxd2820r_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 95267c6..f6ebbb4 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -615,6 +615,7 @@ static int cxd2820r_probe(struct i2c_client *client,
}
 
priv->client[0] = client;
+   priv->fe.demodulator_priv = priv;
priv->i2c = client->adapter;
priv->ts_mode = pdata->ts_mode;
priv->ts_clk_inv = pdata->ts_clk_inv;
@@ -697,7 +698,6 @@ static int cxd2820r_probe(struct i2c_client *client,
memcpy(>fe.ops, _ops, sizeof(priv->fe.ops));
if (!pdata->attach_in_use)
priv->fe.ops.release = NULL;
-   priv->fe.demodulator_priv = priv;
i2c_set_clientdata(client, priv);
 
/* Setup callbacks */
-- 
http://palosaari.fi/

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

[Steve Longerbeam]

On 01/16/2017 07:03 AM, Philipp Zabel wrote:

On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:

This is a media entity subdevice for the i.MX Camera
Serial Interface module.

s/Serial/Sensor/


done.


Signed-off-by: Steve Longerbeam 
---
  drivers/staging/media/imx/Kconfig   |  13 +
  drivers/staging/media/imx/Makefile  |   2 +
  drivers/staging/media/imx/imx-csi.c | 644 
  3 files changed, 659 insertions(+)
  create mode 100644 drivers/staging/media/imx/imx-csi.c

diff --git a/drivers/staging/media/imx/Kconfig 
b/drivers/staging/media/imx/Kconfig
index bfde58d..ce2d2c8 100644
--- a/drivers/staging/media/imx/Kconfig
+++ b/drivers/staging/media/imx/Kconfig
@@ -6,3 +6,16 @@ config VIDEO_IMX_MEDIA
  Say yes here to enable support for video4linux media controller
  driver for the i.MX5/6 SOC.
  
+if VIDEO_IMX_MEDIA

+menu "i.MX5/6 Media Sub devices"
+
+config VIDEO_IMX_CAMERA

s/CAMERA/CSI/ ?


done.


+   tristate "i.MX5/6 Camera driver"

i.MX5/6 Camera Sensor Interface driver


done.




+
+struct csi_priv {
+   struct device *dev;
+   struct ipu_soc *ipu;
+   struct imx_media_dev *md;
+   struct v4l2_subdev sd;
+   struct media_pad pad[CSI_NUM_PADS];
+   struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
+   struct v4l2_mbus_config sensor_mbus_cfg;
+   struct v4l2_rect crop;
+   struct ipu_csi *csi;
+   int csi_id;
+   int input_pad;
+   int output_pad;
+   bool power_on;  /* power is on */
+   bool stream_on; /* streaming is on */
+
+   /* the sink for the captured frames */
+   struct v4l2_subdev *sink_sd;
+   enum ipu_csi_dest dest;
+   struct v4l2_subdev *src_sd;

src_sd is not used except that its presence marks an enabled input link.
-> could be changed to bool.


For now I prefer to keep it a pointer to the src/sink subdevs.
At some point the CSI may have some reason to know the
identity of the source.




+   struct v4l2_ctrl_handler ctrl_hdlr;
+   struct imx_media_fim *fim;
+
+   /* the attached sensor at stream on */
+   struct imx_media_subdev *sensor;
+};
+
+static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
+{
+   return container_of(sdev, struct csi_priv, sd);
+}
+
+/* Update the CSI whole sensor and active windows */
+static int csi_setup(struct csi_priv *priv)
+{
+   struct v4l2_mbus_framefmt infmt;
+
+   ipu_csi_set_window(priv->csi, >crop);
+
+   /*
+* the ipu-csi doesn't understand ALTERNATE, but it only
+* needs to know whether the stream is interlaced, so set
+* to INTERLACED if infmt field is ALTERNATE.
+*/
+   infmt = priv->format_mbus[priv->input_pad];
+   if (infmt.field == V4L2_FIELD_ALTERNATE)
+   infmt.field = V4L2_FIELD_INTERLACED;

That should be SEQ_TB/BT depending on video standard.


fixed.


+
+static int csi_s_stream(struct v4l2_subdev *sd, int enable)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   int ret = 0;
+
+   if (!priv->src_sd || !priv->sink_sd)
+   return -EPIPE;
+
+   v4l2_info(sd, "stream %s\n", enable ? "ON" : "OFF");

These could be silenced a bit.


yeah, I think it is time for that. I've silenced all the
v4l2_info()'s for stream on/off, power on/off, as well
as some others.




+static int csi_s_power(struct v4l2_subdev *sd, int on)
+{
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   int ret = 0;
+
+   v4l2_info(sd, "power %s\n", on ? "ON" : "OFF");
+
+   if (priv->fim && on != priv->power_on)
+   ret = imx_media_fim_set_power(priv->fim, on);
+
+   if (!ret)
+   priv->power_on = on;
+   return ret;
+}

Is this called multiple times? I'd expect a poweron during open and a
poweroff during close, so no need for priv->power_on.


It is actually called multiple times. The s_power subdev callbacks are
made every time there is a new link established, in the imx-media core's
link_notify(), in order to re-establish power to the active subdevs in the
new pipeline.

This might change after I look into using v4l2_pipeline_pm_use().




+static int csi_link_setup(struct media_entity *entity,
+ const struct media_pad *local,
+ const struct media_pad *remote, u32 flags)
+{
+   struct v4l2_subdev *sd = media_entity_to_v4l2_subdev(entity);
+   struct csi_priv *priv = v4l2_get_subdevdata(sd);
+   struct v4l2_subdev *remote_sd;
+
+   dev_dbg(priv->dev, "link setup %s -> %s", remote->entity->name,
+   local->entity->name);
+
+   remote_sd = media_entity_to_v4l2_subdev(remote->entity);
+
+   if (local->flags & MEDIA_PAD_FL_SINK) {
+   if (flags & MEDIA_LNK_FL_ENABLED) {
+   if (priv->src_sd)
+   return -EBUSY;
+   priv->src_sd = remote_sd;
+  

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Pavel Machek]

Hi!

> On 16.01.2017 12:10, Sean Young wrote:
> >
> >Have you had a chance to test the ir-rx51 changes?
> >
> >Thanks
> >Sean
> >
> 
> Still no, and afaik there are issues booting n900 with current kernel. Will
> try to find time over the weekend.

v4.10-rc3 (?) works for me on n900. Do you want a working .config?

Best regards,
Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature

Re: Time for a v4l-utils 1.12 release

[Gregor Jasny]

On 16/01/2017 11:06, Sean Young wrote:
> On Mon, Jan 16, 2017 at 09:10:36AM +0100, Gregor Jasny wrote:
>> Hello,
>>
>> I'd like to do a new v4l-utils release before the Debian freeze. Is master
>> in a releasable state? Or should I wait for some more patches to land?
> 
> This pull request is still waiting to be merged.
> 
> https://patchwork.linuxtv.org/patch/38830/

As far as I can tell this looks good. Merged.

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Time for a v4l-utils 1.12 release

[Gregor Jasny]

On 16/01/2017 09:10, Gregor Jasny wrote:
> I'd like to do a new v4l-utils release before the Debian freeze. Is
> master in a releasable state? Or should I wait for some more patches to
> land?

Mauro, could you please check the pot files? It looks like they need a
re-build and translation of some strings.

Thanks,
Gregor
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Time for a v4l-utils 1.12 release

[Gregor Jasny]

On 16/01/2017 12:01, Arnaud Vrac wrote:
> Also, make dist is failing.

Thanks, fixed.


--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Steve Longerbeam]

On 01/16/2017 04:55 AM, Philipp Zabel wrote:

On Fri, 2017-01-13 at 15:04 -0800, Steve Longerbeam wrote:


@@ -299,6 +326,52 @@
pinctrl-names = "default";
pinctrl-0 = <_i2c2>;
status = "okay";
+
+   ov5640: camera@40 {
+   compatible = "ovti,ov5640";
+   pinctrl-names = "default";
+   pinctrl-0 = <_ov5640>;
+   clocks = <_xclk>;
+   clock-names = "xclk";
+   reg = <0x40>;
+   xclk = <2200>;

This is superfluous, you can use clk_get_rate on mipi_xclk.

This property is actually there to tell the driver what to set the
rate to, with clk_set_rate(). So you are saying it would be better
to set the rate in the device tree and the driver should only
retrieve the rate?

Yes. Given that this is a reference clock input that is constant on a
given board and never changes during runtime, I think this is the
correct way. The clock will be fixed rate on most boards, I assume.


Ok, that makes sense, I'll make that change.

Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

[Steve Longerbeam]

On 01/16/2017 04:09 AM, Philipp Zabel wrote:

On Fri, 2017-01-13 at 11:03 -0800, Steve Longerbeam wrote:

On 01/13/2017 03:55 AM, Philipp Zabel wrote:

Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:

Add bindings documentation for the i.MX media driver.

Signed-off-by: Steve Longerbeam 
---
   Documentation/devicetree/bindings/media/imx.txt | 57 
+
   1 file changed, 57 insertions(+)
   create mode 100644 Documentation/devicetree/bindings/media/imx.txt

diff --git a/Documentation/devicetree/bindings/media/imx.txt 
b/Documentation/devicetree/bindings/media/imx.txt
new file mode 100644
index 000..254b64a
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/imx.txt
@@ -0,0 +1,57 @@
+Freescale i.MX Media Video Devices
+
+Video Media Controller node
+---
+
+This is the parent media controller node for video capture support.
+
+Required properties:
+- compatible : "fsl,imx-media";

Would you be opposed to calling this "capture-subsystem" instead of
"imx-media"? We already use "fsl,imx-display-subsystem" and
"fsl,imx-gpu-subsystem" for the display and GPU compound devices.

sure. Some pie-in-the-sky day when DRM and media are unified,
there could be a single device that handles them all,

Indeed :)


  but for now
I'm fine with "fsl,capture-subsystem".

Actually, I meant fsl,imx-capture-subsystem.


right, I caught my error and that is the name chosen.


  fsl,imx-media-subsystem
would be fine, too. Either way, I'll be happy if it looks similar to the
other two.

[...]

This is a clever method to get better frame timestamps. Too bad about
the routing requirements. Can this be used on Nitrogen6X?

Absolutely, this support just needs use of the input-capture channels in the
imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
input capture API, so at this point fsl,input-capture-channel has no effect,
but it does work (tested on SabreAuto).

Nice.

[...]

+Required properties:
+- compatible   : "fsl,imx6-mipi-csi2";

I think this should get an additional "snps,dw-mipi-csi2" compatible,
since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.

right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
Or should wait until the day this subdev is exported for general use, after
pulling out the gasket specifics?

It can be added right away.


ok, I will add.

Steve




+- reg   : physical base address and length of the register set;
+- clocks   : the MIPI CSI-2 receiver requires three clocks: hsi_tx
+  (the DPHY clock), video_27m, and eim_sel;

Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
shared gate bit that gates the HSI clocks as well as the MIPI
"ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
csi-2 core, but we are missing shared gate clocks in the clock tree for
these.

Yes, so many clocks for the MIPI core. Why so many? I would think
there would need to be at most three: a clock for the MIPI CSI-2 core
and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
M-PHY if there is one). I have no clue what all these other clocks are.
But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.

I would imagine the CSI-2 core has a high-speed clock input from the
D-PHY for serial input, an APB clock for register access (ips_clk), and
a pixel clock input for the parallel output (pixel_clk), at least.
The D-PHY will have a PLL reference input (pll_refclk?) and probably its
own register clock (cfg_clk?).

I've looked at the MIPI DSI chapter, and it looks like ac_clk_125m is
used for DSI only.


Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
video_27m seems fine.
But I don't get "dphy".

I presume it's the clock for the D-PHY.


   Which input clock would that correspond to?
"pll_refclk?"

the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.

I think that makes sense.

regards
Philipp



--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Ivaylo Dimitrov]

Hi

On 16.01.2017 12:10, Sean Young wrote:


Have you had a chance to test the ir-rx51 changes?

Thanks
Sean



Still no, and afaik there are issues booting n900 with current kernel. 
Will try to find time over the weekend.


Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 17/24] media: imx: Add CSI subdev driver

[Philipp Zabel]

On Fri, 2017-01-06 at 18:11 -0800, Steve Longerbeam wrote:
> This is a media entity subdevice for the i.MX Camera
> Serial Interface module.

s/Serial/Sensor/

> Signed-off-by: Steve Longerbeam 
> ---
>  drivers/staging/media/imx/Kconfig   |  13 +
>  drivers/staging/media/imx/Makefile  |   2 +
>  drivers/staging/media/imx/imx-csi.c | 644 
> 
>  3 files changed, 659 insertions(+)
>  create mode 100644 drivers/staging/media/imx/imx-csi.c
> 
> diff --git a/drivers/staging/media/imx/Kconfig 
> b/drivers/staging/media/imx/Kconfig
> index bfde58d..ce2d2c8 100644
> --- a/drivers/staging/media/imx/Kconfig
> +++ b/drivers/staging/media/imx/Kconfig
> @@ -6,3 +6,16 @@ config VIDEO_IMX_MEDIA
> Say yes here to enable support for video4linux media controller
> driver for the i.MX5/6 SOC.
>  
> +if VIDEO_IMX_MEDIA
> +menu "i.MX5/6 Media Sub devices"
> +
> +config VIDEO_IMX_CAMERA

s/CAMERA/CSI/ ?

> + tristate "i.MX5/6 Camera driver"

i.MX5/6 Camera Sensor Interface driver

> + depends on VIDEO_IMX_MEDIA && VIDEO_DEV && I2C
> + select VIDEOBUF2_DMA_CONTIG
> + default y
> + ---help---
> +   A video4linux camera capture driver for i.MX5/6.
> +
> +endmenu
> +endif
> diff --git a/drivers/staging/media/imx/Makefile 
> b/drivers/staging/media/imx/Makefile
> index ef9f11b..133672a 100644
> --- a/drivers/staging/media/imx/Makefile
> +++ b/drivers/staging/media/imx/Makefile
> @@ -4,3 +4,5 @@ imx-media-objs := imx-media-dev.o imx-media-fim.o 
> imx-media-internal-sd.o \
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media.o
>  obj-$(CONFIG_VIDEO_IMX_MEDIA) += imx-media-common.o
>  
> +obj-$(CONFIG_VIDEO_IMX_CAMERA) += imx-csi.o
> +
> diff --git a/drivers/staging/media/imx/imx-csi.c 
> b/drivers/staging/media/imx/imx-csi.c
> new file mode 100644
> index 000..64ef862
> --- /dev/null
> +++ b/drivers/staging/media/imx/imx-csi.c
> @@ -0,0 +1,644 @@
> +/*
> + * V4L2 Capture CSI Subdev for Freescale i.MX5/6 SOC
> + *
> + * Copyright (c) 2014-2016 Mentor Graphics Inc.
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include "imx-media.h"
> +
> +#define CSI_NUM_PADS 2
> +
> +struct csi_priv {
> + struct device *dev;
> + struct ipu_soc *ipu;
> + struct imx_media_dev *md;
> + struct v4l2_subdev sd;
> + struct media_pad pad[CSI_NUM_PADS];
> + struct v4l2_mbus_framefmt format_mbus[CSI_NUM_PADS];
> + struct v4l2_mbus_config sensor_mbus_cfg;
> + struct v4l2_rect crop;
> + struct ipu_csi *csi;
> + int csi_id;
> + int input_pad;
> + int output_pad;
> + bool power_on;  /* power is on */
> + bool stream_on; /* streaming is on */
> +
> + /* the sink for the captured frames */
> + struct v4l2_subdev *sink_sd;
> + enum ipu_csi_dest dest;
> + struct v4l2_subdev *src_sd;

src_sd is not used except that its presence marks an enabled input link.
-> could be changed to bool.

> + struct v4l2_ctrl_handler ctrl_hdlr;
> + struct imx_media_fim *fim;
> +
> + /* the attached sensor at stream on */
> + struct imx_media_subdev *sensor;
> +};
> +
> +static inline struct csi_priv *sd_to_dev(struct v4l2_subdev *sdev)
> +{
> + return container_of(sdev, struct csi_priv, sd);
> +}
> +
> +/* Update the CSI whole sensor and active windows */
> +static int csi_setup(struct csi_priv *priv)
> +{
> + struct v4l2_mbus_framefmt infmt;
> +
> + ipu_csi_set_window(priv->csi, >crop);
> +
> + /*
> +  * the ipu-csi doesn't understand ALTERNATE, but it only
> +  * needs to know whether the stream is interlaced, so set
> +  * to INTERLACED if infmt field is ALTERNATE.
> +  */
> + infmt = priv->format_mbus[priv->input_pad];
> + if (infmt.field == V4L2_FIELD_ALTERNATE)
> + infmt.field = V4L2_FIELD_INTERLACED;

That should be SEQ_TB/BT depending on video standard.

> + ipu_csi_init_interface(priv->csi, >sensor_mbus_cfg, );
> +
> + ipu_csi_set_dest(priv->csi, priv->dest);
> +
> + ipu_csi_dump(priv->csi);
> +
> + return 0;
> +}
> +
> +static int csi_start(struct csi_priv *priv)
> +{
> + int ret;
> +
> + if (!priv->sensor) {
> + v4l2_err(>sd, "no sensor attached\n");
> + return -EINVAL;
> + }
> +
> + ret = csi_setup(priv);
> + if (ret)
> + return ret;
> +
> + /* start the frame interval monitor */
> + if (priv->fim) {
> + ret = imx_media_fim_set_stream(priv->fim, priv->sensor, true);
> + if (ret)
> + return ret;
> + }
> +
> + ret = ipu_csi_enable(priv->csi);
> + if (ret) {
> + 

[PATCH 1/4] lib/scatterlist: Fix offset type in sg_alloc_table_from_pages

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Scatterlist entries have an unsigned int for the offset so
correct the sg_alloc_table_from_pages function accordingly.

Since these are offsets withing a page, unsigned int is
wide enough.

Also converts callers which were using unsigned long locally
with the lower_32_bits annotation to make it explicitly
clear what is happening.

v2: Use offset_in_page. (Chris Wilson)

Signed-off-by: Tvrtko Ursulin 
Cc: Masahiro Yamada 
Cc: Pawel Osciak 
Cc: Marek Szyprowski 
Cc: Kyungmin Park 
Cc: Tomasz Stanislawski 
Cc: Matt Porter 
Cc: Alexandre Bounine 
Cc: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org
Acked-by: Marek Szyprowski  (v1)
Reviewed-by: Chris Wilson 
Reviewed-by: Mauro Carvalho Chehab 
---
 drivers/media/v4l2-core/videobuf2-dma-contig.c | 4 ++--
 drivers/rapidio/devices/rio_mport_cdev.c   | 4 ++--
 include/linux/scatterlist.h| 2 +-
 lib/scatterlist.c  | 2 +-
 4 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-dma-contig.c 
b/drivers/media/v4l2-core/videobuf2-dma-contig.c
index fb6a177be461..51e8765bc3c6 100644
--- a/drivers/media/v4l2-core/videobuf2-dma-contig.c
+++ b/drivers/media/v4l2-core/videobuf2-dma-contig.c
@@ -478,7 +478,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
 {
struct vb2_dc_buf *buf;
struct frame_vector *vec;
-   unsigned long offset;
+   unsigned int offset;
int n_pages, i;
int ret = 0;
struct sg_table *sgt;
@@ -506,7 +506,7 @@ static void *vb2_dc_get_userptr(struct device *dev, 
unsigned long vaddr,
buf->dev = dev;
buf->dma_dir = dma_dir;
 
-   offset = vaddr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(vaddr));
vec = vb2_create_framevec(vaddr, size, dma_dir == DMA_FROM_DEVICE);
if (IS_ERR(vec)) {
ret = PTR_ERR(vec);
diff --git a/drivers/rapidio/devices/rio_mport_cdev.c 
b/drivers/rapidio/devices/rio_mport_cdev.c
index 9013a585507e..0fae29ff47ba 100644
--- a/drivers/rapidio/devices/rio_mport_cdev.c
+++ b/drivers/rapidio/devices/rio_mport_cdev.c
@@ -876,10 +876,10 @@ rio_dma_transfer(struct file *filp, u32 transfer_mode,
 * offset within the internal buffer specified by handle parameter.
 */
if (xfer->loc_addr) {
-   unsigned long offset;
+   unsigned int offset;
long pinned;
 
-   offset = (unsigned long)(uintptr_t)xfer->loc_addr & ~PAGE_MASK;
+   offset = lower_32_bits(offset_in_page(xfer->loc_addr));
nr_pages = PAGE_ALIGN(xfer->length + offset) >> PAGE_SHIFT;
 
page_list = kmalloc_array(nr_pages,
diff --git a/include/linux/scatterlist.h b/include/linux/scatterlist.h
index cb3c8fe6acd7..c981bee1a3ae 100644
--- a/include/linux/scatterlist.h
+++ b/include/linux/scatterlist.h
@@ -263,7 +263,7 @@ int __sg_alloc_table(struct sg_table *, unsigned int, 
unsigned int,
 int sg_alloc_table(struct sg_table *, unsigned int, gfp_t);
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask);
 
 size_t sg_copy_buffer(struct scatterlist *sgl, unsigned int nents, void *buf,
diff --git a/lib/scatterlist.c b/lib/scatterlist.c
index 004fc70fc56a..e05e7fc98892 100644
--- a/lib/scatterlist.c
+++ b/lib/scatterlist.c
@@ -391,7 +391,7 @@ EXPORT_SYMBOL(sg_alloc_table);
  */
 int sg_alloc_table_from_pages(struct sg_table *sgt,
struct page **pages, unsigned int n_pages,
-   unsigned long offset, unsigned long size,
+   unsigned int offset, unsigned long size,
gfp_t gfp_mask)
 {
unsigned int chunks;
-- 
2.7.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] [media] ov9650: use msleep() for uncritical long delay

[Nicholas Mc Guire]

ulseep_range() uses hrtimers and provides no advantage over msleep()
for larger delays. Fix up the 25ms delays here to use msleep() and
reduce the load on the hrtimer subsystem.

Link: http://lkml.org/lkml/2017/1/11/377
Signed-off-by: Nicholas Mc Guire <hof...@osadl.org>
---
Problem found by coccinelle script

Patch was compile tested with: x86_64_defconfig + CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_ANALOG_TV_SUPPORT=y, CONFIG_MEDIA_CONTROLLER=y
CONFIG_VIDEO_V4L2_SUBDEV_API=y, CONFIG_MEDIA_SUBDRV_AUTOSELECT=n
CONFIG_VIDEO_OV9650=m

Patch is aginast 4.10-rc3 (localversion-next is next-20170116)

 drivers/media/i2c/ov9650.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/i2c/ov9650.c b/drivers/media/i2c/ov9650.c
index 502c722..2de2fbb 100644
--- a/drivers/media/i2c/ov9650.c
+++ b/drivers/media/i2c/ov9650.c
@@ -522,7 +522,7 @@ static void __ov965x_set_power(struct ov965x *ov965x, int 
on)
if (on) {
ov965x_gpio_set(ov965x->gpios[GPIO_PWDN], 0);
ov965x_gpio_set(ov965x->gpios[GPIO_RST], 0);
-   usleep_range(25000, 26000);
+   msleep(25);
} else {
ov965x_gpio_set(ov965x->gpios[GPIO_RST], 1);
ov965x_gpio_set(ov965x->gpios[GPIO_PWDN], 1);
@@ -1438,7 +1438,7 @@ static int ov965x_detect_sensor(struct v4l2_subdev *sd)
 
mutex_lock(>lock);
__ov965x_set_power(ov965x, 1);
-   usleep_range(25000, 26000);
+   msleep(25);
 
/* Check sensor revision */
ret = ov965x_read(client, REG_PID, );
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 16/24] media: Add i.MX media core driver

[Philipp Zabel]

On Sat, 2017-01-14 at 14:46 -0800, Steve Longerbeam wrote:
[...]
> >> +Unprocessed Video Capture:
> >> +--
> >> +
> >> +Send frames directly from sensor to camera interface, with no
> >> +conversions:
> >> +
> >> +-> ipu_smfc -> camif
> > I'd call this capture interface, this is not just for cameras. Or maybe
> > idmac if you want to mirror hardware names?
> 
> Camif is so named because it is the V4L2 user interface for video
> capture. I suppose it could be named "capif", but that doesn't role
> off the tongue quite as well.

Agreed, capif sounds weird. I find camif a bit confusing though, because
Samsung S3C has a camera interface that is actually called "CAMIF".

> >> +Note the ipu_smfc can do pixel reordering within the same colorspace.
> > That isn't a feature of the SMFC, but of the IDMAC (FCW & FCR).
> 
> yes, the doc is re-worded to make that more clear.
> 
> >> +For example, its sink pad can take UYVY2X8, but its source pad can
> >> +output YUYV2X8.
> > I don't think this is correct. Re-reading "37.4.3.7 Packing to memory"
> > in the CSI chapter, for 8-bit per component data, the internal format
> > between CSI, SMFC, and IDMAC is always some 32-bit RGBx/YUVx variant
> > (or "bayer/generic data"). In either case, the internal format does not
> > change along the way.
> 
> these are pixels in memory buffers, not the IPU internal formats.

As long as we are talking about the CSI -> SMFC -> IDMAC path, these
should be IPU internal formats. How else would one choose between 8-bit
companded RGB, and 16-bit expanded RGB for a 10-bit per component input
signal? This is the same issue as in the next comment.

> >> +   media-ctl -V "\"camif0\":0 [fmt:UYVY2X8/640x480]"
> >> +   media-ctl -V "\"camif0\":1 [fmt:UYVY2X8/640x480]"
> >> +   # Configure pads for OV5640 pipeline
> >> +   media-ctl -V "\"ov5640_mipi 1-0040\":0 [fmt:UYVY2X8/640x480]"
> >> +   media-ctl -V "\"imx-mipi-csi2\":0 [fmt:UYVY2X8/640x480]"
> >> +   media-ctl -V "\"imx-mipi-csi2\":2 [fmt:UYVY2X8/640x480]"
> >> +   media-ctl -V "\"ipu1_csi1\":0 [fmt:UYVY2X8/640x480]"
> >> +   media-ctl -V "\"ipu1_csi1\":1 [fmt:UYVY2X8/640x480]"
> > [...]
> >> +   media-ctl -V "\"camif1\":0 [fmt:UYVY2X8/640x480]"
> > I agree this looks very intuitive, but technically correct for the
> > csi1:1 and camif1:0 pads would be a 32-bit YUV format.
> > (MEDIA_BUS_FMT_YUV8_1X32_PADLO doesn't exist yet).
> >
> > I think it would be better to use the correct format
> 
> I'm not sure I follow you here.

The ov5640 sends UYVY2X8 on the wire, so pads "ov5640_mipi 1-0040":0
up to "ipu1_csi1":0 are correct. But the CSI writes 32-bit YUV values
into the SMFC, so the CSI output pad and the IDMAC input pad should have
a YUV8_1X32 format.

Chapter 37.4.2.3 "FCW & FCR - Format converter write and read" in the
IDMAC chapter states that all internal submodules only work on 8-bit per
component formats with four components: YUVA or RGBA.

> > [...]
> > Is this a whole software buffer queue implementation? I thought the
> > whole point of putting the custom mem2mem framework into the capture
> > driver was to use the hardware FSU channel linking?
> 
>   see below.
> 
> > What is the purpose of this if the sink should be triggered by the FSU?
> 
> Ok, here is where I need to make an admission.
> 
> The only FSU links I have attempted (and which currently have entries
> in the fsu_link_info[] table), are the enc/vf/pp --> IRT links for rotation.

Which are not described as media entity links because the rotation units
do not have separate media entities. So me arguing against handling
mem2mem chaining via media entity links doesn't concern these implicit
links.

> There does not appear to be support in the FSU for linking a write channel
> to the VDIC read channels (8, 9, 10) according to VDI_SRC_SEL field. There
> is support for the direct link from CSI (which I am using), but that's 
> not an
> IDMAC channel link.
> 
> There is a PRP_SRC_SEL field, with linking from IDMAC (SMFC) channels
> 0..2 (and 3? it's not clear, and not clear whether this includes channel 1).

As I read it, that is 0 and 2 only, no idea why. But since there are
only 2 CSIs, that shouldn't be a problem.

> But I think this links to channel 12, and not to channels 8,9,10 to the 
> VDIC.
> Or will it? It's worth experimenting. It would have helped if FSL listed 
> which
> IDMAC channels these FSU links correspond to, instead of making us guess
> at it.

I would have assumed that the FSU triggering only works on 1:1 channels
and the VDIC with its three input channels is different. But then
there's the alleged VDOA link to ch8/9/10 ro ch9, depending on
VDI_MOT_SEL.

This makes me more convinced that the CSI -> VDIC link should only
describe the direct path (real-time mode, single field).

> In any event, the docs are not clear enough to implement a real FSU
> link to the VDIC read channels, if it's even possible. And trying to get
> programming help from FSL can be difficult, and no coding 

em28xx failed with kernel 3.14.79

[em28xx PCTV 520e]

Hi,

I'm using a PCTV 520e usb dvb-c device at an ODROID-C2, running ubuntu 
with kernel 3.14.79. I'd like to use the lates media build drivers. 
However, if I do so, I get the following output with dmesg:


[  132.288365] usb 1-1.1: new high-speed USB device number 4 using dwc_otg
[  133.443178] media: Linux media interface: v0.10
[  133.453273] Linux video capture interface: v2.00
[  133.464065] em28xx 1-1.1:1.0: New device PCTV Systems PCTV 520e @ 480 
Mbps (2013:0251, interface 0, class 0)

[  133.468343] em28xx 1-1.1:1.0: Audio interface 0 found (Vendor Class)
[  133.474549] em28xx 1-1.1:1.0: Video interface 0 found: isoc
[  133.480107] em28xx 1-1.1:1.0: DVB interface 0 found: isoc
[  133.485572] em28xx 1-1.1:1.0: chip ID is em2884
[  133.816085] em28xx 1-1.1:1.0: EEPROM ID = 26 00 03 00, EEPROM hash = 
0x0dff3afa

[  133.816096] em28xx 1-1.1:1.0: EEPROM info:
[  133.816102] em28xx 1-1.1:1.0:microcode start address = 
0x0004, boot configuration = 0x03

[  133.825210] em28xx 1-1.1:1.0:I2S audio, 5 sample rates
[  133.825223] em28xx 1-1.1:1.0:500mA max power
[  133.825229] em28xx 1-1.1:1.0:Table at offset 0x39, 
strings=0x1aa0, 0x14ba, 0x1ace
[  133.825467] em28xx 1-1.1:1.0: Identified as PCTV QuatroStick nano 
(520e) (card=86)
[  133.825474] em28xx 1-1.1:1.0: Currently, V4L2 is not supported on 
this model

[  133.826871] em28xx 1-1.1:1.0: dvb set to isoc mode.
[  133.831978] usbcore: registered new interface driver em28xx
[  133.839161] em28xx 1-1.1:1.0: Binding audio extension
[  133.839175] em28xx 1-1.1:1.0: em28xx-audio.c: Copyright (C) 2006 
Markus Rechberger
[  133.839180] em28xx 1-1.1:1.0: em28xx-audio.c: Copyright (C) 2007-2016 
Mauro Carvalho Chehab
[  133.839238] em28xx 1-1.1:1.0: Endpoint 0x83 high-speed on intf 0 alt 
7 interval = 8, size 196
[  133.839243] em28xx 1-1.1:1.0: Number of URBs: 1, with 64 packets and 
192 size

[  133.839582] em28xx 1-1.1:1.0: Audio extension successfully initialized
[  133.839592] em28xx: Registered (Em28xx Audio Extension) extension
[  133.850876] WARNING: You are using an experimental version of the 
media stack.
As the driver is backported to an older kernel, it 
doesn't offer

enough quality for its usage in production.
Use it with care.
   Latest git patches (needed if you report a bug to 
linux-media@vger.kernel.org):
40eca140c404505c09773d1c6685d818cb55ab1a [media] 
mn88473: add DVB-T2 PLP support
bd361f5de2b338218c276d17a510701a16075deb Merge tag 
'v4.10-rc1' into patchwork

7ce7d89f48834cefece7804d38fc5d85382edf77 Linux 4.10-rc1
[  133.904216] em28xx: Registered (Em28xx dvb Extension) extension
[  133.913570] em28xx 1-1.1:1.0: Registering input extension
[  133.918431] em28xx 1-1.1:1.0: submit of audio urb failed (error=-90)
[  133.947980] Registered IR keymap rc-pinnacle-pctv-hd
[  133.948248] input: 1-1.1:1.0 IR as 
/devices/platform/dwc2_b/usb1/1-1/1-1.1/1-1.1:1.0/rc/rc0/input4
[  133.948451] rc rc0: 1-1.1:1.0 IR as 
/devices/platform/dwc2_b/usb1/1-1/1-1.1/1-1.1:1.0/rc/rc0

[  133.948860] em28xx 1-1.1:1.0: Input extension successfully initalized
[  133.948866] em28xx: Registered (Em28xx Input Extension) extension

Finally, there is no /dev/dvb/... created. I guess because of the

  [  133.918431] em28xx 1-1.1:1.0: submit of audio urb failed (error=-90)

message.

Can any1 help me with this?

regards

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 06/24] ARM: dts: imx6-sabrelite: add OV5642 and OV5640 camera sensors

[Philipp Zabel]

On Fri, 2017-01-13 at 15:04 -0800, Steve Longerbeam wrote:
>
> On 01/13/2017 04:03 AM, Philipp Zabel wrote:
> > Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> >> Enables the OV5642 parallel-bus sensor, and the OV5640 MIPI CSI-2 sensor.
> >> Both hang off the same i2c2 bus, so they require different (and non-
> >> default) i2c slave addresses.
> >>
> >> The OV5642 connects to the parallel-bus mux input port on ipu1_csi0_mux.
> >>
> >> The OV5640 connects to the input port on the MIPI CSI-2 receiver on
> >> mipi_csi. It is set to transmit over MIPI virtual channel 1.
> >>
> >> Signed-off-by: Steve Longerbeam 
> >> ---
> >>   arch/arm/boot/dts/imx6dl-sabrelite.dts   |   5 ++
> >>   arch/arm/boot/dts/imx6q-sabrelite.dts|   6 ++
> >>   arch/arm/boot/dts/imx6qdl-sabrelite.dtsi | 118 
> >> +++
> >>   3 files changed, 129 insertions(+)
> >>
> >> diff --git a/arch/arm/boot/dts/imx6dl-sabrelite.dts 
> >> b/arch/arm/boot/dts/imx6dl-sabrelite.dts
> >> index 0f06ca5..fec2524 100644
> >> --- a/arch/arm/boot/dts/imx6dl-sabrelite.dts
> >> +++ b/arch/arm/boot/dts/imx6dl-sabrelite.dts
[...]
> >> @@ -299,6 +326,52 @@
> >>pinctrl-names = "default";
> >>pinctrl-0 = <_i2c2>;
> >>status = "okay";
> >> +
> >> +  ov5640: camera@40 {
> >> +  compatible = "ovti,ov5640";
> >> +  pinctrl-names = "default";
> >> +  pinctrl-0 = <_ov5640>;
> >> +  clocks = <_xclk>;
> >> +  clock-names = "xclk";
> >> +  reg = <0x40>;
> >> +  xclk = <2200>;
> > This is superfluous, you can use clk_get_rate on mipi_xclk.
> 
> This property is actually there to tell the driver what to set the
> rate to, with clk_set_rate(). So you are saying it would be better
> to set the rate in the device tree and the driver should only
> retrieve the rate?

Yes. Given that this is a reference clock input that is constant on a
given board and never changes during runtime, I think this is the
correct way. The clock will be fixed rate on most boards, I assume.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v3 01/24] [media] dt-bindings: Add bindings for i.MX media driver

[Philipp Zabel]

On Fri, 2017-01-13 at 11:03 -0800, Steve Longerbeam wrote:
> 
> On 01/13/2017 03:55 AM, Philipp Zabel wrote:
> > Am Freitag, den 06.01.2017, 18:11 -0800 schrieb Steve Longerbeam:
> >> Add bindings documentation for the i.MX media driver.
> >>
> >> Signed-off-by: Steve Longerbeam 
> >> ---
> >>   Documentation/devicetree/bindings/media/imx.txt | 57 
> >> +
> >>   1 file changed, 57 insertions(+)
> >>   create mode 100644 Documentation/devicetree/bindings/media/imx.txt
> >>
> >> diff --git a/Documentation/devicetree/bindings/media/imx.txt 
> >> b/Documentation/devicetree/bindings/media/imx.txt
> >> new file mode 100644
> >> index 000..254b64a
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/imx.txt
> >> @@ -0,0 +1,57 @@
> >> +Freescale i.MX Media Video Devices
> >> +
> >> +Video Media Controller node
> >> +---
> >> +
> >> +This is the parent media controller node for video capture support.
> >> +
> >> +Required properties:
> >> +- compatible : "fsl,imx-media";
> > Would you be opposed to calling this "capture-subsystem" instead of
> > "imx-media"? We already use "fsl,imx-display-subsystem" and
> > "fsl,imx-gpu-subsystem" for the display and GPU compound devices.
> 
> sure. Some pie-in-the-sky day when DRM and media are unified,
> there could be a single device that handles them all,

Indeed :)

>  but for now
> I'm fine with "fsl,capture-subsystem".

Actually, I meant fsl,imx-capture-subsystem. fsl,imx-media-subsystem
would be fine, too. Either way, I'll be happy if it looks similar to the
other two.

[...]
> > This is a clever method to get better frame timestamps. Too bad about
> > the routing requirements. Can this be used on Nitrogen6X?
> 
> Absolutely, this support just needs use of the input-capture channels in the
> imx GPT. I still need to submit the patch to the imx-gpt driver that adds an
> input capture API, so at this point fsl,input-capture-channel has no effect,
> but it does work (tested on SabreAuto).

Nice.

[...]
> >> +Required properties:
> >> +- compatible  : "fsl,imx6-mipi-csi2";
> > I think this should get an additional "snps,dw-mipi-csi2" compatible,
> > since the only i.MX6 specific part is the bolted-on IPU2CSI gasket.
> 
> right, minus the gasket it's a Synopsys core. I'll add that compatible flag.
> Or should wait until the day this subdev is exported for general use, after
> pulling out the gasket specifics?

It can be added right away.

> >> +- reg   : physical base address and length of the register set;
> >> +- clocks  : the MIPI CSI-2 receiver requires three clocks: hsi_tx
> >> +  (the DPHY clock), video_27m, and eim_sel;
> > Note that hsi_tx is incorrectly named. CCGR3[CG8] just happens to be the
> > shared gate bit that gates the HSI clocks as well as the MIPI
> > "ac_clk_125m", "cfg_clk", "ips_clk", and "pll_refclk" inputs to the mipi
> > csi-2 core, but we are missing shared gate clocks in the clock tree for
> > these.
> 
> Yes, so many clocks for the MIPI core. Why so many? I would think
> there would need to be at most three: a clock for the MIPI CSI-2 core
> and HSI core, and a clock for the D-PHY (oh and maybe a clock for an
> M-PHY if there is one). I have no clue what all these other clocks are.
> But anyway, a single gating bit, CCGR3[CG8], seems to enable them all.

I would imagine the CSI-2 core has a high-speed clock input from the
D-PHY for serial input, an APB clock for register access (ips_clk), and
a pixel clock input for the parallel output (pixel_clk), at least.
The D-PHY will have a PLL reference input (pll_refclk?) and probably its
own register clock (cfg_clk?).

I've looked at the MIPI DSI chapter, and it looks like ac_clk_125m is
used for DSI only.

> > Both cfg_clk and pll_refclk are sourced from video_27m, so "cfg" ->
> > video_27m seems fine.
> > But I don't get "dphy".
> 
> I presume it's the clock for the D-PHY.
>
> >   Which input clock would that correspond to?
> > "pll_refclk?"
> 
> the mux at CDCDR says it comes from PLL3_120M, or PLL2_PFD2.

I think that makes sense.

regards
Philipp

--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 00/21] Basic i.MX IPUv3 capture support

[Philipp Zabel]

Hi Steve,

On Sat, 2017-01-14 at 12:26 -0800, Steve Longerbeam wrote:
> 
> On 01/13/2017 03:05 AM, Philipp Zabel wrote:
> > Hi Steve,
> >
> > Am Donnerstag, den 12.01.2017, 15:22 -0800 schrieb Steve Longerbeam:
[...]
> >>   I would
> >> imagine it will need two additional inputs and another output to support
> >> the Combiner (two pads for each plane to be combined, and a combiner
> >> output pad).
> > If I accept for a moment that IDMAC/FSU channel links are described as
> > media entity links, that would be right, I guess.
> 
> Hi Philipp,
> 
> Let me start by asking, why you are averse to the idea that a media
> driver passes video frames from source to sink using memory
> buffers? There is no hard-and-fast rule in the media framework that
> states this should not be done, AFAIK.

To help you understand my perspective, I mostly use v4l2 devices in
GStreamer pipelines. That means, chaining separate mem2mem devices into
a pipeline that passes dma-bufs around is the easy default. I consider
linking mem2mem devices in the kernel (so buffers don't have to be
dequeued/queued into userspace all the time) or even in hardware (the
FSU basically implements hardware fences on a free-running rigid
2-buffer queue between two DMA channels) to be two performance
optimization steps from there.

Step 1 of linking two mem2mem devices using a software buffer queue
could be achieved at the videobuf2 level. That would need a new API to
share DMA buffers between vb2 queues and then switch them into a free
running mode that allows the kernel to pass buffers back and forth
automatically. But that mechanism would not be specific to hardware at
all. It could reuse / extend upon the existing vb2 queue implementation,
and it would be possible to use it with any driver instead of only IPU
internal components. In case of i.MX6 we could link the CODA h.264
encoder input to the PRPENC output, for example.
Also I'm opposed to adding a custom mem2mem framework in the IPU driver
because I don't believe the IPU is the only hardware unit that has
processing paths that need to go through temporary memory copies. Adding
the same functionality for every driver that can do this in a slightly
different way doesn't scale.

Step 2 of providing a fixed double-buffer queue and then using the IPU
FSU to trigger the DMA read channels in hardware instead of from the
write channel EOF interrupt handler is quite a bit more hardware
specific, but even there, it could be that the FSU links are not limited
to the IPU. I'm not sure if this actually works, but according to the
reference manual the (CODA) VPU can be triggered by the write channels
from SMFC and PRPVF and the VDOA can trigger the VDI or PP read channels
on i.MX6.

I do feel a bit bad about arguing against an existing working solution
when I only have a rough idea how I'd like steps 1 and 2 to look like,
but I really think implementing this inside a single driver via media
entity links is not the right way, and I fear once established, we'd
never get rid of it.

> I agree this overlaps with the mem2mem device idea somewhat, but
> IMHO a media device should be allowed to use internal memory
> buffers to pass video frames between pads, if that's what it needs to
> do to implement some functionality.
> 
> Can anyone else listening on this thread, chime in on this topic?

Yes, that would be very welcome.

> >>> Is there even a reason for the user to switch between direct and via
> >>> memory paths manually, or could this be inferred from other state
> >>> (formats, active links)?
> >> a CSI -> VDIC link doesn't convey whether that is a direct link using
> >> the FSU, or whether it is via SMFC and memory buffers.
> >>
> >> If you'll recall, the VDIC has three motion modes: low, medium, and
> >> high.
> >>
> >> When VDIC receives directly from CSI, it can only operate in
> >> high motion mode (it processes a single field F(n-1) sent directly
> >> from the CSI using the FSU). The reference manual refers to this
> >> as "real time mode".
> > In my opinion this is the only mode that should be supported in the
> > capture driver.
> 
> I have to disagree on that.

There isn't even hardware assisted triggering of the VDIC inputs for
deinterlacing in those modes, so there's really no performance benefit
over vb2 queue linking, and that would be a lot more useful.

> >   But that may be wishful thinking to a certain degree -
> > see below.
> >
> >> The low and medium motion modes require processing all three
> >> fields F(n-1), F(n), and F(n+1). These fields must come from IDMAC
> >> channels 8, 9, and 10 respectively.
> >>
> >> So in order to support low and medium motion modes, there needs to
> >> be a pipeline where the VDIC receives F(n-1), F(n), and F(n+1) from
> >> memory buffers.
> > In the cases where the VDIC reads all three fields from memory, I'd
> > prefer that to be implemented as a separate mem2mem device.
>
> I prefer that there be a single VDIC media entity, that makes use of its
> dma read 

Re: Time for a v4l-utils 1.12 release

[Hans Verkuil]

On January 16, 2017 9:10:36 AM GMT+01:00, Gregor Jasny  
wrote:
>Hello,
>
>I'd like to do a new v4l-utils release before the Debian freeze. Is 
>master in a releasable state? Or should I wait for some more patches to
>
>land?
>
>Thanks,
>Gregor

Hi Gregor,

I  have  nothing pending.

Regards, 

Hans 
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH V2] Staging: media: bcm2048: style fix - bare use of unsigned

[Greg KH]

On Mon, Jan 16, 2017 at 08:09:51PM +1300, Derek Robson wrote:
> Changed macro to not pass signedness and size as seprate fields.
> This is to improve code readablity.

Not really, it reads just fine as is.  In fact, it forces you to think
about the signed vs. unsigned of the variable and doesn't let you forget
it, which seems to be the intention of the code as-is.

So I would recommend just leaving it alone.

Remember, checkpatch is a hint, you always have to use your brain when
making kernel changes, and always test-build them :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] Staging: media: bcm2048: style fix - bare use of unsigned

[Greg KH]

On Mon, Jan 16, 2017 at 06:06:25PM +1300, Derek Robson wrote:
> On Sun, Jan 15, 2017 at 10:40:02PM -0600, Scott Matheina wrote:
> > 
> > 
> > > On Jan 15, 2017, at 10:30 PM, Derek Robson  wrote:
> > > 
> > > Changed bare use of 'unsigned' to the prefered us of 'unsigned int'
> > > found using checkpatch
> > 
> > Just wondering if you compiled? This patch looks exactly like a patch I 
> > tried, but it didn't compile. 
> > 
> 
> It complied for me, I am on an X86 system.

I don't believe you, and kbuild backs that up  :)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/5] [media] ir-rx51: port to rc-core

[Sean Young]

Hi Ivo,

On Fri, Dec 30, 2016 at 03:50:42PM +0200, Ivaylo Dimitrov wrote:
> On 30.12.2016 15:30, Sean Young wrote:
> >
> >On Fri, Dec 30, 2016 at 01:07:52PM +, Sean Young wrote:
> >>Hi Ivo,,
> >>
> >>On Fri, Dec 30, 2016 at 01:30:01PM +0200, Ivaylo Dimitrov wrote:
> >>>On 20.12.2016 19:50, Sean Young wrote:
> This driver was written using lirc since rc-core did not support
> transmitter-only hardware at that time. Now that it does, port
> this driver.
> 
> Compile tested only.
> 
> >>>
> >>>I guess after that change, there will be no more /dev/lircN device, right?
> >>>Neither will LIRC_XXX IOCTL codes be supported?
> >>
> >>Quite the opposite, /dev/lircN and all the LIRC_XXX ioctls will still be
> >>supported through ir-lirc-codec.c.
> >>
> >>By using rc-core, the driver will be more succinct, and some latent bugs
> >>will be fixed. For example, at the moment it is possible to write hours
> >>of IR data and keep the n900 from suspending.
> >>
> >>I'm working on lirc scancode sending and receiving using the IR encoders,
> >>and when that is in place, any rc-core driver will get it for free.
> >>
> >>>That looks to me as a completely new driver, not a port to new API.
> >>>
> >>>Right now there are applications using the current behaviour (pierogi for
> >>>example), which will be broken by the change.
> >>
> >>Nothing should break.
> >
> >Speaking of which, if you would please test this, that would be great. My
> >N900 died many years ago.
> >
> 
> Will do, but next year :) .

Have you had a chance to test the ir-rx51 changes?

Thanks
Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Time for a v4l-utils 1.12 release

[Sean Young]

Hi,

On Mon, Jan 16, 2017 at 09:10:36AM +0100, Gregor Jasny wrote:
> Hello,
> 
> I'd like to do a new v4l-utils release before the Debian freeze. Is master
> in a releasable state? Or should I wait for some more patches to land?

This pull request is still waiting to be merged.

https://patchwork.linuxtv.org/patch/38830/

Thanks

Sean
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] v4l: subdev: Clean up properly in subdev devnode registration error path

[Sakari Ailus]

Hi Laurent,

On Sun, Jan 15, 2017 at 09:05:30PM +0200, Laurent Pinchart wrote:
> Set the subdev devnode pointer right after registration to ensure that
> later errors won't skip the subdev when unregistering all devnodes.
> 
> Signed-off-by: Laurent Pinchart 

Acked-by: Sakari Ailus 

-- 
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Time for a v4l-utils 1.12 release

[Gregor Jasny]

Hello,

I'd like to do a new v4l-utils release before the Debian freeze. Is 
master in a releasable state? Or should I wait for some more patches to 
land?


Thanks,
Gregor
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html