Re: [PATCH 2/2] i2c: add driver for Sigma Designs SMP8642 I2C master

2015-11-01 Thread Måns Rullgård 
Wolfram Sang  writes:

> On Sat, Oct 31, 2015 at 05:35:57PM +, Mans Rullgard wrote:
>> This adds a driver for the Sigma Designs SMP8642 built-in I2C master
>> controller.  The hardware is very similar to the I2C controller in the
>> Ralink RT3050 chip with the addition of interrupt generation and an
>> inverted busy/idle status bit.  There are typically two controllers with
>> a shared IRQ.
>> 
>> Signed-off-by: Mans Rullgard 
>
> Thanks for the driver. Same answer as here, though:
>
> http://www.spinics.net/lists/linux-i2c/msg17001.html
>
>> +#define TANGOX_I2C_CONFIG   0x00
>> +#define TANGOX_I2C_CLKDIV   0x04
>> +#define TANGOX_I2C_DEVADDR  0x08
>> +#define TANGOX_I2C_ADDR 0x0c
>> +#define TANGOX_I2C_DATAOUT  0x10
>> +#define TANGOX_I2C_DATAIN   0x14
>> +#define TANGOX_I2C_STATUS   0x18
>> +#define TANGOX_I2C_STARTXFER0x1c
>> +#define TANGOX_I2C_BYTECNT  0x20
>> +#define TANGOX_I2C_INT_EN   0x24
>> +#define TANGOX_I2C_INT_STAT 0x28
>
> The register set looks like the one from i2c-xlr.c, only that they are
> 32 bit apart instead of 8. Can you check if you can reuse that driver?

It does look very similar indeed.  I thought I'd checked for an existing
driver, but apparently I missed that one.  I'll modify the xlr driver to
handle this hardware as well instead.

-- 
Måns Rullgård
m...@mansr.com
--
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: add driver for Sigma Designs SMP8642 I2C master

2015-11-01 Thread Wolfram Sang 
On Sat, Oct 31, 2015 at 05:35:57PM +, Mans Rullgard wrote:
> This adds a driver for the Sigma Designs SMP8642 built-in I2C master
> controller.  The hardware is very similar to the I2C controller in the
> Ralink RT3050 chip with the addition of interrupt generation and an
> inverted busy/idle status bit.  There are typically two controllers with
> a shared IRQ.
> 
> Signed-off-by: Mans Rullgard 

Thanks for the driver. Same answer as here, though:

http://www.spinics.net/lists/linux-i2c/msg17001.html

> +#define TANGOX_I2C_CONFIG0x00
> +#define TANGOX_I2C_CLKDIV0x04
> +#define TANGOX_I2C_DEVADDR   0x08
> +#define TANGOX_I2C_ADDR  0x0c
> +#define TANGOX_I2C_DATAOUT   0x10
> +#define TANGOX_I2C_DATAIN0x14
> +#define TANGOX_I2C_STATUS0x18
> +#define TANGOX_I2C_STARTXFER 0x1c
> +#define TANGOX_I2C_BYTECNT   0x20
> +#define TANGOX_I2C_INT_EN0x24
> +#define TANGOX_I2C_INT_STAT  0x28

The register set looks like the one from i2c-xlr.c, only that they are
32 bit apart instead of 8. Can you check if you can reuse that driver?

Thanks,

   Wolfram



signature.asc
Description: Digital signature

Re: [PATCH 0/4] Support multiplexed main SMBus interface on SB800

2015-11-01 Thread fetzerch 

Hi Mika,

On 22.10.2015 13:43, Mika Westerberg wrote:

On Thu, Oct 22, 2015 at 01:03:25PM +0200, Wolfram Sang wrote:

Please review and let me know required changes in order to get this upstream
finally.

Eddi, Thomas, it would be great if you could verify the changes on your
machines.

Yes, additional tests are always good for a patch series

Asking the Intel guys for help, I have not much expierence with x86
platforms... Mika, Jarkko, Andy any chance to help?

Unfortunately I don't have hardware this old to test on :-/

And visual review? (That's what I need to do mostly, too)

Sure.

I don't have a copy of these patches but I went ahead and looked them up
from archives. Christian can you Cc me on next iteration?

Mostly they look good to me. Few comments though.

Patch 2/4: should we remove adapter in reverse order?

Patch 3/4: some stylistic issues, like:
- ERROR label should not be in capital letters actually it is
  not needed at all if you do unlock and return -EBUSY if
  request_region() fails.
- Block comment style

In addition I'm not sure if requesting io region for each transfer is
good idea. Can't we just request it once for this driver and handle the
necessary serialization using the mutex?
Thanks for the review. I've just sent patchset v2 where I tried to 
incorporate the requested changes.

I'm not sure though what you mean with 'block comment style'.
I've tried to apply the same style that is used throughout the file.

Thanks,
Christian

--
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: exynos5: register driver early in subsys initcall to avoid probe defer

2015-11-01 Thread Wolfram Sang 
On Fri, Oct 30, 2015 at 03:23:28PM +0100, Marek Szyprowski wrote:
> i2c bus drivers should be registered earlier than typical drivers to let
> important i2c devices (like PMICs/regulators) get registered early
> enough to avoid probe defer of all devices in typical embedded system.
> 
> Signed-off-by: Marek Szyprowski 

I don't accept such patches anymore. Some more background:

http://www.spinics.net/lists/linux-i2c/msg13102.html
http://www.spinics.net/lists/linux-i2c/msg16644.html



signature.asc
Description: Digital signature

Re: [PATCH 2/2] i2c: add driver for Sigma Designs SMP8642 I2C master

2015-11-01 Thread Wolfram Sang 

> > The register set looks like the one from i2c-xlr.c, only that they are
> > 32 bit apart instead of 8. Can you check if you can reuse that driver?
> 
> It does look very similar indeed.  I thought I'd checked for an existing
> driver, but apparently I missed that one.  I'll modify the xlr driver to
> handle this hardware as well instead.

Thanks, much appreciated!



signature.asc
Description: Digital signature

[PATCH v2 4/5] i2c-piix4: Add support for multiplexed main adapter in SB800

2015-11-01 Thread Christian Fetzer 
The SB800 chipset supports a multiplexed main SMBus controller with
four ports. The multiplexed ports share the same SMBus address and
register set. The port is selected by bits 2:1 of the smb_en register
(0x2C).

Only one port can be active at any point in time therefore a mutex is
needed in order to synchronize access.

Tested on HP ProLiant MicroServer G7 N54L (where this patch adds
support to access sensor data from the w83795adg).

Cc: Thomas Brandon 
Cc: Eddi De Pieri 
Signed-off-by: Christian Fetzer 
---
 drivers/i2c/busses/i2c-piix4.c | 102 +++--
 1 file changed, 97 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index d866b58..54f8af5 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -23,6 +23,9 @@
 
Note: we assume there can only be one device, with one or more
SMBus interfaces.
+   The device can register multiple i2c_adapters (up to PIIX4_MAX_ADAPTERS).
+   For devices supporting multiple ports the i2c_adapter should provide
+   an i2c_algorithm to access them.
 */
 
 #include 
@@ -37,6 +40,7 @@
 #include 
 #include 
 #include 
+#include 
 
 
 /* PIIX4 SMBus address offsets */
@@ -126,10 +130,12 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 };
 
 /* SB800 globals */
