[PATCH] PCI: amlogic: Fix reset assertion via gpio descriptor

Martin Blumenstingl martin.blumenstingl at googlemail.com
Mon Sep 2 15:34:44 PDT 2019

Hi Andrew,

On Mon, Sep 2, 2019 at 12:55 PM Andrew Murray <andrew.murray at arm.com> wrote:
> On Sun, Sep 01, 2019 at 03:39:15PM +0200, Remi Pommarel wrote:
> > Normally asserting reset signal on gpio would be achieved with:
> >       gpiod_set_value_cansleep(reset_gpio, 1);
> >
> > Meson PCI driver set reset value to '0' instead of '1' as it takes into
> > account the PERST# signal polarity. The polarity should be taken care
> > in the device tree instead.
> >
> > This fixes the reset assertion meaning and moves out the polarity
> > configuration in DT (please note that there is no DT currently using
> > this driver).
> The device tree bindings for this give an example configuration:
>         pcie: pcie at f9800000 {
>                         compatible = "amlogic,axg-pcie", "snps,dw-pcie";
>                         reg = <0x0 0xf9800000 0x0 0x400000
>                                         0x0 0xff646000 0x0 0x2000
>                                         0x0 0xff644000 0x0 0x2000
>                                         0x0 0xf9f00000 0x0 0x100000>;
>                         reg-names = "elbi", "cfg", "phy", "config";
>                         reset-gpios = <&gpio GPIOX_19 GPIO_ACTIVE_HIGH>;
> Is the 'reset-gpios' line still consistent with this change, or does
> this need to be updated as well?
in my opinion the example is still valid
whether GPIO_ACTIVE_HIGH or GPIO_ACTIVE_LOW is correct depends on the
actual circuit on the board:
- if the GPIO signal is directly connected to the PERST# line of the
PCIe card then above example is correct
- if the GPIO signal is inverted, for example by using a transistor,
then GPIO_ACTIVE_LOW should be used instead

I haven't looked into the schematics of the boards using a G12A or
G12B SoC (I don't have any schematics of a board with an AXG SoC) so I
can't tell what "most boards" use (active LOW or HIGH).
if there's a pattern in those board schematics (which is likely since
most are derived from Amlogics reference design) then we can update
the example based that.


More information about the linux-amlogic mailing list