Re: [PATCH RFC 0/5] arm64: rockchip: enable PCIE3 controller and its phy for Rock5B boards

From: Qu Wenruo <wqu@suse.com>
To: Sebastian Reichel <sebastian.reichel@collabora.com>,
	Peter Geis <pgwipeout@gmail.com>
Cc: Piotr Oniszczuk <piotr.oniszczuk@gmail.com>,
	"open list:ARM/Rockchip SoC..."
	<linux-rockchip@lists.infradead.org>,
	linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	heiko@sntech.de, lucas.tanure@collabora.com
Subject: Re: [PATCH RFC 0/5] arm64: rockchip: enable PCIE3 controller and its phy for Rock5B boards
Date: Wed, 22 Feb 2023 07:39:32 +0800	[thread overview]
Message-ID: <b5953c8e-1796-2ce2-9a63-7dc06ec83f3d@suse.com> (raw)
In-Reply-To: <20230221214517.5rjtwpftcj5dugdl@mercury.elektranox.org>

On 2023/2/22 05:45, Sebastian Reichel wrote:
> Hi everyone,
> 
[...]
>>
>> If the phy is misconfigured, not powered, or the clocks aren't going
>> active, you'll hang when the controller tries to touch it. Unless
>> someone has completed the combophy rk3588 bits the driver is not
>> functional yet for rk3588.
>>
>> Looking at the current 6.2 release, I only see the rk3568 compatible,
>> so you'll need to add support for rk3588 before it will work.
>>
>> Very Respectfully,
>> Peter Geis
> 
> Sorry for being late to the game. Life is busy right now :)

Welcome back!

> 
> I haven't looked into PCIe myself so far, but some of my colleagues
> are looking into native network support on Rock 5B (and thus PCIe2
> controller).
> 
> Apart from the obvious (missing rk3588 support in the combophy driver),
> the clocks will need some work. The clock tree implementation I upstreamed
> is different from the downstream implementation. Downstream has some
> clocks that have two parent clocks using a hacked implementation
> that's obviously not upstreamable as is. The upstream implementation
> currently only describes the first parent. More details are in the
> following comment:

Thanks for the details!

No wonder why the combo phy doesn't work.

I tried checking the downstream driver, and can only find trivial 
differences between rk3588 and rk3568 naneng combo drivers.

But didn't notice the clock problems.

BTW, is there any docs on all the registers?
For the combo phy drivers, there are some registers only utilized by 
3588 but not 356x, thus docs on this would be very helpful.

Thanks,
Qu

> 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/clk/rockchip/clk-rk3588.c#n16
> 
> Back than I wrote that I do not understand the exact need (the TRM
> does not describe the clock tree unfortuantely), I found this
> explanation:
> 
> https://lore.kernel.org/dri-devel/20220309094139198367142@rock-chips.com/
> 
> To get the advanced blocks properly running upstream this needs a
> solution for this. Note that trying to access registers that are
> not clocked properly will result in a hang (as Peter already wrote).
> 
> Apart from that the power-domain controller might need some of the
> extra bits downstream has.
> 
> Last but not least the GIC controller is handled differently in
> downstream. For that following the workaround that has been used for
> rk356x should also work for rk3588.
> 
> TLDR: This is not trivial. It's really unfortunate, that the board
> is not just using the native ethernet :(
> 
> P.S.: We try to keep a rk3588 / Rock 5 status matrix maintained here:
> 
> https://gitlab.collabora.com/hardware-enablement/rockchip-3588/notes-for-rockchip-3588/-/blob/main/mainline-status.md
> 
> Greetings,
> 
> -- Sebastian