[PATCH] media: rc: ir-rc6-decoder: enable toggle bit for Kathrein RCU-676 remote

[Matthias Reichl]

The Kathrein RCU-676 remote uses the 32-bit rc6 protocol and toggles
bit 15 (0x8000) on repeated button presses, like MCE remotes.

Add it's customer code 0x8046 to the 32-bit rc6 toggle
handling code to get proper scancodes and toggle reports.

Signed-off-by: Matthias Reichl 
---
Here's the link to the bugreport and discussion:
https://forum.libreelec.tv/thread/13086-get-kathrein-rcu-676-remote-to-work-with-le9/

 drivers/media/rc/ir-rc6-decoder.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/media/rc/ir-rc6-decoder.c 
b/drivers/media/rc/ir-rc6-decoder.c
index 68487ce9f79b..d96aed1343e4 100644
--- a/drivers/media/rc/ir-rc6-decoder.c
+++ b/drivers/media/rc/ir-rc6-decoder.c
@@ -40,6 +40,7 @@
 #define RC6_6A_MCE_TOGGLE_MASK 0x8000  /* for the body bits */
 #define RC6_6A_LCC_MASK0x /* RC6-6A-32 long customer 
code mask */
 #define RC6_6A_MCE_CC  0x800f /* MCE customer code */
+#define RC6_6A_KATHREIN_CC 0x8046 /* Kathrein RCU-676 customer code */
 #ifndef CHAR_BIT
 #define CHAR_BIT 8 /* Normally in  */
 #endif
@@ -242,13 +243,17 @@ static int ir_rc6_decode(struct rc_dev *dev, struct 
ir_raw_event ev)
toggle = 0;
break;
case 32:
-   if ((scancode & RC6_6A_LCC_MASK) == 
RC6_6A_MCE_CC) {
+   switch (scancode & RC6_6A_LCC_MASK) {
+   case RC6_6A_MCE_CC:
+   case RC6_6A_KATHREIN_CC:
protocol = RC_PROTO_RC6_MCE;
toggle = !!(scancode & 
RC6_6A_MCE_TOGGLE_MASK);
scancode &= ~RC6_6A_MCE_TOGGLE_MASK;
-   } else {
+   break;
+   default:
protocol = RC_PROTO_RC6_6A_32;
toggle = 0;
+   break;
}
break;
default:
-- 
2.18.0

Re: [PATCH v3 0/5] Add BPF decoders to ir-keytable

[Matthias Reichl]

Hi Sean,

On Sat, Jul 28, 2018 at 10:29:31AM +0100, Sean Young wrote:
> Hi Hias,
> 
> On Sat, Jul 21, 2018 at 08:13:27PM +0200, Matthias Reichl wrote:
> > Hi Sean,
> > 
> > thanks a lot, this is a really nice new feature!
> 
> Thank you for testing it and finding all those issues, it has become much
> better from your testing.
> 
> > On Fri, Jul 13, 2018 at 03:30:06PM +0100, Sean Young wrote:
> > > Once kernel v4.18 is released with IR BPF decoding, this can be merged
> > > to v4l-utils.
> > > 
> > > The idea is that IR decoders can be written in C, compiled to BPF 
> > > relocatable
> > > object file. Any global variables can overriden, so we can supports lots
> > > of variants of similiar protocols (just like in the lircd.conf file).
> > > 
> > > The existing rc_keymap file format can't be used for variables, so I've
> > > converted the format to toml. An alternative would be to use the existing
> > > lircd.conf file format, but it's a very awkward file to parse in C and it
> > > contains many features which are irrelevant to us.
> > > 
> > > We use libelf to load the bpf relocatable object file.
> > > 
> > > After loading our example grundig keymap with bpf decoder, the output of
> > > ir-keytable is:
> > > 
> > > Found /sys/class/rc/rc0/ (/dev/input/event8) with:
> > > Name: Winbond CIR
> > > Driver: winbond-cir, table: rc-rc6-mce
> > > LIRC device: /dev/lirc0
> > > Attached BPF protocols: grundig
> > > Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo 
> > > mce_kbd rc-6 sharp xmp imon
> > > Enabled protocols: lirc
> > > bus: 25, vendor/product: 10ad:00f1, version: 0x0004
> > > Repeat delay = 500 ms, repeat period = 125 ms
> > > 
> > > Alternatively, you simply specify the path to the object file on the 
> > > command
> > > line:
> > > 
> > > $ ir-keytable -e header_pulse=9000,header_space=4500 -p ./pulse_distance.o
> > > 
> > > Derek, please note that you can now convert the dish lircd.conf to toml
> > > and load the keymap; it should just work. It would be great to have your
> > > feedback, thank you.
> > 
> > I did a few tests with one of my RC-5 remotes, this lircd.conf file
> > https://github.com/PiSupply/JustBoom/blob/master/LIRC/lircd.conf
> > and kernel 4.18-rc5 on RPi2, with the 32bit ARM kernel and
> > gpio-ir-recv, and on LePotato / aarch64 with meson-ir.
> > 
> > lircd2toml.py did a really good job on converting it, the only
> > thing missing was the toggle_bit.
> 
> Right, there was a bug in lirc2html.py. I've added a fix to my bpf branch:
> 
> https://git.linuxtv.org/syoung/v4l-utils.git/log/?h=bpf

Thanks a lot, lircd2toml.py now also seems to detect that the lircd.conf
uses the rc-5 protocol and uses the rc-5 decoder - that's really nice!

> > When testing the converted toml (with "toggle_bit = 11" added
> > and the obvious volume keycode fixes) I noticed a couple of issues:
> > 
> > Buttons seem to be "stuck". The scancode is decoded, key_down
> > event is generated, but after release the key_down events repeat
> > indefinitely - with the built-in rc-5 decoder this works fine.
> > 
> > root@upstream:/home/hias/ir-test# ir-keytable -c -w justboom.toml -t
> > Old keytable cleared
> > Wrote 12 keycode(s) to driver
> > Protocols changed to
> > Loaded BPF protocol manchester
> > Testing events. Please, press CTRL-C to abort.
> > 29.065820: lirc protocol(66): scancode = 0x141b
> > 29.065890: event type EV_MSC(0x04): scancode = 0x141b
> > 29.065890: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 29.065890: event type EV_SYN(0x00).
> > 29.570059: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 29.570059: event type EV_SYN(0x00).
> > 29.710062: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 29.710062: event type EV_SYN(0x00).
> > 29.850057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 29.850057: event type EV_SYN(0x00).
> > 29.990057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 29.990057: event type EV_SYN(0x00).
> > 30.130055: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
> > 30.130055: event type EV_SYN(0x00).
> > ...
> 
> Thanks, I had not seen this yet either. There is a fix here:
> 
> https://www.mail-archive.com/linux-media@vger.kernel.org/msg133813.html

Thanks, the patch seems to fix it, I posted a small nit in the t

Re: [PATCH] media: rc: read out of bounds if bpf reports high protocol number

[Matthias Reichl]

Hi Sean,

On Sat, Jul 28, 2018 at 10:11:15AM +0100, Sean Young wrote:
> The repeat period is read from a static array. If a keydown event is
> reported from bpf with a high protocol number, we read out of bounds. This
> is unlikely to end up with a reasonable repeat period at the best of times,
> in which case no timely key up event is generated.
> 
> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/rc-main.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 2e222d9ee01f..a24850be1f4f 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -679,6 +679,14 @@ static void ir_timer_repeat(struct timer_list *t)
>   spin_unlock_irqrestore(>keylock, flags);
>  }
>  
> +unsigned int repeat_period(int protocol)
> +{
> + if (protocol >= ARRAY_SIZE(protocols))
> + return 100;

100 seems a bit arbitrarily chosen to me. Wouldn't it be better to
(re-)use eg protocols[RC_PROTO_UNKNOWN].repeat_period here?

so long,

Hias

> +
> + return protocols[protocol].repeat_period;
> +}
> +
>  /**
>   * rc_repeat() - signals that a key is still pressed
>   * @dev: the struct rc_dev descriptor of the device
> @@ -691,7 +699,7 @@ void rc_repeat(struct rc_dev *dev)
>  {
>   unsigned long flags;
>   unsigned int timeout = nsecs_to_jiffies(dev->timeout) +
> - msecs_to_jiffies(protocols[dev->last_protocol].repeat_period);
> + msecs_to_jiffies(repeat_period(dev->last_protocol));
>   struct lirc_scancode sc = {
>   .scancode = dev->last_scancode, .rc_proto = dev->last_protocol,
>   .keycode = dev->keypressed ? dev->last_keycode : KEY_RESERVED,
> @@ -803,7 +811,7 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto 
> protocol, u32 scancode,
>  
>   if (dev->keypressed) {
>   dev->keyup_jiffies = jiffies + nsecs_to_jiffies(dev->timeout) +
> - msecs_to_jiffies(protocols[protocol].repeat_period);
> + msecs_to_jiffies(repeat_period(protocol));
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>   }
>   spin_unlock_irqrestore(>keylock, flags);
> -- 
> 2.17.1
> 

Re: Logspam with "two consecutive events of type space" on gpio-ir-recv and meson-ir

[Matthias Reichl]

Hi Sean,

On Wed, Jul 25, 2018 at 09:21:00PM +0100, Sean Young wrote:
> Hi Hias,
> 
> On Sat, Jul 21, 2018 at 09:04:21PM +0200, Matthias Reichl wrote:
> > Hi Sean,
> > 
> > I noticed that on 4.18-rc5 I get dmesg logspam with
> > "rc rc0: two consecutive events of type space" on gpio-ir-recv
> > and meson-ir - mceusb seems to be fine (haven't tested with
> > other IR receivers yet).
> 
> This does not have a proper fix yet, however we have a workaround
> here:
> 
> https://git.linuxtv.org/media_tree.git/commit/?h=fixes=0ca54b29054151b7a52cbb8904732280afe5a302

Ah, thanks a lot for the pointer, must have missed the discussion
and patch on the list.

The workaround looks fine to me and should be good enough for now.

so long,

Hias

Logspam with "two consecutive events of type space" on gpio-ir-recv and meson-ir

[Matthias Reichl]

Hi Sean,

I noticed that on 4.18-rc5 I get dmesg logspam with
"rc rc0: two consecutive events of type space" on gpio-ir-recv
and meson-ir - mceusb seems to be fine (haven't tested with
other IR receivers yet).

With the default, short IR timeout I get these messages on each
IR message, which is rather spammy on longer button presses:

[ 1988.053215] rc rc0: two consecutive events of type space
[ 1988.173189] rc rc0: two consecutive events of type space
[ 1988.283188] rc rc0: two consecutive events of type space
[ 1988.403185] rc rc0: two consecutive events of type space
[ 1988.513193] rc rc0: two consecutive events of type space
[ 1988.623190] rc rc0: two consecutive events of type space
[ 1988.743190] rc rc0: two consecutive events of type space
[ 1988.853193] rc rc0: two consecutive events of type space
[ 1988.973193] rc rc0: two consecutive events of type space
[ 1989.083193] rc rc0: two consecutive events of type space
[ 1989.193196] rc rc0: two consecutive events of type space
[ 1989.313216] rc rc0: two consecutive events of type space
[ 1989.423197] rc rc0: two consecutive events of type space
...

With a longer timeout (eg 125ms and testing with a RC-5 remote) I get
these messages once per button press.

Eg on 2 shorter button presses:
# ir-keytable -t
Testing events. Please, press CTRL-C to abort.
2045.990064: lirc protocol(rc5): scancode = 0x101b
2045.990123: event type EV_MSC(0x04): scancode = 0x101b
2045.990123: event type EV_SYN(0x00).
2046.100077: lirc protocol(rc5): scancode = 0x101b
2046.100126: event type EV_MSC(0x04): scancode = 0x101b
2046.100126: event type EV_SYN(0x00).
2046.230075: lirc protocol(rc5): scancode = 0x101b
2046.230118: event type EV_MSC(0x04): scancode = 0x101b
2046.230118: event type EV_SYN(0x00).
2050.970078: lirc protocol(rc5): scancode = 0x101b toggle=1
2050.970137: event type EV_MSC(0x04): scancode = 0x101b
2050.970137: event type EV_SYN(0x00).
2051.080071: lirc protocol(rc5): scancode = 0x101b toggle=1
2051.080119: event type EV_MSC(0x04): scancode = 0x101b
2051.080119: event type EV_SYN(0x00).
2051.210056: lirc protocol(rc5): scancode = 0x101b toggle=1
2051.210099: event type EV_MSC(0x04): scancode = 0x101b
2051.210099: event type EV_SYN(0x00).

I get this in dmesg:
[ 2045.933635] rc rc0: two consecutive events of type space
[ 2050.923689] rc rc0: two consecutive events of type space

So it looks like that might be a timeout-related issue with
these 2 drivers.

so long,

Hias

Re: [PATCH v3 0/5] Add BPF decoders to ir-keytable

[Matthias Reichl]

Hi Sean,

thanks a lot, this is a really nice new feature!

On Fri, Jul 13, 2018 at 03:30:06PM +0100, Sean Young wrote:
> Once kernel v4.18 is released with IR BPF decoding, this can be merged
> to v4l-utils.
> 
> The idea is that IR decoders can be written in C, compiled to BPF relocatable
> object file. Any global variables can overriden, so we can supports lots
> of variants of similiar protocols (just like in the lircd.conf file).
> 
> The existing rc_keymap file format can't be used for variables, so I've
> converted the format to toml. An alternative would be to use the existing
> lircd.conf file format, but it's a very awkward file to parse in C and it
> contains many features which are irrelevant to us.
> 
> We use libelf to load the bpf relocatable object file.
> 
> After loading our example grundig keymap with bpf decoder, the output of
> ir-keytable is:
> 
> Found /sys/class/rc/rc0/ (/dev/input/event8) with:
> Name: Winbond CIR
> Driver: winbond-cir, table: rc-rc6-mce
> LIRC device: /dev/lirc0
> Attached BPF protocols: grundig
> Supported kernel protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo 
> mce_kbd rc-6 sharp xmp imon
> Enabled protocols: lirc
> bus: 25, vendor/product: 10ad:00f1, version: 0x0004
> Repeat delay = 500 ms, repeat period = 125 ms
> 
> Alternatively, you simply specify the path to the object file on the command
> line:
> 
> $ ir-keytable -e header_pulse=9000,header_space=4500 -p ./pulse_distance.o
> 
> Derek, please note that you can now convert the dish lircd.conf to toml
> and load the keymap; it should just work. It would be great to have your
> feedback, thank you.

I did a few tests with one of my RC-5 remotes, this lircd.conf file
https://github.com/PiSupply/JustBoom/blob/master/LIRC/lircd.conf
and kernel 4.18-rc5 on RPi2, with the 32bit ARM kernel and
gpio-ir-recv, and on LePotato / aarch64 with meson-ir.

lircd2toml.py did a really good job on converting it, the only
thing missing was the toggle_bit.

When testing the converted toml (with "toggle_bit = 11" added
and the obvious volume keycode fixes) I noticed a couple of issues:

Buttons seem to be "stuck". The scancode is decoded, key_down
event is generated, but after release the key_down events repeat
indefinitely - with the built-in rc-5 decoder this works fine.

root@upstream:/home/hias/ir-test# ir-keytable -c -w justboom.toml -t
Old keytable cleared
Wrote 12 keycode(s) to driver
Protocols changed to
Loaded BPF protocol manchester
Testing events. Please, press CTRL-C to abort.
29.065820: lirc protocol(66): scancode = 0x141b
29.065890: event type EV_MSC(0x04): scancode = 0x141b
29.065890: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
29.065890: event type EV_SYN(0x00).
29.570059: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
29.570059: event type EV_SYN(0x00).
29.710062: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
29.710062: event type EV_SYN(0x00).
29.850057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
29.850057: event type EV_SYN(0x00).
29.990057: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
29.990057: event type EV_SYN(0x00).
30.130055: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
30.130055: event type EV_SYN(0x00).
...

Even scancodes, eg KEY_UP / scancode 0x141a, aren't decoded at
all, only odd scancodes work. My guess is the manchester decoder
could have a problem when the last bit is zero and the message
doesn't end with a pulse, but a (rather long) timeout.

(Re-)loading a bpf decoder only works 8 times. The 9th attempt
gives an error message.

# for i in `seq 1 9` ; do ir-keytable -p manchester ; done
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
Loaded BPF protocol manchester
Protocols changed to
failed to create a map: 1 Operation not permitted
Loaded BPF protocol manchester

so long,

Hias

Re: [PATCH v2 2/3] media: dvb: represent min/max/step/tolerance freqs in Hz

[Matthias Schwarzott]

Am 06.07.2018 um 00:59 schrieb Mauro Carvalho Chehab:

Hi Mauro,

I have one comment below.

> Right now, satellite frontend drivers specify frequencies in kHz,
> while terrestrial/cable ones specify in Hz. That's confusing
> for developers.
> 
> However, the main problem is that universal frontends capable
> of handling both satellite and non-satelite delivery systems
> are appearing. We end by needing to hack the drivers in
> order to support such hybrid frontends.
> 
> So, convert everything to specify frontend frequencies in Hz.
> 
> Tested-by: Katsuhiro Suzuki 
> Signed-off-by: Mauro Carvalho Chehab 
> ---

> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index 75e95b56f8b3..3b9dca7d7d02 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
[...]
> @@ -2391,9 +2417,19 @@ static int dvb_frontend_handle_ioctl(struct file *file,
>  
>   case FE_GET_INFO: {
>   struct dvb_frontend_info *info = parg;
> + memset(info, 0, sizeof(*info));
>  
> - memcpy(info, >ops.info, sizeof(struct dvb_frontend_info));
> - dvb_frontend_get_frequency_limits(fe, >frequency_min, 
> >frequency_max);
> + strcpy(info->name, fe->ops.info.name);
> + info->frequency_stepsize = fe->ops.info.frequency_stepsize_hz;
> + info->frequency_tolerance = fe->ops.info.frequency_tolerance_hz;

The variables frequency_stepsize and frequency_tolerance are assigned
again some lines below.

> + info->symbol_rate_min = fe->ops.info.symbol_rate_min;
> + info->symbol_rate_max = fe->ops.info.symbol_rate_max;
> + info->symbol_rate_tolerance = 
> fe->ops.info.symbol_rate_tolerance;
> + info->caps = fe->ops.info.caps;
> + info->frequency_stepsize = dvb_frontend_get_stepsize(fe);
> + dvb_frontend_get_frequency_limits(fe, >frequency_min,
> +   >frequency_max,
> +   >frequency_tolerance);
>  
>   /*
>* Associate the 4 delivery systems supported by DVBv3

Matthias

Re: [PATCH] cx231xx: Increase USB bridge bandwidth

[Matthias Schwarzott]

Am 02.04.2018 um 21:59 schrieb Brad Love:
> The cx231xx USB bridge has issue streaming QAM256 DVB-C channels.
> QAM64 channels were fine, but QAM256 channels produced corrupted
> transport streams.
> 
> cx231xx alt mode 4 does not provide enough bandwidth to acommodate
> QAM256 DVB-C channels, most likely DVB-T2 channels would break up
> as well. Alt mode 5 increases bridge bandwidth to 90Mbps, and
> fixes QAM256 DVB-C streaming.
> 
Hi Brad,

I read through the media commits applied in the last weeks.

This patch looks so simple and yet resolves the (for me) unexplainable
behaviour of the Hauppauge WinTV-HVR-930C-HD. DVB-C reception did only
produce garbage, but the the same demod driver (si2165) does work
perfectly in a PCI device.

Thank you for fixing this issue.

Regards
Matthias

Re: [RFC PATCH v1 0/4] Add BPF decoders to ir-keytable

[Matthias Reichl]

Hi Sean,

On Sat, Jun 02, 2018 at 01:37:54PM +0100, Sean Young wrote:
> This is not ready for merging yet, however while I finish this work I would
> like some feedback and ideas.
> 
> The idea is that IR decoders can be written in C, compiled to BPF relocatable
> object file. Any global variables can overriden, so we can supports lots
> of variants of similiar protocols (just like in the lircd.conf file).
> 
> The existing rc_keymap file format can't be used for variables, so I've
> converted the format to toml. An alternative would be to use the existing
> lircd.conf file format, but it's a very awkward file to parse in C and it
> contains many features which are irrelevant to us.
> 
> We use libelf to load the bpf relocatable object file.
> 
> After loading our example grundig keymap with bpf decoder, the output of
> ir-keytable is:
> 
> Found /sys/class/rc/rc0/ (/dev/input/event8) with:
>   Name: Winbond CIR
>   Driver: winbond-cir, table: rc-rc6-mce
>   lirc device: /dev/lirc0
>   Attached bpf protocols: grundig
>   Supported protocols: lirc rc-5 rc-5-sz jvc sony nec sanyo mce_kbd rc-6 
> sharp xmp imon 
>   Enabled protocols: lirc
>   bus: 25, vendor/product: 10ad:00f1, version: 0x0004
>   Repeat delay = 500 ms, repeat period = 125 ms

I did a few tests with this patch and noticed some issues:

clang didn't find asm/types.h, I'm running Debian Stretch here
and asm isn't in /usr/include but in /usr/include/HOST-TRIPLET
which gcc uses by default, but clang doesn't seem to know about.

With a quick workaround (adding /usr/include/x86_64-linux-gnu/
on x86_64 and /usr/include/aarch64-linux-gnu/) the grundig decoder
built fine both on x86_64 and aarch64 and grundig.o files were
identical. I noticed some pointer arithmetic warnings though:

hias@lepotato:~/install/v4l-utils/git/utils/keytable$ make
Making all in bpf_protocols
make[1]: Entering directory 
'/home/hias/install/v4l-utils/git/utils/keytable/bpf_protocols'
clang -I../../../include -nostdinc -isystem 
/usr/lib/llvm-3.8/bin/../lib/clang/3.8.1/include -I/usr/include 
-I/usr/include/aarch64-linux-gnu -target bpf -O2 -emit-llvm -c grundig.c -o - | 
llc -march=bpf -filetype=obj -o grundig.o
make[1]: Leaving directory 
'/home/hias/install/v4l-utils/git/utils/keytable/bpf_protocols'
make[1]: Entering directory '/home/hias/install/v4l-utils/git/utils/keytable'
  CC   keytable.o
  CC   ir-encode.o
  CC   toml.o
  CC   bpf.o
  CC   bpf_load.o
bpf_load.c: In function ‘parse_relo_and_apply’:
bpf_load.c:192:41: warning: pointer of type ‘void *’ used in arithmetic 
[-Wpointer-arith]
 int32_t *p = (bpf_file->data->d_buf + sym.st_value);
 ^
bpf_load.c: In function ‘load_elf_maps_section’:
bpf_load.c:308:54: warning: pointer of type ‘void *’ used in arithmetic 
[-Wpointer-arith]
   def = (struct bpf_load_map_def *)(data_maps->d_buf + offset);
  ^
  CCLD ir-keytable
make[1]: Leaving directory '/home/hias/install/v4l-utils/git/utils/keytable'

When trying to load the grundig decoder (tested on aarch64 with
a kernel compiled from yesterday's head of bpf-next, commit
bd3a08aaa9a3) I get an "invalid mem access 'map_value_or_null'"
error:

hias@lepotato:~/install/v4l-utils/git/utils/keytable$ sudo ./ir-keytable -c -w 
rc_keymaps_bpf/RP75_LCD.toml
bpf protocols removed
Old keytable cleared
Wrote 40 keycode(s) to driver
header_space (null)
header_pulse 1244
leader_pulse (null)
bpf_load_program() err=13
0: (bf) r6 = r1
1: (b7) r8 = 0
2: (63) *(u32 *)(r10 -4) = r8
3: (bf) r2 = r10
4: (07) r2 += -4
5: (18) r1 = 0x80006960fa00
7: (85) call bpf_map_lookup_elem#1
8: (bf) r7 = r10
9: (07) r7 += -24
10: (1d) if r0 == r8 goto pc+1
 R0=map_value_or_null(id=1,off=0,ks=4,vs=16,imm=0) R6=ctx(id=0,off=0,imm=0) 
R7=fp-24,call_-1 R8=inv0 R10=fp0,call_-1
11: (bf) r7 = r0
12: (7b) *(u64 *)(r10 -16) = r8
13: (7b) *(u64 *)(r10 -24) = r8
14: (61) r1 = *(u32 *)(r6 +0)
15: (18) r3 = 0xff00
17: (bf) r2 = r1
18: (5f) r2 &= r3
19: (15) if r2 == 0x200 goto pc+131
 R0=map_value_or_null(id=1,off=0,ks=4,vs=16,imm=0) 
R1=inv(id=0,umax_value=4294967295,var_off=(0x0; 0x)) 
R2=inv(id=0,umax_value=4278190080,var_off=(0x0; 0xff00)) R3=inv4278190080 
R6=ctx(id=0,off=0,imm=0) R7=map_value_or_null(id=1,off=0,ks=4,vs=16,imm=0) 
R8=inv0 R10=fp0,call_-1 fp-16=0 fp-24=0
20: (57) r1 &= 16777215
21: (61) r3 = *(u32 *)(r7 +4)
R7 invalid mem access 'map_value_or_null'

Not quite sure who's to blame here, clang/llvm, the grundig code or
the loader. Do you have any ideas or hints?

so long,

Hias

Re: [PATCH v4 0/3] IR decoding using BPF

[Matthias Reichl]

Hi Sean,

On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote:
> The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most
> widely used IR protocols, but there are many protocols which are not
> supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes,
> many of which are not supported by rc-core. There is a "long tail" of
> unsupported IR protocols, for which lircd is need to decode the IR .
> 
> IR encoding is done in such a way that some simple circuit can decode it;
> therefore, bpf is ideal.
> 
> In order to support all these protocols, here we have bpf based IR decoding.
> The idea is that user-space can define a decoder in bpf, attach it to
> the rc device through the lirc chardev.
> 
> Separate work is underway to extend ir-keytable to have an extensive library
> of bpf-based decoders, and a much expanded library of rc keymaps.
> 
> Another future application would be to compile IRP[3] to a IR BPF program, and
> so support virtually every remote without having to write a decoder for each.
> It might also be possible to support non-button devices such as analog
> directional pads or air conditioning remote controls and decode the target
> temperature in bpf, and pass that to an input device.

Thanks a lot, this looks like a very interesting feature to me!

Unfortunately I don't have time to test it ATM, but please keep
me posted - also on ir-keytable progress - I'm rather excited
to give it a try.

so long & thanks,

Hias

> 
> Thanks,
> 
> Sean Young
> 
> [1] http://www.hifi-remote.com/wiki/index.php?title=DecodeIR
> [2] https://sourceforge.net/p/lirc-remotes/code/ci/master/tree/remotes/
> [3] http://www.hifi-remote.com/wiki/index.php?title=IRP_Notation
> 
> Changes since v3:
>  - Implemented review comments from Quentin Monnet and Y Song (thanks!)
>  - More helpful and better formatted bpf helper documentation
>  - Changed back to bpf_prog_array rather than open-coded implementation
>  - scancodes can be 64 bit
>  - bpf gets passed values in microseconds, not nanoseconds.
>microseconds is more than than enough (IR receivers support carriers upto
>70kHz, at which point a single period is already 14 microseconds). Also,
>this makes it much more consistent with lirc mode2.
>  - Since it looks much more like lirc mode2, rename the program type to
>BPF_PROG_TYPE_LIRC_MODE2.
>  - Rebased on bpf-next
> 
> Changes since v2:
>  - Fixed locking issues
>  - Improved self-test to cover more cases
>  - Rebased on bpf-next again
> 
> Changes since v1:
>  - Code review comments from Y Song  and
>Randy Dunlap 
>  - Re-wrote sample bpf to be selftest
>  - Renamed RAWIR_DECODER -> RAWIR_EVENT (Kconfig, context, bpf prog type)
>  - Rebase on bpf-next
>  - Introduced bpf_rawir_event context structure with simpler access checking
> 
> Sean Young (3):
>   bpf: bpf_prog_array_copy() should return -ENOENT if exclude_prog not
> found
>   media: rc: introduce BPF_PROG_LIRC_MODE2
>   bpf: add selftest for lirc_mode2 type program
> 
>  drivers/media/rc/Kconfig  |  13 +
>  drivers/media/rc/Makefile |   1 +
>  drivers/media/rc/bpf-lirc.c   | 308 ++
>  drivers/media/rc/lirc_dev.c   |  30 ++
>  drivers/media/rc/rc-core-priv.h   |  22 ++
>  drivers/media/rc/rc-ir-raw.c  |  12 +-
>  include/linux/bpf_rcdev.h |  30 ++
>  include/linux/bpf_types.h |   3 +
>  include/uapi/linux/bpf.h  |  53 ++-
>  kernel/bpf/core.c |  11 +-
>  kernel/bpf/syscall.c  |   7 +
>  kernel/trace/bpf_trace.c  |   2 +
>  tools/bpf/bpftool/prog.c  |   1 +
>  tools/include/uapi/linux/bpf.h|  53 ++-
>  tools/include/uapi/linux/lirc.h   | 217 
>  tools/lib/bpf/libbpf.c|   1 +
>  tools/testing/selftests/bpf/Makefile  |   8 +-
>  tools/testing/selftests/bpf/bpf_helpers.h |   6 +
>  .../testing/selftests/bpf/test_lirc_mode2.sh  |  28 ++
>  .../selftests/bpf/test_lirc_mode2_kern.c  |  23 ++
>  .../selftests/bpf/test_lirc_mode2_user.c  | 154 +
>  21 files changed, 974 insertions(+), 9 deletions(-)
>  create mode 100644 drivers/media/rc/bpf-lirc.c
>  create mode 100644 include/linux/bpf_rcdev.h
>  create mode 100644 tools/include/uapi/linux/lirc.h
>  create mode 100755 tools/testing/selftests/bpf/test_lirc_mode2.sh
>  create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_kern.c
>  create mode 100644 tools/testing/selftests/bpf/test_lirc_mode2_user.c
> 
> -- 
> 2.17.0
> 

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Thu, May 10, 2018 at 01:01:34PM +0200, Matthias Reichl wrote:
> On Wed, May 09, 2018 at 10:44:42PM +0100, Sean Young wrote:
> > On Mon, May 07, 2018 at 05:54:55PM +0200, Matthias Reichl wrote:
> > > The original reporter gave up before I could get enough info
> > > to understand what's going on, but now another user with an identical
> > > receiver and the same problems showed up and I could get debug logs.
> > > 
> > > FYI: I've uploaded the full dmesg here if you need more info
> > > or I snipped off too much:
> > > http://www.horus.com/~hias/tmp/mceusb-settimeout-issue.txt
> > > 
> > > Here's the info about the IR receiver:
> > > [2.208684] usb 1-1.3: New USB device found, idVendor=1784, 
> > > idProduct=0011
> > > [2.208699] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
> > > SerialNumber=3
> > > [2.208708] usb 1-1.3: Product: eHome Infrared Transceiver
> > > [2.208716] usb 1-1.3: Manufacturer: Topseed Technology Corp.
> > > [2.208724] usb 1-1.3: SerialNumber: EID0137AG-8-104054
> >
> > I think that is correct. For this mceusb device, we should add a quirk
> > which disables the setting of a timeout.
> > 
> > I do wonder if this could work in a slightly different way. Since the
> > device sends out space information before the timeout (every ~6ms), rather
> > than relying on setting a timeout on the device, we could rely on a 
> > software timeout handler. It would not be able to set timeouts > 100ms
> > but we're mostly not interested in that anyway.
> 
> Ah, this is a very good idea!
> 
> I had thought about a quirk to use that device in the old, fixed 100ms,
> timeout mode but if we can do <= 100ms in software it's a far
> better and elegant solution.
> 
> The patch looks fine to me, I'll add it to our builds and see if
> I can get some feedback on it.

The user with the Topseed remote reported back, your patch fixed
the issue - thanks a lot!

so long,

Hias

> > Here is a patch which hopefully solves it.
> > 
> > Thank you!
> > 
> > Sean
> > 
> > >>From 075e1567851ebe3e9d36b30f436c9468fd8772a8 Mon Sep 17 00:00:00 2001
> > From: Sean Young <s...@mess.org>
> > Date: Wed, 9 May 2018 11:11:28 +0100
> > Subject: [PATCH] media: mceusb: MCE_CMD_SETIRTIMEOUT cause strange behaviour
> >  on device
> > 
> > If the IR timeout is set on vid 1784 pid 0011, the device starts
> > behaving strangely.
> > 
> > Reported-by: Matthias Reichl <h...@horus.com>
> > Signed-off-by: Sean Young <s...@mess.org>
> > ---
> >  drivers/media/rc/mceusb.c | 22 +++---
> >  1 file changed, 19 insertions(+), 3 deletions(-)
> > 
> > diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> > index 5c0bf61fae26..1619b748469b 100644
> > --- a/drivers/media/rc/mceusb.c
> > +++ b/drivers/media/rc/mceusb.c
> > @@ -181,6 +181,7 @@ enum mceusb_model_type {
> > MCE_GEN2 = 0,   /* Most boards */
> > MCE_GEN1,
> > MCE_GEN3,
> > +   MCE_GEN3_BROKEN_IRTIMEOUT,
> > MCE_GEN2_TX_INV,
> > MCE_GEN2_TX_INV_RX_GOOD,
> > POLARIS_EVK,
> > @@ -199,6 +200,7 @@ struct mceusb_model {
> > u32 mce_gen3:1;
> > u32 tx_mask_normal:1;
> > u32 no_tx:1;
> > +   u32 broken_irtimeout:1;
> > /*
> >  * 2nd IR receiver (short-range, wideband) for learning mode:
> >  * 0, absent 2nd receiver (rx2)
> > @@ -242,6 +244,12 @@ static const struct mceusb_model mceusb_model[] = {
> > .tx_mask_normal = 1,
> > .rx2 = 2,
> > },
> > +   [MCE_GEN3_BROKEN_IRTIMEOUT] = {
> > +   .mce_gen3 = 1,
> > +   .tx_mask_normal = 1,
> > +   .rx2 = 2,
> > +   .broken_irtimeout = 1
> > +   },
> > [POLARIS_EVK] = {
> > /*
> >  * In fact, the EVK is shipped without
> > @@ -352,7 +360,7 @@ static const struct usb_device_id mceusb_dev_table[] = {
> >   .driver_info = MCE_GEN2_TX_INV },
> > /* Topseed eHome Infrared Transceiver */
> > { USB_DEVICE(VENDOR_TOPSEED, 0x0011),
> > - .driver_info = MCE_GEN3 },
> > + .driver_info = MCE_GEN3_BROKEN_IRTIMEOUT },
> > /* Ricavision internal Infrared Transceiver */
> > { USB_DEVICE(VENDOR_RICAVISION, 0x0010) },
> > /* Itron ione Libra Q-11 */
> > @@ -1441,8 +1449,16 @@ static struct rc_dev *mceusb_init_rc_dev(struct 
> > mceusb_dev *ir)
> > rc->allowed_pr

Re: [PATCH 1/3] media: mceusb: filter out bogus timing irdata of duration 0

[Matthias Reichl]

Hi Sean,

On Fri, May 11, 2018 at 09:36:48AM +0100, Sean Young wrote:
> A mceusb device has been observed producing invalid irdata. Proactively
> guard against this.

Thanks a lot, the patch series looks good to me! Good catch on the
missing break BTW.

We've included this patch in LibreELEC testbuilds, so far we got
not complaints.

so long,

Hias

