Re: [PATCH 4/5 RESEND] si470x-i2c: Add optional reset-gpio support

[Michael Nazzareno Trimarchi]

Hi

On Fri, Dec 7, 2018 at 12:12 PM Hans Verkuil  wrote:
>
> Subject: [PATCH 4/5] si470x-i2c: Add optional reset-gpio support
> Date: Wed,  5 Dec 2018 16:47:49 +0100
> From: Paweł Chmiel 
> To: mche...@kernel.org, robh...@kernel.org, mark.rutl...@arm.com
> CC: hverk...@xs4all.nl, fischerdougl...@gmail.com, keesc...@chromium.org, 
> linux-media@vger.kernel.org, linux-ker...@vger.kernel.org,
> devicet...@vger.kernel.org, Paweł Chmiel 
>
> If reset-gpio is defined, use it to bring device out of reset.
> Without this, it's not possible to access si470x registers.
>
> Signed-off-by: Paweł Chmiel 
> ---
> For some reason this patch was not picked up by patchwork. Resending to see if
> it is picked up now.
> ---
>  drivers/media/radio/si470x/radio-si470x-i2c.c | 15 +++
>  drivers/media/radio/si470x/radio-si470x.h |  1 +
>  2 files changed, 16 insertions(+)
>
> diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c 
> b/drivers/media/radio/si470x/radio-si470x-i2c.c
> index a7ac09c55188..15eea2b2c90f 100644
> --- a/drivers/media/radio/si470x/radio-si470x-i2c.c
> +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
> @@ -28,6 +28,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>   #include "radio-si470x.h"
> @@ -392,6 +393,17 @@ static int si470x_i2c_probe(struct i2c_client *client,
> radio->videodev.release = video_device_release_empty;
> video_set_drvdata(>videodev, radio);
>  +  radio->gpio_reset = devm_gpiod_get_optional(>dev, "reset",
> +   GPIOD_OUT_LOW);
> +   if (IS_ERR(radio->gpio_reset)) {
> +   retval = PTR_ERR(radio->gpio_reset);
> +   dev_err(>dev, "Failed to request gpio: %d\n", retval);
> +   goto err_all;
> +   }
> +
> +   if (radio->gpio_reset)
> +   gpiod_set_value(radio->gpio_reset, 1);
> +
> /* power up : need 110ms */
> radio->registers[POWERCFG] = POWERCFG_ENABLE;
> if (si470x_set_register(radio, POWERCFG) < 0) {
> @@ -478,6 +490,9 @@ static int si470x_i2c_remove(struct i2c_client *client)
> video_unregister_device(>videodev);
>  +  if (radio->gpio_reset)
> +   gpiod_set_value(radio->gpio_reset, 0);

I have a question for you. If the gpio is the last of the bank
acquired for this cpu, when you put to 0, then the gpio will
be free on remove and the clock of the logic will be deactivated so I
think that you don't have any
garantee that the state will be 0

Michael

> +
> return 0;
>  }
>  diff --git a/drivers/media/radio/si470x/radio-si470x.h 
> b/drivers/media/radio/si470x/radio-si470x.h
> index 35fa0f3bbdd2..6fd6a399cb77 100644
> --- a/drivers/media/radio/si470x/radio-si470x.h
> +++ b/drivers/media/radio/si470x/radio-si470x.h
> @@ -189,6 +189,7 @@ struct si470x_device {
>   #if IS_ENABLED(CONFIG_I2C_SI470X)
> struct i2c_client *client;
> +   struct gpio_desc *gpio_reset;
>  #endif
>  };
>  -- 2.17.1
>


-- 
| Michael Nazzareno Trimarchi Amarula Solutions BV |
| COO  -  Founder  Cruquiuskade 47 |
| +31(0)851119172 Amsterdam 1018 AM NL |
|  [`as] http://www.amarulasolutions.com   |

[PATCH 1/2] [media] v4l2-pci-skeleton: depend on CONFIG_SAMPLES

[Michael Tretter]

Commit 0185f8501762 ("[media] samples: v4l: from Documentation to
samples directory") moved the v4l2-pci-skeleton driver to the samples
directory. The samples are only be built, if CONFIG_SAMPLES is enabled.

Therefore, VIDEO_PCI_SKELETON is not enough to build the
v4l2-pci-skeleton driver, but SAMPLES needs to be enabled, too. Let
VIDEO_PCI_SKELETON depend on SAMPLES.

Signed-off-by: Michael Tretter 
---
 drivers/media/v4l2-core/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/media/v4l2-core/Kconfig b/drivers/media/v4l2-core/Kconfig
index b97090e85996..c0940f5c69b4 100644
--- a/drivers/media/v4l2-core/Kconfig
+++ b/drivers/media/v4l2-core/Kconfig
@@ -30,6 +30,7 @@ config VIDEO_FIXED_MINOR_RANGES
 config VIDEO_PCI_SKELETON
tristate "Skeleton PCI V4L2 driver"
depends on PCI
+   depends on SAMPLES
depends on VIDEO_V4L2 && VIDEOBUF2_CORE
depends on VIDEOBUF2_MEMOPS && VIDEOBUF2_DMA_CONTIG
---help---
-- 
2.19.1

[PATCH 0/2] Fix v4l2-pci-skeleton driver

[Michael Tretter]

This series fixes the v4l2-pci-skeleton driver to make it usable as a
reference for new v4l2 drivers again.

The driver was skipped when replacing vb2_buffer with vb2_v4l2_buffers for
v4l2 drivers. Moreover, VIDEO_PCI_SKELETON did not ensure that it is
actually build.

Michael Tretter (2):
  [media] v4l2-pci-skeleton: depend on CONFIG_SAMPLES
  [media] v4l2-pci-skeleton: replace vb2_buffer with vb2_v4l2_buffer

 drivers/media/v4l2-core/Kconfig |  1 +
 samples/v4l/v4l2-pci-skeleton.c | 11 ++-
 2 files changed, 7 insertions(+), 5 deletions(-)

-- 
2.19.1

[PATCH 2/2] [media] v4l2-pci-skeleton: replace vb2_buffer with vb2_v4l2_buffer

[Michael Tretter]

Commit 2d7007153f0c ("[media] media: videobuf2: Restructure vb2_buffer")
replaced vb2_buffer with vb2_v4l2_buffer in all v4l2 drivers. The
restructuring skipped the v4l2-pci-skeleton, probably because it resides
outside the drivers directory.

The v4l2_buf_ops assume that the passed buffer is a vb2_v4l2_buffer.
This is not the case if the skel_buffer is based on vb2_buffer instead
of vb2_v4l2_buffer.

Replace vb2_buffer with vb2_v4l2_buffer in the skeleton to make sure
that future drivers that are based on the skeleton use vb2_v4l2_buffer.

Signed-off-by: Michael Tretter 
---
 samples/v4l/v4l2-pci-skeleton.c | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/samples/v4l/v4l2-pci-skeleton.c b/samples/v4l/v4l2-pci-skeleton.c
index f520e3aef9c6..27ec30952cfa 100644
--- a/samples/v4l/v4l2-pci-skeleton.c
+++ b/samples/v4l/v4l2-pci-skeleton.c
@@ -80,13 +80,13 @@ struct skeleton {
 };
 
 struct skel_buffer {
-   struct vb2_buffer vb;
+   struct vb2_v4l2_buffer vb;
struct list_head list;
 };
 
-static inline struct skel_buffer *to_skel_buffer(struct vb2_buffer *vb2)
+static inline struct skel_buffer *to_skel_buffer(struct vb2_v4l2_buffer *vbuf)
 {
-   return container_of(vb2, struct skel_buffer, vb);
+   return container_of(vbuf, struct skel_buffer, vb);
 }
 
 static const struct pci_device_id skeleton_pci_tbl[] = {
@@ -212,8 +212,9 @@ static int buffer_prepare(struct vb2_buffer *vb)
  */
 static void buffer_queue(struct vb2_buffer *vb)
 {
+   struct vb2_v4l2_buffer *vbuf = to_vb2_v4l2_buffer(vb);
struct skeleton *skel = vb2_get_drv_priv(vb->vb2_queue);
-   struct skel_buffer *buf = to_skel_buffer(vb);
+   struct skel_buffer *buf = to_skel_buffer(vbuf);
unsigned long flags;
 
spin_lock_irqsave(>qlock, flags);
@@ -232,7 +233,7 @@ static void return_all_buffers(struct skeleton *skel,
 
spin_lock_irqsave(>qlock, flags);
list_for_each_entry_safe(buf, node, >buf_list, list) {
-   vb2_buffer_done(>vb, state);
+   vb2_buffer_done(>vb.vb2_buf, state);
list_del(>list);
}
spin_unlock_irqrestore(>qlock, flags);
-- 
2.19.1

Re: [PATCH] lirc.4: remove ioctls and feature bits which were never implemented

[Michael Kerrisk (man-pages)]

Hello Sean,

On 4/23/18 12:26 PM, Sean Young wrote:> The lirc header file included
ioctls and feature bits which were never
> implemented by any driver. They were removed in commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d55f09abe24b4dfadab246b6f217da547361cdb6
>
> Signed-off-by: Sean Young 

Thanks for your persistence.

Mauro, Alec, thanks for your input.

Patch Applied.

Thanks!

Michael
> ---
>  man4/lirc.4 | 92 
> ++---
>  1 file changed, 2 insertions(+), 90 deletions(-)
>
> diff --git a/man4/lirc.4 b/man4/lirc.4
> index 1e94a7163..3adff55f1 100644
> --- a/man4/lirc.4
> +++ b/man4/lirc.4
> @@ -78,9 +78,7 @@ The package reflects a timeout; see the
>  .B LIRC_SET_REC_TIMEOUT_REPORTS
>  ioctl.
>  .\"
> -.SS Reading input with the
> -.B LIRC_MODE_LIRCCODE
> -drivers
> +.SS Reading input with the LIRC_MODE_LIRCCODE drivers
>  .PP
>  In the \fBLIRC_MODE_LIRCCODE\fR
>  mode, the data returned by
> @@ -204,17 +202,11 @@ Currently serves no purpose since only
>  .BR LIRC_MODE_PULSE
>  is supported.
>  .TP
> -.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)"
> -Get the modulation frequency (Hz).
> -.TP
>  .BR LIRC_SET_SEND_CARRIER " (\fIint\fP)"
>  Set the modulation frequency.
>  The argument is the frequency (Hz).
>  .TP
> -.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)"
> -Get the modulation frequency used when decoding (Hz).
> -.TP
> -.BR SET_SEND_DUTY_CYCLE " (\fIint\fP)"
> +.BR LIRC_SET_SEND_DUTY_CYCLE " (\fIint\fP)"
>  Set the carrier duty cycle.
>  .I val
>  is a number in the range [0,100] which
> @@ -284,36 +276,6 @@ By default this should be turned off.
>  .BR LIRC_GET_REC_RESOLUTION " (\fIvoid\fP)"
>  Return the driver resolution (microseconds).
>  .TP
> -.BR LIRC_GET_MIN_FILTER_PULSE " (\fIvoid\fP)", " " \
> -LIRC_GET_MAX_FILTER_PULSE " (\fIvoid\fP)"
> -Some devices are able to filter out spikes in the incoming signal
> -using given filter rules.
> -These ioctls return the hardware capabilities that describe the bounds
> -of the possible filters.
> -Filter settings depend on the IR protocols that are expected.
> -.BR lircd (8)
> -derives the settings from all protocols definitions found in its
> -.BR lircd.conf (5)
> -config file.
> -.TP
> -.BR LIRC_GET_MIN_FILTER_SPACE " (\fIvoid\fP)", " " \
> -LIRC_GET_MAX_FILTER_SPACE " (\fIvoid\fP)"
> -See
> -.BR LIRC_GET_MIN_FILTER_PULSE .
> -.TP
> -.BR LIRC_SET_REC_FILTER " (\fIint\fP)"
> -Pulses/spaces shorter than this (microseconds) are filtered out by
> -hardware.
> -.TP
> -.BR LIRC_SET_REC_FILTER_PULSE " (\fIint\fP)", " " \
> -LIRC_SET_REC_FILTER_SPACE " (\fIint\fP)"
> -Pulses/spaces shorter than this (microseconds) are filtered out by
> -hardware.
> -If filters cannot be set independently for pulse/space, the
> -corresponding ioctls must return an error and
> -.BR LIRC_SET_REC_FILTER
> -should be used instead.
> -.TP
>  .BR LIRC_SET_TRANSMITTER_MASK
>  Enable the set of transmitters specified in
>  .IR val ,
> @@ -343,32 +305,6 @@ carrier reports.
>  In that case, it will be disabled as soon as you disable carrier reports.
>  Trying to disable a wide band receiver while carrier reports are active
>  will do nothing.
> -.TP
> -.BR LIRC_SETUP_START " (\fIvoid\fP), " LIRC_SETUP_END " (\fIvoid\fP)"
> -Setting of several driver parameters can be optimized by bracketing
> -the actual ioctl calls
> -.BR LIRC_SETUP_START
> -and
> -.BR LIRC_SETUP_END .
> -When a driver receives a
> -.BR LIRC_SETUP_START
> -ioctl, it can choose to not commit further setting changes to the
> -hardware until a
> -.BR LIRC_SETUP_END
> -is received.
> -But this is open to the driver implementation and every driver
> -must also handle parameter changes which are not encapsulated by
> -.BR LIRC_SETUP_START
> -and
> -.BR LIRC_SETUP_END .
> -Drivers can also choose to ignore these ioctls.
> -.TP
> -.BR LIRC_NOTIFY_DECODE " (\fIvoid\fP)"
> -This ioctl is called by
> -.BR lircd (8)
> -whenever a successful decoding of an incoming IR signal is possible.
> -This can be used by supporting hardware to give visual user
> -feedback, for example by flashing an LED.
>  .\"
>  .SH FEATURES
>  .PP
> @@ -378,14 +314,6 @@ The
>  ioctl returns a bit mask describing features of the driver.
>  The following bits may be returned in the mask:
>  .TP
> -.BR LIRC_CAN_REC_RAW
> -The driver is capable of receiving using
> -.BR LIRC_MODE_RAW .
> -.TP
> -.BR LI

Re: [PATCH] Documentation/media: uapi: Explicitly say there are no Invariant Sections

[Michael Ira Krufky]

On Thu, Aug 9, 2018 at 11:19 AM Mauro Carvalho Chehab
 wrote:
>
> Em Fri, 3 Aug 2018 15:41:53 +0100
> Ben Hutchings  escreveu:
>
> > The GNU Free Documentation License allows for a work to specify
> > Invariant Sections that are not allowed to be modified.  (Debian
> > considers that this makes such works non-free.)
> >
> > The Linux Media Infrastructure userspace API documentation does not
> > specify any such sections, but it also doesn't say there are none (as
> > is recommended by the license text).  Make it explicit that there are
> > none.
> >
> > References: https://bugs.debian.org/698668
> > Signed-off-by: Ben Hutchings 
>
> From my side:
>
> Signed-off-by: Mauro Carvalho Chehab 
>
> (I'm waiting for more SoBs before merging this)
>
> I pinged some developers that don't use to listen to the media ML
> as often as they used to do, and to the sub-maintainers, via the
> sub-mainainers ML, and got some SoBs. Let me add them to this thread:
>
> Gerd:
>
> Signed-off-by: Gerd Hoffmann 
>
> Hans:
>
> Signed-off-by: Hans Verkuil 
>
> Sylwester:
>
> Signed-off-by: Sylwester Nawrocki 
>
> Johannes:
>
> "I think I didn't contribute to that documentation?
>  Anyway, just in case: I agree with the change to
>  forbid adding invariant sections."
>
> Signed-off-by: Johannes Stezenbach 
>
> Ralph:
>
> "I also do not think there is anything left in there which I contributed.
>  The original documentation up to 2002 probably is copyright of Convergence.
>
>  But I agree with the change to forbid adding invariant sections regarding
>  anything in that documentation that might be my copyright."
>
> Signed-off-by: Ralph Metzler 
>
> Markus:
>
> "Ralph> I also do not think there is anything left in there which I
>  Ralph> contributed.  The original documentation up to 2002
>  Ralph> probably is copyright of Convergence.
>  The same is true for me.
>
>  I also agree with the change to forbid adding invariant sections
>  regarding anything in that documentation that might be my copyright."
>
> Signed-off-by: Marcus Metzler 
>
>
> > ---
> >  Documentation/media/media_uapi.rst | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
> >
> > diff --git a/Documentation/media/media_uapi.rst 
> > b/Documentation/media/media_uapi.rst
> > index 28eb35a1f965..5198ff24a094 100644
> > --- a/Documentation/media/media_uapi.rst
> > +++ b/Documentation/media/media_uapi.rst
> > @@ -10,9 +10,9 @@ Linux Media Infrastructure userspace API
> >
> >  Permission is granted to copy, distribute and/or modify this document
> >  under the terms of the GNU Free Documentation License, Version 1.1 or
> > -any later version published by the Free Software Foundation. A copy of
> > -the license is included in the chapter entitled "GNU Free Documentation
> > -License".
> > +any later version published by the Free Software Foundation, with no
> > +Invariant Sections. A copy of the license is included in the chapter
> > +entitled "GNU Free Documentation License".

The original founders / authors / coders of LinuxDVB have signed off
on this, and that is most important to me.

Signed-off-by: Michael Ira Krufky 

[GIT PULL] [RESEND] urgent em28xx bug fixes for immediate merge

[Michael Ira Krufky]

...previous email failed to indicate `em28xx` branch.  My bad.  Please merge.

The following changes since commit 7ba2eb72f843fb79de1857a39f9a7e8006f8133b:

  media: dib0700: add code comment (2018-07-25 14:55:59 -0400)

are available in the Git repository at:

  ssh://mkru...@linuxtv.org:/home/mkrufky/git/dvb.git em28xx

for you to fetch changes up to f7869d3cd1705c1d7f883d364a1fe52085d219c4:

  em28xx: Remove duplicate PID (2018-07-26 07:42:52 -0400)


Brad Love (3):
  em28xx: Fix dual transport stream operation
  em28xx: Fix DualHD disconnect oops
  em28xx: Remove duplicate PID

 drivers/media/usb/em28xx/em28xx-cards.c | 6 +++---
 drivers/media/usb/em28xx/em28xx-dvb.c   | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)
On Thu, Jul 26, 2018 at 8:27 AM Michael Ira Krufky  wrote:
>
> This is a resend of https://patchwork.linuxtv.org/patch/51227/ - I
> forgot to include an email subject in the pull request :-/
>
> Hello Mauro,
>
> The following three patches from Brad Love are urgently needed for
> merge ASAP.  One just removes a duplicated PID, so it's not as
> important but should be merged ASAP nonetheless.  The other two fix an
> OOPS along with broken dual transport streaming operation.  Please
> merge ASAP.
>
> The following changes since commit 7ba2eb72f843fb79de1857a39f9a7e8006f8133b:
>
>   media: dib0700: add code comment (2018-07-25 14:55:59 -0400)
>
> are available in the Git repository at:
>
>   ssh://linuxtv.org:/home/mkrufky/git/dvb.git
>
> for you to fetch changes up to f7869d3cd1705c1d7f883d364a1fe52085d219c4:
>
>   em28xx: Remove duplicate PID (2018-07-26 07:42:52 -0400)
>
> 
> Brad Love (3):
>   em28xx: Fix dual transport stream operation
>   em28xx: Fix DualHD disconnect oops
>   em28xx: Remove duplicate PID
>
>  drivers/media/usb/em28xx/em28xx-cards.c | 6 +++---
>  drivers/media/usb/em28xx/em28xx-dvb.c   | 4 +++-
>  2 files changed, 6 insertions(+), 4 deletions(-)

[PULL] urgent em28xx bug fixes for immediate merge

[Michael Ira Krufky]

This is a resend of https://patchwork.linuxtv.org/patch/51227/ - I
forgot to include an email subject in the pull request :-/

Hello Mauro,

The following three patches from Brad Love are urgently needed for
merge ASAP.  One just removes a duplicated PID, so it's not as
important but should be merged ASAP nonetheless.  The other two fix an
OOPS along with broken dual transport streaming operation.  Please
merge ASAP.

The following changes since commit 7ba2eb72f843fb79de1857a39f9a7e8006f8133b:

  media: dib0700: add code comment (2018-07-25 14:55:59 -0400)

are available in the Git repository at:

  ssh://linuxtv.org:/home/mkrufky/git/dvb.git

for you to fetch changes up to f7869d3cd1705c1d7f883d364a1fe52085d219c4:

  em28xx: Remove duplicate PID (2018-07-26 07:42:52 -0400)


Brad Love (3):
  em28xx: Fix dual transport stream operation
  em28xx: Fix DualHD disconnect oops
  em28xx: Remove duplicate PID

 drivers/media/usb/em28xx/em28xx-cards.c | 6 +++---
 drivers/media/usb/em28xx/em28xx-dvb.c   | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

[no subject]

[Michael Ira Krufky]

Hello Mauro,

The following three patches from Brad Love are urgently needed for
merge ASAP.  One just removes a duplicated PID, so it's not as
important but should be merged ASAP nonetheless.  The other two fix an
OOPS along with broken dual transport streaming operation.  Please
merge ASAP.

The following changes since commit 7ba2eb72f843fb79de1857a39f9a7e8006f8133b:

  media: dib0700: add code comment (2018-07-25 14:55:59 -0400)

are available in the Git repository at:

  ssh://linuxtv.org:/home/mkrufky/git/dvb.git

for you to fetch changes up to f7869d3cd1705c1d7f883d364a1fe52085d219c4:

  em28xx: Remove duplicate PID (2018-07-26 07:42:52 -0400)


Brad Love (3):
  em28xx: Fix dual transport stream operation
  em28xx: Fix DualHD disconnect oops
  em28xx: Remove duplicate PID

 drivers/media/usb/em28xx/em28xx-cards.c | 6 +++---
 drivers/media/usb/em28xx/em28xx-dvb.c   | 4 +++-
 2 files changed, 6 insertions(+), 4 deletions(-)

Re: [PATCH 1/2] media: dvb: convert tuner_info frequencies to Hz

[Michael Büsch]

On Wed,  4 Jul 2018 23:46:56 -0300
Mauro Carvalho Chehab  wrote:

> diff --git a/drivers/media/tuners/fc0011.c b/drivers/media/tuners/fc0011.c
> index 145407dee3db..a983899c6b0b 100644
> --- a/drivers/media/tuners/fc0011.c
> +++ b/drivers/media/tuners/fc0011.c
> @@ -472,10 +472,10 @@ static int fc0011_get_bandwidth(struct dvb_frontend 
> *fe, u32 *bandwidth)
>  
>  static const struct dvb_tuner_ops fc0011_tuner_ops = {
>   .info = {
> - .name   = "Fitipower FC0011",
> + .name = "Fitipower FC0011",
>  
> - .frequency_min  = 4500,
> - .frequency_max  = 10,
> + .frequency_min_hz =   45 * MHz,
> + .frequency_max_hz = 1000 * MHz,
>   },
>  
>   .release= fc0011_release,

Acked-by: Michael Büsch 

What about a GHz definition for 1000 * MHz?

-- 
Michael


pgpiV7kEiTOKJ.pgp
Description: OpenPGP digital signature

Re: [PATCH 1/2] media: dvb: convert tuner_info frequencies to Hz

[Michael Ira Krufky]

On Wed, Jul 4, 2018 at 10:47 PM Mauro Carvalho Chehab
 wrote:
>
> Right now, satellite tuner drivers specify frequencies in kHz,
> while terrestrial/cable ones specify in Hz. That's confusing
> for developers.
>
> However, the main problem is that universal tuners capable
> of handling both satellite and non-satelite delivery systems
> are appearing. We end by needing to hack the drivers in
> order to support such hybrid tuners.
>
> So, convert everything to specify tuner frequencies in Hz.
>
> Plese notice that a similar patch is also needed for frontends.
>
> Signed-off-by: Mauro Carvalho Chehab 

I'm okay with the idea behind this, but I'm not sure I'm behind the
way it's being done.  What if, rather than changing every tuner range
to HZ, instead, to add a new field to indicate the magnitude. This can
be Hz, KHz, MHz, etc

This way, the ranges would remain unaltered, and userspace can remain
unchanged.  Although the patch as-is may solve a problem, it might be
better to solve it with less impact.

-Mike Krufky

Re: [PATCH] media: dvb: fix noderef.cocci warnings

[Michael Ira Krufky]

On Thu, Jul 5, 2018 at 1:50 AM kbuild test robot  wrote:
>
> From: kbuild test robot 
>
> drivers/media/dvb-core/dvb_frontend.c:2396:18-24: ERROR: application of 
> sizeof to pointer
>
>  sizeof when applied to a pointer typed expression gives the size of
>  the pointer
>
> Generated by: scripts/coccinelle/misc/noderef.cocci
>
> Fixes: 07acff734698 ("media: dvb: represent min/max/step/tolerance freqs in 
> Hz")
> CC: Mauro Carvalho Chehab 
> Signed-off-by: kbuild test robot 
> ---
>
>  dvb_frontend.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -2393,7 +2393,7 @@ static int dvb_frontend_handle_ioctl(str
>
> case FE_GET_INFO: {
> struct dvb_frontend_info *info = parg;
> -   memset(info, 0, sizeof(info));
> +   memset(info, 0, sizeof(*info));
>
> dvb_frontend_get_frequency_limits(fe, >frequency_min, 
> >frequency_max);
> strcpy(info->name, fe->ops.info.name);

Nice catch!  (even for a robot)  I think we'll find more of these
sprinkled throughout the tree.

Reviewed-by: Michael Ira Krufky 

Re: [PATCH] lirc.4: remove ioctls and feature bits which were never implemented

[Michael Kerrisk (man-opages)]

[CCing original author of this page]


On 04/23/2018 12:26 PM, Sean Young wrote:

The lirc header file included ioctls and feature bits which were never
implemented by any driver. They were removed in commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d55f09abe24b4dfadab246b6f217da547361cdb6


Alec, does this patch look okay to you?

Cheers,

Michael


Signed-off-by: Sean Young <s...@mess.org>
---
  man4/lirc.4 | 92 ++---
  1 file changed, 2 insertions(+), 90 deletions(-)

diff --git a/man4/lirc.4 b/man4/lirc.4
index 1e94a7163..3adff55f1 100644
--- a/man4/lirc.4
+++ b/man4/lirc.4
@@ -78,9 +78,7 @@ The package reflects a timeout; see the
  .B LIRC_SET_REC_TIMEOUT_REPORTS
  ioctl.
  .\"
-.SS Reading input with the
-.B LIRC_MODE_LIRCCODE
-drivers
+.SS Reading input with the LIRC_MODE_LIRCCODE drivers
  .PP
  In the \fBLIRC_MODE_LIRCCODE\fR
  mode, the data returned by
@@ -204,17 +202,11 @@ Currently serves no purpose since only
  .BR LIRC_MODE_PULSE
  is supported.
  .TP
-.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)"
-Get the modulation frequency (Hz).
-.TP
  .BR LIRC_SET_SEND_CARRIER " (\fIint\fP)"
  Set the modulation frequency.
  The argument is the frequency (Hz).
  .TP
-.BR LIRC_GET_SEND_CARRIER " (\fIvoid\fP)"
-Get the modulation frequency used when decoding (Hz).
-.TP
-.BR SET_SEND_DUTY_CYCLE " (\fIint\fP)"
+.BR LIRC_SET_SEND_DUTY_CYCLE " (\fIint\fP)"
  Set the carrier duty cycle.
  .I val
  is a number in the range [0,100] which
@@ -284,36 +276,6 @@ By default this should be turned off.
  .BR LIRC_GET_REC_RESOLUTION " (\fIvoid\fP)"
  Return the driver resolution (microseconds).
  .TP
-.BR LIRC_GET_MIN_FILTER_PULSE " (\fIvoid\fP)", " " \
-LIRC_GET_MAX_FILTER_PULSE " (\fIvoid\fP)"
-Some devices are able to filter out spikes in the incoming signal
-using given filter rules.
-These ioctls return the hardware capabilities that describe the bounds
-of the possible filters.
-Filter settings depend on the IR protocols that are expected.
-.BR lircd (8)
-derives the settings from all protocols definitions found in its
-.BR lircd.conf (5)
-config file.
-.TP
-.BR LIRC_GET_MIN_FILTER_SPACE " (\fIvoid\fP)", " " \
-LIRC_GET_MAX_FILTER_SPACE " (\fIvoid\fP)"
-See
-.BR LIRC_GET_MIN_FILTER_PULSE .
-.TP
-.BR LIRC_SET_REC_FILTER " (\fIint\fP)"
-Pulses/spaces shorter than this (microseconds) are filtered out by
-hardware.
-.TP
-.BR LIRC_SET_REC_FILTER_PULSE " (\fIint\fP)", " " \
-LIRC_SET_REC_FILTER_SPACE " (\fIint\fP)"
-Pulses/spaces shorter than this (microseconds) are filtered out by
-hardware.
-If filters cannot be set independently for pulse/space, the
-corresponding ioctls must return an error and
-.BR LIRC_SET_REC_FILTER
-should be used instead.
-.TP
  .BR LIRC_SET_TRANSMITTER_MASK
  Enable the set of transmitters specified in
  .IR val ,
@@ -343,32 +305,6 @@ carrier reports.
  In that case, it will be disabled as soon as you disable carrier reports.
  Trying to disable a wide band receiver while carrier reports are active
  will do nothing.
-.TP
-.BR LIRC_SETUP_START " (\fIvoid\fP), " LIRC_SETUP_END " (\fIvoid\fP)"
-Setting of several driver parameters can be optimized by bracketing
-the actual ioctl calls
-.BR LIRC_SETUP_START
-and
-.BR LIRC_SETUP_END .
-When a driver receives a
-.BR LIRC_SETUP_START
-ioctl, it can choose to not commit further setting changes to the
-hardware until a
-.BR LIRC_SETUP_END
-is received.
-But this is open to the driver implementation and every driver
-must also handle parameter changes which are not encapsulated by
-.BR LIRC_SETUP_START
-and
-.BR LIRC_SETUP_END .
-Drivers can also choose to ignore these ioctls.
-.TP
-.BR LIRC_NOTIFY_DECODE " (\fIvoid\fP)"
-This ioctl is called by
-.BR lircd (8)
-whenever a successful decoding of an incoming IR signal is possible.
-This can be used by supporting hardware to give visual user
-feedback, for example by flashing an LED.
  .\"
  .SH FEATURES
  .PP
@@ -378,14 +314,6 @@ The
  ioctl returns a bit mask describing features of the driver.
  The following bits may be returned in the mask:
  .TP
-.BR LIRC_CAN_REC_RAW
-The driver is capable of receiving using
-.BR LIRC_MODE_RAW .
-.TP
-.BR LIRC_CAN_REC_PULSE
-The driver is capable of receiving using
-.BR LIRC_MODE_PULSE .
-.TP
  .BR LIRC_CAN_REC_MODE2
  The driver is capable of receiving using
  .BR LIRC_MODE_MODE2 .
@@ -426,10 +354,6 @@ The driver supports
  The driver supports
  .BR LIRC_SET_REC_TIMEOUT .
  .TP
-.BR LIRC_CAN_SET_REC_FILTER
-The driver supports
-.BR LIRC_SET_REC_FILTER .
-.TP
  .BR LIRC_CAN_MEASURE_CARRIER
  The driver supports measuring of the modulation frequency using
  .BR LIRC_SET_MEASURE_CARRIER_MODE .
@@ -438,22 +362,10 @@ The driver supports measuring of the modulation frequenc

Re: [PULL] DVB-mmap Kconfig typo fix

[Michael Ira Krufky]

On Thu, Mar 1, 2018 at 7:55 AM, Michael Ira Krufky <mkru...@linuxtv.org> wrote:
> Please pull the following typo fix in the Kconfig for dvb-mmap:
>
> The following changes since commit 4df7ac5f42087dc9bcbed04b5cada0f025fbf9ef:
>
>   drivers/media/Kconfig: typo: replace `with` with `which` (2018-02-15
> 08:01:22 -0500)
>
> are available in the git repository at:
>
>   git://linuxtv.org/mkrufky/dvb.git dvb-mmap-v3
>
> for you to fetch changes up to 4df7ac5f42087dc9bcbed04b5cada0f025fbf9ef:
>
>   drivers/media/Kconfig: typo: replace `with` with `which` (2018-02-15
> 08:01:22 -0500)

I realize I never sent the actual patch to the list.  inline below:

Author: Michael Ira Krufky <mkru...@linuxtv.org>
Date:   Tue Jan 16 22:16:12 2018 -0500

drivers/media/Kconfig: typo: replace `with` with `which`

Signed-off-by: Michael Ira Krufky <mkru...@linuxtv.org>

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index 372c074bb1b9..86c1a190d946 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -151,7 +151,7 @@ config DVB_MMAP
select VIDEOBUF2_VMALLOC
default n
help
- This option enables DVB experimental memory-mapped API, with
+ This option enables DVB experimental memory-mapped API, which
  reduces the number of context switches to read DVB buffers, as
  the buffers can use mmap() syscalls.

[PULL] DVB-mmap Kconfig typo fix

[Michael Ira Krufky]

Mauro,

Please pull the following typo fix in the Kconfig for dvb-mmap:

The following changes since commit 4df7ac5f42087dc9bcbed04b5cada0f025fbf9ef:

  drivers/media/Kconfig: typo: replace `with` with `which` (2018-02-15
08:01:22 -0500)

are available in the git repository at:

  git://linuxtv.org/mkrufky/dvb.git dvb-mmap-v3

for you to fetch changes up to 4df7ac5f42087dc9bcbed04b5cada0f025fbf9ef:

  drivers/media/Kconfig: typo: replace `with` with `which` (2018-02-15
08:01:22 -0500)



 Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Cheers,

Michael Ira Krufky

Re: [RFC PATCH] v4l2-event/dev: wakeup pending events when unregistering

[Michael Walz]

Hi Hans,


On 18.01.2018 16:13, Hans Verkuil wrote:

Only apply the change to v4l2_dev.c, ignore the changes to
v4l2_event. I think it is sufficient to just apply that bit.


I tried both variants, with changes to v4l2_event and without. Both did
not work out of the box. I think the problem is in the wake-up-condition in

ret = wait_event_interruptible(fh->wait, fh->navailable != 0);

As long as we will check only fh->navailable, the thread will continue
to sleep. I inserted an abort-condition to the wait

!video_is_registered(fh->vdev)

and some printk messages. Is is a dirty hack, but now my VIDIOC_DQEVENT 
ioctl returns. Instead I get a bunch of errors in dmesg. Can you have a 
look, please?



diff -Naur drivers.orig/media/v4l2-core/v4l2-dev.c 
drivers/media/v4l2-core/v4l2-dev.c
--- drivers.orig/media/v4l2-core/v4l2-dev.c	2018-01-22 
13:22:47.881815404 +0100

+++ drivers/media/v4l2-core/v4l2-dev.c  2018-01-22 13:23:18.541315363 +0100
@@ -1015,6 +1015,9 @@
  */
 void video_unregister_device(struct video_device *vdev)
 {
+   unsigned long flags;
+   struct v4l2_fh *fh;
+
/* Check if vdev was ever registered at all */
if (!vdev || !video_is_registered(vdev))
return;
@@ -1025,7 +1028,15 @@
 */
clear_bit(V4L2_FL_REGISTERED, >flags);
mutex_unlock(_lock);
+
+   printk("MWALZ wake threads\n");
+spin_lock_irqsave(>fh_lock, flags);
+   list_for_each_entry(fh, >fh_list, list)
+   wake_up_all(>wait);
+   spin_unlock_irqrestore(>fh_lock, flags);
+
device_unregister(>dev);
+printk("MWALZ unregistered devices\n");
 }
 EXPORT_SYMBOL(video_unregister_device);

diff -Naur drivers.orig/media/v4l2-core/v4l2-event.c 
drivers/media/v4l2-core/v4l2-event.c
--- drivers.orig/media/v4l2-core/v4l2-event.c	2018-01-22 
13:22:47.881815404 +0100

+++ drivers/media/v4l2-core/v4l2-event.c2018-01-22 13:23:14.301384509 
+0100
@@ -35,12 +35,18 @@
 {
struct v4l2_kevent *kev;
unsigned long flags;
+   int ret = 0;

spin_lock_irqsave(>vdev->fh_lock, flags);

+   if (!video_is_registered(fh->vdev)) {
+printk("MWALZ device not registered!\n");
+   ret = -ENODEV;
+   goto err;
+   }
if (list_empty(>available)) {
-   spin_unlock_irqrestore(>vdev->fh_lock, flags);
-   return -ENOENT;
+   ret = -ENOENT;
+   goto err;
}

WARN_ON(fh->navailable == 0);
@@ -53,10 +59,10 @@
*event = kev->event;
kev->sev->first = sev_pos(kev->sev, 1);
kev->sev->in_use--;
-
+err:
spin_unlock_irqrestore(>vdev->fh_lock, flags);

-   return 0;
+   return ret;
 }

 int v4l2_event_dequeue(struct v4l2_fh *fh, struct v4l2_event *event,
@@ -73,16 +79,20 @@

do {
ret = wait_event_interruptible(fh->wait,
-  fh->navailable != 0);
+  (fh->navailable != 0) ||
+ (!video_is_registered(fh->vdev)));
+printk("MWALZ woken up\n");
if (ret < 0)
break;

ret = __v4l2_event_dequeue(fh, event);
} while (ret == -ENOENT);

+printk("Try to get the lock\n");
if (fh->vdev->lock)
mutex_lock(fh->vdev->lock);

+printk("MWALZ return event DQ\n");
return ret;
 }
 EXPORT_SYMBOL_GPL(v4l2_event_dequeue);






[ 1566.982359] usb 2-2.1: USB disconnect, device number 7
[ 1566.982827] MWALZ wake threads
[ 1566.983411] MWALZ woken up
[ 1566.983421] MWALZ device not registered!
[ 1566.983426] Try to get the lock
[ 1566.983430] MWALZ return event DQ
[ 1566.993157] MWALZ unregistered devices
[ 1569.227177] sysfs group 'power' not found for kobject 'event8'
[ 1569.227201] [ cut here ]
[ 1569.227214] WARNING: CPU: 1 PID: 2364 at 
/kernel-source//fs/sysfs/group.c:237 sysfs_remove_group+0x46/0x7b
[ 1569.227216] Modules linked in: bnep hid_sensor_gyro_3d 
hid_sensor_accel_3d hid_sensor_trigger hid_sensor_iio_common 
industrialio_triggered_buffer kfifo_buf hid_sensor_hub intel_ishtp_hid 
hid_multitouch input_leds asus_nb_wmi asus_wmi gpio_keys 
intel_powerclamp pcspkr btsdio brcmfmac brcmutil cfg80211 uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 ax88179_178a 
videobuf2_core usbnet videodev hid_generic mei_txe lpc_ich mei 
intel_ish_ipc processor_thermal_device intel_ishtp intel_soc_dts_iosf 
thermal wmi intel_hid sparse_keymap axp20x_i2c axp20x 
intel_soc_pmic_bxtwc intel_pmc_ipc i2c_hid int3400_thermal 
int3403_thermal battery soc_button_array int340x_thermal_zone 
acpi_thermal_rel int3406_thermal ac acpi_pad efivarfs
[ 1569.227341] CPU: 1 PID: 2364 Comm: TabletVP Tainted: GW 
4.12.10-custom #3
[ 1569.227343] Hardware name: ASUSTeK COMPUTER INC. T100HAN/T100HAN, 
BIOS T100HAN.221 05/18/2016

[ 

Re: V4L2 v4l2_event_dequeue blocks forever when USB/UVC disconnects

[Michael Walz]

On 18.01.2018 11:18, Hans Verkuil wrote:

Are you able to compile the kernel if I give you a patch to test?

It should be a fairly easy fix.


Hi Hans,

I have a working yocto setup. Should be no problem to integrate the patch.

Thanks a lot and best regards,
Michael

V4L2 v4l2_event_dequeue blocks forever when USB/UVC disconnects

[Michael Walz]

Hi there,

I am currently developing a USB/UVC camera and I think I discovered an 
issue in the V4L2 event system. In userland I have implemented a thread 
for the VIDIOC_DQEVENT ioctl, which blocks until there is a new event. 
This works perfectly until the camera is disconnected during operation:



In v4l2_event_dequeue() the thread is put to sleep with

wait_event_interruptible(fh->wait, fh->navailable != 0)


and woken up only from  __v4l2_event_queue_fh()

wake_up_all(>wait);


So the event-dq-thread will only wake up when there is really a new 
event queued. It will not wake up when the event is unsubscribed in 
v4l2_event_unsubscribe() and it will also not wake up when 
video_unregister_device() and and consequently v4l2_fh_exit() is called.


In userland, when the device is disconnected while streaming video, 
VIDIOC_DQBUF and all other ioctls return with proper error codes, but 
VIDIOC_DQEVENT blocks until doomsday.
The only (dirty) workaround I found is sending a signal to the userland 
thread to force the wait_event_interruptible() to return.


I think this issue could be solved. I discovered that in videobuf2 a 
similar issue is solved by checking the flag q->streaming in
wait_event_interruptible() in __vb2_wait_for_done_vb(). In 
__vb2_queue_cancel() this flag is deasserted and all threads are woken 
up with wake_up_all.
I suggest that the problem could be solved by waking the 
event-dq-threads in v4l2_event_unsubscribe_all() or 
v4l2_event_unsubscribe() so that v4l2_event_dequeue() can return.


Problem is that I have almost no experience in kernel development. Can 
somebody with more knowledge in these matters please have a look at this 
issue and confirm or correct my observations?


Best regards,
Michael

Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

[Michael Ira Krufky]

On Tue, Jan 9, 2018 at 12:17 AM, Matthias Schwarzott <z...@gentoo.org> wrote:
> Am 05.01.2018 um 01:19 schrieb Michael Ira Krufky:
>> On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
>>> If release is part of frontend ops then it is called in the
>>> course of dvb_frontend_detach. The process also decrements
>>> the module usage count. The problem is if the lgdt3306a
>>> driver is reached via i2c_new_device, then when it is
>>> eventually destroyed remove is called, which further
>>> decrements the module usage count to negative. After this
>>> occurs the driver is in a bad state and no longer works.
>>> Also fixed by NULLing out the release callback is a double
>>> kfree of state, which introduces arbitrary oopses/GPF.
>>> This problem is only currently reachable via the em28xx driver.
>>>
>>> On disconnect of Hauppauge SoloHD before:
>>>
>>> lsmod | grep lgdt3306a
>>> lgdt3306a  28672  -1
>>> i2c_mux16384  1 lgdt3306a
>>>
>>> On disconnect of Hauppauge SoloHD after:
>>>
>>> lsmod | grep lgdt3306a
>>> lgdt3306a  28672  0
>>> i2c_mux16384  1 lgdt3306a
>>>
>>> Signed-off-by: Brad Love <b...@nextdimension.cc>
>>> ---
>>>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>>>  1 file changed, 1 insertion(+)
>>>
>>
>> Brad,
>>
>> We won't be able to apply this one.  The symptom that you're trying to
>> fix is indicative of some other problem, probably in the em28xx
>> driver.  NULL'ing the release callback is not the right thing to do.
>>
>
> Hi Mike,
> Why do you nak this perfectly fine patch?
> Let me start to explain.
>
> dvb_attach style drivers have an attach function and for unloading a
> .release callback.
>
> i2c-style drivers have a probe and a remove function.
>
> Mixed style drivers must be constructed, that either release or remove
> is called, never both.
> They both do the same thing, but with different signature.
>
>
> Now checking lgdt3306a driver:
>
> dvb attach style:
> In lgdt3306a_attach the release callback is set to lgdt3306a_release and
> no remove exists. Fine.
>
> i2c style probe:
> struct i2c_driver contains lgdt3306a_probe and lgdt3306a_remove.
> lgdt3306a_probe shares code and calls lgdt3306a_attach, but afterwards
> the release callback field must be set to NULL.
>
> This is/was done exactly like this in multiple other drivers as long as
> they have been multiple style attachable.
>
> Regards
> Matthias
>
>>
>>> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>>> b/drivers/media/dvb-frontends/lgdt3306a.c
>>> index 6356815..d2477ed 100644
>>> --- a/drivers/media/dvb-frontends/lgdt3306a.c
>>> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>>> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>>>
>>> i2c_set_clientdata(client, fe->demodulator_priv);
>>> state = fe->demodulator_priv;
>>> +   state->frontend.ops.release = NULL;
>>>
>>> /* create mux i2c adapter for tuner */
>>> state->muxc = i2c_mux_alloc(client->adapter, >dev,
>>> --
>>> 2.7.4
>>>
>>
>

Brad & Matthias,

It makes sense.  This is just a result of a transitional period where
there are multiple APIs for attaching the driver.  Hopefully we can
consolidate soon.

I will look at the other drivers when I have time later on, but you're
probably right, and we will likely end up merging this one after all.

I'll try to get a PR out to Mauro by the weekend.

-Mike

Re: [PATCH v2 8/9] lgdt3306a: QAM streaming improvement

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 8:30 PM, Brad Love <b...@nextdimension.cc> wrote:
> Add some register updates required for stable viewing
> on Cablevision in NY. Does not adversely affect other providers.
>
> Changes since v1:
> - Change upper case hex to lower case.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

Looks good - Thanks.

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index d2477ed..2f540f1 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
> *state, int modulation)
> if (lg_chkerr(ret))
> goto fail;
>
> +   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
> +   ret = lgdt3306a_read_reg(state, 0x000a, );
> +   val &= 0xfd;
> +   val |= 0x02;
> +   ret = lgdt3306a_write_reg(state, 0x000a, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.2 V0.36 Control of "no signal" detector function */
> +   ret = lgdt3306a_read_reg(state, 0x2849, );
> +   val &= 0xdf;
> +   ret = lgdt3306a_write_reg(state, 0x2849, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
> +   ret = lgdt3306a_read_reg(state, 0x302b, );
> +   val &= 0x7f;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
> +   ret = lgdt3306a_write_reg(state, 0x302b, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> /* 6. Reset */
> ret = lgdt3306a_soft_reset(state);
> if (lg_chkerr(ret))
> --
> 2.7.4
>

Re: [PATCH 9/9] lgdt3306a: Add QAM AUTO support

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> As configured currently, modulation in the driver is set to auto detect,
> no matter what the user sets modulation to. This leads to both QAM64
> and QAM256 having the same effect. QAM AUTO is explicitly added here for
> compatibility with scanning software who can use AUTO instead of doing
> essentially the same scan twice.
> Also included is a module option to enforce a specific QAM modulation if
> desired. The true modulation is read before calculating the snr.
> Changes are backwards compatible with current behaviour.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 42 
> ++---
>  1 file changed, 33 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 2f540f1..111efb0 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -30,6 +30,17 @@ static int debug;
>  module_param(debug, int, 0644);
>  MODULE_PARM_DESC(debug, "set debug level (info=1, reg=2 (or-able))");
>
> +/*
> + * Older drivers treated QAM64 and QAM256 the same; that is the HW always
> + * used "Auto" mode during detection.  Setting "forced_manual"=1 allows
> + * the user to treat these modes as separate.  For backwards compatibility,
> + * it's off by default.  QAM_AUTO can now be specified to achive that
> + * effect even if "forced_manual"=1
> + */
> +static int forced_manual;
> +module_param(forced_manual, int, 0644);
> +MODULE_PARM_DESC(forced_manual, "if set, QAM64 and QAM256 will only lock to 
> modulation specified");
> +
>  #define DBG_INFO 1
>  #define DBG_REG  2
>  #define DBG_DUMP 4 /* FGR - comment out to remove dump code */
> @@ -566,7 +577,12 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
> *state, int modulation)
> /* 3. : 64QAM/256QAM detection(manual, auto) */
> ret = lgdt3306a_read_reg(state, 0x0009, );
> val &= 0xfc;
> -   val |= 0x02; /* STDOPDETCMODE[1:0]=1=Manual 2=Auto */
> +   /* Check for forced Manual modulation modes; otherwise always "auto" 
> */
> +   if(forced_manual && (modulation != QAM_AUTO)){
> +   val |= 0x01; /* STDOPDETCMODE[1:0]= 1=Manual */
> +   } else {
> +   val |= 0x02; /* STDOPDETCMODE[1:0]= 2=Auto */
> +   }
> ret = lgdt3306a_write_reg(state, 0x0009, val);
> if (lg_chkerr(ret))
> goto fail;
> @@ -642,10 +658,9 @@ static int lgdt3306a_set_modulation(struct 
> lgdt3306a_state *state,
> ret = lgdt3306a_set_vsb(state);
> break;
> case QAM_64:
> -   ret = lgdt3306a_set_qam(state, QAM_64);
> -   break;
> case QAM_256:
> -   ret = lgdt3306a_set_qam(state, QAM_256);
> +   case QAM_AUTO:
> +   ret = lgdt3306a_set_qam(state, p->modulation);
> break;
> default:
> return -EINVAL;
> @@ -672,6 +687,7 @@ static int lgdt3306a_agc_setup(struct lgdt3306a_state 
> *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> break;
> default:
> return -EINVAL;
> @@ -726,6 +742,7 @@ static int lgdt3306a_spectral_inversion(struct 
> lgdt3306a_state *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> /* Auto ok for QAM */
> ret = lgdt3306a_set_inversion_auto(state, 1);
> break;
> @@ -749,6 +766,7 @@ static int lgdt3306a_set_if(struct lgdt3306a_state *state,
> break;
> case QAM_64:
> case QAM_256:
> +   case QAM_AUTO:
> if_freq_khz = state->cfg->qam_if_khz;
> break;
> default:
> @@ -1607,6 +1625,7 @@ static int lgdt3306a_read_status(struct dvb_frontend 
> *fe,
> switch (state->current_modulation) {
> case QAM_256:
> case QAM_64:
> +   case QAM_AUTO:
> if (lgdt3306a_qam_lock_poll(state) == LG3306_LOCK) {
> *status |= FE_HAS_VITERBI;
> *status |= FE_HAS_SYNC;
> @@ -1650,6 +1669,7 @@ static int lgdt3306a_read_signal_strength(struct 
> dvb_frontend *fe,
>  * Calculate some sort of "strength&

Re: [PATCH 8/9] lgdt3306a: QAM streaming improvement

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Add some register updates required for stable viewing
> on Cablevision in NY. Does not adversely affect other providers.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index d2477ed..2f540f1 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -598,6 +598,28 @@ static int lgdt3306a_set_qam(struct lgdt3306a_state 
> *state, int modulation)
> if (lg_chkerr(ret))
> goto fail;
>
> +   /* 5.1 V0.36 SRDCHKALWAYS : For better QAM detection */
> +   ret = lgdt3306a_read_reg(state, 0x000A, );
> +   val &= 0xFD;
> +   val |= 0x02;
> +   ret = lgdt3306a_write_reg(state, 0x000A, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.2 V0.36 Control of "no signal" detector function */
> +   ret = lgdt3306a_read_reg(state, 0x2849, );
> +   val &= 0xDF;
> +   ret = lgdt3306a_write_reg(state, 0x2849, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> +   /* 5.3 Fix for Blonder Tongue HDE-2H-QAM and AQM modulators */
> +   ret = lgdt3306a_read_reg(state, 0x302B, );
> +   val &= 0x7F;  /* SELFSYNCFINDEN_CQS=0; disable auto reset */
> +   ret = lgdt3306a_write_reg(state, 0x302B, val);
> +   if (lg_chkerr(ret))
> +   goto fail;
> +
> /* 6. Reset */
>     ret = lgdt3306a_soft_reset(state);
> if (lg_chkerr(ret))

Brad,

The change looks good, but can you resubmit this using lowercase hex?

Cheers,

Michael Ira Krufky

Re: [PATCH 6/9] em28xx: Enable Hauppauge SoloHD rebranded 292e SE

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Add a missing device to the driver table.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 34c693a..66d4c3a 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2619,6 +2619,8 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM28178_BOARD_PCTV_461E },
> { USB_DEVICE(0x2013, 0x025f),
> .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2013, 0x0264), /* Hauppauge WinTV-soloHD 292e SE */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
> .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
> Bulk */
> --
> 2.7.4
>

Re: [PATCH 5/9] em28xx: Add Hauppauge SoloHD/DualHD bulk models

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Add additional pids to driver list
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 22 +-
>  1 file changed, 17 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 7f5d0b28..34c693a 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -507,8 +507,10 @@ static struct em28xx_reg_seq plex_px_bcud[] = {
>  };
>
>  /*
> - * 2040:0265 Hauppauge WinTV-dualHD DVB
> - * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM
> + * 2040:0265 Hauppauge WinTV-dualHD DVB Isoc
> + * 2040:8265 Hauppauge WinTV-dualHD DVB Bulk
> + * 2040:026d Hauppauge WinTV-dualHD ATSC/QAM Isoc
> + * 2040:826d Hauppauge WinTV-dualHD ATSC/QAM Bulk
>   * reg 0x80/0x84:
>   * GPIO_0: Yellow LED tuner 1, 0=on, 1=off
>   * GPIO_1: Green LED tuner 1, 0=on, 1=off
> @@ -2391,7 +2393,8 @@ struct em28xx_board em28xx_boards[] = {
> .has_dvb   = 1,
> },
> /*
> -* 2040:0265 Hauppauge WinTV-dualHD (DVB version).
> +* 2040:0265 Hauppauge WinTV-dualHD (DVB version) Isoc.
> +* 2040:8265 Hauppauge WinTV-dualHD (DVB version) Bulk.
>  * Empia EM28274, 2x Silicon Labs Si2168, 2x Silicon Labs Si2157
>  */
> [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB] = {
> @@ -2407,7 +2410,8 @@ struct em28xx_board em28xx_boards[] = {
> .leds  = hauppauge_dualhd_leds,
> },
> /*
> -* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM).
> +* 2040:026d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Isoc.
> +* 2040:826d Hauppauge WinTV-dualHD (model 01595 - ATSC/QAM) Bulk.
>  * Empia EM28274, 2x LG LGDT3306A, 2x Silicon Labs Si2157
>  */
> [EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595] = {
> @@ -2549,8 +2553,12 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850 },
> { USB_DEVICE(0x2040, 0x0265),
> .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB },
> +   { USB_DEVICE(0x2040, 0x8265),
> +   .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_DVB },
> { USB_DEVICE(0x2040, 0x026d),
> .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
> +   { USB_DEVICE(0x2040, 0x826d),
> +   .driver_info = 
> EM28174_BOARD_HAUPPAUGE_WINTV_DUALHD_01595 },
> { USB_DEVICE(0x0438, 0xb002),
> .driver_info = EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600 
> },
> { USB_DEVICE(0x2001, 0xf112),
> @@ -2611,7 +2619,11 @@ struct usb_device_id em28xx_id_table[] = {
> .driver_info = EM28178_BOARD_PCTV_461E },
> { USB_DEVICE(0x2013, 0x025f),
> .driver_info = EM28178_BOARD_PCTV_292E },
> -   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD */
> +   { USB_DEVICE(0x2040, 0x0264), /* Hauppauge WinTV-soloHD Isoc */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2040, 0x8264), /* Hauppauge OEM Generic WinTV-soloHD 
> Bulk */
> +   .driver_info = EM28178_BOARD_PCTV_292E },
> +   { USB_DEVICE(0x2040, 0x8268), /* Hauppauge Retail WinTV-soloHD Bulk */
> .driver_info = EM28178_BOARD_PCTV_292E },
> { USB_DEVICE(0x0413, 0x6f07),
> .driver_info = EM2861_BOARD_LEADTEK_VC100 },
> --
> 2.7.4
>

Re: [PATCH 4/9] em28xx: Increase max em28xx boards to max dvb adapters

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Maximum 4 em28xx boards is too low, this can be maxed out by two devices.
> This allows all the dvb adapters in the system to be em28xx if so desired.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index 7be8ac9..3dbcc9d 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -166,7 +166,7 @@
>  #define EM28XX_STOP_AUDIO   0
>
>  /* maximum number of em28xx boards */
> -#define EM28XX_MAXBOARDS 4 /*FIXME: should be bigger */
> +#define EM28XX_MAXBOARDS DVB_MAX_ADAPTERS /* All adapters could be em28xx */
>
>  /* maximum number of frames that can be queued */
>  #define EM28XX_NUM_FRAMES 5
> --
> 2.7.4
>

Re: [PATCH 3/9] em28xx: USB bulk packet size fix

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Hauppauge em28xx bulk devices exhibit continuity errors and corrupted
> packets, when run in VMWare virtual machines. Unknown if other
> manufacturers bulk models exhibit the same issue. KVM/Qemu is unaffected.
>
> According to documentation the maximum packet multiplier for em28xx in bulk
> transfer mode is 256 * 188 bytes. This changes the size of bulk transfers
> to maximum supported value and have a bonus beneficial alignment.
>
> Before:
> # 512 * 384 = 196608
> ## 196608 % 188 != 0
>
> After:
> # 512 * 47 * 2 = 48128(188 * 128 * 2)
> ## 48128 % 188 = 0
>
> This sets up USB to expect just as many bytes as the em28xx is set to emit.
>
> Successful usage under load afterwards natively and in both VMWare
> and KVM/Qemu virtual machines.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx.h 
> b/drivers/media/usb/em28xx/em28xx.h
> index c85292c..7be8ac9 100644
> --- a/drivers/media/usb/em28xx/em28xx.h
> +++ b/drivers/media/usb/em28xx/em28xx.h
> @@ -191,7 +191,7 @@
> USB 2.0 spec says bulk packet size is always 512 bytes
>   */
>  #define EM28XX_BULK_PACKET_MULTIPLIER 384
> -#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 384
> +#define EM28XX_DVB_BULK_PACKET_MULTIPLIER 94
>
>  #define EM28XX_INTERLACED_DEFAULT 1
>
> --
> 2.7.4
>

Re: [PATCH 2/9] em28xx: Bulk transfer implementation fix

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Set appropriate bulk/ISOC transfer multiplier on capture start.
> This sets ISOC transfer to 940 bytes (188 * 5)
> This sets bulk transfer to 48128 bytes (188 * 256)
>
> The above values are maximum allowed according to Empia.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx-core.c | 12 
>  1 file changed, 12 insertions(+)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
> b/drivers/media/usb/em28xx/em28xx-core.c
> index ef38e56..67ed6a3 100644
> --- a/drivers/media/usb/em28xx/em28xx-core.c
> +++ b/drivers/media/usb/em28xx/em28xx-core.c
> @@ -638,6 +638,18 @@ int em28xx_capture_start(struct em28xx *dev, int start)
> dev->chip_id == CHIP_ID_EM28174 ||
> dev->chip_id == CHIP_ID_EM28178) {
> /* The Transport Stream Enable Register moved in em2874 */
> +   if (dev->dvb_xfer_bulk) {
> +   /* Max Tx Size = 188 * 256 = 48128 - LCM(188,512) * 2 
> */
> +   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
> +   EM2874_R5D_TS1_PKT_SIZE :
> +   EM2874_R5E_TS2_PKT_SIZE,
> +   0xFF);
> +   } else {
> +   /* TS2 Maximum Transfer Size = 188 * 5 */
> +   em28xx_write_reg(dev, (dev->ts == PRIMARY_TS) ?
> +   EM2874_R5D_TS1_PKT_SIZE :
> +   EM2874_R5E_TS2_PKT_SIZE, 0x05);
> +   }
> if (dev->ts == PRIMARY_TS)
> rc = em28xx_write_reg_bits(dev,
> EM2874_R5F_TS_ENABLE,
> --
> 2.7.4
>

Re: [PATCH 1/9] em28xx: Hauppauge DualHD second tuner functionality

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
> Implement use of secondary TS port on em28xx.
> Adds has_dual_ts field, allows secondary demod/tuner to be
> added to a single em28xx device.
>
> Hauppauge DualHD models are configured to use this feature.
>
> Signed-off-by: Brad Love <b...@nextdimension.cc>

:+1

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/em28xx/em28xx-cards.c | 126 
> +++-
>  drivers/media/usb/em28xx/em28xx-core.c  |  42 +--
>  drivers/media/usb/em28xx/em28xx-dvb.c   |  33 +++--
>  drivers/media/usb/em28xx/em28xx.h   |  12 +++
>  4 files changed, 196 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> b/drivers/media/usb/em28xx/em28xx-cards.c
> index 34e16f6a..7f5d0b28 100644
> --- a/drivers/media/usb/em28xx/em28xx-cards.c
> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> @@ -2402,6 +2402,7 @@ struct em28xx_board em28xx_boards[] = {
> .tuner_type= TUNER_ABSENT,
> .tuner_gpio= hauppauge_dualhd_dvb,
> .has_dvb   = 1,
> +   .has_dual_ts   = 1,
> .ir_codes  = RC_MAP_HAUPPAUGE,
> .leds  = hauppauge_dualhd_leds,
> },
> @@ -2417,6 +2418,7 @@ struct em28xx_board em28xx_boards[] = {
> .tuner_type= TUNER_ABSENT,
> .tuner_gpio= hauppauge_dualhd_dvb,
> .has_dvb   = 1,
> +   .has_dual_ts   = 1,
> .ir_codes  = RC_MAP_HAUPPAUGE,
> .leds  = hauppauge_dualhd_leds,
> },
> @@ -3239,7 +3241,8 @@ static void em28xx_release_resources(struct em28xx *dev)
> em28xx_i2c_unregister(dev, 1);
> em28xx_i2c_unregister(dev, 0);
>
> -   usb_put_dev(udev);
> +   if (dev->ts == PRIMARY_TS)
> +   usb_put_dev(udev);
>
> /* Mark device as unused */
> clear_bit(dev->devno, em28xx_devused);
> @@ -3432,6 +3435,35 @@ static int em28xx_init_dev(struct em28xx *dev, struct 
> usb_device *udev,
> return 0;
>  }
>
> +int em28xx_duplicate_dev(struct em28xx *dev)
> +{
> +   int nr;
> +   struct em28xx *sec_dev = kzalloc(sizeof(*sec_dev), GFP_KERNEL);
> +
> +   if (sec_dev == NULL) {
> +   dev->dev_next = NULL;
> +   return -ENOMEM;
> +   }
> +   memcpy(sec_dev, dev, sizeof(sizeof(*sec_dev)));
> +   /* Check to see next free device and mark as used */
> +   do {
> +   nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
> +   if (nr >= EM28XX_MAXBOARDS) {
> +   /* No free device slots */
> +   dev_warn(>intf->dev, ": Supports only %i em28xx 
> boards.\n",
> +   EM28XX_MAXBOARDS);
> +   kfree(sec_dev);
> +   dev->dev_next = NULL;
> +   return -ENOMEM;
> +   }
> +   } while (test_and_set_bit(nr, em28xx_devused));
> +   sec_dev->devno = nr;
> +   snprintf(sec_dev->name, 28, "em28xx #%d", nr);
> +   sec_dev->dev_next = NULL;
> +   dev->dev_next = sec_dev;
> +   return 0;
> +}
> +
>  /* high bandwidth multiplier, as encoded in highspeed endpoint descriptors */
>  #define hb_mult(wMaxPacketSize) (1 + (((wMaxPacketSize) >> 11) & 0x03))
>
> @@ -3551,6 +3583,17 @@ static int em28xx_usb_probe(struct usb_interface 
> *interface,
> }
> }
> break;
> +   case 0x85:
> +   if (usb_endpoint_xfer_isoc(e)) {
> +   if (size > 
> dev->dvb_max_pkt_size_isoc_ts2) {
> +   dev->dvb_ep_isoc_ts2 
> = e->bEndpointAddress;
> +   
> dev->dvb_max_pkt_size_isoc_ts2 = size;
> +   dev->dvb_alt_isoc = i;
> +   }
> +   } else {
> +   dev->dvb_ep_bulk_ts2 = 
> e->bEndpointAddress;
> +   }
> +   break;
> }
>

Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

[Michael Ira Krufky]

On Thu, Jan 4, 2018 at 7:04 PM, Brad Love  wrote:
> If release is part of frontend ops then it is called in the
> course of dvb_frontend_detach. The process also decrements
> the module usage count. The problem is if the lgdt3306a
> driver is reached via i2c_new_device, then when it is
> eventually destroyed remove is called, which further
> decrements the module usage count to negative. After this
> occurs the driver is in a bad state and no longer works.
> Also fixed by NULLing out the release callback is a double
> kfree of state, which introduces arbitrary oopses/GPF.
> This problem is only currently reachable via the em28xx driver.
>
> On disconnect of Hauppauge SoloHD before:
>
> lsmod | grep lgdt3306a
> lgdt3306a  28672  -1
> i2c_mux16384  1 lgdt3306a
>
> On disconnect of Hauppauge SoloHD after:
>
> lsmod | grep lgdt3306a
> lgdt3306a  28672  0
> i2c_mux16384  1 lgdt3306a
>
> Signed-off-by: Brad Love 
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>  1 file changed, 1 insertion(+)
>

Brad,

We won't be able to apply this one.  The symptom that you're trying to
fix is indicative of some other problem, probably in the em28xx
driver.  NULL'ing the release callback is not the right thing to do.

-Mike Krufky

> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 6356815..d2477ed 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>
> i2c_set_clientdata(client, fe->demodulator_priv);
> state = fe->demodulator_priv;
> +   state->frontend.ops.release = NULL;
>
> /* create mux i2c adapter for tuner */
> state->muxc = i2c_mux_alloc(client->adapter, >dev,
> --
> 2.7.4
>

Re: [PATCH] tuners: tda8290: reduce stack usage with kasan

[Michael Ira Krufky]

On Mon, Dec 11, 2017 at 2:34 PM, Joe Perches <j...@perches.com> wrote:
> On Mon, 2017-12-11 at 13:06 +0100, Arnd Bergmann wrote:
>> With CONFIG_KASAN enabled, we get a relatively large stack frame in one 
>> function
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes 
>> is larger than 1024 bytes [-Wframe-larger-than=]
>>
>> With CONFIG_KASAN_EXTRA this goes up to
>>
>> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
>> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is 
>> larger than 3072 bytes [-Werror=frame-larger-than=]
>>
>> We can significantly reduce this by marking local arrays as 'static const', 
>> and
>> this should result in better compiled code for everyone.
> []
>> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
> []
>> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int 
>> close)
>>  {
>>   struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char  enable[2] = { 0x21, 0xC0 };
>> - unsigned char disable[2] = { 0x21, 0x00 };
>> + static unsigned char  enable[2] = { 0x21, 0xC0 };
>> + static unsigned char disable[2] = { 0x21, 0x00 };
>
> Doesn't match commit message.
>
> static const or just static?
>
>> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int 
>> close)
>>  {
>>   struct tda8290_priv *priv = fe->analog_demod_priv;
>>
>> - unsigned char  enable[2] = { 0x45, 0xc1 };
>> - unsigned char disable[2] = { 0x46, 0x00 };
>> - unsigned char buf[3] = { 0x45, 0x01, 0x00 };
>> + static unsigned char  enable[2] = { 0x45, 0xc1 };
>> + static unsigned char disable[2] = { 0x46, 0x00 };
>
> etc.
>
>


Joe is correct - they can be CONSTified. My bad -- a lot of the code I
wrote many years ago has this problem -- I wasn't so stack-conscious
back then.

The bytes in `enable` / `disable` don't get changed, but they may be
copied to another byte array that does get changed.  If would be best
to make these `static const`

Best regards,

Michael Ira Krufky

Re: [PATCH] tuners: tda8290: reduce stack usage with kasan

[Michael Ira Krufky]

On Mon, Dec 11, 2017 at 7:06 AM, Arnd Bergmann <a...@arndb.de> wrote:
> With CONFIG_KASAN enabled, we get a relatively large stack frame in one 
> function
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: warning: the frame size of 1520 bytes 
> is larger than 1024 bytes [-Wframe-larger-than=]
>
> With CONFIG_KASAN_EXTRA this goes up to
>
> drivers/media/tuners/tda8290.c: In function 'tda8290_set_params':
> drivers/media/tuners/tda8290.c:310:1: error: the frame size of 3200 bytes is 
> larger than 3072 bytes [-Werror=frame-larger-than=]
>
> We can significantly reduce this by marking local arrays as 'static const', 
> and
> this should result in better compiled code for everyone.
>
> I have another patch for the same symptom to patch tuner_i2c_xfer_*, and we
> actually want both of them.
>
> Signed-off-by: Arnd Bergmann <a...@arndb.de>

Thank you, Arnd.

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>


> ---
>  drivers/media/tuners/tda8290.c | 76 
> ++
>  1 file changed, 39 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/media/tuners/tda8290.c b/drivers/media/tuners/tda8290.c
> index a59c567c55d6..19854221b72d 100644
> --- a/drivers/media/tuners/tda8290.c
> +++ b/drivers/media/tuners/tda8290.c
> @@ -63,8 +63,8 @@ static int tda8290_i2c_bridge(struct dvb_frontend *fe, int 
> close)
>  {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> -   unsigned char  enable[2] = { 0x21, 0xC0 };
> -   unsigned char disable[2] = { 0x21, 0x00 };
> +   static unsigned char  enable[2] = { 0x21, 0xC0 };
> +   static unsigned char disable[2] = { 0x21, 0x00 };
> unsigned char *msg;
>
> if (close) {
> @@ -84,9 +84,9 @@ static int tda8295_i2c_bridge(struct dvb_frontend *fe, int 
> close)
>  {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> -   unsigned char  enable[2] = { 0x45, 0xc1 };
> -   unsigned char disable[2] = { 0x46, 0x00 };
> -   unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> +   static unsigned char  enable[2] = { 0x45, 0xc1 };
> +   static unsigned char disable[2] = { 0x46, 0x00 };
> +   static unsigned char buf[3] = { 0x45, 0x01, 0x00 };
> unsigned char *msg;
>
> if (close) {
> @@ -178,24 +178,24 @@ static void tda8290_set_params(struct dvb_frontend *fe,
>  {
> struct tda8290_priv *priv = fe->analog_demod_priv;
>
> -   unsigned char soft_reset[]  = { 0x00, 0x00 };
> +   static unsigned char soft_reset[]  = { 0x00, 0x00 };
> unsigned char easy_mode[]   = { 0x01, priv->tda8290_easy_mode };
> -   unsigned char expert_mode[] = { 0x01, 0x80 };
> -   unsigned char agc_out_on[]  = { 0x02, 0x00 };
> -   unsigned char gainset_off[] = { 0x28, 0x14 };
> -   unsigned char if_agc_spd[]  = { 0x0f, 0x88 };
> -   unsigned char adc_head_6[]  = { 0x05, 0x04 };
> -   unsigned char adc_head_9[]  = { 0x05, 0x02 };
> -   unsigned char adc_head_12[] = { 0x05, 0x01 };
> -   unsigned char pll_bw_nom[]  = { 0x0d, 0x47 };
> -   unsigned char pll_bw_low[]  = { 0x0d, 0x27 };
> -   unsigned char gainset_2[]   = { 0x28, 0x64 };
> -   unsigned char agc_rst_on[]  = { 0x0e, 0x0b };
> -   unsigned char agc_rst_off[] = { 0x0e, 0x09 };
> -   unsigned char if_agc_set[]  = { 0x0f, 0x81 };
> -   unsigned char addr_adc_sat  = 0x1a;
> -   unsigned char addr_agc_stat = 0x1d;
> -   unsigned char addr_pll_stat = 0x1b;
> +   static unsigned char expert_mode[] = { 0x01, 0x80 };
> +   static unsigned char agc_out_on[]  = { 0x02, 0x00 };
> +   static unsigned char gainset_off[] = { 0x28, 0x14 };
> +   static unsigned char if_agc_spd[]  = { 0x0f, 0x88 };
> +   static unsigned char adc_head_6[]  = { 0x05, 0x04 };
> +   static unsigned char adc_head_9[]  = { 0x05, 0x02 };
> +   static unsigned char adc_head_12[] = { 0x05, 0x01 };
> +   static unsigned char pll_bw_nom[]  = { 0x0d, 0x47 };
> +   static unsigned char pll_bw_low[]  = { 0x0d, 0x27 };
> +   static unsigned char gainset_2[]   = { 0x28, 0x64 };
> +   static unsigned char agc_rst_on[]  = { 0x0e, 0x0b };
> +   static unsigned char agc_rst_off[] = { 0x0e, 0x09 };
> +   static unsigned char if_agc_set[]  = { 0x0f, 0x81 };
> +   static unsigned char addr_adc_sat  = 0x1a;
> +   static unsigned char addr_agc_stat = 0x1d;
> +   static unsigned char addr_pll_stat = 0x1b;
> unsigned char adc_sat, agc_stat,
>   pll_stat;
> int i;
> @@ -468,9 +468,9 @@ static void tda8290_standby(struct dvb_frontend

Re: [PATCH] [media] mxl111sf: remove redundant assignment to index

[Michael Ira Krufky]

On Sun, Oct 29, 2017 at 8:50 AM, Colin King <colin.k...@canonical.com> wrote:
> From: Colin Ian King <colin.k...@canonical.com>
>
> Variable index is set to zero and then set to zero again
> a few lines later in a for loop initialization. Remove the
> redundant setting of index to zero. Cleans up the clang
> warning:
>
> drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c:519:3: warning: Value
> stored to 'index' is never read
>
> Signed-off-by: Colin Ian King <colin.k...@canonical.com>

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>


Thanks for the patch!


> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
> index 0eb33e043079..a221bb8a12b4 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-i2c.c
> @@ -516,7 +516,6 @@ static int mxl111sf_i2c_hw_xfer_msg(struct mxl111sf_state 
> *state,
>data required to program */
> block_len = (msg->len / 8);
> left_over_len = (msg->len % 8);
> -   index = 0;
>
> mxl_i2c("block_len %d, left_over_len %d",
> block_len, left_over_len);
> --
> 2.14.1
>

Re: [PATCHv3 2/2] dib0700: add support for Xbox One Digital TV Tuner

[Michael Ira Krufky]

On Wed, Aug 2, 2017 at 9:00 AM,  <olli.salo...@iki.fi> wrote:
> From: Olli Salonen <olli.salo...@iki.fi>
>
> Xbox One Digital TV Tuner is a low-cost USB 2.0 multistandard TV tuner. It
> supports DVB-T, DVB-T2 and DVB-C broadcast standards.
>
> USB bridge: DibCom 0700C
> Demodulator: Panasonic MN88472
> Tuner: TDA18250BHN
>
> The demodulator requires firmware. Download one from here:
> http://palosaari.fi/linux/v4l-dvb/firmware/MN88472/02/latest/
>
> Signed-off-by: Olli Salonen <olli.salo...@iki.fi>

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/dvb-core/dvb-usb-ids.h|   2 +
>  drivers/media/usb/dvb-usb/Kconfig   |   2 +
>  drivers/media/usb/dvb-usb/dib0700.h |   2 +
>  drivers/media/usb/dvb-usb/dib0700_core.c|  26 ++-
>  drivers/media/usb/dvb-usb/dib0700_devices.c | 109 
> +++-
>  5 files changed, 139 insertions(+), 2 deletions(-)
>



Thanks for this contribution!  It's good to finally have an example of
card support within the dib0700 driver that can serve an an example of
using the newer method of frontend attachment.

It would be nice to move some of the attachment code out of the
card-specific `_attach()` function into a common function, but since
this is the only attachment that works this way, leaving things as-is
is fine enough for now.   After we convert some of the other
`_attach()` functions, or adding some new ones using this method, we
may want to refactor this a bit.

Meanwhile, this is good for merge.  Nice work.



> diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
> b/drivers/media/dvb-core/dvb-usb-ids.h
> index 5b6041d..daf49ec 100644
> --- a/drivers/media/dvb-core/dvb-usb-ids.h
> +++ b/drivers/media/dvb-core/dvb-usb-ids.h
> @@ -80,6 +80,7 @@
>  #define USB_VID_AZUREWAVE  0x13d3
>  #define USB_VID_TECHNISAT  0x14f7
>  #define USB_VID_HAMA   0x147f
> +#define USB_VID_MICROSOFT  0x045e
>
>  /* Product IDs */
>  #define USB_PID_ADSTECH_USB2_COLD  0xa333
> @@ -417,4 +418,5 @@
>  #define USB_PID_WINTV_SOLOHD0x0264
>  #define USB_PID_EVOLVEO_XTRATV_STICK   0xa115
>  #define USB_PID_HAMA_DVBT_HYBRID   0x2758
> +#define USB_PID_XBOX_ONE_TUNER  0x02d5
>  #endif
> diff --git a/drivers/media/usb/dvb-usb/Kconfig 
> b/drivers/media/usb/dvb-usb/Kconfig
> index 959fa09..2651ae2 100644
> --- a/drivers/media/usb/dvb-usb/Kconfig
> +++ b/drivers/media/usb/dvb-usb/Kconfig
> @@ -86,6 +86,7 @@ config DVB_USB_DIB0700
> select DVB_USB_DIB3000MC if MEDIA_SUBDRV_AUTOSELECT
> select DVB_S5H1411 if MEDIA_SUBDRV_AUTOSELECT
> select DVB_LGDT3305 if MEDIA_SUBDRV_AUTOSELECT
> +   select DVB_MN88472 if MEDIA_SUBDRV_AUTOSELECT
> select DVB_TUNER_DIB0070 if MEDIA_SUBDRV_AUTOSELECT
> select DVB_TUNER_DIB0090 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MT2060 if MEDIA_SUBDRV_AUTOSELECT
> @@ -94,6 +95,7 @@ config DVB_USB_DIB0700
> select MEDIA_TUNER_XC5000 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_XC4000 if MEDIA_SUBDRV_AUTOSELECT
> select MEDIA_TUNER_MXL5007T if MEDIA_SUBDRV_AUTOSELECT
> +   select MEDIA_TUNER_TDA18250 if MEDIA_SUBDRV_AUTOSELECT
> help
>   Support for USB2.0/1.1 DVB receivers based on the DiB0700 USB 
> bridge. The
>   USB bridge is also present in devices having the DiB7700 DVB-T-USB
> diff --git a/drivers/media/usb/dvb-usb/dib0700.h 
> b/drivers/media/usb/dvb-usb/dib0700.h
> index 8fd8f5b..5f29128 100644
> --- a/drivers/media/usb/dvb-usb/dib0700.h
> +++ b/drivers/media/usb/dvb-usb/dib0700.h
> @@ -51,6 +51,8 @@ struct dib0700_state {
> int (*read_status)(struct dvb_frontend *, enum fe_status *);
> int (*sleep)(struct dvb_frontend* fe);
> u8 buf[255];
> +   struct i2c_client *i2c_client_demod;
> +   struct i2c_client *i2c_client_tuner;
>  };
>
>  extern int dib0700_get_version(struct dvb_usb_device *d, u32 *hwversion,
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c 
> b/drivers/media/usb/dvb-usb/dib0700_core.c
> index bea1b47..dbd031c 100644
> --- a/drivers/media/usb/dvb-usb/dib0700_core.c
> +++ b/drivers/media/usb/dvb-usb/dib0700_core.c
> @@ -911,10 +911,34 @@ static int dib0700_probe(struct usb_interface *intf,
> return -ENODEV;
>  }
>
> +static void dib0700_disconnect(struct usb_interface *intf)
> +{
> +   struct dvb_usb_device *d = usb_get_intfdata(intf);
> +   struct dib0700_state *st = d->priv;
> +   struct i2c_client *client;
> +
> +   /* r

Re: [PATCHv3 1/2] tda18250: support for new silicon tuner

[Michael Ira Krufky]

On Wed, Aug 2, 2017 at 9:00 AM,  <olli.salo...@iki.fi> wrote:
> From: Olli Salonen <olli.salo...@iki.fi>
>
> NXP TDA18250 silicon tuner driver.
>
> Version 3 removes regmap_exit as I was pointed out that device
> management code automatically frees the regmap.
>
> Signed-off-by: Olli Salonen <olli.salo...@iki.fi>

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/tuners/Kconfig |   7 +
>  drivers/media/tuners/Makefile|   1 +
>  drivers/media/tuners/tda18250.c  | 921 
> +++
>  drivers/media/tuners/tda18250.h  |  51 ++
>  drivers/media/tuners/tda18250_priv.h | 153 ++
>  5 files changed, 1133 insertions(+)
>  create mode 100644 drivers/media/tuners/tda18250.c
>  create mode 100644 drivers/media/tuners/tda18250.h
>  create mode 100644 drivers/media/tuners/tda18250_priv.h


Olli,

Pardon the multiple copies of this email -- I had some trouble with my
mailer (and forgot to keep the mailing list cc'd)

Thank you for your contribution.  Things look good, I just have a
question, see inline below:


>
> diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
> index 05998f0..6687514 100644
> --- a/drivers/media/tuners/Kconfig
> +++ b/drivers/media/tuners/Kconfig
> @@ -26,6 +26,13 @@ config MEDIA_TUNER_SIMPLE
> help
>   Say Y here to include support for various simple tuners.
>
> +config MEDIA_TUNER_TDA18250
> +   tristate "NXP TDA18250 silicon tuner"
> +   depends on MEDIA_SUPPORT && I2C
> +   default m if !MEDIA_SUBDRV_AUTOSELECT
> +   help
> + Say Y here to include support for TDA18250 tuner.
> +
>  config MEDIA_TUNER_TDA8290
> tristate "TDA 8290/8295 + 8275(a)/18271 tuner combo"
> depends on MEDIA_SUPPORT && I2C
> diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
> index 06a9ab6..4b9444b 100644
> --- a/drivers/media/tuners/Makefile
> +++ b/drivers/media/tuners/Makefile
> @@ -41,6 +41,7 @@ obj-$(CONFIG_MEDIA_TUNER_R820T) += r820t.o
>  obj-$(CONFIG_MEDIA_TUNER_MXL301RF) += mxl301rf.o
>  obj-$(CONFIG_MEDIA_TUNER_QM1D1C0042) += qm1d1c0042.o
>  obj-$(CONFIG_MEDIA_TUNER_M88RS6000T) += m88rs6000t.o
> +obj-$(CONFIG_MEDIA_TUNER_TDA18250) += tda18250.o
>
>  ccflags-y += -I$(srctree)/drivers/media/dvb-core
>  ccflags-y += -I$(srctree)/drivers/media/dvb-frontends
> diff --git a/drivers/media/tuners/tda18250.c b/drivers/media/tuners/tda18250.c
> new file mode 100644
> index 000..3a10bd1
> --- /dev/null
> +++ b/drivers/media/tuners/tda18250.c
> @@ -0,0 +1,921 @@
> +/*
> + * NXP TDA18250 silicon tuner driver
> + *
> + * Copyright (C) 2017 Olli Salonen <olli.salo...@iki.fi>
> + *
> + *This program is free software; you can redistribute it and/or modify
> + *it under the terms of the GNU General Public License as published by
> + *the Free Software Foundation; either version 2 of the License, or
> + *(at your option) any later version.
> + *
> + *This program is distributed in the hope that it will be useful,
> + *but WITHOUT ANY WARRANTY; without even the implied warranty of
> + *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + *GNU General Public License for more details.
> + *
> + */
> +
> +#include "tda18250_priv.h"
> +#include 
> +
> +static const struct dvb_tuner_ops tda18250_ops;
> +
> +static int tda18250_power_control(struct dvb_frontend *fe,
> +   unsigned int power_state)
> +{
> +   struct i2c_client *client = fe->tuner_priv;
> +   struct tda18250_dev *dev = i2c_get_clientdata(client);
> +   int ret;
> +   unsigned int utmp;
> +
> +   dev_dbg(>dev, "power state: %d", power_state);
> +
> +   switch (power_state) {
> +   case TDA18250_POWER_NORMAL:
> +   ret = regmap_write_bits(dev->regmap, R06_POWER2, 0x07, 0x00);
> +   if (ret)
> +   goto err;
> +   ret = regmap_write_bits(dev->regmap, R25_REF, 0xc0, 0xc0);
> +   if (ret)
> +   goto err;
> +   break;
> +   case TDA18250_POWER_STANDBY:
> +   if (dev->loopthrough) {
> +   ret = regmap_write_bits(dev->regmap, R25_REF, 0xc0, 
> 0x80);
> +   if (ret)
> +   goto err;
> +   ret = regmap_write_bits(dev->regmap, R06_POWER2, 
> 0x07, 0x02);
> +   if (ret)
> +   goto err;
> +   ret = regmap_write_bits(dev-

Re: [PATCH 03/18] media: use ARRAY_SIZE

[Michael Ira Krufky]

On Sun, Oct 1, 2017 at 3:30 PM, Jérémy Lefaure
<jeremy.lefa...@lse.epita.fr> wrote:
> Using the ARRAY_SIZE macro improves the readability of the code. Also,
> it is not always useful to use a variable to store this constant
> calculated at compile time.
>
> Found with Coccinelle with the following semantic patch:
> @r depends on (org || report)@
> type T;
> T[] E;
> position p;
> @@
> (
>  (sizeof(E)@p /sizeof(*E))
> |
>  (sizeof(E)@p /sizeof(E[...]))
> |
>  (sizeof(E)@p /sizeof(T))
> )
>
> Signed-off-by: Jérémy Lefaure <jeremy.lefa...@lse.epita.fr>


Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>


> ---
>  drivers/media/common/saa7146/saa7146_video.c | 9 -
>  drivers/media/dvb-frontends/cxd2841er.c  | 7 +++
>  drivers/media/pci/saa7146/hexium_gemini.c| 3 ++-
>  drivers/media/pci/saa7146/hexium_orion.c | 3 ++-
>  drivers/media/pci/saa7146/mxb.c  | 3 ++-
>  drivers/media/usb/dvb-usb/cxusb.c| 3 ++-
>  drivers/media/usb/dvb-usb/friio-fe.c | 5 ++---
>  7 files changed, 17 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/media/common/saa7146/saa7146_video.c 
> b/drivers/media/common/saa7146/saa7146_video.c
> index 37b4654dc21c..612aefd804f0 100644
> --- a/drivers/media/common/saa7146/saa7146_video.c
> +++ b/drivers/media/common/saa7146/saa7146_video.c
> @@ -4,6 +4,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  static int max_memory = 32;
>
> @@ -86,13 +87,11 @@ static struct saa7146_format formats[] = {
> due to this, it's impossible to provide additional *packed* formats, 
> which are simply byte swapped
> (like V4L2_PIX_FMT_YUYV) ... 8-( */
>
> -static int NUM_FORMATS = sizeof(formats)/sizeof(struct saa7146_format);
> -
>  struct saa7146_format* saa7146_format_by_fourcc(struct saa7146_dev *dev, int 
> fourcc)
>  {
> -   int i, j = NUM_FORMATS;
> +   int i;
>
> -   for (i = 0; i < j; i++) {
> +   for (i = 0; i < ARRAY_SIZE(formats); i++) {
> if (formats[i].pixelformat == fourcc) {
> return formats+i;
> }
> @@ -524,7 +523,7 @@ static int vidioc_s_fbuf(struct file *file, void *fh, 
> const struct v4l2_framebuf
>
>  static int vidioc_enum_fmt_vid_cap(struct file *file, void *fh, struct 
> v4l2_fmtdesc *f)
>  {
> -   if (f->index >= NUM_FORMATS)
> +   if (f->index >= ARRAY_SIZE(formats))
> return -EINVAL;
> strlcpy((char *)f->description, formats[f->index].name,
> sizeof(f->description));
> diff --git a/drivers/media/dvb-frontends/cxd2841er.c 
> b/drivers/media/dvb-frontends/cxd2841er.c
> index 48ee9bc00c06..2cb97a3130be 100644
> --- a/drivers/media/dvb-frontends/cxd2841er.c
> +++ b/drivers/media/dvb-frontends/cxd2841er.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>
>  #include "dvb_math.h"
>  #include "dvb_frontend.h"
> @@ -1696,12 +1697,10 @@ static u32 cxd2841er_dvbs_read_snr(struct 
> cxd2841er_priv *priv,
> min_index = 0;
> if (delsys == SYS_DVBS) {
> cn_data = s_cn_data;
> -   max_index = sizeof(s_cn_data) /
> -   sizeof(s_cn_data[0]) - 1;
> +   max_index = ARRAY_SIZE(s_cn_data) - 1;
> } else {
> cn_data = s2_cn_data;
> -   max_index = sizeof(s2_cn_data) /
> -   sizeof(s2_cn_data[0]) - 1;
> +   max_index = ARRAY_SIZE(s2_cn_data) - 1;
> }
> if (value >= cn_data[min_index].value) {
> res = cn_data[min_index].cnr_x1000;
> diff --git a/drivers/media/pci/saa7146/hexium_gemini.c 
> b/drivers/media/pci/saa7146/hexium_gemini.c
> index d31a2d4494d1..39357eddee32 100644
> --- a/drivers/media/pci/saa7146/hexium_gemini.c
> +++ b/drivers/media/pci/saa7146/hexium_gemini.c
> @@ -27,6 +27,7 @@
>
>  #include 
>  #include 
> +#include 
>
>  static int debug;
>  module_param(debug, int, 0);
> @@ -388,7 +389,7 @@ static struct saa7146_ext_vv vv_data = {
> .inputs = HEXIUM_INPUTS,
> .capabilities = 0,
> .stds = _standards[0],
> -   .num_stds = sizeof(hexium_standards) / sizeof(struct 
> saa7146_standard),
> +   .num_stds = ARRAY_SIZE(hexium_standards),
> .std_callback = _callback,
>  };
>
> diff --git a/drivers/media/pci/saa7146/hexium_orion.c 
> b/drivers/media/pci/saa7146/hexium_orion.c
> index 043318aa19e2..461e421080

Re: [PATCH 03/25] media: dvbdev: convert DVB device types into an enum

[Michael Ira Krufky]

On Wed, Sep 20, 2017 at 3:11 PM, Mauro Carvalho Chehab
 wrote:
> Enums can be documented via kernel-doc. So, convert the
> DVB_DEVICE_* macros to an enum.
>
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/dvb-core/dvbdev.c | 34 +++
>  drivers/media/dvb-core/dvbdev.h | 51 
> -
>  2 files changed, 64 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> index 41aad0f99d73..7b4cdcfbb02c 100644
> --- a/drivers/media/dvb-core/dvbdev.c
> +++ b/drivers/media/dvb-core/dvbdev.c
> @@ -51,8 +51,15 @@ static LIST_HEAD(dvb_adapter_list);
>  static DEFINE_MUTEX(dvbdev_register_lock);
>
>  static const char * const dnames[] = {
> -   "video", "audio", "sec", "frontend", "demux", "dvr", "ca",
> -   "net", "osd"
> +   [DVB_DEVICE_VIDEO] ="video",
> +   [DVB_DEVICE_AUDIO] ="audio",
> +   [DVB_DEVICE_SEC] =  "sec",
> +   [DVB_DEVICE_FRONTEND] = "frontend",
> +   [DVB_DEVICE_DEMUX] ="demux",
> +   [DVB_DEVICE_DVR] =  "dvr",
> +   [DVB_DEVICE_CA] =   "ca",
> +   [DVB_DEVICE_NET] =  "net",
> +   [DVB_DEVICE_OSD] =  "osd"
>  };
>
>  #ifdef CONFIG_DVB_DYNAMIC_MINORS
> @@ -60,7 +67,24 @@ static const char * const dnames[] = {
>  #define DVB_MAX_IDSMAX_DVB_MINORS
>  #else
>  #define DVB_MAX_IDS4
> -#define nums2minor(num, type, id)  ((num << 6) | (id << 4) | type)
> +
> +static int nums2minor(int num, enum dvb_device_type type, int id)
> +{
> +   int n = (num << 6) | (id << 4);
> +
> +   switch (type) {
> +   case DVB_DEVICE_VIDEO:  return n;
> +   case DVB_DEVICE_AUDIO:  return n | 1;
> +   case DVB_DEVICE_SEC:return n | 2;
> +   case DVB_DEVICE_FRONTEND:   return n | 3;
> +   case DVB_DEVICE_DEMUX:  return n | 4;
> +   case DVB_DEVICE_DVR:return n | 5;
> +   case DVB_DEVICE_CA: return n | 6;
> +   case DVB_DEVICE_NET:return n | 7;
> +   case DVB_DEVICE_OSD:return n | 8;
> +   }
> +}
> +
>  #define MAX_DVB_MINORS (DVB_MAX_ADAPTERS*64)
>  #endif
>
> @@ -426,8 +450,8 @@ static int dvb_register_media_device(struct dvb_device 
> *dvbdev,
>  }
>
>  int dvb_register_device(struct dvb_adapter *adap, struct dvb_device 
> **pdvbdev,
> -   const struct dvb_device *template, void *priv, int 
> type,
> -   int demux_sink_pads)
> +   const struct dvb_device *template, void *priv,
> +   enum dvb_device_type type, int demux_sink_pads)
>  {
> struct dvb_device *dvbdev;
> struct file_operations *dvbdevfops;
> diff --git a/drivers/media/dvb-core/dvbdev.h b/drivers/media/dvb-core/dvbdev.h
> index 49189392cf3b..53058da83873 100644
> --- a/drivers/media/dvb-core/dvbdev.h
> +++ b/drivers/media/dvb-core/dvbdev.h
> @@ -35,15 +35,37 @@
>
>  #define DVB_UNSET (-1)
>
> -#define DVB_DEVICE_VIDEO  0
> -#define DVB_DEVICE_AUDIO  1
> -#define DVB_DEVICE_SEC2
> -#define DVB_DEVICE_FRONTEND   3
> -#define DVB_DEVICE_DEMUX  4
> -#define DVB_DEVICE_DVR5
> -#define DVB_DEVICE_CA 6
> -#define DVB_DEVICE_NET7
> -#define DVB_DEVICE_OSD8
> +/* List of DVB device types */
> +
> +/**
> + * enum dvb_device_type - type of the Digital TV device
> + *
> + * @DVB_DEVICE_SEC:Digital TV standalone Common Interface (CI)
> + * @DVB_DEVICE_FRONTEND:   Digital TV frontend.
> + * @DVB_DEVICE_DEMUX:  Digital TV demux.
> + * @DVB_DEVICE_DVR:Digital TV digital video record (DVR).
> + * @DVB_DEVICE_CA: Digital TV Conditional Access (CA).
> + * @DVB_DEVICE_NET:Digital TV network.
> + *
> + * @DVB_DEVICE_VIDEO:  Digital TV video decoder.
> + * Deprecated. Used only on av7110-av.
> + * @DVB_DEVICE_AUDIO:  Digital TV audio decoder.
> + * Deprecated. Used only on av7110-av.
> + * @DVB_DEVICE_OSD:Digital TV On Screen Display (OSD).
> + * Deprecated. Used only on av7110.
> + */
> +enum dvb_device_type {
> +   DVB_DEVICE_SEC,
> +   DVB_DEVICE_FRONTEND,
> +   DVB_DEVICE_DEMUX,
> +   DVB_DEVICE_DVR,
> +   DVB_DEVICE_CA,
> +   DVB_DEVICE_NET,
> +
> +   DVB_DEVICE_VIDEO,
> +   DVB_DEVICE_AUDIO,
> +   DVB_DEVICE_OSD,
> +};

maybe instead:
```
enum dvb_device_type {
 DVB_DEVICE_SEC  = 0,
 DVB_DEVICE_FRONTEND = 1,
 DVB_DEVICE_DEMUX= 2,
 DVB_DEVICE_DVR  = 3,
 DVB_DEVICE_CA   = 4,
 DVB_DEVICE_NET  = 5,

 DVB_DEVICE_VIDEO= 6,
 DVB_DEVICE_AUDIO= 7,
 DVB_DEVICE_OSD  = 8,
};
```

...and then maybe `nums2minor()` can be 

Re: [RFC 3/5] media: get rid of get_property() callback

[Michael Ira Krufky]

On Thu, Sep 14, 2017 at 7:44 AM, Mauro Carvalho Chehab
<mche...@s-opensource.com> wrote:
> Only lg2160 implement gets_property, but there's no need for that,
> as no other driver calls this callback, as get_frontend() does the
> same, and set_frontend() also calls lg2160 get_frontend().
>
> So, get rid of it.
>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

Re: __tda18271_write_regs ERROR

[Michael Ira Krufky]

regs: [4-0060|M] ERROR: idx = 0x21,
> len = 1, i2c_transfer returned: -6
> [   28.125996] tda18271: RF tracking filter calibration complete
> [   28.137028] em28xx 1-1.2.4.1:1.0: DVB: adapter 0 frontend 0
> frequency 0 out of range (4500..86400)
>
>
> Is this expected? It's running 4.12.3-v7+ from the rpi tree.
>
>
> -Anders


The TDA18271c2 RF tracking filter calibration is a sensitive process
that requires silence on the i2c bus.  My guess is that the em28xx i2c
bus is not as quiet as it should be during this initialization.

However, first I would check to see whether the device works with the
windows driver.  Maybe it's broken.

-Michael Ira Krufky

Re: [PATCH] [media] mxl111sf: Fix potential null pointer dereference

[Michael Ira Krufky]

On Sun, Aug 13, 2017 at 6:06 AM, Eugeniu Rosca <roscaeuge...@gmail.com> wrote:
> From: Eugeniu Rosca <ero...@de.adit-jv.com>
>
> Reviewing the delta between cppcheck output of v4.9.39 and v4.9.40
> stable updates, I stumbled on the new warning:
>
> mxl111sf.c:80: (warning) Possible null pointer dereference: rbuf
>
> Since copying state->rcvbuf into rbuf is not needed in the 'write-only'
> scenario (i.e. calling mxl111sf_ctrl_msg() from mxl111sf_i2c_send_data()
> or from mxl111sf_write_reg()), bypass memcpy() in this case.
>
> Fixes: d90b336f3f65 ("[media] mxl111sf: Fix driver to use heap allocate 
> buffers for USB messages")
> Signed-off-by: Eugeniu Rosca <ero...@de.adit-jv.com>
> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)


Reviewed-by:  Michael Ira Krufky <mkru...@linuxtv.org>


Thank you for this, Eugeniu




> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index b0d5904a4ea6..67953360fda5 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -77,7 +77,9 @@ int mxl111sf_ctrl_msg(struct mxl111sf_state *state,
> dvb_usbv2_generic_rw(d, state->sndbuf, 1+wlen, state->rcvbuf,
>  rlen);
>
> -   memcpy(rbuf, state->rcvbuf, rlen);
> +   if (rbuf)
> +   memcpy(rbuf, state->rcvbuf, rlen);
> +
> mutex_unlock(>msg_lock);
>
> mxl_fail(ret);
> --
> 2.14.1
>

Re: [PATCH 1/4] [media] tw5864, fc0011: better handle WARN_ON()

[Michael Büsch]

On Thu, 18 May 2017 11:06:43 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> diff --git a/drivers/media/tuners/fc0011.c b/drivers/media/tuners/fc0011.c
> index 192b1c7740df..145407dee3db 100644
> --- a/drivers/media/tuners/fc0011.c
> +++ b/drivers/media/tuners/fc0011.c
> @@ -342,6 +342,7 @@ static int fc0011_set_params(struct dvb_frontend *fe)
>   switch (vco_sel) {
>   default:
>   WARN_ON(1);
> + return -EINVAL;
>   case 0:
>   if (vco_cal < 8) {
>   regs[FC11_REG_VCOSEL] &= ~(FC11_VCOSEL_1 | 
> FC11_VCOSEL_2);

This fall through is intentional, but I guess returning an error is OK,
too. This should not happen anyway.
I cannot test this, though.

Acked-by: Michael Büsch <m...@bues.ch>

-- 
Michael


pgpfAl6Qz6id8.pgp
Description: OpenPGP digital signature

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Michael Zoran]

On Mon, 2017-03-20 at 12:33 -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 20 Mar 2017 08:11:41 -0700
> Michael Zoran <mzo...@crowfest.net> escreveu:
> 
> > On Mon, 2017-03-20 at 11:58 -0300, Mauro Carvalho Chehab wrote:
> > > Em Mon, 20 Mar 2017 04:08:21 -0700
> > > Michael Zoran <mzo...@crowfest.net> escreveu:
> > >   
> > > > On Mon, 2017-03-20 at 07:58 -0300, Mauro Carvalho Chehab
> > > > wrote:  
> > > > > Em Sun, 19 Mar 2017 22:11:07 -0300
> > > > > Mauro Carvalho Chehab <mche...@s-opensource.com> escreveu:
> > > > > 
> > > > > > Em Sun, 19 Mar 2017 10:04:28 -0700
> > > > > > Michael Zoran <mzo...@crowfest.net> escreveu:
> > > > > > 
> > > > > > > A working DT that I tried this morning with the current
> > > > > > > firmware
> > > > > > > is
> > > > > > > posted here:
> > > > > > > http://lists.infradead.org/pipermail/linux-rpi-kernel/201
> > > > > > > 7-Ma
> > > > > > > rch/
> > > > > > > 005924
> > > > > > > .html
> > > > > > > 
> > > > > > > It even works with minecraft_pi!  
> > > > > 
> > > > > 
> > > > 
> > > > Hi, can you e-mail out your config.txt?  Do you have audio
> > > > enabled
> > > > in
> > > > config.txt?  
> > > 
> > > yes, I have this:
> > > 
> > > $ cat config.txt |grep -i audio
> > > # uncomment to force a HDMI mode rather than DVI. This can make
> > > audio
> > > work in
> > > # Enable audio (loads snd_bcm2835)
> > > dtparam=audio=on
> > > 
> > > Full config attached.
> > > 
> > > Thanks,
> > > Mauro
> > >   
> > 
> > Are you using Eric Anholt's HDMI Audio driver that's included in
> > VC4? 
> > That could well be incompatible with the firmware driver. Or are
> > you
> > using a half mode of VC4 for audio and VCHIQ for video?
> 
> I'm using vanilla staging Kernel, from Greg's tree:
>   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
> git/commit/?h=staging-
> next=7bc49cb9b9b8bad32536c4b6d1aff1824c1adc6c
> 
> Plus the DWC2 fixup I wrote and DT changes you pointed
> (see enclosed).
> 
> I can disable the audio overlay here, as I don't have anything 
> connected to audio inputs/outputs.
> 
> Regards,
> Mauro
> 

Why is the vchiq node in the tree twice? For me to even respond anymore
you you going to have to include your entire dtb(whatever you are
using) run through dtc -I dtb -O dts.  You are also going to have to
include your exact .config file you used for building, and exactly what
these DWC2 fixeups are.

You don't even state exactly what platform you are using, Is it even an
RPI of some kind.

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Michael Zoran]

On Mon, 2017-03-20 at 11:58 -0300, Mauro Carvalho Chehab wrote:
> Em Mon, 20 Mar 2017 04:08:21 -0700
> Michael Zoran <mzo...@crowfest.net> escreveu:
> 
> > On Mon, 2017-03-20 at 07:58 -0300, Mauro Carvalho Chehab wrote:
> > > Em Sun, 19 Mar 2017 22:11:07 -0300
> > > Mauro Carvalho Chehab <mche...@s-opensource.com> escreveu:
> > >   
> > > > Em Sun, 19 Mar 2017 10:04:28 -0700
> > > > Michael Zoran <mzo...@crowfest.net> escreveu:
> > > >   
> > > > > A working DT that I tried this morning with the current
> > > > > firmware
> > > > > is
> > > > > posted here:
> > > > > http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-Ma
> > > > > rch/
> > > > > 005924
> > > > > .html
> > > > > 
> > > > > It even works with minecraft_pi!
> > > 
> > >   
> > 
> > Hi, can you e-mail out your config.txt?  Do you have audio enabled
> > in
> > config.txt?
> 
> yes, I have this:
> 
> $ cat config.txt |grep -i audio
> # uncomment to force a HDMI mode rather than DVI. This can make audio
> work in
> # Enable audio (loads snd_bcm2835)
> dtparam=audio=on
> 
> Full config attached.
> 
> Thanks,
> Mauro
> 

Are you using Eric Anholt's HDMI Audio driver that's included in VC4? 
That could well be incompatible with the firmware driver. Or are you
using a half mode of VC4 for audio and VCHIQ for video?

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Michael Zoran]

On Mon, 2017-03-20 at 07:58 -0300, Mauro Carvalho Chehab wrote:
> Em Sun, 19 Mar 2017 22:11:07 -0300
> Mauro Carvalho Chehab <mche...@s-opensource.com> escreveu:
> 
> > Em Sun, 19 Mar 2017 10:04:28 -0700
> > Michael Zoran <mzo...@crowfest.net> escreveu:
> > 
> > > A working DT that I tried this morning with the current firmware
> > > is
> > > posted here:
> > > http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/
> > > 005924
> > > .html
> > > 
> > > It even works with minecraft_pi!  
> 
> With the new firmware, sometime after booting, I'm getting an oops,
> caused
> by bcm2835_audio/vchiq:
> 
> [  298.788995] Unable to handle kernel NULL pointer dereference at
> virtual address 0034
> [  298.821458] pgd = ed004000
> [  298.832294] [0034] *pgd=2e5e9835, *pte=,
> *ppte=
> [  298.857450] Internal error: Oops: 17 [#1] SMP ARM
> [  298.876273] Modules linked in: cfg80211 hid_logitech_hidpp
> hid_logitech_dj snd_bcm2835(C) snd_pcm snd_timer snd soundcore
> vchiq(C) uio_pdrv_genirq uio fuse
> [  298.932064] CPU: 3 PID: 847 Comm: pulseaudio Tainted:
> G C  4.11.0-rc1+ #56
> [  298.963774] Hardware name: Generic DT based system
> [  298.982945] task: ef758580 task.stack: ee4c6000
> [  299.001080] PC is at mutex_lock+0x14/0x3c
> [  299.017148] LR is at vchiq_add_service_internal+0x138/0x3a0
> [vchiq]
> [  299.042246] pc : []lr : []psr:
> 4013
> sp : ee4c7ca8  ip :   fp : ef709800
> [  299.088240] r10:   r9 : ee3bffc0  r8 : 0034
> [  299.109153] r7 : 0003  r6 :   r5 : ee4c7d00  r4 :
> ee1d8c00
> [  299.135291] r3 : ef758580  r2 :   r1 : ffc8  r0 :
> 0034
> [  299.161431] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA
> ARM  Segment none
> [  299.190008] Control: 10c5383d  Table: 2d00406a  DAC: 0051
> [  299.213011] Process pulseaudio (pid: 847, stack limit =
> 0xee4c6220)
> [  299.238104] Stack: (0xee4c7ca8 to 0xee4c8000)
> [  299.255539] 7ca0:   c1403d54 80400040 ff7f0600
> ff7f0660 bf06b578 ee3bffc0
> [  299.288301] 7cc0:  ee3afd00  ee4c7d00 
> bf0640b4  bf066428
> [  299.321064] 7ce0: ee3afd00 ee3afd00 ee4c7d34 ee3af444 ee3bffc0
> ee3af444 ee3bffc0 bf0662ec
> [  299.353826] 7d00: 41554453 bf065db0 ee3afd00 00010002 bf0d7408
> ee3af440  bf0d7408
> [  299.386587] 7d20: ee79bd80 bf0d5a04  ef709800 0020
> 0002 0001 41554453
> [  299.419349] 7d40:    bf0d559c ee3af440
> 0001 0001 
> [  299.452111] 7d60: ee24ac80 ee24ac80 ee1c4a00  ee79bd80
> ee24ace8 0001 bf0d4dfc
> [  299.484872] 7d80: 000b  ee4b8c3c  ee4c7dc8
> ee4b8800 ee4b8c28 ee4c6000
> [  299.517635] 7da0:  ee4b8c3c ed029e40 bf0c0404 ee4b8800
> ee1c4a00 ee4b8800 ed029e40
> [  299.550398] 7dc0:  bf0c0560 ee072340  ef758580
> c0367b7c ee4b8c40 ee4b8c40
> [  299.583161] 7de0:  ee4b8800 ed029e40 ee318f80 ed029e40
> 0006 ee318f80 bf0c0748
> [  299.615924] 7e00: bf0a3430 ee4f6180  c0428fe0 ee318f80
> 21b0 0026 ed029e40
> [  299.648697] 7e20: ee318f80 ed029e48 c0428f1c ee4c7e94 0006
> c0421cc0 ee4c7ed0 
> [  299.681464] 7e40: 0802  ee4c7e94 0006 ee318f80
> c0432c8c ee4c7f40 c0433bc0
> [  299.714225] 7e60:  ed029e40  0041 
> ed004000  ee4c6000
> [  299.746987] 7e80: eec69808 0005  0002 ee318f80
> ef0d2910 ee924908 bf0ba284
> [  299.779750] 7ea0: ee31bbc0 bebb53c4 ee4e1d00 0011 ee4c7f74
> 0001 f000 c0308b04
> [  299.812512] 7ec0: ee4c6000  bebb5710 c0434578 ef0d2910
> ee924908 73541c18 0008
> [  299.845274] 7ee0: ee4a7019   ee899bb0 ee318f80
> 0101 0002 0084
> [  299.878037] 7f00:    ee4c7f10 ee318df8
> ed029840 40045532 bebb53c4
> [  299.910799] 7f20: ee4c6000 ee4a7000 c1403ef8 bebb550c 0011
> ee5eca00 0020 ee5eca18
> [  299.943562] 7f40: ee4a7000  00080802 0002 ff9c
> f000 0011 ff9c
> [  299.976324] 7f60: ee4a7000 c0422e70 0002 c04359b0 ed029840
> 0802 ed02 0006
> [  300.009086] 7f80: 0100 0001   0004
> b189d000 0005 c0308b04
> [  300.041848] 7fa0: ee4c6000 c0308940  0004 bebb550c
> 00080802 bebb53c4 00084b58
> [  300.074611] 7fc0:  0004 b189d000 0005 
> bebb550c 00099448 bebb5710
> [  300.107373] 7fe0:  bebb53c8 b6c40da4 b6c24334 8010
> bebb550c 2fffd861 2fffdc61
> [  300.140190] [] (mutex_lock) 

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Michael Zoran]

On Sun, 2017-03-19 at 13:58 -0300, Mauro Carvalho Chehab wrote:
> Em Fri, 17 Mar 2017 17:34:36 -0700
> Eric Anholt <e...@anholt.net> escreveu:
> 
> > Mauro Carvalho Chehab <mche...@s-opensource.com> writes:
> > 
> > > Em Wed, 15 Mar 2017 18:46:24 -0700
> > > Michael Zoran <mzo...@crowfest.net> escreveu:
> > > 
> > > > On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:
> > > > 
> > > > > No, I didn't. Thanks! Applied it but, unfortunately, didn't
> > > > > work.
> > > > > Perhaps I'm missing some other patch. I'm compiling it from
> > > > > the Greg's staging tree (branch staging-next):
> > > > >   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/
> > > > > staging.
> > > > > git/log/?h=staging-next
> > > > > 
> > > > > Btw, as I'm running Raspbian, and didn't want to use compat32
> > > > > bits, 
> > > > > I'm compiling the Kernel as an arm32 bits Kernel.
> > > > > 
> > > > > I did a small trick to build the DTB on arm32:
> > > > > 
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-
> > > > > b.dts
> > > > > arch/arm/boot/dts/bcm2837-rpi-3-b.dts
> > > > >   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> > > > > arch/arm/boot/dts/bcm2837.dtsi
> > > > >   git checkout arch/arm/boot/dts/Makefile
> > > > >   sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb
> > > > > bcm2837-rpi-3-
> > > > > b.dtb," a && mv a arch/arm/boot/dts/Makefile
> > > > >   
> > > > 
> > > > Two other hacks are currently needed to get the camera to work:
> > > > 
> > > > 1. Add this to config.txt(This required to get the firmware to
> > > > detect
> > > > the camera)
> > > > 
> > > > start_x=1
> > > > gpu_mem=128
> > > 
> > > I had this already.
> > > 
> > > > 
> > > > 2. VC4 is incompatible with the firmware at this time, so you
> > > > need 
> > > > to presently munge the build configuration. What you do is
> > > > leave
> > > > simplefb in the build config(I'm assuming you already have
> > > > that), but
> > > > you will need to remove VC4 from the config.
> > > > 
> > > > The firmware currently adds a node for a simplefb for debugging
> > > > purposes to show the boot log.  Surprisingly, this is still
> > > > good enough
> > > > for basic usage and testing.  
> > > 
> > > That solved the issue. Thanks! It would be good to add a notice
> > > about that at the TODO, not let it build if DRM_VC4.
> > > 
> > > Please consider applying the enclosed path.
> > 
> > The VC4 incompatibility (camera firmware's AWB ends up briefly
> > using the
> > GPU, without coordinating with the Linux driver) is supposed to be
> > fixed
> > in current firmware
> > (https://github.com/raspberrypi/firmware/issues/760#issuecomment-28
> > 7391025)
> 
> With the current firmware, when X starts, the screen becomes blank,
> with upstream Kernel (it works with the downstream Kernel shipped
> with 
> the firmware).
> 
> Maybe something changed at DT?
> 
> Thanks,
> Mauro

Hi, exactly which DT are you using and which drivers are you using for
video. If this is a RPI 3, then as you know VC4 doesn't work due to the
HDMI hotplug issue. So I'm not 100% sure how you were getting video.

A working DT that I tried this morning with the current firmware is
posted here:
http://lists.infradead.org/pipermail/linux-rpi-kernel/2017-March/005924
.html

It even works with minecraft_pi!

Re: [PATCH v3 4/7] macintosh: Only descend into directory when CONFIG_MACINTOSH_DRIVERS is set

[Michael Ellerman]

"Andrew F. Davis" <a...@ti.com> writes:

> When CONFIG_MACINTOSH_DRIVERS is not set make will still descend into the
> macintosh directory but nothing will be built. This produces unneeded
> build artifacts and messages in addition to slowing the build.
> Fix this here.
>
> Signed-off-by: Andrew F. Davis <a...@ti.com>
> ---
>  drivers/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

LGTM.

Acked-by: Michael Ellerman <m...@ellerman.id.au>

cheersj

Re: [PATCH 0/6] staging: BCM2835 MMAL V4L2 camera driver

[Michael Zoran]

On Wed, 2017-03-15 at 22:08 -0300, Mauro Carvalho Chehab wrote:

> No, I didn't. Thanks! Applied it but, unfortunately, didn't work.
> Perhaps I'm missing some other patch. I'm compiling it from
> the Greg's staging tree (branch staging-next):
>   https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.
> git/log/?h=staging-next
> 
> Btw, as I'm running Raspbian, and didn't want to use compat32 bits, 
> I'm compiling the Kernel as an arm32 bits Kernel.
> 
> I did a small trick to build the DTB on arm32:
> 
>   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837-rpi-3-b.dts
> arch/arm/boot/dts/bcm2837-rpi-3-b.dts
>   ln -sf ../../../arm64/boot/dts/broadcom/bcm2837.dtsi
> arch/arm/boot/dts/bcm2837.dtsi
>   git checkout arch/arm/boot/dts/Makefile
>   sed "s,bcm2835-rpi-zero.dtb,bcm2835-rpi-zero.dtb bcm2837-rpi-3-
> b.dtb," a && mv a arch/arm/boot/dts/Makefile
> 

Two other hacks are currently needed to get the camera to work:

1. Add this to config.txt(This required to get the firmware to detect
the camera)

start_x=1
gpu_mem=128

2. VC4 is incompatible with the firmware at this time, so you need 
to presently munge the build configuration. What you do is leave
simplefb in the build config(I'm assuming you already have that), but
you will need to remove VC4 from the config.

The firmware currently adds a node for a simplefb for debugging
purposes to show the boot log.  Surprisingly, this is still good enough
for basic usage and testing.  

The only remaining issue is that since simplefb is intented for
debugging, you wan't be able to use many of the RPI specific
applications.  

I've been using cheese and ffmpeg to test the camera which are not RPI
specific.

Re: [PATCH 08/29] drivers, md: convert mddev.active from atomic_t to refcount_t

[Michael Ellerman]

Elena Reshetova  writes:

> refcount_t type and corresponding API should be
> used instead of atomic_t when the variable is used as
> a reference counter. This allows to avoid accidental
> refcounter overflows that might lead to use-after-free
> situations.
>
> Signed-off-by: Elena Reshetova 
> Signed-off-by: Hans Liljestrand 
> Signed-off-by: Kees Cook 
> Signed-off-by: David Windsor 
> ---
>  drivers/md/md.c | 6 +++---
>  drivers/md/md.h | 3 ++-
>  2 files changed, 5 insertions(+), 4 deletions(-)

When booting linux-next (specifically 5be4921c9958ec) I'm seeing the
backtrace below. I suspect this patch is just exposing an existing
issue?

cheers


[0.230738] md: Waiting for all devices to be available before autodetect
[0.230742] md: If you don't use raid, use raid=noautodetect
[0.230962] refcount_t: increment on 0; use-after-free.
[0.230988] [ cut here ]
[0.230996] WARNING: CPU: 0 PID: 1 at lib/refcount.c:114 
.refcount_inc+0x5c/0x70
[0.231001] Modules linked in:
[0.231006] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 
4.11.0-rc1-gccN-next-20170310-g5be4921 #1
[0.231012] task: c0004940 task.stack: c0004944
[0.231016] NIP: c05ac6bc LR: c05ac6b8 CTR: c0743390
[0.231021] REGS: c00049443160 TRAP: 0700   Not tainted  
(4.11.0-rc1-gccN-next-20170310-g5be4921)
[0.231026] MSR: 80029032 
[0.231033]   CR: 24024422  XER: 000c
[0.231038] CFAR: c0a5356c SOFTE: 1 
[0.231038] GPR00: c05ac6b8 c000494433e0 c1079d00 
002b 
[0.231038] GPR04:  00ef  
c10418a0 
[0.231038] GPR08: 4af8 c0ecc9a8 c0ecc9a8 
 
[0.231038] GPR12: 28024824 c6bb  
c00049443a00 
[0.231038] GPR16:  c00049443a10  
 
[0.231038] GPR20:   c0f7dd20 
 
[0.231038] GPR24: 014080c0 c12060b8 c1206080 
0009 
[0.231038] GPR28: c0f7dde0 0090  
c000461ae800 
[0.231100] NIP [c05ac6bc] .refcount_inc+0x5c/0x70
[0.231104] LR [c05ac6b8] .refcount_inc+0x58/0x70
[0.231108] Call Trace:
[0.231112] [c000494433e0] [c05ac6b8] .refcount_inc+0x58/0x70 
(unreliable)
[0.231120] [c00049443450] [c086c008] .mddev_find+0x1e8/0x430
[0.231125] [c00049443530] [c0872b6c] .md_open+0x2c/0x140
[0.231132] [c000494435c0] [c03962a4] .__blkdev_get+0xd4/0x520
[0.231138] [c00049443690] [c0396cc0] .blkdev_get+0x1c0/0x4f0
[0.231145] [c00049443790] [c0336d64] 
.do_dentry_open.isra.1+0x2a4/0x410
[0.231152] [c00049443830] [c03523f4] .path_openat+0x624/0x1580
[0.231157] [c00049443990] [c0354ce4] .do_filp_open+0x84/0x120
[0.231163] [c00049443b10] [c0338d74] .do_sys_open+0x214/0x300
[0.231170] [c00049443be0] [c0da69ac] .md_run_setup+0xa0/0xec
[0.231176] [c00049443c60] [c0da4fbc] 
.prepare_namespace+0x60/0x240
[0.231182] [c00049443ce0] [c0da47a8] 
.kernel_init_freeable+0x330/0x36c
[0.231190] [c00049443db0] [c000dc44] .kernel_init+0x24/0x160
[0.231197] [c00049443e30] [c000badc] 
.ret_from_kernel_thread+0x58/0x7c
[0.231202] Instruction dump:
[0.231206] 6000 3d22ffee 89296bfb 2f89 409effdc 3c62ffc6 3921 
3d42ffee 
[0.231216] 38630928 992a6bfb 484a6e79 6000 <0fe0> 4bb8 6000 
6000 
[0.231226] ---[ end trace 8c51f269ad91ffc2 ]---
[0.231233] md: Autodetecting RAID arrays.
[0.231236] md: autorun ...
[0.231239] md: ... autorun DONE.
[0.234188] EXT4-fs (sda4): mounting ext3 file system using the ext4 
subsystem
[0.250506] refcount_t: underflow; use-after-free.
[0.250531] [ cut here ]
[0.250537] WARNING: CPU: 0 PID: 3 at lib/refcount.c:207 
.refcount_dec_not_one+0x104/0x120
[0.250542] Modules linked in:
[0.250546] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: GW   
4.11.0-rc1-gccN-next-20170310-g5be4921 #1
[0.250553] Workqueue: events .delayed_fput
[0.250557] task: c00049404900 task.stack: c00049448000
[0.250562] NIP: c05ac964 LR: c05ac960 CTR: c0743390
[0.250567] REGS: c0004944b530 TRAP: 0700   Tainted: GW
(4.11.0-rc1-gccN-next-20170310-g5be4921)
[0.250572] MSR: 80029032 
[0.250578]   CR: 24002422  XER: 0007
[0.250584] CFAR: c0a5356c SOFTE: 1 
[0.250584] GPR00: c05ac960 

Re: [PATCH 1/6] staging: Import the BCM2835 MMAL-based V4L2 camera driver.

[Michael Zoran]

Dave: I'd personally like to see the current version of vchi stabbed,
poisoned, beaten, shot, chained and thrown in a river.:)

Would it be possible to find another transport for this driver to
remove the dependency on VCHI?  Given the process of improving drivers
in stagging, I don't expect VCHI to ever make it out of staging in it's
current form either. One possibility is mbox, but it has the limitation
of one one request at a time.

Also, you mention protecting IP and that V4L expects everything to be
exposed.  How does V4L2 work if I have a hybrid software/hardware video
capture device? 

In the case of other drivers in linux that upload a large firmware blob
into who knows where, how does the open source part of the driver hook
into the firmware blob?

On Sun, 2017-02-05 at 22:15 +, Dave Stevenson wrote:
> Hi Mauro.
> 
> I'm going to stick my head above the parapet as one of the original 
> authors back when I worked at Broadcom.
> As it happens I started working at Raspberry Pi last Monday, so that 
> puts me in a place where I can work on this again a bit more. (The
> last 
> two years have been just a spare time support role).
> Whilst I have done kernel development work in various roles, it's
> all 
> been downstream so I've not been that active on these lists before.
> 
> All formatting/checkpatch comments noted.
> Checkpatch was whinging when this was first written around December
> 2013 
> about long lines, so many got broken up to shut it up. Views on code 
> style and checkpatch seem to have changed a little since then.
> I thought we had made checkpatch happy before the driver was pushed,
> but 
> with some of the comments still having // style I guess some slipped 
> through the net.
> Yes chunks of this could do with refactoring to reduce the levels of 
> indentation - always more to do.
> If I've removed any formatting/style type comments in my cuts it's
> not 
> because I'm ignoring them, just that they're not something that
> needs 
> discussion (just fixing). I've only taken out the really big lumps
> of 
> code with no comments on.
> 
> Newbie question: if this has already been merged to staging, where am
> I 
> looking for the relevant tree to add patches on top of? 
> git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging.git
> branch 
> staging-next?
> 
> Responses to the rest inline.
> TL;DR answer is that you are seeing the top edge of a full ISP 
> processing pipe and optional encoders running on the GPU, mainly as 
> there are blocks that can't be exposed for IP reasons (Raspberry Pi
> only 
> being the customer not silicon vendor constrains what can and can't
> be 
> made public).
> That doesn't seem to fit very well into V4L2 which expects that it
> can 
> see all the detail, so there are a few nasty spots to shoe-horn it
> in. 
> If there are better ways to solve the problems, then I'm open to
> them.
> 
> Thanks
>    Dave
> 
> 
> On 03/02/17 18:59, Mauro Carvalho Chehab wrote:
> > HI Eric,
> > 
> > Em Fri, 27 Jan 2017 13:54:58 -0800
> > Eric Anholt  escreveu:
> > 
> > > - Supports raw YUV capture, preview, JPEG and H264.
> > > - Uses videobuf2 for data transfer, using dma_buf.
> > > - Uses 3.6.10 timestamping
> > > - Camera power based on use
> > > - Uses immutable input mode on video encoder
> > > 
> > > This code comes from the Raspberry Pi kernel tree (rpi-4.9.y) as
> > > of
> > > a15ba877dab4e61ea3fc7b006e2a73828b083c52.
> > 
> > First of all, thanks for that! Having an upstream driver for the
> > RPi camera is something that has been long waited!
> > 
> > Greg was kick on merging it on staging ;) Anyway, the real review
> > will happen when the driver becomes ready to be promoted out of
> > staging. When you address the existing issues and get it ready to
> > merge, please send the patch with such changes to linux-media ML.
> > I'll do a full review on it by then.
> 
> Is that even likely given the dependence on VCHI? I wasn't expecting 
> VCHI to leave staging, which would force this to remain too.
> 
> > Still, let me do a quick review on this driver, specially at the
> > non-MMAL code.
> > 
> > > 
> > > Signed-off-by: Eric Anholt 
> > > ---
> > >  .../media/platform/bcm2835/bcm2835-camera.c| 2016
> > > 
> > >  .../media/platform/bcm2835/bcm2835-camera.h|  145 ++
> > >  drivers/staging/media/platform/bcm2835/controls.c  | 1345
> > > +
> > >  .../staging/media/platform/bcm2835/mmal-common.h   |   53 +
> > >  .../media/platform/bcm2835/mmal-encodings.h|  127 ++
> > >  .../media/platform/bcm2835/mmal-msg-common.h   |   50 +
> > >  .../media/platform/bcm2835/mmal-msg-format.h   |   81 +
> > >  .../staging/media/platform/bcm2835/mmal-msg-port.h |  107 ++
> > >  drivers/staging/media/platform/bcm2835/mmal-msg.h  |  404 
> > >  .../media/platform/bcm2835/mmal-parameters.h   |  689
> > > +++
> > >  .../staging/media/platform/bcm2835/mmal-vchiq.c| 1916

Re: [PATCH 3/6] staging: bcm2835-v4l2: Add a build system for the module.

[Michael Zoran]

On Fri, 2017-01-27 at 13:55 -0800, Eric Anholt wrote:
> This is derived from the downstream tree's build system, but with
> just
> a single Kconfig option.
> 
> For now the driver only builds on 32-bit arm -- the aarch64 build
> breaks due to the driver using arm-specific cache flushing functions.
> 
> 

If you are referring to this:
/* enqueue a bulk receive for a given message context */
static int bulk_receive(struct vchiq_mmal_instance *instance,
struct mmal_msg *msg,
struct mmal_msg_context *msg_context)
...

// only need to flush L1 cache here, as VCHIQ takes care of the
L2
// cache.
__cpuc_flush_dcache_area(msg_context->u.bulk.buffer->buffer,
rd_len);


It should be possible to simply remove the __cpuc_flash_dcache_area
call as VCHIQ should now be flushing all the needed caches.  This is
due to the DMA API clean that was necessary to make it multiplatform.

The driver does have a few nasty issues with stuffing callback pointers
into fixed 32 bit sized integers that would need to be fixed to make it
work on 64 bit.




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

[PATCH v2] pci: drop link_reset

[Michael S. Tsirkin]

No hardware seems to actually call link_reset, and
no driver implements it as more than a nop stub.

This drops the mentions of the callback from everywhere.
It's dropped from the documentation as well, but
the doc really needs to be updated to reflect
reality better (e.g. on pcie slot reset is the link reset).

This will be done in a later patch.

Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
---

changes from v2:
- drop from genwqe as well

Note: Doug has patches dropping the implementation from infiniband card
drivers in his tree already. This is unlikely to cause conflicts though.

 Documentation/PCI/pci-error-recovery.txt | 24 +++-
 drivers/infiniband/hw/hfi1/pcie.c| 10 --
 drivers/infiniband/hw/qib/qib_pcie.c |  8 
 drivers/media/pci/ngene/ngene-cards.c|  7 ---
 drivers/misc/genwqe/card_base.c  |  1 -
 include/linux/pci.h  |  3 ---
 6 files changed, 3 insertions(+), 50 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.txt 
b/Documentation/PCI/pci-error-recovery.txt
index ac26869..da3b217 100644
--- a/Documentation/PCI/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
@@ -78,7 +78,6 @@ struct pci_error_handlers
 {
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
int (*mmio_enabled)(struct pci_dev *dev);
-   int (*link_reset)(struct pci_dev *dev);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
 };
@@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). 
If a callback
 is not implemented, the corresponding feature is considered unsupported.
 For example, if mmio_enabled() and resume() aren't there, then it
 is assumed that the driver is not doing any direct recovery and requires
-a slot reset. If link_reset() is not implemented, the card is assumed to
-not care about link resets. Typically a driver will want to know about
+a slot reset.  Typically a driver will want to know about
 a slot_reset().
 
 The actual steps taken by a platform to recover from a PCI error
@@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset)
 
 STEP 3: Link Reset
 --
-The platform resets the link, and then calls the link_reset() callback
-on all affected device drivers.  This is a PCI-Express specific state
+The platform resets the link.  This is a PCI-Express specific step
 and is done whenever a non-fatal error has been detected that can be
-"solved" by resetting the link. This call informs the driver of the
-reset and the driver should check to see if the device appears to be
-in working condition.
-
-The driver is not supposed to restart normal driver I/O operations
-at this point.  It should limit itself to "probing" the device to
-check its recoverability status. If all is right, then the platform
-will call resume() once all drivers have ack'd link_reset().
-
-   Result codes:
-   (identical to STEP 3 (MMIO Enabled)
-
-The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5
-(Resume Operations).
-
->>> The current powerpc implementation does not implement this callback.
+"solved" by resetting the link.
 
 STEP 4: Slot Reset
 --
diff --git a/drivers/infiniband/hw/hfi1/pcie.c 
b/drivers/infiniband/hw/hfi1/pcie.c
index 4ac8f33..ebd941f 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -598,15 +598,6 @@ pci_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
-static pci_ers_result_t
-pci_link_reset(struct pci_dev *pdev)
-{
-   struct hfi1_devdata *dd = pci_get_drvdata(pdev);
-
-   dd_dev_info(dd, "HFI1 link_reset function called, ignored\n");
-   return PCI_ERS_RESULT_CAN_RECOVER;
-}
-
 static void
 pci_resume(struct pci_dev *pdev)
 {
@@ -625,7 +616,6 @@ pci_resume(struct pci_dev *pdev)
 const struct pci_error_handlers hfi1_pci_err_handler = {
.error_detected = pci_error_detected,
.mmio_enabled = pci_mmio_enabled,
-   .link_reset = pci_link_reset,
.slot_reset = pci_slot_reset,
.resume = pci_resume,
 };
diff --git a/drivers/infiniband/hw/qib/qib_pcie.c 
b/drivers/infiniband/hw/qib/qib_pcie.c
index 6abe1c6..c379b83 100644
--- a/drivers/infiniband/hw/qib/qib_pcie.c
+++ b/drivers/infiniband/hw/qib/qib_pcie.c
@@ -682,13 +682,6 @@ qib_pci_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
-static pci_ers_result_t
-qib_pci_link_reset(struct pci_dev *pdev)
-{
-   qib_devinfo(pdev, "QIB link_reset function called, ignored\n");
-   return PCI_ERS_RESULT_CAN_RECOVER;
-}
-
 static void
 qib_pci_resume(struct pci_dev *pdev)
 {
@@ -707,7 +700,6 @@ qib_pci_resume(struct pci_dev *pdev)
 const struct pci_error_handlers qib_pci_err_handler = {
.error_detected = qib_pci_error_detected,
.mmio_enabled = qib_pci_mmio_enabl

Re: [PATCH] pci: drop link_reset

[Michael S. Tsirkin]

On Wed, Jan 18, 2017 at 07:19:48PM -0500, Doug Ledford wrote:
> On Wed, 2017-01-18 at 23:39 +0200, Michael S. Tsirkin wrote:
> > No hardware seems to actually call link_reset, and
> > no driver implements it as more than a nop stub.
> > 
> > This drops the mentions of the callback from everywhere.
> > It's dropped from the documentation as well, but
> > the doc really needs to be updated to reflect
> > reality better (e.g. on pcie slot reset is the link reset).
> > 
> > This will be done in a later patch.
> > 
> > Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
> 
> This is going to conflict with the two patches I have in my for-next
> branch related to this same thing (it drops the stubs from qib and
> hfi1).  It would be easiest if I just added this to my for-next and
> fixed up the conflicts prior to submission.
> 
> > ---
> >  Documentation/PCI/pci-error-recovery.txt | 24 +++---
> > --
> >  drivers/infiniband/hw/hfi1/pcie.c| 10 --
> >  drivers/infiniband/hw/qib/qib_pcie.c |  8 
> >  drivers/media/pci/ngene/ngene-cards.c|  7 ---
> >  include/linux/pci.h  |  3 ---
> >  5 files changed, 3 insertions(+), 49 deletions(-)
> > 
> > diff --git a/Documentation/PCI/pci-error-recovery.txt
> > b/Documentation/PCI/pci-error-recovery.txt
> > index ac26869..da3b217 100644
> > --- a/Documentation/PCI/pci-error-recovery.txt
> > +++ b/Documentation/PCI/pci-error-recovery.txt
> > @@ -78,7 +78,6 @@ struct pci_error_handlers
> >  {
> >     int (*error_detected)(struct pci_dev *dev, enum
> > pci_channel_state);
> >     int (*mmio_enabled)(struct pci_dev *dev);
> > -   int (*link_reset)(struct pci_dev *dev);
> >     int (*slot_reset)(struct pci_dev *dev);
> >     void (*resume)(struct pci_dev *dev);
> >  };
> > @@ -104,8 +103,7 @@ if it implements any, it must implement
> > error_detected(). If a callback
> >  is not implemented, the corresponding feature is considered
> > unsupported.
> >  For example, if mmio_enabled() and resume() aren't there, then it
> >  is assumed that the driver is not doing any direct recovery and
> > requires
> > -a slot reset. If link_reset() is not implemented, the card is
> > assumed to
> > -not care about link resets. Typically a driver will want to know
> > about
> > +a slot reset.  Typically a driver will want to know about
> >  a slot_reset().
> >  
> >  The actual steps taken by a platform to recover from a PCI error
> > @@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset)
> >  
> >  STEP 3: Link Reset
> >  --
> > -The platform resets the link, and then calls the link_reset()
> > callback
> > -on all affected device drivers.  This is a PCI-Express specific
> > state
> > +The platform resets the link.  This is a PCI-Express specific step
> >  and is done whenever a non-fatal error has been detected that can be
> > -"solved" by resetting the link. This call informs the driver of the
> > -reset and the driver should check to see if the device appears to be
> > -in working condition.
> > -
> > -The driver is not supposed to restart normal driver I/O operations
> > -at this point.  It should limit itself to "probing" the device to
> > -check its recoverability status. If all is right, then the platform
> > -will call resume() once all drivers have ack'd link_reset().
> > -
> > -   Result codes:
> > -   (identical to STEP 3 (MMIO Enabled)
> > -
> > -The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5
> > -(Resume Operations).
> > -
> > ->>> The current powerpc implementation does not implement this
> > callback.
> > +"solved" by resetting the link.
> >  
> >  STEP 4: Slot Reset
> >  --
> > diff --git a/drivers/infiniband/hw/hfi1/pcie.c
> > b/drivers/infiniband/hw/hfi1/pcie.c
> > index 4ac8f33..ebd941f 100644
> > --- a/drivers/infiniband/hw/hfi1/pcie.c
> > +++ b/drivers/infiniband/hw/hfi1/pcie.c
> > @@ -598,15 +598,6 @@ pci_slot_reset(struct pci_dev *pdev)
> >     return PCI_ERS_RESULT_CAN_RECOVER;
> >  }
> >  
> > -static pci_ers_result_t
> > -pci_link_reset(struct pci_dev *pdev)
> > -{
> > -   struct hfi1_devdata *dd = pci_get_drvdata(pdev);
> > -
> > -   dd_dev_info(dd, "HFI1 link_reset function called,
> > ignored\n");
> > -   return PCI_ERS_RESULT_CAN_RECOVER;
> > -}
> > -
> >  static 

[PATCH v4 3/7] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 9e6bdafa16f5..fa3ed74af116 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, );
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, _cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, _cap, );
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.11.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

[PATCH v4 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

Add a DT binding documentation for the Video Data Order Adapter (VDOA)
of the Freescale i.MX6 SoC.

Also, add the compatible property and correct clock to the device tree
to match the documentation.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Acked-by: Rob Herring <r...@kernel.org>
---
 .../devicetree/bindings/media/fsl-vdoa.txt  | 21 +
 arch/arm/boot/dts/imx6qdl.dtsi  |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt

diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt 
b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index ..6c5628530bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+is to reorder video data from the macroblock tiled order produced by the CODA
+960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@21e4000 {
+compatible = "fsl,imx6q-vdoa";
+reg = <0x021e4000 0x4000>;
+interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 89b834f3fa17..a227e8be5378 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1158,8 +1158,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.11.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

[PATCH v4 6/7] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  86 +---
 drivers/media/platform/coda/coda-common.c | 104 --
 drivers/media/platform/coda/coda.h|   3 +
 3 files changed, 163 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4eb5ad1..f608de4c52ac 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, >v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1618,6 +1624,15 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 __func__, ctx->idx, width, height);
 
ctx->num_internal_frames = coda_read(dev, CODA_RET_DEC_SEQ_FRAME_NEED);
+   /*
+* If the VDOA is used, the decoder needs one additional frame,
+* because the frames are freed when the next frame is decoded.
+* Otherwise there are visible errors in the decoded frames (green
+* regions in displayed frames) and a broken order of frames (earlier
+* frames are sporadically displayed after later frames).
+*/
+   if (ctx->use_vdoa)
+   ctx->num_internal_frames += 1;
if (ctx->num_internal_frames > CODA_MAX_FRAMEBUFFERS) {
v4l2_err(>v4l2_dev,
 "not enough framebuffers to decode (%d < %d)\n",
@@ -1724,6 +1739,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1775,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries

[PATCH v4 7/7] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index f608de4c52ac..466a44e4549e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2079,6 +2079,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 13ee6cba6847..a918b294adef 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -434,6 +442,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f-&

[PATCH v4 0/7] Add support for Video Data Order Adapter

[Michael Tretter]

Hello,

This is v4 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.

Changes since v3:

- Patch 2/7: Add my copyright to vdoa copyright header
- Patch 2/7: Fix offset of chroma plane to be page-aligned
- Patch 6/7: Fix oops when releasing the coda driver by destroying vdoa
  context after removing all buffers
- Patch 6/7: Fix missing vdoa disable when switching from tiled to linear
  format

Changes since v2:

- Patch 1/7: Update commit message to include binding change; fix
  spelling/style in binding documentation

Changes since v1:

- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
  parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use

Michael Tretter (3):
  [media] coda: fix frame index to returned error
  [media] coda: use VDOA for un-tiling custom macroblock format
  [media] coda: support YUYV output if VDOA is used

Philipp Zabel (4):
  [media] dt-bindings: Add a binding for Video Data Order Adapter
  [media] coda: add i.MX6 VDOA driver
  [media] coda: correctly set capture compose rectangle
  [media] coda: add debug output about tiling

 .../devicetree/bindings/media/fsl-vdoa.txt |  21 ++
 arch/arm/boot/dts/imx6qdl.dtsi |   2 +
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/coda-bit.c |  93 --
 drivers/media/platform/coda/coda-common.c  | 175 ++-
 drivers/media/platform/coda/coda.h |   3 +
 drivers/media/platform/coda/imx-vdoa.c | 338 +
 drivers/media/platform/coda/imx-vdoa.h |  58 
 9 files changed, 652 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

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

[PATCH v4 2/7] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 338 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 400 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..595652613db9 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac57b230..858284328af9 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index ..f61baf7dcbc1
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,338 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ * Copyright (C) 2016 Pengutronix, Michael Tretter <ker...@pengutronix.de>
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = d

[PATCH v4 5/7] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b6625047250d..309eb4eb5ad1 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, >v4l2_dev,
-- 
2.11.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

[PATCH v4 4/7] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index fa3ed74af116..b23fe0f0fb56 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, >dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.11.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

[PATCH] pci: drop link_reset

[Michael S. Tsirkin]

No hardware seems to actually call link_reset, and
no driver implements it as more than a nop stub.

This drops the mentions of the callback from everywhere.
It's dropped from the documentation as well, but
the doc really needs to be updated to reflect
reality better (e.g. on pcie slot reset is the link reset).

This will be done in a later patch.

Signed-off-by: Michael S. Tsirkin <m...@redhat.com>
---
 Documentation/PCI/pci-error-recovery.txt | 24 +++-
 drivers/infiniband/hw/hfi1/pcie.c| 10 --
 drivers/infiniband/hw/qib/qib_pcie.c |  8 
 drivers/media/pci/ngene/ngene-cards.c|  7 ---
 include/linux/pci.h  |  3 ---
 5 files changed, 3 insertions(+), 49 deletions(-)

diff --git a/Documentation/PCI/pci-error-recovery.txt 
b/Documentation/PCI/pci-error-recovery.txt
index ac26869..da3b217 100644
--- a/Documentation/PCI/pci-error-recovery.txt
+++ b/Documentation/PCI/pci-error-recovery.txt
@@ -78,7 +78,6 @@ struct pci_error_handlers
 {
int (*error_detected)(struct pci_dev *dev, enum pci_channel_state);
int (*mmio_enabled)(struct pci_dev *dev);
-   int (*link_reset)(struct pci_dev *dev);
int (*slot_reset)(struct pci_dev *dev);
void (*resume)(struct pci_dev *dev);
 };
@@ -104,8 +103,7 @@ if it implements any, it must implement error_detected(). 
If a callback
 is not implemented, the corresponding feature is considered unsupported.
 For example, if mmio_enabled() and resume() aren't there, then it
 is assumed that the driver is not doing any direct recovery and requires
-a slot reset. If link_reset() is not implemented, the card is assumed to
-not care about link resets. Typically a driver will want to know about
+a slot reset.  Typically a driver will want to know about
 a slot_reset().
 
 The actual steps taken by a platform to recover from a PCI error
@@ -232,25 +230,9 @@ proceeds to STEP 4 (Slot Reset)
 
 STEP 3: Link Reset
 --
-The platform resets the link, and then calls the link_reset() callback
-on all affected device drivers.  This is a PCI-Express specific state
+The platform resets the link.  This is a PCI-Express specific step
 and is done whenever a non-fatal error has been detected that can be
-"solved" by resetting the link. This call informs the driver of the
-reset and the driver should check to see if the device appears to be
-in working condition.
-
-The driver is not supposed to restart normal driver I/O operations
-at this point.  It should limit itself to "probing" the device to
-check its recoverability status. If all is right, then the platform
-will call resume() once all drivers have ack'd link_reset().
-
-   Result codes:
-   (identical to STEP 3 (MMIO Enabled)
-
-The platform then proceeds to either STEP 4 (Slot Reset) or STEP 5
-(Resume Operations).
-
->>> The current powerpc implementation does not implement this callback.
+"solved" by resetting the link.
 
 STEP 4: Slot Reset
 --
diff --git a/drivers/infiniband/hw/hfi1/pcie.c 
b/drivers/infiniband/hw/hfi1/pcie.c
index 4ac8f33..ebd941f 100644
--- a/drivers/infiniband/hw/hfi1/pcie.c
+++ b/drivers/infiniband/hw/hfi1/pcie.c
@@ -598,15 +598,6 @@ pci_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
-static pci_ers_result_t
-pci_link_reset(struct pci_dev *pdev)
-{
-   struct hfi1_devdata *dd = pci_get_drvdata(pdev);
-
-   dd_dev_info(dd, "HFI1 link_reset function called, ignored\n");
-   return PCI_ERS_RESULT_CAN_RECOVER;
-}
-
 static void
 pci_resume(struct pci_dev *pdev)
 {
@@ -625,7 +616,6 @@ pci_resume(struct pci_dev *pdev)
 const struct pci_error_handlers hfi1_pci_err_handler = {
.error_detected = pci_error_detected,
.mmio_enabled = pci_mmio_enabled,
-   .link_reset = pci_link_reset,
.slot_reset = pci_slot_reset,
.resume = pci_resume,
 };
diff --git a/drivers/infiniband/hw/qib/qib_pcie.c 
b/drivers/infiniband/hw/qib/qib_pcie.c
index 6abe1c6..c379b83 100644
--- a/drivers/infiniband/hw/qib/qib_pcie.c
+++ b/drivers/infiniband/hw/qib/qib_pcie.c
@@ -682,13 +682,6 @@ qib_pci_slot_reset(struct pci_dev *pdev)
return PCI_ERS_RESULT_CAN_RECOVER;
 }
 
-static pci_ers_result_t
-qib_pci_link_reset(struct pci_dev *pdev)
-{
-   qib_devinfo(pdev, "QIB link_reset function called, ignored\n");
-   return PCI_ERS_RESULT_CAN_RECOVER;
-}
-
 static void
 qib_pci_resume(struct pci_dev *pdev)
 {
@@ -707,7 +700,6 @@ qib_pci_resume(struct pci_dev *pdev)
 const struct pci_error_handlers qib_pci_err_handler = {
.error_detected = qib_pci_error_detected,
.mmio_enabled = qib_pci_mmio_enabled,
-   .link_reset = qib_pci_link_reset,
.slot_reset = qib_pci_slot_reset,
.resume = qib_pci_resume,
 };
diff --git a/drivers/media/pci/ngene/ngene-cards.c 
b/drivers/media/pci/ngene/ngene-cards.c
index 423e8c8..8438c1c 100644
--

Re: Problem with Hauppauge WinTV-HVR-1250

[Michael Ira Krufky]

On Fri, Jan 13, 2017 at 11:56 PM, Justin Husted  wrote:
> Hi!
>
> I recently got one of these cards on ebay to do some analog video capturing,
> and I'm having a few problems with it on the 4.4.0 kernel.
>
> I wasn't really sure who the maintainer is for this stuff, but I saw your
> name in the Linux MAINTAINERS file for the tda18271, which seems to be one
> of the relevant drivers. :-)
>
> Are you the person to talk to, or do you know who is?
>
> Thanks!
> -Justin
>


Justin,

Better to email the linux-media mailing list on kernel.org with this
type of question (cc added)

What is the problem that you're having in the 4.4.0 kernel?

Which is the most recent kernel that works for you correctly?

Do you have logs that illustrate your problem?

Best regards,

Mike
--
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 v3 4/7] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index fa3ed74af116..b23fe0f0fb56 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, >dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.11.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

[PATCH v3 2/7] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 397 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index d944421e392d..595652613db9 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac57b230..858284328af9 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index ..36ceffbf08de
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,335 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = data;
+

[PATCH v3 7/7] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index f608de4c52ac..466a44e4549e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2079,6 +2079,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 8977a56d6a38..756a235895e5 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -434,6 +442,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f-&

[PATCH v3 6/7] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  86 +
 drivers/media/platform/coda/coda-common.c | 102 --
 drivers/media/platform/coda/coda.h|   3 +
 3 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4eb5ad1..f608de4c52ac 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, >v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1618,6 +1624,15 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 __func__, ctx->idx, width, height);
 
ctx->num_internal_frames = coda_read(dev, CODA_RET_DEC_SEQ_FRAME_NEED);
+   /*
+* If the VDOA is used, the decoder needs one additional frame,
+* because the frames are freed when the next frame is decoded.
+* Otherwise there are visible errors in the decoded frames (green
+* regions in displayed frames) and a broken order of frames (earlier
+* frames are sporadically displayed after later frames).
+*/
+   if (ctx->use_vdoa)
+   ctx->num_internal_frames += 1;
if (ctx->num_internal_frames > CODA_MAX_FRAMEBUFFERS) {
v4l2_err(>v4l2_dev,
 "not enough framebuffers to decode (%d < %d)\n",
@@ -1724,6 +1739,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1775,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries

[PATCH v3 5/7] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b6625047250d..309eb4eb5ad1 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, >v4l2_dev,
-- 
2.11.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

[PATCH v3 0/7] Add support for Video Data Order Adapter

[Michael Tretter]

Hello,

This is v3 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.

Changes since v2:

- Patch 1/7: Update commit message to include binding change; fix
  spelling/style in binding documentation

Changes since v1:

- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
  parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use


Michael Tretter (3):
  [media] coda: fix frame index to returned error
  [media] coda: use VDOA for un-tiling custom macroblock format
  [media] coda: support YUYV output if VDOA is used

Philipp Zabel (4):
  [media] dt-bindings: Add a binding for Video Data Order Adapter
  [media] coda: add i.MX6 VDOA driver
  [media] coda: correctly set capture compose rectangle
  [media] coda: add debug output about tiling

 .../devicetree/bindings/media/fsl-vdoa.txt |  21 ++
 arch/arm/boot/dts/imx6qdl.dtsi |   2 +
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/coda-bit.c |  93 --
 drivers/media/platform/coda/coda-common.c  | 175 ++-
 drivers/media/platform/coda/coda.h |   3 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 
 9 files changed, 649 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

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

[PATCH v3 3/7] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 9e6bdafa16f5..fa3ed74af116 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, );
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, _cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, _cap, );
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.11.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

[PATCH v3 1/7] [media] dt-bindings: Add a binding for Video Data Order Adapter

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

Add a DT binding documentation for the Video Data Order Adapter (VDOA)
of the Freescale i.MX6 SoC.

Also, add the compatible property and correct clock to the device tree
to match the documentation.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 .../devicetree/bindings/media/fsl-vdoa.txt  | 21 +
 arch/arm/boot/dts/imx6qdl.dtsi  |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt

diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt 
b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index ..6c5628530bb7
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+is to reorder video data from the macroblock tiled order produced by the CODA
+960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@21e4000 {
+compatible = "fsl,imx6q-vdoa";
+reg = <0x021e4000 0x4000>;
+interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 53e6e63cbb02..61569c86d28e 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1157,8 +1157,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.11.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

[PATCH v2 6/7] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  86 +
 drivers/media/platform/coda/coda-common.c | 102 --
 drivers/media/platform/coda/coda.h|   3 +
 3 files changed, 161 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4e..f608de4 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, >v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1618,6 +1624,15 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 __func__, ctx->idx, width, height);
 
ctx->num_internal_frames = coda_read(dev, CODA_RET_DEC_SEQ_FRAME_NEED);
+   /*
+* If the VDOA is used, the decoder needs one additional frame,
+* because the frames are freed when the next frame is decoded.
+* Otherwise there are visible errors in the decoded frames (green
+* regions in displayed frames) and a broken order of frames (earlier
+* frames are sporadically displayed after later frames).
+*/
+   if (ctx->use_vdoa)
+   ctx->num_internal_frames += 1;
if (ctx->num_internal_frames > CODA_MAX_FRAMEBUFFERS) {
v4l2_err(>v4l2_dev,
 "not enough framebuffers to decode (%d < %d)\n",
@@ -1724,6 +1739,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1775,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries that includes the
+  

[PATCH v2 3/7] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index c39718a..e0184194 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, );
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, _cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, _cap, );
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.10.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 v2 5/7] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Acked-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b662504..309eb4e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, >v4l2_dev,
-- 
2.10.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 v2 7/7] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
Reviewed-by: Philipp Zabel <p.za...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index f608de4..466a44e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2079,6 +2079,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index c09cafd..43af428 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -434,6 +442,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f->fmt.pix.byt

[PATCH v2 4/7] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index e0184194..f739873 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -616,8 +616,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, >dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.10.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 v2 2/7] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 397 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ce4a96f..41e007f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac5..8582843 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index 000..36ceffb
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,335 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = data;
+   struct vdoa_ctx *curr_ctx;
+  

[PATCH v2 1/7] ARM: dts: imx6qdl: Add VDOA compatible and clocks properties

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

This adds a compatible property and the correct clock for the
i.MX6Q Video Data Order Adapter.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 .../devicetree/bindings/media/fsl-vdoa.txt  | 21 +
 arch/arm/boot/dts/imx6qdl.dtsi  |  2 ++
 2 files changed, 23 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt

diff --git a/Documentation/devicetree/bindings/media/fsl-vdoa.txt 
b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
new file mode 100644
index 000..5e45f9b
--- /dev/null
+++ b/Documentation/devicetree/bindings/media/fsl-vdoa.txt
@@ -0,0 +1,21 @@
+Freescale Video Data Order Adapter
+==
+
+The Video Data Order Adapter (VDOA) is present on the i.MX6q. Its sole purpose
+it to to reorder video data from the macroblock tiled order produced by the
+CODA 960 VPU to the conventional raster-scan order for scanout.
+
+Required properties:
+- compatible: must be "fsl,imx6q-vdoa"
+- reg: the register base and size for the device registers
+- interrupts: the VDOA interrupt
+- clocks: the vdoa clock
+
+Example:
+
+vdoa@021e4000 {
+compatible = "fsl,imx6q-vdoa";
+reg = <0x021e4000 0x4000>;
+interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+clocks = < IMX6QDL_CLK_VDOA>;
+};
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..69e3668 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1153,8 +1153,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.10.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 v2 0/7] Add support for Video Data Order Adapter

[Michael Tretter]

Hello,

This is v2 of a patch series that adds support for the Video Data Order
Adapter (VDOA) that can be found on Freescale i.MX6. It converts the
macroblock tiled format produced by the CODA 960 video decoder to a
raster-ordered format for scanout.

Changes since v1:

- Dropped patch 8/9 of v1
- Patch 1/7: Add devicetree binding documentation for fsl-vdoa
- Patch 6/7: I merged patch 5/9 and patch 8/9 of v1 into a single patch
- Patch 6/7: Use dt compatible instead of a phandle to find VDOA device
- Patch 6/7: Always check VDOA availability even if disabled via module
  parameter and do not print a message if VDOA cannot be found
- Patch 6/7: Do not change the CODA context in coda_try_fmt()
- Patch 6/7: Allocate an additional internal frame if the VDOA is in use

Michael


Michael Tretter (3):
  [media] coda: fix frame index to returned error
  [media] coda: use VDOA for un-tiling custom macroblock format
  [media] coda: support YUYV output if VDOA is used

Philipp Zabel (4):
  ARM: dts: imx6qdl: Add VDOA compatible and clocks properties
  [media] coda: add i.MX6 VDOA driver
  [media] coda: correctly set capture compose rectangle
  [media] coda: add debug output about tiling

 .../devicetree/bindings/media/fsl-vdoa.txt |  21 ++
 arch/arm/boot/dts/imx6qdl.dtsi |   2 +
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/coda-bit.c |  93 --
 drivers/media/platform/coda/coda-common.c  | 175 ++-
 drivers/media/platform/coda/coda.h |   3 +
 drivers/media/platform/coda/imx-vdoa.c | 335 +
 drivers/media/platform/coda/imx-vdoa.h |  58 
 9 files changed, 649 insertions(+), 42 deletions(-)
 create mode 100644 Documentation/devicetree/bindings/media/fsl-vdoa.txt
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

-- 
2.10.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 2/9] [media] coda: add i.MX6 VDOA driver

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

The i.MX6 Video Data Order Adapter's (VDOA) sole purpose is to convert
from a custom macroblock tiled format produced by the CODA960 decoder
into linear formats that can be used for scanout.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/Kconfig |   3 +
 drivers/media/platform/coda/Makefile   |   1 +
 drivers/media/platform/coda/imx-vdoa.c | 331 +
 drivers/media/platform/coda/imx-vdoa.h |  58 ++
 4 files changed, 393 insertions(+)
 create mode 100644 drivers/media/platform/coda/imx-vdoa.c
 create mode 100644 drivers/media/platform/coda/imx-vdoa.h

diff --git a/drivers/media/platform/Kconfig b/drivers/media/platform/Kconfig
index ce4a96f..41e007f 100644
--- a/drivers/media/platform/Kconfig
+++ b/drivers/media/platform/Kconfig
@@ -162,6 +162,9 @@ config VIDEO_CODA
   Coda is a range of video codec IPs that supports
   H.264, MPEG-4, and other video formats.
 
+config VIDEO_IMX_VDOA
+   def_tristate VIDEO_CODA if SOC_IMX6Q || COMPILE_TEST
+
 config VIDEO_MEDIATEK_VPU
tristate "Mediatek Video Processor Unit"
depends on VIDEO_DEV && VIDEO_V4L2 && HAS_DMA
diff --git a/drivers/media/platform/coda/Makefile 
b/drivers/media/platform/coda/Makefile
index 9342ac5..8582843 100644
--- a/drivers/media/platform/coda/Makefile
+++ b/drivers/media/platform/coda/Makefile
@@ -3,3 +3,4 @@ ccflags-y += -I$(src)
 coda-objs := coda-common.o coda-bit.o coda-gdi.o coda-h264.o coda-jpeg.o
 
 obj-$(CONFIG_VIDEO_CODA) += coda.o
+obj-$(CONFIG_VIDEO_IMX_VDOA) += imx-vdoa.o
diff --git a/drivers/media/platform/coda/imx-vdoa.c 
b/drivers/media/platform/coda/imx-vdoa.c
new file mode 100644
index 000..9b4ae07
--- /dev/null
+++ b/drivers/media/platform/coda/imx-vdoa.c
@@ -0,0 +1,331 @@
+/*
+ * i.MX6 Video Data Order Adapter (VDOA)
+ *
+ * Copyright (C) 2014 Philipp Zabel
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation; either version 2
+ * of the License, or (at your option) any later version.
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "imx-vdoa.h"
+
+#define VDOA_NAME "imx-vdoa"
+
+#define VDOAC  0x00
+#define VDOASRR0x04
+#define VDOAIE 0x08
+#define VDOAIST0x0c
+#define VDOAFP 0x10
+#define VDOAIEBA00 0x14
+#define VDOAIEBA01 0x18
+#define VDOAIEBA02 0x1c
+#define VDOAIEBA10 0x20
+#define VDOAIEBA11 0x24
+#define VDOAIEBA12 0x28
+#define VDOASL 0x2c
+#define VDOAIUBO   0x30
+#define VDOAVEBA0  0x34
+#define VDOAVEBA1  0x38
+#define VDOAVEBA2  0x3c
+#define VDOAVUBO   0x40
+#define VDOASR 0x44
+
+#define VDOAC_ISEL BIT(6)
+#define VDOAC_PFS  BIT(5)
+#define VDOAC_SO   BIT(4)
+#define VDOAC_SYNC BIT(3)
+#define VDOAC_NF   BIT(2)
+#define VDOAC_BNDM_MASK0x3
+#define VDOAC_BAND_HEIGHT_80x0
+#define VDOAC_BAND_HEIGHT_16   0x1
+#define VDOAC_BAND_HEIGHT_32   0x2
+
+#define VDOASRR_START  BIT(1)
+#define VDOASRR_SWRST  BIT(0)
+
+#define VDOAIE_EITERR  BIT(1)
+#define VDOAIE_EIEOT   BIT(0)
+
+#define VDOAIST_TERR   BIT(1)
+#define VDOAIST_EOTBIT(0)
+
+#define VDOAFP_FH_MASK (0x1fff << 16)
+#define VDOAFP_FW_MASK (0x3fff)
+
+#define VDOASL_VSLY_MASK   (0x3fff << 16)
+#define VDOASL_ISLY_MASK   (0x7fff)
+
+#define VDOASR_ERRWBIT(4)
+#define VDOASR_EOB BIT(3)
+#define VDOASR_CURRENT_FRAME   (0x3 << 1)
+#define VDOASR_CURRENT_BUFFER  BIT(1)
+
+enum {
+   V4L2_M2M_SRC = 0,
+   V4L2_M2M_DST = 1,
+};
+
+struct vdoa_data {
+   struct vdoa_ctx *curr_ctx;
+   struct device   *dev;
+   struct clk  *vdoa_clk;
+   void __iomem*regs;
+   int irq;
+};
+
+struct vdoa_q_data {
+   unsigned intwidth;
+   unsigned intheight;
+   unsigned intbytesperline;
+   unsigned intsizeimage;
+   u32 pixelformat;
+};
+
+struct vdoa_ctx {
+   struct vdoa_data*vdoa;
+   struct completion   completion;
+   struct vdoa_q_data  q_data[2];
+};
+
+static irqreturn_t vdoa_irq_handler(int irq, void *data)
+{
+   struct vdoa_data *vdoa = data;
+   struct vdoa_ctx *curr_ctx;
+  

[PATCH 1/9] ARM: dts: imx6qdl: Add VDOA compatible and clocks properties

[Michael Tretter]

From: Philipp Zabel <philipp.za...@gmail.com>

This adds a compatible property and the correct clock for the
i.MX6Q Video Data Order Adapter.

Signed-off-by: Philipp Zabel <philipp.za...@gmail.com>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 arch/arm/boot/dts/imx6qdl.dtsi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index b13b0b2..69e3668 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -1153,8 +1153,10 @@
};
 
vdoa@021e4000 {
+   compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
+   clocks = < IMX6QDL_CLK_VDOA>;
};
 
uart2: serial@021e8000 {
-- 
2.10.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 4/9] [media] coda: correctly set capture compose rectangle

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

Correctly store the rectangle of valid video data in the destination
q_data before rounding up to macroblock size. This fixes the output
of VIDIOC_G_SELECTION for the capture side compose rectangle.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 37 ---
 1 file changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index c39718a..e0184194 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -566,7 +566,8 @@ static int coda_try_fmt_vid_out(struct file *file, void 
*priv,
return coda_try_fmt(ctx, codec, f);
 }
 
-static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f)
+static int coda_s_fmt(struct coda_ctx *ctx, struct v4l2_format *f,
+ struct v4l2_rect *r)
 {
struct coda_q_data *q_data;
struct vb2_queue *vq;
@@ -589,10 +590,14 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f)
q_data->height = f->fmt.pix.height;
q_data->bytesperline = f->fmt.pix.bytesperline;
q_data->sizeimage = f->fmt.pix.sizeimage;
-   q_data->rect.left = 0;
-   q_data->rect.top = 0;
-   q_data->rect.width = f->fmt.pix.width;
-   q_data->rect.height = f->fmt.pix.height;
+   if (r) {
+   q_data->rect = *r;
+   } else {
+   q_data->rect.left = 0;
+   q_data->rect.top = 0;
+   q_data->rect.width = f->fmt.pix.width;
+   q_data->rect.height = f->fmt.pix.height;
+   }
 
switch (f->fmt.pix.pixelformat) {
case V4L2_PIX_FMT_NV12:
@@ -621,27 +626,37 @@ static int coda_s_fmt_vid_cap(struct file *file, void 
*priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_cap(file, priv, f);
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, f);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, f, );
 }
 
 static int coda_s_fmt_vid_out(struct file *file, void *priv,
  struct v4l2_format *f)
 {
struct coda_ctx *ctx = fh_to_ctx(priv);
+   struct coda_q_data *q_data_src;
struct v4l2_format f_cap;
+   struct v4l2_rect r;
int ret;
 
ret = coda_try_fmt_vid_out(file, priv, f);
if (ret)
return ret;
 
-   ret = coda_s_fmt(ctx, f);
+   ret = coda_s_fmt(ctx, f, NULL);
if (ret)
return ret;
 
@@ -657,7 +672,13 @@ static int coda_s_fmt_vid_out(struct file *file, void 
*priv,
if (ret)
return ret;
 
-   return coda_s_fmt(ctx, _cap);
+   q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+   r.left = 0;
+   r.top = 0;
+   r.width = q_data_src->width;
+   r.height = q_data_src->height;
+
+   return coda_s_fmt(ctx, _cap, );
 }
 
 static int coda_reqbufs(struct file *file, void *priv,
-- 
2.10.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 3/9] ARM: dts: imx6qdl: Add VDOA phandle to CODA node

[Michael Tretter]

The CODA driver should use the VDOA to transform the tiled format to
raster-ordered format, if the platform has a VDOA. Link the CODA and
VDOA nodes to tell the CODA driver that it can use the VDOA.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 Documentation/devicetree/bindings/media/coda.txt | 2 ++
 arch/arm/boot/dts/imx6qdl.dtsi   | 3 ++-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/media/coda.txt 
b/Documentation/devicetree/bindings/media/coda.txt
index 2865d04..7900788 100644
--- a/Documentation/devicetree/bindings/media/coda.txt
+++ b/Documentation/devicetree/bindings/media/coda.txt
@@ -17,6 +17,7 @@ Required properties:
   determined by the clock-names property.
 - clock-names : Should be "ahb", "per"
 - iram : phandle pointing to the SRAM device node
+- vdoa : phandle pointing to the VDOA device node
 
 Example:
 
@@ -27,4 +28,5 @@ vpu: vpu@63ff4000 {
clocks = < 63>, < 63>;
clock-names = "ahb", "per";
iram = <>;
+   vdoa = <>;
 };
diff --git a/arch/arm/boot/dts/imx6qdl.dtsi b/arch/arm/boot/dts/imx6qdl.dtsi
index 69e3668..7bf3429 100644
--- a/arch/arm/boot/dts/imx6qdl.dtsi
+++ b/arch/arm/boot/dts/imx6qdl.dtsi
@@ -427,6 +427,7 @@
power-domains = < 1>;
resets = < 1>;
iram = <>;
+   vdoa = <>;
};
 
aipstz@0207c000 { /* AIPSTZ1 */
@@ -1152,7 +1153,7 @@
};
};
 
-   vdoa@021e4000 {
+   vdoa: vdoa@021e4000 {
compatible = "fsl,imx6q-vdoa";
reg = <0x021e4000 0x4000>;
interrupts = <0 18 IRQ_TYPE_LEVEL_HIGH>;
-- 
2.10.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 6/9] [media] coda: add debug output about tiling

[Michael Tretter]

From: Philipp Zabel <p.za...@pengutronix.de>

In order to make the VDOA work correctly, the CODA must produce frames
in tiled format. Print this information in the debug output.

Also print the color format in fourcc instead of the numeric value.

Signed-off-by: Philipp Zabel <p.za...@pengutronix.de>
Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 1adb6f3..3a21000 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -649,8 +649,10 @@ static int coda_s_fmt(struct coda_ctx *ctx, struct 
v4l2_format *f,
}
 
v4l2_dbg(1, coda_debug, >dev->v4l2_dev,
-   "Setting format for type %d, wxh: %dx%d, fmt: %d\n",
-   f->type, q_data->width, q_data->height, q_data->fourcc);
+   "Setting format for type %d, wxh: %dx%d, fmt: %4.4s %c\n",
+   f->type, q_data->width, q_data->height,
+   (char *)_data->fourcc,
+   (ctx->tiled_map_type == GDI_LINEAR_FRAME_MAP) ? 'L' : 'T');
 
return 0;
 }
-- 
2.10.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 8/9] [media] coda: use VDOA for un-tiling custom macroblock format

[Michael Tretter]

If the CODA driver is configured to produce NV12 output and the VDOA is
available, the VDOA can be used to transform the custom macroblock tiled
format to a raster-ordered format for scanout.

In this case, set the output format of the CODA to the custom macroblock
tiled format, disable the rotator, and use the VDOA to write to the v4l2
buffer. The VDOA is synchronized with the CODA to always un-tile the
frame that the CODA finished in the previous run.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c| 77 +--
 drivers/media/platform/coda/coda-common.c | 55 --
 drivers/media/platform/coda/coda.h|  2 +
 3 files changed, 104 insertions(+), 30 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 309eb4e..3e2f830 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -30,6 +30,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 #define CREATE_TRACE_POINTS
 #include "trace.h"
 
@@ -1517,6 +1518,10 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
u32 val;
int ret;
 
+   v4l2_dbg(1, coda_debug, >v4l2_dev,
+"Video Data Order Adapter: %s\n",
+ctx->use_vdoa ? "Enabled" : "Disabled");
+
/* Start decoding */
q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
@@ -1535,7 +1540,8 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
if (dst_fourcc == V4L2_PIX_FMT_NV12)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
-   ctx->frame_mem_ctrl |= (0x3 << 9) | CODA9_FRAME_TILED2LINEAR;
+   ctx->frame_mem_ctrl |= (0x3 << 9) |
+   ((ctx->use_vdoa) ? 0 : CODA9_FRAME_TILED2LINEAR);
coda_write(dev, ctx->frame_mem_ctrl, CODA_REG_BIT_FRAME_MEM_CTRL);
 
ctx->display_idx = -1;
@@ -1724,6 +1730,7 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
struct coda_q_data *q_data_dst;
struct coda_buffer_meta *meta;
unsigned long flags;
+   u32 rot_mode = 0;
u32 reg_addr, reg_stride;
 
dst_buf = v4l2_m2m_next_dst_buf(ctx->fh.m2m_ctx);
@@ -1759,27 +1766,40 @@ static int coda_prepare_decode(struct coda_ctx *ctx)
if (dev->devtype->product == CODA_960)
coda_set_gdi_regs(ctx);
 
-   if (dev->devtype->product == CODA_960) {
-   /*
-* The CODA960 seems to have an internal list of buffers with
-* 64 entries that includes the registered frame buffers as
-* well as the rotator buffer output.
-* ROT_INDEX needs to be < 0x40, but > ctx->num_internal_frames.
-*/
-   coda_write(dev, CODA_MAX_FRAMEBUFFERS + dst_buf->vb2_buf.index,
-   CODA9_CMD_DEC_PIC_ROT_INDEX);
-
-   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   if (ctx->use_vdoa &&
+   ctx->display_idx >= 0 &&
+   ctx->display_idx < ctx->num_internal_frames) {
+   vdoa_device_run(ctx->vdoa,
+   
vb2_dma_contig_plane_dma_addr(_buf->vb2_buf, 0),
+   ctx->internal_frames[ctx->display_idx].paddr);
} else {
-   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
-   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   if (dev->devtype->product == CODA_960) {
+   /*
+* The CODA960 seems to have an internal list of
+* buffers with 64 entries that includes the
+* registered frame buffers as well as the rotator
+* buffer output.
+*
+* ROT_INDEX needs to be < 0x40, but >
+* ctx->num_internal_frames.
+*/
+   coda_write(dev,
+  CODA_MAX_FRAMEBUFFERS + 
dst_buf->vb2_buf.index,
+  CODA9_CMD_DEC_PIC_ROT_INDEX);
+
+   reg_addr = CODA9_CMD_DEC_PIC_ROT_ADDR_Y;
+   reg_stride = CODA9_CMD_DEC_PIC_ROT_STRIDE;
+   } else {
+   reg_addr = CODA_CMD_DEC_PIC_ROT_ADDR_Y;
+   reg_stride = CODA_CMD_DEC_PIC_ROT_STRIDE;
+   }
+   coda_write_base(ctx, q_data_dst, dst_buf, reg_addr);
+   coda_write(dev, q_data_ds

[PATCH 5/9] [media] coda: get VDOA device using dt phandle

[Michael Tretter]

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-common.c | 43 +++
 drivers/media/platform/coda/coda.h|  1 +
 2 files changed, 44 insertions(+)

diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index e0184194..1adb6f3 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -41,6 +41,7 @@
 #include 
 
 #include "coda.h"
+#include "imx-vdoa.h"
 
 #define CODA_NAME  "coda"
 
@@ -66,6 +67,10 @@ static int disable_tiling;
 module_param(disable_tiling, int, 0644);
 MODULE_PARM_DESC(disable_tiling, "Disable tiled frame buffers");
 
+static int disable_vdoa;
+module_param(disable_vdoa, int, 0644);
+MODULE_PARM_DESC(disable_vdoa, "Disable Video Data Order Adapter tiled to 
raster-scan conversion");
+
 void coda_write(struct coda_dev *dev, u32 data, u32 reg)
 {
v4l2_dbg(2, coda_debug, >v4l2_dev,
@@ -325,6 +330,34 @@ const char *coda_product_name(int product)
}
 }
 
+static struct vdoa_data *coda_get_vdoa_data(struct device_node *np,
+   const char *name)
+{
+   struct device_node *vdoa_node;
+   struct platform_device *vdoa_pdev;
+   struct vdoa_data *vdoa_data;
+
+   vdoa_node = of_parse_phandle(np, name, 0);
+   if (!vdoa_node)
+   return NULL;
+
+   vdoa_pdev = of_find_device_by_node(vdoa_node);
+   if (!vdoa_pdev) {
+   vdoa_data = NULL;
+   goto out;
+   }
+
+   vdoa_data = platform_get_drvdata(vdoa_pdev);
+   if (!vdoa_data)
+   vdoa_data = ERR_PTR(-EPROBE_DEFER);
+
+out:
+   if (vdoa_node)
+   of_node_put(vdoa_node);
+
+   return vdoa_data;
+}
+
 /*
  * V4L2 ioctl() operations.
  */
@@ -2256,6 +2289,16 @@ static int coda_probe(struct platform_device *pdev)
}
dev->iram_pool = pool;
 
+   /* Get VDOA from device tree if available */
+   if (!disable_tiling && !disable_vdoa) {
+   dev->vdoa = coda_get_vdoa_data(np, "vdoa");
+   if (PTR_ERR(dev->vdoa) == -EPROBE_DEFER)
+   return -EPROBE_DEFER;
+   if (!dev->vdoa)
+   dev_info(>dev,
+"vdoa not available; not using tiled 
intermediate format");
+   }
+
ret = v4l2_device_register(>dev, >v4l2_dev);
if (ret)
return ret;
diff --git a/drivers/media/platform/coda/coda.h 
b/drivers/media/platform/coda/coda.h
index 53f9666..ae202dc 100644
--- a/drivers/media/platform/coda/coda.h
+++ b/drivers/media/platform/coda/coda.h
@@ -75,6 +75,7 @@ struct coda_dev {
struct platform_device  *plat_dev;
const struct coda_devtype *devtype;
int firmware;
+   struct vdoa_data*vdoa;
 
void __iomem*regs_base;
struct clk  *clk_per;
-- 
2.10.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 7/9] [media] coda: fix frame index to returned error

[Michael Tretter]

display_idx refers to the frame that will be returned in the next round.
The currently processed frame is ctx->display_idx and errors should be
reported for this frame.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index b662504..309eb4e 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -2057,7 +2057,7 @@ static void coda_finish_decode(struct coda_ctx *ctx)
}
vb2_set_plane_payload(_buf->vb2_buf, 0, payload);
 
-   coda_m2m_buf_done(ctx, dst_buf, ctx->frame_errors[display_idx] ?
+   coda_m2m_buf_done(ctx, dst_buf, 
ctx->frame_errors[ctx->display_idx] ?
  VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
 
v4l2_dbg(1, coda_debug, >v4l2_dev,
-- 
2.10.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 9/9] [media] coda: support YUYV output if VDOA is used

[Michael Tretter]

The VDOA is able to transform the NV12 custom macroblock tiled format of
the CODA to YUYV format. If and only if the VDOA is available, the
driver can also provide YUYV support.

While the driver is configured to produce YUYV output, the CODA must be
configured to produce NV12 macroblock tiled frames and the VDOA must
transform the intermediate result into the final YUYV output.

Signed-off-by: Michael Tretter <m.tret...@pengutronix.de>
---
 drivers/media/platform/coda/coda-bit.c|  7 +--
 drivers/media/platform/coda/coda-common.c | 30 ++
 2 files changed, 35 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/coda/coda-bit.c 
b/drivers/media/platform/coda/coda-bit.c
index 3e2f830..b94ba62 100644
--- a/drivers/media/platform/coda/coda-bit.c
+++ b/drivers/media/platform/coda/coda-bit.c
@@ -759,7 +759,7 @@ static void coda9_set_frame_cache(struct coda_ctx *ctx, u32 
fourcc)
cache_config = 1 << CODA9_CACHE_PAGEMERGE_OFFSET;
}
coda_write(ctx->dev, cache_size, CODA9_CMD_SET_FRAME_CACHE_SIZE);
-   if (fourcc == V4L2_PIX_FMT_NV12) {
+   if (fourcc == V4L2_PIX_FMT_NV12 || fourcc == V4L2_PIX_FMT_YUYV) {
cache_config |= 32 << CODA9_CACHE_LUMA_BUFFER_SIZE_OFFSET |
16 << CODA9_CACHE_CR_BUFFER_SIZE_OFFSET |
0 << CODA9_CACHE_CB_BUFFER_SIZE_OFFSET;
@@ -1537,7 +1537,7 @@ static int __coda_start_decoding(struct coda_ctx *ctx)
 
ctx->frame_mem_ctrl &= ~(CODA_FRAME_CHROMA_INTERLEAVE | (0x3 << 9) |
 CODA9_FRAME_TILED2LINEAR);
-   if (dst_fourcc == V4L2_PIX_FMT_NV12)
+   if (dst_fourcc == V4L2_PIX_FMT_NV12 || dst_fourcc == V4L2_PIX_FMT_YUYV)
ctx->frame_mem_ctrl |= CODA_FRAME_CHROMA_INTERLEAVE;
if (ctx->tiled_map_type == GDI_TILED_FRAME_MB_RASTER_MAP)
ctx->frame_mem_ctrl |= (0x3 << 9) |
@@ -2070,6 +2070,9 @@ static void coda_finish_decode(struct coda_ctx *ctx)
trace_coda_dec_rot_done(ctx, dst_buf, meta);
 
switch (q_data_dst->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   payload = width * height * 2;
+   break;
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_NV12:
diff --git a/drivers/media/platform/coda/coda-common.c 
b/drivers/media/platform/coda/coda-common.c
index 8b23ea4..1a809b2 100644
--- a/drivers/media/platform/coda/coda-common.c
+++ b/drivers/media/platform/coda/coda-common.c
@@ -95,6 +95,8 @@ void coda_write_base(struct coda_ctx *ctx, struct coda_q_data 
*q_data,
u32 base_cb, base_cr;
 
switch (q_data->fourcc) {
+   case V4L2_PIX_FMT_YUYV:
+   /* Fallthrough: IN -H264-> CODA -NV12 MB-> VDOA -YUYV-> OUT */
case V4L2_PIX_FMT_NV12:
case V4L2_PIX_FMT_YUV420:
default:
@@ -201,6 +203,11 @@ static const struct coda_video_device coda_bit_decoder = {
V4L2_PIX_FMT_NV12,
V4L2_PIX_FMT_YUV420,
V4L2_PIX_FMT_YVU420,
+   /*
+* If V4L2_PIX_FMT_YUYV should be default,
+* set_default_params() must be adjusted.
+*/
+   V4L2_PIX_FMT_YUYV,
},
 };
 
@@ -246,6 +253,7 @@ static u32 coda_format_normalize_yuv(u32 fourcc)
case V4L2_PIX_FMT_YUV420:
case V4L2_PIX_FMT_YVU420:
case V4L2_PIX_FMT_YUV422P:
+   case V4L2_PIX_FMT_YUYV:
return V4L2_PIX_FMT_YUV420;
default:
return fourcc;
@@ -437,6 +445,11 @@ static int coda_try_pixelformat(struct coda_ctx *ctx, 
struct v4l2_format *f)
return -EINVAL;
 
for (i = 0; i < CODA_MAX_FORMATS; i++) {
+   /* Skip YUYV if the vdoa is not available */
+   if (!ctx->vdoa && f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE &&
+   formats[i] == V4L2_PIX_FMT_YUYV)
+   continue;
+
if (formats[i] == f->fmt.pix.pixelformat) {
f->fmt.pix.pixelformat = formats[i];
return 0;
@@ -520,6 +533,11 @@ static int coda_try_fmt(struct coda_ctx *ctx, const struct 
coda_codec *codec,
f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
f->fmt.pix.height * 3 / 2;
break;
+   case V4L2_PIX_FMT_YUYV:
+   f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16) * 2;
+   f->fmt.pix.sizeimage = f->fmt.pix.bytesperline *
+   f->fmt.pix.height;
+   break;
case V4L2_PIX_FMT_YUV422P:
f->fmt.pix.bytesperline = round_up(f->fmt.pix.width, 16);
   

Re: [PATCH 1/3] [media] dvb-usb: move data_mutex to struct dvb_usb_device

[Michael Ira Krufky]

On Sat, Nov 12, 2016 at 9:46 AM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> From: Mauro Carvalho Chehab <mche...@s-opensource.com>
>
> The data_mutex is initialized too late, as it is needed for
> each device driver's power control, causing an OOPS:
>
> dvb-usb: found a 'TerraTec/qanu USB2.0 Highspeed DVB-T Receiver' in 
> warm state.
> BUG: unable to handle kernel NULL pointer dereference at   
> (null)
> IP: [] __mutex_lock_slowpath+0x6f/0x100 PGD 0
> Oops: 0002 [#1] SMP
> Modules linked in: dvb_usb_cinergyT2(+) dvb_usb
> CPU: 0 PID: 2029 Comm: modprobe Not tainted 4.9.0-rc4-dvbmod #24
> Hardware name: FUJITSU LIFEBOOK A544/FJNBB35 , BIOS Version 1.17 
> 05/09/2014
> task: 88020e943840 task.stack: 8801f36ec000
> RIP: 0010:[]  [] 
> __mutex_lock_slowpath+0x6f/0x100
> RSP: 0018:8801f36efb10  EFLAGS: 00010282
> RAX:  RBX: 88021509bdc8 RCX: c100
> RDX: 0001 RSI:  RDI: 88021509bdcc
> RBP: 8801f36efb58 R08: 88021f216320 R09: 0010
> R10: 88021f216320 R11: 0023fee6c5a1 R12: 88020e943840
> R13: 88021509bdcc R14:  R15: 88021509bdd0
> FS:  7f21adb86740() GS:88021f20() 
> knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2:  CR3: 000215bce000 CR4: 001406f0
> Stack:
>  88021509bdd0   c0137c80
>  88021509bdc8 8801f5944000 0001 c0136b00
>  880213e52000 88021509bdc8 84661856 88021509bd80
> Call Trace:
>  [] ? mutex_lock+0x16/0x25
>  [] ? cinergyt2_power_ctrl+0x1f/0x60 
> [dvb_usb_cinergyT2]
>  [] ? dvb_usb_device_init+0x21e/0x5d0 [dvb_usb]
>  [] ? cinergyt2_usb_probe+0x21/0x50 
> [dvb_usb_cinergyT2]
>  [] ? usb_probe_interface+0xf3/0x2a0
>  [] ? driver_probe_device+0x208/0x2b0
>  [] ? __driver_attach+0x87/0x90
>  [] ? driver_probe_device+0x2b0/0x2b0
>  [] ? bus_for_each_dev+0x52/0x80
>  [] ? bus_add_driver+0x1a3/0x220
>  [] ? driver_register+0x56/0xd0
>  [] ? usb_register_driver+0x77/0x130
>  [] ? 0xc013a000
>  [] ? do_one_initcall+0x46/0x180
>  [] ? free_vmap_area_noflush+0x38/0x70
>  [] ? kmem_cache_alloc+0x84/0xc0
>  [] ? do_init_module+0x50/0x1be
>  [] ? load_module+0x1d8b/0x2100
>  [] ? find_symbol_in_section+0xa0/0xa0
>  [] ? SyS_finit_module+0x89/0x90
>  [] ? entry_SYSCALL_64_fastpath+0x13/0x94
> Code: e8 a7 1d 00 00 8b 03 83 f8 01 0f 84 97 00 00 00 48 8b 43 10 4c 
> 8d 7b 08 48 89 63 10 4c 89 3c 24 41 be ff ff ff ff 48 89 44 24 08 <48> 89 20 
> 4c 89 64 24 10 eb 1a 49 c7 44 24 08 02 00 00 00 c6 43 RIP  
> [] __mutex_lock_slowpath+0x6f/0x100 RSP 
> CR2: 
>
> So, move it to the struct dvb_usb_device and initialize it
> before calling the driver's callbacks.
>
> Reported-by: Jörg Otte <jrg.o...@gmail.com>
> Tested-by: Jörg Otte <jrg.o...@gmail.com>
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

> ---
>  drivers/media/usb/dvb-usb/af9005.c | 33 
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 33 
>  drivers/media/usb/dvb-usb/cxusb.c  | 39 -
>  drivers/media/usb/dvb-usb/cxusb.h  |  1 -
>  drivers/media/usb/dvb-usb/dtt200u.c| 40 
> +-
>  drivers/media/usb/dvb-usb/dvb-usb-init.c   |  1 +
>  drivers/media/usb/dvb-usb/dvb-usb.h|  9 +--
>  7 files changed, 61 insertions(+), 95 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb/af9005.c 
> b/drivers/media/usb/dvb-usb/af9005.c
> index b257780fb380..7853261906b1 100644
> --- a/drivers/media/usb/dvb-usb/af9005.c
> +++ b/drivers/media/usb/dvb-usb/af9005.c
> @@ -53,7 +53,6 @@ struct af9005_device_state {
> u8 sequence;
> int led_state;
> unsigned char data[256];
> -   struct mutex data_mutex;
>  };
>
>  static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
> @@ -72,7 +71,7 @@ static int af9005_generic_read_write(struct dvb_usb_device 
> *d, u16 reg,
> return -EINVAL;
> }
>
> -   mutex_lock(>data_mutex);
> +   mutex_lock(>data_mutex);
&g

Lower exposure times than 100 us?

[Michael Haardt]

Hello,

V4L2_CID_EXPOSURE_ABSOLUTE uses a 100 us resolution.  Quite a few
sensors offer lower exposures and more fine resolutions than that.
Can the resolution be switched to e.g. 1 us, similar to how the tuner
frequency may be specified in smaller steps if the driver implements
the V4L2_TUNER_CAP_* values?

Regards,

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

Still images and v4l2?

[Michael Haardt]

I am currently developing a new image v4l2 sensor driver to acquire
sequences of still images and wonder how to interface that to the
v4l2 API.

Currently, cameras are assumed to deliver an endless stream of images
after being triggered internally with VIDIOC_STREAMON.  If supported by
the driver, a certain frame rate is used.

For precise image capturing, I need two additional features:

Limiting the number of captured images: It is desirable not having to stop
streaming from user space for camera latency.  A typical application
are single shots at random times, and possibly with little time in
between the end of one image and start of a new one, so an image that
could not be stopped in time would be a problem.  A video camera would
only support the limit value "unlimited" as possible capturing limit.
Scientific cameras may offer more, or possibly only limited capturing.

Configuring the capture trigger: Right now sensors are implicitly
triggered internally from the driver.  Being able to configure external
triggers, which many sensors support, is needed to start capturing at
exactly the right time.  Again, video cameras may only offer "internal"
as trigger type.

Perhaps v4l2 already offers something that I overlooked.  If not, what
would be good ways to extend it?

Regards,

Michael
--
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] lgdt3306a: remove 20*50 msec unnecessary timeout

[Michael Ira Krufky]

On Mon, Jul 25, 2016 at 9:36 PM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> Em Mon, 25 Jul 2016 15:37:14 -0400
> Michael Ira Krufky <mkru...@linuxtv.org> escreveu:
>
>> On Mon, Jul 25, 2016 at 3:28 PM, Mauro Carvalho Chehab
>> <mche...@osg.samsung.com> wrote:
>> > Hi Michael,
>> >
>> > Em Mon, 25 Jul 2016 14:55:51 -0400
>> > Michael Ira Krufky <mkru...@linuxtv.org> escreveu:
>> >
>> >> On Mon, Jul 25, 2016 at 2:38 PM, Abylay Ospan <aos...@netup.ru> wrote:
>> >> > inside lgdt3306a_search we reading demod status 20 times with 50 msec 
>> >> > sleep after each read.
>> >> > This gives us more than 1 sec of delay. Removing this delay should not 
>> >> > affect demod functionality.
>> >> >
>> >> > Signed-off-by: Abylay Ospan <aos...@netup.ru>
>> >> > ---
>> >> >  drivers/media/dvb-frontends/lgdt3306a.c | 16 
>> >> >  1 file changed, 4 insertions(+), 12 deletions(-)
>> >> >
>> >> > diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> >> > b/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > index 179c26e..dad7ad3 100644
>> >> > --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> >> > @@ -1737,24 +1737,16 @@ static int lgdt3306a_get_tune_settings(struct 
>> >> > dvb_frontend *fe,
>> >> >  static int lgdt3306a_search(struct dvb_frontend *fe)
>> >> >  {
>> >> > enum fe_status status = 0;
>> >> > -   int i, ret;
>> >> > +   int ret;
>> >> >
>> >> > /* set frontend */
>> >> > ret = lgdt3306a_set_parameters(fe);
>> >> > if (ret)
>> >> > goto error;
>> >> >
>> >> > -   /* wait frontend lock */
>> >> > -   for (i = 20; i > 0; i--) {
>> >> > -   dbg_info(": loop=%d\n", i);
>> >> > -   msleep(50);
>> >> > -   ret = lgdt3306a_read_status(fe, );
>> >> > -   if (ret)
>> >> > -   goto error;
>> >> > -
>> >> > -   if (status & FE_HAS_LOCK)
>> >> > -   break;
>> >> > -   }
>> >
>> > Could you please explain why lgdt3306a needs the above ugly hack?
>> >
>> >
>> >> > +   ret = lgdt3306a_read_status(fe, );
>> >> > +   if (ret)
>> >> > +   goto error;
>> >
>> >
>> >> >
>> >> > /* check if we have a valid signal */
>> >> > if (status & FE_HAS_LOCK)
>> >>
>> >> Your patch removes a loop that was purposefully written here to handle
>> >> conditions that are not ideal.  Are you sure this change is best for
>> >> all users?
>> >>
>> >> I would disagree with merging this patch.
>> >>
>> >> Best regards,
>> >>
>> >> Michael Ira Krufky
>>
>> Mauro,
>>
>> I cannot speak for the LG DT3306a part itself, but based on my past
>> experience I can say the following:
>>
>> To my understanding, the hardware might not report a lock on the first
>> read_status request, so the driver author chose to include a loop to
>> retry a few times before giving up.
>
> A one second wait, trying 50 times is not a "few times". It is a lot!
>
>> In real life scenarios, there are marginal signals that may take a
>> longer time to lock onto, but once locked, the demod will deliver a
>> reliable stream.
>>
>> Most applications will only issue a single tune request when trying to
>> tune to a given program. The application does not retry the tune
>> request if the driver reports no lock.
>
> I don't know a single application that would give up after a
> single status request with FE_READ_STATUS. Not even simple
> applications like the legacy dvb-tools do that. If such application
> exits, it is already broken, as it would fail with most drivers,
> as almost no drivers wait for frontend locks.
>
> Also, the frontend thread assumes that the lock will take some
> polls to happen, and it keep polling the status for some time,
> using the status return to do frequency zig-zag, on t

Re: [PATCH] [media] lgdt3306a: remove 20*50 msec unnecessary timeout

[Michael Ira Krufky]

On Mon, Jul 25, 2016 at 3:28 PM, Mauro Carvalho Chehab
<mche...@osg.samsung.com> wrote:
> Hi Michael,
>
> Em Mon, 25 Jul 2016 14:55:51 -0400
> Michael Ira Krufky <mkru...@linuxtv.org> escreveu:
>
>> On Mon, Jul 25, 2016 at 2:38 PM, Abylay Ospan <aos...@netup.ru> wrote:
>> > inside lgdt3306a_search we reading demod status 20 times with 50 msec 
>> > sleep after each read.
>> > This gives us more than 1 sec of delay. Removing this delay should not 
>> > affect demod functionality.
>> >
>> > Signed-off-by: Abylay Ospan <aos...@netup.ru>
>> > ---
>> >  drivers/media/dvb-frontends/lgdt3306a.c | 16 
>> >  1 file changed, 4 insertions(+), 12 deletions(-)
>> >
>> > diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> > b/drivers/media/dvb-frontends/lgdt3306a.c
>> > index 179c26e..dad7ad3 100644
>> > --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> > +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> > @@ -1737,24 +1737,16 @@ static int lgdt3306a_get_tune_settings(struct 
>> > dvb_frontend *fe,
>> >  static int lgdt3306a_search(struct dvb_frontend *fe)
>> >  {
>> > enum fe_status status = 0;
>> > -   int i, ret;
>> > +   int ret;
>> >
>> > /* set frontend */
>> > ret = lgdt3306a_set_parameters(fe);
>> > if (ret)
>> > goto error;
>> >
>> > -   /* wait frontend lock */
>> > -   for (i = 20; i > 0; i--) {
>> > -   dbg_info(": loop=%d\n", i);
>> > -   msleep(50);
>> > -   ret = lgdt3306a_read_status(fe, );
>> > -   if (ret)
>> > -   goto error;
>> > -
>> > -   if (status & FE_HAS_LOCK)
>> > -   break;
>> > -   }
>
> Could you please explain why lgdt3306a needs the above ugly hack?
>
>
>> > +   ret = lgdt3306a_read_status(fe, );
>> > +   if (ret)
>> > +   goto error;
>
>
>> >
>> > /* check if we have a valid signal */
>> > if (status & FE_HAS_LOCK)
>>
>> Your patch removes a loop that was purposefully written here to handle
>> conditions that are not ideal.  Are you sure this change is best for
>> all users?
>>
>> I would disagree with merging this patch.
>>
>> Best regards,
>>
>> Michael Ira Krufky

Mauro,

I cannot speak for the LG DT3306a part itself, but based on my past
experience I can say the following:

To my understanding, the hardware might not report a lock on the first
read_status request, so the driver author chose to include a loop to
retry a few times before giving up.

In real life scenarios, there are marginal signals that may take a
longer time to lock onto, but once locked, the demod will deliver a
reliable stream.

Most applications will only issue a single tune request when trying to
tune to a given program.  The application does not retry the tune
request if the driver reports no lock.

Applying this patch will have the potential to cause userspace to
appear broken.  Some users will not be able to receive some weaker
channels anymore, and they will have no way to diagnose the problem
from within their application.

-Mike
--
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] lgdt3306a: remove 20*50 msec unnecessary timeout

[Michael Ira Krufky]

On Mon, Jul 25, 2016 at 2:38 PM, Abylay Ospan <aos...@netup.ru> wrote:
> inside lgdt3306a_search we reading demod status 20 times with 50 msec sleep 
> after each read.
> This gives us more than 1 sec of delay. Removing this delay should not affect 
> demod functionality.
>
> Signed-off-by: Abylay Ospan <aos...@netup.ru>
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index 179c26e..dad7ad3 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -1737,24 +1737,16 @@ static int lgdt3306a_get_tune_settings(struct 
> dvb_frontend *fe,
>  static int lgdt3306a_search(struct dvb_frontend *fe)
>  {
> enum fe_status status = 0;
> -   int i, ret;
> +   int ret;
>
> /* set frontend */
> ret = lgdt3306a_set_parameters(fe);
> if (ret)
> goto error;
>
> -   /* wait frontend lock */
> -   for (i = 20; i > 0; i--) {
> -   dbg_info(": loop=%d\n", i);
> -   msleep(50);
> -   ret = lgdt3306a_read_status(fe, );
> -   if (ret)
> -   goto error;
> -
> -   if (status & FE_HAS_LOCK)
> -   break;
> -   }
> +   ret = lgdt3306a_read_status(fe, );
> +   if (ret)
> +   goto error;
>
> /* check if we have a valid signal */
> if (status & FE_HAS_LOCK)

Your patch removes a loop that was purposefully written here to handle
conditions that are not ideal.  Are you sure this change is best for
all users?

I would disagree with merging this patch.

Best regards,

Michael Ira Krufky
--
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] vb2: map dmabuf for planes on driver queue instead of vidioc_qbuf

[Michael Olbrich]

Hi,

On Fri, Jul 15, 2016 at 12:26:06PM -0400, Javier Martinez Canillas wrote:
> The buffer planes' dma-buf are currently mapped when buffers are queued
> from userspace but it's more appropriate to do the mapping when buffers
> are queued in the driver since that's when the actual DMA operation are
> going to happen.
> 
> Suggested-by: Nicolas Dufresne <nicolas.dufre...@collabora.com>
> Signed-off-by: Javier Martinez Canillas <jav...@osg.samsung.com>
> 
> ---
> 
> Hello,
> 
> A side effect of this change is that if the dmabuf map fails for some
> reasons (i.e: a driver using the DMA contig memory allocator but CMA
> not being enabled), the fail will no longer happen on VIDIOC_QBUF but
> later (i.e: in VIDIOC_STREAMON).
> 
> I don't know if that's an issue though but I think is worth mentioning.

And for mem2mem devices? Does this mean that the second VIDIOC_STREAMON
will fail? That would make it impossible detect if the buffers on the
capture or the output side are incorrect.

It's already quite difficult to handle these issues gracefully and without
loosing any data. This would make it even worse.

Regards,
Michael

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |
--
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: Linux Media Summit in April, 7 - San Diego - CA - USA

[Michael Ira Krufky]

On Sat, Mar 5, 2016 at 10:08 AM, Mauro Carvalho Chehab
 wrote:
> As discussed on our IRC #v4l channel at Freenode, we'll be running a 1-day
> Linux Media Summit in San Diego on Aug, 7, just after the Embedded
> Linux Conference.
>
> Feel free to submit relevant topics related to the Linux Kernel support
> for media, in order to help us to build the workshop's agenda and take
> other needs into account when working on it.
>
> As usual, we'll be using the media-works...@linuxtv.org ML for the
> specific discussions about that, so the ones interested on participate
> on such discussions and/or be present there are requested to subscribe
> it, and to submit themes of interest via the mailing lists.
>
> Please also send an e-mail if you're intending to join us there, to
> allow us to be sure that we'll have enough seats for the participants.
>
> Hope to see you there!
>
> Regards,
> Mauro

Just to clarify, this will be on APRIL 7th, not Aug 7, is that correct?
--
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] drivers/media/usb/dvb-usb-v2: constify mxl111sf_tuner_config structure

[Michael Ira Krufky]

On Sun, Jan 3, 2016 at 7:11 AM, Julia Lawall <julia.law...@lip6.fr> wrote:
> This mxl111sf_tuner_config structure is never modified, so declare it as
> const.
>
> There are some indentation changes to remain within 80 columns.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>

Thank you for this, Julia

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>


>
> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c |6 +++---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h |8 
>  drivers/media/usb/dvb-usb-v2/mxl111sf.c   |2 +-
>  3 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> index 444579b..7d16252 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.c
> @@ -36,7 +36,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info 
> (or-able)).");
>  struct mxl111sf_tuner_state {
> struct mxl111sf_state *mxl_state;
>
> -   struct mxl111sf_tuner_config *cfg;
> +   const struct mxl111sf_tuner_config *cfg;
>
> enum mxl_if_freq if_freq;
>
> @@ -489,8 +489,8 @@ static struct dvb_tuner_ops mxl111sf_tuner_tuner_ops = {
>  };
>
>  struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> -  struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_tuner_config *cfg)
> +   struct mxl111sf_state *mxl_state,
> +   const struct mxl111sf_tuner_config *cfg)
>  {
> struct mxl111sf_tuner_state *state = NULL;
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> index e6caab2..509b550 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-tuner.h
> @@ -63,13 +63,13 @@ struct mxl111sf_tuner_config {
>  #if IS_ENABLED(CONFIG_DVB_USB_MXL111SF)
>  extern
>  struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> -  struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_tuner_config *cfg);
> +   struct mxl111sf_state *mxl_state,
> +   const struct mxl111sf_tuner_config *cfg);
>  #else
>  static inline
>  struct dvb_frontend *mxl111sf_tuner_attach(struct dvb_frontend *fe,
> -  struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_tuner_config *cfg)
> +   struct mxl111sf_state *mxl_state,
> +   const struct mxl111sf_tuner_config *cfg)
>  {
> printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
> return NULL;
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index b669dec..b586e17 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -856,7 +856,7 @@ static int mxl111sf_ant_hunt(struct dvb_frontend *fe)
> return 0;
>  }
>
> -static struct mxl111sf_tuner_config mxl_tuner_config = {
> +static const struct mxl111sf_tuner_config mxl_tuner_config = {
> .if_freq = MXL_IF_6_0, /* applies to external IF output, only 
> */
> .invert_spectrum = 0,
> .read_reg= mxl111sf_read_reg,
>
> --
> 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] drivers/media/usb/dvb-usb-v2: constify mxl111sf_demod_config structure

[Michael Ira Krufky]

Thanks for this!

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>

On Fri, Nov 13, 2015 at 7:24 AM, Julia Lawall <julia.law...@lip6.fr> wrote:
> The mxl111sf_demod_config structure is never modified, so declare it
> as const.
>
> Done with the help of Coccinelle.
>
> Signed-off-by: Julia Lawall <julia.law...@lip6.fr>
>
> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c |4 ++--
>  drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h |4 ++--
>  drivers/media/usb/dvb-usb-v2/mxl111sf.c   |2 +-
>  3 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
> index ea37536..84f6de6 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.c
> @@ -35,7 +35,7 @@ MODULE_PARM_DESC(debug, "set debugging level (1=info 
> (or-able)).");
>  struct mxl111sf_demod_state {
> struct mxl111sf_state *mxl_state;
>
> -   struct mxl111sf_demod_config *cfg;
> +   const struct mxl111sf_demod_config *cfg;
>
> struct dvb_frontend fe;
>  };
> @@ -579,7 +579,7 @@ static struct dvb_frontend_ops mxl111sf_demod_ops = {
>  };
>
>  struct dvb_frontend *mxl111sf_demod_attach(struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_demod_config *cfg)
> +  const struct mxl111sf_demod_config *cfg)
>  {
> struct mxl111sf_demod_state *state = NULL;
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
> index 0bd83e5..7065aca 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf-demod.h
> @@ -35,11 +35,11 @@ struct mxl111sf_demod_config {
>  #if IS_ENABLED(CONFIG_DVB_USB_MXL111SF)
>  extern
>  struct dvb_frontend *mxl111sf_demod_attach(struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_demod_config *cfg);
> +  const struct mxl111sf_demod_config *cfg);
>  #else
>  static inline
>  struct dvb_frontend *mxl111sf_demod_attach(struct mxl111sf_state *mxl_state,
> -  struct mxl111sf_demod_config *cfg)
> +  const struct mxl111sf_demod_config *cfg)
>  {
> printk(KERN_WARNING "%s: driver disabled by Kconfig\n", __func__);
> return NULL;
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index bec12b0..c4a4a99 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -731,7 +731,7 @@ fail:
> return ret;
>  }
>
> -static struct mxl111sf_demod_config mxl_demod_config = {
> +static const struct mxl111sf_demod_config mxl_demod_config = {
> .read_reg= mxl111sf_read_reg,
> .write_reg   = mxl111sf_write_reg,
> .program_regs= mxl111sf_ctrl_program_regs,
>
> --
> 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: Brazilian television capture device

[Michael Stilmant]

Hi, David

I'm in the same process that you are. I'm also on remote (Europe) but
I have some laptop in Brazil where I can do some test using remote
shell. I don't talk Brazilian/Portuguese so it is also hard to find
Local Linux groups certainly discussing about it

I have also that reference.
http://www.isdb-t.com/usb-isdb-t-full-seg-digital-usb-tv-stick-use-for-pc-philippines-japan-chile-vcan1012/
  I don't know neither if this could be working.  Not yet purchased

My contact purchased
http://www.netserv19.com/ecommerce_site/produto_103630_1598_Visus-Tv-Radicale-Receptor-Tv-Digital-Fullhd-Alta-Definicao-FULL-SEG
I will need to test it coming days
but dvbsnoop -s feinfo allready return:

Device: /dev/dvb/adapter0/frontend0

Basic capabilities:
Name: "DiBcom 8000 ISDB-T"
Frontend-type:   OFDM (DVB-T)
Frequency (min): 45000.000 kHz
Frequency (max): 86.000 kHz
Frequency stepsiz:   62.500 kHz
Frequency tolerance: 0.000 kHz


Which is not a bad sign.

Please share you finding, it would be appreciated.

Regards,

Michael




On Tue, Oct 20, 2015 at 1:04 AM, David Liontooth <lionte...@cogweb.net> wrote:
>
> Does anyone know of a tv capture device for Brazil (ISDB-T) that is
> supported in Linux and available for sale?
>
> I'm having a hard time finding any of the devices listed under
> http://www.linuxtv.org/wiki/index.php/ISDB-T_USB_Devices or ISDB-T PCIe
> devices --
>
> * Pixelview SBTVD
> (http://www.kabum.com.br/produto/6784/receptor-de-tv-digital-pixelview-playtv-usb-2-0-sbtvd-full-seg-pv-d231urn-f)
> is out of stock
> * Geniatech/MyGica X8507 PCI-Express Hybrid Card
> (http://www.linuxtv.org/wiki/index.php/Geniatech/MyGica_X8507_PCI-Express_Hybrid_Card)
>
> I see the Aver3d Hybrid Volar Xpro (H869 --
> http://avertv.avermedia.com/avertv/Upload/ProductImages/DS_H869_EN_140415.pdf)
> at americanas.com
> (http://www.americanas.com.br/produto/9869979/placa-captura-de-tv-aver3d-hybrid-volar-xpro)
> -- is it supported?
>
> I'm advising friends remotely, so I can't just purchase it and try it out.
>
> Cheers,
> Dave
>
> --
> 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] mxl111sf: missing return values validation

[Michael Ira Krufky]

On Thu, Oct 15, 2015 at 4:22 PM, Insu Yun <wuni...@gmail.com> wrote:
> Return values of mxl111sf_enable_usb_output and mxl1x1sf_top_master_ctrl
> are not validated.
>
> Signed-off-by: Insu Yun <wuni...@gmail.com>



Eeek!  You're right!  ...and I'm the one who wrote the offending code.
My bad O:-)

Thank you for this patch.  Mauro, please apply it.

Reviewed-by: Michael Ira Krufky <mkru...@linuxtv.org>



> ---
>  drivers/media/usb/dvb-usb-v2/mxl111sf.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/media/usb/dvb-usb-v2/mxl111sf.c 
> b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> index bec12b0..b71b2e6 100644
> --- a/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> +++ b/drivers/media/usb/dvb-usb-v2/mxl111sf.c
> @@ -288,9 +288,9 @@ static int mxl111sf_adap_fe_init(struct dvb_frontend *fe)
> err = mxl1x1sf_set_device_mode(state, adap_state->device_mode);
>
> mxl_fail(err);
> -   mxl111sf_enable_usb_output(state);
> +   err = mxl111sf_enable_usb_output(state);
> mxl_fail(err);
> -   mxl1x1sf_top_master_ctrl(state, 1);
> +   err = mxl1x1sf_top_master_ctrl(state, 1);
> mxl_fail(err);
>
> if ((MXL111SF_GPIO_MOD_DVBT != adap_state->gpio_mode) &&
> --
> 1.9.1
>
--
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] DT support for omap4-iss

[Michael Allwright]

Hi Everyone,

I'm thinking of using systemtap to create watchpoints on all memory
regions of the ISS and associated PRCM registers to generate two log
files with all memory accesses at any given point of time, one for
3.17 and one for 4.1.4.

Does this sound like reasonable approach, or is this over the top /
inefficient in your experience?

All the best,

Michael Allwright

PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering

University of Paderborn
Office-number 02-10
Zukunftsmeile 1
33102 Paderborn
Germany
--
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] DT support for omap4-iss

[Michael Allwright]

On 11 August 2015 at 13:16, Tony Lindgren t...@atomide.com wrote:
 * Michael Allwright michael.allwri...@upb.de [150810 08:19]:
 +
 +/*
 +We need a better solution for this
 +*/
 +#include ../arch/arm/mach-omap2/omap-pm.h

 Please let's not do things like this, I end up having to deal with
 all these eventually :(

 +static void iss_set_constraints(struct iss_device *iss, bool enable)
 +{
 +if (!iss)
 +return;
 +
 +/* FIXME: Look for something more precise as a good throughtput limit */
 +omap_pm_set_min_bus_tput(iss-dev, OCP_INITIATOR_AGENT,
 + enable ? 80 : -1);
 +}
 +
 +static struct iss_platform_data iss_dummy_pdata = {
 +.set_constraints = iss_set_constraints,
 +};

 If this is one time setting, you could do it based on the
 compatible string using arch/arm/mach-omap2/pdata-quirks.c.

 If you need to toggle it, you could populate a function pointer
 in pdata-quirks.c. Those are easy to fix once there is some Linux
 generic API available :)

 Regards,

 Tony

Hi Tony,

Thanks for the suggestion, I'll move that function into
pdata-quirks.c. Please read on, I really need some help regarding the
following error, I lost 8-9 hours on this today.

 [  141.612609] omap4iss 5200.iss: CSI2: CSI2_96M_FCLK reset timeout!

This comes from the function: int omap4iss_csi2_reset(struct
iss_csi2_device *csi2) in iss_csi2.c. I have found that bit 29 in
REGISTER1 belonging to the CSI2A registers, isn't becoming high after
doing the reset on kernel 4.1.4. However it does come high in 3.17.
This bit is a flag indicating that the reset on the CSI2_96M_FCLK is
complete.

3.17
[   43.399658] omap4-iss 5200.iss: REGISTER1 = 0x
[   43.405456] omap4-iss 5200.iss: REGISTER1 = 0xe002e10e

4.1.4
[  210.331909] omap4iss 5200.iss: REGISTER1 = 0x
[  210.338470] omap4iss 5200.iss: REGISTER1 = 0xc002e10e
[  210.342609] omap4iss 5200.iss: CSI2: CSI2_96M_FCLK reset timeout!

Note: the transition from 0x to 0xc002e10e would seem to
indicate that the operation completed, just not successfully...

I have spent the day sampling at different points in the code,
checking the contents of all the registers belonging to the ISS and
CSI PHY to conclude that there are no differences between the two
instances of the driver running on 3.17 and 4.1.4. Using the internal
__clk_is_enabled from clk-provider.h I also checked that the muxes
responsible for providing the clocks to the module were enabled
before, during and after the reset. I have also confirmed the
identical issue also occurs on a different board.

I suspect someone has broken something in the hwmods, or PRCM data
structures. Although I have not yet been able to find any relevant
differences in the source files that I have searched through.

Any suggestions regarding where I should continue to look for this
issue are welcome. Unfortunately if I can't get some support on this
soon, I will have to abandon working on this patch.


Michael Allwright

PhD Student
Paderborn Institute for Advanced Studies in Computer Science and Engineering

University of Paderborn
Office-number 02-10
Zukunftsmeile 1
33102 Paderborn
Germany
--
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