Re: Rockchip RK3588

Johann Rudloff <[email protected]> wrote:
>On 15/09/2025 17:21, Robert Swindells wrote:
>> I have got the PCIe PHY and host controller drivers from OpenBSD to compile.
>> 
>> The host controller isn't doing anything when it the driver attach
>> function enables link training.
>> 
>> My next thing to check is whether all the power stuff for it is enabled
>> so have started looking at your tree.
>
> Nice to hear that there's progress in that area!

I spotted that Linux prints an error at startup that the link training
has failed but the PCIe devices work once it has fully booted.

Also u-boot doesn't initially detect any PCIe devices either but will
load efiboot then a kernel from the NVMe drive if I let it.

I have just made my driver continue after the link training error and
am working through converting the rest of the OpenBSD code.

Have used your changes to rk_cru.[ch] and rk3588_cru.[ch] then added
some more reset definitions on top.

>> The way that you have done the RK806 driver by putting an SPI attachment
>> in an I2C source file looks messy to me, it doesn't share anything with
>> the i2c code.
>
> Fair enough.  Initially I thought there could be some code shared 
> between RK805 and RK806 (the later one could be attached either via I2C 
> or SPI).  But in any case the right approach would be to extract the 
> common stuff and keep only the transport-related pieces in i2c/ or spi/ 
> directories.

I downloaded the manual for the RK806 after sending my previous email
and saw it could be attached to either interface.

We could define bus_space(9) implementations for i2c and spi then make
the RK80x drivers use them.

>> I have split it out into its own file under dev/spi in my tree and made
>> some changes to match the recent spi updates.
>> 
>> Copied across your rkpmu driver, how complete do you think this is?
>
> Unfortunately, the rkpmic is probably the hackiest part in my whole 
> patch stack (ignoring rkvop2) :(
> The only thing rk806 driver can do right now is power off the device. 
> It has lots of debugging prints and commented-out code left.
>
> I will start by cleaning up the patch implementing half-duplex transfer 
> for rkspi in a 3-wire setup, which was the main effort needed to start 
> talking to the rk806.  Then it could use some testing on different 
> devices to make sure it doesn't break the 4-wire use case.

Maybe define some symbols too, there are a lot of raw numbers in your
code.

> Is your tree available somewhere public so I could have a look at the
> current status?

I am just developing in my local CVS tree but can put the new files
on ftp.NetBSD.org.


Where did your scmi driver come from? It doesn't have a copyright
header.

The existing SCMI driver in the NetBSD tree is derived from an older
version of the OpenBSD one, though OpenBSD only had a device tree
attachment and NetBSD only has an ACPI one.

It seems to be ARM specific so putting it under arch/arm as you have
done feels better to me than under dev/ic.

I think it would be good if there was only one implementation in the
three that was shared by fdt and acpi attachments.

Robert Swindells