date:20140113

Avoid circular mutex lock by pushing the dev->lock to the .fini
callback on each extension.

As em28xx-dvb, em28xx-alsa and em28xx-rc have their own data
structures, and don't touch at the common structure during .fini,
only em28xx-v4l needs to be locked.

[   90.994317] ==
[   90.994356] [ INFO: possible circular locking dependency detected ]
[   90.994395] 3.13.0-rc1+ #24 Not tainted
[   90.994427] ---
[   90.994458] khubd/54 is trying to acquire lock:
[   90.994490]  (&card->controls_rwsem){.+}, at: [] 
snd_ctl_dev_free+0x28/0x60 [snd]
[   90.994656]
[   90.994656] but task is already holding lock:
[   90.994688]  (&dev->lock){+.+.+.}, at: [] 
em28xx_close_extension+0x31/0x90 [em28xx]
[   90.994843]
[   90.994843] which lock already depends on the new lock.
[   90.994843]
[   90.994874]
[   90.994874] the existing dependency chain (in reverse order) is:
[   90.994905]
-> #1 (&dev->lock){+.+.+.}:
[   90.995057][] __lock_acquire+0xb43/0x1330
[   90.995121][] lock_acquire+0xa2/0x120
[   90.995182][] mutex_lock_nested+0x5c/0x3c0
[   90.995245][] em28xx_vol_put_mute+0x1ba/0x1d0 
[em28xx_alsa]
[   90.995309][] snd_ctl_elem_write+0xfd/0x140 [snd]
[   90.995376][] snd_ctl_ioctl+0xe2/0x810 [snd]
[   90.995442][] do_vfs_ioctl+0x300/0x520
[   90.995504][] SyS_ioctl+0x81/0xa0
[   90.995568][] system_call_fastpath+0x16/0x1b
[   90.995630]
-> #0 (&card->controls_rwsem){.+}:
[   90.995780][] check_prevs_add+0x947/0x950
[   90.995841][] __lock_acquire+0xb43/0x1330
[   90.995901][] lock_acquire+0xa2/0x120
[   90.995962][] down_write+0x3b/0xa0
[   90.996022][] snd_ctl_dev_free+0x28/0x60 [snd]
[   90.996088][] snd_device_free+0x65/0x140 [snd]
[   90.996154][] snd_device_free_all+0x61/0xa0 [snd]
[   90.996219][] snd_card_do_free+0x14/0x130 [snd]
[   90.996283][] snd_card_free+0x84/0x90 [snd]
[   90.996349][] em28xx_audio_fini+0x97/0xb0 
[em28xx_alsa]
[   90.996411][] em28xx_close_extension+0x56/0x90 
[em28xx]
[   90.996475][] em28xx_usb_disconnect+0x79/0x90 
[em28xx]
[   90.996539][] usb_unbind_interface+0x67/0x1d0
[   90.996620][] __device_release_driver+0x7f/0xf0
[   90.996682][] device_release_driver+0x25/0x40
[   90.996742][] bus_remove_device+0x11c/0x1a0
[   90.996801][] device_del+0x136/0x1d0
[   90.996863][] usb_disable_device+0xb0/0x290
[   90.996923][] usb_disconnect+0xb5/0x1d0
[   90.996984][] hub_port_connect_change+0xd6/0xad0
[   90.997044][] hub_events+0x313/0x9b0
[   90.997105][] hub_thread+0x35/0x170
[   90.997165][] kthread+0xff/0x120
[   90.997226][] ret_from_fork+0x7c/0xb0
[   90.997287]
[   90.997287] other info that might help us debug this:
[   90.997287]
[   90.997318]  Possible unsafe locking scenario:
[   90.997318]
[   90.997348]CPU0CPU1
[   90.997378]
[   90.997408]   lock(&dev->lock);
[   90.997497]lock(&card->controls_rwsem);
[   90.997607]lock(&dev->lock);
[   90.997697]   lock(&card->controls_rwsem);
[   90.997786]
[   90.997786]  *** DEADLOCK ***
[   90.997786]
[   90.997817] 5 locks held by khubd/54:
[   90.997847]  #0:  (&__lockdep_no_validate__){..}, at: 
[] hub_events+0xb4/0x9b0
[   90.998025]  #1:  (&__lockdep_no_validate__){..}, at: 
[] usb_disconnect+0x66/0x1d0
[   90.998204]  #2:  (&__lockdep_no_validate__){..}, at: 
[] device_release_driver+0x1d/0x40
[   90.998383]  #3:  (em28xx_devlist_mutex){+.+.+.}, at: [] 
em28xx_close_extension+0x27/0x90 [em28xx]
[   90.998567]  #4:  (&dev->lock){+.+.+.}, at: [] 
em28xx_close_extension+0x31/0x90 [em28xx]

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-core.c  | 2 --
 drivers/media/usb/em28xx/em28xx-video.c | 4 
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
b/drivers/media/usb/em28xx/em28xx-core.c
index b6dc3327c51c..898fb9bd88a2 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -1099,12 +1099,10 @@ void em28xx_close_extension(struct em28xx *dev)
const struct em28xx_ops *ops = NULL;
 
mutex_lock(&em28xx_devlist_mutex);
-   mutex_lock(&dev->lock);
list_for_each_entry(ops, &em28xx_extension_devlist, next) {
if (ops->fini)
ops->fini(dev);
}
-   mutex_unlock(&dev->lock);
list_del(&dev->devlist);
mutex_unlock(&em28xx_devlist_mutex);
 }
diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
b/drivers/media/usb/em28xx/em28xx-video.c
index 004fe12ceec7..258628877951 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c

Re: [PATCH v4 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table

Hi Marek, Ricardo,

On 01/08/2014 03:07 PM, Marek Szyprowski wrote:
> Hello All,
> 
> On 2014-01-03 16:51, Ricardo Ribalda Delgado wrote:
>> Hello Hans
>>
>> What if we move the dma_map_sg and dma_unmap_sg to the vb2 interface,
>> and there do something like:
>>
>> n_sg= dma_map_sg()
>> if (n_sg=-ENOMEM){
>> split_table() //Breaks down the sg_table into monopages sg
>> n_sg= dma_map_sg()

This is not a good approach. Remember that if swiotbl needs to allocate
e.g. 17 contiguous pages it will round up to the next power of two, so it
allocates 32 pages. So even if dma_map_sg succeeds, it might waste a lot
of memory.

>> }
>> if (n_sg=-ENOMEM)
>>return -ENOMEM
> 
> dma_map_sg/dma_unmap_sg should be moved to vb2-dma-sg memory allocator. 
> The best place for calling them is buf_prepare() and buf_finish() 
> callbacks. I think that I've already pointed this some time ago, but 
> unfortunately I didn't find enough time to convert existing code.

That would be nice, but this is a separate issue.

> For solving the problem described by Hans, I think that vb2-dma-sg 
> memory allocator should check dma mask of the client device and add 
> appropriate GFP_DMA or GFP_DMA32 flags to alloc_pages(). This should fix 
> the issues with failed dma_map_sg due to lack of bouncing buffers.

Those GFP flags are for the scatterlist itself, and that can be placed
anywhere in memory (frankly, I'm not sure why sg_alloc_table_from_pages
has a gfp_flags argument at all and I think it is used incorrectly in
videobuf2-dma-sg.c as well).

I see two options. The first is the patch I included below: this adds a
bool to sg_alloc_table_from_pages() that tells it whether or not page
combining should be enabled. It also adds the vb2 queue's gfp_flags as
an argument to the get_userptr operation. In videobuf2-dma-sg.c that is
checked to see whether or not sg_alloc_table_from_pages() should enable
page-combining.

The alternative would be to have vb2_queue_init check if the use of
V4L2_MEMORY_USERPTR would lead to dma bouncing based on the q->io_modes
and q->gfp_flags and if so, remove USERPTR support from io_modes. Do
we really want to have page bouncing for video capture?

Feedback would be welcome as I am not sure what the best solution is.

Regards,

Hans

PS: for a final version this patch would be split up in 2 or 3 patches.

Signed-off-by: Hans Verkuil 

diff --git a/arch/arm/mm/dma-mapping.c b/arch/arm/mm/dma-mapping.c
index 79f8b39..404716f 100644
--- a/arch/arm/mm/dma-mapping.c
+++ b/arch/arm/mm/dma-mapping.c
@@ -1468,7 +1468,7 @@ static int arm_iommu_get_sgtable(struct device *dev, 
struct sg_table *sgt,
return -ENXIO;

return sg_alloc_table_from_pages(sgt, pages, count, 0, size,
-GFP_KERNEL);
+true, GFP_KERNEL);
 }

 static int __dma_direction_to_prot(enum dma_data_direction dir)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c3..4c56338 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -617,7 +617,7 @@ struct sg_table *drm_prime_pages_to_sg(struct page **pages, 
int nr_pages)
}

ret = sg_alloc_table_from_pages(sg, pages, nr_pages, 0,
-   nr_pages << PAGE_SHIFT, GFP_KERNEL);
+   nr_pages << PAGE_SHIFT, true, GFP_KERNEL);
if (ret)
goto out;

diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
index 7bccedc..0236f9b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
@@ -505,7 +505,7 @@ static dma_addr_t *g2d_userptr_get_dma_addr(struct 
drm_device *drm_dev,
}

ret = sg_alloc_table_from_pages(sgt, pages, npages, offset,
-   size, GFP_KERNEL);
+   size, true, GFP_KERNEL);
if (ret < 0) {
DRM_ERROR("failed to get sgt from pages.\n");
goto err_free_sgt;
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
index 7776e6f..7ee560c 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c
@@ -348,6 +348,7 @@ static int vmw_ttm_map_dma(struct vmw_ttm_tt *vmw_tt)
vsgt->num_pages, 0,
(unsigned long)
vsgt->num_pages << PAGE_SHIFT,
+   true,
GFP_KERNEL);
if (unlikely(ret != 0))
goto out_sg_alloc_fail;
diff --git a/drivers/media/v4l2-core/videobuf2-core.c 
b/drivers/media/v4l2-core/videobuf2-core.c
index c203b9c..9dd2149 100644
--- a/drivers/media/v4l2-core/videobuf2-core.c
+++ b/drivers/media/v4l2-cor

[PATCH] solo6x10: fix broken PAL support.

The video_type was never set correctly for PAL: it's not a bool, instead
it is a register value.

Signed-off-by: Hans Verkuil 
Tested-by: Hans Verkuil 
Reported-by: tom...@freenet.de
---
 drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c | 2 +-
 drivers/staging/media/solo6x10/solo6x10-v4l2.c | 7 ---
 drivers/staging/media/solo6x10/solo6x10.h  | 2 +-
 3 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c 
b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
index e86c96a..bb59750 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2-enc.c
@@ -966,7 +966,7 @@ static int solo_enc_s_std(struct file *file, void *priv, 
v4l2_std_id std)
 {
struct solo_enc_dev *solo_enc = video_drvdata(file);
 
-   return solo_set_video_type(solo_enc->solo_dev, std & V4L2_STD_PAL);
+   return solo_set_video_type(solo_enc->solo_dev, std & V4L2_STD_625_50);
 }
 
 static int solo_enum_framesizes(struct file *file, void *priv,
diff --git a/drivers/staging/media/solo6x10/solo6x10-v4l2.c 
b/drivers/staging/media/solo6x10/solo6x10-v4l2.c
index 7b26de3..47e72da 100644
--- a/drivers/staging/media/solo6x10/solo6x10-v4l2.c
+++ b/drivers/staging/media/solo6x10/solo6x10-v4l2.c
@@ -527,7 +527,7 @@ static int solo_g_std(struct file *file, void *priv, 
v4l2_std_id *i)
return 0;
 }
 
-int solo_set_video_type(struct solo_dev *solo_dev, bool type)
+int solo_set_video_type(struct solo_dev *solo_dev, bool is_50hz)
 {
int i;
 
@@ -537,7 +537,8 @@ int solo_set_video_type(struct solo_dev *solo_dev, bool 
type)
for (i = 0; i < solo_dev->nr_chans; i++)
if (vb2_is_busy(&solo_dev->v4l2_enc[i]->vidq))
return -EBUSY;
-   solo_dev->video_type = type;
+   solo_dev->video_type = is_50hz ? SOLO_VO_FMT_TYPE_PAL :
+SOLO_VO_FMT_TYPE_NTSC;
/* Reconfigure for the new standard */
solo_disp_init(solo_dev);
solo_enc_init(solo_dev);
@@ -551,7 +552,7 @@ static int solo_s_std(struct file *file, void *priv, 
v4l2_std_id std)
 {
struct solo_dev *solo_dev = video_drvdata(file);
 
-   return solo_set_video_type(solo_dev, std & V4L2_STD_PAL);
+   return solo_set_video_type(solo_dev, std & V4L2_STD_625_50);
 }
 
 static int solo_s_ctrl(struct v4l2_ctrl *ctrl)
diff --git a/drivers/staging/media/solo6x10/solo6x10.h 
b/drivers/staging/media/solo6x10/solo6x10.h
index f1bbb8c..8964f8b 100644
--- a/drivers/staging/media/solo6x10/solo6x10.h
+++ b/drivers/staging/media/solo6x10/solo6x10.h
@@ -398,7 +398,7 @@ int solo_p2m_dma_desc(struct solo_dev *solo_dev,
  int desc_cnt);
 
 /* Global s_std ioctl */
-int solo_set_video_type(struct solo_dev *solo_dev, bool type);
+int solo_set_video_type(struct solo_dev *solo_dev, bool is_50hz);
 void solo_update_mode(struct solo_enc_dev *solo_enc);
 
 /* Set the threshold for motion detection */
-- 
1.8.5.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

[GIT PULL FOR v3.14] Various fixes

The following changes since commit d20e4ed6d30c6ecee315eea0efb3449c3591d09e:



  [media] em28xx: use a better value for I2C timeouts (2014-01-10 06:10:07 
-0200)   


are available in the git repository at: 



  git://linuxtv.org/hverkuil/media_tree.git for-v3.14c  



for you to fetch changes up to 190a7f631e1f972912d1777aadbaa6854be00085:


  vb2: Check if there are buffers before streamon (2014-01-10 16:09:53 +0100)


Alexey Khoroshilov (1):
  go7007-loader: fix usb_dev leak

Hans Verkuil (1):
  Revert "[media] videobuf_vm_{open,close} race fixes"

Levente Kurusa (1):
  media: bt8xx: add missing put_device call

Ricardo Ribalda (1):
  vb2: Check if there are buffers before streamon

 drivers/media/pci/bt8xx/bttv-gpio.c   |  2 +-
 drivers/media/v4l2-core/videobuf-dma-contig.c | 12 +---
 drivers/media/v4l2-core/videobuf-dma-sg.c | 10 --
 drivers/media/v4l2-core/videobuf-vmalloc.c| 10 --
 drivers/media/v4l2-core/videobuf2-core.c  |  5 +
 drivers/staging/media/go7007/go7007-loader.c  |  4 +++-
 6 files changed, 22 insertions(+), 21 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] em28xx: adjust period size at runtime

While the current hardcoded period is ok for the current values,
we may latter change the driver to work with different bit rates
or with different latencies than 64ms.

So, adust the period size at runtime.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/usb/em28xx/em28xx-audio.c | 8 
 drivers/media/usb/em28xx/em28xx.h   | 2 ++
 2 files changed, 10 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 0ec4742c3ab0..1fe85f45924e 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -293,7 +293,12 @@ static int snd_em28xx_capture_open(struct 
snd_pcm_substream *substream)
mutex_unlock(&dev->lock);
}
 
+   /* Dynamically adjust the period size */
snd_pcm_hw_constraint_integer(runtime, SNDRV_PCM_HW_PARAM_PERIODS);
+   snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
+dev->adev.period * 95 / 100,
+dev->adev.period * 105 / 100);
+
dev->adev.capture_pcm_substream = substream;
 
return 0;
@@ -807,6 +812,9 @@ static int em28xx_audio_urb_init(struct em28xx *dev)
em28xx_info("Number of URBs: %d, with %d packets and %d size",
num_urb, npackets, urb_size);
 
+   /* Estimate the bytes per period */
+   dev->adev.period = urb_size * npackets;
+
/* Allocate space to store the number of URBs to be used */
 
dev->adev.transfer_buffer = kcalloc(num_urb,
diff --git a/drivers/media/usb/em28xx/em28xx.h 
b/drivers/media/usb/em28xx/em28xx.h
index d38c08e4da60..8b3438891bb3 100644
--- a/drivers/media/usb/em28xx/em28xx.h
+++ b/drivers/media/usb/em28xx/em28xx.h
@@ -506,6 +506,8 @@ struct em28xx_audio {
unsigned int hwptr_done_capture;
struct snd_card*sndcard;
 
+   size_t period;
+
int users;
spinlock_t slock;
 };
-- 
1.8.3.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: using MFC memory to memery encoder, start stream and queue order problem

2014-01-13 Thread Andrzej Hajda

On 01/10/2014 04:23 PM, randy wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> 于 2014年01月10日 19:13, Andrzej Hajda 写道:
>> Hi Randy,
>>
>> On 01/10/2014 10:15 AM, randy wrote:
>>
>> 
>>
 It won't work, if I do that, after step 7, neither OUPUT nor 
 CAPTURE will poll return in my program. but ./mfc-encode -m 
 /dev/video1 -c h264,header_mode=1 work normally,
>>> I am sorry, I didn't well test it, if I use ./mfc-encode -m 
>>> /dev/video1 -c h264,header_mode=1 -d 1 then the size of demo.out
>>> is zero, but ./mfc-encode -d 1 -m /dev/video1 -c h264 will out a
>>> 158 bytes files. When duration is 2, with header_mode=1, the
>>> output file size is 228 bytes.Without it, the size is 228 too. I
>>> wonder whether it is the driver's problem, as I see this in
>>> dmesg [0.21] Failed to declare coherent memory for MFC
>>> device (0 bytes at 0x4300) As the driver is not ready to use
>>> in 3.13-rc6 as I reported before, I still use the 3.5 from
>>> manufacturer.
>>
>> I am the author of mfc-encode application, it was written for the 
>> mainline kernel 3.8 and later, it should be mentioned in the
>> README.txt - I will update it.
> Sadness, I have tested 3.10.26, in this version, neither decoder nor
> encoder can be work(can't init according to clock problem).
> In 3.8, it doesn't have dts support fully and lack many drivers.
> I think I shall wait the the mfc done for 3.13.
>> App will not work correctly with earlier kernels, mainly (but not
>> only) due to lack of end of stream handling in MFC encoder driver. 
>> If you use vendor kernel I suggest to look at the vendor's capture 
>> apps/libs to check how it uses MFC driver.
>>
> Sadness, they doesn't offer any of them, even not any information
> about it.
> And I can't compile the openmax from samsung. I will report it later
> in sourceforge.
>> Regards Andrzej

You can then try to backport EOS handling patch:
http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/52748

Regards
Andrzej

>>
>>
>>
>>
> 
> Thank you
> ayaka
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.12 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
> 
> iQEcBAEBAgAGBQJS0BCEAAoJEPb4VsMIzTziYJQH/RFX6oSL6JWb4ah/+SOlXT9m
> V+qoPGy2h+KB82+vC7l4UNpYUrDO+U13y8G9IerZp3F3i83qBrpIBNb4jr6M1b/u
> nm/g3U8RvJoTJkiL9iFFKNBuXZAtYYXFV1RgMtJJ/iXZavte3jOBIOeCpRZndh80
> b+ZmihGVPP9d66f/mMFJreFKUwP4UTOR/TuYgv1i106GRLmD2XAWFWTYBXygUeLE
> GCRst2D+t4lpTH8Ttz+ZdzXEINZaCgO5Jf1UvK3+nLXfQbJREH9BWmODDhR6M269
> hn2lcU0D1HwGnVzdEN/Gx/8gneixg3oWP2nZVJ61w5WlABYpWKKyNbZqsfwzGXM=
> =57or
> -END PGP SIGNATURE-
> 

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

[PATCH] drxk: remove the option to load firmware asynchronously

The option to load firmware asynchronously were added due to
a requirement with a few versions of udev. It turns that this was
a bad idea and caused regressions on drxk-based devices.

So, we end by only letting the firmware to be loaded syncronously
everywhere.

So, let's remove the bad code.

This patch partially reverts the changeset 8e30783b0b3.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/drxk.h  |  2 --
 drivers/media/dvb-frontends/drxk_hard.c | 24 ++--
 drivers/media/usb/em28xx/em28xx-dvb.c   |  5 -
 3 files changed, 6 insertions(+), 25 deletions(-)

diff --git a/drivers/media/dvb-frontends/drxk.h 
b/drivers/media/dvb-frontends/drxk.h
index f22eb9f13ad5..f6cb34660327 100644
--- a/drivers/media/dvb-frontends/drxk.h
+++ b/drivers/media/dvb-frontends/drxk.h
@@ -29,7 +29,6 @@
  * A value of 0 (default) or lower indicates that
  * the correct number of parameters will be
  * automatically detected.
- * @load_firmware_sync:Force the firmware load to be 
synchronous.
  *
  * On the *_gpio vars, bit 0 is UIO-1, bit 1 is UIO-2 and bit 2 is
  * UIO-3.
@@ -41,7 +40,6 @@ struct drxk_config {
boolparallel_ts;
booldynamic_clk;
boolenable_merr_cfg;
-   boolload_firmware_sync;
 
boolantenna_dvbt;
u16 antenna_gpio;
diff --git a/drivers/media/dvb-frontends/drxk_hard.c 
b/drivers/media/dvb-frontends/drxk_hard.c
index bf29a3f0e6f0..cce94a75b2e1 100644
--- a/drivers/media/dvb-frontends/drxk_hard.c
+++ b/drivers/media/dvb-frontends/drxk_hard.c
@@ -6830,25 +6830,13 @@ struct dvb_frontend *drxk_attach(const struct 
drxk_config *config,
 
/* Load firmware and initialize DRX-K */
if (state->microcode_name) {
-   if (config->load_firmware_sync) {
-   const struct firmware *fw = NULL;
+   const struct firmware *fw = NULL;
 
-   status = request_firmware(&fw, state->microcode_name,
- state->i2c->dev.parent);
-   if (status < 0)
-   fw = NULL;
-   load_firmware_cb(fw, state);
-   } else {
-   status = request_firmware_nowait(THIS_MODULE, 1,
- state->microcode_name,
- state->i2c->dev.parent,
- GFP_KERNEL,
- state, load_firmware_cb);
-   if (status < 0) {
-   pr_err("failed to request a firmware\n");
-   return NULL;
-   }
-   }
+   status = request_firmware(&fw, state->microcode_name,
+ state->i2c->dev.parent);
+   if (status < 0)
+   fw = NULL;
+   load_firmware_cb(fw, state);
} else if (init_drxk(state) < 0)
goto error;
 
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 7ba209de57dd..00a9611b5228 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -375,7 +375,6 @@ static struct drxk_config terratec_h5_drxk = {
.no_i2c_bridge = 1,
.microcode_name = "dvb-usb-terratec-h5-drxk.fw",
.qam_demod_parameter_count = 2,
-   .load_firmware_sync = true,
 };
 
 static struct drxk_config hauppauge_930c_drxk = {
@@ -385,7 +384,6 @@ static struct drxk_config hauppauge_930c_drxk = {
.microcode_name = "dvb-usb-hauppauge-hvr930c-drxk.fw",
.chunk_size = 56,
.qam_demod_parameter_count = 2,
-   .load_firmware_sync = true,
 };
 
 static struct drxk_config terratec_htc_stick_drxk = {
@@ -399,7 +397,6 @@ static struct drxk_config terratec_htc_stick_drxk = {
.antenna_dvbt = true,
/* The windows driver uses the same. This will disable LNA. */
.antenna_gpio = 0x6,
-   .load_firmware_sync = true,
 };
 
 static struct drxk_config maxmedia_ub425_tc_drxk = {
@@ -408,7 +405,6 @@ static struct drxk_config maxmedia_ub425_tc_drxk = {
.no_i2c_bridge = 1,
.microcode_name = "dvb-demod-drxk-01.fw",
.chunk_size = 62,
-   .load_firmware_sync = true,
.qam_demod_parameter_count = 2,
 };
 
@@ -420,7 +416,6 @@ static struct drxk_config pctv_520e_drxk = {
.chunk_size = 58,
.antenna_dvbt = true, /* disable LNA */
.antenna_gpio = (1 << 2), /* disable LNA */
-   .load_firmware_sync = true,
 };
 
 static int drxk_gate_ctrl(struct dvb_frontend *fe, int enable)
-- 
1.8.3.1

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

[PATCH] Update the link pointing the patch for porting the application to libv4l2

2014-01-13 Thread Prabhakar Lad

From: "Lad, Prabhakar" 

Signed-off-by: Lad, Prabhakar 
---
 README.libv4l |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/README.libv4l b/README.libv4l
index 0be503f..ffe6366 100644
--- a/README.libv4l
+++ b/README.libv4l
@@ -169,4 +169,4 @@ A: Just replace the open call for your device by v4l2_open 
and all
 Q: I still need an example how to convert my application!
 A: Check out the patches for the VLC media player:
https://trac.videolan.org/vlc/attachment/ticket/1804/vlc-0.8.6-libv4l1.patch
-   https://trac.videolan.org/vlc/attachment/ticket/1804/vlc-0.8.6-libv4l2.patch
+   https://trac.videolan.org/vlc/attachment/ticket/1804/vlc-0.9.3-libv4l2.patch
-- 
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

Re: Issue with 3.12.5/7 and CX23880/1/2/3 DVB Card

Em Sun, 12 Jan 2014 16:26:41 -0500
Rich Freeman  escreveu:

> I noticed that you authored commit
> 19496d61f3962fd6470b106b779eddcdbe823c9b, which replaced a dynamic
> buffer with a static one when sending data to the card.
> 
> This broke my ATI HD tuner, listed in lspci as:
> 04:07.0 Multimedia video controller: Conexant Systems, Inc.
> CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
> 04:07.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
> PCI Video and Audio Decoder [Audio Port] (rev 05)
> 04:07.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3
> PCI Video and Audio Decoder [MPEG Port] (rev 05)
> 
> (I'd have to rip the card out to actually get the model number - it
> has been ages since I bought it.)
> 
> The card fails to load firmware in 3.12.7 and will not record video.
> It loads with a warning in 3.12.5, and recording works.
> 
> The warnings in 3.12.5 are:
> Dec 20 10:52:04 rich kernel: [   31.747903] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747908] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747910] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747912] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747914] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747916] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747918] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747919] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747921] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747923] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747925] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747926] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747928] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747930] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747931] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747933] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747935] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747937] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747938] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747940] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747942] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747943] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747945] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747947] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747949] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747950] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747952] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747954] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747955] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747957] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747959] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747961] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747962] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747964] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747966] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=255 is too big!
> Dec 20 10:52:04 rich kernel: [   31.747967] nxt200x:
> nxt200x_writebytes: i2c wr reg=002c: len=25

Re: using MFC memory to memery encoder, start stream and queue order problem

2014-01-13 Thread Andrzej Hajda

On 01/13/2014 11:15 AM, Andrzej Hajda wrote:
> On 01/10/2014 04:23 PM, randy wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> 于 2014年01月10日 19:13, Andrzej Hajda 写道:
>>> Hi Randy,
>>>
>>> On 01/10/2014 10:15 AM, randy wrote:
>>>
>>> 
>>>
> It won't work, if I do that, after step 7, neither OUPUT nor 
> CAPTURE will poll return in my program. but ./mfc-encode -m 
> /dev/video1 -c h264,header_mode=1 work normally,
 I am sorry, I didn't well test it, if I use ./mfc-encode -m 
 /dev/video1 -c h264,header_mode=1 -d 1 then the size of demo.out
 is zero, but ./mfc-encode -d 1 -m /dev/video1 -c h264 will out a
 158 bytes files. When duration is 2, with header_mode=1, the
 output file size is 228 bytes.Without it, the size is 228 too. I
 wonder whether it is the driver's problem, as I see this in
 dmesg [0.21] Failed to declare coherent memory for MFC
 device (0 bytes at 0x4300) As the driver is not ready to use
 in 3.13-rc6 as I reported before, I still use the 3.5 from
 manufacturer.
