Created attachment 187171 [details] decompiled DSDT Using a pre-release of kernel 4.3 I get: Sep 05 14:14:04 localhost kernel: ACPI Error: No handler for Region [GPOR] (ffff88013f4af3a8) [GeneralPurposeIo] (20150619/evregion-163) Sep 05 14:14:04 localhost kernel: ACPI Error: Region GeneralPurposeIo (ID=8) has no handler (20150619/exfldio-297) Sep 05 14:14:04 localhost kernel: ACPI Error: Method parse/execution failed [\_SB_.PCI0.SPI1.NTRG._STA] (Node ffff88013f4b15a0), AE_NOT_EXIST (20150619/psparse-536) (Full log at https://bugzilla.kernel.org/attachment.cgi?id=186711 ) Which in the DSDT corresponds to: Scope (_SB.PCI0.SPI1) { Device (NTRG) { Name (_HID, "MSHW0037") // _HID: Hardware ID Name (_UID, One) // _UID: Unique ID Name (_DEP, Package (0x04) // _DEP: Dependencies { GPO0, GPO1, GPO3, SPI1 }) The MSHW0037 device is the touchscreen, in Windows' device manager program.
Hi, Bastien, Since Aaron has addressed the cause for this problem, can you please help test if Aaron's patch work for you? thanks. diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c index ec256352f423..418c8a7cec91 100644 --- a/drivers/acpi/scan.c +++ b/drivers/acpi/scan.c @@ -2293,7 +2293,7 @@ static int acpi_bus_type_and_status(acpi_handle handle, int *type, *type = ACPI_BUS_TYPE_DEVICE; status = acpi_bus_get_status_handle(handle, sta); if (ACPI_FAILURE(status)) - return -ENODEV; + *sta = 0; break; case ACPI_TYPE_PROCESSOR: *type = ACPI_BUS_TYPE_PROCESSOR; http://marc.info/?l=linux-acpi&m=144187045529326&w=2
That doesn't fix it, I'll upload the dmesg in a second. Let me know if you need me to modularise any particular driver.
Created attachment 187421 [details] 4.3.0-0.rc0.git11.2.fc22.x86_64.txt
Please add initcall_debug to kernel cmdline, BTW, do you have CONFIG_SPI_PXA2XX set?
And CONFIG_PINCTRL_CHERRYVIEW for the GPIO controller.
(In reply to Aaron Lu from comment #5) > And CONFIG_PINCTRL_CHERRYVIEW for the GPIO controller. That's enabled. (In reply to Aaron Lu from comment #4) > Please add initcall_debug to kernel cmdline, BTW, do you have > CONFIG_SPI_PXA2XX set? But that isn't. I'll build a new kernel with that enabled, and will gather debug data if it fails.
Created attachment 187821 [details] 4.3.0-0.rc0.git14.2.fc22.x86_64.txt With CONFIG_SPI_PXA2XX enabled.
Can you double check that you have pinctrl-cherryview loaded? You should have all 4 instances listed under /sys/kernel/debug/pinctrl/INT33FF:* if that's the case.
(In reply to Mika Westerberg from comment #8) > Can you double check that you have pinctrl-cherryview loaded? It's loaded as a module, and looks to have 8 users according to lsmod > You should > have all 4 instances listed under /sys/kernel/debug/pinctrl/INT33FF:* if > that's the case. Yes, the 4 directories are there, pinctrl-devices has "pinmux" and "pinconf" set to yes for all devices, and pinctrl-handles has "current state: none" for all devices as well.
OK thanks. The BIOS should check whether a OpRegion is available or not before trying to access it. It looks like this BIOS does not do that. Regardless of that the devices should be able to request GPIOs as you have the driver loaded. Can you try if CONFIG_PINCTRL_CHERRYVIEW=y changes anything?
Bastien, can you please try what Mika has suggested in comment #10? Thanks.
(In reply to Aaron Lu from comment #11) > Bastien, > > can you please try what Mika has suggested in comment #10? Thanks. I've finally managed to test this, and it makes no difference.
Yu, Since you also have Surface 3, can you please take a look at this? Thanks.
Hi,Aaron Sure. please assign to me. But I'll switch to Surface 3 next week, since this week I'm going to do some preparation for CLK2015. Thanks Yu
Hi, Aaron , Bastien I saw #Comment 18 in https://bugzilla.kernel.org/show_bug.cgi?id=106221, is this problem fixed by the patch mentioned in #Comment 18? thanks Yu
Mika, Is it possible to fix the spi->chip_select equals to master->num_chipselect problem mentioned in comment #18 of bug #106221 somehow? The problem will stop the NTRG SPI slave device from being enumerated as a platform device, thanks.
Good question. Maybe Windows ignores the CS value if the SPI master has only one chip select or so? We could try the same in Linux as well.
(In reply to Mika Westerberg from comment #17) > Good question. > > Maybe Windows ignores the CS value if the SPI master has only one chip > select or so? We could try the same in Linux as well. Would you care to send a patch to fix this? I can test it when it's ready. Thanks.
It turned out that Braswell/Cherry Trail has 2 chipselects so 1 in SpiSerialBus() could be correct after all. However, it all boils down to this error: [ 0.184339] ACPI Error: Method parse/execution failed [\_SB.PCI0.SPI1.NTRG._STA] (Node ffff88007709a5f0), AE_NOT_EXIST (20150930/psparse-542) _STA() fails because GPIO is not there yet.
Created attachment 193231 [details] SPI multiple chipselects hack for Braswell/Cherry Trail
(In reply to Mika Westerberg from comment #19) > It turned out that Braswell/Cherry Trail has 2 chipselects so 1 in > SpiSerialBus() could be correct after all. > > However, it all boils down to this error: > > [ 0.184339] ACPI Error: Method parse/execution failed > [\_SB.PCI0.SPI1.NTRG._STA] (Node ffff88007709a5f0), AE_NOT_EXIST > (20150930/psparse-542) > > _STA() fails because GPIO is not there yet. No worry, that could be worked around by this: http://www.spinics.net/lists/linux-acpi/msg60480.html Though very hacky, it doesn't seem hurt to have an acpi_device node created for ACPI nodes whose _STA evaluation failed. I can send it out formally later.
Mika, I tested your patch(together with the _STA patch), but I still get this error: ... [ 1.113784] calling pxa2xx_spi_init+0x0/0x14 @ 1 [ 1.116115] pxa2xx-spi 8086228E:00: cs1 >= max 1 [ 1.116141] spi_master spi1: failed to add SPI device MSHW0037:00 from ACPI [ 1.120771] initcall pxa2xx_spi_init+0x0/0x14 returned 0 after 0 usecs ... Please let me know if you need any more information, thanks.
Created attachment 194821 [details] SPI multiple chipselects hack for Braswell/Cherry Trail (updated) Please try this patch instead. The previous patch misses few important things.
You forgot this part: diff --git a/include/linux/pxa2xx_ssp.h b/include/linux/pxa2xx_ssp.h index c2f2574ff61c..2a097d176ba9 100644 --- a/include/linux/pxa2xx_ssp.h +++ b/include/linux/pxa2xx_ssp.h @@ -197,6 +197,7 @@ enum pxa_ssp_type { QUARK_X1000_SSP, LPSS_LPT_SSP, /* Keep LPSS types sorted with lpss_platforms[] */ LPSS_BYT_SSP, + LPSS_BSW_SSP, LPSS_SPT_SSP, LPSS_BXT_SSP, }; With the above added, your patch in comment #23 works: the spi-MSHW0027:00 is created. Feel free to add my tested-by tag. BTW, the following three lines seem to be redundant: diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index b25dc71b0ea9..4474ffd88786 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -1567,9 +1587,6 @@ static int pxa2xx_spi_probe(struct platform_device *pdev) if (!is_quark_x1000_ssp(drv_data)) pxa2xx_spi_write(drv_data, SSPSP, 0); - if (is_lpss_ssp(drv_data)) - lpss_ssp_setup(drv_data); - if (is_lpss_ssp(drv_data)) { lpss_ssp_setup(drv_data); config = lpss_get_config(drv_data);
Patch for the _STA problem has been sent out: https://patchwork.kernel.org/patch/7654111/
Mika, did you ever send out a patch for the spi multiple chipselect support? Now that we can get video working on the Surface 3 (Bug #97941), it would be nice to get the touch controller working. It looks like the patch would need some changes to apply cleanly against kernel 4.4-rc6.
No not yet. I need to clean it up first. I'll do that after holidays.
Created attachment 199311 [details] SPI multiple chipselects for Braswell (cleaned up) Here is a new patch to try. If this works for you, I'll submit it upstream.
(In reply to Mika Westerberg from comment #28) > Created attachment 199311 [details] > SPI multiple chipselects for Braswell (cleaned up) > > Here is a new patch to try. If this works for you, I'll submit it upstream. Worked for me, managed to enumerate the touchscreen with this patch. Feel free to add my Tested-by on the kernel patch.