Devicetree
 help / color / mirror / Atom feed
* Re: [PATCH v6 2/3] dt-bindings: fpga: Add Efinix SPI programming bindings
From: Rob Herring (Arm) @ 2026-04-07 18:49 UTC (permalink / raw)
  To: iansdannapel
  Cc: linux-fpga, devicetree, conor+dt, prabhakar.mahadev-lad.rj, heiko,
	krzk+dt, marex, dev, linux-kernel, neil.armstrong, yilun.xu, mdf,
	trix
In-Reply-To: <20260327114842.1300284-3-iansdannapel@gmail.com>


On Fri, 27 Mar 2026 12:48:40 +0100, iansdannapel@gmail.com wrote:
> From: Ian Dannapel <iansdannapel@gmail.com>
> 
> Add device tree bindings documentation for configuring Efinix FPGA
> using serial SPI passive programming mode.
> 
> Signed-off-by: Ian Dannapel <iansdannapel@gmail.com>
> ---
>  .../bindings/fpga/efinix,trion-config.yaml    | 96 +++++++++++++++++++
>  1 file changed, 96 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/fpga/efinix,trion-config.yaml
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH] dt-bindings: soc: qcom,aoss-qmp: Document the Eliza Always-On Subsystem side channel
From: Rob Herring (Arm) @ 2026-04-07 18:50 UTC (permalink / raw)
  To: Abel Vesa
  Cc: Bjorn Andersson, Konrad Dybcio, devicetree, Conor Dooley,
	linux-kernel, linux-arm-msm, Krzysztof Kozlowski
In-Reply-To: <20260327-eliza-bindings-aoss-v1-1-70df76adc69b@oss.qualcomm.com>


On Fri, 27 Mar 2026 14:46:53 +0200, Abel Vesa wrote:
> Document the Always-On Subsystem (AOSS) side channel found on the Qualcomm
> Eliza SoC. It is used for communication with other clients, like
> remoteprocs.
> 
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/soc/qcom/qcom,aoss-qmp.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH] dt-bindings: soc: qcom: qcom,pmic-glink: Document Eliza compatible
From: Rob Herring (Arm) @ 2026-04-07 18:50 UTC (permalink / raw)
  To: Abel Vesa
  Cc: Bjorn Andersson, linux-arm-msm, Conor Dooley, Krzysztof Kozlowski,
	devicetree, linux-kernel, Konrad Dybcio
In-Reply-To: <20260327-eliza-bindings-pmic-glink-v1-1-f9a65495f599@oss.qualcomm.com>


On Fri, 27 Mar 2026 15:44:13 +0200, Abel Vesa wrote:
> Document the compatible for the PMIC GLINK interface found on the
> Qualcomm Eliza SoC.
> 
> It is fully compatible with the one found on SM8550, so use that as
> fallback.
> 
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/soc/qcom/qcom,pmic-glink.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH] dt-bindings: phy: qcom,snps-eusb2: Document the Eliza Synopsys eUSB2 PHY
From: Rob Herring (Arm) @ 2026-04-07 18:51 UTC (permalink / raw)
  To: Abel Vesa
  Cc: linux-arm-msm, linux-phy, Vinod Koul, linux-kernel, devicetree,
	Conor Dooley, Neil Armstrong, Abel Vesa, Krzysztof Kozlowski
In-Reply-To: <20260327-eliza-bindings-phy-eusb2-v1-1-1f8a9ad6a033@oss.qualcomm.com>


On Fri, 27 Mar 2026 16:14:27 +0200, Abel Vesa wrote:
> The Synopsys eUSB2 PHY found on the Eliza SoC is fully compatible with the
> one found the SM8550.
> 
> So document it by adding the compatible to the list that has the SM8550
> one as fallback.
> 
> Signed-off-by: Abel Vesa <abel.vesa@oss.qualcomm.com>
> ---
>  Documentation/devicetree/bindings/phy/qcom,snps-eusb2-phy.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 5/6] clk: fsl-sai: Extract clock setup into fsl_sai_clk_register()
From: Brian Masney @ 2026-04-07 19:03 UTC (permalink / raw)
  To: Marek Vasut
  Cc: linux-clk, Conor Dooley, Krzysztof Kozlowski, Michael Turquette,
	Michael Walle, Rob Herring, Stephen Boyd, devicetree,
	linux-kernel
In-Reply-To: <20260406215150.176599-5-marex@nabladev.com>

Hi Marek,

On Mon, Apr 06, 2026 at 11:49:45PM +0200, Marek Vasut wrote:
> Create helper function fsl_sai_clk_register() to set up and register
> SAI clock. Rename BCLK specific struct fsl_sai_clk members with bclk_
> prefix. Use of_node_full_name(dev->of_node) and clock name to register
> uniquely named clock. This is done in preparation for the follow up
> patch, which adds MCLK support.
> 
> 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
> ---
>  drivers/clk/clk-fsl-sai.c | 78 ++++++++++++++++++++++++++-------------
>  1 file changed, 53 insertions(+), 25 deletions(-)
> 
> diff --git a/drivers/clk/clk-fsl-sai.c b/drivers/clk/clk-fsl-sai.c
> index 2a68e32c3167b..7ec9a4f22735c 100644
> --- a/drivers/clk/clk-fsl-sai.c
> +++ b/drivers/clk/clk-fsl-sai.c
> @@ -21,8 +21,9 @@
>  #define CR2_DIV_WIDTH	8
>  
>  struct fsl_sai_clk {
> -	struct clk_divider div;
> -	struct clk_gate gate;
> +	struct clk_divider bclk_div;
> +	struct clk_gate bclk_gate;
> +	struct clk_hw *bclk_hw;
>  	spinlock_t lock;
>  };
>  
> @@ -30,15 +31,57 @@ struct fsl_sai_data {
>  	unsigned int	offset;	/* Register offset */
>  };
>  
> +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?

> +
> +	return 0;
> +}
> +
>  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;
> +	int ret;
>  
>  	sai_clk = devm_kzalloc(dev, sizeof(*sai_clk), GFP_KERNEL);
>  	if (!sai_clk)
> @@ -54,27 +97,12 @@ static int fsl_sai_clk_probe(struct platform_device *pdev)
>  
>  	spin_lock_init(&sai_clk->lock);
>  
> -	sai_clk->gate.reg = base + data->offset + I2S_CSR;
> -	sai_clk->gate.bit_idx = CSR_BCE_BIT;
> -	sai_clk->gate.lock = &sai_clk->lock;
> -
> -	sai_clk->div.reg = base + data->offset + I2S_CR2;
> -	sai_clk->div.shift = CR2_DIV_SHIFT;
> -	sai_clk->div.width = CR2_DIV_WIDTH;
> -	sai_clk->div.lock = &sai_clk->lock;
> -
> -	/* set clock direction, we are the BCLK master */
> -	writel(CR2_BCD, base + data->offset + I2S_CR2);
> -
> -	hw = devm_clk_hw_register_composite_pdata(dev, dev->of_node->name,
> -						  &pdata, 1, NULL, NULL,
> -						  &sai_clk->div.hw,
> -						  &clk_divider_ops,
> -						  &sai_clk->gate.hw,
> -						  &clk_gate_ops,
> -						  CLK_SET_RATE_GATE);
> -	if (IS_ERR(hw))
> -		return PTR_ERR(hw);
> +	ret = fsl_sai_clk_register(dev, base, &sai_clk->lock,
> +				   &sai_clk->bclk_div, &sai_clk->bclk_gate,
> +				   &sai_clk->bclk_hw, CSR_BCE_BIT, CR2_BCD,
> +				   data->offset + I2S_CR2, "BCLK");
> +	if (ret)
> +		return ret;
>  
>  	return devm_of_clk_add_hw_provider(dev, of_clk_hw_simple_get, hw);
                                                                      ^^^
hw is removed above, and it's still here in this patch. It's removed in
the last patch. This will break git bisect.

