date:20131211

Hauppauge WinTV HVR850 2040:b140 unusable with cx231xx

2013-12-11 Thread Connor Behan

I ordered an HVR850 USB TV tuner, planning to use it with an NTSC cable input.
The LinuxTV.org page
http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-850 said that there
were three different models, so I checked and mine is 2040:b140... the last one
to be supported. A discussion post
http://www.linuxtv.org/wiki/index.php/Talk:Hauppauge_WinTV-HVR-850#Possibly_Valuable_Information
there said that the card was working as of 2013 but my experience has been
closer to these ones:

https://mailman.archlinux.org/pipermail/arch-general/2011-September/021962.html
http://www.spinics.net/lists/linux-media/msg49030.html

Since it was my first time using v4l, I didn't know what modules to load. Upon
inserting the tuner, I saw 16 new modules autoloaded: media, tuner, videodev,
videobuf_core, videobuf_vmalloc, v4l2_common, rc_core, cx25840, cx2341x,
cx231xx, cx231xx_alsa, cx231xx_dvb, dvb_core, tda18271, tea5767, lgdt3305. This
creates a few new device nodes:

/dev/dvb/adapter0/demux0*
/dev/dvb/adapter0/dvr0*
/dev/dvb/adapter0/frontend0*
/dev/dvb/adapter0/net0*
/dev/v4l
/dev/vbi0
/dev/video*
/dev/video0

