Re: [PATCH 0/2] fdt: translate address if #size-cells = <0>

Tero Kristo
2021-04-07T13:21:32Z

On 07/04/2021 15:52, Rob Herring wrote:
> On Wed, Apr 7, 2021 at 2:07 AM Dario Binacchi <dariobin@libero.it> wrote:
>>
>>
>>> Il 07/04/2021 03:16 Rob Herring <robh+dt@kernel.org> ha scritto:
>>>
>>>
>>> On Tue, Apr 6, 2021 at 5:02 PM Dario Binacchi <dariobin@libero.it> wrote:
>>>>
>>>>
>>>>> Il 06/04/2021 16:06 Rob Herring <robh+dt@kernel.org> ha scritto:
>>>>>
>>>>>
>>>>> On Fri, Apr 2, 2021 at 2:21 PM Dario Binacchi <dariobin@libero.it> wrote:
>>>>>>
>>>>>>
>>>>>> The series comes from my commit in U-boot
>>>>>> d64b9cdcd4 ("fdt: translate address if #size-cells = <0>")
>>>>>> and from the subsequent exchange of emails at the end of which I was
>>>>>> suggested to send the patch to the linux kernel
>>>>>> (https://patchwork.ozlabs.org/project/uboot/patch/1614324949-61314-1-git-send-email-bmeng.cn@gmail.com/).
>>>>>
>>>>> It's 'ranges' that determines translatable which is missing from the
>>>>> DT. This should have not had a 0 size either though maybe we could
>>>>> support that.
>>>>
>>>> I have replied to the email you sent to the u-boot mailing list
>>>>
>>>>>
>>>>> Does the DT have to be updated anyways for your spread spectrum support?
>>>>
>>>> The spread spectrum support patch does not need this patch to work. They belong
>>>> to two different series.
>>>
>>> That's not what I asked. Is the spread spectrum support forcing a DT
>>> update for users?
>>
>> Yes, the deltam and modfreq registers must be added to the DPLL clocks.
>
> That's a shame given this dts has been mostly untouched since 2013.
>

I think technically it would be possible to map these registers within
the driver also, seeing there are like a handful of the DPLLs for both
am3/am4 which are impacted. Just add a new compatible or something, or
alternatively parse the register addresses and populate the
deltam/modfreq registers based on that.

>>> If the DT has to be changed anyways (not really
>>> great policy), then you could fix this in the DT at the same time.
>>
>> I could put the fix to the device tree in that series, although I wouldn't
>> create a single patch to fix and add the SSC registers. First the size-cells = <0>
>> fix patch and then the SSC patch.
>> Do you agree?
>
> By at the same time, I really just meant within 1 release.
>
> But I'd like to hear TI maintainers' thoughts on this.

I did post a comment on patch #1 questioning the approach from TI clock
driver perspective, imho I can't see why these two patches would be
needed right now.

-Tero