On Mon, Feb 17, 2014 at 04:24:30PM +0100, Maxime Ripard wrote:
> On Mon, Feb 17, 2014 at 03:26:12PM +0100, Wolfram Sang wrote:
> >
> > > It's been over a month now, and no sign of life from you on this patch
> > > so far... Should I just take this patchset through my tree? :)
> >
> > Nope.
>
> T
On Mon, Feb 17, 2014 at 03:26:12PM +0100, Wolfram Sang wrote:
>
> > It's been over a month now, and no sign of life from you on this patch
> > so far... Should I just take this patchset through my tree? :)
>
> Nope.
Then please review those 40 lines of code.
--
Maxime Ripard, Free Electrons
Em
For !CONFIG_PM_RUNTIME, the device were never put back into active
state while resuming.
For CONFIG_PM_RUNTIME, we blindly trusted the device to be inactive
while we were about to handle it at suspend late, which is just too
optimistic.
Even if the driver uses pm_runtime_put_sync() after each tra
We should never be busy performing transfers at suspend late, thus
there are no reason to check for it.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
drivers/i2c/busses/i2c-nomadik.c | 10 --
1 file changed, 10 deletions(-)
diff --git a/dri
Since the runtime PM state is expected to be active according to the
amba bus, we must align our behaviour while probing to it.
Moreover, this is needed to be able to have the driver fully functional
without depending on CONFIG_RUNTIME_PM.
Since the device is active while a successful probe has b
The amba bus are responsible for pm_runtime_enable|disable, remove the
redundant pm_runtime_disable at driver removal.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
drivers/i2c/busses/i2c-nomadik.c |1 -
1 file changed, 1 deletion(-)
diff --git a
At system suspend_late, runtime PM has been disabled by the PM core
which means we can safely operate on these resources. Consequentially
we no longer have to wait until the noirq phase of the system suspend.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
-
Use devm_* functions to simplify code and error handling.
Cc: Alessandro Rubini
Cc: Linus Walleij
Cc: Wolfram Sang
Signed-off-by: Ulf Hansson
---
drivers/i2c/busses/i2c-nomadik.c | 31 ++-
1 file changed, 10 insertions(+), 21 deletions(-)
diff --git a/drivers/i2
> It's been over a month now, and no sign of life from you on this patch
> so far... Should I just take this patchset through my tree? :)
Nope.
signature.asc
Description: Digital signature
Hi Wolfram,
On Mon, Jan 13, 2014 at 11:34:48AM +0100, Maxime Ripard wrote:
> Hi everyone,
>
> This patchset adds support the A31 i2c controller. This is mostly the
> same controller as the one found in the other Allwinner SoCs, except
> for the interrupts acking.
>
> On the other SoCs using this
From: Wolfram Sang
Signed-off-by: Wolfram Sang
---
drivers/i2c/busses/i2c-rcar.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 0282d4d..cc60bc6 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.
On Mon, Feb 10, 2014 at 11:19:58AM +0100, Uwe Kleine-König wrote:
> This was tested on a EFM32GG-DK3750 devboard that has a temperature
> sensor and an eeprom on its i2c bus.
>
> Signed-off-by: Uwe Kleine-König
ping
Thanks
Uwe
> ---
> Hello,
>
> there are two places marked with a triple-X wher
On 16/02/14 09:46, Wolfram Sang wrote:
On Sun, Jan 26, 2014 at 04:05:34PM +, Ben Dooks wrote:
The i2c-rcar driver currently prints an error message if the master_xfer
callback fails. However if the bus is being probed then lots of NAKs
will be generated, causing the output of a number of err
On Sat, Feb 15, 2014 at 04:27:37PM +0100, Wolfram Sang wrote:
> On Tue, Feb 04, 2014 at 04:31:19PM +0200, Mika Westerberg wrote:
> > Intel Baytrail I2C controllers can be enumerated from PCI as well as from
> > ACPI. In order to support this add the Baytrail PCI IDs to the driver.
> >
> > Signed-o
14 matches
Mail list logo
