Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver

[Andy Walls]

Hi Sean and Devin:

On Wed, 2017-10-11 at 20:25 -0400, Devin Heitmueller wrote:
> > There's an ir_lock mutex in the driver to prevent simultaneous
> > access to the Rx and Tx functions of the z8.  Accessing Rx and Tx
> > functions of the chip together can cause it to do the wrong thing
> > (sometimes hang?), IIRC.
> > 
> > I'll see if I can dig up my old disassembly of the z8's firmware to
> > see if that interlock is strictly necessary.

Following up on this:

1. The I2C bus command and response buffers inside the Z8 appear to be
independent and non-overlapping (ignore the garbage assembly
mnemonics):

; I2C data buffer addresses
01bf srp   #%00   ; 01 00 ; Buffer pointer I2C addr E0 (70w) IR Tx  - 160 bytes
01c1 add   r0,@r0 ; 03 00 ; Buffer pointer I2C addr E1 (70r) IR Tx  -   4 bytes
01c3 add   r1,@r5 ; 03 15 ; Buffer pointer I2C addr E2 (71w) IR Rx  -   5 bytes
01c5 add   r1,@r0 ; 03 10 ; Buffer pointer I2C addr E3 (71r) IR Rx  -   5 bytes
01c7 add   r0,@r10; 03 0a ; Buffer pointer I2C addr E4 (72w) IR PB1 -   4 bytes
01c9 add   r1,@r10; 03 1a ; Buffer pointer I2C addr E5 (72r) IR PB1 -   4 bytes
01cb add   r0,@r5 ; 03 05 ; Buffer pointer I2C addr E6 (73w) IR Lrn -   1 bytes
01cd add   r0,r0  ; 02 00 ; Buffer pointer I2C addr E7 (73r) IR Lrn - 256 bytes

and the I2C handling routines appear to do the right thing in waiting
for "full" buffers before operating on them.

2. Z8 Port B is used by both Tx and Rx functions, but the functions
each only use 1 line of the I/O port and they use different lines.

3. Z8 Port C is unused.

4. Z8 Port A is used by both Tx functions, Rx functions, the I2C
interface.  If something inside the Z8 screws up the I2C bus comms with
the chip, it's likely the errant misconfiguration of Port A during
certain Rx and Tx operations.

5. Rx and IR Learn both use the same external hardware.  Not
coordinating Rx with Learn mode in the same driver, will prevent Learn
operation from working.  That is, if Learn mode is ever implemented. 
(Once upon a time, I was planning on doing that.  But I have no time
for that anymore.)  

> > Yes I know ir-kbd-i2c is in mainline, but as I said, I had reasons
> > for avoiding it when using Tx operation of the chip.  It's been 7
> > years, and I'm getting too old to remember the reasons. :P
> 
> Yeah, you definitely don't want to be issuing requests to the Rx and
> Tx addresses at the same time.  Very bad things will happen.
> 
> Also, what is the polling interval for ir-kbd-i2c?  If it's too high
> you can wedge the I2C bus (depending on the hardware design).
> Likewise, many people disable IR RX entirely (which is trivial to do
> with lirc_zilog through a modprobe optoin).  This is because early
> versions of the HDPVR had issues where polling too often can
> interfere
> with traffic that configures the component receiver chip.  This was
> improved in later versions of the design, but many people found it
> was
> just easiest to disable RX since they don't use it (i.e. they would
> use the blaster for controlling their STB but use a separate IR
> receiver).
> 
> Are you testing with video capture actively in use?  If you're
> testing
> the IR interface without an active HD capture in progress you're
> likely to miss some of these edge cases (in particular those which
> would hang the encoder).

I'm glad someone remembers all this stuff.  I'm assuming you had more
pain with this than I ever did.  I never owned an HD-PVR.

Regards,
Andy

> I'm not against the removal of duplicate code in general, but you
> have
> to tread carefully because there are plenty of non-obvious edge cases
> to consider.
> 
> Devin
> 

Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver

[Andy Walls]

On October 11, 2017 5:02:37 PM EDT, Sean Young <s...@mess.org> wrote:
>On Wed, Oct 11, 2017 at 03:43:16PM -0400, Andy Walls wrote:
>> On Tue, 2017-10-10 at 08:17 +0100, Sean Young wrote:
>> > The ir-kbd-i2c module already handles this very well.
>> 
>> Hi Sean:
>> 
>> It's been years, but my recollection is that although ir-kdb-i2c
>might
>> handle receive well, but since the 4 i2c addresses (1 Rx, 1 Tx, 1 IR
>Tx
>> code learning, 1 custom Tx code) are all handled by the same Zilog
>> microcontroller internally, that splitting the Rx and Tx
>functionality
>> between two modules became problematic.
>> 
>> Believe me, if i could have leveraged ir-kdb-i2c back when I ported
>> this, I would have.  I think it's a very bad idea to remove the
>> receiver from lirc_zilog.
>> 
>> The cx18 and ivtv drivers both use lirc_zilog IIRC.  Have you looked
>at
>> the changes required to have the first I2C address used by one i2c
>> module, and the next one (or three) I2C addresses used by another i2c
>> module?
>
>This is already the case.
>
>In current kernels you can use ir-kbd-i2c for Rx and lirc_zilog for Tx,
>this works fine. In fact, the lirc_zilog Rx code produces lirccodes,
>(not mode2) and ir-kbd-i2c produces keycodes through rc-core, so
>ir-kbd-i2c
>(also mainline, not staging) is much more likely to be used for Rx. For
>Tx
>you have to use lirc_zilog.
>
>I haven't heard of any reports of problems (or observed this myself)
>when
>using these two modules together.
>
>As you point out, both drivers sending i2c commands to the same z8f0811
>
>with its z8 encore hand-coded i2c implementation. But they're using
>different
>addresses.
>
>So removing the lirc_zilog Rx doesn't make things worse, in fact, it
>just
>removes some code which is unlikely to be used.
>
>It's the hdpvr, ivtv, cx18 and pvrusb2 drivers which have a Tx
>interface. I
>have hdpvr and ivtv hardware to test.
>
>
>Sean
>
>> 
>> -Andy
>> 
>> 
>> > 
>> > Signed-off-by: Sean Young <s...@mess.org>
>> > ---
>> >  drivers/staging/media/lirc/lirc_zilog.c | 901
>+++---
>> > --
>> >  1 file changed, 76 insertions(+), 825 deletions(-)
>> > 
>> > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
>> > b/drivers/staging/media/lirc/lirc_zilog.c
>> > index 6bd0717bf76e..757b3fc247ac 100644
>> > --- a/drivers/staging/media/lirc/lirc_zilog.c
>> > +++ b/drivers/staging/media/lirc/lirc_zilog.c
>> > @@ -64,28 +64,7 @@
>> >  /* Max transfer size done by I2C transfer functions */
>> >  #define MAX_XFER_SIZE  64
>> >  
>> > -struct IR;
>> > -
>> > -struct IR_rx {
>> > -  struct kref ref;
>> > -  struct IR *ir;
>> > -
>> > -  /* RX device */
>> > -  struct mutex client_lock;
>> > -  struct i2c_client *c;
>> > -
>> > -  /* RX polling thread data */
>> > -  struct task_struct *task;
>> > -
>> > -  /* RX read data */
>> > -  unsigned char b[3];
>> > -  bool hdpvr_data_fmt;
>> > -};
>> > -
>> >  struct IR_tx {
>> > -  struct kref ref;
>> > -  struct IR *ir;
>> > -
>> >/* TX device */
>> >struct mutex client_lock;
>> >struct i2c_client *c;
>> > @@ -93,39 +72,9 @@ struct IR_tx {
>> >/* TX additional actions needed */
>> >int need_boot;
>> >bool post_tx_ready_poll;
>> > -};
>> > -
>> > -struct IR {
>> > -  struct kref ref;
>> > -  struct list_head list;
>> > -
>> > -  /* FIXME spinlock access to l->features */
>> >struct lirc_dev *l;
>> > -  struct lirc_buffer rbuf;
>> > -
>> > -  struct mutex ir_lock;
>> > -  atomic_t open_count;
>> > -
>> > -  struct device *dev;
>> > -  struct i2c_adapter *adapter;
>> > -
>> > -  spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
>> > -  struct IR_rx *rx;
>> > -
>> > -  spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
>> > -  struct IR_tx *tx;
>> >  };
>> >  
>> > -/* IR transceiver instance object list */
>> > -/*
>> > - * This lock is used for the following:
>> > - * a. ir_devices_list access, insertions, deletions
>> > - * b. struct IR kref get()s and put()s
>> > - * c. serialization of ir_probe() for the two i2c_clients for a Z8

Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver

[Andy Walls]

On Tue, 2017-10-10 at 08:17 +0100, Sean Young wrote:
> The ir-kbd-i2c module already handles this very well.

Hi Sean:

It's been years, but my recollection is that although ir-kdb-i2c might
handle receive well, but since the 4 i2c addresses (1 Rx, 1 Tx, 1 IR Tx
code learning, 1 custom Tx code) are all handled by the same Zilog
microcontroller internally, that splitting the Rx and Tx functionality
between two modules became problematic.

Believe me, if i could have leveraged ir-kdb-i2c back when I ported
this, I would have.  I think it's a very bad idea to remove the
receiver from lirc_zilog.

The cx18 and ivtv drivers both use lirc_zilog IIRC.  Have you looked at
the changes required to have the first I2C address used by one i2c
module, and the next one (or three) I2C addresses used by another i2c
module?

-Andy


> 
> Signed-off-by: Sean Young 
> ---
>  drivers/staging/media/lirc/lirc_zilog.c | 901 +++---
> --
>  1 file changed, 76 insertions(+), 825 deletions(-)
> 
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 6bd0717bf76e..757b3fc247ac 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -64,28 +64,7 @@
>  /* Max transfer size done by I2C transfer functions */
>  #define MAX_XFER_SIZE  64
>  
> -struct IR;
> -
> -struct IR_rx {
> - struct kref ref;
> - struct IR *ir;
> -
> - /* RX device */
> - struct mutex client_lock;
> - struct i2c_client *c;
> -
> - /* RX polling thread data */
> - struct task_struct *task;
> -
> - /* RX read data */
> - unsigned char b[3];
> - bool hdpvr_data_fmt;
> -};
> -
>  struct IR_tx {
> - struct kref ref;
> - struct IR *ir;
> -
>   /* TX device */
>   struct mutex client_lock;
>   struct i2c_client *c;
> @@ -93,39 +72,9 @@ struct IR_tx {
>   /* TX additional actions needed */
>   int need_boot;
>   bool post_tx_ready_poll;
> -};
> -
> -struct IR {
> - struct kref ref;
> - struct list_head list;
> -
> - /* FIXME spinlock access to l->features */
>   struct lirc_dev *l;
> - struct lirc_buffer rbuf;
> -
> - struct mutex ir_lock;
> - atomic_t open_count;
> -
> - struct device *dev;
> - struct i2c_adapter *adapter;
> -
> - spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
> - struct IR_rx *rx;
> -
> - spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
> - struct IR_tx *tx;
>  };
>  
> -/* IR transceiver instance object list */
> -/*
> - * This lock is used for the following:
> - * a. ir_devices_list access, insertions, deletions
> - * b. struct IR kref get()s and put()s
> - * c. serialization of ir_probe() for the two i2c_clients for a Z8
> - */
> -static DEFINE_MUTEX(ir_devices_lock);
> -static LIST_HEAD(ir_devices_list);
> -
>  /* Block size for IR transmitter */
>  #define TX_BLOCK_SIZE99
>  
> @@ -153,348 +102,8 @@ struct tx_data_struct {
>  static struct tx_data_struct *tx_data;
>  static struct mutex tx_data_lock;
>  
> -
>  /* module parameters */
>  static bool debug;   /* debug output */
> -static bool tx_only; /* only handle the IR Tx function */
> -
> -
> -/* struct IR reference counting */
> -static struct IR *get_ir_device(struct IR *ir, bool
> ir_devices_lock_held)
> -{
> - if (ir_devices_lock_held) {
> - kref_get(>ref);
> - } else {
> - mutex_lock(_devices_lock);
> - kref_get(>ref);
> - mutex_unlock(_devices_lock);
> - }
> - return ir;
> -}
> -
> -static void release_ir_device(struct kref *ref)
> -{
> - struct IR *ir = container_of(ref, struct IR, ref);
> -
> - /*
> -  * Things should be in this state by now:
> -  * ir->rx set to NULL and deallocated - happens before ir-
> >rx->ir put()
> -  * ir->rx->task kthread stopped - happens before ir->rx->ir
> put()
> -  * ir->tx set to NULL and deallocated - happens before ir-
> >tx->ir put()
> -  * ir->open_count ==  0 - happens on final close()
> -  * ir_lock, tx_ref_lock, rx_ref_lock, all released
> -  */
> - if (ir->l)
> - lirc_unregister_device(ir->l);
> -
> - if (kfifo_initialized(>rbuf.fifo))
> - lirc_buffer_free(>rbuf);
> - list_del(>list);
> - kfree(ir);
> -}
> -
> -static int put_ir_device(struct IR *ir, bool ir_devices_lock_held)
> -{
> - int released;
> -
> - if (ir_devices_lock_held)
> - return kref_put(>ref, release_ir_device);
> -
> - mutex_lock(_devices_lock);
> - released = kref_put(>ref, release_ir_device);
> - mutex_unlock(_devices_lock);
> -
> - return released;
> -}
> -
> -/* struct IR_rx reference counting */
> -static struct IR_rx *get_ir_rx(struct IR *ir)
> -{
> - struct IR_rx *rx;
> -
> - spin_lock(>rx_ref_lock);
> - rx = ir->rx;
> - if (rx)
> - kref_get(>ref);
> - spin_unlock(>rx_ref_lock);

PVR-250 Composite 3 unavailable [Re: ivtv driver]

[Andy Walls]

On October 26, 2015 7:13:52 PM EDT, Warren Sturm  wrote:
>Hi Andy.
>
>I don't know whether this was intended but the pvr250 lost the
>composite 3 input when going from kernel version 4.1.10 to 4.2.3.
>
>This is on a Fedora 22 x86_64 system.
>
>
>Thanks for any insight.

Unintentional.

I'm guessing this commit was the problem:

http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/drivers/media/pci/ivtv/ivtv-driver.c?id=09290cc885937cab3b2d60a6d48fe3d2d3e04061

Could you confirm?

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

Re: [PATCH v2 2/2] x86/mm/pat, drivers/media/ivtv: move pat warn and replace WARN() with pr_warn()

[Andy Walls]

On Fri, 2015-06-26 at 10:45 +0200, Ingo Molnar wrote:
 * Luis R. Rodriguez mcg...@suse.com wrote:
 
  On Thu, Jun 25, 2015 at 08:51:47AM +0200, Ingo Molnar wrote:
   
   * Luis R. Rodriguez mcg...@do-not-panic.com wrote:
   
From: Luis R. Rodriguez mcg...@suse.com

On built-in kernels this warning will always splat as this is part
of the module init. Fix that by shifting the PAT requirement check
out under the code that does the quasi-probe for the device. This
device driver relies on an existing driver to find its own devices,
it looks for that device driver and its own found devices, then
uses driver_for_each_device() to try to see if it can probe each of
those devices as a frambuffer device with ivtvfb_init_card(). We
tuck the PAT requiremenet check then on the ivtvfb_init_card()
call making the check at least require an ivtv device present
before complaining.

Reported-by: Fengguang Wu fengguang...@intel.com [0-day test robot]
Signed-off-by: Luis R. Rodriguez mcg...@suse.com
---
 drivers/media/pci/ivtv/ivtvfb.c | 15 +--
 1 file changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/media/pci/ivtv/ivtvfb.c 
b/drivers/media/pci/ivtv/ivtvfb.c
index 4cb365d..8b95eef 100644
--- a/drivers/media/pci/ivtv/ivtvfb.c
+++ b/drivers/media/pci/ivtv/ivtvfb.c
@@ -38,6 +38,8 @@
 Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  
02111-1307  USA
  */
 
+#define pr_fmt(fmt) KBUILD_MODNAME :  fmt
+
 #include linux/module.h
 #include linux/kernel.h
 #include linux/fb.h
@@ -1171,6 +1173,13 @@ static int ivtvfb_init_card(struct ivtv *itv)
 {
int rc;
 
+#ifdef CONFIG_X86_64
+   if (pat_enabled()) {
+   pr_warn(ivtvfb needs PAT disabled, boot with nopat 
kernel parameter\n);
+   return -ENODEV;
+   }
+#endif
+
if (itv-osd_info) {
IVTVFB_ERR(Card %d already initialised\n, 
ivtvfb_card_id);
return -EBUSY;
   
   Same argument as for ipath: why not make arch_phys_wc_add() fail on PAT 
   and 
   return -1, and check it in arch_phys_wc_del()?
  
  The arch_phys_wc_add() is a no-op for PAT systems but for PAT to work we 
  need 
  not only need to add this in where we replace the MTRR call but we also 
  need to 
  convert ioremap_nocache() calls to ioremap_wc() but only if things were 
  split up 
  already.
 

Hi Ingo,

 We don't need to do that: for such legacy drivers we can fall back to UC just 
 fine, and inform the user that by booting with 'nopat' the old behavior will 
 be 
 back...

This is really a user experience decision.

IMO anyone who is still using ivtvfb and an old conventional PCI PVR-350
to render, at SDTV resolution, an X Desktop display or video playback on
a television screen, isn't going to give a hoot about modern things like
PAT.  The user will simply want the framebuffer performance they are
accustomed to having with their system.  UC will probably yield
unsatisfactory performance for an ivtvfb framebuffer.

With that in mind, I would think it better to obviously and clearly
disable the ivtvfb framebuffer module with PAT enabled, so the user will
check the log and read the steps needed to obtain acceptable
performance.

Maybe that's me just wanting to head off the poor ivtvfb performance
with latest kernel bug reports.

Whatever the decision, my stock response to bug reports related to this
will always be What do the logs say?.

Regards,
Andy


--
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 02/14] cx18: avoid going past input/audio array

[Andy Walls]

On April 28, 2015 11:43:41 AM EDT, Mauro Carvalho Chehab 
mche...@osg.samsung.com wrote:
As reported by smatch:
   drivers/media/pci/cx18/cx18-driver.c:807 cx18_init_struct2() error:
buffer overflow 'cx-card-video_inputs' 6 = 6

That happens because nof_inputs and nof_audio_inputs can be initialized
as CX18_CARD_MAX_VIDEO_INPUTS, instead of CX18_CARD_MAX_VIDEO_INPUTS -
1.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/pci/cx18/cx18-driver.c
b/drivers/media/pci/cx18/cx18-driver.c
index 83f5074706f9..260e462d91b4 100644
--- a/drivers/media/pci/cx18/cx18-driver.c
+++ b/drivers/media/pci/cx18/cx18-driver.c
@@ -786,11 +786,11 @@ static void cx18_init_struct2(struct cx18 *cx)
 {
   int i;
 
-  for (i = 0; i  CX18_CARD_MAX_VIDEO_INPUTS; i++)
+  for (i = 0; i  CX18_CARD_MAX_VIDEO_INPUTS - 1; i++)
   if (cx-card-video_inputs[i].video_type == 0)
   break;
   cx-nof_inputs = i;
-  for (i = 0; i  CX18_CARD_MAX_AUDIO_INPUTS; i++)
+  for (i = 0; i  CX18_CARD_MAX_AUDIO_INPUTS - 1; i++)
   if (cx-card-audio_inputs[i].audio_type == 0)
   break;
   cx-nof_audio_inputs = i;

Acked-by: Andy Walls awa...@md.metrocast.net
--
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 08/14] avoid going past input/audio array

[Andy Walls]

On April 28, 2015 11:43:47 AM EDT, Mauro Carvalho Chehab 
mche...@osg.samsung.com wrote:
As reported by smatch:
   drivers/media/pci/ivtv/ivtv-driver.c:832 ivtv_init_struct2() error:
buffer overflow 'itv-card-video_inputs' 6 = 6

That happens because nof_inputs and nof_audio_inputs can be initialized
as IVTV_CARD_MAX_VIDEO_INPUTS, instead of IVTV_CARD_MAX_VIDEO_INPUTS -
1.

Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com

diff --git a/drivers/media/pci/ivtv/ivtv-driver.c
b/drivers/media/pci/ivtv/ivtv-driver.c
index c2e60b4f292d..8616fa8193bc 100644
--- a/drivers/media/pci/ivtv/ivtv-driver.c
+++ b/drivers/media/pci/ivtv/ivtv-driver.c
@@ -805,11 +805,11 @@ static void ivtv_init_struct2(struct ivtv *itv)
 {
   int i;
 
-  for (i = 0; i  IVTV_CARD_MAX_VIDEO_INPUTS; i++)
+  for (i = 0; i  IVTV_CARD_MAX_VIDEO_INPUTS - 1; i++)
   if (itv-card-video_inputs[i].video_type == 0)
   break;
   itv-nof_inputs = i;
-  for (i = 0; i  IVTV_CARD_MAX_AUDIO_INPUTS; i++)
+  for (i = 0; i  IVTV_CARD_MAX_AUDIO_INPUTS - 1; i++)
   if (itv-card-audio_inputs[i].audio_type == 0)
   break;
   itv-nof_audio_inputs = i;

Acked-by: Andy Walls awa...@md.metrocast.net
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] ivtv: use arch_phys_wc_add() and require PAT disabled

[Andy Walls]

On Mon, 2015-04-27 at 09:43 -0700, Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@suse.com
 
 We are burrying direct access to MTRR code support on
 x86 in order to take advantage of PAT. In the future we
 also want to make the default behaviour of ioremap_nocache()
 to use strong UC, use of mtrr_add() on those systems
 would make write-combining void.
 
 In order to help both enable us to later make strong
 UC default and in order to phase out direct MTRR access
 code port the driver over to arch_phys_wc_add() and
 annotate that the device driver requires systems to
 boot with PAT disabled, with the nopat kernel parameter.
 
 This is a worthy comprmise given that the hardware is
 really rare these days, and perhaps only some lost souls
 in some third world country are expected to be using this
 feature of the device driver.
 
 Cc: Andy Walls awa...@md.metrocast.net

Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

 Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
 Cc: Andy Lutomirski l...@amacapital.net
 Cc: Suresh Siddha sbsid...@gmail.com
 Cc: Ingo Molnar mi...@elte.hu
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Juergen Gross jgr...@suse.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Dave Airlie airl...@redhat.com
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Antonino Daplas adap...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: Dave Hansen dave.han...@linux.intel.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Stefan Bader stefan.ba...@canonical.com
 Cc: Ville Syrjälä syrj...@sci.fi
 Cc: Mel Gorman mgor...@suse.de
 Cc: Vlastimil Babka vba...@suse.cz
 Cc: Borislav Petkov b...@suse.de
 Cc: Davidlohr Bueso dbu...@suse.de
 Cc: konrad.w...@oracle.com
 Cc: ville.syrj...@linux.intel.com
 Cc: david.vra...@citrix.com
 Cc: jbeul...@suse.com
 Cc: toshi.k...@hp.com
 Cc: Roger Pau Monné roger@citrix.com
 Cc: linux-fb...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Cc: ivtv-de...@ivtvdriver.org
 Cc: linux-media@vger.kernel.org
 Cc: xen-de...@lists.xensource.com
 Signed-off-by: Luis R. Rodriguez mcg...@suse.com
 ---
 
 This v2 moves the PAT bail out error check on to ivtvfb_init()
 as per Andy's request. It also removes some comment about TODO
 items for PAT.
 
  drivers/media/pci/ivtv/Kconfig  |  3 +++
  drivers/media/pci/ivtv/ivtvfb.c | 58 
 -
  2 files changed, 26 insertions(+), 35 deletions(-)
 
 diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
 index dd6ee57e..b2a7f88 100644
 --- a/drivers/media/pci/ivtv/Kconfig
 +++ b/drivers/media/pci/ivtv/Kconfig
 @@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
 This is used in the Hauppauge PVR-350 card. There is a driver
 homepage at http://www.ivtvdriver.org.
  
 +   If you have this hardware you will need to boot with PAT disabled
 +   on your x86 systems, use the nopat kernel parameter.
 +
 To compile this driver as a module, choose M here: the
 module will be called ivtvfb.
 diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
 index 9ff1230..8761e3e 100644
 --- a/drivers/media/pci/ivtv/ivtvfb.c
 +++ b/drivers/media/pci/ivtv/ivtvfb.c
 @@ -44,8 +44,8 @@
  #include linux/ivtvfb.h
  #include linux/slab.h
  
 -#ifdef CONFIG_MTRR
 -#include asm/mtrr.h
 +#ifdef CONFIG_X86_64
 +#include asm/pat.h
  #endif
  
  #include ivtv-driver.h
 @@ -155,12 +155,11 @@ struct osd_info {
   /* Buffer size */
   u32 video_buffer_size;
  
 -#ifdef CONFIG_MTRR
   /* video_base rounded down as required by hardware MTRRs */
   unsigned long fb_start_aligned_physaddr;
   /* video_base rounded up as required by hardware MTRRs */
   unsigned long fb_end_aligned_physaddr;
 -#endif
 + int wc_cookie;
  
   /* Store the buffer offset */
   int set_osd_coords_x;
 @@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
  static int ivtvfb_init_io(struct ivtv *itv)
  {
   struct osd_info *oi = itv-osd_info;
 + /* Find the largest power of two that maps the whole buffer */
 + int size_shift = 31;
  
   mutex_lock(itv-serialize_lock);
   if (ivtv_init_on_first_open(itv)) {
 @@ -1132,29 +1133,16 @@ static int ivtvfb_init_io(struct ivtv *itv)
   oi-video_pbase, oi-video_vbase,
   oi-video_buffer_size / 1024);
  
 -#ifdef CONFIG_MTRR
 - {
 - /* Find the largest power of two that maps the whole buffer */
 - int size_shift = 31;
 -
 - while (!(oi-video_buffer_size  (1  size_shift))) {
 - size_shift--;
 - }
 - size_shift++;
 - oi-fb_start_aligned_physaddr = oi-video_pbase  ~((1  
 size_shift) - 1);
 - oi-fb_end_aligned_physaddr = oi-video_pbase + 
 oi-video_buffer_size;
 - oi-fb_end_aligned_physaddr += (1  size_shift) - 1

Re: [PATCH] [media] ivtv: use arch_phys_wc_add() and require PAT disabled

[Andy Walls]

Hi Luis,

Sorry for the late reply.

Thank you for the patch! See my comments below:

On Wed, 2015-04-22 at 12:33 -0700, Luis R. Rodriguez wrote:
 From: Luis R. Rodriguez mcg...@suse.com
 
 We are burrying direct access to MTRR code support on
 x86 in order to take advantage of PAT. In the future we
 also want to make the default behaviour of ioremap_nocache()
 to use strong UC, use of mtrr_add() on those systems
 would make write-combining void.
 
 In order to help both enable us to later make strong
 UC default and in order to phase out direct MTRR access
 code port the driver over to arch_phys_wc_add() and
 annotate that the device driver requires systems to
 boot with PAT disabled, with the nopat kernel parameter.
 
 This is a worthy comprmise given that the hardware is
 really rare these days,

I'm OK with the compromise solution.  It makes sense.

  and perhaps only some lost souls
 in some third world country are expected to be using this
 feature of the device driver.
 
 Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
 Cc: Andy Lutomirski l...@amacapital.net
 Cc: Andy Walls awa...@md.metrocast.net
 Cc: Suresh Siddha sbsid...@gmail.com
 Cc: Ingo Molnar mi...@elte.hu
 Cc: Thomas Gleixner t...@linutronix.de
 Cc: Juergen Gross jgr...@suse.com
 Cc: Daniel Vetter daniel.vet...@ffwll.ch
 Cc: Dave Airlie airl...@redhat.com
 Cc: Bjorn Helgaas bhelg...@google.com
 Cc: Antonino Daplas adap...@gmail.com
 Cc: Jean-Christophe Plagniol-Villard plagn...@jcrosoft.com
 Cc: Tomi Valkeinen tomi.valkei...@ti.com
 Cc: Dave Hansen dave.han...@linux.intel.com
 Cc: Arnd Bergmann a...@arndb.de
 Cc: Michael S. Tsirkin m...@redhat.com
 Cc: Stefan Bader stefan.ba...@canonical.com
 Cc: Ville Syrjälä syrj...@sci.fi
 Cc: Mel Gorman mgor...@suse.de
 Cc: Vlastimil Babka vba...@suse.cz
 Cc: Borislav Petkov b...@suse.de
 Cc: Davidlohr Bueso dbu...@suse.de
 Cc: konrad.w...@oracle.com
 Cc: ville.syrj...@linux.intel.com
 Cc: david.vra...@citrix.com
 Cc: jbeul...@suse.com
 Cc: toshi.k...@hp.com
 Cc: Roger Pau Monné roger@citrix.com
 Cc: linux-fb...@vger.kernel.org
 Cc: linux-ker...@vger.kernel.org
 Cc: ivtv-de...@ivtvdriver.org
 Cc: linux-media@vger.kernel.org
 Cc: xen-de...@lists.xensource.com
 Signed-off-by: Luis R. Rodriguez mcg...@suse.com
 ---
  drivers/media/pci/ivtv/Kconfig  |  3 +++
  drivers/media/pci/ivtv/ivtvfb.c | 59 
 +
  2 files changed, 27 insertions(+), 35 deletions(-)
 
 diff --git a/drivers/media/pci/ivtv/Kconfig b/drivers/media/pci/ivtv/Kconfig
 index dd6ee57e..b2a7f88 100644
 --- a/drivers/media/pci/ivtv/Kconfig
 +++ b/drivers/media/pci/ivtv/Kconfig
 @@ -57,5 +57,8 @@ config VIDEO_FB_IVTV
 This is used in the Hauppauge PVR-350 card. There is a driver
 homepage at http://www.ivtvdriver.org.
  
 +   If you have this hardware you will need to boot with PAT disabled
 +   on your x86 systems, use the nopat kernel parameter.
 +
 To compile this driver as a module, choose M here: the
 module will be called ivtvfb.
 diff --git a/drivers/media/pci/ivtv/ivtvfb.c b/drivers/media/pci/ivtv/ivtvfb.c
 index 9ff1230..552408b 100644
 --- a/drivers/media/pci/ivtv/ivtvfb.c
 +++ b/drivers/media/pci/ivtv/ivtvfb.c
 @@ -44,8 +44,8 @@
  #include linux/ivtvfb.h
  #include linux/slab.h
  
 -#ifdef CONFIG_MTRR
 -#include asm/mtrr.h
 +#ifdef CONFIG_X86_64
 +#include asm/pat.h
  #endif
  
  #include ivtv-driver.h
 @@ -155,12 +155,11 @@ struct osd_info {
   /* Buffer size */
   u32 video_buffer_size;
  
 -#ifdef CONFIG_MTRR
   /* video_base rounded down as required by hardware MTRRs */
   unsigned long fb_start_aligned_physaddr;
   /* video_base rounded up as required by hardware MTRRs */
   unsigned long fb_end_aligned_physaddr;
 -#endif
 + int wc_cookie;
  
   /* Store the buffer offset */
   int set_osd_coords_x;
 @@ -1099,6 +1098,8 @@ static int ivtvfb_init_vidmode(struct ivtv *itv)
  static int ivtvfb_init_io(struct ivtv *itv)
  {
   struct osd_info *oi = itv-osd_info;
 + /* Find the largest power of two that maps the whole buffer */
 + int size_shift = 31;
  
   mutex_lock(itv-serialize_lock);
   if (ivtv_init_on_first_open(itv)) {
 @@ -1120,6 +1121,7 @@ static int ivtvfb_init_io(struct ivtv *itv)
   oi-video_buffer_size = 1704960;
  
   oi-video_pbase = itv-base_addr + IVTV_DECODER_OFFSET + 
 oi-video_rbase;
 + /* XXX: split this for PAT */

Please remove this comment.  It is prescriptive of a particular
solution, and probably not the one I'm going to implement.  The ivtv
main driver alreay splits the encoder, decoder, and register regions
into 3 mappings.  The final solution will set the whole 8 MB decoder
region mapping to WC, and then fix up all calls in the ivtvfb and ivtv
drivers where writes to the decoder memory with WC enabled could be a
problem.

Also many other places in the driver need audit in a conversion to work
with PAT, so no need to call out this one location

Re: [PATCH] cx18: add missing caps for the PCM video device

[Andy Walls]

On April 24, 2015 2:55:07 AM EDT, Hans Verkuil hverk...@xs4all.nl wrote:
The cx18 PCM video device didn't have any capabilities set, which
caused a warnings
in the v4l2 core:

[6.229393] [ cut here ]
[6.229414] WARNING: CPU: 1 PID: 593 at 
drivers/media/v4l2-core/v4l2-ioctl.c:1025 v4l_querycap+0x41/0x70 
[videodev]()
[6.229415] Modules linked in: cx18_alsa mxl5005s s5h1409 
tuner_simple tuner_types cs5345 tuner intel_rapl iosf_mbi 
x86_pkg_temp_thermal coretemp raid1 snd_hda_codec_realtek kvm_intel 
snd_hda_codec_generic snd_hda_codec_hdmi kvm snd_oxygen(+)
snd_hda_intel 
snd_oxygen_lib snd_hda_controller snd_hda_codec snd_mpu401_uart
iTCO_wdt 
snd_rawmidi iTCO_vendor_support snd_hwdep crct10dif_pclmul crc32_pclmul

crc32c_intel snd_seq cx18 snd_seq_device ghash_clmulni_intel 
videobuf_vmalloc tveeprom cx2341x snd_pcm serio_raw videobuf_core vfat 
dvb_core fat v4l2_common snd_timer videodev snd lpc_ich i2c_i801 joydev

mfd_core mei_me media soundcore tpm_infineon soc_button_array tpm_tis 
mei shpchp tpm nfsd auth_rpcgss nfs_acl lockd grace sunrpc binfmt_misc 
i915 nouveau mxm_wmi wmi e1000e ttm i2c_algo_bit drm_kms_helper
[6.229444]  drm ptp pps_core video
[6.229446] CPU: 1 PID: 593 Comm: v4l_id Not tainted 
3.19.3-200.fc21.x86_64 #1
[6.229447] Hardware name: Gigabyte Technology Co., Ltd. 
Z87-D3HP/Z87-D3HP-CF, BIOS F6 01/20/2014
[6.229448]   d12b1131 88042dacfc28 
8176e215
[6.229449]    88042dacfc68 
8109bc1a
[6.229451]  a0594000 88042dacfd90  
a04e2140
[6.229452] Call Trace:
[6.229466]  [8176e215] dump_stack+0x45/0x57
[6.229469]  [8109bc1a] warn_slowpath_common+0x8a/0xc0
[6.229472]  [8109bd4a] warn_slowpath_null+0x1a/0x20
[6.229474]  [a04ca401] v4l_querycap+0x41/0x70 [videodev]
[6.229477]  [a04ca6cc] __video_do_ioctl+0x29c/0x320
[videodev]
[6.229479]  [81227131] ? do_last+0x2f1/0x1210
[6.229491]  [a04cc776] video_usercopy+0x366/0x5d0
[videodev]
[6.229494]  [a04ca430] ? v4l_querycap+0x70/0x70
[videodev]
[6.229497]  [a04cc9f5] video_ioctl2+0x15/0x20 [videodev]
[6.229499]  [a04c6794] v4l2_ioctl+0x164/0x180 [videodev]
[6.229501]  [8122e298] do_vfs_ioctl+0x2f8/0x500
[6.229502]  [8122e521] SyS_ioctl+0x81/0xa0
[6.229505]  [81774a09] system_call_fastpath+0x12/0x17
[6.229506] ---[ end trace dacd80d4b19277ea ]---

Added the necessary capabilities to stop this warning.

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
Reported-by: Laura Abbott labb...@redhat.com
Cc: sta...@vger.kernel.org  # for v3.19 and up
---
diff --git a/drivers/media/pci/cx18/cx18-streams.c
b/drivers/media/pci/cx18/cx18-streams.c
index c82d25d..c986084 100644
--- a/drivers/media/pci/cx18/cx18-streams.c
+++ b/drivers/media/pci/cx18/cx18-streams.c
@@ -90,6 +90,7 @@ static struct {
   encoder PCM audio,
   VFL_TYPE_GRABBER, CX18_V4L2_ENC_PCM_OFFSET,
   PCI_DMA_FROMDEVICE,
+  V4L2_CAP_TUNER | V4L2_CAP_AUDIO | V4L2_CAP_READWRITE,
   },
   {   /* CX18_ENC_STREAM_TYPE_IDX */
   encoder IDX,

Thanks Hans!
 

Acked-by: Andy Walls awa...@md.metrocast.net
--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

Hi All,

On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
[snip]
  I only saw a few drivers using overlapping ioremap*()
 calls though on my MTRR review and they are all old devices so likely mostly
 used on non-PAT systems, but there might be other corner cases elsewhere.
 
 Lets recap, as I see it we have a few options with all this in mind on our
 quest to bury MTRR (and later make strong UC default):
 
 1) Let drivers do their own get_vm_area() calls as you note and handle the
cut and splicing of ioremap areas
 
 2) Provide an API to split and splice ioremap ranges
 
 3) Try to avoid these types of situations and let drivers simply try to
work towards a proper clean non-overlapping different ioremap() ranges
 
 Let me know if you think of others but please keep in mind the UC- to strong
 UC converstion we want to do later as well. We have ruled out using
 set_memor_wc() now.
 
 I prefer option 3), its technically possible but only for *new* drivers
 and we'd need either some hard work to split the ioremap() areas or provide
 a a set of *transient* APIs as I had originally proposed to phase / hope for
 final transition. There are 3 drivers to address:
 
 [snip]

Just some background for folks:
The ivtv driver supports cards that perform Standard Definition PAL,
NTSC, and SECAM TV capture + hardware MPEG-2 encoding and MPEG-2
decoding + TV output.

Of the supported cards only *one* card type, the PVR-350 based on the
CX23415 chip, can perform the MPEG-2 or YUV video decoding and output,
with an OSD overlay.  PVR-350's are legacy PCI cards that have been end
of life since 2088 or earlier.  Despite that, there are still used units
available on Amazon and eBay.

The ivtvfb driver module is an *optional* companion driver module that
provides a framebuffer interface for the user to output an X display, FB
console, or whatever to a standard definition analog PAL, NTSC, or SECAM
TV or VCR.  It does this by co-opting the OSD overlay of the video
decoding output engine and having it take up the whole screen.


 
 c) ivtv: the driver does not have the PCI space mapped out separately, and
 in fact it actually does not do the math for the framebuffer, instead it lets
 the device's own CPU do that and assume where its at, see
 ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get
 but not a setter. Its not clear if the firmware would make a split easy.

The CX2341[56]'s firmware + hardware machine are notorious for bugs and
being hard to work with.  It would be difficult to determine with any
certainty that the firmware returned predictable OSD framebuffer
addresses from one user's system to the next.


 We'd need ioremap_ucminus() here too and __arch_phys_wc_add().

Yes.

As a driver writer/maintainer, IMO the name ioremap_ucminus() is jargon,
without a clear meaning from the name, and maybe too x86 PAT specific?
The pat.txt file under Documentation didn't explain what UC- meant; I
had to go searching old LKML emails to understand it was a unchached
region that could be overridden with write combine regions.

To me names along, these lines would be better:
   ioremap_nocache_weak(), or
   ioremap_nocache_mutable(), or
   ioremap_nocache()  (with ioremap_nocache_strong() or something for
the UC version)


 From the beginning it seems only framebuffer devices used MTRR/WC,
[snip]
  The ivtv device is a good example of the worst type of
 situations and these days. So perhap __arch_phys_wc_add() and a
 ioremap_ucminus() might be something more than transient unless hardware folks
 get a good memo or already know how to just Do The Right Thing (TM).

Just to reiterate a subtle point, use of the ivtvfb is *optional*.  A
user may or may not load it.  When the user does load the ivtvfb driver,
the ivtv driver has already been initialized and may have functions of
the card already in use by userspace.

Hopefully no one is trying to use the OSD as framebuffer and the video
decoder/output engine for video display at the same time.  But the video
decoder/output device nodes may already be open for performing ioctl()
functions so unmapping the decoder IO space out from under them, when
loading the ivtvfb driver module, might not be a good thing. 

Regards,
Andy

--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

On Wed, 2015-04-15 at 13:42 -0700, Andy Lutomirski wrote:
 On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com wrote:
 
  c) ivtv: the driver does not have the PCI space mapped out separately, and
  in fact it actually does not do the math for the framebuffer, instead it 
  lets
  the device's own CPU do that and assume where its at, see
  ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get
  but not a setter. Its not clear if the firmware would make a split easy.
  We'd need ioremap_ucminus() here too and __arch_phys_wc_add().
 
 
 IMO this should be conceptually easy to split.  Once we get the
 framebuffer address, just unmap it (or don't prematurely map it) and
 then ioremap the thing.

Not so easy.  The main ivtv driver has already set up the PCI device and
done the mapping for the MPEG-2 decoder/video output engine.  The video
decoder/output device nodes might already be open by user space calling
into the main driver, before the ivtvfb module is even loaded.

This could be mitigated by integrating all the ivtvfb module code into
the main ivtv module.  But even then not every PVR-350 owner wants to
use the video output OSD as a framebuffer.  Users might just want an
actual OSD overlaying their TV video playback.

Regards,
Andy

--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

On Thu, 2015-04-16 at 01:58 +0200, Luis R. Rodriguez wrote:
 Hey Andy, thanks for your review,  adding Hyong-Youb Kim for  review of the
 full range ioremap_wc() idea below.
 
 On Wed, Apr 15, 2015 at 06:38:51PM -0400, Andy Walls wrote:
  Hi All,
  
  On Mon, 2015-04-13 at 19:49 +0200, Luis R. Rodriguez wrote:
   From the beginning it seems only framebuffer devices used MTRR/WC,
  [snip]
The ivtv device is a good example of the worst type of
   situations and these days. So perhap __arch_phys_wc_add() and a
   ioremap_ucminus() might be something more than transient unless hardware 
   folks
   get a good memo or already know how to just Do The Right Thing (TM).
  
  Just to reiterate a subtle point, use of the ivtvfb is *optional*.  A
  user may or may not load it.  When the user does load the ivtvfb driver,
  the ivtv driver has already been initialized and may have functions of
  the card already in use by userspace.
 
 I suspected this and its why I note that a rewrite to address a clean
 split with separate ioremap seems rather difficult in this case.
 
  Hopefully no one is trying to use the OSD as framebuffer and the video
  decoder/output engine for video display at the same time. 
 
 Worst case concern I have also is the implications of having overlapping
 ioremap() calls (as proposed in my last reply) for different memory types
 and having the different virtual memory addresse used by different parts
 of the driver. Its not clear to me what the hardware implications of this
 are.
 
   But the video
  decoder/output device nodes may already be open for performing ioctl()
  functions so unmapping the decoder IO space out from under them, when
  loading the ivtvfb driver module, might not be a good thing. 
 
 Using overlapping ioremap() calls with different memory types would address
 this concern provided hardware won't barf both on the device and CPU. Hardware
 folks could provide feedback or an ivtvfb user could test the patch supplied
 on both non-PAT and PAT systems. Even so, who knows,  this might work on some
 systems while not on others, only hardware folks would know.

The CX2341[56] firmware+hardware has a track record for being really
picky about sytem hardware.  It's primary symptoms are for the DMA
engine or Mailbox protocol to get hung up.  So yeah, it could barf
easily on some users.

 An alternative... is to just ioremap_wc() the entire region, including
 MMIO registers for these old devices.

That's my thought; as long as implementing PCI write then read can force
writes to be posted and that setting that many pages as WC doesn't cause
some sort of PAT resource exhaustion. (I know very little about PAT).

  I see one ethernet driver that does
 this, myri10ge, and am curious how and why they ended up deciding this
 and if they have run into any issues. I wonder if this is a reasonable
 comrpomise for these 2 remaining corner cases.
 
   Luis

Regards,
Andy

--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

On Wed, 2015-04-15 at 16:52 -0700, Andy Lutomirski wrote:
 On Wed, Apr 15, 2015 at 3:50 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2015-04-15 at 13:42 -0700, Andy Lutomirski wrote:
  On Mon, Apr 13, 2015 at 10:49 AM, Luis R. Rodriguez mcg...@suse.com 
  wrote:
 
   c) ivtv: the driver does not have the PCI space mapped out separately, 
   and
   in fact it actually does not do the math for the framebuffer, instead it 
   lets
   the device's own CPU do that and assume where its at, see
   ivtvfb_get_framebuffer() and CX2341X_OSD_GET_FRAMEBUFFER, it has a get
   but not a setter. Its not clear if the firmware would make a split easy.
   We'd need ioremap_ucminus() here too and __arch_phys_wc_add().
  
 
  IMO this should be conceptually easy to split.  Once we get the
  framebuffer address, just unmap it (or don't prematurely map it) and
  then ioremap the thing.
 
  Not so easy.  The main ivtv driver has already set up the PCI device and
  done the mapping for the MPEG-2 decoder/video output engine.  The video
  decoder/output device nodes might already be open by user space calling
  into the main driver, before the ivtvfb module is even loaded.
 
 Surely the MPEG-2 decoder/video engine won't overlap the framebuffer,
 though.  Am I missing something?

ivtvfb is stealing the decoders' OSD for use as a framebuffer.
The decoder video output memory doesn't overlap the decoder OSD memory,
but there is a functional overlap.  ivtv driver video output device
nodes can manipulate the OSD that ivtvfb is stealing.

It would be a dumb thing for the user to want to use ivtvfb, and to also
manipulate the OSD via the video output device nodes at the same time,
for anything other than setting up the TV video standard.  However the
current ivtv driver code doesn't prevent the OSD from being manipulated
by the video output device nodes when ivtvfb is in use.

-Andy

--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

On Wed, 2015-04-15 at 17:58 -0700, Andy Lutomirski wrote:
 On Wed, Apr 15, 2015 at 4:59 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
  On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net 
  wrote:
 
  
 
  IMO the right solution would be to avoid ioremapping the whole bar at
  startup.  Instead ioremap pieces once the driver learns what they are.
  This wouldn't have any of these problems -- you'd ioremap() register
  regions and you'd ioremap_wc() the framebuffer once you find it.  If
  there are regions of unknown purpose, just don't map them all.
 
  Would this be feasible?
 
  Feasible? Maybe.
 
  Worth the time and effort for end-of-life, convential PCI hardware so I
  can have an optimally performing X display on a Standard Def Analog TV
  screen?   Nope. I don't have that level of nostalgia.
 
 
 The point is actually to let us unexport or delete mtrr_add.

Understood.


   We can
 either severely regress performance on ivtv on PAT-capable hardware if
 we naively switch it to arch_phys_wc_add or we can do something else.
 The something else remains to be determined.

Maybe ioremap the decoder register area as UC, and ioremap the rest of
the decoder region to WC. (Does that suck up too many PAT resources?)
Then add PCI reads following any sort of singleton PCI writes in the WC
region.  I assume PCI rules about write postings before reads still
apply when WC is set.

 
  We sort of know where some things are in the MMIO space due to
  experimentation and past efforts examining the firmware binary.
 
  Documentation/video4linux/cx2341x/fw-*.txt documents some things.  The
  driver code actually codifies a little bit more knowledge.
 
  The driver code for doing transfers between host and card is complex and
  fragile with some streams that use DMA, other streams that use PIO,
  digging VBI data straight out of card memory, and scatter-gather being
  broken on newer firmwares.  Playing around with ioremapping will be hard
  to get right and likely cause something in the code to break for the
  primary use case of the ivtv supported cards.
 
 Ick.

Yeah.

 If the only thing that really wants WC is the esoteric framebuffer
 thing,

That appears to be it.

  could we just switch to arch_phys_wc_add and assume that no one
 will care about the regression on new CPUs with ivtv cards?

That's on the table in my mind.  Not sure if it is the friendliest thing
to do to users.  Quite honestly though, modern graphics cards have much
better ouput resolution and performance.  Anyone with a modern system
really should be using one.  (i.e. MythTV gave up on support for PVR-350
output for video playback years ago in May 2010.)


BTW, my 2005 system with multiple conventional PCI slots in it shows a
'pat' flag in /proc/cpuinfo.  (AMD Athlon(tm) 64 X2 Dual Core Processor
4200+)  I didn't know it was considered new. :)

Regards,
Andy


--
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: ioremap_uc() followed by set_memory_wc() - burrying MTRR

[Andy Walls]

On Wed, 2015-04-15 at 16:42 -0700, Andy Lutomirski wrote:
 On Wed, Apr 15, 2015 at 3:38 PM, Andy Walls awa...@md.metrocast.net wrote:

 
 
 IMO the right solution would be to avoid ioremapping the whole bar at
 startup.  Instead ioremap pieces once the driver learns what they are.
 This wouldn't have any of these problems -- you'd ioremap() register
 regions and you'd ioremap_wc() the framebuffer once you find it.  If
 there are regions of unknown purpose, just don't map them all.
 
 Would this be feasible?

Feasible? Maybe.

Worth the time and effort for end-of-life, convential PCI hardware so I
can have an optimally performing X display on a Standard Def Analog TV
screen?   Nope. I don't have that level of nostalgia.


We sort of know where some things are in the MMIO space due to
experimentation and past efforts examining the firmware binary.

Documentation/video4linux/cx2341x/fw-*.txt documents some things.  The
driver code actually codifies a little bit more knowledge.

The driver code for doing transfers between host and card is complex and
fragile with some streams that use DMA, other streams that use PIO,
digging VBI data straight out of card memory, and scatter-gather being
broken on newer firmwares.  Playing around with ioremapping will be hard
to get right and likely cause something in the code to break for the
primary use case of the ivtv supported cards. 

Regards,
Andy


--
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] staging: media: lirc: lirc_zilog: Fix for possible null pointer dereference

[Andy Walls]

On Fri, 2015-01-30 at 08:09 -0500, valdis.kletni...@vt.edu wrote:
 On Fri, 30 Jan 2015 16:00:02 +0300, Dan Carpenter said:
 
-   if (ir == NULL) {
-   dev_err(ir-l.dev, close: no private_data attached to 
the file
 !\n);
  

commit be4aa8157c981a8bb9634b886bf1180f97205259
removed the dprintk(), which didn't depend on ir-l.dev, with this
dev_err() call.  That was the wrong thing to do. pr_info() is probably
the right thing to use, if one doesn't have a struct device instance.  

   Yes, the dev_err() call is an obvious thinko.
  
   However, I'm not sure whether removing it entirely is right either.  If
   there *should* be a struct IR * passed there, maybe some other printk()
   should be issued, or even a WARN_ON(!ir), or something?
 
  We set filep-private_data to non-NULL in open() so I don't think it can
  be NULL here.
 
 Then probably the *right* fix is to remove the *entire* if statement, as
 we can't end up doing the 'return -ENODEV'

The if() clause is here as an artifact of being part of a mass port of
lirc drivers from userspace.  I never removed it, because I needed it
when fixing all the lirc_zilog.c ref counting.

IF I got all the lirc_zilog ref counting right, and the upper layers of
the kernel never call close() in error, then this if() statement is not
needed.

I welcome anyone wishing to audit the ref-counting in lirc_zilog.  It
was mentally exhausting to get to what I think is right.  Maybe I just
tire easily mentally though. :)

-Andy

--
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: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions

[Andy Walls]

On December 20, 2014 5:35:17 PM EST, Rickard Strandqvist 
rickard_strandqv...@spectrumdigital.se wrote:
Removes some functions that are not used anywhere:
snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
snd_cx18_mixer_tv_vol_put()

This was partially found by using a static code analysis program called
cppcheck.

Signed-off-by: Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se
---
drivers/media/pci/cx18/cx18-alsa-mixer.c |   62
--
 1 file changed, 62 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
b/drivers/media/pci/cx18/cx18-alsa-mixer.c
index 341bddc..e7b0a1f 100644
--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
   return (v  9) - 119;
 }
 
-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
-struct snd_ctl_elem_info *uinfo)
-{
-  uinfo-type = SNDRV_CTL_ELEM_TYPE_INTEGER;
-  uinfo-count = 1;
-  /* We're already translating values, just keep this control in dB */
-  uinfo-value.integer.min  = -96;
-  uinfo-value.integer.max  =   8;
-  uinfo-value.integer.step =   1;
-  return 0;
-}
-
-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
-   struct snd_ctl_elem_value *uctl)
-{
-  struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
-  struct cx18 *cx = to_cx18(cxsc-v4l2_dev);
-  struct v4l2_control vctrl;
-  int ret;
-
-  vctrl.id = V4L2_CID_AUDIO_VOLUME;
-  vctrl.value = dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-
-  snd_cx18_lock(cxsc);
-  ret = v4l2_subdev_call(cx-sd_av, core, g_ctrl, vctrl);
-  snd_cx18_unlock(cxsc);
-
-  if (!ret)
-  uctl-value.integer.value[0] = cx18_av_vol_to_dB(vctrl.value);
-  return ret;
-}
-
-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
-   struct snd_ctl_elem_value *uctl)
-{
-  struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
-  struct cx18 *cx = to_cx18(cxsc-v4l2_dev);
-  struct v4l2_control vctrl;
-  int ret;
-
-  vctrl.id = V4L2_CID_AUDIO_VOLUME;
-  vctrl.value = dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-
-  snd_cx18_lock(cxsc);
-
-  /* Fetch current state */
-  ret = v4l2_subdev_call(cx-sd_av, core, g_ctrl, vctrl);
-
-  if (ret ||
-  (cx18_av_vol_to_dB(vctrl.value) != uctl-value.integer.value[0]))
{
-
-  /* Set, if needed */
-  vctrl.value = dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-  ret = v4l2_subdev_call(cx-sd_av, core, s_ctrl, vctrl);
-  if (!ret)
-  ret = 1; /* Indicate control was changed w/o error */
-  }
-  snd_cx18_unlock(cxsc);
-
-  return ret;
-}
-
 
/* This is a bit of overkill, the slider is already in dB internally */
static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600, 100,
0);

Really?  Did you try to compile the file after this patch?

http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/pci/cx18/cx18-alsa-mixer.c#n143

They are referenced later in the same file.

This is only half a fix.

 You can either remove the cx18-alsa-mixer.* files and from the build system, 
or even better,you can hook-up and initialize these callbacks with alsa so alsa 
mixer controls show up for cx18.  :)

