* Re: [PATCH v4 2/2] pinctrl: ultrarisc: Add UltraRISC DP1000 pinctrl driver
From: Nathan Chancellor @ 2026-06-13 16:48 UTC (permalink / raw)
To: Jia Wang, Linus Walleij
Cc: Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Bartosz Golaszewski, linux-gpio, devicetree, linux-kernel
In-Reply-To: <20260610-ultrarisc-pinctrl-v4-2-b7e9b2a8ed84@ultrarisc.com>
On Wed, Jun 10, 2026 at 01:29:56PM +0800, Jia Wang wrote:
> diff --git a/drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.c b/drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.c
> new file mode 100644
> index 000000000000..8fb5b0ea5b93
> --- /dev/null
> +++ b/drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.c
...
> +static bool ur_function_is_gpio(struct pinctrl_dev *pctldev,
> + unsigned int selector)
> +{
> + const struct function_desc *function;
> +
> + function = pinmux_generic_get_function(pctldev, selector);
> + if (!function)
> + return false;
> +
> + for (u32 i = 0; i < function->func->ngroups; i++) {
> + const char *func_name;
> + int group_selector;
> +
> + group_selector = pinctrl_get_group_selector(pctldev,
> + function->func->groups[i]);
> + if (group_selector < 0)
> + return false;
> +
> + func_name = ur_get_group_function(pctldev, group_selector, 0);
> + if (!func_name || strcmp(func_name, "gpio"))
> + return false;
> + }
> +
> + return true;
> +}
The usage of pinctrl_get_group_selector() in this function breaks the
build when this driver is a module because pinctrl_get_group_selector()
is not exported for modules:
ERROR: modpost: "pinctrl_get_group_selector" [drivers/pinctrl/ultrarisc/pinctrl-ultrarisc.ko] undefined!
Also reported by the robots:
https://lore.kernel.org/202606130210.ytVPxHlm-lkp@intel.com/
--
Cheers,
Nathan
^ permalink raw reply
* Re: [PATCH 2/4] iio: adc: mt6323-auxadc: add mt6323 PMIC AUXADC driver
From: David Lechner @ 2026-06-13 16:42 UTC (permalink / raw)
To: Roman Vivchar, Nuno Sá
Cc: Jonathan Cameron, Nuno Sá, Andy Shevchenko, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Matthias Brugger,
AngeloGioacchino Del Regno, Lee Jones, linux-iio, devicetree,
linux-kernel, linux-arm-kernel, linux-mediatek, Ben Grisdale
In-Reply-To: <RRvh9UBBrqdfKoCLaqgfcQ06UY-BSM2hQ0F6F1YkdB2k2RXYMQmlCG4phXk72oGY03t1g1kDI4z-SDeKlYkUv84-AjNLaWK7tDQlpEFQVKk=@protonmail.com>
On 6/3/26 6:24 AM, Roman Vivchar wrote:
> Hi Nuno,
>
> On Tuesday, June 2nd, 2026 at 7:42 PM, Nuno Sá <noname.nuno@gmail.com> wrote:
>
>> On Tue, 2026-06-02 at 15:46 +0300, Roman Vivchar via B4 Relay wrote:
>
> ...
>
>>>
>>> +MEDIATEK MT6323 PMIC AUXADC DRIVER
>>> +M: Roman Vivchar <rva333@protonmail.com>
>>> +L: linux-iio@vger.kernel.org
>>> +L: linux-mediatek@lists.infradead.org (moderated for non-subscribers)
>>> +S: Maintained
>>> +F: drivers/iio/adc/mt6323-auxadc.c
>>> +F: include/dt-bindings/iio/adc/mediatek,mt6323-auxadc.h
>>
>> The above file was not added in this patch
>
> The header file is added in patch 1 (dt-bindings). Following Krzysztof's
> feedback on the previous version, I squashed the MAINTAINERS into this patch.
> Please let me know if I misunderstood anything.
Usually, we want the MAINTAINERS entry in the same patch that
the file was added. It is fine to include MAINTAINERS changes
in the dt-bindings patch.
>>> + case IIO_CHAN_INFO_RAW:
>>> + scoped_guard(mutex, &auxadc->lock) {
We can avoid extra indent by making this:
case IIO_CHAN_INFO_RAW: {
guard(mutex)(&auxadc->lock);
...
return IIO_VAL_INT;
}
>>> + ret = mt6323_auxadc_prepare_channel(auxadc);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + ret = mt6323_auxadc_request(auxadc, chan->channel);
>>> + if (ret)
>>> + return ret;
>>> +
>>> + /* Hardware limitation: the AUXADC needs a delay to become
>>> ready. */
>>> + fsleep(300);
>>> +
>>> + ret = mt6323_auxadc_read(auxadc, chan, val);
>>> + if (ret)
>>> + return ret;
>>
>> Could be return mt6323_auxadc_read(...)
>
> The mt6323_auxadc_read returns 0, while IIO expects IIO_VAL_INT (defined as 1).
> Should the mt6323_auxadc_read function return 1 for success?
mt6323_auxadc_read() would need to return IIO_VAL_INT.
^ permalink raw reply
* [PATCH] dt-bindings: usb: ti,tps6598x: add TPS6699x compatible
From: Radhey Shyam Pandey @ 2026-06-13 16:23 UTC (permalink / raw)
To: gregkh, robh, krzk+dt, conor+dt, bryan.odonoghue
Cc: linux-usb, devicetree, linux-kernel, Radhey Shyam Pandey
Add a ti,tps6699x compatible to explicitly identify TPS6699x devices.
The TPS6699x family is not host-interface compatible with TPS6598x, so
a distinct compatible is required.
Signed-off-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
---
Documentation/devicetree/bindings/usb/ti,tps6598x.yaml | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
index 1745e28b3110..76c9cc392a40 100644
--- a/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
+++ b/Documentation/devicetree/bindings/usb/ti,tps6598x.yaml
@@ -4,13 +4,14 @@
$id: http://devicetree.org/schemas/usb/ti,tps6598x.yaml#
$schema: http://devicetree.org/meta-schemas/core.yaml#
-title: Texas Instruments 6598x Type-C Port Switch and Power Delivery controller
+title: Texas Instruments Type-C port switch and USB Power Delivery controllers
maintainers:
- Bryan O'Donoghue <bryan.odonoghue@linaro.org>
description: |
- Texas Instruments 6598x Type-C Port Switch and Power Delivery controller
+ Texas Instruments devices (6598x/6699x) that combine a USB Type-C port
+ switch and Power Delivery controller.
A variant of this controller known as Apple CD321x or Apple ACE is also
present on hardware with Apple SoCs such as the M1.
@@ -19,6 +20,7 @@ properties:
compatible:
enum:
- ti,tps6598x
+ - ti,tps6699x
- apple,cd321x
- ti,tps25750
base-commit: c425609d6ac4012c8bbf01ec2e10e801b1923a7b
--
2.49.1
^ permalink raw reply related
* Re: [PATCH v10 4/6] dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
From: Paul Kocialkowski @ 2026-06-13 16:11 UTC (permalink / raw)
To: sashiko-reviews; +Cc: conor+dt, devicetree, robh, linux-sunxi
In-Reply-To: <20260613153532.EA04E1F000E9@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2439 bytes --]
Hi,
Le Sat 13 Jun 26, 15:35, sashiko-bot@kernel.org a écrit :
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The newly added V3s compatible string is for an rx-only hardware variant, but the binding schema allows it to incorrectly default to `tx`.
> --
>
> commit 2fd664ce10fb7edbf45c93a3bcbbd8adb0bad2ea
> Author: Paul Kocialkowski <paulk@sys-base.io>
>
> dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
>
> The V3s/V3/S3 comes with a rx-only D-PHY paired with the MIPI CSI-2
> controller. It is compatible with the D-PHY found on the A31.
> Add an entry with a new compatible and the A31 compatible as fallback.
>
> > diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > index 6a4fd49299590..3ca1a1c47032f 100644
> > --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> > @@ -21,6 +21,9 @@ properties:
> > - items:
> > - const: allwinner,sun50i-a64-mipi-dphy
> > - const: allwinner,sun6i-a31-mipi-dphy
> > + - items:
> > + - const: allwinner,sun8i-v3s-mipi-dphy
> > + - const: allwinner,sun6i-a31-mipi-dphy
>
> [Severity: Medium]
> Since the commit message indicates the V3s D-PHY is rx-only, should this
> schema include an if-then block to enforce the rx direction?
>
> The base binding defines allwinner,direction with a default of tx:
>
> allwinner,direction:
> ...
> enum:
> - tx
> - rx
> default: tx
>
> Without an allOf if-then block constraining this property for the
> allwinner,sun8i-v3s-mipi-dphy compatible string, a V3s device tree node
> that omits the property will implicitly default to tx.
>
> Would this allow an incomplete device tree node to pass schema validation
> while misconfiguring the rx-only hardware?
That is correct, but maybe a bit over the top. If someone thinks this
should be done, feel free to let me know and I can respin.
All the best,
Paul
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v1 2/4] arm64: dts: qcom: sm8550: Add JPEG encoder node
From: Atanas Filipov @ 2026-06-13 16:05 UTC (permalink / raw)
To: Bryan O'Donoghue, linux-media
Cc: mchehab, robh, krzk+dt, conor+dt, andersson, konradybcio,
linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <2ad008a6-bf67-4854-906a-bd2ba395cfba@kernel.org>
Checked. The MMCX/MXC dependency is covered transitively — camcc
itself declares:
power-domains = <&rpmhpd RPMHPD_MMCX>, <&rpmhpd RPMHPD_MXC>;
CAM_CC_TITAN_TOP_GDSC is a subdomain of camcc, so the RPMh votes are
enforced before any consumer is powered on.
This matches the pattern used by every other single-GDSC camera node
in the upstream tree (cci0/1/2 on sm8250, sm8550, sm8650) — none of
them list MMCX/MXC directly. No change needed.
afilipov
On 6/13/2026 2:52 AM, Bryan O'Donoghue wrote:
> On 12/06/2026 20:44, Atanas Filipov wrote:
>> + power-domains = <&camcc CAM_CC_TITAN_TOP_GDSC>;
>
> This almost certainly should contain MMCX and MXC too.
>
> Please check.
>
> ---
> bod
^ permalink raw reply
* Re: [PATCH v10 5/6] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: Paul Kocialkowski @ 2026-06-13 16:04 UTC (permalink / raw)
To: sashiko-reviews; +Cc: robh, linux-sunxi, conor+dt, devicetree
In-Reply-To: <20260613154131.A62201F000E9@smtp.kernel.org>
[-- Attachment #1: Type: text/plain, Size: 2647 bytes --]
Hi,
Le Sat 13 Jun 26, 15:41, sashiko-bot@kernel.org a écrit :
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Low] The `csi0` node introduces the `interconnects` and `interconnect-names` properties, but these are not defined in the corresponding dt-binding schema `allwinner,sun6i-a31-csi.yaml`.
> --
>
> commit 6348731e0b0149fecdb9ccb7d05f8577710a1724
> Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
>
> ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
>
> This commit adds MIPI CSI-2 support for the V3s SoC by introducing nodes
> for CSI0, the MIPI CSI-2 bridge, and the D-PHY. The CSI0 node includes
> interconnect properties to inherit the proper DMA offsets.
>
> > diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> > index 02d6c62b3874e..03a1739683b16 100644
> > --- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> > +++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> [ ... ]
> > @@ -671,6 +671,79 @@ gic: interrupt-controller@1c81000 {
> > interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> > };
> >
> > + csi0: camera@1cb0000 {
> > + compatible = "allwinner,sun8i-v3s-csi";
> > + reg = <0x01cb0000 0x1000>;
> > + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> > + clocks = <&ccu CLK_BUS_CSI>,
> > + <&ccu CLK_CSI_SCLK>,
> > + <&ccu CLK_DRAM_CSI>;
> > + clock-names = "bus", "mod", "ram";
> > + resets = <&ccu RST_BUS_CSI>;
> > + interconnects = <&mbus 5>;
> > + interconnect-names = "dma-mem";
>
> [Severity: Low]
> Will adding these properties cause a dtbs_check validation warning?
>
> The interconnects and interconnect-names properties do not appear to be
> defined in the corresponding dt-binding schema at
> Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml.
Patches to enable said properties in the binding were accepted already.
All the best,
Paul
> Because that schema enforces additionalProperties: false, introducing
> undocumented properties here might result in a validation failure. Should
> the schema be updated alongside this patch to allow these interconnect
> properties?
>
> > + status = "disabled";
> > +
> [ ... ]
>
> --
> Sashiko AI review · https://sashiko.dev/#/patchset/20260613152655.212490-1-paulk@sys-base.io?part=5
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH v10 5/6] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: sashiko-bot @ 2026-06-13 15:41 UTC (permalink / raw)
To: Paul Kocialkowski; +Cc: robh, linux-sunxi, conor+dt, devicetree
In-Reply-To: <20260613152655.212490-6-paulk@sys-base.io>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] The `csi0` node introduces the `interconnects` and `interconnect-names` properties, but these are not defined in the corresponding dt-binding schema `allwinner,sun6i-a31-csi.yaml`.
--
commit 6348731e0b0149fecdb9ccb7d05f8577710a1724
Author: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
This commit adds MIPI CSI-2 support for the V3s SoC by introducing nodes
for CSI0, the MIPI CSI-2 bridge, and the D-PHY. The CSI0 node includes
interconnect properties to inherit the proper DMA offsets.
> diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> index 02d6c62b3874e..03a1739683b16 100644
> --- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
> +++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
[ ... ]
> @@ -671,6 +671,79 @@ gic: interrupt-controller@1c81000 {
> interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
> };
>
> + csi0: camera@1cb0000 {
> + compatible = "allwinner,sun8i-v3s-csi";
> + reg = <0x01cb0000 0x1000>;
> + interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
> + clocks = <&ccu CLK_BUS_CSI>,
> + <&ccu CLK_CSI_SCLK>,
> + <&ccu CLK_DRAM_CSI>;
> + clock-names = "bus", "mod", "ram";
> + resets = <&ccu RST_BUS_CSI>;
> + interconnects = <&mbus 5>;
> + interconnect-names = "dma-mem";
[Severity: Low]
Will adding these properties cause a dtbs_check validation warning?
The interconnects and interconnect-names properties do not appear to be
defined in the corresponding dt-binding schema at
Documentation/devicetree/bindings/media/allwinner,sun6i-a31-csi.yaml.
Because that schema enforces additionalProperties: false, introducing
undocumented properties here might result in a validation failure. Should
the schema be updated alongside this patch to allow these interconnect
properties?
> + status = "disabled";
> +
[ ... ]
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613152655.212490-1-paulk@sys-base.io?part=5
^ permalink raw reply
* Re: [PATCH 2/3] dt-bindings: iio: magnetometer: add QST QMC5883L Sensor
From: David Lechner @ 2026-06-13 15:39 UTC (permalink / raw)
To: Jonathan Cameron, Joshua Crofts
Cc: Siratul Islam, robh, krzk+dt, conor+dt, nuno.sa, andy, linux-iio,
devicetree, linux-kernel
In-Reply-To: <20260612144529.7521b4f8@jic23-huawei>
On 6/12/26 8:45 AM, Jonathan Cameron wrote:
> On Fri, 12 Jun 2026 15:13:24 +0200
> Joshua Crofts <joshua.crofts1@gmail.com> wrote:
>
>> On Fri, 12 Jun 2026 18:45:26 +0600
>> Siratul Islam <email@sirat.me> wrote:
>>
>>> +QST QMC5883L 3-Axis Magnetic Sensor
>>> +M: Siratul Islam <email@sirat.me>
>>> +L: linux-iio@vger.kernel.org
>>
>> There's no point in having the IIO list in your MAINTAINERS
>> entry, get_maintainer.pl would return it automatically based
>> on the driver file's path.
> True, but I'm not sure there is a standard convention for whether
> lists should be added in this case or not.
>
> One of those things where we should decide on an answer perhaps
> and stick to it. Andy, Nuno, David, Dt folk what do you think?
>
Given that the vast majority of MAINTAINERS entries already have
L:, it seems like it would be easiest to just stick with that
convention.
Even if we cleaned up the 140+ IIO entries that don't strictly
need L: linux-iio@vger.kernel.org but already have it, people
still may just copy the convention from other entries.
^ permalink raw reply
* Re: [PATCH v10 4/6] dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
From: sashiko-bot @ 2026-06-13 15:35 UTC (permalink / raw)
To: Paul Kocialkowski; +Cc: conor+dt, devicetree, robh, linux-sunxi
In-Reply-To: <20260613152655.212490-5-paulk@sys-base.io>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The newly added V3s compatible string is for an rx-only hardware variant, but the binding schema allows it to incorrectly default to `tx`.
--
commit 2fd664ce10fb7edbf45c93a3bcbbd8adb0bad2ea
Author: Paul Kocialkowski <paulk@sys-base.io>
dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
The V3s/V3/S3 comes with a rx-only D-PHY paired with the MIPI CSI-2
controller. It is compatible with the D-PHY found on the A31.
Add an entry with a new compatible and the A31 compatible as fallback.
> diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> index 6a4fd49299590..3ca1a1c47032f 100644
> --- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> +++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
> @@ -21,6 +21,9 @@ properties:
> - items:
> - const: allwinner,sun50i-a64-mipi-dphy
> - const: allwinner,sun6i-a31-mipi-dphy
> + - items:
> + - const: allwinner,sun8i-v3s-mipi-dphy
> + - const: allwinner,sun6i-a31-mipi-dphy
[Severity: Medium]
Since the commit message indicates the V3s D-PHY is rx-only, should this
schema include an if-then block to enforce the rx direction?
The base binding defines allwinner,direction with a default of tx:
allwinner,direction:
...
enum:
- tx
- rx
default: tx
Without an allOf if-then block constraining this property for the
allwinner,sun8i-v3s-mipi-dphy compatible string, a V3s device tree node
that omits the property will implicitly default to tx.
Would this allow an incomplete device tree node to pass schema validation
while misconfiguring the rx-only hardware?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20260613152655.212490-1-paulk@sys-base.io?part=4
^ permalink raw reply
* [PATCH v10 6/6] ARM: dts: sun8i: v3s: Add support for the ISP
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
The V3s (and related platforms) come with an instance of the A31 ISP.
Even though it is very close to the A31 ISP, it is not exactly
register-compatible and a dedicated compatible only is used as a
result.
Just like most other blocks of the camera pipeline, the ISP uses
the common CSI bus, module and ram clock as well as reset.
A port connection to the ISP is added to CSI0 for convenience since
CSI0 serves for MIPI CSI-2 interface support, which is likely to
receive raw data that will need to be processed by the ISP to produce
a final image.
The interconnects property is used to inherit the proper DMA offset.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 35 ++++++++++++++++++++++
1 file changed, 35 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
index 03a1739683b1..628d5504c3ae 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -695,6 +695,14 @@ csi0_in_mipi_csi2: endpoint {
remote-endpoint = <&mipi_csi2_out_csi0>;
};
};
+
+ port@2 {
+ reg = <2>;
+
+ csi0_out_isp: endpoint {
+ remote-endpoint = <&isp_in_csi0>;
+ };
+ };
};
};
@@ -755,5 +763,32 @@ csi1: camera@1cb4000 {
resets = <&ccu RST_BUS_CSI>;
status = "disabled";
};
+
+ isp: isp@1cb8000 {
+ compatible = "allwinner,sun8i-v3s-isp";
+ reg = <0x01cb8000 0x1000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ interconnects = <&mbus 5>;
+ interconnect-names = "dma-mem";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@0 {
+ reg = <0>;
+
+ isp_in_csi0: endpoint {
+ remote-endpoint = <&csi0_out_isp>;
+ };
+ };
+ };
+ };
};
};
--
2.54.0
^ permalink raw reply related
* [PATCH v10 5/6] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
MIPI CSI-2 is supported on the V3s with an A31-based MIPI CSI-2 bridge
controller. The controller uses a separate D-PHY, which is the same
that is otherwise used for MIPI DSI, but used in Rx mode.
On the V3s, the CSI0 controller is dedicated to MIPI CSI-2 as it does
not have access to any parallel interface pins.
Add all the necessary nodes (CSI0, MIPI CSI-2 bridge and D-PHY) to
support the MIPI CSI-2 interface.
Note that a fwnode graph link is created between CSI0 and MIPI CSI-2
even when no sensor is connected. This will result in a probe failure
for the controller as long as no sensor is connected but this is fine
since no other interface is available.
The interconnects property is used to inherit the proper DMA offset.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
---
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 73 ++++++++++++++++++++++
1 file changed, 73 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
index 02d6c62b3874..03a1739683b1 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -671,6 +671,79 @@ gic: interrupt-controller@1c81000 {
interrupts = <GIC_PPI 9 (GIC_CPU_MASK_SIMPLE(4) | IRQ_TYPE_LEVEL_HIGH)>;
};
+ csi0: camera@1cb0000 {
+ compatible = "allwinner,sun8i-v3s-csi";
+ reg = <0x01cb0000 0x1000>;
+ interrupts = <GIC_SPI 83 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>,
+ <&ccu CLK_DRAM_CSI>;
+ clock-names = "bus", "mod", "ram";
+ resets = <&ccu RST_BUS_CSI>;
+ interconnects = <&mbus 5>;
+ interconnect-names = "dma-mem";
+ status = "disabled";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ port@1 {
+ reg = <1>;
+
+ csi0_in_mipi_csi2: endpoint {
+ remote-endpoint = <&mipi_csi2_out_csi0>;
+ };
+ };
+ };
+ };
+
+ mipi_csi2: csi@1cb1000 {
+ compatible = "allwinner,sun8i-v3s-mipi-csi2",
+ "allwinner,sun6i-a31-mipi-csi2";
+ reg = <0x01cb1000 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_CSI_SCLK>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_CSI>;
+ status = "disabled";
+
+ phys = <&dphy>;
+ phy-names = "dphy";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mipi_csi2_in: port@0 {
+ reg = <0>;
+ };
+
+ mipi_csi2_out: port@1 {
+ reg = <1>;
+
+ mipi_csi2_out_csi0: endpoint {
+ remote-endpoint = <&csi0_in_mipi_csi2>;
+ };
+ };
+ };
+ };
+
+ dphy: d-phy@1cb2000 {
+ compatible = "allwinner,sun8i-v3s-mipi-dphy",
+ "allwinner,sun6i-a31-mipi-dphy";
+ reg = <0x01cb2000 0x1000>;
+ interrupts = <GIC_SPI 90 IRQ_TYPE_LEVEL_HIGH>;
+ clocks = <&ccu CLK_BUS_CSI>,
+ <&ccu CLK_MIPI_CSI>;
+ clock-names = "bus", "mod";
+ resets = <&ccu RST_BUS_CSI>;
+ allwinner,direction = "rx";
+ status = "disabled";
+ #phy-cells = <0>;
+ };
+
csi1: camera@1cb4000 {
compatible = "allwinner,sun8i-v3s-csi";
reg = <0x01cb4000 0x3000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v10 4/6] dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
The V3s/V3/S3 comes with a rx-only D-PHY paired with the MIPI CSI-2
controller. It is compatible with the D-PHY found on the A31.
Add an entry with a new compatible and the A31 compatible as fallback.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
.../devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml | 3 +++
1 file changed, 3 insertions(+)
diff --git a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
index 6a4fd4929959..3ca1a1c47032 100644
--- a/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
+++ b/Documentation/devicetree/bindings/phy/allwinner,sun6i-a31-mipi-dphy.yaml
@@ -21,6 +21,9 @@ properties:
- items:
- const: allwinner,sun50i-a64-mipi-dphy
- const: allwinner,sun6i-a31-mipi-dphy
+ - items:
+ - const: allwinner,sun8i-v3s-mipi-dphy
+ - const: allwinner,sun6i-a31-mipi-dphy
- items:
- const: allwinner,sun20i-d1-mipi-dphy
- const: allwinner,sun50i-a100-mipi-dphy
--
2.54.0
^ permalink raw reply related
* [PATCH v10 3/6] ARM: dts: sun8i: v3s: Add mbus node to represent the interconnect
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard, Paul Kocialkowski
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
From: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
The V3s uses the mbus interconnect to provide DRAM access for a
number of blocks. The SoC can only map 2 GiB of DRAM, which is
reflected in the dma-ranges property.
Signed-off-by: Paul Kocialkowski <paul.kocialkowski@bootlin.com>
Reviewed-by: Samuel Holland <samuel@sholland.org>
---
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 15 +++++++++++++++
1 file changed, 15 insertions(+)
diff --git a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
index fa54510319ac..02d6c62b3874 100644
--- a/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
+++ b/arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi
@@ -629,6 +629,21 @@ int_mii_phy: ethernet-phy@1 {
};
};
+ mbus: dram-controller@1c62000 {
+ compatible = "allwinner,sun8i-v3s-mbus";
+ reg = <0x01c62000 0x1000>,
+ <0x01c63000 0x1000>;
+ reg-names = "mbus", "dram";
+ clocks = <&ccu CLK_MBUS>,
+ <&ccu CLK_DRAM>,
+ <&ccu CLK_BUS_DRAM>;
+ clock-names = "mbus", "dram", "bus";
+ #address-cells = <1>;
+ #size-cells = <1>;
+ dma-ranges = <0x00000000 0x40000000 0x80000000>;
+ #interconnect-cells = <1>;
+ };
+
spi0: spi@1c68000 {
compatible = "allwinner,sun8i-h3-spi";
reg = <0x01c68000 0x1000>;
--
2.54.0
^ permalink raw reply related
* [PATCH v10 2/6] clk: sunxi-ng: v3s: Remove exported clock definitions
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
V3s MBUS and DRAM clock definitions are now exported in the dt-bindings
header. We can remove the duplicated definitons in the clock driver.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 4 ----
1 file changed, 4 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
index 345cdbbab362..c933ef016570 100644
--- a/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
+++ b/drivers/clk/sunxi-ng/ccu-sun8i-v3s.h
@@ -39,14 +39,10 @@
/* The first bunch of module clocks are exported */
-#define CLK_DRAM 58
-
/* All the DRAM gates are exported */
/* Some more module clocks are exported */
-#define CLK_MBUS 72
-
/* And the GPU module clock is exported */
#define CLK_PLL_DDR1 74
--
2.54.0
^ permalink raw reply related
* [PATCH v10 1/6] dt-bindings: sun8i-v3s-ccu: Export MBUS and DRAM clocks to the public header
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
In-Reply-To: <20260613152655.212490-1-paulk@sys-base.io>
In order to declare a mbus node for the V3s, expose its associated
clocks to the public header.
Signed-off-by: Paul Kocialkowski <paulk@sys-base.io>
---
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/include/dt-bindings/clock/sun8i-v3s-ccu.h b/include/dt-bindings/clock/sun8i-v3s-ccu.h
index c4055629c9f9..d635bffd6914 100644
--- a/include/dt-bindings/clock/sun8i-v3s-ccu.h
+++ b/include/dt-bindings/clock/sun8i-v3s-ccu.h
@@ -87,7 +87,7 @@
#define CLK_SPI0 55
#define CLK_USB_PHY0 56
#define CLK_USB_OHCI0 57
-
+#define CLK_DRAM 58
#define CLK_DRAM_VE 59
#define CLK_DRAM_CSI 60
#define CLK_DRAM_EHCI 61
@@ -101,7 +101,7 @@
#define CLK_VE 69
#define CLK_AC_DIG 70
#define CLK_AVS 71
-
+#define CLK_MBUS 72
#define CLK_MIPI_CSI 73
/* Clocks not available on V3s */
--
2.54.0
^ permalink raw reply related
* [PATCH v10 0/6] Allwinner A31/A83T MIPI CSI-2 and A31 ISP / Platform Support
From: Paul Kocialkowski @ 2026-06-13 15:26 UTC (permalink / raw)
To: linux-media, devicetree, linux-arm-kernel, linux-sunxi,
linux-kernel
Cc: Yong Deng, Paul Kocialkowski, Mauro Carvalho Chehab, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Chen-Yu Tsai, Jernej Skrabec,
Samuel Holland, Michael Turquette, Stephen Boyd, Brian Masney,
Maxime Ripard
This series adds platform support for the V3s/V3/S3 MIPI CSI-2 and ISP units
as well the as A83T MIPI CSI-2 unit in the respective device-trees.
The corresponding drivers and dt bindings were merged a long time ago but this
series was never actually picked up. It seems more than ready to be merged!
Changes since v9:
- Split clock definitions export;
- Added dedicated v3s d-phy compatible;
- Added interrupt to v3s d-phy definition;
- Removed a83t board overlays that need more work.
Changes since v8:
- Added collected review tags;
- Added the overlays to be built as full dtbs.
- Removed trailing whitespace.
Changes since v7:
- Added collected review tags;
- Added interconnect properties to bindings;
- Added compatible for device-tree overlays;
- Moved mclk pin to sensor node in bpi-m3 overlays;
- Removed duplicated assigned-clocks in bpi-m3 overlays.
Changes since v6:
- Rebased on top of the latest media tree, renamed dts to dtso for overlays.
Changes since v5:
- Added BananaPi M3 camera sensor support as device-tree overlays;
- Cleaned-up OV8865 regulator definitions;
- Always declared the internal links between CSI and MIPI CSI-2 on A83T
in device-tree.
Changes since v4:
- Removed mbus bindings patch: an equivalent change was merged;
- Added collected tags;
- Rebased on latest media tree.
Changes since v3:
- Reordered v3s mbus compatible in binding;
- Added collected tag;
- Removed rejected interconnects fix.
Changes since all-in-one v2:
- Corrected mbus index used for the interconnects;
- Used extended mbus binding and exported the DRAM clock for that;
- Reworked the description of the core openfirmware change to give
more insight about the situation.
Paul Kocialkowski (6):
dt-bindings: sun8i-v3s-ccu: Export MBUS and DRAM clocks to the public
header
clk: sunxi-ng: v3s: Remove exported clock definitions
ARM: dts: sun8i: v3s: Add mbus node to represent the interconnect
dt-bindings: sun6i-a31-mipi-dphy: Add V3s SoC compatible entry
ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
ARM: dts: sun8i: v3s: Add support for the ISP
.../phy/allwinner,sun6i-a31-mipi-dphy.yaml | 3 +
arch/arm/boot/dts/allwinner/sun8i-v3s.dtsi | 123 ++++++++++++++++++
drivers/clk/sunxi-ng/ccu-sun8i-v3s.h | 4 -
include/dt-bindings/clock/sun8i-v3s-ccu.h | 4 +-
4 files changed, 128 insertions(+), 6 deletions(-)
--
2.54.0
^ permalink raw reply
* Re: [PATCH 1/2] dt-bindings: hwmon: pmbus: ti,lm25066: add current limit properties
From: Conor Dooley @ 2026-06-13 15:07 UTC (permalink / raw)
To: Guenter Roeck
Cc: Potin Lai, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Zev Weiss, linux-hwmon, devicetree, linux-kernel, Cosmo Chou,
Mike Hsieh, Potin Lai
In-Reply-To: <4875e6b4-0d9f-4920-9efa-883d1fed983f@roeck-us.net>
[-- Attachment #1: Type: text/plain, Size: 3827 bytes --]
On Sat, Jun 13, 2026 at 06:05:28AM -0700, Guenter Roeck wrote:
> On 6/12/26 14:13, Conor Dooley wrote:
> > On Fri, Jun 12, 2026 at 10:19:14AM -0700, Guenter Roeck wrote:
> > > On 6/12/26 09:12, Conor Dooley wrote:
> > > > On Fri, Jun 12, 2026 at 05:10:38PM +0800, Potin Lai wrote:
> > > > > On Fri, Jun 12, 2026 at 1:27 AM Conor Dooley <conor@kernel.org> wrote:
> > > > > >
> > > > > > On Thu, Jun 11, 2026 at 05:58:44PM +0800, Potin Lai wrote:
> > > > > > > Add mutually exclusive 'ti,cl-smbus-high' and 'ti,cl-smbus-low' boolean
> > > > > > > properties to configure the device's Current Limit (CL) behavior using
> > > > > > > SMBus settings instead of physical pins.
> > > > > > >
> > > > > > > Signed-off-by: Potin Lai <potin.lai.pt@gmail.com>
> > > > > > > ---
> > > > > > > .../devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml | 20 ++++++++++++++++++++
> > > > > > > 1 file changed, 20 insertions(+)
> > > > > > >
> > > > > > > diff --git a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > > > index a20f140dc79a..95ea7c26dec2 100644
> > > > > > > --- a/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > > > +++ b/Documentation/devicetree/bindings/hwmon/pmbus/ti,lm25066.yaml
> > > > > > > @@ -46,6 +46,26 @@ properties:
> > > > > > >
> > > > > > > additionalProperties: false
> > > > > > >
> > > > > > > + ti,cl-smbus-high:
> > > > > > > + description: |
> > > > > > > + Configure the Current Limit (CL) to use the SMBus high setting.
> > > > > > > + type: boolean
> > > > > > > +
> > > > > > > + ti,cl-smbus-low:
> > > > > > > + description: |
> > > > > > > + Configure the Current Limit (CL) to use the SMBus low setting.
> > > > > > > + type: boolean
> > > > > >
> > > > > > What's smbus specific about this? If the pin was connected to a GPIO,
> > > > > > you'd then need to have different properties or use these ones with an
> > > > > > inaccurate name.
> > > > > >
> > > > >
> > > > > The "smbus" in the property name was originally meant to indicate
> > > > > that the setting is configured via the internal register over the SMBus (I2C)
> > > > > interface, rather than physical pins.
> > > >
> > > > Right, but if you do it via the physical pins using a gpio, you still
> > > > need a way to say what limit is. The status quo only works if the limit
> > > > pin is tied high or low.
> > > >
> > >
> > > The physical pin is supposed to be connected to ground or left floating.
> > > It seems unlikely that anyone would ever have the idea of connecting it
> > > to a GPIO pin, and doing so would for sure mess up the driver because
> > > its state is only read in the probe function. The configuration here
> >
> > Well yeah, "obviously" if someone wanted to use a GPIO the driver would
> > have to change to handle that - but probably not that much since it'd be
> > a static setting that could be done at probe.
> >
> > I get that it may be unlikely, but it seems like a reasonable thing that
> > someone might want to do, and renaming the property to not exclude that
> > usecase seems to be "free".
> >
>
> It is not only unlikely, it would be risky and potentially result in
> undefined behavior. The pin is supposed to be static. It is undefined
> if the hardware evaluates it once after power-up, after "power good"
> was detected (if the specific chip supports it), or continuously.
> Making the pin run-time configurable would be a risky endeavor with
> zero gain since the value can be set by software configuration,
> while at the same time adding complexity to the hardware.
Okay, if you think noone will do it, then I will cede to your more
relevant expertise.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
^ permalink raw reply
* Re: [PATCH] dt-bindings: dma: xilinx: Fix "xlnx,irq-delay" type
From: Pandey, Radhey Shyam @ 2026-06-13 14:48 UTC (permalink / raw)
To: Rob Herring (Arm), Vinod Koul, Frank Li, Krzysztof Kozlowski,
Conor Dooley, Michal Simek, Shyam Pandey, Abin Joseph
Cc: dmaengine, devicetree, linux-arm-kernel, linux-kernel
In-Reply-To: <20260612215226.1887726-1-robh@kernel.org>
> "xlnx,irq-delay" programs an 8-bit delay field in the DMA control
> register, and the driver stores and reads it as a byte. The binding
> described the property as a uint32 cell, which made the helper type
> check report the driver as wrong.
>
> Document "xlnx,irq-delay" as uint8 so the generated schema reflects
> the hardware field width and the existing driver access.
>
> Assisted-by: Codex:gpt-5-5
> Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Reviewed-by: Radhey Shyam Pandey <radhey.shyam.pandey@amd.com>
Thanks!
> ---
> Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
> index 340ae9e91cb0..ba0fc515d825 100644
> --- a/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
> +++ b/Documentation/devicetree/bindings/dma/xilinx/xlnx,axi-dma.yaml
> @@ -93,7 +93,7 @@ properties:
> Width in bits of the length register as configured in hardware.
>
> xlnx,irq-delay:
> - $ref: /schemas/types.yaml#/definitions/uint32
> + $ref: /schemas/types.yaml#/definitions/uint8
> minimum: 0
> maximum: 255
> description:
^ permalink raw reply
* Re: [PATCH 0/3] iio: adc: Extend ti-ads1100 driver
From: Jakub Szczudło @ 2026-06-13 14:44 UTC (permalink / raw)
To: David Lechner
Cc: linux-iio, jic23, nuno.sa, andy, marcelo.schmitt, robh, krzk+dt,
conor+dt, mike.looijmans, devicetree, linux-kernel, jorge.marques,
antoniu.miclaus, mazziesaccount, jishnu.prakash, duje, wens,
sakari.ailus, linusw
In-Reply-To: <6305149b-d334-491f-85c2-085fe42cae98@baylibre.com>
wt., 9 cze 2026 o 18:10 David Lechner <dlechner@baylibre.com> napisał(a):
>
> On 6/7/26 1:35 PM, Jakub Szczudlo wrote:
> > Extend ADS 1100 driver to support ADS1110, which is a pin-to-pin
> > compatible device with higher resolution. This patch also updates the
> > device tree bindings and Kconfig description to reflect the new
> > supported device.
> >
> > Signed-off-by: jszczudlo <jakubszczudlo40@gmail.com>
> > ---
> > jszczudlo (3):
> > dt-bindings: iio: adc: Update title and enum
> > iio: adc: Update Kconfig description for TI_ADS1100
> > iio: adc: Add ti-ads1110 support to ti-ads1100 driver
> >
> > .../bindings/iio/adc/ti,ads1100.yaml | 3 +-
> > drivers/iio/adc/Kconfig | 6 +-
> > drivers/iio/adc/ti-ads1100.c | 165 +++++++++++++-----
> > 3 files changed, 131 insertions(+), 43 deletions(-)
> >
>
> I assume this is v2 of [1]? the subject should include [PATCH v2] and the
> cover letter should include a changelog. See [2].
>
> [1]: https://lore.kernel.org/linux-iio/20260527164312.355729-1-jakubszczudlo40@gmail.com/
> [2]: https://www.kernel.org/doc/html/latest/process/submitting-patches.html
Thanks for all reviews, I will work on implementing those
^ permalink raw reply
* Re: [PATCH 4/7] drivers: staging: media: sunxi: cedrus: add H616 variant
From: Chen-Yu Tsai @ 2026-06-13 14:34 UTC (permalink / raw)
To: Jernej Škrabec
Cc: Maxime Ripard, Paul Kocialkowski, Mauro Carvalho Chehab,
Jernej Skrabec, Samuel Holland, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Greg Kroah-Hartman, linux-media, linux-staging,
devicetree, linux-sunxi, linux-arm-kernel, linux-kernel
In-Reply-To: <L1ZJMTqKQbak6NcKbwFkDg@gmail.com>
On Sat, Jun 13, 2026 at 6:33 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
>
> Dne sobota, 30. maj 2026 ob 18:43:05 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > On Tue, May 5, 2026 at 7:18 PM Jernej Škrabec <jernej.skrabec@gmail.com> wrote:
> > >
> > > Dne torek, 5. maj 2026 ob 15:48:08 Srednjeevropski poletni čas je Chen-Yu Tsai napisal(a):
> > > > The Allwinner H616 SoC has a video engine hardware block like the one
> > > > found on previous generations such as the H6. In addition to the
> > > > currently supported features of the H6, it is also supposed to include
> > >
> > > Remove "supposed".
> >
> > I can't actually verify that, so "supposed" is accurate from my point of
> > view.
>
> Isn't info from manual good enough?
The manual says the SoC supports it. Same was said for the H6. Then
we discovered that the VP9 decoder was a separate Hantro block.
So again, *I* cannot claim in the commit message that the hardware
block supports VP9 decoding, because I have not verified it.
> In the interest of unblocking this, I would be fine with "supposed" too,
> but manual and all my experiments show VP9 is supported.
Please give an ack or reviewed-by with a comment at the end stating
VP9 verified.
Thanks
ChenYu
> Best regards,
> Jernej
>
> >
> > ChenYu
> >
> > > > a VP9 decoder. However software support for this is currently missing
> > > > and still needs to be reverse engineered from the vendor BSP.
> > > >
> > > > Add the compatible for the H616 variant, using the H6 variant data.
> > > >
> > > > Signed-off-by: Chen-Yu Tsai <wens@kernel.org>
> > >
> > > With that:
> > > Reviewed-by: Jernej Skrabec <jernej.skrabec@gmail.com>
> > >
> > > Best regards,
> > > Jernej
> > >
> > >
> >
>
>
>
>
>
^ permalink raw reply
* [PATCH v2 3/3] regulator: 88pm886: Add Vbus regulator
From: Duje Mihanović @ 2026-06-13 14:20 UTC (permalink / raw)
To: Karel Balej, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown
Cc: devicetree, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović
In-Reply-To: <20260613-88pm886-vbus-v2-0-021dfb02c6bb@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Add support for the PMIC's Vbus regulator. This regulator is mandatory
for USB OTG support on boards using the PMIC.
Reviewed-by: Karel Balej <balejk@matfyz.cz>
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Changes in v2:
- Drop unneeded units.h include
---
drivers/regulator/88pm886-regulator.c | 26 ++++++++++++++++++++++++++
include/linux/mfd/88pm886.h | 7 +++++++
2 files changed, 33 insertions(+)
diff --git a/drivers/regulator/88pm886-regulator.c b/drivers/regulator/88pm886-regulator.c
index a38bd4f312b7..53cb68528cea 100644
--- a/drivers/regulator/88pm886-regulator.c
+++ b/drivers/regulator/88pm886-regulator.c
@@ -337,6 +337,25 @@ static struct regulator_desc pm886_regulators[] = {
},
};
+static const struct linear_range pm886_vbus_volt_ranges[] = {
+ REGULATOR_LINEAR_RANGE(3750000, 0, 7, 250000)
+};
+
+static struct regulator_desc pm886_vbus_regulator = {
+ .name = "vbus",
+ .regulators_node = "regulators",
+ .of_match = "vbus",
+ .ops = &pm886_buck_ops,
+ .type = REGULATOR_VOLTAGE,
+ .n_voltages = 8,
+ .linear_ranges = pm886_vbus_volt_ranges,
+ .n_linear_ranges = ARRAY_SIZE(pm886_vbus_volt_ranges),
+ .vsel_reg = PM886_REG_BOOST_CONFIG1,
+ .vsel_mask = PM886_REG_BOOST_MASK,
+ .enable_reg = PM886_REG_BATTERY_CONFIG1,
+ .enable_mask = PM886_REG_VBUS_EN,
+};
+
static int pm886_regulator_probe(struct platform_device *pdev)
{
struct pm886_chip *chip = dev_get_drvdata(pdev->dev.parent);
@@ -369,6 +388,13 @@ static int pm886_regulator_probe(struct platform_device *pdev)
"Failed to register %s\n", rdesc->name);
}
+ rcfg.regmap = chip->regmap_battery;
+ rdesc = &pm886_vbus_regulator;
+ rdev = devm_regulator_register(dev, rdesc, &rcfg);
+ if (IS_ERR(rdev))
+ return dev_err_probe(dev, PTR_ERR(rdev),
+ "Failed to register %s\n", rdesc->name);
+
return 0;
}
diff --git a/include/linux/mfd/88pm886.h b/include/linux/mfd/88pm886.h
index 2c24dd3032ab..9e96d2cb92f5 100644
--- a/include/linux/mfd/88pm886.h
+++ b/include/linux/mfd/88pm886.h
@@ -2,6 +2,7 @@
#ifndef __MFD_88PM886_H
#define __MFD_88PM886_H
+#include <linux/bits.h>
#include <linux/i2c.h>
#include <linux/regmap.h>
@@ -130,6 +131,12 @@
#define PM886_GPADC_INDEX_TO_BIAS_uA(i) (1 + (i) * 5)
/* Battery block register definitions */
+#define PM886_REG_BATTERY_CONFIG1 0x28
+#define PM886_REG_VBUS_EN BIT(7)
+
+#define PM886_REG_BOOST_CONFIG1 0x6b
+#define PM886_REG_BOOST_MASK GENMASK(2, 0)
+
#define PM886_REG_CLS_CONFIG1 0x71
struct pm886_chip {
--
2.54.0
^ permalink raw reply related
* [PATCH v2 2/3] mfd: 88pm886: Initialize the battery page
From: Duje Mihanović @ 2026-06-13 14:20 UTC (permalink / raw)
To: Karel Balej, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown
Cc: devicetree, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović
In-Reply-To: <20260613-88pm886-vbus-v2-0-021dfb02c6bb@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Initialize the PMIC's battery page. The battery page registers are
shared between Vbus regulator, charger, fuelgauge and camera flash
blocks, hence the commonization of the page.
Reviewed-by: Karel Balej <balejk@matfyz.cz>
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Changes in v2:
- Reword commit message
- Reorder pm886_probe() local variables according to RCT
- Initialize battery page after succcessful chip ID check
---
drivers/mfd/88pm886.c | 21 ++++++++++++++++++++-
include/linux/mfd/88pm886.h | 5 +++++
2 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/mfd/88pm886.c b/drivers/mfd/88pm886.c
index e411d8dee554..f8401d5e6dbe 100644
--- a/drivers/mfd/88pm886.c
+++ b/drivers/mfd/88pm886.c
@@ -16,6 +16,12 @@ static const struct regmap_config pm886_regmap_config = {
.max_register = PM886_REG_RTC_SPARE6,
};
+static const struct regmap_config pm886_regmap_battery_config = {
+ .reg_bits = 8,
+ .val_bits = 8,
+ .max_register = PM886_REG_CLS_CONFIG1,
+};
+
static const struct regmap_irq pm886_regmap_irqs[] = {
REGMAP_IRQ_REG(PM886_IRQ_ONKEY, 0, PM886_INT_ENA1_ONKEY),
};
@@ -85,10 +91,11 @@ static int pm886_setup_irq(struct pm886_chip *chip,
static int pm886_probe(struct i2c_client *client)
{
+ struct regmap *regmap, *regmap_battery;
struct regmap_irq_chip_data *irq_data;
struct device *dev = &client->dev;
+ struct i2c_client *battery_page;
struct pm886_chip *chip;
- struct regmap *regmap;
unsigned int chip_id;
int err;
@@ -112,6 +119,18 @@ static int pm886_probe(struct i2c_client *client)
if (chip->chip_id != chip_id)
return dev_err_probe(dev, -EINVAL, "Unsupported chip: 0x%x\n", chip_id);
+ battery_page = devm_i2c_new_dummy_device(dev, client->adapter,
+ client->addr + PM886_PAGE_OFFSET_BATTERY);
+ if (IS_ERR(battery_page))
+ return dev_err_probe(dev, PTR_ERR(battery_page),
+ "Failed to initialize battery page\n");
+
+ regmap_battery = devm_regmap_init_i2c(battery_page, &pm886_regmap_battery_config);
+ if (IS_ERR(regmap_battery))
+ return dev_err_probe(dev, PTR_ERR(regmap_battery),
+ "Failed to initialize battery regmap\n");
+ chip->regmap_battery = regmap_battery;
+
err = pm886_setup_irq(chip, &irq_data);
if (err)
return err;
diff --git a/include/linux/mfd/88pm886.h b/include/linux/mfd/88pm886.h
index 38892ba7b8a4..2c24dd3032ab 100644
--- a/include/linux/mfd/88pm886.h
+++ b/include/linux/mfd/88pm886.h
@@ -11,6 +11,7 @@
#define PM886_PAGE_OFFSET_REGULATORS 1
#define PM886_PAGE_OFFSET_GPADC 2
+#define PM886_PAGE_OFFSET_BATTERY 3
#define PM886_REG_ID 0x00
@@ -128,9 +129,13 @@
#define PM886_GPADC_BIAS_LEVELS 16
#define PM886_GPADC_INDEX_TO_BIAS_uA(i) (1 + (i) * 5)
+/* Battery block register definitions */
+#define PM886_REG_CLS_CONFIG1 0x71
+
struct pm886_chip {
struct i2c_client *client;
unsigned int chip_id;
struct regmap *regmap;
+ struct regmap *regmap_battery;
};
#endif /* __MFD_88PM886_H */
--
2.54.0
^ permalink raw reply related
* [PATCH v2 1/3] dt-bindings: mfd: 88pm886: Allow vbus regulator
From: Duje Mihanović @ 2026-06-13 14:20 UTC (permalink / raw)
To: Karel Balej, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown
Cc: devicetree, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović, Conor Dooley
In-Reply-To: <20260613-88pm886-vbus-v2-0-021dfb02c6bb@dujemihanovic.xyz>
From: Duje Mihanović <duje@dujemihanovic.xyz>
Add vbus to patternProperties for the regulators node to allow for the
PMIC's vbus regulator to be exposed.
Reviewed-by: Karel Balej <balejk@matfyz.cz>
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
index 92a72a99fd79..940262898353 100644
--- a/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
+++ b/Documentation/devicetree/bindings/mfd/marvell,88pm886-a1.yaml
@@ -29,7 +29,7 @@ properties:
type: object
additionalProperties: false
patternProperties:
- "^(ldo(1[0-6]|[1-9])|buck[1-5])$":
+ "^(ldo(1[0-6]|[1-9])|buck[1-5]|vbus)$":
type: object
$ref: /schemas/regulator/regulator.yaml#
description: LDO or buck regulator.
--
2.54.0
^ permalink raw reply related
* [PATCH v2 0/3] 88PM886 Vbus regulator support
From: Duje Mihanović @ 2026-06-13 14:20 UTC (permalink / raw)
To: Karel Balej, Lee Jones, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Liam Girdwood, Mark Brown
Cc: devicetree, phone-devel, ~postmarketos/upstreaming, linux-kernel,
Duje Mihanović, Conor Dooley
Hello,
This series adds support for the USB Vbus regulator found on Marvell's
88PM886 PMIC. The regulator enables USB role switching on boards using
the PMIC.
Signed-off-by: Duje Mihanović <duje@dujemihanovic.xyz>
---
Changes in v2:
- Initialize battery page after chip ID check
- Clean up includes and variable ordering
- Update trailers
- Link to v1: https://patch.msgid.link/20260526-88pm886-vbus-v1-0-f2bd1fd3c19e@dujemihanovic.xyz
---
Duje Mihanović (3):
dt-bindings: mfd: 88pm886: Allow vbus regulator
mfd: 88pm886: Initialize the battery page
regulator: 88pm886: Add Vbus regulator
.../bindings/mfd/marvell,88pm886-a1.yaml | 2 +-
drivers/mfd/88pm886.c | 21 ++++++++++++++++-
drivers/regulator/88pm886-regulator.c | 26 ++++++++++++++++++++++
include/linux/mfd/88pm886.h | 12 ++++++++++
4 files changed, 59 insertions(+), 2 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260516-88pm886-vbus-5e3bbfd9cbad
Best regards,
--
Duje Mihanović <duje@dujemihanovic.xyz>
^ permalink raw reply
* Re: [PATCH v9 5/9] ARM: dts: sun8i: v3s: Add nodes for MIPI CSI-2 support
From: Paul Kocialkowski @ 2026-06-13 14:11 UTC (permalink / raw)
To: Chen-Yu Tsai; +Cc: linux-sunxi, conor+dt, robh, devicetree, sashiko-reviews
In-Reply-To: <ahWqcWy_6QuNIOi-@shepard>
[-- Attachment #1: Type: text/plain, Size: 3109 bytes --]
Hi Chen-Yu,
Le Tue 26 May 26, 16:13, Paul Kocialkowski a écrit :
> > > > + reg = <0x01cb2000 0x1000>;
> > > > + clocks = <&ccu CLK_BUS_CSI>,
> > > > + <&ccu CLK_MIPI_CSI>;
> > > > + clock-names = "bus", "mod";
> > > > + resets = <&ccu RST_BUS_CSI>;
> > >
> > > Will this node fail dtbs_check schema validation? The existing device tree
> > > binding schema for "allwinner,sun6i-a31-mipi-dphy" requires an interrupts
> > > property, which appears to be missing here.
> >
> > Yeah, this is definitely going to fail validation.
>
> To be very clear about this, the interrupt is absolutely not required for
> proper operation of the unit and there's a chance we might eventually see
> a SoC that doesn't have it wired.
>
> I could just hook the interrupt for now and we could make it optional if ever
> needed, but I could also mark is as optional now if you prefer.
>
> > > If the V3s hardware physically lacks a D-PHY interrupt, would it be better
> > > to add the V3s-specific compatible string and update the binding schema
> > > to make the interrupts property conditionally optional for the V3s?
> >
> > FWIW the vendor kernel has some code for the D-PHY's interrupt bits [1].
> > Could you add the interrupt (I'm guessing the MIPI-CSI interrupt?) and
> > give it a quick test?
>
> Thanks for digging this up! It really looks like it's just used for debug
> purposes.
>
> I have previously used the mipi csi-2 interrupt for the mipi csi-2 controller
> and never for the d-phy. There's a chance it's the same interrupt that is wired
> to both units (like it is for isp/csi).
>
> I'll give it a try when I get back home. If it doesn't trigger, it probbaly
> means it's not wired to the d-phy and should really be made optional.
I just tested it: the interrupt is wired to both the mipi csi-2 and d-phy
units and triggers when interrupt enable bits are set on the d-phy.
So I will just add it to the d-phy node and keep the property marked as
mandatory in the binding.
All the best,
Paul
> > Thanks
> > ChenYu
> >
> > [1] https://github.com/gediz/v3s-linux-sdk/blob/master/linux-3.4/drivers/media/video/sunxi-vfe/mipi_csi/dphy/dphy_reg.c
> >
> >
> > > > + allwinner,direction = "rx";
> > > > + status = "disabled";
> > > > + #phy-cells = <0>;
> > > > + };
> > > > +
> > >
> > > --
> > > Sashiko AI review · https://sashiko.dev/#/patchset/20260518153339.619947-1-paulk@sys-base.io?part=5
> > >
>
> --
> Paul Kocialkowski,
>
> Independent contractor - sys-base - https://www.sys-base.io/
> Free software developer - https://www.paulk.fr/
>
> Expert in multimedia, graphics and embedded hardware support with Linux.
--
Paul Kocialkowski,
Independent contractor - sys-base - https://www.sys-base.io/
Free software developer - https://www.paulk.fr/
Expert in multimedia, graphics and embedded hardware support with Linux.
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox