[PATCH v2 0/1] ARM: shmobile: r8a7790: add I2C support
From: Nguyen Viet Dung nv-d...@jinso.co.jp Hello, CC Morimoto Please consider the following patch for the r8a7790 Soc. This patch modify I2C driver of rcar-H1 to usable on both rcar-H1 and rcar-H2. It was developed base on the renesas-next-20130528 branch and have tested on the Lager board. Input clock of I2C is peripheral module clock that is named peripheral_clk. V2: dropped patches 2,3,4 from the previous version. Thanks, Nguyen viet Dung Nguyen Viet Dung (1): i2c: rcar: modify I2C driver drivers/i2c/busses/i2c-rcar.c | 17 +++-- include/linux/i2c/i2c-rcar.h |4 2 files changed, 19 insertions(+), 2 deletions(-) -- 1.7.9.5 -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2 1/1] i2c: rcar: modify I2C driver
From: Nguyen Viet Dung nv-d...@jinso.co.jp
This patch modify calculate for clock in I2C driver.
Signed-off-by: Nguyen Viet Dung nv-d...@jinso.co.jp
---
drivers/i2c/busses/i2c-rcar.c | 17 +++--
include/linux/i2c/i2c-rcar.h |4
2 files changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 4ba4a95..85987c1 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
@@ -221,15 +221,28 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
struct device *dev)
{
struct clk *clkp = clk_get(NULL, peripheral_clk);
+ struct i2c_rcar_platform_data *pdata = dev-platform_data;
u32 scgd, cdf;
u32 round, ick;
u32 scl;
+ u32 cdf_width;
+ u32 flags = pdata ? pdata-flags : 0;
if (!clkp) {
dev_err(dev, there is no peripheral_clk\n);
return -EIO;
}
+ switch (flags I2C_RCAR_FLAGS_ICCCR_MASK) {
+ default:
+ case I2C_RCAR_FLAGS_ICCCR_IS_2BIT:
+ cdf_width = 2;
+ break;
+ case I2C_RCAR_FLAGS_ICCCR_IS_3BIT:
+ cdf_width = 3;
+ break;
+ }
+
/*
* calculate SCL clock
* see
@@ -245,7 +258,7 @@ static int rcar_i2c_clock_calculate(struct rcar_i2c_priv
*priv,
* clkp : peripheral_clk
* F[] : integer up-valuation
*/
- for (cdf = 0; cdf 4; cdf++) {
+ for (cdf = 0; cdf (1 cdf_width); cdf++) {
ick = clk_get_rate(clkp) / (1 + cdf);
if (ick 2000)
goto ick_find;
@@ -287,7 +300,7 @@ scgd_find:
/*
* keep icccr value
*/
- priv-icccr = (scgd 2 | cdf);
+ priv-icccr = (scgd (cdf_width) | cdf);
return 0;
}
diff --git a/include/linux/i2c/i2c-rcar.h b/include/linux/i2c/i2c-rcar.h
index 496f5c2..572a6e5 100644
--- a/include/linux/i2c/i2c-rcar.h
+++ b/include/linux/i2c/i2c-rcar.h
@@ -5,6 +5,10 @@
struct i2c_rcar_platform_data {
u32 bus_speed;
+ u32 flags;
+#define I2C_RCAR_FLAGS_ICCCR_MASK (0xF 0)
+#define I2C_RCAR_FLAGS_ICCCR_IS_2BIT (0 0) /* default */
+#define I2C_RCAR_FLAGS_ICCCR_IS_3BIT (1 0)
};
#endif /* __I2C_R_CAR_H__ */
--
1.7.9.5
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c-designware: make *CNT values configurable
On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote: What I meant is the following: The clock cycle time Tc is composed of the four components Tc = Th + Tf + Tl + Tr where Th: Time during which the signal is high Tf: Falling edge transition time Tl: Time during which the signal is low Tr: Rising edge transition time The I2C specification specifies a minimum for Tl and Th and a range (or maximum) for Tr and Tf. A maximum frequency is specified as the frequency obtained by adding the minima for Th and Tl to the maxima of Tr ant Tf. Since as you said, transition times are very much PCB dependent, one way to guarantee the max. frequency constraint (and to achieve a constant frequency at its max) is to define the constants Th' = Th + Tf := Th_min + Tf_max Tl' = Tl + Tr := Tl_min + Tr_max and to calculate the variables Th = Th' - Tf Tl = Tl' - Tr in function of Tf and Tr of the given PCB. If I understand the above, it leaves Tf and Tr to be PCB specific and then these values are passed to the core driver from platform data, right? I'm thinking that passing directly the measured *CNT values from the platform data makes this even more accurate (given that information is available). And if you only have the Tf and Tr for your board, you can have custom calculation done in the platform part of the driver that takes them into account, and then passes these custom *CNT values to the core. At least on Intel hardware we have an ACPI method that returns directly the optimum *CNT values. I don't know ACPI very well and if it deals with register values directly your patch is probably the right thing. Our FW people decided to have a custom ACPI method that returns the correct values to be used in the Windows I2C driver. It returns direct *CNT register values that have been measured to be good for a given PCB. The timing calculation in the driver seems a bit strange to me, however (see above), but I never dared touching it because I never had time to dive into the code deep enough and I was just wondering if it was possible to fix it at the same time. It would be good if we can fix this for non-ACPI devices as well. Is it hard to add similar properties to the driver specific Device Tree bindings? Wolfram, do you have any input on this? -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/2] i2c-designware: configure *CNT values from ACPI
On Mon, Jul 08, 2013 at 02:45:27PM +0300, Mika Westerberg wrote:
Some Intel LPSS I2C devices make the *CNT values available from ACPI
namespace in similar way than the SDA hold value. These values allow
platform/BIOS to specify the most accurate *CNT values for the device
driver to use.
So change the ACPI part of the driver to use these values if they exists
and otherwise use the default method based solely on the input clock speed.
Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com
---
This applies on top of following patch which is not yet in i2c tree:
http://permalink.gmane.org/gmane.linux.drivers.i2c/15754
drivers/i2c/busses/i2c-designware-platdrv.c | 25 +
1 file changed, 21 insertions(+), 4 deletions(-)
diff --git a/drivers/i2c/busses/i2c-designware-platdrv.c
b/drivers/i2c/busses/i2c-designware-platdrv.c
index c7cfdac..a1488df 100644
--- a/drivers/i2c/busses/i2c-designware-platdrv.c
+++ b/drivers/i2c/busses/i2c-designware-platdrv.c
@@ -59,7 +59,6 @@ static int dw_i2c_acpi_configure(struct platform_device
*pdev)
struct dw_i2c_dev *dev = platform_get_drvdata(pdev);
struct acpi_buffer buf = { ACPI_ALLOCATE_BUFFER };
acpi_handle handle = ACPI_HANDLE(pdev-dev);
- acpi_string name;
if (!handle)
return -ENODEV;
@@ -68,14 +67,32 @@ static int dw_i2c_acpi_configure(struct platform_device
*pdev)
dev-tx_fifo_depth = 32;
dev-rx_fifo_depth = 32;
- name = dev-master_cfg DW_IC_CON_SPEED_FAST ? FMCN : SSCN;
- if (ACPI_SUCCESS(acpi_evaluate_object(handle, name, NULL, buf))) {
+ /* Standard speed configuration */
+ if (ACPI_SUCCESS(acpi_evaluate_object(handle, SSCN, NULL, buf))) {
union acpi_object *obj = (union acpi_object *)buf.pointer;
if (obj-type == ACPI_TYPE_PACKAGE obj-package.count == 3) {
const union acpi_object *objs = obj-package.elements;
- dev-sda_hold_time = (u32)objs[2].integer.value;
+ dev-ss_hcnt = (u16)objs[0].integer.value;
+ dev-ss_lcnt = (u16)objs[1].integer.value;
+ if (!(dev-master_cfg DW_IC_CON_SPEED_FAST))
+ dev-sda_hold_time = (u32)objs[2].integer.value;
+ }
+
+ kfree(buf.pointer);
+ }
+ /* Fast speed configuration */
+ if (ACPI_SUCCESS(acpi_evaluate_object(handle, FMCN, NULL, buf))) {
There is a problem with the above as it reuses buf from the previous call.
I'll post a new revision of the patches with this fixed.
+ union acpi_object *obj = (union acpi_object *)buf.pointer;
+
+ if (obj-type == ACPI_TYPE_PACKAGE obj-package.count == 3) {
+ const union acpi_object *objs = obj-package.elements;
+
+ dev-fs_hcnt = (u16)objs[0].integer.value;
+ dev-fs_lcnt = (u16)objs[1].integer.value;
+ if (dev-master_cfg DW_IC_CON_SPEED_FAST)
+ dev-sda_hold_time = (u32)objs[2].integer.value;
}
kfree(buf.pointer);
--
1.8.3.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c-designware: configure SDA hold time from ACPI
On Wed, Jul 03, 2013 at 12:52:40PM +0300, Mika Westerberg wrote: Some Intel LPSS I2C devices make the SDA hold time parameter available via SSCN (standard mode) and FMCN (fast mode) ACPI methods. If we find that such method exist, we evaluate it and pass the returned SDA hold value to the i2c-designware core analogous to Device Tree. Signed-off-by: Mika Westerberg mika.westerb...@linux.intel.com Please disregard this patch. I'll send a new one that combines both setting of SDA hold time and *CNT values from ACPI. -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] i2c-designware: make *CNT values configurable
On Wed, Jul 10, 2013 at 01:52:15PM +0300, Mika Westerberg wrote: On Tue, Jul 09, 2013 at 06:19:28PM +0200, Christian Ruppert wrote: What I meant is the following: The clock cycle time Tc is composed of the four components Tc = Th + Tf + Tl + Tr where Th: Time during which the signal is high Tf: Falling edge transition time Tl: Time during which the signal is low Tr: Rising edge transition time The I2C specification specifies a minimum for Tl and Th and a range (or maximum) for Tr and Tf. A maximum frequency is specified as the frequency obtained by adding the minima for Th and Tl to the maxima of Tr ant Tf. Since as you said, transition times are very much PCB dependent, one way to guarantee the max. frequency constraint (and to achieve a constant frequency at its max) is to define the constants Th' = Th + Tf := Th_min + Tf_max Tl' = Tl + Tr := Tl_min + Tr_max and to calculate the variables Th = Th' - Tf Tl = Tl' - Tr in function of Tf and Tr of the given PCB. If I understand the above, it leaves Tf and Tr to be PCB specific and then these values are passed to the core driver from platform data, right? That would be the idea: Calculate Th' and Tl' in function of the desired clock frequency and duty cycle and then adapt these values using measured transition times. What prevented me from implementing this rather academic approach are the following comments in i2c-designware-core.c: /* * DesignWare I2C core doesn't seem to have solid strategy to meet * the tHD;STA timing spec. Configuring _HCNT based on tHIGH spec * will result in violation of the tHD;STA spec. */ /* ... * This is just experimental rule; the tHD;STA period * turned out to be proportinal to (_HCNT + 3). With this setting, * we could meet both tHIGH and tHD;STA timing specs. * ... */ If I interpret this right, the slow down of the clock is intentional to meet tHD;STA timing constraints. I'm thinking that passing directly the measured *CNT values from the platform data makes this even more accurate (given that information is available). And if you only have the Tf and Tr for your board, you can have custom calculation done in the platform part of the driver that takes them into account, and then passes these custom *CNT values to the core. Well, as in the previous discussion on SDA hold time, Tf and Tr are physical values whereas the register values are clock dependent and probably not appropriate at least for device tree usage (or cases where the clock speed might change). If I understand you correctly, ACPI is more register oriented and able to cope with this outside of the OS? At least on Intel hardware we have an ACPI method that returns directly the optimum *CNT values. I don't know ACPI very well and if it deals with register values directly your patch is probably the right thing. Our FW people decided to have a custom ACPI method that returns the correct values to be used in the Windows I2C driver. It returns direct *CNT register values that have been measured to be good for a given PCB. The timing calculation in the driver seems a bit strange to me, however (see above), but I never dared touching it because I never had time to dive into the code deep enough and I was just wondering if it was possible to fix it at the same time. It would be good if we can fix this for non-ACPI devices as well. Is it hard to add similar properties to the driver specific Device Tree bindings? I think it would be quite trivial to add properties for either the register values or the transition time values. For SDA hold time we concluded that time values would be more adequate which brings us to the question of better understanding the hack for tHD;SDA. Otherwise we might break something. Do you think your team which determines the tHD;SDA values could give us some guidance on that? Wolfram, do you have any input on this? -- Christian Ruppert , christian.rupp...@abilis.com /| Tel: +41/(0)22 816 19-42 //| 3, Chemin du Pré-Fleuri _// | bilis Systems CH-1228 Plan-les-Ouates -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: mpc: Define unique I2C adapter names
The I2C adapters on Freescale MPC107/824x/85xx/512x/52xx/83xx/86xx all
have the same name MPC adapter. Since I2C adapter numbers can change
across reboots and even after loading/unloading an I2C bus master driver,
adapter names have to be used to identify adapters and thus should be
unique and well defined. Since this is not the case with this driver,
it is difficult if not impossible to identify a specific adapter from
user space on affected platforms.
To remedy the problem, use the adapter memory address as part of the
adapter name.
With this patch, adapter names are:
On P2020:
MPC adapter at 0xfff703000
MPC adapter at 0xfff703100
On P5040:
MPC adapter at 0xffe118000
MPC adapter at 0xffe118100
MPC adapter at 0xffe119000
MPC adapter at 0xffe119100
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/i2c/busses/i2c-mpc.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..99acf63 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -609,7 +609,6 @@ static const struct i2c_algorithm mpc_algo = {
static struct i2c_adapter mpc_ops = {
.owner = THIS_MODULE,
- .name = MPC adapter,
.algo = mpc_algo,
.timeout = HZ,
};
@@ -623,6 +622,7 @@ static int fsl_i2c_probe(struct platform_device *op)
u32 clock = MPC_I2C_CLOCK_LEGACY;
int result = 0;
int plen;
+ struct resource res;
match = of_match_device(mpc_i2c_of_match, op-dev);
if (!match)
@@ -682,6 +682,9 @@ static int fsl_i2c_probe(struct platform_device *op)
platform_set_drvdata(op, i2c);
i2c-adap = mpc_ops;
+ of_address_to_resource(op-dev.of_node, 0, res);
+ scnprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ MPC adapter at 0x%llx, (unsigned long long)res.start);
i2c_set_adapdata(i2c-adap, i2c);
i2c-adap.dev.parent = op-dev;
i2c-adap.dev.of_node = of_node_get(op-dev.of_node);
--
1.7.9.7
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: mpc: Define unique I2C adapter names
Hi Guenter,
On Wed, 10 Jul 2013 12:03:21 -0700, Guenter Roeck wrote:
The I2C adapters on Freescale MPC107/824x/85xx/512x/52xx/83xx/86xx all
have the same name MPC adapter. Since I2C adapter numbers can change
across reboots and even after loading/unloading an I2C bus master driver,
adapter names have to be used to identify adapters and thus should be
unique and well defined. Since this is not the case with this driver,
it is difficult if not impossible to identify a specific adapter from
user space on affected platforms.
To remedy the problem, use the adapter memory address as part of the
adapter name.
With this patch, adapter names are:
On P2020:
MPC adapter at 0xfff703000
MPC adapter at 0xfff703100
On P5040:
MPC adapter at 0xffe118000
MPC adapter at 0xffe118100
MPC adapter at 0xffe119000
MPC adapter at 0xffe119100
Signed-off-by: Guenter Roeck li...@roeck-us.net
---
drivers/i2c/busses/i2c-mpc.c |5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/drivers/i2c/busses/i2c-mpc.c b/drivers/i2c/busses/i2c-mpc.c
index 7607dc0..99acf63 100644
--- a/drivers/i2c/busses/i2c-mpc.c
+++ b/drivers/i2c/busses/i2c-mpc.c
@@ -609,7 +609,6 @@ static const struct i2c_algorithm mpc_algo = {
static struct i2c_adapter mpc_ops = {
.owner = THIS_MODULE,
- .name = MPC adapter,
.algo = mpc_algo,
.timeout = HZ,
};
@@ -623,6 +622,7 @@ static int fsl_i2c_probe(struct platform_device *op)
u32 clock = MPC_I2C_CLOCK_LEGACY;
int result = 0;
int plen;
+ struct resource res;
match = of_match_device(mpc_i2c_of_match, op-dev);
if (!match)
@@ -682,6 +682,9 @@ static int fsl_i2c_probe(struct platform_device *op)
platform_set_drvdata(op, i2c);
i2c-adap = mpc_ops;
+ of_address_to_resource(op-dev.of_node, 0, res);
+ scnprintf(i2c-adap.name, sizeof(i2c-adap.name),
+ MPC adapter at 0x%llx, (unsigned long long)res.start);
i2c_set_adapdata(i2c-adap, i2c);
i2c-adap.dev.parent = op-dev;
i2c-adap.dev.of_node = of_node_get(op-dev.of_node);
I'm not familiar with the i2c-mpc driver but the fix looks good to me.
Acked-by: Jean Delvare kh...@linux-fr.org
--
Jean Delvare
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/2] i2c_imc: New driver for Intel's iMC, found on LGA2011 chips
On Mon, Jul 1, 2013 at 4:30 PM, Andy Lutomirski l...@amacapital.net wrote: Sandy Bridge Xeon and Extreme chips have integrated memory controllers with (rather limited) onboard SMBUS masters. This driver gives access to the bus. Ugh! I think that this is related to erratum BT109 in the Xeon E5 spec update. (But then the erratum description is wrong.) Any Intel engineers want to comment? The workaround is going to be unpleasant. I wonder if there's some clean way to temporarily disable package c-states. Otherwise the driver may have to execute in a workqueue on the target package and spin or otherwise disable idle to keep the package awake. --Andy Signed-off-by: Andy Lutomirski l...@amacapital.net --- This is buggy as noted in the series description. Help would be much appreciated! drivers/i2c/busses/Kconfig | 14 ++ drivers/i2c/busses/Makefile | 1 + drivers/i2c/busses/i2c-imc.c | 462 +++ 3 files changed, 477 insertions(+) create mode 100644 drivers/i2c/busses/i2c-imc.c diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig index adfee98..91fd632 100644 --- a/drivers/i2c/busses/Kconfig +++ b/drivers/i2c/busses/Kconfig @@ -133,6 +133,20 @@ config I2C_ISMT This driver can also be built as a module. If so, the module will be called i2c-ismt. +config I2C_IMC + tristate Intel iMC (LGA 2011) SMBus Controller + depends on PCI X86 + help + If you say yes to this option, support will be included for the Intel + Integrated Memory Controller SMBus host controller interface. This + controller is found on LGA 2011 Xeons and Core i7 Extremes. + + It is possibly, although unlikely, that the use of this driver will + interfere with your platform's RAM thermal management. + + This driver can also be built as a module. If so, the module will be + called i2c-imc. + config I2C_PIIX4 tristate Intel PIIX4 and compatible (ATI/AMD/Serverworks/Broadcom/SMSC) depends on PCI diff --git a/drivers/i2c/busses/Makefile b/drivers/i2c/busses/Makefile index 8f4fc23..de46683 100644 --- a/drivers/i2c/busses/Makefile +++ b/drivers/i2c/busses/Makefile @@ -15,6 +15,7 @@ obj-$(CONFIG_I2C_AMD8111) += i2c-amd8111.o obj-$(CONFIG_I2C_I801) += i2c-i801.o obj-$(CONFIG_I2C_ISCH) += i2c-isch.o obj-$(CONFIG_I2C_ISMT) += i2c-ismt.o +obj-$(CONFIG_I2C_IMC) += i2c-imc.o obj-$(CONFIG_I2C_NFORCE2) += i2c-nforce2.o obj-$(CONFIG_I2C_NFORCE2_S4985)+= i2c-nforce2-s4985.o obj-$(CONFIG_I2C_PIIX4)+= i2c-piix4.o diff --git a/drivers/i2c/busses/i2c-imc.c b/drivers/i2c/busses/i2c-imc.c new file mode 100644 index 000..47ec903 --- /dev/null +++ b/drivers/i2c/busses/i2c-imc.c @@ -0,0 +1,462 @@ +/* +Copyright (c) 2013 Andrew Lutomirski l...@amacapital.net + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License version 2 +as published by the Free Software Foundation. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. +*/ + +#include linux/module.h +#include linux/pci.h +#include linux/kernel.h +#include linux/delay.h +#include linux/i2c.h + +/* + * The datasheet can be found here, for example: + * http://www.intel.com/content/dam/www/public/us/en/documents/datasheets/xeon-e5-1600-2600-vol-2-datasheet.pdf + */ + +/* Register offsets (in PCI configuration space) */ +#define SMBSTAT(i) (0x180 + 0x10*i) +#define SMBCMD(i) (0x184 + 0x10*i) +#define SMBCNTL(i) (0x188 + 0x10*i) +#define SMB_TSOD_POLL_RATE_CNTR(i) (0x18C + 0x10*i) +#define SMB_TSOD_POLL_RATE (0x1A8) + +/* SMBSTAT fields */ +#define SMBSTAT_RDO(1U 31) /* Read Data Valid */ +#define SMBSTAT_WOD(1U 30) /* Write Operation Done */ +#define SMBSTAT_SBE(1U 29) /* SMBus Error */ +#define SMBSTAT_SMB_BUSY (1U 28) /* SMBus Busy State */ +/* 26:24 is the last automatically polled TSOD address */ +#define SMBSTAT_RDATA_MASK 0x /* result of a read */ + +/* SMBCMD fields */ +#define SMBCMD_TRIGGER (1U 31) /* CMD Trigger */ +#define SMBCMD_PNTR_SEL(1U 30) /* HW polls TSOD with pointer */ +#define SMBCMD_WORD_ACCESS (1U 29) /* word (vs byte) access */ +#define
Temporarily disabling SNB package C-states?
I wrote a driver for the SNB Xeon iMC SMBUS adapter, but it doesn't work right due to erratum BT109 (I think). To work around it, I need to keep a particular cpu package awake for a few ms when my driver is in use. Is there a good way to do this? So far I've thought of: - pm_qos. This seems hacky and it will keep a lot more of the system awake than I need. - Hook into cpuidle to keep a single core awake. - Actually run on the target package, possibly in a kthread or workqueue, and stay busy. Ugh. - Fiddle with the package c-state limit (in MSR_PKG_CST_CONFIG_CONTROL) directly. This seems like it's asking for trouble. I'd have to coordinate with intel_idle, presumably. Any ideas/suggestions? --Andy -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] i2c: i2c-mxs: Check the return value from stmp_reset_block()
From: Fabio Estevam fabio.este...@freescale.com
stmp_reset_block() may fail, so let's check its return value and propagate it in
the case of error.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
drivers/i2c/busses/i2c-mxs.c | 12 +---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index df8ff5a..1891ae7 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -123,9 +123,11 @@ struct mxs_i2c_dev {
booldma_read;
};
-static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
+static int mxs_i2c_reset(struct mxs_i2c_dev *i2c)
{
- stmp_reset_block(i2c-regs);
+ int ret = stmp_reset_block(i2c-regs);
+ if (ret)
+ return ret;
/*
* Configure timing for the I2C block. The I2C TIMING2 register has to
@@ -139,6 +141,8 @@ static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
writel(0x00300030, i2c-regs + MXS_I2C_TIMING2);
writel(MXS_I2C_IRQ_MASK 8, i2c-regs + MXS_I2C_CTRL1_SET);
+
+ return 0;
}
static void mxs_i2c_dma_finish(struct mxs_i2c_dev *i2c)
@@ -683,7 +687,9 @@ static int mxs_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c);
/* Do reset to enforce correct startup after pinmuxing */
- mxs_i2c_reset(i2c);
+ err = mxs_i2c_reset(i2c);
+ if (err)
+ return err;
adap = i2c-adapter;
strlcpy(adap-name, MXS I2C adapter, sizeof(adap-name));
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] i2c: i2c-mxs: Check the return value from stmp_reset_block()
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com stmp_reset_block() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam fabio.este...@freescale.com Be careful that the mxs_i2c_reset() is called from multiple places in the driver. You should handle all of the calls. Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v2] i2c: i2c-mxs: Check the return value from stmp_reset_block()
From: Fabio Estevam fabio.este...@freescale.com
stmp_reset_block() may fail, so let's check its return value and propagate it in
the case of error.
Signed-off-by: Fabio Estevam fabio.este...@freescale.com
---
Changes since v1:
- Check the return value of all occurences of mxs_i2c_reset()
drivers/i2c/busses/i2c-mxs.c | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/drivers/i2c/busses/i2c-mxs.c b/drivers/i2c/busses/i2c-mxs.c
index df8ff5a..90c052e 100644
--- a/drivers/i2c/busses/i2c-mxs.c
+++ b/drivers/i2c/busses/i2c-mxs.c
@@ -123,9 +123,11 @@ struct mxs_i2c_dev {
booldma_read;
};
-static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
+static int mxs_i2c_reset(struct mxs_i2c_dev *i2c)
{
- stmp_reset_block(i2c-regs);
+ int ret = stmp_reset_block(i2c-regs);
+ if (ret)
+ return ret;
/*
* Configure timing for the I2C block. The I2C TIMING2 register has to
@@ -139,6 +141,8 @@ static void mxs_i2c_reset(struct mxs_i2c_dev *i2c)
writel(0x00300030, i2c-regs + MXS_I2C_TIMING2);
writel(MXS_I2C_IRQ_MASK 8, i2c-regs + MXS_I2C_CTRL1_SET);
+
+ return 0;
}
static void mxs_i2c_dma_finish(struct mxs_i2c_dev *i2c)
@@ -475,7 +479,7 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg,
int stop)
{
struct mxs_i2c_dev *i2c = i2c_get_adapdata(adap);
- int ret;
+ int ret, err;
int flags;
flags = stop ? MXS_I2C_CTRL0_POST_SEND_STOP : 0;
@@ -495,8 +499,11 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg,
i2c-cmd_err = 0;
if (msg-len 8) {
ret = mxs_i2c_pio_setup_xfer(adap, msg, flags);
- if (ret)
- mxs_i2c_reset(i2c);
+ if (ret) {
+ err = mxs_i2c_reset(i2c);
+ if (err)
+ return err;
+ }
} else {
INIT_COMPLETION(i2c-cmd_complete);
ret = mxs_i2c_dma_setup_xfer(adap, msg, flags);
@@ -527,7 +534,10 @@ static int mxs_i2c_xfer_msg(struct i2c_adapter *adap,
struct i2c_msg *msg,
timeout:
dev_dbg(i2c-dev, Timeout!\n);
mxs_i2c_dma_finish(i2c);
- mxs_i2c_reset(i2c);
+ ret = mxs_i2c_reset(i2c);
+ if (ret)
+ return ret;
+
return -ETIMEDOUT;
}
@@ -683,7 +693,9 @@ static int mxs_i2c_probe(struct platform_device *pdev)
platform_set_drvdata(pdev, i2c);
/* Do reset to enforce correct startup after pinmuxing */
- mxs_i2c_reset(i2c);
+ err = mxs_i2c_reset(i2c);
+ if (err)
+ return err;
adap = i2c-adapter;
strlcpy(adap-name, MXS I2C adapter, sizeof(adap-name));
--
1.8.1.2
--
To unsubscribe from this list: send the line unsubscribe linux-i2c in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v2] i2c: i2c-mxs: Check the return value from stmp_reset_block()
Dear Fabio Estevam, From: Fabio Estevam fabio.este...@freescale.com stmp_reset_block() may fail, so let's check its return value and propagate it in the case of error. Signed-off-by: Fabio Estevam fabio.este...@freescale.com --- Changes since v1: - Check the return value of all occurences of mxs_i2c_reset() drivers/i2c/busses/i2c-mxs.c | 26 +++--- 1 file changed, 19 insertions(+), 7 deletions(-) The error handling in mxs_i2c_xfer_msg() is ugly and will need to be reworked, but this is not for this patch. Acked-by: Marek Vasut ma...@denx.de Best regards, Marek Vasut -- To unsubscribe from this list: send the line unsubscribe linux-i2c in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