> 
> Suggested-by: Matthias Reichl <h...@horus.com>
> Signed-off-by: Sean Young <s...@mess.org>
> ---
>  drivers/media/rc/mceusb.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index 1619b748469b..1ca49491abc8 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -1177,6 +1177,11 @@ static void mceusb_process_ir_data(struct mceusb_dev 
> *ir, int buf_len)
>   init_ir_raw_event();
>   rawir.pulse = ((ir->buf_in[i] & MCE_PULSE_BIT) != 0);
>   rawir.duration = (ir->buf_in[i] & MCE_PULSE_MASK);
> + if (unlikely(!rawir.duration)) {
> + dev_warn(ir->dev, "nonsensical irdata %02x with 
> duration 0",
> +  ir->buf_in[i]);
> + break;
> + }
>   if (rawir.pulse) {
>   ir->pulse_tunit += rawir.duration;
>   ir->pulse_count++;
> -- 
> 2.14.3
> 

[PATCH] media: rc: ite-cir: lower timeout and extend allowed timeout range

[Matthias Reichl]

The minimum possible timeout of ite-cir is 8 samples, which is
typically about 70us. The driver however changes the FIFO trigger
level from the hardware's default of 1 byte to 17 bytes, so the minimum
usable timeout value is 17 * 8 samples, which is typically about 1.2ms.

Tests showed that using timeouts down to 1.2ms actually work fine.

The current default timeout of 200ms is much longer than necessary and
the maximum timeout of 1s seems to have been chosen a bit arbitrarily.

So change the minimum timeout to the driver's limit of 17 * 8 samples
and bring timeout and maximum timeout in line with the settings
of many other receivers.

Signed-off-by: Matthias Reichl <h...@horus.com>
---
 drivers/media/rc/ite-cir.c | 8 +---
 drivers/media/rc/ite-cir.h | 7 ---
 2 files changed, 5 insertions(+), 10 deletions(-)

diff --git a/drivers/media/rc/ite-cir.c b/drivers/media/rc/ite-cir.c
index 65e104c7ddfc..de77d22c30a7 100644
--- a/drivers/media/rc/ite-cir.c
+++ b/drivers/media/rc/ite-cir.c
@@ -1561,9 +1561,11 @@ static int ite_probe(struct pnp_dev *pdev, const struct 
pnp_device_id
rdev->close = ite_close;
rdev->s_idle = ite_s_idle;
rdev->s_rx_carrier_range = ite_set_rx_carrier_range;
-   rdev->min_timeout = ITE_MIN_IDLE_TIMEOUT;
-   rdev->max_timeout = ITE_MAX_IDLE_TIMEOUT;
-   rdev->timeout = ITE_IDLE_TIMEOUT;
+   /* FIFO threshold is 17 bytes, so 17 * 8 samples minimum */
+   rdev->min_timeout = 17 * 8 * ITE_BAUDRATE_DIVISOR *
+   itdev->params.sample_period;
+   rdev->timeout = IR_DEFAULT_TIMEOUT;
+   rdev->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
rdev->rx_resolution = ITE_BAUDRATE_DIVISOR *
itdev->params.sample_period;
rdev->tx_resolution = ITE_BAUDRATE_DIVISOR *
diff --git a/drivers/media/rc/ite-cir.h b/drivers/media/rc/ite-cir.h
index 0e8ebc880d1f..9cb24ac01350 100644
--- a/drivers/media/rc/ite-cir.h
+++ b/drivers/media/rc/ite-cir.h
@@ -154,13 +154,6 @@ struct ite_dev {
 /* default carrier freq for when demodulator is off (Hz) */
 #define ITE_DEFAULT_CARRIER_FREQ   38000
 
-/* default idling timeout in ns (0.2 seconds) */
-#define ITE_IDLE_TIMEOUT   2UL
-
-/* limit timeout values */
-#define ITE_MIN_IDLE_TIMEOUT   1UL
-#define ITE_MAX_IDLE_TIMEOUT   10UL
-
 /* convert bits to us */
 #define ITE_BITS_TO_NS(bits, sample_period) \
 ((u32) ((bits) * ITE_BAUDRATE_DIVISOR * sample_period))
-- 
2.11.0

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean!

On Wed, May 09, 2018 at 10:44:42PM +0100, Sean Young wrote:
> Hi Hias,
> 
> On Mon, May 07, 2018 at 05:54:55PM +0200, Matthias Reichl wrote:
> > Hi Sean!
> > 
> > [ I trimmed the Cc list, as this is mceusb specific ]
> > 
> > On Sat, Apr 21, 2018 at 07:41:21PM +0200, Matthias Reichl wrote:
> > > On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote:
> > > > Another bug report came in, button press results in multiple
> > > > key down/up events
> > > > https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
> > > > (and following posts).
> > 
> > The original reporter gave up before I could get enough info
> > to understand what's going on, but now another user with an identical
> > receiver and the same problems showed up and I could get debug logs.
> > 
> > FYI: I've uploaded the full dmesg here if you need more info
> > or I snipped off too much:
> > http://www.horus.com/~hias/tmp/mceusb-settimeout-issue.txt
> > 
> > Here's the info about the IR receiver:
> > [2.208684] usb 1-1.3: New USB device found, idVendor=1784, 
> > idProduct=0011
> > [2.208699] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
> > SerialNumber=3
> > [2.208708] usb 1-1.3: Product: eHome Infrared Transceiver
> > [2.208716] usb 1-1.3: Manufacturer: Topseed Technology Corp.
> > [2.208724] usb 1-1.3: SerialNumber: EID0137AG-8-104054
> > 
> > With timeout configuration in the mceusb driver disabled everything
> > works fine. But with timeout configuration enabled spurious "keyup"
> > events show up during a button press and sometimes also a spurious
> > "ghost" keypress several seconds after the original button press.
> > 
> > Here's the ir-keytable -t output to illustrate the behaviour:
> > 
> > 80.385585: event type EV_MSC(0x04): scancode = 0x800f0422
> > 80.385585: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> > 80.385585: event type EV_SYN(0x00).
> > 80.492469: event type EV_MSC(0x04): scancode = 0x800f0422
> > 80.492469: event type EV_SYN(0x00).
> > 80.633371: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> > 80.633371: event type EV_SYN(0x00).
> > 80.642478: event type EV_MSC(0x04): scancode = 0x800f0422
> > 80.642478: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> > 80.642478: event type EV_SYN(0x00).
> > 80.783375: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> > 80.783375: event type EV_SYN(0x00).
> > 84.318011: event type EV_MSC(0x04): scancode = 0x800f0422
> > 84.318011: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> > 84.318011: event type EV_SYN(0x00).
> > 84.460049: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> > 84.460049: event type EV_SYN(0x00).
> > 
> > >From the kernel log the first 2 scancodes are perfectly fine,
> > we get the timeout space in chunks, followed by the "End of raw IR data"
> > message and the scancode is properly decoded. Then about 45ms later
> > the pulses of the following IR message come in.
> > 
> > Snippet from end of second scancode:
> > 
> > [   80.505896] mceusb 1-1.3:1.0: rx data: 81 7f (length=2)
> 
> I've been staring at these logs for days now. :)

You are not the only one :-)

> So here, 0x81 means one
> byte of IR data, which is 0x7f. For each byte of IR data, if the high 
> bit is set (so value >= 0x80) it is a pulse, else space. The remaining
> 7 bits denote the length of the pulse or space, times 50us. So here
> we have 127 * 50 = 6350us space.
> 
> > [   80.505902] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
> > [   80.505907] mceusb 1-1.3:1.0: Storing space with duration 635
> > [   80.505911] mceusb 1-1.3:1.0: processed IR data
> > [   80.506894] mceusb 1-1.3:1.0: rx data: 81 05 (length=2)
> > [   80.506899] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
> > [   80.506904] mceusb 1-1.3:1.0: Storing space with duration 25
> 
> 5 * 50 us = 250us space
> 
> > [   80.506908] rc rc0: enter idle mode
> > [   80.506913] rc rc0: sample: (25650us space)
> > [   80.506918] mceusb 1-1.3:1.0: rx data: 80 (length=1)
> 
> So the 80 here is the byte which marks the timeout.

Yes. More specifically, it's the "IR Data End" message / command,
as mentioned on page 130 of the "Green Button" pdf.

> > [   80.506922] mceusb 1-1.3:1.0: End of raw IR data
> > [   80.506925] mceusb 1-1.3:1.0: processed IR data
> > [   80.506943] rc rc0: RC6 decode started at state 6 (25650us space)
> > [   80.506949] rc rc0: RC6 decode started at state 8 (25

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean!

[ I trimmed the Cc list, as this is mceusb specific ]

On Sat, Apr 21, 2018 at 07:41:21PM +0200, Matthias Reichl wrote:
> On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote:
> > Another bug report came in, button press results in multiple
> > key down/up events
> > https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
> > (and following posts).

The original reporter gave up before I could get enough info
to understand what's going on, but now another user with an identical
receiver and the same problems showed up and I could get debug logs.

FYI: I've uploaded the full dmesg here if you need more info
or I snipped off too much:
http://www.horus.com/~hias/tmp/mceusb-settimeout-issue.txt

Here's the info about the IR receiver:
[2.208684] usb 1-1.3: New USB device found, idVendor=1784, idProduct=0011
[2.208699] usb 1-1.3: New USB device strings: Mfr=1, Product=2, 
SerialNumber=3
[2.208708] usb 1-1.3: Product: eHome Infrared Transceiver
[2.208716] usb 1-1.3: Manufacturer: Topseed Technology Corp.
[2.208724] usb 1-1.3: SerialNumber: EID0137AG-8-104054

With timeout configuration in the mceusb driver disabled everything
works fine. But with timeout configuration enabled spurious "keyup"
events show up during a button press and sometimes also a spurious
"ghost" keypress several seconds after the original button press.

Here's the ir-keytable -t output to illustrate the behaviour:

80.385585: event type EV_MSC(0x04): scancode = 0x800f0422
80.385585: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
80.385585: event type EV_SYN(0x00).
80.492469: event type EV_MSC(0x04): scancode = 0x800f0422
80.492469: event type EV_SYN(0x00).
80.633371: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
80.633371: event type EV_SYN(0x00).
80.642478: event type EV_MSC(0x04): scancode = 0x800f0422
80.642478: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
80.642478: event type EV_SYN(0x00).
80.783375: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
80.783375: event type EV_SYN(0x00).
84.318011: event type EV_MSC(0x04): scancode = 0x800f0422
84.318011: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
84.318011: event type EV_SYN(0x00).
84.460049: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
84.460049: event type EV_SYN(0x00).

>From the kernel log the first 2 scancodes are perfectly fine,
we get the timeout space in chunks, followed by the "End of raw IR data"
message and the scancode is properly decoded. Then about 45ms later
the pulses of the following IR message come in.

Snippet from end of second scancode:

[   80.505896] mceusb 1-1.3:1.0: rx data: 81 7f (length=2)
[   80.505902] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
[   80.505907] mceusb 1-1.3:1.0: Storing space with duration 635
[   80.505911] mceusb 1-1.3:1.0: processed IR data
[   80.506894] mceusb 1-1.3:1.0: rx data: 81 05 (length=2)
[   80.506899] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
[   80.506904] mceusb 1-1.3:1.0: Storing space with duration 25
[   80.506908] rc rc0: enter idle mode
[   80.506913] rc rc0: sample: (25650us space)
[   80.506918] mceusb 1-1.3:1.0: rx data: 80 (length=1)
[   80.506922] mceusb 1-1.3:1.0: End of raw IR data
[   80.506925] mceusb 1-1.3:1.0: processed IR data
[   80.506943] rc rc0: RC6 decode started at state 6 (25650us space)
[   80.506949] rc rc0: RC6 decode started at state 8 (25650us space)
[   80.506955] rc rc0: RC6(6A) proto 0x0013, scancode 0x800f0422 (toggle: 1)
[   80.506961] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
(1784:0011): scancode 0x800f0422 keycode 0x160
[   80.552906] mceusb 1-1.3:1.0: rx data: 81 b5 (length=2)
[   80.552914] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
[   80.552919] mceusb 1-1.3:1.0: Storing pulse with duration 265
[   80.552924] rc rc0: leave idle mode

But then, the end of the third scancode gets interesting. The
last chunk of the timeout space is missing and instead we get
a combined message with the remaining space and a zero-length
pulse just before the fourth IR message starts. Of course, this is
too late and the keyup timer had already expired:

[   80.612896] mceusb 1-1.3:1.0: rx data: 81 7f (length=2)
[   80.612903] mceusb 1-1.3:1.0: Raw IR data, 1 pulse/space samples
[   80.612908] mceusb 1-1.3:1.0: Storing space with duration 635
[   80.612912] mceusb 1-1.3:1.0: processed IR data
[   80.647880] rc rc0: keyup key 0x0160
[   80.656901] mceusb 1-1.3:1.0: rx data: 82 05 80 (length=3)
[   80.656908] mceusb 1-1.3:1.0: Raw IR data, 2 pulse/space samples
[   80.656913] mceusb 1-1.3:1.0: Storing space with duration 25
[   80.656918] rc rc0: enter idle mode
[   80.656923] rc rc0: sample: (25650us space)
[   80.656928] mceusb 1-1.3:1.0: Storing pulse with duration 0
[   80.656931] rc rc0: leave idle mode
[   80.656935] mceusb 1-1.3:1.0: processed IR data
[   80.656967] rc rc0: RC6 decode started at state 6 (25650us

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

On Sat, Apr 21, 2018 at 03:18:52PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote:
> > One of the affected users reported back that the fix worked fine!
> > 
> > I'm keeping an eye on further reports but so far I'd say everything's
> > working really well.
> 
> Another bug report came in, button press results in multiple
> key down/up events
> https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
> (and following posts).
> 
> ir-ctl -r output looks fine to me, but ir-keytable -t output suggests
> we'll need a margin between raw timeout and key up timeout:
> 
> https://pastebin.com/6RTSGXvp
> 2199.824106: event type EV_MSC(0x04): scancode = 0x800f0419
> 2199.824106: event type EV_KEY(0x01) key_down: KEY_STOP(0x0080)
> 2199.824106: event type EV_SYN(0x00).
> 2199.887081: event type EV_KEY(0x01) key_up: KEY_STOP(0x0080)
> 2199.887081: event type EV_MSC(0x04): scancode = 0x800f0422
> 2199.887081: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> 2199.887081: event type EV_SYN(0x00).
> 2200.029804: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> 2200.029804: event type EV_SYN(0x00).

Sorry, just noticed I snipped off the interesting part, here
is the rest:

2200.036070: event type EV_MSC(0x04): scancode = 0x800f0422
2200.036070: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
2200.036070: event type EV_SYN(0x00).
2200.143067: event type EV_MSC(0x04): scancode = 0x800f0422
2200.143067: event type EV_SYN(0x00).
2200.206061: event type EV_MSC(0x04): scancode = 0x800f0422
2200.206061: event type EV_SYN(0x00).
2200.346472: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
2200.346472: event type EV_SYN(0x00).

I looked at the log again, and now it doesn't make much sense
to me.

I'm not exactly sure what happened with the first KEY_OK
scancode, that seems to have been decoded ~60ms after the
KEY_STOP scancode (.887 vs .824).

The second KEY_OK scancode was decoded ~ 150ms after the first,
(and caused the problem), delay to third is 107ms, to fourth 63ms.

I'll ask the user to change batteries on the remote and check
if the reception is OK, could be that this was a false alarm.

Adding some margin (maybe 20-50ms) for keyup could still make
sense though, as currently we have basically just the timeout
as margin, which can be quite low and round to 1-2 jiffies.

so long,

Hias

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Fri, Apr 20, 2018 at 12:17:23AM +0200, Matthias Reichl wrote:
> One of the affected users reported back that the fix worked fine!
> 
> I'm keeping an eye on further reports but so far I'd say everything's
> working really well.

Another bug report came in, button press results in multiple
key down/up events
https://forum.kodi.tv/showthread.php?tid=298461=2727837#pid2727837
(and following posts).

ir-ctl -r output looks fine to me, but ir-keytable -t output suggests
we'll need a margin between raw timeout and key up timeout:

https://pastebin.com/6RTSGXvp
2199.824106: event type EV_MSC(0x04): scancode = 0x800f0419
2199.824106: event type EV_KEY(0x01) key_down: KEY_STOP(0x0080)
2199.824106: event type EV_SYN(0x00).
2199.887081: event type EV_KEY(0x01) key_up: KEY_STOP(0x0080)
2199.887081: event type EV_MSC(0x04): scancode = 0x800f0422
2199.887081: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
2199.887081: event type EV_SYN(0x00).
2200.029804: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
2200.029804: event type EV_SYN(0x00).

so long,

Hias

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Wed, Apr 18, 2018 at 07:42:29PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Wed, Apr 18, 2018 at 12:24:29PM +0100, Sean Young wrote:
> > Hello Hias,
> > 
> > On Tue, Apr 17, 2018 at 09:14:57PM +0200, Matthias Reichl wrote:
> > > On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote:
> > > > mceusb devices have a default timeout of 100ms, but this can be changed.
> > > 
> > > We finally added a backport of the v2 series (and also the mce_kbd
> > > series) to LibreELEC yesterday and ratcher quickly received 2 bugreports
> > > from users using mceusb receivers.
> > > 
> > > Local testing on RPi/gpio-ir and Intel NUC/ite-cir was fine, I've
> > > been using the v2 series for over a week without issues on
> > > LibreELEC (RPi with kernel 4.14).
> > > 
> > > Here are the links to the bugreports and logs:
> > > https://forum.kodi.tv/showthread.php?tid=298461=2726684#pid2726684
> > > https://forum.kodi.tv/showthread.php?tid=298462=2726690#pid2726690
> > > 
> > > Both users are using similar mceusb receivers:
> > > 
> > > Log 1:
> > > [6.418218] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e017) as 
> > > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0
> > > [6.418358] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e017) as 
> > > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0/input0
> > > [6.419443] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > > at minor = 0
> > > [6.608114] mceusb 1-1.3:1.0: Registered Formosa21 SnowflakeEmulation 
> > > with mce emulator interface version 1
> > > [6.608125] mceusb 1-1.3:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > > (0x1 active)
> > > 
> > > Log 2:
> > > [3.023361] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e03e) as /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0
> > > [3.023393] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > > (147a:e03e) as 
> > > /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0/input11
> > > [3.023868] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > > at minor = 0
> > > [3.119384] input: eventlircd as /devices/virtual/input/input21
> > > [3.138625] ip6_tables: (C) 2000-2006 Netfilter Core Team
> > > [3.196830] mceusb 1-10:1.0: Registered Formosa21 eHome Infrared 
> > > Transceiver with mce emulator interface version 2
> > > [3.196836] mceusb 1-10:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > > (0x1 active)
> > > 
> > > In both cases ir-keytable doesn't report any scancodes and the
> > > ir-ctl -r output contains very odd long space values where I'd expect
> > > a short timeout instead:
> > > 
> > > gap between messages:
> > > space 800
> > > pulse 450
> > > space 16777215
> > > space 25400
> > > pulse 2650
> > > space 800
> > > 
> > > end of last message:
> > > space 800
> > > pulse 450
> > > space 16777215
> > > timeout 31750
> > > 
> > > This patch applied cleanly on 4.14 and the mceusb history from
> > > 4.14 to media/master looked rather unsuspicious. I'm not 100% sure
> > > if I might have missed a dependency when backporting the patch
> > > or if this is indeed an issue of this patch on these particular
> > > (or maybe some more) mceusb receivers.
> > 
> > Thanks again for a great bug report and analysis! So, it seems with the
> > shorter timeout, some mceusb devices add a specific "timeout" code to
> > the IR data stream (0x80) rather than a space. The current mceusb code
> > resets the decoders in this case, causing the IR decoders to reset and
> > lirc to report a space of 0xff.
> > 
> > Turns out that one of my mceusb devices also suffers from this, I don't
> > know how I missed this. Anyway hopefully this will solve the problem.
> 
> Thanks a lot for the quick fix!
> 
> I can't test myself as I don't have the hardware, but we will
> include the patch in tonight's LibreELEC build and I asked the
> users to test it. I'll keep you posted about the outcome.

One of the affected users reported back that the fix worked fine!

I'm keeping an eye on further reports but so far I'd say everything's
working really well.

Great job and thanks a lot for the im

Re: [PATCH 2/9] cx231xx: Use board profile values for addresses

[Matthias Schwarzott]

Am 17.04.2018 um 18:39 schrieb Brad Love:
> Replace all usage of hard coded values with
> the proper field from the board profile.
> 

Hi Brad,

will there be any interference with the usage to configure the analog
tuner via the fields tuner_addr and tuner_type?

Regards
Matthias

> Signed-off-by: Brad Love <b...@nextdimension.cc>
> ---
>  drivers/media/usb/cx231xx/cx231xx-dvb.c | 19 +--
>  1 file changed, 9 insertions(+), 10 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 67ed667..99f1a77 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -728,7 +728,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   if (!dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _rde253s_tunerconfig)) {
>   result = -EINVAL;
>   goto out_free;
> @@ -752,7 +752,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   if (!dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _rde253s_tunerconfig)) {
>   result = -EINVAL;
>   goto out_free;
> @@ -779,7 +779,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _tda18271_config);
>   break;
>  
> @@ -797,7 +797,7 @@ static int dvb_init(struct cx231xx *dev)
>  
>   memset(, 0, sizeof(struct i2c_board_info));
>   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = 0x64;
> + info.addr = dev->board.demod_addr;
>   info.platform_data = _pdata;
>   request_module(info.type);
>   client = i2c_new_device(demod_i2c, );
> @@ -822,8 +822,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> - 0x60,
> - tuner_i2c,
> + dev->board.tuner_addr, tuner_i2c,
>   _tda18271_config);
>  
>   dev->cx231xx_reset_analog_tuner = NULL;
> @@ -844,7 +843,7 @@ static int dvb_init(struct cx231xx *dev)
>  
>   memset(, 0, sizeof(struct i2c_board_info));
>   strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = 0x64;
> + info.addr = dev->board.demod_addr;
>   info.platform_data = _pdata;
>   request_module(info.type);
>   client = i2c_new_device(demod_i2c, );
> @@ -879,7 +878,7 @@ static int dvb_init(struct cx231xx *dev)
>   si2157_config.if_port = 1;
>   si2157_config.inversion = true;
>   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
> - info.addr = 0x60;
> + info.addr = dev->board.tuner_addr;
>   info.platform_data = _config;
>   request_module("si2157");
>  
> @@ -938,7 +937,7 @@ static int dvb_init(struct cx231xx *dev)
>   si2157_config.if_port = 1;
>   si2157_config.inversion = true;
>   strlcpy(info.type, "si2157", I2C_NAME_SIZE);
> - info.addr = 0x60;
> + info.addr = dev->board.tuner_addr;
>   info.platform_data = _config;
>   request_module("si2157");
>  
> @@ -985,7 +984,7 @@ static int dvb_init(struct cx231xx *dev)
>   dvb->frontend[0]->callback = cx231xx_tuner_callback;
>  
>   dvb_attach(tda18271_attach, dev->dvb->frontend[0],
> -0x60, tuner_i2c,
> +dev->board.tuner_addr, tuner_i2c,
>  _tda18271_config);
>   break;
>  
> 

Re: [PATCH 5/9] cx231xx: Switch to using new dvb i2c helpers

[Matthias Schwarzott]

Am 17.04.2018 um 18:39 schrieb Brad Love:
> Mostly very straight forward replace of blocks with equivalent code.
> 
> Cleanup added at end of dvb_init in case of failure.
> 
Hi Brad,

I have some suggestions. See below.

Matthias

> Signed-off-by: Brad Love <b...@nextdimension.cc>
> ---
>  drivers/media/usb/cx231xx/cx231xx-dvb.c | 331 
> 
>  1 file changed, 82 insertions(+), 249 deletions(-)
> 
> diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
> b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> index 681610f..318a6cd 100644
> --- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
> +++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
> @@ -613,23 +613,18 @@ static void unregister_dvb(struct cx231xx_dvb *dvb)
>   dvb_frontend_detach(dvb->frontend[1]);
>   dvb_frontend_detach(dvb->frontend[0]);
>   dvb_unregister_adapter(>adapter);
> +
>   /* remove I2C tuner */
>   client = dvb->i2c_client_tuner;
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> - /* remove I2C demod */
> + if (client)
> + dvb_module_release(client);
The pointer check is not needed, dvb_module_release does check itself
for NULL.

Other drivers added code to set the client-pointers to NULL after
releasing it.

I suggest to do it like this:
/* remove I2C tuner */
dvb_module_release(dvb->i2c_client_tuner);
dvb->i2c_client_tuner = NULL;


> + /* remove I2C demod(s) */
>   client = dvb->i2c_client_demod[1];
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> + if (client)
> + dvb_module_release(client);
>   client = dvb->i2c_client_demod[0];
> - if (client) {
> - module_put(client->dev.driver->owner);
> - i2c_unregister_device(client);
> - }
> + if (client)
> + dvb_module_release(client);