-Andy
--
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: pci: cx18: cx18-alsa-mixer.c: Remove some unused functions

[Andy Walls]

On December 20, 2014 8:17:05 PM EST, Rickard Strandqvist 
rickard_strandqv...@spectrumdigital.se wrote:
2014-12-21 1:06 GMT+01:00 Andy Walls awa...@md.metrocast.net:
 On December 20, 2014 5:35:17 PM EST, Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se wrote:
Removes some functions that are not used anywhere:
snd_cx18_mixer_tv_vol_get() snd_cx18_mixer_tv_vol_info()
snd_cx18_mixer_tv_vol_put()

This was partially found by using a static code analysis program
called
cppcheck.

Signed-off-by: Rickard Strandqvist
rickard_strandqv...@spectrumdigital.se
---
drivers/media/pci/cx18/cx18-alsa-mixer.c |   62
--
 1 file changed, 62 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-alsa-mixer.c
b/drivers/media/pci/cx18/cx18-alsa-mixer.c
index 341bddc..e7b0a1f 100644
--- a/drivers/media/pci/cx18/cx18-alsa-mixer.c
+++ b/drivers/media/pci/cx18/cx18-alsa-mixer.c
@@ -69,68 +69,6 @@ static inline int cx18_av_vol_to_dB(int v)
   return (v  9) - 119;
 }

-static int snd_cx18_mixer_tv_vol_info(struct snd_kcontrol *kcontrol,
-struct snd_ctl_elem_info *uinfo)
-{
-  uinfo-type = SNDRV_CTL_ELEM_TYPE_INTEGER;
-  uinfo-count = 1;
-  /* We're already translating values, just keep this control in
dB */
-  uinfo-value.integer.min  = -96;
-  uinfo-value.integer.max  =   8;
-  uinfo-value.integer.step =   1;
-  return 0;
-}
-
-static int snd_cx18_mixer_tv_vol_get(struct snd_kcontrol *kctl,
-   struct snd_ctl_elem_value *uctl)
-{
-  struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
-  struct cx18 *cx = to_cx18(cxsc-v4l2_dev);
-  struct v4l2_control vctrl;
-  int ret;
-
-  vctrl.id = V4L2_CID_AUDIO_VOLUME;
-  vctrl.value = dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-
-  snd_cx18_lock(cxsc);
-  ret = v4l2_subdev_call(cx-sd_av, core, g_ctrl, vctrl);
-  snd_cx18_unlock(cxsc);
-
-  if (!ret)
-  uctl-value.integer.value[0] =
cx18_av_vol_to_dB(vctrl.value);
-  return ret;
-}
-
-static int snd_cx18_mixer_tv_vol_put(struct snd_kcontrol *kctl,
-   struct snd_ctl_elem_value *uctl)
-{
-  struct snd_cx18_card *cxsc = snd_kcontrol_chip(kctl);
-  struct cx18 *cx = to_cx18(cxsc-v4l2_dev);
-  struct v4l2_control vctrl;
-  int ret;
-
-  vctrl.id = V4L2_CID_AUDIO_VOLUME;
-  vctrl.value = dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-
-  snd_cx18_lock(cxsc);
-
-  /* Fetch current state */
-  ret = v4l2_subdev_call(cx-sd_av, core, g_ctrl, vctrl);
-
-  if (ret ||
-  (cx18_av_vol_to_dB(vctrl.value) !=
uctl-value.integer.value[0]))
{
-
-  /* Set, if needed */
-  vctrl.value =
dB_to_cx18_av_vol(uctl-value.integer.value[0]);
-  ret = v4l2_subdev_call(cx-sd_av, core, s_ctrl,
vctrl);
-  if (!ret)
-  ret = 1; /* Indicate control was changed w/o
error */
-  }
-  snd_cx18_unlock(cxsc);
-
-  return ret;
-}
-

/* This is a bit of overkill, the slider is already in dB internally
*/
static DECLARE_TLV_DB_SCALE(snd_cx18_mixer_tv_vol_db_scale, -9600,
100,
0);

 Really?  Did you try to compile the file after this patch?


http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/pci/cx18/cx18-alsa-mixer.c#n143

 They are referenced later in the same file.

 This is only half a fix.

  You can either remove the cx18-alsa-mixer.* files and from the build
system, or even better,you can hook-up and initialize these callbacks
with alsa so alsa mixer controls show up for cx18.  :)




Hi

Ok sorry :-(

Sure, I compile everything as allyesconfig, allmodconfig and
allnoconfig.

So snd_cx18_mixer_tv_volume_info is the same as
snd_cx18_mixer_tv_vol_info then.

Would gladly done something a little more concrete.
But first I want to see if as I can go through all of the
approximately 2000 functions that are not in use.


Kind regards
Rickard Strandqvist

Yes they are supposed to be the same.  It is dead code with typographical 
errors. So it is probably not even in the Makefile.

Regards,
Andy
--
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 05/11] cx25840/cx18: Use standard ordering of mask and shift

[Andy Walls]

On Sun, 2014-10-26 at 22:25 -0700, Joe Perches wrote:
 Precedence of  and  is not the same and is not left to right.
 shift has higher precedence and should be done after the mask.
 
 This use has a mask then shift which is not the normal style.
 
 Move the shift before the mask to match nearly all the other
 uses in kernel.
 
 Signed-off-by: Joe Perches j...@perches.com

The patch is technically correct.

