[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <ZpelQj6HufZTe52d@hovoldconsulting.com>
Date: Wed, 17 Jul 2024 13:04:34 +0200
From: Johan Hovold <johan@...nel.org>
To: Bryan O'Donoghue <bryan.odonoghue@...aro.org>
Cc: Robert Foss <rfoss@...nel.org>, Todor Tomov <todor.too@...il.com>,
Mauro Carvalho Chehab <mchehab@...nel.org>,
Hans Verkuil <hansverk@...co.com>,
Hans Verkuil <hverkuil-cisco@...all.nl>,
Milen Mitkov <quic_mmitkov@...cinc.com>,
linux-media@...r.kernel.org, linux-arm-msm@...r.kernel.org,
linux-kernel@...r.kernel.org,
Mauro Carvalho Chehab <mchehab+samsung@...nel.org>,
Johan Hovold <johan+linaro@...nel.org>, stable@...r.kernel.org
Subject: Re: [PATCH v2 1/2] media: qcom: camss: Remove use_count guard in
stop_streaming
On Wed, Jul 17, 2024 at 11:43:02AM +0100, Bryan O'Donoghue wrote:
> On 17/07/2024 10:06, Johan Hovold wrote:
> >> The use of use_count like this is a bit hacky and right now breaks regular
> >> usage of CAMSS for a single stream case. As an example the "qcam"
> >> application in libcamera will fail with an -EBUSY result on stream stop and
> >> cannot then subsequently be restarted.
> > No, stopping qcam results in the splat below, and then it cannot be
> > started again and any attempts to do so fails with -EBUSY.
>
> I thought that's what I said.
I read the above as if stopping the stream fails with -EBUSY, when it's
really restarting the stream that fails that way after the first stop.
> Let me reword the commit log with your sentence included directly :)
Sounds good.
Johan
Powered by blists - more mailing lists