chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

Hi,

I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
even then it encounters lags, soft lockups:
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]

spurious interrupts:
> irq 37: nobody cared (try booting with the "irqpoll" option)
> irq 80: nobody cared (try booting with the "irqpoll" option)
> irq 80: nobody cared (try booting with the "irqpoll" option)
> irq 37: nobody cared (try booting with the "irqpoll" option)

and similar. The irq handling is somehow screwed, as:

>  handlers:
>  [<00000000bfbdfc1a>] irq_default_primary_handler threaded [<00000000de877971>] int3496_thread_isr [extcon_intel_int3496]

But irq_default_primary_handler returns WAKE_THREAD and
int3496_thread_isr returns HANDLED. So something must have triggered a
lot of interrupts before the handler was instantiated.

When I run perf top, I see chv_gpio_irq_ack and chv_gpio_irq_handler at
the very top. Monitoring /proc/interrupts shows, that there are ~33000
interrupts/s from:
>   88:    2134217          0          0          0  chv-gpio    8  home
or
>   89:     221232          0          0          0  chv-gpio    3  INT3496:00

depending on what loads first -- the first is from soc_button_array
module, the second from extcon_intel_int3496.

If I blacklist *both* the modules, the system boots and works fine
(except of, I suppose, the vga connector and some buttons).

I tried this: > --- a/drivers/pinctrl/intel/pinctrl-cherryview.c
> +++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
> @@ -1469,6 +1469,13 @@ static const struct dmi_system_id chv_no_valid_mask[] = {
>                         DMI_MATCH(DMI_PRODUCT_NAME, "Celes"),
>                 },
>         },
> +       {
> +               .ident = "UMAX VisionBook 10Wi Pro",
> +               .matches = {
> +                       DMI_MATCH(DMI_SYS_VENDOR, "UMAX"),
> +                       DMI_MATCH(DMI_PRODUCT_NAME, "VisionBook 10Wi Pro"),
> +               },
> +       },
>         {}
>  };
>  
> @@ -1578,6 +1585,7 @@ static int chv_gpio_probe(struct chv_pinctrl *pctrl, int irq)
>         if (need_valid_mask) {
>                 chip->irq.init_valid_mask = chv_init_irq_valid_mask;
>         } else {
> +               pr_info("%s: XXX quirk\n", __func__);
>                 irq_base = devm_irq_alloc_descs(pctrl->dev, -1, 0,
>                                                 community->npins, NUMA_NO_NODE);
>                 if (irq_base < 0) {

But it doesn't help (despite the message is logged). Any ideas?

Output of /proc/interrupts and with CONFIG_GENERIC_IRQ_DEBUGFS enabled
# head -100 /sys/kernel/debug/irq/domains/* /sys/kernel/debug/irq/irqs/*
is here:
https://paste.opensuse.org/view/raw/32092261

Note 125 is the stormed interrupt there now.

This is with 5.7.7, but 5.3.18 behaves the same. With the latter, the
module blacklisting doesn't help or I screwed up testing.

thanks,
-- 
js
suse labs

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Linus Walleij]

On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:

> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
> even then it encounters lags, soft lockups:
> > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
> > watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
> > watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
> > watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]

Adding Hans de Goede to Cc, he often deals with this kind of weirdness
so he might have some ideas here.

Yours,
Linus Walleij

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi all,

On 7/8/20 9:47 AM, Linus Walleij wrote:
> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> 
>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>> even then it encounters lags, soft lockups:
>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
> 
> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
> so he might have some ideas here.

Thank you for looping me in Linus. I've read up on the rest of the
thread in the archives.

So looking at this:
https://www.umax.cz/umax-visionbook-10wi/