Brian


^ permalink raw reply

* Re: [PATCH v2 1/9] dt-bindings: display: msm-dsi-phy-7nm: document the Milos DSI PHY
From: Rob Herring (Arm) @ 2026-04-07 19:06 UTC (permalink / raw)
  To: Luca Weiss
  Cc: freedreno, Alexander Koskovich, Conor Dooley, Maxime Ripard,
	Maarten Lankhorst, linux-kernel, Sean Paul, Abhinav Kumar,
	David Airlie, Jessica Zhang, Thomas Zimmermann, Rob Clark,
	phone-devel, Dmitry Baryshkov, Marijn Suijten, dri-devel,
	~postmarketos/upstreaming, devicetree, Jonathan Marek,
	Neil Armstrong, Krzysztof Kozlowski, Bjorn Andersson,
	linux-arm-msm, Simona Vetter, Krishna Manikandan, Konrad Dybcio
In-Reply-To: <20260327-milos-mdss-v2-1-bc586683f5ca@fairphone.com>


On Fri, 27 Mar 2026 17:12:20 +0100, Luca Weiss wrote:
> Document the DSI PHY on the Milos Platform.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
>  Documentation/devicetree/bindings/display/msm/dsi-phy-7nm.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v2 2/9] dt-bindings: display: msm-dsi-controller-main: document the Milos DSI Controller
From: Rob Herring (Arm) @ 2026-04-07 19:06 UTC (permalink / raw)
  To: Luca Weiss
  Cc: Maxime Ripard, Thomas Zimmermann, Rob Clark, Jessica Zhang,
	linux-arm-msm, devicetree, dri-devel, freedreno,
	Maarten Lankhorst, phone-devel, Simona Vetter, David Airlie,
	Neil Armstrong, ~postmarketos/upstreaming, Conor Dooley,
	Marijn Suijten, Sean Paul, Konrad Dybcio, Bjorn Andersson,
	Krzysztof Kozlowski, linux-kernel, Jonathan Marek,
	Krishna Manikandan, Abhinav Kumar, Dmitry Baryshkov,
	Alexander Koskovich
In-Reply-To: <20260327-milos-mdss-v2-2-bc586683f5ca@fairphone.com>


On Fri, 27 Mar 2026 17:12:21 +0100, Luca Weiss wrote:
> Document the DSI Controller on the Milos Platform.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
>  Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v2 3/9] dt-bindings: display: msm: document the Milos DPU
From: Rob Herring (Arm) @ 2026-04-07 19:07 UTC (permalink / raw)
  To: Luca Weiss
  Cc: Thomas Zimmermann, Sean Paul, Marijn Suijten, Alexander Koskovich,
	Maarten Lankhorst, David Airlie, devicetree, Krzysztof Kozlowski,
	Krishna Manikandan, Konrad Dybcio, ~postmarketos/upstreaming,
	Rob Clark, linux-kernel, Neil Armstrong, Bjorn Andersson,
	Abhinav Kumar, Dmitry Baryshkov, Conor Dooley, Jonathan Marek,
	phone-devel, Jessica Zhang, freedreno, Simona Vetter, dri-devel,
	Maxime Ripard, linux-arm-msm
In-Reply-To: <20260327-milos-mdss-v2-3-bc586683f5ca@fairphone.com>


On Fri, 27 Mar 2026 17:12:22 +0100, Luca Weiss wrote:
> Document the DPU Display Controller on the Milos Platform.
> 
> Signed-off-by: Luca Weiss <luca.weiss@fairphone.com>
> ---
>  Documentation/devicetree/bindings/display/msm/qcom,sm8650-dpu.yaml | 1 +
>  1 file changed, 1 insertion(+)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 2/5] dt-bindings: usb: generic-ohci: add AT91RM9200 OHCI binding support
From: Rob Herring (Arm) @ 2026-04-07 19:08 UTC (permalink / raw)
  To: Charan Pedumuru
  Cc: linux-arm-kernel, Conor Dooley, linux-usb, Claudiu Beznea,
	Herve Codina, Krzysztof Kozlowski, Greg Kroah-Hartman,
	linux-kernel, Alexandre Belloni, Nicolas Ferre, devicetree
