From: Hans de Goede <hdegoede@redhat.com>
To: Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"Rafael J . Wysocki" <rjw@rjwysocki.net>,
Len Brown <lenb@kernel.org>,
Mika Westerberg <mika.westerberg@linux.intel.com>,
Wolfram Sang <wsa@the-dreams.de>,
Jonathan Cameron <jic23@kernel.org>
Cc: linux-acpi@vger.kernel.org, linux-i2c@vger.kernel.org,
Hartmut Knaack <knaack.h@gmx.de>,
Lars-Peter Clausen <lars@metafoo.de>,
linux-iio@vger.kernel.org
Subject: Re: [PATCH 0/9] ACPI/i2c Enumerate several instances out of one fwnode
Date: Mon, 21 May 2018 15:31:55 +0200 [thread overview]
Message-ID: <92663486-b96c-e87f-ad0e-9f50a03ee36b@redhat.com> (raw)
In-Reply-To: <81114e50a1e07763f1645201e42b80a6fc9f33a1.camel@linux.intel.com>
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
next prev parent reply other threads:[~2018-05-21 13:32 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-20 13:28 [PATCH 0/9] ACPI/i2c Enumerate several instances out of one fwnode Hans de Goede
2018-05-20 13:28 ` [PATCH 1/9] ACPI: export __acpi_match_device and __acpi_device[_uevent]_modalias Hans de Goede
2018-05-20 13:28 ` [PATCH 2/9] i2c: Allow specifying irq-index to be used in i2c_device_probe() Hans de Goede
2018-05-21 9:07 ` Andy Shevchenko
2018-05-21 9:08 ` Andy Shevchenko
2018-05-20 13:28 ` [PATCH 3/9] i2c: acpi: Introduce i2c_acpi_get_i2c_resource() helper Hans de Goede
2018-05-20 13:28 ` [PATCH 4/9] i2c: acpi: Allow get info by index in i2c_acpi_get_info() Hans de Goede
2018-05-20 13:28 ` [PATCH 5/9] i2c: acpi: Enumerate several instances out of one device Hans de Goede
2018-05-20 13:28 ` [PATCH 6/9] i2c: acpi: Add BSG1160 to i2c_acpi_multiple_devices_ids Hans de Goede
2018-05-20 13:28 ` [PATCH 7/9] iio: accel: bmc150: Add support for BSG1160 ACPI HID Hans de Goede
2018-05-20 13:28 ` [PATCH 8/9] iio: gyro: bmg160: " Hans de Goede
2018-05-20 13:28 ` [PATCH 9/9] iio: magnetometer: bmc150: " Hans de Goede
2018-05-20 16:23 ` [PATCH 0/9] ACPI/i2c Enumerate several instances out of one fwnode Jonathan Cameron
2018-05-21 13:19 ` Lars-Peter Clausen
2018-05-21 9:19 ` Andy Shevchenko
2018-05-21 12:34 ` Hans de Goede
2018-05-21 13:13 ` Andy Shevchenko
2018-05-21 13:31 ` Lars-Peter Clausen
2018-05-21 13:40 ` Hans de Goede
2018-05-21 13:44 ` Hans de Goede
2018-05-21 15:07 ` Lars-Peter Clausen
2018-05-21 19:12 ` Hans de Goede
2018-05-22 7:59 ` Heikki Krogerus
2018-05-22 10:53 ` Jonathan Cameron
2018-05-22 11:40 ` Lars-Peter Clausen
2018-05-22 11:55 ` Hans de Goede
2018-05-22 12:02 ` Lars-Peter Clausen
2018-05-21 13:31 ` Hans de Goede [this message]
2018-05-24 8:55 ` Rafael J. Wysocki
2018-05-24 8:56 ` Hans de Goede
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=92663486-b96c-e87f-ad0e-9f50a03ee36b@redhat.com \
--to=hdegoede@redhat.com \
--cc=andriy.shevchenko@linux.intel.com \
--cc=jic23@kernel.org \
--cc=knaack.h@gmx.de \
--cc=lars@metafoo.de \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-iio@vger.kernel.org \
--cc=mika.westerberg@linux.intel.com \
--cc=rjw@rjwysocki.net \
--cc=wsa@the-dreams.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).