All of lore.kernel.org
 help / color / mirror / Atom feed
From: Wilken Gottwalt <wilken.gottwalt@posteo.net>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog>,
	Bjorn Andersson <andersson@kernel.org>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Chen-Yu Tsai <wens@kernel.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Andre Przywara <andre.przywara@arm.com>,
	Bastian Germann <bage@debian.org>,
	<linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-sunxi@lists.linux.dev>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] riscv: dts: allwinner: d1-t113: Add the hardware spinlock
Date: Fri, 02 Oct 2026 07:48:21 +0000	[thread overview]
Message-ID: <20261002094816.64349979@posteo.net> (raw)
In-Reply-To: <20261002-matted-tux-5b4059bc305a@wendy>

On Fri, 2 Oct 2026 08:32:51 +0100
Conor Dooley <conor.dooley@microchip.com> wrote:

> On Wed, Sep 30, 2026 at 02:05:47PM +0000, Wilken Gottwalt wrote:
> > On Wed, 30 Sep 2026 20:02:21 +0700
> > Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog> wrote:
> > 
> > > Hi Wilken,
> > > 
> > > > Wouldn't it make more sense to add the "allwinner,sun20i-d1-hwspinlock" line to
> > > > the driver in the sun6i_hwspinlock_ids struct, drop
> > > > "allwinner,sun6i-a31-hwspinlock" here in the D1 device tree and update the yaml
> > > > file accordingly?
> > > 
> > > Thanks for looking at it. Bjorn hasn't replied yet, so I looked a bit
> > > more at the naming. I'd like to keep the A31 fallback: it's the usual
> > > pattern, other blocks in this dtsi do the same (timer, I2S, LED
> > > controller), and Conor already acked the binding in 2/3. If Bjorn
> > > prefers a driver entry instead, I'm fine to change it.
> > 
> > Yeah, Conor was a bit quick to act here, such things happen often with patchsets
> > made out of documentation/devicetrees and code. Though, the get clock and resets
> > patch is fine. The driver could use some modernization.
> 
> I dunno, was I too quick to act? The patched looked correct to me, since
> it was using a fallback to a device that it appears to be compatible
> with. Had the series done what you're suggesting, my review feedback
> would have been to tell the Tien to add a fallback.

I'm just not sure how to actually do it right, because so many SoCs include that
feature. That is why I asked how you would do it having more insight as a
subsystem maintainer. It just looks incomplete to me. In the past I actually
verified it working with H2, H2+ and H3, none of them being
"allwinner,sun6i-a31-hwspinlock".

> > > Bjorn, what do you think? Just stay with the "allwinner,sun6i-a31-hwspinlock"
> > > string or add all the possible combinations like
> > > "allwinner,sun8i-h2-plus-hwspinlock" or "allwinner,sun8i-a83t-hwspinlock".
> > > I mean, it is just a naming game and there are 10+ SoCs supporting this
> > > spinlock register file
> 
> All devices compatible with the a31 should use the a31 as a fallback.
> 
> > 
> > > > Oh, and I may be able to test it against the D1, I own a Sipeed Nezha.
> > > 
> > > That would be great. You don't need FreeRTOS for it: I tested with a
> > > small Linux module that takes each lock and checks the status
> > > register. I can clean it up for the single-core D1 and send it.
> > 
> > Uhm, the Linux-only test doesn't work as a hwspinlock test, it misses the entire
> > point of the primitive. A hwspinlock arbitrates between two independent agents,
> > in this case, Linux running on the C906 core and FreeRTOS running on the HiFi
> > DSP, both sharing the same memory bus and other hardware. If Linux is the only
> > one who ever takes the locks, it is simultaneously writer and reader of the status
> > register, so the test cannot fail even for a broken (or fake) implementation. That
> > would basically test nothing at all, well, maybe it would be some kind of bring-up
> > test, but overall quite useless.


