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

Dave Stevenson <[email protected]> Mon, 3 Aug 2026 18:37:47 +0100
Newsgroups org.kernel.vger.linux-media,org.kernel.vger.linux-devicetree,org.kernel.vger.linux-kernel
Message-ID <CAPY8ntC1T4_orgvxBRqpqux4V90d5XZ-3KZZKoqnCPkbf6wE0Q@mail.gmail.com>
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].

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