> Date: Mon, 28 Mar 2016 21:49:39 +1100 > From: Jonathan Gray <[email protected]> > > On Sun, Mar 27, 2016 at 09:28:25PM +0200, Mark Kettenis wrote: > > The diff below is a first stab at adding support for GPIOs as defined > > in ACPI 5.0. The primary target for this new ACPI feature is hardware > > reduced platforms like those based on Intel's Bay Trail SoC. The diff > > adds a bytgpio(4) driver for the hardware found on that SoC. This > > driver registers itself with the acpi framework by setting the struct > > acpi_gpio pointer on the AML node for the device. Then this gets used > > by the acpi sdhc(4) frontend to use the appropriate gpio as the card > > detect signal. This makes it possible to detectwhether a card is > > inserted when the kernel boots. Support for GPIO-based interrupts is > > still missing, so hotplugging SD cards doesn't work yet. > > > > There are some debug printfs here that will disappear eventually. > > > > ok? > > Works on ideapad 100s: > > bytgpio0 at acpi0: GPO0 uid 1 addr 0xfed0c000/0x1000 irq 49, 102 pins > bytgpio1 at acpi0: GPO1 uid 2 addr 0xfed0d000/0x1000 irq 48, 28 pins > bytgpio2 at acpi0: GPO2 uid 3 addr 0xfed0e000/0x1000 irq 50, 44 pins > sdhc0 at acpi0: SDHA addr 0x9091d000/0x1000 irq 44 > sdmmc0 at sdhc0 > sdhc at acpi0 not configured > sdhc1 at acpi0: SDHD GPO0 pin 38 > tflags 0x1d > ppi 0x3 > drs 0x0 > dbt 0x2710 > GPO0 pin 38 > tflags 0x9 > ppi 0x0 > drs 0x0 > dbt 0x0 > addr 0x90903000/0x1000 irq 47 > sdmmc1 at sdhc1 > > ... > > scsibus1 at sdmmc0: 2 targets, initiator 0 > sd0 at scsibus1 targ 1 lun 0: <SD/MMC, Drive #01, > SCSI2 0/direct fixed > sd0: 29820MB, 512 bytes/sector, 61071360 sectors > scsibus2 at sdmmc1: 2 targets, initiator 0 > sd1 at scsibus2 targ 1 lun 0: <SD/MMC, Drive #01, > SCSI2 0/direct fixed > sd1: 15271MB, 512 bytes/sector, 31275008 sectors > > sdmmc0 is emmc sdmmc1 is a usd card in the slot. > > Though after some network traffic over usb the machine seems to hang. > Opening new windows in tmux over ssh works but shells don't spawn. > I can still type locally (with the polling diff) but can't login on tty. > > Is it possible this somehow enables gpio interrupts that we then > don't acknowledge?
I don't think so. Given the symptoms I'd say it is more likely that the sdmmc interrupt gets stuck.