In-Reply-To: <20260327-atmel-usb-v4-2-eb8b6e49b29d@gmail.com>


On Fri, 27 Mar 2026 16:47:43 +0000, Charan Pedumuru wrote:
> Convert the Atmel AT91RM9200 OHCI USB host controller binding to DT schema
> by defining it in the existing generic OHCI schema.
> 
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
>  .../devicetree/bindings/usb/atmel-usb.txt          | 27 --------------
>  .../devicetree/bindings/usb/generic-ohci.yaml      | 41 ++++++++++++++++++++++
>  2 files changed, 41 insertions(+), 27 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH v4 5/5] dt-bindings: usb: atmel,at91sam9rl-udc: convert to DT schema
From: Rob Herring (Arm) @ 2026-04-07 19:11 UTC (permalink / raw)
  To: Charan Pedumuru
  Cc: Greg Kroah-Hartman, Conor Dooley, Krzysztof Kozlowski,
	linux-arm-kernel, Claudiu Beznea, Nicolas Ferre, Herve Codina,
	devicetree, linux-kernel, linux-usb, Alexandre Belloni
In-Reply-To: <20260327-atmel-usb-v4-5-eb8b6e49b29d@gmail.com>


On Fri, 27 Mar 2026 16:47:46 +0000, Charan Pedumuru wrote:
> Convert Atmel High-Speed USB Device Controller (USBA) binding to DT schema.
> Changes during conversion:
> - Make the "clock-names" property flexible enough to accept the items
>   in any order as the existing in tree DTS nodes doesn't follow an order.
> 
> Signed-off-by: Charan Pedumuru <charan.pedumuru@gmail.com>
> ---
>  .../bindings/usb/atmel,at91sam9rl-udc.yaml         | 74 ++++++++++++++++++++++
>  .../devicetree/bindings/usb/atmel-usb.txt          | 46 --------------
>  2 files changed, 74 insertions(+), 46 deletions(-)
> 

Reviewed-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH RFC 4/4] arm64: dts: qcom: Enable GPU & GMU on Glymur CRD
From: Akhil P Oommen @ 2026-04-07 19:21 UTC (permalink / raw)
  To: Dmitry Baryshkov
  Cc: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
	Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
	Simona Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann, linux-arm-msm, devicetree, linux-kernel,
	dri-devel, freedreno
In-Reply-To: <ui4r3krzvd3i6kjdozhmmueejdqpbnbo5wfa6pwzjolcse3eeg@3u7bdphqv4iz>

On 4/5/2026 3:14 AM, Dmitry Baryshkov wrote:
> On Sun, Apr 05, 2026 at 02:33:17AM +0530, Akhil P Oommen wrote:
>> Enable the necessary DT nodes to add support for GPU on the Glymur CRD.
>> The Glymur CRD boots Linux at EL2, which means it doesn't require the
>> secure GPU firmware (zap fw).
> 
> Is this going to be a default mode for other laptops too? Otherwise it
> might be better to keep ZAP node enabled by default and disable it here.

I believe so. Anyway the laptops are hitting the market right now. If
anyone reports that the EL2 is locked down, we can revisit this.

-Akhil.