>>>
>>> I am the author of mfc-encode application, it was written for the 
>>> mainline kernel 3.8 and later, it should be mentioned in the
>>> README.txt - I will update it.
>> Sadness, I have tested 3.10.26, in this version, neither decoder nor
>> encoder can be work(can't init according to clock problem).
>> In 3.8, it doesn't have dts support fully and lack many drivers.
>> I think I shall wait the the mfc done for 3.13.
>>> App will not work correctly with earlier kernels, mainly (but not
>>> only) due to lack of end of stream handling in MFC encoder driver. 
>>> If you use vendor kernel I suggest to look at the vendor's capture 
>>> apps/libs to check how it uses MFC driver.
>>>
>> Sadness, they doesn't offer any of them, even not any information
>> about it.
>> And I can't compile the openmax from samsung. I will report it later
>> in sourceforge.
>>> Regards Andrzej
> 
> You can then try to backport EOS handling patch:
> http://comments.gmane.org/gmane.linux.drivers.video-input-infrastructure/52748
> 
> Regards
> Andrzej
> 

I believe it is the best solution if you are interesting in fixing only
MFC encoding. If your goal is wider I suggest to try linux-next kernel.
There is basic(!) DT support for this board applied about month ago:
https://lkml.org/lkml/2013/12/18/285

Regards
Andrzej

>>>
>>>
>>>
>>>
>>
>> Thank you
>> ayaka
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.12 (GNU/Linux)
>> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>>
>> iQEcBAEBAgAGBQJS0BCEAAoJEPb4VsMIzTziYJQH/RFX6oSL6JWb4ah/+SOlXT9m
>> V+qoPGy2h+KB82+vC7l4UNpYUrDO+U13y8G9IerZp3F3i83qBrpIBNb4jr6M1b/u
>> nm/g3U8RvJoTJkiL9iFFKNBuXZAtYYXFV1RgMtJJ/iXZavte3jOBIOeCpRZndh80
>> b+ZmihGVPP9d66f/mMFJreFKUwP4UTOR/TuYgv1i106GRLmD2XAWFWTYBXygUeLE
>> GCRst2D+t4lpTH8Ttz+ZdzXEINZaCgO5Jf1UvK3+nLXfQbJREH9BWmODDhR6M269
>> hn2lcU0D1HwGnVzdEN/Gx/8gneixg3oWP2nZVJ61w5WlABYpWKKyNbZqsfwzGXM=
>> =57or
>> -END PGP SIGNATURE-
>>
> 

--
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: Issue with 3.12.5/7 and CX23880/1/2/3 DVB Card

2014-01-13 Thread Rich Freeman

On Mon, Jan 13, 2014 at 6:02 AM, Mauro Carvalho Chehab
 wrote:
> Em Sun, 12 Jan 2014 16:26:41 -0500
> Rich Freeman  escreveu:
>
>> I noticed that you authored commit
>> 19496d61f3962fd6470b106b779eddcdbe823c9b, which replaced a dynamic
>> buffer with a static one when sending data to the card.
>
> Can you please try the following patch?
>
> nxt200x: increase write buffer size

After applying your patch to 3.12.7 (from the git tag) the firmware
loads without any warnings, and the card operates normally.  I think
that did the trick.

Thanks for the prompt response!

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

[PATCH 3/7] seqno-fence: Hardware dma-buf implementation of fencing (v4)

This type of fence can be used with hardware synchronization for simple
hardware that can block execution until the condition
(dma_buf[offset] - value) >= 0 has been met.

A software fallback still has to be provided in case the fence is used
with a device that doesn't support this mechanism. It is useful to expose
this for graphics cards that have an op to support this.

Some cards like i915 can export those, but don't have an option to wait,
so they need the software fallback.

I extended the original patch by Rob Clark.

v1: Original
v2: Renamed from bikeshed to seqno, moved into dma-fence.c since
not much was left of the file. Lots of documentation added.
v3: Use fence_ops instead of custom callbacks. Moved to own file
to avoid circular dependency between dma-buf.h and fence.h
v4: Add spinlock pointer to seqno_fence_init

Signed-off-by: Maarten Lankhorst 
---
 Documentation/DocBook/device-drivers.tmpl |1 
 drivers/base/fence.c  |   50 +
 include/linux/seqno-fence.h   |  109 +
 3 files changed, 160 insertions(+)
 create mode 100644 include/linux/seqno-fence.h

diff --git a/Documentation/DocBook/device-drivers.tmpl 
b/Documentation/DocBook/device-drivers.tmpl
index 7a0c9ddb4818..8c85c20942c2 100644
--- a/Documentation/DocBook/device-drivers.tmpl
+++ b/Documentation/DocBook/device-drivers.tmpl
@@ -131,6 +131,7 @@ X!Edrivers/base/interface.c
 !Edrivers/base/dma-buf.c
 !Edrivers/base/fence.c
 !Iinclude/linux/fence.h
+!Iinclude/linux/seqno-fence.h
 !Edrivers/base/reservation.c
 !Iinclude/linux/reservation.h
 !Edrivers/base/dma-coherent.c
diff --git a/drivers/base/fence.c b/drivers/base/fence.c
index ac5f68020436..25bd5813aa90 100644
--- a/drivers/base/fence.c
+++ b/drivers/base/fence.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CREATE_TRACE_POINTS
 #include 
@@ -413,3 +414,52 @@ __fence_init(struct fence *fence, const struct fence_ops 
*ops,
trace_fence_init(fence);
 }
 EXPORT_SYMBOL(__fence_init);
+
+static const char *seqno_fence_get_driver_name(struct fence *fence) {
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->get_driver_name(fence);
+}
+
+static const char *seqno_fence_get_timeline_name(struct fence *fence) {
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->get_timeline_name(fence);
+}
+
+static bool seqno_enable_signaling(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->enable_signaling(fence);
+}
+
+static bool seqno_signaled(struct fence *fence)
+{
+   struct seqno_fence *seqno_fence = to_seqno_fence(fence);
+   return seqno_fence->ops->signaled && seqno_fence->ops->signaled(fence);
+}
+
+static void seqno_release(struct fence *fence)
+{
+   struct seqno_fence *f = to_seqno_fence(fence);
+
+   dma_buf_put(f->sync_buf);
+   if (f->ops->release)
+   f->ops->release(fence);
+   else
+   kfree(f);
+}
+
+static long seqno_wait(struct fence *fence, bool intr, signed long timeout)
+{
+   struct seqno_fence *f = to_seqno_fence(fence);
+   return f->ops->wait(fence, intr, timeout);
+}
+
+const struct fence_ops seqno_fence_ops = {
+   .get_driver_name = seqno_fence_get_driver_name,
+   .get_timeline_name = seqno_fence_get_timeline_name,
+   .enable_signaling = seqno_enable_signaling,
+   .signaled = seqno_signaled,
+   .wait = seqno_wait,
+   .release = seqno_release,
+};
+EXPORT_SYMBOL(seqno_fence_ops);
diff --git a/include/linux/seqno-fence.h b/include/linux/seqno-fence.h
new file mode 100644
index ..952f7909128c
--- /dev/null
+++ b/include/linux/seqno-fence.h
@@ -0,0 +1,109 @@
+/*
+ * seqno-fence, using a dma-buf to synchronize fencing
+ *
+ * Copyright (C) 2012 Texas Instruments
+ * Copyright (C) 2012 Canonical Ltd
+ * Authors:
+ * Rob Clark 
+ *   Maarten Lankhorst 
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License version 2 as published by
+ * the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+
+#ifndef __LINUX_SEQNO_FENCE_H
+#define __LINUX_SEQNO_FENCE_H
+
+#include 
+#include 
+
+struct seqno_fence {
+   struct fence base;
+
+   const struct fence_ops *ops;
+   struct dma_buf *sync_buf;
+   uint32_t seqno_ofs;
+};
+
+extern const struct fence_ops seqno_fence_ops;
+
+/**
+ * to_seqno_fence - cast a fence to a seqno_fence
+ * @fence: fence to ca

[PATCH 0/7] dma-buf synchronization patches

The following series implements fence and converts dma-buf and
android sync to use it. Patch 6 and 7 add support for polling
to dma-buf, blocking until all fences are signaled.

---

Maarten Lankhorst (7):
  sched: allow try_to_wake_up to be used internally outside of core.c
  fence: dma-buf cross-device synchronization (v16)
  seqno-fence: Hardware dma-buf implementation of fencing (v4)
  dma-buf: use reservation objects
  android: convert sync to fence api, v3
  reservation: add support for fences to enable cross-device synchronisation
  dma-buf: add poll support


 Documentation/DocBook/device-drivers.tmpl  |3 
 drivers/base/Kconfig   |9 
 drivers/base/Makefile  |2 
 drivers/base/dma-buf.c |  124 +++
 drivers/base/fence.c   |  465 
 drivers/gpu/drm/drm_prime.c|8 
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 
 drivers/gpu/drm/nouveau/nouveau_drm.c  |1 
 drivers/gpu/drm/nouveau/nouveau_gem.h  |1 
 drivers/gpu/drm/nouveau/nouveau_prime.c|7 
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |2 
 drivers/gpu/drm/radeon/radeon_drv.c|2 
 drivers/gpu/drm/radeon/radeon_prime.c  |8 
 drivers/gpu/drm/ttm/ttm_object.c   |2 
 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 
 drivers/staging/android/Kconfig|1 
 drivers/staging/android/Makefile   |2 
 drivers/staging/android/sw_sync.c  |4 
 drivers/staging/android/sync.c |  895 
 drivers/staging/android/sync.h |   85 +-
 drivers/staging/android/sync_debug.c   |  245 +++
 drivers/staging/android/trace/sync.h   |   12 
 include/drm/drmP.h |2 
 include/linux/dma-buf.h|   21 -
 include/linux/fence.h  |  329 +
 include/linux/reservation.h|   18 
 include/linux/seqno-fence.h|  109 +++
 include/linux/wait.h   |1 
 include/trace/events/fence.h   |  125 +++
 kernel/sched/core.c|2 
 31 files changed, 1825 insertions(+), 666 deletions(-)
 create mode 100644 drivers/base/fence.c
 create mode 100644 drivers/staging/android/sync_debug.c
 create mode 100644 include/linux/fence.h
 create mode 100644 include/linux/seqno-fence.h
 create mode 100644 include/trace/events/fence.h

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

[PATCH 1/7] sched: allow try_to_wake_up to be used internally outside of core.c

The kernel fence implementation doesn't use event queues, but needs
to perform the same wake up. The symbol is not exported, since the
fence implementation is not built as a module.

Signed-off-by: Maarten Lankhorst 
---
 include/linux/wait.h |1 +
 kernel/sched/core.c  |2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/wait.h b/include/linux/wait.h
index eaa00b10abaa..c54e3ef50134 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -12,6 +12,7 @@
 typedef struct __wait_queue wait_queue_t;
 typedef int (*wait_queue_func_t)(wait_queue_t *wait, unsigned mode, int flags, 
void *key);
 int default_wake_function(wait_queue_t *wait, unsigned mode, int flags, void 
*key);
+int try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags);
 
 struct __wait_queue {
unsigned intflags;
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index a88f4a485c5e..f41d317042dd 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
@@ -1578,7 +1578,7 @@ static void ttwu_queue(struct task_struct *p, int cpu)
  * Return: %true if @p was woken up, %false if it was already running.
  * or @state didn't match @p's state.
  */
-static int
+int
 try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
 {
unsigned long flags;

--
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 v4 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table

2014-01-13 Thread Marek Szyprowski

Hello,

On 2014-01-13 10:54, Hans Verkuil wrote:

Hi Marek, Ricardo,

On 01/08/2014 03:07 PM, Marek Szyprowski wrote:
> Hello All,
>
> On 2014-01-03 16:51, Ricardo Ribalda Delgado wrote:
>> Hello Hans
>>
>> What if we move the dma_map_sg and dma_unmap_sg to the vb2 interface,
>> and there do something like:
>>
>> n_sg= dma_map_sg()
>> if (n_sg=-ENOMEM){
>> split_table() //Breaks down the sg_table into monopages sg
>> n_sg= dma_map_sg()

This is not a good approach. Remember that if swiotbl needs to allocate
e.g. 17 contiguous pages it will round up to the next power of two, so it
allocates 32 pages. So even if dma_map_sg succeeds, it might waste a lot
of memory.

>> }
>> if (n_sg=-ENOMEM)
>>return -ENOMEM
>
> dma_map_sg/dma_unmap_sg should be moved to vb2-dma-sg memory allocator.
> The best place for calling them is buf_prepare() and buf_finish()
> callbacks. I think that I've already pointed this some time ago, but
> unfortunately I didn't find enough time to convert existing code.

That would be nice, but this is a separate issue.

> For solving the problem described by Hans, I think that vb2-dma-sg
> memory allocator should check dma mask of the client device and add
> appropriate GFP_DMA or GFP_DMA32 flags to alloc_pages(). This should fix
> the issues with failed dma_map_sg due to lack of bouncing buffers.

Those GFP flags are for the scatterlist itself, and that can be placed
anywhere in memory (frankly, I'm not sure why sg_alloc_table_from_pages
has a gfp_flags argument at all and I think it is used incorrectly in
videobuf2-dma-sg.c as well).

I was talking about GFP flags passed to alloc_pages in vb2_dma_sg allocator,
not the sg_alloc_table_from_pages().

IMHO the following changes should fix your problem:

1. add client struct device pointer to vb2_dma_sg_desc, so vb2_dma_sg
allocator will be able to check dma parameters of the client device.

2. add following check to vb2_dma_sg_alloc_compacted():

if (dev->dma_mask) {
if (dev->dma_mask < DMA_BIT_MASK(32))
gfp_mask |= GFP_DMA;
else if (dev->dev_mask == DMA_BIT_MASK(32)
gfp_mask |= GFP_DMA32;
}

I see two options. The first is the patch I included below: this adds a
bool to sg_alloc_table_from_pages() that tells it whether or not page
combining should be enabled. It also adds the vb2 queue's gfp_flags as
an argument to the get_userptr operation. In videobuf2-dma-sg.c that is
checked to see whether or not sg_alloc_table_from_pages() should enable
page-combining.

The alternative would be to have vb2_queue_init check if the use of
V4L2_MEMORY_USERPTR would lead to dma bouncing based on the q->io_modes
and q->gfp_flags and if so, remove USERPTR support from io_modes. Do
we really want to have page bouncing for video capture?

So the main problem is about user ptr modes? This once again shows that
the current user pointer API is too limited and should be replaced by
something more reliable.

Feedback would be welcome as I am not sure what the best solution is.

Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland

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

[PATCH 2/7] fence: dma-buf cross-device synchronization (v16)

A fence can be attached to a buffer which is being filled or consumed
by hw, to allow userspace to pass the buffer without waiting to another
device.  For example, userspace can call page_flip ioctl to display the
next frame of graphics after kicking the GPU but while the GPU is still
rendering.  The display device sharing the buffer with the GPU would
attach a callback to get notified when the GPU's rendering-complete IRQ
fires, to update the scan-out address of the display, without having to
wake up userspace.

A driver must allocate a fence context for each execution ring that can
run in parallel. The function for this takes an argument with how many
contexts to allocate:
  + fence_context_alloc()

A fence is transient, one-shot deal.  It is allocated and attached
to one or more dma-buf's.  When the one that attached it is done, with
the pending operation, it can signal the fence:
  + fence_signal()

To have a rough approximation whether a fence is fired, call:
  + fence_is_signaled()

The dma-buf-mgr handles tracking, and waiting on, the fences associated
with a dma-buf.

The one pending on the fence can add an async callback:
  + fence_add_callback()

The callback can optionally be cancelled with:
  + fence_remove_callback()

To wait synchronously, optionally with a timeout:
  + fence_wait()
  + fence_wait_timeout()

When emitting a fence, call:
  + trace_fence_emit()

To annotate that a fence is blocking on another fence, call:
  + trace_fence_annotate_wait_on(fence, on_fence)

A default software-only implementation is provided, which can be used
by drivers attaching a fence to a buffer when they have no other means
for hw sync.  But a memory backed fence is also envisioned, because it
is common that GPU's can write to, or poll on some memory location for
synchronization.  For example:

  fence = custom_get_fence(...);
  if ((seqno_fence = to_seqno_fence(fence)) != NULL) {
dma_buf *fence_buf = fence->sync_buf;
get_dma_buf(fence_buf);

... tell the hw the memory location to wait ...
custom_wait_on(fence_buf, fence->seqno_ofs, fence->seqno);
  } else {
/* fall-back to sw sync * /
fence_add_callback(fence, my_cb);
  }

On SoC platforms, if some other hw mechanism is provided for synchronizing
between IP blocks, it could be supported as an alternate implementation
with it's own fence ops in a similar way.

enable_signaling callback is used to provide sw signaling in case a cpu
waiter is requested or no compatible hardware signaling could be used.

The intention is to provide a userspace interface (presumably via eventfd)
later, to be used in conjunction with dma-buf's mmap support for sw access
to buffers (or for userspace apps that would prefer to do their own
synchronization).

v1: Original
v2: After discussion w/ danvet and mlankhorst on #dri-devel, we decided
that dma-fence didn't need to care about the sw->hw signaling path
(it can be handled same as sw->sw case), and therefore the fence->ops
can be simplified and more handled in the core.  So remove the signal,
add_callback, cancel_callback, and wait ops, and replace with a simple
enable_signaling() op which can be used to inform a fence supporting
hw->hw signaling that one or more devices which do not support hw
signaling are waiting (and therefore it should enable an irq or do
whatever is necessary in order that the CPU is notified when the
fence is passed).
v3: Fix locking fail in attach_fence() and get_fence()
v4: Remove tie-in w/ dma-buf..  after discussion w/ danvet and mlankorst
we decided that we need to be able to attach one fence to N dma-buf's,
so using the list_head in dma-fence struct would be problematic.
v5: [ Maarten Lankhorst ] Updated for dma-bikeshed-fence and dma-buf-manager.
v6: [ Maarten Lankhorst ] I removed dma_fence_cancel_callback and some comments
about checking if fence fired or not. This is broken by design.
waitqueue_active during destruction is now fatal, since the signaller
should be holding a reference in enable_signalling until it signalled
the fence. Pass the original dma_fence_cb along, and call __remove_wait
in the dma_fence_callback handler, so that no cleanup needs to be
performed.
v7: [ Maarten Lankhorst ] Set cb->func and only enable sw signaling if
fence wasn't signaled yet, for example for hardware fences that may
choose to signal blindly.
v8: [ Maarten Lankhorst ] Tons of tiny fixes, moved __dma_fence_init to
header and fixed include mess. dma-fence.h now includes dma-buf.h
All members are now initialized, so kmalloc can be used for
allocating a dma-fence. More documentation added.
v9: Change compiler bitfields to flags, change return type of
enable_signaling to bool. Rework dma_fence_wait. Added
dma_fence_is_signaled and dma_fence_wait_timeout.
s/dma// and change exports to non GPL. Added fence_is_signaled and
fence_enable_sw_signaling calls, add ability to override default

[PATCH 4/7] dma-buf: use reservation objects

This allows reservation objects to be used in dma-buf. it's required
for implementing polling support on the fences that belong to a dma-buf.

Signed-off-by: Maarten Lankhorst 
---
 drivers/base/dma-buf.c |   22 --
 drivers/gpu/drm/drm_prime.c|8 +++-
 drivers/gpu/drm/exynos/exynos_drm_dmabuf.c |2 +-
 drivers/gpu/drm/i915/i915_gem_dmabuf.c |2 +-
 drivers/gpu/drm/nouveau/nouveau_drm.c  |1 +
 drivers/gpu/drm/nouveau/nouveau_gem.h  |1 +
 drivers/gpu/drm/nouveau/nouveau_prime.c|7 +++
 drivers/gpu/drm/omapdrm/omap_gem_dmabuf.c  |2 +-
 drivers/gpu/drm/radeon/radeon_drv.c|2 ++
 drivers/gpu/drm/radeon/radeon_prime.c  |8 
 drivers/gpu/drm/ttm/ttm_object.c   |2 +-
 drivers/media/v4l2-core/videobuf2-dma-contig.c |2 +-
 include/drm/drmP.h |2 ++
 include/linux/dma-buf.h|9 ++---
 14 files changed, 59 insertions(+), 11 deletions(-)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 1e16cbd61da2..85e792c2c909 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -25,10 +25,12 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
 #include 
+#include 
 
 static inline int is_dma_buf_file(struct file *);
 
@@ -56,6 +58,9 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
list_del(&dmabuf->list_node);
mutex_unlock(&db_list.lock);
 
+   if (dmabuf->resv == (struct reservation_object*)&dmabuf[1])
+   reservation_object_fini(dmabuf->resv);
+
kfree(dmabuf);
return 0;
 }
@@ -128,6 +133,7 @@ static inline int is_dma_buf_file(struct file *file)
  * @size:  [in]Size of the buffer
  * @flags: [in]mode flags for the file.
  * @exp_name:  [in]name of the exporting module - useful for debugging.
+ * @resv:  [in]reservation-object, NULL to allocate default one.
  *
  * Returns, on success, a newly created dma_buf object, which wraps the
  * supplied private data and operations for dma_buf_ops. On either missing
@@ -135,10 +141,17 @@ static inline int is_dma_buf_file(struct file *file)
  *
  */
 struct dma_buf *dma_buf_export_named(void *priv, const struct dma_buf_ops *ops,
-   size_t size, int flags, const char *exp_name)
+   size_t size, int flags, const char *exp_name,
+   struct reservation_object *resv)
 {
struct dma_buf *dmabuf;
struct file *file;
+   size_t alloc_size = sizeof(struct dma_buf);
+   if (!resv)
+   alloc_size += sizeof(struct reservation_object);
+   else
+   /* prevent &dma_buf[1] == dma_buf->resv */
+   alloc_size += 1;
 
if (WARN_ON(!priv || !ops
  || !ops->map_dma_buf
@@ -150,7 +163,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
return ERR_PTR(-EINVAL);
}
 
-   dmabuf = kzalloc(sizeof(struct dma_buf), GFP_KERNEL);
+   dmabuf = kzalloc(alloc_size, GFP_KERNEL);
if (dmabuf == NULL)
return ERR_PTR(-ENOMEM);
 
@@ -158,6 +171,11 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+   if (!resv) {
+   resv = (struct reservation_object*)&dmabuf[1];
+   reservation_object_init(resv);
+   }
+   dmabuf->resv = resv;
 
file = anon_inode_getfile("dmabuf", &dma_buf_fops, dmabuf, flags);
if (IS_ERR(file)) {
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index 56805c39c906..a13e90245adf 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -318,7 +318,13 @@ static const struct dma_buf_ops drm_gem_prime_dmabuf_ops = 
 {
 struct dma_buf *drm_gem_prime_export(struct drm_device *dev,
 struct drm_gem_object *obj, int flags)
 {
-   return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size, flags);
+   struct reservation_object *robj = NULL;
+
+   if (dev->driver->gem_prime_res_obj)
+   robj = dev->driver->gem_prime_res_obj(obj);
+
+   return dma_buf_export(obj, &drm_gem_prime_dmabuf_ops, obj->size,
+ flags, robj);
 }
 EXPORT_SYMBOL(drm_gem_prime_export);
 
diff --git a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c 
b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
index 59827cc5e770..b5e89f46326e 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_dmabuf.c
@@ -187,7 +187,7 @@ struct dma_buf *exynos_dmabuf_prime_export(struct 
drm_device *drm_dev,
struct exynos_drm_gem_obj *exynos_gem_obj = to_exynos_ge

[PATCH 6/7] reservation: add support for fences to enable cross-device synchronisation

Signed-off-by: Maarten Lankhorst 
---
 include/linux/reservation.h |   18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/include/linux/reservation.h b/include/linux/reservation.h
index 813dae960ebd..92c4851b5a39 100644
--- a/include/linux/reservation.h
+++ b/include/linux/reservation.h
@@ -6,7 +6,7 @@
  * Copyright (C) 2012 Texas Instruments
  *
  * Authors:
- * Rob Clark 
+ * Rob Clark 
  * Maarten Lankhorst 
  * Thomas Hellstrom 
  *
@@ -40,22 +40,38 @@
 #define _LINUX_RESERVATION_H
 
 #include 
+#include 
 
 extern struct ww_class reservation_ww_class;
 
 struct reservation_object {
struct ww_mutex lock;
+
+   struct fence *fence_excl;
+   struct fence **fence_shared;
+   u32 fence_shared_count, fence_shared_max;
 };
 
 static inline void
 reservation_object_init(struct reservation_object *obj)
 {
ww_mutex_init(&obj->lock, &reservation_ww_class);
+
+   obj->fence_shared_count = obj->fence_shared_max = 0;
+   obj->fence_shared = NULL;
+   obj->fence_excl = NULL;
 }
 
 static inline void
 reservation_object_fini(struct reservation_object *obj)
 {
+   int i;
+
+   if (obj->fence_excl)
+   fence_put(obj->fence_excl);
+   for (i = 0; i < obj->fence_shared_count; ++i)
+   fence_put(obj->fence_shared[i]);
+
ww_mutex_destroy(&obj->lock);
 }
 

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

[PATCH 5/7] android: convert sync to fence api, v3

Android syncpoints can be mapped to a timeline. This removes the need
to maintain a separate api for synchronization. I've left the android
trace events in place, but the core fence events should already be
sufficient for debugging.

v2:
- Call fence_remove_callback in sync_fence_free if not all fences have fired.
v3:
- Merge Colin Cross' bugfixes, and the android fence merge optimization.

Signed-off-by: Maarten Lankhorst 
---
 drivers/staging/android/Kconfig  |1 
 drivers/staging/android/Makefile |2 
 drivers/staging/android/sw_sync.c|4 
 drivers/staging/android/sync.c   |  895 +++---
 drivers/staging/android/sync.h   |   85 ++-
 drivers/staging/android/sync_debug.c |  245 +
 drivers/staging/android/trace/sync.h |   12 
 7 files changed, 592 insertions(+), 652 deletions(-)
 create mode 100644 drivers/staging/android/sync_debug.c

diff --git a/drivers/staging/android/Kconfig b/drivers/staging/android/Kconfig
index 1e9ab6dfc90d..c8d28dc3050c 100644
--- a/drivers/staging/android/Kconfig
+++ b/drivers/staging/android/Kconfig
@@ -77,6 +77,7 @@ config SYNC
bool "Synchronization framework"
default n
select ANON_INODES
+   select DMA_SHARED_BUFFER
---help---
  This option enables the framework for synchronization between multiple
  drivers.  Sync implementations can take advantage of hardware
diff --git a/drivers/staging/android/Makefile b/drivers/staging/android/Makefile
index c136299e05af..81b8293ba1a9 100644
--- a/drivers/staging/android/Makefile
+++ b/drivers/staging/android/Makefile
@@ -7,5 +7,5 @@ obj-$(CONFIG_ANDROID_TIMED_OUTPUT)  += timed_output.o
 obj-$(CONFIG_ANDROID_TIMED_GPIO)   += timed_gpio.o
 obj-$(CONFIG_ANDROID_LOW_MEMORY_KILLER)+= lowmemorykiller.o
 obj-$(CONFIG_ANDROID_INTF_ALARM_DEV)   += alarm-dev.o
-obj-$(CONFIG_SYNC) += sync.o
+obj-$(CONFIG_SYNC) += sync.o sync_debug.o
 obj-$(CONFIG_SW_SYNC)  += sw_sync.o
diff --git a/drivers/staging/android/sw_sync.c 
b/drivers/staging/android/sw_sync.c
index f24493ac65e3..a76db3ff87cb 100644
--- a/drivers/staging/android/sw_sync.c
+++ b/drivers/staging/android/sw_sync.c
@@ -50,7 +50,7 @@ static struct sync_pt *sw_sync_pt_dup(struct sync_pt *sync_pt)
 {
struct sw_sync_pt *pt = (struct sw_sync_pt *) sync_pt;
struct sw_sync_timeline *obj =
-   (struct sw_sync_timeline *)sync_pt->parent;
+   (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
 
return (struct sync_pt *) sw_sync_pt_create(obj, pt->value);
 }
@@ -59,7 +59,7 @@ static int sw_sync_pt_has_signaled(struct sync_pt *sync_pt)
 {
struct sw_sync_pt *pt = (struct sw_sync_pt *)sync_pt;
struct sw_sync_timeline *obj =
-   (struct sw_sync_timeline *)sync_pt->parent;
+   (struct sw_sync_timeline *)sync_pt_parent(sync_pt);
 
return sw_sync_cmp(obj->value, pt->value) >= 0;
 }
diff --git a/drivers/staging/android/sync.c b/drivers/staging/android/sync.c
index 38e5d3b5ed9b..ba0d69e269b5 100644
--- a/drivers/staging/android/sync.c
+++ b/drivers/staging/android/sync.c
@@ -31,22 +31,13 @@
 #define CREATE_TRACE_POINTS
 #include "trace/sync.h"
 
-static void sync_fence_signal_pt(struct sync_pt *pt);
-static int _sync_pt_has_signaled(struct sync_pt *pt);
-static void sync_fence_free(struct kref *kref);
-static void sync_dump(void);
-
-static LIST_HEAD(sync_timeline_list_head);
-static DEFINE_SPINLOCK(sync_timeline_list_lock);
-
-static LIST_HEAD(sync_fence_list_head);
-static DEFINE_SPINLOCK(sync_fence_list_lock);
+static const struct fence_ops android_fence_ops;
+static const struct file_operations sync_fence_fops;
 
 struct sync_timeline *sync_timeline_create(const struct sync_timeline_ops *ops,
   int size, const char *name)
 {
struct sync_timeline *obj;
-   unsigned long flags;
 
if (size < sizeof(struct sync_timeline))
return NULL;
@@ -57,17 +48,14 @@ struct sync_timeline *sync_timeline_create(const struct 
sync_timeline_ops *ops,
 
kref_init(&obj->kref);
obj->ops = ops;
+   obj->context = fence_context_alloc(1);
strlcpy(obj->name, name, sizeof(obj->name));
 
INIT_LIST_HEAD(&obj->child_list_head);
-   spin_lock_init(&obj->child_list_lock);
-
INIT_LIST_HEAD(&obj->active_list_head);
-   spin_lock_init(&obj->active_list_lock);
+   spin_lock_init(&obj->child_list_lock);
 
-   spin_lock_irqsave(&sync_timeline_list_lock, flags);
-   list_add_tail(&obj->sync_timeline_list, &sync_timeline_list_head);
-   spin_unlock_irqrestore(&sync_timeline_list_lock, flags);
+   sync_timeline_debug_add(obj);
 
return obj;
 }
@@ -77,18 +65,25 @@ static void sync_timeline_free(struct kref *kref)
 {
struct sync_timeline *obj =
container_of(kref, struct sync_timeline, kref);
-

[PATCH 7/7] dma-buf: add poll support

Thanks to Fengguang Wu for spotting a missing static cast.

Signed-off-by: Maarten Lankhorst 
---
 drivers/base/dma-buf.c  |  102 +++
 include/linux/dma-buf.h |   12 ++
 2 files changed, 114 insertions(+)

diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index 85e792c2c909..e0898d49530e 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 static inline int is_dma_buf_file(struct file *);
@@ -52,6 +53,13 @@ static int dma_buf_release(struct inode *inode, struct file 
*file)
 
BUG_ON(dmabuf->vmapping_counter);
 
+   /*
+* Any fences that a dma-buf poll can wait on should be signaled
+* before releasing dma-buf. This is the responsibility of each
+* driver that uses the reservation objects.
+*/
+   BUG_ON(dmabuf->cb_shared.active || dmabuf->cb_excl.active);
+
dmabuf->ops->release(dmabuf);
 
mutex_lock(&db_list.lock);
@@ -108,10 +116,100 @@ static loff_t dma_buf_llseek(struct file *file, loff_t 
offset, int whence)
return base + offset;
 }
 
+static void dma_buf_poll_cb(struct fence *fence, struct fence_cb *cb)
+{
+   struct dma_buf_poll_cb_t *dcb = (struct dma_buf_poll_cb_t*) cb;
+   unsigned long flags;
+
+   spin_lock_irqsave(&dcb->poll->lock, flags);
+   wake_up_locked_poll(dcb->poll, dcb->active);
+   dcb->active = 0;
+   spin_unlock_irqrestore(&dcb->poll->lock, flags);
+}
+
+static unsigned int dma_buf_poll(struct file *file, poll_table *poll)
+{
+   struct dma_buf *dmabuf;
+   struct reservation_object *resv;
+   unsigned long events;
+   int need_shared;
+
+   dmabuf = file->private_data;
+   if (!dmabuf || !dmabuf->resv)
+   return POLLERR;
+
+   resv = dmabuf->resv;
+
+   poll_wait(file, &dmabuf->poll, poll);
+
+   events = poll_requested_events(poll) & (POLLIN | POLLOUT);
+   if (!events)
+   return 0;
+
+   ww_mutex_lock(&resv->lock, NULL);
+
+   if (resv->fence_excl && (!(events & POLLOUT) || 
resv->fence_shared_count == 0)) {
+   struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_excl;
+   unsigned long pevents = POLLIN;
+
+   if (resv->fence_shared_count == 0)
+   pevents |= POLLOUT;
+
+   spin_lock_irq(&dmabuf->poll.lock);
+   if (dcb->active) {
+   dcb->active |= pevents;
+   events &= ~pevents;
+   } else
+   dcb->active = pevents;
+   spin_unlock_irq(&dmabuf->poll.lock);
+
+   if (events & pevents) {
+   if (!fence_add_callback(resv->fence_excl,
+   &dcb->cb, dma_buf_poll_cb))
+   events &= ~pevents;
+   else
+   // No callback queued, wake up any additional waiters.
+   dma_buf_poll_cb(NULL, &dcb->cb);
+   }
+   }
+
+   if ((events & POLLOUT) && resv->fence_shared_count > 0) {
+   struct dma_buf_poll_cb_t *dcb = &dmabuf->cb_shared;
+   int i;
+
+   /* Only queue a new callback if no event has fired yet */
+   spin_lock_irq(&dmabuf->poll.lock);
+   if (dcb->active)
+   events &= ~POLLOUT;
+   else
+   dcb->active = POLLOUT;
+   spin_unlock_irq(&dmabuf->poll.lock);
+
+   if (!(events & POLLOUT))
+   goto out;
+
+   for (i = 0; i < resv->fence_shared_count; ++i)
+   if (!fence_add_callback(resv->fence_shared[i],
+   &dcb->cb, dma_buf_poll_cb)) {
+   events &= ~POLLOUT;
+   break;
+   }
+
+   // No callback queued, wake up any additional waiters.
+   if (i == resv->fence_shared_count)
+   dma_buf_poll_cb(NULL, &dcb->cb);
+   }
+
+out:
+   ww_mutex_unlock(&resv->lock);
+   return events;
+}
+
 static const struct file_operations dma_buf_fops = {
.release= dma_buf_release,
.mmap   = dma_buf_mmap_internal,
.llseek = dma_buf_llseek,
+   .poll   = dma_buf_poll,
 };
 
 /*
@@ -171,6 +269,10 @@ struct dma_buf *dma_buf_export_named(void *priv, const 
struct dma_buf_ops *ops,
dmabuf->ops = ops;
dmabuf->size = size;
dmabuf->exp_name = exp_name;
+   init_waitqueue_head(&dmabuf->poll);
+   dmabuf->cb_excl.poll = dmabuf->cb_shared.poll = &dmabuf->poll;
+   dmabuf->cb_excl.active = dmabuf->cb_shared.active = 0;
+
if (!resv) {
resv = (struct reservation_object*)&dmabuf[1];

Re: [PATCH v4 2/2] videobuf2-dma-sg: Replace vb2_dma_sg_desc with sg_table

On 01/13/2014 02:02 PM, Marek Szyprowski wrote:
> Hello,
> 
> On 2014-01-13 10:54, Hans Verkuil wrote:
>> Hi Marek, Ricardo,
>>
>> On 01/08/2014 03:07 PM, Marek Szyprowski wrote:
>>> Hello All,
>>>
>>> On 2014-01-03 16:51, Ricardo Ribalda Delgado wrote:
 Hello Hans

 What if we move the dma_map_sg and dma_unmap_sg to the vb2 interface,
 and there do something like:

 n_sg= dma_map_sg()
 if (n_sg=-ENOMEM){
 split_table() //Breaks down the sg_table into monopages sg
 n_sg= dma_map_sg()
>>
>> This is not a good approach. Remember that if swiotbl needs to allocate
>> e.g. 17 contiguous pages it will round up to the next power of two, so it
>> allocates 32 pages. So even if dma_map_sg succeeds, it might waste a lot
>> of memory.
>>
 }
 if (n_sg=-ENOMEM)
return -ENOMEM
>>>
>>> dma_map_sg/dma_unmap_sg should be moved to vb2-dma-sg memory allocator.
>>> The best place for calling them is buf_prepare() and buf_finish()
>>> callbacks. I think that I've already pointed this some time ago, but
>>> unfortunately I didn't find enough time to convert existing code.
>>
>> That would be nice, but this is a separate issue.
>>
>>> For solving the problem described by Hans, I think that vb2-dma-sg
>>> memory allocator should check dma mask of the client device and add
>>> appropriate GFP_DMA or GFP_DMA32 flags to alloc_pages(). This should fix
>>> the issues with failed dma_map_sg due to lack of bouncing buffers.
>>
>> Those GFP flags are for the scatterlist itself, and that can be placed
>> anywhere in memory (frankly, I'm not sure why sg_alloc_table_from_pages
>> has a gfp_flags argument at all and I think it is used incorrectly in
>> videobuf2-dma-sg.c as well).
> 
> I was talking about GFP flags passed to alloc_pages in vb2_dma_sg allocator,
> not the sg_alloc_table_from_pages().
> 
> IMHO the following changes should fix your problem:
> 
> 1. add client struct device pointer to vb2_dma_sg_desc, so vb2_dma_sg
> allocator will be able to check dma parameters of the client device.
> 
> 2. add following check to vb2_dma_sg_alloc_compacted():
> 
> if (dev->dma_mask) {
>  if (dev->dma_mask < DMA_BIT_MASK(32))
>  gfp_mask |= GFP_DMA;
>  else if (dev->dev_mask == DMA_BIT_MASK(32)
>  gfp_mask |= GFP_DMA32;
> }

No, it doesn't. This concerns the USERPTR memory model, so the memory for
the buffer is allocated by userspace, not by the kernel. The MMAP memory
model works fine, that's not where the problem is.

> 
> 
>> I see two options. The first is the patch I included below: this adds a
>> bool to sg_alloc_table_from_pages() that tells it whether or not page
>> combining should be enabled. It also adds the vb2 queue's gfp_flags as
>> an argument to the get_userptr operation. In videobuf2-dma-sg.c that is
>> checked to see whether or not sg_alloc_table_from_pages() should enable
>> page-combining.
>>
>> The alternative would be to have vb2_queue_init check if the use of
>> V4L2_MEMORY_USERPTR would lead to dma bouncing based on the q->io_modes
>> and q->gfp_flags and if so, remove USERPTR support from io_modes. Do
>> we really want to have page bouncing for video capture?
> 
> So the main problem is about user ptr modes? This once again shows that
> the current user pointer API is too limited and should be replaced by
> something more reliable.

The userptr model worked perfectly fine before the memory compaction was
added. This is a pure regression.

Regards,

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

Re: [RFC PATCH 3/6] DocBook media: partial rewrite of "Opening and Closing Devices"

Em Tue,  7 Jan 2014 14:06:54 +0100
Hans Verkuil  escreveu:

> From: Hans Verkuil 
> 
> This section was horribly out of date. A lot of references to old and
> obsolete behavior have been dropped.
> 
> Signed-off-by: Hans Verkuil 
> ---
>  Documentation/DocBook/media/v4l/common.xml | 188 
> ++---
>  1 file changed, 67 insertions(+), 121 deletions(-)
> 
> diff --git a/Documentation/DocBook/media/v4l/common.xml 
> b/Documentation/DocBook/media/v4l/common.xml
> index 1ddf354..da08df9 100644
> --- a/Documentation/DocBook/media/v4l/common.xml
> +++ b/Documentation/DocBook/media/v4l/common.xml
> @@ -38,70 +38,41 @@ the basic concepts applicable to all devices.
>  
>V4L2 drivers are implemented as kernel modules, loaded
>  manually by the system administrator or automatically when a device is
> -first opened. The driver modules plug into the "videodev" kernel
> +first discovered. The driver modules plug into the "videodev" kernel
>  module. It provides helper functions and a common application
>  interface specified in this document.
>  
>Each driver thus loaded registers one or more device nodes
> -with major number 81 and a minor number between 0 and 255. Assigning
> -minor numbers to V4L2 devices is entirely up to the system administrator,
> -this is primarily intended to solve conflicts between devices.
> -   Access permissions are associated with character
> -device special files, hence we must ensure device numbers cannot
> -change with the module load order. To this end minor numbers are no
> -longer automatically assigned by the "videodev" module as in V4L but
> -requested by the driver. The defaults will suffice for most people
> -unless two drivers compete for the same minor numbers.
> -  The module options to select minor numbers are named
> -after the device special file with a "_nr" suffix. For example "video_nr"
> -for /dev/video video capture devices. The number is
> -an offset to the base minor number associated with the device type.
> -
> -   In earlier versions of the V4L2 API the module options
> -where named after the device special file with a "unit_" prefix, expressing
> -the minor number itself, not an offset. Rationale for this change is unknown.
> -Lastly the naming and semantics are just a convention among driver writers,
> -the point to note is that minor numbers are not supposed to be hardcoded
> -into drivers.
> -  When the driver supports multiple devices of the same
> -type more than one minor number can be assigned, separated by commas:
> -
> +with major number 81 and a minor number between 0 and 255. Minor numbers
> +are allocated dynamically unless the kernel is compiled with the kernel
> +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are
> +allocated in ranges depending on the device node type (video, radio, 
> etc.).
> +
> +  Many drivers support "video_nr", "radio_nr" or "vbi_nr"
> +module options to select specific video/radio/vbi node numbers. This allows
> +the user to request that the device node is named e.g. /dev/video5 instead
> +of leaving it to chance. When the driver supports multiple devices of the 
> same
> +type more than one device node number can be assigned, separated by commas:
> + 
> 
> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1
> +> modprobe mydriver video_nr=0,1 radio_nr=0,1
>   
>  
>In /etc/modules.conf this may be
>  written as: 
> 
> -alias char-major-81-0 mydriver
> -alias char-major-81-1 mydriver
> -alias char-major-81-64 mydriver  
> -options mydriver video_nr=0,1 radio_nr=0,1   
> +options mydriver video_nr=0,1 radio_nr=0,1
> 
> -   
> - 
> -   When an application attempts to open a device
> -special file with major number 81 and minor number 0, 1, or 64, load
> -"mydriver" (and the "videodev" module it depends upon).
> - 
> - 
> -   Register the first two video capture devices with
> -minor number 0 and 1 (base number is 0), the first two radio device
> -with minor number 64 and 65 (base 64).
> - 
> -   
> -  When no minor number is given as module
> -option the driver supplies a default. 
> -recommends the base minor numbers to be used for the various device
> -types. Obviously minor numbers must be unique. When the number is
> -already in use the offending device will not be
> -registered. 
> -
> -  By convention system administrators create various
> -character device special files with these major and minor numbers in
> -the /dev directory. The names recommended for the
> -different V4L2 device types are listed in .
> +  When no device node number is given as module
> +option the driver supplies a default.
> +
> +  Normally udev will create the device nodes in /dev automatically
> +for you. If udev is not installed, then you need to enable the
> +CONFIG_VIDEO_FIXED_MINOR_RANGES kernel option in order to be able to 
> correctly
> +relate a m

Re: using MFC memory to memery encoder, start stream and queue order problem

2014-01-13 Thread randy

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

 20140113 19:18, Andrzej Hajda wrote:

>>>>>>> It won't work, if I do that, after step 7, neither
>>>>>>> OUPUT nor CAPTURE will poll return in my program. but
>>>>>>> ./mfc-encode -m /dev/video1 -c h264,header_mode=1 work
>>>>>>> normally,
>>>>>> I am sorry, I didn't well test it, if I use ./mfc-encode
>>>>>> -m /dev/video1 -c h264,header_mode=1 -d 1 then the size
>>>>>> of demo.out is zero, but ./mfc-encode -d 1 -m /dev/video1
>>>>>> -c h264 will out a 158 bytes files. When duration is 2,
>>>>>> with header_mode=1, the output file size is 228
>>>>>> bytes.Without it, the size is 228 too. I wonder whether
>>>>>> it is the driver's problem, as I see this in dmesg [
>>>>>> 0.21] Failed to declare coherent memory for MFC 
>>>>>> device (0 bytes at 0x4300) As the driver is not ready
>>>>>> to use in 3.13-rc6 as I reported before, I still use the
>>>>>> 3.5 from manufacturer.
>>>>> 
>>>>> I am the author of mfc-encode application, it was written
>>>>> for the mainline kernel 3.8 and later, it should be
>>>>> mentioned in the README.txt - I will update it.
So it seems that the design my program is correct, just the driver's
problem?

>>>>> 
> Sadness, they doesn't offer any of them, even not any information 
> about it. And I can't compile the openmax from samsung. I will
> report it later in sourceforge.
>>> 
> 
>> I believe it is the best solution if you are interesting in
>> fixing only MFC encoding. If your goal is wider I suggest to try
>> linux-next kernel. There is basic(!) DT support for this board
>> applied about month ago: https://lkml.org/lkml/2013/12/18/285
> 
I will try it, I wish the driver in -next is done, as I can never open
the mfc encoder in 3.12.
I have another problem with the data transporting way in
v4l2-mfc-encoder, it use m.userptr, I think it is not need, as it has
been mmap  to bufs->addr before, just fill the bufs->addr is enough,
and for mfc,
the buffer type V4L2_MEMORY_MMAP,  I think that it had better use
m.mem_offset from v4l2 document, why it use userptr?

>> Regards Andrzej
> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
> 
> Thank you ayaka
>>> 
>> 
> 
> 
> 
Thank you
ayaka
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJS1AnoAAoJEPb4VsMIzTzi5aUH/j2MT0YlzhMYtBrzkCGL1niM
iMJ7CprSTFZq8WLxb2OKN4/+WTwsbfEy3CAFmFtCXdhB7JeGeHLpj48vs5L7dtJt
CTc1QPHuAVpWNaL6/mP1gXEWOWZDXjIr70f2rG0lGhiS+t0PVri8+mukyu81Oc+w
AFFoWsuCAJgTKTT3qpWJEhHdEszHrrzfkOJoUa2PdITKZezhQHw4OBbsr1mVdfeJ
UcdYiHHKF40bsglXVfj8BgQ5oM3/Dx3IWowR8kymGJDPB+E18+fk/wogxOdILOYY
WQIC54t5dCdWV8rUVsEaWlHECm/BgHozPdLY6j6n0ou+VqFhlyDMwidcTZXGvKI=
=/COC
-END PGP SIGNATURE-
--
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: using MFC memory to memery encoder, start stream and queue order problem

2014-01-13 Thread Kamil Debski

Hi,

> From: randy [mailto:lxr1...@hotmail.com]
> Sent: Monday, January 13, 2014 4:45 PM
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
>  20140113 19:18, Andrzej Hajda wrote:
> 
> >>>>>>> It won't work, if I do that, after step 7, neither OUPUT nor
> >>>>>>> CAPTURE will poll return in my program. but ./mfc-encode -m
> >>>>>>> /dev/video1 -c h264,header_mode=1 work normally,
> >>>>>> I am sorry, I didn't well test it, if I use ./mfc-encode -m
> >>>>>> /dev/video1 -c h264,header_mode=1 -d 1 then the size of demo.out
> >>>>>> is zero, but ./mfc-encode -d 1 -m /dev/video1 -c h264 will out a
> >>>>>> 158 bytes files. When duration is 2, with header_mode=1, the
> >>>>>> output file size is 228 bytes.Without it, the size is 228 too. I
> >>>>>> wonder whether it is the driver's problem, as I see this in
> dmesg
> >>>>>> [ 0.21] Failed to declare coherent memory for MFC device (0
> >>>>>> bytes at 0x4300) As the driver is not ready to use in
> >>>>>> 3.13-rc6 as I reported before, I still use the
> >>>>>> 3.5 from manufacturer.
> >>>>>
> >>>>> I am the author of mfc-encode application, it was written for the
> >>>>> mainline kernel 3.8 and later, it should be mentioned in the
> >>>>> README.txt - I will update it.
> So it seems that the design my program is correct, just the driver's
> problem?
> 
> >>>>>
> > Sadness, they doesn't offer any of them, even not any information
> > about it. And I can't compile the openmax from samsung. I will report
> > it later in sourceforge.
> >>>
> >
> >> I believe it is the best solution if you are interesting in fixing
> >> only MFC encoding. If your goal is wider I suggest to try linux-next
> >> kernel. There is basic(!) DT support for this board applied about
> >> month ago: https://lkml.org/lkml/2013/12/18/285
> >
> I will try it, I wish the driver in -next is done, as I can never open
> the mfc encoder in 3.12.

Randy, 

Please apply these two patches:
[PATCH] media: s5p_mfc: remove s5p_mfc_get_node_type() function
[PATCH] media: v4l2-dev: fix video device index assignment

And try again with kernel 3.12. There was a problem with opening MFC
that was introduced by other patches.

> I have another problem with the data transporting way in v4l2-mfc-
> encoder, it use m.userptr, I think it is not need, as it has been mmap
> to bufs->addr before, just fill the bufs->addr is enough, and for mfc,
> the buffer type V4L2_MEMORY_MMAP,  I think that it had better use
> m.mem_offset from v4l2 document, why it use userptr?
> 

Best wishes,
-- 
Kamil Debski
Samsung R&D Institute Poland

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

Re: [RFC PATCH 3/6] DocBook media: partial rewrite of "Opening and Closing Devices"

On 01/13/2014 04:20 PM, Mauro Carvalho Chehab wrote:
> Em Tue,  7 Jan 2014 14:06:54 +0100
> Hans Verkuil  escreveu:
> 
>> From: Hans Verkuil 
>>
>> This section was horribly out of date. A lot of references to old and
>> obsolete behavior have been dropped.
>>
>> Signed-off-by: Hans Verkuil 
>> ---
>>  Documentation/DocBook/media/v4l/common.xml | 188 
>> ++---
>>  1 file changed, 67 insertions(+), 121 deletions(-)
>>
>> diff --git a/Documentation/DocBook/media/v4l/common.xml 
>> b/Documentation/DocBook/media/v4l/common.xml
>> index 1ddf354..da08df9 100644
>> --- a/Documentation/DocBook/media/v4l/common.xml
>> +++ b/Documentation/DocBook/media/v4l/common.xml
>> @@ -38,70 +38,41 @@ the basic concepts applicable to all devices.
>>  
>>V4L2 drivers are implemented as kernel modules, loaded
>>  manually by the system administrator or automatically when a device is
>> -first opened. The driver modules plug into the "videodev" kernel
>> +first discovered. The driver modules plug into the "videodev" kernel
>>  module. It provides helper functions and a common application
>>  interface specified in this document.
>>  
>>Each driver thus loaded registers one or more device nodes
>> -with major number 81 and a minor number between 0 and 255. Assigning
>> -minor numbers to V4L2 devices is entirely up to the system administrator,
>> -this is primarily intended to solve conflicts between devices.
>> -  Access permissions are associated with character
>> -device special files, hence we must ensure device numbers cannot
>> -change with the module load order. To this end minor numbers are no
>> -longer automatically assigned by the "videodev" module as in V4L but
>> -requested by the driver. The defaults will suffice for most people
>> -unless two drivers compete for the same minor numbers.
>> - The module options to select minor numbers are named
>> -after the device special file with a "_nr" suffix. For example "video_nr"
>> -for /dev/video video capture devices. The number is
>> -an offset to the base minor number associated with the device type.
>> -
>> -  In earlier versions of the V4L2 API the module options
>> -where named after the device special file with a "unit_" prefix, expressing
>> -the minor number itself, not an offset. Rationale for this change is 
>> unknown.
>> -Lastly the naming and semantics are just a convention among driver writers,
>> -the point to note is that minor numbers are not supposed to be hardcoded
>> -into drivers.
>> - When the driver supports multiple devices of the same
>> -type more than one minor number can be assigned, separated by commas:
>> -
>> +with major number 81 and a minor number between 0 and 255. Minor numbers
>> +are allocated dynamically unless the kernel is compiled with the kernel
>> +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are
>> +allocated in ranges depending on the device node type (video, radio, 
>> etc.).
>> +
>> +  Many drivers support "video_nr", "radio_nr" or "vbi_nr"
>> +module options to select specific video/radio/vbi node numbers. This allows
>> +the user to request that the device node is named e.g. /dev/video5 instead
>> +of leaving it to chance. When the driver supports multiple devices of the 
>> same
>> +type more than one device node number can be assigned, separated by commas:
>> +
>>
>> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1
>> +> modprobe mydriver video_nr=0,1 radio_nr=0,1
>>  
>>  
>>In /etc/modules.conf this may be
>>  written as: 
>>
>> -alias char-major-81-0 mydriver
>> -alias char-major-81-1 mydriver
>> -alias char-major-81-64 mydriver  
>> -options mydriver video_nr=0,1 radio_nr=0,1   
>> +options mydriver video_nr=0,1 radio_nr=0,1
>>
>> -  
>> -
>> -  When an application attempts to open a device
>> -special file with major number 81 and minor number 0, 1, or 64, load
>> -"mydriver" (and the "videodev" module it depends upon).
>> -
>> -
>> -  Register the first two video capture devices with
>> -minor number 0 and 1 (base number is 0), the first two radio device
>> -with minor number 64 and 65 (base 64).
>> -
>> -  
>> - When no minor number is given as module
>> -option the driver supplies a default. 
>> -recommends the base minor numbers to be used for the various device
>> -types. Obviously minor numbers must be unique. When the number is
>> -already in use the offending device will not be
>> -registered. 
>> -
>> -  By convention system administrators create various
>> -character device special files with these major and minor numbers in
>> -the /dev directory. The names recommended for the
>> -different V4L2 device types are listed in .
>> + When no device node number is given as module
>> +option the driver supplies a default.
>> +
>> +  Normally udev will create the device nodes in /dev automatically
>> +for you. If udev

Re: [PATCH 3/3] au8522, au0828: Added demodulator reset

2014-01-13 Thread Devin Heitmueller

On Sat, Jan 11, 2014 at 5:12 PM, Tim Mester  wrote:
>   My device is the 950q, so it uses the AU8522_DEMODLOCKING method.

No devices do tuner locking for digital (it's always the demodulator).
 That code should really just be ripped out.

> It does not appear to be an xc5000 issue on the surface.   When I
> originally put the patch together, I removed the return if the
> frequency was the same, and added the reset_demodulator() call at the
> end of the set_frontend() function. It seemed to work the same as the
> patch that I submitted.

I'm pretty sure that we accomplish the same thing through the patch I
have which reworks the clock management. except for removing the part
where the set_frontend() call returns if the freq/modulation are
already set.

> I have not been able to tell that it keeps the au8522 from losing
> lock, but it allows it to come back.  I see this issue about once a
> every 2-3 weeks on average, which is less frequent than the other
> issues.
>
> If you believe that this issue could result in a xc5000 and au8522
> interaction, then I should be able to try out the updated firmware. It
> will just take some time to know the results.

My instinct would be to get you to try that patch series I have in
git.  I suspect that it will address your issue with no further
patches required (we might need the one additional patch to remove the
early return in set_frontend, but let's see).  The testing of the new
firmware can be done in a separate series (the issue it addresses is
completely unrelated to the behavior you are seeing).

Devin

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

[PATCH 1/2] [media] sh_vou: comment unused vars

Fix two warns below, by commenting the unused code:

drivers/media/platform/sh_vou.c: In function 'sh_vou_configure_geometry':
drivers/media/platform/sh_vou.c:446:49: warning: variable 'height_max' set but 
not used [-Wunused-but-set-variable]
  unsigned int black_left, black_top, width_max, height_max,
 ^
drivers/media/platform/sh_vou.c: In function 'sh_vou_isr':
drivers/media/platform/sh_vou.c:1056:13: warning: variable 'side' set but not 
used [-Wunused-but-set-variable]
  static int side;
 ^

Cc: Guennadi Liakhovetski 
Cc: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/sh_vou.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 65c9f180a309..e5f1d4c14f2c 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -443,7 +443,7 @@ static void sh_vou_configure_geometry(struct sh_vou_device 
*vou_dev,
  int pix_idx, int w_idx, int h_idx)
 {
struct sh_vou_fmt *fmt = vou_fmt + pix_idx;
-   unsigned int black_left, black_top, width_max, height_max,
+   unsigned int black_left, black_top, width_max,
frame_in_height, frame_out_height, frame_out_top;
struct v4l2_rect *rect = &vou_dev->rect;
struct v4l2_pix_format *pix = &vou_dev->pix;
@@ -451,10 +451,10 @@ static void sh_vou_configure_geometry(struct 
sh_vou_device *vou_dev,
 
if (vou_dev->std & V4L2_STD_525_60) {
width_max = 858;
-   height_max = 262;
+   /* height_max = 262; */
} else {
width_max = 864;
-   height_max = 312;
+   /* height_max = 312; */
}
 
frame_in_height = pix->height / 2;
@@ -1053,7 +1053,6 @@ static irqreturn_t sh_vou_isr(int irq, void *dev_id)
static unsigned long j;
struct videobuf_buffer *vb;
static int cnt;
-   static int side;
u32 irq_status = sh_vou_reg_a_read(vou_dev, VOUIR), masked;
u32 vou_status = sh_vou_reg_a_read(vou_dev, VOUSTR);
 
@@ -1081,7 +1080,7 @@ static irqreturn_t sh_vou_isr(int irq, void *dev_id)
irq_status, masked, vou_status, cnt);
 
cnt++;
-   side = vou_status & 0x1;
+   /* side = vou_status & 0x1; */
 
/* Clear only set interrupts */
sh_vou_reg_a_write(vou_dev, VOUIR, masked);
-- 
1.8.3.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

[PATCH 2/2] radio-usb-si4713: make si4713_register_i2c_adapter static

This function isn't used nowhere outside the same .c file.
Fixes this warning:

drivers/media/radio/si4713/radio-usb-si4713.c:418:5: warning: no previous 
prototype for 'si4713_register_i2c_adapter' [-Wmissing-prototypes]
 int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
 ^

Cc: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/si4713/radio-usb-si4713.c 
b/drivers/media/radio/si4713/radio-usb-si4713.c
index d97884494d04..f1e640d71188 100644
--- a/drivers/media/radio/si4713/radio-usb-si4713.c
+++ b/drivers/media/radio/si4713/radio-usb-si4713.c
@@ -415,7 +415,7 @@ static struct i2c_adapter si4713_i2c_adapter_template = {
.algo   = &si4713_algo,
 };
 
-int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
+static int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
 {
radio->i2c_adapter = si4713_i2c_adapter_template;
/* set up sysfs linkage to our parent device */
-- 
1.8.3.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: [RFC PATCH 3/6] DocBook media: partial rewrite of "Opening and Closing Devices"

Em Mon, 13 Jan 2014 17:15:40 +0100
Hans Verkuil  escreveu:

> On 01/13/2014 04:20 PM, Mauro Carvalho Chehab wrote:
> > Em Tue,  7 Jan 2014 14:06:54 +0100
> > Hans Verkuil  escreveu:
> > 
> >> From: Hans Verkuil 
> >>
> >> This section was horribly out of date. A lot of references to old and
> >> obsolete behavior have been dropped.

Forgot to mention, put patches 1 and 2 are ok. I'll review the patches 4-6
later this week.

> >>
> >> Signed-off-by: Hans Verkuil 
> >> ---
> >>  Documentation/DocBook/media/v4l/common.xml | 188 
> >> ++---
> >>  1 file changed, 67 insertions(+), 121 deletions(-)
> >>
> >> diff --git a/Documentation/DocBook/media/v4l/common.xml 
> >> b/Documentation/DocBook/media/v4l/common.xml
> >> index 1ddf354..da08df9 100644
> >> --- a/Documentation/DocBook/media/v4l/common.xml
> >> +++ b/Documentation/DocBook/media/v4l/common.xml
> >> @@ -38,70 +38,41 @@ the basic concepts applicable to all devices.
> >>  
> >>V4L2 drivers are implemented as kernel modules, loaded
> >>  manually by the system administrator or automatically when a device is
> >> -first opened. The driver modules plug into the "videodev" kernel
> >> +first discovered. The driver modules plug into the "videodev" kernel
> >>  module. It provides helper functions and a common application
> >>  interface specified in this document.
> >>  
> >>Each driver thus loaded registers one or more device nodes
> >> -with major number 81 and a minor number between 0 and 255. Assigning
> >> -minor numbers to V4L2 devices is entirely up to the system administrator,
> >> -this is primarily intended to solve conflicts between devices.
> >> -Access permissions are associated with character
> >> -device special files, hence we must ensure device numbers cannot
> >> -change with the module load order. To this end minor numbers are no
> >> -longer automatically assigned by the "videodev" module as in V4L but
> >> -requested by the driver. The defaults will suffice for most people
> >> -unless two drivers compete for the same minor numbers.
> >> -   The module options to select minor numbers are named
> >> -after the device special file with a "_nr" suffix. For example "video_nr"
> >> -for /dev/video video capture devices. The number is
> >> -an offset to the base minor number associated with the device type.
> >> -
> >> -In earlier versions of the V4L2 API the module options
> >> -where named after the device special file with a "unit_" prefix, 
> >> expressing
> >> -the minor number itself, not an offset. Rationale for this change is 
> >> unknown.
> >> -Lastly the naming and semantics are just a convention among driver 
> >> writers,
> >> -the point to note is that minor numbers are not supposed to be hardcoded
> >> -into drivers.
> >> -   When the driver supports multiple devices of the same
> >> -type more than one minor number can be assigned, separated by commas:
> >> -
> >> +with major number 81 and a minor number between 0 and 255. Minor numbers
> >> +are allocated dynamically unless the kernel is compiled with the kernel
> >> +option CONFIG_VIDEO_FIXED_MINOR_RANGES. In that case minor numbers are
> >> +allocated in ranges depending on the device node type (video, radio, 
> >> etc.).
> >> +
> >> +  Many drivers support "video_nr", "radio_nr" or "vbi_nr"
> >> +module options to select specific video/radio/vbi node numbers. This 
> >> allows
> >> +the user to request that the device node is named e.g. /dev/video5 instead
> >> +of leaving it to chance. When the driver supports multiple devices of the 
> >> same
> >> +type more than one device node number can be assigned, separated by 
> >> commas:
> >> +  
> >>  
> >> -> insmod mydriver.o video_nr=0,1 radio_nr=0,1
> >> +> modprobe mydriver video_nr=0,1 radio_nr=0,1
> >>
> >>  
> >>In /etc/modules.conf this may be
> >>  written as: 
> >>  
> >> -alias char-major-81-0 mydriver
> >> -alias char-major-81-1 mydriver
> >> -alias char-major-81-64 mydriver  
> >> -options mydriver video_nr=0,1 radio_nr=0,1   
> >> +options mydriver video_nr=0,1 radio_nr=0,1
> >>  
> >> -
> >> -  
> >> -When an application attempts to open a device
> >> -special file with major number 81 and minor number 0, 1, or 64, load
> >> -"mydriver" (and the "videodev" module it depends upon).
> >> -  
> >> -  
> >> -Register the first two video capture devices with
> >> -minor number 0 and 1 (base number is 0), the first two radio device
> >> -with minor number 64 and 65 (base 64).
> >> -  
> >> -
> >> -   When no minor number is given as module
> >> -option the driver supplies a default. 
> >> -recommends the base minor numbers to be used for the various device
> >> -types. Obviously minor numbers must be unique. When the number is
> >> -already in use the offending device will not be
> >> -registered. 
> >> -
> >> -  By convention system administrators create various
> >> -character device speci

Re: [PATCH] em28xx: push mutex down to extensions on .fini callback


Tested-by: Antti Palosaari 

regards
Antti

On 13.01.2014 08:12, Mauro Carvalho Chehab wrote:

Avoid circular mutex lock by pushing the dev->lock to the .fini
callback on each extension.

As em28xx-dvb, em28xx-alsa and em28xx-rc have their own data
structures, and don't touch at the common structure during .fini,
only em28xx-v4l needs to be locked.

[   90.994317] ==
[   90.994356] [ INFO: possible circular locking dependency detected ]
[   90.994395] 3.13.0-rc1+ #24 Not tainted
[   90.994427] ---
[   90.994458] khubd/54 is trying to acquire lock:
[   90.994490]  (&card->controls_rwsem){.+}, at: [] 
snd_ctl_dev_free+0x28/0x60 [snd]
[   90.994656]
[   90.994656] but task is already holding lock:
[   90.994688]  (&dev->lock){+.+.+.}, at: [] 
em28xx_close_extension+0x31/0x90 [em28xx]
[   90.994843]
[   90.994843] which lock already depends on the new lock.
[   90.994843]
[   90.994874]
[   90.994874] the existing dependency chain (in reverse order) is:
[   90.994905]
-> #1 (&dev->lock){+.+.+.}:
[   90.995057][] __lock_acquire+0xb43/0x1330
[   90.995121][] lock_acquire+0xa2/0x120
[   90.995182][] mutex_lock_nested+0x5c/0x3c0
[   90.995245][] em28xx_vol_put_mute+0x1ba/0x1d0 
[em28xx_alsa]
[   90.995309][] snd_ctl_elem_write+0xfd/0x140 [snd]
[   90.995376][] snd_ctl_ioctl+0xe2/0x810 [snd]
[   90.995442][] do_vfs_ioctl+0x300/0x520
[   90.995504][] SyS_ioctl+0x81/0xa0
[   90.995568][] system_call_fastpath+0x16/0x1b
[   90.995630]
-> #0 (&card->controls_rwsem){.+}:
[   90.995780][] check_prevs_add+0x947/0x950
[   90.995841][] __lock_acquire+0xb43/0x1330
[   90.995901][] lock_acquire+0xa2/0x120
[   90.995962][] down_write+0x3b/0xa0
[   90.996022][] snd_ctl_dev_free+0x28/0x60 [snd]
[   90.996088][] snd_device_free+0x65/0x140 [snd]
[   90.996154][] snd_device_free_all+0x61/0xa0 [snd]
[   90.996219][] snd_card_do_free+0x14/0x130 [snd]
[   90.996283][] snd_card_free+0x84/0x90 [snd]
[   90.996349][] em28xx_audio_fini+0x97/0xb0 
[em28xx_alsa]
[   90.996411][] em28xx_close_extension+0x56/0x90 
[em28xx]
[   90.996475][] em28xx_usb_disconnect+0x79/0x90 
[em28xx]
[   90.996539][] usb_unbind_interface+0x67/0x1d0
[   90.996620][] __device_release_driver+0x7f/0xf0
[   90.996682][] device_release_driver+0x25/0x40
[   90.996742][] bus_remove_device+0x11c/0x1a0
[   90.996801][] device_del+0x136/0x1d0
[   90.996863][] usb_disable_device+0xb0/0x290
[   90.996923][] usb_disconnect+0xb5/0x1d0
[   90.996984][] hub_port_connect_change+0xd6/0xad0
[   90.997044][] hub_events+0x313/0x9b0
[   90.997105][] hub_thread+0x35/0x170
[   90.997165][] kthread+0xff/0x120
[   90.997226][] ret_from_fork+0x7c/0xb0
[   90.997287]
[   90.997287] other info that might help us debug this:
[   90.997287]
[   90.997318]  Possible unsafe locking scenario:
[   90.997318]
[   90.997348]CPU0CPU1
[   90.997378]
[   90.997408]   lock(&dev->lock);
[   90.997497]lock(&card->controls_rwsem);
[   90.997607]lock(&dev->lock);
[   90.997697]   lock(&card->controls_rwsem);
[   90.997786]
[   90.997786]  *** DEADLOCK ***
[   90.997786]
[   90.997817] 5 locks held by khubd/54:
[   90.997847]  #0:  (&__lockdep_no_validate__){..}, at: 
[] hub_events+0xb4/0x9b0
[   90.998025]  #1:  (&__lockdep_no_validate__){..}, at: 
[] usb_disconnect+0x66/0x1d0
[   90.998204]  #2:  (&__lockdep_no_validate__){..}, at: 
[] device_release_driver+0x1d/0x40
[   90.998383]  #3:  (em28xx_devlist_mutex){+.+.+.}, at: [] 
em28xx_close_extension+0x27/0x90 [em28xx]
[   90.998567]  #4:  (&dev->lock){+.+.+.}, at: [] 
em28xx_close_extension+0x31/0x90 [em28xx]

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-core.c  | 2 --
  drivers/media/usb/em28xx/em28xx-video.c | 4 
  2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-core.c 
b/drivers/media/usb/em28xx/em28xx-core.c
index b6dc3327c51c..898fb9bd88a2 100644
--- a/drivers/media/usb/em28xx/em28xx-core.c
+++ b/drivers/media/usb/em28xx/em28xx-core.c
@@ -1099,12 +1099,10 @@ void em28xx_close_extension(struct em28xx *dev)
const struct em28xx_ops *ops = NULL;

mutex_lock(&em28xx_devlist_mutex);
-   mutex_lock(&dev->lock);
list_for_each_entry(ops, &em28xx_extension_devlist, next) {
if (ops->fini)
ops->fini(dev);
}
-   mutex_unlock(&dev->lock);
list_del(&dev->devlist);
mutex_unlock(&em28xx_devlist_mutex);
  }
diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
b/drivers/media/usb/em28xx/e

Re: [PATCH 0/7] Fix remaining issues with em28xx device removal

Em Mon, 13 Jan 2014 19:30:24 +0200
Antti Palosaari  escreveu:

> On 13.01.2014 01:00, Mauro Carvalho Chehab wrote:
> > Even after Frank's series, there are several issues with device module
> > removal.
> >
> > This series fix those issues, by use kref to deallocate the common
> > data (struct em28xx *dev).
> >
> > It also fixes a circular deppendency inside em28xx-audio.
> >
> > Mauro Carvalho Chehab (7):
> >em28xx-audio: fix return code on device disconnect
> >em28xx-audio: simplify error handling
> >em28xx: Only deallocate struct em28xx after finishing all extensions
> >em28xx-audio: disconnect before freeing URBs
> >em28xx-audio: remove a deplock circular dependency
> >em28xx: print a message at disconnect
> >em28xx: Fix usb diconnect logic
> >
> >   drivers/media/usb/em28xx/em28xx-audio.c | 47 
> > -
> >   drivers/media/usb/em28xx/em28xx-cards.c | 41 +---
> >   drivers/media/usb/em28xx/em28xx-dvb.c   |  7 -
> >   drivers/media/usb/em28xx/em28xx-input.c | 10 ++-
> >   drivers/media/usb/em28xx/em28xx-video.c | 13 -
> >   drivers/media/usb/em28xx/em28xx.h   |  9 +--
> >   6 files changed, 76 insertions(+), 51 deletions(-)
> >
> 
> 
> 
> Tested-by: Antti Palosaari 
> 
> 
> I tested quite many em28xx devices and it seems to work very well.
> 
> However, there is that (it looks new) error dump coming after device is 
> unplugged.

That's likely because now the lockdep code is able to go one step further
on their tests.

> tammi 13 18:50:56 localhost.localdomain kernel: usb 8-2: USB disconnect, 
> device number 2
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
> em2884 #0
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
> video extension
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: V4L2 device 
> video0 deregistered
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
> audio extension
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
> DVB extension
> tammi 13 18:50:56 localhost.localdomain kernel: xc5000 6-0061: 
> destroying instance
> tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
> input extensionINFO: trying to register non-static key.
> tammi 13 18:50:56 localhost.localdomain kernel: the code is fine but 
> needs lockdep annotation.
> tammi 13 18:50:56 localhost.localdomain kernel: turning off the locking 
> correctness validator.

I suspect that the reason is because we're not flushing/canceling the
pending work on em28xx-alsa and em28xx-rc.

I can't reproduce it here, but could you please check if this patch fixes
it?

http://git.linuxtv.org/mchehab/experimental.git/commitdiff/144f41066bdab280869e309f76f7a42ad5b2be72

> tammi 13 18:50:56 localhost.localdomain kernel: CPU: 3 PID: 34 Comm: 
> khubd Tainted: G   O 3.13.0-rc1+ #79
> tammi 13 18:50:56 localhost.localdomain kernel: Hardware name: System 
> manufacturer System Product Name/M5A78L-M/USB3, BIOS 180111/12/2013
> tammi 13 18:50:56 localhost.localdomain kernel:  88030da1a8a0 
> 88030dbb99a8 816b8da9 0002
> tammi 13 18:50:56 localhost.localdomain kernel:  88030dbb99b8 
> 816b285c 88030dbb9a28 810bb9ae
> tammi 13 18:50:56 localhost.localdomain kernel:  810b9bc9 
> 0007810b648d 88030da1a8a0 810cbe27
> tammi 13 18:50:56 localhost.localdomain kernel: Call Trace:
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> dump_stack+0x4d/0x66
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> register_lock_class.part.40+0x38/0x3c
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> __lock_acquire+0x9fe/0xc40
> tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
> mark_held_locks+0xb9/0x140
> tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
> vprintk_emit+0x1d7/0x5e0
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> lock_acquire+0xb0/0x150
> tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
> flush_work+0x5/0x60
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> flush_work+0x36/0x60
> tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
> flush_work+0x5/0x60
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> __cancel_work_timer+0x8a/0x120
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> cancel_delayed_work_sync+0x13/0x20
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> em28xx_ir_fini+0x48/0xc0 [em28xx_rc]
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> em28xx_close_extension+0x3e/0x70 [em28xx]
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> em28xx_usb_disconnect+0x60/0x80 [em28xx]
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> usb_unbind_interface+0x67/0x1d0
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> __device_release_driver+0x7f/0xf0
> tammi 13 18:50:56 localhost.localdomain kernel:  [] 
> device_release_driv

Re: [PATCH 0/7] Fix remaining issues with em28xx device removal


On 13.01.2014 01:00, Mauro Carvalho Chehab wrote:

Even after Frank's series, there are several issues with device module
removal.

This series fix those issues, by use kref to deallocate the common
data (struct em28xx *dev).

It also fixes a circular deppendency inside em28xx-audio.

Mauro Carvalho Chehab (7):
   em28xx-audio: fix return code on device disconnect
   em28xx-audio: simplify error handling
   em28xx: Only deallocate struct em28xx after finishing all extensions
   em28xx-audio: disconnect before freeing URBs
   em28xx-audio: remove a deplock circular dependency
   em28xx: print a message at disconnect
   em28xx: Fix usb diconnect logic

  drivers/media/usb/em28xx/em28xx-audio.c | 47 -
  drivers/media/usb/em28xx/em28xx-cards.c | 41 +---
  drivers/media/usb/em28xx/em28xx-dvb.c   |  7 -
  drivers/media/usb/em28xx/em28xx-input.c | 10 ++-
  drivers/media/usb/em28xx/em28xx-video.c | 13 -
  drivers/media/usb/em28xx/em28xx.h   |  9 +--
  6 files changed, 76 insertions(+), 51 deletions(-)





Tested-by: Antti Palosaari 


I tested quite many em28xx devices and it seems to work very well.

However, there is that (it looks new) error dump coming after device is 
unplugged.


tammi 13 18:50:56 localhost.localdomain kernel: usb 8-2: USB disconnect, 
device number 2
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
em2884 #0
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
video extension
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: V4L2 device 
video0 deregistered
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
audio extension
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
DVB extension
tammi 13 18:50:56 localhost.localdomain kernel: xc5000 6-0061: 
destroying instance
tammi 13 18:50:56 localhost.localdomain kernel: em2884 #0: Disconnecting 
input extensionINFO: trying to register non-static key.
tammi 13 18:50:56 localhost.localdomain kernel: the code is fine but 
needs lockdep annotation.
tammi 13 18:50:56 localhost.localdomain kernel: turning off the locking 
correctness validator.
tammi 13 18:50:56 localhost.localdomain kernel: CPU: 3 PID: 34 Comm: 
khubd Tainted: G   O 3.13.0-rc1+ #79
tammi 13 18:50:56 localhost.localdomain kernel: Hardware name: System 
manufacturer System Product Name/M5A78L-M/USB3, BIOS 180111/12/2013
tammi 13 18:50:56 localhost.localdomain kernel:  88030da1a8a0 
88030dbb99a8 816b8da9 0002
tammi 13 18:50:56 localhost.localdomain kernel:  88030dbb99b8 
816b285c 88030dbb9a28 810bb9ae
tammi 13 18:50:56 localhost.localdomain kernel:  810b9bc9 
0007810b648d 88030da1a8a0 810cbe27

tammi 13 18:50:56 localhost.localdomain kernel: Call Trace:
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
dump_stack+0x4d/0x66
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
register_lock_class.part.40+0x38/0x3c
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
__lock_acquire+0x9fe/0xc40
tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
mark_held_locks+0xb9/0x140
tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
vprintk_emit+0x1d7/0x5e0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
lock_acquire+0xb0/0x150
tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
flush_work+0x5/0x60
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
flush_work+0x36/0x60
tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
flush_work+0x5/0x60
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
__cancel_work_timer+0x8a/0x120
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
cancel_delayed_work_sync+0x13/0x20
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
em28xx_ir_fini+0x48/0xc0 [em28xx_rc]
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
em28xx_close_extension+0x3e/0x70 [em28xx]
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
em28xx_usb_disconnect+0x60/0x80 [em28xx]
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
usb_unbind_interface+0x67/0x1d0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
__device_release_driver+0x7f/0xf0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
device_release_driver+0x25/0x40
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
bus_remove_device+0x11c/0x1a0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
device_del+0x136/0x1d0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
usb_disable_device+0xb0/0x290
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
usb_disconnect+0xb5/0x1d0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
hub_port_connect_change+0xd6/0xad0
tammi 13 18:50:56 localhost.localdomain kernel:  [] ? 
usb_control_msg+0xd4/0x110
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
hub_events+0x313/0x9b0
tammi 13 18:50:56 localhost.localdomain kernel:  [] 
hub_thread+0x35/0x190
tammi 13 18:50:56 localhost.localdomain kernel:

Re: [PATCH 2/2] radio-usb-si4713: make si4713_register_i2c_adapter static

On 01/13/2014 02:36 PM, Mauro Carvalho Chehab wrote:
> This function isn't used nowhere outside the same .c file.
> Fixes this warning:
> 
> drivers/media/radio/si4713/radio-usb-si4713.c:418:5: warning: no previous 
> prototype for 'si4713_register_i2c_adapter' [-Wmissing-prototypes]
>  int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
>  ^
> 
> Cc: Hans Verkuil 

Acked-by: Hans Verkuil 

Regards,

Hans

> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/media/radio/si4713/radio-usb-si4713.c 
> b/drivers/media/radio/si4713/radio-usb-si4713.c
> index d97884494d04..f1e640d71188 100644
> --- a/drivers/media/radio/si4713/radio-usb-si4713.c
> +++ b/drivers/media/radio/si4713/radio-usb-si4713.c
> @@ -415,7 +415,7 @@ static struct i2c_adapter si4713_i2c_adapter_template = {
>   .algo   = &si4713_algo,
>  };
>  
> -int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
> +static int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
>  {
>   radio->i2c_adapter = si4713_i2c_adapter_template;
>   /* set up sysfs linkage to our parent device */
> 

--
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/2] em28xx: fix usb alternate setting for analog and digital video endpoints > 0


On 12.01.2014 18:35, Mauro Carvalho Chehab wrote:

Em Sat, 11 Jan 2014 14:42:29 +0100
Frank Schäfer  escreveu:


The current code assumes that the analog + digital video endpoints are always at
interface number 0 when changing the alternate setting.
This seems to work fine for most existing devices.
However, at least the SpeedLink VAD Laplace webcam has the video endpoint on
interface number 3 (which fortunately doesn't cause any trouble because ist uses
bulk transfers only).
We already consider the actual the interface number for audio endpoints, so
rename the the audio_ifnum variable and use it for all device types.
Also get get rid of a pointless (ifnum < 0) in em28xx-audio.

Signed-off-by: Frank Schäfer 
---
  drivers/media/usb/em28xx/em28xx-audio.c |   10 +-
  drivers/media/usb/em28xx/em28xx-cards.c |2 +-
  drivers/media/usb/em28xx/em28xx-dvb.c   |2 +-
  drivers/media/usb/em28xx/em28xx-video.c |2 +-
  drivers/media/usb/em28xx/em28xx.h   |3 +--
  5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 30ee389..b2ae954 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -243,15 +243,15 @@ static int snd_em28xx_capture_open(struct 
snd_pcm_substream *substream)
}
  
  	runtime->hw = snd_em28xx_hw_capture;

-   if ((dev->alt == 0 || dev->audio_ifnum) && dev->adev.users == 0) {
-   if (dev->audio_ifnum)
+   if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {

Lets keep it named as "audio_ifnum". Ok, this is equal to the video_ifnum
for several devices, but on em2861 (and other em2xx1 devices), the audio
interface is different.

Uhm, that doesn't make sense.
Why do you want to call it audio_ifnum although it is used for 
audio/video/dvb ???



Also, as we're trying to get rid of hardcoded values, it also makes sense
to store the alternate used for the audio endpoint.

We already to that: dev->alt.

I think there is some general misunderstanding here.
There is always only a single interface number and current alternate 
setting per driver instance.
If all endpoints are on the same interface, there's only a sibgle driver 
instance.
If the audio endpoints are on a separate interface, there will be two 
driver instances (each of them using their own device struct etc.).



Btw, I'm thinking on rework on this entire code, adding a logic that would
handle properly the interface used by both audio and video (when this is
the case) to not just select alt = 7, but to dynamically allocate the proper
value for it, by taking into account the number of allocated audio URBs.

alt=7 is actually bug that needs to be fixed.
It messes up the alt settings made by the video part.
This just didn't show up so far, because the video stream is almost 
always started after the audio stream.


Do you know any devices with audio endpoints 0x83 on the same interface 
as video/dvb ?
If yes, can you check their alt settings ? I'm pretty sure the audio 
endpoint uses the same wMaxPacketSize and bInterval values at all alt 
settings.

Otherwise things would become very complicated...



For now, could you please rebase this patch, keeping the interface named
as "audio_ifnum"?

Thanks!
Mauro


+   if (dev->ifnum)
dev->alt = 1;
else
dev->alt = 7;
  
  		dprintk("changing alternate number on interface %d to %d\n",

-   dev->audio_ifnum, dev->alt);
-   usb_set_interface(dev->udev, dev->audio_ifnum, dev->alt);
+   dev->ifnum, dev->alt);
+   usb_set_interface(dev->udev, dev->ifnum, dev->alt);
  
  		/* Sets volume, mute, etc */

dev->mute = 0;
@@ -625,7 +625,7 @@ static int em28xx_audio_init(struct em28xx *dev)
const int sb_size = EM28XX_NUM_AUDIO_PACKETS *
EM28XX_AUDIO_MAX_PACKET_SIZE;
  
-	if (!dev->has_alsa_audio || dev->audio_ifnum < 0) {

+   if (!dev->has_alsa_audio) {
/* This device does not support the extension (in this case
   the device is expecting the snd-usb-audio module or
   doesn't have analog audio support at all) */
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 39cf49c..b2cfd5d 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3224,7 +3224,7 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
dev->has_alsa_audio = has_audio;
dev->audio_mode.has_audio = has_audio;
dev->has_video = has_video;
-   dev->audio_ifnum = ifnum;
+   dev->ifnum = ifnum;
  
  	/* Checks if audio is provided by some interface */

for (i = 0; i < udev->config->desc.bNumInterfaces; i++) {
diff --git a/drivers/media/usb/em28xx/em28xx

Re: [PATCH 2/2] em28xx: fix check for audio only usb interfaces when changing the usb alternate setting


On 12.01.2014 18:37, Mauro Carvalho Chehab wrote:

Em Sat, 11 Jan 2014 14:42:30 +0100
Frank Schäfer  escreveu:


Previously, we've been assuming that the video endpoints are always at usb
interface 0. Hence, if vendor audio endpoints are provided at a separate
interface, they were supposed to be at interface number > 0.
Instead of checking for (interface number > 0) to determine if an interface is a
pure audio interface, dev->is_audio_only should be checked.

Signed-off-by: Frank Schäfer 
---
  drivers/media/usb/em28xx/em28xx-audio.c |   15 +--
  1 Datei geändert, 13 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index b2ae954..18b745f 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -243,11 +243,22 @@ static int snd_em28xx_capture_open(struct 
snd_pcm_substream *substream)
}
  
  	runtime->hw = snd_em28xx_hw_capture;

-   if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {
-   if (dev->ifnum)
+   if (dev->adev.users == 0 && (dev->alt == 0 || dev->is_audio_only)) {
+   if (dev->is_audio_only)
+   /* vendor audio is on a separate interface */
dev->alt = 1;
else
+   /* vendor audio is on the same interface as video */
dev->alt = 7;
+   /*
+* FIXME: The intention seems to be to select the alt
+* setting with the largest wMaxPacketSize for the video
+* endpoint.
+* At least dev->alt and dev->dvb_alt_isoc should be
+* used instead, but we should probably not touch it at
+* all if it is already >0, because wMaxPacketSize of
+* the audio endpoints seems to be the same for all.
+*/

Actually, it should take into account only the analog case, since, in
digital mode, the audio comes via the MPEG stream instead.

Yes, of course you are absolutely right.
I will fix the comment.



Ok, it makes sense to return -EBUSY if one tries to use it while using
DVB.

  
  		dprintk("changing alternate number on interface %d to %d\n",

dev->ifnum, dev->alt);




--
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: Kworld 330u broken


On 12.01.2014 18:40, Mauro Carvalho Chehab wrote:

Em Sun, 12 Jan 2014 09:53:43 -0700
Chris Lee  escreveu:


Thanks guys, appreciate it :) As soon as I see the patch fly by I'll
test it out, or you can email me directly if you want it tested before
it goes to the list. Either way Im flexible.

UDL

On Sun, Jan 12, 2014 at 9:50 AM, Mauro Carvalho Chehab
 wrote:

Em Sun, 12 Jan 2014 17:43:28 +0100
Frank Schäfer  escreveu:


On 10.01.2014 05:08, Chris Lee wrote:

Im not sure exactly when it broke but alot of changes have happened in
em28xx lately and they've broken my Kworld 330u. The issue is that

ctl->demod = XC3028_FE_CHINA;
ctl->fname = XC2028_DEFAULT_FIRMWARE;
cfg.ctrl  = &ctl;

are no longer being set, this causes xc2028_attach

if (cfg->ctrl)
xc2028_set_config(fe, cfg->ctrl);

to never get called. Therefore never load the firmware. Ive attached
my logs to show you what I mean.

I quickly hacked up a patch, my tree is quite different from V4L's now
so the line numbers may not lineup anymore, and Im sure you guys wont
like it anyhow lol

Chris Lee

Hi Chris,

thank you for testing and the patch !
The suggested changes in em28xx_attach_xc3028() look good, but instead
of introducing a second copy of em28xx_setup_xc3028() in em28xx-dvb,
we should just move this function from the v4l extension back to the core.

Mauro, I can create a patch, but I assume there is already enough
pending em28xx stuff that requires rebasing, so I assume it's easier for
you to do it yourself.
Let me know if I can assist you.

Yes, I can handle it.

Regards,
Mauro

Patch follows.

Regards,
Mauro

From: Mauro Carvalho Chehab 

[media] em28xx: fix xc3028 demod and firmware setup on DVB

Now that em28xx can be compiled without V4L support, we should
call em28xx_setup_xc3028() on both em28xx-v4l and em28xx-dvb
modules.

Reported-by: Chris Lee 
Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 39cf49c44e10..6efb9029381b 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2768,6 +2768,55 @@ static void em28xx_card_setup(struct em28xx *dev)
dev->tuner_type = tuner;
  }
  
+void em28xx_setup_xc3028(struct em28xx *dev, struct xc2028_ctrl *ctl)

+{
+   memset(ctl, 0, sizeof(*ctl));
+
+   ctl->fname   = XC2028_DEFAULT_FIRMWARE;
+   ctl->max_len = 64;
+   ctl->mts = em28xx_boards[dev->model].mts_firmware;
+
+   switch (dev->model) {
+   case EM2880_BOARD_EMPIRE_DUAL_TV:
+   case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900:
+   case EM2882_BOARD_TERRATEC_HYBRID_XS:
+   ctl->demod = XC3028_FE_ZARLINK456;
+   break;
+   case EM2880_BOARD_TERRATEC_HYBRID_XS:
+   case EM2880_BOARD_TERRATEC_HYBRID_XS_FR:
+   case EM2881_BOARD_PINNACLE_HYBRID_PRO:
+   ctl->demod = XC3028_FE_ZARLINK456;
+   break;
+   case EM2880_BOARD_HAUPPAUGE_WINTV_HVR_900_R2:
+   case EM2882_BOARD_PINNACLE_HYBRID_PRO_330E:
+   ctl->demod = XC3028_FE_DEFAULT;
+   break;
+   case EM2880_BOARD_AMD_ATI_TV_WONDER_HD_600:
+   ctl->demod = XC3028_FE_DEFAULT;
+   ctl->fname = XC3028L_DEFAULT_FIRMWARE;
+   break;
+   case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_850:
+   case EM2883_BOARD_HAUPPAUGE_WINTV_HVR_950:
+   case EM2880_BOARD_PINNACLE_PCTV_HD_PRO:
+   /* FIXME: Better to specify the needed IF */
+   ctl->demod = XC3028_FE_DEFAULT;
+   break;
+   case EM2883_BOARD_KWORLD_HYBRID_330U:
+   case EM2882_BOARD_DIKOM_DK300:
+   case EM2882_BOARD_KWORLD_VS_DVBT:
+   ctl->demod = XC3028_FE_CHINA;
+   ctl->fname = XC2028_DEFAULT_FIRMWARE;
+   break;
+   case EM2882_BOARD_EVGA_INDTUBE:
+   ctl->demod = XC3028_FE_CHINA;
+   ctl->fname = XC3028L_DEFAULT_FIRMWARE;
+   break;
+   default:
+   ctl->demod = XC3028_FE_OREN538;
+   }
+}
+EXPORT_SYMBOL_GPL(em28xx_setup_xc3028);
+
  static void request_module_async(struct work_struct *work)
  {
struct em28xx *dev = container_of(work,
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 5c6be66ac858..7dba17576edf 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -828,11 +828,16 @@ static int em28xx_attach_xc3028(u8 addr, struct em28xx 
*dev)
  {
struct dvb_frontend *fe;
struct xc2028_config cfg;
+   struct xc2028_ctrl ctl;
  
  	memset(&cfg, 0, sizeof(cfg));

cfg.i2c_adap  = &dev->i2c_adap[dev->def_i2c_bus];
cfg.i2c_addr  = addr;
  
+	memset(&ctl, 0, sizeof(ctl));

+   em28xx_setup_xc3028(dev, &ctl);
+   cfg.ctrl  = &ctl;
+
if (!dev->dvb->fe[0]) {
em28xx_errdev("/2: dvb frontend not attached. "
"Ca

Re: [PATCH 1/7] em28xx-audio: fix return code on device disconnect


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

Alsa has an special non-negative return code to indicate device removal
at snd_em28xx_capture_pointer(). Use it, instead of an error code.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-audio.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index f3e320098f79..47766b796acb 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -434,7 +434,7 @@ static snd_pcm_uframes_t snd_em28xx_capture_pointer(struct 
snd_pcm_substream
  
  	dev = snd_pcm_substream_chip(substream);

if (dev->disconnected)
-   return -ENODEV;
+   return SNDRV_PCM_POS_XRUN;
  
  	spin_lock_irqsave(&dev->adev.slock, flags);

hwptr_done = dev->adev.hwptr_done_capture;


Reviewed-by: Frank Schäfer 
--
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 2/7] em28xx-audio: simplify error handling


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

Cleanup the error handling code at em28xx-audio init.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-audio.c | 27 ++-
  1 file changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 47766b796acb..97d9105e6830 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -893,10 +893,8 @@ static int em28xx_audio_init(struct em28xx *dev)
adev->udev = dev->udev;
  
  	err = snd_pcm_new(card, "Em28xx Audio", 0, 0, 1, &pcm);

-   if (err < 0) {
-   snd_card_free(card);
-   return err;
-   }
+   if (err < 0)
+   goto card_free;
  
  	snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_em28xx_pcm_capture);

pcm->info_flags = 0;
@@ -927,20 +925,23 @@ static int em28xx_audio_init(struct em28xx *dev)
}
  
  	err = em28xx_audio_urb_init(dev);

-   if (err) {
-   snd_card_free(card);
-   return -ENODEV;
-   }
+   if (err)
+   goto card_free;
  
  	err = snd_card_register(card);

-   if (err < 0) {
-   em28xx_audio_free_urb(dev);
-   snd_card_free(card);
-   return err;
-   }
+   if (err < 0)
+   goto urb_free;
  
  	em28xx_info("Audio extension successfully initialized\n");

return 0;
+
+urb_free:
+   em28xx_audio_free_urb(dev);
+
+card_free:
+   snd_card_free(card);
+
+   return err;
  }
  
  static int em28xx_audio_fini(struct em28xx *dev)

Reviewed-by: Frank Schäfer 

--
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 4/7] em28xx-audio: disconnect before freeing URBs


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

URBs might be in usage. Disconnect the device before freeing
them.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-audio.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 8e959dae8358..cdc2fcf3e05e 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -958,6 +958,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
return 0;
}
  
+	snd_card_disconnect(dev->adev.sndcard);

em28xx_audio_free_urb(dev);
  
  	if (dev->adev.sndcard) {


Reviewed-by: Frank Schäfer 

--
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/7] sched: allow try_to_wake_up to be used internally outside of core.c

2014-01-13 Thread Colin Cross

On Mon, Jan 13, 2014 at 4:31 AM, Maarten Lankhorst
 wrote:
> The kernel fence implementation doesn't use event queues, but needs
> to perform the same wake up. The symbol is not exported, since the
> fence implementation is not built as a module.
>
> Signed-off-by: Maarten Lankhorst 
> ---
>  include/linux/wait.h |1 +
>  kernel/sched/core.c  |2 +-
>  2 files changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/include/linux/wait.h b/include/linux/wait.h
> index eaa00b10abaa..c54e3ef50134 100644
> --- a/include/linux/wait.h
> +++ b/include/linux/wait.h
> @@ -12,6 +12,7 @@
>  typedef struct __wait_queue wait_queue_t;
>  typedef int (*wait_queue_func_t)(wait_queue_t *wait, unsigned mode, int 
> flags, void *key);
>  int default_wake_function(wait_queue_t *wait, unsigned mode, int flags, void 
> *key);
> +int try_to_wake_up(struct task_struct *p, unsigned int state, int 
> wake_flags);
>
>  struct __wait_queue {
> unsigned intflags;
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index a88f4a485c5e..f41d317042dd 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1578,7 +1578,7 @@ static void ttwu_queue(struct task_struct *p, int cpu)
>   * Return: %true if @p was woken up, %false if it was already running.
>   * or @state didn't match @p's state.
>   */
> -static int
> +int
>  try_to_wake_up(struct task_struct *p, unsigned int state, int wake_flags)
>  {
> unsigned long flags;
>

wake_up_state is already available in linux/sched.h, can you use that?
--
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 6/7] em28xx: print a message at disconnect


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

That helps to identify if something fails and explain why em28xx
struct is not freed (if it ever happens).

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-audio.c | 2 ++
  drivers/media/usb/em28xx/em28xx-dvb.c   | 2 ++
  drivers/media/usb/em28xx/em28xx-input.c | 2 ++
  drivers/media/usb/em28xx/em28xx-video.c | 2 ++
  4 files changed, 8 insertions(+)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 5e16fcf18cac..0ec4742c3ab0 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -962,6 +962,8 @@ static int em28xx_audio_fini(struct em28xx *dev)
return 0;
}
  
+	em28xx_info("Disconnecting audio extension");

+
snd_card_disconnect(dev->adev.sndcard);
em28xx_audio_free_urb(dev);
  
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c b/drivers/media/usb/em28xx/em28xx-dvb.c

index 8674ae5fce06..7ba209de57dd 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1473,6 +1473,8 @@ static int em28xx_dvb_fini(struct em28xx *dev)
return 0;
}
  
+	em28xx_info("Disconnecting DVB extension");

+
if (dev->dvb) {
struct em28xx_dvb *dvb = dev->dvb;
  
diff --git a/drivers/media/usb/em28xx/em28xx-input.c b/drivers/media/usb/em28xx/em28xx-input.c

index 33388b5922a0..bf04c5e1bd2a 100644
--- a/drivers/media/usb/em28xx/em28xx-input.c
+++ b/drivers/media/usb/em28xx/em28xx-input.c
@@ -812,6 +812,8 @@ static int em28xx_ir_fini(struct em28xx *dev)
return 0;
}
  
+	em28xx_info("Disconnecting input extension");

+
em28xx_shutdown_buttons(dev);
  
  	/* skip detach on non attached boards */

diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
b/drivers/media/usb/em28xx/em28xx-video.c
index dc10cec772ba..004fe12ceec7 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -1894,6 +1894,8 @@ static int em28xx_v4l2_fini(struct em28xx *dev)
return 0;
}
  
+	em28xx_info("Disconnecting video extension");

+
v4l2_device_disconnect(&dev->v4l2_dev);
  
  	em28xx_uninit_usb_xfer(dev, EM28XX_ANALOG_MODE);


I would say "Closing" instead of "Disconnecting". That's also how we 
call the function that calls the extensions fini() methods.


Reviewed-by: Frank Schäfer 


--
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 7/7] em28xx: Fix usb diconnect logic


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

Now that everything is extension, the usb disconnect logic should
be the same.

While here, fix the device name.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-cards.c | 7 +--
  1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index df92f417634a..8fc0a437054e 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3384,12 +3384,7 @@ static void em28xx_usb_disconnect(struct usb_interface 
*interface)
  
  	dev->disconnected = 1;
  
-	if (dev->is_audio_only) {

-   em28xx_close_extension(dev);
-   return;
-   }
-
-   em28xx_info("disconnecting %s\n", dev->vdev->name);
+   em28xx_info("Disconnecting %s\n", dev->name);
  
  	flush_request_modules(dev);

Great.
I noticed this buggy section but finally forgot to remove it.

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

Re: [PATCH 3/7] em28xx: Only deallocate struct em28xx after finishing all extensions


On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:

We can't free struct em28xx while one of the extensions is still
using it.

So, add a kref() to control it, freeing it only after the
extensions fini calls.

Signed-off-by: Mauro Carvalho Chehab 
---
  drivers/media/usb/em28xx/em28xx-audio.c |  5 -
  drivers/media/usb/em28xx/em28xx-cards.c | 34 -
  drivers/media/usb/em28xx/em28xx-dvb.c   |  5 -
  drivers/media/usb/em28xx/em28xx-input.c |  8 +++-
  drivers/media/usb/em28xx/em28xx-video.c | 11 +--
  drivers/media/usb/em28xx/em28xx.h   |  9 +++--
  6 files changed, 44 insertions(+), 28 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index 97d9105e6830..8e959dae8358 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -878,6 +878,8 @@ static int em28xx_audio_init(struct em28xx *dev)
  
  	em28xx_info("Binding audio extension\n");
  
+	kref_get(&dev->ref);

+
printk(KERN_INFO "em28xx-audio.c: Copyright (C) 2006 Markus "
 "Rechberger\n");
printk(KERN_INFO
@@ -949,7 +951,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
if (dev == NULL)
return 0;
  
-	if (dev->has_alsa_audio != 1) {

+   if (!dev->has_alsa_audio) {
/* This device does not support the extension (in this case
   the device is expecting the snd-usb-audio module or
   doesn't have analog audio support at all) */
@@ -963,6 +965,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
dev->adev.sndcard = NULL;
}
  
+	kref_put(&dev->ref, em28xx_free_device);

return 0;
  }
  
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c b/drivers/media/usb/em28xx/em28xx-cards.c

index 3b332d527ccb..df92f417634a 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -2867,16 +2867,18 @@ static void flush_request_modules(struct em28xx *dev)
flush_work(&dev->request_module_wk);
  }
  
-/*

- * em28xx_release_resources()
- * unregisters the v4l2,i2c and usb devices
- * called when the device gets disconnected or at module unload
-*/
-void em28xx_release_resources(struct em28xx *dev)
+/**
+ * em28xx_release_resources() -  unregisters the v4l2,i2c and usb devices
+ *
+ * @ref: struct kref for em28xx device
+ *
+ * This is called when all extensions and em28xx core unregisters a device
+ */
+void em28xx_free_device(struct kref *ref)
  {
-   /*FIXME: I2C IR should be disconnected */
+   struct em28xx *dev = kref_to_dev(ref);
  
-	mutex_lock(&dev->lock);

+   em28xx_info("Freeing device\n");
  
  	if (dev->def_i2c_bus)

em28xx_i2c_unregister(dev, 1);
@@ -2887,9 +2889,10 @@ void em28xx_release_resources(struct em28xx *dev)
/* Mark device as unused */
clear_bit(dev->devno, &em28xx_devused);
  
-	mutex_unlock(&dev->lock);

-};
-EXPORT_SYMBOL_GPL(em28xx_release_resources);
+   kfree(dev->alt_max_pkt_size_isoc);
+   kfree(dev);
+}
+EXPORT_SYMBOL_GPL(em28xx_free_device);
  
  /*

   * em28xx_init_dev()
@@ -3342,6 +3345,8 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
dev->dvb_xfer_bulk ? "bulk" : "isoc");
}
  
+	kref_init(&dev->ref);

+
request_modules(dev);
  
  	/* Should be the last thing to do, to avoid newer udev's to

@@ -3390,12 +3395,7 @@ static void em28xx_usb_disconnect(struct usb_interface 
*interface)
  
  	em28xx_close_extension(dev);
  
-	em28xx_release_resources(dev);

-
-   if (!dev->users) {
-   kfree(dev->alt_max_pkt_size_isoc);
-   kfree(dev);
-   }
+   kref_put(&dev->ref, em28xx_free_device);
  }
  
  static struct usb_driver em28xx_usb_driver = {

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 5ea563e3f0e4..8674ae5fce06 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1010,11 +1010,11 @@ static int em28xx_dvb_init(struct em28xx *dev)
em28xx_info("Binding DVB extension\n");
  
  	dvb = kzalloc(sizeof(struct em28xx_dvb), GFP_KERNEL);

-
if (dvb == NULL) {
em28xx_info("em28xx_dvb: memory allocation failed\n");
return -ENOMEM;
}
+   kref_get(&dev->ref);
dev->dvb = dvb;
dvb->fe[0] = dvb->fe[1] = NULL;
  
@@ -1442,6 +1442,7 @@ static int em28xx_dvb_init(struct em28xx *dev)

dvb->adapter.mfe_shared = mfe_shared;
  
  	em28xx_info("DVB extension successfully initialized\n");

+
  ret:
em28xx_set_mode(dev, EM28XX_SUSPEND);
mutex_unlock(&dev->lock);
@@ -1492,6 +1493,8 @@ static int em28xx_dvb_fini(struct em28xx *dev)
dev->dvb = NULL;
}
  
+	kref_put(&dev->ref, em28xx_free_device);

+
return 0;
  }
  
diff --git a/drivers/

Re: [PATCH 1/2] em28xx: fix usb alternate setting for analog and digital video endpoints > 0

Em Mon, 13 Jan 2014 19:29:59 +0100
Frank Schäfer  escreveu:

> On 12.01.2014 18:35, Mauro Carvalho Chehab wrote:
> > Em Sat, 11 Jan 2014 14:42:29 +0100
> > Frank Schäfer  escreveu:
> >
> >> The current code assumes that the analog + digital video endpoints are 
> >> always at
> >> interface number 0 when changing the alternate setting.
> >> This seems to work fine for most existing devices.
> >> However, at least the SpeedLink VAD Laplace webcam has the video endpoint 
> >> on
> >> interface number 3 (which fortunately doesn't cause any trouble because 
> >> ist uses
> >> bulk transfers only).
> >> We already consider the actual the interface number for audio endpoints, so
> >> rename the the audio_ifnum variable and use it for all device types.
> >> Also get get rid of a pointless (ifnum < 0) in em28xx-audio.
> >>
> >> Signed-off-by: Frank Schäfer 
> >> ---
> >>   drivers/media/usb/em28xx/em28xx-audio.c |   10 +-
> >>   drivers/media/usb/em28xx/em28xx-cards.c |2 +-
> >>   drivers/media/usb/em28xx/em28xx-dvb.c   |2 +-
> >>   drivers/media/usb/em28xx/em28xx-video.c |2 +-
> >>   drivers/media/usb/em28xx/em28xx.h   |3 +--
> >>   5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)
> >>
> >> diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
> >> b/drivers/media/usb/em28xx/em28xx-audio.c
> >> index 30ee389..b2ae954 100644
> >> --- a/drivers/media/usb/em28xx/em28xx-audio.c
> >> +++ b/drivers/media/usb/em28xx/em28xx-audio.c
> >> @@ -243,15 +243,15 @@ static int snd_em28xx_capture_open(struct 
> >> snd_pcm_substream *substream)
> >>}
> >>   
> >>runtime->hw = snd_em28xx_hw_capture;
> >> -  if ((dev->alt == 0 || dev->audio_ifnum) && dev->adev.users == 0) {
> >> -  if (dev->audio_ifnum)
> >> +  if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {
> > Lets keep it named as "audio_ifnum". Ok, this is equal to the video_ifnum
> > for several devices, but on em2861 (and other em2xx1 devices), the audio
> > interface is different.
> Uhm, that doesn't make sense.
> Why do you want to call it audio_ifnum although it is used for 
> audio/video/dvb ???

em28xx-audio only cares about the interface used by audio, and if it is
different than the one used by video, in order to switch the alternate at
the right interface.

So, you'll likely need to add a video_ifnum and an audio_ifnum, in
order to track both (eventually, we may need a dvb_ifnum in the future,
if they decide to provide a separate interface for it too).

> > Also, as we're trying to get rid of hardcoded values, it also makes sense
> > to store the alternate used for the audio endpoint.
> We already to that: dev->alt.

See below: dev->alt = 1 or dev->alt = 7.

> I think there is some general misunderstanding here.
> There is always only a single interface number and current alternate 
> setting per driver instance.
> If all endpoints are on the same interface, there's only a sibgle driver 
> instance.
> If the audio endpoints are on a separate interface, there will be two 
> driver instances (each of them using their own device struct etc.).
> 
> > Btw, I'm thinking on rework on this entire code, adding a logic that would
> > handle properly the interface used by both audio and video (when this is
> > the case) to not just select alt = 7, but to dynamically allocate the proper
> > value for it, by taking into account the number of allocated audio URBs.
> alt=7 is actually bug that needs to be fixed.

Huh? alt = 7 is a "works everytime" kind of alternate, as it has the biggest
window size. You can say that this is not optimized, making em28xx to spend
more bandwidth than needed, but this is not a bug.

> It messes up the alt settings made by the video part.

Yes, because it doesn't recalculate the bandwidth.

> This just didn't show up so far, because the video stream is almost 
> always started after the audio stream.

You can't assume that. 

Actually, it is/was common for people to start the video streaming
using some non-alsa compatible application, and then use a separate
process for audio.

See, for example (at ALSA audio with other applications):
http://www.linuxtv.org/wiki/index.php/Saa7134-alsa

I actually use this way when I want to do some tests with alsa,
stopping/restarting its stream without touching on the video one.

> Do you know any devices with audio endpoints 0x83 on the same interface 
> as video/dvb ?

Yes. HVR-950 (and HVR-900).

> If yes, can you check their alt settings ? I'm pretty sure the audio 
> endpoint uses the same wMaxPacketSize and bInterval values at all alt 
> settings.

Yes.

> Otherwise things would become very complicated...

The problem is basically the same: when a audio or video stream starts,
it will need to call some routine to determinate the alternate. Such
routine should track if both streams are active, or if just one is
active, and provide the lowest alternate that works for both (or,
in doubt, the alternate with the highest packet size, e.

When do I need to call 'v4l2_m2m_get_next_job()' in stop_streaming

2014-01-13 Thread m silverstri

Hi,

Can you please tell me when do I need to call 'v4l2_m2m_get_next_job()
in stop streaming/job_abort?

I find 2 examples of v4l2 m2m driver, they implement
stop_streaming/job_abort differently.

One call v4l2_m2m_get_next_job() in stop streaming/job_abort?

https://android.googlesource.com/kernel/exynos.git/+/6ced4b8c77c2be4f6e4c9d1216fd8b99f636569f/drivers/media/video/exynos/gsc/gsc-m2m.c

but the one one does not:

http://lxr.free-electrons.com/source/drivers/media/platform/s5p-jpeg/jpeg-core.c

Can you please tell me how can I determine if I need to call
v4l2_m2m_get_next_job() or not?

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

Re: [PATCH 3/7] em28xx: Only deallocate struct em28xx after finishing all extensions

Em Mon, 13 Jan 2014 20:02:19 +0100
Frank Schäfer  escreveu:

> On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:
> > We can't free struct em28xx while one of the extensions is still
> > using it.
> >
> > So, add a kref() to control it, freeing it only after the
> > extensions fini calls.
> >
> > Signed-off-by: Mauro Carvalho Chehab 
> > ---
> >   drivers/media/usb/em28xx/em28xx-audio.c |  5 -
> >   drivers/media/usb/em28xx/em28xx-cards.c | 34 
> > -
> >   drivers/media/usb/em28xx/em28xx-dvb.c   |  5 -
> >   drivers/media/usb/em28xx/em28xx-input.c |  8 +++-
> >   drivers/media/usb/em28xx/em28xx-video.c | 11 +--
> >   drivers/media/usb/em28xx/em28xx.h   |  9 +++--
> >   6 files changed, 44 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
> > b/drivers/media/usb/em28xx/em28xx-audio.c
> > index 97d9105e6830..8e959dae8358 100644
> > --- a/drivers/media/usb/em28xx/em28xx-audio.c
> > +++ b/drivers/media/usb/em28xx/em28xx-audio.c
> > @@ -878,6 +878,8 @@ static int em28xx_audio_init(struct em28xx *dev)
> >   
> > em28xx_info("Binding audio extension\n");
> >   
> > +   kref_get(&dev->ref);
> > +
> > printk(KERN_INFO "em28xx-audio.c: Copyright (C) 2006 Markus "
> >  "Rechberger\n");
> > printk(KERN_INFO
> > @@ -949,7 +951,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
> > if (dev == NULL)
> > return 0;
> >   
> > -   if (dev->has_alsa_audio != 1) {
> > +   if (!dev->has_alsa_audio) {
> > /* This device does not support the extension (in this case
> >the device is expecting the snd-usb-audio module or
> >doesn't have analog audio support at all) */
> > @@ -963,6 +965,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
> > dev->adev.sndcard = NULL;
> > }
> >   
> > +   kref_put(&dev->ref, em28xx_free_device);
> > return 0;
> >   }
> >   
> > diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
> > b/drivers/media/usb/em28xx/em28xx-cards.c
> > index 3b332d527ccb..df92f417634a 100644
> > --- a/drivers/media/usb/em28xx/em28xx-cards.c
> > +++ b/drivers/media/usb/em28xx/em28xx-cards.c
> > @@ -2867,16 +2867,18 @@ static void flush_request_modules(struct em28xx 
> > *dev)
> > flush_work(&dev->request_module_wk);
> >   }
> >   
> > -/*
> > - * em28xx_release_resources()
> > - * unregisters the v4l2,i2c and usb devices
> > - * called when the device gets disconnected or at module unload
> > -*/
> > -void em28xx_release_resources(struct em28xx *dev)
> > +/**
> > + * em28xx_release_resources() -  unregisters the v4l2,i2c and usb devices
> > + *
> > + * @ref: struct kref for em28xx device
> > + *
> > + * This is called when all extensions and em28xx core unregisters a device
> > + */
> > +void em28xx_free_device(struct kref *ref)
> >   {
> > -   /*FIXME: I2C IR should be disconnected */
> > +   struct em28xx *dev = kref_to_dev(ref);
> >   
> > -   mutex_lock(&dev->lock);
> > +   em28xx_info("Freeing device\n");
> >   
> > if (dev->def_i2c_bus)
> > em28xx_i2c_unregister(dev, 1);
> > @@ -2887,9 +2889,10 @@ void em28xx_release_resources(struct em28xx *dev)
> > /* Mark device as unused */
> > clear_bit(dev->devno, &em28xx_devused);
> >   
> > -   mutex_unlock(&dev->lock);
> > -};
> > -EXPORT_SYMBOL_GPL(em28xx_release_resources);
> > +   kfree(dev->alt_max_pkt_size_isoc);
> > +   kfree(dev);
> > +}
> > +EXPORT_SYMBOL_GPL(em28xx_free_device);
> >   
> >   /*
> >* em28xx_init_dev()
> > @@ -3342,6 +3345,8 @@ static int em28xx_usb_probe(struct usb_interface 
> > *interface,
> > dev->dvb_xfer_bulk ? "bulk" : "isoc");
> > }
> >   
> > +   kref_init(&dev->ref);
> > +
> > request_modules(dev);
> >   
> > /* Should be the last thing to do, to avoid newer udev's to
> > @@ -3390,12 +3395,7 @@ static void em28xx_usb_disconnect(struct 
> > usb_interface *interface)
> >   
> > em28xx_close_extension(dev);
> >   
> > -   em28xx_release_resources(dev);
> > -
> > -   if (!dev->users) {
> > -   kfree(dev->alt_max_pkt_size_isoc);
> > -   kfree(dev);
> > -   }
> > +   kref_put(&dev->ref, em28xx_free_device);
> >   }
> >   
> >   static struct usb_driver em28xx_usb_driver = {
> > diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
> > b/drivers/media/usb/em28xx/em28xx-dvb.c
> > index 5ea563e3f0e4..8674ae5fce06 100644
> > --- a/drivers/media/usb/em28xx/em28xx-dvb.c
> > +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
> > @@ -1010,11 +1010,11 @@ static int em28xx_dvb_init(struct em28xx *dev)
> > em28xx_info("Binding DVB extension\n");
> >   
> > dvb = kzalloc(sizeof(struct em28xx_dvb), GFP_KERNEL);
> > -
> > if (dvb == NULL) {
> > em28xx_info("em28xx_dvb: memory allocation failed\n");
> > return -ENOMEM;
> > }
> > +   kref_get(&dev->ref);
> > dev->dvb = dvb;
> > dvb->fe[0] = dvb->fe[1] = NULL;
> >   
> > @@

[PATCH 7/7] [media] tea575x: Fix build with ARCH=c6x

In file included from /devel/v4l/temp/include/asm-generic/page.h:23:0,
 from /devel/v4l/temp/arch/c6x/include/asm/page.h:9,
 from /devel/v4l/temp/include/asm-generic/io.h:14,
 from arch/c6x/include/generated/asm/io.h:1,
 from /devel/v4l/temp/drivers/media/radio/tea575x.c:23:
/devel/v4l/temp/arch/c6x/include/asm/setup.h:17:27: error: unknown type name 
‘phys_addr_t’
 extern int c6x_add_memory(phys_addr_t start, unsigned long size);

It seems that, on such arch, the includes from asm/ should be
after the ones from linux/.

The proper fix would be to patch the arch files, but, as
this fix is trivial, apply it. Also, we generally put the
asm includes after the linux ones, anyway.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/tea575x.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/tea575x.c b/drivers/media/radio/tea575x.c
index cef06981b7c9..7c14060a40b8 100644
--- a/drivers/media/radio/tea575x.c
+++ b/drivers/media/radio/tea575x.c
@@ -20,12 +20,12 @@
  *
  */
 
-#include 
 #include 
 #include 
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
1.8.3.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

[PATCH 2/7] [media] radio-usb-si4713: make si4713_register_i2c_adapter static

This function isn't used nowhere outside the same .c file.
Fixes this warning:

drivers/media/radio/si4713/radio-usb-si4713.c:418:5: warning: no previous 
prototype for 'si4713_register_i2c_adapter' [-Wmissing-prototypes]
 int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
 ^

Cc: Hans Verkuil 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/radio/si4713/radio-usb-si4713.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/radio/si4713/radio-usb-si4713.c 
b/drivers/media/radio/si4713/radio-usb-si4713.c
index d97884494d04..f1e640d71188 100644
--- a/drivers/media/radio/si4713/radio-usb-si4713.c
+++ b/drivers/media/radio/si4713/radio-usb-si4713.c
@@ -415,7 +415,7 @@ static struct i2c_adapter si4713_i2c_adapter_template = {
.algo   = &si4713_algo,
 };
 
-int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
+static int si4713_register_i2c_adapter(struct si4713_usb_device *radio)
 {
radio->i2c_adapter = si4713_i2c_adapter_template;
/* set up sysfs linkage to our parent device */
-- 
1.8.3.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

[PATCH 3/7] [media] dib8000: Properly represent long long integers

When compiling with avr32, it gets those errors:

drivers/media/dvb-frontends/dib8000.c: In function 'dib8000_get_stats':
drivers/media/dvb-frontends/dib8000.c:4121: warning: integer constant 
is too large for 'long' type

Fix integer representation to avoid overflow.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/dib8000.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/dib8000.c 
b/drivers/media/dvb-frontends/dib8000.c
index 481ee49e6a37..dd4a99cff3e7 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -4118,7 +4118,7 @@ static int dib8000_get_stats(struct dvb_frontend *fe, 
fe_status_t stat)
/* Get UCB measures */
dib8000_read_unc_blocks(fe, &val);
if (val < state->init_ucb)
-   state->init_ucb += 0x1L;
+   state->init_ucb += 0x1LL;
 
c->block_error.stat[0].scale = FE_SCALE_COUNTER;
c->block_error.stat[0].uvalue = val + state->init_ucb;
@@ -4128,7 +4128,7 @@ static int dib8000_get_stats(struct dvb_frontend *fe, 
fe_status_t stat)
time_us = dib8000_get_time_us(fe, -1);
 
if (time_us) {
-   blocks = 125UL * 100UL;
+   blocks = 125ULL * 100ULL;
do_div(blocks, time_us * 8 * 204);
c->block_count.stat[0].scale = FE_SCALE_COUNTER;
c->block_count.stat[0].uvalue += blocks;
@@ -4191,7 +4191,7 @@ static int dib8000_get_stats(struct dvb_frontend *fe, 
fe_status_t stat)
if (!time_us)
time_us = dib8000_get_time_us(fe, i);
if (time_us) {
-   blocks = 125UL * 100UL;
+   blocks = 125ULL * 100ULL;
do_div(blocks, time_us * 8 * 204);
c->block_count.stat[0].scale = FE_SCALE_COUNTER;
c->block_count.stat[0].uvalue += blocks;
-- 
1.8.3.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

[PATCH 4/7] [media] dib8000: Fix a few warnings when compiled for avr32

drivers/media/dvb-frontends/dib8000.c: In function 
'dib8000_get_time_us':
drivers/media/dvb-frontends/dib8000.c:3957: warning: 'interleaving' may 
be used uninitialized in this function
drivers/media/dvb-frontends/dib8000.c:3956: warning: 'rate_denum' may 
be used uninitialized in this function

Those are actually false positives, but it doesn't hurt cleaning them.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/dvb-frontends/dib8000.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/dib8000.c 
b/drivers/media/dvb-frontends/dib8000.c
index dd4a99cff3e7..1632d78a5479 100644
--- a/drivers/media/dvb-frontends/dib8000.c
+++ b/drivers/media/dvb-frontends/dib8000.c
@@ -3953,8 +3953,8 @@ static u32 dib8000_get_time_us(struct dvb_frontend *fe, 
int layer)
int ini_layer, end_layer, i;
u64 time_us, tmp64;
u32 tmp, denom;
-   int guard, rate_num, rate_denum, bits_per_symbol, nsegs;
-   int interleaving, fft_div;
+   int guard, rate_num, rate_denum = 1, bits_per_symbol, nsegs;
+   int interleaving = 0, fft_div;
 
if (layer >= 0) {
ini_layer = layer;
-- 
1.8.3.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

[PATCH 0/7] Multiple arch trivial fixups

This is a series of trivial fixups, solving a bunch of bugs reported
when compiling the media tree with allmodconfig/allyesconfig with
several architectures (47 archs).

There is one patch fixing up a compilation bug with ARCH=c6x:

 lirc_parallel: avoid name conflict on mn10300 arch

The remaining patches are warning fixups. Two of them fixes
real bugs:
dib8000: Properly represent long long integers
go7007-usb: only use go->dev after allocated

The others just make the compiler shut up.

Mauro Carvalho Chehab (7):
  [media] sh_vou: comment unused vars
  [media] radio-usb-si4713: make si4713_register_i2c_adapter static
  [media] dib8000: Properly represent long long integers
  [media] dib8000: Fix a few warnings when compiled for avr32
  [media] go7007-usb: only use go->dev after allocated
  [media] lirc_parallel: avoid name conflict on mn10300 arch
  [media] tea575x: Fix build with ARCH=c6x

 drivers/media/dvb-frontends/dib8000.c | 10 +-
 drivers/media/platform/sh_vou.c   |  9 -
 drivers/media/radio/si4713/radio-usb-si4713.c |  2 +-
 drivers/media/radio/tea575x.c |  2 +-
 drivers/staging/media/go7007/go7007-usb.c | 14 +-
 drivers/staging/media/lirc/lirc_parallel.c|  4 ++--
 drivers/staging/media/lirc/lirc_serial.c  |  4 ++--
 7 files changed, 24 insertions(+), 21 deletions(-)

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

[PATCH 5/7] [media] go7007-usb: only use go->dev after allocated

Fixes those warnings:
drivers/staging/media/go7007/go7007-usb.c: In function 
'go7007_usb_probe':
drivers/staging/media/go7007/go7007-usb.c:1060: warning: 'go' is used 
uninitialized in this function

While here, comment a code that will never run.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/go7007/go7007-usb.c | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/staging/media/go7007/go7007-usb.c 
b/drivers/staging/media/go7007/go7007-usb.c
index 58684da45e6c..1d747de6dfa6 100644
--- a/drivers/staging/media/go7007/go7007-usb.c
+++ b/drivers/staging/media/go7007/go7007-usb.c
@@ -1057,7 +1057,7 @@ static int go7007_usb_probe(struct usb_interface *intf,
char *name;
int video_pipe, i, v_urb_len;
 
-   dev_dbg(go->dev, "probing new GO7007 USB board\n");
+   printk(KERN_DEBUG "go7007-usb: probing new board\n");
 
switch (id->driver_info) {
case GO7007_BOARDID_MATRIX_II:
@@ -1097,13 +1097,16 @@ static int go7007_usb_probe(struct usb_interface *intf,
board = &board_px_tv402u;
break;
case GO7007_BOARDID_LIFEVIEW_LR192:
-   dev_err(go->dev, "The Lifeview TV Walker Ultra is not 
supported. Sorry!\n");
+   printk(KERN_ERR
+  "The Lifeview TV Walker Ultra is not supported. 
Sorry!\n");
return -ENODEV;
+#if 0
name = "Lifeview TV Walker Ultra";
board = &board_lifeview_lr192;
break;
+#endif
case GO7007_BOARDID_SENSORAY_2250:
-   dev_info(go->dev, "Sensoray 2250 found\n");
+   printk(KERN_INFO "Sensoray 2250 found\n");
name = "Sensoray 2250/2251";
board = &board_sensoray_2250;
break;
@@ -1112,8 +1115,9 @@ static int go7007_usb_probe(struct usb_interface *intf,
board = &board_ads_usbav_709;
break;
default:
-   dev_err(go->dev, "unknown board ID %d!\n",
-   (unsigned int)id->driver_info);
+   printk(KERN_ERR
+  "unknown board ID %d!\n",
+  (unsigned int)id->driver_info);
return -ENODEV;
}
 
-- 
1.8.3.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

[PATCH 6/7] [media] lirc_parallel: avoid name conflict on mn10300 arch

The "irq_handler" name is already defined there on a header
file:

/devel/v4l/temp/drivers/staging/media/lirc/lirc_parallel.c:223:13: error: 
conflicting types for ‘irq_handler’
 static void irq_handler(void *blah)
 ^
In file included from 
/devel/v4l/temp/arch/mn10300/include/asm/reset-regs.h:16:0,
 from /devel/v4l/temp/arch/mn10300/include/asm/irq.h:18,
 from /devel/v4l/temp/include/linux/irq.h:24,
 from /devel/v4l/temp/arch/mn10300/include/asm/hardirq.h:16,
 from /devel/v4l/temp/include/linux/preempt_mask.h:5,
 from /devel/v4l/temp/include/linux/sched.h:25,
 from /devel/v4l/temp/include/linux/utsname.h:5,
 from /devel/v4l/temp/arch/mn10300/include/asm/elf.h:15,
 from /devel/v4l/temp/include/linux/elf.h:4,
 from /devel/v4l/temp/include/linux/module.h:14,
 from 
/devel/v4l/temp/drivers/staging/media/lirc/lirc_parallel.c:29:
/devel/v4l/temp/arch/mn10300/include/asm/exceptions.h:107:24: note: previous 
declaration of ‘irq_handler’ was here
 extern asmlinkage void irq_handler(void);

/devel/v4l/patchwork/drivers/staging/media/lirc/lirc_serial.c:653:20: error: 
conflicting types for ‘irq_handler’
 static irqreturn_t irq_handler(int i, void *blah)
^
In file included from 
/devel/v4l/patchwork/arch/mn10300/include/asm/reset-regs.h:16:0,
 from /devel/v4l/patchwork/arch/mn10300/include/asm/irq.h:18,
 from /devel/v4l/patchwork/include/linux/irq.h:24,
 from 
/devel/v4l/patchwork/arch/mn10300/include/asm/hardirq.h:16,
 from /devel/v4l/patchwork/include/linux/preempt_mask.h:5,
 from /devel/v4l/patchwork/include/linux/sched.h:25,
 from /devel/v4l/patchwork/include/linux/utsname.h:5,
 from /devel/v4l/patchwork/arch/mn10300/include/asm/elf.h:15,
 from /devel/v4l/patchwork/include/linux/elf.h:4,
 from /devel/v4l/patchwork/include/linux/module.h:14,
 from 
/devel/v4l/patchwork/drivers/staging/media/lirc/lirc_serial.c:53:
/devel/v4l/patchwork/arch/mn10300/include/asm/exceptions.h:107:24: note: 
previous declaration of ‘irq_handler’ was here
 extern asmlinkage void irq_handler(void);

So, rename it, to avoid namespace conflicts.

This patch fixes building media drivers with allyesconfig/almodconfig on
mn10300 arch.

Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/staging/media/lirc/lirc_parallel.c | 4 ++--
 drivers/staging/media/lirc/lirc_serial.c   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/lirc/lirc_parallel.c 
b/drivers/staging/media/lirc/lirc_parallel.c
index 41d110f8bc02..0b589892351a 100644
--- a/drivers/staging/media/lirc/lirc_parallel.c
+++ b/drivers/staging/media/lirc/lirc_parallel.c
@@ -220,7 +220,7 @@ static void rbuf_write(int signal)
wptr = nwptr;
 }
 
-static void irq_handler(void *blah)
+static void lirc_lirc_irq_handler(void *blah)
 {
struct timeval tv;
static struct timeval lasttv;
@@ -659,7 +659,7 @@ static int __init lirc_parallel_init(void)
goto exit_device_put;
}
ppdevice = parport_register_device(pport, LIRC_DRIVER_NAME,
-  pf, kf, irq_handler, 0, NULL);
+  pf, kf, lirc_lirc_irq_handler, 0, 
NULL);
parport_put_port(pport);
if (ppdevice == NULL) {
pr_notice("parport_register_device() failed\n");
diff --git a/drivers/staging/media/lirc/lirc_serial.c 
b/drivers/staging/media/lirc/lirc_serial.c
index 2e3a98575d47..0be1f468771b 100644
--- a/drivers/staging/media/lirc/lirc_serial.c
+++ b/drivers/staging/media/lirc/lirc_serial.c
@@ -650,7 +650,7 @@ static void frbwrite(int l)
rbwrite(l);
 }
 
-static irqreturn_t irq_handler(int i, void *blah)
+static irqreturn_t lirc_irq_handler(int i, void *blah)
 {
struct timeval tv;
int counter, dcd;
@@ -852,7 +852,7 @@ static int lirc_serial_probe(struct platform_device *dev)
return result;
 #endif
 
-   result = request_irq(irq, irq_handler,
+   result = request_irq(irq, lirc_irq_handler,
 (share_irq ? IRQF_SHARED : 0),
 LIRC_DRIVER_NAME, (void *)&hardware);
if (result < 0) {
-- 
1.8.3.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

[PATCH 1/7] [media] sh_vou: comment unused vars

Fix two warns below, by commenting the unused code:

drivers/media/platform/sh_vou.c: In function 'sh_vou_configure_geometry':
drivers/media/platform/sh_vou.c:446:49: warning: variable 'height_max' set but 
not used [-Wunused-but-set-variable]
  unsigned int black_left, black_top, width_max, height_max,
 ^
drivers/media/platform/sh_vou.c: In function 'sh_vou_isr':
drivers/media/platform/sh_vou.c:1056:13: warning: variable 'side' set but not 
used [-Wunused-but-set-variable]
  static int side;
 ^

Cc: Guennadi Liakhovetski 
Cc: Laurent Pinchart 
Signed-off-by: Mauro Carvalho Chehab 
---
 drivers/media/platform/sh_vou.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/media/platform/sh_vou.c b/drivers/media/platform/sh_vou.c
index 65c9f180a309..e5f1d4c14f2c 100644
--- a/drivers/media/platform/sh_vou.c
+++ b/drivers/media/platform/sh_vou.c
@@ -443,7 +443,7 @@ static void sh_vou_configure_geometry(struct sh_vou_device 
*vou_dev,
  int pix_idx, int w_idx, int h_idx)
 {
struct sh_vou_fmt *fmt = vou_fmt + pix_idx;
-   unsigned int black_left, black_top, width_max, height_max,
+   unsigned int black_left, black_top, width_max,
frame_in_height, frame_out_height, frame_out_top;
struct v4l2_rect *rect = &vou_dev->rect;
struct v4l2_pix_format *pix = &vou_dev->pix;
@@ -451,10 +451,10 @@ static void sh_vou_configure_geometry(struct 
sh_vou_device *vou_dev,
 
if (vou_dev->std & V4L2_STD_525_60) {
width_max = 858;
-   height_max = 262;
+   /* height_max = 262; */
} else {
width_max = 864;
-   height_max = 312;
+   /* height_max = 312; */
}
 
frame_in_height = pix->height / 2;
@@ -1053,7 +1053,6 @@ static irqreturn_t sh_vou_isr(int irq, void *dev_id)
static unsigned long j;
struct videobuf_buffer *vb;
static int cnt;
-   static int side;
u32 irq_status = sh_vou_reg_a_read(vou_dev, VOUIR), masked;
u32 vou_status = sh_vou_reg_a_read(vou_dev, VOUSTR);
 
@@ -1081,7 +1080,7 @@ static irqreturn_t sh_vou_isr(int irq, void *dev_id)
irq_status, masked, vou_status, cnt);
 
cnt++;
-   side = vou_status & 0x1;
+   /* side = vou_status & 0x1; */
 
/* Clear only set interrupts */
sh_vou_reg_a_write(vou_dev, VOUIR, masked);
-- 
1.8.3.1

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

Re: [PATCH 5/7] em28xx-audio: remove a deplock circular dependency

Am 13.01.2014 00:00, schrieb Mauro Carvalho Chehab:
> We can't lock at pcm close, as it causes circular dependency
> lock issues with .init and .fini callbacks. So, move the code
> that puts the device on mute to the kthread.
>
> [  322.026316] ==
> [  322.026356] [ INFO: possible circular locking dependency detected ]
> [  322.026397] 3.13.0-rc1+ #24 Not tainted
> [  322.026437] ---
> [  322.026476] khubd/54 is trying to acquire lock:
> [  322.026516]  (&pcm->open_mutex){+.+.+.}, at: [] 
> snd_pcm_dev_disconnect+0x46/0x1e0 [snd_pcm]
> [  322.026727]
> but task is already holding lock:
> [  322.026767]  (register_mutex#3){+.+.+.}, at: [] 
> snd_pcm_dev_disconnect+0x24/0x1e0 [snd_pcm]
> [  322.027005]
> which lock already depends on the new lock.
>
> [  322.027045]
> the existing dependency chain (in reverse order) is:
> [  322.027084]
> -> #2 (register_mutex#3){+.+.+.}:
> [  322.027318][] __lock_acquire+0xb43/0x1330
> [  322.027401][] lock_acquire+0xa2/0x120
> [  322.027479][] mutex_lock_nested+0x5c/0x3c0
> [  322.027559][] 
> snd_pcm_dev_disconnect+0x24/0x1e0 [snd_pcm]
> [  322.027642][] 
> snd_device_disconnect+0x6a/0xf0 [snd]
> [  322.027727][] 
> snd_device_disconnect_all+0x4c/0x90 [snd]
> [  322.027814][] 
> snd_card_disconnect+0x126/0x1d0 [snd]
> [  322.027898][] snd_card_free+0x18/0x90 [snd]
> [  322.027982][] em28xx_audio_fini+0x8f/0xa0 
> [em28xx_alsa]
> [  322.028063][] 
> em28xx_close_extension+0x56/0x90 [em28xx]
> [  322.028143][] 
> em28xx_usb_disconnect+0x79/0x90 [em28xx]
> [  322.028222][] usb_unbind_interface+0x67/0x1d0
> [  322.028302][] 
> __device_release_driver+0x7f/0xf0
> [  322.028381][] device_release_driver+0x25/0x40
> [  322.028462][] bus_remove_device+0x11c/0x1a0
> [  322.028540][] device_del+0x136/0x1d0
> [  322.028619][] usb_disable_device+0xb0/0x290
> [  322.028698][] usb_disconnect+0xb5/0x1d0
> [  322.028779][] 
> hub_port_connect_change+0xd6/0xad0
> [  322.028859][] hub_events+0x313/0x9b0
> [  322.028940][] hub_thread+0x35/0x170
> [  322.029019][] kthread+0xff/0x120
> [  322.029099][] ret_from_fork+0x7c/0xb0
> [  322.029179]
> -> #1 (&dev->lock#2){+.+.+.}:
> [  322.029414][] __lock_acquire+0xb43/0x1330
> [  322.029494][] lock_acquire+0xa2/0x120
> [  322.029572][] mutex_lock_nested+0x5c/0x3c0
> [  322.029651][] 
> snd_em28xx_pcm_close+0x3e/0x100 [em28xx_alsa]
> [  322.029732][] 
> snd_pcm_release_substream.part.29+0x3f/0x90 [snd_pcm]
> [  322.029816][] snd_pcm_release+0xb0/0xd0 
> [snd_pcm]
> [  322.029900][] __fput+0xe2/0x230
> [  322.029979][] fput+0xe/0x10
> [  322.030057][] task_work_run+0x9f/0xe0
> [  322.030135][] do_notify_resume+0x61/0xa0
> [  322.030223][] int_signal+0x12/0x17
> [  322.030294]
> -> #0 (&pcm->open_mutex){+.+.+.}:
> [  322.030473][] check_prevs_add+0x947/0x950
> [  322.030546][] __lock_acquire+0xb43/0x1330
> [  322.030618][] lock_acquire+0xa2/0x120
> [  322.030689][] mutex_lock_nested+0x5c/0x3c0
> [  322.030760][] 
> snd_pcm_dev_disconnect+0x46/0x1e0 [snd_pcm]
> [  322.030835][] 
> snd_device_disconnect+0x6a/0xf0 [snd]
> [  322.030913][] 
> snd_device_disconnect_all+0x4c/0x90 [snd]
> [  322.030988][] 
> snd_card_disconnect+0x126/0x1d0 [snd]
> [  322.031067][] snd_card_free+0x18/0x90 [snd]
> [  322.031146][] em28xx_audio_fini+0x8f/0xa0 
> [em28xx_alsa]
> [  322.031220][] 
> em28xx_close_extension+0x56/0x90 [em28xx]
> [  322.031292][] 
> em28xx_usb_disconnect+0x79/0x90 [em28xx]
> [  322.031363][] usb_unbind_interface+0x67/0x1d0
> [  322.031433][] 
> __device_release_driver+0x7f/0xf0
> [  322.031503][] device_release_driver+0x25/0x40
> [  322.031573][] bus_remove_device+0x11c/0x1a0
> [  322.031643][] device_del+0x136/0x1d0
> [  322.031714][] usb_disable_device+0xb0/0x290
> [  322.031784][] usb_disconnect+0xb5/0x1d0
> [  322.031853][] 
> hub_port_connect_change+0xd6/0xad0
> [  322.031922][] hub_events+0x313/0x9b0
> [  322.031992][] hub_thread+0x35/0x170
> [  322.032062][] kthread+0xff/0x120
> [  322.032135][] ret_from_fork+0x7c/0xb0
> [  322.032205]
> other info that might help us debug this:
>
> [  322.032240] Chain exists of:
>   &pcm->open_mutex --> &dev->lock#2 --> register_

Re: [PATCH 1/2] em28xx: fix usb alternate setting for analog and digital video endpoints > 0

Am 13.01.2014 20:13, schrieb Mauro Carvalho Chehab:
> Em Mon, 13 Jan 2014 19:29:59 +0100
> Frank Schäfer  escreveu:
>
>> On 12.01.2014 18:35, Mauro Carvalho Chehab wrote:
>>> Em Sat, 11 Jan 2014 14:42:29 +0100
>>> Frank Schäfer  escreveu:
>>>
 The current code assumes that the analog + digital video endpoints are 
 always at
 interface number 0 when changing the alternate setting.
 This seems to work fine for most existing devices.
 However, at least the SpeedLink VAD Laplace webcam has the video endpoint 
 on
 interface number 3 (which fortunately doesn't cause any trouble because 
 ist uses
 bulk transfers only).
 We already consider the actual the interface number for audio endpoints, so
 rename the the audio_ifnum variable and use it for all device types.
 Also get get rid of a pointless (ifnum < 0) in em28xx-audio.

 Signed-off-by: Frank Schäfer 
 ---
   drivers/media/usb/em28xx/em28xx-audio.c |   10 +-
   drivers/media/usb/em28xx/em28xx-cards.c |2 +-
   drivers/media/usb/em28xx/em28xx-dvb.c   |2 +-
   drivers/media/usb/em28xx/em28xx-video.c |2 +-
   drivers/media/usb/em28xx/em28xx.h   |3 +--
   5 Dateien geändert, 9 Zeilen hinzugefügt(+), 10 Zeilen entfernt(-)

 diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
 b/drivers/media/usb/em28xx/em28xx-audio.c
 index 30ee389..b2ae954 100644
 --- a/drivers/media/usb/em28xx/em28xx-audio.c
 +++ b/drivers/media/usb/em28xx/em28xx-audio.c
 @@ -243,15 +243,15 @@ static int snd_em28xx_capture_open(struct 
 snd_pcm_substream *substream)
}
   
runtime->hw = snd_em28xx_hw_capture;
 -  if ((dev->alt == 0 || dev->audio_ifnum) && dev->adev.users == 0) {
 -  if (dev->audio_ifnum)
 +  if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {
>>> Lets keep it named as "audio_ifnum". Ok, this is equal to the video_ifnum
>>> for several devices, but on em2861 (and other em2xx1 devices), the audio
>>> interface is different.
>> Uhm, that doesn't make sense.
>> Why do you want to call it audio_ifnum although it is used for 
>> audio/video/dvb ???
> em28xx-audio only cares about the interface used by audio, and if it is
> different than the one used by video, in order to switch the alternate at
> the right interface.
>
> So, you'll likely need to add a video_ifnum and an audio_ifnum, in
> order to track both (eventually, we may need a dvb_ifnum in the future,
> if they decide to provide a separate interface for it too).
>
>>> Also, as we're trying to get rid of hardcoded values, it also makes sense
>>> to store the alternate used for the audio endpoint.
>> We already to that: dev->alt.
> See below: dev->alt = 1 or dev->alt = 7.
>
>> I think there is some general misunderstanding here.
>> There is always only a single interface number and current alternate 
>> setting per driver instance.
>> If all endpoints are on the same interface, there's only a sibgle driver 
>> instance.
>> If the audio endpoints are on a separate interface, there will be two 
>> driver instances (each of them using their own device struct etc.).
>>
>>> Btw, I'm thinking on rework on this entire code, adding a logic that would
>>> handle properly the interface used by both audio and video (when this is
>>> the case) to not just select alt = 7, but to dynamically allocate the proper
>>> value for it, by taking into account the number of allocated audio URBs.
>> alt=7 is actually bug that needs to be fixed.
> Huh? alt = 7 is a "works everytime" kind of alternate, as it has the biggest
> window size. You can say that this is not optimized, making em28xx to spend
> more bandwidth than needed, but this is not a bug.
>
>> It messes up the alt settings made by the video part.
> Yes, because it doesn't recalculate the bandwidth.
>
>> This just didn't show up so far, because the video stream is almost 
>> always started after the audio stream.
> You can't assume that. 
>
> Actually, it is/was common for people to start the video streaming
> using some non-alsa compatible application, and then use a separate
> process for audio.
>
> See, for example (at ALSA audio with other applications):
>   http://www.linuxtv.org/wiki/index.php/Saa7134-alsa
>
> I actually use this way when I want to do some tests with alsa,
> stopping/restarting its stream without touching on the video one.
>
>> Do you know any devices with audio endpoints 0x83 on the same interface 
>> as video/dvb ?
> Yes. HVR-950 (and HVR-900).
>
>> If yes, can you check their alt settings ? I'm pretty sure the audio 
>> endpoint uses the same wMaxPacketSize and bInterval values at all alt 
>> settings.
> Yes.
>
>> Otherwise things would become very complicated...
> The problem is basically the same: when a audio or video stream starts,
> it will need to call some routine to determinate the alternate. Such
> routine should track if both streams are active, or if just on

Re: [PATCH 3/7] em28xx: Only deallocate struct em28xx after finishing all extensions

Am 13.01.2014 20:23, schrieb Mauro Carvalho Chehab:
> Em Mon, 13 Jan 2014 20:02:19 +0100
> Frank Schäfer  escreveu:
>
>> On 13.01.2014 00:00, Mauro Carvalho Chehab wrote:
>>> We can't free struct em28xx while one of the extensions is still
>>> using it.
>>>
>>> So, add a kref() to control it, freeing it only after the
>>> extensions fini calls.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab 
>>> ---
>>>   drivers/media/usb/em28xx/em28xx-audio.c |  5 -
>>>   drivers/media/usb/em28xx/em28xx-cards.c | 34 
>>> -
>>>   drivers/media/usb/em28xx/em28xx-dvb.c   |  5 -
>>>   drivers/media/usb/em28xx/em28xx-input.c |  8 +++-
>>>   drivers/media/usb/em28xx/em28xx-video.c | 11 +--
>>>   drivers/media/usb/em28xx/em28xx.h   |  9 +++--
>>>   6 files changed, 44 insertions(+), 28 deletions(-)
>>>
>>> diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
>>> b/drivers/media/usb/em28xx/em28xx-audio.c
>>> index 97d9105e6830..8e959dae8358 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-audio.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-audio.c
>>> @@ -878,6 +878,8 @@ static int em28xx_audio_init(struct em28xx *dev)
>>>   
>>> em28xx_info("Binding audio extension\n");
>>>   
>>> +   kref_get(&dev->ref);
>>> +
>>> printk(KERN_INFO "em28xx-audio.c: Copyright (C) 2006 Markus "
>>>  "Rechberger\n");
>>> printk(KERN_INFO
>>> @@ -949,7 +951,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
>>> if (dev == NULL)
>>> return 0;
>>>   
>>> -   if (dev->has_alsa_audio != 1) {
>>> +   if (!dev->has_alsa_audio) {
>>> /* This device does not support the extension (in this case
>>>the device is expecting the snd-usb-audio module or
>>>doesn't have analog audio support at all) */
>>> @@ -963,6 +965,7 @@ static int em28xx_audio_fini(struct em28xx *dev)
>>> dev->adev.sndcard = NULL;
>>> }
>>>   
>>> +   kref_put(&dev->ref, em28xx_free_device);
>>> return 0;
>>>   }
>>>   
>>> diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
>>> b/drivers/media/usb/em28xx/em28xx-cards.c
>>> index 3b332d527ccb..df92f417634a 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-cards.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-cards.c
>>> @@ -2867,16 +2867,18 @@ static void flush_request_modules(struct em28xx 
>>> *dev)
>>> flush_work(&dev->request_module_wk);
>>>   }
>>>   
>>> -/*
>>> - * em28xx_release_resources()
>>> - * unregisters the v4l2,i2c and usb devices
>>> - * called when the device gets disconnected or at module unload
>>> -*/
>>> -void em28xx_release_resources(struct em28xx *dev)
>>> +/**
>>> + * em28xx_release_resources() -  unregisters the v4l2,i2c and usb devices
>>> + *
>>> + * @ref: struct kref for em28xx device
>>> + *
>>> + * This is called when all extensions and em28xx core unregisters a device
>>> + */
>>> +void em28xx_free_device(struct kref *ref)
>>>   {
>>> -   /*FIXME: I2C IR should be disconnected */
>>> +   struct em28xx *dev = kref_to_dev(ref);
>>>   
>>> -   mutex_lock(&dev->lock);
>>> +   em28xx_info("Freeing device\n");
>>>   
>>> if (dev->def_i2c_bus)
>>> em28xx_i2c_unregister(dev, 1);
>>> @@ -2887,9 +2889,10 @@ void em28xx_release_resources(struct em28xx *dev)
>>> /* Mark device as unused */
>>> clear_bit(dev->devno, &em28xx_devused);
>>>   
>>> -   mutex_unlock(&dev->lock);
>>> -};
>>> -EXPORT_SYMBOL_GPL(em28xx_release_resources);
>>> +   kfree(dev->alt_max_pkt_size_isoc);
>>> +   kfree(dev);
>>> +}
>>> +EXPORT_SYMBOL_GPL(em28xx_free_device);
>>>   
>>>   /*
>>>* em28xx_init_dev()
>>> @@ -3342,6 +3345,8 @@ static int em28xx_usb_probe(struct usb_interface 
>>> *interface,
>>> dev->dvb_xfer_bulk ? "bulk" : "isoc");
>>> }
>>>   
>>> +   kref_init(&dev->ref);
>>> +
>>> request_modules(dev);
>>>   
>>> /* Should be the last thing to do, to avoid newer udev's to
>>> @@ -3390,12 +3395,7 @@ static void em28xx_usb_disconnect(struct 
>>> usb_interface *interface)
>>>   
>>> em28xx_close_extension(dev);
>>>   
>>> -   em28xx_release_resources(dev);
>>> -
>>> -   if (!dev->users) {
>>> -   kfree(dev->alt_max_pkt_size_isoc);
>>> -   kfree(dev);
>>> -   }
>>> +   kref_put(&dev->ref, em28xx_free_device);
>>>   }
>>>   
>>>   static struct usb_driver em28xx_usb_driver = {
>>> diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
>>> b/drivers/media/usb/em28xx/em28xx-dvb.c
>>> index 5ea563e3f0e4..8674ae5fce06 100644
>>> --- a/drivers/media/usb/em28xx/em28xx-dvb.c
>>> +++ b/drivers/media/usb/em28xx/em28xx-dvb.c
>>> @@ -1010,11 +1010,11 @@ static int em28xx_dvb_init(struct em28xx *dev)
>>> em28xx_info("Binding DVB extension\n");
>>>   
>>> dvb = kzalloc(sizeof(struct em28xx_dvb), GFP_KERNEL);
>>> -
>>> if (dvb == NULL) {
>>> em28xx_info("em28xx_dvb: memory allocation failed\n");
>>> return -ENOMEM;
>>> }
>>> +   kref_get(&dev->ref);
>>> dev->dvb =

Re: Hauppauge WinTV-HVR-930C-HD with usbId 2040:b131

2014-01-13 Thread Matthias Schwarzott

On 12.01.2014 00:08, Christoph Lutz wrote:
> typo in message body: 939C should be HVR-930C-HD
> 
> 2014/1/12 Christoph Lutz :
>> in current wiki entries it is documented that HVR-939C-HD identifies with
>> usbId 2040:b130. Some days ago I bought a model that identifies with id
>> 2040:b131. Does anyone know more about that difference? Is b131 compatible
>> to b130? Can the new patches from Matthias Schwarzott be applied here, too?

Hi!

According to a mail I got some days ago from Ralph Stamm, this is a new
hardware revision of the HVR-930C-HD.

According to this part of the inf-file:
 ; Exeter DVB-T/C (Si2158/Si2165)
 %hcw10bda.DeviceDesc-B131%=POLARIS_XDS_Install.B131,
   USB\VID_2040&PID_B131&MI_01

the tuner was changed.

This revision is using tuner si2158 and demod si2165.
The si2165 is supported by my driver (as far as possible currently).

For Si2158, see this description
http://www.silabs.com/Support%20Documents/TechnicalDocs/Si2158-short.pdf
I have not found a driver for this tuner.

The challange here is to write a driver for the tuner.

>>
>> I'm interested in getting my new device supported. Is there anything I can
>> do to help developing the corresponding drivers (I'm software developer but
>> have less experience with linux-kernel/drivers hacking)?

You could try to do the same as I do with the si2165 driver and start by
documenting the card in the wiki (a seperate page or just a new section
in the existing entry).
And then starting with sniffing USB traffic.

Regards
Matthias

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

[PATCH v2 2/2] em28xx: fix check for audio only usb interfaces when changing the usb alternate setting

Previously, we've been assuming that the video endpoints are always at usb
interface 0. Hence, if vendor audio endpoints are provided at a separate
interface, they were supposed to be at interface number > 0.
Instead of checking for (interface number > 0) to determine if an interface is a
pure audio interface, dev->is_audio_only should be checked.

Signed-off-by: Frank Schäfer 
---
 drivers/media/usb/em28xx/em28xx-audio.c |   15 +--
 1 Datei geändert, 13 Zeilen hinzugefügt(+), 2 Zeilen entfernt(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index f80c3533..5bdf86c 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -266,7 +266,7 @@ static int snd_em28xx_capture_open(struct snd_pcm_substream 
*substream)
dprintk("opening device and trying to acquire exclusive lock\n");
 
runtime->hw = snd_em28xx_hw_capture;
-   if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {
+   if ((dev->alt == 0 || dev->is_audio_only) && dev->adev.users == 0) {
int nonblock = !!(substream->f_flags & O_NONBLOCK);
 
if (nonblock) {
@@ -274,10 +274,21 @@ static int snd_em28xx_capture_open(struct 
snd_pcm_substream *substream)
return -EAGAIN;
} else
mutex_lock(&dev->lock);
-   if (dev->ifnum)
+   if (dev->is_audio_only)
+   /* vendor audio is on a separate interface */
dev->alt = 1;
else
+   /* vendor audio is on the same interface as video */
dev->alt = 7;
+   /*
+* FIXME: The intention seems to be to select the alt
+* setting with the largest wMaxPacketSize for the video
+* endpoint.
+* At least dev->alt should be used instead, but we
+* should probably not touch it at all if it is
+* already >0, because wMaxPacketSize of the audio
+* endpoints seems to be the same for all.
+*/
 
dprintk("changing alternate number on interface %d to %d\n",
dev->ifnum, dev->alt);
-- 
1.7.10.4

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

[PATCH v2 1/2] em28xx: fix usb alternate setting for analog and digital video endpoints > 0

The current code assumes that the analog + digital video endpoints are always at
interface number 0 when changing the alternate setting.
This seems to work fine for most existing devices.
However, at least the SpeedLink VAD Laplace webcam has the video endpoint on
interface number 3 (which fortunately doesn't cause any trouble because ist uses
bulk transfers only).
We already consider the actual interface number for audio endpoints, so
rename the the audio_ifnum variable and use it for all device types.
Also get get rid of a pointless (ifnum < 0) in em28xx-audio.

Signed-off-by: Frank Schäfer 
---
 drivers/media/usb/em28xx/em28xx-audio.c |   18 +-
 drivers/media/usb/em28xx/em28xx-cards.c |2 +-
 drivers/media/usb/em28xx/em28xx-dvb.c   |2 +-
 drivers/media/usb/em28xx/em28xx-video.c |2 +-
 drivers/media/usb/em28xx/em28xx.h   |3 +--
 5 Dateien geändert, 13 Zeilen hinzugefügt(+), 14 Zeilen entfernt(-)

diff --git a/drivers/media/usb/em28xx/em28xx-audio.c 
b/drivers/media/usb/em28xx/em28xx-audio.c
index f3e3200..f80c3533 100644
--- a/drivers/media/usb/em28xx/em28xx-audio.c
+++ b/drivers/media/usb/em28xx/em28xx-audio.c
@@ -266,7 +266,7 @@ static int snd_em28xx_capture_open(struct snd_pcm_substream 
*substream)
dprintk("opening device and trying to acquire exclusive lock\n");
 
runtime->hw = snd_em28xx_hw_capture;
-   if ((dev->alt == 0 || dev->audio_ifnum) && dev->adev.users == 0) {
+   if ((dev->alt == 0 || dev->ifnum) && dev->adev.users == 0) {
int nonblock = !!(substream->f_flags & O_NONBLOCK);
 
if (nonblock) {
@@ -274,14 +274,14 @@ static int snd_em28xx_capture_open(struct 
snd_pcm_substream *substream)
return -EAGAIN;
} else
mutex_lock(&dev->lock);
-   if (dev->audio_ifnum)
+   if (dev->ifnum)
dev->alt = 1;
else
dev->alt = 7;
 
dprintk("changing alternate number on interface %d to %d\n",
-   dev->audio_ifnum, dev->alt);
-   usb_set_interface(dev->udev, dev->audio_ifnum, dev->alt);
+   dev->ifnum, dev->alt);
+   usb_set_interface(dev->udev, dev->ifnum, dev->alt);
 
/* Sets volume, mute, etc */
dev->mute = 0;
@@ -728,16 +728,16 @@ static int em28xx_audio_urb_init(struct em28xx *dev)
int urb_size, bytes_per_transfer;
u8 alt;
 
-   if (dev->audio_ifnum)
+   if (dev->ifnum)
alt = 1;
else
alt = 7;
 
-   intf = usb_ifnum_to_if(dev->udev, dev->audio_ifnum);
+   intf = usb_ifnum_to_if(dev->udev, dev->ifnum);
 
if (intf->num_altsetting <= alt) {
em28xx_errdev("alt %d doesn't exist on interface %d\n",
- dev->audio_ifnum, alt);
+ dev->ifnum, alt);
return -ENODEV;
}
 
@@ -761,7 +761,7 @@ static int em28xx_audio_urb_init(struct em28xx *dev)
 
em28xx_info("Endpoint 0x%02x %s on intf %d alt %d interval = %d, size 
%d\n",
 EM28XX_EP_AUDIO, usb_speed_string(dev->udev->speed),
-dev->audio_ifnum, alt,
+dev->ifnum, alt,
 interval,
 ep_size);
 
@@ -869,7 +869,7 @@ static int em28xx_audio_init(struct em28xx *dev)
static int  devnr;
int err;
 
-   if (!dev->has_alsa_audio || dev->audio_ifnum < 0) {
+   if (!dev->has_alsa_audio) {
/* This device does not support the extension (in this case
   the device is expecting the snd-usb-audio module or
   doesn't have analog audio support at all) */
diff --git a/drivers/media/usb/em28xx/em28xx-cards.c 
b/drivers/media/usb/em28xx/em28xx-cards.c
index 6efb902..c7e3667 100644
--- a/drivers/media/usb/em28xx/em28xx-cards.c
+++ b/drivers/media/usb/em28xx/em28xx-cards.c
@@ -3273,7 +3273,7 @@ static int em28xx_usb_probe(struct usb_interface 
*interface,
dev->has_alsa_audio = has_audio;
dev->audio_mode.has_audio = has_audio;
dev->has_video = has_video;
-   dev->audio_ifnum = ifnum;
+   dev->ifnum = ifnum;
 
/* Checks if audio is provided by some interface */
for (i = 0; i < udev->config->desc.bNumInterfaces; i++) {
diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 7dba175..4c0338b 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -203,7 +203,7 @@ static int em28xx_start_streaming(struct em28xx_dvb *dvb)
dvb_alt = dev->dvb_alt_isoc;
}
 
-   usb_set_interface(dev->udev, 0, dvb_alt);
+   usb_set_interface(dev->udev, dev->ifnum, dvb_alt);
rc = em28xx_set_mode(dev, EM28XX_DIGITA

Re: s3c-camif question

2014-01-13 Thread Sylwester Nawrocki

Hi Emad,

(adding linux-media at Cc)

On 01/13/2014 10:43 PM, Emad Hosseini Moghadam wrote:

Dear Mr. Nawrocki,

I am writing a driver for an image sensor, using i2c-s3c2410 and
s3c-camif platforms,in order to initialize the registers of the image
sensor. My cpu is s3c2440 . I have some questions regarding s3c-camif,
if it is possible for you of course:

1. I think it is impossible to initialize the registers of my image
sensor by s3c-camif. Then, why s3c-camif needs the information of the
sensor in "struct s3c_camif_sensor_info"?

Basically the driver of an image sensor is supposed to take care of the
I2C registers details. It implements some v4l2_subdevice callbacks, of
which

some can be called by the host interface driver (s3c-camif). You can do
some initialization for example in s_power() callback, or during a first
call to s_stream(). For an example see ov9650 driver [1].

s3c-camif registers an I2C client device for the sensor, so it needs an
information to which physical I2C bus the sensor is connected (i2c bus
adapter id) and what is an I2C slave address of the sensor.

The other members of struct s3c_camif_plat_data [2] include sensor master
clock frequency information - so s3c-camif driver sets clock frequency
appropriate for the sensor; polarization of signals like pixel clock,
VSYNC,

HSYNC - in order to match configuration of the parallel video interface at
the sensor (transmitter) and the application processor SoC (receiver) side.

2. Would you please tell me how can I initialize the "struct
s3c_camif_sensor_info" or give a sample?

For your reference, a patch I used for mini2440 board and ov9650 sensor
can be found at [2].

I hope it helps, please ask if anything is not clear.

--
Regards,
Sylwester

[1]
http://git.linuxtv.org/media_tree.git/blob/eab924d0e2bdfd53c902162b0b499b8464c1fb4a:/drivers/media/i2c/ov9650.c
[2]
http://git.linuxtv.org/snawrocki/media.git/commitdiff/48a72b878abdc9795da753981beff4a99ff80656

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

[linuxtv-media:master 491/499] drivers/media/usb/au0828/au0828-dvb.c:36:5: sparse: symbol 'preallocate_big_buffers' was not declared. Should it be static?

2014-01-13 Thread kbuild test robot

tree:   git://linuxtv.org/media_tree.git master
head:   eab924d0e2bdfd53c902162b0b499b8464c1fb4a
commit: f251b3e78cc57411627d825eae3c911da77b4035 [491/499] [media] au0828: Add 
option to preallocate digital transfer buffers
reproduce: make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> drivers/media/usb/au0828/au0828-dvb.c:36:5: sparse: symbol 
>> 'preallocate_big_buffers' was not declared. Should it be static?

Please consider folding the attached diff :-)

---
0-DAY kernel build testing backend  Open Source Technology Center
http://lists.01.org/mailman/listinfo/kbuild Intel Corporation
From: Fengguang Wu 
Subject: [PATCH linuxtv-media] au0828: preallocate_big_buffers can be static
TO: Tim Mester 
CC: Mauro Carvalho Chehab 
CC: linux-media@vger.kernel.org
CC: linux-media@vger.kernel.org 
CC: linux-ker...@vger.kernel.org 

CC: Tim Mester 
CC: Mauro Carvalho Chehab 
CC: linux-media@vger.kernel.org
Signed-off-by: Fengguang Wu 
---
 au0828-dvb.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/au0828/au0828-dvb.c b/drivers/media/usb/au0828/au0828-dvb.c
index 19fe049..4ae8b10 100644
--- a/drivers/media/usb/au0828/au0828-dvb.c
+++ b/drivers/media/usb/au0828/au0828-dvb.c
@@ -33,7 +33,7 @@
 #include "mxl5007t.h"
 #include "tda18271.h"
 
-int preallocate_big_buffers;
+static int preallocate_big_buffers;
 module_param_named(preallocate_big_buffers, preallocate_big_buffers, int, 0644);
 MODULE_PARM_DESC(preallocate_big_buffers, "Preallocate the larger transfer buffers at module load time");

Re: Support for Empia 2980 video/audio capture chip set

2014-01-13 Thread Keith Lawson


On 2014-01-12 11:56, Frank Schäfer wrote:


On 09.01.2014 02:02, Keith Lawson wrote:

Hello, I sent the following message to the linux-usb mailing list and 
they suggested I try here. I'm trying to get a "Dazzle Video Capture 
USB V1.0" video capture card working on a Linux device but it doesn't
look like the chip set is supported yet. I believe this card is the 
next version of the Pinnacle VC100 capture card that worked with the 
em28xx kernel module. The hardware vendor that sold the card says that
this device has an Empia 2980 chip set in it so I'm inquiring about 
support for that chip set. I'm just wondering about the best approach 
for getting the new chip supported in the kernel. Is this something 
the
em28xx maintainers would naturally address in time or can I assist in 
getting this into the kernel? Here's dmesg from the Debian box I'm 
working on: [ 3198.920619] usb 3-1: new high-speed USB device number 5
usingxhci_hcd [ 3198.939394] usb 3-1: New USB device found, 
idVendor=1b80,idProduct=e60a [ 3198.939399] usb 3-1: New USB device 
strings: Mfr=0, Product=1,SerialNumber=2 [ 3198.939403] usb 3-1: 
Product: Dazzle
Video Capture USB Audio Device [ 3198.939405] usb 3-1: SerialNumber: 0 
l440:~$ uname -a Linux l440 3.10-3-amd64 #1 SMP Debian 3.10.11-1 
(2013-09-10) x86_64 GNU/Linux If this isn't the appropriate list to 
ask

this question please point me in the right direction. Thanks, Keith



The em28xx is indeed the dedicated driver for this device, but it's 
hard

to say how much work would be necessary to add support for it.
We currently don't support any em29xx chip yet, but in theory it is 
just

an extended em28xx device.
Whatever that means when it comes to the low level stuff... ;)



What's the best route to get support for this chip added then? Should I 
start working on a patch myself or will this just happen during the 
course of development of the em28xx module? I'm a developer but haven't 
done any kernel hacking so this would likely be a steep learning curve 
for me.



Regards,
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 [1]




Links:
--
[1] 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

[PATCH RFC v7 03/12] v4l: 1 Hz resolution flag for tuners

Add V4L2_TUNER_CAP_1HZ for 1 Hz resolution.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 include/uapi/linux/videodev2.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 9dc79d1..1cf2076 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -1341,6 +1341,7 @@ struct v4l2_modulator {
 #define V4L2_TUNER_CAP_RDS_CONTROLS0x0200
 #define V4L2_TUNER_CAP_FREQ_BANDS  0x0400
 #define V4L2_TUNER_CAP_HWSEEK_PROG_LIM 0x0800
+#define V4L2_TUNER_CAP_1HZ 0x1000
 
 /*  Flags for the 'rxsubchans' field */
 #define V4L2_TUNER_SUB_MONO0x0001
-- 
1.8.4.2

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

[PATCH RFC v7 05/12] v4l: define own IOCTL ops for SDR FMT

Use own format ops for SDR data:
vidioc_enum_fmt_sdr_cap
vidioc_g_fmt_sdr_cap
vidioc_s_fmt_sdr_cap
vidioc_try_fmt_sdr_cap

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 include/media/v4l2-ioctl.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/include/media/v4l2-ioctl.h b/include/media/v4l2-ioctl.h
index e0b74a4..8be32f5 100644
--- a/include/media/v4l2-ioctl.h
+++ b/include/media/v4l2-ioctl.h
@@ -40,6 +40,8 @@ struct v4l2_ioctl_ops {
  struct v4l2_fmtdesc *f);
int (*vidioc_enum_fmt_vid_out_mplane)(struct file *file, void *fh,
  struct v4l2_fmtdesc *f);
+   int (*vidioc_enum_fmt_sdr_cap) (struct file *file, void *fh,
+   struct v4l2_fmtdesc *f);
 
/* VIDIOC_G_FMT handlers */
int (*vidioc_g_fmt_vid_cap)(struct file *file, void *fh,
@@ -62,6 +64,8 @@ struct v4l2_ioctl_ops {
   struct v4l2_format *f);
int (*vidioc_g_fmt_vid_out_mplane)(struct file *file, void *fh,
   struct v4l2_format *f);
+   int (*vidioc_g_fmt_sdr_cap)(struct file *file, void *fh,
+   struct v4l2_format *f);
 
/* VIDIOC_S_FMT handlers */
int (*vidioc_s_fmt_vid_cap)(struct file *file, void *fh,
@@ -84,6 +88,8 @@ struct v4l2_ioctl_ops {
   struct v4l2_format *f);
int (*vidioc_s_fmt_vid_out_mplane)(struct file *file, void *fh,
   struct v4l2_format *f);
+   int (*vidioc_s_fmt_sdr_cap)(struct file *file, void *fh,
+   struct v4l2_format *f);
 
/* VIDIOC_TRY_FMT handlers */
int (*vidioc_try_fmt_vid_cap)(struct file *file, void *fh,
@@ -106,6 +112,8 @@ struct v4l2_ioctl_ops {
 struct v4l2_format *f);
int (*vidioc_try_fmt_vid_out_mplane)(struct file *file, void *fh,
 struct v4l2_format *f);
+   int (*vidioc_try_fmt_sdr_cap)(struct file *file, void *fh,
+ struct v4l2_format *f);
 
/* Buffer handlers */
int (*vidioc_reqbufs) (struct file *file, void *fh, struct 
v4l2_requestbuffers *b);
-- 
1.8.4.2

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

[PATCH RFC v7 11/12] DocBook: mark SDR API as Experimental

Let it be experimental still as all SDR drivers are in staging.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
---
 Documentation/DocBook/media/v4l/compat.xml  | 3 +++
 Documentation/DocBook/media/v4l/dev-sdr.xml | 6 ++
 2 files changed, 9 insertions(+)

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index 83f64ce..2fb2b8d 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2661,6 +2661,9 @@ ioctls.
 
  Exporting DMABUF files using &VIDIOC-EXPBUF; ioctl.
 
+
+ Software Defined Radio (SDR) Interface, .
+
   
 
 
diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml 
b/Documentation/DocBook/media/v4l/dev-sdr.xml
index 332b87f..ac9f1af 100644
--- a/Documentation/DocBook/media/v4l/dev-sdr.xml
+++ b/Documentation/DocBook/media/v4l/dev-sdr.xml
@@ -1,5 +1,11 @@
   Software Defined Radio Interface (SDR)
 
+  
+Experimental
+This is an  experimental 
+interface and may change in the future.
+  
+
   
 SDR is an abbreviation of Software Defined Radio, the radio device
 which uses application software for modulation or demodulation. This interface
-- 
1.8.4.2

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

[PATCH RFC v7 10/12] DocBook: Software Defined Radio Interface

Document V4L2 SDR interface.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
---
 Documentation/DocBook/media/v4l/compat.xml |  10 ++
 Documentation/DocBook/media/v4l/dev-sdr.xml| 104 +
 Documentation/DocBook/media/v4l/io.xml |   6 ++
 Documentation/DocBook/media/v4l/pixfmt.xml |   8 ++
 Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
 Documentation/DocBook/media/v4l/vidioc-g-fmt.xml   |   7 ++
 .../DocBook/media/v4l/vidioc-querycap.xml  |   6 ++
 7 files changed, 142 insertions(+)
 create mode 100644 Documentation/DocBook/media/v4l/dev-sdr.xml

diff --git a/Documentation/DocBook/media/v4l/compat.xml 
b/Documentation/DocBook/media/v4l/compat.xml
index c4cac6d..83f64ce 100644
--- a/Documentation/DocBook/media/v4l/compat.xml
+++ b/Documentation/DocBook/media/v4l/compat.xml
@@ -2535,6 +2535,16 @@ fields changed from _s32 to _u32.
   
 
 
+
+  V4L2 in Linux 3.14
+  
+
+ Added Software Defined Radio (SDR) Interface.
+ 
+
+  
+
+
 
   Relation of V4L2 to other Linux multimedia APIs
 
diff --git a/Documentation/DocBook/media/v4l/dev-sdr.xml 
b/Documentation/DocBook/media/v4l/dev-sdr.xml
new file mode 100644
index 000..332b87f
--- /dev/null
+++ b/Documentation/DocBook/media/v4l/dev-sdr.xml
@@ -0,0 +1,104 @@
+  Software Defined Radio Interface (SDR)
+
+  
+SDR is an abbreviation of Software Defined Radio, the radio device
+which uses application software for modulation or demodulation. This interface
+is intended for controlling and data streaming of such devices.
+  
+
+  
+SDR devices are accessed through character device special files named
+/dev/swradio0 to /dev/swradio255
+with major number 81 and dynamically allocated minor numbers 0 to 255.
+  
+
+  
+Querying Capabilities
+
+
+Devices supporting the SDR receiver interface set the
+V4L2_CAP_SDR_CAPTURE and
+V4L2_CAP_TUNER flag in the
+capabilities field of &v4l2-capability;
+returned by the &VIDIOC-QUERYCAP; ioctl. That flag means the device has an
+Analog to Digital Converter (ADC), which is a mandatory element for the SDR 
receiver.
+At least one of the read/write, streaming or asynchronous I/O methods must
+be supported.
+
+  
+
+  
+Supplemental Functions
+
+
+SDR devices can support controls, and must
+support the tuner ioctls. Tuner ioctls are used
+for setting the ADC sampling rate (sampling frequency) and the possible RF 
tuner
+frequency.
+
+
+
+The V4L2_TUNER_ADC tuner type is used for ADC tuners, and
+the V4L2_TUNER_RF tuner type is used for RF tuners. The
+tuner index of the RF tuner (if any) must always follow the ADC tuner index.
+Normally the ADC tuner is #0 and the RF tuner is #1.
+
+
+
+The &VIDIOC-S-HW-FREQ-SEEK; ioctl is not supported.
+
+  
+
+  
+Data Format Negotiation
+
+
+The SDR capture device uses the format ioctls to
+select the capture format. Both the sampling resolution and the data streaming
+format are bound to that selectable format. In addition to the basic
+format ioctls, the &VIDIOC-ENUM-FMT; ioctl
+must be supported as well.
+
+
+
+To use the format ioctls applications set the
+type field of a &v4l2-format; to
+V4L2_BUF_TYPE_SDR_CAPTURE and use the &v4l2-format-sdr;
+sdr member of the fmt
+union as needed per the desired operation.
+Currently only the pixelformat field of
+&v4l2-format-sdr; is used. The content of that field is the V4L2 fourcc code
+of the data format.
+
+
+
+  struct v4l2_format_sdr
+  
+&cs-str;
+
+  
+__u32
+pixelformat
+
+The data format or type of compression, set by the application. This is a
+little endian four character code.
+V4L2 defines SDR formats in .
+   
+  
+  
+__u8
+reserved[28]
+This array is reserved for future extensions.
+Drivers and applications must set it to zero.
+  
+
+  
+
+
+
+An SDR device may support read/write
+and/or streaming (memory mapping
+or user pointer) I/O.
+
+
+  
diff --git a/Documentation/DocBook/media/v4l/io.xml 
b/Documentation/DocBook/media/v4l/io.xml
index 2c4c068..1fb11e8 100644
--- a/Documentation/DocBook/media/v4l/io.xml
+++ b/Documentation/DocBook/media/v4l/io.xml
@@ -1005,6 +1005,12 @@ should set this to 0.
Buffer for video output overlay (OSD), see .
  
+ 
+   V4L2_BUF_TYPE_SDR_CAPTURE
+   11
+   Buffer for Software Defined Radio (SDR), see .
+ 

   
 
diff --git a/Documentation/DocBook/media/v4l/pixfmt.xml 
b/Documentation/DocBook/media/v4l/pixfmt.xml
index 72d72bd..f586d34 100644
--- a/Documentation/DocBook/media/v4l/pixfmt.xml
+++ b/Documentation/DocBook/media/v4l/pixfmt.xml
@@ -811,6 +811,14 @@ extended control 
V4L2_CID_MPEG_STREAM_TYPE, see
 
   
 
+  
+SDR Formats
+
+These formats are used fo

[PATCH RFC v7 00/12] SDR API with documentation

Changes done according to Hans comments.

I also added patch which marks that API as a experimental as it it indeed 
experimental.
I think that this whole patch serie is ready for staging!

regards
Antti

Antti Palosaari (11):
  v4l: add device type for Software Defined Radio
  v4l: add new tuner types for SDR
  v4l: 1 Hz resolution flag for tuners
  v4l: add stream format for SDR receiver
  v4l: define own IOCTL ops for SDR FMT
  v4l: enable some IOCTLs for SDR receiver
  v4l: add device capability flag for SDR receiver
  DocBook: document 1 Hz flag
  DocBook: Software Defined Radio Interface
  DocBook: mark SDR API as Experimental
  v4l2-framework.txt: add SDR device type

Hans Verkuil (1):
  v4l: do not allow modulator ioctls for non-radio devices

 Documentation/DocBook/media/v4l/compat.xml |  13 +++
 Documentation/DocBook/media/v4l/dev-sdr.xml| 110 +
 Documentation/DocBook/media/v4l/io.xml |   6 ++
 Documentation/DocBook/media/v4l/pixfmt.xml |   8 ++
 Documentation/DocBook/media/v4l/v4l2.xml   |   1 +
 .../DocBook/media/v4l/vidioc-enum-freq-bands.xml   |   8 +-
 Documentation/DocBook/media/v4l/vidioc-g-fmt.xml   |   7 ++
 .../DocBook/media/v4l/vidioc-g-frequency.xml   |   5 +-
 .../DocBook/media/v4l/vidioc-g-modulator.xml   |   6 +-
 Documentation/DocBook/media/v4l/vidioc-g-tuner.xml |  15 ++-
 .../DocBook/media/v4l/vidioc-querycap.xml  |   6 ++
 .../DocBook/media/v4l/vidioc-s-hw-freq-seek.xml|   8 +-
 Documentation/video4linux/v4l2-framework.txt   |   1 +
 drivers/media/v4l2-core/v4l2-dev.c |  30 +-
 drivers/media/v4l2-core/v4l2-ioctl.c   |  75 +++---
 include/media/v4l2-dev.h   |   3 +-
 include/media/v4l2-ioctl.h |   8 ++
 include/trace/events/v4l2.h|   1 +
 include/uapi/linux/videodev2.h |  16 +++
 19 files changed, 299 insertions(+), 28 deletions(-)
 create mode 100644 Documentation/DocBook/media/v4l/dev-sdr.xml

-- 
1.8.4.2

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

[PATCH RFC v7 09/12] DocBook: document 1 Hz flag

Update documentation to reflect 1 Hz frequency step flag.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 .../DocBook/media/v4l/vidioc-enum-freq-bands.xml  |  8 +---
 Documentation/DocBook/media/v4l/vidioc-g-frequency.xml|  5 +++--
 Documentation/DocBook/media/v4l/vidioc-g-modulator.xml|  6 --
 Documentation/DocBook/media/v4l/vidioc-g-tuner.xml| 15 ---
 Documentation/DocBook/media/v4l/vidioc-s-hw-freq-seek.xml |  8 ++--
 5 files changed, 30 insertions(+), 12 deletions(-)

diff --git a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml 
b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
index 6541ba0..4e8ea65 100644
--- a/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-enum-freq-bands.xml
@@ -100,7 +100,7 @@ See 
capability
The tuner/modulator capability flags for
 this frequency band, see . The 
V4L2_TUNER_CAP_LOW
-capability must be the same for all frequency bands of the selected 
tuner/modulator.
+or V4L2_TUNER_CAP_1HZ capability must be the same for all 
frequency bands of the selected tuner/modulator.
 So either all bands have that capability set, or none of them have that 
capability.
  
  
@@ -109,7 +109,8 @@ So either all bands have that capability set, or none of 
them have that capabili
The lowest tunable frequency in
 units of 62.5 kHz, or if the capability
 flag V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz, for this frequency band.
+Hz, for this frequency band. A 1 Hz unit is used when the 
capability flag
+V4L2_TUNER_CAP_1HZ is set.
  
  
__u32
@@ -117,7 +118,8 @@ Hz, for this frequency band.
The highest tunable frequency in
 units of 62.5 kHz, or if the capability
 flag V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz, for this frequency band.
+Hz, for this frequency band. A 1 Hz unit is used when the 
capability flag
+V4L2_TUNER_CAP_1HZ is set.
  
  
__u32
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
index c7a1c46..d1034fb 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-frequency.xml
@@ -109,9 +109,10 @@ See 
__u32
frequency
Tuning frequency in units of 62.5 kHz, or if the
-&v4l2-tuner; or &v4l2-modulator; capabilities flag
+&v4l2-tuner; or &v4l2-modulator; capability flag
 V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz.
+Hz. A 1 Hz unit is used when the capability flag
+V4L2_TUNER_CAP_1HZ is set.
  
  
__u32
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
index 7f4ac7e..7068b59 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-modulator.xml
@@ -113,7 +113,8 @@ change for example with the current video standard.
The lowest tunable frequency in units of 62.5
 KHz, or if the capability flag
 V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz.
+Hz, or if the capability flag
+V4L2_TUNER_CAP_1HZ is set, in units of 1 Hz.
  
  
__u32
@@ -121,7 +122,8 @@ Hz.
The highest tunable frequency in units of 62.5
 KHz, or if the capability flag
 V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz.
+Hz, or if the capability flag
+V4L2_TUNER_CAP_1HZ is set, in units of 1 Hz.
  
  
__u32
diff --git a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml 
b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
index 6cc8201..b0d8659 100644
--- a/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
+++ b/Documentation/DocBook/media/v4l/vidioc-g-tuner.xml
@@ -134,7 +134,9 @@ the structure refers to a radio tuner the
The lowest tunable frequency in
 units of 62.5 kHz, or if the capability
 flag V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz. If multiple frequency bands are supported, then
+Hz, or if the capability flag
+V4L2_TUNER_CAP_1HZ is set, in units of 1 Hz.
+If multiple frequency bands are supported, then
 rangelow is the lowest frequency
 of all the frequency bands.
  
@@ -144,7 +146,9 @@ of all the frequency bands.
The highest tunable frequency in
 units of 62.5 kHz, or if the capability
 flag V4L2_TUNER_CAP_LOW is set, in units of 62.5
-Hz. If multiple frequency bands are supported, then
+Hz, or if the capability flag
+V4L2_TUNER_CAP_1HZ is set, in units of 1 Hz.
+If multiple frequency bands are supported, then
 rangehigh is the highest frequency
 of all the frequency bands.
  
@@ -270,7 +274,7 @@ applications must set the array to zero.
V4L2_TUNER_CAP_LOW
0x0001
When set, tuning frequencies are expressed in units of
-62.5 Hz, otherwise in units

[PATCH RFC v7 08/12] v4l: do not allow modulator ioctls for non-radio devices

From: Hans Verkuil 

Modulator ioctls could be enabled mistakenly for non-radio devices.
Currently those ioctls are only valid for radio. Fix it.

Signed-off-by: Hans Verkuil 
Signed-off-by: Antti Palosaari 
---
 drivers/media/v4l2-core/v4l2-dev.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index 6308a19..9adde0f 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -553,6 +553,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
const struct v4l2_ioctl_ops *ops = vdev->ioctl_ops;
bool is_vid = vdev->vfl_type == VFL_TYPE_GRABBER;
bool is_vbi = vdev->vfl_type == VFL_TYPE_VBI;
+   bool is_radio = vdev->vfl_type == VFL_TYPE_RADIO;
bool is_sdr = vdev->vfl_type == VFL_TYPE_SDR;
bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
@@ -726,8 +727,8 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_ENUM_DV_TIMINGS, 
vidioc_enum_dv_timings);
SET_VALID_IOCTL(ops, VIDIOC_DV_TIMINGS_CAP, 
vidioc_dv_timings_cap);
}
-   if (is_tx) {
-   /* transmitter only ioctls */
+   if (is_tx && (is_radio || is_sdr)) {
+   /* radio transmitter only ioctls */
SET_VALID_IOCTL(ops, VIDIOC_G_MODULATOR, vidioc_g_modulator);
SET_VALID_IOCTL(ops, VIDIOC_S_MODULATOR, vidioc_s_modulator);
}
-- 
1.8.4.2

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

[PATCH RFC v7 07/12] v4l: add device capability flag for SDR receiver

VIDIOC_QUERYCAP IOCTL is used to query device capabilities. Add new
capability flag to inform given device supports SDR capture.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 include/uapi/linux/videodev2.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 27bed7c..27fedfe 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -267,6 +267,8 @@ struct v4l2_capability {
 #define V4L2_CAP_RADIO 0x0004  /* is a radio device */
 #define V4L2_CAP_MODULATOR 0x0008  /* has a modulator */
 
+#define V4L2_CAP_SDR_CAPTURE   0x0010  /* Is a SDR capture device 
*/
+
 #define V4L2_CAP_READWRITE  0x0100  /* read/write systemcalls 
*/
 #define V4L2_CAP_ASYNCIO0x0200  /* async I/O */
 #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O ioctls */
-- 
1.8.4.2

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

[PATCH RFC v7 06/12] v4l: enable some IOCTLs for SDR receiver

Enable stream format (FMT) IOCTLs for SDR use. These are used for negotiate
used data stream format.

Reorganise some some IOCTL selection logic.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-dev.c   | 21 ++---
 drivers/media/v4l2-core/v4l2-ioctl.c | 35 +++
 2 files changed, 53 insertions(+), 3 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index 2ccacf2..6308a19 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -553,7 +553,7 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
const struct v4l2_ioctl_ops *ops = vdev->ioctl_ops;
bool is_vid = vdev->vfl_type == VFL_TYPE_GRABBER;
bool is_vbi = vdev->vfl_type == VFL_TYPE_VBI;
-   bool is_radio = vdev->vfl_type == VFL_TYPE_RADIO;
+   bool is_sdr = vdev->vfl_type == VFL_TYPE_SDR;
bool is_rx = vdev->vfl_dir != VFL_DIR_TX;
bool is_tx = vdev->vfl_dir != VFL_DIR_RX;
 
@@ -662,9 +662,20 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
   ops->vidioc_try_fmt_sliced_vbi_out)))
set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
SET_VALID_IOCTL(ops, VIDIOC_G_SLICED_VBI_CAP, 
vidioc_g_sliced_vbi_cap);
+   } else if (is_sdr) {
+   /* SDR specific ioctls */
+   if (ops->vidioc_enum_fmt_sdr_cap)
+   set_bit(_IOC_NR(VIDIOC_ENUM_FMT), valid_ioctls);
+   if (ops->vidioc_g_fmt_sdr_cap)
+   set_bit(_IOC_NR(VIDIOC_G_FMT), valid_ioctls);
+   if (ops->vidioc_s_fmt_sdr_cap)
+   set_bit(_IOC_NR(VIDIOC_S_FMT), valid_ioctls);
+   if (ops->vidioc_try_fmt_sdr_cap)
+   set_bit(_IOC_NR(VIDIOC_TRY_FMT), valid_ioctls);
}
-   if (!is_radio) {
-   /* ioctls valid for video or vbi */
+
+   if (is_vid || is_vbi || is_sdr) {
+   /* ioctls valid for video, vbi or sdr */
SET_VALID_IOCTL(ops, VIDIOC_REQBUFS, vidioc_reqbufs);
SET_VALID_IOCTL(ops, VIDIOC_QUERYBUF, vidioc_querybuf);
SET_VALID_IOCTL(ops, VIDIOC_QBUF, vidioc_qbuf);
@@ -672,6 +683,10 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
SET_VALID_IOCTL(ops, VIDIOC_DQBUF, vidioc_dqbuf);
SET_VALID_IOCTL(ops, VIDIOC_CREATE_BUFS, vidioc_create_bufs);
SET_VALID_IOCTL(ops, VIDIOC_PREPARE_BUF, vidioc_prepare_buf);
+   }
+
+   if (is_vid || is_vbi) {
+   /* ioctls valid for video or vbi */
if (ops->vidioc_s_std)
set_bit(_IOC_NR(VIDIOC_ENUMSTD), valid_ioctls);
SET_VALID_IOCTL(ops, VIDIOC_S_STD, vidioc_s_std);
diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 9a2acaf..95dd4f1 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -246,6 +246,7 @@ static void v4l_print_format(const void *arg, bool 
write_only)
const struct v4l2_vbi_format *vbi;
const struct v4l2_sliced_vbi_format *sliced;
const struct v4l2_window *win;
+   const struct v4l2_format_sdr *sdr;
unsigned i;
 
pr_cont("type=%s", prt_names(p->type, v4l2_type_names));
@@ -319,6 +320,14 @@ static void v4l_print_format(const void *arg, bool 
write_only)
sliced->service_lines[0][i],
sliced->service_lines[1][i]);
break;
+   case V4L2_BUF_TYPE_SDR_CAPTURE:
+   sdr = &p->fmt.sdr;
+   pr_cont(", pixelformat=%c%c%c%c\n",
+   (sdr->pixelformat >>  0) & 0xff,
+   (sdr->pixelformat >>  8) & 0xff,
+   (sdr->pixelformat >> 16) & 0xff,
+   (sdr->pixelformat >> 24) & 0xff);
+   break;
}
 }
 
@@ -882,6 +891,7 @@ static int check_fmt(struct file *file, enum v4l2_buf_type 
type)
const struct v4l2_ioctl_ops *ops = vfd->ioctl_ops;
bool is_vid = vfd->vfl_type == VFL_TYPE_GRABBER;
bool is_vbi = vfd->vfl_type == VFL_TYPE_VBI;
+   bool is_sdr = vfd->vfl_type == VFL_TYPE_SDR;
bool is_rx = vfd->vfl_dir != VFL_DIR_TX;
bool is_tx = vfd->vfl_dir != VFL_DIR_RX;
 
@@ -931,6 +941,10 @@ static int check_fmt(struct file *file, enum v4l2_buf_type 
type)
if (is_vbi && is_tx && ops->vidioc_g_fmt_sliced_vbi_out)
return 0;
break;
+   case V4L2_BUF_TYPE_SDR_CAPTURE:
+   if (is_sdr && is_rx && ops->vidioc_g_fmt_sdr_cap)
+   return 0;
+   break;
default:
break;
}
@@ -1050,6 +1064,10 @@ static int v4l_enum_fmt(const stru

[PATCH RFC v7 12/12] v4l2-framework.txt: add SDR device type

Add SDR device type to v4l2-framework.txt document.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 Documentation/video4linux/v4l2-framework.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/video4linux/v4l2-framework.txt 
b/Documentation/video4linux/v4l2-framework.txt
index 6c4866b..ae3a2cc 100644
--- a/Documentation/video4linux/v4l2-framework.txt
+++ b/Documentation/video4linux/v4l2-framework.txt
@@ -768,6 +768,7 @@ types exist:
 VFL_TYPE_GRABBER: videoX for video input/output devices
 VFL_TYPE_VBI: vbiX for vertical blank data (i.e. closed captions, teletext)
 VFL_TYPE_RADIO: radioX for radio tuners
+VFL_TYPE_SDR: swradioX for Software Defined Radio tuners
 
 The last argument gives you a certain amount of control over the device
 device node number used (i.e. the X in videoX). Normally you will pass -1
-- 
1.8.4.2

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

[PATCH RFC v7 01/12] v4l: add device type for Software Defined Radio

Add new V4L device type VFL_TYPE_SDR for Software Defined Radio.
It is registered as /dev/swradio0 (/dev/sdr0 was already reserved).

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-dev.c | 6 ++
 include/media/v4l2-dev.h   | 3 ++-
 2 files changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/media/v4l2-core/v4l2-dev.c 
b/drivers/media/v4l2-core/v4l2-dev.c
index b5c..2ccacf2 100644
--- a/drivers/media/v4l2-core/v4l2-dev.c
+++ b/drivers/media/v4l2-core/v4l2-dev.c
@@ -758,6 +758,8 @@ static void determine_valid_ioctls(struct video_device 
*vdev)
  * %VFL_TYPE_RADIO - A radio card
  *
  * %VFL_TYPE_SUBDEV - A subdevice
+ *
+ * %VFL_TYPE_SDR - Software Defined Radio
  */
 int __video_register_device(struct video_device *vdev, int type, int nr,
int warn_if_nr_in_use, struct module *owner)
@@ -797,6 +799,10 @@ int __video_register_device(struct video_device *vdev, int 
type, int nr,
case VFL_TYPE_SUBDEV:
name_base = "v4l-subdev";
break;
+   case VFL_TYPE_SDR:
+   /* Use device name 'swradio' because 'sdr' was already taken. */
+   name_base = "swradio";
+   break;
default:
printk(KERN_ERR "%s called with unknown type: %d\n",
   __func__, type);
diff --git a/include/media/v4l2-dev.h b/include/media/v4l2-dev.h
index c768c9f..eec6e46 100644
--- a/include/media/v4l2-dev.h
+++ b/include/media/v4l2-dev.h
@@ -24,7 +24,8 @@
 #define VFL_TYPE_VBI   1
 #define VFL_TYPE_RADIO 2
 #define VFL_TYPE_SUBDEV3
-#define VFL_TYPE_MAX   4
+#define VFL_TYPE_SDR   4
+#define VFL_TYPE_MAX   5
 
 /* Is this a receiver, transmitter or mem-to-mem? */
 /* Ignored for VFL_TYPE_SUBDEV. */
-- 
1.8.4.2

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

[PATCH RFC v7 04/12] v4l: add stream format for SDR receiver

Add new V4L2 stream format definition, V4L2_BUF_TYPE_SDR_CAPTURE,
for SDR receiver.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ioctl.c |  1 +
 include/trace/events/v4l2.h  |  1 +
 include/uapi/linux/videodev2.h   | 11 +++
 3 files changed, 13 insertions(+)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 15ab349..9a2acaf 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -152,6 +152,7 @@ const char *v4l2_type_names[] = {
[V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY] = "vid-out-overlay",
[V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE] = "vid-cap-mplane",
[V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE] = "vid-out-mplane",
+   [V4L2_BUF_TYPE_SDR_CAPTURE]= "sdr-cap",
 };
 EXPORT_SYMBOL(v4l2_type_names);
 
diff --git a/include/trace/events/v4l2.h b/include/trace/events/v4l2.h
index ef94eca..b9bb1f2 100644
--- a/include/trace/events/v4l2.h
+++ b/include/trace/events/v4l2.h
@@ -18,6 +18,7 @@
{ V4L2_BUF_TYPE_VIDEO_OUTPUT_OVERLAY, "VIDEO_OUTPUT_OVERLAY" },\
{ V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE, "VIDEO_CAPTURE_MPLANE" },\
{ V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE,  "VIDEO_OUTPUT_MPLANE" }, \
+   { V4L2_BUF_TYPE_SDR_CAPTURE,  "SDR_CAPTURE" }, \
{ V4L2_BUF_TYPE_PRIVATE,  "PRIVATE" })
 
 #define show_field(field)  \
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 1cf2076..27bed7c 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -139,6 +139,7 @@ enum v4l2_buf_type {
 #endif
V4L2_BUF_TYPE_VIDEO_CAPTURE_MPLANE = 9,
V4L2_BUF_TYPE_VIDEO_OUTPUT_MPLANE  = 10,
+   V4L2_BUF_TYPE_SDR_CAPTURE  = 11,
/* Deprecated, do not use */
V4L2_BUF_TYPE_PRIVATE  = 0x80,
 };
@@ -1695,6 +1696,15 @@ struct v4l2_pix_format_mplane {
 } __attribute__ ((packed));
 
 /**
+ * struct v4l2_format_sdr - SDR format definition
+ * @pixelformat:   little endian four character code (fourcc)
+ */
+struct v4l2_format_sdr {
+   __u32   pixelformat;
+   __u8reserved[28];
+} __attribute__ ((packed));
+
+/**
  * struct v4l2_format - stream data format
  * @type:  enum v4l2_buf_type; type of the data stream
  * @pix:   definition of an image format
@@ -1712,6 +1722,7 @@ struct v4l2_format {
struct v4l2_window  win; /* 
V4L2_BUF_TYPE_VIDEO_OVERLAY */
struct v4l2_vbi_format  vbi; /* 
V4L2_BUF_TYPE_VBI_CAPTURE */
struct v4l2_sliced_vbi_format   sliced;  /* 
V4L2_BUF_TYPE_SLICED_VBI_CAPTURE */
+   struct v4l2_format_sdr  sdr; /* 
V4L2_BUF_TYPE_SDR_CAPTURE */
__u8raw_data[200];   /* user-defined */
} fmt;
 };
-- 
1.8.4.2

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

[PATCH RFC v7 02/12] v4l: add new tuner types for SDR

Define tuner types V4L2_TUNER_ADC and V4L2_TUNER_RF for SDR usage.

ADC is used for setting sampling rate (sampling frequency) to SDR
device.

Another tuner type, named as V4L2_TUNER_RF, is possible RF tuner.
Is is used to down-convert RF frequency to range ADC could sample.
Having RF tuner is optional, whilst in practice it is almost always
there.

Also add checks to VIDIOC_G_FREQUENCY, VIDIOC_S_FREQUENCY and
VIDIOC_ENUM_FREQ_BANDS only allow these two tuner types when device
type is SDR (VFL_TYPE_SDR). For VIDIOC_G_FREQUENCY we do not check
tuner type, instead override type with V4L2_TUNER_ADC in every
case (requested by Hans in order to keep functionality in line with
existing tuners and existing API does not specify it).

Prohibit VIDIOC_S_HW_FREQ_SEEK explicitly when device type is SDR,
as device cannot do hardware seek without a hardware demodulator.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
 drivers/media/v4l2-core/v4l2-ioctl.c | 39 ++--
 include/uapi/linux/videodev2.h   |  2 ++
 2 files changed, 30 insertions(+), 11 deletions(-)

diff --git a/drivers/media/v4l2-core/v4l2-ioctl.c 
b/drivers/media/v4l2-core/v4l2-ioctl.c
index 707aef7..15ab349 100644
--- a/drivers/media/v4l2-core/v4l2-ioctl.c
+++ b/drivers/media/v4l2-core/v4l2-ioctl.c
@@ -1291,8 +1291,11 @@ static int v4l_g_frequency(const struct v4l2_ioctl_ops 
*ops,
struct video_device *vfd = video_devdata(file);
struct v4l2_frequency *p = arg;
 
-   p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
-   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+   if (vfd->vfl_type == VFL_TYPE_SDR)
+   p->type = V4L2_TUNER_ADC;
+   else
+   p->type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
return ops->vidioc_g_frequency(file, fh, p);
 }
 
@@ -1303,10 +1306,15 @@ static int v4l_s_frequency(const struct v4l2_ioctl_ops 
*ops,
const struct v4l2_frequency *p = arg;
enum v4l2_tuner_type type;
 
-   type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
-   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
-   if (p->type != type)
-   return -EINVAL;
+   if (vfd->vfl_type == VFL_TYPE_SDR) {
+   if (p->type != V4L2_TUNER_ADC && p->type != V4L2_TUNER_RF)
+   return -EINVAL;
+   } else {
+   type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+   if (type != p->type)
+   return -EINVAL;
+   }
return ops->vidioc_s_frequency(file, fh, p);
 }
 
@@ -1386,6 +1394,10 @@ static int v4l_s_hw_freq_seek(const struct 
v4l2_ioctl_ops *ops,
struct v4l2_hw_freq_seek *p = arg;
enum v4l2_tuner_type type;
 
+   /* s_hw_freq_seek is not supported for SDR for now */
+   if (vfd->vfl_type == VFL_TYPE_SDR)
+   return -EINVAL;
+
type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
if (p->type != type)
@@ -1885,11 +1897,16 @@ static int v4l_enum_freq_bands(const struct 
v4l2_ioctl_ops *ops,
enum v4l2_tuner_type type;
int err;
 
-   type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
-   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
-
-   if (type != p->type)
-   return -EINVAL;
+   if (vfd->vfl_type == VFL_TYPE_SDR) {
+   if (p->type != V4L2_TUNER_ADC && p->type != V4L2_TUNER_RF)
+   return -EINVAL;
+   type = p->type;
+   } else {
+   type = (vfd->vfl_type == VFL_TYPE_RADIO) ?
+   V4L2_TUNER_RADIO : V4L2_TUNER_ANALOG_TV;
+   if (type != p->type)
+   return -EINVAL;
+   }
if (ops->vidioc_enum_freq_bands)
return ops->vidioc_enum_freq_bands(file, fh, p);
if (is_valid_ioctl(vfd, VIDIOC_G_TUNER)) {
diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index 6ae7bbe..9dc79d1 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -159,6 +159,8 @@ enum v4l2_tuner_type {
V4L2_TUNER_RADIO = 1,
V4L2_TUNER_ANALOG_TV = 2,
V4L2_TUNER_DIGITAL_TV= 3,
+   V4L2_TUNER_ADC   = 4,
+   V4L2_TUNER_RF= 5,
 };
 
 enum v4l2_memory {
-- 
1.8.4.2

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

Re: [PATCH RFC v6 07/12] v4l: add device capability flag for SDR receiver


On 05.01.2014 14:13, Hans Verkuil wrote:

On 12/29/2013 05:03 AM, Antti Palosaari wrote:

VIDIOC_QUERYCAP IOCTL is used to query device capabilities. Add new
capability flag to inform given device supports SDR capture.

Cc: Hans Verkuil 
Signed-off-by: Antti Palosaari 
Acked-by: Hans Verkuil 
---
  include/uapi/linux/videodev2.h | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/include/uapi/linux/videodev2.h b/include/uapi/linux/videodev2.h
index c50e449..f596b7b 100644
--- a/include/uapi/linux/videodev2.h
+++ b/include/uapi/linux/videodev2.h
@@ -267,6 +267,8 @@ struct v4l2_capability {
  #define V4L2_CAP_RADIO0x0004  /* is a radio 
device */
  #define V4L2_CAP_MODULATOR0x0008  /* has a modulator */

+#define V4L2_CAP_SDR_CAPTURE   0x0010  /* Is a SDR capture device 
*/
+
  #define V4L2_CAP_READWRITE  0x0100  /* read/write systemcalls 
*/
  #define V4L2_CAP_ASYNCIO0x0200  /* async I/O */
  #define V4L2_CAP_STREAMING  0x0400  /* streaming I/O ioctls */



This new capability needs to be documented in DocBook as well 
(vidioc-querycap.xml).


It is already.

regards
Antti


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

Re: [PATCH 3/6] msi3101: add u8 sample format


On 05.01.2014 14:14, Hans Verkuil wrote:

On 12/29/2013 05:51 AM, Antti Palosaari wrote:

Add unsigned 8-bit sample format. Format is got directly from
hardware, but it is converted from signed to unsigned. It is worst
known sampling resolution hardware offer.

Signed-off-by: Antti Palosaari 
---
  drivers/staging/media/msi3101/sdr-msi3101.c | 67 -
  1 file changed, 66 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 9c54c63..2110488 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -385,6 +385,7 @@ static const struct msi3101_gain msi3101_gain_lut_1000[] = {
  #define MSI3101_CID_TUNER_IF  ((V4L2_CID_USER_BASE | 0xf000) + 12)
  #define MSI3101_CID_TUNER_GAIN((V4L2_CID_USER_BASE | 0xf000) + 13)

+#define V4L2_PIX_FMT_SDR_U8 v4l2_fourcc('D', 'U', '0', '8') /* unsigned 
8-bit */
  #define V4L2_PIX_FMT_SDR_S8 v4l2_fourcc('D', 'S', '0', '8') /* signed 
8-bit */
  #define V4L2_PIX_FMT_SDR_S12v4l2_fourcc('D', 'S', '1', '2') /* signed 
12-bit */
  #define V4L2_PIX_FMT_SDR_S14v4l2_fourcc('D', 'S', '1', '4') /* signed 
14-bit */


These defines should be moved to videodev2.h and documented in DocBook.


Indeed, but that driver is still on staging. I will move those later...

regards
Antti


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

cron job: media_tree daily build: WARNINGS

This message is generated daily by a cron job that builds media_tree for
the kernels and architectures in the list below.

Results of the daily build of media_tree:

date:   Tue Jan 14 04:00:25 CET 2014
git branch: test
git hash:   eab924d0e2bdfd53c902162b0b499b8464c1fb4a
gcc version:i686-linux-gcc (GCC) 4.8.2
sparse version: 0.4.5-rc1
host hardware:  x86_64
host os:3.12-6.slh.2-amd64

linux-git-arm-at91: OK
linux-git-arm-davinci: OK
linux-git-arm-exynos: WARNINGS
linux-git-arm-mx: OK
linux-git-arm-omap: OK
linux-git-arm-omap1: OK
linux-git-arm-pxa: OK
linux-git-blackfin: OK
linux-git-i686: OK
linux-git-m32r: OK
linux-git-mips: OK
linux-git-powerpc64: OK
linux-git-sh: OK
linux-git-x86_64: OK
linux-2.6.31.14-i686: WARNINGS
linux-2.6.32.27-i686: WARNINGS
linux-2.6.33.7-i686: WARNINGS
linux-2.6.34.7-i686: WARNINGS
linux-2.6.35.9-i686: WARNINGS
linux-2.6.36.4-i686: WARNINGS
linux-2.6.37.6-i686: WARNINGS
linux-2.6.38.8-i686: WARNINGS
linux-2.6.39.4-i686: WARNINGS
linux-3.0.60-i686: WARNINGS
linux-3.1.10-i686: WARNINGS
linux-3.2.37-i686: OK
linux-3.3.8-i686: OK
linux-3.4.27-i686: OK
linux-3.5.7-i686: OK
linux-3.6.11-i686: WARNINGS
linux-3.7.4-i686: WARNINGS
linux-3.8-i686: WARNINGS
linux-3.9.2-i686: WARNINGS
linux-3.10.1-i686: OK
linux-3.11.1-i686: OK
linux-3.12-i686: OK
linux-3.13-rc1-i686: OK
linux-2.6.31.14-x86_64: WARNINGS
linux-2.6.32.27-x86_64: WARNINGS
linux-2.6.33.7-x86_64: WARNINGS
linux-2.6.34.7-x86_64: WARNINGS
linux-2.6.35.9-x86_64: WARNINGS
linux-2.6.36.4-x86_64: WARNINGS
linux-2.6.37.6-x86_64: WARNINGS
linux-2.6.38.8-x86_64: WARNINGS
linux-2.6.39.4-x86_64: WARNINGS
linux-3.0.60-x86_64: WARNINGS
linux-3.1.10-x86_64: WARNINGS
linux-3.2.37-x86_64: OK
linux-3.3.8-x86_64: OK
linux-3.4.27-x86_64: OK
linux-3.5.7-x86_64: OK
linux-3.6.11-x86_64: WARNINGS
linux-3.7.4-x86_64: WARNINGS
linux-3.8-x86_64: WARNINGS
linux-3.9.2-x86_64: WARNINGS
linux-3.10.1-x86_64: OK
linux-3.11.1-x86_64: OK
linux-3.12-x86_64: OK
linux-3.13-rc1-x86_64: OK
apps: OK
spec-git: OK
sparse version: 0.4.5-rc1
sparse: ERRORS

Detailed results are available here:

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

Full logs are available here:

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

The Media Infrastructure API from this daily build is here:

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

Re: Upstreaming SAA716x driver to the media_tree

2014-01-13 Thread Manu Abraham

On Tue, Jan 14, 2014 at 12:20 AM, Steven Toth  wrote:
>>> Manu, do you see any inconvenience in sending your driver to the
>>> linux_media tree?
>>> I'm available to place some effort on this task.
>>
>>
>> I can push the 716x driver and whatever additional changes that I have
>> later on this weekend, if that's okay with you.
>
> I never saw a push.

Spliiting and cleaning up the patches took up more time than expected.
Please wait a few days.
--
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: video4linux device name request for Software Defined Radio