You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
4.10.0.0 FreeBSD apuled driver failed to initialize on APU2 #329
With new 4.10.0.0 BIOS I lost LEDs and modeswitch devices on my APU2 in FreeBSD 11.2
With 4.9.0.5 all works fine.
Driver message with 4.9.0.5: apuled0: <APU2> at iomem 0xfed81610-0xfed8161b,0xfed81664-0xfed81667 on isa0
Driver message with 4.10.0.0:
apuled0: <APU2> at iomem 0xfed81610-0xfed8161b,0xfed81664-0xfed81667 on isa0
apuled0: Unable to allocate memory region 0
device_attach: apuled0 attach returned 6
device_attach() returns ENXIO error (device not configured)
Is this some error in new BIOS, or is there a need to make changes in driver code according to changes in new BIOS?
The v4.10.0.0 BIOS adds a GPIO controller device in the ACPI, which reserves the MMIO for the GPIOs. Most likely FreeBSD cannot reserve the memory for the native driver now.
The GPIOs are now accessible in Linux, however it introduced a regression on BSD. IMO it would be better to make changes to the driver. There are few reasons:
ACPI GPIO controller allows to access all GPIOs (i.e. not only leds, mode switch, but also PCIe resets, WLAN disable signals on PCIe slots)
Certain GPIOs can be controlled by generic drivers like gpio-leds, gpio-keys in Linux. We will check whether there is any equivalent on BSD side.
It worked for Linux without issue when native platform drivers were in place along with the ACPI GPIO controller, but BSD is not so flexible.
The v4.10.0.0 BIOS adds a GPIO controller device in the ACPI, which reserves the MMIO for the GPIOs.
Thanks for the hint, the problem is exactly here. I can't quickly fix the driver code unfortunately, since it seems I need to completely rewrite it. But fortunately I found a workaround which can solve this problem pretty easy. There is a need to add environment variable debug.acpi.avoid="\_SB_.PCI0.GPIO"
to loader.conf, and apuled driver works fine. This parameter does not affect other ACPI functionality, it only prevents GPIO resource allocation by ACPI driver.
Just a thought:
In FreeBSD-CURRENT, there is a new amdgpio driver. (https://reviews.freebsd.org/D16865)
If that works on the apu2/3/x then maybe the generic gpioled kernel module might work for the leds.
Even if not, it might be a starting point for a new apuled module?
@Nimloth
I tried this driver, and it works properly. But the LEDs are accessible only as GPIO pins, and can't use with gpioled driver because this driver only supports pins from 0 to 32, but LEDs are mapped to pins with numbers higher than 32 on APU2 at least. And, I can't operate with modeswitch button using amdgpio driver. With my workaround described above old apuled driver works fine, and all other ACPI functionality operates as usual.
Even if not, it might be a starting point for a new apuled module?
Yes, this driver can be used as a starting point, I thought exactly the same :)
If the new amdgpio can control all GPIOs this should not be a problem. Are there any generic Led drivers that can hook to other drivers? Like in the same manner that Linux does it with amd_pinctrl driver and gpio-led driver.
I am not familiar with amd_pinctrl, but if you mean a generic interface for leds then sure, that is available. There is a manpage for it: led(4). It allows to create or destroy an led device and toggle its state.
The FreeBSD gpioled driver combines that interface with the gpiobus functions.
Are there any generic Led drivers that can hook to other drivers?
Yes, gpioled driver can. But not with APU, because LEDs mapped to pins 68,69,70 on APU2 and 3, and pins 189, 190, 191 on APU1.
gpioled can use pins from 0 to 31 unfortunately
@Nimloth
In manual gpioled (4) hint.gpioled.%d.pins: parameter of which pin on the GPIO interface to map to driver instance. It's a mask, and only one bit must be set for driver instance. And wiki says that "At the moment children could be set only by hints file and pin space is limited to 32." (last edited 2019-09-07)
And, modeswitch button can't be used with amdgpio driver.
@alexpro
I was not saying that you are wrong, but merely that this is a strange limitation:
Why would gpiobus be able to see all 256 pins yet gpioled is only able to address the first 32 of the lot?
@miczyg1
I suppose. I assume that for the purpose of gpiobus and gpioctl, you access an array instead of a bitmask. Which would explain why there is no such size limit there.
@alexpro , I added "pin_list" hint a while ago to address that exact issue.
See gpiobus manual page.
FWIW, gpioled is a wrong place to document hints like "pins" and "pin_list", because -- even if not intuitive -- those are properties of the gpio bus and not any individual driver on it.
Activity
miczyg1 commentedon Aug 26, 2019
The v4.10.0.0 BIOS adds a GPIO controller device in the ACPI, which reserves the MMIO for the GPIOs. Most likely FreeBSD cannot reserve the memory for the native driver now.
The GPIOs are now accessible in Linux, however it introduced a regression on BSD. IMO it would be better to make changes to the driver. There are few reasons:
It worked for Linux without issue when native platform drivers were in place along with the ACPI GPIO controller, but BSD is not so flexible.
alexpro commentedon Aug 29, 2019
Thanks for the hint, the problem is exactly here. I can't quickly fix the driver code unfortunately, since it seems I need to completely rewrite it. But fortunately I found a workaround which can solve this problem pretty easy. There is a need to add environment variable
debug.acpi.avoid="\_SB_.PCI0.GPIO"to loader.conf, and apuled driver works fine. This parameter does not affect other ACPI functionality, it only prevents GPIO resource allocation by ACPI driver.
Nimloth commentedon Sep 12, 2019
Just a thought:
In FreeBSD-CURRENT, there is a new amdgpio driver. (https://reviews.freebsd.org/D16865)
If that works on the apu2/3/x then maybe the generic gpioled kernel module might work for the leds.
Even if not, it might be a starting point for a new apuled module?
miczyg1 commentedon Sep 12, 2019
@Nimloth thank you for the pointer. We will look into that and try to align with the new driver approach in the firmware if possible.
alexpro commentedon Sep 12, 2019
@Nimloth
I tried this driver, and it works properly. But the LEDs are accessible only as GPIO pins, and can't use with gpioled driver because this driver only supports pins from 0 to 32, but LEDs are mapped to pins with numbers higher than 32 on APU2 at least. And, I can't operate with modeswitch button using amdgpio driver. With my workaround described above old apuled driver works fine, and all other ACPI functionality operates as usual.
Yes, this driver can be used as a starting point, I thought exactly the same :)
miczyg1 commentedon Sep 12, 2019
If the new amdgpio can control all GPIOs this should not be a problem. Are there any generic Led drivers that can hook to other drivers? Like in the same manner that Linux does it with amd_pinctrl driver and gpio-led driver.
Nimloth commentedon Sep 12, 2019
I am not familiar with amd_pinctrl, but if you mean a generic interface for leds then sure, that is available. There is a manpage for it: led(4). It allows to create or destroy an led device and toggle its state.
The FreeBSD gpioled driver combines that interface with the gpiobus functions.
Nimloth commentedon Sep 12, 2019
This is output from FreeBSD-13.0-CURRENT on an apu2:
And then:
It lists pins 0 through 255.
miczyg1 commentedon Sep 12, 2019
Ok that looks good. Probably it will work.
alexpro commentedon Sep 12, 2019
@miczyg1
Yes, gpioled driver can. But not with APU, because LEDs mapped to pins 68,69,70 on APU2 and 3, and pins 189, 190, 191 on APU1.
gpioled can use pins from 0 to 31 unfortunately
Nimloth commentedon Sep 12, 2019
@alexpro
I have not looked at the code yet, but that seems arbitrary. Nothing specific comes to mind that would explain that this has to be this way.
alexpro commentedon Sep 12, 2019
@Nimloth
In manual gpioled (4)
hint.gpioled.%d.pins:parameter of which pin on the GPIO interface to map to driver instance. It's a mask, and only one bit must be set for driver instance. And wiki says that "At the moment children could be set only by hints file and pin space is limited to 32." (last edited 2019-09-07)And, modeswitch button can't be used with amdgpio driver.
miczyg1 commentedon Sep 12, 2019
It would be great if the GPIO driver could understand ACPI...
Nimloth commentedon Sep 12, 2019
@alexpro
I was not saying that you are wrong, but merely that this is a strange limitation:
Why would gpiobus be able to see all 256 pins yet gpioled is only able to address the first 32 of the lot?
miczyg1 commentedon Sep 12, 2019
The answer is pretty simple. The GPIO index in the hint is most likely a 32bit value. So 1 bit for each gpio gives 32 addressable pins.
Nimloth commentedon Sep 13, 2019
@miczyg1
I suppose. I assume that for the purpose of gpiobus and gpioctl, you access an array instead of a bitmask. Which would explain why there is no such size limit there.
alexpro commentedon Sep 13, 2019
@Nimloth There are some kind of "pools" each of 32 pins. But gpioled does not support select particular "pool", it can use only first one.
avg-I commentedon Oct 15, 2019
@alexpro , I added "pin_list" hint a while ago to address that exact issue.
See gpiobus manual page.
FWIW, gpioled is a wrong place to document hints like "pins" and "pin_list", because -- even if not intuitive -- those are properties of the gpio bus and not any individual driver on it.
miczyg1 commentedon Jul 15, 2020
The workaround is added to the documentation: https://github.com/pcengines/apu2-documentation/blob/master/docs/gpios.md#known-issues