Lan Tianyu | 16 Apr 15:24 2014
Picon

[PATCH 0/9] I2C ACPI operation region handler support

ACPI 5.0 spec(5.5.2.4.5) defines GenericSerialBus(i2c, spi, uart) operation
region. It allows ACPI aml code able to access such kind of devices to
implement some ACPI standard method.

On the Asus T100TA, Bios use GenericSerialBus operation region to access
i2c device to get battery info. So battery function depends on the I2C
operation region support. Here is the bug link.
https://bugzilla.kernel.org/show_bug.cgi?id=69011

This patchset is to add I2C ACPI operation region handler support.

[PATCH 1/9] ACPICA: Executer: Fix buffer allocation issue for
[PATCH 2/9] ACPICA: Export acpi_buffer_to_resource symbol
[PATCH 3/9] ACPI: Add acpi_bus_attach_private_data() to facilitate to
[PATCH 4/9] ACPI/Thermal: Use acpi_bus_attach_private_data() to
[PATCH 5/9] I2C: Add smbus quick read/write helper function
[PATCH 6/9] I2C: Add smbus word/block process call helper function
[PATCH 7/9] I2C/ACPI: Add i2c ACPI operation region support
[PATCH 8/9] I2C/ACPI: Move ACPI related code to i2c-acpi.c
[PATCH 9/9] I2C/ACPI: Add CONFIG_I2C_ACPI config
isabelle | 15 Apr 21:47 2014
Picon

spende /Donation

Hallo
Wenn ich diese Nachricht zu senden wollte, ist dies nicht einfach Zufall. Dies ist, weil Ihre e-Mail vom
elektronischen Roboter gesichert meine WX.7AR BW ausgewählt wurde.
Zunächst möchte ich mich für dieses Eindringen in Ihr Leben zu entschuldigen, obwohl ich zugeben, dass
es mir sehr wichtig. Ich bin Isabelle Vasudev. Ich leide an Krebs im Hals seit nun mehr als 3 Jahre und eine
halbe und es leider, mein Arzt hat gerade informiert mich, dass ich bin voller unheilbar und, dass meine
Tage, wegen meinen etwas gezählt sind abgebaut Zustand. Ich bin eine Witwe und ich habe keine Kind, das
ich beginne zu bedauern.
In der Tat ist der Grund, warum ich Sie kontaktieren bin, möchte ich einen Teil von meinem Grundstück zu
spenden, weil ich niemand, wer die Erben konnte. Ich habe fast mein ganzes Zeug, darunter ein Unternehmen
der Export von Holz, Gummi und Stahl-Industrie in Afrika, wo ich wohne nun mehr 10 Jahren, verkauft. Ein
großer Teil der Gelder gesammelt wurde mit unterschiedlichen Verbänden humanitären Charakter
überall in der Welt, aber besonders hier in Afrika bezahlt.
Im Hinblick auf den Rest der Summe genau in Höhe von 750.000, 00euros (sieben hundert und fünfzig tausend
Euro) auf eine gesperrte Mitarbeiter-Account, meine letzte wünschen würde Sie es spenden, so dass Sie
in Ihrer Branche und vor allem den humanitären investieren können. Ich bin ganz bewusst was ich zu tun
beabsichtigen, und ich denke, trotz der Tatsache, die wir nicht wissen, werdet ihr diese Summe gut
nutzen. Ich bitte Sie, bitte dieses Erbe zu akzeptieren, ohne jedoch Fragen Sie alles, was in
zurückgeben wenn es nicht immer denken, gutes zu tun, um dich herum, was ich nicht getan habe, in meiner Existenz.
Das heißt, wird auf einer verantwortlichen Person und besonders gutem Glauben fallen zu lassen
beruhigt, ich möchte bitten, dass Sie bitte mich bei den meisten schnell kontaktieren, um weitere
Erklärung über die Gründe für meine Geste und den Verlauf der Dinge zu geben. Bitte kontaktieren Sie
mich so bald wie möglich, wenn Sie mein Angebot akzeptieren.
Gott möge mit dir sein!
Ich fordere Sie auf, mich über meine persönliche e-Mail-Adresse zu kontaktieren:
Isabelle.claude654@...
Der Frieden und Barmherzigkeit Gottes möge mit dir sein.
Mrs Isabelle

