Re: [PATCH v1 0/3] Add Luckfox Omni3576 Carrier Board support for RK3576

[Nicolas Frattaroli <nicolas.frattaroli@collabora.com>]

On Friday, 2 May 2025 22:55:30 Central European Summer Time John Clark wrote:
> This series adds device tree support for the Luckfox Omni3576 Carrier Board
> with Core3576 Module, developed by Shenzhen Luckfox Technology Co., Ltd., based
> on the Rockchip RK3576 SoC. The board supports various peripherals, with this
> initial implementation enabling essential functionality for booting Linux and
> basic connectivity.
> 
> Supported and tested features (on Linux 6.15-rc4):
> - UART: Serial console operational.
> - SD card: Mounts and reads/writes successfully.
> - PCIe: NVMe SSD detected via lspci.
> - Ethernet 0: Functional with RGMII PHY.
> - USB: Host ports detect devices.
> - RTC: Timekeeping and wake-up tested.
> - LED: Heartbeat trigger works.

Hi John,

> 
> Disabled features:
> - eMMC: Not populated on the tested board; believed to be functional but disabled.
> - HDMI: Disabled due to mainline driver maturity issues (basic 1080p output works; audio and 4K untested).

that's not a good reason to disable the node, in my eyes. HDMI 2.0 4K output 
should work AFAIK, HDMI audio will land with the already posted SAI audio 
controller patch set. Is there any specific issue like an SoC lock-up you ran 
into that is keeping you from enabling it? If so, please do let the mailing list 
know.

> - Ethernet 1: Disabled as it does not come up, possibly due to PHY configuration or driver issues.
> 
> Patch 1: Add luckfox vendor prefix for Shenzhen Luckfox Technology Co., Ltd.
> Patch 2: Add luckfox,omni3576 binding to rockchip.yaml
> Patch 3: Add rk3576-luckfox-omni3576.dts and Makefile update
> 
> The new DTS is covered by the existing ROCKCHIP ARCHITECTURE entry in MAINTAINERS.
> 
> I am aware of ongoing RK3576 upstreaming efforts (e.g., by Collabora) and
> welcome feedback or collaboration to align with mainline driver development.

I can't speak for the longer term outlook as that's neither my area of expertise
nor my position to make statements about that, but I can give a general overview
of what I myself am working on right now in relation to the RK3576. The general
theme is that most of the low-hanging fruit has already been plucked, so the
bigger drivers remain.

- RK3576 USB Type-C OTG stuff: the USB 2 PHY driver needed some changes to make
  this work. I've yet to send out v2 that reworks the way we detect a type-C
  port, but that part of the code is already done. I was basically just letting
  it stew on my local machine for a bit longer to see if I can figure out why
  superspeed only works in one cable orientation, and to give the mailing list
  some room to breathe, as I've been sending quite a bit of stuff lately.
- RK3576 HWRNG: has already been posted by me, and it's a small enough series
  that I don't see many problems on the horizon with it.
- RK3576 eMMC PD fix: this needed a few revisions but was merged just recently
- RK3576 Thermal ADC: v5 is currently awaiting review, and it's quite a mature
  series by now.
- RK3576 SAI (Audio Output): driver + binding already merged, sent out a v3
  recently to fix an issue with the clock driver part of that patch series.
- RK3576 PWM: v1 of my MFPWM patch series needs some changes. I plan on getting
  around to this in the coming week, bar any other more pressing things on my
  table.
- RK3576 SATA: I sent a tiny patch series to enable this, and it was already
  merged in time for v6.16.

If you do want a small driver to work on that should be easy to port to mainline
and hasn't been done yet, I recommend SPDIFRX. You can find it in
`sound/soc/rockchip/rockchip_spdifrx.c` in the vendor tree. It's around 400
lines, and on your board you should be able to have a pin on the 40-pin header
that can be set to pinmux to the SPDIFRX controller, namely pin 35, aka
GPIO4_B2, aka the third-to-last pin on the side that ends with a GND. You will
need some source of an SPDIF audio signal at the right voltage for that. The
most humorous choice is either the board itself or another Rockchip SBC.

If the driver is a straight-forward port and minor cleanup, leaving the original
author in place for the patch sent upstream is the courteous thing to do. If
there's more work involved than just a few lines changed or downstream-specific
parts deleted, I usually like to include the original author with their signoff
in a `Co-developed-by:` tag, to give credit where credit is due.

I should also mention that Collabora has a public issue tracker on our GitLab
to keep track of Rockchip upstreaming matters. An issue being on it doesn't
necessarily mean that we have any plans to work on it, it just means an engineer
remembered this was a thing and noted it down. Things we actively are working
on are usually assigned to a specific person, unless said person (me, usually)
forgets to do so. You can find it here:
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/linux/-/issues

> 
> Signed-off-by: John Clark <inindev@gmail.com>
> 

Kind regards,
Nicolas Frattaroli