All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Hans Verkuil <hverkuil-cisco@xs4all.nl>
Cc: Vikash Garodia <quic_vgarodia@quicinc.com>,
	Bryan O'Donoghue <bryan.odonoghue@linaro.org>,
	Sergey Senozhatsky <senozhatsky@chromium.org>,
	Stanimir Varbanov <stanimir.k.varbanov@gmail.com>,
	Andy Gross <agross@kernel.org>,
	Bjorn Andersson <andersson@kernel.org>,
	Konrad Dybcio <konrad.dybcio@linaro.org>,
	Tomasz Figa <tfiga@chromium.org>,
	linux-media@vger.kernel.org, linux-arm-msm@vger.kernel.org
Subject: Re: [PATCHv3] media: venus: provide video device lock
Date: Thu, 25 May 2023 17:59:36 +0900	[thread overview]
Message-ID: <20230525085936.GD30543@google.com> (raw)
In-Reply-To: <1eeb16e4-0812-b70b-df5a-1670c21a5221@xs4all.nl>

On (23/05/25 09:22), Hans Verkuil wrote:
> >> Since these are m2m devices, I think this should set vfh->m2m_ctx->q_lock
> >> instead.
> >>
> >> The vb2_queue is per filehandle for such devices, so by just setting
> >> vdev->lock you will have all vb2_queues use the same mutex.
> >>
> >> Instead the struct v4l2_m2m_ctx q_lock pointer, if set, will use that
> >> mutex for all vb2 operations.
> >>
> >> I think you can set it to the 'lock' mutex in struct venus_inst.
> > 
> > IIUC, the suggestion is to use the 'lock' in struct venus_inst while
> > initializing the queue. This might lead to deadlock as the same lock is used
> > during vb2 operations in driver. Might be introducing a new lock for this
> > purpose in struct venus_inst would do, unless we are trying to serialize at
> > video device (or core) context.
> 
> For the record, I have not analyzed how that lock is used in the driver,
> so if a new mutex has to be added to venus_inst rather than reusing the
> existing one, then that's fine by me.
> 
> But it should be a instance-specific mutex, not one at the device level.

Thanks for your help Hans. I added a per-instance queue mutex [1], so if
no one sees any problems with it then I can send a formal patch later on.

[1] https://lore.kernel.org/linux-media/20230525005312.GC30543@google.com

  reply	other threads:[~2023-05-25  8:59 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-24  1:36 [PATCH] media: venus: provide video device lock Sergey Senozhatsky
2023-05-24 12:40 ` Sergey Senozhatsky
2023-05-24 13:56 ` [PATCHv2] " Sergey Senozhatsky
2023-05-24 14:12   ` [PATCHv3] " Sergey Senozhatsky
2023-05-24 14:29     ` Bryan O'Donoghue
2023-05-24 14:44       ` Hans Verkuil
2023-05-24 16:36         ` Vikash Garodia
2023-05-25  0:53           ` Sergey Senozhatsky
2023-05-25 11:02             ` Vikash Garodia
2023-05-26  3:35               ` Sergey Senozhatsky
2023-05-25  7:22           ` Hans Verkuil
2023-05-25  8:59             ` Sergey Senozhatsky [this message]
2023-05-25  9:03               ` Hans Verkuil
2023-06-01 10:16         ` Vikash Garodia

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=20230525085936.GD30543@google.com \
    --to=senozhatsky@chromium.org \
    --cc=agross@kernel.org \
    --cc=andersson@kernel.org \
    --cc=bryan.odonoghue@linaro.org \
    --cc=hverkuil-cisco@xs4all.nl \
    --cc=konrad.dybcio@linaro.org \
    --cc=linux-arm-msm@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=quic_vgarodia@quicinc.com \
    --cc=stanimir.k.varbanov@gmail.com \
    --cc=tfiga@chromium.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.