From: Dustin Byford <dustin@cumulusnetworks.com>
To: Mika Westerberg <mika.westerberg@linux.intel.com>
Cc: Wolfram Sang <wsa@the-dreams.de>,
linux-i2c@vger.kernel.org, linux-kernel@vger.kernel.org,
rjw@rjwysocki.net
Subject: Re: [PATCH 2/2] i2c: add ACPI support for I2C mux ports
Date: Mon, 12 Oct 2015 11:32:31 -0700 [thread overview]
Message-ID: <20151012183231.GB5909@cumulusnetworks.com> (raw)
In-Reply-To: <20151012105023.GX1506@lahna.fi.intel.com>
Hi Mika,
On Mon Oct 12 13:50, Mika Westerberg wrote:
> On Fri, Oct 09, 2015 at 05:41:47PM -0700, Dustin Byford wrote:
> > Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
> > device property compatible string match) enumerating I2C client devices
> > connected through a I2C mux device requires a little extra work.
> >
> > This change implements a method for describing an I2C device hierarchy that
> > includes mux devices by using an ACPI Device() for each mux channel along
> > with an _ADR to set the channel number for the device. See
> > Documentation/acpi/i2c-muxes.txt for a simple example.
> >
> > Signed-off-by: Dustin Byford <dustin@cumulusnetworks.com>
> > ---
> > Documentation/acpi/i2c-muxes.txt | 58 ++++++++++++++++++++++++++++++++++++++++
> > drivers/i2c/i2c-core.c | 18 +++++++++++--
> > drivers/i2c/i2c-mux.c | 8 ++++++
> > 3 files changed, 82 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/acpi/i2c-muxes.txt
> >
> > diff --git a/Documentation/acpi/i2c-muxes.txt b/Documentation/acpi/i2c-muxes.txt
> > new file mode 100644
> > index 0000000..efdcf0d
> > --- /dev/null
> > +++ b/Documentation/acpi/i2c-muxes.txt
> > @@ -0,0 +1,58 @@
> > +ACPI I2C Muxes
> > +--------------
> > +
> > +Describing an I2C device hierarchy that includes I2C muxes requires an ACPI
> > +Device() scope per mux channel.
> > +
> > +Consider this topology:
> > +
> > ++------+ +------+
> > +| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
> > +| | | 0x70 |--CH01--> i2c client B (0x50)
> > ++------+ +------+
> > +
> > +which corresponds to the following ASL:
> > +
> > +Device(SMB1)
> > +{
> > + Name (_HID, ...)
> > + Device(MUX0)
>
> Nit: please be consistent:
>
> Name ()
> Device ()
Sure thing.
> > + {
> > + Name (_HID, ...)
> > + Name (_CRS, ResourceTemplate () {
> > + I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
> > + AddressingMode7Bit, "^SMB1", 0x00,
> > + ResourceConsumer,,)
> > + }
> > +
> > + Device(CH00)
> > + {
> > + Name (_ADR, 0)
> > +
> > + Device(CLIA)
> > + {
> > + Name (_HID, ...)
> > + Name (_CRS, ResourceTemplate () {
> > + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
> > + AddressingMode7Bit, "^CH00", 0x00,
> > + ResourceConsumer,,)
> > + }
> > + }
> > + }
> > +
> > + Device(CH01)
> > + {
> > + Name (_ADR, 1)
> > +
> > + Device(CLIB)
> > + {
> > + Name (_HID, ...)
> > + Name (_CRS, ResourceTemplate () {
> > + I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
> > + AddressingMode7Bit, "^CH01", 0x00,
> > + ResourceConsumer,,)
> > + }
> > + }
> > + }
> > + }
> > +}
> > diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
> > index 3a4c54e..a2de010 100644
> > --- a/drivers/i2c/i2c-core.c
> > +++ b/drivers/i2c/i2c-core.c
> > @@ -156,7 +156,10 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle, u32 level,
> > info.fwnode = acpi_fwnode_handle(adev);
> >
> > memset(&lookup, 0, sizeof(lookup));
> > - lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
> > + if (i2c_parent_is_i2c_adapter(adapter))
> > + lookup.adapter_handle = ACPI_HANDLE(&adapter->dev);
> > + else
> > + lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
>
> So I don't really like this.
I don't love it either.
> Isn't there any other way to figure out the right companion for the
> device?
I've been trying to consider the options, perhaps you can help my
understanding. Using the i801 driver as an example, the device is PCI
and the companion is associated with the PCI dev. The driver creates
another device for the I2C interface (parented by the PCI device) by
calling i2c_add_adapter(). The I2C dev has no ACPI companion.
In the case of an I2C mux port, I've used acpi_preset_companion() to
associate each mux port I2C device with a ACPI node. Unlike the i801,
which has a single port, these companions are one per channel. It's not
an option to associate them all with the I2C mux device.
It seems like the options are to:
a) Special case the I2C mux to use the per-port I2C companions as I've
done here.
b) Move (or copy?) the companion from the i801 PCI dev to the i801 I2C
dev. Then we would always look in the same place for the companion.
I think this approach has some advantages, at least it would make
more sense if an I2C PCI controller had more than one I2C port, but
I'm not sure that case exists. I didn't pursue this approach because
it was specifically avoided in change b34bb1ee.
What do you think? I'd be happy to try out any ideas you have.
Thanks,
--Dustin
next prev parent reply other threads:[~2015-10-12 18:32 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-13 23:59 [RFC PATCH 0/1] i2c: scan ACPI enumerated I2C mux channels Dustin Byford
2015-08-13 23:59 ` Dustin Byford
2015-08-13 23:59 ` [RFC PATCH 1/1] i2c: acpi: " Dustin Byford
[not found] ` <1439510358-16664-1-git-send-email-dustin-qUQiAmfTcIp+XZJcv9eMoEEOCMrvLtNR@public.gmane.org>
2015-08-14 19:31 ` [RFC v2 0/1] " Dustin Byford
2015-08-14 19:31 ` Dustin Byford
2015-08-14 19:31 ` [RFC v2 1/1] " Dustin Byford
2015-10-09 21:42 ` Wolfram Sang
2015-10-09 21:50 ` Dustin Byford
2015-10-09 21:51 ` Wolfram Sang
2015-08-15 20:22 ` [RFC v2 0/1] " Wolfram Sang
2015-08-17 12:03 ` Mika Westerberg
2015-08-17 19:00 ` Dustin Byford
2015-09-29 23:19 ` Dustin Byford
2015-09-30 9:43 ` Mika Westerberg
2015-09-30 12:52 ` Rafael J. Wysocki
2015-09-30 13:57 ` Mika Westerberg
2015-09-30 17:54 ` Dustin Byford
2015-10-10 0:41 ` [PATCH 0/2] " Dustin Byford
2015-10-10 0:41 ` [PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections Dustin Byford
2015-10-12 10:46 ` Mika Westerberg
2015-10-12 11:20 ` Andy Shevchenko
2015-10-12 17:00 ` Dustin Byford
2015-10-12 19:01 ` Rafael J. Wysocki
2015-10-12 18:57 ` Dustin Byford
2015-10-10 0:41 ` [PATCH 2/2] i2c: add ACPI support for I2C mux ports Dustin Byford
2015-10-10 1:03 ` kbuild test robot
2015-10-12 10:50 ` Mika Westerberg
2015-10-12 18:32 ` Dustin Byford [this message]
2015-10-13 11:32 ` Mika Westerberg
2015-10-19 9:01 ` [PATCH v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels Dustin Byford
2015-10-19 22:28 ` [PATCH v3 " Dustin Byford
2015-10-19 22:29 ` [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports Dustin Byford
2015-10-20 9:16 ` Andy Shevchenko
2015-10-20 12:51 ` Mika Westerberg
2015-10-20 17:49 ` Dustin Byford
2015-10-20 23:13 ` Rafael J. Wysocki
2015-10-21 8:12 ` Mika Westerberg
2015-10-21 8:21 ` Dustin Byford
2015-10-21 8:34 ` Mika Westerberg
2015-10-21 8:52 ` Dustin Byford
2015-10-21 9:08 ` Mika Westerberg
2015-10-21 9:25 ` Dustin Byford
2015-10-21 22:39 ` Rafael J. Wysocki
2015-10-22 9:27 ` Dustin Byford
2015-10-20 23:12 ` Rafael J. Wysocki
2015-10-21 8:02 ` Mika Westerberg
2015-10-22 9:17 ` [PATCH v4 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels Dustin Byford
2015-10-22 9:17 ` [PATCH v4 1/2] acpi: add acpi_preset_companion() stub Dustin Byford
2015-10-23 8:33 ` Mika Westerberg
2015-10-25 13:40 ` Rafael J. Wysocki
2015-10-25 15:01 ` Rafael J. Wysocki
2015-10-22 9:17 ` [PATCH v4 2/2] i2c: add ACPI support for I2C mux ports Dustin Byford
2015-10-23 8:40 ` Mika Westerberg
2015-10-23 10:16 ` Wolfram Sang
2015-10-23 13:13 ` Mika Westerberg
2015-10-23 13:40 ` Mika Westerberg
2015-10-23 13:40 ` Mika Westerberg
2015-10-23 13:55 ` Jarkko Nikula
2015-10-23 19:27 ` [PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels Dustin Byford
2015-10-23 19:27 ` [PATCH v5 1/2] acpi: add acpi_preset_companion() stub Dustin Byford
2015-10-24 16:41 ` Wolfram Sang
2015-10-25 15:00 ` Rafael J. Wysocki
2015-10-23 19:27 ` [PATCH v5 2/2] i2c: add ACPI support for I2C mux ports Dustin Byford
2015-10-25 14:53 ` [PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels Wolfram Sang
2015-10-25 15:15 ` Dustin Byford
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=20151012183231.GB5909@cumulusnetworks.com \
--to=dustin@cumulusnetworks.com \
--cc=linux-i2c@vger.kernel.org \
--cc=linux-kernel@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.