linux-kernel - Re: [PATCH v3 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL bridge driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20190408092126.xgqhmyos5hkvmisv@kekkonen.localdomain>
Date:   Mon, 8 Apr 2019 12:21:27 +0300
From:   Sakari Ailus <sakari.ailus@...ux.intel.com>
To:     Mickael GUENE <mickael.guene@...com>
Cc:     "linux-media@...r.kernel.org" <linux-media@...r.kernel.org>,
        Hugues FRUCHET <hugues.fruchet@...com>,
        Mauro Carvalho Chehab <mchehab@...nel.org>,
        Matt Ranostay <matt.ranostay@...sulko.com>,
        Petr Cvek <petrcvekcz@...il.com>,
        Akinobu Mita <akinobu.mita@...il.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "David S. Miller" <davem@...emloft.net>,
        Ben Kao <ben.kao@...el.com>,
        Nicolas Ferre <nicolas.ferre@...rochip.com>,
        Todor Tomov <todor.tomov@...aro.org>,
        Rui Miguel Silva <rui.silva@...aro.org>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Hans Verkuil <hverkuil@...all.nl>,
        Ricardo Ribalda Delgado <ricardo@...alda.com>,
        Jacopo Mondi <jacopo+renesas@...ndi.org>,
        Tianshu Qiu <tian.shu.qiu@...el.com>,
        Bingbu Cao <bingbu.cao@...el.com>
Subject: Re: [PATCH v3 2/2] media:st-mipid02: MIPID02 CSI-2 to PARALLEL
 bridge driver

On Mon, Apr 08, 2019 at 06:17:18AM +0000, Mickael GUENE wrote:
> Hi Sakari,
> 
> On 4/6/19 13:01, Sakari Ailus wrote:
> > On Tue, Mar 26, 2019 at 02:36:41PM +0000, Mickael GUENE wrote:
> >> Sakari,
> >>
> >>>> +static int bpp_from_code(__u32 code)
> >>>> +{
> >>>> +	switch (code) {
> >>>> +	case MEDIA_BUS_FMT_SBGGR8_1X8:
> >>>> +	case MEDIA_BUS_FMT_SGBRG8_1X8:
> >>>> +	case MEDIA_BUS_FMT_SGRBG8_1X8:
> >>>> +	case MEDIA_BUS_FMT_SRGGB8_1X8:
> >>>> +		return 8;
> >>>> +	case MEDIA_BUS_FMT_SBGGR10_1X10:
> >>>> +	case MEDIA_BUS_FMT_SGBRG10_1X10:
> >>>> +	case MEDIA_BUS_FMT_SGRBG10_1X10:
> >>>> +	case MEDIA_BUS_FMT_SRGGB10_1X10:
> >>>> +		return 10;
> >>>> +	case MEDIA_BUS_FMT_SBGGR12_1X12:
> >>>> +	case MEDIA_BUS_FMT_SGBRG12_1X12:
> >>>> +	case MEDIA_BUS_FMT_SGRBG12_1X12:
> >>>> +	case MEDIA_BUS_FMT_SRGGB12_1X12:
> >>>> +		return 12;
> >>>> +	case MEDIA_BUS_FMT_UYVY8_2X8:
> >>>
> >>> This is good for the parallel bus, but on CSI-2 side you should have
> >>> MEDIA_BUS_FMT_UYVY8_1X16 instead. This isn't technically correct for a
> >>> serial bus, but the custom is to use the one sample / pixel formats on the
> >>> serial busses.
> >>>
> >>  Should MEDIA_BUS_FMT_BGR888_1X24 be something like
> >> MEDIA_BUS_FMT_BGR888_3X8 for parallel output bus ?
> > 
> > Good point. Yes.
> > 
> > Could you add that format to
> > Documentation/media/uapi/v4l/subdev-formats.rst, please, in a separate
> > patch?
> > 
>  I also need to add it to include/uapi/linux/media-bus-format.h I
> suppose ?

Yes, that's correct.

>  I was also wondering if I should add MEDIA_BUS_FMT_BGR888_3X8_BE and
> MEDIA_BUS_FMT_BGR888_3X8_LE instead ?

If it's either, then "BE" but in this case I think it's better be without
the explicit endianness as the endianness change results in pixel order
change --- the format itself remains valid.

I wonder what others think, too. Hans, any opinion?

> 
>  So if you are ok with the above I will add MEDIA_BUS_FMT_BGR888_3X8 to
> subdev-formats.rs and media-bus-format.h as a first parch of my serie.

-- 
Regards,

Sakari Ailus
sakari.ailus@...ux.intel.com