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

Laurent Pinchart <[email protected]>
Newsgroups org.kernel.vger.linux-kernel,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-media
Message-ID <[email protected]>
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/[email protected]/T/#m6072f85b03811932427597d8ffe5da008d33246a

-- 
Regards,

Laurent Pinchart
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.