* Re: [PATCH v2] dt-bindings: thermal: idle: Complete the example code
From: Rob Herring (Arm) @ 2026-04-07 19:29 UTC (permalink / raw)
To: Krzysztof Kozlowski
Cc: Conor Dooley, linux-pm, Krzysztof Kozlowski, linux-kernel,
Daniel Lezcano, devicetree, Lukasz Luba, Zhang Rui,
Rafael J. Wysocki
In-Reply-To: <20260407053957.10508-2-krzysztof.kozlowski@oss.qualcomm.com>
On Tue, 07 Apr 2026 07:39:58 +0200, Krzysztof Kozlowski wrote:
> Thermal bindings expect the node name with all the zones to be named
> 'thermal-zones' (hyphen instead of underscore) and thermal zones to end
> with '-thermal'. Also DTS coding style is not to use underscores for
> node names. After using correct names, bindings point warnings for
> missing properties, so add also thermal-sensors. Drop fake top
> compatible as it is not useful in this context.
>
> Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
>
> ---
>
> Changes in v2:
> 1. Drop top level compatible and other properties
> 2. Add thermal-sensors
> 3. Rename also trips and cpu-thermal
> ---
> .../bindings/thermal/thermal-idle.yaml | 18 +++++++-----------
> 1 file changed, 7 insertions(+), 11 deletions(-)
>
My bot found errors running 'make dt_binding_check' on your patch:
yamllint warnings/errors:
dtschema/dtc warnings/errors:
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: 'compatible' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: 'model' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: '#address-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
/builds/robherring/dt-review-ci/linux/Documentation/devicetree/bindings/thermal/thermal-idle.example.dtb: /: '#size-cells' is a required property
from schema $id: http://devicetree.org/schemas/root-node.yaml
doc reference errors (make refcheckdocs):
See https://patchwork.kernel.org/project/devicetree/patch/20260407053957.10508-2-krzysztof.kozlowski@oss.qualcomm.com
The base for the series is generally the latest rc1. A different dependency
should be noted in *this* patch.
If you already ran 'make dt_binding_check' and didn't see the above
error(s), then make sure 'yamllint' is installed and dt-schema is up to
date:
pip3 install dtschema --upgrade
Please check and re-submit after running the above command yourself. Note
that DT_SCHEMA_FILES can be set to your schema file to speed up checking
your schema. However, it must be unset to test all examples with your schema.
^ permalink raw reply
* Re: [PATCH] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Krzysztof Kozlowski @ 2026-04-07 19:30 UTC (permalink / raw)
To: Marek Vasut
Cc: devicetree, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
In-Reply-To: <c3a9c4eb-92ce-48c2-83ff-18c7ce03acd9@nabladev.com>
On 07/04/2026 16:51, Marek Vasut wrote:
> On 4/7/26 10:00 AM, Krzysztof Kozlowski wrote:
>
>>> NOTE: For example Linux kernel driver does already use that information
>>> and fails to probe if it is missing. There are currently no intree
>>
>> The first sentence must be part of the commit msg. That is important
>> reason why you are doing this... but I don't see how you achieve any of
>> this. Look:
>>
>>
>>> users for this binding, so no new warnings will be generated once
>>> this is applied, but a new user is about to be added.
>>
>> What warnings? How?
>
> There are no in-tree users of this binding, so no DT checker warnings
> will be produced on existing in-tree DTs. I am in the process of adding
> a DTO which uses this binding now in arm64: dts: imx8mm: imx8mp: Add
> DTOs for Data Modul i.MX8M Mini and Plus eDM SBC
So add new user, apply this and what warnings are you seeing?
>
>>> ---
>>> .../display/bridge/lontium,lt9211.yaml | 37 ++++++++++++++++++-
>>> 1 file changed, 35 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>>> index 9a6e9b25d14a9..5264fb2b68b78 100644
>>> --- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>>> +++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
>>> @@ -36,18 +36,50 @@ properties:
>>>
>>> properties:
>>> port@0:
>>> - $ref: /schemas/graph.yaml#/properties/port
>>> + $ref: /schemas/graph.yaml#/$defs/port-base
>>
>> OK, that's correct.
>>
>>> + unevaluatedProperties: false
>>> description:
>>> Primary MIPI DSI port-1 for MIPI input or
>>> LVDS port-1 for LVDS input or DPI input.
>>>
>>> + properties:
>>> + endpoint:
>>> + $ref: /schemas/media/video-interfaces.yaml#
>>> + unevaluatedProperties: false
>>
>> That's correct.
>>
>>> +
>>> + properties:
>>> + data-lanes:
>>> + description: array of physical DSI data lane indexes.
>>> + minItems: 1
>>> + items:
>>> + - const: 1
>>> + - const: 2
>>> + - const: 3
>>> + - const: 4
>>
>> That's almost redundant in this context - it was already there - and the
>> point is that it solves noting in the problem you had. Binding still
>> does not validate the ABI and does not match it, still.
>>
>> Since commit foo bar, driver needs data-lanes, so what you need to do is
>> allow them and to require them. You can also specify their constraints
>> if device can be configured multiple ways, up to 4 lanes.
> Please pardon my ignorance, what exactly do you propose I change in this
> patch ?
Follow the subject - require data-lanes. That's was the main point of
this change, no?
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH 16/16] ARM: dts: renesas: r9a06g032: Describe the EIP-150 block
From: Rob Herring @ 2026-04-07 19:33 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Michael Turquette, Stephen Boyd, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-16-5e6ff7853994@bootlin.com>
On Fri, Mar 27, 2026 at 09:09:38PM +0100, Miquel Raynal (Schneider Electric) wrote:
> The EIP-150 is composed of 3 blocks:
> * An interrupt controller named EIP-201 AIC
> - fed by a clock coming from the EIP-150
> - connected to the main GIC
> * A random number generator named EIP-76
> - fed by a clock coming from the EIP-150
> - signalling interrupts through the AIC
> * A public key accelerator engine named EIP-28
> - Fed by a clock coming from the EIP-150
> - Signalling interrupts through the AIC
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> arch/arm/boot/dts/renesas/r9a06g032.dtsi | 42 ++++++++++++++++++++++++++++++++
> 1 file changed, 42 insertions(+)
>
> diff --git a/arch/arm/boot/dts/renesas/r9a06g032.dtsi b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
> index f4f760aff28b..6aaa93ed03d6 100644
> --- a/arch/arm/boot/dts/renesas/r9a06g032.dtsi
> +++ b/arch/arm/boot/dts/renesas/r9a06g032.dtsi
> @@ -8,6 +8,7 @@
>
> #include <dt-bindings/interrupt-controller/arm-gic.h>
> #include <dt-bindings/clock/r9a06g032-sysctrl.h>
> +#include <dt-bindings/interrupt-controller/inside-secure,safexcel-eip201.h>
>
> / {
> compatible = "renesas,r9a06g032";
> @@ -170,6 +171,47 @@ usb@2,0 {
> };
> };
>
> + eip150: bus@40040000 {
> + compatible = "inside-secure,safexcel-eip150", "simple-pm-bus";
> + clocks = <&sysctrl R9A06G032_HCLK_CRYPTO_EIP150>;
> + #clock-cells = <0>;
> + clock-map = <&sysctrl R9A06G032_HCLK_CRYPTO_EIP150>;
I don't get why you need clock-map here. Why can't you just put this
clock in each child node?
Rob
^ permalink raw reply
* Re: [PATCH 05/16] dt-bindings: bus: eip150: Describe the EIP-150 container node
From: Rob Herring @ 2026-04-07 19:44 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Michael Turquette, Stephen Boyd, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-5-5e6ff7853994@bootlin.com>
On Fri, Mar 27, 2026 at 09:09:27PM +0100, Miquel Raynal (Schneider Electric) wrote:
> Part of Inside-Secure's SafeXcel family, the EIP-150 is some kind of
> container node composed of:
> - a public key accelerator,
> - random number generator,
> - an interrupt controller.
>
> It also acts as proxy for the clocks.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> .../bus/inside-secure,safexcel-eip150.yaml | 58 ++++++++++++++++++++++
> 1 file changed, 58 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/bus/inside-secure,safexcel-eip150.yaml b/Documentation/devicetree/bindings/bus/inside-secure,safexcel-eip150.yaml
> new file mode 100644
> index 000000000000..1b3d83a852f5
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/bus/inside-secure,safexcel-eip150.yaml
> @@ -0,0 +1,58 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/bus/inside-secure,safexcel-eip150.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Inside-Secure SafeXcel EIP-150 container
> +
> +maintainers:
> + - Miquel Raynal <miquel.raynal@bootlin.com>
> +
> +description:
> + The EIP-150 is a hardware container, it has its own interrupt
> + controller inside to which a random number generator and a public key
> + accelerator are wired.
> +
> +allOf:
> + - $ref: simple-pm-bus.yaml#
> + - $ref: /schemas/clock/clock-nexus-node.yaml#
Generally, if a schema has 'select: true', you don't reference it as it
has already been applied. And you have to list the properties here
anyways because you need to define how many #clock-cells for example.
> +
> +properties:
> + compatible:
> + items:
> + - const: inside-secure,safexcel-eip150
> + - {} # simple-pm-bus, but not listed here to avoid false select
> +
> + clocks:
> + minItems: 1
Seems to me you are adding this to satisfy simple-pm-bus. Maybe this
should just be simple-bus?
> +
> + "#address-cells":
> + const: 1
> +
> + "#size-cells":
> + const: 1
> +
> + ranges: true
> +
> +patternProperties:
> + "^interrupt-controller@[0-9a-f]+$":
> + type: object
> + $ref: /schemas/interrupt-controller/inside-secure,safexcel-eip201.yaml#
Better to just list a compatible you require. Like this, the schema is
applied twice.
> +
> + "^rng@[0-9a-f]+$":
> + type: object
> + $ref: /schemas/rng/inside-secure,safexcel-eip76.yaml#
> +
> + "^crypto@[0-9a-f]+$":
> + type: object
> + $ref: /schemas/crypto/inside-secure,safexcel-eip28.yaml#
> +
> +required:
> + - compatible
> + - clocks
> + - "#address-cells"
> + - "#size-cells"
> + - ranges
The bus schema requires all these already.
Rob
^ permalink raw reply
* Re: [PATCH 02/16] dt-bindings: interrupt-controller: Describe EIP-201 AIC
From: Rob Herring (Arm) @ 2026-04-07 19:45 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Olivia Mackall, linux-crypto, Geert Uytterhoeven, David S. Miller,
Wolfram Sang, Thomas Petazzoni, Thomas Gleixner, devicetree,
Magnus Damm, Krzysztof Kozlowski, Antoine Tenart, linux-clk,
linux-renesas-soc, linux-kernel, Jayesh Choudhary,
Pascal EBERHARD, Conor Dooley, Christian Marangi, Herbert Xu,
Michael Turquette, Stephen Boyd
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-2-5e6ff7853994@bootlin.com>
On Fri, 27 Mar 2026 21:09:24 +0100, Miquel Raynal (Schneider Electric) wrote:
> The EIP-201 Advanced Interrupt Controller is part of a bigger container
> block from Inside Secure nicely named EIP-150. It typically takes one
> clock from the EIP-150 and offers basic controls through a few simple
> registers.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> .../inside-secure,safexcel-eip201.yaml | 41 ++++++++++++++++++++++
> .../inside-secure,safexcel-eip201.h | 14 ++++++++
> 2 files changed, 55 insertions(+)
>
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v2 1/6] dt-bindings: display/msm/gmu: Document Adreno 810 GMU
From: Akhil P Oommen @ 2026-04-07 19:45 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Bjorn Andersson,
linux-kernel
In-Reply-To: <20260402-adreno-810-v2-1-ce337ca87a9e@pm.me>
On 4/3/2026 4:39 AM, Alexander Koskovich wrote:
> Document Adreno 810 GMU in the dt-binding specification.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> .../devicetree/bindings/display/msm/gmu.yaml | 32 ++++++++++++++++++++++
> 1 file changed, 32 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/msm/gmu.yaml b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> index e32056ae0f5d..2853f6aef966 100644
> --- a/Documentation/devicetree/bindings/display/msm/gmu.yaml
> +++ b/Documentation/devicetree/bindings/display/msm/gmu.yaml
> @@ -299,6 +299,38 @@ allOf:
> required:
> - qcom,qmp
>
> + - if:
> + properties:
> + compatible:
> + contains:
> + const: qcom,adreno-gmu-810.0
> + then:
> + properties:
> + reg:
> + items:
> + - description: Core GMU registers
> + reg-names:
> + items:
> + - const: gmu
> + clocks:
> + items:
> + - description: GPU AHB clock
> + - description: GMU clock
> + - description: GPU CX clock
> + - description: GPU AXI clock
> + - description: GPU MEMNOC clock
> + - description: GMU HUB clock
> + - description: GPUSS DEMET clock
DEMET clk vote from sw is not required for Milos GPU.
-Akhil.
> + clock-names:
> + items:
> + - const: ahb
> + - const: gmu
> + - const: cxo
> + - const: axi
> + - const: memnoc
> + - const: hub
> + - const: demet
> +
> - if:
> properties:
> compatible:
>
^ permalink raw reply
* Re: [PATCH 03/16] dt-bindings: rng: Rename the title of the EIP-76 file
From: Rob Herring (Arm) @ 2026-04-07 19:47 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Magnus Damm, Thomas Gleixner, Michael Turquette, Antoine Tenart,
Christian Marangi, devicetree, linux-clk, Jayesh Choudhary,
Herbert Xu, Wolfram Sang, linux-kernel, linux-crypto,
David S. Miller, Conor Dooley, Stephen Boyd, linux-renesas-soc,
Geert Uytterhoeven, Krzysztof Kozlowski, Pascal EBERHARD,
Olivia Mackall, Thomas Petazzoni
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-3-5e6ff7853994@bootlin.com>
On Fri, 27 Mar 2026 21:09:25 +0100, Miquel Raynal (Schneider Electric) wrote:
> Be a little more precise in the title by giving the family name and the
> own name of the hardware block. Despite the original compatibles, this
> file describes a SafeXcel EIP-76 hardware random number generator.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> Documentation/devicetree/bindings/rng/inside-secure,safexcel-eip76.yaml | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
Acked-by: Rob Herring (Arm) <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH RFC v2 2/6] drm/msm/adreno: rename llc_mmio to cx_misc_mmio
From: Akhil P Oommen @ 2026-04-07 19:47 UTC (permalink / raw)
To: Alexander Koskovich, Rob Clark, Dmitry Baryshkov, Abhinav Kumar,
Jessica Zhang, Sean Paul, Marijn Suijten, Maarten Lankhorst,
Maxime Ripard, Thomas Zimmermann, David Airlie, Simona Vetter,
Rob Herring, Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio,
Bjorn Andersson
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel
In-Reply-To: <20260402-adreno-810-v2-2-ce337ca87a9e@pm.me>
On 4/3/2026 4:39 AM, Alexander Koskovich wrote:
> This region is used for more than just LLCC, it also provides access to
> software fuse values (raytracing, etc).
>
> Rename relevant symbols from _llc to _cx_misc for use in a follow up
> change that decouples this from LLCC.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
-Akhil
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 8 ++++----
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 16 ++++++++--------
> drivers/gpu/drm/msm/adreno/a6xx_gpu.h | 14 +++++++-------
> drivers/gpu/drm/msm/adreno/a8xx_gpu.c | 2 +-
> 4 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> index 916c5d99c4d1..23e5b3a22ea5 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
> @@ -947,7 +947,7 @@ static int a6xx_gmu_fw_start(struct a6xx_gmu *gmu, unsigned int state)
>
> /* Turn on TCM (Tightly Coupled Memory) retention */
> if (adreno_is_a7xx(adreno_gpu))
> - a6xx_llc_write(a6xx_gpu, REG_A7XX_CX_MISC_TCM_RET_CNTL, 1);
> + a6xx_cx_misc_write(a6xx_gpu, REG_A7XX_CX_MISC_TCM_RET_CNTL, 1);
> else if (!adreno_is_a8xx(adreno_gpu))
> gmu_write(gmu, REG_A6XX_GMU_GENERAL_7, 1);
>
> @@ -1215,7 +1215,7 @@ static int a6xx_gmu_secure_init(struct a6xx_gpu *a6xx_gpu)
> if (!qcom_scm_is_available()) {
> dev_warn_once(gpu->dev->dev,
> "SCM is not available, poking fuse register\n");
> - a6xx_llc_write(a6xx_gpu, REG_A7XX_CX_MISC_SW_FUSE_VALUE,
> + a6xx_cx_misc_write(a6xx_gpu, REG_A7XX_CX_MISC_SW_FUSE_VALUE,
> A7XX_CX_MISC_SW_FUSE_VALUE_RAYTRACING |
> A7XX_CX_MISC_SW_FUSE_VALUE_FASTBLEND |
> A7XX_CX_MISC_SW_FUSE_VALUE_LPAC);
> @@ -1236,7 +1236,7 @@ static int a6xx_gmu_secure_init(struct a6xx_gpu *a6xx_gpu)
> * firmware, find out whether that's the case. The scm call
> * above sets the fuse register.
> */
> - fuse_val = a6xx_llc_read(a6xx_gpu,
> + fuse_val = a6xx_cx_misc_read(a6xx_gpu,
> REG_A7XX_CX_MISC_SW_FUSE_VALUE);
> adreno_gpu->has_ray_tracing =
> !!(fuse_val & A7XX_CX_MISC_SW_FUSE_VALUE_RAYTRACING);
> @@ -1299,7 +1299,7 @@ int a6xx_gmu_resume(struct a6xx_gpu *a6xx_gpu)
>
> /* Check to see if we are doing a cold or warm boot */
> if (adreno_is_a7xx(adreno_gpu) || adreno_is_a8xx(adreno_gpu)) {
> - status = a6xx_llc_read(a6xx_gpu, REG_A7XX_CX_MISC_TCM_RET_CNTL) == 1 ?
> + status = a6xx_cx_misc_read(a6xx_gpu, REG_A7XX_CX_MISC_TCM_RET_CNTL) == 1 ?
> GMU_WARM_BOOT : GMU_COLD_BOOT;
> } else if (gmu->legacy) {
> status = gmu_read(gmu, REG_A6XX_GMU_GENERAL_7) == 1 ?
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index e1eae6cb1e40..9847f83b92af 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2039,7 +2039,7 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
> struct msm_gpu *gpu = &adreno_gpu->base;
> u32 cntl1_regval = 0;
>
> - if (IS_ERR(a6xx_gpu->llc_mmio))
> + if (IS_ERR(a6xx_gpu->cx_misc_mmio))
> return;
>
> if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
> @@ -2078,14 +2078,14 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
> * pagetables
> */
> if (!a6xx_gpu->have_mmu500) {
> - a6xx_llc_write(a6xx_gpu,
> + a6xx_cx_misc_write(a6xx_gpu,
> REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_1, cntl1_regval);
>
> /*
> * Program cacheability overrides to not allocate cache
> * lines on a write miss
> */
> - a6xx_llc_rmw(a6xx_gpu,
> + a6xx_cx_misc_rmw(a6xx_gpu,
> REG_A6XX_CX_MISC_SYSTEM_CACHE_CNTL_0, 0xF, 0x03);
> return;
> }
> @@ -2098,7 +2098,7 @@ static void a7xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
> struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> struct msm_gpu *gpu = &adreno_gpu->base;
>
> - if (IS_ERR(a6xx_gpu->llc_mmio))
> + if (IS_ERR(a6xx_gpu->cx_misc_mmio))
> return;
>
> if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
> @@ -2151,15 +2151,15 @@ static void a6xx_llc_slices_init(struct platform_device *pdev,
> of_node_put(phandle);
>
> if (is_a7xx || !a6xx_gpu->have_mmu500)
> - a6xx_gpu->llc_mmio = msm_ioremap(pdev, "cx_mem");
> + a6xx_gpu->cx_misc_mmio = msm_ioremap(pdev, "cx_mem");
> else
> - a6xx_gpu->llc_mmio = NULL;
> + a6xx_gpu->cx_misc_mmio = NULL;
>
> a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
> a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
>
> if (IS_ERR_OR_NULL(a6xx_gpu->llc_slice) && IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
> - a6xx_gpu->llc_mmio = ERR_PTR(-EINVAL);
> + a6xx_gpu->cx_misc_mmio = ERR_PTR(-EINVAL);
> }
>
> #define GBIF_CLIENT_HALT_MASK BIT(0)
> @@ -2560,7 +2560,7 @@ static int a6xx_read_speedbin(struct device *dev, struct a6xx_gpu *a6xx_gpu,
> return ret;
>
> if (info->quirks & ADRENO_QUIRK_SOFTFUSE) {
> - *speedbin = a6xx_llc_read(a6xx_gpu, REG_A8XX_CX_MISC_SW_FUSE_FREQ_LIMIT_STATUS);
> + *speedbin = a6xx_cx_misc_read(a6xx_gpu, REG_A8XX_CX_MISC_SW_FUSE_FREQ_LIMIT_STATUS);
> *speedbin = A8XX_CX_MISC_SW_FUSE_FREQ_LIMIT_STATUS_FINALFREQLIMIT(*speedbin);
> return 0;
> }
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> index eb431e5e00b1..648608c1c98e 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.h
> @@ -102,7 +102,7 @@ struct a6xx_gpu {
>
> bool has_whereami;
>
> - void __iomem *llc_mmio;
> + void __iomem *cx_misc_mmio;
> void *llc_slice;
> void *htw_llc_slice;
> bool have_mmu500;
> @@ -240,19 +240,19 @@ static inline bool a6xx_has_gbif(struct adreno_gpu *gpu)
> return true;
> }
>
> -static inline void a6xx_llc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
> +static inline void a6xx_cx_misc_rmw(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 mask, u32 or)
> {
> - return msm_rmw(a6xx_gpu->llc_mmio + (reg << 2), mask, or);
> + return msm_rmw(a6xx_gpu->cx_misc_mmio + (reg << 2), mask, or);
> }
>
> -static inline u32 a6xx_llc_read(struct a6xx_gpu *a6xx_gpu, u32 reg)
> +static inline u32 a6xx_cx_misc_read(struct a6xx_gpu *a6xx_gpu, u32 reg)
> {
> - return readl(a6xx_gpu->llc_mmio + (reg << 2));
> + return readl(a6xx_gpu->cx_misc_mmio + (reg << 2));
> }
>
> -static inline void a6xx_llc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
> +static inline void a6xx_cx_misc_write(struct a6xx_gpu *a6xx_gpu, u32 reg, u32 value)
> {
> - writel(value, a6xx_gpu->llc_mmio + (reg << 2));
> + writel(value, a6xx_gpu->cx_misc_mmio + (reg << 2));
> }
>
> #define shadowptr(_a6xx_gpu, _ring) ((_a6xx_gpu)->shadow_iova + \
> diff --git a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> index 9e6f2ed69247..8b4b022d9a6b 100644
> --- a/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a8xx_gpu.c
> @@ -103,7 +103,7 @@ void a8xx_gpu_get_slice_info(struct msm_gpu *gpu)
> return;
> }
>
> - slice_mask &= a6xx_llc_read(a6xx_gpu,
> + slice_mask &= a6xx_cx_misc_read(a6xx_gpu,
> REG_A8XX_CX_MISC_SLICE_ENABLE_FINAL);
>
> a6xx_gpu->slice_mask = slice_mask;
>
^ permalink raw reply
* Re: [PATCH 04/16] dt-bindings: crypto: eip28: Describe EIP-28 PKA
From: Rob Herring @ 2026-04-07 19:49 UTC (permalink / raw)
To: Miquel Raynal (Schneider Electric)
Cc: Michael Turquette, Stephen Boyd, Krzysztof Kozlowski,
Conor Dooley, Thomas Gleixner, Olivia Mackall, Herbert Xu,
Jayesh Choudhary, David S. Miller, Christian Marangi,
Antoine Tenart, Geert Uytterhoeven, Magnus Damm, Thomas Petazzoni,
Pascal EBERHARD, Wolfram Sang, linux-clk, devicetree,
linux-kernel, linux-crypto, linux-renesas-soc
In-Reply-To: <20260327-schneider-v7-0-rc1-crypto-v1-4-5e6ff7853994@bootlin.com>
On Fri, Mar 27, 2026 at 09:09:26PM +0100, Miquel Raynal (Schneider Electric) wrote:
> Describe the Public Key Accelerator named EIP-28 from Inside-Secure,
> part of the SafeXcel family, it is typically included in a bigger
> hardware container named EIP-150.
>
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
> .../crypto/inside-secure,safexcel-eip28.yaml | 31 ++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip28.yaml b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip28.yaml
> new file mode 100644
> index 000000000000..96acb257450a
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/inside-secure,safexcel-eip28.yaml
> @@ -0,0 +1,31 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/crypto/inside-secure,safexcel-eip28.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Inside-Secure SafeXcel EIP-28 Public Key Accelerator
> +
> +maintainers:
> + - Miquel Raynal <miquel.raynal@bootlin.com>
> +
> +properties:
> + compatible:
> + const: inside-secure,safexcel-eip28
> +
> + reg:
> + maxItems: 1
> +
> + interrupts:
> + maxItems: 3
> +
> + clocks:
> + minItems: 1
maxItems: 1
(only)
> +
> +required:
> + - compatible
> + - reg
> + - interrupts
> + - clocks
> +
> +additionalProperties: false
>
> --
> 2.51.1
>
^ permalink raw reply
* Re: [PATCH v4 6/6] clk: fsl-sai: Add MCLK generation support
From: Brian Masney @ 2026-04-07 19:57 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Michael Walle, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, Stephen Boyd,
devicetree, linux-kernel
In-Reply-To: <20260406215150.176599-6-marex@nabladev.com>
Hi Marek,
On Mon, Apr 06, 2026 at 11:49:46PM +0200, Marek Vasut wrote:
> The driver currently supports generating BCLK. There are systems which
> require generation of MCLK instead. Register new MCLK clock and handle
> clock-cells = <1> to differentiate between BCLK and MCLK. In case of a
> legacy system with clock-cells = <0>, the driver behaves as before, i.e.
> always returns BCLK.
>
> Note that it is not possible re-use the current SAI audio driver to
> generate MCLK and correctly enable and disable the MCLK.
>
> If SAI (audio driver) is used to control the MCLK enablement, then MCLK
> clock is not always enabled, and it is not necessarily enabled when the
> codec may need the clock to be enabled. There is also no way for the
> codec node to specify phandle to clock provider in DT, because the SAI
> (audio driver) is not clock provider.
>
> If SAI (clock driver) is used to control the MCLK enablement, then MCLK
> clock is enabled when the codec needs the clock enabled, because the
> codec is the clock consumer and the SAI (clock driver) is the clock
> provider, and the codec driver can request the clock to be enabled when
> needed. There is also the usual phandle to clock provider in DT, because
> the SAI (clock driver) is clock provider.
>
> Acked-by: Michael Walle <mwalle@kernel.org>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> V2: No change
> V3: - Rebase on current next, update mail address
> - Update commit message according to clarify the difference between
> SAI audio and SAI clock driver
> - Pick ancient AB from Michael, although this may be outdated
> https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-4-marex@denx.de/
> V4: Use the fsl_sai_clk_register() helper.
> ---
> drivers/clk/clk-fsl-sai.c | 31 ++++++++++++++++++++++++++++++-
> 1 file changed, 30 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
> index 7ec9a4f22735c..386ee5f77a986 100644
> --- a/drivers/clk/clk-fsl-sai.c
> +++ b/drivers/clk/clk-fsl-sai.c
> @@ -6,6 +6,7 @@
> */
>
> #include <linux/clk-provider.h>
> +#include <linux/clk.h>
This include needs to be moved earlier into the series to keep
bisectability. It looks like on patch 2. I'll also comment there.
> #include <linux/err.h>
> #include <linux/module.h>
> #include <linux/of.h>
> @@ -15,22 +16,37 @@
>
> #define I2S_CSR 0x00
> #define I2S_CR2 0x08
> +#define I2S_MCR 0x100
> #define CSR_BCE_BIT 28
> +#define CSR_TE_BIT 31
> #define CR2_BCD BIT(24)
> #define CR2_DIV_SHIFT 0
> #define CR2_DIV_WIDTH 8
> +#define MCR_MOE BIT(30)
>
> struct fsl_sai_clk {
> struct clk_divider bclk_div;
> + struct clk_divider mclk_div;
> struct clk_gate bclk_gate;
> + struct clk_gate mclk_gate;
> struct clk_hw *bclk_hw;
> + struct clk_hw *mclk_hw;
> spinlock_t lock;
> };
>
> struct fsl_sai_data {
> unsigned int offset; /* Register offset */
> + bool have_mclk; /* Have MCLK control */
> };
>
> +static struct clk_hw *
> +fsl_sai_of_clk_get(struct of_phandle_args *clkspec, void *data)
> +{
> + struct fsl_sai_clk *sai_clk = data;
> +
> + return clkspec->args[0] ? sai_clk->mclk_hw : sai_clk->bclk_hw;
For the case when clock-cells is 0, should this check:
clkspec->args_count == 0 || return clkspec->args[0]
Brian
^ permalink raw reply
* Re: [PATCH v4 2/6] clk: fsl-sai: Add i.MX8M support with 8 byte register offset
From: Brian Masney @ 2026-04-07 19:58 UTC (permalink / raw)
To: Marek Vasut
Cc: linux-clk, Peng Fan, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, Stephen Boyd,
devicetree, linux-kernel
In-Reply-To: <20260406215150.176599-2-marex@nabladev.com>
Hi Marek,
On Mon, Apr 06, 2026 at 11:49:42PM +0200, Marek Vasut wrote:
> The i.MX8M/Mini/Nano/Plus variant of the SAI IP has control registers
> shifted by +8 bytes and requires additional bus clock. Add support for
> the i.MX8M variant of the IP with this register shift and additional
> clock.
>
> Reviewed-by: Brian Masney <bmasney@redhat.com>
> Reviewed-by: Peng Fan <peng.fan@nxp.com>
> Signed-off-by: Marek Vasut <marex@nabladev.com>
> ---
> Cc: Brian Masney <bmasney@redhat.com>
> Cc: Conor Dooley <conor+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
> Cc: Michael Turquette <mturquette@baylibre.com>
> Cc: Michael Walle <michael@walle.cc>
> Cc: Rob Herring <robh@kernel.org>
> Cc: Stephen Boyd <sboyd@kernel.org>
> Cc: devicetree@vger.kernel.org
> Cc: linux-clk@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> ---
> V2: Update commit message, align it with the bindings one
> V3: - Rebase on current next, update mail address
> - Pick ancient RB from Peng, although this may be outdated
> https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-2-marex@denx.de/
> - Optionally enable "bus" clock, which are needed on MX8M to operate
> register file
> V4: Add RB from Brian
> ---
> drivers/clk/Kconfig | 2 +-
> drivers/clk/clk-fsl-sai.c | 27 +++++++++++++++++++++++----
> 2 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
> index cc8743b11bb1f..9f7f391a5615a 100644
> --- a/drivers/clk/Kconfig
> +++ b/drivers/clk/Kconfig
> @@ -255,7 +255,7 @@ config COMMON_CLK_FSL_FLEXSPI
>
> config COMMON_CLK_FSL_SAI
> bool "Clock driver for BCLK of Freescale SAI cores"
> - depends on ARCH_LAYERSCAPE || COMPILE_TEST
> + depends on ARCH_LAYERSCAPE || ARCH_MXC || COMPILE_TEST
> help
> This driver supports the Freescale SAI (Synchronous Audio Interface)
> to be used as a generic clock output. Some SoCs have restrictions
> diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
> index cba45e07562da..336aa8477d0ea 100644
> --- a/drivers/clk/clk-fsl-sai.c
> +++ b/drivers/clk/clk-fsl-sai.c
> @@ -26,11 +26,17 @@ struct fsl_sai_clk {
> spinlock_t lock;
> };
>
> +struct fsl_sai_data {
> + unsigned int offset; /* Register offset */
> +};
> +
> static int fsl_sai_clk_probe(struct platform_device *pdev)
> {
> struct device *dev = &pdev->dev;
> + const struct fsl_sai_data *data = device_get_match_data(dev);
> struct fsl_sai_clk *sai_clk;
> struct clk_parent_data pdata = { .index = 0 };
> + struct clk *clk_bus;
> void __iomem *base;
> struct clk_hw *hw;
>
> @@ -42,19 +48,23 @@ static int fsl_sai_clk_probe(struct platform_device *pdev)
> if (IS_ERR(base))
> return PTR_ERR(base);
>
> + clk_bus = devm_clk_get_optional_enabled(dev, "bus");
This patch needs to include <linux/clk.h> and drop it from patch 6 to
keep bisectability.
Brian
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Krzysztof Kozlowski @ 2026-04-07 19:59 UTC (permalink / raw)
To: guptarud, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <20260401-expressatt_fuel_guage-v3-1-9674cfc0b5a2@gmail.com>
On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
> From: Rudraksha Gupta <guptarud@gmail.com>
>
> Reorganize the DTS file for consistency with other msm8960 board files.
>
> Assisted-by: Claude:claude-opus-4.6
> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
> ---
> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408 +++++++++++----------
> 1 file changed, 207 insertions(+), 201 deletions(-)
>
Sorry, but no. We are not taking Claude as one determining coding style.
Are we going to do the work again the moment we come with proper tool?
Same comment as usually - this is highly invasive change which should be
done with dts linter, not LLM, not manually.
Best regards,
Krzysztof
^ permalink raw reply
* Re: [PATCH RFC v2 3/6] drm/msm/adreno: set cx_misc_mmio regardless of if platform has LLCC
From: Akhil P Oommen @ 2026-04-07 20:04 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
linux-kernel, Konrad Dybcio, Rob Clark, Dmitry Baryshkov,
Abhinav Kumar, Jessica Zhang, Sean Paul, Marijn Suijten,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Simona Vetter, Rob Herring, Krzysztof Kozlowski, Conor Dooley,
Konrad Dybcio, Bjorn Andersson
In-Reply-To: <20260402-adreno-810-v2-3-ce337ca87a9e@pm.me>
On 4/3/2026 4:39 AM, Alexander Koskovich wrote:
> Platforms without a LLCC (e.g. milos) still need to be able to read and
> write to the cx_mem region. Previously if LLCC slices were unavailable
> the cx_misc_mmio mapping was overwritten with ERR_PTR, causing a crash
> when the GMU later accessed cx_mem.
>
> Move the cx_misc_mmio mapping out of a6xx_llc_slices_init() into
> a6xx_gpu_init() so that cx_mem mapping is independent of LLCC.
>
> Reviewed-by: Konrad Dybcio <konrad.dybcio@oss.qualcomm.com>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 38 ++++++++++++++++-------------------
> 1 file changed, 17 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> index 9847f83b92af..d691ad1f88b3 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu.c
> @@ -2039,7 +2039,7 @@ static void a6xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
> struct msm_gpu *gpu = &adreno_gpu->base;
> u32 cntl1_regval = 0;
>
> - if (IS_ERR(a6xx_gpu->cx_misc_mmio))
> + if (IS_ERR_OR_NULL(a6xx_gpu->llc_slice) && IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
> return;
>
> if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
> @@ -2098,7 +2098,7 @@ static void a7xx_llc_activate(struct a6xx_gpu *a6xx_gpu)
> struct adreno_gpu *adreno_gpu = &a6xx_gpu->base;
> struct msm_gpu *gpu = &adreno_gpu->base;
>
> - if (IS_ERR(a6xx_gpu->cx_misc_mmio))
> + if (IS_ERR_OR_NULL(a6xx_gpu->llc_slice) && IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
> return;
>
> if (!llcc_slice_activate(a6xx_gpu->llc_slice)) {
> @@ -2135,31 +2135,12 @@ static void a6xx_llc_slices_destroy(struct a6xx_gpu *a6xx_gpu)
> static void a6xx_llc_slices_init(struct platform_device *pdev,
> struct a6xx_gpu *a6xx_gpu, bool is_a7xx)
> {
> - struct device_node *phandle;
> -
> /* No LLCC on non-RPMh (and by extension, non-GMU) SoCs */
> if (adreno_has_gmu_wrapper(&a6xx_gpu->base))
> return;
>
> - /*
> - * There is a different programming path for A6xx targets with an
> - * mmu500 attached, so detect if that is the case
> - */
> - phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
> - a6xx_gpu->have_mmu500 = (phandle &&
> - of_device_is_compatible(phandle, "arm,mmu-500"));
> - of_node_put(phandle);
> -
> - if (is_a7xx || !a6xx_gpu->have_mmu500)
> - a6xx_gpu->cx_misc_mmio = msm_ioremap(pdev, "cx_mem");
> - else
> - a6xx_gpu->cx_misc_mmio = NULL;
> -
> a6xx_gpu->llc_slice = llcc_slice_getd(LLCC_GPU);
> a6xx_gpu->htw_llc_slice = llcc_slice_getd(LLCC_GPUHTW);
> -
> - if (IS_ERR_OR_NULL(a6xx_gpu->llc_slice) && IS_ERR_OR_NULL(a6xx_gpu->htw_llc_slice))
> - a6xx_gpu->cx_misc_mmio = ERR_PTR(-EINVAL);
> }
>
> #define GBIF_CLIENT_HALT_MASK BIT(0)
> @@ -2621,6 +2602,7 @@ static struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
> struct platform_device *pdev = priv->gpu_pdev;
> struct adreno_platform_config *config = pdev->dev.platform_data;
> const struct adreno_info *info = config->info;
> + struct device_node *phandle;
> struct device_node *node;
> struct a6xx_gpu *a6xx_gpu;
> struct adreno_gpu *adreno_gpu;
> @@ -2656,6 +2638,20 @@ static struct msm_gpu *a6xx_gpu_init(struct drm_device *dev)
>
> a6xx_llc_slices_init(pdev, a6xx_gpu, is_a7xx);
>
> + /*
> + * There is a different programming path for A6xx targets with an
> + * mmu500 attached, so detect if that is the case
> + */
> + phandle = of_parse_phandle(pdev->dev.of_node, "iommus", 0);
> + a6xx_gpu->have_mmu500 = (phandle &&
> + of_device_is_compatible(phandle, "arm,mmu-500"));
> + of_node_put(phandle);
> +
> + if (is_a7xx || !a6xx_gpu->have_mmu500)
Instead of this check, I feel it is better to just add a
WARN_ONCE(a6xx_gpu->cx_misc_mmio) in the a6xx_cx_misc_* io accessors.
Then "a6xx_gpu->have_mmu500" init can be moved to the llc_init(). But
that is outside the scope of this series.
Reviewed-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
-Akhil
> + a6xx_gpu->cx_misc_mmio = msm_ioremap(pdev, "cx_mem");
> + else
> + a6xx_gpu->cx_misc_mmio = NULL;
> +
> ret = a6xx_set_supported_hw(&pdev->dev, a6xx_gpu, info);
> if (ret) {
> a6xx_llc_slices_destroy(a6xx_gpu);
>
^ permalink raw reply
* Re: [PATCH 07/19] drm/panel: himax-hx83102: support Waveshare 12.3" DSI panel
From: Linus Walleij @ 2026-04-07 20:12 UTC (permalink / raw)
To: Dmitry Baryshkov
Cc: Neil Armstrong, Jessica Zhang, David Airlie, Simona Vetter,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Cong Yang, Ondrej Jirman,
Javier Martinez Canillas, Jagan Teki, Liam Girdwood, Mark Brown,
Bartosz Golaszewski, dri-devel, devicetree, linux-kernel,
linux-gpio
In-Reply-To: <20260401-waveshare-dsi-touch-v1-7-5e9119b5a014@oss.qualcomm.com>
Hi Dmitry,
thanks for your patch!
On Wed, Apr 1, 2026 at 9:26 AM Dmitry Baryshkov
<dmitry.baryshkov@oss.qualcomm.com> wrote:
> Add support for the Waveshare 12.3" DSI TOUCH-A panel. According to the
> vendor driver, it uses different mode_flags, so let the panel
> descriptions override driver-wide defaults.
>
> Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
(...)
> +#define HX83102_UNKNOWN_BB 0xbb
(...)
> +#define HX83102_UNKNOWN_C2 0xc2
> +#define HX83102_UNKNOWN_C6 0xc6
What I am unable to fathom is why Qualcomm, a fortune 500 company, would be
unable to muscle out the datasheet for this display controller from
the panel vendor
and provide some proper names for these defines.
Could you try to ask Waveshare to just share the datasheet so you can say
what is going on here.
If we have too many *UNKNOWN_NN" it will get hard to see of the same code
can be introduced and refactored into other inits without risk of breaking
something is my thinking here.
If it's like ... really hard for you to achieve this I guess I will
grumpily accept it
but it'd be nice if you try sending the message that we want to know what these
things are.
Yours,
Linus Walleij
^ permalink raw reply
* [PATCH] arm64: dts: qcom: monaco: Add default GIC address cells
From: Krzysztof Kozlowski @ 2026-04-07 20:15 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, Manivannan Sadhasivam, Ziyue Zhang, linux-arm-msm,
devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Add missing address-cells 0 to GIC interrupt node to silence W=1
warning:
monaco.dtsi:2326.4-2329.30: Warning (interrupt_map): /soc@0/pci@1c00000:interrupt-map:
Missing property '#address-cells' in node /soc@0/interrupt-controller@17a00000, using 0 as fallback
Value '0' is correct because:
1. GIC interrupt controller does not have children,
2. interrupt-map property (in PCI node) consists of five components and
the fourth component 'parent unit address', which size is defined by
'#address-cells' of the node pointed to by the interrupt-parent
component, is not used (=0).
Fixes: 46a7c01e7e9d ("arm64: dts: qcom: qcs8300: enable pcie0")
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
Fix for v7.0-rcX.
---
arch/arm64/boot/dts/qcom/monaco.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/qcom/monaco.dtsi b/arch/arm64/boot/dts/qcom/monaco.dtsi
index 7b1d57460f1e..5f060b24d52e 100644
--- a/arch/arm64/boot/dts/qcom/monaco.dtsi
+++ b/arch/arm64/boot/dts/qcom/monaco.dtsi
@@ -7380,6 +7380,7 @@ intc: interrupt-controller@17a00000 {
interrupt-controller;
#redistributor-regions = <1>;
redistributor-stride = <0x0 0x20000>;
+ #address-cells = <0>;
};
watchdog@17c10000 {
--
2.51.0
^ permalink raw reply related
* [PATCH] arm64: dts: qcom: Use GIC_SPI macro for interrupt-map
From: Krzysztof Kozlowski @ 2026-04-07 20:18 UTC (permalink / raw)
To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
Conor Dooley, linux-arm-msm, devicetree, linux-kernel
Cc: Krzysztof Kozlowski
Make the complicated interrupt-map property (with multiple '0' entries)
a bit more readable by using known define for GIC_SPI.
Signed-off-by: Krzysztof Kozlowski <krzysztof.kozlowski@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/glymur.dtsi | 32 ++++++++++++-------------
arch/arm64/boot/dts/qcom/kaanapali.dtsi | 8 +++----
arch/arm64/boot/dts/qcom/msm8998.dtsi | 8 +++----
arch/arm64/boot/dts/qcom/sm8750.dtsi | 8 +++----
4 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/arm64/boot/dts/qcom/glymur.dtsi b/arch/arm64/boot/dts/qcom/glymur.dtsi
index f23cf81ddb77..0a3cf2c62c3e 100644
--- a/arch/arm64/boot/dts/qcom/glymur.dtsi
+++ b/arch/arm64/boot/dts/qcom/glymur.dtsi
@@ -2776,10 +2776,10 @@ pcie4: pci@1bf0000 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 513 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 514 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 515 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 516 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 513 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 514 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 515 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 516 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_4_AUX_CLK>,
<&gcc GCC_PCIE_4_CFG_AHB_CLK>,
@@ -2986,10 +2986,10 @@ pcie5: pci@1b40000 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 526 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 428 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 429 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 435 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 526 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 428 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 429 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 435 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_5_AUX_CLK>,
<&gcc GCC_PCIE_5_CFG_AHB_CLK>,
@@ -3252,10 +3252,10 @@ pcie6: pci@1c00000 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 472 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 473 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 474 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 475 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 472 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 473 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 474 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 475 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_6_AUX_CLK>,
<&gcc GCC_PCIE_6_CFG_AHB_CLK>,
@@ -3462,10 +3462,10 @@ pcie3b: pci@1b80000 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 831 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 832 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 833 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 834 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 831 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 832 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 833 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 834 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_3B_AUX_CLK>,
<&gcc GCC_PCIE_3B_CFG_AHB_CLK>,
diff --git a/arch/arm64/boot/dts/qcom/kaanapali.dtsi b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
index 7cc326aa1a1a..322ebfad6bf7 100644
--- a/arch/arm64/boot/dts/qcom/kaanapali.dtsi
+++ b/arch/arm64/boot/dts/qcom/kaanapali.dtsi
@@ -2313,10 +2313,10 @@ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>,
iommu-map = <0 &apps_smmu 0x1400 0x1>,
<0x100 &apps_smmu 0x1401 0x1>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
interrupt-map-mask = <0 0 0 0x7>;
#interrupt-cells = <1>;
diff --git a/arch/arm64/boot/dts/qcom/msm8998.dtsi b/arch/arm64/boot/dts/qcom/msm8998.dtsi
index d41b5c470c48..347706011637 100644
--- a/arch/arm64/boot/dts/qcom/msm8998.dtsi
+++ b/arch/arm64/boot/dts/qcom/msm8998.dtsi
@@ -955,10 +955,10 @@ pcie0: pcie@1c00000 {
"msi7",
"global";
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 135 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 136 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 138 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 139 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 GIC_SPI 135 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 GIC_SPI 136 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 GIC_SPI 138 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 GIC_SPI 139 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_0_PIPE_CLK>,
<&gcc GCC_PCIE_0_AUX_CLK>,
diff --git a/arch/arm64/boot/dts/qcom/sm8750.dtsi b/arch/arm64/boot/dts/qcom/sm8750.dtsi
index 18fb52c14acd..ae7891c0eddc 100644
--- a/arch/arm64/boot/dts/qcom/sm8750.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm8750.dtsi
@@ -5202,10 +5202,10 @@ pcie0: pcie@1c00000 {
#interrupt-cells = <1>;
interrupt-map-mask = <0 0 0 0x7>;
- interrupt-map = <0 0 0 1 &intc 0 0 0 149 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 2 &intc 0 0 0 150 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 3 &intc 0 0 0 151 IRQ_TYPE_LEVEL_HIGH>,
- <0 0 0 4 &intc 0 0 0 152 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-map = <0 0 0 1 &intc 0 0 GIC_SPI 149 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 2 &intc 0 0 GIC_SPI 150 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 3 &intc 0 0 GIC_SPI 151 IRQ_TYPE_LEVEL_HIGH>,
+ <0 0 0 4 &intc 0 0 GIC_SPI 152 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_PCIE_0_AUX_CLK>,
<&gcc GCC_PCIE_0_CFG_AHB_CLK>,
--
2.51.0
^ permalink raw reply related
* Re: [PATCH net-next v2 4/5] dt-bindings: dpll: add ref-sync-sources property
From: Rob Herring @ 2026-04-07 20:18 UTC (permalink / raw)
To: Ivan Vecera
Cc: netdev, Petr Oros, Prathosh Satish, Arkadiusz Kubalewski,
Jiri Pirko, Michal Schmidt, Simon Horman, Vadim Fedorenko,
linux-kernel, Conor Dooley, Krzysztof Kozlowski, devicetree,
Pasi Vaananen
In-Reply-To: <20260328080624.593916-5-ivecera@redhat.com>
On Sat, Mar 28, 2026 at 09:06:23AM +0100, Ivan Vecera wrote:
> Add ref-sync-sources phandle-array property to the dpll-pin schema
> allowing board designers to declare which input pins can serve as
> sync sources in a Reference-Sync pair. A Ref-Sync pair consists of
> a clock reference and a low-frequency sync signal where the DPLL locks
> to the clock but phase-aligns to the sync reference.
>
> Update both examples in the Microchip ZL3073x binding to demonstrate
> the new property with a 1 PPS sync source paired to a clock source.
>
> Reviewed-by: Petr Oros <poros@redhat.com>
> Reviewed-by: Prathosh Satish <Prathosh.Satish@microchip.com>
> Signed-off-by: Ivan Vecera <ivecera@redhat.com>
> ---
> .../devicetree/bindings/dpll/dpll-pin.yaml | 11 +++++++
> .../bindings/dpll/microchip,zl30731.yaml | 30 ++++++++++++++-----
> 2 files changed, 34 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> index 51db93b77306f..7084f102e274c 100644
> --- a/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> +++ b/Documentation/devicetree/bindings/dpll/dpll-pin.yaml
> @@ -36,6 +36,17 @@ properties:
> description: String exposed as the pin board label
> $ref: /schemas/types.yaml#/definitions/string
>
> + ref-sync-sources:
> + description: |
> + List of phandles to input pins that can serve as the sync source
> + in a Reference-Sync pair with this pin acting as the clock source.
> + A Ref-Sync pair consists of a clock reference and a low-frequency
> + sync signal. The DPLL locks to the clock reference but
> + phase-aligns to the sync reference.
> + Only valid for input pins. Each referenced pin must be a
> + different input pin on the same device.
> + $ref: /schemas/types.yaml#/definitions/phandle-array
phandle-array is really a matrix. As there are no arg cells here, for
a list of phandles you need:
items:
maxItems: 1
With that,
Reviewed-by: Rob Herring (Arm) <robh@kernel.org>
Rob
^ permalink raw reply
* [PATCH v2] dt-bindings: display: bridge: lt9211: Require data-lanes on DSI input ports
From: Marek Vasut @ 2026-04-07 20:31 UTC (permalink / raw)
To: devicetree
Cc: Marek Vasut, Andrzej Hajda, Conor Dooley, David Airlie,
Jernej Skrabec, Jonas Karlman, Krzysztof Kozlowski,
Laurent Pinchart, Maarten Lankhorst, Maxime Ripard,
Neil Armstrong, Rob Herring, Robert Foss, Simona Vetter,
Thomas Zimmermann, dri-devel, linux-kernel
The Lontium LT9211 is capable of 1..4 DSI lanes per input DSI port,
describe the lane count for each input port in the schema.
For example Linux kernel driver does already use that information and
fails to probe if it is missing.
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Andrzej Hajda <andrzej.hajda@intel.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: David Airlie <airlied@gmail.com>
Cc: Jernej Skrabec <jernej.skrabec@gmail.com>
Cc: Jonas Karlman <jonas@kwiboo.se>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Laurent Pinchart <Laurent.pinchart@ideasonboard.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Maxime Ripard <mripard@kernel.org>
Cc: Neil Armstrong <neil.armstrong@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Cc: Robert Foss <rfoss@kernel.org>
Cc: Simona Vetter <simona@ffwll.ch>
Cc: Thomas Zimmermann <tzimmermann@suse.de>
Cc: devicetree@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-kernel@vger.kernel.org
---
V2: - Update commit message, indicate Linux already requires data-lanes property
- Add required: data-lanes
---
.../display/bridge/lontium,lt9211.yaml | 43 ++++++++++++++++++-
1 file changed, 41 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
index 9a6e9b25d14a9..7cfe92a8bcd72 100644
--- a/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/lontium,lt9211.yaml
@@ -36,18 +36,56 @@ properties:
properties:
port@0:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Primary MIPI DSI port-1 for MIPI input or
LVDS port-1 for LVDS input or DPI input.
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+
port@1:
- $ref: /schemas/graph.yaml#/properties/port
+ $ref: /schemas/graph.yaml#/$defs/port-base
+ unevaluatedProperties: false
description:
Additional MIPI port-2 for MIPI input or LVDS port-2
for LVDS input. Used in combination with primary
port-1 to drive higher resolution displays
+ properties:
+ endpoint:
+ $ref: /schemas/media/video-interfaces.yaml#
+ unevaluatedProperties: false
+
+ properties:
+ data-lanes:
+ description: array of physical DSI data lane indexes.
+ minItems: 1
+ items:
+ - const: 1
+ - const: 2
+ - const: 3
+ - const: 4
+
+ required:
+ - data-lanes
+
port@2:
$ref: /schemas/graph.yaml#/properties/port
description:
@@ -99,6 +137,7 @@ examples:
reg = <0>;
endpoint {
+ data-lanes = <1 2 3 4>;
remote-endpoint = <&dsi0_out>;
};
};
--
2.53.0
^ permalink raw reply related
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Rudraksha Gupta @ 2026-04-07 20:39 UTC (permalink / raw)
To: Krzysztof Kozlowski, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <8e4ee378-113e-463d-8b21-eeef74b84120@kernel.org>
On 4/7/26 12:59, Krzysztof Kozlowski wrote:
> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>> From: Rudraksha Gupta <guptarud@gmail.com>
>>
>> Reorganize the DTS file for consistency with other msm8960 board files.
>>
>> Assisted-by: Claude:claude-opus-4.6
>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>> ---
>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408 +++++++++++----------
>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>
> Sorry, but no. We are not taking Claude as one determining coding style.
> Are we going to do the work again the moment we come with proper tool?
There is no tool currently to auto format DTS, and doesn't seem to be
coming for a while:
https://www.youtube.com/watch?v=cvoIbTL_ZQA
Claude didn't determine the coding style. I did based on sony-huashan,
which is already upstream:
https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
I just used Claude to do the manual work for me. In v2, I made sure the
diff before and after the change was nill. v3 included additional
changes requested by Konrad and some comments that I remembered during
prior attempts mainlining patch series for this device.
>
> Same comment as usually - this is highly invasive change which should be
> done with dts linter, not LLM, not manually.
>
> Best regards,
> Krzysztof
^ permalink raw reply
* Re: [PATCH v4 5/6] clk: fsl-sai: Extract clock setup into fsl_sai_clk_register()
From: Marek Vasut @ 2026-04-07 20:43 UTC (permalink / raw)
To: Brian Masney
Cc: linux-clk, Conor Dooley, Krzysztof Kozlowski, Michael Turquette,
Michael Walle, Rob Herring, Stephen Boyd, devicetree,
linux-kernel
In-Reply-To: <adVU-VgLI0MCIjz7@redhat.com>
On 4/7/26 9:03 PM, Brian Masney wrote:
[...]
>> +static int fsl_sai_clk_register(struct device *dev, void __iomem *base,
>> + spinlock_t *lock, struct clk_divider *div,
>> + struct clk_gate *gate, struct clk_hw **hw,
>> + const int gate_bit, const int dir_bit,
>> + const int div_reg, char *name)
>> +{
>> + const struct fsl_sai_data *data = device_get_match_data(dev);
>> + struct clk_parent_data pdata = { .index = 0 };
>> + struct clk_hw *chw;
>> + char *cname;
>> +
>> + gate->reg = base + data->offset + I2S_CSR;
>> + gate->bit_idx = gate_bit;
>> + gate->lock = lock;
>> +
>> + div->reg = base + div_reg;
>> + div->shift = CR2_DIV_SHIFT;
>> + div->width = CR2_DIV_WIDTH;
>> + div->lock = lock;
>> +
>> + cname = devm_kasprintf(dev, GFP_KERNEL, "%s.%s",
>> + of_node_full_name(dev->of_node), name);
>> + if (!cname)
>> + return -ENOMEM;
>> +
>> + chw = devm_clk_hw_register_composite_pdata(dev, cname,
>> + &pdata, 1, NULL, NULL,
>> + &div->hw,
>> + &clk_divider_ops,
>> + &gate->hw,
>> + &clk_gate_ops,
>> + CLK_SET_RATE_GATE);
>> + if (IS_ERR(hw))
>> + return PTR_ERR(hw);
>
> s/hw/chw/ on the two lines above.
>
>> +
>> + *hw = chw;
>> +
>> + /* Set clock direction */
>> + writel(dir_bit, base + div_reg);
>
> The previous behavior of the code was to call writel() and then register
> the clk. This flips it. Just to be sure no regressions are introduced,
> should we keep the old behavior?
I believe this is the correct ordering -- if the clock registration
fails, the clock direction is not going to be configured into hardware.
The clock driver does not operate the clock direction bit after this
write, so whether this write happens before or after the clock
registration has no other impact.
The rest of the items are addressed in V5, thanks !
^ permalink raw reply
* Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs and enable-dma properties
From: Rob Herring @ 2026-04-07 20:44 UTC (permalink / raw)
To: Ryan Chen
Cc: Jeremy Kerr, Krzysztof Kozlowski,
andriy.shevchenko@linux.intel.com, Andi Shyti,
Krzysztof Kozlowski, Conor Dooley, Joel Stanley, Andrew Jeffery,
Benjamin Herrenschmidt, Philipp Zabel, linux-i2c@vger.kernel.org,
devicetree@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-aspeed@lists.ozlabs.org, linux-kernel@vger.kernel.org,
openbmc@lists.ozlabs.org
In-Reply-To: <TY2PPF5CB9A1BE64B7988CD85A7189164E1F253A@TY2PPF5CB9A1BE6.apcprd06.prod.outlook.com>
On Tue, Mar 31, 2026 at 07:30:58AM +0000, Ryan Chen wrote:
> > Subject: Re: [PATCH v28 2/4] dt-bindings: i2c: ast2600-i2c.yaml: Add global-regs
> > and enable-dma properties
> >
> > Hi Ryan,
> >
> > > > Sounds reasonable, but before you do so, how are you planning to
> > > > manage the allocation of DMA channels across multiple i2c peripherals?
> > > >
> > > The AST2600 I2C hardware has only one can use DMA at a time.
> > > To avoid the complexity of managing DMA channel contention, I plan to
> > > use buffer mode by default for all controllers, which still provides
> > > better performance than byte mode without requiring DMA channel
> > allocation.
> >
> > OK, but your wording there ("by default") implies that DMA is still selectable
> > for one controller peripheral. In which case: you still have the problem of
> > managing DMA channel contention, but now it's at runtime instead.
> >
> > So my question still stands: how are you planning to enforce that DMA is only
> > enabled for one controller?
> >
> > Or are you planning to disable I2C DMA entirely on AST2600?
> Yes, This is my intent to do.
> Disable I2C DMA entirely on AST2600.
> If I remove DMA, should can I keep byte and buffer for sysfs?
28 versions and it's still not clear when you need what mode. Sigh. The
only thing better about sysfs then it's not my problem, but that really
doesn't sound much better.
DMA is only going to be useful for transfers above a certain size. If
you are doing the typical SMBus style register accesses, then DMA is
completely useless. The setup DMA overhead is going to be greater than
just directly reading/writing the I2C controller FIFOs. What's the size
that makes DMA useful? 16, 32, 64 bytes? Something greater than the max
size in buffer mode probably. Really, provide some data that DMA gives
better performance and/or less CPU usage. If you set some minimum size
and request DMA only above that size, is there really that much
contention? If there's some specific device that really needs DMA, then
make that device's driver request it and reserve it.
For byte mode, there's not a clear need nor description of why. Someone
once long ago asked for it... Who cares, if they really want it, then
the issue needs to be described. If a certain device requires certain
timing that byte mode provides, then that should be some property the
driver for the device communicates to the controller. No need for DT
nor sysfs in that case.
Rob
^ permalink raw reply
* Re: [PATCH RFC v2 5/6] drm/msm/adreno: add Adreno 810 GPU support
From: Akhil P Oommen @ 2026-04-07 20:56 UTC (permalink / raw)
To: Alexander Koskovich
Cc: Luca Weiss, linux-arm-msm, dri-devel, freedreno, devicetree,
Rob Clark, Dmitry Baryshkov, Abhinav Kumar, Jessica Zhang,
Sean Paul, Marijn Suijten, Maarten Lankhorst, Maxime Ripard,
Thomas Zimmermann, David Airlie, Simona Vetter, Rob Herring,
Krzysztof Kozlowski, Conor Dooley, Konrad Dybcio, Bjorn Andersson,
linux-kernel
In-Reply-To: <20260402-adreno-810-v2-5-ce337ca87a9e@pm.me>
On 4/3/2026 4:39 AM, Alexander Koskovich wrote:
> Add catalog entry and register configuration for the Adreno 810
> found in Qualcomm SM7635 (Milos) based devices.
>
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> drivers/gpu/drm/msm/adreno/a6xx_catalog.c | 271 ++++++++++++++++++++++++++++++
> drivers/gpu/drm/msm/adreno/adreno_gpu.h | 5 +
> 2 files changed, 276 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> index 550ff3a9b82e..8a57e6f9cee0 100644
> --- a/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> +++ b/drivers/gpu/drm/msm/adreno/a6xx_catalog.c
> @@ -1799,6 +1799,240 @@ static const struct adreno_reglist_pipe x285_dyn_pwrup_reglist_regs[] = {
> };
> DECLARE_ADRENO_REGLIST_PIPE_LIST(x285_dyn_pwrup_reglist);
>
> +static const struct adreno_reglist_pipe a810_nonctxt_regs[] = {
> + { REG_A8XX_CP_SMMU_STREAM_ID_LPAC, 0x00000101, BIT(PIPE_NONE) },
> + { REG_A8XX_GRAS_DBG_ECO_CNTL, 0x00f80800, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A6XX_PC_AUTO_VERTEX_STRIDE, 0x00000001, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_VIS_STREAM_CNTL, 0x10010000, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CONTEXT_SWITCH_STABILIZE_CNTL_1, 0x00000002, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_1, 0x00000003, BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_1, 0x00000023, BIT(PIPE_BV) }, /* Avoid partial waves at VFD */
> + { REG_A8XX_PC_CHICKEN_BITS_2, 0x00000200, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_3, 0x00500000, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_4, 0x00500050, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A7XX_RB_CCU_CNTL, 0x00000068, BIT(PIPE_BR) },
> + { REG_A8XX_RB_RESOLVE_PREFETCH_CNTL, 0x00000007, BIT(PIPE_BR) },
> + { REG_A8XX_RB_CMP_DBG_ECO_CNTL, 0x00004000, BIT(PIPE_BR) },
> + { REG_A8XX_RBBM_NC_MODE_CNTL, 0x00000001, BIT(PIPE_NONE) },
> + { REG_A8XX_RBBM_SLICE_NC_MODE_CNTL, 0x00000001, BIT(PIPE_NONE) },
> + { REG_A8XX_RBBM_WAIT_IDLE_CLOCKS_CNTL, 0x00000030, BIT(PIPE_NONE) },
> + { REG_A8XX_RBBM_WAIT_IDLE_CLOCKS_CNTL2, 0x00000030, BIT(PIPE_NONE) },
> + { REG_A8XX_UCHE_GBIF_GX_CONFIG, 0x010240e0, BIT(PIPE_NONE) },
> + { REG_A8XX_RBBM_GBIF_CLIENT_QOS_CNTL, 0x22122212, BIT(PIPE_NONE) },
> + { REG_A8XX_RBBM_CGC_P2S_CNTL, 0x00000040, BIT(PIPE_NONE) },
> + /*
> + * BIT(22): Disable PS out of order retire
> + * BIT(23): Enable half wave mode and MM instruction src&dst is half precision
> + */
> + { REG_A7XX_SP_CHICKEN_BITS_2, BIT(22) | BIT(23), BIT(PIPE_NONE) },
> + { REG_A7XX_SP_CHICKEN_BITS_3, 0x00300000, BIT(PIPE_NONE) },
> + { REG_A6XX_SP_PERFCTR_SHADER_MASK, 0x0000003f, BIT(PIPE_NONE) },
> + { REG_A7XX_SP_HLSQ_TIMEOUT_THRESHOLD_DP, 0x00000080, BIT(PIPE_NONE) },
> + { REG_A7XX_SP_READ_SEL, 0x0001ff00, BIT(PIPE_NONE) },
> + { REG_A6XX_TPL1_DBG_ECO_CNTL, 0x10000000, BIT(PIPE_NONE) },
> + { REG_A6XX_TPL1_DBG_ECO_CNTL1, 0x00000724, BIT(PIPE_NONE) },
> + { REG_A6XX_UCHE_MODE_CNTL, 0x00020000, BIT(PIPE_NONE) },
> + { REG_A8XX_UCHE_CCHE_MODE_CNTL, 0x00001000, BIT(PIPE_NONE) },
> + { REG_A8XX_UCHE_CCHE_CACHE_WAYS, 0x00000800, BIT(PIPE_NONE) },
> + { REG_A8XX_UCHE_CACHE_WAYS, 0x00080000, BIT(PIPE_NONE) },
> + { REG_A8XX_UCHE_VARB_IDLE_TIMEOUT, 0x00000020, BIT(PIPE_NONE) },
> + { REG_A7XX_VFD_DBG_ECO_CNTL, 0x00008000, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_BV_THRESHOLD, 0x00500050, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_BR_THRESHOLD, 0x00600060, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_BUSY_REQ_CNT, 0x00200020, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_LP_REQ_CNT, 0x00100020, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VPC_FLATSHADE_MODE_CNTL, 0x00000001, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VSC_BIN_SIZE, 0x00010001, BIT(PIPE_NONE) },
> + { REG_A8XX_RB_GC_GMEM_PROTECT, 0x00900000, BIT(PIPE_BR) },
> + { },
> +};
> +
> +static const u32 a810_protect_regs[] = {
> + A6XX_PROTECT_RDONLY(0x00000, 0x03a3),
> + A6XX_PROTECT_RDONLY(0x003b4, 0x008b),
> + A6XX_PROTECT_NORDWR(0x00440, 0x001f),
> + A6XX_PROTECT_RDONLY(0x00580, 0x005f),
> + A6XX_PROTECT_NORDWR(0x005e0, 0x011f),
> + A6XX_PROTECT_RDONLY(0x0074a, 0x0005),
> + A6XX_PROTECT_RDONLY(0x00759, 0x0026),
> + A6XX_PROTECT_RDONLY(0x00789, 0x0000),
> + A6XX_PROTECT_RDONLY(0x0078c, 0x0013),
> + A6XX_PROTECT_NORDWR(0x00800, 0x0029),
> + A6XX_PROTECT_NORDWR(0x00837, 0x00af),
> + A6XX_PROTECT_RDONLY(0x008e7, 0x00c9),
> + A6XX_PROTECT_NORDWR(0x008ec, 0x00c3),
> + A6XX_PROTECT_NORDWR(0x009b1, 0x0250),
> + A6XX_PROTECT_RDONLY(0x00ce0, 0x0001),
> + A6XX_PROTECT_RDONLY(0x00df0, 0x0000),
> + A6XX_PROTECT_NORDWR(0x00df1, 0x0000),
> + A6XX_PROTECT_NORDWR(0x00e01, 0x0000),
> + A6XX_PROTECT_NORDWR(0x00e03, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x03c00, 0x00c5),
> + A6XX_PROTECT_RDONLY(0x03cc6, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x08600, 0x01ff),
> + A6XX_PROTECT_NORDWR(0x08e00, 0x00ff),
> + A6XX_PROTECT_RDONLY(0x08f00, 0x0000),
> + A6XX_PROTECT_NORDWR(0x08f01, 0x01be),
> + A6XX_PROTECT_NORDWR(0x09600, 0x01ff),
> + A6XX_PROTECT_RDONLY(0x0981a, 0x02e5),
> + A6XX_PROTECT_NORDWR(0x09e00, 0x01ff),
> + A6XX_PROTECT_NORDWR(0x0a600, 0x01ff),
> + A6XX_PROTECT_NORDWR(0x0ae00, 0x0006),
> + A6XX_PROTECT_NORDWR(0x0ae08, 0x0006),
> + A6XX_PROTECT_NORDWR(0x0ae10, 0x036f),
> + A6XX_PROTECT_NORDWR(0x0b600, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x0dc00, 0x1fff),
> + A6XX_PROTECT_RDONLY(0x0fc00, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x18400, 0x003f),
> + A6XX_PROTECT_RDONLY(0x18440, 0x013f),
> + A6XX_PROTECT_NORDWR(0x18580, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x1b400, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x1f400, 0x0477),
> + A6XX_PROTECT_RDONLY(0x1f878, 0x0787),
> + A6XX_PROTECT_NORDWR(0x1f930, 0x0329),
> + A6XX_PROTECT_NORDWR(0x20000, 0x1fff),
> + A6XX_PROTECT_NORDWR(0x27800, 0x007f),
> + A6XX_PROTECT_RDONLY(0x27880, 0x0381),
> + A6XX_PROTECT_NORDWR(0x27882, 0x0001),
> + /* CP_PROTECT_REG[46, 62] are left untouched! */
> + 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
This is unnecessary waste of space. Were you trying to align with the
downstream code?
> + A6XX_PROTECT_NORDWR(0x27c02, 0x0000),
> +};
> +DECLARE_ADRENO_PROTECT(a810_protect, 64);
Please add this to the __build_asserts() below.
> +
> +static const uint32_t a810_pwrup_reglist_regs[] = {
> + REG_A6XX_UCHE_MODE_CNTL,
> + REG_A8XX_UCHE_VARB_IDLE_TIMEOUT,
> + REG_A8XX_UCHE_GBIF_GX_CONFIG,
> + REG_A8XX_UCHE_CACHE_WAYS,
> + REG_A8XX_UCHE_CCHE_MODE_CNTL,
> + REG_A8XX_UCHE_CCHE_CACHE_WAYS,
> + REG_A8XX_UCHE_CCHE_GC_GMEM_RANGE_MIN,
> + REG_A8XX_UCHE_CCHE_GC_GMEM_RANGE_MIN + 1,
> + REG_A8XX_UCHE_WRITE_THRU_BASE,
> + REG_A8XX_UCHE_WRITE_THRU_BASE + 1,
> + REG_A8XX_UCHE_TRAP_BASE,
> + REG_A8XX_UCHE_TRAP_BASE + 1,
> + REG_A8XX_UCHE_CLIENT_PF,
> + REG_A8XX_VSC_BIN_SIZE,
> + REG_A8XX_RB_CMP_NC_MODE_CNTL,
> + REG_A7XX_SP_HLSQ_TIMEOUT_THRESHOLD_DP,
> + REG_A8XX_SP_HLSQ_GC_GMEM_RANGE_MIN,
> + REG_A8XX_SP_HLSQ_GC_GMEM_RANGE_MIN + 1,
> + REG_A7XX_SP_READ_SEL,
GEN8_UCHE_CCHE_TRAP_BASE_LO
GEN8_UCHE_CCHE_TRAP_BASE_HI
GEN8_UCHE_CCHE_WRITE_THRU_BASE_LO
GEN8_UCHE_CCHE_WRITE_THRU_BASE_HI
We need to include these here.
> +};
> +DECLARE_ADRENO_REGLIST_LIST(a810_pwrup_reglist);
> +
> +static const u32 a810_ifpc_reglist_regs[] = {
> + REG_A8XX_RBBM_NC_MODE_CNTL,
> + REG_A8XX_RBBM_SLICE_INTERFACE_HANG_INT_CNTL,
> + REG_A8XX_RBBM_SLICE_NC_MODE_CNTL,
> + REG_A6XX_SP_NC_MODE_CNTL,
> + REG_A7XX_SP_CHICKEN_BITS_2,
> + REG_A7XX_SP_CHICKEN_BITS_3,
> + REG_A6XX_SP_PERFCTR_SHADER_MASK,
> + REG_A6XX_TPL1_NC_MODE_CNTL,
> + REG_A6XX_TPL1_DBG_ECO_CNTL,
> + REG_A6XX_TPL1_DBG_ECO_CNTL1,
> + REG_A8XX_RBBM_PERFCTR_CNTL,
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(1),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(2),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(3),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(4),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(5),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(6),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(7),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(8),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(9),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(10),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(11),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(12),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(13),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(14),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(15),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(16),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(17),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(18),
> + REG_A8XX_TPL1_BICUBIC_WEIGHTS_TABLE(19),
TPL1 registers should be in pwrup_reglist as the latest code.
> + REG_A8XX_CP_PROTECT_GLOBAL(0),
> + REG_A8XX_CP_PROTECT_GLOBAL(1),
> + REG_A8XX_CP_PROTECT_GLOBAL(2),
> + REG_A8XX_CP_PROTECT_GLOBAL(3),
> + REG_A8XX_CP_PROTECT_GLOBAL(4),
> + REG_A8XX_CP_PROTECT_GLOBAL(5),
> + REG_A8XX_CP_PROTECT_GLOBAL(6),
> + REG_A8XX_CP_PROTECT_GLOBAL(7),
> + REG_A8XX_CP_PROTECT_GLOBAL(8),
> + REG_A8XX_CP_PROTECT_GLOBAL(9),
> + REG_A8XX_CP_PROTECT_GLOBAL(10),
> + REG_A8XX_CP_PROTECT_GLOBAL(11),
> + REG_A8XX_CP_PROTECT_GLOBAL(12),
> + REG_A8XX_CP_PROTECT_GLOBAL(13),
> + REG_A8XX_CP_PROTECT_GLOBAL(14),
> + REG_A8XX_CP_PROTECT_GLOBAL(15),
> + REG_A8XX_CP_PROTECT_GLOBAL(16),
> + REG_A8XX_CP_PROTECT_GLOBAL(17),
> + REG_A8XX_CP_PROTECT_GLOBAL(18),
> + REG_A8XX_CP_PROTECT_GLOBAL(19),
> + REG_A8XX_CP_PROTECT_GLOBAL(20),
> + REG_A8XX_CP_PROTECT_GLOBAL(21),
> + REG_A8XX_CP_PROTECT_GLOBAL(22),
> + REG_A8XX_CP_PROTECT_GLOBAL(23),
> + REG_A8XX_CP_PROTECT_GLOBAL(24),
> + REG_A8XX_CP_PROTECT_GLOBAL(25),
> + REG_A8XX_CP_PROTECT_GLOBAL(26),
> + REG_A8XX_CP_PROTECT_GLOBAL(27),
> + REG_A8XX_CP_PROTECT_GLOBAL(28),
> + REG_A8XX_CP_PROTECT_GLOBAL(29),
> + REG_A8XX_CP_PROTECT_GLOBAL(30),
> + REG_A8XX_CP_PROTECT_GLOBAL(31),
> + REG_A8XX_CP_PROTECT_GLOBAL(32),
> + REG_A8XX_CP_PROTECT_GLOBAL(33),
> + REG_A8XX_CP_PROTECT_GLOBAL(34),
> + REG_A8XX_CP_PROTECT_GLOBAL(35),
> + REG_A8XX_CP_PROTECT_GLOBAL(36),
> + REG_A8XX_CP_PROTECT_GLOBAL(37),
> + REG_A8XX_CP_PROTECT_GLOBAL(38),
> + REG_A8XX_CP_PROTECT_GLOBAL(39),
> + REG_A8XX_CP_PROTECT_GLOBAL(40),
> + REG_A8XX_CP_PROTECT_GLOBAL(41),
> + REG_A8XX_CP_PROTECT_GLOBAL(42),
> + REG_A8XX_CP_PROTECT_GLOBAL(43),
> + REG_A8XX_CP_PROTECT_GLOBAL(44),
> + REG_A8XX_CP_PROTECT_GLOBAL(45),
> + REG_A8XX_CP_PROTECT_GLOBAL(63),
nit: Better to include all protect registers here.
-Akhil
> +};
> +DECLARE_ADRENO_REGLIST_LIST(a810_ifpc_reglist);
> +
> +static const struct adreno_reglist_pipe a810_dyn_pwrup_reglist_regs[] = {
> + { REG_A8XX_CP_PROTECT_CNTL_PIPE, 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> + { REG_A8XX_CP_PROTECT_PIPE(15), 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> + { REG_A8XX_GRAS_TSEFE_DBG_ECO_CNTL, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_GRAS_NC_MODE_CNTL, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_GRAS_DBG_ECO_CNTL, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A7XX_RB_CCU_CNTL, 0, BIT(PIPE_BR) },
> + { REG_A8XX_RB_CCU_NC_MODE_CNTL, 0, BIT(PIPE_BR) },
> + { REG_A8XX_RB_CMP_NC_MODE_CNTL, 0, BIT(PIPE_BR) },
> + { REG_A8XX_RB_RESOLVE_PREFETCH_CNTL, 0, BIT(PIPE_BR) },
> + { REG_A8XX_RB_CMP_DBG_ECO_CNTL, 0, BIT(PIPE_BR) },
> + { REG_A8XX_RB_GC_GMEM_PROTECT, 0, BIT(PIPE_BR) },
> + { REG_A6XX_RB_CONTEXT_SWITCH_GMEM_SAVE_RESTORE_ENABLE, 0, BIT(PIPE_BR) },
> + { REG_A8XX_VPC_FLATSHADE_MODE_CNTL, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_1, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_2, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_3, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_PC_CHICKEN_BITS_4, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A6XX_PC_AUTO_VERTEX_STRIDE, 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> + { REG_A8XX_PC_VIS_STREAM_CNTL, 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> + { REG_A8XX_PC_CONTEXT_SWITCH_STABILIZE_CNTL_1, 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> + { REG_A8XX_VFD_CB_BV_THRESHOLD, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_BR_THRESHOLD, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_BUSY_REQ_CNT, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A8XX_VFD_CB_LP_REQ_CNT, 0, BIT(PIPE_BV) | BIT(PIPE_BR) },
> + { REG_A7XX_VFD_DBG_ECO_CNTL, 0, BIT(PIPE_BR) | BIT(PIPE_BV) },
> +};
> +DECLARE_ADRENO_REGLIST_PIPE_LIST(a810_dyn_pwrup_reglist);
> +
> static const struct adreno_reglist_pipe a840_nonctxt_regs[] = {
> { REG_A8XX_CP_SMMU_STREAM_ID_LPAC, 0x00000101, BIT(PIPE_NONE) },
> { REG_A8XX_GRAS_DBG_ECO_CNTL, 0x00000800, BIT(PIPE_BV) | BIT(PIPE_BR) },
> @@ -2193,6 +2427,43 @@ static const struct adreno_info a8xx_gpus[] = {
> { 252, 2 },
> { 221, 3 },
> ),
> + }, {
> + .chip_ids = ADRENO_CHIP_IDS(0x44010000),
> + .family = ADRENO_8XX_GEN1,
> + .fw = {
> + [ADRENO_FW_SQE] = "gen80300_sqe.fw",
> + [ADRENO_FW_GMU] = "gen80300_gmu.bin",
> + },
> + .gmem = SZ_512K + SZ_64K,
> + .inactive_period = DRM_MSM_INACTIVE_PERIOD,
> + .quirks = ADRENO_QUIRK_HAS_CACHED_COHERENT |
> + ADRENO_QUIRK_HAS_HW_APRIV |
> + ADRENO_QUIRK_PREEMPTION |
> + ADRENO_QUIRK_IFPC,
> + .funcs = &a8xx_gpu_funcs,
> + .zapfw = "gen80300_zap.mbn",
> + .a6xx = &(const struct a6xx_info) {
> + .protect = &a810_protect,
> + .nonctxt_reglist = a810_nonctxt_regs,
> + .pwrup_reglist = &a810_pwrup_reglist,
> + .dyn_pwrup_reglist = &a810_dyn_pwrup_reglist,
> + .ifpc_reglist = &a810_ifpc_reglist,
> + .gbif_cx = a840_gbif,
> + .max_slices = 1,
> + .gmu_chipid = 0x8030000,
> + .bcms = (const struct a6xx_bcm[]) {
> + { .name = "SH0", .buswidth = 16 },
> + { .name = "MC0", .buswidth = 4 },
> + {
> + .name = "ACV",
> + .fixed = true,
> + .perfmode = BIT(2),
> + .perfmode_bw = 10687500,
> + },
> + { /* sentinel */ },
> + },
> + },
> + .preempt_record_size = 4558 * SZ_1K,
> }
> };
>
> diff --git a/drivers/gpu/drm/msm/adreno/adreno_gpu.h b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> index c0ee544ce257..d474d88b9152 100644
> --- a/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> +++ b/drivers/gpu/drm/msm/adreno/adreno_gpu.h
> @@ -596,6 +596,11 @@ static inline int adreno_is_a8xx(struct adreno_gpu *gpu)
> return gpu->info->family >= ADRENO_8XX_GEN1;
> }
>
> +static inline int adreno_is_a810(struct adreno_gpu *gpu)
> +{
> + return gpu->info->chip_ids[0] == 0x44010000;
> +}
> +
> static inline int adreno_is_x285(struct adreno_gpu *gpu)
> {
> return gpu->info->chip_ids[0] == 0x44070001;
>
^ permalink raw reply
* Re: [PATCH v3 1/4] ARM: dts: qcom: msm8960: expressatt: Sort node references and includes
From: Krzysztof Kozlowski @ 2026-04-07 21:04 UTC (permalink / raw)
To: Rudraksha Gupta, Bjorn Andersson, Konrad Dybcio, Rob Herring,
Krzysztof Kozlowski, Conor Dooley
Cc: linux-arm-msm, devicetree, linux-kernel
In-Reply-To: <b8b04f36-2f4d-4d0e-b0af-a01d129a5199@gmail.com>
On 07/04/2026 22:39, Rudraksha Gupta wrote:
>
> On 4/7/26 12:59, Krzysztof Kozlowski wrote:
>> On 01/04/2026 22:32, Rudraksha Gupta via B4 Relay wrote:
>>> From: Rudraksha Gupta <guptarud@gmail.com>
>>>
>>> Reorganize the DTS file for consistency with other msm8960 board files.
>>>
>>> Assisted-by: Claude:claude-opus-4.6
>>> Signed-off-by: Rudraksha Gupta <guptarud@gmail.com>
>>> ---
>>> .../dts/qcom/qcom-msm8960-samsung-expressatt.dts | 408 +++++++++++----------
>>> 1 file changed, 207 insertions(+), 201 deletions(-)
>>>
>> Sorry, but no. We are not taking Claude as one determining coding style.
>> Are we going to do the work again the moment we come with proper tool?
>
> There is no tool currently to auto format DTS, and doesn't seem to be
> coming for a while:
>
> https://www.youtube.com/watch?v=cvoIbTL_ZQA
>
>
> Claude didn't determine the coding style. I did based on sony-huashan,
> which is already upstream:
>
> https://github.com/torvalds/linux/blob/master/arch/arm/boot/dts/qcom/qcom-msm8960-sony-huashan.dts
>
>
> I just used Claude to do the manual work for me. In v2, I made sure the
> diff before and after the change was nill. v3 included additional
> changes requested by Konrad and some comments that I remembered during
> prior attempts mainlining patch series for this device.
IMO, it is just too risky to let Claude reorganize the nodes, but I
assume reviewers of your code did run dtx_diff.
If they did not, then it is on them :(
Best regards,
Krzysztof
^ permalink raw reply
* [PATCH v5 2/6] clk: fsl-sai: Sort the headers
From: Marek Vasut @ 2026-04-07 21:09 UTC (permalink / raw)
To: linux-clk
Cc: Marek Vasut, Brian Masney, Conor Dooley, Krzysztof Kozlowski,
Michael Turquette, Michael Walle, Rob Herring, Stephen Boyd,
devicetree, linux-kernel
In-Reply-To: <20260407211123.77602-1-marex@nabladev.com>
Sort the headers. No functional change.
Reviewed-by: Brian Masney <bmasney@redhat.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Brian Masney <bmasney@redhat.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
V4: New patch
V5: - Reorder this into 2/6 position
- Add RB from Brian
---
drivers/clk/clk-fsl-sai.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
index cba45e07562da..c59ddd519f9f5 100644
--- a/drivers/clk/clk-fsl-sai.c
+++ b/drivers/clk/clk-fsl-sai.c
@@ -5,12 +5,12 @@
* Copyright 2020 Michael Walle <michael@walle.cc>
*/
-#include <linux/module.h>
-#include <linux/platform_device.h>
#include <linux/clk-provider.h>
#include <linux/err.h>
+#include <linux/module.h>
#include <linux/of.h>
#include <linux/of_address.h>
+#include <linux/platform_device.h>
#include <linux/slab.h>
#define I2S_CSR 0x00
--
2.53.0
^ permalink raw reply related
* [PATCH v5 1/6] dt-bindings: clock: fsl-sai: Document i.MX8M support
From: Marek Vasut @ 2026-04-07 21:09 UTC (permalink / raw)
To: linux-clk
Cc: Marek Vasut, Conor Dooley, Brian Masney, Conor Dooley,
Krzysztof Kozlowski, Michael Turquette, Michael Walle,
Rob Herring, Stephen Boyd, devicetree, linux-kernel
The i.MX8M/Mini/Nano/Plus variant of the SAI IP has control registers
shifted by +8 bytes and requires additional bus clock. Document support
for the i.MX8M variant of the IP with this register shift and additional
clock. Update the description slightly.
Acked-by: Conor Dooley <conor.dooley@microchip.com>
Signed-off-by: Marek Vasut <marex@nabladev.com>
---
Cc: Brian Masney <bmasney@redhat.com>
Cc: Conor Dooley <conor+dt@kernel.org>
Cc: Krzysztof Kozlowski <krzk+dt@kernel.org>
Cc: Michael Turquette <mturquette@baylibre.com>
Cc: Michael Walle <michael@walle.cc>
Cc: Rob Herring <robh@kernel.org>
Cc: Stephen Boyd <sboyd@kernel.org>
Cc: devicetree@vger.kernel.org
Cc: linux-clk@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
V2: No change
V3: - Rebase on current next, update mail address
- Pick ancient AB from Conor, although this may be outdated
https://patchwork.kernel.org/project/alsa-devel/patch/20241226162234.40141-1-marex@denx.de/
- Invert the allOf conditional to match on VF610 and limit
the clocks/clock-names there. MX8M can have one or two
input clock, "bus" is mandatory and "mclk1" is optional.
The "mclk1" are used by the driver in 4/4 .
V4: No change
V5: No change
---
.../bindings/clock/fsl,sai-clock.yaml | 41 ++++++++++++++++---
1 file changed, 35 insertions(+), 6 deletions(-)
diff --git a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
index 3bca9d11c148f..90799b3b505ee 100644
--- a/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
+++ b/Documentation/devicetree/bindings/clock/fsl,sai-clock.yaml
@@ -10,10 +10,10 @@ maintainers:
- Michael Walle <michael@walle.cc>
description: |
- It is possible to use the BCLK pin of a SAI module as a generic clock
- output. Some SoC are very constrained in their pin multiplexer
- configuration. Eg. pins can only be changed groups. For example, on the
- LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
+ It is possible to use the BCLK pin of a SAI module as a generic
+ clock output. Some SoC are very constrained in their pin multiplexer
+ configuration. E.g. pins can only be changed in groups. For example, on
+ the LS1028A SoC you can only enable SAIs in pairs. If you use only one SAI,
the second pins are wasted. Using this binding it is possible to use the
clock of the second SAI as a MCLK clock for an audio codec, for example.
@@ -21,17 +21,46 @@ description: |
properties:
compatible:
- const: fsl,vf610-sai-clock
+ oneOf:
+ - items:
+ - enum:
+ - fsl,imx8mm-sai-clock
+ - fsl,imx8mn-sai-clock
+ - fsl,imx8mp-sai-clock
+ - const: fsl,imx8mq-sai-clock
+ - items:
+ - enum:
+ - fsl,imx8mq-sai-clock
+ - fsl,vf610-sai-clock
reg:
maxItems: 1
clocks:
- maxItems: 1
+ minItems: 1
+ maxItems: 2
+
+ clock-names:
+ minItems: 1
+ items:
+ - const: bus
+ - const: mclk1
'#clock-cells':
const: 0
+allOf:
+ - if:
+ properties:
+ compatible:
+ contains:
+ const: fsl,vf610-sai-clock
+ then:
+ properties:
+ clocks:
+ maxItems: 1
+ clock-names: false
+
required:
- compatible
- reg
--
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