* [PATCH v13 00/27] Add new general DRM property "color format"
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: Dmitry Baryshkov, linux-doc, Andy Yan, intel-gfx, linux-kernel,
dri-devel, Nicolas Frattaroli, linux-rockchip, Andri Yngvason,
amd-gfx, Werner Sembach, Marius Vlad, kernel, intel-xe,
linux-arm-kernel
Hello,
this is a follow-up to
https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
which in of itself is a follow-up to
https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/ where
a new DRM connector property has been added allowing users to
force a particular color format.
That in turn was actually also a follow-up from Werner Sembach's posted at
https://lore.kernel.org/dri-devel/20210630151018.330354-1-wse@tuxedocomputers.com/
As the number of cooks have reached critical mass, I'm hoping I'll be
the last person to touch this particular series.
We have an implementation in Weston at
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1825 that
adds support for this property. This patch series has been tested
against that MR on i915 (HDMI, DP), amdgpu (HDMI, DP) and on rockchip
(HDMI).
You can also manually test this with modetest like so, but beware that
this is a non-atomic invocation, so testing YUV420 like this will result
in weird outcomes if only some of the modes support YUV420:
$ modetest -s 115:1920x1080-60@NV12 -w 115:'color format':4
where 115 is the connector ID and '4' is the enum value for a particular
color format.
General notes on the approach taken by me: instead of silently switching
to a different format than was explicitly requested, or even worse,
outputting something to the sink the sink doesn't support, bubble up an
error to userspace instead. "color format" is a "I want this" type
property, not a "force this" type property, i.e. the kernel will respect
the limits imposed by the hardware.
Things I've tested:
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3588
- HDMI (YCbCr 4:4:4 + YCbCr 4:2:2 (8-bit) + RGB + Auto) on RK3576
- HDMI + DP (YCbCr 4:4:4, YCbCr 4:2:0, RGB, Auto) on Intel N97 (i915).
- HDMI (YCbCr 4:4:4, YCbCr 4:2:2, YCbCr 4:2:0, RGB, Auto) + DP (YCbCr
4:4:4, RGB, Auto) on an AMD Radeon RX 550 (amdgpu).
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
Changes in v13:
- Introduce a new drm_connector_funcs member that returns the
connector state's color format with additional bells and whistles.
- Implement this new func in drm_bridge_connector to return whatever the
HDMI implementation did if an HDMI bridge is present.
- Call into the drm_connector.h function wrapping this new func in the
recursive bridge chain bus format selection code.
- Link to v12: https://patch.msgid.link/20260409-color-format-v12-0-ce84e1817a27@collabora.com
Changes in v12:
- Rebase on top of Ville's i915 format selection cleanup series
- i915: Reimplement based on new format selection code. Drop the DP-MST
implementation, as sinks with different sets of supported formats
complicate the matter.
- Adjust documentation on drm_connector_color_format enum values to
mention quantization ranges.
- Add documentation to drm-kms page to document the string values for
the property. Mostly the same documentation as the enum values, but
from a more userspace-centric perspective. This is done in the patch
that introduces the property, but I didn't drop the existing R-b as
it isn't a functional change.
- Update documentation of "colorspace" property to mention that "color
format" property controls the output format.
- amdgpu: Remove property from DP-MST, as it's unclear whether it'd work
properly with sinks that have different sets of supported formats
- Link to v11: https://patch.msgid.link/20260324-color-format-v11-0-605559af4fb4@collabora.com
Changes in v11:
- amdgpu: fix property registration on DP-MST
- i915: fix property registration on DP-MST
- rebase on drm-tip, which includes Maxime's refactor series that was
previously declared a dependency of this series
- Link to v10: https://lore.kernel.org/r/20260305-color-format-v10-0-a58c68a11868@collabora.com
Changes in v10:
- Make DRM_OUTPUT_COLOR_FORMAT_COUNT and
DRM_CONNECTOR_COLOR_FORMAT_COUNT part of the enum definition (thanks
to Maxime)
- Preemptively avoid the warning that would be generated by the
enumification of DRM_OUTPUT_COLOR_FORMAT_COUNT by modifying the
problematic switch statement in drm_hdmi_state_helper's
sink_supports_format_bpc.
- drm/bridge: Change HDMI check from checking for the last bridge having
a DRM_BRIDGE_OP_HDMI in ops to checking if last_bridge->type is HDMIA.
This is not quite the suggestion Dmitry had, but according to the
documentation of the drm_bridge.type member, and the
display-connector.c code, it should be correct.
- Combine drm_mode_create_color_format_property and
drm_connector_attach_color_format_property into one function named the
latter. (thanks to Dmitry Baryshkov)
- Change author of 'drm: Add new general DRM property "color format"'
to myself as it has by now changed quite a bit, and add Andri and
Werner as Co-developed-by, as per Andri's suggestion.
- hdmi-state-helper: Rework hdmi_compute_config to make code flow more
obvious, and drop Dmitry's R-b as a consequence (thanks to Maxime)
- Move dw-hdmi-qp's atomic_get_output_bus_fmts into
drm_bridge_helper.c, along with kernel doc string (thanks to Dmitry)
- Future-proof the aforementioned get_output_bus_fmts use of hweight8 on
the supported_formats bitmask with a BUILD_BUG_ON.
- Add a KUnit test for the HDMI output bus formats helper
- Link to v9: https://lore.kernel.org/r/20260227-color-format-v9-0-658c3b9db7ef@collabora.com
Changes in v9:
- Document what the "AUTO" behaviour is in the color format enum (thanks
to Maxime)
- drm/bridge: dw-hdmi-qp: Fix a rebase oopsie that reintroduced some
functions that were dropped. (thanks to Cristian)
- drm/bridge: Shuffle "1:1" in the bridge fmt selection docs to earlier
in the sentence. (thanks to Randy Dunlap)
- i915: Check chosen output format against requested format for dp-mst
- All color format driver implementations: rebase and rework on top of
Maxime's series
- As part of this rework, rename drm_color_format_enum to
drm_connector_color_format
- drm kunit tests: rework for the new enums. Changes were trivial, so
trailers were kept
- Link to v8: https://lore.kernel.org/r/20260216-color-format-v8-0-5722ce175dd5@collabora.com
Changes in v8:
- Drop "drm/rockchip: vop2: Fix YUV444 output", as the original problem
could not be reproduced anymore, and the justification did not make
sense.
- Remove the 12-bit format from "drm/rockchip: vop2: Recognise 10/12-bit
YUV422 as YUV formats".
- Refactor to keep the original DRM_COLOR_FORMAT bitshifted defines
as-is, but introduce a new drm_color_format_enum enum.
- Adjust conversion functions for the newly refactored enum, ensuring
they only return valid enum values, and only convert in directions
that open up no error value cans of worms.
- Rework the property uapi code for the newly refactored enum, since
it no longer needs to do any bitshifting or ffs().
- Rework all the device drivers for the new enum.
- Rework all the tests for the refactored enum.
- Rework the hdmi state helper for the new enum, and also make it more
explicit about the auto behaviour by not relying on a conversion
function to map AUTO to RGB, but do this in the framework itself.
- rockchip dw_hdmi_qp: Fix the GRF value to check for color >= 0 instead
of color > 0, as the latter broke switching back to RGB.
- Rebase onto a recent drm-tip. This necessitated blindly reworking some
of the i915 dp-mst code.
- Drop the __maybe_unused edid test patch, as I could no longer
reproduce the build warnings I added it for. I blame ghosts.
- drm_bridge tests: remove "destroyed" member from struct
drm_bridge_chain_priv and all associated code, as it was not used in
any test.
- Link to v7: https://lore.kernel.org/r/20260121-color-format-v7-0-ef790dae780c@collabora.com
Changes in v7:
- Fix drm_bridge kunit test build failure caused by rebasing across an
API change.
- Make compilers shut up about unused EDID definitions in the test
suites.
- Empty line checkpatch fixes that b4 prep --check didn't catch.
- Link to v6: https://lore.kernel.org/r/20260121-color-format-v6-0-7b81a771cd0b@collabora.com
Changes in v6:
- Checkpatch fixes
- Add drm_bridge.c kerneldoc fix patch to b4 deps so the kernel docs
required for every contribution to the subsystem can be built
- dw-hdmi-qp core has gained the atomic_get_output_bus_fmts bridge func,
which allows it to participate in the drm_bridge chain recursive format
selection code properly.
- The Rockchip dw-hdmi-qp integration now no longer reimplements the
color format logic (improperly), but reads the bus format of the first
bridge as set by the recursive bridge format selection. If the input
format is FIXED, it'll use the output format. Otherwise, the input
format is used.
- In the synopsys drivers, YUV422 uses the same bus format as the non-qp
hdmi encoder driver. Probably correcter this way. The Rockchip vop2
is_yuv function has been extended to recognise this format as well.
- KUnit tests for drm_bridge chains are now included, which exercise the
chain's recursive bus format selection.
- On HDMI connectors, the drm_bridge bus format selection will try to target
the color format that the HDMI layer came up with. This means the AUTO
logic is not duplicated for HDMI connectors.
- The enum conversion function commit gained a function for converting
from hdmi_colorspace to drm_color_format, and its author changed as no
original code remains anyway. Marius is still included as a
Co-developer.
- Some tests for the HDMI state helper's mode_valid have been written.
They are incomplete as we lack a test EDID for a 420-also mode that
would violate the clock constraints on RGB. I hacked one together with
a hex editor, but it reports a too high of a clock rate, and there's
no EDID editor I could find which supports these extension blocks.
- The color_format KUnit tests have been more heavily parameterised, the
auto case absorbed into other tests, and the comments around them
rewritten.
- Add a few paragraphs of documentation that explain the bridge format
selection, and how to make use of it in a display driver.
- Link to v5: https://lore.kernel.org/r/20251128-color-format-v5-0-63e82f1db1e1@collabora.com
Changes in v5:
- Rebase onto drm-tip
- Drop DRM_MODE_COLOR_FORMAT_* as an enum
- Unify DRM_COLOR_FORMAT_NONE and DRM_COLOR_FORMAT_AUTO, with AUTO being
0. This makes conversion and general logic much easier.
- Adjust the drm_color_format enum to not needlessly renumber the
existing defines, as it doesn't need to correspond to how HDMI numbers
them.
- Make the DRM-to-HDMI conversion function static inline __pure, because
the assembly it generates is tiny, and the function is pure.
- Don't accept nothing as the list of supported color formats for
registration of the property.
- Drop the per-connector variants of the color format registration
function, as it's not needed.
- drm_hdmi_state_helper: Fix mode_valid rejecting 420-only modes.
- drm_hdmi_state_helper: Only fall back to YUV420 with
DRM_COLOR_FORMAT_AUTO.
- drm_hdmi_state_helper: Remove redundant AUTO->RGB condition, as the
conversion already does this.
- Add KUnit tests for hdmi_compute_config.
- drm/bridge: Refactor bus_format_is_color_fmt and add a few more YUV422
formats.
- Register the color format property in drmm_connector_hdmi_init based
on the supported HDMI formats passed to it. This means rockchip
dw_hdmi_qp no longer needs to register it.
- amdgpu: Simplify YUV420 logic
- amdgpu: Don't try to pick YUV444 on YUV420-only modes
- i915: Try to make behaviour more or less the same as that of the drm
hdmi state helper.
- rockchip dw_hdmi_qp: Set supported HDMI formats
- rockchip dw_hdmi_qp: Set the right VO GRF values depending on color
format.
- rockchip dw_hdmi_qp: Act on the color format property in this driver,
rather than in VOP2, by setting the bus_format appropriately.
- rockchip VOP2: Can the BCSH-based implementation. BCSH isn't available
on all video ports of the hardware, and the code was extremely
suspect. Instead, plug into the existing YUV-to-RGB/RGB-to-YUV code,
which can be done now that the HDMI driver sets the bus format.
- A whole bunch of Rockchip VOP2 fixes.
- Link to v4: https://lore.kernel.org/r/20251117-color-format-v4-0-0ded72bd1b00@collabora.com
Changes in v4:
- Rebase onto next-20251117
- Get rid of HDMI_COLORSPACE_AUTO
- Split hdmi_compute_config change into separate patch
- Add missing symbol export for color_format_to_hdmi_colorspace to fix
builds in certain configurations
- Drop "drm: Pass supported color formats straight onto drm_bridge"
- Make dw-hdmi-qp set the platform data's supported color formats as
the bridge's supported HDMI color formats
- drm_hdmi_state_helper: pass requested color format to
hdmi_compute_format_bpc if set.
- drm_bridge: limit the bus formats to those explicitly requested with
the color format property during the atomic bridge check call,
specifically in drm_atomic_bridge_chain_select_bus_fmts.
- i915: Remove INTEL_OUTPUT_FORMAT_AUTO, as automatic format selection
does not need to involve the hardware state
- i915: Deduplicate ntel_output_format_to_drm_color_format code by
moving it as a static inline __pure function into a shared header
- i915: rework logic in HDMI, DP and DP-MST output config functions to
remove redundant locals, simplify execution flow, and return an error
to userspace if an explicit color_format request can't be satisfied.
- i915: assign myself as the author and make the others Co-developers,
so that they don't get the blame for any of my bugs.
- amdgpu: refactor fill_stream_properties_from_drm_display_mode to
improve readability and ensure that impossible color format requests
get bubbled up to userspace as errors
- amdgpu: don't pick YUV444 over RGB.
- amdgpu: assign authorship to myself, with others as Co-developers, as
logic was modified and the blame should fall on me
- dw_hdmi_qp-rockchip: set the supported color formats platform data
member
- rockchip: remove drm property registration for rk3066_hdmi and
inno_hdmi. None of the platforms that use these use vop2 as the
video output processor.
- Link to v3: https://lore.kernel.org/all/20250911130739.4936-1-marius.vlad@collabora.com/
Changes in v3 by mvlad compared to Andri's v2 series:
- renamed the property to just 'color format'
- the property is added dynamically similar to the Colorspace property
- a key point from previous comments was that drivers should advertise
the color formats they support and userspace would query EDID and
perform an intersection from those color formats which users can
further use. With this patch set each driver that adds this property
has such list of hard-coded color formats, but fundamentally the idea
is that driver can query the HW and do that on its own. The
infrastructure is now in place to allow to do that
- by default the 'AUTO' color format is set. With this patch series that
has been introduced as a fallback to RGB. Drivers could further
customize this behavour and could perform additional checks on the sink
to pick another suitable color format they'd like for AUTO
- drm_bridge bridge code has been improved to allow initialization with
the same color formats list as the DRM connector property. Similarly, bpc
pick-up now takes the color format into consideration when deciding
which bpc to choose from
- The new DRM color format re-uses HDMI_COLORPSACE enum and provides an
enum translations between the two to avoid touching all other drivers that
use HDMI_COLORPSACE enum. I believe at this point that this allows the
least amount of disruption and avoids a massive bike shedding around
that part
- a rockchip implementation has been by my colleague Derek Foreman
- YUV444 color format has been added in i915
- address comment about "Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A
check" where aconnector might be invalid
- Link to v2: https://lore.kernel.org/dri-devel/20240115160554.720247-1-andri@yngvason.is/
---
Nicolas Frattaroli (26):
drm/display: hdmi-state-helper: Use default case for unsupported formats
drm: Add new general DRM property "color format"
drm/connector: Let connectors have a say in their color format
drm/display: bridge_connector: Use HDMI color format for HDMI conns
drm/bridge: Act on the DRM color format property
drm/atomic-helper: Add HDMI bridge output bus formats helper
drm/display: hdmi-state-helper: Act on color format DRM property
drm/display: hdmi-state-helper: Try subsampling in mode_valid
drm/amdgpu: Implement "color format" DRM property
drm/i915/hdmi: Add YCBCR444 handling for sink formats
drm/i915/dp: Add YCBCR444 handling for sink formats
drm/i915: Implement the "color format" DRM property
drm/rockchip: Add YUV422 output mode constants for VOP2
drm/rockchip: vop2: Add RK3576 to the RG swap special case
drm/rockchip: vop2: Recognise 10-bit YUV422 as YUV format
drm/rockchip: vop2: Set correct output format for RK3576 YUV422
drm/bridge: dw-hdmi-qp: Use common HDMI output bus fmts helper
drm/rockchip: dw_hdmi_qp: Implement "color format" DRM property
drm/rockchip: dw_hdmi_qp: Set supported_formats platdata
drm/connector: Register color format property on HDMI connectors
drm/tests: hdmi: Add tests for the color_format property
drm/tests: hdmi: Add tests for HDMI helper's mode_valid
drm/tests: bridge: Add KUnit tests for bridge chain format selection
drm/tests: bridge: Add test for HDMI output bus formats helper
drm/bridge: Document bridge chain format selection
drm/connector: Update docs of "colorspace" for color format prop
Werner Sembach (1):
drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
Documentation/gpu/drm-kms-helpers.rst | 6 +
Documentation/gpu/drm-kms.rst | 6 +
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 91 +-
drivers/gpu/drm/bridge/synopsys/dw-hdmi-qp.c | 1 +
drivers/gpu/drm/display/drm_bridge_connector.c | 24 +
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 53 +-
drivers/gpu/drm/drm_atomic_helper.c | 86 ++
drivers/gpu/drm/drm_atomic_uapi.c | 11 +
drivers/gpu/drm/drm_bridge.c | 104 ++-
drivers/gpu/drm/drm_connector.c | 178 +++-
drivers/gpu/drm/i915/display/intel_connector.c | 10 +
drivers/gpu/drm/i915/display/intel_connector.h | 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 43 +-
drivers/gpu/drm/i915/display/intel_hdmi.c | 47 +-
drivers/gpu/drm/rockchip/dw_hdmi_qp-rockchip.c | 111 ++-
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 4 +
drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 21 +-
drivers/gpu/drm/tests/drm_bridge_test.c | 971 +++++++++++++++++++++
drivers/gpu/drm/tests/drm_hdmi_state_helper_test.c | 345 ++++++++
include/drm/drm_atomic_helper.h | 7 +
include/drm/drm_connector.h | 120 +++
21 files changed, 2203 insertions(+), 37 deletions(-)
---
base-commit: e3dc6072028a594d5e9bfc6476165842602d5307
change-id: 20251028-color-format-49fd202b7183
prerequisite-message-id: <20260409101539.22032-1-ville.syrjala@linux.intel.com>
prerequisite-patch-id: f382aeb5da5f2b8f6e2cb22b88eb47f490f2c724
prerequisite-patch-id: 20570aeb28e3c31353e6f697b193b23d8b47c47c
prerequisite-patch-id: 1b7e24034883b22cd82be025a1cf82ae77170fd0
prerequisite-patch-id: 6ec2dc2c05a75391b67cb12d93168f5e8da8ec55
prerequisite-patch-id: 32e84581998ef4eef05e1681c7ec36b90f2a6bb7
prerequisite-patch-id: 99c2187a846b0c9ac2ea1a892c17483120cb7da1
prerequisite-patch-id: fb41b4668a3b7c8c375c67ffd6b178fa3273e86a
prerequisite-patch-id: 4c115a36eea0d5f80643dc34310690894ac80e0e
prerequisite-patch-id: 6fdec0832cd6062de3cc5c2f363c5d624d8a00f9
Best regards,
--
Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH v13 02/27] drm/display: hdmi-state-helper: Use default case for unsupported formats
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: linux-doc, intel-gfx, linux-kernel, dri-devel, Nicolas Frattaroli,
linux-rockchip, amd-gfx, kernel, intel-xe, linux-arm-kernel
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
Switch statements that do not handle all possible values of an
enumeration will generate a warning during compilation. In preparation
for adding a COUNT value to the end of the enum, this needs to be dealt
with.
Add a default case to sink_supports_format_bpc's DRM_OUTPUT_COLOR_FORMAT
switch statement, and move the log-and-return unknown pixel format
handling into it.
No functional change.
Reviewed-by: Maxime Ripard <mripard@kernel.org>
Reviewed-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/display/drm_hdmi_state_helper.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/display/drm_hdmi_state_helper.c b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
index 9f3b696aceeb..a0d88701d236 100644
--- a/drivers/gpu/drm/display/drm_hdmi_state_helper.c
+++ b/drivers/gpu/drm/display/drm_hdmi_state_helper.c
@@ -541,10 +541,11 @@ sink_supports_format_bpc(const struct drm_connector *connector,
drm_dbg_kms(dev, "YUV444 format supported in that configuration.\n");
return true;
- }
- drm_dbg_kms(dev, "Unsupported pixel format.\n");
- return false;
+ default:
+ drm_dbg_kms(dev, "Unsupported pixel format.\n");
+ return false;
+ }
}
static enum drm_mode_status
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v13 01/27] drm/amd/display: Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check
From: Nicolas Frattaroli @ 2026-04-13 10:07 UTC (permalink / raw)
To: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan
Cc: kernel, amd-gfx, dri-devel, linux-kernel, linux-arm-kernel,
linux-rockchip, intel-gfx, intel-xe, linux-doc,
Nicolas Frattaroli, Werner Sembach, Andri Yngvason
In-Reply-To: <20260413-color-format-v13-0-ab37d4dfba48@collabora.com>
From: Werner Sembach <wse@tuxedocomputers.com>
Remove unnecessary SIGNAL_TYPE_HDMI_TYPE_A check that was performed in the
drm_mode_is_420_only() case, but not in the drm_mode_is_420_also() &&
force_yuv420_output case.
Without further knowledge if YCbCr 4:2:0 is supported outside of HDMI,
there is no reason to use RGB when the display
reports drm_mode_is_420_only() even on a non HDMI connection.
This patch also moves both checks in the same if-case. This eliminates an
extra else-if-case.
Signed-off-by: Werner Sembach <wse@tuxedocomputers.com>
Signed-off-by: Andri Yngvason <andri@yngvason.is>
Tested-by: Andri Yngvason <andri@yngvason.is>
Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
---
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 9 +++------
1 file changed, 3 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index c2066319772b..ad9714382d5f 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -6780,12 +6780,9 @@ static void fill_stream_properties_from_drm_display_mode(
timing_out->v_border_top = 0;
timing_out->v_border_bottom = 0;
/* TODO: un-hardcode */
- if (drm_mode_is_420_only(info, mode_in)
- && stream->signal == SIGNAL_TYPE_HDMI_TYPE_A)
- timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
- else if (drm_mode_is_420_also(info, mode_in)
- && aconnector
- && aconnector->force_yuv420_output)
+ if (drm_mode_is_420_only(info, mode_in) ||
+ (aconnector && aconnector->force_yuv420_output &&
+ drm_mode_is_420_also(info, mode_in)))
timing_out->pixel_encoding = PIXEL_ENCODING_YCBCR420;
else if ((connector->display_info.color_formats & BIT(DRM_OUTPUT_COLOR_FORMAT_YCBCR422))
&& aconnector
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* Re: [PATCH] drm/mipi-dsi: Only remove child devices that match the dsi device type
From: Chaoyi Chen @ 2026-04-13 3:19 UTC (permalink / raw)
To: dri-devel, linux-kernel, linux-rockchip
Cc: Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Sandy Huang, Andy Yan, Heiko Stuebner
In-Reply-To: <20251203115028.133-1-kernel@airkyi.com>
Hi,
On 12/3/2025 7:50 PM, Chaoyi Chen wrote:
> From: Chaoyi Chen <chaoyi.chen@rock-chips.com>
>
> This patch checks whether the device is a valid mipi_dsi_device before
> accessing it in mipi_dsi_remove_device_fn().
>
> The mipi_dsi_host_unregister() assumes that all child devices of the
> host device are mipi_dsi_devices and uses mipi_dsi_remove_device_fn()
> to perform subsequent operations specific to mipi_dsi_device.
>
> In rockchip platform, for dw-mipi-dsi-rockchip.c, it creates a dphy
> device, and it use the dsi host device as its parent device.
>
> And when we call dw_mipi_dsi_remove() in
> dw_mipi_dsi_rockchip_remove(), mipi_dsi_host_unregister() will get
> such a dphy child device and treat it as an mipi_dsi_device, which
> will lead to a further panic.
>
> Signed-off-by: Chaoyi Chen <chaoyi.chen@rock-chips.com>
> ---
> drivers/gpu/drm/drm_mipi_dsi.c | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_mipi_dsi.c b/drivers/gpu/drm/drm_mipi_dsi.c
> index a712e177b350..5b9cc799eb87 100644
> --- a/drivers/gpu/drm/drm_mipi_dsi.c
> +++ b/drivers/gpu/drm/drm_mipi_dsi.c
> @@ -349,7 +349,12 @@ EXPORT_SYMBOL(mipi_dsi_host_register);
>
> static int mipi_dsi_remove_device_fn(struct device *dev, void *priv)
> {
> - struct mipi_dsi_device *dsi = to_mipi_dsi_device(dev);
> + struct mipi_dsi_device *dsi;
> +
> + if (!dev_is_mipi_dsi(dev))
> + return 0;
> +
> + dsi = to_mipi_dsi_device(dev);
>
> if (dsi->attached)
> mipi_dsi_detach(dsi);
Gentle ping about this.
Thanks!
--
Best,
Chaoyi
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Mark Brown @ 2026-04-12 16:24 UTC (permalink / raw)
To: Liam Girdwood, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, Anushka Badhe
Cc: linux-sound, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260410055532.60868-1-anushkabadhe@gmail.com>
On Fri, 10 Apr 2026 11:25:32 +0530, Anushka Badhe wrote:
> ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
Applied to
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git for-7.1
Thanks!
[1/1] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
https://git.kernel.org/broonie/sound/c/115e7d764dad
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v3 00/13] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
From: Bob McChesney @ 2026-04-12 16:36 UTC (permalink / raw)
To: Jonas Karlman
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Christian Hewitt,
Diederik de Haas, dri-devel, linux-rockchip, linux-kernel
In-Reply-To: <20260403185303.80748-1-jonas@kwiboo.se>
On Fri, 03 Apr 2026 18:52:46 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
> drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
>
> This is a revival of an old dw-hdmi series and is the first series part
> of a new effort to upstream old LibreELEC HDMI 2.0 patches for Rockchip
> RK33xx devices.
>
> This series ensure poweron/poweroff and CEC phys addr invalidation is
> happening under drm mode_config mutex lock, and also ensure EDID is
> updated after a HPD low voltage pulse by changing to debounce hotplug
> processing.
>
> [...]
Tested-by: Bob McChesney <bob@electricworry.net>
--
Bob McChesney <bob@electricworry.net>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v3 00/13] drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
From: Bob McChesney @ 2026-04-12 15:52 UTC (permalink / raw)
To: Jonas Karlman
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Christian Hewitt,
Diederik de Haas, dri-devel, linux-rockchip, linux-kernel
In-Reply-To: <20260403185303.80748-1-jonas@kwiboo.se>
On Fri, 03 Apr 2026 18:52:46 +0000, Jonas Karlman <jonas@kwiboo.se> wrote:
> drm: bridge: dw_hdmi: Misc enable/disable, CEC and EDID cleanup
>
> This is a revival of an old dw-hdmi series and is the first series part
> of a new effort to upstream old LibreELEC HDMI 2.0 patches for Rockchip
> RK33xx devices.
>
> This series ensure poweron/poweroff and CEC phys addr invalidation is
> happening under drm mode_config mutex lock, and also ensure EDID is
> updated after a HPD low voltage pulse by changing to debounce hotplug
> processing.
>
> [...]
Tested-by: Bob McChesney <bob@electricworry.net>
--
Bob McChesney <bob@electricworry.net>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v2] ASoC: dt-bindings: rockchip: convert rk3399-gru-sound to DT Schema
From: Krzysztof Kozlowski @ 2026-04-12 9:18 UTC (permalink / raw)
To: Anushka Badhe
Cc: Liam Girdwood, Mark Brown, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Heiko Stuebner, linux-sound, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260410055532.60868-1-anushkabadhe@gmail.com>
On Fri, Apr 10, 2026 at 11:25:32AM +0530, Anushka Badhe wrote:
> Convert the rockchip,rk3399-gru-sound.txt DT binding to DT Schema
> format.
>
> Update rockchip,cpu from a single I2S controller phandle to a
> phandle-array. Add an optional second entry for the SPDIF controller,
> as seen in rk3399-gru.dtsi, required by boards with DisplayPort audio.
>
> Signed-off-by: Anushka Badhe <anushkabadhe@gmail.com>
> ---
> Changes in v2:
> - Fix subject and body: "YAML Schema" -> "DT Schema"
> - Fix title: "ROCKCHIP" -> "Rockchip"
> - List items for rockchip,cpu with I2S and SPDIF descriptions
> - List items for rockchip,codec
> - Update descriptions for rockchip,cpu, rockchip,codec and
> dmic-wakeup-delay-ms
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [GIT PULL] Rockchip clock changes for 7.1 #1
From: Stephen Boyd @ 2026-04-11 23:15 UTC (permalink / raw)
To: Heiko Stuebner, mturquette; +Cc: linux-clk, linux-rockchip
In-Reply-To: <3746710.R56niFO833@phil>
Quoting Heiko Stuebner (2026-03-30 06:42:00)
> Hi Mike, Stephen,
>
> please find below a pull-request with a Rockchip clock change for 7.1
> One new clock driver and sone newly accessible existing clocks.
>
> Please pull.
>
> Thanks
> Heiko
>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.1-rockchip-clk1
>
> for you to fetch changes up to 41b1a6760959017c4fa1dbc7c3cc318406ab1455:
>
> clk: rockchip: rk3568: Add PCIe pipe clock gates (2026-03-10 09:34:27 +0100)
>
> ----------------------------------------------------------------
Thanks. Pulled into clk-next
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Alexey Charkov @ 2026-04-11 18:00 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Peter Robinson, Michael Riesch, Mykola Kvach, Jimmy Hon,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-4-dennis@ausil.us>
On Sat, Apr 11, 2026 at 6:47 AM <dennis@ausil.us> wrote:
>
> From: Dennis Gilmore <dennis@ausil.us>
>
> Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
>
> - eMMC module, you can optionally solder a SPI NOR in place and turn
> off the eMMC
> - PCIe-attached NIC (pcie2x1l1)
> - PCIe NVMe slot (pcie2x1l2)
> - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> - BCM4345C5 Bluetooth
> - es8388 audio
> - USB 2.0 and USB 3.0
> - Two HDMI ports, the second is connected to the SoC's DP controller
> driven by a transparent LT8711UXD bridge that has firmware onboard and
> needs no node defined.
>
> Vendors description and links to schematics available:
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
Hi Dennis,
The most useful of these is the schematic, so it's best to include a
direct link to that in a dedicated Link: tag
Link: https://drive.google.com/file/d/1qs1DratHuh7C6J6MEtQIwUsiSrg8qgTi/view
[schematic]
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> .../display/rockchip/rockchip,dw-dp.yaml | 7 +
> arch/arm64/boot/dts/rockchip/Makefile | 1 +
> .../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
> drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
These should be three separate patches, never lumped together. First
the binding change, next the driver change. They go together via the
subsystem tree (likely DRM in this case). Then the DTS addition (or
change) separately (it goes via the SoC tree).
> 4 files changed, 372 insertions(+)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
>
> diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> index 6345f0132d43..079a912d97f1 100644
> --- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> +++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
> @@ -57,6 +57,13 @@ properties:
> - const: i2s
> - const: spdif
>
> + hpd-gpios:
> + maxItems: 1
> + description:
> + GPIO used for hot plug detection when the controller's native HPD
> + input is not connected. If not specified, the controller uses its
> + internal HPD detection mechanism.
Do you actually need this change? According to the schematic, the
DP_HPDIN line from the DP-HDMI bridge is routed to the native
DP0_HPDIN_M0 pin of the DP controller, so it shouldn't require this
GPIO trick if the pinctrl is configured properly.
> phys:
> maxItems: 1
>
> diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
> index 4d384f153c13..c99dca2ae9e7 100644
> --- a/arch/arm64/boot/dts/rockchip/Makefile
> +++ b/arch/arm64/boot/dts/rockchip/Makefile
> @@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
> +dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
> dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> new file mode 100644
> index 000000000000..84c83aa69f63
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
> @@ -0,0 +1,352 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +
> +/dts-v1/;
> +
> +#include "rk3588s-orangepi-5.dtsi"
> +
> +/ {
> + model = "Xunlong Orange Pi 5 Pro";
> + compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
> +
> + aliases {
> + mmc0 = &sdhci;
> + mmc1 = &sdmmc;
> + mmc2 = &sdio;
> + };
> +
> + dp-con {
> + compatible = "dp-connector";
You don't have a physical DP connector on the board, so this node
doesn't describe actual hardware, and is thus a no-go. What you have
instead is an HDMI type A connector routed via an onboard DP to HDMI
bridge, so you should describe exactly that in the device tree (a node
for the HDMI connector, a node for the bridge, a node for the DP
controller, and endpoints connected from the controller to the bridge,
from the bridge to the connector). Please refer to the device tree for
Radxa Rock 5 ITX, which has a similar setup (but a different bridge
IC).
I don't think your LT8711UXD has existing binding or driver entry, so
a one-line patch will likely be needed to
Documentation/devicetree/bindings/display/bridge/simple-bridge.yaml,
and a separate one to drivers/gpu/drm/bridge/simple-bridge.c. Separate
ones :)
> + port {
> + dp_con_in: endpoint {
> + remote-endpoint = <&dp0_out_con>;
> + };
> + };
> + };
> +
> + analog-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_detect>;
> + simple-audio-card,bitclock-master = <&masterdai>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&masterdai>;
> + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,name = "rockchip,es8388";
> + simple-audio-card,routing =
> + "Headphones", "LOUT1",
> + "Headphones", "ROUT1",
> + "LINPUT1", "Microphone Jack",
> + "RINPUT1", "Microphone Jack",
> + "LINPUT2", "Onboard Microphone",
> + "RINPUT2", "Onboard Microphone";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Microphone", "Onboard Microphone",
> + "Headphone", "Headphones";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s2_2ch>;
> + };
> +
> + masterdai: simple-audio-card,codec {
> + sound-dai = <&es8388>;
> + system-clock-frequency = <12288000>;
> + };
> + };
> +
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + led-0 {
> + color = <LED_COLOR_ID_BLUE>;
> + function = LED_FUNCTION_STATUS;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm15 0 1000000 0>;
> + };
> +
> + led-1 {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_ACTIVITY;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm3 0 1000000 0>;
> + };
> + };
> +
> + fan: pwm-fan {
> + compatible = "pwm-fan";
> + #cooling-cells = <2>;
> + cooling-levels = <0 50 100 150 200 255>;
> + fan-supply = <&vcc5v0_sys>;
> + pwms = <&pwm2 0 20000000 0>;
> + };
> +
> + vcc3v3_dp: regulator-vcc3v3-dp {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
Please don't forget to add explicit pinctrl nodes for each GPIO pin
you use (here and in other places like this). These GPIOs happen to
work on Linux without configuring their pin control first, but that is
pure luck and coincidence due to how the respective Linux subsystems
are wired together, and if you ever need to use this device tree in
e.g. U-boot (which also derives its DTS from the Linux kernel tree) it
will break there.
> + regulator-always-on;
> + regulator-boot-on;
Does it have to be always-on, boot-on? This looks like a hack to work
around the fact that you didn't define the bridge node, which uses
this as its supply. Please model the dependencies explicitly - most
likely that will let you drop these attributes.
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
It's two separate regulators on your schematic, one DCDC at 1.25V and
the other a load switch at 3.3V, driving six separate voltage inputs
of the DP bridge. They are both controlled by the same GPIO pin
though, so _maybe_ it's okay to have just one "virtual" node like this
to model them together. Would be great for the DT maintainers to weigh
in on this.
> + regulator-name = "vcc3v3_dp";
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc3v3_phy1: regulator-vcc3v3-phy1 {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
> + regulator-boot-on;
See above
> + regulator-max-microvolt = <3300000>;
> + regulator-min-microvolt = <3300000>;
> + regulator-name = "vcc3v3_phy1";
> + startup-delay-us = <50000>;
> + vin-supply = <&vcc_3v3_s3>;
> + };
> +
> + vcc5v0_otg: regulator-vcc5v0-otg {
> + compatible = "regulator-fixed";
> + enable-active-high;
> + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&vcc5v0_otg_en>;
> + regulator-max-microvolt = <5000000>;
> + regulator-min-microvolt = <5000000>;
> + regulator-name = "vcc5v0_otg";
> + vin-supply = <&vcc5v0_sys>;
> + };
> +
> + sdio_pwrseq: sdio-pwrseq {
> + compatible = "mmc-pwrseq-simple";
> + clocks = <&hym8563>;
> + clock-names = "ext_clock";
> + post-power-on-delay-ms = <200>;
> + reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
This GPIO also needs a pinctrl
> + };
> +
> + typea_con: usb-a-connector {
> + compatible = "usb-a-connector";
> + data-role = "host";
> + label = "USB3 Type-A";
> + power-role = "source";
> + vbus-supply = <&vcc5v0_otg>;
> + };
> +};
> +
> +&dp0 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&dp0m0_pins>;
This switches your HPD pin to the native DP controller handling
(DP0_HPDIN_M0), so the GPIO bits you've patched into the controller
driver aren't even used, and it doesn't look like you tested that code
path.
> + status = "okay";
> +};
> +
> +&dp0_in {
> + dp0_in_vp1: endpoint {
> + remote-endpoint = <&vp1_out_dp0>;
> + };
> +};
> +
> +&dp0_out {
> + dp0_out_con: endpoint {
> + remote-endpoint = <&dp_con_in>;
This will need to be rewritten once you add the proper bridge chain
leading up to the HDMI type A connector.
> + };
> +};
> +
> +&i2c1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c1m4_xfer>;
> + status = "okay";
> +};
> +
> +&i2c3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c3m0_xfer>;
> + status = "okay";
> +
> + es8388: audio-codec@11 {
> + compatible = "everest,es8388", "everest,es8328";
> + reg = <0x11>;
> + #sound-dai-cells = <0>;
> + AVDD-supply = <&vcc_3v3_s0>;
Are you sure? Schematic says VCCA_3V3_S0, which is a different
regulator (PLDO4 output of the PMIC)
> + DVDD-supply = <&vcc_1v8_s0>;
Schematic says VCCA_1V8_S0, which is a different regulator (PLDO1
output of the PMIC)
> + HPVDD-supply = <&vcc_3v3_s0>;
Schematic says VCCA_3V3_S0
> + PVDD-supply = <&vcc_3v3_s0>;
Schematic says VCCA_1V8_S0
> + assigned-clock-rates = <12288000>;
> + assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
> + clocks = <&cru I2S2_2CH_MCLKOUT>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s2m1_mclk>;
> + };
> +};
> +
> +&i2c4 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2c4m3_xfer>;
> + status = "okay";
> +};
> +
> +&i2s2_2ch {
> + pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
> + &i2s2m1_sdi &i2s2m1_sdo>;
> + status = "okay";
> +};
> +
> +&package_thermal {
> + polling-delay = <1000>;
> +
> + cooling-maps {
> + map0 {
> + trip = <&package_fan0>;
> + cooling-device = <&fan THERMAL_NO_LIMIT 1>;
> + };
> +
> + map1 {
> + trip = <&package_fan1>;
> + cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
> + };
> + };
> +
> + trips {
> + package_fan0: package-fan0 {
> + hysteresis = <2000>;
> + temperature = <55000>;
> + type = "active";
> + };
> +
> + package_fan1: package-fan1 {
> + hysteresis = <2000>;
> + temperature = <65000>;
> + type = "active";
> + };
> + };
> +};
> +
> +/* NVMe */
> +&pcie2x1l1 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
> + reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
The GPIO also needs a pinctrl
> + supports-clkreq;
> + vpcie3v3-supply = <&vcc_3v3_s3>;
> + status = "okay";
> +};
> +
> +/* NIC */
> +&pcie2x1l2 {
> + reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
The GPIO also needs a pinctrl
> + vpcie3v3-supply = <&vcc3v3_phy1>;
> + status = "okay";
> +};
> +
> +&pinctrl {
> + bluetooth {
> + bt_wake_gpio: bt-wake-pin {
> + rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> +
> + bt_wake_host_irq: bt-wake-host-irq {
> + rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +
> + usb {
> + vcc5v0_otg_en: vcc5v0-otg-en {
> + rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
> + };
> + };
> +
> + wlan {
> + wifi_host_wake_irq: wifi-host-wake-irq {
> + rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
> + };
> + };
> +};
> +
> +&pwm15 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm15m2_pins>;
> + status = "okay";
> +};
> +
> +&pwm2 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm2m1_pins>;
> + status = "okay";
> +};
> +
> +&pwm3 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&pwm3m2_pins>;
> + status = "okay";
> +};
> +
> +&sdhci {
> + status = "okay";
> +};
> +
> +&sdio {
> + #address-cells = <1>;
> + #size-cells = <0>;
> + bus-width = <4>;
> + cap-sd-highspeed;
> + cap-sdio-irq;
> + keep-power-in-suspend;
> + max-frequency = <150000000>;
> + mmc-pwrseq = <&sdio_pwrseq>;
> + no-mmc;
> + no-sd;
> + non-removable;
> + sd-uhs-sdr104;
> + status = "okay";
> +
> + ap6256: wifi@1 {
> + compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
> + reg = <1>;
> + interrupt-names = "host-wake";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&wifi_host_wake_irq>;
> + };
> +};
> +
> +&uart9 {
> + pinctrl-names = "default";
> + pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
> + uart-has-rtscts;
> + status = "okay";
> +
> + bluetooth {
> + compatible = "brcm,bcm4345c5";
> + clocks = <&hym8563>;
> + clock-names = "lpo";
> + device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
> + interrupt-names = "host-wakeup";
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
> + max-speed = <1500000>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
> + shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
> + vbat-supply = <&vcc_3v3_s3>;
> + vddio-supply = <&vcc_1v8_s3>;
> + };
> +};
> +
> +&usb_host0_xhci {
> + dr_mode = "host";
> +};
> +
> +&usbdp_phy0 {
> + rockchip,dp-lane-mux = <0 1>;
I'm wondering if the DP controller's "out" endpoint should go to the
PHY instead of directly to the connector/bridge. That would describe
the hardware better.
> +};
> +
> +&vp1 {
> + vp1_out_dp0: endpoint@a {
> + reg = <ROCKCHIP_VOP2_EP_DP0>;
> + remote-endpoint = <&dp0_in_vp1>;
> + };
> +};
> diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> index fd23ca2834b0..b58f57b69b22 100644
> --- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> +++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
> @@ -8,6 +8,7 @@
> */
> #include <linux/bitfield.h>
> #include <linux/clk.h>
> +#include <linux/gpio/consumer.h>
> #include <linux/iopoll.h>
> #include <linux/irq.h>
> #include <linux/media-bus-format.h>
> @@ -330,6 +331,8 @@ struct dw_dp {
> u8 pixel_mode;
>
> DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
> +
> + struct gpio_desc *hpd_gpiod;
> };
>
> enum {
> @@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
> {
> u32 value;
>
> + if (dp->hpd_gpiod)
> + return gpiod_get_value_cansleep(dp->hpd_gpiod);
> +
> regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
>
> return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
> @@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
> return ERR_CAST(dp->regmap);
> }
>
> + dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
Not tested, not needed, why bother?..
Best regards,
Alexey
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Krzysztof Kozlowski @ 2026-04-11 13:58 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Michael Riesch, Mykola Kvach,
Jimmy Hon, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <20260411024743.195385-4-dennis@ausil.us>
On Fri, Apr 10, 2026 at 09:47:43PM -0500, dennis@ausil.us wrote:
> From: Dennis Gilmore <dennis@ausil.us>
>
> Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
>
> - eMMC module, you can optionally solder a SPI NOR in place and turn
> off the eMMC
> - PCIe-attached NIC (pcie2x1l1)
> - PCIe NVMe slot (pcie2x1l2)
> - AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
> - BCM4345C5 Bluetooth
> - es8388 audio
> - USB 2.0 and USB 3.0
> - Two HDMI ports, the second is connected to the SoC's DP controller
> driven by a transparent LT8711UXD bridge that has firmware onboard and
> needs no node defined.
>
> Vendors description and links to schematics available:
> http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
> ---
> .../display/rockchip/rockchip,dw-dp.yaml | 7 +
Please run scripts/checkpatch.pl on the patches and fix reported
warnings. After that, run also 'scripts/checkpatch.pl --strict' on the
patches and (probably) fix more warnings. Some warnings can be ignored,
especially from --strict run, but the code here looks like it needs a
fix. Feel free to get in touch if the warning is not clear.
Didn't you already got this comment?
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v6 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: Jimmy Hon @ 2026-04-11 11:58 UTC (permalink / raw)
To: dennis
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Michael Riesch, Mykola Kvach,
devicetree, linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-3-dennis@ausil.us>
On Fri, Apr 10, 2026 at 9:47 PM <dennis@ausil.us> wrote:
>
> From: Dennis Gilmore <dennis@ausil.us>
>
> The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
> Orange Pi 5B but has had sound, USB, and leds wired up differently. The
> boards also use gmac for ethernet where the Pro has a PCIe attached NIC.
>
> I have not changed the definitions from what was in rk3588s-orangepi-5.dtsi
>
> Signed-off-by: Dennis Gilmore <dennis@ausil.us>
Still works on Orange Pi 5.
Having the 5 and 5B share a dtsi is similar to how the 5 Max and 5
Ultra share a dtsi while the 5 Plus has more differences.
Tested-By: Jimmy Hon <honyuenkwun@gmail.com>
Reviewed-By: Jimmy Hon <honyuenkwun@gmail.com>
> ---
> .../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 +++++++++++++++++
> .../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
> .../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +-----------------
> .../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
> 4 files changed, 209 insertions(+), 189 deletions(-)
> create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
>
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
> new file mode 100644
> index 000000000000..b04dd667605d
> --- /dev/null
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
> @@ -0,0 +1,192 @@
> +// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
> +/*
> + * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
> + * but not the Orange Pi 5 Pro.
> + */
> +
> +#include <dt-bindings/usb/pd.h>
> +#include "rk3588s-orangepi-5.dtsi"
> +
> +/ {
> + aliases {
> + ethernet0 = &gmac1;
> + };
> +
> + analog-sound {
> + compatible = "simple-audio-card";
> + pinctrl-names = "default";
> + pinctrl-0 = <&hp_detect>;
> + simple-audio-card,name = "rockchip,es8388";
> + simple-audio-card,bitclock-master = <&masterdai>;
> + simple-audio-card,format = "i2s";
> + simple-audio-card,frame-master = <&masterdai>;
> + simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> + simple-audio-card,mclk-fs = <256>;
> + simple-audio-card,routing =
> + "Headphones", "LOUT1",
> + "Headphones", "ROUT1",
> + "LINPUT1", "Microphone Jack",
> + "RINPUT1", "Microphone Jack",
> + "LINPUT2", "Onboard Microphone",
> + "RINPUT2", "Onboard Microphone";
> + simple-audio-card,widgets =
> + "Microphone", "Microphone Jack",
> + "Microphone", "Onboard Microphone",
> + "Headphone", "Headphones";
> +
> + simple-audio-card,cpu {
> + sound-dai = <&i2s1_8ch>;
> + };
> +
> + masterdai: simple-audio-card,codec {
> + sound-dai = <&es8388>;
> + system-clock-frequency = <12288000>;
> + };
> + };
> +
> + pwm-leds {
> + compatible = "pwm-leds";
> +
> + led {
> + color = <LED_COLOR_ID_GREEN>;
> + function = LED_FUNCTION_STATUS;
> + linux,default-trigger = "heartbeat";
> + max-brightness = <255>;
> + pwms = <&pwm0 0 25000 0>;
> + };
> + };
> +};
> +
> +&gmac1 {
> + clock_in_out = "output";
> + phy-handle = <&rgmii_phy1>;
> + phy-mode = "rgmii-rxid";
> + pinctrl-0 = <&gmac1_miim
> + &gmac1_tx_bus2
> + &gmac1_rx_bus2
> + &gmac1_rgmii_clk
> + &gmac1_rgmii_bus>;
> + pinctrl-names = "default";
> + tx_delay = <0x42>;
> + status = "okay";
> +};
> +
> +&i2c6 {
> + es8388: audio-codec@10 {
> + compatible = "everest,es8388", "everest,es8328";
> + reg = <0x10>;
> + clocks = <&cru I2S1_8CH_MCLKOUT>;
> + AVDD-supply = <&vcc_3v3_s0>;
> + DVDD-supply = <&vcc_1v8_s0>;
> + HPVDD-supply = <&vcc_3v3_s0>;
> + PVDD-supply = <&vcc_3v3_s0>;
> + assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
> + assigned-clock-rates = <12288000>;
> + #sound-dai-cells = <0>;
> + };
> +
> + usbc0: usb-typec@22 {
> + compatible = "fcs,fusb302";
> + reg = <0x22>;
> + interrupt-parent = <&gpio0>;
> + interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&usbc0_int>;
> + vbus-supply = <&vbus_typec>;
> + status = "okay";
> +
> + usb_con: connector {
> + compatible = "usb-c-connector";
> + label = "USB-C";
> + data-role = "dual";
> + op-sink-microwatt = <1000000>;
> + power-role = "dual";
> + sink-pdos =
> + <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
> + source-pdos =
> + <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> + try-power-role = "source";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + usbc0_hs: endpoint {
> + remote-endpoint = <&usb_host0_xhci_drd_sw>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + usbc0_ss: endpoint {
> + remote-endpoint = <&usbdp_phy0_typec_ss>;
> + };
> + };
> +
> + port@2 {
> + reg = <2>;
> + usbc0_sbu: endpoint {
> + remote-endpoint = <&usbdp_phy0_typec_sbu>;
> + };
> + };
> + };
> + };
> + };
> +};
> +
> +&i2s1_8ch {
> + rockchip,i2s-tx-route = <3 2 1 0>;
> + rockchip,i2s-rx-route = <1 3 2 0>;
> + pinctrl-names = "default";
> + pinctrl-0 = <&i2s1m0_sclk
> + &i2s1m0_mclk
> + &i2s1m0_lrck
> + &i2s1m0_sdi1
> + &i2s1m0_sdo3>;
> + status = "okay";
> +};
> +
> +&pwm0 {
> + pinctrl-0 = <&pwm0m2_pins>;
> + pinctrl-names = "default";
> + status = "okay";
> +};
> +
> +&usb_host0_xhci {
> + dr_mode = "otg";
> + usb-role-switch;
> +
> + port {
> + usb_host0_xhci_drd_sw: endpoint {
> + remote-endpoint = <&usbc0_hs>;
> + };
> + };
> +};
> +
> +&usb_host2_xhci {
> + status = "okay";
> +};
> +
> +&usbdp_phy0 {
> + mode-switch;
> + orientation-switch;
> + sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> + sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> +
> + port {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + usbdp_phy0_typec_ss: endpoint@0 {
> + reg = <0>;
> + remote-endpoint = <&usbc0_ss>;
> + };
> +
> + usbdp_phy0_typec_sbu: endpoint@1 {
> + reg = <1>;
> + remote-endpoint = <&usbc0_sbu>;
> + };
> + };
> +};
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> index 83b9b6645a1e..d76bdf1b5e90 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
> @@ -2,12 +2,16 @@
>
> /dts-v1/;
>
> -#include "rk3588s-orangepi-5.dtsi"
> +#include "rk3588s-orangepi-5-5b.dtsi"
>
> / {
> model = "Xunlong Orange Pi 5";
> compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
>
> + aliases {
> + mmc0 = &sdmmc;
> + };
> +
> vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
> compatible = "regulator-fixed";
> enable-active-high;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> index dafad29f9854..5c154cc6c62a 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
> @@ -3,19 +3,13 @@
> /dts-v1/;
>
> #include <dt-bindings/gpio/gpio.h>
> -#include <dt-bindings/leds/common.h>
> #include <dt-bindings/input/input.h>
> +#include <dt-bindings/leds/common.h>
> #include <dt-bindings/pinctrl/rockchip.h>
> #include <dt-bindings/soc/rockchip,vop2.h>
> -#include <dt-bindings/usb/pd.h>
> #include "rk3588s.dtsi"
>
> / {
> - aliases {
> - ethernet0 = &gmac1;
> - mmc0 = &sdmmc;
> - };
> -
> chosen {
> stdout-path = "serial2:1500000n8";
> };
> @@ -34,38 +28,6 @@ button-recovery {
> };
> };
>
> - analog-sound {
> - compatible = "simple-audio-card";
> - pinctrl-names = "default";
> - pinctrl-0 = <&hp_detect>;
> - simple-audio-card,name = "rockchip,es8388";
> - simple-audio-card,bitclock-master = <&masterdai>;
> - simple-audio-card,format = "i2s";
> - simple-audio-card,frame-master = <&masterdai>;
> - simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
> - simple-audio-card,mclk-fs = <256>;
> - simple-audio-card,routing =
> - "Headphones", "LOUT1",
> - "Headphones", "ROUT1",
> - "LINPUT1", "Microphone Jack",
> - "RINPUT1", "Microphone Jack",
> - "LINPUT2", "Onboard Microphone",
> - "RINPUT2", "Onboard Microphone";
> - simple-audio-card,widgets =
> - "Microphone", "Microphone Jack",
> - "Microphone", "Onboard Microphone",
> - "Headphone", "Headphones";
> -
> - simple-audio-card,cpu {
> - sound-dai = <&i2s1_8ch>;
> - };
> -
> - masterdai: simple-audio-card,codec {
> - sound-dai = <&es8388>;
> - system-clock-frequency = <12288000>;
> - };
> - };
> -
> hdmi0-con {
> compatible = "hdmi-connector";
> type = "a";
> @@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
> };
> };
>
> - pwm-leds {
> - compatible = "pwm-leds";
> -
> - led {
> - color = <LED_COLOR_ID_GREEN>;
> - function = LED_FUNCTION_STATUS;
> - linux,default-trigger = "heartbeat";
> - max-brightness = <255>;
> - pwms = <&pwm0 0 25000 0>;
> - };
> - };
> -
> vbus_typec: regulator-vbus-typec {
> compatible = "regulator-fixed";
> enable-active-high;
> @@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
> vin-supply = <&vcc5v0_sys>;
> };
>
> - vcc5v0_sys: regulator-vcc5v0-sys {
> - compatible = "regulator-fixed";
> - regulator-name = "vcc5v0_sys";
> - regulator-always-on;
> - regulator-boot-on;
> - regulator-min-microvolt = <5000000>;
> - regulator-max-microvolt = <5000000>;
> - };
> -
> vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
> compatible = "regulator-fixed";
> gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
> @@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
> regulator-max-microvolt = <3300000>;
> vin-supply = <&vcc_3v3_s3>;
> };
> +
> + vcc5v0_sys: regulator-vcc5v0-sys {
> + compatible = "regulator-fixed";
> + regulator-name = "vcc5v0_sys";
> + regulator-always-on;
> + regulator-boot-on;
> + regulator-min-microvolt = <5000000>;
> + regulator-max-microvolt = <5000000>;
> + };
> };
>
> &combphy0_ps {
> @@ -161,20 +111,6 @@ &cpu_l3 {
> cpu-supply = <&vdd_cpu_lit_s0>;
> };
>
> -&gmac1 {
> - clock_in_out = "output";
> - phy-handle = <&rgmii_phy1>;
> - phy-mode = "rgmii-rxid";
> - pinctrl-0 = <&gmac1_miim
> - &gmac1_tx_bus2
> - &gmac1_rx_bus2
> - &gmac1_rgmii_clk
> - &gmac1_rgmii_bus>;
> - pinctrl-names = "default";
> - tx_delay = <0x42>;
> - status = "okay";
> -};
> -
> &gpu {
> mali-supply = <&vdd_gpu_s0>;
> status = "okay";
> @@ -270,69 +206,6 @@ &i2c6 {
> pinctrl-0 = <&i2c6m3_xfer>;
> status = "okay";
>
> - es8388: audio-codec@10 {
> - compatible = "everest,es8388", "everest,es8328";
> - reg = <0x10>;
> - clocks = <&cru I2S1_8CH_MCLKOUT>;
> - AVDD-supply = <&vcc_3v3_s0>;
> - DVDD-supply = <&vcc_1v8_s0>;
> - HPVDD-supply = <&vcc_3v3_s0>;
> - PVDD-supply = <&vcc_3v3_s0>;
> - assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
> - assigned-clock-rates = <12288000>;
> - #sound-dai-cells = <0>;
> - };
> -
> - usbc0: usb-typec@22 {
> - compatible = "fcs,fusb302";
> - reg = <0x22>;
> - interrupt-parent = <&gpio0>;
> - interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&usbc0_int>;
> - vbus-supply = <&vbus_typec>;
> - status = "okay";
> -
> - usb_con: connector {
> - compatible = "usb-c-connector";
> - label = "USB-C";
> - data-role = "dual";
> - op-sink-microwatt = <1000000>;
> - power-role = "dual";
> - sink-pdos =
> - <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
> - source-pdos =
> - <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
> - try-power-role = "source";
> -
> - ports {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - port@0 {
> - reg = <0>;
> - usbc0_hs: endpoint {
> - remote-endpoint = <&usb_host0_xhci_drd_sw>;
> - };
> - };
> -
> - port@1 {
> - reg = <1>;
> - usbc0_ss: endpoint {
> - remote-endpoint = <&usbdp_phy0_typec_ss>;
> - };
> - };
> -
> - port@2 {
> - reg = <2>;
> - usbc0_sbu: endpoint {
> - remote-endpoint = <&usbdp_phy0_typec_sbu>;
> - };
> - };
> - };
> - };
> - };
> -
> hym8563: rtc@51 {
> compatible = "haoyu,hym8563";
> reg = <0x51>;
> @@ -346,18 +219,6 @@ hym8563: rtc@51 {
> };
> };
>
> -&i2s1_8ch {
> - rockchip,i2s-tx-route = <3 2 1 0>;
> - rockchip,i2s-rx-route = <1 3 2 0>;
> - pinctrl-names = "default";
> - pinctrl-0 = <&i2s1m0_sclk
> - &i2s1m0_mclk
> - &i2s1m0_lrck
> - &i2s1m0_sdi1
> - &i2s1m0_sdo3>;
> - status = "okay";
> -};
> -
> &i2s5_8ch {
> status = "okay";
> };
> @@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
> };
> };
>
> -&pwm0 {
> - pinctrl-0 = <&pwm0m2_pins>;
> - pinctrl-names = "default";
> - status = "okay";
> -};
> -
> &rknn_core_0 {
> npu-supply = <&vdd_npu_s0>;
> sram-supply = <&vdd_npu_s0>;
> @@ -841,26 +696,7 @@ &uart2 {
> };
>
> &usbdp_phy0 {
> - mode-switch;
> - orientation-switch;
> - sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
> - sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
> status = "okay";
> -
> - port {
> - #address-cells = <1>;
> - #size-cells = <0>;
> -
> - usbdp_phy0_typec_ss: endpoint@0 {
> - reg = <0>;
> - remote-endpoint = <&usbc0_ss>;
> - };
> -
> - usbdp_phy0_typec_sbu: endpoint@1 {
> - reg = <1>;
> - remote-endpoint = <&usbc0_sbu>;
> - };
> - };
> };
>
> &usb_host0_ehci {
> @@ -872,15 +708,7 @@ &usb_host0_ohci {
> };
>
> &usb_host0_xhci {
> - dr_mode = "otg";
> - usb-role-switch;
> status = "okay";
> -
> - port {
> - usb_host0_xhci_drd_sw: endpoint {
> - remote-endpoint = <&usbc0_hs>;
> - };
> - };
> };
>
> &usb_host1_ehci {
> @@ -891,7 +719,7 @@ &usb_host1_ohci {
> status = "okay";
> };
>
> -&usb_host2_xhci {
> +&vop {
> status = "okay";
> };
>
> @@ -899,10 +727,6 @@ &vop_mmu {
> status = "okay";
> };
>
> -&vop {
> - status = "okay";
> -};
> -
> &vp0 {
> vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
> reg = <ROCKCHIP_VOP2_EP_HDMI0>;
> diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> index d21ec320d295..8af174777809 100644
> --- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> +++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
> @@ -2,7 +2,7 @@
>
> /dts-v1/;
>
> -#include "rk3588s-orangepi-5.dtsi"
> +#include "rk3588s-orangepi-5-5b.dtsi"
>
> / {
> model = "Xunlong Orange Pi 5B";
> --
> 2.53.0
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [GIT PULL] Rockchip dts32 changes for 7.1 #2
From: Krzysztof Kozlowski @ 2026-04-11 8:10 UTC (permalink / raw)
To: Heiko Stuebner
Cc: arm, soc, linux-rockchip, linux-arm-kernel, Stephen Boyd,
mturquette
In-Reply-To: <13980380.dW097sEU6C@phil>
On Fri, Apr 03, 2026 at 03:39:31PM +0200, Heiko Stuebner wrote:
> Hi soc maintainers,
>
> please find below a new ARM32 Rockchip SoC for 7.1 . This goes on top
> of the generic arm32 changes I just sent.
>
>
> I've split this off from the other ARM32 changes, because this contains
> a shared clock header, shared between the devicetree side and the clock-
> driver side.
>
> The clock pull-request is sent [0], but not merged yet - probably after
> easter I guess.
>
> And while in the past this has always come together in time for the
> merge-window, I wasn't sure if in the soc multi-maintainer context the
> handling changes. So depending on your preference this could also wait
> until after the clock-subsystem-side got merged.
>
>
> Please pull.
> Thanks
> Heiko
>
>
> [0] https://lore.kernel.org/all/3746710.R56niFO833@phil/
>
>
> The following changes since commit 94c8dc1fa8e1ad4037084204152bca1e799d7d1c:
>
> ARM: dts: rockchip: Pass linux,code to the power key on rk3288-veyron-pinky (2026-03-24 17:06:35 +0100)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.1-rockchip-dts32-2
>
> for you to fetch changes up to 683192d7d5b47e89d920867f7c6997d2c0d1a0ad:
>
> ARM: dts: rockchip: Add Onion Omega4 Evaluation Board (2026-03-24 17:40:11 +0100)
>
> ----------------------------------------------------------------
> Support for the RV1103B SoC and the Onion Omega4 board using it.
> While the RV1103B only got a B-extension to its name, the SoC internals
> were reworked heavily. So likely it's mainly pin compatible to the
> non-B variant.
>
> The dt-binding for the RV1103B clock driver is shared with the clock-
> driver branch going into the clock-tree.
Thanks, applied
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [GIT PULL] Rockchip dts32 changes for 7.1 #1
From: Krzysztof Kozlowski @ 2026-04-11 8:06 UTC (permalink / raw)
To: Heiko Stuebner; +Cc: arm, soc, linux-rockchip, linux-arm-kernel
In-Reply-To: <2771700.BddDVKsqQX@phil>
On Fri, Apr 03, 2026 at 03:25:36PM +0200, Heiko Stuebner wrote:
> Hi soc maintainers,
>
> please find below Rockchip ARM32 DT changes for the merge-window for 7.1 .
>
>
> Please pull.
> Thanks
> Heiko
>
>
> The following changes since commit 6de23f81a5e08be8fbf5e8d7e9febc72a5b5f27f:
>
> Linux 7.0-rc1 (2026-02-22 13:18:59 -0800)
>
> are available in the Git repository at:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/mmind/linux-rockchip.git tags/v7.1-rockchip-dts32-1
>
> for you to fetch changes up to 94c8dc1fa8e1ad4037084204152bca1e799d7d1c:
>
> ARM: dts: rockchip: Pass linux,code to the power key on rk3288-veyron-pinky (2026-03-24 17:06:35 +0100)
>
> ----------------------------------------------------------------
> A number of dt-schema cleanups that are log standing, so not suitable
> as fix for the current release.
>
Thanks, applied
Best regards,
Krzysztof
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* [PATCH v6 2/3] arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
The Orange Pi 5 Pro uses the same SoC and base as the Orange Pi 5 and
Orange Pi 5B but has had sound, USB, and leds wired up differently. The
boards also use gmac for ethernet where the Pro has a PCIe attached NIC.
I have not changed the definitions from what was in rk3588s-orangepi-5.dtsi
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 +++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +-----------------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
4 files changed, 209 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
new file mode 100644
index 000000000000..b04dd667605d
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
@@ -0,0 +1,192 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+/*
+ * Device tree definitions shared by the Orange Pi 5 and Orange Pi 5B
+ * but not the Orange Pi 5 Pro.
+ */
+
+#include <dt-bindings/usb/pd.h>
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ aliases {
+ ethernet0 = &gmac1;
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s1_8ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm0 0 25000 0>;
+ };
+ };
+};
+
+&gmac1 {
+ clock_in_out = "output";
+ phy-handle = <&rgmii_phy1>;
+ phy-mode = "rgmii-rxid";
+ pinctrl-0 = <&gmac1_miim
+ &gmac1_tx_bus2
+ &gmac1_rx_bus2
+ &gmac1_rgmii_clk
+ &gmac1_rgmii_bus>;
+ pinctrl-names = "default";
+ tx_delay = <0x42>;
+ status = "okay";
+};
+
+&i2c6 {
+ es8388: audio-codec@10 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x10>;
+ clocks = <&cru I2S1_8CH_MCLKOUT>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
+ assigned-clock-rates = <12288000>;
+ #sound-dai-cells = <0>;
+ };
+
+ usbc0: usb-typec@22 {
+ compatible = "fcs,fusb302";
+ reg = <0x22>;
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&usbc0_int>;
+ vbus-supply = <&vbus_typec>;
+ status = "okay";
+
+ usb_con: connector {
+ compatible = "usb-c-connector";
+ label = "USB-C";
+ data-role = "dual";
+ op-sink-microwatt = <1000000>;
+ power-role = "dual";
+ sink-pdos =
+ <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
+ source-pdos =
+ <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
+ try-power-role = "source";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+ usbc0_hs: endpoint {
+ remote-endpoint = <&usb_host0_xhci_drd_sw>;
+ };
+ };
+
+ port@1 {
+ reg = <1>;
+ usbc0_ss: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_ss>;
+ };
+ };
+
+ port@2 {
+ reg = <2>;
+ usbc0_sbu: endpoint {
+ remote-endpoint = <&usbdp_phy0_typec_sbu>;
+ };
+ };
+ };
+ };
+ };
+};
+
+&i2s1_8ch {
+ rockchip,i2s-tx-route = <3 2 1 0>;
+ rockchip,i2s-rx-route = <1 3 2 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s1m0_sclk
+ &i2s1m0_mclk
+ &i2s1m0_lrck
+ &i2s1m0_sdi1
+ &i2s1m0_sdo3>;
+ status = "okay";
+};
+
+&pwm0 {
+ pinctrl-0 = <&pwm0m2_pins>;
+ pinctrl-names = "default";
+ status = "okay";
+};
+
+&usb_host0_xhci {
+ dr_mode = "otg";
+ usb-role-switch;
+
+ port {
+ usb_host0_xhci_drd_sw: endpoint {
+ remote-endpoint = <&usbc0_hs>;
+ };
+ };
+};
+
+&usb_host2_xhci {
+ status = "okay";
+};
+
+&usbdp_phy0 {
+ mode-switch;
+ orientation-switch;
+ sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
+ sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
+
+ port {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ usbdp_phy0_typec_ss: endpoint@0 {
+ reg = <0>;
+ remote-endpoint = <&usbc0_ss>;
+ };
+
+ usbdp_phy0_typec_sbu: endpoint@1 {
+ reg = <1>;
+ remote-endpoint = <&usbc0_sbu>;
+ };
+ };
+};
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
index 83b9b6645a1e..d76bdf1b5e90 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dts
@@ -2,12 +2,16 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5";
compatible = "xunlong,orangepi-5", "rockchip,rk3588s";
+ aliases {
+ mmc0 = &sdmmc;
+ };
+
vcc3v3_pcie20: regulator-vcc3v3-pcie20 {
compatible = "regulator-fixed";
enable-active-high;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
index dafad29f9854..5c154cc6c62a 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5.dtsi
@@ -3,19 +3,13 @@
/dts-v1/;
#include <dt-bindings/gpio/gpio.h>
-#include <dt-bindings/leds/common.h>
#include <dt-bindings/input/input.h>
+#include <dt-bindings/leds/common.h>
#include <dt-bindings/pinctrl/rockchip.h>
#include <dt-bindings/soc/rockchip,vop2.h>
-#include <dt-bindings/usb/pd.h>
#include "rk3588s.dtsi"
/ {
- aliases {
- ethernet0 = &gmac1;
- mmc0 = &sdmmc;
- };
-
chosen {
stdout-path = "serial2:1500000n8";
};
@@ -34,38 +28,6 @@ button-recovery {
};
};
- analog-sound {
- compatible = "simple-audio-card";
- pinctrl-names = "default";
- pinctrl-0 = <&hp_detect>;
- simple-audio-card,name = "rockchip,es8388";
- simple-audio-card,bitclock-master = <&masterdai>;
- simple-audio-card,format = "i2s";
- simple-audio-card,frame-master = <&masterdai>;
- simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
- simple-audio-card,mclk-fs = <256>;
- simple-audio-card,routing =
- "Headphones", "LOUT1",
- "Headphones", "ROUT1",
- "LINPUT1", "Microphone Jack",
- "RINPUT1", "Microphone Jack",
- "LINPUT2", "Onboard Microphone",
- "RINPUT2", "Onboard Microphone";
- simple-audio-card,widgets =
- "Microphone", "Microphone Jack",
- "Microphone", "Onboard Microphone",
- "Headphone", "Headphones";
-
- simple-audio-card,cpu {
- sound-dai = <&i2s1_8ch>;
- };
-
- masterdai: simple-audio-card,codec {
- sound-dai = <&es8388>;
- system-clock-frequency = <12288000>;
- };
- };
-
hdmi0-con {
compatible = "hdmi-connector";
type = "a";
@@ -77,18 +39,6 @@ hdmi0_con_in: endpoint {
};
};
- pwm-leds {
- compatible = "pwm-leds";
-
- led {
- color = <LED_COLOR_ID_GREEN>;
- function = LED_FUNCTION_STATUS;
- linux,default-trigger = "heartbeat";
- max-brightness = <255>;
- pwms = <&pwm0 0 25000 0>;
- };
- };
-
vbus_typec: regulator-vbus-typec {
compatible = "regulator-fixed";
enable-active-high;
@@ -101,15 +51,6 @@ vbus_typec: regulator-vbus-typec {
vin-supply = <&vcc5v0_sys>;
};
- vcc5v0_sys: regulator-vcc5v0-sys {
- compatible = "regulator-fixed";
- regulator-name = "vcc5v0_sys";
- regulator-always-on;
- regulator-boot-on;
- regulator-min-microvolt = <5000000>;
- regulator-max-microvolt = <5000000>;
- };
-
vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
compatible = "regulator-fixed";
gpios = <&gpio4 RK_PB5 GPIO_ACTIVE_LOW>;
@@ -119,6 +60,15 @@ vcc_3v3_sd_s0: regulator-vcc-3v3-sd-s0 {
regulator-max-microvolt = <3300000>;
vin-supply = <&vcc_3v3_s3>;
};
+
+ vcc5v0_sys: regulator-vcc5v0-sys {
+ compatible = "regulator-fixed";
+ regulator-name = "vcc5v0_sys";
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-min-microvolt = <5000000>;
+ regulator-max-microvolt = <5000000>;
+ };
};
&combphy0_ps {
@@ -161,20 +111,6 @@ &cpu_l3 {
cpu-supply = <&vdd_cpu_lit_s0>;
};
-&gmac1 {
- clock_in_out = "output";
- phy-handle = <&rgmii_phy1>;
- phy-mode = "rgmii-rxid";
- pinctrl-0 = <&gmac1_miim
- &gmac1_tx_bus2
- &gmac1_rx_bus2
- &gmac1_rgmii_clk
- &gmac1_rgmii_bus>;
- pinctrl-names = "default";
- tx_delay = <0x42>;
- status = "okay";
-};
-
&gpu {
mali-supply = <&vdd_gpu_s0>;
status = "okay";
@@ -270,69 +206,6 @@ &i2c6 {
pinctrl-0 = <&i2c6m3_xfer>;
status = "okay";
- es8388: audio-codec@10 {
- compatible = "everest,es8388", "everest,es8328";
- reg = <0x10>;
- clocks = <&cru I2S1_8CH_MCLKOUT>;
- AVDD-supply = <&vcc_3v3_s0>;
- DVDD-supply = <&vcc_1v8_s0>;
- HPVDD-supply = <&vcc_3v3_s0>;
- PVDD-supply = <&vcc_3v3_s0>;
- assigned-clocks = <&cru I2S1_8CH_MCLKOUT>;
- assigned-clock-rates = <12288000>;
- #sound-dai-cells = <0>;
- };
-
- usbc0: usb-typec@22 {
- compatible = "fcs,fusb302";
- reg = <0x22>;
- interrupt-parent = <&gpio0>;
- interrupts = <RK_PD3 IRQ_TYPE_LEVEL_LOW>;
- pinctrl-names = "default";
- pinctrl-0 = <&usbc0_int>;
- vbus-supply = <&vbus_typec>;
- status = "okay";
-
- usb_con: connector {
- compatible = "usb-c-connector";
- label = "USB-C";
- data-role = "dual";
- op-sink-microwatt = <1000000>;
- power-role = "dual";
- sink-pdos =
- <PDO_FIXED(5000, 1000, PDO_FIXED_USB_COMM)>;
- source-pdos =
- <PDO_FIXED(5000, 3000, PDO_FIXED_USB_COMM)>;
- try-power-role = "source";
-
- ports {
- #address-cells = <1>;
- #size-cells = <0>;
-
- port@0 {
- reg = <0>;
- usbc0_hs: endpoint {
- remote-endpoint = <&usb_host0_xhci_drd_sw>;
- };
- };
-
- port@1 {
- reg = <1>;
- usbc0_ss: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_ss>;
- };
- };
-
- port@2 {
- reg = <2>;
- usbc0_sbu: endpoint {
- remote-endpoint = <&usbdp_phy0_typec_sbu>;
- };
- };
- };
- };
- };
-
hym8563: rtc@51 {
compatible = "haoyu,hym8563";
reg = <0x51>;
@@ -346,18 +219,6 @@ hym8563: rtc@51 {
};
};
-&i2s1_8ch {
- rockchip,i2s-tx-route = <3 2 1 0>;
- rockchip,i2s-rx-route = <1 3 2 0>;
- pinctrl-names = "default";
- pinctrl-0 = <&i2s1m0_sclk
- &i2s1m0_mclk
- &i2s1m0_lrck
- &i2s1m0_sdi1
- &i2s1m0_sdo3>;
- status = "okay";
-};
-
&i2s5_8ch {
status = "okay";
};
@@ -404,12 +265,6 @@ typec5v_pwren: typec5v-pwren {
};
};
-&pwm0 {
- pinctrl-0 = <&pwm0m2_pins>;
- pinctrl-names = "default";
- status = "okay";
-};
-
&rknn_core_0 {
npu-supply = <&vdd_npu_s0>;
sram-supply = <&vdd_npu_s0>;
@@ -841,26 +696,7 @@ &uart2 {
};
&usbdp_phy0 {
- mode-switch;
- orientation-switch;
- sbu1-dc-gpios = <&gpio4 RK_PA5 GPIO_ACTIVE_HIGH>;
- sbu2-dc-gpios = <&gpio4 RK_PA7 GPIO_ACTIVE_HIGH>;
status = "okay";
-
- port {
- #address-cells = <1>;
- #size-cells = <0>;
-
- usbdp_phy0_typec_ss: endpoint@0 {
- reg = <0>;
- remote-endpoint = <&usbc0_ss>;
- };
-
- usbdp_phy0_typec_sbu: endpoint@1 {
- reg = <1>;
- remote-endpoint = <&usbc0_sbu>;
- };
- };
};
&usb_host0_ehci {
@@ -872,15 +708,7 @@ &usb_host0_ohci {
};
&usb_host0_xhci {
- dr_mode = "otg";
- usb-role-switch;
status = "okay";
-
- port {
- usb_host0_xhci_drd_sw: endpoint {
- remote-endpoint = <&usbc0_hs>;
- };
- };
};
&usb_host1_ehci {
@@ -891,7 +719,7 @@ &usb_host1_ohci {
status = "okay";
};
-&usb_host2_xhci {
+&vop {
status = "okay";
};
@@ -899,10 +727,6 @@ &vop_mmu {
status = "okay";
};
-&vop {
- status = "okay";
-};
-
&vp0 {
vp0_out_hdmi0: endpoint@ROCKCHIP_VOP2_EP_HDMI0 {
reg = <ROCKCHIP_VOP2_EP_HDMI0>;
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
index d21ec320d295..8af174777809 100644
--- a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5b.dts
@@ -2,7 +2,7 @@
/dts-v1/;
-#include "rk3588s-orangepi-5.dtsi"
+#include "rk3588s-orangepi-5-5b.dtsi"
/ {
model = "Xunlong Orange Pi 5B";
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v6 1/3] dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel, Krzysztof Kozlowski
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add compatible string for the Orange Pi 5 Pro.
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
Documentation/devicetree/bindings/arm/rockchip.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/arm/rockchip.yaml b/Documentation/devicetree/bindings/arm/rockchip.yaml
index ae77ded9fe47..3c6b83a84463 100644
--- a/Documentation/devicetree/bindings/arm/rockchip.yaml
+++ b/Documentation/devicetree/bindings/arm/rockchip.yaml
@@ -1320,6 +1320,7 @@ properties:
items:
- enum:
- xunlong,orangepi-5
+ - xunlong,orangepi-5-pro
- xunlong,orangepi-5b
- const: rockchip,rk3588s
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v6 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
In-Reply-To: <20260411024743.195385-1-dennis@ausil.us>
From: Dennis Gilmore <dennis@ausil.us>
Add device tree for the Xunlong Orange Pi 5 Pro (RK3588S).
- eMMC module, you can optionally solder a SPI NOR in place and turn
off the eMMC
- PCIe-attached NIC (pcie2x1l1)
- PCIe NVMe slot (pcie2x1l2)
- AP6256 WiFi (BCM43456) via SDIO with mmc-pwrseq
- BCM4345C5 Bluetooth
- es8388 audio
- USB 2.0 and USB 3.0
- Two HDMI ports, the second is connected to the SoC's DP controller
driven by a transparent LT8711UXD bridge that has firmware onboard and
needs no node defined.
Vendors description and links to schematics available:
http://www.orangepi.org/html/hardWare/computerAndMicrocontrollers/details/Orange-Pi-5-Pro.html
Signed-off-by: Dennis Gilmore <dennis@ausil.us>
---
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
4 files changed, 372 insertions(+)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
diff --git a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
index 6345f0132d43..079a912d97f1 100644
--- a/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
+++ b/Documentation/devicetree/bindings/display/rockchip/rockchip,dw-dp.yaml
@@ -57,6 +57,13 @@ properties:
- const: i2s
- const: spdif
+ hpd-gpios:
+ maxItems: 1
+ description:
+ GPIO used for hot plug detection when the controller's native HPD
+ input is not connected. If not specified, the controller uses its
+ internal HPD detection mechanism.
+
phys:
maxItems: 1
diff --git a/arch/arm64/boot/dts/rockchip/Makefile b/arch/arm64/boot/dts/rockchip/Makefile
index 4d384f153c13..c99dca2ae9e7 100644
--- a/arch/arm64/boot/dts/rockchip/Makefile
+++ b/arch/arm64/boot/dts/rockchip/Makefile
@@ -214,6 +214,7 @@ dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-nanopi-r6c.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-odroid-m2.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5b.dtb
+dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-5-pro.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-orangepi-cm5-base.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-radxa-cm5-io.dtb
dtb-$(CONFIG_ARCH_ROCKCHIP) += rk3588s-roc-pc.dtb
diff --git a/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
new file mode 100644
index 000000000000..84c83aa69f63
--- /dev/null
+++ b/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
@@ -0,0 +1,352 @@
+// SPDX-License-Identifier: (GPL-2.0+ OR MIT)
+
+/dts-v1/;
+
+#include "rk3588s-orangepi-5.dtsi"
+
+/ {
+ model = "Xunlong Orange Pi 5 Pro";
+ compatible = "xunlong,orangepi-5-pro", "rockchip,rk3588s";
+
+ aliases {
+ mmc0 = &sdhci;
+ mmc1 = &sdmmc;
+ mmc2 = &sdio;
+ };
+
+ dp-con {
+ compatible = "dp-connector";
+
+ port {
+ dp_con_in: endpoint {
+ remote-endpoint = <&dp0_out_con>;
+ };
+ };
+ };
+
+ analog-sound {
+ compatible = "simple-audio-card";
+ pinctrl-names = "default";
+ pinctrl-0 = <&hp_detect>;
+ simple-audio-card,bitclock-master = <&masterdai>;
+ simple-audio-card,format = "i2s";
+ simple-audio-card,frame-master = <&masterdai>;
+ simple-audio-card,hp-det-gpios = <&gpio1 RK_PD5 GPIO_ACTIVE_HIGH>;
+ simple-audio-card,mclk-fs = <256>;
+ simple-audio-card,name = "rockchip,es8388";
+ simple-audio-card,routing =
+ "Headphones", "LOUT1",
+ "Headphones", "ROUT1",
+ "LINPUT1", "Microphone Jack",
+ "RINPUT1", "Microphone Jack",
+ "LINPUT2", "Onboard Microphone",
+ "RINPUT2", "Onboard Microphone";
+ simple-audio-card,widgets =
+ "Microphone", "Microphone Jack",
+ "Microphone", "Onboard Microphone",
+ "Headphone", "Headphones";
+
+ simple-audio-card,cpu {
+ sound-dai = <&i2s2_2ch>;
+ };
+
+ masterdai: simple-audio-card,codec {
+ sound-dai = <&es8388>;
+ system-clock-frequency = <12288000>;
+ };
+ };
+
+ pwm-leds {
+ compatible = "pwm-leds";
+
+ led-0 {
+ color = <LED_COLOR_ID_BLUE>;
+ function = LED_FUNCTION_STATUS;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm15 0 1000000 0>;
+ };
+
+ led-1 {
+ color = <LED_COLOR_ID_GREEN>;
+ function = LED_FUNCTION_ACTIVITY;
+ linux,default-trigger = "heartbeat";
+ max-brightness = <255>;
+ pwms = <&pwm3 0 1000000 0>;
+ };
+ };
+
+ fan: pwm-fan {
+ compatible = "pwm-fan";
+ #cooling-cells = <2>;
+ cooling-levels = <0 50 100 150 200 255>;
+ fan-supply = <&vcc5v0_sys>;
+ pwms = <&pwm2 0 20000000 0>;
+ };
+
+ vcc3v3_dp: regulator-vcc3v3-dp {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PC2 GPIO_ACTIVE_HIGH>;
+ regulator-always-on;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_dp";
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc3v3_phy1: regulator-vcc3v3-phy1 {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio3 RK_PB7 GPIO_ACTIVE_HIGH>;
+ regulator-boot-on;
+ regulator-max-microvolt = <3300000>;
+ regulator-min-microvolt = <3300000>;
+ regulator-name = "vcc3v3_phy1";
+ startup-delay-us = <50000>;
+ vin-supply = <&vcc_3v3_s3>;
+ };
+
+ vcc5v0_otg: regulator-vcc5v0-otg {
+ compatible = "regulator-fixed";
+ enable-active-high;
+ gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&vcc5v0_otg_en>;
+ regulator-max-microvolt = <5000000>;
+ regulator-min-microvolt = <5000000>;
+ regulator-name = "vcc5v0_otg";
+ vin-supply = <&vcc5v0_sys>;
+ };
+
+ sdio_pwrseq: sdio-pwrseq {
+ compatible = "mmc-pwrseq-simple";
+ clocks = <&hym8563>;
+ clock-names = "ext_clock";
+ post-power-on-delay-ms = <200>;
+ reset-gpios = <&gpio0 RK_PD0 GPIO_ACTIVE_LOW>;
+ };
+
+ typea_con: usb-a-connector {
+ compatible = "usb-a-connector";
+ data-role = "host";
+ label = "USB3 Type-A";
+ power-role = "source";
+ vbus-supply = <&vcc5v0_otg>;
+ };
+};
+
+&dp0 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&dp0m0_pins>;
+ status = "okay";
+};
+
+&dp0_in {
+ dp0_in_vp1: endpoint {
+ remote-endpoint = <&vp1_out_dp0>;
+ };
+};
+
+&dp0_out {
+ dp0_out_con: endpoint {
+ remote-endpoint = <&dp_con_in>;
+ };
+};
+
+&i2c1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c1m4_xfer>;
+ status = "okay";
+};
+
+&i2c3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c3m0_xfer>;
+ status = "okay";
+
+ es8388: audio-codec@11 {
+ compatible = "everest,es8388", "everest,es8328";
+ reg = <0x11>;
+ #sound-dai-cells = <0>;
+ AVDD-supply = <&vcc_3v3_s0>;
+ DVDD-supply = <&vcc_1v8_s0>;
+ HPVDD-supply = <&vcc_3v3_s0>;
+ PVDD-supply = <&vcc_3v3_s0>;
+ assigned-clock-rates = <12288000>;
+ assigned-clocks = <&cru I2S2_2CH_MCLKOUT>;
+ clocks = <&cru I2S2_2CH_MCLKOUT>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2s2m1_mclk>;
+ };
+};
+
+&i2c4 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&i2c4m3_xfer>;
+ status = "okay";
+};
+
+&i2s2_2ch {
+ pinctrl-0 = <&i2s2m1_lrck &i2s2m1_sclk
+ &i2s2m1_sdi &i2s2m1_sdo>;
+ status = "okay";
+};
+
+&package_thermal {
+ polling-delay = <1000>;
+
+ cooling-maps {
+ map0 {
+ trip = <&package_fan0>;
+ cooling-device = <&fan THERMAL_NO_LIMIT 1>;
+ };
+
+ map1 {
+ trip = <&package_fan1>;
+ cooling-device = <&fan 2 THERMAL_NO_LIMIT>;
+ };
+ };
+
+ trips {
+ package_fan0: package-fan0 {
+ hysteresis = <2000>;
+ temperature = <55000>;
+ type = "active";
+ };
+
+ package_fan1: package-fan1 {
+ hysteresis = <2000>;
+ temperature = <65000>;
+ type = "active";
+ };
+ };
+};
+
+/* NVMe */
+&pcie2x1l1 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pcie30x1m1_1_clkreqn &pcie30x1m1_1_waken>;
+ reset-gpios = <&gpio4 RK_PA2 GPIO_ACTIVE_HIGH>;
+ supports-clkreq;
+ vpcie3v3-supply = <&vcc_3v3_s3>;
+ status = "okay";
+};
+
+/* NIC */
+&pcie2x1l2 {
+ reset-gpios = <&gpio3 RK_PD1 GPIO_ACTIVE_HIGH>;
+ vpcie3v3-supply = <&vcc3v3_phy1>;
+ status = "okay";
+};
+
+&pinctrl {
+ bluetooth {
+ bt_wake_gpio: bt-wake-pin {
+ rockchip,pins = <0 RK_PC6 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+
+ bt_wake_host_irq: bt-wake-host-irq {
+ rockchip,pins = <0 RK_PC5 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+
+ usb {
+ vcc5v0_otg_en: vcc5v0-otg-en {
+ rockchip,pins = <0 RK_PC4 RK_FUNC_GPIO &pcfg_pull_none>;
+ };
+ };
+
+ wlan {
+ wifi_host_wake_irq: wifi-host-wake-irq {
+ rockchip,pins = <0 RK_PA0 RK_FUNC_GPIO &pcfg_pull_down>;
+ };
+ };
+};
+
+&pwm15 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm15m2_pins>;
+ status = "okay";
+};
+
+&pwm2 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm2m1_pins>;
+ status = "okay";
+};
+
+&pwm3 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&pwm3m2_pins>;
+ status = "okay";
+};
+
+&sdhci {
+ status = "okay";
+};
+
+&sdio {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ bus-width = <4>;
+ cap-sd-highspeed;
+ cap-sdio-irq;
+ keep-power-in-suspend;
+ max-frequency = <150000000>;
+ mmc-pwrseq = <&sdio_pwrseq>;
+ no-mmc;
+ no-sd;
+ non-removable;
+ sd-uhs-sdr104;
+ status = "okay";
+
+ ap6256: wifi@1 {
+ compatible = "brcm,bcm43456-fmac", "brcm,bcm4329-fmac";
+ reg = <1>;
+ interrupt-names = "host-wake";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PA0 IRQ_TYPE_LEVEL_HIGH>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&wifi_host_wake_irq>;
+ };
+};
+
+&uart9 {
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart9m2_xfer &uart9m2_ctsn &uart9m2_rtsn>;
+ uart-has-rtscts;
+ status = "okay";
+
+ bluetooth {
+ compatible = "brcm,bcm4345c5";
+ clocks = <&hym8563>;
+ clock-names = "lpo";
+ device-wakeup-gpios = <&gpio0 RK_PC6 GPIO_ACTIVE_HIGH>;
+ interrupt-names = "host-wakeup";
+ interrupt-parent = <&gpio0>;
+ interrupts = <RK_PC5 IRQ_TYPE_LEVEL_HIGH>;
+ max-speed = <1500000>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&bt_wake_host_irq &bt_wake_gpio>;
+ shutdown-gpios = <&gpio0 RK_PD5 GPIO_ACTIVE_HIGH>;
+ vbat-supply = <&vcc_3v3_s3>;
+ vddio-supply = <&vcc_1v8_s3>;
+ };
+};
+
+&usb_host0_xhci {
+ dr_mode = "host";
+};
+
+&usbdp_phy0 {
+ rockchip,dp-lane-mux = <0 1>;
+};
+
+&vp1 {
+ vp1_out_dp0: endpoint@a {
+ reg = <ROCKCHIP_VOP2_EP_DP0>;
+ remote-endpoint = <&dp0_in_vp1>;
+ };
+};
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-dp.c b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
index fd23ca2834b0..b58f57b69b22 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-dp.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-dp.c
@@ -8,6 +8,7 @@
*/
#include <linux/bitfield.h>
#include <linux/clk.h>
+#include <linux/gpio/consumer.h>
#include <linux/iopoll.h>
#include <linux/irq.h>
#include <linux/media-bus-format.h>
@@ -330,6 +331,8 @@ struct dw_dp {
u8 pixel_mode;
DECLARE_BITMAP(sdp_reg_bank, SDP_REG_BANK_SIZE);
+
+ struct gpio_desc *hpd_gpiod;
};
enum {
@@ -481,6 +484,9 @@ static bool dw_dp_hpd_detect(struct dw_dp *dp)
{
u32 value;
+ if (dp->hpd_gpiod)
+ return gpiod_get_value_cansleep(dp->hpd_gpiod);
+
regmap_read(dp->regmap, DW_DP_HPD_STATUS, &value);
return FIELD_GET(HPD_STATE, value) == DW_DP_HPD_STATE_PLUG;
@@ -2002,6 +2008,12 @@ struct dw_dp *dw_dp_bind(struct device *dev, struct drm_encoder *encoder,
return ERR_CAST(dp->regmap);
}
+ dp->hpd_gpiod = devm_gpiod_get_optional(dev, "hpd", GPIOD_IN);
+ if (IS_ERR(dp->hpd_gpiod)) {
+ dev_err_probe(dev, PTR_ERR(dp->hpd_gpiod), "failed to get hpd GPIO\n");
+ return ERR_CAST(dp->hpd_gpiod);
+ }
+
dp->phy = devm_of_phy_get(dev, dev->of_node, NULL);
if (IS_ERR(dp->phy)) {
dev_err_probe(dev, PTR_ERR(dp->phy), "failed to get phy\n");
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply related
* [PATCH v6 0/3] Add support for Orange Pi 5 Pro
From: dennis @ 2026-04-11 2:47 UTC (permalink / raw)
To: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Heiko Stuebner
Cc: FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Alexey Charkov, Peter Robinson, Dennis Gilmore, Michael Riesch,
Mykola Kvach, Jimmy Hon, devicetree, linux-arm-kernel,
linux-rockchip, linux-kernel
From: Dennis Gilmore <dennis@ausil.us>
This series adds initial support for Orange Pi 5 Pro. The PCIe attached network
driver(dwmac-motorcomm) was just added.
The series was tested against Linux 7.0-rc7
Please take a look.
Thank you,
Dennis Gilmore
Changes in v6:
- Move the shared configs for the Orange Pi 5 and Orange Pi 5b from each
devices dts to a shared rk3588s-orangepi-5-5b.dtsi to avoid duplication
- Remove empty ports subnodeis from typea_con
- Move i2s2m1_mclk pinctrl from &i2s2 to the es8388 codec node
- Add dp-con, dp0_out, dp0_in, and vp1 nodes, plus the vcc3v3_dp regulator
in order to get the second HDMI port working via its transparent
LT8711UXD DP to HDMI bridge
- link to v5 https://lore.kernel.org/linux-devicetree/20260401010707.2584962-1-dennis@ausil.us/
Changes in v5:
- define a connector node for Type-A port, and list the regulator as its VBUS supply explicitly.
- Requires https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
- link to v4 https://lore.kernel.org/linux-devicetree/20260310031002.3921234-1-dennis@ausil.us/
Changes in v4:
- rename vcc3v3_pcie20 copied from rk3588s-orangepi-5.dts to vcc3v3_phy1 to match the schematic
- use vcc_3v3_s3 as the supply not vcc5v0_sys for PCIe
- remove the definition for vcc3v3_pcie_m2 as it does not really exist
as a regulator
- link to v3 https://lore.kernel.org/linux-devicetree/20260306024634.239614-1-dennis@ausil.us/
Changes in v3:
- moved leds from gpio-leds to pwm-leds
- remove disable-wp from sdio
- rename vcc3v3_pcie_eth regulator to vcc3v3_pcie_m2 to reflect the
purppose
- actually clean up the delete lines and comments missed in v2
- link to v2 https://lore.kernel.org/linux-devicetree/20260304025521.210377-1-dennis@ausil.us/
Changes in v2:
- moved items not shared by orangepi 5/5b/5 Pro from dtsi to 5 and 5b
dts files
- removed all the comments and deleted properties from 5 Pro dts
- Link to v1 https://lore.kernel.org/linux-devicetree/20260228205418.2944620-1-dennis@ausil.us/
Dennis Gilmore (3):
dt-bindings: arm: rockchip: Add Orange Pi 5 Pro
arm64: dts: rockchip: refactor items from Orange Pi 5/b to prep for
Pro
arm64: dts: rockchip: Add Orange Pi 5 Pro board support
.../devicetree/bindings/arm/rockchip.yaml | 1 +
.../display/rockchip/rockchip,dw-dp.yaml | 7 +
arch/arm64/boot/dts/rockchip/Makefile | 1 +
.../dts/rockchip/rk3588s-orangepi-5-5b.dtsi | 192 ++++++++++
.../dts/rockchip/rk3588s-orangepi-5-pro.dts | 352 ++++++++++++++++++
.../boot/dts/rockchip/rk3588s-orangepi-5.dts | 6 +-
.../boot/dts/rockchip/rk3588s-orangepi-5.dtsi | 198 +---------
.../boot/dts/rockchip/rk3588s-orangepi-5b.dts | 2 +-
drivers/gpu/drm/bridge/synopsys/dw-dp.c | 12 +
9 files changed, 582 insertions(+), 189 deletions(-)
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-5b.dtsi
create mode 100644 arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts
--
2.53.0
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 6/9] iio: imu: inv_icm42607: Add Accelerometer for icm42607
From: David Lechner @ 2026-04-10 22:59 UTC (permalink / raw)
To: Chris Morgan, linux-iio
Cc: andy, nuno.sa, jic23, jean-baptiste.maneyrol, linux-rockchip,
devicetree, heiko, conor+dt, krzk+dt, robh, andriy.shevchenko,
Chris Morgan
In-Reply-To: <20260330195853.392877-7-macroalpha82@gmail.com>
On 3/30/26 2:58 PM, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add icm42607 accelerometer sensor for icm42607.
>
...
> +static const unsigned long inv_icm42607_accel_scan_masks[] = {
> + /* 3-axis accel + temperature */
> + INV_ICM42607_SCAN_MASK_ACCEL_3AXIS | INV_ICM42607_SCAN_MASK_TEMP,
This is going to make it so that the temperature channel is always read
even if it isn't enabled and additional work is needed when pushing to
buffers to remove it again.
It looks like it is possible to read accel and temp separatly, so
there shuold be two more lines here,
INV_ICM42607_SCAN_MASK_ACCEL_3AXIS,
INV_ICM42607_SCAN_MASK_TEMP,
I forget what the correct order is though.
> + 0,
> +};
> +
> +/* enable accelerometer sensor and FIFO write */
> +static int inv_icm42607_accel_update_scan_mode(struct iio_dev *indio_dev,
> + const unsigned long *scan_mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + unsigned int fifo_en = 0;
> + unsigned int sleep_temp = 0;
> + unsigned int sleep_accel = 0;
> + unsigned int sleep;
> + int ret;
> +
> + mutex_lock(&st->lock);
> +
> + if (*scan_mask & INV_ICM42607_SCAN_MASK_TEMP) {
> + /* enable temp sensor */
> + ret = inv_icm42607_set_temp_conf(st, true, &sleep_temp);
> + if (ret)
> + goto out_unlock;
> + fifo_en |= INV_ICM42607_SENSOR_TEMP;
> + }
> +
> + if (*scan_mask & INV_ICM42607_SCAN_MASK_ACCEL_3AXIS) {
> + /* enable accel sensor */
> + conf.mode = accel_st->power_mode;
> + conf.filter = accel_st->filter;
> + ret = inv_icm42607_set_accel_conf(st, &conf, &sleep_accel);
> + if (ret)
> + goto out_unlock;
> + fifo_en |= INV_ICM42607_SENSOR_ACCEL;
> + }
> +
> + /* update data FIFO write */
> + ret = inv_icm42607_buffer_set_fifo_en(st, fifo_en | st->fifo.en);
> +
> +out_unlock:
> + mutex_unlock(&st->lock);
> + /* sleep maximum required time */
Would be better if the comment explain _why_ we need to sleep.
The code is pretty obvious that it does what the comment says, so
it doesn't add much.
> + sleep = max(sleep_accel, sleep_temp);
> + if (sleep)
Probably don't need the if here as msleep() should handle 0 without actually
sleeping.
> + msleep(sleep);
> + return ret;
> +}
> +
> +static int inv_icm42607_accel_read_sensor(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + s16 *val)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + struct inv_icm42607_sensor_state *accel_st = iio_priv(indio_dev);
> + struct device *dev = regmap_get_device(st->map);
> + struct inv_icm42607_sensor_conf conf = INV_ICM42607_SENSOR_CONF_INIT;
> + unsigned int reg;
> + __be16 *data;
> + int ret;
> +
> + if (chan->type != IIO_ACCEL)
> + return -EINVAL;
> +
> + switch (chan->channel2) {
> + case IIO_MOD_X:
> + reg = INV_ICM42607_REG_ACCEL_DATA_X1;
> + break;
> + case IIO_MOD_Y:
> + reg = INV_ICM42607_REG_ACCEL_DATA_Y1;
> + break;
> + case IIO_MOD_Z:
> + reg = INV_ICM42607_REG_ACCEL_DATA_Z1;
> + break;
> + default:
> + return -EINVAL;
> + }
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
> +
> + guard(mutex)(&st->lock);
> +
> + /* enable accel sensor */
> + conf.mode = accel_st->power_mode;
> + conf.filter = accel_st->filter;
> + ret = inv_icm42607_set_accel_conf(st, &conf, NULL);
> + if (ret)
> + return ret;
> +
> + /* read accel register data */
> + data = (__be16 *)&st->buffer[0];
> + ret = regmap_bulk_read(st->map, reg, data, sizeof(*data));
> + if (ret)
> + return ret;
> +
> + *val = (int16_t)be16_to_cpup(data);
We don't use int16_t in the kernel (ideally). Stick with s16.
Although cast isn't needed here since val is already s16.
> + if (*val == INV_ICM42607_DATA_INVALID)
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> +/* IIO format int + nano */
Usually we make these 2-D arrays for readability and then cast to int * if needed.
> +static const int inv_icm42607_accel_scale[] = {
> + /* +/- 16G => 0.004788403 m/s-2 */
> + [2 * INV_ICM42607_ACCEL_FS_16G] = 0,
> + [2 * INV_ICM42607_ACCEL_FS_16G + 1] = 4788403,
> + /* +/- 8G => 0.002394202 m/s-2 */
> + [2 * INV_ICM42607_ACCEL_FS_8G] = 0,
> + [2 * INV_ICM42607_ACCEL_FS_8G + 1] = 2394202,
> + /* +/- 4G => 0.001197101 m/s-2 */
> + [2 * INV_ICM42607_ACCEL_FS_4G] = 0,
> + [2 * INV_ICM42607_ACCEL_FS_4G + 1] = 1197101,
> + /* +/- 2G => 0.000598550 m/s-2 */
> + [2 * INV_ICM42607_ACCEL_FS_2G] = 0,
> + [2 * INV_ICM42607_ACCEL_FS_2G + 1] = 598550,
> +};
> +
...
> +static int inv_icm42607_accel_read_calibbias(struct inv_icm42607_state *st,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2)
> +{
> + /* Not actually supported in the ICM-42607P registers */
> + return -EOPNOTSUPP;
> +}
Can we just not create the attribute instead of returning an error?
> +static int inv_icm42607_accel_write_raw_get_fmt(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + long mask)
> +{
> + if (chan->type != IIO_ACCEL)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_SCALE:
> + return IIO_VAL_INT_PLUS_NANO;
> + case IIO_CHAN_INFO_SAMP_FREQ:
> + return IIO_VAL_INT_PLUS_MICRO;
> + case IIO_CHAN_INFO_CALIBBIAS:
> + return IIO_VAL_INT_PLUS_MICRO;
Can write this as:
case IIO_CHAN_INFO_SAMP_FREQ:
case IIO_CHAN_INFO_CALIBBIAS:
return IIO_VAL_INT_PLUS_MICRO;
> + default:
> + return -EINVAL;
> + }
> +}
> +
...
> +int inv_icm42607_set_accel_conf(struct inv_icm42607_state *st,
> + struct inv_icm42607_sensor_conf *conf,
> + unsigned int *sleep_ms)
> +{
> + struct inv_icm42607_sensor_conf *oldconf = &st->conf.accel;
> + unsigned int val;
> + int ret;
> +
> + if (conf->mode < 0)
> + conf->mode = oldconf->mode;
> + if (conf->fs < 0)
> + conf->fs = oldconf->fs;
> + if (conf->odr < 0)
> + conf->odr = oldconf->odr;
> + if (conf->filter < 0)
> + conf->filter = oldconf->filter;
> +
> + if (conf->fs != oldconf->fs || conf->odr != oldconf->odr) {
We could use the regmap cache feature to avoid having to manual keep
track of old values. Or just always write the same values anyway. I
find that is nice when debugging hardware with a logic analyzer. Unless
there is some measureable performance improvlment here?
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> + oldconf->fs = conf->fs;
> + oldconf->odr = conf->odr;
> + }
> +
> + if (conf->filter != oldconf->filter) {
> + if (conf->mode == INV_ICM42607_SENSOR_MODE_LOW_POWER) {
> + val = INV_ICM42607_ACCEL_CONFIG1_AVG(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_AVG_MASK, val);
> + } else {
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->filter);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_ACCEL_CONFIG1,
> + INV_ICM42607_ACCEL_CONFIG1_FILTER_MASK, val);
> + }
> + if (ret)
> + return ret;
> + oldconf->filter = conf->filter;
> + }
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode, conf->mode,
> + st->conf.temp_en, sleep_ms);
> +}
> +
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 5/9] iio: imu: inv_icm42607: Add Temperature Support in icm42607
From: David Lechner @ 2026-04-10 22:34 UTC (permalink / raw)
To: Chris Morgan, linux-iio
Cc: andy, nuno.sa, jic23, jean-baptiste.maneyrol, linux-rockchip,
devicetree, heiko, conor+dt, krzk+dt, robh, andriy.shevchenko,
Chris Morgan
In-Reply-To: <20260330195853.392877-6-macroalpha82@gmail.com>
On 3/30/26 2:58 PM, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add functions for reading temperature sensor data.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 3 +
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 17 ++++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.c | 81 +++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_temp.h | 30 +++++++
> 4 files changed, 131 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_temp.h
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 5530fd3bc03f..086848c8fd3b 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> @@ -433,6 +433,9 @@ extern const struct dev_pm_ops inv_icm42607_pm_ops;
>
> u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr);
>
> +int inv_icm42607_set_temp_conf(struct inv_icm42607_state *st, bool enable,
> + unsigned int *sleep_ms);
> +
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> unsigned int writeval, unsigned int *readval);
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 344071089042..735a262dc103 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> @@ -164,6 +164,23 @@ static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> return 0;
> }
>
> +int inv_icm42607_set_temp_conf(struct inv_icm42607_state *st, bool enable,
> + unsigned int *sleep_ms)
> +{
> + unsigned int val;
> + int ret;
> +
> + val = INV_ICM42607_TEMP_CONFIG0_FILTER(INV_ICM42607_FILTER_BW_34HZ);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_TEMP_CONFIG0,
> + INV_ICM42607_TEMP_CONFIG0_FILTER_MASK, val);
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_pwr_mgmt0(st, st->conf.gyro.mode,
> + st->conf.accel.mode, enable,
> + sleep_ms);
> +}
> +
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> unsigned int writeval, unsigned int *readval)
> {
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> new file mode 100644
> index 000000000000..b42eb78cd960
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_temp.c
> @@ -0,0 +1,81 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/mutex.h>
> +#include <linux/pm_runtime.h>
> +#include <linux/regmap.h>
> +#include <linux/iio/iio.h>
> +
> +#include "inv_icm42607.h"
> +#include "inv_icm42607_temp.h"
> +
> +static int inv_icm42607_temp_read(struct inv_icm42607_state *st, s16 *temp)
> +{
> + struct device *dev = regmap_get_device(st->map);
> + __be16 *raw;
> + int ret;
> +
> + PM_RUNTIME_ACQUIRE_AUTOSUSPEND(dev, pm);
> + if (PM_RUNTIME_ACQUIRE_ERR(&pm))
> + return -ENXIO;
> +
> + guard(mutex)(&st->lock);
> +
> + ret = inv_icm42607_set_temp_conf(st, true, NULL);
> + if (ret)
> + return ret;
> +
> + raw = (__be16 *)&st->buffer[0];
Can we make buffer __be16 buffer[] to avoid cast and ensure proper alignment?
> + ret = regmap_bulk_read(st->map, INV_ICM42607_REG_TEMP_DATA1, raw, sizeof(*raw));
> + if (ret)
> + return ret;
> +
> + *temp = (s16)be16_to_cpup(raw);
cast is not needed. temp is already s16.
> + if (*temp == INV_ICM42607_DATA_INVALID)
> + ret = -EINVAL;
> +
> + return ret;
> +}
> +
> +int inv_icm42607_temp_read_raw(struct iio_dev *indio_dev,
> + struct iio_chan_spec const *chan,
> + int *val, int *val2, long mask)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> + s16 temp;
> + int ret;
> +
> + if (chan->type != IIO_TEMP)
> + return -EINVAL;
> +
> + switch (mask) {
> + case IIO_CHAN_INFO_RAW:
> + if (!iio_device_claim_direct(indio_dev))
> + return -EBUSY;
> + ret = inv_icm42607_temp_read(st, &temp);
> + iio_device_release_direct(indio_dev);
> + if (ret)
> + return ret;
> + *val = temp;
> + return IIO_VAL_INT;
> + /*
> + * T°C = (temp / 128) + 25
> + * Tm°C = 1000 * ((temp * 100 / 12800) + 25)
> + * scale: 100000 / 12800 ~= 7.8125
> + * offset: 25000
> + */
> + case IIO_CHAN_INFO_SCALE:
> + *val = 7;
> + *val2 = 812500;
> + return IIO_VAL_INT_PLUS_MICRO;
Could use IIO_VAL_INT_PLUS_NANO to get more exact value.
> + case IIO_CHAN_INFO_OFFSET:
> + *val = 25000;
> + return IIO_VAL_INT;
> + default:
> + return -EINVAL;
> + }
> +}
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 3/9] iio: imu: inv_icm42607: Add I2C and SPI For icm42607
From: David Lechner @ 2026-04-10 22:21 UTC (permalink / raw)
To: Chris Morgan, linux-iio
Cc: andy, nuno.sa, jic23, jean-baptiste.maneyrol, linux-rockchip,
devicetree, heiko, conor+dt, krzk+dt, robh, andriy.shevchenko,
Chris Morgan
In-Reply-To: <20260330195853.392877-4-macroalpha82@gmail.com>
On 3/30/26 2:58 PM, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add I2C and SPI driver support for InvenSense ICM-42607 devices.
> Include runtime power management on each device.
Power management seems unrelated, so likey belongs in a separate patch.
>
> Signed-off-by: Chris Morgan <macromorgan@hotmail.com>
> ---
> drivers/iio/imu/inv_icm42607/inv_icm42607.h | 14 ++
> .../iio/imu/inv_icm42607/inv_icm42607_core.c | 204 ++++++++++++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_i2c.c | 93 ++++++++
> .../iio/imu/inv_icm42607/inv_icm42607_spi.c | 100 +++++++++
> 4 files changed, 411 insertions(+)
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> create mode 100644 drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
>
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607.h b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> index 609188c40ffc..7d13091aa8df 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607.h
> @@ -11,6 +11,7 @@
> #include <linux/regmap.h>
> #include <linux/mutex.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/pm.h>
> #include <linux/iio/iio.h>
> #include <linux/iio/common/inv_sensors_timestamp.h>
>
> @@ -21,6 +22,16 @@ enum inv_icm42607_chip {
> INV_CHIP_NB,
> };
>
> +/* serial bus slew rates */
> +enum inv_icm42607_slew_rate {
> + INV_ICM42607_SLEW_RATE_20_60NS,
> + INV_ICM42607_SLEW_RATE_12_36NS,
> + INV_ICM42607_SLEW_RATE_6_18NS,
> + INV_ICM42607_SLEW_RATE_4_12NS,
> + INV_ICM42607_SLEW_RATE_2_6NS,
> + INV_ICM42607_SLEW_RATE_INF_2NS,
> +};
> +
> enum inv_icm42607_sensor_mode {
> INV_ICM42607_SENSOR_MODE_OFF,
> INV_ICM42607_SENSOR_MODE_STANDBY,
> @@ -413,6 +424,9 @@ struct inv_icm42607_sensor_state {
>
> typedef int (*inv_icm42607_bus_setup)(struct inv_icm42607_state *);
>
> +extern const struct regmap_config inv_icm42607_regmap_config;
> +extern const struct dev_pm_ops inv_icm42607_pm_ops;
> +
> u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr);
>
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> index 6b7078387568..da04c820dab2 100644
> --- a/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_core.c
> @@ -12,12 +12,33 @@
> #include <linux/interrupt.h>
> #include <linux/irq.h>
> #include <linux/regulator/consumer.h>
> +#include <linux/pm_runtime.h>
> #include <linux/property.h>
> #include <linux/regmap.h>
> #include <linux/iio/iio.h>
>
> #include "inv_icm42607.h"
>
> +static const struct regmap_range_cfg inv_icm42607_regmap_ranges[] = {
> + {
> + .name = "user bank",
> + .range_min = 0x0000,
> + .range_max = 0x00FF,
> + .window_start = 0,
> + .window_len = 0x0100,
> + },
> +};
> +
> +const struct regmap_config inv_icm42607_regmap_config = {
> + .reg_bits = 8,
> + .val_bits = 8,
> + .max_register = 0x00FF,
> + .ranges = inv_icm42607_regmap_ranges,
> + .num_ranges = ARRAY_SIZE(inv_icm42607_regmap_ranges),
> + .cache_type = REGCACHE_NONE,
> +};
> +EXPORT_SYMBOL_NS_GPL(inv_icm42607_regmap_config, "IIO_ICM42607");
It would make more sense to include the regmap config in the first patch
since it is shared.
> +
> struct inv_icm42607_hw {
> uint8_t whoami;
> const char *name;
> @@ -86,6 +107,62 @@ u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr)
> return odr_periods[odr];
> }
>
> +static int inv_icm42607_set_pwr_mgmt0(struct inv_icm42607_state *st,
> + enum inv_icm42607_sensor_mode gyro,
> + enum inv_icm42607_sensor_mode accel,
> + bool temp, unsigned int *sleep_ms)
> +{
> + enum inv_icm42607_sensor_mode oldgyro = st->conf.gyro.mode;
> + enum inv_icm42607_sensor_mode oldaccel = st->conf.accel.mode;
> + bool oldtemp = st->conf.temp_en;
> + unsigned int sleepval;
> + unsigned int val;
> + int ret;
> +
> + if (gyro == oldgyro && accel == oldaccel && temp == oldtemp)
> + return 0;
> +
> + val = INV_ICM42607_PWR_MGMT0_GYRO(gyro) |
> + INV_ICM42607_PWR_MGMT0_ACCEL(accel);
> + if (!temp)
> + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + st->conf.gyro.mode = gyro;
> + st->conf.accel.mode = accel;
> + st->conf.temp_en = temp;
> +
> + sleepval = 0;
> + if (temp && !oldtemp) {
> + if (sleepval < INV_ICM42607_TEMP_STARTUP_TIME_MS)
> + sleepval = INV_ICM42607_TEMP_STARTUP_TIME_MS;
> + }
> + if (accel != oldaccel && oldaccel == INV_ICM42607_SENSOR_MODE_OFF) {
> + usleep_range(200, 300);
> + if (sleepval < INV_ICM42607_ACCEL_STARTUP_TIME_MS)
> + sleepval = INV_ICM42607_ACCEL_STARTUP_TIME_MS;
> + }
> + if (gyro != oldgyro) {
> + if (oldgyro == INV_ICM42607_SENSOR_MODE_OFF) {
> + usleep_range(200, 300);
> + if (sleepval < INV_ICM42607_GYRO_STARTUP_TIME_MS)
> + sleepval = INV_ICM42607_GYRO_STARTUP_TIME_MS;
> + } else if (gyro == INV_ICM42607_SENSOR_MODE_OFF) {
> + if (sleepval < INV_ICM42607_GYRO_STOP_TIME_MS)
> + sleepval = INV_ICM42607_GYRO_STOP_TIME_MS;
> + }
> + }
> +
> + if (sleep_ms)
> + *sleep_ms = sleepval;
> + else if (sleepval)
> + msleep(sleepval);
> +
> + return 0;
> +}
> +
> int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> unsigned int writeval, unsigned int *readval)
> {
> @@ -219,6 +296,10 @@ static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
> static void inv_icm42607_disable_vddio_reg(void *_data)
> {
> struct inv_icm42607_state *st = _data;
> + struct device *dev = regmap_get_device(st->map);
> +
> + if (pm_runtime_status_suspended(dev))
> + return;
>
> regulator_disable(st->vddio_supply);
> }
> @@ -289,11 +370,134 @@ int inv_icm42607_core_probe(struct regmap *regmap, int chip,
>
> /* Setup chip registers (includes WHOAMI check, reset check, bus setup) */
> ret = inv_icm42607_setup(st, bus_setup);
> + if (ret)
> + return ret; /* Return error from setup (e.g., WHOAMI fail) */
> +
> + /* Setup runtime power management */
Would add a blank line here if this is meant to apply to more than the
following line. Otherwise it doesn't add much.
> + ret = devm_pm_runtime_set_active_enabled(dev);
> + if (ret)
> + return ret;
> +
> + pm_runtime_set_autosuspend_delay(dev, INV_ICM42607_SUSPEND_DELAY_MS);
> + pm_runtime_use_autosuspend(dev);
>
> return ret;
> }
> EXPORT_SYMBOL_NS_GPL(inv_icm42607_core_probe, "IIO_ICM42607");
>
...
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> new file mode 100644
> index 000000000000..eb72973debc5
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_i2c.c
> @@ -0,0 +1,93 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/i2c.h>
> +#include <linux/regmap.h>
> +#include <linux/property.h>
> +
> +#include "inv_icm42607.h"
> +
> +static int inv_icm42607_i2c_bus_setup(struct inv_icm42607_state *st)
> +{
> + unsigned int mask, val;
> + int ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
> + INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN, 0);
regmap_clear_bits()
> + if (ret)
> + return ret;
> +
> + mask = INV_ICM42607_DRIVE_CONFIG2_I2C_MASK;
Local mask variable isn't helping much.
> + val = INV_ICM42607_DRIVE_CONFIG2_I2C(INV_ICM42607_SLEW_RATE_12_36NS);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG2,
> + mask, val);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_SPI_DIS);
> +}
> +
> +static int inv_icm42607_probe(struct i2c_client *client)
> +{
> + const void *match;
> + enum inv_icm42607_chip chip;
> + struct regmap *regmap;
> +
> + if (!i2c_check_functionality(client->adapter, I2C_FUNC_SMBUS_I2C_BLOCK))
> + return -EOPNOTSUPP;
> +
> + match = device_get_match_data(&client->dev);
Should be i2c_get_match_data(). And we recently decided to standardize
on not checking for NULL return.
> + if (!match)
> + return -EINVAL;
> + chip = (uintptr_t)match;
> +
> + regmap = devm_regmap_init_i2c(client, &inv_icm42607_regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + return inv_icm42607_core_probe(regmap, chip, inv_icm42607_i2c_bus_setup);
> +}
> +
> +static const struct i2c_device_id inv_icm42607_id[] = {
> + { "icm42607", INV_CHIP_ICM42607 },
> + { "icm42607p", INV_CHIP_ICM42607P },
> + { }
> +};
> +MODULE_DEVICE_TABLE(i2c, inv_icm42607_id);
> +
> +static const struct of_device_id inv_icm42607_of_matches[] = {
> + {
> + .compatible = "invensense,icm42607",
> + .data = (void *)INV_CHIP_ICM42607,
> + }, {
> + .compatible = "invensense,icm42607p",
> + .data = (void *)INV_CHIP_ICM42607P,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
> +
> +static struct i2c_driver inv_icm42607_driver = {
> + .driver = {
> + .name = "inv-icm42607-i2c",
> + .of_match_table = inv_icm42607_of_matches,
> + .pm = pm_ptr(&inv_icm42607_pm_ops),
> + },
> + .id_table = inv_icm42607_id,
> + .probe = inv_icm42607_probe,
> +};
> +module_i2c_driver(inv_icm42607_driver);
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-42607x I2C driver");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("IIO_ICM42607");
> diff --git a/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> new file mode 100644
> index 000000000000..51ce3deeb706
> --- /dev/null
> +++ b/drivers/iio/imu/inv_icm42607/inv_icm42607_spi.c
> @@ -0,0 +1,100 @@
> +// SPDX-License-Identifier: GPL-2.0-or-later
> +/*
> + * Copyright (C) 2026 InvenSense, Inc.
> + */
> +
> +#include <linux/kernel.h>
> +#include <linux/device.h>
> +#include <linux/module.h>
> +#include <linux/mod_devicetable.h>
> +#include <linux/spi/spi.h>
> +#include <linux/regmap.h>
> +#include <linux/property.h>
> +
> +#include "inv_icm42607.h"
> +
> +static int inv_icm42607_spi_bus_setup(struct inv_icm42607_state *st)
> +{
> + unsigned int mask, val;
> + int ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_DEVICE_CONFIG,
> + INV_ICM42607_DEVICE_CONFIG_SPI_AP_4WIRE,
> + INV_ICM42607_DEVICE_CONFIG_SPI_AP_4WIRE);
regmap_set_bits()
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_I3C_DDR_EN |
> + INV_ICM42607_INTF_CONFIG1_I3C_SDR_EN, 0);
regmap_clear_bits()
> + if (ret)
> + return ret;
> +
> + mask = INV_ICM42607_DRIVE_CONFIG3_SPI_MASK;
> + val = INV_ICM42607_DRIVE_CONFIG3_SPI(INV_ICM42607_SLEW_RATE_INF_2NS);
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_DRIVE_CONFIG3,
> + mask, val);
> + if (ret)
> + return ret;
> +
> + return regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_MASK,
> + INV_ICM42607_INTF_CONFIG0_UI_SIFS_CFG_I2C_DIS);
> +}
> +
> +static int inv_icm42607_probe(struct spi_device *spi)
> +{
> + const void *match;
> + enum inv_icm42607_chip chip;
> + struct regmap *regmap;
> +
> + match = device_get_match_data(&spi->dev);
> + if (!match)
> + return -EINVAL;
Should be spi_get_device_match_data(). And we recently decided to standardize
on not checking for NULL return.
> + chip = (uintptr_t)match;
uintptr_t is frowned upon in the kernel. Stick with kernel_ulong_t.
> +
> + regmap = devm_regmap_init_spi(spi, &inv_icm42607_regmap_config);
> + if (IS_ERR(regmap))
> + return dev_err_probe(&spi->dev, PTR_ERR(regmap),
> + "Failed to register spi regmap %ld\n",
> + PTR_ERR(regmap));
> +
> + return inv_icm42607_core_probe(regmap, chip,
> + inv_icm42607_spi_bus_setup);
> +}
> +
> +static const struct of_device_id inv_icm42607_of_matches[] = {
> + {
> + .compatible = "invensense,icm42607",
> + .data = (void *)INV_CHIP_ICM42607,
> + },
> + {
> + .compatible = "invensense,icm42607p",
> + .data = (void *)INV_CHIP_ICM42607P,
> + },
> + { }
> +};
> +MODULE_DEVICE_TABLE(of, inv_icm42607_of_matches);
> +
> +static const struct spi_device_id inv_icm42607_spi_id_table[] = {
> + { "icm42607", INV_CHIP_ICM42607 },
> + { "icm42607p", INV_CHIP_ICM42607P },
> + { },
No trailing comma.
> +};
> +MODULE_DEVICE_TABLE(spi, inv_icm42607_spi_id_table);
> +
> +static struct spi_driver inv_icm42607_driver = {
> + .driver = {
> + .name = "inv-icm42607-spi",
> + .of_match_table = inv_icm42607_of_matches,
> + .pm = &inv_icm42607_pm_ops,
> + },
> + .id_table = inv_icm42607_spi_id_table,
> + .probe = inv_icm42607_probe,
> +};
> +module_spi_driver(inv_icm42607_driver);
> +
> +MODULE_AUTHOR("InvenSense, Inc.");
> +MODULE_DESCRIPTION("InvenSense ICM-42607x SPI driver");
> +MODULE_LICENSE("GPL");
> +MODULE_IMPORT_NS("IIO_ICM42607");
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH V3 2/9] iio: imu: inv_icm42607: Add Core for inv_icm42607 Driver
From: David Lechner @ 2026-04-10 22:06 UTC (permalink / raw)
To: Chris Morgan, linux-iio
Cc: andy, nuno.sa, jic23, jean-baptiste.maneyrol, linux-rockchip,
devicetree, heiko, conor+dt, krzk+dt, robh, andriy.shevchenko,
Chris Morgan
In-Reply-To: <20260330195853.392877-3-macroalpha82@gmail.com>
On 3/30/26 2:58 PM, Chris Morgan wrote:
> From: Chris Morgan <macromorgan@hotmail.com>
>
> Add the core component of a new inv_icm42607 driver. This includes
> a few setup functions and the full register definition in the
> header file.
>
> +#define INV_ICM42607_REG_PWR_MGMT0 0x1F
> +#define INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL BIT(7)
> +#define INV_ICM42607_PWR_MGMT0_IDLE BIT(4)
> +#define INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK GENMASK(3, 2)
> +#define INV_ICM42607_PWR_MGMT0_GYRO(_mode) \
> + FIELD_PREP(INV_ICM42607_PWR_MGMT0_GYRO_MODE_MASK, (_mode))
We usually try to avoid macros that hide FIELD_PREP(). IMHO, it makes
the code harder to read because you have to jump back and forth to
definitions to see if it really is that.
> +#define INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK GENMASK(1, 0)
> +#define INV_ICM42607_PWR_MGMT0_ACCEL(_mode) \
> + FIELD_PREP(INV_ICM42607_PWR_MGMT0_ACCEL_MODE_MASK, (_mode))
> +
...
> +u32 inv_icm42607_odr_to_period(enum inv_icm42607_odr odr)
> +{
> + static u32 odr_periods[INV_ICM42607_ODR_NB] = {
> + /* Reserved values */
> + 0, 0, 0, 0, 0,
> + /* 1600Hz */
> + 625000,
> + /* 800Hz */
> + 1250000,
> + /* 400Hz */
> + 2500000,
> + /* 200Hz */
> + 5000000,
> + /* 100 Hz */
> + 10000000,
> + /* 50Hz */
> + 20000000,
> + /* 25Hz */
> + 40000000,
> + /* 12.5Hz */
> + 80000000,
> + /* 6.25Hz */
> + 160000000,
> + /* 3.125Hz */
> + 320000000,
> + /* 1.5625Hz */
> + 640000000,
> + };
No range checking to avoid out-of-bouds access?
> +
> + return odr_periods[odr];
> +}
> +
> +int inv_icm42607_debugfs_reg(struct iio_dev *indio_dev, unsigned int reg,
> + unsigned int writeval, unsigned int *readval)
> +{
> + struct inv_icm42607_state *st = iio_device_get_drvdata(indio_dev);
> +
> + guard(mutex)(&st->lock);
> +
> + if (readval)
> + return regmap_read(st->map, reg, readval);
> +
> + return regmap_write(st->map, reg, writeval);
> +}
> +
> +static int inv_icm42607_set_conf(struct inv_icm42607_state *st,
> + const struct inv_icm42607_conf *conf)
> +{
> + unsigned int val;
> + int ret;
> +
> + val = INV_ICM42607_PWR_MGMT0_GYRO(conf->gyro.mode) |
> + INV_ICM42607_PWR_MGMT0_ACCEL(conf->accel.mode);
Indent wrapped lines one tab or line up with INV_ after `= `.
> + /*
> + * No temperature enable reg in datasheet, but BSP driver
> + * selected RC oscillator clock in LP mode when temperature
> + * was disabled.
> + */
> + if (!conf->temp_en)
> + val |= INV_ICM42607_PWR_MGMT0_ACCEL_LP_CLK_SEL;
> + ret = regmap_write(st->map, INV_ICM42607_REG_PWR_MGMT0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG0_FS_SEL(conf->gyro.fs) |
> + INV_ICM42607_GYRO_CONFIG0_ODR(conf->gyro.odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG0_FS_SEL(conf->accel.fs) |
> + INV_ICM42607_ACCEL_CONFIG0_ODR(conf->accel.odr);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG0, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_GYRO_CONFIG1_FILTER(conf->gyro.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_GYRO_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + val = INV_ICM42607_ACCEL_CONFIG1_FILTER(conf->accel.filter);
> + ret = regmap_write(st->map, INV_ICM42607_REG_ACCEL_CONFIG1, val);
> + if (ret)
> + return ret;
> +
> + st->conf = *conf;
> +
> + return 0;
> +}
> +
> +/**
> + * inv_icm42607_setup() - check and setup chip
> + * @st: driver internal state
> + * @bus_setup: callback for setting up bus specific registers
> + *
> + * Returns 0 on success, a negative error code otherwise.
> + */
> +static int inv_icm42607_setup(struct inv_icm42607_state *st,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + const struct inv_icm42607_hw *hw = &inv_icm42607_hw[st->chip];
> + const struct device *dev = regmap_get_device(st->map);
> + unsigned int val;
> + int ret;
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_WHOAMI, &val);
> + if (ret)
> + return ret;
> +
> + if (val != hw->whoami)
> + dev_warn_probe(dev, -ENODEV,
> + "invalid whoami %#02x expected %#02x (%s)\n",
> + val, hw->whoami, hw->name);
> +
> + st->name = hw->name;
> +
> + ret = regmap_write(st->map, INV_ICM42607_REG_SIGNAL_PATH_RESET,
> + INV_ICM42607_SIGNAL_PATH_RESET_SOFT_RESET);
> + if (ret)
> + return ret;
nit: Add blank line here.
> + msleep(INV_ICM42607_RESET_TIME_MS);
> +
> + ret = regmap_read(st->map, INV_ICM42607_REG_INT_STATUS, &val);
> + if (ret)
> + return ret;
> + if (!(val & INV_ICM42607_INT_STATUS_RESET_DONE))
> + return dev_err_probe(dev, -ENODEV,
> + "reset error, reset done bit not set\n");
Could also replace this and msleep with regmap_read_poll_timeout().
> +
> + ret = bus_setup(st);
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG0,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN,
> + INV_ICM42607_INTF_CONFIG0_SENSOR_DATA_ENDIAN);
Simplify with regmap_set_bits().
> + if (ret)
> + return ret;
> +
> + ret = regmap_update_bits(st->map, INV_ICM42607_REG_INTF_CONFIG1,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_MASK,
> + INV_ICM42607_INTF_CONFIG1_CLKSEL_PLL);
> + if (ret)
> + return ret;
> +
> + return inv_icm42607_set_conf(st, hw->conf);
> +}
> +
> +static int inv_icm42607_enable_vddio_reg(struct inv_icm42607_state *st)
> +{
> + int ret;
> +
> + ret = regulator_enable(st->vddio_supply);
> + if (ret)
> + return ret;
> +
> + usleep_range(3000, 4000);
Use fsleep() and add a comment to explain why the duration
was chosen.
> +
> + return 0;
> +}
> +
> +static void inv_icm42607_disable_vddio_reg(void *_data)
> +{
> + struct inv_icm42607_state *st = _data;
> +
> + regulator_disable(st->vddio_supply);
> +}
> +
> +int inv_icm42607_core_probe(struct regmap *regmap, int chip,
> + inv_icm42607_bus_setup bus_setup)
> +{
> + struct device *dev = regmap_get_device(regmap);
> + struct fwnode_handle *fwnode = dev_fwnode(dev);
> + struct inv_icm42607_state *st;
> + int irq, irq_type;
> + bool open_drain;
> + int ret;
> +
> + if (chip < INV_CHIP_INVALID || chip >= INV_CHIP_NB)
Only two chips are defined in regmap_read_poll_timeout, so this range
checking seems wrong.
> + dev_warn_probe(dev, -ENODEV,
> + "Invalid chip = %d\n", chip);
> +
> + /* get INT1 only supported interrupt or fallback to first interrupt */
> + irq = fwnode_irq_get_byname(fwnode, "INT1");
> + if (irq < 0 && irq != -EPROBE_DEFER) {
> + dev_info(dev, "no INT1 interrupt defined, fallback to first interrupt\n");
> + irq = fwnode_irq_get(fwnode, 0);
> + }
> + if (irq < 0)
> + return dev_err_probe(dev, irq, "error missing INT1 interrupt\n");
> +
> + irq_type = irq_get_trigger_type(irq);
> + if (!irq_type)
> + irq_type = IRQF_TRIGGER_FALLING;
> +
> + open_drain = device_property_read_bool(dev, "drive-open-drain");
> +
> + st = devm_kzalloc(dev, sizeof(*st), GFP_KERNEL);
> + if (!st)
> + return -ENOMEM;
> +
> + dev_set_drvdata(dev, st);
> + mutex_init(&st->lock);
> + st->chip = chip;
> + st->map = regmap;
> + st->irq = irq;
> +
> + ret = iio_read_mount_matrix(dev, &st->orientation);
> + if (ret) {
> + dev_err(dev, "failed to retrieve mounting matrix %d\n", ret);
> + return ret;
> + }
> +
> + ret = devm_regulator_get_enable(dev, "vdd");
> + if (ret)
> + return dev_err_probe(dev, ret,
> + "Failed to get vdd regulator\n");
> +
> + msleep(INV_ICM42607_POWER_UP_TIME_MS);
> +
> + st->vddio_supply = devm_regulator_get(dev, "vddio");
If we aren't implementing power managament, we can just use
devm_regulator_get_enabled() and avoid the devm_add_action_or_reset().
> + if (IS_ERR(st->vddio_supply))
> + return PTR_ERR(st->vddio_supply);
> +
> + ret = inv_icm42607_enable_vddio_reg(st);
> + if (ret)
> + return ret;
> +
> + ret = devm_add_action_or_reset(dev, inv_icm42607_disable_vddio_reg, st);
> + if (ret)
> + return ret;
> +
> + /* Setup chip registers (includes WHOAMI check, reset check, bus setup) */
This comment would be better as part of the function doc comment.
> + ret = inv_icm42607_setup(st, bus_setup);
> +
> + return ret;
> +}
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH 04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
From: Theodore Ts'o @ 2026-04-10 15:18 UTC (permalink / raw)
To: amd-gfx, apparmor, bpf, ceph-devel, cocci, dm-devel, dri-devel,
gfs2, intel-gfx, intel-wired-lan, iommu, kvm, linux-arm-kernel,
linux-block, linux-bluetooth, linux-btrfs, linux-cifs, linux-clk,
linux-erofs, linux-ext4, linux-fsdevel, linux-gpio, linux-hyperv,
linux-input, linux-kernel, linux-leds, linux-media, linux-mips,
linux-mm, linux-modules, linux-mtd, linux-nfs, linux-omap,
linux-phy, linux-pm, linux-rockchip, linux-s390, linux-scsi,
linux-sctp, linux-security-module, linux-sh, linux-sound,
linux-stm32, linux-trace-kernel, linux-usb, linux-wireless,
netdev, ntfs3, samba-technical, sched-ext, target-devel,
tipc-discussion, v9fs, Philipp Hahn
Cc: Theodore Ts'o, Andreas Dilger
In-Reply-To: <20260310-b4-is_err_or_null-v1-4-bd63b656022d@avm.de>
On Tue, 10 Mar 2026 12:48:30 +0100, Philipp Hahn wrote:
> Prefer using IS_ERR_OR_NULL() over using IS_ERR() and a manual NULL
> check.
>
> Change generated with coccinelle.
Applied, thanks!
[04/61] ext4: Prefer IS_ERR_OR_NULL over manual NULL check
commit: 1d749e110277ce4103f27bd60d6181e52c0cc1e3
Best regards,
--
Theodore Ts'o <tytso@mit.edu>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH v12 04/25] drm/bridge: Act on the DRM color format property
From: Nicolas Frattaroli @ 2026-04-10 14:21 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Harry Wentland, Leo Li, Rodrigo Siqueira, Alex Deucher,
Christian König, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann,
Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Sandy Huang, Heiko Stübner,
Andy Yan, Jani Nikula, Rodrigo Vivi, Joonas Lahtinen,
Tvrtko Ursulin, Dmitry Baryshkov, Sascha Hauer, Rob Herring,
Jonathan Corbet, Shuah Khan, kernel, amd-gfx, dri-devel,
linux-kernel, linux-arm-kernel, linux-rockchip, intel-gfx,
intel-xe, linux-doc
In-Reply-To: <edeq6wxmwzvovfoo6pvih6dybwszf3tahg7nvqkjrw3qxllbfd@jwejh2sgb5eh>
On Friday, 10 April 2026 00:08:24 Central European Summer Time Dmitry Baryshkov wrote:
> On Thu, Apr 09, 2026 at 05:44:54PM +0200, Nicolas Frattaroli wrote:
> > The new DRM color format property allows userspace to request a specific
> > color format on a connector. In turn, this fills the connector state's
> > color_format member to switch color formats.
> >
> > Make drm_bridges consider the color_format set in the connector state
> > during the atomic bridge check. For bridges that represent HDMI bridges,
> > rely on whatever format the HDMI logic set. Reject any output bus
> > formats that do not correspond to the requested color format.
> >
> > Non-HDMI last bridges with DRM_CONNECTOR_COLOR_FORMAT_AUTO set will end
> > up choosing the first output format that functions to make a whole
> > recursive bridge chain format selection succeed.
> >
> > Signed-off-by: Nicolas Frattaroli <nicolas.frattaroli@collabora.com>
> > ---
> > drivers/gpu/drm/drm_bridge.c | 89 +++++++++++++++++++++++++++++++++++++++++++-
> > 1 file changed, 88 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_bridge.c b/drivers/gpu/drm/drm_bridge.c
> > index ba80bebb5685..7c1516864d96 100644
> > --- a/drivers/gpu/drm/drm_bridge.c
> > +++ b/drivers/gpu/drm/drm_bridge.c
> > @@ -1150,6 +1150,47 @@ static int select_bus_fmt_recursive(struct drm_bridge *first_bridge,
> > return ret;
> > }
> >
> > +static bool __pure bus_format_is_color_fmt(u32 bus_fmt, enum drm_connector_color_format fmt)
> > +{
> > + if (fmt == DRM_CONNECTOR_COLOR_FORMAT_AUTO)
> > + return true;
> > +
> > + switch (bus_fmt) {
> > + case MEDIA_BUS_FMT_FIXED:
> > + return true;
> > + case MEDIA_BUS_FMT_RGB888_1X24:
> > + case MEDIA_BUS_FMT_RGB101010_1X30:
> > + case MEDIA_BUS_FMT_RGB121212_1X36:
> > + case MEDIA_BUS_FMT_RGB161616_1X48:
> > + return fmt == DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > + case MEDIA_BUS_FMT_YUV8_1X24:
> > + case MEDIA_BUS_FMT_YUV10_1X30:
> > + case MEDIA_BUS_FMT_YUV12_1X36:
> > + case MEDIA_BUS_FMT_YUV16_1X48:
> > + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > + case MEDIA_BUS_FMT_UYVY8_1X16:
> > + case MEDIA_BUS_FMT_VYUY8_1X16:
> > + case MEDIA_BUS_FMT_YUYV8_1X16:
> > + case MEDIA_BUS_FMT_YVYU8_1X16:
> > + case MEDIA_BUS_FMT_UYVY10_1X20:
> > + case MEDIA_BUS_FMT_YUYV10_1X20:
> > + case MEDIA_BUS_FMT_VYUY10_1X20:
> > + case MEDIA_BUS_FMT_YVYU10_1X20:
> > + case MEDIA_BUS_FMT_UYVY12_1X24:
> > + case MEDIA_BUS_FMT_VYUY12_1X24:
> > + case MEDIA_BUS_FMT_YUYV12_1X24:
> > + case MEDIA_BUS_FMT_YVYU12_1X24:
> > + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > + case MEDIA_BUS_FMT_UYYVYY8_0_5X24:
> > + case MEDIA_BUS_FMT_UYYVYY10_0_5X30:
> > + case MEDIA_BUS_FMT_UYYVYY12_0_5X36:
> > + case MEDIA_BUS_FMT_UYYVYY16_0_5X48:
> > + return fmt == DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > + default:
> > + return false;
> > + }
> > +}
> > +
> > /*
> > * This function is called by &drm_atomic_bridge_chain_check() just before
> > * calling &drm_bridge_funcs.atomic_check() on all elements of the chain.
> > @@ -1193,6 +1234,7 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> > struct drm_encoder *encoder = bridge->encoder;
> > struct drm_bridge_state *last_bridge_state;
> > unsigned int i, num_out_bus_fmts = 0;
> > + enum drm_connector_color_format fmt;
> > u32 *out_bus_fmts;
> > int ret = 0;
> >
> > @@ -1234,13 +1276,58 @@ drm_atomic_bridge_chain_select_bus_fmts(struct drm_bridge *bridge,
> > out_bus_fmts[0] = MEDIA_BUS_FMT_FIXED;
> > }
> >
> > + /*
> > + * On HDMI connectors, use the output format chosen by whatever does the
> > + * HDMI logic. For everyone else, just trust that the bridge out_bus_fmts
> > + * are sorted by preference for %DRM_CONNECTOR_COLOR_FORMAT_AUTO, as
> > + * bus_format_is_color_fmt() always returns true for AUTO.
> > + */
> > + if (last_bridge->type == DRM_MODE_CONNECTOR_HDMIA) {
>
> I still think this is misplaced (and misidentified). Consider HDMI
> bridge being routed to the DVI-D connector. The last bridge would have
> different type, but the HDMI-specific logic must still be applied. The
> bridge must use RGB444, but it must be handled in a generic way.
Thanks for the review. I was hoping that an HDMI bridge chain going to
a DVI connector would be a DRM_MODE_CONNECTOR_HDMIB thing, but apparently
not. I also don't know however how doing this in the drm bridge connector
helps us here. I guess we'd call into a drm_bridge_connector specific
function with the connector format and connector, and get an output
format in return, and said function checks that if any bridge in the
bridge connector is HDMI it uses the HDMI logic? That would conflict
with the following case from what I understand:
> Or other way around, a DVI bridge being routed through the HDMI
> connector (thinking about PandaBoard here). The combo should not go
> through the HDMI-specific color format selection although the last
> bridge in the chanin is the HDMI-A bridge.
In that case, wouldn't the recursive bridge bus format selection
take care of this? I assume the DVI bridge will only allow RGB444,
and one of the bridges that follow it is an HDMI bridge for the
HDMI connector that's physically on the board.
In such a case, if the HDMI state helpers came up with something
other than RGB444, the select_bus_fmt_recursive below would fail
as expected, since it won't be able to find an output that
satisfies the constraints given by the DVI bridge.
> I think all these cases should be handled by the connector, which knows
> if there is an OP_HDMI bridge in the chain or not.
Kind regards,
Nicolas Frattaroli
> > + drm_dbg_kms(last_bridge->dev,
> > + "HDMI bridge requests format %s\n",
> > + drm_hdmi_connector_get_output_format_name(
> > + conn_state->hdmi.output_format));
> > + switch (conn_state->hdmi.output_format) {
> > + case DRM_OUTPUT_COLOR_FORMAT_RGB444:
> > + fmt = DRM_CONNECTOR_COLOR_FORMAT_RGB444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR444:
> > + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR444;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR422:
> > + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR422;
> > + break;
> > + case DRM_OUTPUT_COLOR_FORMAT_YCBCR420:
> > + fmt = DRM_CONNECTOR_COLOR_FORMAT_YCBCR420;
> > + break;
> > + default:
> > + ret = -EINVAL;
> > + goto out_free_bus_fmts;
> > + }
> > + } else {
> > + fmt = conn_state->color_format;
> > + drm_dbg_kms(last_bridge->dev, "Non-HDMI bridge requests format %d\n", fmt);
> > + }
> > +
> > for (i = 0; i < num_out_bus_fmts; i++) {
> > + if (!bus_format_is_color_fmt(out_bus_fmts[i], fmt)) {
> > + drm_dbg_kms(last_bridge->dev,
> > + "Skipping bus format 0x%04x as it doesn't match format %d\n",
> > + out_bus_fmts[i], fmt);
> > + ret = -ENOTSUPP;
> > + continue;
> > + }
> > ret = select_bus_fmt_recursive(bridge, last_bridge, crtc_state,
> > conn_state, out_bus_fmts[i]);
> > - if (ret != -ENOTSUPP)
> > + if (ret != -ENOTSUPP) {
> > + drm_dbg_kms(last_bridge->dev,
> > + "Found bridge chain ending with bus format 0x%04x\n",
> > + out_bus_fmts[i]);
> > break;
> > + }
> > }
> >
> > +out_free_bus_fmts:
> > kfree(out_bus_fmts);
> >
> > return ret;
> >
>
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
* Re: [PATCH] gpio: rockchip: convert to dynamic GPIO base allocation
From: Steven Price @ 2026-04-10 11:41 UTC (permalink / raw)
To: Linus Walleij, Jonas Karlman
Cc: Shawn Lin, Bartosz Golaszewski, Heiko Stuebner, linux-gpio,
linux-rockchip, ye.zhang
In-Reply-To: <CAD++jLmhkZhWzjV9b6r9P4oZq=4dqVEVV7mwwE_WWRgRXbq3AQ@mail.gmail.com>
On 09/04/2026 23:25, Linus Walleij wrote:
> On Thu, Apr 9, 2026 at 9:09 PM Jonas Karlman <jonas@kwiboo.se> wrote:
>
>> This patch is causing boot issues on my Rock Pi 4 (RK3399) board using
>> next-20260409 kernel where this patch has been applied as c8079f83e0bf.
I had similar problems with my Firefly RK3288.
>>
>> [ 0.082771] rockchip-gpio ff720000.gpio: probed /pinctrl/gpio@ff720000
>> [ 0.083531] rockchip-gpio ff730000.gpio: probed /pinctrl/gpio@ff730000
>> [ 0.084110] rockchip-gpio ff780000.gpio: probed /pinctrl/gpio@ff780000
>> [ 0.084746] rockchip-gpio ff788000.gpio: probed /pinctrl/gpio@ff788000
>> [ 0.085389] rockchip-gpio ff790000.gpio: probed /pinctrl/gpio@ff790000
>> --
>> [ 0.212208] rockchip-pinctrl pinctrl: pin 637 is not registered so it cannot be requested
>> [ 0.212271] rockchip-pinctrl pinctrl: error -EINVAL: pin-637 (gpio3:637)
>> [ 0.212344] leds-gpio leds: error -EINVAL: Failed to get GPIO '/leds/led-0'
>> [ 0.212389] leds-gpio leds: probe with driver leds-gpio failed with error -22
>
> I think this may be because the rk3399 is missing gpio-ranges despite it is a
> new platform and should have had its gpio-ranges defined in
> arch/arm64/boot/dts/rockchip/rk3399-base.dtsi ...
>
> A bunch of these rockchips seem to have this problem despite the
> code in pinctrl-rockchip.c that says:
>
> /*
> * For DeviceTree-supported systems, the gpio core checks the
> * pinctrl's device node for the "gpio-ranges" property.
> * If it is present, it takes care of adding the pin ranges
> * for the driver. In this case the driver can skip ahead.
> *
> * In order to remain compatible with older, existing DeviceTree
> * files which don't set the "gpio-ranges" property or systems that
> * utilize ACPI the driver has to call gpiochip_add_pin_range().
> */
> if (!of_property_present(bank->of_node, "gpio-ranges")) {
> struct device_node *pctlnp = of_get_parent(bank->of_node);
> struct pinctrl_dev *pctldev = NULL;
>
> if (!pctlnp)
> return -ENODATA;
>
> pctldev = of_pinctrl_get(pctlnp);
> of_node_put(pctlnp);
> if (!pctldev)
> return -ENODEV;
>
> ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
> gc->base, gc->ngpio);
> if (ret) {
> dev_err(bank->dev, "Failed to add pin range\n");
> goto fail;
> }
> }
>
> Notice dereference of gpiolib internal gc-base here.
>
> ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
> gc->base, gc->ngpio);
>
> arguments are gpipchip, pinctontrol device name,
> gpio offset, pin offset, number of pins.
>
> GPIO offset always 0?? Passing GPIO offset as pin offset??
>
> This is probably just working because of luck that 0,0 is passed.
>
> This should probably rather be something like:
>
> ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), gc->base,
> bank->bank_num * bank->nr_pins, gc->ngpio);
This however didn't work. Instead ChatGPT was able to suggest:
ret = gpiochip_add_pin_range(gc, dev_name(pctldev->dev), 0,
bank->pin_base, gc->ngpio);
which works for me. I won't repeat the waffle from ChatGPT because I
honestly don't understand this area of the kernel (and you can ask an AI
yourself if you want to). I'm not subscribed, so please CC me if you
want me to try any alternative fixes.
Thanks,
Steve
> Here we put the assigned (by gpiolib) gc->base in the right place, then
> bank->bank_num should be 0,1,2... and bank->nr_pins always 32 (I think).
>
> Jonas can you test this oneliner change? I can send a proper patch
> if it helps.
>
> If this works the DTS files can (SHOULD) be fixed with proper ranges later.
>
> It would be nice if we could augment the rockchip pinctrl DT schema to
> make gpio-ranges mandatory on new SoCs.
>
> Yours,
> Linus Walleij
>
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox