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

Dave Stevenson <[email protected]>
Newsgroups gmane.linux.drivers.devicetree,gmane.linux.drivers.video-input-infrastructure,gmane.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/20260312150437.1091195-1-eagle.alexander923-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org/T/#m6072f85b03811932427597d8ffe5da008d33246a
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.