date:20151220

Re: [PATCH/RFC 26/48] videodev2.h: Add request field to v4l2_pix_format_mplane

2015-12-20 Thread Laurent Pinchart

Hi Geert,

On Friday 18 December 2015 18:37:51 Geert Uytterhoeven wrote:
> On Fri, Dec 18, 2015 at 6:16 PM, Laurent Pinchart wrote:
> >> > @@ -1987,7 +1988,8 @@ struct v4l2_pix_format_mplane {
> >> > __u8ycbcr_enc;
> >> > __u8quantization;
> >> > __u8xfer_func;
> >> > -   __u8reserved[7];
> >> > +   __u8reserved[3];
> >> > +   __u32   request;
> >> 
> >> I think I mentioned this before: I feel uncomfortable using 4 bytes of
> >> the reserved fields when the request ID is limited to 16 bits anyway.
> > 
> > I'm still unsure whether request IDs should be 16 or 32 bits long. If we
> > go for 16 bits then I'll of course make this field a __u16.
> > 
> >> I would prefer a __u16 here. Also put the request field *before* the
> >> reserved array, not after.
> > 
> > The reserved array isn't aligned to a 32 bit (or even 16 bit) boundary. I
> > can put the request field before it, with a 8 bit hole before the field.
>
> There's no alignment at all due to:
>
> >> >  } __attribute__ ((packed));

Oops, indeed. Still, isn't it better to keep 16-bit or 32-bit values aligned 
to 16-bit or 32-bit boundaries ?

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

[GIT PULL 4.5] rtl2832u changes

2015-12-20 Thread Antti Palosaari


The following changes since commit 0aff8a894a2be4c22e6414db33061153a4b35bc9:

  [media] uvcvideo: small cleanup in uvc_video_clock_update() 
(2015-12-18 15:21:35 -0200)


are available in the git repository at:

  git://linuxtv.org/anttip/media_tree.git rtl2832u_pull

for you to fetch changes up to bbed859d68218c043fa88ccdd9785d9567d8fb5d:

  rtl2832: do not filter out slave TS null packets (2015-12-20 04:57:20 
+0200)



Antti Palosaari (3):
  rtl28xxu: return demod reg page from driver cache
  rtl2832: print reg number on error case
  rtl2832: do not filter out slave TS null packets

 drivers/media/dvb-frontends/rtl2832.c   | 21 ++---
 drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 16 +++-
 2 files changed, 17 insertions(+), 20 deletions(-)

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

Re: per-frame camera metadata (again)

2015-12-20 Thread Laurent Pinchart

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

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

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

> > > 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 also know, that
> > > several proprietary solutions have been developed and are in use in
> > > various projects.
> > > 
> > > I think a general agreement has been, that such data has to be passed
> > > via a buffer queue. But there are a few possibilities there too. Below
> > > are some:
> > > 
> > > 1. Multiplanar. A separate plane is dedicated to metadata. Pros: (a)
> > > metadata is already associated to specific frames, which they correspond
> > > to. Cons: (a) a correct implementation would specify image plane fourcc
> > > separately from any metadata plane format description, but we currently
> > > don't support per-plane format specification.
> > 
> > This only makes sense if the data actually comes in via DMA and if it is
> > large enough to make it worth the effort of implementing this. As you say,
> > it will require figuring out how to do per-frame fourcc.
> > 
> > It also only makes sense if the metadata comes in at the same time as the
> > frame.
> > 
> > > 2. Separate buffer queues. Pros: (a) no need to extend multiplanar
> > > buffer implementation. Cons: (a) more difficult synchronisation with
> > > image frames, (b) still need to work out a way to specify the metadata
> > > version.
> > > 
> > > Any further options? Of the above my choice would go with (1) but with a
> > > dedicated metadata plane in struct vb2_buffer.
> > 
> > 3. Use the request framework and return the metadata as control(s). Since
> > controls can be associated with events when they change you can subscribe
> > to such events. Note: currently I haven't implemented such events for
> > request controls since I am not certainly how it

Re: [PATCH 2/3] mn88472: add work around for failing firmware loading

2015-12-20 Thread Antti Palosaari


Hello
I am not sure if problem is I2C adapter/bus or that demodulator I2C 
slave. If it is demod, then that workaround is correct place, but if it 
is not, then that is wrong and I2C adapter repeating logic should be used.


