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

[Laurent Pinchart <laurent.pinchart@ideasonboard.com>]

Hi Dave,

On Mon, Aug 03, 2026 at 06:37:47PM +0100, Dave Stevenson wrote:
> Hi Lachlan and Laurent.
> 
> It's brilliant that Sony are getting involved in upstreaming drivers!
> 
> <snip>
> >
> > In his IMX678 driver, Jai hardcodes the pixel rate to 594MHz, which is
> > 8 * 74.25MHz (IMX908_XHS_HZ). The rationale is that HMAX is expressed in
> > units of the 74.25 MHz internal clock, so we assumed that the pixel
> > array is not read out using the link clock but using a clock derived
> > from the internal clock. The multiplier was chosen to ensure that the
> > minimum HMAX value corresponds to a positive HBLANK, as negative HBLANK
> > would confuse userspace (and developers). Having a fixed pixel rate
> > greatly simplifies the driver, as you don't have to update the pixel
> > rate control, and HMAX calculation from HBLANK becomes a division by 8.
> >
> > We're not sure how the pixel array of the IMX678 is clocked exactly, so
> > I don't know if the above corresponds to reality, neither for the IMX678
> > nor the IMX908. If you could provide more information about the pixel
> > array readout, that would be greatly appreciated. Note that the pixel
> > rate value does not have to match the physical readout clock, as it is
> > only used by userspace to calculate timings (to convert between h/v
> > blank and fps).
> >
> > Jai can provide more information if needed.
> 
> In case you'd missed it, I'm trying to convert Jai's IMX678 driver
> into a generic Starvis 2 driver[1].

Just a quick message to tell you that I plan to reply to that mail
thread. I'm on vacation this week, so there will be a delay.

> IMX662 that I'm interested in is streaming with a total of 7 changes
> to defines or const structs in the current imx678 driver.
> IMX675 (5MPix Starvis2) frames with a similar number of changes but
> currently isn't giving me images (test patterns work).
> IMX585 looks like it may fit the same pattern, but I'm waiting on a
> module for that one.
> 
> I'm therefore looking to parameterise those diffs but otherwise keep
> it all common. This avoids the hassle of having to convert potentially
> 4 (or more) drivers to the Common Raw Sensor Model once it is
> finalised.
> 
> IMX908 here looks to very much follow the same pattern, so unless
> there are additional diffs between Starvis 2 and Starvis 3 it would
> potentially fit into the same framework.
> 
> I'm hoping to get an RFC out this week as I'm then on holiday for a
> week. It'll be interesting to see if IMX908 will fit with the same
> pattern.
> 
> Lachlan: Are there any particular people we should contact for details
> of IMX908, or just go through our normal contact?
> 
> Thanks
>   Dave
> 
> [1] https://lore.kernel.org/linux-media/20260312150437.1091195-1-eagle.alexander923@gmail.com/T/#m6072f85b03811932427597d8ffe5da008d33246a

-- 
Regards,

Laurent Pinchart