| Message ID | 20211120110257.22775-1-dafna.hirschfeld@collabora.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | media: rkisp1: remove support for V4L2_PIX_FMT_GREY | expand |
Hi Dafna, Thank you for the patch. 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. > Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> > --- > .../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,
On 20.11.21 14:34, Laurent Pinchart wrote: > Hi Dafna, > > Thank you for the patch. > > 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? 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@collabora.com> >> --- >> .../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, >
Hi Dafna, 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. 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 ? > [1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv-luma.html > > >> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> > >> --- > >> .../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,
On 22.11.21 14:29, Laurent Pinchart wrote: > Hi Dafna, > > 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. > > 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. > >> [1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv-luma.html >> >>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> >>>> --- >>>> .../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, >
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. > > > > 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 ? > >> [1] https://www.kernel.org/doc/html/latest/userspace-api/media/v4l/pixfmt-yuv-luma.html > >> > >>>> Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> > >>>> --- > >>>> .../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,
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@collabora.com> >>>>>> --- >>>>>> .../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, >
Le mercredi 01 décembre 2021 à 09:03 +0200, Dafna Hirschfeld a écrit : > > 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. Just a guess, but its possible they use a short cut to gray scale, and write to NV12 buffers. planar YUV 420 are somewhat compatible with grayscale, so that's always a possible cheat. > > > > > > > > > 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@collabora.com> > > > > > > > --- > > > > > > > .../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, > > >
Quoting Nicolas Dufresne (2021-12-01 18:14:45) > Le mercredi 01 décembre 2021 à 09:03 +0200, Dafna Hirschfeld a écrit : > > > > 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. > > Just a guess, but its possible they use a short cut to gray scale, and write to > NV12 buffers. planar YUV 420 are somewhat compatible with grayscale, so that's > always a possible cheat. NV12 would be a pain, as it would require bigger buffers to be provided for the capture, which if coming from an external source rather than allocated on the device might not be given ... Is there an explicit way to configure the UV plane on the RKISP to an internal scratch buffer that would get discarded? or will it always assume the UV data is immediately after the Y data? -- Kieran > > > > > 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@collabora.com> > > > > > > > > --- > > > > > > > > .../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, > > > > > >
On 02.12.21 01:29, Kieran Bingham wrote: > Quoting Nicolas Dufresne (2021-12-01 18:14:45) >> Le mercredi 01 décembre 2021 à 09:03 +0200, Dafna Hirschfeld a écrit : >>> >>> 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. >> >> Just a guess, but its possible they use a short cut to gray scale, and write to >> NV12 buffers. planar YUV 420 are somewhat compatible with grayscale, so that's >> always a possible cheat. > > NV12 would be a pain, as it would require bigger buffers to be provided > for the capture, which if coming from an external source rather than > allocated on the device might not be given ... > > Is there an explicit way to configure the UV plane on the RKISP to an > internal scratch buffer that would get discarded? or will it always > assume the UV data is immediately after the Y data? It's actually not assumed so, the UV buffer address is a different address configured into the device and doesn't have to be continuously after the Y buffer. So we can indeed set it to a dummy buffer (which is already there for the cases no vb2 buffers are queued. Thanks, Dafna > > -- > Kieran > > >>>>>> 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@collabora.com> >>>>>>>>> --- >>>>>>>>> .../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, >>>> >>> >>
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,
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. Signed-off-by: Dafna Hirschfeld <dafna.hirschfeld@collabora.com> --- .../platform/rockchip/rkisp1/rkisp1-capture.c | 15 --------------- 1 file changed, 15 deletions(-)