Re: [PATCH 01/11] mm: page_alloc: set_migratetype_isolate: drain PCP prior to isolating
On Thu, Dec 29, 2011 at 2:39 PM, Marek Szyprowski
wrote:
> From: Michal Nazarewicz
>
> When set_migratetype_isolate() sets pageblock's migrate type, it does
> not change each page_private data. This makes sense, as the function
> has no way of knowing what kind of information page_private stores.
...
>
>
> A side effect is that instead of draining pages from all zones,
> set_migratetype_isolate() now drain only pages from zone pageblock it
> operates on is in.
>
...
>
> +/* Caller must hold zone->lock. */
> +static void __zone_drain_local_pages(void *arg)
> +{
> + struct per_cpu_pages *pcp;
> + struct zone *zone = arg;
> + unsigned long flags;
> +
> + local_irq_save(flags);
> + pcp = &per_cpu_ptr(zone->pageset, smp_processor_id())->pcp;
> + if (pcp->count) {
> + /* Caller holds zone->lock, no need to grab it. */
> + __free_pcppages_bulk(zone, pcp->count, pcp);
> + pcp->count = 0;
> + }
> + local_irq_restore(flags);
> +}
> +
> +/*
> + * Like drain_all_pages() but operates on a single zone. Caller must
> + * hold zone->lock.
> + */
> +static void __zone_drain_all_pages(struct zone *zone)
> +{
> + on_each_cpu(__zone_drain_local_pages, zone, 1);
> +}
> +
Please consider whether sending an IPI to all processors in the system
and interrupting them is appropriate here.
You seem to assume that it is probable that each CPU of the possibly
4,096 (MAXSMP on x86) has a per-cpu page
for the specified zone, otherwise you're just interrupting them out of
doing something useful, or save power idle
for nothing.
While that may or may not be a reasonable assumption for the general
drain_all_pages that drains pcps from
all zones, I feel it is less likely to be the right thing once you
limit the drain to a single zone.
Some background on my attempt to reduce "IPI noise" in the system in
this context is probably useful here as
well: https://lkml.org/lkml/2011/11/22/133
Thanks :-)
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker
gi...@benyossef.com
Israel Cell: +972-52-8260388
US Cell: +1-973-8260388
http://benyossef.com
"Unfortunately, cache misses are an equal opportunity pain provider."
-- Mike Galbraith, LKML
--
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] em28xx: Add Plextor ConvertX PX-AV100U to em28xx-cards.c
This adds support for the Plextor ConvertX PX-AV100U, which uses the
eMPIA EM2820 chip. The device has a device_id of '0x093b, 0xa003'. I
am using the existing EM2820_BOARD_PINNACLE_DVC_90 board profile, as
the Pinnacle Dazzle DVC 90/100/101/107, Kaiser Baas Video to DVD
maker, and Kworld DVD Maker 2 were already mapped to it. Some more
background on the device and my testing can be found at
http://www.donkramer.net/plextor_122710.pdf
Signed-off-by: Don Kramer
---
diff --git a/drivers/media/video/em28xx/em28xx-cards.c b/drivers/media/video/em2
index 6cab22d..b30ea94 100644
--- a/drivers/media/video/em28xx/em28xx-cards.c
+++ b/drivers/media/video/em28xx/em28xx-cards.c
@@ -1270,7 +1270,7 @@ struct em28xx_board em28xx_boards[] = {
},
[EM2820_BOARD_PINNACLE_DVC_90] = {
.name = "Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baa
- "/ Kworld DVD Maker 2",
+ "/ Kworld DVD Maker 2 / Plextor ConvertX PX-AV10
.tuner_type = TUNER_ABSENT, /* capture only board */
.decoder = EM28XX_SAA711X,
.input= { {
@@ -2019,6 +2019,8 @@ struct usb_device_id em28xx_id_table[] = {
.driver_info = EM2880_BOARD_PINNACLE_PCTV_HD_PRO },
{ USB_DEVICE(0x0413, 0x6023),
.driver_info = EM2800_BOARD_LEADTEK_WINFAST_USBII },
+ { USB_DEVICE(0x093b, 0xa003),
+ .driver_info = EM2820_BOARD_PINNACLE_DVC_90 },
{ USB_DEVICE(0x093b, 0xa005),
.driver_info = EM2861_BOARD_PLEXTOR_PX_TV100U },
--
--
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: em28xx: new board id [eb1a:5051]
On Saturday 31 December 2011 01:51:45 Gareth Williams wrote: > On Fri, 2011-12-30 at 15:16 -0800, Reuben Stokes wrote: > > On Friday 30 December 2011 14:27:57 Gareth Williams wrote: > > > On Fri, 2011-12-30 at 05:04 -0800, Reuben Stokes wrote: > > > > On Friday 30 December 2011 02:01:35 you wrote: > > > > > On Thu, 2011-12-29 at 15:13 -0800, Reuben Stokes wrote: > > > > > > Hi, > > > > > > > > > > > > Not nearly as linux-savvy as most of the users here, but I > > > > > > attempted to operate a "Raygo USB Video Recorder" (audio/video > > > > > > capture device). Don't know if my efforts qualify as a "test". > > > > > > > > > > > > > > > > > > Model Number: > > > > > > R12-41373 > > > > > > > > > > > > Display name: > > > > > > USB 2861 Device > > > > > > > > > > > > lsusb: > > > > > > Bus 001 Device 002: ID eb1a:5051 eMPIA Technology, Inc. > > > > > > > > > > > > dmesg: > > > > > > [ 7182.076058] usb 1-1: new high speed USB device using ehci_hcd > > > > > > and address 3 > > > > > > [ 7182.212702] usb 1-1: New USB device found, idVendor=eb1a, > > > > > > idProduct=5051 > > > > > > [ 7182.212714] usb 1-1: New USB device strings: Mfr=0, Product=1, > > > > > > SerialNumber=2 > > > > > > [ 7182.212723] usb 1-1: Product: USB 2861 Device > > > > > > [ 7182.212729] usb 1-1: SerialNumber: 0 > > > > > > > > > > > > System: > > > > > > HP Pavilion dv6910 laptop > > > > > > AMD Turion X2 CPU (64 bit) > > > > > > Mepis 11; 64 bit( based on Debian Squeeze) > > > > > > > > > > > > > > > > > > Tried > > > > > > --- > > > > > > * Installed em28xx drivers using instructions found at linuxtv.org. > > > > > > I note however that this particular vendor/product ID is not > > > > > > validated in the em28xx devices list. > > > > > > * As new drivers do not automatically load, I use command: modprobe > > > > > > em28xx > > > > > >After this "modprobe -l | grep em28xx" yields > > > > > > kernel/drivers/media/video/em28xx/em28xx-alsa.ko > > > > > > kernel/drivers/media/video/em28xx/em28xx.ko > > > > > > kernel/drivers/media/video/em28xx/em28xx-dvb.ko > > > > > > * Device comes with a driver CD for Windows which does work in > > > > > > Windows. > > > > > > > > > > > > End result is the device is not recognized as a capture device > > > > > > option in any software tried including vlc, cheese, guvcview, > > > > > > kdenlive. > > > > > > > > > > > > Any help getting this to work in Linux would be appreciated as it > > > > > > completely sucks in my bloated, memory-hogging, 32-bit Windows > > > > > > Vista. > > > > > > > > > > > > Reuben > > > > > > -- > > > > > > 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 > > > > > > > > > > Reuben, > > > > > > > > > > If you're willing, then open up the device and see what the chips > > > > > within > > > > > are. You believe it's em28xx based, but there may well be additional > > > > > devices in there for audio and video. > > > > > > > > > > Once you've found out what's inside it will be easier to get it > > > > > working. > > > > > It may be as simple as getting the driver to recognise the USB Vendor > > > > > ID > > > > > or it may require much more work. > > > > > > > > > > Regards, > > > > > > > > > > Gareth > > > > > > > > > > -- > > > > > 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 > > > > > > > > > > > > > > > > > > Thank you very much for the response. > > > > > > > > Okay, opening it was easier than first suspected. > > > > > > > > The main (biggest) chip reads with nice big letters and a logo: > > > > eMPIA > > > > EM2860 > > > > P86J3-011 > > > > 201047-01AG > > > > > > > > Less useful information inlcudes: > > > > > > > > A smaller chip on the flip side of the circuit board, in letters > > > > visible only through a magnifying glass, reads: > > > > eMPIA > > > > TECHNOLOGY > > > > EMP202 > > > > T10164 > > > > 1052 > > > > > > > > The circuit board itself is stamped: > > > > PM22860-2GOB > > > > > > > > Again, thank you. > > > > > > > > Reuben > > > Reuben, > > > > > > Was there another chip on there? The EMP202 is an audio chip that can > > > covert analogue audio to digital PCM (and vice versa). The EM2860 sends > > > this digital audio along with digital video over USB. For this to work > > > though, the device will need to convert analogue video to digital and > > > will need another chip to do this. An example would be a SAA7113 from > > > Philips. Have another look and post back here. > > > > > > The two chips you've identified are commonly used in for this type of > > > device and should be easily configurable in the em28xx driver.
[PATCH] [media] saa7134: fix IR handling for HVR-1110
Return the complete RC-5 code, instead of just the 8 least significant
bits.
Reported-by: Dorozel Csaba
Tested-by: Dorozel Csaba
Signed-off-by: Mauro Carvalho Chehab
---
Please, re-test this patch. It is a more detailed version of the
previous one, with a few more documentation, and some cleanups.
drivers/media/video/saa7134/saa7134-input.c | 23 ++-
1 files changed, 14 insertions(+), 9 deletions(-)
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..0e4926a 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -235,22 +235,27 @@ static int get_key_purpletv(struct IR_i2c *ir, u32
*ir_key, u32 *ir_raw)
static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
{
- unsigned char buf[5], cod4, code3, code4;
+ unsigned char buf[5], scancode;
/* poll IR chip */
if (5 != i2c_master_recv(ir->c, buf, 5))
return -EIO;
- cod4= buf[4];
- code4 = (cod4 >> 2);
- code3 = buf[3];
- if (code3 == 0)
- /* no key pressed */
+ /* Check if some key were pressed */
+ if (!(buf[0] & 0x80))
return 0;
- /* return key */
- *ir_key = code4;
- *ir_raw = code4;
+ /*
+* buf[3] & 0x80 is always high.
+* buf[3] & 0x40 is a parity bit. A repeat event is marked
+* by preserving it into two separate readings
+* buf[4] bits 0 and 1, and buf[1] and buf[2] are always
+* zero.
+*/
+ scancode = 0x1fff & ((buf[3] << 8) | (buf[4] >> 2));
+
+ *ir_key = scancode;
+ *ir_raw = scancode;
return 1;
}
--
1.7.8.352.g876a6
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
On 31-12-2011 11:22, Dorozel Csaba wrote: > >> Changing the mask to 0x1fff would work, but this may not be the >> right fix. >> >> the hole idea is that other RC-5 devices could also be used with >> the driver, but if the sub-routine is not doing the right thing, only >> this remote will work. >> >> Could you please try this patch, instead? It is just a debug patch, >> so it won't fix the issue, but it may help us to identify what's >> happening there. >> >> Btw, do you have any other remote controllers producing Philips RC-5 >> codes? If so, could you also test with them and see what happens? > > Haven't got any other remote controllers with Philips RC-5 codes. > > With the 0x1fff mask work. If im pushig the buttons to fast or holding donw > the output look like > this (don't know is it normal): > > ir-keytable -t -d /dev/input/event6 > Testing events. Please, press CTRL-C to abort. > 1325336612.877133: event MSC: scancode = 1e3d > 1325336612.877136: event key down: KEY_POWER2 (0x0164) > 1325336612.877137: event sync > 1325336612.980130: event MSC: scancode = 1e3d > 1325336612.980132: event sync > 1325336613.083136: event MSC: scancode = 1e3d > 1325336613.083138: event sync > 1325336613.186133: event MSC: scancode = 1e3d > 1325336613.186134: event sync > 1325336613.289133: event MSC: scancode = 1e3d > 1325336613.289135: event sync > 1325336613.378155: event key down: KEY_POWER2 (0x0164) > 1325336613.378156: event sync > 1325336613.503153: event key down: KEY_POWER2 (0x0164) > 1325336613.503154: event sync > 1325336613.539111: event key up: KEY_POWER2 (0x0164) > 1325336613.539112: event sync > > With the debug patch dmesg is growing this without any remote activity: > [12672.782150] 0x00 0x00 0x00 0x00 0x00 > [12672.884991] 0x00 0x00 0x00 0x00 0x00 > [12672.987794] 0x00 0x00 0x00 0x00 0x00 > [12673.090632] 0x00 0x00 0x00 0x00 0x00 > [12673.193465] 0x00 0x00 0x00 0x00 0x00 > [12673.296304] 0x00 0x00 0x00 0x00 0x00 > ... > > When pushing fast a button: > [12791.990291] 0x80 0x00 0x00 0xfe 0xf4 > [12792.093123] 0x00 0x00 0x00 0x00 0x00 > [12792.195971] 0x80 0x00 0x00 0xde 0xf4 > [12792.298805] 0x80 0x00 0x00 0xfe 0xf4 > [12792.401632] 0x00 0x00 0x00 0x00 0x00 > [12792.504472] 0x80 0x00 0x00 0xde 0xf4 > [12792.607305] 0x00 0x00 0x00 0x00 0x00 > [12792.710145] 0x80 0x00 0x00 0xfe 0xf4 > [12792.812977] 0x00 0x00 0x00 0x00 0x00 > [12792.915819] 0x00 0x00 0x00 0x00 0x00 > [12793.018650] 0x80 0x00 0x00 0xfe 0xf4 > > When hold down a button: > 12892.986456] 0x80 0x00 0x00 0xde 0xf4 > [12893.089296] 0x80 0x00 0x00 0xde 0xf4 > [12893.192186] 0x80 0x00 0x00 0xde 0xf4 > [12893.295031] 0x80 0x00 0x00 0xde 0xf4 > [12893.397802] 0x80 0x00 0x00 0xde 0xf4 > [12893.500639] 0x80 0x00 0x00 0xde 0xf4 > [12893.603474] 0x80 0x00 0x00 0xde 0xf4 > [12893.706313] 0x80 0x00 0x00 0xde 0xf4 > [12893.809146] 0x00 0x00 0x00 0x00 0x00 > [12893.911985] 0x00 0x00 0x00 0x00 0x00 > [12894.014822] 0x00 0x00 0x00 0x00 0x00 > [12894.118122] 0x80 0x00 0x00 0xde 0xf4 > [12894.220492] 0x80 0x00 0x00 0xde 0xf4 > [12894.325446] 0x80 0x00 0x00 0xde 0xf4 > [12894.428161] 0x80 0x00 0x00 0xde 0xf4 > [12894.530999] 0x80 0x00 0x00 0xde 0xf4 > [12894.633836] 0x80 0x00 0x00 0xde 0xf4 > [12894.736672] 0x80 0x00 0x00 0xde 0xf4 > [12894.839506] 0x80 0x00 0x00 0xde 0xf4 > [12894.942348] 0x00 0x00 0x00 0x00 0x00 > [12895.045178] 0x00 0x00 0x00 0x00 0x00 > [12895.148017] 0x00 0x00 0x00 0x00 0x00 > [12895.250850] 0x00 0x00 0x00 0x00 0x00 OK, so, 0x1fff is the proper mask. bytes 1 and 2 are empty. byte 0 bit 8 is used only to indicate a keypress. It seems that bit 7 of byte 4 is a parity bit: it changes its state every time a new key is pressed. I'll add the patch with a proper documentation at the kernel driver. Thanks for testing and reporting it! Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCHv2 00/94] Only use DVBv5 internally on frontend drivers
On 31-12-2011 13:31, Stefan Richter wrote: > On Dec 30 Mauro Carvalho Chehab wrote: >> Basically, changes all DVB frontend drivers to work directly with >> the DVBv5 structure. > [...] >> Test reports are welcome. > [...] >> [media] firedtv: convert set_fontend to use DVBv5 parameters > [...] >> drivers/media/dvb/firewire/firedtv-avc.c | 95 >> drivers/media/dvb/firewire/firedtv-fe.c | 31 ++ >> drivers/media/dvb/firewire/firedtv.h |4 +- > > I briefly tested git://linuxtv.org/media_tree.gitstaging/for_v3.3 > 7c61d80a9bcf on top of v3.2-rc7 on a FireDTV-T/CI with kaffeine and on a > FireDTV-C/CI with kaffeine and smplayer and didn't notice any runtime problem. Thanks for testing it! > Building fs/compat_ioctl.c failed for me though: > fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to > incomplete type ‘struct dvb_frontend_parameters’ > fs/compat_ioctl.c:1345:1: error: array type has incomplete element type > etc. pp. Yeah, I forgot about the compat stuff ;) The fix is simple: http://git.linuxtv.org/media_tree.git/commit/e97a5d893fdf45c20799b72a1c11dca3b282c89c Basically, one patch at the tree avoids the usage of DVBv3 structs inside the drivers, as this is not supported by the DVB core anymore. The core itself (and compat) will need it, in order to provide DVBv3 compatibility. Regards, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] [media] fs/compat_ioctl: it needs to see the DVBv3 compat stuff
Only the ioctl core should see the DVBv3 compat stuff, as its contents are not available anymore to the drivers. As fs/compat_ioctl also handles DVBv3 ioctl's, it needs those definitions: fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: array type has incomplete element type fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345: error: initializer element is not constant fs/compat_ioctl.c:1345: error: (near initialization for ‘ioctl_pointer[462]’) fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: array type has incomplete element type fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1346: error: initializer element is not constant fs/compat_ioctl.c:1346: error: (near initialization for ‘ioctl_pointer[463]’) fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: array type has incomplete element type fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_event’ fs/compat_ioctl.c:1347: error: initializer element is not constant fs/compat_ioctl.c:1347: error: (near initialization for ‘ioctl_pointer[464]’) Reported-by: Michael Krufky Signed-off-by: Mauro Carvalho Chehab --- fs/compat_ioctl.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/fs/compat_ioctl.c b/fs/compat_ioctl.c index 51352de..32200c2 100644 --- a/fs/compat_ioctl.c +++ b/fs/compat_ioctl.c @@ -105,6 +105,7 @@ #include +#define __DVB_CORE__ #include #include #include -- 1.7.8.352.g876a6 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a mes
Re: [PATCH for 3.2 URGENT] gspca: Fix bulk mode cameras no longer working (regression fix)
On Fri, 30 Dec 2011, Hans de Goede wrote: > Hi, > > On 12/30/2011 11:21 AM, Jean-Francois Moine wrote: > > On Thu, 29 Dec 2011 21:36:42 +0100 > > Hans de Goede wrote: > > > > > The new iso bandwidth calculation code accidentally has broken support > > > for bulk mode cameras. This has broken the following drivers: > > > finepix, jeilinj, ovfx2, ov534, ov534_9, se401, sq905, sq905c, sq930x, > > > stv0680, vicam. > > > > > > Thix patch fixes this. Fix tested with: se401, sq905, sq905c, stv0680& > > > vicam > > > cams. > > > > Hi Hans, > > > > Sorry for I should not be fully awoken yet, but I don't understand the > > problem from your fix. > > > > The patch just sets the altsetting to the highest one for bulk > > transfer. Does this mean that, in this case, the altsetting table > > created by build_ep_tb is wrong and the highest altsetting cannot > > selected? > > Most bulk mode cameras have only one altsetting, altsetting 0, which is > seen as invalid by build_ep_tb, since it is invalid for isoc mode, resulting > in the cameras not working with a: "no transfer endpoint found" error. > > I've opted to fix things by causing build_ep_tb to not be called for > bulk mode cameras at all, since doing bandwidth calculations for > bulk mode makes no sense. bulk transfers get whatever bandwidth is > left on the bus, there is no guarantee that there are 1000 / interval > packets a second like there is with isoc transfers, so the bandwidth > is unknown. Also note that because of this interval is 0 for bulk > endpoints, since it is unused. So calling build_ep_tb for bulk mode > transfers makes no sense. > > WRT just choosing the highest numbered alt setting this is because > some bulk mode cameras (stv0680 based ones) report 2 alt settings > (which makes no sense for bulk mode, but they do it anyways), > with alt setting 0 not listing any endpoints at all, and alt setting > 1 listening the bulk endpoint we want, so by picking the highest alt > setting we end up with picking the one and only alt setting most cameras > have and picking one which actually has the bulk endpoint listed for > weird cases like the stv0680 based ones. > > Note that I'm spending most of my time today on testing the new > bandwidth code with various cameras, I'll send you a patchset > with some more proposed patches today. We should then evaluate > if we want to get those into 3.2 too. I send this one yesterday since > it fixes a large bunch of cameras not working at all and it is a > simple and safe fix IMHO. > > Regards, > > Hans Jean-Francois, Hans, Without addressing finer points, please let me add the following: 1. I figured out what was holding me back from getting 3.2 to work (it was a config error, apparently originating between keyboard and chair). 2. Based upon my testing today, something like this patch is clearly necessary. Namely, I tested a mass storage camera. Without this patch it would not stream. When I applied the patch, it did. Therefore, I hope very much that the problem which occasioned this patch gets fixed. Theodore Kilgore -- 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: ERRORS
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 Dec 31 19:00:23 CET 2011 git hash:53c91373bdd74f7e11d2726046a90b986c1ed650 gcc version: i686-linux-gcc (GCC) 4.6.1 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-armv5-ixp: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: WARNINGS linux-git-powerpc64: OK linux-git-x86_64: WARNINGS linux-2.6.31.12-i686: ERRORS 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-rc1-i686: WARNINGS linux-2.6.31.12-x86_64: ERRORS 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-rc1-x86_64: WARNINGS spec-git: WARNINGS 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 1/9] [media] DVB: dvb_net_init: return -errno on error
Hi
On Sat, December 31, 2011 11:54, Jonathan Nieder wrote:
> dvb_net_init unconditionally returns 0. Callers such as
> videobuf_dvb_register_frontend examine dvbnet->dvbdev instead of the
> return value to tell whether the operation succeeded. If it has been
> set to a valid pointer, success; if it was left equal to NULL,
> failure.
I noticed this when testing the MFE patch set a few years ago
now and as you have seen I tested for NULL elsewhere more as
a reminder than any thing else.
I made no changes either as you can also see since it was beyond
the scope of the MFE patches at the time. I do remember this
and it pops into my mind once in a while and now it can now be
cast aside forever, thanks.
> Alas, there is an edge case where that logic does not work as well:
> when network support has been compiled out (CONFIG_DVB_NET=n), we want
> dvb_net_init and related operations to behave as no-ops and always
> succeed, but there is no appropriate value to which to set dvb->dvbdev
> to indicate this.
I suspect this is the only case where the MFE patches do not
properly check every potential fault with attachment as I cannot
remember any other function being as the NET attachment which
may have actually been a void function when I last visited it
but that's a bit vague and the return 0 suggests not.
> Let dvb_net_init return a meaningful error code, as preparation for
> adapting callers to look at that instead.
>
> The only immediate impact of this patch should be to make the few
> callers that already check for an error code from dvb_net_init behave
> a little more sensibly when it fails.
Cheers, thanks for your efforts.
bye
> Signed-off-by: Jonathan Nieder
> ---
> drivers/media/dvb/dvb-core/dvb_net.c |4 +---
> 1 files changed, 1 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/media/dvb/dvb-core/dvb_net.c
> b/drivers/media/dvb/dvb-core/dvb_net.c
> index 93d9869e0f15..8766ce8c354d 100644
> --- a/drivers/media/dvb/dvb-core/dvb_net.c
> +++ b/drivers/media/dvb/dvb-core/dvb_net.c
> @@ -1510,9 +1510,7 @@ int dvb_net_init (struct dvb_adapter *adap, struct
> dvb_net *dvbnet,
> for (i=0; i dvbnet->state[i] = 0;
>
> - dvb_register_device (adap, &dvbnet->dvbdev, &dvbdev_net,
> + return dvb_register_device(adap, &dvbnet->dvbdev, &dvbdev_net,
>dvbnet, DVB_DEVICE_NET);
> -
> - return 0;
> }
> EXPORT_SYMBOL(dvb_net_init);
--
// /
{:)==={ Darron Broad
\\ \
--
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: [PATCHv2 00/94] Only use DVBv5 internally on frontend drivers
On Dec 30 Mauro Carvalho Chehab wrote: > Basically, changes all DVB frontend drivers to work directly with > the DVBv5 structure. [...] > Test reports are welcome. [...] > [media] firedtv: convert set_fontend to use DVBv5 parameters [...] > drivers/media/dvb/firewire/firedtv-avc.c | 95 > drivers/media/dvb/firewire/firedtv-fe.c | 31 ++ > drivers/media/dvb/firewire/firedtv.h |4 +- I briefly tested git://linuxtv.org/media_tree.gitstaging/for_v3.3 7c61d80a9bcf on top of v3.2-rc7 on a FireDTV-T/CI with kaffeine and on a FireDTV-C/CI with kaffeine and smplayer and didn't notice any runtime problem. Building fs/compat_ioctl.c failed for me though: fs/compat_ioctl.c:1345:1: error: invalid application of ‘sizeof’ to incomplete type ‘struct dvb_frontend_parameters’ fs/compat_ioctl.c:1345:1: error: array type has incomplete element type etc. pp. -- Stefan Richter -=-==-== ==-- = http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/3] v4l: Image source control class
On 12/31/2011 03:42 PM, Sylwester Nawrocki wrote: >> >> +case V4L2_CID_IMAGE_SOURCE_CLASS: return "Image source controls"; >> +case V4L2_CID_IMAGE_SOURCE_VBLANK: return "Vertical blanking"; > > nit: have you considered making it "Blanking, horizontal" Oops, it supposed to be: "Blanking, vertical" >> +case V4L2_CID_IMAGE_SOURCE_HBLANK: return "Horizontal blanking"; > > and "Blanking, vertical" ? and "Blanking, horizontal" :/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/3] v4l: Image source control class
Hi Sakari, thanks for the patch. On 12/14/2011 04:22 PM, Sakari Ailus wrote: > Add image source control class. This control class is intended to contain > low level controls which deal with control of the image capture process --- > the A/D converter in image sensors, for example. > > Signed-off-by: Sakari Ailus > --- > Documentation/DocBook/media/v4l/controls.xml | 101 > > .../DocBook/media/v4l/vidioc-g-ext-ctrls.xml |6 + > drivers/media/video/v4l2-ctrls.c | 10 ++ > include/linux/videodev2.h | 10 ++ > 4 files changed, 127 insertions(+), 0 deletions(-) > > diff --git a/Documentation/DocBook/media/v4l/controls.xml > b/Documentation/DocBook/media/v4l/controls.xml > index 3bc5ee8..69ede83 100644 > --- a/Documentation/DocBook/media/v4l/controls.xml > +++ b/Documentation/DocBook/media/v4l/controls.xml > @@ -3356,6 +3356,107 @@ interface and may change in the future. > > > > + > + > + Image Source Control Reference > + > + > + Experimental > + > + This is an + linkend="experimental">experimental interface and may > + change in the future. > + > + > + > + The Image Source control class is intended for low-level > + control of image source devices such as image sensors. The > + devices feature an analogue to digital converter and a bus > + transmitter to transmit the image data out of the device. > + > + > + > + Image Source Control IDs > + > + > + > + > + > + > + > + > + > + > + ID > + Type > +align="left">Description > + > + > + > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_CLASS > + class > + > + > + The IMAGE_SOURCE class descriptor. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_VBLANK > + integer > + > + > + Vertical blanking. The idle > + preriod after every frame during which no image data is s/preriod/period > + produced. The unit of vertical blanking is a line. Every > + line has length of the image width plus horizontal > + blanking at the pixel clock specified by struct > + v4l2_mbus_framefmt + />. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_HBLANK > + integer > + > + > + Horizontal blanking. The idle > + preriod after every line of image data during which no s/preriod/period > + image data is produced. The unit of horizontal blanking is > + pixels. > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_LINK_FREQ > + integer menu > + > + > + Image source's data bus frequency. > + Together with the media bus pixel code, bus type (clock > + cycles per sample), the data bus frequency defines the > + pixel clock. The > + frame rate can be calculated from the pixel clock, image > + width and height and horizontal and vertical blanking. The > + frame rate control is performed by selecting the desired > + horizontal and vertical blanking. > + > + > + > + spanname="id">V4L2_CID_IMAGE_SOURCE_ANALOGUE_GAIN > + integer > + > + > + Analogue gain is gain affecting > + all colour components in the pixel matrix. The gain > + operation is performed in the analogue domain before A/D > + conversion. > + > + > + > + > + > + > + > + > + > > >8 [1]. http://patchwork.linuxtv.org/patch/8923/ -- Thanks, Sylwester -- 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 3.2 URGENT] gspca: Fix falling back to lower isoc alt settings
The current gspca core code has a regression where it no longer properly falls back to lower alt settings when there is not enough bandwidth. This causes many iso based usb-1 cameras to not work when plugged into a usb2 hub or a sandybridge chipset motherboard! This patch fixes this. Signed-off-by: Hans de Goede Signed-off-by: Mauro Carvalho Chehab --- drivers/media/video/gspca/gspca.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/gspca/gspca.c b/drivers/media/video/gspca/gspca.c index 7fb90ae..c27dc09 100644 --- a/drivers/media/video/gspca/gspca.c +++ b/drivers/media/video/gspca/gspca.c @@ -988,7 +988,7 @@ retry: ret = -EIO; goto out; } - alt = ep_tb[--alt_idx].alt; + gspca_dev->alt = ep_tb[--alt_idx].alt; } } out: -- 1.7.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
> Changing the mask to 0x1fff would work, but this may not be the > right fix. > > the hole idea is that other RC-5 devices could also be used with > the driver, but if the sub-routine is not doing the right thing, only > this remote will work. > > Could you please try this patch, instead? It is just a debug patch, > so it won't fix the issue, but it may help us to identify what's > happening there. > > Btw, do you have any other remote controllers producing Philips RC-5 > codes? If so, could you also test with them and see what happens? Haven't got any other remote controllers with Philips RC-5 codes. With the 0x1fff mask work. If im pushig the buttons to fast or holding donw the output look like this (don't know is it normal): ir-keytable -t -d /dev/input/event6 Testing events. Please, press CTRL-C to abort. 1325336612.877133: event MSC: scancode = 1e3d 1325336612.877136: event key down: KEY_POWER2 (0x0164) 1325336612.877137: event sync 1325336612.980130: event MSC: scancode = 1e3d 1325336612.980132: event sync 1325336613.083136: event MSC: scancode = 1e3d 1325336613.083138: event sync 1325336613.186133: event MSC: scancode = 1e3d 1325336613.186134: event sync 1325336613.289133: event MSC: scancode = 1e3d 1325336613.289135: event sync 1325336613.378155: event key down: KEY_POWER2 (0x0164) 1325336613.378156: event sync 1325336613.503153: event key down: KEY_POWER2 (0x0164) 1325336613.503154: event sync 1325336613.539111: event key up: KEY_POWER2 (0x0164) 1325336613.539112: event sync With the debug patch dmesg is growing this without any remote activity: [12672.782150] 0x00 0x00 0x00 0x00 0x00 [12672.884991] 0x00 0x00 0x00 0x00 0x00 [12672.987794] 0x00 0x00 0x00 0x00 0x00 [12673.090632] 0x00 0x00 0x00 0x00 0x00 [12673.193465] 0x00 0x00 0x00 0x00 0x00 [12673.296304] 0x00 0x00 0x00 0x00 0x00 ... When pushing fast a button: [12791.990291] 0x80 0x00 0x00 0xfe 0xf4 [12792.093123] 0x00 0x00 0x00 0x00 0x00 [12792.195971] 0x80 0x00 0x00 0xde 0xf4 [12792.298805] 0x80 0x00 0x00 0xfe 0xf4 [12792.401632] 0x00 0x00 0x00 0x00 0x00 [12792.504472] 0x80 0x00 0x00 0xde 0xf4 [12792.607305] 0x00 0x00 0x00 0x00 0x00 [12792.710145] 0x80 0x00 0x00 0xfe 0xf4 [12792.812977] 0x00 0x00 0x00 0x00 0x00 [12792.915819] 0x00 0x00 0x00 0x00 0x00 [12793.018650] 0x80 0x00 0x00 0xfe 0xf4 When hold down a button: 12892.986456] 0x80 0x00 0x00 0xde 0xf4 [12893.089296] 0x80 0x00 0x00 0xde 0xf4 [12893.192186] 0x80 0x00 0x00 0xde 0xf4 [12893.295031] 0x80 0x00 0x00 0xde 0xf4 [12893.397802] 0x80 0x00 0x00 0xde 0xf4 [12893.500639] 0x80 0x00 0x00 0xde 0xf4 [12893.603474] 0x80 0x00 0x00 0xde 0xf4 [12893.706313] 0x80 0x00 0x00 0xde 0xf4 [12893.809146] 0x00 0x00 0x00 0x00 0x00 [12893.911985] 0x00 0x00 0x00 0x00 0x00 [12894.014822] 0x00 0x00 0x00 0x00 0x00 [12894.118122] 0x80 0x00 0x00 0xde 0xf4 [12894.220492] 0x80 0x00 0x00 0xde 0xf4 [12894.325446] 0x80 0x00 0x00 0xde 0xf4 [12894.428161] 0x80 0x00 0x00 0xde 0xf4 [12894.530999] 0x80 0x00 0x00 0xde 0xf4 [12894.633836] 0x80 0x00 0x00 0xde 0xf4 [12894.736672] 0x80 0x00 0x00 0xde 0xf4 [12894.839506] 0x80 0x00 0x00 0xde 0xf4 [12894.942348] 0x00 0x00 0x00 0x00 0x00 [12895.045178] 0x00 0x00 0x00 0x00 0x00 [12895.148017] 0x00 0x00 0x00 0x00 0x00 [12895.250850] 0x00 0x00 0x00 0x00 0x00 -- 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: [PATCHv4 1/2] v4l: Add new framesamples field to struct v4l2_mbus_framefmt
Hi Sylwester, On Wed, Dec 28, 2011 at 06:09:17PM +0100, Sylwester Nawrocki wrote: > On 12/26/2011 01:53 PM, Sakari Ailus wrote: > > On Wed, Dec 21, 2011 at 01:20:56AM +0100, Laurent Pinchart wrote: > >> On Wednesday 14 December 2011 13:23:07 Sylwester Nawrocki wrote: > >>> The purpose of the new field is to allow the video pipeline elements > >>> to negotiate memory buffer size for compressed data frames, where > >>> the buffer size cannot be derived from pixel width and height and > >>> the pixel code. > >>> > >>> For VIDIOC_SUBDEV_S_FMT and VIDIOC_SUBDEV_G_FMT ioctls, the > >>> framesamples parameter should be calculated by the driver from pixel > >>> width, height, color format and other parameters if required and > >>> returned to the caller. This applies to compressed data formats only. > >>> > >>> The application should propagate the framesamples value, whatever > >>> returned at the first sub-device within a data pipeline, i.e. at the > >>> pipeline's data source. > >>> > >>> For compressed data formats the host drivers should internally > >>> validate the framesamples parameter values before streaming is > >>> enabled, to make sure the memory buffer size requirements are > >>> satisfied along the pipeline. > >>> > >>> Signed-off-by: Sylwester Nawrocki > >>> Signed-off-by: Kyungmin Park > >>> -- > >>> There is no changes in this patch comparing to v3. > >>> --- > >>> Documentation/DocBook/media/v4l/dev-subdev.xml | 10 -- > >>> Documentation/DocBook/media/v4l/subdev-formats.xml |9 - > >>> include/linux/v4l2-mediabus.h |4 +++- > >>> 3 files changed, 19 insertions(+), 4 deletions(-) > >>> > >>> diff --git a/Documentation/DocBook/media/v4l/dev-subdev.xml > >>> b/Documentation/DocBook/media/v4l/dev-subdev.xml index 0916a73..b9d24eb > >>> 100644 > >>> --- a/Documentation/DocBook/media/v4l/dev-subdev.xml > >>> +++ b/Documentation/DocBook/media/v4l/dev-subdev.xml > >> > >>> @@ -160,7 +160,13 @@ > >>>guaranteed to be supported by the device. In particular, drivers > >>> guarantee that a returned format will not be further changed if passed to > >>> an &VIDIOC-SUBDEV-S-FMT; call as-is (as long as external parameters, such > >>> as > >>> - formats on other pads or links' configuration are not changed). > >>> > >>> + formats on other pads or links' configuration are not changed). > >>> When > >>> + a device contains a data encoder, the > >>> + framesamples > >>> + field value may be further changed, if parameters of > >>> the > >>> + encoding process are changed after the format has been negotiated. > >>> In > >>> + such situation applications should use &VIDIOC-SUBDEV-G-FMT; ioctl > >>> to > >>> + query an updated format. > >> > >> Sorry for answering so late. I've been thinking about this topic (as well > >> as > >> the proposed new pixelclock field) quite a lot, and one question strikes > >> me > >> here (please don't hate me): does userspace need to care about the > >> framesamples field ? It looks like the value is only used inside the > >> kernel, > >> and we're relying on on userspace to propagate those values between > >> subdevs. > >> > >> If that's the case, wouldn't it be better to have an in-kernel API to > >> handle > >> this ? I'm a bit concerned about forcing userspace to handle internal > >> information to userspace if there's no reason to do so. > > > > I feel partly the same about pixelrate --- there are sound reasons to export > > that to user space still, but the method to do that could be something else > > than putting it to v4l2_mbus_framefmt. > > > > I could think of an in-kernel counterpart for v4l2_mbus_framefmt, say, > > v4l2_mbus_framedesc. This could then be passed from subdev to another using > > a new subdev op. > > That might be needed eventually. But I'm not a great fan in general of yet > another set of callbacks for media bus frame format set up. > > > Something else that should probably belong there is information on the frame > > format: contrary to what I've previously thought, the sensor metadata is > > often sent as part of the same CSI-2 channel. There also can be other types > > of data, such as dummy data and data for black level calibration. I wouldn't > > want to export all this to the user space --- it shouldn't probably need to > > care about it. > > > > The transmitter of the data (sensor) has this information and the CSI-2 > > receiver needs it. Same for the framesamples, as far as I understand. > > We could try to design some standard data structure for frame metadata - > that's how I understood the meaning of struct v4l2_mbus_framedesc. > But I doubt such attempts will be sucessful. And how can we distinguish > which data is valid and applicable when there is lots of weird stuff in one > data structure ? Using media bus pixel code only ? I think the media bus pixel code which is exported to the user space should not be involved with
[PATCH] [media] dvb: Add ops.delsys to the remaining frontends
A few drivers don't have .delsys. Add it, in order to allow
future patches for dvb_frontend.c to not use info.type.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/frontends/s5h1432.c |2 +-
drivers/media/dvb/frontends/stv0297.c |2 +-
drivers/media/dvb/frontends/tda10048.c |2 +-
drivers/media/dvb/pt1/va1j5jf8007s.c |1 +
drivers/media/dvb/pt1/va1j5jf8007t.c |1 +
5 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/frontends/s5h1432.c
b/drivers/media/dvb/frontends/s5h1432.c
index 3a9050f..baa3aae 100644
--- a/drivers/media/dvb/frontends/s5h1432.c
+++ b/drivers/media/dvb/frontends/s5h1432.c
@@ -375,7 +375,7 @@ error:
EXPORT_SYMBOL(s5h1432_attach);
static struct dvb_frontend_ops s5h1432_ops = {
-
+ .delsys = { SYS_DVBT },
.info = {
.name = "Samsung s5h1432 DVB-T Frontend",
.type = FE_OFDM,
diff --git a/drivers/media/dvb/frontends/stv0297.c
b/drivers/media/dvb/frontends/stv0297.c
index dd0a190..8f74762 100644
--- a/drivers/media/dvb/frontends/stv0297.c
+++ b/drivers/media/dvb/frontends/stv0297.c
@@ -690,7 +690,7 @@ error:
}
static struct dvb_frontend_ops stv0297_ops = {
-
+ .delsys = { SYS_DVBC },
.info = {
.name = "ST STV0297 DVB-C",
.type = FE_QAM,
diff --git a/drivers/media/dvb/frontends/tda10048.c
b/drivers/media/dvb/frontends/tda10048.c
index 99bf0c0..57711cb 100644
--- a/drivers/media/dvb/frontends/tda10048.c
+++ b/drivers/media/dvb/frontends/tda10048.c
@@ -1157,7 +1157,7 @@ error:
EXPORT_SYMBOL(tda10048_attach);
static struct dvb_frontend_ops tda10048_ops = {
-
+ .delsys = { SYS_DVBT },
.info = {
.name = "NXP TDA10048HN DVB-T",
.type = FE_OFDM,
diff --git a/drivers/media/dvb/pt1/va1j5jf8007s.c
b/drivers/media/dvb/pt1/va1j5jf8007s.c
index 78344e3..ef74440 100644
--- a/drivers/media/dvb/pt1/va1j5jf8007s.c
+++ b/drivers/media/dvb/pt1/va1j5jf8007s.c
@@ -579,6 +579,7 @@ static void va1j5jf8007s_release(struct dvb_frontend *fe)
}
static struct dvb_frontend_ops va1j5jf8007s_ops = {
+ .delsys = { SYS_ISDBS },
.info = {
.name = "VA1J5JF8007/VA1J5JF8011 ISDB-S",
.type = FE_QPSK,
diff --git a/drivers/media/dvb/pt1/va1j5jf8007t.c
b/drivers/media/dvb/pt1/va1j5jf8007t.c
index c642820..6eeabc8 100644
--- a/drivers/media/dvb/pt1/va1j5jf8007t.c
+++ b/drivers/media/dvb/pt1/va1j5jf8007t.c
@@ -428,6 +428,7 @@ static void va1j5jf8007t_release(struct dvb_frontend *fe)
}
static struct dvb_frontend_ops va1j5jf8007t_ops = {
+ .delsys = { SYS_ISDBT },
.info = {
.name = "VA1J5JF8007/VA1J5JF8011 ISDB-T",
.type = FE_OFDM,
--
1.7.8.352.g876a6
--
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 9/9] [media] firedtv: handle errors from dvb_net_init
On Dec 31 Jonathan Nieder wrote: > It is not common for dvb_net_init to fail, but after the patch > "dvb_net_init: return -errno on error" it can fail due to running out > of memory. Handle this. > From an audit of dvb_net_init callers. > > Signed-off-by: Jonathan Nieder Reviewed-by: Stefan Richter [...] > --- a/drivers/media/dvb/firewire/firedtv-dvb.c > +++ b/drivers/media/dvb/firewire/firedtv-dvb.c > @@ -203,7 +203,9 @@ int fdtv_dvb_register(struct firedtv *fdtv, const > char *name) if (err) > goto fail_rem_frontend; > > - dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, &fdtv->demux.dmx); > + err = dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, > &fdtv->demux.dmx); > + if (err) > + goto fail_disconnect_frontend; > > fdtv_frontend_init(fdtv, name); > err = dvb_register_frontend(&fdtv->adapter, &fdtv->fe); > @@ -218,6 +220,7 @@ int fdtv_dvb_register(struct firedtv *fdtv, const > char *name) > fail_net_release: > dvb_net_release(&fdtv->dvbnet); > +fail_disconnect_frontend: > fdtv->demux.dmx.close(&fdtv->demux.dmx); > fail_rem_frontend: > fdtv->demux.dmx.remove_frontend(&fdtv->demux.dmx, > &fdtv->frontend); -- Stefan Richter -=-==-== ==-- = http://arcgraph.de/sr/ -- 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 0/3] cxd2820/af9013/af9015 conversion to DVBv5 parameters
On 31-12-2011 08:22, Mauro Carvalho Chehab wrote:
> Due to the recent changes on those 3 drivers, applied upstream, I've
> discarded the previous patches I had, and made 3 other ones:
>
> [media] cxd2820: convert get|set_fontend to use DVBv5 parameters
> [media] af9013: convert get|set_fontend to use DVBv5 parameters
> [media] af9015: convert set_fontend to use DVBv5 parameters
>
> They're trivial ones: just remove the DVBv3 parameters from the calls.
> A few other patches at my series also suffered minor merge conflicts,
> with an obvious solution. The entire series is at my sixth rebase of
> the DVBv5 patches, at:
>
> http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/DVBv5-v6
>
> And has 142 patches. I'll merge it today, as it is not fun to rebase
> a tree like that. If bugs are discovered on them, they'll be fixed on
> separate patches anyway, so there's no point on holding it forever.
>
> I may eventually modify a them a little bit, when applying upstream,
> in order to make checkpatch happy with the patches.
Ok, fixed several coding style issues (still, I was too lazy to fix
everything).
As reference, I'm enclosing the diff between upstream and my
experimental tree. Everything here should be just coding style
fixes ;)
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 352b27f..b79629f 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -148,7 +148,7 @@ static int thomson_dtt7579_demod_init(struct dvb_frontend*
fe)
return 0;
}
-static int thomson_dtt7579_tuner_calc_regs(struct dvb_frontend* fe, u8*
pllbuf, int buf_len)
+static int thomson_dtt7579_tuner_calc_regs(struct dvb_frontend *fe, u8*
pllbuf, int buf_len)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
u32 div;
@@ -192,7 +192,7 @@ static struct zl10353_config thomson_dtt7579_zl10353_config
= {
.demod_address = 0x0f,
};
-static int cx24108_tuner_set_params(struct dvb_frontend* fe)
+static int cx24108_tuner_set_params(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
u32 freq = c->frequency;
@@ -267,7 +267,7 @@ static struct cx24110_config pctvsat_config = {
.demod_address = 0x55,
};
-static int microtune_mt7202dtf_tuner_set_params(struct dvb_frontend* fe)
+static int microtune_mt7202dtf_tuner_set_params(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct dvb_bt8xx_card *card = (struct dvb_bt8xx_card *) fe->dvb->priv;
@@ -343,7 +343,7 @@ static int advbt771_samsung_tdtc9251dh0_demod_init(struct
dvb_frontend* fe)
return 0;
}
-static int advbt771_samsung_tdtc9251dh0_tuner_calc_regs(struct dvb_frontend*
fe, u8* pllbuf, int buf_len)
+static int advbt771_samsung_tdtc9251dh0_tuner_calc_regs(struct dvb_frontend
*fe, u8 *pllbuf, int buf_len)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
u32 div;
@@ -463,7 +463,7 @@ static struct or51211_config or51211_config = {
.sleep = or51211_sleep,
};
-static int vp3021_alps_tded4_tuner_set_params(struct dvb_frontend* fe)
+static int vp3021_alps_tded4_tuner_set_params(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
struct dvb_bt8xx_card *card = (struct dvb_bt8xx_card *) fe->dvb->priv;
@@ -516,7 +516,7 @@ static int digitv_alps_tded4_demod_init(struct
dvb_frontend* fe)
return 0;
}
-static int digitv_alps_tded4_tuner_calc_regs(struct dvb_frontend* fe, u8*
pllbuf, int buf_len)
+static int digitv_alps_tded4_tuner_calc_regs(struct dvb_frontend *fe, u8
*pllbuf, int buf_len)
{
u32 div;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
diff --git a/drivers/media/dvb/dvb-core/dvb_frontend.h
b/drivers/media/dvb/dvb-core/dvb_frontend.h
index 1ee2e7f..0a080c3 100644
--- a/drivers/media/dvb/dvb-core/dvb_frontend.h
+++ b/drivers/media/dvb/dvb-core/dvb_frontend.h
@@ -281,7 +281,7 @@ struct dvb_frontend_ops {
enum dvbfe_algo (*get_frontend_algo)(struct dvb_frontend *fe);
/* these two are only used for the swzigzag code */
- int (*set_frontend)(struct dvb_frontend* fe);
+ int (*set_frontend)(struct dvb_frontend *fe);
int (*get_tune_settings)(struct dvb_frontend* fe, struct
dvb_frontend_tune_settings* settings);
int (*get_frontend)(struct dvb_frontend *fe);
diff --git a/drivers/media/dvb/dvb-usb/af9005-fe.c
b/drivers/media/dvb/dvb-usb/af9005-fe.c
index 27ad0a3..0e1b04f 100644
--- a/drivers/media/dvb/dvb-usb/af9005-fe.c
+++ b/drivers/media/dvb/dvb-usb/af9005-fe.c
@@ -930,7 +930,8 @@ static int af9005_fe_init(struct dvb_frontend *fe)
/* init other parameters: program cfoe and select bandwidth */
deb_info("program cfoe\n");
- if ((ret = af9005_fe_program_cfoe(state->d, 600)))
+ ret = af9005_fe_pro
[PATCH 9/9] [media] firedtv: handle errors from dvb_net_init
It is not common for dvb_net_init to fail, but after the patch "dvb_net_init: return -errno on error" it can fail due to running out of memory. Handle this. >From an audit of dvb_net_init callers. Signed-off-by: Jonathan Nieder --- That's the end of the series, though it would have been nice to also check the error handling in dvb/mantis/mantis_dvb.c dvb/ngene/ngene-core.c (which looks a little strange) dvb/pluto2/pluto2.c dvb/pt1/pt1.c dvb/ttpci/av7110.c dvb/ttpci/budget-core.c dvb/ttusb-dec/ttusb_dec.c video/au0828/au0828-dvb.c video/cx18/cx18-dvb.c video/cx231xx/cx231xx-dvb.c video/em28xx/em28xx-dvb.c video/pvrusb2/pvrusb2-dvb.c video/saa7164/saa7164-dvb.c Hopefully this gives the idea, anyway. Patch 2 is the important one, and the patches after that are just toys to show off patch 1. Warning: the patches are _completely_ _untested_. Test results (perhaps from provoking artificial failures in dvb_net_init), just like other comments, would be very welcome. 'night, Jonathan drivers/media/dvb/firewire/firedtv-dvb.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/firewire/firedtv-dvb.c b/drivers/media/dvb/firewire/firedtv-dvb.c index fd8bbbfa5c59..eb7496eab130 100644 --- a/drivers/media/dvb/firewire/firedtv-dvb.c +++ b/drivers/media/dvb/firewire/firedtv-dvb.c @@ -203,7 +203,9 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char *name) if (err) goto fail_rem_frontend; - dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, &fdtv->demux.dmx); + err = dvb_net_init(&fdtv->adapter, &fdtv->dvbnet, &fdtv->demux.dmx); + if (err) + goto fail_disconnect_frontend; fdtv_frontend_init(fdtv, name); err = dvb_register_frontend(&fdtv->adapter, &fdtv->fe); @@ -218,6 +220,7 @@ int fdtv_dvb_register(struct firedtv *fdtv, const char *name) fail_net_release: dvb_net_release(&fdtv->dvbnet); +fail_disconnect_frontend: fdtv->demux.dmx.close(&fdtv->demux.dmx); fail_rem_frontend: fdtv->demux.dmx.remove_frontend(&fdtv->demux.dmx, &fdtv->frontend); -- 1.7.8.2+next.20111228 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
On 31-12-2011 09:47, Dorozel Csaba wrote:
>
>> An RC-5 code is just 14 bits. I found some Hauppauge decoders returning
>> just 12 bits on some places. It seems that all it needs is to do a
>> code3 | 0x3f, in order to discard the two most significant bits (MSB).
>>
>> So, the enclosed patch should fix the issues. Please test.
>
> Half way .. something still wrong.
>
> user juuzer # ir-keytable -t -d /dev/input/event6
> Testing events. Please, press CTRL-C to abort.
> 1325331995.343188: event MSC: scancode = 3e3d
> 1325331995.343190: event sync
> 1325331995.446127: event MSC: scancode = 3e3d
> 1325331995.446129: event sync
> 1325331997.504133: event MSC: scancode = 1e3d
> 1325331997.504135: event key down: KEY_POWER2 (0x0164)
> 1325331997.504136: event sync
> 1325331997.607137: event MSC: scancode = 1e3d
> 1325331997.607138: event sync
> 1325331997.857161: event key up: KEY_POWER2 (0x0164)
> 1325331997.857163: event sync
> 1325331999.973135: event MSC: scancode = 3e3d
> 1325331999.973136: event sync
> 1325332000.075130: event MSC: scancode = 3e3d
> 1325332000.075131: event sync
Changing the mask to 0x1fff would work, but this may not be the
right fix.
the hole idea is that other RC-5 devices could also be used with
the driver, but if the sub-routine is not doing the right thing, only
this remote will work.
Could you please try this patch, instead? It is just a debug patch,
so it won't fix the issue, but it may help us to identify what's
happening there.
Btw, do you have any other remote controllers producing Philips RC-5
codes? If so, could you also test with them and see what happens?
Regards,
Mauro
diff --git a/drivers/media/video/saa7134/saa7134-input.c
b/drivers/media/video/saa7134/saa7134-input.c
index d4ee24b..783d44c 100644
--- a/drivers/media/video/saa7134/saa7134-input.c
+++ b/drivers/media/video/saa7134/saa7134-input.c
@@ -241,6 +241,9 @@ static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key,
u32 *ir_raw)
if (5 != i2c_master_recv(ir->c, buf, 5))
return -EIO;
+ printk("0x%02x 0x%02x 0x%02x 0x%02x 0x%02x",
+ buf[0], buf[1],buf[2],buf[3],buf[4]);
+
cod4= buf[4];
code4 = (cod4 >> 2);
code3 = buf[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
[PATCH 8/9] [media] dvb-usb: handle errors from dvb_net_init
>From an audit of dvb_net_init callers, now that that function
returns -errno on error.
Signed-off-by: Jonathan Nieder
---
drivers/media/dvb/dvb-usb/dvb-usb-dvb.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
index ba4a7517354f..ddf282f355b3 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
@@ -141,11 +141,17 @@ int dvb_usb_adapter_dvb_init(struct dvb_usb_adapter
*adap, short *adapter_nums)
goto err_dmx_dev;
}
- dvb_net_init(&adap->dvb_adap, &adap->dvb_net, &adap->demux.dmx);
+ if ((ret = dvb_net_init(&adap->dvb_adap, &adap->dvb_net,
+ &adap->demux.dmx)) < 0) {
+ err("dvb_net_init failed: error %d",ret);
+ goto err_net_init;
+ }
adap->state |= DVB_USB_ADAP_STATE_DVB;
return 0;
+err_net_init:
+ dvb_dmxdev_release(&adap->dmxdev);
err_dmx_dev:
dvb_dmx_release(&adap->demux);
err_dmx:
--
1.7.8.2+next.20111228
--
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 7/9] [media] dm1105: handle errors from dvb_net_init
Clean up and error out if dvb_net_init fails (for example due to ENOMEM). This involves moving the dvb_net_init call to before frontend_init to make cleaning up a little easier. >From an audit of dvb_net_init callers, now that dvb_net_init lets callers know about errors. Signed-off-by: Jonathan Nieder --- drivers/media/dvb/dm1105/dm1105.c |5 - 1 files changed, 4 insertions(+), 1 deletions(-) diff --git a/drivers/media/dvb/dm1105/dm1105.c b/drivers/media/dvb/dm1105/dm1105.c index 55e6533f15e9..70e040b999e7 100644 --- a/drivers/media/dvb/dm1105/dm1105.c +++ b/drivers/media/dvb/dm1105/dm1105.c @@ -1115,11 +1115,14 @@ static int __devinit dm1105_probe(struct pci_dev *pdev, if (ret < 0) goto err_remove_mem_frontend; + ret = dvb_net_init(dvb_adapter, &dev->dvbnet, dmx); + if (ret < 0) + goto err_disconnect_frontend; + ret = frontend_init(dev); if (ret < 0) goto err_disconnect_frontend; - dvb_net_init(dvb_adapter, &dev->dvbnet, dmx); dm1105_ir_init(dev); INIT_WORK(&dev->work, dm1105_dmx_buffer); -- 1.7.8.2+next.20111228 -- 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 6/9] [media] dvb-bt8xx: handle errors from dvb_net_init
Clean up and error out if dvb_net_init fails (for example when
running out of memory).
>From an audit of dvb_net_init callers, now that dvb_net_init
has learned to return a nonzero value from time to time.
Signed-off-by: Jonathan Nieder
---
drivers/media/dvb/bt8xx/dvb-bt8xx.c |8 +++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 6aa3b486e865..94e01b47784f 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -779,7 +779,11 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
goto err_remove_mem_frontend;
}
- dvb_net_init(&card->dvb_adapter, &card->dvbnet, &card->demux.dmx);
+ result = dvb_net_init(&card->dvb_adapter, &card->dvbnet,
&card->demux.dmx);
+ if (result < 0) {
+ printk("dvb_bt8xx: dvb_net_init failed (errno = %d)\n", result);
+ goto err_disconnect_frontend;
+ }
tasklet_init(&card->bt->tasklet, dvb_bt8xx_task, (unsigned long) card);
@@ -787,6 +791,8 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
return 0;
+err_disconnect_frontend:
+ card->demux.dmx.disconnect_frontend(&card->demux.dmx);
err_remove_mem_frontend:
card->demux.dmx.remove_frontend(&card->demux.dmx, &card->fe_mem);
err_remove_hw_frontend:
--
1.7.8.2+next.20111228
--
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 5/9] [media] flexcop: handle errors from dvb_net_init
Bail out if dvb_net_init encounters an error (for example an
out-of-memory condition), now that it reports them.
Signed-off-by: Jonathan Nieder
---
drivers/media/dvb/b2c2/flexcop.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/media/dvb/b2c2/flexcop.c b/drivers/media/dvb/b2c2/flexcop.c
index 2df1b0214dcd..ed3f42776fee 100644
--- a/drivers/media/dvb/b2c2/flexcop.c
+++ b/drivers/media/dvb/b2c2/flexcop.c
@@ -117,11 +117,16 @@ static int flexcop_dvb_init(struct flexcop_device *fc)
goto err_connect_frontend;
}
- dvb_net_init(&fc->dvb_adapter, &fc->dvbnet, &fc->demux.dmx);
+ if ((ret = dvb_net_init(&fc->dvb_adapter, &fc->dvbnet, &fc->demux.dmx))
< 0) {
+ err("dvb_net_init failed: error %d", ret);
+ goto err_net;
+ }
fc->init_state |= FC_STATE_DVB_INIT;
return 0;
+err_net:
+ fc->demux.dmx.disconnect_frontend(&fc->demux.dmx);
err_connect_frontend:
fc->demux.dmx.remove_frontend(&fc->demux.dmx, &fc->mem_frontend);
err_dmx_add_mem_frontend:
--
1.7.8.2+next.20111228
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
On 31-12-2011 09:17, Patrick Dickey wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 12/31/2011 05:07 AM, Mauro Carvalho Chehab wrote: >> On 31-12-2011 08:15, Dorozel Csaba wrote: Basically, the bridge driver is not sending the complete RC-5 keycode to the IR core, but just the 8 least siginificant bits. So, it is loosing the 0x1e00 code for the Hauppauge grey remote. The fix should be at saa7134-input. It should be something like the enclosed patch (I'm just guessing there that code3 contains the MSB bits - you may need to adjust it to match the IR decoder there): >>> >>> I'm absolutly not a programer but an unhappy linux user who want >>> his working remote back. Know nothing about c code, MSB bits ... >>> After apply your fix looks what happening but remote is still >>> broken. >>> >>> user juuzer # ir-keytable -t Testing events. Please, press CTRL-C >>> to abort. 1325324726.066129: event MSC: scancode = de3d >>> 1325324726.066131: event sync 1325324726.169132: event MSC: >>> scancode = de3d 1325324726.169134: event sync 1325324727.508129: >>> event MSC: scancode = fe3d 1325324727.508131: event sync >>> 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134: >>> event sync 1325324730.084132: event MSC: scancode = de3d >>> 1325324730.084134: event sync 1325324730.187132: event MSC: >>> scancode = de3d >>> >>> It seems the code3 sometimes return with de (1100) sometimes >>> fe (1110). Is it possible to bitwise left 3 then bitwise >>> right 3 so the result in both case is 1e (0000) ? Or its >>> totaly wrong ? >> >> An RC-5 code is just 14 bits. I found some Hauppauge decoders >> returning just 12 bits on some places. It seems that all it needs >> is to do a code3 | 0x3f, in order to discard the two most >> significant bits (MSB). >> >> So, the enclosed patch should fix the issues. Please test. >> >> Regards, Mauro - >> >> saa7134-input: Fix get_key_hvr1110() handling >> >> Instead of returning just 8 bits, return the full RC-5 code >> >> Signed-off-by: Mauro Carvalho Chehab >> >> diff --git a/drivers/media/video/saa7134/saa7134-input.c >> b/drivers/media/video/saa7134/saa7134-input.c index >> d4ee24b..29c8efd 100644 --- >> a/drivers/media/video/saa7134/saa7134-input.c +++ >> b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@ >> static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 >> *ir_raw) return 0; >> >> /* return key */ - *ir_key = code4; - *ir_raw = code4; + *ir_key >> = >> 0x3fff & (code4 | code3 << 8); + *ir_raw = *ir_key; return 1; } >> >> >> Regards, Mauro >>> >> >> -- To unsubscribe from this list: send the line "unsubscribe >> linux-media" in the body of a message to majord...@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > Will this work regardless of what remote is being used? No, they're separate issues. That fix is for HVR-1110 IR keycode handling. It shouldn't affect anything else. > Currently I'm > using a Windows Media Center Remote (Hauppauge HVR-1600 provided it) > with a combination of saa7134 (MSI TV@nywhere Plus) and Hauppauge > HVR-1600 tuners. Right now, the Hauppauge works fine (all of this is > in Mythtv 0.24), but the MSI crashes when I change channels. So, there's some bug at the MSI handling. Please test the latest media-build kernel and see if the crash condition still exists there. If so, please open a separate thread describing what's happening and posting the error logs (from dmesg). > Have a great day:) > Patrick. > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.11 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ > > iEYEARECAAYFAk7+72UACgkQMp6rvjb3CAR2tQCgqSAc55bQyDEe3Z4vu0sUYAne > RrQAoIU89vMVzI8UBH8v+dJxl3RsHj44 > =3joI > -END PGP SIGNATURE- -- 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: v4l: how to get blanking clock count?
Hi Sakari, On 12/31/2011 12:35 PM, Sakari Ailus wrote: > On Sat, Dec 31, 2011 at 02:57:31PM +0800, Scott Jiang wrote: >> 2011/12/31 Sakari Ailus : >>> On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote: Our bridge driver needs to know line clock count including active lines and blanking area. I can compute active clock count according to pixel format, but how can I get this in blanking area in current framework? >>> >>> Such information is not available currently over the V4L2 subdev interface. >>> Please see this patchset: >>> >>> http://www.spinics.net/lists/linux-media/msg41765.html> >>> >>> Patches 7 and 8 are probably the most interesting for you. This is an RFC >>> patchset so the final implementation could well still change. >>> >> Hi Sakari, >> >> Thanks for your reply. Your patch added VBLANK and HBLANK control, but >> my case isn't a user control. >> That is to say, you can't specify a blanking control value for sensor. > > I the case of your bridge, that may not be possible, but that's the only one > I've heard of so I think it's definitely a special case. In that case the > sensor driver can't be allowed to change the blanking periods while > streaming is ongoing. I agree, it's just a matter of adding proper logic at the sensor driver. However it might be a bit tricky, the bridge would have to validate blanking values before actually enabling streaming. > framesamples proposed by Sylwester for v4l2_mbus_framefmt could, and > probably should, be exposed as a control with similar property. Yeah, I'm going to try to add it to your proposed image source control class. >> And you added pixel clock rate in mbus format, I think if I add two >> more parametres such as VBLANK lines and HBLANK clocks I can solve >> this problem. In fact, active lines and blanking lines are essential >> params to define an image. > > Only the active lines and rows are, blanking period is just an idle period > where no image data is transferred. It does not affect the resulting image > in any way. -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/9] [media] ttusb-budget: use goto for exception handling
Avoid some repetition by adopting the usual "goto err" idiom for error
handling.
Signed-off-by: Jonathan Nieder
---
drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 40 +++-
1 files changed, 22 insertions(+), 18 deletions(-)
diff --git a/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
b/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
index 420bb42d5233..b0f90b7f0eb1 100644
--- a/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
+++ b/drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c
@@ -1694,10 +1694,8 @@ static int ttusb_probe(struct usb_interface *intf, const
struct usb_device_id *i
ttusb->i2c_adap.dev.parent= &udev->dev;
result = i2c_add_adapter(&ttusb->i2c_adap);
- if (result) {
- dvb_unregister_adapter (&ttusb->adapter);
- return result;
- }
+ if (result)
+ goto err_unregister_adapter;
memset(&ttusb->dvb_demux, 0, sizeof(ttusb->dvb_demux));
@@ -1714,33 +1712,29 @@ static int ttusb_probe(struct usb_interface *intf,
const struct usb_device_id *i
ttusb->dvb_demux.stop_feed = ttusb_stop_feed;
ttusb->dvb_demux.write_to_decoder = NULL;
- if ((result = dvb_dmx_init(&ttusb->dvb_demux)) < 0) {
+ result = dvb_dmx_init(&ttusb->dvb_demux);
+ if (result < 0) {
printk("ttusb_dvb: dvb_dmx_init failed (errno = %d)\n", result);
- i2c_del_adapter(&ttusb->i2c_adap);
- dvb_unregister_adapter (&ttusb->adapter);
- return -ENODEV;
+ result = -ENODEV;
+ goto err_i2c_del_adapter;
}
//FIXME dmxdev (nur WAS?)
ttusb->dmxdev.filternum = ttusb->dvb_demux.filternum;
ttusb->dmxdev.demux = &ttusb->dvb_demux.dmx;
ttusb->dmxdev.capabilities = 0;
- if ((result = dvb_dmxdev_init(&ttusb->dmxdev, &ttusb->adapter)) < 0) {
+ result = dvb_dmxdev_init(&ttusb->dmxdev, &ttusb->adapter);
+ if (result < 0) {
printk("ttusb_dvb: dvb_dmxdev_init failed (errno = %d)\n",
result);
- dvb_dmx_release(&ttusb->dvb_demux);
- i2c_del_adapter(&ttusb->i2c_adap);
- dvb_unregister_adapter (&ttusb->adapter);
- return -ENODEV;
+ result = -ENODEV;
+ goto err_release_dmx;
}
if (dvb_net_init(&ttusb->adapter, &ttusb->dvbnet,
&ttusb->dvb_demux.dmx)) {
printk("ttusb_dvb: dvb_net_init failed!\n");
- dvb_dmxdev_release(&ttusb->dmxdev);
- dvb_dmx_release(&ttusb->dvb_demux);
- i2c_del_adapter(&ttusb->i2c_adap);
- dvb_unregister_adapter (&ttusb->adapter);
- return -ENODEV;
+ result = -ENODEV;
+ goto err_release_dmxdev;
}
usb_set_intfdata(intf, (void *) ttusb);
@@ -1748,6 +1742,16 @@ static int ttusb_probe(struct usb_interface *intf, const
struct usb_device_id *i
frontend_init(ttusb);
return 0;
+
+err_release_dmxdev:
+ dvb_dmxdev_release(&ttusb->dmxdev);
+err_release_dmx:
+ dvb_dmx_release(&ttusb->dvb_demux);
+err_i2c_del_adapter:
+ i2c_del_adapter(&ttusb->i2c_adap);
+err_unregister_adapter:
+ dvb_unregister_adapter (&ttusb->adapter);
+ return result;
}
static void ttusb_disconnect(struct usb_interface *intf)
--
1.7.8.2+next.20111228
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/5] v4l: Convert V4L2_CID_FOCUS_AUTO control to a menu control
Hi Sylwester, Apologies for my late answer. On Sat, Dec 10, 2011 at 03:42:41PM +0100, Sylwester Nawrocki wrote: > Hi Sakari, > > On 12/10/2011 11:33 AM, Sakari Ailus wrote: > > On Sun, Dec 04, 2011 at 04:16:12PM +0100, Sylwester Nawrocki wrote: > >> Change the V4L2_CID_FOCUS_AUTO control type from boolean to a menu > >> type. In case of boolean control we had values 0 and 1 corresponding > >> to manual and automatic focus respectively. > >> > >> The V4L2_CID_FOCUS_AUTO menu control has currently following items: > >> 0 - V4L2_FOCUS_MANUAL, > >> 1 - V4L2_FOCUS_AUTO, > >> 2 - V4L2_FOCUS_AUTO_MACRO, > >> 3 - V4L2_FOCUS_AUTO_CONTINUOUS. > > > > I would put the macro mode to a separate menu since it's configuration for > > how the regular AF works rather than really different mode. > > Yes, makes sense. Most likely there could be also continuous macro auto > focus.. > I don't have yet an idea what could be a name for that new menu though. V4L2_CID_FOCUS_AUTO_DISTANCE? It could then have choices FULL or MACRO. > Many Samsung devices have also something like guided auto focus, where the > application can specify location in the frame for focusing on. IIRC this could > be also single-shot or continuous. So it could make sense to group MACRO and > "guided" auto focus in one menu, what do you think ? I think it could be a separate menu. It's not connected to the distance parameter. We also need to discuss how the af statistics window configuration is done. I'm not certain there could even be a standardised interface which could be used to control it all. > >> @@ -567,6 +576,7 @@ const char *v4l2_ctrl_get_name(u32 id) > >>case V4L2_CID_PRIVACY: return "Privacy"; > >>case V4L2_CID_IRIS_ABSOLUTE:return "Iris, Absolute"; > >>case V4L2_CID_IRIS_RELATIVE:return "Iris, Relative"; > >> + case V4L2_CID_DO_AUTO_FOCUS:return "Do Auto Focus"; > > > > I'd perhaps use "begin" or "start". How does the user learn the autofocus > > I agree, it's not something than is finished after G_CTRL call returns. > > V4L2_CID_START_AUTO_FOCUS sounds better to me. > > > has finished? I think this looks like quite similar problem than telling the > > flash strobe status to the user. The solution could also be similar to that. > > I guess you're suggesting an auto focus status control? Together with the > control > events it would be nice interface for notifying the applications. I agree. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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
[PATCH 3/9] [media] dvb-bt8xx: use goto based exception handling
Repeating the same cleanup code in each error handling path makes life
unnecessarily difficult for reviewers, who much check each instance of
the same copy+pasted code separately. A "goto" to the end of the
function is more maintainable and conveys the intent more clearly.
While we're touching this code, also lift some assignments from "if"
conditionals for simplicity.
No functional change intended.
Signed-off-by: Jonathan Nieder
---
drivers/media/dvb/bt8xx/dvb-bt8xx.c | 57 --
1 files changed, 27 insertions(+), 30 deletions(-)
diff --git a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
index 521d69104982..6aa3b486e865 100644
--- a/drivers/media/dvb/bt8xx/dvb-bt8xx.c
+++ b/drivers/media/dvb/bt8xx/dvb-bt8xx.c
@@ -741,57 +741,42 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
card->demux.stop_feed = dvb_bt8xx_stop_feed;
card->demux.write_to_decoder = NULL;
- if ((result = dvb_dmx_init(&card->demux)) < 0) {
+ result = dvb_dmx_init(&card->demux);
+ if (result < 0) {
printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
-
- dvb_unregister_adapter(&card->dvb_adapter);
- return result;
+ goto err_unregister_adaptor;
}
card->dmxdev.filternum = 256;
card->dmxdev.demux = &card->demux.dmx;
card->dmxdev.capabilities = 0;
- if ((result = dvb_dmxdev_init(&card->dmxdev, &card->dvb_adapter)) < 0) {
+ result = dvb_dmxdev_init(&card->dmxdev, &card->dvb_adapter);
+ if (result < 0) {
printk("dvb_bt8xx: dvb_dmxdev_init failed (errno = %d)\n",
result);
-
- dvb_dmx_release(&card->demux);
- dvb_unregister_adapter(&card->dvb_adapter);
- return result;
+ goto err_dmx_release;
}
card->fe_hw.source = DMX_FRONTEND_0;
- if ((result = card->demux.dmx.add_frontend(&card->demux.dmx,
&card->fe_hw)) < 0) {
+ result = card->demux.dmx.add_frontend(&card->demux.dmx, &card->fe_hw);
+ if (result < 0) {
printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
-
- dvb_dmxdev_release(&card->dmxdev);
- dvb_dmx_release(&card->demux);
- dvb_unregister_adapter(&card->dvb_adapter);
- return result;
+ goto err_dmxdev_release;
}
card->fe_mem.source = DMX_MEMORY_FE;
- if ((result = card->demux.dmx.add_frontend(&card->demux.dmx,
&card->fe_mem)) < 0) {
+ result = card->demux.dmx.add_frontend(&card->demux.dmx, &card->fe_mem);
+ if (result < 0) {
printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
-
- card->demux.dmx.remove_frontend(&card->demux.dmx, &card->fe_hw);
- dvb_dmxdev_release(&card->dmxdev);
- dvb_dmx_release(&card->demux);
- dvb_unregister_adapter(&card->dvb_adapter);
- return result;
+ goto err_remove_hw_frontend;
}
- if ((result = card->demux.dmx.connect_frontend(&card->demux.dmx,
&card->fe_hw)) < 0) {
+ result = card->demux.dmx.connect_frontend(&card->demux.dmx,
&card->fe_hw);
+ if (result < 0) {
printk("dvb_bt8xx: dvb_dmx_init failed (errno = %d)\n", result);
-
- card->demux.dmx.remove_frontend(&card->demux.dmx,
&card->fe_mem);
- card->demux.dmx.remove_frontend(&card->demux.dmx, &card->fe_hw);
- dvb_dmxdev_release(&card->dmxdev);
- dvb_dmx_release(&card->demux);
- dvb_unregister_adapter(&card->dvb_adapter);
- return result;
+ goto err_remove_mem_frontend;
}
dvb_net_init(&card->dvb_adapter, &card->dvbnet, &card->demux.dmx);
@@ -801,6 +786,18 @@ static int __devinit dvb_bt8xx_load_card(struct
dvb_bt8xx_card *card, u32 type)
frontend_init(card, type);
return 0;
+
+err_remove_mem_frontend:
+ card->demux.dmx.remove_frontend(&card->demux.dmx, &card->fe_mem);
+err_remove_hw_frontend:
+ card->demux.dmx.remove_frontend(&card->demux.dmx, &card->fe_hw);
+err_dmxdev_release:
+ dvb_dmxdev_release(&card->dmxdev);
+err_dmx_release:
+ dvb_dmx_release(&card->demux);
+err_unregister_adaptor:
+ dvb_unregister_adapter(&card->dvb_adapter);
+ return result;
}
static int __devinit dvb_bt8xx_probe(struct bttv_sub_device *sub)
--
1.7.8.2+next.20111228
--
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/9] [media] videobuf-dvb: avoid spurious ENOMEM when CONFIG_DVB_NET=n
videobuf_dvb_register_bus relies on dvb_net_init to set dvbnet->dvbdev
on success, but ever since commit fcc8e7d8c0e2 ("dvb_net: Simplify the
code if DVB NET is not defined"), ->dvbdev is left unset when
networking support is disabled. Therefore in such configurations
videobuf_dvb_register_bus always returns failure, tripping
little-tested error handling paths and preventing the device from
being initialized and used.
Now that dvb_net_init returns a nonzero value on error, we can use
that as a more reliable error indication. Do so.
Now your card be used with CONFIG_DVB_NET=n, and the kernel will pass
on a more useful error code describing what happened when
CONFIG_DVB_NET=y but dvb_net_init fails due to resource exhaustion.
Reported-by: David Fries
Signed-off-by: Jonathan Nieder
---
drivers/media/video/videobuf-dvb.c |7 ---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/media/video/videobuf-dvb.c
b/drivers/media/video/videobuf-dvb.c
index 3de7c7e4402d..59cb54aa2946 100644
--- a/drivers/media/video/videobuf-dvb.c
+++ b/drivers/media/video/videobuf-dvb.c
@@ -226,9 +226,10 @@ static int videobuf_dvb_register_frontend(struct
dvb_adapter *adapter,
}
/* register network adapter */
- dvb_net_init(adapter, &dvb->net, &dvb->demux.dmx);
- if (dvb->net.dvbdev == NULL) {
- result = -ENOMEM;
+ result = dvb_net_init(adapter, &dvb->net, &dvb->demux.dmx);
+ if (result < 0) {
+ printk(KERN_WARNING "%s: dvb_net_init failed (errno = %d)\n",
+ dvb->name, result);
goto fail_fe_conn;
}
return 0;
--
1.7.8.2+next.20111228
--
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/4] V4L: Add JPEG compression control class
Hi Sakari, On 12/30/2011 10:42 PM, Sakari Ailus wrote: > Hi Sylwester, > > On Tue, Dec 27, 2011 at 08:43:28PM +0100, Sylwester Nawrocki wrote: > ... >> +#define V4L2_CID_JPEG_ACTIVE_MARKERS >> (V4L2_CID_JPEG_CLASS_BASE + 4) > > Just a few comments. I like the approach, and I'd just remove the 'S' from > the CID name. Thanks for your review. Ok, I'll make it singular form. I was going back and forth with that, and in last minute even forgot to make it consistent in the DocBook patches. I think we need to also redesign VIDIOC_S/G_JPEGCOMP ioctls, to support quantization and Huffman tables setup. My idea was to firstly add the controls support in drivers, let some time for application to start using them (1 year or so), then remove VIDIOC_S/G_JPEGCOMP support from drivers in question. Finally having very few drivers and applications using VIDIOC_S/G_JPEGCOMP we could deprecate those ioctls and add new ones. As of now only two drivers are using S/G_JPEGCOMP for anything else than image quality and the markers, with gspca being main user. -- Thanks, Sylwester -- 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/9] [media] DVB: dvb_net_init: return -errno on error
dvb_net_init unconditionally returns 0. Callers such as videobuf_dvb_register_frontend examine dvbnet->dvbdev instead of the return value to tell whether the operation succeeded. If it has been set to a valid pointer, success; if it was left equal to NULL, failure. Alas, there is an edge case where that logic does not work as well: when network support has been compiled out (CONFIG_DVB_NET=n), we want dvb_net_init and related operations to behave as no-ops and always succeed, but there is no appropriate value to which to set dvb->dvbdev to indicate this. Let dvb_net_init return a meaningful error code, as preparation for adapting callers to look at that instead. The only immediate impact of this patch should be to make the few callers that already check for an error code from dvb_net_init behave a little more sensibly when it fails. Signed-off-by: Jonathan Nieder --- drivers/media/dvb/dvb-core/dvb_net.c |4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/drivers/media/dvb/dvb-core/dvb_net.c b/drivers/media/dvb/dvb-core/dvb_net.c index 93d9869e0f15..8766ce8c354d 100644 --- a/drivers/media/dvb/dvb-core/dvb_net.c +++ b/drivers/media/dvb/dvb-core/dvb_net.c @@ -1510,9 +1510,7 @@ int dvb_net_init (struct dvb_adapter *adap, struct dvb_net *dvbnet, for (i=0; istate[i] = 0; - dvb_register_device (adap, &dvbnet->dvbdev, &dvbdev_net, + return dvb_register_device(adap, &dvbnet->dvbdev, &dvbdev_net, dvbnet, DVB_DEVICE_NET); - - return 0; } EXPORT_SYMBOL(dvb_net_init); -- 1.7.8.2+next.20111228 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [git:v4l-dvb/for_v3.3] [media] cx88-dvb avoid dangling core->gate_ctrl pointer
Mauro Carvalho Chehab wrote: > Subject: [media] cx88-dvb avoid dangling core->gate_ctrl pointer > Author: David Fries > Date:Thu Dec 15 01:59:20 2011 -0300 > > dvb_register calls videobuf_dvb_register_bus, but if that returns > a failure the module will be unloaded without clearing the > value of core->gate_ctrl which will cause an oops in macros > called from video_open in cx88-video.c > > Signed-off-by: David Fries > Cc: Mauro Carvalho Chehab > Cc: Istvan Varga > Cc: Jonathan Nieder > Signed-off-by: Mauro Carvalho Chehab For what it's worth, Acked-by: Jonathan Nieder Thanks. Here are some patches to stop producing the spurious -ENOMEM in the first place, and to start checking the return value from dvb_net_init in other contexts more diligently. Untested. Bug reports, patches in the same vein on top (just try "git grep -Ovi -e dvb_net_init"), and other thoughts of all kinds welcome. Jonathan Nieder (9): [media] DVB: dvb_net_init: return -errno on error [media] videobuf-dvb: avoid spurious ENOMEM when CONFIG_DVB_NET=n [media] dvb-bt8xx: use goto based exception handling [media] ttusb-budget: use goto for exception handling [media] flexcop: handle errors from dvb_net_init [media] dvb-bt8xx: handle errors from dvb_net_init [media] dm1105: handle errors from dvb_net_init [media] dvb-usb: handle errors from dvb_net_init [media] firedtv: handle errors from dvb_net_init drivers/media/dvb/b2c2/flexcop.c |7 ++- drivers/media/dvb/bt8xx/dvb-bt8xx.c | 65 +++-- drivers/media/dvb/dm1105/dm1105.c |5 +- drivers/media/dvb/dvb-core/dvb_net.c |4 +- drivers/media/dvb/dvb-usb/dvb-usb-dvb.c |8 ++- drivers/media/dvb/firewire/firedtv-dvb.c |5 +- drivers/media/dvb/ttusb-budget/dvb-ttusb-budget.c | 40 +++-- drivers/media/video/videobuf-dvb.c|7 +- 8 files changed, 82 insertions(+), 59 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
> An RC-5 code is just 14 bits. I found some Hauppauge decoders returning > just 12 bits on some places. It seems that all it needs is to do a > code3 | 0x3f, in order to discard the two most significant bits (MSB). > > So, the enclosed patch should fix the issues. Please test. Half way .. something still wrong. user juuzer # ir-keytable -t -d /dev/input/event6 Testing events. Please, press CTRL-C to abort. 1325331995.343188: event MSC: scancode = 3e3d 1325331995.343190: event sync 1325331995.446127: event MSC: scancode = 3e3d 1325331995.446129: event sync 1325331997.504133: event MSC: scancode = 1e3d 1325331997.504135: event key down: KEY_POWER2 (0x0164) 1325331997.504136: event sync 1325331997.607137: event MSC: scancode = 1e3d 1325331997.607138: event sync 1325331997.857161: event key up: KEY_POWER2 (0x0164) 1325331997.857163: event sync 1325331999.973135: event MSC: scancode = 3e3d 1325331999.973136: event sync 1325332000.075130: event MSC: scancode = 3e3d 1325332000.075131: event sync -- 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: v4l: how to get blanking clock count?
Hi Scott, On Sat, Dec 31, 2011 at 02:57:31PM +0800, Scott Jiang wrote: > 2011/12/31 Sakari Ailus : > > Hi Scott, > > > > On Fri, Dec 30, 2011 at 03:20:43PM +0800, Scott Jiang wrote: > >> Hi Hans and Guennadi, > >> > >> Our bridge driver needs to know line clock count including active > >> lines and blanking area. > >> I can compute active clock count according to pixel format, but how > >> can I get this in blanking area in current framework? > > > > Such information is not available currently over the V4L2 subdev interface. > > Please see this patchset: > > > > http://www.spinics.net/lists/linux-media/msg41765.html> > > > > Patches 7 and 8 are probably the most interesting for you. This is an RFC > > patchset so the final implementation could well still change. > > > Hi Sakari, > > Thanks for your reply. Your patch added VBLANK and HBLANK control, but > my case isn't a user control. > That is to say, you can't specify a blanking control value for sensor. I the case of your bridge, that may not be possible, but that's the only one I've heard of so I think it's definitely a special case. In that case the sensor driver can't be allowed to change the blanking periods while streaming is ongoing. framesamples proposed by Sylwester for v4l2_mbus_framefmt could, and probably should, be exposed as a control with similar property. > And you added pixel clock rate in mbus format, I think if I add two > more parametres such as VBLANK lines and HBLANK clocks I can solve > this problem. In fact, active lines and blanking lines are essential > params to define an image. Only the active lines and rows are, blanking period is just an idle period where no image data is transferred. It does not affect the resulting image in any way. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: 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: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/31/2011 05:07 AM, Mauro Carvalho Chehab wrote: > On 31-12-2011 08:15, Dorozel Csaba wrote: >>> Basically, the bridge driver is not sending the complete RC-5 >>> keycode to the IR core, but just the 8 least siginificant >>> bits. So, it is loosing the 0x1e00 code for the Hauppauge grey >>> remote. >>> >>> The fix should be at saa7134-input. It should be something >>> like the enclosed patch (I'm just guessing there that code3 >>> contains the MSB bits - you may need to adjust it to match the >>> IR decoder there): >> >> I'm absolutly not a programer but an unhappy linux user who want >> his working remote back. Know nothing about c code, MSB bits ... >> After apply your fix looks what happening but remote is still >> broken. >> >> user juuzer # ir-keytable -t Testing events. Please, press CTRL-C >> to abort. 1325324726.066129: event MSC: scancode = de3d >> 1325324726.066131: event sync 1325324726.169132: event MSC: >> scancode = de3d 1325324726.169134: event sync 1325324727.508129: >> event MSC: scancode = fe3d 1325324727.508131: event sync >> 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134: >> event sync 1325324730.084132: event MSC: scancode = de3d >> 1325324730.084134: event sync 1325324730.187132: event MSC: >> scancode = de3d >> >> It seems the code3 sometimes return with de (1100) sometimes >> fe (1110). Is it possible to bitwise left 3 then bitwise >> right 3 so the result in both case is 1e (0000) ? Or its >> totaly wrong ? > > An RC-5 code is just 14 bits. I found some Hauppauge decoders > returning just 12 bits on some places. It seems that all it needs > is to do a code3 | 0x3f, in order to discard the two most > significant bits (MSB). > > So, the enclosed patch should fix the issues. Please test. > > Regards, Mauro - > > saa7134-input: Fix get_key_hvr1110() handling > > Instead of returning just 8 bits, return the full RC-5 code > > Signed-off-by: Mauro Carvalho Chehab > > diff --git a/drivers/media/video/saa7134/saa7134-input.c > b/drivers/media/video/saa7134/saa7134-input.c index > d4ee24b..29c8efd 100644 --- > a/drivers/media/video/saa7134/saa7134-input.c +++ > b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@ > static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 > *ir_raw) return 0; > > /* return key */ -*ir_key = code4; - *ir_raw = code4; + *ir_key > = > 0x3fff & (code4 | code3 << 8); + *ir_raw = *ir_key; return 1; } > > > Regards, Mauro >> > > -- To unsubscribe from this list: send the line "unsubscribe > linux-media" in the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html Will this work regardless of what remote is being used? Currently I'm using a Windows Media Center Remote (Hauppauge HVR-1600 provided it) with a combination of saa7134 (MSI TV@nywhere Plus) and Hauppauge HVR-1600 tuners. Right now, the Hauppauge works fine (all of this is in Mythtv 0.24), but the MSI crashes when I change channels. Have a great day:) Patrick. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk7+72UACgkQMp6rvjb3CAR2tQCgqSAc55bQyDEe3Z4vu0sUYAne RrQAoIU89vMVzI8UBH8v+dJxl3RsHj44 =3joI -END PGP SIGNATURE- -- 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 3.3] VIDIOC_LOG_STATUS support for sub-devices
Hi Mauro, The following changes since commit 3220eb73c5647af4c1f18e32c12dccb8adbac59d: s5p-fimc: Add support for alpha component configuration (2011-12-20 19:46:55 +0100) are available in the git repository at: git://git.infradead.org/users/kmpark/linux-samsung v4l_mbus This one patch enables VIDIOC_LOG_STATUS on subdev nodes. Sylwester Nawrocki (1): v4l: Add VIDIOC_LOG_STATUS support for sub-device nodes drivers/media/video/v4l2-subdev.c |4 1 files changed, 4 insertions(+), 0 deletions(-) -- Regards, Sylwester -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
On 31-12-2011 08:15, Dorozel Csaba wrote: >> Basically, the bridge driver is not sending the complete RC-5 >> keycode to the IR core, but just the 8 least siginificant bits. >> So, it is loosing the 0x1e00 code for the Hauppauge grey remote. >> >> The fix should be at saa7134-input. It should be something like >> the enclosed patch (I'm just guessing there that code3 contains >> the MSB bits - you may need to adjust it to match the IR decoder >> there): > > I'm absolutly not a programer but an unhappy linux user who want his working > remote back. > Know nothing about c code, MSB bits ... After apply your fix looks what > happening but remote is > still broken. > > user juuzer # ir-keytable -t > Testing events. Please, press CTRL-C to abort. > 1325324726.066129: event MSC: scancode = de3d > 1325324726.066131: event sync > 1325324726.169132: event MSC: scancode = de3d > 1325324726.169134: event sync > 1325324727.508129: event MSC: scancode = fe3d > 1325324727.508131: event sync > 1325324727.611132: event MSC: scancode = fe3d > 1325324727.611134: event sync > 1325324730.084132: event MSC: scancode = de3d > 1325324730.084134: event sync > 1325324730.187132: event MSC: scancode = de3d > > It seems the code3 sometimes return with de (1100) sometimes fe > (1110). Is it possible > to bitwise left 3 then bitwise right 3 so the result in both case is 1e > (0000) ? Or its totaly > wrong ? An RC-5 code is just 14 bits. I found some Hauppauge decoders returning just 12 bits on some places. It seems that all it needs is to do a code3 | 0x3f, in order to discard the two most significant bits (MSB). So, the enclosed patch should fix the issues. Please test. Regards, Mauro - saa7134-input: Fix get_key_hvr1110() handling Instead of returning just 8 bits, return the full RC-5 code Signed-off-by: Mauro Carvalho Chehab diff --git a/drivers/media/video/saa7134/saa7134-input.c b/drivers/media/video/saa7134/saa7134-input.c index d4ee24b..29c8efd 100644 --- a/drivers/media/video/saa7134/saa7134-input.c +++ b/drivers/media/video/saa7134/saa7134-input.c @@ -249,8 +249,8 @@ static int get_key_hvr1110(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw) return 0; /* return key */ - *ir_key = code4; - *ir_raw = code4; + *ir_key = 0x3fff & (code4 | code3 << 8); + *ir_raw = *ir_key; return 1; } Regards, Mauro > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] [media] af9015: convert set_fontend to use DVBv5 parameters
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/dvb-usb/af9015.c |5 ++---
drivers/media/dvb/dvb-usb/af9015.h |3 +--
2 files changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index 7b606b7..7959053 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1096,8 +1096,7 @@ error:
}
/* override demod callbacks for resource locking */
-static int af9015_af9013_set_frontend(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *params)
+static int af9015_af9013_set_frontend(struct dvb_frontend *fe)
{
int ret;
struct dvb_usb_adapter *adap = fe->dvb->priv;
@@ -1106,7 +1105,7 @@ static int af9015_af9013_set_frontend(struct dvb_frontend
*fe,
if (mutex_lock_interruptible(&adap->dev->usb_mutex))
return -EAGAIN;
- ret = priv->set_frontend[adap->id](fe, params);
+ ret = priv->set_frontend[adap->id](fe);
mutex_unlock(&adap->dev->usb_mutex);
diff --git a/drivers/media/dvb/dvb-usb/af9015.h
b/drivers/media/dvb/dvb-usb/af9015.h
index 4a12617..f619063 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -104,8 +104,7 @@ struct af9015_state {
u8 rc_last[4];
/* for demod callback override */
- int (*set_frontend[2]) (struct dvb_frontend *fe,
- struct dvb_frontend_parameters *params);
+ int (*set_frontend[2]) (struct dvb_frontend *fe);
int (*read_status[2]) (struct dvb_frontend *fe, fe_status_t *status);
int (*init[2]) (struct dvb_frontend *fe);
int (*sleep[2]) (struct dvb_frontend *fe);
--
1.7.8.352.g876a6
--
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/3] cxd2820/af9013/af9015 conversion to DVBv5 parameters
Due to the recent changes on those 3 drivers, applied upstream, I've discarded the previous patches I had, and made 3 other ones: [media] cxd2820: convert get|set_fontend to use DVBv5 parameters [media] af9013: convert get|set_fontend to use DVBv5 parameters [media] af9015: convert set_fontend to use DVBv5 parameters They're trivial ones: just remove the DVBv3 parameters from the calls. A few other patches at my series also suffered minor merge conflicts, with an obvious solution. The entire series is at my sixth rebase of the DVBv5 patches, at: http://git.linuxtv.org/mchehab/experimental.git/shortlog/refs/heads/DVBv5-v6 And has 142 patches. I'll merge it today, as it is not fun to rebase a tree like that. If bugs are discovered on them, they'll be fixed on separate patches anyway, so there's no point on holding it forever. I may eventually modify a them a little bit, when applying upstream, in order to make checkpatch happy with the patches. The complete list of patches are: de76d62 [media] dvb: don't require a parameter for get_frontend ff87913 dvb_frontend: Fix inversion breakage due to DVBv5 conversion 7cd0feb [media] s921: Properly report the delivery system 4ef8307 [media] dvb-core: be sure that drivers won't use DVBv3 internally f52daea cx23885-dvb: Remove a dirty hack that would require DVBv3 582ba3c [media] dvb: don't use DVBv3 bandwidth macros 6bdbcd6 [media] dvb-core: don't use fe_bandwidth_t on driver affca15 [media] dvb: remove the track() fops b6f6078 [media] dvb: don't pass a DVBv3 parameter for search() fops 77e4321 [media] dvb-core: Don't pass DVBv3 parameters on tune() fops 1b27a9a [media] dvb: simplify get_tune_settings() struct e1b5a31 [media] dvb-core: remove get|set_frontend_legacy 8bc3df6 [media] af9015: convert set_fontend to use DVBv5 parameters e05aac5 [media] af9013: convert get|set_fontend to use DVBv5 parameters fa0c555 [media] cxd2820: convert get|set_fontend to use DVBv5 parameters ff517a9 [media] tlg2300: convert set_fontend to use DVBv5 parameters 332e2b8 [media] ttusb-dec: convert set_fontend to use DVBv5 parameters 3fc4e97 [media] siano: convert set_fontend to use DVBv5 parameters 7e5442a [media] firedtv: convert set_fontend to use DVBv5 parameters 83816aa [media] vp7045-fe: convert set_fontend to use DVBv5 parameters 1cc4f46 [media] vp702x-fe: convert set_fontend to use DVBv5 parameters be9ccc0 [media] mxl111sf-demod: convert set_fontend to use DVBv5 parameters 6a8635e [media] gp8psk-fe: convert set_fontend to use DVBv5 parameters 27025cd [media] friio-fe: convert set_fontend to use DVBv5 parameters 4c0c471 [media] dtt200u-fe: convert set_fontend to use DVBv5 parameters 86b0ba8 [media] cinergyT2-fe: convert set_fontend to use DVBv5 parameters 5839d66 [media] af9005-fe: convert set_fontend to use DVBv5 parameters 244d107 [media] dst: convert set_fontend to use DVBv5 parameters 6ecdfc1 [media] staging/as102: convert set_fontend to use DVBv5 parameters 439a417 [media] vez1820: convert set_fontend to use DVBv5 parameters d64ef26 [media] tda8083: convert set_fontend to use DVBv5 parameters ee4688d [media] s55h1411: convert set_fontend to use DVBv5 parameters 7d2eea7 [media] s5h1409: convert set_fontend to use DVBv5 parameters 32403dc [media] or51211: convert set_fontend to use DVBv5 parameters 60dfcc4 [media] or51132: convert set_fontend to use DVBv5 parameters 53fa6c4 [media] nxt200x: convert set_fontend to use DVBv5 parameters 6e47d5c [media] tda10086: convert set_fontend to use DVBv5 parameters 0bb603b [media] tda10071: convert set_fontend to use DVBv5 parameters 558a5f1 [media] tda10023: convert set_fontend to use DVBv5 parameters 3b306af [media] tda10021: convert set_fontend to use DVBv5 parameters 0e2a317 [media] stv090x: use .delsys property, instead of get_property() 3892652 [media] stv900: convert set_fontend to use DVBv5 parameters 6d36ee5 [media] stv0299: convert set_fontend to use DVBv5 parameters fb78614 [media] stv0297: convert set_fontend to use DVBv5 parameters 0b67256 [media] stv0288: convert set_fontend to use DVBv5 parameters 889468d [media] stb6100: use get_frontend, instead of get_frontend_legacy() 15f0514 [media] stb0899: convert get_frontend to the new struct 6fda271 [media] si21xx: convert set_fontend to use DVBv5 parameters 2a97b37 [media] s5h1420: convert set_fontend to use DVBv5 parameters 0fc0ec5 [media] mt312: convert set_fontend to use DVBv5 parameters cd1f32c [media] s921: convert set_fontend to use DVBv5 parameters 7e4c5b9 [media] tda1004x: convert set_fontend to use DVBv5 parameters e135675 [media] tda10048: convert set_fontend to use DVBv5 parameters 475d8b8 [media] stv0367: convert set_fontend to use DVBv5 parameters 25ad834 [media] sp887x: convert set_fontend to use DVBv5 parameters 174832a [media] sp8870: convert set_fontend to use DVBv5 parameters 071ab4e [media] s5h1432: convert set_fontend to use DVBv5 parameters 4b63603 [media] nxt6000: convert set_fontend to use DVBv5 parameters 3be9e20 [media] mt352: convert set_
[PATCH 2/3] [media] af9013: convert get|set_fontend to use DVBv5 parameters
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/frontends/af9013.c | 11 +--
1 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/media/dvb/frontends/af9013.c
b/drivers/media/dvb/frontends/af9013.c
index 8a8f78a..a70358c 100644
--- a/drivers/media/dvb/frontends/af9013.c
+++ b/drivers/media/dvb/frontends/af9013.c
@@ -572,8 +572,7 @@ static int af9013_get_tune_settings(struct dvb_frontend *fe,
return 0;
}
-static int af9013_set_frontend(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *p)
+static int af9013_set_frontend(struct dvb_frontend *fe)
{
struct af9013_state *state = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
@@ -847,10 +846,9 @@ err:
}
static int af9013_get_frontend(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *p)
+ struct dtv_frontend_properties *c)
{
struct af9013_state *state = fe->demodulator_priv;
- struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret;
u8 buf[3];
@@ -1482,6 +1480,7 @@ err:
EXPORT_SYMBOL(af9013_attach);
static struct dvb_frontend_ops af9013_ops = {
+ .delsys = { SYS_DVBT },
.info = {
.name = "Afatech AF9013",
.type = FE_OFDM,
@@ -1512,8 +1511,8 @@ static struct dvb_frontend_ops af9013_ops = {
.sleep = af9013_sleep,
.get_tune_settings = af9013_get_tune_settings,
- .set_frontend_legacy = af9013_set_frontend,
- .get_frontend_legacy = af9013_get_frontend,
+ .set_frontend = af9013_set_frontend,
+ .get_frontend = af9013_get_frontend,
.read_status = af9013_read_status,
.read_snr = af9013_read_snr,
--
1.7.8.352.g876a6
--
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/3] [media] cxd2820: convert get|set_fontend to use DVBv5 parameters
Instead of using dvb_frontend_parameters struct, that were
designed for a subset of the supported standards, use the DVBv5
cache information.
Also, fill the supported delivery systems at dvb_frontend_ops
struct.
Signed-off-by: Mauro Carvalho Chehab
---
drivers/media/dvb/frontends/cxd2820r_c.c|6 +--
drivers/media/dvb/frontends/cxd2820r_core.c | 62 +-
drivers/media/dvb/frontends/cxd2820r_priv.h | 18 +++-
drivers/media/dvb/frontends/cxd2820r_t.c|6 +--
drivers/media/dvb/frontends/cxd2820r_t2.c |6 +--
5 files changed, 34 insertions(+), 64 deletions(-)
diff --git a/drivers/media/dvb/frontends/cxd2820r_c.c
b/drivers/media/dvb/frontends/cxd2820r_c.c
index 9d081ef..9454049 100644
--- a/drivers/media/dvb/frontends/cxd2820r_c.c
+++ b/drivers/media/dvb/frontends/cxd2820r_c.c
@@ -21,8 +21,7 @@
#include "cxd2820r_priv.h"
-int cxd2820r_set_frontend_c(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *params)
+int cxd2820r_set_frontend_c(struct dvb_frontend *fe)
{
struct cxd2820r_priv *priv = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
@@ -105,8 +104,7 @@ error:
return ret;
}
-int cxd2820r_get_frontend_c(struct dvb_frontend *fe,
- struct dvb_frontend_parameters *p)
+int cxd2820r_get_frontend_c(struct dvb_frontend *fe)
{
struct cxd2820r_priv *priv = fe->demodulator_priv;
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
diff --git a/drivers/media/dvb/frontends/cxd2820r_core.c
b/drivers/media/dvb/frontends/cxd2820r_core.c
index f4718d5..56b7c28 100644
--- a/drivers/media/dvb/frontends/cxd2820r_core.c
+++ b/drivers/media/dvb/frontends/cxd2820r_core.c
@@ -246,8 +246,7 @@ u32 cxd2820r_div_u64_round_closest(u64 dividend, u32
divisor)
return div_u64(dividend + (divisor / 2), divisor);
}
-static int cxd2820r_set_frontend(struct dvb_frontend *fe,
-struct dvb_frontend_parameters *p)
+static int cxd2820r_set_frontend(struct dvb_frontend *fe)
{
struct dtv_frontend_properties *c = &fe->dtv_property_cache;
int ret;
@@ -258,7 +257,7 @@ static int cxd2820r_set_frontend(struct dvb_frontend *fe,
ret = cxd2820r_init_t(fe);
if (ret < 0)
goto err;
- ret = cxd2820r_set_frontend_t(fe, p);
+ ret = cxd2820r_set_frontend_t(fe);
if (ret < 0)
goto err;
break;
@@ -266,15 +265,15 @@ static int cxd2820r_set_frontend(struct dvb_frontend *fe,
ret = cxd2820r_init_t(fe);
if (ret < 0)
goto err;
- ret = cxd2820r_set_frontend_t2(fe, p);
+ ret = cxd2820r_set_frontend_t2(fe);
if (ret < 0)
goto err;
break;
- case SYS_DVBC_ANNEX_AC:
+ case SYS_DVBC_ANNEX_A:
ret = cxd2820r_init_c(fe);
if (ret < 0)
goto err;
- ret = cxd2820r_set_frontend_c(fe, p);
+ ret = cxd2820r_set_frontend_c(fe);
if (ret < 0)
goto err;
break;
@@ -298,7 +297,7 @@ static int cxd2820r_read_status(struct dvb_frontend *fe,
fe_status_t *status)
case SYS_DVBT2:
ret = cxd2820r_read_status_t2(fe, status);
break;
- case SYS_DVBC_ANNEX_AC:
+ case SYS_DVBC_ANNEX_A:
ret = cxd2820r_read_status_c(fe, status);
break;
default:
@@ -309,20 +308,20 @@ static int cxd2820r_read_status(struct dvb_frontend *fe,
fe_status_t *status)
}
static int cxd2820r_get_frontend(struct dvb_frontend *fe,
-struct dvb_frontend_parameters *p)
+struct dtv_frontend_properties *c)
{
int ret;
dbg("%s: delsys=%d", __func__, fe->dtv_property_cache.delivery_system);
switch (fe->dtv_property_cache.delivery_system) {
case SYS_DVBT:
- ret = cxd2820r_get_frontend_t(fe, p);
+ ret = cxd2820r_get_frontend_t(fe);
break;
case SYS_DVBT2:
- ret = cxd2820r_get_frontend_t2(fe, p);
+ ret = cxd2820r_get_frontend_t2(fe);
break;
- case SYS_DVBC_ANNEX_AC:
- ret = cxd2820r_get_frontend_c(fe, p);
+ case SYS_DVBC_ANNEX_A:
+ ret = cxd2820r_get_frontend_c(fe);
break;
default:
ret = -EINVAL;
@@ -343,7 +342,7 @@ static int cxd2820r_read_ber(struct dvb_frontend *fe, u32
*ber)
case SYS_DVBT2:
ret = cxd2820r_read_ber_t2(fe, ber);
break;
- case SYS_DVBC_ANNEX_AC:
+ case SYS_DVBC_ANNEX_A:
ret = cxd2820r_read_ber_c(fe, ber);
break;
Re: ir-kbd-i2c / rc-hauppauge / linux-3.x broken
> Basically, the bridge driver is not sending the complete RC-5 > keycode to the IR core, but just the 8 least siginificant bits. > So, it is loosing the 0x1e00 code for the Hauppauge grey remote. > > The fix should be at saa7134-input. It should be something like > the enclosed patch (I'm just guessing there that code3 contains > the MSB bits - you may need to adjust it to match the IR decoder > there): I'm absolutly not a programer but an unhappy linux user who want his working remote back. Know nothing about c code, MSB bits ... After apply your fix looks what happening but remote is still broken. user juuzer # ir-keytable -t Testing events. Please, press CTRL-C to abort. 1325324726.066129: event MSC: scancode = de3d 1325324726.066131: event sync 1325324726.169132: event MSC: scancode = de3d 1325324726.169134: event sync 1325324727.508129: event MSC: scancode = fe3d 1325324727.508131: event sync 1325324727.611132: event MSC: scancode = fe3d 1325324727.611134: event sync 1325324730.084132: event MSC: scancode = de3d 1325324730.084134: event sync 1325324730.187132: event MSC: scancode = de3d It seems the code3 sometimes return with de (1100) sometimes fe (1110). Is it possible to bitwise left 3 then bitwise right 3 so the result in both case is 1e (0000) ? Or its totaly wrong ? -- 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: em28xx: new board id [eb1a:5051]
On Fri, 2011-12-30 at 15:16 -0800, Reuben Stokes wrote: > On Friday 30 December 2011 14:27:57 Gareth Williams wrote: > > On Fri, 2011-12-30 at 05:04 -0800, Reuben Stokes wrote: > > > On Friday 30 December 2011 02:01:35 you wrote: > > > > On Thu, 2011-12-29 at 15:13 -0800, Reuben Stokes wrote: > > > > > Hi, > > > > > > > > > > Not nearly as linux-savvy as most of the users here, but I attempted > > > > > to operate a "Raygo USB Video Recorder" (audio/video capture device). > > > > > Don't know if my efforts qualify as a "test". > > > > > > > > > > > > > > > Model Number: > > > > > R12-41373 > > > > > > > > > > Display name: > > > > > USB 2861 Device > > > > > > > > > > lsusb: > > > > > Bus 001 Device 002: ID eb1a:5051 eMPIA Technology, Inc. > > > > > > > > > > dmesg: > > > > > [ 7182.076058] usb 1-1: new high speed USB device using ehci_hcd and > > > > > address 3 > > > > > [ 7182.212702] usb 1-1: New USB device found, idVendor=eb1a, > > > > > idProduct=5051 > > > > > [ 7182.212714] usb 1-1: New USB device strings: Mfr=0, Product=1, > > > > > SerialNumber=2 > > > > > [ 7182.212723] usb 1-1: Product: USB 2861 Device > > > > > [ 7182.212729] usb 1-1: SerialNumber: 0 > > > > > > > > > > System: > > > > > HP Pavilion dv6910 laptop > > > > > AMD Turion X2 CPU (64 bit) > > > > > Mepis 11; 64 bit( based on Debian Squeeze) > > > > > > > > > > > > > > > Tried > > > > > --- > > > > > * Installed em28xx drivers using instructions found at linuxtv.org. > > > > > I note however that this particular vendor/product ID is not > > > > > validated in the em28xx devices list. > > > > > * As new drivers do not automatically load, I use command: modprobe > > > > > em28xx > > > > >After this "modprobe -l | grep em28xx" yields > > > > > kernel/drivers/media/video/em28xx/em28xx-alsa.ko > > > > > kernel/drivers/media/video/em28xx/em28xx.ko > > > > > kernel/drivers/media/video/em28xx/em28xx-dvb.ko > > > > > * Device comes with a driver CD for Windows which does work in > > > > > Windows. > > > > > > > > > > End result is the device is not recognized as a capture device option > > > > > in any software tried including vlc, cheese, guvcview, kdenlive. > > > > > > > > > > Any help getting this to work in Linux would be appreciated as it > > > > > completely sucks in my bloated, memory-hogging, 32-bit Windows Vista. > > > > > > > > > > Reuben > > > > > -- > > > > > 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 > > > > > > > > Reuben, > > > > > > > > If you're willing, then open up the device and see what the chips within > > > > are. You believe it's em28xx based, but there may well be additional > > > > devices in there for audio and video. > > > > > > > > Once you've found out what's inside it will be easier to get it working. > > > > It may be as simple as getting the driver to recognise the USB Vendor ID > > > > or it may require much more work. > > > > > > > > Regards, > > > > > > > > Gareth > > > > > > > > -- > > > > 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 > > > > > > > > > > > > > > Thank you very much for the response. > > > > > > Okay, opening it was easier than first suspected. > > > > > > The main (biggest) chip reads with nice big letters and a logo: > > > eMPIA > > > EM2860 > > > P86J3-011 > > > 201047-01AG > > > > > > Less useful information inlcudes: > > > > > > A smaller chip on the flip side of the circuit board, in letters visible > > > only through a magnifying glass, reads: > > > eMPIA > > > TECHNOLOGY > > > EMP202 > > > T10164 > > > 1052 > > > > > > The circuit board itself is stamped: > > > PM22860-2GOB > > > > > > Again, thank you. > > > > > > Reuben > > Reuben, > > > > Was there another chip on there? The EMP202 is an audio chip that can > > covert analogue audio to digital PCM (and vice versa). The EM2860 sends > > this digital audio along with digital video over USB. For this to work > > though, the device will need to convert analogue video to digital and > > will need another chip to do this. An example would be a SAA7113 from > > Philips. Have another look and post back here. > > > > The two chips you've identified are commonly used in for this type of > > device and should be easily configurable in the em28xx driver. We just > > need the video chip now! And a tail wind... > > > > Regards, > > > > Gareth > > > > -- > > 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 > > > > > > Good call. There is another chip. The logo