>  }
>  
>  static int dvb_init(struct cx231xx *dev)
> @@ -638,6 +633,8 @@ static int dvb_init(struct cx231xx *dev)
>   struct cx231xx_dvb *dvb;
>   struct i2c_adapter *tuner_i2c;
>   struct i2c_adapter *demod_i2c;
> + struct i2c_client *client;
> + struct i2c_adapter *adapter;
>  
>   if (!dev->board.has_dvb) {
>   /* This device does not support the extension */
> @@ -785,8 +782,6 @@ static int dvb_init(struct cx231xx *dev)
>  
>   case CX231XX_BOARD_HAUPPAUGE_930C_HD_1113xx:
>   {
> - struct i2c_client *client;
> - struct i2c_board_info info;
>   struct si2165_platform_data si2165_pdata = {};
>  
>   /* attach demod */
> @@ -794,25 +789,14 @@ static int dvb_init(struct cx231xx *dev)
>   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL;
>   si2165_pdata.ref_freq_hz = 1600;
>  
> - memset(, 0, sizeof(struct i2c_board_info));
> - strlcpy(info.type, "si2165", I2C_NAME_SIZE);
> - info.addr = dev->board.demod_addr;
> - info.platform_data = _pdata;
> - request_module(info.type);
> - client = i2c_new_device(demod_i2c, );
> - if (!client || !client->dev.driver || !dev->dvb->frontend[0]) {
> - dev_err(dev->dev,
> - "Failed to attach SI2165 front end\n");
> - result = -EINVAL;
> - goto out_free;
> - }
> -
> - if (!try_module_get(client->dev.driver->owner)) {
> - i2c_unregister_device(client);
> + /* perform tuner probe/init/attach */
> + client = dvb_module_probe("si2165", NULL, demod_i2c,
> + dev->board.demod_addr,
> + _pdata);
> + if (!client) {
>   result = -ENODEV;
>   goto out_free;
>   }
> -
>   dvb->i2c_client_demod[0] = client;
>  
>   dev->dvb->frontend[0]->ops.i2c_gate_ctrl = NULL;
> @@ -829,8 +813,6 @@ static int dvb_init(struct cx231xx *dev)
>   }
>   case CX231XX_BOARD_HAUPPAUGE_930C_HD_1114xx:
>   {
> - struct i2c_client *client;
> - struct i2c_board_info info;
>   struct si2165_platform_data si2165_pdata = {};
>   struct si2157_config si2157_config = {};
>  
> @@ -839,29 +821,16 @@ static int dvb_init(struct cx231xx

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean,

On Wed, Apr 18, 2018 at 12:24:29PM +0100, Sean Young wrote:
> Hello Hias,
> 
> On Tue, Apr 17, 2018 at 09:14:57PM +0200, Matthias Reichl wrote:
> > On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote:
> > > mceusb devices have a default timeout of 100ms, but this can be changed.
> > 
> > We finally added a backport of the v2 series (and also the mce_kbd
> > series) to LibreELEC yesterday and ratcher quickly received 2 bugreports
> > from users using mceusb receivers.
> > 
> > Local testing on RPi/gpio-ir and Intel NUC/ite-cir was fine, I've
> > been using the v2 series for over a week without issues on
> > LibreELEC (RPi with kernel 4.14).
> > 
> > Here are the links to the bugreports and logs:
> > https://forum.kodi.tv/showthread.php?tid=298461=2726684#pid2726684
> > https://forum.kodi.tv/showthread.php?tid=298462=2726690#pid2726690
> > 
> > Both users are using similar mceusb receivers:
> > 
> > Log 1:
> > [6.418218] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > (147a:e017) as 
> > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0
> > [6.418358] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > (147a:e017) as 
> > /devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0/input0
> > [6.419443] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > at minor = 0
> > [6.608114] mceusb 1-1.3:1.0: Registered Formosa21 SnowflakeEmulation 
> > with mce emulator interface version 1
> > [6.608125] mceusb 1-1.3:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > (0x1 active)
> > 
> > Log 2:
> > [3.023361] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
> > (147a:e03e) as /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0
> > [3.023393] input: Media Center Ed. eHome Infrared Remote Transceiver 
> > (147a:e03e) as 
> > /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0/input11
> > [3.023868] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered 
> > at minor = 0
> > [3.119384] input: eventlircd as /devices/virtual/input/input21
> > [3.138625] ip6_tables: (C) 2000-2006 Netfilter Core Team
> > [3.196830] mceusb 1-10:1.0: Registered Formosa21 eHome Infrared 
> > Transceiver with mce emulator interface version 2
> > [3.196836] mceusb 1-10:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors 
> > (0x1 active)
> > 
> > In both cases ir-keytable doesn't report any scancodes and the
> > ir-ctl -r output contains very odd long space values where I'd expect
> > a short timeout instead:
> > 
> > gap between messages:
> > space 800
> > pulse 450
> > space 16777215
> > space 25400
> > pulse 2650
> > space 800
> > 
> > end of last message:
> > space 800
> > pulse 450
> > space 16777215
> > timeout 31750
> > 
> > This patch applied cleanly on 4.14 and the mceusb history from
> > 4.14 to media/master looked rather unsuspicious. I'm not 100% sure
> > if I might have missed a dependency when backporting the patch
> > or if this is indeed an issue of this patch on these particular
> > (or maybe some more) mceusb receivers.
> 
> Thanks again for a great bug report and analysis! So, it seems with the
> shorter timeout, some mceusb devices add a specific "timeout" code to
> the IR data stream (0x80) rather than a space. The current mceusb code
> resets the decoders in this case, causing the IR decoders to reset and
> lirc to report a space of 0xff.
> 
> Turns out that one of my mceusb devices also suffers from this, I don't
> know how I missed this. Anyway hopefully this will solve the problem.

Thanks a lot for the quick fix!

I can't test myself as I don't have the hardware, but we will
include the patch in tonight's LibreELEC build and I asked the
users to test it. I'll keep you posted about the outcome.

so long,

Hias

> 
> 
> Thanks
> 
> Sean
> 
> >>From 92d27b206e51993e927dc0b3aba210a621eef3d0 Mon Sep 17 00:00:00 2001
> From: Sean Young <s...@mess.org>
> Date: Wed, 18 Apr 2018 10:36:25 +0100
> Subject: [PATCH] media: rc: mceusb: IR of length 0 means IR timeout, not reset
> 
> The last usb packet with IR data will end with 0x80 (MCE_IRDATA_TRAILER).
> If we reset the decoder state at this point, IR decoding can fail.
> 
> Signed-off-by: Sean Young <s...@mess.org>
> ---
>  drivers/media/rc/mceusb.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index c97c

Re: [PATCH v2 7/7] media: rc: mceusb: allow the timeout to be configurable

[Matthias Reichl]

Hi Sean!

On Sun, Apr 08, 2018 at 10:19:42PM +0100, Sean Young wrote:
> mceusb devices have a default timeout of 100ms, but this can be changed.

We finally added a backport of the v2 series (and also the mce_kbd
series) to LibreELEC yesterday and ratcher quickly received 2 bugreports
from users using mceusb receivers.

Local testing on RPi/gpio-ir and Intel NUC/ite-cir was fine, I've
been using the v2 series for over a week without issues on
LibreELEC (RPi with kernel 4.14).

Here are the links to the bugreports and logs:
https://forum.kodi.tv/showthread.php?tid=298461=2726684#pid2726684
https://forum.kodi.tv/showthread.php?tid=298462=2726690#pid2726690

Both users are using similar mceusb receivers:

Log 1:
[6.418218] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
(147a:e017) as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0
[6.418358] input: Media Center Ed. eHome Infrared Remote Transceiver 
(147a:e017) as 
/devices/platform/soc/3f98.usb/usb1/1-1/1-1.3/1-1.3:1.0/rc/rc0/input0
[6.419443] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at 
minor = 0
[6.608114] mceusb 1-1.3:1.0: Registered Formosa21 SnowflakeEmulation with 
mce emulator interface version 1
[6.608125] mceusb 1-1.3:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors (0x1 
active)

Log 2:
[3.023361] rc rc0: Media Center Ed. eHome Infrared Remote Transceiver 
(147a:e03e) as /devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0
[3.023393] input: Media Center Ed. eHome Infrared Remote Transceiver 
(147a:e03e) as 
/devices/pci:00/:00:14.0/usb1/1-10/1-10:1.0/rc/rc0/input11
[3.023868] rc rc0: lirc_dev: driver ir-lirc-codec (mceusb) registered at 
minor = 0
[3.119384] input: eventlircd as /devices/virtual/input/input21
[3.138625] ip6_tables: (C) 2000-2006 Netfilter Core Team
[3.196830] mceusb 1-10:1.0: Registered Formosa21 eHome Infrared Transceiver 
with mce emulator interface version 2
[3.196836] mceusb 1-10:1.0: 0 tx ports (0x0 cabled) and 1 rx sensors (0x1 
active)

In both cases ir-keytable doesn't report any scancodes and the
ir-ctl -r output contains very odd long space values where I'd expect
a short timeout instead:

gap between messages:
space 800
pulse 450
space 16777215
space 25400
pulse 2650
space 800

end of last message:
space 800
pulse 450
space 16777215
timeout 31750

This patch applied cleanly on 4.14 and the mceusb history from
4.14 to media/master looked rather unsuspicious. I'm not 100% sure
if I might have missed a dependency when backporting the patch
or if this is indeed an issue of this patch on these particular
(or maybe some more) mceusb receivers.

so long,

Hias

> Signed-off-by: Sean Young 
> ---
>  drivers/media/rc/mceusb.c | 22 ++
>  1 file changed, 22 insertions(+)
> 
> diff --git a/drivers/media/rc/mceusb.c b/drivers/media/rc/mceusb.c
> index 69ba57372c05..c97cb2eb1c5f 100644
> --- a/drivers/media/rc/mceusb.c
> +++ b/drivers/media/rc/mceusb.c
> @@ -982,6 +982,25 @@ static int mceusb_set_tx_carrier(struct rc_dev *dev, u32 
> carrier)
>   return 0;
>  }
>  
> +static int mceusb_set_timeout(struct rc_dev *dev, unsigned int timeout)
> +{
> + u8 cmdbuf[4] = { MCE_CMD_PORT_IR, MCE_CMD_SETIRTIMEOUT, 0, 0 };
> + struct mceusb_dev *ir = dev->priv;
> + unsigned int units;
> +
> + units = DIV_ROUND_CLOSEST(timeout, US_TO_NS(MCE_TIME_UNIT));
> +
> + cmdbuf[2] = units >> 8;
> + cmdbuf[3] = units;
> +
> + mce_async_out(ir, cmdbuf, sizeof(cmdbuf));
> +
> + /* get receiver timeout value */
> + mce_async_out(ir, GET_RX_TIMEOUT, sizeof(GET_RX_TIMEOUT));
> +
> + return 0;
> +}
> +
>  /*
>   * Select or deselect the 2nd receiver port.
>   * Second receiver is learning mode, wide-band, short-range receiver.
> @@ -1415,7 +1434,10 @@ static struct rc_dev *mceusb_init_rc_dev(struct 
> mceusb_dev *ir)
>   rc->dev.parent = dev;
>   rc->priv = ir;
>   rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> + rc->min_timeout = US_TO_NS(MCE_TIME_UNIT);
>   rc->timeout = MS_TO_NS(100);
> + rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
> + rc->s_timeout = mceusb_set_timeout;
>   if (!ir->flags.no_tx) {
>   rc->s_tx_mask = mceusb_set_tx_mask;
>   rc->s_tx_carrier = mceusb_set_tx_carrier;
> -- 
> 2.14.3
> 

Re: [PATCH v2 0/7] Improve latency of IR decoding

[Matthias Reichl]

On Tue, Apr 10, 2018 at 07:39:43PM +0100, Sean Young wrote:
> On Tue, Apr 10, 2018 at 07:53:43PM +0200, Matthias Reichl wrote:
> > Hi Sean,
> > 
> > On Sun, Apr 08, 2018 at 10:19:35PM +0100, Sean Young wrote:
> > > The current IR decoding is much too slow. Many IR protocols rely on
> > > a trailing space for decoding (e.g. rc-6 needs to know when the bits
> > > end). The trailing space is generated by the IR timeout, and if this
> > > is longer than required, buttons can feel slow to respond.
> > > 
> > > The other issue is the keyup timer. IR has no concept of a keyup message,
> > > this is implied by the absence of IR. So, minimising the timeout for
> > > this makes buttons less "sticky"; the are released much quicker.
> > > 
> > > With these patches in place, using IR with the builtin decoders is much
> > > improved and feels very snappy.
> > > 
> > > Changes since v1:
> > >  - lost more testing
> > >  - fixed various issues with mce decoder
> > >  - fixed mceusb so it can use better timeout too
> > 
> > thanks, this version is working fine with meson-ir and gpio-rc-recv
> > (latter on RPi). I mainly tested it with rc-5 remotes so far, more
> > will follow and I'll update LibreELEC in a day or two to include
> > the v2 series.
> 
> Thanks again for testing!
> 
> > Also thanks a lot for the mce_kbd fixes, I was just going to dig
> > into the decoder (we received a bug report about stuck keys with
> > mce_kbd last week), your patches can in just at the right time :)
> > 
> > I had a closer look at ir-mce_kbd-decoder.c and noticed 2 things
> > (which can be handled separately):
> > 
> > It looks like the input_sync call in the state machine error
> > path is not necessary:
> > 
> > out:
> > dev_dbg(>dev, "failed at state %i (%uus %s)\n",
> > data->state, TO_US(ev.duration), TO_STR(ev.pulse));
> > data->state = STATE_INACTIVE;
> > input_sync(data->idev);
> > return -EINVAL;
> > 
> > If I followed the code paths correctly states that generate
> > input events won't go to out, only paths were no events are
> > generated jump to out - but better verify that, I could have
> > missed something.
> 
> The input_sync() patch is in mce_kbd_rx_timeout() code path, which
> doesn't go through this. Hopefully it should fix the keys stuck
> issue.

Yes, I saw that and the input_sync() in mce_kbd_rx_timeout() fixed
this (I could verify that locally).

What I meant is that the input_sync() in the snippet above, which
isn't touched by your patches, doesn't seem necessary, as the
code paths that lead to there don't submit input events. The
happy paths (successful key/mouse event and keyup) call input_sync()
at the end of STATE_FINISHED:

lsc.scancode = scancode;
ir_lirc_scancode_event(dev, );
data->state = STATE_INACTIVE;
input_event(data->idev, EV_MSC, MSC_SCAN, scancode);
input_sync(data->idev);
return 0;

> > The other thing I noticed is that there's no spinlock synchronizing
> > the events from the timeout callback with the ones from the state
> > machine - like keylock in rc-main. So the code could potentially
> > be racy (if the timeout fires while the state machine is outputting
> > events).
> 
> This timeout is for sending keyups in case no keyup is received from
> the keyboard via input_report_key(). The input system does locking
> for us (see drivers/input/input.c:436).

The synchronization code in rc-main looks like it's used to make
code blocks that eg call input_report_key and input_sync do that
in an atomic way (plus there's the special handling of keyup_jiffies
to prevent a race betwen the keyup timeout callback and new
decoded scancodes.

As both the timeout callback and the state machine send out
multiple key events and end them with input_sync it looks to me
like we'd need to make that atomic as well. Otherwise we could
have eg timeout running, starting to report a bunch of shift
and other keys as up, then interruption by a new key/scancode
calling input_report_key down plus input_sync and then timeout
resuming and reporting the rest of the keys down and again
do input_sync().

so long,

Hias

Re: [PATCH v2 0/7] Improve latency of IR decoding

[Matthias Reichl]

Hi Sean,

On Sun, Apr 08, 2018 at 10:19:35PM +0100, Sean Young wrote:
> The current IR decoding is much too slow. Many IR protocols rely on
> a trailing space for decoding (e.g. rc-6 needs to know when the bits
> end). The trailing space is generated by the IR timeout, and if this
> is longer than required, buttons can feel slow to respond.
> 
> The other issue is the keyup timer. IR has no concept of a keyup message,
> this is implied by the absence of IR. So, minimising the timeout for
> this makes buttons less "sticky"; the are released much quicker.
> 
> With these patches in place, using IR with the builtin decoders is much
> improved and feels very snappy.
> 
> Changes since v1:
>  - lost more testing
>  - fixed various issues with mce decoder
>  - fixed mceusb so it can use better timeout too

thanks, this version is working fine with meson-ir and gpio-rc-recv
(latter on RPi). I mainly tested it with rc-5 remotes so far, more
will follow and I'll update LibreELEC in a day or two to include
the v2 series.

Also thanks a lot for the mce_kbd fixes, I was just going to dig
into the decoder (we received a bug report about stuck keys with
mce_kbd last week), your patches can in just at the right time :)

I had a closer look at ir-mce_kbd-decoder.c and noticed 2 things
(which can be handled separately):

It looks like the input_sync call in the state machine error
path is not necessary:

out:
dev_dbg(>dev, "failed at state %i (%uus %s)\n",
data->state, TO_US(ev.duration), TO_STR(ev.pulse));
data->state = STATE_INACTIVE;
input_sync(data->idev);
return -EINVAL;

If I followed the code paths correctly states that generate
input events won't go to out, only paths were no events are
generated jump to out - but better verify that, I could have
missed something.

The other thing I noticed is that there's no spinlock synchronizing
the events from the timeout callback with the ones from the state
machine - like keylock in rc-main. So the code could potentially
be racy (if the timeout fires while the state machine is outputting
events).

so long,

Hias

> 
> Sean Young (7):
>   media: rc: set timeout to smallest value required by enabled protocols
>   media: rc: add ioctl to get the current timeout
>   media: rc: per-protocol repeat period and minimum keyup timer
>   media: rc: mce_kbd decoder: low timeout values cause double keydowns
>   media: rc: mce_kbd protocol encodes two scancodes
>   media: rc: mce_kbd decoder: fix stuck keys
>   media: rc: mceusb: allow the timeout to be configurable
> 
>  Documentation/media/uapi/rc/lirc-func.rst  |  1 +
>  .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
>  drivers/media/cec/cec-core.c   |  2 +-
>  drivers/media/rc/ir-imon-decoder.c |  1 +
>  drivers/media/rc/ir-jvc-decoder.c  |  1 +
>  drivers/media/rc/ir-mce_kbd-decoder.c  | 36 +++-
>  drivers/media/rc/ir-nec-decoder.c  |  1 +
>  drivers/media/rc/ir-rc5-decoder.c  |  1 +
>  drivers/media/rc/ir-rc6-decoder.c  |  1 +
>  drivers/media/rc/ir-sanyo-decoder.c|  1 +
>  drivers/media/rc/ir-sharp-decoder.c|  1 +
>  drivers/media/rc/ir-sony-decoder.c |  1 +
>  drivers/media/rc/ir-xmp-decoder.c  |  1 +
>  drivers/media/rc/lirc_dev.c|  9 ++-
>  drivers/media/rc/mceusb.c  | 22 +++
>  drivers/media/rc/rc-core-priv.h|  1 +
>  drivers/media/rc/rc-ir-raw.c   | 31 +-
>  drivers/media/rc/rc-main.c | 68 
> +++---
>  include/uapi/linux/lirc.h  |  6 ++
>  19 files changed, 144 insertions(+), 55 deletions(-)
> 
> -- 
> 2.14.3
> 

Re: [PATCH 1/3] media: si2165: Remove owner assignment from i2c_driver

[Matthias Schwarzott]

Thank you for sending this patch.

Am 24.03.2018 um 15:01 schrieb Fabio Estevam:
> From: Fabio Estevam <fabio.este...@nxp.com>
> 
> Structure i2c_driver does not need to set the owner field, as this will
> be populated by the driver core.
> 
> Generated by scripts/coccinelle/api/platform_no_drv_owner.cocci.
> 
> Cc: Matthias Schwarzott <z...@gentoo.org>
> Signed-off-by: Fabio Estevam <fabio.este...@nxp.com>
> ---
>  drivers/media/dvb-frontends/si2165.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/si2165.c 
> b/drivers/media/dvb-frontends/si2165.c
> index 2dd336f..d132e3c 100644
> --- a/drivers/media/dvb-frontends/si2165.c
> +++ b/drivers/media/dvb-frontends/si2165.c
> @@ -1299,7 +1299,6 @@ MODULE_DEVICE_TABLE(i2c, si2165_id_table);
>  
>  static struct i2c_driver si2165_driver = {
>   .driver = {
> - .owner  = THIS_MODULE,
>   .name   = "si2165",
>   },
>   .probe  = si2165_probe,
> 

The change is fine.

Reviewed-by: Matthias Schwarzott <z...@gentoo.org>

Re: [PATCH 01/16] omap: omap-iommu.h: allow building drivers with COMPILE_TEST

[Matthias Schwarzott]

Am 05.04.2018 um 19:54 schrieb Mauro Carvalho Chehab:
> Drivers that depend on omap-iommu.h (currently, just omap3isp)
> need a stub implementation in order to be built with COMPILE_TEST.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  include/linux/omap-iommu.h | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/include/linux/omap-iommu.h b/include/linux/omap-iommu.h
> index c1aede46718b..0c21fc5b002e 100644
> --- a/include/linux/omap-iommu.h
> +++ b/include/linux/omap-iommu.h
> @@ -13,7 +13,12 @@
>  #ifndef _OMAP_IOMMU_H_
>  #define _OMAP_IOMMU_H_
>  
> +#ifdef CONFIG_OMAP_IOMMU
>  extern void omap_iommu_save_ctx(struct device *dev);
>  extern void omap_iommu_restore_ctx(struct device *dev);
> +#else
> +static inline void omap_iommu_save_ctx(struct device *dev) {};
> +static inline void omap_iommu_restore_ctx(struct device *dev) {};

The semicolons at end of line are unnecessary.

> +#endif
>  
>  #endif
> 

Regards
Matthias

Re: [PATCH 0/3] Improve latency of IR decoding

[Matthias Reichl]

Hi Sean,

On Wed, Mar 28, 2018 at 08:30:29PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Sat, Mar 24, 2018 at 02:50:42PM +, Sean Young wrote:
> > The current IR decoding is much too slow. Many IR protocols rely on
> > a trailing space for decoding (e.g. rc-6 needs to know when the bits
> > end). The trailing space is generated by the IR timeout, and if this
> > is longer than required, keys can be perceived as sticky and slugish.
> > 
> > The other issue the keyup timer. IR has no concept of a keyup message,
> > this is implied by the absence of IR. So, minimising the timeout for
> > this further improves the handling.
> > 
> > With these patches in place, using IR with the builtin decoders is much
> > improved and feels very snappy.
> 
> thanks a lot for the patches!
> 
> I didn't have much time to test yet, but quick checks on
> Amlogic/meson-ir (kernel 4.16-rc7 + media tree + your patches)
> and Raspberry Pi (RPi foundation kernel 4.14 + my backport of
> your patches) look really promising.
> 
> I found one issue, though, in ir-sharp-decoder.c max_space must
> be set to SHARP_ECHO_SPACE - otherwise we get a timeout between
> the normal and inverted message part and decoding fails.
> 
> One thing I'm wondering is if the keyup timer marging might
> be too tight now. Basically we have just the fixed 10ms marging
> from idle timeout. The repeat periods of the protocols are rather
> accurate/strict, so (programmable) remotes not sticking to the
> official timing might cause repeated keyup/down events if they
> are repeating a tad to slow.
> 
> I'm not sure if this could be an issue, but maybe we should
> add a safety margin to the repeat periods as well? For example
> 10 or 20 percent of the specced repeat periods. What do you think?
> 
> To get some more test coverage I've asked my colleague to
> include my backport patch in the LibreELEC testbuilds for
> x86 and RPi. We've got some 500 regular users of these so if
> something's not working we should find out soon.

Quick update: testing so far went really smooth, no issues reported
since we included the backport patch in LibreELEC testbuilds.

Quote from 
https://github.com/LibreELEC/LibreELEC.tv/pull/2623#issuecomment-377897518
> This is in my nightly test builds since 28 March, and no problems reported so 
> far.
>
> On my NUC with Harmony One/RC6 remote these commits are working just fine.

I've been using LibreELEC on RPi with the patch (using a gpio ir
receiver and a Hauppauge RC-5 remote) since then and everything
was fine as well.

so long,

Hias

> I just hope I
> didn't mess up the backport... Here's the link to my 4.14 patch:
> 
> https://github.com/HiassofT/LibreELEC.tv/blob/le9-ir-latency/packages/linux/patches/default/linux-999-improve-ir-timeout-handling.patch
> 
> so long & thanks,
> 
> Hias
> 
> > 
> > Sean Young (3):
> >   media: rc: set timeout to smallest value required by enabled protocols
> >   media: rc: add ioctl to get the current timeout
> >   media: rc: per-protocol repeat period and minimum keyup timer
> > 
> >  Documentation/media/uapi/rc/lirc-func.rst  |  1 +
> >  .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
> >  drivers/media/cec/cec-core.c   |  2 +-
> >  drivers/media/rc/ir-imon-decoder.c |  1 +
> >  drivers/media/rc/ir-jvc-decoder.c  |  1 +
> >  drivers/media/rc/ir-mce_kbd-decoder.c  |  1 +
> >  drivers/media/rc/ir-nec-decoder.c  |  1 +
> >  drivers/media/rc/ir-rc5-decoder.c  |  1 +
> >  drivers/media/rc/ir-rc6-decoder.c  |  1 +
> >  drivers/media/rc/ir-sanyo-decoder.c|  1 +
> >  drivers/media/rc/ir-sharp-decoder.c|  1 +
> >  drivers/media/rc/ir-sony-decoder.c |  1 +
> >  drivers/media/rc/ir-xmp-decoder.c  |  1 +
> >  drivers/media/rc/lirc_dev.c|  9 ++-
> >  drivers/media/rc/rc-core-priv.h|  1 +
> >  drivers/media/rc/rc-ir-raw.c   | 31 +-
> >  drivers/media/rc/rc-main.c | 68 
> > +++---
> >  include/uapi/linux/lirc.h  |  6 ++
> >  18 files changed, 101 insertions(+), 41 deletions(-)
> > 
> > -- 
> > 2.14.3
> > 

Re: [PATCH 0/3] Improve latency of IR decoding

[Matthias Reichl]

Hi Sean,

On Sat, Mar 24, 2018 at 02:50:42PM +, Sean Young wrote:
> The current IR decoding is much too slow. Many IR protocols rely on
> a trailing space for decoding (e.g. rc-6 needs to know when the bits
> end). The trailing space is generated by the IR timeout, and if this
> is longer than required, keys can be perceived as sticky and slugish.
> 
> The other issue the keyup timer. IR has no concept of a keyup message,
> this is implied by the absence of IR. So, minimising the timeout for
> this further improves the handling.
> 
> With these patches in place, using IR with the builtin decoders is much
> improved and feels very snappy.

thanks a lot for the patches!

I didn't have much time to test yet, but quick checks on
Amlogic/meson-ir (kernel 4.16-rc7 + media tree + your patches)
and Raspberry Pi (RPi foundation kernel 4.14 + my backport of
your patches) look really promising.

I found one issue, though, in ir-sharp-decoder.c max_space must
be set to SHARP_ECHO_SPACE - otherwise we get a timeout between
the normal and inverted message part and decoding fails.

One thing I'm wondering is if the keyup timer marging might
be too tight now. Basically we have just the fixed 10ms marging
from idle timeout. The repeat periods of the protocols are rather
accurate/strict, so (programmable) remotes not sticking to the
official timing might cause repeated keyup/down events if they
are repeating a tad to slow.

I'm not sure if this could be an issue, but maybe we should
add a safety margin to the repeat periods as well? For example
10 or 20 percent of the specced repeat periods. What do you think?

To get some more test coverage I've asked my colleague to
include my backport patch in the LibreELEC testbuilds for
x86 and RPi. We've got some 500 regular users of these so if
something's not working we should find out soon. I just hope I
didn't mess up the backport... Here's the link to my 4.14 patch:

https://github.com/HiassofT/LibreELEC.tv/blob/le9-ir-latency/packages/linux/patches/default/linux-999-improve-ir-timeout-handling.patch

so long & thanks,

Hias

> 
> Sean Young (3):
>   media: rc: set timeout to smallest value required by enabled protocols
>   media: rc: add ioctl to get the current timeout
>   media: rc: per-protocol repeat period and minimum keyup timer
> 
>  Documentation/media/uapi/rc/lirc-func.rst  |  1 +
>  .../media/uapi/rc/lirc-set-rec-timeout.rst | 14 +++--
>  drivers/media/cec/cec-core.c   |  2 +-
>  drivers/media/rc/ir-imon-decoder.c |  1 +
>  drivers/media/rc/ir-jvc-decoder.c  |  1 +
>  drivers/media/rc/ir-mce_kbd-decoder.c  |  1 +
>  drivers/media/rc/ir-nec-decoder.c  |  1 +
>  drivers/media/rc/ir-rc5-decoder.c  |  1 +
>  drivers/media/rc/ir-rc6-decoder.c  |  1 +
>  drivers/media/rc/ir-sanyo-decoder.c|  1 +
>  drivers/media/rc/ir-sharp-decoder.c|  1 +
>  drivers/media/rc/ir-sony-decoder.c |  1 +
>  drivers/media/rc/ir-xmp-decoder.c  |  1 +
>  drivers/media/rc/lirc_dev.c|  9 ++-
>  drivers/media/rc/rc-core-priv.h|  1 +
>  drivers/media/rc/rc-ir-raw.c   | 31 +-
>  drivers/media/rc/rc-main.c | 68 
> +++---
>  include/uapi/linux/lirc.h  |  6 ++
>  18 files changed, 101 insertions(+), 41 deletions(-)
> 
> -- 
> 2.14.3
> 

Re: [PATCH] [media] vcodec: fix error return value from mtk_jpeg_clk_init()

[Matthias Brugger]

On 03/23/2018 04:44 AM, Ryder Lee wrote:
> The error return value should be fixed as it may return EPROBE_DEFER.
> 
> Cc: Rick Chang <rick.ch...@mediatek.com>
> Cc: Bin Liu <bin@mediatek.com>
> Signed-off-by: Ryder Lee <ryder....@mediatek.com>

Reviewed-by: Matthias Brugger <matthias@gmail.com>

> ---
>  drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c 
> b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> index 226f908..af17aaa 100644
> --- a/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> +++ b/drivers/media/platform/mtk-jpeg/mtk_jpeg_core.c
> @@ -1081,11 +1081,11 @@ static int mtk_jpeg_clk_init(struct mtk_jpeg_dev 
> *jpeg)
>  
>   jpeg->clk_jdec = devm_clk_get(jpeg->dev, "jpgdec");
>   if (IS_ERR(jpeg->clk_jdec))
> - return -EINVAL;
> + return PTR_ERR(jpeg->clk_jdec);
>  
>   jpeg->clk_jdec_smi = devm_clk_get(jpeg->dev, "jpgdec-smi");
>   if (IS_ERR(jpeg->clk_jdec_smi))
> - return -EINVAL;
> + return PTR_ERR(jpeg->clk_jdec_smi);
>  
>   return 0;
>  }
> 

Issue with sharp protocol on ite-cir due to high idle timeout

[Matthias Reichl]

Hi Sean,

yesterday we received an interesting bug report that might
help to motivate using a lower idle timeout on ite-cir:

https://forum.libreelec.tv/thread/11951-sharp-ir-remote-on-intel-nuc-2820-double-presses/

The rather long message time of the sharp protocol (about 86ms)
in combination with the 200ms default idle timeout of ite-cir
leads to the last message being received after the current 250ms
"keyup" timeout. This results in an additional keyup/keydown
event being generated from the last message. Even a short button
press results in 2 keydown events.

I dont't have any ite-cir hardware here but could reproduce it
with gpio-ir-recv set to 200ms idle timeout. Lowering the
timeout to 100 or 125ms fixed the issue both here and on the
reporter's hardware.

so long,

Hias

Re: [PATCH] media: rc: meson-ir: add timeout on idle

[Matthias Reichl]

Hi Sean,

On Mon, Mar 12, 2018 at 01:58:11PM +, Sean Young wrote:
> On Mon, Mar 12, 2018 at 02:20:00PM +0100, Matthias Reichl wrote:
> > On Sun, Mar 11, 2018 at 12:55:19PM +, Sean Young wrote:
> > > That makes complete sense. I'm actually keen to get this lowered, since
> > > this makes it possible to lower the repeat period per-protocol, see
> > > commit d57ea877af38 which had to be reverted (the ite driver will
> > > need fixing up as well before this can happen).
> > 
> > I remember the commit, this issue hit us in LibreELEC testbuilds
> > as well :-)
> > 
> > > Lowering to below 125ms does increase the risk of regressions, so I
> > > am weary of that. Do you think there is benefit in doing this?
> > 
> > I'd also say stick to the 125ms default. The default settings
> > should always be safe ones IMO.
> 
> Well, yes. I just wanted to explore the ideal situation before making
> up our minds.
> 
> > People who want to optimize for the last bit of performance can
> > easily do that on their own, at their own risk.
> > 
> > 
> > Personally I've been using gpio-ir-recv on RPi with the default 125ms
> > timeout and a Hauppauge rc-5 remote for about 2 years now and I've
> > always been happy with that.
> 
> Ok. We should try to get this change for meson-ir ready for v4.17. I can
> write a patch later.

Thanks, it worked fine!

> > I have to acknowledge though that the responsiveness of a remote
> > with short messages, like rc-5, in combination with a low timeout
> > (I tested down to 10ms) is pretty impressive.
> 
> I've been thinking about this problem. What we could do is have a 
> per-protocol maximum space length, and repeat period. The timeout
> can then be set to a maximum space length (+safety margin), and the
> keyup timer can be set to timeout + repeat period (+safety margin).

This sounds like a very good idea. It won't help much with IR
receivers that have no configurable timeout or a large minimum
timeout (ite-cir has 100ms min, probably a hardware limitation?),
but for other receivers this'll be a nice improvement.

> If memory serves, the lirc daemon always sets the timeout with
> LIRC_SET_REC_TIMEOUT, so it would not affect lirc daemon decoding.

Current versions of Lirc (0.9.4 and newer) don't seem to use
LIRC_SET_REC_TIMEOUT but handle timeouts on it's own via a
timeout value in poll().

There's still some generic code in lircd.cpp that supports setting
timeouts via LIRC_SET_REC_TIMEOUT but the default plugin (which
handles /dev/lircX) doesn't implement any of the required 
get/set timeout ioctls.

strace on lircd 0.10.0 also shows that only LIRC_GET_FEATURES is
used.

Older Lirc versions (checked with 0.9.1 source I had here)
seem to be using LIRC_SET_REC_TIMEOUT.

So I think we should be fine here.

Not sure if there are other users of the /dev/lirc interface
that could be affected, I'm only familiar with lirc and the
tools from v4l-utils.

> Anyway, just an idea. Not something for v4.17.

No need to rush things, your idea looks good to me but better
test it thoroughly.

Drop me a line if you have a first implementation, I'd be happy
to help with testing.

so long,

Hias

Re: [PATCH] media: rc: meson-ir: lower timeout and make configurable

[Matthias Reichl]

On Mon, Mar 12, 2018 at 09:48:40PM +, Sean Young wrote:
> A timeout of 200ms is much longer than necessary, and delays the decoding
> decoding of a single scancode and the last scancode when a button is being
> held. This makes the remote seem sluggish.
> 
> If the min_timeout and max_timeout values are set, the timeout is
> configurable via the LIRC_SET_REC_TIMEOUT ioctl.
> 
> Signed-off-by: Sean Young <s...@mess.org>

Tested-by: Matthias Reichl <h...@horus.com>

Thanks a lot, this is working fine!

so long,

Hias

> ---
>  drivers/media/rc/meson-ir.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> index 64b0aa4f4db7..f449b35d25e7 100644
> --- a/drivers/media/rc/meson-ir.c
> +++ b/drivers/media/rc/meson-ir.c
> @@ -144,7 +144,9 @@ static int meson_ir_probe(struct platform_device *pdev)
>   ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
>   ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
>   ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
> - ir->rc->timeout = MS_TO_NS(200);
> + ir->rc->min_timeout = 1;
> + ir->rc->timeout = IR_DEFAULT_TIMEOUT;
> + ir->rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
>   ir->rc->driver_name = DRIVER_NAME;
>  
>   spin_lock_init(>lock);
> -- 
> 2.14.3
> 

Re: [PATCH] media: rc: meson-ir: add timeout on idle

[Matthias Reichl]

Hi Sean,

On Sun, Mar 11, 2018 at 12:55:19PM +, Sean Young wrote:
> Hi Matthias,
> 
> On Sat, Mar 10, 2018 at 06:38:28PM +0100, Matthias Reichl wrote:
> > On Sat, Mar 10, 2018 at 11:27:45AM +, Sean Young wrote:
> > > So if the timeout is below N then you will never get a space of N or 
> > > larger;
> > > the largest space I know of in an IR message is 40ms in the sanyo 
> > > protocol:
> > > 
> > > https://www.sbprojects.net/knowledge/ir/sharp.php
> > > 
> > > So if timeout is set to less than 40ms, we would have trouble decoding the
> > > sharp protocol.
> > > 
> > > The space between nec repeats is a little less than 100ms. I'm trying to
> > > remember what would could go wrong if the space between them would be
> > > timeouts instead. Mauro do you remember? I can imagine some IR hardware
> > > (e.g. winbond) queuing up IR after generating a timeout, thus delaying
> > > delivering IR to the kernel and we ending up generating a key up.
> > > 
> > > The problem with a higher timeout is that the trailing space (=timeout)
> > > is sometimes needed for decoding, and decoding of the last message is
> > > delayed until the timeout is received. That means the keyup message is
> > > delayed until that time, making keys a bit "sticky" and more likely to
> > > generate repeats. I'm pretty sure that is needed for rc-5 and nec.
> > 
> > Another issue with high timeouts is the response to very short button
> > presses where the remote only transmits a single scancode. It then
> > takes signal transmission time plus timeout, so roughly a quarter
> > of a second on meson-ir and ite-cir with 200ms timeout, until the
> > scancode is decoded and the keydown event is generated.
> > 
> > On longer button presses this is less of an issue as we get the
> > space signal when the first pulse of the repeated scancode is
> > received. So the delay between button press and keydown is determined
> > by the remote scancode repeat interval and with typically ~110ms
> > on nec/rc-5 a lot lower.
> > 
> > This affects both "quick fingers" using a standard remote and
> > users of programmable remotes like the Logitech Harmony where
> > the number of scancodes transmitted on a short press can be
> > configured. With a single scancode transmission we run into
> > the long keydown delay, 2 scancodes is fine, and at 3 or 4 we
> > start running into the key repeat issue.
> > 
> > We received several reports from users that their remote felt
> > "sluggish" when we switched from the downstream "amremote" driver
> > (which IIRC decoded the nec protocol in hardware) to meson-ir.
> > 
> > Lowering the timeout to 125ms or even significantly lower
> > (depending on what the protocol and IR receiver permits)
> > removes this "sluggishness", users report that their remote
> > is more "responsive".
> 
> That makes complete sense. I'm actually keen to get this lowered, since
> this makes it possible to lower the repeat period per-protocol, see
> commit d57ea877af38 which had to be reverted (the ite driver will
> need fixing up as well before this can happen).

I remember the commit, this issue hit us in LibreELEC testbuilds
as well :-)

> Lowering to below 125ms does increase the risk of regressions, so I
> am weary of that. Do you think there is benefit in doing this?

I'd also say stick to the 125ms default. The default settings
should always be safe ones IMO.

People who want to optimize for the last bit of performance can
easily do that on their own, at their own risk.

Personally I've been using gpio-ir-recv on RPi with the default 125ms
timeout and a Hauppauge rc-5 remote for about 2 years now and I've
always been happy with that.

I have to acknowledge though that the responsiveness of a remote
with short messages, like rc-5, in combination with a low timeout
(I tested down to 10ms) is pretty impressive.

so long,

Hias

Re: [PATCH] media: rc: meson-ir: add timeout on idle

[Matthias Reichl]

Hi Sean,

On Sat, Mar 10, 2018 at 11:27:45AM +, Sean Young wrote:
> Hi Matthias,
> 
> On Fri, Mar 09, 2018 at 04:54:51PM +0100, Matthias Reichl wrote:
> > On Thu, Mar 08, 2018 at 04:43:27PM +, Sean Young wrote:
> > > On Tue, Mar 06, 2018 at 06:41:22PM +0100, Matthias Reichl wrote:
> > > > +
> > > >  static int meson_ir_probe(struct platform_device *pdev)
> > > >  {
> > > > struct device *dev = >dev;
> > > > @@ -145,7 +161,9 @@ static int meson_ir_probe(struct platform_device 
> > > > *pdev)
> > > > ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
> > > > ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> > > > ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
> > > > +   ir->rc->min_timeout = 1;
> > > > ir->rc->timeout = MS_TO_NS(200);
> > > > +   ir->rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
> > > 
> > > Any idea why the default timeout is to 200ms? It seems very high.
> > 
> > Indeed it is very high, but I have no idea where that might be
> > coming from - so I didn't touch it.
> > 
> > I've been testing rc-5 and NEC remotes with 20-50ms timeouts
> > on meson-ir/upstream kernel and a couple of LibreELEC users are
> > using 30-50ms timeouts without issues on Amlogic devices as well
> > (on 3.14 vendor kernel with meson-ir timeout patch):
> > 
> > https://forum.libreelec.tv/thread/11643-le9-0-remote-configs-ir-keytable-amlogic-devices/?postID=83124#post83124
> > 
> > Out of curiosity: where does the 125ms IR_DEFAULT_TIMEOUT value
> > come from? For raw IR signals processed by the decoders this seems
> > rather high to me as well. On my RPi3 with gpio-ir-recv I'm
> > using 30ms timeout (with an rc-5 remote) without issues.
> 
> So if the timeout is below N then you will never get a space of N or larger;
> the largest space I know of in an IR message is 40ms in the sanyo protocol:
> 
> https://www.sbprojects.net/knowledge/ir/sharp.php
> 
> So if timeout is set to less than 40ms, we would have trouble decoding the
> sharp protocol.
> 
> The space between nec repeats is a little less than 100ms. I'm trying to
> remember what would could go wrong if the space between them would be
> timeouts instead. Mauro do you remember? I can imagine some IR hardware
> (e.g. winbond) queuing up IR after generating a timeout, thus delaying
> delivering IR to the kernel and we ending up generating a key up.
> 
> The problem with a higher timeout is that the trailing space (=timeout)
> is sometimes needed for decoding, and decoding of the last message is
> delayed until the timeout is received. That means the keyup message is
> delayed until that time, making keys a bit "sticky" and more likely to
> generate repeats. I'm pretty sure that is needed for rc-5 and nec.

Another issue with high timeouts is the response to very short button
presses where the remote only transmits a single scancode. It then
takes signal transmission time plus timeout, so roughly a quarter
of a second on meson-ir and ite-cir with 200ms timeout, until the
scancode is decoded and the keydown event is generated.

On longer button presses this is less of an issue as we get the
space signal when the first pulse of the repeated scancode is
received. So the delay between button press and keydown is determined
by the remote scancode repeat interval and with typically ~110ms
on nec/rc-5 a lot lower.

This affects both "quick fingers" using a standard remote and
users of programmable remotes like the Logitech Harmony where
the number of scancodes transmitted on a short press can be
configured. With a single scancode transmission we run into
the long keydown delay, 2 scancodes is fine, and at 3 or 4 we
start running into the key repeat issue.

We received several reports from users that their remote felt
"sluggish" when we switched from the downstream "amremote" driver
(which IIRC decoded the nec protocol in hardware) to meson-ir.

Lowering the timeout to 125ms or even significantly lower
(depending on what the protocol and IR receiver permits)
removes this "sluggishness", users report that their remote
is more "responsive".

so long,

Hias

Re: [PATCH] media: rc: meson-ir: add timeout on idle

[Matthias Reichl]

Hi Sean,

On Thu, Mar 08, 2018 at 04:43:27PM +, Sean Young wrote:
> On Tue, Mar 06, 2018 at 06:41:22PM +0100, Matthias Reichl wrote:
> > Meson doesn't seem to be able to generate timeout events
> > in hardware. So install a software timer to generate the
> > timeout events required by the decoders to prevent
> > "ghost keypresses".
> > 
> > Signed-off-by: Matthias Reichl <h...@horus.com>
> > ---
> >  drivers/media/rc/meson-ir.c | 22 ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
> > index f2204eb77e2a..f34c5836412b 100644
> > --- a/drivers/media/rc/meson-ir.c
> > +++ b/drivers/media/rc/meson-ir.c
> > @@ -69,6 +69,7 @@ struct meson_ir {
> > void __iomem*reg;
> > struct rc_dev   *rc;
> > spinlock_t  lock;
> > +   struct timer_list timeout_timer;
> >  };
> >  
> >  static void meson_ir_set_mask(struct meson_ir *ir, unsigned int reg,
> > @@ -98,6 +99,10 @@ static irqreturn_t meson_ir_irq(int irqno, void *dev_id)
> > rawir.pulse = !!(status & STATUS_IR_DEC_IN);
> >  
> > ir_raw_event_store(ir->rc, );
> > +
> > +   mod_timer(>timeout_timer,
> > +   jiffies + nsecs_to_jiffies(ir->rc->timeout));
> > +
> > ir_raw_event_handle(ir->rc);
> >  
> > spin_unlock(>lock);
> > @@ -105,6 +110,17 @@ static irqreturn_t meson_ir_irq(int irqno, void 
> > *dev_id)
> > return IRQ_HANDLED;
> >  }
> >  
> > +static void meson_ir_timeout_timer(struct timer_list *t)
> > +{
> > +   struct meson_ir *ir = from_timer(ir, t, timeout_timer);
> > +   DEFINE_IR_RAW_EVENT(rawir);
> > +
> > +   rawir.timeout = true;
> > +   rawir.duration = ir->rc->timeout;
> > +   ir_raw_event_store(ir->rc, );
> > +   ir_raw_event_handle(ir->rc);
> > +}
> 
> Now there can be concurrent access to the raw IR kfifo from the interrupt
> handler and the timer. As there is a race condition between the timeout
> timer and new IR arriving from the interrupt handler, the timeout could
> end being generated after new IR and corrupting a message. There is very
> similar functionality in rc-ir-raw.c (with a spinlock).

Ah, thanks for the hint! Now I also noticed your commit a few
weeks ago - must have missed that before.

> > +
> >  static int meson_ir_probe(struct platform_device *pdev)
> >  {
> > struct device *dev = >dev;
> > @@ -145,7 +161,9 @@ static int meson_ir_probe(struct platform_device *pdev)
> > ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
> > ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
> > ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
> > +   ir->rc->min_timeout = 1;
> > ir->rc->timeout = MS_TO_NS(200);
> > +   ir->rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
> 
> Any idea why the default timeout is to 200ms? It seems very high.

Indeed it is very high, but I have no idea where that might be
coming from - so I didn't touch it.

I've been testing rc-5 and NEC remotes with 20-50ms timeouts
on meson-ir/upstream kernel and a couple of LibreELEC users are
using 30-50ms timeouts without issues on Amlogic devices as well
(on 3.14 vendor kernel with meson-ir timeout patch):

https://forum.libreelec.tv/thread/11643-le9-0-remote-configs-ir-keytable-amlogic-devices/?postID=83124#post83124

Out of curiosity: where does the 125ms IR_DEFAULT_TIMEOUT value
come from? For raw IR signals processed by the decoders this seems
rather high to me as well. On my RPi3 with gpio-ir-recv I'm
using 30ms timeout (with an rc-5 remote) without issues.

> > ir->rc->driver_name = DRIVER_NAME;
> >  
> > spin_lock_init(>lock);
> > @@ -157,6 +175,8 @@ static int meson_ir_probe(struct platform_device *pdev)
> > return ret;
> > }
> >  
> > +   timer_setup(>timeout_timer, meson_ir_timeout_timer, 0);
> > +
> > ret = devm_request_irq(dev, irq, meson_ir_irq, 0, NULL, ir);
> > if (ret) {
> > dev_err(dev, "failed to request irq\n");
> > @@ -198,6 +218,8 @@ static int meson_ir_remove(struct platform_device *pdev)
> > meson_ir_set_mask(ir, IR_DEC_REG1, REG1_ENABLE, 0);
> > spin_unlock_irqrestore(>lock, flags);
> >  
> > +   del_timer_sync(>timeout_timer);
> > +
> > return 0;
> >  }
> >  
> > -- 
> > 2.11.0
> 
> Would you mind trying this patch?

Tested-by: Matthias Reichl <h...@horus.com>

Thanks a lot, this patch works fin

[PATCH] media: rc: meson-ir: add timeout on idle

[Matthias Reichl]

Meson doesn't seem to be able to generate timeout events
in hardware. So install a software timer to generate the
timeout events required by the decoders to prevent
"ghost keypresses".

Signed-off-by: Matthias Reichl <h...@horus.com>
---
 drivers/media/rc/meson-ir.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/drivers/media/rc/meson-ir.c b/drivers/media/rc/meson-ir.c
index f2204eb77e2a..f34c5836412b 100644
--- a/drivers/media/rc/meson-ir.c
+++ b/drivers/media/rc/meson-ir.c
@@ -69,6 +69,7 @@ struct meson_ir {
void __iomem*reg;
struct rc_dev   *rc;
spinlock_t  lock;
+   struct timer_list timeout_timer;
 };
 
 static void meson_ir_set_mask(struct meson_ir *ir, unsigned int reg,
@@ -98,6 +99,10 @@ static irqreturn_t meson_ir_irq(int irqno, void *dev_id)
rawir.pulse = !!(status & STATUS_IR_DEC_IN);
 
ir_raw_event_store(ir->rc, );
+
+   mod_timer(>timeout_timer,
+   jiffies + nsecs_to_jiffies(ir->rc->timeout));
+
ir_raw_event_handle(ir->rc);
 
spin_unlock(>lock);
@@ -105,6 +110,17 @@ static irqreturn_t meson_ir_irq(int irqno, void *dev_id)
return IRQ_HANDLED;
 }
 
+static void meson_ir_timeout_timer(struct timer_list *t)
+{
+   struct meson_ir *ir = from_timer(ir, t, timeout_timer);
+   DEFINE_IR_RAW_EVENT(rawir);
+
+   rawir.timeout = true;
+   rawir.duration = ir->rc->timeout;
+   ir_raw_event_store(ir->rc, );
+   ir_raw_event_handle(ir->rc);
+}
+
 static int meson_ir_probe(struct platform_device *pdev)
 {
struct device *dev = >dev;
@@ -145,7 +161,9 @@ static int meson_ir_probe(struct platform_device *pdev)
ir->rc->map_name = map_name ? map_name : RC_MAP_EMPTY;
ir->rc->allowed_protocols = RC_PROTO_BIT_ALL_IR_DECODER;
ir->rc->rx_resolution = US_TO_NS(MESON_TRATE);
+   ir->rc->min_timeout = 1;
ir->rc->timeout = MS_TO_NS(200);
+   ir->rc->max_timeout = 10 * IR_DEFAULT_TIMEOUT;
ir->rc->driver_name = DRIVER_NAME;
 
spin_lock_init(>lock);
@@ -157,6 +175,8 @@ static int meson_ir_probe(struct platform_device *pdev)
return ret;
}
 
+   timer_setup(>timeout_timer, meson_ir_timeout_timer, 0);
+
ret = devm_request_irq(dev, irq, meson_ir_irq, 0, NULL, ir);
if (ret) {
dev_err(dev, "failed to request irq\n");
@@ -198,6 +218,8 @@ static int meson_ir_remove(struct platform_device *pdev)
meson_ir_set_mask(ir, IR_DEC_REG1, REG1_ENABLE, 0);
spin_unlock_irqrestore(>lock, flags);
 
+   del_timer_sync(>timeout_timer);
+
return 0;
 }
 
-- 
2.11.0

Re: [PATCH] Potential fix for "[BUG] process stuck when closing saa7146 [dvb_ttpci]"

[Philipp Matthias Hahn]

Hello Andrey,

On Sun, Oct 16, 2016 at 11:52:19PM +0200, Philipp Matthias Hahn wrote:
> On Mon, Sep 19, 2016 at 07:08:52AM +0200, Philipp Hahn wrote:
> > Am 16.09.2016 um 12:00 schrieb Andrey Utkin:
> > > Please try this patch. It is purely speculative as I don't have the 
> > > hardware,
> > > but I hope my approach is right.
> > 
> > Thanks you for the patch; I've built a new kernel but didn't have the
> > time to test it yet; I'll mail you again as soon as I have tested it.
> 
> I tested your patch and during my limites testing I wan't able to
> reproduce the previous problem. Seems you fixed it.
> 
> Tested-by: Philipp Matthias Hahn <pmh...@pmhahn.de>
> 
> Thanks you again for looking into that issues.

Bad news: I'm running linux-4.15.2 by now and again got a stuck ffmpeg
process after accessing /dev/video0:

| INFO: task read_thread:20579 blocked for more than 120 seconds.
|   Tainted: P   O 4.15.2 #1
| "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
| read_thread D0 20579   2949 0x8000
| Call Trace:
|  ? __schedule+0x646/0x697
|  schedule+0x79/0x94
|  videobuf_waiton+0x11c/0x148 [videobuf_core]
|  ? wait_woken+0x68/0x68
|  saa7146_dma_free+0x34/0x55 [saa7146_vv]
|  buffer_release+0x25/0x33 [saa7146_vv]
|  videobuf_vm_close+0xd6/0x103 [videobuf_dma_sg]
|  remove_vma+0x23/0x49
|  exit_mmap+0xea/0x114
|  mmput+0x45/0xdb
|  do_exit+0x3a0/0x8c1
|  do_group_exit+0x95/0x95
|  get_signal+0x41c/0x447
|  do_signal+0x1e/0x4c2
|  ? __schedule+0x646/0x697
|  ? do_task_dead+0x38/0x3a
|  ? SyS_futex+0x127/0x137
|  exit_to_usermode_loop+0x1f/0x69
|  do_syscall_64+0xe3/0xea
|  entry_SYSCALL_64_after_hwframe+0x21/0x86
| RIP: 0033:0x7f56429927fd
| RSP: 002b:7f56217b3550 EFLAGS: 0246 ORIG_RAX: 00ca
| RAX: fe00 RBX: 7f5608002320 RCX: 7f56429927fd
| RDX:  RSI: 0080 RDI: 7f560800234c
| RBP:  R08:  R09: 7f5608002320
| R10:  R11: 0246 R12: 0003
| R13: 7f56080022f8 R14:  R15: 7f560800234c

Your previous patch is applied since v4.10-rc1~71^2^2~34 , so the issue seems
to be not fixed.
The tainting is from the NVidia driver.

Philipp

Re: [PATCH 7/9] lgdt3306a: Set fe ops.release to NULL if probed

[Matthias Schwarzott]

Am 05.01.2018 um 01:19 schrieb Michael Ira Krufky:
> On Thu, Jan 4, 2018 at 7:04 PM, Brad Love <b...@nextdimension.cc> wrote:
>> If release is part of frontend ops then it is called in the
>> course of dvb_frontend_detach. The process also decrements
>> the module usage count. The problem is if the lgdt3306a
>> driver is reached via i2c_new_device, then when it is
>> eventually destroyed remove is called, which further
>> decrements the module usage count to negative. After this
>> occurs the driver is in a bad state and no longer works.
>> Also fixed by NULLing out the release callback is a double
>> kfree of state, which introduces arbitrary oopses/GPF.
>> This problem is only currently reachable via the em28xx driver.
>>
>> On disconnect of Hauppauge SoloHD before:
>>
>> lsmod | grep lgdt3306a
>> lgdt3306a  28672  -1
>> i2c_mux16384  1 lgdt3306a
>>
>> On disconnect of Hauppauge SoloHD after:
>>
>> lsmod | grep lgdt3306a
>> lgdt3306a  28672  0
>> i2c_mux16384  1 lgdt3306a
>>
>> Signed-off-by: Brad Love <b...@nextdimension.cc>
>> ---
>>  drivers/media/dvb-frontends/lgdt3306a.c | 1 +
>>  1 file changed, 1 insertion(+)
>>
> 
> Brad,
> 
> We won't be able to apply this one.  The symptom that you're trying to
> fix is indicative of some other problem, probably in the em28xx
> driver.  NULL'ing the release callback is not the right thing to do.
> 

Hi Mike,
Why do you nak this perfectly fine patch?
Let me start to explain.

dvb_attach style drivers have an attach function and for unloading a
.release callback.

i2c-style drivers have a probe and a remove function.

Mixed style drivers must be constructed, that either release or remove
is called, never both.
They both do the same thing, but with different signature.


Now checking lgdt3306a driver:

dvb attach style:
In lgdt3306a_attach the release callback is set to lgdt3306a_release and
no remove exists. Fine.

i2c style probe:
struct i2c_driver contains lgdt3306a_probe and lgdt3306a_remove.
lgdt3306a_probe shares code and calls lgdt3306a_attach, but afterwards
the release callback field must be set to NULL.

This is/was done exactly like this in multiple other drivers as long as
they have been multiple style attachable.

Regards
Matthias

> 
>> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
>> b/drivers/media/dvb-frontends/lgdt3306a.c
>> index 6356815..d2477ed 100644
>> --- a/drivers/media/dvb-frontends/lgdt3306a.c
>> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
>> @@ -2177,6 +2177,7 @@ static int lgdt3306a_probe(struct i2c_client *client,
>>
>> i2c_set_clientdata(client, fe->demodulator_priv);
>> state = fe->demodulator_priv;
>> +   state->frontend.ops.release = NULL;
>>
>> /* create mux i2c adapter for tuner */
>> state->muxc = i2c_mux_alloc(client->adapter, >dev,
>> --
>> 2.7.4
>>
> 

Re: [PATCH 2/2] lgdt3306a: Fix a double kfree on i2c device remove

[Matthias Schwarzott]

Am 05.01.2018 um 15:57 schrieb Brad Love:
> Both lgdt33606a_release and lgdt3306a_remove kfree state, but _release is
> called first, then _remove operates on states members before kfree'ing it.
> This can lead to random oops/GPF/etc on USB disconnect.
> 
lgdt3306a_release does nothing but the kfree. So the exact same effect
can be archived by setting state->frontend.ops.release to NULL. This
need to be done already at probe time I think.
lgdt3306a_remove does this, but too late (after the call to release).

Regards
Matthias

> Signed-off-by: Brad Love <b...@nextdimension.cc>
> ---
>  drivers/media/dvb-frontends/lgdt3306a.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/media/dvb-frontends/lgdt3306a.c 
> b/drivers/media/dvb-frontends/lgdt3306a.c
> index d370671..3642e6e 100644
> --- a/drivers/media/dvb-frontends/lgdt3306a.c
> +++ b/drivers/media/dvb-frontends/lgdt3306a.c
> @@ -1768,7 +1768,13 @@ static void lgdt3306a_release(struct dvb_frontend *fe)
>   struct lgdt3306a_state *state = fe->demodulator_priv;
>  
>   dbg_info("\n");
> - kfree(state);
> +
> + /*
> +  * If state->muxc is not NULL, then we are an i2c device
> +  * and lgdt3306a_remove will clean up state
> +  */
> + if (!state->muxc)
> + kfree(state);
>  }
>  
>  static const struct dvb_frontend_ops lgdt3306a_ops;
> 

Re: [BUG] ir-ctl: error sending file with multiple scancodes

[Matthias Reichl]

Hi Sean,

On Wed, Nov 29, 2017 at 08:05:21PM +, Sean Young wrote:
> On Wed, Nov 29, 2017 at 03:44:00PM +0100, Matthias Reichl wrote:
> > The goal I'm trying to achieve is to send a repeated signal with ir-ctl
> > (a user reported his sony receiver needs this to actually power up).
> 
> That's interesting.

I'm not sure how common that is. I've got a Panasonic TV here
that needs a 0.5-1sec button press to power up from standby,
but it could well be that this is a rather nieche issue.

I had a look at what it would take to add proper repeat handling
to ir-ctl (similar to the --count  option in lirc's irsend)
but that looks like a larger endeavour: implement automatic
variable length gaps to get fixed repeat times, handle toggle
bits in some protocols, send special repeat codes eg in NEC etc.

As I'm not sure if all of this is even needed I think it's best
to leave it for maybe some time later. For now the current
functionality in ir-ctl looks sufficient.

> > Using the -S option multiple times comes rather close, but the 125ms
> > delay between signals is a bit long for the sony protocol - would be
> > nice if that would be adjustable :)
> 
> Yes, that would be a useful feature.
> 
> I've got some patches for this, I'll send them as a reply to this. Please
> let me know what you think.

[PATCH 1/2] ir-ctl: fix multiple scancodes in one file 
01-multiple-scancodes.patch
[PATCH 2/2] ir-ctl: specify the gap between scancodes or files

Tested-by: Matthias Reichl <h...@horus.com>

Thanks, the patches look and tested fine!

I've tested multiple scancodes in a file with and without explicit
space in between and the gap option with multiple -S scancodes on
the command line. I also tested rc5 protocol in addition to sony12.

So I'd like to say a big thank you for fixing the issue so quickly!

so long,

Hias

[BUG] ir-ctl: error sending file with multiple scancodes

[Matthias Reichl]

Hi Sean!

According to the ir-ctl manpage it should be possible to send a file
containing multiple scancodes, but when trying to do this I get
a warning and an error message.

I initially noticed that on version 1.12.3 but 1.12.5 and master
(rev 85f8e5a99) give the same error.

Sending a file with a single scancode or using the -S option
to specify the scancode on the command line both work fine.

I've tested with the following file:

scancode sony12:0x100015
space 25000
scancode sony12:0x100015

Trying to send it gives this:
$ ./utils/ir-ctl/ir-ctl -s ../sony-test.irctl
warning: ../sony-test.irctl:2: trailing space ignored
/dev/lirc0: failed to send: Invalid argument

Checking with the -v option gives some interesting output - it
looks like the the second half of the buffer hadn't been filled in:

$ ./utils/ir-ctl/ir-ctl -v -s ../sony-test.irctl
warning: ../sony-test.irctl:2: trailing space ignored
Sending:
pulse 2400
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 600
space 600
pulse 1200
space 600
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
space 0
pulse 0
/dev/lirc0: failed to send: Invalid argument

The goal I'm trying to achieve is to send a repeated signal with ir-ctl
(a user reported his sony receiver needs this to actually power up).

Using the -S option multiple times comes rather close, but the 125ms
delay between signals is a bit long for the sony protocol - would be
nice if that would be adjustable :)

so long,

Hias

Re: usb/media/em28xx: use-after-free in dvb_unregister_frontend

[Matthias Schwarzott]

Am 21.11.2017 um 14:51 schrieb Andrey Konovalov:
> Hi!
> 
Hi Andrey,

> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit e1d1ea549b57790a3d8cf6300e6ef86118d692a3 (4.15-rc1).
> 
> em28xx 1-1:9.0: Disconnecting
> tc90522 1-0015: Toshiba TC90522 attached.
> qm1d1c0042 2-0061: Sharp QM1D1C0042 attached.
> dvbdev: DVB: registering new adapter (1-1:9.0)
> em28xx 1-1:9.0: DVB: registering adapter 0 frontend 0 (Toshiba TC90522
> ISDB-S module)...
> dvbdev: dvb_create_media_entity: media entity 'Toshiba TC90522 ISDB-S
> module' registered.
> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
> em28xx 1-1:9.0: DVB extension successfully initialized
> em28xx 1-1:9.0: Remote control support is not available for this card.
> em28xx 1-1:9.0: Closing DVB extension
> ==
> BUG: KASAN: use-after-free in dvb_unregister_frontend+0x8f/0xa0
> Read of size 8 at addr 880067853628 by task kworker/0:3/3182
> 
> CPU: 0 PID: 3182 Comm: kworker/0:3 Not tainted 4.14.0-57501-g9284d204d604 #119
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:17
>  dump_stack+0xe1/0x157 lib/dump_stack.c:53
>  print_address_description+0x71/0x234 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x173/0x270 mm/kasan/report.c:409
>  __asan_report_load8_noabort+0x19/0x20 mm/kasan/report.c:430
>  dvb_unregister_frontend+0x8f/0xa0 drivers/media/dvb-core/dvb_frontend.c:2768
>  em28xx_unregister_dvb drivers/media/usb/em28xx/em28xx-dvb.c:1122
>  em28xx_dvb_fini+0x62d/0x8e0 drivers/media/usb/em28xx/em28xx-dvb.c:2129
>  em28xx_close_extension+0x71/0x220 drivers/media/usb/em28xx/em28xx-core.c:1122
>  em28xx_usb_disconnect+0xd7/0x130 drivers/media/usb/em28xx/em28xx-cards.c:3763
>  usb_unbind_interface+0x1b6/0x950 drivers/usb/core/driver.c:423
>  __device_release_driver drivers/base/dd.c:870
>  device_release_driver_internal+0x563/0x630 drivers/base/dd.c:903
>  device_release_driver+0x1e/0x30 drivers/base/dd.c:928
>  bus_remove_device+0x2fc/0x4b0 drivers/base/bus.c:565
>  device_del+0x39f/0xa70 drivers/base/core.c:1984
>  usb_disable_device+0x223/0x710 drivers/usb/core/message.c:1205
>  usb_disconnect+0x285/0x7f0 drivers/usb/core/hub.c:2205
>  hub_port_connect drivers/usb/core/hub.c:4851
>  hub_port_connect_change drivers/usb/core/hub.c:5106
>  port_event drivers/usb/core/hub.c:5212
>  hub_event_impl+0x10f0/0x3440 drivers/usb/core/hub.c:5324
>  hub_event+0x38/0x50 drivers/usb/core/hub.c:5222
>  process_one_work+0x944/0x15f0 kernel/workqueue.c:2112
>  worker_thread+0xef/0x10d0 kernel/workqueue.c:2246
>  kthread+0x367/0x420 kernel/kthread.c:238
>  ret_from_fork+0x24/0x30 arch/x86/entry/entry_64.S:437
> 

this looks similar to the oops fixed by this patch:

https://patchwork.linuxtv.org/patch/45219/

Could you try if it fixes your case also?

Regards
Matthias

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

[Matthias Reichl]

Hi Sean!

On Sun, Nov 19, 2017 at 09:57:27PM +, Sean Young wrote:
> I think for now the best solution is to revert to 250ms for all protocols
> (except for cec which needs 550ms), and reconsider for another kernel.

Thanks, this sounds like a good idea!

> >>From 2f1135f3f9873778ca5c013d1118710152840cb2 Mon Sep 17 00:00:00 2001
> From: Sean Young <s...@mess.org>
> Date: Sun, 19 Nov 2017 21:11:17 +
> Subject: [PATCH] media: rc: partial revert of "media: rc: per-protocol repeat
>  period"
> 
> Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), most
> IR protocols have a lower keyup timeout. This causes problems on the
> ite-cir, which has default IR timeout of 200ms.
> 
> Since the IR decoders read the trailing space, with a IR timeout of 200ms,
> the last keydown will have at least a delay of 200ms. This is more than
> the protocol timeout of e.g. rc-6 (which is 164ms). As a result the last
> IR will be interpreted as a new keydown event, and we get two keypresses.
> 
> Revert the protocol timeout to 250ms, except for cec which needs a timeout
> of 550ms.
> 
> Fixes: d57ea877af38 ("media: rc: per-protocol repeat period")
> Cc: <sta...@vger.kernel.org> # 4.14
> Signed-off-by: Sean Young <s...@mess.org>

Tested-by: Matthias Reichl <h...@horus.com>

I tested this locally with gpio-ir configured to 200ms timeout and
we also received feedback from 2 users that this change fixed the
issue with the ite-cir receiver.

https://forum.kodi.tv/showthread.php?tid=298462=2670637#pid2670637

Thanks a lot for fixing this so quickly!

so long,

Hias
> ---
>  drivers/media/rc/rc-main.c | 32 
>  1 file changed, 16 insertions(+), 16 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 17950e29d4e3..5057b2ba0c10 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -39,41 +39,41 @@ static const struct {
>   [RC_PROTO_UNKNOWN] = { .name = "unknown", .repeat_period = 250 },
>   [RC_PROTO_OTHER] = { .name = "other", .repeat_period = 250 },
>   [RC_PROTO_RC5] = { .name = "rc-5",
> - .scancode_bits = 0x1f7f, .repeat_period = 164 },
> + .scancode_bits = 0x1f7f, .repeat_period = 250 },
>   [RC_PROTO_RC5X_20] = { .name = "rc-5x-20",
> - .scancode_bits = 0x1f7f3f, .repeat_period = 164 },
> + .scancode_bits = 0x1f7f3f, .repeat_period = 250 },
>   [RC_PROTO_RC5_SZ] = { .name = "rc-5-sz",
> - .scancode_bits = 0x2fff, .repeat_period = 164 },
> + .scancode_bits = 0x2fff, .repeat_period = 250 },
>   [RC_PROTO_JVC] = { .name = "jvc",
>   .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_SONY12] = { .name = "sony-12",
> - .scancode_bits = 0x1f007f, .repeat_period = 100 },
> + .scancode_bits = 0x1f007f, .repeat_period = 250 },
>   [RC_PROTO_SONY15] = { .name = "sony-15",
> - .scancode_bits = 0xff007f, .repeat_period = 100 },
> + .scancode_bits = 0xff007f, .repeat_period = 250 },
>   [RC_PROTO_SONY20] = { .name = "sony-20",
> - .scancode_bits = 0x1fff7f, .repeat_period = 100 },
> + .scancode_bits = 0x1fff7f, .repeat_period = 250 },
>   [RC_PROTO_NEC] = { .name = "nec",
> - .scancode_bits = 0x, .repeat_period = 160 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_NECX] = { .name = "nec-x",
> - .scancode_bits = 0xff, .repeat_period = 160 },
> + .scancode_bits = 0xff, .repeat_period = 250 },
>   [RC_PROTO_NEC32] = { .name = "nec-32",
> - .scancode_bits = 0x, .repeat_period = 160 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_SANYO] = { .name = "sanyo",
>   .scancode_bits = 0x1f, .repeat_period = 250 },
>   [RC_PROTO_MCIR2_KBD] = { .name = "mcir2-kbd",
> - .scancode_bits = 0x, .repeat_period = 150 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_MCIR2_MSE] = { .name = "mcir2-mse",
> - .scancode_bits = 0x1f, .repeat_period = 150 },
> + .scancode_bits = 0x1f, .repeat_period = 250 },
>   [RC_PROTO_RC6_0] = { .name = "rc-6-0",
> - .scancode_bits = 0x, .repeat_period = 164 },
> + .scancode_bits = 0x, .repeat_period = 250 },
>   [RC_PROTO_RC6_6A_20] = { .name = "rc-6

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

[Matthias Reichl]

On Fri, Nov 17, 2017 at 03:52:50PM +0100, Matthias Reichl wrote:
> Hi Sean!
> 
> On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote:
> > Since commit d57ea877af38 ("media: rc: per-protocol repeat period"),
> > double keypresses are reported on the ite-cir driver. This is due
> > two factors: that commit reduced the timeout used for some protocols
> > (it became protocol dependant) and the high default IR timeout used
> > by the ite-cir driver.
> > 
> > Some of the IR decoders wait for a trailing space, as that is
> > the only way to know if the bit stream has ended (e.g. rc-6 can be
> > 16, 20 or 32 bits). The longer the IR timeout, the longer it will take
> > to receive the trailing space, delaying decoding and pushing it past the
> > keyup timeout.
> > 
> > So, add the IR timeout to the keyup timeout.
> 
> Thanks a lot for the patch, I've asked the people with ite-cir
> receivers to test it.

Just got the first test results from ite-cir + rc-6 remote back,
events were the same as I was seeing with gpio-ir-recv with 200ms
timeout - key repeat event from input layer.

Kernel 4.14 + your patch:
Event: time 1510938801.797335, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938801.797335, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1
Event: time 1510938801.797335, -- SYN_REPORT 
Event: time 1510938802.034331, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938802.034331, -- SYN_REPORT 
Event: time 1510938802.301333, type 1 (EV_KEY), code 108 (KEY_DOWN), value 2
Event: time 1510938802.301333, -- SYN_REPORT 
Event: time 1510938802.408003, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0
Event: time 1510938802.408003, -- SYN_REPORT 

Kernel 4.13.2:
Event: time 1510938637.791450, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938637.791450, type 1 (EV_KEY), code 108 (KEY_DOWN), value 1
Event: time 1510938637.791450, -- SYN_REPORT 
Event: time 1510938638.028301, type 4 (EV_MSC), code 4 (MSC_SCAN), value 
800f041f
Event: time 1510938638.028301, -- SYN_REPORT 
Event: time 1510938638.292323, type 1 (EV_KEY), code 108 (KEY_DOWN), value 0
Event: time 1510938638.292323, -- SYN_REPORT 

so long,

Hias

> 
> In the meanwhile I ran some tests with gpio-ir-recv and timeout
> set to 200ms with a rc-5 remote (that's as close to the original
> setup as I can test right now).
> 
> While the patch fixes the additional key down/up event on longer
> presses, I still get a repeated key event on a short button
> press - which makes it hard to do a single click with the
> remote.
> 
> Test on kernel 4.14 with your patch:
> 1510927844.292126: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.292126: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
> 1510927844.292126: event type EV_SYN(0x00).
> 1510927844.498773: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.498773: event type EV_SYN(0x00).
> 1510927844.795410: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
> 1510927844.795410: event type EV_SYN(0x00).
> 1510927844.875412: event type EV_KEY(0x01) key_up: KEY_ENTER(0x001c)
> 1510927844.875412: event type EV_SYN(0x00).
> 
> Same signal received on kernel 4.9:
> 1510927844.280350: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.280350: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
> 1510927844.280350: event type EV_SYN(0x00).
> 1510927844.506477: event type EV_MSC(0x04): scancode = 0x1015
> 1510927844.506477: event type EV_SYN(0x00).
> 1510927844.763111: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
> 1510927844.763111: event type EV_SYN(0x00).
> 
> If I understand it correctly it's the input layer repeat (500ms delay)
> kicking in, because time between initial scancode and timeout is
> now signal time + 200ms + 164ms + 200ms (about 570-580ms).
> On older kernels this was signal time + 200ms + 250ms, so typically
> just below the 500ms default repeat delay.
> 
> I'm still trying to wrap my head around the timeout code in the
> rc layer. One problem seems to be that we apply the rather large
> timeout twice. Maybe detecting scancodes generated via timeout
> (sth like timestamp - last_timestamp > protocol_repeat_period)
> and in that case immediately signalling keyup could help? Could well
> be that I'm missing somehting important and this is a bad idea.
> I guess I'd better let you figure something out :)
> 
> so long,
> 
> Hias
> 
> > 
> > Cc: <sta...@vger.kernel.org> # 4.14
> > Reported-by: Matthias Reichl <h...@horus.com>
> > Signed-off-by: Sean Young <s...@mess.org>
>

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

[Matthias Reichl]

Hi Sean!

On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote:
> Since commit d57ea877af38 ("media: rc: per-protocol repeat period"),
> double keypresses are reported on the ite-cir driver. This is due
> two factors: that commit reduced the timeout used for some protocols
> (it became protocol dependant) and the high default IR timeout used
> by the ite-cir driver.
> 
> Some of the IR decoders wait for a trailing space, as that is
> the only way to know if the bit stream has ended (e.g. rc-6 can be
> 16, 20 or 32 bits). The longer the IR timeout, the longer it will take
> to receive the trailing space, delaying decoding and pushing it past the
> keyup timeout.
> 
> So, add the IR timeout to the keyup timeout.

Thanks a lot for the patch, I've asked the people with ite-cir
receivers to test it.

In the meanwhile I ran some tests with gpio-ir-recv and timeout
set to 200ms with a rc-5 remote (that's as close to the original
setup as I can test right now).

While the patch fixes the additional key down/up event on longer
presses, I still get a repeated key event on a short button
press - which makes it hard to do a single click with the
remote.

Test on kernel 4.14 with your patch:
1510927844.292126: event type EV_MSC(0x04): scancode = 0x1015
1510927844.292126: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
1510927844.292126: event type EV_SYN(0x00).
1510927844.498773: event type EV_MSC(0x04): scancode = 0x1015
1510927844.498773: event type EV_SYN(0x00).
1510927844.795410: event type EV_KEY(0x01) key_down: KEY_ENTER(0x001c)
1510927844.795410: event type EV_SYN(0x00).
1510927844.875412: event type EV_KEY(0x01) key_up: KEY_ENTER(0x001c)
1510927844.875412: event type EV_SYN(0x00).

Same signal received on kernel 4.9:
1510927844.280350: event type EV_MSC(0x04): scancode = 0x1015
1510927844.280350: event type EV_KEY(0x01) key_down: KEY_OK(0x0160)
1510927844.280350: event type EV_SYN(0x00).
1510927844.506477: event type EV_MSC(0x04): scancode = 0x1015
1510927844.506477: event type EV_SYN(0x00).
1510927844.763111: event type EV_KEY(0x01) key_up: KEY_OK(0x0160)
1510927844.763111: event type EV_SYN(0x00).

If I understand it correctly it's the input layer repeat (500ms delay)
kicking in, because time between initial scancode and timeout is
now signal time + 200ms + 164ms + 200ms (about 570-580ms).
On older kernels this was signal time + 200ms + 250ms, so typically
just below the 500ms default repeat delay.

I'm still trying to wrap my head around the timeout code in the
rc layer. One problem seems to be that we apply the rather large
timeout twice. Maybe detecting scancodes generated via timeout
(sth like timestamp - last_timestamp > protocol_repeat_period)
and in that case immediately signalling keyup could help? Could well
be that I'm missing somehting important and this is a bad idea.
I guess I'd better let you figure something out :)

so long,

Hias

> 
> Cc: <sta...@vger.kernel.org> # 4.14
> Reported-by: Matthias Reichl <h...@horus.com>
> Signed-off-by: Sean Young <s...@mess.org>
> ---
>  drivers/media/rc/rc-main.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/rc/rc-main.c b/drivers/media/rc/rc-main.c
> index 17950e29d4e3..fae721534517 100644
> --- a/drivers/media/rc/rc-main.c
> +++ b/drivers/media/rc/rc-main.c
> @@ -672,7 +672,8 @@ void rc_repeat(struct rc_dev *dev)
>   input_event(dev->input_dev, EV_MSC, MSC_SCAN, dev->last_scancode);
>   input_sync(dev->input_dev);
>  
> - dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout);
> + dev->keyup_jiffies = jiffies + msecs_to_jiffies(timeout) +
> + nsecs_to_jiffies(dev->timeout);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>  
>  out:
> @@ -744,7 +745,8 @@ void rc_keydown(struct rc_dev *dev, enum rc_proto 
> protocol, u32 scancode,
>  
>   if (dev->keypressed) {
>   dev->keyup_jiffies = jiffies +
> - msecs_to_jiffies(protocols[protocol].repeat_period);
> + msecs_to_jiffies(protocols[protocol].repeat_period) +
> + nsecs_to_jiffies(dev->timeout);
>   mod_timer(>timer_keyup, dev->keyup_jiffies);
>   }
>   spin_unlock_irqrestore(>keylock, flags);
> -- 
> 2.14.3
> 

4.14 regression from commit d57ea877af38 media: rc: per-protocol repeat period

[Matthias Reichl]

The following commit introduced a regression

commit d57ea877af38057b0ef31758cf3b99765dc33695
Author: Sean Young 
Date:   Wed Aug 9 13:19:16 2017 -0400

media: rc: per-protocol repeat period

CEC needs a keypress timeout of 550ms, which is too high for the IR
protocols. Also fill in known repeat times, with 50ms error margin.

Also, combine all protocol data into one structure.

We received a report that an RC6 MCE remote used with the ite-cir
produces "double events" on short button presses:

https://forum.kodi.tv/showthread.php?tid=298462=2667855#pid2667855

Looking at the ir-keytable -t output an additional key event is also
generated after longer button presses:

# ir-keytable -t
Testing events. Please, press CTRL-C to abort.
1510680591.697657: event type EV_MSC(0x04): scancode = 0x800f041f
1510680591.697657: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1510680591.697657: event type EV_SYN(0x00).
1510680591.867355: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1510680591.867355: event type EV_SYN(0x00).
1510680591.935026: event type EV_MSC(0x04): scancode = 0x800f041f
1510680591.935026: event type EV_KEY(0x01) key_down: KEY_DOWN(0x006c)
1510680591.935026: event type EV_SYN(0x00).
1510680592.104100: event type EV_KEY(0x01) key_up: KEY_DOWN(0x006c)
1510680592.104100: event type EV_SYN(0x00).

1510680597.714055: event type EV_MSC(0x04): scancode = 0x800f0405
1510680597.714055: event type EV_KEY(0x01) key_down: KEY_NUMERIC_5(0x0205)
1510680597.714055: event type EV_SYN(0x00).
1510680597.819939: event type EV_MSC(0x04): scancode = 0x800f0405
1510680597.819939: event type EV_SYN(0x00).
1510680597.925614: event type EV_MSC(0x04): scancode = 0x800f0405
1510680597.925614: event type EV_SYN(0x00).
1510680598.032422: event type EV_MSC(0x04): scancode = 0x800f0405
1510680598.032422: event type EV_SYN(0x00).
...
1510680598.562114: event type EV_MSC(0x04): scancode = 0x800f0405
1510680598.562114: event type EV_SYN(0x00).
1510680598.630641: event type EV_KEY(0x01) key_down: KEY_NUMERIC_5(0x0205)
1510680598.630641: event type EV_SYN(0x00).
1510680598.667906: event type EV_MSC(0x04): scancode = 0x800f0405
1510680598.667906: event type EV_SYN(0x00).
1510680598.760760: event type EV_KEY(0x01) key_down: KEY_NUMERIC_5(0x0205)
1510680598.760760: event type EV_SYN(0x00).
1510680598.837412: event type EV_KEY(0x01) key_up: KEY_NUMERIC_5(0x0205)
1510680598.837412: event type EV_SYN(0x00).
1510680598.905003: event type EV_MSC(0x04): scancode = 0x800f0405
1510680598.905003: event type EV_KEY(0x01) key_down: KEY_NUMERIC_5(0x0205)
1510680598.905003: event type EV_SYN(0x00).
1510680599.074092: event type EV_KEY(0x01) key_up: KEY_NUMERIC_5(0x0205)
1510680599.074092: event type EV_SYN(0x00).

Looking at the timestamps of the scancode events it seems that
signals are received every ~106ms but the last signal seems to be
received 237ms after the last-but-one - which is then interpreted
as a new key press cycle as the delay is longer than the 164ms
"repeat_period" setting of the RC6 protocol (before that commit
250ms was used).

This 237ms delay seems to be coming from the 200ms timeout value
of the ite-cir driver (237ms is in the ballpark of ~30ms rc6 signal
time plus 200ms timeout).

The original author hasn't reported back yet but others confirmed
that changing the timeout to 100ms (minimum idle timeout value
of ite-cir) using "ir-ctl -t 10" fixes the issue.

I could locally reproduce this with gpio-ir-recv (which uses the
default 125ms timeout) and the sony protocol (repeat_period = 100ms):

1510838115.272021: event type EV_MSC(0x04): scancode = 0x110001
1510838115.272021: event type EV_KEY(0x01) key_down: KEY_2(0x0003)
1510838115.272021: event type EV_SYN(0x00).
1510838115.322014: event type EV_MSC(0x04): scancode = 0x110001
1510838115.322014: event type EV_SYN(0x00).
1510838115.362003: event type EV_MSC(0x04): scancode = 0x110001
1510838115.362003: event type EV_SYN(0x00).
1510838115.412002: event type EV_MSC(0x04): scancode = 0x110001
1510838115.412002: event type EV_SYN(0x00).
1510838115.521973: event type EV_KEY(0x01) key_up: KEY_2(0x0003)
1510838115.521973: event type EV_SYN(0x00).
1510838115.532007: event type EV_MSC(0x04): scancode = 0x110001
1510838115.532007: event type EV_KEY(0x01) key_down: KEY_2(0x0003)
1510838115.532007: event type EV_SYN(0x00).
1510838115.641972: event type EV_KEY(0x01) key_up: KEY_2(0x0003)
1510838115.641972: event type EV_SYN(0x00).

Reducing the timeout to 20ms removes the addional key_down/up event.

Another test with a rc-5 remote on gpio-ir-recv worked fine at the
default 125ms timeout but with 200ms as on the ite-cir I again
got the additional key event.

so long,

Hias

Re: [PATCH] dvb_frontend: don't use-after-free the frontend struct

[Matthias Schwarzott]

Am 07.11.2017 um 14:44 schrieb Mauro Carvalho Chehab:
> diff --git a/drivers/media/dvb-core/dvb_frontend.c 
> b/drivers/media/dvb-core/dvb_frontend.c
> index d485d5f6cc88..3ad83359098b 100644
> --- a/drivers/media/dvb-core/dvb_frontend.c
> +++ b/drivers/media/dvb-core/dvb_frontend.c
> @@ -150,11 +150,8 @@ static void __dvb_frontend_free(struct dvb_frontend *fe)
>  
>   dvb_frontend_invoke_release(fe, fe->ops.release);
>  
> - if (!fepriv)
> - return;
> -
> - kfree(fepriv);
> - fe->frontend_priv = NULL;
> + if (fepriv)
> + kfree(fepriv);

I think the condition is redundant and should be removed.
kfree(NULL) is fine.

>  }
>  
>  static void dvb_frontend_free(struct kref *ref)
> 

