On 12/04/2018 17:24, Mauro Carvalho Chehab wrote:
> As warned by smatch:
> drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this loop
> depends on readl() succeeding
>
> If something goes wrong at readl(), the logic will stay there
> inside an IRQ code forever. This is not the nices
On 13/04/2018 11:25, Mauro Carvalho Chehab wrote:
> Em Fri, 13 Apr 2018 11:15:16 +0200
> Mason escreveu:
>
>> On 12/04/2018 17:24, Mauro Carvalho Chehab wrote:
>>
>>> As warned by smatch:
>>> drivers/media/rc/st_rc.c:110 st_rc_rx_interrupt() warn: this
Hello Mauro,
Haven't heard back from you in a while. Maybe someone else can point
out what I'm doing wrong?
On 17/12/2015 13:55, Mauro Carvalho Chehab wrote:
> Mason wrote:
>
>> I have a TechnoTrend TT-TVStick CT2-4400v2 USB tuner, as described here:
>> http:
On 28/12/2015 11:44, Mason wrote:
> Hello Mauro,
>
> Haven't heard back from you in a while. Maybe someone else can point
> out what I'm doing wrong?
>
> On 17/12/2015 13:55, Mauro Carvalho Chehab wrote:
>
>> Mason wrote:
>>
>>> I ha
Hello,
I'm trying to use an IR driver written for my SoC:
https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
I added these options to my defconfig:
+CONFIG_MEDIA_SUPPORT=y
+CONFIG_MEDIA_RC_SUPPORT=y
+CONFIG_RC_DEVICES=y
+CONFIG_IR_TANGO=y
(I don't think I need the RC
On 29/06/2017 17:29, Mason wrote:
> I suppose I am missing some important piece of the puzzle?
> I hope someone can point me in the right direction.
FWIW,
$ ir-keytable -v
Found device /sys/class/rc/rc0/
Input sysfs node is /sys/class/rc/rc0/input0/
Couldn't find any node at /sys/c
Hello,
On 29/06/2017 17:55, Sean Young wrote:
> On Thu, Jun 29, 2017 at 05:29:01PM +0200, Mason wrote:
>
>> I'm trying to use an IR driver written for my SoC:
>> https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
>>
>> I
On 29/06/2017 19:50, Sean Young wrote:
> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
>
>> $ ir-keytable -v -t
>> Found device /sys/class/rc/rc0/
>> Input sysfs node is /sys/class/rc/rc0/input0/
>> Event sysfs node is /sys/class/rc/rc0/input0/event0/
>&
On 29/06/2017 19:50, Sean Young wrote:
> The only thing that stands out is RC5_TIME_BASE. If that is the bit
> length or shortest pulse/space? In the latter case it should be 888 usec.
IR_RC5_DECODER_CLK_DIV
Length of 1 bit of the RC5 code in units of 27 MHz clks
Default value = 0xbb86 => 1.778
On 29/06/2017 21:44, Sean Young wrote:
> On Thu, Jun 29, 2017 at 09:12:48PM +0200, Mason wrote:
>
>> On 29/06/2017 19:50, Sean Young wrote:
>>
>>> On Thu, Jun 29, 2017 at 06:25:55PM +0200, Mason wrote:
>>>
>>>> $ ir-keytable -v -t
>>>> F
Hello,
First of all, let's see if I got this right.
An infrared remote control emits IR pulses to send a bitstream.
This is the "raw" data. The bit sequence depends on the button
being pressed (or released), and the protocol being used, right?
An infrared receiver "captures" this bitstream, whic
On 11/07/2017 21:50, Sean Young wrote:
> On Mon, Jul 10, 2017 at 11:44:08AM +0200, Mason wrote:
>
>> How does one know which decoder to use, out of
>> the dozen protocols available?
>
> Well, that depends on the protocol the remote uses to send.
Is there a way to "g
On 11/07/2017 20:35, Sean Young wrote:
> Mason wrote:
>
>> Repeating the test (pressing '1' for one second) with ir-keytable:
>>
>> # ir-keytable -p all -t -v
>> Found device /sys/class/rc/rc0/
>> Input sysfs node is /sys/class/rc/rc0/input0/
>>
Hello Sean,
After a long hiatus, I can now work again on the IR driver support
for tango platforms. I'm still using this driver:
https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c
There are two nits I'd like to discuss.
A) When I hold a key on the RC, ir-keytable re
Hello,
I enabled all debug messages, and I see:
[1.931214] Allocated space for 1 keycode entries (8 bytes)
[1.936822] Allocated space for 1 keycode entries (8 bytes)
One comes from ir_create_table()
The other from ir_setkeytable()
ir_setkeytable() calls ir_create_table()
It looks like
On 11/09/2017 23:12, Sean Young wrote:
On Sep 11, 2017 at 04:37, Mason wrote:
I'm confused. Does this mean a keymap is mandatory?
I thought it was possible to handle the "scancode to keycode"
step in user-space?
The handling could be better here, but for nec repeats, yes a m
On 12/09/2017 20:19, Sean Young wrote:
It looks great, thanks! I have made some minor points below.
Thanks for having reviewed the driver! :-)
I have now fixed all the points you mentioned.
Changes from v1 to v2:
o Rebase driver on top of linuxtv/master
o Use ir_nec_bytes_to_scancode() in t
On 13/09/2017 16:57, Sean Young wrote:
On Sep 13, 2017 at 16:03, Mason wrote:
Changes from v1 to v2:
o Rebase driver on top of linuxtv/master
o Use ir_nec_bytes_to_scancode() in tango_ir_handle_nec()
o Use devm_rc_allocate_device() in tango_ir_probe()
o Use Use devm_rc_register_device() in
Hello everyone,
I have a TechnoTrend TT-TVStick CT2-4400v2 USB tuner, as described here:
http://linuxtv.org/wiki/index.php/TechnoTrend_TT-TVStick_CT2-4400
According to the article, the device is supported since kernel 3.19
and indeed, if I use a 4.1 kernel, I can pick CONFIG_DVB_USB_DVBSKY
and ev
Hello Mauro,
On 17/12/2015 13:55, Mauro Carvalho Chehab wrote:
> Mason wrote:
>
>> I have a TechnoTrend TT-TVStick CT2-4400v2 USB tuner, as described here:
>> http://linuxtv.org/wiki/index.php/TechnoTrend_TT-TVStick_CT2-4400
>>
>> According to the article, the de
On 17/12/2015 15:08, Mauro Carvalho Chehab wrote:
> Then I guess you're not using vanilla 3.4 Kernel, but some heavily
> modified version. You're on your own here.
#ifdef NEED_KVFREE
#include
static inline void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
vfree(a
On 17/12/2015 15:55, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Dec 2015 15:30:43 +0100
> Mason escreveu:
>
>> On 17/12/2015 15:08, Mauro Carvalho Chehab wrote:
>>
>>> Then I guess you're not using vanilla 3.4 Kernel, but some heavily
>>> modified ve
On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Dec 2015 16:32:54 +0100
> Mason escreveu:
>
>> I wanted to fix the NEED_WRITEL_RELAXED warning, but I don't know Perl.
>>
>> v4l/scripts/make_config_compat.pl
>>
>> check_files_for
On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
> As I said before, heavily patched Kernel. It seems that the network stack
> was updated to some newer version. The media_build backport considers
> only the upstream Kernels. In the specific case of 3.4, it is known
> to build fine with Kernel li
On 17/12/2015 18:03, Mason wrote:
> On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
>
>> As I said before, heavily patched Kernel. It seems that the network stack
>> was updated to some newer version. The media_build backport considers
>> only the upstream Kernels. In
On 17/12/2015 18:03, Mason wrote:
> The media_build process prints:
>
> "Preparing to compile for kernel version 3.4.3913"
>
> In fact, the custom kernel's Makefile contains:
>
> VERSION = 3
> PATCHLEVEL = 4
> SUBLEVEL = 39
> EXTRAVERSION =
On 18/12/2015 11:37, Mauro Carvalho Chehab wrote:
> Em Thu, 17 Dec 2015 17:48:57 +0100
> Mason escreveu:
>
>> On 17/12/2015 17:09, Mauro Carvalho Chehab wrote:
>>> Em Thu, 17 Dec 2015 16:32:54 +0100
>>> Mason escreveu:
>>>
>>>> I wanted to
On 18/12/2015 12:22, Mauro Carvalho Chehab wrote:
> Patch applied.
Great! Thanks.
Using the latest media_build master + my writel_relaxed work-around,
compilation proceeds much further, then dies on device tree stuff:
(same error with vanilla and custom kernel)
Will look into it. Any idea? :-(
On 18/12/2015 13:10, Mason wrote:
> On 18/12/2015 12:22, Mauro Carvalho Chehab wrote:
>
>> Patch applied.
>
> Great! Thanks.
>
> Using the latest media_build master + my writel_relaxed work-around,
> compilation proceeds much further, then dies on device tree stuff:
On 18/12/2015 13:59, Mason wrote: [snip previous work-arounds]
Compilation completes.
make -C /tmp/sandbox/custom-linux-3.4 SUBDIRS=/tmp/sandbox/media_build/v4l
modules
make[2]: Entering directory `/tmp/sandbox/custom-linux-3.4'
Building modules, stage 2.
MODPOST 209 modules
WA
On 18/12/2015 14:40, Mason wrote:
> I will try building a kernel with CONFIG_OF=n
Build works much better with CONFIG_OF=n
I suppose OF support with ancient kernels is untested.
(My setup didn't need it anyway.)
The remaining issue is:
WARNING: "nsecs_to_jiffies" [/tmp/sandb
On 17/12/2015 15:55, Mauro Carvalho Chehab wrote:
> Did the driver compile fine?
Once all the modules finish building, I have many *.ko files in v4l.
I copy them to my target's /lib/modules/3.4.39.13/kernel
and run depmod -a
It seems modprobe rc-dvbsky doesn't bring in all the stuff needed
to a
On 18/12/2015 18:10, Mason wrote:
> Am I doing something wrong?
Yes, I didn't have I2C enabled.
By running 'make menuconfig' in a recent kernel, I could see which
Kconfig options are required to build the dvbsky driver.
Mauro, I hope you'll find time to address my remain
My laptop has the "Ricoh Co., Ltd Visual Communication Camera VGP-VCC7
[R5U870]" webcam. A quick scan of the kernel does not show the USB ID
listed. `lsusb` has it listed as:
Bus 001 Device 005: ID 05ca:183a Ricoh Co., Ltd Visual Communication
Camera VGP-VCC7 [R5U870]
I managed to find a Linux
pci_restore_state only ever returns 0, thus there is no benefit in
having it return any value. Also, a large majority of the callers do
not check the return code of pci_restore_state. Make the
pci_restore_state a void return and avoid the overhead.
Signed-off-by: Jon Mason
---
drivers/media
Use PCI_VENDOR_ID_INTEL instead of creating its own vendor ID #define.
Signed-off-by: Jon Mason
Cc: Mauro Carvalho Chehab
---
drivers/staging/media/dt3155v4l/dt3155v4l.c |3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/staging/media/dt3155v4l/dt3155v4l.c
b
36 matches
Mail list logo
