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 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
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-muxe
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}
Thanks,
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/busse
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
> >> indi
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
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()
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
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
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 t
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
> > co
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
now 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
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
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 ACP
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
> > co
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 u
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
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
Name (_CRS, ResourceTemplate () {
I2cSerialBus (0x50, ControllerInitiated, I2C_SPEED,
AddressingMode7Bit, "^CH01", 0x00,
ResourceConsumer,,)
}
}
}
}
}
Dustin Byford (2):
i2c: scan entire A
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:
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
>
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 th
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"),
> >
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.
Signe
. 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
licit 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 chan
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
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
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
31 matches
Mail list logo