This device appears to be a pretty standard Cherry Trail based 2-in-1
with detachable keyboard. Which usually means (with all the hw-enablement
I've been doing the last 2 years for these) that it will just work.
But no such luck this time it seems.

What I find interesting / weird is that you (Jiri) get an active
(/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
all. That typically only happens when the BIOS thinks you are booting
Android.

Now you may think that Android == Linux so that should be good,
but Intel did a real frankenstein solution for Android X86, see:
https://github.com/intel/ProductionKernelQuilts
for all the 5000 downstream patches in al their glory (hint your
life will be better if you don't take a look).

The much saner support for these devices which eventually got added
to the mainline kernel actually works much better with the "Windows"
profile of the BIOS, since the mainline code expects sane ACPI tables
and the Android targetting ACPI tables are a bit of a mess.

So the first thing to do is to go into the BIOS setup and see if
there is a setting for this (this depends on if the BIOS is
unlocked and has like a gazillion settings, or if it is locked
to only show a few settings).

I just checked on one of own CHT devices and there the option is
under Advanced -> System Component -> OS IMAGE ID

If you have that option (or a similar android/windows toggle
elsewhere) try setting it to Windows and see if that helps.

I would expect the INT3496 device to disappear when you do
this (it will be replaced by an ACPI event handler for the
USB id pin GPIO, so I guess we might change one interrupt
storm for the other).

Also can you put an acpidump of this device up somewhere,
or send me a private email with it ?

Regards,

Hans


p.s.

As for adding your device's DMI id to the chv_no_valid_mask
dmi table not helping. That is somewhat expected, that table
activates a bug to work around an *IRQ* numbering problem
for some older Chromebooks which use direct IRQ resources
in combination with broken IRQ numbering. The chromebooks
adjusted the ACPI tables to deal with a bug in the Linux kernel,
then when we fixed the bug so that things would work with
the gazillion Windows devices out there, we had to add the
quirk to restore the buggy behavior for the chromebooks.

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

[-- Attachment #1: Type: text/plain, Size: 1653 bytes --]

Hi,

On 7/8/20 10:23 AM, Hans de Goede wrote:
> Hi all,
> 
> On 7/8/20 9:47 AM, Linus Walleij wrote:
>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>
>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>> even then it encounters lags, soft lockups:
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>
>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>> so he might have some ideas here.

Thinking more about this, we might need to do something like this
for chv too:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9291c65b01d1c67ebd56644cb19317ad665c44b3

Looking at the datasheet:

https://www.intel.com/content/dam/www/public/us/en/documents/datasheets/atom-z8000-datasheet-vol-2.pdf

Section  10.5.54 / page 4949

The chv GPIO controller has a glitch filter too. This is controlled by
bits 26-27 of the PADCTRL0 register.

So I've gone ahead and written a, compile-tested only, patch
enabling the glitch filter on cht devices, as we are already
doing on byt devices. Can you give this a try and see if it helps?

I've also attached another chv-gpio fix which I posted upstream
a while ago, which resulted in a discussion and an alternative
approach. But I haven't gotten around to implementing the
alternative approach to the fix yet. Note it is unlikely this
helps, but you never know.

Regards,

Hans




[-- Attachment #2: 0001-pinctrl-cherryview-Enable-glitch-filter-for-GPIOs-us.patch --]
[-- Type: text/x-patch, Size: 1913 bytes --]

From 069365867e9c24f865aa7c44474d0cf2b86f03f3 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 8 Jul 2020 10:41:18 +0200
Subject: [PATCH] pinctrl: cherryview: Enable glitch filter for GPIOs used as
 interrupts

On some systems, some PCB traces attached to GpioInts are routed in such
a way that they pick up enough interference to constantly (many times per
second) trigger.

Enabling glitch-filtering fixes this.

Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 571c02218bda..8f7b1ded9b64 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -36,6 +36,12 @@
 #define CHV_PADCTRL0			0x000
 #define CHV_PADCTRL0_INTSEL_SHIFT	28
 #define CHV_PADCTRL0_INTSEL_MASK	GENMASK(31, 28)
+#define CHV_PADCTRL0_GLITCH_FILT_SHIFT	26
+#define CHV_PADCTRL0_GLITCH_FILT_MASK	GENMASK(27, 26)
+#define CHV_PADCTRL0_GLITCH_FILT_OFF	0
+#define CHV_PADCTRL0_GLITCH_FILT_EDGE	1
+#define CHV_PADCTRL0_GLITCH_FILT_DATA	2
+#define CHV_PADCTRL0_GLITCH_FILT_BOTH	3
 #define CHV_PADCTRL0_TERM_UP		BIT(23)
 #define CHV_PADCTRL0_TERM_SHIFT		20
 #define CHV_PADCTRL0_TERM_MASK		GENMASK(22, 20)
@@ -1389,10 +1395,14 @@ static int chv_gpio_irq_type(struct irq_data *d, unsigned int type)
 		chv_writel(value, reg);
 	}
 
+	/* Enable glitch filtering */
 	value = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0));
+	value |= CHV_PADCTRL0_GLITCH_FILT_BOTH << CHV_PADCTRL0_GLITCH_FILT_SHIFT;
+	chv_writel(value, CHV_PADCTRL0);
+
+	/* Store interrupt-line to pin mapping for this pin*/
 	value &= CHV_PADCTRL0_INTSEL_MASK;
 	value >>= CHV_PADCTRL0_INTSEL_SHIFT;
-
 	pctrl->intr_lines[value] = pin;
 
 	if (type & IRQ_TYPE_EDGE_BOTH)
-- 
2.26.2


[-- Attachment #3: 0001-pinctrl-cherryview-Ensure-_REG-ACPI_ADR_SPACE_GPIO-1.patch --]
[-- Type: text/x-patch, Size: 3844 bytes --]

From 742406fcfbaa2311968e74170ab10a20b63eb373 Mon Sep 17 00:00:00 2001
From: Hans de Goede <hdegoede@redhat.com>
Date: Wed, 29 Apr 2020 10:16:33 +0200
Subject: [PATCH] pinctrl: cherryview: Ensure _REG(ACPI_ADR_SPACE_GPIO, 1) gets
 called

On Cherry Trail devices there are 2 possible ACPI OpRegions for
accessing GPIOs. The standard GeneralPurposeIo OpRegion and the Cherry
Trail specific UserDefined 0x9X OpRegions.

Having 2 different types of OpRegions leads to potential issues with
checks for OpRegion availability, or in other words checks if _REG has
been called for the OpRegion which the ACPI code wants to use.

The ACPICA core does not call _REG on an ACPI node which does not
define an OpRegion matching the type being registered; and the reference
design DSDT, from which most Cherry Trail DSDTs are derived, does not
define GeneralPurposeIo, nor UserDefined(0x93) OpRegions for the GPO2
(UID 3) device, because no pins were assigned ACPI controlled functions
in the reference design.

Together this leads to the perfect storm, at least on the Cherry Trail
based Medion Akayo E1239T. This design does use a GPO2 pin from its ACPI
code and has added the Cherry Trail specific UserDefined(0x93) opregion
to its GPO2 ACPI node to access this pin.

But it uses a has _REG been called availability check for the standard
GeneralPurposeIo OpRegion. This clearly is a bug in the DSDT, but this
does work under Windows. This issue leads to the intel_vbtn driver
reporting the device always being in tablet-mode at boot, even if it
is in laptop mode. Which in turn causes userspace to ignore touchpad
events. So iow this issues causes the touchpad to not work at boot.

Since the bug in the DSDT stems from the confusion of having 2 different
OpRegion types for accessing GPIOs on Cherry Trail devices, I believe
that this is best fixed inside the Cherryview pinctrl driver.

This commit adds a workaround to the Cherryview pinctrl driver so
that the DSDT's expectations of _REG always getting called for the
GeneralPurposeIo OpRegion are met.

Cc: stable@vger.kernel.org
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
- Drop unnecessary if (acpi_has_method(adev->handle, "_REG")) check
- Fix Cherryview spelling in the commit message
---
 drivers/pinctrl/intel/pinctrl-cherryview.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/drivers/pinctrl/intel/pinctrl-cherryview.c b/drivers/pinctrl/intel/pinctrl-cherryview.c
index 8e3953a223d0..a0aceaf52c6a 100644
--- a/drivers/pinctrl/intel/pinctrl-cherryview.c
+++ b/drivers/pinctrl/intel/pinctrl-cherryview.c
@@ -1629,6 +1629,8 @@ static acpi_status chv_pinctrl_mmio_access_handler(u32 function,
 
 static int chv_pinctrl_probe(struct platform_device *pdev)
 {
+	struct acpi_object_list input;
+	union acpi_object params[2];
 	struct chv_pinctrl *pctrl;
 	struct acpi_device *adev;
 	acpi_status status;
@@ -1691,6 +1693,22 @@ static int chv_pinctrl_probe(struct platform_device *pdev)
 	if (ACPI_FAILURE(status))
 		dev_err(&pdev->dev, "failed to install ACPI addr space handler\n");
 
+	/*
+	 * Some DSDT-s use the chv_pinctrl_mmio_access_handler while checking
+	 * for the regular GeneralPurposeIo OpRegion availability, mixed with
+	 * the DSDT not defining a GeneralPurposeIo OpRegion at all. In this
+	 * case the ACPICA code will not call _REG to signal availability of
+	 * the GeneralPurposeIo OpRegion. Manually call _REG here so that
+	 * the DSDT-s GeneralPurposeIo availability checks will succeed.
+	 */
+	params[0].type = ACPI_TYPE_INTEGER;
+	params[0].integer.value = ACPI_ADR_SPACE_GPIO;
+	params[1].type = ACPI_TYPE_INTEGER;
+	params[1].integer.value = 1;
+	input.count = 2;
+	input.pointer = params;
+	acpi_evaluate_object(adev->handle, "_REG", &input, NULL);
+
 	platform_set_drvdata(pdev, pctrl);
 
 	return 0;
-- 
2.26.2

Re: [PATCH] pinctrl: cherryview: Enable glitch filter for GPIOs used as

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 3908 bytes --]

Hi Hans,

I love your patch! Perhaps something to improve:

[auto build test WARNING on pinctrl/devel]
[also build test WARNING on v5.8-rc4]
[cannot apply to next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/pinctrl-cherryview-Enable-glitch-filter-for-GPIOs-used-as/20200708-164742
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: x86_64-randconfig-s022-20200709 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.2-37-gc9676a3b-dirty
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)

>> drivers/pinctrl/intel/pinctrl-cherryview.c:1401:27: sparse: sparse: Using plain integer as NULL pointer

vim +1401 drivers/pinctrl/intel/pinctrl-cherryview.c

  1351	
  1352	static int chv_gpio_irq_type(struct irq_data *d, unsigned int type)
  1353	{
  1354		struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
  1355		struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
  1356		unsigned int pin = irqd_to_hwirq(d);
  1357		unsigned long flags;
  1358		u32 value;
  1359	
  1360		raw_spin_lock_irqsave(&chv_lock, flags);
  1361	
  1362		/*
  1363		 * Pins which can be used as shared interrupt are configured in
  1364		 * BIOS. Driver trusts BIOS configurations and assigns different
  1365		 * handler according to the irq type.
  1366		 *
  1367		 * Driver needs to save the mapping between each pin and
  1368		 * its interrupt line.
  1369		 * 1. If the pin cfg is locked in BIOS:
  1370		 *	Trust BIOS has programmed IntWakeCfg bits correctly,
  1371		 *	driver just needs to save the mapping.
  1372		 * 2. If the pin cfg is not locked in BIOS:
  1373		 *	Driver programs the IntWakeCfg bits and save the mapping.
  1374		 */
  1375		if (!chv_pad_locked(pctrl, pin)) {
  1376			void __iomem *reg = chv_padreg(pctrl, pin, CHV_PADCTRL1);
  1377	
  1378			value = readl(reg);
  1379			value &= ~CHV_PADCTRL1_INTWAKECFG_MASK;
  1380			value &= ~CHV_PADCTRL1_INVRXTX_MASK;
  1381	
  1382			if (type & IRQ_TYPE_EDGE_BOTH) {
  1383				if ((type & IRQ_TYPE_EDGE_BOTH) == IRQ_TYPE_EDGE_BOTH)
  1384					value |= CHV_PADCTRL1_INTWAKECFG_BOTH;
  1385				else if (type & IRQ_TYPE_EDGE_RISING)
  1386					value |= CHV_PADCTRL1_INTWAKECFG_RISING;
  1387				else if (type & IRQ_TYPE_EDGE_FALLING)
  1388					value |= CHV_PADCTRL1_INTWAKECFG_FALLING;
  1389			} else if (type & IRQ_TYPE_LEVEL_MASK) {
  1390				value |= CHV_PADCTRL1_INTWAKECFG_LEVEL;
  1391				if (type & IRQ_TYPE_LEVEL_LOW)
  1392					value |= CHV_PADCTRL1_INVRXTX_RXDATA;
  1393			}
  1394	
  1395			chv_writel(value, reg);
  1396		}
  1397	
  1398		/* Enable glitch filtering */
  1399		value = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0));
  1400		value |= CHV_PADCTRL0_GLITCH_FILT_BOTH << CHV_PADCTRL0_GLITCH_FILT_SHIFT;
> 1401		chv_writel(value, CHV_PADCTRL0);
  1402	
  1403		/* Store interrupt-line to pin mapping for this pin*/
  1404		value &= CHV_PADCTRL0_INTSEL_MASK;
  1405		value >>= CHV_PADCTRL0_INTSEL_SHIFT;
  1406		pctrl->intr_lines[value] = pin;
  1407	
  1408		if (type & IRQ_TYPE_EDGE_BOTH)
  1409			irq_set_handler_locked(d, handle_edge_irq);
  1410		else if (type & IRQ_TYPE_LEVEL_MASK)
  1411			irq_set_handler_locked(d, handle_level_irq);
  1412	
  1413		raw_spin_unlock_irqrestore(&chv_lock, flags);
  1414	
  1415		return 0;
  1416	}
  1417	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all@lists.01.org

[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 27184 bytes --]

Re: [PATCH] pinctrl: cherryview: Enable glitch filter for GPIOs used as

[kernel test robot]

[-- Attachment #1: Type: text/plain, Size: 4012 bytes --]

Hi Hans,

I love your patch! Perhaps something to improve:

[auto build test WARNING on pinctrl/devel]
[also build test WARNING on v5.8-rc4]
[cannot apply to next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:    https://github.com/0day-ci/linux/commits/Hans-de-Goede/pinctrl-cherryview-Enable-glitch-filter-for-GPIOs-used-as/20200708-164742
base:   https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-pinctrl.git devel
config: x86_64-randconfig-s022-20200709 (attached as .config)
compiler: gcc-9 (Debian 9.3.0-14) 9.3.0
reproduce:
        # apt-get install sparse
        # sparse version: v0.6.2-37-gc9676a3b-dirty
        # save the attached .config to linux build tree
        make W=1 C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__' ARCH=x86_64 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot <lkp@intel.com>


sparse warnings: (new ones prefixed by >>)

>> drivers/pinctrl/intel/pinctrl-cherryview.c:1401:27: sparse: sparse: Using plain integer as NULL pointer

vim +1401 drivers/pinctrl/intel/pinctrl-cherryview.c

  1351	
  1352	static int chv_gpio_irq_type(struct irq_data *d, unsigned int type)
  1353	{
  1354		struct gpio_chip *gc = irq_data_get_irq_chip_data(d);
  1355		struct chv_pinctrl *pctrl = gpiochip_get_data(gc);
  1356		unsigned int pin = irqd_to_hwirq(d);
  1357		unsigned long flags;
  1358		u32 value;
  1359	
  1360		raw_spin_lock_irqsave(&chv_lock, flags);
  1361	
  1362		/*
  1363		 * Pins which can be used as shared interrupt are configured in
  1364		 * BIOS. Driver trusts BIOS configurations and assigns different
  1365		 * handler according to the irq type.
  1366		 *
  1367		 * Driver needs to save the mapping between each pin and
  1368		 * its interrupt line.
  1369		 * 1. If the pin cfg is locked in BIOS:
  1370		 *	Trust BIOS has programmed IntWakeCfg bits correctly,
  1371		 *	driver just needs to save the mapping.
  1372		 * 2. If the pin cfg is not locked in BIOS:
  1373		 *	Driver programs the IntWakeCfg bits and save the mapping.
  1374		 */
  1375		if (!chv_pad_locked(pctrl, pin)) {
  1376			void __iomem *reg = chv_padreg(pctrl, pin, CHV_PADCTRL1);
  1377	
  1378			value = readl(reg);
  1379			value &= ~CHV_PADCTRL1_INTWAKECFG_MASK;
  1380			value &= ~CHV_PADCTRL1_INVRXTX_MASK;
  1381	
  1382			if (type & IRQ_TYPE_EDGE_BOTH) {
  1383				if ((type & IRQ_TYPE_EDGE_BOTH) == IRQ_TYPE_EDGE_BOTH)
  1384					value |= CHV_PADCTRL1_INTWAKECFG_BOTH;
  1385				else if (type & IRQ_TYPE_EDGE_RISING)
  1386					value |= CHV_PADCTRL1_INTWAKECFG_RISING;
  1387				else if (type & IRQ_TYPE_EDGE_FALLING)
  1388					value |= CHV_PADCTRL1_INTWAKECFG_FALLING;
  1389			} else if (type & IRQ_TYPE_LEVEL_MASK) {
  1390				value |= CHV_PADCTRL1_INTWAKECFG_LEVEL;
  1391				if (type & IRQ_TYPE_LEVEL_LOW)
  1392					value |= CHV_PADCTRL1_INVRXTX_RXDATA;
  1393			}
  1394	
  1395			chv_writel(value, reg);
  1396		}
  1397	
  1398		/* Enable glitch filtering */
  1399		value = readl(chv_padreg(pctrl, pin, CHV_PADCTRL0));
  1400		value |= CHV_PADCTRL0_GLITCH_FILT_BOTH << CHV_PADCTRL0_GLITCH_FILT_SHIFT;
> 1401		chv_writel(value, CHV_PADCTRL0);
  1402	
  1403		/* Store interrupt-line to pin mapping for this pin*/
  1404		value &= CHV_PADCTRL0_INTSEL_MASK;
  1405		value >>= CHV_PADCTRL0_INTSEL_SHIFT;
  1406		pctrl->intr_lines[value] = pin;
  1407	
  1408		if (type & IRQ_TYPE_EDGE_BOTH)
  1409			irq_set_handler_locked(d, handle_edge_irq);
  1410		else if (type & IRQ_TYPE_LEVEL_MASK)
  1411			irq_set_handler_locked(d, handle_level_irq);
  1412	
  1413		raw_spin_unlock_irqrestore(&chv_lock, flags);
  1414	
  1415		return 0;
  1416	}
  1417	

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 27184 bytes --]

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

On 08. 07. 20, 10:23, Hans de Goede wrote:
> Hi all,
> 
> On 7/8/20 9:47 AM, Linus Walleij wrote:
>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>
>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>> even then it encounters lags, soft lockups:
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>
>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>> so he might have some ideas here.
> 
> Thank you for looping me in Linus. I've read up on the rest of the
> thread in the archives.
> 
> So looking at this:
> https://www.umax.cz/umax-visionbook-10wi/
> 
> This device appears to be a pretty standard Cherry Trail based 2-in-1
> with detachable keyboard. Which usually means (with all the hw-enablement
> I've been doing the last 2 years for these) that it will just work.
> But no such luck this time it seems.

Hi,

It seems to be Baytrail.

> What I find interesting / weird is that you (Jiri) get an active
> (/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
> all. That typically only happens when the BIOS thinks you are booting
> Android.

15 that is.

> Now you may think that Android == Linux so that should be good,
> but Intel did a real frankenstein solution for Android X86, see:
> https://github.com/intel/ProductionKernelQuilts
> for all the 5000 downstream patches in al their glory (hint your
> life will be better if you don't take a look).
> 
> The much saner support for these devices which eventually got added
> to the mainline kernel actually works much better with the "Windows"
> profile of the BIOS, since the mainline code expects sane ACPI tables
> and the Android targetting ACPI tables are a bit of a mess.
> 
> So the first thing to do is to go into the BIOS setup and see if
> there is a setting for this (this depends on if the BIOS is
> unlocked and has like a gazillion settings, or if it is locked
> to only show a few settings).
> 
> I just checked on one of own CHT devices and there the option is
> under Advanced -> System Component -> OS IMAGE ID

I had/have:
Advanced
  -> Droid boot = disabled
  -> Android boot = disabled
  -> OS selection = Windows 8.x (there is also GMIN and Android to select)

So there seems nothing I should change?

> I would expect the INT3496 device to disappear when you do
> this (it will be replaced by an ACPI event handler for the
> USB id pin GPIO, so I guess we might change one interrupt
> storm for the other).
> 
> Also can you put an acpidump of this device up somewhere,
> or send me a private email with it ?

Sure:
https://paste.opensuse.org/view/raw/79423338

> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> As for adding your device's DMI id to the chv_no_valid_mask
> dmi table not helping. That is somewhat expected, that table
> activates a bug to work around an *IRQ* numbering problem
> for some older Chromebooks which use direct IRQ resources
> in combination with broken IRQ numbering. The chromebooks
> adjusted the ACPI tables to deal with a bug in the Linux kernel,
> then when we fixed the bug so that things would work with
> the gazillion Windows devices out there, we had to add the
> quirk to restore the buggy behavior for the chromebooks.

The bugs also suggest that this avoids storms thanks to different
handling in chv_gpio_irq_init_hw (if (!pctrl->chip.irq.init_valid_mask)
there).

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/8/20 10:52 AM, Jiri Slaby wrote:
> On 08. 07. 20, 10:23, Hans de Goede wrote:
>> Hi all,
>>
>> On 7/8/20 9:47 AM, Linus Walleij wrote:
>>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>>
>>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>>> even then it encounters lags, soft lockups:
>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>
>>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>>> so he might have some ideas here.
>>
>> Thank you for looping me in Linus. I've read up on the rest of the
>> thread in the archives.
>>
>> So looking at this:
>> https://www.umax.cz/umax-visionbook-10wi/
>>
>> This device appears to be a pretty standard Cherry Trail based 2-in-1
>> with detachable keyboard. Which usually means (with all the hw-enablement
>> I've been doing the last 2 years for these) that it will just work.
>> But no such luck this time it seems.
> 
> Hi,
> 
> It seems to be Baytrail.

Ah, ok I did not check, I went by the chv-gpio in the subject.

>> What I find interesting / weird is that you (Jiri) get an active
>> (/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
>> all. That typically only happens when the BIOS thinks you are booting
>> Android.
> 
> 15 that is.

Right, that is normal for an enabled device the ACPI method
implementing the status attribute for your tablet looks like this:

             Method (_STA, 0, NotSerialized)  // _STA: Status
             {
                 If (((BDID == One) && (OSID != One)))
                 {
                     Return (0x0F)
                 }

                 Return (Zero)
             }

So now we know that BDID == One and OSID != One, OSID == One
typically is Windows...

Looking at the buttons next, can you do:

cat /sys/bus/acpi/devices/ACPI0011:00/status

and:

cat /sys/bus/acpi/devices/INTCFD9:00/status

If the BIOS thinks you are booting normal Windows the first
one should output 15  (0xf) aka present and the second one
should output 0, but I suspect it is the other way around...

So looking at the GPIO resource definitions for BDID == One
for the ACPI0011 device we have:

                 Name (PBUF, ResourceTemplate ()
                 {
                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp, 0x0BB8,
                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x0008
                         }
                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault, 0x0BB8,
                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x004E
                         }
                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault, 0x0BB8,
                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x0050
                         }
                 })

With a mapping of first resource to KEY_POWER, second resource to
KEY_VOLUMEUP and third resource to KEY_VOLUMEDOWN

The INTCFD9 device OTOH has the following resource definitions for BDID == One

                 Name (PBUF, ResourceTemplate ()
                 {
                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp, 0x0BB8,
                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x0008
                         }
                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullDefault, 0x
                         "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x0008
                         }
                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault, 0x0BB8,
                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x004E
                         }
                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault, 0x0BB8,
                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
                         )
                         {   // Pin list
                             0x0050
                         }
                 })

With a mapping of resource1: power, resource2: home, resource3: volume_up,
resource4: volume_down.

So what we see here is that the "Android" style INTCFD9 device has
an extra entry for the home-button and I guess (hard to see on the
pictures) that there is no physical home-button.

Since the IRQ storm you are seeing on the home button is happening on
GPO1 pin 8 which is only listed as a button on the "Android" style
INTCFD9 device. I guess that the manufacturer started with a standard
ACPI DSDT for these devices and then hacked up the Windows entries until
they work.

Likewise the INT3496 entry likely is non-sense too. So you are seeing
a storm from some floating GPIOs which are close enough to some
other signals to pick up interference from them.

Conclusion: we need to get your BIOS to stop setting OSID to 0
(Android) and get it to set it to 1 (Windows).

>> Now you may think that Android == Linux so that should be good,
>> but Intel did a real frankenstein solution for Android X86, see:
>> https://github.com/intel/ProductionKernelQuilts
>> for all the 5000 downstream patches in al their glory (hint your
>> life will be better if you don't take a look).
>>
>> The much saner support for these devices which eventually got added
>> to the mainline kernel actually works much better with the "Windows"
>> profile of the BIOS, since the mainline code expects sane ACPI tables
>> and the Android targetting ACPI tables are a bit of a mess.
>>
>> So the first thing to do is to go into the BIOS setup and see if
>> there is a setting for this (this depends on if the BIOS is
>> unlocked and has like a gazillion settings, or if it is locked
>> to only show a few settings).
>>
>> I just checked on one of own CHT devices and there the option is
>> under Advanced -> System Component -> OS IMAGE ID
> 
> I had/have:
> Advanced
>    -> Droid boot = disabled
>    -> Android boot = disabled
>    -> OS selection = Windows 8.x (there is also GMIN and Android to select)
> 
> So there seems nothing I should change?

Ok, so some of these devices have some multi-boot code inside for
dualbooting both Android and Windows and they automatically override
the "OS selection" on every boot.

Since your device has only 1G of RAM it likely shipped with a 32
bit Windows to save RAM and thus has either a 32 bit only UEFI,
or a dual-mode UEFI. I'm guessing that it is the latter and when
you inserted the boot-medium you used to install, the BIOS saw a
EFI/BOOT/bootx64.efi binary on the boot-medium and switches to
64 bit mode which it associates with Android.

If you run:
efibootmgr -v

You will likely see your current active boot entry point to
something with x64 in the name, e.g. I have:

Boot0000* Fedora        HD(1,GPT,a662134d-b40c-48de-8811-e43fee1adfa3,0x800,0x82000)/File(\EFI\fedora\shimx64.efi)

I guess you run Suse on there? Assuming the setup is similar
as we use on Fedora you should also have both of these files:

/boot/efi/EFI/Boot/bootx64.efi
/boot/efi/EFI/Boot/bootia32.efi

(note the caps may differ, because of vfat)

These are fallback boot files which the BIOS will use when
there are no valid boot entries.

If you are missing the bootia32 variant you should be able
to install it, e.g. I have:

[root@x1 ~]# rpm -qf /boot/efi/EFI/BOOT/BOOTX64.EFI
shim-x64-15-8.x86_64

So I can add the ia32 variant by doing:

dnf install shim-ia32

Once you have the bootia32.efi (and grub 32 bit too!)
you should be able to get the BIOS to switch to 32 bit
UEFI aka Windows mode by removing the
/boot/efi/EFI/BOOT/BOOTX64.EFI file
(I would just mv it to .bak for now)

And also removing all boot entries in
efibootmgr pointing to x64 efi binaries (or just remove
them all).

Then the BIOS should do a fallback boot, see there is
no bootx64.efi and switch to 32 bit mode.

I say should, you probably want to have a livecd or
some such at hand to rescue the system if I'm wrong
and it only supports 64 bit EFI.

Note that your 64 bit kernel will be fine with running on
top of the 32 bit UEFI, it will thunk any firmware calls to
32 bits as necessary.

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

Hi,

On 08. 07. 20, 12:15, Hans de Goede wrote:
> Hi,
> 
> On 7/8/20 10:52 AM, Jiri Slaby wrote:
>> On 08. 07. 20, 10:23, Hans de Goede wrote:
>>> Hi all,
>>>
>>> On 7/8/20 9:47 AM, Linus Walleij wrote:
>>>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>>>
>>>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>>>> even then it encounters lags, soft lockups:
>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>
>>>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>>>> so he might have some ideas here.
>>>
>>> Thank you for looping me in Linus. I've read up on the rest of the
>>> thread in the archives.
>>>
>>> So looking at this:
>>> https://www.umax.cz/umax-visionbook-10wi/
>>>
>>> This device appears to be a pretty standard Cherry Trail based 2-in-1
>>> with detachable keyboard. Which usually means (with all the
>>> hw-enablement
>>> I've been doing the last 2 years for these) that it will just work.
>>> But no such luck this time it seems.
...
>>> What I find interesting / weird is that you (Jiri) get an active
>>> (/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
>>> all. That typically only happens when the BIOS thinks you are booting
>>> Android.
>>
>> 15 that is.
> 
> Right, that is normal for an enabled device the ACPI method
> implementing the status attribute for your tablet looks like this:
> 
>             Method (_STA, 0, NotSerialized)  // _STA: Status
>             {
>                 If (((BDID == One) && (OSID != One)))
>                 {
>                     Return (0x0F)
>                 }
> 
>                 Return (Zero)
>             }
> 
> So now we know that BDID == One and OSID != One, OSID == One
> typically is Windows...
> 
> Looking at the buttons next, can you do:
> 
> cat /sys/bus/acpi/devices/ACPI0011:00/status

Gives 0

> and:
> 
> cat /sys/bus/acpi/devices/INTCFD9:00/status

Gives 15

> 
> If the BIOS thinks you are booting normal Windows the first
> one should output 15  (0xf) aka present and the second one
> should output 0, but I suspect it is the other way around...

Right.

> So looking at the GPIO resource definitions for BDID == One
> for the ACPI0011 device we have:
> 
>                 Name (PBUF, ResourceTemplate ()
>                 {
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
> 0x0BB8,
>                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x004E
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0050
>                         }
>                 })
> 
> With a mapping of first resource to KEY_POWER, second resource to
> KEY_VOLUMEUP and third resource to KEY_VOLUMEDOWN
> 
> The INTCFD9 device OTOH has the following resource definitions for BDID
> == One
> 
>                 Name (PBUF, ResourceTemplate ()
>                 {
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
> 0x0BB8,
>                         "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, ExclusiveAndWake,
> PullDefault, 0x
>                         "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0008
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x004E
>                         }
>                     GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
> 0x0BB8,
>                         "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>                         )
>                         {   // Pin list
>                             0x0050
>                         }
>                 })
> 
> With a mapping of resource1: power, resource2: home, resource3: volume_up,
> resource4: volume_down.
> 
> So what we see here is that the "Android" style INTCFD9 device has
> an extra entry for the home-button and I guess (hard to see on the
> pictures) that there is no physical home-button.

I don't know what it should look like, but there is no button with
house-like painting. There is only a standard "Home" button -- Fn+PgUp.
And that works even without that module.

> Since the IRQ storm you are seeing on the home button is happening on
> GPO1 pin 8 which is only listed as a button on the "Android" style
> INTCFD9 device. I guess that the manufacturer started with a standard
> ACPI DSDT for these devices and then hacked up the Windows entries until
> they work.
> 
> Likewise the INT3496 entry likely is non-sense too. So you are seeing
> a storm from some floating GPIOs which are close enough to some
> other signals to pick up interference from them.
> 
> Conclusion: we need to get your BIOS to stop setting OSID to 0
> (Android) and get it to set it to 1 (Windows).
> 
>>> Now you may think that Android == Linux so that should be good,
>>> but Intel did a real frankenstein solution for Android X86, see:
>>> https://github.com/intel/ProductionKernelQuilts
>>> for all the 5000 downstream patches in al their glory (hint your
>>> life will be better if you don't take a look).
>>>
>>> The much saner support for these devices which eventually got added
>>> to the mainline kernel actually works much better with the "Windows"
>>> profile of the BIOS, since the mainline code expects sane ACPI tables
>>> and the Android targetting ACPI tables are a bit of a mess.
>>>
>>> So the first thing to do is to go into the BIOS setup and see if
>>> there is a setting for this (this depends on if the BIOS is
>>> unlocked and has like a gazillion settings, or if it is locked
>>> to only show a few settings).
>>>
>>> I just checked on one of own CHT devices and there the option is
>>> under Advanced -> System Component -> OS IMAGE ID
>>
>> I had/have:
>> Advanced
>>    -> Droid boot = disabled
>>    -> Android boot = disabled
>>    -> OS selection = Windows 8.x (there is also GMIN and Android to
>> select)
>>
>> So there seems nothing I should change?
> 
> Ok, so some of these devices have some multi-boot code inside for
> dualbooting both Android and Windows and they automatically override
> the "OS selection" on every boot.
> 
> Since your device has only 1G of RAM it likely shipped with a 32
> bit Windows to save RAM and thus has either a 32 bit only UEFI,
> or a dual-mode UEFI. I'm guessing that it is the latter and when
> you inserted the boot-medium you used to install, the BIOS saw a
> EFI/BOOT/bootx64.efi binary on the boot-medium and switches to
> 64 bit mode which it associates with Android.

No, it has 2G of RAM.
# free -h
              total        used        free      shared  buff/cache
available
Mem:          1,8Gi       497Mi       786Mi       108Mi       567Mi
  1,1Gi
Swap:         2,0Gi          0B       2,0Gi

It also has only 32 but EFI. It doesn't recognize 64-bit binaries. I had
to load 32-bit grub first to load the installer from a USB. So this is
EFI-mixed mode as it is called.

> If you run:
> efibootmgr -v
> 
> You will likely see your current active boot entry point to
> something with x64 in the name, e.g. I have:
> 
> Boot0000* Fedora       
> HD(1,GPT,a662134d-b40c-48de-8811-e43fee1adfa3,0x800,0x82000)/File(\EFI\fedora\shimx64.efi)

As I wrote above:
Boot0001* opensuse
HD(1,GPT,3f7cc368-0736-45a3-b23e-e1c0eda840be,0x800,0xfa000)/File(\EFI\opensuse\grub32.efi)

I've tried your patches now, but it crashes the kernel due to omitted
chv_padreg(), so rebuilding with that fixed...

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/8/20 1:02 PM, Jiri Slaby wrote:
> Hi,
> 
> On 08. 07. 20, 12:15, Hans de Goede wrote:
>> Hi,
>>
>> On 7/8/20 10:52 AM, Jiri Slaby wrote:
>>> On 08. 07. 20, 10:23, Hans de Goede wrote:
>>>> Hi all,
>>>>
>>>> On 7/8/20 9:47 AM, Linus Walleij wrote:
>>>>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>>>>
>>>>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>>>>> even then it encounters lags, soft lockups:
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>>
>>>>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>>>>> so he might have some ideas here.
>>>>
>>>> Thank you for looping me in Linus. I've read up on the rest of the
>>>> thread in the archives.
>>>>
>>>> So looking at this:
>>>> https://www.umax.cz/umax-visionbook-10wi/
>>>>
>>>> This device appears to be a pretty standard Cherry Trail based 2-in-1
>>>> with detachable keyboard. Which usually means (with all the
>>>> hw-enablement
>>>> I've been doing the last 2 years for these) that it will just work.
>>>> But no such luck this time it seems.
> ...
>>>> What I find interesting / weird is that you (Jiri) get an active
>>>> (/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
>>>> all. That typically only happens when the BIOS thinks you are booting
>>>> Android.
>>>
>>> 15 that is.
>>
>> Right, that is normal for an enabled device the ACPI method
>> implementing the status attribute for your tablet looks like this:
>>
>>              Method (_STA, 0, NotSerialized)  // _STA: Status
>>              {
>>                  If (((BDID == One) && (OSID != One)))
>>                  {
>>                      Return (0x0F)
>>                  }
>>
>>                  Return (Zero)
>>              }
>>
>> So now we know that BDID == One and OSID != One, OSID == One
>> typically is Windows...
>>
>> Looking at the buttons next, can you do:
>>
>> cat /sys/bus/acpi/devices/ACPI0011:00/status
> 
> Gives 0
> 
>> and:
>>
>> cat /sys/bus/acpi/devices/INTCFD9:00/status
> 
> Gives 15
> 
>>
>> If the BIOS thinks you are booting normal Windows the first
>> one should output 15  (0xf) aka present and the second one
>> should output 0, but I suspect it is the other way around...
> 
> Right.
> 
>> So looking at the GPIO resource definitions for BDID == One
>> for the ACPI0011 device we have:
>>
>>                  Name (PBUF, ResourceTemplate ()
>>                  {
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
>> 0x0BB8,
>>                          "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x004E
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0050
>>                          }
>>                  })
>>
>> With a mapping of first resource to KEY_POWER, second resource to
>> KEY_VOLUMEUP and third resource to KEY_VOLUMEDOWN
>>
>> The INTCFD9 device OTOH has the following resource definitions for BDID
>> == One
>>
>>                  Name (PBUF, ResourceTemplate ()
>>                  {
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
>> 0x0BB8,
>>                          "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake,
>> PullDefault, 0x
>>                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x004E
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0050
>>                          }
>>                  })
>>
>> With a mapping of resource1: power, resource2: home, resource3: volume_up,
>> resource4: volume_down.
>>
>> So what we see here is that the "Android" style INTCFD9 device has
>> an extra entry for the home-button and I guess (hard to see on the
>> pictures) that there is no physical home-button.
> 
> I don't know what it should look like, but there is no button with
> house-like painting. There is only a standard "Home" button -- Fn+PgUp.
> And that works even without that module.
> 
>> Since the IRQ storm you are seeing on the home button is happening on
>> GPO1 pin 8 which is only listed as a button on the "Android" style
>> INTCFD9 device. I guess that the manufacturer started with a standard
>> ACPI DSDT for these devices and then hacked up the Windows entries until
>> they work.
>>
>> Likewise the INT3496 entry likely is non-sense too. So you are seeing
>> a storm from some floating GPIOs which are close enough to some
>> other signals to pick up interference from them.
>>
>> Conclusion: we need to get your BIOS to stop setting OSID to 0
>> (Android) and get it to set it to 1 (Windows).
>>
>>>> Now you may think that Android == Linux so that should be good,
>>>> but Intel did a real frankenstein solution for Android X86, see:
>>>> https://github.com/intel/ProductionKernelQuilts
>>>> for all the 5000 downstream patches in al their glory (hint your
>>>> life will be better if you don't take a look).
>>>>
>>>> The much saner support for these devices which eventually got added
>>>> to the mainline kernel actually works much better with the "Windows"
>>>> profile of the BIOS, since the mainline code expects sane ACPI tables
>>>> and the Android targetting ACPI tables are a bit of a mess.
>>>>
>>>> So the first thing to do is to go into the BIOS setup and see if
>>>> there is a setting for this (this depends on if the BIOS is
>>>> unlocked and has like a gazillion settings, or if it is locked
>>>> to only show a few settings).
>>>>
>>>> I just checked on one of own CHT devices and there the option is
>>>> under Advanced -> System Component -> OS IMAGE ID
>>>
>>> I had/have:
>>> Advanced
>>>     -> Droid boot = disabled
>>>     -> Android boot = disabled
>>>     -> OS selection = Windows 8.x (there is also GMIN and Android to
>>> select)
>>>
>>> So there seems nothing I should change?
>>
>> Ok, so some of these devices have some multi-boot code inside for
>> dualbooting both Android and Windows and they automatically override
>> the "OS selection" on every boot.
>>
>> Since your device has only 1G of RAM it likely shipped with a 32
>> bit Windows to save RAM and thus has either a 32 bit only UEFI,
>> or a dual-mode UEFI. I'm guessing that it is the latter and when
>> you inserted the boot-medium you used to install, the BIOS saw a
>> EFI/BOOT/bootx64.efi binary on the boot-medium and switches to
>> 64 bit mode which it associates with Android.
> 
> No, it has 2G of RAM.
> # free -h
>                total        used        free      shared  buff/cache
> available
> Mem:          1,8Gi       497Mi       786Mi       108Mi       567Mi
>    1,1Gi
> Swap:         2,0Gi          0B       2,0Gi
> 
> It also has only 32 but EFI. It doesn't recognize 64-bit binaries. I had
> to load 32-bit grub first to load the installer from a USB. So this is
> EFI-mixed mode as it is called.

Hmm, ok, with CHT I would really expect there to be a 64 bit UEFI and
your DSDT and the fact that my untested patch broke your boot, all do
show that this is Cherry Trail / Cherryview and not a Bay Trail.

I guess that doing:

cat /proc/cpuinfo  | grep "model name"

Will output something like this:

model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz

Note the model bould be some other Z8xxx nummer, likely it is a
Z8350, and if not a Z8300 but any Z8xxx number is CHT.

Further confirming that this really is Cherry Trail. Which
at least means that my patches might help a bit.

But ideally we would still be able to get the BIOS to see
us as Windows and set its OSID variable to 1. So we don't
try to use the wrong GPIOs as IRQ at all. Can you try loading
the BIOS setup-defaults / optimal defaults?

If that does not get rid of the IN3496 device (changes its
status to 0), then try this:

Maybe you have a "Boot Architecture" option under the "Boot"
menu in the BIOS? I know you are already at 32 bits, but
maybe changing it to 64 bits helps? (after installing a 64 bit
shim + grub)

>> If you run:
>> efibootmgr -v
>>
>> You will likely see your current active boot entry point to
>> something with x64 in the name, e.g. I have:
>>
>> Boot0000* Fedora
>> HD(1,GPT,a662134d-b40c-48de-8811-e43fee1adfa3,0x800,0x82000)/File(\EFI\fedora\shimx64.efi)
> 
> As I wrote above:
> Boot0001* opensuse
> HD(1,GPT,3f7cc368-0736-45a3-b23e-e1c0eda840be,0x800,0xfa000)/File(\EFI\opensuse\grub32.efi)
> 
> I've tried your patches now, but it crashes the kernel due to omitted
> chv_padreg(), so rebuilding with that fixed...

Oops, yeah I just noticed that too (while testing some other
kernel patches). I've this fixed locally now...

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

Hi,

On 08. 07. 20, 13:24, Hans de Goede wrote:
>> It also has only 32 but EFI. It doesn't recognize 64-bit binaries. I had
>> to load 32-bit grub first to load the installer from a USB. So this is
>> EFI-mixed mode as it is called.
> 
> Hmm, ok, with CHT I would really expect there to be a 64 bit UEFI and
> your DSDT and the fact that my untested patch broke your boot, all do
> show that this is Cherry Trail / Cherryview and not a Bay Trail.
> 
> I guess that doing:
> 
> cat /proc/cpuinfo  | grep "model name"
> 
> Will output something like this:
> 
> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
> 
> Note the model bould be some other Z8xxx nummer, likely it is a
> Z8350, and if not a Z8300 but any Z8xxx number is CHT.

Yes, correct:
model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz

> Further confirming that this really is Cherry Trail. Which
> at least means that my patches might help a bit.

They do not :(. The interrupts are still storming.

FWIW I tried the acpi_osi="Windows 2015" kernel parameter. No success too.

> But ideally we would still be able to get the BIOS to see
> us as Windows and set its OSID variable to 1. So we don't
> try to use the wrong GPIOs as IRQ at all. Can you try loading
> the BIOS setup-defaults / optimal defaults?

Loaded the optimal values. Still the same

> If that does not get rid of the IN3496 device (changes its
> status to 0), then try this:
> 
> Maybe you have a "Boot Architecture" option under the "Boot"
> menu in the BIOS? I know you are already at 32 bits, but
> maybe changing it to 64 bits helps? (after installing a 64 bit
> shim + grub)

Unfortunately, there is nothing like that. It's discussed on the net,
that these UMAXes have only 32bit EFI.

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/8/20 1:36 PM, Jiri Slaby wrote:
> Hi,
> 
> On 08. 07. 20, 13:24, Hans de Goede wrote:
>>> It also has only 32 but EFI. It doesn't recognize 64-bit binaries. I had
>>> to load 32-bit grub first to load the installer from a USB. So this is
>>> EFI-mixed mode as it is called.
>>
>> Hmm, ok, with CHT I would really expect there to be a 64 bit UEFI and
>> your DSDT and the fact that my untested patch broke your boot, all do
>> show that this is Cherry Trail / Cherryview and not a Bay Trail.
>>
>> I guess that doing:
>>
>> cat /proc/cpuinfo  | grep "model name"
>>
>> Will output something like this:
>>
>> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
>> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
>> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
>> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
>>
>> Note the model bould be some other Z8xxx nummer, likely it is a
>> Z8350, and if not a Z8300 but any Z8xxx number is CHT.
> 
> Yes, correct:
> model name      : Intel(R) Atom(TM) x5-Z8350  CPU @ 1.44GHz
> 
>> Further confirming that this really is Cherry Trail. Which
>> at least means that my patches might help a bit.
> 
> They do not :(. The interrupts are still storming.
> 
> FWIW I tried the acpi_osi="Windows 2015" kernel parameter. No success too.
> 
>> But ideally we would still be able to get the BIOS to see
>> us as Windows and set its OSID variable to 1. So we don't
>> try to use the wrong GPIOs as IRQ at all. Can you try loading
>> the BIOS setup-defaults / optimal defaults?
> 
> Loaded the optimal values. Still the same
> 
>> If that does not get rid of the IN3496 device (changes its
>> status to 0), then try this:
>>
>> Maybe you have a "Boot Architecture" option under the "Boot"
>> menu in the BIOS? I know you are already at 32 bits, but
>> maybe changing it to 64 bits helps? (after installing a 64 bit
>> shim + grub)
> 
> Unfortunately, there is nothing like that. It's discussed on the net,
> that these UMAXes have only 32bit EFI.

Which is not a problem by itself, mixed-mode support works well,
in Fedora we even support it out of the box.

What is a problem is the OSID thing. So one last silly idea,
can you try on your EFI system partition, creating a dir called:

EFI/Microsoft/Boot

So the Linux path of that likely is:

/boot/efi/EFI/Microsoft/Boot

And then copy your grub.efi to:

/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi

And then with efibootmgr create an entry
titled Windows pointing to that and try booting
that boot entry?

If that does not help and you cannot find any other helpful
options in the BIOS, the only thing I can think of is to
use a DSDT overlay with the OSID checks in the _STA method
of the INT3496, ACPI0011 and INTCFD9 ACPI objects
inverted (or removed).

That should get rid of the interrupt storm, but there are
a lot of other OSID checks and chances are some of those
will cause other issues.

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

Hi,

On 08. 07. 20, 13:47, Hans de Goede wrote:
>> Unfortunately, there is nothing like that. It's discussed on the net,
>> that these UMAXes have only 32bit EFI.
> 
> Which is not a problem by itself, mixed-mode support works well,
> in Fedora we even support it out of the box.
> 
> What is a problem is the OSID thing. So one last silly idea,
> can you try on your EFI system partition, creating a dir called:
> 
> EFI/Microsoft/Boot
> 
> So the Linux path of that likely is:
> 
> /boot/efi/EFI/Microsoft/Boot
> 
> And then copy your grub.efi to:
> 
> /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
> 
> And then with efibootmgr create an entry
> titled Windows pointing to that and try booting
> that boot entry?

Ugh, there is indeed some magic, but it doesn't help.

I created that entry and dubbed it "opensuse_MS2". BIOS renamed it to
"Windows Boot Manager". But still
/sys/bus/acpi/devices/INTCFD9:00/status shows 15 and storms.

I created also EFI/Boot/bootia32.efi. Now BIOS thinks I am android! I.e.
wifi disappeared, the boot option in BIOS says "Android legacy". And it
always switches "Windows 8.x" to "Android legacy". If I delete
EFI/Boot/bootia32.efi (deleting or adding an entry to efibootmgr makes
no difference, the presence of the file matters), I can set "Windows
8.x" and it persists booting, but still storms and things (but wifi is
back).

Any other idea what file/volume I should create in EFI fs?

Note that there is also this entry in bootmgr:
Boot0000* Windows Recovery
FvVol(a881d567-6cb0-4eee-8435-2e72d33e45b5)/FvFile(c57ad6b7-0515-40a8-9d21-551652854e37)RC.W..

This volume definitely no longer exists, at least I believe so. Should I
create such (how?), so that BIOS really believes Win is installed?

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Andy Shevchenko]

On Thu, Jul 9, 2020 at 11:30 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> On 08. 07. 20, 13:47, Hans de Goede wrote:
> >> Unfortunately, there is nothing like that. It's discussed on the net,
> >> that these UMAXes have only 32bit EFI.

Maybe I missed something thru discussion, but is it possible to flash
custom firmware?
Perhaps flashing CoreBoot will help.


-- 
With Best Regards,
Andy Shevchenko

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Andy Shevchenko]

On Thu, Jul 9, 2020 at 11:34 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Jul 9, 2020 at 11:30 AM Jiri Slaby <jirislaby@kernel.org> wrote:
> > On 08. 07. 20, 13:47, Hans de Goede wrote:
> > >> Unfortunately, there is nothing like that. It's discussed on the net,
> > >> that these UMAXes have only 32bit EFI.
>
> Maybe I missed something thru discussion, but is it possible to flash
> custom firmware?
> Perhaps flashing CoreBoot will help.

Yeah, I admit it might actually require writing the support of this
board into CoreBoot :-(

-- 
With Best Regards,
Andy Shevchenko

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/9/20 10:30 AM, Jiri Slaby wrote:
> Hi,
> 
> On 08. 07. 20, 13:47, Hans de Goede wrote:
>>> Unfortunately, there is nothing like that. It's discussed on the net,
>>> that these UMAXes have only 32bit EFI.
>>
>> Which is not a problem by itself, mixed-mode support works well,
>> in Fedora we even support it out of the box.
>>
>> What is a problem is the OSID thing. So one last silly idea,
>> can you try on your EFI system partition, creating a dir called:
>>
>> EFI/Microsoft/Boot
>>
>> So the Linux path of that likely is:
>>
>> /boot/efi/EFI/Microsoft/Boot
>>
>> And then copy your grub.efi to:
>>
>> /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi
>>
>> And then with efibootmgr create an entry
>> titled Windows pointing to that and try booting
>> that boot entry?
> 
> Ugh, there is indeed some magic, but it doesn't help.
> 
> I created that entry and dubbed it "opensuse_MS2". BIOS renamed it to
> "Windows Boot Manager". But still
> /sys/bus/acpi/devices/INTCFD9:00/status shows 15 and storms.
> 
> I created also EFI/Boot/bootia32.efi. Now BIOS thinks I am android! I.e.
> wifi disappeared, the boot option in BIOS says "Android legacy". And it
> always switches "Windows 8.x" to "Android legacy". If I delete
> EFI/Boot/bootia32.efi (deleting or adding an entry to efibootmgr makes
> no difference, the presence of the file matters), I can set "Windows
> 8.x" and it persists booting, but still storms and things (but wifi is
> back).
> 
> Any other idea what file/volume I should create in EFI fs?

No I'm afraid not. The ACPI subsystem will execute the DSDT's
_INI method (line 21712 in the disassembled DSDT) pretty early on.

I think the best way to workaround this is to use a DSDT override
where you set OSID=1 in that _INI method.

This is far from ideal, but so are the other options. Unfortunately
this will not help any other users with the same device, but it at
least should get it working for you.

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

Hi,

On 09. 07. 20, 12:01, Hans de Goede wrote:
>> Any other idea what file/volume I should create in EFI fs?
> 
> No I'm afraid not. The ACPI subsystem will execute the DSDT's
> _INI method (line 21712 in the disassembled DSDT) pretty early on.
> 
> I think the best way to workaround this is to use a DSDT override
> where you set OSID=1 in that _INI method.

Yep, that indeed works.

> This is far from ideal, but so are the other options. Unfortunately
> this will not help any other users with the same device, but it at
> least should get it working for you.

If we only had sources of that BIOS (or at least binary)...

Now, I need to find a way how to persuade dracut to automatically pick
up the updated DSDT.

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

On 09. 07. 20, 13:10, Jiri Slaby wrote:
> Now, I need to find a way how to persuade dracut to automatically pick
> up the updated DSDT.

# cat > /etc/dracut.conf.d/dsdt.conf  <<EOF
acpi_table_dir=/boot/acpi/
acpi_override=yes
EOF
# cp dsdt.aml /boot/acpi/
# dracut --force

That is.

FWIW, now:
# cat /sys/bus/acpi/devices/ACPI0011:00/status
15
# cat /sys/bus/acpi/devices/INTCFD9:00/status
0

thanks,
-- 
js

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/9/20 1:19 PM, Jiri Slaby wrote:
> On 09. 07. 20, 13:10, Jiri Slaby wrote:
>> Now, I need to find a way how to persuade dracut to automatically pick
>> up the updated DSDT.
> 
> # cat > /etc/dracut.conf.d/dsdt.conf  <<EOF
> acpi_table_dir=/boot/acpi/
> acpi_override=yes
> EOF
> # cp dsdt.aml /boot/acpi/
> # dracut --force
> 
> That is.
> 
> FWIW, now:
> # cat /sys/bus/acpi/devices/ACPI0011:00/status
> 15
> # cat /sys/bus/acpi/devices/INTCFD9:00/status
> 0

And I assume the interrupt storms are gone now too :)   ?

I'm glad that this helps, even if it is not entirely ideal.

Let me know if you need help to e.g. get the touchscreen to
work (if it is a silead / MSSL1680 touchscreen you need to do
some manual config).

Likewise you will probably need some quirks for the audio
to get e.g. the internal mic and/or jack-detect to work, see e.g. :

sound/soc/intel/boards/bytcr_rt5640.c
sound/soc/intel/boards/bytcr_rt5651.c
sound/soc/codecs/rt5645.c

The bringup of different codecs was done by different people,
spo the quirks for the rt5640 and rt5651 live in the machine
driver, where as for the rt5645 they are in the codec driver
itself.

For rt5640 / rt5641 the userspace UCM profile bits should pick
up the changes automatically. For rt5645 the UCM profile will
give you all available options. Once you know the right ones
for your tablet we can add a userspace DMI match to make it
show only the ones which are actually valid for your tablet.

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Hans de Goede]

Hi,

On 7/8/20 1:02 PM, Jiri Slaby wrote:
> Hi,
> 
> On 08. 07. 20, 12:15, Hans de Goede wrote:
>> Hi,
>>
>> On 7/8/20 10:52 AM, Jiri Slaby wrote:
>>> On 08. 07. 20, 10:23, Hans de Goede wrote:
>>>> Hi all,
>>>>
>>>> On 7/8/20 9:47 AM, Linus Walleij wrote:
>>>>> On Wed, Jul 8, 2020 at 9:18 AM Jiri Slaby <jirislaby@kernel.org> wrote:
>>>>>
>>>>>> I installed Linux on UMAX VisionBook 10Wi Pro. It sometimes boots, but
>>>>>> even then it encounters lags, soft lockups:
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 23s! [kworker/0:0H:6]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [kworker/0:2:133]
>>>>>>> watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [swapper/0:0]
>>>>>
>>>>> Adding Hans de Goede to Cc, he often deals with this kind of weirdness
>>>>> so he might have some ideas here.
>>>>
>>>> Thank you for looping me in Linus. I've read up on the rest of the
>>>> thread in the archives.
>>>>
>>>> So looking at this:
>>>> https://www.umax.cz/umax-visionbook-10wi/
>>>>
>>>> This device appears to be a pretty standard Cherry Trail based 2-in-1
>>>> with detachable keyboard. Which usually means (with all the
>>>> hw-enablement
>>>> I've been doing the last 2 years for these) that it will just work.
>>>> But no such luck this time it seems.
> ...
>>>> What I find interesting / weird is that you (Jiri) get an active
>>>> (/sys/bus/acpi/devices/INT3496\:00/status != 0) INT3496 device at
>>>> all. That typically only happens when the BIOS thinks you are booting
>>>> Android.
>>>
>>> 15 that is.
>>
>> Right, that is normal for an enabled device the ACPI method
>> implementing the status attribute for your tablet looks like this:
>>
>>              Method (_STA, 0, NotSerialized)  // _STA: Status
>>              {
>>                  If (((BDID == One) && (OSID != One)))
>>                  {
>>                      Return (0x0F)
>>                  }
>>
>>                  Return (Zero)
>>              }
>>
>> So now we know that BDID == One and OSID != One, OSID == One
>> typically is Windows...
>>
>> Looking at the buttons next, can you do:
>>
>> cat /sys/bus/acpi/devices/ACPI0011:00/status
> 
> Gives 0
> 
>> and:
>>
>> cat /sys/bus/acpi/devices/INTCFD9:00/status
> 
> Gives 15
> 
>>
>> If the BIOS thinks you are booting normal Windows the first
>> one should output 15  (0xf) aka present and the second one
>> should output 0, but I suspect it is the other way around...
> 
> Right.
> 
>> So looking at the GPIO resource definitions for BDID == One
>> for the ACPI0011 device we have:
>>
>>                  Name (PBUF, ResourceTemplate ()
>>                  {
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
>> 0x0BB8,
>>                          "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x004E
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0050
>>                          }
>>                  })
>>
>> With a mapping of first resource to KEY_POWER, second resource to
>> KEY_VOLUMEUP and third resource to KEY_VOLUMEDOWN
>>
>> The INTCFD9 device OTOH has the following resource definitions for BDID
>> == One
>>
>>                  Name (PBUF, ResourceTemplate ()
>>                  {
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake, PullUp,
>> 0x0BB8,
>>                          "\\_SB.GPO2", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, ExclusiveAndWake,
>> PullDefault, 0x
>>                          "\\_SB.GPO1", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0008
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x004E
>>                          }
>>                      GpioInt (Edge, ActiveBoth, Exclusive, PullDefault,
>> 0x0BB8,
>>                          "\\_SB.GPO0", 0x00, ResourceConsumer, ,
>>                          )
>>                          {   // Pin list
>>                              0x0050
>>                          }
>>                  })
>>
>> With a mapping of resource1: power, resource2: home, resource3: volume_up,
>> resource4: volume_down.
>>
>> So what we see here is that the "Android" style INTCFD9 device has
>> an extra entry for the home-button and I guess (hard to see on the
>> pictures) that there is no physical home-button.
> 
> I don't know what it should look like, but there is no button with
> house-like painting. There is only a standard "Home" button -- Fn+PgUp.
> And that works even without that module.

I just realized I did not reply to this bit. I meant a home button on
the tablet part of the 2-in-1, so next to the power and volume buttons
on the tablet's edge.

Regards,

Hans

Re: chv-gpio interrupt storm on UMAX VisionBook 10Wi Pro

[Jiri Slaby]

On 08. 07. 20, 13:30, Hans de Goede wrote:
>>> So what we see here is that the "Android" style INTCFD9 device has
>>> an extra entry for the home-button and I guess (hard to see on the
>>> pictures) that there is no physical home-button.
>>
>> I don't know what it should look like, but there is no button with
>> house-like painting. There is only a standard "Home" button -- Fn+PgUp.
>> And that works even without that module.
> 
> I just realized I did not reply to this bit. I meant a home button on
> the tablet part of the 2-in-1, so next to the power and volume buttons
> on the tablet's edge.

Nope, there is only (volume) +, -, and ⏻.

thanks,
-- 
js