(Continue reading)

Doug Anderson | 12 Apr 00:19 2014

[PATCH] i2c: s3c2410: resume race fix

From: Olof Johansson <olof@...>

Don't unmark the device as suspended until after it's been re-setup.

The main race would be w.r.t. an i2c driver that gets resumed at the same
time (asyncronously), that is allowed to do a transfer since suspended
is set to 0 before reinit, but really should have seen the -EIO return
instead.

Signed-off-by: Olof Johansson <olof@...>
Signed-off-by: Doug Anderson <dianders@...>
---
 drivers/i2c/busses/i2c-s3c2410.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-s3c2410.c b/drivers/i2c/busses/i2c-s3c2410.c
index ae44910..bb3a996 100644
--- a/drivers/i2c/busses/i2c-s3c2410.c
+++ b/drivers/i2c/busses/i2c-s3c2410.c
 <at>  <at>  -1276,10 +1276,10  <at>  <at>  static int s3c24xx_i2c_resume(struct device *dev)
 	struct platform_device *pdev = to_platform_device(dev);
 	struct s3c24xx_i2c *i2c = platform_get_drvdata(pdev);

-	i2c->suspended = 0;
 	clk_prepare_enable(i2c->clk);
 	s3c24xx_i2c_init(i2c);
 	clk_disable_unprepare(i2c->clk);
+	i2c->suspended = 0;

 	return 0;
(Continue reading)

Richard Leitner | 11 Apr 13:44 2014
Picon

[PATCH v2] i2c: busses: ali1563: fix checkpatch.pl issues

Fixed most checkpatch.pl issues

Signed-off-by: Richard Leitner <me@...>
Reviewed-by: Jean Delvare <jdelvare@...>
---
v2: applied changes recommended by Jean Delvare
---
 drivers/i2c/busses/i2c-ali1563.c | 82 ++++++++++++++++++++++------------------
 1 file changed, 45 insertions(+), 37 deletions(-)

diff --git a/drivers/i2c/busses/i2c-ali1563.c b/drivers/i2c/busses/i2c-ali1563.c
index 98a1c97..15517d7 100644
--- a/drivers/i2c/busses/i2c-ali1563.c
+++ b/drivers/i2c/busses/i2c-ali1563.c
 <at>  <at>  -63,7 +63,7  <at>  <at> 
 static struct pci_driver ali1563_pci_driver;
 static unsigned short ali1563_smba;

