Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Prabhakar,
On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote:
...
+unsigned short len;
+void *config;
+};
+
+5: IOCTL: VPFE_CMD_S_CCDC_RAW_PARAMS/VPFE_CMD_G_CCDC_RAW_PARAMS
+Description:
+Sets/Gets the CCDC parameter
+Parameter:
+/**
+ * struct ccdc_config_params_raw - structure for configuring
ccdc params
+ * @linearize: linearization parameters for image sensor data input
+ * @df_csc: data formatter or CSC
+ * @dfc: defect Pixel Correction (DFC) configuration
+ * @bclamp: Black/Digital Clamp configuration
+ * @gain_offset: Gain, offset adjustments
+ * @culling: Culling
+ * @pred: predictor for DPCM compression
+ * @horz_offset: horizontal offset for Gain/LSC/DFC
+ * @vert_offset: vertical offset for Gain/LSC/DFC
+ * @col_pat_field0: color pattern for field 0
+ * @col_pat_field1: color pattern for field 1
+ * @data_size: data size from 8 to 16 bits
+ * @data_shift: data shift applied before storing to SDRAM
+ * @test_pat_gen: enable input test pattern generation
+ */
+struct ccdc_config_params_raw {
+struct ccdc_linearize linearize;
+struct ccdc_df_csc df_csc;
+struct ccdc_dfc dfc;
+struct ccdc_black_clamp bclamp;
+struct ccdc_gain_offsets_adj gain_offset;
+struct ccdc_cul culling;
+enum ccdc_dpcm_predictor pred;
+unsigned short horz_offset;
+unsigned short vert_offset;
+struct ccdc_col_pat col_pat_field0;
+struct ccdc_col_pat col_pat_field1;
+enum ccdc_data_size data_size;
+enum ccdc_datasft data_shift;
+unsigned char test_pat_gen;
Are the struct definitions available somewhere? I bet more than the test
pattern Laurent suggested might be implementable as controls. The dpcm
predictor, for example.
I will check on the DPSM test pattern. The definitions are available
at:http://davinci-linux-open-source.1494791.n2.nabble.com/RESEND-RFC-PATCH-v4-00-15-RFC-for-Media-Controller-capture-driver-for-DM365-td7003648.html
Thanks!
I think the DPCM predictor should be made a control in the image processing
controls class. The test pattern would fit there as well I think.
For test pattern you meant control to enable/disable it ?
There are two approaches I can think of.
One is a menu control which can be used to choose the test pattern (or
disable it). The control could be standardised but the menu items would have
to be hardware-specific since the test patterns themselves are not
standardised.
The alternative is to have a boolean control to enable (and disable) the
test pattern and then a menu control to choose which one to use. Using or
implemeting the control to select the test pattern isn't even strictly
necessary to get a test pattern out of the device: one can enable it without
knowing which one it is.
So which one would be better? Similar cases include V4L2_CID_SCENE_MODE
which is used to choose the scene mode from a list of alternatives. The main
difference to this case is that the menu items of the scene mode control are
standardised, too.
I'd be inclined to have a single menu control, even if the other menu items
will be device-specific. The first value (0) still has to be documented to
mean the test pattern is disabled.
Laurent, Hans: what do you think?
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] rtl28xxu: stream did not start after stop on USB3.0
On 08/22/2012 01:56 AM, Antti Palosaari wrote:
Stream did not start anymore after stream was stopped once.
Following error can be seen, xhci_hcd
WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
usb_clear_halt for streaming endpoint helps.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index d2b1505..1ccb99b 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -834,6 +834,7 @@ static int rtl28xxu_streaming_ctrl(struct dvb_frontend
*fe , int onoff)
if (onoff) {
buf[0] = 0x00;
buf[1] = 0x00;
+ usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
} else {
buf[0] = 0x10; /* stall EPA */
buf[1] = 0x02; /* reset EPA */
After every soft/warm [re]boot only after first scandvb:
[ cut here ]
WARNING: at drivers/usb/host/ehci-hcd.c:1226
ehci_endpoint_reset+0x111/0x120()
Hardware name: M720-US3
clear_halt for a busy endpoint
Modules linked in: fc0012(O) rtl2832(O) dvb_usb_rtl28xxu(O) rtl2830(O)
dvb_usbv2(O) dvb_core(O) nvidia(PO) tvaudio(O) tda7432(O) msp3400(O)
tuner_simple(O) tuner_types(O) wm8775(O) snd_hda_codec_realtek
tda9887(O) tda8290(O) tuner(O) cx25840(O) snd_hda_intel snd_bt87x
bttv(O) ivtv(O) snd_hda_codec snd_hwdep tveeprom(O) cx2341x(O)
btcx_risc(O) snd_pcm snd_page_alloc snd_timer snd soundcore ppdev
videobuf_dma_sg(O) videobuf_core(O) v4l2_common(O) parport_serial
parport_pc parport videodev(O) edac_core media(O) i2c_nforce2 rc_core(O)
i2c_algo_bit microcode i2c_core edac_mce_amd vhost_net tun macvtap
macvlan kvm_amd kvm uinput binfmt_misc raid1 r8169 ata_generic pata_acpi
mii usb_storage skge pata_amd wmi sunrpc be2iscsi bnx2i cnic uio cxgb4i
cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs
libiscsi scsi_transport_iscsi [last unloaded: scsi_wait_scan]
Pid: 1170, comm: scandvb Tainted: P O 3.5.2-3.fc17.x86_64 #1
Call Trace:
[810584bf] warn_slowpath_common+0x7f/0xc0
[810585b6] warn_slowpath_fmt+0x46/0x50
[81444a31] ehci_endpoint_reset+0x111/0x120
[8142c135] usb_hcd_reset_endpoint+0x25/0x70
[8142d468] usb_reset_endpoint+0x28/0x40
[8142e06e] usb_clear_halt+0x6e/0x80
[a0f2baed] rtl28xxu_streaming_ctrl+0xad/0x110 [dvb_usb_rtl28xxu]
[a0f50375] dvb_usb_start_feed+0x235/0x440 [dvb_usbv2]
[8115ca5d] ? __vmalloc_node_range+0x17d/0x240
[a0f111b9] ? dvb_dmxdev_filter_start+0x2c9/0x3e0 [dvb_core]
[a0f12b00] dmx_section_feed_start_filtering+0xe0/0x180 [dvb_core]
[a0f110fe] dvb_dmxdev_filter_start+0x20e/0x3e0 [dvb_core]
[a0f11945] dvb_demux_do_ioctl+0x405/0x640 [dvb_core]
[a0f11540] ? dvb_dvr_do_ioctl+0x130/0x130 [dvb_core]
[a0f0fa36] dvb_usercopy+0x86/0x1d0 [dvb_core]
[811976d1] ? do_filp_open+0x41/0xa0
[a0f0ffa5] dvb_demux_ioctl+0x15/0x20 [dvb_core]
[811996c9] do_vfs_ioctl+0x99/0x580
[812793da] ? inode_has_perm.isra.31.constprop.61+0x2a/0x30
[8127a9b7] ? file_has_perm+0x97/0xb0
[81199c49] sys_ioctl+0x99/0xa0
[81614969] system_call_fastpath+0x16/0x1b
---[ end trace cce2913a24da6585 ]---
media_build
commit 420335f564c32517a791ecea3909af233925634d
Cheers,
poma
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/5] rtl28xxu: stream did not start after stop on USB3.0
On 09/01/2012 04:33 PM, poma wrote:
On 08/22/2012 01:56 AM, Antti Palosaari wrote:
Stream did not start anymore after stream was stopped once.
Following error can be seen, xhci_hcd
WARN Set TR Deq Ptr cmd failed due to incorrect slot or ep state.
usb_clear_halt for streaming endpoint helps.
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index d2b1505..1ccb99b 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -834,6 +834,7 @@ static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe
, int onoff)
if (onoff) {
buf[0] = 0x00;
buf[1] = 0x00;
+ usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
} else {
buf[0] = 0x10; /* stall EPA */
buf[1] = 0x02; /* reset EPA */
After every soft/warm [re]boot only after first scandvb:
[ cut here ]
WARNING: at drivers/usb/host/ehci-hcd.c:1226
ehci_endpoint_reset+0x111/0x120()
Hardware name: M720-US3
clear_halt for a busy endpoint
Modules linked in: fc0012(O) rtl2832(O) dvb_usb_rtl28xxu(O) rtl2830(O)
dvb_usbv2(O) dvb_core(O) nvidia(PO) tvaudio(O) tda7432(O) msp3400(O)
tuner_simple(O) tuner_types(O) wm8775(O) snd_hda_codec_realtek
tda9887(O) tda8290(O) tuner(O) cx25840(O) snd_hda_intel snd_bt87x
bttv(O) ivtv(O) snd_hda_codec snd_hwdep tveeprom(O) cx2341x(O)
btcx_risc(O) snd_pcm snd_page_alloc snd_timer snd soundcore ppdev
videobuf_dma_sg(O) videobuf_core(O) v4l2_common(O) parport_serial
parport_pc parport videodev(O) edac_core media(O) i2c_nforce2 rc_core(O)
i2c_algo_bit microcode i2c_core edac_mce_amd vhost_net tun macvtap
macvlan kvm_amd kvm uinput binfmt_misc raid1 r8169 ata_generic pata_acpi
mii usb_storage skge pata_amd wmi sunrpc be2iscsi bnx2i cnic uio cxgb4i
cxgb4 cxgb3i cxgb3 mdio libcxgbi libiscsi_tcp qla4xxx iscsi_boot_sysfs
libiscsi scsi_transport_iscsi [last unloaded: scsi_wait_scan]
Pid: 1170, comm: scandvb Tainted: P O 3.5.2-3.fc17.x86_64 #1
Call Trace:
[810584bf] warn_slowpath_common+0x7f/0xc0
[810585b6] warn_slowpath_fmt+0x46/0x50
[81444a31] ehci_endpoint_reset+0x111/0x120
[8142c135] usb_hcd_reset_endpoint+0x25/0x70
[8142d468] usb_reset_endpoint+0x28/0x40
[8142e06e] usb_clear_halt+0x6e/0x80
[a0f2baed] rtl28xxu_streaming_ctrl+0xad/0x110 [dvb_usb_rtl28xxu]
[a0f50375] dvb_usb_start_feed+0x235/0x440 [dvb_usbv2]
[8115ca5d] ? __vmalloc_node_range+0x17d/0x240
[a0f111b9] ? dvb_dmxdev_filter_start+0x2c9/0x3e0 [dvb_core]
[a0f12b00] dmx_section_feed_start_filtering+0xe0/0x180 [dvb_core]
[a0f110fe] dvb_dmxdev_filter_start+0x20e/0x3e0 [dvb_core]
[a0f11945] dvb_demux_do_ioctl+0x405/0x640 [dvb_core]
[a0f11540] ? dvb_dvr_do_ioctl+0x130/0x130 [dvb_core]
[a0f0fa36] dvb_usercopy+0x86/0x1d0 [dvb_core]
[811976d1] ? do_filp_open+0x41/0xa0
[a0f0ffa5] dvb_demux_ioctl+0x15/0x20 [dvb_core]
[811996c9] do_vfs_ioctl+0x99/0x580
[812793da] ? inode_has_perm.isra.31.constprop.61+0x2a/0x30
[8127a9b7] ? file_has_perm+0x97/0xb0
[81199c49] sys_ioctl+0x99/0xa0
[81614969] system_call_fastpath+0x16/0x1b
---[ end trace cce2913a24da6585 ]---
media_build
commit 420335f564c32517a791ecea3909af233925634d
That is already fixed, but I haven't sent patch yet. Currently last patch:
http://git.linuxtv.org/anttip/media_tree.git/shortlog/refs/heads/for_v3.7-10
Mabbe I will sent that fix out to mailing list right now.
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/5] rtl28xxu: fix rtl2832u module reload fails bug
On 08/22/2012 01:56 AM, Antti Palosaari wrote: This is workaround / partial fix. rtl2832u_power_ctrl() and rtl2832u_frontend_attach() needs to be go through carefully and fix properly. There is clearly some logical errors when handling power-management ang GPIOs... Signed-off-by: Antti Palosaari cr...@iki.fi Cc: Thomas Mair thomas.mai...@googlemail.com --- drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 11 --- 1 file changed, 11 deletions(-) diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c index 1ccb99b..c246c50 100644 --- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c +++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c @@ -946,17 +946,6 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d, int onoff) if (ret) goto err; - /* demod HW reset */ - ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, val); - if (ret) - goto err; - /* bit 5 to 0 */ - val = 0xdf; - - ret = rtl28xx_wr_reg(d, SYS_DEMOD_CTL, val); - if (ret) - goto err; - ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL, val); if (ret) goto err; Test: PASSED! Working zapping on every hard/cold boot, soft/warm [re]boot and every module(dvb_usb_rtl28xxu) [re]load. Outside the box thinking! Antti, thank you very much! media_build commit 420335f564c32517a791ecea3909af233925634d 1f4d:b803 G-Tek Electronics Group Lifeview LV5TDLX DVB-T [RTL2832U] Cheers, poma -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] rtl28xxu: correct usb_clear_halt() usage
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55 +++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
- int ret;
- u8 buf[2];
- struct dvb_usb_device *d = fe_to_d(fe);
-
- dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
- if (onoff) {
- buf[0] = 0x00;
- buf[1] = 0x00;
- usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
- } else {
- buf[0] = 0x10; /* stall EPA */
- buf[1] = 0x02; /* reset EPA */
- }
-
- ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
- if (ret)
- goto err;
-
- return ret;
-err:
- dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
- return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
- u8 gpio, sys0;
+ u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+ epa_ctl[0] = 0x00; /* clear stall */
+ epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+ epa_ctl[0] = 0x10; /* set stall */
+ epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n, __func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
+ /* streaming EP: stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+ if (ret)
+ goto err;
+
+ if (onoff)
+ usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
goto err;
+ /* streaming EP: clear stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+ if (ret)
+ goto err;
+
+ ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+ if (ret)
+ goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
+ /* streaming EP: set stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+ if (ret)
+ goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Sakari, On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote: On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote: [snip] For test pattern you meant control to enable/disable it ? There are two approaches I can think of. One is a menu control which can be used to choose the test pattern (or disable it). The control could be standardised but the menu items would have to be hardware-specific since the test patterns themselves are not standardised. Agreed. The test patterns themselves are highly hardware-specific. From personal experience with sensors, most devices implement a small, fixed set of test patterns that can be exposed through a menu control. However, some devices also implement more configurable test patterns. For instance the MT9V032 can generate horizontal, vertical or diagonal test patterns, or a uniform grey test pattern with a user-configurable value. This would then require two controls. The alternative is to have a boolean control to enable (and disable) the test pattern and then a menu control to choose which one to use. Using or implemeting the control to select the test pattern isn't even strictly necessary to get a test pattern out of the device: one can enable it without knowing which one it is. So which one would be better? Similar cases include V4L2_CID_SCENE_MODE which is used to choose the scene mode from a list of alternatives. The main difference to this case is that the menu items of the scene mode control are standardised, too. I'd be inclined to have a single menu control, even if the other menu items will be device-specific. The first value (0) still has to be documented to mean the test pattern is disabled. Laurent, Hans: what do you think? A menu control with value 0 meaning test pattern disabled has my preference as well. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Laurent, On Sat, Sep 1, 2012 at 7:52 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sakari, On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote: On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote: [snip] For test pattern you meant control to enable/disable it ? There are two approaches I can think of. One is a menu control which can be used to choose the test pattern (or disable it). The control could be standardised but the menu items would have to be hardware-specific since the test patterns themselves are not standardised. Agreed. The test patterns themselves are highly hardware-specific. From personal experience with sensors, most devices implement a small, fixed set of test patterns that can be exposed through a menu control. However, some devices also implement more configurable test patterns. For instance the MT9V032 can generate horizontal, vertical or diagonal test patterns, or a uniform grey test pattern with a user-configurable value. This would then require two controls. two controls I didn't get it ? When we have menu itself with a list of standard patterns why would two controls be required ? Thx, --Prabhakar Lad The alternative is to have a boolean control to enable (and disable) the test pattern and then a menu control to choose which one to use. Using or implemeting the control to select the test pattern isn't even strictly necessary to get a test pattern out of the device: one can enable it without knowing which one it is. So which one would be better? Similar cases include V4L2_CID_SCENE_MODE which is used to choose the scene mode from a list of alternatives. The main difference to this case is that the menu items of the scene mode control are standardised, too. I'd be inclined to have a single menu control, even if the other menu items will be device-specific. The first value (0) still has to be documented to mean the test pattern is disabled. Laurent, Hans: what do you think? A menu control with value 0 meaning test pattern disabled has my preference as well. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtl28xxu: correct usb_clear_halt() usage
On 09/01/2012 03:54 PM, Antti Palosaari wrote:
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55
+++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
- int ret;
- u8 buf[2];
- struct dvb_usb_device *d = fe_to_d(fe);
-
- dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
- if (onoff) {
- buf[0] = 0x00;
- buf[1] = 0x00;
- usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
- } else {
- buf[0] = 0x10; /* stall EPA */
- buf[1] = 0x02; /* reset EPA */
- }
-
- ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
- if (ret)
- goto err;
-
- return ret;
-err:
- dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
- return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
- u8 gpio, sys0;
+ u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device
*d, int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+ epa_ctl[0] = 0x00; /* clear stall */
+ epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+ epa_ctl[0] = 0x10; /* set stall */
+ epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n, __func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
+ /* streaming EP: stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+ if (ret)
+ goto err;
+
+ if (onoff)
+ usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
goto err;
+ /* streaming EP: clear stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+ if (ret)
+ goto err;
+
+ ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+ if (ret)
+ goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device
*d, int onoff)
if (ret)
goto err;
+ /* streaming EP: set stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+ if (ret)
+ goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
OK, after patching with this one from http://goo.gl/5wtpT there is no
OOPS, but this happened[1][2]:
1. mythtv-setup version: fixes/0.25 [v0.25.2-3-gf0e2ad8-dirty]:
…
E DVBChan(1:/dev/dvb/adapter0/frontend0): Getting Frontend
uncorrected block count failed.
eno: Operation not supported (95)
2012-09-01 17:08:20.577044 W DVBSM(/dev/dvb/adapter0/frontend0): Cannot
count Uncorrected Blocks
eno: Operation not supported (95)
…
2. tzap/femon:
…
status 1f | signal 2f2f | snr 00f2 |
Re: [PATCH] rtl28xxu: correct usb_clear_halt() usage
On 09/01/2012 06:35 PM, poma wrote:
On 09/01/2012 03:54 PM, Antti Palosaari wrote:
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55 +++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
- int ret;
- u8 buf[2];
- struct dvb_usb_device *d = fe_to_d(fe);
-
- dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
- if (onoff) {
- buf[0] = 0x00;
- buf[1] = 0x00;
- usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
- } else {
- buf[0] = 0x10; /* stall EPA */
- buf[1] = 0x02; /* reset EPA */
- }
-
- ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
- if (ret)
- goto err;
-
- return ret;
-err:
- dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
- return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
- u8 gpio, sys0;
+ u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+ epa_ctl[0] = 0x00; /* clear stall */
+ epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+ epa_ctl[0] = 0x10; /* set stall */
+ epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n, __func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
+ /* streaming EP: stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+ if (ret)
+ goto err;
+
+ if (onoff)
+ usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
goto err;
+ /* streaming EP: clear stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+ if (ret)
+ goto err;
+
+ ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+ if (ret)
+ goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct dvb_usb_device *d,
int onoff)
if (ret)
goto err;
+ /* streaming EP: set stall reset */
+ ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+ if (ret)
+ goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
- .streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
OK, after patching with this one from http://goo.gl/5wtpT there is no
OOPS, but this happened[1][2]:
1. mythtv-setup version: fixes/0.25 [v0.25.2-3-gf0e2ad8-dirty]:
…
E DVBChan(1:/dev/dvb/adapter0/frontend0): Getting Frontend
uncorrected block count failed.
eno: Operation not supported (95)
2012-09-01 17:08:20.577044 W DVBSM(/dev/dvb/adapter0/frontend0): Cannot
count Uncorrected Blocks
eno: Operation not supported (95)
…
Re: Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On 08/12/2012 04:15 AM, Mauro Carvalho Chehab wrote:
Devin/Antti,
As Juergen mentioned your help on this patch, do you mind helping reviewing
and testing it?
Touching on those semaphores can be very tricky, as anything wrong may cause
a driver hangup. So, it is great to have more pair of eyes looking on it.
While I didn't test the code (too busy trying to clean up my long queue -
currently with still 200+ patches left), I did a careful review at the
semaphore code there, and it seems this approach will work.
At least, the first hunk looks perfect for me. The second hunk seems
a little more worrying, as the dvb core might be waiting forever for
a lock on a device that was already removed.
In order to test it in practice, I think we need to remove an USB device
by hand while tuning it, and see if the core will not lock the device
forever.
What do you think?
Mauro
Mensagem original
Assunto: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
Data: Wed, 1 Aug 2012 00:22:16 +0200
De: Juergen Lock n...@jelal.kn-bremen.de
Para: linux-media@vger.kernel.org
CC: hsela...@c2i.net
That likely fxes this MythTV ticket:
http://code.mythtv.org/trac/ticket/10830
(which btw affects all usb tuners I tested as well, pctv452e,
dib0700, af9015) pctv452e is still possibly broken with MythTV
even after this fix; it does work with VDR here tho despite I2C
errors.
Reduced testcase:
http://people.freebsd.org/~nox/tmp/ioctltst.c
Thanx to devinheitmueller and crope from #linuxtv for helping with
this fix! :)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -604,6 +604,7 @@ static int dvb_frontend_thread(void *dat
enum dvbfe_algo algo;
bool re_tune = false;
+ bool semheld = false;
dprintk(%s\n, __func__);
@@ -627,6 +628,8 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
+ if (!down_interruptible (fepriv-sem))
+ semheld = true;
fepriv-exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -742,6 +745,8 @@ restart:
fepriv-exit = DVB_FE_NO_EXIT;
mb();
+ if (semheld)
+ up(fepriv-sem);
dvb_frontend_wakeup(fe);
return 0;
}
@@ -1804,16 +1809,20 @@ static int dvb_frontend_ioctl(struct fil
dprintk(%s (%d)\n, __func__, _IOC_NR(cmd));
- if (fepriv-exit != DVB_FE_NO_EXIT)
+ if (down_interruptible (fepriv-sem))
+ return -ERESTARTSYS;
+
+ if (fepriv-exit != DVB_FE_NO_EXIT) {
+ up(fepriv-sem);
return -ENODEV;
+ }
if ((file-f_flags O_ACCMODE) == O_RDONLY
(_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
- cmd == FE_DISEQC_RECV_SLAVE_REPLY))
+ cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
+ up(fepriv-sem);
return -EPERM;
-
- if (down_interruptible (fepriv-sem))
- return -ERESTARTSYS;
+ }
if ((cmd == FE_SET_PROPERTY) || (cmd == FE_GET_PROPERTY))
err = dvb_frontend_ioctl_properties(file, cmd, parg);
--
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
+1
This one resolve annoying mythtv-setup output:
E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0)
eno: No such device (19)
http://www.gossamer-threads.com/lists/mythtv/dev/513410
But, there is a new one!
Just had a little déjà vu :)
Cheers,
poma
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Prabhakar, On Sat, Sep 01, 2012 at 08:23:58PM +0530, Prabhakar Lad wrote: On Sat, Sep 1, 2012 at 7:52 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sakari, On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote: On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote: [snip] For test pattern you meant control to enable/disable it ? There are two approaches I can think of. One is a menu control which can be used to choose the test pattern (or disable it). The control could be standardised but the menu items would have to be hardware-specific since the test patterns themselves are not standardised. Agreed. The test patterns themselves are highly hardware-specific. From personal experience with sensors, most devices implement a small, fixed set of test patterns that can be exposed through a menu control. However, some devices also implement more configurable test patterns. For instance the MT9V032 can generate horizontal, vertical or diagonal test patterns, or a uniform grey test pattern with a user-configurable value. This would then require two controls. two controls I didn't get it ? When we have menu itself with a list of standard patterns why would two controls be required ? Two are not required. A single menu control will do. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On 09/01/2012 06:51 PM, poma wrote:
On 08/12/2012 04:15 AM, Mauro Carvalho Chehab wrote:
Devin/Antti,
As Juergen mentioned your help on this patch, do you mind helping reviewing
and testing it?
Touching on those semaphores can be very tricky, as anything wrong may cause
a driver hangup. So, it is great to have more pair of eyes looking on it.
While I didn't test the code (too busy trying to clean up my long queue -
currently with still 200+ patches left), I did a careful review at the
semaphore code there, and it seems this approach will work.
At least, the first hunk looks perfect for me. The second hunk seems
a little more worrying, as the dvb core might be waiting forever for
a lock on a device that was already removed.
In order to test it in practice, I think we need to remove an USB device
by hand while tuning it, and see if the core will not lock the device
forever.
What do you think?
Mauro
Mensagem original
Assunto: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
Data: Wed, 1 Aug 2012 00:22:16 +0200
De: Juergen Lock n...@jelal.kn-bremen.de
Para: linux-media@vger.kernel.org
CC: hsela...@c2i.net
That likely fxes this MythTV ticket:
http://code.mythtv.org/trac/ticket/10830
(which btw affects all usb tuners I tested as well, pctv452e,
dib0700, af9015) pctv452e is still possibly broken with MythTV
even after this fix; it does work with VDR here tho despite I2C
errors.
Reduced testcase:
http://people.freebsd.org/~nox/tmp/ioctltst.c
Thanx to devinheitmueller and crope from #linuxtv for helping with
this fix! :)
Signed-off-by: Juergen Lock n...@jelal.kn-bremen.de
--- a/drivers/media/dvb/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.c
@@ -604,6 +604,7 @@ static int dvb_frontend_thread(void *dat
enum dvbfe_algo algo;
bool re_tune = false;
+ bool semheld = false;
dprintk(%s\n, __func__);
@@ -627,6 +628,8 @@ restart:
if (kthread_should_stop() || dvb_frontend_is_exiting(fe)) {
/* got signal or quitting */
+ if (!down_interruptible (fepriv-sem))
+ semheld = true;
fepriv-exit = DVB_FE_NORMAL_EXIT;
break;
}
@@ -742,6 +745,8 @@ restart:
fepriv-exit = DVB_FE_NO_EXIT;
mb();
+ if (semheld)
+ up(fepriv-sem);
dvb_frontend_wakeup(fe);
return 0;
}
@@ -1804,16 +1809,20 @@ static int dvb_frontend_ioctl(struct fil
dprintk(%s (%d)\n, __func__, _IOC_NR(cmd));
- if (fepriv-exit != DVB_FE_NO_EXIT)
+ if (down_interruptible (fepriv-sem))
+ return -ERESTARTSYS;
+
+ if (fepriv-exit != DVB_FE_NO_EXIT) {
+ up(fepriv-sem);
return -ENODEV;
+ }
if ((file-f_flags O_ACCMODE) == O_RDONLY
(_IOC_DIR(cmd) != _IOC_READ || cmd == FE_GET_EVENT ||
-cmd == FE_DISEQC_RECV_SLAVE_REPLY))
+cmd == FE_DISEQC_RECV_SLAVE_REPLY)) {
+ up(fepriv-sem);
return -EPERM;
-
- if (down_interruptible (fepriv-sem))
- return -ERESTARTSYS;
+ }
if ((cmd == FE_SET_PROPERTY) || (cmd == FE_GET_PROPERTY))
err = dvb_frontend_ioctl_properties(file, cmd, parg);
--
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
+1
This one resolve annoying mythtv-setup output:
E FE_GET_INFO ioctl failed (/dev/dvb/adapter0/frontend0)
eno: No such device (19)
http://www.gossamer-threads.com/lists/mythtv/dev/513410
But, there is a new one!
Just had a little déjà vu :)
Is there anyone caring to review that carefully?
I am quite out with semaphores (up/down_interruptible) and also frontend
is so complex... I would rather design / write whole dvb-frontend from
the scratch :] (not doing that as no time).
regards
Antti
--
http://palosaari.fi/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On Sat, Sep 1, 2012 at 12:13 PM, Antti Palosaari cr...@iki.fi wrote: Is there anyone caring to review that carefully? I am quite out with semaphores (up/down_interruptible) and also frontend is so complex... I would rather design / write whole dvb-frontend from the scratch :] (not doing that as no time). If you're not willing to take the time to understand why the existing dvb-frontend is so complex, how could you possibly suggest that you could do a better job rewriting it from scratch? :-) Like most things, the devil is in the details. The threading model is complicated not because it was done poorly, but because there are lots of complexity that is not obvious (combined with it having evolved over time to adapt to hardware bugs). It's only when you run it against a half dozen cards with different behavior that you begin to see why certain things were done the way they were. In this case, I think the race condition in question has become more obvious because of more aggressive use of power management for the tuner and demod. Because powering down the frontend now takes actual time (due to i2c), users are now starting to hit the race condition. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fwd: [PATCH, RFC] Fix DVB ioctls failing if frontend open/closed too fast
On 09/01/2012 07:26 PM, Devin Heitmueller wrote: On Sat, Sep 1, 2012 at 12:13 PM, Antti Palosaari cr...@iki.fi wrote: Is there anyone caring to review that carefully? I am quite out with semaphores (up/down_interruptible) and also frontend is so complex... I would rather design / write whole dvb-frontend from the scratch :] (not doing that as no time). If you're not willing to take the time to understand why the existing dvb-frontend is so complex, how could you possibly suggest that you could do a better job rewriting it from scratch? :-) Writing and designing things from the scratch is more motivated that trying to learn this much complex stuff. You surely know I has a kinda understanding with current dvb-frontend but I hate there is so much hacks which makes it even worse. Writing from the scratch means you could get rid of hacks - slowly. See all the module parameters and think twice are those really needed? Also re-initialization stuff and what more. Unfortunately those are allowed at some phase as easy solution and now it is impossible to get rid. Hacks which belongs to individual drivers instead of core. Like most things, the devil is in the details. The threading model is complicated not because it was done poorly, but because there are lots of complexity that is not obvious (combined with it having evolved over time to adapt to hardware bugs). It's only when you run it against a half dozen cards with different behavior that you begin to see why certain things were done the way they were. In this case, I think the race condition in question has become more obvious because of more aggressive use of power management for the tuner and demod. Because powering down the frontend now takes actual time (due to i2c), users are now starting to hit the race condition. Devin regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 2/9] ir-rx51: Handle signals properly
Moi, On Thu, Aug 30, 2012 at 08:54:24PM +0300, Timo Kokkonen wrote: @@ -273,9 +281,18 @@ static ssize_t lirc_rx51_write(struct file *file, const char *buf, /* * Don't return back to the userspace until the transfer has - * finished + * finished. However, we wish to not spend any more than 500ms + * in kernel. No IR code TX should ever take that long. + */ + i = wait_event_timeout(lirc_rx51-wqueue, lirc_rx51-wbuf_index 0, + HZ / 2); Why such an arbitrary timeout? In reality it might not bite the user space in practice ever, but is it (and if so, why) really required in the first place? Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv3 9/9] ir-rx51: Add missing quote mark in Kconfig text
Moi, On Thu, Aug 30, 2012 at 08:54:31PM +0300, Timo Kokkonen wrote: This trivial fix cures the following warning message: drivers/media/rc/Kconfig:275:warning: multi-line strings not supported Signed-off-by: Timo Kokkonen timo.t.kokko...@iki.fi --- drivers/media/rc/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig index 4a68014..1300655 100644 --- a/drivers/media/rc/Kconfig +++ b/drivers/media/rc/Kconfig @@ -272,7 +272,7 @@ config IR_IGUANA be called iguanair. config IR_RX51 - tristate Nokia N900 IR transmitter diode + tristate Nokia N900 IR transmitter diode depends on OMAP_DM_TIMER LIRC ---help--- Say Y or M here if you want to enable support for the IR This should be combined with patch 1. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] davinci: vpfe: Add documentation
Hi Manju,
My apologies for the delayed answer.
On Wed, Aug 22, 2012 at 02:26:50PM +0530, Manjunath Hadli wrote:
On Thursday 16 August 2012 09:53 PM, Sakari Ailus wrote:
On Thu, Aug 09, 2012 at 09:13:52AM +0530, Manjunath Hadli wrote:
On Thursday 02 August 2012 05:37 AM, Sakari Ailus wrote:
Hi Manju,
Thanks for the patch.
Please make sure these patches reach linux-media next time. If they do
not,
it severely limits the number of potential reviewers. I don't know
why, but
the original patch isn't on linux-media even if the list was cc'd.
Dropping linux-kernel from cc.
Manjunath Hadli wrote:
Add documentation on the Davinci VPFE driver. Document the subdevs,
and private IOTCLs the driver implements
Signed-off-by: Manjunath Hadli manjunath.ha...@ti.com
Signed-off-by: Lad, Prabhakar prabhakar@ti.com
---
Documentation/video4linux/davinci-vpfe-mc.txt | 263
+
1 files changed, 263 insertions(+), 0 deletions(-)
create mode 100644 Documentation/video4linux/davinci-vpfe-mc.txt
diff --git a/Documentation/video4linux/davinci-vpfe-mc.txt
b/Documentation/video4linux/davinci-vpfe-mc.txt
new file mode 100644
index 000..968194f
--- /dev/null
+++ b/Documentation/video4linux/davinci-vpfe-mc.txt
@@ -0,0 +1,263 @@
+Davinci Video processing Front End (VPFE) driver
+
+Copyright (C) 2012 Texas Instruments Inc
+
+Contacts: Manjunath Hadli manjunath.ha...@ti.com
+
+Introduction
+
+
+This file documents the Texas Instruments Davinci Video processing
Front End
+(VPFE) driver located under drivers/media/video/davinci. The
original driver
+exists for Davinci VPFE, which is now being changed to Media Controller
+Framework.
+
+Currently the driver has been successfully used on the following
version of Davinci:
+
+DM365/DM368
+
+The driver implements V4L2, Media controller and v4l2_subdev
interfaces.
+Sensor, lens and flash drivers using the v4l2_subdev interface in
the kernel
+are supported.
+
+
+Split to subdevs
+
+
+The Davinic VPFE is split into V4L2 subdevs, each of the blocks
inside the VPFE
+having one subdev to represent it. Each of the subdevs provide a
V4L2 subdev
+interface to userspace.
+
+DAVINCI CCDC
+DAVINCI PREVIEWER
+DAVINCI RESIZER
+DAVINCI AEW
+DAVINCI AF
+
+Each possible link in the VPFE is modeled by a link in the Media
controller
+interface. For an example program see [1].
+
+
+Private IOCTLs
+==
+
+The Davinci Video processing Front End (VPFE) driver supports
standard V4L2
+IOCTLs and controls where possible and practical. Much of the
functions provided
+by the VPFE, however, does not fall under the standard IOCTLs.
+
+In general, there is a private ioctl for configuring each of the blocks
+containing hardware-dependent functions.
+
+The following private IOCTLs are supported:
+
+1: IOCTL: PREV_S_PARAM/PREV_G_PARAM
+Description:
+Sets/Gets the parameters required by the previewer module
+Parameter:
+/**
+ * struct prev_module_param- structure to configure preview modules
+ * @version: Version of the preview module
+ * @len: Length of the module config structure
+ * @module_id: Module id
+ * @param: pointer to module config parameter.
+ */
+struct prev_module_param {
+char version[IMP_MAX_NAME_SIZE];
+unsigned short len;
+unsigned short module_id;
+void *param;
+};
In addition to what Laurent commented on this, could the version
information be passed in struct media_entity_desc instead?
I plan to leave out the version.
As a general comment, it's a bad idea to design an API that allows
passing
blobs, especially when the expected size of the blobs isn't known. That
really equals to asking for trouble.
That said, I know this is an area where complete documentation is acarce,
but I think that at least the memory layout of the current blob pointers
should be visible in the struct definitions whenever possible. See
e.g. the
OMAP 3 ISP driver.
I have proposed using a union of structures instead of the void blob.
I also saw the OMAP implementation, and they are pointers (but not void).
To me the union approach looks better as it keeps the architecture
intact and does not necessitate an
explicit copy_from_user. Which of these ways do you suggest?
I would suggest to use the approach taken in the OMAP 3 ISP driver as it has
one obvious advantage over the union of pointers: it makes it possible to
perform atomic changes to the configuration.
However, changes to configuration done through controls and the private
IOCTL can never be atomic as they're done using a different IOCTL. This is
something that will require some work at the API level in the future.
I'm fine with
Re: [PATCH] [media] davinci: vpfe: Add documentation
On Sat, Sep 01, 2012 at 08:25:30PM +0300, Sakari Ailus wrote: That would be against the V4L2 spec. It's explicitly defined that the source compose rectangle defines the output size of the scaler. This should be sink, not source. -- Sakari Ailus e-mail: sakari.ai...@iki.fi XMPP: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtl28xxu: correct usb_clear_halt() usage
On 09/01/2012 05:48 PM, Antti Palosaari wrote:
On 09/01/2012 06:35 PM, poma wrote:
On 09/01/2012 03:54 PM, Antti Palosaari wrote:
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55
+++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
-int ret;
-u8 buf[2];
-struct dvb_usb_device *d = fe_to_d(fe);
-
-dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
-if (onoff) {
-buf[0] = 0x00;
-buf[1] = 0x00;
-usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
-} else {
-buf[0] = 0x10; /* stall EPA */
-buf[1] = 0x02; /* reset EPA */
-}
-
-ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
-if (ret)
-goto err;
-
-return ret;
-err:
-dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
-return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
-u8 gpio, sys0;
+u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+epa_ctl[0] = 0x00; /* clear stall */
+epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+epa_ctl[0] = 0x10; /* set stall */
+epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n,
__func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+if (ret)
+goto err;
+
+if (onoff)
+usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
goto err;
+/* streaming EP: clear stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+if (ret)
+goto err;
+
+ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+if (ret)
+goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: set stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+if (ret)
+goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
OK, after patching with this one from http://goo.gl/5wtpT there is no
OOPS, but this happened[1][2]:
1. mythtv-setup version: fixes/0.25 [v0.25.2-3-gf0e2ad8-dirty]:
…
E DVBChan(1:/dev/dvb/adapter0/frontend0): Getting Frontend
uncorrected block count failed.
eno: Operation not supported (95)
2012-09-01 17:08:20.577044 W DVBSM(/dev/dvb/adapter0/frontend0): Cannot
count Uncorrected Blocks
eno: Operation not supported (95)
…
2. tzap/femon:
…
status 1f | signal 2f2f | snr 00f2 | ber 001e | unc 0033 |
FE_HAS_LOCK
status 1f | signal 2f2f | snr 00f3 | ber 000b | unc 0033 |
FE_HAS_LOCK
status
[PATCH] [media] mceusb: Optimize DIV_ROUND_CLOSEST call
DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
cron job: media_tree daily build: WARNINGS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Sat Sep 1 19:00:19 CEST 2012 git hash:79e8c7bebb467bbc3f2514d75bba669a3f354324 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: WARNINGS linux-git-arm-eabi-exynos: OK linux-git-arm-eabi-omap: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: WARNINGS linux-3.6-rc2-x86_64: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: WARNINGS linux-3.6-rc2-i686: WARNINGS apps: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] rtl28xxu: correct usb_clear_halt() usage
On 09/01/2012 07:37 PM, poma wrote:
On 09/01/2012 05:48 PM, Antti Palosaari wrote:
On 09/01/2012 06:35 PM, poma wrote:
On 09/01/2012 03:54 PM, Antti Palosaari wrote:
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55
+++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
-int ret;
-u8 buf[2];
-struct dvb_usb_device *d = fe_to_d(fe);
-
-dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
-if (onoff) {
-buf[0] = 0x00;
-buf[1] = 0x00;
-usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
-} else {
-buf[0] = 0x10; /* stall EPA */
-buf[1] = 0x02; /* reset EPA */
-}
-
-ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
-if (ret)
-goto err;
-
-return ret;
-err:
-dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
-return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
-u8 gpio, sys0;
+u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+epa_ctl[0] = 0x00; /* clear stall */
+epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+epa_ctl[0] = 0x10; /* set stall */
+epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n,
__func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+if (ret)
+goto err;
+
+if (onoff)
+usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
goto err;
+/* streaming EP: clear stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+if (ret)
+goto err;
+
+ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+if (ret)
+goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: set stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+if (ret)
+goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
OK, after patching with this one from http://goo.gl/5wtpT there is no
OOPS, but this happened[1][2]:
1. mythtv-setup version: fixes/0.25 [v0.25.2-3-gf0e2ad8-dirty]:
…
E DVBChan(1:/dev/dvb/adapter0/frontend0): Getting Frontend
uncorrected block count failed.
eno: Operation not supported (95)
2012-09-01 17:08:20.577044 W DVBSM(/dev/dvb/adapter0/frontend0): Cannot
count Uncorrected Blocks
eno: Operation not supported (95)
…
2. tzap/femon:
…
status 1f | signal 2f2f | snr 00f2 | ber 001e | unc 0033 |
FE_HAS_LOCK
status 1f | signal 2f2f | snr 00f3 | ber 000b |
Re: [PATCH] rtl28xxu: correct usb_clear_halt() usage
On 09/02/2012 01:58 AM, poma wrote:
On 09/01/2012 07:37 PM, poma wrote:
On 09/01/2012 05:48 PM, Antti Palosaari wrote:
On 09/01/2012 06:35 PM, poma wrote:
On 09/01/2012 03:54 PM, Antti Palosaari wrote:
It is not allowed to call usb_clear_halt() after urbs are submitted.
That causes oops sometimes. Move whole streaming_ctrl() logic to
power_ctrl() in order to avoid wrong usb_clear_halt() use. Also,
configuring streaming endpoint in streaming_ctrl() sounds like a
little bit wrong as it is aimed for control stream gate.
Reported-by: Hin-Tak Leung ht...@users.sourceforge.net
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 55
+++--
1 file changed, 25 insertions(+), 30 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index e29fca2..7d11c5d 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -825,37 +825,10 @@ err:
return ret;
}
-static int rtl28xxu_streaming_ctrl(struct dvb_frontend *fe , int onoff)
-{
-int ret;
-u8 buf[2];
-struct dvb_usb_device *d = fe_to_d(fe);
-
-dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
-
-if (onoff) {
-buf[0] = 0x00;
-buf[1] = 0x00;
-usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
-} else {
-buf[0] = 0x10; /* stall EPA */
-buf[1] = 0x02; /* reset EPA */
-}
-
-ret = rtl28xx_wr_regs(d, USB_EPA_CTL, buf, 2);
-if (ret)
-goto err;
-
-return ret;
-err:
-dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
-return ret;
-}
-
static int rtl2831u_power_ctrl(struct dvb_usb_device *d, int onoff)
{
int ret;
-u8 gpio, sys0;
+u8 gpio, sys0, epa_ctl[2];
dev_dbg(d-udev-dev, %s: onoff=%d\n, __func__, onoff);
@@ -878,11 +851,15 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
gpio |= 0x04; /* GPIO2 = 1, LED on */
sys0 = sys0 0x0f;
sys0 |= 0xe0;
+epa_ctl[0] = 0x00; /* clear stall */
+epa_ctl[1] = 0x00; /* clear reset */
} else {
gpio = (~0x01); /* GPIO0 = 0 */
gpio |= 0x10; /* GPIO4 = 1 */
gpio = (~0x04); /* GPIO2 = 1, LED off */
sys0 = sys0 (~0xc0);
+epa_ctl[0] = 0x10; /* set stall */
+epa_ctl[1] = 0x02; /* set reset */
}
dev_dbg(d-udev-dev, %s: WR SYS0=%02x GPIO_OUT_VAL=%02x\n,
__func__,
@@ -898,6 +875,14 @@ static int rtl2831u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, epa_ctl, 2);
+if (ret)
+goto err;
+
+if (onoff)
+usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+
return ret;
err:
dev_dbg(d-udev-dev, %s: failed=%d\n, __func__, ret);
@@ -972,6 +957,14 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
goto err;
+/* streaming EP: clear stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x00\x00, 2);
+if (ret)
+goto err;
+
+ret = usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x81));
+if (ret)
+goto err;
} else {
/* demod_ctl_1 */
ret = rtl28xx_rd_reg(d, SYS_DEMOD_CTL1, val);
@@ -1006,6 +999,10 @@ static int rtl2832u_power_ctrl(struct
dvb_usb_device *d, int onoff)
if (ret)
goto err;
+/* streaming EP: set stall reset */
+ret = rtl28xx_wr_regs(d, USB_EPA_CTL, \x10\x02, 2);
+if (ret)
+goto err;
}
return ret;
@@ -1182,7 +1179,6 @@ static const struct dvb_usb_device_properties
rtl2831u_props = {
.tuner_attach = rtl2831u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2831u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
@@ -1204,7 +1200,6 @@ static const struct dvb_usb_device_properties
rtl2832u_props = {
.tuner_attach = rtl2832u_tuner_attach,
.init = rtl28xxu_init,
.get_rc_config = rtl2832u_get_rc_config,
-.streaming_ctrl = rtl28xxu_streaming_ctrl,
.num_adapters = 1,
.adapter = {
OK, after patching with this one from http://goo.gl/5wtpT there is no
OOPS, but this happened[1][2]:
1. mythtv-setup version: fixes/0.25 [v0.25.2-3-gf0e2ad8-dirty]:
…
E DVBChan(1:/dev/dvb/adapter0/frontend0): Getting Frontend
uncorrected block count failed.
eno: Operation not supported (95)
2012-09-01 17:08:20.577044 W DVBSM(/dev/dvb/adapter0/frontend0): Cannot
count Uncorrected Blocks
eno: Operation not supported (95)
…
2. tzap/femon:
…
status 1f | signal 2f2f | snr 00f2 | ber 001e | unc 0033 |
FE_HAS_LOCK
status 1f | signal 2f2f | snr 00f3 | ber 000b | unc 0033 |
FE_HAS_LOCK
status 1f | signal 2f2f | snr
[PATCH 1/2] Elonics E4000 silicon tuner driver
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/tuners/Kconfig | 7 +
drivers/media/tuners/Makefile | 1 +
drivers/media/tuners/e4000.c | 408 ++
drivers/media/tuners/e4000.h | 52 +
drivers/media/tuners/e4000_priv.h | 147 ++
5 files changed, 615 insertions(+)
create mode 100644 drivers/media/tuners/e4000.c
create mode 100644 drivers/media/tuners/e4000.h
create mode 100644 drivers/media/tuners/e4000_priv.h
diff --git a/drivers/media/tuners/Kconfig b/drivers/media/tuners/Kconfig
index 80238b9..f9e299c 100644
--- a/drivers/media/tuners/Kconfig
+++ b/drivers/media/tuners/Kconfig
@@ -222,6 +222,13 @@ config MEDIA_TUNER_TDA18212
help
NXP TDA18212 silicon tuner driver.
+config MEDIA_TUNER_E4000
+ tristate Elonics E4000 silicon tuner
+ depends on MEDIA_SUPPORT I2C
+ default m if !MEDIA_SUBDRV_AUTOSELECT
+ help
+ Elonics E4000 silicon tuner driver.
+
config MEDIA_TUNER_TUA9001
tristate Infineon TUA 9001 silicon tuner
depends on MEDIA_SUPPORT I2C
diff --git a/drivers/media/tuners/Makefile b/drivers/media/tuners/Makefile
index 112aeee..9f7b2c2 100644
--- a/drivers/media/tuners/Makefile
+++ b/drivers/media/tuners/Makefile
@@ -28,6 +28,7 @@ obj-$(CONFIG_MEDIA_TUNER_MC44S803) += mc44s803.o
obj-$(CONFIG_MEDIA_TUNER_MAX2165) += max2165.o
obj-$(CONFIG_MEDIA_TUNER_TDA18218) += tda18218.o
obj-$(CONFIG_MEDIA_TUNER_TDA18212) += tda18212.o
+obj-$(CONFIG_MEDIA_TUNER_E4000) += e4000.o
obj-$(CONFIG_MEDIA_TUNER_TUA9001) += tua9001.o
obj-$(CONFIG_MEDIA_TUNER_FC0011) += fc0011.o
obj-$(CONFIG_MEDIA_TUNER_FC0012) += fc0012.o
diff --git a/drivers/media/tuners/e4000.c b/drivers/media/tuners/e4000.c
new file mode 100644
index 000..ffaa482
--- /dev/null
+++ b/drivers/media/tuners/e4000.c
@@ -0,0 +1,408 @@
+/*
+ * Elonics E4000 silicon tuner driver
+ *
+ * Copyright (C) 2012 Antti Palosaari cr...@iki.fi
+ *
+ *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 program is distributed in the hope that it will be useful,
+ *but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ *GNU General Public License for more details.
+ *
+ *You should have received a copy of the GNU General Public License along
+ *with this program; if not, write to the Free Software Foundation, Inc.,
+ *51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
+ */
+
+#include e4000_priv.h
+
+/* write multiple registers */
+static int e4000_wr_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[1 + len];
+ struct i2c_msg msg[1] = {
+ {
+ .addr = priv-cfg-i2c_addr,
+ .flags = 0,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ buf[0] = reg;
+ memcpy(buf[1], val, len);
+
+ ret = i2c_transfer(priv-i2c, msg, 1);
+ if (ret == 1) {
+ ret = 0;
+ } else {
+ dev_warn(priv-i2c-dev, %s: i2c wr failed=%d reg=%02x \
+ len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ ret = -EREMOTEIO;
+ }
+ return ret;
+}
+
+/* read multiple registers */
+static int e4000_rd_regs(struct e4000_priv *priv, u8 reg, u8 *val, int len)
+{
+ int ret;
+ u8 buf[len];
+ struct i2c_msg msg[2] = {
+ {
+ .addr = priv-cfg-i2c_addr,
+ .flags = 0,
+ .len = 1,
+ .buf = reg,
+ }, {
+ .addr = priv-cfg-i2c_addr,
+ .flags = I2C_M_RD,
+ .len = sizeof(buf),
+ .buf = buf,
+ }
+ };
+
+ ret = i2c_transfer(priv-i2c, msg, 2);
+ if (ret == 2) {
+ memcpy(val, buf, len);
+ ret = 0;
+ } else {
+ dev_warn(priv-i2c-dev, %s: i2c rd failed=%d reg=%02x \
+ len=%d\n, KBUILD_MODNAME, ret, reg, len);
+ ret = -EREMOTEIO;
+ }
+
+ return ret;
+}
+
+/* write single register */
+static int e4000_wr_reg(struct e4000_priv *priv, u8 reg, u8 val)
+{
+ return e4000_wr_regs(priv, reg, val, 1);
+}
+
+/* read single register */
+static int e4000_rd_reg(struct e4000_priv *priv, u8 reg, u8 *val)
+{
+ return e4000_rd_regs(priv, reg, val, 1);
+}
+
+static int e4000_init(struct dvb_frontend *fe)
+{
+ struct e4000_priv *priv = fe-tuner_priv;
+ int ret;
+
+ dev_dbg(priv-i2c-dev, %s:\n, __func__);
+
+
[PATCH 2/2] rtl28xxu: add support for Elonics E4000 tuner
Signed-off-by: Antti Palosaari cr...@iki.fi
---
drivers/media/usb/dvb-usb-v2/Kconfig| 1 +
drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 17 +++--
2 files changed, 16 insertions(+), 2 deletions(-)
diff --git a/drivers/media/usb/dvb-usb-v2/Kconfig
b/drivers/media/usb/dvb-usb-v2/Kconfig
index 9671151..329d222 100644
--- a/drivers/media/usb/dvb-usb-v2/Kconfig
+++ b/drivers/media/usb/dvb-usb-v2/Kconfig
@@ -141,6 +141,7 @@ config DVB_USB_RTL28XXU
select MEDIA_TUNER_MXL5005S if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_FC0012 if MEDIA_SUBDRV_AUTOSELECT
select MEDIA_TUNER_FC0013 if MEDIA_SUBDRV_AUTOSELECT
+ select MEDIA_TUNER_E4000 if MEDIA_SUBDRV_AUTOSELECT
help
Say Y here to support the Realtek RTL28xxU DVB USB receiver.
diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 7d11c5d..88b5ea1 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -30,6 +30,7 @@
#include mxl5005s.h
#include fc0012.h
#include fc0013.h
+#include e4000.h
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
@@ -625,10 +626,11 @@ static int rtl2832u_frontend_attach(struct
dvb_usb_adapter *adap)
ret = rtl28xxu_ctrl_msg(d, req_e4000);
if (ret == 0 buf[0] == 0x40) {
priv-tuner = TUNER_RTL2832_E4000;
- /* TODO implement tuner */
+ /* FIXME: do not abuse fc0012 settings */
+ rtl2832_config = rtl28xxu_rtl2832_fc0012_config;
dev_info(d-udev-dev, %s: E4000 tuner found,
KBUILD_MODNAME);
- goto unsupported;
+ goto found;
}
/* check TDA18272 ID register; reg=00 val=c760 */
@@ -746,6 +748,11 @@ err:
return ret;
}
+static const struct e4000_config rtl2832u_e4000_config = {
+ .i2c_addr = 0x64,
+ .clock = 2880,
+};
+
static int rtl2832u_tuner_attach(struct dvb_usb_adapter *adap)
{
int ret;
@@ -774,6 +781,10 @@ static int rtl2832u_tuner_attach(struct dvb_usb_adapter
*adap)
adap-fe[0]-ops.read_signal_strength =
adap-fe[0]-ops.tuner_ops.get_rf_strength;
return 0;
+ case TUNER_RTL2832_E4000:
+ fe = dvb_attach(e4000_attach, adap-fe[0], d-i2c_adap,
+ rtl2832u_e4000_config);
+ break;
default:
fe = NULL;
dev_err(d-udev-dev, %s: unknown tuner=%d\n, KBUILD_MODNAME,
@@ -1223,6 +1234,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, G-Tek Electronics Group Lifeview LV5TDLX
DVB-T, NULL) },
{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_NOXON_DAB_STICK,
rtl2832u_props, NOXON DAB/DAB+ USB dongle, NULL) },
+ { DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
+ rtl2832u_props, Realtek RTL2832U reference design, NULL) },
{ }
};
MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);
--
1.7.11.4
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] davinci: vpfe: Add documentation
On Saturday 01 September 2012 19:11:56 Sakari Ailus wrote: Hi Prabhakar, On Sat, Sep 01, 2012 at 08:23:58PM +0530, Prabhakar Lad wrote: On Sat, Sep 1, 2012 at 7:52 PM, Laurent Pinchart laurent.pinch...@ideasonboard.com wrote: Hi Sakari, On Saturday 01 September 2012 12:57:07 Sakari Ailus wrote: On Wed, Aug 29, 2012 at 08:11:50PM +0530, Prabhakar Lad wrote: [snip] For test pattern you meant control to enable/disable it ? There are two approaches I can think of. One is a menu control which can be used to choose the test pattern (or disable it). The control could be standardised but the menu items would have to be hardware-specific since the test patterns themselves are not standardised. Agreed. The test patterns themselves are highly hardware-specific. From personal experience with sensors, most devices implement a small, fixed set of test patterns that can be exposed through a menu control. However, some devices also implement more configurable test patterns. For instance the MT9V032 can generate horizontal, vertical or diagonal test patterns, or a uniform grey test pattern with a user-configurable value. This would then require two controls. two controls I didn't get it ? When we have menu itself with a list of standard patterns why would two controls be required ? Two are not required. A single menu control will do. That's correct, in this case a single menu control will do. We would only need multiple controls if the device exposes test pattern parameters, as in the MT9V032 sensor example. -- Regards, Laurent Pinchart -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] [media] mceusb: Optimize DIV_ROUND_CLOSEST call
On Sat, Sep 01, 2012 at 08:53:57PM +0200, Jean Delvare wrote: DIV_ROUND_CLOSEST is faster if the compiler knows it will only be dealing with unsigned dividends. Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Andrew Morton a...@linux-foundation.org Cc: Guenter Roeck li...@roeck-us.net Cc: Mauro Carvalho Chehab mche...@infradead.org Tested-by: Guenter Roeck li...@roeck-us.net --- drivers/media/rc/mceusb.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-3.6-rc3.orig/drivers/media/rc/mceusb.c 2012-08-04 21:49:27.0 +0200 +++ linux-3.6-rc3/drivers/media/rc/mceusb.c 2012-09-01 18:53:32.053042123 +0200 @@ -627,7 +627,7 @@ static void mceusb_dev_printdata(struct break; case MCE_RSP_EQIRCFS: period = DIV_ROUND_CLOSEST( - (1 data1 * 2) * (data2 + 1), 10); + (1U data1 * 2) * (data2 + 1), 10); if (!period) break; carrier = (1000 * 1000) / period; -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
