From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-rockchip@lists.infradead.org,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rick wertenbroek" <rick.wertenbroek@gmail.com>,
linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required
Date: Mon, 30 Jun 2025 14:55:05 -0300 [thread overview]
Message-ID: <aGLPeZn9ZSw3FurH@geday> (raw)
In-Reply-To: <2affed16-f3c4-47d3-9ca6-e4f48e875367@arm.com>
On Mon, Jun 30, 2025 at 02:48:25PM +0100, Robin Murphy wrote:
> On 29/06/2025 9:58 pm, Geraldo Nascimento wrote:
> > Current code enables only Lane 0 because pwr_cnt will be incremented on
> > first call to the function. Let's reorder the enablement code to enable
> > all 4 lanes through GRF.
>
> As usual the TRM isn't very clear, but the way it describes the
> GRF_SOC_CON_5_PCIE bits does suggest they're driving external input
> signals of the phy block, so it seems reasonable that it could be OK to
> update the register itself without worrying about releasing the phy from
> reset first. In that case I'd agree this seems the cleanest fix, and if
> it works empirically then I think I'm now sufficiently convinced too;
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Hi Robin and Neil,
Thank you both for the positive reviews and the effort.
I must admit however that it looks like this patch was lifted verbatim
from Armbian and I'm missing the Signed-off-by from the original author.
As Robin may attest, I initially started by blindingly enabling all
lanes which, of course, is no good. I tried a suggestion by Robin which
did not work, and eventually settled on this Armbian solution, which at
least has got some battle-testing.
I already contacted Valmintas Paliksa, the original author of the patch,
and asked permission to use his Signed-off-by. I'm aware I could probably
use the Signed-off-by without strict permission, but it does not feel
right to me.
Thanks,
Geraldo Nascimento
WARNING: multiple messages have this Message-ID (diff)
From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-rockchip@lists.infradead.org,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rick wertenbroek" <rick.wertenbroek@gmail.com>,
linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required
Date: Mon, 30 Jun 2025 14:55:05 -0300 [thread overview]
Message-ID: <aGLPeZn9ZSw3FurH@geday> (raw)
In-Reply-To: <2affed16-f3c4-47d3-9ca6-e4f48e875367@arm.com>
On Mon, Jun 30, 2025 at 02:48:25PM +0100, Robin Murphy wrote:
> On 29/06/2025 9:58 pm, Geraldo Nascimento wrote:
> > Current code enables only Lane 0 because pwr_cnt will be incremented on
> > first call to the function. Let's reorder the enablement code to enable
> > all 4 lanes through GRF.
>
> As usual the TRM isn't very clear, but the way it describes the
> GRF_SOC_CON_5_PCIE bits does suggest they're driving external input
> signals of the phy block, so it seems reasonable that it could be OK to
> update the register itself without worrying about releasing the phy from
> reset first. In that case I'd agree this seems the cleanest fix, and if
> it works empirically then I think I'm now sufficiently convinced too;
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Hi Robin and Neil,
Thank you both for the positive reviews and the effort.
I must admit however that it looks like this patch was lifted verbatim
from Armbian and I'm missing the Signed-off-by from the original author.
As Robin may attest, I initially started by blindingly enabling all
lanes which, of course, is no good. I tried a suggestion by Robin which
did not work, and eventually settled on this Armbian solution, which at
least has got some battle-testing.
I already contacted Valmintas Paliksa, the original author of the patch,
and asked permission to use his Signed-off-by. I'm aware I could probably
use the Signed-off-by without strict permission, but it does not feel
right to me.
Thanks,
Geraldo Nascimento
--
linux-phy mailing list
linux-phy@lists.infradead.org
https://lists.infradead.org/mailman/listinfo/linux-phy
WARNING: multiple messages have this Message-ID (diff)
From: Geraldo Nascimento <geraldogabriel@gmail.com>
To: Robin Murphy <robin.murphy@arm.com>
Cc: linux-rockchip@lists.infradead.org,
"Shawn Lin" <shawn.lin@rock-chips.com>,
"Lorenzo Pieralisi" <lpieralisi@kernel.org>,
"Krzysztof Wilczyński" <kw@linux.com>,
"Manivannan Sadhasivam" <mani@kernel.org>,
"Rob Herring" <robh@kernel.org>,
"Bjorn Helgaas" <bhelgaas@google.com>,
"Heiko Stuebner" <heiko@sntech.de>,
"Vinod Koul" <vkoul@kernel.org>,
"Kishon Vijay Abraham I" <kishon@kernel.org>,
"Rick wertenbroek" <rick.wertenbroek@gmail.com>,
linux-phy@lists.infradead.org, linux-pci@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required
Date: Mon, 30 Jun 2025 14:55:05 -0300 [thread overview]
Message-ID: <aGLPeZn9ZSw3FurH@geday> (raw)
In-Reply-To: <2affed16-f3c4-47d3-9ca6-e4f48e875367@arm.com>
On Mon, Jun 30, 2025 at 02:48:25PM +0100, Robin Murphy wrote:
> On 29/06/2025 9:58 pm, Geraldo Nascimento wrote:
> > Current code enables only Lane 0 because pwr_cnt will be incremented on
> > first call to the function. Let's reorder the enablement code to enable
> > all 4 lanes through GRF.
>
> As usual the TRM isn't very clear, but the way it describes the
> GRF_SOC_CON_5_PCIE bits does suggest they're driving external input
> signals of the phy block, so it seems reasonable that it could be OK to
> update the register itself without worrying about releasing the phy from
> reset first. In that case I'd agree this seems the cleanest fix, and if
> it works empirically then I think I'm now sufficiently convinced too;
>
> Reviewed-by: Robin Murphy <robin.murphy@arm.com>
Hi Robin and Neil,
Thank you both for the positive reviews and the effort.
I must admit however that it looks like this patch was lifted verbatim
from Armbian and I'm missing the Signed-off-by from the original author.
As Robin may attest, I initially started by blindingly enabling all
lanes which, of course, is no good. I tried a suggestion by Robin which
did not work, and eventually settled on this Armbian solution, which at
least has got some battle-testing.
I already contacted Valmintas Paliksa, the original author of the patch,
and asked permission to use his Signed-off-by. I'm aware I could probably
use the Signed-off-by without strict permission, but it does not feel
right to me.
Thanks,
Geraldo Nascimento
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next prev parent reply other threads:[~2025-06-30 18:24 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-29 12:47 [PATCH v7 0/4] PCI: rockchip: Improve driver quality Geraldo Nascimento
2025-06-29 12:47 ` Geraldo Nascimento
2025-06-29 12:47 ` Geraldo Nascimento
2025-06-29 12:47 ` [PATCH v7 1/4] PCI: rockchip: Use standard PCIe defines Geraldo Nascimento
2025-06-29 12:47 ` Geraldo Nascimento
2025-06-29 12:47 ` Geraldo Nascimento
2025-06-29 12:48 ` [PATCH v7 2/4] PCI: rockchip: Set Target Link Speed before retraining Geraldo Nascimento
2025-06-29 12:48 ` Geraldo Nascimento
2025-06-29 12:48 ` Geraldo Nascimento
2025-06-29 12:48 ` [PATCH v7 4/4] phy: rockchip-pcie: Properly disable TEST_WRITE strobe signal Geraldo Nascimento
2025-06-29 12:48 ` Geraldo Nascimento
2025-06-29 12:48 ` Geraldo Nascimento
2025-06-30 8:49 ` neil.armstrong
2025-06-30 8:49 ` neil.armstrong
2025-06-30 8:49 ` neil.armstrong
2025-06-29 20:58 ` [PATCH v7 3/4] phy: rockchip-pcie: Enable all four lanes if required Geraldo Nascimento
2025-06-29 20:58 ` Geraldo Nascimento
2025-06-29 20:58 ` Geraldo Nascimento
2025-06-30 8:49 ` neil.armstrong
2025-06-30 8:49 ` neil.armstrong
2025-06-30 8:49 ` neil.armstrong
2025-06-30 13:48 ` Robin Murphy
2025-06-30 13:48 ` Robin Murphy
2025-06-30 13:48 ` Robin Murphy
2025-06-30 17:55 ` Geraldo Nascimento [this message]
2025-06-30 17:55 ` Geraldo Nascimento
2025-06-30 17:55 ` Geraldo Nascimento
2025-07-21 14:52 ` Geraldo Nascimento
2025-07-21 14:52 ` Geraldo Nascimento
2025-07-21 14:52 ` 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=aGLPeZn9ZSw3FurH@geday \
--to=geraldogabriel@gmail.com \
--cc=bhelgaas@google.com \
--cc=heiko@sntech.de \
--cc=kishon@kernel.org \
--cc=kw@linux.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pci@vger.kernel.org \
--cc=linux-phy@lists.infradead.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=lpieralisi@kernel.org \
--cc=mani@kernel.org \
--cc=rick.wertenbroek@gmail.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=shawn.lin@rock-chips.com \
--cc=vkoul@kernel.org \
/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.