Messages in this thread | | | Subject | Re: [PATCH v3 06/11] iio: light: cm32181: Handle CM3218 ACPI devices with 2 I2C resources | From | Hans de Goede <> | Date | Mon, 4 May 2020 11:52:46 +0200 |
| |
Hi,
On 5/3/20 1:04 PM, Jonathan Cameron wrote: > On Tue, 28 Apr 2020 19:29:18 +0200 > Hans de Goede <hdegoede@redhat.com> wrote: > >> Some ACPI systems list 2 I2C resources for the CM3218 sensor. On these >> systems the first I2cSerialBus ACPI-resource points to the SMBus Alert >> Response Address (ARA, 0x0c) and the second I2cSerialBus ACPI-resource >> points to the actual CM3218 sensor address: >> >> Method (_CRS, 0, NotSerialized) // _CRS: Current Resource Settings >> { >> Name (SBUF, ResourceTemplate () >> { > > I have a vague recollection that we had case of this where they could > come in either order. Could that happen here?
Not to the best of my knowledge. I've only seen this construct on a couple of Asus models and they are all consistent.
> My mind may be playing tricks on me of course and that may never > happen... > > Did I ever mention how much the lack of spec for some of these corner > cases annoys me?
Yes I think you have mentioned before. Unfortunately there is nothing we can do about this, but I hear you.
Regards,
Hans
> > J > >> I2cSerialBusV2 (0x000C, ControllerInitiated, 0x00061A80, >> AddressingMode7Bit, "\\_SB.I2C3", >> 0x00, ResourceConsumer, , Exclusive, >> ) >> I2cSerialBusV2 (0x0048, ControllerInitiated, 0x00061A80, >> AddressingMode7Bit, "\\_SB.I2C3", >> 0x00, ResourceConsumer, , Exclusive, >> ) >> Interrupt (ResourceConsumer, Level, ActiveHigh, Exclusive, ,, ) >> { >> 0x00000033, >> } >> }) >> Return (SBUF) /* \_SB_.I2C3.ALSD._CRS.SBUF */ >> } >> >> Detect this and take the following step to deal with it: >> >> 1. When a SMBus Alert capable sensor has an Alert asserted, it will >> not respond on its actual I2C address. Read a byte from the ARA >> to clear any pending Alerts. >> >> 2. Create a "dummy" client for the actual I2C address and >> use that client to communicate with the sensor. >> >> Signed-off-by: Hans de Goede <hdegoede@redhat.com> >> --- >> Changes in v3: >> - Create and use a dummy client instead of relying on i2c-multi-instantiate >> to create 2 separate clients for the 2 I2C resources >> >> Changes in v2 >> - s/i2c_client-s/I2C clients/ in added comment >> --- >> drivers/iio/light/cm32181.c | 22 ++++++++++++++++++++++ >> 1 file changed, 22 insertions(+) >> >> diff --git a/drivers/iio/light/cm32181.c b/drivers/iio/light/cm32181.c >> index 8fe49610fc26..c23a5c3a86a3 100644 >> --- a/drivers/iio/light/cm32181.c >> +++ b/drivers/iio/light/cm32181.c >> @@ -51,6 +51,8 @@ >> #define CM32181_CALIBSCALE_RESOLUTION 1000 >> #define MLUX_PER_LUX 1000 >> >> +#define SMBUS_ALERT_RESPONSE_ADDRESS 0x0c >> + >> static const u8 cm32181_reg[CM32181_CONF_REG_NUM] = { >> CM32181_REG_ADDR_CMD, >> }; >> @@ -335,6 +337,26 @@ static int cm32181_probe(struct i2c_client *client) >> if (!indio_dev) >> return -ENOMEM; >> >> + /* >> + * Some ACPI systems list 2 I2C resources for the CM3218 sensor, the >> + * SMBus Alert Response Address (ARA, 0x0c) and the actual I2C address. >> + * Detect this and take the following step to deal with it: >> + * 1. When a SMBus Alert capable sensor has an Alert asserted, it will >> + * not respond on its actual I2C address. Read a byte from the ARA >> + * to clear any pending Alerts. >> + * 2. Create a "dummy" client for the actual I2C address and >> + * use that client to communicate with the sensor. >> + */ >> + if (ACPI_HANDLE(dev) && client->addr == SMBUS_ALERT_RESPONSE_ADDRESS) { >> + struct i2c_board_info board_info = { .type = "dummy" }; >> + >> + i2c_smbus_read_byte(client); >> + >> + client = i2c_acpi_new_device(dev, 1, &board_info); >> + if (IS_ERR(client)) >> + return PTR_ERR(client); >> + } >> + >> cm32181 = iio_priv(indio_dev); >> cm32181->client = client; >> >
| |