linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver
       [not found] ` <D99582E5322435468A77E74BB0039E7B1D22784CF0-6hi2BFpdtA3X4XV0xjfKZxOngtiEHj0sqGK+G5UkneY@public.gmane.org>
@ 2012-04-26 11:01   ` Nikolaus Voss
       [not found]     ` <D99582E5322435468A77E74BB0039E7B1D22784E8B@SRV02.hamburg.garz-fricke.de>
  0 siblings, 1 reply; 4+ messages in thread
From: Nikolaus Voss @ 2012-04-26 11:01 UTC (permalink / raw)
  To: Carsten Behling
  Cc: Marc-Oliver Westerburg,
	linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
	linux-kernel-u79uwXL29TY76Z2rM5mHXA,
	linux-i2c-u79uwXL29TY76Z2rM5mHXA,
	h.feurstein-Re5JQEeQqe8AvxtiuMwx3w, w.sang-bIcnvbaLZ9MEGnE8C9+IrQ

Hi Carsten,

On Wed, 25 Apr 2012, Carsten Behling wrote:
> I cannot find the fix for the RXRDY overrun bug in this patch:

The fix refers to the bug when RXRDY flag was masked out by TXCOMP,
reported by Hubert. I hope this is fixed with v10.

[...]
> here you only report the status flags after a complete transfer, but 
> an overrun can happen after every byte. After reading the status 
> register after an overrun for the next byte this info will be lost !

Right, I didn't consider this. Would you mind to test if the attached 
patch on top of v10 fixes your problem?

Thanks,
Niko

P.S. Are you using a RM9200? Seems that this SOC has some problems...

diff --git a/drivers/i2c/busses/i2c-at91.c b/drivers/i2c/busses/i2c-at91.c
index 97f4365..df0f6ed 100644
--- a/drivers/i2c/busses/i2c-at91.c
+++ b/drivers/i2c/busses/i2c-at91.c
@@ -186,9 +186,11 @@ static irqreturn_t atmel_twi_interrupt(int irq, void *dev_id)
  	else if (irqstatus & AT91_TWI_TXRDY)
  		at91_twi_write_next_byte(dev);

+	/* catch error flags */
+	dev->transfer_status |= status;
+
  	if (irqstatus & AT91_TWI_TXCOMP) {
  		at91_disable_twi_interrupts(dev);
-		dev->transfer_status = status;
  		complete(&dev->cmd_complete);
  	}

@@ -203,6 +205,7 @@ static int at91_do_twi_transfer(struct at91_twi_dev *dev)
  		(dev->msg->flags & I2C_M_RD) ? "read" : "write", dev->buf_len);

  	INIT_COMPLETION(dev->cmd_complete);
+	dev->transfer_status = 0;
  	if (dev->msg->flags & I2C_M_RD) {
  		unsigned start_flags = AT91_TWI_START;

^ permalink raw reply related	[flat|nested] 4+ messages in thread

* RE: [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver
       [not found]     ` <D99582E5322435468A77E74BB0039E7B1D22784E8B@SRV02.hamburg.garz-fricke.de>
@ 2012-04-27  8:04       ` Voss, Nikolaus
  2012-04-27  8:36         ` AW: " Carsten Behling
  0 siblings, 1 reply; 4+ messages in thread
From: Voss, Nikolaus @ 2012-04-27  8:04 UTC (permalink / raw)
  To: 'Carsten Behling'
  Cc: 'devel@ayanes.com', 'Wolfram Sang',
	'linux-kernel@vger.kernel.org',
	'Hubert Feurstein', 'linux-i2c@vger.kernel.org',
	'Marc-Oliver Westerburg',
	'linux-arm-kernel@lists.infradead.org'

Hi Carsten,