Reviewed-by: Andy Walls awa...@md.metrocast.net

 ---
  drivers/media/i2c/cx25840/cx25840-core.c | 12 ++--
  drivers/media/pci/cx18/cx18-av-core.c| 16 
  2 files changed, 14 insertions(+), 14 deletions(-)
 
 diff --git a/drivers/media/i2c/cx25840/cx25840-core.c 
 b/drivers/media/i2c/cx25840/cx25840-core.c
 index e453a3f..0327032 100644
 --- a/drivers/media/i2c/cx25840/cx25840-core.c
 +++ b/drivers/media/i2c/cx25840/cx25840-core.c
 @@ -879,7 +879,7 @@ void cx25840_std_setup(struct i2c_client *client)
   /* Sets horizontal blanking delay and active lines */
   cx25840_write(client, 0x470, hblank);
   cx25840_write(client, 0x471,
 - 0xff  (((hblank  8)  0x3) | (hactive  4)));
 +   (((hblank  8)  0x3) | (hactive  4))  0xff);
   cx25840_write(client, 0x472, hactive  4);
  
   /* Sets burst gate delay */
 @@ -888,13 +888,13 @@ void cx25840_std_setup(struct i2c_client *client)
   /* Sets vertical blanking delay and active duration */
   cx25840_write(client, 0x474, vblank);
   cx25840_write(client, 0x475,
 - 0xff  (((vblank  8)  0x3) | (vactive  4)));
 +   (((vblank  8)  0x3) | (vactive  4))  0xff);
   cx25840_write(client, 0x476, vactive  4);
   cx25840_write(client, 0x477, vblank656);
  
   /* Sets src decimation rate */
 - cx25840_write(client, 0x478, 0xff  src_decimation);
 - cx25840_write(client, 0x479, 0xff  (src_decimation  8));
 + cx25840_write(client, 0x478, src_decimation  0xff);
 + cx25840_write(client, 0x479, (src_decimation  8)  0xff);
  
   /* Sets Luma and UV Low pass filters */
   cx25840_write(client, 0x47a, luma_lpf  6 | ((uv_lpf  4)  0x30));
 @@ -904,8 +904,8 @@ void cx25840_std_setup(struct i2c_client *client)
  
   /* Sets SC Step*/
   cx25840_write(client, 0x47c, sc);
 - cx25840_write(client, 0x47d, 0xff  sc  8);
 - cx25840_write(client, 0x47e, 0xff  sc  16);
 + cx25840_write(client, 0x47d, (sc  8)  0xff);
 + cx25840_write(client, 0x47e, (sc  16)  0xff);
  
   /* Sets VBI parameters */
   if (std  V4L2_STD_625_50) {
 diff --git a/drivers/media/pci/cx18/cx18-av-core.c 
 b/drivers/media/pci/cx18/cx18-av-core.c
 index 2d3afe0..45be26c 100644
 --- a/drivers/media/pci/cx18/cx18-av-core.c
 +++ b/drivers/media/pci/cx18/cx18-av-core.c
 @@ -490,8 +490,8 @@ void cx18_av_std_setup(struct cx18 *cx)
  
   /* Sets horizontal blanking delay and active lines */
   cx18_av_write(cx, 0x470, hblank);
 - cx18_av_write(cx, 0x471, 0xff  (((hblank  8)  0x3) |
 - (hactive  4)));
 + cx18_av_write(cx, 0x471,
 +   (((hblank  8)  0x3) | (hactive  4))  0xff);
   cx18_av_write(cx, 0x472, hactive  4);
  
   /* Sets burst gate delay */
 @@ -499,14 +499,14 @@ void cx18_av_std_setup(struct cx18 *cx)
  
   /* Sets vertical blanking delay and active duration */
   cx18_av_write(cx, 0x474, vblank);
 - cx18_av_write(cx, 0x475, 0xff  (((vblank  8)  0x3) |
 - (vactive  4)));
 + cx18_av_write(cx, 0x475,
 +   (((vblank  8)  0x3) | (vactive  4))  0xff);
   cx18_av_write(cx, 0x476, vactive  4);
   cx18_av_write(cx, 0x477, vblank656);
  
   /* Sets src decimation rate */
 - cx18_av_write(cx, 0x478, 0xff  src_decimation);
 - cx18_av_write(cx, 0x479, 0xff  (src_decimation  8));
 + cx18_av_write(cx, 0x478, src_decimation  0xff);
 + cx18_av_write(cx, 0x479, (src_decimation  8)  0xff);
  
   /* Sets Luma and UV Low pass filters */
   cx18_av_write(cx, 0x47a, luma_lpf  6 | ((uv_lpf  4)  0x30));
 @@ -516,8 +516,8 @@ void cx18_av_std_setup(struct cx18 *cx)
  
   /* Sets SC Step*/
   cx18_av_write(cx, 0x47c, sc);
 - cx18_av_write(cx, 0x47d, 0xff  sc  8);
 - cx18_av_write(cx, 0x47e, 0xff  sc  16);
 + cx18_av_write(cx, 0x47d, (sc  8)  0xff);
 + cx18_av_write(cx, 0x47e, (sc  16)  0xff);
  
   if (std  V4L2_STD_625_50) {
   state-slicer_line_delay = 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: staging: media: lirc: lirc_zilog.c: replace custom print macros with dev_* and pr_*

[Andy Walls]

On November 6, 2014 8:54:28 AM EST, Andy Walls awalls.c...@gmail.com wrote:
On November 6, 2014 8:21:13 AM EST, Sean Young s...@mess.org wrote:
On Thu, Nov 06, 2014 at 11:05:49AM -0200, Mauro Carvalho Chehab wrote:
 Hi Sean,
 
 Em Thu, 06 Nov 2014 12:46:29 +
 Sean Young s...@mess.org escreveu:
 
  On Fri, Oct 31, 2014 at 05:35:41PM +0300, Dan Carpenter wrote:
   On Fri, Oct 31, 2014 at 04:26:45PM +0200, Aya Mahfouz wrote:
On Fri, Oct 31, 2014 at 04:06:00PM +0300, Dan Carpenter wrote:
 drivers/staging/media/lirc/lirc_zilog.c
   1333  /* Close the IR device */
   1334  static int close(struct inode *node, struct file
*filep)
   1335  {
   1336  /* find our IR struct */
   1337  struct IR *ir = filep-private_data;
   1338  
   1339  if (ir == NULL) {
 ^^
   1340  dev_err(ir-l.dev, close: no
private_data attached to the file!\n);
 ^
 
 I suggest you just delete the error message.  Can ir
actually be NULL
 here anyway?


Since I'm a newbie and this is not my code, I prefer to use
pr_err().
   
   This driver doesn't belong to anyone.  Go ahead and take
ownership.  The
   message is fairly worthless and no one will miss it.
  
  Speaking of ownership, what this driver really needs is to be
ported to 
  rc-core. In order to do this it'll need to be able to send raw IR
rather
  key codes; I've been peering at the firmware but it neither looks
like
  zilog z8 opcodes nor space/pulse information.
 
 Actually, I think that all features provided by this driver were
already
 migrated into the ir-kbd-i2c (drivers/media/i2c/ir-kbd-i2c.c)
driver.

All the features for the IR receiver are implemented (very nicely) in
ir-kbd-i2c (the ir_rx_z8f0811_haup and ir_rx_z8f0811_hdpvr i2c
drivers).

However the IR emitter (i2c driver ir_tx_z8f0811_haup and 
ir_tx_z8f0811_hdpvr) are not implemented there. I wanted to port the 
IR emitter but the driver can only send specific rc5 (IIRC) keycodes,
not
raw IR. So I cannot port it.

 Andy and Jarod worked on this conversion, but we decided, on that
time,
 to keep lirc_zilog for a while (can't remember why).
 
 Andy/Jarod,
 
 What's the status of the ir-kbd-i2c with regards to Zilog z8
support?

Transmitter side.

  Does anyone have any contacts at Hauppauge who could help with
this?
 
 Probably, it won't be easy to get someone there that worked on it,
 as this device is too old.
 
 Anyway, if are there anything still pending, I may be able to get
 some contacts at the vendor.

That would be great, I have hardware and I'm happy to re-write the
driver.

Thanks

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

Sean,

Ir-kbd-i2c was never intended for Tx.

You can transmit *short* arbitrary pulse-space streams with the zilog
chip, by feeding it a parameter block that has the pulse timing
information and then subsequently has been obfuscated.  The firmware
file that LIRC uses in userspace is full of predefined versions of
these things for RC5 and NEC IIRC.  This LIRC firmware file also holds
the (de)obfuscation key.

I've got a bunch of old notes on this stuff from essentially reverse
engineering the firmware in the Z8.  IANAL, but to me, its use in
developing in-kernel stuff could be dubious.

Regards,
Andy

Resending as plain text for mailing list.
--
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: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

On October 26, 2014 1:50:36 AM EDT, Hans Verkuil hverk...@xs4all.nl wrote:
Hi Christopher,

On 10/26/2014 01:15 AM, Christopher Neufeld wrote:
 I've been using a PVR-500 to record shows in MythTV, and to capture
the VBI
 part of the stream from the standard-definition output of my STB when
it
 records high definition.  This has worked for about 7 years now.
 
 I recently updated my LinHES MythTV distribution, and part of the
update
 involved moving to a new kernel.  The old kernel went by the code
 3.6.7-1-ARCH, while the new one is 3.13.7-2-ARCH.
 
 With the updated kernel, my VBI captures no longer function.
 Standard-definition recordings made from MythTV using the PVR-500
before
 the update have caption data in the stream, those made after do not.
 
 The retrieval of caption data for high-definition shows involves some
 manual scripting to set the modes for the PVR-500, after which I run
 ccextractor on the V4L device node and just pull out the captions
data (the
 audio and video being output separately on high-definition outputs of
the
 STB, and captured by a HD-PVR).
 
 The script that I use to set up captions invokes this command:
 v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc
--set-ctrl=stream_vbi_format=1
 
 This now errors out.  Part of that is a parsing bug in v4l2-ctl, it
wants
 to see more text after the 'cc'.  I can change it to 
 v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc=1
--set-ctrl=stream_vbi_format=1

This is a v4l2-ctl bug. I'll fix that asap. But using cc=1 is a valid
workaround.

 
 with this change, it no longer complains about the command line, but
it
 errors out in the ioctls.  This behaviour is seen with three versions
of
 v4l2-ctl: the old one packaged with the old kernel, the new one
packaged
 with the newer kernel, and the git-head, compiled against the headers
of
 the new kernel.

Are you calling this when MythTV is already running? If nobody else is
using
the PVR-500, does it work?

 
 I strace-d the v4l2-ctl command.  The relevant output is:
 open(/dev/pvr_500_1, O_RDWR)  = 3
 ioctl(3, VIDIOC_QUERYCAP or VT_OPENQRY, 0x7fff836aac10) = 0
 ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
 ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
 brk(0)  = 0x12ca000
 brk(0x12eb000)  = 0x12eb000
 ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
  PREVIOUS LINE REPEATS 41 TIMES
 ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = 0
 ioctl(3, VIDIOC_QUERYCTRL, 0x7fff836aaa70) = -1 EINVAL (Invalid
argument)
 ioctl(3, VIDIOC_S_FMT or VT_RELDISP, 0x62eae0) = -1 EINVAL (Invalid
argument)
 fstat(1, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 0), ...}) = 0
 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
0) = 0x7fe8233bf000
 write(1, VIDIOC_S_FMT: failed: Invalid ar..., 39VIDIOC_S_FMT:
failed: Invalid argument
 ) = 39
 close(3)= 0
 exit_group(-1)  = ?
 
 I did once see VBI data arriving from one of the paired devices in
the
 PVR-500, and not from the other.  I would guess that to be because it
 started up in that state.  When this happened, I ran v4l2-ctl --all
on both
 devices, captured the output, and stored it to files.  I did not see
any
 relevent differences in these outputs, but I present the diff here:
 
 --- file1   2014-10-25 13:40:36.698703171 -0400
 +++ file2   2014-10-25 13:40:41.248614481 -0400
 @@ -1,15 +1,14 @@
  Driver Info (not using libv4l2):
 Driver name   : ivtv
 -   Card type : WinTV PVR 500 (unit #1)
 -   Bus info  : PCI::06:08.0
 +   Card type : WinTV PVR 500 (unit #2)
 +   Bus info  : PCI::06:09.0
 Driver version: 3.13.7
 -   Capabilities  : 0x81070051
 +   Capabilities  : 0x81030051
 Video Capture
 VBI Capture
 Sliced VBI Capture
 Tuner
 Audio
 -   Radio
 Read/Write
 Device Capabilities
 Device Caps   : 0x01030001
 @@ -18,7 +17,7 @@
 Audio
 Read/Write
  Priority: 2
 -Frequency for tuner 0: 4148 (259.25 MHz)
 +Frequency for tuner 0: 884 (55.25 MHz)
  Tuner 0:
 Name : ivtv TV Tuner
 Capabilities : 62.5 kHz multi-standard stereo lang1
lang2 freq-bands 
 
 
 The fact that I once saw valid VBI data suggests that the driver is
still
 capable of the feature, but something about the ioctl invocations in
 v4l2-ctl and in MythTV 0.27.4 is wrong for getting the driver
reliably into
 the state where VBI data is present in the stream coming from the
device.

I won't be able to test this myself until next weekend at the earliest.
Andy, are you able to look at this?

Regards,

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

Re: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

Hi Chris,

On Sun, 2014-10-26 at 08:10 -0400, Christopher Neufeld wrote:
 Hello Hans,
 
 On Sun, 26 Oct 2014 06:50:36 +0100, Hans Verkuil hverk...@xs4all.nl said:
 
  The script that I use to set up captions invokes this command:
  v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1
  
  This now errors out.  Part of that is a parsing bug in v4l2-ctl, it wants
  to see more text after the 'cc'.  I can change it to 
  v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc=1 --set-ctrl=stream_vbi_format=1
 
  This is a v4l2-ctl bug. I'll fix that asap. But using cc=1 is a valid 
  workaround.
 
  
  with this change, it no longer complains about the command line, but it
  errors out in the ioctls.  This behaviour is seen with three versions of
  v4l2-ctl: the old one packaged with the old kernel, the new one packaged
  with the newer kernel, and the git-head, compiled against the headers of
  the new kernel.

Can you verify that 

v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format

also fails, and that

v4l2-ctl --list-devices
v4l2-ctl -d /dev/vbiN --set-fmt-sliced-vbi=cc=1 
--set-ctrl=stream_vbi_format=1
v4l2-ctl -d /dev/vbiN --get-fmt-sliced-vbi 
--get-ctrl=stream_vbi_format

both succeed on the corresponding vbi node?

Looking at the v3.16 kernel code that I'm compiling right now, it looks
like extra checks put in the v4l2-core don't allow setting sliced VBI
formats using video device nodes:

http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-vbi.cpp#n209
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n959
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1192
http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1265

I have to actually install and test, but this is my current guess.

If you can use the /dev/vbiN node as a work-around, please do.

Regards,
Andy

  Are you calling this when MythTV is already running? If nobody else is using
  the PVR-500, does it work?
 
 When my script is running, MythTV is not using that unit of the PVR-500.  I
 use the recording groups feature to ensure that that unit is made
 unavailable for recordings whenever high-definition recordings are being
 made.  The details of what I'm doing can be found here:
 https://www.mythtv.org/wiki/Captions_With_HD_PVR
 
 I would not expect this command to succeed if the unit were in use, in fact
 the script detects that as an error case and loops until the device is
 free.  The v4l2-ctl command that I use has historically returned an error
 if somebody had the unit's video device open for reading.  Now, though, it
 errors even when the unit is unused.
 
 For my script, it is necessary that the MythTV backend be running, the
 script is invoked by the backend, but when it is invoked, nobody is using
 that unit of the PVR-500 (and, in practice, the other unit is almost never
 used, as it's quite rare that I make standard-definition recordings).
 
 My script is not used when MythTV directly makes a standard-definition
 recording from the PVR-500.  In that case, the program presumably issues
 its own ioctl equivalents of the v4l2-ctl command, and those are not
 working, because the recordings produced do not have VBI data, while those
 recorded before the kernel upgrade do.
 
  I won't be able to test this myself until next weekend at the earliest.
 
 Captions are mostly for my wife's benefit, and I checked, most of her
 upcoming shows are being recorded from OTA broadcasts, which provide ATSC
 captions independently of the PVR-500, so I can wait for a week or two.
 
 
 Thank you for looking into this.
 


--
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: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

On Sun, 2014-10-26 at 13:41 -0400, Andy Walls wrote:
 Hi Chris,
 
 On Sun, 2014-10-26 at 08:10 -0400, Christopher Neufeld wrote:
  Hello Hans,
  
  On Sun, 26 Oct 2014 06:50:36 +0100, Hans Verkuil hverk...@xs4all.nl said:
  
   The script that I use to set up captions invokes this command:
   v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc --set-ctrl=stream_vbi_format=1
   
   This now errors out.  Part of that is a parsing bug in v4l2-ctl, it wants
   to see more text after the 'cc'.  I can change it to 
   v4l2-ctl -d DEV --set-fmt-sliced-vbi=cc=1 
   --set-ctrl=stream_vbi_format=1
  
   This is a v4l2-ctl bug. I'll fix that asap. But using cc=1 is a valid 
   workaround.
  
   
   with this change, it no longer complains about the command line, but it
   errors out in the ioctls.  This behaviour is seen with three versions of
   v4l2-ctl: the old one packaged with the old kernel, the new one packaged
   with the newer kernel, and the git-head, compiled against the headers of
   the new kernel.
 
 Can you verify that 
 
   v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format
 
 also fails, and that
 
   v4l2-ctl --list-devices
   v4l2-ctl -d /dev/vbiN --set-fmt-sliced-vbi=cc=1 
 --set-ctrl=stream_vbi_format=1
   v4l2-ctl -d /dev/vbiN --get-fmt-sliced-vbi 
 --get-ctrl=stream_vbi_format
 
 both succeed on the corresponding vbi node?
 
 Looking at the v3.16 kernel code that I'm compiling right now, it looks
 like extra checks put in the v4l2-core don't allow setting sliced VBI
 formats using video device nodes:
 
 http://git.linuxtv.org/cgit.cgi/v4l-utils.git/tree/utils/v4l2-ctl/v4l2-ctl-vbi.cpp#n209
 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n959
 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1192
 http://git.linuxtv.org/cgit.cgi/media_tree.git/tree/drivers/media/v4l2-core/v4l2-ioctl.c#n1265
 
 I have to actually install and test, but this is my current guess.

FWIW, those checks were introduced in this commit:
http://git.linuxtv.org/cgit.cgi/media_tree.git/commit/?id=4b20259fa642d6f7a2dabef0b3adc14ca9dadbde

Hans,
I'm inclined to say these checks are good things, but they did break
existing behavior for user scripts and apps at about kernel v3.7 AFAICT.

FYI, MythTV has already worked around it:
https://code.mythtv.org/trac/ticket/11723
https://github.com/MythTV/mythtv/commit/25310069a1154213cbc94c903c8b0ace30893ec4

But I don't know about any other apps.

Regards,
Andy

 If you can use the /dev/vbiN node as a work-around, please do.
 
 Regards,
 Andy
 
   Are you calling this when MythTV is already running? If nobody else is 
   using
   the PVR-500, does it work?
  
  When my script is running, MythTV is not using that unit of the PVR-500.  I
  use the recording groups feature to ensure that that unit is made
  unavailable for recordings whenever high-definition recordings are being
  made.  The details of what I'm doing can be found here:
  https://www.mythtv.org/wiki/Captions_With_HD_PVR
  
  I would not expect this command to succeed if the unit were in use, in fact
  the script detects that as an error case and loops until the device is
  free.  The v4l2-ctl command that I use has historically returned an error
  if somebody had the unit's video device open for reading.  Now, though, it
  errors even when the unit is unused.
  
  For my script, it is necessary that the MythTV backend be running, the
  script is invoked by the backend, but when it is invoked, nobody is using
  that unit of the PVR-500 (and, in practice, the other unit is almost never
  used, as it's quite rare that I make standard-definition recordings).
  
  My script is not used when MythTV directly makes a standard-definition
  recording from the PVR-500.  In that case, the program presumably issues
  its own ioctl equivalents of the v4l2-ctl command, and those are not
  working, because the recordings produced do not have VBI data, while those
  recorded before the kernel upgrade do.
  
   I won't be able to test this myself until next weekend at the earliest.
  
  Captions are mostly for my wife's benefit, and I checked, most of her
  upcoming shows are being recorded from OTA broadcasts, which provide ATSC
  captions independently of the PVR-500, so I can wait for a week or two.
  
  
  Thank you for looking into this.
  
 
 
 --
 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: VBI on PVR-500 stopped working between kernels 3.6 and 3.13

[Andy Walls]

On October 26, 2014 5:35:30 PM EDT, Christopher Neufeld 
media-al...@cneufeld.ca wrote:
Andy,

On Sun, 26 Oct 2014 13:41:14 -0400, Andy Walls
awa...@md.metrocast.net said:

 Can you verify that 

  v4l2-ctl -d DEV --get-fmt-sliced-vbi --get-ctrl=stream_vbi_format

 also fails, and that

Yes, that also fails.

  v4l2-ctl --list-devices
  v4l2-ctl -d /dev/vbiN --set-fmt-sliced-vbi=cc=1
--set-ctrl=stream_vbi_format=1
  v4l2-ctl -d /dev/vbiN --get-fmt-sliced-vbi
--get-ctrl=stream_vbi_format

 both succeed on the corresponding vbi node?

Yes, those succeed.  So, that solves my problem, thank you.

 If you can use the /dev/vbiN node as a work-around, please do.

I will switch to doing that, and update the MythTV wiki appropriately. 
I
assume that this is the correct invocation for any similar capture
devices,
not just the PVR-500 and family.


On Sun, 26 Oct 2014 14:28:15 -0400, Andy Walls
awa...@md.metrocast.net said:

 FYI, MythTV has already worked around it:
 https://code.mythtv.org/trac/ticket/11723

https://github.com/MythTV/mythtv/commit/25310069a1154213cbc94c903c8b0ace30893ec4

Ah, well then that part of my bug report was incorrect.  Sometimes
shows
don't send caption data, even the same program one week later.  I
happened
to have two recordings in standard definition that had no captions, but
one
recorded last night did, as might be expected if MythTV already worked
around it.

Thank you for your time on this, Andy and Hans.  I will update my
scripts,
and this will work perfectly for me.

Hi Chris,

Well, I didn't look at MythTV's logic for finding the correct vbi device.  You 
might not get captions from MythTV recordings, if it guessed the wrong vbi node 
or if it didn't have sufficient permissions to access the vbi node.

Regards,
Andy
--
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: strange empia device

[Andy Walls]

On September 2, 2014 2:28:23 AM EDT, Lorenzo Marcantonio 
l.marcanto...@logossrl.com wrote:
On Mon, Sep 01, 2014 at 07:58:52PM -0400, Andy Walls wrote:
 A Merlin firmware of 16 kB strongly suggests that this chip has an
 integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
 Broadtcast A/V decoder core.  The chip might only have a Merlin
 integrated, but so far I've never encountered that.  It will be easy
 enough to tell, if the Thresher registers don't respond or only
respond
 with junk.

However I strongly suspect that these drivers are for a whole *family*
of empia device. The oem ini by roxio talks about three different
parts... probably they give one sys file for everyone and the oem
customizes the ini.

In short the merlin fw may not be actually used for *this* part but
only
for other empia devices/configurations.

Otherwise I wonder *why* a fscking 1.5MB of sys driver for a mostly
dumb
capture device...

Yeah.  I guess you can analyze the USB captures of the Windows driver and see 
if it looks like cx25843 registers are being accessed.  If so, you are that 
much closer to a working linux driver.  If not, you still have an unknown 
decoder as a big hurdle.

Regards,
Andy
--
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: strange empia device

[Andy Walls]

On Sun, 2014-08-31 at 16:47 +0200, Frank Schäfer wrote:
 Hi Lorenzo,
 
 Am 25.08.2014 um 21:01 schrieb Lorenzo Marcantonio:
  Just bought a roxio video capture dongle. Read around that it was an
  easycap clone (supported, then); it seems it's not so anymore :(
 
  It identifies as 1b80:e31d Roxio Video Capture USB
 
  (it also uses audio class for audio)
 
  Now comes the funny thing. Inside there is the usual E2P memory,
  a regulator or two and an empia marked EM2980 (*not* em2890!); some
  passive and nothing else.
 
  Digging around in the driver cab (emBDA.inf) shows that it seems an
  em28285 driver rebranded by roxio... it installs emBDAA.sys and
  emOEMA.sys (pretty big: about 1.5MB combined!); also a 16KB merlinFW.rom
  (presumably a firmware for the em chip? 

A Merlin firmware of 16 kB strongly suggests that this chip has an
integarted Conexant CX25843 (Merlin Audio + Thresher Video = Mako)
Broadtcast A/V decoder core.  The chip might only have a Merlin
integrated, but so far I've never encountered that.  It will be easy
enough to tell, if the Thresher registers don't respond or only respond
with junk.

The Merlin has an integrated 8051 microcontroller that, if you are
decoding SIF audio from an analog tuner, will periodically reprogram
registers in the Merlin core to do spectral analysis of the SIF to
determine the broadcast audio standard (BTSC, etc.).

A public datasheet for the CX25843 is here:
http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf

There appear to be at least two families of CX25843 cores:

- the core in the stand-alone CX2584[0123] chips and the '843 core
integrated into the CX23418

- the core integrated into the CX2388[578] and CX2310[012] chips, which
have a slightly different register defintion in some places 


The cx25840 driver under linux handles most of these, except that the
cx18 driver has it's own fork of the cx25840 driver in its cx18-av-*
files.  The core is normally I2C connected, except for the one
integrated into the CX23418.

If the empia device driver needs to support a CX25843 core, I highly
recommend forking a copy of the cx25840 driver specifically for the
empia devices, as opposed to trying to fit in yet another variant in the
cx25840 driver itself. 

FWIW, since the CX2310[012] devices are also USB connected, maybe that
driver can provide some basis for comparison along with the USB traces
you already have.  (I haven't compared them myself.)

Regards,
Andy

  I tought they were fixed
  function); also the usual directshow .ax filter and some exe in
  autorun (emmona.exe: firmware/setup loader?).
 
  Looking in the em28xx gave me the idea that that thing is not
  supported (at least in my current 3.6.6)... however the empia sites says
  (here http://www.empiatech.com/wp/video-grabber-em282xx/) 28284 should
  be linux supported. Nothing said about 28285. And the chip is marked
  2980?! by the way, forcing the driver to load I get this:
 
  [ 3439.787701] em28xx: New device  Roxio Video Capture USB @ 480 Mbps 
  (1b80:e31d, interface 0, class 0)
  [ 3439.787704] em28xx: Video interface 0 found
  [ 3439.787705] em28xx: DVB interface 0 found
  [ 3439.787866] em28xx #0: em28xx chip ID = 146
 
  Is there any hope to make it work (even on git kernel there is nothing
  for chip id 146...)?
 
 
 See http://www.spinics.net/lists/linux-media/msg73699.html
 
 HTH,
 Frank
 --
 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

Fwd: Re: CX23885 error during boot

[Andy Walls]

Dear Media Community:
  Since switching to CentOS7 and the 3.10.0-123 kernel as listed below:
 Linux mythbox.lightfoot.us 3.10.0-123.6.3.el7.x86_64 #1 SMP Wed Aug
 6 21:12:36 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

   I keep getting the following in dmesg related to my Hauppage Video
Card at bootup.  The error seems to have no affect on operation, but I
am curious if there is something to be done to resolve it?

You have the wrong firmware image for the CX23417 MPEG encoder chip connected 
to the CX23885.  Update it to the proper file.  If you dont use the card for 
compressed analog video, it doesnt matter.

Regards,
Andy
--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

[Andy Walls]

On August 1, 2014 11:33:26 AM EDT, Antti Palosaari cr...@iki.fi wrote:


On 08/01/2014 06:19 PM, Antonio Ospite wrote:
 On Fri, 01 Aug 2014 12:14:15 +0200
 Hans Verkuil hverk...@xs4all.nl wrote:

 On 07/31/2014 09:16 PM, Andy Walls wrote:
 On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com

 [..]
 +- Improve the sinus generation of the SDR radio.

 Maybe a lookup table, containing the first quarter wave of cos()
from 0
 to pi/2 in pi/200 steps, and then linear interpolation for cos() of
 angles in between those steps.  You could go with a larger lookup
table
 with finer grained steps to reduce the approximation errors.  A
lookup
 table with linear interpolation, I would think, requires fewer
 mutliplies and divides than the current Taylor expansion
computation.

 Yeah, I had plans for that. There actually is a sine-table already
in vivid-tpg.c
 since I'm using that to implement Hue support.


 I don't know what your requirements are here but JFTR there is
already a
 simplistic implementation of fixed point operations in
 include/linux/fixp-arith.h I used them in
 drivers/media/usb/gspca/ov534.c for some hue calculation.

I looked that too, but there was very small LUT = very bad resolution.

So I ended up copying sin/cos from cx88 driver (Taylor method).

regards
Antti

I was thinking of implementing a fixed point sine based on the quintic 
polynomial approximation of sin (pi/2 * x) described here:

http://www.coranac.com/2009/07/sines/

since I wanted to learn fixed point stuff anyway.

But probably -ENOTIME .

Regards,
Andy
--
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: [PATCHv1 02/12] vivid.txt: add documentation for the vivid driver.

[Andy Walls]

On Wed, 2014-07-30 at 16:23 +0200, Hans Verkuil wrote:
 From: Hans Verkuil hans.verk...@cisco.com
 
 The vivid Virtual Video Test Driver helps testing V4L2 applications
 and can emulate V4L2 hardware. Add the documentation for this driver
 first.
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  Documentation/video4linux/vivid.txt | 1108 
 +++
  1 file changed, 1108 insertions(+)
  create mode 100644 Documentation/video4linux/vivid.txt
 
 diff --git a/Documentation/video4linux/vivid.txt 
 b/Documentation/video4linux/vivid.txt
 new file mode 100644
 index 000..2dc7354
 --- /dev/null
 +++ b/Documentation/video4linux/vivid.txt
 @@ -0,0 +1,1108 @@
 +vivid: Virtual Video Test Driver
 +

 +
 +Section 8: Software Defined Radio Receiver
 +--
 +
 +The SDR receiver has three frequency bands for the ADC tuner:
 +
 + - 300 kHz
 + - 900 kHz - 2800 kHz
 + - 3200 kHz
 +
 +The RF tuner supports 50 MHz - 2000 MHz.
 +
 +The generated data contains sinus and cosinus signals.
 +

In (American) English the names are sine and cosine for sin(x) and
cos(x).

Maybe say:

The generated data contains the In-phase and Quadrature components of a
1 kHz tone that has an amplitude of sqrt(2).

FWIW, the signals are the In-phase and Quadrature components of the
signal A*cos(2*pi*f + phi), where f = 1 kHz, A = sqrt(2), and phi =
-pi/4

 +
 +Section 15: Some Future Improvements
 +
 +
 +Just as a reminder and in no particular order:
 +
 +- Add a virtual alsa driver to test audio
 +- Add virtual sub-devices and media controller support
 +- Some support for testing compressed video
 +- Add support to loop raw VBI output to raw VBI input
 +- Fix sequence/field numbering when looping of video with alternate fields
 +- Add support for V4L2_CID_BG_COLOR for video outputs
 +- Add ARGB888 overlay support: better testing of the alpha channel
 +- Add custom DV timings support
 +- Add support for V4L2_DV_FL_REDUCED_FPS
 +- Improve pixel aspect support in the tpg code by passing a real v4l2_fract
 +- Use per-queue locks and/or per-device locks to improve throughput
 +- Add support to loop from a specific output to a specific input across
 +  vivid instances
 +- Add support for VIDIOC_EXPBUF once support for that has been added to vb2
 +- The SDR radio should use the same 'frequencies' for stations as the normal
 +  radio receiver, and give back noise if the frequency doesn't match up with
 +  a station frequency
 +- Improve the sinus generation of the SDR radio.

Maybe a lookup table, containing the first quarter wave of cos() from 0
to pi/2 in pi/200 steps, and then linear interpolation for cos() of
angles in between those steps.  You could go with a larger lookup table
with finer grained steps to reduce the approximation errors.  A lookup
table with linear interpolation, I would think, requires fewer
mutliplies and divides than the current Taylor expansion computation.


 +- Make a thread for the RDS generation, that would help in particular for the
 +  Controls RDS Rx I/O Mode as the read-only RDS controls could be updated
 +  in real-time.

Regards,
Andy

--
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: Best way to add subdev that doesn't use I2C or SPI?

[Andy Walls]

On June 20, 2014 9:58:19 PM EDT, Devin Heitmueller 
dheitmuel...@kernellabs.com wrote:
Hello,

I'm in the process of adding support for a new video decoder.  However
in this case it's an IP block on a USB bridge as opposed to the
typical case which is an I2C device.  Changing registers for the
subdev is the same mechanism as changing registers in the rest of the
bridge (a specific region of registers is allocated for the video
decoder).

Doing a subdev driver seems like the logical approach to keep the
video decoder related routines separate from the rest of the bridge.
It also allows the reuse of the code if we find other cases where the
IP block is present in other devices.  However I'm not really sure
what the mechanics are for creating a subdev that isn't really an I2C
device.

I think we've had similar cases with the Conexant parts where the Mako
was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx).
But in that case the cx25840 subdev just issues I2C commands and
leverages the fact that you can talk to the parts over I2C even though
they're really on-chip.

Are there any other cases today where we have a subdev that uses
traditional register access routines provided by the bridge driver to
read/write the video decoder registers?  In this case I would want to
reuse the register read/write routines provided by the bridge, which
ultimately are send as USB control messages.

Any suggestions welcome (and in particular if you can point me to an
example case where this is already being done).

Thanks in advance,

Devin

cx23888-ir
cx18-av
cx18-gpio

I have a nonreleased one that uses SPI as well if you need an example of that.

Regards,
Andy
--
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: Best way to add subdev that doesn't use I2C or SPI?

[Andy Walls]

On June 21, 2014 7:17:07 AM EDT, Andy Walls awa...@md.metrocast.net wrote:
On June 20, 2014 9:58:19 PM EDT, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
Hello,

I'm in the process of adding support for a new video decoder.  However
in this case it's an IP block on a USB bridge as opposed to the
typical case which is an I2C device.  Changing registers for the
subdev is the same mechanism as changing registers in the rest of the
bridge (a specific region of registers is allocated for the video
decoder).

Doing a subdev driver seems like the logical approach to keep the
video decoder related routines separate from the rest of the bridge.
It also allows the reuse of the code if we find other cases where the
IP block is present in other devices.  However I'm not really sure
what the mechanics are for creating a subdev that isn't really an I2C
device.

I think we've had similar cases with the Conexant parts where the Mako
was actually a block on the main bridge (i.e. cx23885/7/8, cx231xx).
But in that case the cx25840 subdev just issues I2C commands and
leverages the fact that you can talk to the parts over I2C even though
they're really on-chip.

Are there any other cases today where we have a subdev that uses
traditional register access routines provided by the bridge driver to
read/write the video decoder registers?  In this case I would want to
reuse the register read/write routines provided by the bridge, which
ultimately are send as USB control messages.

Any suggestions welcome (and in particular if you can point me to an
example case where this is already being done).

Thanks in advance,

Devin

cx23888-ir
cx18-av
cx18-gpio

I have a nonreleased one that uses SPI as well if you need an example
of that.

Regards,
Andy
--
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

I should mention that cx23888-ir and cx23885-ir both bring up interesting 
issues with IRQ handling and reuse.

Regarding interrupts:

cx23888-ir does all its interrupt handling work in the hard IRQ context; 
because it can, but it shouldn't. 

cx23885-ir uses a work queue to defer interrupt handling work, but that's not 
optimal for RT, as you can't tune concurrency managed work queue handler 
priorities for your work items.

Both should really be using a threaded IRQ handler.  That makes deferring work 
easy and tuning RT priority easy.


Regarding resue:

Both are using the same watermark level for triggering interrupts even though 
response times for direct vs. I2c connected is different. Also the IRQ mask 
registers between the block versions are inverted.  These sorts of things 
amount in code reuse pains.

Regards,
Andy
--
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: bttv and colorspace

[Andy Walls]

On Fri, 2014-06-20 at 09:07 +0200, Hans Verkuil wrote:
 Hi Mauro,
 
 I wonder if you remember anything about the reported broken colorspace 
 handling
 of bttv. The spec talks about V4L2_COLORSPACE_BT878 where the Y range is 
 16-253
 instead of the usual 16-235.
 
 I downloaded a bt878 datasheet and that mentions the normal 16-235 range.
 
 I wonder if this was perhaps a bug in older revisions of the bt878. Do you
 remember anything about this?

I have a Rockwell datasheet for the BrookTree 878/879 that has the Y
16-253 (16 is the pedestal level) and Cr/Cb 2-253 on page 118.

I will email to you off list.

Regards,
Andy 


  I plan on doing some tests with my bttv cards
 next week.
 
 The main reason I'm interested in this is that I am researching the colorspace
 handling in v4l2 (and how it is defined in the spec). That needs to be nailed
 down because today nobody really knows how it is supposed to work and it is a
 complicated topic.
 
 Regards,
 
   Hans
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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: Conexant PCI-8604PW 4 channel BNC Video capture card (bttv)

[Andy Walls]

Robert Longbottom rongb...@googlemail.com wrote:

Hi,

I've just bought one of these cards which is based on the Conexant
Fusion 878A chip thinking it would just work under Linux being
bttv-based.  Unfortunately (for me) it's not and it is just picked up
as
a generic unknown card by the bttv driver.

Does anyone have one of these that is working, or have any pointers to
what I can try to make it work?  I've had a go manually specifying
card=
as a module option for a couple of the existing cards that also use the
Conexant Fusion chip but neither work (BTTV_BOARD_PICOLO_TETRA_CHIP and
BTTV_BOARD_GEOVISION_GV800S).

When I start up xawtv and switch to framegrabber mode I just get lots
of
errors in /var/log/messages saying:

Jan 20 21:09:13 quad kernel: [ 2732.616016] bttv: 0: timeout: drop=0
irq=2998/35891, risc=339d5000, bits: HSYNC
Jan 20 21:09:13 quad kernel: [ 2733.122014] bttv: 0: timeout: drop=0
irq=3028/35952, risc=339d5000, bits: HSYNC
Jan 20 21:09:14 quad kernel: [ 2733.625018] bttv: 0: timeout: drop=0
irq=3058/36015, risc=339d5000, bits: HSYNC
Jan 20 21:09:14 quad kernel: [ 2734.127014] bttv: 0: timeout: drop=0
irq=3088/36077, risc=339d5000, bits: HSYNC
Jan 20 21:09:15 quad kernel: [ 2734.628014] bttv: 0: timeout: drop=0
irq=3118/36140, risc=339d5000, bits: HSYNC

Any help appreciated.  More info about the card below.
Thanks,
Rob.

Chips on card:

4x Conexant Fusion 878A
1x PCI6140-AA33PC
1x SMD IC with no markings at all
Couple of 74HCTnnn chips
1x Atmel 520
1x 35.46895M Crystal

Result of modprobe bttv:

Jan 20 20:07:07 quad kernel: [ 8490.076924] bttv: driver version 0.9.19
loaded
Jan 20 20:07:07 quad kernel: [ 8490.076930] bttv: using 8 buffers with
2080k (520 pages) each for capture
Jan 20 20:07:07 quad kernel: [ 8490.076983] bttv: Bt8xx card found (0)
Jan 20 20:07:07 quad kernel: [ 8490.077001] bttv: 0: Bt878 (rev 17) at
:02:0c.0, irq: 16, latency: 32, mmio: 0xd500
Jan 20 20:07:07 quad kernel: [ 8490.077033] bttv: 0: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.109816] bttv: 0: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.110099] bttv: 0: registered device
video0
Jan 20 20:07:07 quad kernel: [ 8490.110485] bttv: 0: registered device
vbi0
Jan 20 20:07:07 quad kernel: [ 8490.114206] bttv: Bt8xx card found (1)
Jan 20 20:07:07 quad kernel: [ 8490.114228] bttv: 1: Bt878 (rev 17) at
:02:0d.0, irq: 17, latency: 32, mmio: 0xd5002000
Jan 20 20:07:07 quad kernel: [ 8490.114279] bttv: 1: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.116288] tveeprom 5-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.116296] bttv: 1: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.116393] bttv: 1: registered device
video1
Jan 20 20:07:07 quad kernel: [ 8490.116589] bttv: 1: registered device
vbi1
Jan 20 20:07:07 quad kernel: [ 8490.120104] bttv: Bt8xx card found (2)
Jan 20 20:07:07 quad kernel: [ 8490.120135] bttv: 2: Bt878 (rev 17) at
:02:0e.0, irq: 18, latency: 32, mmio: 0xd5004000
Jan 20 20:07:07 quad kernel: [ 8490.120165] bttv: 2: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.121031] tveeprom 6-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.121035] bttv: 2: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.121090] bttv: 2: registered device
video2
Jan 20 20:07:07 quad kernel: [ 8490.121226] bttv: 2: registered device
vbi2
Jan 20 20:07:07 quad kernel: [ 8490.124682] bttv: Bt8xx card found (3)
Jan 20 20:07:07 quad kernel: [ 8490.124714] bttv: 3: Bt878 (rev 17) at
:02:0f.0, irq: 19, latency: 32, mmio: 0xd5006000
Jan 20 20:07:07 quad kernel: [ 8490.124744] bttv: 3: using:  ***
UNKNOWN/GENERIC ***  [card=0,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.125739] tveeprom 7-0050: Huh, no
eeprom present (err=-6)?
Jan 20 20:07:07 quad kernel: [ 8490.125745] bttv: 3: tuner type unset
Jan 20 20:07:07 quad kernel: [ 8490.125842] bttv: 3: registered device
video3
Jan 20 20:07:07 quad kernel: [ 8490.126063] bttv: 3: registered device
vbi3
Jan 20 20:07:07 quad kernel: [ 8490.130127] bttv: Bt8xx card found (4)
Jan 20 20:07:07 quad kernel: [ 8490.130151] bttv: 4: Bt878 (rev 17) at
:03:04.0, irq: 17, latency: 32, mmio: 0xd510
Jan 20 20:07:07 quad kernel: [ 8490.130182] bttv: 4: detected: IVC-200
[card=102], PCI subsystem ID is :a155
Jan 20 20:07:07 quad kernel: [ 8490.130186] bttv: 4: using: IVC-200
[card=102,autodetected]
Jan 20 20:07:07 quad kernel: [ 8490.130283] bttv: 4: tuner absent
Jan 20 20:07:07 quad kernel: [ 8490.130473] bttv: 4: registered device
video4
Jan 20 20:07:07 quad kernel: [ 8490.130512] bttv: 4: registered device
vbi4
Jan 20 20:07:07 quad kernel: [ 8490.130534] bttv: 4: Setting PLL:
28636363 = 35468950 (needs up to 100ms)
Jan 20 20:07:07 quad kernel: [ 8490.136550] bttv: 4: Setting PLL:
28636363 = 35468950 (needs up to 100ms)
Jan 20 20:07:07 quad kernel: [ 8490.139121] bttv: 4: 

Re: [PATCH] [media] cx18: introduce a helper function to avoid array overrun

[Andy Walls]

On Fri, 2014-01-10 at 14:06 +0100, Hans Verkuil wrote:
 Also CC to linux-media and Andy Walls who maintains this driver.
 
 Regards,
 
   Hans
 
 On 01/06/14 16:07, Ethan Zhao wrote:
  cx18_i2c_register() is called in cx18_init_subdevs() with index
  greater than length of hw_bus array, that will cause array overrun,
  introduce a helper cx18_get_max_bus_num() to avoid it.
  
  V2: fix a typo and use ARRAY_SIZE macro
  
  Signed-off-by: Ethan Zhao ethan.ker...@gmail.com

Hi Ethan,

