From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Michal Simek <michal.simek@amd.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Vinod Koul <vkoul@kernel.org>,
dmaengine@vger.kernel.org
Subject: Re: [PATCH 2/3] dma: xilinx_dpdma: Remove unnecessary use of irqsave/restore
Date: Thu, 28 Mar 2024 18:37:06 +0200 [thread overview]
Message-ID: <4f994662-347d-4562-9108-5d7e3798fa51@ideasonboard.com> (raw)
In-Reply-To: <d6a8c1c8-258a-447b-b6cd-199f33199388@linux.dev>
On 28/03/2024 17:00, Sean Anderson wrote:
> On 3/27/24 08:27, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 08/03/2024 23:00, Sean Anderson wrote:
>>> xilinx_dpdma_chan_done_irq and xilinx_dpdma_chan_vsync_irq are always
>>> called with IRQs disabled from xilinx_dpdma_irq_handler. Therefore we
>>> don't need to save/restore the IRQ flags.
>>
>> I think this is fine, but a few thoughts:
>>
>> - Is spin_lock clearly faster than the irqsave variant, or is this a pointless optimization? It's safer to just use irqsave variant, instead of making sure the code is always called from the expected contexts.
>
> It's not an optimization. Technically this will save a few instructions,
> but...
>
>> - Is this style documented/recommended anywhere? Going through docs, I only found docs telling to use irqsave when mixing irq and non-irq contexts.
>
> The purpose is mainly to make it clear that this is meant to be called
> in IRQ context. With irqsave, there's an implication that this could be
> called in non-IRQ context, which it never is.
Hmm, I see. Yes, I think that makes sense.
>> - Does this cause issues on PREEMPT_RT?
>
> Why would it?
I was reading locktypes.rst, I started wondering what it means if
spinlocks are changed into sleeping locks. But thinking about it again,
it doesn't matter, as the irq will still be masked when in irq-context.
So:
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
WARNING: multiple messages have this Message-ID (diff)
From: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
To: Sean Anderson <sean.anderson@linux.dev>
Cc: Michal Simek <michal.simek@amd.com>,
linux-kernel@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
Vinod Koul <vkoul@kernel.org>,
dmaengine@vger.kernel.org
Subject: Re: [PATCH 2/3] dma: xilinx_dpdma: Remove unnecessary use of irqsave/restore
Date: Thu, 28 Mar 2024 18:37:06 +0200 [thread overview]
Message-ID: <4f994662-347d-4562-9108-5d7e3798fa51@ideasonboard.com> (raw)
In-Reply-To: <d6a8c1c8-258a-447b-b6cd-199f33199388@linux.dev>
On 28/03/2024 17:00, Sean Anderson wrote:
> On 3/27/24 08:27, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 08/03/2024 23:00, Sean Anderson wrote:
>>> xilinx_dpdma_chan_done_irq and xilinx_dpdma_chan_vsync_irq are always
>>> called with IRQs disabled from xilinx_dpdma_irq_handler. Therefore we
>>> don't need to save/restore the IRQ flags.
>>
>> I think this is fine, but a few thoughts:
>>
>> - Is spin_lock clearly faster than the irqsave variant, or is this a pointless optimization? It's safer to just use irqsave variant, instead of making sure the code is always called from the expected contexts.
>
> It's not an optimization. Technically this will save a few instructions,
> but...
>
>> - Is this style documented/recommended anywhere? Going through docs, I only found docs telling to use irqsave when mixing irq and non-irq contexts.
>
> The purpose is mainly to make it clear that this is meant to be called
> in IRQ context. With irqsave, there's an implication that this could be
> called in non-IRQ context, which it never is.
Hmm, I see. Yes, I think that makes sense.
>> - Does this cause issues on PREEMPT_RT?
>
> Why would it?
I was reading locktypes.rst, I started wondering what it means if
spinlocks are changed into sleeping locks. But thinking about it again,
it doesn't matter, as the irq will still be masked when in irq-context.
So:
Reviewed-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>
Tomi
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-03-28 16:37 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-08 21:00 [PATCH 0/3] dma: xilinx_dpdma: Fix locking Sean Anderson
2024-03-08 21:00 ` Sean Anderson
2024-03-08 21:00 ` [PATCH 1/3] " Sean Anderson
2024-03-08 21:00 ` Sean Anderson
2024-03-27 11:57 ` Tomi Valkeinen
2024-03-27 11:57 ` Tomi Valkeinen
2024-03-08 21:00 ` [PATCH 2/3] dma: xilinx_dpdma: Remove unnecessary use of irqsave/restore Sean Anderson
2024-03-08 21:00 ` Sean Anderson
2024-03-27 12:27 ` Tomi Valkeinen
2024-03-27 12:27 ` Tomi Valkeinen
2024-03-28 15:00 ` Sean Anderson
2024-03-28 15:00 ` Sean Anderson
2024-03-28 16:37 ` Tomi Valkeinen [this message]
2024-03-28 16:37 ` Tomi Valkeinen
2024-03-08 21:00 ` [PATCH 3/3] dma: Add lockdep asserts to virt-dma Sean Anderson
2024-03-08 21:00 ` Sean Anderson
2024-03-27 12:29 ` Tomi Valkeinen
2024-03-27 12:29 ` Tomi Valkeinen
2024-04-07 16:38 ` [PATCH 0/3] dma: xilinx_dpdma: Fix locking Vinod Koul
2024-04-07 16:38 ` Vinod Koul
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=4f994662-347d-4562-9108-5d7e3798fa51@ideasonboard.com \
--to=tomi.valkeinen@ideasonboard.com \
--cc=dmaengine@vger.kernel.org \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=michal.simek@amd.com \
--cc=sean.anderson@linux.dev \
--cc=vkoul@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.