* ACPI SPI slave device @ 2016-02-23 1:54 Leif Liddy 2016-02-23 7:38 ` Mika Westerberg 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-02-23 1:54 UTC (permalink / raw) To: linux-acpi I'm new to kernel development, and there's few fairly large gaps in my understanding about how drivers are meant to work, but hopefully you guys can point me in the right direction. The macbook8,1 (early 2015) has a keyboard/trackpad that is seen by ACPI as a single SPI slave device. It appears the only method to access the keyboard/trackpad is via the SPI bus --my goal is the get keyboard/trackpad working. I've recently submitted a kernel patch that binds the spi-pxa2xx-pci driver to the Wildcat Point-LP Serial IO GSPI Controller. With this patch, the SPI controller appears to be working... http://www.spinics.net/lists/linux-spi/msg06867.html ----------LSHW INFO------------ *-serial:1 description: Serial bus controller product: Wildcat Point-LP Serial IO GSPI Controller #1 vendor: Intel Corporation physical id: 15.4 bus info: pci@0000:00:15.4 version: 03 width: 32 bits clock: 33MHz capabilities: pm cap_list configuration: driver=pxa2xx_spi_pci latency=0 resources: irq:21 memory:c181a000-c181afff What I'm having trouble with is sorting out how to register the SPI slave device with the SPI controller. **no slave devices are found when I modprobe the driver. I'm not sure if this is something that should be done by the spi driver (by calling an acpi function), or whether I must manually do it. –------------UDEV INFO--------------- P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=13574842 **INT33C1 is the SPI master controller **APP000D is the slave device ----------------SPI modules loaded----------- spi_pxa2xx_platform 24576 0 spi_pxa2xx_pci 16384 0 The ACPI DSDT table (decoded): https://bugzilla.kernel.org/attachment.cgi?id=202141 The full bug report: https://bugzilla.kernel.org/show_bug.cgi?id=108331 ANY help would be appreciated Leif Liddy -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 1:54 ACPI SPI slave device Leif Liddy @ 2016-02-23 7:38 ` Mika Westerberg 2016-02-23 14:18 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Mika Westerberg @ 2016-02-23 7:38 UTC (permalink / raw) To: Leif Liddy; +Cc: linux-acpi On Tue, Feb 23, 2016 at 02:54:45AM +0100, Leif Liddy wrote: > I'm new to kernel development, and there's few fairly large gaps in my > understanding about > how drivers are meant to work, but hopefully you guys can point me in > the right direction. > > The macbook8,1 (early 2015) has a keyboard/trackpad that is seen by > ACPI as a single SPI slave device. > It appears the only method to access the keyboard/trackpad is via > the SPI bus --my goal is the get keyboard/trackpad working. > > I've recently submitted a kernel patch that binds the spi-pxa2xx-pci > driver to the Wildcat Point-LP Serial IO GSPI Controller. With this > patch, the SPI controller appears to be working... > http://www.spinics.net/lists/linux-spi/msg06867.html > > ----------LSHW INFO------------ > *-serial:1 > description: Serial bus controller > product: Wildcat Point-LP Serial IO GSPI Controller #1 > vendor: Intel Corporation > physical id: 15.4 > bus info: pci@0000:00:15.4 > version: 03 > width: 32 bits > clock: 33MHz > capabilities: pm cap_list > configuration: driver=pxa2xx_spi_pci latency=0 > resources: irq:21 memory:c181a000-c181afff > > > What I'm having trouble with is sorting out how to register the SPI > slave device with the SPI controller. > **no slave devices are found when I modprobe the driver. > I'm not sure if this is something that should be done by the spi > driver (by calling an acpi function), or whether I must manually do > it. > > –------------UDEV INFO--------------- > > P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 > E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 > E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc > E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: > E: SUBSYSTEM=acpi > E: USEC_INITIALIZED=13574842 > > **INT33C1 is the SPI master controller > **APP000D is the slave device If the device has ACPI SpiSerialBus() resource in _CRS it should be enumerated automatically by the Linux SPI core. See Documentation/acpi/enumeration.txt. You should also see the device listed under /sys/bus/spi/devices. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 7:38 ` Mika Westerberg @ 2016-02-23 14:18 ` Leif Liddy 2016-02-23 15:02 ` Mika Westerberg 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-02-23 14:18 UTC (permalink / raw) To: Mika Westerberg; +Cc: linux-acpi The device does have SPISerialbus() in _CRS. Looks like this guy is having the same issue. https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04044.html "Slave devices were not enumerated by ACPI data because the ACPI handle for the spi-pxa2xx controller was NULL if it was itself enumerated by PCI. Upstream-status: Inappropriate, real fix forthcoming" I'm going to try out his patch and see what happens.. On Tue, Feb 23, 2016 at 8:38 AM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > On Tue, Feb 23, 2016 at 02:54:45AM +0100, Leif Liddy wrote: >> I'm new to kernel development, and there's few fairly large gaps in my >> understanding about >> how drivers are meant to work, but hopefully you guys can point me in >> the right direction. >> >> The macbook8,1 (early 2015) has a keyboard/trackpad that is seen by >> ACPI as a single SPI slave device. >> It appears the only method to access the keyboard/trackpad is via >> the SPI bus --my goal is the get keyboard/trackpad working. >> >> I've recently submitted a kernel patch that binds the spi-pxa2xx-pci >> driver to the Wildcat Point-LP Serial IO GSPI Controller. With this >> patch, the SPI controller appears to be working... >> http://www.spinics.net/lists/linux-spi/msg06867.html >> >> ----------LSHW INFO------------ >> *-serial:1 >> description: Serial bus controller >> product: Wildcat Point-LP Serial IO GSPI Controller #1 >> vendor: Intel Corporation >> physical id: 15.4 >> bus info: pci@0000:00:15.4 >> version: 03 >> width: 32 bits >> clock: 33MHz >> capabilities: pm cap_list >> configuration: driver=pxa2xx_spi_pci latency=0 >> resources: irq:21 memory:c181a000-c181afff >> >> >> What I'm having trouble with is sorting out how to register the SPI >> slave device with the SPI controller. >> **no slave devices are found when I modprobe the driver. >> I'm not sure if this is something that should be done by the spi >> driver (by calling an acpi function), or whether I must manually do >> it. >> >> –------------UDEV INFO--------------- >> >> P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 >> E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 >> E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc >> E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: >> E: SUBSYSTEM=acpi >> E: USEC_INITIALIZED=13574842 >> >> **INT33C1 is the SPI master controller >> **APP000D is the slave device > > If the device has ACPI SpiSerialBus() resource in _CRS it should be > enumerated automatically by the Linux SPI core. See > Documentation/acpi/enumeration.txt. > > You should also see the device listed under /sys/bus/spi/devices. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 14:18 ` Leif Liddy @ 2016-02-23 15:02 ` Mika Westerberg 2016-02-23 15:32 ` Mika Westerberg 0 siblings, 1 reply; 24+ messages in thread From: Mika Westerberg @ 2016-02-23 15:02 UTC (permalink / raw) To: Leif Liddy; +Cc: linux-acpi, jarkko.nikula On Tue, Feb 23, 2016 at 03:18:26PM +0100, Leif Liddy wrote: > The device does have SPISerialbus() in _CRS. > > Looks like this guy is having the same issue. > https://www.mail-archive.com/linux-yocto@yoctoproject.org/msg04044.html > > "Slave devices were not enumerated by ACPI data because the ACPI handle > for the spi-pxa2xx controller was NULL if it was itself enumerated by > PCI. Yes, PCI part of the spi-pxa2xx does not propagate ACPI handle of the device to the platform device it creates which prevents SPI core from enumerating it. > Upstream-status: Inappropriate, real fix forthcoming" I believe passing the ACPI handle to the platform device is the real fix. Actually I think Jarkko (CC'd) already did patch for this some time ago. We probably never upstreamed it because Haswell and Broadwell both were supposed to enumerate LPSS devices only from ACPI. It seems not to be the case for Apple devices, though. > > I'm going to try out his patch and see what happens.. > > On Tue, Feb 23, 2016 at 8:38 AM, Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: > > On Tue, Feb 23, 2016 at 02:54:45AM +0100, Leif Liddy wrote: > >> I'm new to kernel development, and there's few fairly large gaps in my > >> understanding about > >> how drivers are meant to work, but hopefully you guys can point me in > >> the right direction. > >> > >> The macbook8,1 (early 2015) has a keyboard/trackpad that is seen by > >> ACPI as a single SPI slave device. > >> It appears the only method to access the keyboard/trackpad is via > >> the SPI bus --my goal is the get keyboard/trackpad working. > >> > >> I've recently submitted a kernel patch that binds the spi-pxa2xx-pci > >> driver to the Wildcat Point-LP Serial IO GSPI Controller. With this > >> patch, the SPI controller appears to be working... > >> http://www.spinics.net/lists/linux-spi/msg06867.html > >> > >> ----------LSHW INFO------------ > >> *-serial:1 > >> description: Serial bus controller > >> product: Wildcat Point-LP Serial IO GSPI Controller #1 > >> vendor: Intel Corporation > >> physical id: 15.4 > >> bus info: pci@0000:00:15.4 > >> version: 03 > >> width: 32 bits > >> clock: 33MHz > >> capabilities: pm cap_list > >> configuration: driver=pxa2xx_spi_pci latency=0 > >> resources: irq:21 memory:c181a000-c181afff > >> > >> > >> What I'm having trouble with is sorting out how to register the SPI > >> slave device with the SPI controller. > >> **no slave devices are found when I modprobe the driver. > >> I'm not sure if this is something that should be done by the spi > >> driver (by calling an acpi function), or whether I must manually do > >> it. > >> > >> –------------UDEV INFO--------------- > >> > >> P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 > >> E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 > >> E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc > >> E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: > >> E: SUBSYSTEM=acpi > >> E: USEC_INITIALIZED=13574842 > >> > >> **INT33C1 is the SPI master controller > >> **APP000D is the slave device > > > > If the device has ACPI SpiSerialBus() resource in _CRS it should be > > enumerated automatically by the Linux SPI core. See > > Documentation/acpi/enumeration.txt. > > > > You should also see the device listed under /sys/bus/spi/devices. -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 15:02 ` Mika Westerberg @ 2016-02-23 15:32 ` Mika Westerberg 2016-02-23 20:30 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Mika Westerberg @ 2016-02-23 15:32 UTC (permalink / raw) To: Leif Liddy; +Cc: linux-acpi, jarkko.nikula On Tue, Feb 23, 2016 at 05:02:22PM +0200, Mika Westerberg wrote: > > Upstream-status: Inappropriate, real fix forthcoming" > > I believe passing the ACPI handle to the platform device is the real > fix. That said, I remember discussing this with Ismo (author of the patch you are trying out) and the real fix probably means that we do the same for SPI that we already did for I2C - scan all devices for SpiSerialBus() connections to the SPI master we just registered, not just the immediate children. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 15:32 ` Mika Westerberg @ 2016-02-23 20:30 ` Leif Liddy 2016-02-29 8:21 ` Mika Westerberg 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-02-23 20:30 UTC (permalink / raw) To: Mika Westerberg; +Cc: linux-acpi, jarkko.nikula I'm beginning to understand how this is meant to work. spi_pxa2xx_platform should by itself be able to setup the SPI controller. **it has the ACPI ID for it { "INT33C1", LPSS_LPT_SSP } When I modprobe spi_pxa2xx_platform pxa2xx_spi_probe never gets called, there must be an issue with: acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match) Ok, so I've installed Ismo's one line patch dmesg log of "modprobe spi_pxa2xx_pci" pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan0) pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 dmaengine: private_candidate: dma0chan0 busy dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan1) without the patch: dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan0) dmaengine: private_candidate: dma0chan0 busy dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan1) On Tue, Feb 23, 2016 at 4:32 PM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > On Tue, Feb 23, 2016 at 05:02:22PM +0200, Mika Westerberg wrote: >> > Upstream-status: Inappropriate, real fix forthcoming" >> >> I believe passing the ACPI handle to the platform device is the real >> fix. > > That said, I remember discussing this with Ismo (author of the patch you > are trying out) and the real fix probably means that we do the same for > SPI that we already did for I2C - scan all devices for SpiSerialBus() > connections to the SPI master we just registered, not just the immediate > children. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-23 20:30 ` Leif Liddy @ 2016-02-29 8:21 ` Mika Westerberg 2016-02-29 17:21 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Mika Westerberg @ 2016-02-29 8:21 UTC (permalink / raw) To: Leif Liddy; +Cc: linux-acpi, jarkko.nikula On Tue, Feb 23, 2016 at 09:30:40PM +0100, Leif Liddy wrote: > I'm beginning to understand how this is meant to work. > > spi_pxa2xx_platform should by itself be able to setup the SPI controller. > **it has the ACPI ID for it > { "INT33C1", LPSS_LPT_SSP } > > When I modprobe spi_pxa2xx_platform > pxa2xx_spi_probe never gets called, there must be an issue with: > acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match) That's fine - the device is a PCI device and does not require ACPI ID. However, the PCI part of the driver creates this platform device for spi_pxa2xx_platform. > Ok, so I've installed Ismo's one line patch > > dmesg log of "modprobe spi_pxa2xx_pci" > > pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 > dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan0) > pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 > dmaengine: private_candidate: dma0chan0 busy > dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan1) Difference is that with Ismo's patch you actually have ACPI handle for the device so it tries to use ACPI to look for the DMA channels. > without the patch: > > dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan0) > dmaengine: private_candidate: dma0chan0 busy > dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan1) Here it uses hardcoded indices instead. In both cases result is the same. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-29 8:21 ` Mika Westerberg @ 2016-02-29 17:21 ` Leif Liddy 2016-03-01 15:42 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-02-29 17:21 UTC (permalink / raw) To: Mika Westerberg; +Cc: linux-acpi, jarkko.nikula I debugged acpi_lpss.c as it attempted to created a platform device for INT33C1. I got as far as this function in resouce.c status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS, acpi_dev_process_resource, &c); the value of c never gets incremented --and returns 0. I'm not sure how closely apcia follows the logic of these tables and whether the OSI value is actually checked or not. If WBUF is being returned, then that would be the source of the issue. Device (SDMA) { Name (_ADR, 0x00150000) // _ADR: Address Name (_UID, 0x01) // _UID: Unique ID Name (RBUF, ResourceTemplate () ... Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (RBUF) /* \_SB_.PCI0.SDMA.RBUF */ } ... Device (SPI1) { Name (_ADR, 0x00150004) // _ADR: Address Name (_CID, "INT33C1" /* Intel Serial I/O SPI Host Controller */) .. Name (WBUF, ResourceTemplate () { }) Name (DBUF, ResourceTemplate () { FixedDMA (0x0010, 0x0006, Width32bit, ) FixedDMA (0x0011, 0x0007, Width32bit, ) }) Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { If (!OSDW ()) { Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ } Return (ConcatenateResTemplate (RBUF, DBUF)) } } ...... In any case, it sounds like the best approach is just to go with the spi-pxa2xx-pci driver. >>I believe passing the ACPI handle to the platform device is the real >fix. Ok, I understand what this means now --and I know what the acpi handle is for INT33C1. I'm going to try and modify spi.c to use this acpi handle --and hopefully it will find the SPI slave device. handle = ACPI_HANDLE(master->dev.parent); status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1, acpi_spi_add_device, NULL, master, NULL); On Mon, Feb 29, 2016 at 9:21 AM, Mika Westerberg <mika.westerberg@linux.intel.com> wrote: > On Tue, Feb 23, 2016 at 09:30:40PM +0100, Leif Liddy wrote: >> I'm beginning to understand how this is meant to work. >> >> spi_pxa2xx_platform should by itself be able to setup the SPI controller. >> **it has the ACPI ID for it >> { "INT33C1", LPSS_LPT_SSP } >> >> When I modprobe spi_pxa2xx_platform >> pxa2xx_spi_probe never gets called, there must be an issue with: >> acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match) > > That's fine - the device is a PCI device and does not require ACPI ID. > However, the PCI part of the driver creates this platform device for > spi_pxa2xx_platform. > >> Ok, so I've installed Ismo's one line patch >> >> dmesg log of "modprobe spi_pxa2xx_pci" >> >> pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 >> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors >> dmaengine: __dma_request_channel: success (dma0chan0) >> pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 >> dmaengine: private_candidate: dma0chan0 busy >> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors >> dmaengine: __dma_request_channel: success (dma0chan1) > > Difference is that with Ismo's patch you actually have ACPI handle for > the device so it tries to use ACPI to look for the DMA channels. > >> without the patch: >> >> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors >> dmaengine: __dma_request_channel: success (dma0chan0) >> dmaengine: private_candidate: dma0chan0 busy >> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors >> dmaengine: __dma_request_channel: success (dma0chan1) > > Here it uses hardcoded indices instead. In both cases result is the > same. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-02-29 17:21 ` Leif Liddy @ 2016-03-01 15:42 ` Leif Liddy 2016-03-01 16:07 ` Lukas Wunner 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-01 15:42 UTC (permalink / raw) To: Mika Westerberg; +Cc: linux-acpi, jarkko.nikula With Ismo's patch applied, I added a few printk statements to spi.c and resource.c (the lines beginning with xxx). modprobe pxa2xx-spi-pci pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 xxx resource.c acpi_dev_get_resources acpi_handle is ffff8802650bdcd0 returns c.count 0... dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan0) pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 xxx resource.c acpi_dev_get_resources acpi_handle is ffff8802650bdcd0 returns c.count 0... dmaengine: private_candidate: dma0chan0 busy dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan1) pxa2xx-spi pxa2xx-spi.0: registered master spi0 xxx spi.c acpi_register_spi_devices acpi_handle is ffff8802650bdcd0 xxx resource.c acpi_dev_get_resources acpi_handle is ffff8802650bf000 returns c.count 0... I believe these acpi handle values correspond to: ffff8802650bdcd0 = INT33C1/SPI controller ffff8802650bf000 = APP000D/SPI slave spi.c did find the slave device, as this statement was not evaluated: if (ACPI_FAILURE(status)) dev_warn(&master->dev, "failed to enumerate SPI slaves\n"); However, the slave device is never enumerated. Do you know how I could print out the the name or id of the ACPI device from the acpi_device pointer? **I'm struggling a bit with some of these data types I'll continue to debug this issue a bit more... On Mon, Feb 29, 2016 at 6:21 PM, Leif Liddy <leif.linux@gmail.com> wrote: > I debugged acpi_lpss.c as it attempted to created a platform device for INT33C1. > > I got as far as this function in resouce.c > status = acpi_walk_resources(adev->handle, METHOD_NAME__CRS, > acpi_dev_process_resource, &c); > > the value of c never gets incremented --and returns 0. > > I'm not sure how closely apcia follows the logic of these tables and > whether the OSI value is actually checked or not. > If WBUF is being returned, then that would be the source of the issue. > > > Device (SDMA) > { > Name (_ADR, 0x00150000) // _ADR: Address > Name (_UID, 0x01) // _UID: Unique ID > Name (RBUF, ResourceTemplate () > ... > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Return (RBUF) /* \_SB_.PCI0.SDMA.RBUF */ > } > ... > Device (SPI1) > { > Name (_ADR, 0x00150004) // _ADR: Address > Name (_CID, "INT33C1" /* Intel Serial I/O SPI Host Controller */) > .. > Name (WBUF, ResourceTemplate () > { > }) > Name (DBUF, ResourceTemplate () > { > FixedDMA (0x0010, 0x0006, Width32bit, ) > FixedDMA (0x0011, 0x0007, Width32bit, ) > }) > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > If (!OSDW ()) > { > Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ > } > > Return (ConcatenateResTemplate (RBUF, DBUF)) > } > } > ...... > > > In any case, it sounds like the best approach is just to go with the > spi-pxa2xx-pci driver. > >>>I believe passing the ACPI handle to the platform device is the real >>fix. > > Ok, I understand what this means now --and I know what the acpi handle > is for INT33C1. > I'm going to try and modify spi.c to use this acpi handle --and > hopefully it will find the SPI slave device. > > handle = ACPI_HANDLE(master->dev.parent); > > status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1, > acpi_spi_add_device, NULL, > master, NULL); > > On Mon, Feb 29, 2016 at 9:21 AM, Mika Westerberg > <mika.westerberg@linux.intel.com> wrote: >> On Tue, Feb 23, 2016 at 09:30:40PM +0100, Leif Liddy wrote: >>> I'm beginning to understand how this is meant to work. >>> >>> spi_pxa2xx_platform should by itself be able to setup the SPI controller. >>> **it has the ACPI ID for it >>> { "INT33C1", LPSS_LPT_SSP } >>> >>> When I modprobe spi_pxa2xx_platform >>> pxa2xx_spi_probe never gets called, there must be an issue with: >>> acpi_match_table = ACPI_PTR(pxa2xx_spi_acpi_match) >> >> That's fine - the device is a PCI device and does not require ACPI ID. >> However, the PCI part of the driver creates this platform device for >> spi_pxa2xx_platform. >> >>> Ok, so I've installed Ismo's one line patch >>> >>> dmesg log of "modprobe spi_pxa2xx_pci" >>> >>> pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 >>> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors >>> dmaengine: __dma_request_channel: success (dma0chan0) >>> pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 >>> dmaengine: private_candidate: dma0chan0 busy >>> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors >>> dmaengine: __dma_request_channel: success (dma0chan1) >> >> Difference is that with Ismo's patch you actually have ACPI handle for >> the device so it tries to use ACPI to look for the DMA channels. >> >>> without the patch: >>> >>> dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors >>> dmaengine: __dma_request_channel: success (dma0chan0) >>> dmaengine: private_candidate: dma0chan0 busy >>> dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors >>> dmaengine: __dma_request_channel: success (dma0chan1) >> >> Here it uses hardcoded indices instead. In both cases result is the >> same. ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-01 15:42 ` Leif Liddy @ 2016-03-01 16:07 ` Lukas Wunner 2016-03-01 23:33 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Lukas Wunner @ 2016-03-01 16:07 UTC (permalink / raw) To: Leif Liddy; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula Hi Leif, On Tue, Mar 01, 2016 at 04:42:18PM +0100, Leif Liddy wrote: > Do you know how I could print out the the name or id of the ACPI > device from the acpi_device pointer? printk("acpi_dev_name=%s\n", acpi_dev_name(adev)); https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/acpi.h#n83 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/acpi/acpi_bus.h#n354 Best regards, Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-01 16:07 ` Lukas Wunner @ 2016-03-01 23:33 ` Leif Liddy 2016-03-02 3:13 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-01 23:33 UTC (permalink / raw) To: Lukas Wunner; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula Thanks for that!!! Ok, I added a few more printk statments to spi.c. It looks like the root cause of the issue is that the "ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS" check is failing. pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 xxx resource.c acpi_dev_get_resources acpi_dev_name=INT33C1:00 returns c.count 0... dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan0) pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 xxx resource.c acpi_dev_get_resources acpi_dev_name=INT33C1:00 returns c.count 0... dmaengine: private_candidate: dma0chan0 busy dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors dmaengine: __dma_request_channel: success (dma0chan1) pxa2xx-spi pxa2xx-spi.0: registered master spi0 xxx spi.c acpi_register_spi_devices acpi_handle is ffff8802650bdcd0 (INT33C1:00) xxx spi.c acpi_spi_add_device() start xxx spi.c *spi_alloc_device() start xxx spi.c acpi_spi_add_device acpi_dev_name=APP000D:00 xxx spi.c acpi_spi_add_resource() start xxx spi.c acpi_spi_add_resource spi->irq = -1 xxx spi.c acpi_spi_add_resource failed check: ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS xxx spi.c acpi_spi_add_resource :else if (spi->irq < 0) xxx spi.c acpi_spi_add_resource return 1 xxx resource.c acpi_dev_get_resources acpi_dev_name=APP000D:00 returns c.count 0... xxx spi.c acpi_spi_add_device ret returns 0 xxx spi.c acpi_spi_add_device spi->max_speed_hz is 0 xxx spi.c acpi_spi_add_device (ret < 0 || !spi->max_speed_hz) ---> spi_dev_put(spi) --> return AE_OK I assume it's looking for SpiSerialBus in the _CRS method, not sure why it can't find it. I wonder if there's a way to just manually configure the slave device. Device (SPIT) { Name (_HID, EisaId ("APP000D")) // _HID: Hardware ID ..... Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { Name (UBUF, ResourceTemplate () { SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\\_SB.PCI0.SPI1", 0x00, ResourceConsumer, , ) Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, ) { 0x0000001E, } }) Name (ABUF, ResourceTemplate () { }) If (!OSDW ()) { Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ } Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ } On Tue, Mar 1, 2016 at 5:07 PM, Lukas Wunner <lukas@wunner.de> wrote: > Hi Leif, > > On Tue, Mar 01, 2016 at 04:42:18PM +0100, Leif Liddy wrote: >> Do you know how I could print out the the name or id of the ACPI >> device from the acpi_device pointer? > > printk("acpi_dev_name=%s\n", acpi_dev_name(adev)); > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/acpi.h#n83 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/acpi/acpi_bus.h#n354 > > Best regards, > > Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-01 23:33 ` Leif Liddy @ 2016-03-02 3:13 ` Leif Liddy 2016-03-02 11:42 ` Lukas Wunner 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-02 3:13 UTC (permalink / raw) To: Lukas Wunner; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula I finally got the SPI slave enumerated....by modifying the DSDT table P: /devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00 E: DEVPATH=/devices/pci0000:00/0000:00:15.4/pxa2xx-spi.0/spi_master/spi0/spi-APP000D:00 E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: E: SUBSYSTEM=spi E: USEC_INITIALIZED=27944872 /proc/acpi/wakeup Device S-state Status Sysfs node SPIT S3 *disabled spi:spi-APP000D:00 I'll post more tomorrow, need to evaluate the changes I made --but I think the change that did it was changing this: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { If (!OSDW ()) { Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ } Return (ConcatenateResTemplate (RBUF, DBUF)) } to: Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings { Return (ConcatenateResTemplate (RBUF, DBUF)) } On Wed, Mar 2, 2016 at 12:33 AM, Leif Liddy <leif.linux@gmail.com> wrote: > Thanks for that!!! > > Ok, I added a few more printk statments to spi.c. It looks like the > root cause of the issue is that the > "ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS" check is failing. > > pxa2xx-spi pxa2xx-spi.0: found DMA channel "tx" at index 0 > xxx resource.c acpi_dev_get_resources acpi_dev_name=INT33C1:00 returns > c.count 0... > dma dma0chan0: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan0) > pxa2xx-spi pxa2xx-spi.0: found DMA channel "rx" at index 1 > xxx resource.c acpi_dev_get_resources acpi_dev_name=INT33C1:00 returns > c.count 0... > dmaengine: private_candidate: dma0chan0 busy > dma dma0chan1: dwc_alloc_chan_resources: allocated 64 descriptors > dmaengine: __dma_request_channel: success (dma0chan1) > pxa2xx-spi pxa2xx-spi.0: registered master spi0 > xxx spi.c acpi_register_spi_devices acpi_handle is ffff8802650bdcd0 (INT33C1:00) > xxx spi.c acpi_spi_add_device() start > xxx spi.c *spi_alloc_device() start > xxx spi.c acpi_spi_add_device acpi_dev_name=APP000D:00 > xxx spi.c acpi_spi_add_resource() start > xxx spi.c acpi_spi_add_resource spi->irq = -1 > xxx spi.c acpi_spi_add_resource failed check: ares->type == > ACPI_RESOURCE_TYPE_SERIAL_BUS > xxx spi.c acpi_spi_add_resource :else if (spi->irq < 0) > xxx spi.c acpi_spi_add_resource return 1 > xxx resource.c acpi_dev_get_resources acpi_dev_name=APP000D:00 returns > c.count 0... > xxx spi.c acpi_spi_add_device ret returns 0 > xxx spi.c acpi_spi_add_device spi->max_speed_hz is 0 > xxx spi.c acpi_spi_add_device (ret < 0 || !spi->max_speed_hz) ---> > spi_dev_put(spi) --> return AE_OK > > > I assume it's looking for SpiSerialBus in the _CRS method, not sure > why it can't find it. I wonder if there's a way to just manually > configure the slave device. > > > Device (SPIT) > { > Name (_HID, EisaId ("APP000D")) // _HID: Hardware ID > ..... > > Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings > { > Name (UBUF, ResourceTemplate () > { > SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08, > ControllerInitiated, 0x007A1200, ClockPolarityLow, > ClockPhaseFirst, "\\_SB.PCI0.SPI1", > 0x00, ResourceConsumer, , > ) > Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, ) > { > 0x0000001E, > } > }) > Name (ABUF, ResourceTemplate () > { > }) > If (!OSDW ()) > { > Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ > } > > Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ > } > > On Tue, Mar 1, 2016 at 5:07 PM, Lukas Wunner <lukas@wunner.de> wrote: >> Hi Leif, >> >> On Tue, Mar 01, 2016 at 04:42:18PM +0100, Leif Liddy wrote: >>> Do you know how I could print out the the name or id of the ACPI >>> device from the acpi_device pointer? >> >> printk("acpi_dev_name=%s\n", acpi_dev_name(adev)); >> >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/linux/acpi.h#n83 >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/acpi/acpi_bus.h#n354 >> >> Best regards, >> >> Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-02 3:13 ` Leif Liddy @ 2016-03-02 11:42 ` Lukas Wunner 2016-03-02 13:07 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Lukas Wunner @ 2016-03-02 11:42 UTC (permalink / raw) To: Leif Liddy; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula Hi, On Wed, Mar 02, 2016 at 04:13:16AM +0100, Leif Liddy wrote: > I'll post more tomorrow, need to evaluate the changes I made --but I > think the change that did it was changing this: > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > If (!OSDW ()) > { > Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ > } > > Return (ConcatenateResTemplate (RBUF, DBUF)) > } > > to: > > Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > { > Return (ConcatenateResTemplate (RBUF, DBUF)) > } If that is true then the fix is to change the OS we're reporting to ACPI: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c#n141 We had trouble with this before: https://mjg59.dreamwidth.org/29954.html I've just grabbed the acpidump you've posted here: https://bugzilla.kernel.org/attachment.cgi?id=200961&action=edit I'll take a look at it hopefully this afternoon to see what they've changed in the OSDW method. Thanks a lot for your perseverance in tackling this issue. Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-02 11:42 ` Lukas Wunner @ 2016-03-02 13:07 ` Leif Liddy 2016-03-02 14:37 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-02 13:07 UTC (permalink / raw) To: Lukas Wunner; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula You're right, it's not evaluating the OSDW method properly. I tracked it down to this single change: change this: If (!OSDW ()) { Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ } Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ } to: Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ On Wed, Mar 2, 2016 at 12:42 PM, Lukas Wunner <lukas@wunner.de> wrote: > Hi, > > On Wed, Mar 02, 2016 at 04:13:16AM +0100, Leif Liddy wrote: >> I'll post more tomorrow, need to evaluate the changes I made --but I >> think the change that did it was changing this: >> >> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >> { >> If (!OSDW ()) >> { >> Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ >> } >> >> Return (ConcatenateResTemplate (RBUF, DBUF)) >> } >> >> to: >> >> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >> { >> Return (ConcatenateResTemplate (RBUF, DBUF)) >> } > > If that is true then the fix is to change the OS we're reporting to ACPI: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c#n141 > > We had trouble with this before: > https://mjg59.dreamwidth.org/29954.html > > I've just grabbed the acpidump you've posted here: > https://bugzilla.kernel.org/attachment.cgi?id=200961&action=edit > > I'll take a look at it hopefully this afternoon to see what they've > changed in the OSDW method. > > Thanks a lot for your perseverance in tackling this issue. > > Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-02 13:07 ` Leif Liddy @ 2016-03-02 14:37 ` Leif Liddy 2016-03-03 11:47 ` Lukas Wunner 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-02 14:37 UTC (permalink / raw) To: Lukas Wunner; +Cc: Mika Westerberg, linux-acpi, jarkko.nikula This issue is more easily resolved by just changing !OSDW to OSDW for that method. The default behavior it seems is for Linux to identify itself as OSX, but there are a few methods where we don't want to identify as being OSX. I'll try and come up with a list of methods of where we don't want to identify as being OSX. On Wed, Mar 2, 2016 at 2:07 PM, Leif Liddy <leif.linux@gmail.com> wrote: > You're right, it's not evaluating the OSDW method properly. I tracked > it down to this single change: > > change this: > > If (!OSDW ()) > { > Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ > } > Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ > } > > to: > > Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ > > > On Wed, Mar 2, 2016 at 12:42 PM, Lukas Wunner <lukas@wunner.de> wrote: >> Hi, >> >> On Wed, Mar 02, 2016 at 04:13:16AM +0100, Leif Liddy wrote: >>> I'll post more tomorrow, need to evaluate the changes I made --but I >>> think the change that did it was changing this: >>> >>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >>> { >>> If (!OSDW ()) >>> { >>> Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ >>> } >>> >>> Return (ConcatenateResTemplate (RBUF, DBUF)) >>> } >>> >>> to: >>> >>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >>> { >>> Return (ConcatenateResTemplate (RBUF, DBUF)) >>> } >> >> If that is true then the fix is to change the OS we're reporting to ACPI: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c#n141 >> >> We had trouble with this before: >> https://mjg59.dreamwidth.org/29954.html >> >> I've just grabbed the acpidump you've posted here: >> https://bugzilla.kernel.org/attachment.cgi?id=200961&action=edit >> >> I'll take a look at it hopefully this afternoon to see what they've >> changed in the OSDW method. >> >> Thanks a lot for your perseverance in tackling this issue. >> >> Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-02 14:37 ` Leif Liddy @ 2016-03-03 11:47 ` Lukas Wunner [not found] ` <20160303114740.GA24132-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Lukas Wunner @ 2016-03-03 11:47 UTC (permalink / raw) To: Leif Liddy Cc: Mika Westerberg, linux-acpi, jarkko.nikula, Matthew Garrett, linux-spi [Cc: += Matthew Garrett, linux-spi] Hi Leif, On Wed, Mar 02, 2016 at 03:37:27PM +0100, Leif Liddy wrote: > On Wed, Mar 2, 2016 at 2:07 PM, Leif Liddy <leif.linux@gmail.com> wrote: > > On Wed, Mar 2, 2016 at 12:42 PM, Lukas Wunner <lukas@wunner.de> wrote: > >> On Wed, Mar 02, 2016 at 04:13:16AM +0100, Leif Liddy wrote: > >>> I'll post more tomorrow, need to evaluate the changes I made --but I > >>> think the change that did it was changing this: > >>> > >>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > >>> { > >>> If (!OSDW ()) > >>> { > >>> Return (WBUF) /* \_SB_.PCI0.SPI1.WBUF */ > >>> } > >>> > >>> Return (ConcatenateResTemplate (RBUF, DBUF)) > >>> } > >>> > >>> to: > >>> > >>> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings > >>> { > >>> Return (ConcatenateResTemplate (RBUF, DBUF)) > >>> } > >> > >> If that is true then the fix is to change the OS we're reporting to ACPI: > >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/acpi/osl.c#n141 > >> > >> We had trouble with this before: > >> https://mjg59.dreamwidth.org/29954.html > >> > >> I've just grabbed the acpidump you've posted here: > >> https://bugzilla.kernel.org/attachment.cgi?id=200961&action=edit > >> > >> I'll take a look at it hopefully this afternoon to see what they've > >> changed in the OSDW method. > >> > > You're right, it's not evaluating the OSDW method properly. I tracked > > it down to this single change: > > > > change this: > > > > If (!OSDW ()) > > { > > Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ > > } > > Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ > > } > > > > to: > > > > Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ > > > This issue is more easily resolved by just changing !OSDW to OSDW for > that method. The default behavior it seems is for Linux to identify > itself as OSX, but there are a few methods where we don't want to > identify as being OSX. I'll try and come up with a list of methods of > where we don't want to identify as being OSX. I'm not aware that it's possible to choose the OS per method. I've compared the \_SB.PCI0._INI method (which sets \OSYS) and the OSDW method (which returns true iff \OSYS == 0x2710 (Darwin)) between your MB8,1 and my MBP9,1 and nothing relevant has changed. However after looking at the DSDT I can explain what's going on: The standard way of describing resource settings is to let _CRS return them. The OS X way of describing resource settings is to let a _DSM return them. If you disassemble AppleACPIPlatform.kext and search for the label gDSM_GET_PROP_UUID, you'll find a UUID that looks like this: a0b5b7c6-1318-441c-b0c9-fe695eaf949b. The kernel extension invokes the _DSM with this UUID for every ACPI device and merges the package it returns into the device's entry in the I/O registry. The SPI driver on OS X then retrieves the settings from the I/O registry. If you boot OS X and invoke "ioreg -l | grep spiSclkPeriod" you should see the value stored in this device's _DSM (0x0000007d). Now the problem is, in the DSDT of your machine, the _CRS method for the SPIT (spi-topcase) device returns a proper ResourceTemplate for non-Darwin OSes (UBUF) and an *empty* ResourceTemplate for Darwin (named ABUF). Conversely the device's _DSM returns zero for non-Darwin OSes and the I/O registry package for Darwin. (Excerpt of the DSDT included below for others following this thread.) Further down in the DSDT, the exact same snafu is present for the Bluetooth resource settings (BCM2E7C, apple-uart-blth). Perhaps on this particular laptop it's better to not masquerade as Darwin at all? On the other hand e.g. in SSDT5 it's apparent that without masquerading as Darwin, the USB controller's _PS0 and _PS3 methods are no-ops, so it looks like it cannot enter low power modes. Quirking SPI and Bluetooth is probably the lesser evil. I think you want to add a quirk to spi.c:acpi_spi_add_device() which checks if acpi_dev_get_resources() returned nothing and the HID of the acpi_device is APP000D: Search the namespace below the acpi_device's handle for _CRS.UBUF (using acpi_get_handle()). If this exists, call acpi_walk_resource_buffer() on it (with the acpi_spi_add_resource callback). You need to somehow convert the acpi_handle to an acpi_buffer, maybe that just involves filling in acpi_buffer->pointer = acpi_handle and somehow determining the length of the resource settings from the handle. Someone more intimately familiar with the layout of the namespace in memory should be able to answer this. Hopefully this will already get you started, if not just ask questions. HTH, Lukas -- cut here -- Scope (\_SB.PCI0.SPI1) { Device (SPIT) { Name (_HID, EisaId ("APP000D")) // _HID: Hardware ID Name (_CID, "apple-spi-topcase") // _CID: Compatible ID ... Method (_CRS, 0, Serialized) // _CRS: Current Resource Settings { Name (UBUF, ResourceTemplate () { SpiSerialBus (0x0000, PolarityLow, FourWireMode, 0x08, ControllerInitiated, 0x007A1200, ClockPolarityLow, ClockPhaseFirst, "\\_SB.PCI0.SPI1", 0x00, ResourceConsumer, , ) Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, ) { 0x0000001E, } }) Name (ABUF, ResourceTemplate () { }) If (LNot (OSDW ())) { Return (UBUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.UBUF */ } Return (ABUF) /* \_SB_.PCI0.SPI1.SPIT._CRS.ABUF */ } ... Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (OSDW ()) { If (LEqual (Arg0, ToUUID ("a0b5b7c6-1318-441c-b0c9-fe695eaf949b"))) { Store (Package (0x10) { "spiSclkPeriod", Buffer (0x08) { 0x7D, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* }....... */ }, "spiWordSize", Buffer (0x08) { 0x08, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "spiBitOrder", Buffer (0x08) { 0x01, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "spiSPO", Buffer (0x08) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "spiSPH", Buffer (0x08) { 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "spiCSDelay", Buffer (0x08) { 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "resetA2RUsec", Buffer (0x08) { 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ }, "resetRecUsec", Buffer (0x08) { 0x0A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* ........ */ } }, Local0) DTGP (Arg0, Arg1, Arg2, Arg3, RefOf (Local0)) Return (Local0) } } Return (0x00) } ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20160303114740.GA24132-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>]
* Re: ACPI SPI slave device [not found] ` <20160303114740.GA24132-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> @ 2016-03-03 17:45 ` Matthew Garrett 2016-03-03 18:55 ` Lukas Wunner 2016-03-03 17:48 ` Matthew Garrett 1 sibling, 1 reply; 24+ messages in thread From: Matthew Garrett @ 2016-03-03 17:45 UTC (permalink / raw) To: Lukas Wunner Cc: Leif Liddy, Mika Westerberg, linux-acpi-u79uwXL29TY76Z2rM5mHXA, jarkko.nikula-VuQAYsv1563Yd54FQh9/CA, linux-spi-u79uwXL29TY76Z2rM5mHXA On Thu, Mar 03, 2016 at 12:47:40PM +0100, Lukas Wunner wrote: > I think you want to add a quirk to spi.c:acpi_spi_add_device() > which checks if acpi_dev_get_resources() returned nothing and > the HID of the acpi_device is APP000D: Search the namespace below > the acpi_device's handle for _CRS.UBUF (using acpi_get_handle()). > If this exists, call acpi_walk_resource_buffer() on it (with the > acpi_spi_add_resource callback). You need to somehow convert the > acpi_handle to an acpi_buffer, maybe that just involves filling in > acpi_buffer->pointer = acpi_handle and somehow determining the > length of the resource settings from the handle. Someone more > intimately familiar with the layout of the namespace in memory > should be able to answer this. Hopefully this will already get > you started, if not just ask questions. If Apple are consistently using this mechanism to define resources, do we want to extend acpi_dev_get_resources to attempt to call the _DSM method as well? -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-03 17:45 ` Matthew Garrett @ 2016-03-03 18:55 ` Lukas Wunner 2016-03-03 19:12 ` Matthew Garrett 0 siblings, 1 reply; 24+ messages in thread From: Lukas Wunner @ 2016-03-03 18:55 UTC (permalink / raw) To: Matthew Garrett Cc: Leif Liddy, Mika Westerberg, linux-acpi, jarkko.nikula, linux-spi Hi Matthew, On Thu, Mar 03, 2016 at 05:45:35PM +0000, Matthew Garrett wrote: > On Thu, Mar 03, 2016 at 12:47:40PM +0100, Lukas Wunner wrote: > > > I think you want to add a quirk to spi.c:acpi_spi_add_device() > > which checks if acpi_dev_get_resources() returned nothing and > > the HID of the acpi_device is APP000D: Search the namespace below > > the acpi_device's handle for _CRS.UBUF (using acpi_get_handle()). > > If this exists, call acpi_walk_resource_buffer() on it (with the > > acpi_spi_add_resource callback). You need to somehow convert the > > acpi_handle to an acpi_buffer, maybe that just involves filling in > > acpi_buffer->pointer = acpi_handle and somehow determining the > > length of the resource settings from the handle. Someone more > > intimately familiar with the layout of the namespace in memory > > should be able to answer this. Hopefully this will already get > > you started, if not just ask questions. > > If Apple are consistently using this mechanism to define resources, do > we want to extend acpi_dev_get_resources to attempt to call the _DSM > method as well? What Apple is doing with their _DSM is functionally equivalent to the _DSD (Device Specific Data) method in the ACPI spec. (Apple isn't using _DSD at all.) We could extend drivers/acpi/property.c:acpi_init_properties() to check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of calling _DSD, call _DSM with Apple's UUID and populate adev->data with that. Or add the properties to the existing data, if any. Then whenever we feel the need we could just retrieve Apple's properties with acpi_dev_get_property(). E.g. in the case of this SPI slave we need to fill in five values of struct spi_device and we would add a quirk for APP000D which retrieves each value via acpi_dev_get_property() instead of acpi_dev_get_resources(). Alternatively we could evaluate the _DSM individually from the quirk and obtain the values we need from the returned package. But being able to get them with acpi_dev_get_property() might be more generic, it's not unlikely that we need to retrieve Apple's properties from other quirks as well. The suggestion I made in my previous e-mail (to fetch UBUF) was probably not so great in terms of maintainability since Apple might change the name of the variable in a future version of the DSDT, or on other machines. Best regards, Lukas ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-03 18:55 ` Lukas Wunner @ 2016-03-03 19:12 ` Matthew Garrett 2016-03-08 14:40 ` Leif Liddy 0 siblings, 1 reply; 24+ messages in thread From: Matthew Garrett @ 2016-03-03 19:12 UTC (permalink / raw) To: Lukas Wunner Cc: Leif Liddy, Mika Westerberg, linux-acpi, jarkko.nikula, linux-spi On Thu, Mar 03, 2016 at 07:55:53PM +0100, Lukas Wunner wrote: > We could extend drivers/acpi/property.c:acpi_init_properties() to > check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of > calling _DSD, call _DSM with Apple's UUID and populate adev->data > with that. Or add the properties to the existing data, if any. Just do it unconditionally, it's cheap. > E.g. in the case of this SPI slave we need to fill in five values > of struct spi_device and we would add a quirk for APP000D which > retrieves each value via acpi_dev_get_property() instead of > acpi_dev_get_resources(). Mm. It'd be nice to avoid having to keep a list of Apple devices - some sort of mapping function might be easier, returning the values from _CRS if they're present or from _DSM/_DSD otherwise? -- Matthew Garrett | mjg59@srcf.ucam.org ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device 2016-03-03 19:12 ` Matthew Garrett @ 2016-03-08 14:40 ` Leif Liddy [not found] ` <CAAbRKOu8UWrn5bhxjrHx5cykFWOChyxr_ZCWK=R4nYCc11cvsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Leif Liddy @ 2016-03-08 14:40 UTC (permalink / raw) To: Matthew Garrett Cc: Lukas Wunner, Mika Westerberg, linux-acpi, jarkko.nikula, linux-spi > We could extend drivers/acpi/property.c:acpi_init_properties() to > check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of > calling _DSD, call _DSM with Apple's UUID and populate adev->data > with that. Or add the properties to the existing data, if any. Lukas, this a bit beyond my skill level at the moment. I'd like to start with something with a bit easier, and then work my way up. Here's how I gather things are supposed to work. The references inside the _DSM method for SPIT device: {spiSclkPeriod, spiWordSize, spiCSDelay....etc} are meant to be parsed out and used as parameters to configure the SPI controller/protocol driver (or not used at all). **that's exactly what i2c-designware-platdrv.c does in configuring the ss_hcnt, ssh_lcnt...etc parameters SPI controllers are relatively simple devices and I'm just going to assume that the default parameters used in spi-pxa2xx are sufficient for now. **I can always manually adjust them later My goal at the moment is just to be able to perform basic connectivity testing with the slave device. The first issue I ran into was that the IRQ assigned to the DMA controller (dw_dmac) was wrong. /proc/interrupts 20: dw_dmac --by default, it's set to 20 21: pxa2xx-spi.0 /proc/interrupts 21: dw_dmac, pxa2xx-spi.0 --should be set to 21 and share IRQ with spi controller IRQ 21 is what is shown in the DSDT table for both the DMA and SPI devices. I think because the DMA controller is called by its PCI ID (dma/dw/pci.c)that's it's not checking ACPI for the IRQ value. modprobe spi_pxa2xx_pci --everything seems to come up fine .... xxx pxa2xx.c setup() tx_thres: 160 tx_hi_thres: 224 rx_thres: 64 xxx pxa2xx.c setup() chip->enable_dma is 1 xxx pxa2xx.c setup() bits_per_word: 8 dma_burst_size: 1 dma_threshold: 1088 spi spi-APP000D:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 pxa2xx-spi pxa2xx-spi.0: registered child spi-APP000D:00 .... I've modified spidev.c to bind to the APP000D slave device. However, when I run spidev_test nothing gets received. ./spidev_test -D /dev/spidev0.0 spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) RX | 00 00 00 00 00 00 00 00 00 00....... **dmesg (prink statements) shows it running through the whole dma transfer transfer process I'm wondering what functions SIEN, SIST, and ISOL methods are meant to perform on the SPIT device (in the DSDT table) --and how to use them. Here's what I got so far: ..................................................... static int spi_hid_probe(struct spi_device *spi) { struct acpi_object_list input; union acpi_object param[1]; acpi_status status; param[0].type = ACPI_TYPE_INTEGER; param[0].integer.value = 0x01; input.count = 1; input.pointer = param; status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "SIEN", &input, NULL); if (ACPI_FAILURE(status)) printk("xxx mb81_spi_probe --ACPI_FAILURE\n"); return 0; } static const struct acpi_device_id spi_hid_acpi_match[] = { { "APP000D", 0 }, { }, }; ... ................................................... If I load & unload this test module --and then run spidev ./spidev_test -D /dev/spidev0.0 -v spi mode: 0x0 bits per word: 8 max speed: 500000 Hz (500 KHz) TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF FF F0 0D | ......@....�..................�. RX | 20 D0 00 00 00 00 04 00 A0 80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | .�......��.................... It changed something.... It looks like SIEN is modifying the GPIO registers, but its function isn't exactly clear. Lukas, can you help me sort out what the purpose of these methods are and how to use them? ----------------------------------------------------------------------------------------------- Method (SIEN, 1, Serialized) { If ((Arg0 <= 0x01)) { If ((Arg0 == 0x01)) { GP13 = 0x01 GD13 = 0x00 } Else { GD13 = 0x01 } } } Method (SIST, 0, Serialized) { Local0 = GD13 /* \GD13 */ If ((Local0 == 0x01)) { Return (GL13) /* \GL13 */ } Else { Return (GP13) /* \GP13 */ } } } Method (ISOL, 1, Serialized) { If ((Arg0 <= 0x01)) { If ((Arg0 == 0x01)) { GP87 = 0x01 GP88 = 0x00 GP89 = 0x00 GP90 = 0x00 GD87 = 0x00 GD88 = 0x00 GD89 = 0x01 GD90 = 0x00 GU87 = 0x01 GU88 = 0x01 GU89 = 0x01 GU90 = 0x01 Local0 = GP87 /* \GP87 */ } Else { GU87 = 0x00 GU88 = 0x00 GU89 = 0x00 GU90 = 0x00 GP87 = 0x00 GP88 = 0x00 GP89 = 0x00 GP90 = 0x00 GD87 = 0x00 GD88 = 0x00 GD89 = 0x00 GD90 = 0x00 Local0 = GU87 /* \GU87 */ } Return (0x00) } Return (0xFFFFFFFF) } } ----------------------------------------------------------------------------------------------- Decoded DSDT table: https://bugzilla.kernel.org/attachment.cgi?id=202141 On Thu, Mar 3, 2016 at 8:12 PM, Matthew Garrett <mjg59@srcf.ucam.org> wrote: > On Thu, Mar 03, 2016 at 07:55:53PM +0100, Lukas Wunner wrote: > >> We could extend drivers/acpi/property.c:acpi_init_properties() to >> check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of >> calling _DSD, call _DSM with Apple's UUID and populate adev->data >> with that. Or add the properties to the existing data, if any. > > Just do it unconditionally, it's cheap. > >> E.g. in the case of this SPI slave we need to fill in five values >> of struct spi_device and we would add a quirk for APP000D which >> retrieves each value via acpi_dev_get_property() instead of >> acpi_dev_get_resources(). > > Mm. It'd be nice to avoid having to keep a list of Apple devices - some > sort of mapping function might be easier, returning the values from _CRS > if they're present or from _DSM/_DSD otherwise? > > -- > Matthew Garrett | mjg59@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <CAAbRKOu8UWrn5bhxjrHx5cykFWOChyxr_ZCWK=R4nYCc11cvsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>]
* Re: ACPI SPI slave device [not found] ` <CAAbRKOu8UWrn5bhxjrHx5cykFWOChyxr_ZCWK=R4nYCc11cvsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> @ 2016-03-09 12:36 ` Lukas Wunner [not found] ` <20160309123625.GA26143-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> 0 siblings, 1 reply; 24+ messages in thread From: Lukas Wunner @ 2016-03-09 12:36 UTC (permalink / raw) To: Leif Liddy Cc: Matthew Garrett, Mika Westerberg, linux-acpi-u79uwXL29TY76Z2rM5mHXA, jarkko.nikula-VuQAYsv1563Yd54FQh9/CA, linux-spi-u79uwXL29TY76Z2rM5mHXA, John Horan, Henrik Rydberg Hi Leif, I went through my collection of MacBook acpidumps and noticed that the MacBookPro12,1 also uses SPI, the DSDT entries are identical (save for some changes in the ISOL method and an additional UIST method). That's the 13" 2015 MacBookPro model. John Horan and Henrik Rydberg added support for that model's keyboard and trackpad with: d58069265c9d ("Input: bcm5974 - add support for the 2015 Macbook Pro") a4a2c54560f2 ("HID: apple: Add support for the 2015 Macbook Pro") efbd34702fb1 ("Input: bcm5974 - prepare for a new trackpad generation") I'm wondering, if the keyboard and trackpad are working on the MBP12,1, why aren't they working on the MB8,1? Adding John and Henrik to cc: in the hope of clarifying this. On Tue, Mar 08, 2016 at 03:40:14PM +0100, Leif Liddy wrote: > > We could extend drivers/acpi/property.c:acpi_init_properties() to > > check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of > > calling _DSD, call _DSM with Apple's UUID and populate adev->data > > with that. Or add the properties to the existing data, if any. > > Lukas, this a bit beyond my skill level at the moment. I'd like to > start with something with a bit easier, and then work my way up. > > Here's how I gather things are supposed to work. > > The references inside the _DSM method for SPIT device: {spiSclkPeriod, > spiWordSize, spiCSDelay....etc} are meant to be parsed out and used as > parameters to configure the SPI controller/protocol driver (or not > used at all). Yes. Call the _DSM method and you'll get back a "package". Basically that's a fancy ACPI term for a struct. You can then retrieve the values out of that package. > My goal at the moment is just to be able to perform basic connectivity > testing with the slave device. > The first issue I ran into was that the IRQ assigned to the DMA > controller (dw_dmac) was wrong. > > /proc/interrupts > 20: dw_dmac --by default, it's set to 20 > 21: pxa2xx-spi.0 > > /proc/interrupts > 21: dw_dmac, pxa2xx-spi.0 --should be set to 21 and share IRQ > with spi controller Hm, according to DSDT the interrupt for APP000D should be 0x1E, i.e. 30. I notice that the interrupt is specified in the device's ResourceTemplate (_CRS.UBUF) but not in the package returned by the _DSM. If we need that value then we cannot solve this by just parsing the values returned by the _DSM. The only option we'd have is to retrieve that UBUF ResourceTemplate. > IRQ 21 is what is shown in the DSDT table for both the DMA and SPI > devices. I think because the DMA controller is called by its PCI ID > (dma/dw/pci.c)that's it's not checking ACPI for the IRQ value. > > modprobe spi_pxa2xx_pci --everything seems to come up fine > > .... > xxx pxa2xx.c setup() tx_thres: 160 tx_hi_thres: 224 rx_thres: 64 > xxx pxa2xx.c setup() chip->enable_dma is 1 > xxx pxa2xx.c setup() bits_per_word: 8 dma_burst_size: 1 dma_threshold: 1088 > spi spi-APP000D:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 > pxa2xx-spi pxa2xx-spi.0: registered child spi-APP000D:00 > .... > > I've modified spidev.c to bind to the APP000D slave device. However, > when I run spidev_test nothing gets received. > > ./spidev_test -D /dev/spidev0.0 > > spi mode: 0x0 > bits per word: 8 > max speed: 500000 Hz (500 KHz) > RX | 00 00 00 00 00 00 00 00 00 00....... > > **dmesg (prink statements) shows it running through the whole dma > transfer transfer process > > I'm wondering what functions SIEN, SIST, and ISOL methods are meant to > perform on the SPIT device (in the DSDT table) --and how to use them. If you grep /System/Library/Extensions on OS X for these strings you'll find the SPI drivers. Disassemble those and you'll find these methods are called in the following functions: ISOL gets called in AppleIntelLpssGspi.kext from AppleIntelLpssGspi::gpioConfig() AppleIntelLpssGspi::initGspiGpio() SIEN gets called in AppleIntelLpssSpiController.kext from AppleIntelLpssSpiController::_setSPIBusDeviceEnable() SIEN, SIST und UIST in the same kext from: AppleIntelLpssSpiController::getSpiDevices() Apple often uses nonstandard ACPI methods like this for power management, i.e. to power a chip up and down and query its status. SIEN takes one argument which can be 1 or 0 and modifies GPIO pin 13. You'd need the schematics of the mainboard to know what this pin is connected to but this might be a power switch which powers the SPI controller up and down. So the "EN" in "SIEN" might stand for "enable", which matches with the function it's called from (_setSPIBusDeviceEnable). Likewise SIST returns the status of GPIO pin 13 so the "ST" might stand for "status". I don't know what ISOL does. "Isolation" maybe? This also modifies a few GPIO registers. And UIST ist only present in the MBP12,1 DSDT, it returns the status of GPIO pin 26. HTH, Lukas > Here's what I got so far: > > ..................................................... > static int spi_hid_probe(struct spi_device *spi) > { > struct acpi_object_list input; > union acpi_object param[1]; > acpi_status status; > param[0].type = ACPI_TYPE_INTEGER; > param[0].integer.value = 0x01; > input.count = 1; > input.pointer = param; > > status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "SIEN", > &input, NULL); > if (ACPI_FAILURE(status)) > printk("xxx mb81_spi_probe --ACPI_FAILURE\n"); > > return 0; > } > > > static const struct acpi_device_id spi_hid_acpi_match[] = { > { "APP000D", 0 }, > { }, > }; > ... > ................................................... > > If I load & unload this test module --and then run spidev > > ./spidev_test -D /dev/spidev0.0 -v > spi mode: 0x0 > bits per word: 8 > max speed: 500000 Hz (500 KHz) > TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF > FF FF FF FF FF FF FF FF F0 0D | ......@....???..................???. > RX | 20 D0 00 00 00 00 04 00 A0 80 00 00 00 00 00 00 00 00 00 00 00 00 > 00 00 00 00 00 00 00 00 00 00 | .???......??????.................... > > It changed something.... > It looks like SIEN is modifying the GPIO registers, but its function > isn't exactly clear. > > > Lukas, can you help me sort out what the purpose of these methods are > and how to use them? > > ----------------------------------------------------------------------------------------------- > > Method (SIEN, 1, Serialized) > { > If ((Arg0 <= 0x01)) > { > If ((Arg0 == 0x01)) > { > GP13 = 0x01 > GD13 = 0x00 > } > Else > { > GD13 = 0x01 > } > } > } > > Method (SIST, 0, Serialized) > { > Local0 = GD13 /* \GD13 */ > If ((Local0 == 0x01)) > { > Return (GL13) /* \GL13 */ > } > Else > { > Return (GP13) /* \GP13 */ > } > } > } > > Method (ISOL, 1, Serialized) > { > If ((Arg0 <= 0x01)) > { > If ((Arg0 == 0x01)) > { > GP87 = 0x01 > GP88 = 0x00 > GP89 = 0x00 > GP90 = 0x00 > GD87 = 0x00 > GD88 = 0x00 > GD89 = 0x01 > GD90 = 0x00 > GU87 = 0x01 > GU88 = 0x01 > GU89 = 0x01 > GU90 = 0x01 > Local0 = GP87 /* \GP87 */ > } > Else > { > GU87 = 0x00 > GU88 = 0x00 > GU89 = 0x00 > GU90 = 0x00 > GP87 = 0x00 > GP88 = 0x00 > GP89 = 0x00 > GP90 = 0x00 > GD87 = 0x00 > GD88 = 0x00 > GD89 = 0x00 > GD90 = 0x00 > Local0 = GU87 /* \GU87 */ > } > > Return (0x00) > } > > Return (0xFFFFFFFF) > } > } > > ----------------------------------------------------------------------------------------------- > > Decoded DSDT table: > https://bugzilla.kernel.org/attachment.cgi?id=202141 > > On Thu, Mar 3, 2016 at 8:12 PM, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> wrote: > > On Thu, Mar 03, 2016 at 07:55:53PM +0100, Lukas Wunner wrote: > > > >> We could extend drivers/acpi/property.c:acpi_init_properties() to > >> check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of > >> calling _DSD, call _DSM with Apple's UUID and populate adev->data > >> with that. Or add the properties to the existing data, if any. > > > > Just do it unconditionally, it's cheap. > > > >> E.g. in the case of this SPI slave we need to fill in five values > >> of struct spi_device and we would add a quirk for APP000D which > >> retrieves each value via acpi_dev_get_property() instead of > >> acpi_dev_get_resources(). > > > > Mm. It'd be nice to avoid having to keep a list of Apple devices - some > > sort of mapping function might be easier, returning the values from _CRS > > if they're present or from _DSM/_DSD otherwise? > > > > -- > > Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
[parent not found: <20160309123625.GA26143-JFq808J9C/izQB+pC5nmwQ@public.gmane.org>]
* Re: ACPI SPI slave device [not found] ` <20160309123625.GA26143-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> @ 2016-03-10 18:12 ` Leif Liddy 0 siblings, 0 replies; 24+ messages in thread From: Leif Liddy @ 2016-03-10 18:12 UTC (permalink / raw) To: Lukas Wunner Cc: Matthew Garrett, Mika Westerberg, linux-acpi-u79uwXL29TY76Z2rM5mHXA, jarkko.nikula-VuQAYsv1563Yd54FQh9/CA, linux-spi-u79uwXL29TY76Z2rM5mHXA, John Horan, Henrik Rydberg > I'm wondering, if the keyboard and trackpad are working on the MBP12,1, > why aren't they working on the MB8,1? this issue has been brought up before: http://www.spinics.net/lists/linux-acpi/msg61848.html It sounds like the MBP12,1 models have a way to access the keyboard/trackpad via USB and SPI OSX identifies the keyboard/trackpad on the MB8,1 as "Product" = "Apple Internal Keyboard / Trackpad" "ProductID" = 0x272 https://bugzilla.kernel.org/attachment.cgi?id=201111 **that is same device id as the MBP12,1 keyboard/trackpad, which is referenced in a few kernel device drivers as: USB_DEVICE_ID_APPLE_WELLSPRING9_ANSI 0x0272 OSX appears to be binding an HID driver to the slave device via an SPI transport driver. there's no SPI transport driver for linux (yet??) https://www.kernel.org/doc/Documentation/hid/hid-transport.txt In any case I'd still like to try and make some progress on this --it's a good learning experience DSDT shows the following (named gpio's???) being assigned to the SPI master "gspi-pin-cs", Buffer (0x08) { 0x57, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* W....... */ }, "gspi-pin-clk", Buffer (0x08) { 0x58, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* X....... */ }, "gspi-pin-mosi", Buffer (0x08) { 0x59, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* Y....... */ }, "gspi-pin-miso", Buffer (0x08) { 0x5A, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00 /* Z....... */ } I'm trying to sort out what these values represent and how to use them. My guess is that they function as gpio's, although this is not the standard format of passing this sort of information. The config I'm using for the controller in spi-pxa2xx.c is { /* LPSS_LPT_SSP */ .offset = 0x800, .reg_general = 0x08, .reg_ssp = 0x0c, .reg_cs_ctrl = 0x18, .reg_capabilities = -1, } **presumably it should be finding the parameters for controlling the device from these memory locations. **ACPI ID of controller INT33C1 matches this config **In any case I'm going to spend the next couple of weeks deconstructing this driver... > Hm, according to DSDT the interrupt for APP000D should be 0x1E, i.e. 30. I was referring to that fact that the SPI controller and the DMA controller (and I2C1 and UART0) all share the same interrupt. If the two controllers don't share the same IRQ, then no communication will occur between the two controllers I ran some basic DMA tests to highlight this: https://bugzilla.kernel.org/attachment.cgi?id=207871 I don't think I need to worry about about the IRQ of the slave device just yet, I don't *believe* that comes into play when using spidev + DMA + spidev_test. **I've modified the DSDT tables so that UBUF is returned.. [ 39.509846] xxx spi.c acpi_spi_add_resource :if (acpi_dev_resource_interrupt(ares, 0, &r)) [ 39.509849] xxx spi.c acpi_spi_add_resource spi->irq = r.start --is equal to 30 [ 39.509851] xxx spi.c acpi_spi_add_resource --start [ 39.509853] xxx spi.c spi->irq = 30 [ 39.509856] xxx resource.c acpi_dev_get_resources acpi_dev_name=APP000D:00 [ 39.509859] xxx resource.c acpi_handle is ffff8802650be000 returns c.count 0... [ 39.509864] xxx spi.c acpi_spi_add_device :spi->max_speed_hz is 8000000 > If you grep /System/Library/Extensions on OS X for these strings you'll > find the SPI drivers. Disassemble those and you'll find these methods are > called in the following functions: Thanks for sharing that...really useful!!! -Leif On Wed, Mar 9, 2016 at 1:36 PM, Lukas Wunner <lukas-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> wrote: > Hi Leif, > > I went through my collection of MacBook acpidumps and noticed that the > MacBookPro12,1 also uses SPI, the DSDT entries are identical (save for > some changes in the ISOL method and an additional UIST method). That's > the 13" 2015 MacBookPro model. > > John Horan and Henrik Rydberg added support for that model's keyboard > and trackpad with: > d58069265c9d ("Input: bcm5974 - add support for the 2015 Macbook Pro") > a4a2c54560f2 ("HID: apple: Add support for the 2015 Macbook Pro") > efbd34702fb1 ("Input: bcm5974 - prepare for a new trackpad generation") > > I'm wondering, if the keyboard and trackpad are working on the MBP12,1, > why aren't they working on the MB8,1? Adding John and Henrik to cc: in > the hope of clarifying this. > > > On Tue, Mar 08, 2016 at 03:40:14PM +0100, Leif Liddy wrote: >> > We could extend drivers/acpi/property.c:acpi_init_properties() to >> > check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of >> > calling _DSD, call _DSM with Apple's UUID and populate adev->data >> > with that. Or add the properties to the existing data, if any. >> >> Lukas, this a bit beyond my skill level at the moment. I'd like to >> start with something with a bit easier, and then work my way up. >> >> Here's how I gather things are supposed to work. >> >> The references inside the _DSM method for SPIT device: {spiSclkPeriod, >> spiWordSize, spiCSDelay....etc} are meant to be parsed out and used as >> parameters to configure the SPI controller/protocol driver (or not >> used at all). > > Yes. Call the _DSM method and you'll get back a "package". Basically > that's a fancy ACPI term for a struct. You can then retrieve the values > out of that package. > > >> My goal at the moment is just to be able to perform basic connectivity >> testing with the slave device. >> The first issue I ran into was that the IRQ assigned to the DMA >> controller (dw_dmac) was wrong. >> >> /proc/interrupts >> 20: dw_dmac --by default, it's set to 20 >> 21: pxa2xx-spi.0 >> >> /proc/interrupts >> 21: dw_dmac, pxa2xx-spi.0 --should be set to 21 and share IRQ >> with spi controller > > Hm, according to DSDT the interrupt for APP000D should be 0x1E, i.e. 30. > > I notice that the interrupt is specified in the device's ResourceTemplate > (_CRS.UBUF) but not in the package returned by the _DSM. If we need that > value then we cannot solve this by just parsing the values returned by the > _DSM. The only option we'd have is to retrieve that UBUF ResourceTemplate. > > >> IRQ 21 is what is shown in the DSDT table for both the DMA and SPI >> devices. I think because the DMA controller is called by its PCI ID >> (dma/dw/pci.c)that's it's not checking ACPI for the IRQ value. >> >> modprobe spi_pxa2xx_pci --everything seems to come up fine >> >> .... >> xxx pxa2xx.c setup() tx_thres: 160 tx_hi_thres: 224 rx_thres: 64 >> xxx pxa2xx.c setup() chip->enable_dma is 1 >> xxx pxa2xx.c setup() bits_per_word: 8 dma_burst_size: 1 dma_threshold: 1088 >> spi spi-APP000D:00: setup mode 0, 8 bits/w, 8000000 Hz max --> 0 >> pxa2xx-spi pxa2xx-spi.0: registered child spi-APP000D:00 >> .... >> >> I've modified spidev.c to bind to the APP000D slave device. However, >> when I run spidev_test nothing gets received. >> >> ./spidev_test -D /dev/spidev0.0 >> >> spi mode: 0x0 >> bits per word: 8 >> max speed: 500000 Hz (500 KHz) >> RX | 00 00 00 00 00 00 00 00 00 00....... >> >> **dmesg (prink statements) shows it running through the whole dma >> transfer transfer process >> >> I'm wondering what functions SIEN, SIST, and ISOL methods are meant to >> perform on the SPIT device (in the DSDT table) --and how to use them. > > If you grep /System/Library/Extensions on OS X for these strings you'll > find the SPI drivers. Disassemble those and you'll find these methods are > called in the following functions: > > ISOL gets called in AppleIntelLpssGspi.kext from > AppleIntelLpssGspi::gpioConfig() > AppleIntelLpssGspi::initGspiGpio() > SIEN gets called in AppleIntelLpssSpiController.kext from > AppleIntelLpssSpiController::_setSPIBusDeviceEnable() > SIEN, SIST und UIST in the same kext from: > AppleIntelLpssSpiController::getSpiDevices() > > Apple often uses nonstandard ACPI methods like this for power management, > i.e. to power a chip up and down and query its status. SIEN takes one > argument which can be 1 or 0 and modifies GPIO pin 13. You'd need the > schematics of the mainboard to know what this pin is connected to but > this might be a power switch which powers the SPI controller up and down. > So the "EN" in "SIEN" might stand for "enable", which matches with the > function it's called from (_setSPIBusDeviceEnable). Likewise SIST returns > the status of GPIO pin 13 so the "ST" might stand for "status". > > I don't know what ISOL does. "Isolation" maybe? This also modifies a few > GPIO registers. And UIST ist only present in the MBP12,1 DSDT, it returns > the status of GPIO pin 26. > > HTH, > > Lukas > >> Here's what I got so far: >> >> ..................................................... >> static int spi_hid_probe(struct spi_device *spi) >> { >> struct acpi_object_list input; >> union acpi_object param[1]; >> acpi_status status; >> param[0].type = ACPI_TYPE_INTEGER; >> param[0].integer.value = 0x01; >> input.count = 1; >> input.pointer = param; >> >> status = acpi_evaluate_object(ACPI_HANDLE(&spi->dev), "SIEN", >> &input, NULL); >> if (ACPI_FAILURE(status)) >> printk("xxx mb81_spi_probe --ACPI_FAILURE\n"); >> >> return 0; >> } >> >> >> static const struct acpi_device_id spi_hid_acpi_match[] = { >> { "APP000D", 0 }, >> { }, >> }; >> ... >> ................................................... >> >> If I load & unload this test module --and then run spidev >> >> ./spidev_test -D /dev/spidev0.0 -v >> spi mode: 0x0 >> bits per word: 8 >> max speed: 500000 Hz (500 KHz) >> TX | FF FF FF FF FF FF 40 00 00 00 00 95 FF FF FF FF FF FF FF FF FF FF >> FF FF FF FF FF FF FF FF F0 0D | ......@....???..................???. >> RX | 20 D0 00 00 00 00 04 00 A0 80 00 00 00 00 00 00 00 00 00 00 00 00 >> 00 00 00 00 00 00 00 00 00 00 | .???......??????.................... >> >> It changed something.... >> It looks like SIEN is modifying the GPIO registers, but its function >> isn't exactly clear. >> >> >> Lukas, can you help me sort out what the purpose of these methods are >> and how to use them? >> >> ----------------------------------------------------------------------------------------------- >> >> Method (SIEN, 1, Serialized) >> { >> If ((Arg0 <= 0x01)) >> { >> If ((Arg0 == 0x01)) >> { >> GP13 = 0x01 >> GD13 = 0x00 >> } >> Else >> { >> GD13 = 0x01 >> } >> } >> } >> >> Method (SIST, 0, Serialized) >> { >> Local0 = GD13 /* \GD13 */ >> If ((Local0 == 0x01)) >> { >> Return (GL13) /* \GL13 */ >> } >> Else >> { >> Return (GP13) /* \GP13 */ >> } >> } >> } >> >> Method (ISOL, 1, Serialized) >> { >> If ((Arg0 <= 0x01)) >> { >> If ((Arg0 == 0x01)) >> { >> GP87 = 0x01 >> GP88 = 0x00 >> GP89 = 0x00 >> GP90 = 0x00 >> GD87 = 0x00 >> GD88 = 0x00 >> GD89 = 0x01 >> GD90 = 0x00 >> GU87 = 0x01 >> GU88 = 0x01 >> GU89 = 0x01 >> GU90 = 0x01 >> Local0 = GP87 /* \GP87 */ >> } >> Else >> { >> GU87 = 0x00 >> GU88 = 0x00 >> GU89 = 0x00 >> GU90 = 0x00 >> GP87 = 0x00 >> GP88 = 0x00 >> GP89 = 0x00 >> GP90 = 0x00 >> GD87 = 0x00 >> GD88 = 0x00 >> GD89 = 0x00 >> GD90 = 0x00 >> Local0 = GU87 /* \GU87 */ >> } >> >> Return (0x00) >> } >> >> Return (0xFFFFFFFF) >> } >> } >> >> ----------------------------------------------------------------------------------------------- >> >> Decoded DSDT table: >> https://bugzilla.kernel.org/attachment.cgi?id=202141 >> >> On Thu, Mar 3, 2016 at 8:12 PM, Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org> wrote: >> > On Thu, Mar 03, 2016 at 07:55:53PM +0100, Lukas Wunner wrote: >> > >> >> We could extend drivers/acpi/property.c:acpi_init_properties() to >> >> check if dmi_match(DMI_BOARD_VENDOR, "Apple Inc."), and instead of >> >> calling _DSD, call _DSM with Apple's UUID and populate adev->data >> >> with that. Or add the properties to the existing data, if any. >> > >> > Just do it unconditionally, it's cheap. >> > >> >> E.g. in the case of this SPI slave we need to fill in five values >> >> of struct spi_device and we would add a quirk for APP000D which >> >> retrieves each value via acpi_dev_get_property() instead of >> >> acpi_dev_get_resources(). >> > >> > Mm. It'd be nice to avoid having to keep a list of Apple devices - some >> > sort of mapping function might be easier, returning the values from _CRS >> > if they're present or from _DSM/_DSD otherwise? >> > >> > -- >> > Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org > -- > To unsubscribe from this list: send the line "unsubscribe linux-spi" in > the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: ACPI SPI slave device [not found] ` <20160303114740.GA24132-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> 2016-03-03 17:45 ` Matthew Garrett @ 2016-03-03 17:48 ` Matthew Garrett 1 sibling, 0 replies; 24+ messages in thread From: Matthew Garrett @ 2016-03-03 17:48 UTC (permalink / raw) To: Lukas Wunner Cc: Leif Liddy, Mika Westerberg, linux-acpi-u79uwXL29TY76Z2rM5mHXA, jarkko.nikula-VuQAYsv1563Yd54FQh9/CA, linux-spi-u79uwXL29TY76Z2rM5mHXA Oh, sorry, I see - it's a little more complicated than that. Bleah. I still think we probably want to do this at the core level rather than having the driver special-case things based on the HID, but it's clearly going to need some knowledge of the device type to parse Apple's data into something consistent with the spec. -- Matthew Garrett | mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
* ACPI: SPI slave device @ 2016-02-22 19:37 Leif Liddy 0 siblings, 0 replies; 24+ messages in thread From: Leif Liddy @ 2016-02-22 19:37 UTC (permalink / raw) To: linux-acpi I'm extremely new to kernel development, and I'm reaching out to the ACPI community in an effort to gain a better understanding of the issue I'm experiencing. The macbook8,1 (early 2015) has a keyboard/trackpad that is seen by ACPI as a single SPI slave device. The appears the only method the access the keyboard/trackpad is via the SPI bus, and that's what I'm trying to get working. I've recently submitted a kernel patch that binds the spi-pxa2xx driver to the Wildcat Point-LP Serial IO GSPI Controller. With this patch, the SPI controller appears to be working. http://www.spinics.net/lists/linux-spi/msg06867.html ----------LSHW INFO------------ *-serial:1 description: Serial bus controller product: Wildcat Point-LP Serial IO GSPI Controller #1 vendor: Intel Corporation physical id: 15.4 bus info: pci@0000:00:15.4 version: 03 width: 32 bits clock: 33MHz capabilities: pm cap_list configuration: driver=pxa2xx_spi_pci latency=0 resources: irq:21 memory:c181a000-c181afff I'm now attempting to write an SPI protocol driver, but I have no idea on how to reference the SPI slave device as it only exists in the ACPI name space. I'm not sure if I should be using a platform or an acpi driver to register/enable it. –------------UDEV INFO--------------- P: /devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 E: DEVPATH=/devices/LNXSYSTM:00/LNXSYBUS:00/PNP0A08:00/INT33C1:00/APP000D:00 E: ID_VENDOR_FROM_DATABASE=Apple Computer Inc E: MODALIAS=acpi:APP000D:APPLE-SPI-TOPCASE: E: SUBSYSTEM=acpi E: USEC_INITIALIZED=13574842 **INT33C1 is the SPI master controller **APP000D is the slave device The ACPI DSDT table (decoded): https://bugzilla.kernel.org/attachment.cgi?id=202141 The full bug report: https://bugzilla.kernel.org/show_bug.cgi?id=108331 Any help no matter how brief would be useful. Thanks, Leif Liddy -- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html ^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2016-03-10 18:12 UTC | newest] Thread overview: 24+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2016-02-23 1:54 ACPI SPI slave device Leif Liddy 2016-02-23 7:38 ` Mika Westerberg 2016-02-23 14:18 ` Leif Liddy 2016-02-23 15:02 ` Mika Westerberg 2016-02-23 15:32 ` Mika Westerberg 2016-02-23 20:30 ` Leif Liddy 2016-02-29 8:21 ` Mika Westerberg 2016-02-29 17:21 ` Leif Liddy 2016-03-01 15:42 ` Leif Liddy 2016-03-01 16:07 ` Lukas Wunner 2016-03-01 23:33 ` Leif Liddy 2016-03-02 3:13 ` Leif Liddy 2016-03-02 11:42 ` Lukas Wunner 2016-03-02 13:07 ` Leif Liddy 2016-03-02 14:37 ` Leif Liddy 2016-03-03 11:47 ` Lukas Wunner [not found] ` <20160303114740.GA24132-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> 2016-03-03 17:45 ` Matthew Garrett 2016-03-03 18:55 ` Lukas Wunner 2016-03-03 19:12 ` Matthew Garrett 2016-03-08 14:40 ` Leif Liddy [not found] ` <CAAbRKOu8UWrn5bhxjrHx5cykFWOChyxr_ZCWK=R4nYCc11cvsw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org> 2016-03-09 12:36 ` Lukas Wunner [not found] ` <20160309123625.GA26143-JFq808J9C/izQB+pC5nmwQ@public.gmane.org> 2016-03-10 18:12 ` Leif Liddy 2016-03-03 17:48 ` Matthew Garrett -- strict thread matches above, loose matches on Subject: below -- 2016-02-22 19:37 ACPI: " Leif Liddy
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.