+DEFINE_MUTEX(piix4_mutex_sb800);
 static unsigned short piix4_smb_idx_sb800;
 
 struct i2c_piix4_adapdata {
unsigned short smba;
+   unsigned short port;
 };
 
 static int piix4_setup(struct pci_dev *PIIX4_dev,
@@ -309,6 +315,8 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
dev_dbg(_dev->dev, "Using SMI# for SMBus\n");
 
+   mutex_init(_mutex_sb800);
+
dev_info(_dev->dev,
 "SMBus Host Controller at 0x%x, revision %d\n",
 piix4_smba, i2ccfg >> 4);
@@ -523,6 +531,42 @@ static s32 piix4_access(struct i2c_adapter * adap, u16 
addr,
return 0;
 }
 
+/* Handles access to multiple SMBus ports on the SB800.
+ * The port is selected by bits 2:1 of the smb_en register (0x2C).
+ * Returns negative errno on error.
+ *
+ * Note: The selected port must be returned to the initial selection to avoid
+ * problems on certain systems.
+ */
+static s32 piix4_access_sb800(struct i2c_adapter *adap, u16 addr,
+unsigned short flags, char read_write,
+u8 command, int size, union i2c_smbus_data *data)
+{
+   struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
+   u8 smba_en_lo, smb_en = 0x2c;
+   u8 port;
+   int retval;
+
+   mutex_lock(_mutex_sb800);
+
+   outb_p(smb_en, piix4_smb_idx_sb800);
+   smba_en_lo = inb_p(piix4_smb_idx_sb800 + 1);
+
+   port = adapdata->port;
+   if ((smba_en_lo & 6) != (port << 1))
+   outb_p((smba_en_lo & ~6) | (port << 1),
+  piix4_smb_idx_sb800 + 1);
+
+   retval = piix4_access(adap, addr, flags, read_write,
+ command, size, data);
+
+   outb_p(smba_en_lo, piix4_smb_idx_sb800 + 1);
+
+   mutex_unlock(_mutex_sb800);
+
+   return retval;
+}
+
 static u32 piix4_func(struct i2c_adapter *adapter)
 {
return I2C_FUNC_SMBUS_QUICK | I2C_FUNC_SMBUS_BYTE |
@@ -535,6 +579,11 @@ static const struct i2c_algorithm smbus_algorithm = {
.functionality  = piix4_func,
 };
 
+static const struct i2c_algorithm piix4_smbus_algorithm_sb800 = {
+   .smbus_xfer = piix4_access_sb800,
+   .functionality  = piix4_func,
+};
+
 static const struct pci_device_id piix4_ids[] = {
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_3) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82443MX_3) },
@@ -610,6 +659,42 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned 
short smba,
return 0;
 }
 