There is no need for this change.  See below.

  ---
   drivers/media/pci/cx18/cx18-driver.c | 2 +-
   drivers/media/pci/cx18/cx18-i2c.c| 5 +
   drivers/media/pci/cx18/cx18-i2c.h| 1 +
   3 files changed, 7 insertions(+), 1 deletion(-)
  
  diff --git a/drivers/media/pci/cx18/cx18-driver.c 
  b/drivers/media/pci/cx18/cx18-driver.c
  index 6386ced..dadcd4a 100644
  --- a/drivers/media/pci/cx18/cx18-driver.c
  +++ b/drivers/media/pci/cx18/cx18-driver.c
  @@ -856,7 +856,7 @@ static void cx18_init_subdevs(struct cx18 *cx)
  u32 device;
  int i;
   
  -   for (i = 0, device = 1; i  32; i++, device = 1) {
  +   for (i = 0, device = 1; i  cx18_get_max_bus_num(); i++, device = 1) {
   
  if (!(device  hw))
  continue;

This check of !(device  hw) already does the bounds check.  Card
specific, I2C device presence flags are statically compiled into the
driver in cx18-cards.c and are used in this check.

The ivtv driver does the same sort of check in
ivtv-driver.c:ivtv_load_and_init_modules().

Both the cx18 and ivtv drivers are very mature, so I don't want any
unecessary code churn in them to address non-problems.

Regards,
Andy

  diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
  b/drivers/media/pci/cx18/cx18-i2c.c
  index 4af8cd6..1a7b49b 100644
  --- a/drivers/media/pci/cx18/cx18-i2c.c
  +++ b/drivers/media/pci/cx18/cx18-i2c.c
  @@ -108,6 +108,11 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct 
  i2c_adapter *adap, u32 hw,
 -1 : 0;
   }
   
  +int cx18_get_max_bus_num(void)
  +{
  +   return ARRAY_SIZE(hw_bus);
  +}
  +
   int cx18_i2c_register(struct cx18 *cx, unsigned idx)
   {
  struct v4l2_subdev *sd;
  diff --git a/drivers/media/pci/cx18/cx18-i2c.h 
  b/drivers/media/pci/cx18/cx18-i2c.h
  index 1180fdc..6f2ceb5 100644
  --- a/drivers/media/pci/cx18/cx18-i2c.h
  +++ b/drivers/media/pci/cx18/cx18-i2c.h
  @@ -21,6 +21,7 @@
*  02111-1307  USA
*/
   
  +int cx18_get_max_bus_num(void);
   int cx18_i2c_register(struct cx18 *cx, unsigned idx);
   struct v4l2_subdev *cx18_find_hw(struct cx18 *cx, u32 hw);
   
  


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

tda8290 broken badly with cx18 (Re: Kernel crash with modprobe cx18)

[Andy Walls]

On Fri, 2014-01-10 at 10:55 -0600, Scott Robinson wrote:
 I did the bisect. My results are as follows:

Hi Scott,

Thank you! for doing a bisection.  It is a non-trivial investment in
time.

Ondrej and Mike,

The change Scott isolated below breaks cx18 driver use of the TDA8290.
See the Ooops in the email chain below.

For how the cx18 driver initializes analog tuners, see the following:

cx18-driver.c:cx18_probe() (search for 'struct tuner_setup')
cx18-i2c.c:cx18_i2c_register()

Do you have any recommendations on how to fix the Oops by the tda8290
driver?

Regards,
Andy

 cdcd141c95f0c2b88e0b0869028c320cd031a23b is the first bad commit
 commit cdcd141c95f0c2b88e0b0869028c320cd031a23b
 Author: Ondrej Zary li...@rainbow-software.org
 Date:   Sat Apr 6 14:21:36 2013 -0300
 
 [media] tuner-core: Change config from unsigned int to void *
 
 config looks like a hack that was added to tuner-core to allow some
 configuration of TDA8290 tuner (it's not used by any other driver).
 But with the new configuration options of tda8290 driver (no_i2c_gate
 and std_map), it's no longer sufficient.
 Change config to be void * instead, which allows passing tuner-dependent
 config struct to drivers.
 Also update saa7134 driver to reflect this change (no other driver
 uses this).
 
 Signed-off-by: Ondrej Zary li...@rainbow-software.org
 Signed-off-by: Michael Krufky mkru...@linuxtv.org
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 :04 04 f2492f3c86adf77f671bcda6bd9fcc3541b69e48
 9e42c49fecb111f2f6aec6102bed1e29194a2fd5 Mdrivers
 :04 04 23c5843c6a01e8b8a69bd2237a2d2f1e5aa7a154
 d7937ce34beccf87efcffb742504a1c545e6a9eb Minclude
 
 Regards,
 Scott
 
 
 On Sat, Dec 28, 2013 at 9:54 AM, Andy Walls awa...@md.metrocast.net wrote:
  On Thu, 2013-12-26 at 06:57 -0600, Scott Robinson wrote:
  The machine with which I encountered this problem has two HVR-1600
  cards. I moved one card to another machine. The card still fails at
  the same point. I ran memtest, which passed. The machine has about 3GB
  memory free. I loaded other versions of the kernel. Up to and
  including 3.9.11-200.fc18 work. Starting at 3.10.4-100.fc18 fail. I
  tried a Ubuntu 13.10 (kernel-3.11.0-12-generic) livecd; the machine
  failed at the same point.
 
  OK.  I'll have to find some time to bisect this problem with my own
  setup at home.  Having known good and bad versions helps bound where the
  problem could be, thanks.
 
  I'm very busy at work until about mid-January, so don't expect much
  until then. Bisection iterations take me about 2 hours each, IIRC.
 
  $ git bisect start v3.10 v3.9
 
  tells me I have 14 steps, so 28 hours, or 3.5 full work days.
 
 
  I am wondering what changed, starting with the 3.10 series, that may
  cause this problem.
 
  A change to the tuner driver in question; not likely the cx18 driver
  itself.
 
  I'll wildly speculate that it might be a driver problem with attempting
  to use too much memory from the kernel stack.
 
  It doesn't matter. The Oops is close to useless in finding the cause.
  It'll have to be bisected.
 
   I also wonder why I haven't seen this problem
  reported before.
 
  Both Conventional (legacy) PCI and Analog TV are about dead; that
  probably means a small user base.
 
 
  I looked at modinfo. That's above my skill level. I use the cards to
  record using the analog cable input, the mpeg encoder. What options
  could I use to inhibit everything else?
 
  I would appreciate any advise as to what else I may check to isolate
  this problem.
 
  I'll say not much at this point; unless you want to start bisecting
  kernel source code revisions and compiling, installing, and tetsing
  custom kernels.
 
  Regards,
  Andy
 
  Thanks,
  Scott
 
 
  On Thu, Dec 19, 2013 at 7:11 PM, Andy Walls awa...@md.metrocast.net 
  wrote:
   On Thu, 2013-12-19 at 07:00 -0600, Scott Robinson wrote:
   Please see attachment. Many thanks for your response.
  
   On Wed, Dec 18, 2013 at 7:40 PM, Andy Walls awa...@md.metrocast.net 
   wrote:
On Wed, 2013-12-18 at 13:06 -0600, Scott Robinson wrote:
I am running Fedora 18, x86_64, and recently updated the kernel to
3.11.10-100.fc18 from 3.6.10-4.fc18.
   
When I try to install the cx18 module, the kernel crashes with the 
following:
   
Can you provide the output of
   
$ objdump -d -l -F 
/lib/modules/3.11.10-100.fc18.x86_64/kernel/drivers/media/common/tuners/tda8290.ko
   
for the first few screenfuls of the tda829x_attach function?
   
I can match that up with the kernel v3.10 source code and see what
pointer is NULL.
  
[  495.361662] netconsole: network logging started
[  558.481787] media: Linux media interface: v0.10
[  558.502941] Linux video capture interface: v2.00
[  558.617145] cx18:  Start initialization, version 1.5.1
[  558.617237] cx18-0: Initializing card 0
  
[  558.725076] cx18

Re: HVR-1800/1850 aka CX23885

[Andy Walls]

Hi Bob:

(CC-ing linux-media mailing list.)

On Mon, 2013-12-30 at 16:45 -0500, Bob Lightfoot wrote:
 Dear Andy:
Based on what I read here
 {http://ivtvdriver.org/pipermail/ivtv-users/2009-June/009460.html} you
 are or were maintaining the cx18 driver for Fedora.
I have been running a HVR-1600 and an HVR-1850-MCE successfully with
 Centos 6 and Mythtv for some time now.  But I have never seen a
 /dev/radio or had working fm radio in linux.

For an HVR-1600 with an FM antenna connector, FM radio should work under
linux.

/dev/radio0 is the control node.  It switches the card to radio mode and
you can set the FM radio freq using it.  You also can use it for volume
control.  This /dev/node doesn't provide any digitized radio data.

/dev/video24 is an ivtv/cx18 unique device node which provides the PCM
radio data.

Using the cx18-alsa module, the cx18 driver will provide
ALSA /dev/snd/pcm* nodes for the HVR-1600 which also provide the
digitizer audio, the Linux standard way.  The cx18-alsa implementtation
doesn't implement the ALSA mixer controls, IIRC, so you can't use the
ALSA interface to control the HVR-1600 volume directly. 

   I know the HVR-1850-MCE
 had working fm radio in Vista and that dmesg shows linux as seeing the
 radio.

Analog support for the HVR-1850 in Linux was added late.  It would not
surprise me if FM radio support in that driver didn't exist or was not
tested at all.  I have not looked at that driver lately.  


Can you suggest where to look for reading material on getting the
 radio working?

For the cx18 and ivtv based cards, ivtv-radio is a simple CLI app that
works in conjuntion with aplay to tune to an FM station and play the
audio.

The source for ivtv-radio is in the archive here:

http://dl.ivtvdriver.org/ivtv/stable/ivtv-utils-1.4.1.tar.gz

Save the archive and rename the file to end in .tar.gz.gz.  The web
server re-gzips the archive (*grumble*) so you need to gunzip it twice.
 
Regards,
Andy

 Sincerely,
 Bob Lightfoot


--
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: Fwd: v4l2: The device does not support the streaming I/O method.

[Andy Walls]

On Sun, 2013-12-29 at 15:27 -0500, Andy wrote:
 Are there any other viable options to stream /dev/video0 then?

I'm not sure what you mean by stream; what are you trying to do?

By default the ivtv driver and the PVR-150 output an MPEG-2 Program
Stream containing MPEG-2 Video and MPEG-2 Audio Elementary Streams.

Any Linux video application worth it's salt (mplayer, VLC, ffmpeg)
should be able to handle that MPEG-2 PS with no problem.

It's just a matter of using the correct command line argument to do what
you want to do.  mplayer only needs the device node name as a command
line argument to play back the stream.

Regards,
Andy




 On Sat, Dec 28, 2013 at 1:15 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Fri, 2013-12-27 at 00:37 -0500, Andy wrote:
  I am trying to capture input from /dev/video0 which is Hauppauge Win
  150 MCE PCI card but I get the following error which has no record on
  google
 
  [video4linux2,v4l2 @ 0xb080d60] The device does not support the
  streaming I/O method.
  /dev/video0: Function not implemented
 
  The ivtv driver does not support the V4L2 Streaming I/O ioctl()'s for
  transferring video data buffers.  It only supports the read()/write()
  calls.
 
  I'm not sure about ffmpeg, but mplayer is happy to read() the mpeg
  stream from standard input or the device node:
 
  # cat /dev/video0 | mplayer
  or
  # mplayer /dev/video0
 
  Regards,
  Andy
 
  Here is the ffmpeg command
  ffmpeg -y -f:v video4linux2 -i /dev/video0 -f:a alsa -ac 1 -i hw:1,0
  -threads 2 -override_ffserver -flags +global_header -vcodec libx264 -s
  320x240 -preset superfast -r 7.5 -acodec aac -ar 44100
  ipgoeshere:port/dvbstest.ffm
 
  Disregard the DVB syntax, not relevant
 
  Any idea what is causing the error?
  --
  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: Fwd: v4l2: The device does not support the streaming I/O method.

[Andy Walls]

On Wed, 2014-01-01 at 14:46 -0500, Devin Heitmueller wrote:
 On Wed, Jan 1, 2014 at 2:41 PM, Andy dssnos...@gmail.com wrote:
  I am trying to stream /dev/video0 to http and encode it in h.264.
 
 Last I checked, the ffmpeg v4l2 input interface is just for raw video.
  What you probably want to do is just use v4l2-ctl to setup the tuner
 appropriately, and then pass in /dev/video0 as a standard filehandle
 to ffmpeg (i.e. -i /dev/video0).

To obtain uncompressed video and audio from the ivtv driver and the
PVR-150:

uncompressed video is available from /dev/video32 in an odd Conexant
macroblock format that is called 'HM12' under linux.

raw PCM audio samples are available from /dev/video24


Note that /dev/video0 is always MPEG-2 compressed video.

I assume ffmpeg and mencoder can transcode from MPEG-2 PS to H.264 on
the fly, however, they will consume more CPU to do the decompression of
the MPEG-2 PS.  The advantage of working with the MPEG-2 PS as the
source is that one avoids the audio  video synchronization problem one
might encounter working with the separate uncompressed audio  video
streams. 

Regards,
Andy

--
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: Fwd: v4l2: The device does not support the streaming I/O method.

[Andy Walls]

On Wed, 2014-01-01 at 17:22 -0500, Devin Heitmueller wrote:
 On Wed, Jan 1, 2014 at 5:21 PM, Devin Heitmueller
 dheitmuel...@kernellabs.com wrote:
  On Wed, Jan 1, 2014 at 5:18 PM, Andy Walls awa...@md.metrocast.net wrote:
  uncompressed video is available from /dev/video32 in an odd Conexant
  macroblock format that is called 'HM12' under linux.
 
 One more point worth making - I doubt ffmpeg supports HM12 natively.

mplayer/mencoder knows how to handle HM12.

But yeah it's and odd format.  It is an intermediate by-product of the
CX23416's MPEG-2 encoding process.  It's kind of a debugging/bonus that
the chip provides the stream. 

 You would either have to add the functionality to ffmpeg to do the
 colorspace conversion, or you might be able to wrap ffmpeg around
 libv4l2convert via LD_LIBRARY_PATH.

Yeah.

 Devin

Regards,
Andy

--
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: [ivtv-users] Kernel crash with modprobe cx18

[Andy Walls]

On Thu, 2013-12-26 at 06:57 -0600, Scott Robinson wrote:
 The machine with which I encountered this problem has two HVR-1600
 cards. I moved one card to another machine. The card still fails at
 the same point. I ran memtest, which passed. The machine has about 3GB
 memory free. I loaded other versions of the kernel. Up to and
 including 3.9.11-200.fc18 work. Starting at 3.10.4-100.fc18 fail. I
 tried a Ubuntu 13.10 (kernel-3.11.0-12-generic) livecd; the machine
 failed at the same point.

OK.  I'll have to find some time to bisect this problem with my own
setup at home.  Having known good and bad versions helps bound where the
problem could be, thanks.

I'm very busy at work until about mid-January, so don't expect much
until then. Bisection iterations take me about 2 hours each, IIRC.

$ git bisect start v3.10 v3.9

tells me I have 14 steps, so 28 hours, or 3.5 full work days.

  
 I am wondering what changed, starting with the 3.10 series, that may
 cause this problem.

A change to the tuner driver in question; not likely the cx18 driver
itself.

I'll wildly speculate that it might be a driver problem with attempting
to use too much memory from the kernel stack.

It doesn't matter. The Oops is close to useless in finding the cause.
It'll have to be bisected.

  I also wonder why I haven't seen this problem
 reported before.

Both Conventional (legacy) PCI and Analog TV are about dead; that
probably means a small user base.  


 I looked at modinfo. That's above my skill level. I use the cards to
 record using the analog cable input, the mpeg encoder. What options
 could I use to inhibit everything else?
 
 I would appreciate any advise as to what else I may check to isolate
 this problem.

I'll say not much at this point; unless you want to start bisecting
kernel source code revisions and compiling, installing, and tetsing
custom kernels.

Regards,
Andy

 Thanks,
 Scott
 
 
 On Thu, Dec 19, 2013 at 7:11 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Thu, 2013-12-19 at 07:00 -0600, Scott Robinson wrote:
  Please see attachment. Many thanks for your response.
 
  On Wed, Dec 18, 2013 at 7:40 PM, Andy Walls awa...@md.metrocast.net 
  wrote:
   On Wed, 2013-12-18 at 13:06 -0600, Scott Robinson wrote:
   I am running Fedora 18, x86_64, and recently updated the kernel to
   3.11.10-100.fc18 from 3.6.10-4.fc18.
  
   When I try to install the cx18 module, the kernel crashes with the 
   following:
  
   Can you provide the output of
  
   $ objdump -d -l -F 
   /lib/modules/3.11.10-100.fc18.x86_64/kernel/drivers/media/common/tuners/tda8290.ko
  
   for the first few screenfuls of the tda829x_attach function?
  
   I can match that up with the kernel v3.10 source code and see what
   pointer is NULL.
 
   [  495.361662] netconsole: network logging started
   [  558.481787] media: Linux media interface: v0.10
   [  558.502941] Linux video capture interface: v2.00
   [  558.617145] cx18:  Start initialization, version 1.5.1
   [  558.617237] cx18-0: Initializing card 0
 
   [  558.725076] cx18-0:  info: activating i2c...
   [  558.725084] cx18-0:  i2c: i2c init
   [  558.858738] tveeprom 6-0050: Hauppauge model 74351, rev F1F5, 
   serial# 7764125
   [  558.858766] tveeprom 6-0050: MAC address is 00:0d:fe:76:78:9d
   [  558.858790] tveeprom 6-0050: tuner model is NXP 18271C2 (idx 155, 
   type 54)
   [  558.858801] tveeprom 6-0050: TV standards PAL(B/G) NTSC(M) PAL(I)
   SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
   [  558.858817] tveeprom 6-0050: audio processor is CX23418 (idx 38)
   [  558.858825] tveeprom 6-0050: decoder processor is CX23418 (idx 31)
   [  558.858839] tveeprom 6-0050: has no radio
   [  558.858847] cx18-0: Autodetected Hauppauge HVR-1600
   [  558.858860] cx18-0:  info: Worldwide tuner detected
   [  558.858882] cx18-0:  info: GPIO initial dir: cffe/ out:
   3001/
   [  558.908552] cx18-0: Simultaneous Digital and Analog TV capture 
   supported
   [  559.075778] tuner 7-0042: Tuner -1 found with type(s) Radio TV.
   [  559.098598] cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
   [  559.105203] BUG: unable to handle kernel NULL pointer dereference
   at 0202
   [  559.109526] IP: [a04facae] tda829x_attach+0x6e/0xba0 
   [tda8290]
   [  559.113832] PGD 0
   [  559.118058] Oops:  [#1] SMP
   [  559.122219] Modules linked in: cs5345 tda8290 tuner cx18(+)
   videobuf_vmalloc tveeprom cx2341x videobuf_core dvb_core v4l2_common
   videodev media netconsole nfsv4 dns_resolver nfs lockd fscache
   snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
   snd_seq_device snd_pcm snd_page_alloc ppdev kvm_amd kvm sp5100_tco
   snd_timer snd soundcore shpchp parport_pc parport microcode serio_raw
   edac_core k10temp edac_mce_amd acpi_cpufreq mperf i2c_piix4 uinput
   ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper pata_atiixp
   ttm r8169 drm mii i2c_core sunrpc
   [  559.137276] CPU: 0 PID

Re: Fwd: v4l2: The device does not support the streaming I/O method.

[Andy Walls]

On Fri, 2013-12-27 at 00:37 -0500, Andy wrote:
 I am trying to capture input from /dev/video0 which is Hauppauge Win
 150 MCE PCI card but I get the following error which has no record on
 google
 
 [video4linux2,v4l2 @ 0xb080d60] The device does not support the
 streaming I/O method.
 /dev/video0: Function not implemented

The ivtv driver does not support the V4L2 Streaming I/O ioctl()'s for
transferring video data buffers.  It only supports the read()/write()
calls.

I'm not sure about ffmpeg, but mplayer is happy to read() the mpeg
stream from standard input or the device node:

# cat /dev/video0 | mplayer
or
# mplayer /dev/video0 

Regards,
Andy

 Here is the ffmpeg command
 ffmpeg -y -f:v video4linux2 -i /dev/video0 -f:a alsa -ac 1 -i hw:1,0
 -threads 2 -override_ffserver -flags +global_header -vcodec libx264 -s
 320x240 -preset superfast -r 7.5 -acodec aac -ar 44100
 ipgoeshere:port/dvbstest.ffm
 
 Disregard the DVB syntax, not relevant
 
 Any idea what is causing the error?
 --
 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: [ivtv-users] Kernel crash with modprobe cx18

[Andy Walls]

On Thu, 2013-12-19 at 07:00 -0600, Scott Robinson wrote:
 Please see attachment. Many thanks for your response.

 On Wed, Dec 18, 2013 at 7:40 PM, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2013-12-18 at 13:06 -0600, Scott Robinson wrote:
  I am running Fedora 18, x86_64, and recently updated the kernel to
  3.11.10-100.fc18 from 3.6.10-4.fc18.
 
  When I try to install the cx18 module, the kernel crashes with the 
  following:
 
  Can you provide the output of
 
  $ objdump -d -l -F 
  /lib/modules/3.11.10-100.fc18.x86_64/kernel/drivers/media/common/tuners/tda8290.ko
 
  for the first few screenfuls of the tda829x_attach function?
 
  I can match that up with the kernel v3.10 source code and see what
  pointer is NULL.

  [  495.361662] netconsole: network logging started
  [  558.481787] media: Linux media interface: v0.10
  [  558.502941] Linux video capture interface: v2.00
  [  558.617145] cx18:  Start initialization, version 1.5.1
  [  558.617237] cx18-0: Initializing card 0

  [  558.725076] cx18-0:  info: activating i2c...
  [  558.725084] cx18-0:  i2c: i2c init
  [  558.858738] tveeprom 6-0050: Hauppauge model 74351, rev F1F5, serial# 
  7764125
  [  558.858766] tveeprom 6-0050: MAC address is 00:0d:fe:76:78:9d
  [  558.858790] tveeprom 6-0050: tuner model is NXP 18271C2 (idx 155, type 
  54)
  [  558.858801] tveeprom 6-0050: TV standards PAL(B/G) NTSC(M) PAL(I)
  SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
  [  558.858817] tveeprom 6-0050: audio processor is CX23418 (idx 38)
  [  558.858825] tveeprom 6-0050: decoder processor is CX23418 (idx 31)
  [  558.858839] tveeprom 6-0050: has no radio
  [  558.858847] cx18-0: Autodetected Hauppauge HVR-1600
  [  558.858860] cx18-0:  info: Worldwide tuner detected
  [  558.858882] cx18-0:  info: GPIO initial dir: cffe/ out:
  3001/
  [  558.908552] cx18-0: Simultaneous Digital and Analog TV capture supported
  [  559.075778] tuner 7-0042: Tuner -1 found with type(s) Radio TV.
  [  559.098598] cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
  [  559.105203] BUG: unable to handle kernel NULL pointer dereference
  at 0202
  [  559.109526] IP: [a04facae] tda829x_attach+0x6e/0xba0 [tda8290]
  [  559.113832] PGD 0
  [  559.118058] Oops:  [#1] SMP
  [  559.122219] Modules linked in: cs5345 tda8290 tuner cx18(+)
  videobuf_vmalloc tveeprom cx2341x videobuf_core dvb_core v4l2_common
  videodev media netconsole nfsv4 dns_resolver nfs lockd fscache
  snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
  snd_seq_device snd_pcm snd_page_alloc ppdev kvm_amd kvm sp5100_tco
  snd_timer snd soundcore shpchp parport_pc parport microcode serio_raw
  edac_core k10temp edac_mce_amd acpi_cpufreq mperf i2c_piix4 uinput
  ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper pata_atiixp
  ttm r8169 drm mii i2c_core sunrpc
  [  559.137276] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted
  3.11.10-100.fc18.x86_64 #1
  [  559.142306] Hardware name: FOXCONN A6VMX/A6VMX, BIOS 080014  06/03/2009
  [  559.147406] Workqueue: events work_for_cpu_fn
  [  559.152497] task: 880121ef9e80 ti: 8801219a task.ti:
  8801219a
  [  559.157655] RIP: 0010:[a04facae]  [a04facae]
  tda829x_attach+0x6e/0xba0 [tda8290]
  [  559.162964] RSP: 0018:8801219a1b68  EFLAGS: 00010202
  [  559.168238] RAX: 88011d3bf060 RBX: 88011c734000 RCX: 
  
  [  559.173537] RDX:  RSI:  RDI: 
  88011d3bf0c0
  [  559.178905] RBP: 8801219a1bf8 R08: 00016f00 R09: 
  880123401a00
  [  559.184294] R10: a04fac87 R11:  R12: 
  88011d3bf060
  [  559.189662] R13: 0202 R14: 88012099d698 R15: 
  0042
  [  559.195081] FS:  7fc9f1c89840() GS:880127c0()
  knlGS:
  [  559.200563] CS:  0010 DS:  ES:  CR0: 8005003b
  [  559.206034] CR2: 0202 CR3: 01c0c000 CR4: 
  07f0
  [  559.211611] Stack:
  [  559.217124]  8801219a1bc8 810cc08d 88012099d370
  a04f6138
  [  559.222852]  8801219a0101 a04fe060 
  a04fd030
  [  559.228659]  8801219a1c4c a04fd030 0036
  b58d6d22
  [  559.234345] Call Trace:
  [  559.239922]  [810cc08d] ? find_symbol+0x3d/0xb0
  [  559.245535]  [a04f3605] set_type+0x325/0x9f0 [tuner]
  [  559.251177]  [a04c95ca] ? cx18_i2c_register+0x15a/0x210 [cx18]
  [  559.256814]  [a04f3d6f] tuner_s_type_addr+0x9f/0x140 [tuner]
  [  559.262494]  [a04c8722] cx18_probe+0xda2/0x1560 [cx18]
  [  559.268195]  [8133d4ab] local_pci_probe+0x4b/0x80
  [  559.273897]  [81080da8] work_for_cpu_fn+0x18/0x30
  [  559.279604]  [8108391a] process_one_work+0x17a/0x400
  [  559.285341]  [81083bcc] process_scheduled_works+0x2c/0x40
  [  559.291056

Re: [ivtv-users] Kernel crash with modprobe cx18

[Andy Walls]

On Wed, 2013-12-18 at 13:06 -0600, Scott Robinson wrote:
 I am running Fedora 18, x86_64, and recently updated the kernel to
 3.11.10-100.fc18 from 3.6.10-4.fc18.
 
 When I try to install the cx18 module, the kernel crashes with the following:

Can you provide the output of 

$ objdump -d -l -F 
/lib/modules/3.11.10-100.fc18.x86_64/kernel/drivers/media/common/tuners/tda8290.ko

for the first few screenfuls of the tda829x_attach function?

I can match that up with the kernel v3.10 source code and see what
pointer is NULL.

Regards,
Andy


 [  495.361662] netconsole: network logging started
 [  558.481787] media: Linux media interface: v0.10
 [  558.502941] Linux video capture interface: v2.00
 [  558.617145] cx18:  Start initialization, version 1.5.1
 [  558.617237] cx18-0: Initializing card 0
 [  558.617271] cx18-0:  info: Stream type 0 options: 2 MB, 64 buffers,
 32768 bytes
 [  558.617290] cx18-0:  info: Stream type 1 options: 1 MB, 32 buffers,
 32768 bytes
 [  558.617300] cx18-0:  info: Stream type 2 options: 2 MB, 20 buffers,
 103680 bytes
 [  558.617314] cx18-0:  info: Stream type 3 options: 1 MB, 20 buffers,
 51984 bytes
 [  558.617322] cx18-0:  info: Stream type 4 options: 1 MB, 256
 buffers, 4096 bytes
 [  558.617336] cx18-0:  info: Stream type 5 options: 0 MB, 63 buffers,
 1536 bytes
 [  558.617345] cx18-0: Autodetected Hauppauge card
 [  558.617434] cx18-0:  info: base addr: 0xf800
 [  558.617442] cx18-0:  info: Enabling pci device
 [  558.617639] cx18-0:  info: cx23418 (rev 0) at 03:00.0, irq: 20,
 latency: 64, memory: 0xf800
 [  558.617649] cx18-0:  info: attempting ioremap at 0xf800 len 0x0400
 [  558.626564] cx18-0: cx23418 revision 0101 (B)
 [  558.724970] cx18-0:  info: GPIO initial dir: / out:
 /
 [  558.725076] cx18-0:  info: activating i2c...
 [  558.725084] cx18-0:  i2c: i2c init
 [  558.858738] tveeprom 6-0050: Hauppauge model 74351, rev F1F5, serial# 
 7764125
 [  558.858766] tveeprom 6-0050: MAC address is 00:0d:fe:76:78:9d
 [  558.858790] tveeprom 6-0050: tuner model is NXP 18271C2 (idx 155, type 54)
 [  558.858801] tveeprom 6-0050: TV standards PAL(B/G) NTSC(M) PAL(I)
 SECAM(L/L') PAL(D/D1/K) ATSC/DVB Digital (eeprom 0xfc)
 [  558.858817] tveeprom 6-0050: audio processor is CX23418 (idx 38)
 [  558.858825] tveeprom 6-0050: decoder processor is CX23418 (idx 31)
 [  558.858839] tveeprom 6-0050: has no radio
 [  558.858847] cx18-0: Autodetected Hauppauge HVR-1600
 [  558.858860] cx18-0:  info: Worldwide tuner detected
 [  558.858882] cx18-0:  info: GPIO initial dir: cffe/ out:
 3001/
 [  558.908552] cx18-0: Simultaneous Digital and Analog TV capture supported
 [  559.075778] tuner 7-0042: Tuner -1 found with type(s) Radio TV.
 [  559.098598] cs5345 6-004c: chip found @ 0x98 (cx18 i2c driver #0-0)
 [  559.105203] BUG: unable to handle kernel NULL pointer dereference
 at 0202
 [  559.109526] IP: [a04facae] tda829x_attach+0x6e/0xba0 [tda8290]
 [  559.113832] PGD 0
 [  559.118058] Oops:  [#1] SMP
 [  559.122219] Modules linked in: cs5345 tda8290 tuner cx18(+)
 videobuf_vmalloc tveeprom cx2341x videobuf_core dvb_core v4l2_common
 videodev media netconsole nfsv4 dns_resolver nfs lockd fscache
 snd_hda_codec_realtek snd_hda_intel snd_hda_codec snd_hwdep snd_seq
 snd_seq_device snd_pcm snd_page_alloc ppdev kvm_amd kvm sp5100_tco
 snd_timer snd soundcore shpchp parport_pc parport microcode serio_raw
 edac_core k10temp edac_mce_amd acpi_cpufreq mperf i2c_piix4 uinput
 ata_generic pata_acpi radeon i2c_algo_bit drm_kms_helper pata_atiixp
 ttm r8169 drm mii i2c_core sunrpc
 [  559.137276] CPU: 0 PID: 26 Comm: kworker/0:1 Not tainted
 3.11.10-100.fc18.x86_64 #1
 [  559.142306] Hardware name: FOXCONN A6VMX/A6VMX, BIOS 080014  06/03/2009
 [  559.147406] Workqueue: events work_for_cpu_fn
 [  559.152497] task: 880121ef9e80 ti: 8801219a task.ti:
 8801219a
 [  559.157655] RIP: 0010:[a04facae]  [a04facae]
 tda829x_attach+0x6e/0xba0 [tda8290]
 [  559.162964] RSP: 0018:8801219a1b68  EFLAGS: 00010202
 [  559.168238] RAX: 88011d3bf060 RBX: 88011c734000 RCX: 
 
 [  559.173537] RDX:  RSI:  RDI: 
 88011d3bf0c0
 [  559.178905] RBP: 8801219a1bf8 R08: 00016f00 R09: 
 880123401a00
 [  559.184294] R10: a04fac87 R11:  R12: 
 88011d3bf060
 [  559.189662] R13: 0202 R14: 88012099d698 R15: 
 0042
 [  559.195081] FS:  7fc9f1c89840() GS:880127c0()
 knlGS:
 [  559.200563] CS:  0010 DS:  ES:  CR0: 8005003b
 [  559.206034] CR2: 0202 CR3: 01c0c000 CR4: 
 07f0
 [  559.211611] Stack:
 [  559.217124]  8801219a1bc8 810cc08d 88012099d370
 a04f6138
 [  559.222852]  8801219a0101 a04fe060 
 a04fd030
 [  559.228659]  

Re: [patch] [media] cx18: check for allocation failure in cx18_read_eeprom()

[Andy Walls]

On Fri, 2013-11-22 at 10:51 +0300, Dan Carpenter wrote:
 It upsets static checkers when we don't check for allocation failure.  I
 moved the memset() of tv earlier so we don't use uninitialized data on
 error.
 
 Fixes: 1d212cf0c2d8 ('[media] cx18: struct i2c_client is too big for stack')
 Signed-off-by: Dan Carpenter dan.carpen...@oracle.com

Acked-by: Andy Walls awa...@md.metrocast.net


 diff --git a/drivers/media/pci/cx18/cx18-driver.c 
 b/drivers/media/pci/cx18/cx18-driver.c
 index c1f8cc6f14b2..716bdc57fac6 100644
 --- a/drivers/media/pci/cx18/cx18-driver.c
 +++ b/drivers/media/pci/cx18/cx18-driver.c
 @@ -327,13 +327,16 @@ void cx18_read_eeprom(struct cx18 *cx, struct tveeprom 
 *tv)
   struct i2c_client *c;
   u8 eedata[256];
  
 + memset(tv, 0, sizeof(*tv));
 +
   c = kzalloc(sizeof(*c), GFP_KERNEL);
 + if (!c)
 + return;
  
   strlcpy(c-name, cx18 tveeprom tmp, sizeof(c-name));
   c-adapter = cx-i2c_adap[0];
   c-addr = 0xa0  1;
  
 - memset(tv, 0, sizeof(*tv));
   if (tveeprom_read(c, eedata, sizeof(eedata)))
   goto ret;
  
 --
 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] [media] cx18: check for allocation failure in cx18_read_eeprom()

[Andy Walls]

On Fri, 2013-11-22 at 10:21 +0100, Hans Verkuil wrote:
 Andy,
 
 Should we perhaps change the MAINTAINERS file to point to the linux-media list
 instead?

Yes.  When I get time this weekend, I can submit a patch; unless you
beat me to it.

Regards,
Andy

 Regards,
 
   Hans
 
 On 11/22/2013 10:13 AM, Dan Carpenter wrote:
  Btw, the MAINTAINERS file says the ivtv list is moderated but actually
  it's a subscriber only list...  Sucks.
 
 --
 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 RFC] videobuf2: Improve file I/O emulation to handle buffers in any order

[Andy Walls]

Hi Hans,

On Thu, 2013-11-21 at 14:52 +0100, Hans Verkuil wrote:
 Hi Andy,
 
 This seems more complex than is necessary. See my comments below...
 
 On 11/21/13 02:05, Andy Walls wrote:
  (This patch is RFC, because it was compiled and tested against kernel
  v3.5)
  
  videobuf2 file I/O emulation assumed that buffers dequeued from the
  driver would return in the order they were enqueued in the driver. 
  
  Improve the file I/O emulator's book-keeping to remove this assumption.
  
  Also remove the, AFAICT, assumption that only read() calls would need to
  dequeue a buffer from the driver.
  
  Also set the buf-size properly, if a write() dequeues a buffer.
  
  
  Signed-off-by: Andy Walls awa...@md.metrocast.net
  Cc: Kyungmin Park kyungmin.p...@samsung.com
  Cc: PawelOsciakpa...@osciak.com
  Cc: Marek Szyprowski m.szyprow...@samsung.com
  
  
  diff --git a/drivers/media/video/videobuf2-core.c 
  b/drivers/media/video/videobuf2-core.c
  index 9d4e9ed..f330aa4 100644
  --- a/drivers/media/video/videobuf2-core.c
  +++ b/drivers/media/video/videobuf2-core.c
  @@ -1796,6 +1796,7 @@ struct vb2_fileio_data {
  unsigned int dq_count;
  unsigned int flags;
   };
  +#define FILEIO_INDEX_NOT_SET   ((unsigned int) INT_MAX)
   
   /**
* __vb2_init_fileio() - initialize file io emulator
  @@ -1889,6 +1890,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
  read)
  goto err_reqbufs;
  fileio-bufs[i].queued = 1;
  }
  +   fileio-index = FILEIO_INDEX_NOT_SET;
   
  /*
   * Start streaming.
  @@ -1975,15 +1977,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
   */
  q-fileio = NULL;
   
  -   index = fileio-index;
  -   buf = fileio-bufs[index];
  -
  /*
   * Check if we need to dequeue the buffer.
   */
  -   if (buf-queued) {
  -   struct vb2_buffer *vb;
  -
  +   index = fileio-index;
  +   if (index == FILEIO_INDEX_NOT_SET) {
  /*
   * Call vb2_dqbuf to get buffer back.
   */
  @@ -1997,12 +1995,19 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
  goto end;
  fileio-dq_count += 1;
   
  +   fileio-index = fileio-b.index;
  +   index = fileio-index;
  +   buf = fileio-bufs[index];
  +   
  /*
   * Get number of bytes filled by the driver
   */
  -   vb = q-bufs[index];
  -   buf-size = vb2_get_plane_payload(vb, 0);
  +   buf-pos = 0;
  buf-queued = 0;
  +   buf-size = read ? vb2_get_plane_payload(q-bufs[index], 0)
  +: vb2_plane_size(q-bufs[index], 0);
  +   } else {
  +   buf = fileio-bufs[index];
  }
   
  /*
  @@ -2070,13 +2075,28 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
   */
  buf-pos = 0;
  buf-queued = 1;
  -   buf-size = q-bufs[0]-v4l2_planes[0].length;
  +   buf-size = vb2_plane_size(q-bufs[index], 0);
  fileio-q_count += 1;
   
  /*
  -* Switch to the next buffer
  +* Decide on the next buffer
   */
  -   fileio-index = (index + 1) % q-num_buffers;
  +   if (read || (q-num_buffers == 1)) {
  +   /* Use the next buffer the driver provides back */
  +   fileio-index = FILEIO_INDEX_NOT_SET;
  +   } else {
  +   /* Prefer a buffer that is not quequed in the driver */
  +   int initial_index = fileio-index;
  +   fileio-index = FILEIO_INDEX_NOT_SET;
  +   do {
  +   if (++index == q-num_buffers)
  +   index = 0;
  +   if (!fileio-bufs[index].queued) {
  +   fileio-index = index;
  +   break;
  +   }
  +   } while (index != initial_index);
 
 Why bother finding an unused index? There are really just two situations:
 either all the buffers have been queued, and after that you just dequeue
 and queue them (and you get the index from the dequeued buffer), or you
 are still only queuing buffers (in the write case, for the read case that
 already happened) and you can use a simple counter as the index.

Yes, you are correct.


  +   }
   
  /*
   * Start streaming if required.
  
  
 
 See my version of this patch below (it might not cleanly apply as this sits
 on top of a bunch of other vb2 patches that I will post soon):

I have reviewed your patch.  It looks fine to me.

Reviewed-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

 diff --git a/drivers/media/v4l2-core/videobuf2

Re: [PATCH RFC] videobuf2: Improve file I/O emulation to handle buffers in any order

[Andy Walls]

On Thu, 2013-11-21 at 08:56 +0100, Hans Verkuil wrote:
 Hi Andy,
 
 As I mentioned in irc I have been working in this same area as well, so
 I'll take this patch and merge it in my tree and test it as well.
 
 I suspect that it might be easiest if I add the patch to my upcoming
 patch series in order to prevent merge conflicts. I'll know more later
 today.

Hi Hans,

That sounds good to me. :)

I have 4 comments on my own stuff below:


 On 11/21/2013 02:05 AM, Andy Walls wrote:
  (This patch is RFC, because it was compiled and tested against kernel
  v3.5)
  
  videobuf2 file I/O emulation assumed that buffers dequeued from the
  driver would return in the order they were enqueued in the driver. 
  
  Improve the file I/O emulator's book-keeping to remove this assumption.
  
  Also remove the, AFAICT, assumption that only read() calls would need to
  dequeue a buffer from the driver.

Please remove the above sentence, it is incorrect.

 
  Also set the buf-size properly, if a write() dequeues a buffer.

Please append: , and the VB2_FILEIO_WRITE_IMMEDIATELY flag is set.


  Signed-off-by: Andy Walls awa...@md.metrocast.net
  Cc: Kyungmin Park kyungmin.p...@samsung.com
  Cc: PawelOsciakpa...@osciak.com
  Cc: Marek Szyprowski m.szyprow...@samsung.com
  
  
  diff --git a/drivers/media/video/videobuf2-core.c 
  b/drivers/media/video/videobuf2-core.c
  index 9d4e9ed..f330aa4 100644
  --- a/drivers/media/video/videobuf2-core.c
  +++ b/drivers/media/video/videobuf2-core.c
  @@ -1796,6 +1796,7 @@ struct vb2_fileio_data {
  unsigned int dq_count;
  unsigned int flags;
   };
  +#define FILEIO_INDEX_NOT_SET   ((unsigned int) INT_MAX)
   
   /**
* __vb2_init_fileio() - initialize file io emulator
  @@ -1889,6 +1890,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
  read)
  goto err_reqbufs;
  fileio-bufs[i].queued = 1;
  }
  +   fileio-index = FILEIO_INDEX_NOT_SET;
   
  /*
   * Start streaming.
  @@ -1975,15 +1977,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
   */
  q-fileio = NULL;
   
  -   index = fileio-index;
  -   buf = fileio-bufs[index];
  -
  /*
   * Check if we need to dequeue the buffer.
   */
  -   if (buf-queued) {
  -   struct vb2_buffer *vb;
  -
  +   index = fileio-index;
  +   if (index == FILEIO_INDEX_NOT_SET) {
  /*
   * Call vb2_dqbuf to get buffer back.
   */
  @@ -1997,12 +1995,19 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
  goto end;
  fileio-dq_count += 1;
   
  +   fileio-index = fileio-b.index;
  +   index = fileio-index;
  +   buf = fileio-bufs[index];
  +   
  /*
   * Get number of bytes filled by the driver
   */
  -   vb = q-bufs[index];
  -   buf-size = vb2_get_plane_payload(vb, 0);
  +   buf-pos = 0;
  buf-queued = 0;
  +   buf-size = read ? vb2_get_plane_payload(q-bufs[index], 0)
  +: vb2_plane_size(q-bufs[index], 0);
  +   } else {
  +   buf = fileio-bufs[index];
  }
   
  /*
  @@ -2070,13 +2075,28 @@ static size_t __vb2_perform_fileio(struct vb2_queue 
  *q, char __user *data, size_
   */
  buf-pos = 0;
  buf-queued = 1;
  -   buf-size = q-bufs[0]-v4l2_planes[0].length;
  +   buf-size = vb2_plane_size(q-bufs[index], 0);
  fileio-q_count += 1;
   
  /*
  -* Switch to the next buffer
  +* Decide on the next buffer
   */
  -   fileio-index = (index + 1) % q-num_buffers;
  +   if (read || (q-num_buffers == 1)) {

Change to

if (read || (fileio-q_count = q-num_buffers))

After the initial write() calls queue all the buffers, steady state is
all the buffers queued in the driver.  At steady state, the do-while
loop below is wasted effort.  This change to the if() condition avoids
that wasted effort, except for briefly after every roll-over of
fileio-q_count.

  +   /* Use the next buffer the driver provides back */
  +   fileio-index = FILEIO_INDEX_NOT_SET;
  +   } else {
  +   /* Prefer a buffer that is not quequed in the driver */

s/quequed/queued/

  +   int initial_index = fileio-index;
  +   fileio-index = FILEIO_INDEX_NOT_SET;
  +   do {
  +   if (++index == q-num_buffers)
  +   index = 0;
  +   if (!fileio-bufs[index].queued) {
  +   fileio-index = index;
  +   break;
  +   }
  +   } while (index

Re: [PATCH RFC] videobuf2: Improve file I/O emulation to handle buffers in any order

[Andy Walls]

Hans Verkuil hverk...@xs4all.nl wrote:
Hi Andy,

This seems more complex than is necessary. See my comments below...

On 11/21/13 02:05, Andy Walls wrote:
 (This patch is RFC, because it was compiled and tested against kernel
 v3.5)
 
 videobuf2 file I/O emulation assumed that buffers dequeued from the
 driver would return in the order they were enqueued in the driver. 
 
 Improve the file I/O emulator's book-keeping to remove this
assumption.
 
 Also remove the, AFAICT, assumption that only read() calls would need
to
 dequeue a buffer from the driver.
 
 Also set the buf-size properly, if a write() dequeues a buffer.
 
 
 Signed-off-by: Andy Walls awa...@md.metrocast.net
 Cc: Kyungmin Park kyungmin.p...@samsung.com
 Cc: PawelOsciakpa...@osciak.com
 Cc: Marek Szyprowski m.szyprow...@samsung.com
 
 
 diff --git a/drivers/media/video/videobuf2-core.c
b/drivers/media/video/videobuf2-core.c
 index 9d4e9ed..f330aa4 100644
 --- a/drivers/media/video/videobuf2-core.c
 +++ b/drivers/media/video/videobuf2-core.c
 @@ -1796,6 +1796,7 @@ struct vb2_fileio_data {
  unsigned int dq_count;
  unsigned int flags;
  };
 +#define FILEIO_INDEX_NOT_SET((unsigned int) INT_MAX)
  
  /**
   * __vb2_init_fileio() - initialize file io emulator
 @@ -1889,6 +1890,7 @@ static int __vb2_init_fileio(struct vb2_queue
*q, int read)
  goto err_reqbufs;
  fileio-bufs[i].queued = 1;
  }
 +fileio-index = FILEIO_INDEX_NOT_SET;
  
  /*
   * Start streaming.
 @@ -1975,15 +1977,11 @@ static size_t __vb2_perform_fileio(struct
vb2_queue *q, char __user *data, size_
   */
  q-fileio = NULL;
  
 -index = fileio-index;
 -buf = fileio-bufs[index];
 -
  /*
   * Check if we need to dequeue the buffer.
   */
 -if (buf-queued) {
 -struct vb2_buffer *vb;
 -
 +index = fileio-index;
 +if (index == FILEIO_INDEX_NOT_SET) {
  /*
   * Call vb2_dqbuf to get buffer back.
   */
 @@ -1997,12 +1995,19 @@ static size_t __vb2_perform_fileio(struct
vb2_queue *q, char __user *data, size_
  goto end;
  fileio-dq_count += 1;
  
 +fileio-index = fileio-b.index;
 +index = fileio-index;
 +buf = fileio-bufs[index];
 +
  /*
   * Get number of bytes filled by the driver
   */
 -vb = q-bufs[index];
 -buf-size = vb2_get_plane_payload(vb, 0);
 +buf-pos = 0;
  buf-queued = 0;
 +buf-size = read ? vb2_get_plane_payload(q-bufs[index], 0)
 + : vb2_plane_size(q-bufs[index], 0);
 +} else {
 +buf = fileio-bufs[index];
  }
  
  /*
 @@ -2070,13 +2075,28 @@ static size_t __vb2_perform_fileio(struct
vb2_queue *q, char __user *data, size_
   */
  buf-pos = 0;
  buf-queued = 1;
 -buf-size = q-bufs[0]-v4l2_planes[0].length;
 +buf-size = vb2_plane_size(q-bufs[index], 0);
  fileio-q_count += 1;
  
  /*
 - * Switch to the next buffer
 + * Decide on the next buffer
   */
 -fileio-index = (index + 1) % q-num_buffers;
 +if (read || (q-num_buffers == 1)) {
 +/* Use the next buffer the driver provides back */
 +fileio-index = FILEIO_INDEX_NOT_SET;
 +} else {
 +/* Prefer a buffer that is not quequed in the driver */
 +int initial_index = fileio-index;
 +fileio-index = FILEIO_INDEX_NOT_SET;
 +do {
 +if (++index == q-num_buffers)
 +index = 0;
 +if (!fileio-bufs[index].queued) {
 +fileio-index = index;
 +break;
 +}
 +} while (index != initial_index);

Why bother finding an unused index? There are really just two
situations:
either all the buffers have been queued, and after that you just
dequeue
and queue them (and you get the index from the dequeued buffer), or you
are still only queuing buffers (in the write case, for the read case
that
already happened) and you can use a simple counter as the index.

 +}
  
  /*
   * Start streaming if required.
 
 

See my version of this patch below (it might not cleanly apply as this
sits
on top of a bunch of other vb2 patches that I will post soon):

diff --git a/drivers/media/v4l2-core/videobuf2-core.c
b/drivers/media/v4l2-core/videobuf2-core.c
index 66cd81d..257b4ca 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-core/videobuf2-core.c
@@ -2309,6 +2309,7 @@ static int __vb2_init_fileio(struct vb2_queue

[PATCH RFC] videobuf2: Improve file I/O emulation to handle buffers in any order

[Andy Walls]

(This patch is RFC, because it was compiled and tested against kernel
v3.5)

videobuf2 file I/O emulation assumed that buffers dequeued from the
driver would return in the order they were enqueued in the driver. 

Improve the file I/O emulator's book-keeping to remove this assumption.

Also remove the, AFAICT, assumption that only read() calls would need to
dequeue a buffer from the driver.

Also set the buf-size properly, if a write() dequeues a buffer.


Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: PawelOsciakpa...@osciak.com
Cc: Marek Szyprowski m.szyprow...@samsung.com


diff --git a/drivers/media/video/videobuf2-core.c 
b/drivers/media/video/videobuf2-core.c
index 9d4e9ed..f330aa4 100644
--- a/drivers/media/video/videobuf2-core.c
+++ b/drivers/media/video/videobuf2-core.c
@@ -1796,6 +1796,7 @@ struct vb2_fileio_data {
unsigned int dq_count;
unsigned int flags;
 };
+#define FILEIO_INDEX_NOT_SET   ((unsigned int) INT_MAX)
 
 /**
  * __vb2_init_fileio() - initialize file io emulator
@@ -1889,6 +1890,7 @@ static int __vb2_init_fileio(struct vb2_queue *q, int 
read)
goto err_reqbufs;
fileio-bufs[i].queued = 1;
}
+   fileio-index = FILEIO_INDEX_NOT_SET;
 
/*
 * Start streaming.
@@ -1975,15 +1977,11 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
 */
q-fileio = NULL;
 
-   index = fileio-index;
-   buf = fileio-bufs[index];
-
/*
 * Check if we need to dequeue the buffer.
 */
-   if (buf-queued) {
-   struct vb2_buffer *vb;
-
+   index = fileio-index;
+   if (index == FILEIO_INDEX_NOT_SET) {
/*
 * Call vb2_dqbuf to get buffer back.
 */
@@ -1997,12 +1995,19 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
goto end;
fileio-dq_count += 1;
 
+   fileio-index = fileio-b.index;
+   index = fileio-index;
+   buf = fileio-bufs[index];
+   
/*
 * Get number of bytes filled by the driver
 */
-   vb = q-bufs[index];
-   buf-size = vb2_get_plane_payload(vb, 0);
+   buf-pos = 0;
buf-queued = 0;
+   buf-size = read ? vb2_get_plane_payload(q-bufs[index], 0)
+: vb2_plane_size(q-bufs[index], 0);
+   } else {
+   buf = fileio-bufs[index];
}
 
/*
@@ -2070,13 +2075,28 @@ static size_t __vb2_perform_fileio(struct vb2_queue *q, 
char __user *data, size_
 */
buf-pos = 0;
buf-queued = 1;
-   buf-size = q-bufs[0]-v4l2_planes[0].length;
+   buf-size = vb2_plane_size(q-bufs[index], 0);
fileio-q_count += 1;
 
/*
-* Switch to the next buffer
+* Decide on the next buffer
 */
-   fileio-index = (index + 1) % q-num_buffers;
+   if (read || (q-num_buffers == 1)) {
+   /* Use the next buffer the driver provides back */
+   fileio-index = FILEIO_INDEX_NOT_SET;
+   } else {
+   /* Prefer a buffer that is not quequed in the driver */
+   int initial_index = fileio-index;
+   fileio-index = FILEIO_INDEX_NOT_SET;
+   do {
+   if (++index == q-num_buffers)
+   index = 0;
+   if (!fileio-bufs[index].queued) {
+   fileio-index = index;
+   break;
+   }
+   } while (index != initial_index);
+   }
 
/*
 * Start streaming if required.


--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Mon, 2013-11-11 at 12:14 +0100, Hans Verkuil wrote:
 On 10/19/2013 07:09 PM, Andy Walls wrote:
  On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote:
  I was finally able to carry out a git bisect. Had to do a git pull on
  a fast internet hooked machine and ftp the files over to the remote
  machine.
 
  I started with 'git bisect bad v2.6.36.4' and 'git bisect good v2.6.35.10'.
 
  And the result was:
 
  5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 is the first bad commit
  commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79
  Author: Hans Verkuil hverk...@xs4all.nl
  Date:   Sat Apr 24 08:23:53 2010 -0300
 
  V4L/DVB: wm8775: convert to the new control framework
 
  Signed-off-by: Hans Verkuil hverk...@xs4all.nl
  Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
  :04 04 37847ffe592f255c6a9d9daedaf7bbfd3cd7b055
  2f094df6f65d7fb296657619c1ad6f93fe085a75 Mdrivers
 
  I then removed the patch from linux-2.6.36-gentoo-r8 which are gentoo
  sources, and confirmed that video/audio now works fine on v4l2-ctl -d
  /dev/video1 --set-input 4
 
  I wasnt able to remove the patch in 3.10.7 which is gentoo stable
  kernel. Any idea how can i do that?
  
  Try applying the following (untested) patch that is made against the
  bleeding edge Linux kernel.  The test on the mute control state in
  wm8775_s_routing() appears to have been inverted in the bad commit you
  isolated.
 
 Can you give me your Signed-off-by?


Signed-off-by: Andy Walls awa...@md.metrocast.net
Bisected-by: Rajil Saraswat raji...@gmail.com
Reported-by: Rajil Saraswat raji...@gmail.com

 Thanks!
 
   Hans
 
  
  Along with '--set-input', you may also want to use v4l2-ctl to exercise
  the mute control as well, to see if it works as expected, once this
  patch is applied.
  
  Regards,
  Andy
  
  file: wm8775_s_route_mute_test_inverted.patch
  
  diff --git a/drivers/media/i2c/wm8775.c b/drivers/media/i2c/wm8775.c
  index 3f584a7..bee7946 100644
  --- a/drivers/media/i2c/wm8775.c
  +++ b/drivers/media/i2c/wm8775.c
  @@ -130,12 +130,10 @@ static int wm8775_s_routing(struct v4l2_subdev *sd,
  return -EINVAL;
  }
  state-input = input;
  -   if (!v4l2_ctrl_g_ctrl(state-mute))
  +   if (v4l2_ctrl_g_ctrl(state-mute))
  return 0;
  if (!v4l2_ctrl_g_ctrl(state-vol))
  return 0;
  -   if (!v4l2_ctrl_g_ctrl(state-bal))
  -   return 0;
  wm8775_set_audio(sd, 1);
  return 0;
   }
  
  
 
 --
 To unsubscribe from this list: send the line unsubscribe linux-media in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html


--
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] libv4lconvert: SDR conversion from U8 to FLOAT

[Andy Walls]

On Sun, 2013-11-10 at 19:16 +0200, Antti Palosaari wrote:
 Convert unsigned 8 to float 32 [-1 to +1], which is commonly
 used format for baseband signals.

Hi Annti,

I don't think this a good idea.  Floating point representations are
inherently non-portable.  Even though most everything now uses IEEE-754
representation, things like denormaliazed numbers may be treated
differently by different machines.  If someone saves the data to a file,
endianess issues aside, there are no guarantees that a different machine
reading is going to interpret all the floating point data from that file
properly.

I really would recommend staying with scaled integer representations or
explicit integer mantissa, exponent representations.

Two more comments below...

 Signed-off-by: Antti Palosaari cr...@iki.fi
 ---
  contrib/freebsd/include/linux/videodev2.h |  4 
  include/linux/videodev2.h |  4 
  lib/libv4lconvert/libv4lconvert.c | 29 -
  3 files changed, 36 insertions(+), 1 deletion(-)
 
 diff --git a/contrib/freebsd/include/linux/videodev2.h 
 b/contrib/freebsd/include/linux/videodev2.h
 index 1fcfaeb..8829400 100644
 --- a/contrib/freebsd/include/linux/videodev2.h
 +++ b/contrib/freebsd/include/linux/videodev2.h
 @@ -465,6 +465,10 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_SE401  v4l2_fourcc('S', '4', '0', '1') /* se401 
 janggu compressed rgb */
  #define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3 
 interleaved UYVY/JPEG */
  
 +/* SDR */
 +#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float 
 32-bit */
 +#define V4L2_PIX_FMT_U8   v4l2_fourcc('D', 'U', '0', '8') /* unsigned 
 8-bit */
 +
  /*
   *   F O R M A T   E N U M E R A T I O N
   */
 diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
 index 437f1b0..14299a6 100644
 --- a/include/linux/videodev2.h
 +++ b/include/linux/videodev2.h
 @@ -431,6 +431,10 @@ struct v4l2_pix_format {
  #define V4L2_PIX_FMT_SE401  v4l2_fourcc('S', '4', '0', '1') /* se401 
 janggu compressed rgb */
  #define V4L2_PIX_FMT_S5C_UYVY_JPG v4l2_fourcc('S', '5', 'C', 'I') /* S5C73M3 
 interleaved UYVY/JPEG */
  
 +/* SDR */
 +#define V4L2_PIX_FMT_FLOATv4l2_fourcc('D', 'F', '3', '2') /* float 
 32-bit */
 +#define V4L2_PIX_FMT_U8   v4l2_fourcc('D', 'U', '0', '8') /* unsigned 
 8-bit */
 +
  /*
   *   F O R M A T   E N U M E R A T I O N
   */
 diff --git a/lib/libv4lconvert/libv4lconvert.c 
 b/lib/libv4lconvert/libv4lconvert.c
 index e2afc27..38c9125 100644
 --- a/lib/libv4lconvert/libv4lconvert.c
 +++ b/lib/libv4lconvert/libv4lconvert.c
 @@ -78,7 +78,8 @@ static void v4lconvert_get_framesizes(struct 
 v4lconvert_data *data,
   { V4L2_PIX_FMT_RGB24,   24,  1,  5, 0 }, \
   { V4L2_PIX_FMT_BGR24,   24,  1,  5, 0 }, \
   { V4L2_PIX_FMT_YUV420,  12,  6,  1, 0 }, \
 - { V4L2_PIX_FMT_YVU420,  12,  6,  1, 0 }
 + { V4L2_PIX_FMT_YVU420,  12,  6,  1, 0 }, \
 + { V4L2_PIX_FMT_FLOAT,0,  0,  0, 0 }
  
  static const struct v4lconvert_pixfmt supported_src_pixfmts[] = {
   SUPPORTED_DST_PIXFMTS,
 @@ -131,6 +132,8 @@ static const struct v4lconvert_pixfmt 
 supported_src_pixfmts[] = {
   { V4L2_PIX_FMT_Y6,   8, 20, 20, 0 },
   { V4L2_PIX_FMT_Y10BPACK,10, 20, 20, 0 },
   { V4L2_PIX_FMT_Y16, 16, 20, 20, 0 },
 + /* SDR formats */
 + { V4L2_PIX_FMT_U8,  0,  0,  0,  0 },
  };
  
  static const struct v4lconvert_pixfmt supported_dst_pixfmts[] = {
 @@ -1281,6 +1284,25 @@ static int v4lconvert_convert_pixfmt(struct 
 v4lconvert_data *data,
   }
   break;
  
 + /* SDR */
 + case V4L2_PIX_FMT_U8:
 + switch (dest_pix_fmt) {
 + case V4L2_PIX_FMT_FLOAT:
 + {
 + /* 8-bit unsigned to 32-bit float */
 + unsigned int i;
 + float ftmp;
 + for (i = 0; i  src_size; i++) {
 + ftmp = *src++;
 + ftmp -= 127.5;
 + ftmp /= 127.5;
 + memcpy(dest, ftmp, 4);
 + dest += 4;

Replace the 4's with sizeof(float).

You have no guarantees that sizeof(float) == 4, but it is usally a safe
assumption for 'float' on Unix.

sizeof(long double) is certainly different for IA32 machines (80 bits)
vs. other 32 bit platforms.  I was burned by this many years ago on a
RedHat 9.0 machine (the GNU Ada Translator's libm bindings made some bad
assumptions about the size of float types).


 + }
 + }
 + }
 + break;
 +
   

Re: [PATCH v3 04/29] [media] cx18: struct i2c_client is too big for stack

[Andy Walls]

On Tue, 2013-11-05 at 08:01 -0200, Mauro Carvalho Chehab wrote:
   drivers/media/pci/cx18/cx18-driver.c: In function 'cx18_read_eeprom':
   drivers/media/pci/cx18/cx18-driver.c:357:1: warning: the frame size of 
 1072 bytes is larger than 1024 bytes [-Wframe-larger-than=]
 That happens because the routine allocates 256 bytes for an eeprom buffer, 
 plus
 the size of struct i2c_client, with is big.
 Change the logic to dynamically allocate/deallocate space for struct 
 i2c_client,
 instead of  using the stack.
 
 Signed-off-by: Mauro Carvalho Chehab m.che...@samsung.com
 ---
  drivers/media/pci/cx18/cx18-driver.c | 20 
  1 file changed, 12 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/pci/cx18/cx18-driver.c 
 b/drivers/media/pci/cx18/cx18-driver.c
 index ff7232023f56..87f5bcf29e90 100644
 --- a/drivers/media/pci/cx18/cx18-driver.c
 +++ b/drivers/media/pci/cx18/cx18-driver.c
 @@ -324,23 +324,24 @@ static void cx18_eeprom_dump(struct cx18 *cx, unsigned 
 char *eedata, int len)
  /* Hauppauge card? get values from tveeprom */
  void cx18_read_eeprom(struct cx18 *cx, struct tveeprom *tv)
  {
 - struct i2c_client c;
 + struct i2c_client *c;
   u8 eedata[256];
  
 - memset(c, 0, sizeof(c));
 - strlcpy(c.name, cx18 tveeprom tmp, sizeof(c.name));
 - c.adapter = cx-i2c_adap[0];
 - c.addr = 0xA0  1;
 + c = kzalloc(sizeof(*c), GFP_ATOMIC);

Hi Mauro,

GFP_ATOMIC seems overly strict, as this function is not in called in an
atomic context AFAIK.

Maybe use GFP_TEMPORARY or GFP_KERNEL.

Regards,
Andy

 +
 + strlcpy(c-name, cx18 tveeprom tmp, sizeof(c-name));
 + c-adapter = cx-i2c_adap[0];
 + c-addr = 0xa0  1;
  
   memset(tv, 0, sizeof(*tv));
 - if (tveeprom_read(c, eedata, sizeof(eedata)))
 - return;
 + if (tveeprom_read(c, eedata, sizeof(eedata)))
 + goto ret;
  
   switch (cx-card-type) {
   case CX18_CARD_HVR_1600_ESMT:
   case CX18_CARD_HVR_1600_SAMSUNG:
   case CX18_CARD_HVR_1600_S5H1411:
 - tveeprom_hauppauge_analog(c, tv, eedata);
 + tveeprom_hauppauge_analog(c, tv, eedata);
   break;
   case CX18_CARD_YUAN_MPC718:
   case CX18_CARD_GOTVIEW_PCI_DVD3:
 @@ -354,6 +355,9 @@ void cx18_read_eeprom(struct cx18 *cx, struct tveeprom 
 *tv)
   cx18_eeprom_dump(cx, eedata, sizeof(eedata));
   break;
   }
 +
 +ret:
 + kfree(c);
  }
  
  static void cx18_process_eeprom(struct cx18 *cx)


--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Mon, 2013-11-04 at 13:44 +0100, Hans Verkuil wrote:
 On 10/19/2013 07:09 PM, Andy Walls wrote:
  On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote:

  Try applying the following (untested) patch that is made against the
  bleeding edge Linux kernel.  The test on the mute control state in
  wm8775_s_routing() appears to have been inverted in the bad commit you
  isolated.
 
 Aargh! I'm pretty sure that's the culprit. Man, that's been broken for ages.

Hi Hans,

Yes, and only *one* person reported it in those years.  I suspect very
few people use the comination of conventional PCI, analog video, and
SVideo 2 or Composite 2 anymore.


 I'll see if I can test this patch this week.

Thanks!  I'm very busy at work until mid-December.

Regards,
Andy

--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Wed, 2013-10-16 at 01:10 +0100, Rajil Saraswat wrote:
 I was finally able to carry out a git bisect. Had to do a git pull on
 a fast internet hooked machine and ftp the files over to the remote
 machine.
 
 I started with 'git bisect bad v2.6.36.4' and 'git bisect good v2.6.35.10'.
 
 And the result was:
 
 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79 is the first bad commit
 commit 5aa9ae5ed5d449a85fbf7aac3d1fdc241c542a79
 Author: Hans Verkuil hverk...@xs4all.nl
 Date:   Sat Apr 24 08:23:53 2010 -0300
 
 V4L/DVB: wm8775: convert to the new control framework
 
 Signed-off-by: Hans Verkuil hverk...@xs4all.nl
 Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
 
 :04 04 37847ffe592f255c6a9d9daedaf7bbfd3cd7b055
 2f094df6f65d7fb296657619c1ad6f93fe085a75 Mdrivers
 
 I then removed the patch from linux-2.6.36-gentoo-r8 which are gentoo
 sources, and confirmed that video/audio now works fine on v4l2-ctl -d
 /dev/video1 --set-input 4
 
 I wasnt able to remove the patch in 3.10.7 which is gentoo stable
 kernel. Any idea how can i do that?

Try applying the following (untested) patch that is made against the
bleeding edge Linux kernel.  The test on the mute control state in
wm8775_s_routing() appears to have been inverted in the bad commit you
isolated.

Along with '--set-input', you may also want to use v4l2-ctl to exercise
the mute control as well, to see if it works as expected, once this
patch is applied.

Regards,
Andy

file: wm8775_s_route_mute_test_inverted.patch

diff --git a/drivers/media/i2c/wm8775.c b/drivers/media/i2c/wm8775.c
index 3f584a7..bee7946 100644
--- a/drivers/media/i2c/wm8775.c
+++ b/drivers/media/i2c/wm8775.c
@@ -130,12 +130,10 @@ static int wm8775_s_routing(struct v4l2_subdev *sd,
return -EINVAL;
}
state-input = input;
-   if (!v4l2_ctrl_g_ctrl(state-mute))
+   if (v4l2_ctrl_g_ctrl(state-mute))
return 0;
if (!v4l2_ctrl_g_ctrl(state-vol))
return 0;
-   if (!v4l2_ctrl_g_ctrl(state-bal))
-   return 0;
wm8775_set_audio(sd, 1);
return 0;
 }


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

Re: [media-workshop] V2: Agenda for the Edinburgh mini-summit

[Andy Walls]

On Thu, 2013-10-17 at 08:36 +0900, Milo Kim wrote:

  That's current solution, we plan to unify this two API since those
  chip are basically LED.
 
  On the other hands, LM3642 has an indicator mode with flash/torch.
  Then, it will consist of 3 parts - MFD core, LED(indicator) and
  V4L2(flash/torch).
 
 
  So if one LED device driver can support that, we don't need these 3 parts.
 
 Let me clarify our discussion briefly.
 
 For the flash and torch, there are scattered user-space APIs.
 We need to unify them.

Sorry for the late input.

There are also subject matter illuminators (is that the same as torch?).
They may be LED or halogen incadescent bulbs that are integral to a
device such as the QX5 microscope:

http://git.linuxtv.org/media_tree.git/blob/HEAD:/drivers/media/usb/cpia2/cpia2_v4l.c#l1152

The V4L2 user controls ioctl()'s are used to control those two lamps
currently.  Their activation seemed like a switch the user would want to
turn easily, via a GUI that contained other V4L2 device controls.

Do these fit in anywhere into the unification?  Not that I'm advocating
that. I just thought cases like this shouldn't be overlooked in deciding
what to do.

Regards,
Andy

 We are considering supporting V4L2 structures in the LED camera trigger.
 Then, camera application controls the flash/torch via not the LED sysfs 
 but the V4L2 ioctl interface.
 So, changing point is the ledtrig-camera.c. No chip driver changes at all.
 
 Is it correct?
 
 Best regards,
 Milo


--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Sat, 2013-10-12 at 19:23 -0400, Andy Walls wrote:
 On Thu, 2013-10-10 at 22:00 +0100, Rajil Saraswat wrote:
  On 10 October 2013 03:20, Andy Walls awa...@md.metrocast.net wrote:
   On Wed, 2013-09-18 at 02:19 +0530, Rajil Saraswat wrote:
   Hi,
  
I have a couple of PVR-500's which have additional tuners connected
   to them (using daughter cards).
  
   The PVR-500's don't have daughter cards with additional tuners AFAIK.
  
   There is this however:
   http://www.hauppauge.com/site/webstore2/webstore_avcable-pci.asp
  
[snip]
  
The audio is not usable on either
   1.4.2 or 1.4.3 ivtv drivers. The issue is described at
   http://ivtvdriver.org/pipermail/ivtv-users/2013-September/010462.html
  
   With your previous working kernel and with the non-working kernel, what
   is the output of
  
   $ v4l2-ctl -d /dev/videoX --log-status
  
   after you have set up the inputs properly and have a known good signal
   going into the input in question?
  
   I'm speculating this is a problem with the cx25840 driver or the wm8775
   driver, since they change more often than the ivtv driver.
  
  Yes, thats right it is a set of extra inputs and not a separate tuner
  card. I played a video stream fro both kernels. Here are the logs
  
  Working kernel 2.6.35
   v4l2-ctl -d /dev/video1 --log-status
  
  Status Log:
  
 [50885.487963] ivtv1: =  START STATUS CARD #1
  =
 [50885.487967] ivtv1: Version: 1.4.1 Card: WinTV PVR 500 (unit #2)
 [snip]
 [50885.545429] cx25840 2-0044: Video signal:  present
 [50885.545431] cx25840 2-0044: Detected format:   PAL-BDGHI
 [50885.545433] cx25840 2-0044: Specified standard:PAL-BDGHI
 [50885.545435] cx25840 2-0044: Specified video input: Composite 4
 [50885.545437] cx25840 2-0044: Specified audioclock freq: 48000 Hz
 [snip]
 [50885.553121] ivtv1: ==  END STATUS CARD #1
  ==
  
  For the non-working kernel 2.6.37
  
 [  212.730996] ivtv1: =  START STATUS  =
 [  212.731001] ivtv1: Version: 1.4.3 Card: WinTV PVR 500 (unit #2)
 [snip]
 [  212.787820] cx25840 2-0044: Video signal:  present
 [  212.787822] cx25840 2-0044: Detected format:   PAL-BDGHI
 [  212.787823] cx25840 2-0044: Specified standard:PAL-BDGHI
 [  212.787824] cx25840 2-0044: Specified video input: Composite 4
 [snip]
 
 Hmm.  I have a PVR-500, with the extra input cable hooked up to unit #2
 of the PVR-500 and a DTV-to-CVBS converter box connected.
 
 My CVBS signal shows up when I am set to PVR-500  'Input 2, Composite 1'
 which is cx25840 'Composite 3'.  This makes sense for unit #2 of a
 PVR-500. It must have the white connector wired differently from unit #1
 of the PVR-500 (and from the PVR-150), since the PVR-500 unit #2 doesn't
 have a CVBS input connector on the main card.
 
 Are you sure you have the input like this and obtain good video from
 PVR-500 unit #2, when it is set to 'Input 4, Composite 2', cx25840
 'Composite 4'?
 
 Could you try recording with PVR unit #2 set to 'Input 2, Composite 1',
 cx25840 'Composite 3'?  
 
 These are the questions in my mind:
 
 Is your PVR-500 unit #2 wired differently than mine?
 Are the older kernels more forgiving when capturing audio with the wrong
 input set? (Try both Input 2 and Input 4 with both kernels.)


OK, I just tested with my Wii game console connected to the PVR-500 unit
#2, Fedora 17, kernel 3.6.10-2.fc17.x86_64.

1. With the unit set to 'Input 2, Composite 1', cx25840 'Composite 3':
Good video, good audio

2. With the unit set to 'Input 4, Composite 2', cx25840 'Composite 4':
No video, distorted audio.

AFAICT:
You're using the wrong input.
You weren't checking the video, only the audio.

I consider this problem resolved.


  Unfortunately, i cannot do a git bisect since it is a remote system
  with a slow internet connection.

Is this system for personal or professional use?  I don't know of any
home users who have remote sites.

If for professional use, I'd suggest your employer pay a consultant, if
the company/university/whatever can't do a git bisect on a development
system in house.

-Andy

--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Sun, 2013-10-13 at 20:14 +0100, Rajil Saraswat wrote:
  OK, I just tested with my Wii game console connected to the PVR-500 unit
  #2, Fedora 17, kernel 3.6.10-2.fc17.x86_64.
 
  1. With the unit set to 'Input 2, Composite 1', cx25840 'Composite 3':
  Good video, good audio
 
  2. With the unit set to 'Input 4, Composite 2', cx25840 'Composite 4':
  No video, distorted audio.
 
 
 This is what i used to changed the input
 
 v4l2-ctl -d /dev/video1 --set-input 4
 
 With this 2.6.35 gives me perfect video/audio. Kernel 3.10.7 on the
 other hand gives good video but distorted audio. On this cards primary
 input (/dev/video0), i use the radio so i cant use input 2 of this
 card. My composite cable is connected to the 'extra-input' card which
 should be composite 2.
 
 My understanding is input 4 is #2 composite, and input 2 is #1
 composite. Is that not right?

For my PVR-500, it doesn't appear to be.  Here's how I believ it is
wired up:

PVR-500 Left/First half (aka Unit #1)
Tuner TV Composite out  --- CX25843 Analog Input 7--+ 
SVideo 1(rear bracket)  --- CX25843 Analog Inputs 1,5 --+
Composite 1 (rear bracket)  --- CX25843 Analog Input 3--+-- CX25843 
VIP out -- CX23416 VIP In
SVideo 2(white connector)   --- CX25843 Analog Inputs 2,6 --+
Composite 2 (white connector)   --- CX25843 Analog Input 4--+

Tuner SIF audio out   --- CX25843 Analog Input 8
+  

 |  
Tuner TV mono-audio out   --- WM8775 AIN1 L,R --+  
 |  
Audio 1 L,R (rear bracket)--- WM8775 AIN2 L,R --+- WM8775 I2S out -- 
CX25843 I2S 1 In -+- CX25843 I2S out -- CX23416 I2S In
Audio 2 L,R (white connector) --- WM8775 AIN3 L,R --+
Tuner FM audio out L,R--- WM8775 AIN4 L,R --+


PVR-500 Right/Second half (aka Unit #2)
Tuner TV Composite out  --- CX25843 Analog Input 7--+ 
SVideo 1(white connector)   --- CX25843 Analog Inputs 1,5 --+
Composite 1 (white connector)   --- CX25843 Analog Input 3--+-- CX25843 
VIP out -- CX23416 VIP In

Tuner SIF audio out   --- CX25843 Analog Input 8
+  

 |  
Tuner TV mono-audio out   --- WM8775 AIN1 L,R --+  
 |  
Audio 1 L,R (white connector) --- WM8775 AIN2 L,R --+- WM8775 I2S out -- 
CX25843 I2S 1 In -+- CX25843 I2S out -- CX23416 I2S In

So for my PVR-500,
unit #1 Composite 1 is on the card's bracket.
unit #1 Composite 2 is on the white connector.
unit #2 Composite 1 is on the white connector.
unit #2 Composite 2 is not available


 This is what i tried in kernel 2.6.35:
 
 1. v4l2-ctl -d /dev/video1 --set-input 2
 Video input set to 2 (Composite 1: ok)
 No video
 
 2. v4l2-ctl -d /dev/video1 --set-input 4
 Video input set to 4 (Composite 2: ok)
 Good video

If /dev/video1 referes to unit #2 of your PVR-500 (according to v4l2-ctl
-d /dev/video1 --log-status) then it appears your unit is wired
differently than mine.


 As i mentioned in kernel 2.6.35, mythtv/mplayer give me both good
 video/audio if i use 2 above.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/wm8775.c

Shows me no really good reason why the wm8775 driver should have broken.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/cx25840/*[ch]

Show a few conceptually simple changes to the cx25840 driver.  Something
may have broken, but I doubt it.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/cx2341x.c

Shows changes to the control handling.  The ones regarding audio
sampling frequency may be at fault.

$ git diff --color v2.6.35 v2.6.37 drivers/media/video/ivtv/ivtv*[ch]

Shows changes to the irq handling and the control handling.  Again the
controls realted to audio mode and audio sampling rate stand out as
potential causes.

None of the above changes would explain to me why audio on input 3 of
the WM8775 works (for me) but audio on input 4 of the WM8775 does not
work (for you).

I'll have to try additional tests with unit #1 of my PVR-500 later this
week.

  AFAICT:
  You're using the wrong input.
  You weren't checking the video, only the audio.
 
 What inputs do you think i should use with v4l2-ctl?

I have no recommendation at the moment.

If you can do a git bisect please try.
There are 11,117 commits to bisect: that's 15 steps.  Each
bisect/compile/install/test iteration I would estimate takes about 2
hours.

If I can reproduce your problem on a PVR-150 or on unit #1 of my
PVR-500, then I can try to bisect.  But I have no idea when I would have
time to perform the bisection.


   Unfortunately, i cannot do a git bisect since it is a remote system
   with a slow internet connection.
 
  Is this system for personal or professional use?  I don't know of any
  home users who have remote sites.
 
 Your know one 

Re: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Thu, 2013-10-10 at 22:00 +0100, Rajil Saraswat wrote:
 On 10 October 2013 03:20, Andy Walls awa...@md.metrocast.net wrote:
  On Wed, 2013-09-18 at 02:19 +0530, Rajil Saraswat wrote:
  Hi,
 
   I have a couple of PVR-500's which have additional tuners connected
  to them (using daughter cards).
 
  The PVR-500's don't have daughter cards with additional tuners AFAIK.
 
  There is this however:
  http://www.hauppauge.com/site/webstore2/webstore_avcable-pci.asp
 
  Make sure you have any jumpers set properly and the cable connectors
  seated properly.
 
  Also make sure the cable is routed aways from any electrically noisy
  cards and high speed data busses: disk controller cards, graphics cards,
  etc.
 
   The audio is not usable on either
  1.4.2 or 1.4.3 ivtv drivers. The issue is described at
  http://ivtvdriver.org/pipermail/ivtv-users/2013-September/010462.html
 
  With your previous working kernel and with the non-working kernel, what
  is the output of
 
  $ v4l2-ctl -d /dev/videoX --log-status
 
  after you have set up the inputs properly and have a known good signal
  going into the input in question?
 
  I'm speculating this is a problem with the cx25840 driver or the wm8775
  driver, since they change more often than the ivtv driver.
 
 Yes, thats right it is a set of extra inputs and not a separate tuner
 card. I played a video stream fro both kernels. Here are the logs
 
 Working kernel 2.6.35
  v4l2-ctl -d /dev/video1 --log-status
 
 Status Log:
 
[50885.487963] ivtv1: =  START STATUS CARD #1
 =
[50885.487967] ivtv1: Version: 1.4.1 Card: WinTV PVR 500 (unit #2)
[snip]
[50885.545429] cx25840 2-0044: Video signal:  present
[50885.545431] cx25840 2-0044: Detected format:   PAL-BDGHI
[50885.545433] cx25840 2-0044: Specified standard:PAL-BDGHI
[50885.545435] cx25840 2-0044: Specified video input: Composite 4
[50885.545437] cx25840 2-0044: Specified audioclock freq: 48000 Hz
[snip]
[50885.553121] ivtv1: ==  END STATUS CARD #1
 ==
 
 For the non-working kernel 2.6.37
 
[  212.730996] ivtv1: =  START STATUS  =
[  212.731001] ivtv1: Version: 1.4.3 Card: WinTV PVR 500 (unit #2)
[snip]
[  212.787820] cx25840 2-0044: Video signal:  present
[  212.787822] cx25840 2-0044: Detected format:   PAL-BDGHI
[  212.787823] cx25840 2-0044: Specified standard:PAL-BDGHI
[  212.787824] cx25840 2-0044: Specified video input: Composite 4
[snip]

Hmm.  I have a PVR-500, with the extra input cable hooked up to unit #2
of the PVR-500 and a DTV-to-CVBS converter box connected.

My CVBS signal shows up when I am set to PVR-500  'Input 2, Composite 1'
which is cx25840 'Composite 3'.  This makes sense for unit #2 of a
PVR-500. It must have the white connector wired differently from unit #1
of the PVR-500 (and from the PVR-150), since the PVR-500 unit #2 doesn't
have a CVBS input connector on the main card.

Are you sure you have the input like this and obtain good video from
PVR-500 unit #2, when it is set to 'Input 4, Composite 2', cx25840
'Composite 4'?

Could you try recording with PVR unit #2 set to 'Input 2, Composite 1',
cx25840 'Composite 3'?  

These are the questions in my mind:

Is your PVR-500 unit #2 wired differently than mine?
Are the older kernels more forgiving when capturing audio with the wrong
input set? (Try both Input 2 and Input 4 with both kernels.)

 The 3.10.7 kernel has extra wm8775 parameters and  cx25840 parameters
 than 2.6.35.

The cx25840 blurts out IR unit status (ignore it) and the cx5840 user
controls (Volume, Balance, etc.) a little differently,

 Any clues from above?

No.  They look the same for everything that matters.

Regards,
Andy

 Unfortunately, i cannot do a git bisect since it is a remote system
 with a slow internet connection.


--
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: ivtv 1.4.2/1.4.3 broken in recent kernels?

[Andy Walls]

On Wed, 2013-09-18 at 02:19 +0530, Rajil Saraswat wrote:
 Hi,
 
  I have a couple of PVR-500's which have additional tuners connected
 to them (using daughter cards).

The PVR-500's don't have daughter cards with additional tuners AFAIK. 

There is this however:
http://www.hauppauge.com/site/webstore2/webstore_avcable-pci.asp

Make sure you have any jumpers set properly and the cable connectors
seated properly.

Also make sure the cable is routed aways from any electrically noisy
cards and high speed data busses: disk controller cards, graphics cards,
etc.  

  The audio is not usable on either
 1.4.2 or 1.4.3 ivtv drivers. The issue is described at
 http://ivtvdriver.org/pipermail/ivtv-users/2013-September/010462.html

With your previous working kernel and with the non-working kernel, what
is the output of

$ v4l2-ctl -d /dev/videoX --log-status

after you have set up the inputs properly and have a known good signal
going into the input in question?

I'm speculating this is a problem with the cx25840 driver or the wm8775
driver, since they change more often than the ivtv driver.

BTW, I have very little time to fix things nowadays.

Also my development machine with PCI slots is tied up running simulation
experiments for 4 more weeks.  I can't test any fixes until those
simulations are done.

 Is there anything i can do to make kernel 3.10.7 (ivtv 1.4.3) play
 nice with my card?

1. Differential analysis of the v4l2-ctl --log-status output

2. Differential analysis of the kernel source code for the ivtv, cx2580,
and wm8775 drivers.

3. git bisection of the kernel starting from known good and bad kernel
versions, compile kernel, test, repeat.
http://git-scm.com/book/en/Git-Tools-Debugging-with-Git#Binary-Search
http://lwn.net/Articles/317154/

That's what I'd have to do, but it takes time and a setup that is able
to reporduce the problem reliably.

The git bisect is guaranteed to terminate on the problem change, if it
is a software change that caused the problem.

Although it doesn't sound like a hardware problem so far:

If it is a hardware problem induced by a change in hardware, or the way
the hardware is being driven, then verify your cables and any jumpers
and take steps to reduce EMI on the audio lines (move the cables away
from potential noise sources).  Also, if you suspect hardware, remove
*all* the PCI cards, blow the dust out of the PCI slots and reseat them.

Regards,
Andy

--
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 19/26] ivtv: Convert driver to use get_user_pages_unlocked()

[Andy Walls]

Hi Jan:

rant
This patch alone does not have suffcient information for me to evaluate
it.  get_user_pages_unlocked() is added in another patch which I did not
receive, and which I cannot find in any list archives.

I wasted quite a bit of time looking for this additional patch:

https://git.kernel.org/cgit/linux/kernel/git/jack/linux-fs.git/commit/?h=get_user_pagesid=624fc1bfb70fb65d32d31fbd16427ad9c234653e

/rant

If I found the correct patch for adding get_user_pages_unlocked(), then
the patch below looks fine.

Reviewed-by: Andy Walls awa...@md.metrocast.net
Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy

On Wed, 2013-10-02 at 16:28 +0200, Jan Kara wrote:
 CC: Andy Walls awa...@md.metrocast.net
 CC: linux-media@vger.kernel.org
 Signed-off-by: Jan Kara j...@suse.cz
 ---
  drivers/media/pci/ivtv/ivtv-udma.c |  6 ++
  drivers/media/pci/ivtv/ivtv-yuv.c  | 12 ++--
  2 files changed, 8 insertions(+), 10 deletions(-)
 
 diff --git a/drivers/media/pci/ivtv/ivtv-udma.c 
 b/drivers/media/pci/ivtv/ivtv-udma.c
 index 7338cb2d0a38..6012e5049076 100644
 --- a/drivers/media/pci/ivtv/ivtv-udma.c
 +++ b/drivers/media/pci/ivtv/ivtv-udma.c
 @@ -124,10 +124,8 @@ int ivtv_udma_setup(struct ivtv *itv, unsigned long 
 ivtv_dest_addr,
   }
  
   /* Get user pages for DMA Xfer */
 - down_read(current-mm-mmap_sem);
 - err = get_user_pages(current, current-mm,
 - user_dma.uaddr, user_dma.page_count, 0, 1, dma-map, 
 NULL);
 - up_read(current-mm-mmap_sem);
 + err = get_user_pages_unlocked(current, current-mm, user_dma.uaddr,
 +   user_dma.page_count, 0, 1, dma-map);
  
   if (user_dma.page_count != err) {
   IVTV_DEBUG_WARN(failed to map user pages, returned %d instead 
 of %d\n,
 diff --git a/drivers/media/pci/ivtv/ivtv-yuv.c 
 b/drivers/media/pci/ivtv/ivtv-yuv.c
 index 2ad65eb29832..9365995917d8 100644
 --- a/drivers/media/pci/ivtv/ivtv-yuv.c
 +++ b/drivers/media/pci/ivtv/ivtv-yuv.c
 @@ -75,15 +75,15 @@ static int ivtv_yuv_prep_user_dma(struct ivtv *itv, 
 struct ivtv_user_dma *dma,
   ivtv_udma_get_page_info (uv_dma, (unsigned long)args-uv_source, 360 * 
 uv_decode_height);
  
   /* Get user pages for DMA Xfer */
 - down_read(current-mm-mmap_sem);
 - y_pages = get_user_pages(current, current-mm, y_dma.uaddr, 
 y_dma.page_count, 0, 1, dma-map[0], NULL);
 + y_pages = get_user_pages_unlocked(current, current-mm, y_dma.uaddr,
 +   y_dma.page_count, 0, 1, dma-map[0]);
   uv_pages = 0; /* silence gcc. value is set and consumed only if: */
   if (y_pages == y_dma.page_count) {
 - uv_pages = get_user_pages(current, current-mm,
 -   uv_dma.uaddr, uv_dma.page_count, 0, 1,
 -   dma-map[y_pages], NULL);
 + uv_pages = get_user_pages_unlocked(current, current-mm,
 +uv_dma.uaddr,
 +uv_dma.page_count, 0, 1,
 +dma-map[y_pages]);
   }
 - up_read(current-mm-mmap_sem);
  
   if (y_pages != y_dma.page_count || uv_pages != uv_dma.page_count) {
   int rc = -EFAULT;


--
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: Capture driver implementation issue/questions

[Andy Walls]

On Thu, 2013-09-26 at 14:57 +, Rick Ball wrote:
 Hi All,
 
 I'm working on a video capture driver (my first) for a custom board,
 and I have a few questions about handling 'overflow' conditions (when
 the application doesn't get back in time to de-queue every frame). I
 know that one way to avoid this is to allocate additional frame
 buffers, but I'm thinking about conditions where even this doesn't
 provide enough of a FIFO. It looks to me (from studying the videobuf2
 code), that if the buffers all fill up (they all end up on the 'done'
 list), and then the application 'comes back' and starts de-queuing
 buffers, it will get the OLDEST one first, and then, the newer buffers
 will be returned, in the order they were originally captured. For some
 (most?) applications, this is probably what is best, as frames only
 get dropped when they have to, i.e., when the FIFO overflows, and the
 app sees the maximum number of frames. But what about applications
 that always want to see the 'newest' buffer, even if some frames are
 dropped? 
 
 What I would like to do is write my driver such that if a new frame is
 captured before the app has de-queued an earlier frame, the older
 capture buffer would be removed from the done list and re-queued to
 the h/w (it's already still on the queued list, I think). The done
 list would then always contain only 1 frame, and it would be the
 newest frame captured (and the capture hardware would never run out of
 capture buffers to use). I think this would be OK as far as the API is
 concerned - the app shouldn't expect that the buffers will necessarily
 be returned in the order they were queued, right? 


Hi Rick,

 So here are the questions:
 
 1. Does this make sense, or am I wanting to do something that isn't
 reasonable (or do I not understand the framework)?

In my opinion, if a driver has to drop data, it should prefer to drop
the oldest data.  Although for TV program video/audio, it doesn't really
matter.

Both the ivtv driver and cx18 driver, under certain circumstances,
recover internal buffers that userspace has delayed too long in reading.

ivtv_queue_move(), for example, has a steal argument to sometimes
steals from the end of internal queues.

cx18_stream_rotate_idx_mdls() steals from the head of its particular
buffer queue.

Both of these drivers use their own internal queueing mechanism though,
so they don't help with understanding videobuf. 

I do not think having a queue with only 1 frame in it makes sense.  I'm
not quite sure what you're aiming to do with that.  You might end up
inadventantly forcing synchronization of userspace to the driver (via a
spinlock or mutex), which could be a problem with live playback.

If userspace can't keep up reading buffers, you should try and examine
your system and figure out why.

 2. Is there any way to do this within the current videobuf2 framework?
 3. If not, do you have any suggestions on changes to make this
 possible? I'm thinking that we would need a new function that would be
 called (probably from an ISR, just before calling vb2_buffer_done on
 the new buffer) 

An ISR?  From an interrupt generated by what exactly?  This doesn't
sound like a good idea to me.

Buffer manipulations shouldn't be handled from an hard IRQ (atomic)
context anyway.  Do this in the work handler, threaded irq handler, or
kthread, that normally handles buffer handoffs to and from the
hardware. 

The only time you need to steal buffers is when the hardware dma engine
is starved of buffers (for incoming data) or you have no buffers for
feeding thw hardware (to send data out).   

 that would remove the older buffer from the done queue, re-increment
 the 'queued_count', and call the 'buf_queue' function provided by the
 driver to re-queue the older buffer to the h/w. Am I missing anything?

I don't know much about videobuf[2], so I can't help with that.

Regards,
Andy

 Thanks,
 
 Rick


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

Re: [PATCH 1/3] media: i2c: Add ADV761X support

[Andy Walls]

Hans Verkuil hverk...@xs4all.nl wrote:
On 09/24/2013 06:19 PM, Guennadi Liakhovetski wrote:
 Hi Hans
 
 On Tue, 24 Sep 2013, Hans Verkuil wrote:
 
 Shouldn't the interrupt_service_routine() op be implemented as well?
 Usually these drivers will generate interrupts if e.g. the format
changes.
 
 Should it? AFAIU, .interrupt_service_routine() is a subde operation
to be 
 called by a bridge driver, when it gets an interrupt for the
respective 
 subdevice:
 
interrupt_service_routine: Called by the bridge chip's interrupt
service
  handler, when an interrupt status has be raised due to this subdev,
   typo ^^
 
  so that this subdev can handle the details.  It may schedule work to
be
  performed later.  It must not sleep.  *Called from an IRQ context*.

Hmm, I have serious doubts whether the It must not sleep.  *Called
from an IRQ context*.
part is correct. I have to check that. I think it is actually the
opposite,
especially since most i2c drivers will have to do i2c accesses which
can always
sleep.

 
 In this case the device does indeed have 2 interrupt output lines,
but I 
 don't think they would be connected to dedicated bridge inputs,
rather to 
 GPIOs, so, the driver can implement an ISR itself, when it decides to

 implement support for those interrupts.

That's another option. But this driver implements neither option, which
is
unusual.

Regards,

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

The comment of the subdev irq handler op is (mine and) wrong.

If a bridge driver knows a subdev has direct register access and doesn't sleep, 
then the op can be called from an irq context.  (Although RT folks might not 
like it.)

If a bridge driver doesn't know about the subdev implementation, then to be 
safe, the brige driver should call from a workqueue, threaded irq handler, 
kthread, etc.

Regards,
Andy
--
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: dvb_device_open: possible circular locking dependency detected

[Andy Walls]

Knut Petersen knut_peter...@t-online.de wrote:
As long as I use the Hauppauge WinTV Nova-HD-S2, nobody seems to be
really interested in silencing deadlock warnings triggered by
dvb_device_open().

dvb lockdep problems are old, see Andy Walls mail written in 2010
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/27027,
but they still
exist.


[  186.583006] ==
[  186.583009] [ INFO: possible circular locking dependency detected ]
[  186.583013] 3.11.0-rc6-main+ #29 Not tainted
[  186.583016] ---
[  186.583019] kaffeine/1986 is trying to acquire lock:
[  186.583022]  (fe-lock){+.+.+.}, at: [f8c4a0d9]
videobuf_dvb_find_frontend+0x1b/0x43 [videobuf_dvb]
[  186.583036]
[  186.583036] but task is already holding lock:
[  186.583039]  (minor_rwsem){..}, at: [f8c340a1]
dvb_device_open+0x26/0xfa [dvb_core]
[  186.583054]
[  186.583054] which lock already depends on the new lock.
[  186.583054]
[  186.583058]
[  186.583058] the existing dependency chain (in reverse order) is:
[  186.583062]
[  186.583062] - #2 (minor_rwsem){..}:
[  186.583068][c01682d4] lock_acquire+0x9b/0xd5
[  186.583077][c0532cea] down_write+0x20/0x3c
[  186.583084][f8c343f8] dvb_register_device+0x158/0x20a
[dvb_core]
[  186.583093][f8c3a28a] dvb_register_frontend+0x15b/0x18d
[dvb_core]
[  186.583104][f8c4a297] videobuf_dvb_register_bus+0xd1/0x2c7
[videobuf_dvb]
[  186.583110][f8c51eb1] cx8802_dvb_probe+0x201b/0x2136
[cx88_dvb]
[  186.583118][f851787b] cx8802_register_driver+0x121/0x1f7
[cx8802]
[  186.583129][f8c5f01c] 0xf8c5f01c
[  186.583135][c01003b5] do_one_initcall+0x6f/0xea
[  186.583140][c0170443] load_module+0x168a/0x1985
[  186.583146][c01707b7] SyS_init_module+0x79/0x91
[  186.583151][c0535045] syscall_call+0x7/0xb
[  186.583156]
[  186.583156] - #1 (dvbdev_register_lock){+.+.+.}:
[  186.583162][c01682d4] lock_acquire+0x9b/0xd5
[  186.583167][c05326a1] mutex_lock_nested+0x3a/0x298
[  186.583172][f8c342c2] dvb_register_device+0x22/0x20a
[dvb_core]
[  186.583181][f8c34968] dvb_dmxdev_init+0xbb/0xf7 [dvb_core]
[  186.583189][f8c4a33f]
videobuf_dvb_register_bus+0x179/0x2c7 [videobuf_dvb]
[  186.583195][f8c51eb1] cx8802_dvb_probe+0x201b/0x2136
[cx88_dvb]
[  186.583202][f851787b] cx8802_register_driver+0x121/0x1f7
[cx8802]
[  186.583208][f8c5f01c] 0xf8c5f01c
[  186.583212][c01003b5] do_one_initcall+0x6f/0xea
[  186.583217][c0170443] load_module+0x168a/0x1985
[  186.583221][c01707b7] SyS_init_module+0x79/0x91
[  186.583226][c0535045] syscall_call+0x7/0xb
[  186.583231]
[  186.583231] - #0 (fe-lock){+.+.+.}:
[  186.583237][c01677cd] __lock_acquire+0xebd/0x154c
[  186.583242][c01682d4] lock_acquire+0x9b/0xd5
[  186.583246][c05326a1] mutex_lock_nested+0x3a/0x298
[  186.583251][f8c4a0d9] videobuf_dvb_find_frontend+0x1b/0x43
[videobuf_dvb]
[  186.583257][f8c4fcef] cx88_dvb_bus_ctrl+0x25/0x9d
[cx88_dvb]
[  186.583263][f8c39e63] dvb_frontend_open+0x12f/0x2ca
[dvb_core]
[  186.583273][f8c34103] dvb_device_open+0x88/0xfa [dvb_core]
[  186.583281][c01db1ab] chrdev_open+0xfc/0x11c
[  186.583287][c01d6332] do_dentry_open+0x169/0x203
[  186.583293][c01d656f] finish_open+0x2c/0x37
[  186.583297][c01e2b45] do_last+0x818/0xa03
[  186.583303][c01e2f35] path_openat+0x205/0x4d2
[  186.583308][c01e343d] do_filp_open+0x2a/0x63
[  186.583312][c01d749e] do_sys_open+0x140/0x1bb
[  186.583317][c01d7536] SyS_open+0x1d/0x1f
[  186.583322][c0535045] syscall_call+0x7/0xb
[  186.583327]
[  186.583327] other info that might help us debug this:
[  186.583327]
[  186.583331] Chain exists of:
[  186.583331]   fe-lock -- dvbdev_register_lock -- minor_rwsem
[  186.583331]
[  186.583340]  Possible unsafe locking scenario:
[  186.583340]
[  186.583343]CPU0CPU1
[  186.583346]
[  186.583348]   lock(minor_rwsem);
[  186.583352] lock(dvbdev_register_lock);
[  186.583357]lock(minor_rwsem);
[  186.583361]   lock(fe-lock);
[  186.583365]
[  186.583365]  *** DEADLOCK ***
[  186.583365]
[  186.583369] 2 locks held by kaffeine/1986:
[  186.583372]  #0:  (dvbdev_mutex){+.+...}, at: [f8c34097]
dvb_device_open+0x1c/0xfa [dvb_core]
[  186.583385]  #1:  (minor_rwsem){..}, at: [f8c340a1]
dvb_device_open+0x26/0xfa [dvb_core]
[  186.583398]
[  186.583398] stack backtrace:
[  186.583403] CPU: 0 PID: 1986 Comm: kaffeine Not tainted
3.11.0-rc6-main+ #29
[  186.583406] Hardware name:/i915GMm-HFS, BIOS 6.00 PG 09/14/2005
[  186.583410]   c0a3600c f0d79c5c c052f17a f0d79c8c c052d253
c06b1687 c06b1553
[  186.583421]  c06b151b c06b153c c06b151b

Re: Fw: [PATCH] Fixed misleading error when handling IR interrupts.

[Andy Walls]

Date: Thu, 11 Jul 2013 17:02:44 +0100
From: Luis Alves lja...@gmail.com
To: linux-media@vger.kernel.org
Cc: mche...@infradead.org, cr...@iki.fi, Luis Alves lja...@gmail.com
Subject: [PATCH] Fixed misleading error when handling IR interrupts.


Hi,
Handling the AV Core/IR interrupts schedules its workqueue but
the schedule_work function returns false if @work was already on the
kernel-global workqueue and true otherwise.

Printing an error message if @work wasn't in the queue is wrong.

Regards,
Luis


Yes, the use of the return value is wrong (at least since 2.6.32).  I must have 
misinterpreted the meaning of the return value when I added in that error 
message long ago.

Regards,
Andy

Acked-by: Andy Walls awa...@md.metrocast.net

Signed-off-by: Luis Alves lja...@gmail.com
---
 drivers/media/pci/cx23885/cx23885-core.c |5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-core.c
b/drivers/media/pci/cx23885/cx23885-core.c
index 268654a..9f63d93 100644
--- a/drivers/media/pci/cx23885/cx23885-core.c
+++ b/drivers/media/pci/cx23885/cx23885-core.c
@@ -1941,10 +1941,7 @@ static irqreturn_t cx23885_irq(int irq, void
*dev_id)
 
   if ((pci_status  pci_mask)  PCI_MSK_AV_CORE) {
   cx23885_irq_disable(dev, PCI_MSK_AV_CORE);
-  if (!schedule_work(dev-cx25840_work))
-  printk(KERN_ERR %s: failed to set up deferred work for
-  AV Core/IR interrupt. Interrupt is disabled
-  and won't be re-enabled\n, dev-name);
+  schedule_work(dev-cx25840_work);
   handled++;
   }
 


--
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: A false alarm for recursive lock in v4l2_ctrl_add_handler

[Andy Walls]

Su Jiaquan jiaquan@gmail.com wrote:
Hi Hans,

On Wed, Aug 21, 2013 at 7:47 PM, Hans Verkuil hverk...@xs4all.nl
wrote:
 On Wed 21 August 2013 12:56:21 Su Jiaquan wrote:
 Hi Hans,

 Recently when we enable LOCKDEP in our kernel, it detected a
possible
 recursive locking. As we check the code, we found that it's just a
 false alarm, the conceived scenario should never happen. Shell I
 submit a patch to suppress it?

 A patch went in for 3.10 that suppresses this false alarm.

 Regards,

 Hans


Sorry I didn't notice the fix, Is it this one?

commit 6cd247ef22e493e1884e576c01538b031981
Author: Andy Walls awa...@md.metrocast.net
Date:   Sat Mar 9 05:55:11 2013 -0300

[media] v4l2-ctrls: eliminate lockdep false alarms for struct
v4l2_ctrl_handler.lock


Yes.

Regards,
Andy

Thanks!

Jiaquan



--
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] cx23885[v4]: Fix interrupt storm when enabling IR receiver.

[Andy Walls]

On Wed, 2013-07-24 at 14:06 +0100, Luis Alves wrote:
 Hi,
 Removed wrong description in the header file. Sorry about that...
 
 New patch for this issue. Changes:
  - Added flatiron readreg and writereg functions prototypes (new header file).
  - Modified the av work handler to preserve all other register bits when 
 dealing
with the interrupt flag.
 
 Regards,
 Luis
 
 
 Signed-off-by: Luis Alves lja...@gmail.com

Looks OK to me.
Theoretically you did'nt need to bitwise-OR in the 0x80, e.g.

cx23885_flatiron_write(dev, 0x1f,
cx23885_flatiron_read(dev, 0x1f));

should work as well, since the set interrupt status bit will clear that
bit on the write back of the bit.

But this patch is good enough. :)

Acked-by: Andy Walls awa...@md.metrocast.net

 ---
  drivers/media/pci/cx23885/cx23885-av.c|   13 +
  drivers/media/pci/cx23885/cx23885-video.c |4 ++--
  drivers/media/pci/cx23885/cx23885-video.h |   26 ++
  3 files changed, 41 insertions(+), 2 deletions(-)
  create mode 100644 drivers/media/pci/cx23885/cx23885-video.h
 
 diff --git a/drivers/media/pci/cx23885/cx23885-av.c 
 b/drivers/media/pci/cx23885/cx23885-av.c
 index e958a01..c443b7a 100644
 --- a/drivers/media/pci/cx23885/cx23885-av.c
 +++ b/drivers/media/pci/cx23885/cx23885-av.c
 @@ -23,6 +23,7 @@
  
  #include cx23885.h
  #include cx23885-av.h
 +#include cx23885-video.h
  
  void cx23885_av_work_handler(struct work_struct *work)
  {
 @@ -32,5 +33,17 @@ void cx23885_av_work_handler(struct work_struct *work)
  
   v4l2_subdev_call(dev-sd_cx25840, core, interrupt_service_routine,
PCI_MSK_AV_CORE, handled);
 +
 + /* Getting here with the interrupt not handled
 +then probbaly flatiron does have pending interrupts.
 + */
 + if (!handled) {
 + /* clear left and right adc channel interrupt request flag */
 + cx23885_flatiron_write(dev, 0x1f,
 + cx23885_flatiron_read(dev, 0x1f) | 0x80);
 + cx23885_flatiron_write(dev, 0x23,
 + cx23885_flatiron_read(dev, 0x23) | 0x80);
 + }
 +
   cx23885_irq_enable(dev, PCI_MSK_AV_CORE);
  }
 diff --git a/drivers/media/pci/cx23885/cx23885-video.c 
 b/drivers/media/pci/cx23885/cx23885-video.c
 index e33d1a7..f4e7cef 100644
 --- a/drivers/media/pci/cx23885/cx23885-video.c
 +++ b/drivers/media/pci/cx23885/cx23885-video.c
 @@ -417,7 +417,7 @@ static void res_free(struct cx23885_dev *dev, struct 
 cx23885_fh *fh,
   mutex_unlock(dev-lock);
  }
  
 -static int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
 +int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data)
  {
   /* 8 bit registers, 8 bit values */
   u8 buf[] = { reg, data };
 @@ -428,7 +428,7 @@ static int cx23885_flatiron_write(struct cx23885_dev 
 *dev, u8 reg, u8 data)
   return i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
  }
  
 -static u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
 +u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg)
  {
   /* 8 bit registers, 8 bit values */
   int ret;
 diff --git a/drivers/media/pci/cx23885/cx23885-video.h 
 b/drivers/media/pci/cx23885/cx23885-video.h
 new file mode 100644
 index 000..c961a2b
 --- /dev/null
 +++ b/drivers/media/pci/cx23885/cx23885-video.h
 @@ -0,0 +1,26 @@
 +/*
 + *  Driver for the Conexant CX23885/7/8 PCIe bridge
 + *
 + *  Copyright (C) 2010  Andy Walls awa...@md.metrocast.net
 + *
 + *  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.
 + *
 + *  You should have received a copy of the GNU General Public License
 + *  along with this program; if not, write to the Free Software
 + *  Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
 + *  02110-1301, USA.
 + */
 +
 +#ifndef _CX23885_VIDEO_H_
 +#define _CX23885_VIDEO_H_
 +int cx23885_flatiron_write(struct cx23885_dev *dev, u8 reg, u8 data);
 +u8 cx23885_flatiron_read(struct cx23885_dev *dev, u8 reg);
 +#endif


--
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] cx23885[v2]: Fix IR interrupt storm.

[Andy Walls]

Luis Alves lja...@gmail.com wrote:

Hi Max,

Should have thought on that! I'll change it to preserve all other bits.

Thanks,
Luis


On Fri, Jul 19, 2013 at 4:37 AM, nibble.max nibble@gmail.com
wrote:
 Hello Luis,
 The internel interrupts are rounted as follow:
 flatiron(include ADC)---HammerHead(include IR inside)---Pecos(PCIe)
 The flatiron interrupt is enabled when chip power up.
 When HammerHead interrupt is enalbe in Pecos, the most of interrupts
are coming from flatiron.
 The more accurate code is that reading back these left and right
registers(0x1f, 0x23), set its bit-7 to 1 , then write back.
 So that it does not touch other bits.
 BR,
 Max

Hi all,
This path is meant to be up-streamed.

Andy has a nice explanation for the interrupt storm when
enabling the IR interrupt:

The flatiron core (the audio adc) signals the end of its self-test
with an interrupt. Since the flatiron irq seems OR-wired
with the IR irq the result is this interrupt storm.
This i2c tranfers will clear the flatiron interrupts - the left
and right channels self-tests.

Also as suggested by Andy I moved the i2c transfers to the
cx23885 av core interrupt handling worker. If any spurious
interrupt happens we silence them.

The flatiron has some dedicated register read/write functions but are
not exported so Antti just suggested to call the i2c_transfer
directly.

Tested in the TBS6981 Dual DVB-S2 card.

PS: I've found this i2c_transfers in TBS media tree, more precisely
in the cx23885-i2c.c file.

Regards,
Luis


Signed-off-by: Luis Alves lja...@gmail.com
---
 drivers/media/pci/cx23885/cx23885-av.c |   17 +
 1 file changed, 17 insertions(+)

diff --git a/drivers/media/pci/cx23885/cx23885-av.c
b/drivers/media/pci/cx23885/cx23885-av.c
index e958a01..d33570f 100644
--- a/drivers/media/pci/cx23885/cx23885-av.c
+++ b/drivers/media/pci/cx23885/cx23885-av.c
@@ -29,8 +29,25 @@ void cx23885_av_work_handler(struct work_struct
*work)
   struct cx23885_dev *dev =
  container_of(work, struct cx23885_dev,
cx25840_work);
   bool handled;
+  char buffer[2];
+  struct i2c_msg msg = {
+  .addr = 0x98  1,
+  .flags = 0,
+  .len = 2,
+  .buf = buffer,
+  };

   v4l2_subdev_call(dev-sd_cx25840, core,
interrupt_service_routine,
PCI_MSK_AV_CORE, handled);
+
+  if (!handled) {
+  /* clear any pending flatiron interrupts */
+  buffer[0] = 0x1f;
+  buffer[1] = 0x80;
+  i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+  buffer[0] = 0x23;
+  i2c_transfer(dev-i2c_bus[2].i2c_adap, msg, 1);
+  }
+
   cx23885_irq_enable(dev, PCI_MSK_AV_CORE);
 }
--
1.7.9.5

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


Yup, I was going to suggest that.

At that point you'll want to put prototypes for cx23885_flatiron_read/write() 
in a header file and remove any static keyword in front of the function 
definitions in cx23885-video.c.

Using those functions will make the change easier to read.

Regards,
Andy
--
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] cx23885: Fix interrupt storm that happens in some cards when IR is enabled.

[Andy Walls]

On Wed, 2013-07-17 at 22:41 -0400, Devin Heitmueller wrote:
 On Wed, Jul 17, 2013 at 10:15 PM, Antti Palosaari cr...@iki.fi wrote:
  hmm, I looked again the cx23885 driver.
 
  0x4c == [0x98  1] = flatiron == some internal block of the chip
 
 Yeah, ok.  Pretty sure Flatiron is the codename for the ADC for the SIF.
 
  There is routine which dumps registers out, 0x00 - 0x23
  cx23885_flatiron_dump()
 
  There is also existing routine to write those Flatiron registers. So, that
  direct I2C access could be shorten to:
  cx23885_flatiron_write(dev, 0x1f, 0x80);
  cx23885_flatiron_write(dev, 0x23, 0x80);
 
 Yeah, the internal register routines should be used to avoid confusion.
 
  Unfortunately these two register names are not defined. Something clock or
  interrupt related likely.
 
 Strange.  The ADC output is usually tied directly to the Merlin.  I
 wonder why it would ever generate interrupts.

The CX2310[012] datasheet has a very short description of these Flatiron
registers.

Apparently the Flatiron genereates an interrupt after the built-in self
test for each of its left and right channels has completed.

Apparently Conexant wire-OR'ed the Flatiron's interrupt output with the
interrupt output of the CX23885 A/V core.



 No easy answers here.  WIll probably have to take a closer look at the
 datasheet, or just ask Andy.

The I2C writes clear the interrupt status of the built in self test
status interrupt for the left and right channels respectively.

It would be best to do this after any spurious A/V core interrupt is
detected from a CX23885.  Since they are I2C writes, they have to be
done in a non-IRQ context, as are the IR unit manipulations.

Regards,
Andy



--
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 00/50] USB: cleanup spin_lock in URB-complete()

[Andy Walls]

On Thu, 2013-07-11 at 17:05 +0800, Ming Lei wrote:
 Hi,
 
 As we are going to run URB-complete() in tasklet context[1][2],

Hi,

Please pardon my naivete, but why was it decided to use tasklets to
defer work, as opposed to some other deferred work mechanism?

It seems to me that getting rid of tasklets has been an objective for
years:

http://lwn.net/Articles/239633/
http://lwn.net/Articles/520076/
http://lwn.net/Articles/240054/


Regards,
Andy

  and
 hard interrupt may be enabled when running URB completion handler[3],
 so we might need to disable interrupt when acquiring one lock in
 the completion handler for the below reasons:
 
 - URB-complete() holds a subsystem wide lock which may be acquired
 in another hard irq context, and the subsystem wide lock is acquired
 by spin_lock()/read_lock()/write_lock() in complete()
 
 - URB-complete() holds a private lock with 
 spin_lock()/read_lock()/write_lock()
 but driver may export APIs to make other drivers acquire the same private
 lock in its interrupt handler.
 
 For the sake of safety and making the change simple, this patch set
 converts all spin_lock()/read_lock()/write_lock() in completion handler
 path into their irqsave version mechanically.
 
 But if you are sure the above two cases do not happen in your driver,
 please let me know and I can drop the unnecessary change.
 
 Also if you find some conversions are missed, also please let me know so
 that I can add it in the next round.
 
 
 [1], http://marc.info/?l=linux-usbm=137286322526312w=2
 [2], http://marc.info/?l=linux-usbm=137286326726326w=2
 [3], http://marc.info/?l=linux-usbm=137286330626363w=2
 
[snip]
 
 
 Thanks,
 --
 Ming Lei


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

Re: [RFC 1/3] saa7115: Set saa7113 init to values from datasheet

[Andy Walls]

Mauro Carvalho Chehab mche...@redhat.com wrote:

Em Wed, 29 May 2013 22:41:16 +0200
Jon Arne Jørgensen jona...@jonarne.no escreveu:

 Change all default values in the initial setup table to match the
table
 in the datasheet.

This is not a good idea, as it can produce undesired side effects
on the existing drivers that depend on it, and can't be easily
tested.

Please, don't change the current default. It is, of course, OK
to change them if needed via the information provided inside the
platform data.

Regards,
Mauro
 
 Signed-off-by: Jon Arne Jørgensen jona...@jonarne.no
 ---
  drivers/media/i2c/saa7115.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)
 
 diff --git a/drivers/media/i2c/saa7115.c
b/drivers/media/i2c/saa7115.c
 index d6f589a..4403679 100644
 --- a/drivers/media/i2c/saa7115.c
 +++ b/drivers/media/i2c/saa7115.c
 @@ -223,12 +223,12 @@ static const unsigned char saa7111_init[] = {
  static const unsigned char saa7113_init[] = {
  R_01_INC_DELAY, 0x08,
  R_02_INPUT_CNTL_1, 0xc2,
 -R_03_INPUT_CNTL_2, 0x30,
 +R_03_INPUT_CNTL_2, 0x33,
  R_04_INPUT_CNTL_3, 0x00,
  R_05_INPUT_CNTL_4, 0x00,
 -R_06_H_SYNC_START, 0x89,
 +R_06_H_SYNC_START, 0xe9,
  R_07_H_SYNC_STOP, 0x0d,
 -R_08_SYNC_CNTL, 0x88,
 +R_08_SYNC_CNTL, 0x98,
  R_09_LUMA_CNTL, 0x01,
  R_0A_LUMA_BRIGHT_CNTL, 0x80,
  R_0B_LUMA_CONTRAST_CNTL, 0x47,
 @@ -236,11 +236,11 @@ static const unsigned char saa7113_init[] = {
  R_0D_CHROMA_HUE_CNTL, 0x00,
  R_0E_CHROMA_CNTL_1, 0x01,
  R_0F_CHROMA_GAIN_CNTL, 0x2a,
 -R_10_CHROMA_CNTL_2, 0x08,
 +R_10_CHROMA_CNTL_2, 0x00,
  R_11_MODE_DELAY_CNTL, 0x0c,
 -R_12_RT_SIGNAL_CNTL, 0x07,
 +R_12_RT_SIGNAL_CNTL, 0x01,
  R_13_RT_X_PORT_OUT_CNTL, 0x00,
 -R_14_ANAL_ADC_COMPAT_CNTL, 0x00,
 +R_14_ANAL_ADC_COMPAT_CNTL, 0x00,/* RESERVED */
  R_15_VGATE_START_FID_CHG, 0x00,
  R_16_VGATE_STOP, 0x00,
  R_17_MISC_VGATE_CONF_AND_MSB, 0x00,


-- 

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

I was going to make a comment along the same line as Mauro.  
Please leave the driver defaults alone.  It is almost impossible to regression 
test all the different devices with a SAA7113 chip, to ensure the change 
doesn't cause someone's device to not work properly.

Regards,
Andy

--
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: saa7115/gm7113c - device specific initialization

[Andy Walls]

Jon Arne Jørgensen jona...@jonarne.no wrote:

Hi,
I've recently discovered that the smi2021 device have some pretty
specific
needs for the setup of the gm7113c chip.

Both the smi2021 driver and the stk1160 driver needs registers
0x14 - 0x17 to be zeroed, this is what forced me to add the gm7113c
chip to the saa7115 driver in the first place.

Then Timo reported that the Terratec Grabby hwrev2 needs some of the
initial register settings to be changed for the device to work.
He posted a small list of required changes.
One of these changes is a change to register 0x12 which sets
up what to output on the RTS0 pin on the chip.

Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
to be generated by VREF - whatever that means :).
That is, I need bit 7 to be clear and bit 6 to be set in register 0x10.
To have the device behave correctly.

Both the change for the smi2021 driver and the changes for the Terratec
device are pretty hardware specific.
They should probably not be part of the generic gm7113c setup.

I would also guess that if other devices with the gm7113c chip should
surface, these devices might also have different needs for the setup of
the chip.

I'm not sure what would be the correct way to handle these
differences.
The only sollution I'we tried is to bypass the saa7115
driver, and push the needed changes directly over usb to the device,
after the initial setup is sent by the saa7115 driver.
This is a major hack, and the changes should probably go through
the saa7115 driver.

Should the saa7115 driver be extended with an interface to change
random
register settings, or does the i2c subsystem already have a way to
handle this?

Any idea about what might could be a better sollution?

Best regards
Jon Arne Jørgensen

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

For v4l2_subdev's there is a way to pass in platform/bridge device specific 
data so initialization can be different than the default, based on the needs of 
the bridge driver.

As for the meaning of the V (Vertical) flag in Start Active Video (SAV) / End 
Active Video (EAV) markers, the VESA VIP 1.x standard explains that.  Basically 
they are codes embedded in digitized video rasters horizontal blanking interval 
that describe the current video line and delimit their start and end.

The V flag probably means a line in the vertical blanking interval (VBI), but I 
can't recall.

Regards,
Andy
--
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: saa7115/gm7113c - device specific initialization

[Andy Walls]

Jon Arne Jørgensen jona...@jonarne.no wrote:

On Mon, May 20, 2013 at 06:33:20AM -0400, Andy Walls wrote:
 Jon Arne Jørgensen jona...@jonarne.no wrote:
 
 Hi,
 I've recently discovered that the smi2021 device have some pretty
 specific
 needs for the setup of the gm7113c chip.
 
 Both the smi2021 driver and the stk1160 driver needs registers
 0x14 - 0x17 to be zeroed, this is what forced me to add the gm7113c
 chip to the saa7115 driver in the first place.
 
 Then Timo reported that the Terratec Grabby hwrev2 needs some of the
 initial register settings to be changed for the device to work.
 He posted a small list of required changes.
 One of these changes is a change to register 0x12 which sets
 up what to output on the RTS0 pin on the chip.
 
 Then I discovered that the smi2021 needs the V-Flag in the SAV/EAV
 to be generated by VREF - whatever that means :).
 That is, I need bit 7 to be clear and bit 6 to be set in register
0x10.
 To have the device behave correctly.
 
 Both the change for the smi2021 driver and the changes for the
Terratec
 device are pretty hardware specific.
 They should probably not be part of the generic gm7113c setup.
 
 I would also guess that if other devices with the gm7113c chip
should
 surface, these devices might also have different needs for the setup
of
 the chip.
 
 I'm not sure what would be the correct way to handle these
 differences.
 The only sollution I'we tried is to bypass the saa7115
 driver, and push the needed changes directly over usb to the device,
 after the initial setup is sent by the saa7115 driver.
 This is a major hack, and the changes should probably go through
 the saa7115 driver.
 
 Should the saa7115 driver be extended with an interface to change
 random
 register settings, or does the i2c subsystem already have a way to
 handle this?
 
 Any idea about what might could be a better sollution?
 
 Best regards
 Jon Arne Jørgensen
 
 --
 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
 
 For v4l2_subdev's there is a way to pass in platform/bridge device
specific data so initialization can be different than the default,
based on the needs of the bridge driver.

Ok, can you give any pointers to any documentation/source files I can
look at for this?

 
 As for the meaning of the V (Vertical) flag in Start Active Video
(SAV) / End Active Video (EAV) markers, the VESA VIP 1.x standard
explains that.  Basically they are codes embedded in digitized video
rasters horizontal blanking interval that describe the current video
line and delimit their start and end.
 
 The V flag probably means a line in the vertical blanking interval
(VBI), but I can't recall.
 

I'm sorry, I was a bit quick with that comment.
I know what the SAV/EAV and V-flag is. I just don't know what it means
that the V-flag is
generated by VREF.

 Regards,
 Andy
 --
 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

http://lxr.free-electrons.com/source/drivers/media/i2c/wm8775.c#L232

The bttv driver, IIRC, has the wm8775 driver initialize differently for the 
Nova S card.  FWIW, the defaults for the wm8775 driver are generally those 
needed by the ivtv driver.

Regards,
Andy
--
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: cx18 list corruption and related problems

[Andy Walls]

On Tue, 2013-04-09 at 10:50 +0100, Tvrtko Ursulin wrote:
 Hi Andy, all,
 
 Were there any known problems in the cx18 locking department regarding video 
 buffers or mailbox handling fixed sometime between 3.5.0 and today?

No.
 
 We are seeing some issues there (on a flavour of 3.5.0) and I just wanted to 
 quickly check here before diving in the code. I'll paste below some of the 
 problems we are seeing.
 
  cx18-0: Skipped encoder PCM audio, MDL 223, 62 times - it must have dropped 
 out of rotation
 
  cx18-0: Could not find MDL 358 for stream encoder PCM audio
  cx18-0: Skipped encoder PCM audio, MDL 357, 62 times - it must have dropped 
 out of rotation
  cx18-0: Could not find MDL 218 for stream encoder PCM audio
  cx18-0: Skipped encoder PCM audio, MDL 217, 62 times - it must have dropped 
 out of rotation

These messages are normal.  The cx18 driver is indirectly telling you
that your system is too slow in responding to hardware interrupts for
the mentioned PCM audio buffers.  The cx18 driver is directly telling
you that it noticed the problem and is sweeping up lost (actually,
incorrectly marked) buffers as it notices them.

_Normally_ the performance problem is not caused by the cx18 driver, but
by another Linux driver's IRQ handler being poorly written.  A very busy
system can also be to blame.

Since you are using YUV video with cx18, which the cx18 driver
inefficiently has the CPU copying buffers, the cx18 driver handling YUV
might be part of your system's performance problem.  It is doubtful
though.

  [ cut here ]
  WARNING: at lib/list_debug.c:59 __list_del_entry+0xa1/0xd0()
  Hardware name: 
  list_del corruption. prev-next should be 8800371d1d40, but was 
 dead00100100
  Modules linked in: tun dummy ip6t_REJECT snd_dummy w83627ehf hwmon_vid 
 cx18_alsa mxl5005s s5h1409 tuner_simple tuner_types cs5345 tda9887 tda8290 
 tuner snd_hda_codec_realtek snd_hda_intel snd_hda_codec cx18 coretemp 
 snd_hwdep dvb_core cx2341x snd_seq videobuf_vmalloc videobuf_core 
 snd_seq_device ppdev tveeprom v4l2_common snd_pcm videodev parport_pc media 
 parport snd_timer snd soundcore lpc_ich i2c_i801 mfd_core r8169 
 snd_page_alloc 
 mii ftdi_sio serio_raw microcode i915 drm_kms_helper drm i2c_algo_bit 
 i2c_core 
 video [last unloaded: nf_conntrack]
  Pid: 5562, comm: player_movie Tainted: GW3.5.0-93.fc16.x86_64 #1
  Call Trace:
   [8105927f] warn_slowpath_common+0x7f/0xc0
   [81059376] warn_slowpath_fmt+0x46/0x50
   [812e4f81] __list_del_entry+0xa1/0xd0
   [812e4fc1] list_del+0x11/0x40
   [a01cd4b6] videobuf_queue_cancel+0x66/0x100 [videobuf_core]
   [a01ce4ee] videobuf_streamoff+0x2e/0x70 [videobuf_core]
   [a0221672] cx18_streamoff+0x52/0x70 [cx18]
   [a01806e7] __video_do_ioctl+0x2507/0x5350 [videodev]
   [8109132f] ? wakeup_preempt_entity+0x4f/0x60
   [8108b1a4] ? check_preempt_curr+0x84/0xa0
   [8109132f] ? wakeup_preempt_entity+0x4f/0x60
   [8108b1fd] ? ttwu_do_wakeup+0x3d/0x120
   [a017dd70] video_usercopy+0x120/0x570 [videodev]
   [a017e1e0] ? video_ioctl2+0x20/0x20 [videodev]
   [8108e940] ? wake_up_state+0x10/0x20
   [810b11ab] ? wake_futex+0x3b/0x60
   [810b1d10] ? futex_wake+0x100/0x120
   [a017e1d5] video_ioctl2+0x15/0x20 [videodev]
   [a02221ce] cx18_v4l2_ioctl+0x6e/0xa0 [cx18]
   [a017c783] v4l2_ioctl+0x113/0x1c0 [videodev]
   [81092a1d] ? set_next_entity+0x9d/0xb0
   [81198a88] do_vfs_ioctl+0x98/0x550
   [8160f8d4] ? __schedule+0x3c4/0x7c0
   [810b3c7a] ? sys_futex+0x10a/0x1a0
   [81198fd1] sys_ioctl+0x91/0xa0
   [81619129] system_call_fastpath+0x16/0x1b
  ---[ end trace 8e1185c5fb30e531 ]---
 
  [ cut here ]
  WARNING: at lib/list_debug.c:33 __list_add+0xc8/0xd0()
  Hardware name: 
  list_add corruption. prev-next should be next (88007af48c70), but was   
 
 (null). (prev=880064dc6d40).
  Modules linked in: tun dummy ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 
 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter 
 ip6_tables snd_dummy w83627ehf hwmon_vid cx18_alsa mxl5005s s5h1409 
 tuner_simple tuner_types cs5345 tda9887 tda8290 tuner snd_hda_codec_realtek 
 snd_hda_intel snd_hda_codec cx18 coretemp snd_hwdep dvb_core cx2341x snd_seq 
 videobuf_vmalloc videobuf_core snd_seq_device ppdev tveeprom v4l2_common 
 snd_pcm videodev parport_pc media parport snd_timer snd soundcore lpc_ich 
 i2c_i801 mfd_core r8169 snd_page_alloc mii ftdi_sio serio_raw microcode i915 
 drm_kms_helper drm i2c_algo_bit i2c_core video [last unloaded: scsi_wait_scan]
  Pid: 5562, comm: player_movie Tainted: GW3.5.0-93.fc16.x86_64 #1
  Call Trace:
   [8105927f] warn_slowpath_common+0x7f/0xc0
   [81059376] warn_slowpath_fmt+0x46/0x50
   [812e50b8] 

Re: cannot unload cx18_alsa to hibernate Mint13 64 computer

[Andy Walls]

Dixon Craig dixon...@gmail.com wrote:

Thanks Andy

Pulse was indeed respawning.
Once I got it killed for certain, I was able to rmmod cx18_alsa and
cx18,
then hibernate and wake up worked without problem.

On wake up,  I tried   modprobe  cx18_alsa, but it just hung. I exited
by
pressing ctrl-c, and lsmod reported it had not loaded, but that cx18
had.

My sound config is a bit of a mess right now after days of randomly
trying
things to get things working, so once I get things cleaned up I will
see if
I can figure out how I can reload TV drivers after hibernate and report
back to this list in case someone else is faced with this.

Thanks again for your timely help.
Dixon

modprobe cx18 will prompt a reload of cx18-alsa on its own.

BTW you should also unload cx18 before hibernation.  The cx18 driver really 
doesn't support power management and can't  save and restore CX23418 state 
short of reinitializing the whole chip anyway.

Regards,
Andy
--
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: cannot unload cx18_alsa to hibernate Mint13 64 computer

[Andy Walls]

On Sat, 2013-03-09 at 21:57 +, Dixon Craig wrote:
 Hello and thank you to all linuxtv developers!
 
 I have my hauppuage pvr-1600 working very nicely for us-cable analog and 
 composite inputs using cx18 from original linuxmint 13 MATE 64 and I also 
 tried 
 newest drivers from git.linuxtv.org.
 
 My problem is cx18_alsa prevents successful suspend to disk when I run 
 hibernate 
 script.
 
 I cannot unload module before hibernating because modprobe -r returns FATAL: 
 Module cx18_alsa is in use. 
 
 lsmod does not list dependancies but lists 1 in use. here is my lsmod output:
 
 dixon2@phenom ~ $ lsmod | grep cx
 cx18_alsa  13730  1 
 cx18  131960  1 cx18_alsa
 dvb_core  105885  1 cx18
 cx2341x28283  1 cx18
 i2c_algo_bit   13423  1 cx18
 videobuf_vmalloc   13589  1 cx18
 videobuf_core  26022  2 cx18,videobuf_vmalloc
 tveeprom   21249  1 cx18
 v4l2_common21560  4 cs5345,tuner,cx18,cx2341x
 videodev  135159  5 cs5345,tuner,cx18,cx2341x,v4l2_common
 snd_pcm97275  3 cx18_alsa,snd_hda_intel,snd_hda_codec
 snd79041  18 
 cx18_alsa,snd_hda_codec_via,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm,snd_ra
 wmidi,snd_seq,snd_timer,snd_seq_device
 
 
 I have tried stopping all sound services (alsa-restore, alsa-store, and 
 pulseaudio) then running modprobe -r on all the above listed modules but they 
 all return the same in use error.

pulseaudio respawns when you kill it.  pulseaudio is likely the process
keeping the CX23418 ALSA device node open: use 'ps axf' and 'fuser' as
root on the /dev/snd/pcm* and /dev/snd/control* nodes to verify.

You have these options:

# killall pulseaudio; modprobe -r cx18_alsa; killall pulseaudio;
modprobe -r cx18_alsa; killall pulseaudio; modprobe -r cx18_alsa

or

# pactl (some arcane arugments to get pulseaudio to let go of the cx18
ALSA /dev/ nodes)

or 

# pacmd
 (some arcane commands to get pulseaudio to let go of the cx18
ALSA /dev/ nodes)
 exit

or

# find /lib/modules/`uname -r` -name cx18-alsa.ko -exec mv {}
{}.backup \; -print
# shutdown -r now


Regards,
Andy


 I have tried Lubuntu 12.04 with the same hardware and nvidia graphics driver
 using same kernel 3.2.0-38 and I can successfully rmmod cx18_alsa and 
 hibernate
 computer. In Lubuntu, lsmod reports cx18_alsa is used by 0 other modules and
 it rmmods without a problem.
 
 
 Is there any other trick I can use to remove cx18_alsa module from kernel?
 
 Thank you
 
 Dixon 
 
 
 --
 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: drxk driver statistics

[Andy Walls]

Oliver Schinagl oli...@schinagl.nl wrote:

On 03/06/13 18:36, Jean Delvare wrote:
 Hi all,

 I have a TerraTec Cinergy T PCIe Dual card, with DRX-3916K and
 DRX-3913K frontends. I am thus using the drxk dvb-frontend driver.
 While trying to find the best antenna, position and amplification, I
 found that the statistics returned by the drxk driver look quite bad:

 $ femon -H 3
 FE: DRXK DVB-T (DVBT)
 status SCVYL | signal   0% | snr   0% | ber 0 | unc 38822 |
FE_HAS_LOCK
 status SCVYL | signal   0% | snr   0% | ber 0 | unc 38822 |
FE_HAS_LOCK
 status SCVYL | signal   0% | snr   0% | ber 0 | unc 38822 |
FE_HAS_LOCK

 This is with TV looking reasonably good, so these figures are not
 plausible.

 $ femon 10
 FE: DRXK DVB-T (DVBT)
 status SCVYL | signal 00de | snr 00f5 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00f0 | snr 00f5 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 0117 | snr 00f6 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00b6 | snr 00eb | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00d1 | snr 00e7 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 0073 | snr 00ea | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00a3 | snr 00ee | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00b5 | snr 00f4 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00ba | snr 00f3 | ber  | unc 97a6 |
FE_HAS_LOCK
 status SCVYL | signal 00be | snr 00f0 | ber  | unc 97a6 |
FE_HAS_LOCK

 Signal values are changing too much, snr is stable enough but way too
 low, ber is apparently unimplemented, and unc is never reset AFAICS
(it
 started at 1 when the system started and has been only increasing
since
 then.) On my previous card, unc was an instant measurement, not a
 cumulative value, not sure which is correct.
Yes I found that out aswell, but since image quality has always been 
very fine, I haven't looked what this all should be.

 I would like to see these statistics improved. I am willing to help,
 however the drxk driver is rather complex (at least to my eyes) and I
 do not have a datasheet so I wouldn't know where to start. Is there
 anyone who can work on this and/or provide some guidance?

 Thanks,


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

Unc should be a cumulative value and not reset after each read.  Then you can 
support a use case of 2 different apps monitoring the statistics.

I can't recall when exactly unc should be reset, but of frequency change sounds 
reasonable.

Regards,
Andy
--
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: Firmware for cx23885 in linux-firmware.git is broken

[Andy Walls]

Hi,

Instead of answering points in the email chain, I'm just going to
provide the best information I have.

I. Definitions:
- Thresher: broadcast video decoder
- Merlin:   broadcast audio system detection microcontroller and decoder
- Mako: Thresher + Merlin

- CX2583[67]:   stand-alone Thresher
- CX2584[0123]: stand-alone Mako

- CX23415: PCI/Microcontroller host MPEG Encoder + MPEG Decoder, JHVM
- CX23416: PCI/Microcontroller host MPEG Encoder, JHVM
- CX23417: Microcontroller host MPEG Encoder, JHVM

- CX23418: PCI/Microcontroller host MPEG Encoder + Mako, ARM

- CX2388[578]: PCIe host Video capture + Mako
- CX2310[012]: USB host Video capture + Mako

II. Notes about the Mako core:
1. The Merlin in every Mako uses a 16 kB firmware image.  (Technically
it is 16382 bytes instead of 16384 bytes, IIRC.)

2. The Merlin implementations appear to vary from one another, but there
are at least two distinct groupings based on hardware register
implementation:
   a. Older: CX2584[0123] (v4l-cx25840.fw)
 CX23418  (v4l-cx23418-dig.fw)

   b. Newer: CX2388[578]  (v4l-cx23885-avcore-01.fw)
 CX231[012]   (v4l-cx231xx-avcore-01.fw)

The firmwares between the two groups are not interchangeable.  For
example, IIRC the older Merlin audio firmwares might manipulate video
U,V saturation registers on a CX23885.

3. There seem to be a large number of versions of Merlin firmware files,
upon examining Windows driver CD I have.  It is very possible that two
different Merlin firmware files, with different MD5 sums, are both
intended to work on the same chip, e.g. CX23885.

4. There appears to be no way to tell what chip for which a Merlin
firmware file is intended, without disassembling the Merlin firmware
file and painfully examining the assembly code.  A violation of most, if
not all, of the license agreements.

5. With the exception of the CX23418 chip and cx18 driver, all
Mako/Merlin stuff in Linux is handled by the cx25840 driver.  The cx18
driver has its own fork of cx25840-*.c in cx18-av-*.c


III. Notes on the MPEG Encoders:
1. The MPEG encoder firmware images are never 16 kB; they are around 10
times larger than that, or larger.

2. The CX2341[56] chips both use the same MPEG encoder firmware image.
(v4l-cx2341x-enc.fw)

3. It is very plausible that the CX23417 can use the same MPEG Encoder
firmware image as a CX23416, I just don't know for sure.

4. The CX23418 MPEG encoder firmware images (v4l-cx23418-cpu.fw, 
v4l-cx23418-apu.fw) and distinct from the firmware for the CX2341[567]
chips, as the underlying embedded processor has a different machine
architecture and instruction set.


IV. Known good firmware images

1. CX23418 MPEG encoder and CX23418 Merlin/Mako:
http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz
(Save as... adding an extra .gz at the end, since the webserver double
gzips the file.)
e8188c7542a82a8d7cdc2720ddfb3a3e CX23418 Firmware Video Firmware Release
Notes.pdf
6686a1673585585f5017c13ada343f98 LICENSE
588f081b562f5c653a3db1ad8f65939a v4l-cx23418-apu.fw
b6c7ed64bc44b1a6e0840adaeac39d79 v4l-cx23418-cpu.fw
b3704908fd058485f3ef136941b2e513 v4l-cx23418-dig.fw

Last I checked months ago, the CX23418 APU, CPU, and Merlin firmware
images all matched linuxtv.org's copies.

This CX23418 Merlin image does not match the CX23418 Merlin image that
Hauppauge is shipping with the HVR-1600 driver CD:
c529278bbceb51d68d3fc1993657c901  hcw18mlC.rom

So I now have doubts as to whether the CX23418 Merlin firmware file
being used under Linux is correct. :(


2. CX2341[56] MPEG decoder/encoder, CX2584[0123] Merlin, and PVRUSB
microcontroller
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20080701.tar.gz
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20070217.tar.gz
(Save as... adding an extra .gz at the end, since the webserver double
gzips the file.)

(The licenses in these files appear to be OK if the firmware is used
with Hauppauge products.  For any other use, consult your legal
council.)

The above archives are identical, except for the v4l-cx25840.fw Merlin
firmware file.

The 2007 archive has the original CX2584[0123] Merlin firmware,

The 2008 archive has the CX23418 Merlin firmware (which might be a bad
thing). I think the CX23418 Merlin firmware actually causes the
user-reported ivtv tinny-audio problem, when used with the
CX2584[0123] chips.

Please note: The ivtv driver was coded to a very specific version of the
v4l-cx2341x-enc.fw image, due the ivtv driver's use of firmware specific
memory locations to work around some chip and firmware bugs.  No other
version of this firmware image is recommended for the ivtv driver.


3. CX2388[578] MPEG encoder (aka. CX23417) firmware
Aside from Conextant, I don't know where to get a redistributable copy,
specifically intended for the CX23417.
The v4l-cx2341x-enc.fw file for the CX23416 might work, after being
renamed:
http://dl.ivtvdriver.org/ivtv/firmware/ivtv-firmware-20080701.tar.gz
(Save as... adding an extra .gz at 

Re: 3.7/3.8 kernel won't boot with Hauppauge pvr-150

[Andy Walls]

On Thu, 2013-02-21 at 22:32 -0500, Andy Walls wrote:
 Ron Andreasen dlano...@gmail.com wrote:
 
 I've been having trouble getting distros that have any kernel above the
 3.5
 series to boot (only tried 64-bit). I get a black screen with a bunch
 of
 text and the boot process goes no further. I don't know if this is
 usually
 okay, but I'm posting a link to a picture I took of my monitor with my
 cell
 phone. It's a bit blurry but hopefully it's still okay:
 
 http://imgur.com/viP1kWk,3YJXKbG
 
 The distros I've had this problem in are Kubuntu (I've tried several of
 the
 daily builds) which uses the 3.8.? (can't boot far enough to see)
 kernel,
 Cinnarch which uses the 3.7.3 kernel, and openSUSE 12.3 and I don't
 remember what version of the kernel that one used.
 
 

 It looks like the ivtv module is failing to initialize, starts to
 unload, and in the process of unloading, the cleanup path causes an
 Ooops.  
 
 I should have time to look closer at it this weekend.

Test this patch (made against Kernel v3.8-rc5).

Hopefully, it will fix the oops and then let you see why the
ivtv_probe() function fails when initializing the PVR-150.

Regards,
Andy

diff --git a/drivers/media/pci/ivtv/ivtv-driver.c 
b/drivers/media/pci/ivtv/ivtv-driver.c
index df88dc4..de5db69 100644
--- a/drivers/media/pci/ivtv/ivtv-driver.c
+++ b/drivers/media/pci/ivtv/ivtv-driver.c
@@ -298,7 +298,6 @@ static void request_module_async(struct work_struct *work)
 
 static void request_modules(struct ivtv *dev)
 {
-   INIT_WORK(dev-request_module_wk, request_module_async);
schedule_work(dev-request_module_wk);
 }
 
@@ -307,6 +306,9 @@ static void flush_request_modules(struct ivtv *dev)
flush_work_sync(dev-request_module_wk);
 }
 #else
+static void request_module_async(struct work_struct *work)
+{
+}
 #define request_modules(dev)
 #define flush_request_modules(dev)
 #endif /* CONFIG_MODULES */
@@ -751,6 +753,8 @@ static int ivtv_init_struct1(struct ivtv *itv)
spin_lock_init(itv-lock);
spin_lock_init(itv-dma_reg_lock);
 
+   INIT_WORK(itv-request_module_wk, request_module_async);
+
init_kthread_worker(itv-irq_worker);
itv-irq_worker_task = kthread_run(kthread_worker_fn, itv-irq_worker,
   itv-v4l2_dev.name);



--
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: 3.7/3.8 kernel won't boot with Hauppauge pvr-150

[Andy Walls]

Ron Andreasen dlano...@gmail.com wrote:

I've been having trouble getting distros that have any kernel above the
3.5
series to boot (only tried 64-bit). I get a black screen with a bunch
of
text and the boot process goes no further. I don't know if this is
usually
okay, but I'm posting a link to a picture I took of my monitor with my
cell
phone. It's a bit blurry but hopefully it's still okay:

http://imgur.com/viP1kWk,3YJXKbG

The distros I've had this problem in are Kubuntu (I've tried several of
the
daily builds) which uses the 3.8.? (can't boot far enough to see)
kernel,
Cinnarch which uses the 3.7.3 kernel, and openSUSE 12.3 and I don't
remember what version of the kernel that one used.

My processor is a AMD Phenom(tm) 9850 Quad-Core Processor with all four
cores unlocked. The output of lspci -vvv (in Kubuntu 12.10) can be
found at
[redacted]. I have 6 gb of ddr2 ram. Not sure
what
else I need to include so if you need more please let me know.

When I was testing out Cinnarch I was able to boot by taking the
Hauppauge
PVR-150 out of the computer so I know for sure that's the hardware that
was
causing the problem. I haven't found any other way to boot with the
card
in. I tried different boot options. The ones I can remember are
nomodeset
and noacpi (or something like that). The distro I'm currently using is
Kubuntu 12.10 and the kernel as of this writing is 3.5.0-24

For now rename the ivtv-alsa.ko module to ivtv-alsa.ko.orig 

If that doesn't allow a normal boot, blacklist the ivtv module in 
/etc/modprobe.d/blacklist.  That way your machine will at least boot.

It looks like the ivtv module is failing to initialize, starts to unload, and 
in the process of unloading, the cleanup path causes an Ooops.  

I should have time to look closer at it this weekend.

Regards,
Andy
--
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: Wrongly identified easycap em28xx

[Andy Walls]

Theodore Kilgore kilg...@banach.math.auburn.edu wrote:



On Tue, 19 Feb 2013, Mauro Carvalho Chehab wrote:

 Em Tue, 19 Feb 2013 20:45:21 +0100
 Frank Sch?fer fschaefer@googlemail.com escreveu:
 
  Am 19.02.2013 19:53, schrieb Mauro Carvalho Chehab:
   Em Tue, 19 Feb 2013 19:45:29 +0100
   Frank Sch?fer fschaefer@googlemail.com escreveu:
  
   I don't like the idea of merging those two entries. As far as I
remember
   there are devices that works out of the box with
   EM2860_BOARD_SAA711X_REFERENCE_DESIGN. A change like that can
break
   the driver for them.
   As described above, there is a good chance to break devices with
both
   solutions.
  
   What's your suggestion ? ;-)
  
   As I said, just leave it as-is (documenting at web) 
  
  That seems to be indeed the only 100%-regression-safe solution.
  But also _no_ solution for this device.
  A device which works only with a special module parameter passed on
  driver loading isn't much better than an unsupported device.
 
 That's not true. There are dozens of devices that only work with
 modprobe parameter (even ones with their own USB or PCI address). The
thing
 is that crappy vendors don't provide any way for a driver to detect
what's
 there, as their driver rely on some *.inf config file with those
parameters
 hardcoded.
 
 We can't do any better than what's provided by the device.
 
  
  It comes down to the following question:
  Do we want to refuse fixing known/existing devices for the sake of
  avoiding regression for unknown devices which even might not exist
? ;-)
 
 HUH? As I said: there are devices that work with the other board
entry.
 If you remove the other entry, _then_ you'll be breaking the driver.
 
  I have no strong and final opinion yet. Still hoping someone knows
how
  the Empia driver handles these cases...
 
 What do you mean? The original driver? The parameters are hardcoded
at the
 *.inf file. Once you get the driver, the *.inf file contains all the
 parameters for it to work there. If you have two empia devices with
 different models, you can only use the second one after removing the
 install for the first one.
 
   or to use the AC97
   chip ID as a hint. This works fine for devices that don't come
with
   Empiatech em202, but with something else, like the case of the
Realtek
   chip found on this device. The reference design for sure uses
em202.
  
  How could the AC97 chip ID help us in this situation ?
  As far as I understand, it doesn't matter which AC97 IC is used.
  They are all compatible and at least our driver uses the same code
for
  all of them.
 
 The em28xx Kernel driver uses a hint code to try to identify the
device
 model. That hint code is not perfect, but it is the better we can do.
 
 There are two hint codes there, currently: 
 1) device's eeprom hash, used when the device has an eeprom, but the
USB ID is not unique;
 
 2) I2C scan bus hash: sometimes, different devices use different I2C
 addresses.
 
  
  So even if you are are right and the Empia reference design uses an
EMP202,
  EM2860_BOARD_SAA711X_REFERENCE_DESIGN might work for devices with
other
  AC97-ICs, too.
 
 The vast majority of devices use emp202. There are very few ones
using
 different models.
 
 The proposal here is to add a third hint code, that would distinguish
 the devices based on the ac97 ID.
 
  We should also expect manufacturers to switch between them whenever
they
  want (e.g. because of price changes).
 
 Yes, and then we'll need other entries at the hint table.
 
 Regards
 Mauro

I see the dilemma. Devices which are not uniquely identifiable. Mauro
is 
right in pinpointing the problem, and he is also right that one can not

expect the manufacturers to pay any attention. Mauro is also absolutely

right that it is not good to break what works already for some people, 
hoping to please some others who are presently unhappy. A better
solution 
needs to be found.

Could I make a suggestion?

Sometimes it is possible to find some undocumented way to identify 
uniquely which one of two devices you have. As an example, look in 
mr97310a.c, where there is a detection routine for several devices
which 
all have the same USB vendor:product code but are different inside. 

Indeed, back when lots of those mr97310a cameras were on the market,
the 
manufacturers were supposed to be sending out the cameras with the 
right windows driver. Except the situation was actually so bad that 
quite often some of the manufacturers were grabbing the wrong driver CD

off the shelf and putting it with the wrong cameras! You can do a
Google 
search for the Windows driver for some of those cameras and find web
pages 
full of complaints from disgruntled users who got the wrong CD in the 
package with the camera, frantically looking for the right driver CD.
It 
was that bad. Now to top that off, think of some poor guy having a
Windows 
computer and wanting to have two cameras of the same brand and make,
with 
identical cases on the outside, 

Re: possible recursive locking: find_ref_lock() / v4l2_ctrl_add_handler()

[Andy Walls]

On Sun, 2013-02-10 at 11:54 +0100, Hans Verkuil wrote:
 On Sun February 10 2013 11:34:11 Knut Petersen wrote:
  Maybe somebody could have at that old locking warning:
 
 It's a false warning. If someone can point me to some documentation on how to
 tell lockdep that it isn't a deadlock, then that would be appreciated.

Hi Hans,

Here you go, an old patch for you:
http://permalink.gmane.org/gmane.linux.drivers.video-input-infrastructure/27027

Be warned, if lockdep has a limit on the number of classes it can
handle, then my patch could be a problem with a large number of drivers
with v4l2_ctrl_handlers loaded. I must emphasize, that is a new lock
classes per driver instance, not per hardware device instance ... IIRC.

FYI, here's some context that led up to me making the patch:
http://www.gossamer-threads.com/lists/ivtv/devel/41525#41525

Regards,
Andy

 Regards,
 
   Hans
 
  
  [9.761427] cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded
  [9.782848] cx88/0: cx2388x v4l2 driver version 0.0.9 loaded
  [9.794205] input: HDA Digital PCBeep as 
  /devices/pci:00/:00:1b.0/input/input5
  [9.879194] cx88[0]: subsystem: 0070:6906, board: Hauppauge 
  WinTV-HVR4000(Lite) DVB-S/S2 [card=69,autodetected], frontend(s): 1
  [9.914871] input: HDA Intel Line as 
  /devices/pci:00/:00:1b.0/sound/card0/input6
  [9.932037] cx88[0]: TV tuner type -1, Radio tuner type -1
  [9.953646] input: HDA Intel Front Mic as 
  /devices/pci:00/:00:1b.0/sound/card0/input7
  [9.981718] input: HDA Intel Rear Mic as 
  /devices/pci:00/:00:1b.0/sound/card0/input8
  [9.996493] input: HDA Intel Line Out CLFE as 
  /devices/pci:00/:00:1b.0/sound/card0/input9
  [   10.003354] input: HDA Intel Line Out Surround as 
  /devices/pci:00/:00:1b.0/sound/card0/input10
  [   10.007987] input: HDA Intel Line Out Front as 
  /devices/pci:00/:00:1b.0/sound/card0/input11
  [   10.450310] tveeprom 9-0050: Hauppauge model 69100, rev B4C3, serial# 
  7900937
  [   10.453751] tveeprom 9-0050: MAC address is 00:0d:fe:78:8f:09
  [   10.457134] tveeprom 9-0050: tuner model is Conexant CX24118A (idx 123, 
  type 4)
  [   10.460547] tveeprom 9-0050: TV standards ATSC/DVB Digital (eeprom 0x80)
  [   10.463936] tveeprom 9-0050: audio processor is None (idx 0)
  [   10.467320] tveeprom 9-0050: decoder processor is CX880 (idx 20)
  [   10.470648] tveeprom 9-0050: has no radio, has IR receiver, has no IR 
  transmitter
  [   10.474038] cx88[0]: hauppauge eeprom: model=69100
  [   10.508060] Registered IR keymap rc-hauppauge
  [   10.518107] input: cx88 IR (Hauppauge WinTV-HVR400 as 
  /devices/pci:00/:00:1e.0/:05:05.2/rc/rc0/input12
  [   10.526485] rc0: cx88 IR (Hauppauge WinTV-HVR400 as 
  /devices/pci:00/:00:1e.0/:05:05.2/rc/rc0
  [   10.530869] cx88[0]/2: cx2388x 8802 Driver Manager
  [   10.534533] cx88[0]/2: found at :05:05.2, rev: 5, irq: 17, latency: 
  32, mmio: 0xd200
  [   10.541221] cx88[0]/0: found at :05:05.0, rev: 5, irq: 17, latency: 
  32, mmio: 0xd000
  [   10.545197] IR RC5(x) protocol handler initialized
  [   10.557935]
  [   10.560012] =
  [   10.560012] [ INFO: possible recursive locking detected ]
  [   10.560012] 3.8.0-rc7-main #20 Not tainted
  [   10.560012] -
  [   10.560012] modprobe/469 is trying to acquire lock:
  [   10.560012]  (hdl-lock){+.+...}, at: [f85604f6] 
  find_ref_lock+0x1f/0x39 [videodev]
  [   10.560012]
  [   10.560012] but task is already holding lock:
  [   10.560012]  (hdl-lock){+.+...}, at: [f85622d3] 
  v4l2_ctrl_add_handler+0x35/0x91 [videodev]
  [   10.560012]
  [   10.560012] other info that might help us debug this:
  [   10.560012]  Possible unsafe locking scenario:
  [   10.560012]
  [   10.560012]CPU0
  [   10.560012]
  [   10.560012]   lock(hdl-lock);
  [   10.560012]   lock(hdl-lock);
  [   10.560012]
  [   10.560012]  *** DEADLOCK ***
  [   10.560012]
  [   10.560012]  May be due to missing lock nesting notation
  [   10.560012]
  [   10.560012] 3 locks held by modprobe/469:
  [   10.560012]  #0:  (__lockdep_no_validate__){..}, at: [c03cbcfc] 
  __driver_attach+0x31/0x6b
  [   10.560012]  #1:  (__lockdep_no_validate__){..}, at: [c03cbd08] 
  __driver_attach+0x3d/0x6b
  [   10.560012]  #2:  (hdl-lock){+.+...}, at: [f85622d3] 
  v4l2_ctrl_add_handler+0x35/0x91 [videodev]
  [   10.560012]
  [   10.560012] stack backtrace:
  [   10.560012] Pid: 469, comm: modprobe Not tainted 3.8.0-rc7-main #20
  [   10.560012] Call Trace:
  [   10.560012]  [c01272cb] ? console_unlock+0x34b/0x374
  [   10.560012]  [c015b25a] __lock_acquire+0x1314/0x138a
  [   10.560012]  [c015bc94] ? mark_held_locks+0xa1/0xc8
  [   10.560012]  [f85604f6] ? find_ref_lock+0x1f/0x39 [videodev]
  [   10.560012]  [c015b703] lock_acquire+0xaf/0xcd
  [   10.560012]  [f85604f6] ? 

Re: [RFC PATCH] ivtv-alsa: regression fix: remove __init from ivtv_alsa_load

[Andy Walls]

Hans Verkuil hverk...@xs4all.nl wrote:

Andy,

Please review this patch. This fix probably should be fast-tracked to
3.8 and
queued for stable 3.7.

ivtv-alsa kept crashing my machine every time I loaded it, and this is
the
cause.

Regards,

   Hans

This function is called after initialization, so it should never be
marked
__init!

Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
 drivers/media/pci/ivtv/ivtv-alsa-main.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/pci/ivtv/ivtv-alsa-main.c
b/drivers/media/pci/ivtv/ivtv-alsa-main.c
index 4a221c6..e970cfa 100644
--- a/drivers/media/pci/ivtv/ivtv-alsa-main.c
+++ b/drivers/media/pci/ivtv/ivtv-alsa-main.c
@@ -205,7 +205,7 @@ err_exit:
   return ret;
 }
 
-static int __init ivtv_alsa_load(struct ivtv *itv)
+static int ivtv_alsa_load(struct ivtv *itv)
 {
   struct v4l2_device *v4l2_dev = itv-v4l2_dev;
   struct ivtv_stream *s;
-- 
1.7.10.4

Hans,

I concur.  Now I have to check cx18 for the same problem.

Your patch looks good.

Reviewed-by: Andy Walls awa...@md.metrocast.net
Signed-off-by: Andy Walls awa...@md.metrocast.net

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

Re: [RFC PATCH] ivtv-alsa: regression fix: remove __init from ivtv_alsa_load

[Andy Walls]

Hans Verkuil hverk...@xs4all.nl wrote:

On Thu February 7 2013 22:58:53 Andy Walls wrote:
 Hans Verkuil hverk...@xs4all.nl wrote:
 
 Andy,
 
 Please review this patch. This fix probably should be fast-tracked
to
 3.8 and
 queued for stable 3.7.
 
 ivtv-alsa kept crashing my machine every time I loaded it, and this
is
 the
 cause.
 
 Regards,
 
 Hans
 
 This function is called after initialization, so it should never be
 marked
 __init!
 
 Signed-off-by: Hans Verkuil hans.verk...@cisco.com
 ---
  drivers/media/pci/ivtv/ivtv-alsa-main.c |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/drivers/media/pci/ivtv/ivtv-alsa-main.c
 b/drivers/media/pci/ivtv/ivtv-alsa-main.c
 index 4a221c6..e970cfa 100644
 --- a/drivers/media/pci/ivtv/ivtv-alsa-main.c
 +++ b/drivers/media/pci/ivtv/ivtv-alsa-main.c
 @@ -205,7 +205,7 @@ err_exit:
 return ret;
  }
  
 -static int __init ivtv_alsa_load(struct ivtv *itv)
 +static int ivtv_alsa_load(struct ivtv *itv)
  {
 struct v4l2_device *v4l2_dev = itv-v4l2_dev;
 struct ivtv_stream *s;
 
 Hans,
 
 I concur.  Now I have to check cx18 for the same problem.

Hmm, there is the same problem in cx18 as well:

static int __init cx18_alsa_load(struct cx18 *cx)

Checking some more I saw that this __init annotation was added only in
3.8,
both for ivtv and cx18 (so 3.7 is fine).

Ah, I see that Mauro added __init accidentally when fixing some
compiler
warnings in ivtv and cx18.

I'll make a pull request tomorrow morning removing the __init from
ivtv_alsa_load
and cx18_alsa_load and ask Mauro to fast-track this regression.

I assume I have your SoB for this?

Regards,

   Hans

 
 Your patch looks good.
 
 Reviewed-by: Andy Walls awa...@md.metrocast.net
 Signed-off-by: Andy Walls awa...@md.metrocast.net
 
 Regards,
 Andy  
 

Yes.

Signed-off-by: Andy Walls awa...@md.metrocast.net

-Andy
--
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: [ivtv-users] cx18 module causes freeze after kernel upgrade

[Andy Walls]

On Fri, 2013-01-18 at 14:23 -0500, Kyle Lil wrote:
 I'm having trouble getting drivers installed for my Hauppauge HVR-1600
 in recent kernels. In Mythbuntu 12.04, I first tried upgrading to 3.4
 kernel or 3.3 kernel. After installing each of these, I booted into
 the new kernel, then downloaded and built a fresh copy of media_build
 from the git server.

Why?  What is wrong with the cx18 module (and supporting modules) in the
stock 3.4 or 3.3 kernel?

FYI, the ^media_build^ is only a partial rebuild of the sources for the
latest ^media_tree^ kernel, with some backward compatability patches so
things at least compile.  No guarantee that things are going to work.

If you rebuild and install the ^media_tree^ kernel and all the modules,
then you will have the bleeding edge V4L-DVB modules with a vanilla
kernel.  You will not have any security or valued added patches from
Cannonical, but you will have the bleeding edge V4L-DVB modules with
their intended kernel and they shouldn't crash.

  On reboot, for both kernels, the system would hang. A bunch of trace
 information would scroll by and a hard reboot was required. (I'm not
 really sure how to retrieve that info).

Take a picture with a digital camera and email direct to me:
awa...@md.metrocast.net .  If the Code bytes in the photo are not
readable, please transcribe them by hand (there are only 64 of them) and
send them as well.


  I thought the issue might have been related to using a newer kernel
 than the Ubuntu 12.04 repositories gave me. 

Maybe.  I don't know from where media_build is picking up the kernel
headers.

 
 So I upgraded to Ubuntu 12.10 (and kernel 3.5.0-21). Unfortunately,
 I'm having the same experience. If I install the media_build tree and
 try sudo modprobe cx18, the system immediately hangs with no log
 output (that I know how to retrieve - I had tail -f /var/log/messages
 running in a separate terminal window) and again the system hangs
 during boot.

During your experimentation blacklist the cx18 driver
in /etc/modprobe.d/blacklist.conf .  That way on reboot, you get to
decide when your machine hangs by typing modprobe cx18 manually.


  The last good working kernel I have with v4l-dvb drivers is 3.2.0-32.
 
 
 Any help would be greatly appreciated. Please let me know if there is
 any additional info I can provide (or if there is a different list I
 should be sending to). 

Certainly, questions related to media_build should be directed to the
Linux media list: linux-media@vger.kernel.org .  I don't use the
media_build backward-compatability build system, myself.

Regards,
Andy
 
 Thanks,
 Kyle



--
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 5/5] kfifo: log based kfifo API

[Andy Walls]

Dmitry Torokhov dmitry.torok...@gmail.com wrote:

Hi Yuanhan,

On Tue, Jan 08, 2013 at 10:57:53PM +0800, Yuanhan Liu wrote:
 The current kfifo API take the kfifo size as input, while it rounds
  _down_ the size to power of 2 at __kfifo_alloc. This may introduce
 potential issue.
 
 Take the code at drivers/hid/hid-logitech-dj.c as example:
 
  if (kfifo_alloc(djrcv_dev-notif_fifo,
DJ_MAX_NUMBER_NOTIFICATIONS * sizeof(struct
dj_report),
GFP_KERNEL)) {
 
 Where, DJ_MAX_NUMBER_NOTIFICATIONS is 8, and sizeo of(struct
dj_report)
 is 15.
 
 Which means it wants to allocate a kfifo buffer which can store 8
 dj_report entries at once. The expected kfifo buffer size would be
 8 * 15 = 120 then. While, in the end, __kfifo_alloc will turn the
 size to rounddown_power_of_2(120) =  64, and then allocate a buf
 with 64 bytes, which I don't think this is the original author want.
 
 With the new log API, we can do like following:
 
  int kfifo_size_order = order_base_2(DJ_MAX_NUMBER_NOTIFICATIONS *
  sizeof(struct dj_report));
 
  if (kfifo_alloc(djrcv_dev-notif_fifo, kfifo_size_order,
GFP_KERNEL)) {
 
 This make sure we will allocate enough kfifo buffer for holding
 DJ_MAX_NUMBER_NOTIFICATIONS dj_report entries.

Why don't you simply change __kfifo_alloc to round the allocation up
instead of down?

Thanks.

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

Hi Dmitry,

I agree.   I don't see the benefit in pushing up the change to a kfifo internal 
decision/problem to many different places in the kernel.

Regards,
Andy

 
--
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] ivtv: ivtv-driver: Replace 'flush_work_sync()'

[Andy Walls]

On Thu, 2012-12-20 at 15:18 -0200, Mauro Carvalho Chehab wrote:
 Em Wed, 21 Nov 2012 15:28:09 -0200
 Mauro Carvalho Chehab mche...@redhat.com escreveu:
 
  Hi Andy,
  
  I'm understanding that you'll be reviewing this patch. So, I'm marking it as
  under_review at patchwork.
 
 -ENOANSWER. Let me apply it, in order to fix the warning.

Ooops.  Sorry about that.

Strictly speaking, I think the patch introduces a race condition that is
extremely unlikely to be encountered, and it likely wouldn't have
terrible consequences anyway.

For the normal end-user, it will never be a problem.

FWIW:
Acked-by: Andy Walls awa...@md.metrocast.net

Regards,
Andy
  
  Thanks,
  Mauro
  
  Forwarded message:
  
  Date: Wed, 24 Oct 2012 10:14:16 -0200
  From: Fabio Estevam feste...@gmail.com
  To: awa...@md.metrocast.net
  Cc: mche...@infradead.org, linux-media@vger.kernel.org, t...@kernel.org, 
  Fabio Estevam fabio.este...@freescale.com
  Subject: [PATCH] [media] ivtv: ivtv-driver: Replace 'flush_work_sync()'
  
  
  From: Fabio Estevam fabio.este...@freescale.com
  
  Since commit 43829731d (workqueue: deprecate flush[_delayed]_work_sync()),
  flush_work() should be used instead of flush_work_sync().
  
  Signed-off-by: Fabio Estevam fabio.este...@freescale.com
  ---
   drivers/media/pci/ivtv/ivtv-driver.c |2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
  
  diff --git a/drivers/media/pci/ivtv/ivtv-driver.c 
  b/drivers/media/pci/ivtv/ivtv-driver.c
  index 74e9a50..5d0a5df 100644
  --- a/drivers/media/pci/ivtv/ivtv-driver.c
  +++ b/drivers/media/pci/ivtv/ivtv-driver.c
  @@ -304,7 +304,7 @@ static void request_modules(struct ivtv *dev)
   
   static void flush_request_modules(struct ivtv *dev)
   {
  -   flush_work_sync(dev-request_module_wk);
  +   flush_work(dev-request_module_wk);
   }
   #else
   #define request_modules(dev)
 
 


--
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: cx18, ivtv: do not dereference array before index check

[Andy Walls]

On Sat, 2013-01-05 at 14:11 -0500, Nickolai Zeldovich wrote:
 Move dereferencing of hw_devicenames[], hw_bus[] arrays until after
 checking that idx is within range.
 
 Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu

Hi Nickolai,

My comments are in line below.

 ---
  drivers/media/pci/cx18/cx18-i2c.c |   10 +++---
  drivers/media/pci/ivtv/ivtv-i2c.c |5 -
  2 files changed, 11 insertions(+), 4 deletions(-)
 
 diff --git a/drivers/media/pci/cx18/cx18-i2c.c 
 b/drivers/media/pci/cx18/cx18-i2c.c
 index 4908eb7..d164239 100644
 --- a/drivers/media/pci/cx18/cx18-i2c.c
 +++ b/drivers/media/pci/cx18/cx18-i2c.c
 @@ -111,14 +111,18 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct 
 i2c_adapter *adap, u32 hw,
  int cx18_i2c_register(struct cx18 *cx, unsigned idx)
  {
   struct v4l2_subdev *sd;
 - int bus = hw_bus[idx];
 - struct i2c_adapter *adap = cx-i2c_adap[bus];
 - const char *type = hw_devicenames[idx];
 + int bus;
 + struct i2c_adapter *adap;
 + const char *type;
   u32 hw = 1  idx;
  
   if (idx = ARRAY_SIZE(hw_addrs))
   return -1;

 + bus = hw_bus[idx];
 + adap = cx-i2c_adap[bus];
 + type = hw_devicenames[idx];
 +

It would be better to simply remove the if (idx = ARRAY_SIZE(...))
check.  That change would result in fewer lines of code instead of more
lines of code.  It is statically provable that cx18_i2c_register() is
never called with a bad idx value.


   if (hw == CX18_HW_TUNER) {
   /* special tuner group handling */
   sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
 diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
 b/drivers/media/pci/ivtv/ivtv-i2c.c
 index 46e262b..c6af94c 100644
 --- a/drivers/media/pci/ivtv/ivtv-i2c.c
 +++ b/drivers/media/pci/ivtv/ivtv-i2c.c
 @@ -264,11 +264,14 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned idx)
  {
   struct v4l2_subdev *sd;
   struct i2c_adapter *adap = itv-i2c_adap;
 - const char *type = hw_devicenames[idx];
 + const char *type;
   u32 hw = 1  idx;
  
   if (idx = ARRAY_SIZE(hw_addrs))
   return -1;
 +
 + type = hw_devicenames[idx];
 +

It would be better to simply remove the if (idx = ARRAY_SIZE(...))
check.  That change would result in fewer lines of code instead of more
lines of code.  It is statically provable that ivtv_i2c_register() is
never called with a bad idx value.

Regards,
Andy

   if (hw == IVTV_HW_TUNER) {
   /* special tuner handling */
   sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,


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

Re: [PATCH v2] media: cx18, ivtv: eliminate unnecessary array index checks

[Andy Walls]

Nickolai Zeldovich nicko...@csail.mit.edu wrote:

The idx values passed to cx18_i2c_register() and ivtv_i2c_register()
by cx18_init_subdevs() and ivtv_load_and_init_modules() respectively
are always in-range, based on how the hw_all bitmask is populated.
Previously, the checks were already ineffective because arrays were
being dereferenced using the index before the check.

Signed-off-by: Nickolai Zeldovich nicko...@csail.mit.edu
---
Thanks to Andy Walls for suggesting that instead of moving the checks
before array dereference, a better fix is to remove the checks
altogether,
since they are superfluous.

 drivers/media/pci/cx18/cx18-i2c.c |3 ---
 drivers/media/pci/ivtv/ivtv-i2c.c |2 --
 2 files changed, 5 deletions(-)

diff --git a/drivers/media/pci/cx18/cx18-i2c.c
b/drivers/media/pci/cx18/cx18-i2c.c
index 4908eb7..ccb1d15 100644
--- a/drivers/media/pci/cx18/cx18-i2c.c
+++ b/drivers/media/pci/cx18/cx18-i2c.c
@@ -116,9 +116,6 @@ int cx18_i2c_register(struct cx18 *cx, unsigned
idx)
   const char *type = hw_devicenames[idx];
   u32 hw = 1  idx;
 
-  if (idx = ARRAY_SIZE(hw_addrs))
-  return -1;
-
   if (hw == CX18_HW_TUNER) {
   /* special tuner group handling */
   sd = v4l2_i2c_new_subdev(cx-v4l2_dev,
diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c
b/drivers/media/pci/ivtv/ivtv-i2c.c
index 46e262b..bc984af 100644
--- a/drivers/media/pci/ivtv/ivtv-i2c.c
+++ b/drivers/media/pci/ivtv/ivtv-i2c.c
@@ -267,8 +267,6 @@ int ivtv_i2c_register(struct ivtv *itv, unsigned
idx)
   const char *type = hw_devicenames[idx];
   u32 hw = 1  idx;
 
-  if (idx = ARRAY_SIZE(hw_addrs))
-  return -1;
   if (hw == IVTV_HW_TUNER) {
   /* special tuner handling */
   sd = v4l2_i2c_new_subdev(itv-v4l2_dev, adap, type, 0,
-- 
1.7.10.4

Acked-by: Andy Walls awa...@md.metrocast.net
--
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: ivtv driver inputs randomly block

[Andy Walls]

On Thu, 2012-11-29 at 12:29 -0300, Ezequiel Garcia wrote:
 Hi Brian,
 
 See my comments below.
 
 On Wed, Nov 28, 2012 at 8:19 PM, Brian J. Murrell br...@interlinx.bc.ca 
 wrote:
  On 12-11-28 08:13 AM, Ezequiel Garcia wrote:
 
  Try again with
  modprobe ivtv ivtv_debug=10
 
  OK.  Happened again.  The kernel log for the whole day since starting
  the module with debug this morning can be found at
  http://brian.interlinx.bc.ca/ivtv-dmesg.txt.bz2.
 
  Associated with that log there was a successful recording from 09:00:00
  until 10:00:00 then another successful recording from 14:00:00 until
  15:00:00 and then failed recordings starting at 15:00:00 until 18:00:00.
 
  The log cuts off just short of 18:00:00 but there's nothing different
  about the pattern from the end of the log until 18:00:04 from the
  previous 3 hours or so.
 
  It seems that the problem lies in amongst the start of these lines from
  the log, as my best guess:
 
  Nov 28 15:00:05 cmurrell kernel: [868297.536049] ivtv0 encoder MPG: 
  VIDIOC_ENCODER_CMD cmd=0, flags=0
  Nov 28 15:00:07 cmurrell kernel: [868300.039324] ivtv0:  ioctl: 
  V4L2_ENC_CMD_STOP
  Nov 28 15:00:07 cmurrell kernel: [868300.039330] ivtv0:  info: close 
  stopping capture
  Nov 28 15:00:07 cmurrell kernel: [868300.039334] ivtv0:  info: Stop Capture
  Nov 28 15:00:09 cmurrell kernel: [868302.140151] ivtv0 encoder MPG: 
  VIDIOC_ENCODER_CMD cmd=1, flags=1
  Nov 28 15:00:09 cmurrell kernel: [868302.148093] ivtv0:  ioctl: 
  V4L2_ENC_CMD_START
  Nov 28 15:00:09 cmurrell kernel: [868302.148101] ivtv0:  info: Start 
  encoder stream encoder MPG
  Nov 28 15:00:09 cmurrell kernel: [868302.188580] ivtv0:  info: Setup VBI 
  API header 0xbd03 pkts 1 buffs 4 ln 24 sz 1456
  Nov 28 15:00:09 cmurrell kernel: [868302.188655] ivtv0:  info: Setup VBI 
  start 0x002fea04 frames 4 fpi 1
  Nov 28 15:00:09 cmurrell kernel: [868302.191952] ivtv0:  info: PGM Index at 
  0x00180150 with 400 elements
  Nov 28 15:00:10 cmurrell kernel: [868302.544052] ivtv0 encoder MPG: 
  VIDIOC_ENCODER_CMD cmd=0, flags=0
  Nov 28 15:00:12 cmurrell kernel: [868305.047260] ivtv0:  ioctl: 
  V4L2_ENC_CMD_STOP
  Nov 28 15:00:12 cmurrell kernel: [868305.047265] ivtv0:  info: close 
  stopping capture
  Nov 28 15:00:12 cmurrell kernel: [868305.047270] ivtv0:  info: Stop Capture
  ...
 
  FWIW, the recording software here is MythTV completely up to date on the
  0.25-fixes branch.
 
  Thoughts?
 
 
 Mmm, the log shows this repeating pattern:
 
 ---
 Nov 28 17:54:46 cmurrell kernel: [878779.229702] ivtv0:  info: Setup
 VBI start 0x002fea04 frames 4 fpi 1
 Nov 28 17:54:46 cmurrell kernel: [878779.233129] ivtv0:  info: PGM
 Index at 0x00180150 with 400 elements
 Nov 28 17:54:47 cmurrell kernel: [878779.556039] ivtv0 encoder MPG:
 VIDIOC_ENCODER_CMD cmd=0, flags=0
 Nov 28 17:54:49 cmurrell kernel: [878782.059204] ivtv0:  ioctl:
 V4L2_ENC_CMD_STOP
 Nov 28 17:54:49 cmurrell kernel: [878782.059209] ivtv0:  info: close
 stopping capture
 Nov 28 17:54:49 cmurrell kernel: [878782.059214] ivtv0:  info: Stop Capture
 Nov 28 17:54:51 cmurrell kernel: [878784.156135] ivtv0 encoder MPG:
 VIDIOC_ENCODER_CMD cmd=1, flags=1
 Nov 28 17:54:51 cmurrell kernel: [878784.166157] ivtv0:  ioctl:
 V4L2_ENC_CMD_START
 Nov 28 17:54:51 cmurrell kernel: [878784.166165] ivtv0:  info: Start
 encoder stream encoder MPG
 ---
 
 And from 15:00 to 18:00 recording fails?
 
 Perhaps it would make sense to restart application upon driver failure,
 now that output is more verbose.

Hi Ezequiel,

Nope.  IIRC, that's just MythTV timing-out, closing the device node, and
reopening the device node, in attempt to make things work again.

Hi Brian,
I haven't checked the log you provided yet, but you'll likely need to
set the module debug flags a little more verbose.

/sbin/modinfo ivtv | less
[...]
parm:   debug:Debug level (bitmask). Default: 0
   1/0x0001: warning
   2/0x0002: info
   4/0x0004: mailbox
   8/0x0008: ioctl
  16/0x0010: file
  32/0x0020: dma
  64/0x0040: irq
 128/0x0080: decoder
 256/0x0100: yuv
 512/0x0200: i2c
1024/0x0400: high volume
[..]

So maybe as root

# echo 0x07f  /sys/module/ivtv/parameters/debug

until the problem appears.  Then once you experience the problem change
it to high volume

# echo 0x47f  /sys/module/ivtv/parameters/debug

You may want to also get a baseline of what a good capture looks like
using high volume debugging.  Be aware that high volume debugging will
fill up your logs and degrade performance a little, so you don't want to
normally use high volume debugging.


 Regards,
 
 Ezequiel
 
 PS: Please don't drop linux-media list from Cc

+1

The ideas or interest of one individual often spurs that of others.

Regards,
Andy

--
To 

Re: anyone here know anyone at ivtvdriver.org? it's been down a few days now

[Andy Walls]

Brian J. Murrell br...@interlinx.bc.ca wrote:

I wonder if anyone here has control over or knows anyone who has
control
over the ivtvdriver.org website and lists.

They seem to be down and have been for a bit now.

Does anyone know if there is any expectation that this stuff will come
back or is headed for moribund-land?

Cheers,
b.

I know its down.  I've been traveling.  I have to talk with the webmaster when 
I get back home.

Regards,
Andy

--
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: Poor HVR 1600 Video Quality - Feedback for Devin Heitmueller 2012-11-24

[Andy Walls]

On Sat, 2012-11-24 at 23:08 -0500, Bob Lightfoot wrote:
 Devin :
  Let me see if I can answer some of your questions.
 

 
 2.  Links on Google to files related to this issue :
 A. The Main Can on the Tuner Card -
https://docs.google.com/open?id=0B95B_9punKEmeHBUNHprMnVNV00
 B. First of the Conextant Chips on Card -
https://docs.google.com/open?id=0B95B_9punKEmT2wwbmltSzFWb2c
 C. Second of the Conextant Chips on Card -
https://docs.google.com/open?id=0B95B_9punKEmNTdVMENHUFllNzA
 D. A Final ESMT Chip on Card -
https://docs.google.com/open?id=0B95B_9punKEmYUd5eWNrWEhudWc

Alright, this is one of the older card models.  They have been working
for quite a long while.

 E. The v4l2-ctl and cat /dev/video2 file made from Svideo1
https://docs.google.com/open?id=0B95B_9punKEmUGdJNTI3ZnR2T1k

Looks good.

 F. The v4l2-ctl and cat /dev/video2 file made from Tuner1
https://docs.google.com/open?id=0B95B_9punKEmOUhLWjNyRG02NDA

Blech.  Obviously an almost total loss of Horizontal Synchronization.
Vertical Synchronization appears to be OK, under the circumstances. 

FYI,  I normally associate the following conditions with signal level
going into the CX23418's integrated CX25843 A/V decoder:

- Good sound, bad video: signal strength too low
- Bad/no sound, good video:  signal strength too high

Low video signal strength could explain why H-sync is lost.  However, it
also could be a DC voltage level building up on the CVBS signal trace
between the tuner and the CX23418 causing the CVBS signal (and the
H-sync pulse) to be floated upwards, such that the H-Sync pulse ins't
detected.

So here's what you need to do:

1. provide the output of v4l2-ctl -d /dev/video2 --log-status, so I can
see the analog tuner assembly that your unit has.

2. Test the unit under the previous Linux kernel version with which you
were *sure* the unit worked properly.  Or test with Windows as Devin
suggested.  We're trying to eliminate a bad HVR-1600 card here, so if
you can test it in that very same machine, all the better.

Also, if you can provide us with the two kernel versions, working and
non-working, we can narrow down if a kernel change caused the problem
for you.

3. Test with as few cards in the PC chassis as possible.  This will
eliminate some EMI and power supply problems.  It's a shot in the dark,
but easy enough for you to try.

4. If you do decide to much around in the PC, pull out all the PCI
cards, blow the dust out of all the slots, reseat the cards, and retest.
I am amazed at how often that actually helps with various problems.



I would point you to an email where I added all sorts of extra controls
to the cx18 driver in a patchset, for the express purpose of debugging
sync problems:

http://www.gossamer-threads.com/lists/ivtv/users/40227?do=post_view_threaded#40227

and ask you to fiddle around with them.

Unfortunately the patches, which are still here:

http://linuxtv.org/hg/~awalls/v4l-dvb-ctls/

are very old and don't apply cleanly to newer versions of the cx18
driver. :(


My suspicion is either 

a. you have a marginal CX23418 chip and something on you card or in your
chassis is allowing a DC charge to build up on the CVBS line between the
tuner and the CX23418

or

b. a recent kernel change broke the ananlog tuner configuration for the
tuner on your board.


 3.  I tested with both the SVideo and Coax Inputs for Analog.  As
 you'll see from the 10 second videos the SVideo works fine but the
 Coax Tuner is a problem.
 
 4.  I don't know if I am capturing raw for MPEG compressed for certain
 but I'll go over the test method used to make to two videos and that
 should also answer this question.

It doesn't matter.  It looks like MPEG and not raw YUV, BTW.


 5. As far as test tools I have used v4l2-ctl, mplayer, vlc and cat
 commands for testing.
 
 6.  Commands issued in order were as follows for the SVideo Capture:
 A. v4l2-ctl --list-devices
 B. v4l2-ctl -d /dev/video2 --list-inputs
 C. v4l2-ctl -d /dev/video2 --set-input=1  {Note this is SVideo1}
 D. v4l2-ctl -d /dev/video2 --list-standards | less
 E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
 F. mplayer /dev/video2 -cache 8192
 G. close mplayer after successfully watching video
 H. cat /dev/video2  hvr1600-svideo1.mpg
 
 7.  Commands issued in order were as follows for the Tuner1 Capture:
 A. v4l2-ctl --list-devices
 B. v4l2-ctl -d /dev/video2 --list-inputs
 C. v4l2-ctl -d /dev/video2 --set-input=0 {Note this is Tuner1}
 D. v4l2-ctl -d /dev/video2 --list-standards | less
 E. v4l2-ctl -d /dev/video2 --set-standard=1  {Note this is NTSC}
 F. v4l2-ctl -d /dev/video2 -f 67.250  {Note this is us-bdcst chan 4}
 G. mplayer /dev/video2 -cache 8192
 H. close mplayer after successfully watching video
 I. cat /dev/video2  hvr1600-Tuner1.mpg
 
 8.  It should be obvious by this point, but I am too much of a
 neophyte to be compiling 

Re: ir rremote support for TeVii S471

[Andy Walls]

On Mon, 2012-11-12 at 10:04 +0100, Joakim Hernberg wrote:
 Hello,
 
 First of all, thanks a lot for adding the S471 support to the kernel.
 It appears to work very well on 3.6 which is what I'm running.
 
 I am trying to get the included ir remote working.  Tried the
 enable_885_ir=1 module parameter (for cx23885) to no effect.
 
 Any ideas?

You need to patch the cx23885 driver to teach it about the remote.

Here's a recent example of how to do this: 
http://www.spinics.net/lists/linux-media/msg56151.html
http://www.spinics.net/lists/linux-media/msg56152.html
http://www.spinics.net/lists/linux-media/msg56153.html

You can probably just use the RC_MAP_TEVII_NEC remote controller map and
not have to define a new one.

If the TeVii S471 has a CX23885 chip, just patch the driver similar to
what is already done for the TeVii S470 (load the cx25840 driver and use
the AV_CORE interrupt).

If the TeVii S471 uses a CX23888 chip, do something simlar for what is
done for the HVR-1270 (load the cx25840 driver and use the IR
interrupt), but still use setup paramaters that match the S470's NEC
remote.

Be warned: I never was able to get the CX23885 on the S470 to stop
producing an interrupt storm.  Blacklist the cx23885 module after you
have made you patches and load it manually, in case the same problem
happens with the S471.

-Andy 

--
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] cx23885: Added support for AVerTV Hybrid Express Slim HC81R (only analog)

[Andy Walls]

On Sun, 2012-11-04 at 09:59 +0200, Oleg Kravchenko wrote:
 субота, 03-лис-2012 16:41:10 Andy Walls написано:
  Oleg Kravchenko o...@kaa.org.ua wrote:
  Hello! Please review my patch.
  
  Supported inputs:
  Television, S-Video, Component.
  
  Modules options:
  options cx25840 firmware=v4l-cx23418-dig.fw
  
  Hi,
  
  Please do not use the CX23418 digitizer firmware with the CX2388[578] chips.
   Use the proper cx23885 digitizer firmware.  You need the proper firmware
  to get the best results in detecting the audio standard in broadcast analog
  video.
  
  Regards,
  Andy
 
 Windows driver use v4l-cx23418-dig.fw
 95bc688d3e7599fd5800161e9971cc55  merlinAVC.rom
 95bc688d3e7599fd5800161e9971cc55  /lib/firmware/v4l-cx23418-dig.fw
 
 So, i think this is a proper firmware :)

Maybe it is, but it is not the v4l-cx23418-dig.fw file:

$ md5sum /lib/firmware/v4l-cx23418-dig.fw 
b3704908fd058485f3ef136941b2e513  /lib/firmware/v4l-cx23418-dig.fw

Which can be extracted from this (double) gzipped tar archive:
http://dl.ivtvdriver.org/ivtv/firmware/cx18-firmware.tar.gz
(After downloading the file, rename it to cx18-firmware.tar.gz.gz.
Sorry, I don't know how to stop the web server from gzipping things
twice. :( )

Mauro or Hans,

Linuxtv.org seems to be serving up the wrong firmware for the CX23418's
built in CX25843 core:
http://www.linuxtv.org/downloads/firmware/v4l-cx23418-dig.fw

$ md5sum Downloads/linuxtv.org-v4l-cx23418-dig.fw
95bc688d3e7599fd5800161e9971cc55 Downloads/linuxtv.org-v4l-cx23418-dig.fw

Can either of you please put the proper firmware file in place at
LinuxTV.org? 

Thanks.

Regards,
Andy

--
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] cx23885: Added support for AVerTV Hybrid Express Slim HC81R (only analog)

[Andy Walls]

Oleg Kravchenko o...@kaa.org.ua wrote:

Hello! Please review my patch.

Supported inputs:
Television, S-Video, Component.

Modules options:
options cx25840 firmware=v4l-cx23418-dig.fw   

Hi,

Please do not use the CX23418 digitizer firmware with the CX2388[578] chips.  
Use the proper cx23885 digitizer firmware.  You need the proper firmware to get 
the best results in detecting the audio standard in broadcast analog video.

Regards,
Andy
--
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] saa7134: Add pm_qos_request to fix video corruption

[Andy Walls]

On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
 On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
  I prefer if you don't c/c me on that ;) Patchwork is the main source that I 
  use
  on my patch reviews.
  
 Noted.
 
  Btw, I saw your patch yesterday (and skipped it, for now), as I never played
  with those pm QoS stuff before, nor I ever noticed anything like what you
  reported on saa7134 (but I can't even remember the last time I tested 
  something
  on a saa7134 board ;) - so, it can be some new bug).
  
  So, I'll postpone its review to when I have some time to actually test it
  especially as the same issue might also be happening on other drivers.
  
 It will affect other drivers as well; the basic cause is that modern chips
 can enter a package deep sleep state that affects both CPU speed and latency
 to start of DMA. On older systems, this couldn't happen - the Northbridge
 kept running at all times, and DMA latencies were low.
 
 However, on the Intel Sandybridge system I'm testing with, the maximum wake
 latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
 hold onto data for that long, and overflows, resulting in the corruption I'm
 seeing. The pm QoS request fixes this for me, by telling the PM subsystem
 that the SAA7134 cannot cope with a long latency on the first write of a DMA
 transfer.
 
 Now, some media bridges (like the ones driven by the cx18 driver) can cope
 with very high latency before the beginning of a DMA burst. Andy Walls has
 worked on the cx18 driver to cope in this situation, so it doesn't fail even
 with the 109 microsecond DMA latency we have on Sandybridge.

Well if brdige wake-up DMA latency is the problem, it is alos the case
that the CX23418 has a *lot* of on board memory with which to collect
video and compress it.  (And lets face it, the CX23418 is an SoC with
two ARM cores and a lot of dedicated external memory, as opposed to the
SAA7134 with 1 kB of FIFO.)   That hardware helps quite a bit, if the
PCI bus is slow to wake up.

I found a SAA7134 sheet for you:

http://www.nxp.com/documents/data_sheet/SAA7134HL.pdf

Section 6.4.3 has a short description of the behaviour when the FIFO
overflows.

But this sheet (close enough):

http://www.nxp.com/documents/data_sheet/SAA7133HL.pdf

Has much nicer examples of the programmed levels of the FIFO in section
6.4.3.  That 1 kB is for everything: raw VBI, Y, U, V, MPEG, and Audio.
So you're lucky if one full line of video fits in the FIFO.

 Others, like the SAA7134, just don't have that much buffering, and we need
 to ask the pm core to cope with it. I suspect that most old drivers will need
 updating if anyone wants to use them with modern systems; either they'll have
 an architecture like the cx18 series, and the type of work Andy has done will
 fix the problem, or they'll behave like the saa7134, and need a pm_qos request
 to ensure that the CPU package (and thus memory controller) stay awake.

Unless the chip has a lot of internal memory and processing resources, I
suspect a pm_qos solution is needed to ensure the PCI bus responds in
time.

This is a system level issue though.  Having the drivers decide what QoS
they need in the absences of total system requirements, is the right
thing for the home user.  It might not be very friendly for a
professional solution where someone is trying to tune the use of the
system IO bandwidth and CPU resources.

The ivtv driver and cx18 driver unconditionally bumping up their PCI
latency timer to 64 cycles minimum always bugged me: drivers shouldn't
be deciding QoS in a vaccuum.  But, then again, user complaints went
away and the 64 PCI cycles seemed to be a minimum QoS that everyone
needed.  Also both drivers have a ivtv/cx18_pci_latency module option to
override the behaviour anyway.


-Andy

--
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] saa7134: Add pm_qos_request to fix video corruption

[Andy Walls]

On Mon, 2012-10-29 at 13:02 +, Simon Farnsworth wrote:
 On Monday 29 October 2012 09:58:17 Mauro Carvalho Chehab wrote:
  I prefer if you don't c/c me on that ;) Patchwork is the main source that I 
  use
  on my patch reviews.
  
 Noted.
 
  Btw, I saw your patch yesterday (and skipped it, for now), as I never played
  with those pm QoS stuff before, nor I ever noticed anything like what you
  reported on saa7134 (but I can't even remember the last time I tested 
  something
  on a saa7134 board ;) - so, it can be some new bug).
  
  So, I'll postpone its review to when I have some time to actually test it
  especially as the same issue might also be happening on other drivers.
  
 It will affect other drivers as well; the basic cause is that modern chips
 can enter a package deep sleep state that affects both CPU speed and latency
 to start of DMA. On older systems, this couldn't happen - the Northbridge
 kept running at all times, and DMA latencies were low.
 
 However, on the Intel Sandybridge system I'm testing with, the maximum wake
 latency from deep sleep is 109 microseconds; the SAA7134's internal FIFO can't
 hold onto data for that long, and overflows,

BTW

For Y:U:Y:V or raw VBI with a PAL line rate
109 usecs * 15,625 lines/sec ~= 1.7 lines

1.7 lines * 1440 samples/line ~= 2452 samples

2452 samples / 1024 samples/FIFO ~= 2.4 FIFOs

So 109 usecs fully overruns the FIFO by about 1.4 FIFO depths.


  resulting in the corruption I'm
 seeing. The pm QoS request fixes this for me, by telling the PM subsystem
 that the SAA7134 cannot cope with a long latency on the first write of a DMA
 transfer.

Regards,
Andy

--
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: hvr-1600 records one, fails recording the other on an mplex

[Andy Walls]

Brian J. Murrell br...@interlinx.bc.ca wrote:

Hi,

As I wrote about a number (3-4) of weeks ago, I am still having a
problem with my HVR-1600 failing on multiple digital recordings.  At
the
time I reported this previously, there was a question of whether my
current version of MythTV was to blame.

To that end, I updated my MythTV to the latest (at the time) on the
0.25-fixes branch.  I also, at the same time, switched my primary
digital tuner to my HVR-950Q.  I ran in that configuration for a couple
of weeks without a single failed recording.

A week ago, I switched back to having my HVR-1600 as the primary device
to determine if it was the HVR-950Q switch or the MythTV update that
gave me such success and sure enough, on a particularly busy evening of
recording (but no busier than the same evening the prior two weeks
where
the HVR-950Q worked flawlessly) one recording on a given multiplex
failed while another on the same multiplex, at the same time, was
successful.

Unsurprisingly femon reported FE_HAS_LOCK for the entire time
period
of the failed recording.  I say unsurprisingly because as I mentioned
prior, another recording on the HVR-1600 at the same time was
successful.

Additionally, many, many times during the last week more than one
recording on a given multiplex on this HVR-1600 worked so this problem
is most definitely intermittent, but my experience for the last 3-4
weeks I think proves that it's a problem with the HVR-1600 and not
MythTV given that it's something that happens only with the HVR-1600
and
not with the HVR-950Q.

Unfortunately, there was nothing on the kernel log at the time of the
failed recording.

How can I gather further information on what might be going on which is
causing this failure?

b.


# /sbin/modinfo cx18
Look at the flags for the debug module option.
You probably want to log info, warning, mailbox/api, and i2c at first.  If that 
doesn't show you anything, log dma, irq, and high volume.  You'll get very 
heavy log activity, but you'll be able to see if buffers are going back and 
forth.

Really I'm not sure why you could record one channel from mux (e.g. 7.1) and 
not another (e.g. 7.2).  The ATSC or QAM data is just that: a mux of all the 
programs on that frequency.  The cx18 driver just passes the data over to the 
DVB subsystem for processing/demuxing.Maybe the cx18 driver initializes 
something wrong initializing dvb in cx18-dvb.

Regards,
Andy
--
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 01/23] uvc: Replace memcpy with struct assignment

[Andy Walls]

Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:

Hi Ezequiel,

Thanks for the patch.

On Tuesday 23 October 2012 16:57:04 Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to
read.
 
 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.

This looks good, but there's one more memcpy that can be replaced by a
direct 
structure assignment in uvc_ctrl_add_info() 
(drivers/media/usb/uvc/uvc_ctrl.c). You might want to check why it
hasn't been 
caught by the semantic patch.

 A simplified version of the semantic match that finds this problem is
as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/usb/uvc/uvc_v4l2.c |6 +++---
  1 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/drivers/media/usb/uvc/uvc_v4l2.c
 b/drivers/media/usb/uvc/uvc_v4l2.c index f00db30..4fc8737 100644
 --- a/drivers/media/usb/uvc/uvc_v4l2.c
 +++ b/drivers/media/usb/uvc/uvc_v4l2.c
 @@ -314,7 +314,7 @@ static int uvc_v4l2_set_format(struct
uvc_streaming
 *stream, goto done;
  }
 
 -memcpy(stream-ctrl, probe, sizeof probe);
 +stream-ctrl = probe;
  stream-cur_format = format;
  stream-cur_frame = frame;
 
 @@ -386,7 +386,7 @@ static int uvc_v4l2_set_streamparm(struct
uvc_streaming
 *stream, return -EBUSY;
  }
 
 -memcpy(probe, stream-ctrl, sizeof probe);
 +probe = stream-ctrl;
  probe.dwFrameInterval =
  uvc_try_frame_interval(stream-cur_frame, interval);
 
 @@ -397,7 +397,7 @@ static int uvc_v4l2_set_streamparm(struct
uvc_streaming
 *stream, return ret;
  }
 
 -memcpy(stream-ctrl, probe, sizeof probe);
 +stream-ctrl = probe;
  mutex_unlock(stream-mutex);
 
  /* Return the actual frame period. */

-- 
Regards,

Laurent Pinchart

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

Maybe because there is no '' operator on the second argument. 

Regards,
Andy
--
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 15/23] ivtv: Replace memcpy with struct assignment

[Andy Walls]

On Tue, 2012-10-23 at 16:57 -0300, Ezequiel Garcia wrote:
 This kind of memcpy() is error-prone. Its replacement with a struct
 assignment is prefered because it's type-safe and much easier to read.

This one is a code maintenance win. :)

See my comments at the end for the difference in assembled code on an
AMD x86_64 CPU using
$ gcc --version
gcc (GCC) 4.6.3 20120306 (Red Hat 4.6.3-2)


 Found by coccinelle. Hand patched and reviewed.
 Tested by compilation only.
 
 A simplified version of the semantic match that finds this problem is as
 follows: (http://coccinelle.lip6.fr/)
 
 // smpl
 @@
 identifier struct_name;
 struct struct_name to;
 struct struct_name from;
 expression E;
 @@
 -memcpy((to), (from), E);
 +to = from;
 // /smpl
 
 Cc: Andy Walls awa...@md.metrocast.net

Signed-off-by: Andy Walls awa...@md.metrocast.net


 Signed-off-by: Peter Senna Tschudin peter.se...@gmail.com
 Signed-off-by: Ezequiel Garcia elezegar...@gmail.com
 ---
  drivers/media/pci/ivtv/ivtv-i2c.c |   12 
  1 files changed, 4 insertions(+), 8 deletions(-)
 
 diff --git a/drivers/media/pci/ivtv/ivtv-i2c.c 
 b/drivers/media/pci/ivtv/ivtv-i2c.c
 index d47f41a..27a8466 100644
 --- a/drivers/media/pci/ivtv/ivtv-i2c.c
 +++ b/drivers/media/pci/ivtv/ivtv-i2c.c
 @@ -719,13 +719,10 @@ int init_ivtv_i2c(struct ivtv *itv)
   return -ENODEV;
   }
   if (itv-options.newi2c  0) {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_hw_template,
 -sizeof(struct i2c_adapter));
 + itv-i2c_adap = ivtv_i2c_adap_hw_template;
   } else {
 - memcpy(itv-i2c_adap, ivtv_i2c_adap_template,
 -sizeof(struct i2c_adapter));
 - memcpy(itv-i2c_algo, ivtv_i2c_algo_template,
 -sizeof(struct i2c_algo_bit_data));
 + itv-i2c_adap = ivtv_i2c_adap_template;
 + itv-i2c_algo = ivtv_i2c_algo_template;
   }
   itv-i2c_algo.udelay = itv-options.i2c_clock_period / 2;
   itv-i2c_algo.data = itv;
 @@ -735,8 +732,7 @@ int init_ivtv_i2c(struct ivtv *itv)
   itv-instance);
   i2c_set_adapdata(itv-i2c_adap, itv-v4l2_dev);
  
 - memcpy(itv-i2c_client, ivtv_i2c_client_template,
 -sizeof(struct i2c_client));
 + itv-i2c_client = ivtv_i2c_client_template;
   itv-i2c_client.adapter = itv-i2c_adap;
   itv-i2c_adap.dev.parent = itv-pdev-dev;
  

I looked at the generated assembly with only this last change
implemented:

$ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
[...]
 07e0  69767476 20696e74 65726e61  ivtv interna
 07f0 6c00     l...
 0800      
 0810      
 0820      
 0830      
[...]
init_ivtv_i2c():
/home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
13bb:   48 c7 c6 00 00 00 00mov$0x0,%rsi
13be: R_X86_64_32S  .rodata+0x7e0
13c2:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


$ objdump -h -r -d -l -s orig-ivtv-i2c.o.sav | less
[...]
 07e0  69767476 20696e74 65726e61  ivtv interna
 07f0 6c00     l...
 0800      
 0810      
 0820      
 0830      
[...]
init_ivtv_i2c():
/home/andy/cx18dev/git/media_tree/drivers/media/video/ivtv/ivtv-i2c.c:738
13bb:   48 8d bb 30 04 01 00lea0x10430(%rbx),%rdi
13c2:   48 c7 c6 00 00 00 00mov$0x0,%rsi
13c5: R_X86_64_32S  .rodata+0x7e0
13c9:   b9 5a 00 00 00  mov$0x5a,%ecx
13ce:   f3 48 a5rep movsq %ds:(%rsi),%es:(%rdi)


The generated code is reordered, but essentially identical.  So I guess
in this instance, the preprocessor defines resolved such that an x86-64
optimized memcpy() function was not used from the linux kernel source.

Since all of these memcpy()'s are only called once for each board at
board initialization, performance here really doesn't matter here
anyway.  (Unless one is insanely trying to shave microseconds off boot
time :P )

With other memcpy()/assignement_operator replacement patches, you may
wish to keep performance in mind, if you are patching a frequently
called function.

Regards,
Andy


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