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