[v6,0/3] Add imx577 compatible to imx412

v6:
- Drops -items encapsulating compatible - Krzysztof

v5:
- Drops imx477 from compat strings
  After Dave's comments I went and got the official imx477 sensor for the
  RPI and fired up the upstream imx412 usptream.

  Aside from the chip-id, the # of mipi-data lanes doesn't match and as
  Dave subsequently pointed out, neither do the PLL settings.

  I think it is possible to import a lot of the imx477.c code in the RPI
  tree into imx412/imx577 and potentially unify the code base. Even if its
  not possible to unify the code in the RPI imx477 can probably be adapted
  to imx412 for some combination of test patterns, data-lanes or PLLs.

  Anyway dropping imx477 is the right thing here since there's more work
  than a simple compat string to unify with imx412.c

Resend:
- Cc Rob and Krzysztof

v4:
- Squashes dt-bindings addition - Sakari
- Squashes compat string addition to driver - Sakari
- Drops checking fwnode(&client->dev), checks for !name - Sakari
- Retains imx477 compat
  I think we have established that imx477 and imx577 do have additional
  settings and modes over the imx412 which, we can and hopefully will add
  in as time goes by. What we have upstream will work for all three parts.

v3:
To really get to the bottom of what was going on with the imx412, imx477
and imx577 I got a Nvida Nano with both sensors from Leopard imaging.

Interestingly the shipped driver from Leopard is called "imx477" and is
keyed to work with imx412, imx477 and imx577 with predictably the same
register init sequence.

For me aside from the physical size difference in the modules the only
discerable difference is the imx577 has a "green tinge" which is exactly
the same experience I have with the imx577 on the Qualcomm RB5 - with both
the downstream driver stack and the usptream driver.

With the modules shipped from Leopard both the imx412 and imx577 report the
same chip id of 0x0577.

I dumped the first 32 registers on both modules using the Nvidia/Leopard
stack and as expected - all of the register values match.

So I've confirmed as far as my investigation has gone, there's no
clear register we can interrogate to differentiate the parts.

- Drops renaming of the driver to imx577.c
  I continue to think this is the right thing to do but, I'm happy to
  leave that on the back burner for another time.
- Add in compatible strings for imx477 and imx577 into the dt-bindings
- Extend the imx412 per Sakari's comment re: media device naming
  https://patchwork.kernel.org/project/linux-media/patch/20220607134057.2427663-3-bryan.odonoghue@linaro.org/#24894500
- Add imx477 and imx577 with supporting code to drive media device name

Depending then if the compat string is imx412, imx477 or imx577 the media
name of the device will be imx412, imx477 or imx577 e.g. I use the
following media-ctl command depending on the specified compatible.

media-ctl -v -d /dev/media0 -V '"imx577 '22-001a'"...
media-ctl -v -d /dev/media0 -V '"imx412 '22-001a'"...

v2:
Sakari wasn't especially satisfied with the answer imx412 and imx577 have
the same init sequence but, suggested setting the string for imx577 as is
done in the ccs driver.

https://lore.kernel.org/all/20220607134057.2427663-3-bryan.odonoghue@xxxxxxxxxx/t/

I went to look at that and asked myself "how would I tell the difference
between the two silicon parts". The obvious answer is a chip identifier.

Luckily this class of IMX sensor has a chip identifier at offset 0x0016.

That looks like this for imx258, imx319 and imx355

drivers/media/i2c/imx258.c:#define IMX258_REG_CHIP_ID    0x0016
drivers/media/i2c/imx258.c:#define IMX258_CHIP_ID        0x0258

drivers/media/i2c/imx319.c:#define IMX319_REG_CHIP_ID    0x0016
drivers/media/i2c/imx319.c:#define IMX319_CHIP_ID        0x0319

drivers/media/i2c/imx355.c:#define IMX355_REG_CHIP_ID    0x0016
drivers/media/i2c/imx355.c:#define IMX355_CHIP_ID        0x0355

but then looks like this for imx412.

drivers/media/i2c/imx412.c:#define IMX412_REG_ID         0x0016
drivers/media/i2c/imx412.c:#define IMX412_ID             0x577

