From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Ye Zhang" <ye.zhang@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Johan Jonker" <jbx6244@gmail.com>,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] arm64: dts: rockchip: align bindings to PCIe spec
Date: Sat, 8 Nov 2025 19:43:17 -0300 [thread overview]
Message-ID: <aQ_HhfK0pbOE1m1R@geday> (raw)
In-Reply-To: <sbulnlwz3vxyk3yw2c2tcsdvyu57cdvyixkpeq2okh4vn6yyod@4o4kltfb5u6n>
On Sat, Nov 08, 2025 at 11:12:54PM +0100, Sebastian Reichel wrote:
> Hi,
Hi Sebastian,
>
> On Fri, Nov 07, 2025 at 11:01:04AM +0800, Shawn Lin wrote:
> > + Ye Zhang
> >
> > 在 2025/11/07 星期五 10:43, Geraldo Nascimento 写道:
> > > On Wed, Nov 05, 2025 at 04:56:36PM +0800, Shawn Lin wrote:
> > > > 在 2025/11/05 星期三 16:18, Geraldo Nascimento 写道:
> > > > > Hi Shawn, glad to hear from you.
> > > > >
> > > > > Perhaps the following change is better? It resolves the issue
> > > > > without the added complication of open drain. After you questioned
> > > > > if open drain is actually part of the spec, I remembered that
> > > > > GPIO_OPEN_DRAIN is actually (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN)
> > > > > so I decided to test with just GPIO_SINGLE_ENDED and it works.
> > >
> > > Shawn,
> > >
> > > I quote from the PCIe Mini Card Electromechanical Specification Rev 1.2
> > >
> > > "3.4.1. Logic Signal Requirements
> > >
> > > The 3.3V card logic levels for single-ended digital signals (WAKE#,
> > > CLKREQ#, PERST#, and W_DISABLE#) are given in Table 3-7. [...]"
> > >
> > > So while you are correct that PERST# is most definitely not Open Drain,
> > > there's evidence on the spec that defines this signal as Single-Ended.
> > >
> >
> > This's true. But I couldn't find any user in dts using either
> > GPIO_SINGLE_ENDED or GPIO_OPEN_DRAIN for PCIe PERST#. I'm curious
> > how these two flags affect actual behavior of chips. Ye, could you
> > please help check it?
>
> FWIW I assume single-ended in the spec means it's not differential
> like all the highspeed signals on the PCIe connection. This says
> nothing about open-drain, open-source or push-pull being used. The
yes, I agree. It was an oversight on my part to assume open-drain on
PERST# was part of the spec just because many cores implement it that
way. Kudos to Shawn for correcting me.
> kernel on the other hand has a very specific understanding of
> GPIO_SINGLE_ENDED:
>
> if (flags & OF_GPIO_SINGLE_ENDED) {
> if (flags & OF_GPIO_OPEN_DRAIN)
> lflags |= GPIO_OPEN_DRAIN;
> else
> lflags |= GPIO_OPEN_SOURCE;
> }
>
> I.e. it is the same as configuring open-source ;)
Yup, I had noticed that. This works because the reset value of PMU GRF
register PMUGRF_GPIO0B_P sets the relevant PERST# GPIO (GPIO0-12) on my
board to pull-down, which can work with Open Source/Emitter. If we set
the GPIO to Open Drain/Collector we must on the other hand set that pin
to pull-up. Either way it works.
I've been investigating why that GPIO isn't properly working as
Push-Pull for my board (Rock PI N10) but so far I'm clueless.
Thank you,
Geraldo Nascimento
>
> Greetings,
>
> -- Sebastian
WARNING: multiple messages have this Message-ID (diff)
From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>
Cc: "Shawn Lin" <shawn.lin@rock-chips.com>,
"Ye Zhang" <ye.zhang@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kwilczynski@kernel.org>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
linux-pci@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
"Krzysztof Kozlowski" <krzk+dt@kernel.org>,
"Conor Dooley" <conor+dt@kernel.org>,
"Johan Jonker" <jbx6244@gmail.com>,
linux-rockchip@lists.infradead.org
Subject: Re: [PATCH] arm64: dts: rockchip: align bindings to PCIe spec
Date: Sat, 8 Nov 2025 19:43:17 -0300 [thread overview]
Message-ID: <aQ_HhfK0pbOE1m1R@geday> (raw)
In-Reply-To: <sbulnlwz3vxyk3yw2c2tcsdvyu57cdvyixkpeq2okh4vn6yyod@4o4kltfb5u6n>
On Sat, Nov 08, 2025 at 11:12:54PM +0100, Sebastian Reichel wrote:
> Hi,
Hi Sebastian,
>
> On Fri, Nov 07, 2025 at 11:01:04AM +0800, Shawn Lin wrote:
> > + Ye Zhang
> >
> > 在 2025/11/07 星期五 10:43, Geraldo Nascimento 写道:
> > > On Wed, Nov 05, 2025 at 04:56:36PM +0800, Shawn Lin wrote:
> > > > 在 2025/11/05 星期三 16:18, Geraldo Nascimento 写道:
> > > > > Hi Shawn, glad to hear from you.
> > > > >
> > > > > Perhaps the following change is better? It resolves the issue
> > > > > without the added complication of open drain. After you questioned
> > > > > if open drain is actually part of the spec, I remembered that
> > > > > GPIO_OPEN_DRAIN is actually (GPIO_SINGLE_ENDED | GPIO_LINE_OPEN_DRAIN)
> > > > > so I decided to test with just GPIO_SINGLE_ENDED and it works.
> > >
> > > Shawn,
> > >
> > > I quote from the PCIe Mini Card Electromechanical Specification Rev 1.2
> > >
> > > "3.4.1. Logic Signal Requirements
> > >
> > > The 3.3V card logic levels for single-ended digital signals (WAKE#,
> > > CLKREQ#, PERST#, and W_DISABLE#) are given in Table 3-7. [...]"
> > >
> > > So while you are correct that PERST# is most definitely not Open Drain,
> > > there's evidence on the spec that defines this signal as Single-Ended.
> > >
> >
> > This's true. But I couldn't find any user in dts using either
> > GPIO_SINGLE_ENDED or GPIO_OPEN_DRAIN for PCIe PERST#. I'm curious
> > how these two flags affect actual behavior of chips. Ye, could you
> > please help check it?
>
> FWIW I assume single-ended in the spec means it's not differential
> like all the highspeed signals on the PCIe connection. This says
> nothing about open-drain, open-source or push-pull being used. The
yes, I agree. It was an oversight on my part to assume open-drain on
PERST# was part of the spec just because many cores implement it that
way. Kudos to Shawn for correcting me.
> kernel on the other hand has a very specific understanding of
> GPIO_SINGLE_ENDED:
>
> if (flags & OF_GPIO_SINGLE_ENDED) {
> if (flags & OF_GPIO_OPEN_DRAIN)
> lflags |= GPIO_OPEN_DRAIN;
> else
> lflags |= GPIO_OPEN_SOURCE;
> }
>
> I.e. it is the same as configuring open-source ;)
Yup, I had noticed that. This works because the reset value of PMU GRF
register PMUGRF_GPIO0B_P sets the relevant PERST# GPIO (GPIO0-12) on my
board to pull-down, which can work with Open Source/Emitter. If we set
the GPIO to Open Drain/Collector we must on the other hand set that pin
to pull-up. Either way it works.
I've been investigating why that GPIO isn't properly working as
Push-Pull for my board (Rock PI N10) but so far I'm clueless.
Thank you,
Geraldo Nascimento
>
> Greetings,
>
> -- Sebastian
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-11-08 22:43 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-05 5:55 [PATCH] arm64: dts: rockchip: align bindings to PCIe spec Geraldo Nascimento
2025-11-05 5:55 ` Geraldo Nascimento
2025-11-05 6:35 ` Shawn Lin
2025-11-05 6:35 ` Shawn Lin
2025-11-05 8:18 ` Geraldo Nascimento
2025-11-05 8:18 ` Geraldo Nascimento
2025-11-05 8:56 ` Shawn Lin
2025-11-05 8:56 ` Shawn Lin
2025-11-05 20:02 ` Geraldo Nascimento
2025-11-05 20:02 ` Geraldo Nascimento
2025-11-07 2:43 ` Geraldo Nascimento
2025-11-07 2:43 ` Geraldo Nascimento
2025-11-07 3:01 ` Shawn Lin
2025-11-07 3:01 ` Shawn Lin
2025-11-08 22:12 ` Sebastian Reichel
2025-11-08 22:12 ` Sebastian Reichel
2025-11-08 22:43 ` Geraldo Nascimento [this message]
2025-11-08 22:43 ` Geraldo Nascimento
2025-11-11 5:06 ` Geraldo Nascimento
2025-11-11 5:06 ` Geraldo Nascimento
[not found] ` <AGsAmwCFJj0ZQ4vKzrqC84rs.3.1762847224180.Hmail.ye.zhang@rock-chips.com>
2025-11-12 8:03 ` Geraldo Nascimento
2025-11-12 8:03 ` Geraldo Nascimento
2025-11-13 1:09 ` Geraldo Nascimento
2025-11-13 1:09 ` Geraldo Nascimento
2025-11-14 4:41 ` Geraldo Nascimento
2025-11-14 4:41 ` Geraldo Nascimento
2025-11-14 9:16 ` Shawn Lin
2025-11-14 9:16 ` Shawn Lin
2025-11-14 20:34 ` Geraldo Nascimento
2025-11-14 20:34 ` Geraldo Nascimento
2025-11-15 2:21 ` Shawn Lin
2025-11-15 2:21 ` Shawn Lin
2025-11-15 7:02 ` Geraldo Nascimento
2025-11-15 7:02 ` Geraldo Nascimento
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=aQ_HhfK0pbOE1m1R@geday \
--to=geraldogabriel@gmail.com \
--cc=bhelgaas@google.com \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=heiko@sntech.de \
--cc=jbx6244@gmail.com \
--cc=krzk+dt@kernel.org \
--cc=kwilczynski@kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=robh@kernel.org \
--cc=sebastian.reichel@collabora.com \
--cc=shawn.lin@rock-chips.com \
--cc=ye.zhang@rock-chips.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.