Re: [RFCv3 API PATCH 15/31] v4l2-core: Add new V4L2_CAP_MONOTONIC_TS capability.
Hi Sylwester, Sylwester Nawrocki wrote: On 09/17/2012 07:19 PM, Sakari Ailus wrote: Sylwester Nawrocki wrote: On 09/16/2012 05:33 PM, Laurent Pinchart wrote: On Sunday 16 September 2012 15:57:14 Hans Verkuil wrote: On Sat September 15 2012 22:16:24 Sylwester Nawrocki wrote: On 09/15/2012 02:35 PM, Hans Verkuil wrote: One alternative might be to use a v4l2_buffer flag instead. That does have the advantage that in the future we can add additional flags should we need to support different clocks. Should we ever add support to switch clocks dynamically, then a buffer flag is more suitable than a driver capability. In that scenario it does make real sense to have a flag (or really mask). Say something like this: /* Clock Mask */ V4L2_BUF_FLAG_CLOCK_MASK 0xf000 /* Possible Clocks */ V4L2_BUF_FLAG_CLOCK_SYSTEM 0x I realized that this should be called: V4L2_BUF_FLAG_CLOCK_UNKNOWN 0x With a comment saying that is clock is either the system clock or a monotonic clock. That reflects the current situation correctly. V4L2_BUF_FLAG_CLOCK_MONOTONIC 0x1000 There is already lots of overhead related to the buffers management, could we perhaps have the most common option defined in a way that drivers don't need to update each buffer's flags before dequeuing, only to indicate the timestamp type (other than flags being modified in videobuf) ? Well, if all vb2 drivers use the monotonic clock, then you could do it in __fill_v4l2_buffer: instead of clearing just the state flags you'd clear state + clock flags, and you OR in the monotonic flag in the case statement below (adding just a single b-flags |= line in the DEQUEUED case). So that wouldn't add any overhead. Not that I think setting a flag will add any measurable overhead in any case. Yes, that might be indeed negligible overhead, especially if it's done well. User space logic usually adds much more to complexity. Might be good idea to add some helpers to videobuf2, so handling timestamps is as simple as possible in drivers. Of the V4L2 core. Taking the timestamp has to be done usually at a very precise point in the code, and that's a decision I think is better done in the driver. Timestamps are also independent of the videobuf2. Yes, good point. All in all videobuf2 belongs to v4l2-core, doesn't it ? ;) You're correct. I meant to say that it could (or should) be separate from handling the buffers themselves. Taking a timestamp indeed needs some care and precision, but setting a flag could be considered a sort of separate issue - it's more relaxed and videobuf2 already handles the buffer flags. True. This buffer flags idea sounds to me worse than the capability flag. After all the drivers should use monotonic clock timestamps, shouldn't they ? Yes. But you have monotonic and raw monotonic clocks at the moment, and perhaps others will be added in the future. You can't change clocks if you put this in the querycap capabilities. Fair enough. BTW, CLOCK_MONOTONIC_RAW is not defined in any POSIX standard, is it ? It's Linux-specific. Perhaps it's worth noting that both V4L2 and ALSA are Linux-specific, too. :-) OK. I don't mind V4L2 and ALSA being Linux-specific... :) Raw wonotonic time could be better in some use cases as it's not NTP-adjusted. Which one is better for the purpose might be system-specific, albeit I'm leaning on the side of the monotonic in a general case. Yeah, I guess it's all determined by streams from what subsystems we're trying to synchronize and what clocks are used there. If there is a possibility to select from various clocks in at least one of the subsystems then we're all set. It's not only that, it's also that the clock has to be suitable for the synchronisation problem at hand. Currently realtime timestamps could be used by ALSA and V4L2 but I could hardly recommend using them for audio/video synchronisation. The main issue here is that we already have plenty of different clocks and there is a need on the video side for at least: 1. reporting to user space what clock is used by a driver, and optionally 2. selecting clock type on user request. I think the solution for 1 should be such it makes easy and clean to do 2. I'd really like to keep this door open. My experience is that if something is possible, then someone somewhere will want to use it. Indeed, caps flags approach might be too limited anyway. And a v4l2 control might be not good for reporting things like these. Why not? Are there other mechanisms that are suitable for this than controls? If we end up using controls for this, then we should make it as easy as possible for the drivers. Sorry, my concern here was that timestamps are needed by all video devices and I wasn't sure if there are any video nodes that don't implement the v4l2 control ioctls. I.e. we might be enforcing adding controls support only for the purpose of being able to query the timestamps type. That was my concern here about using controls.
Re: [PATCH 27/34] media: mx2_camera: use managed functions to clean up code
On Mon, Sep 17, 2012 at 03:36:07PM +0200, javier Martin wrote: This patch breaks the driver: Javier, Can you please apply the following change to see if it fixes the problem? Shawn @@ -1783,6 +1783,8 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) goto exit; } + platform_set_drvdata(pdev, NULL); + pcdev-soc_host.drv_name= MX2_CAM_DRV_NAME, pcdev-soc_host.ops = mx2_soc_camera_host_ops, pcdev-soc_host.priv= pcdev; soc-camera-pdrv soc-camera-pdrv.0: Probing soc-camera-pdrv.0 Unable to handle kernel paging request at virtual address 656d6162 pgd = c0004000 [656d6162] *pgd= Internal error: Oops: 8005 [#1] PREEMPT ARM Modules linked in: CPU: 0Not tainted (3.6.0-rc5-01222-g3413fb1 #12) PC is at 0x656d6162 LR is at soc_camera_host_register+0x230/0x81c pc : [656d6162]lr : [c01ff6a0]psr: 4033 sp : c3025e48 ip : fp : r10: c03f236c r9 : r8 : 0001 r7 : r6 : c317d414 r5 : c30431a0 r4 : c317d600 r3 : 656d6163 r2 : c3025e18 r1 : 000c r0 : c317d600 Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA Thumb Segment kernel Control: 0005317f Table: a0004000 DAC: 0017 Process swapper (pid: 1, stack limit = 0xc3024270) Stack: (0xc3025e48 to 0xc3026000) 5e40: c3006460 c3192960 0043 c317d638 c005d624 5e60: 0043 c317d410 c317d478 c317d414 c02012f0 c317d410 0043 5e80: c31a9800 c31a9820 c022ca74 c300ab20 c306e4a8 c306e4a0 5ea0: c3c0 4013 80d0 c317d410 c317d410 c306e4a8 c306e4a0 0001 5ec0: c03f236c c02c8d50 c03535ee c317d410 c02c8a44 5ee0: c306e4a8 c306e4a8 c03fc478 c03fc478 0050 c03e0774 c03dc684 c0189d30 5f00: c306e4a8 c0188c3c c306e4a8 c306e4dc c03fc478 0050 c0188db8 5f20: c03fc478 c3025f30 c0188d58 c0187610 c300760c c3079ad0 c03fc478 c03fc478 5f40: c318e680 c03f6458 c0187d24 c03535ee c03535ee c3025f58 c03fc478 5f60: 0001 c04049c0 c01892c8 c03fc464 0001 c04049c0 5f80: 0050 c018a05c c03dc67c c03d4e84 c04049c0 c00087c8 0006 0006 5fa0: c03eeca0 c03dc67c 0007 c03dc67c 0007 c04049c0 c03c41a4 0050 5fc0: c03e0774 c03c42f4 0006 0006 c03c41a4 c03c4214 5fe0: c0014900 0013 c0014900 [c01ff6a0] (soc_camera_host_register+0x230/0x81c) from [c02c8d50] (mx2_camera_probe+0x30c/0x3ac) [c02c8d50] (mx2_camera_probe+0x30c/0x3ac) from [c0189d30] (platform_drv_probe+0x14/0x18) [c0189d30] (platform_drv_probe+0x14/0x18) from [c0188c3c] (driver_probe_device+0xb0/0x1cc) [c0188c3c] (driver_probe_device+0xb0/0x1cc) from [c0188db8] (__driver_attach+0x60/0x84) [c0188db8] (__driver_attach+0x60/0x84) from [c0187610] (bus_for_each_dev+0x48/0x84) [c0187610] (bus_for_each_dev+0x48/0x84) from [c0187d24] (bus_add_driver+0x9c/0x20c) [c0187d24] (bus_add_driver+0x9c/0x20c) from [c01892c8] (driver_register+0xa0/0x138) [c01892c8] (driver_register+0xa0/0x138) from [c018a05c] (platform_driver_probe+0x18/0x98) [c018a05c] (platform_driver_probe+0x18/0x98) from [c00087c8] (do_one_initcall+0x94/0x16c) [c00087c8] (do_one_initcall+0x94/0x16c) from [c03c42f4] (kernel_init+0xe0/0x1ac) [c03c42f4] (kernel_init+0xe0/0x1ac) from [c0014900] (kernel_thread_exit+0x0/0x8) Code: bad PC value ---[ end trace 7f259a1ce2e10b1a ]--- Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/34] i.MX multi-platform support
Hi Shawn, On Mon, Sep 17, 2012 at 01:34:29PM +0800, Shawn Guo wrote: The series enables multi-platform support for imx. Since the required frameworks (clk, pwm) and spare_irq have already been adopted on imx, the series is all about cleaning up mach/* headers. Along with the changes, arch/arm/plat-mxc gets merged into arch/arm/mach-imx. It's based on a bunch of branches (works from others), Rob's initial multi-platform series, Arnd's platform-data and smp_ops (Marc's) and imx 3.7 material (Sascha and myself). It's available on branch below. git://git.linaro.org/people/shawnguo/linux-2.6.git imx/multi-platform It's been tested on imx5 and imx6, and only compile-tested on imx2 and imx3, so testing on imx2/3 are appreciated. Subsystem maintainers, I plan to send the whole series via arm-soc tree at the end of 3.7 merge window when all dependant bits hit mainline. Please have a look at the patches you get copied and provide ACKs if the changes are good. Thanks. I just had a look at the remaining initcalls in arch-imx. Most of them are protected with a cpu_is_*, but this one should be fixed before i.MX is enabled for multi platform: arch/arm/mach-imx/devices/devices.c:48:core_initcall(mxc_device_init); I think this won't harm others directly, but it will register i.MX related devices on foreign platforms. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- 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: [alsa-devel] [PATCH 00/34] i.MX multi-platform support
On Tue, Sep 18, 2012 at 09:52:13AM +0200, Sascha Hauer wrote: I just had a look at the remaining initcalls in arch-imx. Most of them are protected with a cpu_is_*, but this one should be fixed before i.MX is enabled for multi platform: arch/arm/mach-imx/devices/devices.c:48:core_initcall(mxc_device_init); Ah, I missed that. Thanks for reminding, Sascha. Shawn -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/34] i.MX multi-platform support
On Mon, Sep 17, 2012 at 09:51:38AM +0200, Sascha Hauer wrote: I gave it a test on i.MX1, i.MX27, i.MX31 and i.MX35. All run fine, but the last patch breaks the imx_v4_v5_defconfig: Somehow it now defaults to ARMv7 based machines. I haven't looked into it, just reenabled ARMv4/ARMv5 and the boards again - works. The config should be updated with the last patch. Yes, I will rework the patch with all these and Arnd's comment on the last patch taken into account. I'm fine with the changes to mx2-camera, but Javier should give his ok to it, he has worked on it quite a lot recently. One other issue related to imx-dma, see comment to that patch. Otherwise: Acked-by: Sascha Hauer s.ha...@pengutronix.de Tested-by: Sascha Hauer s.ha...@pengutronix.de Thanks a lot. Shawn -- 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 27/34] media: mx2_camera: use managed functions to clean up code
Hi Shawn, On 18 September 2012 09:43, Shawn Guo shawn@linaro.org wrote: On Mon, Sep 17, 2012 at 03:36:07PM +0200, javier Martin wrote: This patch breaks the driver: Javier, Can you please apply the following change to see if it fixes the problem? Shawn @@ -1783,6 +1783,8 @@ static int __devinit mx2_camera_probe(struct platform_device *pdev) goto exit; } + platform_set_drvdata(pdev, NULL); + pcdev-soc_host.drv_name= MX2_CAM_DRV_NAME, pcdev-soc_host.ops = mx2_soc_camera_host_ops, pcdev-soc_host.priv= pcdev; Yes. That fixes the problem. With this fix: Tested-by: Javier Martin javier.mar...@vista-silicon.com 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: [PATCH 28/34] media: mx2_camera: remove mach/hardware.h inclusion
On 17 September 2012 15:59, Guennadi Liakhovetski g.liakhovet...@gmx.de wrote:
On Mon, 17 Sep 2012, javier Martin wrote:
Hi Shawn,
On 17 September 2012 11:21, Guennadi Liakhovetski g.liakhovet...@gmx.de
wrote:
On Mon, 17 Sep 2012, Shawn Guo wrote:
It changes the driver to use platform_device_id rather than cpu_is_xxx
to determine the controller type, and updates the platform code
accordingly.
As the result, mach/hardware.h inclusion gets removed from the driver.
Signed-off-by: Shawn Guo shawn@linaro.org
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: linux-media@vger.kernel.org
Tested-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
i.MX25 support is broken and is scheduled for removal.
It is not yet, I haven't pushed those your patches yet.
Thanks
Guennadi
I think we should not keep on trying to maintain it. Couldn't we just
drop it? It only makes maintenance tasks more difficult.
Thanks
Guennadi
---
arch/arm/mach-imx/clk-imx25.c |6 +-
arch/arm/mach-imx/clk-imx27.c |6 +-
arch/arm/mach-imx/devices/devices-common.h |1 +
arch/arm/mach-imx/devices/platform-mx2-camera.c | 12 +--
drivers/media/video/mx2_camera.c| 95
+--
5 files changed, 85 insertions(+), 35 deletions(-)
diff --git a/arch/arm/mach-imx/clk-imx25.c b/arch/arm/mach-imx/clk-imx25.c
index 1aea073..71fe521 100644
--- a/arch/arm/mach-imx/clk-imx25.c
+++ b/arch/arm/mach-imx/clk-imx25.c
@@ -231,9 +231,9 @@ int __init mx25_clocks_init(void)
clk_register_clkdev(clk[esdhc2_ipg_per], per,
sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ipg], ipg, sdhci-esdhc-imx25.1);
clk_register_clkdev(clk[esdhc2_ahb], ahb, sdhci-esdhc-imx25.1);
- clk_register_clkdev(clk[csi_ipg_per], per, mx2-camera.0);
- clk_register_clkdev(clk[csi_ipg], ipg, mx2-camera.0);
- clk_register_clkdev(clk[csi_ahb], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ipg_per], per, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ipg], ipg, imx25-camera.0);
+ clk_register_clkdev(clk[csi_ahb], ahb, imx25-camera.0);
clk_register_clkdev(clk[dummy], audmux, NULL);
clk_register_clkdev(clk[can1_ipg], NULL, flexcan.0);
clk_register_clkdev(clk[can2_ipg], NULL, flexcan.1);
diff --git a/arch/arm/mach-imx/clk-imx27.c b/arch/arm/mach-imx/clk-imx27.c
index 5ff5cf0..e26de52 100644
--- a/arch/arm/mach-imx/clk-imx27.c
+++ b/arch/arm/mach-imx/clk-imx27.c
@@ -224,7 +224,7 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[per3_gate], per, imx-fb.0);
clk_register_clkdev(clk[lcdc_ipg_gate], ipg, imx-fb.0);
clk_register_clkdev(clk[lcdc_ahb_gate], ahb, imx-fb.0);
- clk_register_clkdev(clk[csi_ahb_gate], ahb, mx2-camera.0);
+ clk_register_clkdev(clk[csi_ahb_gate], ahb, imx27-camera.0);
clk_register_clkdev(clk[usb_div], per, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ipg_gate], ipg, fsl-usb2-udc);
clk_register_clkdev(clk[usb_ahb_gate], ahb, fsl-usb2-udc);
@@ -251,8 +251,8 @@ int __init mx27_clocks_init(unsigned long fref)
clk_register_clkdev(clk[i2c2_ipg_gate], NULL, imx21-i2c.1);
clk_register_clkdev(clk[owire_ipg_gate], NULL, mxc_w1.0);
clk_register_clkdev(clk[kpp_ipg_gate], NULL, imx-keypad);
- clk_register_clkdev(clk[emma_ahb_gate], emma-ahb, mx2-camera.0);
- clk_register_clkdev(clk[emma_ipg_gate], emma-ipg, mx2-camera.0);
+ clk_register_clkdev(clk[emma_ahb_gate], emma-ahb,
imx27-camera.0);
+ clk_register_clkdev(clk[emma_ipg_gate], emma-ipg,
imx27-camera.0);
clk_register_clkdev(clk[emma_ahb_gate], ahb, m2m-emmaprp.0);
clk_register_clkdev(clk[emma_ipg_gate], ipg, m2m-emmaprp.0);
clk_register_clkdev(clk[iim_ipg_gate], iim, NULL);
diff --git a/arch/arm/mach-imx/devices/devices-common.h
b/arch/arm/mach-imx/devices/devices-common.h
index 7f2698c..8112a1a 100644
--- a/arch/arm/mach-imx/devices/devices-common.h
+++ b/arch/arm/mach-imx/devices/devices-common.h
@@ -202,6 +202,7 @@ struct platform_device *__init imx_add_mx3_sdc_fb(
#include linux/platform_data/camera-mx2.h
struct imx_mx2_camera_data {
+ const char *devid;
resource_size_t iobasecsi;
resource_size_t iosizecsi;
resource_size_t irqcsi;
diff --git a/arch/arm/mach-imx/devices/platform-mx2-camera.c
b/arch/arm/mach-imx/devices/platform-mx2-camera.c
index 9ad5b2d..b88877d 100644
--- a/arch/arm/mach-imx/devices/platform-mx2-camera.c
+++ b/arch/arm/mach-imx/devices/platform-mx2-camera.c
@@ -9,14 +9,16 @@
#include mach/hardware.h
#include devices-common.h
-#define imx_mx2_camera_data_entry_single(soc)
\
+#define imx_mx2_camera_data_entry_single(soc, _devid)
Re: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Tue, Sep 18, 2012 at 5:40 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Initially I thought Xen would be the cause of the problem, but after having written on the Xen development mailing list and talked about it with a couple developers, it isn't very clear where the problem is. So far I haven't been able to get the smallest warning or error. This is a very common problem when attempting to use any PCI/PCIe tuner under a hypervisor. Essentially the issue is all of the virtualization solutions provide very poor interrupt latency, which results in the data being lost. Devices delivering a high bitrate stream of data in realtime are much more likely for this problem to be visible since such devices have very little buffering (it's not like a hard drive controller where it can just deliver the data slower). The problem is not specific to the cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards work this way, and they cannot really be blamed for expecting to run in an environment with really crappy interrupt latency. I won't go as far as to say, abandon all hope, but you're not really likely to find any help in this forum. Well, it is not what I wanted to hear but at least I know for sure what is happening. I´ve post your words on the xen ml, I´ll see what they have to say. I still don´t understand how graphics pass through works and a tuner card has problems. I also have read reports of people running vdr on a domU. Anyway, thanks for the prompt and quick answer. -- Javier Marcet jmar...@gmail.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
[GIT PULL v2] Initial i.MX5/CODA7 support for the CODA driver
Hi Mauro, please pull the following patches that fix a few issues in the coda driver and add initial firmware loading and encoding support for the CODA7 series VPU contained in i.MX51 and i.MX53 SoCs. I have dropped Ezequiel's vb2_queue_init commit and rebased onto current linux-media staging/for_v3.7. The following changes since commit 36aee5ff9098a871bda38dbbdad40ad59f6535cf: [media] ir-rx51: Adjust dependencies (2012-09-15 19:44:30 -0300) are available in the git repository at: git://git.pengutronix.de/git/pza/linux.git coda/for_v3.7 for you to fetch changes up to 64a01774162824f4a39d67ee2a4913d5ea2c651e: media: coda: set up buffers to be sized as negotiated with s_fmt (2012-09-18 10:34:45 +0200) Philipp Zabel (13): media: coda: firmware loading for 64-bit AXI bus width media: coda: add i.MX53 / CODA7541 platform support media: coda: fix IRAM/AXI handling for i.MX53 media: coda: allocate internal framebuffers separately from v4l2 buffers media: coda: ignore coda busy status in coda_job_ready media: coda: keep track of active instances media: coda: stop all queues in case of lockup media: coda: enable user pointer support media: coda: wait for picture run completion in start/stop_streaming media: coda: fix sizeimage setting in try_fmt media: coda: add horizontal / vertical flipping support media: coda: add byte size slice limit control media: coda: set up buffers to be sized as negotiated with s_fmt Sylwester Nawrocki (1): coda: Add V4L2_CAP_VIDEO_M2M capability flag drivers/media/platform/Kconfig |3 +- drivers/media/platform/coda.c | 431 +--- drivers/media/platform/coda.h | 30 ++- 3 files changed, 344 insertions(+), 120 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/34] media: mx1_camera: remove the driver
On Tuesday 18 September 2012, Shawn Guo wrote: On Mon, Sep 17, 2012 at 10:33:25AM +0200, Guennadi Liakhovetski wrote: Ok, it used to compile not-so-long-ago, but it doesn't seem to be cared for a lot lately. Let's give Paulius a bit more time to react to this mail, otherwise I'll have no objections. Just as an idea, to make it a bit milder we could first mark it BROKEN and add to remove schedule... But I don't mind either way. I chose to remove the driver completely rather than marking it BROKEN because the removal of the driver cleans up platform code a lot :) Ok, if we hear anything back from Paulius in the next couple of weeks, I keep the driver there with BROKEN marked. Sounds fine to me. Of course, if someone wants the driver back and is willing to fix it, we'll just revert this patch even after the driver is gone. I would like an Ack from Mauro however. You did not Cc him directly in the patch, and he probably has an opionion on it as well, or may want to take this patch through his git tree. Arnd -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv2 5/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/saa7706h.c | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
index bb953ef..97cf867 100644
--- a/drivers/media/radio/saa7706h.c
+++ b/drivers/media/radio/saa7706h.c
@@ -199,8 +199,20 @@ static int saa7706h_get_reg16(struct v4l2_subdev *sd, u16
reg)
u8 buf[2];
int err;
u8 regaddr[] = {reg 8, reg};
- struct i2c_msg msg[] = { {client-addr, 0, sizeof(regaddr), regaddr},
- {client-addr, I2C_M_RD, sizeof(buf), buf} };
+ struct i2c_msg msg[] = {
+ {
+ .addr = client-addr,
+ .flags = 0,
+ .len = sizeof(regaddr),
+ .buf = regaddr
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf
+ }
+ };
err = saa7706h_i2c_transfer(client, msg, ARRAY_SIZE(msg));
if (err)
--
1.7.5.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
[PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/msp3400-driver.c | 42 ++-
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/msp3400-driver.c
b/drivers/media/i2c/msp3400-driver.c
index aeb22be..b8cef8d 100644
--- a/drivers/media/i2c/msp3400-driver.c
+++ b/drivers/media/i2c/msp3400-driver.c
@@ -119,12 +119,32 @@ int msp_reset(struct i2c_client *client)
static u8 write[3] = { I2C_MSP_DSP + 1, 0x00, 0x1e };
u8 read[2];
struct i2c_msg reset[2] = {
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_off },
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_on },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_off
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_on
+ },
};
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .flags = 0,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ },
};
v4l_dbg(3, msp_debug, client, msp_reset\n);
@@ -143,8 +163,18 @@ static int msp_read(struct i2c_client *client, int dev,
int addr)
u8 write[3];
u8 read[2];
struct i2c_msg msgs[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read }
+ {
+ .addr = client-addr,
+ .flags = 0,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ }
};
write[0] = dev + 1;
--
1.7.5.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
[PATCHv2 1/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/ks0127.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ee7ca2d..4ede64a 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -319,8 +319,18 @@ static u8 ks0127_read(struct v4l2_subdev *sd, u8 reg)
struct i2c_client *client = v4l2_get_subdevdata(sd);
char val = 0;
struct i2c_msg msgs[] = {
- { client-addr, 0, sizeof(reg), reg },
- { client-addr, I2C_M_RD | I2C_M_NO_RD_ACK, sizeof(val), val }
+ {
+ .addr = client-addr,
+ .flags = 0,
+ .len = sizeof(reg),
+ .buf = reg
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD | I2C_M_NO_RD_ACK,
+ .len = sizeof(val),
+ .buf = val
+ }
};
int ret;
--
1.7.5.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
[PATCHv2 0/6] media: convert to c99 format
The series tries to convert the i2c_msg to c99 struct. This may avoid issues like below if someone tries to add an element to the structure. http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg08972.html Special thanks to Julia Lawall for helping it automate. By the below script. http://www.mail-archive.com/cocci@diku.dk/msg02753.html Shubhrajyoti D (6): media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format drivers/media/i2c/ks0127.c| 14 +++- drivers/media/i2c/msp3400-driver.c| 42 +--- drivers/media/i2c/tvaudio.c | 14 +++- drivers/media/radio/radio-tea5764.c | 14 ++-- drivers/media/radio/saa7706h.c| 16 - drivers/media/radio/si470x/radio-si470x-i2c.c | 24 ++--- 6 files changed, 103 insertions(+), 21 deletions(-) -- 1.7.5.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
[PATCHv2 4/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 24 ++--
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index f867f04..be2efb9 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -98,8 +98,12 @@ int si470x_get_register(struct si470x_device *radio, int
regnr)
{
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
@@ -119,8 +123,12 @@ int si470x_set_register(struct si470x_device *radio, int
regnr)
int i;
u16 buf[WRITE_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, 0, sizeof(u16) * WRITE_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = 0,
+ .len = sizeof(u16) * WRITE_REG_NUM,
+ .buf = (void *)buf
+ },
};
for (i = 0; i WRITE_REG_NUM; i++)
@@ -146,8 +154,12 @@ static int si470x_get_all_registers(struct si470x_device
*radio)
int i;
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
--
1.7.5.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
[PATCHv2 3/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/radio-tea5764.c | 14 +++---
1 files changed, 11 insertions(+), 3 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 6b1fae3..41de676 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -151,8 +151,11 @@ int tea5764_i2c_read(struct tea5764_device *radio)
u16 *p = (u16 *) radio-regs;
struct i2c_msg msgs[1] = {
- { radio-i2c_client-addr, I2C_M_RD, sizeof(radio-regs),
- (void *)radio-regs },
+ { .addr = radio-i2c_client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(radio-regs),
+ .buf = (void *)radio-regs
+ },
};
if (i2c_transfer(radio-i2c_client-adapter, msgs, 1) != 1)
return -EIO;
@@ -167,7 +170,12 @@ int tea5764_i2c_write(struct tea5764_device *radio)
struct tea5764_write_regs wr;
struct tea5764_regs *r = radio-regs;
struct i2c_msg msgs[1] = {
- { radio-i2c_client-addr, 0, sizeof(wr), (void *) wr },
+ {
+ .addr = radio-i2c_client-addr,
+ .flags = 0,
+ .len = sizeof(wr),
+ .buf = (void *)wr
+ },
};
wr.intreg = r-intreg 0xff;
wr.frqset = __cpu_to_be16(r-frqset);
--
1.7.5.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
[PATCHv2 2/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/tvaudio.c | 14 --
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index 321b315..c9c1da3 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -217,8 +217,18 @@ static int chip_read2(struct CHIPSTATE *chip, int subaddr)
unsigned char write[1];
unsigned char read[1];
struct i2c_msg msgs[2] = {
- { c-addr, 0,1, write },
- { c-addr, I2C_M_RD, 1, read }
+ {
+ .addr = c-addr,
+ .flags = 0,
+ .len = 1,
+ .buf = write
+ },
+ {
+ .addr = c-addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = read
+ }
};
write[0] = subaddr;
--
1.7.5.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: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99 format
On Tue, Sep 18, 2012 at 3:26 PM, Venu Byravarasu vbyravar...@nvidia.com wrote:
-Original Message-
From: linux-kernel-ow...@vger.kernel.org [mailto:linux-kernel-
ow...@vger.kernel.org] On Behalf Of Shubhrajyoti D
Sent: Tuesday, September 18, 2012 3:21 PM
To: linux-media@vger.kernel.org
Cc: linux-ker...@vger.kernel.org; julia.law...@lip6.fr; Shubhrajyoti D
Subject: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99
format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other
fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/msp3400-driver.c | 42
++-
1 files changed, 36 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/msp3400-driver.c
b/drivers/media/i2c/msp3400-driver.c
index aeb22be..b8cef8d 100644
--- a/drivers/media/i2c/msp3400-driver.c
+++ b/drivers/media/i2c/msp3400-driver.c
@@ -119,12 +119,32 @@ int msp_reset(struct i2c_client *client)
static u8 write[3] = { I2C_MSP_DSP + 1, 0x00, 0x1e };
u8 read[2];
struct i2c_msg reset[2] = {
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_off },
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_on },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_off
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_on
+ },
};
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .flags = 0,
Does flags not contain 0 by default?
It does however I felt that 0 means write so letting it be explicit.
In case a removal is preferred that's doable too however felt it is
more readable this way.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 0/6] media: convert to c99 format
On Tue 18 September 2012 11:50:37 Shubhrajyoti D wrote: The series tries to convert the i2c_msg to c99 struct. This may avoid issues like below if someone tries to add an element to the structure. http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg08972.html Special thanks to Julia Lawall for helping it automate. By the below script. http://www.mail-archive.com/cocci@diku.dk/msg02753.html That looks much better. For the whole series: Acked-by: Hans Verkuil hans.verk...@cisco.com Regards, Hans Shubhrajyoti D (6): media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format drivers/media/i2c/ks0127.c| 14 +++- drivers/media/i2c/msp3400-driver.c| 42 +--- drivers/media/i2c/tvaudio.c | 14 +++- drivers/media/radio/radio-tea5764.c | 14 ++-- drivers/media/radio/saa7706h.c| 16 - drivers/media/radio/si470x/radio-si470x-i2c.c | 24 ++--- 6 files changed, 103 insertions(+), 21 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99 format
-Original Message-
From: Shubhrajyoti Datta [mailto:omaplinuxker...@gmail.com]
Sent: Tuesday, September 18, 2012 3:30 PM
To: Venu Byravarasu
Cc: Shubhrajyoti D; linux-media@vger.kernel.org; linux-
ker...@vger.kernel.org; julia.law...@lip6.fr
Subject: Re: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99
format
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .flags = 0,
Does flags not contain 0 by default?
It does however I felt that 0 means write so letting it be explicit.
In case a removal is preferred that's doable too however felt it is
more readable this way.
Though it adds readability, it carries an overhead of one write operation too.
So, better to remove 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
[RFCv1 PATCH 00/11] davinci: clean up input/output/subdev config
Hi Prabhakar, This patch series does some driver cleanup and reorganizes the config structs that are used to set up subdevices. The current driver associates an input or output with a subdev, but multiple inputs may use the same subdev and some inputs may not use a subdev at all (this is the case for our hardware). Several other things were also configured in the wrong structure. For example the vpif_interface struct is really part of the channel config and has nothing to do with the subdev. What is missing here is that the output doesn't have the same flexibility as the input when it comes to configuration. It would be good if someone can pick this up as a follow-up since it's unlikely I'll be working on that. What would also be nice is that by leaving the inputs or outputs for the second channel empty (NULL) in the configuration you can disable the second video node, e.g. trying to use it will always result in ENODEV or something. This patch series will at least make things more flexible. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFCv1 PATCH 02/11] vpif_display: remove unused data structures.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_display.h | 15 ---
1 file changed, 15 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index 1263de6..ad22c70 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -66,12 +66,6 @@ struct video_obj {
u32 output_id; /* Current output id */
};
-struct vbi_obj {
- int num_services;
- struct vpif_vbi_params vbiparams; /* vpif parameters for the raw
-* vbi data */
-};
-
struct vpif_disp_buffer {
struct vb2_buffer vb;
struct list_head list;
@@ -137,7 +131,6 @@ struct channel_obj {
struct vpif_params vpifparams;
struct common_obj common[VPIF_NUMOBJECTS];
struct video_obj video;
- struct vbi_obj vbi;
};
/* File handle structure */
@@ -169,12 +162,4 @@ struct vpif_config_params {
u8 min_numbuffers;
};
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
- u16 service_id;
- u16 service_line[2];
- u16 enc_service_id;
- u8 bytestowrite;
-};
-
#endif /* DAVINCIHD_DISPLAY_H */
--
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
[RFCv1 PATCH 05/11] vpif_capture: remove unnecessary can_route flag.
Calling a subdev op that isn't implemented will just return -ENOIOCTLCMD
No need to have a flag for that.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c|2 --
arch/arm/mach-davinci/board-dm646x-evm.c |2 --
drivers/media/video/davinci/vpif_capture.c | 18 --
include/media/davinci/vpif_types.h |1 -
4 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d0954a2..d92e0ab 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1209,7 +1209,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -1225,7 +1224,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 958679a..a0be63b 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -603,7 +603,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_CVBS_VI2B,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -619,7 +618,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
},
.input = INPUT_SVIDEO_VI2C_VI1C,
.output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
- .can_route = 1,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index eec687c..ae5cabf 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -1487,15 +1487,13 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
}
}
- if (subdev_info-can_route) {
- input = subdev_info-input;
- output = subdev_info-output;
- ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
- input, output, 0);
- if (ret 0) {
- vpif_dbg(1, debug, Failed to set input\n);
- return ret;
- }
+ input = subdev_info-input;
+ output = subdev_info-output;
+ ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video, s_routing,
+ input, output, 0);
+ if (ret 0 ret != -ENOIOCTLCMD) {
+ vpif_dbg(1, debug, Failed to set input\n);
+ return ret;
}
ch-input_idx = index;
ch-curr_subdev_info = subdev_info;
@@ -1505,7 +1503,7 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
/* update tvnorms from the sub device input info */
ch-video_dev-tvnorms = chan_cfg-inputs[index].input.std;
- return ret;
+ return 0;
}
/**
diff --git a/include/media/davinci/vpif_types.h
b/include/media/davinci/vpif_types.h
index d8f6ab1..1fe46a5 100644
--- a/include/media/davinci/vpif_types.h
+++ b/include/media/davinci/vpif_types.h
@@ -39,7 +39,6 @@ struct vpif_subdev_info {
struct i2c_board_info board_info;
u32 input;
u32 output;
- unsigned can_route:1;
struct vpif_interface vpif_if;
};
--
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
[RFCv1 PATCH 10/11] vpif_display: use a v4l2_subdev pointer to call a subdev.
This makes it easier to have outputs without subdevs.
This needs more work. The way the outputs are configured should be identical
to how inputs are configured.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_display.c | 17 +
drivers/media/video/davinci/vpif_display.h |1 +
2 files changed, 10 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index a6e8ddd..5f1d736 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1232,6 +1232,8 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
vpif_err(Failed to set output standard\n);
ch-output_idx = i;
+ if (vpif_obj.sd[i])
+ ch-sd = vpif_obj.sd[i];
return ret;
}
@@ -1302,14 +1304,13 @@ static int vpif_s_dv_timings(struct file *file, void
*priv,
}
/* Configure subdevice timings, if any */
- ret = v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
- video, s_dv_timings, timings);
+ ret = v4l2_subdev_call(ch-sd, video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, Custom DV timings not supported by
subdevice\n);
- return -EINVAL;
+ return -ENODATA;
}
- if (ret 0) {
+ if (ret 0 ret != -ENODEV) {
vpif_dbg(2, debug, Error setting custom DV timings\n);
return ret;
}
@@ -1434,8 +1435,7 @@ static int vpif_dbg_g_register(struct file *file, void
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
- g_register, reg);
+ return v4l2_subdev_call(ch-sd, core, g_register, reg);
}
/*
@@ -1452,8 +1452,7 @@ static int vpif_dbg_s_register(struct file *file, void
*priv,
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
- s_register, reg);
+ return v4l2_subdev_call(ch-sd, core, s_register, reg);
}
#endif
@@ -1721,6 +1720,8 @@ static __init int vpif_probe(struct platform_device *pdev)
}
ch-initialized = 0;
+ if (subdev_count)
+ ch-sd = vpif_obj.sd[0];
ch-channel_id = j;
if (j 2)
ch-common[VPIF_VIDEO_INDEX].numbuffers =
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index b602def..1e436ac 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -126,6 +126,7 @@ struct channel_obj {
u8 initialized; /* flag to indicate whether
* encoder is initialized */
u32 output_idx; /* Current output index */
+ struct v4l2_subdev *sd; /* Current output subdev (may be NULL)
*/
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
--
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
[RFCv1 PATCH 11/11] davinci: move struct vpif_interface to chan_cfg.
struct vpif_interface is channel specific, not subdev specific.
Move it to the channel config.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c| 24
arch/arm/mach-davinci/board-dm646x-evm.c | 24
drivers/media/video/davinci/vpif_capture.c |2 +-
include/media/davinci/vpif_types.h |2 +-
4 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index 514d4d4..3081ea4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1211,12 +1211,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
{
.name = TVP5147_CH1,
@@ -1224,12 +1218,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
};
@@ -1239,10 +1227,22 @@ static struct vpif_capture_config
da850_vpif_capture_config = {
.chan_config[0] = {
.inputs = da850_ch0_inputs,
.input_count = ARRAY_SIZE(da850_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.chan_config[1] = {
.inputs = da850_ch1_inputs,
.input_count = ARRAY_SIZE(da850_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.card_name = DA850/OMAP-L138 Video Capture,
};
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index 0daec7e..ad249c7 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,12 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
{
.name = TVP5147_CH1,
@@ -614,12 +608,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .vpif_if = {
- .if_type = VPIF_IF_BT656,
- .hd_pol = 1,
- .vd_pol = 1,
- .fid_pol = 0,
- },
},
};
@@ -659,10 +647,22 @@ static struct vpif_capture_config dm646x_vpif_capture_cfg
= {
.chan_config[0] = {
.inputs = dm6467_ch0_inputs,
.input_count = ARRAY_SIZE(dm6467_ch0_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
.chan_config[1] = {
.inputs = dm6467_ch1_inputs,
.input_count = ARRAY_SIZE(dm6467_ch1_inputs),
+ .vpif_if = {
+ .if_type = VPIF_IF_BT656,
+ .hd_pol = 1,
+ .vd_pol = 1,
+ .fid_pol = 0,
+ },
},
};
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 5266167..466f02d 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -1295,7 +1295,7 @@ static int vpif_set_input(
ch-input_idx = index;
ch-sd = sd;
/* copy interface parameters to vpif */
- ch-vpifparams.iface = subdev_info-vpif_if;
+ ch-vpifparams.iface = chan_cfg-vpif_if;
/* update tvnorms from the sub device input info */
ch-video_dev-tvnorms =
[RFCv1 PATCH 08/11] vpif_display: first init subdevs, then register device nodes.
When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_display.c | 59 ++--
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 19338b4..a6e8ddd 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1674,6 +1674,32 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
}
+ i2c_adap = i2c_get_adapter(1);
+ config = pdev-dev.platform_data;
+ subdev_count = config-subdev_count;
+ subdevdata = config-subdevinfo;
+ vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
+ GFP_KERNEL);
+ if (vpif_obj.sd == NULL) {
+ vpif_err(unable to allocate memory for subdevice pointers\n);
+ err = -ENOMEM;
+ goto vpif_int_err;
+ }
+
+ for (i = 0; i subdev_count; i++) {
+ vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(vpif_obj.v4l2_dev,
+ i2c_adap,
+ subdevdata[i].board_info,
+ NULL);
+ if (!vpif_obj.sd[i]) {
+ vpif_err(Error registering v4l2 subdevice\n);
+ goto probe_subdev_out;
+ }
+
+ if (vpif_obj.sd[i])
+ vpif_obj.sd[i]-grp_id = 1 i;
+ }
+
for (j = 0; j VPIF_DISPLAY_MAX_DEVICES; j++) {
ch = vpif_obj.dev[j];
/* Initialize field of the channel objects */
@@ -1713,6 +1739,7 @@ static __init int vpif_probe(struct platform_device *pdev)
This driver needs auditing so that this flag can be removed.
*/
set_bit(V4L2_FL_LOCK_ALL_FOPS, ch-video_dev-flags);
ch-video_dev-lock = common-lock;
+ video_set_drvdata(ch-video_dev, ch);
/* register video device */
vpif_dbg(1, debug, channel=%x,channel-video_dev=%x\n,
@@ -1722,42 +1749,12 @@ static __init int vpif_probe(struct platform_device
*pdev)
VFL_TYPE_GRABBER, (j ? 3 : 2));
if (err 0)
goto probe_out;
-
- video_set_drvdata(ch-video_dev, ch);
- }
-
- i2c_adap = i2c_get_adapter(1);
- config = pdev-dev.platform_data;
- subdev_count = config-subdev_count;
- subdevdata = config-subdevinfo;
- vpif_obj.sd = kzalloc(sizeof(struct v4l2_subdev *) * subdev_count,
- GFP_KERNEL);
- if (vpif_obj.sd == NULL) {
- vpif_err(unable to allocate memory for subdevice pointers\n);
- err = -ENOMEM;
- goto probe_out;
- }
-
- for (i = 0; i subdev_count; i++) {
- vpif_obj.sd[i] = v4l2_i2c_new_subdev_board(vpif_obj.v4l2_dev,
- i2c_adap,
- subdevdata[i].board_info,
- NULL);
- if (!vpif_obj.sd[i]) {
- vpif_err(Error registering v4l2 subdevice\n);
- goto probe_subdev_out;
- }
-
- if (vpif_obj.sd[i])
- vpif_obj.sd[i]-grp_id = 1 i;
}
v4l2_info(vpif_obj.v4l2_dev,
VPIF display driver initialized\n);
return 0;
-probe_subdev_out:
- kfree(vpif_obj.sd);
probe_out:
for (k = 0; k j; k++) {
ch = vpif_obj.dev[k];
@@ -1765,6 +1762,8 @@ probe_out:
video_device_release(ch-video_dev);
ch-video_dev = NULL;
}
+probe_subdev_out:
+ kfree(vpif_obj.sd);
vpif_int_err:
v4l2_device_unregister(vpif_obj.v4l2_dev);
vpif_err(VPIF IRQ request failed\n);
--
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
[RFCv1 PATCH 07/11] vpif_capture: first init subdevs, then register device nodes.
When device nodes are registered they must be ready for use
immediately, so make sure the subdevs are loaded first.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.c | 55
1 file changed, 24 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index f11b9e3..0d67443 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -2122,28 +2122,6 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
}
- for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
- ch = vpif_obj.dev[j];
- ch-channel_id = j;
- common = (ch-common[VPIF_VIDEO_INDEX]);
- spin_lock_init(common-irqlock);
- mutex_init(common-lock);
- /* Locking in file operations other than ioctl should be done
- by the driver, not the V4L2 core.
- This driver needs auditing so that this flag can be removed.
*/
- set_bit(V4L2_FL_LOCK_ALL_FOPS, ch-video_dev-flags);
- ch-video_dev-lock = common-lock;
- /* Initialize prio member of channel object */
- v4l2_prio_init(ch-prio);
- err = video_register_device(ch-video_dev,
- VFL_TYPE_GRABBER, (j ? 1 : 0));
- if (err)
- goto probe_out;
-
- video_set_drvdata(ch-video_dev, ch);
-
- }
-
i2c_adap = i2c_get_adapter(1);
config = pdev-dev.platform_data;
@@ -2153,7 +2131,7 @@ static __init int vpif_probe(struct platform_device *pdev)
if (vpif_obj.sd == NULL) {
vpif_err(unable to allocate memory for subdevice pointers\n);
err = -ENOMEM;
- goto probe_out;
+ goto vpif_dev_alloc_err;
}
for (i = 0; i subdev_count; i++) {
@@ -2170,19 +2148,31 @@ static __init int vpif_probe(struct platform_device
*pdev)
}
v4l2_info(vpif_obj.v4l2_dev, registered sub device %s\n,
subdevdata-name);
-
- if (vpif_obj.sd[i])
- vpif_obj.sd[i]-grp_id = 1 i;
}
+ for (j = 0; j VPIF_CAPTURE_MAX_DEVICES; j++) {
+ ch = vpif_obj.dev[j];
+ ch-channel_id = j;
+ common = (ch-common[VPIF_VIDEO_INDEX]);
+ spin_lock_init(common-irqlock);
+ mutex_init(common-lock);
+ /* Locking in file operations other than ioctl should be done
+ by the driver, not the V4L2 core.
+ This driver needs auditing so that this flag can be removed.
*/
+ set_bit(V4L2_FL_LOCK_ALL_FOPS, ch-video_dev-flags);
+ ch-video_dev-lock = common-lock;
+ /* Initialize prio member of channel object */
+ v4l2_prio_init(ch-prio);
+ video_set_drvdata(ch-video_dev, ch);
+
+ err = video_register_device(ch-video_dev,
+ VFL_TYPE_GRABBER, (j ? 1 : 0));
+ if (err)
+ goto probe_out;
+ }
v4l2_info(vpif_obj.v4l2_dev, VPIF capture driver initialized\n);
return 0;
-probe_subdev_out:
- /* free sub devices memory */
- kfree(vpif_obj.sd);
-
- j = VPIF_CAPTURE_MAX_DEVICES;
probe_out:
for (k = 0; k j; k++) {
/* Get the pointer to the channel object */
@@ -2190,6 +2180,9 @@ probe_out:
/* Unregister video device */
video_unregister_device(ch-video_dev);
}
+probe_subdev_out:
+ /* free sub devices memory */
+ kfree(vpif_obj.sd);
vpif_dev_alloc_err:
k = VPIF_CAPTURE_MAX_DEVICES-1;
--
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
[RFCv1 PATCH 06/11] vpif_capture: move routing info from subdev to input.
Routing information is a property of the input, not of the subdev.
One subdev may provide multiple inputs, each with its own routing
information.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
arch/arm/mach-davinci/board-da850-evm.c|8
arch/arm/mach-davinci/board-dm646x-evm.c |8
drivers/media/video/davinci/vpif_capture.c |7 +--
include/media/davinci/vpif_types.h |4 ++--
4 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/arch/arm/mach-davinci/board-da850-evm.c
b/arch/arm/mach-davinci/board-da850-evm.c
index d92e0ab..514d4d4 100644
--- a/arch/arm/mach-davinci/board-da850-evm.c
+++ b/arch/arm/mach-davinci/board-da850-evm.c
@@ -1184,6 +1184,8 @@ static const struct vpif_input da850_ch0_inputs[] = {
.type = V4L2_INPUT_TYPE_CAMERA,
.std = TVP514X_STD_ALL,
},
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH0,
},
};
@@ -1196,6 +1198,8 @@ static const struct vpif_input da850_ch1_inputs[] = {
.type = V4L2_INPUT_TYPE_CAMERA,
.std = TVP514X_STD_ALL,
},
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.subdev_name = TVP5147_CH1,
},
};
@@ -1207,8 +1211,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_CVBS_VI2B,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -1222,8 +1224,6 @@ static struct vpif_subdev_info
da850_vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_SVIDEO_VI2C_VI1C,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
diff --git a/arch/arm/mach-davinci/board-dm646x-evm.c
b/arch/arm/mach-davinci/board-dm646x-evm.c
index a0be63b..0daec7e 100644
--- a/arch/arm/mach-davinci/board-dm646x-evm.c
+++ b/arch/arm/mach-davinci/board-dm646x-evm.c
@@ -601,8 +601,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5d),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_CVBS_VI2B,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -616,8 +614,6 @@ static struct vpif_subdev_info vpif_capture_sdev_info[] = {
I2C_BOARD_INFO(tvp5146, 0x5c),
.platform_data = tvp5146_pdata,
},
- .input = INPUT_SVIDEO_VI2C_VI1C,
- .output = OUTPUT_10BIT_422_EMBEDDED_SYNC,
.vpif_if = {
.if_type = VPIF_IF_BT656,
.hd_pol = 1,
@@ -636,6 +632,8 @@ static const struct vpif_input dm6467_ch0_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH0,
+ .input_route = INPUT_CVBS_VI2B,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
};
@@ -648,6 +646,8 @@ static const struct vpif_input dm6467_ch1_inputs[] = {
.std = TVP514X_STD_ALL,
},
.subdev_name = TVP5147_CH1,
+ .input_route = INPUT_SVIDEO_VI2C_VI1C,
+ .output_route = OUTPUT_10BIT_422_EMBEDDED_SYNC,
},
};
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index ae5cabf..f11b9e3 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -1449,6 +1449,9 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
chan_cfg = config-chan_config[ch-channel_id];
+ if (index = chan_cfg-input_count)
+ return -EINVAL;
+
if (common-started) {
vpif_err(Streaming in progress\n);
return -EBUSY;
@@ -1487,8 +1490,8 @@ static int vpif_s_input(struct file *file, void *priv,
unsigned int index)
}
}
- input = subdev_info-input;
- output = subdev_info-output;
+ input = chan_cfg-inputs[index].input_route;
+ output = chan_cfg-inputs[index].output_route;
ret = v4l2_subdev_call(vpif_obj.sd[sd_index], video,
[RFCv1 PATCH 04/11] vpif_display: move output_id to channel_obj.
The output index does not belong to video_obj, it belongs to
channel_obj. Also rename to output_idx to be consistent with
the input_idx name used in vpif_capture.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_display.c | 17 ++---
drivers/media/video/davinci/vpif_display.h |2 +-
2 files changed, 7 insertions(+), 12 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_display.c
b/drivers/media/video/davinci/vpif_display.c
index 371a459..19338b4 100644
--- a/drivers/media/video/davinci/vpif_display.c
+++ b/drivers/media/video/davinci/vpif_display.c
@@ -1217,7 +1217,6 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
struct common_obj *common = ch-common[VPIF_VIDEO_INDEX];
int ret = 0;
@@ -1232,7 +1231,7 @@ static int vpif_s_output(struct file *file, void *priv,
unsigned int i)
if (ret 0)
vpif_err(Failed to set output standard\n);
- vid_ch-output_id = i;
+ ch-output_idx = i;
return ret;
}
@@ -1240,9 +1239,8 @@ static int vpif_g_output(struct file *file, void *priv,
unsigned int *i)
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- *i = vid_ch-output_id;
+ *i = ch-output_idx;
return 0;
}
@@ -1276,9 +1274,8 @@ static int vpif_enum_dv_timings(struct file *file, void
*priv,
{
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id],
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
video, enum_dv_timings, timings);
}
@@ -1305,7 +1302,7 @@ static int vpif_s_dv_timings(struct file *file, void
*priv,
}
/* Configure subdevice timings, if any */
- ret = v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id],
+ ret = v4l2_subdev_call(vpif_obj.sd[ch-output_idx],
video, s_dv_timings, timings);
if (ret == -ENOIOCTLCMD) {
vpif_dbg(2, debug, Custom DV timings not supported by
@@ -1436,9 +1433,8 @@ static int vpif_dbg_g_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id], core,
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
g_register, reg);
}
@@ -1455,9 +1451,8 @@ static int vpif_dbg_s_register(struct file *file, void
*priv,
struct v4l2_dbg_register *reg){
struct vpif_fh *fh = priv;
struct channel_obj *ch = fh-channel;
- struct video_obj *vid_ch = ch-video;
- return v4l2_subdev_call(vpif_obj.sd[vid_ch-output_id], core,
+ return v4l2_subdev_call(vpif_obj.sd[ch-output_idx], core,
s_register, reg);
}
#endif
diff --git a/drivers/media/video/davinci/vpif_display.h
b/drivers/media/video/davinci/vpif_display.h
index ad22c70..b602def 100644
--- a/drivers/media/video/davinci/vpif_display.h
+++ b/drivers/media/video/davinci/vpif_display.h
@@ -63,7 +63,6 @@ struct video_obj {
v4l2_std_id stdid; /* Currently selected or default
* standard */
struct v4l2_dv_timings dv_timings;
- u32 output_id; /* Current output id */
};
struct vpif_disp_buffer {
@@ -126,6 +125,7 @@ struct channel_obj {
* which is being displayed */
u8 initialized; /* flag to indicate whether
* encoder is initialized */
+ u32 output_idx; /* Current output index */
enum vpif_channel_id channel_id;/* Identifies channel */
struct vpif_params vpifparams;
--
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
[RFCv1 PATCH 01/11] vpif_capture: remove unused data structure.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.h |6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.h
b/drivers/media/video/davinci/vpif_capture.h
index aa6d3da..de19c80 100644
--- a/drivers/media/video/davinci/vpif_capture.h
+++ b/drivers/media/video/davinci/vpif_capture.h
@@ -160,10 +160,6 @@ struct vpif_config_params {
u32 video_limit[VPIF_CAPTURE_NUM_CHANNELS];
u8 max_device_type;
};
-/* Struct which keeps track of the line numbers for the sliced vbi service */
-struct vpif_service_line {
- u16 service_id;
- u16 service_line[2];
-};
+
#endif /* End of __KERNEL__ */
#endif /* VPIF_CAPTURE_H */
--
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
[RFCv1 PATCH 09/11] vpif_capture: separate subdev from input.
vpif_capture relied on a 1-1 mapping of input and subdev. This is not
necessarily the case. Separate the two. So there is a list of subdevs
and a list of inputs. Each input refers to a subdev and has routing
information. An input does not have to have a subdev.
The initial input for each channel is set to the fist input.
Currently missing is support for associating multiple subdevs with
an input.
Signed-off-by: Hans Verkuil hans.verk...@cisco.com
---
drivers/media/video/davinci/vpif_capture.c | 239 +---
drivers/media/video/davinci/vpif_capture.h |6 +-
2 files changed, 113 insertions(+), 132 deletions(-)
diff --git a/drivers/media/video/davinci/vpif_capture.c
b/drivers/media/video/davinci/vpif_capture.c
index 0d67443..5266167 100644
--- a/drivers/media/video/davinci/vpif_capture.c
+++ b/drivers/media/video/davinci/vpif_capture.c
@@ -856,13 +856,11 @@ static unsigned int vpif_poll(struct file *filep,
poll_table * wait)
*/
static int vpif_open(struct file *filep)
{
- struct vpif_capture_config *config = vpif_dev-platform_data;
struct video_device *vdev = video_devdata(filep);
struct common_obj *common;
struct video_obj *vid_ch;
struct channel_obj *ch;
struct vpif_fh *fh;
- int i;
vpif_dbg(2, debug, vpif_open\n);
@@ -871,24 +869,6 @@ static int vpif_open(struct file *filep)
vid_ch = ch-video;
common = ch-common[VPIF_VIDEO_INDEX];
- if (NULL == ch-curr_subdev_info) {
- /**
-* search through the sub device to see a registered
-* sub device and make it as current sub device
-*/
- for (i = 0; i config-subdev_count; i++) {
- if (vpif_obj.sd[i]) {
- /* the sub device is registered */
- ch-curr_subdev_info = config-subdev_info[i];
- break;
- }
- }
- if (i == config-subdev_count) {
- vpif_err(No sub device registered\n);
- return -ENOENT;
- }
- }
-
/* Allocate memory for the file handle object */
fh = kzalloc(sizeof(struct vpif_fh), GFP_KERNEL);
if (NULL == fh) {
@@ -1159,10 +1139,9 @@ static int vpif_streamon(struct file *file, void *priv,
return ret;
/* Enable streamon on the sub device */
- ret = v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], video,
- s_stream, 1);
+ ret = v4l2_subdev_call(ch-sd, video, s_stream, 1);
- if (ret (ret != -ENOIOCTLCMD)) {
+ if (ret ret != -ENOIOCTLCMD ret != -ENODEV) {
vpif_dbg(1, debug, stream on failed in subdev\n);
return ret;
}
@@ -1222,73 +1201,105 @@ static int vpif_streamoff(struct file *file, void
*priv,
common-started = 0;
- ret = v4l2_subdev_call(vpif_obj.sd[ch-curr_sd_index], video,
- s_stream, 0);
+ ret = v4l2_subdev_call(ch-sd, video, s_stream, 0);
- if (ret (ret != -ENOIOCTLCMD))
+ if (ret ret != -ENOIOCTLCMD ret != -ENODEV)
vpif_dbg(1, debug, stream off failed in subdev\n);
return vb2_streamoff(common-buffer_queue, buftype);
}
/**
- * vpif_map_sub_device_to_input() - Maps sub device to input
- * @ch - ptr to channel
- * @config - ptr to capture configuration
+ * vpif_input_to_subdev() - Maps input to sub device
+ * @vpif_cfg - global config ptr
+ * @chan_cfg - channel config ptr
* @input_index - Given input index from application
- * @sub_device_index - index into sd table
*
* lookup the sub device information for a given input index.
* we report all the inputs to application. inputs table also
* has sub device name for the each input
*/
-static struct vpif_subdev_info *vpif_map_sub_device_to_input(
- struct channel_obj *ch,
- struct vpif_capture_config *vpif_cfg,
- int input_index,
- int *sub_device_index)
+static int vpif_input_to_subdev(
+ struct vpif_capture_config *vpif_cfg,
+ struct vpif_capture_chan_config *chan_cfg,
+ int input_index)
{
- struct vpif_capture_chan_config *chan_cfg;
- struct vpif_subdev_info *subdev_info = NULL;
- const char *subdev_name = NULL;
+ struct vpif_subdev_info *subdev_info;
+ const char *subdev_name;
int i;
- vpif_dbg(2, debug, vpif_map_sub_device_to_input\n);
-
- chan_cfg = vpif_cfg-chan_config[ch-channel_id];
+ vpif_dbg(2, debug, vpif_input_to_subdev\n);
- /**
-* search through the inputs to find the sub device supporting
-* the input
-*/
- for (i = 0; i chan_cfg-input_count; i++) {
-
Re: [RFCv1 PATCH 00/11] davinci: clean up input/output/subdev config
On Tue 18 September 2012 12:53:02 Hans Verkuil wrote: Hi Prabhakar, This patch series does some driver cleanup and reorganizes the config structs that are used to set up subdevices. The current driver associates an input or output with a subdev, but multiple inputs may use the same subdev and some inputs may not use a subdev at all (this is the case for our hardware). Several other things were also configured in the wrong structure. For example the vpif_interface struct is really part of the channel config and has nothing to do with the subdev. What is missing here is that the output doesn't have the same flexibility as the input when it comes to configuration. It would be good if someone can pick this up as a follow-up since it's unlikely I'll be working on that. What would also be nice is that by leaving the inputs or outputs for the second channel empty (NULL) in the configuration you can disable the second video node, e.g. trying to use it will always result in ENODEV or something. This patch series will at least make things more flexible. I forgot to mention that this patch series is on top of this git tree: http://git.linuxtv.org/mhadli/v4l-dvb-davinci_devices.git/shortlog/refs/heads/pull_vpif Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCHv3 0/6] media: convert to c99 format
The series tries to convert the i2c_msg to c99 struct. This may avoid issues like below if someone tries to add an element to the structure. http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg08972.html Special thanks to Julia Lawall for helping it automate. By the below script. http://www.mail-archive.com/cocci@diku.dk/msg02753.html Changelogs - Remove the zero inititialisation of the flags. Shubhrajyoti D (6): media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format drivers/media/i2c/ks0127.c| 13 +++- drivers/media/i2c/msp3400-driver.c| 40 + drivers/media/i2c/tvaudio.c | 13 +++- drivers/media/radio/radio-tea5764.c | 13 ++-- drivers/media/radio/saa7706h.c| 15 - drivers/media/radio/si470x/radio-si470x-i2c.c | 23 ++ 6 files changed, 96 insertions(+), 21 deletions(-) -- 1.7.5.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
[PATCHv3 5/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/saa7706h.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
index bb953ef..54db36c 100644
--- a/drivers/media/radio/saa7706h.c
+++ b/drivers/media/radio/saa7706h.c
@@ -199,8 +199,19 @@ static int saa7706h_get_reg16(struct v4l2_subdev *sd, u16
reg)
u8 buf[2];
int err;
u8 regaddr[] = {reg 8, reg};
- struct i2c_msg msg[] = { {client-addr, 0, sizeof(regaddr), regaddr},
- {client-addr, I2C_M_RD, sizeof(buf), buf} };
+ struct i2c_msg msg[] = {
+ {
+ .addr = client-addr,
+ .len = sizeof(regaddr),
+ .buf = regaddr
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf
+ }
+ };
err = saa7706h_i2c_transfer(client, msg, ARRAY_SIZE(msg));
if (err)
--
1.7.5.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
[PATCHv3 4/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/msp3400-driver.c | 40 ++-
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/msp3400-driver.c
b/drivers/media/i2c/msp3400-driver.c
index aeb22be..766305f 100644
--- a/drivers/media/i2c/msp3400-driver.c
+++ b/drivers/media/i2c/msp3400-driver.c
@@ -119,12 +119,31 @@ int msp_reset(struct i2c_client *client)
static u8 write[3] = { I2C_MSP_DSP + 1, 0x00, 0x1e };
u8 read[2];
struct i2c_msg reset[2] = {
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_off },
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_on },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_off
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_on
+ },
};
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ },
};
v4l_dbg(3, msp_debug, client, msp_reset\n);
@@ -143,8 +162,17 @@ static int msp_read(struct i2c_client *client, int dev,
int addr)
u8 write[3];
u8 read[2];
struct i2c_msg msgs[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read }
+ {
+ .addr = client-addr,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ }
};
write[0] = dev + 1;
--
1.7.5.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
[PATCHv3 6/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index f867f04..e5024cf 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -98,8 +98,12 @@ int si470x_get_register(struct si470x_device *radio, int
regnr)
{
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
@@ -119,8 +123,11 @@ int si470x_set_register(struct si470x_device *radio, int
regnr)
int i;
u16 buf[WRITE_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, 0, sizeof(u16) * WRITE_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .len = sizeof(u16) * WRITE_REG_NUM,
+ .buf = (void *)buf
+ },
};
for (i = 0; i WRITE_REG_NUM; i++)
@@ -146,8 +153,12 @@ static int si470x_get_all_registers(struct si470x_device
*radio)
int i;
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
--
1.7.5.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
[PATCHv3 2/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/tvaudio.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index 321b315..f74a3f9 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -217,8 +217,17 @@ static int chip_read2(struct CHIPSTATE *chip, int subaddr)
unsigned char write[1];
unsigned char read[1];
struct i2c_msg msgs[2] = {
- { c-addr, 0,1, write },
- { c-addr, I2C_M_RD, 1, read }
+ {
+ .addr = c-addr,
+ .len = 1,
+ .buf = write
+ },
+ {
+ .addr = c-addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = read
+ }
};
write[0] = subaddr;
--
1.7.5.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
[PATCHv3 1/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/ks0127.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ee7ca2d..04a6efa 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -319,8 +319,17 @@ static u8 ks0127_read(struct v4l2_subdev *sd, u8 reg)
struct i2c_client *client = v4l2_get_subdevdata(sd);
char val = 0;
struct i2c_msg msgs[] = {
- { client-addr, 0, sizeof(reg), reg },
- { client-addr, I2C_M_RD | I2C_M_NO_RD_ACK, sizeof(val), val }
+ {
+ .addr = client-addr,
+ .len = sizeof(reg),
+ .buf = reg
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD | I2C_M_NO_RD_ACK,
+ .len = sizeof(val),
+ .buf = val
+ }
};
int ret;
--
1.7.5.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: [PATCHv3 5/6] media: Convert struct i2c_msg initialization to C99 format
On Tue, Sep 18, 2012 at 05:14:31PM +0530, Shubhrajyoti D wrote:
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
no need for these tabs here.
FWIW:
Reviewed-by: Felipe Balbi ba...@ti.com
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/saa7706h.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
index bb953ef..54db36c 100644
--- a/drivers/media/radio/saa7706h.c
+++ b/drivers/media/radio/saa7706h.c
@@ -199,8 +199,19 @@ static int saa7706h_get_reg16(struct v4l2_subdev *sd,
u16 reg)
u8 buf[2];
int err;
u8 regaddr[] = {reg 8, reg};
- struct i2c_msg msg[] = { {client-addr, 0, sizeof(regaddr), regaddr},
- {client-addr, I2C_M_RD, sizeof(buf), buf} };
+ struct i2c_msg msg[] = {
+ {
+ .addr = client-addr,
+ .len = sizeof(regaddr),
+ .buf = regaddr
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf
+ }
+ };
err = saa7706h_i2c_transfer(client, msg, ARRAY_SIZE(msg));
if (err)
--
1.7.5.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
balbi
signature.asc
Description: Digital signature
[GIT PULL FOR v3.7] Davinci VPIF cleanup and feature enhancement
Hi Mauro, Can you please pull the following patches for vpif, Which involves driver cleanup and replace preset by timings API. Thanks and Regards, --Prabhakar Lad The following changes since commit 36aee5ff9098a871bda38dbbdad40ad59f6535cf: [media] ir-rx51: Adjust dependencies (2012-09-15 19:44:30 -0300) are available in the git repository at: git://linuxtv.org/mhadli/v4l-dvb-davinci_devices.git vpif_driver_cleanup Dror Cohen (1): media/video: vpif: fixing function name start to vpif_config_params Hans Verkuil (2): vpif: replace preset with the timings API. davinci: vpif: remove unwanted header file inclusion Lad, Prabhakar (2): media: davinci: vpif: add check for NULL handler davinci: vpif: capture/display: fix race condition drivers/media/platform/davinci/vpif.c | 22 +++-- drivers/media/platform/davinci/vpif.h |4 +- drivers/media/platform/davinci/vpif_capture.c | 133 ++--- drivers/media/platform/davinci/vpif_capture.h |6 +- drivers/media/platform/davinci/vpif_display.c | 121 -- drivers/media/platform/davinci/vpif_display.h |6 +- 6 files changed, 69 insertions(+), 223 deletions(-) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 5/6] media: Convert struct i2c_msg initialization to C99 format
On Tuesday 18 September 2012 05:12 PM, Felipe Balbi wrote: On Tue, Sep 18, 2012 at 05:14:31PM +0530, Shubhrajyoti D wrote: Convert the struct i2c_msg initialization to C99 format. This makes maintaining and editing the code simpler. Also helps once other fields like transferred are added in future. no need for these tabs here. yep will fix and repost thanks. FWIW: Reviewed-by: Felipe Balbi ba...@ti.com thanks for the review -- 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
[PATCHv4 2/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/tvaudio.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/tvaudio.c b/drivers/media/i2c/tvaudio.c
index 321b315..f74a3f9 100644
--- a/drivers/media/i2c/tvaudio.c
+++ b/drivers/media/i2c/tvaudio.c
@@ -217,8 +217,17 @@ static int chip_read2(struct CHIPSTATE *chip, int subaddr)
unsigned char write[1];
unsigned char read[1];
struct i2c_msg msgs[2] = {
- { c-addr, 0,1, write },
- { c-addr, I2C_M_RD, 1, read }
+ {
+ .addr = c-addr,
+ .len = 1,
+ .buf = write
+ },
+ {
+ .addr = c-addr,
+ .flags = I2C_M_RD,
+ .len = 1,
+ .buf = read
+ }
};
write[0] = subaddr;
--
1.7.5.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
[PATCHv4 5/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/saa7706h.c | 15 +--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/media/radio/saa7706h.c b/drivers/media/radio/saa7706h.c
index bb953ef..54db36c 100644
--- a/drivers/media/radio/saa7706h.c
+++ b/drivers/media/radio/saa7706h.c
@@ -199,8 +199,19 @@ static int saa7706h_get_reg16(struct v4l2_subdev *sd, u16
reg)
u8 buf[2];
int err;
u8 regaddr[] = {reg 8, reg};
- struct i2c_msg msg[] = { {client-addr, 0, sizeof(regaddr), regaddr},
- {client-addr, I2C_M_RD, sizeof(buf), buf} };
+ struct i2c_msg msg[] = {
+ {
+ .addr = client-addr,
+ .len = sizeof(regaddr),
+ .buf = regaddr
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf
+ }
+ };
err = saa7706h_i2c_transfer(client, msg, ARRAY_SIZE(msg));
if (err)
--
1.7.5.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
[PATCHv4 3/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/radio-tea5764.c | 13 ++---
1 files changed, 10 insertions(+), 3 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 6b1fae3..52a34b1 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -151,8 +151,11 @@ int tea5764_i2c_read(struct tea5764_device *radio)
u16 *p = (u16 *) radio-regs;
struct i2c_msg msgs[1] = {
- { radio-i2c_client-addr, I2C_M_RD, sizeof(radio-regs),
- (void *)radio-regs },
+ { .addr = radio-i2c_client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(radio-regs),
+ .buf = (void *)radio-regs
+ },
};
if (i2c_transfer(radio-i2c_client-adapter, msgs, 1) != 1)
return -EIO;
@@ -167,7 +170,11 @@ int tea5764_i2c_write(struct tea5764_device *radio)
struct tea5764_write_regs wr;
struct tea5764_regs *r = radio-regs;
struct i2c_msg msgs[1] = {
- { radio-i2c_client-addr, 0, sizeof(wr), (void *) wr },
+ {
+ .addr = radio-i2c_client-addr,
+ .len = sizeof(wr),
+ .buf = (void *)wr
+ },
};
wr.intreg = r-intreg 0xff;
wr.frqset = __cpu_to_be16(r-frqset);
--
1.7.5.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
[PATCHv4 1/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/ks0127.c | 13 +++--
1 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/drivers/media/i2c/ks0127.c b/drivers/media/i2c/ks0127.c
index ee7ca2d..04a6efa 100644
--- a/drivers/media/i2c/ks0127.c
+++ b/drivers/media/i2c/ks0127.c
@@ -319,8 +319,17 @@ static u8 ks0127_read(struct v4l2_subdev *sd, u8 reg)
struct i2c_client *client = v4l2_get_subdevdata(sd);
char val = 0;
struct i2c_msg msgs[] = {
- { client-addr, 0, sizeof(reg), reg },
- { client-addr, I2C_M_RD | I2C_M_NO_RD_ACK, sizeof(val), val }
+ {
+ .addr = client-addr,
+ .len = sizeof(reg),
+ .buf = reg
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD | I2C_M_NO_RD_ACK,
+ .len = sizeof(val),
+ .buf = val
+ }
};
int ret;
--
1.7.5.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
[PATCHv4 0/6] media: convert to c99 format
The series tries to convert the i2c_msg to c99 struct. This may avoid issues like below if someone tries to add an element to the structure. http://www.mail-archive.com/linux-i2c@vger.kernel.org/msg08972.html Special thanks to Julia Lawall for helping it automate. By the below script. http://www.mail-archive.com/cocci@diku.dk/msg02753.html Changelogs - Remove the zero inititialisation of the flags. Shubhrajyoti D (6): media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format media: Convert struct i2c_msg initialization to C99 format drivers/media/i2c/ks0127.c| 13 +++- drivers/media/i2c/msp3400-driver.c| 40 + drivers/media/i2c/tvaudio.c | 13 +++- drivers/media/radio/radio-tea5764.c | 13 ++-- drivers/media/radio/saa7706h.c| 15 - drivers/media/radio/si470x/radio-si470x-i2c.c | 23 ++ 6 files changed, 96 insertions(+), 21 deletions(-) -- 1.7.5.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
[PATCHv4 6/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/radio/si470x/radio-si470x-i2c.c | 23 +--
1 files changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c
b/drivers/media/radio/si470x/radio-si470x-i2c.c
index f867f04..e5024cf 100644
--- a/drivers/media/radio/si470x/radio-si470x-i2c.c
+++ b/drivers/media/radio/si470x/radio-si470x-i2c.c
@@ -98,8 +98,12 @@ int si470x_get_register(struct si470x_device *radio, int
regnr)
{
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
@@ -119,8 +123,11 @@ int si470x_set_register(struct si470x_device *radio, int
regnr)
int i;
u16 buf[WRITE_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, 0, sizeof(u16) * WRITE_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .len = sizeof(u16) * WRITE_REG_NUM,
+ .buf = (void *)buf
+ },
};
for (i = 0; i WRITE_REG_NUM; i++)
@@ -146,8 +153,12 @@ static int si470x_get_all_registers(struct si470x_device
*radio)
int i;
u16 buf[READ_REG_NUM];
struct i2c_msg msgs[1] = {
- { radio-client-addr, I2C_M_RD, sizeof(u16) * READ_REG_NUM,
- (void *)buf },
+ {
+ .addr = radio-client-addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(u16) * READ_REG_NUM,
+ .buf = (void *)buf
+ },
};
if (i2c_transfer(radio-client-adapter, msgs, 1) != 1)
--
1.7.5.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
[PATCHv4 4/6] media: Convert struct i2c_msg initialization to C99 format
Convert the struct i2c_msg initialization to C99 format. This makes
maintaining and editing the code simpler. Also helps once other fields
like transferred are added in future.
Signed-off-by: Shubhrajyoti D shubhrajy...@ti.com
---
drivers/media/i2c/msp3400-driver.c | 40 ++-
1 files changed, 34 insertions(+), 6 deletions(-)
diff --git a/drivers/media/i2c/msp3400-driver.c
b/drivers/media/i2c/msp3400-driver.c
index aeb22be..766305f 100644
--- a/drivers/media/i2c/msp3400-driver.c
+++ b/drivers/media/i2c/msp3400-driver.c
@@ -119,12 +119,31 @@ int msp_reset(struct i2c_client *client)
static u8 write[3] = { I2C_MSP_DSP + 1, 0x00, 0x1e };
u8 read[2];
struct i2c_msg reset[2] = {
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_off },
- { client-addr, I2C_M_IGNORE_NAK, 3, reset_on },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_off
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_IGNORE_NAK,
+ .len = 3,
+ .buf = reset_on
+ },
};
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ },
};
v4l_dbg(3, msp_debug, client, msp_reset\n);
@@ -143,8 +162,17 @@ static int msp_read(struct i2c_client *client, int dev,
int addr)
u8 write[3];
u8 read[2];
struct i2c_msg msgs[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read }
+ {
+ .addr = client-addr,
+ .len = 3,
+ .buf = write
+ },
+ {
+ .addr = client-addr,
+ .flags = I2C_M_RD,
+ .len = 2,
+ .buf = read
+ }
};
write[0] = dev + 1;
--
1.7.5.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 v4] media: v4l2-ctrls: add control for dpcm predictor
Hi Sakari, On Thu, Sep 13, 2012 at 6:29 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sakari, On Friday 07 September 2012 21:46:44 Sakari Ailus wrote: Could you replace the above with this text (with appropriate indentation etc.) while keeping the reference to Wikipedia? --8-- Differential pulse-code modulation (DPCM) compression can be used to compress the samples into fewer bits than they would otherwise require. This is done by calculating the difference between consecutive samples and outputting the difference which in average is much smaller than the values of the samples themselves since there is generally lots of correlation between adjacent pixels. In decompression the original samples are reconstructed. The process isn't lossless as the encoded sample size in bits is less than the original. Formats using DPCM compression include xref linkend=pixfmt-srggb10dpcm8 /. This control is used to select the predictor used to encode the samples. If I remember correctly this control will be used on the receiver side on DaVinci, to decode pixels not encode them. How is the predictor used in that case ? Must it match the predictor used on the encoding side ? If so I expect documentation to be available somewhere. The OMAP3 ISP supports both DPCM encoding and decoding, and documents the predictors as - The simple predictor This predictor uses only the previous same color component value as a prediction value. Therefore, only two-pixel memory is required. - The advanced predictor This predictor uses four previous pixel values, when the prediction value is evaluated. This means that also the other color component values are used, when the prediction value has been defined. It also states the the simple predictor is preferred for 10-8-10 conversion, and the advanced predictor for 10-7-10 and 10-6-10 conversion. What do you suggest ? Regards, --Prabhakar Lad The main difference between the simple and the advanced predictors is image quality, with advanced predictor supposed to produce better quality images as a result. Simple predictor can be used e.g. for testing purposes. --8-- -- Regards, Laurent Pinchart ___ Davinci-linux-open-source mailing list davinci-linux-open-sou...@linux.davincidsp.com http://linux.davincidsp.com/mailman/listinfo/davinci-linux-open-source -- 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] rtl28xxu: add ID [0bda:2832] Realtek RTL2832U reference design
Also change location of other RTL2832 reference design ID 0bda:2838.
I just like to see reference design IDs at the first IDs in the list.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 843eeaf..70c2df1 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1328,14 +1328,16 @@ static const struct usb_device_id rtl28xxu_id_table[] =
{
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT_2,
rtl2831u_props, Freecom USB2.0 DVB-T, NULL) },
+ { DVB_USB_DEVICE(USB_VID_REALTEK, 0x2832,
+ rtl2832u_props, Realtek RTL2832U reference design, NULL) },
+ { DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
+ rtl2832u_props, Realtek RTL2832U reference design, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC,
USB_PID_TERRATEC_CINERGY_T_STICK_BLACK_REV1,
rtl2832u_props, Terratec Cinergy T Stick Black, NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_DELOCK_USB2_DVBT,
rtl2832u_props, G-Tek Electronics Group Lifeview LV5TDLX
DVB-T, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK,
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
- { DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
- rtl2832u_props, Realtek RTL2832U reference design, NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_TREKSTOR_TERRES_2_0,
rtl2832u_props, Trekstor DVB-T Stick Terres 2.0, NULL) },
{ DVB_USB_DEVICE(USB_VID_DEXATEK, 0x1101,
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] Processing context in the V4L2 subdev and V4L2 controls API ?
Hi All, I'm trying to fulfil following requirements with V4L2 API that are specific to most of Samsung camera sensors with embedded SoC ISP and also for local SoC camera ISPs: - separate pixel format and pixel resolution needs to be configured in a device for camera preview and capture; - there is a need to set capture or preview mode in a device explicitly as it makes various adjustments (in firmware) in each operation mode and controls external devices accordingly (e.g. camera Flash); - some devices have more than two use case specific contexts that a user needs to choose from, e.g. video preview, video capture, still preview, still capture; for each of these modes there are separate settings, especially pixel resolution and others corresponding to existing v4l2 controls; - some devices can have two processing contexts enabled simultaneously, e.g. a sensor emitting YUYV and JPEG streams simultaneously (please see discussion [1]). This makes me considering making the v4l2 subdev (and maybe v4l2 controls) API processing (capture) context aware. If I remember correctly introducing processing context, as the per file handle device contexts in case of mem-to-mem devices was considered bad idea in past discussions. But this was more about v4ll2 video nodes. And I was considering adding context only to v4l2 subdev API, and possibly to the (extended) control API. The idea is to extend the subdev (and controls ?) ioctls so it is possible to preconfigure sets of parameters on subdevs, while V4L2 video node parameters would be switched manually by applications to match a selected subdevs contest. There would also be needed an API to select specific context (e.g. a control), or maybe multiple contexts like in case of a sensor from discussion [1]. I've seen various hacks in some v4l2 drivers trying to fulfil above requirements, e.g. abusing struct v4l2_mbus_framefmt::colorspace field to select between capture/preview in a device or using 32-bit integer control where upper 16-bits are used for pixel width and lower 16 for pixel height. This may suggest there something missing at the API. Any suggestions, critics, please ?... :) -- Regards, Sylwester [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg42707.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] Processing context in the V4L2 subdev and V4L2 controls API ?
Hi Sylwester On Tue, 18 Sep 2012, Sylwester Nawrocki wrote: Hi All, I'm trying to fulfil following requirements with V4L2 API that are specific to most of Samsung camera sensors with embedded SoC ISP and also for local SoC camera ISPs: - separate pixel format and pixel resolution needs to be configured in a device for camera preview and capture; Nice to see this topic come to light again:-) You certainly remember this short discussion http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/40126 and preceding threads, where various related ideas have been discussed, I think, we already discussed this back in Warsaw and before that on the ML. So, I hope, this time we have a valid use-case for these contexts and they finally can be brought to an upstreamable implementation:-) Good luck! Guennadi - there is a need to set capture or preview mode in a device explicitly as it makes various adjustments (in firmware) in each operation mode and controls external devices accordingly (e.g. camera Flash); - some devices have more than two use case specific contexts that a user needs to choose from, e.g. video preview, video capture, still preview, still capture; for each of these modes there are separate settings, especially pixel resolution and others corresponding to existing v4l2 controls; - some devices can have two processing contexts enabled simultaneously, e.g. a sensor emitting YUYV and JPEG streams simultaneously (please see discussion [1]). This makes me considering making the v4l2 subdev (and maybe v4l2 controls) API processing (capture) context aware. If I remember correctly introducing processing context, as the per file handle device contexts in case of mem-to-mem devices was considered bad idea in past discussions. But this was more about v4ll2 video nodes. And I was considering adding context only to v4l2 subdev API, and possibly to the (extended) control API. The idea is to extend the subdev (and controls ?) ioctls so it is possible to preconfigure sets of parameters on subdevs, while V4L2 video node parameters would be switched manually by applications to match a selected subdevs contest. There would also be needed an API to select specific context (e.g. a control), or maybe multiple contexts like in case of a sensor from discussion [1]. I've seen various hacks in some v4l2 drivers trying to fulfil above requirements, e.g. abusing struct v4l2_mbus_framefmt::colorspace field to select between capture/preview in a device or using 32-bit integer control where upper 16-bits are used for pixel width and lower 16 for pixel height. This may suggest there something missing at the API. Any suggestions, critics, please ?... :) -- Regards, Sylwester [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg42707.html --- 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: [PATCH] [media] mceusb: Optimize DIV_ROUND_CLOSEST call
Em 01-09-2012 15:53, Jean Delvare escreveu: DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c 2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; Hmm... this generates the following warning with W=1: drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] Perhaps it makes sense to use an optimized version for unsigned, or to change the macro to take the data types into account. 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] Mygica X8507 audio for YPbPr, AV and S-Video
Em 03-09-2012 17:14, Alfredo Jesús Delaiti escreveu:
Hi
This patch add audio support for input YPbPr, AV and S-Video for Mygica X8507
card.
I tried it with the 3.4 and 3.5 kernel
Remains to be done: IR, FM and ISDBT
Sorry if I sent the patch improperly.
Signed-off-by: Alfredo J. Delaiti alfredodela...@netscape.net
diff --git a/media/video/cx23885/cx23885-cards.c
b/media/video/cx23885/cx23885-cards.c
index 080e111..17e2576 100644
--- a/media/video/cx23885/cx23885-cards.c
+++ b/media/video/cx23885/cx23885-cards.c
Wrong format... the drivers/ is missing.
Well, the location also changed to drivers/media/pci, but my scripts can
fix it.
@@ -541,11 +541,13 @@ struct cx23885_board cx23885_boards[] = {
{
.type = CX23885_VMUX_COMPOSITE1,
.vmux = CX25840_COMPOSITE8,
+ .amux = CX25840_AUDIO7,
Didn't apply well. It seems it conflicted with some other patch.
Please, re-generate it against the very latest tree.
Also, when doing diffs for the boards entries, it is wise to have
more context lines, in order that a patch made for one driver would
be badly applied at some other board entry.
The easiest way to do that is to do:
$ git diff -U10
or
$ git show -U10
(if you've merged the patch at your local copy)
(if you're generating the patch against the main media-tree.git)
Where 10 is just an arbitrary large number that will allow to
see the board name that will be modified, like:
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -531,20 +531,21 @@ struct cx23885_board cx23885_boards[] = {
.name = Mygica X8507,
.tuner_type = TUNER_XC5000,
.tuner_addr = 0x61,
.tuner_bus = 1,
.porta = CX23885_ANALOG_VIDEO,
.input = {
{
.type = CX23885_VMUX_TELEVISION,
.vmux = CX25840_COMPOSITE2,
.amux = CX25840_AUDIO8,
+ /* Some foo addition - just for testing */
},
{
.type = CX23885_VMUX_COMPOSITE1,
.vmux = CX25840_COMPOSITE8,
},
{
.type = CX23885_VMUX_SVIDEO,
.vmux = CX25840_SVIDEO_LUMA3 |
CX25840_SVIDEO_CHROMA4,
},
Thanks,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: Optimize DIV_ROUND_CLOSEST call
On Tue, Sep 18, 2012 at 12:49:53PM -0300, Mauro Carvalho Chehab wrote: Em 01-09-2012 15:53, Jean Delvare escreveu: DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; Hmm... this generates the following warning with W=1: drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] Perhaps it makes sense to use an optimized version for unsigned, or to change the macro to take the data types into account. DIV_ROUND_CLOSEST tests ((typeof(x))-1) = 0 on purpose, so the compiler can optimize the signed part of the macro away if the variable type is unsigned. The test was borrowed from C99 code. Would be great if someone has an idea how to tell the compiler not to create a warning for this test. Guenter -- 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
2x TT CT-3650 CI USB = corrupt video
Individually each of them work. When both of them are connected I get corrupted video as soon as I tune to another channel. There is no specific pattern in the logs, but now and then trouble about too large packets when communicating with the CAM appears in dmesg, which could make sense given the pervasive use of encryption by my cable provider. I have kept a log of most of the things I've already tried here: http://ubuntuforums.org/showthread.php?t=2054643 Is this a common problem when you use two of the same tuners? Who can help me fix this problem? Henk Poley -- 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: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Tue, Sep 18, 2012 at 5:40 AM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: Hi Devin, This is a very common problem when attempting to use any PCI/PCIe tuner under a hypervisor. Essentially the issue is all of the virtualization solutions provide very poor interrupt latency, which results in the data being lost. Devices delivering a high bitrate stream of data in realtime are much more likely for this problem to be visible since such devices have very little buffering (it's not like a hard drive controller where it can just deliver the data slower). The problem is not specific to the cx23885 - pretty much all of the PCI/PCIe bridges used in tuner cards work this way, and they cannot really be blamed for expecting to run in an environment with really crappy interrupt latency. I won't go as far as to say, abandon all hope, but you're not really likely to find any help in this forum. I can't say how happy I am that you were wrong in your guess. Quoting Konrad Rzeszutek Wilk: The issue as I understand is that the DVB drivers allocate their buffers from 0-4GB most (all the time?) so they never have to do bounce-buffering. While the pv-ops one ends up quite frequently doing the bounce-buffering, which implies that the DVB drivers end up allocating their buffers above the 4GB. This means we end up spending some CPU time (in the guest) copying the memory from 4GB to 0-4GB region (And vice-versa). You can see the original thread where this was found, together with a working patch, here: http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html -- Javier Marcet jmar...@gmail.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] mceusb: Optimize DIV_ROUND_CLOSEST call
Hi Mauro, On Tue, 18 Sep 2012 12:49:53 -0300, Mauro Carvalho Chehab wrote: Em 01-09-2012 15:53, Jean Delvare escreveu: DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; Hmm... this generates the following warning with W=1: drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] I doubt this is the only warning of that kind. There must be a reason why -Wextra isn't enabled by default. Perhaps it makes sense to use an optimized version for unsigned, or to change the macro to take the data types into account. This was discussed before, but Andrew said he preferred a single macro. And I agree with him, having two macros would induce a risk of the wrong one being called. If you can come up with a variant of DIV_ROUND_CLOSEST which performs the same and doesn't trigger the warning above, we'll be happy to see it, but neither Guenter nor myself could come up with one. -- Jean Delvare -- 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 v4] media: v4l2-ctrl: add a helper function to add standard control with driver specific menu
From: Lad, Prabhakar prabhakar@ti.com
Add helper function v4l2_ctrl_new_std_menu_items(), which adds
a standard menu control, with driver specific menu.
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: Sakari Ailus sakari.ai...@iki.fi
Cc: Sylwester Nawrocki s.nawro...@samsung.com
Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans de Goede hdego...@redhat.com
Cc: Kyungmin Park kyungmin.p...@samsung.com
Cc: Guennadi Liakhovetski g.liakhovet...@gmx.de
Cc: Rob Landley r...@landley.net
---
Changes for v4:
1: Rather then adding a function to modify the menu, added a helper
function, that creates a new standard control with user specific
menu.
Changes for v3:
1: Fixed style/grammer issues as pointed by Hans.
Thanks Hans for providing the description.
Changes for v2:
1: Fixed review comments from Hans, to have return type as
void, add WARN_ON() for fail conditions, allow this fucntion
to modify the menu of custom controls.
Documentation/video4linux/v4l2-controls.txt | 25
drivers/media/v4l2-core/v4l2-ctrls.c| 28 +++
include/media/v4l2-ctrls.h | 23 ++
3 files changed, 76 insertions(+), 0 deletions(-)
diff --git a/Documentation/video4linux/v4l2-controls.txt
b/Documentation/video4linux/v4l2-controls.txt
index 43da22b..ad8e172 100644
--- a/Documentation/video4linux/v4l2-controls.txt
+++ b/Documentation/video4linux/v4l2-controls.txt
@@ -136,11 +136,25 @@ Or alternatively for integer menu controls, by calling
v4l2_ctrl_new_int_menu:
const struct v4l2_ctrl_ops *ops,
u32 id, s32 max, s32 def, const s64 *qmenu_int);
+Standard menu controls with driver specific menu are added by calling
+v4l2_ctrl_new_std_menu_items:
+
+ struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(
+ struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
+ s32 skip_mask, s32 def, const char * const *qmenu_user);
+
These functions are typically called right after the v4l2_ctrl_handler_init:
static const s64 exp_bias_qmenu[] = {
-2, -1, 0, 1, 2
};
+ static const char * const test_pattern[] = {
+ Disabled,
+ Vertical Bars,
+ Solid Black,
+ Solid White,
+ };
v4l2_ctrl_handler_init(foo-ctrl_handler, nr_of_controls);
v4l2_ctrl_new_std(foo-ctrl_handler, foo_ctrl_ops,
@@ -156,6 +170,9 @@ These functions are typically called right after the
v4l2_ctrl_handler_init:
ARRAY_SIZE(exp_bias_qmenu) - 1,
ARRAY_SIZE(exp_bias_qmenu) / 2 - 1,
exp_bias_qmenu);
+ v4l2_ctrl_new_std_menu_items(foo-ctrl_handler, foo_ctrl_ops,
+ V4L2_CID_TEST_PATTERN, ARRAY_SIZE(test_pattern) - 1, 0,
+ 0, test_pattern);
...
if (foo-ctrl_handler.error) {
int err = foo-ctrl_handler.error;
@@ -185,6 +202,14 @@ v4l2_ctrl_new_std_menu in that it doesn't have the mask
argument and takes
as the last argument an array of signed 64-bit integers that form an exact
menu item list.
+The v4l2_ctrl_new_std_menu_items funtion is very similar as
+v4l2_ctrl_new_std_menu but takes a extra parameter qmenu_user, which is
+driver specific menu but yet a standard menu control.
+A good example for this control is the test pattern control for
+capture/display/sensors devices that have the capability to generate test
+patterns. These test patterns are hardware specific, so the contents of the
+menu will vary from device to device.
+
Note that if something fails, the function will return NULL or an error and
set ctrl_handler-error to the error code. If ctrl_handler-error was already
set, then it will just return and do nothing. This is also true for
diff --git a/drivers/media/v4l2-core/v4l2-ctrls.c
b/drivers/media/v4l2-core/v4l2-ctrls.c
index d731422..9ac1b75 100644
--- a/drivers/media/v4l2-core/v4l2-ctrls.c
+++ b/drivers/media/v4l2-core/v4l2-ctrls.c
@@ -1649,6 +1649,34 @@ struct v4l2_ctrl *v4l2_ctrl_new_std_menu(struct
v4l2_ctrl_handler *hdl,
}
EXPORT_SYMBOL(v4l2_ctrl_new_std_menu);
+/* Helper function for standard menu controls with user defined menu */
+struct v4l2_ctrl *v4l2_ctrl_new_std_menu_items(struct v4l2_ctrl_handler *hdl,
+ const struct v4l2_ctrl_ops *ops, u32 id, s32 max,
+ s32 mask, s32 def, const char * const *qmenu_user)
+{
+ const char * const *qmenu = v4l2_ctrl_get_menu(id);
+ const char *name;
+ enum v4l2_ctrl_type type;
+ s32 min;
+ s32 step;
+ u32 flags;
+
+ if (!qmenu) {
+ handler_set_err(hdl, -EINVAL);
+
Re: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Tue, Sep 18, 2012 at 2:34 PM, Javier Marcet jmar...@gmail.com wrote: I can't say how happy I am that you were wrong in your guess. Quoting Konrad Rzeszutek Wilk: Well, you haven't proven me wrong yet. :-) The issue as I understand is that the DVB drivers allocate their buffers from 0-4GB most (all the time?) so they never have to do bounce-buffering. While the pv-ops one ends up quite frequently doing the bounce-buffering, which implies that the DVB drivers end up allocating their buffers above the 4GB. This means we end up spending some CPU time (in the guest) copying the memory from 4GB to 0-4GB region (And vice-versa). You can see the original thread where this was found, together with a working patch, here: http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html As far as I can read, the patch has never been confirmed to work. The user mentioned upgrading to an updated kernel and seeing a slight decrease in load: http://lists.xen.org/archives/html/xen-devel/2012-01/msg02166.html Further, the reason many of the drivers in question require the memory to be in the 0-4GB memory region is due to some hardware not being able to DMA to memory 4GB. Such a change would have to be tested with every board that does scatter/gather, and the framework would likely have to change to explicitly allow the board driver to specify whether it supports memory 4GB. In short, this is a useful bit of information, but not clear whether it would actually solve the underlying problem. Again, I would be happy to be proven wrong, but there appears to still be quite a bit of work required for such. I would suggest trying the patch yourself to see if it has any visible effect on the problem. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
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:Tue Sep 18 19:00:24 CEST 2012 git hash:4313902ebe33155209472215c62d2f29d117be29 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS 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: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: ERRORS linux-2.6.34-x86_64: ERRORS linux-2.6.35.3-x86_64: ERRORS linux-2.6.36-x86_64: ERRORS 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: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: ERRORS linux-2.6.34-i686: ERRORS linux-2.6.35.3-i686: ERRORS linux-2.6.36-i686: ERRORS 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: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Tuesday.tar.bz2 The 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: Terratec Cinergy T PCIe Dual doesn;t work nder the Xen hypervisor
On Tue, Sep 18, 2012 at 8:56 PM, Devin Heitmueller dheitmuel...@kernellabs.com wrote: You can see the original thread where this was found, together with a working patch, here: http://lists.xen.org/archives/html/xen-devel/2012-01/msg01927.html As far as I can read, the patch has never been confirmed to work. The user mentioned upgrading to an updated kernel and seeing a slight decrease in load: http://lists.xen.org/archives/html/xen-devel/2012-01/msg02166.html Further, the reason many of the drivers in question require the memory to be in the 0-4GB memory region is due to some hardware not being able to DMA to memory 4GB. Such a change would have to be tested with every board that does scatter/gather, and the framework would likely have to change to explicitly allow the board driver to specify whether it supports memory 4GB. In short, this is a useful bit of information, but not clear whether it would actually solve the underlying problem. Again, I would be happy to be proven wrong, but there appears to still be quite a bit of work required for such. I would suggest trying the patch yourself to see if it has any visible effect on the problem. I'm sorry I was not explicit. I have tested it, I have it working right now, flawlessly. It even worked after resuming from S3! -- Javier Marcet jmar...@gmail.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] Support for Asus MyCinema U3100Mini Plus
On 09/17/12 23:57, Oliver Schinagl wrote:
On 09/17/12 23:07, Antti Palosaari wrote:
On 09/17/2012 11:43 PM, Oliver Schinagl wrote:
On 09/17/12 17:20, Oliver Schinagl wrote:
If tuner communication is really working and it says chip id is 0x5a
then it is different than driver knows. It could be new revision of
tuner. Change chip_id to match 0x5a
Ah, so it's called chip_id on one end, but tuner_id on the other end.
If/when I got this link working properly, I'll write a patch to fix
some
naming consistencies.
No, you are totally wrong now. Chip ID is value inside chip register.
Almost every chip has some chip id value which driver could detect it
is speaking with correct chip. In that case value is stored inside
fc2580.
Tuner ID is value stored inside AF9035 chip / eeprom. It is
configuration value for AF9035 hardware design. It says that AF9035
device uses FC2580 RF-tuner. AF9035 (FC2580) tuner ID and FC2580 chip
ID are different values having different meaning.
Ok, I understand the difference between Chip ID and Tuner ID I guess,
and with my new knowledge about dynamic debug I know also understand my
findings and where it goes wrong. I also know understand the chipID is
stored in fc2580.c under the fc2580_attach, where it checks for 0x56.
Appearantly my chipID is 0x5a. I wasn't triggered by this as none of
the
other fc2580 or af9035 devices had such a change so it wasn't obvious.
Tuner ID is actively being chechked/set in the source, so that seemed
more obvious.
It can't be 0x5a as chipid. I actually found that the vendor driver also
reads from 0x01 once to test the chip.
This function is a generic function which tests I2C interface's
availability by reading out it's I2C id data from reg. address '0x01'.
int fc2580_i2c_test( void ) {
return ( fc2580_i2c_read( 0x01 ) == 0x56 )? 0x01 : 0x00;
}
So something else is going weird. chipid being 0x56 is good though; same
chip revision. However I now got my system to hang, got some soft-hang
errors and the driver only reported failure on loading. No other debug
that I saw from dmesg before the crash. Will investigate more.
huoh.
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 ff
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 00
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
i2c i2c-5: fc2580: FCI FC2580 successfully identified
Why do you think its value is static - it cannot be changed...
I'm not saying it can be at all :p
according to debug output, I had
[ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a
so to your suggestion, I made it accept chip_id 0x5a as well.
if ((chip_id != 0x56) || (chip_id != 0x5a))
goto err;
But theoretically, it can't be 0x5a, as even the vendor driver would
only check for 0x56 (the function actually never gets called, so any
revision according the those sources could work).
So I will investigate why it would return 0x5a for the chip id :)
Turns out, the chip REALLY REALLY is 0x5a. I took some snapshots of both
the tuner and bridge/demodulator and uploaded them to the linuxtv wiki
[1]. If you could compare that one to your Chips? The markings are:
FCI 2580 01BD
AF9035B-N2
1012 QJFSQ
On a more serious note, right now, the driver soft-locks-up. Either with
or without accepting the 0x5a chip_id.
What I do is, manually load all modules, enable debugging and plug in
the device.
Everything appears to work normally for a while, I can do the dmesg dump
etc, but after about 22 seconds, I get this warning:
BUG: soft lockup - CPU#2 stuck for 22s! [udev-acl:2320]
(With the CPU# number being arbitrary). 22s later, another CPU fails. I
haven't waited for the other core's to fail.
Also, removing the module is impossible. Rebooting also fails. I have to
sys-req reboot it.
I don't know how much my patch is responsible for this of course, but
since attaching of the tuner fails due to the wrong chip_id in one case,
the only code affected is the USB id that loads the driver/firmware. I
did see this with the older firmware too btw, so appears to be firmware
unrelated.
In the meantime, I continue finding out why after accepting chip_id
0x5a, it still fails on tuner attach. I suppose somehow the tuner_id
isn't matching, which is weird, but will find out about it in the next
few days.
[1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T
Antti
--
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: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99 format
On Tue 18 Sep 2012 03:02:42 AM PDT, Venu Byravarasu wrote:
-Original Message-
From: Shubhrajyoti Datta [mailto:omaplinuxker...@gmail.com]
Sent: Tuesday, September 18, 2012 3:30 PM
To: Venu Byravarasu
Cc: Shubhrajyoti D; linux-media@vger.kernel.org; linux-
ker...@vger.kernel.org; julia.law...@lip6.fr
Subject: Re: [PATCHv2 6/6] media: Convert struct i2c_msg initialization to C99
format
struct i2c_msg test[2] = {
- { client-addr, 0,3, write },
- { client-addr, I2C_M_RD, 2, read },
+ {
+ .addr = client-addr,
+ .flags = 0,
Does flags not contain 0 by default?
It does however I felt that 0 means write so letting it be explicit.
In case a removal is preferred that's doable too however felt it is
more readable this way.
Though it adds readability, it carries an overhead of one write operation too.
So, better to remove it.
Partially initialized structs will have their unmentioned members
initialized to zero.
So there is no overhead of one write operation by mentioning it
explicitly.
--
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] Support for Asus MyCinema U3100Mini Plus (attempt 2)
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly. It uses the
af9035 USB Bridge chip, with an af9033 demodulator. The tuner used is
the FCI FC2580.
I have only done a quick dvb scan, but it failed to tune to anything.
Using dvbv5-scan -I CHANNEL channelfile It did show 'signal 100%' but
failed to tune to anything, so I don't think signal strength works at
all. Since I have really bad reception where my dev PC is, I may simple
not receive anything here.
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/dvb-frontends/af9033.c | 4 +++
drivers/media/dvb-frontends/af9033.h | 1 +
drivers/media/dvb-frontends/af9033_priv.h | 38 +++
drivers/media/tuners/fc2580.c | 4 ++-
drivers/media/tuners/fc2580.h | 10 +++
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 50 +++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
9 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
#define USB_PID_ASUS_U3000 0x171f
#define USB_PID_ASUS_U3000H0x1736
#define USB_PID_ASUS_U3100 0x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
#define USB_PID_YUAN_EC372S0x1edc
#define USB_PID_YUAN_STK7700PH 0x1f08
#define USB_PID_YUAN_PD378S0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+ case AF9033_TUNER_FC2580:
+ len = ARRAY_SIZE(tuner_init_fc2580);
+ init = tuner_init_fc2580;
+ break;
default:
dev_dbg(state-i2c-dev, %s: unsupported tuner ID=%d\n,
__func__, state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h
b/drivers/media/dvb-frontends/af9033.h
index 288622b..739137e 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
#define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */
#define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
#define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580 0x32 /* FIC FC2580 */
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..d2c9ae6 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,43 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FIC FC2580 tuner init
+ AF9033_TUNER_FC2580 = 0x32 */
+static const struct reg_val tuner_init_fc2580[] = {
+ { 0x800046, AF9033_TUNER_FC2580 },
+ { 0x800057, 0x01 },
+ { 0x800058, 0x00 },
+ { 0x80005f, 0x00 },
+ { 0x800060, 0x00 },
+ { 0x800071, 0x05 },
+ { 0x800072, 0x02 },
+ { 0x800074, 0x01 },
+ { 0x800079, 0x01 },
+ { 0x800093, 0x00 },
+ { 0x800094, 0x00 },
+ { 0x800095, 0x00 },
+ { 0x800096, 0x05 },
+ { 0x8000b3, 0x01 },
+ { 0x8000c3, 0x01 },
+ { 0x8000c4, 0x00 },
+ { 0x80f007, 0x00 },
+ { 0x80f00c, 0x19 },
+ { 0x80f00d, 0x1A },
+ { 0x80f00e, 0x00 },
+ { 0x80f00f, 0x02 },
+ { 0x80f010, 0x00 },
+ { 0x80f011, 0x02 },
+ { 0x80f012, 0x00 },
+ { 0x80f013, 0x02 },
+ { 0x80f014, 0x00 },
+ { 0x80f015, 0x02 },
+ { 0x80f01f, 0x96 },
+ { 0x80f020, 0x00 },
+ { 0x80f029, 0x96 },
+ { 0x80f02a, 0x00 },
+ { 0x80f077, 0x01 },
+ { 0x80f1e6, 0x01 },
+};
+
#endif /* AF9033_PRIV_H */
diff --git a/drivers/media/tuners/fc2580.c b/drivers/media/tuners/fc2580.c
index afc0491..4e7c802 100644
--- a/drivers/media/tuners/fc2580.c
+++ b/drivers/media/tuners/fc2580.c
@@ -498,8 +498,10 @@ struct dvb_frontend *fc2580_attach(struct dvb_frontend *fe,
dev_dbg(priv-i2c-dev, %s: chip_id=%02x\n, __func__, chip_id);
- if (chip_id != 0x56)
+ if ((chip_id != 0x56) (chip_id != 0x5a)) {
goto err;
+ }
+
dev_info(priv-i2c-dev,
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus (attempt 2)
On 09/19/2012 01:22 AM, oli...@schinagl.nl wrote:
From: Oliver Schinagl oli...@schinagl.nl
This is initial support for the Asus MyCinema U3100Mini Plus. The driver
in its current form gets detected and loads properly. It uses the
af9035 USB Bridge chip, with an af9033 demodulator. The tuner used is
the FCI FC2580.
I have only done a quick dvb scan, but it failed to tune to anything.
Using dvbv5-scan -I CHANNEL channelfile It did show 'signal 100%' but
failed to tune to anything, so I don't think signal strength works at
all. Since I have really bad reception where my dev PC is, I may simple
not receive anything here.
Signal strength is very worst indicator. It should not be 100% in any
case. Switch off stupid % meter your are using and look plain numbers.
It is should be something between 0-0x (0x == 100% ?).
For me successful tzap reports (af9035 + tua9001):
status 1f | signal 5eb7 | snr 010e | ber | unc |
FE_HAS_LOCK
FE_HAS_LOCK is most important, it says demodulator is locked to channel
and likely device is 100% working.
Biggest problem of your patch is fc2580 frontend callback. fc2580 driver
does not use any callback and that code is simple dead. It is never called.
Otherwise it looks quite correct.
regards
Antti
Signed-off-by: Oliver Schinagl oli...@schinagl.nl
---
drivers/media/dvb-core/dvb-usb-ids.h | 1 +
drivers/media/dvb-frontends/af9033.c | 4 +++
drivers/media/dvb-frontends/af9033.h | 1 +
drivers/media/dvb-frontends/af9033_priv.h | 38 +++
drivers/media/tuners/fc2580.c | 4 ++-
drivers/media/tuners/fc2580.h | 10 +++
drivers/media/usb/dvb-usb-v2/Kconfig | 1 +
drivers/media/usb/dvb-usb-v2/af9035.c | 50 +++
drivers/media/usb/dvb-usb-v2/af9035.h | 1 +
9 files changed, 109 insertions(+), 1 deletion(-)
diff --git a/drivers/media/dvb-core/dvb-usb-ids.h
b/drivers/media/dvb-core/dvb-usb-ids.h
index d572307..58e0220 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -329,6 +329,7 @@
#define USB_PID_ASUS_U30000x171f
#define USB_PID_ASUS_U3000H 0x1736
#define USB_PID_ASUS_U31000x173f
+#define USB_PID_ASUS_U3100MINI_PLUS0x1779
#define USB_PID_YUAN_EC372S 0x1edc
#define USB_PID_YUAN_STK7700PH0x1f08
#define USB_PID_YUAN_PD378S 0x2edc
diff --git a/drivers/media/dvb-frontends/af9033.c
b/drivers/media/dvb-frontends/af9033.c
index 0979ada..b40f5a0 100644
--- a/drivers/media/dvb-frontends/af9033.c
+++ b/drivers/media/dvb-frontends/af9033.c
@@ -314,6 +314,10 @@ static int af9033_init(struct dvb_frontend *fe)
len = ARRAY_SIZE(tuner_init_tda18218);
init = tuner_init_tda18218;
break;
+ case AF9033_TUNER_FC2580:
+ len = ARRAY_SIZE(tuner_init_fc2580);
+ init = tuner_init_fc2580;
+ break;
default:
dev_dbg(state-i2c-dev, %s: unsupported tuner ID=%d\n,
__func__, state-cfg.tuner);
diff --git a/drivers/media/dvb-frontends/af9033.h
b/drivers/media/dvb-frontends/af9033.h
index 288622b..739137e 100644
--- a/drivers/media/dvb-frontends/af9033.h
+++ b/drivers/media/dvb-frontends/af9033.h
@@ -42,6 +42,7 @@ struct af9033_config {
#define AF9033_TUNER_FC0011 0x28 /* Fitipower FC0011 */
#define AF9033_TUNER_MXL5007T0xa0 /* MaxLinear MxL5007T */
#define AF9033_TUNER_TDA182180xa1 /* NXP TDA 18218HN */
+#define AF9033_TUNER_FC2580 0x32 /* FIC FC2580 */
u8 tuner;
/*
diff --git a/drivers/media/dvb-frontends/af9033_priv.h
b/drivers/media/dvb-frontends/af9033_priv.h
index 0b783b9..d2c9ae6 100644
--- a/drivers/media/dvb-frontends/af9033_priv.h
+++ b/drivers/media/dvb-frontends/af9033_priv.h
@@ -466,5 +466,43 @@ static const struct reg_val tuner_init_tda18218[] = {
{0x80f1e6, 0x00},
};
+/* FIC FC2580 tuner init
+ AF9033_TUNER_FC2580 = 0x32 */
+static const struct reg_val tuner_init_fc2580[] = {
+ { 0x800046, AF9033_TUNER_FC2580 },
+ { 0x800057, 0x01 },
+ { 0x800058, 0x00 },
+ { 0x80005f, 0x00 },
+ { 0x800060, 0x00 },
+ { 0x800071, 0x05 },
+ { 0x800072, 0x02 },
+ { 0x800074, 0x01 },
+ { 0x800079, 0x01 },
+ { 0x800093, 0x00 },
+ { 0x800094, 0x00 },
+ { 0x800095, 0x00 },
+ { 0x800096, 0x05 },
+ { 0x8000b3, 0x01 },
+ { 0x8000c3, 0x01 },
+ { 0x8000c4, 0x00 },
+ { 0x80f007, 0x00 },
+ { 0x80f00c, 0x19 },
+ { 0x80f00d, 0x1A },
+ { 0x80f00e, 0x00 },
+ { 0x80f00f, 0x02 },
+ { 0x80f010, 0x00 },
+ { 0x80f011, 0x02 },
+ { 0x80f012, 0x00 },
+ { 0x80f013, 0x02 },
+ { 0x80f014, 0x00
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/18/2012 08:18 PM, Oliver Schinagl wrote:
On 09/17/12 23:57, Oliver Schinagl wrote:
On 09/17/12 23:07, Antti Palosaari wrote:
On 09/17/2012 11:43 PM, Oliver Schinagl wrote:
On 09/17/12 17:20, Oliver Schinagl wrote:
If tuner communication is really working and it says chip id is
0x5a
then it is different than driver knows. It could be new revision of
tuner. Change chip_id to match 0x5a
Ah, so it's called chip_id on one end, but tuner_id on the other
end.
If/when I got this link working properly, I'll write a patch to fix
some
naming consistencies.
No, you are totally wrong now. Chip ID is value inside chip register.
Almost every chip has some chip id value which driver could detect it
is speaking with correct chip. In that case value is stored inside
fc2580.
Tuner ID is value stored inside AF9035 chip / eeprom. It is
configuration value for AF9035 hardware design. It says that AF9035
device uses FC2580 RF-tuner. AF9035 (FC2580) tuner ID and FC2580
chip
ID are different values having different meaning.
Ok, I understand the difference between Chip ID and Tuner ID I guess,
and with my new knowledge about dynamic debug I know also
understand my
findings and where it goes wrong. I also know understand the chipID is
stored in fc2580.c under the fc2580_attach, where it checks for 0x56.
Appearantly my chipID is 0x5a. I wasn't triggered by this as none of
the
other fc2580 or af9035 devices had such a change so it wasn't obvious.
Tuner ID is actively being chechked/set in the source, so that seemed
more obvious.
It can't be 0x5a as chipid. I actually found that the vendor driver
also
reads from 0x01 once to test the chip.
This function is a generic function which tests I2C interface's
availability by reading out it's I2C id data from reg. address '0x01'.
int fc2580_i2c_test( void ) {
return ( fc2580_i2c_read( 0x01 ) == 0x56 )? 0x01 : 0x00;
}
So something else is going weird. chipid being 0x56 is good though;
same
chip revision. However I now got my system to hang, got some soft-hang
errors and the driver only reported failure on loading. No other debug
that I saw from dmesg before the crash. Will investigate more.
huoh.
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 ff
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
usb 2-2: rtl28xxu_ctrl_msg: 40 00 ac 01 10 03 01 00 00
usb 2-2: rtl28xxu_ctrl_msg: c0 00 ac 01 00 03 01 00 56
i2c i2c-5: fc2580: FCI FC2580 successfully identified
Why do you think its value is static - it cannot be changed...
I'm not saying it can be at all :p
according to debug output, I had
[ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a
so to your suggestion, I made it accept chip_id 0x5a as well.
if ((chip_id != 0x56) || (chip_id != 0x5a))
goto err;
But theoretically, it can't be 0x5a, as even the vendor driver would
only check for 0x56 (the function actually never gets called, so any
revision according the those sources could work).
So I will investigate why it would return 0x5a for the chip id :)
Turns out, the chip REALLY REALLY is 0x5a. I took some snapshots of both
the tuner and bridge/demodulator and uploaded them to the linuxtv wiki
[1]. If you could compare that one to your Chips? The markings are:
FCI 2580 01BD
AF9035B-N2
1012 QJFSQ
I haven't opened my device at all...
On a more serious note, right now, the driver soft-locks-up. Either with
or without accepting the 0x5a chip_id.
What I do is, manually load all modules, enable debugging and plug in
the device.
Everything appears to work normally for a while, I can do the dmesg dump
etc, but after about 22 seconds, I get this warning:
BUG: soft lockup - CPU#2 stuck for 22s! [udev-acl:2320]
(With the CPU# number being arbitrary). 22s later, another CPU fails. I
haven't waited for the other core's to fail.
Also, removing the module is impossible. Rebooting also fails. I have to
sys-req reboot it.
I don't know how much my patch is responsible for this of course, but
since attaching of the tuner fails due to the wrong chip_id in one case,
the only code affected is the USB id that loads the driver/firmware. I
did see this with the older firmware too btw, so appears to be firmware
unrelated.
In the meantime, I continue finding out why after accepting chip_id
0x5a, it still fails on tuner attach. I suppose somehow the tuner_id
isn't matching, which is weird, but will find out about it in the next
few days.
Tuner attach does nothing more that could fail than check that one
register. It is almost impossible to get it failing if tuner ID match.
Maybe I2C communication is not working, error returned and it bails out?
Anyhow, such situation should be visible when debugs are enabled.
[1] http://www.linuxtv.org/wiki/index.php/Asus_U3100_Mini_plus_DVB-T
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to
Re: [PATCH] Support for Asus MyCinema U3100Mini Plus
On 09/17/2012 06:20 PM, Oliver Schinagl wrote: On 17-09-12 15:52, Antti Palosaari wrote: On 09/17/2012 04:26 PM, Oliver Schinagl wrote: On 17-09-12 15:16, Antti Palosaari wrote: On 09/17/2012 04:02 PM, Oliver Schinagl wrote: On 17-09-12 10:25, Oliver Schinagl wrote: On 17-09-12 01:36, Antti Palosaari wrote: On 09/17/2012 01:10 AM, Oliver Schinagl wrote: On 09/16/12 19:25, Antti Palosaari wrote: On 09/16/2012 06:03 PM, Oliver Schinagl wrote: I don't have windows, so capturing using windows is near impossible. Also since the vendor driver used to work, I guess I will have to dig into that more. You could capture data from Linux too (eg. Wireshark). Ah of course. I'll dig up the old vendor driver and see if I can get it running on 3.2 or better yet, on 3.5/your-3.6. I know there's patches for 3.2 but I've never tested those. Otherwise the older 2.6.2* series should still work. But with a little experience you could see those GPIOs reading existing Linux driver and then do some tests to see what happens. For example some GPIO powers tuner off, you will see I2C error. Changing it back error disappears. I have zero experience so I'll try to figure things out. I guess you currently turn on/off GPIO's etc in the current driver? Any line which does this so I can examine how it's done? As for the I2C errors, I suppose the current driver will spew those out? Those GPIOs are set in file af9035.c, functiuons: af9035_tuner_attach() and af9035_fc0011_tuner_callback(). For TDA18218 tuner there is no any GPIOs set, which could be wrong and it just works with good luck OR it is wired/connected directly so that GPIOs are not used at all. Ahah! Then I know what to look for. Since af9035 also has fc0011 support, there should be some similarities I can find. Which I did. I found that the af9033 sets the gpiot2 o, en and on values high to enable the tuner. Luckly, the fc2580 is routed to the exact same gpio and thus the same tuner enable/disable routine can be used as the FC0011. Appearantly the FC0011 tuner also has a led that needs to be enabled/disabled, at gpioh8, which the fc2580 lacks. So I found the tuner enable and should be able to incorporate that without issue. The other callback the fc2580 has, is a 'reset'. The fc2580 appears to be lacking such feature, or is not used in the vendor driver. Speaking off, in my previous message, I wrote about the driver spitting out the following error: [dvb_usb_af9035]af9035_read_config =_ %s: [%d]tuner=%02x\012 It is the tuner ID value got from eeprom. You should take that number and add it to af9033.h file: #define AF9033_TUNER_FC25800x = insert number here Yes, but I think %s, %d and %02x\012 should actually list values? (\012 I belive is \newline) I need to learn dynamic_debug; and I think I may have set it up wrong last time (af9035 and fc2580, but not af9033). I found some good documentation and will try this tonight. None of the values where set however. Did I miss-configure anything for it to cause to 'forget' substituting? What you mean? Could you enable debugs, plug stick in and copy paste what debugs says? I have dynamic debugging enabled and have gotten the above snipped from the proc/sysfs interface. Also dmesg from replugging I've attached a few messages back. [ 188.051502] af9033: firmware version: LINK=12.13.15.0 OFDM=6.20.15.0 [ 188.051520] usb 1-3: DVB: registering adapter 0 frontend 0 (Afatech AF9033 (DVB-T))... [ 188.054019] i2c i2c-1: fc2580_attach: chip_id=5a [ 188.054030] i2c i2c-1: fc2580_attach: failed=0 [ 188.054471] i2c i2c-1: fc2580_release: [ 188.054485] usb 1-3: dvb_usbv2: 'Asus U3100Mini Plus' error while loading driver (-19) is the dmesg output from then, which doesn't list the values from the debugging bit either. I suppose I need more debugging options enabled to have those flag characters actually filled in? It should print af9035 debugs too. usb 2-2: af9035_read_config: [0]tuner=27 modprobe dvb_usb_af9035; echo -n 'module dvb_usb_af9035 +p' /sys/kernel/debug/dynamic_debug/control modprobe dvb_usb_v2; echo -n 'module dvb_usb_v2 +p' /sys/kernel/debug/dynamic_debug/control If tuner communication is really working and it says chip id is 0x5a then it is different than driver knows. It could be new revision of tuner. Change chip_id to match 0x5a Ah, so it's called chip_id on one end, but tuner_id on the other end. If/when I got this link working properly, I'll write a patch to fix some naming consistencies. No, you are totally wrong now. Chip ID is value inside chip register. Almost every chip has some chip id value which driver could detect it is speaking with correct chip. In that case value is stored inside fc2580. Tuner ID is value stored inside AF9035 chip / eeprom. It is configuration value for AF9035 hardware design. It says that AF9035 device uses FC2580 RF-tuner. AF9035 (FC2580) tuner ID and FC2580 chip ID are different values having different meaning. Ok, I understand the
Re: [PATCH 4/5] video:omap3isp:fix up ENOIOCTLCMD error handling
Hi Mauro, On Saturday 15 September 2012 13:24:37 Mauro Carvalho Chehab wrote: Em Thu, 13 Sep 2012 06:03:21 +0200 Laurent Pinchart escreveu: On Monday 27 August 2012 15:23:15 Wanlong Gao wrote: At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be translated as ENOTTY to user mode. Cc: Laurent Pinchart laurent.pinch...@ideasonboard.com Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org Signed-off-by: Wanlong Gao gaowanl...@cn.fujitsu.com --- drivers/media/video/omap3isp/ispvideo.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/media/video/omap3isp/ispvideo.c b/drivers/media/video/omap3isp/ispvideo.c index b37379d..2dd982e 100644 --- a/drivers/media/video/omap3isp/ispvideo.c +++ b/drivers/media/video/omap3isp/ispvideo.c @@ -337,7 +337,7 @@ __isp_video_get_format(struct isp_video *video, struct v4l2_format *format) fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE; ret = v4l2_subdev_call(subdev, pad, get_fmt, NULL, fmt); if (ret == -ENOIOCTLCMD) - ret = -EINVAL; + ret = -ENOTTY; I don't think this location should be changed. __isp_video_get_format() is called by isp_video_check_format() only, which in turn is called by isp_video_streamon() only. A failure to retrieve the format in __isp_video_get_format() does not really mean the VIDIOC_STREAMON is not supported. I'll apply hunks 2 to 5 and drop hunk 1 if that's fine with you. Not quite sure how to tag it at patchwork... I guess I'll mark it as accepted, as, from what I understood, Laurent partially accepted it, and will be adding on his tree. Yes I'll add a modified version to my tree. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: Optimize DIV_ROUND_CLOSEST call
On Tue, Sep 18, 2012 at 08:35:09PM +0200, Jean Delvare wrote: Hi Mauro, On Tue, 18 Sep 2012 12:49:53 -0300, Mauro Carvalho Chehab wrote: Em 01-09-2012 15:53, Jean Delvare escreveu: DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c 2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; Hmm... this generates the following warning with W=1: drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] drivers/media/rc/mceusb.c:629:4: warning: comparison of unsigned expression = 0 is always true [-Wtype-limits] I doubt this is the only warning of that kind. There must be a reason why -Wextra isn't enabled by default. Perhaps it makes sense to use an optimized version for unsigned, or to change the macro to take the data types into account. This was discussed before, but Andrew said he preferred a single macro. And I agree with him, having two macros would induce a risk of the wrong one being called. If you can come up with a variant of DIV_ROUND_CLOSEST which performs the same and doesn't trigger the warning above, we'll be happy to see it, but neither Guenter nor myself could come up with one. I did some more research, and I think I found a fix. I'll send out a patch in a minute for people to try. Guenter -- 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
