minimal required mt9m114 driver changes

[rmast]

          > As I expect the rewritten Onsemi driver to abide closer to the new v4l2 I'm curious what would happen if I add { "INT33F0" } to the of_device_id call. It has a slightly different name from the acpi_device_id call in the old driver.

@jwrdegoede writes: Unfortunately things are not that easy, I have a pretty good idea what the minimum necessary changes are, to get things to work at a minimum the following mt9m114 driver changes are required:

1. Add the ACPI and support for ACPI based enumeration in general which may require further changes.
2. Waiting for the fwnode endpoint to show up before continuing with probing
3. Special handling for the clk, devm_get_clk() is expected to fail since the clk is managed by ACPI
4. Maybe handling of a second (powerdown) GPIO
5. atomisp changes to deal with the standard v4l2 driver offering multiple mbus formats instead of only offering a single raw bayer format.

Originally posted by @jwrdegoede in https://github.com/jfwells/linux-asus-t100ta/issues/4#issuecomment-2409030204

[rmast]

@jwrdegoede

1. As ACPI based enumeration seemed to have long been a no go area, is that something that requires active Intel support, or is another strategy feasible? I guess this one is only meant to be able to skip the hardly reachable PCI enumeration?
2. I guess GPT-4o can make sense of this.
3. Can we just skip the clock handling in this case, or is a replacing ACPI clk handler required? Can we write a GPT-4o prompt to make this happen?
4. and 5. also seem not really minimal to get a first picture out of the new driver.

Do we additionally have to transplant some of the GPIO handling of the atomisp-mt9m114.c to some atomisp or v4l2-driver to make the new mt9m114.c work?

[rmast]

The devil is in the detail:

mt9m114.c: static struct i2c_driver mt9m114_driver = { .driver = { .name = "mt9m114", .pm = &mt9m114_pm_ops, .of_match_table = mt9m114_of_ids, }, .probe = mt9m114_probe, .remove = mt9m114_remove, };

ov2680.c:

static struct i2c_driver ov2680_i2c_driver = { .driver = { .name = "ov2680", .pm = pm_sleep_ptr(&ov2680_pm_ops), .of_match_table = ov2680_dt_ids, .acpi_match_table = ov2680_acpi_ids, }, .probe = ov2680_probe, .remove = ov2680_remove, };

[rmast]

This source: https://github.com/torvalds/linux/blob/master/drivers/staging/media/atomisp/pci/atomisp_csi2_bridge.c

should be adapted for Baytrail as was suggested in this commit message:

https://git.kernel.org/pub/scm/linux/kernel/git/hansg/linux.git/commit/drivers/staging/media/atomisp/i2c/atomisp-ov2680.c?h=media-atomisp&id=b7e155e16601b0c6f34e3345b9eca6a2efc5bc5d

Currently this source only supports Lenovo Ideapad Miix 310 and Xiaomi Mipad2, which both depend on a well formed Cherry Trail GUID for the camera in the DSDT, where the DSDT of the Asus T100 is not that mature and doesn't contain this GUID: dc2f6c4f-045b-4f1d-97b9-882a6860a4be

[rmast]

And probably this one as well: https://github.com/torvalds/linux/blob/master/drivers/media/pci/intel/ipu-bridge.c

[rmast]

This file has a comment that only mentions the atomisp2401: https://github.com/torvalds/linux/blob/master/drivers/staging/media/atomisp/pci/atomisp_csi2.c

[rmast]

This function is a model for how parse_dt should await the bridge: https://github.com/torvalds/linux/blob/master/drivers/media/i2c/ov2680.c#L1074

[rmast]

You could wonder why https://github.com/torvalds/linux/blob/master/drivers/media/i2c/aptina-pll.c is not applied in mt9m114.c for determining the PLL values.