* [PATCH v3] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Ben Gardner @ 2017-02-09 17:09 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-kernel, Andy Shevchenko, Ben Gardner
In-Reply-To: <CAE7DoPa1taAOWOO+g=A=QJ5wTy+GicjyL6GgdiTYQ94QWaX1Ug@mail.gmail.com>
Allow the at24 driver to get configuration information from both OF and
ACPI by using the more generic device_property functions.
This change was inspired by the at25.c driver.
I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
With the following ACPI construct, this patch instantiates a working
instance of the driver.
Device (EEP0) {
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", Package () {"st,24c02"}},
Package () {"pagesize", 16},
},
})
Name (_CRS, ResourceTemplate () {
I2cSerialBus (
0x0057, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
ResourceConsumer,,)
})
}
Note: Matching the driver to the I2C device requires another patch.
http://www.spinics.net/lists/linux-acpi/msg71914.html
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
---
drivers/misc/eeprom/at24.c | 45 +++++++++++++++++++--------------------------
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 051b147..c2d9969 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -19,7 +19,7 @@
#include <linux/log2.h>
#include <linux/bitops.h>
#include <linux/jiffies.h>
-#include <linux/of.h>
+#include <linux/property.h>
#include <linux/acpi.h>
#include <linux/i2c.h>
#include <linux/nvmem-provider.h>
@@ -562,26 +562,26 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
return 0;
}
-#ifdef CONFIG_OF
-static void at24_get_ofdata(struct i2c_client *client,
- struct at24_platform_data *chip)
+static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
{
- const __be32 *val;
- struct device_node *node = client->dev.of_node;
-
- if (node) {
- if (of_get_property(node, "read-only", NULL))
- chip->flags |= AT24_FLAG_READONLY;
- val = of_get_property(node, "pagesize", NULL);
- if (val)
- chip->page_size = be32_to_cpup(val);
+ int err;
+ u32 val;
+
+ if (device_property_present(dev, "read-only"))
+ chip->flags |= AT24_FLAG_READONLY;
+
+ err = device_property_read_u32(dev, "pagesize", &val);
+ if (!err) {
+ chip->page_size = val;
+ } else {
+ /*
+ * This is slow, but we can't know all eeproms, so we better
+ * play safe. Specifying custom eeprom-types via platform_data
+ * is recommended anyhow.
+ */
+ chip.page_size = 1;
}
}
-#else
-static void at24_get_ofdata(struct i2c_client *client,
- struct at24_platform_data *chip)
-{ }
-#endif /* CONFIG_OF */
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
@@ -613,15 +613,8 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
- /*
- * This is slow, but we can't know all eeproms, so we better
- * play safe. Specifying custom eeprom-types via platform_data
- * is recommended anyhow.
- */
- chip.page_size = 1;
- /* update chipdata if OF is present */
- at24_get_ofdata(client, &chip);
+ at24_get_pdata(&client->dev, &chip);
chip.setup = NULL;
chip.context = NULL;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v3] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Ben Gardner @ 2017-02-09 17:18 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Linux I2C, linux-kernel, Andy Shevchenko, Ben Gardner
In-Reply-To: <1486660199-30065-1-git-send-email-gardner.ben@gmail.com>
Ignore this last patch. I should remember to test even the simplest of
cut-and-paste ops.
On Thu, Feb 9, 2017 at 11:09 AM, Ben Gardner <gardner.ben@gmail.com> wrote:
> Allow the at24 driver to get configuration information from both OF and
> ACPI by using the more generic device_property functions.
> This change was inspired by the at25.c driver.
>
> I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
> With the following ACPI construct, this patch instantiates a working
> instance of the driver.
>
> Device (EEP0) {
> Name (_HID, "PRP0001")
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"st,24c02"}},
> Package () {"pagesize", 16},
> },
> })
> Name (_CRS, ResourceTemplate () {
> I2cSerialBus (
> 0x0057, ControllerInitiated, 400000,
> AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
> ResourceConsumer,,)
> })
> }
>
> Note: Matching the driver to the I2C device requires another patch.
> http://www.spinics.net/lists/linux-acpi/msg71914.html
>
> Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
> ---
> drivers/misc/eeprom/at24.c | 45 +++++++++++++++++++--------------------------
> 1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 051b147..c2d9969 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -19,7 +19,7 @@
> #include <linux/log2.h>
> #include <linux/bitops.h>
> #include <linux/jiffies.h>
> -#include <linux/of.h>
> +#include <linux/property.h>
> #include <linux/acpi.h>
> #include <linux/i2c.h>
> #include <linux/nvmem-provider.h>
> @@ -562,26 +562,26 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
> return 0;
> }
>
> -#ifdef CONFIG_OF
> -static void at24_get_ofdata(struct i2c_client *client,
> - struct at24_platform_data *chip)
> +static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
> {
> - const __be32 *val;
> - struct device_node *node = client->dev.of_node;
> -
> - if (node) {
> - if (of_get_property(node, "read-only", NULL))
> - chip->flags |= AT24_FLAG_READONLY;
> - val = of_get_property(node, "pagesize", NULL);
> - if (val)
> - chip->page_size = be32_to_cpup(val);
> + int err;
> + u32 val;
> +
> + if (device_property_present(dev, "read-only"))
> + chip->flags |= AT24_FLAG_READONLY;
> +
> + err = device_property_read_u32(dev, "pagesize", &val);
> + if (!err) {
> + chip->page_size = val;
> + } else {
> + /*
> + * This is slow, but we can't know all eeproms, so we better
> + * play safe. Specifying custom eeprom-types via platform_data
> + * is recommended anyhow.
> + */
> + chip.page_size = 1;
> }
> }
> -#else
> -static void at24_get_ofdata(struct i2c_client *client,
> - struct at24_platform_data *chip)
> -{ }
> -#endif /* CONFIG_OF */
>
> static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> @@ -613,15 +613,8 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
> magic >>= AT24_SIZE_BYTELEN;
> chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
> - /*
> - * This is slow, but we can't know all eeproms, so we better
> - * play safe. Specifying custom eeprom-types via platform_data
> - * is recommended anyhow.
> - */
> - chip.page_size = 1;
>
> - /* update chipdata if OF is present */
> - at24_get_ofdata(client, &chip);
> + at24_get_pdata(&client->dev, &chip);
>
> chip.setup = NULL;
> chip.context = NULL;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCH] i2c: piix4: Request the SMBUS semaphore inside the mutex
From: Jean Delvare @ 2017-02-09 17:31 UTC (permalink / raw)
To: Wolfram Sang
Cc: Ricardo Ribalda Delgado, Andy Shevchenko, linux-i2c, linux-kernel
In-Reply-To: <20170209160926.fmxmnjb7oqf27pww@ninjato>
Hi Wolfram,
On Thu, 9 Feb 2017 17:09:26 +0100, Wolfram Sang wrote:
> > Thanks for the quick fix.
> >
> > Signed-off-by: Jean Delvare <jdelvare@suse.de>
>
> I wonder: why do you use Signed-off instead of Reviewed-by recently?
I use Signed-off-by for drivers I maintain, and Reviewed-by for the
rest.
But I can use whatever you prefer if that's a problem, I don't really
care.
--
Jean Delvare
SUSE L3 Support
^ permalink raw reply
* [PATCH v4] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Ben Gardner @ 2017-02-09 17:36 UTC (permalink / raw)
To: Wolfram Sang; +Cc: linux-i2c, linux-kernel, Andy Shevchenko, Ben Gardner
In-Reply-To: <CAE7DoPan8Y_-F-Fj22xYkKBeCTPPD60MvEAv+hjSzU+H5DHovg@mail.gmail.com>
Allow the at24 driver to get configuration information from both OF and
ACPI by using the more generic device_property functions.
This change was inspired by the at25.c driver.
I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
With the following ACPI construct, this patch instantiates a working
instance of the driver.
Device (EEP0) {
Name (_HID, "PRP0001")
Name (_DSD, Package () {
ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
Package () {
Package () {"compatible", Package () {"st,24c02"}},
Package () {"pagesize", 16},
},
})
Name (_CRS, ResourceTemplate () {
I2cSerialBus (
0x0057, ControllerInitiated, 400000,
AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
ResourceConsumer,,)
})
}
Note: Matching the driver to the I2C device requires another patch.
http://www.spinics.net/lists/linux-acpi/msg71914.html
Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
---
drivers/misc/eeprom/at24.c | 45 +++++++++++++++++++--------------------------
1 file changed, 19 insertions(+), 26 deletions(-)
diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
index 051b147..764ff5df 100644
--- a/drivers/misc/eeprom/at24.c
+++ b/drivers/misc/eeprom/at24.c
@@ -19,7 +19,7 @@
#include <linux/log2.h>
#include <linux/bitops.h>
#include <linux/jiffies.h>
-#include <linux/of.h>
+#include <linux/property.h>
#include <linux/acpi.h>
#include <linux/i2c.h>
#include <linux/nvmem-provider.h>
@@ -562,26 +562,26 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
return 0;
}
-#ifdef CONFIG_OF
-static void at24_get_ofdata(struct i2c_client *client,
- struct at24_platform_data *chip)
+static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
{
- const __be32 *val;
- struct device_node *node = client->dev.of_node;
-
- if (node) {
- if (of_get_property(node, "read-only", NULL))
- chip->flags |= AT24_FLAG_READONLY;
- val = of_get_property(node, "pagesize", NULL);
- if (val)
- chip->page_size = be32_to_cpup(val);
+ int err;
+ u32 val;
+
+ if (device_property_present(dev, "read-only"))
+ chip->flags |= AT24_FLAG_READONLY;
+
+ err = device_property_read_u32(dev, "pagesize", &val);
+ if (!err) {
+ chip->page_size = val;
+ } else {
+ /*
+ * This is slow, but we can't know all eeproms, so we better
+ * play safe. Specifying custom eeprom-types via platform_data
+ * is recommended anyhow.
+ */
+ chip->page_size = 1;
}
}
-#else
-static void at24_get_ofdata(struct i2c_client *client,
- struct at24_platform_data *chip)
-{ }
-#endif /* CONFIG_OF */
static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
@@ -613,15 +613,8 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
magic >>= AT24_SIZE_BYTELEN;
chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
- /*
- * This is slow, but we can't know all eeproms, so we better
- * play safe. Specifying custom eeprom-types via platform_data
- * is recommended anyhow.
- */
- chip.page_size = 1;
- /* update chipdata if OF is present */
- at24_get_ofdata(client, &chip);
+ at24_get_pdata(&client->dev, &chip);
chip.setup = NULL;
chip.context = NULL;
--
2.7.4
^ permalink raw reply related
* Re: [PATCH v4] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Andy Shevchenko @ 2017-02-09 17:43 UTC (permalink / raw)
To: Ben Gardner; +Cc: Wolfram Sang, linux-i2c, linux-kernel@vger.kernel.org
In-Reply-To: <1486661768-21456-1-git-send-email-gardner.ben@gmail.com>
On Thu, Feb 9, 2017 at 7:36 PM, Ben Gardner <gardner.ben@gmail.com> wrote:
> Allow the at24 driver to get configuration information from both OF and
> ACPI by using the more generic device_property functions.
> This change was inspired by the at25.c driver.
>
> I have a custom board with a ST M24C02 EEPROM attached to an I2C bus.
> With the following ACPI construct, this patch instantiates a working
> instance of the driver.
>
> Device (EEP0) {
> Name (_HID, "PRP0001")
> Name (_DSD, Package () {
> ToUUID("daffd814-6eba-4d8c-8a91-bc9bbf4aa301"),
> Package () {
> Package () {"compatible", Package () {"st,24c02"}},
> Package () {"pagesize", 16},
> },
> })
> Name (_CRS, ResourceTemplate () {
> I2cSerialBus (
> 0x0057, ControllerInitiated, 400000,
> AddressingMode7Bit, "\\_SB.PCI0.I2C3", 0x00,
> ResourceConsumer,,)
> })
> }
>
> Note: Matching the driver to the I2C device requires another patch.
> http://www.spinics.net/lists/linux-acpi/msg71914.html
Reviewed-by: Andy Shevchenko <andy.shevchenko@gmail.com>
> Signed-off-by: Ben Gardner <gardner.ben@gmail.com>
> ---
> drivers/misc/eeprom/at24.c | 45 +++++++++++++++++++--------------------------
> 1 file changed, 19 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/misc/eeprom/at24.c b/drivers/misc/eeprom/at24.c
> index 051b147..764ff5df 100644
> --- a/drivers/misc/eeprom/at24.c
> +++ b/drivers/misc/eeprom/at24.c
> @@ -19,7 +19,7 @@
> #include <linux/log2.h>
> #include <linux/bitops.h>
> #include <linux/jiffies.h>
> -#include <linux/of.h>
> +#include <linux/property.h>
> #include <linux/acpi.h>
> #include <linux/i2c.h>
> #include <linux/nvmem-provider.h>
> @@ -562,26 +562,26 @@ static int at24_write(void *priv, unsigned int off, void *val, size_t count)
> return 0;
> }
>
> -#ifdef CONFIG_OF
> -static void at24_get_ofdata(struct i2c_client *client,
> - struct at24_platform_data *chip)
> +static void at24_get_pdata(struct device *dev, struct at24_platform_data *chip)
> {
> - const __be32 *val;
> - struct device_node *node = client->dev.of_node;
> -
> - if (node) {
> - if (of_get_property(node, "read-only", NULL))
> - chip->flags |= AT24_FLAG_READONLY;
> - val = of_get_property(node, "pagesize", NULL);
> - if (val)
> - chip->page_size = be32_to_cpup(val);
> + int err;
> + u32 val;
> +
> + if (device_property_present(dev, "read-only"))
> + chip->flags |= AT24_FLAG_READONLY;
> +
> + err = device_property_read_u32(dev, "pagesize", &val);
> + if (!err) {
> + chip->page_size = val;
> + } else {
> + /*
> + * This is slow, but we can't know all eeproms, so we better
> + * play safe. Specifying custom eeprom-types via platform_data
> + * is recommended anyhow.
> + */
> + chip->page_size = 1;
> }
> }
> -#else
> -static void at24_get_ofdata(struct i2c_client *client,
> - struct at24_platform_data *chip)
> -{ }
> -#endif /* CONFIG_OF */
>
> static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> {
> @@ -613,15 +613,8 @@ static int at24_probe(struct i2c_client *client, const struct i2c_device_id *id)
> chip.byte_len = BIT(magic & AT24_BITMASK(AT24_SIZE_BYTELEN));
> magic >>= AT24_SIZE_BYTELEN;
> chip.flags = magic & AT24_BITMASK(AT24_SIZE_FLAGS);
> - /*
> - * This is slow, but we can't know all eeproms, so we better
> - * play safe. Specifying custom eeprom-types via platform_data
> - * is recommended anyhow.
> - */
> - chip.page_size = 1;
>
> - /* update chipdata if OF is present */
> - at24_get_ofdata(client, &chip);
> + at24_get_pdata(&client->dev, &chip);
>
> chip.setup = NULL;
> chip.context = NULL;
> --
> 2.7.4
>
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* [PATCH] i2c: designware: Fix regression when dynamic TAR update is disabled
From: Shah Nehal-Bakulchandra @ 2017-02-09 19:50 UTC (permalink / raw)
To: jarkko.nikula, andriy.shevchenko, mika.westerberg
Cc: lucas.demarchi, wsa, linux-i2c, linux-kernel, Shyam-sundar.S-k,
Shah Nehal-Bakulchandra, Shah Nehal-Bakulchandra,
Suravee Suthikulpanit
The following commit causes a regression when dynamic TAR update is
disabled:
commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3 ("i2c: designware:
detect when dynamic tar update is possible")
In such case, the DW_IC_CON_10BITADDR_MASTER is R/W, and is changed
by the logic that's trying to detect dynamic TAR update.The original
value of DW_IC_CON_10BITADDR_MASTER bit should be restored.
Signed-off-by: Shah Nehal-Bakulchandra <Nehal-bakulchandra.Shah@amd.com>
Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
---
drivers/i2c/busses/i2c-designware-core.c | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 6d81c56..0c57166 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -987,6 +987,11 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
(reg & DW_IC_CON_10BITADDR_MASTER)) {
dev->dynamic_tar_update_enabled = true;
dev_dbg(dev->dev, "Dynamic TAR update enabled");
+ } else {
+ /* If test is failed then restore the original value */
+ dev->dynamic_tar_update_enabled = false;
+ dev_dbg(dev->dev, "Dynamic TAR update disable restore the value");
+ dw_writel(dev, reg, DW_IC_CON);
}
i2c_dw_release_lock(dev);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH] i2c: piix4: Request the SMBUS semaphore inside the mutex
From: Wolfram Sang @ 2017-02-09 19:56 UTC (permalink / raw)
To: Jean Delvare
Cc: Ricardo Ribalda Delgado, Andy Shevchenko, linux-i2c, linux-kernel
In-Reply-To: <20170209183139.1a63f1fd@endymion>
[-- Attachment #1: Type: text/plain, Size: 441 bytes --]
> I use Signed-off-by for drivers I maintain, and Reviewed-by for the
> rest.
I see. I never noticed so far :)
> But I can use whatever you prefer if that's a problem, I don't really
> care.
Patchwork collects Rev-by tags from threads and shows the number of tags
in a list. This is helpful for me because I want to process already
reviewed patches earlier.
So, Rev-by would in deed be much appreciated for a better workflow.
Thanks!
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH] i2c: designware: Fix regression when dynamic TAR update is disabled
From: Andy Shevchenko @ 2017-02-09 20:07 UTC (permalink / raw)
To: Shah Nehal-Bakulchandra, jarkko.nikula, mika.westerberg
Cc: lucas.demarchi, wsa, linux-i2c, linux-kernel, Shyam-sundar.S-k,
Suravee Suthikulpanit
In-Reply-To: <1486669851-25632-1-git-send-email-Nehal-Bakulchandra.Shah@amd.com>
On Fri, 2017-02-10 at 01:20 +0530, Shah Nehal-Bakulchandra wrote:
> The following commit causes a regression when dynamic TAR update is
> disabled:
>
> commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3 ("i2c:
> designware:
> detect when dynamic tar update is possible")
Please, leave just 12 characters, it still enough.
> In such case, the DW_IC_CON_10BITADDR_MASTER is R/W, and is changed
> by the logic that's trying to detect dynamic TAR update.The original
> value of DW_IC_CON_10BITADDR_MASTER bit should be restored.
>
+ Fixes tag?
> Signed-off-by: Shah Nehal-Bakulchandra <Nehal-
> bakulchandra.Shah@amd.com>
> Signed-off-by: Suravee Suthikulpanit <suravee.suthikulpanit@amd.com>
> ---
> drivers/i2c/busses/i2c-designware-core.c | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/drivers/i2c/busses/i2c-designware-core.c
> b/drivers/i2c/busses/i2c-designware-core.c
> index 6d81c56..0c57166 100644
> --- a/drivers/i2c/busses/i2c-designware-core.c
> +++ b/drivers/i2c/busses/i2c-designware-core.c
> @@ -987,6 +987,11 @@ int i2c_dw_probe(struct dw_i2c_dev *dev)
> (reg & DW_IC_CON_10BITADDR_MASTER)) {
> dev->dynamic_tar_update_enabled = true;
> dev_dbg(dev->dev, "Dynamic TAR update enabled");
> + } else {
> + /* If test is failed then restore the original value
> */
> + dev->dynamic_tar_update_enabled = false;
It's default.
> + dev_dbg(dev->dev, "Dynamic TAR update disable restore
> the value");
I think this is useless. Either you have enabled message, or have
nothing.
> + dw_writel(dev, reg, DW_IC_CON);
> }
>
> i2c_dw_release_lock(dev);
--
Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Intel Finland Oy
^ permalink raw reply
* Re: [PATCH v4] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Ben Gardner @ 2017-02-09 20:31 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Linux I2C, linux-kernel, Andy Shevchenko
In-Reply-To: <20170209195859.GB1431@katana>
On Thu, Feb 9, 2017 at 1:58 PM, Wolfram Sang <wsa@the-dreams.de> wrote:
>
>> Note: Matching the driver to the I2C device requires another patch.
>> http://www.spinics.net/lists/linux-acpi/msg71914.html
>
> Do I get it right? With the patch applied we won't have a regression but
> the new feature will only be available when the above series is
> upstream? So, it is a "weak" dependency?
That is correct.
This patch shouldn't cause any regressions, but isn't useful without
the other patch series.
The other patch series was picked up today by Rafael J. Wysocki.
http://marc.info/?l=linux-acpi&m=148664872023023&w=2
Ben
^ permalink raw reply
* Re: [PATCH v2] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: kbuild test robot @ 2017-02-09 20:35 UTC (permalink / raw)
Cc: kbuild-all, Wolfram Sang, linux-i2c, linux-kernel,
Andy Shevchenko, Ben Gardner
In-Reply-To: <1486654433-20148-1-git-send-email-gardner.ben@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1262 bytes --]
Hi Ben,
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.10-rc7 next-20170209]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ben-Gardner/eeprom-at24-use-device_property_-functions-instead-of-of_get_property/20170210-025938
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/misc/eeprom/at24.c: In function 'at24_get_pdata':
>> drivers/misc/eeprom/at24.c:580:7: error: 'chip' is a pointer; did you mean to use '->'?
chip.page_size = 1;
^
->
vim +580 drivers/misc/eeprom/at24.c
574 } else {
575 /*
576 * This is slow, but we can't know all eeproms, so we better
577 * play safe. Specifying custom eeprom-types via platform_data
578 * is recommended anyhow.
579 */
> 580 chip.page_size = 1;
581 }
582 }
583
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 38283 bytes --]
^ permalink raw reply
* Re: [PATCH v2] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Andy Shevchenko @ 2017-02-09 21:30 UTC (permalink / raw)
To: kbuild test robot
Cc: Ben Gardner, kbuild-all, Wolfram Sang, linux-i2c,
linux-kernel@vger.kernel.org
In-Reply-To: <201702100424.gYk6PzId%fengguang.wu@intel.com>
On Thu, Feb 9, 2017 at 10:35 PM, kbuild test robot <lkp@intel.com> wrote:
> Hi Ben,
>
> [auto build test ERROR on char-misc/char-misc-testing]
> [also build test ERROR on v4.10-rc7 next-20170209]
> [if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
Optimistic way of thinking: kbuild bot was fast enough.
Pessimistic: it wasn't too slow enough.
P.S. I think it against older version of the patch, thus, we may
safely ignore this.
>
> url: https://github.com/0day-ci/linux/commits/Ben-Gardner/eeprom-at24-use-device_property_-functions-instead-of-of_get_property/20170210-025938
> config: x86_64-rhel (attached as .config)
> compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
> reproduce:
> # save the attached .config to linux build tree
> make ARCH=x86_64
>
> All errors (new ones prefixed by >>):
>
> drivers/misc/eeprom/at24.c: In function 'at24_get_pdata':
>>> drivers/misc/eeprom/at24.c:580:7: error: 'chip' is a pointer; did you mean to use '->'?
> chip.page_size = 1;
> ^
> ->
>
> vim +580 drivers/misc/eeprom/at24.c
>
> 574 } else {
> 575 /*
> 576 * This is slow, but we can't know all eeproms, so we better
> 577 * play safe. Specifying custom eeprom-types via platform_data
> 578 * is recommended anyhow.
> 579 */
> > 580 chip.page_size = 1;
> 581 }
> 582 }
> 583
>
> ---
> 0-DAY kernel test infrastructure Open Source Technology Center
> https://lists.01.org/pipermail/kbuild-all Intel Corporation
--
With Best Regards,
Andy Shevchenko
^ permalink raw reply
* Re: [PATCH] i2c: designware: Fix regression when dynamic TAR update is disabled
From: De Marchi, Lucas @ 2017-02-09 21:34 UTC (permalink / raw)
To: mika.westerberg@linux.intel.com,
andriy.shevchenko@linux.intel.com, jarkko.nikula@linux.intel.com,
Nehal-Bakulchandra.Shah@amd.com
Cc: wsa@the-dreams.de, linux-kernel@vger.kernel.org,
suravee.suthikulpanit@amd.com, linux-i2c@vger.kernel.org,
Shyam-sundar.S-k@amd.com
In-Reply-To: <1486670858.2133.436.camel@linux.intel.com>
On Thu, 2017-02-09 at 22:07 +0200, Andy Shevchenko wrote:
> On Fri, 2017-02-10 at 01:20 +0530, Shah Nehal-Bakulchandra wrote:
> > The following commit causes a regression when dynamic TAR update is
> > disabled:
> >
> > commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3 ("i2c:
> > designware:
> > detect when dynamic tar update is possible")
>
> Please, leave just 12 characters, it still enough.
>
> > In such case, the DW_IC_CON_10BITADDR_MASTER is R/W, and is changed
> > by the logic that's trying to detect dynamic TAR update.The original
> > value of DW_IC_CON_10BITADDR_MASTER bit should be restored.
You are right, thanks for the fix. This may also explains why
0317e6c (i2c: designware: do not disable adapter after transfer) caused problems
and ended up being reverted. Could you try that on your hardware?
The dynamic tar update detection was only done as preparation work to allow not
disabling the adapter, which is reverted. We may also just revert this commit
instead of fixing the logic.
thanks
Lucas De Marchi
^ permalink raw reply
* Re: [PATCH v4] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: Wolfram Sang @ 2017-02-09 19:58 UTC (permalink / raw)
To: Ben Gardner; +Cc: linux-i2c, linux-kernel, Andy Shevchenko
In-Reply-To: <1486661768-21456-1-git-send-email-gardner.ben@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 308 bytes --]
> Note: Matching the driver to the I2C device requires another patch.
> http://www.spinics.net/lists/linux-acpi/msg71914.html
Do I get it right? With the patch applied we won't have a regression but
the new feature will only be available when the above series is
upstream? So, it is a "weak" dependency?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
^ permalink raw reply
* Re: [PATCH v2] eeprom/at24: use device_property_*() functions instead of of_get_property()
From: kbuild test robot @ 2017-02-09 23:52 UTC (permalink / raw)
Cc: kbuild-all, Wolfram Sang, linux-i2c, linux-kernel,
Andy Shevchenko, Ben Gardner
In-Reply-To: <1486654433-20148-1-git-send-email-gardner.ben@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1281 bytes --]
Hi Ben,
[auto build test ERROR on char-misc/char-misc-testing]
[also build test ERROR on v4.10-rc7]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Ben-Gardner/eeprom-at24-use-device_property_-functions-instead-of-of_get_property/20170210-025938
config: x86_64-randconfig-it0-02100353 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
All errors (new ones prefixed by >>):
drivers/misc/eeprom/at24.c: In function 'at24_get_pdata':
>> drivers/misc/eeprom/at24.c:580:7: error: request for member 'page_size' in something not a structure or union
chip.page_size = 1;
^
vim +/page_size +580 drivers/misc/eeprom/at24.c
574 } else {
575 /*
576 * This is slow, but we can't know all eeproms, so we better
577 * play safe. Specifying custom eeprom-types via platform_data
578 * is recommended anyhow.
579 */
> 580 chip.page_size = 1;
581 }
582 }
583
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 22328 bytes --]
^ permalink raw reply
* Re: [PATCH 1/3] of: fix of_node leak caused in of_find_node_opts_by_path
From: qhou @ 2017-02-10 1:15 UTC (permalink / raw)
To: Rob Herring
Cc: Peter Rosin, stable, linux-i2c@vger.kernel.org, Leif Lindholm,
Pantelis Antoniou, Grant Likely, Bruce Ashfield, Paul Gortmaker,
ZhangXiao
In-Reply-To: <CAL_JsqJ210Nfwpi=pstTo+E8nTowVdLaMFNjd5rwSUpEcKcNJg@mail.gmail.com>
On 2017年02月09日 23:11, Rob Herring wrote:
> On Sun, Feb 5, 2017 at 10:55 PM, Qi Hou <qi.hou@windriver.com> wrote:
>> During stepping down the tree, parent node is gotten first and its refcount is
>> increased with of_node_get() in __of_get_next_child(). Since it just being used
>> as tmp node, its refcount must be decreased with of_node_put() after traversing
>> its child nodes.
>>
>> Or, its refcount will never be descreased to ZERO, then it will never be freed,
>> as well as other related memory blocks.
>>
>> To fix this, decrease refcount of parent with of_node_put() after
>> __of_find_node_by_path().
>>
>> Signed-off-by: Qi Hou <qi.hou@windriver.com>
>> Acked-by: Peter Rosin <peda@axentia.se>
>> ---
>> drivers/of/base.c | 3 +++
>> 1 file changed, 3 insertions(+)
> It doesn't look like there is any inter-dependency with this patch and
> the other 2, so I'll apply this one.
No, there is no inter-dependency in these three patches.
Just since they are all related with of_node_put and reported by
kmemleak and debugged
by the similar means, I sent them together.
-- Best regards,
Qi Hou
>
> Rob
^ permalink raw reply
* Re: [PATCH] i2c: designware: Fix regression when dynamic TAR update is disabled
From: Suravee Suthikulpanit @ 2017-02-10 6:38 UTC (permalink / raw)
To: De Marchi, Lucas, mika.westerberg@linux.intel.com,
andriy.shevchenko@linux.intel.com, jarkko.nikula@linux.intel.com,
Nehal-Bakulchandra.Shah@amd.com
Cc: wsa@the-dreams.de, linux-kernel@vger.kernel.org,
linux-i2c@vger.kernel.org, Shyam-sundar.S-k@amd.com
In-Reply-To: <1486676048.14478.4.camel@intel.com>
On 2/10/17 04:34, De Marchi, Lucas wrote:
> On Thu, 2017-02-09 at 22:07 +0200, Andy Shevchenko wrote:
>> On Fri, 2017-02-10 at 01:20 +0530, Shah Nehal-Bakulchandra wrote:
>>> The following commit causes a regression when dynamic TAR update is
>>> disabled:
>>>
>>> commit 63d0f0a6952a1a02bc4f116b7da7c7887e46efa3 ("i2c:
>>> designware:
>>> detect when dynamic tar update is possible")
>>
>> Please, leave just 12 characters, it still enough.
>>
>>> In such case, the DW_IC_CON_10BITADDR_MASTER is R/W, and is changed
>>> by the logic that's trying to detect dynamic TAR update.The original
>>> value of DW_IC_CON_10BITADDR_MASTER bit should be restored.
>
> You are right, thanks for the fix. This may also explains why
> 0317e6c (i2c: designware: do not disable adapter after transfer) caused problems
> and ended up being reverted. Could you try that on your hardware?
After looking at the patch (i2c: designware: do not disable adapter after transfer),
we see that it modifies the i2c_dw_xfer_init(). However, this function is never
called on our platform. So, this patch would not have any effects.
At this points, my understanding is there are probably two options here:
1) Keep the commit 63d0f0a6952a (i2c: designware: detect when dynamic tar update
is possible) and apply V2 of this patch in 4.10. We might need to back-port the change
to v4.9 stable as well.
2) Revert the 63d0f0a6952a (i2c: designware: detect when dynamic tar update is possible) in 4.10,
and also in v4.9 stable as well.
Thanks,
Suravee
> The dynamic tar update detection was only done as preparation work to allow not
> disabling the adapter, which is reverted. We may also just revert this commit
> instead of fixing the logic.
>
>
> thanks
> Lucas De Marchi
>
^ permalink raw reply
* Re: [PATCH] i2c: exynos5: fix arbitration lost handling
From: Andrzej Hajda @ 2017-02-10 7:39 UTC (permalink / raw)
To: Wolfram Sang
Cc: linux-i2c, Bartlomiej Zolnierkiewicz, Marek Szyprowski,
Krzysztof Kozlowski, Javier Martinez Canillas, linux-samsung-soc
In-Reply-To: <20170209162736.nfyfd5dpjkjq65w7@ninjato>
On 09.02.2017 17:27, Wolfram Sang wrote:
> On Thu, Jan 05, 2017 at 01:06:53PM +0100, Andrzej Hajda wrote:
>> In case of arbitration lost adequate interrupt sometimes is not signaled. As
>> a result transfer timeouts and is not retried, as it should. To avoid such
>> cases code is added to check transaction status in case of every interrupt.
>>
>> Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
>> ---
>> +
>> + switch (trans_status & HSI2C_MASTER_ST_MASK) {
>> + case HSI2C_MASTER_ST_LOSE:
>> + i2c->state = -EAGAIN;
>> + goto stop;
>> + }
> Why not using if() instead of switch() as in the rest of the driver?
Following reasons (not serious ones):
1. With if() the line should be split anyway to keep 80 chars per line
limit, and the result looks less readable, so no gain:
if ((trans_status & HSI2C_MASTER_ST_MASK) ==
HSI2C_MASTER_ST_LOSE) {
i2c->state = -EAGAIN;
goto stop;
}
2. It is ready to handle other status values as well, without repeating
long if() clause, in fact during tests I have added more values, but
finally they went out.
3. In the rest of the functions if() is used because code tests if some
bits are set, here we test if some bit field have specific value,
slightly different thing.
Of course I can change to if() if you prefer it.
> And there is arbitration lost checking already with int_status &
> HSI2C_INT_TRANS_ABORT. Any guess why it doesn't trigger?
>
Nope. This patch is just a result of comparing register values during
good and bad transfer.
I have looked for similar issues over the net, but without ultimate
answer, some hints are that master can check status of SDA line too early.
Anyway it works correctly with gpio bit-banging driver, it suggests
there could be something wrong in hsi2c logic.
Regards
Andrzej
^ permalink raw reply
* Re: [PATCH v6 0/3] i2c: mux: pca954x: Add interrupt controller support
From: Peter Rosin @ 2017-02-10 8:02 UTC (permalink / raw)
To: Wolfram Sang; +Cc: Phil Reid, linux-i2c
In-Reply-To: <1485307868-5408-1-git-send-email-preid@electromag.com.au>
Hi Wolfram!
I had prepared a branch for you to pull but then the kbuild
bot finally found this series and complained about the missing
initializer for the 'handled' variable. I amended the previously
posted fixup and was just about to send you the pull request when
you started to add patches to i2c/for-next. What is now left of what
I originally had in i2c-mux/for-next is this series. However, since
I told Phil that I amended the fixup I do not think he will resend
and I think you might therefore be waiting for a resend which will
probably not happen (anytime soon). I'm going to short out the wait
and just send a reworked pull request. See below.
A few thing to take away from this. Phil didn't post the series to
LKML, and the kbuild bots didn't find the series until I added it to
my i2c-mux tree. Fengguang indicated that the kbuild bot will now
(or soon) start to track the i2c list, which might be good to know.
I also think we need to come up with something that prevents us from
doing work twice. I think the main problem is at my end, for not
being clear enough about my intentions with an i2c-mux related
submission. So, from now on I think I'm just going to change my
acks to some message saying that the patch(es) have been added
to i2c-mux/for-next (in case the submission is clear-cut i2c-mux
and not at all about i2c-the-rest). If I just ack a submission I'll
expect you to pick it up. Ok?
The question then becomes at approximately which point you'll need
a pull request? Or should you perhaps be pulling in my tree
on a more continuous level so that everything i2c-related is
available in one tree (i.e. your tree)?
One thing that happened last time you pulled from the i2c-mux tree
was that you added your sign-offs, and that makes the i2c-mux tree
into a kind of 2nd rate tree that is not useful for much more than
feeding patches upstream. I have to force-push after each of your
pulls. I think (at least some) other 2nd level maintainers do not
"suffer" from this fate? Anyway, do you really need to add that
sign-off when you pull? It's not a big thing, but all things being
equal, I'd prefer the commits to stay as-is...
Cheers,
peda
The following changes since commit 7a308bb3016f57e5be11a677d15b821536419d36:
Linux 4.10-rc5 (2017-01-22 12:54:15 -0800)
are available in the git repository at:
https://github.com/peda-r/i2c-mux.git i2c-mux/for-next
for you to fetch changes up to f2114795f721bd5028284ddf84b150798a9b7a73:
i2c: mux: pca954x: Add interrupt controller support (2017-02-10 08:23:51 +0100)
----------------------------------------------------------------
Phil Reid (3):
i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
dt: bindings: i2c-mux-pca954x: Add documentation for interrupt controller
i2c: mux: pca954x: Add interrupt controller support
Documentation/devicetree/bindings/i2c/i2c-mux-pca954x.txt | 14 +++++-
drivers/i2c/muxes/i2c-mux-pca954x.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 159 insertions(+), 5 deletions(-)
On 2017-01-25 02:31, Phil Reid wrote:
> Various muxes can aggregate multiple interrupts from each i2c bus.
> All of the muxes with interrupt support combine the active low irq lines
> using an internal 'and' function and generate a combined active low
> output. The muxes do provide the ability to read a control register to
> determine which irq is active. By making the mux an irq controller isr
> latenct can potentially be reduced by reading the status register and
> then only calling the registered isr on that bus segment.
>
> Changes from v5:
> - p3 Added Peter's Ack.
> - Drop p4/5
>
> Changes from v4:
> - p4: Change definition of irq_mask_enable to an array.
> - p4: Removed acks due to change requested by Peter
> - p5: Parse array of enables. Currently only supports 1 chip
> But dt specification will allow expansion to handle
> multple irq consume chips to be registered on a bus segment
> - p5: Fix up logic related to enabling and disable irq's.
> Use a flag to indicate when irq has been enabled.
>
> Changes from v3:
> - p3: Add spin lock to irq mask / unmask.
> - p4: Add Rob's ack.
>
> Changes from v2:
> - p1: Added Acked-by
> - p5: fixup 2 typos
>
> Changes from v1:
> - Update for new ACPI table
> - Fix typo in documentation
> - Fix typo in function names
> - Fix typo in irq name
> - Added spaces around '+' / '='
> - Change goto label names
> - Change property name from i2c-mux-irq-mask-en to nxp,irq-mask-enable
> - Change variable name irq_mask_en to irq_mask_enable
> - Add commentt about irq_mask_enable
> - Added Acked-By's
> Phil Reid (3):
> i2c: mux: pca954x: Add missing pca9542 definition to chip_desc
> dt: bindings: i2c-mux-pca954x: Add documentation for interrupt
> controller
> i2c: mux: pca954x: Add interrupt controller support
>
> .../devicetree/bindings/i2c/i2c-mux-pca954x.txt | 14 +-
> drivers/i2c/muxes/i2c-mux-pca954x.c | 150 ++++++++++++++++++++-
> 2 files changed, 159 insertions(+), 5 deletions(-)
>
^ permalink raw reply
* Re: [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings
From: Hans de Goede @ 2017-02-10 10:19 UTC (permalink / raw)
To: Ville Syrjälä
Cc: Wolfram Sang, Takashi Iwai, russianneuromancer @ ya . ru,
intel-gfx, linux-i2c, Jarkko Nikula, dri-devel, H . Peter Anvin,
Daniel Vetter, Thomas Gleixner, Andy Shevchenko, Mika Westerberg,
Len Brown
In-Reply-To: <20170130151144.GP31595@intel.com>
Hi,
On 30-01-17 16:11, Ville Syrjälä wrote:
> On Mon, Jan 30, 2017 at 04:02:19PM +0100, Hans de Goede wrote:
>> Hi,
>>
>> On 30-01-17 14:10, Ville Syrjälä wrote:
>>> On Sat, Jan 28, 2017 at 06:18:45PM +0100, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 01/28/2017 05:25 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 01/27/2017 02:51 PM, Ville Syrjälä wrote:
>>>>>> On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote:
>>>>>>> Make sure the P-Unit or the PMIC i2c bus is not in use when we send a
>>>>>>> request to the P-Unit by calling iosf_mbi_punit_acquire() / _release()
>>>>>>> around P-Unit write accesses.
>>>>>>
>>>>>> Can't we just stuff the calls into the actual punit write function
>>>>>> rather than sprinkling them all over the place?
>>>>>
>>>>> punit access is acquired across sections like this:
>>>>>
>>>>> iosf_mbi_punit_acquire();
>>>>>
>>>>> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
>>>>> val &= ~DSPFREQGUAR_MASK;
>>>>> val |= (cmd << DSPFREQGUAR_SHIFT);
>>>>> vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
>>>>> if (wait_for((vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ) &
>>>>> DSPFREQSTAT_MASK) == (cmd << DSPFREQSTAT_SHIFT),
>>>>> 50)) {
>>>>> DRM_ERROR("timed out waiting for CDclk change\n");
>>>>> }
>>>>> iosf_mbi_punit_release();
>>>>>
>>>>> Where we want to wait for the requested change to have taken
>>>>> effect before releasing the punit.
>>>
>>> Hmm. That's somewhat unfortunate. It also highlights a problem with the
>>> patch wrt. RPS. We don't wait for the GPU to actually change frequencies
>>> in set_rps() because that would slow things down too much. So I have to
>>> wonder how much luck is needed to make this workaround really effective.
>>
>> So the history of this patch-set is that I wrote this patch before
>> writing the patch to get FORCEWAKE_ALL before the pmic bus becomes
>> active (patch 12/13). Since a lot of testing was done with this
>> patch included in the patch-set and since it seemed a good idea
>> regardless (given my experience with accessing the punit vs
>> pmic bus accesses) I decided to leave it in.
>>
>> Possibly just the patch to get FORCEWAKE_ALL is enough, that one
>> actually fixed things for me. That is also why I made this the
>> last patch in the set. I asked tagorereddy to test his system
>> without this patch, but he did not get around to that.
>>
>> After all we do tell the punit to not touch the bus by acquiring
>> the pmic bus semaphore from i2c-desigware-baytrail.c, so maybe
>> for RPS freq changes it honors that and properly waits. Maybe it
>> honors that for all punit requests i915 does and the only real
>> problem is the forcewake stuff ?
>>
>> I can try to drop this patch from my queue and run without it
>> for a while and see if things don't regress. And also ask
>> tagorereddy again to test his system that way.
>>
>> Does that (dropping this patch for now) sound like a good idea?
>
> More test results couldn't hurt at least.
Ok, I've done a whole bunch of suspend + resume cycles on my cht
tablet with this patch dropped and things still work fine
(where as without the first 12 patches of this patch-set that
was a guarenteed way to get a forcewake timeout followed by
a lockup).
So it indeed seems this test is not necessary. I'll send a v3
with that patch dropped, as well as your comments for
patches 11 and 12 being addressed.
Regards,
Hans
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH v3 01/12] x86/platform/intel/iosf_mbi: Add a mutex for P-Unit access
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: russianneuromancer @ ya . ru, intel-gfx, dri-devel, Hans de Goede,
linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
One some systems the P-Unit accesses the PMIC to change various voltages
through the same bus as other kernel drivers use for e.g. battery
monitoring.
If a driver sends requests to the P-Unit which require the P-Unit to access
the PMIC bus while another driver is also accessing the PMIC bus various
bad things happen.
This commit adds a mutex to protect the P-Unit against simultaneous
accesses and 2 functions to lock / unlock this mutex.
Note on these systems the i2c-bus driver will request a sempahore from the
P-Unit for exclusive access to the PMIC bus when i2c drivers are accessing
it, but this does not appear to be sufficient, we still need to avoid
making certain P-Unit requests during the access window to avoid problems.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: tagorereddy <tagore.chandan@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Changes in v2:
-Rename iosf_mbi_punit_lock/_unlock to _acquire/_release rename
-Spelling: P-Unit, PMIC
---
arch/x86/include/asm/iosf_mbi.h | 31 +++++++++++++++++++++++++++++++
arch/x86/platform/intel/iosf_mbi.c | 13 +++++++++++++
2 files changed, 44 insertions(+)
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index b41ee16..f6119d0 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -88,6 +88,33 @@ int iosf_mbi_write(u8 port, u8 opcode, u32 offset, u32 mdr);
*/
int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask);
+/**
+ * iosf_mbi_punit_acquire() - Acquire access to the P-Unit
+ *
+ * One some systems the P-Unit accesses the PMIC to change various voltages
+ * through the same bus as other kernel drivers use for e.g. battery monitoring.
+ *
+ * If a driver sends requests to the P-Unit which require the P-Unit to access
+ * the PMIC bus while another driver is also accessing the PMIC bus various bad
+ * things happen.
+ *
+ * To avoid these problems this function must be called before accessing the
+ * P-Unit or the PMIC, be it through iosf_mbi* functions or through other means.
+ *
+ * Note on these systems the i2c-bus driver will request a sempahore from the
+ * P-Unit for exclusive access to the PMIC bus when i2c drivers are accessing
+ * it, but this does not appear to be sufficient, we still need to avoid making
+ * certain P-Unit requests during the access window to avoid problems.
+ *
+ * This function locks a mutex, as such it may sleep.
+ */
+void iosf_mbi_punit_acquire(void);
+
+/**
+ * iosf_mbi_punit_release() - Release access to the P-Unit
+ */
+void iosf_mbi_punit_release(void);
+
#else /* CONFIG_IOSF_MBI is not enabled */
static inline
bool iosf_mbi_available(void)
@@ -115,6 +142,10 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
WARN(1, "IOSF_MBI driver not available");
return -EPERM;
}
+
+static inline void iosf_mbi_punit_acquire(void) {}
+static inline void iosf_mbi_punit_release(void) {}
+
#endif /* CONFIG_IOSF_MBI */
#endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/platform/intel/iosf_mbi.c b/arch/x86/platform/intel/iosf_mbi.c
index edf2c54..ed24fa9f 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -34,6 +34,7 @@
static struct pci_dev *mbi_pdev;
static DEFINE_SPINLOCK(iosf_mbi_lock);
+static DEFINE_MUTEX(iosf_mbi_punit_mutex);
static inline u32 iosf_mbi_form_mcr(u8 op, u8 port, u8 offset)
{
@@ -190,6 +191,18 @@ bool iosf_mbi_available(void)
}
EXPORT_SYMBOL(iosf_mbi_available);
+void iosf_mbi_punit_acquire(void)
+{
+ mutex_lock(&iosf_mbi_punit_mutex);
+}
+EXPORT_SYMBOL(iosf_mbi_punit_acquire);
+
+void iosf_mbi_punit_release(void)
+{
+ mutex_unlock(&iosf_mbi_punit_mutex);
+}
+EXPORT_SYMBOL(iosf_mbi_punit_release);
+
#ifdef CONFIG_IOSF_MBI_DEBUG
static u32 dbg_mdr;
static u32 dbg_mcr;
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 02/12] x86/platform/intel/iosf_mbi: Add a PMIC bus access notifier
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: russianneuromancer @ ya . ru, intel-gfx, dri-devel, Hans de Goede,
linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
Some drivers may need to acquire P-Unit managed resources from interrupt
context, where they cannot call iosf_mbi_punit_acquire().
This commit adds a notifier chain which allows a driver to get notified
(in a process context) before other drivers start accessing the PMIC bus,
so that the driver can acquire any resources, which it may need during
the window the other driver is accessing the PMIC, before hand.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: tagorereddy <tagore.chandan@gmail.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
---
Changes in v2:
-Spelling: P-Unit, PMIC
-Adjust for iosf_mbi_punit_lock/_unlock to _acquire/_release rename
---
arch/x86/include/asm/iosf_mbi.h | 54 ++++++++++++++++++++++++++++++++++++++
arch/x86/platform/intel/iosf_mbi.c | 36 +++++++++++++++++++++++++
2 files changed, 90 insertions(+)
diff --git a/arch/x86/include/asm/iosf_mbi.h b/arch/x86/include/asm/iosf_mbi.h
index f6119d0..59e8f8b 100644
--- a/arch/x86/include/asm/iosf_mbi.h
+++ b/arch/x86/include/asm/iosf_mbi.h
@@ -47,6 +47,10 @@
#define QRK_MBI_UNIT_MM 0x05
#define QRK_MBI_UNIT_SOC 0x31
+/* Action values for the pmic_bus_access_notifier functions */
+#define MBI_PMIC_BUS_ACCESS_BEGIN 1
+#define MBI_PMIC_BUS_ACCESS_END 2
+
#if IS_ENABLED(CONFIG_IOSF_MBI)
bool iosf_mbi_available(void);
@@ -115,6 +119,38 @@ void iosf_mbi_punit_acquire(void);
*/
void iosf_mbi_punit_release(void);
+/**
+ * iosf_mbi_register_pmic_bus_access_notifier - Register PMIC bus notifier
+ *
+ * This function can be used by drivers which may need to acquire P-Unit
+ * managed resources from interrupt context, where iosf_mbi_punit_acquire()
+ * can not be used.
+ *
+ * This function allows a driver to register a notifier to get notified (in a
+ * process context) before other drivers start accessing the PMIC bus.
+ *
+ * This allows the driver to acquire any resources, which it may need during
+ * the window the other driver is accessing the PMIC, before hand.
+ *
+ * @nb: notifier_block to register
+ */
+int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb);
+
+/**
+ * iosf_mbi_register_pmic_bus_access_notifier - Unregister PMIC bus notifier
+ *
+ * @nb: notifier_block to unregister
+ */
+int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb);
+
+/**
+ * iosf_mbi_call_pmic_bus_access_notifier_chain - Call PMIC bus notifier chain
+ *
+ * @val: action to pass into listener's notifier_call function
+ * @v: data pointer to pass into listener's notifier_call function
+ */
+int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v);
+
#else /* CONFIG_IOSF_MBI is not enabled */
static inline
bool iosf_mbi_available(void)
@@ -146,6 +182,24 @@ int iosf_mbi_modify(u8 port, u8 opcode, u32 offset, u32 mdr, u32 mask)
static inline void iosf_mbi_punit_acquire(void) {}
static inline void iosf_mbi_punit_release(void) {}
+static inline
+int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline
+int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
+{
+ return 0;
+}
+
+static inline
+int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v)
+{
+ return 0;
+}
+
#endif /* CONFIG_IOSF_MBI */
#endif /* IOSF_MBI_SYMS_H */
diff --git a/arch/x86/platform/intel/iosf_mbi.c b/arch/x86/platform/intel/iosf_mbi.c
index ed24fa9f..a952ac1 100644
--- a/arch/x86/platform/intel/iosf_mbi.c
+++ b/arch/x86/platform/intel/iosf_mbi.c
@@ -35,6 +35,7 @@
static struct pci_dev *mbi_pdev;
static DEFINE_SPINLOCK(iosf_mbi_lock);
static DEFINE_MUTEX(iosf_mbi_punit_mutex);
+static BLOCKING_NOTIFIER_HEAD(iosf_mbi_pmic_bus_access_notifier);
static inline u32 iosf_mbi_form_mcr(u8 op, u8 port, u8 offset)
{
@@ -203,6 +204,41 @@ void iosf_mbi_punit_release(void)
}
EXPORT_SYMBOL(iosf_mbi_punit_release);
+int iosf_mbi_register_pmic_bus_access_notifier(struct notifier_block *nb)
+{
+ int ret;
+
+ /* Wait for the bus to go inactive before registering */
+ mutex_lock(&iosf_mbi_punit_mutex);
+ ret = blocking_notifier_chain_register(
+ &iosf_mbi_pmic_bus_access_notifier, nb);
+ mutex_unlock(&iosf_mbi_punit_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(iosf_mbi_register_pmic_bus_access_notifier);
+
+int iosf_mbi_unregister_pmic_bus_access_notifier(struct notifier_block *nb)
+{
+ int ret;
+
+ /* Wait for the bus to go inactive before unregistering */
+ mutex_lock(&iosf_mbi_punit_mutex);
+ ret = blocking_notifier_chain_unregister(
+ &iosf_mbi_pmic_bus_access_notifier, nb);
+ mutex_unlock(&iosf_mbi_punit_mutex);
+
+ return ret;
+}
+EXPORT_SYMBOL(iosf_mbi_unregister_pmic_bus_access_notifier);
+
+int iosf_mbi_call_pmic_bus_access_notifier_chain(unsigned long val, void *v)
+{
+ return blocking_notifier_call_chain(
+ &iosf_mbi_pmic_bus_access_notifier, val, v);
+}
+EXPORT_SYMBOL(iosf_mbi_call_pmic_bus_access_notifier_chain);
+
#ifdef CONFIG_IOSF_MBI_DEBUG
static u32 dbg_mdr;
static u32 dbg_mcr;
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 03/12] i2c: designware: Rename accessor_flags to flags
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: russianneuromancer @ ya . ru, intel-gfx, dri-devel, Hans de Goede,
linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
Rename accessor_flags to flags, so that we can use the field for
other flags too. This is a preparation patch for adding cherrytrail
support to the punit semaphore code.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-designware-core.c | 14 +++++++-------
drivers/i2c/busses/i2c-designware-core.h | 2 +-
drivers/i2c/busses/i2c-designware-platdrv.c | 2 +-
3 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-core.c b/drivers/i2c/busses/i2c-designware-core.c
index 6d81c56..8c3ba42 100644
--- a/drivers/i2c/busses/i2c-designware-core.c
+++ b/drivers/i2c/busses/i2c-designware-core.c
@@ -177,13 +177,13 @@ static u32 dw_readl(struct dw_i2c_dev *dev, int offset)
{
u32 value;
- if (dev->accessor_flags & ACCESS_16BIT)
+ if (dev->flags & ACCESS_16BIT)
value = readw_relaxed(dev->base + offset) |
(readw_relaxed(dev->base + offset + 2) << 16);
else
value = readl_relaxed(dev->base + offset);
- if (dev->accessor_flags & ACCESS_SWAP)
+ if (dev->flags & ACCESS_SWAP)
return swab32(value);
else
return value;
@@ -191,10 +191,10 @@ static u32 dw_readl(struct dw_i2c_dev *dev, int offset)
static void dw_writel(struct dw_i2c_dev *dev, u32 b, int offset)
{
- if (dev->accessor_flags & ACCESS_SWAP)
+ if (dev->flags & ACCESS_SWAP)
b = swab32(b);
- if (dev->accessor_flags & ACCESS_16BIT) {
+ if (dev->flags & ACCESS_16BIT) {
writew_relaxed((u16)b, dev->base + offset);
writew_relaxed((u16)(b >> 16), dev->base + offset + 2);
} else {
@@ -339,10 +339,10 @@ int i2c_dw_init(struct dw_i2c_dev *dev)
reg = dw_readl(dev, DW_IC_COMP_TYPE);
if (reg == ___constant_swab32(DW_IC_COMP_TYPE_VALUE)) {
/* Configure register endianess access */
- dev->accessor_flags |= ACCESS_SWAP;
+ dev->flags |= ACCESS_SWAP;
} else if (reg == (DW_IC_COMP_TYPE_VALUE & 0x0000ffff)) {
/* Configure register access mode 16bit */
- dev->accessor_flags |= ACCESS_16BIT;
+ dev->flags |= ACCESS_16BIT;
} else if (reg != DW_IC_COMP_TYPE_VALUE) {
dev_err(dev->dev, "Unknown Synopsys component type: "
"0x%08x\n", reg);
@@ -926,7 +926,7 @@ static irqreturn_t i2c_dw_isr(int this_irq, void *dev_id)
tx_aborted:
if ((stat & (DW_IC_INTR_TX_ABRT | DW_IC_INTR_STOP_DET)) || dev->msg_err)
complete(&dev->cmd_complete);
- else if (unlikely(dev->accessor_flags & ACCESS_INTR_MASK)) {
+ else if (unlikely(dev->flags & ACCESS_INTR_MASK)) {
/* workaround to trigger pending interrupt */
stat = dw_readl(dev, DW_IC_INTR_MASK);
i2c_dw_disable_int(dev);
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 26250b4..2c50571 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -103,7 +103,7 @@ struct dw_i2c_dev {
unsigned int status;
u32 abort_source;
int irq;
- u32 accessor_flags;
+ u32 flags;
struct i2c_adapter adapter;
u32 functionality;
u32 master_cfg;
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 6ce4313..3eede7b 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -112,7 +112,7 @@ static int dw_i2c_acpi_configure(struct platform_device *pdev)
id = acpi_match_device(pdev->dev.driver->acpi_match_table, &pdev->dev);
if (id && id->driver_data)
- dev->accessor_flags |= (u32)id->driver_data;
+ dev->flags |= (u32)id->driver_data;
return 0;
}
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 04/12] i2c: designware-baytrail: Pass dw_i2c_dev into helper functions
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: russianneuromancer @ ya . ru, intel-gfx, dri-devel, Hans de Goede,
linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
Pass dw_i2c_dev into the helper functions, this is a preparation patch
for the punit semaphore fixes done in the other patches in this set.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
---
drivers/i2c/busses/i2c-designware-baytrail.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c b/drivers/i2c/busses/i2c-designware-baytrail.c
index 1590ad0..a3f581c 100644
--- a/drivers/i2c/busses/i2c-designware-baytrail.c
+++ b/drivers/i2c/busses/i2c-designware-baytrail.c
@@ -28,14 +28,14 @@
static unsigned long acquired;
-static int get_sem(struct device *dev, u32 *sem)
+static int get_sem(struct dw_i2c_dev *dev, u32 *sem)
{
u32 data;
int ret;
ret = iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, PUNIT_SEMAPHORE, &data);
if (ret) {
- dev_err(dev, "iosf failed to read punit semaphore\n");
+ dev_err(dev->dev, "iosf failed to read punit semaphore\n");
return ret;
}
@@ -44,18 +44,18 @@ static int get_sem(struct device *dev, u32 *sem)
return 0;
}
-static void reset_semaphore(struct device *dev)
+static void reset_semaphore(struct dw_i2c_dev *dev)
{
u32 data;
if (iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, PUNIT_SEMAPHORE, &data)) {
- dev_err(dev, "iosf failed to reset punit semaphore during read\n");
+ dev_err(dev->dev, "iosf failed to reset punit semaphore during read\n");
return;
}
data &= ~PUNIT_SEMAPHORE_BIT;
if (iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, PUNIT_SEMAPHORE, data))
- dev_err(dev, "iosf failed to reset punit semaphore during write\n");
+ dev_err(dev->dev, "iosf failed to reset punit semaphore during write\n");
}
static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
@@ -83,7 +83,7 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
start = jiffies;
end = start + msecs_to_jiffies(SEMAPHORE_TIMEOUT);
do {
- ret = get_sem(dev->dev, &sem);
+ ret = get_sem(dev, &sem);
if (!ret && sem) {
acquired = jiffies;
dev_dbg(dev->dev, "punit semaphore acquired after %ums\n",
@@ -95,7 +95,7 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
} while (time_before(jiffies, end));
dev_err(dev->dev, "punit semaphore timed out, resetting\n");
- reset_semaphore(dev->dev);
+ reset_semaphore(dev);
ret = iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, PUNIT_SEMAPHORE, &sem);
if (ret)
@@ -116,7 +116,7 @@ static void baytrail_i2c_release(struct dw_i2c_dev *dev)
if (!dev->acquire_lock)
return;
- reset_semaphore(dev->dev);
+ reset_semaphore(dev);
dev_dbg(dev->dev, "punit semaphore held for %ums\n",
jiffies_to_msecs(jiffies - acquired));
}
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH v3 05/12] i2c: designware-baytrail: Only check iosf_mbi_available() for shared hosts
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: Takashi Iwai, russianneuromancer @ ya . ru, intel-gfx, dri-devel,
Hans de Goede, linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
If (!shared_host) simply return 0, this avoids delaying the probe if
iosf_mbi_available() returns false when an i2c bus is not using the
punit semaphore.
Also move the if (!iosf_mbi_available()) check to above the
dev_info, so that we do not repeat the dev_info on every probe
until iosf_mbi_available() returns true.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
---
Changes in v2:
-New patch in v2 of this set
Changes in v3:
-Use if (!shared_host) return 0, to simplify the non-shared_host path
and to avoid nested ifs
---
drivers/i2c/busses/i2c-designware-baytrail.c | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c b/drivers/i2c/busses/i2c-designware-baytrail.c
index a3f581c..cf02222 100644
--- a/drivers/i2c/busses/i2c-designware-baytrail.c
+++ b/drivers/i2c/busses/i2c-designware-baytrail.c
@@ -138,15 +138,16 @@ int i2c_dw_eval_lock_support(struct dw_i2c_dev *dev)
if (ACPI_FAILURE(status))
return 0;
- if (shared_host) {
- dev_info(dev->dev, "I2C bus managed by PUNIT\n");
- dev->acquire_lock = baytrail_i2c_acquire;
- dev->release_lock = baytrail_i2c_release;
- dev->pm_runtime_disabled = true;
- }
+ if (!shared_host)
+ return 0;
if (!iosf_mbi_available())
return -EPROBE_DEFER;
+ dev_info(dev->dev, "I2C bus managed by PUNIT\n");
+ dev->acquire_lock = baytrail_i2c_acquire;
+ dev->release_lock = baytrail_i2c_release;
+ dev->pm_runtime_disabled = true;
+
return 0;
}
--
2.9.3
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply related
* [PATCH v3 06/12] i2c: designware-baytrail: Disallow the CPU to enter C6 or C7 while holding the punit semaphore
From: Hans de Goede @ 2017-02-10 10:27 UTC (permalink / raw)
To: Daniel Vetter, Jani Nikula, Ville Syrjälä,
Jarkko Nikula, Wolfram Sang, Len Brown, Andy Shevchenko,
Thomas Gleixner, H . Peter Anvin
Cc: russianneuromancer @ ya . ru, intel-gfx, dri-devel, Hans de Goede,
linux-i2c, Mika Westerberg
In-Reply-To: <20170210102802.20898-1-hdegoede@redhat.com>
On my cherrytrail tablet with axp288 pmic, just doing a bunch of repeated
reads from the pmic, e.g. "i2cdump -y 14 0x34" would lookup the tablet in
1 - 3 runs guaranteed.
This seems to be causes by the cpu trying to enter C6 or C7 while we hold
the punit bus semaphore, at which point everything just hangs.
Avoid this by disallowing the CPU to enter C6 or C7 before acquiring the
punit bus semaphore.
BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=109051
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Tested-by: Takashi Iwai <tiwai@suse.de>
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Acked-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Acked-by: Wolfram Sang <wsa@the-dreams.de>
---
Changes in v2:
-New patch in v2 of this set
Changes in v3:
-Change commit message and comment in the code from "force the CPU to C1"
to "Disallow the CPU to enter C6 or C7", as the CPU may still be in either
C0 or C1 with the request pm_qos
Changes in v4:
-Rename i2c_dw_eval_lock_support to i2c_dw_probe_lock_support so that we can
add a matching i2c_dw_remove_lock_support cleanup function
-Move qm_pos removal to new i2c_dw_remove_lock_support function
-Move pm_qos_add_request to the end of i2c_dw_probe_lock_support
Changes in v5:
-Update the pm_qos for a latency of 0 *before* requesting the semaphore,
instead of doing it while waiting for the request to be acked
---
drivers/i2c/busses/i2c-designware-baytrail.c | 24 ++++++++++++++++++++++--
drivers/i2c/busses/i2c-designware-core.h | 9 +++++++--
drivers/i2c/busses/i2c-designware-platdrv.c | 4 +++-
3 files changed, 32 insertions(+), 5 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-baytrail.c b/drivers/i2c/busses/i2c-designware-baytrail.c
index cf02222..650a700 100644
--- a/drivers/i2c/busses/i2c-designware-baytrail.c
+++ b/drivers/i2c/busses/i2c-designware-baytrail.c
@@ -16,6 +16,7 @@
#include <linux/acpi.h>
#include <linux/i2c.h>
#include <linux/interrupt.h>
+#include <linux/pm_qos.h>
#include <asm/iosf_mbi.h>
@@ -56,6 +57,8 @@ static void reset_semaphore(struct dw_i2c_dev *dev)
data &= ~PUNIT_SEMAPHORE_BIT;
if (iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, PUNIT_SEMAPHORE, data))
dev_err(dev->dev, "iosf failed to reset punit semaphore during write\n");
+
+ pm_qos_update_request(&dev->pm_qos, PM_QOS_DEFAULT_VALUE);
}
static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
@@ -72,11 +75,18 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
if (!dev->release_lock)
return 0;
+ /*
+ * Disallow the CPU to enter C6 or C7 state, entering these states
+ * requires the punit to talk to the pmic and if this happens while
+ * we're holding the semaphore, the SoC hangs.
+ */
+ pm_qos_update_request(&dev->pm_qos, 0);
+
/* host driver writes to side band semaphore register */
ret = iosf_mbi_write(BT_MBI_UNIT_PMC, MBI_REG_WRITE, PUNIT_SEMAPHORE, sem);
if (ret) {
dev_err(dev->dev, "iosf punit semaphore request failed\n");
- return ret;
+ goto out;
}
/* host driver waits for bit 0 to be set in semaphore register */
@@ -95,6 +105,7 @@ static int baytrail_i2c_acquire(struct dw_i2c_dev *dev)
} while (time_before(jiffies, end));
dev_err(dev->dev, "punit semaphore timed out, resetting\n");
+out:
reset_semaphore(dev);
ret = iosf_mbi_read(BT_MBI_UNIT_PMC, MBI_REG_READ, PUNIT_SEMAPHORE, &sem);
@@ -121,7 +132,7 @@ static void baytrail_i2c_release(struct dw_i2c_dev *dev)
jiffies_to_msecs(jiffies - acquired));
}
-int i2c_dw_eval_lock_support(struct dw_i2c_dev *dev)
+int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev)
{
acpi_status status;
unsigned long long shared_host = 0;
@@ -149,5 +160,14 @@ int i2c_dw_eval_lock_support(struct dw_i2c_dev *dev)
dev->release_lock = baytrail_i2c_release;
dev->pm_runtime_disabled = true;
+ pm_qos_add_request(&dev->pm_qos, PM_QOS_CPU_DMA_LATENCY,
+ PM_QOS_DEFAULT_VALUE);
+
return 0;
}
+
+void i2c_dw_remove_lock_support(struct dw_i2c_dev *dev)
+{
+ if (dev->acquire_lock)
+ pm_qos_remove_request(&dev->pm_qos);
+}
diff --git a/drivers/i2c/busses/i2c-designware-core.h b/drivers/i2c/busses/i2c-designware-core.h
index 2c50571..94a5fd1 100644
--- a/drivers/i2c/busses/i2c-designware-core.h
+++ b/drivers/i2c/busses/i2c-designware-core.h
@@ -23,6 +23,7 @@
*/
#include <linux/i2c.h>
+#include <linux/pm_qos.h>
#define DW_IC_DEFAULT_FUNCTIONALITY (I2C_FUNC_I2C | \
I2C_FUNC_SMBUS_BYTE | \
@@ -75,6 +76,7 @@
* @fp_lcnt: fast plus LCNT value
* @hs_hcnt: high speed HCNT value
* @hs_lcnt: high speed LCNT value
+ * @pm_qos: pm_qos_request used while holding a hardware lock on the bus
* @acquire_lock: function to acquire a hardware lock on the bus
* @release_lock: function to release a hardware lock on the bus
* @pm_runtime_disabled: true if pm runtime is disabled
@@ -122,6 +124,7 @@ struct dw_i2c_dev {
u16 fp_lcnt;
u16 hs_hcnt;
u16 hs_lcnt;
+ struct pm_qos_request pm_qos;
int (*acquire_lock)(struct dw_i2c_dev *dev);
void (*release_lock)(struct dw_i2c_dev *dev);
bool pm_runtime_disabled;
@@ -139,7 +142,9 @@ extern u32 i2c_dw_read_comp_param(struct dw_i2c_dev *dev);
extern int i2c_dw_probe(struct dw_i2c_dev *dev);
#if IS_ENABLED(CONFIG_I2C_DESIGNWARE_BAYTRAIL)
-extern int i2c_dw_eval_lock_support(struct dw_i2c_dev *dev);
+extern int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev);
+extern void i2c_dw_remove_lock_support(struct dw_i2c_dev *dev);
#else
-static inline int i2c_dw_eval_lock_support(struct dw_i2c_dev *dev) { return 0; }
+static inline int i2c_dw_probe_lock_support(struct dw_i2c_dev *dev) { return 0; }
+static inline void i2c_dw_remove_lock_support(struct dw_i2c_dev *dev) {}
#endif
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c b/drivers/i2c/busses/i2c-designware-platdrv.c
index 3eede7b..d474db0 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -238,7 +238,7 @@ static int dw_i2c_plat_probe(struct platform_device *pdev)
return -EINVAL;
}
- r = i2c_dw_eval_lock_support(dev);
+ r = i2c_dw_probe_lock_support(dev);
if (r)
return r;
@@ -307,6 +307,8 @@ static int dw_i2c_plat_remove(struct platform_device *pdev)
if (!dev->pm_runtime_disabled)
pm_runtime_disable(&pdev->dev);
+ i2c_dw_remove_lock_support(dev);
+
return 0;
}
--
2.9.3
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox