Re: [PATCH libv4l tree, RFC] libv4l: skip false Pixart markers with buffer copy
Hi,
This is a proof-of-concept patch to try to decode the JPEG with PixArt markers.
Please check whether it is working at your side. My experience is that the
number of frames with glitch are reduced.
Regards,
Márton Németh
---
From: Márton Németh nm...@freemail.hu
Before trying to decode the image data filter the PixArt markers out.
Signed-off-by: Márton Németh nm...@freemail.hu
---
diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.h
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hTue Feb 02
11:34:06 2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg-internal.hThu Feb 04
09:13:24 2010 +0100
@@ -91,8 +91,11 @@
/* Private variables */
const unsigned char *stream_begin, *stream_end;
unsigned int stream_length;
+ unsigned char *stream_begin_filtered, *stream_end_filtered;
+ unsigned int stream_length_filtered;
const unsigned char *stream; /* Pointer to the current stream */
+ unsigned char *stream_filtered;
unsigned int reservoir, nbits_in_reservoir;
struct component component_infos[COMPONENTS];
diff -r 966f60c672e9 v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c
--- a/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Tue Feb 02 11:34:06 2010 +0100
+++ b/v4l2-apps/libv4l/libv4lconvert/tinyjpeg.c Thu Feb 04 09:13:24 2010 +0100
@@ -312,19 +312,18 @@
/* Special Pixart versions of the *_nbits functions, these remove the special
ff ff ff xx sequences pixart cams insert from the bitstream */
-#define pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted) \
+#define
pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted) \
do { \
while (nbits_in_reservoirnbits_wanted) \
{ \
unsigned char c; \
- if (stream = priv-stream_end) { \
+ if (stream = stream_end) { \
snprintf(priv-error_string, sizeof(priv-error_string), \
fill_nbits error: need %u more bits\n, \
nbits_wanted - nbits_in_reservoir); \
longjmp(priv-jump_state, -EIO); \
} \
c = *stream++; \
- reservoir = 8; \
if (c == 0xff) { \
switch (stream[0]) { \
case 0x00: \
@@ -332,7 +331,7 @@
break; \
case 0xd9: /* EOF marker */ \
stream++; \
- if (stream != priv-stream_end) { \
+ if (stream != stream_end) { \
snprintf(priv-error_string, sizeof(priv-error_string), \
Pixart JPEG error: premature EOF\n); \
longjmp(priv-jump_state, -EIO); \
@@ -340,14 +339,22 @@
break; \
case 0xff: \
if (stream[1] == 0xff) { \
- if (stream[2] 7) { \
+ if (stream[2] == 0) { \
+ stream += 3; \
+ c = *stream++; \
+ break; \
+ } else if (stream[2] == 1) { \
+ stream += 3; \
+ c = *stream++; \
+ break; \
+ } else if (stream[2] == 2) { \
stream += 3; \
c = *stream++; \
break; \
} else if (stream[2] == 0xff) { \
- /* four 0xff in a row: the first belongs to the image data
*/ \
+ /* four 0xff in a row: the first belongs to the image */ \
break; \
- }\
+ } \
} \
/* Error fall through */ \
default: \
@@ -358,15 +365,16 @@
longjmp(priv-jump_state, -EIO); \
} \
} \
+ reservoir = 8; \
reservoir |= c; \
nbits_in_reservoir+=8; \
} \
} while(0);
/* Signed version */
-#define
pixart_get_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \
+#define
pixart_get_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result)
\
do { \
- pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \
+
pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,(nbits_wanted));
\
result = ((reservoir)(nbits_in_reservoir-(nbits_wanted))); \
nbits_in_reservoir -= (nbits_wanted); \
reservoir = ((1Unbits_in_reservoir)-1); \
@@ -374,9 +382,9 @@
result += (0xUL(nbits_wanted))+1; \
} while(0);
-#define
pixart_look_nbits(reservoir,nbits_in_reservoir,stream,nbits_wanted,result) \
+#define
pixart_look_nbits(reservoir,nbits_in_reservoir,stream,stream_end,nbits_wanted,result)
\
do { \
- pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,(nbits_wanted)); \
+
pixart_fill_nbits(reservoir,nbits_in_reservoir,stream,stream_end,(nbits_wanted));
\
result = ((reservoir)(nbits_in_reservoir-(nbits_wanted))); \
} while(0);
@@ -443,7 +451,8 @@
unsigned int extra_nbits, nbits;
uint16_t *slowtable;
- pixart_look_nbits(priv-reservoir, priv-nbits_in_reservoir, priv-stream,
HUFFMAN_HASH_NBITS, hcode);
+ pixart_look_nbits(priv-reservoir, priv-nbits_in_reservoir,
Reloading DVB drivers causes 100% reproducible crash
Hi, I've posted previously with this subject line [TT-Budget/S-1500 PCI crashes with current hg (v4l-dvb-cdcf089168df)] and have finally figured out what is happening. If you remove your DVB drivers, and reload them, you will get a 100% reproducible crash with todays HG repository (i.e the bug is still in as of Feb 4th 2010). Anyone with a budget_ci card with a ir will see this. Dave Feb 3 20:49:07 home kernel: cx8802_start_dma() Failed. Unsupported value in .mpeg (0x0001) Feb 3 20:49:38 home last message repeated 61 times Feb 3 20:49:48 home last message repeated 21 times Feb 3 20:49:52 home kernel: /usr/src/mythtv/vdr-sc/contrib/sasc-ng/dvbloopback/module/dvb_loopback.c: Unregistering ca loopback devices Feb 3 20:49:52 home kernel: removing dvblb proc adapter Feb 3 20:49:52 home kernel: dvblb init = 100 Feb 3 20:49:52 home kernel: removing dvblb proc adapter Feb 3 20:49:52 home kernel: dvblb init = 100 Feb 3 20:50:08 home kernel: saa7146: unregister extension 'budget_ci dvb'. Feb 3 20:50:08 home kernel: budget_ci dvb :04:00.0: PCI INT A disabled Feb 3 20:50:09 home kernel: cx8800 :04:02.0: PCI INT A disabled Feb 3 20:50:09 home kernel: cx88/2: unregistering cx8802 driver, type: dvb access: shared Feb 3 20:50:09 home kernel: cx88[0]/2: subsystem: 0070:6902, board: Hauppauge WinTV-HVR4000 DVB-S/S2/T/Hybrid [card=68] Feb 3 20:50:09 home kernel: cx88-mpeg driver manager :04:02.2: PCI INT A disabled Feb 3 20:50:14 home kernel: saa7146: register extension 'budget_ci dvb'. Feb 3 20:50:14 home kernel: budget_ci dvb :04:00.0: PCI INT A - GSI 20 (level, low) - IRQ 20 Feb 3 20:50:14 home kernel: IRQ 20/: IRQF_DISABLED is not guaranteed on shared IRQs Feb 3 20:50:14 home kernel: saa7146: found saa7146 @ mem f9c1c000 (revision 1, irq 20) (0x13c2,0x1017). Feb 3 20:50:14 home kernel: saa7146 (0): dma buffer size 192512 Feb 3 20:50:14 home kernel: DVB: registering new adapter (TT-Budget/S-1500 PCI) Feb 3 20:50:14 home kernel: adapter has MAC addr = 00:d0:5c:07:98:02 Feb 3 20:50:14 home kernel: input: Budget-CI dvb ir receiver saa7146 (0) as /devices/pci:00/:00:1e.0/:04:00.0/input/input6 Feb 3 20:50:14 home kernel: [ cut here ] Feb 3 20:50:14 home kernel: WARNING: at fs/sysfs/dir.c:487 sysfs_add_one+0x92/0xb0() Feb 3 20:50:14 home kernel: Hardware name: EP41-UD3L Feb 3 20:50:14 home kernel: sysfs: cannot create duplicate filename '/devices/virtual/irrcv/irrcv1' Feb 3 20:50:14 home kernel: Modules linked in: budget_ci(+) budget_core ttpci_eeprom saa7146 stv0299 dvb_core lnbp21 rfcomm sco bridge stp bnep l2cap iptable_filter ip_tables x_tables appletalk psnap llc autofs4 nfsd lockd sunrpc exportfs mac80211 cfg80211 btusb bluetooth forcedeth tun snd_pcm_oss snd_mixer_oss usb_storage ohci_hcd it87 hwmon_vid i2c_dev wm8775 tuner_simple tuner_types tda9887 tuner cx88_alsa snd_hda_codec_realtek cx88xx usblp v4l2_common videodev v4l1_compat ir_common i2c_algo_bit snd_hda_intel snd_hda_codec tveeprom nvidia(P) videobuf_dma_sg videobuf_core btcx_risc ir_core snd_pcm snd_timer snd snd_page_alloc ehci_hcd i2c_i801 uhci_hcd i2c_core [last unloaded: dvb_core] Feb 3 20:50:14 home kernel: Pid: 27084, comm: modprobe Tainted: P 2.6.30.10 #17 Feb 3 20:50:14 home kernel: Call Trace: Feb 3 20:50:14 home kernel: [c01c8fe2] ? sysfs_add_one+0x92/0xb0 Feb 3 20:50:14 home kernel: [c01c8fe2] ? sysfs_add_one+0x92/0xb0 Feb 3 20:50:14 home kernel: [c012f2ef] ? warn_slowpath_common+0x6f/0xd0 Feb 3 20:50:15 home kernel: [c01c8fe2] ? sysfs_add_one+0x92/0xb0 Feb 3 20:50:15 home kernel: [c012f39b] ? warn_slowpath_fmt+0x2b/0x30 Feb 3 20:50:15 home kernel: [c01c8fe2] ? sysfs_add_one+0x92/0xb0 Feb 3 20:50:15 home kernel: [c01c9588] ? create_dir+0x48/0x90 Feb 3 20:50:15 home kernel: [c01c95f9] ? sysfs_create_dir+0x29/0x50 Feb 3 20:50:15 home kernel: [c0215282] ? kobject_add_internal+0xc2/0x1b0 Feb 3 20:50:15 home kernel: [c02154fd] ? kobject_add+0x2d/0x60 Feb 3 20:50:15 home kernel: [c0289c07] ? device_add+0xd7/0x570 Feb 3 20:50:15 home kernel: [c0214f0a] ? kobject_init+0x2a/0xa0 Feb 3 20:50:15 home kernel: [c021cdf5] ? kvasprintf+0x45/0x60 Feb 3 20:50:15 home kernel: [c028a159] ? device_create_vargs+0xa9/0xc0 Feb 3 20:50:15 home kernel: [c028a19b] ? device_create+0x2b/0x30 Feb 3 20:50:15 home kernel: [f8933976] ? ir_register_class+0x66/0xd0 [ir_core] Feb 3 20:50:15 home kernel: [f8933275] ? ir_input_register+0x1b5/0x290 [ir_core] Feb 3 20:50:15 home kernel: [f9c39292] ? budget_ci_attach+0x1b2/0xcf0 [budget_ci] Feb 3 20:50:15 home kernel: [f9beeb41] ? saa7146_init_one+0x811/0x8e0 [saa7146] Feb 3 20:50:15 home kernel: [c019895d] ? iput+0x1d/0x50 Feb 3 20:50:15 home kernel: [c01c92aa] ? sysfs_addrm_finish+0x3a/0x200 Feb 3 20:50:15 home kernel: [c01074b0] ? dma_generic_alloc_coherent+0x0/0x110 Feb 3 20:50:15 home kernel: [c01074b0] ? dma_generic_alloc_coherent+0x0/0x110
Re: [PATCH v2 00/10] add linux driver for chip TLG2300
No, I don't meant that.
The differences of FM radio standards are basically the preemphasis and the
frequency ranges.
For frequency ranges, V4L2_TUNER_RADIO allows specifying the maximum/minimum
values.
For preemphasis, you should implement V4L2_CID_TUNE_PREEMPHASIS ctrl. This
CTRL has 3 states:
static const char *tune_preemphasis[] = {
No preemphasis,
50 useconds,
75 useconds,
NULL,
};
At v4l2-common.c, there are some functions that helps to implement it
at the driver, like:
v4l2_ctrl_get_menu, v4l2_ctrl_get_name and v4l2_ctrl_query_fill.
I meet a problem now. :(
Even I add the ctrl to the tlg2300 driver, there is no application to
test it :
[1] The Mplayer do not check the ctrl except the vulume or mute.
[2] I do not know how to use the VLC to listen the radio with ALSA, I
tried many times, but failed. Does someone know this ?
Btw: I will be on my vacation for the following two weeks, I will come
back to
work at 20th of this month. I afraid I can not finish the patches to
remove the
country code in the two days(today and tomorrow).
Take a look at si4713-i2c.c for an example on how to use it.
Ah, please submit those changes as another series of patches. This helps me
to not needing to review the entire changeset again.
Cheers,
Mauro
Best Regards
Huang Shijie
--
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] RFC: mx27: Add soc_camera support
Hi Alan,
On Tue, Dec 15, 2009 at 12:07:43PM -0200, Alan Carvalho de Assis wrote:
Please note: I just get it compiling and loaded correctly on the
mainline kernel.
If you have a board powered by i.MX27 and with a camera supported by
soc_camera driver, I will be glad case you can do a try.
I'm now in the process of making this driver work on i.MX25. The CSI hardware
of the i.MX25 is very similar to the i.MX27 one. If you have any updates for
this driver please let me know.
baruch
--
~. .~ Tk Open Systems
=}ooO--U--Ooo{=
- bar...@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
--
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: DM1105: could not attach frontend 195d:1105
Igor M. Liplianin wrote:
On 3 февраля 2010 00:07:36 Nameer Kazzaz wrote:
Nameer Kazzaz wrote:
Igor M. Liplianin wrote:
On 2 февраля 2010 17:21:46 Nameer Kazzaz wrote:
Hi Igor,
What do you think ? if I can help you solve this, let me know
what I
can do.
Thanks
Nameer
Nameer Kazzaz wrote:
Hi there,
dmesg output with patched dm1105.c against current v4l-dvb 'modprob
dm1105 card=4'
dm1105 :05:0f.0: PCI INT A - GSI 16 (level, low) - IRQ 16
DVB: registering new adapter (dm1105)
dm1105 :05:0f.0: MAC dd49b0dc
dm1105 :05:0f.0: could not attach frontend
dm1105 :05:0f.0: PCI INT A disabled
Thanks
Nameer Kazzaz
Igor M. Liplianin wrote:
On 20 ?? 2010 23:20:20 pau...@planar.id.au wrote:
Igor wrote:
Oh, that is wrong. It is registers addresses, Never touch this.
Let's look on that part of code:
/* GPIO's for LNB power control */
#define DM1105_LNB_MASK 0x //
later in
code write it to
DM1105_GPIOCTR, all GPIO's as OUT
#define DM1105_LNB_OFF 0x0002 //
later in
code write it to
DM1105_GPIOVAL, set GPIO17 to HIGH
But you have not to change this.
Right way is to write another entry in cards structure and so on.
Better leave it to me.
Regards
Igor
Thanks for all your help, I understand better now. I have moved to
code
like that at the bottom. It still doesn't work, but feels a lot
closer.
Before I keep playing with values, I want to check I'm on the right
track.
Does it look right? Specific questions:
1. I see there is a hw_init function. Should I be using that? I
put the
logic into fe_attach because there was already card-specific
logic in
there. But this feels like hw initialisation.
2. Should I set the control to input or output? I'm assuming input
= 1.
3. Would pin 15 be numbered from the left or right - is it 0x4, or
0x2000?
Thanks,
Paul
*** dm1105.c.old2010-01-13 16:15:00.0 +1100
--- dm1105.c2010-01-21 08:13:14.0 +1100
***
*** 51,56
--- 51,57
#define DM1105_BOARD_DVBWORLD_20021
#define DM1105_BOARD_DVBWORLD_20042
#define DM1105_BOARD_AXESS_DM05 3
+ #define DM1105_BOARD_UNBRANDED4
/* --- */
/*
***
*** 171,176
--- 172,181
#define DM05_LNB_13V 0x0002
#define DM05_LNB_18V 0x0003
+ /* GPIO's for demod reset for unbranded 195d:1105 */
+ #define UNBRANDED_DEMOD_MASK 0x8000
+ #define UNBRANDED_DEMOD_RESET 0x8000
+
static unsigned int card[] = {[0 ... 3] = UNSET };
module_param_array(card, int, NULL, 0444);
MODULE_PARM_DESC(card, card type);
***
*** 206,211
--- 211,219
[DM1105_BOARD_AXESS_DM05] = {
.name = Axess/EasyTv DM05,
},
+ [DM1105_BOARD_UNBRANDED] = {
+ .name = Unbranded 195d:1105,
+ },
};
static const struct dm1105_subid dm1105_subids[] = {
***
*** 229,234
--- 237,246
.subvendor = 0x195d,
.subdevice = 0x1105,
.card = DM1105_BOARD_AXESS_DM05,
+ }, {
+ .subvendor = 0x195d,
+ .subdevice = 0x1105,
+ .card = DM1105_BOARD_UNBRANDED,
},
};
***
*** 698,703
--- 710,727
dm1105dvb-fe-ops.set_voltage =
dm1105dvb_set_voltage;
break;
+ case DM1105_BOARD_UNBRANDED:
+ printk(KERN_ERR Attaching as board_unbranded\n);
+ outl(UNBRANDED_DEMOD_MASK,
dm_io_mem(DM1105_GPIOCTR));
+ outl(UNBRANDED_DEMOD_RESET ,
dm_io_mem(DM1105_GPIOVAL));
+ dm1105dvb-fe = dvb_attach(
+ si21xx_attach, serit_config,
+ dm1105dvb-i2c_adap);
+ if (dm1105dvb-fe)
+ dm1105dvb-fe-ops.set_voltage =
+ dm1105dvb_set_voltage;
+
+ break;
case DM1105_BOARD_DVBWORLD_2002:
case DM1105_BOARD_AXESS_DM05:
default:
Some things are missed, like keep GPIO15 high in set_voltage
function.
Try attached patch against current v4l-dvb tree with modprobe option
card=4
modprobe dm1105 card=4
Hi Nameer,
You can modify sended by me patch to guess GPIO pin. Simply try all
of them, it is only 17. Just replace all appearances DM1105_GPIO(15)
with number you want.
Ok I will do that.
Thanks
Nameer
Hi Igor,
I tried all DM1105_GPIO(0) to DM1105_GPIO(17), same error. Any Idea ?
Nameer
Hi
I have some ideas, for example, to add to driver
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
In my understanding the cause of the remote problem is chipset bug which sets
USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
or starts repeating. It is possible to implement remote as polling from the
driver which works very well. But HID problem still remains. I have some
hacks
in my mind to test to kill HID. One is to configure HID wrongly to see if it
stops outputting characters. Other way is try to read remote codes directly
from the chip memory.
Yes, Pekka Sarnila has added this workaround to the HID driver, as the
device is apparently broken.
I want to better understand why others are not hitting this with the
DVB remote driver before removing the quirk from HID code completely.
I think, we should go for a better way. Thanks Pekka for hints, I ended
up with the patch in the attachment. Could you try it whether it works
for you?
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.
Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.
Ideas, comments?
regards,
--
js
diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig
index 139668d..0daf90a 100644
--- a/drivers/hid/Kconfig
+++ b/drivers/hid/Kconfig
@@ -122,6 +122,13 @@ config DRAGONRISE_FF
Say Y here if you want to enable force feedback support for DragonRise Inc.
game controllers.
+config HID_DVB
+ tristate DVB remotes support if EMBEDDED
+ depends on USB_HID
+ default !EMBEDDED
+ ---help---
+ Say Y here if you have DVB remote controllers.
+
config HID_EZKEY
tristate Ezkey if EMBEDDED
depends on USB_HID
diff --git a/drivers/hid/Makefile b/drivers/hid/Makefile
index b62d4b3..a336b2a 100644
--- a/drivers/hid/Makefile
+++ b/drivers/hid/Makefile
@@ -30,6 +30,7 @@ obj-$(CONFIG_HID_CHERRY) += hid-cherry.o
obj-$(CONFIG_HID_CHICONY) += hid-chicony.o
obj-$(CONFIG_HID_CYPRESS) += hid-cypress.o
obj-$(CONFIG_HID_DRAGONRISE) += hid-drff.o
+obj-$(CONFIG_HID_DVB) += hid-dvb.o
obj-$(CONFIG_HID_EZKEY) += hid-ezkey.o
obj-$(CONFIG_HID_GYRATION) += hid-gyration.o
obj-$(CONFIG_HID_KENSINGTON) += hid-kensington.o
diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 2dd9b28..678c553 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -1252,6 +1252,7 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_3M, USB_DEVICE_ID_3M1968) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_WCP32PU) },
{ HID_USB_DEVICE(USB_VENDOR_ID_A4TECH, USB_DEVICE_ID_A4TECH_X5_005D) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_ATV_IRCONTROL) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_IRCONTROL4) },
{ HID_USB_DEVICE(USB_VENDOR_ID_APPLE, USB_DEVICE_ID_APPLE_MIGHTYMOUSE) },
@@ -1310,6 +1311,7 @@ static const struct hid_device_id hid_blacklist[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_KENSINGTON, USB_DEVICE_ID_KS_SLIMBLADE) },
{ HID_USB_DEVICE(USB_VENDOR_ID_KYE, USB_DEVICE_ID_KYE_ERGO_525V) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LABTEC, USB_DEVICE_ID_LABTEC_WIRELESS_KEYBOARD) },
+ { HID_USB_DEVICE(USB_VENDOR_ID_LEADTEK, USB_DEVICE_ID_DTV_GOLD) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_MX3000_RECEIVER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_S510_RECEIVER) },
{ HID_USB_DEVICE(USB_VENDOR_ID_LOGITECH, USB_DEVICE_ID_S510_RECEIVER_2) },
diff --git a/drivers/hid/hid-dvb.c b/drivers/hid/hid-dvb.c
new file mode 100644
index 000..ee94c07
--- /dev/null
+++ b/drivers/hid/hid-dvb.c
@@ -0,0 +1,78 @@
+/*
+ * HID driver for dvb devices
+ *
+ * Copyright (c) 2010 Jiri Slaby
+ *
+ * Licensed under the GPLv2.
+ */
+
+#include linux/device.h
+#include linux/hid.h
+#include linux/module.h
+
+#include hid-ids.h
+
+#define FULLSPEED_INTERVAL 0x1
+
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a key up event */
+ if (value) {
+ input_event(field-hidinput-input, usage-type, usage-code, 1);
+ input_event(field-hidinput-input, usage-type, usage-code, 0);
+ }
+ return 1;
+}
+
+static int dvb_probe(struct hid_device *hdev, const struct hid_device_id *id)
+{
+ unsigned long quirks = id-driver_data;
+ int ret;
+
+ if (quirks FULLSPEED_INTERVAL)
+ hdev-quirks |= HID_QUIRK_FULLSPEED_INTERVAL;
+
+ ret = hid_parse(hdev);
+ if (ret) {
+ dev_err(hdev-dev, parse failed\n);
+ goto end;
+ }
+
+ ret = hid_hw_start(hdev, HID_CONNECT_DEFAULT);
+ if (ret)
+ dev_err(hdev-dev, hw start failed\n);
+end:
+ return ret;
+}
+
+static const struct hid_device_id dvb_devices[] = {
+ { HID_USB_DEVICE(USB_VENDOR_ID_AFATECH, USB_DEVICE_ID_AFATECH_AF9016),
+ .driver_data = FULLSPEED_INTERVAL },
+
[PATCH v2 0/1] mfd: Add support for the timberdale FPGA.
Hi, To follow is the timberdale patch (again), to sort out the merging as pointed out by Mauro and Samuel. --Richard -- 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 v2 1/1] mfd: Add support for the timberdale FPGA.
The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
board
russelville.
The driver is a PCI driver which chunks up the I/O memory and distributes
interrupts
to a number of platform devices for each IP inside the FPGA.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
---
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8782978..f92673b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -348,6 +348,17 @@ config AB4500_CORE
read/write functions for the devices to get access to this chip.
This chip embeds various other multimedia funtionalities as well.
+config MFD_TIMBERDALE
+ tristate Support for the Timberdale FPGA
+ select MFD_CORE
+ depends on PCI
+ ---help---
+ This is the core driver for the timberdale FPGA. This device is a
+ multifunction device which exposes numerous platform devices.
+
+ The timberdale FPGA can be found on the Intel Atom development board
+ for in-vehicle infontainment, called Russellville.
+
endmenu
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e09eb48..53375ac 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -55,4 +55,6 @@ obj-$(CONFIG_AB3100_CORE) += ab3100-core.o
obj-$(CONFIG_AB3100_OTP) += ab3100-otp.o
obj-$(CONFIG_AB4500_CORE)+= ab4500-core.o
obj-$(CONFIG_MFD_88PM8607) += 88pm8607.o
-obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
\ No newline at end of file
+obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
+
+obj-$(CONFIG_MFD_TIMBERDALE) += timberdale.o
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
new file mode 100644
index 000..603cf06
--- /dev/null
+++ b/drivers/mfd/timberdale.c
@@ -0,0 +1,663 @@
+/*
+ * timberdale.c timberdale FPGA MFD driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/mfd/core.h
+
+#include linux/timb_gpio.h
+
+#include linux/i2c.h
+#include linux/i2c-ocores.h
+#include linux/i2c/tsc2007.h
+
+#include linux/spi/spi.h
+#include linux/spi/xilinx_spi.h
+#include linux/spi/max7301.h
+#include linux/spi/mc33880.h
+
+#include timberdale.h
+
+#define DRIVER_NAME timberdale
+
+struct timberdale_device {
+ resource_size_t ctl_mapbase;
+ unsigned char __iomem *ctl_membase;
+ struct {
+ u32 major;
+ u32 minor;
+ u32 config;
+ } fw;
+};
+
+/*--*/
+
+static struct tsc2007_platform_data timberdale_tsc2007_platform_data = {
+ .model = 2003,
+ .x_plate_ohms = 100
+};
+
+static struct i2c_board_info timberdale_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO(tsc2007, 0x48),
+ .platform_data = timberdale_tsc2007_platform_data,
+ .irq = IRQ_TIMBERDALE_TSC_INT
+ },
+};
+
+static __devinitdata struct ocores_i2c_platform_data
+timberdale_ocores_platform_data = {
+ .regstep = 4,
+ .clock_khz = 62500,
+ .devices = timberdale_i2c_board_info,
+ .num_devices = ARRAY_SIZE(timberdale_i2c_board_info)
+};
+
+const static __devinitconst struct resource timberdale_ocores_resources[] = {
+ {
+ .start = OCORESOFFSET,
+ .end= OCORESEND,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_TIMBERDALE_I2C,
+ .end= IRQ_TIMBERDALE_I2C,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+const struct max7301_platform_data timberdale_max7301_platform_data = {
+ .base = 200
+};
+
+const struct mc33880_platform_data timberdale_mc33880_platform_data = {
+ .base = 100
+};
+
+static struct spi_board_info timberdale_spi_16bit_board_info[] = {
+ {
+ .modalias = max7301,
+ .max_speed_hz = 26000,
+ .chip_select = 2,
+ .mode = SPI_MODE_0,
+ .platform_data = timberdale_max7301_platform_data
+ },
+};
+
+static struct spi_board_info timberdale_spi_8bit_board_info[] = {
+ {
+ .modalias = mc33880,
+
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Jiri Slaby wrote:
On 01/26/2010 02:08 PM, Jiri Kosina wrote:
In my understanding the cause of the remote problem is chipset bug which
sets
USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all
or starts repeating. It is possible to implement remote as polling from the
driver which works very well. But HID problem still remains. I have some
hacks
in my mind to test to kill HID. One is to configure HID wrongly to see if it
stops outputting characters. Other way is try to read remote codes directly
from the chip memory.
Yes, Pekka Sarnila has added this workaround to the HID driver, as the
device is apparently broken.
I want to better understand why others are not hitting this with the
DVB remote driver before removing the quirk from HID code completely.
I think, we should go for a better way. Thanks Pekka for hints, I ended
up with the patch in the attachment. Could you try it whether it works
for you?
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.
Module parameters always bothers me. They should be used as last resort
alternatives
when there's no other possible way to make it work properly.
If we know for sure that the RC polling should be disabled by an specific
device,
just add this logic at the driver.
Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.
Ideas, comments?
Please next time, send the patch inlined. As you're using Thunderbird, you'll
likely need
Asalted-patches[1] to avoid thunderbird to destroy your patches.
[1]https://hg.mozilla.org/users/clarkbw_gnome.org/asalted-patches/
+config HID_DVB
+ tristate DVB remotes support if EMBEDDED
+ depends on USB_HID
+ default !EMBEDDED
+ ---help---
+ Say Y here if you have DVB remote controllers.
+
I think the better would be to use a more generic name, like HID_RC (for Remote
Controller).
I suspect we may need in the future other hacks for other similar devices.
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a key up event */
+ if (value) {
+ input_event(field-hidinput-input, usage-type, usage-code,
1);
+ input_event(field-hidinput-input, usage-type, usage-code,
0);
+ }
+ return 1;
+}
Several V4L/DVB IR's have keyup/keydown events. So I think the name here is
also wrong:
it is better to name the function as dvb_nokeyup_event() and eventually add an
specific
quirk to indicate devices that only have key up events.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 00/10] add linux driver for chip TLG2300
Huang Shijie wrote:
No, I don't meant that.
The differences of FM radio standards are basically the preemphasis
and the
frequency ranges.
For frequency ranges, V4L2_TUNER_RADIO allows specifying the
maximum/minimum values.
For preemphasis, you should implement V4L2_CID_TUNE_PREEMPHASIS ctrl.
This
CTRL has 3 states:
static const char *tune_preemphasis[] = {
No preemphasis,
50 useconds,
75 useconds,
NULL,
};
At v4l2-common.c, there are some functions that helps to implement it
at the driver, like:
v4l2_ctrl_get_menu, v4l2_ctrl_get_name and v4l2_ctrl_query_fill.
I meet a problem now. :(
Even I add the ctrl to the tlg2300 driver, there is no application to
test it :
[1] The Mplayer do not check the ctrl except the vulume or mute.
Unfortunately, userspace applications take some time to follow kernel changes.
Yet, there are a few generic applications for it, both hosted together with
the v4l-dvb mercurial tree: v4l2-ctl and qv4l2. On both applications, the
controls are retrieved dynamically. In particular, v4l2-ctl is a command-line
application. So, you may call it when the device is detected (for example, by
udev) or before starting the application.
This is very useful with dumb applications that doesn't give full control over
the device.
For example, I use it on my environment to pre-adjust my webcam to give a
clearer
image, when using on skype, with this script:
export LD_PRELOAD=/usr/lib64/libv4l/v4l1compat.so
v4l2-ctl -cexposure=1000
v4l2-ctl -cwhite_balance=47
export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so
/usr/bin/skype.real $_
[2] I do not know how to use the VLC to listen the radio with ALSA, I
tried many times, but failed. Does someone know this ?
I've no idea. Never tried vlc for radio here.
Btw: I will be on my vacation for the following two weeks, I will come
back to
work at 20th of this month. I afraid I can not finish the patches to
remove the
country code in the two days(today and tomorrow).
-rc7 is about to be released. So, it is late for 2.6.33 cycle.
I think we'll have -rc8 again, as there were several changes at drm/nouveau/x86
arch.
I may be wrong though. Assuming that I did a good guess, we'll have +2 weeks
for the
next merge window. Also, as this is a new driver, if we miss the merge window,
we may
try to submit it for -rc1 or -rc2.
So, providing that, on your return, you focus on it, I think it would be
possible to
have it added for 2.6.34.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2 1/1] mfd: Add support for the timberdale FPGA.
Hi Richard,
On Thu, Feb 04, 2010 at 12:18:52PM +0100, Richard Röjfors wrote:
The timberdale FPGA is found on the Intel in-Vehicle Infotainment reference
board
russelville.
The driver is a PCI driver which chunks up the I/O memory and distributes
interrupts
to a number of platform devices for each IP inside the FPGA.
Signed-off-by: Richard Röjfors richard.rojf...@pelagicore.com
The patch looks fine to me:
Signed-off-by: Samuel Ortiz sa...@linux.intel.com
Cheers,
Samuel.
---
diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index 8782978..f92673b 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -348,6 +348,17 @@ config AB4500_CORE
read/write functions for the devices to get access to this chip.
This chip embeds various other multimedia funtionalities as well.
+config MFD_TIMBERDALE
+ tristate Support for the Timberdale FPGA
+ select MFD_CORE
+ depends on PCI
+ ---help---
+ This is the core driver for the timberdale FPGA. This device is a
+ multifunction device which exposes numerous platform devices.
+
+ The timberdale FPGA can be found on the Intel Atom development board
+ for in-vehicle infontainment, called Russellville.
+
endmenu
menu Multimedia Capabilities Port drivers
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e09eb48..53375ac 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -55,4 +55,6 @@ obj-$(CONFIG_AB3100_CORE) += ab3100-core.o
obj-$(CONFIG_AB3100_OTP) += ab3100-otp.o
obj-$(CONFIG_AB4500_CORE) += ab4500-core.o
obj-$(CONFIG_MFD_88PM8607) += 88pm8607.o
-obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
\ No newline at end of file
+obj-$(CONFIG_PMIC_ADP5520) += adp5520.o
+
+obj-$(CONFIG_MFD_TIMBERDALE) += timberdale.o
diff --git a/drivers/mfd/timberdale.c b/drivers/mfd/timberdale.c
new file mode 100644
index 000..603cf06
--- /dev/null
+++ b/drivers/mfd/timberdale.c
@@ -0,0 +1,663 @@
+/*
+ * timberdale.c timberdale FPGA MFD driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+/* Supports:
+ * Timberdale FPGA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/pci.h
+#include linux/msi.h
+#include linux/mfd/core.h
+
+#include linux/timb_gpio.h
+
+#include linux/i2c.h
+#include linux/i2c-ocores.h
+#include linux/i2c/tsc2007.h
+
+#include linux/spi/spi.h
+#include linux/spi/xilinx_spi.h
+#include linux/spi/max7301.h
+#include linux/spi/mc33880.h
+
+#include timberdale.h
+
+#define DRIVER_NAME timberdale
+
+struct timberdale_device {
+ resource_size_t ctl_mapbase;
+ unsigned char __iomem *ctl_membase;
+ struct {
+ u32 major;
+ u32 minor;
+ u32 config;
+ } fw;
+};
+
+/*--*/
+
+static struct tsc2007_platform_data timberdale_tsc2007_platform_data = {
+ .model = 2003,
+ .x_plate_ohms = 100
+};
+
+static struct i2c_board_info timberdale_i2c_board_info[] = {
+ {
+ I2C_BOARD_INFO(tsc2007, 0x48),
+ .platform_data = timberdale_tsc2007_platform_data,
+ .irq = IRQ_TIMBERDALE_TSC_INT
+ },
+};
+
+static __devinitdata struct ocores_i2c_platform_data
+timberdale_ocores_platform_data = {
+ .regstep = 4,
+ .clock_khz = 62500,
+ .devices = timberdale_i2c_board_info,
+ .num_devices = ARRAY_SIZE(timberdale_i2c_board_info)
+};
+
+const static __devinitconst struct resource timberdale_ocores_resources[] = {
+ {
+ .start = OCORESOFFSET,
+ .end= OCORESEND,
+ .flags = IORESOURCE_MEM,
+ },
+ {
+ .start = IRQ_TIMBERDALE_I2C,
+ .end= IRQ_TIMBERDALE_I2C,
+ .flags = IORESOURCE_IRQ,
+ },
+};
+
+const struct max7301_platform_data timberdale_max7301_platform_data = {
+ .base = 200
+};
+
+const struct mc33880_platform_data timberdale_mc33880_platform_data = {
+ .base = 100
+};
+
+static struct spi_board_info timberdale_spi_16bit_board_info[] = {
+ {
+ .modalias = max7301,
+ .max_speed_hz = 26000,
+ .chip_select = 2,
+ .mode = SPI_MODE_0,
Re: [PATCH] fix memory leak media IR keytable
Hi Yoichi,
Yoichi Yuasa wrote:
Signed-off-by: Yoichi Yuasa yu...@linux-mips.org
---
drivers/media/IR/ir-keytable.c |4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/media/IR/ir-keytable.c b/drivers/media/IR/ir-keytable.c
index b521ed9..44501d9 100644
--- a/drivers/media/IR/ir-keytable.c
+++ b/drivers/media/IR/ir-keytable.c
@@ -422,8 +422,10 @@ int ir_input_register(struct input_dev *input_dev,
ir_dev-rc_tab.size = ir_roundup_tablesize(rc_tab-size);
ir_dev-rc_tab.scan = kzalloc(ir_dev-rc_tab.size *
sizeof(struct ir_scancode), GFP_KERNEL);
- if (!ir_dev-rc_tab.scan)
+ if (!ir_dev-rc_tab.scan) {
+ kfree(ir_dev);
return -ENOMEM;
+ }
Thanks for the patch, but we've received and applied an identical fix at the
development
tree.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.
Module parameters always bothers me. They should be used as last resort
alternatives
when there's no other possible way to make it work properly.
If we know for sure that the RC polling should be disabled by an specific
device,
just add this logic at the driver.
Yes, this is planned and written below:
Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.
Ideas, comments?
Please next time, send the patch inlined. As you're using Thunderbird, you'll
likely need
Asalted-patches[1] to avoid thunderbird to destroy your patches.
I must disagree for two reasons: (a) it was not patch intended for merge
and (b) it was a plain-text attachment which is fine even for
submission. However I don't like patches as attachments so if I decide
to submit it for a merge later, you will not see it as an attachment
then :).
+config HID_DVB
+ tristate DVB remotes support if EMBEDDED
+ depends on USB_HID
+ default !EMBEDDED
+ ---help---
+ Say Y here if you have DVB remote controllers.
+
I think the better would be to use a more generic name, like HID_RC (for
Remote Controller).
I suspect we may need in the future other hacks for other similar devices.
Seconded. I would only go for some other abbreviation other than RC or
not abbreviate that at all.
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a key up event */
+ if (value) {
+ input_event(field-hidinput-input, usage-type, usage-code,
1);
+ input_event(field-hidinput-input, usage-type, usage-code,
0);
+ }
+ return 1;
+}
Several V4L/DVB IR's have keyup/keydown events. So I think the name here is
also wrong:
it is better to name the function as dvb_nokeyup_event() and eventually add
an specific
quirk to indicate devices that only have key up events.
If such appear later, it can be rewritten. I don't plan to add such
functionality now until somebody comes with device IDs which should be
handled that way and tests it, because I guess I will definitely do it
wrong otherwise. Do you know/have such a device?
There are many of quirks needed for various devices. I already wrote
about af9005 which sends key repeat aside from key down etc. But the
same as above, I can't test it (and don't want to introduce
regressions). So again, if somebody can test it, I'll be happy to code it.
thanks for the input,
--
js
--
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: Videotext application crashes the kernel due to DVB-demux patch
On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563492] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb1/1-0:1.0/uevent Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563589] Process alevt (pid: 1780, ti=e7934000 task=e7915be0 task.ti=e7934000) Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563592] Stack: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563622] Call Trace: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8 e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b 46 04 8d 48 f8 8b 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89 50 04 89 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563697] EIP: [f8cec1b2] dvb_demux_release+0x43/0x183 [dvb_core] SS:ESP 0068:e7935f58 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563706] CR2: I don't have a 32 bti machine set up to compile the module and compare the disassembly directly. However, the kernel code above disassembles to this, and is supposedly in dvb_demux_release() but things have been inlined by the compiler: 1c: 8d 56 78lea0x78(%esi),%edx 1f: 89 54 24 04 mov%edx,0x4(%esp) 23: 89 d0 mov%edx,%eax 25: e8 e4 da 4c c8 call 0xc84cdb0e 2a: 89 f0 mov%esi,%eax 2c: e8 31 ff ff ff call 0xff62 (dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here %esi holds dmxdevfilter) 31: 83 7e 4c 01 cmpl $0x1,0x4c(%esi)if (dmxdevfilter-state DMXDEV_STATE_SET) 35: 76 73 jbe0xaa return 0; 37: 83 7e 48 02 cmpl $0x2,0x48(%esi)if (dmxdevfilter-type == DMXDEV_TYPE_PES) 3b: 75 49 jne0x86 (dvb_dmxdev_delete_pids() appears to be inlined starting here %esi still holds dmxdevfilter) 3d: 8b 46 04mov0x4(%esi),%eax %eax gets loaded with dmxdevfilter-feed.ts for list_for_each_entry_safe(feed, tmp, dmxdevfilter-feed.ts, ... 40: 8d 48 f8lea-0x8(%eax),%ecx%ecx is feed and gets loaded with the next struct dmxdev_feed pointed to by the dmxdevfilter-feed.ts list 43: 8b 41 08mov0x8(%ecx),%eax Oops appears to happen here: %ecx and hence feed was (craftily?) set to 0xfff8 based on CR2 above 46: 8d 58 f8lea-0x8(%eax),%ebx 49: 8d 7e 04lea0x4(%esi),%edi 4c: eb 28 jmp0x76 4e: 8b 41 08mov0x8(%ecx),%eax 51: 8b 51 0cmov0xc(%ecx),%edx 54: 89 50 04mov%edx,0x4(%eax) So there is something wrong with the list manipulations or, if needed, locking around the the list manipulations of the list that was introduced in the patch you identified as the problem. That is what is causing the Ooops on close(). It will
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Well the thing is that this device (afatech) offers two different ways to read the remote: vendor class bulk endpoint (0/81, used afatech driver) and HID class interrupt endpoint (1/83, seen as an ordinary usb keyboard by the usb/hid system). When I used unmodified kernel (with new firmware) both of these were used simultaneously. When added afatech to hid blacklist hid of course did not work any more, so only the bulk endpoint was used, and things worked trough afatech driver, nor was the HID FULLSPEED QUIRK needed. The problem using vendor class is that there is no standard. Each vendor can define its own way using endpoints (and has done so e.g Logitech joysticks). Thus each usb ir receiver must have its own specific driver. However then you get the raw ir codes. When using HID class, generic HID driver can do the job. But then you get HID key codes directly not ir codes. Also this should not be seen at all as dvb question. First, not all the world uses dvb standard (including USA) but uses very similar tv-sticks with identical ir receivers and remotes. Second there are many other type of usb devices with ir receiver. So dvb layer should not be involved at all. There maybe would be need for hid-ir-remote layer (your code suggestion moved there). However even there IMHO better would be just to improve HID - input layer interface so that input layer could divert the remotes input to generic remotes layer instead of keyboard layer. IMHO this would be the real linux way. The FULLSPEED thing is really not ir receiver specific problem. It can happen with any device with interrupt endpoint. That's the reason why I placed the quirk to HID driver. However even the HID driver is logically a wrong place. Really it should belong to the usb/endpoint layer because this really is not HID specific problem but usb layer problem (as also Jiri Kosina then pointed out). However linux usb layer has been build so that it was technically impossible to put it there without completely redesigning usb - higher layer (including HID) interface. But I'm of the opinion that that redesign should be done anyway. Even when no quirk is needed interrupt endpoint handling is a usb level task not a hid level (or any other higher level) task. The usb layer should do the interrupt endpoint polling and just put up interrupt events to higher layers. Partly this confusion is due the poor usb/hid specifications. It really should be a device/endpoint-quirk. Now the question is, how much all usb based ir receivers have in common, and how much they differ. This should determine on what level and in which way they should be handled. How much and on what level there should be common code and where device specific driver code would be needed and where and how the ir-to-code translate should take place. IMHO all that have HID endpoint that works (either as such or with some generic quirk) should be handled by HID first and then conveyed to generic remotes layer that handles all remote controllers what ever the lower layers (and does translate per remote not per ir receiver). Vendor class should be avoided unless that's the only way to make it work right. But using HID is not without problems either. Now with the two receivers that need the quirk. If they don't have vendor class bulk endpoint for reading ir codes, then specific driver is out anyway. However then changes to HID driver would be needed to make the translate work. The quirk just makes them work as generic usb keyboard with no remote specific translate. With afatech, driver loads the translate table to the device, different for different remotes. I don't know if one table could handle them all. Maybe this table should be loaded from a user space file. Nor do I know how it is with other receivers: can the table be loaded or is it fixed. In any case a generic secondary per remote user configurable translate would be highly desirable. And I don't mean lircd. This job is IMHO kernel level job and lircd won't work here anyway. It does ir code to key code or function translate not key code to key code translate. How nice it would be if there would be a generic usb ir receiver class that all vendors used. There seems to be no way to make this well and clean. Well it got a bit long, but the problem is not simple either, and it cuts trough many parts (and maintainers) of the kernel. So what to do? Pekka Jiri Slaby wrote: On 01/26/2010 02:08 PM, Jiri Kosina wrote: In my understanding the cause of the remote problem is chipset bug which sets USB2.0 polling interval to 4096ms. Therefore HID remote does not work at all or starts repeating. It is possible to implement remote as polling from the driver which works very well. But HID problem still remains. I have some hacks in my mind to test to kill HID. One is to configure HID wrongly to see if it stops outputting characters. Other way is try to read remote codes directly
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On Thu, 4 Feb 2010, Pekka Sarnila wrote: The FULLSPEED thing is really not ir receiver specific problem. It can happen with any device with interrupt endpoint. That's the reason why I placed the quirk to HID driver. However even the HID driver is logically a wrong place. Really it should belong to the usb/endpoint layer because this really is not HID specific problem but usb layer problem (as also Jiri Kosina then pointed out). However linux usb layer has been build so that it was technically impossible to put it there without completely redesigning usb - higher layer (including HID) interface. But I'm of the opinion that that redesign should be done anyway. Even when no quirk is needed interrupt endpoint handling is a usb level task not a hid level (or any other higher level) task. The usb layer should do the interrupt endpoint polling and just put up interrupt events to higher layers. Partly this confusion is due the poor usb/hid specifications. It really should be a device/endpoint-quirk. Yes, I still think what I have stated before, that this should be properly handled in the USB stack. On the other hand, in usbhid driver we do a lot of USB-specific lower-level things anyway, so it's technically more-or-less OK to apply the quirk there as well (and that's why I have accepted it back then). -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Jiri Slaby wrote:
On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote:
I have 2 dvb-t receivers and both of them need fullspeed quirk. Further
disable_rc_polling (a dvb_usb module parameter) must be set to not get
doubled characters now. And then, it works like a charm.
Module parameters always bothers me. They should be used as last resort
alternatives
when there's no other possible way to make it work properly.
If we know for sure that the RC polling should be disabled by an specific
device,
just add this logic at the driver.
Yes, this is planned and written below:
Ok.
Note that, it's just some kind of proof of concept. A migration of
af9015 devices from dvb-usb-remote needs to be done first.
Ideas, comments?
Please next time, send the patch inlined. As you're using Thunderbird,
you'll likely need
Asalted-patches[1] to avoid thunderbird to destroy your patches.
I must disagree for two reasons: (a) it was not patch intended for merge
and (b) it was a plain-text attachment which is fine even for
submission. However I don't like patches as attachments so if I decide
to submit it for a merge later, you will not see it as an attachment
then :).
Attachments aren't good for reply, as they appear as a file. So, people need to
open the attachment on a separate application to see and to cut-and-paste
if they want to comment, like what I did.
+config HID_DVB
+tristate DVB remotes support if EMBEDDED
+depends on USB_HID
+default !EMBEDDED
+---help---
+Say Y here if you have DVB remote controllers.
+
I think the better would be to use a more generic name, like HID_RC (for
Remote Controller).
I suspect we may need in the future other hacks for other similar devices.
Seconded. I would only go for some other abbreviation other than RC or
not abbreviate that at all.
we're using irrcv at the IR remote class. So, this can be another name for it.
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+struct hid_usage *usage, __s32 value)
+{
+/* we won't get a key up event */
+if (value) {
+input_event(field-hidinput-input, usage-type, usage-code,
1);
+input_event(field-hidinput-input, usage-type, usage-code,
0);
+}
+return 1;
+}
Several V4L/DVB IR's have keyup/keydown events. So I think the name here is
also wrong:
it is better to name the function as dvb_nokeyup_event() and eventually add
an specific
quirk to indicate devices that only have key up events.
If such appear later, it can be rewritten. I don't plan to add such
functionality now until somebody comes with device IDs which should be
handled that way and tests it, because I guess I will definitely do it
wrong otherwise.
Do you know/have such a device?
I have several devices here with different ways to generate keyup/keydown or
keydown/repeat, but they don't export a standard usb HID interface (in a matter
of fact, I have just one PCI device that came with a separate USB HID interface,
but this device always worked fine - also - as it has physically a separate
device -
it doesn't generate any conflict with the DVB hardware).
The point is that it is better to name the function right since the beginning.
There are many of quirks needed for various devices. I already wrote
about af9005 which sends key repeat aside from key down etc. But the
same as above, I can't test it (and don't want to introduce
regressions). So again, if somebody can test it, I'll be happy to code it.
thanks for the input,
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote: The point is that it is better to name the function right since the beginning. Sorry, I misunderstood you for the first time. It's .event member of hid_driver. Hence I named it dvb_event (or now rc_event or whatever). The function may contain decisions on what to do with the event based for example on quirks set up in .probe. And if the function grows later, it may be factored out to rc_nokeyup_event. But rc_event is a root for the decision tree and it should be there forever. Does it make sense now? -- js -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Pekka Sarnila wrote: The problem using vendor class is that there is no standard. Each vendor can define its own way using endpoints (and has done so e.g Logitech joysticks). Thus each usb ir receiver must have its own specific driver. However then you get the raw ir codes. When using HID class, generic HID driver can do the job. But then you get HID key codes directly not ir codes. We started writing an abstraction layer for IR, using the input. The idea is to allow the IR receivers to work with different IR's, as several users prefer to use universal IR's to control their devices, instead of the original one. This is already used by all V4L drivers and I intend to port most of the DVB drivers to use it as well soon. Also this should not be seen at all as dvb question. First, not all the world uses dvb standard (including USA) but uses very similar tv-sticks with identical ir receivers and remotes. Despiste its name, the DVB subsystem is not specific for DVB standards, but it is meant to be used by all DTV standards (and almost all DTV standards are already supported). Second there are many other type of usb devices with ir receiver. So dvb layer should not be involved at all. There maybe would be need for hid-ir-remote layer (your code suggestion moved there). However even there IMHO better would be just to improve HID - input layer interface so that input layer could divert the remotes input to generic remotes layer instead of keyboard layer. IMHO this would be the real linux way. This is already happening. See drivers/media/IR on linux-next for the IR common code. The ir-core is provided by ir-keytable.c and ir-sysfs.c, and it is not DVB or V4L specific. The ir-common module were developed for V4L drivers and will probably be changed into a more generic way, with the integration with lirc. However linux usb layer has been build so that it was technically impossible to put it there without completely redesigning usb - higher layer (including HID) interface. But I'm of the opinion that that redesign should be done anyway. Feel free to submit patches. My plan is to integrate the DVB devices soon into the new ir-core. I should start with dvb-usb-remote, where most of the DVB USB devices use to attach their IR's. Unfortunately, af9015 doesn't rely on the dvb-usb-remote, so, it will require some specific changes. As I don't have any af9015 device, I'll likely postpone it or wait for someone to do the job. Now the question is, how much all usb based ir receivers have in common, and how much they differ. This should determine on what level and in which way they should be handled. How much and on what level there should be common code and where device specific driver code would be needed and where and how the ir-to-code translate should take place. There are several different ways for IR receivers, and, at least for vendor class, no standard way to handle. They can use GPIO polling, they can use i2c layer, they can use IRQ (on PCI devices) and the data may be provided in parallel or on a serial interface. The idea of the ir-core is to provide support for all those options. IMHO all that have HID endpoint that works (either as such or with some generic quirk) should be handled by HID first and then conveyed to generic remotes layer that handles all remote controllers what ever the lower layers (and does translate per remote not per ir receiver). Vendor class should be avoided unless that's the only way to make it work right. But using HID is not without problems either. Almost all chipsets only provide IR via vendor class. I agree that using standard HID class is the better way for doing it. Now with the two receivers that need the quirk. If they don't have vendor class bulk endpoint for reading ir codes, then specific driver is out anyway. However then changes to HID driver would be needed to make the translate work. The quirk just makes them work as generic usb keyboard with no remote specific translate. With afatech, driver loads the translate table to the device, different for different remotes. I don't know if one table could handle them all. Maybe this table should be loaded from a user space file. Nor do I know how it is with other receivers: can the table be loaded or is it fixed. In any case a generic secondary per remote user configurable translate would be highly desirable. And I don't mean lircd. This job is IMHO kernel level job and lircd won't work here anyway. It does ir code to key code or function translate not key code to key code translate. How nice it would be if there would be a generic usb ir receiver class that all vendors used. There seems to be no way to make this well and clean. The ir-core provides standard ways to replace the IR keycode and IR protocols. The IR protocol change is already working with vendor class with em28xx driver. Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Yes, my comment maybe criticizes more the basic architectural structure of usb putting it's own work up to higher layer. The only practical thing is that, if there is a non-HID device suffering from that FULLSPEED problem, the quirk won't help it. Anyway in current kernel structure usb layer doesn't handle endpoint setup at all, thus it simply can not do the job. Pekka Jiri Kosina wrote: Yes, I still think what I have stated before, that this should be properly handled in the USB stack. On the other hand, in usbhid driver we do a lot of USB-specific lower-level things anyway, so it's technically more-or-less OK to apply the quirk there as well (and that's why I have accepted it back then). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Jiri Slaby wrote: On 02/04/2010 02:41 PM, Mauro Carvalho Chehab wrote: The point is that it is better to name the function right since the beginning. Sorry, I misunderstood you for the first time. It's .event member of hid_driver. Hence I named it dvb_event (or now rc_event or whatever). The function may contain decisions on what to do with the event based for example on quirks set up in .probe. And if the function grows later, it may be factored out to rc_nokeyup_event. But rc_event is a root for the decision tree and it should be there forever. Does it make sense now? Ah, ok. Due to the comments at the function, I misunderstood that you were planning to have separate functions for separate quirks. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote: Jiri Slaby wrote: On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote: I have 2 dvb-t receivers and both of them need fullspeed quirk. Further disable_rc_polling (a dvb_usb module parameter) must be set to not get doubled characters now. And then, it works like a charm. Module parameters always bothers me. They should be used as last resort alternatives when there's no other possible way to make it work properly. If we know for sure that the RC polling should be disabled by an specific device, just add this logic at the driver. Yes, this is planned and written below: Ok. Note that, it's just some kind of proof of concept. A migration of af9015 devices from dvb-usb-remote needs to be done first. Ideas, comments? Please next time, send the patch inlined. As you're using Thunderbird, you'll likely need Asalted-patches[1] to avoid thunderbird to destroy your patches. I must disagree for two reasons: (a) it was not patch intended for merge and (b) it was a plain-text attachment which is fine even for submission. However I don't like patches as attachments so if I decide to submit it for a merge later, you will not see it as an attachment then :). Attachments aren't good for reply, as they appear as a file. So, people need to open the attachment on a separate application to see and to cut-and-paste if they want to comment, like what I did. Just as an FYI... If you use mutt appropriately configured, it'll DTRT with attached patches and let you reply with them quoted inline, and actually, thunderbird 3 will more or less work with attached patches if you do a select-all, then hit reply (tbird finally has 'quote selected text' support). Not that I'm advocating patches as attachments. -- Jarod Wilson ja...@redhat.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Videotext application crashes the kernel due to DVB-demux patch
Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563492] last sysfs file: /sys/devices/pci:00/:00:1d.7/usb1/1-0:1.0/uevent Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563589] Process alevt (pid: 1780, ti=e7934000 task=e7915be0 task.ti=e7934000) Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563592] Stack: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563622] Call Trace: Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563650] Code: f2 da 4c c8 8d 56 78 89 54 24 04 89 d0 e8 e4 da 4c c8 89 f0 e8 31 ff ff ff 83 7e 4c 01 76 73 83 7e 48 02 75 49 8b 46 04 8d 48 f8 8b 41 08 8d 58 f8 8d 7e 04 eb 28 8b 41 08 8b 51 0c 89 50 04 89 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563697] EIP: [f8cec1b2] dvb_demux_release+0x43/0x183 [dvb_core] SS:ESP 0068:e7935f58 Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563706] CR2: I don't have a 32 bti machine set up to compile the module and compare the disassembly directly. However, the kernel code above disassembles to this, and is supposedly in dvb_demux_release() but things have been inlined by the compiler: 1c: 8d 56 78lea0x78(%esi),%edx 1f: 89 54 24 04 mov%edx,0x4(%esp) 23: 89 d0 mov%edx,%eax 25: e8 e4 da 4c c8 call 0xc84cdb0e 2a: 89 f0 mov%esi,%eax 2c: e8 31 ff ff ff call 0xff62 (dmxdev.c:dvb_dmxdev_filter_reset() appears to be inlined starting here %esi holds dmxdevfilter) 31: 83 7e 4c 01 cmpl $0x1,0x4c(%esi)if (dmxdevfilter-state DMXDEV_STATE_SET) 35: 76 73 jbe0xaa return 0; 37: 83 7e 48 02 cmpl $0x2,0x48(%esi)if (dmxdevfilter-type == DMXDEV_TYPE_PES) 3b: 75 49 jne0x86 (dvb_dmxdev_delete_pids() appears to be inlined starting here %esi still holds dmxdevfilter) 3d: 8b 46 04mov0x4(%esi),%eax %eax gets loaded with dmxdevfilter-feed.ts for list_for_each_entry_safe(feed, tmp, dmxdevfilter-feed.ts, ... 40: 8d 48 f8lea-0x8(%eax),%ecx%ecx is feed and gets loaded with the next struct dmxdev_feed pointed to by the dmxdevfilter-feed.ts list 43: 8b 41 08mov0x8(%ecx),%eax Oops appears to happen here: %ecx and hence feed was (craftily?) set to 0xfff8 based on CR2 above 46: 8d 58 f8lea-0x8(%eax),%ebx 49: 8d 7e 04lea0x4(%esi),%edi 4c: eb 28 jmp0x76 4e: 8b 41 08mov0x8(%ecx),%eax 51: 8b 51 0cmov0xc(%ecx),%edx 54: 89 50 04mov%edx,0x4(%eax) So there is something wrong with the list manipulations or, if needed, locking around the
Re: omap34xxcam question?
Hi Michael, Michael Trimarchi wrote: Aguirre, Sergio wrote: ... So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) Apologies for my late answer. The frame sizes in our sensor drivers are in width descending order. The selection has been working somehow so far but it's definitely not perfect. We're converting the ISP driver to use the Media controller so this code will be dropped in near future probably. In that case the user space has to select the sensor mode it wants to use as well. Regular V4L2 applications of course cannot be expected to do that. But it probably should be handled in user space (i.e. libv4l) or by offering a dummy video node that just produces some kind of images. -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Jarod Wilson wrote: On 02/04/2010 08:41 AM, Mauro Carvalho Chehab wrote: Jiri Slaby wrote: On 02/04/2010 01:04 PM, Mauro Carvalho Chehab wrote: I have 2 dvb-t receivers and both of them need fullspeed quirk. Further disable_rc_polling (a dvb_usb module parameter) must be set to not get doubled characters now. And then, it works like a charm. Module parameters always bothers me. They should be used as last resort alternatives when there's no other possible way to make it work properly. If we know for sure that the RC polling should be disabled by an specific device, just add this logic at the driver. Yes, this is planned and written below: Ok. Note that, it's just some kind of proof of concept. A migration of af9015 devices from dvb-usb-remote needs to be done first. Ideas, comments? Please next time, send the patch inlined. As you're using Thunderbird, you'll likely need Asalted-patches[1] to avoid thunderbird to destroy your patches. I must disagree for two reasons: (a) it was not patch intended for merge and (b) it was a plain-text attachment which is fine even for submission. However I don't like patches as attachments so if I decide to submit it for a merge later, you will not see it as an attachment then :). Attachments aren't good for reply, as they appear as a file. So, people need to open the attachment on a separate application to see and to cut-and-paste if they want to comment, like what I did. Just as an FYI... If you use mutt appropriately configured, it'll DTRT with attached patches and let you reply with them quoted inline, and actually, thunderbird 3 will more or less work with attached patches if you do a select-all, then hit reply (tbird finally has 'quote selected text' support). RHEL5 has Thunderbird 2, so, quote selected text doesn't work. I don't like very much to use text mailers, but i prefer the alpine interface. I never saw this feature in alpine. Maybe I just never managed to properly configure it there. Claws-mail has this feature, its monothread/monotask structure is very bad, since it stops answering to the edit window, if it starts to fetch new emails while you're editing an email. So, I stopped using it. -- Cheers, Mauro -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Mauro Carvalho Chehab wrote: Pekka Sarnila wrote: The problem using vendor class is that there is no standard. Each vendor can define its own way using endpoints (and has done so e.g Logitech joysticks). Thus each usb ir receiver must have its own specific driver. However then you get the raw ir codes. When using HID class, generic HID driver can do the job. But then you get HID key codes directly not ir codes. We started writing an abstraction layer for IR, using the input. The idea is to allow the IR receivers to work with different IR's, as several users prefer to use universal IR's to control their devices, instead of the original one. This is already used by all V4L drivers and I intend to port most of the DVB drivers to use it as well soon. This is very good. The problem here is that at least afatech ir receiver has the ir code to key code build in, so trough HID you can use only the remote whose ir to key translate table has been loaded to the aftech device. Unless that can be easily controlled by the user HID is no good for this. Also this should not be seen at all as dvb question. First, not all the world uses dvb standard (including USA) but uses very similar tv-sticks with identical ir receivers and remotes. Despiste its name, the DVB subsystem is not specific for DVB standards, but it is meant to be used by all DTV standards (and almost all DTV standards are already supported). But most of the world still uses analog (they can not afford yet the transfer). Those tv-sticks have identical receivers. And there are usb ir receivers not embedded to tv-sticks. Conceptually and technically it has nothing to do with any tv or any other audiovisual system system (e.g. a remote controlled weather station). So dvb is both as a place and a name misleading. Second there are many other type of usb devices with ir receiver. So dvb layer should not be involved at all. There maybe would be need for hid-ir-remote layer (your code suggestion moved there). However even there IMHO better would be just to improve HID - input layer interface so that input layer could divert the remotes input to generic remotes layer instead of keyboard layer. IMHO this would be the real linux way. This is already happening. See drivers/media/IR on linux-next for the IR common code. The ir-core is provided by ir-keytable.c and ir-sysfs.c, and it is not DVB or V4L specific. Well I was talking about HID remotes that don't give ir codes but key codes. What to do with them? The ir-common module were developed for V4L drivers and will probably be changed into a more generic way, with the integration with lirc. However linux usb layer has been build so that it was technically impossible to put it there without completely redesigning usb - higher layer (including HID) interface. But I'm of the opinion that that redesign should be done anyway. Feel free to submit patches. My plan is to integrate the DVB devices soon Yes, I have thought of it. But it is a big job, I'm quite busy, and after all mostly the benefit is more esthetical than practical. A lot of other usb strandard and vendor class interrupt endpoint drivers beside HID should be rewritten. Writing new ones would be easier though. into the new ir-core. I should start with dvb-usb-remote, where most of the DVB USB devices use to attach their IR's. Unfortunately, af9015 doesn't rely on the dvb-usb-remote, so, it will require some specific changes. As I don't have any af9015 device, I'll likely postpone it or wait for someone to do the job. Well that was the original point of my involvement. It can support both the dvb-usb-remote and HID. The problem with af9015/dvb-usb-remote is that it uses usb vendor class endpoint (all trough I have used 'vendor class' to specifically mean usb vendor class). Usb vendor classes have no standard. But af9015 can also use USB HID class (remote as keyboard) in a standard manner. That would avoid using special device based driver. Now the question is, how much all usb based ir receivers have in common, and how much they differ. This should determine on what level and in which way they should be handled. How much and on what level there should be common code and where device specific driver code would be needed and where and how the ir-to-code translate should take place. There are several different ways for IR receivers, and, at least for vendor class, no standard way to handle. They can use GPIO polling, they can use i2c layer, they can use IRQ (on PCI devices) and the data may be provided in parallel or on a serial interface. Well the thing is that even with usb each device can have non standard user vendor endpoint. In case of af9015 it can provide the ir code. The idea of the ir-core is to provide support for all those options. Even for those that do provide key codes trough standard HID layer instead of ir codes trough specific device drivers? IMHO all that have HID
Re: omap34xxcam question?
Hi, Sakari Ailus wrote: Hi Michael, Michael Trimarchi wrote: Aguirre, Sergio wrote: ... So, if I got you right, you're saying that, there should be priorities for sensor baseformats, depending on the preference specified somewhere in the boardfile? Yes, that is the idea. Try to provide a better patch later, I'm working hard on the sensor part :) Apologies for my late answer. No problem on that The frame sizes in our sensor drivers are in width descending order. The selection has been working somehow so far but it's definitely not perfect. Ok for the frame size but you need to test all the possible sensor output too and continue in case of error. We're converting the ISP driver to use the Media controller so this code will be dropped in near future probably. In that case the user space has to select the sensor mode it wants to use as well. Good. Maybe I can test the framework on the FLOW1.5 mobile device using the TCM8240MD What is your git for the camera framework? Michael -- 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: Any saa711x users out there?
On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls awa...@radix.net wrote: With all that said, if you have a baseband Luma or Chroma signal with strong spurious high frequency components (crappy source, or you're overdriving the front end and getting intermods), then keep the anti-alias filter turned on as the assumption of a bandlimited input signal is violated in this case. In this case, I'm seeing it with both the analog signal generator (which one might consider a fairly pristine source), as well coming off the s-video output of a DirectTV box (in which case the signal is being generated only a few feet away from the saa7113). In the SAA7113 the anti-alias filter introduces a delay of 50 ns. At 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of delay. Just turn it on in and leave it on in the SAA7113 to handle the unexpected input signal case. This would be my vote (assuming we try it with the other parts and confirm no regressions are introduced). My only concern is the way the code is currently written, the saa7113 initialization block actually does enable it by default, and then some code for the saa7115 tramples the register, turning it off (see saa7115_init_misc at saa7115.c:600). I think the decision we have to make is which of the following paths to take: 1. Enable it in the saa7115_init_misc, thereby enabling it for the 7113, 7114, and 7115. 2. Exclude the saa7115_init_misc block from being run at all against the 7113 3. Let the saa7115_init_misc block get run, and then flip the bit back for the 7113. My thinking at this point is that the AA filter should probably be on by default regardless of the chip, in which case we would just need to make the one line change to enable it in the saa7115_init_misc block. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
Pekka Sarnila wrote: The problem here is that at least afatech ir receiver has the ir code to key code build in, so trough HID you can use only the remote whose ir to key translate table has been loaded to the aftech device. Unless that can be easily controlled by the user HID is no good for this. The ir-core allows a driver to start with a built in table, that can be dynamically replaced in userspace by a different table, and even with a different protocol, if supported by the driver/device. But most of the world still uses analog (they can not afford yet the transfer). Those tv-sticks have identical receivers. And there are usb ir receivers not embedded to tv-sticks. Conceptually and technically it has nothing to do with any tv or any other audiovisual system system (e.g. a remote controlled weather station). So dvb is both as a place and a name misleading. It happens that almost all tv products (analog or digital) come with some IR support. But you can find also some products that are just IR. That's why we're moving it to be outside the V4L and the DVB directory. For now, it is at /drivers/media/IR (since it helps us to move the code, while there are still some dependencies at ir-common). But the better is to move it later to /drivers/IR or /drivers/input/IR. See drivers/media/IR on linux-next for the IR common code. The ir-core is provided by ir-keytable.c and ir-sysfs.c, and it is not DVB or V4L specific. Well I was talking about HID remotes that don't give ir codes but key codes. What to do with them? What happens if you use it to receive keycodes from a different IR using the same protocol? Maybe it can still be valid to keep allowing keycode translation. As I don't have any af9015 device, I'll likely postpone it or wait for someone to do the job. Well that was the original point of my involvement. It can support both the dvb-usb-remote and HID. The problem with af9015/dvb-usb-remote is that it uses usb vendor class endpoint (all trough I have used 'vendor class' to specifically mean usb vendor class). Usb vendor classes have no standard. But af9015 can also use USB HID class (remote as keyboard) in a standard manner. That would avoid using special device based driver. Well, as HID, you may loose the capability of using a different IR than the one shipped with the af9015. It may make sense to just disable HID and use USB Vendor Class. Well the thing is that even with usb each device can have non standard user vendor endpoint. In case of af9015 it can provide the ir code. It doesn't matter how the IR code is get, kernel needs to translate it into a linux key. That's where the ir-core enters: instead of registering the device directly at input event, the driver registers via ir_input_register(): int ir_input_register(struct input_dev *input_dev, const struct ir_scancode_table *rc_tab, const struct ir_dev_props *props) The arguments are the input device, the keycode-scancode table and an optional argument that specifies the IR supported protocols, and a callback function to be called when a different protocol is requested. The IR subsystem will do a dynamic allocation for the keytable and will take care of EVIOCGKEY/EVIOCSKEY events. It will increase/decrease the keytable size if needed. This way, userspace may replace the scancode/keycode table and even the IR protocol, without needing to add any specific code at the driver. It will also create some sysfs nodes that will help udev to identify when a new IR device driver is loaded, allowing the keycode replacement during device hotplug. The only needed change, at the driver, is to replace input_register_device/input_unregister_device by ir_input_register/ir_input_unregister. The idea of the ir-core is to provide support for all those options. Even for those that do provide key codes trough standard HID layer instead of ir codes trough specific device drivers? It basically depends on what the HID layer receives from the IR. Yet, it is possible to use the ir-core layer in order to use an IR keycode to produce a different code. It is not always clear what certain remote keys are supposed to do. For example, should the POWER key turn off the PC, or just quit the application? The ir-core provides standard ways to replace the IR keycode and IR protocols. The IR protocol change is already working with vendor class with em28xx driver. The thing is that remote controller trough HID layer does not provide IR keycode but standard keyboard key code. And HID layer does not know that it is a remote controller but sees it as an ordinary usb keyboard. The question is that how can it tell the upper layer that it really is a remote controller so that the event would end up to generic ir-core. For HID remote controllers, the only way I see is to have an USB ID list of devices that are known to be remote controllers and register them via
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a key up event */
+ if (value) {
+ input_event(field-hidinput-input, usage-type, usage-code,
1);
+ input_event(field-hidinput-input, usage-type, usage-code,
0);
Do not ever forget input_sync(), you need 2 of them here.
With the latest changes to evdev, if you are using SIGIO you won't get
wioken up until EV_SYN/SYN_REPORT.
--
Dmitry
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+struct hid_usage *usage, __s32 value)
+{
+/* we won't get a key up event */
+if (value) {
+input_event(field-hidinput-input, usage-type, usage-code,
1);
+input_event(field-hidinput-input, usage-type, usage-code,
0);
Do not ever forget input_sync(), you need 2 of them here.
With the latest changes to evdev, if you are using SIGIO you won't get
wioken up until EV_SYN/SYN_REPORT.
HID layer syncs on its own. So the second is not needed. Why is needed
the first?
I.e. should there be one also in dvb_usb_read_remote_control?
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] media: dvb-usb/af9015, fix disconnection crashes
On Thu, Feb 04, 2010 at 07:33:22PM +0100, Jiri Slaby wrote:
On 02/04/2010 07:14 PM, Dmitry Torokhov wrote:
On Thu, Feb 04, 2010 at 11:31:45AM +0100, Jiri Slaby wrote:
+
+static int dvb_event(struct hid_device *hdev, struct hid_field *field,
+ struct hid_usage *usage, __s32 value)
+{
+ /* we won't get a key up event */
+ if (value) {
+ input_event(field-hidinput-input, usage-type, usage-code,
1);
+ input_event(field-hidinput-input, usage-type, usage-code,
0);
Do not ever forget input_sync(), you need 2 of them here.
With the latest changes to evdev, if you are using SIGIO you won't get
wioken up until EV_SYN/SYN_REPORT.
HID layer syncs on its own. So the second is not needed. Why is needed
the first?
Userpsace has a right to accumulate events and only act on them when
receiving EV_SYN. Press + release in the same event block may be treated
as no change. The same as REL_X +2, REL_X -2 - no need to move pointer at
all. And so on.
I.e. should there be one also in dvb_usb_read_remote_control?
Probably, I have not looked.
--
Dmitry
--
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: ivtv-utils/test/ps-analyzer.cpp: error in extracting SCR?
Am 04.02.2010 08:25, schrieb Hans Verkuil: On Thursday 04 February 2010 04:16:03 Andy Walls wrote: On Thu, 2010-02-04 at 01:18 +0100, Lars Hanisch wrote: Hi, I'm writing some code repacking the program stream that ivtv delivers into a transport stream (BTW: is there existing code for this?). Buy a CX23418 based board. That chip's firmware can produce a TS. I think Compro and LeadTek cards are available in Europe and are supported by the cx18 driver. My PVR150 and 350 are still ok and I hope I have DVB-S-access in one or two years... But I will keep that in mind in case I need a new card. Since many players needs the PCR I would like to use the SCR of the PS and place it in the adaption field of the TS (if wikipedia [1] and my interpretation of it is correct it should be the same). I stumbled upon the ps-analyzer.cpp in the test-directory of the ivtv-utils (1.4.0). From line 190 to 198 the SCR and SCR extension are extracted from the PS-header. But referring to [2] the SCR extension has 9 bits, the highest 2 bits in the fifth byte after the sync bytes and the lower 7 bits in the sixth byte. The last bit is a marker bit (always 1). So instead of scr_ext = (hdr[4] 0x1) 8; scr_ext |= hdr[5]; I think it should be scr_ext = (unsigned)(hdr[4] 0x3) 7; scr_ext |= (hdr[5] 0xfe) 1; Given the non-authoritative MPEG-2 documents I have, yes, you appear to be correct on this. Please keep in mind that ps-analyzer.cpp is simply a debug tool from an ivtv developer perspective. You base prodcution software off of it at your own risk. :) Of course I will. :-) I already had coded my part and was looking for references... And the bitrate is coded in the next 22 bits, so it should be mux_rate = (unsigned)(hdr[6]) 14; mux_rate |= (unsigned)(hdr[7]) 6; mux_rate |= (unsigned)(hdr[8] 0xfc) 2; Am I correct? Yes, you are correct. I miscounted the bits when I wrote this originally. Thanks for reporting this! You're welcome! Regards, Lars. Regards, Hans I did not check this one, but I would not be surprised if ps-analyzer had this wrong too. Regards, Andy Regards, Lars. [1] http://en.wikipedia.org/wiki/Presentation_time_stamp [2] http://en.wikipedia.org/wiki/MPEG_program_stream -- -- 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Thu Feb 4 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14138:8b2925e0c59f gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-rc5-armv5-davinci: OK linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-rc5-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-rc5-armv5-omap2: OK linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.20-i686: ERRORS linux-2.6.26.8-i686: ERRORS linux-2.6.27.44-i686: ERRORS linux-2.6.28.10-i686: ERRORS linux-2.6.29.1-i686: ERRORS linux-2.6.30.10-i686: OK linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-rc5-i686: OK linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: OK linux-2.6.33-rc5-mips: OK linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-rc5-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.20-x86_64: ERRORS linux-2.6.26.8-x86_64: ERRORS linux-2.6.27.44-x86_64: ERRORS linux-2.6.28.10-x86_64: ERRORS linux-2.6.29.1-x86_64: ERRORS linux-2.6.30.10-x86_64: OK linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-rc5-x86_64: OK spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The 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: How can I add IR remote to this new device (DIKOM DK300)?
Mauro Carvalho Chehab ha scritto: andrea.amoros...@gmail.com wrote: Mauro Carvalho Chehab ha scritto: andrea.amoros...@gmail.com wrote: So since it is necessary to create a new entry, is there any rules to follow to choose it? Just use the existing entry as an example. You'll need to put your card name at the entry, and add a new #define at em28xx.h. Cheers, Mauro Ok! As far as the auto detection issue is concerned, can I add the EEPROM ID and hash so that to use such data to detect the DIKOM device? I've seen that the same numbers are not present for other devices, so I think adding them should not create problems with other devices, but I'm not sure regard that. Yes, but the code will need to be changed a little bit, since the eeprom id detection happens only for some specific usb id's. Cheers, Mauro Hi Mauro, since I was not able to have my remote controller working (maybe it does not work at all), I've send a new version of the patch which should solve all the issue you pointed by creating a new entry and using the eeprom id to detect the card. That patch still does not appear in patchwork. Can you have a look at it, please? I've send it yesterday with this object [PATCH] em28xx: add Dikom DK300 hybrid USB tuner which is clearer than this mail one. Thank you, Andrea -- 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] soc-camera: add runtime pm support for subdevices
To save power soc-camera powers subdevices down, when they are not in use,
if this is supported by the platform. However, the V4L standard dictates,
that video nodes shall preserve configuration between uses. This requires
runtime power management, which is implemented by this patch. It allows
subdevice drivers to specify their runtime power-management methods, by
assigning a type to the video device.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Please review, whether this use of the video device doesn't contradict any
V4L assumptions. Also notice, that it is planned to later use a reference
to the video device in subdevice, when one becomes available. Shortly I'll
post a dummy example implementation for the mt9v022 sensor.
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 6b3fbcc..53201f3 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -24,6 +24,7 @@
#include linux/mutex.h
#include linux/module.h
#include linux/platform_device.h
+#include linux/pm_runtime.h
#include linux/vmalloc.h
#include media/soc_camera.h
@@ -387,6 +388,11 @@ static int soc_camera_open(struct file *file)
goto eiciadd;
}
+ pm_runtime_enable(icd-vdev-dev);
+ ret = pm_runtime_resume(icd-vdev-dev);
+ if (ret 0 ret != -ENOSYS)
+ goto eresume;
+
/*
* Try to configure with default parameters. Notice: this is the
* very first open, so, we cannot race against other calls,
@@ -408,10 +414,12 @@ static int soc_camera_open(struct file *file)
return 0;
/*
-* First five errors are entered with the .video_lock held
+* First four errors are entered with the .video_lock held
* and use_count == 1
*/
esfmt:
+ pm_runtime_disable(icd-vdev-dev);
+eresume:
ici-ops-remove(icd);
eiciadd:
if (icl-power)
@@ -436,7 +444,11 @@ static int soc_camera_close(struct file *file)
if (!icd-use_count) {
struct soc_camera_link *icl = to_soc_camera_link(icd);
+ pm_runtime_suspend(icd-vdev-dev);
+ pm_runtime_disable(icd-vdev-dev);
+
ici-ops-remove(icd);
+
if (icl-power)
icl-power(icd-pdev, 0);
}
@@ -1294,6 +1306,7 @@ static int video_dev_create(struct soc_camera_device *icd)
*/
static int soc_camera_video_start(struct soc_camera_device *icd)
{
+ struct device_type *type = icd-vdev-dev.type;
int ret;
if (!icd-dev.parent)
@@ -1310,6 +1323,9 @@ static int soc_camera_video_start(struct
soc_camera_device *icd)
return ret;
}
+ /* Restore device type, possibly set by the subdevice driver */
+ icd-vdev-dev.type = type;
+
return 0;
}
diff --git a/include/media/soc_camera.h b/include/media/soc_camera.h
index dcc5b86..58b39a9 100644
--- a/include/media/soc_camera.h
+++ b/include/media/soc_camera.h
@@ -282,4 +282,12 @@ static inline void soc_camera_limit_side(unsigned int
*start,
extern unsigned long soc_camera_apply_sensor_flags(struct soc_camera_link *icl,
unsigned long flags);
+/* This is only temporary here - until v4l2-subdev begins to link to
video_device */
+#include linux/i2c.h
+static inline struct video_device *soc_camera_i2c_to_vdev(struct i2c_client
*client)
+{
+ struct soc_camera_device *icd = client-dev.platform_data;
+ return icd-vdev;
+}
+
#endif
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] MT9T031: write xskip and yskip at each set_params call
(added two more persons to CC, because I think, this discussion can be
interesting for them too)
On Thu, 21 Jan 2010, Valentin Longchamp wrote:
Guennadi Liakhovetski wrote:
On Wed, 20 Jan 2010, Valentin Longchamp wrote:
This prevents the registers to be different to the computed values
the second time you open the same camera with the sames parameters.
The images were different between the first device open and the
second one with the same parameters.
But why they were different? Weren't xskip and yskip preserved from the
previous S_CROP / S_FMT configuration? If so, then, I am afraid, this is the
behaviour, mandated by the API, and as such shall not be changed. Or have I
misunderstood you?
Here are more details about what I debugged:
Sorry for taking so long to reply.
First more details about what I do with the camera: I open the device, issue
the S_CROP / S_FMT calls and read images, the behaviour is fine, then close
the device.
Then if I reopen the device, reissue the S_CROP / S_FMT calls with the same
params, but the images is not the sames because of different xskip and yskip.
From what I have debugged in the driver at the second S_CROP /S_FMT, xskip and
yskip are computed by mt9t031_skip (and have the same value that the one
stored in the mt9t031 struct) and thus with the current code are not
rewritten.
However, if I read the register values containing bin and skip values on the
camera chip they have been reset (does a open/close do some reset to the cam
?) and thus different than the ones that should be written.
Yes, if hooks are provided by the platform, on last close we power down
cameras, on first open we power on and reset them.
I hope this clarifies the problem that I am experiencing. I don't think that
the API wants you to get two different images when you open the device and
issue the same parameters twice.
Yes, sorry, this is a different issue. The issue is - too crude power
management in soc-camera. What we should do is implement proper (runtime)
power-management in soc-camera (ideally, in v4l2-subdev API) and call
suspend() to save registers before powering down, and resume() after
powering on and resetting.
I gave it a shot and just posted a patch
http://thread.gmane.org/gmane.linux.drivers.video-input-infrastructure/15686
(hm, would have been smart to cc you, sorry), doing just that. Below is an
example dummy implementation for mt9v022. Please, use it as example to
implement suspend / resume for mt9t031, for now, I think, it would suffice
if you just restore xskip and yskip in restore and skip suspend. If more
is needed in the future, we can always extend it.
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
[PATCH] soc-camera: DUMMY runtime power-management for mt9v022 (not for
mainline)
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
diff --git a/drivers/media/video/mt9v022.c b/drivers/media/video/mt9v022.c
index 1a34d29..08a3478 100644
--- a/drivers/media/video/mt9v022.c
+++ b/drivers/media/video/mt9v022.c
@@ -8,15 +8,17 @@
* published by the Free Software Foundation.
*/
-#include linux/videodev2.h
-#include linux/slab.h
-#include linux/i2c.h
#include linux/delay.h
+#include linux/device.h
+#include linux/i2c.h
#include linux/log2.h
+#include linux/pm.h
+#include linux/slab.h
+#include linux/videodev2.h
-#include media/v4l2-subdev.h
-#include media/v4l2-chip-ident.h
#include media/soc_camera.h
+#include media/v4l2-chip-ident.h
+#include media/v4l2-subdev.h
/*
* mt9v022 i2c address 0x48, 0x4c, 0x58, 0x5c
@@ -718,6 +720,28 @@ static int mt9v022_s_ctrl(struct v4l2_subdev *sd, struct
v4l2_control *ctrl)
return 0;
}
+static int mt9v022_runtime_suspend(struct device *dev)
+{
+ dev_info(dev, %s\n, __func__);
+ return 0;
+}
+
+static int mt9v022_runtime_resume(struct device *dev)
+{
+ dev_info(dev, %s\n, __func__);
+ return 0;
+}
+
+static struct dev_pm_ops mt9v022_dev_pm_ops = {
+ .runtime_suspend= mt9v022_runtime_suspend,
+ .runtime_resume = mt9v022_runtime_resume,
+};
+
+static struct device_type mt9v022_dev_type = {
+ .name = MT9V022,
+ .pm = mt9v022_dev_pm_ops,
+};
+
/*
* Interface active, can use i2c. If it fails, it can indeed mean, that
* this wasn't our capture interface, so, we wait for the right one
@@ -727,6 +751,7 @@ static int mt9v022_video_probe(struct soc_camera_device
*icd,
{
struct mt9v022 *mt9v022 = to_mt9v022(client);
struct soc_camera_link *icl = to_soc_camera_link(icd);
+ struct video_device *vdev = soc_camera_i2c_to_vdev(client);
s32 data;
int ret;
unsigned long flags;
@@ -803,6 +828,8 @@ static int mt9v022_video_probe(struct soc_camera_device
*icd,
ret = mt9v022_init(client);
if (ret 0)
dev_err(client-dev,
Re: [PATCH 14/15] - zl10353
Am 04.02.2010 03:43, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
Am 03.02.2010 21:49, schrieb Devin Heitmueller:
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de
wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/dvb/frontends/zl10353.h
+++ b/drivers/media/dvb/frontends/zl10353.h
@@ -45,6 +45,8 @@ struct zl10353_config
/* clock control registers (0x51-0x54) */
u8 clock_ctl_1; /* default: 0x46 */
u8 pll_0;/* default: 0x15 */
+
+ int tm6000:1;
};
Why is this being submitted as its own patch? It is code that is not
used by *anything*. If you really did require a new field in the
zl10353 config, that field should be added in the same patch as
whatever requires it.
Devin
Hi Stefan,
Due to the problem with your emailer, most of the patches failed:
2/15 3/15 4/15 5/15 6/15 7/15 2/15 (the second one 8th in the sequence)
9/15 11/15 12/15 13/15 and 15/15.
In brief, only two patches applied: the 1/15 and a patch also called 2/15
(I suspect it is the 10th patch).
So, after reading our comments, reading README.patches and applying the
Asaulted-patches extension to your thunderbird, please resubmit the patches.
Actually doesn't work zl10353 with tm6010, it have a little different
between a few registers, so I think that I use it.
for example:
zl10353 use 0x64 , but not mine (0x63)
register 0x5f is 0x17 not 0x13
register 0x5e is 0x40 not 0x00 for auto
and tuner go is 0x70 not 0x71
the other register are ok. I have no idea how I can set it.
I agree with Devin that the patch 14/15 shouldn't be applied as-is.
I have no idea why zl10353 needs a different setup, but you don't need
to add an extra parameter to identify the bridge driver. There's a field
at struct i2c_client that can be used: i2c_adapter-id.
This is already initialized with I2C_HW_B_TM6000 (although it currently
uses a fake value).
It is still ugly to do some specific initialization like this, but, when
we have no other glue, due to the lack of datasheets, this is a better
alternative than adding an extra fake parameter at the config struct.
All you need is some code like:
diff --git a/linux/drivers/media/dvb/frontends/zl10353.c
b/linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c
+++ b/linux/drivers/media/dvb/frontends/zl10353.c
@@ -597,6 +597,10 @@ static int zl10353_init(struct dvb_front
zl10353_read_register(state, 0x51) != zl10353_reset_attach[2]) {
rc = zl10353_write(fe, zl10353_reset_attach,
sizeof(zl10353_reset_attach));
+
+ if (state-i2c-id == I2C_HW_B_TM6000) {
+ /* Do special init needed by tm6000 driver */
+ }
#if 1
if (debug_regs)
zl10353_dump_regs(fe);
diff --git a/linux/drivers/staging/tm6000/tm6000-i2c.c
b/linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c
@@ -33,8 +33,6 @@
#include tuner-xc2028.h
-/*FIXME: Hack to avoid needing to patch i2c-id.h */
-#define I2C_HW_B_TM6000 I2C_HW_B_EM28XX
/* --- */
static unsigned int i2c_debug = 0;
diff --git a/linux/include/linux/i2c-id.h b/linux/include/linux/i2c-id.h
--- a/linux/include/linux/i2c-id.h
+++ b/linux/include/linux/i2c-id.h
@@ -42,6 +42,7 @@
#define I2C_HW_B_AU0828 0x010023 /* auvitek au0828 usb bridge */
#define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */
#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */
+#define I2C_HW_B_TM6000 0x010026 /* TM5600/6000/6010 video
bridge */
/* --- SGI adapters */
#define I2C_HW_SGI_VINO 0x16
init is ok, but it has only one additional register 0x55 (value 0x40)
reset after second. I think it can work without this additional once.
The different is in function set_parameters.
--
Stefan Ringel stefan.rin...@arcor.de
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
HVR1120 with saa7134 module
I am user of Hauppauge HVR1120, using saa7134 module, and I have problem with radio FM use in linux mode. Distribution OpenSuse11.2 Kernel 2.6.31.8-0.1-desktop Firmware dvb-fe-tda10048-1.0.fw loaded Analog and Digital Television are OK in both Windows and Linux. Windows is using Hauppauge WinTV7 v7.027313 Linux is using Kaffeine v1.0-pre2 for Digital Television Linux is using mplayer for analog TV like: mplayer tv:// -tv driver=v4l2:freq=495.750:norm=SECAM- L:input=0:audiorate=32000:immediatemode=0:alsa:forceaudio:adevice=hw.1,0:width=720:height=576:amode=1 The problem is to listen radio. One radio station is OK at 91.5MHz stereo using WintTV7 in Windows. With Linux, the command used is mplayer radio://91.5/capture/ -radio adevice=hw=1,0:arate=44100:achannels=2 The result is a non stable frecuency. The station is not tuned correctly. The 91.5MHz station is mixed permanently with other stations. How can I check saa7134 ? Do you need saa7134 dmesg output ? Regards, ftape-jlc -- 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 14/15] - zl10353
Stefan Ringel wrote:
Am 04.02.2010 03:43, schrieb Mauro Carvalho Chehab:
Stefan Ringel wrote:
Am 03.02.2010 21:49, schrieb Devin Heitmueller:
On Wed, Feb 3, 2010 at 3:38 PM, Stefan Ringel stefan.rin...@arcor.de
wrote:
signed-off-by: Stefan Ringel stefan.rin...@arcor.de
--- a/drivers/media/dvb/frontends/zl10353.h
+++ b/drivers/media/dvb/frontends/zl10353.h
@@ -45,6 +45,8 @@ struct zl10353_config
/* clock control registers (0x51-0x54) */
u8 clock_ctl_1; /* default: 0x46 */
u8 pll_0;/* default: 0x15 */
+
+ int tm6000:1;
};
Why is this being submitted as its own patch? It is code that is not
used by *anything*. If you really did require a new field in the
zl10353 config, that field should be added in the same patch as
whatever requires it.
Devin
Hi Stefan,
Due to the problem with your emailer, most of the patches failed:
2/15 3/15 4/15 5/15 6/15 7/15 2/15 (the second one 8th in the sequence)
9/15 11/15 12/15 13/15 and 15/15.
In brief, only two patches applied: the 1/15 and a patch also called 2/15
(I suspect it is the 10th patch).
So, after reading our comments, reading README.patches and applying the
Asaulted-patches extension to your thunderbird, please resubmit the patches.
Actually doesn't work zl10353 with tm6010, it have a little different
between a few registers, so I think that I use it.
for example:
zl10353 use 0x64 , but not mine (0x63)
register 0x5f is 0x17 not 0x13
register 0x5e is 0x40 not 0x00 for auto
and tuner go is 0x70 not 0x71
the other register are ok. I have no idea how I can set it.
I agree with Devin that the patch 14/15 shouldn't be applied as-is.
I have no idea why zl10353 needs a different setup, but you don't need
to add an extra parameter to identify the bridge driver. There's a field
at struct i2c_client that can be used: i2c_adapter-id.
This is already initialized with I2C_HW_B_TM6000 (although it currently
uses a fake value).
It is still ugly to do some specific initialization like this, but, when
we have no other glue, due to the lack of datasheets, this is a better
alternative than adding an extra fake parameter at the config struct.
All you need is some code like:
diff --git a/linux/drivers/media/dvb/frontends/zl10353.c
b/linux/drivers/media/dvb/frontends/zl10353.c
--- a/linux/drivers/media/dvb/frontends/zl10353.c
+++ b/linux/drivers/media/dvb/frontends/zl10353.c
@@ -597,6 +597,10 @@ static int zl10353_init(struct dvb_front
zl10353_read_register(state, 0x51) != zl10353_reset_attach[2]) {
rc = zl10353_write(fe, zl10353_reset_attach,
sizeof(zl10353_reset_attach));
+
+if (state-i2c-id == I2C_HW_B_TM6000) {
+/* Do special init needed by tm6000 driver */
+}
#if 1
if (debug_regs)
zl10353_dump_regs(fe);
diff --git a/linux/drivers/staging/tm6000/tm6000-i2c.c
b/linux/drivers/staging/tm6000/tm6000-i2c.c
--- a/linux/drivers/staging/tm6000/tm6000-i2c.c
+++ b/linux/drivers/staging/tm6000/tm6000-i2c.c
@@ -33,8 +33,6 @@
#include tuner-xc2028.h
-/*FIXME: Hack to avoid needing to patch i2c-id.h */
-#define I2C_HW_B_TM6000 I2C_HW_B_EM28XX
/* --- */
static unsigned int i2c_debug = 0;
diff --git a/linux/include/linux/i2c-id.h b/linux/include/linux/i2c-id.h
--- a/linux/include/linux/i2c-id.h
+++ b/linux/include/linux/i2c-id.h
@@ -42,6 +42,7 @@
#define I2C_HW_B_AU0828 0x010023 /* auvitek au0828 usb bridge */
#define I2C_HW_B_CX231XX0x010024 /* Conexant CX231XX USB based cards */
#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */
+#define I2C_HW_B_TM6000 0x010026 /* TM5600/6000/6010 video
bridge */
/* --- SGI adapters */
#define I2C_HW_SGI_VINO 0x16
init is ok, but it has only one additional register 0x55 (value 0x40)
reset after second. I think it can work without this additional once.
The different is in function set_parameters.
Ok. Well, just add the logic to check for the bridge at the place it is needed,
and
only if it won't work otherwise. I would love to have the datasheet to check for
the values, but unfortunately I don't have it. Anyway, after having it working,
someone
may help to figure out why the changes are needed and provide a better approach.
-
A side note:
due to the backport code that you've added on your patches, I suspect that you
just
copied the files from the -hg to -git. You shouldn't do it, since we remove all
backport
stuff at -git, by running the gentree.pl script, found at
v4l/scripts/gentree.pl.
--
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More
Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP So there is something wrong with the list manipulations or, if needed, locking around the the list manipulations of the list that was introduced in the patch you identified as the problem. That is what is causing the Ooops on close(). It will take a some more scrutiny to see what exactly is wrong. Schedule update: I'll be looking at this tonight (Thursday evening). After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Comments? Regards, Andy -- 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: Need to discuss method for multiple, multiple-PID TS's from same demux (Re: Videotext application crashes the kernel due to DVB-demux patch)
Hi Andy, Am Donnerstag, den 04.02.2010, 21:21 -0500 schrieb Andy Walls: On Thu, 2010-02-04 at 15:07 +0100, Chicken Shack wrote: Am Donnerstag, den 04.02.2010, 07:54 -0500 schrieb Andy Walls: On Wed, 2010-02-03 at 02:01 +0100, hermann pitton wrote: Am Dienstag, den 02.02.2010, 07:52 -0500 schrieb Andy Walls: On Tue, 2010-02-02 at 10:11 +0100, Chicken Shack wrote: Am Montag, den 01.02.2010, 21:00 -0500 schrieb Andy Walls: On Mon, 2010-02-01 at 07:41 -0500, Andy Walls wrote: On Mon, 2010-02-01 at 10:56 +0100, Chicken Shack wrote: Hi, here is a link to a patch which breaks backwards compatibility for a teletext software called alevt-dvb. http://www.mail-archive.com/linuxtv-comm...@linuxtv.org/msg04638.html The kernel patch was introduced with kernel 2.6.32-rc1. It was Signed-off-by Brandon Philips, Mauro Carvalho Chehab and its author, Andreas Oberritter. Regards CS P. S.: This is how the kernel crash looks like: The information below can get me started. Could you please provide whole Ooops from the output dmesg or from your /var/log/messages file? I'll try to look at this tonight. Regards, Andy brian:~# alevt alevt: SDT: service_id 0xcf24 not in PAT alevt: ioctl: DMX_SET_PES_FILTER Invalid argument (22) Getötet brian:~# Message from sysl...@brian at Jan 31 19:52:33 ... kernel:[ 116.563487] Oops: [#1] PREEMPT SMP So there is something wrong with the list manipulations or, if needed, locking around the the list manipulations of the list that was introduced in the patch you identified as the problem. That is what is causing the Ooops on close(). It will take a some more scrutiny to see what exactly is wrong. Schedule update: I'll be looking at this tonight (Thursday evening). After investigation, my recommendation for fixing the problem is to revert the patch that is causing the problem. The reason for this is not that fixing the patch is impossible. INstead, I'll assert that using the DMX_ADD_PID and DMX_REMOVE_PID in conjunction with output=DMX_OUT_TSDEMUX_TAP is simply converting the demux0 device into multiple dynamically created anonymous dvr0 devices, and that is the wrong thing to do. I understand the need for sending a single PID TS out to an open demux0 instance as described in this email: http://www.mail-archive.com/linux-...@linuxtv.org/msg29814.html even though it seems like a slight abuse of the demux0 device. But sending multiple PIDs out in a TS to the open demux0 device instance is just an awkward way to essentially dynamically create a dvrN device associated with filter(s) set on an open demux0 instance. It would be better, in my opinion, to figure out a way to properly create and/or associate a dvrN device node with a collection of demuxN filters. Maybe just allow creation of a logical demux1 device and dvr1 device and the use the DVB API calls as is on the new logical devices. I'm not a DVB apps programmer, so I don't know all the userspace needs nor if anything is already using the DMX_ADD_PID and DMX_REMOVE_PID ioctl()s. Comments? Regards, Andy without looking any much closer, just at some headers that might be out of sync, taking the DVB patched version from here http://pluto.blackbone-ev.de/v1/AleVT%20mit%20DVB-T.html make cc -O2 -s -w main.o ui.o xio.o fdset.o vbi.o cache.o help.o edline.o search.o edit.o misc.o hamm.o lang.o export.o exp-txt.o exp-html.o exp-gfx.o font.o -o alevt -L/usr/X11R6/lib -L/usr/X11R6/lib64 -lX11 -lpng -lz -lm /usr/bin/ld: i386 architecture of input file `main.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `ui.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `xio.o' is incompatible with i386:x86-64 output /usr/bin/ld: i386 architecture of input file `fdset.o' is incompatible with i386:x86-64 output collect2: ld gab 1 als Ende-Status zurück make: *** [alevt] Fehler 1 make clean rm -f *.o page*.txt a.out core bdf2xbm font?.xbm fontsize.h Makefile.bak rm -f alevt alevt-date alevt-cap rm -f alevt.1x alevt-date.1 alevt-cap.1 rm -f contrib/a.out ttext-*.* rm -f alevt.html make cc -O2 -s -w -DVERSION=\1.6.2\ -DWITH_PNG -I/usr/X11R6/include -c -o main.o main.c cc -O2 -s -w -DVERSION=\1.6.2\ -DWITH_PNG -I/usr/X11R6/include -c -o ui.o ui.c cc bdf2xbm.c -o bdf2xbm ./bdf2xbm font1 vtxt-latin-1.bdf font1.xbm ./bdf2xbm font2 vtxt-latin-2.bdf font2.xbm fgrep -h #define font1.xbm font2.xbm fontsize.h cc -O2 -s -w -DVERSION=\1.6.2\ -DWITH_PNG -I/usr/X11R6/include -c -o xio.o xio.c
Re: [PATCH] Fix the risk of an oops at dvb_dmx_release
On Mon, 2010-02-01 at 11:35 -0200, Mauro Carvalho Chehab wrote:
dvb_dmx_init tries to allocate virtual memory for 2 pointers: filter and feed.
If the second vmalloc fails, filter is freed, but the pointer keeps pointing
to the old place. Later, when dvb_dmx_release() is called, it will try to
free an already freed memory, causing an OOPS.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Looks good.
Reviewed-by: Andy Walls awa...@radix.net
---
drivers/media/dvb/dvb-core/dvb_demux.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index b78cfb7..a78408e 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -1246,6 +1246,7 @@ int dvb_dmx_init(struct dvb_demux *dvbdemux)
dvbdemux-feed = vmalloc(dvbdemux-feednum * sizeof(struct
dvb_demux_feed));
if (!dvbdemux-feed) {
vfree(dvbdemux-filter);
+ dvbdemux-filter = NULL;
return -ENOMEM;
}
for (i = 0; i dvbdemux-filternum; i++) {
--
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] dvb_demux: Don't use vmalloc at dvb_dmx_swfilter_packet
On Mon, 2010-02-01 at 12:50 -0200, Mauro Carvalho Chehab wrote:
As dvb_dmx_swfilter_packet() is protected by a spinlock, it shouldn't sleep.
However, vmalloc() may call sleep. So, move the initialization of
dvb_demux::cnt_storage field to a better place.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
Looks good. In fact it is slightly better in that it doesn't disable
the global module option for all following demuxes simply for one
vmalloc() failure.
Reviewed-by: Andy Walls awa...@radix.net
Regards,
Andy
---
drivers/media/dvb/dvb-core/dvb_demux.c | 19 ---
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/media/dvb/dvb-core/dvb_demux.c
b/drivers/media/dvb/dvb-core/dvb_demux.c
index a78408e..67f189b 100644
--- a/drivers/media/dvb/dvb-core/dvb_demux.c
+++ b/drivers/media/dvb/dvb-core/dvb_demux.c
@@ -426,16 +426,7 @@ static void dvb_dmx_swfilter_packet(struct dvb_demux
*demux, const u8 *buf)
};
};
- if (dvb_demux_tscheck) {
- if (!demux-cnt_storage)
- demux-cnt_storage = vmalloc(MAX_PID + 1);
-
- if (!demux-cnt_storage) {
- printk(KERN_WARNING Couldn't allocate memory for
TS/TEI check. Disabling it\n);
- dvb_demux_tscheck = 0;
- goto no_dvb_demux_tscheck;
- }
-
+ if (demux-cnt_storage) {
/* check pkt counter */
if (pid MAX_PID) {
if (buf[1] 0x80)
@@ -454,7 +445,6 @@ static void dvb_dmx_swfilter_packet(struct dvb_demux
*demux, const u8 *buf)
};
/* end check */
};
-no_dvb_demux_tscheck:
list_for_each_entry(feed, demux-feed_list, list_head) {
if ((feed-pid != pid) (feed-pid != 0x2000))
@@ -1258,6 +1248,13 @@ int dvb_dmx_init(struct dvb_demux *dvbdemux)
dvbdemux-feed[i].index = i;
}
+ if (dvb_demux_tscheck) {
+ dvbdemux-cnt_storage = vmalloc(MAX_PID + 1);
+
+ if (!dvbdemux-cnt_storage)
+ printk(KERN_WARNING Couldn't allocate memory for
TS/TEI check. Disabling it\n);
+ }
+
INIT_LIST_HEAD(dvbdemux-frontend_list);
for (i = 0; i DMX_TS_PES_OTHER; i++) {
--
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: Any saa711x users out there?
On Thu, 2010-02-04 at 10:24 -0500, Devin Heitmueller wrote: On Wed, Feb 3, 2010 at 8:51 PM, Andy Walls awa...@radix.net wrote: With all that said, if you have a baseband Luma or Chroma signal with strong spurious high frequency components (crappy source, or you're overdriving the front end and getting intermods), then keep the anti-alias filter turned on as the assumption of a bandlimited input signal is violated in this case. In this case, I'm seeing it with both the analog signal generator (which one might consider a fairly pristine source), as well coming off the s-video output of a DirectTV box (in which case the signal is being generated only a few feet away from the saa7113). Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. In the SAA7113 the anti-alias filter introduces a delay of 50 ns. At 13.5 Mpixels/sec, or 74.1 ns/pixel, that's less than 1 pixel time of delay. Just turn it on in and leave it on in the SAA7113 to handle the unexpected input signal case. This would be my vote (assuming we try it with the other parts and confirm no regressions are introduced). My only concern is the way the code is currently written, the saa7113 initialization block actually does enable it by default, and then some code for the saa7115 tramples the register, turning it off (see saa7115_init_misc at saa7115.c:600). I think the decision we have to make is which of the following paths to take: 1. Enable it in the saa7115_init_misc, thereby enabling it for the 7113, 7114, and 7115. 2. Exclude the saa7115_init_misc block from being run at all against the 7113 3. Let the saa7115_init_misc block get run, and then flip the bit back for the 7113. My thinking at this point is that the AA filter should probably be on by default regardless of the chip, in which case we would just need to make the one line change to enable it in the saa7115_init_misc block. Probably. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Regards, Andy Devin -- 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: Any saa711x users out there?
Hey Andy, On Thu, Feb 4, 2010 at 11:15 PM, Andy Walls awa...@radix.net wrote: Hmmm. The AGC (or static gain level?) of the amplifier in the SAA7113 before the anti-alias filter may be set too high causing the clipping (intermods) there. It may be worth looking at the gain setting for that amp. It's possible. One thing I did as a test though was I did a capture of the i2c traffic under Windows (using the same reference video source), and then compared the register programming (via some scripts I whipped up). There were some other registers that were different, but the only one that made *any* visible difference in the output was the AA flag. The visible effects of the anti-alais filter could possibly be: 1. Less range of color, if high freqs of the color get attenuated. (Most people likely will not perceive this as most people are not that sensitive to small color variations.) 2. Loss of rapid variations in Luma - softer edges between light and dark areas on a scan line - if higher freqs of the Luma get attenuated. but given that the anti-alais filter is essentially flat out to about 5.6 MHz and has a slow rolloff (only 3 dB down at about 6.9 MHz), I doubt anyone would ever notice it is on with NTSC. To give you a better idea of what I'm talking about, look at this image: http://imagebin.org/83458 The above image was taken with the generator via the s-video input (ruling out the possibility that it's any sort of product of intermodulation). For the sake of comparison, here's the exact same signal source against an a similar em28xx design but with the tvp5150. http://imagebin.org/83459 Since you have a signal generator, you should run experiments with PAL-D and SECAM-D with a grid containing vertical lines since those both have a 6.0 MHz video bandwidth. SECAM also has FM color, so you might see the greatest affect of an antialias filter on color on the Cyan color bar in SECAM-D. Believe it or not, I'm actually having trouble with the generator right now with anything but NTSC. I'm going back and forth with Promax on repair options. So I cannot do any PAL or SECAM testing right now. On a separate note, I really should look at extending the v4l2 capture-example to a version that let's me do a direct capture of the YUYV frame and convert the output into a zero-loss RGB format. It's too easy to be mislead by things the applications are doing like deinterlacing, rescaling, blending, and compression of the screenshot when saving to a file. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: omap34xxcam question?
Michael Trimarchi wrote: Hi, Hi, Sakari Ailus wrote: Hi Michael, ... The frame sizes in our sensor drivers are in width descending order. The selection has been working somehow so far but it's definitely not perfect. Ok for the frame size but you need to test all the possible sensor output too and continue in case of error. The try function should return an error only in real error cases, not otherwise. But as I said, this code will be removed soon from that driver... We're converting the ISP driver to use the Media controller so this code will be dropped in near future probably. In that case the user space has to select the sensor mode it wants to use as well. Good. Maybe I can test the framework on the FLOW1.5 mobile device using the TCM8240MD What is your git for the camera framework? It's all available here but I'm afraid you'll have to wait a bit first. The legacy nodes (per sensor devices) are the only ones in existence at the moment. URL:http://www.gitorious.org/projects/omap3camera -- Sakari Ailus sakari.ai...@maxwell.research.nokia.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
