[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJM55Z_jp7ZGUcV=4Ciq0ZMPbrf_YARpSDwWgxBa9OjbYzhiFw@mail.gmail.com>
Date: Wed, 23 Oct 2024 12:49:28 -0400
From: Emil Renner Berthing <emil.renner.berthing@...onical.com>
To: Conor Dooley <conor@...nel.org>, Alex Elder <elder@...cstar.com>
Cc: Krzysztof Kozlowski <krzk@...nel.org>, Guodong Xu <guodong@...cstar.com>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>, Emil Renner Berthing <kernel@...il.dk>, rafal@...ecki.pl,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Paul Walmsley <paul.walmsley@...ive.com>,
Palmer Dabbelt <palmer@...belt.com>, Albert Ou <aou@...s.berkeley.edu>,
Neil Armstrong <neil.armstrong@...aro.org>, Heiko Stuebner <heiko.stuebner@...rry.de>,
Michael Zhu <michael.zhu@...rfivetech.com>, Drew Fustini <drew@...gleboard.org>,
Alexandru Stan <ams@...me.work>, Daniel Schaefer <dhs@...me.work>,
Sandie Cao <sandie.cao@...pcomputing.io>, Yuning Liang <yuning.liang@...pcomputing.io>,
Huiming Qiu <huiming.qiu@...pcomputing.io>, linux@...me.work, devicetree@...r.kernel.org,
linux-riscv@...ts.infradead.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v5 3/3] riscv: dts: starfive: add DeepComputing FML13V01
board device tree
Conor Dooley wrote:
> On Mon, Oct 21, 2024 at 08:44:16AM -0500, Alex Elder wrote:
> > On 10/21/24 7:47 AM, Krzysztof Kozlowski wrote:
> > > On 21/10/2024 13:16, Conor Dooley wrote:
> > > > On Mon, Oct 21, 2024 at 09:17:59AM +0200, Krzysztof Kozlowski wrote:
> > > > > On Sun, Oct 20, 2024 at 09:49:59PM +0800, Guodong Xu wrote:
> > > > > > From: Sandie Cao <sandie.cao@...pcomputing.io>
> > > > > > +&camss {
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > +&csi2rx {
> > > > > > + status = "disabled";
> > > > > > +};
> > > >
> > > > You can drop these two, I marked them disabled in the common file
> > > > earlier this week.
> > > > 1
> > > > > > +
> > > > > > +&gmac0 {
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > +&i2c0 {
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > +&pwm {
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > +&pwmdac {
> > > > > > + status = "disabled";
> > > > > > +};
> > > > > > +
> > > > > > +&spi0 {
> > > > > > + status = "disabled";
> > > > >
> > > > > If your board has to disable all these, then they should not have been
> > > > > enabled in DTSI in the first place. Only blocks present and working in
> > > > > the SoC (without amny external needs) should be enabled.
> > > > >
> > > > > I suggest to fix that aspect first.
> > > >
> > > > Eh, I don't think I agree. Having 5 disables here is a lesser evil than
> > > > reproducing 90% of jh7110-common.dtsi or shunting a bunch of stuff
> > > > around. Emil?
> > >
> > > Why reproducing 90%? Only enable would be here, no? Or you want to say
> > > the common DTSI has things which do not exist?
> >
> > For what it's worth, I agree with Krzysztof. In the (long) cover
> > page we pointed this out, and offered to do it in a followup patch.
> > But if requested we can do it now.
> >
> > So in v6, a new patch would be inserted before the other three,
> > and it would:
> > - Remove the status = "okay" lines for those nodes that are not enabled
> > in this new platform, in "jh7110-common.dtsi"
> > - Add nodes where appropriate in:
> > jh7110-milkv-mars.dts
> > jh7110-pine64-star64.dts
> > jh7110-starfive-visionfive-2.dtsi
> > They'll look like this, to enable the ones disabled above, e.g.:
> > &gmac0 {
> > status = "okay";
> > };
> >
> > &i2c0 {
> > status = "okay";
> > };
> >
> > You guys should come to agreement, but I do think what Krzysztof says
> > is the right approach. And unless convinced otherwise, this will be
> > what shows up in the next version of this series.
>
> Ultimately, it is up to Emil how he wants these laid out.
Thanks, but I agree. Please begin with a patch moving the nodes that are no
longer common out of jh7110-common.dtsi and into the vf2, mars and pine64
consumers. You should probably do the same with the &usb0 node instead
of overriding the dr_mode property.
/Emil
Powered by blists - more mailing lists