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

2015-12-15 Thread Måns Rullgård
Wolfram Sang  writes:

> On Mon, Nov 02, 2015 at 02:03:37AM +, Mans Rullgard wrote:
>> 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.
>
> Uh, this is wrong, zero byte should really not transfer anything. We
> need to fix that and bail out, so probably something like
>
>   if (!len)
>   return -EOPNOTSUPP;

So the existing driver is wrong to allow it.  Makes sense to drop that.

> Also, the xlr_func() should mask out I2C_FUNC_SMBUS_QUICK.

OK.

> Other than that, the patch looks good to me.
>
> Out of curiosity, your first driver had the registers 32bit apart. Now
> you can deal with 8bit. Is this configurable on this SoC?

It's all 32 bits.  The XLR driver uses a u32 * to access the registers.

-- 
Måns Rullgård
--
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 1/3] i2c: xlr: add support for Sigma Designs controller variant

2015-11-21 Thread Måns Rullgård
Mans Rullgard  writes:

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

Any comments on these patches?

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