Regards
Matthias

[PATCH 15/15] media: MAINTAINERS: add si2165 driver

[Matthias Schwarzott]

Silicon Labs Si2165 DVB-C/T demod driver

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 MAINTAINERS | 8 
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index adbf69306e9e..b3dc695bcfa4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -12193,6 +12193,14 @@ T: git git://linuxtv.org/anttip/media_tree.git
 S: Maintained
 F: drivers/media/tuners/si2157*
 
+SI2165 MEDIA DRIVER
+M: Matthias Schwarzott <z...@gentoo.org>
+L: linux-media@vger.kernel.org
+W: https://linuxtv.org
+Q: http://patchwork.linuxtv.org/project/linux-media/list/
+S: Maintained
+F: drivers/media/dvb-frontends/si2165*
+
 SI2168 MEDIA DRIVER
 M: Antti Palosaari <cr...@iki.fi>
 L: linux-media@vger.kernel.org
-- 
2.15.0

[PATCH 14/15] si2165: Add DVBv3 wrapper for ber statistics

[Matthias Schwarzott]

Add read_ber function that reads from property cache to support DVBv3.
The implementation is inspired by the cx24120 driver.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index ceb5a2bb0dea..2ad6409dd6b1 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -57,6 +57,9 @@ struct si2165_state {
u32 sys_clk;
u32 adc_clk;
 
+   /* DVBv3 stats */
+   u64 ber_prev;
+
bool has_dvbc;
bool has_dvbt;
bool firmware_loaded;
@@ -757,6 +760,12 @@ static int si2165_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
c->post_bit_error.stat[0].uvalue = 0;
c->post_bit_count.stat[0].uvalue = 0;
 
+   /*
+* reset DVBv3 value to deliver a good result
+* for the first call
+*/
+   state->ber_prev = 0;
+
} else {
ret = si2165_readreg8(state, REG_BER_AVAIL, );
if (ret < 0)
@@ -805,6 +814,22 @@ static int si2165_read_snr(struct dvb_frontend *fe, u16 
*snr)
return 0;
 }
 
