Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Ken Xue
On Tue, 2015-12-15 at 16:59 +0200, Mika Westerberg wrote: > On Tue, Dec 15, 2015 at 08:52:19AM -0600, Suravee Suthikulpanit wrote: > > > > > > On 12/15/2015 07:27 AM, Mika Westerberg wrote: > > >On Mon, Dec 14, 2015 at 06:53:25PM -0600, Suravee Suthikulanit wrote: > > >>>I'm not sure if this has

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Mika Westerberg
On Wed, Dec 23, 2015 at 05:34:01PM +0800, Ken Xue wrote: > 1) Regarding > https://msdn.microsoft.com/en-us/library/windows/hardware/dn919852(v=vs.85).aspx > , Window I2C driver should pass MITT test. There are 5 I2C devices > connect to one I2C bus for test. And those devices defined different >

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Ken Xue
On Wed, 2015-12-23 at 11:52 +0200, Mika Westerberg wrote: > On Wed, Dec 23, 2015 at 05:34:01PM +0800, Ken Xue wrote: > > 1) Regarding > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn919852(v=vs.85).aspx > > , Window I2C driver should pass MITT test. There are 5 I2C devices > >

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Mika Westerberg
On Wed, Dec 23, 2015 at 10:02:04AM +, Zheng, Ivan wrote: > Why/how can Linux driver make use of such non-ACPI defined methods? What do you mean exactly? I added support for these (well, SSCN and FMCN) because I found out that some vendors include such methods with their BIOS implementation.

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Mika Westerberg
On Wed, Dec 23, 2015 at 05:59:49PM +0800, Ken Xue wrote: > On Wed, 2015-12-23 at 11:52 +0200, Mika Westerberg wrote: > > On Wed, Dec 23, 2015 at 05:34:01PM +0800, Ken Xue wrote: > > > 1) Regarding > > > https://msdn.microsoft.com/en-us/library/windows/hardware/dn919852(v=vs.85).aspx > > > , Window

RE: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Zheng, Ivan
Why/how can Linux driver make use of such non-ACPI defined methods? Thanks, Ivan -Original Message- From: Mika Westerberg [mailto:mika.westerb...@linux.intel.com] Sent: Wednesday, December 23, 2015 17:53 To: Xue, Ken Cc: w...@the-dreams.de; Suthikulpanit, Suravee; Loc Ho;

Re: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Mika Westerberg
On Wed, Dec 23, 2015 at 11:24:44AM +, Zheng, Ivan wrote: > I'm a BIOS engineer and my point is that such non-ACPI defined methods > rely on BIOS implementation, so how the generic I2C driver works on a > platform without such methods? Should the vendor implement their own > driver in such

RE: [PATCH v2 0/2] i2c:dw: Add APM X-Gene ACPI I2C device support

2015-12-23 Thread Zheng, Ivan
Thanks Mika for the background. I'm a BIOS engineer and my point is that such non-ACPI defined methods rely on BIOS implementation, so how the generic I2C driver works on a platform without such methods? Should the vendor implement their own driver in such case? I think Windows driver use

[PATCH 2/3] i2c: rcar: remove macros dealing with flags

2015-12-23 Thread Wolfram Sang
From: Wolfram Sang These macros don't really hide complexity, but C idioms. Removing them makes the code easier to read IMO and make a planned extension easier. Acked-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang

[PATCH 1/3] i2c: document binding for multi-master case

2015-12-23 Thread Wolfram Sang
From: Wolfram Sang We need this binding because some I2C master drivers will need to adapt their PM settings for the arbitration circuitry. Acked-by: Geert Uytterhoeven Acked-by: Rob Herring Signed-off-by: Wolfram

[PATCH 0/3] i2c: rcar: adapt PM usage to multi master case

2015-12-23 Thread Wolfram Sang
If we are in a multi-master scenario, we need to block runtime PM so the arbitration circuit stays awake. So, we define a new binding and adapt the i2c-rcar driver to have an example implementation. Changes since RFC: * added acks from Rob and Geert (thanks!) * use of_property_read_bool() now

[PATCH 3/3] i2c: rcar: disable PM in multi-master mode

2015-12-23 Thread Wolfram Sang
From: Wolfram Sang In multi master mode, the IP core needs to be always active for arbitration reasons. Get the config from DT and set up PM depending on the config. Acked-by: Geert Uytterhoeven Signed-off-by: Wolfram Sang

[PATCH 1/2] i2c: always enable RuntimePM for the adapter device

