Hi,
On 21-05-18 15:13, Andy Shevchenko wrote:
On Mon, 2018-05-21 at 14:34 +0200, Hans de Goede wrote:
On 21-05-18 11:19, Andy Shevchenko wrote:
Patches 6-9 use the new functionality creating one i2c-client per
I2cSerialBusV2 resource to make the sensor cluster on the HP X2
work
and
are posted as part of this series to show how this functionality
can
be
used.
I suppose it's better to do an "MFD" type of IIO driver for that
chip.
Check, for example, drivers/iio/imu/bmi160/bmi160_core.c
That seems to be a single chip listening on a single i2c address / spi
chip-select.
Ooops, wrong reference.
In the BSG1160 case the 3 sensors are listening on 3 different i2c
addresses.
There is a Bosh magnetometer + accelerometer chip (BMC150). We have just
two independent drivers for them. Luckily for ACPI they have different
IDs (on the platforms where it's used like that).
So, my series targeting the series of same IPs under one device...
We could use the drivers/mfd framework, but the we get platform
devices
and we would need to patch all 3 existing drivers to support platform
bindings and get a regmap from there (converting them to regmap where
necessary).
...and in your case MFD sounds better. Though why do you need to have a
common regmap?
Not a common regmap, but a regmap per i2c-address of course, but we need
to have the MFD driver create these regmaps because the MFD-child devices
are platform_devices which know nothing about i2c. And then we need to add
platform_device / driver support to 3 iio devices and have that code
retrieve the regmap. And if not all drivers are using regmap (I did not
check) convert some of them to regmap first.
There really is no MFD device here, as the need to create separate
regmaps shows, usually the whole purpose of the MFD framework is
to share a single i2c-client / regmap between multiple drivers
because the i2c device has multiple function blocks. So the MFD
framework really is a _very_ poor fit here.
To put this differently, I can rewrite the DSDT so that things
just work without needing any kernel modification at all, the
problem is in the *enumeration* here, not in multiple separate function
blocks sharing a single address space.
And using your proposed quirk support for enumeration multiple
i2c-clients from a single acpi_device fixes the enumeration problem.
Regards,
Hans
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
