Hi,
On 11/1/21 21:03, Mauro Carvalho Chehab wrote:
> Em Mon, 1 Nov 2021 20:06:52 +0100
> Hans de Goede <hdegoede@xxxxxxxxxx> escreveu:
<snip>
>> -Patch to not load atomisp_foo sensor drivers on !BYT && !CHT
>
> Not sure if it is worth doing it, as there are a lot more to be
> done before being able to use a generic sensor driver.
As you may know, I'm also working on IPU3 support for $dayjob atm
actually :)
So the drivers for e.g. the ov5693 sensor conflict, by adding
a small (one line) check to atomisp_ov5693.c to not register
the driver at all when not on BYT/CHT we can avoid the conflict
on most devices for now. And when actually on BYT/CHT the user
will need to blacklist the non atomisp sensor-modules which, well
sucks, but atomisp is in staging for a reason ...
So the idea here is that with some small added ugliness to the
atomisp_foo.c sensor drivers we can make the 2 drivers co-exist
a bit more, allowing e.g. generic distro kernels to (maybe) enable
the atomisp2 stuff without regressing the IPU3 support.
###
Since we are discussing this now anyways, the atomisp_foo.c
patches would look like this:
#include <linux/platform_data/x86/soc.h>
if (!soc_intel_is_byt() && !soc_intel_is_cht())
return -ENODEV;
In the probe() function and change driver.name from
e.g. "ov5693" to "atom_ov5693".
Before I spend time on writing patches for this, would patches doing
this for conflicting drivers be acceptable ?
Regards,
Hans