+static int piix4_add_adapters_sb800(struct pci_dev *dev, unsigned short smba)
+{
+   unsigned short port;
+   int retval;
+   struct i2c_piix4_adapdata *adapdata;
+
+   for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
+   retval = piix4_add_adapter(dev, smba,
+  _main_adapters[port]);
+   if (retval < 0)
+   goto error;
+
+   piix4_main_adapters[port]->algo = _smbus_algorithm_sb800;
+
+   adapdata = i2c_get_adapdata(piix4_main_adapters[port]);
+   adapdata->port = port;
+   }
+
+   return retval;
+
+error:
+   dev_err(>dev, "Error setting up SB800 adapters. "
+   "Unregistering all adapters!\n");
+   for (port--; port >= 0; port--) {
+   adapdata = i2c_get_adapdata(piix4_main_adapters[port]);
+   if (adapdata->smba) {
+   i2c_del_adapter(piix4_main_adapters[port]);
+   kfree(adapdata);
+

[PATCH v2 0/5] Support multiplexed main SMBus interface on SB80

2015-11-01 Thread Christian Fetzer 
This is an attempt to upstream the patches created by Thomas Brandon and
Eddi De Pieri to support the multiplexed main SMBus interface on the SB800
chipset. (https://www.mail-archive.com/linux-i2c@vger.kernel.org/msg06757.html)

I have mainly rebased the latest patch version and tested the driver on a
HP ProLiant MicroServer G7 N54L (where this patch allows to access sensor data
from a w83795adg).

The patched driver is running stable on the machine, given that ic2_piix4 is
loaded before jc42 and w83795. If jc42 is loaded before i2c_piix4 calling
sensors triggers some errors:
ERROR: Can't get value of subfeature temp1_min_alarm: Can't read

While the kernel log shows:
i2c i2c-1: Transaction (pre): CNT=0c, CMD=05, ADD=31, DAT0=03, DAT1=c0
i2c i2c-1: Error: no response!
i2c i2c-1: Transaction (post): CNT=0c, CMD=05, ADD=31, DAT0=ff, DAT1=ff
Unfortunately I don't know how to tackle this specific issue.

Please review and let me know required changes in order to get this upstream
finally.

Eddi, Thomas, it would be great if you could verify the changes on your
machines.

Regards,
Christian

v2:
- Incorporated changes requested by Mika
- remove adapter in reverse order
- ERROR label
- request base address index region only once

Christian Fetzer (5):
  i2c-piix4: Optionally release smba in piix4_adap_remove
  i2c-piix4: Convert piix4_main_adapter to array
  i2c-piix4: Request base address index region once for SB800
  i2c-piix4: Add support for multiplexed main adapter in SB800
  i2c-piix4: Add adapter port name support for SB800 chipset

 drivers/i2c/busses/i2c-piix4.c | 172 ++---
 1 file changed, 144 insertions(+), 28 deletions(-)

-- 
1.9.1

--
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 3/5] i2c-piix4: Request base address index region once for SB800

2015-11-01 Thread Christian Fetzer 
Request the SMBus base address index region once in piix4_probe. This
is particularly useful when using the multiplexed adapter in SB800 as
it avoids requesting and releasing the region on every transfer.

Signed-off-by: Christian Fetzer 
---
 drivers/i2c/busses/i2c-piix4.c | 35 ++-
 1 file changed, 22 insertions(+), 13 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 35eeb0d..d866b58 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -125,6 +125,9 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
{ },
 };
 
+/* SB800 globals */
+static unsigned short piix4_smb_idx_sb800;
+
 struct i2c_piix4_adapdata {
unsigned short smba;
 };
@@ -232,7 +235,6 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
 const struct pci_device_id *id, u8 aux)
 {
unsigned short piix4_smba;
-   unsigned short smba_idx = 0xcd6;
u8 smba_en_lo, smba_en_hi, smb_en, smb_en_status;
u8 i2ccfg, i2ccfg_offset = 0x10;
 
@@ -254,16 +256,10 @@ static int piix4_setup_sb800(struct pci_dev *PIIX4_dev,
else
smb_en = (aux) ? 0x28 : 0x2c;
 
-   if (!request_region(smba_idx, 2, "smba_idx")) {
-   dev_err(_dev->dev, "SMBus base address index region "
-   "0x%x already in use!\n", smba_idx);
-   return -EBUSY;
-   }
-   outb_p(smb_en, smba_idx);
-   smba_en_lo = inb_p(smba_idx + 1);
-   outb_p(smb_en + 1, smba_idx);
-   smba_en_hi = inb_p(smba_idx + 1);
-   release_region(smba_idx, 2);
+   outb_p(smb_en, piix4_smb_idx_sb800);
+   smba_en_lo = inb_p(piix4_smb_idx_sb800 + 1);
+   outb_p(smb_en + 1, piix4_smb_idx_sb800);
+   smba_en_hi = inb_p(piix4_smb_idx_sb800 + 1);
 
if (!smb_en) {
smb_en_status = smba_en_lo & 0x10;
@@ -616,16 +612,26 @@ static int piix4_add_adapter(struct pci_dev *dev, 
unsigned short smba,
 
 static int piix4_probe(struct pci_dev *dev, const struct pci_device_id *id)
 {
+   unsigned short smba_idx = 0xcd6;
int retval;
 
if ((dev->vendor == PCI_VENDOR_ID_ATI &&
 dev->device == PCI_DEVICE_ID_ATI_SBX00_SMBUS &&
 dev->revision >= 0x40) ||
-   dev->vendor == PCI_VENDOR_ID_AMD)
+   dev->vendor == PCI_VENDOR_ID_AMD) {
+
+   if (!request_region(smba_idx, 2, "smba_idx")) {
+   dev_err(>dev, "SMBus base address index region "
+   "0x%x already in use!\n", smba_idx);
+   return -EBUSY;
+   }
+   piix4_smb_idx_sb800 = smba_idx;
+
/* base address location etc changed in SB800 */
retval = piix4_setup_sb800(dev, id, 0);
-   else
+   } else {
retval = piix4_setup(dev, id);
+   }
 
/* If no main SMBus found, give up */
if (retval < 0)
@@ -692,6 +698,9 @@ static void piix4_remove(struct pci_dev *dev)
piix4_adap_remove(piix4_aux_adapter, 1);
piix4_aux_adapter = NULL;
}
+
+   if (piix4_smb_idx_sb800)
+   release_region(piix4_smb_idx_sb800, 2);
 }
 
 static struct pci_driver piix4_driver = {
-- 
1.9.1

--
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 2/5] i2c-piix4: Convert piix4_main_adapter to array

2015-11-01 Thread Christian Fetzer 
The SB800 chipset supports a multiplexed main SMBus controller with
four ports. Therefore the static variable piix4_main_adapter is
converted into a piix4_main_adapters array that can hold one
i2c_adapter for each multiplexed port.

The auxiliary adapter remains unchanged since it represents the second
(not multiplexed) SMBus controller on the SB800 chipset.

Signed-off-by: Christian Fetzer 
---
 drivers/i2c/busses/i2c-piix4.c | 18 +-
 1 file changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 97d2165..35eeb0d 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -75,6 +75,9 @@
 #define PIIX4_WORD_DATA0x0C
 #define PIIX4_BLOCK_DATA   0x14
 
+/* Multi-port constants */
+#define PIIX4_MAX_ADAPTERS 4
+
 /* insmod parameters */
 
 /* If force is set to anything different from 0, we forcibly enable the
@@ -561,7 +564,7 @@ static const struct pci_device_id piix4_ids[] = {
 
 MODULE_DEVICE_TABLE (pci, piix4_ids);
 
-static struct i2c_adapter *piix4_main_adapter;
+static struct i2c_adapter *piix4_main_adapters[PIIX4_MAX_ADAPTERS];
 static struct i2c_adapter *piix4_aux_adapter;
 
 static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
@@ -629,7 +632,7 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return retval;
 
/* Try to register main SMBus adapter, give up if we can't */
-   retval = piix4_add_adapter(dev, retval, _main_adapter);
+   retval = piix4_add_adapter(dev, retval, _main_adapters[0]);
if (retval < 0)
return retval;
 
@@ -675,9 +678,14 @@ static void piix4_adap_remove(struct i2c_adapter *adap, 
int free_smba)
 
 static void piix4_remove(struct pci_dev *dev)
 {
-   if (piix4_main_adapter) {
-   piix4_adap_remove(piix4_main_adapter, 1);
-   piix4_main_adapter = NULL;
+   int port;
+
+   for (port = PIIX4_MAX_ADAPTERS - 1; port >= 0; port--) {
+   if (piix4_main_adapters[port]) {
+   piix4_adap_remove(piix4_main_adapters[port],
+ port == 0);
+   piix4_main_adapters[port] = NULL;
+   }
}
 
if (piix4_aux_adapter) {
-- 
1.9.1

--
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/5] i2c-piix4: Optionally release smba in piix4_adap_remove

2015-11-01 Thread Christian Fetzer 
This is in preparation to support the multiplexed SMBus main controller
in the SB800 chipset where the controller address is shared among
the four multiplexed ports. As such the address region should be
only freed for the first multiplexed adapter to avoid double free
warnings.

Signed-off-by: Christian Fetzer 
---
 drivers/i2c/busses/i2c-piix4.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 630bce6..97d2165 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -660,13 +660,14 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return 0;
 }
 
-static void piix4_adap_remove(struct i2c_adapter *adap)
+static void piix4_adap_remove(struct i2c_adapter *adap, int free_smba)
 {
struct i2c_piix4_adapdata *adapdata = i2c_get_adapdata(adap);
 
if (adapdata->smba) {
i2c_del_adapter(adap);
-   release_region(adapdata->smba, SMBIOSIZE);
+   if (free_smba)
+   release_region(adapdata->smba, SMBIOSIZE);
kfree(adapdata);
kfree(adap);
}
@@ -675,12 +676,12 @@ static void piix4_adap_remove(struct i2c_adapter *adap)
 static void piix4_remove(struct pci_dev *dev)
 {
if (piix4_main_adapter) {
-   piix4_adap_remove(piix4_main_adapter);
+   piix4_adap_remove(piix4_main_adapter, 1);
piix4_main_adapter = NULL;
}
 
if (piix4_aux_adapter) {
-   piix4_adap_remove(piix4_aux_adapter);
+   piix4_adap_remove(piix4_aux_adapter, 1);
piix4_aux_adapter = NULL;
}
 }
-- 
1.9.1

--
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 5/5] i2c-piix4: Add adapter port name support for SB800 chipset

2015-11-01 Thread Christian Fetzer 
This patch adds support for port names for the SB800 chipset.
Since the chipset supports a multiplexed main SMBus controller, adding
the channel name to the adapter name is necessary to differentiate the
ports better (for example in sensors output).

Signed-off-by: Christian Fetzer 
---
 drivers/i2c/busses/i2c-piix4.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)

diff --git a/drivers/i2c/busses/i2c-piix4.c b/drivers/i2c/busses/i2c-piix4.c
index 54f8af5..18ea5d7 100644
--- a/drivers/i2c/busses/i2c-piix4.c
+++ b/drivers/i2c/busses/i2c-piix4.c
@@ -132,6 +132,10 @@ static const struct dmi_system_id piix4_dmi_ibm[] = {
 /* SB800 globals */
 DEFINE_MUTEX(piix4_mutex_sb800);
 static unsigned short piix4_smb_idx_sb800;
+static const char *piix4_main_port_names_sb800[4] = {
+   "SDA0", "SDA2", "SDA3", "SDA4"
+};
+static const char *piix4_aux_port_name_sb800 = "SDA1";
 
 struct i2c_piix4_adapdata {
unsigned short smba;
@@ -613,7 +617,7 @@ static struct i2c_adapter 
*piix4_main_adapters[PIIX4_MAX_ADAPTERS];
 static struct i2c_adapter *piix4_aux_adapter;
 
 static int piix4_add_adapter(struct pci_dev *dev, unsigned short smba,
-struct i2c_adapter **padap)
+const char *name, struct i2c_adapter **padap)
 {
struct i2c_adapter *adap;
struct i2c_piix4_adapdata *adapdata;
@@ -642,7 +646,7 @@ static int piix4_add_adapter(struct pci_dev *dev, unsigned 
short smba,
adap->dev.parent = >dev;
 
snprintf(adap->name, sizeof(adap->name),
-   "SMBus PIIX4 adapter at %04x", smba);
+   "SMBus PIIX4 adapter %s at %04x", name, smba);
 
i2c_set_adapdata(adap, adapdata);
 
@@ -667,6 +671,7 @@ static int piix4_add_adapters_sb800(struct pci_dev *dev, 
unsigned short smba)
 
for (port = 0; port < PIIX4_MAX_ADAPTERS; port++) {
retval = piix4_add_adapter(dev, smba,
+  piix4_main_port_names_sb800[port],
   _main_adapters[port]);
if (retval < 0)
goto error;
@@ -726,7 +731,7 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
return retval;
 
/* Try to register main SMBus adapter, give up if we can't */
-   retval = piix4_add_adapter(dev, retval,
+   retval = piix4_add_adapter(dev, retval, "",
   _main_adapters[0]);
}
 
@@ -755,7 +760,8 @@ static int piix4_probe(struct pci_dev *dev, const struct 
pci_device_id *id)
if (retval > 0) {
/* Try to add the aux adapter if it exists,
 * piix4_add_adapter will clean up if this fails */
-   piix4_add_adapter(dev, retval, _aux_adapter);
+   piix4_add_adapter(dev, retval, piix4_aux_port_name_sb800,
+ _aux_adapter);
}
 
return 0;
-- 
1.9.1

--
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

Double commits in i2c/for-next branch?

2015-11-01 Thread Masahiro Yamada 
Hi Wolfram,

I noticed my patch was applied twice in the next branch
with different commit IDs.



[1] commit 6a62974b667f3976ec44e255bed31746cca1ff51
Author: Masahiro Yamada 
Date:   Fri Oct 23 19:52:00 2015 +0900

i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver


[2] commit f496cf367b613c94e40893e07e1b20470deb9363
Author: Masahiro Yamada 
Date:   Fri Oct 23 19:52:00 2015 +0900

i2c: uniphier_f: add UniPhier FIFO-builtin I2C driver



Please let me confirm if I correctly understood
the branch strategy of this subsystem.



[1] was applied to i2c/for-4.4 and then merged
into i2c/for-next.   It is supposed to be pulled
into the mainline in this merge window.


[2] was directly applied to i2c/for-next and
won't be pulled into the mainline.  It will only
remain in linux-next.



Is this correct?





-- 
Best Regards
Masahiro Yamada
--
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 3/3] i2c: xlr: add interrupt support for Sigma Designs chips

2015-11-01 Thread Mans Rullgard 
The Sigma Designs variant of this controller has the ability to generate
interrupts.  This is controlled using two additional registers, oddly
enough overlapping with the defined but unused HDSTATIM.

This patch adds support for using this feature instead of busy-looping
if an IRQ is specified.

Signed-off-by: Mans Rullgard 
---
 drivers/i2c/busses/i2c-xlr.c | 119 +++
 1 file changed, 119 insertions(+)

diff --git a/drivers/i2c/busses/i2c-xlr.c b/drivers/i2c/busses/i2c-xlr.c
index c1afc3e..dd48c1e 100644
--- a/drivers/i2c/busses/i2c-xlr.c
+++ b/drivers/i2c/busses/i2c-xlr.c
@@ -19,6 +19,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* XLR I2C REGISTERS */
 #define XLR_I2C_CFG0x00
@@ -32,6 +34,10 @@
 #define XLR_I2C_BYTECNT0x08
 #define XLR_I2C_HDSTATIM   0x09
 
+/* Sigma Designs additional registers */
+#define XLR_I2C_INT_EN 0x09
+#define XLR_I2C_INT_STAT   0x0a
+
 /* XLR I2C REGISTERS FLAGS */
 #define XLR_I2C_BUS_BUSY   0x01
 #define XLR_I2C_SDOEMPTY   0x02
@@ -65,7 +71,10 @@ static inline u32 xlr_i2c_rdreg(u32 __iomem *base, unsigned 
int reg)
return __raw_readl(base + reg);
 }
 
+#define XLR_I2C_FLAG_IRQ   1
+
 struct xlr_i2c_config {
+   u32 flags;  /* optional feature support */
u32 status_busy;/* value of STATUS[0] when busy */
u32 cfg_extra;  /* extra CFG bits to set */
 };
@@ -73,7 +82,11 @@ struct xlr_i2c_config {
 struct xlr_i2c_private {
struct i2c_adapter adap;
u32 __iomem *iobase;
+   int irq;
+   int pos;
+   struct i2c_msg *msg;
const struct xlr_i2c_config *cfg;
+   wait_queue_head_t wait;
struct clk *clk;
 };
 
@@ -82,6 +95,74 @@ static int xlr_i2c_busy(struct xlr_i2c_private *priv, u32 
status)
return (status & XLR_I2C_BUS_BUSY) == priv->cfg->status_busy;
 }
 
+static int xlr_i2c_idle(struct xlr_i2c_private *priv)
+{
+   return !xlr_i2c_busy(priv, xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS));
+}
+
+static int xlr_i2c_wait(struct xlr_i2c_private *priv, unsigned long timeout)
+{
+   int status;
+   int t;
+
+   t = wait_event_timeout(priv->wait, xlr_i2c_idle(priv),
+   msecs_to_jiffies(timeout));
+   if (!t)
+   return -ETIMEDOUT;
+
+   status = xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS);
+
+   return status & XLR_I2C_ACK_ERR ? -EIO : 0;
+}
+
+static void xlr_i2c_tx_irq(struct xlr_i2c_private *priv, u32 status)
+{
+   struct i2c_msg *msg = priv->msg;
+
+   if (status & XLR_I2C_SDOEMPTY)
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_DATAOUT,
+   msg->buf[priv->pos++]);
+}
+
+static void xlr_i2c_rx_irq(struct xlr_i2c_private *priv, u32 status)
+{
+   struct i2c_msg *msg = priv->msg;
+
+   if (status & XLR_I2C_RXRDY)
+   msg->buf[priv->pos++] =
+   xlr_i2c_rdreg(priv->iobase, XLR_I2C_DATAIN);
+}
+
+static irqreturn_t xlr_i2c_irq(int irq, void *dev_id)
+{
+   struct xlr_i2c_private *priv = dev_id;
+   struct i2c_msg *msg = priv->msg;
+   u32 int_stat, status;
+
+   int_stat = xlr_i2c_rdreg(priv->iobase, XLR_I2C_INT_STAT);
+   if (!int_stat)
+   return IRQ_NONE;
+
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_INT_STAT, int_stat);
+
+   if (!msg)
+   return IRQ_HANDLED;
+
+   status = xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS);
+
+   if (priv->pos < msg->len) {
+   if (msg->flags & I2C_M_RD)
+   xlr_i2c_rx_irq(priv, status);
+   else
+   xlr_i2c_tx_irq(priv, status);
+   }
+
+   if (!xlr_i2c_busy(priv, status))
+   wake_up(>wait);
+
+   return IRQ_HANDLED;
+}
+
 static int xlr_i2c_tx(struct xlr_i2c_private *priv,  u16 len,
u8 *buf, u16 addr)
 {
@@ -119,10 +200,15 @@ static int xlr_i2c_tx(struct xlr_i2c_private *priv,  u16 
len,
pos = 2;
}
 
+   priv->pos = pos;
+
 retry:
/* retry can only happen on the first byte */
xlr_i2c_wreg(priv->iobase, XLR_I2C_STARTXFR, xfer);
 
+   if (priv->irq > 0)
+   return xlr_i2c_wait(priv, XLR_I2C_TIMEOUT * len);
+
while (!timedout) {
checktime = jiffies;
i2c_status = xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS);
@@ -170,6 +256,8 @@ static int xlr_i2c_rx(struct xlr_i2c_private *priv, u16 
len, u8 *buf, u16 addr)
xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
 
+   priv->pos = 0;
+
timeout = msecs_to_jiffies(XLR_I2C_TIMEOUT);
stoptime = jiffies + timeout;
timedout = 0;
@@ -177,6 +265,9 @@ static int xlr_i2c_rx(struct xlr_i2c_private *priv, u16 
len, u8 *buf, u16 addr)
 retry:
xlr_i2c_wreg(priv->iobase, XLR_I2C_STARTXFR,

[PATCH 2/3] i2c: xlr: fix extra read/write at end of rx transfer

2015-11-01 Thread Mans Rullgard 
The BYTECNT register holds the transfer size minus one.  Setting it
to the correct value requires a dummy read/write only for zero-length
transfers as it is impossible to request one from the hardware.  If a
zero-length transfer is requested, changing the length to 1 and setting
"buf" to a dummy location allows making the main loops less convoluted.

In other words, this patch makes the driver transfer the number of bytes
requested unless this is zero, which is not supported by the hardware,
in which case one byte is transferred instead.

Signed-off-by: Mans Rullgard 
---
 drivers/i2c/busses/i2c-xlr.c | 51 +++-
 1 file changed, 31 insertions(+), 20 deletions(-)

diff --git a/drivers/i2c/busses/i2c-xlr.c b/drivers/i2c/busses/i2c-xlr.c
index 10fb916..c1afc3e 100644
--- a/drivers/i2c/busses/i2c-xlr.c
+++ b/drivers/i2c/busses/i2c-xlr.c
@@ -90,37 +90,45 @@ static int xlr_i2c_tx(struct xlr_i2c_private *priv,  u16 
len,
u32 i2c_status;
int pos, timedout;
u8 offset, byte;
+   u32 xfer;
+
+   if (!len) {
+   byte = 0;
+   buf = 
+   len = 1;
+   }
 
offset = buf[0];
xlr_i2c_wreg(priv->iobase, XLR_I2C_ADDR, offset);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG,
XLR_I2C_CFG_ADDR | priv->cfg->cfg_extra);
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
 
timeout = msecs_to_jiffies(XLR_I2C_TIMEOUT);
stoptime = jiffies + timeout;
timedout = 0;
-   pos = 1;
-retry:
+
if (len == 1) {
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_STARTXFR,
-   XLR_I2C_STARTXFR_ND);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
+   xfer = XLR_I2C_STARTXFR_ND;
+   pos = 1;
} else {
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_DATAOUT, buf[pos]);
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_STARTXFR,
-   XLR_I2C_STARTXFR_WR);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 2);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_DATAOUT, buf[1]);
+   xfer = XLR_I2C_STARTXFR_WR;
+   pos = 2;
}
 
