Hi Bryan, On Wed, Oct 12, 2022 at 01:56:19AM +0100, Bryan O'Donoghue wrote: > On 22/09/2022 12:19, Bryan O'Donoghue wrote: > > On 22/09/2022 12:16, Dave Stevenson wrote: > > > It may*eventually* work for all three parts, but isn't the time to > > > add the compatible string at the point where it is actually compatible > > > with the driver? > > > > Yes. I forgot about the 0x477 chip id on your part. > > > > I'm happy enough to drop 477 from the compat string or indeed to allow > > 0x0477 as a valid chip identifier in imx412. > > > > Sakari, what would you like to do ? > > > > --- > > bod > > Right. > > So I got myself the official rpi imx477 sensor and ran the imx412/imx577 > driver on the rpi 5.19.y tree > > It looks like the rpi driver configures imx477 for two MIPI data-lanes, > whereas upstream imx412 wants four MIPI data-lanes. > > So already that means the imx412 config as-is won't work. > > But, we do know these sensors are very very close. > > I think the right medium term thing to do is try take in the majority of the > imx477 code - including the various test modes, and resolutions and support > for different MIPI data-lane configurations. > > Its not clear to me that the imx412/imx577 and imx378/imx477 can genuinely > live in the same codebase though. > > Anyway I think adding imx477 to the imx412 driver should be considered out > of scope pending answering most of those questions and getting the code to > work. > > Anyway that merging of rpi imx477 and upstream imx412/imx577 code feels like > an entirely different series. > > So I'll resend this series minus the imx477 bits. I wonder if you saw my earlier reply... but this is certainly fine, too. -- Sakari Ailus