I did some testing again... Loading mn88472 firmware 1000 times, it failed:
61 times RC polling disabled
68 times RC polling enabled
83 times RC polling enabled, but repeated failed message due to that patch

I don't want apply that patch until I find some time myself to examine 
that problem - or someone else does some study to point out whats wrong. 
There is many things to test in order to get better understanding.


regards
Antti

On 11/29/2015 04:10 AM, Benjamin Larsson wrote:

Sometimes the firmware fails to load because of an i2c error.
Work around that by adding retry logic. This kind of logic
also exist in the binary driver and failures have been observed
there also. Thus this seems to be a property of the hardware
and a fix like this is needed.

Signed-off-by: Benjamin Larsson 
---
  drivers/staging/media/mn88472/mn88472.c | 15 ++-
  1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/mn88472/mn88472.c 
b/drivers/staging/media/mn88472/mn88472.c
index cf2e96b..80c5807 100644
--- a/drivers/staging/media/mn88472/mn88472.c
+++ b/drivers/staging/media/mn88472/mn88472.c
@@ -282,7 +282,7 @@ static int mn88472_init(struct dvb_frontend *fe)
int ret, len, remaining;
const struct firmware *fw = NULL;
u8 *fw_file = MN88472_FIRMWARE;
-   unsigned int tmp;
+   unsigned int tmp, retry_cnt;

dev_dbg(>dev, "\n");

@@ -330,9 +330,22 @@ static int mn88472_init(struct dvb_frontend *fe)
if (len > (dev->i2c_wr_max - 1))
len = dev->i2c_wr_max - 1;