-static int ali1563_transaction(struct i2c_adapter * a, int size)
+static int ali1563_transaction(struct i2c_adapter *a, int size)
 {
 	u32 data;
 	int timeout;
 <at>  <at>  -78,7 +78,7  <at>  <at>  static int ali1563_transaction(struct i2c_adapter * a, int size)
 	data = inb_p(SMB_HST_STS);
 	if (data & HST_STS_BAD) {
 		dev_err(&a->dev, "ali1563: Trying to reset busy device\n");
-		outb_p(data | HST_STS_BAD,SMB_HST_STS);
+		outb_p(data | HST_STS_BAD, SMB_HST_STS);
 		data = inb_p(SMB_HST_STS);
(Continue reading)

Srinivas Pandruvada | 11 Apr 06:15 2014
Picon

[PATCH 1/2] i2c/ACPI: Support for multiple serial bus addresses

ACPI specification allows multiple i2c addresses defined under one
ACPI device object. These addresses are defined using _CRS method.
The current implementation will pickup the last entry in _CRS, and
create an i2C device, ignoring all other previous entries for addresses.

The ACPI specification does not define, whether these addresses for one
i2c device or for multiple i2c devices, which are defined under the same
ACPI device object. We need some appoach where i2c clients can enumerate
on each of the i2C address and/or have access to those extra addresses.

This change addresses both cases:
- Create a new i2c device for each i2c address
- Allow each i2 client to get addresses of all other devices under
the same ACPI device object (companions or siblings)

Example 1:
Here in the following example, there are two i2C address in _CRS.
They belong to two different physical chipsets, with two different i2c
address but part of a module.
Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
{
        Name (RBUF, ResourceTemplate ()
        {
		I2cSerialBus (0x0068, ControllerInitiated, 0x00061A80,
			AddressingMode7Bit, "\\_SB.I2C5",
			0x00, ResourceConsumer, ,
		)
		I2cSerialBus (0x000C, ControllerInitiated, 0x00061A80,
			AddressingMode7Bit, "\\_SB.I2C5",
			0x00, ResourceConsumer, ,
(Continue reading)

Kuninori Morimoto | 11 Apr 03:20 2014
Picon

[PATCH] I2C: rcar: add R-Car Gen2 and r8a7791 support for DT

From: Kuninori Morimoto <kuninori.morimoto.gx@...>

Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@...>
---
 drivers/i2c/busses/i2c-rcar.c |    2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/i2c/busses/i2c-rcar.c b/drivers/i2c/busses/i2c-rcar.c
index 0282d4d..e7c798e 100644
--- a/drivers/i2c/busses/i2c-rcar.c
+++ b/drivers/i2c/busses/i2c-rcar.c
 <at>  <at>  -635,9 +635,11  <at>  <at>  static const struct i2c_algorithm rcar_i2c_algo = {

 static const struct of_device_id rcar_i2c_dt_ids[] = {
 	{ .compatible = "renesas,i2c-rcar", .data = (void *)I2C_RCAR_GEN1 },
+	{ .compatible = "renesas,i2c-rcar-gen2", .data = (void *)I2C_RCAR_GEN2 },
 	{ .compatible = "renesas,i2c-r8a7778", .data = (void *)I2C_RCAR_GEN1 },
 	{ .compatible = "renesas,i2c-r8a7779", .data = (void *)I2C_RCAR_GEN1 },
 	{ .compatible = "renesas,i2c-r8a7790", .data = (void *)I2C_RCAR_GEN2 },
+	{ .compatible = "renesas,i2c-r8a7791", .data = (void *)I2C_RCAR_GEN2 },
 	{},
 };
 MODULE_DEVICE_TABLE(of, rcar_i2c_dt_ids);
--

-- 
1.7.9.5

Du, Wenkai | 11 Apr 01:03 2014
Picon

[PATCH V2] i2c-designware: Mask all interrupts during i2c controller enable

Hi all,

Updated problem descriptions from Mika's feedback and new test data: 

There have been "i2c_designware 80860F41:00: controller timed out" errors
on a number of Baytrail platforms. The issue is caused by incorrect value in
Interrupt Mask Register (DW_IC_INTR_MASK)  when i2c core is being enabled. 
This causes call to __i2c_dw_enable() to immediately start the transfer which
leads to timeout. There are 3 failure modes observed:

1. Failure in S0 to S3 resume path

The default value after reset for DW_IC_INTR_MASK is 0x8ff. When we start 
the first transaction after resuming from system sleep, TX_EMPTY interrupt 
is already unmasked because of the hardware default.

2. Failure in normal operational path

This failure happens rarely and is hard to reproduce. Debug trace showed that
DW_IC_INTR_MASK had value of 0x254 when failure occurred, which meant 
TX_EMPTY was unmasked.

2. Failure in S3 to S0 suspend path

This failure also happens rarely and is hard to reproduce. Adding debug trace
that read DW_IC_INTR_MASK made this failure not reproducible. But from ISR 
call trace we could conclude TX_EMPTY was unmasked when problem occurred.

The patch masks all interrupts before the controller is enabled to resolve the
faulty DW_IC_INTR_MASK conditions.
(Continue reading)

Ulf Hansson | 10 Apr 16:19 2014

[PATCH] i2c: nomadik: Don't use IS_ERR for devm_ioremap

devm_ioremap() returns NULL on error, not an error.

Cc: Alessandro Rubini <rubini@...>
Cc: Linus Walleij <linus.walleij@...>
Signed-off-by: Ulf Hansson <ulf.hansson@...>
---
 drivers/i2c/busses/i2c-nomadik.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-nomadik.c b/drivers/i2c/busses/i2c-nomadik.c
index 28cbe1b..32c85e9 100644
--- a/drivers/i2c/busses/i2c-nomadik.c
+++ b/drivers/i2c/busses/i2c-nomadik.c
 <at>  <at>  -999,7 +999,7  <at>  <at>  static int nmk_i2c_probe(struct amba_device *adev, const struct amba_id *id)

 	dev->virtbase = devm_ioremap(&adev->dev, adev->res.start,
 				resource_size(&adev->res));
-	if (IS_ERR(dev->virtbase)) {
+	if (!dev->virtbase) {
 		ret = -ENOMEM;
 		goto err_no_mem;
 	}
--

-- 
1.7.9.5

Ulf Hansson | 10 Apr 15:59 2014

[PATCH] i2c: nomadik: Fixup system suspend

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 tranfer to
return it's runtime PM resources, there are no guarantees this will
actually mean the device will inactivated. The reason is that the PM
core will prevent runtime suspend during system suspend, and thus when
a transfer occurs during the early phases of system suspend the device
will be kept active after the transfer.

To handle both issues above, use pm_runtime_force_suspend|resume() from
the system suspend|resume callbacks.

Cc: Alessandro Rubini <rubini@...>
Cc: Linus Walleij <linus.walleij@...>
Cc: Wolfram Sang <wsa@...>
Signed-off-by: Ulf Hansson <ulf.hansson@...>
---

Do note, this patch were sent during the previous kernel release cycle, as
a part of another patchset on the PM core. Back then, it provided proof of
concept, for the new runtime PM helper functions:
pm_runtime_force_suspend|resume().

---
 drivers/i2c/busses/i2c-nomadik.c |   14 +++++++-------
(Continue reading)

Prarit Bhargava | 9 Apr 18:22 2014
Picon

[PATCH RFC] i2c algo, Add i2c-algo-i801 driver [v1]

RFC and a work in progress ... I need to go through and do a bunch of error
condition checking, more testing, etc.  I'm just throwing this out there to see
if anyone has any major concerns about doing something like this.

TODO:

- decipher error returns from ACPI AML operations (and implement those too)
- additional error checking from i2c and acpi function calls (this code is
not robust enough)
- testing

P.

----8<----

Some ACPI tables on new systems implement an SBUS device in ACPI.  This results
in a conflict with the ACPI tables and the i2c-i801 driver over the address
space.  As a result the i2c-i801 driver will not load.  To workaround this, we
have users use the kernel parameter "acpi_enforce_resources=lax".  This,
isn't a good solution as I've seen other conflicts on some systems that are
also overriden.  I thought about implementing an i2c-core kernel parameter and
a wrapper function for acpi_check_resource_conflict() but that seems rather
clunky and doesn't resolve the issue of the shared resource between the ACPI
and the device.

There isn't any documentaton on Intel's website about the SBUS device but from
reading the acpidump it looks like the operations are straightforward.

SSXB
     transmit one byte
(Continue reading)

Sourav Poddar | 9 Apr 12:22 2014
Picon

[PATCH] i2c: omap: Disable default probing of i2c devices for omap i2c.

I2c core supports defualt probing functionality for devices not registered through
dt/board files. If there are any client driver registered, i2c core will try to
check if there is any device present corresponding to the address supplied by
the client driver. If the device is actually present and not registered, core
will register it, else the device default probe will fail and we get a omap i2c controller
specific timeout messages.
For example, Using multi_v7_config on omap5-uevm, CONFIG_SENSORS_LM90 and CONFIG_ICS932S401
is the driver which is enabled and gets registered. I2c core tries to find a valid
corresponding device on each of the address supplied by registered driver,
but could not find anyone. Hence, keep dumping the controller timeout speciic message.

The patch tends to disable class based instantiation, default probing will not be attempted
by the i2c-core for omap i2c. Device will always get registered through device tree(dt case)
and board files(for non dt cases).

Tested i2c enumeration and data transfer(using i2c utilities) with linux-next master
on the following boards using omap2plus_defconfig:
* Omap3 beagle-Xm (for dt and non dt case)
* omap4 panda
* omap5-uevm
* Dra7xx
* Beaglebone white
* Beaglebone black
* am335x-evm
* AM43xx epos evm

Tested i2c enumeration with linux-next master(except omap5)
on the following boards using multi_v7_defconfig:
* Omap3 beagle-Xm (for dt and non dt case)
* omap4 panda
(Continue reading)


Gmane