+retry:
+   /* retry can only happen on the first byte */
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_STARTXFR, xfer);
+
while (!timedout) {
checktime = jiffies;
i2c_status = xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS);
 
-   if (i2c_status & XLR_I2C_SDOEMPTY) {
-   pos++;
-   /* need to do a empty dataout after the last byte */
-   byte = (pos < len) ? buf[pos] : 0;
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_DATAOUT, byte);
+   if ((i2c_status & XLR_I2C_SDOEMPTY) && pos < len) {
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_DATAOUT, buf[pos++]);
 
/* reset timeout on successful xmit */
stoptime = jiffies + timeout;
@@ -151,9 +159,15 @@ static int xlr_i2c_rx(struct xlr_i2c_private *priv, u16 
len, u8 *buf, u16 addr)
int nbytes, timedout;
u8 byte;
 
+   if (!len) {
+   byte = 0;
+   buf = 
+   len = 1;
+   }
+
xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG,
XLR_I2C_CFG_NOADDR | priv->cfg->cfg_extra);
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
 
timeout = msecs_to_jiffies(XLR_I2C_TIMEOUT);
@@ -167,14 +181,11 @@ retry:
checktime = jiffies;
i2c_status = xlr_i2c_rdreg(priv->iobase, XLR_I2C_STATUS);
if (i2c_status & XLR_I2C_RXRDY) {
-   if (nbytes > len)
+   if (nbytes >= len)
return -EIO;/* should not happen */
 
-   /* we need to do a dummy datain when nbytes == len */
-   byte = xlr_i2c_rdreg(priv->iobase, XLR_I2C_DATAIN);
-   if (nbytes < len)
-   buf[nbytes] = byte;
-   nbytes++;
+   buf[nbytes++] =
+   xlr_i2c_rdreg(priv->iobase, XLR_I2C_DATAIN);
 
/* reset timeout on successful read */
stoptime = jiffies + timeout;
-- 
2.6.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

[PATCH 1/3] i2c: xlr: add support for Sigma Designs controller variant

2015-11-01 Thread Mans Rullgard 
Sigma Designs chips use a variant of this controller with the following
differences:

- The BUSY bit in the STATUS register is inverted
- Bit 8 of the CONFIG register must be set
- The controller can generate interrupts

This patch adds support for the first two of these.  It also calculates
and sets the correct clock divisor if a clk is provided.  The bus
frequency is optionally speficied in the device tree node.

Signed-off-by: Mans Rullgard 
---
 drivers/i2c/busses/Kconfig   |  6 ++--
 drivers/i2c/busses/i2c-xlr.c | 81 +---
 2 files changed, 80 insertions(+), 7 deletions(-)

diff --git a/drivers/i2c/busses/Kconfig b/drivers/i2c/busses/Kconfig
index f764e3a..fdedf59 100644
--- a/drivers/i2c/busses/Kconfig
+++ b/drivers/i2c/busses/Kconfig
@@ -944,11 +944,11 @@ config I2C_XILINX
  will be called xilinx_i2c.
 
 config I2C_XLR
-   tristate "XLR I2C support"
-   depends on CPU_XLR
+   tristate "Netlogic XLR and Sigma Designs I2C support"
+   depends on CPU_XLR || ARCH_TANGOX
help
  This driver enables support for the on-chip I2C interface of
- the Netlogic XLR/XLS MIPS processors.
+ the Netlogic XLR/XLS MIPS processors and Sigma Designs SOCs.
 
  This driver can also be built as a module.  If so, the module
  will be called i2c-xlr.
diff --git a/drivers/i2c/busses/i2c-xlr.c b/drivers/i2c/busses/i2c-xlr.c
index 8b36bcf..10fb916 100644
--- a/drivers/i2c/busses/i2c-xlr.c
+++ b/drivers/i2c/busses/i2c-xlr.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 /* XLR I2C REGISTERS */
 #define XLR_I2C_CFG0x00
@@ -63,11 +65,23 @@ static inline u32 xlr_i2c_rdreg(u32 __iomem *base, unsigned 
int reg)
return __raw_readl(base + reg);
 }
 