+   /* I2C transfers during firmware load might fail sometimes,
+* just retry in that case. 4 consecutive failures have
+* been observed thus a retry limit of 20 is used.
+*/
+   retry_cnt = 20;
+retry:
ret = regmap_bulk_write(dev->regmap[0], 0xf6,
>data[fw->size - remaining], len);
if (ret) {
+   if (retry_cnt) {
+   dev_dbg(>dev,
+   "i2c error, retry %d triggered\n", retry_cnt);
+   retry_cnt--;
+   usleep_range(200, 1);
+   goto retry;
+   }
dev_err(>dev,
"firmware download failed=%d\n", ret);
goto firmware_release;



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

Re: [PATCH/RFC 27/48] v4l2-subdev.h: Add request field to format and selection structures

2015-12-20 Thread Laurent Pinchart

Hi Hans,

On Friday 18 December 2015 12:20:54 Hans Verkuil wrote:
> On 12/17/2015 09:40 AM, Laurent Pinchart wrote:
> > Let userspace specify a request ID when getting or setting formats or
> > selection rectangles.
> > 
> > From a userspace point of view the API change is minimized and doesn't
> > require any new ioctl.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  include/uapi/linux/v4l2-subdev.h | 15 +--
> >  1 file changed, 13 insertions(+), 2 deletions(-)
> > 
> > diff --git a/include/uapi/linux/v4l2-subdev.h
> > b/include/uapi/linux/v4l2-subdev.h index dbce2b554e02..2f1691ce9df5
> > 100644
> > --- a/include/uapi/linux/v4l2-subdev.h
> > +++ b/include/uapi/linux/v4l2-subdev.h
> > @@ -32,10 +32,12 @@
> >   * enum v4l2_subdev_format_whence - Media bus format type
> >   * @V4L2_SUBDEV_FORMAT_TRY: try format, for negotiation only
> >   * @V4L2_SUBDEV_FORMAT_ACTIVE: active format, applied to the device
> > + * @V4L2_SUBDEV_FORMAT_REQUEST: format stored in request
> >   */
> >  enum v4l2_subdev_format_whence {
> > V4L2_SUBDEV_FORMAT_TRY = 0,
> > V4L2_SUBDEV_FORMAT_ACTIVE = 1,
> > +   V4L2_SUBDEV_FORMAT_REQUEST = 2,
> >  };
> >  
> >  /**
> > @@ -43,12 +45,17 @@ enum v4l2_subdev_format_whence {
> >   * @which: format type (from enum v4l2_subdev_format_whence)
> >   * @pad: pad number, as reported by the media API
> >   * @format: media bus format (format code and frame size)
> > + * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
> > + * @reserved2: for future use, set to zero for now
> > + * @reserved: for future use, set to zero for now
> >   */
> >  struct v4l2_subdev_format {
> > __u32 which;
> > __u32 pad;
> > struct v4l2_mbus_framefmt format;
> > -   __u32 reserved[8];
> > +   __u16 request;
> > +   __u16 reserved2;
> > +   __u32 reserved[7];
> 
> I would prefer:
> 
>   __u16 request;
>   __u16 reserved[15];
> 
> >  };
> >  
> >  /**
> > @@ -139,6 +146,8 @@ struct v4l2_subdev_frame_interval_enum {
> >   * defined in v4l2-common.h; V4L2_SEL_TGT_* .
> >   * @flags: constraint flags, defined in v4l2-common.h; V4L2_SEL_FLAG_*.
> >   * @r: coordinates of the selection window
> > + * @request: request ID (when which is set to V4L2_SUBDEV_FORMAT_REQUEST)
> > + * @reserved2: for future use, set to zero for now
> >   * @reserved: for future use, set to zero for now
> >   *
> >   * Hardware may use multiple helper windows to process a video stream.
> > @@ -151,7 +160,9 @@ struct v4l2_subdev_selection {
> > __u32 target;
> > __u32 flags;
> > struct v4l2_rect r;
> > -   __u32 reserved[8];
> > +   __u16 request;
> > +   __u16 reserved2;
> > +   __u32 reserved[7];
> 
> Ditto.
> 
> Generally apps do a memset of reserved, and that will just keep working.
> But adding a reserved2 field means that they have to explicitly set
> reserved2 to 0, which won't happen.

Agreed. Consider it fixed.

> >  };
> >  
> >  /* Backwards compatibility define --- to be removed */

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

cron job: media_tree daily build: ERRORS

2015-12-20 Thread 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:   Mon Dec 21 04:00:15 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: ERRORS
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: ERRORS
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/Monday.log

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

http://www.xs4all.nl/~hverkuil/spec/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: [PATCH] [media] videobuf2: avoid memory leak on errors

2015-12-20 Thread Marek Szyprowski


Hello,

On 2015-12-18 17:14, Mauro Carvalho Chehab wrote:

As reported by smatch:
drivers/media/v4l2-core/videobuf2-core.c:2415 __vb2_init_fileio() warn: 
possible memory leak of 'fileio'

While here, avoid the usage of sizeof(struct foo_struct).

Signed-off-by: Mauro Carvalho Chehab 


Acked-by: Marek Szyprowski 


---
  drivers/media/v4l2-core/videobuf2-core.c | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index e6890d47cdcb..c5d49d7a0d76 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2406,13 +2406,15 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
(read) ? "read" : "write", count, q->fileio_read_once,
q->fileio_write_immediately);
  
-	fileio = kzalloc(sizeof(struct vb2_fileio_data), GFP_KERNEL);

+   fileio = kzalloc(sizeof(*fileio), GFP_KERNEL);
if (fileio == NULL)
return -ENOMEM;
  
  	fileio->b = kzalloc(q->buf_struct_size, GFP_KERNEL);

-   if (fileio->b == NULL)
+   if (fileio->b == NULL) {
+   kfree(fileio);
return -ENOMEM;
+   }
  
  	fileio->read_once = q->fileio_read_once;

fileio->write_immediately = q->fileio_write_immediately;


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute 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: [PATCH 1/3] rtl2832: add support for slave ts pid filter

2015-12-20 Thread Antti Palosaari


Patch looks acceptable, but it is broken in a mean it does not apply :(

$ wget -O - https://patchwork.linuxtv.org/patch/32030/mbox/ | git am -3 -s
--2015-12-21 04:40:46--  https://patchwork.linuxtv.org/patch/32030/mbox/
Resolving patchwork.linuxtv.org (patchwork.linuxtv.org)... 130.149.80.248
Connecting to patchwork.linuxtv.org 
(patchwork.linuxtv.org)|130.149.80.248|:443... connected.

HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/plain]
Saving to: ‘STDOUT’

-   [ <=> 


  ]   2.73K  --.-KB/s   in 0s

2015-12-21 04:40:46 (60.4 MB/s) - written to stdout [2796]

