Re: [PATCH] usb: onboard_dev: add the Rockchip rk1808

From: Rudi Heitbaum

Date: Fri Aug 28 2026 - 09:25:13 EST


On Fri, Aug 28, 2026 at 02:14:22PM +0200, Heiko Stübner wrote:
> Hi Rudi,
>
> Am Freitag, 28. August 2026, 12:55:56 Mitteleuropäische Sommerzeit schrieb Rudi Heitbaum:
> > On Thu, Aug 27, 2026 at 03:25:23PM +0200, Heiko Stuebner wrote:
> > > Am Montag, 24. August 2026, 04:52:02 Mitteleuropäische Sommerzeit schrieb Rudi Heitbaum:
> > > > The rk1808 is the npu die in an rk3399pro package. It is wired to one
> > > > of the usb3 controllers rather than to an external port, and it needs
> > > > its reference clock running before it will boot, which is exactly what
> > > > this driver exists to do for onboard devices.
> > > >
> > > > It takes no supply from the driver: the rails are sequenced elsewhere.
> > > > Only the clock matters here, and that is already optional and handled
> > > > generically.
> > >
> > > the "elsewhere" might need a bit more explanation to verify it's the right
> > > implementation. Even if the regulators are always-on or something, we
> > > still want the supplies defined - for future uses.
> >
> > As follow up on the bringup of the Rock-Pi-N10, the proposed change to the dtsi
> > for the rk3399pro-vmarc-som is here, but needs the provision of the usb first.
> > https://github.com/heitbaum/linux/commit/6b114b6fff4022c330003d7f70ce09915ffd774f
>
> I might have formulated that strangly, what I meant was, who is enabling
> the power supplies.
>
> The "NPU Power" part of any rk3399pro schematics (should) list 5 power
> supplies for the NPU block itself:
>
> NPU_LOGIC_VDD
> --> regulator likely named NPU_VDD_LOG_S0
> --> enabled by NPU_PWREN_2 gpio fixed regulator
>
> NPU_EFUSE_VQPS
> --> regulator likely named NPU_VCC1V8_EFUSE
> --> enabled by NPU_EFUSE_EN_H gpio fixed regulator
>
> NPU_CORE_VDD
> --> regulator likely named NPU_VDD_S0
> --> TCS4525 regulator with voltage being set via the i2c controller
> inside the NPU - but enabled by the NPU_PWREN_6 gpio from
> core RK3399.
>
> NPU_CPU_VDD
> --> regulator likely named NPU_VDD_CPU_S0
> --> enabled by NPU_PWREN_4 gpio fixed regulator
>
> NPU_ADC_AVDD_1V8
> --> regulator likely named NPU_VCC_1V8_S3
> --> enabled by NPU_PWREN_3 gpio fixed regulator
>
> Naming might vary, I found just some EVB schematics.
>
> Someone needs to enable these, so the question was, who is doing that?

Hi Heiko,

I hadn't looked in to these from the mainline viewpoint. I had been
using an adapted vendor script based on the radxa npu_powerctl binary
which reimplements the npu_reset sequence over GPIO.

This has been the sequence:

gpio0 line 4 NPU_PWREN_1 -> 1, 2 ms
gpio0 line 10 NPU_PWREN_2 -> 1, 2 ms
gpio0 line 11 NPU_PWREN_3 -> 1, 2 ms
gpio1 line 22 -> 1, 2 ms
gpio1 line 23 -> 1, 2 ms
gpio1 line 24 NPU_PWREN_6 -> 1, 25 ms
gpio1 line 0 -> 1 (reset release)

I have the schematics and the working N10 here, so let me look into
describing these in the .dts and update the onboard_usb_dev.h.

Would you prefer that once I have a working and tested dts description of
the rk1808 - submit the onboard_usb_dev.h and rk3399pro-vmarc-som.dtsi
changes as a patchset - or just update the onboard_usb_dev.h as a v2?

Regards
Rudi

> Thanks
> Heiko
>
>
>