From: Philipp Puschmann <philipp.puschmann@emlix.com>
To: "Jan Lübbe" <jlu@pengutronix.de>, linux-kernel@vger.kernel.org
Cc: fugang.duan@nxp.com, festevam@gmail.com, s.hauer@pengutronix.de,
vkoul@kernel.org, linux-imx@nxp.com, kernel@pengutronix.de,
dan.j.williams@intel.com, yibin.gong@nxp.com,
shawnguo@kernel.org, dmaengine@vger.kernel.or,
linux-arm-kernel@lists.infradead.org, l.stach@pengutronix.de
Subject: Re: [PATCH v4 2/3] dmaengine: imx-sdma: fix dma freezes
Date: Fri, 20 Sep 2019 10:53:44 +0200 [thread overview]
Message-ID: <9305e5ff-f555-3c6e-9e99-36d88edcae0a@emlix.com> (raw)
In-Reply-To: <ad87f175496358adb825240f1de609318ed8204c.camel@pengutronix.de>
Hi Jan,
Am 19.09.19 um 17:19 schrieb Jan Lübbe:
> Hi Philipp,
>
> see below...
>
> On Thu, 2019-09-19 at 16:29 +0200, Philipp Puschmann wrote:
>> For some years and since many kernel versions there are reports that the
>> RX UART SDMA channel stops working at some point. The workaround was to
>> disable DMA for RX. This commit tries to fix the problem itself.
>>
>> Due to its license i wasn't able to debug the sdma script itself but it
>> somehow leads to blocking the scheduling of the channel script when a
>> running sdma script does not find any free descriptor in the ring to put
>> its data into.
>>
>> If we detect such a potential case we manually restart the channel.
>>
>> As sdmac->desc is constant we can move desc out of the loop.
>>
>> Fixes: 1ec1e82f2510 ("dmaengine: Add Freescale i.MX SDMA support")
>> Signed-off-by: Philipp Puschmann <philipp.puschmann@emlix.com>
>> Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
>> ---
>>
>> Changelog v4:
>> - fixed the fixes tag
>>
>> Changelog v3:
>> - use correct dma_wmb() instead of dma_wb()
>> - add fixes tag
>>
>> Changelog v2:
>> - clarify comment and commit description
>>
>> drivers/dma/imx-sdma.c | 21 +++++++++++++++++----
>> 1 file changed, 17 insertions(+), 4 deletions(-)
>>
>> diff --git a/drivers/dma/imx-sdma.c b/drivers/dma/imx-sdma.c
>> index e029a2443cfc..a32b5962630e 100644
>> --- a/drivers/dma/imx-sdma.c
>> +++ b/drivers/dma/imx-sdma.c
>> @@ -775,21 +775,23 @@ static void sdma_start_desc(struct sdma_channel *sdmac)
>> static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> {
>> struct sdma_buffer_descriptor *bd;
>> - int error = 0;
>> - enum dma_status old_status = sdmac->status;
>> + struct sdma_desc *desc = sdmac->desc;
>> + int error = 0, cnt = 0;
>> + enum dma_status old_status = sdmac->status;
>>
>> /*
>> * loop mode. Iterate over descriptors, re-setup them and
>> * call callback function.
>> */
>> - while (sdmac->desc) {
>> - struct sdma_desc *desc = sdmac->desc;
>> + while (desc) {
>>
>> bd = &desc->bd[desc->buf_tail];
>>
>> if (bd->mode.status & BD_DONE)
>> break;
>>
>> + cnt++;
>> +
>> if (bd->mode.status & BD_RROR) {
>> bd->mode.status &= ~BD_RROR;
>> sdmac->status = DMA_ERROR;
>> @@ -822,6 +824,17 @@ static void sdma_update_channel_loop(struct sdma_channel *sdmac)
>> if (error)
>> sdmac->status = old_status;
>> }
>> +
>> + /* In some situations it may happen that the sdma does not found any
> ^ hasn't
>> + * usable descriptor in the ring to put data into. The channel is
>> + * stopped then. While there is no specific error condition we can
>> + * check for, a necessary condition is that all available buffers for
>> + * the current channel have been written to by the sdma script. In
>> + * this case and after we have made the buffers available again,
>> + * we restart the channel.
>> + */
>
> Are you sure we can't miss cases where we only had to make some buffers
> available again, but the SDMA already ran out of buffers before?
Think so, yes.
>
> A while ago, I was debugging a similar issue triggered by receiving
> data with a wrong baud rate, which leads to all descriptors being
> marked with the error flag very quickly (and the SDMA stalling).
> I noticed that you can check if the channel is still running by
> checking the SDMA_H_STATSTOP register & BIT(sdmac->channel).
I think checking for this register is the better approach. Then i could drop the
cnt variable. And by droppting cnt i would propose to move the check and reenabling
to the end of the while loop to reenable the channel after freeing first buffer.
>
> I also added a flag for the sdmac->flags field to allow stopping the
> channel from the callback (otherwise it would enable the channel
> again).
Could memory and compiler ordering a problem here?
I'm not that into these kind of problems, but is this
sdmac->flags &= ~IMX_DMA_ACTIVE;
writel_relaxed(BIT(channel), sdma->regs + SDMA_H_STATSTOP);
guaranteed to be free of race conditions?
Regards,
Philipp
>
> Attached is my current version of that patch for reference.
>
>> + if (cnt >= desc->num_bd)
>> + sdma_enable_channel(sdmac->sdma, sdmac->channel);
>> }
>>
>> static void mxc_sdma_handle_channel_normal(struct sdma_channel *data)
next prev parent reply other threads:[~2019-09-20 8:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-19 14:29 [PATCH v4 0/3] Fix UART DMA freezes for i.MX SOCs Philipp Puschmann
2019-09-19 14:29 ` [PATCH v4 1/3] dmaengine: imx-sdma: fix buffer ownership Philipp Puschmann
2019-09-19 14:29 ` [PATCH v4 2/3] dmaengine: imx-sdma: fix dma freezes Philipp Puschmann
2019-09-19 15:19 ` Jan Lübbe
2019-09-20 8:53 ` Philipp Puschmann [this message]
2019-09-20 9:26 ` Lucas Stach
2019-09-24 1:38 ` Robin Gong
2019-09-19 14:29 ` [PATCH v4 3/3] dmaengine: imx-sdma: drop redundant variable Philipp Puschmann
2019-09-20 2:44 ` [EXT] [PATCH v4 0/3] Fix UART DMA freezes for i.MX SOCs Andy Duan
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=9305e5ff-f555-3c6e-9e99-36d88edcae0a@emlix.com \
--to=philipp.puschmann@emlix.com \
--cc=dan.j.williams@intel.com \
--cc=dmaengine@vger.kernel.or \
--cc=festevam@gmail.com \
--cc=fugang.duan@nxp.com \
--cc=jlu@pengutronix.de \
--cc=kernel@pengutronix.de \
--cc=l.stach@pengutronix.de \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-imx@nxp.com \
--cc=linux-kernel@vger.kernel.org \
--cc=s.hauer@pengutronix.de \
--cc=shawnguo@kernel.org \
--cc=vkoul@kernel.org \
--cc=yibin.gong@nxp.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).