* Re: [PATCH 0/4] drm/panel: simple: add Waveshare LCD panels
From: Marek Vasut @ 2026-03-31 21:46 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Thierry Reding, Sam Ravnborg,
Joseph Guo, Marek Vasut, Andrzej Hajda, Robert Foss,
Laurent Pinchart, Jonas Karlman, Jernej Skrabec, dri-devel,
devicetree, linux-kernel
In-Reply-To: <kqrdzvu5ycajmdprrjqwcktq42t6453csi77ngzlkomtazxjhv@sxp7vh66my4x>
On 3/31/26 5:36 PM, Dmitry Baryshkov wrote:
> On Tue, Mar 31, 2026 at 05:11:43AM +0200, Marek Vasut wrote:
>> On 3/31/26 3:22 AM, Dmitry Baryshkov wrote:
>>> On Tue, 31 Mar 2026 at 00:07, Marek Vasut <marek.vasut@mailbox.org> wrote:
>>>>
>>>> On 3/30/26 3:25 PM, Dmitry Baryshkov wrote:
>>>>> Waveshare have a serie of DSI panel kits with the DPI or LVDS panel
>>>>> being attached to the DSI2DPI or DSI2LVDS bridge. Commit 80b0eb11f8e0
>>>>> ("dt-bindings: display: panel: Add waveshare DPI panel support")
>>>>> described two of them in the bindings and commit 46be11b678e0
>>>>> ("drm/panel: simple: Add Waveshare 13.3" panel support") added
>>>>> definitions for one of those panels. Add support for the rest of them.
>>>> Can we by any chance use the icn6211 driver in tree for this ?
>>>
>>> As far as I can see, no. Waveshare kits have an extra ASIC in front of
>>> ICN6211 / ICN6202, which completely hides all programming. So far the
>>> interface is really better expressed by the waveshare,dsi2dpi /
>>> dsi2lvds: this way, even if they decide to change the actual
>>> implementation (like they did for DPI -> LVDS), we won't have to worry
>>> about it for as long as their programming interface remains stable.
>> Hmmm, I've seen this before, but I don't think this is extra ASIC. The
>> ICN6211 pulls its register settings from EEPROM, does it not ?
>
> The kits that I have at hand don't have I2C EEPROMs. They have 25Q8
> QSPI. Also note that neither ICN6211 nor ICN6202 datasheets describe I2C
> master interface. It is defined as a purely I2C slave.
>
> The kits have WSVTH01 chip (CPLD?) and 25Q8 QSPI NOR. I assume the
> bridge settings are loaded from by the WSVTH01 and programmed into the
> ICN bridge.
>
>> But no matter how the ICN loads its configuration, this is not waveshare
>> specific. I have another display from another manufacturer here which is
>> also ICN6211 that is preprogrammed. Can we instead have some generic-dsi
>> display , because I don't think these proprogrammed DSI displays are going
>> to be only ICN6211 based and only made by waveshare ?
>
> If it was just about the bridge config, I would completely agree with
> you. However if you check the waveshare-dsi.c, you'd notice that it is
> not directly related to either of ICN bridges. It controls backlight
> and panel regulators.
Oh ok, this part, I understand.
^ permalink raw reply
* Re: [PATCH v9 4/7] media: i2c: imx355: Restrict data lanes to 4
From: Vladimir Zapolskiy @ 2026-03-31 21:37 UTC (permalink / raw)
To: Richard Acayan, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio, Tianshu Qiu,
Sakari Ailus, linux-media, devicetree, linux-arm-msm
Cc: Robert Mader, David Heidelberg, phone-devel
In-Reply-To: <20260217002738.133534-5-mailingradian@gmail.com>
On 2/17/26 02:27, Richard Acayan wrote:
> The IMX355 sensor driver currently supports having 4 data lanes. There
> can't be more or less, so check if the firmware specifies 4 lanes.
Does IMX355 sensor hardware support any other number of lanes?
1) If no, then it makes no practical sense to check for data lanes number
given by firmware, there can be any stored value, but it's known that the
number of sensor data lanes is 4.
2) If yes, then please return to the sensor dt bindings, and reflect any
other options, right now it is set strictly to 4 lanes only. In case if
'data-lanes' property is omitted, you can use 4 lanes as a default number
of data lanes, and this information shall be documented in the dt bindings.
>
> Existing ACPI hardware descriptions may not have the data lanes defined
> so this check also accepts a placeholder of 0 lanes.
>
> Suggested-by: Sakari Ailus <sakari.ailus@linux.intel.com>
> Link: https://lore.kernel.org/r/aW3uFcT1zmiF4GUP@kekkonen.localdomain
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
> ---
> drivers/media/i2c/imx355.c | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/media/i2c/imx355.c b/drivers/media/i2c/imx355.c
> index 9ca87488c933..0d6aabea7d59 100644
> --- a/drivers/media/i2c/imx355.c
> +++ b/drivers/media/i2c/imx355.c
> @@ -66,6 +66,9 @@
> #define IMX355_EXT_CLK 19200000
> #define IMX355_LINK_FREQ_INDEX 0
>
> +/* number of data lanes */
> +#define IMX355_DATA_LANES 4
> +
> struct imx355_reg {
> u16 address;
> u8 val;
> @@ -1705,6 +1708,10 @@ static struct imx355_hwcfg *imx355_get_hwcfg(struct device *dev)
> if (!cfg)
> goto out_err;
>
> + if (bus_cfg.bus.mipi_csi2.num_data_lanes != 0
> + && bus_cfg.bus.mipi_csi2.num_data_lanes != IMX355_DATA_LANES)
> + goto out_err;
> +
> ret = v4l2_link_freq_to_bitmap(dev, bus_cfg.link_frequencies,
> bus_cfg.nr_of_link_frequencies,
> link_freq_menu_items,
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH v2] riscv: dts: spacemit: k3: Add USB2.0 support
From: kernel test robot @ 2026-03-31 21:34 UTC (permalink / raw)
To: Yixun Lan, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Paul Walmsley, Palmer Dabbelt, Albert Ou, Alexandre Ghiti
Cc: oe-kbuild-all, devicetree, linux-riscv, spacemit, linux-kernel,
Yixun Lan
In-Reply-To: <20260330-02-k3-usb20-dts-v2-1-46af262fb4a9@kernel.org>
Hi Yixun,
kernel test robot noticed the following build errors:
[auto build test ERROR on af62a095eb0c3359d477b55ef72d2afd94c83c8f]
url: https://github.com/intel-lab-lkp/linux/commits/Yixun-Lan/riscv-dts-spacemit-k3-Add-USB2-0-support/20260331-231732
base: af62a095eb0c3359d477b55ef72d2afd94c83c8f
patch link: https://lore.kernel.org/r/20260330-02-k3-usb20-dts-v2-1-46af262fb4a9%40kernel.org
patch subject: [PATCH v2] riscv: dts: spacemit: k3: Add USB2.0 support
config: riscv-randconfig-002-20260401 (https://download.01.org/0day-ci/archive/20260401/202604010550.sTNDXe0k-lkp@intel.com/config)
compiler: riscv32-linux-gcc (GCC) 11.5.0
reproduce (this is a W=1 build): (https://download.01.org/0day-ci/archive/20260401/202604010550.sTNDXe0k-lkp@intel.com/reproduce)
If you fix the issue in a separate patch/commit (i.e. not just a new version of
the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202604010550.sTNDXe0k-lkp@intel.com/
All errors (new ones prefixed by >>):
Lexical error: arch/riscv/boot/dts/spacemit/k3.dtsi:446.27-46 Unexpected 'RESET_APMU_USB2_AHB'
Lexical error: arch/riscv/boot/dts/spacemit/k3.dtsi:447.20-39 Unexpected 'RESET_APMU_USB2_VCC'
Lexical error: arch/riscv/boot/dts/spacemit/k3.dtsi:448.20-39 Unexpected 'RESET_APMU_USB2_PHY'
>> FATAL ERROR: Syntax error parsing input tree
--
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
^ permalink raw reply
* Re: [PATCH v9 1/7] dt-bindings: media: qcom,sdm670-camss: Remove clock-lanes requirement
From: Vladimir Zapolskiy @ 2026-03-31 21:22 UTC (permalink / raw)
To: Richard Acayan, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Bjorn Andersson, Konrad Dybcio, Tianshu Qiu,
Sakari Ailus, linux-media, devicetree, linux-arm-msm
Cc: Robert Mader, David Heidelberg, phone-devel
In-Reply-To: <20260217002738.133534-2-mailingradian@gmail.com>
On 2/17/26 02:27, Richard Acayan wrote:
> The clock-lanes property has no effect on the hardware configuration, as
> of commit 336136e197e2 ("media: dt-bindings: media: camss: Remove
> clock-lane property"). Since boards with new camss support can omit the
> property, remove it from the required lists.
>
> Signed-off-by: Richard Acayan <mailingradian@gmail.com>
If you send another v10 of the series, please remove 'clock-lanes'
property from the example as well. Anyway, feel free to add my
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
--
Best wishes,
Vladimir
^ permalink raw reply
* Re: [PATCH 7/7] clk: qcom: Add support for global clock controller on Hawi
From: Bjorn Andersson @ 2026-03-31 21:11 UTC (permalink / raw)
To: Vivek Aknurwar
Cc: Michael Turquette, Stephen Boyd, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Taniya Das, Taniya Das, linux-arm-msm, linux-clk,
devicetree, linux-kernel, Mike Tipton
In-Reply-To: <20260330-clk-hawi-v1-7-c2a663e1d35b@oss.qualcomm.com>
On Mon, Mar 30, 2026 at 05:35:02PM -0700, Vivek Aknurwar wrote:
> +++ b/drivers/clk/qcom/gcc-hawi.c
[..]
> +static const struct qcom_cc_desc gcc_hawi_desc = {
> + .config = &gcc_hawi_regmap_config,
> + .clks = gcc_hawi_clocks,
> + .num_clks = ARRAY_SIZE(gcc_hawi_clocks),
> + .resets = gcc_hawi_resets,
> + .num_resets = ARRAY_SIZE(gcc_hawi_resets),
> + .gdscs = gcc_hawi_gdscs,
> + .num_gdscs = ARRAY_SIZE(gcc_hawi_gdscs),
> + .driver_data = &gcc_hawi_driver_data,
Sorry for not spotting this earlier, but don't we need a ".use_rpm =
true" here?
In line with
https://lore.kernel.org/all/20260309-glymur-fix-gcc-cx-scaling-v2-2-d7a58a0a9ecb@oss.qualcomm.com/
Regards,
Bjorn
> +};
> +
^ permalink raw reply
* Re: (subset) [PATCH v2 0/9] interconnect: qcom: let MSM8974 interconnect work again
From: Bjorn Andersson @ 2026-03-31 21:04 UTC (permalink / raw)
To: Georgi Djakov, Konrad Dybcio, Luca Weiss, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Brian Masney, Dmitry Baryshkov
Cc: linux-arm-msm, linux-pm, devicetree, linux-kernel, Brian Masney,
Konrad Dybcio
In-Reply-To: <20260324-msm8974-icc-v2-0-527280043ad8@oss.qualcomm.com>
On Tue, 24 Mar 2026 02:10:36 +0200, Dmitry Baryshkov wrote:
> Commit d6edc31f3a68 ("clk: qcom: smd-rpm: Separate out interconnect bus
> clocks") moved control over several RPM resources from the clk-smd-rpm
> driver to the icc-rpm.c interconnect helpers. Most of the platforms were
> fixed before that commit or shortly after. However the MSM8974 was left
> as a foster child in broken state. Fix the loose ends and reenable
> interconnects on that platform.
>
> [...]
Applied, thanks!
[9/9] ARM: dts: qcom: msm8974: Drop RPM bus clocks
commit: 6453ad0865b68ab0de5873c1a8bb4addbbde5c19
Best regards,
--
Bjorn Andersson <andersson@kernel.org>
^ permalink raw reply
* Re: [PATCH v9 3/6] mfd: max77759: add register bitmasks and modify irq configs for charger
From: Amit Sunil Dhamne @ 2026-03-31 20:39 UTC (permalink / raw)
To: Lee Jones
Cc: Sebastian Reichel, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
André Draszik, Greg Kroah-Hartman, Badhri Jagan Sridharan,
Heikki Krogerus, Peter Griffin, Tudor Ambarus, Alim Akhtar,
Mark Brown, Matti Vaittinen, Andrew Morton, linux-kernel,
linux-pm, devicetree, linux-usb, linux-arm-kernel,
linux-samsung-soc, RD Babiera, Kyle Tso
In-Reply-To: <20260331123138.GE3795166@google.com>
Hi Lee,
On 3/31/26 5:31 AM, Lee Jones wrote:
> On Wed, 25 Mar 2026, Amit Sunil Dhamne via B4 Relay wrote:
>
>> From: Amit Sunil Dhamne <amitsd@google.com>
>>
>> Add register bitmasks for charger function.
>> In addition split the charger IRQs further such that each bit represents
>> an IRQ downstream of charger regmap irq chip. In addition populate the
>> ack_base to offload irq ack to the regmap irq chip framework.
>>
>> Signed-off-by: Amit Sunil Dhamne <amitsd@google.com>
>> Reviewed-by: André Draszik <andre.draszik@linaro.org>
>> ---
>> drivers/mfd/max77759.c | 95 ++++++++++++++++++++++---
>> include/linux/mfd/max77759.h | 166 +++++++++++++++++++++++++++++++++++--------
>> 2 files changed, 222 insertions(+), 39 deletions(-)
>>
> [...]
>
>> +/*
>> + * enum max77759_chgr_chgin_dtls_status - Charger Input Status
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE:
>> + * Charger input voltage (Vchgin) < Under Voltage Threshold (Vuvlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE: Vchgin > Vuvlo and
>> + * Vchgin < (Battery Voltage (Vbatt) + system voltage (Vsys))
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE:
>> + * Vchgin > Over Voltage threshold (Vovlo)
>> + * @MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID:
>> + * Vchgin > Vuvlo, Vchgin < Vovlo and Vchgin > (Vsys + Vbatt)
>> + */
> This comment is masquerading as a kernel-doc header, but isn't actually
> kernel-doc. Either change the formatting or adapt the formatting to use
> /** and use W=1 to check it.
Thanks for pointing this out! I'll fix this in the next version and
ensure it's a proper kernel-doc block.
BR,
Amit
>> +enum max77759_chgr_chgin_dtls_status {
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_UNDERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_MARGINAL_VOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_OVERVOLTAGE,
>> + MAX77759_CHGR_CHGIN_DTLS_VBUS_VALID,
>> +};
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Heiko Stuebner @ 2026-03-31 20:19 UTC (permalink / raw)
To: Alexey Charkov, Dennis Gilmore
Cc: Jimmy Hon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
FUKAUMI Naoki, Hsun Lai, Jonas Karlman, Chaoyi Chen, John Clark,
Michael Opdenacker, Quentin Schulz, Andrew Lunn, Chukun Pan,
Peter Robinson, Michael Riesch, Mykola Kvach, devicetree,
linux-arm-kernel, linux-rockchip, linux-kernel
In-Reply-To: <CAABkxwsD_59G3YrpMdUi7D1fVHruSuDHn9-gQAZbwTdxGBHaBA@mail.gmail.com>
Hi Dennis,
Am Dienstag, 31. März 2026, 21:41:50 Mitteleuropäische Sommerzeit schrieb Dennis Gilmore:
> On Wed, Mar 11, 2026 at 9:26 AM Alexey Charkov <alchark@gmail.com> wrote:
> >
> > On Wed, Mar 11, 2026 at 5:29 AM Dennis Gilmore <dennis@ausil.us> wrote:
> > >
> > > On Tue, Mar 10, 2026 at 7:20 PM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > > >
> > > > <snip>
> > > > > +
> > > > > + vcc5v0_otg: regulator-vcc5v0-otg {
> > > > > + compatible = "regulator-fixed";
> > > > > + enable-active-high;
> > > > > + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> > > > > + pinctrl-names = "default";
> > > > > + pinctrl-0 = <&vcc5v0_otg_en>;
> > > > > + regulator-always-on;
> > > > > + regulator-boot-on;
> > > > regulator-always-on and regulator-boot-on does not seem right.
> > > >
> > > > Why were these added? The vendor did not have them.
> > > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L216-L226
> > > >
> > > > Was this mistakenly taken from the regulator usb 20 which is powering
> > > > the onboard usb2.0 hub?
> > > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L111-L119
> > >
> > > It may have been a missreading of the schematic, but it was added to
> > > get power to the USB3 port. before I added it devices plugged into the
> > > USB 3 port would not power on
> >
> > Hi Dennis,
> >
> > The schematic says that this regulator supplies the VBUS voltage for
> > the USB3 part of your Type-A OTG connector. If you make it always-on,
> > you'll likely lose the possibility to use this port in device mode
> > (which you would need e.g. for flashing images over a USB cable in
> > U-boot which also takes device tree sources from Linux via
> > devicetree-rebasing).
> >
> > You also link it up as the PHY supply of the USB2 controller, which
> > doesn't describe the actual hardware.
> >
> > Please see if you'd rather define a connector node for your Type-A
> > port, and list this regulator as its VBUS supply explicitly. I've
> > recently submitted a patch [1] to make the "onboard_usb_dev" driver
> > take care of enabling VBUS in exactly this type of situations (it's in
> > usb-testing now and will hopefully hit -next sometime soon). If you
> > need an example for its use, please refer to [2].
> >
> > Best regards,
> > Alexey
> >
> > [1] https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
> > [2] https://github.com/flipperdevices/flipper-linux-kernel/blob/2f814cdf07f50e901fc1b1328213e76460864c20/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts#L303-L328
>
> Sorry for the delay, I am taking a look at it now. Please let me know
> when it lands in -next. In the meantime, I believe what I have is in
> good shape and is working well here. I am happy to make a change once
> support lands upstream.
Review comments should be addressed before patches get applied.
So there is no waiting for "when it lands upstream" to make additional
fixes, when you know at submission time, that things need improvement.
Heiko
^ permalink raw reply
* [PATCH v5 4/4] arm64: dts: qcom: sdm670: add lpi pinctrl
From: Richard Acayan @ 2026-03-31 20:06 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
The Snapdragon 670 has a separate TLMM for audio pins. Add the device
node for it.
Also add reserved GPIOs for the Pixel 3a, which blocks access to the
sensor GPIOs.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../boot/dts/qcom/sdm670-google-common.dtsi | 5 ++
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 +++++++++++++++++++
2 files changed, 78 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
index 0f57b915186b..b4854801a5f5 100644
--- a/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670-google-common.dtsi
@@ -522,6 +522,11 @@ rmi4_f12: rmi4-f12@12 {
};
};
+&lpi_tlmm {
+ /* sensor gpios are protected */
+ gpio-reserved-ranges = <0 8>, <12 6>;
+};
+
&mdss {
status = "okay";
};
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index 5b41f8bac7bc..2d5728c75a93 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -2346,6 +2346,79 @@ lmh_cluster0: lmh@17d78800 {
interrupt-controller;
#interrupt-cells = <1>;
};
+
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0 0x62b40000 0 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_pdm_default: cdc-pdm-default-state {
+ clk-pins {
+ pins = "gpio18";
+ function = "slimbus_clk";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ sync-pins {
+ pins = "gpio19";
+ function = "pdm_sync";
+ drive-strength = <4>;
+ output-low;
+ };
+
+ tx-pins {
+ pins = "gpio20";
+ function = "pdm_tx";
+ drive-strength = <8>;
+ };
+
+ rx-pins {
+ pins = "gpio21", "gpio23", "gpio25";
+ function = "pdm_rx";
+ drive-strength = <4>;
+ output-low;
+ };
+ };
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+
+ cdc_dmic_default: cdc-dmic-default-state {
+ clk1-pins {
+ pins = "gpio26";
+ function = "dmic1_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ clk2-pins {
+ pins = "gpio28";
+ function = "dmic2_clk";
+ drive-strength = <8>;
+ output-high;
+ };
+
+ data1-pins {
+ pins = "gpio27";
+ function = "dmic1_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+
+ data2-pins {
+ pins = "gpio29";
+ function = "dmic2_data";
+ drive-strength = <8>;
+ input-enable;
+ };
+ };
+ };
};
thermal-zones {
--
2.53.0
^ permalink raw reply related
* [PATCH v5 3/4] pinctrl: qcom: add sdm670 lpi tlmm
From: Richard Acayan @ 2026-03-31 20:06 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
The Snapdragon 670 has an Low-Power Island (LPI) TLMM for configuring
pins related to audio. Add the driver for this.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
---
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
3 files changed, 177 insertions(+)
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
diff --git a/drivers/pinctrl/qcom/Kconfig b/drivers/pinctrl/qcom/Kconfig
index f56592411cf6..eb8ed3effd58 100644
--- a/drivers/pinctrl/qcom/Kconfig
+++ b/drivers/pinctrl/qcom/Kconfig
@@ -89,6 +89,16 @@ config PINCTRL_SM4250_LPASS_LPI
Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
(Low Power Island) found on the Qualcomm Technologies Inc SM4250 platform.
+config PINCTRL_SDM670_LPASS_LPI
+ tristate "Qualcomm Technologies Inc SDM670 LPASS LPI pin controller driver"
+ depends on GPIOLIB
+ depends on ARM64 || COMPILE_TEST
+ depends on PINCTRL_LPASS_LPI
+ help
+ This is the pinctrl, pinmux, pinconf and gpiolib driver for the
+ Qualcomm Technologies Inc LPASS (Low Power Audio SubSystem) LPI
+ (Low Power Island) found on the Qualcomm Technologies Inc SDM670 platform.
+
config PINCTRL_SM6115_LPASS_LPI
tristate "Qualcomm Technologies Inc SM6115 LPASS LPI pin controller driver"
depends on ARM64 || COMPILE_TEST
diff --git a/drivers/pinctrl/qcom/Makefile b/drivers/pinctrl/qcom/Makefile
index 4269d1781015..ed2127d26912 100644
--- a/drivers/pinctrl/qcom/Makefile
+++ b/drivers/pinctrl/qcom/Makefile
@@ -48,6 +48,7 @@ obj-$(CONFIG_PINCTRL_SC8280XP) += pinctrl-sc8280xp.o
obj-$(CONFIG_PINCTRL_SDM660) += pinctrl-sdm660.o
obj-$(CONFIG_PINCTRL_SDM660_LPASS_LPI) += pinctrl-sdm660-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM670) += pinctrl-sdm670.o
+obj-$(CONFIG_PINCTRL_SDM670_LPASS_LPI) += pinctrl-sdm670-lpass-lpi.o
obj-$(CONFIG_PINCTRL_SDM845) += pinctrl-sdm845.o
obj-$(CONFIG_PINCTRL_SDX55) += pinctrl-sdx55.o
obj-$(CONFIG_PINCTRL_SDX65) += pinctrl-sdx65.o
diff --git a/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
new file mode 100644
index 000000000000..6270c6d09c22
--- /dev/null
+++ b/drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
@@ -0,0 +1,166 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (c) 2023-2026, Richard Acayan. All rights reserved.
+ */
+
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/of.h>
+#include <linux/platform_device.h>
+#include <linux/pinctrl/pinctrl.h>
+
+#include "pinctrl-lpass-lpi.h"
+
+enum lpass_lpi_functions {
+ LPI_MUX_comp_rx,
+ LPI_MUX_dmic1_clk,
+ LPI_MUX_dmic1_data,
+ LPI_MUX_dmic2_clk,
+ LPI_MUX_dmic2_data,
+ LPI_MUX_i2s1_clk,
+ LPI_MUX_i2s1_data,
+ LPI_MUX_i2s1_ws,
+ LPI_MUX_lpi_cdc_rst,
+ LPI_MUX_mclk0,
+ LPI_MUX_pdm_rx,
+ LPI_MUX_pdm_sync,
+ LPI_MUX_pdm_tx,
+ LPI_MUX_slimbus_clk,
+ LPI_MUX_gpio,
+ LPI_MUX__,
+};
+
+static const struct pinctrl_pin_desc sdm670_lpi_pinctrl_pins[] = {
+ PINCTRL_PIN(0, "gpio0"),
+ PINCTRL_PIN(1, "gpio1"),
+ PINCTRL_PIN(2, "gpio2"),
+ PINCTRL_PIN(3, "gpio3"),
+ PINCTRL_PIN(4, "gpio4"),
+ PINCTRL_PIN(5, "gpio5"),
+ PINCTRL_PIN(6, "gpio6"),
+ PINCTRL_PIN(7, "gpio7"),
+ PINCTRL_PIN(8, "gpio8"),
+ PINCTRL_PIN(9, "gpio9"),
+ PINCTRL_PIN(10, "gpio10"),
+ PINCTRL_PIN(11, "gpio11"),
+ PINCTRL_PIN(12, "gpio12"),
+ PINCTRL_PIN(13, "gpio13"),
+ PINCTRL_PIN(14, "gpio14"),
+ PINCTRL_PIN(15, "gpio15"),
+ PINCTRL_PIN(16, "gpio16"),
+ PINCTRL_PIN(17, "gpio17"),
+ PINCTRL_PIN(18, "gpio18"),
+ PINCTRL_PIN(19, "gpio19"),
+ PINCTRL_PIN(20, "gpio20"),
+ PINCTRL_PIN(21, "gpio21"),
+ PINCTRL_PIN(22, "gpio22"),
+ PINCTRL_PIN(23, "gpio23"),
+ PINCTRL_PIN(24, "gpio24"),
+ PINCTRL_PIN(25, "gpio25"),
+ PINCTRL_PIN(26, "gpio26"),
+ PINCTRL_PIN(27, "gpio27"),
+ PINCTRL_PIN(28, "gpio28"),
+ PINCTRL_PIN(29, "gpio29"),
+ PINCTRL_PIN(30, "gpio30"),
+ PINCTRL_PIN(31, "gpio31"),
+};
+
+static const char * const comp_rx_groups[] = { "gpio22", "gpio24" };
+static const char * const dmic1_clk_groups[] = { "gpio26" };
+static const char * const dmic1_data_groups[] = { "gpio27" };
+static const char * const dmic2_clk_groups[] = { "gpio28" };
+static const char * const dmic2_data_groups[] = { "gpio29" };
+static const char * const i2s1_clk_groups[] = { "gpio8" };
+static const char * const i2s1_ws_groups[] = { "gpio9" };
+static const char * const i2s1_data_groups[] = { "gpio10", "gpio11" };
+static const char * const lpi_cdc_rst_groups[] = { "gpio29" };
+static const char * const mclk0_groups[] = { "gpio19" };
+static const char * const pdm_rx_groups[] = { "gpio21", "gpio23", "gpio25" };
+static const char * const pdm_sync_groups[] = { "gpio19" };
+static const char * const pdm_tx_groups[] = { "gpio20" };
+static const char * const slimbus_clk_groups[] = { "gpio18" };
+
+const struct lpi_pingroup sdm670_lpi_pinctrl_groups[] = {
+ LPI_PINGROUP(0, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(1, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(2, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(3, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(4, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(5, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(6, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(7, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(8, LPI_NO_SLEW, _, _, i2s1_clk, _),
+ LPI_PINGROUP(9, LPI_NO_SLEW, _, _, i2s1_ws, _),
+ LPI_PINGROUP(10, LPI_NO_SLEW, _, _, _, i2s1_data),
+ LPI_PINGROUP(11, LPI_NO_SLEW, _, i2s1_data, _, _),
+ LPI_PINGROUP(12, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(13, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(14, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(15, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(16, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(17, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(18, LPI_NO_SLEW, _, slimbus_clk, _, _),
+ LPI_PINGROUP(19, LPI_NO_SLEW, mclk0, _, pdm_sync, _),
+ LPI_PINGROUP(20, LPI_NO_SLEW, _, pdm_tx, _, _),
+ LPI_PINGROUP(21, LPI_NO_SLEW, _, pdm_rx, _, _),
+ LPI_PINGROUP(22, LPI_NO_SLEW, _, comp_rx, _, _),
+ LPI_PINGROUP(23, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(24, LPI_NO_SLEW, comp_rx, _, _, _),
+ LPI_PINGROUP(25, LPI_NO_SLEW, pdm_rx, _, _, _),
+ LPI_PINGROUP(26, LPI_NO_SLEW, dmic1_clk, _, _, _),
+ LPI_PINGROUP(27, LPI_NO_SLEW, dmic1_data, _, _, _),
+ LPI_PINGROUP(28, LPI_NO_SLEW, dmic2_clk, _, _, _),
+ LPI_PINGROUP(29, LPI_NO_SLEW, dmic2_data, lpi_cdc_rst, _, _),
+ LPI_PINGROUP(30, LPI_NO_SLEW, _, _, _, _),
+ LPI_PINGROUP(31, LPI_NO_SLEW, _, _, _, _),
+};
+
+const struct lpi_function sdm670_lpi_pinctrl_functions[] = {
+ LPI_FUNCTION(comp_rx),
+ LPI_FUNCTION(dmic1_clk),
+ LPI_FUNCTION(dmic1_data),
+ LPI_FUNCTION(dmic2_clk),
+ LPI_FUNCTION(dmic2_data),
+ LPI_FUNCTION(i2s1_clk),
+ LPI_FUNCTION(i2s1_data),
+ LPI_FUNCTION(i2s1_ws),
+ LPI_FUNCTION(lpi_cdc_rst),
+ LPI_FUNCTION(mclk0),
+ LPI_FUNCTION(pdm_tx),
+ LPI_FUNCTION(pdm_rx),
+ LPI_FUNCTION(pdm_sync),
+ LPI_FUNCTION(slimbus_clk),
+};
+
+static const struct lpi_pinctrl_variant_data sdm670_lpi_pinctrl_data = {
+ .pins = sdm670_lpi_pinctrl_pins,
+ .npins = ARRAY_SIZE(sdm670_lpi_pinctrl_pins),
+ .groups = sdm670_lpi_pinctrl_groups,
+ .ngroups = ARRAY_SIZE(sdm670_lpi_pinctrl_groups),
+ .functions = sdm670_lpi_pinctrl_functions,
+ .nfunctions = ARRAY_SIZE(sdm670_lpi_pinctrl_functions),
+ .flags = LPI_FLAG_SLEW_RATE_SAME_REG,
+};
+
+static const struct of_device_id sdm670_lpi_pinctrl_of_match[] = {
+ {
+ .compatible = "qcom,sdm670-lpass-lpi-pinctrl",
+ .data = &sdm670_lpi_pinctrl_data,
+ },
+ { }
+};
+MODULE_DEVICE_TABLE(of, sdm670_lpi_pinctrl_of_match);
+
+static struct platform_driver sdm670_lpi_pinctrl_driver = {
+ .driver = {
+ .name = "qcom-sdm670-lpass-lpi-pinctrl",
+ .of_match_table = sdm670_lpi_pinctrl_of_match,
+ },
+ .probe = lpi_pinctrl_probe,
+ .remove = lpi_pinctrl_remove,
+};
+module_platform_driver(sdm670_lpi_pinctrl_driver);
+
+MODULE_AUTHOR("Richard Acayan <mailingradian@gmail.com>");
+MODULE_DESCRIPTION("QTI SDM670 LPI GPIO pin control driver");
+MODULE_LICENSE("GPL");
--
2.53.0
^ permalink raw reply related
* [PATCH v5 2/4] dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
From: Richard Acayan @ 2026-03-31 20:06 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
Add the pin controller for the audio Low-Power Island (LPI) on SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++++++++++++
1 file changed, 81 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
new file mode 100644
index 000000000000..c76ad70e6b9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
@@ -0,0 +1,81 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm SDM670 SoC LPASS LPI TLMM
+
+maintainers:
+ - Richard Acayan <mailingradian@gmail.com>
+
+description:
+ Top Level Mode Multiplexer pin controller in the Low Power Audio SubSystem
+ (LPASS) Low Power Island (LPI) of Qualcomm SDM670 SoC.
+
+properties:
+ compatible:
+ const: qcom,sdm670-lpass-lpi-pinctrl
+
+ reg:
+ items:
+ - description: LPASS LPI TLMM Control and Status registers
+
+patternProperties:
+ "-state$":
+ oneOf:
+ - $ref: "#/$defs/qcom-sdm670-lpass-state"
+ - patternProperties:
+ "-pins$":
+ $ref: "#/$defs/qcom-sdm670-lpass-state"
+ additionalProperties: false
+
+$defs:
+ qcom-sdm670-lpass-state:
+ type: object
+ description:
+ Pinctrl node's client devices use subnodes for desired pin configuration.
+ Client device subnodes use below standard properties.
+ $ref: qcom,lpass-lpi-common.yaml#/$defs/qcom-tlmm-state
+ unevaluatedProperties: false
+
+ properties:
+ pins:
+ description:
+ List of gpio pins affected by the properties specified in this
+ subnode.
+ items:
+ pattern: "^gpio([0-9]|1[0-9]|2[0-9]|3[0-1])$"
+
+ function:
+ enum: [ gpio, comp_rx, dmic1_clk, dmic1_data, dmic2_clk, dmic2_data,
+ i2s1_clk, i2s_data, i2s_ws, lpi_cdc_rst, mclk0, pdm_rx,
+ pdm_sync, pdm_tx, slimbus_clk ]
+ description:
+ Specify the alternative function to be configured for the specified
+ pins.
+
+allOf:
+ - $ref: qcom,lpass-lpi-common.yaml#
+
+required:
+ - compatible
+ - reg
+
+unevaluatedProperties: false
+
+examples:
+ - |
+ lpi_tlmm: pinctrl@62b40000 {
+ compatible = "qcom,sdm670-lpass-lpi-pinctrl";
+ reg = <0x62b40000 0x20000>;
+ gpio-controller;
+ #gpio-cells = <2>;
+ gpio-ranges = <&lpi_tlmm 0 0 32>;
+
+ cdc_comp_default: cdc-comp-default-state {
+ pins = "gpio22", "gpio24";
+ function = "comp_rx";
+ drive-strength = <4>;
+ };
+ };
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/4] dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
From: Richard Acayan @ 2026-03-31 20:06 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
In-Reply-To: <20260331200658.1306-1-mailingradian@gmail.com>
There can be reserved GPIOs on the LPASS LPI pin controller to possibly
control sensors. Add the property for reserved GPIOs so they can be
avoided appropriately.
Adapted from the same entry in qcom,tlmm-common.yaml.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
.../bindings/pinctrl/qcom,lpass-lpi-common.yaml | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
index 619341dd637c..30f93b8159fd 100644
--- a/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
+++ b/Documentation/devicetree/bindings/pinctrl/qcom,lpass-lpi-common.yaml
@@ -27,6 +27,14 @@ properties:
gpio-ranges:
maxItems: 1
+ gpio-reserved-ranges:
+ minItems: 1
+ maxItems: 30
+ description:
+ Pins can be reserved for trusted applications or for LPASS, thereby
+ inaccessible from the OS. This property can be used to mark the pins
+ which resources should not be accessed by the OS.
+
required:
- gpio-controller
- "#gpio-cells"
--
2.53.0
^ permalink raw reply related
* [PATCH v5 0/4] SDM670 LPASS LPI pin controller support
From: Richard Acayan @ 2026-03-31 20:06 UTC (permalink / raw)
To: Bjorn Andersson, Linus Walleij, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Konrad Dybcio, Srinivas Kandagatla, linux-arm-msm,
linux-gpio, devicetree
Cc: Richard Acayan
This adds support for the LPASS LPI pin controller on SDM670, which
controls some audio pins (e.g. TDM or PDM busses). The ADSP patches are
not sent yet.
Dependencies:
- SDM670 Basic SoC thermal zones (devicetree nodes are touching)
https://lore.kernel.org/r/20260310002037.1863-1-mailingradian@gmail.com
- Support for the Pixel 3a XL with the Tianma panel (for reserved GPIOs)
https://lore.kernel.org/r/20260310002606.16413-1-mailingradian@gmail.com
Changes since v4 (https://lore.kernel.org/r/20260330164707.87441-1-mailingradian@gmail.com):
- squash reserved gpios patch (Dmitry's review tag dropped) (4/4, previously 5/5)
- add review tags (3/4, 4/4)
- correct changelog (0/4)
Changes since v3 (https://lore.kernel.org/r/20260328021036.85945-1-mailingradian@gmail.com):
- restore review tags (2-5/5)
- add review tags (1/5)
Changes since v2 (https://lore.kernel.org/r/20260310012446.32226-1-mailingradian@gmail.com):
- add minItems and maxItems (1/5)
- add review tags (2-5/5)
Changes since v1 (https://lore.kernel.org/r/20260210021109.11906-1-mailingradian@gmail.com):
- add LPASS in dt-bindings patch subject (2/5)
- change pin names (2/5, 3/5, 4/5)
- add reviewed-by from Krzysztof (2/5)
- specify gpio-reserved-ranges (1/5, 5/5)
Richard Acayan (4):
dt-bindings: qcom: lpass-lpi-common: add reserved GPIOs property
dt-bindings: pinctrl: qcom: Add SDM670 LPASS LPI pinctrl
pinctrl: qcom: add sdm670 lpi tlmm
arm64: dts: qcom: sdm670: add lpi pinctrl
.../pinctrl/qcom,lpass-lpi-common.yaml | 8 +
.../qcom,sdm670-lpass-lpi-pinctrl.yaml | 81 +++++++++
.../boot/dts/qcom/sdm670-google-common.dtsi | 5 +
arch/arm64/boot/dts/qcom/sdm670.dtsi | 73 ++++++++
drivers/pinctrl/qcom/Kconfig | 10 ++
drivers/pinctrl/qcom/Makefile | 1 +
.../pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c | 166 ++++++++++++++++++
7 files changed, 344 insertions(+)
create mode 100644 Documentation/devicetree/bindings/pinctrl/qcom,sdm670-lpass-lpi-pinctrl.yaml
create mode 100644 drivers/pinctrl/qcom/pinctrl-sdm670-lpass-lpi.c
--
2.53.0
^ permalink raw reply
* Re: [PATCH v5] MAINTAINERS: Add Axiado reviewer and Maintainers
From: Karthikeyan Mitran @ 2026-03-31 19:45 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: alexandre.belloni@bootlin.com, Arnd Bergmann, conor+dt@kernel.org,
devicetree@vger.kernel.org, fustini@kernel.org, Harshit Shah,
Karthikeyan Mitran, krzk+dt@kernel.org, linusw@kernel.org, ALKML,
Linux Kernel Mailing List, Axiado Reviewers, Prasad Bolisetty,
robh@kernel.org, Tzu-Hao Wei
>On 26/03/2026 21:50, Karthikeyan Mitran wrote:
>> From: Prasad Bolisetty <pbolisetty@axiado.com>
>>
>> Adding 3 new maintainers Prasad,Tzu-Hao, and Karthikeyan
>> and adding a group reviewer entry for review coverage,
>> Removed previous maintainer as the previous maintainer moved from project
>...
>> ---
>> MAINTAINERS | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/MAINTAINERS b/MAINTAINERS
>> index 55af015174a5..49f47e8c2ec3 100644
>> --- a/MAINTAINERS
>> +++ b/MAINTAINERS
>> @@ -2605,7 +2605,10 @@ F: arch/arm/mach-aspeed/
>> N: aspeed
>>
>> ARM/AXIADO ARCHITECTURE
>> -M: Harshit Shah <hshah@axiado.com>
>> +M: Prasad Bolisetty <pbolisetty@axiado.com>
>> +M: Tzu-Hao Wei <twei@axiado.com>
>> +M: Karthikeyan Mitran <kmitran@axiado.com>
>> +R: Axiado Reviewers <linux-maintainer@axiado.com>
>How many entries do you need? You already have three, so who is in
>Axiado reviewers? And what is "review coverage" you mentioned in the
>commit msg.
Thanks for your review and time, the 3 Maintainers are actively responsible for upstreaming and maintaining the code, the reviews are an group alias of axiado members who catch review gaps internally before going out, we acknowledge the internal structure does not map well with the upstream model.
>I skimmed through https://lore.kernel.org/all/?q=f%3Aaxiado.com and I do
>not see reviews from any of these addresses, so it all looks like you
>add some corporate structure, because some managers want to see what is
>posted.
Our internal reviews happens to be off-list so far, given the concerns I am fine in droping the reviewers <linux-maintainer@axiado.com>, will send v6 with just the 3 maintainers.
Thanks,
Karthikeyan Mitran
^ permalink raw reply
* [PATCH v12 3/3] arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
From: Richard Acayan @ 2026-03-31 19:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree
Cc: Mauro Carvalho Chehab, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Vladimir Zapolskiy, Tianshu Qiu, Sakari Ailus,
linux-media, Robert Mader, David Heidelberg, phone-devel,
Richard Acayan
In-Reply-To: <20260331194437.41041-1-mailingradian@gmail.com>
The Sony IMX355 is the front camera on the Pixel 3a, mounted in portrait
mode. It is connected to CSIPHY1 and CCI I2C1, and uses MCLK2. Add
support for it.
Co-developed-by: Robert Mader <robert.mader@collabora.com>
Signed-off-by: Robert Mader <robert.mader@collabora.com>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
---
.../boot/dts/qcom/sdm670-google-sargo.dts | 100 ++++++++++++++++++
1 file changed, 100 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670-google-sargo.dts b/arch/arm64/boot/dts/qcom/sdm670-google-sargo.dts
index ed55646ca419..eba2f3792dd0 100644
--- a/arch/arm64/boot/dts/qcom/sdm670-google-sargo.dts
+++ b/arch/arm64/boot/dts/qcom/sdm670-google-sargo.dts
@@ -172,6 +172,34 @@ vreg_s2b_1p05: vreg-s2b-regulator {
regulator-min-microvolt = <1050000>;
regulator-max-microvolt = <1050000>;
};
+
+ cam_front_ldo: cam-front-ldo-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "cam_front_ldo";
+ regulator-min-microvolt = <1352000>;
+ regulator-max-microvolt = <1352000>;
+ regulator-enable-ramp-delay = <135>;
+
+ gpios = <&pm660l_gpios 4 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_front_ldo_pin>;
+ pinctrl-names = "default";
+ };
+
+ cam_vio_ldo: cam-vio-ldo-regulator {
+ compatible = "regulator-fixed";
+ regulator-name = "cam_vio_ldo";
+ regulator-min-microvolt = <1800000>;
+ regulator-max-microvolt = <1800000>;
+ regulator-enable-ramp-delay = <233>;
+
+ gpios = <&pm660_gpios 13 GPIO_ACTIVE_HIGH>;
+ enable-active-high;
+
+ pinctrl-0 = <&cam_vio_pin>;
+ pinctrl-names = "default";
+ };
};
&apps_rsc {
@@ -392,6 +420,64 @@ vreg_bob: bob {
};
};
+&camss {
+ vdda-phy-supply = <&vreg_l1a_1p225>;
+ vdda-pll-supply = <&vreg_s6a_0p87>;
+
+ status = "okay";
+};
+
+&camss_port1 {
+ camss_endpoint1: endpoint {
+ data-lanes = <0 1 2 3>;
+ remote-endpoint = <&cam_front_endpoint>;
+ };
+};
+
+&cci {
+ pinctrl-0 = <&cci1_default>;
+ pinctrl-1 = <&cci1_sleep>;
+ pinctrl-names = "default", "sleep";
+
+ status = "okay";
+};
+
+&cci_i2c1 {
+ camera@1a {
+ compatible = "sony,imx355";
+ reg = <0x1a>;
+
+ clocks = <&camcc CAM_CC_MCLK2_CLK>;
+
+ /*
+ * The sensor can accept a 24 MHz clock, but 19.2 MHz has
+ * better driver compatibility.
+ */
+ assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>;
+ assigned-clock-rates = <19200000>;
+
+ reset-gpios = <&tlmm 9 GPIO_ACTIVE_LOW>;
+
+ avdd-supply = <&cam_front_ldo>;
+ dvdd-supply = <&cam_front_ldo>;
+ dovdd-supply = <&cam_vio_ldo>;
+
+ pinctrl-0 = <&cam_mclk2_default>;
+ pinctrl-names = "default";
+
+ rotation = <270>;
+ orientation = <0>;
+
+ port {
+ cam_front_endpoint: endpoint {
+ data-lanes = <1 2 3 4>;
+ link-frequencies = /bits/ 64 <360000000>;
+ remote-endpoint = <&camss_endpoint1>;
+ };
+ };
+ };
+};
+
&gcc {
protected-clocks = <GCC_QSPI_CORE_CLK>,
<GCC_QSPI_CORE_CLK_SRC>,
@@ -490,6 +576,14 @@ &pm660_charger {
status = "okay";
};
+&pm660_gpios {
+ cam_vio_pin: cam-vio-state {
+ pins = "gpio13";
+ function = "normal";
+ power-source = <0>;
+ };
+};
+
&pm660_rradc {
status = "okay";
};
@@ -508,6 +602,12 @@ led-0 {
};
&pm660l_gpios {
+ cam_front_ldo_pin: cam-front-state {
+ pins = "gpio4";
+ function = "normal";
+ power-source = <0>;
+ };
+
vol_up_pin: vol-up-state {
pins = "gpio7";
function = "normal";
--
2.53.0
^ permalink raw reply related
* [PATCH v12 2/3] arm64: dts: qcom: sdm670: add camera mclk pins
From: Richard Acayan @ 2026-03-31 19:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree
Cc: Mauro Carvalho Chehab, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Vladimir Zapolskiy, Tianshu Qiu, Sakari Ailus,
linux-media, Robert Mader, David Heidelberg, phone-devel,
Richard Acayan
In-Reply-To: <20260331194437.41041-1-mailingradian@gmail.com>
The camera subsystem is added for the SoC common devicetree, but the
mclk pins should also be common across the SoC. Add the mclk pins for
the cameras.
Suggested-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Link: https://lore.kernel.org/r/5135823c-f2e4-4873-9e3a-9d190cac0113@oss.qualcomm.com
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Bryan O'Donoghue <bod@kernel.org>
Reviewed-by: David Heidelberg <david@ixit.cz>
Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 28 ++++++++++++++++++++++++++++
1 file changed, 28 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index fbd16b1f3455..f115bc6e64f3 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -1196,6 +1196,34 @@ tlmm: pinctrl@3400000 {
gpio-ranges = <&tlmm 0 0 151>;
wakeup-parent = <&pdc>;
+ cam_mclk0_default: cam-mclk0-default-state {
+ pins = "gpio13";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk1_default: cam-mclk1-default-state {
+ pins = "gpio14";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk2_default: cam-mclk2-default-state {
+ pins = "gpio15";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
+ cam_mclk3_default: cam-mclk3-default-state {
+ pins = "gpio16";
+ function = "cam_mclk";
+ drive-strength = <2>;
+ bias-disable;
+ };
+
cci0_default: cci0-default-state {
pins = "gpio17", "gpio18";
function = "cci_i2c";
--
2.53.0
^ permalink raw reply related
* [PATCH v12 1/3] arm64: dts: qcom: sdm670: label the camss ports instead of endpoints
From: Richard Acayan @ 2026-03-31 19:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree
Cc: Mauro Carvalho Chehab, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Vladimir Zapolskiy, Tianshu Qiu, Sakari Ailus,
linux-media, Robert Mader, David Heidelberg, phone-devel,
Richard Acayan
In-Reply-To: <20260331194437.41041-1-mailingradian@gmail.com>
Endpoints cannot be pre-defined since commit dcf6fb89e6f7 ("media: qcom:
camss: remove a check for unavailable CAMSS endpoint") was applied,
probing all endpoint nodes and requiring them to have a remote. There is
no sensible remote in the SoC devicetree because camera sensors are
board-specific.
The ports are meant to be extended by a board devicetree in order to
define fully configured endpoints and connect the ports to camera
sensors. For nodes that are only meaningful if extended, labels are
usually assigned. Label these ports so they can be extended directly.
Reviewed-by: Vladimir Zapolskiy <vladimir.zapolskiy@linaro.org>
Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
arch/arm64/boot/dts/qcom/sdm670.dtsi | 18 +++---------------
1 file changed, 3 insertions(+), 15 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/sdm670.dtsi b/arch/arm64/boot/dts/qcom/sdm670.dtsi
index 746e9deba526..fbd16b1f3455 100644
--- a/arch/arm64/boot/dts/qcom/sdm670.dtsi
+++ b/arch/arm64/boot/dts/qcom/sdm670.dtsi
@@ -1776,28 +1776,16 @@ ports {
#address-cells = <1>;
#size-cells = <0>;
- port@0 {
+ camss_port0: port@0 {
reg = <0>;
-
- camss_endpoint0: endpoint {
- status = "disabled";
- };
};
- port@1 {
+ camss_port1: port@1 {
reg = <1>;
-
- camss_endpoint1: endpoint {
- status = "disabled";
- };
};
- port@2 {
+ camss_port2: port@2 {
reg = <2>;
-
- camss_endpoint2: endpoint {
- status = "disabled";
- };
};
};
};
--
2.53.0
^ permalink raw reply related
* [PATCH v12 0/3] arm64: dts: qcom: sdm670-google-sargo: front camera support
From: Richard Acayan @ 2026-03-31 19:44 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree
Cc: Mauro Carvalho Chehab, Bryan O'Donoghue, Robert Foss,
Todor Tomov, Vladimir Zapolskiy, Tianshu Qiu, Sakari Ailus,
linux-media, Robert Mader, David Heidelberg, phone-devel,
Richard Acayan
This adds support for the IMX355 in devicetree and adds support for the
Pixel 3a front camera.
Changes since v11 (https://lore.kernel.org/r/20260324020132.8683-1-mailingradian@gmail.com):
- mention 24 MHz in mclk2 comment (3/3)
- drop applied patches (previously 1-4/7)
Changes since v10, 4/7 (https://lore.kernel.org/r/20260311020328.57976-1-mailingradian@gmail.com):
- add data-lanes to dts (everyone's review retained) (7/7)
Changes since v9 (https://lore.kernel.org/r/20260217002738.133534-1-mailingradian@gmail.com):
- reject zero data-lanes (4/7)
Changes since v8 (https://lore.kernel.org/r/20260210020207.10246-1-mailingradian@gmail.com):
- allow clock-lanes, but make it optional (1/7)
Changes since v7 (https://lore.kernel.org/r/20260117040657.27043-1-mailingradian@gmail.com):
- restrict data-lanes to 4 (4/7)
- include first patch (1/7)
- add back optional data-lanes in bindings (2/7)
- remove assert low on power on again (Bryan's review retained) (3/7)
- use dev_err_probe in power on (3/7)
- remove second error on probe power on (3/7)
- add review tags (2/7, 3/7, 7/7)
Changes since v6 (https://lore.kernel.org/r/20260107043044.92485-1-mailingradian@gmail.com):
- remove NAK from Krzysztof (3/6)
- assert reset GPIO on probe (3/6)
- change delays in reset sequence (3/6)
- remove __maybe_unused from OF match table (3/6)
- fix alignment for arguments to devm_regulator_bulk_get_const (3/6)
- remove front camera pin configuration (6/6)
- remove clock-lanes from camss endpoint (1/6, 6/6)
- remove data-lanes from camera sensor endpoint (2/6, 6/6)
- remove blank line at top of binding (2/6)
- add review tags (2/6, 3/6, 5/6, 6/6)
Changes since v5 (https://lore.kernel.org/r/20260107042451.92048-1-mailingradian@gmail.com):
- add Bryan to CC who added a Reviewed-by
Changes since v4 (https://lore.kernel.org/r/20251211014846.16602-1-mailingradian@gmail.com):
- add NAK from Krzysztof (2/5)
- label the camss ports (3/5, 5/5)
- define endpoint properties correctly (1/5)
- use devm_regulator_bulk_get_const (2/5)
- remove clock-names (1/5, 5/5)
- set reset GPIO as active low (1/5, 2/5, 5/5)
- explicitly drive reset low at start of sequence (2/5)
- make data-lanes in endpoint optional and start at 1 (1/5, 5/5)
- add mclk3 pin (4/5)
- add Reviewed-by's (4/5)
Changes since v3 (https://lore.kernel.org/r/20250905215516.289998-6-mailingradian@gmail.com):
- separate camera mclk pins and move to different patch (4/5, 5/5)
- remove polarity from rear camera pin (5/5)
- remove output-low from front camera pins (5/5)
- mention effects of dcf6fb89e6f7 ("media: qcom: camss: remove a check for unavailable CAMSS endpoint") (3/5)
- specify single clock-name without items nesting (1/5)
- rebase on 49c6ac166cf7 ("media: i2c: imx355: Replace client->dev
usage") and eaa7d46d9654 ("media: i2c: imx335: Use V4L2 sensor clock
helper") (2/5)
- do not use of_match_ptr for OF match table (2/5)
- remove redundant GPIO validity checks (2/5)
- describe endpoint data-lanes (1/5)
Changes since v2 (https://lore.kernel.org/r/20250714210227.714841-6-mailingradian@gmail.com):
- use devm_v4l2_sensor_clk_get (2/4)
- require supplies and clock-names (1/4)
- move unevaluatedProperties down (1/4)
- disable clocks as last power-off action (2/4)
- use 0 in gpio pin power-supply (4/4)
Changes since v1 (https://lore.kernel.org/r/20250630225944.320755-7-mailingradian@gmail.com):
- too much to have a complete list (1-4/4)
- squash camera orientation patch (4/4, previously 5/5)
- squash driver changes (2/4, previously 3/5)
- remove labelled endpoint node in sdm670.dtsi (3/4, 4/4)
- change init sequence to match other similar drivers (2/4)
- retrieve clock frequency from devicetree-defined clock (4/4)
- remove clock-frequency from dt-bindings (1/4)
- remove redundant descriptions of child nodes (1/4)
- switch initial drive of the reset GPIO to low (2/4)
- set mclk frequency to 19.2 MHz (4/4)
- add vdda-pll supply for camss (4/4)
- use common power on and off functions (2/4)
- use devm_clk_get_optional (2/4)
- remove extra layer when describing mclk pin (4/4)
- rename regulators (1/4, 2/4, 4/4)
Richard Acayan (3):
arm64: dts: qcom: sdm670: label the camss ports instead of endpoints
arm64: dts: qcom: sdm670: add camera mclk pins
arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
.../boot/dts/qcom/sdm670-google-sargo.dts | 100 ++++++++++++++++++
arch/arm64/boot/dts/qcom/sdm670.dtsi | 46 +++++---
2 files changed, 131 insertions(+), 15 deletions(-)
--
2.53.0
^ permalink raw reply
* Re: [PATCH v9 7/7] arm64: dts: qcom: sdm670-google-sargo: add imx355 front camera
From: Richard Acayan @ 2026-03-31 19:44 UTC (permalink / raw)
To: Sakari Ailus
Cc: David Heidelberg, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Robert Foss, Todor Tomov,
Bryan O'Donoghue, Vladimir Zapolskiy, Bjorn Andersson,
Konrad Dybcio, Tianshu Qiu, Robert Mader, phone-devel,
linux-arm-msm, devicetree, linux-media
In-Reply-To: <actxn5kvN3auqCBm@kekkonen.localdomain>
On Tue, Mar 31, 2026 at 10:02:55AM +0300, Sakari Ailus wrote:
> On Mon, Mar 30, 2026 at 09:27:59PM -0400, Richard Acayan wrote:
> > On Tue, Mar 24, 2026 at 12:57:59PM +0200, Sakari Ailus wrote:
> > > Hi David, Richard,
> > >
> > > On Tue, Mar 24, 2026 at 10:35:24AM +0100, David Heidelberg wrote:
> > > >
> > > >
> > > > On 24/03/2026 03:05, Richard Acayan wrote:
> > > > > On Fri, Mar 13, 2026 at 07:26:47PM +0100, David Heidelberg wrote:
> > > > > > On 17/02/2026 01:27, Richard Acayan wrote:
> > > > > > [...]
> > > > > >
> > > > > > > +&cci_i2c1 {
> > > > > > > + camera@1a {
> > > > > > > + compatible = "sony,imx355";
> > > > > > > + reg = <0x1a>;
> > > > > > > +
> > > > > > > + clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > > +
> > > > > > > + assigned-clocks = <&camcc CAM_CC_MCLK2_CLK>;
> > > > > > > + assigned-clock-rates = <19200000>;
> > > > > >
> > > > > > Extract from #sdm670-mainline:erebion.eu discussion:
> > > > > > The imx355 can operate on 24 MHz (on both Pixel 3 and 3a), but Linux kernel
> > > > > > driver can operate only with 19.2 MHz.
> > > > > >
> > > > > > I assume it would be worth it mention at least by comment here.
> > > > >
> > > > > This might set the series back because the devicetree isn't meant to be
> > > > > written for specific software, but it's included in v11 because you
> > > > > already asked twice.
> > > > >
> > > >
> > > > I would say node with lower clock frequency is still much better than
> > > > nothing or placeholder saying "i2c camera here". Instead we'll have small
> > > > placeholder that value can be bumped to 24 MHz. Important is this can be
> > > > easily improved when at least one consumer of the device-tree gains support.
> > > >
> > > > We have very scarce support of cameras on mobile phones in mainline, thus
> > > > leaving a comment that HW can do 24 MHz is reasonable compromise IMHO.
> > >
> > > The bindings could document the supported frequency range.
> > >
> > > In DTS it may make sense to set the frequency the vendor uses as it may
> > > affect the link frequencies (albeit I guess they're the same in this
> > > case?).
> >
> > Is this review relevant to v11?
>
> I'd think so: it doesn't mention the frequency should be 24 MHz.
Ok, please check the dts comment in v12 when I send it and continue there.
^ permalink raw reply
* Re: [PATCH v4 3/3] arm64: dts: rockchip: Add Orange Pi 5 Pro board support
From: Dennis Gilmore @ 2026-03-31 19:41 UTC (permalink / raw)
To: Alexey Charkov
Cc: Jimmy Hon, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Heiko Stuebner, FUKAUMI Naoki, Hsun Lai, Jonas Karlman,
Chaoyi Chen, John Clark, Michael Opdenacker, Quentin Schulz,
Andrew Lunn, Chukun Pan, Peter Robinson, Michael Riesch,
Mykola Kvach, devicetree, linux-arm-kernel, linux-rockchip,
linux-kernel
In-Reply-To: <CABjd4Yz3MKOp-gE8kNc4EOt3-a0mKZsxvbVYCN4KsbqTRDtWgA@mail.gmail.com>
On Wed, Mar 11, 2026 at 9:26 AM Alexey Charkov <alchark@gmail.com> wrote:
>
> On Wed, Mar 11, 2026 at 5:29 AM Dennis Gilmore <dennis@ausil.us> wrote:
> >
> > On Tue, Mar 10, 2026 at 7:20 PM Jimmy Hon <honyuenkwun@gmail.com> wrote:
> > >
> > > <snip>
> > > > +
> > > > + vcc5v0_otg: regulator-vcc5v0-otg {
> > > > + compatible = "regulator-fixed";
> > > > + enable-active-high;
> > > > + gpios = <&gpio0 RK_PC4 GPIO_ACTIVE_HIGH>;
> > > > + pinctrl-names = "default";
> > > > + pinctrl-0 = <&vcc5v0_otg_en>;
> > > > + regulator-always-on;
> > > > + regulator-boot-on;
> > > regulator-always-on and regulator-boot-on does not seem right.
> > >
> > > Why were these added? The vendor did not have them.
> > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L216-L226
> > >
> > > Was this mistakenly taken from the regulator usb 20 which is powering
> > > the onboard usb2.0 hub?
> > > https://github.com/orangepi-xunlong/linux-orangepi/blob/232ed4b97b65da2b7b647c4e3c496f8594b9f3f1/arch/arm64/boot/dts/rockchip/rk3588s-orangepi-5-pro.dts#L111-L119
> >
> > It may have been a missreading of the schematic, but it was added to
> > get power to the USB3 port. before I added it devices plugged into the
> > USB 3 port would not power on
>
> Hi Dennis,
>
> The schematic says that this regulator supplies the VBUS voltage for
> the USB3 part of your Type-A OTG connector. If you make it always-on,
> you'll likely lose the possibility to use this port in device mode
> (which you would need e.g. for flashing images over a USB cable in
> U-boot which also takes device tree sources from Linux via
> devicetree-rebasing).
>
> You also link it up as the PHY supply of the USB2 controller, which
> doesn't describe the actual hardware.
>
> Please see if you'd rather define a connector node for your Type-A
> port, and list this regulator as its VBUS supply explicitly. I've
> recently submitted a patch [1] to make the "onboard_usb_dev" driver
> take care of enabling VBUS in exactly this type of situations (it's in
> usb-testing now and will hopefully hit -next sometime soon). If you
> need an example for its use, please refer to [2].
>
> Best regards,
> Alexey
>
> [1] https://lore.kernel.org/all/20260217-typea-vbus-v1-1-657b4e55a4c2@flipper.net/
> [2] https://github.com/flipperdevices/flipper-linux-kernel/blob/2f814cdf07f50e901fc1b1328213e76460864c20/arch/arm64/boot/dts/rockchip/rk3576-flipper-one-rev-f0b0c1.dts#L303-L328
Sorry for the delay, I am taking a look at it now. Please let me know
when it lands in -next. In the meantime, I believe what I have is in
good shape and is working well here. I am happy to make a change once
support lands upstream.
Dennis
^ permalink raw reply
* [PATCH v3 15/15] ASoC: msm8916-wcd-analog: add quirk for cajon 2.0
From: Richard Acayan @ 2026-03-31 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik, Konrad Dybcio, linux-sound, linux-arm-msm,
devicetree
Cc: Nickolay Goppen, Adam Skladowski, Vladimir Lypak,
Dmitry Baryshkov, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Richard Acayan
In-Reply-To: <20260331193939.40636-1-mailingradian@gmail.com>
The codec version CAJON_2_0 on the Snapdragon 670 requires touching the
HPH test registers. Add the quirk so this driver can also support
SDM670.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
sound/soc/codecs/msm8916-wcd-analog.c | 63 ++++++++++++++++++++++++++-
1 file changed, 61 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/msm8916-wcd-analog.c b/sound/soc/codecs/msm8916-wcd-analog.c
index b9325290c28d..87f8a47cc293 100644
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -217,9 +217,11 @@
#define CDC_A_RX_HPH_BIAS_LDO_OCP (0xf195)
#define CDC_A_RX_HPH_BIAS_CNP (0xf196)
#define CDC_A_RX_HPH_CNP_EN (0xf197)
+#define CDC_A_RX_HPH_L_TEST (0xf19A)
#define CDC_A_RX_HPH_L_PA_DAC_CTL (0xf19B)
#define RX_HPA_L_PA_DAC_CTL_DATA_RESET_MASK BIT(1)
#define RX_HPA_L_PA_DAC_CTL_DATA_RESET_RESET BIT(1)
+#define CDC_A_RX_HPH_R_TEST (0xf19C)
#define CDC_A_RX_HPH_R_PA_DAC_CTL (0xf19D)
#define RX_HPH_R_PA_DAC_CTL_DATA_RESET BIT(1)
#define RX_HPH_R_PA_DAC_CTL_DATA_RESET_MASK BIT(1)
@@ -705,6 +707,59 @@ static int pm8916_wcd_analog_enable_ear_pa(struct snd_soc_dapm_widget *w,
return 0;
}
+static int pm8916_wcd_analog_enable_hphl_pa(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm);
+ struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
+
+ /* This quirk is not required for revisions prior to CAJON_2_0 */
+ if (priv->codec_version < 4)
+ return 0;
+
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMU:
+ usleep_range(7000, 7100);
+ snd_soc_component_update_bits(component, CDC_A_RX_HPH_L_TEST,
+ 0x04, 0x04);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ /* wait 20 ms after the digital codec has powered down */
+ msleep(20);
+ snd_soc_component_update_bits(component, CDC_A_RX_HPH_L_TEST,
+ 0x04, 0x00);
+ break;
+ }
+ return 0;
+}
+
+static int pm8916_wcd_analog_enable_hphr_pa(struct snd_soc_dapm_widget *w,
+ struct snd_kcontrol *kcontrol,
+ int event)
+{
+ struct snd_soc_component *component = snd_soc_dapm_to_component(w->dapm);
+ struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
+
+ /* This quirk is not required for revisions prior to CAJON_2_0 */
+ if (priv->codec_version < 4)
+ return 0;
+
+ switch (event) {
+ case SND_SOC_DAPM_POST_PMU:
+ usleep_range(7000, 7100);
+ snd_soc_component_update_bits(component, CDC_A_RX_HPH_R_TEST,
+ 0x04, 0x04);
+ break;
+ case SND_SOC_DAPM_POST_PMD:
+ msleep(20);
+ snd_soc_component_update_bits(component, CDC_A_RX_HPH_R_TEST,
+ 0x04, 0x00);
+ break;
+ }
+ return 0;
+}
+
static const struct reg_default wcd_reg_defaults_2_0[] = {
{CDC_A_RX_COM_OCP_CTL, 0xD1},
{CDC_A_RX_COM_OCP_COUNT, 0xFF},
@@ -954,11 +1009,15 @@ static const struct snd_soc_dapm_widget pm8916_wcd_analog_dapm_widgets[] = {
SND_SOC_DAPM_MUX("EAR_S", SND_SOC_NOPM, 0, 0, &ear_mux),
SND_SOC_DAPM_SUPPLY("EAR CP", CDC_A_NCP_EN, 4, 0, NULL, 0),
- SND_SOC_DAPM_PGA("HPHL PA", CDC_A_RX_HPH_CNP_EN, 5, 0, NULL, 0),
+ SND_SOC_DAPM_PGA_E("HPHL PA", CDC_A_RX_HPH_CNP_EN, 5, 0, NULL, 0,
+ pm8916_wcd_analog_enable_hphl_pa,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_MUX("HPHL", SND_SOC_NOPM, 0, 0, &hphl_mux),
SND_SOC_DAPM_MIXER("HPHL DAC", CDC_A_RX_HPH_L_PA_DAC_CTL, 3, 0, NULL,
0),
- SND_SOC_DAPM_PGA("HPHR PA", CDC_A_RX_HPH_CNP_EN, 4, 0, NULL, 0),
+ SND_SOC_DAPM_PGA_E("HPHR PA", CDC_A_RX_HPH_CNP_EN, 4, 0, NULL, 0,
+ pm8916_wcd_analog_enable_hphr_pa,
+ SND_SOC_DAPM_POST_PMU | SND_SOC_DAPM_POST_PMD),
SND_SOC_DAPM_MUX("HPHR", SND_SOC_NOPM, 0, 0, &hphr_mux),
SND_SOC_DAPM_MIXER("HPHR DAC", CDC_A_RX_HPH_R_PA_DAC_CTL, 3, 0, NULL,
0),
--
2.53.0
^ permalink raw reply related
* [PATCH v3 14/15] ASoC: msm8916-wcd-analog: add pm8953 codec
From: Richard Acayan @ 2026-03-31 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik, Konrad Dybcio, linux-sound, linux-arm-msm,
devicetree
Cc: Nickolay Goppen, Adam Skladowski, Vladimir Lypak,
Dmitry Baryshkov, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Richard Acayan
In-Reply-To: <20260331193939.40636-1-mailingradian@gmail.com>
From: Vladimir Lypak <vladimir.lypak@gmail.com>
Add regs overrides for PM8953 codec.
Signed-off-by: Vladimir Lypak <vladimir.lypak@gmail.com>
[Adam: rename codec]
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
sound/soc/codecs/msm8916-wcd-analog.c | 29 +++++++++++++++++++++++++++
1 file changed, 29 insertions(+)
diff --git a/sound/soc/codecs/msm8916-wcd-analog.c b/sound/soc/codecs/msm8916-wcd-analog.c
index 13df60409857..b9325290c28d 100644
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -755,6 +755,34 @@ static const struct wcd_reg_seq pm8950_data = {
.seq_size = ARRAY_SIZE(wcd_reg_defaults_pm8950),
};
+static const struct reg_default wcd_reg_defaults_pm8953[] = {
+ {CDC_A_RX_COM_OCP_CTL, 0xd1},
+ {CDC_A_RX_COM_OCP_COUNT, 0xff},
+ {CDC_D_SEC_ACCESS, 0xa5},
+ {CDC_D_PERPH_RESET_CTL3, 0x0f},
+ {CDC_A_TX_1_2_OPAMP_BIAS, 0x4c},
+ {CDC_A_NCP_FBCTRL, 0xa8},
+ {CDC_A_NCP_VCTRL, 0xa4},
+ {CDC_A_SPKR_DRV_CTL, 0x69},
+ {CDC_A_SPKR_DRV_DBG, 0x01},
+ {CDC_A_SEC_ACCESS, 0xa5},
+ {CDC_A_PERPH_RESET_CTL3, 0x0f},
+ {CDC_A_CURRENT_LIMIT, 0xa2},
+ {CDC_A_BYPASS_MODE, 0x18},
+ {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
+ {CDC_A_SPKR_DAC_CTL, 0x03},
+ {CDC_A_SPKR_OCP_CTL, 0xe1},
+ {CDC_A_RX_HPH_BIAS_PA, 0xfa},
+ {CDC_A_RX_EAR_STATUS, 0x10},
+ {CDC_A_MASTER_BIAS_CTL, 0x30},
+ {CDC_A_MICB_1_INT_RBIAS, 0x00},
+};
+
+static const struct wcd_reg_seq pm8953_data = {
+ .seq = wcd_reg_defaults_pm8953,
+ .seq_size = ARRAY_SIZE(wcd_reg_defaults_pm8953),
+};
+
static int pm8916_wcd_analog_probe(struct snd_soc_component *component)
{
struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
@@ -1304,6 +1332,7 @@ static int pm8916_wcd_analog_spmi_probe(struct platform_device *pdev)
static const struct of_device_id pm8916_wcd_analog_spmi_match_table[] = {
{ .compatible = "qcom,pm8916-wcd-analog-codec", .data = &pm8916_data },
{ .compatible = "qcom,pm8950-wcd-analog-codec", .data = &pm8950_data },
+ { .compatible = "qcom,pm8953-wcd-analog-codec", .data = &pm8953_data },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 13/15] ASoC: msm8916-wcd-analog: add pm8950 codec
From: Richard Acayan @ 2026-03-31 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik, Konrad Dybcio, linux-sound, linux-arm-msm,
devicetree
Cc: Nickolay Goppen, Adam Skladowski, Vladimir Lypak,
Dmitry Baryshkov, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Richard Acayan
In-Reply-To: <20260331193939.40636-1-mailingradian@gmail.com>
From: Adam Skladowski <a39.skl@gmail.com>
Add regs overrides for PM8950 codec and implement matching reg overrides
via compatible.
Signed-off-by: Adam Skladowski <a39.skl@gmail.com>
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
sound/soc/codecs/msm8916-wcd-analog.c | 52 ++++++++++++++++++++++++---
1 file changed, 48 insertions(+), 4 deletions(-)
diff --git a/sound/soc/codecs/msm8916-wcd-analog.c b/sound/soc/codecs/msm8916-wcd-analog.c
index 9ca381812975..13df60409857 100644
--- a/sound/soc/codecs/msm8916-wcd-analog.c
+++ b/sound/soc/codecs/msm8916-wcd-analog.c
@@ -232,6 +232,8 @@
#define RX_EAR_CTL_PA_SEL_MASK BIT(7)
#define RX_EAR_CTL_PA_SEL BIT(7)
+#define CDC_A_RX_EAR_STATUS (0xf1A1)
+
#define CDC_A_SPKR_DAC_CTL (0xf1B0)
#define SPKR_DAC_CTL_DAC_RESET_MASK BIT(4)
#define SPKR_DAC_CTL_DAC_RESET_NORMAL 0
@@ -250,6 +252,7 @@
SPKR_DRV_CAL_EN | SPKR_DRV_SETTLE_EN | \
SPKR_DRV_FW_EN | SPKR_DRV_BOOST_SET | \
SPKR_DRV_CMFB_SET | SPKR_DRV_GAIN_SET)
+#define CDC_A_SPKR_ANA_BIAS_SET (0xf1B3)
#define CDC_A_SPKR_OCP_CTL (0xf1B4)
#define CDC_A_SPKR_PWRSTG_CTL (0xf1B5)
#define SPKR_PWRSTG_CTL_DAC_EN_MASK BIT(0)
@@ -264,6 +267,7 @@
#define CDC_A_SPKR_DRV_DBG (0xf1B7)
#define CDC_A_CURRENT_LIMIT (0xf1C0)
+#define CDC_A_BYPASS_MODE (0xf1C2)
#define CDC_A_BOOST_EN_CTL (0xf1C3)
#define CDC_A_SLOPE_COMP_IP_ZERO (0xf1C4)
#define CDC_A_SEC_ACCESS (0xf1D0)
@@ -286,6 +290,11 @@ static const char * const supply_names[] = {
#define MBHC_MAX_BUTTONS (5)
+struct wcd_reg_seq {
+ const struct reg_default *seq;
+ int seq_size;
+};
+
struct pm8916_wcd_analog_priv {
u16 pmic_rev;
u16 codec_version;
@@ -715,9 +724,41 @@ static const struct reg_default wcd_reg_defaults_2_0[] = {
{CDC_A_MASTER_BIAS_CTL, 0x30},
};
+static const struct wcd_reg_seq pm8916_data = {
+ .seq = wcd_reg_defaults_2_0,
+ .seq_size = ARRAY_SIZE(wcd_reg_defaults_2_0),
+};
+
+static const struct reg_default wcd_reg_defaults_pm8950[] = {
+ {CDC_A_RX_COM_OCP_CTL, 0xd1},
+ {CDC_A_RX_COM_OCP_COUNT, 0xff},
+ {CDC_D_SEC_ACCESS, 0xa5},
+ {CDC_D_PERPH_RESET_CTL3, 0x0f},
+ {CDC_A_TX_1_2_OPAMP_BIAS, 0x4c},
+ {CDC_A_NCP_FBCTRL, 0xa8},
+ {CDC_A_NCP_VCTRL, 0xa4},
+ {CDC_A_SPKR_DRV_CTL, 0x69},
+ {CDC_A_SPKR_DRV_DBG, 0x01},
+ {CDC_A_SEC_ACCESS, 0xa5},
+ {CDC_A_PERPH_RESET_CTL3, 0x0f},
+ {CDC_A_CURRENT_LIMIT, 0x82},
+ {CDC_A_SPKR_ANA_BIAS_SET, 0x41},
+ {CDC_A_SPKR_DAC_CTL, 0x03},
+ {CDC_A_SPKR_OCP_CTL, 0xe1},
+ {CDC_A_RX_HPH_BIAS_PA, 0xfa},
+ {CDC_A_MASTER_BIAS_CTL, 0x30},
+ {CDC_A_MICB_1_INT_RBIAS, 0x00},
+};
+
+static const struct wcd_reg_seq pm8950_data = {
+ .seq = wcd_reg_defaults_pm8950,
+ .seq_size = ARRAY_SIZE(wcd_reg_defaults_pm8950),
+};
+
static int pm8916_wcd_analog_probe(struct snd_soc_component *component)
{
struct pm8916_wcd_analog_priv *priv = dev_get_drvdata(component->dev);
+ const struct wcd_reg_seq *wcd_reg_init_data;
int err, reg;
err = regulator_bulk_enable(ARRAY_SIZE(priv->supplies), priv->supplies);
@@ -738,9 +779,11 @@ static int pm8916_wcd_analog_probe(struct snd_soc_component *component)
snd_soc_component_write(component, CDC_D_PERPH_RESET_CTL4, 0x01);
snd_soc_component_write(component, CDC_A_PERPH_RESET_CTL4, 0x01);
- for (reg = 0; reg < ARRAY_SIZE(wcd_reg_defaults_2_0); reg++)
- snd_soc_component_write(component, wcd_reg_defaults_2_0[reg].reg,
- wcd_reg_defaults_2_0[reg].def);
+ wcd_reg_init_data = of_device_get_match_data(component->dev);
+
+ for (reg = 0; reg < wcd_reg_init_data->seq_size; reg++)
+ snd_soc_component_write(component, wcd_reg_init_data->seq[reg].reg,
+ wcd_reg_init_data->seq[reg].def);
priv->component = component;
@@ -1259,7 +1302,8 @@ static int pm8916_wcd_analog_spmi_probe(struct platform_device *pdev)
}
static const struct of_device_id pm8916_wcd_analog_spmi_match_table[] = {
- { .compatible = "qcom,pm8916-wcd-analog-codec", },
+ { .compatible = "qcom,pm8916-wcd-analog-codec", .data = &pm8916_data },
+ { .compatible = "qcom,pm8950-wcd-analog-codec", .data = &pm8950_data },
{ }
};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 12/15] ASoC: qcom: sm8250: add SDM660 compatible
From: Richard Acayan @ 2026-03-31 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik, Konrad Dybcio, linux-sound, linux-arm-msm,
devicetree
Cc: Nickolay Goppen, Adam Skladowski, Vladimir Lypak,
Dmitry Baryshkov, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Richard Acayan
In-Reply-To: <20260331193939.40636-1-mailingradian@gmail.com>
Add the compatible for SDM660 and SDM670 devices, which can use the
support for WCD codecs connected to internal MI2S.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
sound/soc/qcom/sm8250.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/sound/soc/qcom/sm8250.c b/sound/soc/qcom/sm8250.c
index b8f1c91725df..84898bfff7d8 100644
--- a/sound/soc/qcom/sm8250.c
+++ b/sound/soc/qcom/sm8250.c
@@ -210,6 +210,7 @@ static const struct of_device_id snd_sm8250_dt_match[] = {
{ .compatible = "qcom,qrb2210-sndcard", .data = "qcm2290" },
{ .compatible = "qcom,qrb4210-rb2-sndcard", .data = "sm4250" },
{ .compatible = "qcom,qrb5165-rb5-sndcard", .data = "sm8250" },
+ { .compatible = "qcom,sdm660-sndcard", .data = "sdm660" },
{ .compatible = "qcom,sm8250-sndcard", .data = "sm8250" },
{}
};
--
2.53.0
^ permalink raw reply related
* [PATCH v3 11/15] ASoC: qcom: sm8250: add support for INT0_MI2S_RX and INT3_MI2S_TX
From: Richard Acayan @ 2026-03-31 19:39 UTC (permalink / raw)
To: Srinivas Kandagatla, Liam Girdwood, Mark Brown, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Jaroslav Kysela, Takashi Iwai,
Mohammad Rafi Shaik, Konrad Dybcio, linux-sound, linux-arm-msm,
devicetree
Cc: Nickolay Goppen, Adam Skladowski, Vladimir Lypak,
Dmitry Baryshkov, Wesley Cheng, Greg Kroah-Hartman, Johan Hovold,
Kees Cook, Charles Keepax, Kuninori Morimoto, Richard Acayan
In-Reply-To: <20260331193939.40636-1-mailingradian@gmail.com>
The INT0_MI2S_RX and INT3_MI2S_TX ports on SDM660 can be connected to
the digital and analog WCD codecs. They can be supported with the same
logic for other ports, but just need to be explicitly stated. Add
support for these ports.
Signed-off-by: Richard Acayan <mailingradian@gmail.com>
---
sound/soc/qcom/sm8250.c | 16 ++++++++++++++++
1 file changed, 16 insertions(+)
diff --git a/sound/soc/qcom/sm8250.c b/sound/soc/qcom/sm8250.c
index f193d0ba63d0..b8f1c91725df 100644
--- a/sound/soc/qcom/sm8250.c
+++ b/sound/soc/qcom/sm8250.c
@@ -112,6 +112,22 @@ static int sm8250_snd_startup(struct snd_pcm_substream *substream)
snd_soc_dai_set_fmt(cpu_dai, fmt);
snd_soc_dai_set_fmt(codec_dai, codec_dai_fmt);
break;
+ case INT0_MI2S_RX:
+ codec_dai_fmt |= SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_I2S;
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_INT0_MI2S_IBIT,
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ snd_soc_dai_set_fmt(cpu_dai, fmt);
+ snd_soc_dai_set_fmt(codec_dai, codec_dai_fmt);
+ break;
+ case INT3_MI2S_TX:
+ codec_dai_fmt |= SND_SOC_DAIFMT_NB_NF | SND_SOC_DAIFMT_I2S;
+ snd_soc_dai_set_sysclk(cpu_dai,
+ Q6AFE_LPASS_CLK_ID_INT3_MI2S_IBIT,
+ MI2S_BCLK_RATE, SNDRV_PCM_STREAM_PLAYBACK);
+ snd_soc_dai_set_fmt(cpu_dai, fmt);
+ snd_soc_dai_set_fmt(codec_dai, codec_dai_fmt);
+ break;
default:
break;
}
--
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