+struct xlr_i2c_config {
+   u32 status_busy;/* value of STATUS[0] when busy */
+   u32 cfg_extra;  /* extra CFG bits to set */
+};
+
 struct xlr_i2c_private {
struct i2c_adapter adap;
u32 __iomem *iobase;
+   const struct xlr_i2c_config *cfg;
+   struct clk *clk;
 };
 
+static int xlr_i2c_busy(struct xlr_i2c_private *priv, u32 status)
+{
+   return (status & XLR_I2C_BUS_BUSY) == priv->cfg->status_busy;
+}
+
 static int xlr_i2c_tx(struct xlr_i2c_private *priv,  u16 len,
u8 *buf, u16 addr)
 {
@@ -80,7 +94,8 @@ static int xlr_i2c_tx(struct xlr_i2c_private *priv,  u16 len,
offset = buf[0];
xlr_i2c_wreg(priv->iobase, XLR_I2C_ADDR, offset);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG, XLR_I2C_CFG_ADDR);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG,
+   XLR_I2C_CFG_ADDR | priv->cfg->cfg_extra);
xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len - 1);
 
timeout = msecs_to_jiffies(XLR_I2C_TIMEOUT);
@@ -121,7 +136,7 @@ retry:
if (i2c_status & XLR_I2C_ACK_ERR)
return -EIO;
 
