On 22.11.21 16:28, Laurent Pinchart wrote:
Hi Dafna,
On Mon, Nov 22, 2021 at 04:21:25PM +0200, Dafna Hirschfeld wrote:
On 22.11.21 14:29, Laurent Pinchart wrote:
On Mon, Nov 22, 2021 at 01:20:47PM +0200, Dafna Hirschfeld wrote:
On 20.11.21 14:34, Laurent Pinchart wrote:
On Sat, Nov 20, 2021 at 01:02:57PM +0200, Dafna Hirschfeld wrote:
When trying to stream on both mainpatch and selfpatch
with grey format, I get an iommu page fault.
The fault is on the address at the end of the buffer,
so it seems that the device is somehow wrongly
configured and thinks there is another plane.
Could we try to fix that instead ? There are IR sensors for which the
GREY format is useful.
Hi, the doc is not very useful so I can try doing a bit trial and error.
I see that there are several greyscale formats: [1]
which make me think that maybe the device support one of the other greyscale formats.
Do you know if some formats are more likely than other?
GREY seems the most likely (useful for IR sensors for instance, after
ISP processing). Formats with a higher bpp would require processing of
more than 8bpp through the ISP pipeline, I don't know if that's
supported.
I tried all kind of things but was not able to stream greyscale.
When ISP processing works it outputs YUV 422 format and then the resizer
is used to change the format to YUV 420 if wanted.
I tried to chance the scale to YUV 400 (grey) or change the mainpath/selfpath
configuration but still had that iommu page fault errors.
Interestingly when I bypass the iommu and dma allocation is direct
the streaming works and even the output frames seems okayish greyscale format
but that might be by accident.
Formats with a higher bpp (both greyscale and bayer formats) are also
useful to capture raw images (before ISP processing). Is that something
the hardware and driver support ?
hi, yes the variations of V4L2_PIX_FMT_Sxxxx10, V4L2_PIX_FMT_Sxxxx12
are supported on mainpath.
That's nice. Does it bypass the whole ISP then ? Is it possible to
capture raw frames on the main path and processed frames on the self
path at the same time, or are we restricted to raw only when we capture
raw frames ?
I think we are restricted to raw only when we capture raw frames.
The doc describe the isp_ctl register that set the isp output to either raw or yuv.
It seems not to be possible to send raw to mainpath and yuv to selfpath.
Thanks,
Dafna
[1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv-luma.html
Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@xxxxxxxxxxxxx>
---
.../platform/rockchip/rkisp1/rkisp1-capture.c | 15 ---------------
1 file changed, 15 deletions(-)
diff --git a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
index 768987d5f2dd..7f78f361dd5e 100644
--- a/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
+++ b/drivers/media/platform/rockchip/rkisp1/rkisp1-capture.c
@@ -116,13 +116,6 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_mp_fmts[] = {
.write_format = RKISP1_MI_CTRL_MP_WRITE_YUV_PLA_OR_RAW8,
.mbus = MEDIA_BUS_FMT_YUYV8_2X8,
},
- /* yuv400 */
- {
- .fourcc = V4L2_PIX_FMT_GREY,
- .uv_swap = 0,
- .write_format = RKISP1_MI_CTRL_MP_WRITE_YUV_PLA_OR_RAW8,
- .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
- },
/* yuv420 */
{
.fourcc = V4L2_PIX_FMT_NV21,
@@ -244,14 +237,6 @@ static const struct rkisp1_capture_fmt_cfg rkisp1_sp_fmts[] = {
.output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV422,
.mbus = MEDIA_BUS_FMT_YUYV8_2X8,
},
- /* yuv400 */
- {
- .fourcc = V4L2_PIX_FMT_GREY,
- .uv_swap = 0,
- .write_format = RKISP1_MI_CTRL_SP_WRITE_PLA,
- .output_format = RKISP1_MI_CTRL_SP_OUTPUT_YUV400,
- .mbus = MEDIA_BUS_FMT_YUYV8_2X8,
- },
/* rgb */
{
.fourcc = V4L2_PIX_FMT_XBGR32,