> 
>>
>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>> ---
>>  arch/arm64/boot/dts/qcom/glymur-crd.dts | 8 ++++++++
>>  1 file changed, 8 insertions(+)
>>
>> diff --git a/arch/arm64/boot/dts/qcom/glymur-crd.dts b/arch/arm64/boot/dts/qcom/glymur-crd.dts
>> index 51ea23a49b9e..a579df902323 100644
>> --- a/arch/arm64/boot/dts/qcom/glymur-crd.dts
>> +++ b/arch/arm64/boot/dts/qcom/glymur-crd.dts
>> @@ -110,6 +110,14 @@ vreg_misc_3p3: regulator-misc-3p3 {
>>  	};
>>  };
>>  
>> +&gpu {
>> +	status = "okay";
>> +};
>> +
>> +&gmu {
>> +	status = "okay";
>> +};
>> +
>>  &i2c0 {
>>  	clock-frequency = <400000>;
>>  
>>
>> -- 
>> 2.51.0
>>
> 


^ permalink raw reply

* Re: [PATCH 06/11] dt-bindings: timer: renesas,rz-mtu3: remove TCIU8 interrupt
From: Rob Herring (Arm) @ 2026-04-07 19:21 UTC (permalink / raw)
  To: Cosmin Tanislav
  Cc: Stephen Boyd, Philipp Zabel, linux-iio, Krzysztof Kozlowski,
	Biju Das, linux-clk, Conor Dooley, Magnus Damm, Thomas Gleixner,
	linux-renesas-soc, linux-kernel, Geert Uytterhoeven, Lee Jones,
	Michael Turquette, devicetree, Daniel Lezcano
In-Reply-To: <20260327192425.438263-7-cosmin-gabriel.tanislav.xa@renesas.com>


On Fri, 27 Mar 2026 21:24:20 +0200, Cosmin Tanislav wrote:
> Based on the following pages in the User Manuals, the MTU3 block does
> not have a TCIU8 interrupt, only a TCIV8 interrupt, as the row where
> TCIU8 should have been is marked as reserved, and the GIC SPI numbers
> stop at 212.
> 
>  * Page 486, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2UL
>    Rev.1.40 User Manual
>  * Page 363, Table 8.2 Interrupt Mapping (6/13) in the Renesas RZ/Five
>    Rev.1.30 User Manual
>  * Page 528, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/G2L
>    and RZ/G2LC Rev.1.50 User Manual
>  * Page 540, Table 8.2 Interrupt mapping (7/13) in the Renesas RZ/V2L
>    Rev.1.50 User Manual
> 
> Remove the TCIU8 interrupt.
> 
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
>  .../devicetree/bindings/timer/renesas,rz-mtu3.yaml         | 7 ++-----
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH 07/11] dt-bindings: timer: renesas,rz-mtu3: move required resets to conditional
From: Rob Herring (Arm) @ 2026-04-07 19:22 UTC (permalink / raw)
  To: Cosmin Tanislav
  Cc: Biju Das, linux-iio, Lee Jones, Magnus Damm, Daniel Lezcano,
	Stephen Boyd, devicetree, Michael Turquette, Geert Uytterhoeven,
	Philipp Zabel, linux-renesas-soc, Thomas Gleixner, linux-clk,
	linux-kernel, Krzysztof Kozlowski, Conor Dooley
In-Reply-To: <20260327192425.438263-8-cosmin-gabriel.tanislav.xa@renesas.com>


On Fri, 27 Mar 2026 21:24:21 +0200, Cosmin Tanislav wrote:
> The Renesas RZ/T2H (R9A09G077) and RZ/N2H (R9A09G087) SoCs do not have a
> reset line for the MTU3 block.
> 
> Prepare for adding support for them by moving the required reset into a
> conditional matching all compatibles except the fallback one.
> 
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
>  .../devicetree/bindings/timer/renesas,rz-mtu3.yaml | 14 +++++++++++++-
>  1 file changed, 13 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring (Arm) <robh@kernel.org>


^ permalink raw reply

* Re: [PATCH RFC 0/4] Devicetree support for Glymur GPU
From: Akhil P Oommen @ 2026-04-07 19:22 UTC (permalink / raw)
  To: Bjorn Andersson, Konrad Dybcio, Rob Herring, Krzysztof Kozlowski,
	Conor Dooley, Rob Clark, Sean Paul, Dmitry Baryshkov,
	Abhinav Kumar, Jessica Zhang, Marijn Suijten, David Airlie,
	Simona Vetter, Maarten Lankhorst, Maxime Ripard,
	Thomas Zimmermann
  Cc: linux-arm-msm, devicetree, linux-kernel, dri-devel, freedreno,
	Rajendra Nayak, Rajendra Nayak