-   if ((i2c_status & XLR_I2C_BUS_BUSY) == 0 && pos >= len)
+   if (!xlr_i2c_busy(priv, i2c_status) && pos >= len)
return 0;
}
dev_err(>dev, "I2C transmit timeout\n");
@@ -136,7 +151,8 @@ static int xlr_i2c_rx(struct xlr_i2c_private *priv, u16 
len, u8 *buf, u16 addr)
int nbytes, timedout;
u8 byte;
 
-   xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG, XLR_I2C_CFG_NOADDR);
+   xlr_i2c_wreg(priv->iobase, XLR_I2C_CFG,
+   XLR_I2C_CFG_NOADDR | priv->cfg->cfg_extra);
xlr_i2c_wreg(priv->iobase, XLR_I2C_BYTECNT, len);
xlr_i2c_wreg(priv->iobase, XLR_I2C_DEVADDR, addr);
 
@@ -174,7 +190,7 @@ retry:
if (i2c_status & XLR_I2C_ACK_ERR)
return -EIO;
 
-   if ((i2c_status & XLR_I2C_BUS_BUSY) == 0)
+   if (!xlr_i2c_busy(priv, i2c_status))
return 0;
}
 
@@ -190,6 +206,10 @@ static int xlr_i2c_xfer(struct i2c_adapter *adap,
int ret = 0;
struct xlr_i2c_private *priv = i2c_get_adapdata(adap);
 
+   ret = clk_enable(priv->clk);
+   if (ret)
+   return ret;
+
for (i = 0; ret == 0 && i < num; i++) {
msg = [i];
if (msg->flags & I2C_M_RD)
@@ -200,6 +220,8 @@ static int xlr_i2c_xfer(struct i2c_adapter *adap,
msg->addr);
}
 
+   clk_disable(priv->clk);
+
return (ret != 0) ? ret : num;
 }
 
