RE: why is there no enum_input in v4l2_subdev_video_ops
Hi Laurent, On Tue, May 10, 2011 at 5:42 AM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Why is there no enum_input operation in v4l2_subdev_video_ops? Why do you need one ? Because I want to query decoder how many inputs it can support. So the question is where we should store inputs info, board specific data or decoder driver? I appreciate your advice. ENUMINPUT as defined by V4L2 enumerates input connectors available on the board. Which inputs the board designer hooked up is something that only the top-level V4L driver will know. Subdevices do not have that information, so enuminputs is not applicable there. Of course, subdevices do have input pins and output pins, but these are assumed to be fixed. With the s_routing ops the top level driver selects which input and output pins are active. Enumeration of those inputs and outputs wouldn't gain you anything as far as I can tell since the subdevice simply does not know which inputs/outputs are actually hooked up. It's the top level driver that has that information (usually passed in through board/card info structures). Regards, Hans Maybe because noone needed it until now? I found some drivers put this info in board specific data, but in my opinion this info is sensor or decoder related. Can you tell which drivers / boards you're referring to? I referred to drivers/media/video/davinci files. So it should be put into the sensor drivers. Maybe. Also notice, I'm not a maintainer nor a principal v4l2-subdev developer. I've added Hans and Laurent to Cc:, will see what they say, or you can just point out which drivers / platforms are doing this wrong and propose a fix. Sorry, I only found your mail in MAINTAINERS. Regards, Scott -- 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: Current status report of mt9p031.
On 5 May 2011 18:55, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote:
Hi Javier,
Here's the review of 0002-mt9p031.patch.
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031 *mt9p031;
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support I2C_FUNC_SMBUS_WORD\n);
+ return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
+ if (!mt9p031)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(mt9p031-subdev, client, mt9p031_subdev_ops);
+
+// struct isp_device *isp = v4l2_dev_to_isp_device(subdev-v4l2_dev);
+// isp_set_xclk(isp, 16*1000*1000, ISP_XCLK_A);
+
+ mt9p031-rect.left = 0/*MT9P031_COLUMN_SKIP*/;
+ mt9p031-rect.top = 0/*MT9P031_ROW_SKIP*/;
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height = MT9P031_MAX_HEIGHT;
+
+ switch (pdata-data_shift) {
+ case 2:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG8_1X8;
+ break;
+ case 1:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ break;
+ case 0:
+ mt9p031-format.code = V4L2_MBUS_FMT_SBGGR12_1X12;
+ }
Why ? The sensor produces 12-bit data, you shouldn't fake other data widths.
Hi Laurent,
I was fixing all the issues you have pointed out when I ran into this.
It is true that mt9p031 produces 12-bit data only. However, when
connected to omap3isp it is possible to discard 4 least significant
bits (i.e. changing V4L2_MBUS_FMT_SGRBG12_1X12 into
V4L2_MBUS_FMT_SGRBG8_1X8).
The point is, if I just force mt9p031-format.code =
V4L2_MBUS_FMT_SGRBG12_1X12; then the following test will fail:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
Unable to set format: Invalid argument (-22) ---
v4l2_subdev_set_format() fails which is quite logical since that
format is now not defined in mt9p031.c
And this test will fail too:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40133000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x401e3000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4021e000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40368000.
Unable to start streaming: 22. --- ioctl(VIDIOC_STREAMON) fails
What is the clean way of doing this?
Thank you.
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [alsa-devel] [PATCH 1/3] tea575x: unify read/write functions
At Mon, 9 May 2011 23:39:26 +0200,
Ondrej Zary wrote:
Implement generic read/write functions to access TEA575x tuners. They're now
implemented 4 times (once in es1968 and 3 times in fm801).
This also allows mute to work on all cards.
Also improve tuner detection/initialization.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
Applied all three patches to sound git tree. Thanks!
Takashi
--- linux-2.6.39-rc2-/include/sound/tea575x-tuner.h 2011-04-29
22:48:34.0 +0200
+++ linux-2.6.39-rc2/include/sound/tea575x-tuner.h2011-05-06
22:20:46.0 +0200
@@ -26,12 +26,17 @@
#include media/v4l2-dev.h
#include media/v4l2-ioctl.h
+#define TEA575X_DATA (1 0)
+#define TEA575X_CLK (1 1)
+#define TEA575X_WREN (1 2)
+#define TEA575X_MOST (1 3)
+
struct snd_tea575x;
struct snd_tea575x_ops {
- void (*write)(struct snd_tea575x *tea, unsigned int val);
- unsigned int (*read)(struct snd_tea575x *tea);
- void (*mute)(struct snd_tea575x *tea, unsigned int mute);
+ void (*set_pins)(struct snd_tea575x *tea, u8 pins);
+ u8 (*get_pins)(struct snd_tea575x *tea);
+ void (*set_direction)(struct snd_tea575x *tea, bool output);
};
struct snd_tea575x {
@@ -49,7 +54,7 @@ struct snd_tea575x {
void *private_data;
};
-void snd_tea575x_init(struct snd_tea575x *tea);
+int snd_tea575x_init(struct snd_tea575x *tea);
void snd_tea575x_exit(struct snd_tea575x *tea);
#endif /* __SOUND_TEA575X_TUNER_H */
--- linux-2.6.39-rc2-/sound/i2c/other/tea575x-tuner.c 2011-05-06
22:44:14.0 +0200
+++ linux-2.6.39-rc2/sound/i2c/other/tea575x-tuner.c 2011-05-06
22:21:09.0 +0200
@@ -77,11 +77,65 @@ static struct v4l2_queryctrl radio_qctrl
* lowlevel part
*/
+static void snd_tea575x_write(struct snd_tea575x *tea, unsigned int val)
+{
+ u16 l;
+ u8 data;
+
+ tea-ops-set_direction(tea, 1);
+ udelay(16);
+
+ for (l = 25; l 0; l--) {
+ data = (val 24) TEA575X_DATA;
+ val = 1; /* shift data */
+ tea-ops-set_pins(tea, data | TEA575X_WREN);
+ udelay(2);
+ tea-ops-set_pins(tea, data | TEA575X_WREN | TEA575X_CLK);
+ udelay(2);
+ tea-ops-set_pins(tea, data | TEA575X_WREN);
+ udelay(2);
+ }
+
+ if (!tea-mute)
+ tea-ops-set_pins(tea, 0);
+}
+
+static unsigned int snd_tea575x_read(struct snd_tea575x *tea)
+{
+ u16 l, rdata;
+ u32 data = 0;
+
+ tea-ops-set_direction(tea, 0);
+ tea-ops-set_pins(tea, 0);
+ udelay(16);
+
+ for (l = 24; l--;) {
+ tea-ops-set_pins(tea, TEA575X_CLK);
+ udelay(2);
+ if (!l)
+ tea-tuned = tea-ops-get_pins(tea) TEA575X_MOST ? 0
: 1;
+ tea-ops-set_pins(tea, 0);
+ udelay(2);
+ data = 1; /* shift data */
+ rdata = tea-ops-get_pins(tea);
+ if (!l)
+ tea-stereo = (rdata TEA575X_MOST) ? 0 : 1;
+ if (rdata TEA575X_DATA)
+ data++;
+ udelay(2);
+ }
+
+ if (tea-mute)
+ tea-ops-set_pins(tea, TEA575X_WREN);
+
+ return data;
+}
+
static void snd_tea575x_get_freq(struct snd_tea575x *tea)
{
unsigned long freq;
- freq = tea-ops-read(tea) TEA575X_BIT_FREQ_MASK;
+ freq = snd_tea575x_read(tea) TEA575X_BIT_FREQ_MASK;
/* freq *= 12.5 */
freq *= 125;
freq /= 10;
@@ -111,7 +165,7 @@ static void snd_tea575x_set_freq(struct
tea-val = ~TEA575X_BIT_FREQ_MASK;
tea-val |= freq TEA575X_BIT_FREQ_MASK;
- tea-ops-write(tea, tea-val);
+ snd_tea575x_write(tea, tea-val);
}
/*
@@ -139,7 +193,7 @@ static int vidioc_g_tuner(struct file *f
if (v-index 0)
return -EINVAL;
- tea-ops-read(tea);
+ snd_tea575x_read(tea);
strcpy(v-name, FM);
v-type = V4L2_TUNER_RADIO;
@@ -233,10 +287,8 @@ static int vidioc_g_ctrl(struct file *fi
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- if (tea-ops-mute) {
- ctrl-value = tea-mute;
- return 0;
- }
+ ctrl-value = tea-mute;
+ return 0;
}
return -EINVAL;
}
@@ -248,11 +300,11 @@ static int vidioc_s_ctrl(struct file *fi
switch (ctrl-id) {
case V4L2_CID_AUDIO_MUTE:
- if (tea-ops-mute) {
- tea-ops-mute(tea, ctrl-value);
+ if (tea-mute != ctrl-value) {
tea-mute = ctrl-value;
- return 0;
+ snd_tea575x_set_freq(tea);
}
+ return 0;
}
return -EINVAL;
}
@@ -317,18 +369,16 @@ static struct video_device tea575x_radio
/*
*
Re: Current status report of mt9p031.
Hi Javier,
On Tuesday 10 May 2011 09:31:02 javier Martin wrote:
On 5 May 2011 18:55, Laurent Pinchart laurent.pinch...@ideasonboard.com
wrote:
Hi Javier,
Here's the review of 0002-mt9p031.patch.
[snip]
+static int mt9p031_probe(struct i2c_client *client,
+ const struct i2c_device_id *did)
+{
+ struct mt9p031 *mt9p031;
+ struct v4l2_subdev *sd = i2c_get_clientdata(client);
+ struct mt9p031_platform_data *pdata = client-dev.platform_data;
+ struct i2c_adapter *adapter = to_i2c_adapter(client-dev.parent);
+ int ret;
+
+ if (!i2c_check_functionality(adapter, I2C_FUNC_SMBUS_WORD_DATA)) {
+ dev_warn(adapter-dev,
+ I2C-Adapter doesn't support
I2C_FUNC_SMBUS_WORD\n); + return -EIO;
+ }
+
+ mt9p031 = kzalloc(sizeof(struct mt9p031), GFP_KERNEL);
+ if (!mt9p031)
+ return -ENOMEM;
+
+ v4l2_i2c_subdev_init(mt9p031-subdev, client,
mt9p031_subdev_ops); +
+// struct isp_device *isp =
v4l2_dev_to_isp_device(subdev-v4l2_dev); +// isp_set_xclk(isp,
16*1000*1000, ISP_XCLK_A);
+
+ mt9p031-rect.left = 0/*MT9P031_COLUMN_SKIP*/;
+ mt9p031-rect.top = 0/*MT9P031_ROW_SKIP*/;
+ mt9p031-rect.width = MT9P031_MAX_WIDTH;
+ mt9p031-rect.height= MT9P031_MAX_HEIGHT;
+
+ switch (pdata-data_shift) {
+ case 2:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG8_1X8;
+ break;
+ case 1:
+ mt9p031-format.code = V4L2_MBUS_FMT_SGRBG10_1X10;
+ break;
+ case 0:
+ mt9p031-format.code = V4L2_MBUS_FMT_SBGGR12_1X12;
+ }
Why ? The sensor produces 12-bit data, you shouldn't fake other data
widths.
Hi Laurent,
I was fixing all the issues you have pointed out when I ran into this.
It is true that mt9p031 produces 12-bit data only. However, when
connected to omap3isp it is possible to discard 4 least significant
bits (i.e. changing V4L2_MBUS_FMT_SGRBG12_1X12 into
V4L2_MBUS_FMT_SGRBG8_1X8).
The point is, if I just force mt9p031-format.code =
V4L2_MBUS_FMT_SGRBG12_1X12; then the following test will fail:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
Unable to set format: Invalid argument (-22) ---
v4l2_subdev_set_format() fails which is quite logical since that
format is now not defined in mt9p031.c
And this test will fail too:
./media-ctl -r -l 'mt9p031 2-0048:0-OMAP3 ISP CCDC:0[1], OMAP3
ISP CCDC:1-OMAP3 ISP CCDC output:0[1]'
./media-ctl -f 'mt9p031 2-0048:0[SGRBG8 320x240], OMAP3 ISP
CCDC:1[SGRBG8 320x240]'
./yavta --stdout -f SGRBG8 -s 320x240 -n 4 --capture=100 --skip 3 -F
`./media-ctl -e OMAP3 ISP CCDC output` | nc 192.168.0.42 3000
Device /dev/video2 opened: OMAP3 ISP CCDC output (media).
Video format set: width: 320 height: 240 buffer size: 76800
Video format: GRBG (47425247) 320x240
4 buffers requested.
length: 76800 offset: 0
Buffer 0 mapped at address 0x40133000.
length: 76800 offset: 77824
Buffer 1 mapped at address 0x401e3000.
length: 76800 offset: 155648
Buffer 2 mapped at address 0x4021e000.
length: 76800 offset: 233472
Buffer 3 mapped at address 0x40368000.
Unable to start streaming: 22. --- ioctl(VIDIOC_STREAMON) fails
What is the clean way of doing this?
Please try replacing the media-ctl -f line with
./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \
OMAP3 ISP CCDC:0[SGRBG8 320x240], \
OMAP3 ISP CCDC:1[SGRBG8 320x240]'
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
On Tuesday 10 May 2011 11:49:10 javier Martin wrote: Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) With the latest 2.6.39-rc ? Lane-shifter support has been introduced very recently. Can you post the output of media-ctl -p after configuring formats on your pipeline ? -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
On 10 May 2011 11:53, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: On Tuesday 10 May 2011 11:49:10 javier Martin wrote: Please try replacing the media-ctl -f line with ./media-ctl -f 'mt9p031 2-0048:0[SGRBG12 320x240], \ OMAP3 ISP CCDC:0[SGRBG8 320x240], \ OMAP3 ISP CCDC:1[SGRBG8 320x240]' -- Regards, Laurent Pinchart Hi Laurent, that didn't work either (Unable to start streaming: 32.) With the latest 2.6.39-rc ? Lane-shifter support has been introduced very recently. Can you post the output of media-ctl -p after configuring formats on your pipeline ? -- Regards, Laurent Pinchart Sure, this is the output you requested: root@beagleboard:~# ./media-ctl -p Opening media device /dev/media0 Enumerating entities Found 16 entities Enume rating pads and links Device topology - entity 1: OMAP3 ISP CCP2 (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev0 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCP2 input':pad0 [] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad0 [] - entity 2: OMAP3 ISP CCP2 input (1 pad, 1 link) type Node subtype V4L device node name /dev/video0 pad0: Output - 'OMAP3 ISP CCP2':pad0 [] - entity 3: OMAP3 ISP CSI2a (2 pads, 2 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev1 pad0: Input [SGRBG10 4096x4096] pad1: Output [SGRBG10 4096x4096] - 'OMAP3 ISP CSI2a output':pad0 [] - 'OMAP3 ISP CCDC':pad0 [] - entity 4: OMAP3 ISP CSI2a output (1 pad, 1 link) type Node subtype V4L device node name /dev/video1 pad0: Input - 'OMAP3 ISP CSI2a':pad1 [] - entity 5: OMAP3 ISP CCDC (3 pads, 9 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev2 pad0: Input [SGRBG8 320x240] - 'OMAP3 ISP CCP2':pad1 [] - 'OMAP3 ISP CSI2a':pad1 [] - 'mt9p031 2-0048':pad0 [ACTIVE] pad1: Output [SGRBG8 320x240] - 'OMAP3 ISP CCDC output':pad0 [ACTIVE] - 'OMAP3 ISP resizer':pad0 [] pad2: Output [SGRBG8 320x239] - 'OMAP3 ISP preview':pad0 [] - 'OMAP3 ISP AEWB':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP AF':pad0 [IMMUTABLE,ACTIVE] - 'OMAP3 ISP histogram':pad0 [IMMUTABLE,ACTIVE] - entity 6: OMAP3 ISP CCDC output (1 pad, 1 link) type Node subtype V4L device node name /dev/video2 pad0: Input - 'OMAP3 ISP CCDC':pad1 [ACTIVE] - entity 7: OMAP3 ISP preview (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev3 pad0: Input [SGRBG10 4096x4096] - 'OMAP3 ISP CCDC':pad2 [] - 'OMAP3 ISP preview input':pad0 [] pad1: Output [YUYV 4082x4088] - 'OMAP3 ISP preview output':pad0 [] - 'OMAP3 ISP resizer':pad0 [] - entity 8: OMAP3 ISP preview input (1 pad, 1 link) type Node subtype V4L device node name /dev/video3 pad0: Output - 'OMAP3 ISP preview':pad0 [] - entity 9: OMAP3 ISP preview output (1 pad, 1 link) type Node subtype V4L device node name /dev/video4 pad0: Input - 'OMAP3 ISP preview':pad1 [] - entity 10: OMAP3 ISP resizer (2 pads, 4 links) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev4 pad0: Input [YUYV 4095x4095 (4,6)/4086x4082] - 'OMAP3 ISP CCDC':pad1 [] - 'OMAP3 ISP preview':pad1 [] - 'OMAP3 ISP resizer input':pad0 [] pad1: Output [YUYV 4096x4095] - 'OMAP3 ISP resizer output':pad0 [] - entity 11: OMAP3 ISP resizer input (1 pad, 1 link) type Node subtype V4L device node name /dev/video5 pad0: Output - 'OMAP3 ISP resizer':pad0 [] - entity 12: OMAP3 ISP resizer output (1 pad, 1 link) type Node subtype V4L device node name /dev/video6 pad0: Input - 'OMAP3 ISP resizer':pad1 [] - entity 13: OMAP3 ISP AEWB (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev5 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 14: OMAP3 ISP AF (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev6 pad0: Input - 'OMAP3 ISP CCDC':pad2 [IMMUTABLE,ACTIVE] - entity 15: OMAP3 ISP histogram (1 pad, 1 link) type V4L2 subdev subtype Unknown device node name /dev/v4l-subdev7 pad0: Input -
Re: Current status report of mt9p031.
I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
Hi Javier, On Tuesday 10 May 2011 13:05:35 javier Martin wrote: I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 There's no such commit in mainline. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
On 10 May 2011 14:25, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Javier, On Tuesday 10 May 2011 13:05:35 javier Martin wrote: I almost forget, I am using 2.6.39-rc commit bd99337e95b6bba976e41a5f3cf65c1f04069156 There's no such commit in mainline. -- Regards, Laurent Pinchart Sorry Laurent, the commit is 5895198c56d131cc696556a45f7ff0ea99ac297b -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Query] Anyone here working with the mainline omap3isp driver?
On Tuesday 10 May 2011 00:04:09 Aguirre, Sergio wrote: Hi Everyone, I'll just like to know if there's someone working with the mainline version of the omap3isp driver. I do :-) Ohad (in CC) has some omap3 iommu changes which might affect the omap3isp driver. Which changes are you referring to ? IOMMU is known to be broken in mainline. I've sent a patch to fix it (https://patchwork.kernel.org/patch/736351/). I have been a bit away of the omap3 driver these days, so, if there's someone else that can try some iommu changes on top, that'll be great. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: IR remote control autorepeat / evdev
On 10.05.2011 08:30, Peter Hutterer wrote: On Tue, May 10, 2011 at 08:14:30AM +0300, Anssi Hannula wrote: On 10.05.2011 07:11, Peter Hutterer wrote: On Sun, May 08, 2011 at 07:38:00AM +0300, Anssi Hannula wrote: Hi all! Most IR/RF remotes differ from normal keyboards in that they don't provide release events. They do provide native repeat events, though. Currently the Linux kernel RC/input subsystems provide a simulated autorepeat for remote controls (default delay 500ms, period 33ms), and X.org server ignores these events and generates its own autorepeat for them. The kernel RC subsystem provides a simulated release event when 250ms has passed since the last native event (repeat or non-repeat) was received from the device. This is problematic, since it causes lots of extra repeat events to be always sent (for up to 250ms) after the user has released the remote control button, which makes the remote quite uncomfortable to use. I got a bit confused reading this description. Does this mean that remotes usually send: key press - repeat - repeat - ... - repeat - silence where the silence indicates that the key has been released? Which the kernel after 250ms translates into a release event. And the kernel discards the repeats and generates it's own on 500/33? Do I get this right so far? Yes. If so, I'm not sure how to avoid the 250ms delay since we have no indication from the hardware when the silence will stop, right? Yes. AFAICS what we need is to not use softrepeat for these devices and instead use the native repeats. The 250ms release delay could then be kept (as it wouldn't cause unwanted repeats anymore) or it could be made 0ms if that is deemed better. I listed some ways to do that below in my original post. Note that the repeat delay and ratio are configurable per-device using XKB, so you could set up the 500/33 in X too. It wouldn't make any difference with the actual issue which is autorepeat happening after physical key released. I guess the reason this hasn't come up earlier is that the unified IR/RC subsystem in the linux kernel is still quite new. It definitely needs to be improved regarding this issue - just trying to figure out the best way to do it. right. we used to have hardware repeats in X a few releases back. I think 1.6 was the first one that shifted to pure software autorepeat. One of the results we saw in the transition period was the clash of hw autorepeat (in X's input system, anything that comes out of the kernel counts as hw) and software repeat. Integrating them back in is going to be a bit iffy, especially since you need the integration with XKB on each device, essentially disallowing the clients from enabling autorepeat. Not 100% what's required there. The evtev part is going to be the simplest part of all that. I suspected it might be tricky. So maybe (at least for the time being) remote controls in X should simply get KeyRelease immediately after every KeyPress? Meaning that either a) kernel does it (while maybe providing some new extra info for those evdev users that want to distinguish repeats from new keypresses - original suggestion 4), or b) kernel provides a flag which causes the X evdev driver to follow-up every keydown/repeat event with an immediate release event. (both of these include kernel changed to use native repeats instead of softrepeats, which is trivial) Now, IMO something should be done to fix this. But what exactly? Here are two ideas that would remove these ghost repeats: 1. Do not provide any repeat/release simulation in the kernel for RC devices (by default?), just provide both keydown and immediate release events for every native keypress or repeat received from the device. + Very simple to implement - We lose the ability to track repeats, i.e. if a new event was a repeat or a new keypress; holding down a key becomes impossible or 2. Replace kernel autorepeat simulation by passing through the native repeat events (probably filtering them according to REP_DELAY and REP_PERIOD), and have a device property bit (fetchable via EVIOCGPROP) indicating that the keyrelease is simulated, and have the X server use the native repeats instead of softrepeats for such a device. + The userspace correctly gets repeat events tagged as repeats and release events when appropriate (albeit a little late) - Adds complexity. Also, while the kernel part is quite easy to implement, I'm not sure if the X server part is. or 3. Same as 1., but indicate the repeatness of an event with a new additional special event before EV_SYN (sync event). + Simple to implement - Quite hacky, and userspace still can't guess from initial keypress/release if the key is still pressed down or not. 4. Same as 1., but have a new EV_RC with RC_KEYDOWN and RC_KEYUP events, with RC_KEYDOWN sent when a key is pressed down a first time along with the normal EV_KEY event, and RC_KEYUP
[PATCH] cx18: Move spinlock and vb_type initialisation into stream_init
The initialisation of vb_type in serialized_open was preventing
REQBUFS from working reliably. Remove it, and move the spinlock into
stream_init for good measure - it's only used when we have a stream
that supports videobuf anyway.
Signed-off-by: Simon Farnsworth simon.farnswo...@onelan.co.uk
---
Mauro,
This fixes a bug I introduced, and noticed while trying to work out
how videobuf works and interacts with the rest of the driver, in
preparation for working out how to port this code to videobuf2.
Briefly, if you open a device node at the wrong time, you lose
videobuf support forever.
Please consider this for 2.6.40,
Simon
drivers/media/video/cx18/cx18-fileops.c |3 ---
drivers/media/video/cx18/cx18-streams.c |2 ++
2 files changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/cx18/cx18-fileops.c
b/drivers/media/video/cx18/cx18-fileops.c
index 6609222..07411f3 100644
--- a/drivers/media/video/cx18/cx18-fileops.c
+++ b/drivers/media/video/cx18/cx18-fileops.c
@@ -810,9 +810,6 @@ static int cx18_serialized_open(struct cx18_stream *s,
struct file *filp)
item-cx = cx;
item-type = s-type;
- spin_lock_init(s-vbuf_q_lock);
- s-vb_type = 0;
-
item-open_id = cx-open_id++;
filp-private_data = item-fh;
diff --git a/drivers/media/video/cx18/cx18-streams.c
b/drivers/media/video/cx18/cx18-streams.c
index 24c9688..4282ff5 100644
--- a/drivers/media/video/cx18/cx18-streams.c
+++ b/drivers/media/video/cx18/cx18-streams.c
@@ -275,6 +275,8 @@ static void cx18_stream_init(struct cx18 *cx, int type)
init_timer(s-vb_timeout);
spin_lock_init(s-vb_lock);
if (type == CX18_ENC_STREAM_TYPE_YUV) {
+ spin_lock_init(s-vbuf_q_lock);
+
s-vb_type = V4L2_BUF_TYPE_VIDEO_CAPTURE;
videobuf_queue_vmalloc_init(s-vbuf_q, cx18_videobuf_qops,
cx-pci_dev-dev, s-vbuf_q_lock,
--
1.7.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
Hi Laurent,
information for data lane shifter is passed through platform data:
/**
* struct isp_parallel_platform_data - Parallel interface platform data
* @data_lane_shift: Data lane shifter
* 0 - CAMEXT[13:0] - CAM[13:0]
* 1 - CAMEXT[13:2] - CAM[11:0]
* 2 - CAMEXT[13:4] - CAM[9:0]
* 3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
* 0 - Non Inverted, 1 - Inverted
* @bridge: CCDC Bridge input control
* ISPCTRL_PAR_BRIDGE_DISABLE - Disable
* ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
* ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
This way I am able to convert from 12bpp to 8bpp:
data_lane_shift = 2 and bridge = ISPCTRL_PAR_BRIDGE_DISABLE
--
Javier Martin
Vista Silicon S.L.
CDTUC - FASE C - Oficina S-345
Avda de los Castros s/n
39005- Santander. Cantabria. Spain
+34 942 25 32 60
www.vista-silicon.com
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Current status report of mt9p031.
Hi Javier,
On Tuesday 10 May 2011 16:14:09 javier Martin wrote:
Hi Laurent,
information for data lane shifter is passed through platform data:
/**
* struct isp_parallel_platform_data - Parallel interface platform data
* @data_lane_shift: Data lane shifter
*0 - CAMEXT[13:0] - CAM[13:0]
*1 - CAMEXT[13:2] - CAM[11:0]
*2 - CAMEXT[13:4] - CAM[9:0]
*3 - CAMEXT[13:6] - CAM[7:0]
* @clk_pol: Pixel clock polarity
*0 - Non Inverted, 1 - Inverted
* @bridge: CCDC Bridge input control
*ISPCTRL_PAR_BRIDGE_DISABLE - Disable
*ISPCTRL_PAR_BRIDGE_LENDIAN - Little endian
*ISPCTRL_PAR_BRIDGE_BENDIAN - Big endian
*/
struct isp_parallel_platform_data {
unsigned int data_lane_shift:2;
unsigned int clk_pol:1;
unsigned int bridge:4;
};
This way I am able to convert from 12bpp to 8bpp:
data_lane_shift = 2 and bridge = ISPCTRL_PAR_BRIDGE_DISABLE
That's usually used to define a static conversion, when sensor data lines 7-0
are connected to ISP data lines 11-3. Capturing 8-bit raw bayer data from a
12-bit raw bayer sensor should be done by dynamically configuring the
pipeline.
I'm not at home and don't have access to my OMAP3 hardware now, I'll try your
use case when I'll come back (end of the week or during the weekend).
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
fm801: implement TEA575x tuner autodetection
Autodetect TEA575x tuner connection type during init. This allows tuner to
work out-of-the box.
tea575x_tuner module parameter remains functional to force tuner type.
Tested with SF256-PCP and SF64-PCR.
Signed-off-by: Ondrej Zary li...@rainbow-software.org
--- linux-2.6.39-rc2-/sound/pci/fm801.c 2011-05-10 22:31:45.0 +0200
+++ linux-2.6.39-rc2/sound/pci/fm801.c 2011-05-10 23:21:42.0 +0200
@@ -53,7 +53,7 @@ static int enable[SNDRV_CARDS] = SNDRV_D
/*
* Enable TEA575x tuner
*1 = MediaForte 256-PCS
- *2 = MediaForte 256-PCPR
+ *2 = MediaForte 256-PCP
*3 = MediaForte 64-PCR
* 16 = setup tuner only (this is additional bit), i.e. SF64-PCR FM card
* High 16-bits are video (radio) device number + 1
@@ -67,7 +67,7 @@ MODULE_PARM_DESC(id, ID string for the
module_param_array(enable, bool, NULL, 0444);
MODULE_PARM_DESC(enable, Enable FM801 soundcard.);
module_param_array(tea575x_tuner, int, NULL, 0444);
-MODULE_PARM_DESC(tea575x_tuner, TEA575x tuner access method (1 = SF256-PCS,
2=SF256-PCPR, 3=SF64-PCR, +16=tuner-only).);
+MODULE_PARM_DESC(tea575x_tuner, TEA575x tuner access method (0 = auto, 1 =
SF256-PCS, 2=SF256-PCP, 3=SF64-PCR, 8=disable, +16=tuner-only).);
#define TUNER_ONLY (14)
#define TUNER_TYPE_MASK(~TUNER_ONLY 0x)
@@ -720,12 +720,13 @@ static int __devinit snd_fm801_pcm(struc
/* GPIO to TEA575x maps */
struct snd_fm801_tea575x_gpio {
u8 data, clk, wren, most;
+ char *name;
};
static struct snd_fm801_tea575x_gpio snd_fm801_tea575x_gpios[] = {
- { .data = 1, .clk = 3, .wren = 2, .most = 0 }, /* SF256-PCS */
- { .data = 1, .clk = 0, .wren = 2, .most = 3 }, /* SF256-PCP */
- { .data = 2, .clk = 0, .wren = 1, .most = 3 }, /* SF64-PCR */
+ { .data = 1, .clk = 3, .wren = 2, .most = 0, .name = SF256-PCS },
+ { .data = 1, .clk = 0, .wren = 2, .most = 3, .name = SF256-PCP },
+ { .data = 2, .clk = 0, .wren = 1, .most = 3, .name = SF64-PCR },
};
static void snd_fm801_tea575x_set_pins(struct snd_tea575x *tea, u8 pins)
@@ -1229,14 +1230,24 @@ static int __devinit snd_fm801_create(st
snd_card_set_dev(card, pci-dev);
#ifdef TEA575X_RADIO
+ chip-tea.card = card;
+ chip-tea.freq_fixup = 10700;
+ chip-tea.private_data = chip;
+ chip-tea.ops = snd_fm801_tea_ops;
if ((tea575x_tuner TUNER_TYPE_MASK) 0
(tea575x_tuner TUNER_TYPE_MASK) 4) {
- chip-tea.card = card;
- chip-tea.freq_fixup = 10700;
- chip-tea.private_data = chip;
- chip-tea.ops = snd_fm801_tea_ops;
- snd_tea575x_init(chip-tea);
- }
+ if (snd_tea575x_init(chip-tea))
+ snd_printk(KERN_ERR TEA575x radio not found\n);
+ } else if ((tea575x_tuner TUNER_TYPE_MASK) == 0)
+ /* autodetect tuner connection */
+ for (tea575x_tuner = 1; tea575x_tuner = 3; tea575x_tuner++) {
+ chip-tea575x_tuner = tea575x_tuner;
+ if (!snd_tea575x_init(chip-tea)) {
+ snd_printk(KERN_INFO detected TEA575x radio
type %s\n,
+ snd_fm801_tea575x_gpios[tea575x_tuner -
1].name);
+ break;
+ }
+ }
#endif
*rchip = chip;
--
Ondrej Zary
--
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: Remote control not working for Terratec Cinergy C (2.6.37 Mantis driver)
On Fri, 6 May 2011, Marko Ristola wrote: The hardware device is active (it is enabled, messages are sent from the remote to the Kernel Mantis software driver. The bytes can be logged into /var/log/messages file. That's all the driver is designed to do at this point. It doesn't sound promising. Thanks for the update Marko. -- Adrian C. (anrxc) | anrxc..sysphere.org | PGP ID: D20A0618 PGP FP: 02A5 628A D8EE 2A93 996E 929F D5CB 31B7 D20A 0618 -- 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
TT S2-3650CI problems with high-SR DVB-S2 transponders
I've been trying to get TechnoTrend S2-3650CI running with DVB-S2 transponder with SR of 3. I'm using stock Debian 6 kernel 2.6.32-5-amd64 and s2-liplianin tree. Initially, the device couldn't lock the 30K transponders at all. After applying patch [1], it locks without any problems, and does so very fast: sat 0, frequency 11632 MHz V, symbolrate 3000, coderate auto, rolloff 0.35 vpid 0x1fff, apid 0x1fff, sid 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal | snr 0004 | ber | unc fffe | status 1b | signal 05aa | snr 0023 | ber 00516155 | unc fffe | FE_HAS_LOCK This happens each and every time I try. So far, so good, but when I'm trying to stream a PID with dvblast, I get lots of TS discontinuities. It does read the NIT and PAT fine, but nothing else is nearly-usable. I've then tried the STB6100 patch [2], but it does not seem to do any help in this case. Any ideas? -- 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: TT S2-3650CI problems with high-SR DVB-S2 transponders
На 11.5.2011 г. 02:24 ч., Doychin Dokov написа: I've been trying to get TechnoTrend S2-3650CI running with DVB-S2 transponder with SR of 3. I'm using stock Debian 6 kernel 2.6.32-5-amd64 and s2-liplianin tree. Initially, the device couldn't lock the 30K transponders at all. After applying patch [1], it locks without any problems, and does so very fast: sat 0, frequency 11632 MHz V, symbolrate 3000, coderate auto, rolloff 0.35 vpid 0x1fff, apid 0x1fff, sid 0x using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' status 00 | signal | snr 0004 | ber | unc fffe | status 1b | signal 05aa | snr 0023 | ber 00516155 | unc fffe | FE_HAS_LOCK This happens each and every time I try. So far, so good, but when I'm trying to stream a PID with dvblast, I get lots of TS discontinuities. It does read the NIT and PAT fine, but nothing else is nearly-usable. I've then tried the STB6100 patch [2], but it does not seem to do any help in this case. Any ideas? Sorry, missed some info: [1] http://dev.net1.cc/dvb-s23650/patch-01-lock-fix.diff [2] http://dev.net1.cc/dvb-s23650/patch-02-noise-filter.diff Also, the same device on the same machine, but under Windows OS, works fine and decodes the very same transponder with no artefacts at all. The firmware of the device is updated with the latest one from the TT web site. Thanks very much for any help! -- 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