Applying: rtl2832: add support for slave ts pid filter
fatal: corrupt patch at line 39
Repository lacks necessary blobs to fall back on 3-way merge.
Cannot fall back to three-way merge.
Patch failed at 0001 rtl2832: add support for slave ts pid filter
The copy of the patch that failed is found in:
   /home/crope/linuxtv/code/media_tree/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
[crope@localhost media_tree]$ patch -p1 < .git/rebase-apply/patch
patching file drivers/media/dvb-frontends/rtl2832.c
patch:  malformed patch at line 39: @@ -1178,14 +1185,22 @@ static 
int rtl2832_pid_filter(struct dvb_frontend *fe, u8 index, u16 pid,


[crope@localhost media_tree]$ git am --abort
[crope@localhost media_tree]$ git am ~/\[PATCH\ 1_3\]\ rtl2832\:\ add\ 
support\ for\ slave\ ts\ pid\ filter.eml

Applying: rtl2832: add support for slave ts pid filter
fatal: corrupt patch at line 39
Patch failed at 0001 rtl2832: add support for slave ts pid filter
The copy of the patch that failed is found in:
   /home/crope/linuxtv/code/media_tree/.git/rebase-apply/patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
[crope@localhost media_tree]$ git am --abort

Antti

On 11/29/2015 04:10 AM, Benjamin Larsson wrote:

Signed-off-by: Benjamin Larsson 
---
  drivers/media/dvb-frontends/rtl2832.c  | 21 ++---
  drivers/media/dvb-frontends/rtl2832_priv.h |  1 +
  2 files changed, 19 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 78b87b2..e054079 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -407,6 +407,7 @@ static int rtl2832_init(struct dvb_frontend *fe)
/* start statistics polling */
schedule_delayed_work(>stat_work, msecs_to_jiffies(2000));
dev->sleeping = false;
+   dev->slave_ts = false;

return 0;
  err:
@@ -1122,6 +1123,8 @@ static int rtl2832_enable_slave_ts(struct i2c_client 
*client)
if (ret)
goto err;

+   dev->slave_ts = true;
+
return 0;
  err:
dev_dbg(>dev, "failed=%d\n", ret);
@@ -1143,7 +1146,11 @@ static int rtl2832_pid_filter_ctrl(struct dvb_frontend 
*fe, int onoff)
else
u8tmp = 0x00;

-   ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
+   if (dev->slave_ts)
+   ret = rtl2832_update_bits(client, 0x021, 0xc0, u8tmp);
+   else
+   ret = rtl2832_update_bits(client, 0x061, 0xc0, u8tmp);
if (ret)
goto err;

@@ -1178,14 +1185,22 @@ static int rtl2832_pid_filter(struct dvb_frontend *fe, 
u8 index, u16 pid,
buf[1] = (dev->filters >>  8) & 0xff;
buf[2] = (dev->filters >> 16) & 0xff;
buf[3] = (dev->filters >> 24) & 0xff;
-   ret = rtl2832_bulk_write(client, 0x062, buf, 4);
+
+   if (dev->slave_ts)
+   ret = rtl2832_bulk_write(client, 0x022, buf, 4);
+   else
+   ret = rtl2832_bulk_write(client, 0x062, buf, 4);
if (ret)
goto err;

/* add PID */
buf[0] = (pid >> 8) & 0xff;
buf[1] = (pid >> 0) & 0xff;
-   ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
+
+   if (dev->slave_ts)
+   ret = rtl2832_bulk_write(client, 0x026 + 2 * index, buf, 2);
+   else
+   ret = rtl2832_bulk_write(client, 0x066 + 2 * index, buf, 2);
if (ret)
goto err;

diff --git a/drivers/media/dvb-frontends/rtl2832_priv.h 
b/drivers/media/dvb-frontends/rtl2832_priv.h
index 5dcd3a4..efc230f 100644
--- a/drivers/media/dvb-frontends/rtl2832_priv.h
+++ b/drivers/media/dvb-frontends/rtl2832_priv.h
@@ -46,6 +46,7 @@ struct rtl2832_dev {
bool sleeping;
struct delayed_work i2c_gate_work;
unsigned long filters; /* PID filter */
+   bool slave_ts;
  };

  struct rtl2832_reg_entry {



--
http://palosaari.fi/
--
To unsubscribe from this list: send the line

Some build questions

2015-12-20 Thread Maury Markowitz

I’m looking over the page here:

http://www.linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers

There are a number of passages on this page which could use a little 
clarification. But before I jump in, I want to be sure I really understand them.

1) "This seems to be fixed on a fully updated systtem (5 July 2011)"

Given that this warning appears to be talking about a problem that was fixed 
almost five years ago, would anyone object if this was moved to a note section 
at the bottom of the page? And is the second note still an issue or is that 
long gone too?

2) "Note: The build script will clone the entire media-tree.git, which will 
take some time”

We should be precise with our terminology here. I believe this is trying to say:

"This build script will copy the entire linux source code tree from our git 
repository into the 'media' directory."

Is that correct? Or do some of you actually have something called "media_tree"?

3) "make tar DIR=”

