[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <700f857c-0d99-4e7e-a969-191c5afd10f8@www.fastmail.com>
Date: Fri, 20 Dec 2019 07:46:18 +1030
From: "Andrew Jeffery" <andrew@...id.au>
To: "Eddie James" <eajames@...ux.ibm.com>,
linux-aspeed@...ts.ozlabs.org
Cc: linux-kernel@...r.kernel.org, devicetree@...r.kernel.org,
mark.rutland@....com, "Jason Cooper" <jason@...edaemon.net>,
"Marc Zyngier" <maz@...nel.org>,
"Rob Herring" <robh+dt@...nel.org>, tglx@...utronix.de,
"Joel Stanley" <joel@....id.au>
Subject: Re: [PATCH v3 07/12] soc: aspeed: xdma: Add user interface
On Fri, 20 Dec 2019, at 02:30, Eddie James wrote:
>
> On 12/18/19 7:19 PM, Andrew Jeffery wrote:
> >
> > On Thu, 19 Dec 2019, at 01:39, Eddie James wrote:
> >> + mutex_unlock(&ctx->file_lock);
> >> + return -EBUSY;
> >> + }
> >> + } else {
> >> + mutex_lock(&ctx->file_lock);
> >> +
> >> + rc = wait_event_interruptible(ctx->wait, !ctx->current_client);
> >> + if (rc) {
> >> + mutex_unlock(&ctx->file_lock);
> >> + return -EINTR;
> >> + }
> >> + }
> >> +
> >> + aspeed_xdma_start(ctx, &op, client->phys, client);
> >> +
> >> + mutex_unlock(&ctx->file_lock);
> > Shouldn't we lift start_lock out of aspeed_xdma_start() use that here
> > instead of file_lock? I think that would mean that we could remove
> > file_lock.
>
>
> That wouldn't work with the reset though. The reset should hold
> start_lock as well, but if a client is waiting here with start_lock,
> we'd never get to the reset if the transfer doesn't complete. I think
> file_lock is necessary.
Hmm, let me think about this some more.
Andrew
Powered by blists - more mailing lists