Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 09:31:55AM +0100, Guennadi Liakhovetski wrote:
On Wed, 11 Mar 2009, Sascha Hauer wrote:
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
arch/arm/mach-pxa/pcm990-baseboard.c | 50
+++--
1 files changed, 41 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..e9feb89 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,46 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct device *dev,
The prototype will change to use struct soc_camera_link *
OK
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
+ else
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
You wanted to use gpio_bus_switch for these.
s/wanted to/should/?
OK
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct device *dev)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, camera);
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -1;
This is a purely internal variable, so, I won't insist if you disagree,
but, I think, a scheme non-negative for a valid value or a negative error
code looks better, cf.
If you want to initialize a structure with an invalid GPIO number, use
some negative number (perhaps -EINVAL); that will never be valid.
(Documentation/gpio.txt). -1 looks like you're going to perform
calculations with it.
OK
}
+
+ if (gpio_bus_switch 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
+ .gpio = NR_BUILTIN_GPIO + 1,
There's one patch missing in your patch series:
[PATCH 5/5] Remove the gpio member from the struct soc_camera_link
OK. I saw this member is unnecessary now and forgot it a minute later...
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
One more thing I noticed while looking at your patch 3/4:
+static int pcm990_camera_set_bus_param(struct device *dev,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
+ else
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
Originally the logic here was only if flags == SOCAM_DATAWIDTH_8, switch
to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
you have any reason to change that logic?
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
One more thing I noticed while looking at your patch 3/4:
+static int pcm990_camera_set_bus_param(struct device *dev,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
+ else
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
Originally the logic here was only if flags == SOCAM_DATAWIDTH_8, switch
to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
you have any reason to change that logic?
I was not aware that I changed any logic. I thought I would get here
with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
here with more than one width flags set?
The mt9v022 driver has this in set_bus_param:
/* Only one width bit may be set */
if (!is_power_of_2(width_flag))
return -EINVAL;
And I think it makes sense.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, 12 Mar 2009, Sascha Hauer wrote:
On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
One more thing I noticed while looking at your patch 3/4:
+static int pcm990_camera_set_bus_param(struct device *dev,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
+ else
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
Originally the logic here was only if flags == SOCAM_DATAWIDTH_8, switch
to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
you have any reason to change that logic?
I was not aware that I changed any logic. I thought I would get here
with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
here with more than one width flags set?
The mt9v022 driver has this in set_bus_param:
/* Only one width bit may be set */
if (!is_power_of_2(width_flag))
return -EINVAL;
And I think it makes sense.
Ok, then, could you, please add the same test to mt9m001? And, as I
mentioned in a comment to 3/4, please, return an error if switching is
requested but unsupported.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
--
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: EC168 support?!
bloehei wrote: 40 00 00 00 40 08 c5 03 12 0c 93 80 06 12 0d 43 74 83 f0 e5 48 30 e3 78 hmm, at least that last fw upload packet is wrong. It should look like 40 00 00 00 00 18 c5 03 49 9f f5 I did yesterday many changes and fixed one bad bug that could be behind that. Please test with latest tree at: http://linuxtv.org/hg/~anttip/ec168/ regards Antti Hi, GREAT! The firmware now gets uploaded and I can watch all channels in my region with the linux vdr. Thanks a lot! Here's my system log: ec168_module_init: usbcore: registered new interface driver dvb_usb_ec168 usb 1-3: new high speed USB device using ehci_hcd and address 2 usb 1-3: configuration #1 chosen from 1 choice ec168_probe: interface:0 ec168_identify_state: c0 01 00 00 01 00 01 00 00 ec168_identify_state: reply:00 dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in cold state, will try to load a firmware usb 1-3: firmware: requesting dvb-usb-ec168.fw dvb-usb: downloading firmware from file 'dvb-usb-ec168.fw' ec168_download_firmware: 40 00 00 00 00 00 00 08 02 13 e4 02 0e d3 00 00 00 00 00 02 14 f7 00 00 00 00 00 ---cut--- 40 00 00 00 00 08 00 08 4a 12 0c 5b 04 f0 02 08 4b 12 09 7f 12 0d 43 74 82 f0 12 ---cut--- 40 00 00 00 00 10 00 08 9d ec 98 40 05 fc ee 9d fe 0f d5 f0 e9 e4 ce fd 22 ed f8 ---cut--- 40 00 00 00 00 18 c5 03 49 9f f5 49 e5 48 94 00 f5 48 80 b3 e4 f5 24 f5 25 22 af ---cut--- 40 01 00 00 01 00 00 00 40 04 01 00 08 00 00 00 ec168_rw_udev: usb_control_msg failed :-110 40 04 00 00 06 02 00 00 dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference design) ec168_ec100_frontend_attach: DVB: registering adapter 0 frontend 0 (E3C EC100 DVB-T)... ec168_mxl5003s_tuner_attach: MXL5005S: Attached at address 0xc6 dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized and connected. ec168_probe: interface:1 ec168_identify_state: c0 01 00 00 01 00 01 00 01 ec168_identify_state: reply:01 dvb-usb: found a 'E3C EC168 DVB-T USB2.0 reference design' in warm state. dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. DVB: registering new adapter (E3C EC168 DVB-T USB2.0 reference design) ec168_ec100_frontend_attach: DVB: registering adapter 1 frontend 0 (E3C EC100 DVB-T)... ec168_mxl5003s_tuner_attach: MXL5005S: Attached at address 0xc6 dvb-usb: E3C EC168 DVB-T USB2.0 reference design successfully initialized and connected. USB-Id: 18b4:1689 Card name: Sinovideo SV DVB-T 3420B If I can help with testing, just let me know. Regards, Jo -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] mt9v022: allow setting of bus width from board code
On Wed, 11 Mar 2009, Sascha Hauer wrote:
This patch removes the phytec specific setting of the bus width
and switches to the more generic query_bus_param/set_bus_param
hooks
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/media/video/Kconfig |7 ---
drivers/media/video/mt9v022.c | 97
+
2 files changed, 11 insertions(+), 93 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 5fc1531..071d66f 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -747,13 +747,6 @@ config SOC_CAMERA_MT9V022
help
This driver supports MT9V022 cameras from Micron
-config MT9V022_PCA9536_SWITCH
- bool pca9536 datawidth switch for mt9v022
- depends on SOC_CAMERA_MT9V022 GENERIC_GPIO
- help
- Select this if your MT9V022 camera uses a PCA9536 I2C GPIO
- extender to switch between 8 and 10 bit datawidth modes
-
config SOC_CAMERA_TW9910
tristate tw9910 support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index b04c8cb..26f97eb 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -209,66 +209,6 @@ static int mt9v022_stop_capture(struct soc_camera_device
*icd)
return 0;
}
-static int bus_switch_request(struct mt9v022 *mt9v022, struct
soc_camera_link *icl)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- int ret;
- unsigned int gpio = icl-gpio;
-
- if (gpio_is_valid(gpio)) {
- /* We have a data bus switch. */
- ret = gpio_request(gpio, mt9v022);
- if (ret 0) {
- dev_err(mt9v022-client-dev, Cannot get GPIO %u\n,
gpio);
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 0);
- if (ret 0) {
- dev_err(mt9v022-client-dev,
- Cannot set GPIO %u to output\n, gpio);
- gpio_free(gpio);
- return ret;
- }
- }
-
- mt9v022-switch_gpio = gpio;
-#else
- mt9v022-switch_gpio = -EINVAL;
-#endif
- return 0;
-}
-
-static void bus_switch_release(struct mt9v022 *mt9v022)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- if (gpio_is_valid(mt9v022-switch_gpio))
- gpio_free(mt9v022-switch_gpio);
-#endif
-}
-
-static int bus_switch_act(struct mt9v022 *mt9v022, int go8bit)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- if (!gpio_is_valid(mt9v022-switch_gpio))
- return -ENODEV;
-
- gpio_set_value_cansleep(mt9v022-switch_gpio, go8bit);
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static int bus_switch_possible(struct mt9v022 *mt9v022)
-{
-#ifdef CONFIG_MT9V022_PCA9536_SWITCH
- return gpio_is_valid(mt9v022-switch_gpio);
-#else
- return 0;
-#endif
-}
-
static int mt9v022_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
@@ -282,19 +222,10 @@ static int mt9v022_set_bus_param(struct
soc_camera_device *icd,
if (!is_power_of_2(width_flag))
return -EINVAL;
- if ((mt9v022-datawidth != 10 (width_flag == SOCAM_DATAWIDTH_10)) ||
- (mt9v022-datawidth != 9 (width_flag == SOCAM_DATAWIDTH_9)) ||
- (mt9v022-datawidth != 8 (width_flag == SOCAM_DATAWIDTH_8))) {
- /* Well, we actually only can do 10 or 8 bits... */
- if (width_flag == SOCAM_DATAWIDTH_9)
- return -EINVAL;
-
- ret = bus_switch_act(mt9v022,
- width_flag == SOCAM_DATAWIDTH_8);
- if (ret 0)
+ if (icl-set_bus_param) {
+ ret = icl-set_bus_param(mt9v022-client-dev, width_flag);
+ if (ret)
return ret;
-
- mt9v022-datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
}
flags = soc_camera_apply_sensor_flags(icl, flags);
@@ -328,10 +259,14 @@ static int mt9v022_set_bus_param(struct
soc_camera_device *icd,
static unsigned long mt9v022_query_bus_param(struct soc_camera_device *icd)
{
struct mt9v022 *mt9v022 = container_of(icd, struct mt9v022, icd);
- unsigned int width_flag = SOCAM_DATAWIDTH_10;
+ struct soc_camera_link *icl = mt9v022-client-dev.platform_data;
+ unsigned int width_flag;
- if (bus_switch_possible(mt9v022))
- width_flag |= SOCAM_DATAWIDTH_8;
+ if (icl-query_bus_param)
+ width_flag = icl-query_bus_param(mt9v022-client-dev)
+ SOCAM_DATAWIDTH_MASK;
+ else
+ width_flag = SOCAM_DATAWIDTH_10;
return SOCAM_PCLK_SAMPLE_RISING | SOCAM_PCLK_SAMPLE_FALLING |
SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_HSYNC_ACTIVE_LOW |
@@ -729,6 +664,7 @@ static int
Re: [PATCH 2/4] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 10:25:35AM +0100, Guennadi Liakhovetski wrote:
On Thu, 12 Mar 2009, Sascha Hauer wrote:
On Thu, Mar 12, 2009 at 09:40:46AM +0100, Guennadi Liakhovetski wrote:
One more thing I noticed while looking at your patch 3/4:
+static int pcm990_camera_set_bus_param(struct device *dev,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 1);
+ else
+ gpio_set_value(NR_BUILTIN_GPIO + 1, 0);
Originally the logic here was only if flags == SOCAM_DATAWIDTH_8, switch
to 8 bits, otherwise do 10 bits. I.e., if flags == SOCAM_DATAWIDTH_8 |
SOCAM_DATAWIDTH_10, it would still do the default (and wider) 10 bits. Do
you have any reason to change that logic?
I was not aware that I changed any logic. I thought I would get here
with only one of the SOCAM_DATAWIDTH_* set. Isn't it a bug when we get
here with more than one width flags set?
The mt9v022 driver has this in set_bus_param:
/* Only one width bit may be set */
if (!is_power_of_2(width_flag))
return -EINVAL;
And I think it makes sense.
Ok, then, could you, please add the same test to mt9m001? And, as I
mentioned in a comment to 3/4, please, return an error if switching is
requested but unsupported.
Ok, will do.
It may be that we need a different approach to the bus width setting in
the longer term. For example the mt9m001 can support any thinkable bus
width of 1 to inf. bits. This depends on the hardware designer who wired
up the connection and not the physical count of data lines the chip has.
I have no idea how to implement this though.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] mt9m001: allow setting of bus width from board code
On Wed, 11 Mar 2009, Sascha Hauer wrote:
This patch removes the phytec specific setting of the bus width
and switches to the more generic query_bus_param/set_bus_param
hooks
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/media/video/Kconfig |7 --
drivers/media/video/mt9m001.c | 130 +---
2 files changed, 30 insertions(+), 107 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..5fc1531 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -728,13 +728,6 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
-config MT9M001_PCA9536_SWITCH
- bool pca9536 datawidth switch for mt9m001
- depends on SOC_CAMERA_MT9M001 GENERIC_GPIO
- help
- Select this if your MT9M001 camera uses a PCA9536 I2C GPIO
- extender to switch between 8 and 10 bit datawidth modes
-
config SOC_CAMERA_MT9M111
tristate mt9m111 and mt9m112 support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index c1bf75e..112c612 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -75,7 +75,6 @@ struct mt9m001 {
int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
int switch_gpio;
unsigned char autoexposure;
- unsigned char datawidth;
};
static int reg_read(struct soc_camera_device *icd, const u8 reg)
@@ -181,90 +180,17 @@ static int mt9m001_stop_capture(struct
soc_camera_device *icd)
return 0;
}
-static int bus_switch_request(struct mt9m001 *mt9m001,
- struct soc_camera_link *icl)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- int ret;
- unsigned int gpio = icl-gpio;
-
- if (gpio_is_valid(gpio)) {
- /* We have a data bus switch. */
- ret = gpio_request(gpio, mt9m001);
- if (ret 0) {
- dev_err(mt9m001-client-dev, Cannot get GPIO %u\n,
- gpio);
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 0);
- if (ret 0) {
- dev_err(mt9m001-client-dev,
- Cannot set GPIO %u to output\n, gpio);
- gpio_free(gpio);
- return ret;
- }
- }
-
- mt9m001-switch_gpio = gpio;
-#else
- mt9m001-switch_gpio = -EINVAL;
-#endif
- return 0;
-}
-
-static void bus_switch_release(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (gpio_is_valid(mt9m001-switch_gpio))
- gpio_free(mt9m001-switch_gpio);
-#endif
-}
-
-static int bus_switch_act(struct mt9m001 *mt9m001, int go8bit)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (!gpio_is_valid(mt9m001-switch_gpio))
- return -ENODEV;
-
- gpio_set_value_cansleep(mt9m001-switch_gpio, go8bit);
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static int bus_switch_possible(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- return gpio_is_valid(mt9m001-switch_gpio);
-#else
- return 0;
-#endif
-}
-
static int mt9m001_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- unsigned int width_flag = flags SOCAM_DATAWIDTH_MASK;
- int ret;
+ struct soc_camera_link *icl = mt9m001-client-dev.platform_data;
/* Flags validity verified in test_bus_param */
- if ((mt9m001-datawidth != 10 (width_flag == SOCAM_DATAWIDTH_10)) ||
- (mt9m001-datawidth != 9 (width_flag == SOCAM_DATAWIDTH_9)) ||
- (mt9m001-datawidth != 8 (width_flag == SOCAM_DATAWIDTH_8))) {
- /* Well, we actually only can do 10 or 8 bits... */
- if (width_flag == SOCAM_DATAWIDTH_9)
- return -EINVAL;
- ret = bus_switch_act(mt9m001,
- width_flag == SOCAM_DATAWIDTH_8);
- if (ret 0)
- return ret;
-
- mt9m001-datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
- }
+ if (icl-set_bus_param)
+ return icl-set_bus_param(mt9m001-client-dev,
+ flags SOCAM_DATAWIDTH_MASK);
Not quite. Look at the original code. If no change is requested - just
return 0. If a change is requested, but switching is impossible - return
an error - and this is not, what you are doing in 2/4, please fix. So, you
might still want to preserve .datawidth for the verification.
Calls to camera-device -query_bus_param() and -set_bus_param() methods
are currently internal to specific host drivers. So, it
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Wed, 11 Mar 2009 11:25:20 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: Hello Mauro, Please pull from: http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 for the following: xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 au8522: rename the au8522.c source file au8522: move shared state and common functions into a separate header files au8522: fix register read/write high bits au8522: power down the digital demod when not in use au8522: make use of hybrid framework so analog/digital demod can share state au8522: add support for analog side of demodulator au0828: add support for analog functionality in bridge au0828: workaround a bug in the au0828 i2c handling au0828: add analog profile for the HVR-850 au8522: add mutex protecting use of hybrid state au0828: Rework the way the analog video binding occurs tveeprom: add the xc5000 tuner to the tveeprom definition au0828: advertise only NTSC-M (as opposed to all NTSC standards) au0828: disable VBI code since it doesn't yet work au0828: fix i2c enumeration bug au0828: make register debug lines easier to read au0828: make g_chip_ident call work properly au0828: properly handle missing analog USB endpoint au0828: properly handle non-existent analog inputs au0828: fix panic on disconnect if analog initialization failed au0828: Convert to use v4l2_device/subdev framework Cheers, Devin Hi Devin, There's a bug on your patch series: see this: Those are the locations of au8522 files at Kernel's tree: drivers/media/dvb/frontends/au8522.h drivers/media/dvb/frontends/au8522_dig.c drivers/media/dvb/frontends/au8522_priv.h drivers/media/video/au8522_decoder.c And those are the Makefile rules for au8522.h on drivers/media/dvb/frontends/Makefile: au8522-objs = au8522_dig.o au8522_decoder.o obj-$(CONFIG_DVB_AU8522) += au8522.o When you're compiling the out-of-tree version, everything works OK, but, for in-tree compilation, au8522_decoder won't be compiled, since the file will be in the wrong dir. If I'm understanding well, this chip has two functions: it is a dvb frontend and an analog video/audio demodulator, right? One solution would be to have all those files in the same directory. However, au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, otherwise common/tuners would be another better place. Another alternative would be to create two kconfig rules (and two separate modules), being one for au8522_decoder and another for the frontend, since they are, in fact, two different things. I suspect,however, that compiling just one or another would break compilation. So, we need to create some sort of rules that will warrant that both modules will be compiled at the same time. This is not an easy task, since we cannot add depends on, since frontends are compiled by using select. So, we will need to re-design the Kconfig rules to use depends on instead of select (well, this is something good, anyway, since the usage of select is something that should be avoided, according with Kbuild docs). I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, I'll need to blacklist the module until we found a solution, or find a way to allow my -git trees to compile. 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: disable v4l2-ctl logging --log-status in /var/log/messages
On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hello, Is it possible to disable v4l2-ctl aplication logging into /var/log/messages. I am using it to control and monitor my PVR 150 cards and every time I run v4l2-ctl -d /dev/video0 --log-status all output is logged into /var/log/messages and some other linux log files. All --log-status does is to tell the driver to show it's status in the kernel log for debugging purposes. It cannot and should not be relied upon for monitoring/controlling a driver. What do you need it for anyway? I am just monitoring if signal is present on tuner, and what signal format is detected. These two lines: cx25840 1-0044: Video signal: not present cx25840 1-0044: Detected format: PAL-Nc I run this every minute and it is really annoying to have all this in my system logs. Is it possible to modify v4l2-ctl source to disable system logging? Regards, Gregor -- 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.22 and up: ERRORS, 2.6.16-2.6.21: 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:Thu Mar 12 09:40:14 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10966:3392722cc5b6 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc7-m32r: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc7-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Wed, 11 Mar 2009 21:00:19 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
Hello Mauro,
Please apply one additional patch for the series I sent this morning:
- au0828: make sure v4l2_device name is unique
Thanks,
Devin
+static int vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh-dev;
+
+ memset(cap, 0, sizeof(*cap));
Please remove all memsets for input/output arguments on vidioc_foo at
au0828-video.c.
The V4L2 core warrants that the non-input fields are zeroed.
+static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if(f-index)
+ return -EINVAL;
+
+ memset(f, 0, sizeof(*f));
+ f-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ strcpy(f-description, Packed YUV2);
+
+ f-flags = 0;
+ f-pixelformat = V4L2_PIX_FMT_UYVY;
+
+ memset(f-reserved, 0, sizeof(f-reserved));
+ return 0;
+}
hmm.. you are cleaning up f-reserved three times: at v4l2-ioctl, at the
memset(f) and at memset(f-reserved).
You really wanted to make sure that you've cleaned it, don't you? ;)
hmm...
+#ifdef VBI_NOT_YET_WORKING
+ .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+ .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+#endif
I don't see any reference of this macro. If VBI is working, please cleanup the
driver. Btw, your logic seems to be inverted on some cases. Why are you adding
VBI macros, if it is not working yet?
On the other hand, if VBI is broken we'll need some rules for removing vbi code
from upstream, at gentree.pl.
+enum au0828_itype {
+ AU0828_VMUX_UNDEFINED = 0,
+ AU0828_VMUX_COMPOSITE,
+ AU0828_VMUX_SVIDEO,
+ AU0828_VMUX_CABLE,
+ AU0828_VMUX_TELEVISION,
+ AU0828_VMUX_DVB,
+ AU0828_VMUX_DEBUG
+};
...
+static int vidioc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *input)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh-dev;
+ unsigned int tmp;
+
+ static const char *inames[] = {
+ [AU0828_VMUX_COMPOSITE] = Composite,
+ [AU0828_VMUX_SVIDEO] = S-Video,
+ [AU0828_VMUX_CABLE] = Cable TV,
+ [AU0828_VMUX_TELEVISION] = Television,
+ [AU0828_VMUX_DVB] = DVB,
+ [AU0828_VMUX_DEBUG] = tv debug
+ };
If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is it
what you really wanted? I would, instead, assign another value for
AU0828_VMUX_UNDEFINED, like -1.
+ switch(AUVI_INPUT(index).type) {
+ case AU0828_VMUX_SVIDEO:
+ {
+ dev-input_type = AU0828_VMUX_SVIDEO;
+ break;
+ }
+ case AU0828_VMUX_COMPOSITE:
+ {
+ dev-input_type = AU0828_VMUX_COMPOSITE;
+ break;
+ }
+ case AU0828_VMUX_TELEVISION:
+ {
+ dev-input_type = AU0828_VMUX_TELEVISION;
+ break;
+ }
+ default:
+ ;
+ }
You don't need all those braces.
Also, the default rule is missing. I don't see why you would preserve the same
dev-input_type if the user selects an undefined entry, or a DVB or a debug.
Ah, finally, there are a number of CodingStyle fun. I've enclosed what it got,
from the final code. Please, always use make checkpatch before committing a
patch.
Cheers,
Mauro
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In '
printk(arg); \':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:40: warning:
suspect code indent for conditional statements (8, 17)
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 buf
[] = { (reg 8) | 0x80, reg 0xff, data };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:48: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 b0
[] = { (reg 8) | 0x40, reg 0xff };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:65: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' u8 b1
[] = { 0 };':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:66: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c: In ' struct
i2c_msg msg [] = {':
/home/v4l/master/linux/drivers/media/dvb/frontends/au8522_dig.c:68: ERROR:
space prohibited before open square bracket '['
/home/v4l/master/linux/drivers/media/video/au0828/au0828-cards.c: In '
}':
/home/v4l/master/linux/drivers/media/video/au0828/au0828-cards.c:205: warning:
Re: [linuxtv-commits] [hg:v4l-dvb] Fix I2C bridge error in zl10353
On Thu, 12 Mar 2009 12:35:40 +0900 Dmitri Belimov d.beli...@gmail.com wrote: Hi Antti Antti Palosaari wrote: Dmitri Belimov wrote: Could one of you please do such patchset? I haven't a lot expirience with kernel programming. If Antti can it is good. I'll check it on our board. OK, I will do. For the first phase and as a bug fix I will do that (disable i2c-gate) like dtv5100 driver does. After that I will add new configuration switch for i2c-gate disable and also change .no_tuner name to better one. Here it is, please review and test. I kept changes as small as possible to prevent errors. Lets fix more later. http://linuxtv.org/hg/~anttip/zl10353/ This patch is good. All work is ok. Antti, since you said that this patch should go to 2.6.29, I've already merged from your tree, after having Dmitry ack. With my best regards, Dmitry. regards Antti -- http://palosaari.fi/ 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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
On Thu, 12 Mar 2009 08:38:59 +0100 Hans Verkuil hverk...@xs4all.nl wrote: Mauro, What the hell??! Since when does a big addition like this get merged without undergoing a public review? I've been working my ass off converting drivers to the new i2c API and v4l2_subdev structures and here you merge a big driver that uses old-style (which will lead to 'deprecated' warnings when compiling with 2.6.29, BTW), where the driver writes directly to i2c modules instead of adding a proper i2c module for them. And what are 'colibri', 'flatrion' and 'hammerhead' anyway? Are they integrated devices of the cx231xx? Can they be used separately in other products as well? So yes, I have objections. At the minimum it should be converted first to use v4l2_device/v4l2_subdev and I need more information on the new i2c devices so I can tell whether the code for those should be split off into separate i2c modules. Not to mention that I want to have the time to review this code more closely. Sorry Sri, this isn't your fault. Hans, I know that you're rushing to convert all drivers to the new model, but you should give time to time. Even with Kernel's fast development cycle, we should take care to not depreciate things faster than developers can track (btw, lwn.net already complained that V4L subsystem changes their APIs faster than usual). Mauro, you did not answer the question why this driver was just merged without going through a public review? If I'd seen it beforehand I'd have worked together with Sri to get it fixed first. I don't expect him to know about this, but I didn't even get a chance to discuss it and help with it. Everyone else has to go through the normal review channels, but apparently this was just fast-tracked and merged. That's not the way to do it. Please back out this driver, put it in a separate tree and let me 1) review this driver first, and 2) help Sri implementing the v4l2_device/v4l2_subdev stuff. First of all, except for ivtv drivers, the first conversion to the new model occurred just few weeks ago. The new model will bring some gains, but this shouldn't stop the merge of the drivers whose development started before we port the drivers used as example by the developer. This is a new model, and we should give people some time to adapt to it. This is the way we worked in the past and it is the way we should keep working. It's not a new model. The I2C core changes went in in 2.6.22. Jean is no longer accepting new i2c drivers that use the old module, and neither should we. And definitely NOT without discussing it first. The old i2c API has been marked deprecated in 2.6.29, and that's for a reason. There are good alternatives for this and I'm available to help with the conversion. Not to mention that this will make Jean quite unhappy. And please note that the use of the old API isn't the only question I have, there are more oddities with the i2c handling that I'd like to have more information about. Writing i2c registers directly from the adapter driver doesn't look good to me at first sight. For example, video_ioctl2 were added several Kernel releases before merging uvc driver. Yet, we've accepted uvc driver without using the new model, because its development that occurred before video_ioctl2. The second point is that there's nothing at Documentation/feature-removal-schedule.txt informing that those stuff is deprecated. Yes it is, see this from the 2.6.29 kernel: What: i2c_attach_client(), i2c_detach_client(), i2c_driver-detach_client() When: 2.6.29 (ideally) or 2.6.30 (more likely) Why:Deprecated by the new (standard) device driver binding model. Use i2c_driver-probe() and -remove() instead. Who:Jean Delvare kh...@linux-fr.org So, we should still accept new drivers without the conversion at least until the end of 2.6.30 window, and add some notice at feature-removal-schedule.txt on 2.6.30 clearly stating what's deprecated and when, before generating penalty over the developers that are using the current drivers as their model of development. In the specific case of cx231xx driver, I've explained to Sri, there are still some issues to be fixed at the driver. Although the driver works, It is not ready for 2.6.30 yet. However, keeping this on a separate tree will just create more mess (according with Sri, he already had to rebase this driver 4 times during 2.6.29-rc cycle, due to the high speed of internal API changes). Since his driver seems to be based on em28xx, he had no sample on how to convert it to v4l2_device/v4l2_subdev/new_i2c model. Again, if I'd known about it I'd be happy to help with it. Why didn't you put me in contact with him? You know I'm spending a lot of time on this. After committing Devin's Austek patches (also seemed to be based on em28xx), it will probably be easier for Uri to convert his driver to the new approach. That depends. As I said, there are other i2c
[PATCH 0/5] V2: soc-camera: setting the buswidth of camera sensors
Take 2: I hope I addressed all comments I receive in the first round. The following patches change the handling of the bus width for camera sensors so that a board can overwrite a sensors native bus width Sascha Hauer (5): soc-camera: add board hook to specify the buswidth for camera sensors pcm990 baseboard: add camera bus width switch setting mt9m001: allow setting of bus width from board code mt9v022: allow setting of bus width from board code soc-camera: remove now unused gpio member of struct soc_camera_link arch/arm/mach-pxa/pcm990-baseboard.c | 49 ++-- drivers/media/video/Kconfig | 14 drivers/media/video/mt9m001.c| 143 ++ drivers/media/video/mt9v022.c| 141 ++--- include/media/soc_camera.h |9 ++- 5 files changed, 129 insertions(+), 227 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 2/5] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
arch/arm/mach-pxa/pcm990-baseboard.c | 49 +++--
1 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..8b01565 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,45 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, camera);
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -399,10 +430,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = pca9536_data,
}, {
I2C_BOARD_INFO(mt9v022, 0x48),
- .platform_data = iclink[0], /* With extender */
+ .platform_data = iclink, /* With extender */
}, {
I2C_BOARD_INFO(mt9m001, 0x5d),
- .platform_data = iclink[0], /* With extender */
+ .platform_data = iclink, /* With extender */
},
};
#endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/5] soc-camera: add board hook to specify the buswidth for camera sensors
Camera sensors have a native bus width say support, but on some
boards not all sensor data lines are connected to the image
interface and thus support a different bus width than the sensors
native one. Some boards even have a bus driver which dynamically
switches between different bus widths with a GPIO.
This patch adds a hook which board code can use to support different
bus widths.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
include/media/soc_camera.h |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index 7440d92..62f07db 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -100,6 +100,13 @@ struct soc_camera_link {
/* Optional callbacks to power on or off and reset the sensor */
int (*power)(struct device *, int);
int (*reset)(struct device *);
+ /*
+* some platforms may support different data widths than the sensors
+* native ones due to different data line routing. Let the board code
+* overwrite the width flags.
+*/
+ int (*set_bus_param)(struct soc_camera_link *, unsigned long flags);
+ unsigned long (*query_bus_param)(struct soc_camera_link *);
};
static inline struct soc_camera_device *to_soc_camera_dev(struct device *dev)
--
1.5.6.5
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/5] mt9m001: allow setting of bus width from board code
This patch removes the phytec specific setting of the bus width
and switches to the more generic query_bus_param/set_bus_param
hooks
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
drivers/media/video/Kconfig |7 --
drivers/media/video/mt9m001.c | 143 +++-
2 files changed, 40 insertions(+), 110 deletions(-)
diff --git a/drivers/media/video/Kconfig b/drivers/media/video/Kconfig
index 19cf3b8..5fc1531 100644
--- a/drivers/media/video/Kconfig
+++ b/drivers/media/video/Kconfig
@@ -728,13 +728,6 @@ config SOC_CAMERA_MT9M001
This driver supports MT9M001 cameras from Micron, monochrome
and colour models.
-config MT9M001_PCA9536_SWITCH
- bool pca9536 datawidth switch for mt9m001
- depends on SOC_CAMERA_MT9M001 GENERIC_GPIO
- help
- Select this if your MT9M001 camera uses a PCA9536 I2C GPIO
- extender to switch between 8 and 10 bit datawidth modes
-
config SOC_CAMERA_MT9M111
tristate mt9m111 and mt9m112 support
depends on SOC_CAMERA I2C
diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c
index c1bf75e..d3bc84c 100644
--- a/drivers/media/video/mt9m001.c
+++ b/drivers/media/video/mt9m001.c
@@ -12,7 +12,6 @@
#include linux/slab.h
#include linux/i2c.h
#include linux/log2.h
-#include linux/gpio.h
#include media/v4l2-common.h
#include media/v4l2-chip-ident.h
@@ -73,9 +72,7 @@ struct mt9m001 {
struct i2c_client *client;
struct soc_camera_device icd;
int model; /* V4L2_IDENT_MT9M001* codes from v4l2-chip-ident.h */
- int switch_gpio;
unsigned char autoexposure;
- unsigned char datawidth;
};
static int reg_read(struct soc_camera_device *icd, const u8 reg)
@@ -181,92 +178,28 @@ static int mt9m001_stop_capture(struct soc_camera_device
*icd)
return 0;
}
-static int bus_switch_request(struct mt9m001 *mt9m001,
- struct soc_camera_link *icl)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- int ret;
- unsigned int gpio = icl-gpio;
-
- if (gpio_is_valid(gpio)) {
- /* We have a data bus switch. */
- ret = gpio_request(gpio, mt9m001);
- if (ret 0) {
- dev_err(mt9m001-client-dev, Cannot get GPIO %u\n,
- gpio);
- return ret;
- }
-
- ret = gpio_direction_output(gpio, 0);
- if (ret 0) {
- dev_err(mt9m001-client-dev,
- Cannot set GPIO %u to output\n, gpio);
- gpio_free(gpio);
- return ret;
- }
- }
-
- mt9m001-switch_gpio = gpio;
-#else
- mt9m001-switch_gpio = -EINVAL;
-#endif
- return 0;
-}
-
-static void bus_switch_release(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (gpio_is_valid(mt9m001-switch_gpio))
- gpio_free(mt9m001-switch_gpio);
-#endif
-}
-
-static int bus_switch_act(struct mt9m001 *mt9m001, int go8bit)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- if (!gpio_is_valid(mt9m001-switch_gpio))
- return -ENODEV;
-
- gpio_set_value_cansleep(mt9m001-switch_gpio, go8bit);
- return 0;
-#else
- return -ENODEV;
-#endif
-}
-
-static int bus_switch_possible(struct mt9m001 *mt9m001)
-{
-#ifdef CONFIG_MT9M001_PCA9536_SWITCH
- return gpio_is_valid(mt9m001-switch_gpio);
-#else
- return 0;
-#endif
-}
-
static int mt9m001_set_bus_param(struct soc_camera_device *icd,
unsigned long flags)
{
struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd);
- unsigned int width_flag = flags SOCAM_DATAWIDTH_MASK;
- int ret;
+ struct soc_camera_link *icl = mt9m001-client-dev.platform_data;
+ unsigned long width_flag = flags SOCAM_DATAWIDTH_MASK;
- /* Flags validity verified in test_bus_param */
+ /* Only one width bit may be set */
+ if (!is_power_of_2(width_flag))
+ return -EINVAL;
- if ((mt9m001-datawidth != 10 (width_flag == SOCAM_DATAWIDTH_10)) ||
- (mt9m001-datawidth != 9 (width_flag == SOCAM_DATAWIDTH_9)) ||
- (mt9m001-datawidth != 8 (width_flag == SOCAM_DATAWIDTH_8))) {
- /* Well, we actually only can do 10 or 8 bits... */
- if (width_flag == SOCAM_DATAWIDTH_9)
- return -EINVAL;
- ret = bus_switch_act(mt9m001,
-width_flag == SOCAM_DATAWIDTH_8);
- if (ret 0)
- return ret;
+ if (icl-set_bus_param)
+ return icl-set_bus_param(icl, width_flag);
- mt9m001-datawidth = width_flag == SOCAM_DATAWIDTH_8 ? 8 : 10;
- }
+ /*
+* Without board specific bus width settings we only support the
+*
[PATCH 1/1] sdio: add low level i/o functions for workarounds
sdio: add low level i/o functions for workarounds
From: Pierre Ossman drz...@drzeus.cx
Some shoddy hardware doesn't properly adhere to the register model
of SDIO, but treats the system like a series of transaction. That means
that the drivers must have full control over what goes the bus (and the
core cannot optimize transactions or work around problems in host
controllers).
This commit adds some low level functions that gives SDIO drivers the
ability to send specific register access commands. They should only be
used when the hardware is truly broken though.
This patch has been created on August 2008, and re-generated against 2.6.29-rc7
.
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -uNr linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c
linux-2.6.29-rc7/drivers/mmc/core/sdio_io.c
--- linux-2.6.29-rc7.prestine/drivers/mmc/core/sdio_io.c2009-03-04
03:05:22.0 +0200
+++ linux-2.6.29-rc7/drivers/mmc/core/sdio_io.c 2009-03-12 12:22:42.0
+0200
@@ -635,3 +635,252 @@
*err_ret = ret;
}
EXPORT_SYMBOL_GPL(sdio_f0_writeb);
+
+/**
+ * sdio_read_bytes - low level byte mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num, addr, 1,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes);
+
+/**
+ * sdio_read_bytes_noincr - low level byte mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @bytes: number of bytes to read
+ *
+ * Performs a byte mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_bytes_noincr(struct sdio_func *func, void *dst,
+ unsigned int addr, int bytes)
+{
+ if (bytes sdio_max_byte_size(func))
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num, addr, 0,
+ dst, 1, bytes);
+}
+EXPORT_SYMBOL_GPL(sdio_read_bytes_noincr);
+
+/**
+ * sdio_read_blocks - low level block mode transfer from an SDIO function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ * sdio_set_block_size().
+ *
+ * Note: This is a low level function that should only be used as a
+ * workaround when the hardware has a crappy register abstraction
+ * that relies on specific SDIO operations.
+ */
+int sdio_read_blocks(struct sdio_func *func, void *dst,
+ unsigned int addr, int blocks)
+{
+ if (!func-card-cccr.multi_block)
+ return -EINVAL;
+
+ if (blocks func-card-host-max_blk_count)
+ return -EINVAL;
+ if (blocks (func-card-host-max_seg_size / func-cur_blksize))
+ return -EINVAL;
+ if (blocks 511)
+ return -EINVAL;
+
+ return mmc_io_rw_extended(func-card, 0, func-num, addr, 1,
+ dst, blocks, func-cur_blksize);
+}
+EXPORT_SYMBOL_GPL(sdio_read_blocks);
+
+/**
+ * sdio_read_blocks_noincr - low level block mode transfer from an SDIO
function
+ * @func: SDIO function to access
+ * @dst: buffer to store the data
+ * @addr: address to begin reading from
+ * @block: number of blocks to read
+ *
+ * Performs a block mode transfer from the address space of the given
+ * SDIO function. The address is NOT increased for each byte. Return
+ * value indicates if the transfer succeeded or not.
+ *
+ * The block size needs to be explicitly changed by calling
+ *
[PULL] Rhttp://linuxtv.org/hg/~mkrufky/lgdt3305 ( was - e: null pointer access in error path of lgdt3305 driver )
Matthias Schwarzott wrote: Hi Michael! Looking at your new lgdt3305 driver, I noticed that the error path of lgdt3305_attach, that is also jumped to kzalloc errors, sets state-frontend.demodulator_priv to NULL. That will oops in case state is NULL. So you either need two goto labels for failures or just return in case kzalloc fails. Regards Matthias Matthias, Thank you for pointing this out -- I am pushing up a fix right now. Mauro, Please pull from: http://linuxtv.org/hg/~mkrufky/lgdt3305 for the following fix, thanks to Matthias: - lgdt3305: avoid OOPS in error path of lgdt3305_attach lgdt3305.c |1 - 1 file changed, 1 deletion(-) Regards, Mike -- 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: [linuxtv-commits] [hg:v4l-dvb] Add cx231xx USB driver
On Thu, 12 Mar 2009 12:14:22 +0100 (CET) Hans Verkuil hverk...@xs4all.nl wrote: Mauro, you did not answer the question why this driver was just merged without going through a public review? If I'd seen it beforehand I'd have worked together with Sri to get it fixed first. I don't expect him to know about this, but I didn't even get a chance to discuss it and help with it. Everyone else has to go through the normal review channels, but apparently this was just fast-tracked and merged. That's not the way to do it. It were added one week ago on a temporary public tree, at linuxtv. Please back out this driver, put it in a separate tree and let me 1) review this driver first, and 2) help Sri implementing the v4l2_device/v4l2_subdev stuff. It is better to review it at the tree. I won't merge it upstream until the remaining bugs would be fixed. Until then, it will wait on my staging -git tree (the pending tree). First of all, except for ivtv drivers, the first conversion to the new model occurred just few weeks ago. The new model will bring some gains, but this shouldn't stop the merge of the drivers whose development started before we port the drivers used as example by the developer. This is a new model, and we should give people some time to adapt to it. This is the way we worked in the past and it is the way we should keep working. It's not a new model. It is. The first changeset were committed on Nov, 30, and the last internal API changes, according with the docs, happened on Feb, 14. So, if we don't touch on it, the first stable version of the framework will be available upstream on 2.6.30. If we keep it stable during 2.6.30, convert the drivers merged on 2.6.30 to the new framework, and mark the legacy approach as a feature to be removed on a patch applied at 2.6.30, then we can remove the previous support for 2.6.31. $ hg log linux/Documentation/video4linux/v4l2-framework.txt changeset: 10648:e471b963bef6 parent: 10640:4f6c3f9efa58 parent: 10647:63256532f5a7 user:Mauro Carvalho Chehab mche...@redhat.com date:Tue Feb 17 23:44:45 2009 -0300 summary: merge: http://www.linuxtv.org/hg/~hverkuil/v4l-dvb changeset: 10644:44b5df81ab02 user:Hans Verkuil hverk...@xs4all.nl date:Sat Feb 14 16:00:53 2009 +0100 summary: v4l2-subdev: rename dev field to v4l2_dev changeset: 10643:9eb2f6220a18 user:Hans Verkuil hverk...@xs4all.nl date:Sat Feb 14 15:54:23 2009 +0100 summary: v4l2-device: allow a NULL parent device when registering. changeset: 10573:b73e7bdad8c4 user:Mauro Carvalho Chehab mche...@redhat.com date:Mon Feb 16 15:54:29 2009 -0300 summary: v4l2-framework.txt: Whitespace clenups changeset: 10571:12a10f808bfd user:Mauro Carvalho Chehab mche...@redhat.com date:Sat Feb 14 08:51:28 2009 -0200 summary: v4l2-framework.txt: Fixes the videobuf init functions changeset: 10570:6f4cff0e7f16 user:Mauro Carvalho Chehab mche...@redhat.com date:Sat Feb 14 08:29:07 2009 -0200 summary: v4l2-framework: documments videobuf usage on drivers changeset: 10489:c84416787a43 user:Mauro Carvalho Chehab mche...@redhat.com date:Sat Feb 07 11:07:04 2009 +0100 summary: doc: use consistent naming conventions for vdev and v4l2_dev. changeset: 10252:09cabe4f0c63 user:Hans Verkuil hverk...@xs4all.nl date:Thu Jan 15 10:09:05 2009 +0100 summary: v4l2 doc: explain why v4l2_device_unregister_subdev() has to be called. changeset: 10141:4cc8ed11e2e0 user:Hans Verkuil hverk...@xs4all.nl date:Tue Dec 30 11:14:19 2008 +0100 summary: v4l2: debugging API changed to match against driver name instead of ID. changeset: 10136:ffe112f306a3 user:Hans Verkuil hverk...@xs4all.nl date:Tue Dec 23 17:42:25 2008 +0100 summary: v4l2 doc: update v4l2-framework.txt changeset: 10134:a11cf6774c04 user:Hans Verkuil hverk...@xs4all.nl date:Tue Dec 23 16:17:23 2008 +0100 summary: v4l2 doc: set v4l2_dev instead of parent. changeset: 10133:f03ab4ab3f87 user:Hans Verkuil hverk...@xs4all.nl date:Mon Dec 22 13:13:11 2008 +0100 summary: v4l2-framework: use correct comment style. changeset: 9943:2e680d8a3b2f user:Hans Verkuil hverk...@xs4all.nl date:Fri Dec 19 14:20:22 2008 +0100 summary: v4l2: document video_device. changeset: 9820:5611723c9512 parent: 9767:7100e78482d7 user:Hans Verkuil hverk...@xs4all.nl date:Sun Nov 30 01:36:58 2008 +0100 summary: v4l2: add v4l2_device and v4l2_subdev structs to the v4l2 framework. The I2C core changes went in in 2.6.22. I'm not referring to i2c core changes, but to v4l2 dev/subdev stuff. And please note that the use of the old API isn't the only question I have, there are more oddities with the i2c handling that I'd like to have more information about. Writing
Re: [PATCH 0/5] V2: soc-camera: setting the buswidth of camera sensors
On Thu, 12 Mar 2009, Sascha Hauer wrote: Take 2: I hope I addressed all comments I receive in the first round. The following patches change the handling of the bus width for camera sensors so that a board can overwrite a sensors native bus width Sascha Hauer (5): soc-camera: add board hook to specify the buswidth for camera sensors pcm990 baseboard: add camera bus width switch setting mt9m001: allow setting of bus width from board code mt9v022: allow setting of bus width from board code soc-camera: remove now unused gpio member of struct soc_camera_link Ok, the rest look good to me. So, after you fix or explain 2/5 I'll be pulling them. arch/arm/mach-pxa/pcm990-baseboard.c | 49 ++-- drivers/media/video/Kconfig | 14 drivers/media/video/mt9m001.c| 143 ++ drivers/media/video/mt9v022.c| 141 ++--- include/media/soc_camera.h |9 ++- 5 files changed, 129 insertions(+), 227 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Wed, 11 Mar 2009 11:25:20 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: Hello Mauro, Please pull from: http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 for the following: xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 au8522: rename the au8522.c source file au8522: move shared state and common functions into a separate header files au8522: fix register read/write high bits au8522: power down the digital demod when not in use au8522: make use of hybrid framework so analog/digital demod can share state au8522: add support for analog side of demodulator au0828: add support for analog functionality in bridge au0828: workaround a bug in the au0828 i2c handling au0828: add analog profile for the HVR-850 au8522: add mutex protecting use of hybrid state au0828: Rework the way the analog video binding occurs tveeprom: add the xc5000 tuner to the tveeprom definition au0828: advertise only NTSC-M (as opposed to all NTSC standards) au0828: disable VBI code since it doesn't yet work au0828: fix i2c enumeration bug au0828: make register debug lines easier to read au0828: make g_chip_ident call work properly au0828: properly handle missing analog USB endpoint au0828: properly handle non-existent analog inputs au0828: fix panic on disconnect if analog initialization failed au0828: Convert to use v4l2_device/subdev framework Hi Devin, Can you also do the last bit of the v4l2_device/subdev conversion by actually using the subdev callbacks (replace au0828_call_i2c_clients with v4l2_device_call_all), removing attach_inform and detach_inform (already deprecated in 2.6.29) and in au8522_decoder.c replacing v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. Basically, when you compile against 2.6.29 you shouldn't see any 'deprecated' warnings! I also suggest renaming au8522_decoder.c to just au8522.c, like all the other i2c modules. Hans, There was already a au8522.c in the master branch before Devin's patches -- au8522.c is located in drivers/media/dvb/frontends -- it is an ATSC/QAM demodulator modulator. Devin had renamed au8522.c to au8522_dig.c , so that it can be built with au8522_decoder.c into a single module. It is important that this remain a single module, because there is state being shared between the analog and digitial sides of this device. This is a hybrid demodulator, the first of it's kind within our codebase. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1236865697 -7200
# Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
# Parent 3392722cc5b687586c4d898b73050ab6e59bf401
siano: add high level SDIO interface driver for SMS based cards
From: Uri Shkolnik u...@siano-ms.com
This patch provides SDIO interface driver for
SMS (Siano Mobile Silicon) based devices.
The patch includes SMS high level SDIO driver and
requires patching the kernel SDIO stack,
those stack patches had been provided previously.
I would like to thank Pierre Ossman, MMC maintainer,
who wrote this driver.
Priority: normal
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 3392722cc5b6 -r 7352ee1288f6 linux/drivers/media/dvb/siano/smssdio.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smssdio.c Thu Mar 12 15:48:17 2009 +0200
@@ -0,0 +1,356 @@
+/*
+ * smssdio.c - Siano 1xxx SDIO interface driver
+ *
+ * Copyright 2008 Pierre Ossman
+ *
+ * Based on code by Siano Mobile Silicon, Inc.,
+ * Copyright (C) 2006-2008, Uri Shkolnik
+ *
+ * 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.
+ *
+ *
+ * This hardware is a bit odd in that all transfers should be done
+ * to/from the SMSSDIO_DATA register, yet the increase address bit
+ * always needs to be set.
+ *
+ * Also, buffers from the card are always aligned to 128 byte
+ * boundaries.
+ */
+
+/*
+ * General cleanup notes:
+ *
+ * - only typedefs should be name *_t
+ *
+ * - use ERR_PTR and friends for smscore_register_device()
+ *
+ * - smscore_getbuffer should zero fields
+ *
+ * Fix stop command
+ */
+
+#include linux/moduleparam.h
+#include linux/firmware.h
+#include linux/delay.h
+#include linux/mmc/card.h
+#include linux/mmc/sdio_func.h
+#include linux/mmc/sdio_ids.h
+
+#include smscoreapi.h
+#include sms-cards.h
+
+/* Registers */
+
+#define SMSSDIO_DATA 0x00
+#define SMSSDIO_INT0x04
+
+static const struct sdio_device_id smssdio_ids[] = {
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
+.driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
+.driver_data = SMS1XXX_BOARD_SIANO_NOVA_A},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_B0),
+.driver_data = SMS1XXX_BOARD_SIANO_NOVA_B},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VEGA_A0),
+.driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VENICE),
+.driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ { /* end: all zeroes */ },
+};
+
+MODULE_DEVICE_TABLE(sdio, smssdio_ids);
+
+struct smssdio_device {
+ struct sdio_func *func;
+
+ struct smscore_device_t *coredev;
+
+ struct smscore_buffer_t *split_cb;
+};
+
+/***/
+/* Siano core callbacks*/
+/***/
+
+static int smssdio_sendrequest(void *context, void *buffer, size_t size)
+{
+ int ret;
+ struct smssdio_device *smsdev;
+
+ smsdev = context;
+
+ sdio_claim_host(smsdev-func);
+
+ while (size = smsdev-func-cur_blksize) {
+ ret = sdio_write_blocks(smsdev-func, SMSSDIO_DATA, buffer, 1);
+ if (ret)
+ goto out;
+
+ buffer += smsdev-func-cur_blksize;
+ size -= smsdev-func-cur_blksize;
+ }
+
+ if (size) {
+ ret = sdio_write_bytes(smsdev-func, SMSSDIO_DATA,
+ buffer, size);
+ if (ret)
+ goto out;
+ }
+
+out:
+ sdio_release_host(smsdev-func);
+
+ return ret;
+}
+
+/***/
+/* SDIO callbacks */
+/***/
+
+static void smssdio_interrupt(struct sdio_func *func)
+{
+ int ret, isr;
+
+ struct smssdio_device *smsdev;
+ struct smscore_buffer_t *cb;
+ struct SmsMsgHdr_ST *hdr;
+ size_t size;
+
+ smsdev = sdio_get_drvdata(func);
+
+ /*
+* The interrupt register has no defined meaning. It is just
+* a way of turning of the level triggered interrupt.
+*/
+ isr = sdio_readb(func, SMSSDIO_INT, ret);
+ if (ret) {
+ dev_err(smsdev-func-dev,
+ Unable to read interrupt register!\n);
+ return;
+ }
+
+ if (smsdev-split_cb == NULL) {
+ cb =
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Wed, 11 Mar 2009 11:25:20 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: Hello Mauro, Please pull from: http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2 for the following: xc5000: fix bug for hybrid xc5000 devices with IF other than 5380 au8522: rename the au8522.c source file au8522: move shared state and common functions into a separate header files au8522: fix register read/write high bits au8522: power down the digital demod when not in use au8522: make use of hybrid framework so analog/digital demod can share state au8522: add support for analog side of demodulator au0828: add support for analog functionality in bridge au0828: workaround a bug in the au0828 i2c handling au0828: add analog profile for the HVR-850 au8522: add mutex protecting use of hybrid state au0828: Rework the way the analog video binding occurs tveeprom: add the xc5000 tuner to the tveeprom definition au0828: advertise only NTSC-M (as opposed to all NTSC standards) au0828: disable VBI code since it doesn't yet work au0828: fix i2c enumeration bug au0828: make register debug lines easier to read au0828: make g_chip_ident call work properly au0828: properly handle missing analog USB endpoint au0828: properly handle non-existent analog inputs au0828: fix panic on disconnect if analog initialization failed au0828: Convert to use v4l2_device/subdev framework Hi Devin, Can you also do the last bit of the v4l2_device/subdev conversion by actually using the subdev callbacks (replace au0828_call_i2c_clients with v4l2_device_call_all), removing attach_inform and detach_inform (already deprecated in 2.6.29) and in au8522_decoder.c replacing v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. Basically, when you compile against 2.6.29 you shouldn't see any 'deprecated' warnings! I also suggest renaming au8522_decoder.c to just au8522.c, like all the other i2c modules. Hans, There was already a au8522.c in the master branch before Devin's patches -- au8522.c is located in drivers/media/dvb/frontends -- it is an ATSC/QAM demodulator modulator. Devin had renamed au8522.c to au8522_dig.c , so that it can be built with au8522_decoder.c into a single module. It is important that this remain a single module, because there is state being shared between the analog and digitial sides of this device. This is a hybrid demodulator, the first of it's kind within our codebase. Ah, thank you for the explanation. No need for a rename then :-) Thanks, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 4:54 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, There's a bug on your patch series: see this: Those are the locations of au8522 files at Kernel's tree: drivers/media/dvb/frontends/au8522.h drivers/media/dvb/frontends/au8522_dig.c drivers/media/dvb/frontends/au8522_priv.h drivers/media/video/au8522_decoder.c And those are the Makefile rules for au8522.h on drivers/media/dvb/frontends/Makefile: au8522-objs = au8522_dig.o au8522_decoder.o obj-$(CONFIG_DVB_AU8522) += au8522.o When you're compiling the out-of-tree version, everything works OK, but, for in-tree compilation, au8522_decoder won't be compiled, since the file will be in the wrong dir. If I'm understanding well, this chip has two functions: it is a dvb frontend and an analog video/audio demodulator, right? One solution would be to have all those files in the same directory. However, au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, otherwise common/tuners would be another better place. Another alternative would be to create two kconfig rules (and two separate modules), being one for au8522_decoder and another for the frontend, since they are, in fact, two different things. I suspect,however, that compiling just one or another would break compilation. So, we need to create some sort of rules that will warrant that both modules will be compiled at the same time. This is not an easy task, since we cannot add depends on, since frontends are compiled by using select. So, we will need to re-design the Kconfig rules to use depends on instead of select (well, this is something good, anyway, since the usage of select is something that should be avoided, according with Kbuild docs). I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, I'll need to blacklist the module until we found a solution, or find a way to allow my -git trees to compile. Cheers, Mauro Hello Mauro, Both files are required, as they share certain functions (such as the i2c transfer functions). Also, they share a common state mechanism, which is why both files end up in the same .ko file. This case is a little unique since it is the first case where we have a single chip that acts as a digital demod, an analog demod, and an analog video/audio decoder. I can certainly put the au8522_decoder.c into dvb/frontends even though this probably violates some rule about analog stuff being in the DVB section of the tree. Would that resolve your concern? I really don't want to make redesigning the KConfig rules a prerequisite to getting this rather large patch series merged. I would suggest we do what is required to get the code in (such as moving the _decoder.c to frontends), and then we can tune the solution to be something more optimal in terms of how the tree is structured. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 02:12:09PM +0100, Guennadi Liakhovetski wrote:
On Thu, 12 Mar 2009, Sascha Hauer wrote:
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
arch/arm/mach-pxa/pcm990-baseboard.c | 49
+++--
1 files changed, 40 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..8b01565 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,45 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0)
+ return 0;
Are you really sure you don't want to return an error here? In
query_bus_param() below, if you fail to get the GPIO, you set
gpio_bus_switch to -EINVAL and return only 10 bit. Now if a buggy host
driver still requests 8 bits, mt9m001 will call -set_bus_param and you
will happily return 0...
Of course there are no buggy host drivers ;)
Ok, changed it to support only ten bit without gpio switch and return
-EINVAL for any other width.
Sasche
From 58485f136579273d4da41d65974ce6ed02ba877a Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Tue, 10 Mar 2009 16:45:58 +0100
Subject: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
---
arch/arm/mach-pxa/pcm990-baseboard.c | 53 --
1 files changed, 44 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 34841c7..fd8f786 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -381,14 +381,49 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0) {
+ if (flags == SOCAM_DATAWIDTH_10)
+ return 0;
+ else
+ return -EINVAL;
+ }
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, camera);
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -399,10 +434,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = pca9536_data,
}, {
I2C_BOARD_INFO(mt9v022, 0x48),
- .platform_data = iclink[0], /* With extender */
+ .platform_data = iclink, /* With extender */
}, {
I2C_BOARD_INFO(mt9m001, 0x5d),
-
Re: [PATCH 0/5] V2: soc-camera: setting the buswidth of camera sensors
On Thu, Mar 12, 2009 at 02:31:17PM +0100, Guennadi Liakhovetski wrote: On Thu, 12 Mar 2009, Sascha Hauer wrote: Take 2: I hope I addressed all comments I receive in the first round. The following patches change the handling of the bus width for camera sensors so that a board can overwrite a sensors native bus width Sascha Hauer (5): soc-camera: add board hook to specify the buswidth for camera sensors pcm990 baseboard: add camera bus width switch setting mt9m001: allow setting of bus width from board code mt9v022: allow setting of bus width from board code soc-camera: remove now unused gpio member of struct soc_camera_link Ok, the rest look good to me. So, after you fix or explain 2/5 I'll be pulling them. If by pulling you mean 'git pull' you can do it here: git://git.pengutronix.de/git/sha/linux-2.6.git soc-camera-bus-switch Thanks Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0| Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- | -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 5:19 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Devin, Can you also do the last bit of the v4l2_device/subdev conversion by actually using the subdev callbacks (replace au0828_call_i2c_clients with v4l2_device_call_all), removing attach_inform and detach_inform (already deprecated in 2.6.29) and in au8522_decoder.c replacing v4l2-i2c-drv-legacy.h by v4l2-i2c-drv.h and removing the au8522_command. Basically, when you compile against 2.6.29 you shouldn't see any 'deprecated' warnings! I also suggest renaming au8522_decoder.c to just au8522.c, like all the other i2c modules. Hello Hans, I am certainly in favor of what you have proposed. However, I would like to do it as an incremental improvement over what the series currently contains. Any chance you can allow the current series to go in as-is, and I can work on this over the next couple of days (as I will need to retest everything)? The patch series has gotten kind of unwieldy. No problem. It's fairly trivial to do since you're 90% there already :-) Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
Hello Mauro,
Thank you for reviewing. See comments inline.
On Thu, Mar 12, 2009 at 6:06 AM, Mauro Carvalho Chehab
mche...@infradead.org wrote:
+static int vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *cap)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh-dev;
+
+ memset(cap, 0, sizeof(*cap));
Please remove all memsets for input/output arguments on vidioc_foo at
au0828-video.c.
The V4L2 core warrants that the non-input fields are zeroed.
Ok.
+static int vidioc_enum_fmt_vid_cap(struct file *file, void *priv,
+ struct v4l2_fmtdesc *f)
+{
+ if(f-index)
+ return -EINVAL;
+
+ memset(f, 0, sizeof(*f));
+ f-type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
+ strcpy(f-description, Packed YUV2);
+
+ f-flags = 0;
+ f-pixelformat = V4L2_PIX_FMT_UYVY;
+
+ memset(f-reserved, 0, sizeof(f-reserved));
+ return 0;
+}
hmm.. you are cleaning up f-reserved three times: at v4l2-ioctl, at the
memset(f) and at memset(f-reserved).
You really wanted to make sure that you've cleaned it, don't you? ;)
Well, I wanted to be *extra* sure. ;-) Yeah, I'll yank the duplicate code.
hmm...
+#ifdef VBI_NOT_YET_WORKING
+ .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+ .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+#endif
I don't see any reference of this macro. If VBI is working, please cleanup the
driver. Btw, your logic seems to be inverted on some cases. Why are you adding
VBI macros, if it is not working yet?
On the other hand, if VBI is broken we'll need some rules for removing vbi
code
from upstream, at gentree.pl.
Here's the situation with VBI: I did all the groundwork, but it
doesn't work yet. I am hoping on getting it working over the next
couple of weeks. I believed that #ifdef'ing out the code was the
safest way to ensure that the code does not get called, while not
having to remove it from the tree entirely.
If this is important to you that the code not appear in the source
tree at all until it works entirely, then I will remove the VBI code
entirely.
+enum au0828_itype {
+ AU0828_VMUX_UNDEFINED = 0,
+ AU0828_VMUX_COMPOSITE,
+ AU0828_VMUX_SVIDEO,
+ AU0828_VMUX_CABLE,
+ AU0828_VMUX_TELEVISION,
+ AU0828_VMUX_DVB,
+ AU0828_VMUX_DEBUG
+};
...
+static int vidioc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *input)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh-dev;
+ unsigned int tmp;
+
+ static const char *inames[] = {
+ [AU0828_VMUX_COMPOSITE] = Composite,
+ [AU0828_VMUX_SVIDEO] = S-Video,
+ [AU0828_VMUX_CABLE] = Cable TV,
+ [AU0828_VMUX_TELEVISION] = Television,
+ [AU0828_VMUX_DVB] = DVB,
+ [AU0828_VMUX_DEBUG] = tv debug
+ };
If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is it
what you really wanted? I would, instead, assign another value for
AU0828_VMUX_UNDEFINED, like -1.
Yeah, printing NULL is bad and I can obviously fix that. The real
reason for the addition of the UNDEFINED entry is I use that to
detect if there are *any* analog inputs defined, which dictates
whether the analog subsystem is initialized. Because the .input
section is a member of the au0828_dev struct, and not a pointer, I
needed some way to tell if it was populated with anything.
+ switch(AUVI_INPUT(index).type) {
+ case AU0828_VMUX_SVIDEO:
+ {
+ dev-input_type = AU0828_VMUX_SVIDEO;
+ break;
+ }
+ case AU0828_VMUX_COMPOSITE:
+ {
+ dev-input_type = AU0828_VMUX_COMPOSITE;
+ break;
+ }
+ case AU0828_VMUX_TELEVISION:
+ {
+ dev-input_type = AU0828_VMUX_TELEVISION;
+ break;
+ }
+ default:
+ ;
+ }
You don't need all those braces.
I will remove the braces.
Also, the default rule is missing. I don't see why you would preserve the same
dev-input_type if the user selects an undefined entry, or a DVB or a debug.
I will fix that.
Ah, finally, there are a number of CodingStyle fun. I've enclosed what it got,
from the final code. Please, always use make checkpatch before committing a
patch.
I rather foolishly assumed that make commit ran make checkpatch.
I looked at the list and all of these issues are easy to fix, and I
will do that tonight.
Please let me know if you have any other concerns (and what you want
me to do regarding the VBI stuff), since I would like to avoid having
do redo the tree again.
Thanks,
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM:
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Mauro and all, I submitted 3 patches, two modifications for the SDIO generic stack, and one new high level SDIO interface driver for Siano based devices. This concludes SDIO related changes, with one exception, which is explained below. However this explanation requires some overview about Siano's module inner architecture. The Siano kernel module architecture is composed from: 1) SMS Core - This main component holds all Siano's host-device protocol logic, and any logic needed to bind the other module's components, interface and adapters. 2) Interfaces drivers (SDIO, USB, TS, SPP, HIF, ...) - At lease one interface driver must be compiled and linked, but multiple interfaces are supported. This feature enables platforms like the Asus UMPC series to use SMS based USB dongle and SMS based SDIO dongle simultaneously. 3) Client adapters (DVB API v3, DVB API v5, others) - Similar to the interfaces drivers, at least one client adapter must be linked, but multiple are supported. 4) SMS cards - This component contains any hardware target specific information (like LEDs locations, antenna configuration, alternative firmware names, and much more), leaving any other component target-independent. And now back to SDIO True all SDIO related sources files are now updated (after these 3 patches), but since the build system (Kconfig Makefile) and smscore component are yet to be updated, the SDIO interface driver can not be linked into the module. The option to link and use the SDIO interface driver, will be available after those files will be updated (hope it'll happen shortly). One question: Should I continue submit patches (I have them ready), or should I wait till the 3 previous submission will be reviewed and committed? Regards, Uri -- 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://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 10:24:02 -0400
Devin Heitmueller devin.heitmuel...@gmail.com wrote:
hmm.. you are cleaning up f-reserved three times: at v4l2-ioctl, at the
memset(f) and at memset(f-reserved).
You really wanted to make sure that you've cleaned it, don't you? ;)
Well, I wanted to be *extra* sure. ;-) Yeah, I'll yank the duplicate code.
LOL
hmm...
+#ifdef VBI_NOT_YET_WORKING
+ .vidioc_g_fmt_vbi_cap = vidioc_g_fmt_vbi_cap,
+ .vidioc_try_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+ .vidioc_s_fmt_vbi_cap = vidioc_s_fmt_vbi_cap,
+#endif
I don't see any reference of this macro. If VBI is working, please cleanup
the
driver. Btw, your logic seems to be inverted on some cases. Why are you
adding
VBI macros, if it is not working yet?
On the other hand, if VBI is broken we'll need some rules for removing vbi
code
from upstream, at gentree.pl.
Here's the situation with VBI: I did all the groundwork, but it
doesn't work yet. I am hoping on getting it working over the next
couple of weeks. I believed that #ifdef'ing out the code was the
safest way to ensure that the code does not get called, while not
having to remove it from the tree entirely.
If this is important to you that the code not appear in the source
tree at all until it works entirely, then I will remove the VBI code
entirely.
Hmm... So, I understood just the opposite ;)
you wrote if VBI_IS_NOT_WORKING, when you should have written if
VBI_IS_WORKING.
Just rename it. I'll add it at gentree.pl to remove this symbol.
+enum au0828_itype {
+ AU0828_VMUX_UNDEFINED = 0,
+ AU0828_VMUX_COMPOSITE,
+ AU0828_VMUX_SVIDEO,
+ AU0828_VMUX_CABLE,
+ AU0828_VMUX_TELEVISION,
+ AU0828_VMUX_DVB,
+ AU0828_VMUX_DEBUG
+};
...
+static int vidioc_enum_input(struct file *file, void *priv,
+ struct v4l2_input *input)
+{
+ struct au0828_fh *fh = priv;
+ struct au0828_dev *dev = fh-dev;
+ unsigned int tmp;
+
+ static const char *inames[] = {
+ [AU0828_VMUX_COMPOSITE] = Composite,
+ [AU0828_VMUX_SVIDEO] = S-Video,
+ [AU0828_VMUX_CABLE] = Cable TV,
+ [AU0828_VMUX_TELEVISION] = Television,
+ [AU0828_VMUX_DVB] = DVB,
+ [AU0828_VMUX_DEBUG] = tv debug
+ };
If the user enumerates an entry marked as UNDEFINED, it will print NULL. Is
it
what you really wanted? I would, instead, assign another value for
AU0828_VMUX_UNDEFINED, like -1.
Yeah, printing NULL is bad and I can obviously fix that. The real
reason for the addition of the UNDEFINED entry is I use that to
detect if there are *any* analog inputs defined, which dictates
whether the analog subsystem is initialized. Because the .input
section is a member of the au0828_dev struct, and not a pointer, I
needed some way to tell if it was populated with anything.
if you attribute it to -1, the userspace calls will never set it to undefined.
You should take some care to avoid reading outside some array though.
Ah, finally, there are a number of CodingStyle fun. I've enclosed what it
got,
from the final code. Please, always use make checkpatch before committing a
patch.
I rather foolishly assumed that make commit ran make checkpatch.
It runs, and outputs its result at the commit comments.
I looked at the list and all of these issues are easy to fix, and I
will do that tonight.
Ok.
Please let me know if you have any other concerns (and what you want
me to do regarding the VBI stuff), since I would like to avoid having
do redo the tree again.
No, just the above. Please, instead of redo the tree, just add some patches
fixing those issues. This allows me to review faster your series.
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: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, Mar 12, 2009 at 11:06 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Yeah, printing NULL is bad and I can obviously fix that. The real reason for the addition of the UNDEFINED entry is I use that to detect if there are *any* analog inputs defined, which dictates whether the analog subsystem is initialized. Because the .input section is a member of the au0828_dev struct, and not a pointer, I needed some way to tell if it was populated with anything. if you attribute it to -1, the userspace calls will never set it to undefined. You should take some care to avoid reading outside some array though. The problem is that I check for UNDEFINED so that the .input section of the au0828 board definition can be left uninitialized. Otherwise, I would have to add something like num_inputs to the board definition and worry about the value matching the actual number of inputs defined. I looked at the list and all of these issues are easy to fix, and I will do that tonight. Ok. Please let me know if you have any other concerns (and what you want me to do regarding the VBI stuff), since I would like to avoid having do redo the tree again. No, just the above. Please, instead of redo the tree, just add some patches fixing those issues. This allows me to review faster your series. Do you mean the checkpatch fixes should be done as a separate patch too? I assumed you wanted me to fix the original patch to pass make checkpatch. Is there a way to do the equivalent of make checkpatch against particular hg revisions or source files? I'm just trying to understand the best way to ensure that all of the issues actually get fixed. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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] mt9t031 bugfix
On Fri, 6 Mar 2009, Philippe Rétornaz wrote: - The video device is not allocated when mt9t031_init() is called, don't use it in debug printk. - The clock polarity is inverted in mt9t031_set_bus_param(), use the correct one. Signed-off-by: Philippe Rétornaz philippe.retor...@epfl.ch --- diff --git a/drivers/media/video/mt9t031.c b/drivers/media/video/mt9t031.c index acc1fa9..d846110 100644 --- a/drivers/media/video/mt9t031.c +++ b/drivers/media/video/mt9t031.c @@ -144,8 +144,6 @@ static int mt9t031_init(struct soc_camera_device *icd) int ret; /* Disable chip output, synchronous option update */ - dev_dbg(icd-vdev-parent, %s\n, __func__); - ret = reg_write(icd, MT9T031_RESET, 1); if (ret = 0) ret = reg_write(icd, MT9T031_RESET, 0); @@ -186,9 +184,9 @@ static int mt9t031_set_bus_param(struct soc_camera_device *icd, return -EINVAL; if (flags SOCAM_PCLK_SAMPLE_FALLING) - reg_set(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); - else reg_clear(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); + else + reg_set(icd, MT9T031_PIXEL_CLOCK_CONTROL, 0x8000); Why do you think this is the correct one? According to the Pin Description Table (Table 3 on page 8 in my copy), indeed, it says quote Pixel clock: pixel data outputs are valid during falling edge of this clock. /quote which _probably_ should refer to the default configuration, which is R10=0, i.e., non-inverted pixclk. In this case you are right. However, in Figure Pixel Color Pattern Detail (Top Right Corner) (Figure 5 on page 10) you see the first pixel green in a red row, and this is what I seem to be getting with the current driver, after applying your patch I'm getting a red pixel at the start. Are you basing your patch only on Table 3 or you verified it practically somehow? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 Email: off...@denx.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
[PULL] gspca
Hi Mauro, Is there any problem with these changesets from http://linuxtv.org/hg/~jfrancois/v4l-dvb/ ? changeset: 10789:57bfe95f2ac1 gspca - most jpeg subdrivers: Change the JPEG header creation. changeset: 10790:2a1b8f88f331 gspca - most jpeg subdrivers: Have the JPEG quality settable. Cheers. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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.22 and up: ERRORS, 2.6.16-2.6.21: 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:Thu Mar 12 19:00:05 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 10979:0475dee8dab8 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-rc7-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: OK linux-2.6.29-rc7-armv5-ixp: OK linux-2.6.27-armv5-omap2: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-rc7-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-rc7-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-rc7-m32r: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-rc7-mips: WARNINGS linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-rc7-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-rc7-x86_64: WARNINGS fw/apps: OK sparse (linux-2.6.28): ERRORS sparse (linux-2.6.29-rc7): ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] pcm990 baseboard: add camera bus width switch setting
On Thu, Mar 12, 2009 at 08:11:27PM +0100, Guennadi Liakhovetski wrote:
...one more thing. I noticed, that after patch 2 the cameras would stop
work, because iclink-gpio would be set to 0. Which would break bisection.
Ok, this is rather theoretical, still I modified the patches a bit.
Please, have a look, if you're ok with these changes, that's how I'm going
to commit them. Affected are patches 2/5 and 5/5. I'm just quoting them
below.
Yes, I was aware of this bisection problem. I just wanted to avoid
having patch 5/5 touch arch/arm and include/media or even split this
up further.
Anyway, I'm fine with the change.
Sascha
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
From 80912f8e2bbbf0f81318c68e1bd5f69fc9537795 Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Thu, 12 Mar 2009 20:04:43 +0100
Subject: [PATCH] pcm990 baseboard: add camera bus width switch setting
Some Phytec cameras have a I2C GPIO expander which allows it to
switch between different sensor bus widths. This was previously
handled in the camera driver. Since handling of this switch
varies on several boards the cameras are used on, the board
support seems a better place to handle the switch
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/arm/mach-pxa/pcm990-baseboard.c | 54 -
1 files changed, 45 insertions(+), 9 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index f46698e..90a3990 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -380,14 +380,50 @@ static struct pca953x_platform_data pca9536_data = {
.gpio_base = NR_BUILTIN_GPIO + 1,
};
-static struct soc_camera_link iclink[] = {
- {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = NR_BUILTIN_GPIO + 1,
- }, {
- .bus_id = 0, /* Must match with the camera ID above */
- .gpio = -ENXIO,
+static int gpio_bus_switch;
+
+static int pcm990_camera_set_bus_param(struct soc_camera_link *link,
+ unsigned long flags)
+{
+ if (gpio_bus_switch = 0) {
+ if (flags == SOCAM_DATAWIDTH_10)
+ return 0;
+ else
+ return -EINVAL;
+ }
+
+ if (flags SOCAM_DATAWIDTH_8)
+ gpio_set_value(gpio_bus_switch, 1);
+ else
+ gpio_set_value(gpio_bus_switch, 0);
+
+ return 0;
+}
+
+static unsigned long pcm990_camera_query_bus_param(struct soc_camera_link
*link)
+{
+ int ret;
+
+ if (!gpio_bus_switch) {
+ ret = gpio_request(NR_BUILTIN_GPIO + 1, camera);
+ if (!ret) {
+ gpio_bus_switch = NR_BUILTIN_GPIO + 1;
+ gpio_direction_output(gpio_bus_switch, 0);
+ } else
+ gpio_bus_switch = -EINVAL;
}
+
+ if (gpio_bus_switch 0)
+ return SOCAM_DATAWIDTH_8 | SOCAM_DATAWIDTH_10;
+ else
+ return SOCAM_DATAWIDTH_10;
+}
+
+static struct soc_camera_link iclink = {
+ .bus_id = 0, /* Must match with the camera ID above */
+ .gpio = NR_BUILTIN_GPIO + 1,
+ .query_bus_param = pcm990_camera_query_bus_param,
+ .set_bus_param = pcm990_camera_set_bus_param,
};
/* Board I2C devices. */
@@ -398,10 +434,10 @@ static struct i2c_board_info __initdata
pcm990_i2c_devices[] = {
.platform_data = pca9536_data,
}, {
I2C_BOARD_INFO(mt9v022, 0x48),
- .platform_data = iclink[0], /* With extender */
+ .platform_data = iclink, /* With extender */
}, {
I2C_BOARD_INFO(mt9m001, 0x5d),
- .platform_data = iclink[0], /* With extender */
+ .platform_data = iclink, /* With extender */
},
};
#endif /* CONFIG_VIDEO_PXA27x ||CONFIG_VIDEO_PXA27x_MODULE */
--
1.5.4
From 2d9b3eb219c391f9d626ae63835c8224ea8ef10e Mon Sep 17 00:00:00 2001
From: Sascha Hauer s.ha...@pengutronix.de
Date: Thu, 12 Mar 2009 20:06:01 +0100
Subject: [PATCH] soc-camera: remove now unused gpio member of struct
soc_camera_link
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
arch/arm/mach-pxa/pcm990-baseboard.c |1 -
include/media/soc_camera.h |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/arch/arm/mach-pxa/pcm990-baseboard.c
b/arch/arm/mach-pxa/pcm990-baseboard.c
index 90a3990..6112740 100644
--- a/arch/arm/mach-pxa/pcm990-baseboard.c
+++ b/arch/arm/mach-pxa/pcm990-baseboard.c
@@ -421,7 +421,6 @@ static unsigned long pcm990_camera_query_bus_param(struct
soc_camera_link *link)
static struct soc_camera_link
Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Can we have this merged into -stable? Jarod Wilson sent this last
month, but he left off the cc to sta...@kernel.org
Signed-off-by: Michael Krufky mkru...@linuxtv.org
-- Forwarded message --
From: Jarod Wilson ja...@redhat.com
Date: Tue, Feb 24, 2009 at 6:00 PM
Subject: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
To: linux-ker...@vger.kernel.org
Cc: Mike Krufky mkru...@linuxtv.org
From: Mark Jenks
https://www.redhat.com/mailman/private/video4linux-list/2009-January/msg00041.html
The Hauppauge WinTV HVR-1800 tv tuner card has both digital and analog
abilities, both of which are supported by v4l/dvb under 2.6.27.y. The analog
side also features a hardware mpeg2 encoder. The HVR-1250 tv tuner card
has both digital and analog abilities, but analog isn't currently supported
under any kernel. These cards both utilize the cx23885 driver, but with
slightly different usage. When the code paths for each card is executed,
they wind up poking a cx23885_devlist, which contains devices from both
of the cards, and access attempts are made to portions of 'struct
cx23885_dev' that aren't valid for that device. Simply add some extra
checks before trying to access these structs.
More gory details:
http://article.gmane.org/gmane.linux.drivers.dvb/46630
This was triggering on my own system at home w/both cards in it, and
no longer happens with this patch included.
Signed-off-by: Jarod Wilson ja...@redhat.com
Reviewed-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/video/cx23885/cx23885-417.c | 2 +-
drivers/media/video/cx23885/cx23885-video.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-417.c
b/drivers/media/video/cx23885/cx23885-417.c
index 7b0e8c0..19154b6 100644
--- a/drivers/media/video/cx23885/cx23885-417.c
+++ b/drivers/media/video/cx23885/cx23885-417.c
@@ -1585,7 +1585,7 @@ static int mpeg_open(struct inode *inode, struct
file *file)
list_for_each(list, cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h-v4l_device-minor == minor) {
+ if (h-v4l_device h-v4l_device-minor == minor) {
dev = h;
break;
}
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 6047c78..a2b5a0c 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -733,7 +733,7 @@ static int video_open(struct inode *inode, struct
file *file)
list_for_each(list, cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h-video_dev-minor == minor) {
+ if (h-video_dev h-video_dev-minor == minor) {
dev = h;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
}
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - doc: improve the v4l2-framework documentation. - cx231xx: prevent building it on kernels 2.6.23. - cx231xx: fix compile warning - v4l2-common: add missing i2c_unregister_device. Thanks, Hans diffstat: linux/Documentation/video4linux/v4l2-framework.txt | 12 -- linux/drivers/media/video/cx231xx/cx231xx-cards.c |2 - linux/drivers/media/video/v4l2-common.c| 25 - v4l/versions.txt |4 +++ 4 files changed, 35 insertions(+), 8 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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
[linux-dvb] getting started
I once had my TechnoTrend DVB-C driver working with linux, looking tv. However, completely forgot how I managed that. I think I was following the wiki How to Obtain, Build and Install V4L-DVB Device Driver I checked out the v4l-dvb sources using Mercurial. However, a make failed immediately: make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 --- Am I on the right track? If so, what is missing? ngong ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hello, Uri
On Thu, 2009-03-12 at 06:52 -0700, Uri Shkolnik wrote:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1236865697 -7200
# Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
# Parent 3392722cc5b687586c4d898b73050ab6e59bf401
siano: add high level SDIO interface driver for SMS based cards
From: Uri Shkolnik u...@siano-ms.com
This patch provides SDIO interface driver for
SMS (Siano Mobile Silicon) based devices.
The patch includes SMS high level SDIO driver and
requires patching the kernel SDIO stack,
those stack patches had been provided previously.
I would like to thank Pierre Ossman, MMC maintainer,
who wrote this driver.
Priority: normal
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 3392722cc5b6 -r 7352ee1288f6 linux/drivers/media/dvb/siano/smssdio.c
--- /dev/null Thu Jan 01 00:00:00 1970 +
+++ b/linux/drivers/media/dvb/siano/smssdio.c Thu Mar 12 15:48:17 2009 +0200
@@ -0,0 +1,356 @@
+/*
+ * smssdio.c - Siano 1xxx SDIO interface driver
+ *
+ * Copyright 2008 Pierre Ossman
I'm sorry, but may be 2009 ?
+ *
+ * Based on code by Siano Mobile Silicon, Inc.,
+ * Copyright (C) 2006-2008, Uri Shkolnik
+ *
+ * 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.
+ *
+ *
+ * This hardware is a bit odd in that all transfers should be done
+ * to/from the SMSSDIO_DATA register, yet the increase address bit
+ * always needs to be set.
+ *
+ * Also, buffers from the card are always aligned to 128 byte
+ * boundaries.
+ */
+
+/*
+ * General cleanup notes:
+ *
+ * - only typedefs should be name *_t
+ *
+ * - use ERR_PTR and friends for smscore_register_device()
+ *
+ * - smscore_getbuffer should zero fields
+ *
+ * Fix stop command
+ */
+
+#include linux/moduleparam.h
+#include linux/firmware.h
+#include linux/delay.h
+#include linux/mmc/card.h
+#include linux/mmc/sdio_func.h
+#include linux/mmc/sdio_ids.h
+
+#include smscoreapi.h
+#include sms-cards.h
+
+/* Registers */
+
+#define SMSSDIO_DATA 0x00
+#define SMSSDIO_INT 0x04
+
+static const struct sdio_device_id smssdio_ids[] = {
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_STELLAR),
+ .driver_data = SMS1XXX_BOARD_SIANO_STELLAR},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_A0),
+ .driver_data = SMS1XXX_BOARD_SIANO_NOVA_A},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_NOVA_B0),
+ .driver_data = SMS1XXX_BOARD_SIANO_NOVA_B},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VEGA_A0),
+ .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO, SDIO_DEVICE_ID_SIANO_VENICE),
+ .driver_data = SMS1XXX_BOARD_SIANO_VEGA},
+ { /* end: all zeroes */ },
+};
+
+MODULE_DEVICE_TABLE(sdio, smssdio_ids);
+
+struct smssdio_device {
+ struct sdio_func *func;
+
+ struct smscore_device_t *coredev;
+
+ struct smscore_buffer_t *split_cb;
+};
+
+/***/
+/* Siano core callbacks*/
+/***/
+
+static int smssdio_sendrequest(void *context, void *buffer, size_t size)
+{
+ int ret;
+ struct smssdio_device *smsdev;
+
+ smsdev = context;
+
+ sdio_claim_host(smsdev-func);
+
+ while (size = smsdev-func-cur_blksize) {
+ ret = sdio_write_blocks(smsdev-func, SMSSDIO_DATA, buffer, 1);
+ if (ret)
+ goto out;
+
+ buffer += smsdev-func-cur_blksize;
+ size -= smsdev-func-cur_blksize;
+ }
+
+ if (size) {
+ ret = sdio_write_bytes(smsdev-func, SMSSDIO_DATA,
+buffer, size);
+ if (ret)
+ goto out;
+ }
Do you really need this check and goto ?
Without them, as i see, the algorithm will do the same.
+
+out:
+ sdio_release_host(smsdev-func);
+
+ return ret;
+}
+
+/***/
+/* SDIO callbacks */
+/***/
+
+static void smssdio_interrupt(struct sdio_func *func)
+{
+ int ret, isr;
+
+ struct smssdio_device *smsdev;
+ struct smscore_buffer_t *cb;
+ struct SmsMsgHdr_ST *hdr;
+ size_t size;
+
+ smsdev = sdio_get_drvdata(func);
+
+ /*
+ * The interrupt register has no defined meaning. It is just
+ * a way of turning of the level triggered interrupt.
+ */
+ isr =
Re: [linux-dvb] getting started
thank you, Antti, Thomas kernel-headers are installed. Why does make try to read the wrong file? My kernel is named 2.6.28-7.slh.4-sidux-686, not 2.6.28-7.slh.3-sidux-686 - r...@rolf9:~/src/v4l-dvb$ make make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ?.myconfig?, benotigt von ?config-compat.h?, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 r...@rolf9:~/src/v4l-dvb$ r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config ls: Zugriff auf /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config nicht moglich: Datei oder Verzeichnis nicht gefunden r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config -rw-r--r-- 1 root root 95158 12. Mar 00:30 /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config r...@rolf9:~/src/v4l-dvb$ hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved r...@rolf9:~/src/v4l-dvb$ Antti Palosaari wrote: Rolf Schumacher wrote: File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. kernel-devel, kernel-headers, linux-devel or linux-headers package is missing. Package name varies from distribution to distribution... -- 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
[Fwd: Re: [linux-dvb] getting started]
ok, adapted the value in v4l/.version make is doing fine now Original Message Subject:Re: [linux-dvb] getting started Date: Thu, 12 Mar 2009 23:47:24 +0100 From: Rolf Schumacher mailingl...@august.de To: linux-media@vger.kernel.org References: 49b982a5.7010...@august.de 49b98677.9030...@iki.fi thank you, Antti, Thomas kernel-headers are installed. Why does make try to read the wrong file? My kernel is named 2.6.28-7.slh.4-sidux-686, not 2.6.28-7.slh.3-sidux-686 - r...@rolf9:~/src/v4l-dvb$ make make -C /home/rsc/src/v4l-dvb/v4l make[1]: Entering directory `/home/rsc/src/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.28 File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ?.myconfig?, benotigt von ?config-compat.h?, zu erstellen. Schluss. make[1]: Leaving directory `/home/rsc/src/v4l-dvb/v4l' make: *** [all] Fehler 2 r...@rolf9:~/src/v4l-dvb$ r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config ls: Zugriff auf /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config nicht moglich: Datei oder Verzeichnis nicht gefunden r...@rolf9:~/src/v4l-dvb$ ls -la /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config -rw-r--r-- 1 root root 95158 12. Mar 00:30 /lib/modules/2.6.28-7.slh.4-sidux-686/build/.config r...@rolf9:~/src/v4l-dvb$ hg update 0 files updated, 0 files merged, 0 files removed, 0 files unresolved r...@rolf9:~/src/v4l-dvb$ Antti Palosaari wrote: Rolf Schumacher wrote: File not found: /lib/modules/2.6.28-7.slh.3-sidux-686/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. kernel-devel, kernel-headers, linux-devel or linux-headers package is missing. Package name varies from distribution to distribution... -- 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] Add support for ProVideo PV-183 to bttv
This patch adds support for the ProVideo PV-183 card to the bttv
device driver. The PV-183 is a PCI card with 8 BT878 devices plus a Hint
Corp HiNT HB4 PCI-PCI Bridge. Each BT878 has two composite input channels
available. There are no tuners on this card.
This patch was generated against the V4L-DVB mercurial tree as of 12
March 2009.
Signed-off-by: Alan McIvor alan.mci...@reveal.co.nz
--- linux/drivers/media/video/bt8xx/bttv.h.orig 2009-03-13 10:12:09.0
+1300
+++ linux/drivers/media/video/bt8xx/bttv.h 2009-03-13 10:18:46.0
+1300
@@ -184,6 +184,7 @@
#define BTTV_BOARD_IVCE8784 0x9c
#define BTTV_BOARD_GEOVISION_GV800S 0x9d
#define BTTV_BOARD_GEOVISION_GV800S_SL0x9e
+#define BTTV_BOARD_PV183 0x9f
/* more card-specific defines */
--- linux/drivers/media/video/bt8xx/bttv-cards.c.orig 2009-03-13
10:12:19.0 +1300
+++ linux/drivers/media/video/bt8xx/bttv-cards.c2009-03-13
10:24:28.0 +1300
@@ -321,6 +321,16 @@ static struct CARD {
{ 0x763d800b, BTTV_BOARD_GEOVISION_GV800S_SL, GeoVision GV-800(S)
(slave) },
{ 0x763d800c, BTTV_BOARD_GEOVISION_GV800S_SL, GeoVision GV-800(S)
(slave) },
{ 0x763d800d, BTTV_BOARD_GEOVISION_GV800S_SL, GeoVision GV-800(S)
(slave) },
+
+{ 0x15401830, BTTV_BOARD_PV183, Provideo PV183-1 },
+{ 0x15401831, BTTV_BOARD_PV183, Provideo PV183-2 },
+{ 0x15401832, BTTV_BOARD_PV183, Provideo PV183-3 },
+{ 0x15401833, BTTV_BOARD_PV183, Provideo PV183-4 },
+{ 0x15401834, BTTV_BOARD_PV183, Provideo PV183-5 },
+{ 0x15401835, BTTV_BOARD_PV183, Provideo PV183-6 },
+{ 0x15401836, BTTV_BOARD_PV183, Provideo PV183-7 },
+{ 0x15401837, BTTV_BOARD_PV183, Provideo PV183-8 },
+
{ 0, -1, NULL }
};
@@ -2910,6 +2920,20 @@ struct tvcard bttv_tvcards[] = {
.no_tda9875 = 1,
.muxsel_hook= gv800s_muxsel,
},
+ [BTTV_BOARD_PV183] = {
+ .name = ProVideo PV183, /* 0x9f */
+ .video_inputs = 2,
+ /* .audio_inputs= 0, */
+ .svhs = NO_SVHS,
+ .gpiomask = 0,
+ .muxsel = MUXSEL(2, 3),
+ .gpiomux= { 0 },
+ .needs_tvaudio = 0,
+ .no_msp34xx = 1,
+ .pll= PLL_28,
+ .tuner_type = TUNER_ABSENT,
+ .tuner_addr = ADDR_UNSET,
+ },
};
static const unsigned int bttv_num_tvcards = ARRAY_SIZE(bttv_tvcards);
--
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: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote:
Can we have this merged into -stable? Jarod Wilson sent this last
month, but he left off the cc to sta...@kernel.org
Signed-off-by: Michael Krufky mkru...@linuxtv.org
Mike,
A version of this is already in the v4l-dvb hg development repository:
hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c
hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c
I helped Mark work through the solution: I coded some of it, he coded
some of it and he also tested it.
Regards,
Andy
-- Forwarded message --
From: Jarod Wilson ja...@redhat.com
Date: Tue, Feb 24, 2009 at 6:00 PM
Subject: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
To: linux-ker...@vger.kernel.org
Cc: Mike Krufky mkru...@linuxtv.org
From: Mark Jenks
https://www.redhat.com/mailman/private/video4linux-list/2009-January/msg00041.html
The Hauppauge WinTV HVR-1800 tv tuner card has both digital and analog
abilities, both of which are supported by v4l/dvb under 2.6.27.y. The analog
side also features a hardware mpeg2 encoder. The HVR-1250 tv tuner card
has both digital and analog abilities, but analog isn't currently supported
under any kernel. These cards both utilize the cx23885 driver, but with
slightly different usage. When the code paths for each card is executed,
they wind up poking a cx23885_devlist, which contains devices from both
of the cards, and access attempts are made to portions of 'struct
cx23885_dev' that aren't valid for that device. Simply add some extra
checks before trying to access these structs.
More gory details:
http://article.gmane.org/gmane.linux.drivers.dvb/46630
This was triggering on my own system at home w/both cards in it, and
no longer happens with this patch included.
Signed-off-by: Jarod Wilson ja...@redhat.com
Reviewed-by: Michael Krufky mkru...@linuxtv.org
---
drivers/media/video/cx23885/cx23885-417.c |2 +-
drivers/media/video/cx23885/cx23885-video.c |2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23885-417.c
b/drivers/media/video/cx23885/cx23885-417.c
index 7b0e8c0..19154b6 100644
--- a/drivers/media/video/cx23885/cx23885-417.c
+++ b/drivers/media/video/cx23885/cx23885-417.c
@@ -1585,7 +1585,7 @@ static int mpeg_open(struct inode *inode, struct
file *file)
list_for_each(list, cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h-v4l_device-minor == minor) {
+ if (h-v4l_device h-v4l_device-minor == minor) {
dev = h;
break;
}
diff --git a/drivers/media/video/cx23885/cx23885-video.c
b/drivers/media/video/cx23885/cx23885-video.c
index 6047c78..a2b5a0c 100644
--- a/drivers/media/video/cx23885/cx23885-video.c
+++ b/drivers/media/video/cx23885/cx23885-video.c
@@ -733,7 +733,7 @@ static int video_open(struct inode *inode, struct
file *file)
list_for_each(list, cx23885_devlist) {
h = list_entry(list, struct cx23885_dev, devlist);
- if (h-video_dev-minor == minor) {
+ if (h-video_dev h-video_dev-minor == minor) {
dev = h;
type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
}
--
Jarod Wilson
ja...@redhat.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
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: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Andy Walls wrote: On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org Signed-off-by: Michael Krufky mkru...@linuxtv.org Mike, A version of this is already in the v4l-dvb hg development repository: hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c I helped Mark work through the solution: I coded some of it, he coded some of it and he also tested it. Regards, Andy I'm aware of that, Andy -- That's why I am sending this off to the -stable team for 2.6.27.y Thanks regards, Mike -- 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
cx231xx review of i2c handling
Hi Sri,
Here is a review of the i2c part of this driver, together with pointers on
how to proceed to convert it to v4l2_device/v4l2_subdev.
Time permitting I hope to look at the v4l2 implementation in the driver as
well over the weekend, but the i2c part is for me the most urgent issue at
the moment as you've no doubt guessed by now :-)
Although I couldn't help noticing this typo:
cx231xx-cards.c:cx231xx_info(Board is Conexnat RDE 250\n);
cx231xx-cards.c:cx231xx_info(Board is Conexnat RDU 250\n);
:-)
Looking at cx231xx-i2c.c I see it has the following devices:
0x32: Geminit III
0x02: Acquarius
0xa0: eeprom
0x60: Colibri
0x8e: IR
0x80/0x88: Hammerhead
And it also uses an external tuner.
It is my understanding that these devices are integrated on the cx231xx and
so are completely internal to it:
Geminit III, Acquarius, Colibri, Hammerhead.
Is the eeprom also internal, or is it external?
Why can Hammerhead be at two addresses? Since it is an integral device I'd
expect that the address would be fixed. Or are there two Hammerheads?
Looking at the source I'd say that it can only be at address 0x88.
A general note: please add a description in the cx231xx.h header or in
another suitable place for each of these devices. The codenames themselves
do not give much of an idea of what the device actually does.
I have 'decoded' that Hammerhead is the cx231xx version of the cx25843. You
are loading the cx25840 module to handle this (good), but you also write
directly to the i2c device from the cx231xx driver (bad). You have to make
a choice here: either handle it completely from inside cx231xx, or add full
support for it to the cx25840 module and call that.
The rule is that parent drivers of an i2c module should never attempt to set
registers directly as that breaks reusability. In this case, suppose a
change is made in cx25840 that overwrites a register you've set from
without cx231xx. Now the cx231xx is broken, and that is because there is no
way of knowing when you edit the cx25840 sources that it is used like that.
Whereas if all the code that reads and writes registers is fully within the
cx25840 module, then whoever needs to modify that driver can see the whole
picture.
It is much preferred to keep using cx25840 and just add the missing pieces
to that driver, rather than moving all the code inside cx231xx.
Since the i2c addresses for the integral i2c devices are hardwired (I
assume), I recommend making some simple inline functions like this:
static int inline colibri_read_byte(struct cx231xx *dev, int reg, u8 *byte)
{
return cx231xx_read_i2c_data(dev, Colibri_DEVICE_ADDRESS,
reg, 2, byte, 1);
}
That will make the code much more readable.
A note on the cx231xx_usb_disconnect: this can be simplified without needing
user counts and complicated code. Read the section on video_device cleanup
in the v4l2-framework.txt. The release() callback is guaranteed to be
called when the last user disappears, so you can do your cleanup there.
This is a fairly recent change. Before this was implemented each USB driver
had to do their own reference counting.
Anyway, none of the points above is really urgent. What is urgent is that
the new i2c API should be used. The background for this is that currently
you just load an i2c module (e.g. tuner or cx25840) and it magically probes
the i2c bus and attaches itself when it finds a suitable i2c device. The
problem with that is that not all i2c devices can be uniquely identified,
so that can lead to misdetections and that can cause lots of problems,
including cases of corrupted eeproms.
A new i2c API was created for this and at the moment both old and new
co-exist. However, the intention is to remove support for the old i2c API
from the i2c core in 2.6.30.
Rather than just switching to the new API I've taken the opportunity to
integrate it into a bigger v4l2 framework, based around new v4l2_device and
v4l2_subdev structs. Currently the sole purpose is to aid in the migration
to the new i2c API, basically hiding all the details from the driver. A
major advantage of v4l2_subdev is also that it is not limited to i2c
devices, instead you can model just about any type of device around it.
This is particularly useful for highly integrated devices and it might be
interesting to consider their use for the integrated devices that cx231xx
has.
Please read v4l2-framework.txt. Let me know if something is not clear as
that might indicate that I need to improve it.
This driver luckily doesn't need a lot of work. The first step is to
introduce struct v4l2_device. Just stick it in struct cx231xx, register it
in cx231xx_usb_probe and unregister it when cleaning up.
One thing you need to be aware of is that you should set i2c_set_adapdata to
the v4l2_device pointer instead of the cx231xx_i2c bus.
The second step is to load the i2c modules through v4l2_i2c_new_subdev or
Re: disable v4l2-ctl logging --log-status in /var/log/messages
On Thu, 2009-03-12 at 10:49 +0100, Gregor Fuis wrote: On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hello, Is it possible to disable v4l2-ctl aplication logging into /var/log/messages. I am using it to control and monitor my PVR 150 cards and every time I run v4l2-ctl -d /dev/video0 --log-status all output is logged into /var/log/messages and some other linux log files. All --log-status does is to tell the driver to show it's status in the kernel log for debugging purposes. It cannot and should not be relied upon for monitoring/controlling a driver. What do you need it for anyway? I am just monitoring if signal is present on tuner, and what signal format is detected. These two lines: cx25840 1-0044: Video signal: not present cx25840 1-0044: Detected format: PAL-Nc I run this every minute and it is really annoying to have all this in my system logs. Is it possible to modify v4l2-ctl source to disable system logging? $ v4l2-ctl -d /dev/video0 -T which calls the VIDIOC_G_TUNER ioctl(), can be used to tell you if a signal is present: Tuner: Name : cx18 TV Tuner Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 Frequency range : 44.0 MHz - 958.0 MHz Signal strength/AFC : 0%/-187500 Current audio mode : lang1 Available subchannels: mono Signal strength will be 0% or 100% - both the cx18 driver and the cx25840 driver behave the same in this regard. AFAICT, other than --log-status (the VIDIOC_LOG_STATUS ioctl()) which always writes to the system logs, there is no way for a non-root user to read out the Video standard detected by the CX25843 hardware. That would require a change to the driver(s) and maybe an API change (I'm not sure). Regards, Andy Regards, Gregor -- 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: disable v4l2-ctl logging --log-status in /var/log/messages
On Friday 13 March 2009 00:34:43 Andy Walls wrote: On Thu, 2009-03-12 at 10:49 +0100, Gregor Fuis wrote: On Thu, Mar 12, 2009 at 10:28 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hello, Is it possible to disable v4l2-ctl aplication logging into /var/log/messages. I am using it to control and monitor my PVR 150 cards and every time I run v4l2-ctl -d /dev/video0 --log-status all output is logged into /var/log/messages and some other linux log files. All --log-status does is to tell the driver to show it's status in the kernel log for debugging purposes. It cannot and should not be relied upon for monitoring/controlling a driver. What do you need it for anyway? I am just monitoring if signal is present on tuner, and what signal format is detected. These two lines: cx25840 1-0044: Video signal: not present cx25840 1-0044: Detected format: PAL-Nc I run this every minute and it is really annoying to have all this in my system logs. Is it possible to modify v4l2-ctl source to disable system logging? $ v4l2-ctl -d /dev/video0 -T which calls the VIDIOC_G_TUNER ioctl(), can be used to tell you if a signal is present: Tuner: Name : cx18 TV Tuner Capabilities : 62.5 kHz multi-standard stereo lang1 lang2 Frequency range : 44.0 MHz - 958.0 MHz Signal strength/AFC : 0%/-187500 Current audio mode : lang1 Available subchannels: mono Signal strength will be 0% or 100% - both the cx18 driver and the cx25840 driver behave the same in this regard. AFAICT, other than --log-status (the VIDIOC_LOG_STATUS ioctl()) which always writes to the system logs, there is no way for a non-root user to read out the Video standard detected by the CX25843 hardware. That would require a change to the driver(s) and maybe an API change (I'm not sure). There is a VIDIOC_QUERYSTD ioctl. However, neither ivtv nor cx25840 supports that. I've always thought that that would be a useful addition, but never got around to implementing it. You are the first one for whom such an ioctl would actually be useful, Gregor :-) It should be fairly easy to add this, but I really don't have the time for this I'm afraid. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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: Fwd: [stable] [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, 2009-03-12 at 19:18 -0400, Michael Krufky wrote: Andy Walls wrote: On Thu, 2009-03-12 at 16:24 -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org Signed-off-by: Michael Krufky mkru...@linuxtv.org Mike, A version of this is already in the v4l-dvb hg development repository: hg log -vp --limit 1 linux/drivers/media/video/cx23885/cx23885-417.c hg log -vp --limit 2 linux/drivers/media/video/cx23885/cx23885-video.c I helped Mark work through the solution: I coded some of it, he coded some of it and he also tested it. Regards, Andy I'm aware of that, Andy -- That's why I am sending this off to the -stable team for 2.6.27.y Ooops. Sorry for my cluelessness. :) Regards, Andy Thanks regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 10:11:12 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Thu, Mar 12, 2009 at 4:54 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Hi Devin, There's a bug on your patch series: see this: Those are the locations of au8522 files at Kernel's tree: drivers/media/dvb/frontends/au8522.h drivers/media/dvb/frontends/au8522_dig.c drivers/media/dvb/frontends/au8522_priv.h drivers/media/video/au8522_decoder.c And those are the Makefile rules for au8522.h on drivers/media/dvb/frontends/Makefile: au8522-objs = au8522_dig.o au8522_decoder.o obj-$(CONFIG_DVB_AU8522) += au8522.o When you're compiling the out-of-tree version, everything works OK, but, for in-tree compilation, au8522_decoder won't be compiled, since the file will be in the wrong dir. If I'm understanding well, this chip has two functions: it is a dvb frontend and an analog video/audio demodulator, right? One solution would be to have all those files in the same directory. However, au8522_decoder doesn't fit well on dvb/frontends. It is also not a tuner, otherwise common/tuners would be another better place. Another alternative would be to create two kconfig rules (and two separate modules), being one for au8522_decoder and another for the frontend, since they are, in fact, two different things. I suspect,however, that compiling just one or another would break compilation. So, we need to create some sort of rules that will warrant that both modules will be compiled at the same time. This is not an easy task, since we cannot add depends on, since frontends are compiled by using select. So, we will need to re-design the Kconfig rules to use depends on instead of select (well, this is something good, anyway, since the usage of select is something that should be avoided, according with Kbuild docs). I'll keep reviewing the patch series. Maybe I'll merge it, but, in this case, I'll need to blacklist the module until we found a solution, or find a way to allow my -git trees to compile. Cheers, Mauro Hello Mauro, Both files are required, as they share certain functions (such as the i2c transfer functions). Also, they share a common state mechanism, which is why both files end up in the same .ko file. This case is a little unique since it is the first case where we have a single chip that acts as a digital demod, an analog demod, and an analog video/audio decoder. I can certainly put the au8522_decoder.c into dvb/frontends even though this probably violates some rule about analog stuff being in the DVB section of the tree. Would that resolve your concern? I really don't want to make redesigning the KConfig rules a prerequisite to getting this rather large patch series merged. I would suggest we do what is required to get the code in (such as moving the _decoder.c to frontends), and then we can tune the solution to be something more optimal in terms of how the tree is structured. I don't like much the idea of moving decoder to frontends, but we may do this as an intermediate step. To make things easier for future changes, IMO, it would be better to create a separate dir for this driver, inside dvb/frontends. This will help to move it elsewhere. Cheers, Mauro. 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: [PATCH] Add support for ProVideo PV-183 to bttv
On Fri, 13 Mar 2009, Alan McIvor wrote:
+
+{ 0x15401830, BTTV_BOARD_PV183, Provideo PV183-1 },
+{ 0x15401831, BTTV_BOARD_PV183, Provideo PV183-2 },
+{ 0x15401832, BTTV_BOARD_PV183, Provideo PV183-3 },
+{ 0x15401833, BTTV_BOARD_PV183, Provideo PV183-4 },
+{ 0x15401834, BTTV_BOARD_PV183, Provideo PV183-5 },
+{ 0x15401835, BTTV_BOARD_PV183, Provideo PV183-6 },
+{ 0x15401836, BTTV_BOARD_PV183, Provideo PV183-7 },
+{ 0x15401837, BTTV_BOARD_PV183, Provideo PV183-8 },
+
{ 0, -1, NULL }
};
Looks like you used spaces here instead of tabs. If you run make commit
from the v4l-dvb tree it will fix these things.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS based cards
Hi Alexey,
I numbered your comments and append all answers to the end of this email.
--- On Fri, 3/13/09, Alexey Klimov klimov.li...@gmail.com wrote:
From: Alexey Klimov klimov.li...@gmail.com
Subject: Re: [PATCH 1/1] siano: add high level SDIO interface driver for SMS
based cards
To: Uri Shkolnik uri...@yahoo.com
Cc: Mauro Carvalho Chehab mche...@infradead.org, Michael Krufky
mkru...@linuxtv.org, linux-media@vger.kernel.org
Date: Friday, March 13, 2009, 12:46 AM
Hello, Uri
On Thu, 2009-03-12 at 06:52 -0700, Uri Shkolnik wrote:
# HG changeset patch
# User Uri Shkolnik u...@siano-ms.com
# Date 1236865697 -7200
# Node ID 7352ee1288f651d19d58c7bb479a98f070ad98e6
# Parent
3392722cc5b687586c4d898b73050ab6e59bf401
siano: add high level SDIO interface driver for SMS
based cards
From: Uri Shkolnik u...@siano-ms.com
This patch provides SDIO interface driver for
SMS (Siano Mobile Silicon) based devices.
The patch includes SMS high level SDIO driver and
requires patching the kernel SDIO stack,
those stack patches had been provided previously.
I would like to thank Pierre Ossman, MMC maintainer,
who wrote this driver.
Priority: normal
Signed-off-by: Pierre Ossman drz...@drzeus.cx
Signed-off-by: Uri Shkolnik u...@siano-ms.com
diff -r 3392722cc5b6 -r 7352ee1288f6
linux/drivers/media/dvb/siano/smssdio.c
--- /dev/null Thu Jan 01 00:00:00
1970 +
+++
b/linux/drivers/media/dvb/siano/smssdio.c
Thu Mar 12 15:48:17 2009 +0200
@@ -0,0 +1,356 @@
+/*
+ * smssdio.c - Siano 1xxx SDIO interface
driver
+ *
+ * Copyright 2008 Pierre Ossman
I'm sorry, but may be 2009 ?
[ #1 ]
+ *
+ * Based on code by Siano Mobile Silicon, Inc.,
+ * Copyright (C) 2006-2008, Uri Shkolnik
+ *
+ * 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.
+ *
+ *
+ * This hardware is a bit odd in that all transfers
should be done
+ * to/from the SMSSDIO_DATA register, yet the
increase address bit
+ * always needs to be set.
+ *
+ * Also, buffers from the card are always aligned to
128 byte
+ * boundaries.
+ */
+
+/*
+ * General cleanup notes:
+ *
+ * - only typedefs should be name *_t
+ *
+ * - use ERR_PTR and friends for
smscore_register_device()
+ *
+ * - smscore_getbuffer should zero fields
+ *
+ * Fix stop command
+ */
+
+#include linux/moduleparam.h
+#include linux/firmware.h
+#include linux/delay.h
+#include linux/mmc/card.h
+#include linux/mmc/sdio_func.h
+#include linux/mmc/sdio_ids.h
+
+#include smscoreapi.h
+#include sms-cards.h
+
+/* Registers */
+
+#define SMSSDIO_DATA
0x00
+#define SMSSDIO_INT
0x04
+
+static const struct sdio_device_id smssdio_ids[] = {
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
SDIO_DEVICE_ID_SIANO_STELLAR),
+ .driver_data =
SMS1XXX_BOARD_SIANO_STELLAR},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
SDIO_DEVICE_ID_SIANO_NOVA_A0),
+ .driver_data =
SMS1XXX_BOARD_SIANO_NOVA_A},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
SDIO_DEVICE_ID_SIANO_NOVA_B0),
+ .driver_data =
SMS1XXX_BOARD_SIANO_NOVA_B},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
SDIO_DEVICE_ID_SIANO_VEGA_A0),
+ .driver_data =
SMS1XXX_BOARD_SIANO_VEGA},
+ {SDIO_DEVICE(SDIO_VENDOR_ID_SIANO,
SDIO_DEVICE_ID_SIANO_VENICE),
+ .driver_data =
SMS1XXX_BOARD_SIANO_VEGA},
+ { /* end: all zeroes */ },
+};
+
+MODULE_DEVICE_TABLE(sdio, smssdio_ids);
+
+struct smssdio_device {
+ struct sdio_func *func;
+
+ struct smscore_device_t *coredev;
+
+ struct smscore_buffer_t
*split_cb;
+};
+
+/***/
+/* Siano core callbacks
*/
+/***/
+
+static int smssdio_sendrequest(void *context, void
*buffer, size_t size)
+{
+ int ret;
+ struct smssdio_device *smsdev;
+
+ smsdev = context;
+
+ sdio_claim_host(smsdev-func);
+
+ while (size =
smsdev-func-cur_blksize) {
+ ret =
sdio_write_blocks(smsdev-func, SMSSDIO_DATA, buffer,
1);
+ if (ret)
+
goto out;
+
+ buffer +=
smsdev-func-cur_blksize;
+ size -=
smsdev-func-cur_blksize;
+ }
+
+ if (size) {
+ ret =
sdio_write_bytes(smsdev-func, SMSSDIO_DATA,
+
buffer, size);
+ if (ret)
+
goto out;
+ }
Do you really need this check and goto ?
Without them, as i see, the algorithm will do the same.
[ #2 ]
+
+out:
+
sdio_release_host(smsdev-func);
+
+ return ret;
+}
+
Re: [PULL] http://linuxtv.org/hg/~dheitmueller/hvr950q-analog2
On Thu, 12 Mar 2009 11:26:15 -0400 Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Thu, Mar 12, 2009 at 11:06 AM, Mauro Carvalho Chehab mche...@infradead.org wrote: Yeah, printing NULL is bad and I can obviously fix that. The real reason for the addition of the UNDEFINED entry is I use that to detect if there are *any* analog inputs defined, which dictates whether the analog subsystem is initialized. Because the .input section is a member of the au0828_dev struct, and not a pointer, I needed some way to tell if it was populated with anything. if you attribute it to -1, the userspace calls will never set it to undefined. You should take some care to avoid reading outside some array though. The problem is that I check for UNDEFINED so that the .input section of the au0828 board definition can be left uninitialized. Otherwise, I would have to add something like num_inputs to the board definition and worry about the value matching the actual number of inputs defined. num_inputs is a really bad thing. Maybe you can just test if input type is UNDEFINED and return -EINVAL. I looked at the list and all of these issues are easy to fix, and I will do that tonight. Ok. Please let me know if you have any other concerns (and what you want me to do regarding the VBI stuff), since I would like to avoid having do redo the tree again. No, just the above. Please, instead of redo the tree, just add some patches fixing those issues. This allows me to review faster your series. Do you mean the checkpatch fixes should be done as a separate patch too? I assumed you wanted me to fix the original patch to pass make checkpatch. Is there a way to do the equivalent of make checkpatch against particular hg revisions or source files? I'm just trying to understand the best way to ensure that all of the issues actually get fixed. There are two ways: 1) v4l/check.pl file This accepts just one file each time; 2) hg diff -r the last review before your patch series file v4l/check.pl file The check.pl script is just a wrapper for the checkpatch.pl. Its output is equal to an standard C compiler. So, you can use it on a C error parser for some gui. Also, the wrapper removes some checks that are ok (the ones for the lines that adds kernel version checks - since this will be removed anyway by the submit script). 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: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org What is the git commit id of the patch in Linus's tree that matches up with this? thanks, greg k-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
kernel oops in dvb_net
Hi linux-tver, Not sure whether this is the right mailing list or not. I've encountered a kernel oops in dvb_net. My receiver card is HVR-4000 Lite. I'm running a rawhide kernel on Fedora 10. Attached is the syslog just before when nuts. I tested with rawhide kernel version 2.6.29-0.124.rc5.fc10.i586 and vanilla kernel 2.6.28.7. I'm using the receiver card for ULE decapsulation. Should you need more information, please drop me a mail. Attached are the kernel oops message of the 2 kernels just before the system freeze. Thanks. Regards, Ang Way Chuang Mar 9 16:18:44 localhost kernel: dvb0_0: no ts feed to stop Mar 9 16:18:44 localhost kernel: dvb_net: removed network interface dvb0_0 Mar 9 16:18:44 localhost kernel: 1802201963: Expected 1802201963 more SNDU bytes, but got PUSI (pf 0, ts_remain 183). Flushing incomplete payload. Mar 9 16:18:44 localhost kernel: BUG: unable to handle kernel paging request at 6b6b6c1f Mar 9 16:18:44 localhost kernel: IP: [c065c31f] kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: *pde = Mar 9 16:18:44 localhost kernel: Oops: [#1] SMP Mar 9 16:18:44 localhost kernel: last sysfs file: /sys/devices/virtual/net/dvb0_0/flags Mar 9 16:18:44 localhost kernel: Modules linked in: sco bridge stp llc bnep l2cap bluetooth ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq dm_multipath uinput isl6421 cx24116 snd_hda_codec_realtek cx88_dvb cx88_vp3054_i2c snd_hda_intel videobuf_dvb dvb_core tuner cx8802 cx8800 cx88_alsa snd_hda_codec snd_hwdep cx88xx snd_seq_dummy snd_seq_oss ir_common tveeprom snd_seq_midi_event v4l2_common snd_seq videodev snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm v4l1_compat videobuf_dma_sg videobuf_core iTCO_wdt btcx_risc iTCO_vendor_support ppdev floppy pcspkr snd_timer snd i2c_i801 r8169 soundcore parport_pc via_velocity parport snd_page_alloc mii crc_ccitt ata_generic pata_acpi i915 drm i2c_algo_bit i2c_core [last unloaded: microcode] Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: Pid: 4024, comm: cx88[0] dvb Tainted: G W (2.6.29-0.124.rc5.fc10.i586 #1) Prime Series Mar 9 16:18:44 localhost kernel: EIP: 0060:[c065c31f] EFLAGS: 00010002 CPU: 1 Mar 9 16:18:44 localhost kernel: EIP is at kfree_skb+0x9/0x32 Mar 9 16:18:44 localhost kernel: EAX: 6b6b6b6b EBX: fa4ca301 ECX: 6b6b6b6b EDX: 01a2c000 Mar 9 16:18:44 localhost kernel: ESI: f4d415e0 EDI: f4d41060 EBP: f4e09ec4 ESP: f4e09ec4 Mar 9 16:18:44 localhost kernel: DS: 007b ES: 007b FS: 00d8 GS: SS: 0068 Mar 9 16:18:44 localhost kernel: Process cx88[0] dvb (pid: 4024, ti=f4e09000 task=f4f029e0 task.ti=f4e09000) Mar 9 16:18:44 localhost kernel: Stack: Mar 9 16:18:44 localhost kernel: f4e09f40 f81939fd f81973d1 6b6b6b6b 6b6b6b6b 00b7 f4c0d3c0 Mar 9 16:18:44 localhost kernel: f4d415e0 fa4ca318 f4d41060 b7a5b100 fa4ca31d fa4ca3d4 f4d411c4 f4d4162c Mar 9 16:18:44 localhost kernel: b4b6ba84 0be6 f4e09f20 f4d022a4 f4d022a4 f4d02294 0293 Mar 9 16:18:44 localhost kernel: Call Trace: Mar 9 16:18:44 localhost kernel: [f81939fd] ? dvb_net_ts_callback+0x340/0xa57 [dvb_core] Mar 9 16:18:44 localhost kernel: [f818ce97] ? dvb_dmx_swfilter_packet+0x122/0x300 [dvb_core] Mar 9 16:18:44 localhost kernel: [c06e66b2] ? _spin_lock_irqsave+0x63/0x6d Mar 9 16:18:44 localhost kernel: [f818e073] ? dvb_dmx_swfilter+0xce/0x10d [dvb_core] Mar 9 16:18:44 localhost kernel: [f80e25f2] ? videobuf_dvb_thread+0xad/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [f80e2545] ? videobuf_dvb_thread+0x0/0x12f [videobuf_dvb] Mar 9 16:18:44 localhost kernel: [c043fe95] ? kthread+0x3b/0x61 Mar 9 16:18:44 localhost kernel: [c043fe5a] ? kthread+0x0/0x61 Mar 9 16:18:44 localhost kernel: [c04046f7] ? kernel_thread_helper+0x7/0x10 Mar 9 16:18:44 localhost kernel: Code: 00 00 88 4b 65 f0 ff 0a 0f 94 c0 84 c0 74 10 8d 93 48 ff ff ff a1 34 37 8b c0 e8 1f 44 e4 ff 5b 5d c3 55 85 c0 89 e5 89 c1 74 27 8b 80 b4 00 00 00 48 75 07 0f ae e8 89 f6 eb 10 8d 81 b4 00 00 Mar 9 16:18:44 localhost kernel: EIP: [c065c31f] kfree_skb+0x9/0x32 SS:ESP 0068:f4e09ec4 Mar 9 16:18:44 localhost kernel: ---[ end trace 265db78d6888b949 ]--- Mar 9 16:18:44 localhost kernel: = Mar 9 16:18:44 localhost kernel: BUG kmalloc-2048 (Tainted: G D W ): Poison overwritten Mar 9 16:18:44 localhost kernel: - Mar 9 16:18:44 localhost kernel: Mar 9 16:18:44 localhost kernel: INFO: 0xf4d410c0-0xf4d416bc. First byte 0x6c instead of 0x6b Mar 9 16:18:44 localhost kernel: INFO: Allocated in alloc_netdev_mq+0x3d/0x11c age=1499438 cpu=1 pid=3815 Mar 9 16:18:44 localhost kernel: INFO: Freed in netdev_release+0x2f/0x32 age=126 cpu=1 pid=4277 Mar 9 16:18:44 localhost kernel: INFO: Slab 0xc1f66b00 objects=15 used=0 fp=0xf4d4
Re: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
Greg KH wrote: On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org What is the git commit id of the patch in Linus's tree that matches up with this? thanks, greg k-h Now that I look closer, seems there's an even more complete patch already in linus' tree, commit id: cd8f894eacf13996d920fdd2aef1afc55156b191 Shoulda just forwarded that along, but I was under the impression that area of code had changed significantly in 2.6.28 and the patch was no longer applicable. Maybe that was the v4l/dvb hg tree though... So I'd just grab that, and add: Signed-off-by: Jarod Wilson ja...@redhat.com --jarod -- 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: [stable] Fwd: [PATCH] 2.6.27.y: fix NULL ptr deref in cx23885 video_open
On Thu, Mar 12, 2009 at 11:00:11PM -0400, Jarod Wilson wrote: Greg KH wrote: On Thu, Mar 12, 2009 at 04:24:38PM -0400, Michael Krufky wrote: Can we have this merged into -stable? Jarod Wilson sent this last month, but he left off the cc to sta...@kernel.org What is the git commit id of the patch in Linus's tree that matches up with this? thanks, greg k-h Now that I look closer, seems there's an even more complete patch already in linus' tree, commit id: cd8f894eacf13996d920fdd2aef1afc55156b191 Shoulda just forwarded that along, but I was under the impression that area of code had changed significantly in 2.6.28 and the patch was no longer applicable. Maybe that was the v4l/dvb hg tree though... So I'd just grab that, and add: Signed-off-by: Jarod Wilson ja...@redhat.com Ok, will do that. thanks, greg k-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: The right way to interpret the content of SNR, signal strength and BER from HVR 4000 Lite
VDR User wrote: On Thu, Mar 12, 2009 at 6:53 PM, Ang Way Chuang wc...@nav6.org wrote: Hi all, I've looked through the mailing list and there seems to be no standard way to interpret to content of SNR, signal strength and BER returned from the DVB API. So, I wonder if someone knows how to interpret these values at least for HVR 4000 Lite? Thanks. I've seen talk about converting everything to report SNR/STR in dB which is a great idea if it ever happens. I know a lot of guys not on the mailing list who've been waiting for that. Yes, please :) -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