Am I correct this passage is referring to the same thing as (2)? That is, 
"media -git tree” is the same thing as "media-tree.git"? If so, would it not be 
proper to use the same terminology here?

And am I correct in understanding that this step, the tar/untar, is replacing 
the original "media" directory I got from v4l with the new one in the 
external/custom/other kernel?--
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] usbtv: discard redundant video fields

2015-12-20 Thread Nikola Forró

There are many dropped fields with some sources, leading to many
redundant fields without counterparts. When this redundant field
is odd, a new frame is pushed containing this odd field interleaved
with whatever was left in the buffer, causing video artifacts.

Do not push a new frame after processing every odd field, but do it
only after those which come after an even field.

Signed-off-by: Nikola Forró 
---
 drivers/media/usb/usbtv/usbtv-video.c | 33 +++--
 drivers/media/usb/usbtv/usbtv.h   |  1 +
 2 files changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/media/usb/usbtv/usbtv-video.c 
b/drivers/media/usb/usbtv/usbtv-video.c
index e645c9d..a20fd60 100644
--- a/drivers/media/usb/usbtv/usbtv-video.c
+++ b/drivers/media/usb/usbtv/usbtv-video.c
@@ -312,20 +312,24 @@ static void usbtv_image_chunk(struct usbtv *usbtv, __be32 
*chunk)
usbtv_chunk_to_vbuf(frame, [1], chunk_no, odd);
usbtv->chunks_done++;
 
-   /* Last chunk in a frame, signalling an end */
-   if (odd && chunk_no == usbtv->n_chunks-1) {
-   int size = vb2_plane_size(>vb.vb2_buf, 0);
-   enum vb2_buffer_state state = usbtv->chunks_done ==
-   usbtv->n_chunks ?
-   VB2_BUF_STATE_DONE :
-   VB2_BUF_STATE_ERROR;
-
-   buf->vb.field = V4L2_FIELD_INTERLACED;
-   buf->vb.sequence = usbtv->sequence++;
-   v4l2_get_timestamp(>vb.timestamp);
-   vb2_set_plane_payload(>vb.vb2_buf, 0, size);
-   vb2_buffer_done(>vb.vb2_buf, state);
-   list_del(>list);
+   /* Last chunk in a field */
+   if (chunk_no == usbtv->n_chunks-1) {
+   /* Last chunk in a frame, signalling an end */
+   if (odd && !usbtv->last_odd) {
+   int size = vb2_plane_size(>vb.vb2_buf, 0);
+   enum vb2_buffer_state state = usbtv->chunks_done ==
+   usbtv->n_chunks ?
+   VB2_BUF_STATE_DONE :
+   VB2_BUF_STATE_ERROR;
+
+   buf->vb.field = V4L2_FIELD_INTERLACED;
+   buf->vb.sequence = usbtv->sequence++;
+   v4l2_get_timestamp(>vb.timestamp);
+   vb2_set_plane_payload(>vb.vb2_buf, 0, size);
+   vb2_buffer_done(>vb.vb2_buf, state);
+   list_del(>list);
+   }
+   usbtv->last_odd = odd;
}
 
spin_unlock_irqrestore(>buflock, flags);
@@ -640,6 +644,7 @@ static int usbtv_start_streaming(struct vb2_queue *vq, 
unsigned int count)
if (usbtv->udev == NULL)
return -ENODEV;
 
+   usbtv->last_odd = 1;
usbtv->sequence = 0;
return usbtv_start(usbtv);
 }
