Re: [PATCH 09/10] MCDE: Add build files and bus
On Sat, Dec 04, 2010 at 04:34:22PM -0500, Alex Deucher wrote: This doesn't seem that different from the graphics chips we support with kms. I don't think it would require much work to use KMS. One thing we considered, but never ended up implementing was a generic overlay API for KMS. Most PC hardware still has overlays, but we don't use them much any more on the desktop side. It may be worthwhile to design an appropriate API for them for these type of hardware. Just fyi about a generic overlay api: I've looked a bit into this when doing the intel overlay support and I think adding special overlay crtcs that can be attached real crtcs gives a nice clean api. We could the reuse the existing framebuffer/pageflipping api to get the buffers to the overlay engine. The real pain starts when we want format discovery from userspace with all the alignement/size/layout constrains. Add in tiling support and its almost impossible to do in a generic way. But also for kms userspace needs to know these constrains (implemented for generic use in libkms). I favor such an approach for overlays, too (if it ever happens) - i.e. a few helpers in libkms that allocate an appropriate buffer for a given format and size and returns the buffer, strides and offsets for the different planes. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] add Technisat skystar usb plus USB-ID
this device is a rebranded Technotrend s-2400 with USB id 0x3009. THx to Carsten Wehmeier for reporting Signed-off-by: Halim Sahin halim.sa...@freenet.de --- drivers/media/dvb/dvb-usb/dvb-usb-ids.h |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h index 192a40c..380066b 100644 --- a/drivers/media/dvb/dvb-usb/dvb-usb-ids.h +++ b/drivers/media/dvb/dvb-usb/dvb-usb-ids.h @@ -204,6 +204,7 @@ #define USB_PID_AVERMEDIA_A805 0xa805 #define USB_PID_AVERMEDIA_A815M0x815a #define USB_PID_TECHNOTREND_CONNECT_S2400 0x3006 +#define USB_PID_TECHNOTREND_CONNECT_S2400 0x3009 #define USB_PID_TECHNOTREND_CONNECT_CT3650 0x300d #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY 0x005a #define USB_PID_TERRATEC_CINERGY_DT_XS_DIVERSITY_2 0x0081 -- 1.7.2.2 -- 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
SatelliteHD GOTVIEW USB2.0 DVB-S2
Hi any news about Linux drivers for this card ? http://www.gotview.ru/v2/news-satellitehd.html Goga -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
On Sunday 05 December 2010 17:20:05 Igor M. Liplianin wrote:
В сообщении от 21 ноября 2010 01:51:36 автор Alexey Chernov написал:
Hello,
Hello Alexey,
Hello Igor,
thank you very much for reviewing the patch and your suggestions. I've fixed
everything you've mentioned:
I've added support of GoTView PCI-E X5 3D Hybrid to cx23885 module
(thanks to help of Gotview support team). Some details:
1. Everything initialize properly except radio.
2. All analog inputs (TV, composite, S-Video) are tested by myself in
several TV norms (SECAM-D, PAL, NTSC), everything work fine. DVB isn't
tested properly due to absense of DVB signal.
So the patch adds general support/detection of the card with working
analog part and hopefully working (untested) DVB part. I hope it will be
useful.
Signed-off-by: Alexey Chernov 4er...@gmail.com
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c v4l-
dvb/drivers/media/video/cx23885/cx23885-cards.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c
2010-11-20
22:24:11.0 +0300
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-cards.c 2010-11-21
02:09:54.0 +0300
@@ -309,6 +309,24 @@ struct cx23885_board cx23885_boards[] =
CX25840_COMPONENT_ON,
} },
},
+ [CX23885_BOARD_GOTVIEW_X5_3D_HYBRID] = {
+ .name = GoTView X5 3D Hybrid,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x64,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_DVB,
+ .input = {{
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_VIN2_CH1 | CX25840_VIN5_CH2,
+ .gpio0 = 0x02,
+ }, {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX23885_VMUX_COMPOSITE1,
+ }, {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
CX25840_SVIDEO_CHROMA4,
+ } },
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -496,6 +514,10 @@ struct cx23885_subid cx23885_subids[] =
.subvendor = 0x107d,
.subdevice = 0x6f22,
.card = CX23885_BOARD_LEADTEK_WINFAST_PXTV1200,
+ }, {
+ .subvendor = 0x5654,
+ .subdevice = 0x2390,
+ .card = CX23885_BOARD_GOTVIEW_X5_3D_HYBRID,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -712,6 +734,10 @@ int cx23885_tuner_callback(void *priv, i
else if (port-nr == 2)
bitmask = 0x04;
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ /* Tuner Reset Command */
+ bitmask = 0x02;
+ break;
}
if (bitmask) {
@@ -1218,6 +1244,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
default:
ts2-gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
@@ -1245,6 +1272,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_bus[2].i2c_adap,
NULL, cx25840, 0x88 1, NULL);
Только в v4l-dvb/drivers/media/video/cx23885: cx23885-cards.c~
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c v4l-
dvb/drivers/media/video/cx23885/cx23885-dvb.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c 2010-11-20
22:24:11.0 +0300
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-dvb.c 2010-11-21
02:09:54.0 +0300
@@ -460,6 +460,10 @@ static struct xc5000_config mygica_x8506
.if_khz = 5380,
};
+static struct zl10353_config gotview_x5_3d_hybrid_zl10353_config = {
+ .demod_address = 0x0F,
Why is this not lower case?
Fixed it.
+};
+
static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *param)
{
@@ -484,6 +488,9 @@ static int cx23885_dvb_set_frontend(stru
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ cx23885_gpio_set(dev,
Re: tm6000 and IR
Hi Em 02-12-2010 02:41, Dmitri Belimov escreveu: Hi Stefan Am 29.11.2010 09:44, schrieb Dmitri Belimov: Hi I try add IR for our TV cards. After my some changes IR is working. But when I remove USB stick from USB port What has you change? 1. Add vendor-specific init code for IR. 2. Add vendor-specific key filter for IR. 3. Add some code for show IR activity via power led 4. Move TV card defines to header file. work it also with TM6010_REQ07_RD8_IR_WAKEUP_SEL = 0xff and TM6010_REQ07_RD8_IR_WAKEUP_ADD = 0xff? It works I think, this both values are setting the remote control address mask and so. And it is not good if we set individual remote controls (better one setting for all). The TV card must be controled only from own IR remotes not from other. One for all may be with additional setting like other ir_table. Too much IR remotes usually in one home much devices can do some tasks without key filter when you pressed a key. Yes, but users should be allowed to replace the IR tables, in order to do some advance usage. Hardcoding the IR address at the driver is a bad practice. I never tried to play with IR on tm5600/6000, but is there a way for it to output the command+address code? The tm6010 return only two bytes when key pressed. high byte is IR vendor id, low byte is key code. saa7134 with our IR decoder returned 4 bytes - 2 bytes is IR vendor id, 1 byte is key code and control byte. I don't know about common IR remotes how many bytes it sended. For switch tm6000 to other ir_table need know vendor id byte and new ir_table. Or describe full value from remotes in ir_table and add logic for use only one piece of this for filtering. If not, then we'll probably need to add some logic to allow users to change the address. Has it received keys? Yes. I received keys, and can control any programm via lirc Which protocol you it? Our remotes has NEC protocol. Damn, has you values for rc5 protocols, any idea? IR_LEADER_CNT1 set 'b0xxx for RC5 IR_LEADER_CNT0 'b This value depend from clock frequency and pulse period. I found this value for RC5 and IR_PULSE_CNT clock frequency 12MHz, pulse period 1.78ms 1.78 * 12000 = 16'h21360 clock frequency 30MHz, pulse period 1.78ms 1.78 * 3 = 16'h53400 clock frequency 12MHz, pulse period 1.72ms 1.72 * 12000 = 16'h20640 Try this value. As I wrote that I haven't the right value for rc5 protocol, and nec protocol works, that I have tested. IR over int works well. But I found two main problems: 1. crash after remove has you test it with lastest git branch (for_v2.6.38)? I used git checkout -b media-master linuxtv/staging/v.2.6.37 but when kernel builded I get linux-image-2.6.35 Wrong branch. The latest development branch is staging/for_v2.6.38. Thank you. When I switched to this branch modules is not crash when USB removed. But disable IR over interrupt after start video/radio With my best regards, Dmitry. 2. disable IR after start video/radio. Try solve this problem right now. sorry, I don't understand that. See dmesg with my comments after modprobe tm6000 [ 150.009123] usb 1-1: link qh0-00ff/f4fa0b00 start 0 [1/0 us] [ 150.070012] Registered IR keymap rc-behold-columbus [ 150.070160] input: tm5600/60x0 IR (tm6000 #0) as /class/input/input5 [ 150.070217] rc0: tm5600/60x0 IR (tm6000 #0) as /class/rc/rc0 [ 150.227066] usbcore: registered new interface driver tm6000 [ 151.063914] tm6000: open called (dev=video0) press some keys [ 168.703849] tm6000_ir_urb_received start [ 168.703855] int_in ir urb received 08 86 08 86 [ 169.586424] tm6000_ir_urb_received start [ 169.586431] int_in ir urb received 04 86 04 86 [ 170.009832] tm6000_ir_urb_received start [ 170.009838] int_in ir urb received 04 86 04 86 [ 170.344236] tm6000_ir_urb_received start [ 170.344242] int_in ir urb received 01 86 01 86 [ 170.711642] tm6000_ir_urb_received start [ 170.711649] int_in ir urb received 02 86 02 86 [ 171.082425] tm6000_ir_urb_received start [ 171.082429] int_in ir urb received 00 86 00 86 start watch a TV [ 214.446038] tm6000: open called (dev=video0) [ 216.265019] xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... [ 216.267055] xc5000: firmware read 12401 bytes. [ 216.267057] xc5000: firmware uploading... [ 222.942009] xc5000: firmware upload complete... try press a key [ 224.137976] tm6000_ir_urb_received start [ 224.137981] not ready [ 224.138014] usb 1-1: unlink qh0-00ff/f4fa0b00 start 0 [1/0 us] [ 224.138177] usb 1-1: link qh0-00ff/f4fa0b00 start 0 [1/0 us] [ 224.138458] usb 1-1: unlink qh0-00ff/f4fa0b00 start 0 [1/0 us] [ 224.139225] tm6000_ir_urb_received start [ 224.139225] not ready IR over int die here [ 224.139225] ehci_hcd :00:1d.7: shutdown urb f4ee58c0 ep3in-intr [ 224.155239]
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
So the patch adds general support/detection of the card with working analog part and hopefully working (untested) DVB part. I hope it will be useful. Excellent, another card profile. Thanks Alexey! Hmm, we generally don't add code to the kernel that hasn't been tested. For this reason I need to nak your patch. Either have someone test the code and report success to this mailing list or consider removing the untested code. Regards, - Steve -- Steven Toth - 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: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
В сообщении от 5 декабря 2010 17:07:05 автор Alexey Chernov написал:
On Sunday 05 December 2010 17:20:05 Igor M. Liplianin wrote:
В сообщении от 21 ноября 2010 01:51:36 автор Alexey Chernov написал:
Hello,
Hello Alexey,
Hello Igor,
thank you very much for reviewing the patch and your suggestions. I've
fixed
everything you've mentioned:
I've added support of GoTView PCI-E X5 3D Hybrid to cx23885 module
(thanks to help of Gotview support team). Some details:
1. Everything initialize properly except radio.
2. All analog inputs (TV, composite, S-Video) are tested by myself in
several TV norms (SECAM-D, PAL, NTSC), everything work fine. DVB isn't
tested properly due to absense of DVB signal.
So the patch adds general support/detection of the card with working
analog part and hopefully working (untested) DVB part. I hope it will
be useful.
Signed-off-by: Alexey Chernov 4er...@gmail.com
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c
v4l- dvb/drivers/media/video/cx23885/cx23885-cards.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-cards.c
2010-11-20
22:24:11.0 +0300
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-cards.c 2010-11-21
02:09:54.0 +0300
@@ -309,6 +309,24 @@ struct cx23885_board cx23885_boards[] =
CX25840_COMPONENT_ON,
} },
},
+ [CX23885_BOARD_GOTVIEW_X5_3D_HYBRID] = {
+ .name = GoTView X5 3D Hybrid,
+ .tuner_type = TUNER_XC5000,
+ .tuner_addr = 0x64,
+ .porta = CX23885_ANALOG_VIDEO,
+ .portb = CX23885_MPEG_DVB,
+ .input = {{
+ .type = CX23885_VMUX_TELEVISION,
+ .vmux = CX25840_VIN2_CH1 | CX25840_VIN5_CH2,
+ .gpio0 = 0x02,
+ }, {
+ .type = CX23885_VMUX_COMPOSITE1,
+ .vmux = CX23885_VMUX_COMPOSITE1,
+ }, {
+ .type = CX23885_VMUX_SVIDEO,
+ .vmux = CX25840_SVIDEO_LUMA3 |
CX25840_SVIDEO_CHROMA4,
+ } },
+ },
};
const unsigned int cx23885_bcount = ARRAY_SIZE(cx23885_boards);
@@ -496,6 +514,10 @@ struct cx23885_subid cx23885_subids[] =
.subvendor = 0x107d,
.subdevice = 0x6f22,
.card = CX23885_BOARD_LEADTEK_WINFAST_PXTV1200,
+ }, {
+ .subvendor = 0x5654,
+ .subdevice = 0x2390,
+ .card = CX23885_BOARD_GOTVIEW_X5_3D_HYBRID,
},
};
const unsigned int cx23885_idcount = ARRAY_SIZE(cx23885_subids);
@@ -712,6 +734,10 @@ int cx23885_tuner_callback(void *priv, i
else if (port-nr == 2)
bitmask = 0x04;
break;
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
+ /* Tuner Reset Command */
+ bitmask = 0x02;
+ break;
}
if (bitmask) {
@@ -1218,6 +1244,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_HAUPPAUGE_HVR1850:
case CX23885_BOARD_COMPRO_VIDEOMATE_E800:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
default:
ts2-gen_ctrl_val = 0xc; /* Serial bus + punctured clock */
ts2-ts_clk_en_val = 0x1; /* Enable TS_CLK */
@@ -1245,6 +1272,7 @@ void cx23885_card_setup(struct cx23885_d
case CX23885_BOARD_MAGICPRO_PROHDTVE2:
case CX23885_BOARD_HAUPPAUGE_HVR1290:
case CX23885_BOARD_LEADTEK_WINFAST_PXTV1200:
+ case CX23885_BOARD_GOTVIEW_X5_3D_HYBRID:
dev-sd_cx25840 = v4l2_i2c_new_subdev(dev-v4l2_dev,
dev-i2c_bus[2].i2c_adap,
NULL, cx25840, 0x88 1, NULL);
Только в v4l-dvb/drivers/media/video/cx23885: cx23885-cards.c~
diff -uprB v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c v4l-
dvb/drivers/media/video/cx23885/cx23885-dvb.c
--- v4l-dvb.orig/drivers/media/video/cx23885/cx23885-dvb.c
2010-11-20
22:24:11.0 +0300
+++ v4l-dvb/drivers/media/video/cx23885/cx23885-dvb.c 2010-11-21
02:09:54.0 +0300
@@ -460,6 +460,10 @@ static struct xc5000_config mygica_x8506
.if_khz = 5380,
};
+static struct zl10353_config gotview_x5_3d_hybrid_zl10353_config = {
+ .demod_address = 0x0F,
Why is this not lower case?
Fixed it.
+};
+
static int cx23885_dvb_set_frontend(struct dvb_frontend *fe,
struct dvb_frontend_parameters *param)
{
@@ -484,6 +488,9 @@ static int cx23885_dvb_set_frontend(stru
/* Select Digital TV */
cx23885_gpio_set(dev, GPIO_0);
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
Hello, Steve, thank you very much for your comments! As for DVB maybe I'm not correct. The initialization itself, which the DVB part of patch is about, is fully tested by me and works successfully on my everyday PC. The thing I meant saying 'untested' concerned receiving DVB signal through the initialized device. So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. On Sunday 05 December 2010 18:51:13 Steven Toth wrote: So the patch adds general support/detection of the card with working analog part and hopefully working (untested) DVB part. I hope it will be useful. Excellent, another card profile. Thanks Alexey! Hmm, we generally don't add code to the kernel that hasn't been tested. For this reason I need to nak your patch. Either have someone test the code and report success to this mailing list or consider removing the untested code. Regards, - Steve -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Has the DVB related change proven that it enables digital TV streaming? -- Steven Toth - 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: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote: Hello, Steve, thank you very much for your comments! As for DVB maybe I'm not correct. The initialization itself, which the DVB part of patch is about, is fully tested by me and works successfully on my everyday PC. The thing I meant saying 'untested' concerned receiving DVB signal through the initialized device. So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Hello Alexey, What I believe Steven is trying to say is the device successfully initializing is not enough to consider the DVB part of the driver to be working. If you have not seen the device receiving digital television, the DVB parts of this patch should not be committed. There are a variety of other reasons why DVB streaming would not work even if the device properly initializes. These can include an improperly configured IF, wrong GPIOs, missing power management code, etc. It is far worse for a user to be led to believe the driver should be working but doesn't then it is for the driver claim to not work with DVB at all. This is how we end up with users wasting hours wondering what is wrong with their MythTV setup when in fact the driver never actually worked in the first place. Find someone to test the DVB parts of the board that it shows DVB streaming. If you cannot do that, remove those parts from the patch until someone can be found who is able to test the functionality. 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
[PATCH 0/2] OMAP1: amsdelta: reserve memory for videobuf_contig
Latest developements seem to allow for reserving a block of memory on boot to be used as a device dedicated dma coherent memory. This may be required for videobuf_config based video drivers avoid problems with allocating dma coherent memory after system memory gets fragmented. This set extends the OMAP1 camera resource initialization code with a function that can be used for reserving a block of memory early, then declared as the camera device dedicated dma coherent memory. An example use case is provided for Amstrad Delta camera. arch/arm/mach-omap1/board-ams-delta.c | 12 +- arch/arm/mach-omap1/devices.c | 36 ++ arch/arm/mach-omap1/include/mach/camera.h |1 3 files changed, 48 insertions(+), 1 deletion(-) Thanks, Janusz -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[cron job] v4l-dvb daily build: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Dec 5 19:00:05 CET 2010 git master: 59365d136d205cc20fe666ca7f89b1c5001b0d5a git media-master: gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.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
[PATCH 1/2] OMAP1: allow reserving memory for camera
OMAP1 camera driver, when starting up in its videobuf_contig mode, may have
problems with allocating dma coherent memory after system memory gets
fragmented if there is no dedicated memory declared as a dma coherent memory
block associated with the device. To solve this issue, allow for removing a
block of memory from system memory early on boot, then, if reserved this way,
declare it as the device dedicated dma coherent memory.
An example use case on Amstrad Delta will be provided with patch 2/2.
Created and tested against linux-2.6.37-rc4.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/devices.c | 36 ++
arch/arm/mach-omap1/include/mach/camera.h |1
2 files changed, 37 insertions(+)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c.orig 2010-12-04
18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/devices.c 2010-12-04
22:22:13.0 +0100
@@ -16,6 +16,7 @@
#include linux/platform_device.h
#include linux/io.h
#include linux/spi/spi.h
+#include linux/memblock.h
#include mach/hardware.h
#include asm/mach/map.h
@@ -222,13 +223,48 @@ static struct platform_device omap1_came
.resource = omap1_camera_resources,
};
+static phys_addr_t omap1_camera_phys_mempool_base;
+static phys_addr_t omap1_camera_phys_mempool_size;
+
+void __init omap1_camera_reserve(phys_addr_t size)
+{
+ phys_addr_t paddr;
+
+ if (!size)
+ return;
+
+ paddr = memblock_alloc(size, SZ_1M);
+
+ if (!paddr) {
+ pr_err(%s: failed to reserve %x bytes\n, __func__, size);
+ return;
+ }
+ memblock_free(paddr, size);
+ memblock_remove(paddr, size);
+
+ omap1_camera_phys_mempool_base = paddr;
+ omap1_camera_phys_mempool_size = size;
+}
+
void __init omap1_camera_init(void *info)
{
struct platform_device *dev = omap1_camera_device;
+ dma_addr_t paddr = omap1_camera_phys_mempool_base;
+ dma_addr_t size = omap1_camera_phys_mempool_size;
int ret;
dev-dev.platform_data = info;
+ if (paddr) {
+ if (dma_declare_coherent_memory(dev-dev, paddr, paddr, size,
+ DMA_MEMORY_MAP | DMA_MEMORY_EXCLUSIVE))
+ pr_info(%s: reserved %d bytes camera buffer memory\n,
+ __func__, size);
+ else
+ pr_warn(%s: cannot reserve camera buffer memory\n,
+ __func__);
+ }
+
ret = platform_device_register(dev);
if (ret)
dev_err(dev-dev, unable to register device: %d\n, ret);
--- linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h.orig
2010-12-04 18:00:39.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/include/mach/camera.h 2010-12-04
22:26:23.0 +0100
@@ -3,6 +3,7 @@
#include media/omap1_camera.h
+void omap1_camera_reserve(phys_addr_t);
void omap1_camera_init(void *);
static inline void omap1_set_camera_info(struct omap1_cam_platform_data *info)
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/2] OMAP1: Amstrad Delta: reserve memory for camera
Patch 1/2 from this set provides a possibility to reserve a block of memory
for use as the OMAP1 camera dedicated dma coherent memory. Use this
functionality to avoid the camera driver switching form videobuf_contig mode
to less efficient videobuf_sg mode in case of dma coherent memory allocation
failure after system memory gets fragmented.
Created and tested against linux-2.6.27-rc4 on top of patch 1/2.
Signed-off-by: Janusz Krzysztofik jkrzy...@tis.icnet.pl
---
arch/arm/mach-omap1/board-ams-delta.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
--- linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c.orig 2010-12-04
18:05:25.0 +0100
+++ linux-2.6.37-rc4/arch/arm/mach-omap1/board-ams-delta.c 2010-12-04
22:19:39.0 +0100
@@ -262,6 +262,16 @@ static struct omap1_cam_platform_data am
.lclk_khz_max = 1334, /* results in 5fps CIF, 10fps QCIF */
};
+void __init amsdelta_reserve(void)
+{
+#if defined(CONFIG_VIDEO_OMAP1) || defined(CONFIG_VIDEO_OMAP1_MODULE)
+ omap1_camera_reserve(PAGE_SIZE get_order(352 * 288 * 2 *
+ OMAP1_CAMERA_MIN_BUF_COUNT(OMAP1_CAM_DMA_CONTIG)));
+#endif
+
+ omap_reserve();
+}
+
static struct platform_device *ams_delta_devices[] __initdata = {
ams_delta_kp_device,
ams_delta_lcd_device,
@@ -366,7 +376,7 @@ MACHINE_START(AMS_DELTA, Amstrad E3 (De
/* Maintainer: Jonathan McDowell nood...@earth.li */
.boot_params= 0x1100,
.map_io = ams_delta_map_io,
- .reserve= omap_reserve,
+ .reserve= amsdelta_reserve,
.init_irq = ams_delta_init_irq,
.init_machine = ams_delta_init,
.timer = omap_timer,
--
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 for stable 2.6.36 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Mauro Carvalho Chehab mche...@redhat.com
Cc: sta...@kernel.org
---
drivers/media/video/cx25840/cx25840-core.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c
index f5a3e74..b9a2f18 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1991,8 +1991,23 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_new_std(state-hdl, cx25840_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
if (!is_cx2583x(state)) {
- default_volume = 228 - cx25840_read(client, 0x8d4);
- default_volume = ((default_volume / 2) + 23) 9;
+ default_volume = cx25840_read(client, 0x8d4);
+ /*
+* Enforce the legacy PVR-350/MSP3400 to PVR-150/CX25843 volume
+* scale mapping limits to avoid -ERANGE errors when
+* initializing the volume control
+*/
+ if (default_volume 228) {
+ /* Bottom out at -96 dB, v4l2 vol range 0x2e00-0x2fff */
+ default_volume = 228;
+ cx25840_write(client, 0x8d4, 228);
+ }
+ else if (default_volume 20) {
+ /* Top out at + 8 dB, v4l2 vol range 0xfe00-0x */
+ default_volume = 20;
+ cx25840_write(client, 0x8d4, 20);
+ }
+ default_volume = (((228 - default_volume) 1) + 23) 9;
state-volume = v4l2_ctrl_new_std(state-hdl,
cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
2010/12/5 Steven Toth st...@kernellabs.com: So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Has the DVB related change proven that it enables digital TV streaming? Yes, it enables digital TV streaming (tested using GStreamer dvbsrc element on adapter created for this card). -- Steven Toth - 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: [PATCH] support of GoTView PCI-E X5 3D Hybrid in cx23885
Hello, Devin, 2010/12/5 Devin Heitmueller dheitmuel...@kernellabs.com: On Sun, Dec 5, 2010 at 12:09 PM, Alexey Chernov 4er...@gmail.com wrote: Hello, Steve, thank you very much for your comments! As for DVB maybe I'm not correct. The initialization itself, which the DVB part of patch is about, is fully tested by me and works successfully on my everyday PC. The thing I meant saying 'untested' concerned receiving DVB signal through the initialized device. So I think I was mistaken that the code itself is untested. I hope it's possible to add full of this patch. Hello Alexey, What I believe Steven is trying to say is the device successfully initializing is not enough to consider the DVB part of the driver to be working. If you have not seen the device receiving digital television, the DVB parts of this patch should not be committed. There are a variety of other reasons why DVB streaming would not work even if the device properly initializes. These can include an improperly configured IF, wrong GPIOs, missing power management code, etc. It is far worse for a user to be led to believe the driver should be working but doesn't then it is for the driver claim to not work with DVB at all. This is how we end up with users wasting hours wondering what is wrong with their MythTV setup when in fact the driver never actually worked in the first place. Thank you for additional description. I agree with you that successful DVB initialization and my tests doesn't necessarily guarantee its full proper work. But I can't see any reasons why the code can't be included. I think not including this code harms far more. I see a lot of people using binary distros on Gotview forum at least which would like to test Linux drivers for their cards. They could test them in wide variety of different circumstances. But they are normal users and they don't want even to hear about any patches and kernel builds. If DVB works in their distro's kernel maybe someone would test it on real signal. If it is not even initialized, nobody would test it. Not even saying about big efforts which took me this DVB part of patch (I should say, most part of the time spent on this patch). Find someone to test the DVB parts of the board that it shows DVB streaming. If you cannot do that, remove those parts from the patch until someone can be found who is able to test the functionality. Surely I tried to find someone to test the DVB parts but DVB-T is not spread so wide here in Russia where Gotview cards seem to be primarily sold and I wasn't able to find anybody. Gotview support team was also unable to help me with this problem. So, is it impossible now to accept the patch in its current state? 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: tm6000 and IR
Am 05.12.2010 17:09, schrieb Dmitri Belimov: Hi Em 02-12-2010 02:41, Dmitri Belimov escreveu: Hi Stefan Am 29.11.2010 09:44, schrieb Dmitri Belimov: Hi I try add IR for our TV cards. After my some changes IR is working. But when I remove USB stick from USB port What has you change? 1. Add vendor-specific init code for IR. 2. Add vendor-specific key filter for IR. 3. Add some code for show IR activity via power led 4. Move TV card defines to header file. work it also with TM6010_REQ07_RD8_IR_WAKEUP_SEL = 0xff and TM6010_REQ07_RD8_IR_WAKEUP_ADD = 0xff? It works I think, this both values are setting the remote control address mask and so. And it is not good if we set individual remote controls (better one setting for all). The TV card must be controled only from own IR remotes not from other. One for all may be with additional setting like other ir_table. Too much IR remotes usually in one home much devices can do some tasks without key filter when you pressed a key. Yes, but users should be allowed to replace the IR tables, in order to do some advance usage. Hardcoding the IR address at the driver is a bad practice. I never tried to play with IR on tm5600/6000, but is there a way for it to output the command+address code? The tm6010 return only two bytes when key pressed. high byte is IR vendor id, low byte is key code. saa7134 with our IR decoder returned 4 bytes - 2 bytes is IR vendor id, 1 byte is key code and control byte. I don't know about common IR remotes how many bytes it sended. IR vendor ? nether rc5 nor nec protocol has this terminus . It has address and command. for extended protocol double length. For switch tm6000 to other ir_table need know vendor id byte and new ir_table. Or describe full value from remotes in ir_table and add logic for use only one piece of this for filtering. If not, then we'll probably need to add some logic to allow users to change the address. Has it received keys? Yes. I received keys, and can control any programm via lirc Which protocol you it? Our remotes has NEC protocol. Damn, has you values for rc5 protocols, any idea? IR_LEADER_CNT1 set 'b0xxx for RC5 IR_LEADER_CNT0 'b This value depend from clock frequency and pulse period. I found this value for RC5 and IR_PULSE_CNT clock frequency 12MHz, pulse period 1.78ms 1.78 * 12000 = 16'h21360 clock frequency 30MHz, pulse period 1.78ms 1.78 * 3 = 16'h53400 clock frequency 12MHz, pulse period 1.72ms 1.72 * 12000 = 16'h20640 Try this value. As I wrote that I haven't the right value for rc5 protocol, and nec protocol works, that I have tested. IR over int works well. But I found two main problems: 1. crash after remove has you test it with lastest git branch (for_v2.6.38)? I used git checkout -b media-master linuxtv/staging/v.2.6.37 but when kernel builded I get linux-image-2.6.35 Wrong branch. The latest development branch is staging/for_v2.6.38. Thank you. When I switched to this branch modules is not crash when USB removed. But disable IR over interrupt after start video/radio With my best regards, Dmitry. changing the interface configuration by initiation isoc urb can deactivating the interrupt in endpoint here the different configurations interfacealtsettingendpointfifo 00isoc0 byte 00bulk512bytes 00interrupt0 byte 01isoc3x1024 bytes 01bulk512 bytes 01interrupt4 bytes 02isoc0 byte 02bulk512 bytes 02interrupt4 bytes 03isoc3x1024 bytes 03bulk512 bytes 03interrupt0 byte 2. disable IR after start video/radio. Try solve this problem right now. sorry, I don't understand that. See dmesg with my comments after modprobe tm6000 [ 150.009123] usb 1-1: link qh0-00ff/f4fa0b00 start 0 [1/0 us] [ 150.070012] Registered IR keymap rc-behold-columbus [ 150.070160] input: tm5600/60x0 IR (tm6000 #0) as /class/input/input5 [ 150.070217] rc0: tm5600/60x0 IR (tm6000 #0) as /class/rc/rc0 [ 150.227066] usbcore: registered new interface driver tm6000 [ 151.063914] tm6000: open called (dev=video0) press some keys [ 168.703849] tm6000_ir_urb_received start [ 168.703855] int_in ir urb received 08 86 08 86 [ 169.586424] tm6000_ir_urb_received start [ 169.586431] int_in ir urb received 04 86 04 86 [ 170.009832] tm6000_ir_urb_received start [ 170.009838] int_in ir urb received 04 86 04 86 [ 170.344236] tm6000_ir_urb_received start [ 170.344242] int_in ir urb
[PATCH for 2.6.37 REGRESSION] cx25840: Prevent device probe failure due to volume control ERANGE error
This patch was created and tested against linux-next
( git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git ),
tag next-20101203, and fixes a regression that crept into 2.6.36.
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls awa...@md.metrocast.net
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
drivers/media/video/cx25840/cx25840-core.c | 19 +--
1 files changed, 17 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/cx25840/cx25840-core.c
b/drivers/media/video/cx25840/cx25840-core.c
index dfb198d..f164618 100644
--- a/drivers/media/video/cx25840/cx25840-core.c
+++ b/drivers/media/video/cx25840/cx25840-core.c
@@ -1989,8 +1989,23 @@ static int cx25840_probe(struct i2c_client *client,
v4l2_ctrl_new_std(state-hdl, cx25840_ctrl_ops,
V4L2_CID_HUE, -128, 127, 1, 0);
if (!is_cx2583x(state)) {
- default_volume = 228 - cx25840_read(client, 0x8d4);
- default_volume = ((default_volume / 2) + 23) 9;
+ default_volume = cx25840_read(client, 0x8d4);
+ /*
+* Enforce the legacy PVR-350/MSP3400 to PVR-150/CX25843 volume
+* scale mapping limits to avoid -ERANGE errors when
+* initializing the volume control
+*/
+ if (default_volume 228) {
+ /* Bottom out at -96 dB, v4l2 vol range 0x2e00-0x2fff */
+ default_volume = 228;
+ cx25840_write(client, 0x8d4, 228);
+ }
+ else if (default_volume 20) {
+ /* Top out at + 8 dB, v4l2 vol range 0xfe00-0x */
+ default_volume = 20;
+ cx25840_write(client, 0x8d4, 20);
+ }
+ default_volume = (((228 - default_volume) 1) + 23) 9;
state-volume = v4l2_ctrl_new_std(state-hdl,
cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
--
1.7.2.3
--
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: PCI: make pci_restore_state return void
On Tue, 2010-11-30 at 17:43 -0600, Jon Mason wrote: pci_restore_state only ever returns 0, thus there is no benefit in having it return any value. Also, a large majority of the callers do not check the return code of pci_restore_state. Make the pci_restore_state a void return and avoid the overhead. It does kind of make me nervous that (basically) no one ever checks the return code from the PCI config space accessors, even though in theory they can fail. This code being but one example. /end random comment :) cheers signature.asc Description: This is a digitally signed message part
Issue with firewire from 2.6.35.9 to 2.6.36.1
Hello, I recently upgraded from 26.35.9 to 2.6.36.1 and now the /dev/fwX devices are not being created. I have udev 164 installed. 2.6.35.9 dmesg firewire lines... firewire_ohci :07:00.0: PCI INT A - GSI 44 (level, low) - IRQ 44 firewire_ohci :07:00.0: setting latency timer to 64 firewire_ohci: Added fw-ohci device :07:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x1 firewire_core: created device fw0: GUID 0010dc0001adc862, S400 firewire_core: created device fw1: GUID 00808803072803a5, S100 firewire_core: phy config: card 0, new root=ffc1, gap_count=5 2.6.36.1 dmesg firewire lines... firewire_ohci :07:00.0: PCI INT A - GSI 44 (level, low) - IRQ 44 firewire_ohci :07:00.0: setting latency timer to 64 firewire_ohci :07:00.0: irq 75 for MSI/MSI-X firewire_ohci: Added fw-ohci device :07:00.0, OHCI v1.10, 4 IR + 8 IT contexts, quirks 0x1 I have compared the difference between the two kernel configs and the only differences that I see that may apply to the firewire are: CONFIG_DNOTIFY=y -CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y # CONFIG_IEEE1394 is not set +CONFIG_FIREWIRE_NOSY=m CONFIG_I2O=m On the ieee1394 wiki page it says that these kernel option are expected to be on for the libraw1394: CONFIG_INOTIFY=y CONFIG_INOTIFY_USER=y CONFIG_EPOLL=y These option are correct in the 2.6.35.9 kernel but the CONFIG_INOTIFY option is missing completely in the 2.6.36.1 kernel. Is this a change in how the firewire works in the kernel and that udev needs to be modified or is there something else wrong? signature.asc Description: This is a digitally signed message part
Re: [GIT PATCHES for 2.6.38] broken cx25840 probe and CX2388[578] IR receive timeoouts
On Sun, 2010-11-28 at 20:06 -0500, Andy Walls wrote: Mauro, Please pull the following changes for 2.6.38. Hi Mauro, Please disregard this PULL request. I have sent the cx25840 fix as a patch to the list for both 2.6.36 (stable) and 2.6.37. Regards, Andy The cx25840 module has a bad bug in its probe function which causes device probing to fail. It can completely break cx23885 IR and analog video and ivtv and pvrusb2 analog video. (Can you checrry pick the cx25840-core.c commit for 2.6.37 as well? commit 18688563aa635993cf31edc6a985a8a6736044f7 cx25840: Prevent device probe failure due to volume control ERANGE error) Regards, Andy The following changes since commit a287789447cecc7a82ffc4451cbaf16a5c1dccc0: [media] [FOR, 2.6.37] Revert V4L/DVB: v4l2-dev: remove unnecessary lock around atomic clear_bit (2010-11-26 18:41:02 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git ir-38 Andy Walls (2): cx25840: Prevent device probe failure due to volume control ERANGE error cx23885, cx25840: Provide an IR Rx timeout event reports to the rc decoders drivers/media/video/cx23885/cx23888-ir.c | 12 drivers/media/video/cx25840/cx25840-core.c | 19 +-- drivers/media/video/cx25840/cx25840-ir.c | 12 3 files changed, 33 insertions(+), 10 deletions(-) ___ ivtv-devel mailing list ivtv-de...@ivtvdriver.org http://ivtvdriver.org/mailman/listinfo/ivtv-devel -- 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 for 2.6.37] cx23885, cx25840: Provide IR Rx timeout event reports
Provide CX2388[578] IR receive timeout (RTO) reports in the
final space raw event sent up the chain to the raw IR pulse
decoders. This should allow the lirc decoder to actually
measure the inter-transmission gap properly.
Signed-off-by: Andy Walls awa...@md.metrocast.net
---
drivers/media/video/cx23885/cx23888-ir.c | 12
drivers/media/video/cx25840/cx25840-ir.c | 12
2 files changed, 16 insertions(+), 8 deletions(-)
diff --git a/drivers/media/video/cx23885/cx23888-ir.c
b/drivers/media/video/cx23885/cx23888-ir.c
index e37be6f..bb1ce34 100644
--- a/drivers/media/video/cx23885/cx23888-ir.c
+++ b/drivers/media/video/cx23885/cx23888-ir.c
@@ -673,7 +673,7 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
unsigned int i, n;
union cx23888_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
n = count / sizeof(union cx23888_ir_fifo_rec)
* sizeof(union cx23888_ir_fifo_rec);
@@ -692,11 +692,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if ((p-hw_fifo_data FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_888_debug, sd, rx read: end of rx\n);
+ w = 1;
} else {
u = (p-hw_fifo_data FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -707,9 +708,12 @@ static int cx23888_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(p-ir_core_data);
p-ir_core_data.pulse = u;
p-ir_core_data.duration = v;
+ p-ir_core_data.timeout = w;
- v4l2_dbg(2, ir_888_debug, sd, rx read: %10u ns %s\n,
-v, u ? mark : space);
+ v4l2_dbg(2, ir_888_debug, sd, rx read: %10u ns %s %s\n,
+v, u ? mark : space, w ? (timed out) : );
+ if (w)
+ v4l2_dbg(2, ir_888_debug, sd, rx read: end of rx\n);
}
return 0;
}
diff --git a/drivers/media/video/cx25840/cx25840-ir.c
b/drivers/media/video/cx25840/cx25840-ir.c
index 627926f..b210c29 100644
--- a/drivers/media/video/cx25840/cx25840-ir.c
+++ b/drivers/media/video/cx25840/cx25840-ir.c
@@ -668,7 +668,7 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
u16 divider;
unsigned int i, n;
union cx25840_ir_fifo_rec *p;
- unsigned u, v;
+ unsigned u, v, w;
if (ir_state == NULL)
return -ENODEV;
@@ -694,11 +694,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
if ((p-hw_fifo_data FIFO_RXTX_RTO) == FIFO_RXTX_RTO) {
/* Assume RTO was because of no IR light input */
u = 0;
- v4l2_dbg(2, ir_debug, sd, rx read: end of rx\n);
+ w = 1;
} else {
u = (p-hw_fifo_data FIFO_RXTX_LVL) ? 1 : 0;
if (invert)
u = u ? 0 : 1;
+ w = 0;
}
v = (unsigned) pulse_width_count_to_ns(
@@ -709,9 +710,12 @@ static int cx25840_ir_rx_read(struct v4l2_subdev *sd, u8
*buf, size_t count,
init_ir_raw_event(p-ir_core_data);
p-ir_core_data.pulse = u;
p-ir_core_data.duration = v;
+ p-ir_core_data.timeout = w;
- v4l2_dbg(2, ir_debug, sd, rx read: %10u ns %s\n,
-v, u ? mark : space);
+ v4l2_dbg(2, ir_debug, sd, rx read: %10u ns %s %s\n,
+v, u ? mark : space, w ? (timed out) : );
+ if (w)
+ v4l2_dbg(2, ir_debug, sd, rx read: end of rx\n);
}
return 0;
}
--
1.7.2.3
--
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
omap3isp: Getting 8 bit data out of CCDC module?
Hi, from reading the isp/ispccdc.c source, it seems that one currently can only stream 10 bit data from /dev/video2, not 8 bits. a) Is that correct? b) Is it possible at all to get 8 bit output? (so I need to go ahead and implement it?) Note: I have configured the data lane shifter to feed effectively 8 bits into CCDC, but I'd like to get rid of the interleaved zero-bytes coming out of it. Thank you, Stefan. -- 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 7/7] v4l: videobuf2: add CMA allocator
Pawel Osciak wrote:
-Original Message-
From: Pawel Osciak [mailto:pa...@osciak.com]
Sent: Sunday, December 05, 2010 7:47 AM
To: Marek Szyprowski; Jonghun Han
Cc: linux-media@vger.kernel.org; kyungmin.p...@samsung.com
Subject: Re: [PATCH 7/7] v4l: videobuf2: add CMA allocator
Hi,
please see my comments below.
Also, if I could suggest something, please cut the code between
functions, not inside them, it'll make it easier for others to find
that location in the original code.
On Wed, Dec 1, 2010 at 00:56, Marek Szyprowski m.szyprow...@samsung.com
wrote:
Hello,
On Wednesday, December 01, 2010 9:36 AM Jonghun Han wrote:
Marek Szyprowski wrote:
2010/11/20 Marek Szyprowski m.szyprow...@samsung.com:
From: Pawel Osciak p.osc...@samsung.com
Add support for the CMA contiguous memory allocator to videobuf2.
Signed-off-by: Pawel Osciak p.osc...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
Signed-off-by: Marek Szyprowski m.szyprow...@samsung.com
CC: Pawel Osciak pa...@osciak.com
---
Hi Marek,
snip
+static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size)
static void *vb2_cma_get_userptr(unsigned long vaddr, unsigned long
size,
const struct
vb2_alloc_ctx
*alloc_ctx)
alloc_ctx can be useful for many cases.
Yes, right, I will add it in the next version.
Actually, I don't think so. Can you give an example of one of those
many cases? There is no need to add unused arguments that can be
useful in future just for the sake of future extensions, especially
not in the kernel in such sensitive code. This function can
potentially be called on each frame. And even more importantly, the
whole allocator interface has been designed so that functions will not
have to be vb2- or media-specific. Ideally, we should be able to hook
up functions from mm and other modules. And such functions either use
only vaddr and size, or have means of finding their contexts
otherwise.
If I remember correctly, this approach was actually suggested by
Laurent and it makes a lot of sense. We want to be able to use third
party kernel functions in allocators as much as possbile.
Hi,
What I mentioned many cases is related in VCMM(Virtual Contiguous Memory
Manager).
http://www.linuxsymposium.org/2010/view_abstract.php?content_key=64
When IOMMU(SYS.MMU) is used for device, each device uses its own device
virtual address
not a physical address or virtual address. VCMM device id is needed to get
the device virtual address.
But in vb2_cma_get_userptr we cannot find the VCMM device id.
If vb2_alloc_ctx is added as argument in vb2_cma_get_userptr and VCMM device
id is set
in vb2_cma_conf on vb2_cma_init, we can find VCMM device id in
vb2_cma_get_userptr.
+{
+ struct vb2_cma_buf *buf;
+ unsigned long paddr = 0;
+ int ret;
+
+ buf = kzalloc(sizeof *buf, GFP_KERNEL);
+ if (!buf)
+ return ERR_PTR(-ENOMEM);
+
+ buf-vma = vb2_get_userptr(vaddr);
vb2_get_vma looks good instead of vb2_get_userptr.
How do you think about this ?
Right, this will make the code easier to understand. Thanks for the
hint!
Actually, I don't think it's a good idea. I think you have the whole
concept backwards.
vb2 doesn't care what is returned from this function. All it wants is
a cookie from this allocator. From the point of view where this
function is used, it is get_userptr not get_vma, vb2 wants to get
something describing a user pointer, but that does not have to mean a
vma. Moreover, in any case, the core does not care at all what it is
it is getting, since it *never uses it*. Changing the name of this
function would actually make it confusing.
In other words: this function is an implementation of
get_userptr_private_allocator_cookie allocator interface function
and *not* a get_vma function implementation. It does not have to be
a vma and the core does not care what it is anyway.
What I mentioned is vb2_get_userptr not
vb2_cma_get_userptr(vb2_mem_ops-get_userptr).
vb2_get_userptr is used in vb2_cma_get_userptr to find struct vm_area in
videobuf2-memops.c
Cookie concept is very nice. I absolutely agree with you.
+ if (!buf-vma) {
+ printk(KERN_ERR Failed acquiring VMA for vaddr
0x%08lx\n,
+ vaddr);
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = vb2_contig_verify_userptr(buf-vma, vaddr, size,
paddr);
+ if (ret) {
+ vb2_put_userptr(buf-vma);
+ goto done;
+ }
+
In vb2_contig_verify_userptr, vma is re-found via find_vma although it
has
been checked after vb2_get_userptr.
Why double checking is needed ?
I'm not sure. I must check this core again, maybe it can be simplified a
bit.
I agree, it seems that it
RE: RFC: Problem of using v4l2 spec with codec function
Hi, If MFC(encoder/decoder) has a single node, how to know application's object before VIDIOC_S_FMT calling ? VIDIOC_S_CTRL can be called before VIDIOC_S_FMT. For example user wants to use MFC as an *encoder*, but user calls VIDIOC_S_CTRL with *decoder* command by mistake. In that case driver cannot return fail because it cannot know the purpose before VIDIOC_S_FMT calling. When VIDIOC_S_FMT is called to use MFC as an *encoder* after VIDIOC_S_CTRL, driver will be confused how to handle it. But in two nodes solution decoder command via VIDIOC_S_CTRL will be failed on encoder device node. -- Best regards, Jonghun Han -- -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Pawel Osciak Sent: Sunday, December 05, 2010 7:55 AM To: Kamil Debski Cc: Hans Verkuil; Jonghun Han; Laurent Pinchart; jaeryul...@samsung.com; linux- me...@vger.kernel.org Subject: Re: RFC: Problem of using v4l2 spec with codec function Hi all, I would side with Laurent on this. Judging by formats seems to be enough for this driver and it has great, in my opinion, advantages of a) not overcomplicating things for applications b) not adding new pieces to the API... -- Best regards, Pawel Osciak -- 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
SV:FW: 3--.
Recently, I bought some presents from a commercial site for Christmas, all the products can enjoy a big discount, it is worth visiting: fallinele.com , for the Christmas more one choice. 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
