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@xxxxxxxxxxxxxx/
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
