Re: [PATCH] Fix VIDIOC_TRY_EXT_CTRLS regression
On Mon July 30 2012 03:25:58 Mauro Carvalho Chehab wrote: Em 18-07-2012 10:34, Hans Verkuil escreveu: Hi all, This patch fixes an omission in the new v4l2_ioctls table: VIDIOC_TRY_EXT_CTRLS must get the INFO_FL_CTRL flag, just like all the other control related ioctls. Otherwise the ioctl core won't know it also has to check whether v4l2_fh-ctrl_handler is non-zero before it can decide that this ioctl is not implemented. Caught by v4l2-compliance while I was testing the mem2mem_testdev driver. Missing SOB. It seems Steven asked for this fix. Did he test? If so, it would be nice to get his tested-by:. Oops! Here it is: Signed-off-by: Hans Verkuil hans.verk...@cisco.com Welcome back! Regards, Hans Regards, Mauro Regards, Hans diff --git a/drivers/media/video/v4l2-ioctl.c b/drivers/media/video/v4l2-ioctl.c index 70e0efb..17dff31 100644 --- a/drivers/media/video/v4l2-ioctl.c +++ b/drivers/media/video/v4l2-ioctl.c @@ -1900,7 +1900,7 @@ static struct v4l2_ioctl_info v4l2_ioctls[] = { IOCTL_INFO_FNC(VIDIOC_LOG_STATUS, v4l_log_status, v4l_print_newline, 0), IOCTL_INFO_FNC(VIDIOC_G_EXT_CTRLS, v4l_g_ext_ctrls, v4l_print_ext_controls, INFO_FL_CTRL), IOCTL_INFO_FNC(VIDIOC_S_EXT_CTRLS, v4l_s_ext_ctrls, v4l_print_ext_controls, INFO_FL_PRIO | INFO_FL_CTRL), - IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls, v4l_print_ext_controls, 0), + IOCTL_INFO_FNC(VIDIOC_TRY_EXT_CTRLS, v4l_try_ext_ctrls, v4l_print_ext_controls, INFO_FL_CTRL), IOCTL_INFO_STD(VIDIOC_ENUM_FRAMESIZES, vidioc_enum_framesizes, v4l_print_frmsizeenum, INFO_FL_CLEAR(v4l2_frmsizeenum, pixel_format)), IOCTL_INFO_STD(VIDIOC_ENUM_FRAMEINTERVALS, vidioc_enum_frameintervals, v4l_print_frmivalenum, INFO_FL_CLEAR(v4l2_frmivalenum, height)), IOCTL_INFO_STD(VIDIOC_G_ENC_INDEX, vidioc_g_enc_index, v4l_print_enc_idx, 0), -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] Initial version of RDS Control utility Signed-off-by: Konke Radlow krad...@cisco.com
On Sat July 28 2012 13:11:13 Hans de Goede wrote: Hi, Overall this looks good, but some of the code, for example the set/get freq and get/set tuner stuff seems to be a 1 on 1 copy of code from v4l2-ctrl, please factor this out into a common file which can be shared between both utilities (I think Hans V's recent work on splitting v4l2-ctl into multiple files comes a long way towards this). I'm not sure how valuable this is. If we do this, then that means a fair amount of work in v4l2-ctl (although the split was a major step forward in that direction). There are a bunch of utilities that all share some common code in that respect. But they are all stand-alone and I would have to think carefully how to organize the code if you want to make it easy to share code. Bottom-line: let's keep this as a separate project and not mix it with rds-ctl. Regards, Hans Regards, Hans On 07/25/2012 07:44 PM, Konke Radlow wrote: --- Makefile.am |3 +- configure.ac |1 + utils/rds-ctl/Makefile.am |5 + utils/rds-ctl/rds-ctl.cpp | 978 + 4 files changed, 986 insertions(+), 1 deletion(-) create mode 100644 utils/rds-ctl/Makefile.am create mode 100644 utils/rds-ctl/rds-ctl.cpp diff --git a/Makefile.am b/Makefile.am index 6707f5f..47103a1 100644 --- a/Makefile.am +++ b/Makefile.am @@ -18,7 +18,8 @@ SUBDIRS += \ utils/v4l2-compliance \ utils/v4l2-ctl \ utils/v4l2-dbg \ - utils/v4l2-sysfs-path + utils/v4l2-sysfs-path \ + utils/rds-ctl if LINUX_OS SUBDIRS += \ diff --git a/configure.ac b/configure.ac index 1d7eb29..1ad99e6 100644 --- a/configure.ac +++ b/configure.ac @@ -28,6 +28,7 @@ AC_CONFIG_FILES([Makefile utils/v4l2-sysfs-path/Makefile utils/xc3028-firmware/Makefile utils/qv4l2/Makefile + utils/rds-ctl/Makefile contrib/freebsd/Makefile contrib/test/Makefile diff --git a/utils/rds-ctl/Makefile.am b/utils/rds-ctl/Makefile.am new file mode 100644 index 000..9a84257 --- /dev/null +++ b/utils/rds-ctl/Makefile.am @@ -0,0 +1,5 @@ +bin_PROGRAMS = rds-ctl + +rds_ctl_SOURCES = rds-ctl.cpp +rds_ctl_LDADD = ../../lib/libv4l2/libv4l2.la ../../lib/libv4l2rds/libv4l2rds.la + diff --git a/utils/rds-ctl/rds-ctl.cpp b/utils/rds-ctl/rds-ctl.cpp new file mode 100644 index 000..8ddb969 --- /dev/null +++ b/utils/rds-ctl/rds-ctl.cpp @@ -0,0 +1,978 @@ +/* + * rds-ctl.cpp is based on v4l2-ctl.cpp + * + * the following applies for all RDS related parts: + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * Author: Konke Radlow korad...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA + */ + +#include unistd.h +#include stdlib.h +#include stdio.h +#include string.h +#include wchar.h +#include locale.h +#include inttypes.h +#include getopt.h +#include sys/types.h +#include fcntl.h +#include errno.h +#include sys/ioctl.h +#include sys/time.h +#include dirent.h +#include config.h +#include signal.h + +#ifdef HAVE_SYS_KLOG_H +#include sys/klog.h +#endif + +#include linux/videodev2.h +#include libv4l2.h +#include libv4l2rds.h + +#include list +#include vector +#include map +#include string +#include algorithm + +#define ARRAY_SIZE(arr) ((int)(sizeof(arr) / sizeof((arr)[0]))) + +typedef std::vectorstd::string dev_vec; +typedef std::mapstd::string, std::string dev_map; + +/* Short option list + + Please keep in alphabetical order. + That makes it easier to see which short options are still free. + + In general the lower case is used to set something and the upper + case is used to retrieve a setting. */ +enum Option { + OptSetDevice = 'd', + OptGetDriverInfo = 'D', + OptGetFreq = 'F', + OptSetFreq = 'f', + OptHelp = 'h', + OptReadRds = 'R', + OptGetTuner = 'T', + OptSetTuner = 't', + OptUseWrapper = 'w', + OptAll = 128, + OptFreqSeek, + OptListDevices, + OptOpenFile, + OptPrintBlock, + OptSilent, + OptTunerIndex, + OptVerbose, +
Re: rtl28xxu - rtl2832 frontend attach
On 06/27/2012 07:21 AM, Thomas Mair wrote: On 26.06.2012 19:17, poma wrote: On 05/28/2012 04:48 PM, Thomas Mair wrote: On 28.05.2012 08:58, Thomas Mair wrote: On 26.05.2012 04:47, poma wrote: On 05/20/2012 11:12 PM, Thomas Mair wrote: On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes even more. Precisely, what breaks a tuner on next soft [re]boot are apps/utils which engage tzap/scan[dvb]. To reproduce the bug it is not necessary to reboot the machine. Simply unload and load of the dvb_usb_rtl28xxu module will lead to the same situation. I suspect, that when power is turned off, the tuner power is not switched on correctly. The mistake is not related to the OUTPUT_VAL registers but probably to the OUTPUT_DIR or OUTPUT_EN registers. What makes me wonder is if no tuning operation is performed before reboot, the driver does work correctly after that, as poma already noticed. I have some spare time today and will investigate the problem further. I tried a few things regarding the problem today and could find out a few more details, but could not resolve the issue. The GPIO pin configuration for the devices with the fc0012 (and probably also with the fc0013) tuner is the following: GPIO0: demod power GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it again) GPIO4: tuner power? (maybe antenna power?) GPIO5: tuner reset GPIO6: UHF/VHF band selection All of these GPIOs are configured as output. When the device is plugged in the tuner is powered up correctly, but I am not able to power it up when a reboot is performed. What I tried was the following: - on rtl28xxu_power_ctrl off: - GPIO4 = 1 (off) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl28xxu_power_ctrl on: - GPIO3 = 1 - GPIO4 = 0 (on) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl2832_frontend_attach: - GPIO5 = 1 - GPIO5 = 0 This sequence should ensure that the tuner is powered on when the frontend is attached, and a tuner reset is being performed before the tuner is probed. However this sequence fails the same way as it did before. I tried to add timeouts to be sure that the tuner is not probed while it is reset but that did not help either. Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Is there anybody who could look at the code, or maybe knows what could be the cause of the problem? I suspect I am just too blind to see my own mistakes. Regards Thomas Cheers Thomas, Hans-Frieder, Antti, Mauro! Hans-Frieder, are you having the same issue with fc0011af9035? Antti, no tricks up your sleeve? Senhor Mauro, is rtl2832 demod going to be merged? regards, poma Hi all, I will try to solve the issue as soon as I have some spare time. In the meantime I asked Realtek if they knew of any problems with the hardware, and I got a GPIO list which might help me to solve the problem. Regrads Thomas This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs https://gist.github.com/2171926#120 David, can you help with this tuner issue? http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898 Cheers, poma -- 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: GPIO interface between DVB sub-drivers (bridge, demod, tuner)
On 07/30/2012 12:21 AM, poma wrote: On 07/20/2012 03:43 AM, Antti Palosaari wrote: On 07/13/2012 12:07 AM, Steven Toth wrote: On Thu, Jul 12, 2012 at 4:49 PM, Steven Toth st...@kernellabs.com wrote: Nobody understands the relationship between the bridge and the sub-component as well as the bridge driver. The current interfaces are limiting in many ways. We solve that today with rather ugly 'attach' structures that are inflexible, for example to set gpios to a default state. Then, once that interface is attached, the bridge effectively loses most of the control to the tuner and/or demod. The result is a large disconnect between the bridge and subcomponents. Why limit any interface extension to GPIOs? Why not make something a little more flexible so we can pass custom messages around? What did you ever decide about the enable/disable of the LNA? And, how would the bridge do that in your proposed solution? Via the proposed GPIO interface? GPIO / LNA is ready, see following patches: add LNA support for DVB API cxd2820r: use Kernel GPIO for GPIO access em28xx: implement FE set_lna() callback from: http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/dvb_core Kernel GPIOs were quite easy to implement and use - when needed knowledge was gathered after all the testing and study. I wonder why none was done that earlier for DVB... It also offer nice debug/devel feature as you can mount those GPIOs via sysfs and use directly. Above mentioned GPIO functionality must be implemented in driver itself to use /sys/class/gpio/… sysfs interface, right? It is not enough to build kernel with CONFIG_GENERIC_GPIO=y, CONFIG_GPIOLIB=y, CONFIG_GPIO_SYSFS, right? You will need to implement callbacks for gpiolib. sysfs interface is then get for free. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v2 3/4] media: videobuf2-dma-contig: use dma_mmap_coherent if available
Hello, On Thursday, July 26, 2012 1:13 PM Hideki EIRAKU wrote: Previously the vb2_dma_contig_mmap() function was using a dma_addr_t as a physical address. The two addressses are not necessarily the same. For example, when using the IOMMU funtion on certain platforms, dma_addr_t addresses are not directly mappable physical address. dma_mmap_coherent() maps the address correctly. It is available on ARM platforms. Signed-off-by: Hideki EIRAKU h...@igel.co.jp --- drivers/media/video/videobuf2-dma-contig.c | 18 ++ 1 files changed, 18 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/videobuf2-dma-contig.c b/drivers/media/video/videobuf2-dma- contig.c index 4b71326..4dc85ab 100644 --- a/drivers/media/video/videobuf2-dma-contig.c +++ b/drivers/media/video/videobuf2-dma-contig.c @@ -101,14 +101,32 @@ static unsigned int vb2_dma_contig_num_users(void *buf_priv) static int vb2_dma_contig_mmap(void *buf_priv, struct vm_area_struct *vma) { struct vb2_dc_buf *buf = buf_priv; +#ifdef ARCH_HAS_DMA_MMAP_COHERENT + int ret; +#endif if (!buf) { printk(KERN_ERR No buffer to map\n); return -EINVAL; } +#ifdef ARCH_HAS_DMA_MMAP_COHERENT + vma-vm_page_prot = pgprot_noncached(vma-vm_page_prot); The above line is not needed. It is up to dma_mmap_coherent() / dma_mmap_attrs() to set page protection bits which match requested type of dma buffer mapping. + ret = dma_mmap_coherent(buf-conf-dev, vma, buf-vaddr, buf-dma_addr, + buf-size); + if (ret) { + pr_err(Remapping memory failed, error: %d\n, ret); + return ret; + } + vma-vm_flags |= VM_DONTEXPAND | VM_RESERVED; + vma-vm_private_data = buf-handler; + vma-vm_ops = vb2_common_vm_ops; + vma-vm_ops-open(vma); + return 0; +#else return vb2_mmap_pfn_range(vma, buf-dma_addr, buf-size, vb2_common_vm_ops, buf-handler); +#endif } static void *vb2_dma_contig_get_userptr(void *alloc_ctx, unsigned long vaddr, Best regards -- Marek Szyprowski Samsung Poland RD Center -- 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] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks.
This driver wasn't converted to the new clock framework (e038ed50a4a767add205094c035b6943e7b30140). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- This is broken in current stable 3.5 too. So it should be applied to both stable and 3.6. --- drivers/media/video/mx2_emmaprp.c | 27 --- 1 file changed, 16 insertions(+), 11 deletions(-) diff --git a/drivers/media/video/mx2_emmaprp.c b/drivers/media/video/mx2_emmaprp.c index 0bd5815..2614a89 100644 --- a/drivers/media/video/mx2_emmaprp.c +++ b/drivers/media/video/mx2_emmaprp.c @@ -209,7 +209,7 @@ struct emmaprp_dev { int irq_emma; void __iomem*base_emma; - struct clk *clk_emma; + struct clk *clk_emma_ahb, *clk_emma_ipg; struct resource *res_emma; struct v4l2_m2m_dev *m2m_dev; @@ -800,7 +800,8 @@ static int emmaprp_open(struct file *file) return ret; } - clk_enable(pcdev-clk_emma); + clk_prepare_enable(pcdev-clk_emma_ipg); + clk_prepare_enable(pcdev-clk_emma_ahb); ctx-q_data[V4L2_M2M_SRC].fmt = formats[1]; ctx-q_data[V4L2_M2M_DST].fmt = formats[0]; @@ -816,7 +817,8 @@ static int emmaprp_release(struct file *file) dprintk(pcdev, Releasing instance %p\n, ctx); - clk_disable(pcdev-clk_emma); + clk_disable_unprepare(pcdev-clk_emma_ahb); + clk_disable_unprepare(pcdev-clk_emma_ipg); v4l2_m2m_ctx_release(ctx-m2m_ctx); kfree(ctx); @@ -876,9 +878,15 @@ static int emmaprp_probe(struct platform_device *pdev) spin_lock_init(pcdev-irqlock); - pcdev-clk_emma = clk_get(pdev-dev, NULL); - if (IS_ERR(pcdev-clk_emma)) { - ret = PTR_ERR(pcdev-clk_emma); + pcdev-clk_emma_ipg = devm_clk_get(pdev-dev, ipg); + if (IS_ERR(pcdev-clk_emma_ipg)) { + ret = PTR_ERR(pcdev-clk_emma_ipg); + goto free_dev; + } + + pcdev-clk_emma_ahb = devm_clk_get(pdev-dev, ahb); + if (IS_ERR(pcdev-clk_emma_ipg)) { + ret = PTR_ERR(pcdev-clk_emma_ahb); goto free_dev; } @@ -887,12 +895,12 @@ static int emmaprp_probe(struct platform_device *pdev) if (irq_emma 0 || res_emma == NULL) { dev_err(pdev-dev, Missing platform resources data\n); ret = -ENODEV; - goto free_clk; + goto free_dev; } ret = v4l2_device_register(pdev-dev, pcdev-v4l2_dev); if (ret) - goto free_clk; + goto free_dev; mutex_init(pcdev-dev_mutex); @@ -965,8 +973,6 @@ rel_vdev: video_device_release(vfd); unreg_dev: v4l2_device_unregister(pcdev-v4l2_dev); -free_clk: - clk_put(pcdev-clk_emma); free_dev: kfree(pcdev); @@ -983,7 +989,6 @@ static int emmaprp_remove(struct platform_device *pdev) v4l2_m2m_release(pcdev-m2m_dev); vb2_dma_contig_cleanup_ctx(pcdev-alloc_ctx); v4l2_device_unregister(pcdev-v4l2_dev); - clk_put(pcdev-clk_emma); kfree(pcdev); return 0; -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks.
Hi, On 07/30/2012 10:37 AM, Javier Martin wrote: This driver wasn't converted to the new clock framework (e038ed50a4a767add205094c035b6943e7b30140). Signed-off-by: Javier Martin javier.mar...@vista-silicon.com --- This is broken in current stable 3.5 too. So it should be applied to both stable and 3.6. The you should add Cc: sta...@vger.kernel.org line along with your sign-off, ideally mentioning in the patch description to what stable kernels it applies, and it would all be handled automatically. I guess Mauro is going to add that missing Cc, when applying the patch though. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] v4l: Add missing compatibility definitions for bounds rectangles
Compatibility defines for ACTUAL subdev selection rectangles were added and also the name of the BOUNDS rectangles was changed in the process, which, alas, went unnoticed until now. Add compatibility definitions for these rectangles. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- include/linux/v4l2-common.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/v4l2-common.h b/include/linux/v4l2-common.h index 0fa8b64..4f0667e 100644 --- a/include/linux/v4l2-common.h +++ b/include/linux/v4l2-common.h @@ -53,10 +53,10 @@ /* Backward compatibility target definitions --- to be removed. */ #define V4L2_SEL_TGT_CROP_ACTIVE V4L2_SEL_TGT_CROP #define V4L2_SEL_TGT_COMPOSE_ACTIVEV4L2_SEL_TGT_COMPOSE -#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL \ - V4L2_SEL_TGT_CROP -#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL \ - V4L2_SEL_TGT_COMPOSE +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUALV4L2_SEL_TGT_CROP +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL V4L2_SEL_TGT_COMPOSE +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDSV4L2_SEL_TGT_CROP_BOUNDS +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS V4L2_SEL_TGT_COMPOSE_BOUNDS /* Selection flags */ #define V4L2_SEL_FLAG_GE (1 0) -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] v4l: Add missing compatibility definitions for bounds rectangles
Hi Sakari, Thanks for the patch. On Monday 30 July 2012 12:08:47 Sakari Ailus wrote: Compatibility defines for ACTUAL subdev selection rectangles were added and also the name of the BOUNDS rectangles was changed in the process, which, alas, went unnoticed until now. Add compatibility definitions for these rectangles. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com --- include/linux/v4l2-common.h |8 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/include/linux/v4l2-common.h b/include/linux/v4l2-common.h index 0fa8b64..4f0667e 100644 --- a/include/linux/v4l2-common.h +++ b/include/linux/v4l2-common.h @@ -53,10 +53,10 @@ /* Backward compatibility target definitions --- to be removed. */ #define V4L2_SEL_TGT_CROP_ACTIVE V4L2_SEL_TGT_CROP #define V4L2_SEL_TGT_COMPOSE_ACTIVE V4L2_SEL_TGT_COMPOSE -#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL \ - V4L2_SEL_TGT_CROP -#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL \ - V4L2_SEL_TGT_COMPOSE +#define V4L2_SUBDEV_SEL_TGT_CROP_ACTUAL V4L2_SEL_TGT_CROP +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_ACTUAL V4L2_SEL_TGT_COMPOSE +#define V4L2_SUBDEV_SEL_TGT_CROP_BOUNDS V4L2_SEL_TGT_CROP_BOUNDS +#define V4L2_SUBDEV_SEL_TGT_COMPOSE_BOUNDS V4L2_SEL_TGT_COMPOSE_BOUNDS /* Selection flags */ #define V4L2_SEL_FLAG_GE (1 0) -- 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
[GIT PULL FOR 3.6] Selection API compatibility fix, small SMIA++ correction
Hi Mauro, This pull request contains an important for for the compatibility definitions of the bounds rectangles. They were missing from the original patches changing the selection rectangles. There's an one-liner to fix double include in the SMIA++ driver, too. Please pull: The following changes since commit 931efdf58bd83af8d0578a6cc53421675daf6d41: Merge branch 'v4l_for_linus' into staging/for_v3.6 (2012-07-14 15:45:44 -0300) are available in the git repository at: ssh://linuxtv.org/git/sailus/media_tree.git media-for-3.6 Duan Jiong (1): smiapp: remove duplicated include Sakari Ailus (1): v4l: Add missing compatibility definitions for bounds rectangles drivers/media/video/smiapp/smiapp-core.c |1 - include/linux/v4l2-common.h |8 2 files changed, 4 insertions(+), 5 deletions(-) Kind regards, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- 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/2] Add support for RDS decoding
thank you for the info, it's working now (I went for the include solution) -- 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: rtl28xxu - rtl2832 frontend attach
On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote: On 06/27/2012 07:21 AM, Thomas Mair wrote: On 26.06.2012 19:17, poma wrote: On 05/28/2012 04:48 PM, Thomas Mair wrote: On 28.05.2012 08:58, Thomas Mair wrote: On 26.05.2012 04:47, poma wrote: On 05/20/2012 11:12 PM, Thomas Mair wrote: On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes even more. Precisely, what breaks a tuner on next soft [re]boot are apps/utils which engage tzap/scan[dvb]. To reproduce the bug it is not necessary to reboot the machine. Simply unload and load of the dvb_usb_rtl28xxu module will lead to the same situation. I suspect, that when power is turned off, the tuner power is not switched on correctly. The mistake is not related to the OUTPUT_VAL registers but probably to the OUTPUT_DIR or OUTPUT_EN registers. What makes me wonder is if no tuning operation is performed before reboot, the driver does work correctly after that, as poma already noticed. I have some spare time today and will investigate the problem further. I tried a few things regarding the problem today and could find out a few more details, but could not resolve the issue. The GPIO pin configuration for the devices with the fc0012 (and probably also with the fc0013) tuner is the following: GPIO0: demod power GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it again) GPIO4: tuner power? (maybe antenna power?) GPIO5: tuner reset GPIO6: UHF/VHF band selection All of these GPIOs are configured as output. When the device is plugged in the tuner is powered up correctly, but I am not able to power it up when a reboot is performed. What I tried was the following: - on rtl28xxu_power_ctrl off: - GPIO4 = 1 (off) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl28xxu_power_ctrl on: - GPIO3 = 1 - GPIO4 = 0 (on) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl2832_frontend_attach: - GPIO5 = 1 - GPIO5 = 0 This sequence should ensure that the tuner is powered on when the frontend is attached, and a tuner reset is being performed before the tuner is probed. However this sequence fails the same way as it did before. I tried to add timeouts to be sure that the tuner is not probed while it is reset but that did not help either. Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Is there anybody who could look at the code, or maybe knows what could be the cause of the problem? I suspect I am just too blind to see my own mistakes. Regards Thomas Cheers Thomas, Hans-Frieder, Antti, Mauro! Hans-Frieder, are you having the same issue with fc0011af9035? Antti, no tricks up your sleeve? Senhor Mauro, is rtl2832 demod going to be merged? regards, poma Hi all, I will try to solve the issue as soon as I have some spare time. In the meantime I asked Realtek if they knew of any problems with the hardware, and I got a GPIO list which might help me to solve the problem. Regrads Thomas This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs https://gist.github.com/2171926#120 David, can you help with this tuner issue? http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898 Cheers, poma It sounds like you're definately on the right track with the GPIO pins for tuner power and reset lines, especially if it's not making it through the tuner probe. The gist you linked to above has since been merged into the rtl-sdr tree, and the version in there is likely to be a much better reference than the old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr It reliably brings the rtl and the tuner
Asus PVR-416
I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on Scientific Linux 6. I have a bttv card working, my setup works in general, etc, and the driver attempts to load. But when I check dmesg, I keep getting firmware load errors and checksum errors. I've tried every firmware I could find. I've used the one from Atrpms, I've downloaded the correctly named firmware from ivtv, but no luck. Anyone know anything about this card? I've tried cutting the drivers myself like it says in the direcitons at mythtv.org. This is supposed to be a supported card, does anyone have any experience with it? -- 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 for stable] cx25821: Remove bad strcpy to read-only char*
Hi Ben, On Sun, Jul 29, 2012 at 10:56 PM, Ben Hutchings b...@decadent.org.uk wrote: If I'm doing anything wrong, just yell at me. [...] An upstream commit hash would have helped, but I found it anyway. Queued up for 3.2.y. Thanks for the hint and sorry for the trouble... Ezequiel. -- 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 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
Hello Hans, no need to thank me for working on it. First of all I do it as a part of a summerjob, and more importantly I quite enjoy it and intend to stay a active member of the development process after my time at Cisco is over. Thank you for your comments. Most fields in this struct (and in the other structs for that matter) could do with some more documentation. I added a lot of short comments explaining the meaning of the fields, and extended the explanation part that comes before each struct definition. + /** RDS info fields **/ + bool is_rbds; /* use RBDS standard version of LUTs */ + uint16_t pi; + uint8_t ps[8]; Looking at rds-ctl, this contains a string, please make it 9 bytes and always 0 terminate it! I also notice in rds-ctl that you filter the chars for being valid ascii and if not replace them with a space. Does the spec say anything about the encoding used for this string? Could we maybe convert it to UTF-8 inside the library so that apps can just consume the string? The character encoding complies with ISO/IEC 10646, so it basically already is UTF-8, and the data could be stored in a wchar_t array without conversion. Is that preferred over uint8_t? +/* adds a raw RDS block to decode it into RDS groups + * @return:bitmask with with updated fields set to 1 + * @rds_data: 3 bytes of raw RDS data, obtained by calling read() + * on RDS capable V4L2 devices */ +LIBV4L_PUBLIC uint32_t v4l2_rds_add(struct v4l2_rds *handle, struct v4l2_rds_data *rds_data); Unless I'm missing something, you are no defining struct v4l2_rds_data anywhere, why not just make this a uint8_t ? The v4l2_rds_data structure is defined by v4l in the videodev2.h header, and is returned when calling the read function on a rds capable device On Saturday, July 28, 2012 11:08:24 AM Hans de Goede wrote: Hi, First of all many thanks for working on this! Note I've also taken a quick look at the original patch with the actual implementation and that looks good. I'm replying here because in my mind the API is the most interesting thing to discuss. Comments inline. On 07/26/2012 06:21 PM, Konke Radlow wrote: PATCH 1/2 was missing the public header for the rds library. I'm sorry for that mistake: diff --git a/lib/include/libv4l2rds.h b/lib/include/libv4l2rds.h new file mode 100644 index 000..04843d3 --- /dev/null +++ b/lib/include/libv4l2rds.h @@ -0,0 +1,203 @@ +/* + * Copyright 2012 Cisco Systems, Inc. and/or its affiliates. All rights reserved. + * Author: Konke Radlow korad...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU Lesser General Public License as published by + * the Free Software Foundation; either version 2.1 of the License, or + * (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 51 Franklin Street, Suite 500, Boston, MA 02110-1335 USA + */ + +#ifndef __LIBV4L2RDS +#define __LIBV4L2RDS + +#include errno.h +#include stdio.h +#include stdlib.h +#include string.h +#include stdbool.h +#include unistd.h +#include stdint.h +#include sys/types.h +#include sys/mman.h + +#include linux/videodev2.h + +#ifdef __cplusplus +extern C { +#endif /* __cplusplus */ + +#if __GNUC__ = 4 +#define LIBV4L_PUBLIC __attribute__ ((visibility(default))) +#else +#define LIBV4L_PUBLIC +#endif + +/* used to define the current version (version field) of the v4l2_rds struct */ +#define V4L2_RDS_VERSION (1) + +/* Constants used to define the size of arrays used to store RDS information */ +#define MAX_ODA_CNT 18 /* there are 16 groups each with type a or b. Of these + * 32 distinct groups, 18 can be used for ODA purposes*/ +#define MAX_AF_CNT 25 /* AF Method A allows a maximum of 25 AFs to be defined +* AF Method B does not impose a limit on the number of AFs +* but it is not fully supported at the moment and will +* not receive more than 25 AFs */ + +/* Define Constants for the possible types of RDS information + * used to address the relevant bit in the valid_bitmask */ +#define V4L2_RDS_PI0x01/* Program Identification */ +#define V4L2_RDS_PTY 0x02/* Program Type */ +#define V4L2_RDS_TP0x04/* Traffic Program */ +#define V4L2_RDS_PS0x08/* Program
Re: [PATCH] cx25840: Declare MODULE_FIRMWARE usage
On 07/28/2012 10:52 AM, Andy Walls wrote: On Fri, 2012-07-27 at 06:06 -0600, Tim Gardner wrote: On 07/26/2012 03:59 PM, Andy Walls wrote: On Thu, 2012-07-26 at 10:44 -0600, Tim Gardner wrote: Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/video/cx25840/cx25840-firmware.c | 15 --- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/cx25840/cx25840-firmware.c b/drivers/media/video/cx25840/cx25840-firmware.c index 8150200..b3169f9 100644 --- a/drivers/media/video/cx25840/cx25840-firmware.c +++ b/drivers/media/video/cx25840/cx25840-firmware.c @@ -61,6 +61,10 @@ static void end_fw_load(struct i2c_client *client) cx25840_write(client, 0x803, 0x03); } +#define CX2388x_FIRMWARE v4l-cx23885-avcore-01.fw +#define CX231xx_FIRMWARE v4l-cx231xx-avcore-01.fw +#define CX25840_FIRMWARE v4l-cx25840.fw + static const char *get_fw_name(struct i2c_client *client) { struct cx25840_state *state = to_state(i2c_get_clientdata(client)); @@ -68,10 +72,10 @@ static const char *get_fw_name(struct i2c_client *client) if (firmware[0]) return firmware; if (is_cx2388x(state)) - return v4l-cx23885-avcore-01.fw; + return CX2388x_FIRMWARE; if (is_cx231xx(state)) - return v4l-cx231xx-avcore-01.fw; - return v4l-cx25840.fw; + return CX231xx_FIRMWARE; + return CX25840_FIRMWARE; } static int check_fw_load(struct i2c_client *client, int size) @@ -164,3 +168,8 @@ int cx25840_loadfw(struct i2c_client *client) return check_fw_load(client, size); } + +MODULE_FIRMWARE(CX2388x_FIRMWARE); +MODULE_FIRMWARE(CX231xx_FIRMWARE); +MODULE_FIRMWARE(CX25840_FIRMWARE); + How will the firmware attribute in the .module_info section be used? For any one model of TV capture device, the cx25840 only needs one of the above firmware files. The others need not exist. I would not want anything in user or kernel space to refuse to load the module just because all 3 firmware files are not present. Regards, Andy The MODULE_FIRMWARE macro is purely informational. Declaring the firmware files that the driver _might_ use helps me pare down the external firmware package to just those files that I know it must have. Would it help if the MODULE_FIRMWARE text was more descriptive, e.g.: MODULE_FIRMWARE(CX25840_FIRMWARE CX25840/1/2/3 chips only); MODULE_FIRMWARE(CX231xx_FIRMWARE CX23100/1/2 chips only); MODULE_FIRMWARE(CX2388x_FIRMWARE CX23885/7/8 chips only); Similarly for ivtv: MODULE_FIRMWARE(CX2341X_FIRM_ENC_FILENAME); MODULE_FIRMWARE(CX2341X_FIRM_DEC_FILENAME PVR-350 only); MODULE_FIRMWARE(IVTV_DECODE_INIT_MPEG_FILENAME PVR-350 only); and cx18: MODULE_FIRMWARE(FWFILE); /* v4l-cx23418-dig.fw */ MODULE_FIRMWARE(CX18_CPU_FIRMWARE); MODULE_FIRMWARE(CX18_APU_FIRMWARE); MODULE_FIRMWARE(XC2028_DEFAULT_FIRMWARE Non-HVR-1600 cards); MODULE_FIRMWARE(FWFILE Yuan MPC-718 only); or would that confuse some userspace tools? Yeah, I think it would confuse any tools that assume the firmware string emitted by modinfo is a literal filename. rtg -- Tim Gardner tim.gard...@canonical.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: [PATCH] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
Hi, thank you for yor ACKs. On 20 July 2012 13:31, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 12 Jul 2012, Javier Martin wrote: These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin javier.mar...@vista-silicon.com For the ARM tree: Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de forgive my ignorance on the matter. Could you please point me to the git repository this patch should be merged? Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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: rtl28xxu - rtl2832 frontend attach
Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it doesn't, GPIO5 on the RTL isn't setup correctly somehow. At the same time, I was rereading code from: http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898 and at no point is GPIO5 actually set to an output or enabled that I can find. rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running into this problem while trying to use some DVB driver code as an example of how to setup the RTL to talk to the FC0012) Try giving the patch below a go. Sorry, I don't have a build environment to hand, so there might be a typo I haven't picked up, but the upshot is that I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the tuner and then trying to probe for the FC0012. Please let me know if this helps :) David --- a/rtl28xxu.c2012-07-30 22:31:53.789638678 +1000 +++ b/rtl28xxu.c2012-07-30 22:48:35.774607232 +1000 @@ -550,15 +550,6 @@ priv-tuner = TUNER_NONE; - /* check FC0012 ID register; reg=00 val=a1 */ - ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012); - if (ret == 0 buf[0] == 0xa1) { - priv-tuner = TUNER_RTL2832_FC0012; - rtl2832_config = rtl28xxu_rtl2832_fc0012_config; - info(%s: FC0012 tuner found, __func__); - goto found; - } - /* check FC0013 ID register; reg=00 val=a3 */ ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013); if (ret == 0 buf[0] == 0xa3) { @@ -640,6 +631,71 @@ goto unsupported; } + /* If it's a FC0012, we need to bring GPIO5/RESET + out of floating or it's not going to show up. + We set GPIO5 to an output, enable the output, then + reset the tuner by bringing GPIO5 high then low again. + + We're testing this last so that we don't accidentally + mess with other hardware that wouldn't like us messing + with whatever is connected to the rtl2832's GPIO5 + */ + + /* close demod I2C gate */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close); + if (ret) + goto err; + + /* Set GPIO5 to be an output */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val); + if (ret) + goto err; + + val = 0xdf; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val); + if (ret) + goto err; + + /* enable as output GPIO5 */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val); + if (ret) + goto err; + + val |= 0x20; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val); + if (ret) + goto err; + + /* set GPIO5 high to reset fc0012 (if it exists) */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + val |= 0x20; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + /* bring GPIO5 low again after reset */ + val = 0xdf; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + /* re-open demod I2C gate */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open); + if (ret) + goto err; + + /* check FC0012 ID register; reg=00 val=a1 */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012); + if (ret == 0 buf[0] == 0xa1) { + priv-tuner = TUNER_RTL2832_FC0012; + rtl2832_config = rtl28xxu_rtl2832_fc0012_config; + info(%s: FC0012 tuner found, __func__); + goto found; + } + unsupported: /* close demod I2C gate */ ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close); -- 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 1/2] Initial version of the RDS-decoder library Signed-off-by: Konke Radlow krad...@cisco.com
Hello Hans, no need to thank me for working on it. First of all I do it as a part of a summerjob, and more importantly I quite enjoy it and intend to stay a active member of the development process after my time at Cisco is over. Thank you for your comments. Most fields in this struct (and in the other structs for that matter) could do with some more documentation. I added a lot of short comments explaining the meaning of the fields, and extended the explanation part that comes before each struct definition. + /** RDS info fields **/ + bool is_rbds; /* use RBDS standard version of LUTs */ + uint16_t pi; + uint8_t ps[8]; Looking at rds-ctl, this contains a string, please make it 9 bytes and always 0 terminate it! I also notice in rds-ctl that you filter the chars for being valid ascii and if not replace them with a space. Does the spec say anything about the encoding used for this string? Could we maybe convert it to UTF-8 inside the library so that apps can just consume the string? The character encoding complies with ISO/IEC 10646, so it basically already is UTF-8, and the data could be stored in a wchar_t array without conversion. Is that preferred over uint8_t? +/* adds a raw RDS block to decode it into RDS groups + * @return:bitmask with with updated fields set to 1 + * @rds_data: 3 bytes of raw RDS data, obtained by calling read() + * on RDS capable V4L2 devices */ +LIBV4L_PUBLIC uint32_t v4l2_rds_add(struct v4l2_rds *handle, struct v4l2_rds_data *rds_data); Unless I'm missing something, you are no defining struct v4l2_rds_data anywhere, why not just make this a uint8_t ? The v4l2_rds_data structure is defined by v4l in the videodev2.h header, and is returned when calling the read function on a rds capable device source: http://hverkuil.home.xs4all.nl/spec/media.html#v4l2-rds-data Maybe I didn't get you point though? greetings, Konke -- 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: Asus PVR-416
On Mon, Jul 30, 2012 at 6:57 AM, Jerry Haggard xen2x...@gmail.com wrote: I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on Scientific Linux 6. I have a bttv card working, my setup works in general, etc, and the driver attempts to load. But when I check dmesg, I keep getting firmware load errors and checksum errors. I've tried every firmware I could find. I've used the one from Atrpms, I've downloaded the correctly named firmware from ivtv, but no luck. Anyone know anything about this card? I've tried cutting the drivers myself like it says in the direcitons at mythtv.org. This is supposed to be a supported card, does anyone have any experience with it? I've got one and it worked years ago, but I haven't used it since. IIRC, the initial blackbird support was added using this card, but I'm not sure what the current state is. Alex -- 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] mt9v022: Add support for mt9v024
This patch has been successfully tested Signed-off-by: Alex Gershgorin al...@meprolight.com --- drivers/media/video/Kconfig |2 +- drivers/media/video/mt9v022.c | 28 ++-- 2 files changed, 19 insertions(+), 11 deletions(-) diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 99937c9..38d6944 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -1013,7 +1013,7 @@ config SOC_CAMERA_MT9T112 This driver supports MT9T112 cameras from Aptina. config SOC_CAMERA_MT9V022 - tristate mt9v022 support + tristate mt9v022 and mt9v024 support depends on SOC_CAMERA I2C select GPIO_PCA953X if MT9V022_PCA9536_SWITCH help diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c index bf63417..d2c1ab1 100644 --- a/drivers/media/video/mt9v022.c +++ b/drivers/media/video/mt9v022.c @@ -26,7 +26,7 @@ * The platform has to define ctruct i2c_board_info objects and link to them * from struct soc_camera_link */ - +static s32 chip_id; static char *sensor_type; module_param(sensor_type, charp, S_IRUGO); MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or \monochrome\); @@ -57,6 +57,10 @@ MODULE_PARM_DESC(sensor_type, Sensor type: \colour\ or \monochrome\); #define MT9V022_AEC_AGC_ENABLE 0xAF #define MT9V022_MAX_TOTAL_SHUTTER_WIDTH0xBD +/* mt9v024 partial list register addresses changes with respect to mt9v022 */ +#define MT9V024_PIXCLK_FV_LV 0x72 +#define MT9V024_MAX_TOTAL_SHUTTER_WIDTH0xAD + /* Progressive scan, master, defaults */ #define MT9V022_CHIP_CONTROL_DEFAULT 0x188 @@ -185,7 +189,9 @@ static int mt9v022_init(struct i2c_client *client) if (!ret) ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, 480); if (!ret) - ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480); + ret = reg_write(client, (chip_id == 0x1324) ? + MT9V024_MAX_TOTAL_SHUTTER_WIDTH : + MT9V022_MAX_TOTAL_SHUTTER_WIDTH, 480); if (!ret) /* default - auto */ ret = reg_clear(client, MT9V022_BLACK_LEVEL_CALIB_CTRL, 1); @@ -238,8 +244,10 @@ static int mt9v022_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a) ret = reg_read(client, MT9V022_AEC_AGC_ENABLE); if (ret = 0) { if (ret 1) /* Autoexposure */ - ret = reg_write(client, MT9V022_MAX_TOTAL_SHUTTER_WIDTH, - rect.height + mt9v022-y_skip_top + 43); + ret = reg_write(client, (chip_id == 0x1324) ? + MT9V024_MAX_TOTAL_SHUTTER_WIDTH : + MT9V022_MAX_TOTAL_SHUTTER_WIDTH, + rect.height + mt9v022-y_skip_top + 43); else ret = reg_write(client, MT9V022_TOTAL_SHUTTER_WIDTH, rect.height + mt9v022-y_skip_top + 43); @@ -566,18 +574,17 @@ static int mt9v022_video_probe(struct i2c_client *client) { struct mt9v022 *mt9v022 = to_mt9v022(client); struct soc_camera_link *icl = soc_camera_i2c_to_link(client); - s32 data; int ret; unsigned long flags; /* Read out the chip version register */ - data = reg_read(client, MT9V022_CHIP_VERSION); + chip_id = reg_read(client, MT9V022_CHIP_VERSION); /* must be 0x1311 or 0x1313 */ - if (data != 0x1311 data != 0x1313) { + if (chip_id != 0x1311 chip_id != 0x1313 chip_id != 0x1324) { ret = -ENODEV; dev_info(client-dev, No MT9V022 found, ID register 0x%x\n, -data); +chip_id); goto ei2c; } @@ -632,7 +639,7 @@ static int mt9v022_video_probe(struct i2c_client *client) mt9v022-fmt = mt9v022-fmts[0]; dev_info(client-dev, Detected a MT9V022 chip ID %x, %s sensor\n, -data, mt9v022-model == V4L2_IDENT_MT9V022IX7ATM ? +chip_id, mt9v022-model == V4L2_IDENT_MT9V022IX7ATM ? monochrome : colour); ret = mt9v022_init(client); @@ -728,7 +735,8 @@ static int mt9v022_s_mbus_config(struct v4l2_subdev *sd, if (!(flags V4L2_MBUS_VSYNC_ACTIVE_HIGH)) pixclk |= 0x2; - ret = reg_write(client, MT9V022_PIXCLK_FV_LV, pixclk); + ret = reg_write(client, (chip_id == 0x1324) ? MT9V024_PIXCLK_FV_LV : + MT9V022_PIXCLK_FV_LV, pixclk); if (ret 0) return ret; -- 1.7.0.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: [PATCH RFCv3] add DTMB support for DVB API
Em 10-07-2012 12:04, Antti Palosaari escreveu: Cc: Patrick Boettcher pboettc...@kernellabs.com Cc: Andreas Oberritter o...@linuxtv.org Cc: Mauro Carvalho Chehab mche...@redhat.com Acked-by: Patrick Boettcher pboettc...@kernellabs.com Signed-off-by: Antti Palosaari cr...@iki.fi On a quick check, it looks ok on my eyes. --- Documentation/DocBook/media/dvb/dvbproperty.xml | 40 ++- drivers/media/dvb/dvb-core/dvb_frontend.c | 14 ++-- drivers/media/dvb/dvb-core/dvb_frontend.h |2 ++ drivers/media/dvb/frontends/atbm8830.c |2 +- drivers/media/dvb/frontends/lgs8gl5.c |2 +- drivers/media/dvb/frontends/lgs8gxx.c |2 +- include/linux/dvb/frontend.h| 21 ++-- include/linux/dvb/version.h |2 +- 8 files changed, 74 insertions(+), 11 deletions(-) diff --git a/Documentation/DocBook/media/dvb/dvbproperty.xml b/Documentation/DocBook/media/dvb/dvbproperty.xml index e633c09..05230ed 100644 --- a/Documentation/DocBook/media/dvb/dvbproperty.xml +++ b/Documentation/DocBook/media/dvb/dvbproperty.xml @@ -194,6 +194,7 @@ get/set up to 64 properties. The actual meaning of each property is described on APSK_16, APSK_32, DQPSK, + QAM_4_NR, } fe_modulation_t; /programlisting /section @@ -265,6 +266,7 @@ typedef enum fe_code_rate { FEC_AUTO, FEC_3_5, FEC_9_10, + FEC_2_5, } fe_code_rate_t; /programlisting parawhich correspond to error correction rates of 1/2, 2/3, etc., @@ -351,7 +353,7 @@ typedef enum fe_delivery_system { SYS_ISDBC, SYS_ATSC, SYS_ATSCMH, - SYS_DMBTH, + SYS_DTMB, SYS_CMMB, SYS_DAB, SYS_DVBT2, @@ -725,6 +727,9 @@ typedef enum fe_guard_interval { GUARD_INTERVAL_1_128, GUARD_INTERVAL_19_128, GUARD_INTERVAL_19_256, + GUARD_INTERVAL_PN420, + GUARD_INTERVAL_PN595, + GUARD_INTERVAL_PN945, } fe_guard_interval_t; /programlisting @@ -733,6 +738,7 @@ typedef enum fe_guard_interval { try to find the correct guard interval (if capable) and will use TMCC to fill in the missing parameters./para para2) Intervals 1/128, 19/128 and 19/256 are used only for DVB-T2 at present/para + para3) DTMB specifies PN420, PN595 and PN945./para /section section id=DTV-TRANSMISSION-MODE titleconstantDTV_TRANSMISSION_MODE/constant/title @@ -749,6 +755,8 @@ typedef enum fe_transmit_mode { TRANSMISSION_MODE_1K, TRANSMISSION_MODE_16K, TRANSMISSION_MODE_32K, + TRANSMISSION_MODE_C1, + TRANSMISSION_MODE_C3780, } fe_transmit_mode_t; /programlisting paraNotes:/para @@ -760,6 +768,7 @@ typedef enum fe_transmit_mode { use TMCC to fill in the missing parameters./para para3) DVB-T specifies 2K and 8K as valid sizes./para para4) DVB-T2 specifies 1K, 2K, 4K, 8K, 16K and 32K./para + para5) DTMB specifies C1 and C3780./para /section section id=DTV-HIERARCHY titleconstantDTV_HIERARCHY/constant/title @@ -796,6 +805,17 @@ typedef enum fe_hierarchy { FE_GET_INFO. In the case of a legacy frontend, the result is just the same as with FE_GET_INFO, but in a more structured format /para /section + section id=DTV-INTERLEAVING + titleconstantDTV_INTERLEAVING/constant/title + paraInterleaving mode/para + programlisting +enum fe_interleaving { + INTERLEAVING_NONE, + INTERLEAVING_240, + INTERLEAVING_720, +}; + /programlisting + /section /section section id=frontend-property-terrestrial-systems titleProperties used on terrestrial delivery systems/title @@ -934,6 +954,24 @@ typedef enum fe_hierarchy { listitemparalink linkend=DTV-ATSCMH-SCCC-CODE_MODE-DconstantDTV_ATSCMH_SCCC_CODE_MODE_D/constant/link/para/listitem /itemizedlist /section + section id=dtmb-params + titleDTMB delivery system/title + paraThe following parameters are valid for DTMB:/para + itemizedlist mark='opencircle' + listitemparalink linkend=DTV-API-VERSIONconstantDTV_API_VERSION/constant/link/para/listitem + listitemparalink linkend=DTV-DELIVERY-SYSTEMconstantDTV_DELIVERY_SYSTEM/constant/link/para/listitem + listitemparalink linkend=DTV-TUNEconstantDTV_TUNE/constant/link/para/listitem + listitemparalink linkend=DTV-CLEARconstantDTV_CLEAR/constant/link/para/listitem + listitemparalink
Re: [PATCH] media: mx2_camera: Remove MX2_CAMERA_SWAP16 and MX2_CAMERA_PACK_DIR_MSB flags.
Hi Javier On Mon, 30 Jul 2012, javier Martin wrote: Hi, thank you for yor ACKs. On 20 July 2012 13:31, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote: On Thu, 12 Jul 2012, Javier Martin wrote: These flags are not used any longer and can be safely removed since the following patch: http://www.spinics.net/lists/linux-media/msg50165.html Signed-off-by: Javier Martin javier.mar...@vista-silicon.com For the ARM tree: Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de forgive my ignorance on the matter. Could you please point me to the git repository this patch should be merged? Sorry, my for the ARM tree comment was probably not clear enough. This patch should certainly go via the ARM (SoC) tree, since it only touches arch/arm. So, the maintainer (Sascha - added to CC), that will be forwarding this patch to Linus can thereby add my acked-by to this patch, if he feels like it. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- 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: patches to media_build, and a few other things
Hi Hin-Tak, Em 17-07-2012 11:35, Antti Palosaari escreveu: On 07/17/2012 01:21 AM, Hin-Tak Leung wrote: It seems I lost your original email. Anyway: I have a couple of patches to my local media_build repo, which do these: - a new option --as-is to the build script. It basically suppresses any git pull/rebase to both media_build and the ./media subdirectory (if used in combination with --main-git). In combination to --main-git, you are left on your own and be wholy responsible about what is inside ./media - I use that to check Antti's work (which is on a branch), and also since I have some interrim patches to media_build itself, I would prefer I can tell it not to pull/merge . Seems fine for me. - a small change to v4l/Makefile , to install under /lib/modules/$(KERNELRELEASE)/updates/... - recent fedora seems to have a modprobe preference to load from ../updates/... (or at least, that's the case of having installed compat-wireless at some stage - one might want to steal some code from that?), when more than one kernel module of the same name exists. This is so as not to trash distro-shipped modules (and also if one cleans out .../updates/... and runs depmod -a, one is back to distro as shipped behavior). Also trashing distro-shipped modules have the side-effect of making drpm not to work and whole kernel packages are downloaded in the next yum upgrade. This needs to be smart enough to detect if the system is Fedora and if it is a version compatible with updates (17 or upper ?). It should be noticed that Ubuntu has a similar kind of preference, but it uses the modules on a separate place. I also have a suggestion to make: - How http://linux/linuxtv.org/downloads/drivers/linux-media-LATEST.tar.bz2 is generated, probably should be documented. Over the weekend I was playing with one with timestamp Jul 7, and it is quite broken with firstly header files not in the right place (linux/v4l2-common.h instead of media/v4l2-common.h), and also the following: It does: $ run make -C linux todaytar DIR=~/tmp/media_build The script should be updating the media_build to the very latest version. I'll double check if this is happening fine. 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: rtl28xxu - rtl2832 frontend attach
On 07/30/2012 12:17 PM, David Basden wrote: On Mon, Jul 30, 2012 at 09:06:54AM +0200, poma wrote: On 06/27/2012 07:21 AM, Thomas Mair wrote: On 26.06.2012 19:17, poma wrote: On 05/28/2012 04:48 PM, Thomas Mair wrote: On 28.05.2012 08:58, Thomas Mair wrote: On 26.05.2012 04:47, poma wrote: On 05/20/2012 11:12 PM, Thomas Mair wrote: On 20.05.2012 22:08, Antti Palosaari wrote: On 20.05.2012 20:04, poma wrote: After hard/cold boot: DVB: register adapter0/net0 @ minor: 2 (0x02) rtl2832u_frontend_attach: rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 rtl28xxu_ctrl_msg: failed=-32 No compatible tuner found These errors are coming from tuner probe. As it still goes to probing and did not jump out earlier when gate is opened it means that demod is answering commands but tuner are not. My guess is that tuner is still on the reset or not powered at all. It is almost 100% sure error is wrong tuner GPIO. There is an issue with GPIO, as FC0012 tuner callback will set the value of one of the GPIO outputs. However fixing that, will not resolve the issue. So I need to debug the problem further. True. Whatever a value is changed - 'rtl2832u_power_ctrl', it brakes even more. Precisely, what breaks a tuner on next soft [re]boot are apps/utils which engage tzap/scan[dvb]. To reproduce the bug it is not necessary to reboot the machine. Simply unload and load of the dvb_usb_rtl28xxu module will lead to the same situation. I suspect, that when power is turned off, the tuner power is not switched on correctly. The mistake is not related to the OUTPUT_VAL registers but probably to the OUTPUT_DIR or OUTPUT_EN registers. What makes me wonder is if no tuning operation is performed before reboot, the driver does work correctly after that, as poma already noticed. I have some spare time today and will investigate the problem further. I tried a few things regarding the problem today and could find out a few more details, but could not resolve the issue. The GPIO pin configuration for the devices with the fc0012 (and probably also with the fc0013) tuner is the following: GPIO0: demod power GPIO3: tuner power? (the realtek driver puts this to 1 and never touches it again) GPIO4: tuner power? (maybe antenna power?) GPIO5: tuner reset GPIO6: UHF/VHF band selection All of these GPIOs are configured as output. When the device is plugged in the tuner is powered up correctly, but I am not able to power it up when a reboot is performed. What I tried was the following: - on rtl28xxu_power_ctrl off: - GPIO4 = 1 (off) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl28xxu_power_ctrl on: - GPIO3 = 1 - GPIO4 = 0 (on) - GPIO5 = 0 - GPIO6 = 0 (default state) - on rtl2832_frontend_attach: - GPIO5 = 1 - GPIO5 = 0 This sequence should ensure that the tuner is powered on when the frontend is attached, and a tuner reset is being performed before the tuner is probed. However this sequence fails the same way as it did before. I tried to add timeouts to be sure that the tuner is not probed while it is reset but that did not help either. Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Is there anybody who could look at the code, or maybe knows what could be the cause of the problem? I suspect I am just too blind to see my own mistakes. Regards Thomas Cheers Thomas, Hans-Frieder, Antti, Mauro! Hans-Frieder, are you having the same issue with fc0011af9035? Antti, no tricks up your sleeve? Senhor Mauro, is rtl2832 demod going to be merged? regards, poma Hi all, I will try to solve the issue as soon as I have some spare time. In the meantime I asked Realtek if they knew of any problems with the hardware, and I got a GPIO list which might help me to solve the problem. Regrads Thomas This is correspondent code by dbasden - fc0012 for rtl-sdr GPIOs https://gist.github.com/2171926#120 David, can you help with this tuner issue? http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898 Cheers, poma It sounds like you're definately on the right track with the GPIO pins for tuner power and reset lines, especially if it's not making it through the tuner probe. The gist you linked to above has since been merged into the rtl-sdr tree, and the version in there is likely to be a much better reference than the old patch I had posted: http://sdr.osmocom.org/trac/wiki/rtl-sdr It reliably brings the rtl and the tuner up from cold, after reboots, and multiple times without rebooting. Given
Re: set default protocol for TerraTec Cinergy XXS to nec
Em 16-07-2012 17:22, Toralf Förster escreveu: For a TerraTec Cinergy XXS USB stick (Bus 001 Device 008: ID 0ccd:00ab TerraTec Electronic GmbH ) I've to switch the protocol every time after plugin to get (at least few) keys working : $ sudo ir-keytable --protocol=nec --sysdev=`ir-keytable 21 | head -n 1 | cut -f5 -d'/'` /me wonders whether nec should be set as the default for this key in kernel or not It makes sense to patch it to use the nec protocol. If not all keys are working, it also makes sense to fix the kernel table to handle all codes, or to point to a new table where all Terratec keys are defined. Could you please write such patch? Thank you! Mauro From the syslog : 2012-07-16T22:12:53.357+02:00 n22 kernel: usb 1-1: new high-speed USB device number 7 using ehci_hcd 2012-07-16T22:12:53.460+02:00 n22 kernel: ehci_hcd :00:1a.7: dma_pool_free ehci_qh, f60cd4e0/f4e0 (bad dma) 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: New USB device found, idVendor=0ccd, idProduct=00ab 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: Product: Cinergy T XXS 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: Manufacturer: TerraTec GmbH 2012-07-16T22:12:53.471+02:00 n22 kernel: usb 1-1: SerialNumber: 01 2012-07-16T22:12:53.639+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in cold state, will try to load a firmware 2012-07-16T22:12:53.650+02:00 n22 kernel: dvb-usb: downloading firmware from file 'dvb-usb-dib0700-1.20.fw' 2012-07-16T22:12:53.854+02:00 n22 kernel: dib0700: firmware started successfully. 2012-07-16T22:12:54.355+02:00 n22 kernel: dvb-usb: found a 'Terratec Cinergy T USB XXS (HD)/ T3' in warm state. 2012-07-16T22:12:54.355+02:00 n22 kernel: dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. 2012-07-16T22:12:54.355+02:00 n22 kernel: DVB: registering new adapter (Terratec Cinergy T USB XXS (HD)/ T3) 2012-07-16T22:12:54.560+02:00 n22 kernel: DVB: registering adapter 0 frontend 0 (DiBcom 7000PC)... 2012-07-16T22:12:54.763+02:00 n22 kernel: DiB0070: successfully identified 2012-07-16T22:12:54.801+02:00 n22 kernel: Registered IR keymap rc-dib0700-rc5 2012-07-16T22:12:54.801+02:00 n22 kernel: input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc0/input15 2012-07-16T22:12:54.801+02:00 n22 kernel: rc0: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1a.7/usb1/1-1/rc/rc0 2012-07-16T22:12:54.801+02:00 n22 kernel: dvb-usb: schedule remote query interval to 50 msecs. 2012-07-16T22:12:54.801+02:00 n22 kernel: dvb-usb: Terratec Cinergy T USB XXS (HD)/ T3 successfully initialized and connected. 2012-07-16T22:12:54.801+02:00 n22 kernel: usbcore: registered new interface driver dvb_usb_dib0700 2012-07-16T22:12:55.000+02:00 n22 sudo: tfoerste : TTY=pts/2 ; PWD=/home/tfoerste/tmp ; USER=root ; COMMAND=/usr/bin/ir-keytable --protocol=nec --sysdev=rc0 -- 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: rtl28xxu - rtl2832 frontend attach
On 07/30/2012 02:56 PM, David Basden wrote: Right now I really don't know where I should look for the solution of the problem. It seems that the tuner reset does not have any effect on the tuner whatsoever. Can I suggest setting GPIO5 to 1, leave it there, and see if it breaks. If it doesn't, GPIO5 on the RTL isn't setup correctly somehow. At the same time, I was rereading code from: http://git.linuxtv.org/anttip/media_tree.git/blob/3efd26330fda97e06279cbca170ae4a0dee53220:/drivers/media/dvb/dvb-usb/rtl28xxu.c#l898 and at no point is GPIO5 actually set to an output or enabled that I can find. rtl2832u_frontend_attach skips doing so. (Actually, I seem to remember running into this problem while trying to use some DVB driver code as an example of how to setup the RTL to talk to the FC0012) Try giving the patch below a go. Sorry, I don't have a build environment to hand, so there might be a typo I haven't picked up, but the upshot is that I'm moving the FC0012 detection to the end, setting up GPIO5, resetting the tuner and then trying to probe for the FC0012. Please let me know if this helps :) David --- a/rtl28xxu.c 2012-07-30 22:31:53.789638678 +1000 +++ b/rtl28xxu.c 2012-07-30 22:48:35.774607232 +1000 @@ -550,15 +550,6 @@ priv-tuner = TUNER_NONE; - /* check FC0012 ID register; reg=00 val=a1 */ - ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012); - if (ret == 0 buf[0] == 0xa1) { - priv-tuner = TUNER_RTL2832_FC0012; - rtl2832_config = rtl28xxu_rtl2832_fc0012_config; - info(%s: FC0012 tuner found, __func__); - goto found; - } - /* check FC0013 ID register; reg=00 val=a3 */ ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0013); if (ret == 0 buf[0] == 0xa3) { @@ -640,6 +631,71 @@ goto unsupported; } + /* If it's a FC0012, we need to bring GPIO5/RESET +out of floating or it's not going to show up. +We set GPIO5 to an output, enable the output, then +reset the tuner by bringing GPIO5 high then low again. + +We're testing this last so that we don't accidentally +mess with other hardware that wouldn't like us messing +with whatever is connected to the rtl2832's GPIO5 + */ + + /* close demod I2C gate */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close); + if (ret) + goto err; + + /* Set GPIO5 to be an output */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_DIR, val); + if (ret) + goto err; + + val = 0xdf; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_DIR, val); + if (ret) + goto err; + + /* enable as output GPIO5 */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_EN, val); + if (ret) + goto err; + + val |= 0x20; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_EN, val); + if (ret) + goto err; + + /* set GPIO5 high to reset fc0012 (if it exists) */ + ret = rtl28xx_rd_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + val |= 0x20; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + /* bring GPIO5 low again after reset */ + val = 0xdf; + ret = rtl28xx_wr_reg(adap-dev, SYS_GPIO_OUT_VAL, val); + if (ret) + goto err; + + /* re-open demod I2C gate */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_open); + if (ret) + goto err; + + /* check FC0012 ID register; reg=00 val=a1 */ + ret = rtl28xxu_ctrl_msg(adap-dev, req_fc0012); + if (ret == 0 buf[0] == 0xa1) { + priv-tuner = TUNER_RTL2832_FC0012; + rtl2832_config = rtl28xxu_rtl2832_fc0012_config; + info(%s: FC0012 tuner found, __func__); + goto found; + } + unsupported: /* close demod I2C gate */ ret = rtl28xxu_ctrl_msg(adap-dev, req_gate_close); …sorry for the delay, After applied patch no luck - in attach is dmesg for working original Realtek driver(dvb_usb_rtl2832), and second one(dvb-usb-rtl28xxu) rtl2832 part by Thomas with tuner issue, still not working. Most intriguing is tuner get stucked by tuning(t-zapping)! Cheers, poma ps. Thank you so far, really thorough explanation! dvb-usb-rtl28xxu-dmesg.txt … rtl28xxu_module_init: rtl28xxu_probe: interface=0 check for warm bda 2831 check for warm 14aa 160 check for warm 14aa 161 something went very wrong, device was not found in current device list - let's see what comes next. check for warm ccd a9 check for warm 1f4d b803 dvb-usb: found a 'G-Tek Electronics Group Lifeview LV5TDLX DVB-T' in warm state. power control: 1 rtl2832u_power_ctrl: onoff=1 dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. all in all I will use 24576 bytes for streaming allocating buffer 0 buffer
[PATCH -resend] DVB: dib0700, remove double \n's from log
err() already adds \n to the end of the format string. So remove one more \n from formatting strings in the dib0700 driver. Signed-off-by: Jiri Slaby jsl...@suse.cz Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Michael Krufky mkru...@linuxtv.org --- drivers/media/dvb/dvb-usb/dib0700_core.c |6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c b/drivers/media/dvb/dvb-usb/dib0700_core.c index 7e9e00f..ef87229 100644 --- a/drivers/media/dvb/dvb-usb/dib0700_core.c +++ b/drivers/media/dvb/dvb-usb/dib0700_core.c @@ -768,13 +768,13 @@ int dib0700_rc_setup(struct dvb_usb_device *d) /* Starting in firmware 1.20, the RC info is provided on a bulk pipe */ purb = usb_alloc_urb(0, GFP_KERNEL); if (purb == NULL) { - err(rc usb alloc urb failed\n); + err(rc usb alloc urb failed); return -ENOMEM; } purb-transfer_buffer = kzalloc(RC_MSG_SIZE_V1_20, GFP_KERNEL); if (purb-transfer_buffer == NULL) { - err(rc kzalloc failed\n); + err(rc kzalloc failed); usb_free_urb(purb); return -ENOMEM; } @@ -786,7 +786,7 @@ int dib0700_rc_setup(struct dvb_usb_device *d) ret = usb_submit_urb(purb, GFP_ATOMIC); if (ret) { - err(rc submit urb failed\n); + err(rc submit urb failed); kfree(purb-transfer_buffer); usb_free_urb(purb); } -- 1.7.10.4 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365
On Sat July 28 2012 00:01:24 Sakari Ailus wrote: Hi Prabhakar, Thanks for the patch, and my apologies for delayed answer! On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8 entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry entry0x300b/entry @@ -853,10 +921,16 @@
[GIT PULL for v3.6-rc1] media updates
Hi Linus, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus This is the first part of the media patches for v3.6. During my 3-weeks vacation that finished yesterday, I got about 400 patches on my queue. My intention is to handle at least part of the pending stuff today, sending you another pull request tomorrow with some other stuff that are mature enough for v3.6. This patch series contain: - new DVB frontend: rtl2832; - new video drivers: adv7393; - some unused files got removed; - a selection API cleanup between V4L2 and V4L2 subdev API's; - a major redesign at v4l-ioctl2, in order to clean it up; - several driver fixes and improvements. Thanks! Mauro - Latest commit at the branch: c893e7c64e36087dceb4662917976a81d1754fc0 Merge branch 'patches_for_v3.6' into v4l_for_linus The following changes since commit ec3ed85f926f4e900bc48cec6e72abbe6475321f: [media] Revert [media] V4L: JPEG class documentation corrections (2012-07-07 00:12:50 -0300) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-media v4l_for_linus for you to fetch changes up to c893e7c64e36087dceb4662917976a81d1754fc0: Merge branch 'patches_for_v3.6' into v4l_for_linus (2012-07-30 14:22:44 -0300) Albert Wang (1): [media] videobuf2: correct the #ifndef text mistake in videobuf2-dma-contig.h Andy Shevchenko (1): [media] media: dvb-usb: print mac address via native %pM Antti Palosaari (5): [media] tda10071: fix DiSEqC message len check [media] tda10071: use decimal numbers for indexes and lengths [media] tda10071: convert Kernel dev_* logging [media] a8293: fix register 00 init value [media] a8293: use Kernel dev_* logging Benoît Thébaudeau (4): [media] media: gpio-ir-recv: fix missing udev by-path entry [media] media: gpio-ir-recv: add map name [media] media: gpio-ir-recv: switch to module_platform_driver media: add Analog Devices ADV7393 video encoder driver Dan Carpenter (3): [media] videobuf-dma-contig: use gfp_t for GFP flags [media] staging: solo6x10: fix | vs [media] drxk: fix a '' vs '|' bug Daniel Glöckner (10): [media] tvaudio: fix TDA9873 constants [media] tvaudio: fix tda8425_setmode [media] tvaudio: use V4L2_TUNER_MODE_SAP for TDA985x SAP [media] tvaudio: remove watch_stereo [media] tvaudio: don't use thread for TA8874Z [media] tvaudio: use V4L2_TUNER_SUB_* for bitfields [media] tvaudio: obey V4L2 tuner audio matrix [media] tvaudio: support V4L2_TUNER_MODE_LANG1_LANG2 [media] tvaudio: don't report mono when stereo is received [media] tvaudio: rename getmode and setmode David Dillow (2): [media] cx231xx: use TRANSFER_TYPE enum for cleanup [media] cx231xx: don't DMA to random addresses Dmitry Lifshitz (1): [media] tvp5150: fix kernel crash if chip is unavailable Du, Changbin (1): [media] media: gpio-ir-recv: add allowed_protos for platform data Ezequiel García (6): [media] em28xx: Make em28xx_ir_change_protocol a static function [media] em28xx: Fix wrong AC97 mic register usage [media] em28xx: Rename AC97 registers to use sound/ac97_codec.h definitions [media] em28xx: Remove unused AC97 register definitions [media] em28xx: Make a few drxk_config structs static [media] staging: solo6x10: Fix TODO file with proper maintainer Hans Verkuil (57): [media] videodev2.h: add new hwseek capability bits [media] v4l2 spec: document the new v4l2_tuner capabilities [media] S_HW_FREQ_SEEK: set capability flags and return ENODATA instead of EAGAIN [media] V4L2 spec: clarify a few modulator issues [media] V4L2 Spec: fix typo: NTSC - NRSC [media] zr364xx: embed video_device and register it at the end of probe [media] zr364xx: introduce v4l2_device [media] zr364xx: convert to the control framework [media] zr364xx: fix querycap and fill in colorspace [media] zr364xx: add support for control events [media] zr364xx: allow multiple opens [media] zr364xx: add suspend/resume support [media] v4l2-ioctl.c: move a block of code down, no other changes [media] v4l2-ioctl.c: introduce INFO_FL_CLEAR to replace switch [media] v4l2-ioctl.c: v4l2-ioctl: add debug and callback/offset functionality [media] v4l2-ioctl.c: remove an unnecessary #ifdef [media] v4l2-ioctl.c: use the new table for querycap and i/o ioctls [media] v4l2-ioctl.c: use the new table for priority ioctls [media] v4l2-ioctl.c: use the new table for format/framebuffer ioctls [media] v4l2-ioctl.c: use the new table for overlay/streamon/off ioctls [media] v4l2-ioctl.c: use the new table for std/tuner/modulator ioctls [media]
Re: [PATCH v7 1/2] media: add new mediabus format enums for dm365
Hi Hans, On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: On Sat July 28 2012 00:01:24 Sakari Ailus wrote: On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the - DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entryrsubscript7/subscript/entry + entryrsubscript6/subscript/entry + entryrsubscript5/subscript/entry + entryrsubscript4/subscript/entry + entryrsubscript3/subscript/entry + entryrsubscript2/subscript/entry + entryrsubscript1/subscript/entry + entryrsubscript0/subscript/entry + /row row id=V4L2-MBUS-FMT-SBGGR10-DPCM8-1X8 entryV4L2_MBUS_FMT_SBGGR10_DPCM8_1X8/entry entry0x300b/entry @@ -853,10 +921,16 @@
[PATCH] media: mx3_camera: buf_init() add buffer state check
This patch check the state of the buffer when calling buf_init() method. The thread http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/48587 also includes report witch can show the problem. This patch solved the problem. Both MMAP and USERPTR methods was successfully tested. Signed-off-by: Alex Gershgorin al...@meprolight.com --- drivers/media/video/mx3_camera.c | 12 +++- 1 files changed, 7 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c index f13643d..950a8fe 100644 --- a/drivers/media/video/mx3_camera.c +++ b/drivers/media/video/mx3_camera.c @@ -405,13 +405,15 @@ static int mx3_videobuf_init(struct vb2_buffer *vb) struct mx3_camera_dev *mx3_cam = ici-priv; struct mx3_camera_buffer *buf = to_mx3_vb(vb); - /* This is for locking debugging only */ - INIT_LIST_HEAD(buf-queue); - sg_init_table(buf-sg, 1); + if (buf-state != CSI_BUF_PREPARED) { + /* This is for locking debugging only */ + INIT_LIST_HEAD(buf-queue); + sg_init_table(buf-sg, 1); - buf-state = CSI_BUF_NEEDS_INIT; + buf-state = CSI_BUF_NEEDS_INIT; - mx3_cam-buf_total += vb2_plane_size(vb, 0); + mx3_cam-buf_total += vb2_plane_size(vb, 0); + } return 0; } -- 1.7.0.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: [PATCH v7 1/2] media: add new mediabus format enums for dm365
On Mon July 30 2012 21:06:33 Laurent Pinchart wrote: Hi Hans, On Monday 30 July 2012 20:36:36 Hans Verkuil wrote: On Sat July 28 2012 00:01:24 Sakari Ailus wrote: On Fri, Jul 27, 2012 at 04:25:04PM +0530, Prabhakar Lad wrote: From: Manjunath Hadli manjunath.ha...@ti.com add new enum entries for supporting the media-bus formats on dm365. These include some bayer and some non-bayer formats. V4L2_MBUS_FMT_YDYUYDYV8_1X16 and V4L2_MBUS_FMT_UV8_1X8 are used internal to the hardware by the resizer. V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 represents the bayer ALAW format that is supported by dm365 hardware. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com Acked-by: Hans Verkuil hans.verk...@cisco.com Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com Signed-off-by: Lad, Prabhakar prabhakar@ti.com Cc: Sakari Ailus sakari.ai...@iki.fi Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Documentation/DocBook/media/v4l/subdev-formats.xml | 250 +++- include/linux/v4l2-mediabus.h | 10 +- 2 files changed, 252 insertions(+), 8 deletions(-) diff --git a/Documentation/DocBook/media/v4l/subdev-formats.xml b/Documentation/DocBook/media/v4l/subdev-formats.xml index 49c532e..75dc275 100644 --- a/Documentation/DocBook/media/v4l/subdev-formats.xml +++ b/Documentation/DocBook/media/v4l/subdev-formats.xml @@ -353,9 +353,9 @@ listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem - listitemparaIf the pixel components are DPCM-compressed, a mention of the -DPCM compression and the number of bits per compressed pixel component./para - /listitem + listitemparaThe compression (optional). If the pixel components are + ALAW- or DPCM-compressed, a mention of the compression scheme and the + number of bits per compressed pixel component./para/listitem listitemparaThe number of bus samples per pixel. Pixels that are wider than the bus width must be transferred in multiple samples. Common values are 1 and 2./para/listitem @@ -504,6 +504,74 @@ entryrsubscript1/subscript/entry entryrsubscript0/subscript/entry /row + row id=V4L2-MBUS-FMT-SBGGR10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SBGGR10_ALAW8_1X8/entry + entry0x3015/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrybsubscript7/subscript/entry + entrybsubscript6/subscript/entry + entrybsubscript5/subscript/entry + entrybsubscript4/subscript/entry + entrybsubscript3/subscript/entry + entrybsubscript2/subscript/entry + entrybsubscript1/subscript/entry + entrybsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGBRG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGBRG10_ALAW8_1X8/entry + entry0x3016/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SGRBG10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SGRBG10_ALAW8_1X8/entry + entry0x3017/entry + entry/entry + entry-/entry + entry-/entry + entry-/entry + entry-/entry + entrygsubscript7/subscript/entry + entrygsubscript6/subscript/entry + entrygsubscript5/subscript/entry + entrygsubscript4/subscript/entry + entrygsubscript3/subscript/entry + entrygsubscript2/subscript/entry + entrygsubscript1/subscript/entry + entrygsubscript0/subscript/entry + /row + row id=V4L2-MBUS-FMT-SRGGB10-ALAW8-1X8 + entryV4L2_MBUS_FMT_SRGGB10_ALAW8_1X8/entry + entry0x3018/entry + entry/entry + entry-/entry
cron job: media_tree daily build: ERRORS
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:Mon Jul 30 19:00:22 CEST 2012 git hash:9bc31633c20ca6a49071f2162c232ae556151cc2 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification 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: [PATCH v7 1/2] media: add new mediabus format enums for dm365
Hi Laurent, On 07/30/2012 09:06 PM, Laurent Pinchart wrote: - bus. Possible values are YUYV, UYVY, YVYU and VYUY./para/listitem + bus. Possible values are YUYV, UYVY, YVYU and VYUY for formats with no + dummy bit, and YDYUYDYV, YDYVYDYU, YUYDYVYD and YVYDYUYD for YDYC formats. + /para/listitem listitemparaThe number of bits per pixel component. All components are transferred on the same number of bits. Common values are 8, 10 and 12./para /listitem I dicussed dummy vs. padding (zeros) with Laurent and we concluded we should use zero padding instead. The difference is that when processing the pixels no extra operations are necessary to get rid of the dummy data when the dummy bits are actually zero --- which in practice always is the case. I'm not aware of hardware that would assign padding bits (in this very purpose) that are a part of writes the width of bus width something else than zeros. It wouldn't make much sense either. So I suggest that dummy is replaced by padding which is defined to be zero. The letter in the format name could be 'Z', for example. Hans: what do you think? Bad idea. First of all, some hardware or FPGA can insert different values there. It's something that Cisco uses in some cases: it makes it easier to identify the dummy values if they have a non-zero fixed value. Another reason for not doing this is when such formats are used to display video: you don't want to force the software to fill in the dummy values with a specific value for no good reason. That would only cost extra CPU cycles. On the other hand, when you process data that includes dummy bits stored in memory, knowing that the dummy bits are zero can save a mask operation. I don't have a strong opinion whether we should use zero or dummy bits for media bus formats. For memory formats I'd be inclined to use zero bits (at least when capturing). Perhaps it would make sense to assume those dummy bits have undefined value and add some other API for retrieving/setting them where possible, e.g. a v4l2 control ? It just feels like an unnecessary API limitation to assume those dummy bits are always zero. -- Regards, Sylwester -- 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: [GIT PULL FOR v3.6] DVB USB v2
Em 09-07-2012 15:49, Antti Palosaari escreveu: On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote: Em 03-07-2012 18:47, Antti Palosaari escreveu: On 07/02/2012 04:08 PM, Antti Palosaari wrote: Here it is finally - quite totally rewritten DVB-USB-framework. I haven't got almost any feedback so far... I rebased it in order to fix compilation issues coming from Kconfig. regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git dvb_usb_pull for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898: dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29 +0300) Antti Palosaari (103): dvb_usb_v2: copy current dvb_usb as a starting point Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly. It took me some time to discover what happened. You should have named it as dvb-usb-v2 instead, or to store it into a separate directory. This is even worse as it seems that this series doesn't change all drivers to use dvb usb v2. So, it will be harder to discover what drivers are at V1 and what are at V2. I won't merge it as-is at staging/for_v3.6. I may eventually create a separate topic branch and add them there, while the namespace mess is not corrected, if I still have some time today. Otherwise, I'll only handle that after returning from vacations. I moved it to the dvb-usb-v2 directory. Same location only added patch top of that. Surely I can convert all drivers and use old directory, but IMHO it is simply too risky. We have already too much problems coming from that kind of big changes. And what goes to file naming hyphen (-) vs. underscore (_), underscore seems to be much more common inside Kernel. Anyhow, I keep directory name as dvb-usb-v2 to follow old naming. $ find ./ -type f -printf %f\n | grep _ | wc -l 21465 $ find ./ -type f -printf %f\n | grep - | wc -l 13927 The above works for me, but unfortunately, the tree can't be applied. The fact is that there are lots of duplicated symbols between dvb-usb and dvb-usb-v2. They'll fail if someone would compile everything bultin (make allyesconfig). I tried to remove the Kconfig/Makefile changes from the initial patch, moving it to happen just before the first driver using dvb-usb-v2. See: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dvb-usb-v2 The patch that adds it to the build system is enclosed. It is basically what's there at the initial patch, plus the changes done at the intermediate patches at the Makefile. The result is shown below: # make ARCH=i386 allyesconfig ... $ make ARCH=i386 CONFIG_DEBUG_SECTION_MISMATCH=y M=drivers/media drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `_GLOBAL__sub_I_65535_0_dvb_usb_download_firmware': /home/v4l/v4l/patchwork/include/linux/usb.h:197: multiple definition of `dvb_usb_disable_rc_polling' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/include/linux/usb.h:1570: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `usb_urb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb_urb.c:310: multiple definition of `usb_urb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb-urb.c:213: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_frontend_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:332: multiple definition of `dvb_usb_adapter_frontend_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:221: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_exit': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:260: multiple definition of `dvb_usb_adapter_dvb_exit' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:164: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:191: multiple definition of `dvb_usb_adapter_dvb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:98: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_device_power_ctrl': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_init.c:254: multiple definition of `dvb_usb_device_power_ctrl' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-init.c:216: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_remote_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_remote.c:42: multiple
Re: [RFC] media DT bindings
On 07/23/2012 02:14 PM, Mark Brown wrote: On Wed, Jul 18, 2012 at 07:00:15PM +0200, Sylwester Nawrocki wrote: One possible solution would be to have host/bridge drivers to register a clkdev entry for I2C client device, so it can acquire the clock through just clk_get(). We would have to ensure the clock is not tried to be accessed before it is registered by a bridge. This would require to add clock handling code to all sensor/encoder subdev drivers though.. If this is done well it could just be a simple callback, and we could probably arrange for the framework to just implement the default behaviour if the driver doesn't do anything explicit. I agree, if a clock is bound to a sub-device beforehand it could probably be done with just a callback as well. Implementing default behaviour at the framework makes a lot of sense too, it could ease the conversion process significantly. Of couse this is one of those things where we really need the generic clock API to be generally available... Indeed, I hope it won't take too much time before at least some of the platforms get converted. -- Thanks, Sylwester -- 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 05/13] media: s5p-fimc: Add device tree support for FIMC devices
Hi Laurent, On 07/26/2012 04:54 PM, Laurent Pinchart wrote: On Wednesday 18 July 2012 21:53:34 Sylwester Nawrocki wrote: I think we need a one combined RFC and continue discussions in one thread. Agreed. Still, our proposals are quite different, but I believe we need something in between. I presume we should focus more to have common bindings for subdevs that are reused among different host/ISP devices, i.e. sensors and encoders. For simple host interfaces we can likely come up with common binding patterns, but more complex processing pipelines may require a sort of individual approach. The suspend/resume handling is still something I don't have an idea on how the solution for might look like.. Instantiating all devices from a top level driver could help, but it is only going to work when platforms are converted to the common clock framework and have their clocks instantiated from device tree. This week I'm out of office, and next one or two I have some pending assignments. So there might be some delay before I can dedicate some reasonable amount of time to carry on with that topic. I unfortunately won't be attending KS this time. That's bad news :-( I still think this topic should be discussed during KS, I Yeah, shit happens.. :) I guess -ENOBUDGET this time... I didn't really plan early to attend KS, I might be coming to ELCE though. However it's a rather distant event and we'll probably get most things settled by that time. expect several developers to be interested. The media workshop might not be the best venue though, as we might need quite a lot of time. Until KS let's continue the discussion by e-mail. OK, thank you for taking time to review the RFCs. -- Regards, Sylwester -- 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: Asus PVR-416
On Mon, 2012-07-30 at 06:57 -0400, Jerry Haggard wrote: I've been trying to get an ASUS PVR-416 card to work with MythTV .25 on Scientific Linux 6. I have a bttv card working, my setup works in general, etc, and the driver attempts to load. But when I check dmesg, I keep getting firmware load errors and checksum errors. I've tried every firmware I could find. I've used the one from Atrpms, I've downloaded the correctly named firmware from ivtv, but no luck. Anyone know anything about this card? I've tried cutting the drivers myself like it says in the direcitons at mythtv.org. This is supposed to be a supported card, does anyone have any experience with it? No experience with it. It is supposedly a Blackbird design supported by the cx88 driver. My standard response for legacy PCI cards that are responding somewhat, but aren't working properly, is to 1. remove all the legacy PCI cards from all the slots 2. blow the dust out of all the slots 3. if feasible, reseat only the 1 card and test again 4. reseat all the cards and test again Since legacy PCI uses reflected wave switching, dust in any one slot can cause problems. It's a troubleshooting step that's easy enough to do. If that doesn't work, we would need to see the output of dmesg and/or /var/log/messages when the module is being loaded and the firmware loaded. If providing logs, please don't just grep on the 'cx88' lines, since other modules are involved in getting the card working. Regards, Andy -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[media-ctl PATCH 1/1] libv4l2subdev: Add v4l2_subdev_enum_mbus_code()
v4l2_subdev_enum_mbus_code() enumerates over supported media bus formats on a pad. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi --- src/v4l2subdev.c | 23 +++ src/v4l2subdev.h | 14 ++ 2 files changed, 37 insertions(+), 0 deletions(-) diff --git a/src/v4l2subdev.c b/src/v4l2subdev.c index d60bd7e..6b6df0a 100644 --- a/src/v4l2subdev.c +++ b/src/v4l2subdev.c @@ -58,6 +58,29 @@ void v4l2_subdev_close(struct media_entity *entity) entity-fd = -1; } +int v4l2_subdev_enum_mbus_code(struct media_entity *entity, + uint32_t *code, uint32_t pad, uint32_t index) +{ + struct v4l2_subdev_mbus_code_enum c; + int ret; + + ret = v4l2_subdev_open(entity); + if (ret 0) + return ret; + + memset(c, 0, sizeof(c)); + c.pad = pad; + c.index = index; + + ret = ioctl(entity-fd, VIDIOC_SUBDEV_ENUM_MBUS_CODE, c); + if (ret 0) + return -errno; + + *code = c.code; + + return 0; +} + int v4l2_subdev_get_format(struct media_entity *entity, struct v4l2_mbus_framefmt *format, unsigned int pad, enum v4l2_subdev_format_whence which) diff --git a/src/v4l2subdev.h b/src/v4l2subdev.h index 5d55482..1cca7b9 100644 --- a/src/v4l2subdev.h +++ b/src/v4l2subdev.h @@ -22,6 +22,7 @@ #ifndef __SUBDEV_H__ #define __SUBDEV_H__ +#include stdint.h #include linux/v4l2-subdev.h struct media_entity; @@ -47,6 +48,19 @@ int v4l2_subdev_open(struct media_entity *entity); void v4l2_subdev_close(struct media_entity *entity); /** + * @brief Enumerate mbus pixel codes. + * @param entity - subdev-device media entity. + * @param code - mbus pixel code + * + * Enumerate media bus pixel codes. This is just a wrapper for + * VIDIOC_SUBDEV_ENUM_MBUS_CODE IOCTL. + * + * @return 0 on success, or a negative error code on failure. + */ +int v4l2_subdev_enum_mbus_code(struct media_entity *entity, + uint32_t *code, uint32_t pad, uint32_t index); + +/** * @brief Retrieve the format on a pad. * @param entity - subdev-device media entity. * @param format - format to be filled. -- 1.7.2.5 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Use a named union in struct v4l2_ioctl_info
Hi Mauro, On Fri, 13 Jul 2012 11:25:30 +1000 Stephen Rothwell s...@canb.auug.org.au wrote: On Thu, 12 Jul 2012 18:06:24 +0200 Hans Verkuil hverk...@xs4all.nl wrote: struct v4l2_ioctl_info uses an anonymous union, which is initialized in the v4l2_ioctls table. Unfortunately gcc 4.6 uses a non-standard syntax for that, so trying to compile v4l2-ioctl.c with an older gcc will fail. It is possible to work around this by testing the gcc version, but in this case it is easier to make the union named since it is used in only a few places. Randy, Stephen, this patch should solve the v4l2-ioctl.c compilation problem in linux-next. Since Mauro is still on holiday you'll have to apply it manually. I have added this as a merge fix for today. Ping? -- Cheers, Stephen Rothwells...@canb.auug.org.au pgpMPD0fMfa9j.pgp Description: PGP signature
Re: [PULL] video_visstrim for 3.6
Em 26-07-2012 06:36, Javier Martin escreveu: Hi Mauro, this pull request is composed of two series that provide support for two mem2mem devices: - 'm2m-deinterlace' video deinterlacer - 'coda video codec' I've included platform support for them too. The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: https://github.com/jmartinc/video_visstrim.git for_3.6 for you to fetch changes up to 9bb10266da63ae7f8f198573e099580e9f98f4e8: i.MX27: Visstrim_M10: Add support for deinterlacing driver. (2012-07-26 10:57:30 +0200) Javier Martin (5): i.MX: coda: Add platform support for coda in i.MX27. media: coda: Add driver for Coda video codec. Visstrim M10: Add support for Coda. media: Add mem2mem deinterlacing driver. i.MX27: Visstrim_M10: Add support for deinterlacing driver. arch/arm/mach-imx/clk-imx27.c |4 +- arch/arm/mach-imx/devices-imx27.h |4 + arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 49 +- arch/arm/plat-mxc/devices/Kconfig |6 +- arch/arm/plat-mxc/devices/Makefile |1 + arch/arm/plat-mxc/devices/platform-imx27-coda.c | 37 + arch/arm/plat-mxc/include/mach/devices-common.h |8 + I need ARM maintainer's ack for the patches that touch the above 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: [GIT PULL FOR v3.6] DVB USB v2
On 07/30/2012 11:46 PM, Mauro Carvalho Chehab wrote: Em 09-07-2012 15:49, Antti Palosaari escreveu: On 07/07/2012 01:22 AM, Mauro Carvalho Chehab wrote: Em 03-07-2012 18:47, Antti Palosaari escreveu: On 07/02/2012 04:08 PM, Antti Palosaari wrote: Here it is finally - quite totally rewritten DVB-USB-framework. I haven't got almost any feedback so far... I rebased it in order to fix compilation issues coming from Kconfig. regards Antti The following changes since commit 6887a4131da3adaab011613776d865f4bcfb5678: Linux 3.5-rc5 (2012-06-30 16:08:57 -0700) are available in the git repository at: git://linuxtv.org/anttip/media_tree.git dvb_usb_pull for you to fetch changes up to 747abaa1e0ee4415e67026c119cb73e6277f4898: dvb_usb_v2: remove usb_clear_halt() from stream (2012-07-02 15:54:29 +0300) Antti Palosaari (103): dvb_usb_v2: copy current dvb_usb as a starting point Naming the DVB USB v2 as dvb_usb, instead of dvb-usb is very very ugly. It took me some time to discover what happened. You should have named it as dvb-usb-v2 instead, or to store it into a separate directory. This is even worse as it seems that this series doesn't change all drivers to use dvb usb v2. So, it will be harder to discover what drivers are at V1 and what are at V2. I won't merge it as-is at staging/for_v3.6. I may eventually create a separate topic branch and add them there, while the namespace mess is not corrected, if I still have some time today. Otherwise, I'll only handle that after returning from vacations. I moved it to the dvb-usb-v2 directory. Same location only added patch top of that. Surely I can convert all drivers and use old directory, but IMHO it is simply too risky. We have already too much problems coming from that kind of big changes. And what goes to file naming hyphen (-) vs. underscore (_), underscore seems to be much more common inside Kernel. Anyhow, I keep directory name as dvb-usb-v2 to follow old naming. $ find ./ -type f -printf %f\n | grep _ | wc -l 21465 $ find ./ -type f -printf %f\n | grep - | wc -l 13927 The above works for me, but unfortunately, the tree can't be applied. The fact is that there are lots of duplicated symbols between dvb-usb and dvb-usb-v2. They'll fail if someone would compile everything bultin (make allyesconfig). I tried to remove the Kconfig/Makefile changes from the initial patch, moving it to happen just before the first driver using dvb-usb-v2. See: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/dvb-usb-v2 The patch that adds it to the build system is enclosed. It is basically what's there at the initial patch, plus the changes done at the intermediate patches at the Makefile. The result is shown below: # make ARCH=i386 allyesconfig ... $ make ARCH=i386 CONFIG_DEBUG_SECTION_MISMATCH=y M=drivers/media drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `_GLOBAL__sub_I_65535_0_dvb_usb_download_firmware': /home/v4l/v4l/patchwork/include/linux/usb.h:197: multiple definition of `dvb_usb_disable_rc_polling' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/include/linux/usb.h:1570: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `usb_urb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb_urb.c:310: multiple definition of `usb_urb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/usb-urb.c:213: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_frontend_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:332: multiple definition of `dvb_usb_adapter_frontend_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:221: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_exit': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:260: multiple definition of `dvb_usb_adapter_dvb_exit' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:164: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_adapter_dvb_init': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_dvb.c:191: multiple definition of `dvb_usb_adapter_dvb_init' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c:98: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_device_power_ctrl': /home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb_usb_init.c:254: multiple definition of `dvb_usb_device_power_ctrl' drivers/media/dvb/dvb-usb/dvb-usb.o:/home/v4l/v4l/patchwork/drivers/media/dvb/dvb-usb/dvb-usb-init.c:216: first defined here drivers/media/dvb/dvb-usb/dvb_usbv2.o: In function `dvb_usb_remote_init':
Re: [PATCH] xc5000: Add MODULE_FIRMWARE statements
Em 25-07-2012 10:48, Antti Palosaari escreveu: On 07/25/2012 04:24 PM, Devin Heitmueller wrote: On Wed, Jul 25, 2012 at 9:15 AM, Tim Gardner tim.gard...@canonical.com wrote: This will make modinfo more useful with regard to discovering necessary firmware files. Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Michael Krufky mkru...@kernellabs.com Cc: Eddi De Pieri e...@depieri.net Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com --- drivers/media/common/tuners/xc5000.c |8 ++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/drivers/media/common/tuners/xc5000.c b/drivers/media/common/tuners/xc5000.c index dcca42c..4d33f86 100644 --- a/drivers/media/common/tuners/xc5000.c +++ b/drivers/media/common/tuners/xc5000.c @@ -210,13 +210,15 @@ struct xc5000_fw_cfg { u16 size; }; +#define XC5000A_FIRMWARE dvb-fe-xc5000-1.6.114.fw static const struct xc5000_fw_cfg xc5000a_1_6_114 = { - .name = dvb-fe-xc5000-1.6.114.fw, + .name = XC5000A_FIRMWARE, .size = 12401, }; +#define XC5000C_FIRMWARE dvb-fe-xc5000c-41.024.5.fw static const struct xc5000_fw_cfg xc5000c_41_024_5 = { - .name = dvb-fe-xc5000c-41.024.5.fw, + .name = XC5000C_FIRMWARE, .size = 16497, }; @@ -1253,3 +1255,5 @@ EXPORT_SYMBOL(xc5000_attach); MODULE_AUTHOR(Steven Toth); MODULE_DESCRIPTION(Xceive xc5000 silicon tuner driver); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(XC5000A_FIRMWARE); +MODULE_FIRMWARE(XC5000C_FIRMWARE); -- Hi Tim, I'm just eyeballing the patch and I'm not familiar with this new functionality, but where are the new macros you're specifying actually defined? You're swapping out the filename for XC5000A_FIRMWARE, but where is the actual reference to dvb-fe-xc5000-1.6.114.fw? Also, Mauro, can I merge this into my tree first rather than you pulling it direct? I've got a whole patch series for xc5000 that I'm slated to issue a PULL for this weekend, and I *really* don't want to rebase the series for a four line change (which will definitely cause a conflict). Devin, As you didn't send your pull request in time for 3.6, I'll add this one, as otherwise it will miss the 3.6 bus. You don't need to rebase your pull request due to that anyway, as, if a merge conflict happens, I'll fix it, as it should be trivial. I'm fixing trivial merge conflicts like that all the time. Just today, I fixed maybe dozens of similar ones. The conflicts that I ask developers to rework are the ones where the complex logic is modified by two different patches. Devin Also this issue has been spoken earlier and nacked. It was 2009 when Ben Hutchings sends large patch serie adding MODULE_FIRMWARE for every Linux-Media driver. I am not sure if arguments are changed after that to allow it now. http://www.mail-archive.com/linux-media@vger.kernel.org/msg11373.html On Ben's patchset, firmwares were added to the bridge driver. That's wrong. Adding it to the driver that actually uses the firmware looks OK on my eyes. regards Antti 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] Add support for Prof Revolution DVB-S2 8000 PCI-E card
Em 26-07-2012 15:08, Mariusz Bialonczyk escreveu: The device is based on STV0903 demodulator, STB6100 tuner and CX23885 chipset; subsystem id: 8000:3034 Signed-off-by: Mariusz Bialonczyk ma...@skyboo.net This is the second time I see this patch. It seems very similar to the one sent by Wojciech. So, who is the author of this patch? --- drivers/media/video/cx23885/Kconfig |1 + drivers/media/video/cx23885/cx23885-cards.c | 10 + drivers/media/video/cx23885/cx23885-dvb.c | 56 +++ drivers/media/video/cx23885/cx23885.h |1 + 4 files changed, 68 insertions(+) diff --git a/drivers/media/video/cx23885/Kconfig b/drivers/media/video/cx23885/Kconfig index b391e9b..510adfe 100644 --- a/drivers/media/video/cx23885/Kconfig +++ b/drivers/media/video/cx23885/Kconfig @@ -21,6 +21,7 @@ config VIDEO_CX23885 select DVB_STV6110 if !DVB_FE_CUSTOMISE select DVB_CX24116 if !DVB_FE_CUSTOMISE select DVB_STV0900 if !DVB_FE_CUSTOMISE + select DVB_STV090x if !DVB_FE_CUSTOMISE select DVB_DS3000 if !DVB_FE_CUSTOMISE select DVB_STV0367 if !DVB_FE_CUSTOMISE select MEDIA_TUNER_MT2131 if !MEDIA_TUNER_CUSTOMISE You've included 3 files at -dvb: +#include stv090x.h +#include stb6100.h +#include stb6100_cfg.h but you're selecting only STV090x. It seems you missed stb6100 here. diff --git a/drivers/media/video/cx23885/cx23885-cards.c b/drivers/media/video/cx23885/cx23885-cards.c index 080e111..50fedff 100644 --- a/drivers/media/video/cx23885/cx23885-cards.c +++ b/drivers/media/video/cx23885/cx23885-cards.c @@ -564,6 +564,10 @@ struct cx23885_board cx23885_boards[] = { [CX23885_BOARD_TEVII_S471] = { .name = TeVii S471, .portb = CX23885_MPEG_DVB, + }, + [CX23885_BOARD_PROF_8000] = { + .name = Prof Revolution DVB-S2 8000, + .portb = CX23885_MPEG_DVB, } }; const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards); @@ -776,6 +780,10 @@ struct cx23885_subid cx23885_subids[] = { .subvendor = 0xd471, .subdevice = 0x9022, .card = CX23885_BOARD_TEVII_S471, + }, { + .subvendor = 0x8000, + .subdevice = 0x3034, + .card = CX23885_BOARD_PROF_8000, }, }; const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids); @@ -1155,6 +1163,7 @@ void cx23885_gpio_setup(struct cx23885_dev *dev) cx_set(GP0_IO, 0x00040004); break; case CX23885_BOARD_TBS_6920: + case CX23885_BOARD_PROF_8000: cx_write(MC417_CTL, 0x0036); cx_write(MC417_OEN, 0x1000); cx_set(MC417_RWD, 0x0002); @@ -1536,6 +1545,7 @@ void cx23885_card_setup(struct cx23885_dev *dev) case CX23885_BOARD_TEVII_S470: case CX23885_BOARD_TEVII_S471: case CX23885_BOARD_DVBWORLD_2005: + case CX23885_BOARD_PROF_8000: ts1-gen_ctrl_val = 0x5; /* Parallel */ ts1-ts_clk_en_val = 0x1; /* Enable TS_CLK */ ts1-src_sel_val = CX23885_SRC_SEL_PARALLEL_MPEG_VIDEO; diff --git a/drivers/media/video/cx23885/cx23885-dvb.c b/drivers/media/video/cx23885/cx23885-dvb.c index cd54268..ba046ea 100644 --- a/drivers/media/video/cx23885/cx23885-dvb.c +++ b/drivers/media/video/cx23885/cx23885-dvb.c @@ -63,6 +63,9 @@ #include stv0367.h #include drxk.h #include mt2063.h +#include stv090x.h +#include stb6100.h +#include stb6100_cfg.h static unsigned int debug; @@ -489,6 +492,42 @@ static struct xc5000_config mygica_x8506_xc5000_config = { .if_khz = 5380, }; +static struct stv090x_config prof_8000_stv090x_config = { +.device = STV0903, +.demod_mode = STV090x_SINGLE, +.clk_mode = STV090x_CLK_EXT, +.xtal = 2700, +.address= 0x6A, +.ts1_mode = STV090x_TSMODE_PARALLEL_PUNCTURED, +.repeater_level = STV090x_RPTLEVEL_64, +.adc1_range = STV090x_ADC_2Vpp, +.diseqc_envelope_mode = false, + +.tuner_get_frequency= stb6100_get_frequency, +.tuner_set_frequency= stb6100_set_frequency, +.tuner_set_bandwidth= stb6100_set_bandwidth, +.tuner_get_bandwidth= stb6100_get_bandwidth, +}; + +static struct stb6100_config prof_8000_stb6100_config = { + .tuner_address = 0x60, + .refclock = 2700, +}; + +static int p8000_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage) +{ + struct cx23885_tsport *port = fe-dvb-priv; + struct cx23885_dev *dev = port-dev; + + if (voltage == SEC_VOLTAGE_18) + cx_write(MC417_RWD, 0x1e00); + else if
Re: [PATCH 2/2] [media] ngene: add support for Terratec Cynergy 2400i, Dual DVB-T
Em 29-07-2012 17:50, Patrice Chotard escreveu: [media] ngene: add support for Terratec Cynergy 2400i Dual DVB-T Sorry, but the patch got line wrapped. Please re-send this patch series. Thanks! Mauro This code is based on ngene initial check-in (dae52d009fc950b5c209260d50fcc000f5becd3c) Signed-off-by: Patrice Chotard patricechot...@free.fr --- drivers/media/dvb/ngene/ngene-cards.c | 263 + 1 files changed, 263 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/ngene/ngene-cards.c b/drivers/media/dvb/ngene/ngene-cards.c index 7539a5d..08c610f 100644 --- a/drivers/media/dvb/ngene/ngene-cards.c +++ b/drivers/media/dvb/ngene/ngene-cards.c @@ -42,6 +42,8 @@ #include mt2131.h #include tda18271c2dd.h #include drxk.h +#include drxd.h +#include dvb-pll.h // @@ -312,6 +314,235 @@ static int demod_attach_lg330x(struct ngene_channel *chan) return (chan-fe) ? 0 : -ENODEV; } +static int demod_attach_drxd(struct ngene_channel *chan) +{ + struct drxd_config *feconf; + + feconf = chan-dev-card_info-fe_config[chan-number]; + + chan-fe = dvb_attach(drxd_attach, feconf, chan, + chan-i2c_adapter, chan-dev-pci_dev-dev); + if (!chan-fe) { + pr_err(No DRXD found!\n); + return -ENODEV; + } + + if (!dvb_attach(dvb_pll_attach, chan-fe, feconf-pll_address, + chan-i2c_adapter, + feconf-pll_type)) { + pr_err(No pll(%d) found!\n, feconf-pll_type); + return -ENODEV; + } + return 0; +} + +// +/* EEPROM TAGS **/ +// + +#define MICNG_EE_START 0x0100 +#define MICNG_EE_END0x0FF0 + +#define MICNG_EETAG_END00x +#define MICNG_EETAG_END10x + +/* 0x0001 - 0x000F reserved for housekeeping */ +/* 0x - 0xFFFE reserved for housekeeping */ + +/* Micronas assigned tags + EEProm tags for hardware support */ + +#define MICNG_EETAG_DRXD1_OSCDEVIATION 0x1000 /* 2 Bytes data */ +#define MICNG_EETAG_DRXD2_OSCDEVIATION 0x1001 /* 2 Bytes data */ + +#define MICNG_EETAG_MT2060_1_1STIF 0x1100 /* 2 Bytes data */ +#define MICNG_EETAG_MT2060_2_1STIF 0x1101 /* 2 Bytes data */ + +/* Tag range for OEMs */ + +#define MICNG_EETAG_OEM_FIRST 0xC000 +#define MICNG_EETAG_OEM_LAST 0xFFEF + +static int i2c_write_eeprom(struct i2c_adapter *adapter, + u8 adr, u16 reg, u8 data) +{ + u8 m[3] = {(reg 8), (reg 0xff), data}; + struct i2c_msg msg = {.addr = adr, .flags = 0, .buf = m, + .len = sizeof(m)}; + + if (i2c_transfer(adapter, msg, 1) != 1) { + pr_err(DEVICE_NAME : Error writing EEPROM!\n); + return -EIO; + } + return 0; +} + +static int i2c_read_eeprom(struct i2c_adapter *adapter, +u8 adr, u16 reg, u8 *data, int len) +{ + u8 msg[2] = {(reg 8), (reg 0xff)}; + struct i2c_msg msgs[2] = {{.addr = adr, .flags = 0, +.buf = msg, .len = 2 }, + {.addr = adr, .flags = I2C_M_RD, +.buf = data, .len = len} }; + + if (i2c_transfer(adapter, msgs, 2) != 2) { + pr_err(DEVICE_NAME : Error reading EEPROM\n); + return -EIO; + } + return 0; +} + +static int ReadEEProm(struct i2c_adapter *adapter, + u16 Tag, u32 MaxLen, u8 *data, u32 *pLength) +{ + int status = 0; + u16 Addr = MICNG_EE_START, Length, tag = 0; + u8 EETag[3]; + + while (Addr + sizeof(u16) + 1 MICNG_EE_END) { + if (i2c_read_eeprom(adapter, 0x50, Addr, EETag, sizeof(EETag))) + return -1; + tag = (EETag[0] 8) | EETag[1]; + if (tag == MICNG_EETAG_END0 || tag == MICNG_EETAG_END1) + return -1; + if (tag == Tag) + break; + Addr += sizeof(u16) + 1 + EETag[2]; + } + if (Addr + sizeof(u16) + 1 + EETag[2] MICNG_EE_END) { + pr_err(DEVICE_NAME +: Reached EOEE @ Tag = %04x Length = %3d\n, +tag, EETag[2]); + return -1; + } + Length = EETag[2]; + if (Length MaxLen) + Length = (u16) MaxLen; + if (Length 0) { + Addr += sizeof(u16) + 1; + status = i2c_read_eeprom(adapter, 0x50, Addr, data, Length); + if (!status) { + *pLength = EETag[2]; + if (Length EETag[2]) +
[git:v4l-dvb/for_v3.6] [media] s2255drv: Add MODULE_FIRMWARE statement
This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] s2255drv: Add MODULE_FIRMWARE statement Author: Tim Gardner tim.gard...@canonical.com Date:Tue Jul 24 16:52:27 2012 -0300 Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Dean Anderson linux-...@sensoray.com Cc: Hans Verkuil hans.verk...@cisco.com Cc: Dan Carpenter dan.carpen...@oracle.com Cc: Hans de Goede hdego...@redhat.com Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/video/s2255drv.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=1bec982dd432a187459d59900a16cd79d5eea7fc diff --git a/drivers/media/video/s2255drv.c b/drivers/media/video/s2255drv.c index 01c2179..95007dd 100644 --- a/drivers/media/video/s2255drv.c +++ b/drivers/media/video/s2255drv.c @@ -2686,3 +2686,4 @@ MODULE_DESCRIPTION(Sensoray 2255 Video for Linux driver); MODULE_AUTHOR(Dean Anderson (Sensoray Company Inc.)); MODULE_LICENSE(GPL); MODULE_VERSION(S2255_VERSION); +MODULE_FIRMWARE(FIRMWARE_FILE_NAME); -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[git:v4l-dvb/for_v3.6] [media] lgs8gxx: Declare MODULE_FIRMWARE usage
This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] lgs8gxx: Declare MODULE_FIRMWARE usage Author: Tim Gardner tim.gard...@canonical.com Date:Wed Jul 25 12:54:02 2012 -0300 Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Hans Verkuil hans.verk...@cisco.com Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/dvb/frontends/lgs8gxx.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=ccb7c5939cc7185fdecb913f4c7cba94cf82287e diff --git a/drivers/media/dvb/frontends/lgs8gxx.c b/drivers/media/dvb/frontends/lgs8gxx.c index 568363a..c2ea274 100644 --- a/drivers/media/dvb/frontends/lgs8gxx.c +++ b/drivers/media/dvb/frontends/lgs8gxx.c @@ -40,6 +40,8 @@ static int debug; static int fake_signal_str = 1; +#define LGS8GXX_FIRMWARE lgs8g75.fw + module_param(debug, int, 0644); MODULE_PARM_DESC(debug, Turn on/off frontend debugging (default:off).); @@ -592,7 +594,7 @@ static int lgs8g75_init_data(struct lgs8gxx_state *priv) int rc; int i; - rc = request_firmware(fw, lgs8g75.fw, priv-i2c-dev); + rc = request_firmware(fw, LGS8GXX_FIRMWARE, priv-i2c-dev); if (rc) return rc; @@ -1070,3 +1072,4 @@ EXPORT_SYMBOL(lgs8gxx_attach); MODULE_DESCRIPTION(Legend Silicon LGS8913/LGS8GXX DMB-TH demodulator driver); MODULE_AUTHOR(David T. L. Wong davidtlw...@gmail.com); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(LGS8GXX_FIRMWARE); -- 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:v4l-dvb/for_v3.6] [media] xc5000: Add MODULE_FIRMWARE statements
This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] xc5000: Add MODULE_FIRMWARE statements Author: Tim Gardner tim.gard...@canonical.com Date:Wed Jul 25 09:15:19 2012 -0300 This will make modinfo more useful with regard to discovering necessary firmware files. Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: Michael Krufky mkru...@kernellabs.com Cc: Eddi De Pieri e...@depieri.net Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/common/tuners/xc5000.c |8 ++-- 1 files changed, 6 insertions(+), 2 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=3422f2a6bc0ed9b1fa159a33d94efef08f142570 diff --git a/drivers/media/common/tuners/xc5000.c b/drivers/media/common/tuners/xc5000.c index bac8009..362a8d7 100644 --- a/drivers/media/common/tuners/xc5000.c +++ b/drivers/media/common/tuners/xc5000.c @@ -210,13 +210,15 @@ struct xc5000_fw_cfg { u16 size; }; +#define XC5000A_FIRMWARE dvb-fe-xc5000-1.6.114.fw static const struct xc5000_fw_cfg xc5000a_1_6_114 = { - .name = dvb-fe-xc5000-1.6.114.fw, + .name = XC5000A_FIRMWARE, .size = 12401, }; +#define XC5000C_FIRMWARE dvb-fe-xc5000c-41.024.5.fw static const struct xc5000_fw_cfg xc5000c_41_024_5 = { - .name = dvb-fe-xc5000c-41.024.5.fw, + .name = XC5000C_FIRMWARE, .size = 16497, }; @@ -1259,3 +1261,5 @@ EXPORT_SYMBOL(xc5000_attach); MODULE_AUTHOR(Steven Toth); MODULE_DESCRIPTION(Xceive xc5000 silicon tuner driver); MODULE_LICENSE(GPL); +MODULE_FIRMWARE(XC5000A_FIRMWARE); +MODULE_FIRMWARE(XC5000C_FIRMWARE); -- 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:v4l-dvb/for_v3.6] [media] tlg2300: Declare MODULE_FIRMWARE usage
This is an automatic generated email to let you know that the following patch were queued at the http://git.linuxtv.org/media_tree.git tree: Subject: [media] tlg2300: Declare MODULE_FIRMWARE usage Author: Tim Gardner tim.gard...@canonical.com Date:Wed Jul 25 15:41:04 2012 -0300 Cc: Huang Shijie shij...@gmail.com Cc: Kang Yong kangy...@telegent.com Cc: Zhang Xiaobing xbzh...@telegent.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Tim Gardner tim.gard...@canonical.com Acked-by: Huang Shijie shij...@gmail.com Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com drivers/media/video/tlg2300/pd-main.c |4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) --- http://git.linuxtv.org/media_tree.git?a=commitdiff;h=4d98015eef6fa97b0cbba7310041ab75b223524b diff --git a/drivers/media/video/tlg2300/pd-main.c b/drivers/media/video/tlg2300/pd-main.c index c096b3f..7b1f6eb 100644 --- a/drivers/media/video/tlg2300/pd-main.c +++ b/drivers/media/video/tlg2300/pd-main.c @@ -53,7 +53,8 @@ int debug_mode; module_param(debug_mode, int, 0644); MODULE_PARM_DESC(debug_mode, 0 = disable, 1 = enable, 2 = verbose); -static const char *firmware_name = tlg2300_firmware.bin; +#define TLG2300_FIRMWARE tlg2300_firmware.bin +static const char *firmware_name = TLG2300_FIRMWARE; static struct usb_driver poseidon_driver; static LIST_HEAD(pd_device_list); @@ -532,3 +533,4 @@ MODULE_AUTHOR(Telegent Systems); MODULE_DESCRIPTION(For tlg2300-based USB device ); MODULE_LICENSE(GPL); MODULE_VERSION(0.0.2); +MODULE_FIRMWARE(TLG2300_FIRMWARE); -- 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