On 07/04/2021 15:52, Rob Herring wrote:
On Wed, Apr 7, 2021 at 2:07 AM Dario Binacchi <dariobin@xxxxxxxxx> wrote:
Il 07/04/2021 03:16 Rob Herring <robh+dt@xxxxxxxxxx> ha scritto:
On Tue, Apr 6, 2021 at 5:02 PM Dario Binacchi <dariobin@xxxxxxxxx> wrote:
Il 06/04/2021 16:06 Rob Herring <robh+dt@xxxxxxxxxx> ha scritto:
On Fri, Apr 2, 2021 at 2:21 PM Dario Binacchi <dariobin@xxxxxxxxx> 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@xxxxxxxxx/).
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
