Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, Am Donnerstag, den 13.05.2010, 15:45 -0300 schrieb Mauro Carvalho Chehab: Mauro Carvalho Chehab wrote: hermann pitton wrote: My view is that the backport tree is very useful to have a broader number of people testing V4L/DVB code, as it can be applied against legacy kernels. Of course, for this to work, people should quickly fix broken backports (that means that not only Douglas should work on it, but other developers are welcomed to contribute with backport fixes). For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb then to provide relevant debug output and eventually patches. Until Douglas or someone fix the breakages with older kernels, yes. As the fix patch is really trivial, I found a couple of minutes to write a patch for fixing this issue. I haven't test the patch, but, as it uses the same backport logic as found at cx2355-ir, I don't expect much troubles on it. Mauro, fine, it is a start. Compiles down to to 2.6.30, but has some __check_debug warnings for three static bool insmod options there. (build cron job of today) To replace them with some int seems ok, but since no such warnings on higher kernels for bool, likely some compat issue. IR oopses on 2.6.30 with Pinnacle 310i on a first try. Thanks for all explanations of the current sync procedures, Douglas does well and four weeks without in depth backward compat are hard to avoid either way. Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. Cheers, Hermann saa7133[1]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[1]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 5-004b: chip found @ 0x96 (saa7133[1]) tda829x 5-004b: setting tuner address to 61 tda829x 5-004b: type set to tda8290+75a saa7133[1]: registered device video1 [v4l2] saa7133[1]: registered device vbi1 saa7133[1]: registered device radio1 saa7133[2]: setting pci latency timer to 64 saa7133[2]: found at :02:09.0, rev: 208, irq: 19, latency: 64, mmio: 0xfdefd000 saa7133[2]: subsystem: 11bd:002f, board: Pinnacle PCTV 310i [card=101,autodetected] saa7133[2]: board init: gpio is 600c000 IRQ 19/saa7133[2]: IRQF_DISABLED is not guaranteed on shared IRQs saa7133[2]: i2c eeprom 00: bd 11 2f 00 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7133[2]: i2c eeprom 10: ff e0 60 06 ff 20 ff ff 00 30 8d 2c b0 22 ff ff saa7133[2]: i2c eeprom 20: 01 2c 01 02 02 01 04 30 98 ff 00 a5 ff 21 00 c2 saa7133[2]: i2c eeprom 30: 96 10 03 32 15 20 ff ff 0c 22 17 88 03 44 31 f9 saa7133[2]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7133[2]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff tuner 6-004b: chip found @ 0x96 (saa7133[2]) tda829x 6-004b: setting tuner address to 61 tda829x 6-004b: type set to tda8290+75a Registered IR keymap rc-pinnacle-color input: i2c IR (Pinnacle PCTV) as /devices/virtual/input/input8 BUG: unable to handle kernel NULL pointer dereference at (null) IP: [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] PGD 3ecbd067 PUD 2006b067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/module/saa7134/initstate CPU 0 Modules linked in: rc_pinnacle_color ir_kbd_i2c(+) tda827x tda8290 tuner saa7134(+) v4l2_common videodev v4l1_compat v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core ir_common ir_core tveeprom sit tunnel4 fuse bridge stp llc bnep sco l2cap bluetooth sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand powernow_k8 freq_table dm_multipath uinput snd_intel8x0 snd_ac97_codec ac97_bus snd_seq snd_seq_device snd_pcm snd_timer r8169 ppdev snd mii soundcore snd_page_alloc parport_pc shpchp k8temp parport hwmon joydev floppy serio_raw pcspkr i2c_nforce2 ata_generic pata_acpi pata_amd radeon drm i2c_algo_bit i2c_core [last unloaded: v4l1_compat] Pid: 3399, comm: modprobe Not tainted 2.6.30.10-105.2.16.fc11.x86_64 #1 RIP: 0010:[a00e97c7] [a00e97c7] __ir_input_register+0x26d/0x2fd [ir_core] RSP: 0018:88003b459cb8 EFLAGS: 00010246 RAX:
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi, [snip] Did not try on 2.6.33.4 yet, but should be OK. The rest we can fix after the merge window. The saa7134 card=2 gpio remote is OK on 2.6.33.4 with current v4l-dvb. Sander, let's know about further questions. Cheers, Hermann -- 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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia
M135A,
since this is the board I'm using at the IR refactoring tests, but the
same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference
of the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.
Long answer:
===
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
hermann pitton wrote:
Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia
M135A,
since this is the board I'm using at the IR refactoring tests, but the
same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference
of the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.
Long answer:
===
As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests
not
handled yet, mercurial
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi,
Am Donnerstag, den 13.05.2010, 09:32 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Donnerstag, den 13.05.2010, 01:49 -0300 schrieb Mauro Carvalho
Chehab:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia
M135A,
since this is the board I'm using at the IR refactoring tests, but the
same approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write
one table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name.
See http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a
reference of the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that
the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for
Re: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
hermann pitton wrote: My view is that the backport tree is very useful to have a broader number of people testing V4L/DVB code, as it can be applied against legacy kernels. Of course, for this to work, people should quickly fix broken backports (that means that not only Douglas should work on it, but other developers are welcomed to contribute with backport fixes). For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb then to provide relevant debug output and eventually patches. Until Douglas or someone fix the breakages with older kernels, yes. He has to check if his distribution has the minimal requirements for that one too. In thesis, yes, but, unless he is running a really old distribution (those that come with kernels lower than 2.6.16), it should be ok to run 2.6.33 on it, provided that properly compiled with the minimum requirements needed by the distro. Generally, make oldconfig do a good job of enabling the needed bits, but sometimes, manual adjustments at compilation parameters might be needed. Well, if the distro is older than 2.6.16, it won't be capable of running from -hg anyway (as the minimum supported kernel is 2.6.16). So, I don't think that this would be a problem, in practice. -- 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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Mauro Carvalho Chehab wrote: hermann pitton wrote: My view is that the backport tree is very useful to have a broader number of people testing V4L/DVB code, as it can be applied against legacy kernels. Of course, for this to work, people should quickly fix broken backports (that means that not only Douglas should work on it, but other developers are welcomed to contribute with backport fixes). For now, if not using git, Sander needs a 2.6.33 with recent v4l-dvb then to provide relevant debug output and eventually patches. Until Douglas or someone fix the breakages with older kernels, yes. As the fix patch is really trivial, I found a couple of minutes to write a patch for fixing this issue. I haven't test the patch, but, as it uses the same backport logic as found at cx2355-ir, I don't expect much troubles on 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: Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
Hi,
On Thu, May 13, 2010 at 1:49 AM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16.
For GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of
the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the
wiki page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
Well, any help to fix v4l-dvb trees are welcome.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
Exactly.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
Agreed.
As the backport is manual, some delay is expected at the backport tree.
Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
As Mauro pointed, the backport job is done by 99% of time taking every single
patch available in git tree and apply it manually and fixing
eventually problems.
So, it's can take some time.
Developers
Mercurial x git tree sync - was: Re: Remote control at Zolid Hybrid TV Tuner
hermann pitton wrote:
Am Mittwoch, den 12.05.2010, 15:59 -0300 schrieb Mauro Carvalho Chehab:
Sander Pientka wrote:
Hi Hermann,
I am going to revive this old thread, I completely forgot about it and
I still want to solve this problem.
Yes, with the IR transmitter not plugged in, the gpio is reported as
0 by dmesg.
I am aware there is a picture of the backside missing on the wiki, I
will try to make one a.s.a.p.
NEC IR support seems to be built-in already:
drivers/media/IR/ir-nec-decoder.c.
Besides, dmesg outputs a section of error messages I don't understand:
[ 1585.548221] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.548229] tda18271_toggle_output: error -5 on line 47
[ 1585.720118] tda18271_write_regs: ERROR: idx = 0x5, len = 1,
i2c_transfer returned: -5
[ 1585.720129] tda18271_init: error -5 on line 826
[ 1585.720136] tda18271_tune: error -5 on line 904
[ 1585.720141] tda18271_set_analog_params: error -5 on line 1041
[ 1586.381026] tda18271_write_regs: ERROR: idx = 0x6, len = 1,
i2c_transfer returned: -5
[ 1586.500589] tda18271_write_regs: ERROR: idx = 0x1d, len = 1,
i2c_transfer returned: -5
[ 1586.629447] tda18271_write_regs: ERROR: idx = 0x10, len = 1,
i2c_transfer returned: -5
[ 1586.629458] tda18271_channel_configuration: error -5 on line 160
[ 1586.629465] tda18271_set_analog_params: error -5 on line 1041
Do you have any idea about the origin of these errors? Do you think
they affect the IR functionality?
The above errors won't change anything at IR side. For IR, the better
approach
is to start using raw_decode mode. I've enabled it only for Avermedia M135A,
since this is the board I'm using at the IR refactoring tests, but the same
approach
should work fine for any other saa7134 board that uses GPIO18 or GPIO16. For
GPIO18,
all you need is to use something like:
case SAA7134_BOARD_AVERMEDIA_M135A:
ir_codes = RC_MAP_AVERMEDIA_M135A_RM_JX;
mask_keydown = 0x004;
mask_keyup = 0x004;
mask_keycode = 0x;
raw_decode = 1;
break;
(Of course, replacing the board name by your board name
(SAA7134_BOARD_ZOLID_HYBRID_PCI?),
and pointing to the proper ir_codes table. You'll likely need to write one
table for
the IR that were shipped with your board.
To do that, you'll need to enable debug at ir_core (modprobe ir_core
debug=1), and type every
key on your keyboard, associating the scancode number with a key name. See
http://www.linuxtv.org/wiki/index.php/Remote_Controllers for a reference of
the most comon keycodes.
For example, pressing the power button of an IR I have here (for Leadtek
PVR3000), it
gives this info at the dmesg log:
ir_nec_decode: NEC scancode 0x0300
All I need to do is to write a new keymap:
add a new media/rc-map.h
as, for example:
drivers/media/IR/keymaps/rc-leadtek_pvr3000.c
(copying one of the existing keymaps) and add:
static struct ir_scancode leadtek_winfast_pvr3000_dlx[] = {
{ 0x300, KEY_POWER2 },
for every key that it is there. Then, add the new file at
drivers/media/IR/keymaps/Makefile.
I've tried to summarize the above patches on a change I just did at the wiki
page. Feel
free to improve it, if needed.
Cheers,
Mauro
Hi Mauro,
what I did try to point to, with some sarcasm involved, is that I can't
advice any v4l-dvb as reference anymore.
To start to look such up, with all patches involved, per user, who
likely does not know himself on what he exactly is, find the last
building kernel for him then, guess on pending pull requests that time,
and so on, is not making any sense for me.
Should we not state, that is nothing against Douglas at all or Hans with
his build reports, please be on latest .rc and git to test anything we
have around?
We are out of sync else.
Hermann,
Sorry, but, sometimes, it is very hard to understand your English. I'm
suspecting
that you're referring to the sync between hg and git.
Short answer:
- AFAIK, Douglas finished syncing the trees at the night of May, 12.
- Developers primary reference tree:
http://git.linuxtv.org/v4l-dvb.git
- Backport tree:
http://linuxtv.org/hg/v4l-dvb
As the backport is manual, some delay is expected at the backport tree. Also,
backports are made at the best efforts basis. So, nobody can warrant that the
drivers will behave correctly with an old kernel. Also, eventually, the
backport tree
can break when compiled with an older kernel.
Developers are encouraged to use git for development, but patches and pull
requests against the backport tree are accepted.
Long answer:
===
As I have about 100 pending patches at Patchwork, plus 4 or 5 pull requests not
handled yet, mercurial tree will be soon out of sync. I'll try to merge most of
the
pending stuff during this weekend.
The main
