Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver
On Tue, 2017-10-10 at 08:17 +0100, Sean Young wrote:
> The ir-kbd-i2c module already handles this very well.
Hi Sean:
It's been years, but my recollection is that although ir-kdb-i2c might
handle receive well, but since the 4 i2c addresses (1 Rx, 1 Tx, 1 IR Tx
code learning, 1 custom Tx code) are all handled by the same Zilog
microcontroller internally, that splitting the Rx and Tx functionality
between two modules became problematic.
Believe me, if i could have leveraged ir-kdb-i2c back when I ported
this, I would have. I think it's a very bad idea to remove the
receiver from lirc_zilog.
The cx18 and ivtv drivers both use lirc_zilog IIRC. Have you looked at
the changes required to have the first I2C address used by one i2c
module, and the next one (or three) I2C addresses used by another i2c
module?
-Andy
>
> Signed-off-by: Sean Young
> ---
> drivers/staging/media/lirc/lirc_zilog.c | 901 +++---
> --
> 1 file changed, 76 insertions(+), 825 deletions(-)
>
> diff --git a/drivers/staging/media/lirc/lirc_zilog.c
> b/drivers/staging/media/lirc/lirc_zilog.c
> index 6bd0717bf76e..757b3fc247ac 100644
> --- a/drivers/staging/media/lirc/lirc_zilog.c
> +++ b/drivers/staging/media/lirc/lirc_zilog.c
> @@ -64,28 +64,7 @@
> /* Max transfer size done by I2C transfer functions */
> #define MAX_XFER_SIZE 64
>
> -struct IR;
> -
> -struct IR_rx {
> - struct kref ref;
> - struct IR *ir;
> -
> - /* RX device */
> - struct mutex client_lock;
> - struct i2c_client *c;
> -
> - /* RX polling thread data */
> - struct task_struct *task;
> -
> - /* RX read data */
> - unsigned char b[3];
> - bool hdpvr_data_fmt;
> -};
> -
> struct IR_tx {
> - struct kref ref;
> - struct IR *ir;
> -
> /* TX device */
> struct mutex client_lock;
> struct i2c_client *c;
> @@ -93,39 +72,9 @@ struct IR_tx {
> /* TX additional actions needed */
> int need_boot;
> bool post_tx_ready_poll;
> -};
> -
> -struct IR {
> - struct kref ref;
> - struct list_head list;
> -
> - /* FIXME spinlock access to l->features */
> struct lirc_dev *l;
> - struct lirc_buffer rbuf;
> -
> - struct mutex ir_lock;
> - atomic_t open_count;
> -
> - struct device *dev;
> - struct i2c_adapter *adapter;
> -
> - spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
> - struct IR_rx *rx;
> -
> - spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
> - struct IR_tx *tx;
> };
>
> -/* IR transceiver instance object list */
> -/*
> - * This lock is used for the following:
> - * a. ir_devices_list access, insertions, deletions
> - * b. struct IR kref get()s and put()s
> - * c. serialization of ir_probe() for the two i2c_clients for a Z8
> - */
> -static DEFINE_MUTEX(ir_devices_lock);
> -static LIST_HEAD(ir_devices_list);
> -
> /* Block size for IR transmitter */
> #define TX_BLOCK_SIZE99
>
> @@ -153,348 +102,8 @@ struct tx_data_struct {
> static struct tx_data_struct *tx_data;
> static struct mutex tx_data_lock;
>
> -
> /* module parameters */
> static bool debug; /* debug output */
> -static bool tx_only; /* only handle the IR Tx function */
> -
> -
> -/* struct IR reference counting */
> -static struct IR *get_ir_device(struct IR *ir, bool
> ir_devices_lock_held)
> -{
> - if (ir_devices_lock_held) {
> - kref_get(&ir->ref);
> - } else {
> - mutex_lock(&ir_devices_lock);
> - kref_get(&ir->ref);
> - mutex_unlock(&ir_devices_lock);
> - }
> - return ir;
> -}
> -
> -static void release_ir_device(struct kref *ref)
> -{
> - struct IR *ir = container_of(ref, struct IR, ref);
> -
> - /*
> - * Things should be in this state by now:
> - * ir->rx set to NULL and deallocated - happens before ir-
> >rx->ir put()
> - * ir->rx->task kthread stopped - happens before ir->rx->ir
> put()
> - * ir->tx set to NULL and deallocated - happens before ir-
> >tx->ir put()
> - * ir->open_count == 0 - happens on final close()
> - * ir_lock, tx_ref_lock, rx_ref_lock, all released
> - */
> - if (ir->l)
> - lirc_unregister_device(ir->l);
> -
> - if (kfifo_initialized(&ir->rbuf.fifo))
> - lirc_buffer_free(&ir->rbuf);
> - list_del(&ir->list);
> - kfree(ir);
> -}
> -
> -static int put_ir_device(struct IR *ir, bool ir_devices_lock_held)
> -{
> - int released;
> -
> - if (ir_devices_lock_held)
> - return kref_put(&ir->ref, release_ir_device);
> -
> - mutex_lock(&ir_devices_lock);
> - released = kref_put(&ir->ref, release_ir_device);
> - mutex_unlock(&ir_devices_lock);
> -
> - return released;
> -}
> -
> -/* struct IR_rx reference counting */
> -static struct IR_rx *get_ir_rx(struct IR *ir)
> -{
> - struct IR_rx *rx;
> -
> - spin_lock(&ir->rx_ref_lock);
> - rx = ir->rx;
> - if (rx)
> - kref_get(&rx->ref);
> -
Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver
On October 11, 2017 5:02:37 PM EDT, Sean Young wrote:
>On Wed, Oct 11, 2017 at 03:43:16PM -0400, Andy Walls wrote:
>> On Tue, 2017-10-10 at 08:17 +0100, Sean Young wrote:
>> > The ir-kbd-i2c module already handles this very well.
>>
>> Hi Sean:
>>
>> It's been years, but my recollection is that although ir-kdb-i2c
>might
>> handle receive well, but since the 4 i2c addresses (1 Rx, 1 Tx, 1 IR
>Tx
>> code learning, 1 custom Tx code) are all handled by the same Zilog
>> microcontroller internally, that splitting the Rx and Tx
>functionality
>> between two modules became problematic.
>>
>> Believe me, if i could have leveraged ir-kdb-i2c back when I ported
>> this, I would have. I think it's a very bad idea to remove the
>> receiver from lirc_zilog.
>>
>> The cx18 and ivtv drivers both use lirc_zilog IIRC. Have you looked
>at
>> the changes required to have the first I2C address used by one i2c
>> module, and the next one (or three) I2C addresses used by another i2c
>> module?
>
>This is already the case.
>
>In current kernels you can use ir-kbd-i2c for Rx and lirc_zilog for Tx,
>this works fine. In fact, the lirc_zilog Rx code produces lirccodes,
>(not mode2) and ir-kbd-i2c produces keycodes through rc-core, so
>ir-kbd-i2c
>(also mainline, not staging) is much more likely to be used for Rx. For
>Tx
>you have to use lirc_zilog.
>
>I haven't heard of any reports of problems (or observed this myself)
>when
>using these two modules together.
>
>As you point out, both drivers sending i2c commands to the same z8f0811
>
>with its z8 encore hand-coded i2c implementation. But they're using
>different
>addresses.
>
>So removing the lirc_zilog Rx doesn't make things worse, in fact, it
>just
>removes some code which is unlikely to be used.
>
>It's the hdpvr, ivtv, cx18 and pvrusb2 drivers which have a Tx
>interface. I
>have hdpvr and ivtv hardware to test.
>
>
>Sean
>
>>
>> -Andy
>>
>>
>> >
>> > Signed-off-by: Sean Young
>> > ---
>> > drivers/staging/media/lirc/lirc_zilog.c | 901
>+++---
>> > --
>> > 1 file changed, 76 insertions(+), 825 deletions(-)
>> >
>> > diff --git a/drivers/staging/media/lirc/lirc_zilog.c
>> > b/drivers/staging/media/lirc/lirc_zilog.c
>> > index 6bd0717bf76e..757b3fc247ac 100644
>> > --- a/drivers/staging/media/lirc/lirc_zilog.c
>> > +++ b/drivers/staging/media/lirc/lirc_zilog.c
>> > @@ -64,28 +64,7 @@
>> > /* Max transfer size done by I2C transfer functions */
>> > #define MAX_XFER_SIZE 64
>> >
>> > -struct IR;
>> > -
>> > -struct IR_rx {
>> > - struct kref ref;
>> > - struct IR *ir;
>> > -
>> > - /* RX device */
>> > - struct mutex client_lock;
>> > - struct i2c_client *c;
>> > -
>> > - /* RX polling thread data */
>> > - struct task_struct *task;
>> > -
>> > - /* RX read data */
>> > - unsigned char b[3];
>> > - bool hdpvr_data_fmt;
>> > -};
>> > -
>> > struct IR_tx {
>> > - struct kref ref;
>> > - struct IR *ir;
>> > -
>> >/* TX device */
>> >struct mutex client_lock;
>> >struct i2c_client *c;
>> > @@ -93,39 +72,9 @@ struct IR_tx {
>> >/* TX additional actions needed */
>> >int need_boot;
>> >bool post_tx_ready_poll;
>> > -};
>> > -
>> > -struct IR {
>> > - struct kref ref;
>> > - struct list_head list;
>> > -
>> > - /* FIXME spinlock access to l->features */
>> >struct lirc_dev *l;
>> > - struct lirc_buffer rbuf;
>> > -
>> > - struct mutex ir_lock;
>> > - atomic_t open_count;
>> > -
>> > - struct device *dev;
>> > - struct i2c_adapter *adapter;
>> > -
>> > - spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
>> > - struct IR_rx *rx;
>> > -
>> > - spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
>> > - struct IR_tx *tx;
>> > };
>> >
>> > -/* IR transceiver instance object list */
>> > -/*
>> > - * This lock is used for the following:
>> > - * a. ir_devices_list access, insertions, deletions
>> > - * b. struct IR kref get()s and put()s
>> > - * c. serialization of ir_probe() for the two i2c_clients for a Z8
>> > - */
>>
Re: [PATCH v3 04/26] media: lirc_zilog: remove receiver
Hi Sean and Devin: On Wed, 2017-10-11 at 20:25 -0400, Devin Heitmueller wrote: > > There's an ir_lock mutex in the driver to prevent simultaneous > > access to the Rx and Tx functions of the z8. Accessing Rx and Tx > > functions of the chip together can cause it to do the wrong thing > > (sometimes hang?), IIRC. > > > > I'll see if I can dig up my old disassembly of the z8's firmware to > > see if that interlock is strictly necessary. Following up on this: 1. The I2C bus command and response buffers inside the Z8 appear to be independent and non-overlapping (ignore the garbage assembly mnemonics): ; I2C data buffer addresses 01bf srp #%00 ; 01 00 ; Buffer pointer I2C addr E0 (70w) IR Tx - 160 bytes 01c1 add r0,@r0 ; 03 00 ; Buffer pointer I2C addr E1 (70r) IR Tx - 4 bytes 01c3 add r1,@r5 ; 03 15 ; Buffer pointer I2C addr E2 (71w) IR Rx - 5 bytes 01c5 add r1,@r0 ; 03 10 ; Buffer pointer I2C addr E3 (71r) IR Rx - 5 bytes 01c7 add r0,@r10; 03 0a ; Buffer pointer I2C addr E4 (72w) IR PB1 - 4 bytes 01c9 add r1,@r10; 03 1a ; Buffer pointer I2C addr E5 (72r) IR PB1 - 4 bytes 01cb add r0,@r5 ; 03 05 ; Buffer pointer I2C addr E6 (73w) IR Lrn - 1 bytes 01cd add r0,r0 ; 02 00 ; Buffer pointer I2C addr E7 (73r) IR Lrn - 256 bytes and the I2C handling routines appear to do the right thing in waiting for "full" buffers before operating on them. 2. Z8 Port B is used by both Tx and Rx functions, but the functions each only use 1 line of the I/O port and they use different lines. 3. Z8 Port C is unused. 4. Z8 Port A is used by both Tx functions, Rx functions, the I2C interface. If something inside the Z8 screws up the I2C bus comms with the chip, it's likely the errant misconfiguration of Port A during certain Rx and Tx operations. 5. Rx and IR Learn both use the same external hardware. Not coordinating Rx with Learn mode in the same driver, will prevent Learn operation from working. That is, if Learn mode is ever implemented. (Once upon a time, I was planning on doing that. But I have no time for that anymore.) > > Yes I know ir-kbd-i2c is in mainline, but as I said, I had reasons > > for avoiding it when using Tx operation of the chip. It's been 7 > > years, and I'm getting too old to remember the reasons. :P > > Yeah, you definitely don't want to be issuing requests to the Rx and > Tx addresses at the same time. Very bad things will happen. > > Also, what is the polling interval for ir-kbd-i2c? If it's too high > you can wedge the I2C bus (depending on the hardware design). > Likewise, many people disable IR RX entirely (which is trivial to do > with lirc_zilog through a modprobe optoin). This is because early > versions of the HDPVR had issues where polling too often can > interfere > with traffic that configures the component receiver chip. This was > improved in later versions of the design, but many people found it > was > just easiest to disable RX since they don't use it (i.e. they would > use the blaster for controlling their STB but use a separate IR > receiver). > > Are you testing with video capture actively in use? If you're > testing > the IR interface without an active HD capture in progress you're > likely to miss some of these edge cases (in particular those which > would hang the encoder). I'm glad someone remembers all this stuff. I'm assuming you had more pain with this than I ever did. I never owned an HD-PVR. Regards, Andy > I'm not against the removal of duplicate code in general, but you > have > to tread carefully because there are plenty of non-obvious edge cases > to consider. > > Devin >
Re: [PATCH 14/18] cx25840: Fix subdev registration in cx25840-core.c
Igor,
The proper fix is here:
https://patchwork.kernel.org/patch/376612/
So, NAK on your particular patch.
Mauro,
I do not see the above patch at linux next. And I couldn't find it in your
kernel.org tree. What is its status?
This fixes a regression that is known to break cx23885 hardware initialization
and can break ivtv hardware initialization.
Regards,
Andy
"Igor M. Liplianin" wrote:
>On my system, cx23885 based card reports default volume value above 7.
>So, register cx25840 subdev fails. Although, the card don't have a/v inputs
>it needs a/v firmware to be loaded.
>
>Signed-off-by: Igor M. Liplianin
>---
> drivers/media/video/cx25840/cx25840-core.c |2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
>diff --git a/drivers/media/video/cx25840/cx25840-core.c
>b/drivers/media/video/cx25840/cx25840-core.c
>index dfb198d..dc0cec7 100644
>--- a/drivers/media/video/cx25840/cx25840-core.c
>+++ b/drivers/media/video/cx25840/cx25840-core.c
>@@ -1991,6 +1991,8 @@ static int cx25840_probe(struct i2c_client *client,
> if (!is_cx2583x(state)) {
> default_volume = 228 - cx25840_read(client, 0x8d4);
> default_volume = ((default_volume / 2) + 23) << 9;
>+ if (default_volume > 65535)
>+ default_volume = 65535;
>
> state->volume = v4l2_ctrl_new_std(&state->hdl,
> &cx25840_audio_ctrl_ops, V4L2_CID_AUDIO_VOLUME,
>--
>1.7.1
>
>--
>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
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Summary of REGRESSIONS which are being ignored?! (Re: Summary of the pending patches up to Dec, 31 (26 patches))
On Fri, 2010-12-31 at 10:41 -0200, Mauro Carvalho Chehab wrote: > Dear Developers, > > I'm enclosing the current list of patches that I have on my queue. I did > an effort to apply a large amount of patches during the past two weeks, in > order to be ready for the 2.6.38 merge window, expected to be after > the end year's holiday. > > I lost about one month of emails from the period between Nov-Dec, so > I may have lost a pull request, or some patch comments. I had to fully > rely on patchwork for the patches sent during that period. Hi Mauro, I don't see this patch on it's way upstream: https://patchwork.kernel.org/patch/376612/ (Sent on 5 Dec 2010) http://www.spinics.net/lists/linux-media/msg26649.html (Resent on 19 Dec 2010) It fixes a regression in IR and Analog video for cx23885 based cards and an intermittent analog video regression in ivtv based cards in 2.6.36 and soon in 2.6.37. I don't see it in the media_tree staging/for_v2.6.38 nor staging/for_2.6.37-rc1 nor master: http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=staging/for_v2.6.38 http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=master http://git.linuxtv.org/media_tree.git?a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=staging/for_v2.6.37-rc1 I don't see it at a very recent linux-next: http://git.kernel.org/?p=linux/kernel/git/next/linux-next.git;a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=bfa221f25c0ec816f725c3a145bda4ee65a277ff I don't see it at your kernel.org linux-next tree: http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=history;f=drivers/media/video/cx25840/cx25840-core.c;h=dfb198d0415bc200b0152c1be105d722261653c5;hb=refs/heads/master Am I missing something? I cannot get this *REGRESSION*, which I did not introduce, fixed in stable tree(s) until it is upstream. Also this following commit causes a very bad analog audio *REGRESSION*, which is now shipping in major distirbutions: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864 I emailed the LMML, you, and the author, as soon as I verified the root cause on 31 Dec, and haven't heard from from anyone: http://www.spinics.net/lists/linux-media/msg27261.html Please revert it before the merge window closes. I have no time to make improvements that I want to make, much less waste my *VOLUNTEER* time on *REGRESSIONS* that *I DID NOT INTRODUCE*. It bothers me enough, that as a volunteer, I have to clean up other people's untested cr*pware. AND, that as the lucky individual who finds the bugs, I have to do additional work to get fixes back into stable kernels. Watching my requests for regressions to be fixed be ignored, as merge windows go by without the fixes going forward so that even more users and kernel versions are affected, makes me wonder why I do this anymore. Anyone want to be ivtv and cx18 maintainer? > Kernel 2.6.38 will be a nice Kernel for us, as it will contain some > very interesting things: > - The removal of BKL (in fact, .37 will have that also, but > we have some BKL cleanups already for .38, and I suspect that we'll > have some bug fixes for the changes during the .38 rc period); > - The removal of V4L1 API. We're trying to remove it for a > very long time. V4L2 API is here since 2002. That means that we took > 8 years to remove the legacy API. > - The merge between lirc_i2c and ir-kbd-i2c. The LIRC i2c driver > is also very old, and there were several IR key parsers implemented > on both. The missing things were migrated into ir-kbd-i2c and some > board-specific get key parsers into their respective boards. > > Due to that, we have enough reasons to celebrate the end of this year > and the arrival of the next year. I do not share your optimism. Regressions that affect the analog video capture, for the userbase I deal with, have been introduced due to lack of review and testing. It appears to me, that these regessions are going to be in yet another kernel version, 2.6.37, and the gates for getting the known fixes back into stable kernels will still be left unsatisfied. > Cheers! I, nor PVR-150 and HVR-1250 users, have much to cheer about. Regards, Andy > I wish you all the best for the coming year! > > P.S.: > > 1) I explicitly c/c the developers or the ones waiting for an analysis. >If you're a developer and were c/c, please comment on the listed >patches. > 2) I removed the Videobuf2 patches from the list. I expect to be >analyzing and testing them during the next week. > > == Need more tests/acks from DVB users == > > Aug, 7 2010: Avoid unnecessary data copying inside dvb_dmx_swfilter_204() > function http:
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Sun, 2011-01-02 at 23:00 -0500, Eric Sharkey wrote: > On Fri, Dec 31, 2010 at 7:55 PM, Andy Walls wrote: > > Mauro, > > > > Please revert at least the wm8775.c portion of commit > > fcb9757333df37cf4a7feccef7ef6f5300643864: > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864 > > > > It completely trashes baseband line-in audio for PVR-150 cards, and > > likely does the same for any other ivtv card that has a WM8775 chip. > > Confirmed. I manually rolled back most of the changes in that commit > for wm8775.c, leaving all other files alone, and the audio is now > working correctly for me. I haven't yet narrowed it down to exactly > which changes in that file cause the problem. I'll try and do that > tomorrow if I have time. This might help then: http://dl.ivtvdriver.org/datasheets/audio/WM8775.pdf I don't have time to look, but I'm hoping it is just the initialization in wm8775_probe(). Without both a PVR-150 card and a Nova-S-plus DVB-S with which to test you are unlikely to get an initialization that works for both the Nova-S Plus and PVR-150. Even if you did, such a configuration would be "fragile" in that it will be hard to tweak in the future for one card without breaking the other. (Code reuse doesn't work out too well for setting up hardware parameters.) The fix will probably have to use some context sensitive initialization in wm8775_probe(): "Am I being called by ivtv for a PVR-150 or cx88 for a Nova-S plus?" Which probably means: 1. adding a ".s_config" method to the "wm8775_core_ops" See: http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/v4l2-framework.txt;h=f22f35c271f38d34fda0c19d8942b536e2fc95d9;hb=staging/for_v2.6.38#l206 http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l109 http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l141 2. developing a "struct wm8775_platform_data" type that can be used to indicate the needs for the Nova-S versus the PVR-150 and any other legacy boards that use the wm8775 module That structure should probably be defined here: http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/wm8775.h;h=a1c4d417dfa205e8d5c2cf1d4f9d6bbd7a6ec419;hb=staging/for_v2.6.38 3. writing the corresponding "wm8775_s_config" function in wm8775.c to setup the WM8775 based on the arguments passed in the "platform_data". Note that this function may get called at least once initially by the v4l2 infrastructure with "irq" set to 0 and "platform_data" set to NULL. See: http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/v4l2-framework.txt;h=f22f35c271f38d34fda0c19d8942b536e2fc95d9;hb=staging/for_v2.6.38#l399 4. Fixing the wm8775_probe() function to do something sensible, knowing that the .s_config method may get called once by the infrastructure, and/or once again by the cx88 driver or the ivtv driver. 5. Searching through the video drivers to see if any other drivers may use the wm8775 module, and validating that your changes won't break them. All I see with a quick grep is cx88, ivtv, and pvrusb2 6. Testing with real hardware Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Summary of REGRESSIONS which are being ignored?! (Re: Summary of the pending patches up to Dec, 31 (26 patches))
On Mon, 2011-01-03 at 09:49 -0200, Mauro Carvalho Chehab wrote: > Em 02-01-2011 17:30, Andy Walls escreveu: > > I don't see this patch on it's way upstream: > > > > https://patchwork.kernel.org/patch/376612/ (Sent on 5 Dec 2010) > > http://www.spinics.net/lists/linux-media/msg26649.html (Resent on 19 Dec > > 2010) > > > > It fixes a regression in IR and Analog video for cx23885 based cards and > > an intermittent analog video regression in ivtv based cards in 2.6.36 > > and soon in 2.6.37. > > Not sure what happened here. I'm sure I've applied on my fixes tree. > Anyway, I'm re-applying it. Thank you. > > I emailed the LMML, you, and the author, as soon as I verified the root > > cause on 31 Dec, and haven't heard from from anyone: > > > > http://www.spinics.net/lists/linux-media/msg27261.html > > Here, Dec, 31 is a national holiday. People work only half of the day. > Yet, I was finishing some things and preparing patches for the incoming > window, until afternoon. I understand. But AFAIK the 2.6.37 final is supposed to happen very soon and the end user effects of the problem are very bad. > I only noticed your email today, and I'm promptly sending it upstream, > together with a patch revert for wm8775 regression. > > > Please revert it before the merge window closes. > > I'm sending it right now. Thank you. -Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/32] v4l/cx18: update workqueue usage
On Mon, 2011-01-03 at 14:49 +0100, Tejun Heo wrote:
> With cmwq, there's no reason to use separate out_work_queue. Drop it
> and use system_wq instead. The in_work_queue needs to be ordered so
> can't use one of the system wqs; however, as it isn't used to reclaim
> memory, allocate the workqueue with alloc_ordered_workqueue() without
> WQ_MEM_RECLAIM.
>
> Signed-off-by: Tejun Heo
> Cc: Andy Walls
> Cc: linux-media@vger.kernel.org
Tejun,
I have a question about cmwq, but to ask it, I need to give the context.
The non-system out_work_queue in cx18 had two purposes:
1. To prevent a userspace video rendering application from sleeping in
read(), when it had emptied a cx18 driver DMA buffer and the cx18 driver
had to sleep to notify the CX2318 engine that the buffer was available
again.
Your change has no adverse effect on this.
2. To prevent work items being handled by keventd/n from being delayed
too long, as the deferred work in question can involve a bit of sleeping
due to contention, the workload of the CX23418's MPEG encoding engine,
and the number of CX23418 devices in the system.
Will all the sleeping that can happen, is the move to a system wq, under
cmwq, going to have adverse affects on processing other work items in
the system?
I get the feeling it won't be a problem with cmwq, but I haven't paid
enough attention to be sure.
Here are some gory details, if it helps:
A single CX23418 has *one* cx18 driver to CX23418 Capture Processing
Unit (epu2cpu_mb) mailbox though which the cx18 driver sends all normal
commands along with a notification interrupt to the CX23418.
The CX23418 will acknowledge all commands with ack back in the mailbox
and an interrupt for the cx18 driver. Sometimes the ack happens right
away. Sometimes the cx18 driver has to wait(), if the CX23418 is
busy.
The cx18 driver uses a mutex (epu2cpu_mb_lock) to protect cx18 driver
access to the one epu2cpu_mb mailbox. The mutex is grabbed and released
on a per epu2cpu_mb mailbox command basis
To tell the CX23418 about a usable empty buffer for DMA, one epu2cpu
mailbox command (CX18_CPU_DE_SET_MDL) must be performed for each usable
empty buffer.
A CX23418 can support multiple, simultaneous logical capture streams at
once. The streams for a DVB TS, analog video converted to MPEG, VBI
data, and the MPEG Index data are common to have active simultaneously.
The CX23418 can keep track of 63 empty buffers for each active stream
and the cx18 driver tries to ensure the CX23418 always has as close to
63 as possible available at any time.
The out_work_handler, when triggered for a capture stream type, will try
to perform, as needed, from 1 to 63 CX18_CPU_DE_SET_MDL mailbox commands
for that stream. At steady state, the number of CX18_CPU_DE_SET_MDL
mailbox commands executed one after the other in a batch will likely be
from 1 to 3.
It is not unusual for a non-commercial end user to have 2 or 3 CX23418
based capture cards in one machine. I am aware of at least one
commercial user that had 5 CX23418 based cards in a modest machine.
It is not unusual for scheduled TV recording software to start nearly
simultaneous DTV TS, MPEG, and VBI or MPEG Index streams on multiple
cards. So 3 CX23418 cards with 3 streams each. Let's nominally
estimate the timing of the CX18_CPU_DE_SET_MDL commands per stream at
the PAL frame rate of 25 Hz; or 1 CX18_CPU_DE_SET_MDL mailbox command
per stream per 40 milliseconds.
Regards,
Andy
> ---
> Only compile tested. Please feel free to take it into the subsystem
> tree or simply ack - I'll route it through the wq tree.
>
> Thanks.
>
> drivers/media/video/cx18/cx18-driver.c | 24 ++--
> drivers/media/video/cx18/cx18-driver.h |3 ---
> drivers/media/video/cx18/cx18-streams.h |3 +--
> 3 files changed, 3 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/media/video/cx18/cx18-driver.c
> b/drivers/media/video/cx18/cx18-driver.c
> index df60f27..41c0822 100644
> --- a/drivers/media/video/cx18/cx18-driver.c
> +++ b/drivers/media/video/cx18/cx18-driver.c
> @@ -656,7 +656,7 @@ static int __devinit cx18_create_in_workq(struct cx18 *cx)
> {
> snprintf(cx->in_workq_name, sizeof(cx->in_workq_name), "%s-in",
>cx->v4l2_dev.name);
> - cx->in_work_queue = create_singlethread_workqueue(cx->in_workq_name);
> + cx->in_work_queue = alloc_ordered_workqueue(cx->in_workq_name, 0);
> if (cx->in_work_queue == NULL) {
> CX18_ERR("Unable to create incoming mailbox handler thread\n");
> return -ENOMEM;
> @@ -664,18 +664,6 @@ static int __devinit cx18_create_in_workq(struct cx18
> *cx)
> return 0;
> }
>
> -static int __devinit cx18_create_out_workq(struct cx18 *cx)
> -{
> -
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Tue, 2011-01-04 at 08:10 +0100, Hans Verkuil wrote: > On Monday, January 03, 2011 23:34:16 Andy Walls wrote: > > On Sun, 2011-01-02 at 23:00 -0500, Eric Sharkey wrote: > > > On Fri, Dec 31, 2010 at 7:55 PM, Andy Walls > > > wrote: > > > > Mauro, > > > > > > > > Please revert at least the wm8775.c portion of commit > > > > fcb9757333df37cf4a7feccef7ef6f5300643864: > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864 > > > > > > > > It completely trashes baseband line-in audio for PVR-150 cards, and > > > > likely does the same for any other ivtv card that has a WM8775 chip. > > > > > > Confirmed. I manually rolled back most of the changes in that commit > > > for wm8775.c, leaving all other files alone, and the audio is now > > > working correctly for me. I haven't yet narrowed it down to exactly > > > which changes in that file cause the problem. I'll try and do that > > > tomorrow if I have time. > > > > This might help then: > > > > http://dl.ivtvdriver.org/datasheets/audio/WM8775.pdf > > > > I don't have time to look, but I'm hoping it is just the initialization > > in wm8775_probe(). > > > > Without both a PVR-150 card and a Nova-S-plus DVB-S with which to test > > you are unlikely to get an initialization that works for both the Nova-S > > Plus and PVR-150. Even if you did, such a configuration would be > > "fragile" in that it will be hard to tweak in the future for one card > > without breaking the other. (Code reuse doesn't work out too well for > > setting up hardware parameters.) > > > > The fix will probably have to use some context sensitive initialization > > in wm8775_probe(): "Am I being called by ivtv for a PVR-150 or cx88 for > > a Nova-S plus?" > > > > Which probably means: > > > > 1. adding a ".s_config" method to the "wm8775_core_ops" > > See: > > http://git.linuxtv.org/media_tree.git?a=blob;f=Documentation/video4linux/v4l2-framework.txt;h=f22f35c271f38d34fda0c19d8942b536e2fc95d9;hb=staging/for_v2.6.38#l206 > > http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l109 > > http://git.linuxtv.org/media_tree.git?a=blob;f=include/media/v4l2-subdev.h;h=b0316a7cf08d21f2ac68f1dc452894441948c155;hb=staging/for_v2.6.38#l141 > > Don't use .s_config! That will be removed soon. > > Use platform_data and v4l2_i2c_new_subdev_board instead. Gah! Sorry. I knew that .init had been deprecated. The comments in v4l2_subdev.h indicate that .init is deprecated, but do not do the same for .s_config. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/32] v4l/cx18: update workqueue usage
On Tue, 2011-01-04 at 09:36 +0100, Tejun Heo wrote: > Hello, > > On Mon, Jan 03, 2011 at 07:54:56PM -0500, Andy Walls wrote: > > 2. To prevent work items being handled by keventd/n from being delayed > > too long, as the deferred work in question can involve a bit of sleeping > > due to contention, the workload of the CX23418's MPEG encoding engine, > > and the number of CX23418 devices in the system. > > > > Will all the sleeping that can happen, is the move to a system wq, under > > cmwq, going to have adverse affects on processing other work items in > > the system? > > > > I get the feeling it won't be a problem with cmwq, but I haven't paid > > enough attention to be sure. > > It won't be a problem. Now the system_wq supports parallel execution > of multiple works and manages concurrency automatically. Work items > can sleep as necessary without worrying about other work items. OK, that's what I thought. I just wanted to ensure that busy CX23418 chips are not going to delay the processing of other work-events in the rest the system down. > ... > > It is not unusual for scheduled TV recording software to start nearly > > simultaneous DTV TS, MPEG, and VBI or MPEG Index streams on multiple > > cards. So 3 CX23418 cards with 3 streams each. Let's nominally > > estimate the timing of the CX18_CPU_DE_SET_MDL commands per stream at > > the PAL frame rate of 25 Hz; or 1 CX18_CPU_DE_SET_MDL mailbox command > > per stream per 40 milliseconds. > > IIUC, if they spend any significant amount of time executing, they'll > be doing so by waiting for events (mutex, IRQ...), right? Right. As a CX23418 is expected to do more streaming by the host, the mailbox mutex contention goes up and the latency of the CX23418 responding to mailbox commands also goes up so there is more wait()ing. > If so, > there's nothing to worry about. If it's gonna burn a lot of CPU > cycles, we'll need to use a workqueue marked CPU_INTENSIVE but I don't > think that's the case here. Correct, CPU is not the concern here. > Thank you. Thanks. I'll do a proper inspection of the patch tonight. It looked OK on cursory review. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hdpvr: Add I2C and ir-kdb-i2c registration of the Zilog Z8 IR chip
On Wed, 2011-01-05 at 13:50 +0100, Jean Delvare wrote: > On Tue, 28 Dec 2010 20:46:13 -0500, Andy Walls wrote: > > > > Add I2C registration of the Zilog Z8F0811 IR microcontroller for either > > lirc_zilog or ir-kbd-i2c to use. This is a required step in removing > > lirc_zilog's use of the deprecated struct i2c_adapter.id field. > > > > Signed-off-by: Andy Walls > > --- > > drivers/media/video/hdpvr/hdpvr-core.c |5 +++ > > drivers/media/video/hdpvr/hdpvr-i2c.c | 53 > > > > drivers/media/video/hdpvr/hdpvr.h |6 +++ > > 3 files changed, 64 insertions(+), 0 deletions(-) > > Looks good to me (even though it looks strange to update code which is > apparently disabled for quite a while...) Yes it is odd. My intent was ensure that after removal of adap->id, that the hdpvr driver would, in the future, identify its device in a manner lirc_zilog was expecting. I don't have a HD PVR with which to test things myself. So putting in all the plumbing lowers the barrier for developers like Jarrod or Janne to test lirc_zilog with an HD PVR when/if they re-enable I2C in hdpvr. Regards, Andy > Acked-by: Jean Delvare -- 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 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 2011-01-05 at 15:45 +0100, Jean Delvare wrote:
> Hi Andy,
>
> On Tue, 28 Dec 2010 20:49:50 -0500, Andy Walls wrote:
> > Remove use of deprecated struct i2c_adapter.id field. In the process,
> > perform different detection of the HD PVR's Z8 IR microcontroller versus
> > the other Hauppauge cards with the Z8 IR microcontroller.
>
> Thanks a lot for doing this. I'll be very happy when we can finally get
> rid of i2c_adapter.id.
You're welcome. If I hadn't done it, I was worried that lirc_zilog
would have been deleted. I want to fix lirc_zilog properly, but haven't
had the time yet.
Keep in mind, that in this patch I had one objective: remove use of
struct i2c_adapter.id .
I turned a blind-eye to other obvious problems, since fixing
lirc_zilog's problems looked like it was going to be like peeling an
onion. Once you peel back one layer of problems, you find another one
underneath. ;)
> > Also added a comment about probe() function behavior that needs to be
> > fixed.
>
> See my suggestion inline below.
>
> > Signed-off-by: Andy Walls
> > ---
> > drivers/staging/lirc/lirc_zilog.c | 47
> >
> > 1 files changed, 31 insertions(+), 16 deletions(-)
> >
> > diff --git a/drivers/staging/lirc/lirc_zilog.c
> > b/drivers/staging/lirc/lirc_zilog.c
> > index 52be6de..ad29bb1 100644
> > --- a/drivers/staging/lirc/lirc_zilog.c
> > +++ b/drivers/staging/lirc/lirc_zilog.c
> > @@ -66,6 +66,7 @@ struct IR {
> > /* Device info */
> > struct mutex ir_lock;
> > int open;
> > + bool is_hdpvr;
> >
> > /* RX device */
> > struct i2c_client c_rx;
> > @@ -206,16 +207,12 @@ static int add_to_buf(struct IR *ir)
> > }
> >
> > /* key pressed ? */
> > -#ifdef I2C_HW_B_HDPVR
> > - if (ir->c_rx.adapter->id == I2C_HW_B_HDPVR) {
> > + if (ir->is_hdpvr) {
> > if (got_data && (keybuf[0] == 0x80))
> > return 0;
> > else if (got_data && (keybuf[0] == 0x00))
> > return -ENODATA;
> > } else if ((ir->b[0] & 0x80) == 0)
> > -#else
> > - if ((ir->b[0] & 0x80) == 0)
> > -#endif
> > return got_data ? 0 : -ENODATA;
> >
> > /* look what we have */
> > @@ -841,15 +838,15 @@ static int send_code(struct IR *ir, unsigned int
> > code, unsigned int key)
> > return ret < 0 ? ret : -EFAULT;
> > }
> >
> > -#ifdef I2C_HW_B_HDPVR
> > /*
> > * The sleep bits aren't necessary on the HD PVR, and in fact, the
> > * last i2c_master_recv always fails with a -5, so for now, we're
> > * going to skip this whole mess and say we're done on the HD PVR
> > */
> > - if (ir->c_rx.adapter->id == I2C_HW_B_HDPVR)
> > - goto done;
> > -#endif
> > + if (ir->is_hdpvr) {
> > + dprintk("sent code %u, key %u\n", code, key);
> > + return 0;
> > + }
>
> I don't get the change. What was wrong with the "goto done"? Now you
> duplicated the dprintk(), and as far as I can see the "done" label is
> left unused.
Mauro removed the "done:" label in a commit just prior to this one.
Otherwise, yes, I would have used a "goto done:".
So much needs cleaning up in lirc_zilog, that I didn't agonize over this
particular item.
> >
> > /*
> > * This bit NAKs until the device is ready, so we retry it
> > @@ -,12 +1108,14 @@ static int ir_remove(struct i2c_client *client);
> > static int ir_probe(struct i2c_client *client, const struct i2c_device_id
> > *id);
> > static int ir_command(struct i2c_client *client, unsigned int cmd, void
> > *arg);
> >
> > +#define ID_FLAG_TX 0x01
> > +#define ID_FLAG_HDPVR 0x02
> > +
> > static const struct i2c_device_id ir_transceiver_id[] = {
> > - /* Generic entry for any IR transceiver */
> > - { "ir_video", 0 },
> > - /* IR device specific entries should be added here */
> > - { "ir_tx_z8f0811_haup", 0 },
> > - { "ir_rx_z8f0811_haup", 0 },
> > + { "ir_tx_z8f0811_haup", ID_FLAG_TX },
> > + { "ir_rx_z8f0811_haup", 0 },
> > + { "ir_tx_z8f0811_hdpvr", ID_FLAG_HDPVR | ID_FLAG_TX },
> > + { &quo
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
On Wed, 2011-01-05 at 20:02 -0200, Mauro Carvalho Chehab wrote:
> Em 05-01-2011 19:51, Jean Delvare escreveu:
> > Hi Mauro,
> >
> > On Wed, 05 Jan 2011 15:34:28 -0200, Mauro Carvalho Chehab wrote:
> >> Hi Jean,
> >>
> >> Thanks for your acks for patches 1 and 2. I've already applied the patches
> >> on my tree and at linux-next. I'll try to add the acks on it before sending
> >> upstream.
> >
> > If you can't, it's fine. I merely wanted to show my support to Andy's
> > work, I don't care if I'm not counted as a reviewer for these small
> > patches.
>
> Ok. So, it is probably better to keep it as-is, to avoid rebasing and having
> to wait for a couple days at linux-next before sending the git pull request.
>
> >
> >> Em 05-01-2011 12:45, Jean Delvare escreveu:
> >>> From a purely technical perspective, changing client->addr in the
> >>> probe() function is totally prohibited.
> >>
> >> Agreed. Btw, there are some other hacks with client->addr abuse on some
> >> other random places at drivers/media, mostly at the device bridge code,
> >> used to test if certain devices are present and/or to open some I2C gates
> >> before doing some init code. People use this approach as it provides a
> >> fast way to do some things. On several cases, the amount of code for
> >> doing such hack is very small, when compared to writing a new I2C driver
> >> just to do some static initialization code. Not sure what would be the
> >> better approach to fix them.
> >
> > Hard to tell without seeing the exact code. Ideally,
> > i2c_new_dummy() would cover these cases: you don't need to write an
> > actual driver for the device, it's perfectly OK to use the freshly
> > instantiated i2c_client from the bridge driver directly. Alternatively,
> > i2c_smbus_xfer() or i2c_transfer() can be used for one-time data
> > exchange with any slave on the bus as long as you know what you're
> > doing (i.e. you know that no i2c_client will ever be instantiated for
> > this slave.)
> >
> > If you have specific cases you don't know how to solve, please point me
> > to them and I'll take a look.
>
> You can take a look at saa7134-cards.c, for example. saa7134_tuner_setup()
> has several examples. It starts with this one:
>
> switch (dev->board) {
> case SAA7134_BOARD_BMK_MPEX_NOTUNER:
> case SAA7134_BOARD_BMK_MPEX_TUNER:
> /* Checks if the device has a tuner at 0x60 addr
> If the device doesn't have a tuner, TUNER_ABSENT
> will be used at tuner_type, avoiding loading tuner
> without needing it
>*/
> dev->i2c_client.addr = 0x60;
> board = (i2c_master_recv(&dev->i2c_client, &buf, 0) < 0)
> ? SAA7134_BOARD_BMK_MPEX_NOTUNER
> : SAA7134_BOARD_BMK_MPEX_TUNER;
>
> In this specific case, it is simply a probe for a device at address 0x60, but
> there are more complex cases there, with eeprom reads and/or some random init
> that happens before actually attaching some driver at the i2c address.
> It is known to work, but it sounds like a hack.
The cx18 driver has a function scope i2c_client for reading the EEPROM,
and there's a good reason for it. We don't want to register the EEPROM
with the I2C system and make it visible to the rest of the system,
including i2c-dev and user-space tools. To avoid EEPROM corruption,
it's better keep communication with EEPROMs to a very limited scope.
Regards,
Andy
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Cropping and scaling with subdev pad-level operations
On Thu, 2011-01-06 at 16:33 +0100, Laurent Pinchart wrote: > Hi everybody, > > I ran into an issue when implementing cropping and scaling on the OMAP3 ISP > resizer sub-device using the pad-level operations. As nobody seems to be > happy > with the V4L2 crop ioctls, I thought I would ask for comments about the > subdev > pad-level API to avoid repeating the same mistakes. > > A little background information first. The OMAP3 ISP resizer has an input and > an output pad. It receives images on its input pad, performs cropping to a > user-configurable rectange and then scales that rectangle up or down to a > user-configurable output size. The resulting image is output on the output > pad. > > The hardware sets various restrictions on the crop rectangle and on the > output > size, or more precisely on the relationship between them. Horizontal and > vertical scaling ratios are independent (at least independent enough for the > purpose of this discussion), so I'll will not comment on one of them in > particular. > > The minimum and maximum scaling ratios are roughly 1/4 and x4. A complex > equation describes the relationship between the ratio, the cropped size and > the output size. It involves integer arithmetics and must be fullfilled > exactly, so not all combination of crop rectangle and output size can be > achieved. > > The driver expects the user to set the input size first. It propagates the > input format to the output pad, resetting the crop rectangle. That behaviour > is common to all the OMAP3 ISP modules, and I don't think much discussion is > needed there. I'll note here that the driver is allowing the application to make *two* assumptions here: output size == input size and output pixel resolution == input pixel resolution If I'm taking a picture of a building, at a distance from the building such that the input image has a resolution of 1 pixel per 5 cm in the plane of the building, then the output image also has a pixel resolution of 1 pixel per 5 cm in the plane of the building. > The user can then configure the crop rectangle and the output size > independently. As not all combinations are possible, configuring one of them > can modify the other one as a side effect. What enforces the modification, the hardware or the driver? IMO, a crop should be a crop with no scaling or interpolation side effects. If I have 1 pixel per 5 cm on the input, I should get 1 pixel per 5 cm on the output. Changing the output size when setting a new crop window is IMO the correct thing to do since: a. it maintains the pixel resolution (e.g. 1 pixel per 5 cm). b. it is a predictable result that people and applications can rely upon c. It fail due to any implicit zoom constraint violation d. The application also knows what the new output size will be, since it just set the crop window to that same size > This is where problems come from. > Let's assume that the input size, the crop rectangle and the output size are > all set to 4000x4000. The user then wants to crop a 500x500 rectangle and > scale it up to 750x750. > > If the user first sets the crop rectangle to 500x500, the 4000x4000 output > size would result in a x8 scaling factor, not supported by the resizer. The > driver must then either modify the requested crop rectangle or the output > size > to fullfill the hardware requirements. My suggestion is to have the driver modify the output size as a side effect. Changing the output size already happens as a side effect when the application sets the input size. > If the user first sets the output size to 750x750 we end up with a similar > problem, and the driver needs to modify one of crop rectangle or output size > as well. > > When the stream is on, the output size can't be modified as it would change > the captured frame size. Hmm. > The crop rectangle and scaling ratios, on the other > hand, can be modified to implement digital zoom. For that reason, the resizer > driver doesn't modify the output size when the crop rectangle is set while a > stream is running, but restricts the crop rectangle size. With the above > example as a starting point, requesting a 500x500 crop rectangle, which would > result in an unsupported x8 zoom, will return a 1000x1000 crop rectangle. But in this situation - fixed input size, fixed output size - you know exactly what scaling levels are supported, 1/4x to 4x, right? It sounds like this can be hidden from userpace with different behavior inside the driver for the crop and scale API calls when streaming. 1. When streaming, a single crop or scale API request from userspace would cause the driver to command all the required underlying crop and scale operations for the resizer. 2. When streaming stops, either a. require the applications to query the state of the crop window and output size, or b. require drivers to revert to the original crop and scale settings that were in place before stream
Re: [RFC/PATCH v7 01/12] media: Media device node support
Why, yes, there is a standard:
http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html
A somewhat verbose description of the errnos is in section 2.3.
-Andy
Hans Verkuil wrote:
>On Thursday, January 06, 2011 23:19:12 Greg KH wrote:
>
>
>
>> > > > +static ssize_t media_read(struct file *filp, char __user *buf,
>> > > > + size_t sz, loff_t *off)
>> > > > +{
>> > > > + struct media_devnode *mdev = media_devnode_data(filp);
>> > > > +
>> > > > + if (!mdev->fops->read)
>> > > > + return -EINVAL;
>> > > > + if (!media_devnode_is_registered(mdev))
>> > > > + return -EIO;
>> > >
>> > > How could this happen?
>> >
>> > This can happen when a USB device is disconnected for instance.
>>
>> But what's to keep that from happening on the next line as well?
>
>Nothing.
>
>> That
>> doesn't seem like a check you can ever be sure about, so I wouldn't do
>> it at all.
>
>Actually, there is a reason why this was done for v4l (and now the media
>API): typically, once a USB disconnect happens V4L drivers will call
>video_unregister_device() which calls device_unregister. Afterwards the
>device node should reject any new file operations except for release().
>
>Obviously, this check can be done in the driver as well, but doing this
>check in the V4L core has the advantage of 1) consistent return codes and
>2) drivers no longer have to check.
>
>Of course, since the disconnect can happen at any time drivers still need
>to be able to handle errors from the USB subsystem due to disconnects, but
>that is something they always have to do.
>
>>
>> > > And are you sure -EIO is correct?
>> >
>> > -ENXIO is probably better (I always confuse that with -ENODEV).
>
>I wondered why V4L uses -EIO and I think it is related to the V4L2
>specification
>of the read() function:
>
>EIO
>I/O error. This indicates some hardware problem or a failure to communicate
>with
>a remote device (USB camera etc.).
>
>Well, I guess a disconnect can be seen as a failure to communicate :-)
>
>I think that ENODEV is much better. After all, there is no device
>anymore after a disconnect.
>
>Is there some standard for this?
>
>Regards,
>
> Hans
>
>--
>Hans Verkuil - video4linux developer - sponsored by Cisco
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH v7 01/12] media: Media device node support
Yeah well, lame-o default email client on my Android phone. -Andy Greg KH wrote: > > >A: No. >Q: Should I include quotations after my reply? > >http://daringfireball.net/2007/07/on_top > >On Thu, Jan 06, 2011 at 07:24:27PM -0500, Andy Walls wrote: >> Why, yes, there is a standard: >> >> http://pubs.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_03.html >> >> A somewhat verbose description of the errnos is in section 2.3. > >Ah, so perhaps -ENXIO is the correct thing to return with here. > >thanks, > >greg k-h >-- >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: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Sat, 2011-01-08 at 13:09 +0100, Lawrence Rust wrote: > On Mon, 2011-01-03 at 17:34 -0500, Andy Walls wrote: > > On Sun, 2011-01-02 at 23:00 -0500, Eric Sharkey wrote: > > > On Fri, Dec 31, 2010 at 7:55 PM, Andy Walls > > > wrote: > > > > Mauro, > > > > > > > > Please revert at least the wm8775.c portion of commit > > > > fcb9757333df37cf4a7feccef7ef6f5300643864: > > > > > > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=fcb9757333df37cf4a7feccef7ef6f5300643864 > > > > > > > > It completely trashes baseband line-in audio for PVR-150 cards, and > > > > likely does the same for any other ivtv card that has a WM8775 chip. > > > > > > Confirmed. I manually rolled back most of the changes in that commit > > > for wm8775.c, leaving all other files alone, and the audio is now > > > working correctly for me. I haven't yet narrowed it down to exactly > > > which changes in that file cause the problem. I'll try and do that > > > tomorrow if I have time. > > Oh dear, you leave the ranch for 5 minutes to a place without email and > all hell breaks loose. Didn't anyone think that New Year is a time for > holidays? > > So, for a minor niggle, which is trivially sorted, you pull almost the > whole patch leaving the only bit that causes problems for the Nova-S > (for which the patch was intended). Sorry Lawrence. I didn't have time to review and test the original patch properly when you submitted it. By the time the regression was discovered there was not time for me to fix. (I did have to do work for customers between Christmas and New Year's :( ). Getting fixes back into stable trees is a royal PITA and has a time lag waiting for the fix to get upstream first. It's better not to let regression slip forward into a kernel release. If the PVR-150 was some low volume distribution card that no one used or had only been in the kernel for only a few releases, I wouldn't have pushed so hard for the revert. However the PVR-150 is a very popular card and many units are in service with linux users. It is the 1st choice for analog recording for many users with a MythTV setup. With the transition to DTV in the US, the PVR-150's banseband input is the most useful part of the card in the US. > The remnant, > drivers/media/video/cx88/cx88-cards.c line 970, adds wm8775 baseband > audio-in which is horribly distorted without the patch. So I suggest it > too is removed. > > Now, if someone can direct me to a full hardware description for the > PVR-150 http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/ivtv/ivtv-cards.c;h=87afbbee20636f1e9f1192f8592a35954382bd7f;hb=master#l190 http://www.hauppauge.com/site/support/support_pvr150.html > and datasheets for the components connected to the wm8775 then > I'll endeavour to provide a solution compatible with both. WM8775: http://dl.ivtvdriver.org/datasheets/audio/WM8775.pdf CX2584[0123]: http://dl.ivtvdriver.org/datasheets/video/cx25840.pdf CX23416 (old, but the first hit with a Google search): http://www.google.com/url?sa=t&source=web&cd=1&sqi=2&ved=0CBQQFjAA&url=http%3A%2F%2Fwww.icbank.com%2Ficbank_data%2Fonline_seminar%2Fconexant_060517%2FDatasheet.pdf&rct=j&q=CX23416%20datasheet&ei=GHAoTf31MYWglAeh_bG4AQ&usg=AFQjCNHESSp00ahlEGzxm6I-RXZ7WBMA0w&cad=rja One of many different analog tuners that can bue used with a PVR-150: http://dl.ivtvdriver.org/datasheets/tuners/TAPE-H091F_MK3.pdf Good photographs of the PVR-150MCE board: http://www.ixbt.com/monitor/images/hauppauge-pvr150/hauppauge-pvr-150-front.jpg http://www.ixbt.com/monitor/images/hauppauge-pvr150/hauppauge-pvr-150-back.jpg Approximate layout of the sound path: +-++---+ | SIF|--->|AFE In8|+-+ | Analog||CX25843|| CX23416 | | Tuner | +---+| || | |TV AF|-->|AIN1I2S|--->|I2S In I2S Out|--->|I2S In | | FM L,R|-->|AIN4 |+---+| | +-+ | WM8775 | | PCI|<---> | | +-+ Line In 1 L,R --->|AIN2 | Line In 2 L,R --->|AIN3 | +---+ Note that 1. the PVR-500 is essentially two PVR-150's on on card and also uses the WM8775/CX2584x combination but with smaller, probably poorer performing, ananlog tuners. . 2. other cards use the CX2584x with something other than a WM8775 (e.g. a WM8739 with a 74HC4052 a
Re: zilog and IR
On Sat, 2011-01-08 at 10:44 -0500, Jason Gauthier wrote: > Andy, > >Firstly, I apologize for reaching out to you directly. The list could have answered this, so I adding the Cc:. BTW, I normally ignore direct emails asking for free support, as the N-to-1 free support problem is too costly for me personally. The N-to-M free support problem on the list is a little easier to bear, and is consistent with Linux's community development model. > I stumbled into your git tree, which looks like it does exactly what > I want. But it doesn't. It's a bleeding edge tree of mine used to develop a changeset. Be warned that such trees come with no guarantees that at any one moment in time it will compile and not damage your hardware. I only subjected the changes to personal review, compilation check, and inspection by others on the list. That was sufficient for me for software defect removal, since the change was a cut-and-paste from the cx18 and ivtv modules and the code is not yet called by hdpvr anyway. > I grabbed the source but, unfortunately, it is not compiling for me > because one of the constants is not defined. > > in hdprv_new_i2c_ir, the line: > init_data->type = RC_TYPE_RC5; > I have not been able to find any traces of RC_TYPE_RC5 in my 2.6.37 > kernel source. > Is this a #define that you've made specific to your git tree? No: http://git.linuxtv.org/media_tree.git?a=commit;h=e58462f45e39e01799d8b1ebab4816bd0ca68ddc That media_tree.git repository is the bleeding edge tree recommended for developers and advanced users wanting the latest drivers. The alternate is the media_build.git repository when has ability to build the modules with some not so old kernels. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 11/32] v4l/cx18: update workqueue usage
On Mon, 2011-01-03 at 14:49 +0100, Tejun Heo wrote:
> With cmwq, there's no reason to use separate out_work_queue. Drop it
> and use system_wq instead. The in_work_queue needs to be ordered so
> can't use one of the system wqs; however, as it isn't used to reclaim
> memory, allocate the workqueue with alloc_ordered_workqueue() without
> WQ_MEM_RECLAIM.
>
> Signed-off-by: Tejun Heo
> Cc: Andy Walls
> Cc: linux-media@vger.kernel.org
> ---
> Only compile tested. Please feel free to take it into the subsystem
> tree or simply ack - I'll route it through the wq tree.
Reviewed-by: Andy Walls
Acked-by: Andy Walls
Sorry it took so long for me to review.
Please route via your wq tree for the cx18 driver.
Thanks,
Andy
> Thanks.
>
> drivers/media/video/cx18/cx18-driver.c | 24 ++--
> drivers/media/video/cx18/cx18-driver.h |3 ---
> drivers/media/video/cx18/cx18-streams.h |3 +--
> 3 files changed, 3 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/media/video/cx18/cx18-driver.c
> b/drivers/media/video/cx18/cx18-driver.c
> index df60f27..41c0822 100644
> --- a/drivers/media/video/cx18/cx18-driver.c
> +++ b/drivers/media/video/cx18/cx18-driver.c
> @@ -656,7 +656,7 @@ static int __devinit cx18_create_in_workq(struct cx18 *cx)
> {
> snprintf(cx->in_workq_name, sizeof(cx->in_workq_name), "%s-in",
>cx->v4l2_dev.name);
> - cx->in_work_queue = create_singlethread_workqueue(cx->in_workq_name);
> + cx->in_work_queue = alloc_ordered_workqueue(cx->in_workq_name, 0);
> if (cx->in_work_queue == NULL) {
> CX18_ERR("Unable to create incoming mailbox handler thread\n");
> return -ENOMEM;
> @@ -664,18 +664,6 @@ static int __devinit cx18_create_in_workq(struct cx18
> *cx)
> return 0;
> }
>
> -static int __devinit cx18_create_out_workq(struct cx18 *cx)
> -{
> - snprintf(cx->out_workq_name, sizeof(cx->out_workq_name), "%s-out",
> - cx->v4l2_dev.name);
> - cx->out_work_queue = create_workqueue(cx->out_workq_name);
> - if (cx->out_work_queue == NULL) {
> - CX18_ERR("Unable to create outgoing mailbox handler threads\n");
> - return -ENOMEM;
> - }
> - return 0;
> -}
> -
> static void __devinit cx18_init_in_work_orders(struct cx18 *cx)
> {
> int i;
> @@ -702,15 +690,9 @@ static int __devinit cx18_init_struct1(struct cx18 *cx)
> mutex_init(&cx->epu2apu_mb_lock);
> mutex_init(&cx->epu2cpu_mb_lock);
>
> - ret = cx18_create_out_workq(cx);
> - if (ret)
> - return ret;
> -
> ret = cx18_create_in_workq(cx);
> - if (ret) {
> - destroy_workqueue(cx->out_work_queue);
> + if (ret)
> return ret;
> - }
>
> cx18_init_in_work_orders(cx);
>
> @@ -1094,7 +1076,6 @@ free_mem:
> release_mem_region(cx->base_addr, CX18_MEM_SIZE);
> free_workqueues:
> destroy_workqueue(cx->in_work_queue);
> - destroy_workqueue(cx->out_work_queue);
> err:
> if (retval == 0)
> retval = -ENODEV;
> @@ -1244,7 +1225,6 @@ static void cx18_remove(struct pci_dev *pci_dev)
> cx18_halt_firmware(cx);
>
> destroy_workqueue(cx->in_work_queue);
> - destroy_workqueue(cx->out_work_queue);
>
> cx18_streams_cleanup(cx, 1);
>
> diff --git a/drivers/media/video/cx18/cx18-driver.h
> b/drivers/media/video/cx18/cx18-driver.h
> index 77be58c..f7f71d1 100644
> --- a/drivers/media/video/cx18/cx18-driver.h
> +++ b/drivers/media/video/cx18/cx18-driver.h
> @@ -614,9 +614,6 @@ struct cx18 {
> struct cx18_in_work_order in_work_order[CX18_MAX_IN_WORK_ORDERS];
> char epu_debug_str[256]; /* CX18_EPU_DEBUG is rare: use shared space */
>
> - struct workqueue_struct *out_work_queue;
> - char out_workq_name[12]; /* "cx18-NN-out" */
> -
> /* i2c */
> struct i2c_adapter i2c_adap[2];
> struct i2c_algo_bit_data i2c_algo[2];
> diff --git a/drivers/media/video/cx18/cx18-streams.h
> b/drivers/media/video/cx18/cx18-streams.h
> index 77412be..5837ffb 100644
> --- a/drivers/media/video/cx18/cx18-streams.h
> +++ b/drivers/media/video/cx18/cx18-streams.h
> @@ -41,8 +41,7 @@ static inline bool cx18_stream_enabled(struct cx18_stream
> *s)
> /* Related to submission of mdls to firmware */
> static inline void cx18_stream_load_fw_queue(struct cx18_stream *s)
> {
> - struct cx18 *cx = s->cx;
> - queue_work(cx->out_work_queue, &s->out_work_order);
> + schedule_work(&s->out_work_order);
> }
>
> static inline void cx18_stream_put_mdl_fw(struct cx18_stream *s,
--
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: user accesses in ivtv-fileops.c:ivtv_v4l2_write ?
On Sun, 2011-01-09 at 00:34 +, Dr. David Alan Gilbert wrote:
> Hi Andy,
> It looks like we missed something in that copy from user
> patch from the end of last year:
>
> +void ivtv_write_vbi_from_user(struct ivtv *itv,
> + const struct v4l2_sliced_vbi_data __user
> *sliced,
> + size_t cnt)
> +{
> + struct vbi_cc cc = { .odd = { 0x80, 0x80 }, .even = { 0x80, 0x80 } };
> + int found_cc = 0;
> + size_t i;
> + struct v4l2_sliced_vbi_data d;
> +
> + for (i = 0; i < cnt; i++) {
> + if (copy_from_user(&d, sliced + i,
> + sizeof(struct v4l2_sliced_vbi_data)))
> + break;
> + ivtv_write_vbi_line(itv, sliced + i, &cc, &found_cc);
^^
What was I thinking? -+
Decent plan; failed execution. :(
>
> sparse is giving me:
> drivers/media/video/ivtv/ivtv-vbi.c:177:49: warning: incorrect type in
> argument 2 (different address spaces)
> drivers/media/video/ivtv/ivtv-vbi.c:177:49:expected struct
> v4l2_sliced_vbi_data const *d
> drivers/media/video/ivtv/ivtv-vbi.c:177:49:got struct
> v4l2_sliced_vbi_data const [noderef] *
>
> and I think the point is that while you've copied the data I think
> you're still passing the user pointer to ivtv_write_vbi_line and it
> should be:
>
>ivtv_write_vbi_line(itv, &d, &cc, &found_cc);
>
>
> What do you think?
Yes, it looks like I gooned that one up. :)
That's what I get for trying to fix things with the kids running around
before bedtime.
I assume that you have made the replacement and tested that sparse is
satisfied?
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Enable IR on hdpvr
On Mon, 2011-01-10 at 01:05 -0500, Jarod Wilson wrote: > On Jan 9, 2011, at 7:36 PM, Jason Gauthier wrote: > Janne, I've heard many success stories w/the hdpvr IR lately, and almost no > reports > of lockups, so I'm thinking a firmware update may have helped out here, and > thus, > maybe its time we just go ahead and push this patch along upstream? We still > require someone to load lirc_zilog manually, so it seems like a fairly > low-risk > thing to do. FYI, the code I added to hdpvr-i2c.c will perform 2 accesses to the chip to check for existence, by virtue of a call to i2c_new_probed_device() (or whatever it is called). The I2C subsystem tries to talk the chip to see if it exists. If you are really concerned about corner cases that may hang, add a module option to hdpvr to disable I2C and/or IR in the hdpvr driver. With that users in the field can work-around the problem without rebuilding modules. 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
Maybe I'll hack on lirc_zilog.c this coming weekend (Re: Enable IR on hdpvr)
On Mon, 2011-01-10 at 01:05 -0500, Jarod Wilson wrote: > On Jan 9, 2011, at 7:36 PM, Jason Gauthier wrote: > There's a bit more to it than just the one line change. Here's the patch we're > carrying in the Fedora kernels to enable it: > > http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable.patch > BTW, I plan to work on lirc_zilog.c this coming weekend, with my PVR-150 and HVR-1600 as test units. If there are any lirc_zilog.c patches you have developed that are not in the media_tree.git repo, could you point me to them before then? Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Sat, 2011-01-08 at 19:45 +0100, Lawrence Rust wrote: > On Sat, 2011-01-08 at 09:22 -0500, Andy Walls wrote: > Thanks for the info on the PVR-150. It largely confirmed what I had > surmised - that the two cards disagree about serial audio data format. > Before my patch, the wm8775 was programmed for Philips mode but the > CX25843 on the PVR-150 is setup for Sony I2S mode!! On the Nova-S, the > cx23883 is setup (in cx88-tvaudio.c) for Philips mode. The patch > changed the wm8775 to Sony I2S mode because the existing setup gave > noise, indicative of a mismatch. > > It is my belief that either the wm8775 datasheet is wrong or there are > inverters on the SCLK lines between the wm8775 and cx25843/23883. It is > also plausible that Conexant have it wrong and both their datasheets are > wrong. > > Anyway, I have revised the patch (attached) so that the wm8775 is kept > in Philips mode (to please the PVR-150) and the cx23883 on the Nove-S is > now switched to Sony I2S mode (like the PVR-150) and this works fine. I will try and review and test this coming weekend. > The change is trivial, just 2 lines, so they're shouldn't be any other > consequences. However, could this affect any other cards? That is the problem with code reuse, for multiple board models, in all the I2C modules. It makes code increasingly more difficult to maintain as more different board models are supported and tested. But now there is infrastructure in place to pass board specific info down to the I2C v4l2_subdevice drivers. If the wm8775 driver were changed to provide a wm8775-specific platform-data structure for bridge drivers to use, bridge drivers could fill it out and call v4l2_i2c_new_subdev_board() to instantiate the wm8775 device instance specific to the board: Nova-S, PVR-150, or whatever. See the interaction between the ivtv and cx25840 module in this patch as an example: https://patchwork.kernel.org/patch/465571/ (Not all of the details are visible in the patch, since some were already there for the .s_config call in cx25840.) Obviously, the wm8775 module would need code added to take different actions when passed different platform data. However, that the best way to make sure one doesn't accidentally affect other boards. > NB I have only tested this patch on my Nova-S, no other. I do see one problem with your patch at the moment: diff --git a/include/media/wm8775.c b/include/media/wm8775.c ... + sd->grp_id = WM8775_GID; /* subdev group id */ ... diff --git a/include/media/wm8775.h b/include/media/wm8775.h ... +/* subdev group ID */ +#define WM8775_GID (1 << 0) + ... The wm8775 module probably should not define WM8775_GID and definitely should not set sd->grp_id. The sd->grp_id is for the bridge driver's use for that v4l2_subdev instance. Some bridge drivers may expect it to be 0 unless they set it themselves. The group ID values should be defined in the bridge driver, and the sd->grp_id field should be set by the bridge driver. You would want to do that in cx88. See cx23885, ivtv, and cx18 as examples of bridge drivers that use the group id field. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Mon, 2011-01-10 at 13:56 +0100, Lawrence Rust wrote: > On Mon, 2011-01-10 at 07:39 -0500, Andy Walls wrote: > You know what, life's too short. I've spent far too long on this at the > expense of far more interesting projects. Every time I put some effort > in someone says just one more thing... I get the message. With all due respect, I don't think that you do. The message is *not* "Lawrence we don't won't your patches here , because we're an exclusive club" nor "Lawrence, we don't find your time and talent valuable" All of my comments stem from *one* high level requirement: Don't break the code for existing boards - especially popular ones for which I have some level of maintenance responsibility. How you satisfy that requirement is up to you. Just as you don't have a lot of time to do all the analysis and testing to ensure that requirement is met; I don't have time to clean up every patch that doesn't meet that requirement. The time and effort you don't expend gets pushed off to me or someone else. I have tried to provide you with constructive criticism and guidance. I will not do your work for you. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.38] Implement core priority handling
On Tue, 2011-01-11 at 09:21 +0100, Hans Verkuil wrote: > This implements core support for priority handling. This is basically the same > as my RFCv3 patch series, except without some of the driver changes (I want to > do that for 2.6.39) and with the single fix to patch 05/16 I posted to the > list. > > Currently the only drivers this affects are ivtv (which is the only user of > v4l2_fh at the moment) and vivi. > > I will probably also adapt cx18 this weekend since as it stands now it is > possible > for a lower prio process to change controls for a higher prio process. To fix > this requires core prio handling anyway, so let's get this in for 2.6.38 so > people can start using it. Have fun. I have no pending cx18 patches that would possibly conflict. off topic: I'm still working on a software UART driver pet project. Satisfying the Linux tty subsystem's internal interface requirements, and understanding tty subsystem internal behaviors and locking, is shaping up to be more work than writing the soft-uart itself. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Enable IR on hdpvr
On Wed, 2011-01-12 at 13:49 +, Jason Gauthier wrote: > >> > >> Bah. Yeah, sorry, that wasn't the current patch in Fedora 14. This is: > >> > >> http://wilsonet.com/jarod/lirc_misc/hdpvr-ir/hdpvr-ir-enable-2.patch > >> > >> Its atop the F14 2.6.35.10 kernel, which has a fairly recent v4l/dvb > >> backport on top of it, so it should be pretty close to matching the > >> current v4l/dvb code... > > >With the help of Andy Walls and Jean Delvare, I think we've hashed > out an updated patch that will work sitting atop the current v4l/dvb > hdpvr code, but I'm only just now getting around to compile->testing > it, and its past my bedtime, so it'll be tomorrow before I can do any > sort of functional testing (but hey, due to the snow, I'll be working > from home tomorrow, where my hdpvr happens to be...). > > I've got two hdpvrs. Whenever you're ready to extend your testing, > I'm happy to extend that functional testing. I didn't get a chance to > look at the FC14 patch yet (busy couple of days), but I will hold off > now, anyway! If all goes well, with Jarrod's change, you should be able to test the hdpvr module with the ir-kbd-i2c module and test IR Rx. Strictly speaking, lirc_zilog needs some rework to use the kernel internal interfaces properly. It might still work, but don't be surprised if it doesn't. I might get to working on lirc_zilog tonight, but otherwise not until this weekend. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Enable IR on hdpvr
On Wed, 2011-01-12 at 18:45 -0500, Andy Walls wrote: > If all goes well, with Jarrod's change, you should be able to test the > hdpvr module with the ir-kbd-i2c module and test IR Rx. FYI, I have (re)confirmed that ir-kbd-i2c and cx18, in a bleeding-edge development kernel, still work with the Zilog Z8 IR Rx on the HVR-1600. It's nice to have a known working baseline. > Strictly speaking, lirc_zilog needs some rework to use the kernel > internal interfaces properly. It might still work, but don't be > surprised if it doesn't. > > I might get to working on lirc_zilog tonight, but otherwise not until > this weekend. lirc_zilog got a little work tonight: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 My changes make it slightly *more* broken in some respects. :D At least what needs to be reworked is now becoming easier to see and address. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Enable IR on hdpvr
On Thu, 2011-01-13 at 02:16 +, Jason Gauthier wrote: > >> I've got two hdpvrs. Whenever you're ready to extend your testing, > >> I'm happy to extend that functional testing. I didn't get a chance to > >> look at the FC14 patch yet (busy couple of days), but I will hold off > >> now, anyway! > > >If all goes well, with Jarrod's change, you should be able to test the > >hdpvr module with the ir-kbd-i2c module and test IR Rx. > > >Strictly speaking, lirc_zilog needs some rework to use the kernel > >internal interfaces properly. It might still work, but don't be > >surprised if it doesn't. > > >I might get to working on lirc_zilog tonight, but otherwise not until > >this weekend. > > Sounds good. Will give any feedback I can! Is Tx completely a no show > at this point? No, it might work. It's hard to tell, but you best course of action is to load the hdpvr driver and then load the lirc_zilog module and *do not* unload it. The major lirc_zilog problem is *double* registration of the Tx and Rx interfaces due to an old design in lirc_zilog.c:ir_probe(). Other subtle problems I noticed were pointer use after kfree() and not deallocating everything properly on module unload. How will those affect you? I don't know... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Devin,
You've seen the clock stretch with your I2C analyzer?
Jean,
How should clock stretches by slaves be handled using i2c-algo-bit?
Regards,
Andy
Devin Heitmueller wrote:
>On Thu, Jan 13, 2011 at 8:21 AM, Jean Delvare wrote:
>> My bet is that register at 0x00 is a control register, and writing bit
>> 7 (value 0x80) makes the chip busy enough that it can't process I2C
>> requests at the same time. The following naks would be until the
>> chip is operational again.
>
>Correct. Poking bit 7 of 0xE0:00 triggers the "send" for all the
>bytes that were previously loaded into the device. It puts the chip
>into a busy state, doing an i2c clock stretch until it is available
>again. During that time it cannot see any i2c traffic, which is why
>you are getting NAKs.
>
>Devin
>
>--
>Devin J. Heitmueller - Kernel Labs
>http://www.kernellabs.com
>--
>To unsubscribe from this list: send the line "unsubscribe linux-media" in
>the body of a message to majord...@vger.kernel.org
>More majordomo info at http://vger.kernel.org/majordomo-info.html
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH 3/3] lirc_zilog: Remove use of deprecated struct i2c_adapter.id field
Jean, Yes, however, I asked because ivtv and cx18 use i2c-algo-bit and also provide Zilog z8 IR I2C clients for lirc_zilog to use. So if those get clock stretch handling "for free", that's great. Regards, Andy Jean Delvare wrote: >On Thu, 13 Jan 2011 11:34:42 -0500, Andy Walls wrote: >> How should clock stretches by slaves be handled using i2c-algo-bit? > >It is already handled. But hdpvr-i2c doesn't use i2c-algo-bit. I2C >support is done with USB commands instead. Maybe the hardware >implementation doesn't support clock stretching by slaves. Apparently >it doesn't support repeated start conditions either, so it wouldn't >surprise me. > >-- >Jean Delvare >-- >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] hdpvr: enable IR part
On Fri, 2011-01-14 at 14:54 -0500, Jarod Wilson wrote:
> A number of things going on here, but the end result is that the IR part
> on the hdpvr gets enabled, and can be used with ir-kbd-i2c and/or
> lirc_zilog.
>
> First up, there are some conditional build fixes that come into play
> whether i2c is built-in or modular. Second, we're swapping out
> i2c_new_probed_device() for i2c_new_device(), as in my testing, probing
> always fails, but we *know* that all hdpvr devices have a z8 chip at
> 0x70 and 0x71. Third, we're poking at an i2c address directly without a
> client, and writing some magic bits to actually turn on this IR part
> (this could use some improvement in the future). Fourth, some of the
> i2c_adapter storage has been reworked, as the existing implementation
> used to lead to an oops following i2c changes c. 2.6.31.
>
> Earlier editions of this patch have been floating around the 'net for a
> while, including being patched into Fedora kernels, and they *do* work.
> This specific version isn't yet tested, beyond loading ir-kbd-i2c and
> confirming that it does bind to the RX address of the hdpvr:
>
> Registered IR keymap rc-hauppauge-new
> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6
> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1
> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR I2C]
>
> (Yes, I'm posting before fully testing, and I do have a reason for that,
> and will post a v2 after testing this weekend, if need be)...
As discussed on IRC
1. no need to probe for the Z8 as HD PVR always has one.
2. accessing the chip at address 0x54 directly should eventually be
reworked with nicer i2c subsystem methods, but that can wait
So
Acked-by: Andy Walls
Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function
get_key_haup_xvr() *may* need some additions to account for the Rx data
format. I'm not sure of this though. (Or a custom get_key() in the
hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via
platform_data.)
I will provide a debug patch in another email so that it's easier to see
the data ir-kbd-i2c.c sees coming from the Z8.
Regards,
Andy
> Signed-off-by: Jarod Wilson
> ---
> drivers/media/video/hdpvr/Makefile |4 +-
> drivers/media/video/hdpvr/hdpvr-core.c | 10 +--
> drivers/media/video/hdpvr/hdpvr-i2c.c | 120
> +++
> drivers/media/video/hdpvr/hdpvr-video.c |7 +--
> drivers/media/video/hdpvr/hdpvr.h |2 +-
> 5 files changed, 66 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/media/video/hdpvr/Makefile
> b/drivers/media/video/hdpvr/Makefile
> index e0230fc..3baa9f6 100644
> --- a/drivers/media/video/hdpvr/Makefile
> +++ b/drivers/media/video/hdpvr/Makefile
> @@ -1,6 +1,4 @@
> -hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o
> -
> -hdpvr-$(CONFIG_I2C) += hdpvr-i2c.o
> +hdpvr-objs := hdpvr-control.o hdpvr-core.o hdpvr-video.o hdpvr-i2c.o
>
> obj-$(CONFIG_VIDEO_HDPVR) += hdpvr.o
>
> diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
> b/drivers/media/video/hdpvr/hdpvr-core.c
> index f7d1ee5..a6572e5 100644
> --- a/drivers/media/video/hdpvr/hdpvr-core.c
> +++ b/drivers/media/video/hdpvr/hdpvr-core.c
> @@ -378,19 +378,17 @@ static int hdpvr_probe(struct usb_interface *interface,
> goto error;
> }
>
> -#ifdef CONFIG_I2C
> - /* until i2c is working properly */
> - retval = 0; /* hdpvr_register_i2c_adapter(dev); */
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> + retval = hdpvr_register_i2c_adapter(dev);
> if (retval < 0) {
> v4l2_err(&dev->v4l2_dev, "registering i2c adapter failed\n");
> goto error;
> }
>
> - /* until i2c is working properly */
> - retval = 0; /* hdpvr_register_i2c_ir(dev); */
> + retval = hdpvr_register_i2c_ir(dev);
> if (retval < 0)
> v4l2_err(&dev->v4l2_dev, "registering i2c IR devices failed\n");
> -#endif /* CONFIG_I2C */
> +#endif
>
> /* let the user know what node this device is now attached to */
> v4l2_info(&dev->v4l2_dev, "device now attached to %s\n",
> diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> b/drivers/media/video/hdpvr/hdpvr-i2c.c
> index 24966aa..c0696c3 100644
> --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> @@ -13,6 +13,8 @@
> *
> */
>
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> +
> #include
> #include
>
> @@ -28,55 +30,31 @@
> #define Z8F0811_IR_TX_I2C_ADDR 0x70
> #define Z8F08
[PATCH] ir-kbd-i2c: Add debug to examine received data in get_key_haup_common()
Add a hex dump of the received bytes for tester reporting of actual data received from the hardware. Signed-off-by: Andy Walls --- My heart won't be broken if this never makes it into the kernel. Regards, Andy diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c index c87b6bc..b27fc43 100644 --- a/drivers/media/video/ir-kbd-i2c.c +++ b/drivers/media/video/ir-kbd-i2c.c @@ -76,6 +76,11 @@ static int get_key_haup_common(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw, if (size != i2c_master_recv(ir->c, buf, size)) return -EIO; + if (debug >= 2) + print_hex_dump_bytes(MODULE_NAME +": get_key_haup_common: received bytes: ", +DUMP_PREFIX_NONE, buf, size); + /* split rc5 data block ... */ start = (buf[offset] >> 7) &1; range = (buf[offset] >> 6) &1; -- 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
VIDIOC_INT_RESET still needed in ivtv for the moment
Hans, A few weeks ago you asked if VIDIOC_INT_RESET is still needed in ivtv. I can now say for certain, that yes, it is still needed. See this from 2008: http://www.mail-archive.com/ivtv-users@ivtvdriver.org/msg08613.html It will not be needed after I get two things done: 1. patch ivtv to issue a GPIO reset of the IR chip at module load. 2. add a way for the cx18, ivtv, and hdpvr bridge drivers to provide a reset callback to lirc_zilog. (I know ivtv and cx18 can provide one.) After that, cx18 and ivtv will not need the VIDIOC_INT_RESET ioctl(). Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Fri, 2011-01-14 at 21:30 -0500, Jarod Wilson wrote: > On Jan 14, 2011, at 5:08 PM, Jarod Wilson wrote: > >>> Registered IR keymap rc-hauppauge-new > >>> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 > >>> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 > >>> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD PVR > >>> I2C] > > And it *almost* works. Every key on the bundled remote is recognized, but > every press gets feedback about like this w/evtest: > > Event: time 1295058330.966180, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058330.966212, type 1 (Key), code 401 (Blue), value 1 > Event: time 1295058330.966220, -- Report Sync > Event: time 1295058331.066175, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.166290, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.275664, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.376160, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.465505, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.476161, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.498502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.531504, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.564503, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.576153, type 4 (Misc), code 4 (ScanCode), value 29 > Event: time 1295058331.597502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.630501, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.663502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.696500, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.729503, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.762502, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.795500, type 1 (Key), code 401 (Blue), value 2 > Event: time 1295058331.825507, type 1 (Key), code 401 (Blue), value 0 > Event: time 1295058331.825526, -- Report Sync > > That's just a single short press. With arrow keys, its quite funky to > watch in, say, mythtv UI menus. Hit up, and it moves up one, stalls for a > second, then moves up several more. Hmm bizzarre. > ... > >> Note, that code in lirc_zilog.c indicates that ir-kbd-i2c.c's function > >> get_key_haup_xvr() *may* need some additions to account for the Rx data > >> format. I'm not sure of this though. (Or a custom get_key() in the > >> hdpvr module could be provided as a function pointer to ir-kbd-i2c.c via > >> platform_data.) > >> > >> I will provide a debug patch in another email so that it's easier to see > >> the data ir-kbd-i2c.c sees coming from the Z8. > > > > I'll tack that onto the machine I've got hooked to the hdpvr and see what > > I can see this weekend, thanks much for the pointers. > > I'm inclined to think that it does indeed need some of the changes from > lirc_zilog brought over (or the custom get_key()). Now on to adding that > patch and some testing with lirc_zilog... Yes, maybe both the Rx data parsing *and* the precise delay between Rx polls. BTW, a checkpatch and compiler tested lirc_zilog.c is here: http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 It should fix all the binding and allocation problems related to ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll kthread. That's possibly another bug to add to the list. Anyway, $DIETY knows if the lirc_zilog module actually still works after all my hacks. Give it a test if you are adventurous. I won't be able to test until tomorrow evening. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
With my newly hacked lirc_zilog, try using the 'tx_only' parameter please. It's not quite ready yet, but I'd like to know if it can bind. If you already loaded a lirc_zilog without my latest patches, the i2c subsystem might have bogus crud still registered. A reboot might be needed for a valid test. R, Andy Jarod Wilson wrote: >On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote: >... >>> BTW, a checkpatch and compiler tested lirc_zilog.c is here: >>> >>> http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 >>> >>> It should fix all the binding and allocation problems related to >>> ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll >>> kthread. That's possibly another bug to add to the list. >>> >>> Anyway, $DIETY knows if the lirc_zilog module actually still works after >>> all my hacks. Give it a test if you are adventurous. I won't be able >>> to test until tomorrow evening. >> >> I'll try to grab those and give them a test tomorrow, and hey, I've even got >> a baseline to test against now. > >Forgot to mention: I think it was suggested that one could use ir-kbd-i2c >for receive and lirc_zilog for transmit, at the same time. With ir-kbd-i2c >already loaded, lirc_zilog currently won't bind to anything. > >-- >Jarod Wilson >ja...@wilsonet.com > > > >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Sat, 2011-01-15 at 00:37 -0500, Jarod Wilson wrote: > On Jan 14, 2011, at 11:35 PM, Andy Walls wrote: > > > A single button press w/ir-kbd-i2c debugging and your patch: > > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > ir-kbd-i2c: ir_poll_key > ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 54 00 > T. > ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=21 > FWIW, here's what an HVR-1600 and ir-kbd-i2c dumped out for me: ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 24 00 $. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=9 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 24 00 $. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=9 ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. [...] ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 de 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t0 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 80 00 00 fe 08 00 .. ir-kbd-i2c: ir hauppauge (rc5): s1 r1 t1 dev=30 code=2 ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. ir-kbd-i2c: get_key_haup_common: received bytes: 00 00 00 00 00 00 .. I did a momentary press of button '9' and got a single '9'. I did a press and hold of button '2' during which I accidentally pointed the remote away from the sensor and then back. IIRC I got one '2' and then many '2''s after an initial lag. (What I might expect from holding down a keybard key.) I did a following momentary press of button '2'. I can't recall if I got one or many '2''s for that. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Sat, 2011-01-15 at 07:50 -0500, Andy Walls wrote: > Jarod Wilson wrote: > >Forgot to mention: I think it was suggested that one could use ir-kbd-i2c > >for receive and lirc_zilog for transmit, at the same time. With ir-kbd-i2c > >already loaded, lirc_zilog currently won't bind to anything. > With my newly hacked lirc_zilog, try using the 'tx_only' parameter > please. It's not quite ready yet, but I'd like to know if it can > bind. I have now tested this. Using the 'tx_only' module parameter to lirc_zilog appears to allow ir-kbd-i2c and lirc_zilog to coexist, for I2C subsystem binding at least. It does not appear to matter what order the two modules are loaded. I tried it both ways. However, lirc_zilog sharing of Z8 is not fully functional yet. I need to change things to have the bridge drivers provide a IR transceiver mutex to both lirc_zilog and ir-kbd-i2c. lirc_zilog and ir-kbd-i2c would use that mutex for exclusive access to the Z8 when needed, if it was provided by the bridge driver. I view proper sharing of the Z8 as an important requirement, because of two use cases: 1. User only wants to use the Z8 for IR Rx. User doesn't want to fetch the lirc_zilog required firmware or perform any LIRC setup. 2. User only wants to use the Z8 for IR Tx. User uses some other ir-kbd-i2c supported receiver and remote IR Rx. Maybe use case #2 is too rare to worry about? However, if one accepts both use cases as valid, then ir-kbd-i2c must support the Z8, and lirc_zilog must be able to coexist with ir-kbd-i2c. Proper sharing of the Z8 is, however, lower on my to-do list than fixing some internal lirc_zilog problems. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Sat, 2011-01-15 at 00:37 -0500, Jarod Wilson wrote: > On Jan 14, 2011, at 11:35 PM, Andy Walls wrote: > Receive with lirc_zilog does actually work slightly better, though its still > not perfect. Each key press (using irw to watch) always results in at least > two lines of output, both with sequence number 00 (i.e., two distinct events), > and holding a button down results in a stream of 00 events. So repeat is > obviously busted. But I don't see the wackiness that is happening > w/ir-kbd-i2c. > > Oh, and transmit works too. So this patch and the buffer alloc patch have now > been formally tested. Unless we go the custom get_key() route inside the hdpvr > driver, I think the rest of the legwork to make the hdpvr's IR part behave is > within lirc_zilog and ir-kbd-i2c (both of which I need to spend some more > time reading over). > > > > BTW, a checkpatch and compiler tested lirc_zilog.c is here: > > > > http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8 > > > > It should fix all the binding and allocation problems related to > > ir_probe()/ir_remove(). Except I suspect it may leak the Rx poll > > kthread. That's possibly another bug to add to the list. > > > > Anyway, $DIETY knows if the lirc_zilog module actually still works after > > all my hacks. Give it a test if you are adventurous. I won't be able > > to test until tomorrow evening. > > I'll try to grab those and give them a test tomorrow, and hey, I've even got > a baseline to test against now. I have now confirmed that with all the above patches to lirc_zilog, both Tx and Rx using an HVR-1600 work. Time to start cleaning up the less important things I noticed... Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] hdpvr: enable IR part
On Sat, 2011-01-15 at 01:56 -0500, Jarod Wilson wrote: > On Jan 15, 2011, at 12:37 AM, Jarod Wilson wrote: > >> Registered IR keymap rc-hauppauge-new > >> input: i2c IR (HD PVR) as /devices/virtual/rc/rc1/input6 > >> rc1: i2c IR (HD PVR) as /devices/virtual/rc/rc1 > >> ir-kbd-i2c: i2c IR (HD PVR) detected at i2c-1/1-0071/ir0 [Hauppage HD > >> PVR I2C] > Okay, last spam before I head off to bed... :) > > I can get ir-kbd-i2c behavior to pretty much match lirc_zilog wrt key repeat, > by simply setting init_data->polling_interval = 260; in hdpvr-i2c.c, which > matches up with the delay in lirc_zilog. With the 260 interval: RC-5 has a repetition interval of about 4096/36kHz = 113.8 ms, IIRC. Using 260 ms, you are throwing away one repeat from the remote for sure, maybe two. Maybe that will help you understand what may be going on. (I've lost the bubble on hdpvr with ir-kbd-i2c.) Regards, Andy > Event: time 1295072449.490542, -- Report Sync > Event: time 1295072453.321206, type 4 (Misc), code 4 (ScanCode), value 15 > Event: time 1295072453.321245, type 1 (Key), code 108 (Down), value 1 > Event: time 1295072453.321252, -- Report Sync > Event: time 1295072453.570512, type 1 (Key), code 108 (Down), value 0 > Event: time 1295072453.570544, -- Report Sync > Event: time 1295072453.575718, type 4 (Misc), code 4 (ScanCode), value 15 > Event: time 1295072453.575744, type 1 (Key), code 108 (Down), value 1 > Event: time 1295072453.575752, -- Report Sync > Event: time 1295072453.816215, type 4 (Misc), code 4 (ScanCode), value 15 > Event: time 1295072454.065515, type 1 (Key), code 108 (Down), value 0 > Event: time 1295072454.065544, -- Report Sync > > Lowering this a bit, I can get split personality, one press will look like > what I was originally seeing, another will look like the 260 output. > > Adding filtering (return 0 if buf[0] != 0x80) doesn't help any. > > The final thing I've noticed tonight is that ir-kbd-i2c calls rc_keydown > using a value of 0 for its 3rd parameter. From rc-main.c: > > * @toggle: the toggle value (protocol dependent, if the protocol doesn't > * support toggle values, this should be set to zero) > > Well, in this case, the protocol *does* use a toggle, so that's probably > something that could use fixing. Not sure it actually has anything to do with > the odd repeats I'm seeing. Okay, wasn't too much work to pass along toggle > values too, but it didn't help any. > > I'll sleep on it. -- 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
[RFC PATCH] ir-kbd-i2c, lirc_zilog: Allow bridge drivers to pass an IR trasnceiver mutex to I2C IR modules
The following patch allows bridge drivers, with an I2C IR Tx/Rx
transceiver, to pass a mutex for serializing access to a single I2C IR
chip between separate IR Tx and Rx modules.
The change modifies struct IR_i2c_init_data and struct IR_i2c to add
struct mutex *transceiver_lock
that ir-kbd-i2c and lirc_zilog will use, if provided by the bridge
driver. The changes to ir-kbd-i2c.[ch] and lirc_zilog.c provide the
functional change in the patch.
This patch also modifies cx18, ivtv, and hdpvr (sans Jarrod's recent
patches) to provide a transceiver_lock mutex to ir-kbd-i2c and
lirc_zilog.
I skimmed all the other modules that use IR_i2c_init_data. They all
appear to zero-fill the init_data properly before handing the data over
to ir-kbd-i2c.c.
I did find that pvrusb2 IR Rx for address 0x71 was broken, due to my
recommendation to remove automatic config for address 0x71 from
ir-kbd-i2c.c. I'll fix that in another patch, if someone with a pvrusb2
device doesn't beat me to it.
So without further ado...
diff --git a/drivers/media/video/cx18/cx18-driver.c
b/drivers/media/video/cx18/cx18-driver.c
index 676e5be..da1ef93 100644
--- a/drivers/media/video/cx18/cx18-driver.c
+++ b/drivers/media/video/cx18/cx18-driver.c
@@ -701,6 +701,7 @@ static int __devinit cx18_init_struct1(struct cx18 *cx)
mutex_init(&cx->serialize_lock);
mutex_init(&cx->gpio_lock);
+ mutex_init(&cx->ir_transceiver_lock);
mutex_init(&cx->epu2apu_mb_lock);
mutex_init(&cx->epu2cpu_mb_lock);
diff --git a/drivers/media/video/cx18/cx18-driver.h
b/drivers/media/video/cx18/cx18-driver.h
index f6f3e50..82dc747 100644
--- a/drivers/media/video/cx18/cx18-driver.h
+++ b/drivers/media/video/cx18/cx18-driver.h
@@ -626,6 +626,7 @@ struct cx18 {
struct cx18_i2c_algo_callback_data i2c_algo_cb_data[2];
struct IR_i2c_init_data ir_i2c_init_data;
+ struct mutex ir_transceiver_lock;
/* gpio */
u32 gpio_dir;
diff --git a/drivers/media/video/cx18/cx18-i2c.c
b/drivers/media/video/cx18/cx18-i2c.c
index c330fb9..7782de1 100644
--- a/drivers/media/video/cx18/cx18-i2c.c
+++ b/drivers/media/video/cx18/cx18-i2c.c
@@ -96,10 +96,12 @@ static int cx18_i2c_new_ir(struct cx18 *cx, struct
i2c_adapter *adap, u32 hw,
/* Our default information for ir-kbd-i2c.c to use */
switch (hw) {
case CX18_HW_Z8F0811_IR_RX_HAUP:
+ case CX18_HW_Z8F0811_IR_TX_HAUP:
init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
init_data->type = RC_TYPE_RC5;
init_data->name = cx->card_name;
+ init_data->transceiver_lock = &cx->ir_transceiver_lock;
info.platform_data = init_data;
break;
}
diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
b/drivers/media/video/hdpvr/hdpvr-core.c
index f7d1ee5..df4a02a 100644
--- a/drivers/media/video/hdpvr/hdpvr-core.c
+++ b/drivers/media/video/hdpvr/hdpvr-core.c
@@ -304,6 +304,7 @@ static int hdpvr_probe(struct usb_interface *interface,
mutex_init(&dev->io_mutex);
mutex_init(&dev->i2c_mutex);
+ mutex_init(&dev->ir_transceiver_mutex);
mutex_init(&dev->usbc_mutex);
dev->usbc_buf = kmalloc(64, GFP_KERNEL);
if (!dev->usbc_buf) {
diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
b/drivers/media/video/hdpvr/hdpvr-i2c.c
index 24966aa..b1e68b8 100644
--- a/drivers/media/video/hdpvr/hdpvr-i2c.c
+++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
@@ -48,13 +48,15 @@ static int hdpvr_new_i2c_ir(struct hdpvr_device *dev,
struct i2c_adapter *adap,
memset(&info, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, type, I2C_NAME_SIZE);
- /* Our default information for ir-kbd-i2c.c to use */
+ /* Our default information for ir-kbd-i2c.c and lirc_zilog.c to use */
switch (addr) {
case Z8F0811_IR_RX_I2C_ADDR:
+ case Z8F0811_IR_TX_I2C_ADDR:
init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
init_data->type = RC_TYPE_RC5;
init_data->name = "HD PVR";
+ init_data->transceiver_lock = &dev->ir_transceiver_mutex;
info.platform_data = init_data;
break;
}
diff --git a/drivers/media/video/hdpvr/hdpvr.h
b/drivers/media/video/hdpvr/hdpvr.h
index 37f1e4c..00c8563 100644
--- a/drivers/media/video/hdpvr/hdpvr.h
+++ b/drivers/media/video/hdpvr/hdpvr.h
@@ -112,6 +112,7 @@ struct hdpvr_device {
/* For passing data to ir-kbd-i2c */
struct IR_i2c_init_data ir_i2c_init_data;
+ struct mutex ir_transceiver_mutex;
/* usb control transfer buffer and lock */
struct mutexusbc_mutex;
diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c
index c87b6bc..6714e1e 100644
--- a/drivers/
[GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
Mauro, Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes for 2.6.38. The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set defaults for I2C client address 0x71. I know I was the one who recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv rely on it for the moment - Mea culpa. The lirc_zilog changes are tested to work with both Tx and Rx with an HVR-1600. I don't want to continue much further on lirc_zilog changes, unitl a few things happen: 1. I have developed, and have had tested, a patch for the pvrusb2 driver to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported device. 2. Jarrod finishes his changes related to the Z8 chip for hdpvr and they are pulled into media_tree.git branch. 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if adding some new fields for struct IR_i2c_init_data is acceptable. Specifically, I'd like to add a transceiver_lock mutex, a transceiver reset callback, and a data pointer for that reset callback. (Only lirc_zilog would use the reset callback and data pointer.) 4. I find spare time ever again. Anyway, here's the patchset reference... The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git z8 Andy Walls (11): lirc_zilog: Reword debug message in ir_probe() lirc_zilog: Remove disable_tx module parameter lirc_zilog: Split struct IR into structs IR, IR_tx, and IR_rx lirc_zilog: Don't make private copies of i2c clients lirc_zilog: Extensive rework of ir_probe()/ir_remove() lirc_zilog: Update IR Rx polling kthread start/stop and some printks lirc_zilog: Remove unneeded tests for existence of the IR Tx function lirc_zilog: Remove useless struct i2c_driver.command function lirc_zilog: Add Andy Walls to copyright notice and authors list lirc_zilog: Update TODO.lirc_zilog ir-kbd-i2c: Add back defaults setting for Zilog Z8's at addr 0x71 drivers/media/video/ir-kbd-i2c.c |6 + drivers/staging/lirc/TODO.lirc_zilog | 36 ++- drivers/staging/lirc/lirc_zilog.c| 650 ++ 3 files changed, 389 insertions(+), 303 deletions(-) Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH] ir-kbd-i2c, lirc_zilog: Allow bridge drivers to pass an IR trasnceiver mutex to I2C IR modules
On Sun, 2011-01-16 at 16:27 -0200, Mauro Carvalho Chehab wrote: > Jarod/Andy, > > For now, I'm marking all those ir-kbd-i2c/lirc_zilog patches as "RFC" at > patchwork, > as I'm not sure if they're ok, and because there are a few revisions of them > and > I'm afraid to apply some wrong version. And that's just fine. :) That particular RFC was to get mostly Jean's opinion on adding fields to struct IR_i2c_init_data and struct IR_i2c and code to ir-kbd-i2c. > Please, after finishing and testing, send me a patch series or, preferably, a > git pull with those stuff. I just sent a [GIT PATCHES for 2.6.38], which is my pull request. It fixes one minor regression in ir-kbd-i2c.c. The rest of the patches are limited to lirc_zilog and do not modify any bridge drivers. The lirc_zilog changes were tested by me using my HVR-1600. Jarrod will have to ask you to pull any hdpvr fixes, when he feels they are ready. Note my pull request does *not* include the patches in the subject [RFC PATCH], so no worries about pulling those in. :) I'll submit a pull for those when they are correct and ready. 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
[RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
When registering an IR Rx device with the I2C subsystem, provide more detailed
information about the IR device and default remote configuration for the IR
driver modules.
Also explicitly register any IR Tx device with the I2C subsystem.
Signed-off-by: Andy Walls
Cc: Mike Isely
--
Mike,
As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
Z8 IR units on devices supported by pvrusb2.
Please review and comment. This patch could have been written a number
of ways. The way I chose was very direct: hard-coding information in a
single function.
A git branch with this change, and the updated lirc_zilog, is here:
git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
Regards,
Andy
diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
index ac94a8b..305e6aa 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
+++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
@@ -40,6 +40,7 @@
#include "pvrusb2-io.h"
#include
#include
+#include
#include "pvrusb2-devattr.h"
/* Legal values for PVR2_CID_HSM */
@@ -202,6 +203,7 @@ struct pvr2_hdw {
/* IR related */
unsigned int ir_scheme_active; /* IR scheme as seen from the outside */
+ struct IR_i2c_init_data ir_init_data; /* params passed to IR modules */
/* Frequency table */
unsigned int freqTable[FREQTABLE_SIZE];
diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
index 7cbe18c..ccc8849 100644
--- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
+++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
@@ -19,6 +19,7 @@
*/
#include
+#include
#include "pvrusb2-i2c-core.h"
#include "pvrusb2-hdw-internal.h"
#include "pvrusb2-debug.h"
@@ -48,13 +49,6 @@ module_param_named(disable_autoload_ir_video,
pvr2_disable_ir_video,
MODULE_PARM_DESC(disable_autoload_ir_video,
"1=do not try to autoload ir_video IR receiver");
-/* Mapping of IR schemes to known I2C addresses - if any */
-static const unsigned char ir_video_addresses[] = {
- [PVR2_IR_SCHEME_ZILOG] = 0x71,
- [PVR2_IR_SCHEME_29XXX] = 0x18,
- [PVR2_IR_SCHEME_24XXX] = 0x18,
-};
-
static int pvr2_i2c_write(struct pvr2_hdw *hdw, /* Context */
u8 i2c_addr, /* I2C address we're talking to */
u8 *data, /* Data to write */
@@ -574,26 +568,56 @@ static void do_i2c_scan(struct pvr2_hdw *hdw)
static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
{
struct i2c_board_info info;
- unsigned char addr = 0;
+ struct IR_i2c_init_data *init_data = &hdw->ir_init_data;
if (pvr2_disable_ir_video) {
pvr2_trace(PVR2_TRACE_INFO,
"Automatic binding of ir_video has been disabled.");
return;
}
- if (hdw->ir_scheme_active < ARRAY_SIZE(ir_video_addresses)) {
- addr = ir_video_addresses[hdw->ir_scheme_active];
- }
- if (!addr) {
+ memset(&info, 0, sizeof(struct i2c_board_info));
+ switch (hdw->ir_scheme_active) {
+ case PVR2_IR_SCHEME_24XXX: /* FX2-controlled IR */
+ case PVR2_IR_SCHEME_29XXX: /* Original 29xxx device */
+ init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP;
+ init_data->type = RC_TYPE_RC5;
+ init_data->name = hdw->hdw_desc->description;
+ init_data->polling_interval = 100; /* ms From ir-kbd-i2c */
+ /* IR Receiver */
+ info.addr = 0x18;
+ info.platform_data = init_data;
+ strlcpy(info.type, "ir_video", I2C_NAME_SIZE);
+ pvr2_trace(PVR2_TRACE_INFO, "Binding %s to i2c address 0x%02x.",
+ info.type, info.addr);
+ i2c_new_device(&hdw->i2c_adap, &info);
+ break;
+ case PVR2_IR_SCHEME_ZILOG: /* HVR-1950 style */
+ case PVR2_IR_SCHEME_24XXX_MCE: /* 24xxx MCE device */
+ init_data->ir_codes = RC_MAP_HAUPPAUGE_NEW;
+ init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
+ init_data->type = RC_TYPE_RC5;
+ init_data->name = hdw->hdw_desc->description;
+ init_data->polling_interval = 260; /* ms From lirc_zilog */
+ /* IR Receiver */
+ info.addr = 0x71;
+ info.platform_data = init_data;
+ strlcpy(info.t
Re: [RFC PATCH] pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c
On Sun, 2011-01-16 at 20:27 -0600, Mike Isely wrote:
> Andy:
>
> Is the IR_i2c_init_data struct instance required to remain around for
> the life of the driver's registration and is that why you stuffed it
> into the pvr2_hdw struct?
Yes.
The loading of ir-kbd-i2c or lirc_zilog can happen some undetermined
amount of time after or before the pvrusb2 driver registers the I2C
devices. The data needs to persist on a per device basis; it cannot
come from the stack.
> Second: If the first question is yes, then is
> that struct considered to be read-only once it is set up and passed
> through to the i2c device registration function?
Yes. It will only be read once by lirc_zilog or ir-kbd-i2c in their
probe methods. Although both of those modules can be unloaded and
reloaded, so there is the possibility of being read again any number of
times.
> In other words, could
> that structure be a const static initialized at compile time, perhaps
> as part of a table definition?
Right now, yes. In the near future, I need to use to to pass 3
non-const items though:
1. A "struct mutex *transceiver_lock" so that the bridge driver can pass
a mutex to multiple modules accessing the Z8. That would be a per
device instance mutex, instantiated and initialized by the bridge
driver. The use case where this would be needed is a setup where
ir-kbd-i2c handles Z8 IR Rx and lirc_zilog handles only Z8 IR Tx of the
same chip.
2. A bridge driver provided "void (*reset_ir_chip)(struct i2c_adapter
*adap)", or maybe "void (*reset_ir_chip)(void *priv)", callback to
reset the transceiver chip when it gets hung. The original lirc_pvr150
module had some hard coded reset function names and calls in it, but
they were removed with the rename to lirc_zilog and move into the
kernel. I'd like to get that ability back.
3. A bridge driver provided private data structure for the "void *priv"
argument of the aforementioned reset callback. This would also be a per
device object instantiated and initialized by the bridge driver.
> I believe I follow this and it looks good. The concept looks very
> simple and it's nice that the changes are really only in a single spot.
> Just thinking ahead about making the setup table-driven and not
> requiring data segment storage.
With the patch right now it could be constant, I think. You would have
to use some generic name, like "pvrusb2 IR", instead of
hdw->hdw_desc->description though.
For my future plans, if you don't provide a reset callback and don't
wish to provide a mutex, then yes you can keep it constant.
I suspect not providing a reset callback may be OK.
Not providing a mutex is also OK but it imposes a limitation: only one
IR module should be allowed to use the Z8 chip. That means
only lirc_zilog for IR Tx/Rx with Rx through LIRC, or
only ir-kbd-i2c for IR Rx through the the Linux input subsystem.
> -Mike
>
>
> Acked-By: Mike Isely
Thanks. I'll pull this into my Z8 branch then.
Regards,
Andy
> On Sun, 16 Jan 2011, Andy Walls wrote:
>
> >
> > When registering an IR Rx device with the I2C subsystem, provide more
> > detailed
> > information about the IR device and default remote configuration for the IR
> > driver modules.
> >
> > Also explicitly register any IR Tx device with the I2C subsystem.
> >
> > Signed-off-by: Andy Walls
> > Cc: Mike Isely
> >
> > --
> > Mike,
> >
> > As discussed on IRC, this patch will enable lirc_zilog to bind to Zilog
> > Z8 IR units on devices supported by pvrusb2.
> >
> > Please review and comment. This patch could have been written a number
> > of ways. The way I chose was very direct: hard-coding information in a
> > single function.
> >
> > A git branch with this change, and the updated lirc_zilog, is here:
> >
> > git://linuxtv.org/awalls/media_tree.git z8-pvrusb2
> >
> >
> > http://git.linuxtv.org/awalls/media_tree.git?a=shortlog;h=refs/heads/z8-pvrusb2
> >
> > Regards,
> > Andy
> >
> > diff --git a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > index ac94a8b..305e6aa 100644
> > --- a/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > +++ b/drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h
> > @@ -40,6 +40,7 @@
> > #include "pvrusb2-io.h"
> > #include
> > #include
> > +#include
> > #include "pvrusb2-devattr.h"
> >
> > /* Legal values for PVR2_CID_HSM */
> > @@ -202,6 +203,7 @@ struct pvr2_hdw {
> >
> > /* IR related */
> > unsigned int ir_s
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote: > Mauro, > > Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes > for 2.6.38. > > The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set > defaults for I2C client address 0x71. I know I was the one who > recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv > rely on it for the moment - Mea culpa. > > The lirc_zilog changes are tested to work with both Tx and Rx with an > HVR-1600. I don't want to continue much further on lirc_zilog changes, > unitl a few things happen: > > 1. I have developed, and have had tested, a patch for the pvrusb2 driver > to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported > device. Mauro, I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I have added it to my "z8" branch and this pull request. > 2. Jarrod finishes his changes related to the Z8 chip for hdpvr and they > are pulled into media_tree.git branch. > > 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if > adding some new fields for struct IR_i2c_init_data is acceptable. > Specifically, I'd like to add a transceiver_lock mutex, a transceiver > reset callback, and a data pointer for that reset callback. > (Only lirc_zilog would use the reset callback and data pointer.) > > 4. I find spare time ever again. Here's the updated changeset information: The following changes since commit 0a97a683049d83deaf636d18316358065417d87b: [media] cpia2: convert .ioctl to .unlocked_ioctl (2011-01-06 11:34:41 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git z8 Andy Walls (12): lirc_zilog: Reword debug message in ir_probe() lirc_zilog: Remove disable_tx module parameter lirc_zilog: Split struct IR into structs IR, IR_tx, and IR_rx lirc_zilog: Don't make private copies of i2c clients lirc_zilog: Extensive rework of ir_probe()/ir_remove() lirc_zilog: Update IR Rx polling kthread start/stop and some printks lirc_zilog: Remove unneeded tests for existence of the IR Tx function lirc_zilog: Remove useless struct i2c_driver.command function lirc_zilog: Add Andy Walls to copyright notice and authors list lirc_zilog: Update TODO.lirc_zilog ir-kbd-i2c: Add back defaults setting for Zilog Z8's at addr 0x71 pvrusb2: Provide more information about IR units to lirc_zilog and ir-kbd-i2c drivers/media/video/ir-kbd-i2c.c |6 + drivers/media/video/pvrusb2/pvrusb2-hdw-internal.h |2 + drivers/media/video/pvrusb2/pvrusb2-i2c-core.c | 62 ++- drivers/staging/lirc/TODO.lirc_zilog | 36 +- drivers/staging/lirc/lirc_zilog.c | 650 +++- 5 files changed, 434 insertions(+), 322 deletions(-) Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH][_COMPAT_H] git://linuxtv.org/media_build.git Legacy issues
On Mon, 2011-01-17 at 22:59 +, Malcolm Priestley wrote: > Clean up legacy issues for error free build on Kernel 2.6.37. > > Today while testing on Kernel 2.6.35 latest tarball throws error with > alloc_ordered_workqueue undefined on Kernels less than 2.6.37. defined back > to > create_singlethread_workqueue. > > Please test on other kernel versions. > > Tested-on 2.6.35/37 by: Malcolm Priestley > > > diff --git a/v4l/compat.h b/v4l/compat.h > index 9e622ce..df98698 100644 > --- a/v4l/compat.h > +++ b/v4l/compat.h > @@ -749,6 +749,8 @@ static inline void *vzalloc(unsigned long size) > > #endif > > +#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 37) > + > #if NEED_FLUSH_WORK_SYNC > #define flush_work_sync(dev) > #endif > @@ -760,6 +762,14 @@ static inline void *vzalloc(unsigned long size) > } > #endif > > +#define alloc_ordered_workqueue(a,b) create_singlethread_workqueue(a) That will get cx18 to compile. However, I can tell you without testing, the latest cx18 driver could badly affect system event processing performance on older kernels. This is because another change happened at the same time as the change to call alloc_ordered_workqueue(). A kernel version before that, CMWQ was added to the kernel, so there was no longer a need for the cx18_out_work workqueue. So now the cx18_out_work workqueue has been removed from the cx18 driver. In the older kernels without CMWQ and without the cx18_out_work workqueue, outgoing cx18 buffer work will get queued to the [keventd/M] kernel threads. Unrelated system work being processed by [keventd/M] threads will regularly find itself *waiting for the CX23418 hardware* to respond to firmware commands. It would be better to not allow the newest cx18 driver version to compile on older kernels. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote: > On Jan 16, 2011, at 10:29 PM, Andy Walls wrote: > > > On Sun, 2011-01-16 at 14:20 -0500, Andy Walls wrote: > >> Mauro, > >> > >> Please pull the one ir-kbd-i2c change and multiple lirc_zilog changes > >> for 2.6.38. > >> > >> The one ir-kbd-i2c change is to put back a case to have ir-kbd-i2c set > >> defaults for I2C client address 0x71. I know I was the one who > >> recommend that ir-kbd-i2c not do this, but I discovered pvrusb2 and bttv > >> rely on it for the moment - Mea culpa. > >> > >> The lirc_zilog changes are tested to work with both Tx and Rx with an > >> HVR-1600. I don't want to continue much further on lirc_zilog changes, > >> unitl a few things happen: > >> > >> 1. I have developed, and have had tested, a patch for the pvrusb2 driver > >> to allow the in kernel lirc_zilog to bind to a Z8 on a pvrusb2 supported > >> device. > > > > Mauro, > > > > I have developed a patch for pvrusb2 and Mike Isely provided his Ack. I > > have added it to my "z8" branch and this pull request. > > I've finally got around to trying it out with the HVR-1950 I've got here, > and it does do the trick for ir-kbd-i2c (albeit I never see proper key > repeats, only alternating press/release key events). Yay, a small victory. I explicitly set the polling interval to 260 ms in pvrusb2, based on your hdpvr findings and lirc_zilog code. I guess you can try tweaking that back to 100 ms. > Not working with > lirc_zilog yet, it fails to load, due to an -EIO ret to one of the > i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't > looked into it any more than that yet. Well technically lirc_zilog doesn't "probe" anymore. It relies on the bridge driver telling it the truth. But yes, lirc_zilog is overly sensitive to anything not being right during lirc_zilog.c:ir_probe(). BTW, does your HVR-1950 have a blaster? The simple code I added to pvrusb2 doesn't try to detect a unit on address 0x70. It always assumes the Z8 is Tx capable. With the cx18 and ivtv cards, the Hauppauge EEPROM indicates whether a blaster is present. For those bridge drivers, I can communicate that information to the IR modules. For the hdpvr and pvrusb2, my short term plan was to always assume a Z8 could Tx, and make lirc_zilog not barf when it couldn't talk to a Tx unit. I notice that Mike had written some short, simple IR unit detection code here for other reasons: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l661 http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542 For debugging, you might want to hack in a probe of address 0x70 for your HVR-1950, to ensure the Tx side responds in the bridge driver. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 2011-01-19 at 13:40 +0100, Jean Delvare wrote: > On Wed, 19 Jan 2011 07:21:58 -0500, Andy Walls wrote: > > For debugging, you might want to hack in a probe of address 0x70 for > > your HVR-1950, to ensure the Tx side responds in the bridge driver. > > ... keeping in mind that the Z8 doesn't seem to like quick writes, so > short reads should be used for probing purpose. > Noted. Thanks. Actually, I think that might be due to the controller in the USB connected devices (hdpvr and pvrusb2). The PCI connected devices, like cx18 cards, don't have a problem with the Z8, the default I2C probe method, and i2c-algo-bit. (A good example of why only bridge drivers should do any required probing.) Looking at the code in pvrusb2, it appears to already use a 0 length read for a probe: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/pvrusb2/pvrusb2-i2c-core.c;h=ccc884948f34b385563ccbf548c5f80b33cd4f08;hb=refs/heads/staging/for_2.6.38-rc1#l542 Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 2011-01-19 at 07:20 -0600, Mike Isely wrote: > On Wed, 19 Jan 2011, Andy Walls wrote: > > > On Wed, 2011-01-19 at 00:20 -0500, Jarod Wilson wrote: > > > > > > > Not working with > > > lirc_zilog yet, it fails to load, due to an -EIO ret to one of the > > > i2c_master_send() calls in lirc_zilog during probe of the TX side. Haven't > > > looked into it any more than that yet. > > > > Well technically lirc_zilog doesn't "probe" anymore. It relies on the > > bridge driver telling it the truth. > > The bridge driver (pvrusb2) still does one probe if it's a 24xxx device: > It probes 0x71 in order to determine if it is dealing with an MCE > variant device. Hauppauge did not change the USB ID when they released > the 24xxx MCE variant (which has the IR blaster, thus the zilog device). > The only way to tell the two devices apart is by discovering the > existence of the zilog device - and the bridge driver needs to do this > in order to properly disable its "emulated" I2C IR receiver which would > otherwise be needed for the non-MCE device. > > Based on the discussion here, could that probe be a source of trouble on > the 24XXX MCE device? IMO, No. I think it is needed and just fine. As I understand it, the rules/guidelines for I2C probing are now something like this: 1. I2C device driver modules (ir-kbd-i2c, lirc_zilog, etc.) should not do hardware probes at all. They are to assume the bridge or platform drivers verified the I2C slave hardware's existence somehow. 2. Bridge drivers (pvrusb, hdpvr, cx18, ivtv, etc.) should not ask the I2C subsystem to probe hardware that it knows for sure exists, or knows for sure does not exist. Just add the I2C device or not. 3. Bridge drivers should generally ask the I2C subsystem to probe for hardware that _may_ exist. 4. If the default I2C subsystem hardware probe method doesn't work on a particular hardware unit, the bridge driver may perform its own hardware probe or provide a custom hardware probe method to the I2C subsystem. hdpvr and pvrusb2 currently do the former. > This probing behavior does not happen for HVR-1950 (or HVR-1900) since > there's only one possible IR configuration there. So the HVR-1950 only has Z8's capable of both Tx and Rx? No HVR-1950 has an Rx only Z8 unit? Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
Jean,
As Mike noted, "transceiver" is a contraction of "transmitter-receiver". But I
wouldn't blame English speakers in general for that, just English speaking
engineers. ;)
English speaking engineers (likely) also orignated use of the "x" as shorthand
for "trans-" and "crys-".
"Transceiver_lock" was intended to mean a lock protecting access to both
portions of a chip: tx and rx.
I'm still mulling it all over though. Some change will be made to
IR_i2c_init_data. I found I need some more time to design exactly what I need.
Regards,
Andy
Mike Isely wrote:
>On Wed, 19 Jan 2011, Jean Delvare wrote:
>
>> Hi Andy,
>>
>> On Sun, 16 Jan 2011 14:20:49 -0500, Andy Walls wrote:
>> > 3. I hear from Jean, or whomever really cares about ir-kbd-i2c, if
>> > adding some new fields for struct IR_i2c_init_data is acceptable.
>> > Specifically, I'd like to add a transceiver_lock mutex, a transceiver
>> > reset callback, and a data pointer for that reset callback.
>> > (Only lirc_zilog would use the reset callback and data pointer.)
>>
>> Adding fields to these structures is perfectly fine, if you need to do
>> that, just go on.
>>
>> But I'm a little confused about the names you chose,
>> "ir_transceiver_lock" and "transceiver_lock". These seem too
>> TX-oriented for a mutex that is supposed to synchronize TX and RX
>> access. It's particularly surprising for the ir-kbd-i2c driver, which
>> as far as I know only supports RX. The name "xcvr_lock" you used for
>> lirc_zilog seems more appropriate.
>
>Actually the term "transceiver" is normally understood to mean both
>directions. Otherwise it would be "receiver" or "transmitter".
>Another screwy as aspect of english, and I say this as a native english
>speaker. The term "xcvr" is usually just considered to be shorthand for
>"transceiver".
>
> -Mike
>
>
>--
>
>Mike Isely
>isely @ isely (dot) net
>PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
>--
>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
N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ&�)ߡ�a���� �G���h��j:+v���w��٥
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Wed, 2011-01-19 at 23:45 -0500, Jarod Wilson wrote: > On Jan 19, 2011, at 3:08 PM, Jarod Wilson wrote: > > I'm working on > > fixing up hdpvr-i2c further right now, and will do some more prodding > > with pvrusb2, the code for which looks correct with two i2c_new_device() > > calls in it, one for each address, so I just need to figure out why > > lirc_zilog is getting an -EIO trying to get tx brought up. > > So as we were discussing on irc today, the -EIO is within lirc_zilog's > send_boot_data() function. The firmware is loaded, and then we send the > z8 a command to activate the firmware, immediately follow by an attempt > to read the firmware version. The z8 is still busy when we do that, and > throwing in a simple mdelay() remedies the problem for both the hvr-1950 > and the hdpvr -- tried 100 initially, and all the way down to 20 still > worked, didn't try any lower. The Z8 on my HVR-1600 is using a 18.432 MHz crystal for its clock. The Z8 CPU Fetch and Execution units are running with a pipeline depth of 1: 1 insn being executed while another 1 insn is being fetched. Most Z8 fetch or execution cycle counts are in the range of 2-4 cycles. So let's just assume an insn takes 4 cycles to execute. 18.432 MHz * 20 ms = 368,640 cycles 368,640 cycles / 4 cycles/insn = 92,160 insns 20 ms is ~90k instructions, and seems like too long a delay to be just for Z8 latency. I find it interesting that for the HVR-1600 the delay isn't needed at all. I'm wondering if there might also be some Linux/USB latency in getting commands shoved over to the HVR-1950's controller (or maybe latency in the HVR-1950's controller too), for which this delay is really accounting. I suppose in kernel tracing can be used to find the latency on shoving things across the USB and watching for any Ack from the HVR-1950 controller. An experiment for some other day, I guess. > And I definitely horked up the hdpvr i2c a bit, but have a follow-up > patch that goes back to doing the right thing with two i2c_new_device() > calls, which I've successfully tested with the latest lirc_zilog plus > mdelay patch. Yay! Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES for 2.6.38] Zilog Z8 IR unit fixes
On Thu, 2011-01-20 at 16:49 -0500, Jarod Wilson wrote: > On Jan 20, 2011, at 8:22 AM, Andy Walls wrote: > > > On Wed, 2011-01-19 at 23:45 -0500, Jarod Wilson wrote: > >> On Jan 19, 2011, at 3:08 PM, Jarod Wilson wrote: > > > >>> I'm working on > >>> fixing up hdpvr-i2c further right now, and will do some more prodding > >>> with pvrusb2, the code for which looks correct with two i2c_new_device() > >>> calls in it, one for each address, so I just need to figure out why > >>> lirc_zilog is getting an -EIO trying to get tx brought up. > >> > >> So as we were discussing on irc today, the -EIO is within lirc_zilog's > >> send_boot_data() function. The firmware is loaded, and then we send the > >> z8 a command to activate the firmware, immediately follow by an attempt > >> to read the firmware version. The z8 is still busy when we do that, and > >> throwing in a simple mdelay() remedies the problem for both the hvr-1950 > >> and the hdpvr -- tried 100 initially, and all the way down to 20 still > >> worked, didn't try any lower. > > > > The Z8 on my HVR-1600 is using a 18.432 MHz crystal for its clock. > > > > The Z8 CPU Fetch and Execution units are running with a pipeline depth > > of 1: 1 insn being executed while another 1 insn is being fetched. Most > > Z8 fetch or execution cycle counts are in the range of 2-4 cycles. So > > let's just assume an insn takes 4 cycles to execute. > > > > 18.432 MHz * 20 ms = 368,640 cycles > > 368,640 cycles / 4 cycles/insn = 92,160 insns > > > > 20 ms is ~90k instructions, and seems like too long a delay to be just > > for Z8 latency. > > Some further testing today with a try-check success-delay-retry loop > shows one i2c_master_send() failure plus a udelay(100), and the second > i2c_master_send() typically always works (I haven't seen it *not* work > on the HVR-1950 in cursory testing). Cool. > A second similar loop has proven necessary for IR TX attempts to actually > claim to succeed -- not 100% certain they really worked, as I don't have > the IR emitter with me at the moment, its at home hooked up to my hdpvr, > but I suspect its working fine now. I'm not sure I follow here. By "claim" I assume you mean no i2c_master_send() error. > > I find it interesting that for the HVR-1600 the delay isn't needed at > > all. > > > > I'm wondering if there might also be some Linux/USB latency in getting > > commands shoved over to the HVR-1950's controller (or maybe latency in > > the HVR-1950's controller too), for which this delay is really > > accounting. I suppose in kernel tracing can be used to find the latency > > on shoving things across the USB and watching for any Ack from the > > HVR-1950 controller. An experiment for some other day, I guess. > > Yeah, definitely seems to be specific to usb devices. On the plus side, > the delay loops should only add insignificant delay overhead for pci > devices, since if they work on the first call, there won't be any delay > added. Cool, nice implementation. > Oh, I've also got IR RX with ir-kbd-i2c attached to the HVR-1950 working > much better now, with the polling interval reverted to the standard > 100ms, but simply introducing the same i2c_master_send() poll that > lirc_zilog uses into get_key_haup_xvr(). You might want to check what video cards in the source tree request of, or are defaulted by, ir-kbd-i2c to use get_key_haup_xvr(). If it's only the chips at address 0x71, you're probably OK. > I want to test today's changes with the hdpvr tonight (and verify that > tx is working on the HVR-1950) before I send along my current stack of > patches, and I have suspicions that most of the hdpvr-specific crud in > lirc_zilog is bogus now -- it *should* behave exactly like the HVR-1950, > which obviously doesn't follow any of those hdpvr-specific code paths, > so I'm hoping we can rip out some additional complexity from lirc_zilog. Good riddance to old kludges. :) You could then rename the i2c client strings back to "ir_[tr]x_z8f0811_haup". We're going to modify struct IR_i2c_init_data with all the bridge specific parameters that need to be sent anyway, so no need to encode that information implicitly in the client's name anymore. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/3] hdpvr: fix up i2c device registration
On Thu, 2011-01-20 at 23:30 -0500, Jarod Wilson wrote:
> We have to actually call i2c_new_device() once for each of the rx and tx
> addresses. Also improve error-handling and device remove i2c cleanup.
>
> Signed-off-by: Jarod Wilson
Reviewed-by: Andy Walls
I do have some comments, but the real show-stoppers are:
- '#if defined(..' for the i2c_del_adapter() in the error path
- A very unlikely race by using file scope data
See below.
> ---
> drivers/media/video/hdpvr/hdpvr-core.c | 21 +
> drivers/media/video/hdpvr/hdpvr-i2c.c | 28
> drivers/media/video/hdpvr/hdpvr.h |6 +-
> 3 files changed, 42 insertions(+), 13 deletions(-)
>
> diff --git a/drivers/media/video/hdpvr/hdpvr-core.c
> b/drivers/media/video/hdpvr/hdpvr-core.c
> index a6572e5..f617a23 100644
> --- a/drivers/media/video/hdpvr/hdpvr-core.c
> +++ b/drivers/media/video/hdpvr/hdpvr-core.c
> @@ -381,13 +381,21 @@ static int hdpvr_probe(struct usb_interface *interface,
> #if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> retval = hdpvr_register_i2c_adapter(dev);
> if (retval < 0) {
> - v4l2_err(&dev->v4l2_dev, "registering i2c adapter failed\n");
> + v4l2_err(&dev->v4l2_dev, "i2c adapter register failed\n");
> goto error;
> }
>
> - retval = hdpvr_register_i2c_ir(dev);
> - if (retval < 0)
> - v4l2_err(&dev->v4l2_dev, "registering i2c IR devices failed\n");
> + hdpvr_register_ir_rx_i2c(dev);
> + if (!dev->i2c_rx) {
> + v4l2_err(&dev->v4l2_dev, "i2c IR RX device register failed\n");
> + goto reg_fail;
> + }
> +
> + hdpvr_register_ir_tx_i2c(dev);
> + if (!dev->i2c_tx) {
> + v4l2_err(&dev->v4l2_dev, "i2c IR TX device register failed\n");
> + goto reg_fail;
> + }
Once your driver is debugged and complete, there is really never a need
to save pointers to the i2c_clients. You might want to consider having
void hdpvr_register_ir_?x_i2c() instead return a pointer that you can
check against NULL.
> #endif
>
> /* let the user know what node this device is now attached to */
> @@ -395,6 +403,8 @@ static int hdpvr_probe(struct usb_interface *interface,
> video_device_node_name(dev->video_dev));
> return 0;
>
> +reg_fail:
> + i2c_del_adapter(&dev->i2c_adapter);
Don't you need an '#if defined(CONFIG_I2C)...' here, in case the symbol
does not exist?
> error:
> if (dev) {
> /* Destroy single thread */
> @@ -424,6 +434,9 @@ static void hdpvr_disconnect(struct usb_interface
> *interface)
> mutex_lock(&dev->io_mutex);
> hdpvr_cancel_queue(dev);
> mutex_unlock(&dev->io_mutex);
> +#if defined(CONFIG_I2C) || defined(CONFIG_I2C_MODULE)
> + i2c_del_adapter(&dev->i2c_adapter);
> +#endif
> video_unregister_device(dev->video_dev);
> atomic_dec(&dev_nr);
> }
> diff --git a/drivers/media/video/hdpvr/hdpvr-i2c.c
> b/drivers/media/video/hdpvr/hdpvr-i2c.c
> index 89b71fa..e891bb0 100644
> --- a/drivers/media/video/hdpvr/hdpvr-i2c.c
> +++ b/drivers/media/video/hdpvr/hdpvr-i2c.c
> @@ -31,26 +31,38 @@
> #define Z8F0811_IR_RX_I2C_ADDR 0x71
>
>
> -static struct i2c_board_info hdpvr_i2c_board_info = {
> +static struct i2c_board_info hdpvr_ir_tx_i2c_board_info = {
> I2C_BOARD_INFO("ir_tx_z8f0811_hdpvr", Z8F0811_IR_TX_I2C_ADDR),
> +};
This does not need to be file scope. (In fact this creates a hard to
trigger race in the function below.)
It should be non-static function scope, as the I2C subsystem will make a
copy of the string and address byte and the platform data pointer when
you add the I2C device.See pvrusb2.
> +void hdpvr_register_ir_tx_i2c(struct hdpvr_device *dev)
> +{
> + struct IR_i2c_init_data *init_data = &dev->ir_i2c_init_data;
> +
> + init_data->name = "HD-PVR";
> + hdpvr_ir_tx_i2c_board_info.platform_data = init_data;
If hdpvr_ir_tx_i2c_board_info is file scope and static, then you have a
race for the platform data pointer when two hdpvr's are instantiated
simultaneously. It'll be extremely rare, I know, but it is possible.
You should use a function scope copy of the board info.
The per device instance of the init_data is correct.
> + dev->i2c_tx = i2c_new_device(&dev->i2c_adapter,
> + &hdpvr_ir_tx_i2c_board_info);
> +}
Again maybe just have this function 'return i2c_new_device(...);'.
The caller can
Re: [PATCH 2/3] lirc_zilog: z8 on usb doesn't like back-to-back i2c_master_send
On Thu, 2011-01-20 at 23:30 -0500, Jarod Wilson wrote:
> Both the HD-PVR and HVR-1950, driven by the hdpvr and pvrusb2 drivers
> respectively, have a zilog z8 chip exposed via i2c. These are both
> usb-connected devices, and on both of them, back-to-back i2c_master_send
> calls that work fine with a z8 on a pci card fail with a -EIO, as the
> chip isn't yet ready from the prior command. To cope with that, add a
> delay and retry loop where necessary.
>
> Signed-off-by: Jarod Wilson
I haven't tested it, but it looks good.
Acked-by: Andy Walls
> ---
> drivers/staging/lirc/lirc_zilog.c | 32 ++--
> 1 files changed, 26 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/staging/lirc/lirc_zilog.c
> b/drivers/staging/lirc/lirc_zilog.c
> index 3fe5f41..0aad0d7 100644
> --- a/drivers/staging/lirc/lirc_zilog.c
> +++ b/drivers/staging/lirc/lirc_zilog.c
> @@ -495,7 +495,7 @@ static int send_data_block(struct IR_tx *tx, unsigned
> char *data_block)
> /* send boot data to the IR TX device */
> static int send_boot_data(struct IR_tx *tx)
> {
> - int ret;
> + int ret, i;
> unsigned char buf[4];
>
> /* send the boot block */
> @@ -503,7 +503,7 @@ static int send_boot_data(struct IR_tx *tx)
> if (ret != 0)
> return ret;
>
> - /* kick it off? */
> + /* Hit the go button to activate the new boot data */
> buf[0] = 0x00;
> buf[1] = 0x20;
> ret = i2c_master_send(tx->c, buf, 2);
> @@ -511,7 +511,19 @@ static int send_boot_data(struct IR_tx *tx)
> zilog_error("i2c_master_send failed with %d\n", ret);
> return ret < 0 ? ret : -EFAULT;
> }
> - ret = i2c_master_send(tx->c, buf, 1);
> +
> + /*
> + * Wait for zilog to settle after hitting go post boot block upload.
> + * Without this delay, the HD-PVR and HVR-1950 both return an -EIO
> + * upon attempting to get firmware revision, and tx probe thus fails.
> + */
> + for (i = 0; i < 10; i++) {
> + ret = i2c_master_send(tx->c, buf, 1);
> + if (ret == 1)
> + break;
> + udelay(100);
> + }
> +
> if (ret != 1) {
> zilog_error("i2c_master_send failed with %d\n", ret);
> return ret < 0 ? ret : -EFAULT;
> @@ -523,8 +535,8 @@ static int send_boot_data(struct IR_tx *tx)
> zilog_error("i2c_master_recv failed with %d\n", ret);
> return 0;
> }
> - if (buf[0] != 0x80) {
> - zilog_error("unexpected IR TX response: %02x\n", buf[0]);
> + if ((buf[0] != 0x80) && (buf[0] != 0xa0)) {
> + zilog_error("unexpected IR TX init response: %02x\n", buf[0]);
> return 0;
> }
> zilog_notify("Zilog/Hauppauge IR blaster firmware version "
> @@ -827,7 +839,15 @@ static int send_code(struct IR_tx *tx, unsigned int
> code, unsigned int key)
> zilog_error("i2c_master_send failed with %d\n", ret);
> return ret < 0 ? ret : -EFAULT;
> }
> - ret = i2c_master_send(tx->c, buf, 1);
> +
> + /* Give the z8 a moment to process data block */
> + for (i = 0; i < 10; i++) {
> + ret = i2c_master_send(tx->c, buf, 1);
> + if (ret == 1)
> + break;
> + udelay(100);
> + }
> +
> if (ret != 1) {
> zilog_error("i2c_master_send failed with %d\n", ret);
> return ret < 0 ? ret : -EFAULT;
--
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 3/3] ir-kbd-i2c: improve remote behavior with z8 behind usb
On Thu, 2011-01-20 at 23:30 -0500, Jarod Wilson wrote:
> Add the same "are you ready?" i2c_master_send() poll command to
> get_key_haup_xvr found in lirc_zilog, which is apparently seen in
> the Windows driver for the PVR-150 w/a z8. This stabilizes what is
> received from both the HD-PVR and HVR-1950, even with their polling
> intervals at the default of 100, thus the removal of the custom
> 260ms polling_interval in pvrusb2-i2c-core.c.
>
> CC: Andy Walls
> CC: Mike Isley
> Signed-off-by: Jarod Wilson
I haven't tested it, but it looks good.
The only thing to worry about is accidentally writing a 0 to register 0
at address 0x71 and maybe losing an Rx button press. (However, for that
to happen, the Z8 would have already screwed up in its role of an I2C
slave anyway, or the I2C master did not honor the Z8's clock stretches.)
Since it makes things better and lirc_zilog already does it anyway...
Acked-by: Andy Walls
> ---
> drivers/media/video/ir-kbd-i2c.c | 13 +
> drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |1 -
> 2 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/drivers/media/video/ir-kbd-i2c.c
> b/drivers/media/video/ir-kbd-i2c.c
> index d2b20ad..a221ad6 100644
> --- a/drivers/media/video/ir-kbd-i2c.c
> +++ b/drivers/media/video/ir-kbd-i2c.c
> @@ -128,6 +128,19 @@ static int get_key_haup(struct IR_i2c *ir, u32 *ir_key,
> u32 *ir_raw)
>
> static int get_key_haup_xvr(struct IR_i2c *ir, u32 *ir_key, u32 *ir_raw)
> {
> + int ret;
> + unsigned char buf[1] = { 0 };
> +
> + /*
> + * This is the same apparent "are you ready?" poll command observed
> + * watching Windows driver traffic and implemented in lirc_zilog. With
> + * this added, we get far saner remote behavior with z8 chips on usb
> + * connected devices, even with the default polling interval of 100ms.
> + */
> + ret = i2c_master_send(ir->c, buf, 1);
> + if (ret != 1)
> + return (ret < 0) ? ret : -EINVAL;
> +
> return get_key_haup_common (ir, ir_key, ir_raw, 6, 3);
> }
>
> diff --git a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> index ccc8849..451ecd4 100644
> --- a/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> +++ b/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
> @@ -597,7 +597,6 @@ static void pvr2_i2c_register_ir(struct pvr2_hdw *hdw)
> init_data->internal_get_key_func = IR_KBD_GET_KEY_HAUP_XVR;
> init_data->type = RC_TYPE_RC5;
> init_data->name = hdw->hdw_desc->description;
> - init_data->polling_interval = 260; /* ms From lirc_zilog */
> /* IR Receiver */
> info.addr = 0x71;
> info.platform_data = init_data;
--
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: v4l2-compliance utility
On Fri, 2011-01-21 at 23:37 +0100, Hans Verkuil wrote: > Hi all, > > As you may have seen I have been adding a lot of tests to the v4l2-compliance > utility in v4l-utils lately. It is now getting to the state that is becomes > quite useful even though there is no full coverage yet. > > Currently the following ioctls are being tested: Hans, This is a great thing to have. Thanks! > Also tested is whether you can open device nodes multiple times. > > These tests are pretty exhaustive and more strict than the spec itself. OK, so multiple open is not strictly required by the spec, IIRC. If you check the ivtv /dev/radio node, it does not allow multiple open, IIRC, so it should not get OK for that test. I also think during the subdev conversion, some of the less popular ivtv cards with GPIO controlled radio audio may have been broken (and still not fixed yet :( ), but working for the PVR-150, PVR-500, etc.. The DEBUG ioctl()s can be compiled out too. So for someone making decisions based on the output of this tool: 1. if something comes back as "Not supported", that still means the driver is API specification compliant, right? 2. could it be the case that this compliance tool will be sensitive to the driver/hardware combination and not the driver alone? Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 1/3] v4l2-ctrls: must be able to enable/disable controls
On Sat, 2011-01-22 at 12:05 +0100, Hans Verkuil wrote:
> Controls can be dependent on the chosen input/output. So it has to be possible
> to enable or disable groups of controls, preventing them from being seen in
> the application.
I'm not a human factors expert, but given some of the principles listed
here:
http://www.asktog.com/basics/firstPrinciples.html
I get the feeling that forcing controls to disappear and reappear will
not be good for every possible application UI design.
I'm sure that due to subdevices providing all sorts of interesting
controls, some method of disabling controls is needed so as not to show
duplicates, etc.
However, would it be better to provide a hint to the application and let
the application UI designer decide what gets shown; instead of the
kernel dictating what is shown?
Regards,
Andy
> We need to allow duplicate controls as well so that two control handlers
> that both have the same control will still work. The first enabled control
> will win. And duplicate controls are always sorted based on when they were
> added (so the sorted list and the hash are both stable lists/hashes).
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/media/video/v4l2-ctrls.c | 123
> +-
> include/media/v4l2-ctrls.h | 34 +++
> 2 files changed, 115 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/media/video/v4l2-ctrls.c
> b/drivers/media/video/v4l2-ctrls.c
> index ef66d2a..983e287 100644
> --- a/drivers/media/video/v4l2-ctrls.c
> +++ b/drivers/media/video/v4l2-ctrls.c
> @@ -820,7 +820,7 @@ static struct v4l2_ctrl_ref *find_private_ref(
> VIDIOC_G/S_CTRL. */
> if (V4L2_CTRL_ID2CLASS(ref->ctrl->id) == V4L2_CTRL_CLASS_USER &&
> V4L2_CTRL_DRIVER_PRIV(ref->ctrl->id)) {
> - if (!type_is_int(ref->ctrl))
> + if (!ref->ctrl->is_enabled || !type_is_int(ref->ctrl))
> continue;
> if (id == 0)
> return ref;
> @@ -849,7 +849,7 @@ static struct v4l2_ctrl_ref *find_ref(struct
> v4l2_ctrl_handler *hdl, u32 id)
>
> /* Not in cache, search the hash */
> ref = hdl->buckets ? hdl->buckets[bucket] : NULL;
> - while (ref && ref->ctrl->id != id)
> + while (ref && ref->ctrl->id != id && ref->ctrl->is_enabled)
> ref = ref->next;
>
> if (ref)
> @@ -926,23 +926,28 @@ static int handler_new_ref(struct v4l2_ctrl_handler
> *hdl,
>
> /* Find insert position in sorted list */
> list_for_each_entry(ref, &hdl->ctrl_refs, node) {
> - if (ref->ctrl->id < id)
> - continue;
> - /* Don't add duplicates */
> - if (ref->ctrl->id == id) {
> - kfree(new_ref);
> - goto unlock;
> + /* If there are multiple elements with the same ID, then
> +add the new element at the end. */
> + if (ref->ctrl->id > id) {
> + list_add(&new_ref->node, ref->node.prev);
> + break;
> }
> - list_add(&new_ref->node, ref->node.prev);
> - break;
> }
>
> insert_in_hash:
> - /* Insert the control node in the hash */
> - new_ref->next = hdl->buckets[bucket];
> - hdl->buckets[bucket] = new_ref;
> + /* Append the control ref to the hash */
> + if (hdl->buckets[bucket] == NULL) {
> + hdl->buckets[bucket] = new_ref;
> + } else {
> + for (ref = hdl->buckets[bucket]; ref->next; ref = ref->next)
> + ; /* empty */
> + ref->next = new_ref;
> + }
> + /* Note regarding the hdl->cached control ref: since new control refs
> +are always appended after any existing controls they will never
> +invalidate the cached control ref. So there is no need to set the
> +hdl->cached pointer to NULL. */
>
> -unlock:
> mutex_unlock(&hdl->lock);
> return 0;
> }
> @@ -960,8 +965,22 @@ static struct v4l2_ctrl *v4l2_ctrl_new(struct
> v4l2_ctrl_handler *hdl,
> if (hdl->error)
> return NULL;
>
> - /* Sanity checks */
> + /* Sanity checks:
> +- id must never be 0 (reserved value as it is the starting point
> + if apps want to iterate over all controls using
> + V4L2_CTRL_FLAG_NEXT_CTRL).
> +- name must be set.
> +- V4L2_CID_PRIVATE_BASE IDs are no longer allowed: these IDs make
> + it impossible to set the control using explicit control IDs.
> +- def must be in range and max must be >= min.
> +- V4L2_CTRL_FLAG_DISABLED must not be used by drivers any more.
> + There are better ways of doing this.
> +- Integer types must have a non-zero step.
> +- Menu types must have a menu.
> +- String types must have a non-zero max string l
Re: [PATCH 12/13] [media] rc/keymaps: Rename Hauppauge table as rc-hauppauge
On Mon, 2011-01-24 at 13:18 -0200, Mauro Carvalho Chehab wrote:
> There are two "hauppauge-new" keymaps, one with protocol
> unknown, and the other with the protocol marked accordingly.
> However, both tables are miss-named.
>
> Also, the old rc-hauppauge-new is broken, as it mixes
> three different controllers as if they were just one.
>
> This patch solves half of the problem by renaming the
> correct keycode table as just rc-hauppauge. This table
> contains the codes for the four different types of
> remote controllers found on Hauppauge cards, properly
> mapped with their different addresses.
Are you sure about doing this?
The problem is that the old black Hauppauge remote is using the same
RC-5 address as a common RC-5 TV remote: address 0x00.
See the table at the bottom of:
http://www.sbprojects.com/knowledge/ir/rc5.htm
IMO, RC-5 address 0x00 is not an address that every Hauppauge card
should be responding to by default.
I'm not too concerned with addresses 0x1d, 0x1e, and 0x1f colliding with
other consumer electronics remotes.
Regards,
Andy
> Signed-off-by: Mauro Carvalho Chehab
>
> create mode 100644 drivers/media/rc/keymaps/rc-hauppauge.c
> delete mode 100644 drivers/media/rc/keymaps/rc-rc5-hauppauge-new.c
>
> diff --git a/drivers/media/dvb/siano/sms-cards.c
> b/drivers/media/dvb/siano/sms-cards.c
> index 25b43e5..af121db 100644
> --- a/drivers/media/dvb/siano/sms-cards.c
> +++ b/drivers/media/dvb/siano/sms-cards.c
> @@ -64,7 +64,7 @@ static struct sms_board sms_boards[] = {
> .type = SMS_NOVA_B0,
> .fw[DEVICE_MODE_ISDBT_BDA] = "sms1xxx-hcw-55xxx-isdbt-02.fw",
> .fw[DEVICE_MODE_DVBT_BDA] = "sms1xxx-hcw-55xxx-dvbt-02.fw",
> - .rc_codes = RC_MAP_RC5_HAUPPAUGE_NEW,
> + .rc_codes = RC_MAP_HAUPPAUGE,
> .board_cfg.leds_power = 26,
> .board_cfg.led0 = 27,
> .board_cfg.led1 = 28,
> diff --git a/drivers/media/rc/keymaps/Makefile
> b/drivers/media/rc/keymaps/Makefile
> index f0c8055..c79e192 100644
> --- a/drivers/media/rc/keymaps/Makefile
> +++ b/drivers/media/rc/keymaps/Makefile
> @@ -68,7 +68,7 @@ obj-$(CONFIG_RC_MAP) += rc-adstech-dvb-t-pci.o \
> rc-proteus-2309.o \
> rc-purpletv.o \
> rc-pv951.o \
> - rc-rc5-hauppauge-new.o \
> + rc-hauppauge.o \
> rc-rc5-tv.o \
> rc-rc6-mce.o \
> rc-real-audio-220-32-keys.o \
> diff --git a/drivers/media/rc/keymaps/rc-hauppauge.c
> b/drivers/media/rc/keymaps/rc-hauppauge.c
> new file mode 100644
> index 000..66e0498
> --- /dev/null
> +++ b/drivers/media/rc/keymaps/rc-hauppauge.c
> @@ -0,0 +1,241 @@
> +/* rc-hauppauge.h - Keytable for Hauppauge Remote Controllers
> + *
> + * keymap imported from ir-keymaps.c
> + *
> + * This map currently contains the code for four different RCs:
> + * - New Hauppauge Gray;
> + * - Old Hauppauge Gray (with a golden screen for media keys);
> + * - Hauppauge Black;
> + * - DSR-0112 remote bundled with Haupauge MiniStick.
> + *
> + * Copyright (c) 2010-2011 by Mauro Carvalho Chehab
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include
> +
> +/*
> + * Hauppauge:the newer, gray remotes (seems there are multiple
> + * slightly different versions), shipped with cx88+ivtv cards.
> + *
> + * This table contains the complete RC5 code, instead of just the data part
> + */
> +
> +static struct rc_map_table rc5_hauppauge_new[] = {
> + /*
> + * Remote Controller Hauppauge Gray found on modern devices
> + * Keycodes start with address = 0x1e
> + */
> +
> + { 0x1e3b, KEY_SELECT }, /* GO / house symbol */
> + { 0x1e3d, KEY_POWER2 }, /* system power (green button) */
> +
> + { 0x1e1c, KEY_TV },
> + { 0x1e18, KEY_VIDEO }, /* Videos */
> + { 0x1e19, KEY_AUDIO }, /* Music */
> + { 0x1e1a, KEY_CAMERA }, /* Pictures */
> +
> + { 0x1e1b, KEY_EPG },/* Guide */
> + { 0x1e0c, KEY_RADIO },
> +
> + { 0x1e14, KEY_UP },
> + { 0x1e15, KEY_DOWN },
> + { 0x1e16, KEY_LEFT },
> + { 0x1e17, KEY_RIGHT },
> + { 0x1e25, KEY_OK }, /* OK */
> +
> + { 0x1e1f, KEY_EXIT }, /* back/exit */
> + { 0x1e0d, KEY_MENU },
> +
> + { 0x1e10, KEY_VOLUMEUP },
> + { 0x1e11, KEY_VOLUMEDOWN },
> +
> + { 0x1e12, KEY_PREVIOUS }, /* previous channel */
> + { 0x1e0f, KEY_MUTE },
> +
> + { 0x1e20, KEY_CHANNELUP }, /* channel / program + */
> + { 0x1e21, KEY_CHANNELDOWN },/* channel / program - */
> +
> + { 0x1e37, KEY_RECORD }, /* recording */
> +
Re: [PATCH 13/13] [media] remove the old RC_MAP_HAUPPAUGE_NEW RC map
On Mon, 2011-01-24 at 13:18 -0200, Mauro Carvalho Chehab wrote:
> The rc-hauppauge-new map is a messy thing, as it bundles 3
> different remote controllers as if they were just one,
> discarding the address byte. Also, some key maps are wrong.
>
> With the conversion to the new rc-core, it is likely that
> most of the devices won't be working properly, as the i2c
> driver and the raw decoders are now providing 16 bits for
> the remote, instead of just 8.
>
> Signed-off-by: Mauro Carvalho Chehab
All the patch emails didn't/haven't come through to me.
Did you miss cx23885-input.c, or is that using a map that isn't affected
by these changes?
Also one comment below:
> delete mode 100644 drivers/media/rc/keymaps/rc-hauppauge-new.c
[...]
> diff --git a/drivers/media/video/ir-kbd-i2c.c
> b/drivers/media/video/ir-kbd-i2c.c
> index d2b20ad..b18373a 100644
> --- a/drivers/media/video/ir-kbd-i2c.c
> +++ b/drivers/media/video/ir-kbd-i2c.c
> @@ -300,7 +300,7 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> ir->get_key = get_key_haup;
> rc_type = RC_TYPE_RC5;
> if (hauppauge == 1) {
> - ir_codes= RC_MAP_HAUPPAUGE_NEW;
> + ir_codes= RC_MAP_HAUPPAUGE;
> } else {
> ir_codes= RC_MAP_RC5_TV;
> }
> @@ -327,7 +327,7 @@ static int ir_probe(struct i2c_client *client, const
> struct i2c_device_id *id)
> name= "Hauppauge/Zilog Z8";
> ir->get_key = get_key_haup_xvr;
> rc_type = RC_TYPE_RC5;
> - ir_codes= hauppauge ? RC_MAP_HAUPPAUGE_NEW : RC_MAP_RC5_TV;
> + ir_codes= hauppauge ? RC_MAP_HAUPPAUGE : RC_MAP_RC5_TV;
> break;
> }
The "hauppauge" module parameter was to make ir-kbd-i2c to default to a
keymap for the old black remote.
If you have combined the black remote's keymap with the grey remote's
keymap, why keep the "hauppauge" module parameter?
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] video/saa7164: Fix sparse warning: Using plain integer as NULL pointer
On Tue, 2011-01-25 at 18:05 -0500, Devin Heitmueller wrote:
> On Tue, Jan 25, 2011 at 5:54 PM, Peter Hüwe wrote:
> > Hi Julia,
> >
> > thanks for your input.
> > So do I understand you correctly if I say
> > if(!x) is better than if(x==NULL) in any case?
The machine code should be equivalent in size and speed.
> > Or only for the kmalloc family?
> >
> > Do you remember the reason why !x should be preferred?
> >
> > In Documentation/CodingStyle , Chapter 7: Centralized exiting of functions
> > there is a function fun with looks like this:
> > int fun(int a)
> > {
> >int result = 0;
> >char *buffer = kmalloc(SIZE);
> >
> >if (buffer == NULL)
> >return -ENOMEM;
> >
> > --> So if (buffer == NULL) is in the official CodingStyle - maybe we
> > should
> > add a paragraph there as well ;)
CodingStyle shouldn't specify anything on the matter. There is no
overall, optimal choice for all contexts. Arguing either way is as
pointless as the Lilliputians' little-end vs. big-end dispute.
> To my knowledge, the current CodingStyle doesn't enforce a particular
> standard in this regard, leaving it at the discretion of the author.
Correct, it does not. I just checked CodingStyle and checkpatch
yesterday.
> Whether to do (!foo) or (foo == NULL) is one of those debates people
> have similar to whether to use tabs as whitespace. People have
> differing opinions and there is no clearly "right" answer.
It depends on one's measurement criteria for "optimizing" the written
form of source code.
I prefer more explicit statement of action is taking place over
statements with fewer characters. It usually saves me time when
revisiting code.
More genrally I prefer any coding practice that saves me time when
revisiting code. (Note the word "me" carries a lot of context with it.)
Ambiguity and implicit behaviors ultimately waste my time.
> Personally
> I strongly prefer (foo == NULL) as it makes it blindingly obvious that
> it's a pointer comparison, whereas (!foo) leaves you wondering whether
> it's an integer or pointer comparison.
Me too.
> All that said, you shouldn't submit patches which arbitrarily change
> from one format to the other. With regards to the proposed patch, you
> should follow whatever style the author employed in the rest of the
> file.
That is another reasonable critereon in "optimizing" the written form of
the source code. I tend to give it less weight though.
Regards,
Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] More IR fixes for 2.6.38
Mauro, I plan to make extensive lirc_zilog changes starting tonight, so the sooner Jarrod's lirc_zilog.c fix is in a media_tree branch, the less rebase I'll have to do. :) Thanks. Andy Jarod Wilson wrote: >Mauro, > >Please pull these additional IR driver fixes against Linus' tree in for >2.6.38 merge. Without these, mceusb is still broken (keybounce issues), >the HD-PVR tx won't work, and ir-kbd-i2c behaves badly with both the >HD-PVR and the HVR-1950. > >Thanks much! > >The following changes since commit 6fb1b304255efc5c4c93874ac8c066272e257e28: > > Merge branch 'for-linus' of > git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input (2011-01-26 16:31:44 > +1000) > >are available in the git repository at: > > git://linuxtv.org/jarod/linux-2.6-ir.git for-2.6.38 > >Jarod Wilson (7): > rc/mce: add mappings for missing keys > hdpvr: fix up i2c device registration > lirc_zilog: z8 on usb doesn't like back-to-back i2c_master_send > ir-kbd-i2c: improve remote behavior with z8 behind usb > rc/ir-lirc-codec: add back debug spew > rc: use time unit conversion macros correctly > mceusb: really fix remaining keybounce issues > > drivers/media/rc/ir-lirc-codec.c |6 +++- > drivers/media/rc/keymaps/rc-rc6-mce.c |6 > drivers/media/rc/mceusb.c |9 -- > drivers/media/rc/nuvoton-cir.c |6 ++-- > drivers/media/rc/streamzap.c | 12 > drivers/media/video/hdpvr/hdpvr-core.c | 24 +++--- > drivers/media/video/hdpvr/hdpvr-i2c.c | 30 ++ > drivers/media/video/hdpvr/hdpvr.h |3 +- > drivers/media/video/ir-kbd-i2c.c | 13 + > drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |1 - > drivers/staging/lirc/lirc_zilog.c | 32 +++ > 11 files changed, 106 insertions(+), 36 deletions(-) > >-- >Jarod Wilson >ja...@redhat.com > >-- >To unsubscribe from this list: send the line "unsubscribe linux-media" in >the body of a message to majord...@vger.kernel.org >More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PULL] More IR fixes for 2.6.38
On Wed, 2011-01-26 at 15:44 -0200, Mauro Carvalho Chehab wrote: > Andy, > > Then, it is better to use Jarod's tree for it. His patches are against > upstream, and are meant to be applied to .38. So, I need first to send > them to linux-next, then to upstream and then merge from upstream, > otherwise, I'll have to manually fix the conflicts on the next merge window. > Due to LCA, I'm not sure if Linus will apply much patches during this > week. So, I'll probably wait until next week to send Jarod's patches > upstream. > Jarod Wilson wrote: > >> git://linuxtv.org/jarod/linux-2.6-ir.git for-2.6.38 OK. I'll work off of Jarod's branch then. Thanks. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT PATCHES FOR 2.6.39] fix cx18 regression
On Mon, 2011-01-31 at 12:12 -0200, Mauro Carvalho Chehab wrote: > Em 26-01-2011 05:23, Hans Verkuil escreveu: > > Mauro, please get this upstream asap since this fix needs to go into 2.6.38 > > as well. > > > > Regards, > > > > Hans > > > > The following changes since commit e5fb95675639f064ca40df7ad319f1c380443999: > > Hans Verkuil (1): > > [media] vivi: fix compiler warning > > > > are available in the git repository at: > > > > ssh://linuxtv.org/git/hverkuil/media_tree.git cx18-fix > > > > Hans Verkuil (1): > > cx18: fix kernel oops when setting MPEG control before capturing. > > > > drivers/media/video/cx18/cx18-driver.c |1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > I tried to apply it against 2.6.38-rc2, but it failed: > > mutex_init(&cx->serialize_lock); > mutex_init(&cx->gpio_lock); > mutex_init(&cx->epu2apu_mb_lock); > mutex_init(&cx->epu2cpu_mb_lock); > > ret = cx18_create_in_workq(cx); > <<< > === > cx->cxhdl.capabilities = CX2341X_CAP_HAS_TS | > CX2341X_CAP_HAS_SLICED_VBI; > cx->cxhdl.ops = &cx18_cxhdl_ops; > cx->cxhdl.func = cx18_api_func; > cx->cxhdl.priv = &cx->streams[CX18_ENC_STREAM_TYPE_MPG]; > ret = cx2341x_handler_init(&cx->cxhdl, 50); > >>> > if (ret) > return ret; > > Perhaps this change requires some patch delayed for .39? The bug was authored on 31 Dec 2010, but not comitted until 23 Jan 2011: http://git.linuxtv.org/hverkuil/media_tree.git?a=commit;h=82f205b2f2a1deb1ab700a601ef48a4db4ca4f4e Kernel 2.6.38-rc2 appears to have a date one day prior: 22 Jan 2011: http://git.linuxtv.org/hverkuil/media_tree.git?a=commit;h=1bae4ce27c9c90344f23c65ea6966c50ffeae2f5 So the bug will be in whatever version comes out after 2.6.38-rc2 Regards, Andy > 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: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Tue, 2011-02-01 at 13:49 -0200, Mauro Carvalho Chehab wrote:
> Hi Lawrence,
>
> Em 08-01-2011 16:45, Lawrence Rust escreveu:
> > Thanks for the info on the PVR-150. It largely confirmed what I had
> > surmised - that the two cards disagree about serial audio data format.
> > Before my patch, the wm8775 was programmed for Philips mode but the
> > CX25843 on the PVR-150 is setup for Sony I2S mode!! On the Nova-S, the
> > cx23883 is setup (in cx88-tvaudio.c) for Philips mode. The patch
> > changed the wm8775 to Sony I2S mode because the existing setup gave
> > noise, indicative of a mismatch.
> >
> > It is my belief that either the wm8775 datasheet is wrong or there are
> > inverters on the SCLK lines between the wm8775 and cx25843/23883. It is
> > also plausible that Conexant have it wrong and both their datasheets are
> > wrong.
> >
> > Anyway, I have revised the patch (attached) so that the wm8775 is kept
> > in Philips mode (to please the PVR-150) and the cx23883 on the Nove-S is
> > now switched to Sony I2S mode (like the PVR-150) and this works fine.
> > The change is trivial, just 2 lines, so they're shouldn't be any other
> > consequences. However, could this affect any other cards?
> >
> > NB I have only tested this patch on my Nova-S, no other.
>
> As it was pointed, your patch affects other boards with wm8775. In order
> to avoid it, you need to use platform_data to pass nova_s specific parameters,
> and be sure that other boards won't be affected by your changes.
>
> As you might not be able to see how this should be written, I modified your
> patch in a way that, hopefully, it won't affect PVR-150. Please test.
>
> Please notice that I don't have any board with wm8775 handy, so it is
> compiled-only.
>
> If this patch doesn't break PVR-150 or Nova-S, then I think we can merge
> it.
>
> There are however two issues:
> 1) I don't think it is a good idea to keep the I2C group for wm8775
> inside
> the wm8775 header. Instead, we should move it to some place were people can
> look on it
> to avoid duplicated groups. We may instead just get rid of it, as I added
> tests for
> wm8775 on all places. So, only if wm8775 is used, the i2c subdev commands
> will be
> called.
> 2) I just added one platform_data info that indicates if the device is a
> nova_s or not. I did it just because I was lazy enough to not go through
> wm8775
> datasheet and add parameters for the parameters that are different. The better
> is to split it into some more parameters.
>
> If it works for you, please add your Signed-off-by:.
>
> Andy,
> please test if this don't break ivtv. If it breaks, please help us to fix,
> as only you noticed an issue on the previous versions.
I'll plan this for Sunday 6 Feb. (I have a wedding to attend on
Saturday).
Regards,
Andy
> -
>
> From: Lawrence Rust
>
> This patch adds audio DMA capture and ALSA mixer elements for the line
> input jack of the Hauppauge Nova-S-plus DVB-S PCI card. The Nova-S-plus
> has a WM8775 ADC that is currently not detected. This patch enables
> this chip and exports volume, balance mute and ALC elements for ALSA
> mixer controls.
>
> [mche...@redhat.com: Changed the patch to only talk with wm8775 if board info
> says so. Also, added platform_data support, to avoid changing the behaviour
> for other boards, and fixed CodingStyle]
>
> Signed-off-by: Mauro Carvalho Chehab
>
> diff --git a/drivers/media/video/cx88/cx88-alsa.c
> b/drivers/media/video/cx88/cx88-alsa.c
> index 54b7fcd..a2d688e 100644
> --- a/drivers/media/video/cx88/cx88-alsa.c
> +++ b/drivers/media/video/cx88/cx88-alsa.c
> @@ -40,6 +40,7 @@
> #include
> #include
> #include
> +#include
>
> #include "cx88.h"
> #include "cx88-reg.h"
> @@ -577,6 +578,35 @@ static int snd_cx88_volume_get(struct snd_kcontrol
> *kcontrol,
> return 0;
> }
>
> +static void snd_cx88_wm8775_volume_put(struct snd_kcontrol *kcontrol,
> +struct snd_ctl_elem_value *value)
> +{
> + snd_cx88_card_t *chip = snd_kcontrol_chip(kcontrol);
> + struct cx88_core *core = chip->core;
> + struct v4l2_control client_ctl;
> + int left = value->value.integer.value[0];
> + int right = value->value.integer.value[1];
> + int v, b;
> +
> + memset(&client_ctl, 0, sizeof(client_ctl));
> +
> + /* Pass volume & balance onto any WM8775 */
> + if (left >= right) {
> + v = left << 10;
> + b = left ? (0x8000 * right) / left : 0x8000;
> + } else {
> + v = right << 10;
> + b = right ? 0x - (0x8000 * left) / right : 0x8000;
> + }
> + client_ctl.value = v;
> + client_ctl.id = V4L2_CID_AUDIO_VOLUME;
> + call_hw(core, WM8775_GID, core, s_ctrl, &client_ctl);
> +
> + client_ctl.value = b;
> + client_ctl.id = V4L2_CID_AUDIO_BALANCE;
> + call_hw(core, WM8775_GID, core, s_ctrl, &client_ctl);
> +}
> +
> /* OK - TODO: test it */
> static int snd_cx88_vol
Re: [GIT PATCHES FOR 2.6.39] fix cx18 regression
Hans, What I was trying to say was that Mauro should have observed the patch fail to apply to 2.6.38-rc2. It appears the bug did not get commited until a day after 2.6.38-rc2 was tagged. R, Andy Hans Verkuil wrote: >On Thursday, February 03, 2011 00:50:12 Andy Walls wrote: >> On Mon, 2011-01-31 at 12:12 -0200, Mauro Carvalho Chehab wrote: >> > Em 26-01-2011 05:23, Hans Verkuil escreveu: >> > > Mauro, please get this upstream asap since this fix needs to go into >> > > 2.6.38 >> > > as well. >> > > >> > > Regards, >> > > >> > > Hans >> > > >> > > The following changes since commit >> > > e5fb95675639f064ca40df7ad319f1c380443999: >> > > Hans Verkuil (1): >> > > [media] vivi: fix compiler warning >> > > >> > > are available in the git repository at: >> > > >> > > ssh://linuxtv.org/git/hverkuil/media_tree.git cx18-fix >> > > >> > > Hans Verkuil (1): >> > > cx18: fix kernel oops when setting MPEG control before capturing. >> > > >> > > drivers/media/video/cx18/cx18-driver.c |1 + >> > > 1 files changed, 1 insertions(+), 0 deletions(-) >> > > >> > >> > I tried to apply it against 2.6.38-rc2, but it failed: >> > >> >mutex_init(&cx->serialize_lock); >> > mutex_init(&cx->gpio_lock); >> > mutex_init(&cx->epu2apu_mb_lock); >> >mutex_init(&cx->epu2cpu_mb_lock); >> > >> > ret = cx18_create_in_workq(cx); >> > <<<<<<< >> > === >> >cx->cxhdl.capabilities = CX2341X_CAP_HAS_TS | >> > CX2341X_CAP_HAS_SLICED_VBI; >> > cx->cxhdl.ops = &cx18_cxhdl_ops; >> > cx->cxhdl.func = cx18_api_func; >> > cx->cxhdl.priv = &cx->streams[CX18_ENC_STREAM_TYPE_MPG]; >> > ret = cx2341x_handler_init(&cx->cxhdl, 50); >> > >>>>>>> >> > if (ret) >> > return ret; >> > >> > Perhaps this change requires some patch delayed for .39? >> >> The bug was authored on 31 Dec 2010, but not comitted until 23 Jan 2011: >> >> http://git.linuxtv.org/hverkuil/media_tree.git?a=commit;h=82f205b2f2a1deb1ab700a601ef48a4db4ca4f4e >> >> Kernel 2.6.38-rc2 appears to have a date one day prior: 22 Jan 2011: >> >> http://git.linuxtv.org/hverkuil/media_tree.git?a=commit;h=1bae4ce27c9c90344f23c65ea6966c50ffeae2f5 >> >> So the bug will be in whatever version comes out after 2.6.38-rc2 > >I'll look at this tomorrow. It's been very busy for the past week and I haven't >had time to look into this. > >It definitely doesn't require any other patches, but probably some new patch >changed the order of some lines causing the patch to fail. > >Regards, > > Hans > >> >> Regards, >> Andy >> >> > Cheers, >> > Mauro >> >> >> > >-- >Hans Verkuil - video4linux developer - sponsored by Cisco
Re: cx25840: probe crashes for cx25837 chip on 2.6.37
On Sat, 2011-02-05 at 16:45 +0100, Sven Barth wrote: > Hello together! > > I was eager to test my patch for cx25840 that was included in 2.6.37, so > I've updated my system and plugged in my Grabster AV400. But this > resulted in a "kernel bug" printed to dmesg: > > dmesg begin > > usb 1-5: new high speed USB device using ehci_hcd and address 6 > Linux video capture interface: v2.00 > pvrusb2: Hardware description: Terratec Grabster AV400 > pvrusb2: ** > pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is > experimental. > pvrusb2: Important functionality might not be entirely working. > pvrusb2: Please consider contacting the driver author to help with > further stabilization of the driver. > pvrusb2: ** > usb 1-5: USB disconnect, address 6 > usbcore: registered new interface driver pvrusb2 > pvrusb2: 20110116 (from www.isely.net):Hauppauge WinTV-PVR-USB2 MPEG2 > Encoder/Tuner > pvrusb2: Debug mask is 31 (0x1f) > pvrusb2: Failed to submit write-control URB status=-19 > pvrusb2: Device being rendered inoperable > pvrusb2: ***WARNING*** pvrusb2 device hardware appears to be jammed and > I can't clear it. > pvrusb2: You might need to power cycle the pvrusb2 device in order to > recover. > usb 1-5: new high speed USB device using ehci_hcd and address 7 > pvrusb2: Hardware description: Terratec Grabster AV400 > pvrusb2: ** > pvrusb2: WARNING: Support for this device (Terratec Grabster AV400) is > experimental. > pvrusb2: Important functionality might not be entirely working. > pvrusb2: Please consider contacting the driver author to help with > further stabilization of the driver. > pvrusb2: ** > cx25840 6-0044: cx25837-3 found @ 0x88 (pvrusb2_a) > [ cut here ] > kernel BUG at drivers/media/video/v4l2-ctrls.c:1143! > invalid opcode: [#1] PREEMPT SMP > last sysfs file: > /sys/devices/pci:00/:00:02.2/usb1/1-5/i2c-6/6-0044/uevent > CPU 1 > Modules linked in: cx25840 pvrusb2 dvb_core cx2341x v4l2_common videodev > v4l1_compat v4l2_compat_ioctl32 tveeprom ipv6 xfs exportfs ext2 radeon > snd_emu10k1 snd_intel8x0 ohci_hcd snd_rawmidi snd_ac97_codec ttm > drm_kms_helper ac97_bus snd_seq_dummy skge ehci_hcd snd_seq_oss > snd_seq_midi_event snd_seq snd_util_mem snd_seq_device snd_pcm_oss > snd_hwdep snd_mixer_oss snd_pcm snd_timer emu10k1_gp drm i2c_algo_bit > shpchp snd i2c_nforce2 soundcore usbcore processor pci_hotplug i2c_core > parport_pc snd_page_alloc floppy serio_raw button psmouse ns558 > edac_core ppdev k8temp edac_mce_amd evdev sg analog lp gameport pcspkr > parport ext4 mbcache jbd2 crc16 sd_mod sr_mod cdrom sata_nv pata_acpi > sata_sil24 pata_amd libata scsi_mod raid1 md_mod > > Pid: 2184, comm: pvrusb2-context Not tainted 2.6.37-ARCH #1 nForce/ > RIP: 0010:[] [] > v4l2_ctrl_cluster+0x32/0x40 [videodev] > RSP: 0018:880033c61a30 EFLAGS: 00010246 > RAX: 0001 RBX: 880038065800 RCX: 0001 > RDX: RSI: 880039de1ee0 RDI: 0002 > RBP: 880033c61a30 R08: R09: > R10: R11: R12: 880039de1e78 > R13: 8373 R14: 880039de1e00 R15: 00ed > FS: 7f05b98a8700() GS:88003fd0() knlGS: > CS: 0010 DS: ES: CR0: 8005003b > CR2: 7fff6c8c5fe0 CR3: 3c89b000 CR4: 06e0 > DR0: DR1: DR2: > DR3: DR6: 0ff0 DR7: 0400 > Process pvrusb2-context (pid: 2184, threadinfo 880033c6, task > 88003f8ada30) > Stack: > 880033c61aa0 a0310b99 8800 88003c99e3fc > 880033c61ab0 0200 880039de1e08 > 880033c61ac0 880038065828 a0318590 a0318540 > Call Trace: > [] cx25840_probe+0x479/0x840 [cx25840] > [] i2c_device_probe+0x94/0xd0 [i2c_core] > [] ? driver_sysfs_add+0x7a/0xb0 > [] driver_probe_device+0x96/0x1c0 > [] ? __device_attach+0x0/0x60 > [] __device_attach+0x4b/0x60 > [] bus_for_each_drv+0x64/0x90 > [] device_attach+0x8f/0xb0 > [] bus_probe_device+0x25/0x40 > [] device_add+0x4e4/0x5c0 > [] ? pm_runtime_init+0xd1/0xe0 > [] device_register+0x19/0x20 > [] i2c_new_device+0x145/0x250 [i2c_core] > [] v4l2_i2c_new_subdev_board+0x96/0x240 [v4l2_common] > [] v4l2_i2c_new_subdev_cfg+0x83/0xb0 [v4l2_common] > [] ? pvr2_context_notify+0x0/0x10 [pvrusb2] > [] ? pvr2_context_notify+0x0/0x10 [pvrusb2] > [] pvr2_hdw_initialize+0x346/0x1060 [pvrusb2] > [] pvr2_context_thread_func+0x9b/0x320 [pvrusb2] > [] ? pvr2_context_thread_func+0x0/0x320 [pvrusb2] > [] ? autoremove_wake_function+0x0/0x40 > [] ? _raw_spin_unlock_irqrestore+0x32/0x40 > [] ? pvr2_context_thread_func+0x0/0x320 [pvrusb2] > [] kthread+0x96/0xa0 > [] kernel_thread_helper+0x4/0x10 > [] ? kthread+0x0/0xa0
Re: [PATCH] cx25840: fix probing of cx2583x chips
On Sat, 2011-02-05 at 22:53 +0100, Sven Barth wrote: > Fix the probing of cx2583x chips, because two controls were clustered > that are not created for these chips. > > This regression was introduced in 2.6.36. > > Signed-off-by: Sven Barth Acked-by: Andy Walls > diff -aur linux-2.6.37/drivers/media/video/cx25840/cx25840-core.c > linux-2.6.37-patched/drivers/media/video/cx25840/cx25840-core.c > --- linux-2.6.37/drivers/media/video/cx25840/cx25840-core.c 2011-01-05 > 00:50:19.0 + > +++ linux-2.6.37-patched/drivers/media/video/cx25840/cx25840-core.c > 2011-02-05 15:58:27.733325238 + > @@ -2031,7 +2031,8 @@ > kfree(state); > return err; > } > - v4l2_ctrl_cluster(2, &state->volume); > + if (!is_cx2583x(state)) > + v4l2_ctrl_cluster(2, &state->volume); > v4l2_ctrl_handler_setup(&state->hdl); > > cx25840_ir_probe(sd); -- 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: [REGRESSION: wm8775, ivtv] Please revert commit fcb9757333df37cf4a7feccef7ef6f5300643864
On Tue, 2011-02-01 at 13:49 -0200, Mauro Carvalho Chehab wrote: > Hi Lawrence, > > Em 08-01-2011 16:45, Lawrence Rust escreveu: > > Thanks for the info on the PVR-150. It largely confirmed what I had > > surmised - that the two cards disagree about serial audio data format. > > Before my patch, the wm8775 was programmed for Philips mode but the > > CX25843 on the PVR-150 is setup for Sony I2S mode!! On the Nova-S, the > > cx23883 is setup (in cx88-tvaudio.c) for Philips mode. The patch > > changed the wm8775 to Sony I2S mode because the existing setup gave > > noise, indicative of a mismatch. > > > > It is my belief that either the wm8775 datasheet is wrong or there are > > inverters on the SCLK lines between the wm8775 and cx25843/23883. It is > > also plausible that Conexant have it wrong and both their datasheets are > > wrong. > > > > Anyway, I have revised the patch (attached) so that the wm8775 is kept > > in Philips mode (to please the PVR-150) and the cx23883 on the Nove-S is > > now switched to Sony I2S mode (like the PVR-150) and this works fine. > > The change is trivial, just 2 lines, so they're shouldn't be any other > > consequences. However, could this affect any other cards? > > > > NB I have only tested this patch on my Nova-S, no other. > > As it was pointed, your patch affects other boards with wm8775. In order > to avoid it, you need to use platform_data to pass nova_s specific parameters, > and be sure that other boards won't be affected by your changes. > > As you might not be able to see how this should be written, I modified your > patch in a way that, hopefully, it won't affect PVR-150. Please test. > > Please notice that I don't have any board with wm8775 handy, so it is > compiled-only. > > If this patch doesn't break PVR-150 or Nova-S, then I think we can merge > it. > > There are however two issues: > 1) I don't think it is a good idea to keep the I2C group for wm8775 > inside > the wm8775 header. Instead, we should move it to some place were people can > look on it > to avoid duplicated groups. We may instead just get rid of it, as I added > tests for > wm8775 on all places. So, only if wm8775 is used, the i2c subdev commands > will be > called. > 2) I just added one platform_data info that indicates if the device is a > nova_s or not. I did it just because I was lazy enough to not go through > wm8775 > datasheet and add parameters for the parameters that are different. The better > is to split it into some more parameters. > > If it works for you, please add your Signed-off-by:. > > Andy, > please test if this don't break ivtv. If it breaks, please help us to fix, > as only you noticed an issue on the previous versions. Mauro and Lawrence, I have tested the patch with my PVR-150 (ivtv) and it does not break line in audio, and volume control works as well (mute doesn't work, but that might be an existing ivtv issue). I'm fairly sure the patch will also not break the PVR-USB2 (pvrusb2), but I don't have PVR-USB2 hardware to test. Since the use of the v4l2_subdev grp_id field is bridge driver private, I have made (only) these changes to the patch: drivers/media/video/cx88/cx88.h add WM8775_GID definition drivers/media/video/cx88/cx88-video.c add setting sd->grp_id drivers/media/video/wm8775.c remove setting sd->grp_id include/media/wm8775.h remove WM8775_GID defintion and comment add pvrusb2 to the platform data comment Regards, Andy -- From: Lawrence Rust This patch adds audio DMA capture and ALSA mixer elements for the line input jack of the Hauppauge Nova-S-plus DVB-S PCI card. The Nova-S-plus has a WM8775 ADC that is currently not detected. This patch enables this chip and exports volume, balance mute and ALC elements for ALSA mixer controls. [mche...@redhat.com: Changed the patch to only talk with wm8775 if board info says so. Also, added platform_data support, to avoid changing the behaviour for other boards, and fixed CodingStyle] [awa...@md.metrocast.net: Changed patch to make the WM8775_GID defintion bridge driver private and let the bridge driver set the value of v4l2_subdev.grp_id.] Signed-off-by: Mauro Carvalho Chehab Signed-off-by: Andy Walls diff --git a/drivers/media/video/cx88/cx88-alsa.c b/drivers/media/video/cx88/cx88-alsa.c index 54b7fcd..a2d688e 100644 --- a/drivers/media/video/cx88/cx88-alsa.c +++ b/drivers/media/video/cx88/cx88-alsa.c @@ -40,6 +40,7 @@ #include #include #include +#include #include "cx88.h" #include "cx88-reg.h" @@ -577,6 +578,35 @@ static int snd_cx88_volume_get(struct snd_kcontrol *kcontrol, return 0;
Re: Tuning channels with DViCO FusionHDTV7 Dual Express
On Sun, 2011-02-06 at 22:18 -0700, Dave Johansen wrote: > On Sun, Feb 6, 2011 at 9:10 PM, Daniel O'Connor wrote: > > > > On 07/02/2011, at 13:34, Dave Johansen wrote: > >>> However the drivers in Ubuntu at least work for 1 tuner, if I try and use > >>> both in mythtv one tends to lock up after a while :-/ > >> > >> I actually had the card working and tuning channels about 2 years ago > >> with Ubuntu 08.10 and 09.04. From what I recall 08.10 required updated > > > > Yes that's my recollection. > > > >> drivers but 09.04 didn't, so I'd imagine that it should at least be > >> possible for it to work and possibly just out of the box. But do you > >> think that has a high likelihood of success now? > > > > I would expect at least a single channel and the remote to work since your > > card seems very similar to mine.. > > > > However I don't see any timeouts using mine, at least for 1 channel. Have > > you looked in dmesg for related parameters? > > When I use MythTV's channel scan it gets to Channel 9 and says > "Locked" at the top of the screen and then hangs there after printing > "ATSC Channel 9 -- Timed out, no channels". > > Here's the output from the terminal: > > 2011-02-06 21:55:10.545 DiSEqCDevTree, Warning: No device tree for cardid 1 > 2011-02-06 21:55:10.547 New DB connection, total: 3 > 2011-02-06 21:55:10.547 Connected to database 'mythconverg' at host: localhost > 2011-02-06 21:55:10.550 New DB connection, total: 4 > 2011-02-06 21:55:10.550 Connected to database 'mythconverg' at host: localhost > 2011-02-06 21:55:10.553 DiSEqCDevTree, Warning: No device tree for cardid 2 > 2011-02-06 21:55:14.472 Skipping channel fetch, you need to scan for > channels first. > > Here's the output from dmesg: > > [ 1233.984618] xc5000: waiting for firmware upload > (dvb-fe-xc5000-1.6.114.fw)... > [ 1233.986994] xc5000: firmware read 12401 bytes. > [ 1233.986997] xc5000: firmware uploading... > [ 1235.540016] xc5000: firmware upload complete... > [ 1244.872037] BUG: unable to handle kernel paging request at 01010028 > [ 1244.872057] IP: [] videobuf_dma_unmap+0x43/0xb0 > [videobuf_dma_sg] > [ 1244.872074] PGD 0 > [ 1244.872087] Oops: [#1] SMP > [ 1244.872098] last sysfs file: > /sys/devices/pci:00/:00:10.0/:03:00.0/firmware/:03:00.0/loading > [ 1244.872143] CPU 1 > [ 1244.872146] Modules linked in: snd_hda_codec_nvhdmi > snd_hda_codec_realtek nfsd exportfs nfs lockd fscache nfs_acl > auth_rpcgss sunrpc nvidia(P) xc5000 s5h1411 s5h1409 ir_lirc_codec > lirc_dev ir_sony_decoder ir_jvc_decoder ir_rc6_decoder ir_rc5_decoder > snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi > snd_seq_midi_event snd_seq ir_nec_decoder cx23885 ir_core snd_timer > cx2341x snd_seq_device video v4l2_common output videodev v4l1_compat > v4l2_compat_ioctl32 videobuf_dma_sg videobuf_dvb snd edac_core psmouse > serio_raw dvb_core videobuf_core btcx_risc tveeprom edac_mce_amd > k8temp shpchp soundcore snd_page_alloc i2c_nforce2 lp parport > dm_raid45 usbhid hid xor forcedeth ahci libahci pata_amd > [ 1244.872478] > [ 1244.872498] Pid: 2119, comm: cx23885[0] dvb Tainted: P > 2.6.35-25-generic #44-Ubuntu K9N2GM-FIH(MS-7508)/MS-7508 > [ 1244.872544] RIP: 0010:[] [] > videobuf_dma_unmap+0x43/0xb0 [videobuf_dma_sg] > [ 1244.872593] RSP: 0018:88005c151dc0 EFLAGS: 00010246 > [ 1244.872619] RAX: 0101 RBX: 88005ac47ef8 RCX: > 0002 > [ 1244.872646] RDX: 0006 RSI: c90010918000 RDI: > 88005d7340a0 > [ 1244.872673] RBP: 88005c151dd0 R08: R09: > > [ 1244.872700] R10: R11: 0001 R12: > 88004e6cc028 > [ 1244.872727] R13: 88005ac47ef8 R14: 88004e6cc028 R15: > 88005c1816e0 > [ 1244.872755] FS: 7f0f8f1bf7c0() GS:880001e4() > knlGS: > [ 1244.872797] CS: 0010 DS: ES: CR0: 8005003b > [ 1244.872822] CR2: 01010028 CR3: 5da71000 CR4: > 06e0 > [ 1244.872849] DR0: DR1: DR2: > > [ 1244.872876] DR3: DR6: 0ff0 DR7: > 0400 > [ 1244.872904] Process cx23885[0] dvb (pid: 2119, threadinfo > 88005c15, task 88005c1816e0) > [ 1244.872950] Stack: > [ 1244.872968] 88005ac47ef8 88005ac47e00 88005c151e00 > a0b6a11a > [ 1244.872999] <0> 88005c151df0 88004e6cc028 88004e6cc028 > 88004e6cc128 > [ 1244.873045] <0> 88005c151e10 a0b6bd4e 88005c151e40 > a011e457 > [ 1244.873106] Call Trace: > [ 1244.873138] [] cx23885_free_buffer+0x5a/0xa0 [cx23885] > [ 1244.873170] [] dvb_buf_release+0xe/0x10 [cx23885] > [ 1244.873200] [] videobuf_queue_cancel+0xf7/0x120 > [videobuf_core] > [ 1244.873244] [] __videobuf_read_stop+0x17/0x70 > [videobuf_core] > [ 1244.873289] [] videobuf_read_stop+0x1e/0x30 > [videobuf_core] > [ 1244.873331] [] videobuf_dvb_threa
Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: > > Just two quick notes. I'll try to do a full review this weekend. > > > > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: > >> == > >> Introduction > >> == > >> > >> The purpose of this RFC is to discuss the driver for a TV output interface > >> available in upcoming Samsung SoC. The HW is able to generate digital and > >> analog signals. Current version of the driver supports only digital output. > >> > >> Internally the driver uses videobuf2 framework, and CMA memory allocator. > > Not > >> all of them are merged by now, but I decided to post the sources to start > >> discussion driver's design. > > > > Cisco (i.e. a few colleagues and myself) are working on this. We hope to > > post > > an RFC by the end of this month. We also have a proposal for CEC support in > > the pipeline. > > Any reason to not use the drm kms APIs for modesetting, display > configuration, and hotplug support? We already have the > infrastructure in place for complex display configurations and > generating events for hotplug interrupts. It would seem to make more > sense to me to fix any deficiencies in the KMS APIs than to spin a new > API. Things like CEC would be a natural fit since a lot of desktop > GPUs support hdmi audio/3d/etc. and are already using kms. > > Alex I'll toss one out: lack of API documentation for driver or application developers to use. When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to possibly get rid of reliance on the ivtv X video driver http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation was really sparse. DRM had the most documentation under Documentation/DocBook/drm.tmpl, but the userland API wasn't fleshed out. GEM was talked about a bit in there as well, IIRC. TTM documentation was essentially non-existant. I can't find any KMS documentation either. I recall having to read much of the drm code, and having to look at the radeon driver, just to tease out what the DRM ioctls needed to do. Am I missing a Documentation source for the APIs? For V4L2 and DVB on ther other hand, one can point to pretty verbose documentation that application developers can use: http://linuxtv.org/downloads/v4l-dvb-apis/ Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH/RFC 0/5] HDMI driver for Samsung S5PV310 platform
On Wed, 2011-02-09 at 02:12 -0500, Alex Deucher wrote: > On Tue, Feb 8, 2011 at 5:47 PM, Andy Walls wrote: > > On Tue, 2011-02-08 at 10:28 -0500, Alex Deucher wrote: > >> On Tue, Feb 8, 2011 at 4:47 AM, Hans Verkuil wrote: > >> > Just two quick notes. I'll try to do a full review this weekend. > >> > > >> > On Tuesday, February 08, 2011 10:30:22 Tomasz Stanislawski wrote: > >> >> == > >> >> Introduction > >> >> == > >> >> > >> >> The purpose of this RFC is to discuss the driver for a TV output > >> >> interface > >> >> available in upcoming Samsung SoC. The HW is able to generate digital > >> >> and > >> >> analog signals. Current version of the driver supports only digital > >> >> output. > >> >> > >> >> Internally the driver uses videobuf2 framework, and CMA memory > >> >> allocator. > >> > Not > >> >> all of them are merged by now, but I decided to post the sources to > >> >> start > >> >> discussion driver's design. > > > >> > > >> > Cisco (i.e. a few colleagues and myself) are working on this. We hope to > >> > post > >> > an RFC by the end of this month. We also have a proposal for CEC support > >> > in > >> > the pipeline. > >> > >> Any reason to not use the drm kms APIs for modesetting, display > >> configuration, and hotplug support? We already have the > >> infrastructure in place for complex display configurations and > >> generating events for hotplug interrupts. It would seem to make more > >> sense to me to fix any deficiencies in the KMS APIs than to spin a new > >> API. Things like CEC would be a natural fit since a lot of desktop > >> GPUs support hdmi audio/3d/etc. and are already using kms. > >> > >> Alex > > > > I'll toss one out: lack of API documentation for driver or application > > developers to use. > > > > > > When I last looked at converting ivtvfb to use DRM, KMS, TTM, etc. (to > > possibly get rid of reliance on the ivtv X video driver > > http://dl.ivtvdriver.org/xf86-video-ivtv/ ), I found the documentation > > was really sparse. > > > > DRM had the most documentation under Documentation/DocBook/drm.tmpl, but > > the userland API wasn't fleshed out. GEM was talked about a bit in > > there as well, IIRC. > > > > TTM documentation was essentially non-existant. > > > > I can't find any KMS documentation either. > > > > I recall having to read much of the drm code, and having to look at the > > radeon driver, just to tease out what the DRM ioctls needed to do. > > > > Am I missing a Documentation source for the APIs? > > > > Documentation is somewhat sparse compared to some other APIs. Mostly > inline kerneldoc comments in the core functions. It would be nice to > improve things. The modesetting API is very similar to the xrandr > API in the xserver. > > At the moment a device specific surface manager (Xorg ddx, or some > other userspace lib) is required to use kms due to device specific > requirements with respect to memory management and alignment for > acceleration. The kms modesetting ioctls are common across all kms > drm drivers, but the memory management ioctls are device specific. > GEM itself is an Intel-specific memory manager, although radeon uses > similar ioctls. TTM is used internally by radeon, nouveau, and svga > for managing memory gpu accessible memory pools. Drivers are free to > use whatever memory manager they want; an existing one shared with a > v4l or platform driver, TTM, or something new. > There is no generic > userspace kms driver/lib although Dave and others have done some work > to support that, but it's really hard to make a generic interface > flexible enough to handle all the strange acceleration requirements of > GPUs. All of the above unfortunately says to me that the KMS API has a fairly tightly coupled set of userspace components, because userspace applications need have details about the specific underlying hardware embeeded in the application to effectively use the API. If so, that's not really conducive to getting application developers to write applications to the API, since applications will get tied to specific sets of hardware. Lack of documentation on the API for userpace application writers to use exacerbates that issue, as there are no clearly stated guarantees on device no
Re: Tuning channels with DViCO FusionHDTV7 Dual Express
On Tue, 2011-02-08 at 22:41 -0700, Dave Johansen wrote: > On Tue, Feb 8, 2011 at 9:51 AM, Dave Johansen wrote: > > On Tue, Feb 8, 2011 at 8:25 AM, Mark Zimmerman wrote: > >> On Mon, Feb 07, 2011 at 06:54:30PM -0500, Andy Walls wrote: > >>> > >>> You perhaps could > >>> > >>> A. provide the smallest window of known good vs known bad kernel > >>> versions. Maybe someone with time and hardware can 'git bisect' the > >>> issue down to the problem commit. (I'm guessing this problem might be > >>> specific to a particular 64 bit platform IOMMU type, given the bad > >>> dma_ops pointer.) > >>> > >> > >> FYI: I am on the process of doing a git bisect (10 kernels to go) to > >> track down this problem: > >> > >> http://www.mail-archive.com/linux-media@vger.kernel.org/msg25342.html > >> > >> Which may or may not be related to the problem in this thread. > >> > > > > I'm using Mythbuntu 10.10 x64, which I believe uses 2.6.35 but I will > > check tonight, so if the issue you're tracking down really is related > > to 2.6.36, then I imagine that my problem wouldn't be caused by what > > you're looking into. Plus, every time I've looked at dmesg the > > firmware has loaded properly, so I'm guessing I'm on 2.6.35 and being > > affected by a different issue. > > > > Thanks for the heads up, > > Dave > > > > So I don't know how useful this is, but I tried Mythbuntu 10.10 x86 > and it works like a charm. So the issue appears to be isolated to the > x64 build. You validated my guess. :) > If there's anything I can do to help figure out what the > cause of this issue is in the x64 build, then please let me know and > I'll do my best to help out. So this increases the likelyhood that this is a kernel problem introduced outside of the drivers/media directory. To find it, someone needs to clone out the kernel with git; start a git bisect using the lastest known good and earliest known bad kernel versions; and build, install, and test kernels until the problem is found, as outlined here: http://www.reactivated.net/weblog/archives/2006/01/using-git-bisect-to-find-buggy-kernel-patches/ http://manpages.ubuntu.com/manpages/maverick/man1/git-bisect.1.html The "build, install and test kernels" step is the pain. Let's say it takes a 2 core AMD64 machine about 17 minutes to build a minimal kernel. The number of kernels that need to be tested will be roughly log2(Number of commits between known good and bad kernels). So 30,000 commits will require roughly 15 kernel builds to narrow the problem. If it takes 20 minutes per iteration, that's 5 hours to find the problem. That someone also needs 64 bit hardware and a board supported by the cx23885 driver that also exhibits the problem. I have an HVR-1850 and a 64-bit machine, but I haven't tested it yet. I do not have 5 hours free. Sorry. Regards, Andy > Thanks for all the help, > Dave -- 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
[GIT PATCHES for 2.6.39] ivtv fixes
Mauro, Please pull the following ivtv patches for 2.6.39. Thanks go to David Alan Gilbert for reporting a problem I failed to clean up properly the first time, and Paul Cassella for providing fixes for long-standing problems in error handling. Regards, Andy The following changes since commit ffd14aab03dbb8bb1bac5284603835f94d833bd6: [media] au0828: fix VBI handling when in V4L2 streaming mode (2011-02-02 12:06:14 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git ivtv_39 Andy Walls (1): ivtv: Fix sparse warning regarding a user pointer in ivtv_write_vbi_from_user() Paul Cassella (3): Documentation: README.ivtv: Remove note that ivtvfb is not yet in the kernel ivtv: udma: handle get_user_pages() returning fewer pages than we asked for ivtv: yuv: handle get_user_pages() -errno returns Documentation/video4linux/README.ivtv |3 +- drivers/media/video/ivtv/ivtv-udma.c |7 - drivers/media/video/ivtv/ivtv-vbi.c |2 +- drivers/media/video/ivtv/ivtv-yuv.c | 52 +--- 4 files changed, 48 insertions(+), 16 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > Greetings: > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > fails to load due to an i2c failure. A search of the archives indicates > > that this is not the first time this issue has occurred. > > > > What can I do to help get this problem fixed? > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete... > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: firmware upload complete.. > > > > and here is what happens with 2.6.36: > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > xc5000: Unable to initialise tuner > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > xc5000: firmware read 12401 bytes. > > xc5000: firmware uploading... > > xc5000: I2C write failed (len=3) > > xc5000: firmware upload complete... > > > > I did a git bisect on this and finally reached the end of the line. > Here is what it said: > > qpc$ git bisect bad > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > Author: Jarod Wilson > Date: Thu Jul 29 18:20:44 2010 -0300 > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > Fix when CONFIG_MODULES is not enabled: > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration of > function 'module_refcount' > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of > function 'module_refcount' > drivers/built-in.o: In function `it87_probe': > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > drivers/built-in.o: In function `lirc_it87_exit': > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > Its a quick hack and untested beyond building, since I don't have the > hardware, but it should do the trick. > > Acked-by: Randy Dunlap > Signed-off-by: Jarod Wilson > Signed-off-by: Mauro Carvalho Chehab > > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 > 49e50945ccf8e1c8567c049908890d2752443b72 M drivers Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the commit is completely unrealted. Please try and see if things are good or bad at commit 18a87becf85d50e7f3d547f1b7a75108b151374d: commit 18a87becf85d50e7f3d547f1b7a75108b151374d Author: Jean Delvare Date: Sun Jul 18 17:05:17 2010 -0300 V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for < 0 return v Function i2c_wait_done() never returns negative values, so there is no point in checking for them. Signed-off-by: Jean Delvare Signed-off-by: Andy Walls Signed-off-by: Mauro Carvalho Chehab Which is the first commit, prior to the one you found, that seems to me to have any direct bearing to I2C transactions. If that commit is good, then these commits in between would be my next likely suspects: e5514f104d875b3d28cbcd5d4f2b96ab2fca1e29 dbe83a3b921328e12b2abe894fc692afba293d7f 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 -- 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: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > Greetings: > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 but > > > > which fails to initialize with the latest 2.6.36 kernel. The firmware > > > > fails to load due to an i2c failure. A search of the archives indicates > > > > that this is not the first time this issue has occurred. > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: firmware upload complete... > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: firmware upload complete.. > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: I2C write failed (len=3) > > > > xc5000: firmware upload complete... > > > > xc5000: Unable to initialise tuner > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > xc5000: firmware read 12401 bytes. > > > > xc5000: firmware uploading... > > > > xc5000: I2C write failed (len=3) > > > > xc5000: firmware upload complete... > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > Here is what it said: > > > > > > qpc$ git bisect bad > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > Author: Jarod Wilson > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit declaration > > > of function 'module_refcount' > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration of > > > function 'module_refcount' > > > drivers/built-in.o: In function `it87_probe': > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > drivers/built-in.o: In function `lirc_it87_exit': > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to `drop_chrdev' > > > > > > Its a quick hack and untested beyond building, since I don't have the > > > hardware, but it should do the trick. > > > > > > Acked-by: Randy Dunlap > > > Signed-off-by: Jarod Wilson > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 > > > 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > Hmm. git log --patch 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 shows the > > commit is completely unrealted. > > > > Please try and see if things are good or bad at commit > > 18a87becf85d50e7f3d547f1b7a75108b151374d: > > > > commit 18a87becf85d50e7f3d547f1b7a75108b151374d > > Author: Jean Delvare > > Date: Sun Jul 18 17:05:17 2010 -0300 > > > > V4L/DVB: cx23885: i2c_wait_done returns 0 or 1, don't check for > > < 0 return v > > > > Function i2c_wait_done() never returns negative values, so > > there is no > > point in checking for them. > > > > Signed-off-by: Jean Delvare > > Signed-off-by: Andy Walls > > Signed-off-by: Mauro Carvalho Chehab > > > > Which is the first commit, prior to the one you fou
Re: [get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sat, 2011-02-12 at 12:05 -0700, Mark Zimmerman wrote: > On Sat, Feb 12, 2011 at 11:46:13AM -0500, Andy Walls wrote: > > On Sat, 2011-02-12 at 09:36 -0700, Mark Zimmerman wrote: > > > On Sat, Feb 12, 2011 at 11:27:27AM -0500, Andy Walls wrote: > > > > On Sat, 2011-02-12 at 08:29 -0700, Mark Zimmerman wrote: > > > > > On Tue, Dec 07, 2010 at 12:07:53PM -0700, Mark Zimmerman wrote: > > > > > > Greetings: > > > > > > > > > > > > I have a DViCO FusionHDTV7 Dual Express card that works with 2.6.35 > > > > > > but > > > > > > which fails to initialize with the latest 2.6.36 kernel. The > > > > > > firmware > > > > > > fails to load due to an i2c failure. A search of the archives > > > > > > indicates > > > > > > that this is not the first time this issue has occurred. > > > > > > > > > > > > What can I do to help get this problem fixed? > > > > > > > > > > > > Here is the dmesg from 2.6.35, for the two tuners: > > > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: firmware upload complete... > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: firmware upload complete.. > > > > > > > > > > > > and here is what happens with 2.6.36: > > > > > > > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: I2C write failed (len=3) > > > > > > xc5000: firmware upload complete... > > > > > > xc5000: Unable to initialise tuner > > > > > > xc5000: waiting for firmware upload (dvb-fe-xc5000-1.6.114.fw)... > > > > > > xc5000: firmware read 12401 bytes. > > > > > > xc5000: firmware uploading... > > > > > > xc5000: I2C write failed (len=3) > > > > > > xc5000: firmware upload complete... > > > > > > > > > > > > > > > > I did a git bisect on this and finally reached the end of the line. > > > > > Here is what it said: > > > > > > > > > > qpc$ git bisect bad > > > > > 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 is the first bad commit > > > > > commit 82ce67bf262b3f47ecb5a0ca31cace8ac72b7c98 > > > > > Author: Jarod Wilson > > > > > Date: Thu Jul 29 18:20:44 2010 -0300 > > > > > > > > > > V4L/DVB: staging/lirc: fix non-CONFIG_MODULES build horkage > > > > > > > > > > Fix when CONFIG_MODULES is not enabled: > > > > > > > > > > drivers/staging/lirc/lirc_parallel.c:243: error: implicit > > > > > declaration of function 'module_refcount' > > > > > drivers/staging/lirc/lirc_it87.c:150: error: implicit declaration > > > > > of function 'module_refcount' > > > > > drivers/built-in.o: In function `it87_probe': > > > > > lirc_it87.c:(.text+0x4079b0): undefined reference to `init_chrdev' > > > > > lirc_it87.c:(.text+0x4079cc): undefined reference to `drop_chrdev' > > > > > drivers/built-in.o: In function `lirc_it87_exit': > > > > > lirc_it87.c:(.exit.text+0x38a5): undefined reference to > > > > > `drop_chrdev' > > > > > > > > > > Its a quick hack and untested beyond building, since I don't have > > > > > the > > > > > hardware, but it should do the trick. > > > > > > > > > > Acked-by: Randy Dunlap > > > > > Signed-off-by: Jarod Wilson > > > > > Signed-off-by: Mauro Carvalho Chehab > > > > > > > > > > :04 04 f645b46a07b7ff87a2c11ac9296a5ff56e89a0d0 > > > > > 49e50945ccf8e1c8567c049908890d2752443b72 M drivers > > > > > > > > Hm
Re: PCTV USB2 PAL / adds loud hum to correct audio
On Sat, 2011-02-12 at 13:44 -0800, AW wrote:
> Devin Heitmueller wrote:
> > > When I use this command simultaneously:
> > > arecord -D front:CARD=PAL,DEV=0 -f S16_LE -c 2 -r 8000 /aux/tmp/bla.wav
> > > I get correct audio with strong noise:
> > > http://www.wgboome.de./bla.wav
> > > (it is from input=1 for copyright reasons... so there is silence plus
> noise)
> >
> > The "-r" argument should almost certainly be 48000, not 8000.
> >
> Maybe...
> That device is rather old...
> And i didnt tell pactl anything about sample rate...
I find audio at 8 ksps very unusual for a TV capture device.
> With the filter from the appendix the noise is gone...
> But it feels like a dirty hack, because it would cut out (overly?) loud
> noise,
> 2...
>
> My wild guess is, that the usbaudio driver injects some bad samples
> (0x8000..0x9000) every appr. 256 bytes...
I looked at the data. It is mostly hovering around 0, but you have
bursts of very negative values periodically:
(These values are shown as little endian, so swap the bytes to consider the
value)
630: faff fdff f9ff fbff 1080 1080 1080 1080
640: 1080 1080 faff fbff 1080 1080
650: 1080 1080 fbff fcff fbff fcff fdff fdff
...
0002fe0: 0100 0100 1080 1080
0002ff0: 1080 1080 1080 1080 1080 1080 1080 1080
0003000: 0100
0x8010 is -32752 and 0x is -30584.
The data set contains no large positive values (nothing in the range
0x1000-0x7fff).
The valuex 0x10 and 0x80 do remind me of the YUV values for black: Y =
0x10, U = 0x80, V = 0x80. Maybe some video data is getting thrown in
with the audio?
Regards,
Andy
> -Arne
>
> appendix:
> #include
> #include
>
> int main() {
> uint16_t buf[100];
> const int r = read(0,buf,sizeof(buf));
> for (int i=0; i*sizeof(*buf) if (buf[i]/256>=0x80 && buf[i]/256<0x90) continue;
> if (write(1,buf+i,2) != 2) break;
> }
> 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: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > > Clearly my previous bisection went astray; I think I have a more > > > sensible result this time. > > > > > > qpc$ git bisect good > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > Author: Jean Delvare > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > ? ?other transactions too. > > > > This could be a combination of the xc5000 doing clock stretching and > > the cx23885 i2c master not properly implementing clock stretch. In > > the past I've seen i2c masters broken in their handling of clock > > stretching where they treat it as a NAK. > > > > The xc5000 being one of the few devices that actually does i2c clock > > stretching often exposes cases where it is improperly implemented in > > the i2c master driver (I've had to fix this with several bridges). > > > > Thanks for your insight. I am looking at cx23885-i2c.c and there is no > clock stretching logic in i2c_slave_did_ack(). Would this be the > right place for it to be? Can you point me to an example of another > driver that does it correctly? I really don't know what I am doing... Mark, You don't have much hope of getting that right without the CX23885 datasheet. Let's just get the bad commit reverted and into 2.6.38, and fix what used to work for you. Doing a git bisect is enough work for anyone. I'll do a patch to revert the commit and ask it to be pulled for 2.6.38-rc-whatever. I'll be sure to add a Bisected-by: Mark Zimmerman tag to the patch. (The Linux Kernel devs understand the work involved to do a bisection.) Later, if I can work up a patch to deal with clock stretching properly, I may ask you to test. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: radio tuner but no V4L2_CAP_RADIO ?
On Sun, 2011-02-13 at 20:39 +0100, Martin Dauskardt wrote: > The following cards have a Multi Standard tuner with radio: > KNC One TV-Station DVR (saa7134) FMD1216MEX > HVR1300 (cx88-blackbird) Philips FMD1216ME > /dev/radio0 is present and working. > > Both drivers do not report the radio when using VIDIOC_QUERYCAP. > > Is this a bug, or is there no clear specification that a driver must report > this? The V4L2 API spec is unclear on this subject in most places, but it is *very* clear here: http://linuxtv.org/downloads/v4l-dvb-apis/radio.html#id2682669 "Devices supporting the radio interface set the V4L2_CAP_RADIO and V4L2_CAP_TUNER or V4L2_CAP_MODULATOR flag in the capabilities field of struct v4l2_capability returned by the VIDIOC_QUERYCAP ioctl." Those drivers have bugs. Regards, Andy > Is there are any other way to check radio for support (besides trying to open > a matching radio device) ? > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [corrected get-bisect results]: DViCO FusionHDTV7 Dual Express I2C write failed
On Sun, 2011-02-13 at 16:26 -0500, Andy Walls wrote: > On Sun, 2011-02-13 at 13:26 -0700, Mark Zimmerman wrote: > > On Sun, Feb 13, 2011 at 09:52:25AM -0500, Devin Heitmueller wrote: > > > On Sun, Feb 13, 2011 at 9:47 AM, Mark Zimmerman wrote: > > > > Clearly my previous bisection went astray; I think I have a more > > > > sensible result this time. > > > > > > > > qpc$ git bisect good > > > > 44835f197bf1e3f57464f23dfb239fef06cf89be is the first bad commit > > > > commit 44835f197bf1e3f57464f23dfb239fef06cf89be > > > > Author: Jean Delvare > > > > Date: ? Sun Jul 18 16:52:05 2010 -0300 > > > > > > > > ? ?V4L/DVB: cx23885: Check for slave nack on all transactions > > > > > > > > ? ?Don't just check for nacks on zero-length transactions. Check on > > > > ? ?other transactions too. > > > > > > This could be a combination of the xc5000 doing clock stretching and > > > the cx23885 i2c master not properly implementing clock stretch. In > > > the past I've seen i2c masters broken in their handling of clock > > > stretching where they treat it as a NAK. > > > > > > The xc5000 being one of the few devices that actually does i2c clock > > > stretching often exposes cases where it is improperly implemented in > > > the i2c master driver (I've had to fix this with several bridges). > > > Devin, I just checked. The CX23885 driver *is* setting up to allow slaves to stretch the clock. By analysis, I have confirmed that Jean's sugguested patch that I moved forward was wrong for the hardware's behavior. When the cx23885 I2C routines decide to set the I2C_EXTEND flag (and maybe the I2C_NOSTOP flag), we most certainly should *not* be expecting an ACK from the particular hardware register. The original commit should certainly be reverted. Checking for slave ACK/NAK will need to be done with a little more care; so for now, I'll settle for ignoring them. 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
cx23885-input.c does in fact use a workqueue....
Tejun, I just noticed this commit: commit 8c71778cbf2c8beaefaa2dee5478aa0622d96682 Author: Tejun Heo Date: Fri Dec 24 16:14:20 2010 +0100 media/video: don't use flush_scheduled_work() This patch converts the remaining users of flush_scheduled_work() in media/video. * bttv-input.c and cx23885-input.c don't use workqueue at all. No need to flush. [...] The cx23885 driver does in fact schedule work for IR input handling: Here's where it is scheduled for CX23888 chips: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-ir.c;h=7125247dd25558678c823ee3262675570c9aa630;hb=HEAD#l76 Here's where it is scheduled for CX23885 chips: http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-core.c;h=359882419b7f588b7c698dbcfb6a39ddb1603301;hb=HEAD#l1861 The two different chips are handled slightly differently because a. the CX23888 IR unit is accessable via a PCI register block. The IR IRQ can be acknowledged with direct PCI register accesses in an interrupt context, and the IR pulse FIFO serviced later in a workqueue context. b. the CX23885 IR unit is accessed over an I2C bus. The CX23885 A/V IRQ has to be masked in an interrupt context (with PCI registers accesses). Then the CX23885 A/V unit's IR IRQ is ack'ed over I2C in a workqueue context and the IR pulse FIFO is also serviced over I2C in a workqueue context. So what should be done about the flush_scheduled_work()? I think it belongs there. 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
[GIT FIXES for 2.6.38] Fix cx23885 and cx25840 regressions
Mauro, Please pull the following regression fixes (and related compiler squawk fix) for 2.6.38. Thanks go to Sven Barth for reporting the regression with the CX2583x chips in cx25840 and providing a patch. Thanks also go to Mark Zimmerman for climinb the git learning curve and devoting the time perform a git bisect to isolate the cx23885 regression. Regards, Andy The following changes since commit cf720fed25b8078ce0d6a10036dbf7a0baded679: [media] add support for Encore FM3 (2011-01-19 16:42:42 -0200) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git cx-fix-38 Andy Walls (2): cx23885: Revert "Check for slave nack on all transactions" cx23885: Remove unused 'err:' labels to quiet compiler warning Sven Barth (1): cx25840: fix probing of cx2583x chips drivers/media/video/cx23885/cx23885-i2c.c | 10 -- drivers/media/video/cx25840/cx25840-core.c |3 ++- 2 files changed, 2 insertions(+), 11 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [GIT FIXES for 2.6.38] Fix cx23885 and cx25840 regressions
Jean Delvare wrote: >> Andy Walls (2): >> cx23885: Revert "Check for slave nack on all transactions" > >Thanks for fixing my mistakes! > Jean, No problem. I was the one who actually asked for your patch to go in without checking the hardware behavior carefully. So I jointly own the mistake. :) I'll shoulder some of the blame. Regards, Andy -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: cx23885-input.c does in fact use a workqueue....
On Mon, 2011-02-14 at 12:03 +0100, Tejun Heo wrote: > Hello, > > On Sun, Feb 13, 2011 at 08:33:55PM -0800, Dmitry Torokhov wrote: > > > The cx23885 driver does in fact schedule work for IR input handling: > > > > > > Here's where it is scheduled for CX23888 chips: > > > > > > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-ir.c;h=7125247dd25558678c823ee3262675570c9aa630;hb=HEAD#l76 > > > > > > Here's where it is scheduled for CX23885 chips: > > > > > > http://git.linuxtv.org/media_tree.git?a=blob;f=drivers/media/video/cx23885/cx23885-core.c;h=359882419b7f588b7c698dbcfb6a39ddb1603301;hb=HEAD#l1861 > > Ah, sorry about missing those. There's a lot of indirection in drivers under drivers/media/video so it doesn't surprise me when someone misses something. (BTW, I only checked cx23885 since I wrote the IR handling and added the work queue usage for IR that driver.) > > > So what should be done about the flush_scheduled_work()? I think it > > > belongs there. > > > > > > > Convert to using threaded irq? Too big of a regression testing job for me to take on at the moment. > Or > > 1. Just flush the work items explicitly using flush_work_sync(). That will do for now. > 2. Create a dedicated workqueue to serve as flushing domain. I have gotten reports of the IR Rx FIFO overflows for the CX23885 IR Rx unit (the I2C connected one). I eventually should either set the Rx FIFO service interrupt watermark down from 4 measurments to 1 measurment, or use a kthread_worker with some higher priority to respond to the IR Rx FIFO service interrupt. > The first would look like the following. Does this look correct? Yes, your patch below looks sane to me. Reviewed-by: Andy Walls Thanks, Andy > Thanks. > > diff --git a/drivers/media/video/cx23885/cx23885-input.c > b/drivers/media/video/cx23885/cx23885-input.c > index 199b996..e27cedb 100644 > --- a/drivers/media/video/cx23885/cx23885-input.c > +++ b/drivers/media/video/cx23885/cx23885-input.c > @@ -229,6 +229,9 @@ static void cx23885_input_ir_stop(struct cx23885_dev *dev) > v4l2_subdev_call(dev->sd_ir, ir, rx_s_parameters, ¶ms); > v4l2_subdev_call(dev->sd_ir, ir, rx_g_parameters, ¶ms); > } > + flush_work_sync(&dev->cx25840_work); > + flush_work_sync(&dev->ir_rx_work); > + flush_work_sync(&dev->ir_tx_work); > } > > static void cx23885_input_ir_close(struct rc_dev *rc) > -- 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: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
On Mon, 2011-02-14 at 13:35 +0200, Dennis Kurten wrote: > Hello, > > This card (technisat cablestar hd 2 dvb-c) works fine when plugged > into a native PCI slot. > When I try it with a PCI-adapter I intend to use in mITX-builds there > doesn't seem > to be any data coming in through the tuner. The adapter is a > transparent bridge (with a > PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through a > 4-pin molex. > > My guess is some kind of dma mapping incompatibility with the mantis > driver (s2-liplianin). > The card seems to initialize correctly, but doesn't work when the > tuner is put into action > (scandvb timeouts, dvbtraffic yields nothing). For the record, I've > tested the bridge with a > firewire card and that works fine. > > Kernel is 2.6.32 (+the compiled drivers) > > lspci for the bridge and the card: > -- > 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI > Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) > Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- > SERR- Latency: 0, Cache Line Size: 32 bytes ^^ I can't remember the exact meaning of setting the latency to 0. IIRC it is not actually 0, but allows at least to one data phase (but that may not be enough for correct operation): http://www.sierrasales.com/pdfs/PCI-PCI_Bridges_When_Designing.pdf I would recommend you use setpci to bump this number up to 32, 64, or 128 for troubleshooting/testing to ensure the bridge gets a decent number of PCI bus clocks on the bus. The worst thing that could happen is the PLX bridge hogs a PCI bus segment while you are testing - no big deal. > Bus: primary=03, secondary=04, subordinate=04, sec-latency=32 > I/O behind bridge: e000-efff > Memory behind bridge: fdd0-fddf > Prefetchable memory behind bridge: fdc0-fdcf > Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium > >TAbort- BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B- > PriDiscTmr- SecDiscTmr- DiscTmrStat+ DiscTmrSERREn- > Capabilities: > Kernel modules: shpchp > > 04:00.0 Multimedia controller: Twinhan Technology Co. Ltd Mantis DTV > PCI Bridge Controller [Ver 1.0] (rev 01) > Subsystem: Device 1ae4:0002 > Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- > ParErr- Stepping- SERR- FastB2B- DisINTx- > Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium > >TAbort- SERR- Latency: 32 (2000ns min, 63750ns max) > Interrupt: pin A routed to IRQ 16 > Region 0: Memory at fdcff000 (32-bit, prefetchable) [size=4K] Heh, I always find it curious when I/O peripherials claim their register space is prefetchable (the CX23416 does this as well). If the chip is designed right, it is valid though AFAICT. You may want to run a separate test with the cache-line size on the bridge set to something smaller than 32 using setpci. I believe powers of 2 and the value 0 are allowed. Transfers will become more inefficient with smaller cache-line size, but it may eliminate any problems related to conditions required for prefetching. Worth a try. You may also want to look for some BIOS/EFI settings related to interrupt routing and emulation. Regards, Andy > Kernel driver in use: Mantis > Kernel modules: mantis > > dmesg output with modules loaded: > - > Mantis :04:00.0: PCI INT A -> Link[APC7] -> GSI 16 (level, low) -> IRQ 16 > irq: 16, latency: 32 > memory: 0xfdcff000, mmio: 0xc900031a > found a VP-2040 PCI DVB-C device on (04:00.0), > Mantis Rev 1 [1ae4:0002], irq: 16, latency: 32 > memory: 0xfdcff000, mmio: 0xc900031a > MAC Address=[00:08:c9:d0:46:b4] > mantis_alloc_buffers (0): DMA=0x1bb9 cpu=0x88001bb9 size=65536 > mantis_alloc_buffers (0): RISC=0x1bbec000 cpu=0x88001bbec000 size=1000 > DVB: registering new adapter (Mantis dvb adapter) > mantis_frontend_init (0): Probing for CU1216 (DVB-C) > TDA10023: i2c-addr = 0x0c, id = 0x7d > mantis_frontend_init (0): found Philips CU1216 DVB-C frontend (TDA10023) @ > 0x0c > mantis_frontend_init (0): Mantis DVB-C Philips CU1216 frontend attach success > DVB: registering adapter 0 frontend 0 (Philips TDA10023 DVB-C)... > mantis_ca_init (0): Registering EN50221 device > mantis_ca_init (0): Registered EN50221 device > mantis_hif_init (0): Adapter(0) Initializing Mantis Host Interface > Registered IR keymap rc-vp2040 > input: Mantis VP-2040 IR Receiver as /devices/virtual/rc/rc4/input11 > rc4: Mantis VP-2040 IR Receiver as /devices/virtual/rc/rc4 > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded > su
Re: No data from tuner over PCI bridge adapter (Cablestar HD 2 / mantis / PEX 8112)
Dennis Kurten wrote: >The power issue did cross my mind after some more research. Maybe >that would explain why the card is registering correctly but not >returning >any tuned data. I haven't found any detailed requirement specs for the >tv card but I assume that the tuner/demodulator could consume a fair >amount of power. However, my adapter should be supplying 12V >500mA with the molex. I'll try to measure if I can get the equipment >of >a friend (just in case, since the connectors seem a bit sloppy). > >Andy's insightful tips from the other reply also made a lot of sense >since >there does not seem to be anything at all coming back from the card, >not >even jitter or noise. That could indicate lost interrupts / bus >mastering >problems. I'll see tonight after some tweaking. > >As far as using native PCIe cards there's only one experimental (and >very expensive) DVB-C model I know of. Combine this with the shortage >of PCI slots on SFF motherboards and you have a problem with media >centers. > >Regard, >Dennis > > > >On Tue, Feb 15, 2011 at 10:20 AM, Konstantin Dimitrov > wrote: >> oh, i have just noticed your DVB card is for Cable and not for >> Satellite, but still it may use 12V PCI interface pins for something >> else and not exactly for LNB power as i thought assuming it's >DVB-S/S2 >> DVB card. >> >> On Tue, Feb 15, 2011 at 10:18 AM, Konstantin Dimitrov >> wrote: >>> hi, does your DVB card can get signal lock when it's inserted into >the >>> PCI-to-PCIE adapter, because as far as i know most PCI-to-PCIE >>> adapters based on PEX 8111/8112 don't provide power to 12V pins of >the >>> PCI interface, which probably all PCI DVB card use for LNB power. >so, >>> what i would check if i'm at your position is the LNB power of the >>> card as well as if there is no some extensive amount of noise in the >>> LNB power when the DVB card is inside PEX 8111/8112 PCI-to-PCIE >>> adapter. also, i can give you example from my own experience with an >>> "Audiotrak Prodigy HD2" PCI audio card and PEX 8111/8112 based >>> PCI-to-PCIE adapters - with one such adapter that don't provide >power >>> to 12V pins of the PCI interface there is no sound coming out, >because >>> the amplifier on the card uses power from 12V pins of the PCI >>> interface, with another PEX 8111/8112 PCI-to-PCIE adapter that seems >>> to provide power to 12V pins there is extensive noise in the sound >>> that is coming out, because PCI-to-PCIE adapter doesn't provide good >>> power on 12V pins of the PCI interface and thus the noise in the >>> audio. also, on some motherboards (with nVidia chipset on my tests) >>> there was some problem with how the memory was mapped preventing the >>> work of the PCI card when it's inserted into PEX 8111/8112 based >>> PCI-to-PCIE adapter. so, it's also helpful to test motherboards with >>> different chipset. in any case it's always better to find and use >>> native PCI-Express card instead of PEX 8111/8112 PCI-to-PCIE adapter >>> and PCI card. anyway, maybe, someone with more hardware engineering >>> knowledge then i have, especially if the problem is 12V can find >some >>> way to fix those cheap PEX 8111/8112 PCI-to-PCIE adapters that are >>> floating around, because i'm sure they just sacrifice 12V power to >>> lower the BOM cost of the adapter. BTW, i'm sure your firewire card >is >>> working, because it doesn't use 12V PCI interface pins - it's the >same >>> with many PCI cards, but all that needs 12V are no-go based on my >>> experience. >>> >>> --konstantin >>> >>> On Mon, Feb 14, 2011 at 1:35 PM, Dennis Kurten > wrote: Hello, This card (technisat cablestar hd 2 dvb-c) works fine when plugged into a native PCI slot. When I try it with a PCI-adapter I intend to use in mITX-builds >there doesn't seem to be any data coming in through the tuner. The adapter is a transparent bridge (with a PEX 8112 chip) that goes into a 1xPCIe-slot and gets power through >a 4-pin molex. My guess is some kind of dma mapping incompatibility with the >mantis driver (s2-liplianin). The card seems to initialize correctly, but doesn't work when the tuner is put into action (scandvb timeouts, dvbtraffic yields nothing). For the record, I've tested the bridge with a firewire card and that works fine. Kernel is 2.6.32 (+the compiled drivers) lspci for the bridge and the card: -- 03:00.0 PCI bridge: PLX Technology, Inc. PEX8112 x1 Lane PCI Express-to-PCI Bridge (rev aa) (prog-if 00 [Normal decode]) Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >>TAbort- SERR- >>> Latency: 0, Cache Line Size: 32 bytes Bus: primary=03, secondary=04, subordinate=04, >sec-latency=32 I/O behind bridge: e000-efff >>>
Re: [PATCH 1/4] [media] tuner-core: remove usage of DIGITAL_TV
Mauro Carvalho Chehab wrote:
>tuner-core has no business to do with digital TV. So, don't use
>T_DIGITAL_TV on it, as it has no code to distinguish between
>them, and nobody fills T_DIGITAL_TV right.
>
>Signed-off-by: Mauro Carvalho Chehab
>
>diff --git a/drivers/media/video/au0828/au0828-cards.c
>b/drivers/media/video/au0828/au0828-cards.c
>index 01be89f..39fc923 100644
>--- a/drivers/media/video/au0828/au0828-cards.c
>+++ b/drivers/media/video/au0828/au0828-cards.c
>@@ -185,8 +185,7 @@ void au0828_card_setup(struct au0828_dev *dev)
> static u8 eeprom[256];
> struct tuner_setup tun_setup;
> struct v4l2_subdev *sd;
>- unsigned int mode_mask = T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_ANALOG_TV;
>
> dprintk(1, "%s()\n", __func__);
>
>diff --git a/drivers/media/video/bt8xx/bttv-cards.c
>b/drivers/media/video/bt8xx/bttv-cards.c
>index 7f58756..242f0d5 100644
>--- a/drivers/media/video/bt8xx/bttv-cards.c
>+++ b/drivers/media/video/bt8xx/bttv-cards.c
>@@ -3616,7 +3616,7 @@ void __devinit bttv_init_tuner(struct bttv *btv)
> &btv->c.i2c_adap, "tuner",
> 0, v4l2_i2c_tuner_addrs(ADDRS_TV_WITH_DEMOD));
>
>- tun_setup.mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>+ tun_setup.mode_mask = T_ANALOG_TV;
> tun_setup.type = btv->tuner_type;
> tun_setup.addr = addr;
>
>diff --git a/drivers/media/video/cx88/cx88-cards.c
>b/drivers/media/video/cx88/cx88-cards.c
>index 4e6ee55..8128b93 100644
>--- a/drivers/media/video/cx88/cx88-cards.c
>+++ b/drivers/media/video/cx88/cx88-cards.c
>@@ -3165,9 +3165,7 @@ static void cx88_card_setup(struct cx88_core
>*core)
> {
> static u8 eeprom[256];
> struct tuner_setup tun_setup;
>- unsigned int mode_mask = T_RADIO |
>- T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>
> memset(&tun_setup, 0, sizeof(tun_setup));
>
>diff --git a/drivers/media/video/saa7134/saa7134-cards.c
>b/drivers/media/video/saa7134/saa7134-cards.c
>index 74467c1..61c6007 100644
>--- a/drivers/media/video/saa7134/saa7134-cards.c
>+++ b/drivers/media/video/saa7134/saa7134-cards.c
>@@ -7333,9 +7333,7 @@ int saa7134_board_init1(struct saa7134_dev *dev)
> static void saa7134_tuner_setup(struct saa7134_dev *dev)
> {
> struct tuner_setup tun_setup;
>- unsigned int mode_mask = T_RADIO |
>- T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ unsigned int mode_mask = T_RADIO | T_ANALOG_TV;
>
> memset(&tun_setup, 0, sizeof(tun_setup));
> tun_setup.tuner_callback = saa7134_tuner_callback;
>diff --git a/drivers/media/video/tuner-core.c
>b/drivers/media/video/tuner-core.c
>index dcf03fa..5e1437c 100644
>--- a/drivers/media/video/tuner-core.c
>+++ b/drivers/media/video/tuner-core.c
>@@ -497,7 +497,7 @@ static void tuner_lookup(struct i2c_adapter *adap,
> device. If other devices appear then we need to
> make this test more general. */
> else if (*tv == NULL && pos->type != TUNER_TDA9887 &&
>- (pos->mode_mask & (T_ANALOG_TV | T_DIGITAL_TV)))
>+ (pos->mode_mask & T_ANALOG_TV))
> *tv = pos;
> }
> }
>@@ -565,8 +565,7 @@ static int tuner_probe(struct i2c_client *client,
> } else {
> /* Default is being tda9887 */
> t->type = TUNER_TDA9887;
>- t->mode_mask = T_RADIO | T_ANALOG_TV |
>- T_DIGITAL_TV;
>+ t->mode_mask = T_RADIO | T_ANALOG_TV;
> goto register_client;
> }
> break;
>@@ -596,7 +595,7 @@ static int tuner_probe(struct i2c_client *client,
> first found TV tuner. */
> tuner_lookup(t->i2c->adapter, &radio, &tv);
> if (tv == NULL) {
>- t->mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
>+ t->mode_mask = T_ANALOG_TV;
> if (radio == NULL)
> t->mode_mask |= T_RADIO;
> tuner_dbg("Setting mode_mask to 0x%02x\n", t->mode_mask);
>@@ -607,18 +606,15 @@ register_client:
> /* Sets a default mode */
> if (t->mode_mask & T_ANALOG_TV)
> t->mode = V4L2_TUNER_ANALOG_TV;
>- else if (t->mode_mask & T_RADIO)
>- t->mode = V4L2_TUNER_RADIO;
> else
>- t->mode = V4L2_TUNER_DIGITAL_TV;
>+ t->mode = V4L2_TUNER_RADIO;
> set_type(client, t->type, t->mode_mask, t->config, t->fe.callback);
> list_add_tail(&t->list, &tuner_list);
>
>- tuner_info("Tuner %d found with type(s)%s%s%s.\n",
>+ tuner_info("Tuner %d found with
Re: [PATCH 1/4] [media] tuner-core: remove usage of DIGITAL_TV
On Tue, 2011-02-15 at 17:48 -0200, Mauro Carvalho Chehab wrote:
> Em 15-02-2011 15:25, Andy Walls escreveu:
> > Mauro Carvalho Chehab wrote:
> >
> >> tuner-core has no business to do with digital TV. So, don't use
> >> T_DIGITAL_TV on it, as it has no code to distinguish between
> >> them, and nobody fills T_DIGITAL_TV right.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab
> >>
> >> diff --git a/drivers/media/video/tuner-core.c
> >> b/drivers/media/video/tuner-core.c
> >> index dcf03fa..5e1437c 100644
> >> --- a/drivers/media/video/tuner-core.c
> >> +++ b/drivers/media/video/tuner-core.c
> >> @@ -596,7 +595,7 @@ static int tuner_probe(struct i2c_client *client,
> >> first found TV tuner. */
> >>tuner_lookup(t->i2c->adapter, &radio, &tv);
> >>if (tv == NULL) {
> >> - t->mode_mask = T_ANALOG_TV | T_DIGITAL_TV;
> >> + t->mode_mask = T_ANALOG_TV;
> >>if (radio == NULL)
> >>t->mode_mask |= T_RADIO;
> >>tuner_dbg("Setting mode_mask to 0x%02x\n", t->mode_mask);
> >> @@ -607,18 +606,15 @@ register_client:
> >>/* Sets a default mode */
> >>if (t->mode_mask & T_ANALOG_TV)
> >>t->mode = V4L2_TUNER_ANALOG_TV;
> >> - else if (t->mode_mask & T_RADIO)
> >> - t->mode = V4L2_TUNER_RADIO;
> >>else
> >> - t->mode = V4L2_TUNER_DIGITAL_TV;
> >> + t->mode = V4L2_TUNER_RADIO;
^
Mauro,
Here's where I saw a default being changed from DIGITAL_TV to RADIO.
Maybe it doesn't matter?
> > Hmm. I thought tuner-cards.c or tuner-simple.c had entries for hybrid
> > tuner assemblies.
>
> They have, but tuner-core takes care only for V4L2 API calls.
>
> > You are changing the default mode from digital to radio; does that affect
> > the use of the hybrid tuner assemblies.
>
> Where are you seeing such change? I just removed T_DIGITAL_TV mode mask, as
> this is
> unused. On all places at boards, they use a mask with (T_ANALOG_TV |
> T_DIGITAL_TV).
> The same mask is used at tuner-core. This patch is basically:
> s/"T_ANALOG_TV | T_DIGITAL_TV"/T_ANALOG_TV/g
>
> Also, the default mode is almost meaningless. On all VIDIOC calls that touch
> at tuner
> (get/set frequency, get/set tuner), the type of the tuner is passed as a
> parameter.
> So, no default mode is assumed. At digital mode, on all cases, the set_params
> callback
> will pass the bandwidth, digital tv standard and the frequency to set. The
> digital TV
> logic inside the tuner will handle it directly, via a direct I2C attach
> function, not
> using tuner-core.
OK.
Regards,
Andy
> So, this patch should cause no functional change.
>
> 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] [media] rc: do not enable remote controller adapters by default.
On Wed, 2011-02-16 at 01:16 -0500, Stephen Wilson wrote: > Having the RC_CORE config default to INPUT is almost equivalent to > saying "yes". Default to "no" instead. > > Signed-off-by: Stephen Wilson I don't particularly like this, if it discourages desktop distributions from building RC_CORE. The whole point of RC_CORE in kernel was to have the remote controllers bundled with TV and DTV cards "just work" out of the box for end users. Also the very popular MCE USB receiver device, shipped with Media Center PC setups, needs it too. Why exactly do you need it set to "No"? Regards, Andy > --- > drivers/media/rc/Kconfig |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig > index 3785162..8842843 100644 > --- a/drivers/media/rc/Kconfig > +++ b/drivers/media/rc/Kconfig > @@ -1,7 +1,7 @@ > menuconfig RC_CORE > tristate "Remote Controller adapters" > depends on INPUT > - default INPUT > + default n > ---help--- > Enable support for Remote Controllers on Linux. This is > needed in order to support several video capture adapters. > -- > 1.7.3.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 -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/13] lirc_zilog: Ref-counting and locking cleanup
The following 13 patches are a substantial rework of lirc_zilog reference counting, object allocation and deallocation, and object locking. With these changes, devices can now disappear out from under lircd + lirc_dev + lirc_zilog with no adverse effects. I tested this with irw + lircd + lirc_dev + lirc_zilog + cx18 + HVR-1600. I could unload the cx18 driver without any oops or application crashes. When I reloaded the cx18 driver, irw started receiving RX button presses again, and irsend worked without a problem (and I didn't even need to restart lircd!). The ref counting fixes aren't finished as lirc_zilog itself can still be unloaded by the user when it shouldn't be, but a hot unplug of an HD-PVR, PVR-USB2, or HVR-1950 isn't going to trigger that. These changes are base off of Jarod Wilson's git repo http://git.linuxtv.org/jarod/linux-2.6-ir.git for-2.6.38 (IIRC) Regards, Andy The following changes since commit c369acfb63914f9f502baef032bacfd5a53a871f: mceusb: really fix remaining keybounce issues (2011-01-26 10:56:29 -0500) are available in the git repository at: ssh://linuxtv.org/git/awalls/media_tree.git z8-wilson-38 Andy Walls (13): lirc_zilog: Restore checks for existence of the IR_tx object lirc_zilog: Remove broken, ineffective reference counting lirc_zilog: Convert ir_device instance array to a linked list lirc_zilog: Convert the instance open count to an atomic_t lirc_zilog: Use kernel standard methods for marking device non-seekable lirc_zilog: Don't acquire the rx->buf_lock in the poll() function lirc_zilog: Remove unneeded rx->buf_lock lirc_zilog: Always allocate a Rx lirc_buffer object lirc_zilog: Move constants from ir_probe() into the lirc_driver template lirc_zilog: Add ref counting of struct IR, IR_tx, and IR_rx lirc_zilog: Add locking of the i2c_clients when in use lirc_zilog: Fix somewhat confusing information messages in ir_probe() lirc_zilog: Update TODO list based on work completed and revised plans drivers/staging/lirc/TODO.lirc_zilog | 51 +-- drivers/staging/lirc/lirc_zilog.c| 802 +- 2 files changed, 523 insertions(+), 330 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 01/13] lirc_zilog: Restore checks for existence of the IR_tx object
This reverts commit 8090232a237ab62e22307fc060097da1a283dd66 and
adds an additional check for ir->tx == NULL.
The user may need us to handle an RX only unit. Apparently
there are TV capture units in existence with Rx only wiring
and/or RX only firmware for the on-board Zilog Z8 IR unit.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 27 ---
1 files changed, 20 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 0aad0d7..7389b77 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -209,7 +209,8 @@ static int add_to_buf(struct IR *ir)
return -ENODATA;
}
schedule_timeout((100 * HZ + 999) / 1000);
- ir->tx->need_boot = 1;
+ if (ir->tx != NULL)
+ ir->tx->need_boot = 1;
++failures;
mutex_unlock(&ir->ir_lock);
@@ -1032,9 +1033,10 @@ static long ioctl(struct file *filep, unsigned int cmd,
unsigned long arg)
int result;
unsigned long mode, features = 0;
- features |= LIRC_CAN_SEND_PULSE;
if (ir->rx != NULL)
features |= LIRC_CAN_REC_LIRCCODE;
+ if (ir->tx != NULL)
+ features |= LIRC_CAN_SEND_PULSE;
switch (cmd) {
case LIRC_GET_LENGTH:
@@ -1061,9 +1063,15 @@ static long ioctl(struct file *filep, unsigned int cmd,
unsigned long arg)
result = -EINVAL;
break;
case LIRC_GET_SEND_MODE:
+ if (!(features&LIRC_CAN_SEND_MASK))
+ return -ENOSYS;
+
result = put_user(LIRC_MODE_PULSE, (unsigned long *) arg);
break;
case LIRC_SET_SEND_MODE:
+ if (!(features&LIRC_CAN_SEND_MASK))
+ return -ENOSYS;
+
result = get_user(mode, (unsigned long *) arg);
if (!result && mode != LIRC_MODE_PULSE)
return -EINVAL;
@@ -1242,8 +1250,10 @@ static int ir_remove(struct i2c_client *client)
}
/* Good-bye Tx */
- i2c_set_clientdata(ir->tx->c, NULL);
- kfree(ir->tx);
+ if (ir->tx != NULL) {
+ i2c_set_clientdata(ir->tx->c, NULL);
+ kfree(ir->tx);
+ }
/* Good-bye IR */
del_ir_device(ir);
@@ -1393,9 +1403,12 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
* after registering with lirc as otherwise hotplug seems to take
* 10s to create the lirc device.
*/
- ret = tx_init(ir->tx);
- if (ret != 0)
- goto out_unregister;
+ if (ir->tx != NULL) {
+ /* Special TX init */
+ ret = tx_init(ir->tx);
+ if (ret != 0)
+ goto out_unregister;
+ }
zilog_info("probe of IR %s on %s (i2c-%d) done. IR unit ready.\n",
tx_probe ? "Tx" : "Rx", adap->name, adap->nr);
--
1.7.2.1
--
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 02/13] lirc_zilog: Remove broken, ineffective reference counting
The set_use_inc() and set_use_dec() functions tried to lock
the underlying bridge driver device instance in memory by
changing the use count on the device's i2c_clients. This
worked for PCI devices (ivtv, cx18, bttv). It doesn't
work for hot-pluggable usb devices (pvrusb2 and hdpvr).
With usb device instances, the driver may get locked into
memory, but the unplugged hardware is gone.
The set_use_inc() set_use_dec() functions also tried to have
lirc_zilog change its own module refernce count, which is
racy and not guaranteed to work. The lirc_dev module does
actually perform proper module ref count manipulation on the
lirc_zilog module, so there is need for lirc_zilog to
attempt a buggy module get on itself anyway.
lirc_zilog also errantly called these functions on itself
in open() and close(), but lirc_dev did that already too.
So let's just gut the bodies of the set_use_*() functions,
and remove the extra calls to them from within lirc_zilog.
Proper reference counting of the struct IR, IR_rx, and IR_tx
objects -- to handle the case when the underlying
bttv, ivtv, cx18, hdpvr, or pvrusb2 bridge driver module or
device instance goes away -- will be added in subsequent
patches.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 32 +---
1 files changed, 1 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 7389b77..3a91257 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -305,34 +305,12 @@ static int lirc_thread(void *arg)
static int set_use_inc(void *data)
{
- struct IR *ir = data;
-
- if (ir->l.owner == NULL || try_module_get(ir->l.owner) == 0)
- return -ENODEV;
-
- /* lock bttv in memory while /dev/lirc is in use */
- /*
-* this is completely broken code. lirc_unregister_driver()
-* must be possible even when the device is open
-*/
- if (ir->rx != NULL)
- i2c_use_client(ir->rx->c);
- if (ir->tx != NULL)
- i2c_use_client(ir->tx->c);
-
return 0;
}
static void set_use_dec(void *data)
{
- struct IR *ir = data;
-
- if (ir->rx)
- i2c_release_client(ir->rx->c);
- if (ir->tx)
- i2c_release_client(ir->tx->c);
- if (ir->l.owner != NULL)
- module_put(ir->l.owner);
+ return;
}
/* safe read of a uint32 (always network byte order) */
@@ -1098,7 +1076,6 @@ static struct IR *find_ir_device_by_minor(unsigned int
minor)
static int open(struct inode *node, struct file *filep)
{
struct IR *ir;
- int ret;
unsigned int minor = MINOR(node->i_rdev);
/* find our IR struct */
@@ -1112,12 +1089,6 @@ static int open(struct inode *node, struct file *filep)
/* increment in use count */
mutex_lock(&ir->ir_lock);
++ir->open;
- ret = set_use_inc(ir);
- if (ret != 0) {
- --ir->open;
- mutex_unlock(&ir->ir_lock);
- return ret;
- }
mutex_unlock(&ir->ir_lock);
/* stash our IR struct */
@@ -1139,7 +1110,6 @@ static int close(struct inode *node, struct file *filep)
/* decrement in use count */
mutex_lock(&ir->ir_lock);
--ir->open;
- set_use_dec(ir);
mutex_unlock(&ir->ir_lock);
return 0;
--
1.7.2.1
--
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 03/13] lirc_zilog: Convert ir_device instance array to a linked list
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 59 +++-
1 files changed, 31 insertions(+), 28 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 3a91257..39f7b53 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -89,6 +89,8 @@ struct IR_tx {
};
struct IR {
+ struct list_head list;
+
struct lirc_driver l;
struct mutex ir_lock;
@@ -99,9 +101,9 @@ struct IR {
struct IR_tx *tx;
};
-/* Minor -> data mapping */
-static struct mutex ir_devices_lock;
-static struct IR *ir_devices[MAX_IRCTL_DEVICES];
+/* IR transceiver instance object list */
+static DEFINE_MUTEX(ir_devices_lock);
+static LIST_HEAD(ir_devices_list);
/* Block size for IR transmitter */
#define TX_BLOCK_SIZE 99
@@ -1063,10 +1065,16 @@ static long ioctl(struct file *filep, unsigned int cmd,
unsigned long arg)
/* ir_devices_lock must be held */
static struct IR *find_ir_device_by_minor(unsigned int minor)
{
- if (minor >= MAX_IRCTL_DEVICES)
+ struct IR *ir;
+
+ if (list_empty(&ir_devices_list))
return NULL;
- return ir_devices[minor];
+ list_for_each_entry(ir, &ir_devices_list, list)
+ if (ir->l.minor == minor)
+ return ir;
+
+ return NULL;
}
/*
@@ -1172,25 +1180,21 @@ static void destroy_rx_kthread(struct IR_rx *rx)
/* ir_devices_lock must be held */
static int add_ir_device(struct IR *ir)
{
- int i;
-
- for (i = 0; i < MAX_IRCTL_DEVICES; i++)
- if (ir_devices[i] == NULL) {
- ir_devices[i] = ir;
- break;
- }
-
- return i == MAX_IRCTL_DEVICES ? -ENOMEM : i;
+ list_add_tail(&ir->list, &ir_devices_list);
+ return 0;
}
/* ir_devices_lock must be held */
static void del_ir_device(struct IR *ir)
{
- int i;
+ struct IR *p;
+
+ if (list_empty(&ir_devices_list))
+ return;
- for (i = 0; i < MAX_IRCTL_DEVICES; i++)
- if (ir_devices[i] == ir) {
- ir_devices[i] = NULL;
+ list_for_each_entry(p, &ir_devices_list, list)
+ if (p == ir) {
+ list_del(&p->list);
break;
}
}
@@ -1237,17 +1241,16 @@ static int ir_remove(struct i2c_client *client)
/* ir_devices_lock must be held */
static struct IR *find_ir_device_by_adapter(struct i2c_adapter *adapter)
{
- int i;
- struct IR *ir = NULL;
+ struct IR *ir;
- for (i = 0; i < MAX_IRCTL_DEVICES; i++)
- if (ir_devices[i] != NULL &&
- ir_devices[i]->adapter == adapter) {
- ir = ir_devices[i];
- break;
- }
+ if (list_empty(&ir_devices_list))
+ return NULL;
+
+ list_for_each_entry(ir, &ir_devices_list, list)
+ if (ir->adapter == adapter)
+ return ir;
- return ir;
+ return NULL;
}
static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
@@ -1284,6 +1287,7 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
goto out_no_ir;
}
/* store for use in ir_probe() again, and open() later on */
+ INIT_LIST_HEAD(&ir->list);
ret = add_ir_device(ir);
if (ret)
goto out_free_ir;
@@ -1421,7 +1425,6 @@ static int __init zilog_init(void)
zilog_notify("Zilog/Hauppauge IR driver initializing\n");
mutex_init(&tx_data_lock);
- mutex_init(&ir_devices_lock);
request_module("firmware_class");
--
1.7.2.1
--
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 04/13] lirc_zilog: Convert the instance open count to an atomic_t
The open count is simply used for deciding if the Rx polling thread
needs to poll the IR chip for userspace. Simplify the manipulation
of the open count by using an atomic_t and not requiring a lock
The polling thread errantly didn't try to take the lock anyway.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 39f7b53..c857b99 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -94,7 +94,7 @@ struct IR {
struct lirc_driver l;
struct mutex ir_lock;
- int open;
+ atomic_t open_count;
struct i2c_adapter *adapter;
struct IR_rx *rx;
@@ -279,7 +279,7 @@ static int lirc_thread(void *arg)
set_current_state(TASK_INTERRUPTIBLE);
/* if device not opened, we can sleep half a second */
- if (!ir->open) {
+ if (atomic_read(&ir->open_count) == 0) {
schedule_timeout(HZ/2);
continue;
}
@@ -1094,10 +1094,7 @@ static int open(struct inode *node, struct file *filep)
if (ir == NULL)
return -ENODEV;
- /* increment in use count */
- mutex_lock(&ir->ir_lock);
- ++ir->open;
- mutex_unlock(&ir->ir_lock);
+ atomic_inc(&ir->open_count);
/* stash our IR struct */
filep->private_data = ir;
@@ -1115,10 +1112,7 @@ static int close(struct inode *node, struct file *filep)
return -ENODEV;
}
- /* decrement in use count */
- mutex_lock(&ir->ir_lock);
- --ir->open;
- mutex_unlock(&ir->ir_lock);
+ atomic_dec(&ir->open_count);
return 0;
}
@@ -1294,6 +1288,7 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
ir->adapter = adap;
mutex_init(&ir->ir_lock);
+ atomic_set(&ir->open_count, 0);
/* set lirc_dev stuff */
memcpy(&ir->l, &lirc_template, sizeof(struct lirc_driver));
--
1.7.2.1
--
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 05/13] lirc_zilog: Use kernel standard methods for marking device non-seekable
lirc_zilog had its own llseek stub that returned -ESPIPE. Get rid of
it and use the kernel's no_llseek() and nonseekable_open() functions
instead.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c |9 ++---
1 files changed, 2 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index c857b99..720ef67 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -712,12 +712,6 @@ static int tx_init(struct IR_tx *tx)
return 0;
}
-/* do nothing stub to make LIRC happy */
-static loff_t lseek(struct file *filep, loff_t offset, int orig)
-{
- return -ESPIPE;
-}
-
/* copied from lirc_dev */
static ssize_t read(struct file *filep, char *outbuf, size_t n, loff_t *ppos)
{
@@ -1099,6 +1093,7 @@ static int open(struct inode *node, struct file *filep)
/* stash our IR struct */
filep->private_data = ir;
+ nonseekable_open(node, filep);
return 0;
}
@@ -1150,7 +1145,7 @@ static struct i2c_driver driver = {
static const struct file_operations lirc_fops = {
.owner = THIS_MODULE,
- .llseek = lseek,
+ .llseek = no_llseek,
.read = read,
.write = write,
.poll = poll,
--
1.7.2.1
--
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 06/13] lirc_zilog: Don't acquire the rx->buf_lock in the poll() function
There is no need to take the rx->buf_lock in the the poll() function
as all the underling calls made on objects in the rx->buf lirc_buffer object
are protected by spinlocks.
Corrected a bad error return value in poll(): return POLLERR instead
of -ENODEV.
Added some comments to poll() for when, in the future, I forget what
poll() and poll_wait() are supposed to do.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 21 ++---
1 files changed, 14 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 720ef67..dfa6a42 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -985,19 +985,26 @@ static unsigned int poll(struct file *filep, poll_table
*wait)
unsigned int ret;
dprintk("poll called\n");
- if (rx == NULL)
- return -ENODEV;
- mutex_lock(&rx->buf_lock);
+ if (rx == NULL) {
+ /*
+* Revisit this, if our poll function ever reports writeable
+* status for Tx
+*/
+ dprintk("poll result = POLLERR\n");
+ return POLLERR;
+ }
+ /*
+* Add our lirc_buffer's wait_queue to the poll_table. A wake up on
+* that buffer's wait queue indicates we may have a new poll status.
+*/
poll_wait(filep, &rx->buf.wait_poll, wait);
- dprintk("poll result = %s\n",
- lirc_buffer_empty(&rx->buf) ? "0" : "POLLIN|POLLRDNORM");
-
+ /* Indicate what ops could happen immediately without blocking */
ret = lirc_buffer_empty(&rx->buf) ? 0 : (POLLIN|POLLRDNORM);
- mutex_unlock(&rx->buf_lock);
+ dprintk("poll result = %s\n", ret ? "POLLIN|POLLRDNORM" : 0);
return ret;
}
--
1.7.2.1
--
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 07/13] lirc_zilog: Remove unneeded rx->buf_lock
Remove the rx->buf_lock that protected the rx->buf lirc_buffer. The
underlying operations on the objects within the lirc_buffer are already
protected by spinlocks, or the objects are constant (e.g. chunk_size).
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 23 +--
1 files changed, 9 insertions(+), 14 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index dfa6a42..0f2fa58 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -67,9 +67,8 @@ struct IR_rx {
/* RX device */
struct i2c_client *c;
- /* RX device buffer & lock */
+ /* RX device buffer */
struct lirc_buffer buf;
- struct mutex buf_lock;
/* RX polling thread data */
struct task_struct *task;
@@ -718,18 +717,15 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
struct IR *ir = filep->private_data;
struct IR_rx *rx = ir->rx;
int ret = 0, written = 0;
+ unsigned int m;
DECLARE_WAITQUEUE(wait, current);
dprintk("read called\n");
if (rx == NULL)
return -ENODEV;
- if (mutex_lock_interruptible(&rx->buf_lock))
- return -ERESTARTSYS;
-
if (n % rx->buf.chunk_size) {
dprintk("read result = -EINVAL\n");
- mutex_unlock(&rx->buf_lock);
return -EINVAL;
}
@@ -767,19 +763,19 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
set_current_state(TASK_INTERRUPTIBLE);
} else {
unsigned char buf[rx->buf.chunk_size];
- lirc_buffer_read(&rx->buf, buf);
- ret = copy_to_user((void *)outbuf+written, buf,
- rx->buf.chunk_size);
- written += rx->buf.chunk_size;
+ m = lirc_buffer_read(&rx->buf, buf);
+ if (m == rx->buf.chunk_size) {
+ ret = copy_to_user((void *)outbuf+written, buf,
+ rx->buf.chunk_size);
+ written += rx->buf.chunk_size;
+ }
}
}
remove_wait_queue(&rx->buf.wait_poll, &wait);
set_current_state(TASK_RUNNING);
- mutex_unlock(&rx->buf_lock);
- dprintk("read result = %s (%d)\n",
- ret ? "-EFAULT" : "OK", ret);
+ dprintk("read result = %d (%s)\n", ret, ret ? "Error" : "OK");
return ret ? ret : written;
}
@@ -1327,7 +1323,6 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
if (ret)
goto out_free_xx;
- mutex_init(&ir->rx->buf_lock);
ir->rx->c = client;
ir->rx->hdpvr_data_fmt =
(id->driver_data & ID_FLAG_HDPVR) ? true : false;
--
1.7.2.1
--
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 08/13] lirc_zilog: Always allocate a Rx lirc_buffer object
Always allocate a lirc_buffer object, instead of just upon setup of
the Rx i2c_client. If we do not allocate a lirc_buffer object, because
we are not handling the Rx i2c_client, lirc_dev will allocate its own
lirc_buffer anyway and not tell us about its location.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 62 ++--
1 files changed, 31 insertions(+), 31 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 0f2fa58..a94b10a 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -67,9 +67,6 @@ struct IR_rx {
/* RX device */
struct i2c_client *c;
- /* RX device buffer */
- struct lirc_buffer buf;
-
/* RX polling thread data */
struct task_struct *task;
@@ -91,6 +88,7 @@ struct IR {
struct list_head list;
struct lirc_driver l;
+ struct lirc_buffer rbuf;
struct mutex ir_lock;
atomic_t open_count;
@@ -157,12 +155,13 @@ static int add_to_buf(struct IR *ir)
int ret;
int failures = 0;
unsigned char sendbuf[1] = { 0 };
+ struct lirc_buffer *rbuf = ir->l.rbuf;
struct IR_rx *rx = ir->rx;
if (rx == NULL)
return -ENXIO;
- if (lirc_buffer_full(&rx->buf)) {
+ if (lirc_buffer_full(rbuf)) {
dprintk("buffer overflow\n");
return -EOVERFLOW;
}
@@ -250,9 +249,9 @@ static int add_to_buf(struct IR *ir)
codes[1] = code & 0xff;
/* return it */
- lirc_buffer_write(&rx->buf, codes);
+ lirc_buffer_write(rbuf, codes);
++got_data;
- } while (!lirc_buffer_full(&rx->buf));
+ } while (!lirc_buffer_full(rbuf));
return 0;
}
@@ -270,7 +269,7 @@ static int add_to_buf(struct IR *ir)
static int lirc_thread(void *arg)
{
struct IR *ir = arg;
- struct IR_rx *rx = ir->rx;
+ struct lirc_buffer *rbuf = ir->l.rbuf;
dprintk("poll thread started\n");
@@ -297,7 +296,7 @@ static int lirc_thread(void *arg)
if (kthread_should_stop())
break;
if (!add_to_buf(ir))
- wake_up_interruptible(&rx->buf.wait_poll);
+ wake_up_interruptible(&rbuf->wait_poll);
}
dprintk("poll thread ended\n");
@@ -716,6 +715,7 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
{
struct IR *ir = filep->private_data;
struct IR_rx *rx = ir->rx;
+ struct lirc_buffer *rbuf = ir->l.rbuf;
int ret = 0, written = 0;
unsigned int m;
DECLARE_WAITQUEUE(wait, current);
@@ -724,7 +724,7 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
if (rx == NULL)
return -ENODEV;
- if (n % rx->buf.chunk_size) {
+ if (n % rbuf->chunk_size) {
dprintk("read result = -EINVAL\n");
return -EINVAL;
}
@@ -734,7 +734,7 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
* to avoid losing scan code (in case when queue is awaken somewhere
* between while condition checking and scheduling)
*/
- add_wait_queue(&rx->buf.wait_poll, &wait);
+ add_wait_queue(&rbuf->wait_poll, &wait);
set_current_state(TASK_INTERRUPTIBLE);
/*
@@ -742,7 +742,7 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
* mode and 'copy_to_user' is happy, wait for data.
*/
while (written < n && ret == 0) {
- if (lirc_buffer_empty(&rx->buf)) {
+ if (lirc_buffer_empty(rbuf)) {
/*
* According to the read(2) man page, 'written' can be
* returned as less than 'n', instead of blocking
@@ -762,17 +762,17 @@ static ssize_t read(struct file *filep, char *outbuf,
size_t n, loff_t *ppos)
schedule();
set_current_state(TASK_INTERRUPTIBLE);
} else {
- unsigned char buf[rx->buf.chunk_size];
- m = lirc_buffer_read(&rx->buf, buf);
- if (m == rx->buf.chunk_size) {
+ unsigned char buf[rbuf->chunk_size];
+ m = lirc_buffer_read(rbuf, buf);
+ if (m == rbuf->chunk_size) {
ret = copy_to_user((void *)outbuf+written, buf,
- rx->buf.chunk_s
[PATCH 09/13] lirc_zilog: Move constants from ir_probe() into the lirc_driver template
ir_probe() makes a number of constant assignments into the lirc_driver
object after copying in a template. Make better use of the template.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 27 +++
1 files changed, 15 insertions(+), 12 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index a94b10a..8ab60e9 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -1116,13 +1116,6 @@ static int close(struct inode *node, struct file *filep)
return 0;
}
-static struct lirc_driver lirc_template = {
- .name = "lirc_zilog",
- .set_use_inc= set_use_inc,
- .set_use_dec= set_use_dec,
- .owner = THIS_MODULE
-};
-
static int ir_remove(struct i2c_client *client);
static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id);
@@ -1161,6 +1154,19 @@ static const struct file_operations lirc_fops = {
.release= close
};
+static struct lirc_driver lirc_template = {
+ .name = "lirc_zilog",
+ .minor = -1,
+ .code_length= 13,
+ .buffer_size= BUFLEN / 2,
+ .sample_rate= 0, /* tell lirc_dev to not start its own kthread */
+ .chunk_size = 2,
+ .set_use_inc= set_use_inc,
+ .set_use_dec= set_use_dec,
+ .fops = &lirc_fops,
+ .owner = THIS_MODULE,
+};
+
static void destroy_rx_kthread(struct IR_rx *rx)
{
/* end up polling thread */
@@ -1292,14 +1298,9 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
/* set lirc_dev stuff */
memcpy(&ir->l, &lirc_template, sizeof(struct lirc_driver));
ir->l.minor = minor; /* module option */
- ir->l.code_length = 13;
- ir->l.chunk_size = 2;
- ir->l.buffer_size = BUFLEN / 2;
ir->l.rbuf= &ir->rbuf;
- ir->l.fops= &lirc_fops;
ir->l.data= ir;
ir->l.dev = &adap->dev;
- ir->l.sample_rate = 0;
ret = lirc_buffer_init(ir->l.rbuf,
ir->l.chunk_size, ir->l.buffer_size);
if (ret)
@@ -1314,6 +1315,7 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
goto out_free_xx;
}
+ ir->l.features |= LIRC_CAN_SEND_PULSE;
ir->tx->c = client;
ir->tx->need_boot = 1;
ir->tx->post_tx_ready_poll =
@@ -1326,6 +1328,7 @@ static int ir_probe(struct i2c_client *client, const
struct i2c_device_id *id)
goto out_free_xx;
}
+ ir->l.features |= LIRC_CAN_REC_LIRCCODE;
ir->rx->c = client;
ir->rx->hdpvr_data_fmt =
(id->driver_data & ID_FLAG_HDPVR) ? true : false;
--
1.7.2.1
--
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 10/13] lirc_zilog: Add ref counting of struct IR, IR_tx, and IR_rx
This is a major change to add pointer reference counting for
struct IR, struct IR_tx, and struct IR_rx object instances.
This ref counting gets lirc_zilog closer to gracefully handling
bridge drivers and hot-unplugged USB devices disappearing out from
under lirc_zilog when the /dev/lircN node is still open. (mutexes
to protect the i2c_client pointers in struct IR_tx and struct IR_rx
still need to be added.)
This reference counting also helps lirc_zilog clean up properly
when the i2c_clients disappear.
Signed-off-by: Andy Walls
---
drivers/staging/lirc/lirc_zilog.c | 582 -
1 files changed, 380 insertions(+), 202 deletions(-)
diff --git a/drivers/staging/lirc/lirc_zilog.c
b/drivers/staging/lirc/lirc_zilog.c
index 8ab60e9..755cb39 100644
--- a/drivers/staging/lirc/lirc_zilog.c
+++ b/drivers/staging/lirc/lirc_zilog.c
@@ -63,8 +63,14 @@
#include
#include
+struct IR;
+
struct IR_rx {
+ struct kref ref;
+ struct IR *ir;
+
/* RX device */
+ /* FIXME mutex lock access to this pointer */
struct i2c_client *c;
/* RX polling thread data */
@@ -76,7 +82,11 @@ struct IR_rx {
};
struct IR_tx {
+ struct kref ref;
+ struct IR *ir;
+
/* TX device */
+ /* FIXME mutex lock access to this pointer */
struct i2c_client *c;
/* TX additional actions needed */
@@ -85,8 +95,10 @@ struct IR_tx {
};
struct IR {
+ struct kref ref;
struct list_head list;
+ /* FIXME spinlock access to l.features */
struct lirc_driver l;
struct lirc_buffer rbuf;
@@ -94,11 +106,21 @@ struct IR {
atomic_t open_count;
struct i2c_adapter *adapter;
+
+ spinlock_t rx_ref_lock; /* struct IR_rx kref get()/put() */
struct IR_rx *rx;
+
+ spinlock_t tx_ref_lock; /* struct IR_tx kref get()/put() */
struct IR_tx *tx;
};
/* IR transceiver instance object list */
+/*
+ * This lock is used for the following:
+ * a. ir_devices_list access, insertions, deletions
+ * b. struct IR kref get()s and put()s
+ * c. serialization of ir_probe() for the two i2c_clients for a Z8
+ */
static DEFINE_MUTEX(ir_devices_lock);
static LIST_HEAD(ir_devices_list);
@@ -146,6 +168,157 @@ static int minor = -1;/* minor number */
## args); \
} while (0)
+
+/* struct IR reference counting */
+static struct IR *get_ir_device(struct IR *ir, bool ir_devices_lock_held)
+{
+ if (ir_devices_lock_held) {
+ kref_get(&ir->ref);
+ } else {
+ mutex_lock(&ir_devices_lock);
+ kref_get(&ir->ref);
+ mutex_unlock(&ir_devices_lock);
+ }
+ return ir;
+}
+
+static void release_ir_device(struct kref *ref)
+{
+ struct IR *ir = container_of(ref, struct IR, ref);
+
+ /*
+* Things should be in this state by now:
+* ir->rx set to NULL and deallocated - happens before ir->rx->ir put()
+* ir->rx->task kthread stopped - happens before ir->rx->ir put()
+* ir->tx set to NULL and deallocated - happens before ir->tx->ir put()
+* ir->open_count == 0 - happens on final close()
+* ir_lock, tx_ref_lock, rx_ref_lock, all released
+*/
+ if (ir->l.minor >= 0 && ir->l.minor < MAX_IRCTL_DEVICES) {
+ lirc_unregister_driver(ir->l.minor);
+ ir->l.minor = MAX_IRCTL_DEVICES;
+ }
+ if (ir->rbuf.fifo_initialized)
+ lirc_buffer_free(&ir->rbuf);
+ list_del(&ir->list);
+ kfree(ir);
+}
+
+static int put_ir_device(struct IR *ir, bool ir_devices_lock_held)
+{
+ int released;
+
+ if (ir_devices_lock_held)
+ return kref_put(&ir->ref, release_ir_device);
+
+ mutex_lock(&ir_devices_lock);
+ released = kref_put(&ir->ref, release_ir_device);
+ mutex_unlock(&ir_devices_lock);
+
+ return released;
+}
+
+/* struct IR_rx reference counting */
+static struct IR_rx *get_ir_rx(struct IR *ir)
+{
+ struct IR_rx *rx;
+
+ spin_lock(&ir->rx_ref_lock);
+ rx = ir->rx;
+ if (rx != NULL)
+ kref_get(&rx->ref);
+ spin_unlock(&ir->rx_ref_lock);
+ return rx;
+}
+
+static void destroy_rx_kthread(struct IR_rx *rx, bool ir_devices_lock_held)
+{
+ /* end up polling thread */
+ if (!IS_ERR_OR_NULL(rx->task)) {
+ kthread_stop(rx->task);
+ rx->task = NULL;
+ /* Put the ir ptr that ir_probe() gave to the rx poll thread */
+ put_ir_device(rx->ir, ir_devices_lock_held);
+ }
+}
+
+static void release_ir_rx(struct kref *ref)
+{
+ struct IR_rx *rx = container_of(ref, struct IR_rx, ref);
+ struct IR *ir = rx->
