Hi Tomi On Thu, Feb 23, 2023 at 07:52:48PM +0200, Tomi Valkeinen wrote: > On 23/02/2023 19:10, Jacopo Mondi wrote: > > Hi Tomi > > > > On Wed, Feb 22, 2023 at 02:56:28PM +0200, Tomi Valkeinen wrote: > > > For legacy reasons the CAL driver uses 2X8 mbus formats for the CSI-2 > > > link (e.g. MEDIA_BUS_FMT_YUYV8_2X8). 1X16 formats are more correct and > > > used by many drivers, so add 1X16 support to CAL. > > > > > > We keep the 2X8 formats for backward compatibility. > > > > Eh, this is the usual question about what we should consider a > > to be a userspace breakage or not. > > > > I presume the reason to maintain 2X8 formats is (assuming the CAL > > interface is CSI-2 only, right ?) because sensor drivers that only > > support 2X8 formats will then fail to link_validate() if you remove > > Yes. > > > all 2X8 formats here. I'm of the opinion that we should bite the > > bullet and move to 1X16. If any driver that used to work with CAL now > > breaks, the sensor driver will have to be fixed. > > > > In my humble experience, that's what we did with the ov5640 sensor. We > > Yes, you did. > > > removed the 2X8 formats in CSI-2 mode and some platform driver broke > > and then had been fixed (it happened in the same release cycle), win win. > > No, CAL is still broken =). OV5640 is the only sensor I have. I just haven't > had time to look at this and fix it (and no one has complained). > Ups, I was thinking at the ST and microchip receivers, I thought CAL was fixed already :) See ? win win (almost) > > I know it's controversial, let's see what others think. > > I'm all for dropping the 2X8 formats, if that's the consensus. It would keep > the driver simpler, as we could keep the 1:1 relationship between pixel > formats and mbus codes. > > I'll look at your other comments tomorrow. > And I'll look at your last patch tomorrow if I can get a media graph dump! > Tomi >