diff --git a/drivers/media/usb/usbtv/usbtv.h b/drivers/media/usb/usbtv/usbtv.h
index 19cb8bf..161b38d 100644
--- a/drivers/media/usb/usbtv/usbtv.h
+++ b/drivers/media/usb/usbtv/usbtv.h
@@ -95,6 +95,7 @@ struct usbtv {
int width, height;
int n_chunks;
int iso_size;
+   int last_odd;
unsigned int sequence;
struct urb *isoc_urbs[USBTV_ISOC_TRANSFERS];
 
-- 
2.6.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

JUST REPLY YES ONLY

2015-12-20 Thread Richard

Hello

My proposal will give us 2 million in seven days reply "YES" for details.

Regards,

Richard.
--
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 3/3] rtl28xxu: change Astrometa DVB-T2 to always use hardware pid filters

2015-12-20 Thread Benjamin Larsson


On 12/20/2015 04:36 AM, Antti Palosaari wrote:

Moikka!
I did some testing and I cannot see reason to force hw pid filter for
that device. I assume you somehow think it does not work without
filtering, but I think it does.



[... proof that I was wrong ...]



So point me the reason hw PID filters need to be forced.


The only reason would be that I suspected that high rates would not be 
possible over the bridge and that this was the default mode for the 
binary driver but as you proved that the bridge is able to support the 
rate this patch can be nacked.




regards
Antti


MvH
Benjamin Larsson
--
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: soc_camera: rcar_vin: Add R-Car Gen3 support

2015-12-20 Thread Yoshihiro Kaneko

Hi,

2015-12-14 2:43 GMT+09:00 Sergei Shtylyov :
> On 12/13/2015 06:27 PM, Yoshihiro Kaneko wrote:
>
>> From: Yoshihiko Mori 
>>
>> Add chip identification for R-Car Gen3.
>>
>> Signed-off-by: Yoshihiko Mori 
>> Signed-off-by: Yoshihiro Kaneko 
>
> [...]
>>
>> diff --git a/drivers/media/platform/soc_camera/rcar_vin.c
>> b/drivers/media/platform/soc_camera/rcar_vin.c
>> index 5d90f39..29e7ca4 100644
>> --- a/drivers/media/platform/soc_camera/rcar_vin.c
>> +++ b/drivers/media/platform/soc_camera/rcar_vin.c
>> @@ -143,6 +143,7 @@
>>   #define RCAR_VIN_BT656(1 << 3)
>>
>>   enum chip_id {
>> +   RCAR_GEN3,
>> RCAR_GEN2,
>> RCAR_H1,
>> RCAR_M1,
>> @@ -1846,6 +1847,7 @@ static struct soc_camera_host_ops rcar_vin_host_ops
>> = {
>>
>>   #ifdef CONFIG_OF
>>   static const struct of_device_id rcar_vin_of_table[] = {
>> +   { .compatible = "renesas,vin-r8a7795", .data = (void *)RCAR_GEN3
>> },
>
>
>I don't see where this is checked in the driver. Shouldn't we just use
> gen2?

I'd like to withdraw this patch now.
I intend to post the series patch including this patch at another day.

>
> MBR, Sergei
>

Thanks,
kaneko
--
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/RFC 26/48] videodev2.h: Add request field to v4l2_pix_format_mplane

[GIT PULL 4.5] rtl2832u changes

Re: per-frame camera metadata (again)

Re: [PATCH 2/3] mn88472: add work around for failing firmware loading

Re: [PATCH/RFC 27/48] v4l2-subdev.h: Add request field to format and selection structures

cron job: media_tree daily build: ERRORS

Re: [PATCH] [media] videobuf2: avoid memory leak on errors

Re: [PATCH 1/3] rtl2832: add support for slave ts pid filter

Some build questions

[PATCH] usbtv: discard redundant video fields

JUST REPLY YES ONLY

Re: [PATCH 3/3] rtl28xxu: change Astrometa DVB-T2 to always use hardware pid filters

Re: [PATCH] media: soc_camera: rcar_vin: Add R-Car Gen3 support

13 matches

Site Navigation

Mail list logo

Footer information