In-Reply-To: <20260405-glymur-gpu-dt-v1-0-2135eb11c562@oss.qualcomm.com>

On 4/5/2026 2:33 AM, Akhil P Oommen wrote:
> This series adds the necessary Device Tree bits to enable GPU support
> on the Glymur-based CRD devices. The Adreno X2-85 GPU present in Glymur
> chipsets is based on the new Adreno A8x family of GPUs. It features a new
> slice architecture with 4 slices, significantly higher bandwidth
> throughput compared to mobile counterparts, raytracing support, and the
> highest GPU Fmax seen so far on an Adreno GPU (1850 Mhz), among other
> improvements.
> 
> This series includes patches that add GPU SMMU, GPU/GMU support, and a
> patch to enable the GPU/GMU nodes on the CRD. Keen-eyed readers may
> notice that the secure firmware property is missing. This is
> intentional: The Glymur-based laptop platforms generally allow booting
> Linux at EL2 (yay!), which means the zap firmware not required here.
> 
> The series is marked as RFC because an update is required in the
> gxclkctl/drm drivers to properly support the IFPC feature across all A8x
> GPUs. We plan to post a separate series shortly to address this. I prefer
> to merge the DT series after that series is acked, so that we retain the
> flexibility adjust the DT bindings if needed.

Taniya has posted it here:
https://lore.kernel.org/lkml/20260407-gfx-clk-fixes-v1-0-4bb5583a5054@oss.qualcomm.com/

-Akhil

> 
> This series is only compile tested on linux-next. But I have cherry-picked
> and verified the functionality on a downstream tree which is pretty close
> to upstream. Also, there is a dtb-check error for the adreno smmu node. I
> will fix that in the next revision.
> 
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
> Akhil P Oommen (3):
>       dt-bindings: display/msm: gpu: Document Adreno X2-185
>       arm64: dts: qcom: Add GPU support for Glymur
>       arm64: dts: qcom: Enable GPU & GMU on Glymur CRD
> 
> Rajendra Nayak (1):
>       arm64: dts: qcom: glymur: Add GPU smmu node
> 
>  .../devicetree/bindings/display/msm/gpu.yaml       |   1 +
>  arch/arm64/boot/dts/qcom/glymur-crd.dts            |   8 +
>  arch/arm64/boot/dts/qcom/glymur.dtsi               | 234 +++++++++++++++++++++
>  3 files changed, 243 insertions(+)
> ---
> base-commit: 83acad05dee54a5cff0c98dd7962e55d4c6b145a
> change-id: 20260226-glymur-gpu-dt-339e5092606b
> prerequisite-message-id: <20260303-glymur_mmcc_dt_config_v2-v2-0-da9ded08c26f@oss.qualcomm.com>
> prerequisite-patch-id: a1fb5b7ee94995a24f6e96d1d2524e710d3a7e60
> prerequisite-patch-id: 56c830b7718129323b006e492aed9822d7c30079
> 
> Best regards,


^ permalink raw reply

* Re: [PATCH 08/11] dt-bindings: timer: renesas,rz-mtu3: document RZ/{T2H,N2H}
From: Rob Herring @ 2026-04-07 19:24 UTC (permalink / raw)
  To: Cosmin Tanislav
  Cc: Biju Das, Daniel Lezcano, Thomas Gleixner, Krzysztof Kozlowski,
	Conor Dooley, Geert Uytterhoeven, Magnus Damm, Michael Turquette,
	Stephen Boyd, Lee Jones, Philipp Zabel, linux-iio,
	linux-renesas-soc, linux-kernel, devicetree, linux-clk
In-Reply-To: <20260327192425.438263-9-cosmin-gabriel.tanislav.xa@renesas.com>

