Opening firmware source code (vhdl)
Hello, We're fully opening firmware sources for our new card - NetUP Dual Universal DVB CI. License is GPLv3. Sources is VHDL for Altera FPGA EP4CGX22CF19C8 and can be compiled with Altera Quartus II (free edition). Hope this will help for enthusiasts and developers to deeply understand hardware part of DVB card. Source code: https://github.com/aospan/NetUP_Dual_Universal_CI-fpga Here is a description for building and uploading fw into DVB card: http://linuxtv.org/wiki/index.php/FPGA_fw_for_NetUP_Dual_Universal_CI Feel free to contact me for any questions or comments. -- Abylay Ospan, NetUP Inc. http://www.netup.tv -- 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: Can the patch adding support for the Tasco USB microscope be queued up?
My apologies, the other emails were sent to linux-uvc-devel, not linux-media. Do you want an attached patch file, or simply a diff in the body of the email? I'm also not clear on what you mean by correct Signed-off-by line, I have very little experience with git, I've mostly used bzr. Michael Hall mhall...@gmail.com On 02/16/2015 10:40 AM, Hans Verkuil wrote: On 02/16/2015 04:31 PM, Michael Hall wrote: This is now the 3rd or 4th email to this list requesting that this patch be merged in. If there is something wrong with the patch that needs fixing, please let me know and I will work on the fix. Otherwise I've lost interest in pushing to get it into upstream. I can't remember ever seeing a patch for that posted to the linux-media mailinglist. The best way is just to post the patch to this mailinglist, check that it appears in patchwork (https://patchwork.linuxtv.org/project/linux-media/list/), make sure you keep the author and correct Signed-off-by line and it's *guaranteed* that someone will look at it, and merge it or reply to it if there are problems. Mails like 'please pick up a patch from some other git repo' are very likely to be forgotten due to volume of other postings. Patchwork won't pick them up and that's what we all rely on. So if either of you can just post this as a properly formatted patch, then it will be taken care of. Regards, Hans Michael Hall mhall...@gmail.com On 02/16/2015 10:08 AM, Steven Zakulec wrote: Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. 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 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: DVB suspend/resume regression on 3.19
At Fri, 13 Feb 2015 16:12:40 +0100, Takashi Iwai wrote: At Fri, 13 Feb 2015 12:41:25 -0200, Mauro Carvalho Chehab wrote: Em Fri, 13 Feb 2015 15:02:42 +0100 Takashi Iwai ti...@suse.de escreveu: At Mon, 09 Feb 2015 11:59:07 +0100, Takashi Iwai wrote: Hi, we've got a bug report about the suspend/resume regression of DVB device with 3.19. The symptom is VLC doesn't work after S3 or S4 resume. strace shows that /dev/dvb/adaptor0/dvr returns -ENODEV. The reporter confirmed that 3.18 works fine, so the regression must be in 3.19. There is a relevant kernel warning while suspending: WARNING: CPU: 1 PID: 3603 at ../kernel/module.c:1001 module_put+0xc7/0xd0() Workqueue: events_unbound async_run_entry_fn 81a45779 81664f12 81062381 a051eea0 8800ca369278 a051a068 8800c0a18090 810dfb47 Call Trace: [810055ac] dump_trace+0x8c/0x340 [81005903] show_stack_log_lvl+0xa3/0x190 [81007061] show_stack+0x21/0x50 [81664f12] dump_stack+0x47/0x67 [81062381] warn_slowpath_common+0x81/0xb0 [810dfb47] module_put+0xc7/0xd0 [a04d98d1] dvb_usb_adapter_frontend_exit+0x41/0x60 [dvb_usb] [a04d8451] dvb_usb_exit+0x31/0xa0 [dvb_usb] [a04d84fb] dvb_usb_device_exit+0x3b/0x50 [dvb_usb] [814cefad] usb_unbind_interface+0x1ed/0x2c0 [8145ceae] __device_release_driver+0x7e/0x100 [8145cf52] device_release_driver+0x22/0x30 [814cf13d] usb_forced_unbind_intf+0x2d/0x60 [814cf3c3] usb_suspend+0x73/0x130 [814bd453] usb_dev_freeze+0x13/0x20 [81468fca] dpm_run_callback+0x4a/0x150 [81469c81] __device_suspend+0x121/0x350 [81469ece] async_suspend+0x1e/0xa0 [81081e63] async_run_entry_fn+0x43/0x150 [81079e72] process_one_work+0x142/0x3f0 [8107a234] worker_thread+0x114/0x460 [8107f3b1] kthread+0xc1/0xe0 [8166b77c] ret_from_fork+0x7c/0xb0 So something went wrong in module refcount, which likely leads to disabling the device and returning -ENODEV in the end. Does this ring a bell to you guys? The hardware details and logs are found in the URL below: https://bugzilla.novell.com/show_bug.cgi?id=916577 I wonder whether no one hits the same problem...? Hi Takashi, There were no recent changes at dvb-usb core or at the dtt200u.c driver. So, I don't think that the regression was caused by a change at the media subsystem. Yet, we've added some patches to fix suspend/resume at the DVB core, but they basically add a new set of optional callbacks. So, it should not cause any regression. The changeset in question is 59d7889ae49f6e3e9d9cff8c0de7ad95d9ca068b. Hm, is this commit really merged between 3.18 and 3.19? From those messages: 2015-02-06T15:30:47.468258+01:00 linux-z24t kernel: [ 150.552119] dvb-usb: downloading firmware from file 'dvb-usb-wt220u-fc03.fw' 2015-02-06T15:30:47.468827+01:00 linux-z24t mtp-probe: checking bus 1, device 5: /sys/devices/pci:00/:00:1d.7/usb1/1-4 2015-02-06T15:30:47.879878+01:00 linux-z24t mtp-probe: bus: 1, device: 5 was not an MTP device 2015-02-06T15:30:47.880192+01:00 linux-z24t kernel: [ 151.992993] usb 1-4: USB disconnect, device number 5 2015-02-06T15:30:47.880839+01:00 linux-z24t kernel: [ 151.993076] dvb-usb: generic DVB-USB module successfully deinitialized and disconnected. I _suspect_ that dvb_usb_download_firmware() failed to load the firmware file. That problem actually looks like a recently discovered issue:t request_firmware() fails during resume on some systems. What seems to happen in this case is that the media drivers are resumed _before_ mounting the partition where the firmware file is hosted. Yet, in this case, it should be printing: did not find the firmware file. Right. This makes me wonder, too. I would add a test patch in order to print the return code from dvb_usb_download_firmware(), in order to see if it succeeds or not, e. g. something like the patch below, and then try to narrow down where it is failing, assuming that the new message will be printed. If nothing gets printed, then I would try to discover why the USB stack disconnected the device. Perhaps an ehci/xhci bug? OK, I'll give a test kernel to report. The patched kernel didn't show the message. So it's not about the firmware load failure, apparently. Any other point to check? Takashi -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at
Re: Can the patch adding support for the Tasco USB microscope be queued up?
On 02/16/2015 05:01 PM, Michael Hall wrote: My apologies, the other emails were sent to linux-uvc-devel, not linux-media. Do you want an attached patch file, or simply a diff in the body of the email? I'm also not clear on what you mean by correct Signed-off-by line, I have very little experience with git, I've mostly used bzr. This is a good link with the relevant information: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches Anyway, I checked where the original patch came from, and Laurent Pinchart wrote it. Since he's kernel maintainer he knows all about well-formatted patches and it's best if he just posts and merges his own patch :-) Laurent, it's all yours! Regards, Hans Michael Hall mhall...@gmail.com On 02/16/2015 10:40 AM, Hans Verkuil wrote: On 02/16/2015 04:31 PM, Michael Hall wrote: This is now the 3rd or 4th email to this list requesting that this patch be merged in. If there is something wrong with the patch that needs fixing, please let me know and I will work on the fix. Otherwise I've lost interest in pushing to get it into upstream. I can't remember ever seeing a patch for that posted to the linux-media mailinglist. The best way is just to post the patch to this mailinglist, check that it appears in patchwork (https://patchwork.linuxtv.org/project/linux-media/list/), make sure you keep the author and correct Signed-off-by line and it's *guaranteed* that someone will look at it, and merge it or reply to it if there are problems. Mails like 'please pick up a patch from some other git repo' are very likely to be forgotten due to volume of other postings. Patchwork won't pick them up and that's what we all rely on. So if either of you can just post this as a properly formatted patch, then it will be taken care of. Regards, Hans Michael Hall mhall...@gmail.com On 02/16/2015 10:08 AM, Steven Zakulec wrote: Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. 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 -- 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: Opening firmware source code (vhdl)
On Mon, Feb 16, 2015 at 11:04:47AM -0500, Abylay Ospan wrote: Hello, We're fully opening firmware sources for our new card - NetUP Dual Universal DVB CI. License is GPLv3. Sources is VHDL for Altera FPGA EP4CGX22CF19C8 and can be compiled with Altera Quartus II (free edition). Hope this will help for enthusiasts and developers to deeply understand hardware part of DVB card. Source code: https://github.com/aospan/NetUP_Dual_Universal_CI-fpga Here is a description for building and uploading fw into DVB card: http://linuxtv.org/wiki/index.php/FPGA_fw_for_NetUP_Dual_Universal_CI Feel free to contact me for any questions or comments. -- Abylay Ospan, NetUP Inc. http://www.netup.tv -- Thanks for open sourcing the firmware of your new card! I am sure the owners of this hardware will appreciate this. Luis -- 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 v5 3/4] media: ov2640: add primary dt support
Hi Josh, Thanks for the patch. On Tue, Feb 10, 2015 at 9:31 AM, Josh Wu josh...@atmel.com wrote: [Snip] - priv-clk = v4l2_clk_get(client-dev, mclk); + priv-clk = v4l2_clk_get(client-dev, xvclk); with this change don’t you need to update the board file using this driver/ the bridge driver ? Regards, --Prabhakar Lad -- 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
[RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. I've tested this patch by applying it to current media-master and it applies cleanly and builds without issue for me. More information on the card can be found at: http://prospero-tech.com/vortex-1-dvb-t-pcie-card/ Regards, Philip Downer Philip Downer (1): [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd. drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c -- 2.1.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
[RFC PATCH 1/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
This patch adds support for the Vortex 1 PCIe card from Prospero Technologies Ltd. The Vortex 1 supports up to 8 tuner modules and currently ships with 8xDibcom 7090p tuners. The card also has raw infra-red support and a hardware demuxer. Signed-off-by: Philip Downer pdow...@prospero-tech.com --- drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c diff --git a/drivers/media/pci/Kconfig b/drivers/media/pci/Kconfig index 218144a..5c7c356 100644 --- a/drivers/media/pci/Kconfig +++ b/drivers/media/pci/Kconfig @@ -46,6 +46,7 @@ source drivers/media/pci/pt3/Kconfig source drivers/media/pci/mantis/Kconfig source drivers/media/pci/ngene/Kconfig source drivers/media/pci/ddbridge/Kconfig +source drivers/media/pci/prospero/Kconfig source drivers/media/pci/smipcie/Kconfig endif diff --git a/drivers/media/pci/Makefile b/drivers/media/pci/Makefile index 0baf0d2..d792604 100644 --- a/drivers/media/pci/Makefile +++ b/drivers/media/pci/Makefile @@ -11,6 +11,7 @@ obj-y+= ttpci/ \ mantis/ \ ngene/ \ ddbridge/ \ + prospero/ \ saa7146/\ smipcie/ @@ -26,4 +27,5 @@ obj-$(CONFIG_VIDEO_SAA7164) += saa7164/ obj-$(CONFIG_VIDEO_TW68) += tw68/ obj-$(CONFIG_VIDEO_MEYE) += meye/ obj-$(CONFIG_STA2X11_VIP) += sta2x11/ +obj-$(CONFIG_PROSPERO) += prospero/ obj-$(CONFIG_VIDEO_SOLO6X10) += solo6x10/ diff --git a/drivers/media/pci/prospero/Kconfig b/drivers/media/pci/prospero/Kconfig new file mode 100644 index 000..960f370 --- /dev/null +++ b/drivers/media/pci/prospero/Kconfig @@ -0,0 +1,7 @@ +config DVB_PROSPERO + tristate Prospero cards + depends on DVB_CORE PCI + help + Support for PCIe DVB-T cards from Prospero Technologies Ltd. + + Say Y or M if you own such a device and want to use it. diff --git a/drivers/media/pci/prospero/Makefile b/drivers/media/pci/prospero/Makefile new file mode 100644 index 000..ea35912 --- /dev/null +++ b/drivers/media/pci/prospero/Makefile @@ -0,0 +1,7 @@ +obj-m := prospero.o +prospero-objs := prospero_main.o prospero_fe_main.o prospero_i2c.o prospero_ir.o + +ccflags-y += -Idrivers/media/common/tuners +ccflags-y += -Idrivers/media/dvb-core +ccflags-y += -Idrivers/media/dvb-frontends +ccflags-y += -Idrivers/media/pci/prospero diff --git a/drivers/media/pci/prospero/prospero_common.h b/drivers/media/pci/prospero/prospero_common.h new file mode 100644 index 000..f8aece1 --- /dev/null +++ b/drivers/media/pci/prospero/prospero_common.h @@ -0,0 +1,264 @@ +#ifndef PROSPERO_COMMON + +#define PROSPERO_COMMON + +#include linux/init.h +#include linux/kernel.h +#include linux/module.h +#include linux/pci.h +#include linux/mutex.h +#include linux/dma-mapping.h +#include linux/firmware.h +#include linux/kobject.h +#include linux/list.h +#include linux/timer.h + +#include demux.h +#include dmxdev.h +#include dvb_demux.h +#include dvb_frontend.h +#include dvb_net.h +#include dvbdev.h + +#define MAXIMUM_NUM_OF_FE 8 + +#define MAX_NUM_OF_DEMUXS 8 +#define DEMUX_PER_FE 1 + +#define STREAMS_PER_DEMUX 30 + +#define MAX_STREAMS (STREAMS_PER_DEMUX * MAX_NUM_OF_DEMUXS) + +#define WILD_PID 0x2000 + +#define PROSPERO_REGISTER_BASE 0x000 + +#define PID_TABLE_START (PROSPERO_REGISTER_BASE + 0x4) + +#define I2C_RESETS (PROSPERO_REGISTER_BASE + 0x70) + +#define TS_CAP_ENABLE (PROSPERO_REGISTER_BASE + 0x74) + +#define INTERRUPT_ENABLE (PROSPERO_REGISTER_BASE + 0x78) +#define INTERRUPT_CONTROL (PROSPERO_REGISTER_BASE + 0x40) + +#define PID_TABLE_SLOT_SIZE 0x04 + +#define CONTROL_BITS_OFFSET 0x00 + +/*Control bit masks*/ +#define NULL_PACKET
Re: [PATCH 3/5] uvc gadget: switch to unlocked_ioctl.
Hi Hans, On Monday 16 February 2015 16:11:55 Hans Verkuil wrote: On 02/03/2015 02:55 PM, Laurent Pinchart wrote: On Tuesday 03 February 2015 13:47:24 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Instead of .ioctl use unlocked_ioctl. While all the queue ops already use a lock, there was no lock to protect uvc_video, so add that one. There's more. streamon and streamoff need to be protected by a lock for instance. Wouldn't it be easier to just set vdev-lock for this driver instead of adding manual locking ? I could set vdev-lock to video-mutex and remove the queue-mutex altogether since video-mutex will now be used for all locking. I only need to take the video-mutex in uvc_v4l2_release() as well. If you agree with that, then I'll make that change. That sounds good to me. I haven't really tried to optimize locking in the UVC gadget driver, so relying on core locking is fine. Could you split that in two patches, one that switches to core locking, and another that switches to unlocked_ioctl ? Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/usb/gadget/function/f_uvc.c| 1 + drivers/usb/gadget/function/uvc.h | 1 + drivers/usb/gadget/function/uvc_v4l2.c | 6 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 945b3bd..748a80c 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -817,6 +817,7 @@ static struct usb_function *uvc_alloc(struct usb_function_instance *fi) if (uvc == NULL) return ERR_PTR(-ENOMEM); + mutex_init(uvc-video.mutex); We need a corresponding mutex_destroy() somewhere. Why? Few drivers do so. If you want it, then I'll do that, but it's not required to my knowledge. I somehow thought mutex_destroy() was required to avoid leakages when mutex debugging is enabled, but it turns out I'm wrong. Omitting it thus seems fine. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uvcvideo: Don't call vb2 mmap and get_unmapped_area with queue lock held
videobuf2 has long been subject to AB-BA style deadlocks due to the
queue lock and mmap_sem being taken in different orders for the mmap and
get_unmapped_area operations. The problem has been fixed by making those
two operations callable without taking the queue lock, using an
mmap_lock internal to videobuf2.
The uvcvideo driver still calls the mmap and get_unmapped_area
operations with the queue lock held, resulting in a potential deadlock.
As the operations can now be called without locking the queue, fix it.
Reported-by: Bjørn Mork bj...@mork.no
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_queue.c | 15 ++-
1 file changed, 2 insertions(+), 13 deletions(-)
Bjørn, does this fix the circular locking dependency you have reported in
[v3.19-rc7] possible circular locking dependency in uvc_queue_streamoff ?
The report mentions involves locks, so I'm not 100% this patch will fix the
issue.
diff --git a/drivers/media/usb/uvc/uvc_queue.c
b/drivers/media/usb/uvc/uvc_queue.c
index 10c554e..87a19f3 100644
--- a/drivers/media/usb/uvc/uvc_queue.c
+++ b/drivers/media/usb/uvc/uvc_queue.c
@@ -306,25 +306,14 @@ int uvc_queue_streamoff(struct uvc_video_queue *queue,
enum v4l2_buf_type type)
int uvc_queue_mmap(struct uvc_video_queue *queue, struct vm_area_struct *vma)
{
- int ret;
-
- mutex_lock(queue-mutex);
- ret = vb2_mmap(queue-queue, vma);
- mutex_unlock(queue-mutex);
-
- return ret;
+ return vb2_mmap(queue-queue, vma);
}
#ifndef CONFIG_MMU
unsigned long uvc_queue_get_unmapped_area(struct uvc_video_queue *queue,
unsigned long pgoff)
{
- unsigned long ret;
-
- mutex_lock(queue-mutex);
- ret = vb2_get_unmapped_area(queue-queue, 0, 0, pgoff, 0);
- mutex_unlock(queue-mutex);
- return ret;
+ return vb2_get_unmapped_area(queue-queue, 0, 0, pgoff, 0);
}
#endif
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] uvcvideo: Recognize the Tasco USB microscope
The device is based on an Aveo chipset, implements UVC but advertises a
vendor-specific class on all interfaces.
Support it by listing the USB VID:PID explicitly.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
drivers/media/usb/uvc/uvc_driver.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/media/usb/uvc/uvc_driver.c
b/drivers/media/usb/uvc/uvc_driver.c
index 7f5003c..62359f6 100644
--- a/drivers/media/usb/uvc/uvc_driver.c
+++ b/drivers/media/usb/uvc/uvc_driver.c
@@ -2482,6 +2482,14 @@ static struct usb_device_id uvc_ids[] = {
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_PROBE_MINMAX
| UVC_QUIRK_PROBE_EXTRAFIELDS },
+ /* Aveo Technology USB 2.0 Camera (Tasco USB Microscope) */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x1871,
+ .idProduct= 0x0516,
+ .bInterfaceClass = USB_CLASS_VENDOR_SPEC,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0 },
/* Ecamm Pico iMage */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Can the patch adding support for the Tasco USB microscope be queued up?
Hi Hans, On Monday 16 February 2015 17:08:52 Hans Verkuil wrote: On 02/16/2015 05:01 PM, Michael Hall wrote: My apologies, the other emails were sent to linux-uvc-devel, not linux-media. Do you want an attached patch file, or simply a diff in the body of the email? I'm also not clear on what you mean by correct Signed-off-by line, I have very little experience with git, I've mostly used bzr. This is a good link with the relevant information: http://linuxtv.org/wiki/index.php/Development:_How_to_submit_patches Anyway, I checked where the original patch came from, and Laurent Pinchart wrote it. Since he's kernel maintainer he knows all about well-formatted patches and it's best if he just posts and merges his own patch :-) Laurent, it's all yours! I've sent the patch to linux-media and will include it in my next uvcvideo pull request. Steven, could you please send me the output of lsusb -v -d '1871:0516' (if possible running as root) on your system ? On 02/16/2015 10:40 AM, Hans Verkuil wrote: On 02/16/2015 04:31 PM, Michael Hall wrote: This is now the 3rd or 4th email to this list requesting that this patch be merged in. If there is something wrong with the patch that needs fixing, please let me know and I will work on the fix. Otherwise I've lost interest in pushing to get it into upstream. I can't remember ever seeing a patch for that posted to the linux-media mailinglist. The best way is just to post the patch to this mailinglist, check that it appears in patchwork (https://patchwork.linuxtv.org/project/linux-media/list/), make sure you keep the author and correct Signed-off-by line and it's *guaranteed* that someone will look at it, and merge it or reply to it if there are problems. Mails like 'please pick up a patch from some other git repo' are very likely to be forgotten due to volume of other postings. Patchwork won't pick them up and that's what we all rely on. So if either of you can just post this as a properly formatted patch, then it will be taken care of. Regards, Hans Michael Hall mhall...@gmail.com On 02/16/2015 10:08 AM, Steven Zakulec wrote: Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. Thank you! -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. regards Antti I've tested this patch by applying it to current media-master and it applies cleanly and builds without issue for me. More information on the card can be found at: http://prospero-tech.com/vortex-1-dvb-t-pcie-card/ Regards, Philip Downer Philip Downer (1): [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd. drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c -- 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: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Hi Antti, On Mon, Feb 16, 2015 at 8:01 PM, Antti Palosaari cr...@iki.fi wrote: Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. Yes, all those tuners can be operated independently. So would I be correct in saying that in Linux an adapter is an independent tuner? In that case the only time you would have frontend0, frontend1 etc is when there is a single dvb source that is switched between tuners? -- Philip Downer +44 (0)7879 470 969 pdow...@prospero-tech.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
Re: [RFC PATCH 0/1] [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd.
Em Mon, 16 Feb 2015 22:01:07 +0200 Antti Palosaari cr...@iki.fi escreveu: Moikka! On 02/16/2015 09:48 PM, Philip Downer wrote: The Vortex PCIe card by Prospero Technologies Ltd is a modular DVB card with a hardware demux, the card can support up to 8 modules which are fixed to the board at assembly time. Currently we only offer one configuration, 8 x Dibcom 7090p DVB-t tuners, but we will soon be releasing other configurations. There is also a connector for an infra-red receiver dongle on the board which supports RAW IR. The driver has been in testing on our systems (ARM Cortex-A9, Marvell Sheva, x86, x86-64) for longer than 6 months, so I'm confident that it works. However as this is the first Linux driver I've written, I'm sure there are some things that I've got wrong. One thing in particular which has been raised by one of our early testers is that we currently register all of our frontends as being attached to one adapter. This means the device is enumerated in /dev like this: /dev/dvb/adapter0/frontend0 /dev/dvb/adapter0/dvr0 /dev/dvb/adapter0/demux0 /dev/dvb/adapter0/frontend1 /dev/dvb/adapter0/dvr1 /dev/dvb/adapter0/demux1 /dev/dvb/adapter0/frontend2 /dev/dvb/adapter0/dvr2 /dev/dvb/adapter0/demux2 etc. Whilst I think this is ok according to the spec, our tester has complained that it's incompatible with their software which expects to find just one frontend per adapter. So I'm wondering if someone could confirm if what I've done with regards to this is correct. As I understand all those tuners are independent (could be used same time) you should register those as a 8 adapters, each having single frontend, dvr and demux. Yeah, creating one adapter per device is the best solution, if you can't do things like: frontend0 - demux2 - dvr5 If such configuration is allowed, then the best is to use the media controller API. The patches for it were just added. Yet, userspace programs are not aware, as this will be merged upstream only for Kernel 3.21. For now, the media controller API is still experimental. Regards, Mauro regards Antti I've tested this patch by applying it to current media-master and it applies cleanly and builds without issue for me. More information on the card can be found at: http://prospero-tech.com/vortex-1-dvb-t-pcie-card/ Regards, Philip Downer Philip Downer (1): [media] pci: Add support for DVB PCIe cards from Prospero Technologies Ltd. drivers/media/pci/Kconfig |1 + drivers/media/pci/Makefile|2 + drivers/media/pci/prospero/Kconfig|7 + drivers/media/pci/prospero/Makefile |7 + drivers/media/pci/prospero/prospero_common.h | 264 drivers/media/pci/prospero/prospero_fe.h |5 + drivers/media/pci/prospero/prospero_fe_main.c | 466 ++ drivers/media/pci/prospero/prospero_i2c.c | 449 ++ drivers/media/pci/prospero/prospero_i2c.h |3 + drivers/media/pci/prospero/prospero_ir.c | 150 ++ drivers/media/pci/prospero/prospero_ir.h |4 + drivers/media/pci/prospero/prospero_main.c| 2086 + 12 files changed, 3444 insertions(+) create mode 100644 drivers/media/pci/prospero/Kconfig create mode 100644 drivers/media/pci/prospero/Makefile create mode 100644 drivers/media/pci/prospero/prospero_common.h create mode 100644 drivers/media/pci/prospero/prospero_fe.h create mode 100644 drivers/media/pci/prospero/prospero_fe_main.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.c create mode 100644 drivers/media/pci/prospero/prospero_i2c.h create mode 100644 drivers/media/pci/prospero/prospero_ir.c create mode 100644 drivers/media/pci/prospero/prospero_ir.h create mode 100644 drivers/media/pci/prospero/prospero_main.c -- 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: [PATCHv4 25/25] [media] dvb_frontend: start media pipeline while thread is running
On 02/13/2015 11:58 PM, Mauro Carvalho Chehab wrote:
While the DVB thread is running, the media pipeline should be
streaming. This should prevent any attempt of using the analog
TV while digital TV is working, and vice-versa.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/dvb_frontend.c
index 50bc6056e914..aa5306908193 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -131,6 +131,11 @@ struct dvb_frontend_private {
int quality;
unsigned int check_wrapped;
enum dvbfe_search algo_status;
+
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ struct media_pipeline pipe;
+ struct media_entity *pipe_start_entity;
+#endif
};
static void dvb_frontend_wakeup(struct dvb_frontend *fe);
@@ -608,9 +613,9 @@ static void dvb_frontend_wakeup(struct dvb_frontend *fe)
* or 0 if everything is OK, if no tuner is linked to the frontend or if the
* mdev is NULL.
*/
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
static int dvb_enable_media_tuner(struct dvb_frontend *fe)
{
-#ifdef CONFIG_MEDIA_CONTROLLER_DVB
struct dvb_frontend_private *fepriv = fe-frontend_priv;
struct dvb_adapter *adapter = fe-dvb;
struct media_device *mdev = adapter-mdev;
@@ -618,10 +623,14 @@ static int dvb_enable_media_tuner(struct dvb_frontend
*fe)
struct media_link *link, *found_link = NULL;
int i, ret, n_links = 0, active_links = 0;
+ fepriv-pipe_start_entity = NULL;
+
if (!mdev)
return 0;
entity = fepriv-dvbdev-entity;
+ fepriv-pipe_start_entity = entity;
+
for (i = 0; i entity-num_links; i++) {
link = entity-links[i];
if (link-sink-entity == entity) {
@@ -648,6 +657,7 @@ static int dvb_enable_media_tuner(struct dvb_frontend *fe)
}
source = found_link-source-entity;
+ fepriv-pipe_start_entity = source;
for (i = 0; i source-num_links; i++) {
struct media_entity *sink;
int flags = 0;
@@ -672,9 +682,9 @@ static int dvb_enable_media_tuner(struct dvb_frontend *fe)
source-name, sink-name,
flags ? ENABLED : disabled);
}
-#endif
return 0;
}
+#endif
static int dvb_frontend_thread(void *data)
{
@@ -696,12 +706,19 @@ static int dvb_frontend_thread(void *data)
fepriv-wakeup = 0;
fepriv-reinitialise = 0;
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
With this change I get this warning:
drivers/media/dvb-core/dvb_frontend.c: In function ‘dvb_frontend_thread’:
drivers/media/dvb-core/dvb_frontend.c:695:6: warning: unused variable ‘ret’
[-Wunused-variable]
int ret;
^
So the 'ret' variable declaration should be under #ifdef
CONFIG_MEDIA_CONTROLLER_DVB
as well.
Regards,
Hans
ret = dvb_enable_media_tuner(fe);
if (ret) {
/* FIXME: return an error if it fails */
dev_info(fe-dvb-device,
proceeding with FE task\n);
+ } else {
+ ret = media_entity_pipeline_start(fepriv-pipe_start_entity,
+ fepriv-pipe);
+ if (ret)
+ return ret;
}
+#endif
dvb_frontend_init(fe);
@@ -812,6 +829,11 @@ restart:
}
}
+#ifdef CONFIG_MEDIA_CONTROLLER_DVB
+ media_entity_pipeline_stop(fepriv-pipe_start_entity);
+ fepriv-pipe_start_entity = NULL;
+#endif
+
if (dvb_powerdown_on_sleep) {
if (fe-ops.set_voltage)
fe-ops.set_voltage(fe, SEC_VOLTAGE_OFF);
--
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: Recent commit introduces compiler Error in some platforms
On Mon, Feb 16, 2015 at 01:36:43PM +0100, Hans Verkuil wrote: On 02/16/2015 01:18 PM, Luis de Bethencourt wrote: Hi all, As can be seen in Han's build log: http://hverkuil.home.xs4all.nl/logs/Saturday.log The recent commit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a compiler error in some platforms. /home/hans/work/build/media_build/v4l/ir-hix5hd2.c: In function 'hix5hd2_ir_config': /home/hans/work/build/media_build/v4l/ir-hix5hd2.c:95:2: error: implicit declaration of function 'writel_relaxed' [-Werror=implicit-function-declaration] writel_relaxed(0x01, priv-base + IR_ENABLE); ^ Better than reverting, what would be a good solution for this problem? I am happy to implment it once I know what is the right direction. From what I see that commit mentions that the function is now available from include/asm-generic/io.h, but this isn't included. I've just fixed the media_build repository to handle this. Do a git pull and it should compile again (only tested against kernel 3.18). Regards, Hans Great! Nice to know this is already fixed. Thanks, Luis Thanks, Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: vivid test device: Add NV{12,21} and Y{U,V}12 pixel format.
Hi Miguel,
On 02/11/2015 07:39 PM, Miguel Casas-Sanchez wrote:
Add support for vertical + horizontal subsampled formats to vivid and use it
to
generate YU12, YV12, NV12, NV21 as defined in [1,2]. These formats are tightly
packed N planar, because they provide chroma(s) as a separate array, but they
are not mplanar yet, as discussed in the list.
The modus operandi is to let tpg_fillbuffer() create a YUYV packed format per
pattern line as usual and apply downsampling if needed immediately afterwards,
in a new function called tpg_apply_downsampling(). This one will unpack as
needed, and average the chroma samples (note that luma samples are never
downsampled). (Some provisions for horizontal downsampling are made, so it can
be followed up with e.g. YUV410 etc formats, please understand in this
context).
Writing the text information on top of the produced pattern also needs a bit
of
a retouch.
[1] http://linuxtv.org/downloads/v4l-dvb-apis/re30.html
[2] http://linuxtv.org/downloads/v4l-dvb-apis/re24.html
Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org
I'm afraid there are a number of issues with this patch that prevent it from
being
merged. First of all, your mailer wraps around long lines, making it impossible
to
apply this patch. Instead, I've used your earlier post that attached the patch.
I'm
assuming the two are identical.
Secondly, I noticed various spurious whitespace changes that made the patch
longer
than necessary. Thirdly, you didn't check the patch with checkpatch.pl.
Also note that the ENUM_FMT descriptions are too long: the string is cut off.
Easy
to see with qv4l2.
Much more serious is that you break the pattern movements, the border, the
square
and the vertical flip support for these new pixel formats. That really must
remain
functional. The 'Insert SAV/EAV Code' controls are also not working, but in all
fairness, I don't think those make sense for these subsampled formats.
Cropping and scaling is also broken.
I noticed that when printing the text you only fill in the luma and not the
chroma,
effectively making that transparent. Which may not be a bad idea. However, note
that
the 'Noise' test pattern is broken with the new formats.
Conclusion: there is a lot more work to be done here...
Regards,
Hans
---
drivers/media/platform/vivid/vivid-kthread-cap.c | 6 +-
drivers/media/platform/vivid/vivid-tpg.c | 232
+++
drivers/media/platform/vivid/vivid-tpg.h | 15 +-
drivers/media/platform/vivid/vivid-vid-common.c | 28 +++
4 files changed, 238 insertions(+), 43 deletions(-)
diff --git a/drivers/media/platform/vivid/vivid-kthread-cap.c
b/drivers/media/platform/vivid/vivid-kthread-cap.c
index 39a67cf..93c6ca3 100644
--- a/drivers/media/platform/vivid/vivid-kthread-cap.c
+++ b/drivers/media/platform/vivid/vivid-kthread-cap.c
@@ -669,8 +669,7 @@ static void vivid_thread_vid_cap_tick(struct
vivid_dev *dev, int dropped_bufs)
if (vid_cap_buf) {
/* Fill buffer */
vivid_fillbuff(dev, vid_cap_buf);
- dprintk(dev, 1, filled buffer %d\n,
- vid_cap_buf-vb.v4l2_buf.index);
+ dprintk(dev, 1, filled buffer %d\n,
vid_cap_buf-vb.v4l2_buf.index);
/* Handle overlay */
if (dev-overlay_cap_owner dev-fb_cap.base
@@ -679,8 +678,7 @@ static void vivid_thread_vid_cap_tick(struct
vivid_dev *dev, int dropped_bufs)
vb2_buffer_done(vid_cap_buf-vb, dev-dqbuf_error ?
VB2_BUF_STATE_ERROR : VB2_BUF_STATE_DONE);
- dprintk(dev, 2, vid_cap buffer %d done\n,
- vid_cap_buf-vb.v4l2_buf.index);
+ dprintk(dev, 2, vid_cap buffer %d done\n,
vid_cap_buf-vb.v4l2_buf.index);
}
if (vbi_cap_buf) {
diff --git a/drivers/media/platform/vivid/vivid-tpg.c
b/drivers/media/platform/vivid/vivid-tpg.c
index 34493f4..d72e19a 100644
--- a/drivers/media/platform/vivid/vivid-tpg.c
+++ b/drivers/media/platform/vivid/vivid-tpg.c
@@ -193,6 +193,10 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_UYVY:
case V4L2_PIX_FMT_YVYU:
case V4L2_PIX_FMT_VYUY:
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
tpg-is_yuv = true;
break;
default:
@@ -224,12 +228,32 @@ bool tpg_s_fourcc(struct tpg_data *tpg, u32 fourcc)
case V4L2_PIX_FMT_ABGR32:
tpg-twopixelsize[0] = 2 * 4;
break;
+ case V4L2_PIX_FMT_NV12:
+ case V4L2_PIX_FMT_NV21:
+ case V4L2_PIX_FMT_YUV420:
+ case V4L2_PIX_FMT_YVU420:
+ tpg-twopixelsize[0] = 3;
+ break;
case V4L2_PIX_FMT_NV16M:
case V4L2_PIX_FMT_NV61M:
[GIT PULL for v3.21] Various fixes
Hi Mauro, Just a bunch of various fixes for v3.21. Same as the pull request I posted three hours ago, but with the addition of Pablo Anton's patch. Regards, Hans The following changes since commit 135f9be9194cf7778eb73594aa55791b229cf27c: [media] dvb_frontend: start media pipeline while thread is running (2015-02-13 21:10:17 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.21a for you to fetch changes up to f04996a39b27bf9f4404c90aa5d73a0469422fa2: media: i2c: ADV7604: Rename adv7604 prefixes. (2015-02-16 15:17:38 +0100) Alexey Khoroshilov (1): sh_vou: fix memory leak on error paths in sh_vou_open() Christian Engelmayer (1): cx88: Fix possible leak in cx8802_probe() Geert Uytterhoeven (2): am437x: VIDEO_AM437X_VPFE should depend on HAS_DMA timberdale: VIDEO_TIMBERDALE should depend on HAS_DMA Hans Verkuil (1): DocBook media: fix validation error Kiran Padwal (1): staging: dt3155v4l: Switch to using managed resource with devm_ Luis de Bethencourt (1): media: bcm2048: remove unused return of function Markus Elfring (2): stk-webcam: Delete an unnecessary check before the function call vfree au0828: Delete unnecessary checks before the function call video_unregister_device Mauro Carvalho Chehab (1): fixp-arith: replace sin/cos table by a better precision one Nicholas Mc Guire (4): cx231xx: drop condition with no effect si470x: fixup wait_for_completion_timeout return handling media: radio: assign wait_for_completion_timeout to appropriately typed var media: radio: handle timeouts Pablo Anton (1): media: i2c: ADV7604: Rename adv7604 prefixes. Prashant Laddha (2): vivid sdr: Use LUT based implementation for sin/cos() vivid sdr: fix broken sine tone generated for sdr FM jean-michel.hautb...@vodalys.com (2): media: i2c: ADV7604: In free run mode, signal is locked media: adv7604: CP CSC uses a different register on adv7604 and adv7611 Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml | 2 +- drivers/input/ff-memless.c | 18 +- drivers/media/i2c/adv7604.c | 915 drivers/media/pci/cx88/cx88-mpeg.c | 3 +- drivers/media/platform/Kconfig | 2 +- drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/sh_vou.c | 9 +- drivers/media/platform/vivid/vivid-sdr-cap.c| 66 +++--- drivers/media/radio/radio-wl1273.c | 27 ++- drivers/media/radio/si470x/radio-si470x-common.c| 14 +- drivers/media/usb/au0828/au0828-video.c | 8 +- drivers/media/usb/cx231xx/cx231xx-core.c| 13 +- drivers/media/usb/gspca/ov534.c | 11 +- drivers/media/usb/stkwebcam/stk-webcam.c| 6 +- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +- drivers/staging/media/dt3155v4l/dt3155v4l.c | 13 +- include/linux/fixp-arith.h | 145 +--- include/media/adv7604.h | 83 +++ 18 files changed, 705 insertions(+), 636 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
Re: [PATCH] media: vivid test device: Add NV{12,21} and Y{U,V}12 pixel format.
On 02/16/2015 03:11 PM, Hans Verkuil wrote: Hi Miguel, On 02/11/2015 07:39 PM, Miguel Casas-Sanchez wrote: Add support for vertical + horizontal subsampled formats to vivid and use it to generate YU12, YV12, NV12, NV21 as defined in [1,2]. These formats are tightly packed N planar, because they provide chroma(s) as a separate array, but they are not mplanar yet, as discussed in the list. The modus operandi is to let tpg_fillbuffer() create a YUYV packed format per pattern line as usual and apply downsampling if needed immediately afterwards, in a new function called tpg_apply_downsampling(). This one will unpack as needed, and average the chroma samples (note that luma samples are never downsampled). (Some provisions for horizontal downsampling are made, so it can be followed up with e.g. YUV410 etc formats, please understand in this context). Writing the text information on top of the produced pattern also needs a bit of a retouch. [1] http://linuxtv.org/downloads/v4l-dvb-apis/re30.html [2] http://linuxtv.org/downloads/v4l-dvb-apis/re24.html Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org I'm afraid there are a number of issues with this patch that prevent it from being merged. First of all, your mailer wraps around long lines, making it impossible to apply this patch. Instead, I've used your earlier post that attached the patch. I'm assuming the two are identical. Secondly, I noticed various spurious whitespace changes that made the patch longer than necessary. Thirdly, you didn't check the patch with checkpatch.pl. Also note that the ENUM_FMT descriptions are too long: the string is cut off. Easy to see with qv4l2. Much more serious is that you break the pattern movements, the border, the square and the vertical flip support for these new pixel formats. That really must remain functional. The 'Insert SAV/EAV Code' controls are also not working, but in all fairness, I don't think those make sense for these subsampled formats. Cropping and scaling is also broken. I noticed that when printing the text you only fill in the luma and not the chroma, effectively making that transparent. Which may not be a bad idea. However, note that the 'Noise' test pattern is broken with the new formats. Conclusion: there is a lot more work to be done here... For the record, I really hope you'll continue with this as it is a very nice and useful addition, but I did think you were overly optimistic about how easy it would be to add this feature. There was a reason after all why I decided not to add it and leave it for the future... 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
cron job: media_tree daily build: ABI WARNING
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 Feb 17 04:00:23 CET 2015 git branch: test git hash: 135f9be9194cf7778eb73594aa55791b229cf27c gcc version:i686-linux-gcc (GCC) 4.9.1 sparse version: v0.5.0-41-g6c2d743 smatch version: 0.4.1-3153-g7d56ab3 host hardware: x86_64 host os:3.18.0-5.slh.1-amd64 linux-git-arm-at91: OK linux-git-arm-davinci: WARNINGS linux-git-arm-exynos: OK linux-git-arm-mx: OK linux-git-arm-omap: OK linux-git-arm-omap1: OK linux-git-arm-pxa: OK linux-git-blackfin: OK linux-git-i686: OK linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-sh: OK linux-git-x86_64: OK linux-2.6.32.27-i686: OK linux-2.6.33.7-i686: OK linux-2.6.34.7-i686: OK linux-2.6.35.9-i686: OK linux-2.6.36.4-i686: OK linux-2.6.37.6-i686: OK linux-2.6.38.8-i686: OK linux-2.6.39.4-i686: OK linux-3.0.60-i686: OK linux-3.1.10-i686: OK linux-3.2.37-i686: OK linux-3.3.8-i686: OK linux-3.4.27-i686: OK linux-3.5.7-i686: OK linux-3.6.11-i686: OK linux-3.7.4-i686: OK linux-3.8-i686: WARNINGS linux-3.9.2-i686: WARNINGS linux-3.10.1-i686: OK linux-3.11.1-i686: OK linux-3.12.23-i686: OK linux-3.13.11-i686: OK linux-3.14.9-i686: OK linux-3.15.2-i686: OK linux-3.16.7-i686: OK linux-3.17.8-i686: OK linux-3.18.7-i686: OK linux-3.19-i686: OK linux-2.6.32.27-x86_64: OK linux-2.6.33.7-x86_64: OK linux-2.6.34.7-x86_64: OK linux-2.6.35.9-x86_64: OK linux-2.6.36.4-x86_64: OK linux-2.6.37.6-x86_64: OK linux-2.6.38.8-x86_64: OK linux-2.6.39.4-x86_64: OK linux-3.0.60-x86_64: OK linux-3.1.10-x86_64: OK linux-3.2.37-x86_64: OK linux-3.3.8-x86_64: OK linux-3.4.27-x86_64: OK linux-3.5.7-x86_64: OK linux-3.6.11-x86_64: OK linux-3.7.4-x86_64: OK linux-3.8-x86_64: 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.23-x86_64: OK linux-3.13.11-x86_64: OK linux-3.14.9-x86_64: OK linux-3.15.2-x86_64: OK linux-3.16.7-x86_64: OK linux-3.17.8-x86_64: OK linux-3.18.7-x86_64: OK linux-3.19-x86_64: OK apps: OK spec-git: OK ABI WARNING: change for arm-at91 ABI WARNING: change for arm-davinci ABI WARNING: change for arm-exynos ABI WARNING: change for arm-mx ABI WARNING: change for arm-omap ABI WARNING: change for arm-omap1 ABI WARNING: change for arm-pxa ABI WARNING: change for blackfin ABI WARNING: change for i686 ABI WARNING: change for m32r ABI WARNING: change for mips ABI WARNING: change for powerpc64 ABI WARNING: change for sh ABI WARNING: change for x86_64 sparse: WARNINGS smatch: 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: [BUG, workaround] HVR-2200/saa7164 problem with C7 power state
On 02/12/2015 03:38 PM, David Harty wrote: I hadn't changed the PCI Express Configuration to Gen1 because per the http://whirlpool.net.au/wiki/n54l_all_in_one page it didn't appear to help reliably. I've made that change now. I'll report to see if that improves anything, perhaps both changes have to be made in conjunction. So the PCI Express change hasn't seemed to help either. Any other ideas? David -- 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] rtl28xxu: add support for Turbo-X DTT2000
On 02/14/2015 04:11 PM, Dimitris Lampridis wrote:
ID 1b80:d3a4 Afatech
Simply added the PID (0xd3a4) of this DVB-T USB device to the list of
rtl2832u-supported devices. VID (0x1b80) is same as KWORLD2.
Tested and verified to work in amd64 with kernels 3.13.0 and 3.16.0.
Signed-off-by: Dimitris Lampridis dlampri...@logikonlabs.com
Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi
PS. Could someone correct that USB ID vendor name for database? It is
not Afatech, but MaxMedia in my understanding...
http://www.maxmediatek.com/pd-page/DVB-T.htm
Antti
---
drivers/media/dvb-core/dvb-usb-ids.h| 1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
2 files changed, 3 insertions(+)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index 80ab8d0..a9d601d 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -385,4 +385,5 @@
#define USB_PID_PCTV_2002E 0x025c
#define USB_PID_PCTV_2002E_SE 0x025d
#define USB_PID_SVEON_STV27 0xd3af
+#define USB_PID_TURBOX_DTT_2000 0xd3a4
#endif
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 77dcfdf..b11380d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1756,6 +1756,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl28xxu_props, Sveon STV21, NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_SVEON_STV27,
rtl28xxu_props, Sveon STV27, NULL) },
+ { DVB_USB_DEVICE(USB_VID_KWORLD_2, USB_PID_TURBOX_DTT_2000,
+ rtl28xxu_props, TURBO-X Pure TV Tuner DTT-2000, NULL) },
/* RTL2832P devices: */
{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
--
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] media: docs: Correct NV{12,21}/M pixel formats, chroma samples used.
On 02/11/2015 08:32 PM, Miguel Casas-Sanchez wrote: Docos says for these pixel formats: start... : Cb00 Cr00 Cb01 Cr01 start... : Cb10 Cr10 Cb11 Cr11 whereas it should read: start... : Cb00 Cr00 Cb11 Cr11 start... : Cb20 Cr20 Cb21 Cr21 where ... depends on the exact multi/single planar format. See e.g. http://linuxtv.org/downloads/v4l-dvb-apis/re30.html and http://linuxtv.org/downloads/v4l-dvb-apis/re31.html Signed-off-by: Miguel Casas-Sanchez mca...@chromium.org Nacked-by: Hans Verkuil hans.verk...@cisco.com The Chroma coordinates are those of the CbCr plane, not the luma plane. This is true for all other YCbCr format descriptions as well. Regards, Hans --- Documentation/DocBook/media/v4l/pixfmt-nv12.xml | 8 Documentation/DocBook/media/v4l/pixfmt-nv12m.xml | 12 ++-- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml index 84dd4fd..4148696 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12.xml @@ -73,15 +73,15 @@ pixel image/title entrystartnbsp;+nbsp;16:/entry entryCbsubscript00/subscript/entry entryCrsubscript00/subscript/entry - entryCbsubscript01/subscript/entry - entryCrsubscript01/subscript/entry + entryCbsubscript02/subscript/entry + entryCrsubscript02/subscript/entry /row row entrystartnbsp;+nbsp;20:/entry entryCbsubscript10/subscript/entry entryCrsubscript10/subscript/entry - entryCbsubscript11/subscript/entry - entryCrsubscript11/subscript/entry + entryCbsubscript22/subscript/entry + entryCrsubscript22/subscript/entry /row /tbody /tgroup diff --git a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml index f3a3d45..e0a35ea 100644 --- a/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml +++ b/Documentation/DocBook/media/v4l/pixfmt-nv12m.xml @@ -83,15 +83,15 @@ CbCr plane has as many pad bytes after its rows./para entrystart1nbsp;+nbsp;0:/entry entryCbsubscript00/subscript/entry entryCrsubscript00/subscript/entry - entryCbsubscript01/subscript/entry - entryCrsubscript01/subscript/entry + entryCbsubscript02/subscript/entry + entryCrsubscript02/subscript/entry /row row entrystart1nbsp;+nbsp;4:/entry - entryCbsubscript10/subscript/entry - entryCrsubscript10/subscript/entry - entryCbsubscript11/subscript/entry - entryCrsubscript11/subscript/entry + entryCbsubscript20/subscript/entry + entryCrsubscript20/subscript/entry + entryCbsubscript22/subscript/entry + entryCrsubscript22/subscript/entry /row /tbody /tgroup -- 2.2.0.rc0.207.ga3a616c -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Recent commit introduces compiler Error in some platforms
Hi all, As can be seen in Han's build log: http://hverkuil.home.xs4all.nl/logs/Saturday.log The recent commit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a compiler error in some platforms. /home/hans/work/build/media_build/v4l/ir-hix5hd2.c: In function 'hix5hd2_ir_config': /home/hans/work/build/media_build/v4l/ir-hix5hd2.c:95:2: error: implicit declaration of function 'writel_relaxed' [-Werror=implicit-function-declaration] writel_relaxed(0x01, priv-base + IR_ENABLE); ^ Better than reverting, what would be a good solution for this problem? I am happy to implment it once I know what is the right direction. From what I see that commit mentions that the function is now available from include/asm-generic/io.h, but this isn't included. Thanks, Luis -- 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: Recent commit introduces compiler Error in some platforms
On 02/16/2015 01:18 PM, Luis de Bethencourt wrote: Hi all, As can be seen in Han's build log: http://hverkuil.home.xs4all.nl/logs/Saturday.log The recent commit bc0c5aa35ac88342831933ca7758ead62d9bae2b introduces a compiler error in some platforms. /home/hans/work/build/media_build/v4l/ir-hix5hd2.c: In function 'hix5hd2_ir_config': /home/hans/work/build/media_build/v4l/ir-hix5hd2.c:95:2: error: implicit declaration of function 'writel_relaxed' [-Werror=implicit-function-declaration] writel_relaxed(0x01, priv-base + IR_ENABLE); ^ Better than reverting, what would be a good solution for this problem? I am happy to implment it once I know what is the right direction. From what I see that commit mentions that the function is now available from include/asm-generic/io.h, but this isn't included. I've just fixed the media_build repository to handle this. Do a git pull and it should compile again (only tested against kernel 3.18). Regards, Hans Thanks, Luis -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PULL FOR v3.21] Various fixes
Hi Mauro, Just a bunch of various fixes for 3.21. Regards, Hans The following changes since commit 135f9be9194cf7778eb73594aa55791b229cf27c: [media] dvb_frontend: start media pipeline while thread is running (2015-02-13 21:10:17 -0200) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git for-v3.21a for you to fetch changes up to 4c75339d0238da17f5d28311373b6335d9f290b1: media: radio: handle timeouts (2015-02-16 12:24:16 +0100) Alexey Khoroshilov (1): sh_vou: fix memory leak on error paths in sh_vou_open() Christian Engelmayer (1): cx88: Fix possible leak in cx8802_probe() Geert Uytterhoeven (2): am437x: VIDEO_AM437X_VPFE should depend on HAS_DMA timberdale: VIDEO_TIMBERDALE should depend on HAS_DMA Hans Verkuil (1): DocBook media: fix validation error Kiran Padwal (1): staging: dt3155v4l: Switch to using managed resource with devm_ Luis de Bethencourt (1): media: bcm2048: remove unused return of function Markus Elfring (2): stk-webcam: Delete an unnecessary check before the function call vfree au0828: Delete unnecessary checks before the function call video_unregister_device Mauro Carvalho Chehab (1): fixp-arith: replace sin/cos table by a better precision one Nicholas Mc Guire (4): cx231xx: drop condition with no effect si470x: fixup wait_for_completion_timeout return handling media: radio: assign wait_for_completion_timeout to appropriately typed var media: radio: handle timeouts Prashant Laddha (2): vivid sdr: Use LUT based implementation for sin/cos() vivid sdr: fix broken sine tone generated for sdr FM jean-michel.hautb...@vodalys.com (2): media: i2c: ADV7604: In free run mode, signal is locked media: adv7604: CP CSC uses a different register on adv7604 and adv7611 Documentation/DocBook/media/v4l/pixfmt-srggb10p.xml | 2 +- drivers/input/ff-memless.c | 18 +++-- drivers/media/i2c/adv7604.c | 17 +++-- drivers/media/pci/cx88/cx88-mpeg.c | 3 +- drivers/media/platform/Kconfig | 2 +- drivers/media/platform/am437x/Kconfig | 2 +- drivers/media/platform/sh_vou.c | 9 +++-- drivers/media/platform/vivid/vivid-sdr-cap.c| 66 ++--- drivers/media/radio/radio-wl1273.c | 27 +- drivers/media/radio/si470x/radio-si470x-common.c| 14 --- drivers/media/usb/au0828/au0828-video.c | 8 +--- drivers/media/usb/cx231xx/cx231xx-core.c| 13 ++- drivers/media/usb/gspca/ov534.c | 11 ++ drivers/media/usb/stkwebcam/stk-webcam.c| 6 +-- drivers/staging/media/bcm2048/radio-bcm2048.c | 4 +- drivers/staging/media/dt3155v4l/dt3155v4l.c | 13 +++ include/linux/fixp-arith.h | 145 +--- 17 files changed, 214 insertions(+), 146 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
Re: [PATCHv2] Partially revert 'Fix DVB devnode representation at media controller'
Em Mon, 16 Feb 2015 13:11:39 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
Partially revert e31a0ba7df6ce21ac4ed58c4182ec12ca8fd78fb (media: Fix DVB
devnode
representation at media controller) and
15d2042107f90f7ce39705716bc2c9a2ec1d5125
(Docbook: Fix documentation for media controller devnodes) commits.
Those commits mark the alsa struct in struct media_entity_desc as deprecated.
However, the alsa struct should remain as it is since it cannot be replaced
by a simple major/minor device node description. The alsa struct was designed
to be used as an alsa card description so V4L2 drivers could use this to
expose
the alsa card that they create to carry the captured audio. Such a card is not
just a PCM device, but also needs to contain the alsa subdevice information,
and it may map to multiple devices, e.g. a PCM and a mixer device, such as the
au0828 usb stick creates.
This is exactly as intended and this cannot and should not be replaced by a
simple major/minor.
However, whether this information is in the right form for an ALSA device such
that it can handle udev renaming rules as well is another matter. So mark this
alsa struct as experimental and document the problems involved.
Updated the documentation as well to reflect this and to reinstate the 'major'
and 'minor' field documentation for the struct dev that was removed in the
original commit.
Updated the documentation to clearly state that struct dev is to be used for
(sub-)devices that create a single device node. Other devices need their own
structure here.
I'm OK with this patch.
I have to say that, when we end by merging media controller support into
ALSA, the best is to not use MEDIA_ENT_T_DEVNODE_ALSA, as we should reserve
MEDIA_ENT_T_DEVNODE_* for the (sub-)devices that have a single devnode
mapping.
So, IMHO, the best would be to create a new type for ALSA (MEDIA_ENT_T_ALSA),
as its properties will be different than a normal MEDIA_ENT_T_DEVNODE.
In other words, something like:
#define MEDIA_ENT_T_DEVNODE (1 MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_V4L2_SUBDEV (2 MEDIA_ENT_TYPE_SHIFT)
#define MEDIA_ENT_T_ALSA(3 MEDIA_ENT_TYPE_SHIFT)
struct media_entity_desc {
/* Common fields for all types/subtypes of entities */
__u32 id;
char name[32];
__u32 type;
__u32 revision;
__u32 flags;
__u32 group_id;
__u16 pads;
__u16 links;
__u32 reserved[4];
/*
* Data specific for a media entity type
*/
union {
/*
* for MEDIA_ENT_T_DEVNODE and MEDIA_ENT_T_V4L2_SUBDEV.
*
* If MEDIA_ENT_T_V4L2_SUBDEV, this is filled only if
* CONFIG_VIDEO_V4L2_SUBDEV_API. Otherwise, major/minor
* should be zero. Perhaps we should add a new flag to
* indicate if subdev devnode info is available.
*/
struct { __u32 major, minor } dev;
/* for MEDIA_ENT_T_ALSA */
struct { __u32 card, device, subdevice } alsa_props; /*
MEDIA_ENT_T_DEVNODE_ALSA */
}
/*
* Data specific to a media entity subtype, if needed
*/
union {
u32 reserved2[172];
}
}
(deprecated fields removed, just to easy the reading of the above struct)
Regards,
Mauro
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index cbf307f..a77c1de 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -145,7 +145,52 @@
entrystruct/entry
entrystructfielddev/structfield/entry
entry/entry
- entryValid for (sub-)devices that create devnodes./entry
+ entryValid for (sub-)devices that create a single device
node./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldmajor/structfield/entry
+ entryDevice node major number./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldminor/structfield/entry
+ entryDevice node minor number./entry
+ /row
+ row
+ entry/entry
+ entrystruct/entry
+ entrystructfieldalsa/structfield/entry
+ entry/entry
+ entryValid for ALSA devices only. This is an link
linkend=experimentalexperimental/link
+ ALSA device specification. If you want to use this, please contact
the
+ linux-media mailing list (v4l-ml;) first.
+ /entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+
work with
My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust you with a business worth 8.3 million USD? Please reply ONLY to my private email: mga...@rogers.com for more information. -- 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: [PATCHv4 15/25] [media] tuner-core: properly initialize media controller subdev
Except for PVR-500, I can't remember any case where the same tuner is used more than once. There is the case of a device with two tuners, one for TV and another one for FM. Yet, on such case, the name of the FM tuner will be different, anyway. So, I don't think this is a current issue, but if the name should be unique, then we need to properly document it. Perhaps I've misunderstood the comment, but HVR-2200/2250 and numerous dib0700 designs are dual DVB tuners. Neither are like the PVR-500 in that they are a single entity with two tuners (as opposed to the PVR-500 which is two PCI devices which happen to be on the same PCB). 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
Re: [PATCHv4 15/25] [media] tuner-core: properly initialize media controller subdev
On 02/16/2015 03:39 PM, Devin Heitmueller wrote: Except for PVR-500, I can't remember any case where the same tuner is used more than once. There is the case of a device with two tuners, one for TV and another one for FM. Yet, on such case, the name of the FM tuner will be different, anyway. So, I don't think this is a current issue, but if the name should be unique, then we need to properly document it. Perhaps I've misunderstood the comment, but HVR-2200/2250 and numerous dib0700 designs are dual DVB tuners. Neither are like the PVR-500 in that they are a single entity with two tuners (as opposed to the PVR-500 which is two PCI devices which happen to be on the same PCB). DVB, yes, but not analog (V4L2) tuners. For DVB tuners the frontend name is used as the entity name, which I assumed is unique. It is, right? If that's not unique, then the same issue is there as well. I have ordered a dual DVB-T board, but I won't have that for another two weeks. 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: [PATCH 0/2] Drop g/s_priority ioctl ops
On 02/03/2015 02:46 PM, Hans Verkuil wrote: Only pvrusb2 is still using the vidioc_g/s_priority ioctl ops. Add struct v4l2_fh support to pvrusb2, allowing us to drop those ioctl ops altogether. This patch series sits on top of the earlier 5 part patch series Remove .ioctl from v4l2_file_operations, but it is probably independent of that one. Note: this is not yet tested. If Mike can't get around to that this week, then I'll give it a spin on Monday. Tested-by: Hans Verkuil hans.verk...@cisco.com 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
Can the patch adding support for the Tasco USB microscope be queued up?
Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. 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/5] uvc gadget: switch to unlocked_ioctl.
On 02/03/2015 02:55 PM, Laurent Pinchart wrote: Hi Hans, Thank you for the patch. On Tuesday 03 February 2015 13:47:24 Hans Verkuil wrote: From: Hans Verkuil hans.verk...@cisco.com Instead of .ioctl use unlocked_ioctl. While all the queue ops already use a lock, there was no lock to protect uvc_video, so add that one. There's more. streamon and streamoff need to be protected by a lock for instance. Wouldn't it be easier to just set vdev-lock for this driver instead of adding manual locking ? I could set vdev-lock to video-mutex and remove the queue-mutex altogether since video-mutex will now be used for all locking. I only need to take the video-mutex in uvc_v4l2_release() as well. If you agree with that, then I'll make that change. Signed-off-by: Hans Verkuil hans.verk...@cisco.com --- drivers/usb/gadget/function/f_uvc.c| 1 + drivers/usb/gadget/function/uvc.h | 1 + drivers/usb/gadget/function/uvc_v4l2.c | 6 +- 3 files changed, 7 insertions(+), 1 deletion(-) diff --git a/drivers/usb/gadget/function/f_uvc.c b/drivers/usb/gadget/function/f_uvc.c index 945b3bd..748a80c 100644 --- a/drivers/usb/gadget/function/f_uvc.c +++ b/drivers/usb/gadget/function/f_uvc.c @@ -817,6 +817,7 @@ static struct usb_function *uvc_alloc(struct usb_function_instance *fi) if (uvc == NULL) return ERR_PTR(-ENOMEM); +mutex_init(uvc-video.mutex); We need a corresponding mutex_destroy() somewhere. Why? Few drivers do so. If you want it, then I'll do that, but it's not required to my knowledge. 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: [PATCHv4 15/25] [media] tuner-core: properly initialize media controller subdev
Hi Hans, On Mon, Feb 16, 2015 at 9:46 AM, Hans Verkuil hverk...@xs4all.nl wrote: On 02/16/2015 03:39 PM, Devin Heitmueller wrote: Except for PVR-500, I can't remember any case where the same tuner is used more than once. There is the case of a device with two tuners, one for TV and another one for FM. Yet, on such case, the name of the FM tuner will be different, anyway. So, I don't think this is a current issue, but if the name should be unique, then we need to properly document it. Perhaps I've misunderstood the comment, but HVR-2200/2250 and numerous dib0700 designs are dual DVB tuners. Neither are like the PVR-500 in that they are a single entity with two tuners (as opposed to the PVR-500 which is two PCI devices which happen to be on the same PCB). DVB, yes, but not analog (V4L2) tuners. For DVB tuners the frontend name is used as the entity name, which I assumed is unique. It is, right? If that's not unique, then the same issue is there as well. I have ordered a dual DVB-T board, but I won't have that for another two weeks. Sorry, I thought this patch was related to the DVB tuner subdev - didn't realize it was for tuner-core (which is obviously analog). The HVR-2200/2250 is a single board with dual hybrid tuners (model 2200 has a DVB-T demod and 2250 has an ATSC demod). In other words, it has two tuners, each of which can be independently tuned to either digital or analog signals. And unlike the PVR-500, it's a single PCIe bridge (saa7164). Regarding your question on DVB tuners, yes - each tuner gets its own frontendX device node (in reality the frontendX points to the digital demodulator, but ultimately it passes the tuning request off to the tuner as well). 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
Re: Can the patch adding support for the Tasco USB microscope be queued up?
This is now the 3rd or 4th email to this list requesting that this patch be merged in. If there is something wrong with the patch that needs fixing, please let me know and I will work on the fix. Otherwise I've lost interest in pushing to get it into upstream. Michael Hall mhall...@gmail.com On 02/16/2015 10:08 AM, Steven Zakulec wrote: Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. 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
[PATCH] cxusb: Use enum to represent table offsets rather than hard-coding numbers
Use enum to represent table offsets rather than hard-coding numbers to avoid
problems with the numbers becoming out of sync with the table.
Signed-off-by: David Howells dhowe...@redhat.com
---
drivers/media/usb/dvb-usb/cxusb.c | 115 +++--
1 file changed, 71 insertions(+), 44 deletions(-)
diff --git a/drivers/media/usb/dvb-usb/cxusb.c
b/drivers/media/usb/dvb-usb/cxusb.c
index f327c49..5bb1c5c 100644
--- a/drivers/media/usb/dvb-usb/cxusb.c
+++ b/drivers/media/usb/dvb-usb/cxusb.c
@@ -1516,28 +1516,55 @@ static void cxusb_disconnect(struct usb_interface *intf)
dvb_usb_device_exit(intf);
}
-static struct usb_device_id cxusb_table [] = {
- { USB_DEVICE(USB_VID_MEDION, USB_PID_MEDION_MD95700) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LG064F_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_LGZ201_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_TH7579_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_4) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2) },
- { USB_DEVICE(USB_VID_DVICO,
USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2_NFW_WARM) },
- { USB_DEVICE(USB_VID_AVERMEDIA, USB_PID_AVERMEDIA_VOLAR_A868R) },
- { USB_DEVICE(USB_VID_DVICO, USB_PID_DVICO_BLUEBIRD_DUAL_4_REV_2) },
- { USB_DEVICE(USB_VID_CONEXANT, USB_PID_CONEXANT_D680_DMB) },
- { USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_D689) },
- { USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230) },
+enum cxusb_table_index {
+ ix_USB_PID_MEDION_MD95700,
+ ix_USB_PID_DVICO_BLUEBIRD_LG064F_COLD,
+ ix_USB_PID_DVICO_BLUEBIRD_LG064F_WARM,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM,
+ ix_USB_PID_DVICO_BLUEBIRD_LGZ201_COLD,
+ ix_USB_PID_DVICO_BLUEBIRD_LGZ201_WARM,
+ ix_USB_PID_DVICO_BLUEBIRD_TH7579_COLD,
+ ix_USB_PID_DVICO_BLUEBIRD_TH7579_WARM,
+ ix_USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD,
+ ix_USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_4,
+ ix_USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2,
+ ix_USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2_NFW_WARM,
+ ix_USB_PID_AVERMEDIA_VOLAR_A868R,
+ ix_USB_PID_DVICO_BLUEBIRD_DUAL_4_REV_2,
+ ix_USB_PID_CONEXANT_D680_DMB,
+ ix_USB_PID_MYGICA_D689,
+ ix_USB_PID_MYGICA_T230,
+ NR__cxusb_table_index
+};
+
+static struct usb_device_id cxusb_table [NR__cxusb_table_index + 1] = {
+#define _(vend, prod) [ix_##prod] = { vend, prod }
+ _(USB_VID_MEDION, USB_PID_MEDION_MD95700), // 0
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_LG064F_COLD),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_LG064F_WARM), // 2
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_1_COLD),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_1_WARM), // 4
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_LGZ201_COLD),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_LGZ201_WARM), // 6
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_TH7579_COLD),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_TH7579_WARM), // 8
+ _(USB_VID_DVICO,USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_COLD),
+ _(USB_VID_DVICO,USB_PID_DIGITALNOW_BLUEBIRD_DUAL_1_WARM), // 10
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_2_COLD),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_2_WARM), // 12
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_4),
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2), // 14
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DVB_T_NANO_2_NFW_WARM),
+ _(USB_VID_AVERMEDIA,USB_PID_AVERMEDIA_VOLAR_A868R), // 16
+ _(USB_VID_DVICO,USB_PID_DVICO_BLUEBIRD_DUAL_4_REV_2),
+ _(USB_VID_CONEXANT, USB_PID_CONEXANT_D680_DMB), // 18
+ _(USB_VID_CONEXANT, USB_PID_MYGICA_D689),
+ _(USB_VID_CONEXANT, USB_PID_MYGICA_T230), // 20
+#undef _
{} /* Terminating entry */
};
MODULE_DEVICE_TABLE (usb, cxusb_table);
@@ -1581,7 +1608,7 @@ static struct
Re: Can the patch adding support for the Tasco USB microscope be queued up?
On 02/16/2015 04:31 PM, Michael Hall wrote: This is now the 3rd or 4th email to this list requesting that this patch be merged in. If there is something wrong with the patch that needs fixing, please let me know and I will work on the fix. Otherwise I've lost interest in pushing to get it into upstream. I can't remember ever seeing a patch for that posted to the linux-media mailinglist. The best way is just to post the patch to this mailinglist, check that it appears in patchwork (https://patchwork.linuxtv.org/project/linux-media/list/), make sure you keep the author and correct Signed-off-by line and it's *guaranteed* that someone will look at it, and merge it or reply to it if there are problems. Mails like 'please pick up a patch from some other git repo' are very likely to be forgotten due to volume of other postings. Patchwork won't pick them up and that's what we all rely on. So if either of you can just post this as a properly formatted patch, then it will be taken care of. Regards, Hans Michael Hall mhall...@gmail.com On 02/16/2015 10:08 AM, Steven Zakulec wrote: Hi, as an owner of a Tasco/Aveo USB microscope detected but not working under Linux, I'd really like to see the patch adding this variant added to the kernel. I've copied the patch's author on the email. The people on the linux-uvc-devel list directed me over here. The patch here: http://sourceforge.net/p/linux-uvc/mailman/message/32434617/ , itself an update of an earlier patch: http://sourceforge.net/p/linux-uvc/mailman/message/29835445/ works. The patch does make the USB microscope work where it didn't work at all before. 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 -- 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 for v3.20] vb2: fix 'UNBALANCED' warnings when calling vb2_thread_stop()
Stopping the vb2 thread (as used by several DVB devices) can result in an 'UNBALANCED' warning such as this: vb2: counters for queue 880407ee9828: UNBALANCED! vb2: setup: 1 start_streaming: 1 stop_streaming: 1 vb2: wait_prepare: 249333 wait_finish: 249334 This is due to a race condition between stopping the thread and calling vb2_internal_streamoff(). While I have not been able to deduce the exact mechanism how this race condition can produce this warning, I can see that the way the stream is stopped is likely to lead to a race somewhere. This patch simplifies how this is done by first ensuring that the thread is completely stopped before cleaning up the vb2 queue. It does that by setting threadio-stop to true, followed by a call to vb2_queue_error() which will wake up the thread. The thread sees that 'stop' is true and it will exit. The call to kthread_stop() waits until the thread has exited, and only then is the queue cleaned up by calling __vb2_cleanup_fileio(). This is a much cleaner sequence and the warning has now disappeared. Reported-by: Jurgen Kramer gtmkra...@xs4all.nl Tested-by: Jurgen Kramer gtmkra...@xs4all.nl Signed-off-by: Hans Verkuil hans.verk...@cisco.com Cc: sta...@vger.kernel.org # for v3.18 and up --- drivers/media/v4l2-core/videobuf2-core.c | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/drivers/media/v4l2-core/videobuf2-core.c b/drivers/media/v4l2-core/videobuf2-core.c index bc08a82..cc16e76 100644 --- a/drivers/media/v4l2-core/videobuf2-core.c +++ b/drivers/media/v4l2-core/videobuf2-core.c @@ -3230,18 +3230,13 @@ int vb2_thread_stop(struct vb2_queue *q) if (threadio == NULL) return 0; - call_void_qop(q, wait_finish, q); threadio-stop = true; - vb2_internal_streamoff(q, q-type); - call_void_qop(q, wait_prepare, q); + /* Wake up all pending sleeps in the thread */ + vb2_queue_error(q); err = kthread_stop(threadio-thread); - q-fileio = NULL; - fileio-req.count = 0; - vb2_reqbufs(q, fileio-req); - kfree(fileio); + __vb2_cleanup_fileio(q); threadio-thread = NULL; kfree(threadio); - q-fileio = NULL; q-threadio = NULL; return err; } -- 2.1.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
Re: [PATCHv4 00/25] dvb core: add basic support for the media controller
Em Mon, 16 Feb 2015 10:55:50 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 02/15/2015 11:27 AM, Mauro Carvalho Chehab wrote: In any case, for ALSA, we should do the right thing here: remove (actually deprecate) whatever definition is there, and then re-add it only when we actually have the patches inside the ALSA subsystem to support the media controller, plus having the corresponding patches for the media-ctl in order to support the devnode discovery using both udev and sysfs for their nodes. I actually thought about how alsa should be handled and it is doing the right thing. See my patch that I posted today, partially reverting your patch. Well, I can live with that patch for now, but I suspect that removing major/minor from ALSA will make things very complex at the userspace side. Do you know how to convert from card/device/subdevice into a device node patch using libudev and sysfs? Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 13/25] [media] dvb_net: add support for DVB net node at the media controller
Em Mon, 16 Feb 2015 10:03:51 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Make the dvb core network support aware of the media controller and
register the corresponding devices.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
Thanks for reviewing this patch series!
diff --git a/drivers/media/dvb-core/dvb_net.c
b/drivers/media/dvb-core/dvb_net.c
index 686d3277dad1..40990058b4bc 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -1462,14 +1462,16 @@ static const struct file_operations dvb_net_fops = {
.llseek = noop_llseek,
};
-static struct dvb_device dvbdev_net = {
+static const struct dvb_device dvbdev_net = {
.priv = NULL,
.users = 1,
.writers = 1,
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ .name = dvb net,
I would suggest 'dvb-net' rather than 'dvb net' with a space. That's a
personal
preference, though.
Works for me. I'll write a patch changing the names to dvb-foo for the
DVB nodes.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 12/25] [media] dvb_ca_en50221: add support for CA node at the media controller
Em Mon, 16 Feb 2015 10:04:50 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Make the dvb core CA support aware of the media controller and
register the corresponding devices.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c
b/drivers/media/dvb-core/dvb_ca_en50221.c
index 0aac3096728e..2bf28eb97a64 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -1638,15 +1638,17 @@ static const struct file_operations dvb_ca_fops = {
.llseek = noop_llseek,
};
-static struct dvb_device dvbdev_ca = {
+static const struct dvb_device dvbdev_ca = {
.priv = NULL,
.users = 1,
.readers = 1,
.writers = 1,
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ .name = ca_en50221,
I'd use 'dvb-ca-en50221': the dvb prefix makes it clear that this is a
dvb core device, and personally I prefer '-' over '_'.
Ok, will do, in order to standardize. Yet, at dvb, the core uses dvb_foo
for the several c files.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 15/25] [media] tuner-core: properly initialize media controller subdev
Em Mon, 16 Feb 2015 10:10:08 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Properly initialize tuner core subdev at the media controller.
That requires a new subtype at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index 559f8372e2eb..9a83b27a7e8f 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -134,6 +134,9 @@ struct tuner {
unsigned inttype; /* chip type id */
void*config;
const char *name;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpad;
+#endif
};
/*
@@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int
type,
t-name = analog_ops-info.name;
}
+ t-sd.entity.name = t-name;
+
tuner_dbg(type set to %s\n, t-name);
t-mode_mask = new_mode_mask;
@@ -592,6 +597,9 @@ static int tuner_probe(struct i2c_client *client,
struct tuner *t;
struct tuner *radio;
struct tuner *tv;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ int ret;
+#endif
t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
if (NULL == t)
@@ -684,6 +692,18 @@ static int tuner_probe(struct i2c_client *client,
/* Should be just before return */
register_client:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ t-pad.flags = MEDIA_PAD_FL_SOURCE;
+ t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.name = t-name;
Will this be a unique name in the case of one board with multiple identical
tuners?
Good point. Well, it should, as otherwise the logs will be confusing, but
we need to double check it, if we have such case.
I don't know if we have any cards like that (my PVR-500 is really two PCI
boards on
one PCB).
Except for PVR-500, I can't remember any case where the same tuner is used
more than once.
There is the case of a device with two tuners, one for TV and another one
for FM. Yet, on such case, the name of the FM tuner will be different,
anyway. So, I don't think this is a current issue, but if the name should
be unique, then we need to properly document it.
Laurent, the name should be unique, right? In any case, the spec needs to be
updated
to clearly state whether or not the name should be unique.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 00/25] dvb core: add basic support for the media controller
On 02/16/2015 11:50 AM, Mauro Carvalho Chehab wrote: Em Mon, 16 Feb 2015 10:55:50 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 02/15/2015 11:27 AM, Mauro Carvalho Chehab wrote: In any case, for ALSA, we should do the right thing here: remove (actually deprecate) whatever definition is there, and then re-add it only when we actually have the patches inside the ALSA subsystem to support the media controller, plus having the corresponding patches for the media-ctl in order to support the devnode discovery using both udev and sysfs for their nodes. I actually thought about how alsa should be handled and it is doing the right thing. See my patch that I posted today, partially reverting your patch. Well, I can live with that patch for now, but I suspect that removing major/minor from ALSA will make things very complex at the userspace side. Do you know how to convert from card/device/subdevice into a device node patch using libudev and sysfs? You don't *want* a device. The user space alsa utilities all operate on card/device/subdevice level. I've never used an alsa device node directly, or seen anyone do that. That's all done by the alsa library. But regardless of whether or not it is right or wrong, as long as we do not actually implement this in a driver I would keep this and wait until we do have a working example. Replacing the alsa struct by a simple major/minor is certainly not enough, of that I am 100% certain. Let's keep it as is, and only touch it again when we actually get the first user. 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: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
Em Mon, 16 Feb 2015 10:11:59 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote: Instead of keeping the media controller entity not initialized, fill it and create the pads for cx25840. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c index 573e08826b9b..bdb5bb6b58da 100644 --- a/drivers/media/i2c/cx25840/cx25840-core.c +++ b/drivers/media/i2c/cx25840/cx25840-core.c @@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client, int default_volume; u32 id; u16 device_id; +#if defined(CONFIG_MEDIA_CONTROLLER) + int ret; +#endif /* Check if the adapter supports the needed features */ if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA)) @@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client, sd = state-sd; v4l2_i2c_subdev_init(sd, client, cx25840_ops); +#if defined(CONFIG_MEDIA_CONTROLLER) + /* TODO: need to represent analog inputs too */ Which analog inputs? Do you mean 'audio inputs' instead? I mean analog video inputs like composite, svideo, etc, e. g. having multiple input pads for the analog demods, like: ___ TUNER | | | | SVIDEO ... | cx25840 | | | COMPOSITE1 ... |_| (in the above, dashes represent the enabled link, and periods represent the disabled ones) In other words, if we want to properly represent the pipeline, it should be possible to see via the media controller if the tuner is being used as an image source, or if the source is something else. I didn't map those other inputs here yet, due to a few things: - Not sure if it is really worth - The extra inputs would require subdevs that won't be controlled - I was in doubt about the best way for doing that - That would likely require some extra setup for cx25840 caller drivers, in order to represent what of the possible internal inputs are actually used on each specific board - I was too lazy to do it ;) Actually, I didn't see much benefit on adding such map now, so I decided to just add a comment inside the source code. Regards, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 12/25] [media] dvb_ca_en50221: add support for CA node at the media controller
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Make the dvb core CA support aware of the media controller and
register the corresponding devices.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-core/dvb_ca_en50221.c
b/drivers/media/dvb-core/dvb_ca_en50221.c
index 0aac3096728e..2bf28eb97a64 100644
--- a/drivers/media/dvb-core/dvb_ca_en50221.c
+++ b/drivers/media/dvb-core/dvb_ca_en50221.c
@@ -1638,15 +1638,17 @@ static const struct file_operations dvb_ca_fops = {
.llseek = noop_llseek,
};
-static struct dvb_device dvbdev_ca = {
+static const struct dvb_device dvbdev_ca = {
.priv = NULL,
.users = 1,
.readers = 1,
.writers = 1,
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ .name = ca_en50221,
I'd use 'dvb-ca-en50221': the dvb prefix makes it clear that this is a
dvb core device, and personally I prefer '-' over '_'.
Regards,
Hans
+#endif
.fops = dvb_ca_fops,
};
-
/*
*/
/* Initialisation/shutdown functions */
--
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] [media] mantis: Move jump label to activate dead code
On Sun, Feb 15, 2015 at 01:11:04PM +0100, Silvan Jegen wrote:
diff --git a/drivers/media/pci/mantis/mantis_cards.c
b/drivers/media/pci/mantis/mantis_cards.c
index 801fc55..e566061 100644
--- a/drivers/media/pci/mantis/mantis_cards.c
+++ b/drivers/media/pci/mantis/mantis_cards.c
@@ -215,10 +215,11 @@ static int mantis_pci_probe(struct pci_dev *pdev,
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DVB initialization
failed %d, err);
goto fail4;
}
+
err = mantis_uart_init(mantis);
if (err 0) {
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART initialization
failed %d, err);
- goto fail6;
+ goto fail5;
}
devs++;
@@ -226,10 +227,10 @@ static int mantis_pci_probe(struct pci_dev *pdev,
return err;
+fail5:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis UART exit! %d, err);
mantis_uart_exit(mantis);
-fail6:
fail4:
dprintk(MANTIS_ERROR, 1, ERROR: Mantis DMA exit! %d, err);
mantis_dma_exit(mantis);
This patch isn't right, I'm afraid. The person who wrote this driver
deliberately added some dead error handling code in case we change it
later and need to activate it. It's an ugly thing to do because it
causes static checker warnings, and confusion, and, in real life, then
we are not ever going to need to activate it. It's defensive
programming but we don't do defensive programming.
http://lwn.net/Articles/604813/ Just delete this dead code.
Also this code uses GW-BASIC style numbered gotos. So ugly! The label
names should be based on what the label location does. Eg
err_uart_exit, err_dma_exit. I have written an essay about label
names: https://plus.google.com/106378716002406849458/posts/dnanfhQ4mHQ
In theory, we should be calling mantis_dvb_exit() if mantis_uart_init()
fails. In reality, it can't fail but it's still wrong to leave that
out.
These patches would be easier to review if you just folded them into one
patch. Call it fix error error handling or something.
regards,
dan carpenter
--
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: [PATCHv4 15/25] [media] tuner-core: properly initialize media controller subdev
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Properly initialize tuner core subdev at the media controller.
That requires a new subtype at the media controller API.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/v4l2-core/tuner-core.c
b/drivers/media/v4l2-core/tuner-core.c
index 559f8372e2eb..9a83b27a7e8f 100644
--- a/drivers/media/v4l2-core/tuner-core.c
+++ b/drivers/media/v4l2-core/tuner-core.c
@@ -134,6 +134,9 @@ struct tuner {
unsigned inttype; /* chip type id */
void*config;
const char *name;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpad;
+#endif
};
/*
@@ -434,6 +437,8 @@ static void set_type(struct i2c_client *c, unsigned int
type,
t-name = analog_ops-info.name;
}
+ t-sd.entity.name = t-name;
+
tuner_dbg(type set to %s\n, t-name);
t-mode_mask = new_mode_mask;
@@ -592,6 +597,9 @@ static int tuner_probe(struct i2c_client *client,
struct tuner *t;
struct tuner *radio;
struct tuner *tv;
+#ifdef CONFIG_MEDIA_CONTROLLER
+ int ret;
+#endif
t = kzalloc(sizeof(struct tuner), GFP_KERNEL);
if (NULL == t)
@@ -684,6 +692,18 @@ static int tuner_probe(struct i2c_client *client,
/* Should be just before return */
register_client:
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ t-pad.flags = MEDIA_PAD_FL_SOURCE;
+ t-sd.entity.type = MEDIA_ENT_T_V4L2_SUBDEV_TUNER;
+ t-sd.entity.name = t-name;
Will this be a unique name in the case of one board with multiple identical
tuners?
I don't know if we have any cards like that (my PVR-500 is really two PCI
boards on
one PCB).
Laurent, the name should be unique, right? In any case, the spec needs to be
updated
to clearly state whether or not the name should be unique.
Regards,
Hans
+
+ ret = media_entity_init(t-sd.entity, 1, t-pad, 0);
+ if (ret 0) {
+ tuner_err(failed to initialize media entity!\n);
+ kfree(t);
+ return -ENODEV;
+ }
+#endif
/* Sets a default mode */
if (t-mode_mask T_ANALOG_TV)
t-mode = V4L2_TUNER_ANALOG_TV;
--
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: [PATCHv4 24/25] [media] cx231xx: enable tuner-decoder link at videobuf start
On 02/13/2015 11:58 PM, Mauro Carvalho Chehab wrote:
The tuner-decoder needs to be enabled when we're about to
start streaming.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c
b/drivers/media/usb/cx231xx/cx231xx-video.c
index f3d1a488dfa7..634763535d60 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -703,6 +703,74 @@ static void free_buffer(struct videobuf_queue *vq,
struct cx231xx_buffer *buf)
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
+static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *mdev = dev-media_dev;
+ struct media_entity *entity, *decoder = NULL, *source;
+ struct media_link *link, *found_link = NULL;
+ int i, ret, active_links = 0;
+
+ if (!mdev)
+ return 0;
+
+/*
+ * This will find the tuner that it is connected into the decoder.
+ * Technically, this is not 100% correct, as the device may be using an
+ * analog input instead of the tuner. However, we can't use the DVB for dvb
'we can't use the DVB for dvb'?? You probably mean 'can't use the DVB API'.
+ * while the DMA engine is being used for V4L2.
+ */
Weird indentation, should be one to the right.
+ media_device_for_each_entity(entity, mdev) {
+ if (entity-type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+ decoder = entity;
+ break;
+ }
+ }
+ if (!decoder)
+ return 0;
+
+ for (i = 0; i decoder-num_links; i++) {
+ link = decoder-links[i];
+ if (link-sink-entity == decoder) {
+ found_link = link;
+ if (link-flags MEDIA_LNK_FL_ENABLED)
+ active_links++;
+ break;
+ }
+ }
+
+ if (active_links == 1 || !found_link)
+ return 0;
+
+ source = found_link-source-entity;
+ for (i = 0; i source-num_links; i++) {
+ struct media_entity *sink;
+ int flags = 0;
+
+ link = source-links[i];
+ sink = link-sink-entity;
+
+ if (sink == entity)
+ flags = MEDIA_LNK_FL_ENABLED;
+
+ ret = media_entity_setup_link(link, flags);
+ if (ret) {
+ dev_err(dev-dev,
+ Couldn't change link %s-%s to %s. Error %d\n,
+ source-name, sink-name,
+ flags ? enabled : disabled,
+ ret);
+ return ret;
+ } else
+ dev_dbg(dev-dev,
+ link %s-%s was %s\n,
+ source-name, sink-name,
+ flags ? ENABLED : disabled);
+ }
+#endif
+ return 0;
+}
+
static int
buffer_prepare(struct videobuf_queue *vq, struct videobuf_buffer *vb,
enum v4l2_field field)
@@ -756,6 +824,9 @@ buffer_prepare(struct videobuf_queue *vq, struct
videobuf_buffer *vb,
}
buf-vb.state = VIDEOBUF_PREPARED;
+
+ cx231xx_enable_analog_tuner(dev);
Is this the right place? Isn't this now called for every QBUF? I would expect
this
to happen when you start streaming.
In vb2 it would be in start_streaming(), of course.
Regards,
Hans
+
return 0;
fail:
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: [PATCHv4 13/25] [media] dvb_net: add support for DVB net node at the media controller
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Make the dvb core network support aware of the media controller and
register the corresponding devices.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/dvb-core/dvb_net.c
b/drivers/media/dvb-core/dvb_net.c
index 686d3277dad1..40990058b4bc 100644
--- a/drivers/media/dvb-core/dvb_net.c
+++ b/drivers/media/dvb-core/dvb_net.c
@@ -1462,14 +1462,16 @@ static const struct file_operations dvb_net_fops = {
.llseek = noop_llseek,
};
-static struct dvb_device dvbdev_net = {
+static const struct dvb_device dvbdev_net = {
.priv = NULL,
.users = 1,
.writers = 1,
+#if defined(CONFIG_MEDIA_CONTROLLER_DVB)
+ .name = dvb net,
I would suggest 'dvb-net' rather than 'dvb net' with a space. That's a personal
preference, though.
Regards,
Hans
+#endif
.fops = dvb_net_fops,
};
-
void dvb_net_release (struct dvb_net *dvbnet)
{
int i;
--
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: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
Instead of keeping the media controller entity not initialized,
fill it and create the pads for cx25840.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/i2c/cx25840/cx25840-core.c
b/drivers/media/i2c/cx25840/cx25840-core.c
index 573e08826b9b..bdb5bb6b58da 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.c
+++ b/drivers/media/i2c/cx25840/cx25840-core.c
@@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client,
int default_volume;
u32 id;
u16 device_id;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ int ret;
+#endif
/* Check if the adapter supports the needed features */
if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA))
@@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client,
sd = state-sd;
v4l2_i2c_subdev_init(sd, client, cx25840_ops);
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ /* TODO: need to represent analog inputs too */
Which analog inputs? Do you mean 'audio inputs' instead?
Regards,
Hans
+ state-pads[0].flags = MEDIA_PAD_FL_SINK; /* Tuner or input */
+ state-pads[1].flags = MEDIA_PAD_FL_SOURCE; /* Video */
+ state-pads[2].flags = MEDIA_PAD_FL_SOURCE; /* VBI */
+ sd-entity.type = MEDIA_ENT_T_V4L2_SUBDEV_DECODER;
+
+ ret = media_entity_init(sd-entity, ARRAY_SIZE(state-pads),
+ state-pads, 0);
+ if (ret 0) {
+ v4l_info(client, failed to initialize media entity!\n);
+ kfree(state);
+ return -ENODEV;
+ }
+#endif
switch (id) {
case CX23885_AV:
diff --git a/drivers/media/i2c/cx25840/cx25840-core.h
b/drivers/media/i2c/cx25840/cx25840-core.h
index 37bc04217c44..17b409f55445 100644
--- a/drivers/media/i2c/cx25840/cx25840-core.h
+++ b/drivers/media/i2c/cx25840/cx25840-core.h
@@ -64,6 +64,9 @@ struct cx25840_state {
wait_queue_head_t fw_wait;/* wake up when the fw load is finished */
struct work_struct fw_work; /* work entry for fw load */
struct cx25840_ir_state *ir_state;
+#if defined(CONFIG_MEDIA_CONTROLLER)
+ struct media_padpads[3];
+#endif
};
static inline struct cx25840_state *to_state(struct v4l2_subdev *sd)
--
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: [PATCHv4 00/25] dvb core: add basic support for the media controller
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote: This patch series adds basic support for the media controller at the DVB core: it creates one media entity per DVB devnode, if the media device is passed as an argument to the DVB structures. The cx231xx driver was modified to pass such argument for DVB NET, DVB frontend and DVB demux. I've posted review comments for several patches and a new patch partially reverting patches 2 and 4. For the other patches: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans - version 4: - Addressed the issues pointed via e-mail - Added a separate Kconfig option to enable media controller DVB experimental support - Fixed some CodingStyle issues - Added documentation for the API changes at the DocBook version 3: - Added the second series of patches (add link graph to cx231xx using the media controller) - tuner-core and cx25840: add proper error handling as suggested by Sakari Ailus and pointed by Joe Perches; - dvb core: move the media_dev struct to be inside the DVB adapter. That allowed to simplify the changes for the dvbdev clients; - Add logic to setup the pipelines when analog or digital TV stream starts. - Renamed some patches to better describe its contents. version 2: - Now the PADs are created for all nodes - Instead of using entity-flags for subtypes, create separate MEDIA_ENT_T_DEVNODE_DVB_foo for each DVB devtype - The API change patch was split from the DVB core changes Mauro Carvalho Chehab (24): [media] media: Fix DVB devnode representation at media controller [media] Docbook: Fix documentation for media controller devnodes [media] media: add new types for DVB devnodes [media] DocBook: Document the DVB API devnodes at the media controller [media] media: add a subdev type for tuner [media] DocBook: Add tuner subdev at documentation [media] dvbdev: add support for media controller [media] cx231xx: add media controller support [media] dvb_frontend: add media controller support for DVB frontend [media] dmxdev: add support for demux/dvr nodes at media controller [media] dvb_ca_en50221: add support for CA node at the media controller [media] dvb_net: add support for DVB net node at the media controller [media] dvbdev: add pad for the DVB devnodes [media] tuner-core: properly initialize media controller subdev [media] cx25840: fill the media controller entity [media] cx231xx: initialize video/vbi pads [media] cx231xx: create media links for analog mode [media] dvbdev: represent frontend with two pads [media] dvbdev: add a function to create DVB media graph [media] cx231xx: create DVB graph [media] dvbdev: enable DVB-specific links [media] dvb-frontend: enable tuner link when the FE thread starts [media] cx231xx: enable tuner-decoder link at videobuf start [media] dvb_frontend: start media pipeline while thread is running Zhangfei Gao (1): [media] ir-hix5hd2: remove writel/readl_relaxed define .../DocBook/media/v4l/media-ioc-enum-entities.xml | 102 --- Documentation/DocBook/media/v4l/v4l2.xml | 9 ++ drivers/media/Kconfig | 10 +- drivers/media/dvb-core/dmxdev.c| 11 +- drivers/media/dvb-core/dvb_ca_en50221.c| 6 +- drivers/media/dvb-core/dvb_frontend.c | 121 - drivers/media/dvb-core/dvb_net.c | 6 +- drivers/media/dvb-core/dvbdev.c| 143 - drivers/media/dvb-core/dvbdev.h| 15 +++ drivers/media/i2c/cx25840/cx25840-core.c | 18 +++ drivers/media/i2c/cx25840/cx25840-core.h | 3 + drivers/media/rc/ir-hix5hd2.c | 8 -- drivers/media/usb/cx231xx/cx231xx-cards.c | 98 +- drivers/media/usb/cx231xx/cx231xx-dvb.c| 5 + drivers/media/usb/cx231xx/cx231xx-video.c | 84 +++- drivers/media/usb/cx231xx/cx231xx.h| 5 + drivers/media/v4l2-core/tuner-core.c | 20 +++ drivers/media/v4l2-core/v4l2-dev.c | 4 +- drivers/media/v4l2-core/v4l2-device.c | 4 +- include/media/media-entity.h | 12 +- include/uapi/linux/media.h | 26 +++- 21 files changed, 592 insertions(+), 118 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] Partially revert 'Fix DVB devnode representation at media controller'
Partially revert e31a0ba7df6ce21ac4ed58c4182ec12ca8fd78fb (media: Fix DVB
devnode
representation at media controller) and 15d2042107f90f7ce39705716bc2c9a2ec1d5125
(Docbook: Fix documentation for media controller devnodes) commits.
Those commits mark the alsa struct in struct media_entity_desc as deprecated.
However, the alsa struct should remain as it is since it cannot be replaced
by a simple major/minor device node description. The alsa struct was designed
to be used as an alsa card description so V4L2 drivers could use this to expose
the alsa card that they create to carry the captured audio. Such a card is not
just a PCM device, but also needs to contain the alsa subdevice information,
and it may map to multiple devices, e.g. a PCM and a mixer device, such as the
au0828 usb stick creates.
This is exactly as intended and this cannot and should not be replaced by a
simple major/minor.
Updated the documentation as well to reflect this and to reinstate the 'major'
and 'minor' field documentation for the struct dev that was removed in the
original commit.
Updated the documentation to clearly state that struct dev is to be used for
(sub-)devices that create a single device node.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index cbf307f..8b22244 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -145,7 +145,49 @@
entrystruct/entry
entrystructfielddev/structfield/entry
entry/entry
- entryValid for (sub-)devices that create devnodes./entry
+ entryValid for (sub-)devices that create a single device
node./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldmajor/structfield/entry
+ entryDevice node major number./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldminor/structfield/entry
+ entryDevice node minor number./entry
+ /row
+ row
+ entry/entry
+ entrystruct/entry
+ entrystructfieldalsa/structfield/entry
+ entry/entry
+ entryValid for ALSA devices only./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldcard/structfield/entry
+ entryALSA card number/entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfielddevice/structfield/entry
+ entryALSA device number/entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldsubdevice/structfield/entry
+ entryALSA sub-device number/entry
/row
row
entry/entry
diff --git a/include/media/media-entity.h b/include/media/media-entity.h
index d6d74bc..ec4e7ad 100644
--- a/include/media/media-entity.h
+++ b/include/media/media-entity.h
@@ -88,6 +88,11 @@ struct media_entity {
u32 major;
u32 minor;
} dev;
+ struct {
+ u32 card;
+ u32 device;
+ u32 subdevice;
+ } alsa;
/* Sub-device specifications */
/* Nothing needed yet */
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 52cc2a6..34a10a5 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -88,6 +88,11 @@ struct media_entity_desc {
__u32 major;
__u32 minor;
} dev;
+ struct {
+ __u32 card;
+ __u32 device;
+ __u32 subdevice;
+ } alsa;
#if 1
/*
@@ -106,11 +111,6 @@ struct media_entity_desc {
__u32 major;
__u32 minor;
} fb;
- struct {
- __u32 card;
- __u32 device;
- __u32 subdevice;
- } alsa;
int dvb;
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv4 00/25] dvb core: add basic support for the media controller
On 02/15/2015 11:27 AM, Mauro Carvalho Chehab wrote:
Em Sat, 14 Feb 2015 12:43:30 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/14/2015 12:00 PM, Mauro Carvalho Chehab wrote:
Em Sat, 14 Feb 2015 10:32:21 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote:
This patch series adds basic support for the media controller at the
DVB core: it creates one media entity per DVB devnode, if the media
device is passed as an argument to the DVB structures.
The cx231xx driver was modified to pass such argument for DVB NET,
DVB frontend and DVB demux.
-
version 4:
- Addressed the issues pointed via e-mail
No, you didn't. Especially with regards to the alsa node definition. I'm
pretty sure you need at least the subdevice information which is now
removed.
Well, back on Jan, 26 I answered your issues about that at:
http://www.spinics.net/lists/linux-media/msg85857.html
As you didn't reply back in a reasonable amount of time, I assumed that
you're happy with that.
In any case, the definitions are still there, as nothing got dropped
from the external header.
So, when ALSA media controller support will be added at the Kernel, we
can decide if it will use major/minor or card/device/subdevice or both.
As I said back in Jan, 26, IMO, the best would be to use both:
struct media_entity_desc {
...
union {
struct {
u32 major;
u32 minor;
} dev;
/* deprecated fields */
...
}
union {
struct {
u32 card;
u32 device;
u32 subdevice;
} alsa_props;
__u8 raw[172];
}
}
(additional and deprecated fields removed just to simplify its
representation above)
Even for ALSA, it is a way easier for libmediactl.c to keep using
major/minor to get the device node name via both udev/sysfs than
using anything else, as I don't think that udev has any method to
find the associated name without major,minor information. Ok, there
are indirect methods using the ALSA API to get such association, but
it is just easier to fill everything at the struct than to add the
extra complexity for the media control clients to convert between
major/minor into card/device/subdevice.
What I'm saying is that the card/device/subdevice really seems to be
an extra property for this specific type of devnode, and not a
replacement.
In any case, I think we should take the decision on how to properly
map the ALSA specific bits when we merge ALSA media controller patches,
and not before.
I also do *not* like the fact that you posted a v4 and immediately applied
these patches to the master without leaving any time for more discussions.
These patches change the kernel API and need to go to proper review and
need
a bunch of Acks, Laurent's at the very minimum since he's MC maintainer.
Please revert the whole patch series from master, then we can discuss this
more.
For the record, for patch 02/25:
Nacked-by: Hans Verkuil hans.verk...@cisco.com
I do *not* agree with this API change.
We can discuss this more on Monday.
This hole series is for discussions for a long time (since the beginning of
January), without rejection, and its now starting to receive patches from
other authors. Keeping it OOT just makes harder to discuss and for people to
test. It is time to move on.
No, it isn't. Laurent and myself actually discussed it during FOSDEM, and
we did have concerns about the API changes. Since he's the MC maintainer I
assumed he would get back to you, but I think he's been very busy since
FOSDEM.
In fact, I believe he attended the Linaro Connect last week, so it is very
likely he will not have had time to do anything with what we discussed at
FOSDEM.
No, I hadn't any return from that, nor by e-mail or IRC, except for Devin's
emails saying he's ok, provided that we'll also look at the cases with
multiple DVB adapters. I have already some patches covering it, but, in
order to discuss, it is important to merge the work I have already done,
plus the patches from Rafael, as my patches are in the top of his ones.
Patches changing the MC API need his Ack at minimum. You can't just post a
v4 patch series and commit the same day. Not when it changes APIs and
especially
not since there were concerns raised about it in the past. You should have
pinged Laurent and probably myself and ask for comments on v4.
My understanding from the last discussions on IRC with Laurent is that, while
he prefers to not get this merged for 3.20, he is ok if I do that. So, I
took the decision of waiting till the merge of the patches for 3.20 to be
merged and adding those patches for 3.21, giving us 2 Kernel cycles to
do a deeper review.
This is basically the same thing I do with all API changes: try to merge
them before -rc1
Re: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
On 02/16/2015 12:11 PM, Mauro Carvalho Chehab wrote: Em Mon, 16 Feb 2015 10:11:59 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote: Instead of keeping the media controller entity not initialized, fill it and create the pads for cx25840. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c index 573e08826b9b..bdb5bb6b58da 100644 --- a/drivers/media/i2c/cx25840/cx25840-core.c +++ b/drivers/media/i2c/cx25840/cx25840-core.c @@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client, int default_volume; u32 id; u16 device_id; +#if defined(CONFIG_MEDIA_CONTROLLER) + int ret; +#endif /* Check if the adapter supports the needed features */ if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA)) @@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client, sd = state-sd; v4l2_i2c_subdev_init(sd, client, cx25840_ops); +#if defined(CONFIG_MEDIA_CONTROLLER) + /* TODO: need to represent analog inputs too */ Which analog inputs? Do you mean 'audio inputs' instead? I mean analog video inputs like composite, svideo, etc, e. g. having multiple input pads for the analog demods, like: ___ TUNER | | | | SVIDEO ... | cx25840 | | | COMPOSITE1 ... |_| (in the above, dashes represent the enabled link, and periods represent the disabled ones) In other words, if we want to properly represent the pipeline, it should be possible to see via the media controller if the tuner is being used as an image source, or if the source is something else. I didn't map those other inputs here yet, due to a few things: - Not sure if it is really worth - The extra inputs would require subdevs that won't be controlled - I was in doubt about the best way for doing that - That would likely require some extra setup for cx25840 caller drivers, in order to represent what of the possible internal inputs are actually used on each specific board - I was too lazy to do it ;) Actually, I didn't see much benefit on adding such map now, so I decided to just add a comment inside the source code. OK, fair enough, I'd have done the same. But if you could extend the comment to include what you just said, then that will be helpful in the future. Thanks! 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: [PATCHv4 24/25] [media] cx231xx: enable tuner-decoder link at videobuf start
Em Mon, 16 Feb 2015 10:27:15 +0100
Hans Verkuil hverk...@xs4all.nl escreveu:
On 02/13/2015 11:58 PM, Mauro Carvalho Chehab wrote:
The tuner-decoder needs to be enabled when we're about to
start streaming.
Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com
diff --git a/drivers/media/usb/cx231xx/cx231xx-video.c
b/drivers/media/usb/cx231xx/cx231xx-video.c
index f3d1a488dfa7..634763535d60 100644
--- a/drivers/media/usb/cx231xx/cx231xx-video.c
+++ b/drivers/media/usb/cx231xx/cx231xx-video.c
@@ -703,6 +703,74 @@ static void free_buffer(struct videobuf_queue *vq,
struct cx231xx_buffer *buf)
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
+static int cx231xx_enable_analog_tuner(struct cx231xx *dev)
+{
+#ifdef CONFIG_MEDIA_CONTROLLER
+ struct media_device *mdev = dev-media_dev;
+ struct media_entity *entity, *decoder = NULL, *source;
+ struct media_link *link, *found_link = NULL;
+ int i, ret, active_links = 0;
+
+ if (!mdev)
+ return 0;
+
+/*
+ * This will find the tuner that it is connected into the decoder.
+ * Technically, this is not 100% correct, as the device may be using an
+ * analog input instead of the tuner. However, we can't use the DVB for dvb
'we can't use the DVB for dvb'?? You probably mean 'can't use the DVB API'.
What I meant to say is that we can't use the device for DVB while it is
doing an analog stream.
I'll fix this on a separate patch.
+ * while the DMA engine is being used for V4L2.
+ */
Weird indentation, should be one to the right.
Ah, true. I'll fix this too.
+ media_device_for_each_entity(entity, mdev) {
+ if (entity-type == MEDIA_ENT_T_V4L2_SUBDEV_DECODER) {
+ decoder = entity;
+ break;
+ }
+ }
+ if (!decoder)
+ return 0;
+
+ for (i = 0; i decoder-num_links; i++) {
+ link = decoder-links[i];
+ if (link-sink-entity == decoder) {
+ found_link = link;
+ if (link-flags MEDIA_LNK_FL_ENABLED)
+ active_links++;
+ break;
+ }
+ }
+
+ if (active_links == 1 || !found_link)
+ return 0;
+
+ source = found_link-source-entity;
+ for (i = 0; i source-num_links; i++) {
+ struct media_entity *sink;
+ int flags = 0;
+
+ link = source-links[i];
+ sink = link-sink-entity;
+
+ if (sink == entity)
+ flags = MEDIA_LNK_FL_ENABLED;
+
+ ret = media_entity_setup_link(link, flags);
+ if (ret) {
+ dev_err(dev-dev,
+ Couldn't change link %s-%s to %s. Error %d\n,
+ source-name, sink-name,
+ flags ? enabled : disabled,
+ ret);
+ return ret;
+ } else
+ dev_dbg(dev-dev,
+ link %s-%s was %s\n,
+ source-name, sink-name,
+ flags ? ENABLED : disabled);
+ }
+#endif
+ return 0;
+}
+
static int
buffer_prepare(struct videobuf_queue *vq, struct videobuf_buffer *vb,
enum v4l2_field field)
@@ -756,6 +824,9 @@ buffer_prepare(struct videobuf_queue *vq, struct
videobuf_buffer *vb,
}
buf-vb.state = VIDEOBUF_PREPARED;
+
+ cx231xx_enable_analog_tuner(dev);
Is this the right place? Isn't this now called for every QBUF? I would expect
this
to happen when you start streaming.
In vb2 it would be in start_streaming(), of course.
True. I think that the vb1 dialog would be, instead, ops-buf_setup.
I'll fix this on a separate patch.
Regards,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH RFC] media: radio: handle timeouts
Hi Nicholas,
On 02/05/2015 09:56 AM, Nicholas Mc Guire wrote:
Add handling for timeout case.
Signed-off-by: Nicholas Mc Guire hof...@osadl.org
---
Some error state/error information seems be get lost int the current code.
(line-numbers are from 3.19.0-rc7.
Assume that on line 827 core-write succeeds but the following
wait_for_completion_timeout times out and the radio-irq_received condition
is not satisfied resulting in goto out;
827 r = core-write(core, WL1273_TUNER_MODE_SET, TUNER_MODE_AUTO_SEEK);
828 if (r)
829 goto out;
830
831 wait_for_completion_timeout(radio-busy, msecs_to_jiffies(1000));
832 if (!(radio-irq_received WL1273_BL_EVENT))
833 goto out;
A similar situation is at line 955 - 859 where a tiemout could occure
and the reported value would be the success value from core-write.
852 reinit_completion(radio-busy);
853 dev_dbg(radio-dev, %s: BUSY\n, __func__);
854
855 r = core-write(core, WL1273_TUNER_MODE_SET, TUNER_MODE_AUTO_SEEK);
856 if (r)
857 goto out;
858
859 wait_for_completion_timeout(radio-busy, msecs_to_jiffies(1000)
the problem is that the value of r now is the success value from core-write
and any timeout and/or failure to detect the expected interrupt is not
reported in
860 out:
861 dev_dbg(radio-dev, %s: Err: %d\n, __func__, r);
862 return r;
Should the wait_for_completion_timeout not report the timeout event by
setting
r to -ETIMEOUT ? respectively use if (!(radio-irq_received
WL1273_BL_EVENT))
to check and set -ETIMEOUT there ?
Comparing this with wl1273_fm_set_tx_freq - the below patch might be suitable
way to handle timeout - but this needs a review by someone who knows the
details of the driver - so this is really just a guess.
While I am certainly not an expert, I agree that the current situation is bad.
I'm taking your patch as-is, since returning a proper error here seems to make
much more sense.
Regards,
Hans
Patch was only compile tested with x86_64_defconfig + CONFIG_MEDIA_SUPPORT=m
CONFIG_MEDIA_CAMERA_SUPPORT=y, CONFIG_V4L_PLATFORM_DRIVERS=y,
CONFIG_MEDIA_RADIO_SUPPORT=y, RADIO_ADAPTER=y, CONFIG_RADIO_WL1273=m
Patch is against 3.19.0-rc7 (localversion-next is -next-20150204)
drivers/media/radio/radio-wl1273.c |9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/radio-wl1273.c
b/drivers/media/radio/radio-wl1273.c
index 571c7f6..6830523 100644
--- a/drivers/media/radio/radio-wl1273.c
+++ b/drivers/media/radio/radio-wl1273.c
@@ -828,9 +828,12 @@ static int wl1273_fm_set_seek(struct wl1273_device
*radio,
if (r)
goto out;
+ /* wait for the FR IRQ */
wait_for_completion_timeout(radio-busy, msecs_to_jiffies(1000));
- if (!(radio-irq_received WL1273_BL_EVENT))
+ if (!(radio-irq_received WL1273_BL_EVENT)) {
+ r = -ETIMEDOUT;
goto out;
+ }
radio-irq_received = ~WL1273_BL_EVENT;
@@ -856,7 +859,9 @@ static int wl1273_fm_set_seek(struct wl1273_device *radio,
if (r)
goto out;
- wait_for_completion_timeout(radio-busy, msecs_to_jiffies(1000));
+ /* wait for the FR IRQ */
+ if (!wait_for_completion_timeout(radio-busy, msecs_to_jiffies(1000)))
+ r = -ETIMEDOUT;
out:
dev_dbg(radio-dev, %s: Err: %d\n, __func__, r);
return r;
--
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 v3][RFC] add raw video stream support for Samsung SUR40
On 02/11/2015 12:52 PM, Florian Echtler wrote: Hello again, does anyone have any suggestions why USERPTR still fails with dma-sg? Could I just disable the corresponding capability for the moment so that the patch could perhaps be merged, and investigate this separately? I prefer to dig into this a little bit more, as I don't really understand it. Set the videobuf2-core debug level to 1 and see what the warnings are. Since 'buf.qbuf' fails in v4l2-compliance, it's something in the VIDIOC_QBUF sequence that returns an error, so you need to pinpoint that. If push comes to shove I can also merge the patch without USERPTR support, but I really prefer not to do that. 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: [PATCH v2 00/15] media: blackfin: bfin_capture enhancements
On 02/02/2015 12:24 PM, Hans Verkuil wrote: On 01/30/2015 04:49 PM, Lad, Prabhakar wrote: Hello Scott, On Thu, Jan 22, 2015 at 10:18 PM, Lad, Prabhakar prabhakar.cse...@gmail.com wrote: This patch series, enhances blackfin capture driver with vb2 helpers. Changes for v2: -- Only patches 5/15 and 8/15 as per Scott's suggestions. Lad, Prabhakar (15): media: blackfin: bfin_capture: drop buf_init() callback media: blackfin: bfin_capture: release buffers in case start_streaming() call back fails media: blackfin: bfin_capture: set min_buffers_needed media: blackfin: bfin_capture: improve buf_prepare() callback media: blackfin: bfin_capture: improve queue_setup() callback media: blackfin: bfin_capture: use vb2_fop_mmap/poll media: blackfin: bfin_capture: use v4l2_fh_open and vb2_fop_release media: blackfin: bfin_capture: use vb2_ioctl_* helpers media: blackfin: bfin_capture: make sure all buffers are returned on stop_streaming() callback media: blackfin: bfin_capture: return -ENODATA for *std calls media: blackfin: bfin_capture: return -ENODATA for *dv_timings calls media: blackfin: bfin_capture: add support for vidioc_create_bufs media: blackfin: bfin_capture: add support for VB2_DMABUF media: blackfin: bfin_capture: add support for VIDIOC_EXPBUF media: blackfin: bfin_capture: set v4l2 buffer sequence drivers/media/platform/blackfin/bfin_capture.c | 311 - 1 file changed, 99 insertions(+), 212 deletions(-) Can you ACK the series ? so that its easier for Hans to pick it up. ping! Scott, I can't take it unless you Ack it. Actually, I'd like to see a 'Tested-by' tag. And if you are testing anyway, then I would really like to see the output of 'v4l2-compliance -s', using the v4l2-compliance from the latest v4l-utils.git. I'm curious to see the results of that. Ping! Again, I need an Ack. 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: [PATCHv4 16/25] [media] cx25840: fill the media controller entity
Em Mon, 16 Feb 2015 12:16:07 +0100 Hans Verkuil hansv...@cisco.com escreveu: On 02/16/2015 12:11 PM, Mauro Carvalho Chehab wrote: Em Mon, 16 Feb 2015 10:11:59 +0100 Hans Verkuil hverk...@xs4all.nl escreveu: On 02/13/2015 11:57 PM, Mauro Carvalho Chehab wrote: Instead of keeping the media controller entity not initialized, fill it and create the pads for cx25840. Signed-off-by: Mauro Carvalho Chehab mche...@osg.samsung.com diff --git a/drivers/media/i2c/cx25840/cx25840-core.c b/drivers/media/i2c/cx25840/cx25840-core.c index 573e08826b9b..bdb5bb6b58da 100644 --- a/drivers/media/i2c/cx25840/cx25840-core.c +++ b/drivers/media/i2c/cx25840/cx25840-core.c @@ -5137,6 +5137,9 @@ static int cx25840_probe(struct i2c_client *client, int default_volume; u32 id; u16 device_id; +#if defined(CONFIG_MEDIA_CONTROLLER) + int ret; +#endif /* Check if the adapter supports the needed features */ if (!i2c_check_functionality(client-adapter, I2C_FUNC_SMBUS_BYTE_DATA)) @@ -5178,6 +5181,21 @@ static int cx25840_probe(struct i2c_client *client, sd = state-sd; v4l2_i2c_subdev_init(sd, client, cx25840_ops); +#if defined(CONFIG_MEDIA_CONTROLLER) + /* TODO: need to represent analog inputs too */ Which analog inputs? Do you mean 'audio inputs' instead? I mean analog video inputs like composite, svideo, etc, e. g. having multiple input pads for the analog demods, like: ___ TUNER | | | | SVIDEO ... | cx25840 | | | COMPOSITE1 ... |_| (in the above, dashes represent the enabled link, and periods represent the disabled ones) In other words, if we want to properly represent the pipeline, it should be possible to see via the media controller if the tuner is being used as an image source, or if the source is something else. I didn't map those other inputs here yet, due to a few things: - Not sure if it is really worth - The extra inputs would require subdevs that won't be controlled - I was in doubt about the best way for doing that - That would likely require some extra setup for cx25840 caller drivers, in order to represent what of the possible internal inputs are actually used on each specific board - I was too lazy to do it ;) Actually, I didn't see much benefit on adding such map now, so I decided to just add a comment inside the source code. OK, fair enough, I'd have done the same. But if you could extend the comment to include what you just said, then that will be helpful in the future. Sure. Will do. Thanks! Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2] Partially revert 'Fix DVB devnode representation at media controller'
Partially revert e31a0ba7df6ce21ac4ed58c4182ec12ca8fd78fb (media: Fix DVB
devnode
representation at media controller) and 15d2042107f90f7ce39705716bc2c9a2ec1d5125
(Docbook: Fix documentation for media controller devnodes) commits.
Those commits mark the alsa struct in struct media_entity_desc as deprecated.
However, the alsa struct should remain as it is since it cannot be replaced
by a simple major/minor device node description. The alsa struct was designed
to be used as an alsa card description so V4L2 drivers could use this to expose
the alsa card that they create to carry the captured audio. Such a card is not
just a PCM device, but also needs to contain the alsa subdevice information,
and it may map to multiple devices, e.g. a PCM and a mixer device, such as the
au0828 usb stick creates.
This is exactly as intended and this cannot and should not be replaced by a
simple major/minor.
However, whether this information is in the right form for an ALSA device such
that it can handle udev renaming rules as well is another matter. So mark this
alsa struct as experimental and document the problems involved.
Updated the documentation as well to reflect this and to reinstate the 'major'
and 'minor' field documentation for the struct dev that was removed in the
original commit.
Updated the documentation to clearly state that struct dev is to be used for
(sub-)devices that create a single device node. Other devices need their own
structure here.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
diff --git a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
index cbf307f..a77c1de 100644
--- a/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
+++ b/Documentation/DocBook/media/v4l/media-ioc-enum-entities.xml
@@ -145,7 +145,52 @@
entrystruct/entry
entrystructfielddev/structfield/entry
entry/entry
- entryValid for (sub-)devices that create devnodes./entry
+ entryValid for (sub-)devices that create a single device
node./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldmajor/structfield/entry
+ entryDevice node major number./entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldminor/structfield/entry
+ entryDevice node minor number./entry
+ /row
+ row
+ entry/entry
+ entrystruct/entry
+ entrystructfieldalsa/structfield/entry
+ entry/entry
+ entryValid for ALSA devices only. This is an link
linkend=experimentalexperimental/link
+ ALSA device specification. If you want to use this, please contact
the
+ linux-media mailing list (v4l-ml;) first.
+ /entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldcard/structfield/entry
+ entryALSA card number/entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfielddevice/structfield/entry
+ entryALSA device number/entry
+ /row
+ row
+ entry/entry
+ entry/entry
+ entry__u32/entry
+ entrystructfieldsubdevice/structfield/entry
+ entryALSA sub-device number/entry
/row
row
entry/entry
diff --git a/include/uapi/linux/media.h b/include/uapi/linux/media.h
index 52cc2a6..bcb2fe8a 100644
--- a/include/uapi/linux/media.h
+++ b/include/uapi/linux/media.h
@@ -91,6 +91,27 @@ struct media_entity_desc {
#if 1
/*
+* EXPERIMENTAL: this shouldn't have been added without
+* actual drivers that use this. When the first real driver
+* appears that sets this information, special attention
+* should be given whether this information is 1) enough, and
+* 2) can deal with udev rules that rename devices. The struct
+* dev would not be sufficient for this since that does not
+* contain the subdevice information. In addition, struct dev
+* can only refer to a single device, and not to multiple (e.g.
+* pcm and mixer devices).
+*
+* So for now mark this as experimental.
+*/
+ struct {
+ __u32 card;
+ __u32 device;
+ __u32 subdevice;
+ } alsa;
+#endif
+
+#if 1
+ /*
* DEPRECATED: previous node specifications. Kept just to
* avoid breaking compilation, but media_entity_desc.dev
* should be used instead. In particular, alsa and dvb
@@
