lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 3 Dec 2014 23:04:37 +0300
From:	Alexander Kochetkov <al.kochet@...il.com>
To:	balbi@...com
Cc:	Kevin Hilman <khilman@...nel.org>,
	Tony Lindgren <tony@...mide.com>,
	Wolfram Sang <wsa@...-dreams.de>,
	linux-omap <linux-omap@...r.kernel.org>,
	linux-i2c@...r.kernel.org, LKML <linux-kernel@...r.kernel.org>
Subject: Re: Question about patch "i2c: omap: resize fifos before each message"


03 дек. 2014 г., в 22:38, Felipe Balbi <balbi@...com> написал(а):

> then handle slave interrupts :-) But handle them so that it won't race
> with a master transfer request. Moving omap_i2c_xfer() inside the IRQ
> handler isn't the best way to do it, however.

I do that with care :)

Currently, only 'resize fifo' and 'clear fifo' is the one thing what must 
be moved into ISR (I'll check is it possible or late). 
Because I can't ask ISR to generate interrupt to start master transfer.
I thought about that without luck.
I have to write to CON register. I can lock xfer for short time to
check STAT (for AAS) and either write CON or flag to start master after
slave complete.

'clear fifo' must be done in response to NACK. TRM states this[1]"
"TX and RX FIFOs must be cleared (the I2Ci.I2C_BUF[6] TXFIFO_CLR
and I2Ci.I2C_BUF[14] RXFIFO_CLR bits are set to 1)."

'resize fifo' could be avoided at all, but, it so nice feature.

And yes, if we could utilize full fifo to send message, we could set
threshold to message size and get only RRDY at the end.

If message size is greater than fifo size, we want to use double
buffer scheme to minimize ISR latencies.

But now, variable 'fifo_size' is set to half of IP real fifo size.
And for messages with fifo_size/2 ... fifo_size we use drainig
feature (get RDR, XRD). While we could receive only one IRQ.
I'll fix that.

>> And, I'll try to move fifo threshold init code into ISR. Don't see
>> something wrong.
> 
> I wouldn't do that. It's just too late... look, IRQs won't fire until
> I2C_CON is setup to start a transfer (transmit or receive), you *must*
> resize FIFO before starting a transfer otherwise, well, you know...
Looks, like RRDY is fired after simple compare with threshold.
I'll check is this possible (but, that doesn't cover into TRM).
Or may be it is late to change it.

[1] AM-DM37x Multimedia Device Silicon Revision 1.x  - sprugn4r,
     p. 2796, Table 17-9. HS I2C Interrupt Events--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