[0/3] media: vimc: Add support for GBR and BGR formats on source pad of debayer

  The objective of this series is to add support for GBR and BGR media bus formats
for the source pad of debayer subdevices of the vimc driver.

Since the GBR media bus code doesn't have a corresponding pixelformat, it needed
to use the pixelformat of another bus code.

The first patch makes it possible to have multiple media bus codes mapping to
the same pixelformat.

The second patch adds the GBR media bus code, using the RGB pixelformat.

The third patch adds support for GBR and BGR media bus formats on the source
pad of the debayer subdevice.

This patch series passed all tests of v4l2-compliance:
$ compliance_git -m /dev/media0
v4l2-compliance SHA: c4a62f26c5c3ecd856ca10cf2f0d35d100283d7f, 64 bits, 64-bit time_t

Grand Total for vimc device /dev/media0: 461, Succeeded: 461, Failed: 0, Warnings: 0

Nícolas F. R. A. Prado (3):
  media: vimc: Support multiple buscodes for each pixelformat
  media: vimc: Add GBR media bus code
  media: vimc: deb: Add support for GBR and BGR bus formats on source
    pad

 drivers/media/platform/vimc/vimc-common.c  | 68 +++++++++++++---------
 drivers/media/platform/vimc/vimc-common.h  |  9 ++-
 drivers/media/platform/vimc/vimc-debayer.c | 53 +++++++++++++----
 drivers/media/platform/vimc/vimc-scaler.c  | 10 +++-
 drivers/media/platform/vimc/vimc-sensor.c  |  6 +-
 5 files changed, 102 insertions(+), 44 deletions(-)
  

On Sun, 2 Feb 2020 at 12:50, Nícolas F. R. A. Prado
<nfraprado@protonmail.com> wrote:
>
> The objective of this series is to add support for GBR and BGR media bus formats
> for the source pad of debayer subdevices of the vimc driver.
>

Can you elaborate why is this needed, e.g. what use-case is this enabling,
or what is this fixing?

Thanks,
Ezequiel

> Since the GBR media bus code doesn't have a corresponding pixelformat, it needed
> to use the pixelformat of another bus code.
>
> The first patch makes it possible to have multiple media bus codes mapping to
> the same pixelformat.
>
> The second patch adds the GBR media bus code, using the RGB pixelformat.
>
> The third patch adds support for GBR and BGR media bus formats on the source
> pad of the debayer subdevice.
>
> This patch series passed all tests of v4l2-compliance:
> $ compliance_git -m /dev/media0
> v4l2-compliance SHA: c4a62f26c5c3ecd856ca10cf2f0d35d100283d7f, 64 bits, 64-bit time_t
>
> Grand Total for vimc device /dev/media0: 461, Succeeded: 461, Failed: 0, Warnings: 0
>
> Nícolas F. R. A. Prado (3):
>   media: vimc: Support multiple buscodes for each pixelformat
>   media: vimc: Add GBR media bus code
>   media: vimc: deb: Add support for GBR and BGR bus formats on source
>     pad
>
>  drivers/media/platform/vimc/vimc-common.c  | 68 +++++++++++++---------
>  drivers/media/platform/vimc/vimc-common.h  |  9 ++-
>  drivers/media/platform/vimc/vimc-debayer.c | 53 +++++++++++++----
>  drivers/media/platform/vimc/vimc-scaler.c  | 10 +++-
>  drivers/media/platform/vimc/vimc-sensor.c  |  6 +-
>  5 files changed, 102 insertions(+), 44 deletions(-)
>
> --
> 2.25.0
>
>
  

Hi,
Ezequiel.

On Sun, Feb 09, 2020 at 02:09:17PM -0300, Ezequiel Garcia wrote:
> 
> On Sun, 2 Feb 2020 at 12:50, Nícolas F. R. A. Prado
> <nfraprado@protonmail.com> wrote:
> >
> > The objective of this series is to add support for GBR and BGR media bus formats
> > for the source pad of debayer subdevices of the vimc driver.
> >
> 
> Can you elaborate why is this needed, e.g. what use-case is this enabling,
> or what is this fixing?

Sure.

At the moment, the only supported media bus format on the source pad of
the debayer subdevice is the RGB888_1X24.

The mbus format of the source pad of the debayer ultimately determines the
pixelformat that is streamed on /dev/video3, since:
    * The mbus formats of the links on the topology have to match for the
        streaming to be possible, and [1] shows that the source pad of the
        debayer links to the sink of the scaler.
    * The scaler uses the same mbus format on sink and source.
    * The source pad of the scaler is linked to the /dev/video3 Capture.

That said, there isn't a GBR pixelformat, so it uses the RGB pixelformat.

So what this patch series enables:
    * Setting debayer and scaler subdevices to use GBR and BGR mbus formats.
    * Stream video using the BGR pixelformat from /dev/video3.

By enabling these, it makes it possible to use vimc to emulate hardware that
uses GBR or BGR mbus formats internally or that streams using the BGR
pixelformat.

Regards,
Nícolas

[1] https://linuxtv.org/downloads/v4l-dvb-apis-new/v4l-drivers/vimc.html#topology

> 
> Thanks,
> Ezequiel