All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rudi Heitbaum <rudi@heitbaum.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: onboard_dev: add the Rockchip rk1808
Date: Fri, 28 Aug 2026 13:24:34 +0000	[thread overview]
Message-ID: <apGMEsCwly8TCOww@5be1eda4e59e> (raw)
In-Reply-To: <4512468.iIbC2pHGDl@diego>

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
> 
> 
> 

WARNING: multiple messages have this Message-ID (diff)
From: Rudi Heitbaum <rudi@heitbaum.com>
To: "Heiko Stübner" <heiko@sntech.de>
Cc: Matthias Kaehlcke <mka@chromium.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	linux-usb@vger.kernel.org, linux-rockchip@lists.infradead.org,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] usb: onboard_dev: add the Rockchip rk1808
Date: Fri, 28 Aug 2026 13:24:34 +0000	[thread overview]
Message-ID: <apGMEsCwly8TCOww@5be1eda4e59e> (raw)
In-Reply-To: <4512468.iIbC2pHGDl@diego>

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
> 
> 
> 

_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip

  reply	other threads:[~2026-08-28 13:24 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24  2:52 [PATCH] usb: onboard_dev: add the Rockchip rk1808 Rudi Heitbaum
2026-08-24  2:52 ` Rudi Heitbaum
2026-08-27 13:25 ` Heiko Stuebner
2026-08-27 13:25   ` Heiko Stuebner
2026-08-28 10:55   ` Rudi Heitbaum
2026-08-28 10:55     ` Rudi Heitbaum
2026-08-28 12:14     ` Heiko Stübner
2026-08-28 12:14       ` Heiko Stübner
2026-08-28 13:24       ` Rudi Heitbaum [this message]
2026-08-28 13:24         ` Rudi Heitbaum
2026-08-31  1:41         ` Chaoyi Chen
2026-08-31  1:41           ` Chaoyi Chen
2026-09-01 11:42           ` Rudi Heitbaum
2026-09-01 11:42             ` Rudi Heitbaum
2026-09-02  1:39             ` Chaoyi Chen
2026-09-02  1:39               ` Chaoyi Chen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=apGMEsCwly8TCOww@5be1eda4e59e \
    --to=rudi@heitbaum.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=heiko@sntech.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-rockchip@lists.infradead.org \
    --cc=linux-usb@vger.kernel.org \
    --cc=mka@chromium.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.