On Fri, Mar 27, 2026 at 09:24:22PM +0200, Cosmin Tanislav wrote:
> Compared to the previously supported SoCs, the Renesas RZ/T2H and RZ/N2H
> SoCs do not have a reset line.
> 
> Add a new conditional only matching RZ/T2H and RZ/N2H which disables the
> resets property.
> 
> Document RZ/T2H and RZ/N2H, and use the generic compatible as a
> fallback, as functionality is the same.
> 
> Signed-off-by: Cosmin Tanislav <cosmin-gabriel.tanislav.xa@renesas.com>
> ---
>  .../devicetree/bindings/timer/renesas,rz-mtu3.yaml  | 13 +++++++++++++
>  1 file changed, 13 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
> index 4623f6cddaf0..410951ca53f8 100644
> --- a/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
> +++ b/Documentation/devicetree/bindings/timer/renesas,rz-mtu3.yaml
> @@ -112,6 +112,8 @@ properties:
>            - renesas,r9a07g043-mtu3  # RZ/{G2UL,Five}
>            - renesas,r9a07g044-mtu3  # RZ/G2{L,LC}
>            - renesas,r9a07g054-mtu3  # RZ/V2L
> +          - renesas,r9a09g077-mtu3  # RZ/T2H
> +          - renesas,r9a09g087-mtu3  # RZ/N2H
>        - const: renesas,rz-mtu3
>  
>    reg:
> @@ -245,6 +247,17 @@ allOf:
>        required:
>          - resets
>  
> +  - if:
> +      properties:
> +        compatible:
> +          contains:
> +            enum:
> +              - renesas,r9a09g077-mtu3
> +              - renesas,r9a09g087-mtu3

This can just be an 'else' on the prior if/then schema. Really, these 2 
patches can be combined as the motivation for the 1st patch is the 2nd 
patch.

> +    then:
> +      properties:
> +        resets: false
> +
>  additionalProperties: false
>  
>  examples:
> -- 
> 2.53.0
> 

^ permalink raw reply

* Re: [PATCH RFC v2 0/6] Add support for Adreno 810 GPU
From: Akhil P Oommen @ 2026-04-07 19:26 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-0-ce337ca87a9e@pm.me>

On 4/3/2026 4:38 AM, Alexander Koskovich wrote:
> Adreno 810 is present in the Milos SoC and is the first GPU to be released in
> the A8x family.
> 
> Note that the OPP table is limited to 1050MHz to start with as the only Milos
> device I have is limited to that speed in GPU_CC_FREQ_LIMIT_VAL.
> 
> This series is marked as RFC because it depends on a couple other in review
> series, batch 2 for A8x [1] and the GXCLKCTL block for Milos [2].
> 
> There is also currently an issue on Milos with gx_clkctl_gx_gdsc being stuck on
> during runtime PM [3]. The proper fix is to only toggle the GX GDSC during GMU
> recovery, as the firmware manages it in all other cases. This is the same issue
> seen on SM8750 and is being worked on by Qualcomm. Right now I am just working
> around this locally by not collapsing the GX GDSC during runtime suspend.

This fix is posted here:
https://lore.kernel.org/lkml/20260407-gfx-clk-fixes-v1-0-4bb5583a5054@oss.qualcomm.com/

Please mark you series as dependent on this.

-Akhil

