Hi Laurent,
On Wed, May 20, 2020 at 03:50:20AM +0300, Laurent Pinchart wrote:
> Hi Sakari,
>
> On Mon, May 18, 2020 at 12:45:18PM +0100, Kieran Bingham wrote:
> > Hi Sakari,
> >
> > There are only fairly minor comments here, fix ups will be included in a
> > v10.
> >
> > Is there anything major blocking integration?
> >
> > On 16/05/2020 22:51, Sakari Ailus wrote:
> > > On Tue, May 12, 2020 at 04:51:03PM +0100, Kieran Bingham wrote:
> > >
> > > ...
> > >
> > >> +static int max9286_enum_mbus_code(struct v4l2_subdev *sd,
> > >> + struct v4l2_subdev_pad_config *cfg,
> > >> + struct v4l2_subdev_mbus_code_enum *code)
> > >> +{
> > >> + if (code->pad || code->index > 0)
> > >> + return -EINVAL;
> > >> +
> > >> + code->code = MEDIA_BUS_FMT_UYVY8_2X8;
> > >
> > > Why UYVY8_2X8 and not UYVY8_1X16? In general, the single sample / pixel
> > > variant of the format is generally used on the serial busses. This choice
> > > was made when serial busses were introduced.
>
> This is a bit of a tricky one. On the camera size, for the RDACM20, the
> O10635 sensor outputs UYVY8_2X8. This if fed to the MAX9271 serializer,
> which doesn't care about the data type. The MAX9271 has a 16-bit input
> bus, with 10 bits reserved for data, 2 bits dynamically configurable
> to carry H/V sync or extra data, and 4 bits dynamically configurable to
> carry GPIOs or extra data. The 16-bit words are then serialized (it's a
> bit more complicated, when using the H/V sync signals they are
> transmitted in a different way, and the MAX9271 also supports a DDR mode
> that makes the "serial link word" carry up to 30 bits). Effectively, the
> two samples of UYVY8_2X8 are serialized in a 16-bit word each.
>
> Sakari, with this information in mind, what would you recommend ?
As this pad describes a serial bus --- doesn't it? --- it should use the
same formats as other serial busses such as CSI-2. I.e. the 1X16 variant.
--
Regards,
Sakari Ailus
