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: Wed Dec 23 04:00:17 CET 2015 git branch: test git hash: 0aff8a894a2be4c22e6414db33061153a4b35bc9 gcc version:i686-linux-gcc (GCC) 5.1.0 sparse version: v0.5.0-51-ga53cea2 smatch version: v0.5.0-3228-g5cf65ab host hardware: x86_64 host os:4.2.0-164 linux-git-arm-at91: OK linux-git-arm-davinci: OK linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: 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.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: OK linux-3.9.2-i686: OK linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-4.0-i686: OK linux-4.1.1-i686: OK linux-4.2-i686: OK linux-4.3-i686: OK linux-4.4-rc1-i686: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: OK linux-3.9.2-x86_64: OK linux-3.10.1-x86_64: OK linux-3.11.1-x86_64: OK linux-3.12.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK linux-4.0-x86_64: OK linux-4.1.1-x86_64: OK linux-4.2-x86_64: OK linux-4.3-x86_64: OK linux-4.4-rc1-x86_64: OK apps: OK spec-git: OK sparse: WARNINGS smatch: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The Media Infrastructure API from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.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
Re: next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
Hi Mauro, On Tuesday 22 December 2015 16:33:50 Mauro Carvalho Chehab wrote: > Em Tue, 22 Dec 2015 20:06:38 +0200 Laurent Pinchart escreveu: > > On Tuesday 22 December 2015 09:40:43 Javier Martinez Canillas wrote: > > > On 12/22/2015 07:18 AM, Valdis Kletnieks wrote: > > > > next-20151222 fails to build for me: > > > > CC drivers/media/usb/uvc/uvc_driver.o > > > > > > > > drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe': > > > > drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' > > > > has no member named 'mdev' > > > > > > > > if (media_device_register(&dev->mdev) < 0) > > > > ^ > > > > > > > > scripts/Makefile.build:258: recipe for target > > > > 'drivers/media/usb/uvc/uvc_driver.o' failed > > > > > > > > 'git blame' points at that line being added in: > > > > > > > > commit 1590ad7b52714fddc958189103c95541b49b1dae > > > > Author: Javier Martinez Canillas > > > > Date: Fri Dec 11 20:57:08 2015 -0200 > > > > > > > > [media] media-device: split media initialization and registration > > > > > > > > Not sure what went wrong here. > > > > > > It was my forgetting to test with !CONFIG_MEDIA_CONTROLLER... > > > > > > Anyways, I've already posted a fix for this: > > > > > > https://lkml.org/lkml/2015/12/21/224 > > > > Thank you for the fix. > > > > I know this is an unpopular request, but can't we make this MC rework > > series bisectable ? We're introducing bugs, which is unavoidable given > > the scope of the change, and I'm really worried about how difficult we'll > > make it to debug them if we keep piling even compilation fixes on top. > > > > I can spend a day this week rebasing the patches myself if that could > > help. > > Laurent, > > The problem is that those patches got merged already at media_tree, > at the media-controller topic branch. > > Any rebase there will break the git copies from all developers that are > based on it. It will also break the trees at linuxtv.org, since the > developer trees share objects with media_tree.git, in order to save > space on the servers. But that branch hasn't been merged to master, so it doesn't have to be the one we send upstream, does it ? I'm willing to spend time working on the patches if it can help. > What we could try to do is to fold them just before sending the pull > request upstream, as we're using tags for pull requests. > > I'll do that during the merge window, if someone reminds me about > what patches should be fold. I guess there are only two or three > patches to be fold, as the only compilation breakages I'm aware are > the ones related to Javier's patch series that broke media_device > init from the media devnode creation. -- Regards, Laurent Pinchart -- 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] [media] rc: sunxi-cir: Initialize the spinlock properly
Hi,
On Tue, Dec 22, 2015 at 12:27:35PM +0800, Chen-Yu Tsai wrote:
> The driver allocates the spinlock but fails to initialize it correctly.
> The kernel reports a BUG indicating bad spinlock magic when spinlock
> debugging is enabled.
>
> Call spin_lock_init() on it to initialize it correctly.
>
> Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
> Signed-off-by: Chen-Yu Tsai
You should probably Cc stable on this one.
Thanks!
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
signature.asc
Description: Digital signature
Re: next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
Em Tue, 22 Dec 2015 20:06:38 +0200 Laurent Pinchart escreveu: > Hi Javier, > > On Tuesday 22 December 2015 09:40:43 Javier Martinez Canillas wrote: > > On 12/22/2015 07:18 AM, Valdis Kletnieks wrote: > > > next-20151222 fails to build for me: > > > CC drivers/media/usb/uvc/uvc_driver.o > > > > > > drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe': > > > drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' has > > > no member named 'mdev'> > > > if (media_device_register(&dev->mdev) < 0) > > > ^ > > > > > > scripts/Makefile.build:258: recipe for target > > > 'drivers/media/usb/uvc/uvc_driver.o' failed > > > > > > 'git blame' points at that line being added in: > > > > > > commit 1590ad7b52714fddc958189103c95541b49b1dae > > > Author: Javier Martinez Canillas > > > Date: Fri Dec 11 20:57:08 2015 -0200 > > > > > > [media] media-device: split media initialization and registration > > > > > > Not sure what went wrong here. > > > > It was my forgetting to test with !CONFIG_MEDIA_CONTROLLER... > > > > Anyways, I've already posted a fix for this: > > > > https://lkml.org/lkml/2015/12/21/224 > > Thank you for the fix. > > I know this is an unpopular request, but can't we make this MC rework series > bisectable ? We're introducing bugs, which is unavoidable given the scope of > the change, and I'm really worried about how difficult we'll make it to debug > them if we keep piling even compilation fixes on top. > > I can spend a day this week rebasing the patches myself if that could help. Laurent, The problem is that those patches got merged already at media_tree, at the media-controller topic branch. Any rebase there will break the git copies from all developers that are based on it. It will also break the trees at linuxtv.org, since the developer trees share objects with media_tree.git, in order to save space on the servers. What we could try to do is to fold them just before sending the pull request upstream, as we're using tags for pull requests. I'll do that during the merge window, if someone reminds me about what patches should be fold. I guess there are only two or three patches to be fold, as the only compilation breakages I'm aware are the ones related to Javier's patch series that broke media_device init from the media devnode creation. Regards, Mauro -- 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: next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
Hi Javier, On Tuesday 22 December 2015 09:40:43 Javier Martinez Canillas wrote: > On 12/22/2015 07:18 AM, Valdis Kletnieks wrote: > > next-20151222 fails to build for me: > > CC drivers/media/usb/uvc/uvc_driver.o > > > > drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe': > > drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' has > > no member named 'mdev'> > > if (media_device_register(&dev->mdev) < 0) > > ^ > > > > scripts/Makefile.build:258: recipe for target > > 'drivers/media/usb/uvc/uvc_driver.o' failed > > > > 'git blame' points at that line being added in: > > > > commit 1590ad7b52714fddc958189103c95541b49b1dae > > Author: Javier Martinez Canillas > > Date: Fri Dec 11 20:57:08 2015 -0200 > > > > [media] media-device: split media initialization and registration > > > > Not sure what went wrong here. > > It was my forgetting to test with !CONFIG_MEDIA_CONTROLLER... > > Anyways, I've already posted a fix for this: > > https://lkml.org/lkml/2015/12/21/224 Thank you for the fix. I know this is an unpopular request, but can't we make this MC rework series bisectable ? We're introducing bugs, which is unavoidable given the scope of the change, and I'm really worried about how difficult we'll make it to debug them if we keep piling even compilation fixes on top. I can spend a day this week rebasing the patches myself if that could help. -- Regards, Laurent Pinchart -- 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: sn9c20x: incorrect support for 0c45:6270 MT9V011/MT9V111 ?
Hi TJ, On 12/18/2015 12:48 PM, TJ wrote: I've been trying to get the 0c45:6270 Vehoh VMS-001 'Discovery' Microscope to work correctly and discovered what seem to be differences in the bridge_init and other control commands. The most obvious difference currently is the LEDs do not turn on, but there seem to be other problems with empty frames, bad/unrecognised formats, and resolutions, although vlc is able to render a usable JPEG stream. I've installed the Windows XP Sonix driver package in a Qemu virtual machine guest and used wireshark on the host (Kubuntu 15.10, kernel v4.2) to capture and analyse the control commands. https://iam.tj/projects/misc/usbmon-0c45-6270.pcapng That seems to show the bridge_init, and possibly some of the i2c_init, byte sequences are different. It being the first time I've sniffed a USB driver though, I'm not yet 100% confident I'm identifying the correct starting point of the control command flow or the relationships between code and what is on the wire. The Windows .inf seems to indicate the chipset is MT9V111: %USBPCamDesc% = SN.USBPCam,USB\VID_0c45&PID_6270 ; SN9C201 + MI0360\MT9V111 but the sn9c20x is matching as the MT9V011 (I've copied the module to a DKMS build location and named the clone sn9c20x_vehoh, matching only on 0c45_6270, to make testing easier): Right, so it likely actually is an MT9V011, at least we are successfully reading the sensor-id, and it has the id of an MT9V011, reading the id is more reliable then relying on the windows inf file :) gspca_main: v2.14.0 registered gspca_main: sn9c20x_vehoh-2.14.0 probing 0c45:6270 sn9c20x_vehoh: MT9V011 sensor detected sn9c20x_vehoh: MT9VPRB sensor detected input: sn9c20x_vehoh as /devices/pci:00/:00:1d.7/usb2/2-3/input/input34 sn9c20x_vehoh 2-3:1.0: video1 created I'd like to know the best way to add the correct command support in this situation where the existing Linux driver's control data is different to that in use by the Windows driver? The best way I can think of to do this is to add a "#define SENSOR_MT9V011_ALT" to the list of sensor defines which uses the correct init sequences for your cam, and add a module option to override the sd->sensor value from the cmdline, so you would get something like this in sd_config(): if (sensor_override != -1) sd->sensor = sensor_override; else sd->sensor = id->driver_info >> 8; And then you can set the sensor_override module option to SENSOR_MT9V011_ALT when loading the module to work with your cam. I realize that this is not ideal, but I'm afraid it is the best I can come up with, this at least will allow you to develop support for your cam, once we have that we can see if we can find some way to autodetect it. Regards, Hans Do I somehow create another profile in the driver, or directly modify the existing data and command sequences (this latter would seem to risk regressions for other users) ? If creating another profile, how would they differentiate seeing as the device IDs are identical (I've not seen any sign of obvious version responses so far) ? My first attempt to add the correct command values for controlling the LEDs failed, and seems to indicate that more than 1 command is sent to control the LEDs, unlike the sn9c20x driver. -- 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 -- 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] adv7604: add direct interrupt handling
Hello.
On 12/22/2015 05:21 PM, Ulrich Hecht wrote:
When probed from device tree, the i2c client driver can handle the
interrupt on its own.
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
---
This revision implements the suggested style changes and drops the
IRQF_TRIGGER_LOW flag, which is handled in the device tree.
CU
Uli
drivers/media/i2c/adv7604.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 5bd81bd..be5980c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1971,6 +1972,16 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
return 0;
}
+static irqreturn_t adv76xx_irq_handler(int irq, void *devid)
+{
+ struct adv76xx_state *state = devid;
+ bool handled;
+
+ adv76xx_isr(&state->sd, 0, &handled);
+
+ return handled ? IRQ_HANDLED : IRQ_NONE;
Just IRQ_RETVAL(handled), maybe?
[...]
MBR, Sergei
--
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: next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
On Tue, 22 Dec 2015 09:40:43 -0300, Javier Martinez Canillas said: > It was my forgetting to test with !CONFIG_MEDIA_CONTROLLER... > > Anyways, I've already posted a fix for this: > > https://lkml.org/lkml/2015/12/21/224 Thanks, that fixed it. When I posted, Google hadn't indexed that post yet (or wasn't telling me about it), and it had escaped landing in my mailbox by then. Now that you reply, both Google and my mailbox have it. :) pgpRipjFLWYCB.pgp Description: PGP signature
Re:Hi
Hello iphone 6s , € 358 laptop, moto, tv, gultar, bike, dj, the shipping is free si te: poazzlo .com
[PATCH] [media] bttv-driver, usbvision-video: use to_video_device()
Use to_video_device() instead of open-coding it.
Signed-off-by: Geliang Tang
---
drivers/media/pci/bt8xx/bttv-driver.c | 2 +-
drivers/media/usb/usbvision/usbvision-video.c | 27 +--
2 files changed, 10 insertions(+), 19 deletions(-)
diff --git a/drivers/media/pci/bt8xx/bttv-driver.c
b/drivers/media/pci/bt8xx/bttv-driver.c
index 9400e99..a04329a 100644
--- a/drivers/media/pci/bt8xx/bttv-driver.c
+++ b/drivers/media/pci/bt8xx/bttv-driver.c
@@ -186,7 +186,7 @@ MODULE_VERSION(BTTV_VERSION);
static ssize_t show_card(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vfd = container_of(cd, struct video_device, dev);
+ struct video_device *vfd = to_video_device(cd);
struct bttv *btv = video_get_drvdata(vfd);
return sprintf(buf, "%d\n", btv ? btv->c.type : UNSET);
}
diff --git a/drivers/media/usb/usbvision/usbvision-video.c
b/drivers/media/usb/usbvision/usbvision-video.c
index de9ff3b..7f5d6f1 100644
--- a/drivers/media/usb/usbvision/usbvision-video.c
+++ b/drivers/media/usb/usbvision/usbvision-video.c
@@ -162,8 +162,7 @@ MODULE_ALIAS(DRIVER_ALIAS);
static inline struct usb_usbvision *cd_to_usbvision(struct device *cd)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
return video_get_drvdata(vdev);
}
@@ -177,8 +176,7 @@ static DEVICE_ATTR(version, S_IRUGO, show_version, NULL);
static ssize_t show_model(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
return sprintf(buf, "%s\n",
usbvision_device_data[usbvision->dev_model].model_string);
@@ -188,8 +186,7 @@ static DEVICE_ATTR(model, S_IRUGO, show_model, NULL);
static ssize_t show_hue(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_HUE;
@@ -203,8 +200,7 @@ static DEVICE_ATTR(hue, S_IRUGO, show_hue, NULL);
static ssize_t show_contrast(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_CONTRAST;
@@ -218,8 +214,7 @@ static DEVICE_ATTR(contrast, S_IRUGO, show_contrast, NULL);
static ssize_t show_brightness(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_BRIGHTNESS;
@@ -233,8 +228,7 @@ static DEVICE_ATTR(brightness, S_IRUGO, show_brightness,
NULL);
static ssize_t show_saturation(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
struct v4l2_control ctrl;
ctrl.id = V4L2_CID_SATURATION;
@@ -248,8 +242,7 @@ static DEVICE_ATTR(saturation, S_IRUGO, show_saturation,
NULL);
static ssize_t show_streaming(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
return sprintf(buf, "%s\n",
YES_NO(usbvision->streaming == stream_on ? 1 : 0));
@@ -259,8 +252,7 @@ static DEVICE_ATTR(streaming, S_IRUGO, show_streaming,
NULL);
static ssize_t show_compression(struct device *cd,
struct device_attribute *attr, char *buf)
{
- struct video_device *vdev =
- container_of(cd, struct video_device, dev);
+ struct video_device *vdev = to_video_device(cd);
struct usb_usbvision *usbvision = video_get_drvdata(vdev);
return sprintf(buf, "%s\n",
YES_NO(
[PATCH v2 1/2] media: adv7604: implement get_selection
The rcar_vin driver relies on this.
Signed-off-by: Ulrich Hecht
---
drivers/media/i2c/adv7604.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index be5980c..8ad5c28 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1885,6 +1885,26 @@ static int adv76xx_get_format(struct v4l2_subdev *sd,
return 0;
}
+static int adv76xx_get_selection(struct v4l2_subdev *sd,
+struct v4l2_subdev_pad_config *cfg,
+struct v4l2_subdev_selection *sel)
+{
+ struct adv76xx_state *state = to_state(sd);
+
+ if (sel->which != V4L2_SUBDEV_FORMAT_ACTIVE)
+ return -EINVAL;
+ /* Only CROP, CROP_DEFAULT and CROP_BOUNDS are supported */
+ if (sel->target > V4L2_SEL_TGT_CROP_BOUNDS)
+ return -EINVAL;
+
+ sel->r.left = 0;
+ sel->r.top = 0;
+ sel->r.width= state->timings.bt.width;
+ sel->r.height = state->timings.bt.height;
+
+ return 0;
+}
+
static int adv76xx_set_format(struct v4l2_subdev *sd,
struct v4l2_subdev_pad_config *cfg,
struct v4l2_subdev_format *format)
@@ -2415,6 +2435,7 @@ static const struct v4l2_subdev_video_ops
adv76xx_video_ops = {
static const struct v4l2_subdev_pad_ops adv76xx_pad_ops = {
.enum_mbus_code = adv76xx_enum_mbus_code,
+ .get_selection = adv76xx_get_selection,
.get_fmt = adv76xx_get_format,
.set_fmt = adv76xx_set_format,
.get_edid = adv76xx_get_edid,
--
2.6.3
--
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 v2 2/2] media: adv7604: update timings on change of input signal
Without this, .get_selection will always return the boot-time state.
Signed-off-by: Ulrich Hecht
---
drivers/media/i2c/adv7604.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 8ad5c28..dcd659b 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -1945,6 +1945,7 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
u8 fmt_change_digital;
u8 fmt_change;
u8 tx_5v;
+ int ret;
if (irq_reg_0x43)
io_write(sd, 0x44, irq_reg_0x43);
@@ -1968,6 +1969,14 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
v4l2_subdev_notify_event(sd, &adv76xx_ev_fmt);
+ /* update timings */
+ ret = adv76xx_query_dv_timings(sd, &state->timings);
+ if (ret == -ENOLINK) {
+ /* no signal, fall back to default timings */
+ state->timings = (struct v4l2_dv_timings)
+ V4L2_DV_BT_CEA_640X480P59_94;
+ }
+
if (handled)
*handled = true;
}
--
2.6.3
--
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 v2 0/2] adv7604: .get_selection support
Hi! The rcar_vin driver relies on this method. The second patch makes sure that they return up-to-date data if the input signal has changed since initialization. This revision implements .get_selection instead of .g_crop/.cropcap and includes the suggested style changes. It has been tested with the rcar_vin driver together with Hans Verkuil's "v4l2: remove g/s_crop and cropcap from video ops" patch: https://git.linuxtv.org/hverkuil/media_tree.git/commit/?h=rmcrop&id=9ff32166c29d1323db090d638da27ea652d1d4d8 CU Uli Ulrich Hecht (2): media: adv7604: implement get_selection media: adv7604: update timings on change of input signal drivers/media/i2c/adv7604.c | 30 ++ 1 file changed, 30 insertions(+) -- 2.6.3 -- 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 v2] adv7604: add direct interrupt handling
When probed from device tree, the i2c client driver can handle the
interrupt on its own.
Signed-off-by: Ulrich Hecht
Reviewed-by: Laurent Pinchart
---
This revision implements the suggested style changes and drops the
IRQF_TRIGGER_LOW flag, which is handled in the device tree.
CU
Uli
drivers/media/i2c/adv7604.c | 24 ++--
1 file changed, 22 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/adv7604.c b/drivers/media/i2c/adv7604.c
index 5bd81bd..be5980c 100644
--- a/drivers/media/i2c/adv7604.c
+++ b/drivers/media/i2c/adv7604.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1971,6 +1972,16 @@ static int adv76xx_isr(struct v4l2_subdev *sd, u32
status, bool *handled)
return 0;
}
+static irqreturn_t adv76xx_irq_handler(int irq, void *devid)
+{
+ struct adv76xx_state *state = devid;
+ bool handled;
+
+ adv76xx_isr(&state->sd, 0, &handled);
+
+ return handled ? IRQ_HANDLED : IRQ_NONE;
+}
+
static int adv76xx_get_edid(struct v4l2_subdev *sd, struct v4l2_edid *edid)
{
struct adv76xx_state *state = to_state(sd);
@@ -2844,8 +2855,7 @@ static int adv76xx_parse_dt(struct adv76xx_state *state)
state->pdata.op_656_range = 1;
}
- /* Disable the interrupt for now as no DT-based board uses it. */
- state->pdata.int1_config = ADV76XX_INT1_CONFIG_DISABLED;
+ state->pdata.int1_config = ADV76XX_INT1_CONFIG_ACTIVE_LOW;
/* Use the default I2C addresses. */
state->pdata.i2c_addresses[ADV7604_PAGE_AVLINK] = 0x42;
@@ -3235,6 +3245,16 @@ static int adv76xx_probe(struct i2c_client *client,
v4l2_info(sd, "%s found @ 0x%x (%s)\n", client->name,
client->addr << 1, client->adapter->name);
+ if (client->irq) {
+ err = devm_request_threaded_irq(&client->dev,
+ client->irq,
+ NULL, adv76xx_irq_handler,
+ IRQF_ONESHOT,
+ dev_name(&client->dev), state);
+ if (err)
+ goto err_entity;
+ }
+
err = v4l2_async_register_subdev(sd);
if (err)
goto err_entity;
--
2.6.3
--
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] next: media: cx231xx: add #ifdef to fix compile error
> On 22 Dec 2015, at 13:08, Javier Martinez Canillas > wrote: > > Hello Okash, > > On 12/22/2015 10:00 AM, Okash Khawaja wrote: > > [snip] > >> >> Cool. There was another similar compile error >> >> https://lkml.org/lkml/2015/12/22/196 > > Yes and you can see in that thread that I also mention > that was fixed already :) > >> Thanks, >> Okash > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America Of course! I'm blind. -- 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: per-frame camera metadata (again)
I have been wanting to share these thoughts for the group but was waiting for the right time which I think is now since Guennadi brought up this discussion. For the Amazon Fire phone 4 corner camera, here is how we passed metadata from driver to application (which was a CV client requiring per frame metadata). We took an unused field in struct v4l2_buffer (__u32 reserved in this case) and used it to pass in a pointer to a user space metadata object (i.e. struct app_metadata) to the driver via the VIDIOC_DQBUF ioctl call. struct v4l2_buffer for reference. http://lxr.free-electrons.com/source/include/uapi/linux/videodev2.h#L836 The driver copied its local copy of the metadata object to the userspace metadata object using the copy_to_user primitive offered by the kernel. Here is how we handled the metadata in the driver code. https://github.com/Fire-Phone/android_kernel_amazon_kodiak/blob/master/drivers/media/platform/msm/camera_v2/camera/camera.c#L235 This was done before HAL V3 was available. With HAL V3, the metadata object can be the HAL v3 metadata buffer. Non Android devices can use custom metadata format (like the one we used). With this approach, the metadata always accompanies the frame data as it's available along with the frame buffer inside struct v4l2_buffer from the VIDIOC_DQBUF ioctl call. If the community likes this idea, the v4l2_buffer can now be officially modified to contain a pointer to user space metadata object v4l2_buffer.metadata and then metadata format and size can be agreed upon between application and driver. Thoughts ? -- Regards, Karthik Poduval On Tue, Dec 22, 2015 at 3:16 AM, Guennadi Liakhovetski wrote: > Hi Laurent, > > On Mon, 21 Dec 2015, Laurent Pinchart wrote: > >> Hi Guennadi, >> >> On Wednesday 16 December 2015 12:25:24 Guennadi Liakhovetski wrote: >> > On Wed, 16 Dec 2015, Hans Verkuil wrote: >> > > On 12/16/15 10:37, Guennadi Liakhovetski wrote: >> > > > Hi all, >> > > > >> > > > A project, I am currently working on, requires acquiringing per-frame >> > > > metadata from the camera and passing it to user-space. This is not the >> > > > first time this comes up and I know such discussions have been held >> > > > before. A typical user is Android (also my case), where you have to >> > > > provide parameter values, that have been used to capture a specific >> > > > frame, to the user. I know Hans is working to handle one side of this >> > > > process - sending per-request controls, >> > > >> > > Actually, the request framework can do both sides of the equation: giving >> > > back meta data in read-only controls that are per-frame. While ideally >> > > the >> > > driver would extract the information from the binary blob and put it in >> > > nice controls, it is also possible to make a control that just contains >> > > the binary blob itself. Whether that's a good approach depends on many >> > > factors and that's another topic. >> > >> > Yes, sorry, didn't mention this possibility. On the one hand I agree, that >> > this would look nice and consistent - you send a bunch of controls down >> > and you get them back in exactly the same way, nicely taken apart. OTOH >> > there are some issues with that: >> > >> > 1. Metadata values can indeed come from the camera in a buffer, that's >> > DMAed to a buffer by the bridge - we have such examples. In our use-cases >> > those buffers are separate from main data, so, that the driver could >> > allocate them itself, but can there be cases, in which those buffers have >> > to be supplied by the user? >> >> The only case I can think of where the user would benefit from supplying the >> buffer is sharing meta data with other processes and/or devices *if* the >> amount of meta data is so large that a memcpy would negatively affect >> performances. And I can't think of such a case at the moment :-) > > Ok, so, we could for now limit metadata buffer support to driver > allocation. > >> > 2. Size - not sure how large those control buffers can become, in >> > use-cases, that I'm aware of we transfer up to 20 single-value parameters >> > per frame. >> >> I have to deal with a system that can transfer up to ~200 parameters per >> frame >> (at least in theory). > > Are they single-value (say, up to 32 bits) parameters or can be arrays / > data chunks? > >> > 3. With control values delivered per DMA, it's the bridge driver, that >> > gets the data, but it's the sensor subdevice driver, that knows what that >> > buffer contains. So, to deliver those parameters to the user, the sensor >> > driver control processing routines will have to get access to that >> > metadata buffer. This isn't supported so far even with the proposed >> > request API? >> >> Correct. My current implementation (see git://linuxtv.org/pinchartl/media.git >> drm/du/vsp1-kms/request) doesn't deal with controls yet as the first use case >> I focused on for the request API primarily requires setting formats (and >> links, which are my next target). >> >> My other
Re: [PATCH] next: media: cx231xx: add #ifdef to fix compile error
Hello Okash, On 12/22/2015 10:00 AM, Okash Khawaja wrote: [snip] > > Cool. There was another similar compile error > > https://lkml.org/lkml/2015/12/22/196 > Yes and you can see in that thread that I also mention that was fixed already :) > Thanks, > Okash > Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] next: media: cx231xx: add #ifdef to fix compile error
On Tue, Dec 22, 2015 at 09:46:19AM -0300, Javier Martinez Canillas wrote: > Hello Okash, > > On 12/22/2015 07:27 AM, Okash Khawaja wrote: > > Compiling linux-next gave this warning: > > > > drivers/media/usb/cx231xx/cx231xx-cards.c: In function > > ‘cx231xx_usb_probe’: > > drivers/media/usb/cx231xx/cx231xx-cards.c:1754:36: error: ‘struct > > cx231xx’ has no member named ‘media_dev’ > > retval = media_device_register(dev->media_dev); > > > > Looking at the refactoring in past two commits, following seems like a > > decent fix, i.e. to surround dev->media_dev by #ifdef > > CONFIG_MEDIA_CONTROLLER. > > > > Signed-off-by: Okash Khawaja > > --- > > drivers/media/usb/cx231xx/cx231xx-cards.c | 2 ++ > > 1 file changed, 2 insertions(+) > > > > diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c > > b/drivers/media/usb/cx231xx/cx231xx-cards.c > > index 35692d1..220a5db 100644 > > --- a/drivers/media/usb/cx231xx/cx231xx-cards.c > > +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c > > @@ -1751,7 +1751,9 @@ static int cx231xx_usb_probe(struct usb_interface > > *interface, > > if (retval < 0) > > goto done; > > > > +#ifdef CONFIG_MEDIA_CONTROLLER > > retval = media_device_register(dev->media_dev); > > +#endif > > > > done: > > if (retval < 0) > > > > Thanks for your patch, I've posted the same fix already: > > https://lkml.org/lkml/2015/12/21/270 > > Best regards, > -- > Javier Martinez Canillas > Open Source Group > Samsung Research America Cool. There was another similar compile error https://lkml.org/lkml/2015/12/22/196 Thanks, Okash -- 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] next: media: cx231xx: add #ifdef to fix compile error
Hello Okash, On 12/22/2015 07:27 AM, Okash Khawaja wrote: > Compiling linux-next gave this warning: > > drivers/media/usb/cx231xx/cx231xx-cards.c: In function > ‘cx231xx_usb_probe’: > drivers/media/usb/cx231xx/cx231xx-cards.c:1754:36: error: ‘struct > cx231xx’ has no member named ‘media_dev’ > retval = media_device_register(dev->media_dev); > > Looking at the refactoring in past two commits, following seems like a > decent fix, i.e. to surround dev->media_dev by #ifdef > CONFIG_MEDIA_CONTROLLER. > > Signed-off-by: Okash Khawaja > --- > drivers/media/usb/cx231xx/cx231xx-cards.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c > b/drivers/media/usb/cx231xx/cx231xx-cards.c > index 35692d1..220a5db 100644 > --- a/drivers/media/usb/cx231xx/cx231xx-cards.c > +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c > @@ -1751,7 +1751,9 @@ static int cx231xx_usb_probe(struct usb_interface > *interface, > if (retval < 0) > goto done; > > +#ifdef CONFIG_MEDIA_CONTROLLER > retval = media_device_register(dev->media_dev); > +#endif > > done: > if (retval < 0) > Thanks for your patch, I've posted the same fix already: https://lkml.org/lkml/2015/12/21/270 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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: next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
Hello Valdis, On 12/22/2015 07:18 AM, Valdis Kletnieks wrote: > next-20151222 fails to build for me: > > CC drivers/media/usb/uvc/uvc_driver.o > drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe': > drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' has no > member named 'mdev' > if (media_device_register(&dev->mdev) < 0) > ^ > scripts/Makefile.build:258: recipe for target > 'drivers/media/usb/uvc/uvc_driver.o' failed > > 'git blame' points at that line being added in: > > commit 1590ad7b52714fddc958189103c95541b49b1dae > Author: Javier Martinez Canillas > Date: Fri Dec 11 20:57:08 2015 -0200 > > [media] media-device: split media initialization and registration > > Not sure what went wrong here. > It was my forgetting to test with !CONFIG_MEDIA_CONTROLLER... Anyways, I've already posted a fix for this: https://lkml.org/lkml/2015/12/21/224 Best regards, -- Javier Martinez Canillas Open Source Group Samsung Research America -- 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] [media] rc: sunxi-cir: Initialize the spinlock properly
Hi,
On 22-12-15 05:27, Chen-Yu Tsai wrote:
The driver allocates the spinlock but fails to initialize it correctly.
The kernel reports a BUG indicating bad spinlock magic when spinlock
debugging is enabled.
Call spin_lock_init() on it to initialize it correctly.
Fixes: b4e3e59fb59c ("[media] rc: add sunxi-ir driver")
Signed-off-by: Chen-Yu Tsai
Good catch:
Acked-by: Hans de Goede
Regards,
Hans
---
drivers/media/rc/sunxi-cir.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/media/rc/sunxi-cir.c b/drivers/media/rc/sunxi-cir.c
index 7830aef3db45..40f77685cc4a 100644
--- a/drivers/media/rc/sunxi-cir.c
+++ b/drivers/media/rc/sunxi-cir.c
@@ -153,6 +153,8 @@ static int sunxi_ir_probe(struct platform_device *pdev)
if (!ir)
return -ENOMEM;
+ spin_lock_init(&ir->ir_lock);
+
if (of_device_is_compatible(dn, "allwinner,sun5i-a13-ir"))
ir->fifo_size = 64;
else
--
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: per-frame camera metadata (again)
Hi Laurent, On Mon, 21 Dec 2015, Laurent Pinchart wrote: > Hi Guennadi, > > On Wednesday 16 December 2015 12:25:24 Guennadi Liakhovetski wrote: > > On Wed, 16 Dec 2015, Hans Verkuil wrote: > > > On 12/16/15 10:37, Guennadi Liakhovetski wrote: > > > > Hi all, > > > > > > > > A project, I am currently working on, requires acquiringing per-frame > > > > metadata from the camera and passing it to user-space. This is not the > > > > first time this comes up and I know such discussions have been held > > > > before. A typical user is Android (also my case), where you have to > > > > provide parameter values, that have been used to capture a specific > > > > frame, to the user. I know Hans is working to handle one side of this > > > > process - sending per-request controls, > > > > > > Actually, the request framework can do both sides of the equation: giving > > > back meta data in read-only controls that are per-frame. While ideally the > > > driver would extract the information from the binary blob and put it in > > > nice controls, it is also possible to make a control that just contains > > > the binary blob itself. Whether that's a good approach depends on many > > > factors and that's another topic. > > > > Yes, sorry, didn't mention this possibility. On the one hand I agree, that > > this would look nice and consistent - you send a bunch of controls down > > and you get them back in exactly the same way, nicely taken apart. OTOH > > there are some issues with that: > > > > 1. Metadata values can indeed come from the camera in a buffer, that's > > DMAed to a buffer by the bridge - we have such examples. In our use-cases > > those buffers are separate from main data, so, that the driver could > > allocate them itself, but can there be cases, in which those buffers have > > to be supplied by the user? > > The only case I can think of where the user would benefit from supplying the > buffer is sharing meta data with other processes and/or devices *if* the > amount of meta data is so large that a memcpy would negatively affect > performances. And I can't think of such a case at the moment :-) Ok, so, we could for now limit metadata buffer support to driver allocation. > > 2. Size - not sure how large those control buffers can become, in > > use-cases, that I'm aware of we transfer up to 20 single-value parameters > > per frame. > > I have to deal with a system that can transfer up to ~200 parameters per > frame > (at least in theory). Are they single-value (say, up to 32 bits) parameters or can be arrays / data chunks? > > 3. With control values delivered per DMA, it's the bridge driver, that > > gets the data, but it's the sensor subdevice driver, that knows what that > > buffer contains. So, to deliver those parameters to the user, the sensor > > driver control processing routines will have to get access to that > > metadata buffer. This isn't supported so far even with the proposed > > request API? > > Correct. My current implementation (see git://linuxtv.org/pinchartl/media.git > drm/du/vsp1-kms/request) doesn't deal with controls yet as the first use case > I focused on for the request API primarily requires setting formats (and > links, which are my next target). > > My other use case (Android camera HAL v3 for Project Ara) mainly deals with > controls and meta-data, but I'll then likely pass the meta-data blob to > userspace as-is, as its format isn't always known to the driver. I'm also > concerned about efficiency but haven't had time to perform measurements yet. Hm, why is it not known to the subdevice driver? Does the buffer layout depend on some external conditions? Maybe loaded firmware? But it should be possible to tell the driver, say, that the current metadata buffer layout has version N? Those metadata buffers can well contain some parameters, that can also be obtained via controls. So, if we just send metadata buffers to the user as is, we create duplication, which isn't nice. Besides, the end user will anyway want broken down control values. E.g. in the Android case, the app is getting single controls, not opaque metadata buffers. Of course, one could create a vendor metadata tag "metadata blob," but that's not how Android does it so far. OTOH passing those buffers to the subdevice driver for parsing and returning them as an (extended) control also seems a bit ugly. What about performance cost? If we pass all those parameters as a single extended control (as long as they are of the same class), the cost won't be higher, than dequeuing a buffer? Let's not take the parsing cost and the control struct memory overhead into account for now. User-friendliness: I think, implementors would prefer to pass a complete buffer to the user-space to avoid having to modify drivers every time they modify those parameters. > > > > but I'm not aware whether he or anyone else is actively working on this > > > > already or is planning to do so in the near future? I
[no subject]
Are you in need of private or business loans for various purposes? if yes,apply now -- 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
next-20151222 - compile failure in drivers/media/usb/uvc/uvc_driver.c
next-20151222 fails to build for me: CC drivers/media/usb/uvc/uvc_driver.o drivers/media/usb/uvc/uvc_driver.c: In function 'uvc_probe': drivers/media/usb/uvc/uvc_driver.c:1941:32: error: 'struct uvc_device' has no member named 'mdev' if (media_device_register(&dev->mdev) < 0) ^ scripts/Makefile.build:258: recipe for target 'drivers/media/usb/uvc/uvc_driver.o' failed 'git blame' points at that line being added in: commit 1590ad7b52714fddc958189103c95541b49b1dae Author: Javier Martinez Canillas Date: Fri Dec 11 20:57:08 2015 -0200 [media] media-device: split media initialization and registration Not sure what went wrong here. -- 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] next: media: cx231xx: add #ifdef to fix compile error
Compiling linux-next gave this warning: drivers/media/usb/cx231xx/cx231xx-cards.c: In function ‘cx231xx_usb_probe’: drivers/media/usb/cx231xx/cx231xx-cards.c:1754:36: error: ‘struct cx231xx’ has no member named ‘media_dev’ retval = media_device_register(dev->media_dev); Looking at the refactoring in past two commits, following seems like a decent fix, i.e. to surround dev->media_dev by #ifdef CONFIG_MEDIA_CONTROLLER. Signed-off-by: Okash Khawaja --- drivers/media/usb/cx231xx/cx231xx-cards.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/media/usb/cx231xx/cx231xx-cards.c b/drivers/media/usb/cx231xx/cx231xx-cards.c index 35692d1..220a5db 100644 --- a/drivers/media/usb/cx231xx/cx231xx-cards.c +++ b/drivers/media/usb/cx231xx/cx231xx-cards.c @@ -1751,7 +1751,9 @@ static int cx231xx_usb_probe(struct usb_interface *interface, if (retval < 0) goto done; +#ifdef CONFIG_MEDIA_CONTROLLER retval = media_device_register(dev->media_dev); +#endif done: if (retval < 0) -- 2.5.2 -- 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
