WinTV-HVR-2255 saa7164 and linux kernel 4.1.27

[catchall]

I recently replaced a broken WinTV-HVR-2250 with an WinTV-HVR-2255.

I knew that the 2255 was supported in kernel 4.2, what I didn't know was 
that the latest stable version of my distro (opensuse) only used 4.1.


I was on 13.2 with kernel 3.16 at the time of the upgrade.

Anyway, is it possible to patch the saa7164 driver in 4.1?

I had to perform a similar patch in  3.16 for the 2250 to address a PCI 
interupt issue.



Regards,

David


--
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: WARNINGS

[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:   Thu Sep 22 04:00:17 CEST 2016
git branch: test
git hash:   142a0e11b52c18a82c4fe55132b762005dda05c0
gcc version:i686-linux-gcc (GCC) 5.4.0
sparse version: v0.5.0-56-g7647c77
smatch version: v0.5.0-3428-gdfe27cf
host hardware:  x86_64
host os:4.6.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.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-i686: OK
linux-4.5-i686: OK
linux-4.6-i686: OK
linux-4.7-i686: OK
linux-4.8-rc1-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.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-x86_64: OK
linux-4.5-x86_64: OK
linux-4.6-x86_64: OK
linux-4.7-x86_64: OK
linux-4.8-rc1-x86_64: OK
apps: WARNINGS
spec-git: OK
sparse: WARNINGS
smatch: WARNINGS

Detailed results are available here:

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

Full logs are available here:

http://www.xs4all.nl/~hverkuil/logs/Thursday.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

Supported, available Dual ATSC tuner? If not, I'll pay you to make one work!

[Jonathan Kamens]

I'm sure this is one of the most commonly asked question on this list,
and for that I apologize, but I've tried reading all the information
that I can find about this online, and I just can't figure it out, so
here goes... Is there actually a USB or PCI, ATSC, DVB-T device with
two tuners that I can buy today that will actually work on Linux
(Ubuntu 16.04.1)? If so, what is it?

It seems like all the lists of compatible devices I've seen list a
bunch of devices that aren't actually sold anymore, and most of them
only have one tuner. I already have a working device with one tuner; I
need two.

And a related question... I bought the Hauppauge WinTV-dualHD tuner,
in particular this device:

https://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-dualHD#Model_01595_.28USB_device_ID_2040:026d.29

thinking that it was compatible with Linux, but it's actually not.

Is it just a matter of messing around with USB device detection and
kernel driver settings and loading the correct firmware into the
dongle, or something? Could an experienced V4L developer with access
to this device figure out how to make it work relatively easily?

If so, then I've got an offer that will hopefully be attractive enough
for someone to take me up on it. Here's the deal...

If you know what you're doing in this code -- I certainly don't, and I
don't have time to learn -- and you think you can make this device
work with Linux -- and to be clear, I mean making *both* tuners work,
not just one of them -- then in exchange for your doing so, I offer
one of the following:

1. I will give you the tuner for free for you to keep;
2. I will donate USD$300 to any IRS-recognized 501(c)3 charity of your
   choice; or
3. I will send you USD$200 via Paypal.

To facilitate this, I will either give you remote access to an Ubuntu
Linux 16.04.1 box with the tuner plugged into it for you to work on
(including TeamViewer access so you can see the remote display to
verify that the tuner is working when you get to the point where it's
actually being registered properly in the kernel), or send you the
tuner (if you're in the U.S.; shipping overseas is cost-prohibitive),
with the understanding that if you then _can't_ make it work, you have
to pay to send it back to me.

Why am I doing this? Because I'm sick of trying to make this work by
myself and I don't have any more time to spend on it, so I'm happy to
substitute money for time if there's someone more knowledgeable than I
am who can solve this problem for me. And because I want to help the
Linux community by adding at least one to the small set of currently
sold tuner devices that actually work with Linux.

Anybody interested?

Thanks,

Jonathan Kamens

--
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] tw5864: crop picture width to 704

[Andrey Utkin]

Previously, width of 720 was used, but it gives 16-pixel wide black bar
at right side of encoded picture.

Signed-off-by: Andrey Utkin 
---
 drivers/media/pci/tw5864/tw5864-reg.h   |  8 
 drivers/media/pci/tw5864/tw5864-video.c | 13 +++--
 2 files changed, 19 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/tw5864/tw5864-reg.h 
b/drivers/media/pci/tw5864/tw5864-reg.h
index 92a1b07..30ac142 100644
--- a/drivers/media/pci/tw5864/tw5864-reg.h
+++ b/drivers/media/pci/tw5864/tw5864-reg.h
@@ -1879,6 +1879,14 @@
 #define TW5864_INDIR_IN_PIC_HEIGHT(channel) (0x201 + 4 * channel)
 #define TW5864_INDIR_OUT_PIC_WIDTH(channel) (0x202 + 4 * channel)
 #define TW5864_INDIR_OUT_PIC_HEIGHT(channel) (0x203 + 4 * channel)
+
+/* Some registers skipped */
+
+#define TW5864_INDIR_CROP_ETC 0x260
+/* Define controls in register TW5864_INDIR_CROP_ETC */
+/* Enable cropping from 720 to 704 */
+#define TW5864_INDIR_CROP_ETC_CROP_EN 0x4
+
 /*
  * Interrupt status register from the front-end. Write "1" to each bit to clear
  * the interrupt
diff --git a/drivers/media/pci/tw5864/tw5864-video.c 
b/drivers/media/pci/tw5864/tw5864-video.c
index ff94e6c..3c8c302 100644
--- a/drivers/media/pci/tw5864/tw5864-video.c
+++ b/drivers/media/pci/tw5864/tw5864-video.c
@@ -590,6 +590,15 @@ static int tw5864_enable_input(struct tw5864_input *input)
tw_indir_writeb(TW5864_INDIR_OUT_PIC_WIDTH(nr), input->width / 4);
tw_indir_writeb(TW5864_INDIR_OUT_PIC_HEIGHT(nr), input->height / 4);
 
+   /*
+* Crop width from 720 to 704.
+* Above register settings need value 720 involved.
+*/
+   input->width = 704;
+   tw_indir_writeb(TW5864_INDIR_CROP_ETC,
+   tw_indir_readb(TW5864_INDIR_CROP_ETC) |
+   TW5864_INDIR_CROP_ETC_CROP_EN);
+
tw_writel(TW5864_DSP_PIC_MAX_MB,
  ((input->width / 16) << 8) | (input->height / 16));
 
@@ -792,7 +801,7 @@ static int tw5864_fmt_vid_cap(struct file *file, void *priv,
 {
struct tw5864_input *input = video_drvdata(file);
 
-   f->fmt.pix.width = 720;
+   f->fmt.pix.width = 704;
switch (input->std) {
default:
WARN_ON_ONCE(1);
@@ -998,7 +1007,7 @@ static int tw5864_enum_framesizes(struct file *file, void 
*priv,
return -EINVAL;
 
fsize->type = V4L2_FRMSIZE_TYPE_DISCRETE;
-   fsize->discrete.width = 720;
+   fsize->discrete.width = 704;
fsize->discrete.height = input->std == STD_NTSC ? 480 : 576;
 
return 0;
-- 
2.9.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

[PATCH] [media] solo6x10: avoid delayed register write

[Andrey Utkin]

This fixes a lockup at device probing which happens on some solo6010
hardware samples. This is a regression introduced by commit e1ceb25a1569
("[media] SOLO6x10: remove unneeded register locking and barriers")

The observed lockup happens in solo_set_motion_threshold() called from
solo_motion_config().

This extra "flushing" is not fundamentally needed for every write, but
apparently the code in driver assumes such behaviour at last in some
places.

Actual fix was proposed by Hans Verkuil.

Signed-off-by: Andrey Utkin 
---
 drivers/media/pci/solo6x10/solo6x10.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/media/pci/solo6x10/solo6x10.h 
b/drivers/media/pci/solo6x10/solo6x10.h
index 5bd4987..3f8da5e 100644
--- a/drivers/media/pci/solo6x10/solo6x10.h
+++ b/drivers/media/pci/solo6x10/solo6x10.h
@@ -284,7 +284,10 @@ static inline u32 solo_reg_read(struct solo_dev *solo_dev, 
int reg)
 static inline void solo_reg_write(struct solo_dev *solo_dev, int reg,
  u32 data)
 {
+   u16 val;
+
writel(data, solo_dev->reg_base + reg);
+   pci_read_config_word(solo_dev->pdev, PCI_STATUS, );
 }
 
 static inline void solo_irq_on(struct solo_dev *dev, u32 mask)
-- 
2.9.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

Re: [PATCH v5 2/2] media: Add a driver for the ov5645 camera sensor.

[Sakari Ailus]

Hi Todor,

Todor Tomov wrote:
> Hi Sakari,
> 
> One more question below:
> 
> On 08/25/2016 10:18 AM, Sakari Ailus wrote:
> +
> +static struct v4l2_subdev_core_ops ov5645_core_ops = {
> + .s_power = ov5645_s_power,
> +};
> +
> +static struct v4l2_subdev_video_ops ov5645_video_ops = {
> + .s_stream = ov5645_s_stream,
> +};
> +
> +static struct v4l2_subdev_pad_ops ov5645_subdev_pad_ops = {
> + .enum_mbus_code = ov5645_enum_mbus_code,
> + .enum_frame_size = ov5645_enum_frame_size,
> + .get_fmt = ov5645_get_format,
> + .set_fmt = ov5645_set_format,
> + .get_selection = ov5645_get_selection,

 Could you add init_cfg() pad op to initialise the try format and 
 selections?
>>>
>>> Yes, I'll do that.
> 
> If I follow the code correctly this init_cfg() is called whenever the device 
> is opened, right?
> This means that the format will be reset to default values every time the 
> userspace opens the device.
> So I wonder if this is what we really want, or do we want to keep the last 
> set format instead. For
> example if we use media-ctl only to get the current format, this is already 
> enough - it opens the
> subdev node and resets the format to default.

What's getting set in init_cfg() called through open system call is the
try format, not the active format.

Whether to choose the default or current format for the try format for a
file handle was discussed some years ago and we indeed settled to use
the default one, since that's independent of whatever configuration
happened to be set --- quite possibly by a different application. AFAIR.

-- 
Kind regards,

Sakari Ailus
sakari.ai...@iki.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 -next] [media] cx88: fix error return code in cx8802_dvb_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return error code -ENODEV from the error handling case
instead of 0(err maybe overwrited to 0 in the for loop), as
done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/media/pci/cx88/cx88-dvb.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/pci/cx88/cx88-dvb.c 
b/drivers/media/pci/cx88/cx88-dvb.c
index ac2392d..d76a175 100644
--- a/drivers/media/pci/cx88/cx88-dvb.c
+++ b/drivers/media/pci/cx88/cx88-dvb.c
@@ -1779,6 +1779,7 @@ static int cx8802_dvb_probe(struct cx8802_driver *drv)
if (fe == NULL) {
printk(KERN_ERR "%s() failed to get frontend(%d)\n",
__func__, i);
+   err = -ENODEV;
goto fail_probe;
}
q = >dvb.dvbq;

--
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] bdisp: fix error return code in bdisp_probe()

[Wei Yongjun]

From: Wei Yongjun 

Fix to return error code -EINVAL from the platform_get_resource() error
handling case instead of 0, as done elsewhere in this function.

Signed-off-by: Wei Yongjun 
---
 drivers/media/platform/sti/bdisp/bdisp-v4l2.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c 
b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
index 45f82b5..8236081 100644
--- a/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
+++ b/drivers/media/platform/sti/bdisp/bdisp-v4l2.c
@@ -1337,6 +1337,7 @@ static int bdisp_probe(struct platform_device *pdev)
res = platform_get_resource(pdev, IORESOURCE_IRQ, 0);
if (!res) {
dev_err(dev, "failed to get IRQ resource\n");
+   ret = -EINVAL;
goto err_clk;
}

--
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: g_webcam Isoch high bandwidth transfer

[Bin Liu]

On Wed, Sep 21, 2016 at 08:27:02AM -0500, Bin Liu wrote:
> On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
> > 
> > Hi,
> > 
> > Bin Liu  writes:
> > > Hi,
> > >
> > > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
> > >  high-speed connection.
> > >
> > > First I hacked webcam.c as follows to enable 640x480@30fps mode.
> > >
> > > diff --git a/drivers/usb/gadget/legacy/webcam.c 
> > > b/drivers/usb/gadget/legacy/webcam.c
> > > index 72c976b..9eb315f 100644
> > > --- a/drivers/usb/gadget/legacy/webcam.c
> > > +++ b/drivers/usb/gadget/legacy/webcam.c
> > > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> > > uvc_frame_yuv_360p = {
> > > .bFrameIndex= 1,
> > > .bmCapabilities = 0,
> > > .wWidth = cpu_to_le16(640),
> > > -   .wHeight= cpu_to_le16(360),
> > > +   .wHeight= cpu_to_le16(480),
> > > .dwMinBitRate   = cpu_to_le32(18432000),
> > > .dwMaxBitRate   = cpu_to_le32(55296000),
> > > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> > > -   .dwDefaultFrameInterval = cpu_to_le32(66),
> > > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> > > +   .dwDefaultFrameInterval = cpu_to_le32(33),
> > > .bFrameIntervalType = 3,
> > > -   .dwFrameInterval[0] = cpu_to_le32(66),
> > > -   .dwFrameInterval[1] = cpu_to_le32(100),
> > > -   .dwFrameInterval[2] = cpu_to_le32(500),
> > > +   .dwFrameInterval[0] = cpu_to_le32(33),
> > > +   .dwFrameInterval[1] = cpu_to_le32(66),
> > > +   .dwFrameInterval[2] = cpu_to_le32(100),
> > >  };
> > >
> > > then loaded g_webcam.ko as
> > >
> > > # modprobe g_webcam streaming_maxpacket=3072
> > >
> > > The endpoint descriptor showing on the host is
> > >
> > >   Endpoint Descriptor:
> > > bLength 7
> > > bDescriptorType 5
> > > bEndpointAddress 0x8d  EP 13 IN
> > > bmAttributes5
> > >   Transfer TypeIsochronous
> > >   Synch Type   Asynchronous
> > >   Usage Type   Data
> > > wMaxPacketSize 0x1400  3x 1024 bytes
> > > bInterval   1
> > >
> > > However the usb bus trace shows only one transaction with 1024-bytes 
> > > packet in
> > > every SOF. The host only sends one IN packet in every SOF, I am expecting 
> > > 2~3
> > > 1024-bytes transactions, since this would be required to transfer 
> > > 640x480@30fps
> > > YUV frames in high-speed.
> > >
> > > DId I miss anything in the setup?
> > 
> > MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
> 
> Happened on both MUSB and DWC3.

Indeed, it is MUSB gadget driver problem.

> 
> > of your bus analyzer? When host sends IN token, are you replying with
> 
> The trace screenshot on DWC3 is attached.
> 
> > DATA0, DATA1 or DATA2?
> 
> Good hint! It is DATA0!
> 
> > 
> > -- 
> > balbi
> 
> Regards,
> -Bin.


--
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 v5 2/2] media: Add a driver for the ov5645 camera sensor.

[Todor Tomov]

Hi Sakari,

One more question below:

On 08/25/2016 10:18 AM, Sakari Ailus wrote:
 +
 +static struct v4l2_subdev_core_ops ov5645_core_ops = {
 +  .s_power = ov5645_s_power,
 +};
 +
 +static struct v4l2_subdev_video_ops ov5645_video_ops = {
 +  .s_stream = ov5645_s_stream,
 +};
 +
 +static struct v4l2_subdev_pad_ops ov5645_subdev_pad_ops = {
 +  .enum_mbus_code = ov5645_enum_mbus_code,
 +  .enum_frame_size = ov5645_enum_frame_size,
 +  .get_fmt = ov5645_get_format,
 +  .set_fmt = ov5645_set_format,
 +  .get_selection = ov5645_get_selection,
>>>
>>> Could you add init_cfg() pad op to initialise the try format and selections?
>>
>> Yes, I'll do that.

If I follow the code correctly this init_cfg() is called whenever the device is 
opened, right?
This means that the format will be reset to default values every time the 
userspace opens the device.
So I wonder if this is what we really want, or do we want to keep the last set 
format instead. For
example if we use media-ctl only to get the current format, this is already 
enough - it opens the
subdev node and resets the format to default.


-- 
Best regards,
Todor Tomov
--
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: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Andrey Utkin]

On Wed, Sep 21, 2016 at 03:16:57PM +0200, Krzysztof Hałasa wrote:
> Hans Verkuil  writes:
> 
> > That was probably the reason for the pci_read_config_word in the reg_write
> > code. Try putting that back (and just that).
> 
> Yes. I guess a single pci_read_config_word() would suffice.
> 
> Though it would obviously be much better to identify the place in the
> driver which needs to have the write buffers flushed, and add a read()
> just there.
> 
> The interrupt handler maybe (e.g. just before the return IRQ_HANDLED)?
> 
> OTOH this may be some sort of timing problem, I mean the faster code may
> put too much stress on the SOLO chip.
> 
> Doesn't happen here so I can't test the cure.

It happens in solo_disp_init at uploading default motion thresholds
array.

I've got a prints trace with solo6010-fix-lockup branch
https://github.com/bluecherrydvr/linux/tree/solo6010-fix-lockup/drivers/media/pci/solo6x10
the trace itself in jpg:
https://decent.im:5281/upload/3793f393-e285-4514-83dd-bf08d1c8b4a2/e7ad898b-515b-4522-86a9-553daaeb0860.jpg

Indeed, targeted fixing would be more reasonable than making register
r/w routines follow blocking fashion. But the driver is already complete
and was known to be working, and I seems all places in code assume the
blocking fashion of reg r/w, and changing that assumption may lead to
covert bugs anywhere else, not just at probing, which may be hard to
nail down.

For now, I'll try setting pci_read_config_word() back instead of full
revert. Does it need to be just in reg_write? No need for it in
reg_read, right?
--
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: [RFC PATCH 5/7] ov7670: add devicetree support

[Laurent Pinchart]

Hi Hans,

On Friday 26 Aug 2016 09:45:25 Hans Verkuil wrote:
> On 08/17/2016 02:44 PM, Laurent Pinchart wrote:
> > On Wednesday 17 Aug 2016 08:29:41 Hans Verkuil wrote:
> >> From: Hans Verkuil 
> >> 
> >> Add DT support. Use it to get the reset and pwdn pins (if there are any).
> >> Tested with one sensor requiring reset/pwdn and one sensor that doesn't
> >> have reset/pwdn pins.
> >> 
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >> 
> >>  .../devicetree/bindings/media/i2c/ov7670.txt   | 44 ++
> >>  MAINTAINERS|  1 +
> >>  drivers/media/i2c/ov7670.c | 51 
> >>  3 files changed, 96 insertions(+)
> >>  create mode 100644
> >>  Documentation/devicetree/bindings/media/i2c/ov7670.txt
> >> 
> >> diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> >> b/Documentation/devicetree/bindings/media/i2c/ov7670.txt new file mode
> >> 100644
> >> index 000..3231c47
> >> --- /dev/null
> >> +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> >> @@ -0,0 +1,44 @@
> >> +* Omnivision OV7670 CMOS sensor
> >> +
> >> +The Omnivision OV7670 sensor support multiple resolutions output, such
> >> as
> > 
> > s/support/supports/
> > 
> >> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> >> +output format.
> > 
> > s/format/formats/ (and possibly s/can support/can support the/)
> > 
> >> +
> >> +Required Properties:
> >> +- compatible: should be "ovti,ov7670"
> >> +- clocks: reference to the xvclk input clock.
> >> +- clock-names: should be "xvclk".
> >> +
> >> +Optional Properties:
> >> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if
> >> any.
> >> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
> >> +
> >> +The device node must contain one 'port' child node for its digital
> >> output
> >> +video port, in accordance with the video interface bindings defined in
> >> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> >> +
> >> +Example:
> >> +
> >> +  i2c1: i2c@f0018000 {
> >> +  status = "okay";
> >> +
> >> +  ov7670: camera@0x21 {
> >> +  compatible = "ovti,ov7670";
> >> +  reg = <0x21>;
> >> +  pinctrl-names = "default";
> >> +  pinctrl-0 = <_pck0_as_isi_mck
> >> _sensor_power
> >> _sensor_reset>;
> > 
> > The pinctrl properties should be part of the clock provider DT node.
> 
> Do you have examples of that?

Sure, it's pretty simple. The pinctrl_pck0_as_isi_mck can just be moved to the 
isi DT node, as the isi is the clock provider for the sensor.

The two other properties, however, have to stay here (I think I've overlooked 
them in my previous review e-mail), so I'm also not totally opposed to keeping 
all three pinctrl entries together.

> I just copied this from existing atmel dts code
> (arch/arm/boot/dts/sama5d3xmb.dtsi).
>
> >> +  resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> >> +  pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> >> +  clocks = <>;
> >> +  clock-names = "xvclk";

I missed this, isn't the pin named "xclk" in the datasheet ?

> >> +  assigned-clocks = <>;
> >> +  assigned-clock-rates = <2400>;
> > 
> > You should compute and set the clock rate dynamically in the driver, not
> > hardcode it in DT.
> 
> Do you have an example of that? Again, I just copied this from the same
> sama5d3xmb.dtsi.

Please see my reply to Sakari's e-mail in the same thread.

-- 
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: solo6010 modprobe lockup since e1ceb25a (v4.3 regression)

[Krzysztof Hałasa]

Hans Verkuil  writes:

> That was probably the reason for the pci_read_config_word in the reg_write
> code. Try putting that back (and just that).

Yes. I guess a single pci_read_config_word() would suffice.

Though it would obviously be much better to identify the place in the
driver which needs to have the write buffers flushed, and add a read()
just there.

The interrupt handler maybe (e.g. just before the return IRQ_HANDLED)?

OTOH this may be some sort of timing problem, I mean the faster code may
put too much stress on the SOLO chip.

Doesn't happen here so I can't test the cure.
-- 
Krzysztof Halasa

Industrial Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland
--
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: g_webcam Isoch high bandwidth transfer

[Bin Liu]

On Wed, Sep 21, 2016 at 11:01:21AM +0300, Felipe Balbi wrote:
> 
> Hi,
> 
> Bin Liu  writes:
> > Hi,
> >
> > I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
> >  high-speed connection.
> >
> > First I hacked webcam.c as follows to enable 640x480@30fps mode.
> >
> > diff --git a/drivers/usb/gadget/legacy/webcam.c 
> > b/drivers/usb/gadget/legacy/webcam.c
> > index 72c976b..9eb315f 100644
> > --- a/drivers/usb/gadget/legacy/webcam.c
> > +++ b/drivers/usb/gadget/legacy/webcam.c
> > @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> > uvc_frame_yuv_360p = {
> > .bFrameIndex= 1,
> > .bmCapabilities = 0,
> > .wWidth = cpu_to_le16(640),
> > -   .wHeight= cpu_to_le16(360),
> > +   .wHeight= cpu_to_le16(480),
> > .dwMinBitRate   = cpu_to_le32(18432000),
> > .dwMaxBitRate   = cpu_to_le32(55296000),
> > -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> > -   .dwDefaultFrameInterval = cpu_to_le32(66),
> > +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> > +   .dwDefaultFrameInterval = cpu_to_le32(33),
> > .bFrameIntervalType = 3,
> > -   .dwFrameInterval[0] = cpu_to_le32(66),
> > -   .dwFrameInterval[1] = cpu_to_le32(100),
> > -   .dwFrameInterval[2] = cpu_to_le32(500),
> > +   .dwFrameInterval[0] = cpu_to_le32(33),
> > +   .dwFrameInterval[1] = cpu_to_le32(66),
> > +   .dwFrameInterval[2] = cpu_to_le32(100),
> >  };
> >
> > then loaded g_webcam.ko as
> >
> > # modprobe g_webcam streaming_maxpacket=3072
> >
> > The endpoint descriptor showing on the host is
> >
> >   Endpoint Descriptor:
> > bLength 7
> > bDescriptorType 5
> > bEndpointAddress 0x8d  EP 13 IN
> > bmAttributes5
> >   Transfer TypeIsochronous
> >   Synch Type   Asynchronous
> >   Usage Type   Data
> > wMaxPacketSize 0x1400  3x 1024 bytes
> > bInterval   1
> >
> > However the usb bus trace shows only one transaction with 1024-bytes packet 
> > in
> > every SOF. The host only sends one IN packet in every SOF, I am expecting 
> > 2~3
> > 1024-bytes transactions, since this would be required to transfer 
> > 640x480@30fps
> > YUV frames in high-speed.
> >
> > DId I miss anything in the setup?
> 
> MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot

Happened on both MUSB and DWC3.

> of your bus analyzer? When host sends IN token, are you replying with

The trace screenshot on DWC3 is attached.

> DATA0, DATA1 or DATA2?

Good hint! It is DATA0!

> 
> -- 
> balbi

Regards,
-Bin.

[PATCH -next] [media] gs1662: remove .owner field for driver

[Wei Yongjun]

From: Wei Yongjun 

Remove .owner field if calls are used which set it automatically.

Generated by: scripts/coccinelle/api/platform_no_drv_owner.cocci

Signed-off-by: Wei Yongjun 
---
 drivers/media/spi/gs1662.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/spi/gs1662.c b/drivers/media/spi/gs1662.c
index d76f362..057530b 100644
--- a/drivers/media/spi/gs1662.c
+++ b/drivers/media/spi/gs1662.c
@@ -463,7 +463,6 @@ static int gs_remove(struct spi_device *spi)
 static struct spi_driver gs_driver = {
.driver = {
.name   = "gs1662",
-   .owner  = THIS_MODULE,
},
 
.probe  = gs_probe,



--
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] gs1662: drop kfree for memory allocated with devm_kzalloc

[Wei Yongjun]

From: Wei Yongjun 

It's not necessary to free memory allocated with devm_kzalloc
and using kfree leads to a double free.

Fixes: 7aae6e2df127 ("[media] Add GS1662 driver, a video serializer")
Signed-off-by: Wei Yongjun 
---
 drivers/media/spi/gs1662.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/spi/gs1662.c b/drivers/media/spi/gs1662.c
index d76f362..5143a90 100644
--- a/drivers/media/spi/gs1662.c
+++ b/drivers/media/spi/gs1662.c
@@ -453,10 +453,9 @@ static int gs_probe(struct spi_device *spi)
 static int gs_remove(struct spi_device *spi)
 {
struct v4l2_subdev *sd = spi_get_drvdata(spi);
-   struct gs *gs = to_gs(sd);
 
v4l2_device_unregister_subdev(sd);
-   kfree(gs);
+
return 0;
 }

--
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: [RFC PATCH 5/7] ov7670: add devicetree support

[Laurent Pinchart]

Hello Sakari,

On Wednesday 21 Sep 2016 14:33:29 Sakari Ailus wrote:
> Hi Laurent,
> 
> On Wed, Aug 17, 2016 at 03:44:00PM +0300, Laurent Pinchart wrote:
> > > + assigned-clock-rates = <2400>;
> > 
> > You should compute and set the clock rate dynamically in the driver, not
> > hardcode it in DT.
> 
> This frequency is typically defined by hardware engineers and it's
> hand-picked from possible ranges. What counts is EMC so you don't disturb
> a GSM/3G/4G modem (if you have one) or GPS receiver, for instance. In order
> to freely choose this frequency, you'd also need to be aware of the limits
> of the sensor's internal clock tree, and make sure you still would be able
> to obtain the desired frame rates for there are often corner cases where the
> resulting maximum pixel clock may be substantially lower if your input
> frequency goes up.
> 
> I also haven't encountered a use case for more than a single, fixed
> frequency. In other words I'd keep this constant.

My review predates our recent discussion on this topic. I still believe that 
in the general case we could want to express allowable frequencies constraints 
in DT and let the driver compute the desired frequency based on timings. 
However, I also agree that there are very few cases for this, so it's not 
really worth tackling the issue at the moment. I'm thus fine with the usage of 
assigned-clock-rates.

-- 
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: [RFC PATCH 5/7] ov7670: add devicetree support

[Sakari Ailus]

Hi Laurent,

On Wed, Aug 17, 2016 at 03:44:00PM +0300, Laurent Pinchart wrote:
> > +   assigned-clock-rates = <2400>;
> 
> You should compute and set the clock rate dynamically in the driver, not 
> hardcode it in DT.

This frequency is typically defined by hardware engineers and it's
hand-picked from possible ranges. What counts is EMC so you don't disturb
a GSM/3G/4G modem (if you have one) or GPS receiver, for instance. In order
to freely choose this frequency, you'd also need to be aware of the limits
of the sensor's internal clock tree, and make sure you still would be able
to obtain the desired frame rates for there are often corner cases where the
resulting maximum pixel clock may be substantially lower if your input
frequency goes up.

I also haven't encountered a use case for more than a single, fixed
frequency. In other words I'd keep this constant.

-- 
Regards,

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

Re: [RFC PATCH 4/7] ov7670: get xvclk

[Sakari Ailus]

Hi Hans,

On Wed, Aug 17, 2016 at 08:29:40AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Get the clock for this sensor.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  drivers/media/i2c/ov7670.c | 15 +++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index fe527b2..57adf3d 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -10,6 +10,7 @@
>   * This file may be distributed under the terms of the GNU General
>   * Public License, version 2.
>   */
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -18,6 +19,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -228,6 +230,7 @@ struct ov7670_info {
>   struct v4l2_ctrl *hue;
>   };
>   struct ov7670_format_struct *fmt;  /* Current format */
> + struct v4l2_clk *clk;
>   int min_width;  /* Filter out smaller sizes */
>   int min_height; /* Filter out smaller sizes */
>   int clock_speed;/* External clock speed (MHz) */
> @@ -1588,8 +1591,19 @@ static int ov7670_probe(struct i2c_client *client,
>   info->pclk_hb_disable = true;
>   }
>  
> + info->clk = v4l2_clk_get(>dev, "xvclk");

If you don't use this with either em28xx or SoC camera framework, you could
use (devm_)clk_get() directly.

> + if (IS_ERR(info->clk))
> + return -EPROBE_DEFER;
> + v4l2_clk_enable(info->clk);

The clock is left enabled after probe until remove. Runtime PM support would
be nice.

Can probe fail later on?

> +
> + info->clock_speed = v4l2_clk_get_rate(info->clk) / 100;
> + if (info->clock_speed < 12 ||
> + info->clock_speed > 48)
> + return -EINVAL;
> +
>   /* Make sure it's an ov7670 */
>   ret = ov7670_detect(sd);
> +
>   if (ret) {
>   v4l_dbg(1, debug, client,
>   "chip found @ 0x%x (%s) is not an ov7670 chip.\n",
> @@ -1682,6 +1696,7 @@ static int ov7670_remove(struct i2c_client *client)
>  #if defined(CONFIG_MEDIA_CONTROLLER)
>   media_entity_cleanup(>entity);
>  #endif
> + v4l2_clk_put(info->clk);
>   return 0;
>  }

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

Re: [RFC PATCH 5/7] ov7670: add devicetree support

[Sakari Ailus]

Hi Hans,

On Wed, Aug 17, 2016 at 08:29:41AM +0200, Hans Verkuil wrote:
> From: Hans Verkuil 
> 
> Add DT support. Use it to get the reset and pwdn pins (if there are any).
> Tested with one sensor requiring reset/pwdn and one sensor that doesn't
> have reset/pwdn pins.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  .../devicetree/bindings/media/i2c/ov7670.txt   | 44 +++
>  MAINTAINERS|  1 +
>  drivers/media/i2c/ov7670.c | 51 
> ++
>  3 files changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/media/i2c/ov7670.txt
> 
> diff --git a/Documentation/devicetree/bindings/media/i2c/ov7670.txt 
> b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> new file mode 100644
> index 000..3231c47
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/media/i2c/ov7670.txt
> @@ -0,0 +1,44 @@
> +* Omnivision OV7670 CMOS sensor
> +
> +The Omnivision OV7670 sensor support multiple resolutions output, such as
> +CIF, SVGA, UXGA. It also can support YUV422/420, RGB565/555 or raw RGB
> +output format.
> +
> +Required Properties:
> +- compatible: should be "ovti,ov7670"
> +- clocks: reference to the xvclk input clock.
> +- clock-names: should be "xvclk".

Where does "xvclk" come from? Why not "xclk"?

> +
> +Optional Properties:
> +- resetb-gpios: reference to the GPIO connected to the resetb pin, if any.
> +- pwdn-gpios: reference to the GPIO connected to the pwdn pin, if any.
> +
> +The device node must contain one 'port' child node for its digital output
> +video port, in accordance with the video interface bindings defined in
> +Documentation/devicetree/bindings/media/video-interfaces.txt.
> +
> +Example:
> +
> + i2c1: i2c@f0018000 {
> + status = "okay";
> +
> + ov7670: camera@0x21 {
> + compatible = "ovti,ov7670";
> + reg = <0x21>;
> + pinctrl-names = "default";
> + pinctrl-0 = <_pck0_as_isi_mck 
> _sensor_power _sensor_reset>;
> + resetb-gpios = < 11 GPIO_ACTIVE_LOW>;
> + pwdn-gpios = < 13 GPIO_ACTIVE_HIGH>;
> + clocks = <>;
> + clock-names = "xvclk";
> + assigned-clocks = <>;
> + assigned-clock-rates = <2400>;

What's the difference between assigned-clocks and just clocks?

The example in video-interfaces.txt uses "clocks" and "clock-frequency" for
the purpose.

> +

How about the regulators? This sensor requires three. You probably have
fixed regulators there if things just work.

> + port {
> + ov7670_0: endpoint {
> + remote-endpoint = <_0>;
> + bus-width = <8>;
> + };
> + };
> + };
> + };
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 20bb1d0..1fec3a6 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -8615,6 +8615,7 @@ L:  linux-media@vger.kernel.org
>  T:   git git://linuxtv.org/media_tree.git
>  S:   Maintained
>  F:   drivers/media/i2c/ov7670.c
> +F:   Documentation/devicetree/bindings/media/i2c/ov7670.txt
>  
>  ONENAND FLASH DRIVER
>  M:   Kyungmin Park 
> diff --git a/drivers/media/i2c/ov7670.c b/drivers/media/i2c/ov7670.c
> index 57adf3d..a401b99 100644
> --- a/drivers/media/i2c/ov7670.c
> +++ b/drivers/media/i2c/ov7670.c
> @@ -17,6 +17,9 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
> +#include 

You don't need at least of_gpio here. Probably linux/gpio.h is redundant as
well.

>  #include 
>  #include 
>  #include 
> @@ -231,6 +234,8 @@ struct ov7670_info {
>   };
>   struct ov7670_format_struct *fmt;  /* Current format */
>   struct v4l2_clk *clk;
> + struct gpio_desc *resetb_gpio;
> + struct gpio_desc *pwdn_gpio;
>   int min_width;  /* Filter out smaller sizes */
>   int min_height; /* Filter out smaller sizes */
>   int clock_speed;/* External clock speed (MHz) */
> @@ -1551,6 +1556,40 @@ static const struct ov7670_devtype ov7670_devdata[] = {
>   },
>  };
>  
> +static int ov7670_probe_dt(struct i2c_client *client,
> + struct ov7670_info *info)
> +{
> + /* Request the reset GPIO deasserted */
> + info->resetb_gpio = devm_gpiod_get_optional(>dev, "resetb",
> + GPIOD_OUT_LOW);
> + if (!info->resetb_gpio)
> + dev_dbg(>dev, "resetb gpio is not assigned!\n");

AFAIR the GPIO framework already complains vocally if the GPIO can't be
found.

> + else if (IS_ERR(info->resetb_gpio)) {
> + dev_info(>dev, "no resetb\n");
> + return PTR_ERR(info->resetb_gpio);
> + }
> +
> + /* Request the power 

Re: [RFC] Remove row numbers from tables in V4L2 documentation

[Laurent Pinchart]

Hi Markus,

On Wednesday 21 Sep 2016 11:24:33 Markus Heiser wrote:
> Am 21.09.2016 um 10:48 schrieb Laurent Pinchart:
> > Hello,
> > 
> > While documenting the metadata API I got annoyed by how tables were
> > converted from DocBook to ReST.
> 
> I suggested to drop them, but Mauro wanted to address this later:
> 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg100971.html

Mauro said he would take care of it for v4.9, these two patches might be our 
last occasion not to miss the release ;-) Let's see what Mauro says.

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

[PATCH] [media] rc: split nec protocol into its three variants

[Sean Young]

Currently we do not know what variant (bit length) of the nec protocol
is used, other than from guessing from the length of the scancode. Now
nec will be handled the same way as the sony protocol or the rc6 protocol;
one variant per bit length.

In the future we might want to expose the rc protocol type to userspace
and we don't want to be introducing this world of pain into userspace
too.

Signed-off-by: Sean Young 
---
 drivers/media/pci/cx23885/cx23885-input.c |  2 +-
 drivers/media/pci/cx88/cx88-input.c   |  5 +++--
 drivers/media/pci/saa7134/saa7134-input.c |  4 ++--
 drivers/media/rc/igorplugusb.c|  3 ++-
 drivers/media/rc/img-ir/img-ir-nec.c  |  6 --
 drivers/media/rc/ir-nec-decoder.c |  8 ++--
 drivers/media/rc/rc-main.c|  4 +++-
 drivers/media/usb/au0828/au0828-input.c   |  3 ++-
 drivers/media/usb/dvb-usb-v2/af9015.c |  8 ++--
 drivers/media/usb/dvb-usb-v2/af9035.c |  9 +++--
 drivers/media/usb/dvb-usb-v2/az6007.c | 13 +
 drivers/media/usb/dvb-usb-v2/lmedm04.c|  5 +++--
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c   |  9 +++--
 drivers/media/usb/dvb-usb/dib0700_core.c  |  4 +++-
 drivers/media/usb/dvb-usb/dtt200u.c   |  5 -
 include/media/rc-map.h| 31 +++
 16 files changed, 81 insertions(+), 38 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-input.c 
b/drivers/media/pci/cx23885/cx23885-input.c
index 64328d0..410c314 100644
--- a/drivers/media/pci/cx23885/cx23885-input.c
+++ b/drivers/media/pci/cx23885/cx23885-input.c
@@ -293,7 +293,7 @@ int cx23885_input_init(struct cx23885_dev *dev)
case CX23885_BOARD_TERRATEC_CINERGY_T_PCIE_DUAL:
/* Integrated CX23885 IR controller */
driver_type = RC_DRIVER_IR_RAW;
-   allowed_protos = RC_BIT_NEC;
+   allowed_protos = RC_BIT_ALL;
/* The grey Terratec remote with orange buttons */
rc_map = RC_MAP_NEC_TERRATEC_CINERGY_XS;
break;
diff --git a/drivers/media/pci/cx88/cx88-input.c 
b/drivers/media/pci/cx88/cx88-input.c
index 3f1342c..6eac81b 100644
--- a/drivers/media/pci/cx88/cx88-input.c
+++ b/drivers/media/pci/cx88/cx88-input.c
@@ -144,7 +144,8 @@ static void cx88_ir_handle_key(struct cx88_IR *ir)
scancode = RC_SCANCODE_NECX(addr, cmd);
 
if (0 == (gpio & ir->mask_keyup))
-   rc_keydown_notimeout(ir->dev, RC_TYPE_NEC, scancode, 0);
+   rc_keydown_notimeout(ir->dev, RC_TYPE_NECX, scancode,
+   0);
else
rc_keyup(ir->dev);
 
@@ -345,7 +346,7 @@ int cx88_ir_init(struct cx88_core *core, struct pci_dev 
*pci)
 * 002-T mini RC, provided with newer PV hardware
 */
ir_codes = RC_MAP_PIXELVIEW_MK12;
-   rc_type = RC_BIT_NEC;
+   rc_type = RC_BIT_NECX;
ir->gpio_addr = MO_GP1_IO;
ir->mask_keyup = 0x80;
ir->polling = 10; /* ms */
diff --git a/drivers/media/pci/saa7134/saa7134-input.c 
b/drivers/media/pci/saa7134/saa7134-input.c
index c8042c3..eff52bb 100644
--- a/drivers/media/pci/saa7134/saa7134-input.c
+++ b/drivers/media/pci/saa7134/saa7134-input.c
@@ -345,7 +345,7 @@ static int get_key_beholdm6xx(struct IR_i2c *ir, enum 
rc_type *protocol,
if (data[9] != (unsigned char)(~data[8]))
return 0;
 
-   *protocol = RC_TYPE_NEC;
+   *protocol = RC_TYPE_NECX;
*scancode = RC_SCANCODE_NECX(data[11] << 8 | data[10], data[9]);
*toggle = 0;
return 1;
@@ -1035,7 +1035,7 @@ void saa7134_probe_i2c_ir(struct saa7134_dev *dev)
dev->init_data.name = "BeholdTV";
dev->init_data.get_key = get_key_beholdm6xx;
dev->init_data.ir_codes = RC_MAP_BEHOLD;
-   dev->init_data.type = RC_BIT_NEC;
+   dev->init_data.type = RC_BIT_NECX;
info.addr = 0x2d;
break;
case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
diff --git a/drivers/media/rc/igorplugusb.c b/drivers/media/rc/igorplugusb.c
index e0c531f..5cf983b 100644
--- a/drivers/media/rc/igorplugusb.c
+++ b/drivers/media/rc/igorplugusb.c
@@ -203,7 +203,8 @@ static int igorplugusb_probe(struct usb_interface *intf,
 * This device can only store 36 pulses + spaces, which is not enough
 * for the NEC protocol and many others.
 */
-   rc->allowed_protocols = RC_BIT_ALL & ~(RC_BIT_NEC | RC_BIT_RC6_6A_20 |
+   rc->allowed_protocols = RC_BIT_ALL & ~(RC_BIT_NEC | RC_BIT_NECX |
+   RC_BIT_NEC32 | RC_BIT_RC6_6A_20 |
RC_BIT_RC6_6A_24 | RC_BIT_RC6_6A_32 | RC_BIT_RC6_MCE |
RC_BIT_SONY20 | RC_BIT_MCE_KBD | RC_BIT_SANYO);
 
diff --git 

[PATCH] [media/input] rc: report rc protocol type to userspace through input

[Sean Young]

We might want to know what protocol a remote uses when we do not know. With
this patch and another patch for v4l-utils (follows), you can do that with:

./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
Testing events. Please, press CTRL-C to abort.
1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
1474415431.689685: event type EV_SYN(0x00).

This makes RC_TYPE_* part of the ABI. We also remove the enum rc_type,
since in input-event-codes.h we cannot not use enums.

In addition, now that the input layer knows the rc protocol and scancode,
at a later point we could add a feature where keymaps could be created
based on both protocol and scancode, not just scancode.

Signed-off-by: Sean Young 
---
 drivers/media/i2c/ir-kbd-i2c.c  | 17 +
 drivers/media/pci/bt8xx/bttv-input.c|  4 +--
 drivers/media/pci/cx88/cx88-input.c |  4 +--
 drivers/media/pci/ivtv/ivtv-i2c.c   |  4 +--
 drivers/media/pci/saa7134/saa7134-input.c   | 18 +-
 drivers/media/rc/img-ir/img-ir-hw.h |  2 +-
 drivers/media/rc/ir-nec-decoder.c   |  3 +-
 drivers/media/rc/ir-rc5-decoder.c   |  3 +-
 drivers/media/rc/ir-rc6-decoder.c   |  3 +-
 drivers/media/rc/ir-sony-decoder.c  |  3 +-
 drivers/media/rc/rc-main.c  | 11 +++---
 drivers/media/usb/cx231xx/cx231xx-input.c   |  4 +--
 drivers/media/usb/dvb-usb-v2/af9015.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/af9035.c   |  3 +-
 drivers/media/usb/dvb-usb-v2/az6007.c   |  2 +-
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c |  2 +-
 drivers/media/usb/dvb-usb/dib0700_core.c|  2 +-
 drivers/media/usb/dvb-usb/dib0700_devices.c |  3 +-
 drivers/media/usb/dvb-usb/dtt200u.c |  2 +-
 drivers/media/usb/em28xx/em28xx-input.c | 15 
 drivers/media/usb/tm6000/tm6000-input.c |  3 +-
 include/media/i2c/ir-kbd-i2c.h  |  4 +--
 include/media/rc-core.h |  7 ++--
 include/media/rc-map.h  | 54 ++---
 include/uapi/linux/input-event-codes.h  | 28 +++
 25 files changed, 89 insertions(+), 114 deletions(-)

diff --git a/drivers/media/i2c/ir-kbd-i2c.c b/drivers/media/i2c/ir-kbd-i2c.c
index bf82726..f8435fa 100644
--- a/drivers/media/i2c/ir-kbd-i2c.c
+++ b/drivers/media/i2c/ir-kbd-i2c.c
@@ -62,7 +62,7 @@ module_param(debug, int, 0644);/* debug level (0,1,2) */
 
 /* --- */
 
-static int get_key_haup_common(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup_common(struct IR_i2c *ir, u32 *protocol,
   u32 *scancode, u8 *ptoggle, int size, int offset)
 {
unsigned char buf[6];
@@ -104,13 +104,13 @@ static int get_key_haup_common(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_haup(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
return get_key_haup_common (ir, protocol, scancode, toggle, 3, 0);
 }
 
-static int get_key_haup_xvr(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_haup_xvr(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
int ret;
@@ -129,7 +129,7 @@ static int get_key_haup_xvr(struct IR_i2c *ir, enum rc_type 
*protocol,
return get_key_haup_common(ir, protocol, scancode, toggle, 6, 3);
 }
 
-static int get_key_pixelview(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_pixelview(struct IR_i2c *ir, u32 *protocol,
 u32 *scancode, u8 *toggle)
 {
unsigned char b;
@@ -146,7 +146,7 @@ static int get_key_pixelview(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_fusionhdtv(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_fusionhdtv(struct IR_i2c *ir, u32 *protocol,
  u32 *scancode, u8 *toggle)
 {
unsigned char buf[4];
@@ -171,7 +171,7 @@ static int get_key_fusionhdtv(struct IR_i2c *ir, enum 
rc_type *protocol,
return 1;
 }
 
-static int get_key_knc1(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_knc1(struct IR_i2c *ir, u32 *protocol,
u32 *scancode, u8 *toggle)
 {
unsigned char b;
@@ -201,7 +201,7 @@ static int get_key_knc1(struct IR_i2c *ir, enum rc_type 
*protocol,
return 1;
 }
 
-static int get_key_avermedia_cardbus(struct IR_i2c *ir, enum rc_type *protocol,
+static int get_key_avermedia_cardbus(struct IR_i2c *ir, u32 *protocol,
 u32 *scancode, u8 *toggle)
 {
unsigned char subaddr, key, keygroup;
@@ -248,8 +248,7 @@ static int get_key_avermedia_cardbus(struct IR_i2c *ir, 
enum rc_type *protocol,
 
 

[PATCH] [media] v4l-utils: report rc protocol while testing

[Sean Young]

If you have a remote and want to see what protocol it uses, simply run
the following. That's enough to write a new keymap.

./ir-keytable  -p rc-5,nec,rc-6,jvc,sony,sanyo,sharp,xmp -t
Testing events. Please, press CTRL-C to abort.
1474415431.689685: event type EV_MSC(0x04): protocol = RC_TYPE_RC6_MCE
1474415431.689685: event type EV_MSC(0x04): scancode = 0x800f040e
1474415431.689685: event type EV_SYN(0x00).
1474415443.857071: event type EV_MSC(0x04): protocol = RC_TYPE_RC5
1474415443.857071: event type EV_MSC(0x04): scancode = 0x1e0f
1474415443.857071: event type EV_SYN(0x00).

Signed-off-by: Sean Young 
---
 utils/keytable/Makefile.am |  7 +++
 utils/keytable/keytable.c  |  6 ++
 utils/keytable/parse.h | 26 ++
 3 files changed, 39 insertions(+)

diff --git a/utils/keytable/Makefile.am b/utils/keytable/Makefile.am
index 62b90ad..73cd676 100644
--- a/utils/keytable/Makefile.am
+++ b/utils/keytable/Makefile.am
@@ -59,6 +59,13 @@ sync-with-kernel:
>> $(srcdir)/parse.h
@printf "\t{ NULL, 0}\n};\n" >> $(srcdir)/parse.h
 
+   @printf "struct parse_event rc_type_events[] = {\n" >> $(srcdir)/parse.h
+   @more $(KERNEL_DIR)/usr/include/linux/input-event-codes.h | perl -n \
+   -e 'if (m/^\#define\s+(RC_TYPE_[^\s]+)\s+(0x[\d\w]+|[\d]+)/) ' \
+   -e '{ printf "\t{\"%s\", %s},\n",$$1,$$2; }' \
+   >> $(srcdir)/parse.h
+   @printf "\t{ NULL, 0}\n};\n" >> $(srcdir)/parse.h
+
@-mkdir -p $(srcdir)/rc_keymaps
@-rm $(srcdir)/rc_keymaps/*
@-cp $(srcdir)/rc_keymaps_userspace/* $(srcdir)/rc_keymaps/
diff --git a/utils/keytable/keytable.c b/utils/keytable/keytable.c
index 3922ad2..d4c295b 100644
--- a/utils/keytable/keytable.c
+++ b/utils/keytable/keytable.c
@@ -55,6 +55,10 @@ struct input_keymap_entry_v2 {
 #define EVIOCSKEYCODE_V2   _IOW('E', 0x04, struct input_keymap_entry_v2)
 #endif
 
+#ifndef MSC_RC_TYPE
+#define MSC_RC_TYPE 6
+#endif
+
 struct keytable_entry {
u_int32_t scancode;
u_int32_t keycode;
@@ -1294,6 +1298,8 @@ static void test_event(int fd)
case EV_MSC:
if (ev[i].code == MSC_SCAN)
printf(_(": scancode = 0x%02x\n"), 
ev[i].value);
+   else if (ev[i].code == MSC_RC_TYPE)
+   printf(_(": protocol = %s\n"), 
get_event_name(rc_type_events, ev[i].value));
else
printf(_(": code = %s(0x%02x), value = 
%d\n"),
get_event_name(msc_events, 
ev[i].code),
diff --git a/utils/keytable/parse.h b/utils/keytable/parse.h
index 67eb1a6..10f58ef 100644
--- a/utils/keytable/parse.h
+++ b/utils/keytable/parse.h
@@ -25,6 +25,7 @@ struct parse_event msc_events[] = {
{"MSC_RAW", 0x03},
{"MSC_SCAN", 0x04},
{"MSC_TIMESTAMP", 0x05},
+   {"MSC_RC_TYPE", 0x06},
{"MSC_MAX", 0x07},
{ NULL, 0}
 };
@@ -639,3 +640,28 @@ struct parse_event abs_events[] = {
{"ABS_MAX", 0x3f},
{ NULL, 0}
 };
+struct parse_event rc_type_events[] = {
+   {"RC_TYPE_UNKNOWN", 0},
+   {"RC_TYPE_OTHER", 1},
+   {"RC_TYPE_RC5", 2},
+   {"RC_TYPE_RC5X", 3},
+   {"RC_TYPE_RC5_SZ", 4},
+   {"RC_TYPE_JVC", 5},
+   {"RC_TYPE_SONY12", 6},
+   {"RC_TYPE_SONY15", 7},
+   {"RC_TYPE_SONY20", 8},
+   {"RC_TYPE_NEC", 9},
+   {"RC_TYPE_NECX", 10},
+   {"RC_TYPE_NEC32", 11},
+   {"RC_TYPE_SANYO", 12},
+   {"RC_TYPE_MCE_KBD", 13},
+   {"RC_TYPE_RC6_0", 14},
+   {"RC_TYPE_RC6_6A_20", 15},
+   {"RC_TYPE_RC6_6A_24", 16},
+   {"RC_TYPE_RC6_6A_32", 17},
+   {"RC_TYPE_RC6_MCE", 18},
+   {"RC_TYPE_SHARP", 19},
+   {"RC_TYPE_XMP", 20},
+   {"RC_TYPE_CEC", 21},
+   { NULL, 0}
+};
-- 
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

Re: [RFC] Remove row numbers from tables in V4L2 documentation

[Markus Heiser]

Am 21.09.2016 um 10:48 schrieb Laurent Pinchart 
:

> Hello,
> 
> While documenting the metadata API I got annoyed by how tables were converted
> from DocBook to ReST.

I suggested to drop them, but Mauro wanted to address this later:

https://www.mail-archive.com/linux-media@vger.kernel.org/msg100971.html

-- Markus --

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

[RFC] Remove row numbers from tables in V4L2 documentation

[Laurent Pinchart]

Hello,

While documenting the metadata API I got annoyed by how tables were converted
from DocBook to ReST.

The table format currently used by the documentation is as follows:

 -  .. row 1
- row 1, entry 1
- row 1, entry 2
 -  .. row 2
- row 2, entry 1
- row 2, entry 2

The comments that include row numbers are not only useless, but make row
insertion or deletion painful.

I propose switching to the following format instead:

 * - row 1, entry 1
   - row 1, entry 2
 * - row 2, entry 1
   - row 2, entry 2

I've pushed two patches that perform the conversion to

git://linuxtv.org/pinchartl/media.git v4l2/doc

I can't post the patch series to the mailing list due to its size
(112 files changed, 15726 insertions(+), 31353 deletions(-)). However, the
bulk of the changes are performed by a patch generated by a Python script,
which should hopefully be easier to review (I realize that the regexs used in
the script are still a bit painful to review, apologies about that).

The first patch in the series performs a few manual small white space changes
for odd cases that the Python script can't handle. The second patch is the
result of running the script, which follows. I've also included it in the
patch's commit message. 

I've compared the compiled html documentation before and after the patches.
There are no differences, so I'm quite confident that the conversion was done
right.

Given the high risk of conflict, I would recommend merging the patches for
v4.9 now as no other v4.9 pull request should be queued.

--
#!/usr/bin/python

import io
import re
import sys

def process_table(fname, data):
if fname.endswith('hist-v4l2.rst'):
data = re.sub(u'\n{1,2}\t( ?)  -( ?) ?', u'\n\t\\1 -\\2', data, 
flags = re.MULTILINE)
data = re.sub(u'\n(\t|   )-  \.\. row [0-9]+\n\t  ?-( ?) 
?', u'\\1* -\\2', data, flags = re.MULTILINE)
else:
data = re.sub(u'\n{1,2}   -( ?) ?', u'\n  -\\1', data, 
flags = re.MULTILINE)
data = re.sub(u'(\n?)(\n\n-  \.\. row 1\n)', u'\n\\2', 
data, flags = re.MULTILINE)
data = re.sub(u'\n-  \.\. row [0-9]+\n  -( ?) ?', u'
* -\\1', data, flags = re.MULTILINE)
data = re.sub(u'\n-  \.\. row [0-9]+\n   \.\. 
(_[A-Z0-9_`-]*:)', u'\n-  .. \\1', data, flags = re.MULTILINE)
data = re.sub(u'\n-  \.\. (_[A-Z0-9_`-]*:)\n  -', u'
* .. \\1\n\n  -', data, flags = re.MULTILINE)
data = re.sub(u'^   - ', u'  -', data, flags = 
re.MULTILINE)
data = re.sub(u'^(\t{1,2})  ', u'\\1', data, flags = 
re.MULTILINE)

return data


def process_file(fname, data):
buf = io.StringIO(data)
output = ''
in_table = False
table_separator = 0

for line in buf.readlines():
if line.find('.. flat-table::') != -1:
in_table = True
table = ''
elif in_table and not re.match('^[\t\n]|()', line):
in_table = False
output += process_table(fname, table)

if in_table:
table += line
else:
output += line

if in_table:
in_table = False
output += process_table(fname, table)

return output


fname = sys.argv[1]

data = file(fname, 'rb').read().decode('utf-8')
data = process_file(fname, data)
file(fname, 'wb').write(data.encode('utf-8'))
--

-- 
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: g_webcam Isoch high bandwidth transfer

[Felipe Balbi]

Hi,

Bin Liu  writes:
> Hi,
>
> I am trying to check Isoch high bandwidth transfer with g_webcam.ko in
>  high-speed connection.
>
> First I hacked webcam.c as follows to enable 640x480@30fps mode.
>
> diff --git a/drivers/usb/gadget/legacy/webcam.c 
> b/drivers/usb/gadget/legacy/webcam.c
> index 72c976b..9eb315f 100644
> --- a/drivers/usb/gadget/legacy/webcam.c
> +++ b/drivers/usb/gadget/legacy/webcam.c
> @@ -191,15 +191,15 @@ static const struct UVC_FRAME_UNCOMPRESSED(3) 
> uvc_frame_yuv_360p = {
> .bFrameIndex= 1,
> .bmCapabilities = 0,
> .wWidth = cpu_to_le16(640),
> -   .wHeight= cpu_to_le16(360),
> +   .wHeight= cpu_to_le16(480),
> .dwMinBitRate   = cpu_to_le32(18432000),
> .dwMaxBitRate   = cpu_to_le32(55296000),
> -   .dwMaxVideoFrameBufferSize  = cpu_to_le32(460800),
> -   .dwDefaultFrameInterval = cpu_to_le32(66),
> +   .dwMaxVideoFrameBufferSize  = cpu_to_le32(614400),
> +   .dwDefaultFrameInterval = cpu_to_le32(33),
> .bFrameIntervalType = 3,
> -   .dwFrameInterval[0] = cpu_to_le32(66),
> -   .dwFrameInterval[1] = cpu_to_le32(100),
> -   .dwFrameInterval[2] = cpu_to_le32(500),
> +   .dwFrameInterval[0] = cpu_to_le32(33),
> +   .dwFrameInterval[1] = cpu_to_le32(66),
> +   .dwFrameInterval[2] = cpu_to_le32(100),
>  };
>
> then loaded g_webcam.ko as
>
> # modprobe g_webcam streaming_maxpacket=3072
>
> The endpoint descriptor showing on the host is
>
>   Endpoint Descriptor:
> bLength 7
> bDescriptorType 5
> bEndpointAddress 0x8d  EP 13 IN
> bmAttributes5
>   Transfer TypeIsochronous
>   Synch Type   Asynchronous
>   Usage Type   Data
> wMaxPacketSize 0x1400  3x 1024 bytes
> bInterval   1
>
> However the usb bus trace shows only one transaction with 1024-bytes packet in
> every SOF. The host only sends one IN packet in every SOF, I am expecting 2~3
> 1024-bytes transactions, since this would be required to transfer 
> 640x480@30fps
> YUV frames in high-speed.
>
> DId I miss anything in the setup?

MUSB or DWC3? This looks like a UDC bug to me. Can you show a screenshot
of your bus analyzer? When host sends IN token, are you replying with
DATA0, DATA1 or DATA2?

-- 
balbi


signature.asc
Description: PGP signature

Re: [RFC PATCH 6/7] atmel-isi: remove dependency of the soc-camera framework

[Hans Verkuil]

On 08/18/2016 07:53 AM, Wu, Songjun wrote:
> Hi Hans,
> 
> Thank you for the patch.
> 
> On 8/17/2016 14:29, Hans Verkuil wrote:
>> From: Hans Verkuil 
>>
>> This patch converts the atmel-isi driver from a soc-camera driver to a driver
>> that is stand-alone.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  drivers/media/platform/soc_camera/Kconfig |3 +-
>>  drivers/media/platform/soc_camera/atmel-isi.c | 1216 
>> +++--
>>  2 files changed, 721 insertions(+), 498 deletions(-)
>>
>> diff --git a/drivers/media/platform/soc_camera/Kconfig 
>> b/drivers/media/platform/soc_camera/Kconfig
>> index 39f6641..f74e358 100644
>> --- a/drivers/media/platform/soc_camera/Kconfig
>> +++ b/drivers/media/platform/soc_camera/Kconfig
>> @@ -54,9 +54,8 @@ config VIDEO_SH_MOBILE_CEU
>>
>>  config VIDEO_ATMEL_ISI
>>  tristate "ATMEL Image Sensor Interface (ISI) support"
>> -depends on VIDEO_DEV && SOC_CAMERA
>> +depends on VIDEO_V4L2 && VIDEO_V4L2_SUBDEV_API && OF && HAS_DMA
>>  depends on ARCH_AT91 || COMPILE_TEST
>> -depends on HAS_DMA
>>  select VIDEOBUF2_DMA_CONTIG
>>  ---help---
>>This module makes the ATMEL Image Sensor Interface available
>> diff --git a/drivers/media/platform/soc_camera/atmel-isi.c 
>> b/drivers/media/platform/soc_camera/atmel-isi.c
>> index 30211f6..9947acb 100644
>> --- a/drivers/media/platform/soc_camera/atmel-isi.c
>> +++ b/drivers/media/platform/soc_camera/atmel-isi.c


>> +
>>  static int atmel_isi_probe(struct platform_device *pdev)
>>  {
>>  int irq;
>>  struct atmel_isi *isi;
>> +struct vb2_queue *q;
>>  struct resource *regs;
>>  int ret, i;
>> -struct soc_camera_host *soc_host;
>>
>>  isi = devm_kzalloc(>dev, sizeof(struct atmel_isi), GFP_KERNEL);
>>  if (!isi) {
>> @@ -1044,20 +1216,65 @@ static int atmel_isi_probe(struct platform_device 
>> *pdev)
>>  return ret;
>>
>>  isi->active = NULL;
>> -spin_lock_init(>lock);
>> +isi->dev = >dev;
>> +mutex_init(>lock);
>> +spin_lock_init(>irqlock);
>>  INIT_LIST_HEAD(>video_buffer_list);
>>  INIT_LIST_HEAD(>dma_desc_head);
>>
>> +q = >queue;
>> +
>> +/* Initialize the top-level structure */
>> +ret = v4l2_device_register(>dev, >v4l2_dev);
>> +if (ret)
>> +return ret;
>> +
>> +isi->vdev = video_device_alloc();
>> +if (isi->vdev == NULL) {
>> +ret = -ENOMEM;
>> +goto err_vdev_alloc;
>> +}
> If video device is unregistered, the ISI driver must be reloaded when 
> registering a new video device.
> So '*vdev' can be replaced by 'vdev', or move the code above to 
> isi_graph_notify_complete.

I'm afraid I don't understand what you mean. Can you clarify?

Regards,

Hans

> 
>> +
>> +/* video node */
>> +isi->vdev->fops = _fops;
>> +isi->vdev->v4l2_dev = >v4l2_dev;
>> +isi->vdev->queue = >queue;
>> +strlcpy(isi->vdev->name, KBUILD_MODNAME, sizeof(isi->vdev->name));
>> +isi->vdev->release = video_device_release;
>> +isi->vdev->ioctl_ops = _ioctl_ops;
>> +isi->vdev->lock = >lock;
>> +isi->vdev->device_caps = V4L2_CAP_VIDEO_CAPTURE | V4L2_CAP_STREAMING |
>> +V4L2_CAP_READWRITE;
>> +video_set_drvdata(isi->vdev, isi);
>> +
>> +/* buffer queue */
>> +q->type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
>> +q->io_modes = VB2_MMAP | VB2_READ | VB2_DMABUF;
>> +q->lock = >lock;
>> +q->drv_priv = isi;
>> +q->buf_struct_size = sizeof(struct frame_buffer);
>> +q->ops = _video_qops;
>> +q->mem_ops = _dma_contig_memops;
>> +q->timestamp_flags = V4L2_BUF_FLAG_TIMESTAMP_MONOTONIC;
>> +q->min_buffers_needed = 2;
>> +q->dev = >dev;
>> +
>> +ret = vb2_queue_init(q);
>> +if (ret < 0) {
>> +dev_err(>dev, "failed to initialize VB2 queue\n");
>> +goto err_vb2_queue;
>> +}
> 
> Regards,
>   Songjun Wu
> 
> 
> --
> 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] pxa_camera: merge soc_mediabus.c into pxa_camera.c

[Hans Verkuil]

On 09/21/2016 08:37 AM, Robert Jarzmik wrote:
> Hans Verkuil  writes:
> 
>> Linking soc_mediabus into this driver causes multiple definition linker 
>> warnings
>> if soc_camera is also enabled:
>>
>>
>> drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_image_size+0x0):
>>  multiple definition of `__ksymtab_soc_mbus_image_size'
>>
>> drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_image_size+0x0):
>>  first defined here
 drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0):
  multiple definition of `__ksymtab_soc_mbus_samples_per_pixel'
>>
>> drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0):
>>  first defined here
>>drivers/media/platform/soc_camera/built-in.o: In function 
>> `soc_mbus_config_compatible':
>>(.text+0x3840): multiple definition of `soc_mbus_config_compatible'
>>drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x134): first 
>> defined here
>>
>> Since we really don't want to have to use any of the soc-camera code this 
>> patch
>> copies the relevant code and data structures from soc_mediabus and renames 
>> it to pxa_mbus_*.
>>
>> The large table of formats has been culled a bit, removing formats that are 
>> not supported
>> by this driver.
>>
>> Signed-off-by: Hans Verkuil 
>> Cc: Robert Jarzmik 
> 
> Hi Hans,
> 
> I wonder why you chose to copy-paste this code instead of adding in the 
> Kconfig
> a "depends on !SOC_CAMERA". Any specific reason ? As this will have to be 
> dealt
> with later anyway as you pointed out earlier, this format translation I mean, 
> I
> was wondering if this was the best approach.

I thought about that, but that would make it impossible to COMPILE_TEST both the
pxa and the soc_camera driver. In addition, the pxa and soc_camera are the only
drivers that use this, and I prefer to just merge that code into pxa so that it 
can
be modified independently from soc_camera.

I really want to remove all dependencies to soc_camera. That will also make it 
easier
to refactor soc_camera once I get the atmel-isi driver out of soc_camera.

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] pxa_camera: merge soc_mediabus.c into pxa_camera.c

[Robert Jarzmik]

Hans Verkuil  writes:

> Linking soc_mediabus into this driver causes multiple definition linker 
> warnings
> if soc_camera is also enabled:
>
>
> drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_image_size+0x0):
>  multiple definition of `__ksymtab_soc_mbus_image_size'
>
> drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_image_size+0x0):
>  first defined here
>>> drivers/media/platform/soc_camera/built-in.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0):
>>>  multiple definition of `__ksymtab_soc_mbus_samples_per_pixel'
>
> drivers/media/platform/soc_camera/soc_mediabus.o:(___ksymtab+soc_mbus_samples_per_pixel+0x0):
>  first defined here
>drivers/media/platform/soc_camera/built-in.o: In function 
> `soc_mbus_config_compatible':
>(.text+0x3840): multiple definition of `soc_mbus_config_compatible'
>drivers/media/platform/soc_camera/soc_mediabus.o:(.text+0x134): first 
> defined here
>
> Since we really don't want to have to use any of the soc-camera code this 
> patch
> copies the relevant code and data structures from soc_mediabus and renames it 
> to pxa_mbus_*.
>
> The large table of formats has been culled a bit, removing formats that are 
> not supported
> by this driver.
>
> Signed-off-by: Hans Verkuil 
> Cc: Robert Jarzmik 

Hi Hans,

I wonder why you chose to copy-paste this code instead of adding in the Kconfig
a "depends on !SOC_CAMERA". Any specific reason ? As this will have to be dealt
with later anyway as you pointed out earlier, this format translation I mean, I
was wondering if this was the best approach.

Cheers.

--
Robert
--
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] pxa_camera: remove duplicated include from pxa_camera.c

[Robert Jarzmik]

Wei Yongjun  writes:

> From: Wei Yongjun 
>
> Remove duplicated include.
>
> Signed-off-by: Wei Yongjun 
Acked-by: Robert Jarzmik 

Cheers.

-- 
Robert
--
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] pxa_camera: fix error return code in pxa_camera_probe()

[Robert Jarzmik]

Wei Yongjun  writes:

> From: Wei Yongjun 
>
> Fix to return error code -ENODEV from dma_request_slave_channel_compat()
> error handling case instead of 0, as done elsewhere in this function.
>
> Also fix to release resources in v4l2_clk_register() error handling.
>
> Signed-off-by: Wei Yongjun 
Acked-by: Robert Jarzmik 

Cheers.

--
Robert
--
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] platform: pxa_camera: add VIDEO_V4L2 dependency

[Robert Jarzmik]

Arnd Bergmann  writes:

> Moving the pxa_camera driver from soc_camera lots the implied
> VIDEO_V4L2 Kconfig dependency, and building the driver without
> V4L2 results in a kernel that cannot link:
>
> drivers/media/platform/pxa_camera.o: In function `pxa_camera_remove':
> pxa_camera.c:(.text.pxa_camera_remove+0x10): undefined reference to 
> `v4l2_clk_unregister'
> pxa_camera.c:(.text.pxa_camera_remove+0x18): undefined reference to 
> `v4l2_device_unregister'
> drivers/media/platform/pxa_camera.o: In function `pxa_camera_probe':
> pxa_camera.c:(.text.pxa_camera_probe+0x458): undefined reference to 
> `v4l2_of_parse_endpoint'
> drivers/media/v4l2-core/videobuf2-core.o: In function `__enqueue_in_driver':
> drivers/media/v4l2-core/videobuf2-core.o: In function `vb2_core_streamon':
> videobuf2-core.c:(.text.vb2_core_streamon+0x1b4): undefined reference to 
> `v4l_vb2q_enable_media_source'
> drivers/media/v4l2-core/videobuf2-v4l2.o: In function `vb2_ioctl_reqbufs':
> videobuf2-v4l2.c:(.text.vb2_ioctl_reqbufs+0xc): undefined reference to 
> `video_devdata'
>
> This adds back an explicit dependency.
That looks right to me.

Acked-by: Robert Jarzmik 

Cheers.

--
Robert
--
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