@@ -214,22 +236,70 @@ static struct i2c_algorithm xlr_i2c_algo = {
.functionality  = xlr_func,
 };
 
+static const struct xlr_i2c_config xlr_i2c_config_default = {
+   .status_busy= XLR_I2C_BUS_BUSY,
+   .cfg_extra  = 0,
+};
+
+static const struct xlr_i2c_config xlr_i2c_config_tangox = {
+   .status_busy= 0,
+   .cfg_extra  = 1 << 8,
+};
+
+static const struct of_device_id xlr_i2c_dt_ids[] = {
+   {
+

Re: [PATCH] i2c: designware: Don't mask TX_EMPTY if write is in progress

2015-11-01 Thread Jisheng Zhang 
Dear Jarkko,

On Fri, 30 Oct 2015 14:03:53 +0200
Jarkko Nikula wrote:

> Hi
> 
> On 10/30/2015 09:37 AM, Jisheng Zhang wrote:
> > Currently when i2c_msg index search is completed, TX_EMPTY interrupt
> > will be masked. But if the size of i2c_msg data is longer than the size
> > of the tx buffer, we still need TX_EMPTY interrupt, otherwise we will
> > get "controller timed out" error.
> >
> > This patch fixes this issue by only masking TX_EMPTY if i2c_msg index
> > search is completed and write is not in progress.
> >
> > Signed-off-by: Jisheng Zhang 
> > ---
> >   drivers/i2c/busses/i2c-designware-core.c | 7 ---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/i2c/busses/i2c-designware-core.c 
> > b/drivers/i2c/busses/i2c-designware-core.c
> > index 7441cdc..a2eb212 100644
> > --- a/drivers/i2c/busses/i2c-designware-core.c
> > +++ b/drivers/i2c/busses/i2c-designware-core.c
> > @@ -542,10 +542,11 @@ i2c_dw_xfer_msg(struct dw_i2c_dev *dev)
> > }
> >
> > /*
> > -* If i2c_msg index search is completed, we don't need TX_EMPTY
> > -* interrupt any more.
> > +* If i2c_msg index search is completed and writing is not in progress,
> > +* we don't need TX_EMPTY interrupt any more.
> >  */
> > -   if (dev->msg_write_idx == dev->msgs_num)
> > +   if (dev->msg_write_idx == dev->msgs_num &&
> > +   !(dev->status & STATUS_WRITE_IN_PROGRESS))
> > intr_mask &= ~DW_IC_INTR_TX_EMPTY;
> >  
> This looks a possible scenario here. What I'm wondering how is the 
> transfer ending and what condition in i2c_dw_isr() causes the complete() 
> call?
> 
> Assuming we break the for loop in i2c_dw_xfer_msg() with buf_len > 0 and 
> dev->msg_write_idx == dev->msgs_num how we get back inside the for loop 
> for writing the remaining bytes and stop command?

This is a good question. After more consideration, I think the following
condition can't exist:

  (msg_write_idx == dev->msgs_num) && (dev->status & STATUS_WRITE_IN_PROGRESS)

so this patch isn't necessary.

Thanks for your review,
Jisheng

--
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 1/2] i2c: imx: Improve message log when DMA is not used

2015-11-01 Thread Fabio Estevam 
From: Fabio Estevam 

When DMA cannot be used, it is better to state that the I2C controller
will operate in PIO mode.

Signed-off-by: Fabio Estevam 
---
 drivers/i2c/busses/i2c-imx.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 785aa67..1e522c3 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -339,7 +339,7 @@ fail_tx:
dma_release_channel(dma->chan_tx);
 fail_al:
devm_kfree(dev, dma);
-   dev_info(dev, "can't use DMA\n");
+   dev_info(dev, "can't use DMA, using PIO instead.\n");
 }
 
 static void i2c_imx_dma_callback(void *arg)
-- 
1.9.1

--
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 2/2] i2c: imx: Remove unneeded comments

2015-11-01 Thread Fabio Estevam 
From: Fabio Estevam 

These multi-lines comments do not follow the standard kernel coding
style. In fact, they are not useful comments, so get rid of them.

Signed-off-by: Fabio Estevam 
---
 drivers/i2c/busses/i2c-imx.c | 12 
 1 file changed, 12 deletions(-)

diff --git a/drivers/i2c/busses/i2c-imx.c b/drivers/i2c/busses/i2c-imx.c
index 1e522c3..696c920 100644
--- a/drivers/i2c/busses/i2c-imx.c
+++ b/drivers/i2c/busses/i2c-imx.c
@@ -29,9 +29,6 @@
  *
  */
 
-/** Includes 
***
-***/
-
 #include 
 #include 
 #include 
@@ -54,9 +51,6 @@
 #include 
 #include 
 
-/** Defines 

-***/
-
 /* This will be the driver name the kernel reports */
 #define DRIVER_NAME "imx-i2c"
 
@@ -118,9 +112,6 @@
 #define I2CR_IEN_OPCODE_0  0x0
 #define I2CR_IEN_OPCODE_1  I2CR_IEN
 