Carsten Behling wrote on 2012-04-27:
>>  	INIT_COMPLETION(dev->cmd_complete);
>> +	dev->transfer_status = 0;
>>  	if (dev->msg->flags & I2C_M_RD) {
>>  		unsigned start_flags = AT91_TWI_START;
> 
> this patch will not work, because you reset 'dev->transfer_status'
> before it is evaluated on errors (AT91_TWI_NACK, AT91_TWI_OVRE). 

it should, because transfer_status is updated by the ISR between
wait_for_completion_interruptible_timeout() and the error evaluation.
Please try it out.

> > P.S. Are you using a RM9200? Seems that this SOC has some problems...
> 
> Yes, our ECO920 uses the RM9200, but we support it with an very old kernel
> (2.6.21). I remember there were many problems with I2C.

Ok, but good to hear the driver basically works with the RM9200.

Niko

^ permalink raw reply	[flat|nested] 4+ messages in thread

* AW: [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver
  2012-04-27  8:04       ` Voss, Nikolaus
@ 2012-04-27  8:36         ` Carsten Behling
  2012-05-09 19:07           ` Adrian Yanes
  0 siblings, 1 reply; 4+ messages in thread
From: Carsten Behling @ 2012-04-27  8:36 UTC (permalink / raw)
  To: Voss, Nikolaus
  Cc: 'devel@ayanes.com', 'Wolfram Sang',
	'linux-kernel@vger.kernel.org',
	'Hubert Feurstein', 'linux-i2c@vger.kernel.org',
	Marc-Oliver Westerburg,
	'linux-arm-kernel@lists.infradead.org'

Hi Niko,

you a right. Driver works with that patch.

Mit freundlichen Grüßen / Best regards
Carsten Behling

Development Engineer
Garz & Fricke GmbH
Tempowerkring 2, 21079 Hamburg - Germany
Amtsgericht Hamburg HRB 60514
Geschäftsführer: Manfred Garz, Matthias Fricke
Phone: +49 (0) 40 791 899 - 56
Fax:    +49 40 / 791 899 - 39
www.garz-fricke.com 

 


-----Ursprüngliche Nachricht-----
Von: Voss, Nikolaus [mailto:N.Voss@weinmann.de] 
Gesendet: Freitag, 27. April 2012 10:05
An: Carsten Behling
Cc: Marc-Oliver Westerburg; 'devel@ayanes.com'; 'Wolfram Sang'; 'linux-arm-kernel@lists.infradead.org'; 'linux-kernel@vger.kernel.org'; 'linux-i2c@vger.kernel.org'; 'Hubert Feurstein'
Betreff: RE: [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver

Hi Carsten,

Carsten Behling wrote on 2012-04-27:
>>  	INIT_COMPLETION(dev->cmd_complete);
>> +	dev->transfer_status = 0;
>>  	if (dev->msg->flags & I2C_M_RD) {
>>  		unsigned start_flags = AT91_TWI_START;
> 
> this patch will not work, because you reset 'dev->transfer_status'
> before it is evaluated on errors (AT91_TWI_NACK, AT91_TWI_OVRE). 

it should, because transfer_status is updated by the ISR between
wait_for_completion_interruptible_timeout() and the error evaluation.
Please try it out.

> > P.S. Are you using a RM9200? Seems that this SOC has some problems...
> 
> Yes, our ECO920 uses the RM9200, but we support it with an very old kernel
> (2.6.21). I remember there were many problems with I2C.

Ok, but good to hear the driver basically works with the RM9200.

Niko

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: AW: [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver
  2012-04-27  8:36         ` AW: " Carsten Behling
@ 2012-05-09 19:07           ` Adrian Yanes
  0 siblings, 0 replies; 4+ messages in thread
From: Adrian Yanes @ 2012-05-09 19:07 UTC (permalink / raw)
  To: linux-arm-kernel; +Cc: linux-kernel, linux-i2c

>> Yes, our ECO920 uses the RM9200, but we support it with an very old kernel
>> (2.6.21). I remember there were many problems with I2C.

I really doubt this, as I indicated in a previous email[1], the RM9200
has a hardware "bug". So either you performed the testing with less than
2 bytes of data and in a really low frequency (<50kHz) or we are missing
something.

Can you provide more details about which kind of testing you performed?

Thanks

1 - http://article.gmane.org/gmane.linux.kernel/1287445/match=

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2012-05-09 19:07 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <D99582E5322435468A77E74BB0039E7B1D22784CF0@SRV02.hamburg.garz-fricke.de>
     [not found] ` <D99582E5322435468A77E74BB0039E7B1D22784CF0-6hi2BFpdtA3X4XV0xjfKZxOngtiEHj0sqGK+G5UkneY@public.gmane.org>
2012-04-26 11:01   ` [PATCH v10 3/4] drivers/i2c/busses/i2c-at91.c: add new driver Nikolaus Voss
     [not found]     ` <D99582E5322435468A77E74BB0039E7B1D22784E8B@SRV02.hamburg.garz-fricke.de>
2012-04-27  8:04       ` Voss, Nikolaus
2012-04-27  8:36         ` AW: " Carsten Behling
2012-05-09 19:07           ` Adrian Yanes

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).