Re: [PATCH 0/3] platform/x86: int3472/discrete: Make it work with IPU6

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 11/25/22 15:40, Laurent Pinchart wrote:
> On Thu, Nov 24, 2022 at 09:00:04PM +0100, Hans de Goede wrote:
>> Hi All,
>>
>> Here is a small set of patches to make the int3472/discrete code
>> work with the sensor drivers bundled with the (unfortunately out of tree)
>> IPU6 driver.
>>
>> There are parts of the out of tree IPU6 code, like the sensor drivers,
>> which can be moved to the mainline and I do plan to work on this at some
>> point and then some of this might need to change. But for now the goal is
>> to make the out of tree driver work with standard mainline distro kernels
>> through e.g. dkms. Otherwise users need to run a patched kernel just for
>> a couple of small differences.
>>
>> This is basically a rewrite of this patch:
>> https://github.com/intel/ipu6-drivers/blob/master/patch/int3472-support-independent-clock-and-LED-gpios-5.17%2B.patch
>>
>> Wich users who want to use the IPU6 driver so far have had to manually
>> apply to their kernels which is quite inconvenient.
>>
>> This rewrite makes 2 significant changes:
>>
>> 1. Don't break things on IPU3 platforms
>>
>> 2. Instead of extending the int3472_sensor_configs[] quirks table for each
>> model which needs "clken" and "pled" GPIOs, do this based on matching
>> the ACPI HID of the ACPI device describing the sensor.
> 
> How can we be sure that a given sensor model will always be wired to the
> same GPIOs on all platforms that integrate it with an IPU6 (or IPU3) ?

This is not about which GPIOs are actually there, this is about what the
driver expects. Specifically about if the driver expects the clock to
be modelled with the clk framework or as a clk-en GPIO which is
a property of the driver, not of the board design.

But as already mentioned I agree with Dan and you that modelling it
through the clk framework is correct and what needs to happen here is to
patch the IPU6 sensor drivers to move them to the clk framework.

so this is all mute.

Regards,

Hans