[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20240917-flypaper-december-3719ea838b3c@squawk>
Date: Tue, 17 Sep 2024 22:13:58 +0100
From: Conor Dooley <conor@...nel.org>
To: Yao Zi <ziyao@...root.org>
Cc: Heiko Stuebner <heiko@...ech.de>, Conor Dooley <conor+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Rob Herring <robh@...nel.org>,
Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>, linux-clk@...r.kernel.org,
linux-arm-kernel@...ts.infradead.org,
linux-rockchip@...ts.infradead.org, linux-kernel@...r.kernel.org,
devicetree@...r.kernel.org
Subject: Re: Possible misleading information in rockchip,rk3588-cru.yaml
On Mon, Sep 16, 2024 at 05:38:56PM +0000, Yao Zi wrote:
> On Mon, Sep 16, 2024 at 05:33:49PM +0100, Conor Dooley wrote:
> > On Wed, Sep 11, 2024 at 09:20:02PM +0000, Yao Zi wrote:
> > > Hi,
> > >
> > > rockchip,rk3588-cru.yaml, dt-binding for RK3588 clock and reset module,
> > > contains description of customized property "rockchip,grf",
> > >
> > > rockchip,grf:
> > > $ref: /schemas/types.yaml#/definitions/phandle
> > > description: >
> > > phandle to the syscon managing the "general register files". It is
> > > used for GRF muxes, if missing any muxes present in the GRF will
> > > not be available.
> > >
> > > But after doing some searching, I found that clk-rk3588.c actually
> > > defines no clock hardware with MUXGRF type. This is also true in in the
> > > vendor code[1], it seems there is actually no GRF mux on RK3588
> > > platform.
> >
> > Have you been able to check the datasheet/register map for this piece of
> > hardware? Does it have a grf register region?
> > Wouldn't be surprised if it didn't, and the cause of it being in the
> > binding was nothing more than copy-paste.
>
> Have checked a public datasheet[1], RK3588 does have corresponding grf
> region and there are only clock related bits in PHP_GRF_CLK_CON1[2].
>
> But these gmac clocks bits are used in dwmac-rk GMAC driver[3]
> internally, out of the common clock driver, rk3588-cru. So I don't think
> the CRU needs access to the grf by design.
That sounds like a reasonable justification for deleting it - but please
check U-Boot etc to make sure that other projects are not using this in
a different manner to the kernel. If they are not using it, then please
send a patch :)
Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)
Powered by blists - more mailing lists