From: Dafna Hirschfeld <dafna.hirschfeld@collabora.com>
To: linux-media@vger.kernel.org
Cc: mchehab@kernel.org, dafna.hirschfeld@collabora.com,
dafna3@gmail.com, tfiga@chromium.org, hverkuil@xs4all.nl,
linux-rockchip@lists.infradead.org, helen.koike@collabora.com,
laurent.pinchart@ideasonboard.com, sakari.ailus@linux.intel.com,
kernel@collabora.com, ezequiel@collabora.com
Subject: [PATCH v4 00/10] media: staging: rkisp1: add support to V4L2_CAP_IO_MC
Date: Tue, 1 Sep 2020 13:16:02 +0200 [thread overview]
Message-ID: <20200901111612.10552-1-dafna.hirschfeld@collabora.com> (raw)
The patchset solves several problems in the rkisp1 driver.
1. Currently the resizers output media code MEDIA_BUS_FMT_YUYV8_2X8 when the input is
MEDIA_BUS_FMT_YUYV8_2X8.
The patchset adds support to other media codes on the resizer according to
the chroma subsampling.
Setting the correct media code on the source pad that matches the
chroma subsampling reflects userspace that the resizer has downsampling
capability and also the resizer entity does not have to check the capture entity's
configuration to get the scaling ratio, the information of how to scale can be
obtained from the source media code of the resizer.
2. Add support for the V4L2_CAP_IO_MC capability on
the mainpath and selfpath captures. This helps userspace to know the
right configuration for streaming. This is especially helpful for the
RGB and Grey formats that expect media bus MEDIA_BUS_FMT_YUYV8_2X8
which is not something userspace can 'guess'. Adding a mapping of the
required mbus code for each pixelformat also makes the link_validation
code much simpler, it just has to check if the configuration matches the mapping.
3. Removes unsupported packed yuv formats - this patch was already part of a pull request
and was dropped due to merge conflicts.
4. Remove bayer formats on the selfpath resizer since they are not
supported on the selfpath capture.
5. Remove support to YUV444 pixel format, I was not able to find a configuration
that supports this format. I kept getting bad looking frames.
I tried to add capture yuv444 formats by adding an entry:
+ {
+ .mbus_code = MEDIA_BUS_FMT_YUV8_1X24,
+ .hdiv = 1,
+ .vdiv = 1,
+ }
to the list of supported formats: rkisp1_rsz_yuv_src_formats[]
full patch: http://ix.io/2vNJ
On the mainpath I get good images, but on the selfpath I get bad looking images:
https://pasteboard.co/JoWp3U4.png
https://pasteboard.co/Jp1YWLR.png
Interestingly, when changing the sp_input from default RKISP1_MI_CTRL_SP_INPUT_YUV422
to RKISP1_MI_CTRL_SP_INPUT_YUV444, then the images that are not upscaled look good:
https://pasteboard.co/Jp22u6E.png
but with upscaling (1604x1232 -> 1920x1500) it still looks bad:
https://pasteboard.co/Jp22MBU.png
6. Fix the configuration to support Grey format - the 'write_format' field should
be 'planar'
changes since v3:
patch 1 - remove '----' line from commit log
patch 5-7 - refactor code, add documentation
patch 8 - change function name rkisp1_rsz_yuv_mbus_info and code in function rkisp1_rsz_set_src_fmt
Dafna Hirschfeld (10):
media: staging: rkisp1: cap: change RGB24 format to XBGR32
media: staging: rkisp1: cap: remove unsupported formats
media: staging: rkisp1: cap: remove unsupported format YUV444
media: staging: rkisp1: don't support bayer format on selfpath resizer
media: staging: rkisp1: add capability V4L2_CAP_IO_MC to capture
devices
media: staging: rkisp1: add a helper function to enumerate supported
mbus formats on capture
media: staging: rkisp1: rsz: enumerate the formats on the src pad
according to the capture
media: staging: rkisp1: rsz: Add support to more YUV encoded mbus
codes on src pad
media: staging: rkisp1: cap: simplify the link validation by compering
the media bus code
media: staging: rkisp1: fix configuration for GREY pixelformat
drivers/staging/media/rkisp1/rkisp1-capture.c | 199 +++++++++++-------
drivers/staging/media/rkisp1/rkisp1-common.h | 11 +
drivers/staging/media/rkisp1/rkisp1-resizer.c | 93 ++++++--
3 files changed, 203 insertions(+), 100 deletions(-)
--
2.17.1
_______________________________________________
Linux-rockchip mailing list
Linux-rockchip@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-rockchip
next reply other threads:[~2020-09-01 12:05 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-01 11:16 Dafna Hirschfeld [this message]
2020-09-01 11:16 ` [PATCH v4 01/10] media: staging: rkisp1: cap: change RGB24 format to XBGR32 Dafna Hirschfeld
2020-09-01 11:16 ` [PATCH v4 02/10] media: staging: rkisp1: cap: remove unsupported formats Dafna Hirschfeld
2020-09-26 13:17 ` Tomasz Figa
2020-09-27 9:33 ` Dafna Hirschfeld
2020-09-27 12:01 ` Tomasz Figa
2020-09-01 11:16 ` [PATCH v4 03/10] media: staging: rkisp1: cap: remove unsupported format YUV444 Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 04/10] media: staging: rkisp1: don't support bayer format on selfpath resizer Dafna Hirschfeld
2020-09-01 11:16 ` [PATCH v4 05/10] media: staging: rkisp1: add capability V4L2_CAP_IO_MC to capture devices Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 06/10] media: staging: rkisp1: add a helper function to enumerate supported mbus formats on capture Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 07/10] media: staging: rkisp1: rsz: enumerate the formats on the src pad according to the capture Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 08/10] media: staging: rkisp1: rsz: Add support to more YUV encoded mbus codes on src pad Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 09/10] media: staging: rkisp1: cap: simplify the link validation by compering the media bus code Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-01 11:16 ` [PATCH v4 10/10] media: staging: rkisp1: fix configuration for GREY pixelformat Dafna Hirschfeld
2020-09-07 14:19 ` Helen Koike
2020-09-26 13:38 ` [PATCH v4 00/10] media: staging: rkisp1: add support to V4L2_CAP_IO_MC Tomasz Figa
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=20200901111612.10552-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 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).