The ones with asterisk are only created sometimes. The dmesg output was quite
problematic (first_dmesg http://paste.ubuntu.com/6555061/) and I later found
out this was because of lgdt3305_attach() and tda18271_attach(). If I
explicitly modprobe lgdt3305 and tda18271 before inserting the tuner, I get
something better (second_dmesg http://paste.ubuntu.com/6555075/). However,
one troubling thing is __tda18271_write_regs failing with -32. This is probably
the very first call to __tda18271_write_regs being done in
tda18271_init_regs(). So the registers on this chip that is essential to use
the analog part of the tuner are not initialized. When I try to actually use
the tuner, the same error appears again (third_dmesg
http://paste.ubuntu.com/6555081/).

I was testing it with the command mplayer -tv
driver=v4l2:device=/dev/video0:norm=NTSC:chanlist=us-cable tv:// and seeing a
green screen. But I also see a black screen when using xawtv and a 0 byte file
when using cat /dev/video0 foo. I tried a few different machines and kernel
versions.

Some people have suggested patches. One was a user named Jimbo on
http://www.kernellabs.com/blog/?p=1445 (I'm guessing the polaris4 link is
broken because that was merged to mailine?) Anyway he said that
HAUPPAUGE_USBLIVE2 workarounds for error -71 might need to be there for
HAUPPAUGE_EXETER. I tried this and it didn't work. One person who blogged about
trouble with the HAUPPAUGE_USBLIVE2
http://csharpnews.wordpress.com/2011/06/15/usb-live-2-on-ubuntu-shows-only-black-screen/
said it was fixed by getting rid of a value |= (1 7). I tried this and it
also didn't work.

Before I dangerously try any more patches when I don't know what they do... do
you guys know how to fix this?

signature.asc
Description: OpenPGP digital signature

RE: [RFCv4 PATCH 7/8] vb2: return ENODATA in start_streaming in case of too few buffers.

2013-12-11 Thread Kamil Debski

Hi,

 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Tuesday, December 10, 2013 8:52 AM
 
 As Guennadi mentioned in his review, ENODATA will be replaced by
 ENOBUFS, which is more appropriate.
 
 Prabhakar, Kamil, Tomasz, are you OK with this patch provided
 s/ENODATA/ENOBUFS/ ?

The patch looks good. However, shouldn't the documentation be changed too?

Now it says: [1]
(...) Accordingly the output hardware is disabled, no video signal is
produced until VIDIOC_STREAMON has been called. The ioctl will succeed
only when at least one output buffer is in the incoming queue. (...)

If I understand correctly, now the ioctl will succeed with no buffers
queued. Apart from the above you have my ack.

Acked-by: Kamil Debski k.deb...@samsung.com

Best wishes,
-- 
Kamil Debski
Samsung RD Institute Poland

[1] - http://linuxtv.org/downloads/v4l-dvb-apis/vidioc-streamon.html

 
 On 12/09/2013 02:43 PM, Hans Verkuil wrote:
  From: Hans Verkuil hans.verk...@cisco.com
 
  This works together with the retry_start_streaming mechanism to allow
  userspace to start streaming even if not all required buffers have
 been queued.
 
  Signed-off-by: Hans Verkuil hans.verk...@cisco.com
  Cc: Lad, Prabhakar prabhakar.cse...@gmail.com
  Cc: Tomasz Stanislawski t.stanisl...@samsung.com
  Cc: Kyungmin Park kyungmin.p...@samsung.com
  Cc: Kamil Debski k.deb...@samsung.com
  Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
  ---
   drivers/media/platform/davinci/vpbe_display.c   | 2 +-
   drivers/media/platform/davinci/vpif_capture.c   | 2 +-
   drivers/media/platform/davinci/vpif_display.c   | 2 +-
   drivers/media/platform/s5p-mfc/s5p_mfc_enc.c| 2 +-
   drivers/media/platform/s5p-tv/mixer_video.c | 2 +-
   drivers/media/platform/soc_camera/mx2_camera.c  | 2 +-
  drivers/staging/media/davinci_vpfe/vpfe_video.c | 2 ++
   7 files changed, 8 insertions(+), 6 deletions(-)
 
  diff --git a/drivers/media/platform/davinci/vpbe_display.c
  b/drivers/media/platform/davinci/vpbe_display.c
  index eac472b..53be7fc 100644
  --- a/drivers/media/platform/davinci/vpbe_display.c
  +++ b/drivers/media/platform/davinci/vpbe_display.c
  @@ -347,7 +347,7 @@ static int vpbe_start_streaming(struct vb2_queue
 *vq, unsigned int count)
  /* If buffer queue is empty, return error */
  if (list_empty(layer-dma_queue)) {
  v4l2_err(vpbe_dev-v4l2_dev, buffer queue is empty\n);
  -   return -EINVAL;
  +   return -ENODATA;
  }
  /* Get the next frame from the buffer queue */
  layer-next_frm = layer-cur_frm = list_entry(layer-
 dma_queue.next,
  diff --git a/drivers/media/platform/davinci/vpif_capture.c
  b/drivers/media/platform/davinci/vpif_capture.c
  index 52ac5e6..4b04a27 100644
  --- a/drivers/media/platform/davinci/vpif_capture.c
  +++ b/drivers/media/platform/davinci/vpif_capture.c
  @@ -277,7 +277,7 @@ static int vpif_start_streaming(struct vb2_queue
 *vq, unsigned int count)
  if (list_empty(common-dma_queue)) {
  spin_unlock_irqrestore(common-irqlock, flags);
  vpif_dbg(1, debug, buffer queue is empty\n);
  -   return -EIO;
  +   return -ENODATA;
  }
 
  /* Get the next frame from the buffer queue */ diff --git
  a/drivers/media/platform/davinci/vpif_display.c
  b/drivers/media/platform/davinci/vpif_display.c
  index c31bcf1..c5070dc 100644
  --- a/drivers/media/platform/davinci/vpif_display.c
  +++ b/drivers/media/platform/davinci/vpif_display.c
  @@ -239,7 +239,7 @@ static int vpif_start_streaming(struct vb2_queue
 *vq, unsigned int count)
  if (list_empty(common-dma_queue)) {
  spin_unlock_irqrestore(common-irqlock, flags);
  vpif_err(buffer queue is empty\n);
  -   return -EIO;
  +   return -ENODATA;
  }
 
  /* Get the next frame from the buffer queue */ diff --git
  a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
  b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
  index 4ff3b6c..3bdfe85 100644
  --- a/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
  +++ b/drivers/media/platform/s5p-mfc/s5p_mfc_enc.c
  @@ -1863,7 +1863,7 @@ static int s5p_mfc_start_streaming(struct
 vb2_queue *q, unsigned int count)
  if (ctx-src_bufs_cnt  ctx-pb_count) {
  mfc_err(Need minimum %d OUTPUT buffers\n,
  ctx-pb_count);
  -   return -EINVAL;
  +   return -ENODATA;
  }
  }
 
  diff --git a/drivers/media/platform/s5p-tv/mixer_video.c
  b/drivers/media/platform/s5p-tv/mixer_video.c
  index 81b97db..220ec31 100644
  --- a/drivers/media/platform/s5p-tv/mixer_video.c
  +++ b/drivers/media/platform/s5p-tv/mixer_video.c
  @@ -948,7 +948,7 @@ static int start_streaming(struct vb2_queue *vq,
  unsigned int count)
 
  if (count == 0) {
  mxr_dbg(mdev, no output buffers queued\n);
  -   return -EINVAL;
  +   return -ENODATA;
  }
 
  /* block any changes in output

Re: [RFCv4 PATCH 7/8] vb2: return ENODATA in start_streaming in case of too few buffers.

2013-12-11 Thread Hans Verkuil

Hi Kamil,

On 12/11/13 11:27, Kamil Debski wrote:
 Hi,
 
 From: Hans Verkuil [mailto:hverk...@xs4all.nl]
 Sent: Tuesday, December 10, 2013 8:52 AM

 As Guennadi mentioned in his review, ENODATA will be replaced by
 ENOBUFS, which is more appropriate.

 Prabhakar, Kamil, Tomasz, are you OK with this patch provided
 s/ENODATA/ENOBUFS/ ?
 
 The patch looks good. However, shouldn't the documentation be changed too?
 
 Now it says: [1]
 (...) Accordingly the output hardware is disabled, no video signal is
 produced until VIDIOC_STREAMON has been called. The ioctl will succeed
 only when at least one output buffer is in the incoming queue. (...)
 
 If I understand correctly, now the ioctl will succeed with no buffers
 queued.

That's true *only* for drivers using vb2. As long as not all drivers are
converted (which is a *very* long-term project) I don't think i can change
the documentation.

Regards,

Hans

 Apart from the above you have my ack.
 
 Acked-by: Kamil Debski k.deb...@samsung.com
 
 Best wishes,
 
--
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] v4l2-dev: Add tracepoints for QBUF and DQBUF

2013-12-11 Thread Mauro Carvalho Chehab

Hans,

Em Wed, 11 Dec 2013 08:29:58 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:

 On 12/10/2013 09:53 PM, Mauro Carvalho Chehab wrote:
  Em Sat, 23 Nov 2013 17:54:48 +0100
  Hans Verkuil hverk...@xs4all.nl escreveu:
  
  On 11/23/2013 05:30 PM, Sylwester Nawrocki wrote:
  Hi,
 
  On 11/23/2013 12:25 PM, Hans Verkuil wrote:
  Hi Wade,
 
  On 11/22/2013 08:48 PM, Wade Farnsworth wrote:
  Add tracepoints to the QBUF and DQBUF ioctls to enable rudimentary
  performance measurements using standard kernel tracers.
 
  Signed-off-by: Wade Farnsworthwade_farnswo...@mentor.com
  ---
 
  This is the update to the RFC patch I posted a few weeks back.  I've 
  added
  several bits of metadata to the tracepoint output per Mauro's 
  suggestion.
 
  I don't like this. All v4l2 ioctls can already be traced by doing e.g.
  echo 1 (or echo 2)/sys/class/video4linux/video0/debug.
 
  So this code basically duplicates that functionality. It would be nice 
  to be able
  to tie in the existing tracing code (v4l2-ioctl.c) into tracepoints.
 
  I think it would be really nice to have this kind of support for standard
  traces at the v4l2 subsystem. Presumably it could even gradually replace
  the v4l2 custom debug infrastructure.
 
  If I understand things correctly, the current tracing/profiling 
  infrastructure
  is much less invasive than inserting printks all over, which may cause 
  changes
  in control flow. I doubt the system could be reliably profiled by 
  enabling all
  those debug prints.
 
  So my vote would be to add support for standard tracers, like in other
  subsystems in the kernel.
 
  The reason for the current system is to trace which ioctls are called in
  what order by a misbehaving application. It's very useful for that,
  especially when trying to debug user problems.
 
  I don't mind switching to tracepoints as long as this functionality is
  kept one way or another.
  
  I agree with Sylwester: we should move to tracepoints, and this is a good
  start.
 
 As I mentioned, I don't mind switching to tracepoints, but not in the way the
 current patch does it. I certainly don't agree with you merging this patch
 as-is without further discussion.

Let's not mix the subjects here. There are two different demands that can be
either fulfilled by the same solution or by different ones:
1) To have a way to enable debugging all parameters passed from/to
userspace;
2) To be able to measure the driver (and core) performance while
streaming.

This patch's scope is to solve (2), by allowing userspace to hook the two
ioctls that queues/dequeues streaming buffers.

With that regards, what's wrong on this patch? I couldn't see anything bad
there. It is not meant to solve (1).

Before this patch, all we have is (1), as a non-dynamic printk is too
intrusive to be used for performance measurement. So, there's no way to
measure how much time a buffer takes to be filled.

In a matter of fact, in the case you didn't noticed, we are already somewhat
moving to traces, as several drivers are now using dynamic_printk for debug 
messages, Yet, lots of drivers still use either their own normal
printk-based debug macros.

Now, you're proposing to use the same solution for (1) too. 

Ok, we can go on that direction, but this is a separate issue. Converting
the v4l2-ioctl to use tracepoints is the easiest part. However, there are
several things to consider, if we decide to use it for debug purposes:

a) It will likely require to convert all printks to dynamic ones, as we
want to have all debug messages serialized.

Let me explain it better: if some debug messages come via the standard 
printk mechanism while others come via traces, we loose the capability
of receiving the messages at the same order that they were produced, and
it could be harder if not impossible to synchronize them into the right
order.

b) It may make sense to write an userspace tool similar to the rasdaemon
[1] to allow controlling the debug output. That tool directly reads the
events from the raw tracing queues, formatting the data on userspace and
hooking only the events that are needed. 

Currently, the rasdaemon has inside part of the code used by a perf
tool copied on it (as this code is not inside any library yet). However,
that code is being prepared to be used as a library. So, it should be
even easier to write such tool in a near future.

[1] https://git.fedorahosted.org/cgit/rasdaemon.git/

c) I don't think that tracepoints are the right mechanism for a post-mortem
analysis[2]. E. g. if the Kernel crashes, a printk-based mechanism will 
output something, but I'm not sure if doing the same is possible with traces
(e. g. forcing the trace messages to go to to tty).

You should notice that, with the dynamic_printk macros, it is possible to
compile the Kernel to use normal printk macros for debug macros.

However, if we convert the ioctl printk's to tracepoints, we may still
need to have a fallback printk mechanism for ioctl debug

[GIT PULL for v3.13-rc4] media fixes

2013-12-11 Thread Mauro Carvalho Chehab

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Linus,

Please pull from:
  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

For a dvb core deadlock fix, a couple videobuf2 fixes an a series of media
driver fixes.

Thank you!
Mauro

The following changes since commit 6ce4eac1f600b34f2f7f58f9cd8f0503d79e42ae:

  Linux 3.13-rc1 (2013-11-22 11:30:55 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media 
v4l_for_linus

for you to fetch changes up to 64c832a4f79542809d6c10b8ec6225ff8b76092e:

  [media] videobuf2-dma-sg: fix possible memory leak (2013-12-10 05:40:57 -0200)

- 
Alexey Khoroshilov (1):
  [media] dvb_demux: fix deadlock in dmx_section_feed_release_filter()

Antti Palosaari (4):
  [media] af9035: add [0413:6a05] Leadtek WinFast DTV Dongle Dual
  [media] af9035: fix broken I2C and USB I/O
  [media] af9033: fix broken I2C
  [media] rtl2830: add parent for I2C adapter

Dan Carpenter (2):
  [media] cx231xx: use after free on error path in probe
  [media] af9035: unlock on error in af9035_i2c_master_xfer()

Evgeny Plehov (1):
  [media] cxd2820r_c: fix if_ctl calculation

Felipe Pena (1):
  [media] technisat-usb2: fix typo in variable name

Geert Uytterhoeven (1):
  [media] radio-shark: Mark shark_resume_leds() inline to kill compiler 
warning

Georg Kaindl (1):
  [media] usbtv: Add support for PAL video source

Geyslan G. Bem (1):
  [media] videobuf2-dma-sg: fix possible memory leak

Hans Verkuil (4):
  [media] bttv: don't setup the controls if there are no video devices
  [media] tef6862/radio-tea5764: actually assign clamp result
  [media] wm8775: fix broken audio routing
  [media] vb2: regression fix: always set length field.

Hans de Goede (2):
  [media] gspca_sunplus: Add new usb-id for 06d6:0041
  [media] radio-shark2: Mark shark_resume_leds() inline to kill compiler 
warning

Jonathan McCrohan (1):
  [media] media_tree: Fix spelling errors

Laurent Pinchart (1):
  [media] v4l: omap3isp: Don't check for missing get_fmt op on remote subdev

Libin Yang (2):
  [media] marvell-ccic: drop resource free in driver remove
  [media] media: marvell-ccic: use devm to release clk

Michael Krufky (1):
  [media] dvb_demux: clean up whitespace in comments from previous patch 
(trivial)

Ondrej Zary (1):
  [media] gspca-stk1135: Add delay after configuring clock

Philipp Zabel (1):
  [media] videobuf2: Add support for file access mode flags for DMABUF 
exporting

Ricardo Ribalda (2):
  [media] em28xx-video: Swap release order to avoid lock nesting
  [media] ths7303: Declare as static a private function

Sachin Kamat (1):
  [media] mt9p031: Include linux/of.h header

Wei Yongjun (2):
  [media] v4l: vsp1: Fix error return code in vsp1_video_init()
  [media] saa7164: fix return value check in saa7164_initdev()

 Documentation/DocBook/media/v4l/vidioc-expbuf.xml |   8 +-
 drivers/media/common/siano/smscoreapi.h   |   4 +-
 drivers/media/common/siano/smsdvb.h   |   2 +-
 drivers/media/dvb-core/dvb_demux.c|   9 +-
 drivers/media/dvb-frontends/af9033.c  |  12 +-
 drivers/media/dvb-frontends/cxd2820r_c.c  |   2 +-
 drivers/media/dvb-frontends/dib8000.c |   4 +-
 drivers/media/dvb-frontends/drxk_hard.c   |  18 +--
 drivers/media/dvb-frontends/rtl2830.c |   1 +
 drivers/media/i2c/adv7183_regs.h  |   6 +-
 drivers/media/i2c/adv7604.c   |   2 +-
 drivers/media/i2c/adv7842.c   |   2 +-
 drivers/media/i2c/ir-kbd-i2c.c|   2 +-
 drivers/media/i2c/m5mols/m5mols_controls.c|   2 +-
 drivers/media/i2c/mt9p031.c   |   1 +
 drivers/media/i2c/s5c73m3/s5c73m3-core.c  |   2 +-
 drivers/media/i2c/s5c73m3/s5c73m3.h   |   2 +-
 drivers/media/i2c/saa7115.c   |   2 +-
 drivers/media/i2c/soc_camera/ov5642.c |   2 +-
 drivers/media/i2c/ths7303.c   |   3 +-
 drivers/media/i2c/wm8775.c|   4 +-
 drivers/media/pci/bt8xx/bttv-driver.c |   3 +-
 drivers/media/pci/cx18/cx18-driver.h  |   2 +-
 drivers/media/pci/cx23885/cx23885-417.c   |   2 +-
 drivers/media/pci/pluto2/pluto2.c |   2 +-
 drivers/media/pci/saa7164/saa7164-core.c  |   4 +-
 drivers/media/platform/coda.c |   2 +-
 drivers/media/platform/exynos4-is/fimc-core.c |   2 +-
 drivers/media/platform/exynos4-is/media-dev.c |   2 +-
 drivers/media/platform/marvell-ccic/mmp-driver.c  |  46 +-
 drivers/media/platform/omap3isp/isp.c |   2 +-
 drivers/media/platform/omap3isp/ispvideo.c|   7 +-
 drivers/media/platform/s5p-mfc/regs-mfc.h

Re: [PATCH] v4l2-dev: Add tracepoints for QBUF and DQBUF

2013-12-11 Thread Hans Verkuil

Hi Mauro,

On 12/11/13 11:44, Mauro Carvalho Chehab wrote:
 Hans,
 
 Em Wed, 11 Dec 2013 08:29:58 +0100
 Hans Verkuil hverk...@xs4all.nl escreveu:
 
 On 12/10/2013 09:53 PM, Mauro Carvalho Chehab wrote:
 Em Sat, 23 Nov 2013 17:54:48 +0100
 Hans Verkuil hverk...@xs4all.nl escreveu:

 On 11/23/2013 05:30 PM, Sylwester Nawrocki wrote:
 Hi,

 On 11/23/2013 12:25 PM, Hans Verkuil wrote:
 Hi Wade,

 On 11/22/2013 08:48 PM, Wade Farnsworth wrote:
 Add tracepoints to the QBUF and DQBUF ioctls to enable rudimentary
 performance measurements using standard kernel tracers.

 Signed-off-by: Wade Farnsworthwade_farnswo...@mentor.com
 ---

 This is the update to the RFC patch I posted a few weeks back.  I've 
 added
 several bits of metadata to the tracepoint output per Mauro's 
 suggestion.

 I don't like this. All v4l2 ioctls can already be traced by doing e.g.
 echo 1 (or echo 2)/sys/class/video4linux/video0/debug.

 So this code basically duplicates that functionality. It would be nice 
 to be able
 to tie in the existing tracing code (v4l2-ioctl.c) into tracepoints.

 I think it would be really nice to have this kind of support for standard
 traces at the v4l2 subsystem. Presumably it could even gradually replace
 the v4l2 custom debug infrastructure.

 If I understand things correctly, the current tracing/profiling 
 infrastructure
 is much less invasive than inserting printks all over, which may cause 
 changes
 in control flow. I doubt the system could be reliably profiled by 
 enabling all
 those debug prints.

 So my vote would be to add support for standard tracers, like in other
 subsystems in the kernel.

 The reason for the current system is to trace which ioctls are called in
 what order by a misbehaving application. It's very useful for that,
 especially when trying to debug user problems.

 I don't mind switching to tracepoints as long as this functionality is
 kept one way or another.

 I agree with Sylwester: we should move to tracepoints, and this is a good
 start.

 As I mentioned, I don't mind switching to tracepoints, but not in the way the
 current patch does it. I certainly don't agree with you merging this patch
 as-is without further discussion.
 
 Let's not mix the subjects here. There are two different demands that can be
 either fulfilled by the same solution or by different ones:
   1) To have a way to enable debugging all parameters passed from/to
 userspace;
   2) To be able to measure the driver (and core) performance while
 streaming.
 
 This patch's scope is to solve (2), by allowing userspace to hook the two
 ioctls that queues/dequeues streaming buffers.
 
 With that regards, what's wrong on this patch? I couldn't see anything bad
 there. It is not meant to solve (1).

I have two problems with it: 

1) Right now it is just checking for two ioctls, but as soon as we add more
tracepoints you get another switch on the ioctl command, something I've tried
to avoid by creating the table. So a table-oriented implementation would be
much preferred.

2) It duplicates the already existing code to dump the v4l2_buffer struct.
Is there a way to have just one copy of that? I was hoping Wade could look
into that, and if not, then it is something I can explore (although finding
time is an issue).

Bottom line as far as I am concerned: it was merged while I have outstanding
questions.

If there are good technical reasons why the two problems stated above can't
be easily resolved, then I will reconsider, but for now I think it is too early
to merge. For the record, I don't think I mentioned the first problem in my
original reply, it's something I noticed yesterday while looking at the patch
again.

 
 Before this patch, all we have is (1), as a non-dynamic printk is too
 intrusive to be used for performance measurement. So, there's no way to
 measure how much time a buffer takes to be filled.

Having tracepoints here doesn't tell you anything about that. At best it gives
you information about the jitter.

How are these tracepoints supposed to be used? What information will they
provide? Are tracepoints expected to be limited to QBUF/DQBUF? Or other
ioctls/fops as well? If so, which ones?

I just have too many questions and I'd like to see some answers before something
like this is merged in the v4l2 core.

Rereading my older replies I see that I wasn't particularly clear about what
my objections to the patch were, for which I apologies.

Nevertheless, I stand by my opinion that this patch needs more discussion.

Wade, I appreciate it if you can give some more insights into how you are
using this and what it gives you.

 In a matter of fact, in the case you didn't noticed, we are already somewhat
 moving to traces, as several drivers are now using dynamic_printk for debug 
 messages, Yet, lots of drivers still use either their own normal
 printk-based debug macros.
 
 Now, you're proposing to use the same solution for (1) too. 
 
 Ok, we can go on that direction, but this is a separate

41 matches

Mail list logo