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
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
>
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
> >
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.
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
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;
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
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
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
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
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
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
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
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:
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(-)
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
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
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
"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
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:
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
>
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
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
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
24 matches
Mail list logo