Message ID | 1587536339-4030-1-git-send-email-skomatineni@nvidia.com (mailing list archive) |
---|---|
Headers | show |
Series | Add Tegra driver for video capture | expand |
On 22/04/2020 08:18, Sowjanya Komatineni wrote: > Tegra210 contains a powerful Video Input (VI) hardware controller > which can support up to 6 MIPI CSI camera sensors. > > Each Tegra CSI port can be one-to-one mapped to VI channel and can > capture from an external camera sensor connected to CSI or from > built-in test pattern generator. > > Tegra210 supports built-in test pattern generator from CSI to VI. > > This patch adds a v4l2 capture driver with media interface for > Tegra210 built-in CSI to VI test pattern generator. > > This patch includes TPG support only and all the video pipeline > configuration happens through the video device node. > > Acked-by: Thierry Reding <treding@nvidia.com> > Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> > --- > drivers/staging/media/Kconfig | 2 + > drivers/staging/media/Makefile | 1 + > drivers/staging/media/tegra/Kconfig | 13 + > drivers/staging/media/tegra/Makefile | 8 + > drivers/staging/media/tegra/TODO | 10 + > drivers/staging/media/tegra/common.h | 262 ++++++++ > drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ > drivers/staging/media/tegra/csi.h | 149 +++++ > drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ > drivers/staging/media/tegra/tegra210.h | 190 ++++++ > drivers/staging/media/tegra/vi.c | 1132 ++++++++++++++++++++++++++++++++ > drivers/staging/media/tegra/vi.h | 83 +++ > drivers/staging/media/tegra/video.c | 153 +++++ > drivers/staging/media/tegra/video.h | 34 + > 14 files changed, 3352 insertions(+) > create mode 100644 drivers/staging/media/tegra/Kconfig > create mode 100644 drivers/staging/media/tegra/Makefile > create mode 100644 drivers/staging/media/tegra/TODO > create mode 100644 drivers/staging/media/tegra/common.h > create mode 100644 drivers/staging/media/tegra/csi.c > create mode 100644 drivers/staging/media/tegra/csi.h > create mode 100644 drivers/staging/media/tegra/tegra210.c > create mode 100644 drivers/staging/media/tegra/tegra210.h > create mode 100644 drivers/staging/media/tegra/vi.c > create mode 100644 drivers/staging/media/tegra/vi.h > create mode 100644 drivers/staging/media/tegra/video.c > create mode 100644 drivers/staging/media/tegra/video.h With 'make menuconfig' I get this: scripts/kconfig/mconf Kconfig WARNING: unmet direct dependencies detected for TEGRA_HOST1X Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && COMPILE_TEST [=y]) Selected by [y]: - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) This is an x86_64 build with COMPILE_TEST set. I can provide my full .config if you need it. CONFIG_TEGRA_HOST1X=y CONFIG_VIDEO_TEGRA=y Regards, Hans
On 4/23/20 12:48 AM, Hans Verkuil wrote: > External email: Use caution opening links or attachments > > > On 22/04/2020 08:18, Sowjanya Komatineni wrote: >> Tegra210 contains a powerful Video Input (VI) hardware controller >> which can support up to 6 MIPI CSI camera sensors. >> >> Each Tegra CSI port can be one-to-one mapped to VI channel and can >> capture from an external camera sensor connected to CSI or from >> built-in test pattern generator. >> >> Tegra210 supports built-in test pattern generator from CSI to VI. >> >> This patch adds a v4l2 capture driver with media interface for >> Tegra210 built-in CSI to VI test pattern generator. >> >> This patch includes TPG support only and all the video pipeline >> configuration happens through the video device node. >> >> Acked-by: Thierry Reding <treding@nvidia.com> >> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >> --- >> drivers/staging/media/Kconfig | 2 + >> drivers/staging/media/Makefile | 1 + >> drivers/staging/media/tegra/Kconfig | 13 + >> drivers/staging/media/tegra/Makefile | 8 + >> drivers/staging/media/tegra/TODO | 10 + >> drivers/staging/media/tegra/common.h | 262 ++++++++ >> drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ >> drivers/staging/media/tegra/csi.h | 149 +++++ >> drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ >> drivers/staging/media/tegra/tegra210.h | 190 ++++++ >> drivers/staging/media/tegra/vi.c | 1132 ++++++++++++++++++++++++++++++++ >> drivers/staging/media/tegra/vi.h | 83 +++ >> drivers/staging/media/tegra/video.c | 153 +++++ >> drivers/staging/media/tegra/video.h | 34 + >> 14 files changed, 3352 insertions(+) >> create mode 100644 drivers/staging/media/tegra/Kconfig >> create mode 100644 drivers/staging/media/tegra/Makefile >> create mode 100644 drivers/staging/media/tegra/TODO >> create mode 100644 drivers/staging/media/tegra/common.h >> create mode 100644 drivers/staging/media/tegra/csi.c >> create mode 100644 drivers/staging/media/tegra/csi.h >> create mode 100644 drivers/staging/media/tegra/tegra210.c >> create mode 100644 drivers/staging/media/tegra/tegra210.h >> create mode 100644 drivers/staging/media/tegra/vi.c >> create mode 100644 drivers/staging/media/tegra/vi.h >> create mode 100644 drivers/staging/media/tegra/video.c >> create mode 100644 drivers/staging/media/tegra/video.h > With 'make menuconfig' I get this: > > scripts/kconfig/mconf Kconfig > > WARNING: unmet direct dependencies detected for TEGRA_HOST1X > Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && COMPILE_TEST [=y]) > Selected by [y]: > - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) > > This is an x86_64 build with COMPILE_TEST set. I can provide my full .config if you need it. > > CONFIG_TEGRA_HOST1X=y > CONFIG_VIDEO_TEGRA=y > > Regards, > > Hans Hi Hans, In v7, changed Kconfig to remove ARM. But looks like we should limit TEGRA_HOST1X also limits compile to ARM only so running VIDEO_TEGRA on x86_64 shows above warning. We should limit compile to ARM for CONFIG_VIDEO_TEGRA. Will update CONFIG_VIDEO_TEGRA dependency to use ARM && COMPILE_TEST like I had in previous version. Sorry about this. Also, I see some changes went into latest linux-next staging media Kconfig, So, will have my patches on top of today's linux-next. Thanks Sowjanya
23.04.2020 19:50, Sowjanya Komatineni пишет: > > On 4/23/20 12:48 AM, Hans Verkuil wrote: >> External email: Use caution opening links or attachments >> >> >> On 22/04/2020 08:18, Sowjanya Komatineni wrote: >>> Tegra210 contains a powerful Video Input (VI) hardware controller >>> which can support up to 6 MIPI CSI camera sensors. >>> >>> Each Tegra CSI port can be one-to-one mapped to VI channel and can >>> capture from an external camera sensor connected to CSI or from >>> built-in test pattern generator. >>> >>> Tegra210 supports built-in test pattern generator from CSI to VI. >>> >>> This patch adds a v4l2 capture driver with media interface for >>> Tegra210 built-in CSI to VI test pattern generator. >>> >>> This patch includes TPG support only and all the video pipeline >>> configuration happens through the video device node. >>> >>> Acked-by: Thierry Reding <treding@nvidia.com> >>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >>> --- >>> drivers/staging/media/Kconfig | 2 + >>> drivers/staging/media/Makefile | 1 + >>> drivers/staging/media/tegra/Kconfig | 13 + >>> drivers/staging/media/tegra/Makefile | 8 + >>> drivers/staging/media/tegra/TODO | 10 + >>> drivers/staging/media/tegra/common.h | 262 ++++++++ >>> drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ >>> drivers/staging/media/tegra/csi.h | 149 +++++ >>> drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ >>> drivers/staging/media/tegra/tegra210.h | 190 ++++++ >>> drivers/staging/media/tegra/vi.c | 1132 >>> ++++++++++++++++++++++++++++++++ >>> drivers/staging/media/tegra/vi.h | 83 +++ >>> drivers/staging/media/tegra/video.c | 153 +++++ >>> drivers/staging/media/tegra/video.h | 34 + >>> 14 files changed, 3352 insertions(+) >>> create mode 100644 drivers/staging/media/tegra/Kconfig >>> create mode 100644 drivers/staging/media/tegra/Makefile >>> create mode 100644 drivers/staging/media/tegra/TODO >>> create mode 100644 drivers/staging/media/tegra/common.h >>> create mode 100644 drivers/staging/media/tegra/csi.c >>> create mode 100644 drivers/staging/media/tegra/csi.h >>> create mode 100644 drivers/staging/media/tegra/tegra210.c >>> create mode 100644 drivers/staging/media/tegra/tegra210.h >>> create mode 100644 drivers/staging/media/tegra/vi.c >>> create mode 100644 drivers/staging/media/tegra/vi.h >>> create mode 100644 drivers/staging/media/tegra/video.c >>> create mode 100644 drivers/staging/media/tegra/video.h >> With 'make menuconfig' I get this: >> >> scripts/kconfig/mconf Kconfig >> >> WARNING: unmet direct dependencies detected for TEGRA_HOST1X >> Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && >> COMPILE_TEST [=y]) >> Selected by [y]: >> - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && >> MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) >> >> This is an x86_64 build with COMPILE_TEST set. I can provide my full >> .config if you need it. >> >> CONFIG_TEGRA_HOST1X=y >> CONFIG_VIDEO_TEGRA=y >> >> Regards, >> >> Hans > > Hi Hans, > > In v7, changed Kconfig to remove ARM. But looks like we should limit > > TEGRA_HOST1X also limits compile to ARM only so running VIDEO_TEGRA on > x86_64 shows above warning. > > We should limit compile to ARM for CONFIG_VIDEO_TEGRA. > > Will update CONFIG_VIDEO_TEGRA dependency to use ARM && COMPILE_TEST > like I had in previous version. Sorry about this. > > > Also, I see some changes went into latest linux-next staging media > Kconfig, So, will have my patches on top of today's linux-next. VIDEO_TEGRA should depend on TEGRA_HOST1X and not select it. depends on (ARCH_TEGRA && TEGRA_HOST1X) || COMPILE_TEST
On 4/23/20 3:55 PM, Dmitry Osipenko wrote: > External email: Use caution opening links or attachments > > > 23.04.2020 19:50, Sowjanya Komatineni пишет: >> On 4/23/20 12:48 AM, Hans Verkuil wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> On 22/04/2020 08:18, Sowjanya Komatineni wrote: >>>> Tegra210 contains a powerful Video Input (VI) hardware controller >>>> which can support up to 6 MIPI CSI camera sensors. >>>> >>>> Each Tegra CSI port can be one-to-one mapped to VI channel and can >>>> capture from an external camera sensor connected to CSI or from >>>> built-in test pattern generator. >>>> >>>> Tegra210 supports built-in test pattern generator from CSI to VI. >>>> >>>> This patch adds a v4l2 capture driver with media interface for >>>> Tegra210 built-in CSI to VI test pattern generator. >>>> >>>> This patch includes TPG support only and all the video pipeline >>>> configuration happens through the video device node. >>>> >>>> Acked-by: Thierry Reding <treding@nvidia.com> >>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >>>> --- >>>> drivers/staging/media/Kconfig | 2 + >>>> drivers/staging/media/Makefile | 1 + >>>> drivers/staging/media/tegra/Kconfig | 13 + >>>> drivers/staging/media/tegra/Makefile | 8 + >>>> drivers/staging/media/tegra/TODO | 10 + >>>> drivers/staging/media/tegra/common.h | 262 ++++++++ >>>> drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ >>>> drivers/staging/media/tegra/csi.h | 149 +++++ >>>> drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ >>>> drivers/staging/media/tegra/tegra210.h | 190 ++++++ >>>> drivers/staging/media/tegra/vi.c | 1132 >>>> ++++++++++++++++++++++++++++++++ >>>> drivers/staging/media/tegra/vi.h | 83 +++ >>>> drivers/staging/media/tegra/video.c | 153 +++++ >>>> drivers/staging/media/tegra/video.h | 34 + >>>> 14 files changed, 3352 insertions(+) >>>> create mode 100644 drivers/staging/media/tegra/Kconfig >>>> create mode 100644 drivers/staging/media/tegra/Makefile >>>> create mode 100644 drivers/staging/media/tegra/TODO >>>> create mode 100644 drivers/staging/media/tegra/common.h >>>> create mode 100644 drivers/staging/media/tegra/csi.c >>>> create mode 100644 drivers/staging/media/tegra/csi.h >>>> create mode 100644 drivers/staging/media/tegra/tegra210.c >>>> create mode 100644 drivers/staging/media/tegra/tegra210.h >>>> create mode 100644 drivers/staging/media/tegra/vi.c >>>> create mode 100644 drivers/staging/media/tegra/vi.h >>>> create mode 100644 drivers/staging/media/tegra/video.c >>>> create mode 100644 drivers/staging/media/tegra/video.h >>> With 'make menuconfig' I get this: >>> >>> scripts/kconfig/mconf Kconfig >>> >>> WARNING: unmet direct dependencies detected for TEGRA_HOST1X >>> Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && >>> COMPILE_TEST [=y]) >>> Selected by [y]: >>> - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && >>> MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) >>> >>> This is an x86_64 build with COMPILE_TEST set. I can provide my full >>> .config if you need it. >>> >>> CONFIG_TEGRA_HOST1X=y >>> CONFIG_VIDEO_TEGRA=y >>> >>> Regards, >>> >>> Hans >> Hi Hans, >> >> In v7, changed Kconfig to remove ARM. But looks like we should limit >> >> TEGRA_HOST1X also limits compile to ARM only so running VIDEO_TEGRA on >> x86_64 shows above warning. >> >> We should limit compile to ARM for CONFIG_VIDEO_TEGRA. >> >> Will update CONFIG_VIDEO_TEGRA dependency to use ARM && COMPILE_TEST >> like I had in previous version. Sorry about this. >> >> >> Also, I see some changes went into latest linux-next staging media >> Kconfig, So, will have my patches on top of today's linux-next. > VIDEO_TEGRA should depend on TEGRA_HOST1X and not select it. > > depends on (ARCH_TEGRA && TEGRA_HOST1X) || COMPILE_TEST Was selecting it to auto-select Tegra host1x when video_tegra is enabled. Yes, can use depends on
24.04.2020 01:59, Sowjanya Komatineni пишет: > > On 4/23/20 3:55 PM, Dmitry Osipenko wrote: >> External email: Use caution opening links or attachments >> >> >> 23.04.2020 19:50, Sowjanya Komatineni пишет: >>> On 4/23/20 12:48 AM, Hans Verkuil wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> On 22/04/2020 08:18, Sowjanya Komatineni wrote: >>>>> Tegra210 contains a powerful Video Input (VI) hardware controller >>>>> which can support up to 6 MIPI CSI camera sensors. >>>>> >>>>> Each Tegra CSI port can be one-to-one mapped to VI channel and can >>>>> capture from an external camera sensor connected to CSI or from >>>>> built-in test pattern generator. >>>>> >>>>> Tegra210 supports built-in test pattern generator from CSI to VI. >>>>> >>>>> This patch adds a v4l2 capture driver with media interface for >>>>> Tegra210 built-in CSI to VI test pattern generator. >>>>> >>>>> This patch includes TPG support only and all the video pipeline >>>>> configuration happens through the video device node. >>>>> >>>>> Acked-by: Thierry Reding <treding@nvidia.com> >>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >>>>> --- >>>>> drivers/staging/media/Kconfig | 2 + >>>>> drivers/staging/media/Makefile | 1 + >>>>> drivers/staging/media/tegra/Kconfig | 13 + >>>>> drivers/staging/media/tegra/Makefile | 8 + >>>>> drivers/staging/media/tegra/TODO | 10 + >>>>> drivers/staging/media/tegra/common.h | 262 ++++++++ >>>>> drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ >>>>> drivers/staging/media/tegra/csi.h | 149 +++++ >>>>> drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ >>>>> drivers/staging/media/tegra/tegra210.h | 190 ++++++ >>>>> drivers/staging/media/tegra/vi.c | 1132 >>>>> ++++++++++++++++++++++++++++++++ >>>>> drivers/staging/media/tegra/vi.h | 83 +++ >>>>> drivers/staging/media/tegra/video.c | 153 +++++ >>>>> drivers/staging/media/tegra/video.h | 34 + >>>>> 14 files changed, 3352 insertions(+) >>>>> create mode 100644 drivers/staging/media/tegra/Kconfig >>>>> create mode 100644 drivers/staging/media/tegra/Makefile >>>>> create mode 100644 drivers/staging/media/tegra/TODO >>>>> create mode 100644 drivers/staging/media/tegra/common.h >>>>> create mode 100644 drivers/staging/media/tegra/csi.c >>>>> create mode 100644 drivers/staging/media/tegra/csi.h >>>>> create mode 100644 drivers/staging/media/tegra/tegra210.c >>>>> create mode 100644 drivers/staging/media/tegra/tegra210.h >>>>> create mode 100644 drivers/staging/media/tegra/vi.c >>>>> create mode 100644 drivers/staging/media/tegra/vi.h >>>>> create mode 100644 drivers/staging/media/tegra/video.c >>>>> create mode 100644 drivers/staging/media/tegra/video.h >>>> With 'make menuconfig' I get this: >>>> >>>> scripts/kconfig/mconf Kconfig >>>> >>>> WARNING: unmet direct dependencies detected for TEGRA_HOST1X >>>> Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && >>>> COMPILE_TEST [=y]) >>>> Selected by [y]: >>>> - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && >>>> MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) >>>> >>>> This is an x86_64 build with COMPILE_TEST set. I can provide my full >>>> .config if you need it. >>>> >>>> CONFIG_TEGRA_HOST1X=y >>>> CONFIG_VIDEO_TEGRA=y >>>> >>>> Regards, >>>> >>>> Hans >>> Hi Hans, >>> >>> In v7, changed Kconfig to remove ARM. But looks like we should limit >>> >>> TEGRA_HOST1X also limits compile to ARM only so running VIDEO_TEGRA on >>> x86_64 shows above warning. >>> >>> We should limit compile to ARM for CONFIG_VIDEO_TEGRA. >>> >>> Will update CONFIG_VIDEO_TEGRA dependency to use ARM && COMPILE_TEST >>> like I had in previous version. Sorry about this. >>> >>> >>> Also, I see some changes went into latest linux-next staging media >>> Kconfig, So, will have my patches on top of today's linux-next. >> VIDEO_TEGRA should depend on TEGRA_HOST1X and not select it. >> >> depends on (ARCH_TEGRA && TEGRA_HOST1X) || COMPILE_TEST > > Was selecting it to auto-select Tegra host1x when video_tegra is enabled. > > Yes, can use depends on > BTW, perhaps ARCH_TEGRA and COMPILE_TEST aren't needed since TEGRA_HOST1X already depends on them, so just: depends on TEGRA_HOST1X
24.04.2020 02:03, Dmitry Osipenko пишет: > 24.04.2020 01:59, Sowjanya Komatineni пишет: >> >> On 4/23/20 3:55 PM, Dmitry Osipenko wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> 23.04.2020 19:50, Sowjanya Komatineni пишет: >>>> On 4/23/20 12:48 AM, Hans Verkuil wrote: >>>>> External email: Use caution opening links or attachments >>>>> >>>>> >>>>> On 22/04/2020 08:18, Sowjanya Komatineni wrote: >>>>>> Tegra210 contains a powerful Video Input (VI) hardware controller >>>>>> which can support up to 6 MIPI CSI camera sensors. >>>>>> >>>>>> Each Tegra CSI port can be one-to-one mapped to VI channel and can >>>>>> capture from an external camera sensor connected to CSI or from >>>>>> built-in test pattern generator. >>>>>> >>>>>> Tegra210 supports built-in test pattern generator from CSI to VI. >>>>>> >>>>>> This patch adds a v4l2 capture driver with media interface for >>>>>> Tegra210 built-in CSI to VI test pattern generator. >>>>>> >>>>>> This patch includes TPG support only and all the video pipeline >>>>>> configuration happens through the video device node. >>>>>> >>>>>> Acked-by: Thierry Reding <treding@nvidia.com> >>>>>> Signed-off-by: Sowjanya Komatineni <skomatineni@nvidia.com> >>>>>> --- >>>>>> drivers/staging/media/Kconfig | 2 + >>>>>> drivers/staging/media/Makefile | 1 + >>>>>> drivers/staging/media/tegra/Kconfig | 13 + >>>>>> drivers/staging/media/tegra/Makefile | 8 + >>>>>> drivers/staging/media/tegra/TODO | 10 + >>>>>> drivers/staging/media/tegra/common.h | 262 ++++++++ >>>>>> drivers/staging/media/tegra/csi.c | 606 +++++++++++++++++ >>>>>> drivers/staging/media/tegra/csi.h | 149 +++++ >>>>>> drivers/staging/media/tegra/tegra210.c | 709 ++++++++++++++++++++ >>>>>> drivers/staging/media/tegra/tegra210.h | 190 ++++++ >>>>>> drivers/staging/media/tegra/vi.c | 1132 >>>>>> ++++++++++++++++++++++++++++++++ >>>>>> drivers/staging/media/tegra/vi.h | 83 +++ >>>>>> drivers/staging/media/tegra/video.c | 153 +++++ >>>>>> drivers/staging/media/tegra/video.h | 34 + >>>>>> 14 files changed, 3352 insertions(+) >>>>>> create mode 100644 drivers/staging/media/tegra/Kconfig >>>>>> create mode 100644 drivers/staging/media/tegra/Makefile >>>>>> create mode 100644 drivers/staging/media/tegra/TODO >>>>>> create mode 100644 drivers/staging/media/tegra/common.h >>>>>> create mode 100644 drivers/staging/media/tegra/csi.c >>>>>> create mode 100644 drivers/staging/media/tegra/csi.h >>>>>> create mode 100644 drivers/staging/media/tegra/tegra210.c >>>>>> create mode 100644 drivers/staging/media/tegra/tegra210.h >>>>>> create mode 100644 drivers/staging/media/tegra/vi.c >>>>>> create mode 100644 drivers/staging/media/tegra/vi.h >>>>>> create mode 100644 drivers/staging/media/tegra/video.c >>>>>> create mode 100644 drivers/staging/media/tegra/video.h >>>>> With 'make menuconfig' I get this: >>>>> >>>>> scripts/kconfig/mconf Kconfig >>>>> >>>>> WARNING: unmet direct dependencies detected for TEGRA_HOST1X >>>>> Depends on [n]: HAS_IOMEM [=y] && (ARCH_TEGRA || ARM && >>>>> COMPILE_TEST [=y]) >>>>> Selected by [y]: >>>>> - VIDEO_TEGRA [=y] && STAGING [=y] && STAGING_MEDIA [=y] && >>>>> MEDIA_SUPPORT [=y] && (ARCH_TEGRA || COMPILE_TEST [=y]) >>>>> >>>>> This is an x86_64 build with COMPILE_TEST set. I can provide my full >>>>> .config if you need it. >>>>> >>>>> CONFIG_TEGRA_HOST1X=y >>>>> CONFIG_VIDEO_TEGRA=y >>>>> >>>>> Regards, >>>>> >>>>> Hans >>>> Hi Hans, >>>> >>>> In v7, changed Kconfig to remove ARM. But looks like we should limit >>>> >>>> TEGRA_HOST1X also limits compile to ARM only so running VIDEO_TEGRA on >>>> x86_64 shows above warning. >>>> >>>> We should limit compile to ARM for CONFIG_VIDEO_TEGRA. >>>> >>>> Will update CONFIG_VIDEO_TEGRA dependency to use ARM && COMPILE_TEST >>>> like I had in previous version. Sorry about this. >>>> >>>> >>>> Also, I see some changes went into latest linux-next staging media >>>> Kconfig, So, will have my patches on top of today's linux-next. >>> VIDEO_TEGRA should depend on TEGRA_HOST1X and not select it. >>> >>> depends on (ARCH_TEGRA && TEGRA_HOST1X) || COMPILE_TEST >> >> Was selecting it to auto-select Tegra host1x when video_tegra is enabled. >> >> Yes, can use depends on >> > > BTW, perhaps ARCH_TEGRA and COMPILE_TEST aren't needed since > TEGRA_HOST1X already depends on them, so just: > > depends on TEGRA_HOST1X > Although, I guess TEGRA_HOST1X isn't really needed for compile-testing, and thus, it won't hurt to drop that dependency for testing: depends on TEGRA_HOST1X || COMPILE_TEST
22.04.2020 09:18, Sowjanya Komatineni пишет: > +static int chan_capture_kthread_start(void *data) > +{ > + struct tegra_vi_channel *chan = data; > + struct tegra_channel_buffer *buf; > + int err = 0; > + > + set_freezable(); > + > + while (1) { > + try_to_freeze(); > + > + wait_event_interruptible(chan->start_wait, > + !list_empty(&chan->capture) || > + kthread_should_stop()); > + > + if (kthread_should_stop()) > + break; > + > + /* > + * Source is not streaming if error is non-zero. > + * So, do not dequeue buffers on capture error. > + */ > + if (err) > + continue; This will result in an endless loop, I suppose it wasn't the intention.
On 4/23/20 4:16 PM, Dmitry Osipenko wrote: > External email: Use caution opening links or attachments > > > 22.04.2020 09:18, Sowjanya Komatineni пишет: >> +static int chan_capture_kthread_start(void *data) >> +{ >> + struct tegra_vi_channel *chan = data; >> + struct tegra_channel_buffer *buf; >> + int err = 0; >> + >> + set_freezable(); >> + >> + while (1) { >> + try_to_freeze(); >> + >> + wait_event_interruptible(chan->start_wait, >> + !list_empty(&chan->capture) || >> + kthread_should_stop()); >> + >> + if (kthread_should_stop()) >> + break; >> + >> + /* >> + * Source is not streaming if error is non-zero. >> + * So, do not dequeue buffers on capture error. >> + */ >> + if (err) >> + continue; > This will result in an endless loop, I suppose it wasn't the intention. no it will not. on error we report vb2_queue_error which will do streaming stop request. So thread will be stopped on streaming stop request thru kthread stop signal
On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: > > On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >> External email: Use caution opening links or attachments >> >> >> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>> +static int chan_capture_kthread_start(void *data) >>> +{ >>> + struct tegra_vi_channel *chan = data; >>> + struct tegra_channel_buffer *buf; >>> + int err = 0; >>> + >>> + set_freezable(); >>> + >>> + while (1) { >>> + try_to_freeze(); >>> + >>> + wait_event_interruptible(chan->start_wait, >>> + !list_empty(&chan->capture) || >>> + kthread_should_stop()); >>> + >>> + if (kthread_should_stop()) >>> + break; >>> + >>> + /* >>> + * Source is not streaming if error is non-zero. >>> + * So, do not dequeue buffers on capture error. >>> + */ >>> + if (err) >>> + continue; >> This will result in an endless loop, I suppose it wasn't the intention. > > no it will not. on error we report vb2_queue_error which will do > streaming stop request. > > So thread will be stopped on streaming stop request thru kthread stop > signal To be clear on error it reports vb2 queue error and waits for stop streaming to happen
24.04.2020 02:20, Sowjanya Komatineni пишет: > > On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >> >> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>> +static int chan_capture_kthread_start(void *data) >>>> +{ >>>> + struct tegra_vi_channel *chan = data; >>>> + struct tegra_channel_buffer *buf; >>>> + int err = 0; >>>> + >>>> + set_freezable(); >>>> + >>>> + while (1) { >>>> + try_to_freeze(); >>>> + >>>> + wait_event_interruptible(chan->start_wait, >>>> + !list_empty(&chan->capture) || >>>> + kthread_should_stop()); >>>> + >>>> + if (kthread_should_stop()) >>>> + break; >>>> + >>>> + /* >>>> + * Source is not streaming if error is non-zero. >>>> + * So, do not dequeue buffers on capture error. >>>> + */ >>>> + if (err) >>>> + continue; >>> This will result in an endless loop, I suppose it wasn't the intention. >> >> no it will not. on error we report vb2_queue_error which will do >> streaming stop request. >> >> So thread will be stopped on streaming stop request thru kthread stop >> signal > To be clear on error it reports vb2 queue error and waits for stop > streaming to happen If thread should exit on error, then it should do it on the actual error. Otherwise it looks very error-prone.
On 4/23/20 4:25 PM, Dmitry Osipenko wrote: > External email: Use caution opening links or attachments > > > 24.04.2020 02:20, Sowjanya Komatineni пишет: >> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>> +static int chan_capture_kthread_start(void *data) >>>>> +{ >>>>> + struct tegra_vi_channel *chan = data; >>>>> + struct tegra_channel_buffer *buf; >>>>> + int err = 0; >>>>> + >>>>> + set_freezable(); >>>>> + >>>>> + while (1) { >>>>> + try_to_freeze(); >>>>> + >>>>> + wait_event_interruptible(chan->start_wait, >>>>> + !list_empty(&chan->capture) || >>>>> + kthread_should_stop()); >>>>> + >>>>> + if (kthread_should_stop()) >>>>> + break; >>>>> + >>>>> + /* >>>>> + * Source is not streaming if error is non-zero. >>>>> + * So, do not dequeue buffers on capture error. >>>>> + */ >>>>> + if (err) >>>>> + continue; >>>> This will result in an endless loop, I suppose it wasn't the intention. >>> no it will not. on error we report vb2_queue_error which will do >>> streaming stop request. >>> >>> So thread will be stopped on streaming stop request thru kthread stop >>> signal >> To be clear on error it reports vb2 queue error and waits for stop >> streaming to happen > If thread should exit on error, then it should do it on the actual > error. Otherwise it looks very error-prone. When v4l2 drivers indicate fatal error through vb2_queue_error, queue error flag is set and wakes up all processes waiting on queue along with polling reporting EPOLLERR and also reporting error for queuing and dequeuing buffers. Stream stop will surely happen which stops the thread.
24.04.2020 02:50, Sowjanya Komatineni пишет: > > On 4/23/20 4:25 PM, Dmitry Osipenko wrote: >> External email: Use caution opening links or attachments >> >> >> 24.04.2020 02:20, Sowjanya Komatineni пишет: >>> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>>> External email: Use caution opening links or attachments >>>>> >>>>> >>>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>>> +static int chan_capture_kthread_start(void *data) >>>>>> +{ >>>>>> + struct tegra_vi_channel *chan = data; >>>>>> + struct tegra_channel_buffer *buf; >>>>>> + int err = 0; >>>>>> + >>>>>> + set_freezable(); >>>>>> + >>>>>> + while (1) { >>>>>> + try_to_freeze(); >>>>>> + >>>>>> + wait_event_interruptible(chan->start_wait, >>>>>> + !list_empty(&chan->capture) || >>>>>> + kthread_should_stop()); >>>>>> + >>>>>> + if (kthread_should_stop()) >>>>>> + break; >>>>>> + >>>>>> + /* >>>>>> + * Source is not streaming if error is non-zero. >>>>>> + * So, do not dequeue buffers on capture error. >>>>>> + */ >>>>>> + if (err) >>>>>> + continue; >>>>> This will result in an endless loop, I suppose it wasn't the >>>>> intention. >>>> no it will not. on error we report vb2_queue_error which will do >>>> streaming stop request. >>>> >>>> So thread will be stopped on streaming stop request thru kthread stop >>>> signal >>> To be clear on error it reports vb2 queue error and waits for stop >>> streaming to happen >> If thread should exit on error, then it should do it on the actual >> error. Otherwise it looks very error-prone. > When v4l2 drivers indicate fatal error through vb2_queue_error, queue > error flag is set and wakes up all processes waiting on queue along > with polling reporting EPOLLERR and also reporting error for queuing > and dequeuing buffers. Stream stop will surely happen which stops the > thread. This doesn't explain what is the point of continuing to loop instead of exiting immediately on error.
On 4/23/20 5:42 PM, Dmitry Osipenko wrote: > External email: Use caution opening links or attachments > > > 24.04.2020 02:50, Sowjanya Komatineni пишет: >> On 4/23/20 4:25 PM, Dmitry Osipenko wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> 24.04.2020 02:20, Sowjanya Komatineni пишет: >>>> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>>>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>>>> External email: Use caution opening links or attachments >>>>>> >>>>>> >>>>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>>>> +static int chan_capture_kthread_start(void *data) >>>>>>> +{ >>>>>>> + struct tegra_vi_channel *chan = data; >>>>>>> + struct tegra_channel_buffer *buf; >>>>>>> + int err = 0; >>>>>>> + >>>>>>> + set_freezable(); >>>>>>> + >>>>>>> + while (1) { >>>>>>> + try_to_freeze(); >>>>>>> + >>>>>>> + wait_event_interruptible(chan->start_wait, >>>>>>> + !list_empty(&chan->capture) || >>>>>>> + kthread_should_stop()); >>>>>>> + >>>>>>> + if (kthread_should_stop()) >>>>>>> + break; >>>>>>> + >>>>>>> + /* >>>>>>> + * Source is not streaming if error is non-zero. >>>>>>> + * So, do not dequeue buffers on capture error. >>>>>>> + */ >>>>>>> + if (err) >>>>>>> + continue; >>>>>> This will result in an endless loop, I suppose it wasn't the >>>>>> intention. >>>>> no it will not. on error we report vb2_queue_error which will do >>>>> streaming stop request. >>>>> >>>>> So thread will be stopped on streaming stop request thru kthread stop >>>>> signal >>>> To be clear on error it reports vb2 queue error and waits for stop >>>> streaming to happen >>> If thread should exit on error, then it should do it on the actual >>> error. Otherwise it looks very error-prone. >> When v4l2 drivers indicate fatal error through vb2_queue_error, queue >> error flag is set and wakes up all processes waiting on queue along >> with polling reporting EPOLLERR and also reporting error for queuing >> and dequeuing buffers. Stream stop will surely happen which stops the >> thread. > This doesn't explain what is the point of continuing to loop instead of > exiting immediately on error. We are using 2 threads and when capture start error happens, we can stop capture_start thread immediately but capture_finish thread will still run for any outstanding buffers. So, as it makes no diff stopping both threads during stream stop which will definitely happen on error and when we don't dequeue buffers
On 4/23/20 5:51 PM, Sowjanya Komatineni wrote: > > On 4/23/20 5:42 PM, Dmitry Osipenko wrote: >> External email: Use caution opening links or attachments >> >> >> 24.04.2020 02:50, Sowjanya Komatineni пишет: >>> On 4/23/20 4:25 PM, Dmitry Osipenko wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> 24.04.2020 02:20, Sowjanya Komatineni пишет: >>>>> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>>>>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>>>>> External email: Use caution opening links or attachments >>>>>>> >>>>>>> >>>>>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>>>>> +static int chan_capture_kthread_start(void *data) >>>>>>>> +{ >>>>>>>> + struct tegra_vi_channel *chan = data; >>>>>>>> + struct tegra_channel_buffer *buf; >>>>>>>> + int err = 0; >>>>>>>> + >>>>>>>> + set_freezable(); >>>>>>>> + >>>>>>>> + while (1) { >>>>>>>> + try_to_freeze(); >>>>>>>> + >>>>>>>> + wait_event_interruptible(chan->start_wait, >>>>>>>> + !list_empty(&chan->capture) || >>>>>>>> + kthread_should_stop()); >>>>>>>> + >>>>>>>> + if (kthread_should_stop()) >>>>>>>> + break; >>>>>>>> + >>>>>>>> + /* >>>>>>>> + * Source is not streaming if error is non-zero. >>>>>>>> + * So, do not dequeue buffers on capture error. >>>>>>>> + */ >>>>>>>> + if (err) >>>>>>>> + continue; >>>>>>> This will result in an endless loop, I suppose it wasn't the >>>>>>> intention. >>>>>> no it will not. on error we report vb2_queue_error which will do >>>>>> streaming stop request. >>>>>> >>>>>> So thread will be stopped on streaming stop request thru kthread >>>>>> stop >>>>>> signal >>>>> To be clear on error it reports vb2 queue error and waits for stop >>>>> streaming to happen >>>> If thread should exit on error, then it should do it on the actual >>>> error. Otherwise it looks very error-prone. >>> When v4l2 drivers indicate fatal error through vb2_queue_error, queue >>> error flag is set and wakes up all processes waiting on queue along >>> with polling reporting EPOLLERR and also reporting error for queuing >>> and dequeuing buffers. Stream stop will surely happen which stops the >>> thread. >> This doesn't explain what is the point of continuing to loop instead of >> exiting immediately on error. > > We are using 2 threads and when capture start error happens, we can > stop capture_start thread immediately but capture_finish thread will > still run for any outstanding buffers. > > So, as it makes no diff stopping both threads during stream stop which > will definitely happen on error and when we don't dequeue buffers > Also there will be an issue if we break on error immediately during stop_streaming -> kthread_stop() As stop streaming can happen any time, we do kthread_stop and in case of error if we stop thread and on stop streaming kthread_stop might crash as kthread_stop can only be called on running thread
24.04.2020 04:08, Sowjanya Komatineni пишет: > > On 4/23/20 5:51 PM, Sowjanya Komatineni wrote: >> >> On 4/23/20 5:42 PM, Dmitry Osipenko wrote: >>> External email: Use caution opening links or attachments >>> >>> >>> 24.04.2020 02:50, Sowjanya Komatineni пишет: >>>> On 4/23/20 4:25 PM, Dmitry Osipenko wrote: >>>>> External email: Use caution opening links or attachments >>>>> >>>>> >>>>> 24.04.2020 02:20, Sowjanya Komatineni пишет: >>>>>> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>>>>>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>>>>>> External email: Use caution opening links or attachments >>>>>>>> >>>>>>>> >>>>>>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>>>>>> +static int chan_capture_kthread_start(void *data) >>>>>>>>> +{ >>>>>>>>> + struct tegra_vi_channel *chan = data; >>>>>>>>> + struct tegra_channel_buffer *buf; >>>>>>>>> + int err = 0; >>>>>>>>> + >>>>>>>>> + set_freezable(); >>>>>>>>> + >>>>>>>>> + while (1) { >>>>>>>>> + try_to_freeze(); >>>>>>>>> + >>>>>>>>> + wait_event_interruptible(chan->start_wait, >>>>>>>>> + !list_empty(&chan->capture) || >>>>>>>>> + kthread_should_stop()); >>>>>>>>> + >>>>>>>>> + if (kthread_should_stop()) >>>>>>>>> + break; >>>>>>>>> + >>>>>>>>> + /* >>>>>>>>> + * Source is not streaming if error is non-zero. >>>>>>>>> + * So, do not dequeue buffers on capture error. >>>>>>>>> + */ >>>>>>>>> + if (err) >>>>>>>>> + continue; >>>>>>>> This will result in an endless loop, I suppose it wasn't the >>>>>>>> intention. >>>>>>> no it will not. on error we report vb2_queue_error which will do >>>>>>> streaming stop request. >>>>>>> >>>>>>> So thread will be stopped on streaming stop request thru kthread >>>>>>> stop >>>>>>> signal >>>>>> To be clear on error it reports vb2 queue error and waits for stop >>>>>> streaming to happen >>>>> If thread should exit on error, then it should do it on the actual >>>>> error. Otherwise it looks very error-prone. >>>> When v4l2 drivers indicate fatal error through vb2_queue_error, queue >>>> error flag is set and wakes up all processes waiting on queue along >>>> with polling reporting EPOLLERR and also reporting error for queuing >>>> and dequeuing buffers. Stream stop will surely happen which stops the >>>> thread. >>> This doesn't explain what is the point of continuing to loop instead of >>> exiting immediately on error. >> >> We are using 2 threads and when capture start error happens, we can >> stop capture_start thread immediately but capture_finish thread will >> still run for any outstanding buffers. >> >> So, as it makes no diff stopping both threads during stream stop which >> will definitely happen on error and when we don't dequeue buffers >> > Also there will be an issue if we break on error immediately during > stop_streaming -> kthread_stop() > > As stop streaming can happen any time, we do kthread_stop and in case of > error if we stop thread and on stop streaming kthread_stop might crash > as kthread_stop can only be called on running thread > This a better explanation, but still it's not good that there could be a busy loop within the thread. Should be better to sleep if error is set. wait_event_interruptible(chan->start_wait, (!err && !list_empty(&chan->capture)) || kthread_should_stop());
On 4/23/20 7:09 PM, Dmitry Osipenko wrote: > External email: Use caution opening links or attachments > > > 24.04.2020 04:08, Sowjanya Komatineni пишет: >> On 4/23/20 5:51 PM, Sowjanya Komatineni wrote: >>> On 4/23/20 5:42 PM, Dmitry Osipenko wrote: >>>> External email: Use caution opening links or attachments >>>> >>>> >>>> 24.04.2020 02:50, Sowjanya Komatineni пишет: >>>>> On 4/23/20 4:25 PM, Dmitry Osipenko wrote: >>>>>> External email: Use caution opening links or attachments >>>>>> >>>>>> >>>>>> 24.04.2020 02:20, Sowjanya Komatineni пишет: >>>>>>> On 4/23/20 4:19 PM, Sowjanya Komatineni wrote: >>>>>>>> On 4/23/20 4:16 PM, Dmitry Osipenko wrote: >>>>>>>>> External email: Use caution opening links or attachments >>>>>>>>> >>>>>>>>> >>>>>>>>> 22.04.2020 09:18, Sowjanya Komatineni пишет: >>>>>>>>>> +static int chan_capture_kthread_start(void *data) >>>>>>>>>> +{ >>>>>>>>>> + struct tegra_vi_channel *chan = data; >>>>>>>>>> + struct tegra_channel_buffer *buf; >>>>>>>>>> + int err = 0; >>>>>>>>>> + >>>>>>>>>> + set_freezable(); >>>>>>>>>> + >>>>>>>>>> + while (1) { >>>>>>>>>> + try_to_freeze(); >>>>>>>>>> + >>>>>>>>>> + wait_event_interruptible(chan->start_wait, >>>>>>>>>> + !list_empty(&chan->capture) || >>>>>>>>>> + kthread_should_stop()); >>>>>>>>>> + >>>>>>>>>> + if (kthread_should_stop()) >>>>>>>>>> + break; >>>>>>>>>> + >>>>>>>>>> + /* >>>>>>>>>> + * Source is not streaming if error is non-zero. >>>>>>>>>> + * So, do not dequeue buffers on capture error. >>>>>>>>>> + */ >>>>>>>>>> + if (err) >>>>>>>>>> + continue; >>>>>>>>> This will result in an endless loop, I suppose it wasn't the >>>>>>>>> intention. >>>>>>>> no it will not. on error we report vb2_queue_error which will do >>>>>>>> streaming stop request. >>>>>>>> >>>>>>>> So thread will be stopped on streaming stop request thru kthread >>>>>>>> stop >>>>>>>> signal >>>>>>> To be clear on error it reports vb2 queue error and waits for stop >>>>>>> streaming to happen >>>>>> If thread should exit on error, then it should do it on the actual >>>>>> error. Otherwise it looks very error-prone. >>>>> When v4l2 drivers indicate fatal error through vb2_queue_error, queue >>>>> error flag is set and wakes up all processes waiting on queue along >>>>> with polling reporting EPOLLERR and also reporting error for queuing >>>>> and dequeuing buffers. Stream stop will surely happen which stops the >>>>> thread. >>>> This doesn't explain what is the point of continuing to loop instead of >>>> exiting immediately on error. >>> We are using 2 threads and when capture start error happens, we can >>> stop capture_start thread immediately but capture_finish thread will >>> still run for any outstanding buffers. >>> >>> So, as it makes no diff stopping both threads during stream stop which >>> will definitely happen on error and when we don't dequeue buffers >>> >> Also there will be an issue if we break on error immediately during >> stop_streaming -> kthread_stop() >> >> As stop streaming can happen any time, we do kthread_stop and in case of >> error if we stop thread and on stop streaming kthread_stop might crash >> as kthread_stop can only be called on running thread >> > This a better explanation, but still it's not good that there could be a > busy loop within the thread. > > Should be better to sleep if error is set. > > wait_event_interruptible(chan->start_wait, > (!err && !list_empty(&chan->capture)) || > kthread_should_stop()); ok, will add err to wait condition to let it sleep