Re: [PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
On Sun Oct 25 15:53, Wolfram Sang wrote: > On Fri, Oct 23, 2015 at 12:27:05PM -0700, Dustin Byford wrote: > > v5: > > - rebased on i2c/for-next (Jarkko, Wolfram) > > - include acpi.h in designware drivers (Mika) > > - remove return from void stub function (Mika) > > - add acks and tested-by from Mika > > Applied to for-next, thanks! Thanks for the reviews everyone. > In the future, when you send new versions, please don't set In-Reply-To > to the old version, just leave it empty. I (and most maintainers I know) > find it easier to work when patches arrive chronologically. OK, will do. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
On Sun Oct 25 15:53, Wolfram Sang wrote: > On Fri, Oct 23, 2015 at 12:27:05PM -0700, Dustin Byford wrote: > > v5: > > - rebased on i2c/for-next (Jarkko, Wolfram) > > - include acpi.h in designware drivers (Mika) > > - remove return from void stub function (Mika) > > - add acks and tested-by from Mika > > Applied to for-next, thanks! Thanks for the reviews everyone. > In the future, when you send new versions, please don't set In-Reply-To > to the old version, just leave it empty. I (and most maintainers I know) > find it easier to work when patches arrive chronologically. OK, will do. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 1/2] acpi: add acpi_preset_companion() stub
Add a stub for acpi_preset_companion(). Fixes build failures when
acpi_preset_companion() is used and CONFIG_ACPI is not set.
Acked-by: Mika Westerberg
Signed-off-by: Dustin Byford
---
include/linux/acpi.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 43856d1..43b55e7 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -477,6 +477,11 @@ static inline bool has_acpi_companion(struct device *dev)
return false;
}
+static inline void acpi_preset_companion(struct device *dev,
+struct acpi_device *parent, u64 addr)
+{
+}
+
static inline const char *acpi_dev_name(struct acpi_device *adev)
{
return NULL;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] i2c: add ACPI support for I2C mux ports
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs 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.
To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF. This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Acked-by: Mika Westerberg
Tested-by: Mika Westerberg
Signed-off-by: Dustin Byford
---
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
7 files changed, 76 insertions(+), 14 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 000..9fcc4f0
--- /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)
+{
+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/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 169be1e..1543d35d 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "i2c-designware-core.h"
#define DRIVER_NAME "i2c-designware-pci"
@@ -244,6 +245,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap = >adapter;
adap->owner = THIS_MODULE;
adap->class = 0;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->nr = controller->bus_num;
r = i2c_dw_probe(dev);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index c9dc31a..809579e 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -227,6 +227,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
adap = >adapter;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
if (dev->pm_runtime_disabled) {
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eaef9bc..d4a6e77 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1251,6 +1251,9 @@ static int i801_probe(struct pci_dev *dev, const struct
pci_device_id *id)
priv->adapter.owner = THIS_MODULE;
priv->adapter.class = i801_get_adapter_class(priv);
priv->adapter.algo = _algorithm;
+ priv->adapter.dev.parent = >dev;
+ ACPI_COMPANION_SET(>adapter.dev, ACPI_COMPANION(>dev));
+
[PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
v5:
- rebased on i2c/for-next (Jarkko, Wolfram)
- include acpi.h in designware drivers (Mika)
- remove return from void stub function (Mika)
- add acks and tested-by from Mika
v4:
- Moved the acpi_preset_companion() stub to a separate patch.
- Moved ACPI companion set from i2c-core to i801, ismt, and designware
drivers. With a minor rearrangement it was much easier to verify the
drivers are all consistent (hopefully a little extra churn is warranted)
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
The following series adds support for describing ACPI enumerated I2C mux
ports like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
Thanks,
--Dustin
Dustin Byford (2):
acpi: add acpi_preset_companion() stub
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
include/linux/acpi.h| 5 +++
8 files changed, 81 insertions(+), 14 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
v5:
- rebased on i2c/for-next (Jarkko, Wolfram)
- include acpi.h in designware drivers (Mika)
- remove return from void stub function (Mika)
- add acks and tested-by from Mika
v4:
- Moved the acpi_preset_companion() stub to a separate patch.
- Moved ACPI companion set from i2c-core to i801, ismt, and designware
drivers. With a minor rearrangement it was much easier to verify the
drivers are all consistent (hopefully a little extra churn is warranted)
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
The following series adds support for describing ACPI enumerated I2C mux
ports like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
Thanks,
--Dustin
Dustin Byford (2):
acpi: add acpi_preset_companion() stub
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
include/linux/acpi.h| 5 +++
8 files changed, 81 insertions(+), 14 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v5 2/2] i2c: add ACPI support for I2C mux ports
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs 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.
To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF. This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Acked-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Tested-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com>
---
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 2 +
drivers/i2c/busses/i2c-designware-platdrv.c | 1 +
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
7 files changed, 76 insertions(+), 14 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 000..9fcc4f0
--- /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)
+{
+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/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index 169be1e..1543d35d 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include "i2c-designware-core.h"
#define DRIVER_NAME "i2c-designware-pci"
@@ -244,6 +245,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap = >adapter;
adap->owner = THIS_MODULE;
adap->class = 0;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->nr = controller->bus_num;
r = i2c_dw_probe(dev);
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index c9dc31a..809579e 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -227,6 +227,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
adap = >adapter;
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
if (dev->pm_runtime_disabled) {
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eaef9bc..d4a6e77 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1251,6 +1251,9 @@ static int i801_probe(struct pci_dev *dev, const struct
pci_device_id *id)
priv->adapter.owner = THIS_MODULE;
priv->adapter.class = i801_get_adapter_class(priv);
priv->adapter.algo = _algorithm;
+
[PATCH v5 1/2] acpi: add acpi_preset_companion() stub
Add a stub for acpi_preset_companion(). Fixes build failures when
acpi_preset_companion() is used and CONFIG_ACPI is not set.
Acked-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com>
---
include/linux/acpi.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 43856d1..43b55e7 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -477,6 +477,11 @@ static inline bool has_acpi_companion(struct device *dev)
return false;
}
+static inline void acpi_preset_companion(struct device *dev,
+struct acpi_device *parent, u64 addr)
+{
+}
+
static inline const char *acpi_dev_name(struct acpi_device *adev)
{
return NULL;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] i2c: add ACPI support for I2C mux ports
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs 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.
To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF. This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Signed-off-by: Dustin Byford
---
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++-
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
7 files changed, 78 insertions(+), 16 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 000..9fcc4f0
--- /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)
+{
+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/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index df23e8c..5b9dcdb 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -256,6 +256,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap->class = 0;
adap->algo = _dw_algo;
adap->dev.parent = >dev;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->nr = controller->bus_num;
snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci");
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 472b882..9efeac6 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -267,12 +267,14 @@ static int dw_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(adap, dev);
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
- strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
- sizeof(adap->name));
adap->algo = _dw_algo;
adap->dev.parent = >dev;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
+ strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
+ sizeof(adap->name));
+
if (dev->pm_runtime_disabled) {
pm_runtime_forbid(>dev);
} else {
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eaef9bc..d4a6e77 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1251,6 +1251,9 @@ static int i801_probe(struct pci_dev *dev, const struct
pci_device_id *id)
priv->adapter.owner = THIS_M
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Thu Oct 22 00:39, Rafael J. Wysocki wrote: > Hi, > > On Wed, Oct 21, 2015 at 11:25 AM, Dustin Byford > wrote: > > On Wed Oct 21 12:08, Mika Westerberg wrote: > >> I don't really have strong feelings whether it should be the I2C core or > >> individual drivers setting the ACPI companion. However, it would be nice > >> to match DT here and they assign their of_node per driver. > > > > OK with me, if we can convince Rafael this is a good idea, I'll send a > > new revision with drivers setting the companion. > > If you can guarantee that ACPI PM or anything like _DS or _SRS will > never be invoked for the device objects that "inherit" the ACPI > companion from their parent, it at least is not outright dangerous. I'm hoping an ack from Mika will suffice, but please let me know if there's something I can do to verify or help ensure this. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 1/2] acpi: add acpi_preset_companion() stub
Add a stub for acpi_preset_companion(). Fixes build failures when
acpi_preset_companion() is used and CONFIG_ACPI is not set.
Signed-off-by: Dustin Byford
---
include/linux/acpi.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 51a96a8..66564f8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -505,6 +505,12 @@ static inline bool has_acpi_companion(struct device *dev)
return false;
}
+static inline void acpi_preset_companion(struct device *dev,
+struct acpi_device *parent, u64 addr)
+{
+ return;
+}
+
static inline const char *acpi_dev_name(struct acpi_device *adev)
{
return NULL;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
The following series adds support for describing ACPI enumerated I2C mux
ports like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v4:
- Moved the acpi_preset_companion() stub to a separate patch.
- Moved ACPI companion set from i2c-core to i801, ismt, and designware
drivers. With a minor rearrangement it was much easier to verify the
drivers are all consistent (hopefully a little extra churn is warranted)
I was able to test i801 and ismt myself, but I could use some help making
sure the designware driver is OK since I don't have the hardware.
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Thanks,
--Dustin
Dustin Byford (2):
acpi: add acpi_preset_companion() stub
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++-
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
include/linux/acpi.h| 6 +++
8 files changed, 84 insertions(+), 16 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Thu Oct 22 00:39, Rafael J. Wysocki wrote: > Hi, > > On Wed, Oct 21, 2015 at 11:25 AM, Dustin Byford > <dus...@cumulusnetworks.com> wrote: > > On Wed Oct 21 12:08, Mika Westerberg wrote: > >> I don't really have strong feelings whether it should be the I2C core or > >> individual drivers setting the ACPI companion. However, it would be nice > >> to match DT here and they assign their of_node per driver. > > > > OK with me, if we can convince Rafael this is a good idea, I'll send a > > new revision with drivers setting the companion. > > If you can guarantee that ACPI PM or anything like _DS or _SRS will > never be invoked for the device objects that "inherit" the ACPI > companion from their parent, it at least is not outright dangerous. I'm hoping an ack from Mika will suffice, but please let me know if there's something I can do to verify or help ensure this. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 2/2] i2c: add ACPI support for I2C mux ports
Although I2C mux devices are easily enumerated using ACPI (_HID/_CID or
device property compatible string match), enumerating I2C client devices
connected through an I2C mux needs 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.
To make this work the ismt, i801, and designware pci/platform devs now
share an ACPI companion with their I2C adapter dev similar to how it's done
in OF. This is done on the assumption that power management functions will
not be called directly on the I2C dev that is sharing the ACPI node.
Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com>
---
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++-
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
7 files changed, 78 insertions(+), 16 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 000..9fcc4f0
--- /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)
+{
+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/busses/i2c-designware-pcidrv.c
b/drivers/i2c/busses/i2c-designware-pcidrv.c
index df23e8c..5b9dcdb 100644
--- a/drivers/i2c/busses/i2c-designware-pcidrv.c
+++ b/drivers/i2c/busses/i2c-designware-pcidrv.c
@@ -256,6 +256,7 @@ static int i2c_dw_pci_probe(struct pci_dev *pdev,
adap->class = 0;
adap->algo = _dw_algo;
adap->dev.parent = >dev;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->nr = controller->bus_num;
snprintf(adap->name, sizeof(adap->name), "i2c-designware-pci");
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index 472b882..9efeac6 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -267,12 +267,14 @@ static int dw_i2c_probe(struct platform_device *pdev)
i2c_set_adapdata(adap, dev);
adap->owner = THIS_MODULE;
adap->class = I2C_CLASS_DEPRECATED;
- strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
- sizeof(adap->name));
adap->algo = _dw_algo;
adap->dev.parent = >dev;
+ ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
adap->dev.of_node = pdev->dev.of_node;
+ strlcpy(adap->name, "Synopsys DesignWare I2C adapter",
+ sizeof(adap->name));
+
if (dev->pm_runtime_disabled) {
pm_runtime_forbid(>dev);
} else {
diff --git a/drivers/i2c/busses/i2c-i801.c b/drivers/i2c/busses/i2c-i801.c
index eaef9bc..d4a6e77 100644
--- a/drivers/i2c/busses/i2c-i801.c
+++ b/drivers/i2c/busses/i2c-i801.c
@@ -1251,6 +1251,9 @@ static int i801_probe(struct pci_dev *dev, const struct
pci_device_id *id)
[PATCH v4 1/2] acpi: add acpi_preset_companion() stub
Add a stub for acpi_preset_companion(). Fixes build failures when
acpi_preset_companion() is used and CONFIG_ACPI is not set.
Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com>
---
include/linux/acpi.h | 6 ++
1 file changed, 6 insertions(+)
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 51a96a8..66564f8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -505,6 +505,12 @@ static inline bool has_acpi_companion(struct device *dev)
return false;
}
+static inline void acpi_preset_companion(struct device *dev,
+struct acpi_device *parent, u64 addr)
+{
+ return;
+}
+
static inline const char *acpi_dev_name(struct acpi_device *adev)
{
return NULL;
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v4 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
The following series adds support for describing ACPI enumerated I2C mux
ports like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v4:
- Moved the acpi_preset_companion() stub to a separate patch.
- Moved ACPI companion set from i2c-core to i801, ismt, and designware
drivers. With a minor rearrangement it was much easier to verify the
drivers are all consistent (hopefully a little extra churn is warranted)
I was able to test i801 and ismt myself, but I could use some help making
sure the designware driver is OK since I don't have the hardware.
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Thanks,
--Dustin
Dustin Byford (2):
acpi: add acpi_preset_companion() stub
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt| 58 +
drivers/i2c/busses/i2c-designware-pcidrv.c | 1 +
drivers/i2c/busses/i2c-designware-platdrv.c | 6 ++-
drivers/i2c/busses/i2c-i801.c | 9 ++---
drivers/i2c/busses/i2c-ismt.c | 8 +---
drivers/i2c/i2c-core.c | 4 +-
drivers/i2c/i2c-mux.c | 8
include/linux/acpi.h| 6 +++
8 files changed, 84 insertions(+), 16 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 12:08, Mika Westerberg wrote: > I don't really have strong feelings whether it should be the I2C core or > individual drivers setting the ACPI companion. However, it would be nice > to match DT here and they assign their of_node per driver. OK with me, if we can convince Rafael this is a good idea, I'll send a new revision with drivers setting the companion. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 11:34, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > > On Wed Oct 21 11:12, Mika Westerberg wrote: > > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > > > I considered it, but I thought a default that fairly closely matches the > > > > old behavior was more convenient. > > > > > > > > On the other hand, leaving it up to the controllers makes it all very > > > > explicit and perhaps simpler to reason about. > > > > > > > > > > > > I could be convinced either way. But, if we move it to the controller > > > > drivers, which ones need the change? > > > > > > > > grep -i acpi drivers/i2c/busses/i2c* > > > > > > > > shows 18 drivers that might care. > > > > > > I'm quite confident the designware I2C is enough for now. Intel uses it > > > for all SoCs with LPSS and I think AMD has the same block for their I2C > > > solution. > > > > I certainly care about i801, ismt, and isch. Doesn't this affect any > > i2c controller with clients that may be enumerated through ACPI? > > Yes, but so far I haven't seen any other devices being used for this > than the I2C designware. > > Which hardware you are testing this patch on? I'm working with a number of x86-based network switch platforms. Mostly rangeley at the moment, but I'm sure others are in the works. Have a look at: http://www.opencompute.org/wiki/Networking/SpecsAndDesigns for examples. My goal, hence the recent patches, is to help the network switch industry move a lot of platform description into ACPI. That means lots of complicated I2C trees; switches are full of I2C devices. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 11:12, Mika Westerberg wrote: > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > I considered it, but I thought a default that fairly closely matches the > > old behavior was more convenient. > > > > On the other hand, leaving it up to the controllers makes it all very > > explicit and perhaps simpler to reason about. > > > > > > I could be convinced either way. But, if we move it to the controller > > drivers, which ones need the change? > > > > grep -i acpi drivers/i2c/busses/i2c* > > > > shows 18 drivers that might care. > > I'm quite confident the designware I2C is enough for now. Intel uses it > for all SoCs with LPSS and I think AMD has the same block for their I2C > solution. I certainly care about i801, ismt, and isch. Doesn't this affect any i2c controller with clients that may be enumerated through ACPI? --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 12:08, Mika Westerberg wrote: > I don't really have strong feelings whether it should be the I2C core or > individual drivers setting the ACPI companion. However, it would be nice > to match DT here and they assign their of_node per driver. OK with me, if we can convince Rafael this is a good idea, I'll send a new revision with drivers setting the companion. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 11:12, Mika Westerberg wrote: > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > I considered it, but I thought a default that fairly closely matches the > > old behavior was more convenient. > > > > On the other hand, leaving it up to the controllers makes it all very > > explicit and perhaps simpler to reason about. > > > > > > I could be convinced either way. But, if we move it to the controller > > drivers, which ones need the change? > > > > grep -i acpi drivers/i2c/busses/i2c* > > > > shows 18 drivers that might care. > > I'm quite confident the designware I2C is enough for now. Intel uses it > for all SoCs with LPSS and I think AMD has the same block for their I2C > solution. I certainly care about i801, ismt, and isch. Doesn't this affect any i2c controller with clients that may be enumerated through ACPI? --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
On Wed Oct 21 11:34, Mika Westerberg wrote: > On Wed, Oct 21, 2015 at 01:21:16AM -0700, Dustin Byford wrote: > > On Wed Oct 21 11:12, Mika Westerberg wrote: > > > On Tue, Oct 20, 2015 at 10:49:59AM -0700, Dustin Byford wrote: > > > > I considered it, but I thought a default that fairly closely matches the > > > > old behavior was more convenient. > > > > > > > > On the other hand, leaving it up to the controllers makes it all very > > > > explicit and perhaps simpler to reason about. > > > > > > > > > > > > I could be convinced either way. But, if we move it to the controller > > > > drivers, which ones need the change? > > > > > > > > grep -i acpi drivers/i2c/busses/i2c* > > > > > > > > shows 18 drivers that might care. > > > > > > I'm quite confident the designware I2C is enough for now. Intel uses it > > > for all SoCs with LPSS and I think AMD has the same block for their I2C > > > solution. > > > > I certainly care about i801, ismt, and isch. Doesn't this affect any > > i2c controller with clients that may be enumerated through ACPI? > > Yes, but so far I haven't seen any other devices being used for this > than the I2C designware. > > Which hardware you are testing this patch on? I'm working with a number of x86-based network switch platforms. Mostly rangeley at the moment, but I'm sure others are in the works. Have a look at: http://www.opencompute.org/wiki/Networking/SpecsAndDesigns for examples. My goal, hence the recent patches, is to help the network switch industry move a lot of platform description into ACPI. That means lots of complicated I2C trees; switches are full of I2C devices. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
Hi Mika,
On Tue Oct 20 15:51, Mika Westerberg wrote:
> On Mon, Oct 19, 2015 at 03:29:00PM -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
>
> In general this looks good to me.
>
> > ---
> > Documentation/acpi/i2c-muxes.txt | 58
> >
> > drivers/i2c/i2c-core.c | 15 +--
> > drivers/i2c/i2c-mux.c| 8 ++
> > include/linux/acpi.h | 6 +
> > 4 files changed, 85 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/acpi/i2c-muxes.txt
> >
>
> [...]
>
> > + /*
> > +* By default, associate I2C adapters with their parent device's ACPI
> > +* node.
> > +*/
> > + if (!has_acpi_companion(dev)) {
> > + struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> > +
> > + if (adev)
> > + ACPI_COMPANION_SET(dev, adev);
>
> Instead of always doing this in the I2C core, maybe we can make it
> dependent on the host controller driver. For example the I2C designware
> driver already did this for both DT and ACPI:
I considered it, but I thought a default that fairly closely matches the
old behavior was more convenient.
On the other hand, leaving it up to the controllers makes it all very
explicit and perhaps simpler to reason about.
I could be convinced either way. But, if we move it to the controller
drivers, which ones need the change?
grep -i acpi drivers/i2c/busses/i2c*
shows 18 drivers that might care.
> adap->dev.parent = >dev;
> adap->dev.of_node = pdev->dev.of_node;
> ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
Interesting, this code isn't in my tree. I wonder why it was added,
what code looks at the acpi companion on the i2c dev? Before my change
it was supposed to be NULL, and it is NULL on every other controller.
> Also I would like to ask what Rafael thinks about this since he authored
> b34bb1ee71158d5b ("ACPI / I2C: Use parent's ACPI_HANDLE() in
> acpi_i2c_register_devices()").
>
> I don't see a problem multiple Linux devices sharing a single ACPI
> companion device like in this patch but I may be forgetting something ;-)
OK. Thanks.
--Dustin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
Hi Mika,
On Tue Oct 20 15:51, Mika Westerberg wrote:
> On Mon, Oct 19, 2015 at 03:29:00PM -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 <dus...@cumulusnetworks.com>
>
> In general this looks good to me.
>
> > ---
> > Documentation/acpi/i2c-muxes.txt | 58
> >
> > drivers/i2c/i2c-core.c | 15 +--
> > drivers/i2c/i2c-mux.c| 8 ++
> > include/linux/acpi.h | 6 +
> > 4 files changed, 85 insertions(+), 2 deletions(-)
> > create mode 100644 Documentation/acpi/i2c-muxes.txt
> >
>
> [...]
>
> > + /*
> > +* By default, associate I2C adapters with their parent device's ACPI
> > +* node.
> > +*/
> > + if (!has_acpi_companion(dev)) {
> > + struct acpi_device *adev = ACPI_COMPANION(dev->parent);
> > +
> > + if (adev)
> > + ACPI_COMPANION_SET(dev, adev);
>
> Instead of always doing this in the I2C core, maybe we can make it
> dependent on the host controller driver. For example the I2C designware
> driver already did this for both DT and ACPI:
I considered it, but I thought a default that fairly closely matches the
old behavior was more convenient.
On the other hand, leaving it up to the controllers makes it all very
explicit and perhaps simpler to reason about.
I could be convinced either way. But, if we move it to the controller
drivers, which ones need the change?
grep -i acpi drivers/i2c/busses/i2c*
shows 18 drivers that might care.
> adap->dev.parent = >dev;
> adap->dev.of_node = pdev->dev.of_node;
> ACPI_COMPANION_SET(>dev, ACPI_COMPANION(>dev));
Interesting, this code isn't in my tree. I wonder why it was added,
what code looks at the acpi companion on the i2c dev? Before my change
it was supposed to be NULL, and it is NULL on every other controller.
> Also I would like to ask what Rafael thinks about this since he authored
> b34bb1ee71158d5b ("ACPI / I2C: Use parent's ACPI_HANDLE() in
> acpi_i2c_register_devices()").
>
> I don't see a problem multiple Linux devices sharing a single ACPI
> companion device like in this patch but I may be forgetting something ;-)
OK. Thanks.
--Dustin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
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
---
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 15 +--
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 85 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 000..9fcc4f0
--- /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)
+{
+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 579b99d..af0811c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -156,7 +156,7 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
info.fwnode = acpi_fwnode_handle(adev);
memset(, 0, sizeof(lookup));
- lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.adapter_handle = ACPI_HANDLE(>dev);
lookup.device_handle = handle;
lookup.info =
@@ -212,7 +212,7 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
{
acpi_status status;
- if (!adap->dev.parent || !has_acpi_companion(adap->dev.parent))
+ if (!has_acpi_companion(>dev))
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
@@ -1667,6 +1667,17 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
struct device *dev = >dev;
int id;
+ /*
+* By default, associate I2C adapters with their parent device's ACPI
+* node.
+*/
+ if (!has_acpi_companion(dev)) {
+ struct acpi_device *adev = ACPI_COMPANION(dev->parent);
+
+ if (adev)
+ ACPI_COMPANION_SET(dev, adev);
+ }
+
if (dev->of_node) {
id = of_alias_get_id(dev->of_node, "i2c");
if (id >= 0) {
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..00fc5b1 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Associate the mux channel with an ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 51a96a8..66564f8 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -505,6 +
[PATCH v3 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
The following patch adds support for describing ACPI enumerated I2C mux ports
like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Dustin Byford (1):
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 15 +--
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 85 insertions(+), 2 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
The following patch adds support for describing ACPI enumerated I2C mux ports
like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Dustin Byford (1):
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 14 --
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
The following patch adds support for describing ACPI enumerated I2C mux ports
like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Dustin Byford (1):
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 14 --
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 84 insertions(+), 2 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v3 1/1] i2c: add ACPI support for I2C mux ports
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 <dus...@cumulusnetworks.com>
---
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 15 +--
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 85 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 000..9fcc4f0
--- /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)
+{
+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 579b99d..af0811c 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -156,7 +156,7 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
info.fwnode = acpi_fwnode_handle(adev);
memset(, 0, sizeof(lookup));
- lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.adapter_handle = ACPI_HANDLE(>dev);
lookup.device_handle = handle;
lookup.info =
@@ -212,7 +212,7 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
{
acpi_status status;
- if (!adap->dev.parent || !has_acpi_companion(adap->dev.parent))
+ if (!has_acpi_companion(>dev))
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
@@ -1667,6 +1667,17 @@ int i2c_add_adapter(struct i2c_adapter *adapter)
struct device *dev = >dev;
int id;
+ /*
+* By default, associate I2C adapters with their parent device's ACPI
+* node.
+*/
+ if (!has_acpi_companion(dev)) {
+ struct acpi_device *adev = ACPI_COMPANION(dev->parent);
+
+ if (adev)
+ ACPI_COMPANION_SET(dev, adev);
+ }
+
if (dev->of_node) {
id = of_alias_get_id(dev->of_node, "i2c");
if (id >= 0) {
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..00fc5b1 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Associate the mux channel with an ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 51a96a8..66564f8 100644
--- a/include/linux/acpi.h
+++ b/incl
[PATCH v3 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
The following patch adds support for describing ACPI enumerated I2C mux ports
like this (added as Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device (SMB1)
{
Name (_HID, ...)
Device (MUX0)
{
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,,)
}
}
}
}
}
v3:
- Correct to and cc list (sorry git-send-email trouble again)
v2:
- Drop duplicate patch already submitted by Andy Shevchenko (i2c / ACPI:
Rework I2C device scanning)
- Whitespace cleanup suggested by Mika
- Implement a acpi_preset_companion() stub for when CONFIG_ACPI is not set.
- Instead of special casing I2C muxes with regards to enumerating client
devices, make sure adap->dev always has an ACPI companion.
I based this on linux-pm/bleeding-edge, but now it depends on Andy's change
(i2c / ACPI: Rework I2C device scanning) and I don't know where the rest of
his patch set is going. Let me know if there's a more appropriate branch
and I'll be happy to rebase.
Dustin Byford (1):
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58
drivers/i2c/i2c-core.c | 15 +--
drivers/i2c/i2c-mux.c| 8 ++
include/linux/acpi.h | 6 +
4 files changed, 85 insertions(+), 2 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
On Mon Oct 12 21:01, Rafael J. Wysocki wrote: > On Friday, October 09, 2015 05:41:46 PM Dustin Byford wrote: > > An I2cSerialBus connection resource descriptor may indicate a > > ResourceSource (a string uniquely identifying the I2C bus controller) > > anywhere in the ACPI namespace. However, when enumerating connections to a > > I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only > > searching devices that are descendants of the bus controller. > > > > This change corrects acpi_i2c_register_devices() to walk the entire ACPI > > namespace searching for I2C connections. > > > > Suggested-by: Mika Westerberg > > Signed-off-by: Dustin Byford > > This one has already been submitted by Andy and I've ACKed it. Sorry, I missed that before I sent the patch. > I'm not sure what to do here, though. > > I guess I can apply this one and put it into a branch for others to pull from. > > Thoughts? I'd be OK if you just drop this patch and I won't include it in my next revision. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: add ACPI support for I2C mux ports
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
> > ---
> > 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 000..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(, 0, sizeof(lookup));
> > - lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
> > + if (i2c_parent_is_i2c_adapter(adapter))
> > + lookup.adapter_handle = ACPI_HANDLE(>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
Re: [PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
On Mon Oct 12 14:20, Andy Shevchenko wrote: > On Mon, 2015-10-12 at 13:46 +0300, Mika Westerberg wrote: > > On Fri, Oct 09, 2015 at 05:41:46PM -0700, Dustin Byford wrote: > > > An I2cSerialBus connection resource descriptor may indicate a > > > ResourceSource (a string uniquely identifying the I2C bus > > > controller) > > > anywhere in the ACPI namespace. However, when enumerating > > > connections to a > > > I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only > > > searching devices that are descendants of the bus controller. > > > > > > This change corrects acpi_i2c_register_devices() to walk the entire > > > ACPI > > > namespace searching for I2C connections. > > > > > > Suggested-by: Mika Westerberg > > > Signed-off-by: Dustin Byford > > > > This patch is already included in Andy's latest series adding support > > for Intel Galileo here: > > > > https://patchwork.ozlabs.org/patch/527231/ > > > > Maybe we can add your Tested-by/Reviewed-by to that patch instead? > > Indeed, the Tested-by tag would be much appreciated! OK, that works for me. I didn't realize it had been submitted elsewhere or I wouldn't have sent the duplicate. Thanks. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
On Mon Oct 12 14:20, Andy Shevchenko wrote: > On Mon, 2015-10-12 at 13:46 +0300, Mika Westerberg wrote: > > On Fri, Oct 09, 2015 at 05:41:46PM -0700, Dustin Byford wrote: > > > An I2cSerialBus connection resource descriptor may indicate a > > > ResourceSource (a string uniquely identifying the I2C bus > > > controller) > > > anywhere in the ACPI namespace. However, when enumerating > > > connections to a > > > I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only > > > searching devices that are descendants of the bus controller. > > > > > > This change corrects acpi_i2c_register_devices() to walk the entire > > > ACPI > > > namespace searching for I2C connections. > > > > > > Suggested-by: Mika Westerberg <mika.westerb...@linux.intel.com> > > > Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com> > > > > This patch is already included in Andy's latest series adding support > > for Intel Galileo here: > > > > https://patchwork.ozlabs.org/patch/527231/ > > > > Maybe we can add your Tested-by/Reviewed-by to that patch instead? > > Indeed, the Tested-by tag would be much appreciated! OK, that works for me. I didn't realize it had been submitted elsewhere or I wouldn't have sent the duplicate. Thanks. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/2] i2c: add ACPI support for I2C mux ports
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 <dus...@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 000..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(, 0, sizeof(lookup));
> > - lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
> > + if (i2c_parent_is_i2c_adapter(adapter))
> > + lookup.adapter_handle = ACPI_HANDLE(>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.
Re: [PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
On Mon Oct 12 21:01, Rafael J. Wysocki wrote: > On Friday, October 09, 2015 05:41:46 PM Dustin Byford wrote: > > An I2cSerialBus connection resource descriptor may indicate a > > ResourceSource (a string uniquely identifying the I2C bus controller) > > anywhere in the ACPI namespace. However, when enumerating connections to a > > I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only > > searching devices that are descendants of the bus controller. > > > > This change corrects acpi_i2c_register_devices() to walk the entire ACPI > > namespace searching for I2C connections. > > > > Suggested-by: Mika Westerberg <mika.westerb...@linux.intel.com> > > Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com> > > This one has already been submitted by Andy and I've ACKed it. Sorry, I missed that before I sent the patch. > I'm not sure what to do here, though. > > I guess I can apply this one and put it into a branch for others to pull from. > > Thoughts? I'd be OK if you just drop this patch and I won't include it in my next revision. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] i2c: add ACPI support for I2C mux ports
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
---
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 000..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)
+{
+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(, 0, sizeof(lookup));
- lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ if (i2c_parent_is_i2c_adapter(adapter))
+ lookup.adapter_handle = ACPI_HANDLE(>dev);
+ else
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
lookup.device_handle = handle;
lookup.info =
@@ -210,9 +213,20 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
*/
static void acpi_i2c_register_devices(struct i2c_adapter *adap)
{
+ struct device *dev;
acpi_status status;
- if (!adap->dev.parent || !has_acpi_companion(adap->dev.parent))
+ /*
+* Typically we look at the ACPI device's parent for an ACPI companion.
+* However, in the case of an I2C-connected I2C mux, the "virtual" I2C
+* adapter allocated for the mux channel has that association.
+*/
+ if (i2c_parent_is_i2c_adapter(adap))
+ dev = >dev;
+ else
+ dev = adap->dev.parent;
+
+ if (!has_acpi_companion(dev))
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..00fc5b1 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Associate the mux channel with an ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More m
[PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
An I2cSerialBus connection resource descriptor may indicate a
ResourceSource (a string uniquely identifying the I2C bus controller)
anywhere in the ACPI namespace. However, when enumerating connections to a
I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only
searching devices that are descendants of the bus controller.
This change corrects acpi_i2c_register_devices() to walk the entire ACPI
namespace searching for I2C connections.
Suggested-by: Mika Westerberg
Signed-off-by: Dustin Byford
---
drivers/i2c/i2c-core.c | 82 --
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5f89f1e..3a4c54e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -99,27 +99,40 @@ struct gsb_buffer {
};
} __packed;
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+ struct i2c_board_info *info;
+ acpi_handle adapter_handle;
+ acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
{
- struct i2c_board_info *info = data;
+ struct acpi_i2c_lookup *lookup = data;
+ struct i2c_board_info *info = lookup->info;
+ struct acpi_resource_i2c_serialbus *sb;
+ acpi_handle adapter_handle;
+ acpi_status status;
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
+ if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return 1;
- sb = >data.i2c_serial_bus;
- if (!info->addr && sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- info->flags |= I2C_CLIENT_TEN;
- }
- } else if (!info->irq) {
- struct resource r;
+ sb = >data.i2c_serial_bus;
+ if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return 1;
- if (acpi_dev_resource_interrupt(ares, 0, ))
- info->irq = r.start;
+ /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+ status = acpi_get_handle(lookup->device_handle,
+sb->resource_source.string_ptr,
+_handle);
+ if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
+ info->addr = sb->slave_address;
+ if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ info->flags |= I2C_CLIENT_TEN;
}
- /* Tell the ACPI core to skip this resource */
return 1;
}
@@ -128,6 +141,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
{
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+ struct acpi_i2c_lookup lookup;
+ struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -140,14 +155,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
+ memset(, 0, sizeof(lookup));
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.device_handle = handle;
+ lookup.info =
+
+ /*
+* Look up for I2cSerialBus resource with ResourceSource that
+* matches with this adapter.
+*/
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-acpi_i2c_add_resource, );
+acpi_i2c_find_address, );
acpi_dev_free_resource_list(_list);
if (ret < 0 || !info.addr)
return AE_OK;
+ /* Then fill IRQ number if any */
+ ret = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (ret < 0)
+ return AE_OK;
+
+ resource_list_for_each_entry(entry, _list) {
+ if (resource_type(entry->res) == IORESOURCE_IRQ) {
+ info.irq = entry->res->start;
+ break;
+ }
+ }
+
+ acpi_dev_free_resource_list(_list);
+
adev->power.flags.ignore_parent = true;
strlcpy(info.type, dev_name(>dev), sizeof(info.type));
if (!i2c_new_device(adapter, )) {
@@ -160,6 +198,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
return AE_OK;
}
+#define ACPI_I2C_MAX_SCAN_DEPTH 32
+
/**
* acpi_i2c_register_devices - enumerate I2C slave devices behind adapter
* @adap: pointer to adapter
@@ -
[PATCH 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
Two patches ready from my RFC. The first, from Mika scans more of the ACPI
namespace looking for I2C connections. It's not strictly a dependency of
the other patch but they are easy to review together. I was able to test
this by overriding my DSDT and moving I2C resource macros around in the
device hierarchy.
The next adds support for describing I2C mux ports like this (added as
Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device(SMB1)
{
Name (_HID, ...)
Device(MUX0)
{
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,,)
}
}
}
}
}
Dustin Byford (2):
i2c: scan entire ACPI namespace for I2C connections
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58 +
drivers/i2c/i2c-core.c | 94 ++--
drivers/i2c/i2c-mux.c| 8
3 files changed, 138 insertions(+), 22 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Hi Wolfram, On Fri Oct 09 22:42, Wolfram Sang wrote: > On Fri, Aug 14, 2015 at 12:31:33PM -0700, Dustin Byford wrote: > > > > Set an ACPI companion for I2C mux channels enumerated through ACPI and > > ensure they are scanned for devices. > > > > Signed-off-by: Dustin Byford > > Mika, is this one okay with you? I'm working on a revision that incorporates Mika's suggested patch I think you'll want to wait just a bit for that. Thanks, --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] i2c: add ACPI support for I2C mux ports
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 <dus...@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 000..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)
+{
+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(, 0, sizeof(lookup));
- lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ if (i2c_parent_is_i2c_adapter(adapter))
+ lookup.adapter_handle = ACPI_HANDLE(>dev);
+ else
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
lookup.device_handle = handle;
lookup.info =
@@ -210,9 +213,20 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
*/
static void acpi_i2c_register_devices(struct i2c_adapter *adap)
{
+ struct device *dev;
acpi_status status;
- if (!adap->dev.parent || !has_acpi_companion(adap->dev.parent))
+ /*
+* Typically we look at the ACPI device's parent for an ACPI companion.
+* However, in the case of an I2C-connected I2C mux, the "virtual" I2C
+* adapter allocated for the mux channel has that association.
+*/
+ if (i2c_parent_is_i2c_adapter(adap))
+ dev = >dev;
+ else
+ dev = adap->dev.parent;
+
+ if (!has_acpi_companion(dev))
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, ACPI_ROOT_OBJECT,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..00fc5b1 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Associate the mux channel with an ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
[PATCH 1/2] i2c: scan entire ACPI namespace for I2C connections
An I2cSerialBus connection resource descriptor may indicate a
ResourceSource (a string uniquely identifying the I2C bus controller)
anywhere in the ACPI namespace. However, when enumerating connections to a
I2C bus controller, i2c-core.c:acpi_i2c_register_devices() as only
searching devices that are descendants of the bus controller.
This change corrects acpi_i2c_register_devices() to walk the entire ACPI
namespace searching for I2C connections.
Suggested-by: Mika Westerberg <mika.westerb...@linux.intel.com>
Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com>
---
drivers/i2c/i2c-core.c | 82 --
1 file changed, 59 insertions(+), 23 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index 5f89f1e..3a4c54e 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -99,27 +99,40 @@ struct gsb_buffer {
};
} __packed;
-static int acpi_i2c_add_resource(struct acpi_resource *ares, void *data)
+struct acpi_i2c_lookup {
+ struct i2c_board_info *info;
+ acpi_handle adapter_handle;
+ acpi_handle device_handle;
+};
+
+static int acpi_i2c_find_address(struct acpi_resource *ares, void *data)
{
- struct i2c_board_info *info = data;
+ struct acpi_i2c_lookup *lookup = data;
+ struct i2c_board_info *info = lookup->info;
+ struct acpi_resource_i2c_serialbus *sb;
+ acpi_handle adapter_handle;
+ acpi_status status;
- if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
- struct acpi_resource_i2c_serialbus *sb;
+ if (info->addr || ares->type != ACPI_RESOURCE_TYPE_SERIAL_BUS)
+ return 1;
- sb = >data.i2c_serial_bus;
- if (!info->addr && sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
- info->addr = sb->slave_address;
- if (sb->access_mode == ACPI_I2C_10BIT_MODE)
- info->flags |= I2C_CLIENT_TEN;
- }
- } else if (!info->irq) {
- struct resource r;
+ sb = >data.i2c_serial_bus;
+ if (sb->type != ACPI_RESOURCE_SERIAL_TYPE_I2C)
+ return 1;
- if (acpi_dev_resource_interrupt(ares, 0, ))
- info->irq = r.start;
+ /*
+* Extract the ResourceSource and make sure that the handle matches
+* with the I2C adapter handle.
+*/
+ status = acpi_get_handle(lookup->device_handle,
+sb->resource_source.string_ptr,
+_handle);
+ if (ACPI_SUCCESS(status) && adapter_handle == lookup->adapter_handle) {
+ info->addr = sb->slave_address;
+ if (sb->access_mode == ACPI_I2C_10BIT_MODE)
+ info->flags |= I2C_CLIENT_TEN;
}
- /* Tell the ACPI core to skip this resource */
return 1;
}
@@ -128,6 +141,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
{
struct i2c_adapter *adapter = data;
struct list_head resource_list;
+ struct acpi_i2c_lookup lookup;
+ struct resource_entry *entry;
struct i2c_board_info info;
struct acpi_device *adev;
int ret;
@@ -140,14 +155,37 @@ static acpi_status acpi_i2c_add_device(acpi_handle
handle, u32 level,
memset(, 0, sizeof(info));
info.fwnode = acpi_fwnode_handle(adev);
+ memset(, 0, sizeof(lookup));
+ lookup.adapter_handle = ACPI_HANDLE(adapter->dev.parent);
+ lookup.device_handle = handle;
+ lookup.info =
+
+ /*
+* Look up for I2cSerialBus resource with ResourceSource that
+* matches with this adapter.
+*/
INIT_LIST_HEAD(_list);
ret = acpi_dev_get_resources(adev, _list,
-acpi_i2c_add_resource, );
+acpi_i2c_find_address, );
acpi_dev_free_resource_list(_list);
if (ret < 0 || !info.addr)
return AE_OK;
+ /* Then fill IRQ number if any */
+ ret = acpi_dev_get_resources(adev, _list, NULL, NULL);
+ if (ret < 0)
+ return AE_OK;
+
+ resource_list_for_each_entry(entry, _list) {
+ if (resource_type(entry->res) == IORESOURCE_IRQ) {
+ info.irq = entry->res->start;
+ break;
+ }
+ }
+
+ acpi_dev_free_resource_list(_list);
+
adev->power.flags.ignore_parent = true;
strlcpy(info.type, dev_name(>dev), sizeof(info.type));
if (!i2c_new_device(adapter, )) {
@@ -160,6 +198,8 @@ static acpi_status acpi_i2c_add_device(acpi_handle handle,
u32 level,
return AE_OK;
}
+#define ACPI_I2C_MAX_SCAN_DEPTH 32
+
/**
* acpi_i2c_register_devic
[PATCH 0/2] i2c: acpi: scan ACPI enumerated I2C mux channels
Two patches ready from my RFC. The first, from Mika scans more of the ACPI
namespace looking for I2C connections. It's not strictly a dependency of
the other patch but they are easy to review together. I was able to test
this by overriding my DSDT and moving I2C resource macros around in the
device hierarchy.
The next adds support for describing I2C mux ports like this (added as
Documentation/acpi/i2c-muxes.txt):
+--+ +--+
| SMB1 |-->| MUX0 |--CH00--> i2c client A (0x50)
| | | 0x70 |--CH01--> i2c client B (0x50)
+--+ +--+
Device(SMB1)
{
Name (_HID, ...)
Device(MUX0)
{
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,,)
}
}
}
}
}
Dustin Byford (2):
i2c: scan entire ACPI namespace for I2C connections
i2c: add ACPI support for I2C mux ports
Documentation/acpi/i2c-muxes.txt | 58 +
drivers/i2c/i2c-core.c | 94 ++--
drivers/i2c/i2c-mux.c| 8
3 files changed, 138 insertions(+), 22 deletions(-)
create mode 100644 Documentation/acpi/i2c-muxes.txt
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Hi Wolfram, On Fri Oct 09 22:42, Wolfram Sang wrote: > On Fri, Aug 14, 2015 at 12:31:33PM -0700, Dustin Byford wrote: > > > > Set an ACPI companion for I2C mux channels enumerated through ACPI and > > ensure they are scanned for devices. > > > > Signed-off-by: Dustin Byford <dus...@cumulusnetworks.com> > > Mika, is this one okay with you? I'm working on a revision that incorporates Mika's suggested patch I think you'll want to wait just a bit for that. Thanks, --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/6] ACPI / properties: Hierarchical properties support
On Thu Aug 27 04:34, Rafael J. Wysocki wrote:
Hi Rafael,
> The issue at hand is that we need to be able to support hierarchical device
> properties in ACPI, like when the set of properties of an entity called "Fred"
> may include a subset called "dog" containing the properties of the Fred's dog
> rather than those of Fred himself. And it may make sense to have the same
> property, like "hair color", for both Fred and the dog, but with different
> values.
OK. I have a couple of questions.
> We (I, Darren and Dave at least) have explored many possible ways to deal with
> that in ACPI, but the majority of them turned out to be unattractive for
> various
> reasons. Our first take was to use ACPI device objects to make the "child"
> property sets available via _DSD, but that approach is generally incompatible
> with the PnP Manager in Windows following the notion that all device objects
> in ACPI tables are supposed to represent real devices. It can still be made
> work by adding _STA that returns 0 to those "property-only" device objects,
> but that leads to complications in other places and is error prone (if the
> _STA
> is forgotten, for example). Moreover, it adds quite a bit of overhead even in
> Linux (an ACPICA representation, struct acpi_device, driver core mechanics
> etc)
> for things that are only supposed to represent sets of device properties.
> And,
> in addition to that, we'd need to figure out how to give those things
> arbitrary
> names in a consistent way. All of that caused us to drop the approach based
> on
> device objects and look for other options.
What's the overhead/effect on Windows for an ACPI object without a _HID (_ADR
only)? That seems like a case where the OS shouldn't be expecting to load
another driver for the ACPI object and the _ADR gives each node a unique name
(even if it is an unfriendly integer)
> The idea is that _DSD may return a package containing the properties of the
> device it belongs to along with a directory of objects that need to be
> evaluated
> in order to obtain the "child" property sets of it. That directory needs to
> be
> present in a separate section of the _DSD package (after the new UUID defined
> in
> the above document) and is a list of two-element sub-packages (entries) where
> the first element is the name of the entry (the name of the "child" property
> set
> represented by it) and the second element is a "pointer" (essentially, a path
> or "namestring" in the ACPI terminology) to the control method or a static
> data package that needs to be evaluated to obtain the entry's data. The data
> returned by it is then interpreted in the same way as a _DSD return package,
> so it may also contain properties and a directory of its own "child" property
> sets.
Do you expect there to be cases where using an ACPI device object is more
desirable than hierarchical properties? Or is it just impossible given the PNP
manager in Windows?
The best example I can think of is perhaps a multi function device where each
sub-function really does look like a separate device and you probably want to
reference that sub-device, as a device, in other ASL code.
Stating the above more generally, by taking this approach you loose the ability
to reference these child nodes as a device object. In this LED example, I
think it would be nice to set the "trigger" for the led by adding a reference
to the LED from another device (such as a NIC).
Device (NIC0)
{
...
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"activity-led", LEDS.LEDM },
Package () {"link-led", LEDS.LEDH },
},
}
}
I'm not sure that's even supported in devicetree or LEDs are the best example
of this, but the pattern seems generally useful.
Without a device you're also forced to use a "label" property instead of a
_STR.
> As an example, consider the following ASL from an experimental MinnowBoard
> firmware:
>
> Device (LEDS)
> {
> Name (_HID, "PRP0001")
>
> Name (_CRS, ResourceTemplate () {
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {10}
> GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
> "\\_SB.PCI0.LPC", 0, ResourceConsumer) {11}
> })
>
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"gpio-leds"}},
> },
> // Data extension
> ToUUID("dbb8e3e6-5886-4ba6-8795-1319f52a966b"),
> Package () {
> Package () {"heartbeat", "LEDH"},
> Package () {"mmc-activity", "LEDM"},
I guess LEDH and LEDM have to be strings here. It would be
Re: [PATCH 0/6] ACPI / properties: Hierarchical properties support
On Thu Aug 27 04:34, Rafael J. Wysocki wrote:
Hi Rafael,
The issue at hand is that we need to be able to support hierarchical device
properties in ACPI, like when the set of properties of an entity called Fred
may include a subset called dog containing the properties of the Fred's dog
rather than those of Fred himself. And it may make sense to have the same
property, like hair color, for both Fred and the dog, but with different
values.
OK. I have a couple of questions.
We (I, Darren and Dave at least) have explored many possible ways to deal with
that in ACPI, but the majority of them turned out to be unattractive for
various
reasons. Our first take was to use ACPI device objects to make the child
property sets available via _DSD, but that approach is generally incompatible
with the PnP Manager in Windows following the notion that all device objects
in ACPI tables are supposed to represent real devices. It can still be made
work by adding _STA that returns 0 to those property-only device objects,
but that leads to complications in other places and is error prone (if the
_STA
is forgotten, for example). Moreover, it adds quite a bit of overhead even in
Linux (an ACPICA representation, struct acpi_device, driver core mechanics
etc)
for things that are only supposed to represent sets of device properties.
And,
in addition to that, we'd need to figure out how to give those things
arbitrary
names in a consistent way. All of that caused us to drop the approach based
on
device objects and look for other options.
What's the overhead/effect on Windows for an ACPI object without a _HID (_ADR
only)? That seems like a case where the OS shouldn't be expecting to load
another driver for the ACPI object and the _ADR gives each node a unique name
(even if it is an unfriendly integer)
The idea is that _DSD may return a package containing the properties of the
device it belongs to along with a directory of objects that need to be
evaluated
in order to obtain the child property sets of it. That directory needs to
be
present in a separate section of the _DSD package (after the new UUID defined
in
the above document) and is a list of two-element sub-packages (entries) where
the first element is the name of the entry (the name of the child property
set
represented by it) and the second element is a pointer (essentially, a path
or namestring in the ACPI terminology) to the control method or a static
data package that needs to be evaluated to obtain the entry's data. The data
returned by it is then interpreted in the same way as a _DSD return package,
so it may also contain properties and a directory of its own child property
sets.
Do you expect there to be cases where using an ACPI device object is more
desirable than hierarchical properties? Or is it just impossible given the PNP
manager in Windows?
The best example I can think of is perhaps a multi function device where each
sub-function really does look like a separate device and you probably want to
reference that sub-device, as a device, in other ASL code.
Stating the above more generally, by taking this approach you loose the ability
to reference these child nodes as a device object. In this LED example, I
think it would be nice to set the trigger for the led by adding a reference
to the LED from another device (such as a NIC).
Device (NIC0)
{
...
Name (_DSD, Package () {
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package () {activity-led, LEDS.LEDM },
Package () {link-led, LEDS.LEDH },
},
}
}
I'm not sure that's even supported in devicetree or LEDs are the best example
of this, but the pattern seems generally useful.
Without a device you're also forced to use a label property instead of a
_STR.
As an example, consider the following ASL from an experimental MinnowBoard
firmware:
Device (LEDS)
{
Name (_HID, PRP0001)
Name (_CRS, ResourceTemplate () {
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
\\_SB.PCI0.LPC, 0, ResourceConsumer) {10}
GpioIo (Exclusive, PullDown, 0, 0, IoRestrictionOutputOnly,
\\_SB.PCI0.LPC, 0, ResourceConsumer) {11}
})
Name (_DSD, Package () {
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package () {compatible, Package () {gpio-leds}},
},
// Data extension
ToUUID(dbb8e3e6-5886-4ba6-8795-1319f52a966b),
Package () {
Package () {heartbeat, LEDH},
Package () {mmc-activity, LEDM},
I guess LEDH and LEDM have to be strings here. It would be nice if the
compiler could verify the path resolves. I suppose it's more incentive to keep
these in the same scope.
Re: [RFC 0/1] i2c: acpi: revert setting a "stable" device name
On Mon Aug 17 11:00, Jarkko Nikula wrote: > If I remember correctly ACPI ID should not ever change and instance id :xy > after INTABCD:xy should also be visible and keep the order even if device is > disabled or not plugged. But I'm not absolute sure about this. > > At least on a test platform that allow disable devices will show those > devices off-line (/sys/bus/acpi/devices/INTABCD:xy/status == 0). I'm always surprised how hard it is to tell what *can't* happen in ACPI. How about a conditional call to LoadTable()? Seems like that would mess up the :xy. Moot point, I think you're on the right track in your RFC patch. --Dustin -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC 0/1] i2c: acpi: revert setting a stable device name
On Mon Aug 17 11:00, Jarkko Nikula wrote: If I remember correctly ACPI ID should not ever change and instance id :xy after INTABCD:xy should also be visible and keep the order even if device is disabled or not plugged. But I'm not absolute sure about this. At least on a test platform that allow disable devices will show those devices off-line (/sys/bus/acpi/devices/INTABCD:xy/status == 0). I'm always surprised how hard it is to tell what *can't* happen in ACPI. How about a conditional call to LoadTable()? Seems like that would mess up the :xy. Moot point, I think you're on the right track in your RFC patch. --Dustin -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Hi Mika,
Thanks for taking a look.
On Mon Aug 17 15:03, Mika Westerberg wrote:
> On Fri, Aug 14, 2015 at 12:31:32PM -0700, Dustin Byford wrote:
> > Name (_DSD, Package ()
> > {
> > ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> > Package () {
> > Package (2) { "compatible", "nxp,pca9548" },
> > }
>
> Nice, you are using _DSD :-)
Yes, and I've got some other patches related to that. I'll keep
sending, but the relative youth of _DSD does bring up a few higher level
issues (for me at least). One thing at a time though, stay tuned.
> > I had to:
> >
> > 1) Find and set an ACPI companion for the "virtual" I2C adapters created
> >for each mux channel.
> >
> > 2) Make sure to scan adap.dev when registering devices under each mux
> >channel.
> I think the current code in I2C core is not actually doing the right
> thing according the ACPI spec at least. To my understanding you can have
> device with I2cSerialBus resource _anywhere_ in the namespace, not just
> directly below the host controller. It's the ResourceSource attribute
> that tells the corresponding host controller.
I think you're right.
> I wonder if it helps if we scan the whole namespace for devices with
> I2cSerialBus that matches the just registered adapter? Something like
> the patch below.
Looks reasonable to me. Let me work with the patch for a bit and see if
I can make it work in my system.
--Dustin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Hi Mika,
Thanks for taking a look.
On Mon Aug 17 15:03, Mika Westerberg wrote:
On Fri, Aug 14, 2015 at 12:31:32PM -0700, Dustin Byford wrote:
Name (_DSD, Package ()
{
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package (2) { compatible, nxp,pca9548 },
}
Nice, you are using _DSD :-)
Yes, and I've got some other patches related to that. I'll keep
sending, but the relative youth of _DSD does bring up a few higher level
issues (for me at least). One thing at a time though, stay tuned.
I had to:
1) Find and set an ACPI companion for the virtual I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
I think the current code in I2C core is not actually doing the right
thing according the ACPI spec at least. To my understanding you can have
device with I2cSerialBus resource _anywhere_ in the namespace, not just
directly below the host controller. It's the ResourceSource attribute
that tells the corresponding host controller.
I think you're right.
I wonder if it helps if we scan the whole namespace for devices with
I2cSerialBus that matches the just registered adapter? Something like
the patch below.
Looks reasonable to me. Let me work with the patch for a bit and see if
I can make it work in my system.
--Dustin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/1] i2c: acpi: revert setting a "stable" device name
70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
devices. With that change, /sys/bus/i2c/devices/i2c-0-004a, for
example, became /sys/bus/i2c/devices/i2c-PNP:xx
That causes problems for userspace code such as 'sensors' which does
this:
lib/sysfs.c:665:
if ((!subsys || !strcmp(subsys, "i2c")) &&
sscanf(dev_name, "%hd-%x", ,
) == 2) {
...
Fix 'sensors' by reverting the kernel change.
Signed-off-by: Dustin Byford
---
drivers/i2c/i2c-core.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..fb77031 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -916,13 +916,6 @@ EXPORT_SYMBOL_GPL(i2c_unlock_adapter);
static void i2c_dev_set_name(struct i2c_adapter *adap,
struct i2c_client *client)
{
- struct acpi_device *adev = ACPI_COMPANION(>dev);
-
- if (adev) {
- dev_set_name(>dev, "i2c-%s", acpi_dev_name(adev));
- return;
- }
-
/* For 10-bit clients, add an arbitrary offset to avoid collisions */
dev_set_name(>dev, "%d-%04x", i2c_adapter_id(adap),
client->addr | ((client->flags & I2C_CLIENT_TEN)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/1] i2c: acpi: revert setting a "stable" device name
70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
devices. With that change, /sys/bus/i2c/devices/i2c-0-004a, for
example, became /sys/bus/i2c/devices/i2c-PNP:xx
That causes problems for userspace code such as 'sensors' which does
this:
lib/sysfs.c:665:
if ((!subsys || !strcmp(subsys, "i2c")) &&
sscanf(dev_name, "%hd-%x", ,
) == 2) {
...
Therefore, in theory, sensors that were previously visible by running
'sensors' no longer show up. On the other hand, there are probably few,
if any, cases of this because ACPI enumerated I2C hwmon devices are not
common.
I'm not defending the 'sensors' code, I'm sure there are better ways to
discover a hwmon I2C device from userspace. But, I'm also not sure
70762ab achieved its stated goal in a meaningful way. Won't
"i2c-" also vary with ACPI scan order, BIOS settings,
firmware upgrades, etc...?
Hence the RFC patch. To submit a change like this I would need to
consider the fallout for ALSA SoC. The other option is to see what can
be done in 'sensors' to include the ACPI enumerated hwmon devices.
Any opinions on which way to go?
--Dustin
Dustin Byford (1):
i2c: acpi: revert setting a "stable" device name
drivers/i2c/i2c-core.c | 7 ---
1 file changed, 7 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
(v2 corrects cc: list)
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^^SMB2", 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "nxp,pca9548" },
}
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the "virtual" I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev->parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev->parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
Any feedback would be welcome. Thanks,
--Dustin
Dustin Byford (1):
i2c: acpi: scan ACPI enumerated I2C mux channels
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Set an ACPI companion for I2C mux channels enumerated through ACPI and
ensure they are scanned for devices.
Signed-off-by: Dustin Byford
---
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..23cc8e9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
if (!adap->dev.parent)
return;
+ /*
+* Determine where to start walking the ACPI namespace. The common
+* case is to start at the adapter's parent device. However, in
+* the case of a "virtual" I2C adapter created to represent a mux
+* channel the parent dev (pointing to the mux device) does not
+* have an ACPI handle. Walk starting at the adapter instead.
+*/
handle = ACPI_HANDLE(adap->dev.parent);
if (!handle)
+ handle = ACPI_HANDLE(>dev);
+
+ if (!handle)
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..2731b99 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Now try to populate the mux adapter's ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 0/1] i2c: acpi: revert setting a stable device name
70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
devices. With that change, /sys/bus/i2c/devices/i2c-0-004a, for
example, became /sys/bus/i2c/devices/i2c-PNP:xx
That causes problems for userspace code such as 'sensors' which does
this:
lib/sysfs.c:665:
if ((!subsys || !strcmp(subsys, i2c))
sscanf(dev_name, %hd-%x, entry.chip.bus.nr,
entry.chip.addr) == 2) {
...
Therefore, in theory, sensors that were previously visible by running
'sensors' no longer show up. On the other hand, there are probably few,
if any, cases of this because ACPI enumerated I2C hwmon devices are not
common.
I'm not defending the 'sensors' code, I'm sure there are better ways to
discover a hwmon I2C device from userspace. But, I'm also not sure
70762ab achieved its stated goal in a meaningful way. Won't
i2c-acpi_dev_name also vary with ACPI scan order, BIOS settings,
firmware upgrades, etc...?
Hence the RFC patch. To submit a change like this I would need to
consider the fallout for ALSA SoC. The other option is to see what can
be done in 'sensors' to include the ACPI enumerated hwmon devices.
Any opinions on which way to go?
--Dustin
Dustin Byford (1):
i2c: acpi: revert setting a stable device name
drivers/i2c/i2c-core.c | 7 ---
1 file changed, 7 deletions(-)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC 1/1] i2c: acpi: revert setting a stable device name
70762ab from 11/2014 (i2c: Use stable dev_name for ACPI enumerated I2C
slaves) modified the sysfs-visible dev_name() for ACPI enumerated I2C
devices. With that change, /sys/bus/i2c/devices/i2c-0-004a, for
example, became /sys/bus/i2c/devices/i2c-PNP:xx
That causes problems for userspace code such as 'sensors' which does
this:
lib/sysfs.c:665:
if ((!subsys || !strcmp(subsys, i2c))
sscanf(dev_name, %hd-%x, entry.chip.bus.nr,
entry.chip.addr) == 2) {
...
Fix 'sensors' by reverting the kernel change.
Signed-off-by: Dustin Byford dus...@cumulusnetworks.com
---
drivers/i2c/i2c-core.c | 7 ---
1 file changed, 7 deletions(-)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..fb77031 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -916,13 +916,6 @@ EXPORT_SYMBOL_GPL(i2c_unlock_adapter);
static void i2c_dev_set_name(struct i2c_adapter *adap,
struct i2c_client *client)
{
- struct acpi_device *adev = ACPI_COMPANION(client-dev);
-
- if (adev) {
- dev_set_name(client-dev, i2c-%s, acpi_dev_name(adev));
- return;
- }
-
/* For 10-bit clients, add an arbitrary offset to avoid collisions */
dev_set_name(client-dev, %d-%04x, i2c_adapter_id(adap),
client-addr | ((client-flags I2C_CLIENT_TEN)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 0/1] i2c: acpi: scan ACPI enumerated I2C mux channels
(v2 corrects cc: list)
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, PRP0001)
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, ^^SMB2, 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package (2) { compatible, nxp,pca9548 },
}
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the virtual I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev-parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev-parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
Any feedback would be welcome. Thanks,
--Dustin
Dustin Byford (1):
i2c: acpi: scan ACPI enumerated I2C mux channels
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC v2 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Set an ACPI companion for I2C mux channels enumerated through ACPI and
ensure they are scanned for devices.
Signed-off-by: Dustin Byford dus...@cumulusnetworks.com
---
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..23cc8e9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
if (!adap-dev.parent)
return;
+ /*
+* Determine where to start walking the ACPI namespace. The common
+* case is to start at the adapter's parent device. However, in
+* the case of a virtual I2C adapter created to represent a mux
+* channel the parent dev (pointing to the mux device) does not
+* have an ACPI handle. Walk starting at the adapter instead.
+*/
handle = ACPI_HANDLE(adap-dev.parent);
if (!handle)
+ handle = ACPI_HANDLE(adap-dev);
+
+ if (!handle)
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..2731b99 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include linux/i2c.h
#include linux/i2c-mux.h
#include linux/of.h
+#include linux/acpi.h
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Now try to populate the mux adapter's ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(priv-adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv-adap.nr = force_nr;
ret = i2c_add_numbered_adapter(priv-adap);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/1] i2c: scan ACPI enumerated I2C mux channels
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, "PRP0001")
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^^SMB2", 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package (2) { "compatible", "nxp,pca9548" },
}
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the "virtual" I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev->parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev->parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
Any feedback would be welcome. Thanks,
--Dustin
Dustin Byford (1):
i2c: acpi: scan ACPI enumerated I2C mux channels
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Set an ACPI companion for I2C mux channels enumerated through ACPI and
ensure they are scanned for devices.
Signed-off-by: Dustin Byford
---
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..23cc8e9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
if (!adap->dev.parent)
return;
+ /*
+* Determine where to start walking the ACPI namespace. The common
+* case is to start at the adapter's parent device. However, in
+* the case of a "virtual" I2C adapter created to represent a mux
+* channel the parent dev (pointing to the mux device) does not
+* have an ACPI handle. Walk starting at the adapter instead.
+*/
handle = ACPI_HANDLE(adap->dev.parent);
if (!handle)
+ handle = ACPI_HANDLE(>dev);
+
+ if (!handle)
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..2731b99 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Now try to populate the mux adapter's ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(>adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv->adap.nr = force_nr;
ret = i2c_add_numbered_adapter(>adap);
--
2.1.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/1] i2c: scan ACPI enumerated I2C mux channels
I would like to add support for scanning I2C devices connected to ACPI
OF compatible muxes described in ASL like this:
Device (MUX0)
{
Name (_ADR, 0x70)
Name (_HID, PRP0001)
Name (_CRS, ResourceTemplate()
{
I2cSerialBus (0x70, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, ^^SMB2, 0x00,
ResourceConsumer,,)
})
Name (_DSD, Package ()
{
ToUUID(daffd814-6eba-4d8c-8a91-bc9bbf4aa301),
Package () {
Package (2) { compatible, nxp,pca9548 },
}
})
// MUX channels
Device (CH00) { Name (_ADR, 0x0) }
}
Scope(MUX0.CH00)
{
Device (TMP0) {
/* Temp sensor ASL, for example. */
}
}
It seems like a reasonable way to describe a common I2C component and
kernel support is almost there.
I had to:
1) Find and set an ACPI companion for the virtual I2C adapters created
for each mux channel.
2) Make sure to scan adap.dev when registering devices under each mux
channel.
At first, I was confused about why adap.dev-parent is used in
acpi_i2c_register_devices(). I found b34bb1ee from 4/2013 (ACPI / I2C:
Use parent's ACPI_HANDLE()), which offers an explanation.
This patch works well, but I'm not sure about the code to just fall back
to using adap.dev when adap.dev-parent doesn't have an ACPI companion.
Is there a more explicit check I can make to determine if the adapter
represents a mux channel?
Any feedback would be welcome. Thanks,
--Dustin
Dustin Byford (1):
i2c: acpi: scan ACPI enumerated I2C mux channels
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/1] i2c: acpi: scan ACPI enumerated I2C mux channels
Set an ACPI companion for I2C mux channels enumerated through ACPI and
ensure they are scanned for devices.
Signed-off-by: Dustin Byford dus...@cumulusnetworks.com
---
drivers/i2c/i2c-core.c | 10 ++
drivers/i2c/i2c-mux.c | 8
2 files changed, 18 insertions(+)
diff --git a/drivers/i2c/i2c-core.c b/drivers/i2c/i2c-core.c
index c83e4d1..23cc8e9 100644
--- a/drivers/i2c/i2c-core.c
+++ b/drivers/i2c/i2c-core.c
@@ -171,8 +171,18 @@ static void acpi_i2c_register_devices(struct i2c_adapter
*adap)
if (!adap-dev.parent)
return;
+ /*
+* Determine where to start walking the ACPI namespace. The common
+* case is to start at the adapter's parent device. However, in
+* the case of a virtual I2C adapter created to represent a mux
+* channel the parent dev (pointing to the mux device) does not
+* have an ACPI handle. Walk starting at the adapter instead.
+*/
handle = ACPI_HANDLE(adap-dev.parent);
if (!handle)
+ handle = ACPI_HANDLE(adap-dev);
+
+ if (!handle)
return;
status = acpi_walk_namespace(ACPI_TYPE_DEVICE, handle, 1,
diff --git a/drivers/i2c/i2c-mux.c b/drivers/i2c/i2c-mux.c
index 2ba7c0f..2731b99 100644
--- a/drivers/i2c/i2c-mux.c
+++ b/drivers/i2c/i2c-mux.c
@@ -25,6 +25,7 @@
#include linux/i2c.h
#include linux/i2c-mux.h
#include linux/of.h
+#include linux/acpi.h
/* multiplexer per channel data */
struct i2c_mux_priv {
@@ -173,6 +174,13 @@ struct i2c_adapter *i2c_add_mux_adapter(struct i2c_adapter
*parent,
}
}
+ /*
+* Now try to populate the mux adapter's ACPI node.
+*/
+ if (has_acpi_companion(mux_dev))
+ acpi_preset_companion(priv-adap.dev, ACPI_COMPANION(mux_dev),
+ chan_id);
+
if (force_nr) {
priv-adap.nr = force_nr;
ret = i2c_add_numbered_adapter(priv-adap);
--
2.1.4
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
