Re: [PATCH v2 10/10] media: imx.rst: Update doc to reflect fixes to interlaced capture
Steve Longerbeam writes: > Hmm, if the sink is 'alternate', and the requested source is > 'interlaced*', perhaps we should allow the source to be > 'interlaced*' and not override it. For example, if requested > is 'interlaced-tb', let it be that. IOW assume user knows something > we don't about the original field order, or is experimenting > with finding the correct field order. Yes, this is clearly possible. In fact the analog signal doesn't carry information about the field order (if any). The video editing/encoding software does motion estimation for this, and there is no other way (given that the video material can change from progressive to interlaced and vice versa, and probably can change the field order, at any time). -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH v2 04/10] media: imx: interweave only for sequential input/interlaced output fields
Philipp Zabel writes: > This is ok in this patch, but we can't use this check in the following > TRY_FMT patch as there is no way to interweave > SEQ_TB -> INTERLACED_BT (because in SEQ_TB the B field is newer than T, > but in INTERLACED_BT it has to be older) or SEQ_BT -> INTERLACED_TB (the > other way around). Actually we can do SEQ_TB -> INTERLACED_BT and SEQ_BT -> INTERLACED_TB rather easily. We only need to skip a single field at start :-) That's what CCIR_CODE_* registers do. To be honest, SEQ_TB and SEQ_BT are precisely the same thing (i.e., SEQUENTIAL). It's up to the user to say which field is the first. There is the progressive sensor exception, though, and the TB/BT could be a hint for downstream elements (i.e., setting the default field order). But I think we should be able to request INTERLACED_TB or INTERLACED_BT (with any analog signal on input) and the CCIR_CODE registers should be set accordingly. This should all magically work fine. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
Re: [PATCH v2 01/10] media: imx-csi: Pass sink pad field to ipu_csi_init_interface
Steve Longerbeam writes: > I think we should return to enforcing field order to userspace that > matches field order from the source, which is what I had implemented > previously. I agree with you that we should put off allowing inverting > field order. There is no any particular field order at the source, most of the time. The odd field is followed by the even field, and so on, sure. But there is no "first" and "second" field, any field can be the "first". The exception to this is a camera with a progressive sensor - both "fields" are taken at the same time and transmitted one after the other, so in this case the order is defined (by the camera, e.g. B-T on DV even with PAL version). But this isn't exactly PAL/NTSC. -- Krzysztof Halasa Industrial Research Institute for Automation and Measurements PIAP Al. Jerozolimskie 202, 02-486 Warsaw, Poland
cron job: media_tree daily build: OK
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: Mon Jun 4 05:00:14 CEST 2018 media-tree git hash:a00031c159748f322f771f3c1d5ed944cba4bd30 media_build git hash: 464ef972618cc9f845f07c1a4e8957ce2270cf91 v4l-utils git hash: 034fdb4bc2dd380a3c77c0b82c03c99c222ddef4 gcc version:i686-linux-gcc (GCC) 8.1.0 sparse version: 0.5.2 smatch version: 0.5.1 host hardware: x86_64 host os:4.16.0-1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-multi: OK linux-git-arm-pxa: OK linux-git-arm-stm32: OK linux-git-arm64: OK linux-git-i686: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK Check COMPILE_TEST: OK linux-2.6.36.4-i686: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-i686: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-i686: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-i686: OK linux-2.6.39.4-x86_64: OK linux-3.0.101-i686: OK linux-3.0.101-x86_64: OK linux-3.1.10-i686: OK linux-3.1.10-x86_64: OK linux-3.2.101-i686: OK linux-3.2.101-x86_64: OK linux-3.3.8-i686: OK linux-3.3.8-x86_64: OK linux-3.4.113-i686: OK linux-3.4.113-x86_64: OK linux-3.5.7-i686: OK linux-3.5.7-x86_64: OK linux-3.6.11-i686: OK linux-3.6.11-x86_64: OK linux-3.7.10-i686: OK linux-3.7.10-x86_64: OK linux-3.8.13-i686: OK linux-3.8.13-x86_64: OK linux-3.9.11-i686: OK linux-3.9.11-x86_64: OK linux-3.10.108-i686: OK linux-3.10.108-x86_64: OK linux-3.11.10-i686: OK linux-3.11.10-x86_64: OK linux-3.12.74-i686: OK linux-3.12.74-x86_64: OK linux-3.13.11-i686: OK linux-3.13.11-x86_64: OK linux-3.14.79-i686: OK linux-3.14.79-x86_64: OK linux-3.15.10-i686: OK linux-3.15.10-x86_64: OK linux-3.16.56-i686: OK linux-3.16.56-x86_64: OK linux-3.17.8-i686: OK linux-3.17.8-x86_64: OK linux-3.18.102-i686: OK linux-3.18.102-x86_64: OK linux-3.19.8-i686: OK linux-3.19.8-x86_64: OK linux-4.0.9-i686: OK linux-4.0.9-x86_64: OK linux-4.1.51-i686: OK linux-4.1.51-x86_64: OK linux-4.2.8-i686: OK linux-4.2.8-x86_64: OK linux-4.3.6-i686: OK linux-4.3.6-x86_64: OK linux-4.4.109-i686: OK linux-4.4.109-x86_64: OK linux-4.5.7-i686: OK linux-4.5.7-x86_64: OK linux-4.6.7-i686: OK linux-4.6.7-x86_64: OK linux-4.7.10-i686: OK linux-4.7.10-x86_64: OK linux-4.8.17-i686: OK linux-4.8.17-x86_64: OK linux-4.9.91-i686: OK linux-4.9.91-x86_64: OK linux-4.10.17-i686: OK linux-4.10.17-x86_64: OK linux-4.11.12-i686: OK linux-4.11.12-x86_64: OK linux-4.12.14-i686: OK linux-4.12.14-x86_64: OK linux-4.13.16-i686: OK linux-4.13.16-x86_64: OK linux-4.14.42-i686: OK linux-4.14.42-x86_64: OK linux-4.15.14-i686: OK linux-4.15.14-x86_64: OK linux-4.16.8-i686: OK linux-4.16.8-x86_64: OK linux-4.17-rc4-i686: OK linux-4.17-rc4-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/index.html
[PATCH] media: pxa_camera: ignore -ENOIOCTLCMD from v4l2_subdev_call for s_power
When the subdevice doesn't provide s_power core ops callback, the
v4l2_subdev_call for s_power returns -ENOIOCTLCMD. If the subdevice
doesn't have the special handling for its power saving mode, the s_power
isn't required. So -ENOIOCTLCMD from the v4l2_subdev_call should be
ignored.
Actually the -ENOIOCTLCMD is ignored in this driver's suspend/resume,
but the others treat the -ENOIOCTLCMD as an error.
This prepares a wrapper function to ignore -ENOIOCTLCMD and replaces
all s_power calls with it.
This also adds warning message when s_power() is failed.
Cc: Hans Verkuil
Cc: Sakari Ailus
Cc: Mauro Carvalho Chehab
Signed-off-by: Akinobu Mita
---
drivers/media/platform/pxa_camera.c | 35 +++
1 file changed, 23 insertions(+), 12 deletions(-)
diff --git a/drivers/media/platform/pxa_camera.c
b/drivers/media/platform/pxa_camera.c
index c792cb1..4d5a26b 100644
--- a/drivers/media/platform/pxa_camera.c
+++ b/drivers/media/platform/pxa_camera.c
@@ -2030,6 +2030,22 @@ static int pxac_vidioc_s_input(struct file *file, void
*priv, unsigned int i)
return 0;
}
+static int pxac_sensor_set_power(struct pxa_camera_dev *pcdev, int on)
+{
+ int ret;
+
+ ret = sensor_call(pcdev, core, s_power, on);
+ if (ret == -ENOIOCTLCMD)
+ ret = 0;
+ if (ret) {
+ dev_warn(pcdev_to_dev(pcdev),
+"Failed to put subdevice in %s mode: %d\n",
+on ? "normal operation" : "power saving", ret);
+ }
+
+ return ret;
+}
+
static int pxac_fops_camera_open(struct file *filp)
{
struct pxa_camera_dev *pcdev = video_drvdata(filp);
@@ -2043,7 +2059,7 @@ static int pxac_fops_camera_open(struct file *filp)
if (!v4l2_fh_is_singular_file(filp))
goto out;
- ret = sensor_call(pcdev, core, s_power, 1);
+ ret = pxac_sensor_set_power(pcdev, 1);
if (ret)
v4l2_fh_release(filp);
out:
@@ -2064,7 +2080,7 @@ static int pxac_fops_camera_release(struct file *filp)
ret = _vb2_fop_release(filp, NULL);
if (fh_singular)
- ret = sensor_call(pcdev, core, s_power, 0);
+ ret = pxac_sensor_set_power(pcdev, 0);
mutex_unlock(>mlock);
@@ -2167,7 +2183,7 @@ static int pxa_camera_sensor_bound(struct
v4l2_async_notifier *notifier,
pix->pixelformat = pcdev->current_fmt->host_fmt->fourcc;
v4l2_fill_mbus_format(mf, pix, pcdev->current_fmt->code);
- err = sensor_call(pcdev, core, s_power, 1);
+ err = pxac_sensor_set_power(pcdev, 1);
if (err)
goto out;
@@ -2194,7 +2210,7 @@ static int pxa_camera_sensor_bound(struct
v4l2_async_notifier *notifier,
}
out_sensor_poweroff:
- err = sensor_call(pcdev, core, s_power, 0);
+ err = pxac_sensor_set_power(pcdev, 0);
out:
mutex_unlock(>mlock);
return err;
@@ -2249,11 +2265,8 @@ static int pxa_camera_suspend(struct device *dev)
pcdev->save_cicr[i++] = __raw_readl(pcdev->base + CICR3);
pcdev->save_cicr[i++] = __raw_readl(pcdev->base + CICR4);
- if (pcdev->sensor) {
- ret = sensor_call(pcdev, core, s_power, 0);
- if (ret == -ENOIOCTLCMD)
- ret = 0;
- }
+ if (pcdev->sensor)
+ ret = pxac_sensor_set_power(pcdev, 0);
return ret;
}
@@ -2270,9 +2283,7 @@ static int pxa_camera_resume(struct device *dev)
__raw_writel(pcdev->save_cicr[i++], pcdev->base + CICR4);
if (pcdev->sensor) {
- ret = sensor_call(pcdev, core, s_power, 1);
- if (ret == -ENOIOCTLCMD)
- ret = 0;
+ ret = pxac_sensor_set_power(pcdev, 1);
}
/* Restart frame capture if active buffer exists */
--
2.7.4