+static int si2165_read_ber(struct dvb_frontend *fe, u32 *ber)
+{
+   struct si2165_state *state = fe->demodulator_priv;
+   struct dtv_frontend_properties *c = >dtv_property_cache;
+
+   if (c->post_bit_error.stat[0].scale != FE_SCALE_COUNTER) {
+   *ber = 0;
+   return 0;
+   }
+
+   *ber = c->post_bit_error.stat[0].uvalue - state->ber_prev;
+   state->ber_prev = c->post_bit_error.stat[0].uvalue;
+
+   return 0;
+}
+
 static int si2165_set_oversamp(struct si2165_state *state, u32 dvb_rate)
 {
u64 oversamp;
@@ -1123,6 +1148,7 @@ static const struct dvb_frontend_ops si2165_ops = {
.set_frontend  = si2165_set_frontend,
.read_status   = si2165_read_status,
.read_snr  = si2165_read_snr,
+   .read_ber  = si2165_read_ber,
 };
 
 static int si2165_probe(struct i2c_client *client,
-- 
2.15.0

[PATCH 06/15] si2165: improve read_status

[Matthias Schwarzott]

Use check_signal register for DVB-T additionally.
For DVB-C use ps_lock additionally.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c  | 41 ++-
 drivers/media/dvb-frontends/si2165_priv.h |  2 ++
 2 files changed, 37 insertions(+), 6 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index b2541c1fe554..f8d7595a25d4 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -651,18 +651,47 @@ static int si2165_sleep(struct dvb_frontend *fe)
 static int si2165_read_status(struct dvb_frontend *fe, enum fe_status *status)
 {
int ret;
-   u8 fec_lock = 0;
+   u8 u8tmp;
struct si2165_state *state = fe->demodulator_priv;
+   struct dtv_frontend_properties *p = >dtv_property_cache;
+   u32 delsys = p->delivery_system;
 
-   if (!state->has_dvbt)
-   return -EINVAL;
+   *status = 0;
+
+   switch (delsys) {
+   case SYS_DVBT:
+   /* check fast signal type */
+   ret = si2165_readreg8(state, REG_CHECK_SIGNAL, );
+   if (ret < 0)
+   return ret;
+   switch (u8tmp & 0x3) {
+   case 0: /* searching */
+   case 1: /* nothing */
+   break;
+   case 2: /* digital signal */
+   *status |= FE_HAS_SIGNAL | FE_HAS_CARRIER;
+   break;
+   }
+   break;
+   case SYS_DVBC_ANNEX_A:
+   /* check packet sync lock */
+   ret = si2165_readreg8(state, REG_PS_LOCK, );
+   if (ret < 0)
+   return ret;
+   if (u8tmp & 0x01) {
+   *status |= FE_HAS_SIGNAL;
+   *status |= FE_HAS_CARRIER;
+   *status |= FE_HAS_VITERBI;
+   *status |= FE_HAS_SYNC;
+   }
+   break;
+   }
 
/* check fec_lock */
-   ret = si2165_readreg8(state, REG_FEC_LOCK, _lock);
+   ret = si2165_readreg8(state, REG_FEC_LOCK, );
if (ret < 0)
return ret;
-   *status = 0;
-   if (fec_lock & 0x01) {
+   if (u8tmp & 0x01) {
*status |= FE_HAS_SIGNAL;
*status |= FE_HAS_CARRIER;
*status |= FE_HAS_VITERBI;
diff --git a/drivers/media/dvb-frontends/si2165_priv.h 
b/drivers/media/dvb-frontends/si2165_priv.h
index da8bbda8a4e3..47f18ff69fe5 100644
--- a/drivers/media/dvb-frontends/si2165_priv.h
+++ b/drivers/media/dvb-frontends/si2165_priv.h
@@ -93,6 +93,8 @@ struct si2165_config {
 #define REG_GP_REG0_LSB0x0384
 #define REG_GP_REG0_MSB0x0387
 #define REG_CRC0x037a
+#define REG_CHECK_SIGNAL   0x03a8
+#define REG_PS_LOCK0x0440
 #define REG_BER_PKT0x0470
 #define REG_FEC_LOCK   0x04e0
 #define REG_TS_DATA_MODE   0x04e4
-- 
2.15.0

[PATCH 10/15] cx23885: Use semicolon after assignment instead of comma

[Matthias Schwarzott]

End assignments by semicolon instead of comma.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/pci/cx23885/cx23885-dvb.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c 
b/drivers/media/pci/cx23885/cx23885-dvb.c
index b33ded461308..67ad04138183 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -1852,8 +1852,8 @@ static int dvb_register(struct cx23885_tsport *port)
/* attach frontend */
memset(_pdata, 0, sizeof(si2165_pdata));
si2165_pdata.fe = >dvb.frontend;
-   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL,
-   si2165_pdata.ref_freq_hz = 1600,
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL;
+   si2165_pdata.ref_freq_hz = 1600;
memset(, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "si2165", I2C_NAME_SIZE);
info.addr = 0x64;
-- 
2.15.0

[PATCH 12/15] si2165: add DVBv5 BER statistics

[Matthias Schwarzott]

Add support for BER statistics.
Configure a measurement period of 3 packets.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c  | 57 +--
 drivers/media/dvb-frontends/si2165_priv.h | 11 ++
 2 files changed, 66 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 777b7d049ae7..1cd2120f5dc4 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -594,8 +594,9 @@ static int si2165_init(struct dvb_frontend *fe)
if (ret < 0)
goto error;
 
-   /* ber_pkt */
-   ret = si2165_writereg16(state, REG_BER_PKT, 0x7530);
+   /* ber_pkt - default 65535 */
+   ret = si2165_writereg16(state, REG_BER_PKT,
+   STATISTICS_PERIOD_PKT_COUNT);
if (ret < 0)
goto error;
 
@@ -642,6 +643,10 @@ static int si2165_init(struct dvb_frontend *fe)
c = >fe.dtv_property_cache;
c->cnr.len = 1;
c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_error.len = 1;
+   c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_count.len = 1;
+   c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
return 0;
 error:
@@ -738,6 +743,54 @@ static int si2165_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
} else
c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
 
+   /* BER */
+   if (*status & FE_HAS_VITERBI) {
+   if (c->post_bit_error.stat[0].scale == FE_SCALE_NOT_AVAILABLE) {
+   /* start new sampling period to get rid of old data*/
+   ret = si2165_writereg8(state, REG_BER_RST, 0x01);
+   if (ret < 0)
+   return ret;
+
+   /* set scale to enter read code on next call */
+   c->post_bit_error.stat[0].scale = FE_SCALE_COUNTER;
+   c->post_bit_count.stat[0].scale = FE_SCALE_COUNTER;
+   c->post_bit_error.stat[0].uvalue = 0;
+   c->post_bit_count.stat[0].uvalue = 0;
+
+   } else {
+   ret = si2165_readreg8(state, REG_BER_AVAIL, );
+   if (ret < 0)
+   return ret;
+
+   if (u8tmp & 1) {
+   u32 biterrcnt;
+
+   ret = si2165_readreg24(state, REG_BER_BIT,
+   );
+   if (ret < 0)
+   return ret;
+
+   c->post_bit_error.stat[0].uvalue +=
+   biterrcnt;
+   c->post_bit_count.stat[0].uvalue +=
+   STATISTICS_PERIOD_BIT_COUNT;
+
+   /* start new sampling period */
+   ret = si2165_writereg8(state,
+   REG_BER_RST, 0x01);
+   if (ret < 0)
+   return ret;
+
+   dev_dbg(>client->dev,
+   "post_bit_error=%u post_bit_count=%u\n",
+   biterrcnt, STATISTICS_PERIOD_BIT_COUNT);
+   }
+   }
+   } else {
+   c->post_bit_error.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   c->post_bit_count.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+   }
+
return 0;
 }
 
diff --git a/drivers/media/dvb-frontends/si2165_priv.h 
b/drivers/media/dvb-frontends/si2165_priv.h
index 9d79e86d04c2..8c6fbfe441ff 100644
--- a/drivers/media/dvb-frontends/si2165_priv.h
+++ b/drivers/media/dvb-frontends/si2165_priv.h
@@ -38,6 +38,9 @@ struct si2165_config {
bool inversion;
 };
 
+#define STATISTICS_PERIOD_PKT_COUNT3u
+#define STATISTICS_PERIOD_BIT_COUNT(STATISTICS_PERIOD_PKT_COUNT * 204 * 8)
+
 #define REG_CHIP_MODE  0x
 #define REG_CHIP_REVCODE   0x0023
 #define REV_CHIP_TYPE  0x0118
@@ -95,8 +98,16 @@ struct si2165_config {
 #define REG_GP_REG0_MSB0x0387
 #define REG_CRC0x037a
 #define REG_CHECK_SIGNAL   0x03a8
+#define REG_CBER_RST   0x0424
+#define REG_CBER_BIT   0x0428
+#define REG_CBER_ERR   0x0430
+#define REG_CBER_AVAIL 0x0434
 #define REG_PS_LOCK0x0440
+#define REG_UNCOR_CNT  0x0468
+#define REG_BER_RST0x046c
 #d

[PATCH 13/15] si2165: add DVBv3 wrapper for C/N statistics

[Matthias Schwarzott]

Add read_snr function that reads from property cache to support DVBv3.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 1cd2120f5dc4..ceb5a2bb0dea 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -794,6 +794,17 @@ static int si2165_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
return 0;
 }
 
+static int si2165_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+   struct dtv_frontend_properties *c = >dtv_property_cache;
+
+   if (c->cnr.stat[0].scale == FE_SCALE_DECIBEL)
+   *snr = div_s64(c->cnr.stat[0].svalue, 100);
+   else
+   *snr = 0;
+   return 0;
+}
+
 static int si2165_set_oversamp(struct si2165_state *state, u32 dvb_rate)
 {
u64 oversamp;
@@ -,6 +1122,7 @@ static const struct dvb_frontend_ops si2165_ops = {
 
.set_frontend  = si2165_set_frontend,
.read_status   = si2165_read_status,
+   .read_snr  = si2165_read_snr,
 };
 
 static int si2165_probe(struct i2c_client *client,
-- 
2.15.0

[PATCH 11/15] si2165: add DVBv5 C/N statistics for DVB-C

[Matthias Schwarzott]

Add C/N statistics in dB to read_status (DVBv5).

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c  | 43 +--
 drivers/media/dvb-frontends/si2165_priv.h |  1 +
 2 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 30ceba664f5f..777b7d049ae7 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -116,6 +116,17 @@ static int si2165_readreg16(struct si2165_state *state,
return ret;
 }
 
+static int si2165_readreg24(struct si2165_state *state,
+   const u16 reg, u32 *val)
+{
+   u8 buf[3];
+
+   int ret = si2165_read(state, reg, buf, 3);
+   *val = buf[0] | buf[1] << 8 | buf[2] << 16;
+   dev_dbg(>client->dev, "reg read: R(0x%04x)=0x%06x\n", reg, *val);
+   return ret;
+}
+
 static int si2165_writereg8(struct si2165_state *state, const u16 reg, u8 val)
 {
return regmap_write(state->regmap, reg, val);
@@ -518,6 +529,7 @@ static int si2165_init(struct dvb_frontend *fe)
 {
int ret = 0;
struct si2165_state *state = fe->demodulator_priv;
+   struct dtv_frontend_properties *c = >dtv_property_cache;
u8 val;
u8 patch_version = 0x00;
 
@@ -627,6 +639,10 @@ static int si2165_init(struct dvb_frontend *fe)
if (ret < 0)
return ret;
 
+   c = >fe.dtv_property_cache;
+   c->cnr.len = 1;
+   c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
return 0;
 error:
return ret;
@@ -652,9 +668,10 @@ static int si2165_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
 {
int ret;
u8 u8tmp;
+   u32 u32tmp;
struct si2165_state *state = fe->demodulator_priv;
-   struct dtv_frontend_properties *p = >dtv_property_cache;
-   u32 delsys = p->delivery_system;
+   struct dtv_frontend_properties *c = >dtv_property_cache;
+   u32 delsys = c->delivery_system;
 
*status = 0;
 
@@ -699,6 +716,28 @@ static int si2165_read_status(struct dvb_frontend *fe, 
enum fe_status *status)
*status |= FE_HAS_LOCK;
}
 
+   /* CNR */
+   if (delsys == SYS_DVBC_ANNEX_A && *status & FE_HAS_VITERBI) {
+   ret = si2165_readreg24(state, REG_C_N, );
+   if (ret < 0)
+   return ret;
+   /*
+* svalue =
+* 1000 * c_n/dB =
+* 1000 * 10 * log10(2^24 / regval) =
+* 1000 * 10 * (log10(2^24) - log10(regval)) =
+* 1000 * 10 * (intlog10(2^24) - intlog10(regval)) / 2^24
+*
+* intlog10(x) = log10(x) * 2^24
+* intlog10(2^24) = log10(2^24) * 2^24 = 121210686
+*/
+   u32tmp = (1000 * 10 * (121210686 - (u64)intlog10(u32tmp)))
+   >> 24;
+   c->cnr.stat[0].scale = FE_SCALE_DECIBEL;
+   c->cnr.stat[0].svalue = u32tmp;
+   } else
+   c->cnr.stat[0].scale = FE_SCALE_NOT_AVAILABLE;
+
return 0;
 }
 
diff --git a/drivers/media/dvb-frontends/si2165_priv.h 
b/drivers/media/dvb-frontends/si2165_priv.h
index 47f18ff69fe5..9d79e86d04c2 100644
--- a/drivers/media/dvb-frontends/si2165_priv.h
+++ b/drivers/media/dvb-frontends/si2165_priv.h
@@ -74,6 +74,7 @@ struct si2165_config {
 #define REG_KP_LOCK0x023a
 #define REG_UNKNOWN_24C0x024c
 #define REG_CENTRAL_TAP0x0261
+#define REG_C_N0x026c
 #define REG_EQ_AUTO_CONTROL0x0278
 #define REG_UNKNOWN_27C0x027c
 #define REG_START_SYNCHRO  0x02e0
-- 
2.15.0

[PATCH 03/15] si2165: Make checkpatch happy

[Matthias Schwarzott]

Fix almost all of checkpatch --strict warnings.

The remaining warnings are about:
* macro REG16 (should be enclosed in parentheses)
* macro REG16 (Macro argument reuse)

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c  | 87 ---
 drivers/media/dvb-frontends/si2165.h  | 37 ++---
 drivers/media/dvb-frontends/si2165_priv.h | 35 +++--
 drivers/media/pci/cx23885/cx23885-dvb.c   |  2 +-
 drivers/media/usb/cx231xx/cx231xx-dvb.c   |  4 +-
 5 files changed, 86 insertions(+), 79 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 7110b3b37f23..6b22d079ecef 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -63,11 +63,12 @@ struct si2165_state {
 };
 
 static int si2165_write(struct si2165_state *state, const u16 reg,
-  const u8 *src, const int count)
+   const u8 *src, const int count)
 {
int ret;
 
-   dev_dbg(>client->dev, "i2c write: reg: 0x%04x, data: %*ph\n", 
reg, count, src);
+   dev_dbg(>client->dev, "i2c write: reg: 0x%04x, data: %*ph\n",
+   reg, count, src);
 
ret = regmap_bulk_write(state->regmap, reg, src, count);
 
@@ -88,13 +89,14 @@ static int si2165_read(struct si2165_state *state,
return ret;
}
 
-   dev_dbg(>client->dev, "i2c read: reg: 0x%04x, data: %*ph\n", 
reg, count, val);
+   dev_dbg(>client->dev, "i2c read: reg: 0x%04x, data: %*ph\n",
+   reg, count, val);
 
return 0;
 }
 
 static int si2165_readreg8(struct si2165_state *state,
-  const u16 reg, u8 *val)
+  const u16 reg, u8 *val)
 {
unsigned int val_tmp;
int ret = regmap_read(state->regmap, reg, _tmp);
@@ -104,7 +106,7 @@ static int si2165_readreg8(struct si2165_state *state,
 }
 
 static int si2165_readreg16(struct si2165_state *state,
-  const u16 reg, u16 *val)
+   const u16 reg, u16 *val)
 {
u8 buf[2];
 
@@ -161,7 +163,9 @@ static int si2165_writereg_mask8(struct si2165_state 
*state, const u16 reg,
return si2165_writereg8(state, reg, val);
 }
 
-#define REG16(reg, val) { (reg), (val) & 0xff }, { (reg)+1, (val)>>8 & 0xff }
+#define REG16(reg, val) \
+   { (reg), (val) & 0xff }, \
+   { (reg) + 1, (val) >> 8 & 0xff }
 struct si2165_reg_value_pair {
u16 reg;
u8 val;
@@ -191,7 +195,7 @@ static int si2165_get_tune_settings(struct dvb_frontend *fe,
 
 static int si2165_init_pll(struct si2165_state *state)
 {
-   u32 ref_freq_Hz = state->config.ref_freq_Hz;
+   u32 ref_freq_hz = state->config.ref_freq_hz;
u8 divr = 1; /* 1..7 */
u8 divp = 1; /* only 1 or 4 */
u8 divn = 56; /* 1..63 */
@@ -203,7 +207,7 @@ static int si2165_init_pll(struct si2165_state *state)
 * hardcoded values can be deleted if calculation is verified
 * or it yields the same values as the windows driver
 */
-   switch (ref_freq_Hz) {
+   switch (ref_freq_hz) {
case 1600u:
divn = 56;
break;
@@ -214,23 +218,23 @@ static int si2165_init_pll(struct si2165_state *state)
break;
default:
/* ref_freq / divr must be between 4 and 16 MHz */
-   if (ref_freq_Hz > 1600u)
+   if (ref_freq_hz > 1600u)
divr = 2;
 
/*
 * now select divn and divp such that
 * fvco is in 1624..1824 MHz
 */
-   if (162400u * divr > ref_freq_Hz * 2u * 63u)
+   if (162400u * divr > ref_freq_hz * 2u * 63u)
divp = 4;
 
/* is this already correct regarding rounding? */
-   divn = 162400u * divr / (ref_freq_Hz * 2u * divp);
+   divn = 162400u * divr / (ref_freq_hz * 2u * divp);
break;
}
 
/* adc_clk and sys_clk depend on xtal and pll settings */
-   state->fvco_hz = ref_freq_Hz / divr
+   state->fvco_hz = ref_freq_hz / divr
* 2u * divn * divp;
state->adc_clk = state->fvco_hz / (divm * 4u);
state->sys_clk = state->fvco_hz / (divl * 2u);
@@ -272,7 +276,8 @@ static int si2165_wait_init_done(struct si2165_state *state)
 }
 
 static int si2165_upload_firmware_block(struct si2165_state *state,
-   const u8 *data, u32 len, u32 *poffset, u32 block_count)
+   const u8 *data, u32 len, u32 *poffset,
+   u32 block_count)
 {
int ret;
u8 buf_ctrl[4] = { 0x00, 0x00, 0x00, 0xc0 };
@@ -286,

[PATCH 08/15] si2165: Use constellation from property cache instead of hardcoded QAM256

[Matthias Schwarzott]

Use constellation from property cache instead of always setting it to
QAM256.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 29 ++---
 1 file changed, 26 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 0b801bad5802..30ceba664f5f 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -834,13 +834,11 @@ static const struct si2165_reg_value_pair dvbc_regs[] = {
{ REG_KP_LOCK, 0x05 },
{ REG_CENTRAL_TAP, 0x09 },
REG16(REG_UNKNOWN_350, 0x3e80),
-   { REG_REQ_CONSTELLATION, 0x00 },
 
{ REG_AUTO_RESET, 0x01 },
REG16(REG_UNKNOWN_24C, 0x),
REG16(REG_UNKNOWN_27C, 0x),
{ REG_SWEEP_STEP, 0x03 },
-   { REG_REQ_CONSTELLATION, 0x0b },
{ REG_AGC_IF_TRI, 0x00 },
 };
 
@@ -850,6 +848,7 @@ static int si2165_set_frontend_dvbc(struct dvb_frontend *fe)
int ret;
struct dtv_frontend_properties *p = >dtv_property_cache;
const u32 dvb_rate = p->symbol_rate;
+   u8 u8tmp;
 
if (!state->has_dvbc)
return -EINVAL;
@@ -866,6 +865,31 @@ static int si2165_set_frontend_dvbc(struct dvb_frontend 
*fe)
if (ret < 0)
return ret;
 
+   switch (p->modulation) {
+   case QPSK:
+   u8tmp = 0x3;
+   break;
+   case QAM_16:
+   u8tmp = 0x7;
+   break;
+   case QAM_32:
+   u8tmp = 0x8;
+   break;
+   case QAM_64:
+   u8tmp = 0x9;
+   break;
+   case QAM_128:
+   u8tmp = 0xa;
+   break;
+   case QAM_256:
+   default:
+   u8tmp = 0xb;
+   break;
+   }
+   ret = si2165_writereg8(state, REG_REQ_CONSTELLATION, u8tmp);
+   if (ret < 0)
+   return ret;
+
ret = si2165_writereg32(state, REG_LOCK_TIMEOUT, 0x007a1200);
if (ret < 0)
return ret;
@@ -981,7 +1005,6 @@ static const struct dvb_frontend_ops si2165_ops = {
FE_CAN_QAM_64 |
FE_CAN_QAM_128 |
FE_CAN_QAM_256 |
-   FE_CAN_QAM_AUTO |
FE_CAN_GUARD_INTERVAL_AUTO |
FE_CAN_HIERARCHY_AUTO |
FE_CAN_MUTE_TS |
-- 
2.15.0

[PATCH 04/15] si2165: define register macros

[Matthias Schwarzott]

Convert register numbers to macros.

Correctness verified by comparing the disassembly before and after.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c  | 206 +++---
 drivers/media/dvb-frontends/si2165_priv.h |  65 ++
 2 files changed, 169 insertions(+), 102 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 6b22d079ecef..0f5325798bd2 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -239,18 +239,18 @@ static int si2165_init_pll(struct si2165_state *state)
state->adc_clk = state->fvco_hz / (divm * 4u);
state->sys_clk = state->fvco_hz / (divl * 2u);
 
-   /* write pll registers 0x00a0..0x00a3 at once */
+   /* write all 4 pll registers 0x00a0..0x00a3 at once */
buf[0] = divl;
buf[1] = divm;
buf[2] = (divn & 0x3f) | ((divp == 1) ? 0x40 : 0x00) | 0x80;
buf[3] = divr;
-   return si2165_write(state, 0x00a0, buf, 4);
+   return si2165_write(state, REG_PLL_DIVL, buf, 4);
 }
 
 static int si2165_adjust_pll_divl(struct si2165_state *state, u8 divl)
 {
state->sys_clk = state->fvco_hz / (divl * 2u);
-   return si2165_writereg8(state, 0x00a0, divl); /* pll_divl */
+   return si2165_writereg8(state, REG_PLL_DIVL, divl);
 }
 
 static u32 si2165_get_fe_clk(struct si2165_state *state)
@@ -266,7 +266,7 @@ static int si2165_wait_init_done(struct si2165_state *state)
int i;
 
for (i = 0; i < 3; ++i) {
-   si2165_readreg8(state, 0x0054, );
+   si2165_readreg8(state, REG_INIT_DONE, );
if (val == 0x01)
return 0;
usleep_range(1000, 5);
@@ -315,17 +315,18 @@ static int si2165_upload_firmware_block(struct 
si2165_state *state,
 
buf_ctrl[0] = wordcount - 1;
 
-   ret = si2165_write(state, 0x0364, buf_ctrl, 4);
+   ret = si2165_write(state, REG_DCOM_CONTROL_BYTE, buf_ctrl, 4);
if (ret < 0)
goto error;
-   ret = si2165_write(state, 0x0368, data + offset + 4, 4);
+   ret = si2165_write(state, REG_DCOM_ADDR, data + offset + 4, 4);
if (ret < 0)
goto error;
 
offset += 8;
 
while (wordcount > 0) {
-   ret = si2165_write(state, 0x36c, data + offset, 4);
+   ret = si2165_write(state, REG_DCOM_DATA,
+  data + offset, 4);
if (ret < 0)
goto error;
wordcount--;
@@ -415,26 +416,26 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
 
/* start uploading fw */
/* boot/wdog status */
-   ret = si2165_writereg8(state, 0x0341, 0x00);
+   ret = si2165_writereg8(state, REG_WDOG_AND_BOOT, 0x00);
if (ret < 0)
goto error;
/* reset */
-   ret = si2165_writereg8(state, 0x00c0, 0x00);
+   ret = si2165_writereg8(state, REG_RST_ALL, 0x00);
if (ret < 0)
goto error;
/* boot/wdog status */
-   ret = si2165_readreg8(state, 0x0341, val);
+   ret = si2165_readreg8(state, REG_WDOG_AND_BOOT, val);
if (ret < 0)
goto error;
 
/* enable reset on error */
-   ret = si2165_readreg8(state, 0x035c, val);
+   ret = si2165_readreg8(state, REG_EN_RST_ERROR, val);
if (ret < 0)
goto error;
-   ret = si2165_readreg8(state, 0x035c, val);
+   ret = si2165_readreg8(state, REG_EN_RST_ERROR, val);
if (ret < 0)
goto error;
-   ret = si2165_writereg8(state, 0x035c, 0x02);
+   ret = si2165_writereg8(state, REG_EN_RST_ERROR, 0x02);
if (ret < 0)
goto error;
 
@@ -448,12 +449,12 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
if (ret < 0)
goto error;
 
-   ret = si2165_writereg8(state, 0x0344, patch_version);
+   ret = si2165_writereg8(state, REG_PATCH_VERSION, patch_version);
if (ret < 0)
goto error;
 
/* reset crc */
-   ret = si2165_writereg8(state, 0x0379, 0x01);
+   ret = si2165_writereg8(state, REG_RST_CRC, 0x01);
if (ret)
goto error;
 
@@ -466,7 +467,7 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
}
 
/* read crc */
-   ret = si2165_readreg16(state, 0x037a, );
+   ret = si2165_readreg16(state, REG_CRC, );
if (ret)
goto error;
 
@@ -491,12 +492,12 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
}
 
/* reset watchdog error register */
-   ret = si2165_writereg_mask8(st

[PATCH 05/15] si2165: move ts parallel mode setting to the ts init code

[Matthias Schwarzott]

The TS parallel mode setting should be where all other TS settings are written.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 0f5325798bd2..b2541c1fe554 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -621,6 +621,9 @@ static int si2165_init(struct dvb_frontend *fe)
if (ret < 0)
return ret;
ret = si2165_writereg8(state, REG_TS_CLK_MODE, 0x01);
+   if (ret < 0)
+   return ret;
+   ret = si2165_writereg8(state, REG_TS_PARALLEL_MODE, 0x00);
if (ret < 0)
return ret;
 
@@ -723,7 +726,6 @@ static int si2165_set_if_freq_shift(struct si2165_state 
*state)
 static const struct si2165_reg_value_pair dvbt_regs[] = {
/* standard = DVB-T */
{ REG_DVB_STANDARD, 0x01 },
-   { REG_TS_PARALLEL_MODE, 0x00 },
/* impulsive_noise_remover */
{ REG_IMPULSIVE_NOISE_REM, 0x01 },
{ REG_AUTO_RESET, 0x00 },
@@ -786,7 +788,6 @@ static int si2165_set_frontend_dvbt(struct dvb_frontend *fe)
 static const struct si2165_reg_value_pair dvbc_regs[] = {
/* standard = DVB-C */
{ REG_DVB_STANDARD, 0x05 },
-   { REG_TS_PARALLEL_MODE, 0x00 },
 
/* agc2 */
{ REG_AGC2_MIN, 0x50 },
-- 
2.15.0

[PATCH 02/15] si2165: Convert debug printk to dev_dbg

[Matthias Schwarzott]

Removed module parameter debug and the conditions based on it.
Now it can be configured via dynamic debug.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 79 +++-
 1 file changed, 15 insertions(+), 64 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 9471846ad424..7110b3b37f23 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -62,58 +62,12 @@ struct si2165_state {
bool firmware_loaded;
 };
 
-#define DEBUG_OTHER0x01
-#define DEBUG_I2C_WRITE0x02
-#define DEBUG_I2C_READ 0x04
-#define DEBUG_REG_READ 0x08
-#define DEBUG_REG_WRITE0x10
-#define DEBUG_FW_LOAD  0x20
-
-static int debug = 0x00;
-
-#define dprintk(args...) \
-   do { \
-   if (debug & DEBUG_OTHER) \
-   printk(KERN_DEBUG "si2165: " args); \
-   } while (0)
-
-#define deb_i2c_write(args...) \
-   do { \
-   if (debug & DEBUG_I2C_WRITE) \
-   printk(KERN_DEBUG "si2165: i2c write: " args); \
-   } while (0)
-
-#define deb_i2c_read(args...) \
-   do { \
-   if (debug & DEBUG_I2C_READ) \
-   printk(KERN_DEBUG "si2165: i2c read: " args); \
-   } while (0)
-
-#define deb_readreg(args...) \
-   do { \
-   if (debug & DEBUG_REG_READ) \
-   printk(KERN_DEBUG "si2165: reg read: " args); \
-   } while (0)
-
-#define deb_writereg(args...) \
-   do { \
-   if (debug & DEBUG_REG_WRITE) \
-   printk(KERN_DEBUG "si2165: reg write: " args); \
-   } while (0)
-
-#define deb_fw_load(args...) \
-   do { \
-   if (debug & DEBUG_FW_LOAD) \
-   printk(KERN_DEBUG "si2165: fw load: " args); \
-   } while (0)
-
 static int si2165_write(struct si2165_state *state, const u16 reg,
   const u8 *src, const int count)
 {
int ret;
 
-   if (debug & DEBUG_I2C_WRITE)
-   deb_i2c_write("reg: 0x%04x, data: %*ph\n", reg, count, src);
+   dev_dbg(>client->dev, "i2c write: reg: 0x%04x, data: %*ph\n", 
reg, count, src);
 
ret = regmap_bulk_write(state->regmap, reg, src, count);
 
@@ -134,8 +88,7 @@ static int si2165_read(struct si2165_state *state,
return ret;
}
 
-   if (debug & DEBUG_I2C_READ)
-   deb_i2c_read("reg: 0x%04x, data: %*ph\n", reg, count, val);
+   dev_dbg(>client->dev, "i2c read: reg: 0x%04x, data: %*ph\n", 
reg, count, val);
 
return 0;
 }
@@ -146,7 +99,7 @@ static int si2165_readreg8(struct si2165_state *state,
unsigned int val_tmp;
int ret = regmap_read(state->regmap, reg, _tmp);
*val = (u8)val_tmp;
-   deb_readreg("R(0x%04x)=0x%02x\n", reg, *val);
+   dev_dbg(>client->dev, "reg read: R(0x%04x)=0x%02x\n", reg, *val);
return ret;
 }
 
@@ -157,7 +110,7 @@ static int si2165_readreg16(struct si2165_state *state,
 
int ret = si2165_read(state, reg, buf, 2);
*val = buf[0] | buf[1] << 8;
-   deb_readreg("R(0x%04x)=0x%04x\n", reg, *val);
+   dev_dbg(>client->dev, "reg read: R(0x%04x)=0x%04x\n", reg, *val);
return ret;
 }
 
@@ -332,12 +285,12 @@ static int si2165_upload_firmware_block(struct 
si2165_state *state,
if (len % 4 != 0)
return -EINVAL;
 
-   deb_fw_load(
-   "si2165_upload_firmware_block called with len=0x%x offset=0x%x 
blockcount=0x%x\n",
+   dev_dbg(>client->dev,
+   "fw load: si2165_upload_firmware_block called with len=0x%x 
offset=0x%x blockcount=0x%x\n",
len, offset, block_count);
while (offset+12 <= len && cur_block < block_count) {
-   deb_fw_load(
-   "si2165_upload_firmware_block in while len=0x%x 
offset=0x%x cur_block=0x%x blockcount=0x%x\n",
+   dev_dbg(>client->dev,
+   "fw load: si2165_upload_firmware_block in while 
len=0x%x offset=0x%x cur_block=0x%x blockcount=0x%x\n",
len, offset, cur_block, block_count);
wordcount = data[offset];
if (wordcount < 1 || data[offset+1] ||
@@ -376,14 +329,15 @@ static int si2165_upload_firmware_block(struct 
si2165_state *state,
cur_block++;
}
 
-   deb_fw_load(
-   "si2165_upload_firmware_block after while len=0x%x offset=0x%x 
cur_block=0x%x blockcount=0x%x\n",
+   dev_dbg(>client->dev,
+   "fw load: si2165_upload_

[PATCH 09/15] cx231xx: Use semicolon after assignment instead of comma

[Matthias Schwarzott]

End assignments by semicolon instead of comma.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/usb/cx231xx/cx231xx-dvb.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index 4e462edf044f..5cee642dff06 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -762,8 +762,8 @@ static int dvb_init(struct cx231xx *dev)
/* attach demod */
memset(_pdata, 0, sizeof(si2165_pdata));
si2165_pdata.fe = >dvb->frontend;
-   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL,
-   si2165_pdata.ref_freq_hz = 1600,
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_XTAL;
+   si2165_pdata.ref_freq_hz = 1600;
 
memset(, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "si2165", I2C_NAME_SIZE);
@@ -809,8 +809,8 @@ static int dvb_init(struct cx231xx *dev)
/* attach demod */
memset(_pdata, 0, sizeof(si2165_pdata));
si2165_pdata.fe = >dvb->frontend;
-   si2165_pdata.chip_mode = SI2165_MODE_PLL_EXT,
-   si2165_pdata.ref_freq_hz = 2400,
+   si2165_pdata.chip_mode = SI2165_MODE_PLL_EXT;
+   si2165_pdata.ref_freq_hz = 2400;
 
memset(, 0, sizeof(struct i2c_board_info));
strlcpy(info.type, "si2165", I2C_NAME_SIZE);
-- 
2.15.0

[PATCH 07/15] si2165: Write const value for lock timeout

[Matthias Schwarzott]

The lock timeout should not depend on the bandwidth.
It should be either constant or depend on xtal frequency.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index f8d7595a25d4..0b801bad5802 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -850,7 +850,6 @@ static int si2165_set_frontend_dvbc(struct dvb_frontend *fe)
int ret;
struct dtv_frontend_properties *p = >dtv_property_cache;
const u32 dvb_rate = p->symbol_rate;
-   const u32 bw_hz = p->bandwidth_hz;
 
if (!state->has_dvbc)
return -EINVAL;
@@ -867,7 +866,7 @@ static int si2165_set_frontend_dvbc(struct dvb_frontend *fe)
if (ret < 0)
return ret;
 
-   ret = si2165_writereg32(state, REG_LOCK_TIMEOUT, bw_hz);
+   ret = si2165_writereg32(state, REG_LOCK_TIMEOUT, 0x007a1200);
if (ret < 0)
return ret;
 
-- 
2.15.0

[PATCH 01/15] si2165: Remove redundant KBUILD_MODNAME from dev_* logging

[Matthias Schwarzott]

Remove redundant repeated module name from messages.

Before:
  si2165 8-0064: si2165: fw load finished

After:
  si2165 8-0064: fw load finished

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/dvb-frontends/si2165.c | 69 
 1 file changed, 31 insertions(+), 38 deletions(-)

diff --git a/drivers/media/dvb-frontends/si2165.c 
b/drivers/media/dvb-frontends/si2165.c
index 528b82a5dd46..9471846ad424 100644
--- a/drivers/media/dvb-frontends/si2165.c
+++ b/drivers/media/dvb-frontends/si2165.c
@@ -1,7 +1,7 @@
 /*
  *  Driver for Silicon Labs Si2161 DVB-T and Si2165 DVB-C/-T Demodulator
  *
- *  Copyright (C) 2013-2014 Matthias Schwarzott <z...@gentoo.org>
+ *  Copyright (C) 2013-2017 Matthias Schwarzott <z...@gentoo.org>
  *
  *  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
@@ -314,8 +314,7 @@ static int si2165_wait_init_done(struct si2165_state *state)
return 0;
usleep_range(1000, 5);
}
-   dev_err(>client->dev, "%s: init_done was not set\n",
-   KBUILD_MODNAME);
+   dev_err(>client->dev, "init_done was not set\n");
return ret;
 }
 
@@ -344,15 +343,15 @@ static int si2165_upload_firmware_block(struct 
si2165_state *state,
if (wordcount < 1 || data[offset+1] ||
data[offset+2] || data[offset+3]) {
dev_warn(>client->dev,
-"%s: bad fw data[0..3] = %*ph\n",
-   KBUILD_MODNAME, 4, data);
+"bad fw data[0..3] = %*ph\n",
+4, data);
return -EINVAL;
}
 
if (offset + 8 + wordcount * 4 > len) {
dev_warn(>client->dev,
-"%s: len is too small for block len=%d, 
wordcount=%d\n",
-   KBUILD_MODNAME, len, wordcount);
+"len is too small for block len=%d, 
wordcount=%d\n",
+   len, wordcount);
return -EINVAL;
}
 
@@ -413,43 +412,40 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
fw_file = SI2165_FIRMWARE_REV_D;
break;
default:
-   dev_info(>client->dev, "%s: no firmware file for 
revision=%d\n",
-   KBUILD_MODNAME, state->chip_revcode);
+   dev_info(>client->dev, "no firmware file for 
revision=%d\n",
+   state->chip_revcode);
return 0;
}
 
/* request the firmware, this will block and timeout */
ret = request_firmware(, fw_file, >client->dev);
if (ret) {
-   dev_warn(>client->dev, "%s: firmware file '%s' not 
found\n",
-   KBUILD_MODNAME, fw_file);
+   dev_warn(>client->dev, "firmware file '%s' not found\n",
+   fw_file);
goto error;
}
 
data = fw->data;
len = fw->size;
 
-   dev_info(>client->dev, "%s: downloading firmware from file '%s' 
size=%d\n",
-   KBUILD_MODNAME, fw_file, len);
+   dev_info(>client->dev, "downloading firmware from file '%s' 
size=%d\n",
+   fw_file, len);
 
if (len % 4 != 0) {
-   dev_warn(>client->dev, "%s: firmware size is not 
multiple of 4\n",
-   KBUILD_MODNAME);
+   dev_warn(>client->dev, "firmware size is not multiple of 
4\n");
ret = -EINVAL;
goto error;
}
 
/* check header (8 bytes) */
if (len < 8) {
-   dev_warn(>client->dev, "%s: firmware header is 
missing\n",
-   KBUILD_MODNAME);
+   dev_warn(>client->dev, "firmware header is missing\n");
ret = -EINVAL;
goto error;
}
 
if (data[0] != 1 || data[1] != 0) {
-   dev_warn(>client->dev, "%s: firmware file version is 
wrong\n",
-   KBUILD_MODNAME);
+   dev_warn(>client->dev, "firmware file version is 
wrong\n");
ret = -EINVAL;
goto error;
}
@@ -486,8 +482,8 @@ static int si2165_upload_firmware(struct si2165_state 
*state)
/* start right after the header */
offset = 8;
 
-   dev_info(>client->dev, "%s: si2165_upload_fir

[PATCH] build: add fwnode_property_get_reference_args if not defined

[Matthias Schwarzott]

Add function dummy that returns -ENODATA.
Copied struct fwnode_reference_args from include/linux/fwnode.h.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 v4l/compat.h  | 19 +++
 v4l/scripts/make_config_compat.pl |  1 +
 2 files changed, 20 insertions(+)

diff --git a/v4l/compat.h b/v4l/compat.h
index f788e79..eec2974 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -2212,4 +2212,23 @@ static inline void timer_setup(struct timer_list *timer,
 
 #endif
 
+#ifdef NEED_FWNODE_PROP_GET_REF_ARGS
+#define NR_FWNODE_REFERENCE_ARGS   8
+
+struct fwnode_reference_args {
+struct fwnode_handle *fwnode;
+/* unsigned int nargs; */
+unsigned int args[NR_FWNODE_REFERENCE_ARGS];
+};
+
+static inline int fwnode_property_get_reference_args(const struct 
fwnode_handle *fwnode,
+  const char *prop, const char *nargs_prop,
+  unsigned int nargs, unsigned int index,
+  struct fwnode_reference_args *args)
+{
+return -ENODATA;
+}
+
+#endif
+
 #endif /*  _COMPAT_H */
diff --git a/v4l/scripts/make_config_compat.pl 
b/v4l/scripts/make_config_compat.pl
index 62eb6b9..9752ddf 100644
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -707,6 +707,7 @@ sub check_other_dependencies()
check_files_for_func("U32_MAX", "NEED_U32_MAX", 
"include/linux/kernel.h");
check_files_for_func("bsearch", "NEED_BSEARCH", 
"include/linux/bsearch.h");
check_files_for_func("timer_setup", "NEED_TIMER_SETUP", 
"include/linux/timer.h");
+   check_files_for_func("fwnode_property_get_reference_args", 
"NEED_FWNODE_PROP_GET_REF_ARGS", "include/linux/property.h");
 
# For tests for uapi-dependent logic
check_files_for_func_uapi("usb_endpoint_maxp", 
"NEED_USB_ENDPOINT_MAXP", "usb/ch9.h");
-- 
2.15.0

[PATCH] build: Add support for timer_setup

[Matthias Schwarzott]

Literally copied the implementation from kernel
commit 686fef928bba6be13 (timer: Prepare to change timer callback argument type)

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 v4l/compat.h  | 17 +
 v4l/scripts/make_config_compat.pl |  1 +
 2 files changed, 18 insertions(+)

diff --git a/v4l/compat.h b/v4l/compat.h
index 3504288..f788e79 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -2195,4 +2195,21 @@ static inline void *bsearch(const void *key, const void 
*base, size_t num, size_
 }
 #endif
 
+#ifdef NEED_TIMER_SETUP
+#define TIMER_DATA_TYPEunsigned long
+#define TIMER_FUNC_TYPEvoid (*)(TIMER_DATA_TYPE)
+
+static inline void timer_setup(struct timer_list *timer,
+  void (*callback)(struct timer_list *),
+  unsigned int flags)
+{
+   __setup_timer(timer, (TIMER_FUNC_TYPE)callback,
+ (TIMER_DATA_TYPE)timer, flags);
+}
+
+#define from_timer(var, callback_timer, timer_fieldname) \
+   container_of(callback_timer, typeof(*var), timer_fieldname)
+
+#endif
+
 #endif /*  _COMPAT_H */
diff --git a/v4l/scripts/make_config_compat.pl 
b/v4l/scripts/make_config_compat.pl
index 8ebeea3..62eb6b9 100644
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -706,6 +706,7 @@ sub check_other_dependencies()
check_files_for_func("annotate_reachable", "NEED_ANNOTATE_REACHABLE", 
"include/linux/compiler.h");
check_files_for_func("U32_MAX", "NEED_U32_MAX", 
"include/linux/kernel.h");
check_files_for_func("bsearch", "NEED_BSEARCH", 
"include/linux/bsearch.h");
+   check_files_for_func("timer_setup", "NEED_TIMER_SETUP", 
"include/linux/timer.h");
 
# For tests for uapi-dependent logic
check_files_for_func_uapi("usb_endpoint_maxp", 
"NEED_USB_ENDPOINT_MAXP", "usb/ch9.h");
-- 
2.15.0

[PATCH] em28xx: Fix use-after-free when disconnecting

[Matthias Schwarzott]

Fix bug by moving the i2c_unregister_device calls after deregistration
of dvb frontend.

The new style i2c drivers already destroys the frontend object at
i2c_unregister_device time.
When the dvb frontend is unregistered afterwards it leads to this oops:

  [ 6058.866459] BUG: unable to handle kernel NULL pointer dereference at 
01f8
  [ 6058.866578] IP: dvb_frontend_stop+0x30/0xd0 [dvb_core]
  [ 6058.866644] PGD 0
  [ 6058.866646] P4D 0

  [ 6058.866726] Oops:  [#1] SMP
  [ 6058.866768] Modules linked in: rc_pinnacle_pctv_hd(O) em28xx_rc(O) 
si2157(O) si2168(O) em28xx_dvb(O) em28xx(O) si2165(O) a8293(O) tda10071(O) 
tea5767(O) tuner(O) cx23885(O) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) 
m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) 
videobuf2_memops(O) videobuf2_v4l2(O) videobuf2_core(O) videodev(O) media(O) 
bluetooth ecdh_generic ums_realtek uas rtl8192cu rtl_usb rtl8192c_common 
rtlwifi usb_storage snd_hda_codec_realtek snd_hda_codec_hdmi 
snd_hda_codec_generic i2c_mux snd_hda_intel snd_hda_codec snd_hwdep 
x86_pkg_temp_thermal snd_hda_core kvm_intel kvm irqbypass [last unloaded: 
videobuf2_memops]
  [ 6058.867497] CPU: 2 PID: 7349 Comm: kworker/2:0 Tainted: GW  O
4.13.9-gentoo #1
  [ 6058.867595] Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 
08/25/2014
  [ 6058.867692] Workqueue: usb_hub_wq hub_event
  [ 6058.867746] task: 88011a15e040 task.stack: c90003074000
  [ 6058.867825] RIP: 0010:dvb_frontend_stop+0x30/0xd0 [dvb_core]
  [ 6058.867896] RSP: 0018:c90003077b58 EFLAGS: 00010293
  [ 6058.867964] RAX:  RBX:  RCX: 
00010040001f
  [ 6058.868056] RDX: 88011a15e040 RSI: ea000464e400 RDI: 
88001cbe3028
  [ 6058.868150] RBP: c90003077b68 R08: 880119390380 R09: 
00010040001f
  [ 6058.868241] R10: c90003077b18 R11: 0001e200 R12: 
88001cbe3028
  [ 6058.868330] R13: 88001cbe68d0 R14: 8800cf734000 R15: 
8800cf734098
  [ 6058.868419] FS:  () GS:88011fb0() 
knlGS:
  [ 6058.868511] CS:  0010 DS:  ES:  CR0: 80050033
  [ 6058.868578] CR2: 01f8 CR3: 0001113c5000 CR4: 
001406e0
  [ 6058.868662] Call Trace:
  [ 6058.868705]  dvb_unregister_frontend+0x2a/0x80 [dvb_core]
  [ 6058.868774]  em28xx_dvb_fini+0x132/0x220 [em28xx_dvb]
  [ 6058.868840]  em28xx_close_extension+0x34/0x90 [em28xx]
  [ 6058.868902]  em28xx_usb_disconnect+0x4e/0x70 [em28xx]
  [ 6058.868968]  usb_unbind_interface+0x6d/0x260
  [ 6058.869025]  device_release_driver_internal+0x150/0x210
  [ 6058.869094]  device_release_driver+0xd/0x10
  [ 6058.869150]  bus_remove_device+0xe4/0x160
  [ 6058.869204]  device_del+0x1ce/0x2f0
  [ 6058.869253]  usb_disable_device+0x99/0x270
  [ 6058.869306]  usb_disconnect+0x8d/0x260
  [ 6058.869359]  hub_event+0x93d/0x1520
  [ 6058.869408]  ? dequeue_task_fair+0xae5/0xd20
  [ 6058.869467]  process_one_work+0x1d9/0x3e0
  [ 6058.869522]  worker_thread+0x43/0x3e0
  [ 6058.869576]  kthread+0x104/0x140
  [ 6058.869602]  ? trace_event_raw_event_workqueue_work+0x80/0x80
  [ 6058.869640]  ? kthread_create_on_node+0x40/0x40
  [ 6058.869673]  ret_from_fork+0x22/0x30
  [ 6058.869698] Code: 54 49 89 fc 53 48 8b 9f 18 03 00 00 0f 1f 44 00 00 41 83 
bc 24 04 05 00 00 02 74 0c 41 c7 84 24 04 05 00 00 01 00 00 00 0f ae f0 <48> 8b 
bb f8 01 00 00 48 85 ff 74 5c e8 df 40 f0 e0 48 8b 93 f8
  [ 6058.869850] RIP: dvb_frontend_stop+0x30/0xd0 [dvb_core] RSP: 
c90003077b58
  [ 6058.869894] CR2: 01f8
  [ 6058.875880] ---[ end trace 717eecf7193b3fc6 ]---

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/usb/em28xx/em28xx-dvb.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 4a7db623fe29..29cdaaf1ed90 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -2105,6 +2105,8 @@ static int em28xx_dvb_fini(struct em28xx *dev)
}
}
 
+   em28xx_unregister_dvb(dvb);
+
/* remove I2C SEC */
client = dvb->i2c_client_sec;
if (client) {
@@ -2126,7 +2128,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
i2c_unregister_device(client);
}
 
-   em28xx_unregister_dvb(dvb);
kfree(dvb);
dev->dvb = NULL;
kref_put(>ref, em28xx_free_device);
-- 
2.14.2

[PATCH] __dvb_frontend_free: Clear frontend_priv earlier

[Matthias Schwarzott]

sk 24:
 save_stack_trace+0x1b/0x20 arch/x86/kernel/stacktrace.c:59
 save_stack+0x43/0xd0 mm/kasan/kasan.c:447
 set_track mm/kasan/kasan.c:459
 kasan_slab_free+0x72/0xc0 mm/kasan/kasan.c:524
 slab_free_hook mm/slub.c:1390
 slab_free_freelist_hook mm/slub.c:1412
 slab_free mm/slub.c:2988
 kfree+0xf6/0x2f0 mm/slub.c:3919
 dtt200u_fe_release+0x3c/0x50 drivers/media/usb/dvb-usb/dtt200u-fe.c:202
 dvb_frontend_invoke_release.part.13+0x1c/0x30 
drivers/media/dvb-core/dvb_frontend.c:2790
 dvb_frontend_invoke_release drivers/media/dvb-core/dvb_frontend.c:2789
 __dvb_frontend_free+0xad/0x120 drivers/media/dvb-core/dvb_frontend.c:153
 dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
 dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
 dvb_usb_adapter_frontend_exit+0xd6/0x160 
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
 dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
 dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
 dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
 usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
 __device_release_driver drivers/base/dd.c:861
 device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
 device_release_driver+0x1e/0x30 drivers/base/dd.c:918
 bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
 device_del+0x5c4/0xab0 drivers/base/core.c:1985
 usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
 usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
 hub_port_connect drivers/usb/core/hub.c:4754
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x363/0x440 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431

The buggy address belongs to the object at 880067d45500
 which belongs to the cache kmalloc-2048 of size 2048
The buggy address is located 1280 bytes inside of
 2048-byte region [880067d45500, 880067d45d00)
The buggy address belongs to the page:
page:ea00019f5000 count:1 mapcount:0 mapping:  (null)
index:0x0 compound_mapcount: 0
flags: 0x1008100(slab|head)
raw: 01008100   0001000f000f
raw: dead0100 dead0200 88006c002d80 
page dumped because: kasan: bad access detected

Memory state around the buggy address:
 880067d45900: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 880067d45980: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
> 880067d45a00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
   ^
 880067d45a80: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
 880067d45b00: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
==

Fixes: ead666000a5f ("media: dvb_frontend: only use kref after initialized")

Reported-by: Andrey Konovalov <andreyk...@google.com>
Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
Tested-by: Andrey Konovalov <andreyk...@google.com>
---
 drivers/media/dvb-core/dvb_frontend.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/media/dvb-core/dvb_frontend.c 
b/drivers/media/dvb-core/dvb_frontend.c
index daaf969719e4..f552acdb7d8c 100644
--- a/drivers/media/dvb-core/dvb_frontend.c
+++ b/drivers/media/dvb-core/dvb_frontend.c
@@ -150,10 +150,11 @@ static void __dvb_frontend_free(struct dvb_frontend *fe)
 
dvb_free_device(fepriv->dvbdev);
 
+   fe->frontend_priv = NULL;
+
dvb_frontend_invoke_release(fe, fe->ops.release);
 
kfree(fepriv);
-   fe->frontend_priv = NULL;
 }
 
 static void dvb_frontend_free(struct kref *ref)
-- 
2.14.2

Re: usb/media/dtt200u: use-after-free in __dvb_frontend_free

[Matthias Schwarzott]

Am 23.10.2017 um 16:41 schrieb Andrey Konovalov:
> Hi!
> 
> I've got the following report while fuzzing the kernel with syzkaller.
> 
> On commit 3e0cc09a3a2c40ec1ffb6b4e12da86e98feccb11 (4.14-rc5+).
> 
> dvb-usb: found a 'WideView WT-220U PenType Receiver (based on ZL353)'
> in warm state.
> dvb-usb: bulk message failed: -22 (2/1102416563)
> dvb-usb: will use the device's hardware PID filter (table count: 15).
> dvbdev: DVB: registering new adapter (WideView WT-220U PenType
> Receiver (based on ZL353))
> usb 1-1: media controller created
> dvbdev: dvb_create_media_entity: media entity 'dvb-demux' registered.
> usb 1-1: DVB: registering adapter 0 frontend 0 (WideView USB DVB-T)...
> dvbdev: dvb_create_media_entity: media entity 'WideView USB DVB-T' registered.
> Registered IR keymap rc-dtt200u
> rc rc1: IR-receiver inside an USB DVB receiver as
> /devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1
> input: IR-receiver inside an USB DVB receiver as
> /devices/platform/dummy_hcd.0/usb1/1-1/rc/rc1/input9
> dvb-usb: schedule remote query interval to 300 msecs.
> dvb-usb: WideView WT-220U PenType Receiver (based on ZL353)
> successfully initialized and connected.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> dvb-usb: bulk message failed: -22 (1/1807119384)
> dvb-usb: error -22 while querying for an remote control event.
> usb 1-1: USB disconnect, device number 2
> ==
> BUG: KASAN: use-after-free in __dvb_frontend_free+0x113/0x120
> Write of size 8 at addr 880067d45a00 by task kworker/0:1/24
> 
> CPU: 0 PID: 24 Comm: kworker/0:1 Not tainted 4.14.0-rc5-43687-g06ab8a23e0e6 
> #545
> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
> Workqueue: usb_hub_wq hub_event
> Call Trace:
>  __dump_stack lib/dump_stack.c:16
>  dump_stack+0x292/0x395 lib/dump_stack.c:52
>  print_address_description+0x78/0x280 mm/kasan/report.c:252
>  kasan_report_error mm/kasan/report.c:351
>  kasan_report+0x23d/0x350 mm/kasan/report.c:409
>  __asan_report_store8_noabort+0x1c/0x20 mm/kasan/report.c:435
>  __dvb_frontend_free+0x113/0x120 drivers/media/dvb-core/dvb_frontend.c:156
>  dvb_frontend_put+0x59/0x70 drivers/media/dvb-core/dvb_frontend.c:176
>  dvb_frontend_detach+0x120/0x150 drivers/media/dvb-core/dvb_frontend.c:2803
>  dvb_usb_adapter_frontend_exit+0xd6/0x160
> drivers/media/usb/dvb-usb/dvb-usb-dvb.c:340
>  dvb_usb_adapter_exit drivers/media/usb/dvb-usb/dvb-usb-init.c:116
>  dvb_usb_exit+0x9b/0x200 drivers/media/usb/dvb-usb/dvb-usb-init.c:132
>  dvb_usb_device_exit+0xa5/0xf0 drivers/media/usb/dvb-usb/dvb-usb-init.c:295
>  usb_unbind_interface+0x21c/0xa90 drivers/usb/core/driver.c:423
>  __device_release_driver drivers/base/dd.c:861
>  device_release_driver_internal+0x4f1/0x5c0 drivers/base/dd.c:893
>  device_release_driver+0x1e/0x30 drivers/base/dd.c:918
>  bus_remove_device+0x2f4/0x4b0 drivers/base/bus.c:565
>  device_del+0x5c4/0xab0 drivers/base/core.c:1985
>  usb_disable_device+0x1e9/0x680 drivers/usb/core/message.c:1170
>  usb_disconnect+0x260/0x7a0 drivers/usb/core/hub.c:2124
>  hub_port_connect drivers/usb/core/hub.c:4754
>  hub_port_connect_change drivers/usb/core/hub.c:5009
>  port_event drivers/usb/core/hub.c:5115
>  hub_event+0x1318/0x3740 drivers/usb/core/hub.c:5195
>  process_one_work+0xc73/0x1d90 kernel/workqueue.c:2119
>  worker_thread+0x221/0x1850 kernel/workqueue.c:2253
>  kthread+0x363/0x440 kernel/kthread.c:231
>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
> 
It looks like this is caused by commit
ead666000a5fe34bdc82d61838e4df2d416ea15e ("media: dvb_frontend: only use
kref after initialized").

The writing to "fe->frontend_priv" in dvb_frontend.c:156 is a
use-after-free in case the object dvb_frontend *fe is already freed by
the release callback called in line 153.
Only if the demod driver is based on new style i2c_client the memory is
still accessible.

There are two possible solutions:
1. Clear fe->frontend_priv earlier (before line 153).
2. Do not clear fe->frontend_priv

Can you try if the following patch (solution 1) fixes the issue?

Regards
Matthias

diff --git a/drivers/media/dvb-core/dvb_frontend.c
b/drivers/media/dvb-core/d

Re: [PATCH] Simplify major/minor non-dynamic logic

[Matthias Schwarzott]

Am 11.10.2017 um 21:36 schrieb Mauro Carvalho Chehab:
> changeset 6bbf7a855d20 ("media: dvbdev: convert DVB device types into an 
> enum")
> added a new warning on gcc 6:
> 
>>> drivers/media/dvb-core/dvbdev.c:86:1: warning: control reaches end of 
>>> non-void function [-Wreturn-type]
> 
> That's because gcc is not smart enough to see that all types are
> present at the switch. Also, the current code is not too optimized.
> 
How should the compiler know that "int type" will only contain values
0..8? dvb_register_adapter is not inlined.

> So, replace it to a more optimized one, based on a static table.
> 
> Reported-by: kbuild test robot <fengguang...@intel.com>
> Fixes: 6bbf7a855d20 ("media: dvbdev: convert DVB device types into an enum")
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
> I actually suggested this patch to be fold with changeset 6bbf7a855d20.
> Unfortunately, I actually forgot to do that (I guess I did, but on a different
> machine than the one I used today to pick it).
> 
> Anyway, that saves some code space with static minors and cleans up
> a warning. So, let's apply it.
> 
>  drivers/media/dvb-core/dvbdev.c | 28 +---
>  1 file changed, 13 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/media/dvb-core/dvbdev.c b/drivers/media/dvb-core/dvbdev.c
> index a53eb53a4fd5..060c60ddfcc3 100644
> --- a/drivers/media/dvb-core/dvbdev.c
> +++ b/drivers/media/dvb-core/dvbdev.c
> @@ -68,22 +68,20 @@ static const char * const dnames[] = {
>  #else
>  #define DVB_MAX_IDS  4
>  
> -static int nums2minor(int num, enum dvb_device_type type, int id)
> -{
> - int n = (num << 6) | (id << 4);
> +static const u8 minor_type[] = {
> +   [DVB_DEVICE_VIDEO]  = 0,
> +   [DVB_DEVICE_AUDIO]  = 1,
> +   [DVB_DEVICE_SEC]= 2,
> +   [DVB_DEVICE_FRONTEND]   = 3,
> +   [DVB_DEVICE_DEMUX]  = 4,
> +   [DVB_DEVICE_DVR]= 5,
> +   [DVB_DEVICE_CA] = 6,
> +   [DVB_DEVICE_NET]= 7,
> +   [DVB_DEVICE_OSD]= 8,
> +};
>  
> - switch (type) {
> - case DVB_DEVICE_VIDEO:  return n;
> - case DVB_DEVICE_AUDIO:  return n | 1;
> - case DVB_DEVICE_SEC:return n | 2;
> - case DVB_DEVICE_FRONTEND:   return n | 3;
> - case DVB_DEVICE_DEMUX:  return n | 4;
> - case DVB_DEVICE_DVR:return n | 5;
> - case DVB_DEVICE_CA: return n | 6;
> - case DVB_DEVICE_NET:return n | 7;
> - case DVB_DEVICE_OSD:return n | 8;
> - }
> -}
> +#define nums2minor(num, type, id) \
> +   (((num) << 6) | ((id) << 4) | minor_type[type])

In this code it is problematic that a bad value of type will trigger an
invalid memory access.

>  
>  #define MAX_DVB_MINORS   (DVB_MAX_ADAPTERS*64)
>  #endif
> 

Regards
Matthias

[PATCH] cx23885: Explicitly list Hauppauge model numbers of HVR-4400 and HVR-5500

[Matthias Schwarzott]

Add two new model numbers to suppress this message in kernel log:
  cx23885: cx23885[0]: warning: unknown hauppauge model #121029

Add these model numbers:
* Model 121019 - WinTV-HVR4400
* Model 121029 - WinTV-HVR5500

For WinTV-HVR4400 the documentation and my hardware differ:

Documentation says it supports DVB-S/S2 and DVB-T,
but my hardware also supports DVB-C.

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/pci/cx23885/cx23885-cards.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/media/pci/cx23885/cx23885-cards.c 
b/drivers/media/pci/cx23885/cx23885-cards.c
index c48fa8e25a70..78a8836d03e4 100644
--- a/drivers/media/pci/cx23885/cx23885-cards.c
+++ b/drivers/media/pci/cx23885/cx23885-cards.c
@@ -1278,6 +1278,12 @@ static void hauppauge_eeprom(struct cx23885_dev *dev, u8 
*eeprom_data)
case 85721:
/* WinTV-HVR1290 (PCIe, OEM, RCA in, IR,
Dual channel ATSC and Basic analog */
+   case 121019:
+   /* WinTV-HVR4400 (PCIe, DVB-S2, DVB-C/T) */
+   break;
+   case 121029:
+   /* WinTV-HVR5500 (PCIe, DVB-S2, DVB-C/T) */
+   break;
case 150329:
/* WinTV-HVR5525 (PCIe, DVB-S/S2, DVB-T/T2/C) */
break;
-- 
2.14.1

Fwd: Aw: Fwd: [PATCH 1/2] cx23885: Fix use-after-free when unregistering the i2c_client for the dvb demod

[Matthias Schwarzott]

Forwarding a tested-by statement (using a HVR-5500).

Regards
Matthias

 Weitergeleitete Nachricht 
Betreff: Aw: Fwd: [PATCH 1/2] cx23885: Fix use-after-free when
unregistering the i2c_client for the dvb demod
Datum: Sun, 27 Aug 2017 12:18:55 +0200
Von: "Sven Müller" <xpert-reac...@gmx.de>
An: Matthias Schwarzott <z...@gentoo.org>

Tested-by: Sven Müller <xpert-reac...@gmx.de>

> Gesendet: Sonntag, 27. August 2017 um 12:12 Uhr
> Von: "Matthias Schwarzott" <z...@gentoo.org>
> An: "Sven Müller" <xpert-reac...@gmx.de>
> Betreff: Fwd: [PATCH 1/2] cx23885: Fix use-after-free when unregistering the 
> i2c_client for the dvb demod
>
> 
> 
> 
>  Weitergeleitete Nachricht 
> Betreff: [PATCH 1/2] cx23885: Fix use-after-free when unregistering the
> i2c_client for the dvb demod
> Datum: Wed,  2 Aug 2017 18:45:59 +0200
> Von: Matthias Schwarzott <z...@gentoo.org>
> An: linux-media@vger.kernel.org
> Kopie (CC): mche...@osg.samsung.com, cr...@iki.fi, Matthias Schwarzott
> <z...@gentoo.org>
> 
> Unregistering the i2c_client of the demod driver destroys the frontend
> object.
> Calling vb2_dvb_unregister_bus later accesses the frontend (and with the
> refcount_t) conversion the refcount_t code complains:
> 
> kernel: [ cut here ]
> kernel: WARNING: CPU: 0 PID: 7883 at lib/refcount.c:128
> refcount_sub_and_test+0x70/0x80
> kernel: refcount_t: underflow; use-after-free.
> kernel: Modules linked in: bluetooth si2165(O) a8293(O) tda10071(O)
> tea5767(O) tuner(O) cx23885(O-) tda18271(O) videobuf2_dvb(O)
> videobuf2_dma_sg(O) m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O)
> dvb_core(O) rc_core(O) videobuf2_memops(O) videobuf2_v4l2(O) ums_realtek
> videobuf2_core(O) uas videodev(O) media(O) rtl8192cu i2c_mux usb_storage
> rtl_usb rtl8192c_common rtlwifi snd_hda_codec_hdmi snd_hda_codec_realtek
> snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core
> x86_pkg_temp_thermal kvm_intel kvm irqbypass
> kernel: CPU: 0 PID: 7883 Comm: rmmod Tainted: GW  O
> 4.11.3-gentoo #3
> kernel: Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308
> 08/25/2014
> kernel: Call Trace:
> kernel:  dump_stack+0x4d/0x66
> kernel:  __warn+0xc6/0xe0
> kernel:  warn_slowpath_fmt+0x46/0x50
> kernel:  ? kobject_put+0x2f/0x60
> kernel:  refcount_sub_and_test+0x70/0x80
> kernel:  refcount_dec_and_test+0x11/0x20
> kernel:  dvb_unregister_frontend+0x42/0x60 [dvb_core]
> kernel:  vb2_dvb_dealloc_frontends+0x9e/0x100 [videobuf2_dvb]
> kernel:  vb2_dvb_unregister_bus+0xd/0x20 [videobuf2_dvb]
> kernel:  cx23885_dvb_unregister+0xc3/0x110 [cx23885]
> kernel:  cx23885_dev_unregister+0xea/0x150 [cx23885]
> kernel:  cx23885_finidev+0x4f/0x70 [cx23885]
> kernel:  pci_device_remove+0x34/0xb0
> kernel:  device_release_driver_internal+0x150/0x200
> kernel:  driver_detach+0x33/0x70
> kernel:  bus_remove_driver+0x47/0xa0
> kernel:  driver_unregister+0x27/0x50
> kernel:  pci_unregister_driver+0x34/0x90
> kernel:  cx23885_fini+0x10/0x12 [cx23885]
> kernel:  SyS_delete_module+0x166/0x220
> kernel:  ? exit_to_usermode_loop+0x7b/0x80
> kernel:  entry_SYSCALL_64_fastpath+0x17/0x98
> kernel: RIP: 0033:0x7f5901680b07
> kernel: RSP: 002b:7ffdf6cdb028 EFLAGS: 0206 ORIG_RAX:
> 00b0
> kernel: RAX: ffda RBX: 0003 RCX: 7f5901680b07
> kernel: RDX: 000a RSI: 0800 RDI: 01500258
> kernel: RBP: 015001f0 R08:  R09: 1999
> kernel: R10: 0884 R11: 0206 R12: 7ffdf6cda010
> kernel: R13:  R14: 015001f0 R15: 014ff010
> kernel: ---[ end trace c3a4659b89086061 ]---
> 
> Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
> ---
>  drivers/media/pci/cx23885/cx23885-dvb.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c
> b/drivers/media/pci/cx23885/cx23885-dvb.c
> index 979b66627f60..e795ddeb7fe2 100644
> --- a/drivers/media/pci/cx23885/cx23885-dvb.c
> +++ b/drivers/media/pci/cx23885/cx23885-dvb.c
> @@ -2637,6 +2637,11 @@ int cx23885_dvb_unregister(struct cx23885_tsport
> *port)
>   struct vb2_dvb_frontend *fe0;
>   struct i2c_client *client;
>  +fe0 = vb2_dvb_get_frontend(>frontends, 1);
> +
> + if (fe0 && fe0->dvb.frontend)
> + vb2_dvb_unregister_bus(>frontends);
> +
>   /* remove I2C client for CI */
>   client = port->i2c_client_ci;
>   if (client) {
> @@ -2665,11 +2670,6 @@ int cx23885_dvb_unregister(struct cx23885_tsport
> *port)
>   i2c_unregister_device(client);
>   }
>  -fe0 = vb2_dvb_get_frontend(>frontends, 1);
> -
> - if (fe0 && fe0->dvb.frontend)
> - vb2_dvb_unregister_bus(>frontends);
> -
>   switch (port->dev->board) {
>   case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
>   netup_ci_exit(port);
> -- 
> 2.13.3
> 
> 
>

Re: [PATCH 1/2] cx23885: Fix use-after-free when unregistering the i2c_client for the dvb demod

[Matthias Schwarzott]

Am 02.08.2017 um 18:45 schrieb Matthias Schwarzott:
> diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c 
> b/drivers/media/pci/cx23885/cx23885-dvb.c
> index 979b66627f60..e795ddeb7fe2 100644
> --- a/drivers/media/pci/cx23885/cx23885-dvb.c
> +++ b/drivers/media/pci/cx23885/cx23885-dvb.c
> @@ -2637,6 +2637,11 @@ int cx23885_dvb_unregister(struct cx23885_tsport *port)
>   struct vb2_dvb_frontend *fe0;
>   struct i2c_client *client;
>  
> + fe0 = vb2_dvb_get_frontend(>frontends, 1);
> +
> + if (fe0 && fe0->dvb.frontend)
> + vb2_dvb_unregister_bus(>frontends);
> +
>   /* remove I2C client for CI */
>   client = port->i2c_client_ci;
>   if (client) {
> @@ -2665,11 +2670,6 @@ int cx23885_dvb_unregister(struct cx23885_tsport *port)
>   i2c_unregister_device(client);
>   }
>  
> - fe0 = vb2_dvb_get_frontend(>frontends, 1);
> -
> - if (fe0 && fe0->dvb.frontend)
> - vb2_dvb_unregister_bus(>frontends);
> -

The following code is after i2c_unregister_device.
>   switch (port->dev->board) {
>   case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
>   netup_ci_exit(port);
> 
I wonder if the code above should be moved to before the
i2c_unregister_device block.
Currently these NETUP board drivers do not use "new style/i2c_client
based" frontend drivers. But if in future this switch is extended one
could get in trouble.

Regards
Matthias

Re: analog support for WinTV-HVR-900H/930C-HD

[Matthias Schwarzott]

> [   47.182721] cx231xx 3-4:1.1: Registered VBI device vbi0
> [   47.182725] cx231xx 3-4:1.1: video EndPoint Addr 0x84, Alternate settings: 
> 5
> [   47.182728] cx231xx 3-4:1.1: VBI EndPoint Addr 0x85, Alternate settings: 2
> [   47.182730] cx231xx 3-4:1.1: sliced CC EndPoint Addr 0x86, Alternate 
> settings: 2
> [   47.182732] cx231xx 3-4:1.1: TS EndPoint Addr 0x81, Alternate settings: 6
> [   47.182784] usbcore: registered new interface driver cx231xx
> [   47.188184] cx231xx 3-4:1.1: audio EndPoint Addr 0x83, Alternate settings: 
> 3
> [   47.188187] cx231xx 3-4:1.1: Cx231xx Audio Extension initialized
> [   47.251193] i2c i2c-15: si2165: Detected Silicon Labs Si2165-D (type 7, 
> rev 3)
> [   47.251197] i2c i2c-15: si2165: DVB-C is not yet supported.
> [   47.254581] si2157 15-0060: Silicon Labs Si2147/2148/2157/2158 
> successfully attached
> [   47.254588] DVB: registering new adapter (cx231xx #0)
> [   47.254591] cx231xx 3-4:1.1: DVB: registering adapter 0 frontend 0 
> (Silicon Labs Si2165 DVB-T)...
> [   47.254850] cx231xx 3-4:1.1: Successfully loaded cx231xx-dvb
> [   47.254855] cx231xx 3-4:1.1: Cx231xx dvb Extension initialized
> [  100.672828] cx231xx 3-4:1.1: Unknown tuner type configuring SIF
> [  100.748631] cx231xx 3-4:1.1: Unknown tuner type configuring SIF
> 

Your stick is labeled as WinTV-HVR-900H but you got a different hardware
than described by the wiki page mentioned above.

According to your dmesg output your card has USB IDs: 2013:025e and that
is the same ID as used for PCTV 522e DVB-T/C (Si2158+Si2165)

The output shows that the chips si2158 and si2165 are successfully
identified.

The driver for the tuner (si2157) does currently not support analog
reception. I do not know what is necessary to add this support.

Maybe Antti or Olli can answer that question.

Regards
Matthias

Re: [PATCH] keytable: ensure udev rule fires on rc input device

[Matthias Reichl]

Hi Sean!

On Wed, Aug 16, 2017 at 05:56:25PM +0100, Sean Young wrote:
> I've found a shorter way of doing this.

That's a really clever trick of dealing with the RUN/$id issue,
I like it a lot!

> 
> From: Sean Young <s...@mess.org>
> Date: Wed, 16 Aug 2017 17:41:53 +0100
> Subject: [PATCH] keytable: ensure the udev rule fires on creation of the input
>  device
> 
> The rc device is created before the input device, so if ir-keytable runs
> too early the input device does not exist yet.
> 
> Ensure that rule fires on creation of a rc device's input device.
> 
> Note that this also prevents udev from starting ir-keytable on an
> transmit only device, which has no input device.
> 
> Note that $id in RUN will not work, since that is expanded after all the
> rules are matched, at which point the the parent might have been changed
> by another match in another rule. The argument to $env{key} is expanded
> immediately.
> 
> Signed-off-by: Sean Young <s...@mess.org>

Tested-by: Matthias Reichl <h...@horus.com>

so long & thanks for the fix,

Hias
> ---
>  utils/keytable/70-infrared.rules | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/utils/keytable/70-infrared.rules 
> b/utils/keytable/70-infrared.rules
> index afffd951..41ca2089 100644
> --- a/utils/keytable/70-infrared.rules
> +++ b/utils/keytable/70-infrared.rules
> @@ -1,4 +1,4 @@
>  # Automatically load the proper keymaps after the Remote Controller device
>  # creation.  The keycode tables rules should be at /etc/rc_maps.cfg
>  
> -ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s $name"
> +ACTION=="add", SUBSYSTEM=="input", SUBSYSTEMS=="rc", KERNEL=="event*", 
> ENV{.rc_sysdev}="$id", RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s 
> $env{.rc_sysdev}"
> -- 
> 2.13.5
> 

Re: [PATCH] keytable: ensure udev rule fires on rc input device

[Matthias Reichl]

Hi Sean!

On Sun, Aug 06, 2017 at 09:56:55AM +0100, Sean Young wrote:
> The rc device is created before the input device, so if ir-keytable runs
> too early the input device does not exist yet.
> 
> Ensure that rule fires on creation of a rc device's input device.
> 
> Note that this also prevents udev from starting ir-keytable on an
> transmit only device, which has no input device.
> 
> Signed-off-by: Sean Young <s...@mess.org>

Signed-off-by: Matthias Reichl <h...@horus.com>

One comment though, see below

> ---
>  utils/keytable/70-infrared.rules | 10 +-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> Matthias, can I have your Signed-off-by please? Thank you.
> 
> 
> diff --git a/utils/keytable/70-infrared.rules 
> b/utils/keytable/70-infrared.rules
> index afffd951..b3531727 100644
> --- a/utils/keytable/70-infrared.rules
> +++ b/utils/keytable/70-infrared.rules
> @@ -1,4 +1,12 @@
>  # Automatically load the proper keymaps after the Remote Controller device
>  # creation.  The keycode tables rules should be at /etc/rc_maps.cfg
>  
> -ACTION=="add", SUBSYSTEM=="rc", RUN+="/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s $name"
> +ACTION!="add", SUBSYSTEMS!="rc", GOTO="rc_dev_end"

This line doesn't quite what we want it to do.

As SUBSYSTEMS!="rc" is basically a no-op and would only be
evaluated on change/remove events anyways that line boils down to

ACTION!="add", GOTO="rc_dev_end"

and the following rules are evaluated on all add events.

While that'll still work it'll do unnecessary work, like importing
rc_sydev for all input devices and could bite us (or users) later
if we change/extend the ruleset.

Better do it like in my original comment (using positive logic and
a GOTO="begin") or use ACTION!="add", GOTO="rc_dev_end" and add
SUBSYSTEMS=="rc" to the IMPORT and RUN rules below.

so long,

Hias

> +
> +SUBSYSTEM=="rc", ENV{rc_sysdev}="$name"
> +
> +SUBSYSTEM=="input", IMPORT{parent}="rc_sysdev"
> +
> +KERNEL=="event[0-9]*", ENV{rc_sysdev}=="?*", RUN+="/usr/bin/ir-keytable -a 
> /etc/rc_maps.cfg -s $env{rc_sysdev}"
> +
> +LABEL="rc_dev_end"
> -- 
> 2.11.0
> 

[PATCH] [media] rc: gpio-ir-tx: switch to gpiod, fix inverted polarity

[Matthias Reichl]

Manual handling of gpio output polarity was inverted.
Switch to using gpiod, this allows us to simplify the code,
delegate polarity handling to gpiod and remove the buggy local
polarity handling code.

Signed-off-by: Matthias Reichl <h...@horus.com>
---

This patch is against [PATCH v2 3/6] [media] rc: gpio-ir-tx:
add new driver.

Feel free to squash these two patches into one for v3.

so long,

Hias

 drivers/media/rc/gpio-ir-tx.c | 41 +
 1 file changed, 13 insertions(+), 28 deletions(-)

diff --git a/drivers/media/rc/gpio-ir-tx.c b/drivers/media/rc/gpio-ir-tx.c
index 7a5371dbb360..ca6834d09467 100644
--- a/drivers/media/rc/gpio-ir-tx.c
+++ b/drivers/media/rc/gpio-ir-tx.c
@@ -13,11 +13,10 @@
 
 #include 
 #include 
-#include 
+#include 
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 
@@ -25,8 +24,7 @@
 #define DEVICE_NAME"GPIO Bit Banging IR Transmitter"
 
 struct gpio_ir {
-   int gpio_nr;
-   bool active_low;
+   struct gpio_desc *gpio;
unsigned int carrier;
unsigned int duty_cycle;
/* we need a spinlock to hold the cpu while transmitting */
@@ -101,14 +99,12 @@ static int gpio_ir_tx(struct rc_dev *dev, unsigned int 
*txbuf,
ktime_t last = ktime_add_us(edge, txbuf[i]);
 
while (ktime_get() < last) {
-   gpio_set_value(gpio_ir->gpio_nr,
-  gpio_ir->active_low);
+   gpiod_set_value(gpio_ir->gpio, 1);
edge += pulse;
delta = edge - ktime_get();
if (delta > 0)
ndelay(delta);
-   gpio_set_value(gpio_ir->gpio_nr,
-  !gpio_ir->active_low);
+   gpiod_set_value(gpio_ir->gpio, 0);
edge += space;
delta = edge - ktime_get();
if (delta > 0)
@@ -128,16 +124,7 @@ static int gpio_ir_tx_probe(struct platform_device *pdev)
 {
struct gpio_ir *gpio_ir;
struct rc_dev *rcdev;
-   enum of_gpio_flags flags;
-   int rc, gpio;
-
-   gpio = of_get_gpio_flags(pdev->dev.of_node, 0, );
-   if (gpio < 0) {
-   if (gpio != -EPROBE_DEFER)
-   dev_err(>dev, "Failed to get gpio flags (%d)\n",
-   gpio);
-   return -EINVAL;
-   }
+   int rc;
 
gpio_ir = devm_kmalloc(>dev, sizeof(*gpio_ir), GFP_KERNEL);
if (!gpio_ir)
@@ -147,6 +134,14 @@ static int gpio_ir_tx_probe(struct platform_device *pdev)
if (!rcdev)
return -ENOMEM;
 
+   gpio_ir->gpio = devm_gpiod_get(>dev, NULL, GPIOD_OUT_LOW);
+   if (IS_ERR(gpio_ir->gpio)) {
+   if (PTR_ERR(gpio_ir->gpio) != -EPROBE_DEFER)
+   dev_err(>dev, "Failed to get gpio (%ld)\n",
+   PTR_ERR(gpio_ir->gpio));
+   return PTR_ERR(gpio_ir->gpio);
+   }
+
rcdev->priv = gpio_ir;
rcdev->driver_name = DRIVER_NAME;
rcdev->device_name = DEVICE_NAME;
@@ -154,20 +149,10 @@ static int gpio_ir_tx_probe(struct platform_device *pdev)
rcdev->s_tx_duty_cycle = gpio_ir_tx_set_duty_cycle;
rcdev->s_tx_carrier = gpio_ir_tx_set_carrier;
 
-   gpio_ir->gpio_nr = gpio;
-   gpio_ir->active_low = (flags & OF_GPIO_ACTIVE_LOW) != 0;
gpio_ir->carrier = 38000;
gpio_ir->duty_cycle = 50;
spin_lock_init(_ir->lock);
 
-   rc = devm_gpio_request(>dev, gpio, "gpio-ir-tx");
-   if (rc < 0)
-   return rc;
-
-   rc = gpio_direction_output(gpio, !gpio_ir->active_low);
-   if (rc < 0)
-   return rc;
-
rc = devm_rc_register_device(>dev, rcdev);
if (rc < 0)
dev_err(>dev, "failed to register rc device\n");
-- 
2.11.0

[PATCH 2/2] cx231xx: fix use-after-free when unregistering the i2c_client for the dvb demod

[Matthias Schwarzott]

Calling i2c_unregister_device for a demod driver destroys the frontend object.
Later it is accessed by calling dvb_unregister_frontend and
dvb_frontend_detach.

In some cases this leads to a general protection fault with this
callstack:

  dvb_unregister_frontend+0x25/0x50 [dvb_core]
  dvb_fini+0xdb/0x160 [cx231xx_dvb]
  cx231xx_unregister_extension+0x3d/0xb0 [cx231xx]
  cx231xx_dvb_unregister+0x10/0x809 [cx231xx_dvb]
  SyS_delete_module+0x18a/0x240
  ? exit_to_usermode_loop+0x7b/0x80
  entry_SYSCALL_64_fastpath+0x17/0x98

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/usb/cx231xx/cx231xx-dvb.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/cx231xx/cx231xx-dvb.c 
b/drivers/media/usb/cx231xx/cx231xx-dvb.c
index ee3eeeb600f8..c18bb33e060e 100644
--- a/drivers/media/usb/cx231xx/cx231xx-dvb.c
+++ b/drivers/media/usb/cx231xx/cx231xx-dvb.c
@@ -585,6 +585,9 @@ static void unregister_dvb(struct cx231xx_dvb *dvb)
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_hw);
dvb_dmxdev_release(>dmxdev);
dvb_dmx_release(>demux);
+   dvb_unregister_frontend(dvb->frontend);
+   dvb_frontend_detach(dvb->frontend);
+   dvb_unregister_adapter(>adapter);
/* remove I2C tuner */
client = dvb->i2c_client_tuner;
if (client) {
@@ -597,9 +600,6 @@ static void unregister_dvb(struct cx231xx_dvb *dvb)
module_put(client->dev.driver->owner);
i2c_unregister_device(client);
}
-   dvb_unregister_frontend(dvb->frontend);
-   dvb_frontend_detach(dvb->frontend);
-   dvb_unregister_adapter(>adapter);
 }
 
 static int dvb_init(struct cx231xx *dev)
-- 
2.13.3

[PATCH 0/2] Fix use-after-free errors when unregistering the i2c_client for the dvb demod

[Matthias Schwarzott]

Hi!

There seem to be a general error in a lot of dvb bride drivers about the order 
of i2c_unregister_device
and the calls to dvb_unregister_frontend and dvb_frontend_detach.

As soon as the i2c_client for a demod driver is unregistered the memory for the 
frontend is kfreed.
But the calls to dvb_unregister_frontend and dvb_frontend_detach access it 
later.

I fixed the error in cx23885 and cx231xx driver as I have access to the 
hardware.

Further drivers that might show the same bug (but I cannot test):
* em28xx
* ddbride
* saa7164

Regards
Matthias

[PATCH 1/2] cx23885: Fix use-after-free when unregistering the i2c_client for the dvb demod

[Matthias Schwarzott]

Unregistering the i2c_client of the demod driver destroys the frontend
object.
Calling vb2_dvb_unregister_bus later accesses the frontend (and with the
refcount_t) conversion the refcount_t code complains:

kernel: [ cut here ]
kernel: WARNING: CPU: 0 PID: 7883 at lib/refcount.c:128 
refcount_sub_and_test+0x70/0x80
kernel: refcount_t: underflow; use-after-free.
kernel: Modules linked in: bluetooth si2165(O) a8293(O) tda10071(O) tea5767(O) 
tuner(O) cx23885(O-) tda18271(O) videobuf2_dvb(O) videobuf2_dma_sg(O) 
m88ds3103(O) tveeprom(O) cx2341x(O) v4l2_common(O) dvb_core(O) rc_core(O) 
videobuf2_memops(O) videobuf2_v4l2(O) ums_realtek videobuf2_core(O) uas 
videodev(O) media(O) rtl8192cu i2c_mux usb_storage rtl_usb rtl8192c_common 
rtlwifi snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core x86_pkg_temp_thermal 
kvm_intel kvm irqbypass
kernel: CPU: 0 PID: 7883 Comm: rmmod Tainted: GW  O4.11.3-gentoo #3
kernel: Hardware name: MEDION E2050 2391/H81H3-EM2, BIOS H81EM2W08.308 
08/25/2014
kernel: Call Trace:
kernel:  dump_stack+0x4d/0x66
kernel:  __warn+0xc6/0xe0
kernel:  warn_slowpath_fmt+0x46/0x50
kernel:  ? kobject_put+0x2f/0x60
kernel:  refcount_sub_and_test+0x70/0x80
kernel:  refcount_dec_and_test+0x11/0x20
kernel:  dvb_unregister_frontend+0x42/0x60 [dvb_core]
kernel:  vb2_dvb_dealloc_frontends+0x9e/0x100 [videobuf2_dvb]
kernel:  vb2_dvb_unregister_bus+0xd/0x20 [videobuf2_dvb]
kernel:  cx23885_dvb_unregister+0xc3/0x110 [cx23885]
kernel:  cx23885_dev_unregister+0xea/0x150 [cx23885]
kernel:  cx23885_finidev+0x4f/0x70 [cx23885]
kernel:  pci_device_remove+0x34/0xb0
kernel:  device_release_driver_internal+0x150/0x200
kernel:  driver_detach+0x33/0x70
kernel:  bus_remove_driver+0x47/0xa0
kernel:  driver_unregister+0x27/0x50
kernel:  pci_unregister_driver+0x34/0x90
kernel:  cx23885_fini+0x10/0x12 [cx23885]
kernel:  SyS_delete_module+0x166/0x220
kernel:  ? exit_to_usermode_loop+0x7b/0x80
kernel:  entry_SYSCALL_64_fastpath+0x17/0x98
kernel: RIP: 0033:0x7f5901680b07
kernel: RSP: 002b:7ffdf6cdb028 EFLAGS: 0206 ORIG_RAX: 00b0
kernel: RAX: ffda RBX: 0003 RCX: 7f5901680b07
kernel: RDX: 000a RSI: 0800 RDI: 01500258
kernel: RBP: 015001f0 R08:  R09: 1999
kernel: R10: 0884 R11: 0206 R12: 7ffdf6cda010
kernel: R13:  R14: 015001f0 R15: 014ff010
kernel: ---[ end trace c3a4659b89086061 ]---

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 drivers/media/pci/cx23885/cx23885-dvb.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/media/pci/cx23885/cx23885-dvb.c 
b/drivers/media/pci/cx23885/cx23885-dvb.c
index 979b66627f60..e795ddeb7fe2 100644
--- a/drivers/media/pci/cx23885/cx23885-dvb.c
+++ b/drivers/media/pci/cx23885/cx23885-dvb.c
@@ -2637,6 +2637,11 @@ int cx23885_dvb_unregister(struct cx23885_tsport *port)
struct vb2_dvb_frontend *fe0;
struct i2c_client *client;
 
+   fe0 = vb2_dvb_get_frontend(>frontends, 1);
+
+   if (fe0 && fe0->dvb.frontend)
+   vb2_dvb_unregister_bus(>frontends);
+
/* remove I2C client for CI */
client = port->i2c_client_ci;
if (client) {
@@ -2665,11 +2670,6 @@ int cx23885_dvb_unregister(struct cx23885_tsport *port)
i2c_unregister_device(client);
}
 
-   fe0 = vb2_dvb_get_frontend(>frontends, 1);
-
-   if (fe0 && fe0->dvb.frontend)
-   vb2_dvb_unregister_bus(>frontends);
-
switch (port->dev->board) {
case CX23885_BOARD_NETUP_DUAL_DVBS2_CI:
netup_ci_exit(port);
-- 
2.13.3

Re: ir-keytable question [Ubuntu 17.04]

[Matthias Reichl]

On Sat, Jul 29, 2017 at 11:23:22AM +0100, Sean Young wrote:
> Hi,
> 
> On Sun, Jul 16, 2017 at 10:26:14PM -0700, Szabolcs Andrasi wrote:
> > Hi,
> > 
> > I'm using Ubuntu 17.04 and I installed the ir-keytable tool. The
> > output of the ir-keytable command is as follows:
> > 
> > 
> > 
> > Found /sys/class/rc/rc0/ (/dev/input/event5) with:
> > Driver ite-cir, table rc-rc6-mce
> > Supported protocols: unknown other lirc rc-5 rc-5-sz jvc sony nec
> > sanyo mce_kbd rc-6 sharp xmp
> > Enabled protocols: lirc rc-6
> > Name: ITE8708 CIR transceiver
> > bus: 25, vendor/product: 1283:, version: 0x
> > Repeat delay = 500 ms, repeat period = 125 ms
> > 
> > 
> > 
> > I'm trying to enable the supported mce_kbd protocol in addition to the
> > lirc and rc-6 protocols with the
> > 
> > $ sudo ir-keytable -p lirc -p rc-6 -p mce_kbd
> > 
> > command which works as expected. If, however, I reboot my computer,
> > ir-keytable forgets this change and only the lirc and rc-6 protocols
> > are enabled. Is there a configuration file I can edit so that after
> > the boot my IR remote still works? Or is that so that the only way to
> > make it work is to write a start-up script that runs the above command
> > to enable the needed protocol?
> 
> So what we have today is /etc/rc_maps.cfg, where you can select the default
> keymap for a particular driver; unfortunately, you can only select one
> keymap and one keymap can only have one protocol.
>
> Ideally we could either have more than one protocol per keymap, which
> would be helpful for the MCE Keyboard, or we could allow multiple keymaps
> which would be great for supporting different remotes at the same time.

Having more than one protocol in the keymap file works fine here,
we have been using that feature in LibreELEC for a long time now.
Maybe it was just forgotten to document it?

$ git show 42511eb505
commit 42511eb505b46b125652d37e764e5c8d1eb99e6b
Author: Mauro Carvalho Chehab 
Date:   Sat Apr 10 21:55:28 2010 -0300

ir-keytable: add support for more than one protocol in a table

Signed-off-by: Mauro Carvalho Chehab 

Quick test with ir-keytable 1.12.3 from Debian Stretch:

$ sudo ir-keytable -c -p lirc,rc-6 -s rc1
Old keytable cleared
Protocols changed to lirc rc-6

$ sudo ir-keytable -r -s rc1
Enabled protocols: lirc rc-6

$ cat /etc/rc_keymaps/rc6_mce_kbd_test
# table test, type:rc-6,mce_kbd
0x01KEY_1

$ cat test-map.cfg
* * rc6_mce_kbd_test

$ sudo ir-keytable -a test-map.cfg -s rc1
Old keytable cleared
Wrote 1 keycode(s) to driver
Protocols changed to mce_kbd rc-6

$ sudo ir-keytable -r -s rc1
scancode 0x0001 = KEY_1 (0x02)
Enabled protocols: lirc mce_kbd rc-6

so long,

Hias

> 
> For now, you could add a udev rule to also enable the mce_kbd protocol.
> 
> 
> Sean

[PATCH] Add compat code for skb_put_data

[Matthias Schwarzott]

Signed-off-by: Matthias Schwarzott <z...@gentoo.org>
---
 v4l/compat.h  | 12 
 v4l/scripts/make_config_compat.pl |  1 +
 2 files changed, 13 insertions(+)

diff --git a/v4l/compat.h b/v4l/compat.h
index 47e2694..e565292 100644
--- a/v4l/compat.h
+++ b/v4l/compat.h
@@ -2072,4 +2072,16 @@ static inline bool is_of_node(struct fwnode_handle 
*fwnode)
 }
 #endif
 
+#ifdef NEED_SKB_PUT_DATA
+static inline void *skb_put_data(struct sk_buff *skb, const void *data,
+ unsigned int len)
+{
+void *tmp = skb_put(skb, len);
+
+memcpy(tmp, data, len);
+
+return tmp;
+}
+#endif
+
 #endif /*  _COMPAT_H */
diff --git a/v4l/scripts/make_config_compat.pl 
b/v4l/scripts/make_config_compat.pl
index d186cb4..5ac59ab 100644
--- a/v4l/scripts/make_config_compat.pl
+++ b/v4l/scripts/make_config_compat.pl
@@ -699,6 +699,7 @@ sub check_other_dependencies()
check_files_for_func("of_fwnode_handle", "NEED_FWNODE", 
"include/linux/of.h");
check_files_for_func("to_of_node", "NEED_TO_OF_NODE", 
"include/linux/of.h");
check_files_for_func("is_of_node", "NEED_IS_OF_NODE", 
"include/linux/of.h");
+   check_files_for_func("skb_put_data", "NEED_SKB_PUT_DATA", 
"include/linux/skbuff.h");
 
# For tests for uapi-dependent logic
check_files_for_func_uapi("usb_endpoint_maxp", 
"NEED_USB_ENDPOINT_MAXP", "usb/ch9.h");
-- 
2.13.3

Re: [PATCH v2 4/6] [media] rc: pwm-ir-tx: add new driver

[Matthias Reichl]

Hi Sean,

sorry for double-post, forgot to CC the list and others.

On Fri, Jul 07, 2017 at 10:52:02AM +0100, Sean Young wrote:
> This is new driver which uses pwm, so it is more power-efficient
> than the bit banging gpio-ir-tx driver.
> 
> Signed-off-by: Sean Young <s...@mess.org>

Tested-by: Matthias Reichl <h...@horus.com>

Tested on RPi2, with downstream RPi kernel 4.13-rc1, using
ir-ctl to send RC-5 codes, against another RPi with gpio-ir-recv.
Also verified signal polarity and frequency on scope.

so long & thanks a lot,

Hias

> ---
>  MAINTAINERS  |   6 ++
>  drivers/media/rc/Kconfig |  12 
>  drivers/media/rc/Makefile|   1 +
>  drivers/media/rc/pwm-ir-tx.c | 138 
> +++
>  4 files changed, 157 insertions(+)
>  create mode 100644 drivers/media/rc/pwm-ir-tx.c
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 8a37c2f..446a528 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -10449,6 +10449,12 @@ F:   
> Documentation/devicetree/bindings/hwmon/pwm-fan.txt
>  F:   Documentation/hwmon/pwm-fan
>  F:   drivers/hwmon/pwm-fan.c
>  
> +PWM IR Transmitter
> +M:   Sean Young <s...@mess.org>
> +L:   linux-media@vger.kernel.org
> +S:   Maintained
> +F:   drivers/media/rc/pwm-ir-tx.c
> +
>  PWM SUBSYSTEM
>  M:   Thierry Reding <thierry.red...@gmail.com>
>  L:   linux-...@vger.kernel.org
> diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
> index ef767d1..bca77f0 100644
> --- a/drivers/media/rc/Kconfig
> +++ b/drivers/media/rc/Kconfig
> @@ -410,6 +410,18 @@ config IR_GPIO_TX
>  To compile this driver as a module, choose M here: the module will
>  be called gpio-ir-tx.
>  
> +config IR_PWM_TX
> + tristate "PWM IR transmitter"
> + depends on RC_CORE
> + depends on LIRC
> + depends on PWM
> + ---help---
> +Say Y if you want to use a PWM based IR transmitter. This is
> +more power efficient than the bit banging gpio driver.
> +
> +To compile this driver as a module, choose M here: the module will
> +be called pwm-ir-tx.
> +
>  config RC_ST
>   tristate "ST remote control receiver"
>   depends on RC_CORE
> diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
> index 3e64a4e..466c402 100644
> --- a/drivers/media/rc/Makefile
> +++ b/drivers/media/rc/Makefile
> @@ -33,6 +33,7 @@ obj-$(CONFIG_IR_WINBOND_CIR) += winbond-cir.o
>  obj-$(CONFIG_RC_LOOPBACK) += rc-loopback.o
>  obj-$(CONFIG_IR_GPIO_CIR) += gpio-ir-recv.o
>  obj-$(CONFIG_IR_GPIO_TX) += gpio-ir-tx.o
> +obj-$(CONFIG_IR_PWM_TX) += pwm-ir-tx.o
>  obj-$(CONFIG_IR_IGORPLUGUSB) += igorplugusb.o
>  obj-$(CONFIG_IR_IGUANA) += iguanair.o
>  obj-$(CONFIG_IR_TTUSBIR) += ttusbir.o
> diff --git a/drivers/media/rc/pwm-ir-tx.c b/drivers/media/rc/pwm-ir-tx.c
> new file mode 100644
> index 000..27d0f58
> --- /dev/null
> +++ b/drivers/media/rc/pwm-ir-tx.c
> @@ -0,0 +1,138 @@
> +/*
> + * Copyright (C) 2017 Sean Young <s...@mess.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#define DRIVER_NAME  "pwm-ir-tx"
> +#define DEVICE_NAME  "PWM IR Transmitter"
> +
> +struct pwm_ir {
> + struct pwm_device *pwm;
> + unsigned int carrier;
> + unsigned int duty_cycle;
> +};
> +
> +static const struct of_device_id pwm_ir_of_match[] = {
> + { .compatible = "pwm-ir-tx", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, pwm_ir_of_match);
> +
> +static int pwm_ir_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
> +{
> + struct pwm_ir *pwm_ir = dev->priv;
> +
> + pwm_ir->duty_cycle = duty_cycle;
> +
> + return 0;
> +}
> +
> +static int pwm_ir_set_carrier(struct rc_dev *dev, u32 carrier)
> +{
> + struct pwm_ir *pwm_ir = dev->priv;
> +
> + if (!carrier)
> + return -EINVAL;
> +
> + pwm_ir->carrier = carrier;
> +
> + return 0;
> +}
> +
> +static int pwm_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
> +  unsigned int count)
>

Re: [PATCH v2 3/6] [media] rc: gpio-ir-tx: add new driver

[Matthias Reichl]

Hi Sean,

On Fri, Jul 21, 2017 at 04:12:45PM +0200, Matthias Reichl wrote:
> Hi Sean,
> 
> On Fri, Jul 07, 2017 at 10:51:59AM +0100, Sean Young wrote:
> > This is a simple bit-banging GPIO IR TX driver.
> 
> thanks a lot for the driver, this is highly appreciated!
> 
> I tested the patch series on a RPi2, against RPi downstream kernel
> 4.13-rc1, and noticed an issue: the polarity of the gpio seems
> to be reversed.
> 
> Other than the polarity issue the driver seems to work fine -
> at least on the scope screen. Didn't have an IR transmitter to
> do some real tests yet.

I've now run a functional test and it worked fine.

I tested with your patch and my proposed changes, using an
active-high IR transmitter and ir-ctl -S rc5:... to send 
rc-5 codes and another RPi with gpio-ir-recv to receive/decode them.

so long & thanks a lot,

Hias

> 
> I've configured the gpio as active high:
> 
> gpio_ir_tx: gpio-ir-transmitter {
>   compatible = "gpio-ir-tx";
>   gpios = < 18 0>;
> };
> 
> However, when loading the gpio-ir-tx driver the gpio pin changed
> to 3.3V. I did some tests with ir-ctl -S, idle state of the signal
> was 3.3V, active state 0V.
> 
> I think it's better to use the descriptor based gpio functions
> instead of the legacy number based ones. That'll simplify the
> driver and it can delegate polarity handling to gpiod.
> 
> Proposed changes and comments are inline. I've also included
> the patch against your patch that I've been testing with at the
> end of the message.
> 
> > diff --git a/drivers/media/rc/gpio-ir-tx.c b/drivers/media/rc/gpio-ir-tx.c
> > new file mode 100644
> > index 000..7a5371d
> > --- /dev/null
> > +++ b/drivers/media/rc/gpio-ir-tx.c
> > @@ -0,0 +1,189 @@
> > +/*
> > + * Copyright (C) 2017 Sean Young <s...@mess.org>
> > + *
> > + * This program is free software; you can redistribute it and/or modify
> > + * it under the terms of the GNU General Public License version 2, or
> > + * (at your option) any later version.
> > + *
> > + * This program is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > + * GNU General Public License for more details.
> > + */
> > +
> > +#include 
> > +#include 
> > +#include 
> 
> use linux/gpio/consumer.h instead of linux/gpio.h
> 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> of_gpio.h can be dropped
> 
> > +#include 
> > +#include 
> > +
> > +#define DRIVER_NAME"gpio-ir-tx"
> > +#define DEVICE_NAME"GPIO Bit Banging IR Transmitter"
> > +
> > +struct gpio_ir {
> > +   int gpio_nr;
> > +   bool active_low;
> 
> Replace these 2 fields with
>   struct gpio_desc *gpio;
> 
> > +   unsigned int carrier;
> > +   unsigned int duty_cycle;
> > +   /* we need a spinlock to hold the cpu while transmitting */
> > +   spinlock_t lock;
> > +};
> > +
> > +static const struct of_device_id gpio_ir_tx_of_match[] = {
> > +   { .compatible = "gpio-ir-tx", },
> > +   { },
> > +};
> > +MODULE_DEVICE_TABLE(of, gpio_ir_tx_of_match);
> > +
> > +static int gpio_ir_tx_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
> > +{
> > +   struct gpio_ir *gpio_ir = dev->priv;
> > +
> > +   gpio_ir->duty_cycle = duty_cycle;
> > +
> > +   return 0;
> > +}
> > +
> > +static int gpio_ir_tx_set_carrier(struct rc_dev *dev, u32 carrier)
> > +{
> > +   struct gpio_ir *gpio_ir = dev->priv;
> > +
> > +   if (!carrier)
> > +   return -EINVAL;
> > +
> > +   gpio_ir->carrier = carrier;
> > +
> > +   return 0;
> > +}
> > +
> > +static int gpio_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
> > + unsigned int count)
> > +{
> > +   struct gpio_ir *gpio_ir = dev->priv;
> > +   unsigned long flags;
> > +   ktime_t edge;
> > +   /*
> > +* delta should never exceed 0.5 seconds (IR_MAX_DURATION) and on
> > +* m68k ndelay(s64) does not compile; so use s32 rather than s64.
> > +*/
> > +   s32 delta;
> > +   int i;
> > +   unsigned int pulse, space;
> > +
> > +   /* Ensure the dividend fits into 32 bit */
> > +   pulse = DIV_ROUND_CLOSEST(gpio_ir->duty_cycle * (NSEC_PER_SEC / 100),
> > + gpio_ir->carrier);
> > +   space = DIV_ROUN

Re: [PATCH v2 3/6] [media] rc: gpio-ir-tx: add new driver

[Matthias Reichl]

Hi Sean,

On Fri, Jul 07, 2017 at 10:51:59AM +0100, Sean Young wrote:
> This is a simple bit-banging GPIO IR TX driver.

thanks a lot for the driver, this is highly appreciated!

I tested the patch series on a RPi2, against RPi downstream kernel
4.13-rc1, and noticed an issue: the polarity of the gpio seems
to be reversed.

Other than the polarity issue the driver seems to work fine -
at least on the scope screen. Didn't have an IR transmitter to
do some real tests yet.

I've configured the gpio as active high:

gpio_ir_tx: gpio-ir-transmitter {
compatible = "gpio-ir-tx";
gpios = < 18 0>;
};

However, when loading the gpio-ir-tx driver the gpio pin changed
to 3.3V. I did some tests with ir-ctl -S, idle state of the signal
was 3.3V, active state 0V.

I think it's better to use the descriptor based gpio functions
instead of the legacy number based ones. That'll simplify the
driver and it can delegate polarity handling to gpiod.

Proposed changes and comments are inline. I've also included
the patch against your patch that I've been testing with at the
end of the message.

> diff --git a/drivers/media/rc/gpio-ir-tx.c b/drivers/media/rc/gpio-ir-tx.c
> new file mode 100644
> index 000..7a5371d
> --- /dev/null
> +++ b/drivers/media/rc/gpio-ir-tx.c
> @@ -0,0 +1,189 @@
> +/*
> + * Copyright (C) 2017 Sean Young 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2, or
> + * (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#include 
> +#include 
> +#include 

use linux/gpio/consumer.h instead of linux/gpio.h

> +#include 
> +#include 
> +#include 
> +#include 

of_gpio.h can be dropped

> +#include 
> +#include 
> +
> +#define DRIVER_NAME  "gpio-ir-tx"
> +#define DEVICE_NAME  "GPIO Bit Banging IR Transmitter"
> +
> +struct gpio_ir {
> + int gpio_nr;
> + bool active_low;

Replace these 2 fields with
struct gpio_desc *gpio;

> + unsigned int carrier;
> + unsigned int duty_cycle;
> + /* we need a spinlock to hold the cpu while transmitting */
> + spinlock_t lock;
> +};
> +
> +static const struct of_device_id gpio_ir_tx_of_match[] = {
> + { .compatible = "gpio-ir-tx", },
> + { },
> +};
> +MODULE_DEVICE_TABLE(of, gpio_ir_tx_of_match);
> +
> +static int gpio_ir_tx_set_duty_cycle(struct rc_dev *dev, u32 duty_cycle)
> +{
> + struct gpio_ir *gpio_ir = dev->priv;
> +
> + gpio_ir->duty_cycle = duty_cycle;
> +
> + return 0;
> +}
> +
> +static int gpio_ir_tx_set_carrier(struct rc_dev *dev, u32 carrier)
> +{
> + struct gpio_ir *gpio_ir = dev->priv;
> +
> + if (!carrier)
> + return -EINVAL;
> +
> + gpio_ir->carrier = carrier;
> +
> + return 0;
> +}
> +
> +static int gpio_ir_tx(struct rc_dev *dev, unsigned int *txbuf,
> +   unsigned int count)
> +{
> + struct gpio_ir *gpio_ir = dev->priv;
> + unsigned long flags;
> + ktime_t edge;
> + /*
> +  * delta should never exceed 0.5 seconds (IR_MAX_DURATION) and on
> +  * m68k ndelay(s64) does not compile; so use s32 rather than s64.
> +  */
> + s32 delta;
> + int i;
> + unsigned int pulse, space;
> +
> + /* Ensure the dividend fits into 32 bit */
> + pulse = DIV_ROUND_CLOSEST(gpio_ir->duty_cycle * (NSEC_PER_SEC / 100),
> +   gpio_ir->carrier);
> + space = DIV_ROUND_CLOSEST((100 - gpio_ir->duty_cycle) *
> +   (NSEC_PER_SEC / 100), gpio_ir->carrier);
> +
> + spin_lock_irqsave(_ir->lock, flags);
> +
> + edge = ktime_get();
> +
> + for (i = 0; i < count; i++) {
> + if (i % 2) {
> + // space
> + edge = ktime_add_us(edge, txbuf[i]);
> + delta = ktime_us_delta(edge, ktime_get());
> + if (delta > 10) {
> + spin_unlock_irqrestore(_ir->lock, flags);
> + usleep_range(delta, delta + 10);
> + spin_lock_irqsave(_ir->lock, flags);
> + } else if (delta > 0) {
> + udelay(delta);
> + }
> + } else {
> + // pulse
> + ktime_t last = ktime_add_us(edge, txbuf[i]);
> +
> + while (ktime_get() < last) {
> + gpio_set_value(gpio_ir->gpio_nr,
> +gpio_ir->active_low);

gpiod_set_value(gpio_ir->gpio, 1);

> + edge += pulse;
> + delta = edge - 

Re: [PATCH] media: Convert to using %pOF instead of full_name

[Matthias Brugger]

On 07/18/2017 11:43 PM, Rob Herring wrote:

Now that we have a custom printf format specifier, convert users of
full_name to use %pOF instead. This is preparation to remove storing
of the full path string for each node.

Signed-off-by: Rob Herring <r...@kernel.org>
Cc: Kyungmin Park <kyungmin.p...@samsung.com>
Cc: Andrzej Hajda <a.ha...@samsung.com>
Cc: Mauro Carvalho Chehab <mche...@kernel.org>
Cc: "Lad, Prabhakar" <prabhakar.cse...@gmail.com>
Cc: Songjun Wu <songjun...@microchip.com>
Cc: Sylwester Nawrocki <s.nawro...@samsung.com>
Cc: Kukjin Kim <kg...@kernel.org>
Cc: Krzysztof Kozlowski <k...@kernel.org>
Cc: Javier Martinez Canillas <jav...@osg.samsung.com>
Cc: Minghsiu Tsai <minghsiu.t...@mediatek.com>
Cc: Houlong Wei <houlong....@mediatek.com>
Cc: Andrew-CT Chen <andrew-ct.c...@mediatek.com>
Cc: Matthias Brugger <matthias@gmail.com>
Cc: Laurent Pinchart <laurent.pinch...@ideasonboard.com>
Cc: "Niklas Söderlund" <niklas.soderl...@ragnatech.se>
Cc: Guennadi Liakhovetski <g.liakhovet...@gmx.de>
Cc: Hyun Kwon <hyun.k...@xilinx.com>
Cc: Michal Simek <michal.si...@xilinx.com>
Cc: "Sören Brinkmann" <soren.brinkm...@xilinx.com>
Cc: linux-media@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-samsung-...@vger.kernel.org
Cc: linux-media...@lists.infradead.org
Cc: linux-renesas-...@vger.kernel.org
---
  drivers/media/i2c/s5c73m3/s5c73m3-core.c   |  3 +-
  drivers/media/i2c/s5k5baf.c|  7 ++--
  drivers/media/platform/am437x/am437x-vpfe.c|  4 +-
  drivers/media/platform/atmel/atmel-isc.c   |  4 +-
  drivers/media/platform/davinci/vpif_capture.c  | 16 
  drivers/media/platform/exynos4-is/fimc-is.c|  8 ++--
  drivers/media/platform/exynos4-is/fimc-lite.c  |  3 +-
  drivers/media/platform/exynos4-is/media-dev.c  |  8 ++--
  drivers/media/platform/exynos4-is/mipi-csis.c  |  4 +-
  drivers/media/platform/mtk-mdp/mtk_mdp_comp.c  |  6 +--
  drivers/media/platform/mtk-mdp/mtk_mdp_core.c  |  8 ++--


For mediatek parts:

Reviewed-by: Matthias Brugger <matthias@gmail.com>

[v4l-utils] 70-infrared.rules starts ir-keytable too early

[Matthias Reichl]

While testing serial_ir on kernel 4.11.8 with ir-keytable 1.12.3
I noticed that my /etc/rc_maps.cfg configuration wasn't applied.
Manually running "ir-keytable -a /etc/rc_maps.cfg -s rc0" always
worked fine, though.

Digging further into this I tracked it down to the udev rule
being racy. The udev rule triggers on the rc subsystem, but this
is before the input and event devices are created.

The kernel creates 3 events relevant to this context, on rcX
device creation, on inputY creation and on inputY/eventZ creation
- the latter 2 usually in quick succession, but some time can
elapse between the first 2.

In my case ir-keytable -a was executing during this small time
window and failed with an error because it couldn't find the
input/event devices.

Excerpt from log with udev debugging enabled:

Jul 16 11:02:11 LibreELEC systemd-udevd[272]: seq 2099 queued, 'add' 'rc'
...
Jul 16 11:02:11 LibreELEC systemd-udevd[614]: '/usr/bin/ir-keytable -a 
/etc/rc_maps.cfg -s rc0'(err) 'Couldn't find any node at 
/sys/class/rc/rc0/input*.'
Jul 16 11:02:11 LibreELEC systemd-udevd[614]: Process '/usr/bin/ir-keytable -a 
/etc/rc_maps.cfg -s rc0' failed with exit code 255.
...
Jul 16 11:02:11 LibreELEC systemd-udevd[272]: seq 2106 queued, 'add' 'input'
Jul 16 11:02:11 LibreELEC systemd-udevd[272]: seq 2106 forked new worker [622]
Jul 16 11:02:11 LibreELEC systemd-udevd[272]: seq 2107 queued, 'add' 'input'

The full log is available here:
http://www.horus.com/~hias/tmp/journalctl-ir-keytable-failed

One solution is to trigger ir-keytable -a execution from the event device
creation instead. I'm currently testing with the following udev rule:

ACTION=="add", SUBSYSTEMS=="rc", GOTO="begin"
GOTO="end"

LABEL="begin"

SUBSYSTEM=="rc", ENV{rc_sysdev}="$name"

SUBSYSTEM=="input", IMPORT{parent}="rc_sysdev"

KERNEL=="event[0-9]*", ENV{rc_sysdev}=="?*", \
   RUN+="/usr/bin/ir-keytable -a /etc/rc_maps.cfg -s $env{rc_sysdev}"

LABEL="end"

That udev rule is a bit messy, ir-keytable -a needs the rcX sysdev,
which doesn't seem to be easily available from the event node in
the input subsystem, so I'm propagating that info through an
environment variable.

So far testing is working fine, but hints for better/nicer solutions
are welcome!

so long,

Hias

Re: [v2,07/12] intel-ipu3: css: firmware management

[Matthias Kaehlcke]

El Wed, Jun 14, 2017 at 05:19:22PM -0500 Yong Zhi ha dit:

> Functions to load and install imgu FW blobs
> 
> Signed-off-by: Yong Zhi 
> ---
>  drivers/media/pci/intel/ipu3/ipu3-abi.h| 1573 
> 
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.c |  272 +
>  drivers/media/pci/intel/ipu3/ipu3-css-fw.h |  219 
>  drivers/media/pci/intel/ipu3/ipu3-css.h|   54 +
>  4 files changed, 2118 insertions(+)
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-abi.h
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.c
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css-fw.h
>  create mode 100644 drivers/media/pci/intel/ipu3/ipu3-css.h
> 
> diff --git a/drivers/media/pci/intel/ipu3/ipu3-abi.h 
> b/drivers/media/pci/intel/ipu3/ipu3-abi.h
> new file mode 100644
> index 000..5107b35
> --- /dev/null
> +++ b/drivers/media/pci/intel/ipu3/ipu3-abi.h
> @@ -0,0 +1,1573 @@
> +/*
> + * Copyright (c) 2017 Intel Corporation.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License version
> + * 2 as published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + */
> +
> +#ifndef __IPU3_ABI_H
> +#define __IPU3_ABI_H
> +
> +#include 
> +
> +/*** IMGU Hardware information ***/
> +
> +#define IMGU_ISP_VMEM_ALIGN  128
> +#define IMGU_DVS_BLOCK_W 64
> +#define IMGU_DVS_BLOCK_H 32
> +#define IMGU_GDC_BUF_X   (2 * IMGU_DVS_BLOCK_W)
> +#define IMGU_GDC_BUF_Y   IMGU_DVS_BLOCK_H
> +/* n = 0..1 */
> +#define IMGU_SP_PMEM_BASE(n) (0x2 + (n) * 0x4000)
> +#define IMGU_MAX_BQ_GRID_WIDTH   80
> +#define IMGU_MAX_BQ_GRID_HEIGHT  60
> +#define IMGU_OBGRID_TILE_SIZE16
> +#define IMGU_PIXELS_PER_WORD 50
> +#define IMGU_BYTES_PER_WORD  64
> +#define IMGU_STRIPE_FIXED_HALF_OVERLAP   2
> +#define IMGU_SHD_SETS3
> +#define IMGU_BDS_MIN_CLIP_VAL0
> +#define IMGU_BDS_MAX_CLIP_VAL2
> +#define IPU3_ABI_AWB_MAX_CELLS_PER_SET   160
> +#define IPU3_ABI_AF_MAX_CELLS_PER_SET32
> +#define IPU3_ABI_AWB_FR_MAX_CELLS_PER_SET32
> +
> +#define IMGU_ABI_ACC_OP_IDLE 0
> +#define IMGU_ABI_ACC_OP_END_OF_ACK   1
> +#define IMGU_ABI_ACC_OP_END_OF_OPS   2
> +#define IMGU_ABI_ACC_OP_NO_OPS   3
> +
> +#define IMGU_ABI_ACC_OPTYPE_PROCESS_LINES0
> +#define IMGU_ABI_ACC_OPTYPE_TRANSFER_DATA1
> +
> +#define IMGU_MMU_PADDR_SHIFT 12
> +
> +/* Register definitions */
> +
> +/* PM_CTRL_0_5_0_IMGHMMADR */
> +#define IMGU_REG_PM_CTRL 0x0
> +#define IMGU_PM_CTRL_START   BIT(0)
> +#define IMGU_PM_CTRL_CFG_DONEBIT(1)
> +#define IMGU_PM_CTRL_RACE_TO_HALTBIT(2)
> +#define IMGU_PM_CTRL_NACK_ALLBIT(3)
> +#define IMGU_PM_CTRL_CSS_PWRDN   BIT(4)
> +#define IMGU_PM_CTRL_RST_AT_EOF  BIT(5)
> +#define IMGU_PM_CTRL_FORCE_HALT  BIT(6)
> +#define IMGU_PM_CTRL_FORCE_UNHALTBIT(7)
> +#define IMGU_PM_CTRL_FORCE_PWRDN BIT(8)
> +#define IMGU_PM_CTRL_FORCE_RESET BIT(9)
> +#define IMGU_PM_CTRL_RETURN_LICENSE_AT_EOF   BIT(10)
> +#define IMGU_PM_CTRL_POWER_DOWN_AT_EOF   (IMGU_PM_CTRL_CSS_PWRDN 
> | \
> + IMGU_PM_CTRL_RACE_TO_HALT | \
> + IMGU_PM_CTRL_RETURN_LICENSE_AT_EOF)
> +#define IMGU_PM_CTRL_RESET_AT_EOF(IMGU_PM_CTRL_RST_AT_EOF | \
> + IMGU_PM_CTRL_RACE_TO_HALT | \
> + IMGU_PM_CTRL_RETURN_LICENSE_AT_EOF)
> +/* SYSTEM_REQ_0_5_0_IMGHMMADR */
> +#define IMGU_REG_SYSTEM_REQ  0x18
> +#define IMGU_SYSTEM_REQ_FREQ_MASK0x3f
> +#define IMGU_SYSTEM_REQ_FREQ_DIVIDER 25
> +#define IMGU_REG_INT_STATUS  0x30
> +#define IMGU_REG_INT_ENABLE  0x34
> +#define IMGU_REG_INT_CSS_IRQ (1 << 31)
> +/* STATE_0_5_0_IMGHMMADR */
> +#define IMGU_REG_STATE   0x130
> +#define IMGU_STATE_HALT_STS  BIT(0)
> +#define IMGU_STATE_IDLE_STS  BIT(1)
> +#define IMGU_STATE_POWER_UP  BIT(2)
> +#define IMGU_STATE_POWER_DOWNBIT(3)
> +#define 

Re: Unknown symbol put_vaddr_frames when using media_build

[Matthias Schwarzott]

Am 07.06.2017 um 20:23 schrieb Mauro Carvalho Chehab:
> Em Tue, 9 May 2017 06:56:25 +0200
> Matthias Schwarzott <z...@gentoo.org> escreveu:
> 
>> Hi!
>>
>> Whenever I compile the media drivers using media_build against a recent
>> kernel, I get this message when loading them:
>>
>> [5.848537] media: Linux media interface: v0.10
>> [5.881440] Linux video capture interface: v2.00
>> [5.881441] WARNING: You are using an experimental version of the
>> media stack.
>> ...
>> [6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
>> [6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
>> [6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
>> [6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)
>>
>> That means I am not able to load any drivers being based on
>> videobuf2_memops without manual actions.
>>
>> I used kernel 4.11.0, but it does not matter which kernel version
>> exactly is used.
>>
>> My solution for that has been to modify mm/Kconfig of my kernel like
>> this and then enable FRAME_VECTOR in .config
> 
> Well, if you build your Kernel with VB2 compiled, you'll have it.
> 
Sure.

So my question is:
How good do the kernel origin vb2 and the media_build vb2 play together?

Will modprobe always choose the media_build one?
Or will "make install" just overwrite the original file?

>> diff --git a/mm/Kconfig b/mm/Kconfig
>> index 9b8fccb969dc..cfa6a80d1a0a 100644
>> --- a/mm/Kconfig
>> +++ b/mm/Kconfig
>> @@ -701,7 +701,7 @@ config ZONE_DEVICE
>>   If FS_DAX is enabled, then say Y.
>>
>>  config FRAME_VECTOR
>> -   bool
>> +   tristate "frame vector"
>>
>>  config ARCH_USES_HIGH_VMA_FLAGS
>> bool
>>
>> But I do not like that solution.
>> I would prefer one of these solutions:
>>
>> 1. Have media_build apply its fallback the same way as for older kernels
>> that do not even have the the FRAME_VECTOR support.
>>
>> 2. Get the above patch merged (plus description etc.).
>>
>> What do you think?
> 
> (1) is probably simpler, but you would need to play with the building
> system in order to identify if the current Kernel has it enabled or not.
> That could be tricky.
> 
> I suspect people won't accept (2), as it doesn't make sense upstream.

Well, it would be equivalent to options like CRC16 in folder lib.

Regards
Matthias

Re: [PATCH v4 3/3] media: mtk-mdp: Fix mdp device tree

[Matthias Brugger]

On 07/06/17 11:11, Hans Verkuil wrote:

On 07/06/17 11:07, Matthias Brugger wrote:



On 07/06/17 10:56, Hans Verkuil wrote:

On 07/06/17 10:44, Matthias Brugger wrote:

Hi Hans, hi Mauro,

On 23/05/17 05:24, Minghsiu Tsai wrote:

From: Daniel Kurtz <djku...@chromium.org>

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.

Signed-off-by: Daniel Kurtz <djku...@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>
Signed-off-by: Matthias Brugger <matthias@gmail.com>



Are you OK to take this patch, or do you have any further comments?


Nope, it's all good. Queued for 4.13.



Thanks!

I queued the other two in v4.12-next/dts64


Media bindings normally go through the media subsystem, but you've taken
that one as well? I need to know, because then I drop it in my tree.



My fault, I'll drop it from my tree. After that I only queued patch 2/3.

Sorry.
Matthias

Re: [PATCH v4 3/3] media: mtk-mdp: Fix mdp device tree

[Matthias Brugger]

On 07/06/17 10:56, Hans Verkuil wrote:

On 07/06/17 10:44, Matthias Brugger wrote:

Hi Hans, hi Mauro,

On 23/05/17 05:24, Minghsiu Tsai wrote:

From: Daniel Kurtz <djku...@chromium.org>

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.

Signed-off-by: Daniel Kurtz <djku...@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>
Signed-off-by: Matthias Brugger <matthias@gmail.com>



Are you OK to take this patch, or do you have any further comments?


Nope, it's all good. Queued for 4.13.



Thanks!

I queued the other two in v4.12-next/dts64

Regards,
Matthias


Regards,

    Hans



Regards,
Matthias


---
   drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 12 ++--
   1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..8134755 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
   {
   struct mtk_mdp_dev *mdp;
   struct device *dev = >dev;
-struct device_node *node;
+struct device_node *node, *parent;
   int i, ret = 0;
 mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
@@ -117,8 +117,16 @@ static int mtk_mdp_probe(struct platform_device *pdev)
   mutex_init(>lock);
   mutex_init(>vpulock);
   +/* Old dts had the components as child nodes */
+if (of_get_next_child(dev->of_node, NULL)) {
+parent = dev->of_node;
+dev_warn(dev, "device tree is out of date\n");
+} else {
+parent = dev->of_node->parent;
+}
+
   /* Iterate over sibling MDP function blocks */
-for_each_child_of_node(dev->of_node, node) {
+for_each_child_of_node(parent, node) {
   const struct of_device_id *of_id;
   enum mtk_mdp_comp_type comp_type;
   int comp_id;

Re: [PATCH v4 3/3] media: mtk-mdp: Fix mdp device tree

[Matthias Brugger]

Hi Hans, hi Mauro,

On 23/05/17 05:24, Minghsiu Tsai wrote:

From: Daniel Kurtz <djku...@chromium.org>

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.

Signed-off-by: Daniel Kurtz <djku...@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>
Signed-off-by: Matthias Brugger <matthias@gmail.com>



Are you OK to take this patch, or do you have any further comments?

Regards,
Matthias


---
  drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 12 ++--
  1 file changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..8134755 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
  {
struct mtk_mdp_dev *mdp;
struct device *dev = >dev;
-   struct device_node *node;
+   struct device_node *node, *parent;
int i, ret = 0;
  
  	mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);

@@ -117,8 +117,16 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(>lock);
mutex_init(>vpulock);
  
+	/* Old dts had the components as child nodes */

+   if (of_get_next_child(dev->of_node, NULL)) {
+   parent = dev->of_node;
+   dev_warn(dev, "device tree is out of date\n");
+   } else {
+   parent = dev->of_node->parent;
+   }
+
/* Iterate over sibling MDP function blocks */
-   for_each_child_of_node(dev->of_node, node) {
+   for_each_child_of_node(parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;

Re: [PATCH v9 3/4] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Matthias Brugger]

On 10/05/17 13:02, Matthias Brugger wrote:



On 14/12/16 09:04, Rick Chang wrote:

Signed-off-by: Rick Chang <rick.ch...@mediatek.com>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>
---
This patch depends on:
   CCF "Add clock support for Mediatek MT2701"[1]
   iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] 
http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html 


[2] https://patchwork.kernel.org/patch/9164013/


Now queued for v4.12-next/dts32

Thanks and sorry for the delay.
Matthias



I realized that a long time ago I made a mistake when taking:
f3cba0f49c7c ("ARM: dts: mt2701: add iommu/smi dtsi node for mt2701")

as I forgot to include dt-bindings/memory/mt2701-larb-port.h

I fixed this now in v4.12-next/dts32

Sorry for that.

Regards,
Matthias


---
  arch/arm/boot/dts/mt2701.dtsi | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi 
b/arch/arm/boot/dts/mt2701.dtsi

index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
  power-domains = < MT2701_POWER_DOMAIN_ISP>;
  };
+jpegdec: jpegdec@15004000 {
+compatible = "mediatek,mt2701-jpgdec";
+reg = <0 0x15004000 0 0x1000>;
+interrupts = ;
+clocks =  < CLK_IMG_JPGDEC_SMI>,
+  < CLK_IMG_JPGDEC>;
+clock-names = "jpgdec-smi",
+  "jpgdec";
+power-domains = < MT2701_POWER_DOMAIN_ISP>;
+mediatek,larb = <>;
+iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+ < MT2701_M4U_PORT_JPGDEC_BSDMA>;
+};
+
  vdecsys: syscon@1600 {
  compatible = "mediatek,mt2701-vdecsys", "syscon";
  reg = <0 0x1600 0 0x1000>;

Re: [PATCH v3 0/3] Fix mdp device tree

[Matthias Brugger]

On 22/05/17 11:09, Hans Verkuil wrote:

On 05/12/2017 05:22 AM, Minghsiu Tsai wrote:

Who should take care of the dtsi changes? I'm not sure who maintains the mdp 
dts.


I will take care of the dtsi patches.



The driver change and the dtsi change need to be in sync, so it is probably 
easiest
to merge this via one tree.

Here is my Acked-by for these three patches:

Acked-by: Hans Verkuil <hans.verk...@cisco.com>

I can take all three, provided I have the Ack of the mdp dts maintainer. Or it 
can
go through him with my Ack.



I think we should provide backwards compability instead, as proposed here:
http://lists.infradead.org/pipermail/linux-mediatek/2017-May/008811.html

If this change is ok for you, please let Minghsiu know so that he can 
provide a v4.


Regards,
Matthias


Regards,

Hans


Changes in v3:
- Upload patches again because forget to add v2 in title

Changes in v2:
- Update commit message

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.

Daniel Kurtz (2):
   arm64: dts: mt8173: Fix mdp device tree
   media: mtk-mdp: Fix mdp device tree

Minghsiu Tsai (1):
   dt-bindings: mt8173: Fix mdp device tree

  .../devicetree/bindings/media/mediatek-mdp.txt |  12 +-
  arch/arm64/boot/dts/mediatek/mt8173.dtsi   | 126 ++---
  drivers/media/platform/mtk-mdp/mtk_mdp_core.c  |   2 +-
  3 files changed, 64 insertions(+), 76 deletions(-)

Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

[Matthias Brugger]

On 15/05/17 04:31, Minghsiu Tsai wrote:

On Fri, 2017-05-12 at 17:05 +0200, Matthias Brugger wrote:


On 12/05/17 05:22, Minghsiu Tsai wrote:

From: Daniel Kurtz <djku...@chromium.org>

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.



Couldn't we preserve backwards compatibility by doing something like this:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7dcc424..277d8fe6eb76 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
   {
struct mtk_mdp_dev *mdp;
struct device *dev = >dev;
-   struct device_node *node;
+   struct device_node *node, *parent;
int i, ret = 0;

mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
@@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(>lock);
mutex_init(>vpulock);

+   /* Old dts had the components as child nodes */
+   if (of_get_next_child(dev->of_node, NULL))
+   parent = dev->of_node;
+   else
+   parent = dev->of_node->parent;
+
/* Iterate over sibling MDP function blocks */
-   for_each_child_of_node(dev->of_node, node) {
+   for_each_child_of_node(parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;

Maybe even by putting a warning in the if branch to make sure, people
are aware of their out-of-date device tree blobs.

Regards,
Matthias



Hi Matthias,

It is a good idea to do compatible in such a way and put a warning the
device tree is out of date. People can find out cause soon if device
tree is old.

I modify the code as below:

+   /* Old dts had the components as child nodes */
+   if (of_get_next_child(dev->of_node, NULL)) {
+   parent = dev->of_node;
+   dev_warn(dev, "device tree is out of date\n");
+   } else {
+   parent = dev->of_node->parent;
+   }

Will you upload it in a separate patch?
If not, I can merge it in my patch series and upload v4.



Please integrate it into your patch series.

Mauro, are you ok with the dev_warn about the out-of-date device-tree?

Regards,
Matthias




Best Regards,

Ming Hsiu


Signed-off-by: Daniel Kurtz <djku...@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>

---
   drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..a5ad586 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(>vpulock);
   
   	/* Iterate over sibling MDP function blocks */

-   for_each_child_of_node(dev->of_node, node) {
+   for_each_child_of_node(dev->of_node->parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;

Re: [PATCH v3 3/3] media: mtk-mdp: Fix mdp device tree

[Matthias Brugger]

On 12/05/17 05:22, Minghsiu Tsai wrote:

From: Daniel Kurtz <djku...@chromium.org>

If the mdp_* nodes are under an mdp sub-node, their corresponding
platform device does not automatically get its iommu assigned properly.

Fix this by moving the mdp component nodes up a level such that they are
siblings of mdp and all other SoC subsystems.  This also simplifies the
device tree.

Although it fixes iommu assignment issue, it also break compatibility
with old device tree. So, the patch in driver is needed to iterate over
sibling mdp device nodes, not child ones, to keep driver work properly.



Couldn't we preserve backwards compatibility by doing something like this:
diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c

index 9e4eb7dcc424..277d8fe6eb76 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -103,7 +103,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
 {
struct mtk_mdp_dev *mdp;
struct device *dev = >dev;
-   struct device_node *node;
+   struct device_node *node, *parent;
int i, ret = 0;

mdp = devm_kzalloc(dev, sizeof(*mdp), GFP_KERNEL);
@@ -117,8 +117,14 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(>lock);
mutex_init(>vpulock);

+   /* Old dts had the components as child nodes */
+   if (of_get_next_child(dev->of_node, NULL))
+   parent = dev->of_node;
+   else
+   parent = dev->of_node->parent;
+
/* Iterate over sibling MDP function blocks */
-   for_each_child_of_node(dev->of_node, node) {
+   for_each_child_of_node(parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;

Maybe even by putting a warning in the if branch to make sure, people 
are aware of their out-of-date device tree blobs.


Regards,
Matthias


Signed-off-by: Daniel Kurtz <djku...@chromium.org>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>

---
  drivers/media/platform/mtk-mdp/mtk_mdp_core.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c 
b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
index 9e4eb7d..a5ad586 100644
--- a/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
+++ b/drivers/media/platform/mtk-mdp/mtk_mdp_core.c
@@ -118,7 +118,7 @@ static int mtk_mdp_probe(struct platform_device *pdev)
mutex_init(>vpulock);
  
  	/* Iterate over sibling MDP function blocks */

-   for_each_child_of_node(dev->of_node, node) {
+   for_each_child_of_node(dev->of_node->parent, node) {
const struct of_device_id *of_id;
enum mtk_mdp_comp_type comp_type;
int comp_id;

Re: [PATCH v9 3/4] arm: dts: mt2701: Add node for Mediatek JPEG Decoder

[Matthias Brugger]

On 14/12/16 09:04, Rick Chang wrote:

Signed-off-by: Rick Chang <rick.ch...@mediatek.com>
Signed-off-by: Minghsiu Tsai <minghsiu.t...@mediatek.com>
---
This patch depends on:
   CCF "Add clock support for Mediatek MT2701"[1]
   iommu and smi "Add the dtsi node of iommu and smi for mt2701"[2]

[1] http://lists.infradead.org/pipermail/linux-mediatek/2016-October/007271.html
[2] https://patchwork.kernel.org/patch/9164013/


Now queued for v4.12-next/dts32

Thanks and sorry for the delay.
Matthias


---
  arch/arm/boot/dts/mt2701.dtsi | 14 ++
  1 file changed, 14 insertions(+)

diff --git a/arch/arm/boot/dts/mt2701.dtsi b/arch/arm/boot/dts/mt2701.dtsi
index 8f13c70..4dd5048 100644
--- a/arch/arm/boot/dts/mt2701.dtsi
+++ b/arch/arm/boot/dts/mt2701.dtsi
@@ -298,6 +298,20 @@
power-domains = < MT2701_POWER_DOMAIN_ISP>;
};
  
+	jpegdec: jpegdec@15004000 {

+   compatible = "mediatek,mt2701-jpgdec";
+   reg = <0 0x15004000 0 0x1000>;
+   interrupts = ;
+   clocks =  < CLK_IMG_JPGDEC_SMI>,
+ < CLK_IMG_JPGDEC>;
+   clock-names = "jpgdec-smi",
+ "jpgdec";
+   power-domains = < MT2701_POWER_DOMAIN_ISP>;
+   mediatek,larb = <>;
+   iommus = < MT2701_M4U_PORT_JPGDEC_WDMA>,
+< MT2701_M4U_PORT_JPGDEC_BSDMA>;
+   };
+
vdecsys: syscon@1600 {
compatible = "mediatek,mt2701-vdecsys", "syscon";
reg = <0 0x1600 0 0x1000>;

Unknown symbol put_vaddr_frames when using media_build

[Matthias Schwarzott]

Hi!

Whenever I compile the media drivers using media_build against a recent
kernel, I get this message when loading them:

[5.848537] media: Linux media interface: v0.10
[5.881440] Linux video capture interface: v2.00
[5.881441] WARNING: You are using an experimental version of the
media stack.
...
[6.166390] videobuf2_memops: Unknown symbol put_vaddr_frames (err 0)
[6.166394] videobuf2_memops: Unknown symbol get_vaddr_frames (err 0)
[6.166396] videobuf2_memops: Unknown symbol frame_vector_destroy (err 0)
[6.166398] videobuf2_memops: Unknown symbol frame_vector_create (err 0)

That means I am not able to load any drivers being based on
videobuf2_memops without manual actions.

I used kernel 4.11.0, but it does not matter which kernel version
exactly is used.

My solution for that has been to modify mm/Kconfig of my kernel like
this and then enable FRAME_VECTOR in .config

diff --git a/mm/Kconfig b/mm/Kconfig
index 9b8fccb969dc..cfa6a80d1a0a 100644
--- a/mm/Kconfig
+++ b/mm/Kconfig
@@ -701,7 +701,7 @@ config ZONE_DEVICE
  If FS_DAX is enabled, then say Y.

 config FRAME_VECTOR
-   bool
+   tristate "frame vector"

 config ARCH_USES_HIGH_VMA_FLAGS
bool

But I do not like that solution.
I would prefer one of these solutions:

1. Have media_build apply its fallback the same way as for older kernels
that do not even have the the FRAME_VECTOR support.

2. Get the above patch merged (plus description etc.).

What do you think?

Regards
Matthias

Re: [PATCH] [media] vcodec: mediatek: Remove double parentheses

[Matthias Kaehlcke]

El Fri, Mar 17, 2017 at 02:01:33PM -0700 Matthias Kaehlcke ha dit:

> The extra pairs of parentheses are not needed and cause clang
> warnings like this:
> 
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: error: equality 
> comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
> if ((inst->work_bufs[i].size == 0))
>  ^~~~
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: remove 
> extraneous parentheses around the comparison to silence this warning
> if ((inst->work_bufs[i].size == 0))
> ~^   ~
> drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: use '=' to 
> turn this equality comparison into an assignment
> if ((inst->work_bufs[i].size == 0))
>  ^~
>      =
> 
> Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
> ---
>  drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
> b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> index 544f57186243..129cc74b4fe4 100644
> --- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> +++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
> @@ -155,7 +155,7 @@ static void vp8_enc_free_work_buf(struct venc_vp8_inst 
> *inst)
>  
>   /* Buffers need to be freed by AP. */
>   for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
> - if ((inst->work_bufs[i].size == 0))
> + if (inst->work_bufs[i].size == 0)
>   continue;
>   mtk_vcodec_mem_free(inst->ctx, >work_bufs[i]);
>   }
> @@ -172,7 +172,7 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst 
> *inst)
>   mtk_vcodec_debug_enter(inst);
>  
>   for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
> - if ((wb[i].size == 0))
> + if (wb[i].size == 0)
>   continue;
>   /*
>* This 'wb' structure is set by VPU side and shared to AP for

Ping? Any feedback on this patch?

Cheers

Matthias

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

[Matthias Schwarzott]

Am 26.03.2017 um 12:34 schrieb Daniel Scheller:
> Am Sun, 26 Mar 2017 10:03:33 +0200
> schrieb Matthias Schwarzott <z...@gentoo.org>:
> 
>> Am 24.03.2017 um 19:23 schrieb Daniel Scheller:
>>> From: Daniel Scheller <d.schel...@gmx.net>
>>>
>>> Some hardware and bridges (namely ddbridge) require that tuner
>>> access is limited to one concurrent access and wrap i2c gate
>>> control with a mutex_lock when attaching frontends. According to
>>> vendor information, this is required as concurrent tuner
>>> reconfiguration can interfere each other and at worst cause tuning
>>> fails or bad reception quality.
>>>
>>> If the demod driver does gate_ctrl before setting up tuner
>>> parameters, and the tuner does another I2C enable, it will deadlock
>>> forever when gate_ctrl is wrapped into the mutex_lock. This adds a
>>> flag and a conditional before triggering gate_ctrl in the
>>> demodulator driver. 
>>
>> If I get this right, the complete call to i2c_gate_ctrl should be
>> disabled. Why not just overwrite the function-pointer i2c_gate_ctrl
>> with NULL in the relevant attach function (stv0367ddb_attach) or not
>> define it in stv0367ddb_ops?
> 
> This will make communication with the TDA18212 tuner chip impossible.
> We need to open stv0367's I2C gate, thus need the function. But for the
> overall hardware case, concurrent tuner reconfiguration must be avoided
> due to the mentioned issues, thus after _attach the bridge driver
> remaps the function pointer to wrap i2c_gate_ctrl with a lock to
> accomplish this - see [1] and [2]. As the demod AND the tuner driver
> both open the I2C gate, this will lead to a dead lock. To not change or
> break existing behaviour with other cards and tuner drivers, this
> (flag, conditional) appears to be the best option.

Ok, I understand: The real problem is that both demod driver (around
tuner access) and tuner driver care about the i2c_gate.

Regards
Matthias

Re: [PATCH v2 01/12] [media] dvb-frontends/stv0367: add flag to make i2c_gatectrl optional

[Matthias Schwarzott]

Am 24.03.2017 um 19:23 schrieb Daniel Scheller:
> From: Daniel Scheller <d.schel...@gmx.net>
> 
> Some hardware and bridges (namely ddbridge) require that tuner access is
> limited to one concurrent access and wrap i2c gate control with a
> mutex_lock when attaching frontends. According to vendor information, this
> is required as concurrent tuner reconfiguration can interfere each other
> and at worst cause tuning fails or bad reception quality.
> 
> If the demod driver does gate_ctrl before setting up tuner parameters, and
> the tuner does another I2C enable, it will deadlock forever when gate_ctrl
> is wrapped into the mutex_lock. This adds a flag and a conditional before
> triggering gate_ctrl in the demodulator driver.
> 

If I get this right, the complete call to i2c_gate_ctrl should be disabled.
Why not just overwrite the function-pointer i2c_gate_ctrl with NULL in
the relevant attach function (stv0367ddb_attach) or not define it in
stv0367ddb_ops?

That should have exactly the same effect.

Regards
Matthias

[PATCH] [media] vcodec: mediatek: Remove double parentheses

[Matthias Kaehlcke]

The extra pairs of parentheses are not needed and cause clang
warnings like this:

drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: error: equality 
comparison with extraneous parentheses [-Werror,-Wparentheses-equality]
if ((inst->work_bufs[i].size == 0))
 ^~~~
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: remove 
extraneous parentheses around the comparison to silence this warning
if ((inst->work_bufs[i].size == 0))
~^   ~
drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c:158:32: note: use '=' to 
turn this equality comparison into an assignment
if ((inst->work_bufs[i].size == 0))
 ^~
 =

Signed-off-by: Matthias Kaehlcke <m...@chromium.org>
---
 drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c 
b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
index 544f57186243..129cc74b4fe4 100644
--- a/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
+++ b/drivers/media/platform/mtk-vcodec/venc/venc_vp8_if.c
@@ -155,7 +155,7 @@ static void vp8_enc_free_work_buf(struct venc_vp8_inst 
*inst)
 
/* Buffers need to be freed by AP. */
for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
-   if ((inst->work_bufs[i].size == 0))
+   if (inst->work_bufs[i].size == 0)
continue;
mtk_vcodec_mem_free(inst->ctx, >work_bufs[i]);
}
@@ -172,7 +172,7 @@ static int vp8_enc_alloc_work_buf(struct venc_vp8_inst 
*inst)
mtk_vcodec_debug_enter(inst);
 
for (i = 0; i < VENC_VP8_VPU_WORK_BUF_MAX; i++) {
-   if ((wb[i].size == 0))
+   if (wb[i].size == 0)
continue;
/*
 * This 'wb' structure is set by VPU side and shared to AP for
-- 
2.12.0.367.g23dc2f6d3c-goog