Re: [PATCH 13/18] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows

[Daniel Scally]

On 15/12/2020 10:28, Daniel Scally wrote:
> Morning Sakari
>
> On 30/11/2020 20:35, Sakari Ailus wrote:
>>> +/*
>>> + * Extend this array with ACPI Hardware ID's of devices known to be working.
>>> + * Do not add a HID for a sensor that is not actually supported.
>>> + */
>>> +static const char * const cio2_supported_devices[] = {
>>> +	"INT33BE",
>>> +	"OVTI2680",
>> I guess we don't have the known-good frequencies for the CSI-2 bus in
>> firmware?
>>
>> One option would be to put there what the drivers currently use. This
>> assumes the support for these devices is, well, somewhat opportunistic but
>> I guess there's no way around that right now at least.
>>
>> As the systems are laptops, they're likely somewhat less prone to EMI
>> issues to begin with than mobile phones anyway.
> Just looking at this; we're currently using this with the ov2680 driver
> that's in mainline currently (with very minor tweaks) plus a
> hacked-into-roughly-working version of the atomisp-ov5693 driver (ACPI
> ID INT33BE = ov5693 physical device). Neither of those drivers lists any
> link frequencies, nor provides a link frequency control for v4l2 to work
> with.
>
> On the other hand, the ov5648 [1] and ov8865 [2] drivers which Paul has
> submitted recently


Forgot to actually link these:


[1]
https://lore.kernel.org/linux-media/20201211154027.153535-1-paul.kocialkowski@xxxxxxxxxxx/T/#m5eb18611b7df1538ed4924422583b62cc61dbfae

[2]
https://lore.kernel.org/linux-media/20201211154428.153762-1-paul.kocialkowski@xxxxxxxxxxx/T/#m6d4fd5e590b1c4583d4a74f5ae938ea011408640