-/** Variables 
**
-***/
-
 /*
  * sorted list of clock divider, register value pairs
  * taken from table 26-5, p.26-9, Freescale i.MX
@@ -409,9 +400,6 @@ static void i2c_imx_dma_free(struct imx_i2c_struct *i2c_imx)
dma->chan_using = NULL;
 }
 
-/** Functions for IMX I2C adapter driver 
***
-***/
-
 static int i2c_imx_bus_busy(struct imx_i2c_struct *i2c_imx, int for_busy)
 {
unsigned long orig_jiffies = jiffies;
-- 
1.9.1

--
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: [MinnowBoard] Linux x86 I2C device probing with ACPI

2015-11-01 Thread Christophe Ricard 

Hi Mika,

Sorry for the delay.
After forcing _STA method to return 0xF and moving NFC1 node into 
Scope(I2C7) node the probing went through.


Thanks !
Christophe

On 22/10/2015 10:18, Mika Westerberg wrote:

On Wed, Oct 21, 2015 at 09:19:24PM +0200, Christophe Ricard wrote:

From: Christophe Ricard 

Hi,

I am trying to probe slave i2c devices with ACPI running Ubuntu 15.04 and 
kernel 4.3
without success so far.

I've followed guidance here:
http://elinux.org/Minnowboard:MinnowMaxLinuxKernel 


but i found no i2c device are probed at boot.

By probed do you mean that they are not listed under
/sys/bus/i2c/devices/ or that a driver is not probed against an existing
device?


For example, one default device available in the acpi table is never detected: 
RTEK node (with ID 10EC5640).

If the device _STA() method returns 0 then we do not enumerate it. You
can check this by looking for the corresponding ACPI device node. For
example I have here I2C connected touch screen:

# cat /sys/bus/acpi/devices/NTRG0001\:00/status
15

15 means that it is there (among other things). Also the device is then
available as I2C device here:

# ls -1 /sys/bus/i2c/devices/
i2c-0
i2c-1
i2c-2
i2c-NTRG0001:00


When adding my own device to I2C7, my device is never detected as well .

For example the complete modified I2C7 is at the end of the message.

I am compiling the kernel with options:
CONFIG_ACPI_CUSTOM_DSDT_FILE="dsdt.hex"
CONFIG_ACPI_CUSTOM_DSDT=y
CONFIG_ACPI_INITRD_TABLE_OVERRIDE=y

You don't need the last one.


I am running on Minnowboard firmware 0.83 with default options.

Best Regards
Christophe

 Device (I2C7)
 {
 Name (_ADR, Zero)  // _ADR: Address
 Name (_HID, "80860F41" /* Intel Baytrail I2C Host Controller */)  
// _HID: Hardware ID
 Name (_CID, "80860F41" /* Intel Baytrail I2C Host Controller */)  
// _CID: Compatible ID
 Name (_DDN, "Intel(R) I2C Controller #7 - 80860F47") // _DDN: DOS 
Device Name
 Name (_UID, 0x07)  // _UID: Unique ID
 Name (_DEP, Package (One)  // _DEP: Dependencies
 {
 PEPD
 })
 Name (RBUF, ResourceTemplate ()
 {
 Memory32Fixed (ReadWrite,
 0x, // Address Base
 0x1000, // Address Length
 _Y1F)
 Interrupt (ResourceConsumer, Level, ActiveLow, Exclusive, ,, )
 {
 0x0026,
 }
 FixedDMA (0x001C, 0x0004, Width32bit, )
 FixedDMA (0x001D, 0x0005, Width32bit, )
 })
 Method (SSCN, 0, NotSerialized)
 {
 Name (PKG, Package (0x03)
 {
 0x0200,
 0x0200,
 0x06
 })
 Return (PKG) /* \_SB_.I2C7.SSCN.PKG_ */
 }

 Method (FMCN, 0, NotSerialized)
 {
 Name (PKG, Package (0x03)
 {
 0x55,
 0x99,
 0x06
 })
 Return (PKG) /* \_SB_.I2C7.FMCN.PKG_ */
 }

 Method (FPCN, 0, NotSerialized)
 {
 Name (PKG, Package (0x03)
 {
 0x1B,
 0x3A,
 0x06
 })
 Return (PKG) /* \_SB_.I2C7.FPCN.PKG_ */
 }

 Method (_HRV, 0, NotSerialized)  // _HRV: Hardware Revision
 {
 Return (SOCS) /* \SOCS */
 }

 Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
 {
 CreateDWordField (RBUF, \_SB.I2C7._Y1F._BAS, B0BA)  // _BAS: 
Base Address
 CreateDWordField (RBUF, \_SB.I2C7._Y1F._LEN, B0LN)  // _LEN: 
Length
 B0BA = I70A /* \I70A */
 B0LN = I70L /* \I70L */
 Return (RBUF) /* \_SB_.I2C7.RBUF */
 }

 Method (_STA, 0, NotSerialized)  // _STA: Status
 {
 If ((PCIM == One))
 {
 Return (Zero)
 }

 If (((I70A == Zero) || (L27D == One)))
 {
 Return (Zero)
 }

 Return (0x0F)
 }

 Method (_PS3, 0, NotSerialized)  // _PS3: Power State 3
 {
 PSAT |= 0x03
 PSAT |= Zero
 }

 Method (_PS0, 0, NotSerialized)  // _PS0: Power State 0
 {
 PSAT &= 0xFFFC
 PSAT |= Zero
 }

 OperationRegion (KEYS, SystemMemory, I71A, 0x0100)

Re: Double commits in i2c/for-next branch?

2015-11-01 Thread Masahiro Yamada 
Hi Wolfram,

2015-11-02 14:50 GMT+09:00 Wolfram Sang :
>
>> [1] was applied to i2c/for-4.4 and then merged
>> into i2c/for-next.   It is supposed to be pulled
>> into the mainline in this merge window.
>
> Yes.
>
>> [2] was directly applied to i2c/for-next and
>> won't be pulled into the mainline.  It will only
>> remain in linux-next.
>
> Unfortunately, I had to rebase for-4.4 this time :( I try to avoid it,
> but sometimes this happens. When I merge that rebased version into
> for-next, double commits happen. Linus will get the pull request for
> for-4.4 only.
>
> Hope that helps,

Understood.

Thanks!




-- 
Best Regards
Masahiro Yamada
--
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 0/2] Mediatek I2C driver fixup

2015-11-01 Thread Eddie Huang 
On Tue, 2015-10-27 at 16:59 +0800, Liguo Zhang wrote:
> This series contain two patches, first is to optimize Mediatek I2C driver to 
> use WRRD
> if hardware support auto restart. Because auto restart will issue auto restart
> interrupt, change to use WRRD can reduce interrupt latency. The second is to 
> fix
> multi transfer error in high speed mode. If hardware support auto restart, 
> need driver
> to send master code first.

Please fix checkpatch warning in 2/2, then you get my reviewed-by for
this series:

Reviewed-by:Eddie Huang 

> 
> Liguo Zhang (2):
>   i2c: mediatek: add i2c first write then read optimization
>   i2c: mediatek: fix i2c multi transfer issue in high speed mode
> 
>  drivers/i2c/busses/i2c-mt65xx.c | 77 
> +
>  1 file changed, 71 insertions(+), 6 deletions(-)



--
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: Double commits in i2c/for-next branch?

2015-11-01 Thread Wolfram Sang 

> [1] was applied to i2c/for-4.4 and then merged
> into i2c/for-next.   It is supposed to be pulled
> into the mainline in this merge window.

Yes.

> [2] was directly applied to i2c/for-next and
> won't be pulled into the mainline.  It will only
> remain in linux-next.

Unfortunately, I had to rebase for-4.4 this time :( I try to avoid it,
but sometimes this happens. When I merge that rebased version into
for-next, double commits happen. Linus will get the pull request for
for-4.4 only.

Hope that helps,

   Wolfram


signature.asc
Description: PGP signature