WARNING: multiple messages have this Message-ID (diff)
From: Wilken Gottwalt <wilken.gottwalt@posteo.net>
To: Conor Dooley <conor.dooley@microchip.com>
Cc: Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog>,
	Bjorn Andersson <andersson@kernel.org>,
	Baolin Wang <baolin.wang@linux.alibaba.com>,
	Rob Herring <robh@kernel.org>,
	Krzysztof Kozlowski <krzk+dt@kernel.org>,
	Conor Dooley <conor+dt@kernel.org>,
	Chen-Yu Tsai <wens@kernel.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Samuel Holland <samuel@sholland.org>,
	Paul Walmsley <pjw@kernel.org>,
	Palmer Dabbelt <palmer@dabbelt.com>,
	Albert Ou <aou@eecs.berkeley.edu>,
	Alexandre Ghiti <alex@ghiti.fr>,
	Philipp Zabel <p.zabel@pengutronix.de>,
	Andre Przywara <andre.przywara@arm.com>,
	Bastian Germann <bage@debian.org>,
	<linux-remoteproc@vger.kernel.org>, <devicetree@vger.kernel.org>,
	<linux-arm-kernel@lists.infradead.org>,
	<linux-sunxi@lists.linux.dev>, <linux-riscv@lists.infradead.org>,
	<linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 3/3] riscv: dts: allwinner: d1-t113: Add the hardware spinlock
Date: Fri, 02 Oct 2026 07:48:21 +0000	[thread overview]
Message-ID: <20261002094816.64349979@posteo.net> (raw)
In-Reply-To: <20261002-matted-tux-5b4059bc305a@wendy>

On Fri, 2 Oct 2026 08:32:51 +0100
Conor Dooley <conor.dooley@microchip.com> wrote:

> On Wed, Sep 30, 2026 at 02:05:47PM +0000, Wilken Gottwalt wrote:
> > On Wed, 30 Sep 2026 20:02:21 +0700
> > Nguyen Minh Tien <tien.nguyenminh@embeddedlinux.blog> wrote:
> > 
> > > Hi Wilken,
> > > 
> > > > Wouldn't it make more sense to add the "allwinner,sun20i-d1-hwspinlock" line to
> > > > the driver in the sun6i_hwspinlock_ids struct, drop
> > > > "allwinner,sun6i-a31-hwspinlock" here in the D1 device tree and update the yaml
> > > > file accordingly?
> > > 
> > > Thanks for looking at it. Bjorn hasn't replied yet, so I looked a bit
> > > more at the naming. I'd like to keep the A31 fallback: it's the usual
> > > pattern, other blocks in this dtsi do the same (timer, I2S, LED
> > > controller), and Conor already acked the binding in 2/3. If Bjorn
> > > prefers a driver entry instead, I'm fine to change it.
> > 
> > Yeah, Conor was a bit quick to act here, such things happen often with patchsets
> > made out of documentation/devicetrees and code. Though, the get clock and resets
> > patch is fine. The driver could use some modernization.
> 
> I dunno, was I too quick to act? The patched looked correct to me, since
> it was using a fallback to a device that it appears to be compatible
> with. Had the series done what you're suggesting, my review feedback
> would have been to tell the Tien to add a fallback.

I'm just not sure how to actually do it right, because so many SoCs include that
feature. That is why I asked how you would do it having more insight as a
subsystem maintainer. It just looks incomplete to me. In the past I actually
verified it working with H2, H2+ and H3, none of them being
"allwinner,sun6i-a31-hwspinlock".

