SoC-Camera bus width, and "V4LV4L2_PIX_FMT_Y16" for "monochrome 10 bit"

[Agustin <gatoguan-os@yahoo.com>]

(Changing subject)

On Fri, 12/12/08, Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote:
> On Fri, 12 Dec 2008, Agustin wrote:
> > Absolutely. Right now I am connecting 6 MT9P031, the monochrome
> > type, with 12 bits ADC so I think the right format would be 'Y16'.
> 
> Hm, actually I think it is not. As you might have seen in
> the current soc-camera sources, we now handle two formats:
> one from the sensor to the host controller driver, and one
> from the host driver to the user. i.MX31 can handle 15, 10,
> 8 and 4 bits, so, you will either have to extend your 
> 12 bits to 15, or truncate them to 10 or 8. Respectively
> you will choose a suitable format. But - it will have to be
> "15-bit monochrome", "10-bit monochrome", or "8-bit
> monochrome."
> Currently I only see 8 and 16 bits defined in v4l, so, if
> you use anything different you will have to define it. Yes,
> I know I used V4L2_PIX_FMT_Y16 in mt9m001 for "monochrome
> 10 bit" - this is wrong, as well as using
> V4L2_PIX_FMT_SBGGR16 for "Bayer 10 bit,"
> I will have to fix this some time.

According to V4L2 API (http://v4l2spec.bytesex.org/spec/r4246.htm), V4L2_PIX_FMT_Y16 ('Y16 ') describes "a grey-scale image with a depth of 16 bits per pixel". And it is also stated that "the actual sampling precision may be lower than 16 bits, for example 10 bits per pixel".

So I think V4L2_PIX_FMT_Y16 is valid for all the monochrome widths in i.MX31, isn't it?

Maybe you mean that host interface can pack 10-bit data into RAM bit-wise? e.g., putting 4 pixels in every 5 bytes? That would definitely make a new format. I need to check i.MX31 docs on this...

Regarding CSI bus width, I understand it is 'negotiated' through soc_camera_ops.query/set_bus_params(). I still don't know who makes the choice here, so I am just announcing 10 bit cause is what I need at the moment.

> > Later on I plan to use the complete bus width in the i.MX31
> > (16 or 15 bit?) as 'raw' data, in order to pack pixels and
> > get higher data rate at the same clock.
> 
> Maximum 15, but you already use raw data for monochrome,
> i.MX31 doesn't have any special support for it.

I see, then I just need to make sure that nobody tries to interpret
the data on its way to user space.

Regards,
--Agustín.

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list