* Re: [PATCH v3 4/7] drm/rcar-du: dsi: Support DSC in the pipeline
From: Laurent Pinchart @ 2026-06-12 15:53 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Geert Uytterhoeven, Michael Turquette, Stephen Boyd,
Andrzej Hajda, Neil Armstrong, Robert Foss, Jonas Karlman,
Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Kieran Bingham, Philipp Zabel, linux-renesas-soc, linux-clk,
linux-kernel, dri-devel, devicetree
In-Reply-To: <11f27d38-0224-4fce-a975-7c3f7d8d1d38@ideasonboard.com>
On Fri, Jun 12, 2026 at 02:56:11PM +0300, Tomi Valkeinen wrote:
> On 11/06/2026 03:03, Laurent Pinchart wrote:
> > On Fri, May 15, 2026 at 12:09:29PM +0300, Tomi Valkeinen wrote:
> >> Enabling DSI clocks on rcar-du needs some tricks as the DU dot clock is
> >> provided by the DSI. Thus, we call rcar_mipi_dsi_pclk_enable() from the
> >> crtc, when enabling the crtc.
> >>
> >> With DSC (added in upcoming patch) in the pipeline, between the DU and
> >> the DSI, the above call path is broken as the crtc tries to call
> >> rcar_mipi_dsi_pclk_enable() on the DSC.
> >>
> >> Adjust the rcar_mipi_dsi_pclk_enable() so that it detects the DSC, and
> >> in that case gets the next bridge from the DSC, which is the DSI.
> >>
> >> Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> >> ---
> >> drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c | 36 +++++++++++++++++++++++--
> >> 1 file changed, 34 insertions(+), 2 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> index 4ef2e3c129ed..085e229bcb0b 100644
> >> --- a/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> +++ b/drivers/gpu/drm/renesas/rcar-du/rcar_mipi_dsi.c
> >> @@ -88,6 +88,8 @@ struct dsi_setup_info {
> >> const struct dsi_clk_config *clkset;
> >> };
> >>
> >> +static const struct drm_bridge_funcs rcar_mipi_dsi_bridge_ops;
> >> +
> >> static inline struct rcar_mipi_dsi *
> >> bridge_to_rcar_mipi_dsi(struct drm_bridge *bridge)
> >> {
> >> @@ -844,15 +846,39 @@ static void rcar_mipi_dsi_atomic_disable(struct drm_bridge *bridge,
> >> rcar_mipi_dsi_stop_video(dsi);
> >> }
> >>
> >> +/*
> >> + * We need to skip the DSC bridge when we have DSC in between the DU and
> >> + * the DSI. We detect the DSI bridge via bridge->funcs, and assume the
> >> + * next_bridge is the DSI bridge. If this is not the case, the DT data
> >> + * is wrong (so it shouldn't really happen).
> >> + */
> >> +static struct drm_bridge *
> >> +rcar_mipi_dsi_resolve_bridge(struct drm_bridge *bridge)
> >> +{
> >> + if (bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> >> + bridge = bridge->next_bridge;
> >> +
> >> + if (!bridge || bridge->funcs != &rcar_mipi_dsi_bridge_ops)
> >> + return NULL;
> >> +
> >> + return bridge;
> >> +}
> >
> > Hmmmm... It's quite a bit of a hack. It would be nicer to do this in
> > rcar_du_crtc.c instead, where we cache the dsi bridge pointer. The
>
> It's actually cached in rcar_du_encoder.c, but used in rcar_du_crtc.c.
>
> If I understand right, you'd like to do the DSC detection in
> rcar_du_crtc, and skip the DSC, if needed, before calling
> rcar_mipi_dsi_pclk_enable()?
That would be the idea, yes. Knowledge that there's a DSC in the
pipeline would be in the DU driver, not the DSI driver. I think it would
be better, as the DU driver is the one that should have an overall view
of the display pipeline.
> > question is how to then identify the right bridge, as we won't have
> > access to rcar_mipi_dsi_bridge_ops. Should this driver set the bridge
> > type field to DRM_MODE_CONNECTOR_DSI ?
>
> I'm not sure how that would help. Or, I can, as the dsi driver does not
> set the bridge type, so only DSC would set it. But isn't that even more
> hacky?
>
> Or did you rather mean that the DSI driver would set the bridge type,
> and DSC would not? We can then do:
>
> if (bridge->type != DRM_MODE_CONNECTOR_DSI)
> bridge = bridge->next_bridge;
Yes that's what I meant.
> in the crtc driver. This works. It's still a bit hacky, but I think the
> chances of the code getting it wrong are quite low. If the output port
> is RCAR_DU_OUTPUT_DSIx, then the next bridge must be rcar-dsi or
> rcar-dsc, so it's all under our control. Also, it's less code than this
> patch, so I'll go with that.
Thanks.
--
Regards,
Laurent Pinchart
^ permalink raw reply
* Re: [PATCH v4 07/16] phy: rockchip: usbdp: Support single-lane DP
From: Sebastian Reichel @ 2026-06-12 15:57 UTC (permalink / raw)
To: Neil Armstrong
Cc: Vinod Koul, Heiko Stuebner, Frank Wang, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Andy Yan, Dmitry Baryshkov,
Yubing Zhang, Alexey Charkov, linux-phy, linux-arm-kernel,
linux-rockchip, linux-kernel, kernel, devicetree
In-Reply-To: <f29df43b-111d-471b-8579-0196596fc32b@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 2156 bytes --]
Hi,
On Wed, May 06, 2026 at 04:53:07PM +0200, Neil Armstrong wrote:
> > @@ -537,6 +538,13 @@ static void rk_udphy_usb_bvalid_enable(struct rk_udphy *udphy, u8 enable)
> > * <0 1> dpln0 dpln1 usbrx usbtx
> > * <2 3> usbrx usbtx dpln0 dpln1
> > * ---------------------------------------------------------------------------
> > + * if 1 lane for dp function, 2 lane for usb function, define rockchip,dp-lane-mux = <x>;
> > + * sample as follow:
> > + * ---------------------------------------------------------------------------
> > + * B11-B10 A2-A3 A11-A10 B2-B3
> > + * rockchip,dp-lane-mux ln0(tx/rx) ln1(tx) ln2(tx/rx) ln3(tx)
> > + * <0> dpln0 \ usbrx usbtx
> > + * ---------------------------------------------------------------------------
> > */
> > static void rk_udphy_dplane_select(struct rk_udphy *udphy)
> > @@ -544,18 +552,18 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
> > const struct rk_udphy_cfg *cfg = udphy->cfgs;
> > u32 value = 0;
> > - switch (udphy->mode) {
> > - case UDPHY_MODE_DP:
> > - value |= 2 << udphy->dp_lane_sel[2] * 2;
> > + switch (udphy->dp_lanes) {
> > + case 4:
> > value |= 3 << udphy->dp_lane_sel[3] * 2;
> > + value |= 2 << udphy->dp_lane_sel[2] * 2;
> > fallthrough;
> > - case UDPHY_MODE_DP_USB:
> > - value |= 0 << udphy->dp_lane_sel[0] * 2;
> > + case 2:
> > value |= 1 << udphy->dp_lane_sel[1] * 2;
> > - break;
> > + fallthrough;
> > - case UDPHY_MODE_USB:
> > + case 1:
> > + value |= 0 << udphy->dp_lane_sel[0] * 2;
>
> What's the point of keeping this no-op calculation ?
This function is cleaned up in a later patch to no longer have the
switch/case at all ("Cleanup DP lane selection function"). I kept
the no-op calculation here, since it IMHO makes it easier to understand
the cleanup patch and will be optimized away by the compiler anyways.
(I will send out a new patch series in a jiffy)
Greetings,
-- Sebastian
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v2 3/7] ASoC: dt-bindings: loongson,ls-audio-card: Use common sound card
From: Rob Herring (Arm) @ 2026-06-12 15:58 UTC (permalink / raw)
To: Binbin Zhou
Cc: Liam Girdwood, linux-sound, Huacai Chen, Takashi Iwai,
Huacai Chen, devicetree, Binbin Zhou, Krzysztof Kozlowski,
Mark Brown, Jaroslav Kysela, loongarch, Conor Dooley, Xuerui Wang
In-Reply-To: <bbbcfd66b3b98713315f1af374c8da1065c8db68.1780538113.git.zhoubinbin@loongson.cn>
On Thu, 04 Jun 2026 10:11:23 +0800, Binbin Zhou wrote:
> Reference the common sound card properties. This allows removing the
> `model` property and directly using the common `audio-routing` property
> later on.
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> .../bindings/sound/loongson,ls-audio-card.yaml | 11 +++++------
> 1 file changed, 5 insertions(+), 6 deletions(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH v2 6/7] ASoC: dt-bindings: loongson,ls-audio-card: Add ATK-DL2K0300B compatible
From: Rob Herring @ 2026-06-12 16:01 UTC (permalink / raw)
To: Binbin Zhou
Cc: Binbin Zhou, Huacai Chen, Krzysztof Kozlowski, Conor Dooley,
Liam Girdwood, Mark Brown, Jaroslav Kysela, Takashi Iwai,
Huacai Chen, Xuerui Wang, loongarch, devicetree, linux-sound
In-Reply-To: <c03b86a9318cffe69ecf8d5c14543fc5948ab2c7.1780538113.git.zhoubinbin@loongson.cn>
On Thu, Jun 04, 2026 at 10:11:46AM +0800, Binbin Zhou wrote:
> Add new compatible for the ATK-DL2K0300B development board based on
> Loongson-2K0300.
>
> Unlike others, this board features GPIO-controlled headphone detection,
> headphone mute, and speaker enable.
>
> Signed-off-by: Binbin Zhou <zhoubinbin@loongson.cn>
> ---
> .../sound/loongson,ls-audio-card.yaml | 37 +++++++++++++++++++
> 1 file changed, 37 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> index 8c214e5d04b1..e9b248e8246c 100644
> --- a/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> +++ b/Documentation/devicetree/bindings/sound/loongson,ls-audio-card.yaml
> @@ -23,6 +23,7 @@ properties:
> enum:
> - loongson,ls-audio-card # Loongson-2K1000/Loongson-2K2000/LS7A
> - loongson,ls2k0300-forever-pi-audio-card # CTCISZ Forever Pi
> + - loongson,ls2k0300-dl2k0300b-audio-card # ATK-DL2K0300B
>
> mclk-fs:
> $ref: simple-card.yaml#/definitions/mclk-fs
> @@ -47,6 +48,18 @@ properties:
> required:
> - sound-dai
>
> + loongson,spkr-en-gpios:
> + maxItems: 1
> + description: The GPIO that enables the speakers
> +
> + loongson,hp-mute-gpios:
> + maxItems: 1
> + description: The GPIO that mutes the headphones
> +
> + loongson,hp-det-gpios:
> + maxItems: 1
> + description: The GPIO that detect headphones are plugged in
We have standard properties for at least this one. If you see multiple
$vendor,foo-bar properties, don't add yet another vendor foo-bar
property.
Rob
^ permalink raw reply
* Re: [PATCH 2/4] dt-bindings: arm: qcom: Add Lenovo Yoga Slim 7x Gen11
From: Rob Herring @ 2026-06-12 16:05 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Abel Vesa, Konrad Dybcio, rob.clark, Neil Armstrong,
Jessica Zhang, David Airlie, Simona Vetter, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, Krzysztof Kozlowski,
Conor Dooley, Douglas Anderson, Bjorn Andersson, Konrad Dybcio,
dri-devel, devicetree, linux-kernel, linux-arm-msm
In-Reply-To: <ac191a18-bcb4-4fa5-a179-b72a6ac928cb@kernel.org>
On Thu, Jun 11, 2026 at 03:48:15PM +0200, Krzysztof Kozlowski wrote:
> On 10/06/2026 15:31, Abel Vesa wrote:
> >>>>>> @@ -68,6 +68,7 @@ properties:
> >>>>>>
> >>>>>> - items:
> >>>>>> - enum:
> >>>>>> + - lenovo,yoga-slim7x-gen11
> >>>>>
> >>>>> I imagine you might want different panel variants, just like T14s has
> >>>>> LCD and OLED?
> >>>>
> >>>> I expect this will be the case.
> >>>
> >>> Then better to prepare for this now, otherwise later you need to change
> >>> bindings. If unsure what other variants are, then at least make this
> >>> compatible panel-specific, e.g. lenovo,yoga-slim7x-gen11-oled-foo-bar.
> >>
> >> I took another look at psref [1] and there's only OLED SKUs (today?).
> >> There are however, two different resolutions available and both can be
> >> touch/notouch.
> >
> > If the other SKU doesn't have touch, then you might as well mark now this
> > one with touch suffix or something like that.
>
>
> If you decide not to have any changes (new compatibles), then at least
> please document the above reasoning in commit msg.
If the difference is just the panel or touch, then isn't that captured
by the panel and/or touch nodes?
OTOH, if it's different firmware builds and generally treated as 2
different devices, then different top-level compatible is probably fine.
Rob
^ permalink raw reply
* Re: [PATCH v2 2/5] dt-bindings: display: bridge: Document Renesas R-Car V4H DSC bindings
From: Conor Dooley @ 2026-06-12 16:09 UTC (permalink / raw)
To: Tomi Valkeinen
Cc: Laurent Pinchart, Geert Uytterhoeven, Michael Turquette,
Stephen Boyd, Andrzej Hajda, Neil Armstrong, Robert Foss,
Jonas Karlman, Jernej Skrabec, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Magnus Damm, Marek Vasut,
Laurent Pinchart, Kieran Bingham, Philipp Zabel,
linux-renesas-soc, linux-clk, linux-kernel, dri-devel, devicetree
In-Reply-To: <81f89aa1-84d8-44e1-813b-2bbcafe3687e@ideasonboard.com>
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
On Fri, Jun 12, 2026 at 01:43:44PM +0300, Tomi Valkeinen wrote:
> Hi,
>
> On 15/05/2026 20:32, Conor Dooley wrote:
> > On Fri, May 15, 2026 at 10:56:15AM +0300, Tomi Valkeinen wrote:
> > > From: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > >
> > > The Renesas DSC Display Stream Compression is a bridge embedded in the
> > > Renesas R-Car V4H SoC. The bridge performs VESA DSC encoding of up to
> > > 8k or 400 Mpixel/s .
> > >
> > > Signed-off-by: Marek Vasut <marek.vasut+renesas@mailbox.org>
> > > [tomi.valkeinen: fix the example]
> > > Signed-off-by: Tomi Valkeinen <tomi.valkeinen+renesas@ideasonboard.com>
> > > ---
> > > .../bindings/display/bridge/renesas,dsc.yaml | 96 ++++++++++++++++++++++
> > > 1 file changed, 96 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
> > > new file mode 100644
> > > index 000000000000..2918d592732b
> > > --- /dev/null
> > > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,dsc.yaml
> >
> > Filename matching the compatible please.
>
> All the other Documentation/devicetree/bindings/display/bridge/renesas,*
> files follow the same style, where the file name is in a generic format, but
> the actual compat strings are per SoC (and no generic compat string).
No idea why it's like that currently, but filename matching compatible
is the policy.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: iio: adc: Add TI ADS1220
From: David Lechner @ 2026-06-12 16:10 UTC (permalink / raw)
To: Nguyen Minh Tien, Jonathan Cameron
Cc: linux-iio, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nuno Sá, Andy Shevchenko, linux-kernel
In-Reply-To: <20260610151342.44274-2-zizuzacker@gmail.com>
On 6/10/26 10:13 AM, Nguyen Minh Tien wrote:
> The ADS1220 is a 24-bit, 2-kSPS, 4-channel delta-sigma ADC from Texas
> Instruments with an SPI (mode 1) interface, a programmable gain amplifier,
> an internal 2.048V reference and a dedicated DRDY data-ready output.
>
> Add a device tree binding describing the SPI device and its per-input
> channel child nodes (single-ended AINx or the multiplexer's differential
> pairs), the optional external/AVDD reference selection and the DRDY
> interrupt.
FYI, I have a similar chip I am working on (at least in terms of wiring)
that I plan to submit probably next week. I think the DT bindings will
be quite similar, so you might want to wait and see how the review goes
for that (TI ADS122C14).
It could be similar enough that you could add this chip to what I am
doing rather than having separate files.
>
> Signed-off-by: Nguyen Minh Tien <zizuzacker@gmail.com>
> ---
> .../bindings/iio/adc/ti,ads1220.yaml | 146 ++++++++++++++++++
> 1 file changed, 146 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
>
> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
> new file mode 100644
> index 000000000..1fedffc2a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads1220.yaml
> @@ -0,0 +1,146 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/iio/adc/ti,ads1220.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Texas Instruments ADS1220 ADC
> +
> +maintainers:
> + - Nguyen Minh Tien <zizuzacker@gmail.com>
> +
> +description:
> + The TI ADS1220 is a precision 24-bit, 2-kSPS, delta-sigma ADC with an SPI
> + (mode 1) interface. It provides two differential or four single-ended inputs
> + through a multiplexer, a programmable gain amplifier (gain 1 to 128), an
> + internal 2.048V reference and oscillator, two programmable excitation current
> + sources and a 50/60Hz rejection filter. A dedicated DRDY output signals when a
> + new conversion result is available.
> +
> +properties:
> + compatible:
> + const: ti,ads1220
> +
> + reg:
> + maxItems: 1
> +
> + spi-cpha: true
> +
> + interrupts:
> + description: DRDY pin, signals that a new conversion result is ready.
> + maxItems: 1
There are actually 2 DRDY pins, so we need some way to describe which one
is wired up.
So...
interrupt-names:
items:
- enum: [drdy, dout-drdy]
And we have found that when dout-drdy is used, some interrupt controllers
can't handle it correctly and we also need a dout-drdy-gpios to read the pin.
> +
> + avdd-supply:
> + description: Analog power supply (AVDD/AVSS).
> +
> + dvdd-supply:
> + description: Digital power supply (DVDD/DGND).
> +
> + vref-supply:
> + description:
> + External reference voltage (REFP0/REFN0). If omitted, the internal
> + 2.048V reference is used unless ti,vref-avdd is set.
If the pins are REFx0, then let's call it ref0-supply.
There is also a ref1-supply (alternate REFP1/REFN1 function of AIN1/AIN3) so that
needs to be included as well.
Also, in the case when the sensor is an RDT, we only care about the resistor
across these inputs rather than the voltage. So in the one I am working on,
I added extra properties for that.
> +
> + ti,vref-avdd:
> + type: boolean
> + description:
> + Use the analog supply (AVDD/AVSS) as the conversion reference instead of
> + the internal 2.048V reference. Suited to ratiometric single-supply
> + measurements (for example a potentiometer wired across AVDD), giving a
> + full 0..AVDD input range without an external reference. Ignored when
> + vref-supply is present.
> +
On the chip I am working on, we want to select the reference source per-channel
rather than globally, so might want to do the same here.
There is also an optional external clock, so we need clocks property.
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 0
> +
> + "#io-channel-cells":
> + const: 1
> +
> +required:
> + - compatible
> + - reg
> + - "#address-cells"
> + - "#size-cells"
> + - avdd-supply
> + - dvdd-supply
> +
> +patternProperties:
> + "^channel@[0-6]$":
> + $ref: adc.yaml
> + type: object
> + description: Represents one ADC input configuration (channel).
> +
> + properties:
> + reg:
> + minimum: 0
> + maximum: 6
I would add a comment explaining that the limit here is arbitrary. Also wouldn't
hurt to make it a bit bigger. Technically, someone could have every possible
combination of all inputs (16 differential + 4 single-ended).
> +
> + diff-channels:
> + description:
> + Differential input pair routable by the ADS1220 multiplexer.
> + oneOf:
> + - items: [const: 0, const: 1]
> + - items: [const: 0, const: 2]
> + - items: [const: 0, const: 3]
> + - items: [const: 1, const: 2]
> + - items: [const: 1, const: 3]
> + - items: [const: 2, const: 3]
> + - items: [const: 1, const: 0]
> + - items: [const: 3, const: 2]
Sometimes, the same channel may be used as both positive and negative
for a diagnostic, so I would just allow any combination instead of
listing specific combinations.
> +
> + single-channel:
> + description:
> + Single-ended input channel AINx measured against AVSS.
> + minimum: 0
> + maximum: 3
On the chip I am working on, I also added properties here for required
current outputs for the RDT case.
And as mentioned above, a property here to select the reference voltage
that this specific channel uses It could be Internal, REFx0, REFx1 or AVDD,
so a boolean flag is not enough.
> +
> + oneOf:
> + - required: [diff-channels]
> + - required: [single-channel]
> +
> + required:
> + - reg
> +
> + unevaluatedProperties: false
> +
> +allOf:
> + - $ref: /schemas/spi/spi-peripheral-props.yaml#
> +
> +unevaluatedProperties: false
> +
> +examples:
> + - |
> + #include <dt-bindings/interrupt-controller/irq.h>
> +
> + spi {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + adc@0 {
> + compatible = "ti,ads1220";
> + reg = <0>;
> + spi-max-frequency = <2500000>;
> + spi-cpha;
> + interrupt-parent = <&pio>;
> + interrupts = <4 4 IRQ_TYPE_EDGE_FALLING>;
> + avdd-supply = <®_vcc3v3>;
> + dvdd-supply = <®_vcc3v3>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> + #io-channel-cells = <1>;
> +
> + channel@0 {
> + reg = <0>;
> + single-channel = <0>;
> + };
> +
> + channel@1 {
> + reg = <1>;
> + diff-channels = <0 1>;
> + };
> + };
> + };
> +...
^ permalink raw reply
* [PATCH 1/5] dt-binding: ARM: samsung: Add Samsung Exynos8855
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <20260612163020.411761-1-alim.akhtar@samsung.com>
Add Samsung Exynos8855 smdk board to documentation
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
.../devicetree/bindings/arm/samsung/samsung-boards.yaml | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
index 753b3ba1b607..273464400477 100644
--- a/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
+++ b/Documentation/devicetree/bindings/arm/samsung/samsung-boards.yaml
@@ -235,6 +235,12 @@ properties:
- winlink,e850-96 # WinLink E850-96
- const: samsung,exynos850
+ - description: Exynos8855 based boards
+ items:
+ - enum:
+ - samsung,exynos8855-smdk # Samsung SMDK
+ - const: samsung,exynos8855
+
- description: Exynos8895 based boards
items:
- enum:
--
2.34.1
^ permalink raw reply related
* [PATCH 0/5] Add minimal Exynos8855 SoC support
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <CGME20260612161128epcas5p2fe6ebf4b1a7b3ad1794804768180cbdd@epcas5p2.samsung.com>
This series adds initial support for the Exynos8855 SoC and also
initial SMDK board support.
Exynos8855 has octa-core CPUs, a combination of Cortex-A720 and Cortex-A520,
arranged in 3 clusters. And other peripheral for mobile application.
This initial support consists of CPUs, pinctrl and related nodes
needed for initial kernel boot.
With these patches, kernel can boot using initramfs till file system mounts.
More platform support will be added in near future, clock driver to go next.
Known issue: uart driver probe fails because of clk being not available yet.
Alim Akhtar (5):
dt-binding: ARM: samsung: Add Samsung Exynos8855
dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
pinctrl: samsung: Add Exynos8855 pinctrl configuration
arm64: dts: exynos: add initial support for Samsung Exynos8855 smdk
MAINTAINERS: Add entry for Samsung Exynos8855 SoC
.../bindings/arm/samsung/samsung-boards.yaml | 6 +
.../bindings/pinctrl/samsung,pinctrl.yaml | 1 +
MAINTAINERS | 7 +
arch/arm64/boot/dts/exynos/Makefile | 1 +
.../boot/dts/exynos/exynos8855-pinctrl.dtsi | 581 ++++++++++++++++++
.../arm64/boot/dts/exynos/exynos8855-smdk.dts | 37 ++
arch/arm64/boot/dts/exynos/exynos8855.dtsi | 214 +++++++
.../pinctrl/samsung/pinctrl-exynos-arm64.c | 124 ++++
drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
10 files changed, 974 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855.dtsi
base-commit: b99ae45861eccff1e1d8c7b05a13650be805d437
--
2.34.1
^ permalink raw reply
* [PATCH 2/5] dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <20260612163020.411761-1-alim.akhtar@samsung.com>
Document pin controller support on Exynos8855 SoC.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
index 7b006009ca0e..c4773701c92e 100644
--- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
@@ -53,6 +53,7 @@ properties:
- samsung,exynos7870-pinctrl
- samsung,exynos7885-pinctrl
- samsung,exynos850-pinctrl
+ - samsung,exynos8855-pinctrl
- samsung,exynos8890-pinctrl
- samsung,exynos8895-pinctrl
- samsung,exynos9610-pinctrl
--
2.34.1
^ permalink raw reply related
* [PATCH 3/5] pinctrl: samsung: Add Exynos8855 pinctrl configuration
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <20260612163020.411761-1-alim.akhtar@samsung.com>
Add pinctrl configuration for Exynos8855. The bank type
macros are reused from Exynos850 SoC.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
.../pinctrl/samsung/pinctrl-exynos-arm64.c | 124 ++++++++++++++++++
drivers/pinctrl/samsung/pinctrl-samsung.c | 2 +
drivers/pinctrl/samsung/pinctrl-samsung.h | 1 +
3 files changed, 127 insertions(+)
diff --git a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
index fe9f92cb037e..ba2a11f8e19d 100644
--- a/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
+++ b/drivers/pinctrl/samsung/pinctrl-exynos-arm64.c
@@ -943,6 +943,130 @@ const struct samsung_pinctrl_of_match_data exynos850_of_data __initconst = {
.num_ctrl = ARRAY_SIZE(exynos850_pin_ctrl),
};
+/* pin banks of exynos8855 pin-controller 0 (ALIVE) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks0[] __initconst = {
+ /* Must start with EINTG banks, ordered by EINT group number. */
+ EXYNOS850_PIN_BANK_EINTW(8, 0x000, "gpa0", 0x00),
+ EXYNOS850_PIN_BANK_EINTW(4, 0x020, "gpa1", 0x04),
+ EXYNOS850_PIN_BANK_EINTN(3, 0x040, "gpq0"),
+ EXYNOS850_PIN_BANK_EINTN(2, 0x060, "gpq1"),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x080, "gpc0", 0x10),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x0a0, "gpc1", 0x14),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x0c0, "gpc2", 0x18),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x0e0, "gpc3", 0x1c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x100, "gpc4", 0x20),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x120, "gpc5", 0x24),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x140, "gpc6", 0x28),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x160, "gpc7", 0x2c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x180, "gpc8", 0x30),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1a0, "gpc9", 0x34),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1c0, "gpc10", 0x38),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1e0, "gpc11", 0x3c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x200, "gpc12", 0x40),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x220, "gpc13", 0x44),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x240, "gpc14", 0x48),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x260, "gpj0", 0x4c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x280, "gpj1", 0x50),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x2a0, "gpj2", 0x54),
+};
+
+/* pin banks of exynos8855 pin-controller 1 (CMGP) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks1[] __initconst = {
+ EXYNOS850_PIN_BANK_EINTW(1, 0x00, "gpm0", 0x00),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x20, "gpm1", 0x04),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x40, "gpm2", 0x08),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x60, "gpm3", 0x0c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x80, "gpm4", 0x10),
+ EXYNOS850_PIN_BANK_EINTW(1, 0xa0, "gpm5", 0x14),
+ EXYNOS850_PIN_BANK_EINTW(1, 0xc0, "gpm6", 0x18),
+ EXYNOS850_PIN_BANK_EINTW(1, 0xe0, "gpm7", 0x1c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x100, "gpm8", 0x20),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x120, "gpm9", 0x24),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x140, "gpm10", 0x28),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x160, "gpm11", 0x2c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x180, "gpm12", 0x30),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1a0, "gpm13", 0x34),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1c0, "gpm14", 0x38),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x1e0, "gpm15", 0x3c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x200, "gpm16", 0x40),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x220, "gpm17", 0x44),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x240, "gpm18", 0x48),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x260, "gpm19", 0x4c),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x280, "gpm20", 0x50),
+ EXYNOS850_PIN_BANK_EINTW(1, 0x2a0, "gpm21", 0x54),
+};
+
+
+/* pin banks of exynos8855 pin-controller 2 (HSI UFS) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks2[] __initconst = {
+ EXYNOS850_PIN_BANK_EINTG(2, 0x0, "gpf3", 0x00),
+};
+
+/* pin banks of exynos8855 pin-controller 3 (PERIC) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks3[] __initconst = {
+ EXYNOS850_PIN_BANK_EINTG(8, 0x0, "gpp0", 0x00),
+ EXYNOS850_PIN_BANK_EINTG(8, 0x20, "gpp1", 0x04),
+ EXYNOS850_PIN_BANK_EINTG(6, 0x40, "gpp2", 0x08),
+ EXYNOS850_PIN_BANK_EINTG(4, 0x60, "gpg0", 0x0c),
+ EXYNOS850_PIN_BANK_EINTG(3, 0x80, "gpg1", 0x10),
+ EXYNOS850_PIN_BANK_EINTG(6, 0xa0, "gpb0", 0x14),
+ EXYNOS850_PIN_BANK_EINTG(4, 0xc0, "gpb1", 0x18),
+};
+
+/* pin banks of exynos8855 pin-controller 4 (PERICMMC) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks4[] __initconst = {
+ EXYNOS850_PIN_BANK_EINTG(7, 0x0, "gpf2", 0x00),
+};
+
+/* pin banks of exynos8855 pin-controller 5 (USI) */
+static const struct samsung_pin_bank_data exynos8855_pin_banks5[] __initconst = {
+ EXYNOS850_PIN_BANK_EINTG(8, 0x00, "gpp3", 0x00),
+ EXYNOS850_PIN_BANK_EINTG(2, 0x20, "gpp4", 0x04),
+ EXYNOS850_PIN_BANK_EINTG(2, 0x40, "gpg2", 0x08),
+ EXYNOS850_PIN_BANK_EINTG(1, 0x60, "gpg3", 0x0c),
+};
+
+static const struct samsung_pin_ctrl exynos8855_pin_ctrl[] __initconst = {
+ {
+ /* pin-controller instance 0 ALIVE data */
+ .pin_banks = exynos8855_pin_banks0,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks0),
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 1 CMGP data */
+ .pin_banks = exynos8855_pin_banks1,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks1),
+ .eint_wkup_init = exynos_eint_wkup_init,
+ .eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 2 HSI UFS data */
+ .pin_banks = exynos8855_pin_banks2,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks2),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 3 PERIC data */
+ .pin_banks = exynos8855_pin_banks3,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks3),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 4 PERICMMC data */
+ .pin_banks = exynos8855_pin_banks4,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks4),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ }, {
+ /* pin-controller instance 5 USI data */
+ .pin_banks = exynos8855_pin_banks5,
+ .nr_banks = ARRAY_SIZE(exynos8855_pin_banks5),
+ .eint_gpio_init = exynos_eint_gpio_init,
+ },
+};
+
+const struct samsung_pinctrl_of_match_data exynos8855_of_data __initconst = {
+ .ctrl = exynos8855_pin_ctrl,
+ .num_ctrl = ARRAY_SIZE(exynos8855_pin_ctrl),
+};
+
/* pin banks of exynos990 pin-controller 0 (ALIVE) */
static struct samsung_pin_bank_data exynos990_pin_banks0[] = {
/* Must start with EINTG banks, ordered by EINT group number. */
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.c b/drivers/pinctrl/samsung/pinctrl-samsung.c
index 5ac6f6b02327..5ecc9ed4c44d 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.c
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.c
@@ -1500,6 +1500,8 @@ static const struct of_device_id samsung_pinctrl_dt_match[] = {
.data = &exynos7885_of_data },
{ .compatible = "samsung,exynos850-pinctrl",
.data = &exynos850_of_data },
+ { .compatible = "samsung,exynos8855-pinctrl",
+ .data = &exynos8855_of_data },
{ .compatible = "samsung,exynos8890-pinctrl",
.data = &exynos8890_of_data },
{ .compatible = "samsung,exynos8895-pinctrl",
diff --git a/drivers/pinctrl/samsung/pinctrl-samsung.h b/drivers/pinctrl/samsung/pinctrl-samsung.h
index 937600430a6e..bb02fb49b2af 100644
--- a/drivers/pinctrl/samsung/pinctrl-samsung.h
+++ b/drivers/pinctrl/samsung/pinctrl-samsung.h
@@ -396,6 +396,7 @@ extern const struct samsung_pinctrl_of_match_data exynos7_of_data;
extern const struct samsung_pinctrl_of_match_data exynos7870_of_data;
extern const struct samsung_pinctrl_of_match_data exynos7885_of_data;
extern const struct samsung_pinctrl_of_match_data exynos850_of_data;
+extern const struct samsung_pinctrl_of_match_data exynos8855_of_data;
extern const struct samsung_pinctrl_of_match_data exynos8890_of_data;
extern const struct samsung_pinctrl_of_match_data exynos8895_of_data;
extern const struct samsung_pinctrl_of_match_data exynos9610_of_data;
--
2.34.1
^ permalink raw reply related
* [PATCH 5/5] MAINTAINERS: Add entry for Samsung Exynos8855 SoC
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <20260612163020.411761-1-alim.akhtar@samsung.com>
Add maintainers entry for the Samsung Exynos8855 SoC based platforms
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 49a10f0ceb07..fb9b24220258 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -23914,6 +23914,13 @@ F: arch/arm64/boot/dts/exynos/exynos850*
F: drivers/clk/samsung/clk-exynos850.c
F: include/dt-bindings/clock/exynos850.h
+SAMSUNG EXYNOS8855 SoC SUPPORT
+M: Alim Akhtar <alim.akhtar@samsung.com>
+L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
+L: linux-samsung-soc@vger.kernel.org
+S: Maintained
+F: arch/arm64/boot/dts/exynos/exynos8855*
+
SAMSUNG EXYNOS ACPM MAILBOX PROTOCOL
M: Tudor Ambarus <tudor.ambarus@linaro.org>
L: linux-kernel@vger.kernel.org
--
2.34.1
^ permalink raw reply related
* [PATCH 4/5] arm64: dts: exynos: add initial support for Samsung Exynos8855 smdk
From: Alim Akhtar @ 2026-06-12 16:30 UTC (permalink / raw)
To: krzk, peter.griffin, robh, conor+dt, linusw
Cc: linux-samsung-soc, linux-kernel, devicetree, linux-gpio,
hajun.sung, Alim Akhtar
In-Reply-To: <20260612163020.411761-1-alim.akhtar@samsung.com>
Add initial devicetree support for Samsung smdk board using
Exynos8855 SoC.
Signed-off-by: Alim Akhtar <alim.akhtar@samsung.com>
---
arch/arm64/boot/dts/exynos/Makefile | 1 +
.../boot/dts/exynos/exynos8855-pinctrl.dtsi | 581 ++++++++++++++++++
.../arm64/boot/dts/exynos/exynos8855-smdk.dts | 37 ++
arch/arm64/boot/dts/exynos/exynos8855.dtsi | 214 +++++++
4 files changed, 833 insertions(+)
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855-pinctrl.dtsi
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
create mode 100644 arch/arm64/boot/dts/exynos/exynos8855.dtsi
diff --git a/arch/arm64/boot/dts/exynos/Makefile b/arch/arm64/boot/dts/exynos/Makefile
index 76cc23acb9b2..8c48ce2e02e5 100644
--- a/arch/arm64/boot/dts/exynos/Makefile
+++ b/arch/arm64/boot/dts/exynos/Makefile
@@ -14,6 +14,7 @@ dtb-$(CONFIG_ARCH_EXYNOS) += \
exynos7870-on7xelte.dtb \
exynos7885-jackpotlte.dtb \
exynos850-e850-96.dtb \
+ exynos8855-smdk.dtb \
exynos8895-dreamlte.dtb \
exynos9810-starlte.dtb \
exynos990-c1s.dtb \
diff --git a/arch/arm64/boot/dts/exynos/exynos8855-pinctrl.dtsi b/arch/arm64/boot/dts/exynos/exynos8855-pinctrl.dtsi
new file mode 100644
index 000000000000..f5d30fd299b6
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos8855-pinctrl.dtsi
@@ -0,0 +1,581 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung's S5E8855 SoC pin-mux and pin-config device tree source
+ *
+ * Copyright (c) 2023 Samsung Electronics Co., Ltd.
+ * http://www.samsung.com
+ *
+ * Samsung's S5E8855 SoC pin-mux and pin-config options are listed as device
+ * tree nodes are listed in this file.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+#include "exynos-pinctrl.h"
+
+&pinctrl_alive {
+ gpa0: gpa0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 1 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 2 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 3 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 4 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 7 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpa1: gpa1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 8 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 9 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 10 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 11 IRQ_TYPE_LEVEL_HIGH 0>,
+ <GIC_SPI 12 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpq0: gpq0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpq1: gpq1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+ };
+
+ gpc0: gpc0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 13 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc1: gpc1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 14 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc2: gpc2-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 15 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc3: gpc3-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 16 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc4: gpc4-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 17 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc5: gpc5-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 18 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc6: gpc6-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 19 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc7: gpc7-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 20 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc8: gpc8-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 21 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc9: gpc9-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 22 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc10: gpc10-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 23 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc11: gpc11-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 24 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc12: gpc12-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 25 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc13: gpc13-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 26 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpc14: gpc14-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 27 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpj0: gpj0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 28 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpj1: gpj1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 29 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpj2: gpj2-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 30 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ uart0_bus: uart0-bus {
+ samsung,pins = "gpq0-0", "gpq0-1";
+ samsung,pin-function = <2>;
+ samsung,pin-pud = <3>;
+ };
+
+};
+
+&pinctrl_cmgp {
+ gpm0: gpm0 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 114 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm1: gpm1 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 115 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm2: gpm2 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 116 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm3: gpm3 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 117 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm4: gpm4 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 118 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm5: gpm5 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 119 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm6: gpm6 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 120 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm7: gpm7 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 121 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm8: gpm8 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 122 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm9: gpm9 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 123 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm10: gpm10 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 124 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm11: gpm11 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 125 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm12: gpm12 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 126 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm13: gpm13 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 127 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm14: gpm14 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 128 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm15: gpm15 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 129 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm16: gpm16 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 130 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm17: gpm17 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 131 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm18: gpm18 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 132 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm19: gpm19 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 133 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm20: gpm20 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 134 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ gpm21: gpm21 {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ interrupt-parent = <&gic>;
+ interrupts = <GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+};
+
+&pinctrl_hsi_ufs {
+ gpf3: gpf3-gpio-bank{
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+&pinctrl_peric {
+ gpp0: gpp0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpp1: gpp1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpp2: gpp2-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg0: gpg0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg1: gpg1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb0: gpb0-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpb1: gpb1-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+&pinctrl_pericmmc {
+ gpf2: gpf2-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
+
+&pinctrl_usi {
+ gpp3: gpp3-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpp4: gpp4-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg2: gpg2-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+
+ gpg3: gpg3-gpio-bank {
+ gpio-controller;
+ #gpio-cells = <2>;
+
+ interrupt-controller;
+ #interrupt-cells = <2>;
+ };
+};
diff --git a/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts b/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
new file mode 100644
index 000000000000..3ebe847c21cf
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos8855-smdk.dts
@@ -0,0 +1,37 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung Exynos8855 SMDK board device tree source
+ *
+ * Copyright (C) 2026 Samsung Electronics Co., Ltd.
+ *
+ * Device tree source file for WinLink's E850-96 board which is based on
+ * Samsung Exynos8855 SoC.
+ */
+
+/dts-v1/;
+
+#include "exynos8855.dtsi"
+
+/ {
+ model = "Samsung Exynos8855 SMDK board";
+ compatible = "samsung,exynos8855-smdk","samsung,exynos8855";
+
+ aliases {
+ serial0 = &serial_0;
+ };
+
+ chosen {
+ stdout-path = &serial_0;
+ };
+
+ memory@80000000 {
+ device_type = "memory";
+ reg = <0x0 0x80000000 0x80000000>;
+ };
+
+};
+
+&oscclk {
+ clock-frequency = <76800000>;
+};
+
diff --git a/arch/arm64/boot/dts/exynos/exynos8855.dtsi b/arch/arm64/boot/dts/exynos/exynos8855.dtsi
new file mode 100644
index 000000000000..cffa40b6bb98
--- /dev/null
+++ b/arch/arm64/boot/dts/exynos/exynos8855.dtsi
@@ -0,0 +1,214 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Samsung Exynos8855 SoC device tree source
+ *
+ * Copyright (C) 2023 Samsung Electronics Co., Ltd.
+ *
+ * Samsung Exynos8855 SoC device nodes are listed in this file.
+ * Exynos8855 based board files can include this file and provide
+ * values for board specific bindings.
+ */
+
+#include <dt-bindings/interrupt-controller/arm-gic.h>
+
+/ {
+ compatible = "samsung,exynos8855";
+ #address-cells = <2>;
+ #size-cells = <1>;
+
+ interrupt-parent = <&gic>;
+
+ aliases {
+ pinctrl0 = &pinctrl_alive;
+ pinctrl1 = &pinctrl_cmgp;
+ pinctrl2 = &pinctrl_hsi_ufs;
+ pinctrl3 = &pinctrl_peric;
+ pinctrl4 = &pinctrl_pericmmc;
+ pinctrl5 = &pinctrl_usi;
+ };
+
+ oscclk: clock-oscclk {
+ compatible = "fixed-clock";
+ clock-output-names = "oscclk";
+ #clock-cells = <0>;
+ };
+
+ cpus {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ cpu-map {
+ cluster0 {
+ core0 {
+ cpu = <&cpu0>;
+ };
+ core1 {
+ cpu = <&cpu1>;
+ };
+ core2 {
+ cpu = <&cpu2>;
+ };
+ core3 {
+ cpu = <&cpu3>;
+ };
+ };
+
+ cluster1 {
+ core0 {
+ cpu = <&cpu4>;
+ };
+ core1 {
+ cpu = <&cpu5>;
+ };
+ core3 {
+ cpu = <&cpu6>;
+ };
+ };
+
+ cluster2 {
+ core0 {
+ cpu = <&cpu7>;
+ };
+ };
+ };
+
+ cpu0: cpu@0 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a520";
+ reg = <0x0>;
+ enable-method = "psci";
+ };
+
+ cpu1: cpu@100 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a520";
+ reg = <0x100>;
+ enable-method = "psci";
+ };
+
+ cpu2: cpu@200 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a520";
+ reg = <0x200>;
+ enable-method = "psci";
+ };
+
+ cpu3: cpu@300 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a520";
+ reg = <0x300>;
+ enable-method = "psci";
+ };
+
+ cpu4: cpu@400 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a720";
+ reg = <0x400>;
+ enable-method = "psci";
+ };
+
+ cpu5: cpu@500 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a720";
+ reg = <0x500>;
+ enable-method = "psci";
+ };
+
+ cpu6: cpu@600 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a720";
+ reg = <0x600>;
+ enable-method = "psci";
+ };
+
+ cpu7: cpu@700 {
+ device_type = "cpu";
+ compatible = "arm,cortex-a720";
+ reg = <0x700>;
+ enable-method = "psci";
+ };
+ };
+
+ psci {
+ compatible = "arm,psci-1.0";
+ method = "smc";
+ };
+
+ soc: soc@0 {
+ compatible = "simple-bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ ranges = <0x0 0x0 0x0 0x20000000>;
+
+ gic: interrupt-controller@10200000 {
+ compatible = "arm,gic-v3";
+ #interrupt-cells = <4>;
+ #address-cells = <0>;
+ #size-cells = <1>;
+ reg = <0x10200000 0x10000>,
+ <0x10240000 0x100000>;
+ interrupt-controller;
+ interrupts = <GIC_PPI 9 IRQ_TYPE_LEVEL_HIGH 0>;
+ };
+
+ pinctrl_alive: pinctrl@11850000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x11850000 0x1000>;
+
+ wakeup-interrupt-controller {
+ compatible = "samsung,exynos850-wakeup-eint",
+ "samsung,exynos7-wakeup-eint";
+ };
+ };
+
+ pinctrl_cmgp: pinctrl@12030000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x12030000 0x1000>;
+
+ wakeup-interrupt-controller {
+ compatible = "samsung,exynos850-wakeup-eint",
+ "samsung,exynos7-wakeup-eint";
+ };
+ };
+
+ pinctrl_usi: pinctrl@15030000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x15030000 0x1000>;
+ };
+
+ pinctrl_peric: pinctrl@15440000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x15440000 0x1000>;
+ };
+
+ pinctrl_pericmmc: pinctrl@154f0000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x154f0000 0x1000>;
+ };
+
+ pinctrl_hsi_ufs: pinctrl@17040000 {
+ compatible = "samsung,exynos8855-pinctrl";
+ reg = <0x17040000 0x1000>;
+ };
+
+ serial_0: serial@15500000 {
+ compatible = "samsung,exynos850-uart";
+ reg = <0x15500000 0x100>;
+ interrupts = <GIC_SPI 403 IRQ_TYPE_LEVEL_HIGH 0>;
+ pinctrl-names = "default";
+ pinctrl-0 = <&uart0_bus>;
+ };
+ };
+
+ timer {
+ compatible = "arm,armv8-timer";
+ /* Hypervisor Virtual Timer interrupt is not wired to GIC */
+ interrupts =
+ <GIC_PPI 13 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+ <GIC_PPI 14 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+ <GIC_PPI 11 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>,
+ <GIC_PPI 10 (GIC_CPU_MASK_SIMPLE(8) | IRQ_TYPE_LEVEL_LOW) 0>;
+ };
+};
+
+#include "exynos8855-pinctrl.dtsi"
--
2.34.1
^ permalink raw reply related
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Conor Dooley @ 2026-06-12 16:12 UTC (permalink / raw)
To: Potin Lai
Cc: Guenter Roeck, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <CAGfYmwWPhdpTLGhOdddJ0hSj-H86+XOVGTR9eDkZSVqGRLfJvQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2224 bytes --]
On Fri, Jun 12, 2026 at 05:10:38PM +0800, Potin Lai wrote:
> On Fri, Jun 12, 2026 at 1:27 AM Conor Dooley <conor@kernel.org> wrote:
> >
> > On Thu, Jun 11, 2026 at 05:58:44PM +0800, Potin Lai wrote:
> > > Add mutually exclusive 'ti,cl-smbus-high' and 'ti,cl-smbus-low' boolean
> > > properties to configure the device's Current Limit (CL) behavior using
> > > SMBus settings instead of physical pins.
> > >
> > > Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> > > ---
> > > .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 20 ++++++++++++++++++++
> > > 1 file changed, 20 insertions(+)
> > >
> > > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > index a20f140dc79a..95ea7c26dec2 100644
> > > --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > @@ -46,6 +46,26 @@ properties:
> > >
> > > additionalProperties: false
> > >
> > > + ti,cl-smbus-high:
> > > + description: |
> > > + Configure the Current Limit (CL) to use the SMBus high setting.
> > > + type: boolean
> > > +
> > > + ti,cl-smbus-low:
> > > + description: |
> > > + Configure the Current Limit (CL) to use the SMBus low setting.
> > > + type: boolean
> >
> > What's smbus specific about this? If the pin was connected to a GPIO,
> > you'd then need to have different properties or use these ones with an
> > inaccurate name.
> >
>
> The "smbus" in the property name was originally meant to indicate
> that the setting is configured via the internal register over the SMBus (I2C)
> interface, rather than physical pins.
Right, but if you do it via the physical pins using a gpio, you still
need a way to say what limit is. The status quo only works if the limit
pin is tied high or low.
>
> > Please also spell out "current-limit".
> >
>
> I will rename the properties to "ti,current-limit-high" and
> "ti,current-limit-low"
> in the next version.
Other thing that might be worth doing is making the property a string
and just having `ti,current-limit = "low"` etc.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] iio: adc: Add TI ADS1220 driver
From: David Lechner @ 2026-06-12 16:14 UTC (permalink / raw)
To: Nguyen Minh Tien, Jonathan Cameron
Cc: linux-iio, devicetree, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Nuno Sá, Andy Shevchenko, linux-kernel
In-Reply-To: <20260610151342.44274-3-zizuzacker@gmail.com>
On 6/10/26 10:13 AM, Nguyen Minh Tien wrote:
> Add an IIO driver for the Texas Instruments ADS1220 24-bit delta-sigma
> SPI ADC. The driver supports single-ended and differential voltage
> channels described as device-tree child nodes, per-channel programmable
> gain (exposed through scale) and data rate (exposed through sampling
> frequency), the internal 2.048V reference, an external reference via a
> regulator, or the analog supply (AVDD) as a ratiometric reference,
> single-shot conversions and a DRDY-interrupt-driven triggered buffer.
> Conversions are gated either on the DRDY interrupt or, when no interrupt
> is wired, on a data-rate-derived delay. Runtime PM powers the device down
> between conversions.
As I mentioned in the DT binding review, I have a driver for ADS122C14
that I should be able to send to the mailing list next week. ADS1220
looks like a simpler version of that but shares many of the same features.
So I would suggest to check that out when I send it and see if we can
share the driver.
^ permalink raw reply
* Re: [PATCH v2 8/9] dt-bindings: input: microchip,cap11xx: Add CAP1114 support
From: Conor Dooley @ 2026-06-12 16:15 UTC (permalink / raw)
To: Jun Yan
Cc: Dmitry Torokhov, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
linux-input, devicetree, linux-kernel
In-Reply-To: <20260612072237.1177304-9-jerrysteve1101@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3266 bytes --]
On Fri, Jun 12, 2026 at 03:22:14PM +0800, Jun Yan wrote:
> CAP1114 is a 14-channel capacitive touch sensor with 11 LED outputs
> and hardware reset support.
>
> Add the compatible string for CAP1114, add its datasheet URL,
> update the maximum of LED channel reg, and add constraint for
> linux,keycodes.
>
> Previously, the LED reg property had a default maximum of 7 for CAP1188.
> With the addition of CAP1114, the default maximum is now 11.
> An if-then constraint is added to limit the LED count for CAP1188.
>
> Update description for microchip,input-threshold: CAP1114 only provides
> eight threshold entries, which does not match its total channel count.
>
> CAP1114 does not support microchip,signal-guard and
> microchip,calib-sensitivity.
>
> Add CAP1114 to the unsupported enum list.
>
> Signed-off-by: Jun Yan <jerrysteve1101@gmail.com>
> ---
> .../bindings/input/microchip,cap11xx.yaml | 32 ++++++++++++++++++-
> 1 file changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> index 778ec6d659a8..0e9a1a8a3f3e 100644
> --- a/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> +++ b/Documentation/devicetree/bindings/input/microchip,cap11xx.yaml
> @@ -12,6 +12,7 @@ description: |
>
> For more product information please see the links below:
> CAP1106: https://ww1.microchip.com/downloads/en/DeviceDoc/00001624B.pdf
> + CAP1114: https://ww1.microchip.com/downloads/en/DeviceDoc/00002444A.pdf
> CAP1126: https://ww1.microchip.com/downloads/en/DeviceDoc/00001623B.pdf
> CAP1188: https://ww1.microchip.com/downloads/en/DeviceDoc/00001620C.pdf
> CAP1203: https://ww1.microchip.com/downloads/en/DeviceDoc/00001572B.pdf
> @@ -26,6 +27,7 @@ properties:
> compatible:
> enum:
> - microchip,cap1106
> + - microchip,cap1114
> - microchip,cap1126
> - microchip,cap1188
> - microchip,cap1203
> @@ -122,6 +124,8 @@ properties:
> is required for a touch to be registered, making the touch sensor less
> sensitive.
> The number of entries must correspond to the number of channels.
> + CAP1114 is an exception where channels 8~14 reuse the eighth entry's
> + threshold, so counts differ.
>
> microchip,calib-sensitivity:
> $ref: /schemas/types.yaml#/definitions/uint32-array
> @@ -149,7 +153,7 @@ patternProperties:
> reg:
> description: LED channel number
> minimum: 0
> - maximum: 7
> + maximum: 10
>
> label: true
>
> @@ -178,6 +182,18 @@ allOf:
> properties:
> reset-gpios: false
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + enum:
> + - microchip,cap1114
> + then:
> + properties:
> + linux,keycodes:
> + minItems: 14
> + maxItems: 14
Sashiko complaint here is valid.
You need to increase the outer constraint to max 14, and only set the
min here.
Then you need to add an else that sets maxitems to 8.
pw-bot: changes-requested
Cheers,
Conor.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] dt-bindings: power: supply: maxim,max8903: add DC and USB input current-limit controls
From: Rob Herring (Arm) @ 2026-06-12 16:15 UTC (permalink / raw)
To: Herman van Hazendonk
Cc: linux-kernel, linux-pm, devicetree, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Sebastian Reichel
In-Reply-To: <20260605-submit-power-max8903-dc-limit-v2-1-0c5396e98f14@herrie.org>
On Fri, 05 Jun 2026 11:18:12 +0200, Herman van Hazendonk wrote:
> Add three optional properties to the MAX8903 charger binding to
> describe board-level GPIO control of the DC and USB input current
> limits:
>
> DC input (TA / DOK pin):
> - dc-current-limit-gpios (1..4 GPIOs): mux control lines feeding
> the MAX8903 IDC resistor mux;
> - dc-current-limit-mapping (uint32-matrix of {microamps,
> gpio_bit_pattern} pairs): the available current levels and the
> GPIO bit pattern that selects each level.
>
> USB input (USB / UOK pin):
> - usb-current-limit-gpios: a single GPIO driving the IUSB pin.
> The IUSB pin is silicon-fixed by the MAX8903 datasheet (Pin
> Description): low selects 100 mA, high selects 500 mA. Only
> the GPIO mapping is board-specific; the current values are
> not exposed in DT.
>
> A dependentRequired block ties dc-current-limit-gpios and
> dc-current-limit-mapping together so an incomplete DT cannot pass
> validation with only one half of the pair.
>
> These let userspace clamp the input draw via the standard
> POWER_SUPPLY_PROP_INPUT_CURRENT_LIMIT power_supply attribute. The HP
> TouchPad uses both: two TLMM lines select between 0.5 A, 1.0 A,
> 1.5 A and 2.0 A DC input current limits behind the MAX8903B
> charger, and a third TLMM line picks the IUSB 100 mA / 500 mA
> limit.
>
> These are purely additive; existing platforms remain unaffected.
>
> Signed-off-by: Herman van Hazendonk <github.com@herrie.org>
> ---
> .../bindings/power/supply/maxim,max8903.yaml | 53 ++++++++++++++++++++++
> 1 file changed, 53 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 1/7] dt-bindings: display: tegra: Changes to support Tegra264
From: Conor Dooley @ 2026-06-12 16:16 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260612-t264-host1x-v1-1-8d934987de67@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 1736 bytes --]
On Fri, Jun 12, 2026 at 03:32:29PM +0900, Mikko Perttunen wrote:
> Add nvidia,tegra264-host1x compatible string. The Tegra264 host1x is
> similar to Tegra234, but with a different set of engines and layout.
>
> The engine register range is no longer continuous, so two range entries
> are also needed.
Please restrict the new ranges of 2 to only the new device.
pw-bot: changes-requested
Thanks,
Conor.
>
> Signed-off-by: Mikko Perttunen <mperttunen@nvidia.com>
> ---
> .../devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml | 5 ++++-
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> index 3563378a01af..5b0e3158aa5b 100644
> --- a/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> +++ b/Documentation/devicetree/bindings/display/tegra/nvidia,tegra20-host1x.yaml
> @@ -25,6 +25,7 @@ properties:
> - nvidia,tegra186-host1x
> - nvidia,tegra194-host1x
> - nvidia,tegra234-host1x
> + - nvidia,tegra264-host1x
>
> - items:
> - const: nvidia,tegra132-host1x
> @@ -57,7 +58,8 @@ properties:
> enum: [1, 2]
>
> ranges:
> - maxItems: 1
> + minItems: 1
> + maxItems: 2
>
> clocks:
> description: Must contain one entry, for the module clock. See
> @@ -192,6 +194,7 @@ allOf:
> contains:
> enum:
> - nvidia,tegra234-host1x
> + - nvidia,tegra264-host1x
> then:
> properties:
> reg-names:
>
> --
> 2.53.0
>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH 2/7] dt-bindings: display: tegra: Add Tegra264 compatible for VIC
From: Conor Dooley @ 2026-06-12 16:17 UTC (permalink / raw)
To: Mikko Perttunen
Cc: Thierry Reding, Jonathan Hunter, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-tegra, dri-devel,
devicetree, linux-kernel
In-Reply-To: <20260612-t264-host1x-v1-2-8d934987de67@nvidia.com>
[-- Attachment #1: Type: text/plain, Size: 75 bytes --]
Acked-by: Conor Dooley <conor.dooley@microchip.com>
pw-bot: not-applicable
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH v4 01/14] dt-bindings: leds: Document TI LM3533 LED controller
From: Rob Herring (Arm) @ 2026-06-12 16:18 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Jonathan Cameron, dri-devel, linux-kernel, Jingoo Han,
Nuno Sá, Johan Hovold, linux-iio, Andy Shevchenko,
linux-leds, devicetree, Krzysztof Kozlowski, Pavel Machek,
David Lechner, Daniel Thompson, Lee Jones, linux-fbdev,
Helge Deller, Conor Dooley
In-Reply-To: <20260606045738.21050-2-clamor95@gmail.com>
On Sat, 06 Jun 2026 07:57:25 +0300, Svyatoslav Ryhel wrote:
> Document the LM3533 - a complete power source for backlight, keypad and
> indicator LEDs in smartphone handsets. The high-voltage inductive boost
> converter provides the power for two series LED strings display backlight
> and keypad functions.
>
> Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> Reviewed-by: Jonathan Cameron <jic23@kernel.org> #for light sensor
> Reviewed-by: Daniel Thompson (RISCstar) <danielt@kernel.org> #for backlight
> ---
> .../leds/backlight/ti,lm3533-backlight.yaml | 69 +++++++
> .../bindings/leds/ti,lm3533-leds.yaml | 67 +++++++
> .../devicetree/bindings/leds/ti,lm3533.yaml | 169 ++++++++++++++++++
> 3 files changed, 305 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/leds/backlight/ti,lm3533-backlight.yaml
> create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533-leds.yaml
> create mode 100644 Documentation/devicetree/bindings/leds/ti,lm3533.yaml
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH 2/5] dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
From: sashiko-bot @ 2026-06-12 16:21 UTC (permalink / raw)
To: Alim Akhtar; +Cc: devicetree, robh, conor+dt
In-Reply-To: <20260612163020.411761-3-alim.akhtar@samsung.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] Missing SoC-specific compatible string for Exynos8855 wake-up interrupt controller.
--
commit 87a449ad3230af2abf934581a9ca7d771b0d6dd7
Author: Alim Akhtar <alim.akhtar@samsung.com>
dt-binding: pinctrl: samsung: Add exynos8855-pinctrl compatible
This commit documents pin controller support for the Exynos8855 SoC. It adds
the samsung,exynos8855-pinctrl compatible string to the allowed properties
list in the samsung,pinctrl.yaml schema.
> diff --git a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> index 7b006009ca0e7..c4773701c92e3 100644
> --- a/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> +++ b/Documentation/devicetree/bindings/pinctrl/samsung,pinctrl.yaml
> @@ -53,6 +53,7 @@ properties:
> - samsung,exynos7870-pinctrl
> - samsung,exynos7885-pinctrl
> - samsung,exynos850-pinctrl
> + - samsung,exynos8855-pinctrl
[Severity: Low]
Should this patch also define a corresponding SoC-specific compatible string
for the child wake-up interrupt controller (samsung,exynos8855-wakeup-eint)
under properties:compatible:oneOf:items:enum in the following file:
Documentation/devicetree/bindings/pinctrl/samsung,pinctrl-wakeup-interrupt.yaml?
Standard device tree guidelines require an SoC-specific compatible string
for all hardware blocks to accommodate potential future quirks, rather than
relying exclusively on a fallback like samsung,exynos850-wakeup-eint.
> - samsung,exynos8890-pinctrl
> - samsung,exynos8895-pinctrl
> - samsung,exynos9610-pinctrl
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260612163020.411761-1-alim.akhtar@samsung.com?part=2
^ permalink raw reply
* [PATCH v5 00/18] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-06-12 16:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel, William Wu
This series overhauls the Rockchip USBDP driver; apart from a
a bunch of cleanups and small improvements the main goal is to
get the driver ready for proper USB-C DP AltMode support. At
the moment it only contains a semi-working state.
Once this series has landed, it unblocks enabling proper USB-C
DP AltMode on the RK3588 and RK3576 platforms incl. runtime PM
for the Synopsys DesignWare DisplayPort controller.
Apart from this series, further changes are required on the
DRM side. There are no compile-time dependencies between the
DRM side and the PHY side, but the PHY side must be applied
to avoid SErrors once runtime PM is added to the DisplayPort
controller driver. Thus it would be really good to land this
series ASAP as it blocks the DRM side.
Changes in v5:
- Link to v4: https://lore.kernel.org/r/20260428-rockchip-usbdp-cleanup-v4-0-7775671ece22@collabora.com
- Picked up Acked-by from Rob Herring for DT binding
- Fix typos in commit messages/comments
- Add Fixes tag to "Do not looe USB3 PHY status" patch
- Collect Reviewed-by: Neil Armstrong for multiple patches
- Drop now unused code from "Drop DP HPD handling" patch (Sashiko)
- Ignore mux events not involving DP AltMode (Sashiko)
- Add new patch to support going back from DP only mode to USB combo
mode; technically this is a fix, but DP mode does not yet work
upstream, so it does not matter (Sashiko)
- Add new patch adding a few debug messages, which are useful
to investigate potential hotplug issues in the future
- Sashiko comments about the DT binding and property usage
are wrong as the first port is for the superspeed lanes
used for DP and USB, while the last port is just about
DP aux. I ignored them.
- There is a pre-existing bug, that can already be hit with the
upstream kernel and that the series doesn't fix properly:
Accessing the USB3 controller registers requires the USB PHY
running, since it provides a clock. Re-initializing the PHY
means there is a race-condition - if the system tries to access
the USB3 controller in parallel to the re-init, the system will
hang and/or fail with an SError. By keeping the clocks running
and only asserting the resets this time is minimized by this
series. A proper fix for this will be looked into independently
from this series.
- I used v7.1-rc6 as base, but the driver has no changes since
6.18 even in linux-next and there are no pending patches for
it on the mailinglist either, so it applies to *any* recent
kernel branch.
Changes in v4:
- Link to v3: https://lore.kernel.org/r/20260313-rockchip-usbdp-cleanup-v3-0-3e8fe89a35b5@collabora.com
- rebased to v7.1-rc1 (no changes)
- Update DRM bridge registration patch to avoid registration when DP aux
port is not connected to anything, since this results in errors and some
boards use USBDP instances for USB3 only.
- Add patch renaming mode_change into phy_needs_reinit
- Add patch to re-init PHY on orientation change
- Add patch to factor out lane_mux_sel setup
- Add patch to handle mutex via guard functions
Changes in v3:
- Link to v2: https://lore.kernel.org/r/20260213-rockchip-usbdp-cleanup-v2-0-b67ec225f96e@collabora.com
- Add patch to register the USBDP PHY as DRM bridge
- Add patch to describe ports in DT binding (used by the DRM bridge)
- Add patch to drop HPD handling from the PHY
Changes in v2:
- Link to v1: https://lore.kernel.org/r/20260203-rockchip-usbdp-cleanup-v1-0-16a6f92ed176@collabora.com
- Added new patches to fix USB3 SError
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
Frank Wang (1):
phy: rockchip: usbdp: Amend SSC modulation deviation
Sebastian Reichel (15):
dt-bindings: phy: rockchip-usbdp: add improved ports scheme
phy: rockchip: usbdp: Do not lose USB3 PHY status
phy: rockchip: usbdp: Keep clocks running on PHY re-init
phy: rockchip: usbdp: Add missing mode_change update
phy: rockchip: usbdp: Rename DP lane functions
phy: rockchip: usbdp: Use FIELD_PREP_WM16_CONST
phy: rockchip: usbdp: Cleanup DP lane selection function
phy: rockchip: usbdp: Register DP aux bridge
phy: rockchip: usbdp: Drop DP HPD handling
phy: rockchip: usbdp: Rename mode_change to phy_needs_reinit
phy: rockchip: usbdp: Re-init the PHY on orientation change
phy: rockchip: usbdp: Factor out lane_mux_sel setup
phy: rockchip: usbdp: Use guard functions for mutex
phy: rockchip: usbdp: Support going from DP-only mode to USB mode
phy: rockchip: usbdp: Add some extra debug messages
William Wu (1):
phy: rockchip: usbdp: Fix LFPS detect threshold control
Zhang Yubing (1):
phy: rockchip: usbdp: Support single-lane DP
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++
drivers/phy/rockchip/Kconfig | 2 +
drivers/phy/rockchip/phy-rockchip-usbdp.c | 357 +++++++++------------
3 files changed, 181 insertions(+), 201 deletions(-)
---
base-commit: e43ffb69e0438cddd72aaa30898b4dc446f664f8
change-id: 20260203-rockchip-usbdp-cleanup-5b59dfb561a3
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v5 01/18] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Sebastian Reichel @ 2026-06-12 16:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com>
Currently the Rockchip USBDP PHY is missing a documented port scheme.
Meanwhile upstream RK3588 DTS files are a bit messy and use different
port schemes. The upstream USBDP PHY Linux kernel driver does not yet
parse the ports at all and thus does not create any implicit ABI either.
But with the current mess it is not possible to properly support USB-C
DP AltMode. Thus this introduces a proper port scheme following roughly
the ports design of the Qualcomm QMP USB4-USB3-DP PHY controller binding
with a slight difference that there is an additional port for the
USB-C SBU port as the Rockchip USB-DP PHY also contains the SBU mux.
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
.../bindings/phy/phy-rockchip-usbdp.yaml | 23 ++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
index 8b7059d5b182..f728acf057e4 100644
--- a/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
+++ b/Documentation/devicetree/bindings/phy/phy-rockchip-usbdp.yaml
@@ -114,6 +114,29 @@ properties:
A port node to link the PHY to a TypeC controller for the purpose of
handling orientation switching.
+ ports:
+ $ref: /schemas/graph.yaml#/properties/ports
+ properties:
+ port@0:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for USB (or DP when configured into 4 lane
+ mode), which should point to the superspeed port of a USB connector.
+
+ port@1:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the USB controller
+
+ port@2:
+ $ref: /schemas/graph.yaml#/properties/port
+ description: Incoming endpoint from the DisplayPort controller
+
+ port@3:
+ $ref: /schemas/graph.yaml#/properties/port
+ description:
+ Output endpoint of the PHY for DP, which should either point to the
+ SBU port of a USB-C connector or a DisplayPort connector input port.
+
required:
- compatible
- reg
--
2.53.0
^ permalink raw reply related
* [PATCH v5 03/18] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: Sebastian Reichel @ 2026-06-12 16:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com>
When a mode change is required rk_udphy_power_on() disables
the clocks and then calls rk_udphy_setup(), which then enables
all the clocks again before continuing with rk_udphy_init().
Considering that rk_udphy_init() does assert the reset lines,
re-enabling the clocks is just delaying things. Avoid it by
directly calling rk_udphy_init().
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 744cc7c642f4..98562a888b42 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1012,8 +1012,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
- rk_udphy_disable(udphy);
- ret = rk_udphy_setup(udphy);
+ ret = rk_udphy_init(udphy);
if (ret)
return ret;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v5 02/18] phy: rockchip: usbdp: Do not lose USB3 PHY status
From: Sebastian Reichel @ 2026-06-12 16:21 UTC (permalink / raw)
To: Vinod Koul, Neil Armstrong, Heiko Stuebner, Frank Wang,
Rob Herring, Krzysztof Kozlowski, Conor Dooley
Cc: Andy Yan, Dmitry Baryshkov, Yubing Zhang, Alexey Charkov,
linux-phy, linux-arm-kernel, linux-rockchip, linux-kernel, kernel,
devicetree, Sebastian Reichel
In-Reply-To: <20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com>
By default (i.e. without manually enabling runtime PM) DWC3 requests the
USB3 PHY once and keeps it enabled all the time. When DisplayPort is
being requested later on, a mode change is needed. This re-initializes
the PHY. During re-initialization the status variable has incorrectly
been cleared, which means the tracking information for USB3 is lost.
This is not an immediate problem, since the DP side keeps the PHY
enabled. But once DP is toggled off, the whole PHY will be disabled.
This is a problem, because the USB side still needs it powered.
Fix things by not clearing the status flags.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..744cc7c642f4 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1009,7 +1009,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
rk_udphy_u3_port_disable(udphy, false);
} else if (udphy->mode_change) {
udphy->mode_change = false;
- udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
--
2.53.0
^ permalink raw reply related
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