> > > Bjorn, what do you think? Just stay with the "allwinner,sun6i-a31-hwspinlock"
> > > string or add all the possible combinations like
> > > "allwinner,sun8i-h2-plus-hwspinlock" or "allwinner,sun8i-a83t-hwspinlock".
> > > I mean, it is just a naming game and there are 10+ SoCs supporting this
> > > spinlock register file
> 
> All devices compatible with the a31 should use the a31 as a fallback.
> 
> > 
> > > > Oh, and I may be able to test it against the D1, I own a Sipeed Nezha.
> > > 
> > > That would be great. You don't need FreeRTOS for it: I tested with a
> > > small Linux module that takes each lock and checks the status
> > > register. I can clean it up for the single-core D1 and send it.
> > 
> > Uhm, the Linux-only test doesn't work as a hwspinlock test, it misses the entire
> > point of the primitive. A hwspinlock arbitrates between two independent agents,
> > in this case, Linux running on the C906 core and FreeRTOS running on the HiFi
> > DSP, both sharing the same memory bus and other hardware. If Linux is the only
> > one who ever takes the locks, it is simultaneously writer and reader of the status
> > register, so the test cannot fail even for a broken (or fake) implementation. That
> > would basically test nothing at all, well, maybe it would be some kind of bring-up
> > test, but overall quite useless.

_______________________________________________
linux-riscv mailing list
linux-riscv@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-riscv

  reply	other threads:[~2026-10-02  7:48 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-27  2:56 [PATCH 0/3] hwspinlock: sun6i: Allwinner D1 and T113 support Nguyen Minh Tien
2026-09-27  2:56 ` Nguyen Minh Tien
2026-09-27  2:56 ` [PATCH 1/3] hwspinlock: sun6i: Get the clock and the reset without names Nguyen Minh Tien
2026-09-27  2:56   ` Nguyen Minh Tien
2026-09-27  2:56 ` [PATCH 2/3] dt-bindings: hwlock: sun6i: Add compatible for Allwinner D1 Nguyen Minh Tien
2026-09-27  2:56   ` Nguyen Minh Tien
2026-09-28 16:51   ` Conor Dooley
2026-09-28 16:51     ` Conor Dooley
2026-09-27  2:56 ` [PATCH 3/3] riscv: dts: allwinner: d1-t113: Add the hardware spinlock Nguyen Minh Tien
2026-09-27  2:56   ` Nguyen Minh Tien
2026-09-27 11:27   ` Wilken Gottwalt
2026-09-27 11:27     ` Wilken Gottwalt
2026-09-30 13:02     ` Nguyen Minh Tien
2026-09-30 13:02       ` Nguyen Minh Tien
2026-09-30 14:05       ` Wilken Gottwalt
2026-09-30 14:05         ` Wilken Gottwalt
2026-10-02  7:32         ` Conor Dooley
2026-10-02  7:32           ` Conor Dooley
2026-10-02  7:48           ` Wilken Gottwalt [this message]
2026-10-02  7:48             ` Wilken Gottwalt
2026-10-02  7:50             ` Chen-Yu Tsai
2026-10-02  7:50               ` Chen-Yu Tsai
2026-10-02  8:37             ` Conor Dooley
2026-10-02  8:37               ` Conor Dooley
2026-10-02  7:48           ` Chen-Yu Tsai
2026-10-02  7:48             ` Chen-Yu Tsai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20261002094816.64349979@posteo.net \
    --to=wilken.gottwalt@posteo.net \
    --cc=alex@ghiti.fr \
    --cc=andersson@kernel.org \
    --cc=andre.przywara@arm.com \
    --cc=aou@eecs.berkeley.edu \
    --cc=bage@debian.org \
    --cc=baolin.wang@linux.alibaba.com \
    --cc=conor+dt@kernel.org \
    --cc=conor.dooley@microchip.com \
    --cc=devicetree@vger.kernel.org \
    --cc=jernej.skrabec@gmail.com \
    --cc=krzk+dt@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-remoteproc@vger.kernel.org \
    --cc=linux-riscv@lists.infradead.org \
    --cc=linux-sunxi@lists.linux.dev \
    --cc=p.zabel@pengutronix.de \
    --cc=palmer@dabbelt.com \
    --cc=pjw@kernel.org \
    --cc=robh@kernel.org \
    --cc=samuel@sholland.org \
    --cc=tien.nguyenminh@embeddedlinux.blog \
    --cc=wens@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.