V4L-DVB: Status of Lite-On TVT-1060
Hi there, I have an Asus F8SA notebook with Lite-On TVT-1060 tuner. I have done lots of searching to find out how to get this to work but have only found links to patches for older versions or broken links. Can someone tell me whether there is likely to ever be support for this card, or perhaps point me in the right direction to get this card working? I am happy to assist with development but have no idea where to start. Cheers, Michael -- 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
Hauppauge WinTV-HVR-1120 on Unbuntu 10.04
Hi After upgrading from Ubuntu 9.10 to Ubuntu 10.04 my Hauppauge WinTV-HVR-1120 (sometimes) doesn't work correctly. I get random the following errors: [ 53.216153] DVB: registering new adapter (saa7133[0]) [ 53.216156] DVB: registering adapter 2 frontend 0 (NXP TDA10048HN DVB-T)... [ 53.840013] tda10048_firmware_upload: waiting for firmware upload (dvb-fe-tda10048-1.0.fw)... [ 53.840019] saa7134 :01:06.0: firmware: requesting dvb-fe-tda10048-1.0.fw [ 53.880505] tda10048_firmware_upload: firmware read 24878 bytes. [ 53.880509] tda10048_firmware_upload: firmware uploading [ 58.280136] tda10048_firmware_upload: firmware uploaded [ 59.024537] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.024541] tda18271c2_rf_tracking_filters_correction: error -5 on line 264 [ 59.420153] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 59.420157] tda18271_toggle_output: error -5 on line 47 [ 91.004019] Clocksource tsc unstable (delta = -295012684 ns) [ 256.293639] eth0: link up. [ 256.294750] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 263.523498] eth0: link down. [ 265.258740] eth0: link up. [ 266.460026] eth0: no IPv6 routers present [ 9869.636167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9869.636178] tda18271_init: error -5 on line 826 [ 9872.636220] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9872.636232] tda18271_toggle_output: error -5 on line 47 [ 9998.240167] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [ 9998.240178] tda18271_init: error -5 on line 826 [10001.240179] tda18271_write_regs: ERROR: idx = 0x5, len = 1, i2c_transfer returned: -5 [10001.240190] tda18271_toggle_output: error -5 on line 47 Any ideas? Thanks -- 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] viafb camera controller driver
Em 10-10-2010 19:23, Jonathan Corbet escreveu:
> Howdy, all,
>
> Well, that took a whole lot longer than I had hoped...but, attached, is a
> new version of the viafb camera driver patch, done against 2.6.36-rc7.
> I've tried to address most of Laurent's comments from back in June; in
> particular, I have:
>
> - Gotten rid of the static device structure
> - Fixed some locking glitches
> - Fixed a bit of device initialization silliness.
>
> One thing I have *not* done is to push locking down into the ov7670
> driver. That would be a good thing to do at some point, but playing with
> that driver was beyond the scope of what I was trying to do here.
>
> This driver will still need some OLPC bits to work properly, but Daniel is
> working on that. This version of the driver does work on XO-1.5 systems,
> modulo some 2.6.36 API changes.
>
> Mauro, any chance of putting this in the queue for 2.6.37? Yes, I know
> it's really late, my apologies for that.
Jon,
I'll work to handle it for 2.6.37.
>
> Thanks,
>
> jon
> ---
> Add a driver for the video capture port on VIA integrated chipsets. This
> version has a remaining OLPCism or two and expects to be talking to an
> ov7670; those can be improved as the need arises.
>
> This work was supported by the One Laptop Per Child project.
> Thanks to Laurent Pinchart for a number of useful comments.
>
> Cc: Florian Tobias Schandinat
> Signed-off-by: Jonathan Corbet
> ---
> drivers/media/video/Kconfig | 10 +
> drivers/media/video/Makefile |2 +
> drivers/media/video/via-camera.c | 1406
> ++
> drivers/media/video/via-camera.h | 93 +++
> drivers/video/via/accel.c|2 +-
> drivers/video/via/via-core.c | 16 +-
> include/linux/via-core.h |4 +-
> include/media/v4l2-chip-ident.h |4 +
> 8 files changed, 1533 insertions(+), 4 deletions(-)
> create mode 100644 drivers/media/video/via-camera.c
> create mode 100644 drivers/media/video/via-camera.h
>
> diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
> index f6e4d04..b62d6b0 100644
> --- a/drivers/media/video/Kconfig
> +++ b/drivers/media/video/Kconfig
> @@ -774,6 +774,16 @@ config VIDEO_CAFE_CCIC
> CMOS camera controller. This is the controller found on first-
> generation OLPC systems.
>
> +config VIDEO_VIA_CAMERA
> + tristate "VIAFB camera controller support"
> + depends on FB_VIA
> + select VIDEOBUF_DMA_SG
> + select VIDEO_OV7670
> + help
> +Driver support for the integrated camera controller in VIA
> +Chrome9 chipsets. Currently only tested on OLPC xo-1.5 systems
> +with ov7670 sensors.
> +
> config SOC_CAMERA
> tristate "SoC camera support"
> depends on VIDEO_V4L2 && HAS_DMA && I2C
> diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
> index 40f98fb..b592804 100644
> --- a/drivers/media/video/Makefile
> +++ b/drivers/media/video/Makefile
> @@ -125,6 +125,8 @@ obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o
>
> obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o
>
> +obj-$(CONFIG_VIDEO_VIA_CAMERA) += via-camera.o
> +
> obj-$(CONFIG_USB_DABUSB)+= dabusb.o
> obj-$(CONFIG_USB_SE401) += se401.o
> obj-$(CONFIG_USB_ZR364XX) += zr364xx.o
> diff --git a/drivers/media/video/via-camera.c
> b/drivers/media/video/via-camera.c
> new file mode 100644
> index 000..8e970a7
> --- /dev/null
> +++ b/drivers/media/video/via-camera.c
> @@ -0,0 +1,1406 @@
> +/*
> + * Driver for the VIA Chrome integrated camera controller.
> + *
> + * Copyright 2009,2010 Jonathan Corbet
> + * Distributable under the terms of the GNU General Public License, version 2
> + *
> + * This work was supported by the One Laptop Per Child project
> + */
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#include "via-camera.h"
> +
> +MODULE_AUTHOR("Jonathan Corbet ");
> +MODULE_DESCRIPTION("VIA framebuffer-based camera controller driver");
> +MODULE_LICENSE("GPL");
> +
> +static int flip_image;
> +module_param(flip_image, bool, 0444);
> +MODULE_PARM_DESC(flip_image,
> + "If set, the sensor will be instructed to flip the image "
> + "vertically.");
> +
> +#ifdef CONFIG_OLPC_XO_1_5
> +static int override_serial;
> +module_param(override_serial, bool, 0444);
> +MODULE_PARM_DESC(override_serial,
> + "The camera driver will normally refuse to load if "
> + "the XO 1.5 serial port is enabled. Set this option "
> + "to force the issue.");
> +#endif
> +
> +/*
> + * Basic window sizes.
> + */
> +#define VGA_WIDTH640
> +#define VGA_HEIGHT 480
> +#define QCIF_WIDTH 176
> +#define QCIF_HEIGHT 144
> +
> +/*
Re: [PATCH] viafb camera controller driver
Hi Jonathan,
On Monday 11 October 2010 00:23:13 Jonathan Corbet wrote:
> Howdy, all,
>
> Well, that took a whole lot longer than I had hoped...but, attached, is a
> new version of the viafb camera driver patch, done against 2.6.36-rc7.
> I've tried to address most of Laurent's comments from back in June; in
> particular, I have:
>
> - Gotten rid of the static device structure
Thanks. There's one more left, and it's easy to remove, see below.
> - Fixed some locking glitches
> - Fixed a bit of device initialization silliness.
>
> One thing I have *not* done is to push locking down into the ov7670
> driver. That would be a good thing to do at some point, but playing with
> that driver was beyond the scope of what I was trying to do here.
>
> This driver will still need some OLPC bits to work properly, but Daniel is
> working on that. This version of the driver does work on XO-1.5 systems,
> modulo some 2.6.36 API changes.
[snip]
> +/*
> + * Yes, this is a hack, but there's only going to be one of these
> + * on any system we know of.
> + */
> +static struct via_camera *via_cam_info;
That's what I'm talking about.
[snip]
> +static __devinit int viacam_probe(struct platform_device *pdev)
> +{
[snip]
> + /*
> + * Basic structure initialization.
> + */
> + cam = kzalloc (sizeof(struct via_camera), GFP_KERNEL);
> + if (cam == NULL)
> + return -ENOMEM;
> + via_cam_info = cam;
You set it here.
[snip]
> +static __devexit int viacam_remove(struct platform_device *pdev)
> +{
> + struct via_camera *cam = via_cam_info;
And use it here.
Just call platform_set_drvdata(pdev, cam) in viacam_probe to store the struct
via_camera pointer in the platform device, and platform_get_drvdata(pdev) here
to retrieve it.
--
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: OMAP 3530 camera ISP forks and new media framework
So... let's see if i got some things right, please let me now if you disagree: - I do want to use the omap34xxcam.c driver as it is for the newest framework and I get most support for it - The camera sensor driver must implement the v4l2-subdev and the new pad-level api. As the register list of mt9t031 and mt9p031 sensors are identical, I could copy the subdev-part. But the existing mt9t031 driver stacks on top of soc_camera. soc_camera creates a v4l2 device. omap34xxcam also creates a v4l2 dev. Obviously they are competing architectures. Guennadi wrote: > There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if > mt9t031 and mt9p031 are indeed similar enough, I think, the right way is > to join efforts to port soc-camera over to the new "pad-level" API and > re-use the driver. This confuses me a bit now. Guennadi, is your idea to update the soc_camera interface for pad-level support and port omap34xxcam to a soc_camera_omap34xxcam? I don't think I am capable of writing a new host bridge driver, so I would prefer touching only the sensor driver part. Or do you think it is better to remove the soc_camera dependency and fit the camera sensor driver to omap34xxcam directly? - If I do the later, I take Laurent's approach and look at his MT9T001 sensor driver for Sakari's omap34xxcam host driver and adapt it for my needs. I can look for more subdev pad-level examples in Vaibhav's repository. So long, thanks for all your help, Bastian -- 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: OMAP 3530 camera ISP forks and new media framework
Hi Bastian, On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: > So... let's see if i got some things right, please let me now if you > disagree: > > - I do want to use the omap34xxcam.c driver as it is for the newest > framework and I get most support for it That's a bad start. With the latest driver, omap34xxcam.c doesn't exist anymore :-) > - The camera sensor driver must implement the v4l2-subdev and the new > pad-level api. As the register list of mt9t031 and mt9p031 sensors are > identical, I could copy the subdev-part. But the existing mt9t031 > driver stacks on top of soc_camera. soc_camera creates a v4l2 device. > omap34xxcam also creates a v4l2 dev. Obviously they are competing > architectures. > > Guennadi wrote: > > There is already an mt9t031 v4l2-subdev / soc-camera driver, so, if > > mt9t031 and mt9p031 are indeed similar enough, I think, the right way is > > to join efforts to port soc-camera over to the new "pad-level" API and > > re-use the driver. > > This confuses me a bit now. Guennadi, is your idea to update the > soc_camera interface for pad-level support and port omap34xxcam to a > soc_camera_omap34xxcam? > I don't think I am capable of writing a new host bridge driver, so I > would prefer touching only the sensor driver part. Or do you think it > is better to remove the soc_camera dependency and fit the camera > sensor driver to omap34xxcam directly? You can either - Take the mt9t031 driver, add support for the mt9p031 chip, make the soc- camera dependency optional and add the pad-level operations. Adding support for the mt9p031 and adding pad-level operations (in addition to the existing subdev format operations) should be quite straightforward. Remove the soc- camera dependency might be more difficult, I'm less experienced on that subject. - Take the mt9t001 driver and add support for the mt9p031 chip. Register lists are quite similar, so that shouldn't be overly difficult. You would have to remove the hardcoded image sizes and make them configurable. Use the driver_data field in struct i2c_device_id mt9t001_id[] to store model-specific parameters. Different field sizes in some registers might make this approach a bit difficult. > - If I do the later, I take Laurent's approach and look at his MT9T001 > sensor driver for Sakari's omap34xxcam host driver and adapt it for my > needs. I can look for more subdev pad-level examples in Vaibhav's > repository. In the long term drivers should support both soc-camera and non soc-camera use cases, but we're not there yet. -- 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 1/5 v4] V4L/DVB: s5p-fimc: Register definition cleanup
Hi Seuni, thanks for you review! On 10/11/2010 07:09 AM, 박세운 wrote: > Sewoon Park wrote: > >> Add MIPI CSI format definitions, prepare DMA address >> definitions for interlaced input frame mode. >> >> Signed-off-by: Sylwester Nawrocki >> Signed-off-by: Kyungmin Park >> --- >> drivers/media/video/s5p-fimc/fimc-reg.c |6 +- >> drivers/media/video/s5p-fimc/regs-fimc.h | 61 - > - >> --- >> 2 files changed, 28 insertions(+), 39 deletions(-) >> >> diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c >> b/drivers/media/video/s5p-fimc/fimc-reg.c >> index 5570f1c..70f29c5 100644 >> --- a/drivers/media/video/s5p-fimc/fimc-reg.c >> +++ b/drivers/media/video/s5p-fimc/fimc-reg.c >> @@ -507,9 +507,9 @@ void fimc_hw_set_input_addr(struct fimc_dev *dev, >> struct fimc_addr *paddr) >> cfg |= S5P_CIREAL_ISIZE_ADDR_CH_DIS; >> writel(cfg, dev->regs + S5P_CIREAL_ISIZE); >> >> -writel(paddr->y, dev->regs + S5P_CIIYSA0); >> -writel(paddr->cb, dev->regs + S5P_CIICBSA0); >> -writel(paddr->cr, dev->regs + S5P_CIICRSA0); >> +writel(paddr->y, dev->regs + S5P_CIIYSA(0)); >> +writel(paddr->cb, dev->regs + S5P_CIICBSA(0)); >> +writel(paddr->cr, dev->regs + S5P_CIICRSA(0)); >> >> cfg &= ~S5P_CIREAL_ISIZE_ADDR_CH_DIS; >> writel(cfg, dev->regs + S5P_CIREAL_ISIZE); >> diff --git a/drivers/media/video/s5p-fimc/regs-fimc.h >> b/drivers/media/video/s5p-fimc/regs-fimc.h >> index a3cfe82..9e83315 100644 >> --- a/drivers/media/video/s5p-fimc/regs-fimc.h >> +++ b/drivers/media/video/s5p-fimc/regs-fimc.h >> @@ -11,10 +11,6 @@ >> #ifndef REGS_FIMC_H_ >> #define REGS_FIMC_H_ >> >> -#define S5P_CIOYSA(__x) (0x18 + (__x) * 4) >> -#define S5P_CIOCBSA(__x)(0x28 + (__x) * 4) >> -#define S5P_CIOCRSA(__x)(0x38 + (__x) * 4) >> - >> /* Input source format */ >> #define S5P_CISRCFMT0x00 >> #define S5P_CISRCFMT_ITU601_8BIT(1 << 31) >> @@ -28,22 +24,21 @@ >> >> /* Window offset */ >> #define S5P_CIWDOFST0x04 >> -#define S5P_CIWDOFST_WINOFSEN (1 << 31) >> +#define S5P_CIWDOFST_OFF_EN (1 << 31) >> #define S5P_CIWDOFST_CLROVFIY (1 << 30) >> #define S5P_CIWDOFST_CLROVRLB (1 << 29) >> -#define S5P_CIWDOFST_WINHOROFST_MASK(0x7ff << 16) >> +#define S5P_CIWDOFST_HOROFF_MASK(0x7ff << 16) >> #define S5P_CIWDOFST_CLROVFICB (1 << 15) >> #define S5P_CIWDOFST_CLROVFICR (1 << 14) >> -#define S5P_CIWDOFST_WINHOROFST(x) ((x) << 16) >> -#define S5P_CIWDOFST_WINVEROFST(x) ((x) << 0) >> -#define S5P_CIWDOFST_WINVEROFST_MASK(0xfff << 0) >> +#define S5P_CIWDOFST_HOROFF(x) ((x) << 16) >> +#define S5P_CIWDOFST_VEROFF(x) ((x) << 0) >> +#define S5P_CIWDOFST_VEROFF_MASK(0xfff << 0) >> >> /* Global control */ >> #define S5P_CIGCTRL 0x08 >> #define S5P_CIGCTRL_SWRST (1 << 31) >> #define S5P_CIGCTRL_CAMRST_A(1 << 30) >> #define S5P_CIGCTRL_SELCAM_ITU_A(1 << 29) >> -#define S5P_CIGCTRL_SELCAM_ITU_MASK (1 << 29) >> #define S5P_CIGCTRL_TESTPAT_NORMAL (0 << 27) >> #define S5P_CIGCTRL_TESTPAT_COLOR_BAR (1 << 27) >> #define S5P_CIGCTRL_TESTPAT_HOR_INC (2 << 27) >> @@ -61,6 +56,8 @@ >> #define S5P_CIGCTRL_SHDW_DISABLE(1 << 12) >> #define S5P_CIGCTRL_SELCAM_MIPI_A (1 << 7) >> #define S5P_CIGCTRL_CAMIF_SELWB (1 << 6) >> +/* 0 - ITU601; 1 - ITU709 */ >> +#define S5P_CIGCTRL_CSC_ITU601_709 (1 << 5) >> #define S5P_CIGCTRL_INVPOLHSYNC (1 << 4) >> #define S5P_CIGCTRL_SELCAM_MIPI (1 << 3) >> #define S5P_CIGCTRL_INTERLACE (1 << 0) >> @@ -72,23 +69,10 @@ >> #define S5P_CIWDOFST2_HOROFF(x) ((x) << 16) >> #define S5P_CIWDOFST2_VEROFF(x) ((x) << 0) >> >> -/* Output DMA Y plane start address */ >> -#define S5P_CIOYSA1 0x18 >> -#define S5P_CIOYSA2 0x1c >> -#define S5P_CIOYSA3 0x20 >> -#define S5P_CIOYSA4 0x24 >> - >> -/* Output DMA Cb plane start address */ >> -#define S5P_CIOCBSA10x28 >> -#define S5P_CIOCBSA20x2c >> -#define S5P_CIOCBSA30x30 >> -#define S5P_CIOCBSA40x34 >> - >> -/* Output DMA Cr plane start address */ >> -#define S5P_CIOCRSA10x38 >> -#define S5P_CIOCRSA20x3c >> -#define S5P_CIOCRSA30x40 >> -#define S5P_CIOCRSA40x44 >> +/* Output DMA Y/Cb/Cr plane start addresses */ >> +#define S5P_CIOYSA(n) (0x18 + (n) * 4) >> +#define S5P_CIOCBSA(n) (0x28 + (n) * 4) >> +#define S5P_CIOCRSA(n) (0x38 + (n) * 4) >> > As you know, S5P series have S5PC210 also. > Then, > Why don't you add S5PC210's 32 registers for Output DMA start address some
[PATCH v2] V4L/DVB: Add driver for Siliconfile SR030PC30 VGA camera
Add an I2C/v4l2-subdev driver for Siliconfile SR030PC30 VGA camera sensor with Image Signal Processor. SR030PC30 is the low resolution camera sensor on Samsung Aquila boards. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- Hello, this patch is a second version of I2C/v4l2-subdev driver for SR030PC30 camera sensor from SiliconFile. It has undergone significant refactoring comparing to the first version. I am not planning any more extensive changes like this for this driver. The driver has been tested with s5p-fimc bridge interface on Aquila boards. Some features which are also available in the bridge interface are not exported through subdev operation, e.g. cropping or flipping. Changes since v1: - corrected include paths - improved/refactored v4l2 controls handling (white balance, manual exposure) - single array used for all base configuration registers Regards, Sylwester Nawrocki --- drivers/media/video/Kconfig |6 + drivers/media/video/Makefile|1 + drivers/media/video/sr030pc30.c | 893 +++ include/media/sr030pc30.h | 21 + 4 files changed, 921 insertions(+), 0 deletions(-) create mode 100644 drivers/media/video/sr030pc30.c create mode 100644 include/media/sr030pc30.h diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig index 75404fc..ffa3a27 100644 --- a/drivers/media/video/Kconfig +++ b/drivers/media/video/Kconfig @@ -706,6 +706,12 @@ config VIDEO_CAFE_CCIC CMOS camera controller. This is the controller found on first- generation OLPC systems. +config VIDEO_SR030PC30 + tristate "SR030PC30 VGA camera sensor support" + depends on I2C && VIDEO_V4L2 + ---help--- + This driver supports SR030PC30 VGA camera from Siliconfile + config SOC_CAMERA tristate "SoC camera support" depends on VIDEO_V4L2 && HAS_DMA && I2C diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile index 118196c..e239b0a 100644 --- a/drivers/media/video/Makefile +++ b/drivers/media/video/Makefile @@ -71,6 +71,7 @@ obj-$(CONFIG_VIDEO_OV7670)+= ov7670.o obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_MT9V011) += mt9v011.o +obj-$(CONFIG_VIDEO_SR030PC30) += sr030pc30.o obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o diff --git a/drivers/media/video/sr030pc30.c b/drivers/media/video/sr030pc30.c new file mode 100644 index 000..9f29da0 --- /dev/null +++ b/drivers/media/video/sr030pc30.c @@ -0,0 +1,893 @@ +/* + * Driver for SiliconFile SR030PC30 VGA (1/10-Inch) Image Sensor with ISP + * + * Copyright (C) 2010 Samsung Electronics Co., Ltd + * Author: Sylwester Nawrocki, s.nawro...@samsung.com + * + * Based on original driver authored by Dongsoo Nathaniel Kim + * and HeungJun Kim . + * + * Based on mt9v011 Micron Digital Image Sensor driver + * Copyright (c) 2009 Mauro Carvalho Chehab (mche...@redhat.com) + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License as published by + * the Free Software Foundation; either version 2 of the License, or + * (at your option) any later version. + */ + +#include +#include +#include +#include +#include +#include + +static int debug; +module_param(debug, int, 0644); + +#define MODULE_NAME"SR030PC30" + +/* + * Register offsets within a page + * b15..b8 - page id, b7..b0 - register address + */ +#define POWER_CTRL_REG 0x0001 +#define PAGEMODE_REG 0x03 +#define DEVICE_ID_REG 0x0004 +#define NOON010PC30_ID 0x86 +#define SR030PC30_ID 0x8C +#define VDO_CTL1_REG 0x0010 +#define SUBSAMPL_NONE_VGA 0 +#define SUBSAMPL_QVGA 0x10 +#define SUBSAMPL_QQVGA 0x20 +#define VDO_CTL2_REG 0x0011 +#define SYNC_CTL_REG 0x0012 +#define WIN_ROWH_REG 0x0020 +#define WIN_ROWL_REG 0x0021 +#define WIN_COLH_REG 0x0022 +#define WIN_COLL_REG 0x0023 +#define WIN_HEIGHTH_REG0x0024 +#define WIN_HEIGHTL_REG0x0025 +#define WIN_WIDTHH_REG 0x0026 +#define WIN_WIDTHL_REG 0x0027 +#define HBLANKH_REG0x0040 +#define HBLANKL_REG0x0041 +#define VSYNCH_REG 0x0042 +#define VSYNCL_REG 0x0043 +/* page 10 */ +#define ISP_CTL_REG(n) (0x1010 + (n)) +#define YOFS_REG 0x1040 +#define DARK_YOFS_REG 0x1041 +#define AG_ABRTH_REG 0x1050 +#define SAT_CTL_REG0x1060 +#define BSAT_REG 0x1061 +#define RSAT_REG 0x1062 +#define AG_SAT_TH_REG 0x1063 +/* page 11 */ +#define ZLPF_CTRL_REG 0x1110 +#define ZLPF_CTRL2_REG 0x1112 +#define ZLPF_AGH_THR_REG 0x1121 +#define ZLPF_THR_REG 0x1160 +#define ZLPF_DYN_THR_REG 0x1160 +
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
On Sun, Oct 10, 2010 at 1:33 PM, David Ellingsworth wrote: > Hans, > > On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: >> Hi Mauro, >> >> These are the locking patches. It's based on my previous test tree, but with >> more testing with em28xx and radio-mr800 and some small tweaks relating to >> disconnect handling and video_is_registered(). >> >> I also removed the unused get_unmapped_area file op and I am now blocking >> any further (unlocked_)ioctl calls after the device node is unregistered. >> The only things an application can do legally after a disconnect is unmap() >> and close(). >> >> This patch series also contains a small em28xx fix that I found while testing >> the em28xx BKL removal patch. >> >> Regards, >> >> Hans >> >> The following changes since commit dace3857de7a16b83ae7d4e13c94de8e4b267d2a: >> Hans Verkuil (1): >> V4L/DVB: tvaudio: remove obsolete tda8425 initialization >> >> are available in the git repository at: >> >> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl >> >> Hans Verkuil (10): >> v4l2-dev: after a disconnect any ioctl call will be blocked. >> v4l2-dev: remove get_unmapped_area >> v4l2: add core serialization lock. >> videobuf: prepare to make locking optional in videobuf >> videobuf: add ext_lock argument to the queue init functions >> videobuf: add queue argument to videobuf_waiton() >> vivi: remove BKL. >> em28xx: remove BKL. >> em28xx: the default std was not passed on to the subdevs >> radio-mr800: remove BKL > > Did you even test these patches? The last one in the series clearly > breaks radio-mr800 and the commit message does not describe the > changes made. radio-mr800 has been BKL independent for quite some > time. Hans, you of all people should know that calling > video_unregister_device could result in the driver specific structure > being freed. The mutex must therefore be unlocked _before_ calling > video_unregister_device. Otherwise you're passing freed memory to > mutex_unlock in usb_amradio_disconnect. > To reiterate, the video_device struct is part of the amradio_device struct. When video_device_unregister is called, it can cause the release callback of the video_device struct to be called. In this case, that results in usb_amradio_video_device_release being called which frees the amradio_device struct. Therefore any use of the amradio_device struct after calling video_device_unregister is a potential use after free error. In this particular case you are trying to access the amradio_device.lock member which has potentially been freed already. Regards, David Ellingsworth -- 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: OMAP 3530 camera ISP forks and new media framework
2010/10/11 Laurent Pinchart : > Hi Bastian, > > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: >> So... let's see if i got some things right, please let me now if you >> disagree: >> >> - I do want to use the omap34xxcam.c driver as it is for the newest >> framework and I get most support for it > > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist > anymore :-) Nice :S I think I take the mt9t001 approach (Sorry Guennadi, I think modifying your framework is too much for me to start with). So in this driver I tell the framework that I can do i2c probing, some subdev_core_ops and some subdev_video_ops. I define these functions that mostly do some basic i2c communication to the sensor chip. I guess I can handle that as there are so many examples out there. But where do I stack that on top? On the camera bridge host, but if it isn't omap34xxcam, which driver can I use? How are they connected? Thanks, Bastian -- 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: OMAP 3530 camera ISP forks and new media framework
Hi Bastian, On Monday 11 October 2010 16:58:35 Bastian Hecht wrote: > 2010/10/11 Laurent Pinchart : > > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: > >> So... let's see if i got some things right, please let me now if you > >> disagree: > >> > >> - I do want to use the omap34xxcam.c driver as it is for the newest > >> framework and I get most support for it > > > > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist > > anymore :-) > > Nice :S > > I think I take the mt9t001 approach (Sorry Guennadi, I think modifying > your framework is too much for me to start with). So in this driver I > tell the framework that I can do i2c probing, some subdev_core_ops and > some subdev_video_ops. I define these functions that mostly do some > basic i2c communication to the sensor chip. I guess I can handle that > as there are so many examples out there. The best solution would be to add mt9p031 support to the mt9t001 driver. If that's too difficult to start with, you can copy mt9t001 to mt9p031 and modify the driver as needed and merge the two drivers when you will be satisfied with the result. > But where do I stack that on top? On the camera bridge host, but if it > isn't omap34xxcam, which driver can I use? How are they connected? http://gitorious.org/maemo-multimedia/omap3isp-rx51 The omap34xxcam.ko and isp-mod.ko modules have been merged into a single omap3-isp.ko module. All the driver code is now in drivers/media/video/isp. -- 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: OMAP 3530 camera ISP forks and new media framework
On Mon, 11 Oct 2010, Bastian Hecht wrote: > 2010/10/11 Laurent Pinchart : > > Hi Bastian, > > > > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: > >> So... let's see if i got some things right, please let me now if you > >> disagree: > >> > >> - I do want to use the omap34xxcam.c driver as it is for the newest > >> framework and I get most support for it > > > > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist > > anymore :-) > > Nice :S > > I think I take the mt9t001 approach (Sorry Guennadi, I think modifying > your framework is too much for me to start with). AFAIR, you said, that register sets of mt9t031 and mt9p031 are identical, so, I think, I will be against mainlining a new driver for the "same" hardware for the pad-level ops, duplicating an soc-camera driver. Apart from creating a one-off redundancy, this looks like an extremely negative precedent to me. That said, please, double check your estimate as "identical." If there are differences, say, even in only 10% of registers, it might still be justified to make a new driver. mt9m001 and mt9t031 are also "very similar," still, it appeared to me at that time, that a new driver would be cleaner, than a single driver full of forks or other indirections. Thanks Guennadi > So in this driver I > tell the framework that I can do i2c probing, some subdev_core_ops and > some subdev_video_ops. I define these functions that mostly do some > basic i2c communication to the sensor chip. I guess I can handle that > as there are so many examples out there. > > But where do I stack that on top? On the camera bridge host, but if it > isn't omap34xxcam, which driver can I use? How are they connected? > > Thanks, > > Bastian > --- 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] viafb camera controller driver
On Mon, 11 Oct 2010 14:18:55 +0200
Laurent Pinchart wrote:
> > +static __devexit int viacam_remove(struct platform_device *pdev)
> > +{
> > + struct via_camera *cam = via_cam_info;
>
> And use it here.
>
> Just call platform_set_drvdata(pdev, cam) in viacam_probe to store the struct
> via_camera pointer in the platform device, and platform_get_drvdata(pdev)
> here
> to retrieve it.
Yes, I know...but the fix isn't quite that simple because the platform
data is already used elsewhere. What's needed is some sort of "viafb
subdevice instance" structure which can keep all of the pointers
together. My plan is to do that, but it will require via-core changes
and I just don't have time for that right now.
Can I get away with this (it will cause no real-world trouble) with a
promise of a fix in the next month or two? I have some other via-core
stuff (suspend/resume in particular) that I need to do anyway.
Thanks,
jon
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] tm6000 locking fixes
There are a number of locking issues at tm6000 driver. This series fixes those locking issues. After them, both mplayer and tvtime are not causing panic/oops, even if I call it via a remote machine. Unfortunately, my HVR-900H died (probably due to overheat), so I can't test anymore the tm6010 alsa fixes, but, on the tests I did with tm6000, the start/stop of audio is not causing OOPS/Panic anymore (yet, some extra init is needed for tm6000 to have audio). Mauro Carvalho Chehab (4): tm6000: don't use BKL at the driver V4L/DVB: tm6000-alsa: fix some locking issues V4L/DVB: Use just one lock for devlist V4L/DVB: tm6000: fix resource locking drivers/media/video/cx231xx/cx231xx-cards.c |2 + drivers/staging/tm6000/tm6000-alsa.c| 46 +--- drivers/staging/tm6000/tm6000-cards.c |3 - drivers/staging/tm6000/tm6000-core.c| 15 ++ drivers/staging/tm6000/tm6000-video.c | 77 +-- drivers/staging/tm6000/tm6000.h |7 ++- 6 files changed, 98 insertions(+), 52 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/4] tm6000: don't use BKL at the driver
Instead, use core lock handling.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/staging/tm6000/tm6000-cards.c
b/drivers/staging/tm6000/tm6000-cards.c
index 9d091c3..4106ae0 100644
--- a/drivers/staging/tm6000/tm6000-cards.c
+++ b/drivers/staging/tm6000/tm6000-cards.c
@@ -909,8 +909,6 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
printk(KERN_INFO "tm6000: disconnecting %s\n", dev->name);
- mutex_lock(&dev->lock);
-
tm6000_ir_fini(dev);
if (dev->gpio.power_led) {
@@ -945,7 +943,6 @@ static void tm6000_usb_disconnect(struct usb_interface
*interface)
tm6000_close_extension(dev);
tm6000_remove_from_devlist(dev);
- mutex_unlock(&dev->lock);
kfree(dev);
}
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index 57cb69e..f5f8632 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -326,10 +326,8 @@ int tm6000_init_analog_mode(struct tm6000_core *dev)
/*FIXME: Hack!!! */
struct v4l2_frequency f;
- mutex_lock(&dev->lock);
f.frequency = dev->freq;
v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_frequency, &f);
- mutex_unlock(&dev->lock);
msleep(100);
tm6000_set_standard(dev, &dev->norm);
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index a45b012..23c85fd 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -791,16 +791,11 @@ static struct videobuf_queue_ops tm6000_video_qops = {
static int res_get(struct tm6000_core *dev, struct tm6000_fh *fh)
{
/* is it free? */
- mutex_lock(&dev->lock);
- if (dev->resources) {
- /* no, someone else uses it */
- mutex_unlock(&dev->lock);
+ if (dev->resources)
return 0;
- }
/* it's free, grab it */
dev->resources =1;
dprintk(dev, V4L2_DEBUG_RES_LOCK, "res: get\n");
- mutex_unlock(&dev->lock);
return 1;
}
@@ -811,10 +806,8 @@ static int res_locked(struct tm6000_core *dev)
static void res_free(struct tm6000_core *dev, struct tm6000_fh *fh)
{
- mutex_lock(&dev->lock);
dev->resources = 0;
dprintk(dev, V4L2_DEBUG_RES_LOCK, "res: put\n");
- mutex_unlock(&dev->lock);
}
/* --
@@ -1229,10 +1222,8 @@ static int vidioc_s_frequency (struct file *file, void
*priv,
if (unlikely(f->tuner != 0))
return -EINVAL;
-// mutex_lock(&dev->lock);
dev->freq = f->frequency;
v4l2_device_call_all(&dev->v4l2_dev, 0, tuner, s_frequency, f);
-// mutex_unlock(&dev->lock);
return 0;
}
@@ -1308,7 +1299,7 @@ static int tm6000_open(struct file *file)
NULL, &dev->slock,
fh->type,
V4L2_FIELD_INTERLACED,
- sizeof(struct tm6000_buffer), fh, NULL);
+ sizeof(struct tm6000_buffer), fh, &dev->lock);
return 0;
}
@@ -1389,7 +1380,7 @@ static struct v4l2_file_operations tm6000_fops = {
.owner = THIS_MODULE,
.open = tm6000_open,
.release= tm6000_release,
- .ioctl = video_ioctl2, /* V4L2 ioctl handler */
+ .unlocked_ioctl = video_ioctl2, /* V4L2 ioctl handler */
.read = tm6000_read,
.poll = tm6000_poll,
.mmap = tm6000_mmap,
@@ -1451,8 +1442,10 @@ int tm6000_v4l2_register(struct tm6000_core *dev)
INIT_LIST_HEAD(&dev->vidq.active);
INIT_LIST_HEAD(&dev->vidq.queued);
- memcpy (dev->vfd, &tm6000_template, sizeof(*(dev->vfd)));
- dev->vfd->debug=tm6000_debug;
+ memcpy(dev->vfd, &tm6000_template, sizeof(*(dev->vfd)));
+ dev->vfd->debug = tm6000_debug;
+ dev->vfd->lock = &dev->lock;
+
vfd->v4l2_dev = &dev->v4l2_dev;
video_set_drvdata(vfd, dev);
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: > Hans, > > On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: > > Hi Mauro, > > > > These are the locking patches. It's based on my previous test tree, but with > > more testing with em28xx and radio-mr800 and some small tweaks relating to > > disconnect handling and video_is_registered(). > > > > I also removed the unused get_unmapped_area file op and I am now blocking > > any further (unlocked_)ioctl calls after the device node is unregistered. > > The only things an application can do legally after a disconnect is unmap() > > and close(). > > > > This patch series also contains a small em28xx fix that I found while > > testing > > the em28xx BKL removal patch. > > > > Regards, > > > >Hans > > > > The following changes since commit dace3857de7a16b83ae7d4e13c94de8e4b267d2a: > > Hans Verkuil (1): > >V4L/DVB: tvaudio: remove obsolete tda8425 initialization > > > > are available in the git repository at: > > > > ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl > > > > Hans Verkuil (10): > > v4l2-dev: after a disconnect any ioctl call will be blocked. > > v4l2-dev: remove get_unmapped_area > > v4l2: add core serialization lock. > > videobuf: prepare to make locking optional in videobuf > > videobuf: add ext_lock argument to the queue init functions > > videobuf: add queue argument to videobuf_waiton() > > vivi: remove BKL. > > em28xx: remove BKL. > > em28xx: the default std was not passed on to the subdevs > > radio-mr800: remove BKL > > Did you even test these patches? Yes, I did test. And it works for me. But you are correct in that it shouldn't work since the struct will indeed be freed. I'll fix this and post a patch. I'm not sure why it works fine when I test it. There is a problem as well with unlocking before unregistering the device in that it leaves a race condition where another app can open the device again before it is registered. I have to think about that some more. > The last one in the series clearly > breaks radio-mr800 and the commit message does not describe the > changes made. radio-mr800 has been BKL independent for quite some > time. Hans, you of all people should know that calling > video_unregister_device could result in the driver specific structure > being freed. Jeez, relax. I'm human (really!). > The mutex must therefore be unlocked _before_ calling > video_unregister_device. Otherwise you're passing freed memory to > mutex_unlock in usb_amradio_disconnect. > > If each patch had been properly posted to the list, others might have > caught issues like this earlier. Posting a link to a repository is no > substitute for this process. > > Mauro, you should be ashamed for accepting a series that obviously has issues. Hardly obvious, and definitely not his fault. Regards, Hans > > Regards, > > David Ellingsworth > > -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] V4L/DVB: tm6000-alsa: fix some locking issues
Those locking issues affect tvtime, causing a kernel oops/panic, due to
a race condition.
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/media/video/cx231xx/cx231xx-cards.c
b/drivers/media/video/cx231xx/cx231xx-cards.c
index c4cfcab..9c3a926 100644
--- a/drivers/media/video/cx231xx/cx231xx-cards.c
+++ b/drivers/media/video/cx231xx/cx231xx-cards.c
@@ -462,6 +462,8 @@ struct usb_device_id cx231xx_id_table[] = {
.driver_info = CX231XX_BOARD_HAUPPAUGE_USBLIVE2},
{USB_DEVICE_VER(USB_VID_PIXELVIEW, USB_PID_PIXELVIEW_SBTVD, 0x4000,
0x4001),
.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
+ {USB_DEVICE(0x1b80, 0xe424),
+.driver_info = CX231XX_BOARD_PV_PLAYTV_USB_HYBRID},
{},
};
diff --git a/drivers/staging/tm6000/tm6000-alsa.c
b/drivers/staging/tm6000/tm6000-alsa.c
index a99101f..e379e3e 100644
--- a/drivers/staging/tm6000/tm6000-alsa.c
+++ b/drivers/staging/tm6000/tm6000-alsa.c
@@ -201,6 +201,14 @@ _error:
*/
static int snd_tm6000_close(struct snd_pcm_substream *substream)
{
+ struct snd_tm6000_card *chip = snd_pcm_substream_chip(substream);
+ struct tm6000_core *core = chip->core;
+
+ if (atomic_read(&core->stream_started) > 0) {
+ atomic_set(&core->stream_started, 0);
+ schedule_work(&core->wq_trigger);
+ }
+
return 0;
}
@@ -213,6 +221,9 @@ static int tm6000_fillbuf(struct tm6000_core *core, char
*buf, int size)
unsigned int stride, buf_pos;
int length;
+ if (atomic_read(&core->stream_started) == 0)
+ return 0;
+
if (!size || !substream) {
dprintk(1, "substream was NULL\n");
return -EINVAL;
@@ -298,8 +309,12 @@ static int snd_tm6000_hw_params(struct snd_pcm_substream
*substream,
static int snd_tm6000_hw_free(struct snd_pcm_substream *substream)
{
struct snd_tm6000_card *chip = snd_pcm_substream_chip(substream);
+ struct tm6000_core *core = chip->core;
- _tm6000_stop_audio_dma(chip);
+ if (atomic_read(&core->stream_started) > 0) {
+ atomic_set(&core->stream_started, 0);
+ schedule_work(&core->wq_trigger);
+ }
return 0;
}
@@ -321,30 +336,42 @@ static int snd_tm6000_prepare(struct snd_pcm_substream
*substream)
/*
* trigger callback
*/
+static void audio_trigger(struct work_struct *work)
+{
+ struct tm6000_core *core = container_of(work, struct tm6000_core,
+ wq_trigger);
+ struct snd_tm6000_card *chip = core->adev;
+
+ if (atomic_read(&core->stream_started)) {
+ dprintk(1, "starting capture");
+ _tm6000_start_audio_dma(chip);
+ } else {
+ dprintk(1, "stopping capture");
+ _tm6000_stop_audio_dma(chip);
+ }
+}
+
static int snd_tm6000_card_trigger(struct snd_pcm_substream *substream, int
cmd)
{
struct snd_tm6000_card *chip = snd_pcm_substream_chip(substream);
- int err;
-
- spin_lock(&chip->reg_lock);
+ struct tm6000_core *core = chip->core;
+ int err = 0;
switch (cmd) {
case SNDRV_PCM_TRIGGER_START:
- err = _tm6000_start_audio_dma(chip);
+ atomic_set(&core->stream_started, 1);
break;
case SNDRV_PCM_TRIGGER_STOP:
- err = _tm6000_stop_audio_dma(chip);
+ atomic_set(&core->stream_started, 0);
break;
default:
err = -EINVAL;
break;
}
-
- spin_unlock(&chip->reg_lock);
+ schedule_work(&core->wq_trigger);
return err;
}
-
/*
* pointer callback
*/
@@ -437,6 +464,7 @@ int tm6000_audio_init(struct tm6000_core *dev)
snd_pcm_set_ops(pcm, SNDRV_PCM_STREAM_CAPTURE, &snd_tm6000_pcm_ops);
+ INIT_WORK(&dev->wq_trigger, audio_trigger);
rc = snd_card_register(card);
if (rc < 0)
goto error;
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 1ec1bff..5d9dcab 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -205,6 +205,9 @@ struct tm6000_core {
/* audio support */
struct snd_tm6000_card *adev;
+ struct work_struct wq_trigger; /* Trigger to start/stop
audio for alsa module */
+ atomic_tstream_started; /* stream should be
running if true */
+
struct tm6000_IR*ir;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[GIT PATCHES FOR 2.6.37] Fix locking order in radio-mr800
The following changes since commit 9147e3dbca0712a5435cd2ea7c48d39344f904eb: Mauro Carvalho Chehab (1): V4L/DVB: cx231xx: use core-assisted lock are available in the git repository at: ssh://linuxtv.org/git/hverkuil/v4l-dvb.git mr800 Hans Verkuil (1): radio-mr800: fix locking order Documentation/video4linux/v4l2-framework.txt |2 +- drivers/media/radio/radio-mr800.c|2 +- 2 files changed, 2 insertions(+), 2 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] V4L/DVB: Use just one lock for devlist
This avoids a race condition
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/staging/tm6000/tm6000-core.c
b/drivers/staging/tm6000/tm6000-core.c
index f5f8632..02c9c7c 100644
--- a/drivers/staging/tm6000/tm6000-core.c
+++ b/drivers/staging/tm6000/tm6000-core.c
@@ -657,7 +657,6 @@ void tm6000_add_into_devlist(struct tm6000_core *dev)
*/
static LIST_HEAD(tm6000_extension_devlist);
-static DEFINE_MUTEX(tm6000_extension_devlist_lock);
int tm6000_call_fillbuf(struct tm6000_core *dev, enum tm6000_ops_type type,
char *buf, int size)
@@ -681,14 +680,12 @@ int tm6000_register_extension(struct tm6000_ops *ops)
struct tm6000_core *dev = NULL;
mutex_lock(&tm6000_devlist_mutex);
- mutex_lock(&tm6000_extension_devlist_lock);
list_add_tail(&ops->next, &tm6000_extension_devlist);
list_for_each_entry(dev, &tm6000_devlist, devlist) {
ops->init(dev);
printk(KERN_INFO "%s: Initialized (%s) extension\n",
dev->name, ops->name);
}
- mutex_unlock(&tm6000_extension_devlist_lock);
mutex_unlock(&tm6000_devlist_mutex);
return 0;
}
@@ -704,10 +701,8 @@ void tm6000_unregister_extension(struct tm6000_ops *ops)
ops->fini(dev);
}
- mutex_lock(&tm6000_extension_devlist_lock);
printk(KERN_INFO "tm6000: Remove (%s) extension\n", ops->name);
list_del(&ops->next);
- mutex_unlock(&tm6000_extension_devlist_lock);
mutex_unlock(&tm6000_devlist_mutex);
}
EXPORT_SYMBOL(tm6000_unregister_extension);
@@ -716,26 +711,26 @@ void tm6000_init_extension(struct tm6000_core *dev)
{
struct tm6000_ops *ops = NULL;
- mutex_lock(&tm6000_extension_devlist_lock);
+ mutex_lock(&tm6000_devlist_mutex);
if (!list_empty(&tm6000_extension_devlist)) {
list_for_each_entry(ops, &tm6000_extension_devlist, next) {
if (ops->init)
ops->init(dev);
}
}
- mutex_unlock(&tm6000_extension_devlist_lock);
+ mutex_unlock(&tm6000_devlist_mutex);
}
void tm6000_close_extension(struct tm6000_core *dev)
{
struct tm6000_ops *ops = NULL;
- mutex_lock(&tm6000_extension_devlist_lock);
+ mutex_lock(&tm6000_devlist_mutex);
if (!list_empty(&tm6000_extension_devlist)) {
list_for_each_entry(ops, &tm6000_extension_devlist, next) {
if (ops->fini)
ops->fini(dev);
}
}
- mutex_unlock(&tm6000_extension_devlist_lock);
+ mutex_lock(&tm6000_devlist_mutex);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] V4L/DVB: tm6000: fix resource locking
Signed-off-by: Mauro Carvalho Chehab
diff --git a/drivers/staging/tm6000/tm6000-video.c
b/drivers/staging/tm6000/tm6000-video.c
index 23c85fd..f184585 100644
--- a/drivers/staging/tm6000/tm6000-video.c
+++ b/drivers/staging/tm6000/tm6000-video.c
@@ -788,25 +788,49 @@ static struct videobuf_queue_ops tm6000_video_qops = {
IOCTL handling
--*/
-static int res_get(struct tm6000_core *dev, struct tm6000_fh *fh)
+static bool is_res_read(struct tm6000_core *dev, struct tm6000_fh *fh)
{
+ /* Is the current fh handling it? if so, that's OK */
+ if (dev->resources == fh && dev->is_res_read)
+ return true;
+
+ return false;
+}
+
+static bool is_res_streaming(struct tm6000_core *dev, struct tm6000_fh *fh)
+{
+ /* Is the current fh handling it? if so, that's OK */
+ if (dev->resources == fh)
+ return true;
+
+ return false;
+}
+
+static bool res_get(struct tm6000_core *dev, struct tm6000_fh *fh,
+ bool is_res_read)
+{
+ /* Is the current fh handling it? if so, that's OK */
+ if (dev->resources == fh && dev->is_res_read == is_res_read)
+ return true;
+
/* is it free? */
if (dev->resources)
- return 0;
- /* it's free, grab it */
- dev->resources =1;
+ return false;
+
+ /* grab it */
+ dev->resources = fh;
+ dev->is_res_read = is_res_read;
dprintk(dev, V4L2_DEBUG_RES_LOCK, "res: get\n");
- return 1;
-}
-
-static int res_locked(struct tm6000_core *dev)
-{
- return (dev->resources);
+ return true;
}
static void res_free(struct tm6000_core *dev, struct tm6000_fh *fh)
{
- dev->resources = 0;
+ /* Is the current fh handling it? if so, that's OK */
+ if (dev->resources != fh)
+ return;
+
+ dev->resources = NULL;
dprintk(dev, V4L2_DEBUG_RES_LOCK, "res: put\n");
}
@@ -981,7 +1005,7 @@ static int vidioc_streamon(struct file *file, void *priv,
enum v4l2_buf_type i)
if (i != fh->type)
return -EINVAL;
- if (!res_get(dev,fh))
+ if (!res_get(dev, fh, false))
return -EBUSY;
return (videobuf_streamon(&fh->vb_vidq));
}
@@ -1310,7 +1334,7 @@ tm6000_read(struct file *file, char __user *data, size_t
count, loff_t *pos)
struct tm6000_fh*fh = file->private_data;
if (fh->type==V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (res_locked(fh->dev))
+ if (!res_get(fh->dev, fh, true))
return -EBUSY;
return videobuf_read_stream(&fh->vb_vidq, data, count, pos, 0,
@@ -1328,7 +1352,10 @@ tm6000_poll(struct file *file, struct poll_table_struct
*wait)
if (V4L2_BUF_TYPE_VIDEO_CAPTURE != fh->type)
return POLLERR;
- if (res_get(fh->dev,fh)) {
+ if (!!is_res_streaming(fh->dev, fh))
+ return POLLERR;
+
+ if (!is_res_read(fh->dev, fh)) {
/* streaming capture */
if (list_empty(&fh->vb_vidq.stream))
return POLLERR;
@@ -1356,6 +1383,7 @@ static int tm6000_release(struct file *file)
dev->users--;
+ res_free(dev, fh);
if (!dev->users) {
tm6000_uninit_isoc(dev);
videobuf_mmap_free(&fh->vb_vidq);
diff --git a/drivers/staging/tm6000/tm6000.h b/drivers/staging/tm6000/tm6000.h
index 5d9dcab..a1c6ca2 100644
--- a/drivers/staging/tm6000/tm6000.h
+++ b/drivers/staging/tm6000/tm6000.h
@@ -189,7 +189,9 @@ struct tm6000_core {
int users;
/* various device info */
- unsigned intresources;
+ struct tm6000_fh*resources; /* Points to fh that is
streaming */
+ boolis_res_read;
+
struct video_device *vfd;
struct tm6000_dmaqueue vidq;
struct v4l2_device v4l2_dev;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
Em 11-10-2010 12:40, Hans Verkuil escreveu: > On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: >> Hans, >> >> On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: >>> Hi Mauro, >>> >>> These are the locking patches. It's based on my previous test tree, but with >>> more testing with em28xx and radio-mr800 and some small tweaks relating to >>> disconnect handling and video_is_registered(). >>> >>> I also removed the unused get_unmapped_area file op and I am now blocking >>> any further (unlocked_)ioctl calls after the device node is unregistered. >>> The only things an application can do legally after a disconnect is unmap() >>> and close(). >>> >>> This patch series also contains a small em28xx fix that I found while >>> testing >>> the em28xx BKL removal patch. >>> >>> Regards, >>> >>>Hans >>> >>> The following changes since commit dace3857de7a16b83ae7d4e13c94de8e4b267d2a: >>> Hans Verkuil (1): >>>V4L/DVB: tvaudio: remove obsolete tda8425 initialization >>> >>> are available in the git repository at: >>> >>> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl >>> >>> Hans Verkuil (10): >>> v4l2-dev: after a disconnect any ioctl call will be blocked. >>> v4l2-dev: remove get_unmapped_area >>> v4l2: add core serialization lock. >>> videobuf: prepare to make locking optional in videobuf >>> videobuf: add ext_lock argument to the queue init functions >>> videobuf: add queue argument to videobuf_waiton() >>> vivi: remove BKL. >>> em28xx: remove BKL. >>> em28xx: the default std was not passed on to the subdevs >>> radio-mr800: remove BKL >> >> Did you even test these patches? > > Yes, I did test. And it works for me. But you are correct in that it shouldn't > work since the struct will indeed be freed. I'll fix this and post a patch. > > I'm not sure why it works fine when I test it. > > There is a problem as well with unlocking before unregistering the device in > that it leaves a race condition where another app can open the device again > before it is registered. I have to think about that some more. > >> The last one in the series clearly >> breaks radio-mr800 and the commit message does not describe the >> changes made. radio-mr800 has been BKL independent for quite some >> time. Hans, you of all people should know that calling >> video_unregister_device could result in the driver specific structure >> being freed. > > Jeez, relax. I'm human (really!). > >> The mutex must therefore be unlocked _before_ calling >> video_unregister_device. Otherwise you're passing freed memory to >> mutex_unlock in usb_amradio_disconnect. >> >> If each patch had been properly posted to the list, others might have >> caught issues like this earlier. Posting a link to a repository is no >> substitute for this process. >> >> Mauro, you should be ashamed for accepting a series that obviously has >> issues. > > Hardly obvious, and definitely not his fault. Hans, This is a somewhat recurring discussion at #v4l irc nowadays. Next time, please send your patch series first to the ML, tagged with [PATCH RFC] especially if they touch ondrivers that you're not the maintainer or when you weren't able to test. 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] gp8psk: fix tuner delay
People are still waiting for this to be applied. Any reason it hasn't been?
On Tue, Aug 17, 2010 at 10:34 AM, VDR User wrote:
> This patches adjusts the tuner delay to be longer in response to
> several users experiencing tuner timeouts. This change fixes that
> problem and allows those users to be able to tune.
>
> Signed-off-by: Derek Kelly
> --
> --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c
> 2010-08-17 09:53:27.0 -0700
> +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/gp8psk-fe.c 2010-08-17
> 10:00:28.0 -0700
> @@ -109,7 +109,7 @@ static int gp8psk_fe_read_signal_strengt
>
> static int gp8psk_fe_get_tune_settings(struct dvb_frontend* fe,
> struct dvb_frontend_tune_settings *tune)
> {
> - tune->min_delay_ms = 200;
> + tune->min_delay_ms = 800;
> return 0;
> }
>
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
On Monday, October 11, 2010 17:48:45 Mauro Carvalho Chehab wrote: > Em 11-10-2010 12:40, Hans Verkuil escreveu: > > On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: > >> Hans, > >> > >> On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: > >>> Hi Mauro, > >>> > >>> These are the locking patches. It's based on my previous test tree, but > >>> with > >>> more testing with em28xx and radio-mr800 and some small tweaks relating to > >>> disconnect handling and video_is_registered(). > >>> > >>> I also removed the unused get_unmapped_area file op and I am now blocking > >>> any further (unlocked_)ioctl calls after the device node is unregistered. > >>> The only things an application can do legally after a disconnect is > >>> unmap() > >>> and close(). > >>> > >>> This patch series also contains a small em28xx fix that I found while > >>> testing > >>> the em28xx BKL removal patch. > >>> > >>> Regards, > >>> > >>>Hans > >>> > >>> The following changes since commit > >>> dace3857de7a16b83ae7d4e13c94de8e4b267d2a: > >>> Hans Verkuil (1): > >>>V4L/DVB: tvaudio: remove obsolete tda8425 initialization > >>> > >>> are available in the git repository at: > >>> > >>> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl > >>> > >>> Hans Verkuil (10): > >>> v4l2-dev: after a disconnect any ioctl call will be blocked. > >>> v4l2-dev: remove get_unmapped_area > >>> v4l2: add core serialization lock. > >>> videobuf: prepare to make locking optional in videobuf > >>> videobuf: add ext_lock argument to the queue init functions > >>> videobuf: add queue argument to videobuf_waiton() > >>> vivi: remove BKL. > >>> em28xx: remove BKL. > >>> em28xx: the default std was not passed on to the subdevs > >>> radio-mr800: remove BKL > >> > >> Did you even test these patches? > > > > Yes, I did test. And it works for me. But you are correct in that it > > shouldn't > > work since the struct will indeed be freed. I'll fix this and post a patch. > > > > I'm not sure why it works fine when I test it. > > > > There is a problem as well with unlocking before unregistering the device in > > that it leaves a race condition where another app can open the device again > > before it is registered. I have to think about that some more. > > > >> The last one in the series clearly > >> breaks radio-mr800 and the commit message does not describe the > >> changes made. radio-mr800 has been BKL independent for quite some > >> time. Hans, you of all people should know that calling > >> video_unregister_device could result in the driver specific structure > >> being freed. > > > > Jeez, relax. I'm human (really!). > > > >> The mutex must therefore be unlocked _before_ calling > >> video_unregister_device. Otherwise you're passing freed memory to > >> mutex_unlock in usb_amradio_disconnect. > >> > >> If each patch had been properly posted to the list, others might have > >> caught issues like this earlier. Posting a link to a repository is no > >> substitute for this process. > >> > >> Mauro, you should be ashamed for accepting a series that obviously has > >> issues. > > > > Hardly obvious, and definitely not his fault. > > Hans, > > This is a somewhat recurring discussion at #v4l irc nowadays. Next time, > please > send your patch series first to the ML, tagged with [PATCH RFC] especially if > they > touch ondrivers that you're not the maintainer or when you weren't able to > test. So this is the new policy? Post with [PATCH RFC], wait a few days, then post a git pull request? Should I also do this for long but mechanical conversions like the 'video_device' to 'v4l2_devnode'rename patch series? I think posting that would be spamming the list. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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] gp8psk: Add support for the Genpix Skywalker-2
People are still waiting for this to be applied. Any reason it hasn't been?
On Tue, Aug 17, 2010 at 10:56 AM, VDR User wrote:
> gp8psk: Add support for the Genpix Skywalker-2 per user requests.
>
> Patched against v4l-dvb hg ab433502e041 tip. Should patch fine
> against git as well.
>
> Signed-off-by: Derek Kelly
> --
> diff -pruN v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2010-08-17 09:53:27.0 -0700
> +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h
> 2010-08-17 10:38:48.0 -0700
> @@ -267,6 +267,7 @@
> #define USB_PID_GENPIX_8PSK_REV_2 0x0202
> #define USB_PID_GENPIX_SKYWALKER_1 0x0203
> #define USB_PID_GENPIX_SKYWALKER_CW3K 0x0204
> +#define USB_PID_GENPIX_SKYWALKER_2 0x0206
> #define USB_PID_SIGMATEK_DVB_110 0x6610
> #define USB_PID_MSI_DIGI_VOX_MINI_II 0x1513
> #define USB_PID_MSI_DIGIVOX_DUO 0x8801
> diff -pruN v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/gp8psk.c
> v4l-dvb/linux/drivers/media/dvb/dvb-usb/gp8psk.c
> --- v4l-dvb.orig/linux/drivers/media/dvb/dvb-usb/gp8psk.c
> 2010-08-17 09:53:27.0 -0700
> +++ v4l-dvb/linux/drivers/media/dvb/dvb-usb/gp8psk.c 2010-08-17
> 10:42:33.0 -0700
> @@ -227,6 +227,7 @@ static struct usb_device_id gp8psk_usb_t
> { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_8PSK_REV_1_WARM) },
> { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_8PSK_REV_2) },
> { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_SKYWALKER_1) },
> + { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_SKYWALKER_2) },
> /* { USB_DEVICE(USB_VID_GENPIX, USB_PID_GENPIX_SKYWALKER_CW3K) }, */
> { 0 },
> };
> @@ -258,7 +259,7 @@ static struct dvb_usb_device_properties
>
> .generic_bulk_ctrl_endpoint = 0x01,
>
> - .num_device_descs = 3,
> + .num_device_descs = 4,
> .devices = {
> { .name = "Genpix 8PSK-to-USB2 Rev.1 DVB-S receiver",
> .cold_ids = { &gp8psk_usb_table[0], NULL },
> @@ -272,10 +273,14 @@ static struct dvb_usb_device_properties
> .cold_ids = { NULL },
> .warm_ids = { &gp8psk_usb_table[3], NULL },
> },
> + { .name = "Genpix SkyWalker-2 DVB-S receiver",
> + .cold_ids = { NULL },
> + .warm_ids = { &gp8psk_usb_table[4], NULL },
> + },
> #if 0
> { .name = "Genpix SkyWalker-CW3K DVB-S receiver",
> .cold_ids = { NULL },
> - .warm_ids = { &gp8psk_usb_table[4], NULL },
> + .warm_ids = { &gp8psk_usb_table[5], NULL },
> },
> #endif
> { NULL },
>
--
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: OMAP 3530 camera ISP forks and new media framework
2010/10/11 Guennadi Liakhovetski : > On Mon, 11 Oct 2010, Bastian Hecht wrote: > >> 2010/10/11 Laurent Pinchart : >> > Hi Bastian, >> > >> > On Monday 11 October 2010 14:59:15 Bastian Hecht wrote: >> >> So... let's see if i got some things right, please let me now if you >> >> disagree: >> >> >> >> - I do want to use the omap34xxcam.c driver as it is for the newest >> >> framework and I get most support for it >> > >> > That's a bad start. With the latest driver, omap34xxcam.c doesn't exist >> > anymore :-) >> >> Nice :S >> >> I think I take the mt9t001 approach (Sorry Guennadi, I think modifying >> your framework is too much for me to start with). > > AFAIR, you said, that register sets of mt9t031 and mt9p031 are identical, > so, I think, I will be against mainlining a new driver for the "same" > hardware for the pad-level ops, duplicating an soc-camera driver. Apart > from creating a one-off redundancy, this looks like an extremely negative > precedent to me. > > That said, please, double check your estimate as "identical." If there are > differences, say, even in only 10% of registers, it might still be > justified to make a new driver. mt9m001 and mt9t031 are also "very > similar," still, it appeared to me at that time, that a new driver would > be cleaner, than a single driver full of forks or other indirections. > > Thanks > Guennadi > The point is, I will jump around my office for a full day when I get out a single picture of my camera PCB. After that I will gladly work towards uncluttering the driver duplication. I will see if it fits better the mt9t001 or mt9t031 and integrate it in there. Cheers, Bastian >> So in this driver I >> tell the framework that I can do i2c probing, some subdev_core_ops and >> some subdev_video_ops. I define these functions that mostly do some >> basic i2c communication to the sensor chip. I guess I can handle that >> as there are so many examples out there. >> >> But where do I stack that on top? On the camera bridge host, but if it >> isn't omap34xxcam, which driver can I use? How are they connected? >> >> Thanks, >> >> Bastian >> > > --- > 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: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
Hi Hans, On Monday 11 October 2010 17:54:07 Hans Verkuil wrote: > On Monday, October 11, 2010 17:48:45 Mauro Carvalho Chehab wrote: > > Em 11-10-2010 12:40, Hans Verkuil escreveu: > > > On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: > > >> Hans, > > >> > > >> On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: > > >>> Hi Mauro, > > >>> > > >>> These are the locking patches. It's based on my previous test tree, > > >>> but with more testing with em28xx and radio-mr800 and some small > > >>> tweaks relating to disconnect handling and video_is_registered(). > > >>> > > >>> I also removed the unused get_unmapped_area file op and I am now > > >>> blocking any further (unlocked_)ioctl calls after the device node is > > >>> unregistered. The only things an application can do legally after a > > >>> disconnect is unmap() and close(). > > >>> > > >>> This patch series also contains a small em28xx fix that I found while > > >>> testing the em28xx BKL removal patch. > > >>> > > >>> Regards, > > >>> > > >>>Hans > > >>> > > >>> The following changes since commit dace3857de7a16b83ae7d4e13c94de8e4b267d2a: > > >>> Hans Verkuil (1): > > >>>V4L/DVB: tvaudio: remove obsolete tda8425 initialization > > >>> > > >>> are available in the git repository at: > > >>> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl > > >>> > > >>> Hans Verkuil (10): > > >>> v4l2-dev: after a disconnect any ioctl call will be blocked. > > >>> v4l2-dev: remove get_unmapped_area > > >>> v4l2: add core serialization lock. > > >>> videobuf: prepare to make locking optional in videobuf > > >>> videobuf: add ext_lock argument to the queue init functions > > >>> videobuf: add queue argument to videobuf_waiton() > > >>> vivi: remove BKL. > > >>> em28xx: remove BKL. > > >>> em28xx: the default std was not passed on to the subdevs > > >>> radio-mr800: remove BKL > > >> > > >> Did you even test these patches? > > > > > > Yes, I did test. And it works for me. But you are correct in that it > > > shouldn't work since the struct will indeed be freed. I'll fix this > > > and post a patch. > > > > > > I'm not sure why it works fine when I test it. > > > > > > There is a problem as well with unlocking before unregistering the > > > device in that it leaves a race condition where another app can open > > > the device again before it is registered. I have to think about that > > > some more. > > > > > >> The last one in the series clearly > > >> breaks radio-mr800 and the commit message does not describe the > > >> changes made. radio-mr800 has been BKL independent for quite some > > >> time. Hans, you of all people should know that calling > > >> video_unregister_device could result in the driver specific structure > > >> being freed. > > > > > > Jeez, relax. I'm human (really!). > > > > > >> The mutex must therefore be unlocked _before_ calling > > >> video_unregister_device. Otherwise you're passing freed memory to > > >> mutex_unlock in usb_amradio_disconnect. > > >> > > >> If each patch had been properly posted to the list, others might have > > >> caught issues like this earlier. Posting a link to a repository is no > > >> substitute for this process. > > >> > > >> Mauro, you should be ashamed for accepting a series that obviously has > > >> issues. > > > > > > Hardly obvious, and definitely not his fault. > > > > Hans, > > > > This is a somewhat recurring discussion at #v4l irc nowadays. Next time, > > please send your patch series first to the ML, tagged with [PATCH RFC] > > especially if they touch ondrivers that you're not the maintainer or > > when you weren't able to test. > > So this is the new policy? Post with [PATCH RFC], wait a few days, then > post a git pull request? That's a new policy under discussion. I think it's worth being discussed a bit more. http://www.linuxtv.org/irc/v4l/index.php?date=2010-10-01 and http://www.linuxtv.org/irc/v4l/index.php?date=2010-10-11 if you want to catch up with the informal discussion. > Should I also do this for long but mechanical conversions like the > 'video_device' to 'v4l2_devnode'rename patch series? I think posting that > would be spamming the list. -- 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: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
Em 11-10-2010 13:23, Laurent Pinchart escreveu: > Hi Hans, > > On Monday 11 October 2010 17:54:07 Hans Verkuil wrote: >> On Monday, October 11, 2010 17:48:45 Mauro Carvalho Chehab wrote: >>> Em 11-10-2010 12:40, Hans Verkuil escreveu: On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: > Hans, > > On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil > wrote: >> Hi Mauro, >> >> These are the locking patches. It's based on my previous test tree, >> but with more testing with em28xx and radio-mr800 and some small >> tweaks relating to disconnect handling and video_is_registered(). >> >> I also removed the unused get_unmapped_area file op and I am now >> blocking any further (unlocked_)ioctl calls after the device node is >> unregistered. The only things an application can do legally after a >> disconnect is unmap() and close(). >> >> This patch series also contains a small em28xx fix that I found while >> testing the em28xx BKL removal patch. >> >> Regards, >> >>Hans >> >> The following changes since commit > dace3857de7a16b83ae7d4e13c94de8e4b267d2a: >> Hans Verkuil (1): >>V4L/DVB: tvaudio: remove obsolete tda8425 initialization >> >> are available in the git repository at: >> ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl >> >> Hans Verkuil (10): >> v4l2-dev: after a disconnect any ioctl call will be blocked. >> v4l2-dev: remove get_unmapped_area >> v4l2: add core serialization lock. >> videobuf: prepare to make locking optional in videobuf >> videobuf: add ext_lock argument to the queue init functions >> videobuf: add queue argument to videobuf_waiton() >> vivi: remove BKL. >> em28xx: remove BKL. >> em28xx: the default std was not passed on to the subdevs >> radio-mr800: remove BKL > > Did you even test these patches? Yes, I did test. And it works for me. But you are correct in that it shouldn't work since the struct will indeed be freed. I'll fix this and post a patch. I'm not sure why it works fine when I test it. There is a problem as well with unlocking before unregistering the device in that it leaves a race condition where another app can open the device again before it is registered. I have to think about that some more. > The last one in the series clearly > breaks radio-mr800 and the commit message does not describe the > changes made. radio-mr800 has been BKL independent for quite some > time. Hans, you of all people should know that calling > video_unregister_device could result in the driver specific structure > being freed. Jeez, relax. I'm human (really!). > The mutex must therefore be unlocked _before_ calling > video_unregister_device. Otherwise you're passing freed memory to > mutex_unlock in usb_amradio_disconnect. > > If each patch had been properly posted to the list, others might have > caught issues like this earlier. Posting a link to a repository is no > substitute for this process. > > Mauro, you should be ashamed for accepting a series that obviously has > issues. Hardly obvious, and definitely not his fault. >>> >>> Hans, >>> >>> This is a somewhat recurring discussion at #v4l irc nowadays. Next time, >>> please send your patch series first to the ML, tagged with [PATCH RFC] >>> especially if they touch ondrivers that you're not the maintainer or >>> when you weren't able to test. >> >> So this is the new policy? Post with [PATCH RFC], wait a few days, then >> post a git pull request? Acks from other maintainers when a patch touches on their files were always part of the policy. > > That's a new policy under discussion. I think it's worth being discussed a > bit > more. http://www.linuxtv.org/irc/v4l/index.php?date=2010-10-01 and > http://www.linuxtv.org/irc/v4l/index.php?date=2010-10-11 if you want to catch > up with the informal discussion. > >> Should I also do this for long but mechanical conversions like the >> 'video_device' to 'v4l2_devnode'rename patch series? I think posting that >> would be spamming the list. In this case, posting the actual patches seem overkill to me. Yet, is a good idea to c/c the maintainers for the driver you're touching, to avoid conflicts with their merges. Cheers, 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: linux-next: Tree for September 29 (media & IR build errors)
On 09/29/10 21:38, Mauro Carvalho Chehab wrote: > Em 29-09-2010 12:31, Randy Dunlap escreveu: >> On Wed, 29 Sep 2010 14:36:04 +1000 Stephen Rothwell wrote: >> >>> Hi all, >>> >>> Changes since 20100928: >> >> >> ERROR: "ir_keydown" [drivers/media/video/ir-kbd-i2c.ko] undefined! >> ERROR: "__ir_input_register" [drivers/media/video/ir-kbd-i2c.ko] undefined! >> ERROR: "get_rc_map" [drivers/media/video/ir-kbd-i2c.ko] undefined! >> ERROR: "ir_input_unregister" [drivers/media/video/ir-kbd-i2c.ko] undefined! >> ERROR: "get_rc_map" [drivers/media/video/cx88/cx88xx.ko] undefined! >> ERROR: "ir_repeat" [drivers/media/video/cx88/cx88xx.ko] undefined! >> ERROR: "ir_input_unregister" [drivers/media/video/cx88/cx88xx.ko] undefined! >> ERROR: "ir_keydown" [drivers/media/video/cx88/cx88xx.ko] undefined! >> ERROR: "__ir_input_register" [drivers/media/video/cx88/cx88xx.ko] undefined! >> ERROR: "get_rc_map" [drivers/media/video/bt8xx/bttv.ko] undefined! >> ERROR: "ir_input_unregister" [drivers/media/video/bt8xx/bttv.ko] undefined! >> ERROR: "__ir_input_register" [drivers/media/video/bt8xx/bttv.ko] undefined! >> ERROR: "ir_core_debug" [drivers/media/IR/ir-common.ko] undefined! >> ERROR: "ir_g_keycode_from_table" [drivers/media/IR/ir-common.ko] undefined! > > Randy, > > Thanks for the test. > > With Sept, 29 + my linux-next tree (that weren't merged on yesterday's build, > I didn't notice the above errors). I suspect that the fixes were already on my > tree. > > I noticed, however, two Kconfig errors on staging (for go7007 and cx25821), > related > to IR_CORE changes: > > warning: (VIDEO_GO7007 && STAGING && !STAGING_EXCLUDE_BUILD && VIDEO_DEV && > PCI && I2C && INPUT && BKL && SND || VIDEO_CX25821 && STAGING && > !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && > BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) > warning: (VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE && > VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet > direct dependencies (IR_CORE) > > I'm adding the enclosed patch to my linux-next tree in order to fix this > trouble. > On a test after the patch on my tree, your randconfig applied well over my > tree. > So, I'm pushing it to my tree at kernel.org. > > Cheers, > Mauro > > --- > > commit 9c1eba02d90134fdfa4140b594b2367e90df1dbf > Author: Mauro Carvalho Chehab > Date: Thu Sep 30 00:56:08 2010 -0300 > > V4L/DVB: Fix Kconfig dependencies for VIDEO_IR > > warning: (VIDEO_GO7007 && STAGING && !STAGING_EXCLUDE_BUILD && VIDEO_DEV > && PCI && I2C && INPUT && BKL && SND || VIDEO_CX25821 && STAGING && > !STAGING_EXCLUDE_BUILD && DVB_CORE && VIDEO_DEV && PCI && I2C && INPUT && > BKL) selects VIDEO_IR which has unmet direct dependencies (IR_CORE) > warning: (VIDEO_CX25821 && STAGING && !STAGING_EXCLUDE_BUILD && DVB_CORE > && VIDEO_DEV && PCI && I2C && INPUT && BKL) selects VIDEO_IR which has unmet > direct dependencies (IR_CORE) > > Signed-off-by: Mauro Carvalho Chehab Yes, this works. Thanks. Acked-by: Randy Dunlap > diff --git a/drivers/staging/cx25821/Kconfig b/drivers/staging/cx25821/Kconfig > index df7756a..a766d0b 100644 > --- a/drivers/staging/cx25821/Kconfig > +++ b/drivers/staging/cx25821/Kconfig > @@ -4,7 +4,7 @@ config VIDEO_CX25821 > select I2C_ALGOBIT > select VIDEO_BTCX > select VIDEO_TVEEPROM > - select VIDEO_IR > + depends on VIDEO_IR > select VIDEOBUF_DVB > select VIDEOBUF_DMA_SG > select VIDEO_CX25840 > diff --git a/drivers/staging/go7007/Kconfig b/drivers/staging/go7007/Kconfig > index e47f683..b816a60 100644 > --- a/drivers/staging/go7007/Kconfig > +++ b/drivers/staging/go7007/Kconfig > @@ -3,7 +3,7 @@ config VIDEO_GO7007 > depends on VIDEO_DEV && PCI && I2C && INPUT > depends on SND > select VIDEOBUF_DMA_SG > - select VIDEO_IR > + depends on VIDEO_IR > select VIDEO_TUNER > select VIDEO_TVEEPROM > select SND_PCM -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** -- 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 v5 0/6] Add support for camera capture in s5p-fimc driver
Hi all, this is a fifth version of patches adding camera capture capability to the s5p-fimc driver. It incorporates minor fixes that I tracked just after sending v4, my apologies for spaming the list.. Hopefully that is the last version to be merged. Changes since v1: - entirely removed plat-samsung/include/plat/fimc.h header so there is no platform code dependency - improved s/try_fmt ioctl and introduced common ioctl handlers for mem2mem and capture node where it's reasonable - register definition changes merged with previous commit [3/8] v4l: s5p-fimc: Register definition cleanup Changes since v2: - improved s/g/crop(cap) handling in capture node - added passing of v4l controls to the sensor subdevice Changes since v3: - changed summary of patch [4/4] to adhere to patch submitting guidelines - patch "V4L/DVB: s5p-fimc: M2M driver cleanup.." split to 2 separate commits - 2/5 and 3/5 in this series Changes since v4: - fixed passing control to the subdev, removed silly use of check_stream_type() - add support for FIMC on S5PC210 (S5PV310) SoCs The patch series contains: [PATCH 1/6 v5] V4L/DVB: s5p-fimc: Register definition cleanup [PATCH 2/6 v5] V4L/DVB: s5p-fimc: mem2mem driver refactoring and cleanup [PATCH 3/6 v5] V4L/DVB: s5p-fimc: Fix 90/270 deg rotation errors [PATCH 4/6 v5] V4L/DVB: s5p-fimc: Do not lock both buffer queues in s_fmt [PATCH 5/6 v5] V4L/DVB: s5p-fimc: Add camera capture support [PATCH 6/6 v5] V4L/DVB: s5p-fimc: Add suport for FIMC on S5PC210 SoCs It has been rebased onto linuxtv/staging-2.6.37 branch at git://linuxtv.org/media_tree.git with the below 2 bugfix patches already present in 2.6.36 also applied: v4l: s5p-fimc: Fix 3-planar formats handling and pixel offset error on S5PV210 SoCs v4l: s5p-fimc: Fix return value on probe() failure Regards, Sylwester -- Sylwester Nawrocki Linux Platform Group Samsung Poland R&D Center -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/6 v5] V4L/DVB: s5p-fimc: Do not lock both buffer queues in s_fmt
It is not necessary to lock both capture and output buffer queue while
setting format for single queue.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c | 69 +
1 files changed, 31 insertions(+), 38 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 6bddec3..85a7e72 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -742,8 +742,9 @@ static int fimc_m2m_try_fmt(struct file *file, void *priv,
static int fimc_m2m_s_fmt(struct file *file, void *priv, struct v4l2_format *f)
{
struct fimc_ctx *ctx = priv;
- struct v4l2_device *v4l2_dev = &ctx->fimc_dev->m2m.v4l2_dev;
- struct videobuf_queue *src_vq, *dst_vq;
+ struct fimc_dev *fimc = ctx->fimc_dev;
+ struct v4l2_device *v4l2_dev = &fimc->m2m.v4l2_dev;
+ struct videobuf_queue *vq;
struct fimc_frame *frame;
struct v4l2_pix_format *pix;
unsigned long flags;
@@ -755,69 +756,61 @@ static int fimc_m2m_s_fmt(struct file *file, void *priv,
struct v4l2_format *f)
if (ret)
return ret;
- mutex_lock(&ctx->fimc_dev->lock);
+ if (mutex_lock_interruptible(&fimc->lock))
+ return -ERESTARTSYS;
- src_vq = v4l2_m2m_get_src_vq(ctx->m2m_ctx);
- dst_vq = v4l2_m2m_get_dst_vq(ctx->m2m_ctx);
+ vq = v4l2_m2m_get_vq(ctx->m2m_ctx, f->type);
+ mutex_lock(&vq->vb_lock);
- mutex_lock(&src_vq->vb_lock);
- mutex_lock(&dst_vq->vb_lock);
+ if (videobuf_queue_is_busy(vq)) {
+ v4l2_err(v4l2_dev, "%s: queue (%d) busy\n", __func__, f->type);
+ ret = -EBUSY;
+ goto sf_out;
+ }
+ spin_lock_irqsave(&ctx->slock, flags);
if (f->type == V4L2_BUF_TYPE_VIDEO_OUTPUT) {
- if (videobuf_queue_is_busy(src_vq)) {
- v4l2_err(v4l2_dev, "%s queue busy\n", __func__);
- ret = -EBUSY;
- goto s_fmt_out;
- }
frame = &ctx->s_frame;
- spin_lock_irqsave(&ctx->slock, flags);
ctx->state |= FIMC_SRC_FMT;
- spin_unlock_irqrestore(&ctx->slock, flags);
-
} else if (f->type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- if (videobuf_queue_is_busy(dst_vq)) {
- v4l2_err(v4l2_dev, "%s queue busy\n", __func__);
- ret = -EBUSY;
- goto s_fmt_out;
- }
frame = &ctx->d_frame;
- spin_lock_irqsave(&ctx->slock, flags);
ctx->state |= FIMC_DST_FMT;
- spin_unlock_irqrestore(&ctx->slock, flags);
} else {
+ spin_unlock_irqrestore(&ctx->slock, flags);
v4l2_err(&ctx->fimc_dev->m2m.v4l2_dev,
"Wrong buffer/video queue type (%d)\n", f->type);
ret = -EINVAL;
- goto s_fmt_out;
+ goto sf_out;
}
+ spin_unlock_irqrestore(&ctx->slock, flags);
pix = &f->fmt.pix;
frame->fmt = find_format(f);
if (!frame->fmt) {
ret = -EINVAL;
- goto s_fmt_out;
+ goto sf_out;
}
- frame->f_width = pix->bytesperline * 8 / frame->fmt->depth;
- frame->f_height = pix->sizeimage/pix->bytesperline;
- frame->width = pix->width;
- frame->height = pix->height;
- frame->o_width = pix->width;
+ frame->f_width = pix->bytesperline * 8 / frame->fmt->depth;
+ frame->f_height = pix->height;
+ frame->width= pix->width;
+ frame->height = pix->height;
+ frame->o_width = pix->width;
frame->o_height = pix->height;
- frame->offs_h = 0;
- frame->offs_v = 0;
- frame->size = (pix->width * pix->height * frame->fmt->depth) >> 3;
- src_vq->field = dst_vq->field = pix->field;
+ frame->offs_h = 0;
+ frame->offs_v = 0;
+ frame->size = (pix->width * pix->height * frame->fmt->depth) >> 3;
+ vq->field = pix->field;
+
spin_lock_irqsave(&ctx->slock, flags);
ctx->state |= FIMC_PARAMS;
spin_unlock_irqrestore(&ctx->slock, flags);
- dbg("f_width= %d, f_height= %d", frame->f_width, frame->f_height);
+ dbg("f_w: %d, f_h: %d", frame->f_width, frame->f_height);
-s_fmt_out:
- mutex_unlock(&dst_vq->vb_lock);
- mutex_unlock(&src_vq->vb_lock);
- mutex_unlock(&ctx->fimc_dev->lock);
+sf_out:
+ mutex_unlock(&vq->vb_lock);
+ mutex_unlock(&fimc->lock);
return ret;
}
--
1.7.3.1
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/6 v5] V4L/DVB: s5p-fimc: Fix 90/270 deg rotation errors
Due to errorneous swapping of image dimensions the rotation
control was not handled properly in subsequent calls.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c | 15 ++---
drivers/media/video/s5p-fimc/fimc-reg.c | 101 +++---
2 files changed, 57 insertions(+), 59 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 99ab46f..6bddec3 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -207,8 +207,13 @@ static int fimc_set_scaler_info(struct fimc_ctx *ctx)
int tx, ty, sx, sy;
int ret;
- tx = d_frame->width;
- ty = d_frame->height;
+ if (ctx->rotation == 90 || ctx->rotation == 270) {
+ ty = d_frame->width;
+ tx = d_frame->height;
+ } else {
+ tx = d_frame->width;
+ ty = d_frame->height;
+ }
if (tx <= 0 || ty <= 0) {
v4l2_err(&ctx->fimc_dev->m2m.v4l2_dev,
"invalid target size: %d x %d", tx, ty);
@@ -429,12 +434,6 @@ static int fimc_prepare_config(struct fimc_ctx *ctx, u32
flags)
d_frame = &ctx->d_frame;
if (flags & FIMC_PARAMS) {
- if ((ctx->out_path == FIMC_DMA) &&
- (ctx->rotation == 90 || ctx->rotation == 270)) {
- swap(d_frame->f_width, d_frame->f_height);
- swap(d_frame->width, d_frame->height);
- }
-
/* Prepare the DMA offset ratios for scaler. */
fimc_prepare_dma_offset(ctx, &ctx->s_frame);
fimc_prepare_dma_offset(ctx, &ctx->d_frame);
diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c
b/drivers/media/video/s5p-fimc/fimc-reg.c
index 94e98d4..95adc84 100644
--- a/drivers/media/video/s5p-fimc/fimc-reg.c
+++ b/drivers/media/video/s5p-fimc/fimc-reg.c
@@ -34,44 +34,6 @@ void fimc_hw_reset(struct fimc_dev *dev)
cfg = readl(dev->regs + S5P_CIGCTRL);
cfg &= ~S5P_CIGCTRL_SWRST;
writel(cfg, dev->regs + S5P_CIGCTRL);
-
-}
-
-void fimc_hw_set_rotation(struct fimc_ctx *ctx)
-{
- u32 cfg, flip;
- struct fimc_dev *dev = ctx->fimc_dev;
-
- cfg = readl(dev->regs + S5P_CITRGFMT);
- cfg &= ~(S5P_CITRGFMT_INROT90 | S5P_CITRGFMT_OUTROT90);
-
- flip = readl(dev->regs + S5P_MSCTRL);
- flip &= ~S5P_MSCTRL_FLIP_MASK;
-
- /*
-* The input and output rotator cannot work simultaneously.
-* Use the output rotator in output DMA mode or the input rotator
-* in direct fifo output mode.
-*/
- if (ctx->rotation == 90 || ctx->rotation == 270) {
- if (ctx->out_path == FIMC_LCDFIFO) {
- cfg |= S5P_CITRGFMT_INROT90;
- if (ctx->rotation == 270)
- flip |= S5P_MSCTRL_FLIP_180;
- } else {
- cfg |= S5P_CITRGFMT_OUTROT90;
- if (ctx->rotation == 270)
- cfg |= S5P_CITRGFMT_FLIP_180;
- }
- } else if (ctx->rotation == 180) {
- if (ctx->out_path == FIMC_LCDFIFO)
- flip |= S5P_MSCTRL_FLIP_180;
- else
- cfg |= S5P_CITRGFMT_FLIP_180;
- }
- if (ctx->rotation == 180 || ctx->rotation == 270)
- writel(flip, dev->regs + S5P_MSCTRL);
- writel(cfg, dev->regs + S5P_CITRGFMT);
}
static u32 fimc_hw_get_in_flip(u32 ctx_flip)
@@ -114,6 +76,46 @@ static u32 fimc_hw_get_target_flip(u32 ctx_flip)
return flip;
}
+void fimc_hw_set_rotation(struct fimc_ctx *ctx)
+{
+ u32 cfg, flip;
+ struct fimc_dev *dev = ctx->fimc_dev;
+
+ cfg = readl(dev->regs + S5P_CITRGFMT);
+ cfg &= ~(S5P_CITRGFMT_INROT90 | S5P_CITRGFMT_OUTROT90 |
+ S5P_CITRGFMT_FLIP_180);
+
+ flip = readl(dev->regs + S5P_MSCTRL);
+ flip &= ~S5P_MSCTRL_FLIP_MASK;
+
+ /*
+* The input and output rotator cannot work simultaneously.
+* Use the output rotator in output DMA mode or the input rotator
+* in direct fifo output mode.
+*/
+ if (ctx->rotation == 90 || ctx->rotation == 270) {
+ if (ctx->out_path == FIMC_LCDFIFO) {
+ cfg |= S5P_CITRGFMT_INROT90;
+ if (ctx->rotation == 270)
+ flip |= S5P_MSCTRL_FLIP_180;
+ } else {
+ cfg |= S5P_CITRGFMT_OUTROT90;
+ if (ctx->rotation == 270)
+ cfg |= S5P_CITRGFMT_FLIP_180;
+ }
+ } else if (ctx->rotation == 180) {
+ if (ctx->out_path == FIMC_LCDFIFO)
+ flip |= S5P_MSCTRL_FLIP_180;
+ else
+ cfg |= S5P_
[PATCH 1/6 v5] V4L/DVB: s5p-fimc: Register definition cleanup
Add MIPI CSI format definitions, prepare DMA address definitions for interlaced input frame mode. Signed-off-by: Sylwester Nawrocki Signed-off-by: Kyungmin Park --- drivers/media/video/s5p-fimc/fimc-reg.c |6 +- drivers/media/video/s5p-fimc/regs-fimc.h | 61 - 2 files changed, 28 insertions(+), 39 deletions(-) diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 5570f1c..70f29c5 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -507,9 +507,9 @@ void fimc_hw_set_input_addr(struct fimc_dev *dev, struct fimc_addr *paddr) cfg |= S5P_CIREAL_ISIZE_ADDR_CH_DIS; writel(cfg, dev->regs + S5P_CIREAL_ISIZE); - writel(paddr->y, dev->regs + S5P_CIIYSA0); - writel(paddr->cb, dev->regs + S5P_CIICBSA0); - writel(paddr->cr, dev->regs + S5P_CIICRSA0); + writel(paddr->y, dev->regs + S5P_CIIYSA(0)); + writel(paddr->cb, dev->regs + S5P_CIICBSA(0)); + writel(paddr->cr, dev->regs + S5P_CIICRSA(0)); cfg &= ~S5P_CIREAL_ISIZE_ADDR_CH_DIS; writel(cfg, dev->regs + S5P_CIREAL_ISIZE); diff --git a/drivers/media/video/s5p-fimc/regs-fimc.h b/drivers/media/video/s5p-fimc/regs-fimc.h index a3cfe82..9e83315 100644 --- a/drivers/media/video/s5p-fimc/regs-fimc.h +++ b/drivers/media/video/s5p-fimc/regs-fimc.h @@ -11,10 +11,6 @@ #ifndef REGS_FIMC_H_ #define REGS_FIMC_H_ -#define S5P_CIOYSA(__x)(0x18 + (__x) * 4) -#define S5P_CIOCBSA(__x) (0x28 + (__x) * 4) -#define S5P_CIOCRSA(__x) (0x38 + (__x) * 4) - /* Input source format */ #define S5P_CISRCFMT 0x00 #define S5P_CISRCFMT_ITU601_8BIT (1 << 31) @@ -28,22 +24,21 @@ /* Window offset */ #define S5P_CIWDOFST 0x04 -#define S5P_CIWDOFST_WINOFSEN (1 << 31) +#define S5P_CIWDOFST_OFF_EN(1 << 31) #define S5P_CIWDOFST_CLROVFIY (1 << 30) #define S5P_CIWDOFST_CLROVRLB (1 << 29) -#define S5P_CIWDOFST_WINHOROFST_MASK (0x7ff << 16) +#define S5P_CIWDOFST_HOROFF_MASK (0x7ff << 16) #define S5P_CIWDOFST_CLROVFICB (1 << 15) #define S5P_CIWDOFST_CLROVFICR (1 << 14) -#define S5P_CIWDOFST_WINHOROFST(x) ((x) << 16) -#define S5P_CIWDOFST_WINVEROFST(x) ((x) << 0) -#define S5P_CIWDOFST_WINVEROFST_MASK (0xfff << 0) +#define S5P_CIWDOFST_HOROFF(x) ((x) << 16) +#define S5P_CIWDOFST_VEROFF(x) ((x) << 0) +#define S5P_CIWDOFST_VEROFF_MASK (0xfff << 0) /* Global control */ #define S5P_CIGCTRL0x08 #define S5P_CIGCTRL_SWRST (1 << 31) #define S5P_CIGCTRL_CAMRST_A (1 << 30) #define S5P_CIGCTRL_SELCAM_ITU_A (1 << 29) -#define S5P_CIGCTRL_SELCAM_ITU_MASK(1 << 29) #define S5P_CIGCTRL_TESTPAT_NORMAL (0 << 27) #define S5P_CIGCTRL_TESTPAT_COLOR_BAR (1 << 27) #define S5P_CIGCTRL_TESTPAT_HOR_INC(2 << 27) @@ -61,6 +56,8 @@ #define S5P_CIGCTRL_SHDW_DISABLE (1 << 12) #define S5P_CIGCTRL_SELCAM_MIPI_A (1 << 7) #define S5P_CIGCTRL_CAMIF_SELWB(1 << 6) +/* 0 - ITU601; 1 - ITU709 */ +#define S5P_CIGCTRL_CSC_ITU601_709 (1 << 5) #define S5P_CIGCTRL_INVPOLHSYNC(1 << 4) #define S5P_CIGCTRL_SELCAM_MIPI(1 << 3) #define S5P_CIGCTRL_INTERLACE (1 << 0) @@ -72,23 +69,10 @@ #define S5P_CIWDOFST2_HOROFF(x)((x) << 16) #define S5P_CIWDOFST2_VEROFF(x)((x) << 0) -/* Output DMA Y plane start address */ -#define S5P_CIOYSA10x18 -#define S5P_CIOYSA20x1c -#define S5P_CIOYSA30x20 -#define S5P_CIOYSA40x24 - -/* Output DMA Cb plane start address */ -#define S5P_CIOCBSA1 0x28 -#define S5P_CIOCBSA2 0x2c -#define S5P_CIOCBSA3 0x30 -#define S5P_CIOCBSA4 0x34 - -/* Output DMA Cr plane start address */ -#define S5P_CIOCRSA1 0x38 -#define S5P_CIOCRSA2 0x3c -#define S5P_CIOCRSA3 0x40 -#define S5P_CIOCRSA4 0x44 +/* Output DMA Y/Cb/Cr plane start addresses */ +#define S5P_CIOYSA(n) (0x18 + (n) * 4) +#define S5P_CIOCBSA(n) (0x28 + (n) * 4) +#define S5P_CIOCRSA(n) (0x38 + (n) * 4) /* Target image format */ #define S5P_CITRGFMT 0x48 @@ -168,6 +152,8 @@ #define S5P_CISTATUS_OVFICB(1 << 30) #define S5P_CISTATUS_OVFICR(1 << 29) #define S5P_CISTATUS_VSYNC (1 << 28) +#define S5P_CISTATUS_FRAMECNT_MASK (3 << 26) +#define S5P_CISTATUS_FRAMECNT_SHIFT26 #define S5P_CISTATUS_WINOFF_EN (1 << 25) #define S5P_CISTATUS_IMGCPT_EN (1 << 22) #define S5P_CISTATUS_IMGCPT_SCEN (1 << 21) @@ -206,10 +192,10 @@ #define S5P_CIIMGEFF_PAT_CB(x) ((
[PATCH 6/6 v5] V4L/DVB: s5p-fimc: Add suport for FIMC on S5PC210 SoCs
Enable FIMC operation on S5PC210 (S5PV310) SoCs. This a minimal
adaptation to obtain functionality of older FIMC IP revisions
(S5PC100, S5PC110) on S5PC210 SOcs.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c | 157 +-
drivers/media/video/s5p-fimc/fimc-core.h | 56 ---
drivers/media/video/s5p-fimc/regs-fimc.h |3 +
3 files changed, 156 insertions(+), 60 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index 064e7d5..7e63a49 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -823,10 +823,10 @@ int fimc_vidioc_try_fmt(struct file *file, void *priv,
struct v4l2_format *f)
goto tf_out;
if (is_output) {
- max_width = variant->scaler_dis_w;
+ max_width = variant->pix_limit->scaler_dis_w;
mod_x = ffs(variant->min_inp_pixsize) - 1;
} else {
- max_width = variant->out_rot_dis_w;
+ max_width = variant->pix_limit->out_rot_dis_w;
mod_x = ffs(variant->min_out_pixsize) - 1;
}
@@ -843,7 +843,7 @@ int fimc_vidioc_try_fmt(struct file *file, void *priv,
struct v4l2_format *f)
dbg("mod_x: %d, mod_y: %d, max_w: %d", mod_x, mod_y, max_width);
v4l_bound_align_image(&pix->width, 16, max_width, mod_x,
- &pix->height, 8, variant->scaler_dis_w, mod_y, 0);
+ &pix->height, 8, variant->pix_limit->scaler_dis_w, mod_y, 0);
if (pix->bytesperline == 0 ||
(pix->bytesperline * 8 / fmt->depth) > pix->width)
@@ -1519,7 +1519,7 @@ static int fimc_probe(struct platform_device *pdev)
drv_data = (struct samsung_fimc_driverdata *)
platform_get_device_id(pdev)->driver_data;
- if (pdev->id >= drv_data->devs_cnt) {
+ if (pdev->id >= drv_data->num_entities) {
dev_err(&pdev->dev, "Invalid platform device id: %d\n",
pdev->id);
return -EINVAL;
@@ -1602,6 +1602,13 @@ static int fimc_probe(struct platform_device *pdev)
}
}
+ /*
+* Exclude the additional output DMA address registers by masking
+* them out on HW revisions that provide extended capabilites.
+*/
+ if (fimc->variant->out_buf_count > 4)
+ fimc_hw_set_dma_seq(fimc, 0xF);
+
dev_dbg(&pdev->dev, "%s(): fimc-%d registered successfully\n",
__func__, fimc->id);
@@ -1645,78 +1652,135 @@ static int __devexit fimc_remove(struct
platform_device *pdev)
return 0;
}
-static struct samsung_fimc_variant fimc01_variant_s5p = {
- .has_inp_rot= 1,
- .has_out_rot= 1,
+/* Image pixel limits, similar across several FIMC HW revisions. */
+static struct fimc_pix_limit s5p_pix_limit[3] = {
+ [0] = {
+ .scaler_en_w= 3264,
+ .scaler_dis_w = 8192,
+ .in_rot_en_h= 1920,
+ .in_rot_dis_w = 8192,
+ .out_rot_en_w = 1920,
+ .out_rot_dis_w = 4224,
+ },
+ [1] = {
+ .scaler_en_w= 4224,
+ .scaler_dis_w = 8192,
+ .in_rot_en_h= 1920,
+ .in_rot_dis_w = 8192,
+ .out_rot_en_w = 1920,
+ .out_rot_dis_w = 4224,
+ },
+ [2] = {
+ .scaler_en_w= 1920,
+ .scaler_dis_w = 8192,
+ .in_rot_en_h= 1280,
+ .in_rot_dis_w = 8192,
+ .out_rot_en_w = 1280,
+ .out_rot_dis_w = 1920,
+ },
+};
+
+static struct samsung_fimc_variant fimc0_variant_s5p = {
+ .has_inp_rot = 1,
+ .has_out_rot = 1,
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
-
- .scaler_en_w= 3264,
- .scaler_dis_w = 8192,
- .in_rot_en_h= 1920,
- .in_rot_dis_w = 8192,
- .out_rot_en_w = 1920,
- .out_rot_dis_w = 4224,
+ .hor_offs_align = 8,
+ .out_buf_count = 4,
+ .pix_limit = &s5p_pix_limit[0],
};
static struct samsung_fimc_variant fimc2_variant_s5p = {
.min_inp_pixsize = 16,
.min_out_pixsize = 16,
-
- .scaler_en_w= 4224,
- .scaler_dis_w = 8192,
- .in_rot_en_h= 1920,
- .in_rot_dis_w = 8192,
- .out_rot_en_w = 1920,
- .out_rot_dis_w = 4224,
+ .hor_offs_align = 8,
+ .out_buf_count = 4,
+ .pix_limit = &s5p_pix_limit[1],
};
-static struct samsung_fimc_variant fimc01_variant_s5pv210 = {
- .pix_hoff = 1,
- .has_inp_rot= 1,
- .has_out_rot= 1,
+static struct samsung_fimc_variant fimc0_variant_s5pv210 = {
+ .pix_hoff= 1,
+ .has_inp_rot = 1,
+ .has_out_rot = 1,
.min_
[PATCH 2/6 v5] V4L/DVB: s5p-fimc: mem2mem driver refactoring and cleanup
Register access functions refactored for camera capture interface
control. Removed the workqueue since it was only useful for FIFO
output mode which is not supported at this time.
Fixed errors on module unload. Comments and whitespace cleanup.
Signed-off-by: Sylwester Nawrocki
Signed-off-by: Kyungmin Park
---
drivers/media/video/s5p-fimc/fimc-core.c | 151 +++---
drivers/media/video/s5p-fimc/fimc-core.h | 132 ++
drivers/media/video/s5p-fimc/fimc-reg.c | 43 -
3 files changed, 148 insertions(+), 178 deletions(-)
diff --git a/drivers/media/video/s5p-fimc/fimc-core.c
b/drivers/media/video/s5p-fimc/fimc-core.c
index e18ee67..99ab46f 100644
--- a/drivers/media/video/s5p-fimc/fimc-core.c
+++ b/drivers/media/video/s5p-fimc/fimc-core.c
@@ -117,7 +117,7 @@ static struct fimc_fmt fimc_formats[] = {
.buff_cnt = 1,
.planes_cnt = 2
}
- };
+};
static struct v4l2_queryctrl fimc_ctrls[] = {
{
@@ -127,16 +127,14 @@ static struct v4l2_queryctrl fimc_ctrls[] = {
.minimum= 0,
.maximum= 1,
.default_value = 0,
- },
- {
+ }, {
.id = V4L2_CID_VFLIP,
.type = V4L2_CTRL_TYPE_BOOLEAN,
.name = "Vertical flip",
.minimum= 0,
.maximum= 1,
.default_value = 0,
- },
- {
+ }, {
.id = V4L2_CID_ROTATE,
.type = V4L2_CTRL_TYPE_INTEGER,
.name = "Rotation (CCW)",
@@ -181,28 +179,23 @@ static int fimc_check_scaler_ratio(struct v4l2_rect *r,
struct fimc_frame *f)
static int fimc_get_scaler_factor(u32 src, u32 tar, u32 *ratio, u32 *shift)
{
- if (src >= tar * 64) {
+ u32 sh = 6;
+
+ if (src >= 64 * tar)
return -EINVAL;
- } else if (src >= tar * 32) {
- *ratio = 32;
- *shift = 5;
- } else if (src >= tar * 16) {
- *ratio = 16;
- *shift = 4;
- } else if (src >= tar * 8) {
- *ratio = 8;
- *shift = 3;
- } else if (src >= tar * 4) {
- *ratio = 4;
- *shift = 2;
- } else if (src >= tar * 2) {
- *ratio = 2;
- *shift = 1;
- } else {
- *ratio = 1;
- *shift = 0;
+
+ while (sh--) {
+ u32 tmp = 1 << sh;
+ if (src >= tar * tmp) {
+ *shift = sh, *ratio = tmp;
+ return 0;
+ }
}
+ *shift = 0, *ratio = 1;
+
+ dbg("s: %d, t: %d, shift: %d, ratio: %d",
+ src, tar, *shift, *ratio);
return 0;
}
@@ -265,8 +258,8 @@ static int fimc_set_scaler_info(struct fimc_ctx *ctx)
static irqreturn_t fimc_isr(int irq, void *priv)
{
struct fimc_vid_buffer *src_buf, *dst_buf;
- struct fimc_dev *fimc = (struct fimc_dev *)priv;
struct fimc_ctx *ctx;
+ struct fimc_dev *fimc = priv;
BUG_ON(!fimc);
fimc_hw_clear_irq(fimc);
@@ -281,7 +274,7 @@ static irqreturn_t fimc_isr(int irq, void *priv)
dst_buf = v4l2_m2m_dst_buf_remove(ctx->m2m_ctx);
if (src_buf && dst_buf) {
spin_lock(&fimc->irqlock);
- src_buf->vb.state = dst_buf->vb.state = VIDEOBUF_DONE;
+ src_buf->vb.state = dst_buf->vb.state = VIDEOBUF_DONE;
wake_up(&src_buf->vb.done);
wake_up(&dst_buf->vb.done);
spin_unlock(&fimc->irqlock);
@@ -295,20 +288,13 @@ isr_unlock:
}
/* The color format (planes_cnt, buff_cnt) must be already configured. */
-static int fimc_prepare_addr(struct fimc_ctx *ctx,
- struct fimc_vid_buffer *buf, enum v4l2_buf_type type)
+int fimc_prepare_addr(struct fimc_ctx *ctx, struct fimc_vid_buffer *buf,
+ struct fimc_frame *frame, struct fimc_addr *paddr)
{
- struct fimc_frame *frame;
- struct fimc_addr *paddr;
- u32 pix_size;
int ret = 0;
+ u32 pix_size;
- frame = ctx_m2m_get_frame(ctx, type);
- if (IS_ERR(frame))
- return PTR_ERR(frame);
- paddr = &frame->paddr;
-
- if (!buf)
+ if (buf == NULL || frame == NULL)
return -EINVAL;
pix_size = frame->width * frame->height;
@@ -344,8 +330,8 @@ static int fimc_prepare_addr(struct fimc_ctx *ctx,
}
}
- dbg("PHYS_ADDR: type= %d, y= 0x%X cb= 0x%X cr= 0x%X ret= %d",
- type, paddr->y, paddr->cb, paddr->cr, ret);
+ dbg("PHYS_ADDR: y= 0x%X cb= 0x%X cr= 0x%X ret= %d",
+ paddr->y, paddr->cb, paddr->cr, ret);
return ret;
}
@@ -466,16 +452,14 @@ static int fimc_pr
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
On Mon, Oct 11, 2010 at 11:40 AM, Hans Verkuil wrote: > On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: >> Hans, >> >> On Sun, Sep 26, 2010 at 8:25 AM, Hans Verkuil wrote: >> > Hi Mauro, >> > >> > These are the locking patches. It's based on my previous test tree, but >> > with >> > more testing with em28xx and radio-mr800 and some small tweaks relating to >> > disconnect handling and video_is_registered(). >> > >> > I also removed the unused get_unmapped_area file op and I am now blocking >> > any further (unlocked_)ioctl calls after the device node is unregistered. >> > The only things an application can do legally after a disconnect is unmap() >> > and close(). >> > >> > This patch series also contains a small em28xx fix that I found while >> > testing >> > the em28xx BKL removal patch. >> > >> > Regards, >> > >> > Hans >> > >> > The following changes since commit >> > dace3857de7a16b83ae7d4e13c94de8e4b267d2a: >> > Hans Verkuil (1): >> > V4L/DVB: tvaudio: remove obsolete tda8425 initialization >> > >> > are available in the git repository at: >> > >> > ssh://linuxtv.org/git/hverkuil/v4l-dvb.git bkl >> > >> > Hans Verkuil (10): >> > v4l2-dev: after a disconnect any ioctl call will be blocked. >> > v4l2-dev: remove get_unmapped_area >> > v4l2: add core serialization lock. >> > videobuf: prepare to make locking optional in videobuf >> > videobuf: add ext_lock argument to the queue init functions >> > videobuf: add queue argument to videobuf_waiton() >> > vivi: remove BKL. >> > em28xx: remove BKL. >> > em28xx: the default std was not passed on to the subdevs >> > radio-mr800: remove BKL >> >> Did you even test these patches? > > Yes, I did test. And it works for me. But you are correct in that it shouldn't > work since the struct will indeed be freed. I'll fix this and post a patch. > > I'm not sure why it works fine when I test it. > > There is a problem as well with unlocking before unregistering the device in > that it leaves a race condition where another app can open the device again > before it is registered. I have to think about that some more. Actually, no this problem did not exist. The previous version of the driver cleared the USB device member to indicate that the device had been disconnected. During open, if the USB device member was null, it aborted with -EIO. If there's a race there now, it's only because you introduced it. One thing I noticed while looking at this driver is that there's a call to usb_autopm_put_interface in usb_amradio_close. I'm not sure if it's a problem or not, but is it valid to call that after the device has been disconnected? I only ask, because it wasn't called in previous versions if the driver was disconnected before all handles to the device were closed. If it's incorrect to call it within this context, then this introduces another bug as well. It seems logical that for every get there should be a put, but I don't know in this case. > >> >> Mauro, you should be ashamed for accepting a series that obviously has >> issues. > > Hardly obvious, and definitely not his fault. > This comment was more general, since Mauro admitted having to make changes to your series to get it to compile under i386 architectures. Regards, David Ellingsworth -- 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] v4l-dvb daily build 2.6.26 and up: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Oct 11 19:00:04 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15164:1da5fed5c8b2 git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: 9147e3dbca0712a5435cd2ea7c48d39344f904eb gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: 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.32.6-armv5: WARNINGS linux-2.6.33-armv5: WARNINGS linux-2.6.34-armv5: WARNINGS linux-2.6.35.3-armv5: WARNINGS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: ERRORS linux-2.6.34-armv5-davinci: ERRORS linux-2.6.35.3-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: ERRORS linux-2.6.34-armv5-ixp: ERRORS linux-2.6.35.3-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: ERRORS linux-2.6.34-armv5-omap2: ERRORS linux-2.6.35.3-armv5-omap2: ERRORS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.32.6-m32r: WARNINGS linux-2.6.33-m32r: WARNINGS linux-2.6.34-m32r: WARNINGS linux-2.6.35.3-m32r: WARNINGS linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-mips: WARNINGS linux-2.6.35.3-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-powerpc64: WARNINGS linux-2.6.35.3-powerpc64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.37] Move V4L2 locking into the core framework
Em 11-10-2010 15:05, David Ellingsworth escreveu: > On Mon, Oct 11, 2010 at 11:40 AM, Hans Verkuil wrote: >> On Sunday, October 10, 2010 19:33:48 David Ellingsworth wrote: >>> Mauro, you should be ashamed for accepting a series that obviously has >>> issues. >> >> Hardly obvious, and definitely not his fault. >> > > This comment was more general, since Mauro admitted having to make > changes to your series to get it to compile under i386 architectures. > So what? I always test if the tree compiles before sending the thing upstream. My compilation is against i686 architecture, as it enables more drivers than other architectures. Rejecting a patch series just because of the lack of a typecast to remove a warning on an architecture is not a good reason. I really prefer to apply the series and then ask (or make a fix) to one or two lines, than to have to dig the entire patch series again on a rev 2 of the entire patch series. Examining a patch that fixes this issue is a way easier than having to review a series of 11 patches. Cheers, 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
[GIT PATCHES FOR 2.6.37] Support for NetUP Dual DVB-T/C CI RF card
Patches to support for NetUP Dual DVB-T/C-CI RF from NetUP Inc. http://linuxtv.org/wiki/index.php/NetUP_Dual_DVB_T_C_CI_RF Features: PCI-e x1 Supports two DVB-T/DVB-C transponders simultaneously Supports two analog audio/video channels simultaneously Independent descrambling of two transponders Hardware PID filtering Components: Conexant CX23885 STM STV0367 low-power and ultra-compact combo DVB-T/C single-chip receiver Xceive XC5000 silicon TV tuner Altera FPGA for Common Interafce The following changes since commit c8dd732fd119ce6d562d5fa82a10bbe75a376575: V4L/DVB: gspca - sonixj: Have 0c45:6130 handled by sonixj instead of sn9c102 (2010-10-01 18:14:35 -0300) are available in the git repository at: http://udev.netup.ru/git/v4l-dvb.git netup-for-media-tree Abylay Ospan (6): cx23885: Altera FPGA CI interface reworked. stv0367: change default value for AGC register. stv0367: implement uncorrected blocks counter. cx23885, cimax2.c: Fix case of two CAM insertion irq. Fix CI code for NetUP Dual DVB-T/C CI RF card Force xc5000 firmware loading for NetUP Dual DVB-T/C CI RF card Igor M. Liplianin (14): Altera FPGA firmware download module. Altera FPGA based CI driver module. Support for stv0367 multi-standard demodulator. xc5000: add support for DVB-C tuning. Initial commit to support NetUP Dual DVB-T/C CI RF card. cx23885: implement tuner_bus parameter for cx23885_board structure. cx23885: implement num_fds_portb, num_fds_portc parameters for cx23885_board structure. stv0367: Fix potential divide error cx23885: remove duplicate set interrupt mask stv0367: coding style corrections cx25840: Fix subdev registration and typo in cx25840-core.c cx23885: 0xe becomes 0xc again for NetUP Dual DVB-S2 cx23885: disable MSI for NetUP cards, otherwise CI is not working cx23885, altera-ci: enable all PID's less than 0x20 in hardware PID filter. drivers/media/common/tuners/xc5000.c| 18 + drivers/media/dvb/frontends/Kconfig |7 + drivers/media/dvb/frontends/Makefile|1 + drivers/media/dvb/frontends/stv0367.c | 3419 + drivers/media/dvb/frontends/stv0367.h | 62 + drivers/media/dvb/frontends/stv0367_priv.h | 211 ++ drivers/media/dvb/frontends/stv0367_regs.h | 3614 +++ drivers/media/video/cx23885/Kconfig | 12 +- drivers/media/video/cx23885/Makefile|1 + drivers/media/video/cx23885/altera-ci.c | 841 +++ drivers/media/video/cx23885/altera-ci.h | 102 + drivers/media/video/cx23885/cimax2.c| 24 +- drivers/media/video/cx23885/cx23885-cards.c | 116 +- drivers/media/video/cx23885/cx23885-core.c | 35 +- drivers/media/video/cx23885/cx23885-dvb.c | 175 ++- drivers/media/video/cx23885/cx23885-reg.h |1 + drivers/media/video/cx23885/cx23885-video.c |7 +- drivers/media/video/cx23885/cx23885.h |7 +- drivers/media/video/cx25840/cx25840-core.c |4 +- drivers/misc/Kconfig|1 + drivers/misc/Makefile |1 + drivers/misc/stapl-altera/Kconfig |8 + drivers/misc/stapl-altera/Makefile |3 + drivers/misc/stapl-altera/altera.c | 2739 drivers/misc/stapl-altera/jbicomp.c | 163 ++ drivers/misc/stapl-altera/jbiexprt.h| 94 + drivers/misc/stapl-altera/jbijtag.c | 1038 drivers/misc/stapl-altera/jbijtag.h | 83 + drivers/misc/stapl-altera/jbistub.c | 70 + include/misc/altera.h | 49 + 30 files changed, 12872 insertions(+), 34 deletions(-) create mode 100644 drivers/media/dvb/frontends/stv0367.c create mode 100644 drivers/media/dvb/frontends/stv0367.h create mode 100644 drivers/media/dvb/frontends/stv0367_priv.h create mode 100644 drivers/media/dvb/frontends/stv0367_regs.h create mode 100644 drivers/media/video/cx23885/altera-ci.c create mode 100644 drivers/media/video/cx23885/altera-ci.h create mode 100644 drivers/misc/stapl-altera/Kconfig create mode 100644 drivers/misc/stapl-altera/Makefile create mode 100644 drivers/misc/stapl-altera/altera.c create mode 100644 drivers/misc/stapl-altera/jbicomp.c create mode 100644 drivers/misc/stapl-altera/jbiexprt.h create mode 100644 drivers/misc/stapl-altera/jbijtag.c create mode 100644 drivers/misc/stapl-altera/jbijtag.h create mode 100644 drivers/misc/stapl-altera/jbistub.c create mode 100644 include/misc/altera.h -- 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: rtl2831-r2 still not working for Compro VideoMate U80
Could you try: http://linuxtv.org/hg/~anttip/qt1010/ Previous users of Compro VideoMate U80 has a qt1010 tuner, which required that branch. Ugnius Soraka wrote: Hi, I'd like to get in touch with driver developers, is there any way I could help make RTL2831U driver work with Compro VideoMate U80. I would like to actively participate. My programming skills are well below required to write kernel modules, so I know I would be no use there. But anything else, testing with VideoMate U80, sending debug logs, I think I could do that. I've tried http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 driver, it looked promising. U80 device was recognised as VideoMate U90, /dev/dvb entries were created. But when scanning it says there's no signal. Debug gives TPS_NON_LOCK, Signal NOT Present, rtd2830_soft_reset, etc. (I could post message log, if it's any use to somebody). U80 has a led which (on windows) shows if TV stick is tuned in and working, when scanning on linux it's always on. I've also tried to compile http://linuxtv.org/hg/~anttip/rtl2831u/ but for now it's based on old dvb tree and seems to be incompatible with new kernels (mine 2.6.34.7-0.3). Is anttip driver supposed to be included in kernel, but it looks like development is going slow. Thank you, Ugnius -- 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 -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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: [PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Hi stoth,
Em 31-07-2010 17:42, Steven Toth escreveu:
> Mauro,
>
> Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200
> and HVR2250 cards.
>
> Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l
>
As requested on irc, I've pulled from your tree again, and fixed a few things
on your patch series (a warning and _lots_ of checkpatch issues).
There are still some compilation breakages in the middle of your patch series.
So, I'll fold some patches, in order to avoid the issues.
There are still a few checkpatch issues (I removed all 80-columns warning
noise).
Could you please double check them?
To make life easier for you, I've created a temp git tree at:
http://git.linuxtv.org/mchehab/stoth.git
The checkpatch.pl errors/warnings are enclosed bellow.
Thanks,
Mauro
---
WARNING: braces {} are not necessary for single statement blocks
#47: FILE: drivers/media/video/saa7164/saa7164-api.c:43:
+ if (ret != SAA_OK) {
+ printk(KERN_ERR "%s() error, ret = 0x%x\n", __func__, ret);
+ }
WARNING: braces {} are not necessary for single statement blocks
#70: FILE: drivers/media/video/saa7164/saa7164-api.c:66:
+ if (ret != SAA_OK) {
+ printk(KERN_ERR "%s() error, ret = 0x%x\n", __func__,
ret);
+ }
WARNING: braces {} are not necessary for single statement blocks
#93: FILE: drivers/media/video/saa7164/saa7164-api.c:89:
+ if (ret != SAA_OK) {
+ printk(KERN_ERR "%s() error, ret = 0x%x\n", __func__, ret);
+ }
WARNING: braces {} are not necessary for single statement blocks
#103: FILE: drivers/media/video/saa7164/saa7164-api.c:99:
+ if (ret != SAA_OK) {
+ printk(KERN_ERR "%s() error, ret = 0x%x\n", __func__, ret);
+ }
ERROR: do not use C99 // comments
#654: FILE: drivers/media/video/saa7164/saa7164-api.c:650:
+ //saa7164_dumphex16(dev, buf, 16);
WARNING: kfree(NULL) is safe this check is probably not required
#1381: FILE: drivers/media/video/saa7164/saa7164-buffer.c:317:
+ if (buf->data) {
+ kfree(buf->data);
WARNING: kfree(NULL) is safe this check is probably not required
#1386: FILE: drivers/media/video/saa7164/saa7164-buffer.c:322:
+ if (buf)
+ kfree(buf);
ERROR: do not use C99 // comments
#1962: FILE: drivers/media/video/saa7164/saa7164-core.c:126:
+// saa7164_dumphex16FF(buf->port->dev, (p + i), 32);
WARNING: braces {} are not necessary for single statement blocks
#2038: FILE: drivers/media/video/saa7164/saa7164-core.c:202:
+ for (i = 0; i < 30; i++) {
+ hg->counter1[0 + i].val = i;
+ }
WARNING: braces {} are not necessary for single statement blocks
#2043: FILE: drivers/media/video/saa7164/saa7164-core.c:207:
+ for (i = 0; i < 18; i++) {
+ hg->counter1[30 + i].val = 30 + (i * 10);
+ }
WARNING: braces {} are not necessary for single statement blocks
#2048: FILE: drivers/media/video/saa7164/saa7164-core.c:212:
+ for (i = 0; i < 15; i++) {
+ hg->counter1[48 + i].val = 200 + (i * 200);
+ }
WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
#2103: FILE: drivers/media/video/saa7164/saa7164-core.c:267:
+ printk(KERN_ERR " %4d %12d %Ld\n",
ERROR: do not use C99 // comments
#2154: FILE: drivers/media/video/saa7164/saa7164-core.c:318:
+// saa7164_dumphex16FF(dev, (p +
buf->actual_size) - 32 , 64);
WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
#2239: FILE: drivers/media/video/saa7164/saa7164-core.c:403:
+ "%s() %Ldms elapsed irq->deferred %Ldms wp: %d rp: %d\n",
WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
#2315: FILE: drivers/media/video/saa7164/saa7164-core.c:479:
+ "%s() %Ldms elapsed irq->deferred %Ldms wp: %d rp: %d\n",
WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
#2402: FILE: drivers/media/video/saa7164/saa7164-core.c:567:
+ dprintk(DBGLVL_IRQ, "%s() %Ldms elapsed\n", __func__,
WARNING: %Ld/%Lu are not-standard C, use %lld/%llu
#2427: FILE: drivers/media/video/saa7164/saa7164-core.c:592:
+ dprintk(DBGLVL_IRQ, "%s() %Ldms elapsed\n", __func__,
ERROR: else should follow close brace '}'
#2606: FILE: drivers/media/video/saa7164/saa7164-core.c:965:
+ }
+ else
WARNING: struct file_operations should normally be const
#2747: FILE: drivers/media/video/saa7164/saa7164-core.c:1172:
+static struct file_operations saa7164_proc_fops = {
WARNING: braces {} are not necessary for single statement blocks
#4427: FILE: drivers/media/video/saa7164/saa7164-encoder.c:1236:
+ if (ubuf->pos > ubuf->actual_size) {
+ printk(KERN_ERR "read() pos > actual, huh?\n");
+ }
WARNING: braces {} are not necessary for single statement blocks
#4453: FILE: drivers/media/video/saa7164/saa7164-encoder.c:1262:
+ if (!ret && !ubuf) {
+ ret = -EA
Re: [linux-dvb] Asus MyCinema P7131 Dual support
Hi, > Hmm...things you can try: > 1) Tell pulseaudio not to use the saa7134-alsa soundcard (click on > sound preferences (top panel, on the right, near the clock) and > disable saa7134 soundcard). > 2) Run "cat /proc/asound/card" or "arecord -l" and make sure you're > using the right device on the MPlayer command line (the > "adevice=hw.1,0" part). > 3) Add "audiorate=32000" like this: > mplayer tv:// -tv > driver=v4l2:device=/dev/video0:norm=PAL:input=0:alsa:adevice=hw.1,0:amode=1:audiorate=32000:immediatemode=0:chanlist=europe-west Sound started to work with this command: mplayer tv:// -tv driver=v4l2:device=/dev/video0:chanlist=europe-west:alsa:adevice=hw.1,0:amode=1:audiorate=32000:forceaudio:volume=100:immediatemode=0:norm=PAL but after I stopped mythtv-backend ;-) sudo service mythtv-backend stop I wasn't thinking that mythtv might be using the same resources. Things are working better and better with this card. :-) Sound works (but not that good, some chops) with tvtime also using this command: arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | sox -q -c 2 -r 32000 -t wav - -t alsa hw:0,0 tvtime I am getting a few: "sox WARN alsa: under-run" but sound works. Here are the aplay -l and arecord -l, just for the record: % aplay -l List of PLAYBACK Hardware Devices card 0: CK804 [NVidia CK804], device 0: Intel ICH [NVidia CK804] Subdevices: 0/1 Subdevice #0: subdevice #0 card 0: CK804 [NVidia CK804], device 2: Intel ICH - IEC958 [NVidia CK804 - IEC958] Subdevices: 1/1 Subdevice #0: subdevice #0 2052 drodi...@server ~ % arecord -l List of CAPTURE Hardware Devices card 0: CK804 [NVidia CK804], device 0: Intel ICH [NVidia CK804] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: CK804 [NVidia CK804], device 1: Intel ICH - MIC ADC [NVidia CK804 - MIC ADC] Subdevices: 1/1 Subdevice #0: subdevice #0 card 1: SAA7134 [SAA7134], device 0: SAA7134 PCM [SAA7134 PCM] Subdevices: 0/1 Subdevice #0: subdevice #0 > 4) See if MPlayer reports any error with alsa/audio. > > Lastly, I think tvtime only works with a patch audio cable (which is > cable that connects the tv-card "audio out" to the soundcard "line > in"). So you can try to start tvtime and then run: > > arecord -D hw:1,0 -r 32000 -c 2 -f S16_LE | aplay - > > this way you record from the saa7134 audio device and play it back to > your speakers. > -- 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: [PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
Em 11-10-2010 18:03, Mauro Carvalho Chehab escreveu:
> Hi stoth,
>
> Em 31-07-2010 17:42, Steven Toth escreveu:
>> Mauro,
>>
>> Analog Encoder and VBI support in the SAA7164 tree, for the HVR2200
>> and HVR2250 cards.
>>
>> Please pull from http://www.kernellabs.com/hg/~stoth/saa7164-v4l
>>
>
> As requested on irc, I've pulled from your tree again, and fixed a few things
> on your patch series (a warning and _lots_ of checkpatch issues).
>
> There are still some compilation breakages in the middle of your patch series.
> So, I'll fold some patches, in order to avoid the issues.
>
> There are still a few checkpatch issues (I removed all 80-columns warning
> noise).
> Could you please double check them?
>
> To make life easier for you, I've created a temp git tree at:
> http://git.linuxtv.org/mchehab/stoth.git
Stoth,
I realized that I missed a few patches on my queue. I've applied them also at
the
git tree. There are a few issues on some of them:
commit a5209649cb5aa8a706e6ed5ab74378f2f95c64bf
Author: Steven Toth
Date: Wed Oct 6 21:52:22 2010 -0300
V4L/DVB: saa7164: Removed use of the BKL
Remove usage of the BKL and instead used video_set_drvdata() during
open fops.
Signed-off-by: Steven Toth
Signed-off-by: Mauro Carvalho Chehab
There were some conflicts on this patch. Please verify that the conflict solve
went ok.
commit 86ae40b5f3da13c5fd0c70731aac6447c6af4cd8
Author: Gavin Hurlbut
Date: Thu Sep 30 18:21:20 2010 -0300
V4L/DVB: Fix the -E{*} returns in the VBI device as well
commit f92f45822ce73cfc4bde8d61a75598fb9db35d6b
Author: Gavin Hurlbut
Date: Wed Sep 29 15:18:20 2010 -0300
V4L/DVB: Fix the negative -E{BLAH} returns from fops_read
commit 25b5ab78a5240c82baa78167e55c8d74a6e0a276
Author: Gavin Hurlbut
Date: Mon Sep 27 23:50:43 2010 -0300
V4L/DVB: Change the second input names to include " 2" to distinguish them
Those three patches are missing your Signed-off-by: and Gavin's Signed-off-by:
Could you please provide it?
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] viafb camera controller driver
Hi Jonathan,
On Monday 11 October 2010 17:30:48 Jonathan Corbet wrote:
> On Mon, 11 Oct 2010 14:18:55 +0200
>
> Laurent Pinchart wrote:
> > > +static __devexit int viacam_remove(struct platform_device *pdev)
> > > +{
> > > + struct via_camera *cam = via_cam_info;
> >
> > And use it here.
> >
> > Just call platform_set_drvdata(pdev, cam) in viacam_probe to store the
> > struct via_camera pointer in the platform device, and
> > platform_get_drvdata(pdev) here to retrieve it.
>
> Yes, I know...but the fix isn't quite that simple because the platform
> data is already used elsewhere.
Aren't you mistaking platform_data and platform device drvdata ?
platform_{gs}et_drvdata() access the
platform_device::device::device_private::driver_data, which is a private
pointer reserved for driver-specific information. pdev->dev.platform_data is a
private pointer that stores platform-specific data (often configuration data)
in the platform device.
> What's needed is some sort of "viafb subdevice instance" structure which can
> keep all of the pointers together. My plan is to do that, but it will
> require via-core changes and I just don't have time for that right now.
>
> Can I get away with this (it will cause no real-world trouble) with a
> promise of a fix in the next month or two? I have some other via-core
> stuff (suspend/resume in particular) that I need to do anyway.
If the platform device driver data is really used by something else, OK. But
don't dare not keeping your promise ;-)
--
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: [PULL] http://kernellabs.com/hg/~stoth/saa7164-v4l
I replied earlier, but due to gmail wanting to send HTML mail by
default (grr), it bounced when sending to the list Original
reply (slightly reformatted) follows:
>commit 86ae40b5f3da13c5fd0c70731aac6447c6af4cd8
>Author: Gavin Hurlbut
>Date: Thu Sep 30 18:21:20 2010 -0300
>
>V4L/DVB: Fix the -E{*} returns in the VBI device as well
>
>commit f92f45822ce73cfc4bde8d61a75598fb9db35d6b
>Author: Gavin Hurlbut
>Date: Wed Sep 29 15:18:20 2010 -0300
>
>V4L/DVB: Fix the negative -E{BLAH} returns from fops_read
>
>commit 25b5ab78a5240c82baa78167e55c8d74a6e0a276
>Author: Gavin Hurlbut
>Date: Mon Sep 27 23:50:43 2010 -0300
>
>V4L/DVB: Change the second input names to include " 2" to distinguish them
>
> Those three patches are missing your Signed-off-by: and Gavin's Signed-off-by:
>
> Could you please provide it?
Chock those up to me missing putting the Signed-off-by: lines in the
patches I sent to Steven due to me being new to mercurial. Is there a
way for me to add it posthumously, as it were? I'll be sure to add
that in any future patches, and I apologize for the oversight. It
would be (for all three patches):
Signed-off-by: Gavin Hurlbut
--
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] Resource reservation for frontend - Was: Re: xc5000 and switch RF input
Hi Mauro
> Em 07-10-2010 10:00, Dmitri Belimov escreveu:
> > Hi
> >
> >> Em 06-10-2010 16:52, Dmitri Belimov escreveu:
> >>> Hi
> >>>
> >>> Our TV card Behold X7 has two different RF input. This RF inputs
> >>> can switch between different RF sources.
> >>>
> >>> ANT 1 for analog and digital TV
> >>> ANT 2 for FM radio
> >>>
> >>> The switch controlled by zl10353.
> >>>
> >>> How to I can control this switch?
> >>>
> >>> I found 2 way
> >>>
> >>> 1.
> >>> Use tuner callback to saa1734. add some params like
> >>> XC5000_TUNER_SET/XC5000_TUNER_SET_TV to the xc5000.h call tuner
> >>> callback from xc5000_set_analog_params with new params about
> >>> switching. In this case inside saa7134 need know about zl10353 and
> >>> configuration. I don't understand how to do. The structure
> >>> saa7134_dev hasn't pointer to the structure dvb_frontend. Or use
> >>> hardcoded i2c_addr and params.
> >>>
> >>> 2.
> >>> Direct call switch the switcher from the tuner code. In this case
> >>> need know TV card type. I think it is not so good idea.
> >>
> >> The issues between FM and TV mode is only a small part of a big
> >> problem that we're currently facing: drivers that support multiple
> >> types of streams, like radio, analog TV and digital TV need a way
> >> to avoid conflicts between different parts of the driver, and
> >> between a DVB and a V4L call.
> >>
> >> The long-term solution seems to implement a tuner/frontend resource
> >> reservation routine. This will solve other problems as well, like
> >> having both analog and digital parts of the driver trying to access
> >> the same resource at the same time.
> >>
> >> While implementing both analog and ISDB-T support for a
> >> saa7134-based board, I got one issue where analog tuner were
> >> trying to do RF callibration while the DVB demod were initialized.
> >> As the access to the demod requires one I2C gate setup and the
> >> access to the tuner requires another setup, both operations failed.
> >>
> >> We had similar problems in em28xx and cx231xx. Both were partially
> >> solved with a lock, but still if the user tries to open both DVB
> >> and V4L interfaces, it will likely have problems.
> >>
> >> So, we really need to implement some type of resource locking that
> >> will properly setup I2C gates, RF gates, etc, depending on the type
> >> of resource currently in use.
> >>
> >> Basically, the idea would be to implement something like:
> >>
> >> enum frontend_resource {
> >>ANALOG_TV_TUNER,
> >>DIGITAL_TV_TUNER,
> >>FM_TUNER,
> >>ANALOG_DEMOD,
> >>DIGITAL_DEMOD,
> >> };
> >>
> >> And add a new callback at struct dvb_frontend_ops():
> >>
> >>int (*set_resource)(struct dvb_frontend* fe, enum
> >> frontend_resource, bool reserve);
> >>
> >> Those callbacks may replace i2c_gate_ctrl().
> >>
> >> With those changes, when a driver needs to access, for example, a
> >> tuner at a dvb part of the driver, it would do:
> >>
> >> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, true);
> >> /* All i2c transactions and other operations needed at tuner */
> >> fe->ops.set_resource(fe, DIGITAL_TV_TUNER, false);
> >>
> >> In other words, it will basically replace the current occurrences
> >> of i2c_gate_ctrl(), providing a clearer indication that the I2C
> >> change needed are to enable the access to the tuner.
> >>
> >> The fun begins if other parts of the driver try to do different
> >> things on resources that may be shared. They can now say that they
> >> want to access the demod with:
> >>
> >> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
> >>
> >> So, demods operations will be protected by:
> >>
> >> fe->ops.set_resource(fe, DIGITAL_DEMOD, true);
> >>/* All i2c transactions and other operations applied on
> >> demod */ fe->ops.set_resource(fe, DIGITAL_DEMOD, false);
> >>
> >> It is up to driver callback to handle this call. If both
> >> DIGITAL_DEMOD and DIGITAL_TV_TUNER are at the same i2c bus (e.g.
> >> there's no i2c gate), and if there's no risk for one I2C access to
> >> affect the other, the callback can just return 0. Otherwise, it may
> >> return -EBUSY and let the caller wait for the resource to be freed
> >> with: wake_up(fe->ops.set_resource(fe, DIGITAL_DEMOD, true) == 0);
> >> or wake_up_interruptible(fe->ops.set_resource(fe, DIGITAL_DEMOD,
> >> true) == 0);
> >>
> >> This way, when the resource is freed, the digital demod logic may
> >> happen.
> >>
> >> Comments?
> >
> > What about hardware encoders? May be need switch between some TV
> > and encoders. Switch input source, output bus and other.
>
> Yeah, we may need to add encoders here, and other stuff like IR and
> CA modules.
>
> an approach like that is easy to extend, as new issues that may
> require resource reservation is added.
Are you wrote this feature already? I'll try it on my boards.
Some description need :)
> Cheers,
> Mauro
With my best regards, Dmitry.
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to maj
[patch -next] V4L/DVB: IR/streamzap: fix usec to nsec conversion
There is an integer overflow here because 0x0300 * 1000 is too large for 31 bits. rawir.duration should be in terms of nsecs. IR_MAX_DURATION and 0x0300 are already in terms of nsecs. STREAMZAP_TIMEOUT and STREAMZAP_RESOLUTION are 255 and 256 respectively and are in terms of usecs. The original code had a deadline of 1.005 seconds and the new code has a deadline of .065 seconds. Signed-off-by: Dan Carpenter diff --git a/drivers/media/IR/streamzap.c b/drivers/media/IR/streamzap.c index 2cf57e6..d5d3cee 100644 --- a/drivers/media/IR/streamzap.c +++ b/drivers/media/IR/streamzap.c @@ -221,7 +221,7 @@ static void streamzap_callback(struct urb *urb) struct streamzap_ir *sz; unsigned int i; int len; - static int timeout = (((STREAMZAP_TIMEOUT * STREAMZAP_RESOLUTION) & + static int timeout = (((STREAMZAP_TIMEOUT * STREAMZAP_RESOLUTION * 1000) & IR_MAX_DURATION) | 0x0300); if (!urb) @@ -273,7 +273,7 @@ static void streamzap_callback(struct urb *urb) struct ir_raw_event rawir; rawir.pulse = false; - rawir.duration = timeout * 1000; + rawir.duration = timeout; sz->idle = true; if (sz->timeout_enabled) sz_push(sz, rawir); -- 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
