Re: [PATCH 15/17] media: st_rc: Don't stay on an IRQ handler forever
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 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 nicest thing to
>>> do :-)
>>>
>>> So, add a timeout there, preventing staying inside the IRQ
>>> for more than 10ms.
>>>
>>> Signed-off-by: Mauro Carvalho Chehab
>>> ---
>>> drivers/media/rc/st_rc.c | 16 ++--
>>> 1 file changed, 10 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
>>> index d2efd7b2c3bc..c855b177103c 100644
>>> --- a/drivers/media/rc/st_rc.c
>>> +++ b/drivers/media/rc/st_rc.c
>>> @@ -96,19 +96,24 @@ static void st_rc_send_lirc_timeout(struct rc_dev *rdev)
>>>
>>> static irqreturn_t st_rc_rx_interrupt(int irq, void *data)
>>> {
>>> + unsigned long timeout;
>>> unsigned int symbol, mark = 0;
>>> struct st_rc_device *dev = data;
>>> int last_symbol = 0;
>>> - u32 status;
>>> + u32 status, int_status;
>>> DEFINE_IR_RAW_EVENT(ev);
>>>
>>> if (dev->irq_wake)
>>> pm_wakeup_event(dev->dev, 0);
>>>
>>> - status = readl(dev->rx_base + IRB_RX_STATUS);
>>> + /* FIXME: is 10ms good enough ? */
>>> + timeout = jiffies + msecs_to_jiffies(10);
>>> + do {
>>> + status = readl(dev->rx_base + IRB_RX_STATUS);
>>> + if (!(status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW)))
>>> + break;
>>>
>>> - while (status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW)) {
>>> - u32 int_status = readl(dev->rx_base + IRB_RX_INT_STATUS);
>>> + int_status = readl(dev->rx_base + IRB_RX_INT_STATUS);
>>> if (unlikely(int_status & IRB_RX_OVERRUN_INT)) {
>>> /* discard the entire collection in case of errors! */
>>> ir_raw_event_reset(dev->rdev);
>>> @@ -148,8 +153,7 @@ static irqreturn_t st_rc_rx_interrupt(int irq, void
>>> *data)
>>>
>>> }
>>> last_symbol = 0;
>>> - status = readl(dev->rx_base + IRB_RX_STATUS);
>>> - }
>>> + } while (time_is_after_jiffies(timeout));
>>>
>>> writel(IRB_RX_INTS, dev->rx_base + IRB_RX_INT_CLEAR);
>>>
>>
>> Isn't this a place where the iopoll.h helpers might be useful?
>>
>> e.g. readl_poll_timeout()
>>
>> https://elixir.bootlin.com/linux/latest/source/include/linux/iopoll.h#L114
>
> That won't work. Internally[1], readx_poll_timeout() calls
> usleep_range().
>
> [1] https://elixir.bootlin.com/linux/latest/source/include/linux/iopoll.h#L43
>
> It can't be called here, as this loop happens at the irq
> handler.
Sorry, I meant readl_poll_timeout_atomic()
But it might have to be open-coded because of the check for overruns.
Regards.
Re: [PATCH 15/17] media: st_rc: Don't stay on an IRQ handler forever
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 nicest thing to
> do :-)
>
> So, add a timeout there, preventing staying inside the IRQ
> for more than 10ms.
>
> Signed-off-by: Mauro Carvalho Chehab
> ---
> drivers/media/rc/st_rc.c | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/media/rc/st_rc.c b/drivers/media/rc/st_rc.c
> index d2efd7b2c3bc..c855b177103c 100644
> --- a/drivers/media/rc/st_rc.c
> +++ b/drivers/media/rc/st_rc.c
> @@ -96,19 +96,24 @@ static void st_rc_send_lirc_timeout(struct rc_dev *rdev)
>
> static irqreturn_t st_rc_rx_interrupt(int irq, void *data)
> {
> + unsigned long timeout;
> unsigned int symbol, mark = 0;
> struct st_rc_device *dev = data;
> int last_symbol = 0;
> - u32 status;
> + u32 status, int_status;
> DEFINE_IR_RAW_EVENT(ev);
>
> if (dev->irq_wake)
> pm_wakeup_event(dev->dev, 0);
>
> - status = readl(dev->rx_base + IRB_RX_STATUS);
> + /* FIXME: is 10ms good enough ? */
> + timeout = jiffies + msecs_to_jiffies(10);
> + do {
> + status = readl(dev->rx_base + IRB_RX_STATUS);
> + if (!(status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW)))
> + break;
>
> - while (status & (IRB_FIFO_NOT_EMPTY | IRB_OVERFLOW)) {
> - u32 int_status = readl(dev->rx_base + IRB_RX_INT_STATUS);
> + int_status = readl(dev->rx_base + IRB_RX_INT_STATUS);
> if (unlikely(int_status & IRB_RX_OVERRUN_INT)) {
> /* discard the entire collection in case of errors! */
> ir_raw_event_reset(dev->rdev);
> @@ -148,8 +153,7 @@ static irqreturn_t st_rc_rx_interrupt(int irq, void *data)
>
> }
> last_symbol = 0;
> - status = readl(dev->rx_base + IRB_RX_STATUS);
> - }
> + } while (time_is_after_jiffies(timeout));
>
> writel(IRB_RX_INTS, dev->rx_base + IRB_RX_INT_CLEAR);
>
Isn't this a place where the iopoll.h helpers might be useful?
e.g. readl_poll_timeout()
https://elixir.bootlin.com/linux/latest/source/include/linux/iopoll.h#L114
Regards.
Re: IR driver support for tango platforms
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 tango_ir_probe() o Rename rc->input_name to rc->device_name (not sure what value to use here) o List all NEC variants for rc->allowed_protocols o Change type of clkrate to u64 o Fix tango_ir_probe and tango_ir_remove for devm o Move around some init calls in tango_ir_probe() for devm o Use relaxed variants of MMIO accessors TODO: test RC-5 and RC-6 (I need to locate proper remote) You could get a IR transmitter (e.g. raspberry pi + IR led + resistor) or some of the mceusb devices, and then you can use the ir-ctl tool to test all the different protocols, including extended rc5 and the other rc6 variants. Thanks for the suggestions. I do have a box full of remote controls, and I'm hoping some of them are RC-5 and RC-6. (Someone told me there is a Sony decoder in the chip, but I have found no documentation whatsoever regarding that feature!) There is an IR transmitter on the board, but I have no driver for it, only a custom test app. So that doesn't help me for ir-ctl... I don't know how much time a driver would require. But I don't think we need to block merging because these protocols haven't been tested. It would be nice though. I'll try my best to test the driver thoroughly. And then I'll send a formal patch. Regards.
Re: IR driver support for tango platforms
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 tango_ir_handle_nec()
o Use devm_rc_allocate_device() in tango_ir_probe()
o Use Use devm_rc_register_device() in tango_ir_probe()
o Rename rc->input_name to rc->device_name (not sure what value to use here)
o List all NEC variants for rc->allowed_protocols
o Change type of clkrate to u64
o Fix tango_ir_probe and tango_ir_remove for devm
o Move around some init calls in tango_ir_probe() for devm
o Use relaxed variants of MMIO accessors
TODO: test RC-5 and RC-6 (I need to locate proper remote)
/*
* Copyright (C) 2015 Mans Rullgard
*
* 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
#include
#include
#include
#include
#include
#include
#include
#define IR_NEC_CTRL 0x00
#define IR_NEC_DATA 0x04
#define IR_CTRL 0x08
#define IR_RC5_CLK_DIV 0x0c
#define IR_RC5_DATA 0x10
#define IR_INT 0x14
#define NEC_TIME_BASE 560
#define RC5_TIME_BASE 1778
#define RC6_CTRL0x00
#define RC6_CLKDIV 0x04
#define RC6_DATA0 0x08
#define RC6_DATA1 0x0c
#define RC6_DATA2 0x10
#define RC6_DATA3 0x14
#define RC6_DATA4 0x18
#define RC6_CARRIER 36000
#define RC6_TIME_BASE 16
struct tango_ir {
void __iomem *rc5_base;
void __iomem *rc6_base;
struct rc_dev *rc;
struct clk *clk;
};
static void tango_ir_handle_nec(struct tango_ir *ir)
{
u32 v, code;
enum rc_proto proto;
v = readl_relaxed(ir->rc5_base + IR_NEC_DATA);
if (!v) {
rc_repeat(ir->rc);
return;
}
code = ir_nec_bytes_to_scancode(v, v >> 8, v >> 16, v >> 24, &proto);
rc_keydown(ir->rc, proto, code, 0);
}
static void tango_ir_handle_rc5(struct tango_ir *ir)
{
u32 data, field, toggle, addr, cmd, code;
data = readl_relaxed(ir->rc5_base + IR_RC5_DATA);
if (data & BIT(31))
return;
field = data >> 12 & 1;
toggle = data >> 11 & 1;
addr = data >> 6 & 0x1f;
cmd = (data & 0x3f) | (field ^ 1) << 6;
code = RC_SCANCODE_RC5(addr, cmd);
rc_keydown(ir->rc, RC_PROTO_RC5, code, toggle);
}
static void tango_ir_handle_rc6(struct tango_ir *ir)
{
u32 data0, data1, toggle, mode, addr, cmd, code;
data0 = readl_relaxed(ir->rc6_base + RC6_DATA0);
data1 = readl_relaxed(ir->rc6_base + RC6_DATA1);
mode = data0 >> 1 & 7;
if (mode != 0)
return;
toggle = data0 & 1;
addr = data0 >> 16;
cmd = data1;
code = RC_SCANCODE_RC6_0(addr, cmd);
rc_keydown(ir->rc, RC_PROTO_RC6_0, code, toggle);
}
static irqreturn_t tango_ir_irq(int irq, void *dev_id)
{
struct tango_ir *ir = dev_id;
unsigned int rc5_stat;
unsigned int rc6_stat;
rc5_stat = readl_relaxed(ir->rc5_base + IR_INT);
writel_relaxed(rc5_stat, ir->rc5_base + IR_INT);
rc6_stat = readl_relaxed(ir->rc6_base + RC6_CTRL);
writel_relaxed(rc6_stat, ir->rc6_base + RC6_CTRL);
if (!(rc5_stat & 3) && !(rc6_stat & BIT(31)))
return IRQ_NONE;
if (rc5_stat & BIT(0))
tango_ir_handle_rc5(ir);
if (rc5_stat & BIT(1))
tango_ir_handle_nec(ir);
if (rc6_stat & BIT(31))
tango_ir_handle_rc6(ir);
return IRQ_HANDLED;
}
#define DISABLE_NEC (BIT(4) | BIT(8))
#define ENABLE_RC5 (BIT(0) | BIT(9))
#define ENABLE_RC6 (BIT(0) | BIT(7))
static int tango_change_protocol(struct rc_dev *dev, u64 *rc_type)
{
struct tango_ir *ir = dev->priv;
u32 rc5_ctrl = DISABLE_NEC;
u32 rc6_ctrl = 0;
if (*rc_type & RC_PROTO_BIT_NEC)
rc5_ctrl = 0;
if (*rc_type & RC_PROTO_BIT_RC5)
rc5_ctrl |= ENABLE_RC5;
if (*rc_type & RC_PROTO_BIT_RC6_0)
rc6_ctrl = ENABLE_RC6;
writel_relaxed_relaxed(rc5_ctrl, ir->rc5_base + IR_CTRL);
writel_relaxed_relaxed(rc6_ctrl, ir->rc6_base + RC6_CTRL);
return 0;
}
static int tango_ir_probe(struct platform_device *pdev)
{
struct device *dev = &pdev->dev;
struct rc_dev *rc;
struct tango_ir *ir;
struct resource *rc5_res;
struct resource *rc6_res;
u64 clkrate, clkdiv;
int irq, err;
rc5_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!rc5_res)
return -EINVAL;
rc6_res = platform_get_
Re: IR driver support for tango platforms
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 matching keycode is required here. B) Currently, the driver doesn't seem to allow selective protocol enabling/disabling. It just silently enables all protocols at init. It would seem useful to add support for that, so that the HW doesn't fire spurious RC5 interrupts for NEC events. What do you think? That could be useful. In order to that, have to implement the rc_dev->change_protocol function; in that function, you have to tell the hardware to not generate interrupts for protocols which aren't disabled. So, in order to implement that you'll need to know how to do that. Is there a datasheet available? I have access to some documentation, but I was told I cannot share it publically :-( I've made some progress. I'd like to run the code by you (and Mans, the original author), to make sure it is in an acceptable state. I tested the driver using ir-keytable and a NEC remote control. (RC-5 and RC-6 are untested, for now.) # ir-keytable -p nec Protocols changed to nec # ir-keytable -c Old keytable cleared # ir-keytable -w sigma.rc Wrote 35 keycode(s) to driver # ir-keytable -r scancode 0x4cb01 = KEY_RIGHT (0x6a) scancode 0x4cb02 = KEY_OK (0x160) scancode 0x4cb03 = KEY_2 (0x03) scancode 0x4cb06 = KEY_UP (0x67) scancode 0x4cb07 = KEY_5 (0x06) scancode 0x4cb0a = KEY_DOWN (0x6c) scancode 0x4cb0f = KEY_SETUP (0x8d) scancode 0x4cb16 = KEY_ANGLE (0x173) scancode 0x4cb17 = KEY_8 (0x09) scancode 0x4cb19 = KEY_ZOOM (0x174) scancode 0x4cb1a = KEY_AUDIO (0x188) scancode 0x4cb1b = KEY_0 (0x0b) scancode 0x4cb1d = KEY_BLUE (0x191) scancode 0x4cb1e = KEY_GREEN (0x18f) scancode 0x4cb41 = KEY_1 (0x02) scancode 0x4cb42 = KEY_3 (0x04) scancode 0x4cb43 = KEY_LEFT (0x69) scancode 0x4cb44 = KEY_EJECTCD (0xa1) scancode 0x4cb45 = KEY_4 (0x05) scancode 0x4cb46 = KEY_6 (0x07) scancode 0x4cb47 = KEY_BACK (0x9e) scancode 0x4cb4a = KEY_POWER (0x74) scancode 0x4cb4b = KEY_INFO (0x166) scancode 0x4cb4c = KEY_STOP (0x80) scancode 0x4cb4f = KEY_TITLE (0x171) scancode 0x4cb50 = KEY_PLAY (0xcf) scancode 0x4cb51 = KEY_MUTE (0x71) scancode 0x4cb53 = KEY_MENU (0x8b) scancode 0x4cb54 = KEY_PAUSE (0x77) scancode 0x4cb55 = KEY_7 (0x08) scancode 0x4cb56 = KEY_9 (0x0a) scancode 0x4cb58 = KEY_SUBTITLE (0x172) scancode 0x4cb59 = KEY_DELETE (0x6f) scancode 0x4cb5c = KEY_YELLOW (0x190) scancode 0x4cb5f = KEY_RED (0x18e) Enabled protocols: nec # ir-keytable -t -v 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/ Parsing uevent /sys/class/rc/rc0/input0/event0/uevent /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-empty /sys/class/rc/rc0/uevent uevent DRV_NAME=tango-ir input device is /dev/input/event0 /sys/class/rc/rc0/protocols protocol rc-5 (disabled) /sys/class/rc/rc0/protocols protocol nec (enabled) /sys/class/rc/rc0/protocols protocol rc-6 (disabled) Opening /dev/input/event0 Input Protocol version: 0x00010001 Testing events. Please, press CTRL-C to abort. 122.327942: event type EV_MSC(0x04): scancode = 0x4cb41 122.327942: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 122.327942: event type EV_SYN(0x00). 122.381794: event type EV_MSC(0x04): scancode = 0x4cb41 122.381794: event type EV_SYN(0x00). 122.489565: event type EV_MSC(0x04): scancode = 0x4cb41 122.489565: event type EV_SYN(0x00). 122.597335: event type EV_MSC(0x04): scancode = 0x4cb41 122.597335: event type EV_SYN(0x00). 122.705110: event type EV_MSC(0x04): scancode = 0x4cb41 122.705110: event type EV_SYN(0x00). 122.812883: event type EV_MSC(0x04): scancode = 0x4cb41 122.812883: event type EV_SYN(0x00). 122.853335: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 122.853335: event type EV_SYN(0x00). 122.920659: event type EV_MSC(0x04): scancode = 0x4cb41 122.920659: event type EV_SYN(0x00). 122.983335: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 122.983335: event type EV_SYN(0x00). 123.028428: event type EV_MSC(0x04): scancode = 0x4cb41 123.028428: event type EV_SYN(0x00). 123.113334: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 123.113334: event type EV_SYN(0x00). 123.24: event type EV_KEY(0x01) key_down: KEY_1(0x0002) 123.24: event type EV_SYN(0x00). 123.28: event type EV_KEY(0x01) key_up: KEY_1(0x0002) 123.28: event type EV_SYN(0x00). 134.743698: event type EV_MSC(0x04): scancode = 0x4cb50 134.743698: event type EV_KEY(0x01) key_down: KEY_PLAY(0x00cf) 134.743698: event type EV_SYN(0x00). 134.797577: event type EV_MSC(0x04): scancode = 0x4cb50 134.79
Duplicated debug message in drivers/media/rc/rc-main.c
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 one of the two debug messages should be deleted? Regards.
IR driver support for tango platforms
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 reports scancode = 0x00
instead of the scancode for the repeated key.
# ir-keytable -t -v
[ 70.561432] show_protocols: allowed - 0x4204, enabled - 0x0
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/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
[ 227.977324] rc_keydown: keycode=0
227.980533: event type EV_MSC(0x04): scancode = 0x4cb41
227.980533: event type EV_SYN(0x00).
228.031069: event type EV_MSC(0x04): scancode = 0x00
228.031069: event type EV_SYN(0x00).
228.138834: event type EV_MSC(0x04): scancode = 0x00
228.138834: event type EV_SYN(0x00).
228.246603: event type EV_MSC(0x04): scancode = 0x00
228.246603: event type EV_SYN(0x00).
228.354373: event type EV_MSC(0x04): scancode = 0x00
228.354373: event type EV_SYN(0x00).
228.462143: event type EV_MSC(0x04): scancode = 0x00
228.462143: event type EV_SYN(0x00).
228.569913: event type EV_MSC(0x04): scancode = 0x00
228.569913: event type EV_SYN(0x00).
This behavior is caused by ir_do_keydown() not recording the keypress
when keycode == KEY_RESERVED
If I apply the following patch, then the repeated scancode works
as I would expect.
--- a/drivers/media/rc/rc-main.c
+++ b/drivers/media/rc/rc-main.c
@@ -687,6 +687,10 @@ void rc_keydown(struct rc_dev *dev, enum rc_type protocol,
u32 scancode, u8 togg
unsigned long flags;
u32 keycode = rc_g_keycode_from_table(dev, scancode);
+ printk("%s: keycode=%x\n", __func__, keycode);
+ if (keycode == KEY_RESERVED)
+ keycode = KEY_UNKNOWN;
+
spin_lock_irqsave(&dev->keylock, flags);
ir_do_keydown(dev, protocol, scancode, keycode, toggle);
# ir-keytable -t -v
[ 68.192161] show_protocols: allowed - 0x4204, enabled - 0x0
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/
Parsing uevent /sys/class/rc/rc0/input0/event0/uevent
/sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13
/sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64
/sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0
Parsing uevent /sys/class/rc/rc0/uevent
/sys/class/rc/rc0/uevent uevent NAME=rc-empty
input device is /dev/input/event0
/sys/class/rc/rc0/protocols protocol rc-5 (disabled)
/sys/class/rc/rc0/protocols protocol nec (disabled)
/sys/class/rc/rc0/protocols protocol rc-6 (disabled)
Opening /dev/input/event0
Input Protocol version: 0x00010001
Testing events. Please, press CTRL-C to abort.
[ 92.739308] rc_keydown: keycode=0
[ 92.742650] tango-ir: key down event, key 0x00f0, protocol 0x0009, scancode
0x0004cb41
92.749621: event type EV_MSC(0x04): scancode = 0x4cb41
92.749621: event type EV_SYN(0x00).
92.792201: event type EV_MSC(0x04): scancode = 0x4cb41
92.792201: event type EV_SYN(0x00).
92.899966: event type EV_MSC(0x04): scancode = 0x4cb41
92.899966: event type EV_SYN(0x00).
93.007734: event type EV_MSC(0x04): scancode = 0x4cb41
93.007734: event type EV_SYN(0x00).
93.115501: event type EV_MSC(0x04): scancode = 0x4cb41
93.115501: event type EV_SYN(0x00).
93.223269: event type EV_MSC(0x04): scancode = 0x4cb41
93.223269: event type EV_SYN(0x00).
93.331039: event type EV_MSC(0x04): scancode = 0x4cb41
93.331039: event type EV_SYN(0x00).
[ 93.600995] keyup key 0x00f0
I'm confused. Does this mean a keymap is mandatory?
I thought it was possible to handle the "scancode to keycode"
stepin user-space?
B) Currently, the driver doesn't seem to allow selective protocol
enabling/disabling. It just silently enables all protocols at init.
It would seem useful to add support for that, so that the HW
doesn't fire spurious RC5 interrupts for NEC events.
What do you think?
Regards.
Archives of previous threads:
https://www.mail-archive.com/linux-media@vger.kernel.org/msg114854.html
https://www.mail-archive.com/linux-media@vger.kernel.org/msg115316.html
Re: Trying to use IR driver for my SoC
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/ >> Event sysfs node is /sys/class/rc/rc0/input0/event0/ >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >> Parsing uevent /sys/class/rc/rc0/uevent >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >> input device is /dev/input/event0 >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >> /sys/class/rc/rc0/protocols protocol nec (disabled) >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) >> Opening /dev/input/event0 >> Input Protocol version: 0x00010001 >> /sys/class/rc/rc0//protocols: Invalid argument >> Couldn't change the IR protocols >> Testing events. Please, press CTRL-C to abort. >> 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 >> 1296.124872: event type EV_SYN(0x00). >> 1296.178753: event type EV_MSC(0x04): scancode = 0x00 >> 1296.178753: event type EV_SYN(0x00). >> 1296.286526: event type EV_MSC(0x04): scancode = 0x00 >> 1296.286526: event type EV_SYN(0x00). >> 1296.394303: event type EV_MSC(0x04): scancode = 0x00 >> 1296.394303: event type EV_SYN(0x00). >> 1296.502081: event type EV_MSC(0x04): scancode = 0x00 >> 1296.502081: event type EV_SYN(0x00). >> 1296.609857: event type EV_MSC(0x04): scancode = 0x00 >> 1296.609857: event type EV_SYN(0x00). >> 1296.717635: event type EV_MSC(0x04): scancode = 0x00 >> 1296.717635: event type EV_SYN(0x00). >> 1296.825412: event type EV_MSC(0x04): scancode = 0x00 >> 1296.825412: event type EV_SYN(0x00). >> 1296.933189: event type EV_MSC(0x04): scancode = 0x00 >> 1296.933189: event type EV_SYN(0x00). >> 1297.040967: event type EV_MSC(0x04): scancode = 0x00 >> 1297.040967: event type EV_SYN(0x00). >> 1297.148745: event type EV_MSC(0x04): scancode = 0x00 >> 1297.148745: event type EV_SYN(0x00). >> 1297.256522: event type EV_MSC(0x04): scancode = 0x00 >> 1297.256522: event type EV_SYN(0x00). >> >> It looks like scancode 0x00 means "REPEAT" ? > > This looks like nec repeat to me; nec repeats are sent every 110ms; > however when a repeat occurs, the driver should call rc_repeat(), > sending a scancode of 0 won't work. IIUC, the driver requires some fixup, to behave as user-space would expect; is that correct? Are you the reviewer for rc drivers? >> And 0x4cb41 would be '1' then? >> >> If I compile the legacy driver (which is much more cryptic) >> it outputs 04 cb 41 be > > ~0xbe = 0x41. The code in tangox_ir_handle_nec() has decoded this > into extended nec (so the driver should send RC_TYPE_NECX), see > https://github.com/mansr/linux-tangox/blob/master/drivers/media/rc/tangox-ir.c#L68 Another required fixup IIUC, right? Thank you so much for all the insight you've provided. Regards.
Re: Infrared support on tango boards
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 "guess" the protocol used, just by
looking at the raw bitstream?
>> Hmmm, I'm missing a step for going from
>> a9 07 00 00 2e 72 0e 00 04 00 04 00 41 cb 04 00
>> |.r..A...|
>> 0010 a9 07 00 00 2e 72 0e 00 00 00 00 00 00 00 00 00
>> |.r..|
>> to
>> 2589.901611: event type EV_MSC(0x04): scancode = 0x4cb41
>> 2589.901611: event type EV_SYN(0x00).
>> (not the same IR frame, BTW)
>
> The first is a hexdump of struct input_event, the second is a pretty
> print of it.
http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input.h#L25
struct input_event {
struct timeval time;
__u16 type;
__u16 code;
__s32 value;
};
Gotcha.
>> Once we have a scancode, there is another translation pass,
>> to the higher-level concept of an actual key, such as "1",
>> which all applications can agree on.
>
> Yep, that's what the keymaps in drivers/media/rc/keymaps/ are for.
Suppose I wrote a keymap "driver" for my remote control,
Does loading a kernel keymap change what is output on
/dev/input/event0 ?
I mean, does the output changes from 'struct input_event'
to input-event-codes? (so 4-byte int?)
Or is that sent on a different dev node?
http://elixir.free-electrons.com/linux/latest/source/include/uapi/linux/input-event-codes.h
>> Back on topic: it seems to me that Linux supports many protocol
>> decoders, including the 3 supported by block A. I am also assuming
>> that IR signals are pretty low bandwidth? Thus, it would appear
>> to make sense to only use block B, to have the widest support.
>
> Absolutely right. That's what the winbond-cir driver does too. However,
> for wakeup from suspend the winbond-cir uses the hardware decoder.
I was later told that the "universal" HW block had not
received extensive testing; and everyone just uses the
NEC/RC5/RC6 block. So I guess I'll forget about the
UIR block for now.
Regards.
Infrared support on tango boards
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, which is then translated to a "scancode" using the appropriate (protocol) decoder, IIUC. How does one know which decoder to use, out of the dozen protocols available? Are there ambiguities such that a bitstream may be valid under two different protocols? Hmmm, I'm missing a step for going from a9 07 00 00 2e 72 0e 00 04 00 04 00 41 cb 04 00 |.r..A...| 0010 a9 07 00 00 2e 72 0e 00 00 00 00 00 00 00 00 00 |.r..| to 2589.901611: event type EV_MSC(0x04): scancode = 0x4cb41 2589.901611: event type EV_SYN(0x00). (not the same IR frame, BTW) Once we have a scancode, there is another translation pass, to the higher-level concept of an actual key, such as "1", which all applications can agree on. On the board I'm working on (Sigma SMP8758) there are two distinct infrared hardware blocks. A) the first block supports 3 protocols in HW (NEC, RC-5, RC-6A) Documentation states: "supports NEC format, RC5 format, RC5 extended format, RC6A format, interrupt driven, contains error detection" B) the second block doesn't understand protocols and only captures raw bitstreams AFAIU. Documentation states: "Support for up to 2 IR sources Contains debounce and noise filter Contains Timestamp mode or Delta mode Scancodes are timestamped Freely user programmable May support any IR protocol or format May support any scan code length Timebase either variable system clock or fixed 27MHz clock Interrupt driven GPIO pin user selectable" Tangent: it seems complicated to use two IR sources concurrently... Wouldn't both receivers capture both sources? Back on topic: it seems to me that Linux supports many protocol decoders, including the 3 supported by block A. I am also assuming that IR signals are pretty low bandwidth? Thus, it would appear to make sense to only use block B, to have the widest support. What do you think? Regards.
Re: Trying to use IR driver for my SoC
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 >>>> 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/ >>>> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >>>> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >>>> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >>>> Parsing uevent /sys/class/rc/rc0/uevent >>>> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >>>> input device is /dev/input/event0 >>>> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >>>> /sys/class/rc/rc0/protocols protocol nec (disabled) >>>> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) >> >> I had overlooked this. Is it expected for these protocols >> to be marked as "disabled"? > > Ah, good point, I forgot about that. :/ > > "ir-keytable -p all -t -v" should enable all protocols and test. After hours of thrashing around, I finally figured out that the IRQ was misconfigured... Doh! Here's the output from pressing '1' for one second on the RC: # cat /dev/input/event0 | hexdump -vC 04 04 00 00 7a 08 07 00 04 00 04 00 41 cb 04 00 |z...A...| 0010 04 04 00 00 7a 08 07 00 00 00 00 00 00 00 00 00 |z...| 0020 04 04 00 00 f4 da 07 00 04 00 04 00 00 00 00 00 || 0030 04 04 00 00 f4 da 07 00 00 00 00 00 00 00 00 00 || 0040 04 04 00 00 f1 7f 09 00 04 00 04 00 00 00 00 00 || 0050 04 04 00 00 f1 7f 09 00 00 00 00 00 00 00 00 00 || 0060 04 04 00 00 f2 24 0b 00 04 00 04 00 00 00 00 00 |.$..| 0070 04 04 00 00 f2 24 0b 00 00 00 00 00 00 00 00 00 |.$..| 0080 04 04 00 00 f3 c9 0c 00 04 00 04 00 00 00 00 00 || 0090 04 04 00 00 f3 c9 0c 00 00 00 00 00 00 00 00 00 || 00a0 04 04 00 00 f6 6e 0e 00 04 00 04 00 00 00 00 00 |.n..| 00b0 04 04 00 00 f6 6e 0e 00 00 00 00 00 00 00 00 00 |.n..| 00c0 05 04 00 00 ba d1 00 00 04 00 04 00 00 00 00 00 || 00d0 05 04 00 00 ba d1 00 00 00 00 00 00 00 00 00 00 || 00e0 05 04 00 00 bb 76 02 00 04 00 04 00 00 00 00 00 |.v..| 00f0 05 04 00 00 bb 76 02 00 00 00 00 00 00 00 00 00 |.v..| 0100 05 04 00 00 bd 1b 04 00 04 00 04 00 00 00 00 00 || 0110 05 04 00 00 bd 1b 04 00 00 00 00 00 00 00 00 00 || 0120 05 04 00 00 be c0 05 00 04 00 04 00 00 00 00 00 || 0130 05 04 00 00 be c0 05 00 00 00 00 00 00 00 00 00 || 0140 05 04 00 00 c2 65 07 00 04 00 04 00 00 00 00 00 |.e..| 0150 05 04 00 00 c2 65 07 00 00 00 00 00 00 00 00 00 |.e..| I'm not sure what these mean. There seems to be some kind of timestamp? And something else? How do I tell which protocol this RC is using? 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/ Event sysfs node is /sys/class/rc/rc0/input0/event0/ Parsing uevent /sys/class/rc/rc0/input0/event0/uevent /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-empty input device is /dev/input/event0 /sys/class/rc/rc0/protocols protocol rc-5 (disabled) /sys/class/rc/rc0/protocols protocol nec (disabled) /sys/class/rc/rc0/protocols protocol rc-6 (disabled) Opening /dev/input/event0 Input Protocol version: 0x00010001 /sys/class/rc/rc0//protocols: Invalid argument Couldn't change the IR protocols Testing events. Please, press CTRL-C to abort. 1296.124872: event type EV_MSC(0x04): scancode = 0x4cb41 1296.124872: event type EV_SYN(0x00). 1296.178753: event type EV_MSC(0x04): scancode = 0x00 1296.178753: event type EV_SYN(0x00). 1296.286526: event type EV_MSC(0x04): scancode = 0x00 1296.286526: event type EV_SYN(0x00). 1296.394303: event type EV_MSC(0x04): scancode = 0x00 1296.394303: event type EV_SYN(0x00). 1296.502081: event type EV_MSC(0x04): scancode = 0x00 1296.502081: event type EV_SYN(0x00). 1296.609857: event type EV_MSC(0x04): scancode = 0x00 1296.609857: event type EV_SYN(0x00). 1296.
Re: Trying to use IR driver for my SoC
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 ms #define RC5_TIME_BASE 1778 (time in microseconds apparently) clkdiv = clkrate * RC5_TIME_BASE / 1e6 = 48006 = 0xbb86 I don't really see the point of reprogramming the default value, though... I'm thinking GPIO directions might be misconfigured, which could explain why no IRQs are firing. Back to basics. Regards.
Re: Trying to use IR driver for my SoC
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/ >> Parsing uevent /sys/class/rc/rc0/input0/event0/uevent >> /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 >> /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 >> /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 >> Parsing uevent /sys/class/rc/rc0/uevent >> /sys/class/rc/rc0/uevent uevent NAME=rc-empty >> input device is /dev/input/event0 >> /sys/class/rc/rc0/protocols protocol rc-5 (disabled) >> /sys/class/rc/rc0/protocols protocol nec (disabled) >> /sys/class/rc/rc0/protocols protocol rc-6 (disabled) I had overlooked this. Is it expected for these protocols to be marked as "disabled"? >> Opening /dev/input/event0 >> Input Protocol version: 0x00010001 >> Testing events. Please, press CTRL-C to abort. >> ^C >> >> Is rc-empty perhaps not the right choice? > > rc-empty means there is no mapping from scancode to keycode. When you > run "ir-keytable -v -t" you should at see scancodes when the driver > generates them with rc_keydown(). So the mapping can be done either in the kernel, or in user-space by the application consuming the scancodes, right? > From a cursory glance at the driver I can't see anything wrong. > > 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. Need to locate some docs. > It might be worth trying nec, rc5 and rc6_0 and seeing if any of them decode. What do you mean? How do I try them? > Failing that some documentation would be great :) I will try finding some. Regards.
Re: Trying to use IR driver for my SoC
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 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 decoders, because the HW is supposed >> to support HW decoding of NEC, RC5, RC6). > > I haven't seen this driver before, what hardware is this for? Sigma Designs tango3/tango4 (SMP86xx and SMP87xx) >> These are the logs printed at boot: >> >> [1.827842] IR NEC protocol handler initialized >> [1.832407] IR RC5(x/sz) protocol handler initialized >> [1.837491] IR RC6 protocol handler initialized >> [1.842049] IR JVC protocol handler initialized >> [1.846606] IR Sony protocol handler initialized >> [1.851248] IR SANYO protocol handler initialized >> [1.855979] IR Sharp protocol handler initialized >> [1.860708] IR MCE Keyboard/mouse protocol handler initialized >> [1.866575] IR XMP protocol handler initialized >> [1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ >> 21 >> [1.878241] Registered IR keymap rc-empty >> [1.882457] input: tango-ir as >> /devices/platform/soc/10518.ir/rc/rc0/input0 >> [1.889473] tango_ir_open >> [1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 >> >> >> I was naively expecting some kind of dev/input/event0 node >> I could cat to grab all the remote control key presses. >> >> But I don't see anything relevant in /dev > > Do you have CONFIG_INPUT_EVDEV set? Is udev setup to create the devices? I was indeed missing CONFIG_INPUT_EVDEV. As for udev: [2.199642] udevd[960]: starting eudev-3.2.1 $ ls -l /dev/input/ total 0 drwxr-xr-x2 root root60 Jan 1 00:00 by-path crw-rw1 root input 13, 64 Jan 1 00:00 event0 But still no cookie: $ cat /dev/input/event0 remains mute :-( $ 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/ Parsing uevent /sys/class/rc/rc0/input0/event0/uevent /sys/class/rc/rc0/input0/event0/uevent uevent MAJOR=13 /sys/class/rc/rc0/input0/event0/uevent uevent MINOR=64 /sys/class/rc/rc0/input0/event0/uevent uevent DEVNAME=input/event0 Parsing uevent /sys/class/rc/rc0/uevent /sys/class/rc/rc0/uevent uevent NAME=rc-empty input device is /dev/input/event0 /sys/class/rc/rc0/protocols protocol rc-5 (disabled) /sys/class/rc/rc0/protocols protocol nec (disabled) /sys/class/rc/rc0/protocols protocol rc-6 (disabled) Opening /dev/input/event0 Input Protocol version: 0x00010001 Testing events. Please, press CTRL-C to abort. ^C Is rc-empty perhaps not the right choice? > By opening the /dev/input/event0 device, tango_ir_open() gets called which > presumably enables interrupts or IR decoding for the device. It's hard to > say without knowing anything about the soc. Actually tango_ir_open() is called at boot, before any process has a chance to open /dev/input/event0 [1.926730] [] (tango_ir_open) from [] (rc_open+0x44/0x6c) [1.933994] [] (rc_open) from [] (input_open_device+0x74/0xac) [1.941610] [] (input_open_device) from [] (kbd_connect+0x64/0x80) [1.949570] [] (kbd_connect) from [] (input_attach_handler+0x1bc/0x1f4) [1.957965] [] (input_attach_handler) from [] (input_register_device+0x3b4/0x42c) [1.967234] [] (input_register_device) from [] (rc_register_device+0x2d8/0x52c) [1.976327] [] (rc_register_device) from [] (tango_ir_probe+0x328/0x3a4) [1.984815] [] (tango_ir_probe) from [] (platform_drv_probe+0x34/0x6c) [1.993124] [] (platform_drv_probe) from [] (really_probe+0x1c4/0x250) But I have a printk in the ISR, and it's obviously not called. > It would be nice to see this driver merged to mainline. +1 (especially if I can get it to work) Regards.
Re: Trying to use IR driver for my SoC
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/class/rc/rc0/input0/event*. Segmentation fault $ ir-keytable --version IR keytable control version 1.12.2 Regards.
Trying to use IR driver for my SoC
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 decoders, because the HW is supposed to support HW decoding of NEC, RC5, RC6). These are the logs printed at boot: [1.827842] IR NEC protocol handler initialized [1.832407] IR RC5(x/sz) protocol handler initialized [1.837491] IR RC6 protocol handler initialized [1.842049] IR JVC protocol handler initialized [1.846606] IR Sony protocol handler initialized [1.851248] IR SANYO protocol handler initialized [1.855979] IR Sharp protocol handler initialized [1.860708] IR MCE Keyboard/mouse protocol handler initialized [1.866575] IR XMP protocol handler initialized [1.871232] tango-ir 10518.ir: SMP86xx IR decoder at 0x10518/0x105e0 IRQ 21 [1.878241] Registered IR keymap rc-empty [1.882457] input: tango-ir as /devices/platform/soc/10518.ir/rc/rc0/input0 [1.889473] tango_ir_open [1.892105] rc rc0: tango-ir as /devices/platform/soc/10518.ir/rc/rc0 I was naively expecting some kind of dev/input/event0 node I could cat to grab all the remote control key presses. But I don't see anything relevant in /dev /sys/devices/platform/soc/10518.ir/rc/rc0/input0$ ls -l total 0 drwxr-xr-x2 root root 0 Jan 1 00:00 capabilities lrwxrwxrwx1 root root 0 Jan 1 00:07 device -> ../../rc0 drwxr-xr-x2 root root 0 Jan 1 00:07 id -r--r--r--1 root root 4096 Jan 1 00:07 modalias -r--r--r--1 root root 4096 Jan 1 00:00 name -r--r--r--1 root root 4096 Jan 1 00:07 phys -r--r--r--1 root root 4096 Jan 1 00:00 properties lrwxrwxrwx1 root root 0 Jan 1 00:07 subsystem -> ../../../../../../../class/input -rw-r--r--1 root root 4096 Jan 1 00:00 uevent -r--r--r--1 root root 4096 Jan 1 00:07 uniq $ cat * cat: read error: Is a directory cat: read error: Is a directory cat: read error: Is a directory input:bvpe-e0,1,4,14,k98,ram4,lsfw tango-ir tango-ir/input0 0 cat: read error: Is a directory PRODUCT=0/0/0/0 NAME="tango-ir" PHYS="tango-ir/input0" PROP=0 EV=100013 KEY=100 0 0 0 0 MSC=10 MODALIAS=input:bvpe-e0,1,4,14,k98,ram4,lsfw The IR interrupt count remains at 0, even I use the RC nearby. (It works in a legacy system, using a different driver.) I suppose I am missing some important piece of the puzzle? I hope someone can point me in the right direction. Regards.
Re: Automatic device driver back-porting with media_build
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 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 everything seems to work. >>> >>> Unfortunately (for me), I've been asked to make this driver work on >>> an ancient 3.4 kernel. >> >> The goal is to allow compilation since 2.6.32, but please notice that >> not all drivers will go that far. Basically, when the backport seems too >> complex, we just remove the driver from the list of drivers that are >> compiled for a given legacy version. >> >> See the file v4l/versions.txt to double-check if the drivers you need >> have such restrictions. I suspect that, in the specific case of >> DVB_USB_DVBSKY, it should compile. > > Whatever options I pick for my 3.4 config, CONFIG_DVB_USB_DVBSKY remains > unset in v4l/.config > > $ grep -r DVB_USB_DVBSKY media_build/v4l/ > media_build/v4l/Kconfig:config DVB_USB_DVBSKY > media_build/v4l/Kconfig.kern: [snip config USB] > media_build/v4l/Kconfig.kern: [snip config I2C] > media_build/v4l/.myconfig:CONFIG_DVB_USB_DVBSKY:= n > media_build/v4l/Makefile.media:obj-$(CONFIG_DVB_USB_DVBSKY) += > dvb-usb-dvbsky.o > media_build/v4l/.config:# CONFIG_DVB_USB_DVBSKY is not set > > I suppose some prerequisite is missing? > Does anything obvious come to mind? > > I've resorted to interrupting the build and changing v4l/.config to > CONFIG_DVB_USB_DVBSKY=m (and the module is correctly built) but this > feels like an unnecessary hack. /tmp/sandbox/media_build$ make allmodconfig didn't add anything on top of what the vanilla 'make' did. $ make menuconfig make -C /tmp/sandbox/media_build/v4l menuconfig make[1]: Entering directory `/tmp/sandbox/media_build/v4l' /tmp/buildroot-2014.05-13/output/build/linux-custom/scripts/kconfig/mconf ./Kconfig ./Kconfig:519: syntax error ./Kconfig:518: unknown option "Say" ./Kconfig:519: unknown option "To" ./Kconfig:520: unknown option "called" ./Kconfig:523: syntax error ./Kconfig:522:warning: multi-line strings not supported ./Kconfig:522: unknown option "If" make[1]: *** [menuconfig] Error 1 make[1]: Leaving directory `/tmp/sandbox/media_build/v4l' make: *** [menuconfig] Error 2 I'll keep poking random knobs. Regards. -- 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: Automatic device driver back-porting with media_build
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://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 everything seems to work. >> >> Unfortunately (for me), I've been asked to make this driver work on >> an ancient 3.4 kernel. > > The goal is to allow compilation since 2.6.32, but please notice that > not all drivers will go that far. Basically, when the backport seems too > complex, we just remove the driver from the list of drivers that are > compiled for a given legacy version. > > See the file v4l/versions.txt to double-check if the drivers you need > have such restrictions. I suspect that, in the specific case of > DVB_USB_DVBSKY, it should compile. Whatever options I pick for my 3.4 config, CONFIG_DVB_USB_DVBSKY remains unset in v4l/.config $ grep -r DVB_USB_DVBSKY media_build/v4l/ media_build/v4l/Kconfig:config DVB_USB_DVBSKY media_build/v4l/Kconfig.kern: [snip config USB] media_build/v4l/Kconfig.kern: [snip config I2C] media_build/v4l/.myconfig:CONFIG_DVB_USB_DVBSKY:= n media_build/v4l/Makefile.media:obj-$(CONFIG_DVB_USB_DVBSKY) += dvb-usb-dvbsky.o media_build/v4l/.config:# CONFIG_DVB_USB_DVBSKY is not set I suppose some prerequisite is missing? Does anything obvious come to mind? I've resorted to interrupting the build and changing v4l/.config to CONFIG_DVB_USB_DVBSKY=m (and the module is correctly built) but this feels like an unnecessary hack. Regards. -- 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: Automatic device driver back-porting with media_build
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 remaining bug reports.
Issue #1
check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED",
"include/asm-generic/io.h");
is definitely incorrect for older kernels.
Issue #2
WARNING: "nsecs_to_jiffies" [/tmp/sandbox/media_build/v4l/gpio-ir-recv.ko]
undefined!
Regards.
--
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: Automatic device driver back-porting with media_build
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 actually use the device. I added a few more modules at random: Module Size Used by dvb_core 73479 0 v4l2_common 1628 0 videodev 111886 1 v4l2_common media 9838 1 videodev rc_dvbsky815 0 rc_core15521 1 rc_dvbsky Probably needs dvb_usb but I don't see it built... $ grep -rn '\' linux/drivers/media/usb/dvb-usb/Makefile:3:obj-$(CONFIG_DVB_USB) += dvb-usb.o v4l/.myconfig:245:CONFIG_DVB_USB := n v4l/Makefile.media:1010:obj-$(CONFIG_DVB_USB) += dvb-usb.o v4l/config-compat.h:548:#undef CONFIG_DVB_USB v4l/.config:183:# CONFIG_DVB_USB is not set (All these files are generated by the build process.) Am I doing something wrong? Regards. -- 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: Automatic device driver back-porting with media_build
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/sandbox/media_build/v4l/gpio-ir-recv.ko] undefined! $ git describe --contains d560fed6abe0f v3.17-rc1~109^2~40 The actual call site was added recently by commit 3fb136f3392d (Hasn't even it linux-stable yet, I only see it in next-20151123) I think a patch is needed for kernels < 3.17 right? Regards. -- 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: Automatic device driver back-porting with media_build
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 WARNING: "of_graph_parse_endpoint" [/tmp/sandbox/media_build/v4l/videodev.ko] undefined! WARNING: "of_get_next_parent" [/tmp/sandbox/media_build/v4l/videodev.ko] undefined! WARNING: "nsecs_to_jiffies" [/tmp/sandbox/media_build/v4l/gpio-ir-recv.ko] undefined! make[2]: Leaving directory `/tmp/sandbox/custom-linux-3.4' ./scripts/rmmod.pl check found 209 modules make[1]: Leaving directory `/tmp/sandbox/media_build/v4l' A few link problems, two from device tree: of_graph_parse_endpoint() commit fd9fdb78a9bf8 of_get_next_parent() was not exported until commit 6695be6863b75 nsecs_to_jiffies() was not exported until commit d560fed6abe0f How would you fix those? I will try building a kernel with CONFIG_OF=n Regards. -- 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: Automatic device driver back-porting with media_build
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:
> (same error with vanilla and custom kernel)
>
> Will look into it. Any idea? :-(
>
> By the way, if I was not clear, I'm cross-compiling for an ARM platform.
>
> CC [M] /tmp/sandbox/media_build/v4l/v4l2-of.o
> /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_csi_bus':
> /tmp/sandbox/media_build/v4l/v4l2-of.c:38:4: error: implicit declaration of
> function 'of_prop_next_u32' [-Werror=implicit-function-declaration]
> lane = of_prop_next_u32(prop, lane, &v);
> ^
of_prop_next_u32() was introduced by commit c541adc637066
$ git describe --contains c541adc637066
v3.5-rc1~176^2~34
So it seems something needs to be done for kernels older than 3.5
I'll hack around it by adding
static inline const __be32 *of_prop_next_u32(struct property *prop,
const __be32 *cur, u32 *pu)
{
return NULL;
}
What's the correct fix?
> /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_link':
> /tmp/sandbox/media_build/v4l/v4l2-of.c:287:24: warning: passing argument 1 of
> 'of_parse_phandle' discards 'const' qualifier from pointer target type
> np = of_parse_phandle(node, "remote-endpoint", 0);
> ^
Commit b8fbdc42c5c5d made the first parameter const.
$ git describe --contains b8fbdc42c5c5d
v3.8-rc1~105^2~13
I suppose I can live with the warning for now.
Regards.
--
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: Automatic device driver back-porting with media_build
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? :-( By the way, if I was not clear, I'm cross-compiling for an ARM platform. CC [M] /tmp/sandbox/media_build/v4l/v4l2-of.o /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_csi_bus': /tmp/sandbox/media_build/v4l/v4l2-of.c:38:4: error: implicit declaration of function 'of_prop_next_u32' [-Werror=implicit-function-declaration] lane = of_prop_next_u32(prop, lane, &v); ^ /tmp/sandbox/media_build/v4l/v4l2-of.c:38:9: warning: assignment makes pointer from integer without a cast lane = of_prop_next_u32(prop, lane, &v); ^ /tmp/sandbox/media_build/v4l/v4l2-of.c:52:13: warning: assignment makes pointer from integer without a cast polarity = of_prop_next_u32(prop, polarity, &v); ^ /tmp/sandbox/media_build/v4l/v4l2-of.c: In function 'v4l2_of_parse_link': /tmp/sandbox/media_build/v4l/v4l2-of.c:287:24: warning: passing argument 1 of 'of_parse_phandle' discards 'const' qualifier from pointer target type np = of_parse_phandle(node, "remote-endpoint", 0); ^ In file included from include/linux/i2c.h:36:0, from /tmp/sandbox/media_build/v4l/compat.h:977, from :0: include/linux/of.h:237:28: note: expected 'struct device_node *' but argument is of type 'const struct device_node *' extern struct device_node *of_parse_phandle(struct device_node *np, ^ cc1: some warnings being treated as errors make[3]: *** [/tmp/sandbox/media_build/v4l/v4l2-of.o] Error 1 make[2]: *** [_module_/tmp/sandbox/media_build/v4l] Error 2 make[2]: Leaving directory `/tmp/sandbox/linux-3.4.39' make[1]: *** [default] Error 2 make[1]: Leaving directory `/tmp/sandbox/media_build/v4l' make: *** [all] Error 2 -- 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: Automatic device driver back-porting with media_build
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 fix the NEED_WRITEL_RELAXED warning, but I don't know Perl.
>>>>
>>>> v4l/scripts/make_config_compat.pl
>>>>
>>>> check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED",
>>>> "include/asm-generic/io.h");
>>>> incorrectly outputs
>>>> #define NEED_WRITEL_RELAXED 1
>>>>
>>>>
>>>> In file included from :0:0:
>>>> /tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed"
>>>> redefined
>>>> #define writel_relaxed writel
>>>> ^
>>>> In file included from include/linux/scatterlist.h:10:0,
>>>> from /tmp/sandbox/media_build/v4l/compat.h:1255,
>>>> from :0:
>>>> /tmp/sandbox/custom-linux-3.4/arch/arm/include/asm/io.h:235:0: note: this
>>>> is the location of the previous definition
>>>> #define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
>>>> ^
>>>>
>>>> Shouldn't the script examine arch/$ARCH/include/asm/io.h instead of
>>>> include/asm-generic/io.h ? (Or perhaps both?)
>>>>
>>>> Does make_config_compat.pl know about ARCH?
>>>
>>> No to both. When you do a "make init" on the Kernel repository, it
>>> will evaluate the ARCH vars.
>>>
>>> This is also needed for the media build to work, as it needs to
>>> check what CONFIG vars are enabled on the targeted Kernel.
>>
>> I downloaded the vanilla version of my custom kernel: linux-3.4.39.tar.xz
>>
>> Even then, NEED_WRITEL_RELAXED is incorrectly defined.
>
> did you run a:
> make allmodconfig
> make init
>
> for the vanilla version? Without that, the symlinks won't appear.
/tmp/sandbox/linux-3.4.39$ make allmodconfig
scripts/kconfig/conf --allmodconfig Kconfig
#
# configuration written to .config
#
/tmp/sandbox/linux-3.4.39$ make menuconfig
scripts/kconfig/mconf Kconfig
.config:25:warning: symbol value '' invalid for PHYS_OFFSET
#
# configuration written to .config
#
*** End of the configuration.
*** Execute 'make' to start the build or try 'make help'.
/tmp/sandbox/linux-3.4.39$ make init
scripts/kconfig/conf --silentoldconfig Kconfig
CHK include/linux/version.h
CHK include/generated/utsrelease.h
make[1]: `include/generated/mach-types.h' is up to date.
CC kernel/bounds.s
GEN include/generated/bounds.h
CC arch/arm/kernel/asm-offsets.s
GEN include/generated/asm-offsets.h
CALL scripts/checksyscalls.sh
CC scripts/mod/empty.o
MKELF scripts/mod/elfconfig.h
HOSTCC scripts/mod/file2alias.o
HOSTCC scripts/mod/modpost.o
HOSTCC scripts/mod/sumversion.o
HOSTLD scripts/mod/modpost
HOSTCC scripts/selinux/genheaders/genheaders
HOSTCC scripts/selinux/mdp/mdp
CC init/main.o
CHK include/generated/compile.h
UPD include/generated/compile.h
CC init/version.o
CC init/do_mounts.o
CC init/do_mounts_initrd.o
LD init/mounts.o
CC init/initramfs.o
CC init/calibrate.o
LD init/built-in.o
cd ../media_build/linux
make tar DIR=/tmp/sandbox/media_tree
make untar
cd ..
make release DIR=/tmp/sandbox/linux-3.4.39
make
make -C ../linux apply_patches
make[2]: Entering directory `/tmp/sandbox/media_build/linux'
Patches for 3.4.39. already applied.
make[2]: Leaving directory `/tmp/sandbox/media_build/linux'
make -C /tmp/sandbox/linux-3.4.39 SUBDIRS=/tmp/sandbox/media_build/v4l modules
make[2]: Entering directory `/tmp/sandbox/linux-3.4.39'
CC [M] /tmp/sandbox/media_build/v4l/altera-lpt.o
In file included from :0:0:
/tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed"
redefined
#define writel_relaxed writel
^
In file included from include/linux/scatterlist.h:10:0,
from /tmp/sandbox/media_build/v4l/compat.h:1255,
from :0:
/tmp/sandbox/linux-3.4.39/arch/arm/include/asm/io.h:235:0: note: this is the
location of the previous definition
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
^
$ grep -rn NEED_WRITEL_RELAXED
v4l/compat.h:1567:#ifdef NEED_WRITEL_RELAXED
v4l/scripts/make_config_compat.pl:667: check_files_for_func("writel_relaxed",
"NEED_WRITEL_RELAXED", "include/asm-generic/io.h");
v4l/config-compat.h:1888:#define NEED_WRITEL_RELAXED 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
Re: Automatic device driver back-porting with media_build
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 = 13
> NAME = Saber-toothed Squirrel
>
> Is it possible that the build process gets confused by the EXTRAVERSION field?
Here's the problem:
v4l/Makefile writes to KERNELRELEASE and v4l/.version
-e 'printf
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
-e '
$$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
$ cat v4l/.version
VERSION=3
PATCHLEVEL:=4
SUBLEVEL:=39
KERNELRELEASE:=3.4.3913
SRCDIR:=/tmp/sandbox/custom-linux-3.4
Then $(MAKE) -C ../linux apply_patches calls
patches_for_kernel.pl 3.4.3913
which computes kernel_version
= 3 << 16 + 4 << 8 + 3913 = 0x031349
which is incorrectly interpreted as kernel 3.19.73
thus the correct patches are not applied.
Trivial patch follows. Will test right away.
Regards.
diff --git a/v4l/Makefile b/v4l/Makefile
index 1542092004fa..9147a98639b7 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -233,9 +233,9 @@ ifneq ($(DIR),)
-e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \
-e 'elsif (/^KERNELSRC\s*:=\s*(\S.*)\n/ ||
/^MAKEARGS\s*:=\s*-C\s*(\S.*)\n/)' \
-e '{ $$o=$$d; $$d=$$1; goto S; }' \
-e '};' \
- -e 'printf
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
+ -e 'printf
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s.%s\n",' \
-e '
$$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
-e 'print "OUTDIR:=$$o\n" if($$o);' \
-e 'print "SRCDIR:=$$d\n";' > $(obj)/.version
@cat .version|grep KERNELRELEASE:|sed s,'KERNELRELEASE:=','Forcing
compiling to version ',
--
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: Automatic device driver back-porting with media_build
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 the specific case of 3.4, it is known
>> to build fine with Kernel linux-3.4.27. See:
>> http://hverkuil.home.xs4all.nl/logs/Wednesday.log
>
> I don't think the network stack is different from vanilla...
>
> I had a different idea:
>
> 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 = 13
> NAME = Saber-toothed Squirrel
>
> Is it possible that the build process gets confused by the EXTRAVERSION field?
Could this be the problem?
(Missing '.' between sublevel and extra)
Although with vanilla kernels, it will print 3.4.39. which is
probably wrong...
diff --git a/v4l/Makefile b/v4l/Makefile
index 1542092004fa..9147a98639b7 100644
--- a/v4l/Makefile
+++ b/v4l/Makefile
@@ -233,9 +233,9 @@ ifneq ($(DIR),)
-e 'elsif (/^EXTRAVERSION\s*=\s*(\S+)\n/){ $$extra=$$1; }' \
-e 'elsif (/^KERNELSRC\s*:=\s*(\S.*)\n/ ||
/^MAKEARGS\s*:=\s*-C\s*(\S.*)\n/)' \
-e '{ $$o=$$d; $$d=$$1; goto S; }' \
-e '};' \
- -e 'printf
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s%s\n",' \
+ -e 'printf
("VERSION=%s\nPATCHLEVEL:=%s\nSUBLEVEL:=%s\nKERNELRELEASE:=%s.%s.%s.%s\n",' \
-e '
$$version,$$level,$$sublevel,$$version,$$level,$$sublevel,$$extra);' \
-e 'print "OUTDIR:=$$o\n" if($$o);' \
-e 'print "SRCDIR:=$$d\n";' > $(obj)/.version
@cat .version|grep KERNELRELEASE:|sed s,'KERNELRELEASE:=','Forcing
compiling to version ',
--
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: Automatic device driver back-porting with media_build
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 linux-3.4.27. See: > http://hverkuil.home.xs4all.nl/logs/Wednesday.log I don't think the network stack is different from vanilla... I had a different idea: 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 = 13 NAME = Saber-toothed Squirrel Is it possible that the build process gets confused by the EXTRAVERSION field? Regards. -- 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: Automatic device driver back-porting with media_build
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_func("writel_relaxed", "NEED_WRITEL_RELAXED",
>> "include/asm-generic/io.h");
>> incorrectly outputs
>> #define NEED_WRITEL_RELAXED 1
>>
>>
>> In file included from :0:0:
>> /tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed"
>> redefined
>> #define writel_relaxed writel
>> ^
>> In file included from include/linux/scatterlist.h:10:0,
>> from /tmp/sandbox/media_build/v4l/compat.h:1255,
>> from :0:
>> /tmp/sandbox/custom-linux-3.4/arch/arm/include/asm/io.h:235:0: note: this is
>> the location of the previous definition
>> #define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
>> ^
>>
>> Shouldn't the script examine arch/$ARCH/include/asm/io.h instead of
>> include/asm-generic/io.h ? (Or perhaps both?)
>>
>> Does make_config_compat.pl know about ARCH?
>
> No to both. When you do a "make init" on the Kernel repository, it
> will evaluate the ARCH vars.
>
> This is also needed for the media build to work, as it needs to
> check what CONFIG vars are enabled on the targeted Kernel.
I downloaded the vanilla version of my custom kernel: linux-3.4.39.tar.xz
Even then, NEED_WRITEL_RELAXED is incorrectly defined.
How do you propose to fix this bug?
$ grep writel_relaxed arch/arm/include/asm/io.h
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
#define writel(v,c) ({ __iowmb(); writel_relaxed(v,c); })
$ grep writel_relaxed arch/x86/include/asm/io.h
$ grep -r writel_relaxed include
> 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 linux-3.4.27. See:
> http://hverkuil.home.xs4all.nl/logs/Wednesday.log
I will keep trying to get something to compile.
Regards.
--
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: Automatic device driver back-porting with media_build
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 version. You're on your own here.
>>
>> #ifdef NEED_KVFREE
>> #include
>> static inline void kvfree(const void *addr)
>> {
>> if (is_vmalloc_addr(addr))
>> vfree(addr);
>> else
>> kfree(addr);
>> }
>> #endif
>>
>> /tmp/sandbox/media_build/v4l/compat.h: In function 'kvfree':
>> /tmp/sandbox/media_build/v4l/compat.h:1631:3: error: implicit declaration of
>> function 'vfree' [-Werror=implicit-function-declaration]
>>vfree(addr);
>>^
>>
>> vfree is declared in linux/vmalloc.h
>>
>> The fix is trivial:
>>
>> diff --git a/v4l/compat.h b/v4l/compat.h
>> index c225c07d6caa..7f3f1d5f9d11 100644
>> --- a/v4l/compat.h
>> +++ b/v4l/compat.h
>> @@ -1625,6 +1625,7 @@ static inline void eth_zero_addr(u8 *addr)
>>
>> #ifdef NEED_KVFREE
>> #include
>> +#include
>> static inline void kvfree(const void *addr)
>> {
>> if (is_vmalloc_addr(addr))
>>
>>
>
> Well, it doesn't hurt to add it to the media_build tree, since
> vmalloc.h exists at least since 2.6.11.
>
> Added upstream.
>
> Did the driver compile fine?
I wanted to fix the NEED_WRITEL_RELAXED warning, but I don't know Perl.
v4l/scripts/make_config_compat.pl
check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED",
"include/asm-generic/io.h");
incorrectly outputs
#define NEED_WRITEL_RELAXED 1
In file included from :0:0:
/tmp/sandbox/media_build/v4l/compat.h:1568:0: warning: "writel_relaxed"
redefined
#define writel_relaxed writel
^
In file included from include/linux/scatterlist.h:10:0,
from /tmp/sandbox/media_build/v4l/compat.h:1255,
from :0:
/tmp/sandbox/custom-linux-3.4/arch/arm/include/asm/io.h:235:0: note: this is
the location of the previous definition
#define writel_relaxed(v,c) ((void)__raw_writel((__force u32) \
^
Shouldn't the script examine arch/$ARCH/include/asm/io.h instead of
include/asm-generic/io.h ? (Or perhaps both?)
Does make_config_compat.pl know about ARCH?
The following patch makes "#define NEED_WRITEL_RELAXED 1" go away,
but I'm looking for a general solution.
The next error is:
CC [M] /tmp/sandbox/media_build/v4l/dvb_net.o
/tmp/sandbox/media_build/v4l/dvb_net.c: In function 'dvb_net_add_if':
/tmp/sandbox/media_build/v4l/dvb_net.c:1244:38: error: macro "alloc_netdev"
passed 4 arguments, but takes just 3
NET_NAME_UNKNOWN, dvb_net_setup);
^
/tmp/sandbox/media_build/v4l/dvb_net.c:1243:8: error: 'alloc_netdev' undeclared
(first use in this function)
net = alloc_netdev(sizeof(struct dvb_net_priv), "dvb",
^
/tmp/sandbox/media_build/v4l/dvb_net.c:1243:8: note: each undeclared identifier
is reported only once for each function it appears in
/tmp/sandbox/media_build/v4l/dvb_net.c: At top level:
/tmp/sandbox/media_build/v4l/dvb_net.c:1205:13: warning: 'dvb_net_setup'
defined but not used [-Wunused-function]
static void dvb_net_setup(struct net_device *dev)
Will look into it.
Regards.
diff --git a/v4l/scripts/make_config_compat.pl
b/v4l/scripts/make_config_compat.pl
index 641f55e9c137..30a004525c08 100644
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -664,7 +664,7 @@ sub check_other_dependencies()
check_files_for_func("DMA_ATTR_SKIP_CPU_SYNC",
"NEED_DMA_ATTR_SKIP_CPU_SYNC", "include/linux/dma-attrs.h");
check_files_for_func("sign_extend32", "NEED_SIGN_EXTEND32",
"include/linux/bitops.h");
check_files_for_func("netdev_dbg", "NEED_NETDEV_DBG",
"include/linux/netdevice.h");
- check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED",
"include/asm-generic/io.h");
+ check_files_for_func("writel_relaxed", "NEED_WRITEL_RELAXED",
"arch/arm/include/asm/io.h");
check_files_for_func("get_user_pages_unlocked",
"NEED_GET_USER_PAGES_UNLOCKED", "include/linux/mm.h");
check_files_for_func("pr_warn_once", "NEED_PR_WARN_ONCE",
"include/linux/printk.h");
check_files_for_func("DIV_ROUND_CLOSEST_ULL",
"NEED_DIV_ROUND_CLOSEST_ULL", "include/linux/kernel.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: Automatic device driver back-porting with media_build
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(addr);
else
kfree(addr);
}
#endif
/tmp/sandbox/media_build/v4l/compat.h: In function 'kvfree':
/tmp/sandbox/media_build/v4l/compat.h:1631:3: error: implicit declaration of
function 'vfree' [-Werror=implicit-function-declaration]
vfree(addr);
^
vfree is declared in linux/vmalloc.h
The fix is trivial:
diff --git a/v4l/compat.h b/v4l/compat.h
index c225c07d6caa..7f3f1d5f9d11 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -1625,6 +1625,7 @@ static inline void eth_zero_addr(u8 *addr)
#ifdef NEED_KVFREE
#include
+#include
static inline void kvfree(const void *addr)
{
if (is_vmalloc_addr(addr))
--
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: Automatic device driver back-porting with media_build
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 device is supported since kernel 3.19
>> and indeed, if I use a 4.1 kernel, I can pick CONFIG_DVB_USB_DVBSKY
>> and everything seems to work.
>>
>> Unfortunately (for me), I've been asked to make this driver work on
>> an ancient 3.4 kernel.
>>
>> The linuxtv article mentions:
>>
>> "Drivers are included in kernel 3.17 (for version 1) and 3.19 (for version
>> 2).
>> They can be built with media_build for older kernels."
>>
>>
>> This seems to imply that I can use the media_build framework to
>> automatically (??) back-port a 3.19 driver to a 3.4 kernel?
>
> "automatically" is a complex word ;)
If I get it working, I think you can even say "auto-magically" ;-)
>> This sounds too good to be true...
>> How far back can I go?
>
> The goal is to allow compilation since 2.6.32, but please notice that
> not all drivers will go that far. Basically, when the backport seems too
> complex, we just remove the driver from the list of drivers that are
> compiled for a given legacy version.
>
> Se the file v4l/versions.txt to double-check if the drivers you need
> have such restrictions. I suspect that, in the specific case of
> DVB_USB_DVBSKY, it should compile.
That is great news.
> That doesn't mean that it was tested there. We don't test those
> backports to check against regressions. We only work, at best
> effort basis, to make them to build. So, use it with your own
> risk. If you find any problems, feel free to send us patches
> fixing it.
My first problem is that compilation fails on the first file ;-)
See attached log.
My steps are:
cd media_build/linux
make tar DIR=/tmp/sandbox/media_tree
make untar
cd ..
make release DIR=/tmp/sandbox/custom-linux-3.4
make
I will investigate and report back.
Regards.
/tmp/sandbox$ cd media_build/linux
/tmp/sandbox/media_build/linux$ make tar DIR=/tmp/sandbox/media_tree
rm -f /tmp/sandbox/media_build/linux/linux-media.tar.bz2
tar cf /tmp/sandbox/media_build/linux/linux-media.tar -C /tmp/sandbox/media_tree sound/pci/bt87x.c mm/frame_vector.c include/linux/mmc/sdio_ids.h include/sound/aci.h include/uapi/linux/usb/video.h include/linux/via-core.h include/linux/ti_wilink_st.h include/linux/dma-buf.h include/linux/fence.h include/linux/of_graph.h include/linux/kconfig.h include/linux/hdmi.h include/linux/compiler-gcc.h include/linux/dma/xilinx_dma.h include/trace/events/v4l2.h include/trace/events/vb2.h include/linux/pci_ids.h include/misc/altera.h include/uapi/linux/lirc.h include/uapi/linux/videodev2.h include/uapi/linux/meye.h include/uapi/linux/ivtv.h include/uapi/linux/ivtvfb.h include/uapi/linux/media.h include/uapi/linux/media-bus-format.h include/uapi/linux/v4l2-dv-timings.h include/uapi/linux/v4l2-controls.h include/uapi/linux/uvcvideo.h include/uapi/linux/vsp1.h include/uapi/linux/xilinx-v4l2-controls.h include/uapi/linux/smiapp.h include/uapi/linux/v4l2-subdev.h include/uapi/linux/v4l2-common.h include/uapi/linux/v4l2-mediabus.h include/linux/fixp-arith.h firmware/av7110/bootcode.bin.ihex firmware/av7110/Boot.S firmware/cpia2/stv0672_vp4.bin.ihex firmware/ihex2fw.c firmware/vicam/firmware.H16 firmware/ttusb-budget/dspbootcode.bin.ihex
git --git-dir /tmp/sandbox/media_tree/.git log --pretty=oneline -n3 |sed -r 's,([\x22]),,g; s,([\x25\x5c]),\1\1,g' >git_log
perl -e 'while (<>) { $a=$1 if (m/^\s*VERSION\s*=\s*(\d+)/); $b=$1 if (m/^\s*PATCHLEVEL\s*=\s*(\d+)/); $c=$1 if (m/^\s*SUBLEVEL\s*=\s*(\d+)/); } printf "#define V4L2_VERSION %d\n", ((($a) << 16) + (($b) << 8) + ($c))' /tmp/sandbox/media_tree/Makefile > kernel_version.h
tar rvf /tmp/sandbox/media_build/linux/linux-media.tar git_log kernel_version.h
git_log
kernel_version.h
for i in drivers/media/ drivers/staging/media/ drivers/misc/altera-stapl/ include/media/ include/dt-bindings/media/ include/linux/platform_data/media/ include/uapi/linux/dvb/; do \
if [ "`echo $i|grep Documentation`" = "" ]; then \
dir="`(cd /tmp/sandbox/media_tree; find $i -type f -name '*.[ch]')`"; \
dir="$dir `(cd /tmp/sandbox/media_tree; find $i -type f -name Makefile)`"; \
dir="$dir `(cd /tmp/sandbox/media_tree; find $i -type f -name Kconfig)`"; \
tar rvf /tmp/sandbox/media_build/linux/linux-media.tar -C /tmp/sandbox/media_tree $dir; \
else \
tar rvf /tmp/sandbox/media_build/linux/linux-media.tar -C /tmp/sandbox/media_tree $i; \
fi; done; bzip2 /tmp/sandbox/me
Automatic device driver back-porting with media_build
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 everything seems to work. Unfortunately (for me), I've been asked to make this driver work on an ancient 3.4 kernel. The linuxtv article mentions: "Drivers are included in kernel 3.17 (for version 1) and 3.19 (for version 2). They can be built with media_build for older kernels." This seems to imply that I can use the media_build framework to automatically (??) back-port a 3.19 driver to a 3.4 kernel? This sounds too good to be true... How far back can I go? http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers I find the instructions not very clear. I have cloned media_tree and media_build. And I have my 3.4 kernel source in a separate "my-linux-3.4" dir. How am I supposed to tell media_build: "hey, the latest drivers are in this "media_tree" dir, I'd like you to compile this one driver for the kernel in this "my-linux-3.4" dir" ? Note that media_build/linux has scripts which reference include/uapi which did not exist yet in 3.4 Anyway, my confusion level is at 11. I'd be very grateful if anyone here can clear some of it! Regards. -- 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] staging/dt3155v4l: use PCI_VENDOR_ID_INTEL
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/drivers/staging/media/dt3155v4l/dt3155v4l.c
index e729e52..ef4e2aa 100644
--- a/drivers/staging/media/dt3155v4l/dt3155v4l.c
+++ b/drivers/staging/media/dt3155v4l/dt3155v4l.c
@@ -31,7 +31,6 @@
#include "dt3155v4l.h"
-#define DT3155_VENDOR_ID 0x8086
#define DT3155_DEVICE_ID 0x1223
/* DT3155_CHUNK_SIZE is 4M (2^22) 8 full size buffers */
@@ -975,7 +974,7 @@ dt3155_remove(struct pci_dev *pdev)
}
static const struct pci_device_id pci_ids[] = {
- { PCI_DEVICE(DT3155_VENDOR_ID, DT3155_DEVICE_ID) },
+ { PCI_DEVICE(PCI_VENDOR_ID_INTEL, DT3155_DEVICE_ID) },
{ 0, /* zero marks the end */ },
};
MODULE_DEVICE_TABLE(pci, pci_ids);
--
1.7.10.4
--
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
Driver for r5u870 USB webcams
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 driver on the internet at http://code.google.com/p/r5u870/ The comment on the website seems to imply the driver has been abandoned by it's original writer. I am wondering if there are any plans to provide support for this hardware via extending another driver or if there are any plans to pull this driver into the kernel. Thanks, Jon -- 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
PCI: make pci_restore_state return void
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/video/cafe_ccic.c |4 +---
drivers/net/myri10ge/myri10ge.c |4 +---
drivers/net/sfc/falcon.c| 25 +
drivers/net/skge.c |4 +---
drivers/net/sky2.c |5 +
drivers/net/wireless/rt2x00/rt2x00pci.c |4 ++--
drivers/pci/pci-driver.c|3 ++-
drivers/pci/pci.c |7 ++-
drivers/scsi/ipr.c |8 +---
drivers/scsi/pmcraid.c |7 +--
drivers/staging/sm7xx/smtcfb.c |2 +-
include/linux/pci.h |8 +++-
sound/pci/cs5535audio/cs5535audio_pm.c |7 +--
13 files changed, 22 insertions(+), 66 deletions(-)
diff --git a/drivers/media/video/cafe_ccic.c b/drivers/media/video/cafe_ccic.c
index 2934770..3e653f3 100644
--- a/drivers/media/video/cafe_ccic.c
+++ b/drivers/media/video/cafe_ccic.c
@@ -2186,9 +2186,7 @@ static int cafe_pci_resume(struct pci_dev *pdev)
struct cafe_camera *cam = to_cam(v4l2_dev);
int ret = 0;
- ret = pci_restore_state(pdev);
- if (ret)
- return ret;
+ pci_restore_state(pdev);
ret = pci_enable_device(pdev);
if (ret) {
diff --git a/drivers/net/myri10ge/myri10ge.c b/drivers/net/myri10ge/myri10ge.c
index 8524cc4..d3c4a37 100644
--- a/drivers/net/myri10ge/myri10ge.c
+++ b/drivers/net/myri10ge/myri10ge.c
@@ -3403,9 +3403,7 @@ static int myri10ge_resume(struct pci_dev *pdev)
return -EIO;
}
- status = pci_restore_state(pdev);
- if (status)
- return status;
+ pci_restore_state(pdev);
status = pci_enable_device(pdev);
if (status) {
diff --git a/drivers/net/sfc/falcon.c b/drivers/net/sfc/falcon.c
index 267019b..1763b9a 100644
--- a/drivers/net/sfc/falcon.c
+++ b/drivers/net/sfc/falcon.c
@@ -1066,22 +1066,9 @@ static int falcon_reset_hw(struct efx_nic *efx, enum
reset_type method)
/* Restore PCI configuration if needed */
if (method == RESET_TYPE_WORLD) {
- if (efx_nic_is_dual_func(efx)) {
- rc = pci_restore_state(nic_data->pci_dev2);
- if (rc) {
- netif_err(efx, drv, efx->net_dev,
- "failed to restore PCI config for "
- "the secondary function\n");
- goto fail3;
- }
- }
- rc = pci_restore_state(efx->pci_dev);
- if (rc) {
- netif_err(efx, drv, efx->net_dev,
- "failed to restore PCI config for the "
- "primary function\n");
- goto fail4;
- }
+ if (efx_nic_is_dual_func(efx))
+ pci_restore_state(nic_data->pci_dev2);
+ pci_restore_state(efx->pci_dev);
netif_dbg(efx, drv, efx->net_dev,
"successfully restored PCI config\n");
}
@@ -1092,7 +1079,7 @@ static int falcon_reset_hw(struct efx_nic *efx, enum
reset_type method)
rc = -ETIMEDOUT;
netif_err(efx, hw, efx->net_dev,
"timed out waiting for hardware reset\n");
- goto fail5;
+ goto fail3;
}
netif_dbg(efx, hw, efx->net_dev, "hardware reset complete\n");
@@ -1100,11 +1087,9 @@ static int falcon_reset_hw(struct efx_nic *efx, enum
reset_type method)
/* pci_save_state() and pci_restore_state() MUST be called in pairs */
fail2:
-fail3:
pci_restore_state(efx->pci_dev);
fail1:
-fail4:
-fail5:
+fail3:
return rc;
}
diff --git a/drivers/net/skge.c b/drivers/net/skge.c
index 220e039..61553af 100644
--- a/drivers/net/skge.c
+++ b/drivers/net/skge.c
@@ -4087,9 +4087,7 @@ static int skge_resume(struct pci_dev *pdev)
if (err)
goto out;
- err = pci_restore_state(pdev);
- if (err)
- goto out;
+ pci_restore_state(pdev);
err = skge_reset(hw);
if (err)
diff --git a/drivers/net/sky2.c b/drivers/net/sky2.c
index d657708..be3aee7 100644
--- a/drivers/net/sky2.c
+++ b/drivers/net/sky2.c
@@ -4969,10 +4969,7 @@ static int sky2_resume(struct pci_dev *pdev)
if (err)
goto out;
- err = pci_restore_state(pdev);
- if (err)
- goto out;
-
+ pci_rest
