On 17/09/2020 11:33, Sakari Ailus wrote:
>> + sensor_props[3] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + data_lanes,
>> + (int)ssdb->lanes);
>> + sensor_props[4] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_SENSOR];
>> + sensor_props[5] = PROPERTY_ENTRY_NULL;
>> +
>> + cio2_props[0] = PROPERTY_ENTRY_U32_ARRAY_LEN("data-lanes",
>> + data_lanes,
>> + (int)ssdb->lanes);
>> + cio2_props[1] = remote_endpoints[(bridge.n_sensors * 2) + ENDPOINT_CIO2];
>> + cio2_props[2] = PROPERTY_ENTRY_NULL;
> I suppose the CSI-2 link frequency is generally encoded in drivers in this
> case. A lot of drivers already check for those, could you add the
> frequencies here as well (as they are known)?
This one caused me some consternation; I mentioned in a previous email
that I was overwriting the v4l2_subdev's fwnode directly because I
couldn't reprobe() the devices after changing their fwnode. Turns out
that's probably not ok, because as you point out there are some drivers
that check for properties in firmware as part of their .probe() call, so
they _have_ to be there for those to work (including ov5670, which is
the canonical ipu3 driver in the kernel docs). imx258 and ov13858 are
also affected, and I'm aware of at least one other driver in development
that would be affected.
The problem preventing the reprobe working is that i2c_device_match()
relies on a device's fwnode having acpi_device_fwnode_ops to perform
ACPI matching, so after giving the device our software nodes the
matching just fails. I thrashed out a way to make the reprobe work, but
I don't really like the solution so I wanted to talk about it. The long
story short is; clone the driver but add an i2c_device_id matching the
existing i2c_client's name, then use i2c_add_driver() to install it to
the bus before calling device_reprobe(). This does work; it makes the
devices reprobe cleanly at the end of cio2-bridge's init, but it feels a
little bit hacky. Any thoughts? Or if it makes it easier to discuss, I
can just post the v2 containing all the changes that people suggested
after the v1, and showing how this reprobe would work.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