This made no sense at all to me, why is the imx412 driver not named imx577 ?

I went and dug into the Qualcomm camx/chi-cdk sources to find that a file
called cmk_imx577_sensor.xml has a property called sensorId which is
constrained to 0x0577.

In the Qualcomm stack this pairing of filename and identifier is
maintained for imx258, imx376, imx476, imx576, imx519, imx362, imx481,
imx318 imx334 and imx386.

Every single example I can find of a Sony IMX sensor which returns a chip
identifier at offset 0x0016 matches the driver name to the returned sensor
id both here upstream in Linux and in Qualcomm's camx stack.

The conclusion I draw from this is that imx412.c is inappropriately named.

I think the right thing to do is to rename imx412 to imx577. It is
confusing and I think wrong to pair imx412.c with a chip which identifies
as 0x0577.

v1:
Right now the imx412 and imx577 are code and pin compatible however, they
are distinct pieces of silicon.

Document imx577 as a compatible enum and add the compat string to imx412.c.
This allows us to differentiate these chips in DTS and potentially to apply
any future imx412 or imx577 specific changes appropriately.

Bryan O'Donoghue (3):
  media: dt-bindings: imx412: Extend compatible strings
  media: i2c: imx412: Assign v4l2 device subname based on compat string
  media: i2c: imx412: Add new compatible strings

 .../devicetree/bindings/media/i2c/sony,imx412.yaml       | 4 +++-
 drivers/media/i2c/imx412.c                               | 9 ++++++++-
 2 files changed, 11 insertions(+), 2 deletions(-)

On Fri, 14 Oct 2022 19:04:15 +0100, Bryan O'Donoghue wrote:
> Add compatible bindings for imx577 which uses the same silicon enabling
> reference code from Sony in the available examples provided.
> 
> Cc: sakari.ailus@iki.fi
> Cc: dave.stevenson@raspberrypi.com
> Cc: jacopo@jmondi.org
> Cc: "Paul J. Murphy" <paul.j.murphy@intel.com>
> Cc: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
> Cc: Mauro Carvalho Chehab <mchehab@kernel.org>
> Cc: Rob Herring <robh+dt@kernel.org>
> Cc: Krzysztof Kozlowski <krzysztof.kozlowski+dt@linaro.org>
> Cc: linux-media@vger.kernel.org
> Cc: devicetree@vger.kernel.org
> Cc: linux-kernel@vger.kernel.org
> Signed-off-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
> ---
>  Documentation/devicetree/bindings/media/i2c/sony,imx412.yaml | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 

Acked-by: Rob Herring <robh@kernel.org>

On 14/10/2022 19:04, Bryan O'Donoghue wrote:
> v6:
> - Drops -items encapsulating compatible - Krzysztof

Ping.

Any chance of the good folks @ 
https://patchwork.linuxtv.org/project/linux-media picking this up ?

It unblocks enabling CAMSS on the qcom RB5 where the feedback I've had 
is we should get compat imx577 merged to accurately map the hardware 
config we have.

https://patchwork.kernel.org/project/linux-media/list/?series=644675

https://patches.linaro.org/project/linux-arm-msm/patch/20220518133004.342775-2-bryan.odonoghue@linaro.org/

---
bod

Hi Bryan,

On Mon, Nov 07, 2022 at 11:29:47PM +0000, Bryan O'Donoghue wrote:
> On 14/10/2022 19:04, Bryan O'Donoghue wrote:
> > v6:
> > - Drops -items encapsulating compatible - Krzysztof
> 
> Ping.
> 
> Any chance of the good folks @
> https://patchwork.linuxtv.org/project/linux-media picking this up ?

This is waiting like other media patches to be merged to my tree. I think
I'll prepare a second branch to get more patches merged.

> 
> It unblocks enabling CAMSS on the qcom RB5 where the feedback I've had is we
> should get compat imx577 merged to accurately map the hardware config we
> have.
> 
> https://patchwork.kernel.org/project/linux-media/list/?series=644675
> 
> https://patches.linaro.org/project/linux-arm-msm/patch/20220518133004.342775-2-bryan.odonoghue@linaro.org/