[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <666f5917-92d6-4c1d-b172-dc03a38ae46b@oss.qualcomm.com>
Date: Mon, 10 Feb 2025 19:20:01 +0100
From: Konrad Dybcio <konrad.dybcio@....qualcomm.com>
To: neil.armstrong@...aro.org, Konrad Dybcio
<konrad.dybcio@....qualcomm.com>,
Bjorn Andersson <andersson@...nel.org>,
Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>
Cc: linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] arm64: dts: qcom: sm8650: switch to interrupt-cells 4
to add PPI partitions
On 10.02.2025 10:27 AM, Neil Armstrong wrote:
> On 09/02/2025 15:45, Neil Armstrong wrote:
>> On 07/02/2025 21:23, Konrad Dybcio wrote:
>>> On 7.02.2025 11:31 AM, Neil Armstrong wrote:
>>>> The ARM PMUs shares the same per-cpu (PPI) interrupt, so we need to switch
>>>> to interrupt-cells = <4> in the GIC node to allow adding an interrupt
>>>> partition map phandle as the 4th cell value for GIC_PPI interrupts.
>>>>
>>>> Signed-off-by: Neil Armstrong <neil.armstrong@...aro.org>
>>>> ---
>>>
>>> If I'm reading the core right, we can leave the fourth cell
>>> uninitialized where it makes no sense
>>
>> It's not what dtbs_check thinks !
>
> And if you don't specify the 4th cell, dtc is not happy at all:
>
> arch/arm64/boot/dts/qcom/sm8650.dtsi:5302.4-27: Warning (interrupts_property): /soc@...imer@...20000/frame@...2d000:#interrupt-cells: size is (12), expected multiple of 16
> arch/arm64/boot/dts/qcom/sm8650.dtsi:5302.4-27: Warning (interrupts_property): /soc@...sc@...00000:#interrupt-cells: size is (36), expected multiple of 16
> arch/arm64/boot/dts/qcom/sm8650.dtsi:5302.4-27: Warning (interrupts_property): /soc@...mc@...4000:#interrupt-cells: size is (24), expected multiple of 16
> ...
> for a good reason, if you specify 4 cells and you specify multiple interrupts the
> DT code will split the interrupts entry by interrupts-cells + 1.
Right, that's a dumb "feature".. but everyone is kicking down the dtc improvements
can down the road indefinitely
>
> Remember we pass the DT in the DTB format without all the verbosity of DTS,
> the properly is only a bunch of u32 blobs we can extract with the help
> of the -cells properties of the providers.
Which we could/should make dtc autogenerate, eventually
Konrad
Powered by blists - more mailing lists