Skip to content

4.10.0.0 FreeBSD apuled driver failed to initialize on APU2 #329

Closed

Description

@alexpro

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?

Activity

  1. miczyg1 commented on Aug 26, 2019

    @miczyg1
    Member

    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:

    1. 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)
    2. 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.

  2. alexpro commented on Aug 29, 2019

    @alexpro
    Author

    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.

  3. Nimloth commented on Sep 12, 2019

    @Nimloth

    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?

  4. miczyg1 commented on Sep 12, 2019

    @miczyg1
    Member

    @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.

  5. alexpro commented on Sep 12, 2019

    @alexpro
    Author

    @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 :)

  6. miczyg1 commented on Sep 12, 2019

    @miczyg1
    Member

    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.

  7. Nimloth commented on Sep 12, 2019

    @Nimloth

    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.

  8. Nimloth commented on Sep 12, 2019

    @Nimloth

    This is output from FreeBSD-13.0-CURRENT on an apu2:

    # kldload amdgpio
    driver bug: Unable to set devclass (class: ppc devname: (unknown))
    gpio0: <AMD GPIO Controller> iomem 0xfed81500-0xfed817ff irq 7 on acpi0
    gpiobus0: <GPIO bus> on gpio0
    gpioc0: <GPIO controller> on gpio0
    

    And then:

    # gpioctl -l
    pin 00: 1       AMDGPIO0_PIN_0<IN>
    pin 01: 1       AMDGPIO0_PIN_1<IN>
    pin 02: 0       AMDGPIO0_PIN_2<OUT>
    pin 03: 0       AMDGPIO0_PIN_3<IN>
    pin 04: 0       AMDGPIO0_PIN_4<IN>
    pin 05: 0       AMDGPIO0_PIN_5<IN>
    pin 06: 1       AMDGPIO0_PIN_6<IN>
    pin 07: 1       AMDGPIO0_PIN_7<IN>
    pin 08: 1       AMDGPIO0_PIN_8<IN>
    pin 09: 1       AMDGPIO0_PIN_9<IN>
    pin 10: 0       AMDGPIO0_PIN_10<IN>
    pin 11: 1       AMDGPIO0_PIN_11<IN>
    pin 12: 0       AMDGPIO0_PIN_12<IN>
    pin 13: 1       AMDGPIO0_PIN_13<IN>
    pin 14: 1       AMDGPIO0_PIN_14<IN>
    pin 15: 1       AMDGPIO0_PIN_15<IN>
    pin 16: 1       AMDGPIO0_PIN_16<IN>
    pin 17: 1       AMDGPIO0_PIN_17<IN>
    pin 18: 1       AMDGPIO0_PIN_18<IN>
    pin 19: 1       AMDGPIO0_PIN_19<IN>
    pin 20: 1       AMDGPIO0_PIN_20<IN>
    pin 21: -1      <>
    pin 22: -1      <>
    pin 23: 1       AMDGPIO0_PIN_23<IN>
    pin 24: 1       AMDGPIO0_PIN_24<IN>
    pin 25: 0       AMDGPIO0_PIN_25<IN>
    pin 26: 0       AMDGPIO0_PIN_26<IN>
    pin 27: -1      <>
    pin 28: -1      <>
    pin 29: -1      <>
    pin 30: -1      <>
    pin 31: -1      <>
    pin 32: -1      <>
    pin 33: -1      <>
    pin 34: -1      <>
    pin 35: -1      <>
    pin 36: -1      <>
    pin 37: -1      <>
    pin 38: -1      <>
    pin 39: 0       AMDGPIO0_PIN_39<IN>
    pin 40: 0       AMDGPIO0_PIN_40<IN>
    pin 41: -1      <>
    pin 42: -1      <>
    pin 43: 0       AMDGPIO0_PIN_43<IN>
    pin 44: -1      <>
    pin 45: -1      <>
    pin 46: 1       AMDGPIO0_PIN_46<IN>
    pin 47: 0       AMDGPIO0_PIN_47<IN>
    pin 48: 0       AMDGPIO0_PIN_48<IN>
    pin 49: 1       AMDGPIO0_PIN_49<IN>
    pin 50: 0       AMDGPIO0_PIN_50<IN>
    pin 51: 0       AMDGPIO0_PIN_51<IN>
    pin 52: 0       AMDGPIO0_PIN_52<IN>
    pin 53: 0       AMDGPIO0_PIN_53<IN>
    pin 54: 0       AMDGPIO0_PIN_54<IN>
    pin 55: 0       AMDGPIO0_PIN_55<IN>
    pin 56: 0       AMDGPIO0_PIN_56<IN>
    pin 57: 0       AMDGPIO0_PIN_57<IN>
    pin 58: 0       AMDGPIO0_PIN_58<IN>
    pin 59: 0       AMDGPIO0_PIN_59<IN>
    pin 60: 1       AMDGPIO0_PIN_60<IN>
    pin 61: 0       AMDGPIO0_PIN_61<IN>
    pin 62: 0       AMDGPIO0_PIN_62<IN>
    pin 63: -1      <>
    pin 64: 1       AMDGPIO1_PIN_64<IN>
    pin 65: 0       AMDGPIO1_PIN_65<IN>
    pin 66: 1       AMDGPIO1_PIN_66<OUT>
    pin 67: -1      <>
    pin 68: 0       AMDGPIO1_PIN_68<OUT>
    pin 69: 1       AMDGPIO1_PIN_69<OUT>
    pin 70: 1       AMDGPIO1_PIN_70<OUT>
    pin 71: 1       AMDGPIO1_PIN_71<IN>
    pin 72: 1       AMDGPIO1_PIN_72<IN>
    pin 73: -1      <>
    ...
    

    It lists pins 0 through 255.

  9. miczyg1 commented on Sep 12, 2019

    @miczyg1
    Member

    Ok that looks good. Probably it will work.

  10. alexpro commented on Sep 12, 2019

    @alexpro
    Author

    @miczyg1

    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

  11. Nimloth commented on Sep 12, 2019

    @Nimloth

    @alexpro

    gpioled can use pins from 0 to 31 unfortunately

    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.

  12. alexpro commented on Sep 12, 2019

    @alexpro
    Author

    @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.

  13. miczyg1 commented on Sep 12, 2019

    @miczyg1
    Member

    It would be great if the GPIO driver could understand ACPI...

  14. Nimloth commented on Sep 12, 2019

    @Nimloth

    @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?

  15. miczyg1 commented on Sep 12, 2019

    @miczyg1
    Member

    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.

  16. Nimloth commented on Sep 13, 2019

    @Nimloth

    @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.

  17. alexpro commented on Sep 13, 2019

    @alexpro
    Author

    @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.

  18. avg-I commented on Oct 15, 2019

    @avg-I

    @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.

  19. miczyg1 commented on Jul 15, 2020

    @miczyg1
    Member
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions