Re: Fix level-triggered ACPI GPIO interrupts on amd64
Hi Peter, * Peter Hessler wrote: > This was committed on Oct 20, and was shipped in OpenBSD 7.2. Indeed, you're quite right, thanks for the info! Since my touchpad hangs haven't improved since then it is unrelated to the change and I must be mistaken while testing. Cheers Matthias
Re: Fix level-triggered ACPI GPIO interrupts on amd64
This was committed on Oct 20, and was shipped in OpenBSD 7.2.
On 2023 Jan 05 (Thu) at 14:15:26 +0100 (+0100), Matthias Schmidt wrote:
:Hi,
:
:did anyone else on the list had the chance to test this patch? It
:really improved the touchpad hangs here.
:
:Cheers
:
: Matthias
:
:* Mark Kettenis wrote:
:> > Date: Thu, 13 Oct 2022 00:17:37 +0200
:> > From: Mark Kettenis
:> >
:> > > Date: Mon, 10 Oct 2022 17:02:41 +0200
:> > > From: Matthias Schmidt
:> > >
:> > > * Matthias Schmidt wrote:
:> > > > Hi Mark,
:> > > >
:> > > > Addendum after 24h of testing. Your patch fixes the frequent touchpad
:> > > > freezes I see on this model and which I reported back then in
:> > > > https://marc.info/?l=openbsd-bugs=165328803822857=2
:> > >
:> > > Any chance that this patch gets committed or wider testing in snaps?
:> > > It really improved the touchpad situation here.
:> >
:> > Right, I should probably just commit the diff instead of waiting for
:> > more tests.
:> >
:> > ok?
:>
:> For reference, here is the diff again.
:>
:>
:> Index: dev/acpi/amdgpio.c
:> ===
:> RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
:> retrieving revision 1.9
:> diff -u -p -r1.9 amdgpio.c
:> --- dev/acpi/amdgpio.c 27 Jun 2022 08:00:31 - 1.9
:> +++ dev/acpi/amdgpio.c 3 Oct 2022 19:10:03 -
:> @@ -92,6 +92,8 @@ const char *amdgpio_hids[] = {
:> int amdgpio_read_pin(void *, int);
:> voidamdgpio_write_pin(void *, int, int);
:> voidamdgpio_intr_establish(void *, int, int, int (*)(void *), void
*);
:> +voidamdgpio_intr_enable(void *, int);
:> +voidamdgpio_intr_disable(void *, int);
:> int amdgpio_pin_intr(struct amdgpio_softc *, int);
:> int amdgpio_intr(void *);
:> voidamdgpio_save_pin(struct amdgpio_softc *, int pin);
:> @@ -163,6 +165,8 @@ amdgpio_attach(struct device *parent, st
:> sc->sc_gpio.read_pin = amdgpio_read_pin;
:> sc->sc_gpio.write_pin = amdgpio_write_pin;
:> sc->sc_gpio.intr_establish = amdgpio_intr_establish;
:> +sc->sc_gpio.intr_enable = amdgpio_intr_enable;
:> +sc->sc_gpio.intr_disable = amdgpio_intr_disable;
:> sc->sc_node->gpio = >sc_gpio;
:>
:> printf(", %d pins\n", sc->sc_npins);
:> @@ -275,6 +279,32 @@ amdgpio_intr_establish(void *cookie, int
:> if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
:> reg |= AMDGPIO_CONF_ACTBOTH;
:> reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
:> +bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
:> +}
:> +
:> +void
:> +amdgpio_intr_enable(void *cookie, int pin)
:> +{
:> +struct amdgpio_softc *sc = cookie;
:> +uint32_t reg;
:> +
:> +KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
:> +
:> +reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
:> +reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
:> +bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
:> +}
:> +
:> +void
:> +amdgpio_intr_disable(void *cookie, int pin)
:> +{
:> +struct amdgpio_softc *sc = cookie;
:> +uint32_t reg;
:> +
:> +KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
:> +
:> +reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
:> +reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
:> bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
:> }
:>
:> Index: dev/acpi/aplgpio.c
:> ===
:> RCS file: /cvs/src/sys/dev/acpi/aplgpio.c,v
:> retrieving revision 1.5
:> diff -u -p -r1.5 aplgpio.c
:> --- dev/acpi/aplgpio.c 6 Apr 2022 18:59:27 - 1.5
:> +++ dev/acpi/aplgpio.c 3 Oct 2022 19:10:03 -
:> @@ -76,6 +76,8 @@ const char *aplgpio_hids[] = {
:> int aplgpio_read_pin(void *, int);
:> voidaplgpio_write_pin(void *, int, int);
:> voidaplgpio_intr_establish(void *, int, int, int (*)(void *), void
*);
:> +voidaplgpio_intr_enable(void *, int);
:> +voidaplgpio_intr_disable(void *, int);
:> int aplgpio_intr(void *);
:>
:> int
:> @@ -150,6 +152,8 @@ aplgpio_attach(struct device *parent, st
:> sc->sc_gpio.read_pin = aplgpio_read_pin;
:> sc->sc_gpio.write_pin = aplgpio_write_pin;
:> sc->sc_gpio.intr_establish = aplgpio_intr_establish;
:> +sc->sc_gpio.intr_enable = aplgpio_intr_enable;
:> +sc->sc_gpio.intr_disable = aplgpio_intr_disable;
:> sc->sc_node->gpio = >sc_gpio;
:>
:> /* Mask and clear all interrupts. */
:> @@ -227,6 +231,36 @@ aplgpio_intr_establish(void *cookie, int
:> reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
:> APLGPIO_IRQ_EN + (pin / 32) * 4);
:> reg |= (1 << (pin % 32));
:> +bus_space_write_4(sc->sc_memt, sc->sc_memh,
:> +APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
:> +}
:> +
:> +void
:> +aplgpio_intr_enable(void *cookie, int pin)
:> +{
:> +struct aplgpio_softc *sc = cookie;
:> +uint32_t reg;
:> +
:> +KASSERT(pin
Re: Fix level-triggered ACPI GPIO interrupts on amd64
Hi,
did anyone else on the list had the chance to test this patch? It
really improved the touchpad hangs here.
Cheers
Matthias
* Mark Kettenis wrote:
> > Date: Thu, 13 Oct 2022 00:17:37 +0200
> > From: Mark Kettenis
> >
> > > Date: Mon, 10 Oct 2022 17:02:41 +0200
> > > From: Matthias Schmidt
> > >
> > > * Matthias Schmidt wrote:
> > > > Hi Mark,
> > > >
> > > > Addendum after 24h of testing. Your patch fixes the frequent touchpad
> > > > freezes I see on this model and which I reported back then in
> > > > https://marc.info/?l=openbsd-bugs=165328803822857=2
> > >
> > > Any chance that this patch gets committed or wider testing in snaps?
> > > It really improved the touchpad situation here.
> >
> > Right, I should probably just commit the diff instead of waiting for
> > more tests.
> >
> > ok?
>
> For reference, here is the diff again.
>
>
> Index: dev/acpi/amdgpio.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
> retrieving revision 1.9
> diff -u -p -r1.9 amdgpio.c
> --- dev/acpi/amdgpio.c27 Jun 2022 08:00:31 - 1.9
> +++ dev/acpi/amdgpio.c3 Oct 2022 19:10:03 -
> @@ -92,6 +92,8 @@ const char *amdgpio_hids[] = {
> int amdgpio_read_pin(void *, int);
> void amdgpio_write_pin(void *, int, int);
> void amdgpio_intr_establish(void *, int, int, int (*)(void *), void *);
> +void amdgpio_intr_enable(void *, int);
> +void amdgpio_intr_disable(void *, int);
> int amdgpio_pin_intr(struct amdgpio_softc *, int);
> int amdgpio_intr(void *);
> void amdgpio_save_pin(struct amdgpio_softc *, int pin);
> @@ -163,6 +165,8 @@ amdgpio_attach(struct device *parent, st
> sc->sc_gpio.read_pin = amdgpio_read_pin;
> sc->sc_gpio.write_pin = amdgpio_write_pin;
> sc->sc_gpio.intr_establish = amdgpio_intr_establish;
> + sc->sc_gpio.intr_enable = amdgpio_intr_enable;
> + sc->sc_gpio.intr_disable = amdgpio_intr_disable;
> sc->sc_node->gpio = >sc_gpio;
>
> printf(", %d pins\n", sc->sc_npins);
> @@ -275,6 +279,32 @@ amdgpio_intr_establish(void *cookie, int
> if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
> reg |= AMDGPIO_CONF_ACTBOTH;
> reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
> + bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
> +}
> +
> +void
> +amdgpio_intr_enable(void *cookie, int pin)
> +{
> + struct amdgpio_softc *sc = cookie;
> + uint32_t reg;
> +
> + KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
> +
> + reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
> + reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
> + bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
> +}
> +
> +void
> +amdgpio_intr_disable(void *cookie, int pin)
> +{
> + struct amdgpio_softc *sc = cookie;
> + uint32_t reg;
> +
> + KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
> +
> + reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
> + reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
> bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
> }
>
> Index: dev/acpi/aplgpio.c
> ===
> RCS file: /cvs/src/sys/dev/acpi/aplgpio.c,v
> retrieving revision 1.5
> diff -u -p -r1.5 aplgpio.c
> --- dev/acpi/aplgpio.c6 Apr 2022 18:59:27 - 1.5
> +++ dev/acpi/aplgpio.c3 Oct 2022 19:10:03 -
> @@ -76,6 +76,8 @@ const char *aplgpio_hids[] = {
> int aplgpio_read_pin(void *, int);
> void aplgpio_write_pin(void *, int, int);
> void aplgpio_intr_establish(void *, int, int, int (*)(void *), void *);
> +void aplgpio_intr_enable(void *, int);
> +void aplgpio_intr_disable(void *, int);
> int aplgpio_intr(void *);
>
> int
> @@ -150,6 +152,8 @@ aplgpio_attach(struct device *parent, st
> sc->sc_gpio.read_pin = aplgpio_read_pin;
> sc->sc_gpio.write_pin = aplgpio_write_pin;
> sc->sc_gpio.intr_establish = aplgpio_intr_establish;
> + sc->sc_gpio.intr_enable = aplgpio_intr_enable;
> + sc->sc_gpio.intr_disable = aplgpio_intr_disable;
> sc->sc_node->gpio = >sc_gpio;
>
> /* Mask and clear all interrupts. */
> @@ -227,6 +231,36 @@ aplgpio_intr_establish(void *cookie, int
> reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
> APLGPIO_IRQ_EN + (pin / 32) * 4);
> reg |= (1 << (pin % 32));
> + bus_space_write_4(sc->sc_memt, sc->sc_memh,
> + APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
> +}
> +
> +void
> +aplgpio_intr_enable(void *cookie, int pin)
> +{
> + struct aplgpio_softc *sc = cookie;
> + uint32_t reg;
> +
> + KASSERT(pin >= 0 && pin < sc->sc_npins);
> +
> + reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
> + APLGPIO_IRQ_EN + (pin / 32) * 4);
> + reg |= (1 << (pin % 32));
> + bus_space_write_4(sc->sc_memt, sc->sc_memh,
> + APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
> +}
> +
>
Re: Fix level-triggered ACPI GPIO interrupts on amd64
> Date: Thu, 13 Oct 2022 00:17:37 +0200
> From: Mark Kettenis
>
> > Date: Mon, 10 Oct 2022 17:02:41 +0200
> > From: Matthias Schmidt
> >
> > * Matthias Schmidt wrote:
> > > Hi Mark,
> > >
> > > Addendum after 24h of testing. Your patch fixes the frequent touchpad
> > > freezes I see on this model and which I reported back then in
> > > https://marc.info/?l=openbsd-bugs=165328803822857=2
> >
> > Any chance that this patch gets committed or wider testing in snaps?
> > It really improved the touchpad situation here.
>
> Right, I should probably just commit the diff instead of waiting for
> more tests.
>
> ok?
For reference, here is the diff again.
Index: dev/acpi/amdgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
retrieving revision 1.9
diff -u -p -r1.9 amdgpio.c
--- dev/acpi/amdgpio.c 27 Jun 2022 08:00:31 - 1.9
+++ dev/acpi/amdgpio.c 3 Oct 2022 19:10:03 -
@@ -92,6 +92,8 @@ const char *amdgpio_hids[] = {
intamdgpio_read_pin(void *, int);
void amdgpio_write_pin(void *, int, int);
void amdgpio_intr_establish(void *, int, int, int (*)(void *), void *);
+void amdgpio_intr_enable(void *, int);
+void amdgpio_intr_disable(void *, int);
intamdgpio_pin_intr(struct amdgpio_softc *, int);
intamdgpio_intr(void *);
void amdgpio_save_pin(struct amdgpio_softc *, int pin);
@@ -163,6 +165,8 @@ amdgpio_attach(struct device *parent, st
sc->sc_gpio.read_pin = amdgpio_read_pin;
sc->sc_gpio.write_pin = amdgpio_write_pin;
sc->sc_gpio.intr_establish = amdgpio_intr_establish;
+ sc->sc_gpio.intr_enable = amdgpio_intr_enable;
+ sc->sc_gpio.intr_disable = amdgpio_intr_disable;
sc->sc_node->gpio = >sc_gpio;
printf(", %d pins\n", sc->sc_npins);
@@ -275,6 +279,32 @@ amdgpio_intr_establish(void *cookie, int
if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
reg |= AMDGPIO_CONF_ACTBOTH;
reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
+}
+
+void
+amdgpio_intr_enable(void *cookie, int pin)
+{
+ struct amdgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
+ reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
+}
+
+void
+amdgpio_intr_disable(void *cookie, int pin)
+{
+ struct amdgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
+ reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
}
Index: dev/acpi/aplgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/aplgpio.c,v
retrieving revision 1.5
diff -u -p -r1.5 aplgpio.c
--- dev/acpi/aplgpio.c 6 Apr 2022 18:59:27 - 1.5
+++ dev/acpi/aplgpio.c 3 Oct 2022 19:10:03 -
@@ -76,6 +76,8 @@ const char *aplgpio_hids[] = {
intaplgpio_read_pin(void *, int);
void aplgpio_write_pin(void *, int, int);
void aplgpio_intr_establish(void *, int, int, int (*)(void *), void *);
+void aplgpio_intr_enable(void *, int);
+void aplgpio_intr_disable(void *, int);
intaplgpio_intr(void *);
int
@@ -150,6 +152,8 @@ aplgpio_attach(struct device *parent, st
sc->sc_gpio.read_pin = aplgpio_read_pin;
sc->sc_gpio.write_pin = aplgpio_write_pin;
sc->sc_gpio.intr_establish = aplgpio_intr_establish;
+ sc->sc_gpio.intr_enable = aplgpio_intr_enable;
+ sc->sc_gpio.intr_disable = aplgpio_intr_disable;
sc->sc_node->gpio = >sc_gpio;
/* Mask and clear all interrupts. */
@@ -227,6 +231,36 @@ aplgpio_intr_establish(void *cookie, int
reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
APLGPIO_IRQ_EN + (pin / 32) * 4);
reg |= (1 << (pin % 32));
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
+}
+
+void
+aplgpio_intr_enable(void *cookie, int pin)
+{
+ struct aplgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4);
+ reg |= (1 << (pin % 32));
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
+}
+
+void
+aplgpio_intr_disable(void *cookie, int pin)
+{
+ struct aplgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4);
+ reg &= ~(1 << (pin % 32));
Re: Fix level-triggered ACPI GPIO interrupts on amd64
> Date: Mon, 10 Oct 2022 17:02:41 +0200 > From: Matthias Schmidt > > * Matthias Schmidt wrote: > > Hi Mark, > > > > Addendum after 24h of testing. Your patch fixes the frequent touchpad > > freezes I see on this model and which I reported back then in > > https://marc.info/?l=openbsd-bugs=165328803822857=2 > > Any chance that this patch gets committed or wider testing in snaps? > It really improved the touchpad situation here. Right, I should probably just commit the diff instead of waiting for more tests. ok?
Re: Fix level-triggered ACPI GPIO interrupts on amd64
* Matthias Schmidt wrote: > Hi Mark, > > Addendum after 24h of testing. Your patch fixes the frequent touchpad > freezes I see on this model and which I reported back then in > https://marc.info/?l=openbsd-bugs=165328803822857=2 Any chance that this patch gets committed or wider testing in snaps? It really improved the touchpad situation here. Cheers Matthias
Re: Fix level-triggered ACPI GPIO interrupts on amd64
* Mark Kettenis wrote: > > Date: Tue, 4 Oct 2022 07:56:22 +0200 > > From: Matthias Schmidt > > > > Hi Mark, > > > > * Mark Kettenis wrote: > > > The diff below adds the hooks to disable and enable GPIO interrupts > > > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and > > > pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks > > > ago. This should fix potential interrupt storms related to > > > level-triggered interrupts. > > > > > > I can't really test this myself. But if you have a machine with a > > > line like this: > > > > > > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43 > > > > I have a Tuxedo Infinitbook with the following: > > > > ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001 > > > > > that contains the string "gpio", please give this a shot and check > > > whether your keyboard and touchpad still work with it and report back > > > with a fullk dmesg. > > > > I can confirm that both devices still work as expected. However, the > > spdmem device is "gone". Here's a diff between dmesg before and after > > That is strange; I don't really see how this would happen. > > > ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic > > 2 int 16 > > iic2 at ichiic0 > > ... > > -spdmem0 at iic2 addr 0x52: 32GB DDR4 SDRAM PC4-25600 SO-DIMM > > +"eeprom" at iic2 addr 0x52 not configured > > So an EEPROM of some sort is still detected; it just isn't detected as > an SPD EEPROM anymore. Have you seen this happening before? Is there > a difference between a cold and a warm boot? I have never seen this before, I wouldn't have noticed it if I hadn't prepare the dmesg diff. I did several cold and a warm boots and now spdmem is always correctly recognized: --- dmesg.warm Tue Oct 4 22:01:24 2022 +++ dmesg.cold Tue Oct 4 22:04:25 2022 @@ -32,7 +32,7 @@ cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) -cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 +cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu2: smt 0, core 2, package 0 @@ -174,7 +174,7 @@ audio0 at azalia0 ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 2 int 16 iic2 at ichiic0 -iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1d 6f=70 70=32 72=07 73=15 74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=25 8d=41 96=0f 97=01 b0=28 b1=0c b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 c2=81 c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f d1=48 d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a de=e7 df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c ef=41 f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 fd=03 fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 07= +iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1b 6f=70 70=32 72=07 73=15 74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=24 8d=47 96=0f b0=28 b1=0c b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 c2=81 c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f d1=48 d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a de=e7 df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c ef=41 f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 fd=03 fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 07= spdmem0 at iic2 addr 0x52: 32GB DDR4 SDRAM PC4-25600 SO-DIMM "Intel 500 Series SPI" rev 0x20 at pci0 dev 31 function 5 not configured isa0 at pcib0
Re: Fix level-triggered ACPI GPIO interrupts on amd64
> Date: Tue, 4 Oct 2022 07:56:22 +0200 > From: Matthias Schmidt > > Hi Mark, > > * Mark Kettenis wrote: > > The diff below adds the hooks to disable and enable GPIO interrupts > > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and > > pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks > > ago. This should fix potential interrupt storms related to > > level-triggered interrupts. > > > > I can't really test this myself. But if you have a machine with a > > line like this: > > > > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43 > > I have a Tuxedo Infinitbook with the following: > > ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001 > > > that contains the string "gpio", please give this a shot and check > > whether your keyboard and touchpad still work with it and report back > > with a fullk dmesg. > > I can confirm that both devices still work as expected. However, the > spdmem device is "gone". Here's a diff between dmesg before and after That is strange; I don't really see how this would happen. > ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 2 > int 16 > iic2 at ichiic0 > ... > -spdmem0 at iic2 addr 0x52: 32GB DDR4 SDRAM PC4-25600 SO-DIMM > +"eeprom" at iic2 addr 0x52 not configured So an EEPROM of some sort is still detected; it just isn't detected as an SPD EEPROM anymore. Have you seen this happening before? Is there a difference between a cold and a warm boot?
Re: Fix level-triggered ACPI GPIO interrupts on amd64
Hi Mark, Addendum after 24h of testing. Your patch fixes the frequent touchpad freezes I see on this model and which I reported back then in https://marc.info/?l=openbsd-bugs=165328803822857=2 \o/ and cheers Matthias * Matthias Schmidt wrote: > Hi Mark, > > * Mark Kettenis wrote: > > The diff below adds the hooks to disable and enable GPIO interrupts > > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and > > pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks > > ago. This should fix potential interrupt storms related to > > level-triggered interrupts. > > > > I can't really test this myself. But if you have a machine with a > > line like this: > > > > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43 > > I have a Tuxedo Infinitbook with the following: > > ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001 > > > that contains the string "gpio", please give this a shot and check > > whether your keyboard and touchpad still work with it and report back > > with a fullk dmesg. > > I can confirm that both devices still work as expected. However, the > spdmem device is "gone". Here's a diff between dmesg before and after
Re: Fix level-triggered ACPI GPIO interrupts on amd64
Hi Mark, * Mark Kettenis wrote: > The diff below adds the hooks to disable and enable GPIO interrupts > for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and > pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks > ago. This should fix potential interrupt storms related to > level-triggered interrupts. > > I can't really test this myself. But if you have a machine with a > line like this: > > ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43 I have a Tuxedo Infinitbook with the following: ihidev0 at iic1 addr 0x2c gpio 327, vendor 0x93a product 0x255, UNIW0001 > that contains the string "gpio", please give this a shot and check > whether your keyboard and touchpad still work with it and report back > with a fullk dmesg. I can confirm that both devices still work as expected. However, the spdmem device is "gone". Here's a diff between dmesg before and after --- dmesg.now Mon Oct 3 22:22:11 2022 +++ dmesg.beforeMon Oct 3 22:16:16 2022 @@ -1,7 +1,7 @@ -OpenBSD 7.2-current (GENERIC.MP) #9: Mon Oct 3 22:18:38 CEST 2022 -x...@kronos.xosc.net:/usr/src/sys/arch/amd64/compile/GENERIC.MP +OpenBSD 7.2-current (GENERIC.MP) #759: Sat Oct 1 22:48:03 MDT 2022 +dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 34064420864 (32486MB) -avail mem = 33014628352 (31485MB) +avail mem = 33014640640 (31485MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets @@ -32,12 +32,12 @@ cpu1: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu1: smt 0, core 1, package 0 cpu2 at mainbus0: apid 4 (application processor) -cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 +cpu2: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.14 MHz, 06-8c-01 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu2: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu2: smt 0, core 2, package 0 cpu3 at mainbus0: apid 6 (application processor) -cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.12 MHz, 06-8c-01 +cpu3: 11th Gen Intel(R) Core(TM) i7-11370H @ 3.30GHz, 4290.11 MHz, 06-8c-01 cpu3: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,AVX512F,AVX512DQ,RDSEED,ADX,SMAP,AVX512IFMA,CLFLUSHOPT,CLWB,PT,AVX512CD,SHA,AVX512BW,AVX512VL,AVX512VBMI,UMIP,PKU,SRBDS_CTRL,MD_CLEAR,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,XSAVEOPT,XSAVEC,XGETBV1,XSAVES cpu3: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 1MB 64b/line 20-way L2 cache, 12MB 64b/line 12-way L3 cache cpu3: smt 0, core 3, package 0 @@ -80,7 +80,7 @@ acpibtn1 at acpi0: PWRB "PNP0C14" at acpi0 not configured "PNP0C14" at acpi0 not configured -acpiac0 at acpi0: AC unit online +acpiac0 at acpi0: AC unit offline acpibat0 at acpi0: BAT0 model "standard" serial 1 type LiON oem "OEM" acpibtn2 at acpi0: LID1 "PNP0C14" at acpi0 not configured @@ -174,8 +174,8 @@ audio0 at azalia0 ichiic0 at pci0 dev 31 function 4 "Intel 500 Series SMBus" rev 0x20: apic 2 int 16 iic2 at ichiic0 -iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01 2f=73 30=df 35=26 36=22 38=f6 3a=80 3b=80 3c=80 3d=80 3e=80 3f=80 55=c0 58=24 6d=08 6e=1b 6f=70 70=33 72=07 73=15 74=20 75=06 78=02 79=02 7a=20 7e=e0 88=96 8b=2d 8c=25 8d=45 96=0f 97=01 b0=28 b1=0c b2=25 b4=42 b5=21 b6=09 b7=42 b8=80 bb=15 bd=bc be=7a bf=40 c0=13 c1=04 c2=81 c3=0a c4=19 c5=14 c6=05 c7=81 c8=38 ca=03 cc=db cd=32 ce=06 cf=c8 d0=1f d1=48 d2=19 d3=48 d4=13 d5=64 d6=09 d7=24 d8=08 d9=39 da=03 db=7a dc=03 dd=7a de=e7 df=05 e0=0a e1=a0 e2=0a e3=1a e4=10 e5=a1 e6=30 e8=0a e9=7b ea=a4 ee=1c ef=41 f0=14 f1=5d f2=1e f3=78 f5=1e f6=d0 f7=59 f8=64 f9=e2 fa=43 fb=b2 fc=80 fd=03 fe=af ff=ff words 00=00d5 01=8037 02= 03=5200 04= 05= 06= 07= -"eeprom" at iic2 addr 0x52 not configured +iic2: addr 0x20 01=80 03=52 08=63 09=64 0c=7f 15=30 16=39 19=14 1b=45 1d=08 1e=02 21=a1 24=ff 25=92 26=5b 2d=6a 2e=01
Fix level-triggered ACPI GPIO interrupts on amd64
The diff below adds the hooks to disable and enable GPIO interrupts
for amdgpio(4), aplgpio(4), bytgpio(4), chvgpio(4), glkgpio(4) and
pchgpio(4). This is similar to what I did for qcgpio(4) a few weeks
ago. This should fix potential interrupt storms related to
level-triggered interrupts.
I can't really test this myself. But if you have a machine with a
line like this:
ihidev0 at iic7 addr 0x2c gpio 18, vendor 0x6cb product 0x8253, SYNA2B43
that contains the string "gpio", please give this a shot and check
whether your keyboard and touchpad still work with it and report back
with a fullk dmesg.
Thanks,
Mark
Index: dev/acpi/amdgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/amdgpio.c,v
retrieving revision 1.9
diff -u -p -r1.9 amdgpio.c
--- dev/acpi/amdgpio.c 27 Jun 2022 08:00:31 - 1.9
+++ dev/acpi/amdgpio.c 3 Oct 2022 19:10:03 -
@@ -92,6 +92,8 @@ const char *amdgpio_hids[] = {
intamdgpio_read_pin(void *, int);
void amdgpio_write_pin(void *, int, int);
void amdgpio_intr_establish(void *, int, int, int (*)(void *), void *);
+void amdgpio_intr_enable(void *, int);
+void amdgpio_intr_disable(void *, int);
intamdgpio_pin_intr(struct amdgpio_softc *, int);
intamdgpio_intr(void *);
void amdgpio_save_pin(struct amdgpio_softc *, int pin);
@@ -163,6 +165,8 @@ amdgpio_attach(struct device *parent, st
sc->sc_gpio.read_pin = amdgpio_read_pin;
sc->sc_gpio.write_pin = amdgpio_write_pin;
sc->sc_gpio.intr_establish = amdgpio_intr_establish;
+ sc->sc_gpio.intr_enable = amdgpio_intr_enable;
+ sc->sc_gpio.intr_disable = amdgpio_intr_disable;
sc->sc_node->gpio = >sc_gpio;
printf(", %d pins\n", sc->sc_npins);
@@ -275,6 +279,32 @@ amdgpio_intr_establish(void *cookie, int
if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
reg |= AMDGPIO_CONF_ACTBOTH;
reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
+}
+
+void
+amdgpio_intr_enable(void *cookie, int pin)
+{
+ struct amdgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
+ reg |= (AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
+}
+
+void
+amdgpio_intr_disable(void *cookie, int pin)
+{
+ struct amdgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin != 63 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, pin * 4);
+ reg &= ~(AMDGPIO_CONF_INT_MASK | AMDGPIO_CONF_INT_EN);
bus_space_write_4(sc->sc_memt, sc->sc_memh, pin * 4, reg);
}
Index: dev/acpi/aplgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/aplgpio.c,v
retrieving revision 1.5
diff -u -p -r1.5 aplgpio.c
--- dev/acpi/aplgpio.c 6 Apr 2022 18:59:27 - 1.5
+++ dev/acpi/aplgpio.c 3 Oct 2022 19:10:03 -
@@ -76,6 +76,8 @@ const char *aplgpio_hids[] = {
intaplgpio_read_pin(void *, int);
void aplgpio_write_pin(void *, int, int);
void aplgpio_intr_establish(void *, int, int, int (*)(void *), void *);
+void aplgpio_intr_enable(void *, int);
+void aplgpio_intr_disable(void *, int);
intaplgpio_intr(void *);
int
@@ -150,6 +152,8 @@ aplgpio_attach(struct device *parent, st
sc->sc_gpio.read_pin = aplgpio_read_pin;
sc->sc_gpio.write_pin = aplgpio_write_pin;
sc->sc_gpio.intr_establish = aplgpio_intr_establish;
+ sc->sc_gpio.intr_enable = aplgpio_intr_enable;
+ sc->sc_gpio.intr_disable = aplgpio_intr_disable;
sc->sc_node->gpio = >sc_gpio;
/* Mask and clear all interrupts. */
@@ -227,6 +231,36 @@ aplgpio_intr_establish(void *cookie, int
reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
APLGPIO_IRQ_EN + (pin / 32) * 4);
reg |= (1 << (pin % 32));
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
+}
+
+void
+aplgpio_intr_enable(void *cookie, int pin)
+{
+ struct aplgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4);
+ reg |= (1 << (pin % 32));
+ bus_space_write_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4, reg);
+}
+
+void
+aplgpio_intr_disable(void *cookie, int pin)
+{
+ struct aplgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin < sc->sc_npins);
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh,
+ APLGPIO_IRQ_EN + (pin / 32) * 4);
+ reg &= ~(1 << (pin % 32));
Re: acpi gpio interrupts
On Tue, Mar 29, 2016 at 11:13:51PM +0200, Mark Kettenis wrote:
> Hi Jonathan, Joshua & other interested folks,
>
> The diff below adds support for gpio interrupts for the Bay Trail GPIO
> controller. The acpi gpio interface gets extended with an
> intr_establish() method that establishes an interrupt on a specific
> pin. The pin is configured according to the flags that are passed.
> The interrupt is established at IPL_BIO. This is similar to what the
> USB subsystem does. The interrupt handler should call splxxx() as
> appropriate. This means that keyboard interrupts will be blocked by
> pretty much all other interrupt handlers. We can't easily avoid this.
>
> The diff hooks this support up to the sdhc(4) driver. Card insertions
> and de-insertions are now detected in the SD card slot of my Asus
> x205ta.
>
> It should be fairly easy too hook up the keyboard interrupt on the
> Lenovo 100s.
>
> ok?
It would be nice if the intr_establish at least returned an int to avoid
having to add simple functions to get around to different prototype.
Perhaps an empty intr_disestablish and adding the devname argument
like acpi_intr_establish? Is it possible multiple callbacks may
need to be called for a single pin?
It ends up being a bit convoluted on the 100s but works with the
following. Can now click and drag windows in x11...
dwiic0 at acpi0: I2C1 addr 0x90906000/0x1000 irq 32
iic0 at dwiic0
dwiic1 at acpi0: I2C2 addr 0x9090c000/0x1000 irq 33
iic1 at dwiic1
"10EC5640" at acpi0 not configured
dwiic2 at acpi0: I2C3 addr 0x9090e000/0x1000 irq 34
iic2 at dwiic2
GPO2 pin 22
tflags 0x12
ppi 0x1
drs 0x0
dbt 0x0
ihidev0 at iic2 addr 0x5: int 22, vendor 0x6243 product 0x1, ENEE3730
ihidev0: 6 report ids
ikbd0 at ihidev0 reportid 1: 8 variable keys, 6 key codes
wskbd0 at ikbd0 mux 1
hid at ihidev0 reportid 2 not configured
hid at ihidev0 reportid 3 not configured
ims0 at ihidev0 reportid 4: 3 buttons, Z dir
wsmouse0 at ims0 mux 0
hid at ihidev0 reportid 5 not configured
hid at ihidev0 reportid 6 not configured
"ENEE3730" at acpi0 not configured
dwiic3 at acpi0: I2C4 addr 0x9091/0x1000 irq 35
iic3 at dwiic3
dwiic4 at acpi0: I2C5 addr 0x90912000/0x1000 irq 36
iic4 at dwiic4
Index: acpi/dwiic.c
===
RCS file: /cvs/src/sys/dev/acpi/dwiic.c,v
retrieving revision 1.12
diff -u -p -r1.12 dwiic.c
--- acpi/dwiic.c29 Mar 2016 22:35:09 - 1.12
+++ acpi/dwiic.c30 Mar 2016 00:56:40 -
@@ -123,6 +123,10 @@ struct dwiic_crs {
uint32_t addr_bas;
uint32_t addr_len;
uint16_t i2c_addr;
+ struct aml_node *devnode;
+ struct aml_node *gpio_int_node;
+ uint16_t gpio_int_pin;
+ uint16_t gpio_int_flags;
};
struct dwiic_softc {
@@ -238,6 +242,7 @@ dwiic_attach(struct device *parent, stru
return;
}
memset(, 0, sizeof(crs));
+ crs.devnode = sc->sc_devnode;
aml_parse_resource(, dwiic_acpi_parse_crs, );
aml_freevalue();
@@ -374,6 +379,8 @@ int
dwiic_acpi_parse_crs(union acpi_resource *crs, void *arg)
{
struct dwiic_crs *sc_crs = arg;
+ struct aml_node *node;
+ uint16_t pin;
switch (AML_CRSTYPE(crs)) {
case SR_IRQ:
@@ -386,6 +393,22 @@ dwiic_acpi_parse_crs(union acpi_resource
sc_crs->irq_flags = crs->lr_extirq.flags;
break;
+ case LR_GPIO:
+ node = aml_searchname(sc_crs->devnode,
+ (char *)>pad[crs->lr_gpio.res_off]);
+ pin = *(uint16_t *)>pad[crs->lr_gpio.pin_off];
+ printf(" %s pin %d\n", node->name, pin);
+ if (crs->lr_gpio.type == LR_GPIO_INT) {
+ sc_crs->gpio_int_node = node;
+ sc_crs->gpio_int_pin = pin;
+ sc_crs->gpio_int_flags = crs->lr_gpio.tflags;
+ }
+ printf(" tflags 0x%x\n", crs->lr_gpio.tflags);
+ printf(" ppi 0x%x\n", crs->lr_gpio._ppi);
+ printf(" drs 0x%x\n", crs->lr_gpio._drs);
+ printf(" dbt 0x%x\n", crs->lr_gpio._dbt);
+ break;
+
case LR_MEM32:
sc_crs->addr_min = letoh32(crs->lr_m32._min);
sc_crs->addr_len = letoh32(crs->lr_m32._len);
@@ -553,18 +576,27 @@ dwiic_acpi_foundhid(struct aml_node *nod
return (0);
}
memset(, 0, sizeof(crs));
+ crs.devnode = sc->sc_devnode;
aml_parse_resource(, dwiic_acpi_parse_crs, );
aml_freevalue();
- if (crs.irq_int <= 0) {
+ if (crs.gpio_int_node && crs.gpio_int_node->gpio) {
+ struct acpi_gpio *gpio = crs.gpio_int_node->gpio;
+ ia.ia_int = crs.gpio_int_pin;
+ ia.ia_int_flags = crs.gpio_int_flags;
+ ia.acpi_gpio = gpio;
+ } else {
+ ia.ia_int = crs.irq_int;
+ ia.ia_int_flags = crs.irq_flags;
+
acpi gpio interrupts
Hi Jonathan, Joshua & other interested folks,
The diff below adds support for gpio interrupts for the Bay Trail GPIO
controller. The acpi gpio interface gets extended with an
intr_establish() method that establishes an interrupt on a specific
pin. The pin is configured according to the flags that are passed.
The interrupt is established at IPL_BIO. This is similar to what the
USB subsystem does. The interrupt handler should call splxxx() as
appropriate. This means that keyboard interrupts will be blocked by
pretty much all other interrupt handlers. We can't easily avoid this.
The diff hooks this support up to the sdhc(4) driver. Card insertions
and de-insertions are now detected in the SD card slot of my Asus
x205ta.
It should be fairly easy too hook up the keyboard interrupt on the
Lenovo 100s.
ok?
Index: acpi/amltypes.h
===
RCS file: /cvs/src/sys/dev/acpi/amltypes.h,v
retrieving revision 1.41
diff -u -p -r1.41 amltypes.h
--- acpi/amltypes.h 28 Mar 2016 17:27:57 - 1.41
+++ acpi/amltypes.h 29 Mar 2016 21:04:45 -
@@ -367,6 +367,7 @@ struct acpi_pci {
struct acpi_gpio {
void*cookie;
int (*read_pin)(void *, int);
+ void(*intr_establish)(void *, int, int, void (*)(void *), void *);
};
struct aml_node {
Index: acpi/bytgpio.c
===
RCS file: /cvs/src/sys/dev/acpi/bytgpio.c,v
retrieving revision 1.3
diff -u -p -r1.3 bytgpio.c
--- acpi/bytgpio.c 29 Mar 2016 18:04:09 - 1.3
+++ acpi/bytgpio.c 29 Mar 2016 21:04:45 -
@@ -25,8 +25,22 @@
#include
#include
+#define BYTGPIO_CONF_GD_LEVEL 0x0100
+#define BYTGPIO_CONF_GD_TPE0x0200
+#define BYTGPIO_CONF_GD_TNE0x0400
+#define BYTGPIO_CONF_GD_MASK 0x0f00
+
#define BYTGPIO_PAD_VAL0x0001
+#define BYTGPIO_IRQ_TS_0 0x800
+#define BYTGPIO_IRQ_TS_1 0x804
+#define BYTGPIO_IRQ_TS_2 0x808
+
+struct bytgpio_intrhand {
+ void (*ih_func)(void *);
+ void *ih_arg;
+};
+
struct bytgpio_softc {
struct device sc_dev;
struct acpi_softc *sc_acpi;
@@ -43,6 +57,7 @@ struct bytgpio_softc {
const int *sc_pins;
int sc_npins;
+ struct bytgpio_intrhand *sc_pin_ih;
struct acpi_gpio sc_gpio;
};
@@ -90,6 +105,7 @@ const int byt_sus_pins[] = {
intbytgpio_parse_resources(union acpi_resource *, void *);
intbytgpio_read_pin(void *, int);
+void bytgpio_intr_establish(void *, int, int, void (*)(), void *);
intbytgpio_intr(void *);
int
@@ -149,29 +165,39 @@ bytgpio_attach(struct device *parent, st
return;
}
+ sc->sc_pin_ih = mallocarray(sc->sc_npins, sizeof(*sc->sc_pin_ih),
+ M_DEVBUF, M_NOWAIT | M_ZERO);
+ if (sc->sc_pin_ih == NULL) {
+ printf("\n");
+ return;
+ }
+
printf(" irq %d", sc->sc_irq);
sc->sc_memt = aaa->aaa_memt;
if (bus_space_map(sc->sc_memt, sc->sc_addr, sc->sc_size, 0,
>sc_memh)) {
printf(", can't map registers\n");
- return;
+ goto fail;
}
-#if 0
sc->sc_ih = acpi_intr_establish(sc->sc_irq, sc->sc_irq_flags, IPL_BIO,
bytgpio_intr, sc, sc->sc_dev.dv_xname);
if (sc->sc_ih == NULL) {
printf(", can't establish interrupt\n");
- return;
+ goto fail;
}
-#endif
sc->sc_gpio.cookie = sc;
sc->sc_gpio.read_pin = bytgpio_read_pin;
+ sc->sc_gpio.intr_establish = bytgpio_intr_establish;
sc->sc_node->gpio = >sc_gpio;
printf(", %d pins\n", sc->sc_npins);
+ return;
+
+fail:
+ free(sc->sc_pin_ih, M_DEVBUF, sc->sc_npins * sizeof(*sc->sc_pin_ih));
}
int
@@ -207,25 +233,52 @@ bytgpio_read_pin(void *cookie, int pin)
return (reg & BYTGPIO_PAD_VAL);
}
-#if 0
+void
+bytgpio_intr_establish(void *cookie, int pin, int flags,
+void (*func)(void *), void *arg)
+{
+ struct bytgpio_softc *sc = cookie;
+ uint32_t reg;
+
+ KASSERT(pin >= 0 && pin < sc->sc_npins);
+
+ sc->sc_pin_ih[pin].ih_func = func;
+ sc->sc_pin_ih[pin].ih_arg = arg;
+
+ reg = bus_space_read_4(sc->sc_memt, sc->sc_memh, sc->sc_pins[pin] * 16);
+ reg &= ~BYTGPIO_CONF_GD_MASK;
+ if ((flags & LR_GPIO_MODE) == 0)
+ reg |= BYTGPIO_CONF_GD_LEVEL;
+ if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTLO)
+ reg |= BYTGPIO_CONF_GD_TNE;
+ if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTHI)
+ reg |= BYTGPIO_CONF_GD_TPE;
+ if ((flags & LR_GPIO_POLARITY) == LR_GPIO_ACTBOTH)
+ reg |= BYTGPIO_CONF_GD_TNE | BYTGPIO_CONF_GD_TPE;
+ bus_space_write_4(sc->sc_memt, sc->sc_memh, sc->sc_pins[pin] * 16, reg);
+}
int
bytgpio_intr(void *arg)
{
struct bytgpio_softc
