* Re: [PATCH v2 5/8] dt-bindings: iio: adc: add ti,ads122c14
From: David Lechner @ 2026-06-26 18:35 UTC (permalink / raw)
To: Conor Dooley
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chris Hall, Patrick Edwards,
Kurt Borja, Nguyen Minh Tien, linux-iio, devicetree, linux-kernel
In-Reply-To: <20260626-rising-legged-dea08bb68bfe@spud>
On 6/26/26 11:18 AM, Conor Dooley wrote:
> On Thu, Jun 25, 2026 at 04:55:07PM -0500, David Lechner (TI) wrote:
>> Add new bindings for ti,ads122c14 and similar devices.
>>
>> This is an ADC that is primarily intended for use with temperature
>> sensors. There are a few unusual properties because of this. In
>> particular, the reference voltage source and current output requirements
>> can be different for each measurement, so these are included in the
>> channel bindings.
>>
>> The REFP/REFN reference voltage is usually just connected to a resistor
>> that is being driven by the ADC's current outputs, so there is special
>> property for this case rather than requiring a regulator to be defined
>> to represent that.
>>
>> ti,vref-source is reused from ti,tlv320adcx140.yaml (otherwise might
>> have preferred an enum of strings).
>>
>> Signed-off-by: David Lechner (TI) <dlechner@baylibre.com>
>> ---
>>
>> v2 changes:
>> * Added ti, vendor prefix when appropriate.
>> * Others are now standardized properties from adc.yaml.
>> * Moved top-level unevaluatedProperties.
>> * Fixed some issues with the channel@ matching and reg property.
>> * Dropped description on bipolar property.
>> * Renamed currnet-chopping to input-channel-rotation.
>> * Drop header file and use string enum instead for reference-sources.
>> * Added burn-out-current-nanoamp property.
>> * Drop allOf: and just use oneOf: directly.
>> * Fix inconsistent indentation in the examples.
>> ---
>> .../devicetree/bindings/iio/adc/ti,ads112c14.yaml | 205 +++++++++++++++++++++
>> MAINTAINERS | 6 +
>> 2 files changed, 211 insertions(+)
>>
>> diff --git a/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> new file mode 100644
>> index 000000000000..59ee4d652a08
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/iio/adc/ti,ads112c14.yaml
>> @@ -0,0 +1,205 @@
>> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
>> +%YAML 1.2
>> +---
>> +$id: http://devicetree.org/schemas/iio/adc/ti,ads112c14.yaml#
>> +$schema: http://devicetree.org/meta-schemas/core.yaml#
>> +
>> +title: Texas Instruments' ADS112C14 and similar ADC chips
>> +
>> +description: |
>> + Supports the following Texas Instruments' ADC chips:
>> + - ADS112C14 (16-bit)
>> + - ADS122C14 (24-bit)
>> +
>> + https://www.ti.com/lit/ds/symlink/ads122c14.pdf
>> +
>> + These chips are primarily designed for use with temperature sensors such as
>> + RTDs and thermocouples. The channel bindings reflect this in that each channel
>> + represents the conditions required to make a measurement rather than strictly
>> + just the physical input channels.
>> +
>> +maintainers:
>> + - David Lechner <dlechner@baylibre.com>
>> +
>> +properties:
>> + compatible:
>> + enum:
>> + - ti,ads112c14
>> + - ti,ads122c14
>> +
>> + reg:
>> + items:
>> + - minimum: 0x40
>> + maximum: 0x47
>> +
>> + clocks:
>> + maxItems: 1
>> + description: Optional external clock connected to GPIO3 pin.
>> +
>> + avdd-supply: true
>> + dvdd-supply: true
>> +
>> + refp-supply: true
>> + refn-supply: true
>> +
>> + ti,refp-refn-resistor-ohms:
>> + description:
>> + The resistance of the external resistor between REFP and REFN when using
>> + resistor bridge driven by current outputs for RTD measurements.
>> +
>> + interrupts:
>> + minItems: 1
>> + items:
>> + - description: FAULT interrupt (GPIO2 pin)
>> + - description: DRDY interrupt (GPIO3 pin)
>> +
>> + interrupt-names:
>> + minItems: 1
>> + maxItems: 2
>> + items:
>> + enum: [fault, drdy]
>> +
>> + gpio-controller: true
>> + '#gpio-cells':
>> + const: 2
>> +
>> + '#address-cells':
>> + const: 1
>> +
>> + '#size-cells':
>> + const: 0
>> +
>> +patternProperties:
>> + ^channel@[0-7a-f]$:
>
> How does this work/what's the intention here?
>
> 0-7 I get, why a-f but not 8 or 9?
bah, just a typo, not intentional
Should be [0-9a-f] to match maximum: 15 on reg.
>
>> + $ref: adc.yaml
>> +
>> + unevaluatedProperties: false
>> +
>> + properties:
>> + reg:
>> + items:
>> + - maximum: 15 # arbitrary limit, channel@ can be any combination of AIN0-AIN7
>> +
>> + single-channel:
>> + maximum: 7
>> +
>> + diff-channels:
>> + items:
>> + maximum: 7
>> +
>> + bipolar: true
>> +
>> + input-channel-rotation: true
>> +
>> + excitation-channels:
>> + maxItems: 2
>> + items:
>> + maximum: 7
>> +
>> + excitation-current-nanoamp:
>> + maxItems: 2
>> + items:
>> + enum: [1000, 10000, 20000, 30000, 40000, 50000, 60000, 70000, 80000,
>> + 90000, 100000, 200000, 300000, 400000, 500000, 600000, 700000,
>> + 800000, 900000, 1000000]
>> +
>> + burn-out-current-nanoamp:
>> + enum: [200, 1000, 10000]
>> +
>> + reference-sources:
>> + items:
>> + - enum: [internal-2.5v, internal-1.25v, external, avdd]
>> + default: internal-2.5v
>> +
>> + dependencies:
>> + excitation-channels: [ excitation-current-nanoamp ]
>> + excitation-current-nanoamp: [ excitation-channels ]
>> +
>> + oneOf:
>> + - required: [ single-channel ]
>> + - required: [ diff-channels ]
>> +
>> +unevaluatedProperties: false
>> +
>> +required:
>> + - compatible
>
> reg?
I thought reg being required by i2c-controller.yaml was already good enough.
https://github.com/devicetree-org/dt-schema/blob/2203c1720f4ebeebd7f8d10e9dc1812993482fab/dtschema/schemas/i2c/i2c-controller.yaml#L219
>
>> + - avdd-supply
>> + - dvdd-supply
>> +
>> +dependencies:
>> + refn-supply: [ refp-supply ]
>> +
>> +oneOf:
>> + - required: [ refp-supply ]
>> + - required: [ "ti,refp-refn-resistor-ohms" ]
>> + - properties:
>> + refp-supply: false
>> + refn-supply: false
>> + ti,refp-refn-resistor-ohms: false
>
> I assume you've tested this to make sure it enforces the behaviour that
> you want?
yes
^ permalink raw reply
* Re: [PATCH V3 1/8] PCI: imx6: Add skip_pwrctrl_off flag support
From: Frank Li @ 2026-06-26 19:40 UTC (permalink / raw)
To: Sherry Sun (OSS)
Cc: robh, krzk+dt, conor+dt, Frank.Li, s.hauer, kernel, festevam,
amitkumar.karwar, neeraj.sanjaykale, marcel, luiz.dentz,
hongxing.zhu, l.stach, lpieralisi, kwilczynski, mani, bhelgaas,
brgl, imx, linux-pci, linux-arm-kernel, devicetree, linux-kernel,
linux-bluetooth, linux-pm, sherry.sun
In-Reply-To: <20260626023126.2189931-2-sherry.sun@oss.nxp.com>
On Fri, Jun 26, 2026 at 10:31:19AM +0800, Sherry Sun (OSS) wrote:
> From: Sherry Sun <sherry.sun@nxp.com>
>
> Use dw_pcie_rp::skip_pwrctrl_off to avoid powering off devices during
> suspend to preserve wakeup capability of the devices and also not to power
> on the devices in the init path.
Need empty line here.
> This allows controller power-off to be skipped when some devices(e.g. M.2
> cards key E without auxiliary power) required to support PCIe L2 link state
> and wake-up mechanisms.
>
> Move pci_pwrctrl_create_devices() to imx_pcie_probe() so that it is only
> called once during probe, similar to other regulator_get calls.
>
> Signed-off-by: Sherry Sun <sherry.sun@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-imx6.c | 43 ++++++++++++++++-----------
> 1 file changed, 25 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-imx6.c b/drivers/pci/controller/dwc/pci-imx6.c
> index 0fa716d1ed75..0685573fee71 100644
> --- a/drivers/pci/controller/dwc/pci-imx6.c
> +++ b/drivers/pci/controller/dwc/pci-imx6.c
> @@ -1382,16 +1382,12 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> }
> }
>
> - ret = pci_pwrctrl_create_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to create pwrctrl devices\n");
> - goto err_reg_disable;
> - }
> -
Please two patch do that. one patch move pci_pwrctrl_create_devices() to
probe
one patch check skip_power_off.
> - ret = pci_pwrctrl_power_on_devices(dev);
> - if (ret) {
> - dev_err(dev, "failed to power on pwrctrl devices\n");
> - goto err_pwrctrl_destroy;
> + if (!pp->skip_pwrctrl_off) {
> + ret = pci_pwrctrl_power_on_devices(dev);
> + if (ret) {
> + dev_err(dev, "failed to power on pwrctrl devices\n");
> + goto err_reg_disable;
> + }
> }
>
> ret = imx_pcie_clk_enable(imx_pcie);
> @@ -1460,10 +1456,8 @@ static int imx_pcie_host_init(struct dw_pcie_rp *pp)
> err_clk_disable:
> imx_pcie_clk_disable(imx_pcie);
> err_pwrctrl_power_off:
> - pci_pwrctrl_power_off_devices(dev);
> -err_pwrctrl_destroy:
> - if (ret != -EPROBE_DEFER)
> - pci_pwrctrl_destroy_devices(dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(dev);
> err_reg_disable:
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> @@ -1482,7 +1476,8 @@ static void imx_pcie_host_exit(struct dw_pcie_rp *pp)
> }
> imx_pcie_clk_disable(imx_pcie);
>
> - pci_pwrctrl_power_off_devices(pci->dev);
> + if (!pci->pp.skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(pci->dev);
> if (imx_pcie->vpcie)
> regulator_disable(imx_pcie->vpcie);
> }
> @@ -1954,11 +1949,15 @@ static int imx_pcie_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> + ret = pci_pwrctrl_create_devices(dev);
> + if (ret)
> + return dev_err_probe(dev, ret, "failed to create pwrctrl devices\n");
> +
> pci->use_parent_dt_ranges = true;
> if (imx_pcie->drvdata->mode == DW_PCIE_EP_TYPE) {
> ret = imx_add_pcie_ep(imx_pcie, pdev);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> /*
> * FIXME: Only single Device (EPF) is supported due to the
> @@ -1973,7 +1972,7 @@ static int imx_pcie_probe(struct platform_device *pdev)
> pci->pp.use_atu_msg = true;
> ret = dw_pcie_host_init(&pci->pp);
> if (ret < 0)
> - return ret;
> + goto err_pwrctrl_destroy;
>
> if (pci_msi_enabled()) {
> u8 offset = dw_pcie_find_capability(pci, PCI_CAP_ID_MSI);
> @@ -1985,16 +1984,24 @@ static int imx_pcie_probe(struct platform_device *pdev)
> }
>
> return 0;
> +
> +err_pwrctrl_destroy:
> + if (ret != -EPROBE_DEFER)
> + pci_pwrctrl_destroy_devices(dev);
> + return ret;
Mani said he will fix DEFER problem soon.
Frank
> }
>
> static void imx_pcie_shutdown(struct platform_device *pdev)
> {
> struct imx_pcie *imx_pcie = platform_get_drvdata(pdev);
> + struct dw_pcie *pci = imx_pcie->pci;
> + struct dw_pcie_rp *pp = &pci->pp;
>
> /* bring down link, so bootloader gets clean state in case of reboot */
> imx_pcie_assert_core_reset(imx_pcie);
> imx_pcie_assert_perst(imx_pcie, true);
> - pci_pwrctrl_power_off_devices(&pdev->dev);
> + if (!pp->skip_pwrctrl_off)
> + pci_pwrctrl_power_off_devices(&pdev->dev);
> pci_pwrctrl_destroy_devices(&pdev->dev);
> }
>
> --
> 2.50.1
>
>
^ permalink raw reply
* Re: [GIT PULL] Devicetree fixes for v7.2, part 1
From: pr-tracker-bot @ 2026-06-26 20:01 UTC (permalink / raw)
To: Rob Herring
Cc: Linus Torvalds, Saravana Kannan, Krzysztof Kozlowski,
Conor Dooley, linux-kernel, devicetree
In-Reply-To: <20260626133834.GA2142045-robh@kernel.org>
The pull request you sent on Fri, 26 Jun 2026 08:38:34 -0500:
> ssh://git@gitolite.kernel.org/pub/scm/linux/kernel/git/robh/linux.git tags/devicetree-fixes-for-7.2-1
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/fc91b7d77d78c6381b437b7c96aca6b03f7bbfed
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH v6 2/2] Input: isa1200 - new driver for Imagis ISA1200
From: Dmitry Torokhov @ 2026-06-26 20:20 UTC (permalink / raw)
To: Svyatoslav Ryhel
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley, Linus Walleij,
linux-input, devicetree, linux-kernel
In-Reply-To: <CAPVz0n0Ja0eKrpirtMxK8bkTV0NY-UoKU0c09qLEF-xMWmOzKQ@mail.gmail.com>
On Fri, Jun 26, 2026 at 10:45:20AM +0300, Svyatoslav Ryhel wrote:
> пт, 26 черв. 2026 р. о 02:45 Dmitry Torokhov <dmitry.torokhov@gmail.com> пише:
> >
> > Hi Svyatoslav,
> >
> > On Wed, Jun 17, 2026 at 10:05:27AM +0300, Svyatoslav Ryhel wrote:
> > > From: Linus Walleij <linusw@kernel.org>
> > >
> > > The ISA1200 is a haptic feedback unit from Imagis Technology using two
> > > motors for haptic feedback in mobile phones. Used in many mobile devices
> > > c. 2012 including Samsung Galxy S Advance GT-I9070 (Janice), Samsung Beam
> > > GT-I8350 (Gavini), LG Optimus 4X P880 and LG Optimus Vu P895.
> > >
> > > The exact datasheet for the ISA1200 is not available; all data was modeled
> > > based on available downstream kernel sources for various devices and
> > > fragments of information scattered across the internet.
> > >
> > > Tested-by: Linus Walleij <linusw@kernel.org> # GT-I9070 Janice
> > > Signed-off-by: Linus Walleij <linusw@kernel.org>
> > > Co-developed-by: Svyatoslav Ryhel <clamor95@gmail.com>
> > > Signed-off-by: Svyatoslav Ryhel <clamor95@gmail.com>
> >
> >
> > Sashiko convinced me that using mutex_trylock() in the playback work
> > handler will result in dropping requests and that we are safe not taking
> > the lock there at all. Can you please try the following modification?
> >
> > diff --git a/drivers/input/misc/isa1200.c b/drivers/input/misc/isa1200.c
> > index c61adc4b605c..fb7f68fa0a2b 100644
> > --- a/drivers/input/misc/isa1200.c
> > +++ b/drivers/input/misc/isa1200.c
> > @@ -253,15 +253,12 @@ static void isa1200_stop(struct isa1200 *isa)
> > static void isa1200_play_work(struct work_struct *work)
> > {
> > struct isa1200 *isa = container_of(work, struct isa1200, play_work);
> > - struct input_dev *input = isa->input;
> > -
> > - scoped_guard(mutex_try, &input->mutex) {
> > - if (!isa->suspended) {
> > - if (isa->level)
> > - isa1200_start(isa);
> > - else
> > - isa1200_stop(isa);
> > - }
> > +
> > + if (!READ_ONCE(isa->suspended)) {
> > + if (isa->level)
> > + isa1200_start(isa);
> > + else
> > + isa1200_stop(isa);
> > }
> > }
> >
> >
> > If this works no need to resend, I'll fold on my side.
> >
>
> It does work fine. Thank you.
Excelled, thank you. Applied both patches.
--
Dmitry
^ permalink raw reply
* Re: [PATCH 4/4] drm/bridge: lontium-lt9611c: Add DSI port selection via DT property
From: Dmitry Baryshkov @ 2026-06-26 20:24 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-4-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:59AM +0530, Mohit Dsor wrote:
> Some board designs connect only DSI port B, or both DSI ports A and B,
> to the LT9611C. Add support for a 'lontium,port-select' DT property that
> allows the board DTS to specify which DSI port(s) the chip should use:
>
> 0 = PORT_SELECT_A (default, single DSI port A)
> 1 = PORT_SELECT_B (single DSI port B)
> 2 = PORT_SELECT_AB (dual DSI ports A+B)
>
> When the property is absent the driver defaults to PORT_SELECT_A (0),
> preserving backward compatibility with existing DTS files.
>
> The selected port is programmed into the chip via lt9611c_select_port()
> during probe, after the chip ID has been verified.
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
> drivers/gpu/drm/bridge/lontium-lt9611c.c | 44 ++++++++++++++++++++++++++++++++
> 1 file changed, 44 insertions(+)
>
No, existing LT9611 driver doesn't need extra properties to determine
which ports are being used. So, I gues, your driver doesn't need them
too. Follow the OF graph description and drop the property.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 2/4] drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
From: Dmitry Baryshkov @ 2026-06-26 20:25 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-2-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:57AM +0530, Mohit Dsor wrote:
> The on-chip MCU may take longer than 100ms to respond on some hardware
> variants or slower I2C buses, causing spurious -ETIMEDOUT errors during
> normal operation. Double the poll timeout from 100ms to 200ms to improve
> reliability without changing the poll interval.
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
Fixes, cc:stable.
> ---
> drivers/gpu/drm/bridge/lontium-lt9611c.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 3/4] drm-bridge: lontium lt9611c: fixes and improvements
From: Dmitry Baryshkov @ 2026-06-26 20:30 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-3-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:58AM +0530, Mohit Dsor wrote:
> Remove two redundant lt9611c_reset() calls:
>
> 1. In lt9611c_bridge_atomic_pre_enable(): a reset is already performed
> during probe and resume; calling it again on every display enable
> adds ~440ms of unnecessary latency.
>
> 2. At the end of lt9611c_probe(): a reset was already performed earlier
> in probe before lt9611c_lock(). The second reset is redundant.
>
> Also, the DRM HDMI bridge framework requires hdmi_write_hdmi_infoframe and
> hdmi_clear_hdmi_infoframe callbacks for HDMI vendor-specific infoframe
> (VSI) support, used for features such as HDR metadata signalling.
>
> This patch add stub implementations that return success. Wire them into the bridge
> function table.
>
> Also, Store the chip variant enum value in the of_match_table .data field and
> retrieve it via of_device_get_match_data() when probing from a DT node.
> Fall back to i2c_device_id.driver_data for non-DT (e.g. ACPI) probe
> paths.
>
> This is the standard kernel pattern for passing per-compatible data
> through the OF match table, and avoids relying solely on the I2C device
> ID table for chip type detection when DT is available.
>
> Populate bridge.vendor and bridge.product so the DRM HDMI framework can
> report the correct manufacturer and product name in the HDMI connector
> properties (visible via xrandr --prop and related sysfs entries).
I was going to write that this should be split into several commits, but
then... I stumbled upon a fact that the driver is not a part of the
drm-misc. So, instead of posting an update for the not-yet-merged
driver, please post new iteration of the LT9611C series. Don't forget to
drop the R-B tags where applicable.
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
> drivers/gpu/drm/bridge/lontium-lt9611c.c | 31 ++++++++++++++++++++++++++-----
> 1 file changed, 26 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/lontium-lt9611c.c b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> index b0402726367e..fe51f4978546 100644
> --- a/drivers/gpu/drm/bridge/lontium-lt9611c.c
> +++ b/drivers/gpu/drm/bridge/lontium-lt9611c.c
> @@ -622,7 +622,6 @@ static void lt9611c_bridge_atomic_pre_enable(struct drm_bridge *bridge,
> ret = regulator_bulk_enable(ARRAY_SIZE(lt9611c->supplies), lt9611c->supplies);
> if (ret)
> dev_err(lt9611c->dev, "regulator bulk enable failed.\n");
> - lt9611c_reset(lt9611c);
> }
>
> static void lt9611c_bridge_atomic_enable(struct drm_bridge *bridge,
> @@ -777,6 +776,17 @@ static int lt9611c_hdmi_clear_avi_infoframe(struct drm_bridge *bridge)
> return 0;
> }
>
> +static int lt9611c_hdmi_write_hdmi_infoframe(struct drm_bridge *bridge,
> + const u8 *buffer, size_t len)
> +{
> + return 0;
> +}
> +
> +static int lt9611c_hdmi_clear_hdmi_infoframe(struct drm_bridge *bridge)
> +{
> + return 0;
> +}
Definite NAK. The purpose of the callbacks is to write the infoframe.
Purpose of the check in the DRM framework is to ensure that the frame is
actually written. Please work with Lontium and find a way to write HDMI
/ HVS, SPD and HDR infoframes.
> +
> static int lt9611c_hdmi_write_audio_infoframe(struct drm_bridge *bridge,
> const u8 *buffer, size_t len)
> {
> @@ -895,6 +905,8 @@ static const struct drm_bridge_funcs lt9611c_bridge_funcs = {
> .hdmi_tmds_char_rate_valid = lt9611c_hdmi_tmds_char_rate_valid,
> .hdmi_write_avi_infoframe = lt9611c_hdmi_write_avi_infoframe,
> .hdmi_clear_avi_infoframe = lt9611c_hdmi_clear_avi_infoframe,
> + .hdmi_write_hdmi_infoframe = lt9611c_hdmi_write_hdmi_infoframe,
> + .hdmi_clear_hdmi_infoframe = lt9611c_hdmi_clear_hdmi_infoframe,
> .hdmi_write_audio_infoframe = lt9611c_hdmi_write_audio_infoframe,
> .hdmi_clear_audio_infoframe = lt9611c_hdmi_clear_audio_infoframe,
>
> @@ -1025,6 +1037,13 @@ static int lt9611c_probe(struct i2c_client *client)
> lt9611c->dev = dev;
> lt9611c->client = client;
> lt9611c->chip_type = id->driver_data;
> +
> + if (dev->of_node) {
> + lt9611c->chip_type = (uintptr_t)of_device_get_match_data(dev);
> + } else {
> + lt9611c->chip_type = id->driver_data;
> + }
Use i2c_get_match_data(). But, also, why? The driver will likely not
work w/o the OF in place, there is little point in doing something else.
> +
> ret = devm_mutex_init(dev, <9611c->ocm_lock);
> if (ret)
> return dev_err_probe(dev, ret, "failed to init mutex\n");
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH 0/4] (no cover subject)
From: Dmitry Baryshkov @ 2026-06-26 20:32 UTC (permalink / raw)
To: Mohit Dsor
Cc: Andrzej Hajda, Neil Armstrong, Robert Foss, Laurent Pinchart,
Jonas Karlman, Jernej Skrabec, Luca Ceresoli, David Airlie,
Simona Vetter, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Vinod Koul, dri-devel, devicetree, linux-kernel, boss,
qc-display-maintainer
In-Reply-To: <20260611-lt9611-b4-send-v1-0-42abbcd3bb1e@oss.qualcomm.com>
On Thu, Jun 11, 2026 at 02:44:55AM +0530, Mohit Dsor wrote:
> From: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> Subject: [PATCH 0/4] LT9611C improvements and fixes updates
Heh. Is there a reason why you don't follow the internal docs and don't
use b4 tool?
>
> Hi,
>
> This series contains improvements and fixes for the Lontium LT9611C
> MIPI DSI to HDMI bridge driver, along with DT binding updates.
>
> The key addition is support for selecting the DSI input port using
> a new device tree property, which is required for configurations
> using port B or dual-port (A+B) operation.
>
> Summary of changes:
> - Add DSI port selection support via DT property
> - Fixes and improvements
> - Increase MCU polling timeout for stability
>
> - Add dt-binding for port configuration
>
> Patches:
>
> 1. dt-bindings: bridge: lt9611c: add port-select property for LT9611C
> 2. drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
> 3. drm-bridge: lontium lt9611c: fixes and improvements
> 4. drm/bridge: lontium-lt9611c: Add DSI port selection via DT property
This is written several lines below. No need to repeat it again and
again.
>
> This has been tested on LT9611C-based platforms.
> Please review.
>
> Thanks,
> Mohit
>
> Signed-off-by: Mohit Dsor <mohit.dsor@oss.qualcomm.com>
> ---
> Mohit Dsor (4):
> dt-bindings: brige: lt9611c: add port-select property for LT9611C
> drm/bridge: lontium-lt9611c: Increase MCU poll timeout to 200ms
> drm-bridge: lontium lt9611c: fixes and improvements
> drm/bridge: lontium-lt9611c: Add DSI port selection via DT property
>
> .../bindings/display/bridge/lontium,lt9611.yaml | 13 ++++
> drivers/gpu/drm/bridge/lontium-lt9611c.c | 79 ++++++++++++++++++++--
> 2 files changed, 85 insertions(+), 7 deletions(-)
> ---
> base-commit: 7b61c580d964f499f3eaf96d6579a7127dda606b
> change-id: 20260611-lt9611-b4-send-6f1d39c2d6d7
> prerequisite-message-id: <20260420061644.1251070-1-syyang@lontium.com>
> prerequisite-patch-id: 5e0ea8907c87174a28fac5456fc51183d8e8b36f
> prerequisite-patch-id: 6fd8685174c2c83b8871d9e6419c6f3bd29ccc1a
Well... The series is not merged. With these issues it is unlikely that
it will be merged. Please work with the authors from Lontium to
incorporate your changes.
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v3 2/2] drm/panel: add Ilitek ILI7807S panel driver
From: Dmitry Baryshkov @ 2026-06-26 20:41 UTC (permalink / raw)
To: Arpit Saini
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, linux-arm-msm, dri-devel,
devicetree, linux-kernel, ayushi.makhija, rajeevny
In-Reply-To: <20260624-ili7807s-v3-2-ddf37052a289@oss.qualcomm.com>
On Wed, Jun 24, 2026 at 02:23:52PM +0530, Arpit Saini wrote:
> Add a DRM panel driver for the DLC DLC0697 1080x1920@60Hz MIPI DSI
> panel based on the Ilitek ILI7807S display controller.
>
> The panel operates in video burst mode with four data lanes using
> RGB888 pixel format.
>
> Signed-off-by: Arpit Saini <arpit.saini@oss.qualcomm.com>
> ---
> drivers/gpu/drm/panel/Kconfig | 12 ++
> drivers/gpu/drm/panel/Makefile | 1 +
> drivers/gpu/drm/panel/panel-ilitek-ili7807s.c | 293 ++++++++++++++++++++++++++
> 3 files changed, 306 insertions(+)
>
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 7450b27622a2..1cbaac1bf545 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -264,6 +264,18 @@ config DRM_PANEL_HYDIS_HV101HD1
>
> If M is selected the module will be called panel-hydis-hv101hd1
>
> +config DRM_PANEL_ILITEK_ILI7807S
> + tristate "Ilitek ILI7807S-based panels"
> + depends on OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> + Say Y if you want to enable support for panels based on the
> + Ilitek ILI7807S display controller, such as the DLC DLC0697
> + 1080x1920 MIPI DSI panel.
> +
> + If M is selected the module will be called panel-ilitek-ili7807s.
> +
> config DRM_PANEL_ILITEK_IL9322
> tristate "Ilitek ILI9322 320x240 QVGA panels"
> depends on OF && SPI
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index c2c5cf817116..c3002b351cb8 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -26,6 +26,7 @@ obj-$(CONFIG_DRM_PANEL_HIMAX_HX83112B) += panel-himax-hx83112b.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX83121A) += panel-himax-hx83121a.o
> obj-$(CONFIG_DRM_PANEL_HIMAX_HX8394) += panel-himax-hx8394.o
> obj-$(CONFIG_DRM_PANEL_HYDIS_HV101HD1) += panel-hydis-hv101hd1.o
> +obj-$(CONFIG_DRM_PANEL_ILITEK_ILI7807S) += panel-ilitek-ili7807s.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_IL9322) += panel-ilitek-ili9322.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9341) += panel-ilitek-ili9341.o
> obj-$(CONFIG_DRM_PANEL_ILITEK_ILI9805) += panel-ilitek-ili9805.o
> diff --git a/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c b/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c
> new file mode 100644
> index 000000000000..8ddfab2693ec
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-ilitek-ili7807s.c
> @@ -0,0 +1,293 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) Qualcomm Technologies, Inc. and/or its subsidiaries.
> + */
> +
> +#include <linux/backlight.h>
> +#include <linux/delay.h>
> +#include <linux/gpio/consumer.h>
> +#include <linux/module.h>
> +#include <linux/of.h>
> +#include <linux/regulator/consumer.h>
> +
> +#include <drm/drm_mipi_dsi.h>
> +#include <drm/drm_modes.h>
> +#include <drm/drm_panel.h>
> +#include <drm/drm_probe_helper.h>
> +
> +struct panel_desc {
> + const struct drm_display_mode *mode;
> + unsigned int lanes;
> + enum mipi_dsi_pixel_format format;
> + unsigned long mode_flags;
> + void (*init)(struct mipi_dsi_multi_context *dsi_ctx);
> +};
> +
> +struct ili7807s {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + const struct panel_desc *desc;
> +
> + struct regulator_bulk_data *supplies;
> + struct gpio_desc *reset_gpio;
> +};
> +
> +static const struct regulator_bulk_data ili7807s_supplies[] = {
> + { .supply = "vddi" },
> + { .supply = "avdd" },
> + { .supply = "avee" },
> +};
> +
> +static inline struct ili7807s *to_ili7807s(struct drm_panel *panel)
> +{
> + return container_of(panel, struct ili7807s, panel);
> +}
> +
> +static void ili7807s_reset(struct ili7807s *ctx)
> +{
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> + usleep_range(10000, 11000);
> + gpiod_set_value_cansleep(ctx->reset_gpio, 0);
> + usleep_range(10000, 11000);
This looks like the reset being active-low. Please define it as is in
the DT and use normal (hold = 1, drop = 0) semantics in the driver.
> +}
> +
> +static void dlc0697_init_sequence(struct mipi_dsi_multi_context *dsi_ctx)
> +{
> + mipi_dsi_dcs_soft_reset_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 120);
> +
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0xff, 0x78, 0x07, 0x00);
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x35, 0x00);
mipi_dsi_dcs_set_tear_on_multi()
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x5e, 0x09, 0x99);
MIPI_DCS_SET_CABC_MIN_BRIGHTNESS
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x53, 0x24);
MIPI_DCS_WRITE_CONTROL_DISPLAY
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x55, 0x01);
MIPI_DCS_WRITE_POWER_SAVE
> + mipi_dsi_dcs_write_seq_multi(dsi_ctx, 0x51, 0x3f, 0xff);
mipi_dsi_dcs_set_display_brightness_large_multi(). Also please use
0x1fff instead of the full brightness.
> +
> + mipi_dsi_dcs_exit_sleep_mode_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 120);
> +
> + mipi_dsi_dcs_set_display_on_multi(dsi_ctx);
> + mipi_dsi_msleep(dsi_ctx, 20);
> +}
> +
> +static int ili7807s_on(struct ili7807s *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
Drop, set it in probe()
> +
> + ctx->desc->init(&dsi_ctx);
> +
> + ctx->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
Drop
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ili7807s_off(struct ili7807s *ctx)
> +{
> + struct mipi_dsi_multi_context dsi_ctx = { .dsi = ctx->dsi };
> +
> + ctx->dsi->mode_flags |= MIPI_DSI_MODE_LPM;
Drop
> +
> + mipi_dsi_dcs_set_display_off_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 20);
> +
> + mipi_dsi_dcs_enter_sleep_mode_multi(&dsi_ctx);
> + mipi_dsi_msleep(&dsi_ctx, 120);
> +
> + ctx->dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
Drop
> +
> + return dsi_ctx.accum_err;
> +}
> +
> +static int ili7807s_prepare(struct drm_panel *panel)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> + int ret;
> +
> + ret = regulator_bulk_enable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> + if (ret < 0) {
> + dev_err(ctx->panel.dev, "failed to enable regulators: %d\n", ret);
> + return ret;
> + }
> +
> + msleep(20);
> +
> + ili7807s_reset(ctx);
> +
> + ret = ili7807s_on(ctx);
> + if (ret < 0) {
> + dev_err(ctx->panel.dev, "failed to initialise panel: %d\n", ret);
> + goto err;
> + }
> +
> + return 0;
> +
> +err:
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + regulator_bulk_disable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> + return ret;
> +}
> +
> +static int ili7807s_unprepare(struct drm_panel *panel)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> + int ret;
> +
> + ret = ili7807s_off(ctx);
> + if (ret < 0)
> + dev_err(ctx->panel.dev, "failed to disable panel: %d\n", ret);
> +
> + gpiod_set_value_cansleep(ctx->reset_gpio, 1);
> +
> + regulator_bulk_disable(ARRAY_SIZE(ili7807s_supplies), ctx->supplies);
> +
> + return 0;
> +}
> +
> +static int ili7807s_get_modes(struct drm_panel *panel,
> + struct drm_connector *connector)
> +{
> + struct ili7807s *ctx = to_ili7807s(panel);
> +
> + return drm_connector_helper_get_modes_fixed(connector, ctx->desc->mode);
> +}
> +
> +static const struct drm_panel_funcs ili7807s_panel_funcs = {
> + .prepare = ili7807s_prepare,
> + .unprepare = ili7807s_unprepare,
> + .get_modes = ili7807s_get_modes,
> +};
> +
> +static int ili7807s_bl_update_status(struct backlight_device *bl)
> +{
> + struct mipi_dsi_device *dsi = bl_get_data(bl);
> + u16 brightness = backlight_get_brightness(bl);
> + int ret;
> +
> + dsi->mode_flags &= ~MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_display_brightness_large(dsi, brightness);
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + return ret;
> +}
> +
> +static const struct backlight_ops ili7807s_bl_ops = {
> + .update_status = ili7807s_bl_update_status,
> +};
> +
> +static struct backlight_device *ili7807s_create_backlight(struct mipi_dsi_device *dsi)
> +{
> + struct device *dev = &dsi->dev;
> + const struct backlight_properties props = {
> + .type = BACKLIGHT_RAW,
> + .brightness = 0x3fff,
> + .max_brightness = 0x3fff,
> + };
> +
> + return devm_backlight_device_register(dev, dev_name(dev), dev, dsi,
> + &ili7807s_bl_ops, &props);
> +}
> +
> +static const struct drm_display_mode dlc0697_mode = {
> + .clock = 131911,
= (1080 + 18 + 2 + 16) * (1920 + 26 + 4 + 20) * 60 / 1000
> +
> + .hdisplay = 1080,
> + .hsync_start = 1080 + 18,
> + .hsync_end = 1080 + 18 + 2,
> + .htotal = 1080 + 18 + 2 + 16,
> +
> + .vdisplay = 1920,
> + .vsync_start = 1920 + 26,
> + .vsync_end = 1920 + 26 + 4,
> + .vtotal = 1920 + 26 + 4 + 20,
> +
> + .width_mm = 0,
> + .height_mm = 0,
Do you really don't know the dimensions of the panel you are
contributing?
> + .type = DRM_MODE_TYPE_DRIVER | DRM_MODE_TYPE_PREFERRED,
> +};
> +
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 0/3] arm64: dts: qcom: kodiak: Enable 4-lane DP via QMP Combo PHY
From: Dmitry Baryshkov @ 2026-06-26 20:49 UTC (permalink / raw)
To: Konrad Dybcio
Cc: Doug Anderson, Bjorn Andersson, Mahadevan P, Konrad Dybcio,
Rob Herring, Krzysztof Kozlowski, Conor Dooley,
cros-qcom-dts-watchers, linux-arm-msm, devicetree, linux-kernel,
Mahadevan P, Stephen Boyd
In-Reply-To: <d4641613-dcf0-4437-9aaf-dede83afe04b@oss.qualcomm.com>
On Fri, Jun 26, 2026 at 06:02:12PM +0200, Konrad Dybcio wrote:
> On 6/22/26 12:11 AM, Doug Anderson wrote:
> > Hi,
> >
> > On Fri, Jun 19, 2026 at 8:34 AM Konrad Dybcio
> > <konrad.dybcio@oss.qualcomm.com> wrote:
>
> [...]
>
>
> >>>
> >>> Are you sure that herobrine has 4 lanes routed on the PCB?
> >>
> >> +Doug any chance you still have schematics for that old boy?
> >>
> >> Bjorn, perhaps we could switch to a model where we define the max
> >> capabilities (i.e. 4-lane 8.1 GHz link) in the SoC DTs and only limit
> >> them as necessary? Not meeting these is borderline a board defect anyway
> >
> > Bleh, I'd forgotten what a pain it was to look at herobrine schematics
> > with the whole qcard "abstraction".
> >
> > My memory and a quick glance at schematics makes me say that herobrine
> > only has 2 lanes of DP. The problem is that this SoC really wasn't
> > designed with a laptop in mind. I seem to remember there only being
> > one USB 3 port and it is muxed with two of the DP lanes (since the SoC
> > is designed to drive a single Type-C port). In order to support all of
> > the ports that a laptop should have, you pretty much need to feed that
> > one USB 3 port into a USB hub and hardcode the DP to always use two
> > lanes.
This matches my memory and the abstractions that Stephen has been trying
to implement.
> >
> > The two DP lanes then go to a mux where they can be routed either
> > towards the left Type C port or the right Type C port.
> >
> > In terms of whether we can support the 8.1 GHz link speed, I remember
> > much debate during the project, but I don't recall all the details. I
> > think the discussion was that we were supposed to support the higher
> > speeds, but we had to disable them because they weren't working. From
> > my fuzzy memory, it was unclear whether the problem was known to be
> > hardware or software related. I can try to dig deeper if it's
> > relevant.
>
> If anyone still has herobrine easily accessible, I guess a smoke test
> with a high res display and this:
I remember that it was not stable. HBR3 worked in some cases and didn't
in the other cases. So, I'd rather not touch the old grampa and leave it
as is.
>
> diff --git a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> index 5c5e4f1dd221..a39e418fdabb 100644
> --- a/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> +++ b/arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi
> @@ -464,7 +464,7 @@ &mdss_dp {
>
> &mdss_dp_out {
> data-lanes = <0 1>;
> - link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000>;
> + link-frequencies = /bits/ 64 <1620000000 2700000000 5400000000 8100000000>;
> };
>
> /* NVMe drive, enabled on a per-board basis */
>
> would be the quickest way to confirm that. Although we can just leave
> it as-is if it's problematic.. I think you said there's some folks that
> still use it a couple years ago
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 2/3] arm64: dts: qcom: kodiak: move dp data-lanes to SoC dtsi
From: Dmitry Baryshkov @ 2026-06-26 20:50 UTC (permalink / raw)
To: Mahadevan P
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, cros-qcom-dts-watchers, linux-arm-msm, devicetree,
linux-kernel, Mahadevan P
In-Reply-To: <20260429-kodiak_v2-v2-2-c3a703cc30eb@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 12:10:41PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
>
> The connection between the QMP Combo PHY and the DisplayPort controller
> is fixed in SoC, so move the data-lanes property to kodiak.dtsi and
> drop the per-board overrides.
>
> Also remove the redundant remote-endpoint cross-links and
> orientation-switch property from qcs6490-rb3gen2 and
> qcs6490-thundercomm-rubikpi3, which are already defined in kodiak.dtsi.
Separate commit.
>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 1 +
> arch/arm64/boot/dts/qcom/qcm6490-fairphone-fp5.dts | 4 ----
> arch/arm64/boot/dts/qcom/qcm6490-particle-tachyon.dts | 4 ----
> arch/arm64/boot/dts/qcom/qcs6490-rb3gen2.dts | 11 -----------
> arch/arm64/boot/dts/qcom/qcs6490-thundercomm-minipc-g1iot.dts | 1 -
> arch/arm64/boot/dts/qcom/qcs6490-thundercomm-rubikpi3.dts | 3 ---
> arch/arm64/boot/dts/qcom/sc7280-herobrine.dtsi | 1 -
> 7 files changed, 1 insertion(+), 24 deletions(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 96ac3656ab5a..0acc6917d7aa 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,6 +5704,7 @@ dp_in: endpoint {
> port@1 {
> reg = <1>;
> mdss_dp_out: endpoint {
> + data-lanes = <0 1>;
This is not true. The SoC has 4 lanes going from the DP controller to
the QMP PHY.
> remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> };
> };
--
With best wishes
Dmitry
^ permalink raw reply
* Re: [PATCH v2 3/3] arm64: dts: qcom: kodiak: Set up 4-lane DP
From: Dmitry Baryshkov @ 2026-06-26 20:51 UTC (permalink / raw)
To: Mahadevan P
Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, cros-qcom-dts-watchers, linux-arm-msm, devicetree,
linux-kernel, Mahadevan P
In-Reply-To: <20260429-kodiak_v2-v2-3-c3a703cc30eb@oss.qualcomm.com>
On Wed, Apr 29, 2026 at 12:10:42PM +0530, Mahadevan P wrote:
> From: Mahadevan P <mahap@qti.qualcomm.com>
>
> Allow up to 4 lanes for the DisplayPort link from the PHY to the
> controller now the mode-switch events can reach the QMP Combo PHY.
>
> Signed-off-by: Mahadevan P <mahadevan.p@oss.qualcomm.com>
> ---
> arch/arm64/boot/dts/qcom/kodiak.dtsi | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/kodiak.dtsi b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> index 0acc6917d7aa..204513a6bd89 100644
> --- a/arch/arm64/boot/dts/qcom/kodiak.dtsi
> +++ b/arch/arm64/boot/dts/qcom/kodiak.dtsi
> @@ -5704,7 +5704,7 @@ dp_in: endpoint {
> port@1 {
> reg = <1>;
> mdss_dp_out: endpoint {
> - data-lanes = <0 1>;
> + data-lanes = <0 1 2 3>;
So, basically, you've force-enabled 4 lanes for all devices, even though
they had 2 lanes enabled only. Don't do that. Squash it to the previous
commit and enable carefully, only for the platforms where you actually
know that there are 4 DP lanes to be used.
> remote-endpoint = <&usb_dp_qmpphy_dp_in>;
> };
> };
>
> --
> 2.34.1
>
--
With best wishes
Dmitry
^ permalink raw reply
* [PATCH v8 03/29] phy: rockchip: usbdp: Do not lose USB3 PHY status
From: Sebastian Reichel @ 2026-06-26 20:54 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@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 a5ffdf7a6e76..12dfdd470a78 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1008,7 +1008,6 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
rk_udphy_u3_port_disable(udphy, false);
udphy->mode_change = false;
} else if (udphy->mode_change) {
- 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
* [PATCH v8 01/29] dt-bindings: phy: rockchip-usbdp: add improved ports scheme
From: Sebastian Reichel @ 2026-06-26 20:54 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@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 v8 00/29] phy: rockchip: usbdp: Fixes, DP 1-lane support and cleanups
From: Sebastian Reichel @ 2026-06-26 20:54 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, Sashiko, 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.
Apart from that it also fixes a bunch of issues pointed out by
Sashiko (mostly harmless), as well as some real problems. Among
other things it should help drastically with orientation switch
problems and potential SErrors when a USB-C device is hot-plugged.
With this series applied, I did not notice any SErrors. What I do see is
cmn ana lcpll lock timeouts after a few replugs, which are permanent
(i.e. it still happens when re-trying to init the PHY after running into
the timeout). After a reboot the problem is gone. It seems the dynamic
USB3 disabling increased the chance a lot to hit this problem. I think
this is better than the current status where Serrors can appear on hotplug
due to the re-init. Unfortunately LCPLL is more or less undocumented in
the TRM, so it is hard to figure out what is going on exactly.
Changes in v8:
- Link to v7: https://lore.kernel.org/r/20260625-rockchip-usbdp-cleanup-v7-0-38eb3cf654fd@collabora.com
- Move patch "Limit DP lane count to muxed lanes" after single lane
support, which introduces dp_lanes variable to make sure series
is bi-sectable (Sashiko)
- Force disable HPD in "Drop seamless DP takeover" patch and update
patch description to mention potential issues with SErrors for
bootloaders really keeping the DW-DP on. As mentioned in the new
commit message this is untested as I'm not aware of such a
bootloader anyways; this also means we need to keep the HPD GRF
register defines in the 'Drop DP HPD handling' patch (Sashiko)
- Fix mode logic in "Properly handle TYPEC_STATE_SAFE and
TYPEC_STATE_USB" patch; I blame the heat (Sashiko)
- Improve "Support going from DP-only mode to USB mode" patch to
better handle starting in DP only mode; due to TypeC logic
starting delayed this does not really happen, though (Sashiko)
- Improve "Support going from DP-only mode to USB mode" to avoid
checking previous state and instead power on USB state based
on previous requested state to avoid effects from the flip
callback (Sashiko)
- Update the debug message patch to include some more info
- Ad one more patch, which disables USB3 at startup and drops
the -EPROBE_DEFER logic
Changes in v7:
- Link to v6: https://lore.kernel.org/r/20260619-rockchip-usbdp-cleanup-v6-0-3bb1f54b3f35@collabora.com
- Add new patch handling missing clock-names in DT gracefully (Sashiko)
- Add new patch handling rk_udphy_reset_deassert_all errors in init check (Sashiko)
- Add new patch to handle Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB (Sashiko)
- Add new patch to avoid xHCI SErrors
Changes in v6:
- Link to v5: https://lore.kernel.org/r/20260612-rockchip-usbdp-cleanup-v5-0-efc83069869f@collabora.com
- Add explicit <linux/string_choices.h> include in last patch (Sashiko)
- Add new patch moving mode_change update after error handling (Sashiko)
- Add new patch fixing error masking of devm_clk_bulk_get_all() (Sashiko)
- Add new patch dropping seamless DP takeover as it is non-functional and buggy (Sashiko)
- Add new patch limiting DP lane count to muxed lanes (Sashiko)
- Add error handling in the patch that keeps clocks running on PHY re-init (Sashiko)
- Also look for DP being configured to second lane for the flip config
in DP single-lane mode, which should at least keep USB working for
this super unusual config (Sashiko)
- Drop useless ret variable in patch introducing guard() for the mutex
- Add error handling for PHY re-enablement in the patch fixing support for
DP-only -> USB mode (Sashiko)
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 (26):
dt-bindings: phy: rockchip-usbdp: add improved ports scheme
phy: rockchip: usbdp: Update mode_change after error handling
phy: rockchip: usbdp: Do not lose USB3 PHY status
phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
phy: rockchip: usbdp: Handle missing clock-names DT property gracefully
phy: rockchip: usbdp: Drop seamless DP takeover
phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check
phy: rockchip: usbdp: Keep clocks running on PHY re-init
phy: rockchip: usbdp: Add missing mode_change update
phy: rockchip: usbdp: Limit DP lane count to muxed lanes
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: Properly handle TYPEC_STATE_SAFE and TYPEC_STATE_USB
phy: rockchip: usbdp: Use guard functions for mutex
phy: rockchip: usbdp: Support going from DP-only mode to USB mode
phy: rockchip: usbdp: Clear USB status on PHY exit
phy: rockchip: usbdp: Hold mutex in DP PHY configure
phy: rockchip: usbdp: Add some extra debug messages
phy: rockchip: usbdp: Avoid xHCI SErrors
phy: rockchip: usbdp: Disable USB3 on probe
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 | 427 ++++++++++-----------
3 files changed, 231 insertions(+), 221 deletions(-)
---
base-commit: 4edcdefd4083ae04b1a5656f4be6cd83ae919ef4
change-id: 20260203-rockchip-usbdp-cleanup-5b59dfb561a3
Best regards,
--
Sebastian Reichel <sebastian.reichel@collabora.com>
^ permalink raw reply
* [PATCH v8 02/29] phy: rockchip: usbdp: Update mode_change after error handling
From: Sebastian Reichel @ 2026-06-26 20:54 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, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
If rk_udphy_init() or rk_udphy_setup() fails, the reinit will not be
tried again. Fix this by only updating the variable after all potential
errors have been handled.
Note, that no errors have been seen on real hardware and failures would
most likely be fatal and require at least a full reboot as the function
already asserts the PHY reset lines. So this is more of a theoretical
issue.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612163835.8D5471F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index fba35510d88c..a5ffdf7a6e76 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1000,15 +1000,14 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
}
if (udphy->status == UDPHY_MODE_NONE) {
- udphy->mode_change = false;
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
if (udphy->mode & UDPHY_MODE_USB)
rk_udphy_u3_port_disable(udphy, false);
- } else if (udphy->mode_change) {
udphy->mode_change = false;
+ } else if (udphy->mode_change) {
udphy->status = UDPHY_MODE_NONE;
if (udphy->mode == UDPHY_MODE_DP)
rk_udphy_u3_port_disable(udphy, true);
@@ -1017,6 +1016,7 @@ static int rk_udphy_power_on(struct rk_udphy *udphy, u8 mode)
ret = rk_udphy_setup(udphy);
if (ret)
return ret;
+ udphy->mode_change = false;
}
udphy->status |= mode;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 04/29] phy: rockchip: usbdp: Fix devm_clk_bulk_get_all check
From: Sebastian Reichel @ 2026-06-26 20:54 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, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
If devm_clk_bulk_get_all() returns -EPROBE_DEFER, it is replaced with
-ENODEV, permanently failing the driver probe instead of allowing it to
defer. Avoid masking the error code to fix the issue.
This effectively drops returning -ENODEV in case no clocks are being
described in DT. This special case will now be handled by the follow-up
check searching for "refclk" and exit with -EINVAL.
None of this will be hit in practice, since the driver is only used by
RK3588 and RK3576 - on these platforms the DT is validated to contain
the clocks and the clock driver is force probed early. Thus there is
no need to backport this.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 12dfdd470a78..2845a012eafc 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -427,8 +427,8 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
int i;
udphy->num_clks = devm_clk_bulk_get_all(dev, &udphy->clks);
- if (udphy->num_clks < 1)
- return -ENODEV;
+ if (udphy->num_clks < 0)
+ return udphy->num_clks;
/* used for configure phy reference clock frequency */
for (i = 0; i < udphy->num_clks; i++) {
--
2.53.0
^ permalink raw reply related
* [PATCH v8 05/29] phy: rockchip: usbdp: Handle missing clock-names DT property gracefully
From: Sebastian Reichel @ 2026-06-26 20:54 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, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
The rk_udphy_clk_init() function would currently try to do a strncmp for
a NULL pointer, if DT specifies 'clocks' property, but no 'clock-names'
property. Fix this by making sure the clock has an id string set.
Note that DT binding requires setting clock-names, so this is only a
problem when booting a non-compliant device tree.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/message/20260619154349.071321F000E9%40smtp.kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 2845a012eafc..3fc8222fcaec 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -432,6 +432,9 @@ static int rk_udphy_clk_init(struct rk_udphy *udphy, struct device *dev)
/* used for configure phy reference clock frequency */
for (i = 0; i < udphy->num_clks; i++) {
+ if (!udphy->clks[i].id)
+ continue;
+
if (!strncmp(udphy->clks[i].id, "refclk", 6)) {
udphy->refclk = udphy->clks[i].clk;
break;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 08/29] phy: rockchip: usbdp: Keep clocks running on PHY re-init
From: Sebastian Reichel @ 2026-06-26 20:55 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@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 b8de0a47a616..7fb7e4669f9d 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -1020,8 +1020,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;
udphy->mode_change = false;
--
2.53.0
^ permalink raw reply related
* [PATCH v8 06/29] phy: rockchip: usbdp: Drop seamless DP takeover
From: Sebastian Reichel @ 2026-06-26 20:54 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, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
Right now the DRM drivers do not support seamless DP takeover and I'm
I'm not aware of any bootloader implementing this feature either.
In any case this feature would be limited to boards using the USBDP PHY
for a DP or eDP connection instead of the more commonly USB-C connector.
With USB-C's DP AltMode a seamless DP takeover requires handing over the
state of the TCPM state machine from the bootloader to the kernel. This
in turn requires a huge amount of work to keep the state machine
implementations synchronized. It's very unlikely we will see somebody
implementing that in the foreseeable future.
As the current code is obviously buggy and untested, let's simply drop
support for seamless DP takeover. It can be re-implemented cleanly once
somebody adds all missing bits.
Technically the VOP side should be disabled first to avoid data being
send to an unpowered PHY from the running pipeline. As a workaround this
force disables HPD. I'm not sure if this would be good enough, but cannot
test as there is no support in the bootloaders known to me and my test
boards route USBDP to USB-C connectors.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://lore.kernel.org/linux-phy/20260612164107.C7DB21F000E9@smtp.kernel.org/
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 11 +++++++----
1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 3fc8222fcaec..f7ff55f03b7c 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -926,6 +926,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
{
+ const struct rk_udphy_cfg *cfg = udphy->cfgs;
int ret;
u32 value;
@@ -938,10 +939,12 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
rk_udphy_reset_deassert_all(udphy);
regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value);
- if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value))
- udphy->status = UDPHY_MODE_DP;
- else
- rk_udphy_disable(udphy);
+ if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value)) {
+ dev_info(udphy->dev, "Started with DP PHY pre-enabled; seamless takeover unsupported\n");
+ rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, false);
+ }
+
+ rk_udphy_disable(udphy);
return 0;
}
--
2.53.0
^ permalink raw reply related
* [PATCH v8 09/29] phy: rockchip: usbdp: Amend SSC modulation deviation
From: Sebastian Reichel @ 2026-06-26 20:55 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
From: Frank Wang <frank.wang@rock-chips.com>
Move SSC modulation deviation into private config of clock
- 24M: 0x00d4[5:0] = 0x30
- 26M: 0x00d4[5:0] = 0x33
Signed-off-by: Frank Wang <frank.wang@rock-chips.com>
[Taken over from rockchip's kernel tree; register 0x00d4 is not
described in the TRM]
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 7fb7e4669f9d..2aa9ccabf80b 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -350,7 +350,8 @@ static const struct reg_sequence rk_udphy_24m_refclk_cfg[] = {
{0x0a64, 0xa8}, {0x1a3c, 0xd0},
{0x1a44, 0xd0}, {0x1a48, 0x01},
{0x1a4c, 0x0d}, {0x1a54, 0xe0},
- {0x1a5c, 0xe0}, {0x1a64, 0xa8}
+ {0x1a5c, 0xe0}, {0x1a64, 0xa8},
+ {0x00d4, 0x30}
};
static const struct reg_sequence rk_udphy_26m_refclk_cfg[] = {
@@ -377,7 +378,7 @@ static const struct reg_sequence rk_udphy_26m_refclk_cfg[] = {
{0x0c30, 0x0e}, {0x0c48, 0x06},
{0x1c30, 0x0e}, {0x1c48, 0x06},
{0x028c, 0x18}, {0x0af0, 0x00},
- {0x1af0, 0x00}
+ {0x1af0, 0x00}, {0x00d4, 0x33}
};
static const struct reg_sequence rk_udphy_init_sequence[] = {
@@ -412,8 +413,7 @@ static const struct reg_sequence rk_udphy_init_sequence[] = {
{0x0070, 0x7d}, {0x0074, 0x68},
{0x0af4, 0x1a}, {0x1af4, 0x1a},
{0x0440, 0x3f}, {0x10d4, 0x08},
- {0x20d4, 0x08}, {0x00d4, 0x30},
- {0x0024, 0x6e},
+ {0x20d4, 0x08}, {0x0024, 0x6e}
};
static inline int rk_udphy_grfreg_write(struct regmap *base,
--
2.53.0
^ permalink raw reply related
* [PATCH v8 10/29] phy: rockchip: usbdp: Fix LFPS detect threshold control
From: Sebastian Reichel @ 2026-06-26 20:55 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
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
From: William Wu <william.wu@rock-chips.com>
According to the LFPS Tx Low Power/LFPS Rx Detect Threshold [1],
the device under test(DUT) must not respond if LFPS below the
minimum LFPS Rx Detect Threshold 100mV. Test fail on Rockchip
platforms, because the default LFPS detect threshold is set to
65mV.
The USBDP PHY LFPS detect threshold voltage could be set to
30mV ~ 140mV, and since there could be 10-20% PVT variation,
we set LFPS detect threshold voltage to 110mV.
[1] https://compliance.usb.org/resources/LFPS_Rx_Tx_Low_Power_Compliance_Update_Rev5.pdf
Signed-off-by: William Wu <william.wu@rock-chips.com>
[Taken over from rockchip's kernel tree; the registers are not described
in the TRM]
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, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index 2aa9ccabf80b..c6d24dd3bdef 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -413,7 +413,8 @@ static const struct reg_sequence rk_udphy_init_sequence[] = {
{0x0070, 0x7d}, {0x0074, 0x68},
{0x0af4, 0x1a}, {0x1af4, 0x1a},
{0x0440, 0x3f}, {0x10d4, 0x08},
- {0x20d4, 0x08}, {0x0024, 0x6e}
+ {0x20d4, 0x08}, {0x0024, 0x6e},
+ {0x09c0, 0x0a}, {0x19c0, 0x0a}
};
static inline int rk_udphy_grfreg_write(struct regmap *base,
--
2.53.0
^ permalink raw reply related
* [PATCH v8 11/29] phy: rockchip: usbdp: Add missing mode_change update
From: Sebastian Reichel @ 2026-06-26 20:55 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
rk_udphy_set_typec_default_mapping() updates the available modes,
but does not set the mode_change as required. This results in
missing re-initialization and thus non-working DisplayPort.
Fix this issue by introducing a new helper to update the available
modes.
Reviewed-by: Neil Armstrong <neil.armstrong@linaro.org>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 16 +++++++++++-----
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index c6d24dd3bdef..d091f8007acd 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -622,6 +622,15 @@ static void rk_udphy_dp_hpd_event_trigger(struct rk_udphy *udphy, bool hpd)
rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, hpd);
}
+static void rk_udphy_mode_set(struct rk_udphy *udphy, u8 mode)
+{
+ if (udphy->mode == mode)
+ return;
+
+ udphy->mode_change = true;
+ udphy->mode = mode;
+}
+
static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
{
if (udphy->flip) {
@@ -652,7 +661,7 @@ static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
gpiod_set_value_cansleep(udphy->sbu2_dc_gpio, 1);
}
- udphy->mode = UDPHY_MODE_DP_USB;
+ rk_udphy_mode_set(udphy, UDPHY_MODE_DP_USB);
}
static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
@@ -1394,10 +1403,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
usleep_range(750, 800);
rk_udphy_dp_hpd_event_trigger(udphy, true);
} else if (data->status & DP_STATUS_HPD_STATE) {
- if (udphy->mode != mode) {
- udphy->mode = mode;
- udphy->mode_change = true;
- }
+ rk_udphy_mode_set(udphy, mode);
rk_udphy_dp_hpd_event_trigger(udphy, true);
} else {
rk_udphy_dp_hpd_event_trigger(udphy, false);
--
2.53.0
^ permalink raw reply related
* [PATCH v8 12/29] phy: rockchip: usbdp: Support single-lane DP
From: Sebastian Reichel @ 2026-06-26 20:55 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: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
From: Zhang Yubing <yubing.zhang@rock-chips.com>
Implement support for using just a single DisplayPort line.
Signed-off-by: Zhang Yubing <yubing.zhang@rock-chips.com>
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 64 +++++++++++++------------------
1 file changed, 27 insertions(+), 37 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index d091f8007acd..5c38da0dadd2 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -193,6 +193,7 @@ struct rk_udphy {
int id;
bool dp_in_use;
+ int dp_lanes;
/* PHY const config */
const struct rk_udphy_cfg *cfgs;
@@ -540,6 +541,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)
@@ -547,18 +555,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;
break;
default:
@@ -571,28 +579,6 @@ static void rk_udphy_dplane_select(struct rk_udphy *udphy)
FIELD_PREP(DP_AUX_DOUT_SEL, udphy->dp_aux_dout_sel) | value);
}
-static int rk_udphy_dplane_get(struct rk_udphy *udphy)
-{
- int dp_lanes;
-
- switch (udphy->mode) {
- case UDPHY_MODE_DP:
- dp_lanes = 4;
- break;
-
- case UDPHY_MODE_DP_USB:
- dp_lanes = 2;
- break;
-
- case UDPHY_MODE_USB:
- default:
- dp_lanes = 0;
- break;
- }
-
- return dp_lanes;
-}
-
static void rk_udphy_dplane_enable(struct rk_udphy *udphy, int dp_lanes)
{
u32 val = 0;
@@ -662,6 +648,7 @@ static void rk_udphy_set_typec_default_mapping(struct rk_udphy *udphy)
}
rk_udphy_mode_set(udphy, UDPHY_MODE_DP_USB);
+ udphy->dp_lanes = 2;
}
static int rk_udphy_orien_sw_set(struct typec_switch_dev *sw,
@@ -900,7 +887,7 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
return 0;
}
- if (num_lanes != 2 && num_lanes != 4)
+ if (num_lanes != 1 && num_lanes != 2 && num_lanes != 4)
return dev_err_probe(udphy->dev, -EINVAL,
"invalid number of lane mux\n");
@@ -926,9 +913,11 @@ static int rk_udphy_parse_lane_mux_data(struct rk_udphy *udphy)
}
udphy->mode = UDPHY_MODE_DP;
- if (num_lanes == 2) {
+ udphy->dp_lanes = num_lanes;
+ if (num_lanes == 1 || num_lanes == 2) {
udphy->mode |= UDPHY_MODE_USB;
- udphy->flip = (udphy->lane_mux_sel[0] == PHY_LANE_MUX_DP);
+ udphy->flip = (udphy->lane_mux_sel[0] == PHY_LANE_MUX_DP) ||
+ (udphy->lane_mux_sel[1] == PHY_LANE_MUX_DP);
}
return 0;
@@ -1083,18 +1072,17 @@ static int rk_udphy_dp_phy_exit(struct phy *phy)
static int rk_udphy_dp_phy_power_on(struct phy *phy)
{
struct rk_udphy *udphy = phy_get_drvdata(phy);
- int ret, dp_lanes;
+ int ret;
mutex_lock(&udphy->mutex);
- dp_lanes = rk_udphy_dplane_get(udphy);
- phy_set_bus_width(phy, dp_lanes);
+ phy_set_bus_width(phy, udphy->dp_lanes);
ret = rk_udphy_power_on(udphy, UDPHY_MODE_DP);
if (ret)
goto unlock;
- rk_udphy_dplane_enable(udphy, dp_lanes);
+ rk_udphy_dplane_enable(udphy, udphy->dp_lanes);
rk_udphy_dplane_select(udphy);
@@ -1374,6 +1362,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
udphy->lane_mux_sel[2] = PHY_LANE_MUX_DP;
udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
mode = UDPHY_MODE_DP;
+ udphy->dp_lanes = 4;
break;
case TYPEC_DP_STATE_D:
@@ -1390,6 +1379,7 @@ static int rk_udphy_typec_mux_set(struct typec_mux_dev *mux,
udphy->lane_mux_sel[3] = PHY_LANE_MUX_DP;
}
mode = UDPHY_MODE_DP_USB;
+ udphy->dp_lanes = 2;
break;
}
@@ -1538,7 +1528,7 @@ static int rk_udphy_probe(struct platform_device *pdev)
ret = PTR_ERR(udphy->phy_dp);
return dev_err_probe(dev, ret, "failed to create DP phy\n");
}
- phy_set_bus_width(udphy->phy_dp, rk_udphy_dplane_get(udphy));
+ phy_set_bus_width(udphy->phy_dp, udphy->dp_lanes);
udphy->phy_dp->attrs.max_link_rate = 8100;
phy_set_drvdata(udphy->phy_dp, udphy);
--
2.53.0
^ permalink raw reply related
* [PATCH v8 07/29] phy: rockchip: usbdp: Handle rk_udphy_reset_deassert_all errors in init check
From: Sebastian Reichel @ 2026-06-26 20:55 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, Sashiko
In-Reply-To: <20260626-rockchip-usbdp-cleanup-v8-0-47f682987895@collabora.com>
Fix theoretical issue, that failure to deassert the reset lines would
result in an SError in follow-up register access. Note, that this cannot
happen with current code, since the Rockchip reset driver never returns
any errors for (de)asserting reset lines.
Fixes: 2f70bbddeb45 ("phy: rockchip: add usbdp combo phy driver")
Reported-by: Sashiko <sashiko-bot@kernel.org>
Closes: https://sashiko.dev/#/message/20260619154903.2225A1F000E9%40smtp.kernel.org
Signed-off-by: Sebastian Reichel <sebastian.reichel@collabora.com>
---
drivers/phy/rockchip/phy-rockchip-usbdp.c | 7 +++++--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/drivers/phy/rockchip/phy-rockchip-usbdp.c b/drivers/phy/rockchip/phy-rockchip-usbdp.c
index f7ff55f03b7c..b8de0a47a616 100644
--- a/drivers/phy/rockchip/phy-rockchip-usbdp.c
+++ b/drivers/phy/rockchip/phy-rockchip-usbdp.c
@@ -936,7 +936,9 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
return ret;
}
- rk_udphy_reset_deassert_all(udphy);
+ ret = rk_udphy_reset_deassert_all(udphy);
+ if (ret)
+ goto exit;
regmap_read(udphy->pma_regmap, CMN_LANE_MUX_AND_EN_OFFSET, &value);
if (FIELD_GET(CMN_DP_LANE_MUX_ALL, value) && FIELD_GET(CMN_DP_LANE_EN_ALL, value)) {
@@ -944,9 +946,10 @@ static int rk_udphy_get_initial_status(struct rk_udphy *udphy)
rk_udphy_grfreg_write(udphy->vogrf, &cfg->vogrfcfg[udphy->id].hpd_trigger, false);
}
+exit:
rk_udphy_disable(udphy);
- return 0;
+ return ret;
}
static int rk_udphy_parse_dt(struct rk_udphy *udphy)
--
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