Re: Re: [RFC] Serialization flag example
After looking at the proposed solution, I personally find the suggestion for a serialization flag to be quite ridiculous. As others have mentioned, the mere presence of the flag means that driver writers will gloss over any concurrency issues that might exist in their driver on the mere assumption that specifying the serialization flag will handle it all for them. As the author of the most recent patches to radio-mr800, the proposed changes not only add additional complexity to the driver but also remove some of the fundamental error checking within the driver. Despite the fact the error check might not always be successful, it will still catch the majority of cases. I therefore NACK the proposed patches to this driver. The right thing to do is to actually correct the issue within all the drivers that need it. Is this a lot of work? Maybe, but it's a far better solution as each driver will be responsible for concurrency issues that it may or may not have. After all, wasn't this what the removal of the BKL was about in the first place? Regards, David Ellingsworth -- 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 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core
Andy Walls wrote:
> On Fri, 2010-04-02 at 22:32 -0300, Mauro Carvalho Chehab wrote:
>> Andy Walls wrote:
>
>>> I haven't taken a very hard look at this since I'm very busy this month.
>>>
>>> It looks OK so far.
>> Thank you for your review.
>>
>> One general comment: my main target of writing the NEC decoder is to have one
>> decoder for testing. I know that there are several other implementations, so
>> I
>> didn't try to write a perfect decoder, but, instead, I wrote a code that
>> works, and that allows me to continue the Remote Controller subsystem design.
>
> Understood.
Btw, I just finish rewriting the nec decoder:
http://git.linuxtv.org/mchehab/ir.git?a=blob;f=drivers/media/IR/ir-nec-decoder.c;h=33b260f517f509efd9c55067eb89c8cd748ed12c;hb=09b1808271b3d705b839ee3239fd1c85b7289f41
I've got your constants and a few of your ideas, but the code is different:
instead of getting a pulse/mark pair, the code handles event by event. Also,
it is controlled by a state machine.
The end result is that the code seems very reliable. It also handles both NEC
and NEC extended.
(btw, I just noticed that I named the bit0/bit1 symbols wrong - the timings
there
are just for space - I'll write a patch fixing it).
>> I've changed on a latter patch my decoder to work with just the duration
>> of the bits.
>>
>> After reviewing the datasheet, now I think I know how to program IRQ to
>> trigger on both edges. So, my idea is to enable it and rewrite the decoder.
>
> So that brings up and interesting decoder design requirement.
>
> Is it the case that some drivers will only be able to perform leading
> edge detection (measuring time between marks) or trailing edge detection
> (measuring time between spaces)?
In the specific case of saa7134, the IRQ can be enabled for a positive and/or
for a negative edge.
I'm not sure about the other IRQ driven hardware. On cx88, there's no IRQ code
for IR - maybe it is not supported. I haven't check yet how IRQ's work on bttv.
I've no idea about the other devices that support raw IR decoding.
>> Yes, I know. By max/min, I've meant to handle delta variations around
>> the main time, since the driver may miss the exact moment where it were
>> supposed to collect the timestamp.
>
> Yes, and the remote's oscillator can be pretty far off for the ideal
> timing too.
I noticed.
>>> Both of the NEC remotes that I own use the extended protocol, IIRC.
>> I found one NEC IR here that uses the extended protocol. The issue I have
>> here is that
>> maybe it could be interesting to allow enable or disable a more pedantic
>> check.
>> At least on the room I'm working, I have two strong fluorescent lamps that
>> interfere
>> on the IR sensor of the saa7134 board. I'll probably add a sysfs node to
>> allow enable/
>> disable the strict check for non-extended protocol.
>
> Would that make the setting global or would it be on a per remote
> control basis?
The protocol sysfs nodes are per device. Yet, for now, I haven't created
such node.
> The way I handled extended NEC addressing or stardard NEC addressing was
> implicit given the specified expected remote control address.
>
> For setting the adress for which to watch I did something like
>
> if ((specified_address & 0xff00) == 0) {
> /* Store the 8 bit NEC address in 16 bits as A'A */
> ir_input->addr = (specified_address ^ 0xff) << 8 |
> specified_address;
> } else {
> /* Store a 16 bit Extended NEC address directly */
> ir_input->addr = specified_address;
> }
Seems ok to me. I've used the same concept on my code.
> And then when checking the incoming remote code:
>
> if (ir_input->addr != decoded_addr)
> return;
>
> The requirement for proper bit complement of an 8-bit address was
> encoded in the expected 16-bit address. So if what it decoded as an
> address didn't match the expected 16 bits, it discarded the code.
>
>
> I don't know if a driver or end user can set the expectaion of a remote
> control's NEC address in your recent design (or if the intent was to not
> require it and use discovery).
Well, bet to let it as-is. If later needed, it would be easy to add a sysfs
node parameter to control 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] fix dvb frontend lockup
matthieu castet a écrit : matthieu castet a écrit : Hi, With my current kernel (2.6.32), if my dvb device is removed while in use, I got [1]. After checking the source code, the problem seems to happen also in master : If there are users (for example users == -2) : - dvb_unregister_frontend : - stop kernel thread with dvb_frontend_stop : - fepriv->exit = 1; - thread loop catch stop event and break while loop - fepriv->thread = NULL; and fepriv->exit = 0; - dvb_unregister_frontend wait on "fepriv->dvbdev->wait_queue" that fepriv->dvbdev->users==-1. The user finish : - dvb_frontend_release - set users to -1 - don't wait wait_queue because fepriv->exit != 1 => dvb_unregister_frontend never exit the wait queue. Matthieu [ 4920.484047] khubd D c2008000 0 198 2 0x [ 4920.484056] f64c8000 0046 c2008000 0004 c13fa000 c13fa000 f 64c8000 [ 4920.484066] f64c81bc c2008000 d9d9dce6 0452 0001 f64c8000 c 102daad [ 4920.484075] 00100100 f64c81bc 0286 f0a7ccc0 f0913404 f0cba404 f644de58 f 092b0a8 [ 4920.484084] Call Trace: [ 4920.484102] [] ? default_wake_function+0x0/0x8 [ 4920.484147] [] ? dvb_unregister_frontend+0x95/0xcc [dvb_core] [ 4920.484157] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484168] [] ? dvb_usb_adapter_frontend_exit+0x12/0x21 [dvb_usb] [ 4920.484176] [] ? dvb_usb_exit+0x26/0x88 [dvb_usb] [ 4920.484184] [] ? dvb_usb_device_exit+0x3a/0x4a [dvb_usb] [ 4920.484217] [] ? usb_unbind_interface+0x3f/0xb4 [usbcore] [ 4920.484227] [] ? __device_release_driver+0x74/0xb7 [ 4920.484233] [] ? device_release_driver+0x15/0x1e [ 4920.484243] [] ? bus_remove_device+0x6e/0x87 [ 4920.484249] [] ? device_del+0xfa/0x152 [ 4920.484264] [] ? usb_disable_device+0x59/0xb9 [usbcore] [ 4920.484279] [] ? usb_disconnect+0x70/0xdc [usbcore] [ 4920.484294] [] ? hub_thread+0x521/0xe1d [usbcore] [ 4920.484301] [] ? autoremove_wake_function+0x0/0x2d [ 4920.484316] [] ? hub_thread+0x0/0xe1d [usbcore] [ 4920.484321] [] ? kthread+0x61/0x66 [ 4920.484327] [] ? kthread+0x0/0x66 [ 4920.484336] [] ? kernel_thread_helper+0x7/0x10 Here a patch that fix the issue Signed-off-by: Matthieu CASTET Any news on that -- 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: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Apr 3 19:00:19 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14536:a539e5b68945 git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 04/15] V4L/DVB: ir-core: Add logic to decode IR protocols at the IR core
On Fri, 2010-04-02 at 22:32 -0300, Mauro Carvalho Chehab wrote:
> Andy Walls wrote:
> > I haven't taken a very hard look at this since I'm very busy this month.
> >
> > It looks OK so far.
>
> Thank you for your review.
>
> One general comment: my main target of writing the NEC decoder is to have one
> decoder for testing. I know that there are several other implementations, so
> I
> didn't try to write a perfect decoder, but, instead, I wrote a code that
> works, and that allows me to continue the Remote Controller subsystem design.
Understood.
> >> +/* Start time: 4.5 ms */
> >> +#define MIN_START_TIME390
> >> +#define MAX_START_TIME510
> >
> > Hmmm.
> >
> > An NEC header pulse is nominally16 * 560 us = 8.96 ms
> > An NEC header space is nominally 8 * 560 us = 4.48 ms
> > An NEC repeat header space is nominally 4 * 560 us = 2.24 ms
> >
> > I think you need a more explicit name than {MIN,MAX}_START_TIME.
>
> Part of the problem with this decoder is that it was conceived to work with
> the saa7134 driver. The driver is currently programmed to trigger IRQ on just
> one of the edge (positive or negative, I need to double check). Due to that,
> this time is just half of the time it should be.
Hmm. It is the right time duration for the space in a normal,
non-repeat, header.
> I've changed on a latter patch my decoder to work with just the duration
> of the bits.
>
> After reviewing the datasheet, now I think I know how to program IRQ to
> trigger on both edges. So, my idea is to enable it and rewrite the decoder.
So that brings up and interesting decoder design requirement.
Is it the case that some drivers will only be able to perform leading
edge detection (measuring time between marks) or trailing edge detection
(measuring time between spaces)?
> >> +/* Pulse time: 560 us */
> >> +#define MIN_PULSE_TIME46
> >> +#define MAX_PULSE_TIME66
> >> +
> >> +/* Bit 1 space time: 2.25ms-560 us */
> >> +#define MIN_BIT1_TIME 149
> >> +#define MAX_BIT1_TIME 189
> >> +
> >> +/* Bit 0 space time: 1.12ms-560 us */
> >> +#define MIN_BIT0_TIME 36
> >> +#define MAX_BIT0_TIME 76
> >> +
> >
> > The fundamental unit of time in the NEC protocol is ideally:
> >
> > 4192/197 cycles / 38 kHz = 559978.6 ns ~= 560 ns
> >
> > All other time durations in the NEC protocol are multiples of this unit.
>
> Yes, I know. By max/min, I've meant to handle delta variations around
> the main time, since the driver may miss the exact moment where it were
> supposed to collect the timestamp.
Yes, and the remote's oscillator can be pretty far off for the ideal
timing too.
> > Both of the NEC remotes that I own use the extended protocol, IIRC.
>
> I found one NEC IR here that uses the extended protocol. The issue I have
> here is that
> maybe it could be interesting to allow enable or disable a more pedantic
> check.
> At least on the room I'm working, I have two strong fluorescent lamps that
> interfere
> on the IR sensor of the saa7134 board. I'll probably add a sysfs node to
> allow enable/
> disable the strict check for non-extended protocol.
Would that make the setting global or would it be on a per remote
control basis?
The way I handled extended NEC addressing or stardard NEC addressing was
implicit given the specified expected remote control address.
For setting the adress for which to watch I did something like
if ((specified_address & 0xff00) == 0) {
/* Store the 8 bit NEC address in 16 bits as A'A */
ir_input->addr = (specified_address ^ 0xff) << 8 |
specified_address;
} else {
/* Store a 16 bit Extended NEC address directly */
ir_input->addr = specified_address;
}
And then when checking the incoming remote code:
if (ir_input->addr != decoded_addr)
return;
The requirement for proper bit complement of an 8-bit address was
encoded in the expected 16-bit address. So if what it decoded as an
address didn't match the expected 16 bits, it discarded the code.
I don't know if a driver or end user can set the expectaion of a remote
control's NEC address in your recent design (or if the intent was to not
require it and use discovery).
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
Working Avermedia Duet A188 (saa716x and lgdt3304)
I'm trying to get the Avermedia Duet A188 up and working again (see the list about a year ago) and I'm running into the same problem. I'm using Manu's SAA716x driver, and I've modified the budget version to identify with my card. I copied the vp1028 frontend attach function and modified it to call lgdt3304_attach. When I compile and load, I get two dvb adaptors with frontends, but of course it can't tune successfully because I don't know the i2c address to pass to lgdt3304_attach. This where I need some help. I don't see any other driver using the lgdt3304, and even if there was another one, the i2c address wouldn't be the same. How do I determine the address? It's a ubyte value, so I could even manually try all 256 addresses, but I don't know how to tell if it's successfully addressed or not. Also, seeing as I don't see anyone else using this driver and it's got comments saying "not yet tested," will the driver even work correctly for this application if I get the right address? If not, how do I fix it? Thanks in advance for the help! -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: V4L-DVB drivers and BKL
Mauro Carvalho Chehab wrote: > Hans Verkuil wrote: >> On the DVB side there seem to be only two sources that use the BKL: >> >> linux/drivers/media/dvb/bt8xx/dst_ca.c: lock_kernel(); >> linux/drivers/media/dvb/bt8xx/dst_ca.c: unlock_kernel(); >> linux/drivers/media/dvb/dvb-core/dvbdev.c: lock_kernel(); >> linux/drivers/media/dvb/dvb-core/dvbdev.c: unlock_kernel(); >> linux/drivers/media/dvb/dvb-core/dvbdev.c: unlock_kernel(); >> >> At first glance it doesn't seem too difficult to remove them, but I leave >> that to the DVB experts. > > The main issue is at dvbdev, since it is used by all devices. We need to get > rid > of it. Get rid of its lock_kernel in open and its locked ioctl, or of the dvbdev 'library' itself? > That's said, Stefan Richter sent a patch meant to reduce the issues with > DVB. Unfortunately, I haven't seen any comments on it. It would be really > important > to test his approach. I will attempt to continue with this (convert more drivers if not all, in a properly organized patch series for review), though it won't happen overnight as I'm chronically short of spare time. I.e. if others step in, even better. -- Stefan Richter -=-==-=- -=-- ---== http://arcgraph.de/sr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Aw: Re: [RFC] Serialization flag example
- Original Nachricht Von: Andy Walls An: Mauro Carvalho Chehab Datum: 03.04.2010 02:47 Betreff: Re: [RFC] Serialization flag example > On Fri, 2010-04-02 at 18:15 -0300, Mauro Carvalho Chehab wrote: > > Devin Heitmueller wrote: > > > In the case of a V4L x DVB type of lock, this is not to protect some > memory, but, > > instead, to limit the usage of a hardware that is not capable of > simultaneously > > provide V4L and DVB streams. This is a common case on almost all devices, > but, as > > Hermann pointed, there are a few devices that are capable of doing both > analog > > and digital streams at the same time, but saa7134 driver currently doesn't > support. Mauro, to do digital and analog at once is not restricted to a few devices. The only restriction, except those hybrid tuners do have, is that in dual mode only packed video formats are allowed for analog, since planar formats are using DMA channel five, which is already in use by the TS interface then. > I know a driver that does: Me too ;) and Trent tested on cx88xx, IIRC. > cx18 can handle simultaneous streaming of DTV and analog. Yup. Not to talk about recent PCIe devices. During I'm writing this I watch DVB-S, DVB-T and Composite at once on a single saa7231e on vista. Supports also S2 and HDTV, vbi and radio and can have a dual remote interface. http://www.creatix.de/produkte/multimedia/ctx1924.htm > Some cards have both an analog and digital tuner, so both DTV and analog > can come from an RF source simultaneously. (No locking needed really.) We have quite some such cards with two tuners on the saa7134 since 2005. Also such with three and even four tuners, two of them hybrid. Even the simplest variant, say with a single DVB-S only tuner, can still have external analog baseband at once from TV, STB, VCR or whatever. > Some cards only have one tuner, which means simultaneous streaming is > limited to DTV from RF and analog from baseband inputs. Streaming > analog from an RF source on these cards precludes streaming of DTV. (An > odd locking ruleset when you consider MPEG, YUV, PCM, and VBI from the > bridge chip can independently be streamed from the selected analog > source to 4 different device nodes.) On that mentioned Medion Quad md8080/CTX944 it becomes even more interesting. Each of the two PCI bridges can only handle one digital and one analog stream at once. That one must know. And if RF loopthrough is enabled or not is another important point for its usage configuration. For the two hybrid tuners it is a manual switch the driver doesn't know about. For the two DVB-S tuners it could be switchable in software and one of the LNB connectors could even be used as RF out to another device. (Has usage restrictions) The user can make a lot of decisions how to use such a card and for sure doesn't want to have any limitations only because of the hybrid tuners. Cheers, Hermann > Regards, > Andy > Frohe Ostern! Alles für's Fest der Hasen und Lämmer jetzt im Osterspecial auf Arcor.de: http://www.arcor.de/rd/footer.ostern -- 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
