On 29/12/2022 12:04, Konrad Dybcio wrote:
>
>
> On 29.12.2022 11:57, Krzysztof Kozlowski wrote:
>> On 29/12/2022 11:45, Konrad Dybcio wrote:
>>>
>>>
>>> On 29.12.2022 11:42, Krzysztof Kozlowski wrote:
>>>> On 29/12/2022 11:32, Konrad Dybcio wrote:
>>>>> From: Vinod Koul <vkoul@xxxxxxxxxx>
>>>>>
>>>>> Add the spmi bus as found in the SM8450 SoC
>>>>>
>>>>> Signed-off-by: Vinod Koul <vkoul@xxxxxxxxxx>
>>>>> Reviewed-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxxxxxx>
>>>>> [Konrad: 0x0 -> 0, move #cells down, make reg-names a vertical list]
>>>>> Signed-off-by: Konrad Dybcio <konrad.dybcio@xxxxxxxxxx>
>>>>> ---
>>>>> v1 -> v2:
>>>>> No changes
>>>>>
>>>>> arch/arm64/boot/dts/qcom/sm8450.dtsi | 22 ++++++++++++++++++++++
>>>>> 1 file changed, 22 insertions(+)
>>>>>
>>>>> diff --git a/arch/arm64/boot/dts/qcom/sm8450.dtsi b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> index 570475040d95..b9b59c5223eb 100644
>>>>> --- a/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> +++ b/arch/arm64/boot/dts/qcom/sm8450.dtsi
>>>>> @@ -2715,6 +2715,28 @@ aoss_qmp: power-controller@c300000 {
>>>>> #clock-cells = <0>;
>>>>> };
>>>>>
>>>>> + spmi_bus: spmi@c42d000 {
>>>>
>>>> Hmm looks different than reg.
>>>>
>>>>> + compatible = "qcom,spmi-pmic-arb";
>>>>> + reg = <0 0x0c400000 0 0x00003000>,
>>>>> + <0 0x0c500000 0 0x00400000>,
>>>>> + <0 0x0c440000 0 0x00080000>,
>>>>> + <0 0x0c4c0000 0 0x00010000>,
>>>>> + <0 0x0c42d000 0 0x00010000>;
>>>> x
>>> Hm, my guess would be that Vinod chose to put the "cnfg" reg
>>> instead of "core" in the unit address, as 8450 has 2 SPMI bus
>>> hosts and they both share the core reg, so it would have been
>>> impossible to have two spmi@core nodes..
>>
>> Eh? SM8450 has 2 SPMI hosts both using 0x0c400000? How does that work?
>> Usually address can be mapped only once.
> No idea either!
>
>>
>> Where is the second SPMI? I cannot find it in linux-next.
> It's only there on downstream and I'm not sure how useful it is
> really, only some debug subdevice is attached to it.. Perhaps
> we could ignore its existence for now and I could use the core
> reg in unit address for spmi0?
I see it indeed in downstream. core, chnls and obsrvr IO are the same.
There is quite of debug devices attached.
There is a comment in PMIC arbiter code to use a IO mapping allowing
simultaneous mappings, so this is actually valid.
Anyway, DT expects unit address to match first reg, so if we want to
have second PMIC, we need to change the order of reg entries.
We can ignore this problem till we add second PMIC...
Best regards,
Krzysztof
