From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
To: linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com
Cc: dafna.hirschfeld@collabora.com, helen.koike@collabora.com,
ezequiel@collabora.com, hverkuil@xs4all.nl, kernel@collabora.com,
dafna3@gmail.com, sakari.ailus@linux.intel.com,
linux-rockchip@lists.infradead.org, mchehab@kernel.org,
tfiga@chromium.org
Subject: [PATCH 0/4] media: staging: rkisp1: fix possible race conditions in capture
Date: Tue, 14 Jul 2020 14:38:28 +0200 [thread overview]
Message-ID: <20200714123832.28011-1-dafna.hirschfeld@collabora.com> (raw)
This patchset fixes several issues found in capture related
to buffer managings.
Patch 1 - The first patch removes an optimization that seems not useful.
The optimization configures the next buffer in case the capture
already streams and the first buffer is queued just before
the first irq. This is an unlikely scenario. Also
the code reads the field 'frame_sequence' which is updated
on v-start interrupt by 'rkisp1-isp'. Laurent Pinchart mentioned
in a comment that reading the frame_sequence outside of irq
handlers should be avoided due to possible race conditions.
https://patchwork.kernel.org/patch/11066513/#22823561
The entity 'rkisp1-params' also reads 'frame_sequence' outside of the irq handler
a patch(set) will be sent to fix that too.
Patch 2 - The second patch uses buf.lock to protect buf.curr and buf.next
in places where they are not protected.
Patch 3 - moves the code that manages the buffers to be together
with the code that configure the next buffer address to the registers.
This is a preparation for patch 4.
patch 4 - The function 'rkisp1_stream_start' uses the function
'rkisp1_handle_buffer' in order to manage the buffers and configure
the address registers before stream starts. But the function
'rkisp1_handle_buffer' also contains other code that is not needed for
stream start
The patch replace it with calls to rkisp1_set_next_buf.
Dafna Hirschfeld (4):
media: staging: rkisp1: cap: don't set next buffer from
rkisp1_vb2_buf_queue
media: staging: rkisp1: cap: protect buf.curr and buf.next with
buf.lock
media: staging: rkisp1: cap: move code that manages the buffers to
rkisp1_set_next_buf
media: staging: rkisp1: cap: in stream start, replace calls to
rkisp1_handle_buffer with rkisp1_set_next_buf
drivers/staging/media/rkisp1/rkisp1-capture.c | 52 +++++++------------
1 file changed, 20 insertions(+), 32 deletions(-)
--
2.17.1
next reply other threads:[~2020-07-14 12:38 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-14 12:38 Dafna Hirschfeld [this message]
2020-07-14 12:38 ` [PATCH 1/4] media: staging: rkisp1: cap: don't set next buffer from rkisp1_vb2_buf_queue Dafna Hirschfeld
2020-07-14 12:48 ` Helen Koike
2020-07-14 15:11 ` Helen Koike
2020-07-15 10:07 ` Helen Koike
2020-07-14 12:38 ` [PATCH 2/4] media: staging: rkisp1: cap: protect buf.curr and buf.next with buf.lock Dafna Hirschfeld
2020-07-14 15:11 ` Helen Koike
2020-07-14 12:38 ` [PATCH 3/4] media: staging: rkisp1: cap: move code that manages the buffers to rkisp1_set_next_buf Dafna Hirschfeld
2020-07-14 15:11 ` Helen Koike
2020-07-14 12:38 ` [PATCH 4/4] media: staging: rkisp1: cap: in stream start, replace calls to rkisp1_handle_buffer with rkisp1_set_next_buf Dafna Hirschfeld
2020-07-14 15:11 ` Helen Koike
2020-07-15 7:36 ` Dafna Hirschfeld
2020-07-15 10:04 ` Helen Koike
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=20200714123832.28011-1-dafna.hirschfeld@collabora.com \
--to=dafna.hirschfeld@collabora.com \
--cc=dafna3@gmail.com \
--cc=ezequiel@collabora.com \
--cc=helen.koike@collabora.com \
--cc=hverkuil@xs4all.nl \
--cc=kernel@collabora.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=linux-rockchip@lists.infradead.org \
--cc=mchehab@kernel.org \
--cc=sakari.ailus@linux.intel.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.