> 
> [1]: https://lore.kernel.org/linux-arm-msm/20260327-a8xx-gpu-batch2-v2-0-2b53c38d2101@oss.qualcomm.com
> [2]: https://lore.kernel.org/linux-arm-msm/20260306-milos-gxclkctl-v1-0-00b09ee159a7@fairphone.com
> [3]: https://lore.kernel.org/linux-arm-msm/5409e13e-280c-47b6-a29f-351cb609bc6f@oss.qualcomm.com
> 
> Signed-off-by: Alexander Koskovich <akoskovich@pm.me>
> ---
> Changes in v2:
> - Mark as RFC due to dependency on in-review changes
> - Explain in DTS commit why qcom,kaanapali-gxclkctl.h and not qcom,milos-gxclkctl.h
> - cx_mmio -> cx_misc_mmio
> - Sync a810_nonctxt_regs with GRAPHICS.LA.14.0.r5-03100-lanai.0
> - Link to v1: https://lore.kernel.org/r/20260331-adreno-810-v1-0-725801dbb12b@pm.me
> 
> ---
> Alexander Koskovich (6):
>       dt-bindings: display/msm/gmu: Document Adreno 810 GMU
>       drm/msm/adreno: rename llc_mmio to cx_misc_mmio
>       drm/msm/adreno: set cx_misc_mmio regardless of if platform has LLCC
>       drm/msm/a8xx: use pipe protect slot 15 for last-span-unbound feature
>       drm/msm/adreno: add Adreno 810 GPU support
>       arm64: dts: qcom: milos: Add Adreno 810 GPU and GMU nodes
> 
>  .../devicetree/bindings/display/msm/gmu.yaml       |  32 +++
>  arch/arm64/boot/dts/qcom/milos.dtsi                | 148 +++++++++++
>  drivers/gpu/drm/msm/adreno/a6xx_catalog.c          | 271 +++++++++++++++++++++
>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c              |   8 +-
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.c              |  44 ++--
>  drivers/gpu/drm/msm/adreno/a6xx_gpu.h              |  14 +-
>  drivers/gpu/drm/msm/adreno/a8xx_gpu.c              |  11 +-
>  drivers/gpu/drm/msm/adreno/adreno_gpu.h            |   5 +
>  8 files changed, 493 insertions(+), 40 deletions(-)
> ---
> base-commit: 128d2eccd20bd74fd104b412d949d869aa48f108
> change-id: 20260330-adreno-810-5a47525522cd
> 
> Best regards,


^ permalink raw reply

* Re: [PATCH 01/16] dt-bindings: clock: Introduce nexus nodes
From: Rob Herring @ 2026-04-07 19:29 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-1-5e6ff7853994@bootlin.com>

On Fri, Mar 27, 2026 at 09:09:23PM +0100, Miquel Raynal (Schneider Electric) wrote:
> Hardware containers can just decouple external resources like clock
> without any more control. Nexus nodes already exist for PWM and GPIOs,
> add a binding to allow them for clocks as well.
> 
> No examples are given, the file is litteraly a copy-paste from Hervé
> Codina's work on PWM Nexus nodes, hence we just point to the examples
> there which already illustrate very clearly the concept of the various
> properties.
> 
> Signed-off-by: Miquel Raynal (Schneider Electric) <miquel.raynal@bootlin.com>
> ---
>  .../bindings/clock/clock-nexus-node.yaml           | 39 ++++++++++++++++++++++
>  1 file changed, 39 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> new file mode 100644
> index 000000000000..f07e2972e8aa
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/clock/clock-nexus-node.yaml
> @@ -0,0 +1,39 @@
> +# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/clock/clock-nexus-node.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Clock Nexus
> +
> +description: >
> +  A nexus node allows to remap a phandle list in a consumer node through a
> +  container or a connector node in a generic way. With this remapping,
> +  the consumer node needs to know only about the nexus node. Resources
> +  behind the nexus node are decoupled by the nexus node itself.
> +
> +maintainers:
> +  - Miquel Raynal <miquel.raynal@bootlin.com>
> +
> +select: true
> +
> +properties:
> +  '#clock-cells': true

No need for this.

> +
> +  clock-map:
> +    $ref: /schemas/types.yaml#/definitions/uint32-matrix
> +
> +  clock-map-mask:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array
> +
> +  clock-map-pass-thru:
> +    $ref: /schemas/types.yaml#/definitions/uint32-array

I think this can be omitted because there aren't common cell definitions 
for clocks like there are for GPIO and PWM.

> +
> +dependentRequired:
> +  clock-map: ['#clock-cells']
> +  clock-map-mask: [ clock-map ]
> +  clock-map-pass-thru: [ clock-map ]
> +
> +additionalProperties: true
> +
> +# See the original pwm-nexus-node.yaml description for examples
> 
> -- 
> 2.51.1
> 

^ permalink raw reply

* 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


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox