Re: WPC8769L (WEC1020) support in winbond-cir?
I tried to find the hacked code, but it's not there anymore. I have the docs, through, and a rough idea of what would have to be done in order to support WEC1020 in winbond-cir. I cannot tell when I will be able to put time into this, though :-( Best regards, Juan. 2013/10/17 Tom Gundersen t...@jklm.no: On Wednesday, October 16, 2013, Juan Jesús García de Soria Lucena skanda...@gmail.com wrote: Hi there, 2013/10/15 David Härdeman da...@hardeman.nu IIRC, Juan had a hacked-up version of the winbond-cir driver working on his hardware back in March (the hardware seems similar enough, basically the WEC1022 adds some additional Wake-On-IR functionality...I seem to recall). I did indeed look at this at the time. I still have the hardware, should have the hardware docs somewhere, and can look at where I left that hacked code at the time... I really would have liked to merge in the support for it into winbond-cir, but real life took over. But I think Juan is the one to talk to. I don't have the WEC1020 hardware and I don't have his experience of adding support for it... As I said, I still have the hardware around. I might get some time around this weekend to look at it and come back with at least an idea of what is left to be done. Thanks for taking a look. Cheers, Tom -- :wq -- 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: WPC8769L (WEC1020) support in winbond-cir?
Resending, now making sure I use plain text for the email... Hi there, 2013/10/15 David Härdeman da...@hardeman.nu IIRC, Juan had a hacked-up version of the winbond-cir driver working on his hardware back in March (the hardware seems similar enough, basically the WEC1022 adds some additional Wake-On-IR functionality...I seem to recall). I did indeed look at this at the time. I still have the hardware, should have the hardware docs somewhere, and can look at where I left that hacked code at the time... I really would have liked to merge in the support for it into winbond-cir, but real life took over. But I think Juan is the one to talk to. I don't have the WEC1020 hardware and I don't have his experience of adding support for it... As I said, I still have the hardware around. I might get some time around this weekend to look at it and come back with at least an idea of what is left to be done. Best regards, Juan. :wq -- 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] ite-cir: make IR receive work after resume
Hi Jarod, and thanks for looking at this.
El 09/05/2011 20:28, Jarod Wilson ja...@redhat.com escribió:
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1684,6 +1684,8 @@ static int ite_resume(struct pnp_dev *pdev)
/* wake up the transmitter */
wake_up_interruptible(dev-tx_queue);
} else {
+ /* reinitialize hardware config registers */
+ dev-params.init_hardware(dev);
/* enable the receiver */
dev-params.enable_rx(dev);
}
--
1.7.1
But... wouldn't the hardware initialization be required too if the hardware got
suspended while doing TX? I mean, probably the call to init_hardware() should
be done in any case, just before the if... (forgive me if I'm off target; I'm
looking at the code as I remember it, since I don't have it before me right
now).
Best regards,
Juan
Jesús.N�r��yb�X��ǧv�^�){.n�+{���bj)w* jg��� �ݢj/���z�ޖ��2�ޙ�)ߡ�a���� �G���h��j:+v���w��٥
Re: [PATCH] [media] ite-cir: make IR receive work after resume
Hi again, El lun, 09-05-2011 a las 15:45 -0400, Jarod Wilson escribió: Well, looking at the resume function, I wasn't sure if I wanted to mess with things while it was possibly trying to finish up tx, but upon closer inspection, I don't think we can ever get into the state where we're actually doing anything in the tx handler where it would matter. If dev-transmitting is true and we're actually able to grab the spinlock, it means we're just in the middle of the mdelay for remaining_us, and everything done after that is partially redundant with init_hardware anyway. So yeah, it looks safe to me to just put in the init_hardware unconditionally above the check for dev-transmitting. On a related note though... what are the actual chances that we are suspending in the middle of tx, and what are the chances it would actually be of any use to resume that tx after waking up? So what I'm now thinking is this: add a wait_event_interruptible on tx_ended in the suspend path if dev-transmitting to let tx finish before we suspend. Then in resume, we're never resuming in the middle of tx and the whole conditional goes away. That looks like an approach way nicer than the current one. That way sent codes wouldn't be interrupted during transmission by a concurrent suspend request and, yes, the resume function is more elegant too. Please go ahead with this idea if you wish :-) Best regards, Juan Jesú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: AF9015 Problem
El 30/01/2011 14:03, David Ondracek david.ondra...@gmx.de escribió: Hi there, Hi. I have a problem using my DIGITRADE DVB-T stick, which is marked as fully supported in the wiki. It works fine for a while, but after some time it crashes and I have to reboot and disconnect the stick to make it work again (for a while) The same thing happens to me with two different af9015 tuner sticks, an Avermedia Volar Black and a dual KWorld DVB-T-USB 399U (which happens to have other problems too due to its dual nature not being completely supported). In the end, I had to look for a tuner stick with a different chip set (and that proved to be a challenge itself due to the apparent popularity of af9015 among manufacturers) so that my mythtv rig would be dependable. by looking at the dmesg, I found out a strange thing: an af9013 (yes, THREE at the end) device is recognized and registred also. This is normal. It's a part of the device. An older chip model (demodulator) that got integrated into the more modern af9015 (USB bridge plus demodulator in the same package). is anyone running this device stable and/or have an idea what i could do to get rid of the problem? As I said, I'm unable to do so either. I guess it happens to everybody, but not many people seems to be using it for an intensive PVR setup on Linux. If it's that way, perhaps we should edit the linuxtv wiki pages to include a big fat warning for prospective buyers. Best regards, Juan Jesús. -- :wq -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~anttip/ce6230/
Hi, Antti, 2009/3/25 Antti Palosaari cr...@iki.fi: Hello Mauro, Please pull http://linuxtv.org/hg/~anttip/ce6230/ for the following: zl10353: add support for Intel CE6230 and Intel CE6231 Add driver for Intel CE6230 DVB-T USB2.0 I've modified this code (hacking a little bit blindly) to handle the USB ID of the Avermedia A310 DVB-T tuner integrated in my Acer 6530G laptop. I knew it was based on the intel reference design for CE6230, and I can confirm that it seems to work correctly with the current code, altough I didn't perform extensive tests. w_scan finds the channels and Totem is able to change channels and show TV broadcasts. I'd like to have this USB ID supported out of the box when the driver gets upstream: Bus 003 Device 004: ID 07ca:a310 AVerMedia Technologies, Inc. Best regards, and lots of thanks, Juan Jesus. -- 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
