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
gspca-sonixj: ioctl VIDIOC_DQBUF blocks for 3s and retuns EIO
Hi, I'm not sure if I'm hitting a bug or this is the expected driver behavior: With a Microsoft LifeCam VX-3000 (045e:00f5) and gspca-sonixj, ioctl VIDIOC_DQBUF intermittently blocks for exactly 3 seconds and then returns EIO. I noticed that it strongly depends on the captured scenery: when it's changing much, everything is fine. But when for example capturing the wall under constant (lower) light conditions, I'm getting this error nearly permanently. It's a JPEG-device, so I guess the device stops sending data if the picture doesn't change and that's how it should be. But is the long blocking + EIO the way drivers should handle this situtation ? Regards, Frank Schaefer -- 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,
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
[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 May 13 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14849:9b63860cd18a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 4fcfa8824391ef0f9cff82122067f31c6d920921 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: ERRORS linux-2.6.33-armv5: OK linux-2.6.34-rc7-armv5: ERRORS linux-2.6.32.6-armv5-davinci: ERRORS linux-2.6.33-armv5-davinci: OK linux-2.6.34-rc7-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: ERRORS linux-2.6.33-armv5-ixp: OK linux-2.6.34-rc7-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: ERRORS linux-2.6.33-armv5-omap2: OK linux-2.6.34-rc7-armv5-omap2: ERRORS 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: ERRORS linux-2.6.31.12-i686: ERRORS linux-2.6.32.6-i686: ERRORS linux-2.6.33-i686: OK linux-2.6.34-rc7-i686: ERRORS linux-2.6.32.6-m32r: ERRORS linux-2.6.33-m32r: OK linux-2.6.34-rc7-m32r: ERRORS linux-2.6.32.6-mips: ERRORS linux-2.6.33-mips: OK linux-2.6.34-rc7-mips: ERRORS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-powerpc64: OK linux-2.6.34-rc7-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: ERRORS linux-2.6.31.12-x86_64: ERRORS linux-2.6.32.6-x86_64: ERRORS linux-2.6.33-x86_64: OK linux-2.6.34-rc7-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: 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: 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
[PATCH -hg] Build fix for mercurial tree
Fix backport tree compilations with kernels older than 2.6.33.
Compile tested only, with 2.6.32.4 kernel.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/linux/drivers/media/IR/ir-core-priv.h
b/linux/drivers/media/IR/ir-core-priv.h
--- a/linux/drivers/media/IR/ir-core-priv.h
+++ b/linux/drivers/media/IR/ir-core-priv.h
@@ -28,7 +28,11 @@ struct ir_raw_handler {
struct ir_raw_event_ctrl {
struct work_struct rx_work;/* for the rx decoding
workqueue */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ struct kfifo*kfifo; /* fifo for the
pulse/space durations */
+#else
struct kfifokfifo; /* fifo for the
pulse/space durations */
+#endif
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
struct input_dev*input_dev; /* pointer to the
parent input_dev */
diff --git a/linux/drivers/media/IR/ir-raw-event.c
b/linux/drivers/media/IR/ir-raw-event.c
--- a/linux/drivers/media/IR/ir-raw-event.c
+++ b/linux/drivers/media/IR/ir-raw-event.c
@@ -61,8 +61,13 @@ static void ir_raw_event_work(struct wor
struct ir_raw_event_ctrl *raw =
container_of(work, struct ir_raw_event_ctrl, rx_work);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ while (kfifo_get(raw-kfifo, (void *)ev, sizeof(ev)) == sizeof(ev))
+ RUN_DECODER(decode, raw-input_dev, ev);
+#else
while (kfifo_out(raw-kfifo, ev, sizeof(ev)) == sizeof(ev))
RUN_DECODER(decode, raw-input_dev, ev);
+#endif
}
int ir_raw_event_register(struct input_dev *input_dev)
@@ -77,8 +82,15 @@ int ir_raw_event_register(struct input_d
ir-raw-input_dev = input_dev;
INIT_WORK(ir-raw-rx_work, ir_raw_event_work);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ ir-raw-kfifo = kfifo_alloc(sizeof(s64) * MAX_IR_EVENT_SIZE,
+GFP_KERNEL, NULL);
+ if (ir-raw-kfifo == NULL)
+ rc = -ENOMEM;
+#else
rc = kfifo_alloc(ir-raw-kfifo, sizeof(s64) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
+#endif
if (rc 0) {
kfree(ir-raw);
ir-raw = NULL;
@@ -87,7 +99,11 @@ int ir_raw_event_register(struct input_d
rc = RUN_DECODER(raw_register, input_dev);
if (rc 0) {
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ kfifo_free(ir-raw-kfifo);
+#else
kfifo_free(ir-raw-kfifo);
+#endif
kfree(ir-raw);
ir-raw = NULL;
return rc;
@@ -106,7 +122,11 @@ void ir_raw_event_unregister(struct inpu
cancel_work_sync(ir-raw-rx_work);
RUN_DECODER(raw_unregister, input_dev);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ kfifo_free(ir-raw-kfifo);
+#else
kfifo_free(ir-raw-kfifo);
+#endif
kfree(ir-raw);
ir-raw = NULL;
}
@@ -128,8 +148,13 @@ int ir_raw_event_store(struct input_dev
if (!ir-raw)
return -EINVAL;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ if (kfifo_put(ir-raw-kfifo, (void *)ev, sizeof(*ev)) != sizeof(*ev))
+ return -ENOMEM;
+#else
if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev))
return -ENOMEM;
+#endif
return 0;
}
--
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: [PATCH -hg] Build fix for mercurial tree
On Thu, May 13, 2010 at 3:43 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Fix backport tree compilations with kernels older than 2.6.33.
Compile tested only, with 2.6.32.4 kernel.
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
diff --git a/linux/drivers/media/IR/ir-core-priv.h
b/linux/drivers/media/IR/ir-core-priv.h
--- a/linux/drivers/media/IR/ir-core-priv.h
+++ b/linux/drivers/media/IR/ir-core-priv.h
@@ -28,7 +28,11 @@ struct ir_raw_handler {
struct ir_raw_event_ctrl {
struct work_struct rx_work; /* for the rx decoding
workqueue */
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ struct kfifo *kfifo; /* fifo for the
pulse/space durations */
+#else
struct kfifo kfifo; /* fifo for the
pulse/space durations */
+#endif
ktime_t last_event; /* when last event
occurred */
enum raw_event_type last_type; /* last event type */
struct input_dev *input_dev; /* pointer to the
parent input_dev */
diff --git a/linux/drivers/media/IR/ir-raw-event.c
b/linux/drivers/media/IR/ir-raw-event.c
--- a/linux/drivers/media/IR/ir-raw-event.c
+++ b/linux/drivers/media/IR/ir-raw-event.c
@@ -61,8 +61,13 @@ static void ir_raw_event_work(struct wor
struct ir_raw_event_ctrl *raw =
container_of(work, struct ir_raw_event_ctrl, rx_work);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ while (kfifo_get(raw-kfifo, (void *)ev, sizeof(ev)) == sizeof(ev))
+ RUN_DECODER(decode, raw-input_dev, ev);
+#else
while (kfifo_out(raw-kfifo, ev, sizeof(ev)) == sizeof(ev))
RUN_DECODER(decode, raw-input_dev, ev);
+#endif
}
int ir_raw_event_register(struct input_dev *input_dev)
@@ -77,8 +82,15 @@ int ir_raw_event_register(struct input_d
ir-raw-input_dev = input_dev;
INIT_WORK(ir-raw-rx_work, ir_raw_event_work);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ ir-raw-kfifo = kfifo_alloc(sizeof(s64) * MAX_IR_EVENT_SIZE,
+ GFP_KERNEL, NULL);
+ if (ir-raw-kfifo == NULL)
+ rc = -ENOMEM;
+#else
rc = kfifo_alloc(ir-raw-kfifo, sizeof(s64) * MAX_IR_EVENT_SIZE,
GFP_KERNEL);
+#endif
if (rc 0) {
kfree(ir-raw);
ir-raw = NULL;
@@ -87,7 +99,11 @@ int ir_raw_event_register(struct input_d
rc = RUN_DECODER(raw_register, input_dev);
if (rc 0) {
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ kfifo_free(ir-raw-kfifo);
+#else
kfifo_free(ir-raw-kfifo);
+#endif
kfree(ir-raw);
ir-raw = NULL;
return rc;
@@ -106,7 +122,11 @@ void ir_raw_event_unregister(struct inpu
cancel_work_sync(ir-raw-rx_work);
RUN_DECODER(raw_unregister, input_dev);
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ kfifo_free(ir-raw-kfifo);
+#else
kfifo_free(ir-raw-kfifo);
+#endif
kfree(ir-raw);
ir-raw = NULL;
}
@@ -128,8 +148,13 @@ int ir_raw_event_store(struct input_dev
if (!ir-raw)
return -EINVAL;
+#if LINUX_VERSION_CODE KERNEL_VERSION(2, 6, 33)
+ if (kfifo_put(ir-raw-kfifo, (void *)ev, sizeof(*ev)) != sizeof(*ev))
+ return -ENOMEM;
+#else
if (kfifo_in(ir-raw-kfifo, ev, sizeof(*ev)) != sizeof(*ev))
return -ENOMEM;
+#endif
return 0;
}
Applied, thanks.
Cheers
Douglas
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/20] drivers/media: Use kzalloc
From: Julia Lawall ju...@diku.dk
Use kzalloc rather than the combination of kmalloc and memset.
The semantic patch that makes this change is as follows:
(http://coccinelle.lip6.fr/)
// smpl
@@
expression x,size,flags;
statement S;
@@
-x = kmalloc(size,flags);
+x = kzalloc(size,flags);
if (x == NULL) S
-memset(x, 0, size);
// /smpl
Signed-off-by: Julia Lawall ju...@diku.dk
---
drivers/media/dvb/frontends/ds3000.c |5 +
drivers/media/video/omap/omap_vout.c |3 +--
2 files changed, 2 insertions(+), 6 deletions(-)
diff -u -p a/drivers/media/dvb/frontends/ds3000.c
b/drivers/media/dvb/frontends/ds3000.c
--- a/drivers/media/dvb/frontends/ds3000.c
+++ b/drivers/media/dvb/frontends/ds3000.c
@@ -969,15 +969,12 @@ struct dvb_frontend *ds3000_attach(const
dprintk(%s\n, __func__);
/* allocate memory for the internal state */
- state = kmalloc(sizeof(struct ds3000_state), GFP_KERNEL);
+ state = kzalloc(sizeof(struct ds3000_state), GFP_KERNEL);
if (state == NULL) {
printk(KERN_ERR Unable to kmalloc\n);
goto error2;
}
- /* setup the state */
- memset(state, 0, sizeof(struct ds3000_state));
-
state-config = config;
state-i2c = i2c;
state-prevUCBS2 = 0;
diff -u -p a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -2371,12 +2371,11 @@ static int __init omap_vout_create_video
for (k = 0; k pdev-num_resources; k++) {
- vout = kmalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
+ vout = kzalloc(sizeof(struct omap_vout_device), GFP_KERNEL);
if (!vout) {
dev_err(pdev-dev, : could not allocate memory\n);
return -ENOMEM;
}
- memset(vout, 0, sizeof(struct omap_vout_device));
vout-vid = k;
vid_dev-vouts[k] = vout;
--
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: stv090x vs stv0900
В сообщении от 10 мая 2010 14:44:08 автор Pascal Terjan написал: Le dimanche 09 mai 2010 à 21:34 +0300, Igor M. Liplianin a écrit : On 6 мая 2010 11:46:17 Pascal Terjan wrote: Hi, I was adding support for a non working version of DVBWorld HD 2104 It is listed on http://www.linuxtv.org/wiki/index.php/DVBWorld_HD_2104_FTA_USB_Box as : = for new solution : 2104B (Sharp0169 Tuner) * STV6110A tuner * ST0903 demod * Cyrix CY7C68013A USB controller = The 2104A is supposed to be working and also have ST0903 but uses stv0900, so I tried using it too but did not manage to get it working. But it working. I have the device and test it succesfully. OK, but the B does not here while it seems to work with stv090x All I get in log with femon is stv0900_read_status: 7DEMOD LOCK FAIL 6stv0900_get_rf_level 6stv0900_get_rf_level: RFLevel = -100 6stv0900_carr_get_quality And with scandvb : stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL stv0900_read_status: 7DEMOD LOCK FAIL 6stv0900_search: 7stv0900_set_tuner: Frequency=1939000 stv0900_set_tuner: Bandwidth=7200 6stv0900_activate_s2_modcode 6Search Fail stv0900_read_status: 7DEMOD LOCK FAIL So modprobe dvb-usb-dw2102 demod=2 brings DVBWorld 2104A to you on golden plate. Yes but this one is 2104B OK, modprobe dvb-usb-dw2102 demod=2 brings DVBWorld 2104B to you on golden plate Look what I was tested already: 1. DVB-S2 USB 2104A (EARDA4B47, STB6100 + ST0903) 2. DVB-S2 USB 2104B (sharp0169, stv6110A + ST0903) 3. DVB-S2 USB 2104C (cx24116) 4. DVB-S2 USB 2104D (montage_ts2020 + ds3000) 5. DVB-S2 USB 2104E (SERIT2636, stv6110A + ST0903) If someone interested: md5sum dvb-usb-dw2104*.fw* 4cd4215e169c42f6d05cf23be2edd907 dvb-usb-dw2104.fw 4cd4215e169c42f6d05cf23be2edd907 dvb-usb-dw2104.fw.keep 9ccab99bdd4a0f252455d08dee189794 dvb-usb-dw2104d.fw 9ccab99bdd4a0f252455d08dee189794 dvb-usb-dw2104e.fw BR Igor -- Igor M. Liplianin Microsoft Windows Free Zone - Linux used for all Computing Tasks -- 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
Re: [PATCH] af9015 : more robust eeprom parsing
Terve! And sorry I have been out of the office for few months... Now I am back and I think I have again time for this project... On 03/21/2010 01:14 PM, matthieu castet wrote: the af9015 eeprom parsing accept 0x38 as 2nd demodulator. But this is impossible because the first one is already hardcoded to 0x38. This remove a special case for AverMedia AVerTV Volar Black HD. I don't like this. It adds one more rather unnecessary if(). Of course we can validity check many kind of values from eeprom but I think it is not rather wise. Just trust eeprom and if there is device which does have garbage content in eeprom then add special case for that broken device. Currently AverMedia AVerTV Volar Black HD (A850) is only device I know which does have bad eeprom content. Also in af9015_copy_firmware don't hardcode the 2nd demodulator address to 0x3a. This one looks good. Signed-off-by: Matthieu CASTET castet.matth...@free.fr regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AF9015 suspend problem
Terve! On 05/02/2010 06:39 PM, Jose Alberto Reguero wrote: When I have a af9015 DVB-T stick plugged I can not recover from pc suspend. I must unplug the stick to suspend work. Even if I remove the modules I cannot recover from suspend. Any idea why this happen? Did you asked this 7 months ago from me? I did some tests (http://linuxtv.org/hg/~anttip/suspend/) and looks like it is firmware loader problem (fw loader misses something or like that...). No one answered when I asked that from ML, but few weeks ago I saw some discussion. Look ML archives. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~anttip/af9015/
Terve! On 05/05/2010 05:00 PM, Simon Kenyon wrote: as an aside: i bought two of these on ebay and if antti wants one so that he can support it then just drop me an email with a postal address and i'll send it Hou, I have been out of this project some time. But now I have time, maybe whole summer :] Please send one stick and I can see what I can do. http://palosaari.fi/linux/ regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: anysee e30 suspend-resume causes wrong profiling of card.
Terve Hans, On 03/14/2012 05:53 PM, Hans van den Bogert wrote: The anysee driver works correctly from cold boot and reinsertion of the device, however, after a suspend resume cycle (S3), the device suddenly is initated as dvb-t as where it was dvb-c before. Yes this is a combo device, so dvb T and C, but why does the profiling in anysee.c not handle this case? Obviously the following snippet produces a false positive on warm boot and resume: This is known problem. Actually it is coming from wrong GPIOs / demodulator selection logic. I just guessed those in the time driver was made. Now I have also correct info. Unfortunately I don't even have this device currently... IIRC you can blacklist zl10353 driver as workaround. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Stuck Digittrade DVB-T stick (dvb_usb_af9015)
Terve Marc, On 05/13/2010 12:14 AM, marc balta wrote: * when this happens (stuck device) only a reboot or unplugging the stick helps. Reloading all dvb modules helps nothing. So the problem might be the firmware? Problem : device hangs sometimes. It is known problem and hard to fix because it takes so long to reproduce. I have few ideas to test but unfortunately I have been too busy... Lets if I can find some time. regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: AVerTV Volar HD PRO (A835)
Terve Honza, On 04/28/2010 01:59 AM, Honza Stodola wrote: I'm trying to use AVerTV Volar HD PRO (A835) in Linux, but it seems the USB receiver is not supported by current kernel (2.6.34-rc5). Sending some logs and configuration, let me know if you need some more. Any help is appreciated. lsusb looks like AF9035. Could you look windows driver .inf file content and file names to ensure that? regards Antti -- http://palosaari.fi/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Staging: saa7134-go7007: replace dma_sync_single with dma_sync_single_for_cpu
Thanks, Tomonori.
Does this need to get submitted to the linux-media tree as well, or will
this patch get pulled automatically from Linus' tree?
Thanks,
Pete Eberlein
On Thu, 2010-05-13 at 12:45 +0900, FUJITA Tomonori wrote:
dma_sync_single() is deprecated and will be removed soon.
No functional change since dma_sync_single is the wrapper of
dma_sync_single_for_cpu.
saa7134-go7007.c is commented out but anyway let's replace it.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
drivers/staging/go7007/saa7134-go7007.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/go7007/saa7134-go7007.c
b/drivers/staging/go7007/saa7134-go7007.c
index b25d7d2..0d36ce7 100644
--- a/drivers/staging/go7007/saa7134-go7007.c
+++ b/drivers/staging/go7007/saa7134-go7007.c
@@ -242,13 +242,13 @@ static void saa7134_go7007_irq_ts_done(struct
saa7134_dev *dev,
printk(KERN_DEBUG saa7134-go7007: irq: lost %ld\n,
(status 16) 0x0f);
if (status 0x10) {
- dma_sync_single(dev-pci-dev,
- saa-bottom_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-bottom_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-bottom, PAGE_SIZE);
saa_writel(SAA7134_RS_BA2(5), cpu_to_le32(saa-bottom_dma));
} else {
- dma_sync_single(dev-pci-dev,
- saa-top_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-top_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-top, PAGE_SIZE);
saa_writel(SAA7134_RS_BA1(5), cpu_to_le32(saa-top_dma));
}
--
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] Staging: saa7134-go7007: replace dma_sync_single with dma_sync_single_for_cpu
On Thu, 13 May 2010 15:25:24 -0700
Pete Eberlein p...@sensoray.com wrote:
Thanks, Tomonori.
Does this need to get submitted to the linux-media tree as well, or will
this patch get pulled automatically from Linus' tree?
I think that patches for staging drivers are merged via Greg's staging
tree.
Thanks,
Pete Eberlein
On Thu, 2010-05-13 at 12:45 +0900, FUJITA Tomonori wrote:
dma_sync_single() is deprecated and will be removed soon.
No functional change since dma_sync_single is the wrapper of
dma_sync_single_for_cpu.
saa7134-go7007.c is commented out but anyway let's replace it.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
drivers/staging/go7007/saa7134-go7007.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/go7007/saa7134-go7007.c
b/drivers/staging/go7007/saa7134-go7007.c
index b25d7d2..0d36ce7 100644
--- a/drivers/staging/go7007/saa7134-go7007.c
+++ b/drivers/staging/go7007/saa7134-go7007.c
@@ -242,13 +242,13 @@ static void saa7134_go7007_irq_ts_done(struct
saa7134_dev *dev,
printk(KERN_DEBUG saa7134-go7007: irq: lost %ld\n,
(status 16) 0x0f);
if (status 0x10) {
- dma_sync_single(dev-pci-dev,
- saa-bottom_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-bottom_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-bottom, PAGE_SIZE);
saa_writel(SAA7134_RS_BA2(5), cpu_to_le32(saa-bottom_dma));
} else {
- dma_sync_single(dev-pci-dev,
- saa-top_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-top_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-top, PAGE_SIZE);
saa_writel(SAA7134_RS_BA1(5), cpu_to_le32(saa-top_dma));
}
--
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: AF9015 suspend problem
El Jueves, 13 de Mayo de 2010, Antti Palosaari escribió: Terve! On 05/02/2010 06:39 PM, Jose Alberto Reguero wrote: When I have a af9015 DVB-T stick plugged I can not recover from pc suspend. I must unplug the stick to suspend work. Even if I remove the modules I cannot recover from suspend. Any idea why this happen? Did you asked this 7 months ago from me? I did some tests (http://linuxtv.org/hg/~anttip/suspend/) and looks like it is firmware loader problem (fw loader misses something or like that...). No one answered when I asked that from ML, but few weeks ago I saw some discussion. Look ML archives. regards Antti I think that is another problem. If I blacklist the af9015 driver and have the stick plugged in, the suspend don't finish, and the system can't resume. If I unplugg the stick the suspend feature work well. Jose Alberto -- 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] Staging: saa7134-go7007: replace dma_sync_single with dma_sync_single_for_cpu
FUJITA Tomonori wrote:
On Thu, 13 May 2010 15:25:24 -0700
Pete Eberlein p...@sensoray.com wrote:
Thanks, Tomonori.
Does this need to get submitted to the linux-media tree as well, or will
this patch get pulled automatically from Linus' tree?
I think that patches for staging drivers are merged via Greg's staging
tree.
In the specific case of staging drivers for go7007, tm6000 and cx25821,
those patches are going via v4l-dvb git tree.
Thanks,
Pete Eberlein
On Thu, 2010-05-13 at 12:45 +0900, FUJITA Tomonori wrote:
dma_sync_single() is deprecated and will be removed soon.
No functional change since dma_sync_single is the wrapper of
dma_sync_single_for_cpu.
saa7134-go7007.c is commented out but anyway let's replace it.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
drivers/staging/go7007/saa7134-go7007.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/go7007/saa7134-go7007.c
b/drivers/staging/go7007/saa7134-go7007.c
index b25d7d2..0d36ce7 100644
--- a/drivers/staging/go7007/saa7134-go7007.c
+++ b/drivers/staging/go7007/saa7134-go7007.c
@@ -242,13 +242,13 @@ static void saa7134_go7007_irq_ts_done(struct
saa7134_dev *dev,
printk(KERN_DEBUG saa7134-go7007: irq: lost %ld\n,
(status 16) 0x0f);
if (status 0x10) {
- dma_sync_single(dev-pci-dev,
- saa-bottom_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-bottom_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-bottom, PAGE_SIZE);
saa_writel(SAA7134_RS_BA2(5), cpu_to_le32(saa-bottom_dma));
} else {
- dma_sync_single(dev-pci-dev,
- saa-top_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-top_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-top, PAGE_SIZE);
saa_writel(SAA7134_RS_BA1(5), cpu_to_le32(saa-top_dma));
}
--
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
--
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] Staging: saa7134-go7007: replace dma_sync_single with dma_sync_single_for_cpu
On Thu, 13 May 2010 22:27:25 -0300
Mauro Carvalho Chehab mche...@redhat.com wrote:
FUJITA Tomonori wrote:
On Thu, 13 May 2010 15:25:24 -0700
Pete Eberlein p...@sensoray.com wrote:
Thanks, Tomonori.
Does this need to get submitted to the linux-media tree as well, or will
this patch get pulled automatically from Linus' tree?
I think that patches for staging drivers are merged via Greg's staging
tree.
In the specific case of staging drivers for go7007, tm6000 and cx25821,
those patches are going via v4l-dvb git tree.
I see, now I resend the patch to linux-media.
For further information about the background:
http://marc.info/?t=12735405242r=1w=2
Thanks,
=
From: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
Subject: [PATCH] Staging: saa7134-go7007: replace dma_sync_single with
dma_sync_single_for_cpu
dma_sync_single() is deprecated and will be removed soon.
No functional change since dma_sync_single is the wrapper of
dma_sync_single_for_cpu.
saa7134-go7007.c is commented out but anyway let's replace it.
Signed-off-by: FUJITA Tomonori fujita.tomon...@lab.ntt.co.jp
---
drivers/staging/go7007/saa7134-go7007.c |8
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/go7007/saa7134-go7007.c
b/drivers/staging/go7007/saa7134-go7007.c
index b25d7d2..0d36ce7 100644
--- a/drivers/staging/go7007/saa7134-go7007.c
+++ b/drivers/staging/go7007/saa7134-go7007.c
@@ -242,13 +242,13 @@ static void saa7134_go7007_irq_ts_done(struct saa7134_dev
*dev,
printk(KERN_DEBUG saa7134-go7007: irq: lost %ld\n,
(status 16) 0x0f);
if (status 0x10) {
- dma_sync_single(dev-pci-dev,
- saa-bottom_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-bottom_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-bottom, PAGE_SIZE);
saa_writel(SAA7134_RS_BA2(5), cpu_to_le32(saa-bottom_dma));
} else {
- dma_sync_single(dev-pci-dev,
- saa-top_dma, PAGE_SIZE, DMA_FROM_DEVICE);
+ dma_sync_single_for_cpu(dev-pci-dev,
+ saa-top_dma, PAGE_SIZE,
DMA_FROM_DEVICE);
go7007_parse_video_stream(go, saa-top, PAGE_SIZE);
saa_writel(SAA7134_RS_BA1(5), cpu_to_le32(saa-top_dma));
}
--
1.6.5
--
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
[PULL] http://linuxtv.org/hg/~dougsland/v4l-dvb
Hello Mauro, Please pull from http://linuxtv.org/hg/~dougsland/v4l-dvb for the following: - ir-core-priv.h: error: field 'rx_work' has incomplete type Thanks Douglas -- 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