2015-12-23 Thread Wolfram Sang
From: Wolfram Sang The adapter device is a logical device. Because of that, it already uses pm_runtime_no_callbacks() in the core. To ensure proper propagation from the children (i2c devices) to the parent of the adapter (the HW device), make sure RuntimePM is

[PATCH 0/2] i2c: proper RuntimePM for the adapter device

2015-12-23 Thread Wolfram Sang
RuntimePM for the logical adapter device should be handled in a central place by the core, and not by drivers. This series does exactly that. This is the first step of harmonizing RuntimePM handling in I2C. Wolfram Sang (2): i2c: always enable RuntimePM for the adapter device i2c: s3c2410:

[PATCH 2/2] i2c: s3c2410: remove superfluous runtime PM calls

2015-12-23 Thread Wolfram Sang
From: Wolfram Sang RuntimePM of the adapter device is now taken care of by the core. So, we can remove these calls. Signed-off-by: Wolfram Sang --- drivers/i2c/busses/i2c-s3c2410.c | 6 -- 1 file changed, 6 deletions(-)

[PATCH] DT: i2c: Add Freescale MPL3115 to trivial devices list

2015-12-23 Thread Akshay Bhat
This adds devicetree documentation for the bindings of mpl3115 driver. Signed-off-by: Akshay Bhat --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/i2c/trivial-devices.txt

Re: [PATCH v3] i2c: designware: Do not require clock when SSCN and FFCN are provided

2015-12-23 Thread Andy Shevchenko
On Tue, 2015-12-22 at 15:35 -0600, Suravee Suthikulpanit wrote: > The current driver uses input clock source frequency to calculate > values for [SS|FS]_[HC|LC] registers. However, when booting ACPI, we > do not > currently have a good way to provide the frequency information. > Instead, we can

[PATCH] DT: i2c: Add Epson RX8010 to list of trivial devices

2015-12-23 Thread Akshay Bhat
This adds devicetree documentation for the bindings of rtc-rx8010 driver. Signed-off-by: Akshay Bhat --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 1 + 1 file changed, 1 insertion(+) diff --git

[PATCH] DT: i2c: Update vendor prefix for 24c00

2015-12-23 Thread Akshay Bhat
"at" is not a valid vendor prefix, correcting the same to "atmel" Signed-off-by: Akshay Bhat --- Documentation/devicetree/bindings/i2c/trivial-devices.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH] i2c: designware: retry transfer on transient failure

2015-12-23 Thread Baruch Siach
Set the i2c_adapter retries field to a sensible value. This allows the i2c core to retry master_xfer() when it returns -EAGAIN. Currently the i2c-designware driver returns -EAGAIN only on Tx arbitration failure (DW_IC_TX_ARB_LOST). Reported-by: Rolland Chau Signed-off-by:

Re: [PATCH] i2c: designware: retry transfer on transient failure

2015-12-23 Thread Andy Shevchenko
On Wed, 2015-12-23 at 18:43 +0200, Baruch Siach wrote: > Set the i2c_adapter retries field to a sensible value. This allows > the i2c core > to retry master_xfer() when it returns -EAGAIN. Currently the i2c- > designware > driver returns -EAGAIN only on Tx arbitration failure >

Re: [PATCH 0/2] i2c: proper RuntimePM for the adapter device

2015-12-23 Thread Shubhrajyoti Datta
On Wed, Dec 23, 2015 at 10:49 PM, Wolfram Sang wrote: > RuntimePM for the logical adapter device should be handled in a central place > by the core, and not by drivers. This series does exactly that. This is good idea. > > This is the first step of harmonizing RuntimePM

Re: designware i2c bus driver

2015-12-23 Thread Baruch Siach
Hi Rolland, On Wed, Dec 23, 2015 at 05:12:47PM +0800, Rolland Chau wrote: > 2015-12-23 15:45 GMT+08:00 Baruch Siach : > > On Wed, Dec 23, 2015 at 02:56:20PM +0800, Rolland Chau wrote: > > > I found in i2c-designware-platdrv.c , the i2c retry time is not set, > > > and the

Re: [PATCH v2] i2c: designware: Do not require clock when SSCN and FFCN are provided

2015-12-23 Thread Mika Westerberg
On Tue, Dec 22, 2015 at 02:51:13PM -0600, Suravee Suthikulanit wrote: > So, at this point, I can re-submit the V3 and combine these changes, and we > both can sign-off. How does that sound? Sounds good to me :) -- To unsubscribe from this list: send the line "unsubscribe linux-i2c" in the body of