[PATCHv3 0/9] RK3588 Clock and Reset Support

[Qu Wenruo]

On 2022/11/22 02:28, Sebastian Reichel wrote:
> Hi Qu,
> 
> On Mon, Nov 21, 2022 at 04:52:22PM +0800, Qu Wenruo wrote:
>> On 2022/10/18 23:13, Sebastian Reichel wrote:
>>> This has been part of a bigger patchset adding basic rk3588 support.
>>> Since that gets more and more out of hand, I'm now sending patches
>>> for each subsystem as individual patchset.
>>
>> Awesome work! Thanks for the work to bring upstream support for RK3588.
>>
>> This upstream work is especially important since the vendor kernel has so
>> many weird things and is never properly tested using newer tool chains.
>>
>> But considering the support has been split into different patchset, is there
>> a git repo that I can fetch all the patches and test it on my Rock5B board?
> 
> try linux-next + https://lore.kernel.org/all/20221121175814.68927-1-sebastian.reichel@collabora.com/
> 
> It should boot, but that's about it. For Rock 5B there is not even
> ethernet support, since that needs PCIe. Ideally the DT series makes
> it in time for the 6.2 merge window.
> 
> Alternatively my working branch (I rebase that!) is available here:
> https://git.kernel.org/pub/scm/linux/kernel/git/sre/linux-misc.git/log/?h=rk3588
> It adds PMIC, thermal and cpufrequency support.

Sorry for the late reply, finally got my extra rock5b to do experiments.
(The existing one is now a VM host for 24x7 fstests runs)

[TEST REPORT]
Yes, I got the expected-to-work parts working:

- ttyS2 (serial at feb50000)
   Both earlycon and later initialized console.

- eMMC (mmc at fe2e0000)
   The rootfs read write seems fine.

   The latest code seems to have sdmmc, but ironically I don't have
   any sdcard at hand right now...

[PCIE ENABLEMENT]
Personally speaking, I can not care less about things like GMAC (Rock5B 
uses r8125), nor USB (PCIE rules them all) nor graphics (serial is good 
neough).

Thus I'm trying to see if I can re-use the rk3568 pcie drivers.

It looks like unlike RK3399, this time we need PHY for PCIE, and it is 
already done in rk3568 pcie controller, and the core AIX->PCIE is done 
by the designware core, thus it looks feasible to reuse the driver?

But I can be totally wrong, since I'm really just a newbie in arm world.

Any hint on the PCIE bus bringup? Or what I can help for the PCIE bringup?

I know RK3588S seems to cut the PCIE3 lanes completely, and droped one 
PCIE2.0 lane, but I don't know the address for the cut one...

[VENDOR KERNEL PCIE BUG]
Another thing I noticed with vendor (5.10.x) kernel is, the PCIE link up 
is unreliable, causing random reset.
Maybe the incoming upstream bring up can fix it?

Thanks,
Qu

> 
> -- Sebastian