Re: [PATCH 2/2] media: i2c: imx471: Add Sony IMX471 image sensor driver

[Sakari Ailus <sakari.ailus@linux.intel.com>]

Hi Kate,

On Tue, Apr 28, 2026 at 11:08:56AM +0800, Kate Hsuan wrote:
> > > >> Updating both offsets here is wrong when hflip != vflip, you
> > > >> should only update V_WIN_OFFSET when changing vflip and
> > > >> H_WIN_OFFSET when changing hflip.
> > > >
> > > > The cropping configuration should reflect the values on the sensor's pixel
> > > > array and should not be affected by flipping. At least the crop window
> > > > needs to be adjusted accordingly by the driver. Is there a need to change
> > > > flipping while streaming?
> > >
> > > Ah, that is a very valid question, no I don't think we do need to
> > > set them while streaming.
> > >
> > > Kate if you cannot get the start_x / start_y coordinate changes
> > > when changing flipping to work to get a stable bayer output
> > > pattern, then another way to fix this is to only allow changing
> > > the flip controls while not streaming and return -EBUSY otherwise.
> > >
> > > This can then be combined with reporting a flip-ctrl dependend
> > > bayer-order so that userspace sees the right bayer-order after
> > > flipping is applied as long as userspace reads the subdev format
> > > after setting the controls (which libcamera does I believe).
> >
> > It's indeed currently a bit annoying to implement this. The common raw
> > sensor model will make this easier as the driver just indicates the native
> > pattern to userspace. I don't have an estimate currently when that set
> > would be in so the wait could be very long. Libcamera will need changes,
> > too.
> >
> > >
> > > For an example of an imx driver which reports a different
> > > bayer order depending in flipping see: imx214.c and
> > > the imx214_get_format_code() helper, a call to which should
> > > be used to replace any hardcoded mbus-formats in the driver.
> >
> 
> After many configuration attempts, tweaking the X, Y coordinates can
> not get the right Bayer order for the hflip, and also breaks the
> sensor's requirement (multiple by 4). However, changing the Bayer
> format for each kind of flipping works, and the colour is correct for
> every kind of flip, including h/v flipping. The side-effect is that
> the user can't flip the image during runtime.
> 
> It also worked with libcamera. Qcam shows the right colour when
> rotating the image 180 degrees.
> I'll continue to work on this approach, :)

Sounds good. Thanks for confirming this.

-- 
Kind regards,

Sakari Ailus