Hi,
On 21-05-18 11:19, Andy Shevchenko wrote:
On Sun, 2018-05-20 at 15:28 +0200, Hans de Goede wrote:
Hi All,
This series really consists of 2 series, patches 1-5 add support for
interesting ACPI tables which describe multiple i2c chips in a single
fwnode, sometimes multiple cases of the same chip on different
addresses,
sometimes a bunch of related chips.
Andy Shevchenko has come up with the solution of adding a quirk based
on the ACPI HID of the fwnode for these devices which makes the
drivers/i2c/i2c-core-acpi.c code instantiate separate i2c_client
devices
for each I2cSerialBusV2 in the fwnode. I agree with him that this is
the best (least ugly) solution for this.
I've been testing this solution on a device if mine which needs a
solution
for this, the HP Pavilion x2 - 10-n000nd 2-in-1 has an acpi_device /
fwnode
with a HID of BSG1160 which describes 3 different i2c sensors in an
accel /
magneto / gyro sensor cluster on the tablet. This has let to some
extra
prep. patches and some fixes to Andy's patches.
Thanks for taking care!
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.
In the BSG1160 case the 3 sensors are listening on 3 different i2c addresses.
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).
Regards,
Hans
Assuming everyone is ok with this series (I'm not expecting anyone to
be
really happy about the need for this), then I suggest that patches 1-6
get merged togther through either the ACPI or the i2c tree, I guess
the
i2c tree would make somewhat more sense, since most patches are there.
Then once those are accepted patches 7-9 can be merged into the iio
tree,
there is no compile time dependency between the 2, so these can be
merged
separately. Note merging 7-9 before there is agreement that this is
the
right way to fix this is probably not a good idea.
