On Mon, Dec 10, 2012 at 03:02:28PM +0530, Giridhar Maruthy wrote:

Hi Russel,

Thanks for review and please find my replies below.

On 7 December 2012 18:03, Russell King - ARM Linux
[off-list ref] wrote:

quoted

On Fri, Dec 07, 2012 at 05:33:17PM +0530, Tushar Behera wrote:

quoted

On 12/03/2012 05:46 PM, Giridhar Maruthy wrote:

quoted

This patch adds slave support to i2c. The dt entry i2c-mode
decides at probe time if the controller needs to work in
slave mode and the controller is accordingly programmed.

(I don't have the original patches.)

Hmm.  How has slave-mode support been tested?

I have taken two I2C controllers in exynos5250.
I configured one as slave and the other as master port.
Then physically connected the pins of the two ports.

quoted

Remembering that I2C slave devices do not initiate bus accesses, all
accesses will be started by some other master.  How are you dealing
with the bytes received from the master,

I run the slave read application in background.
The resulting slave read will sleep till all bytes are received
(wait_event_interruptible)

Oh god no, not more broken interruptible waits in I2C code.  I've seen
already the results of crap like this with a kernel I2C peripheral driver
falling over because the I2C layer returns -ERESTARTcrap with the Marvell
I2C bus adapter.

once the master sends the data, an ack is given out by the slave controller
in the ISR and the data is cached in the buffer(
buffer sent by slave receive application).
After all data is received, the read wakes up and the
slave receive program gets the data.

quoted

and how are you returning a response to the master in reply to a read request?

Similarl logic works in slave transmit mode (read request). Slave
sleeps till the master initiates the transfer.

quoted

We had support for this on PXA I2C through a callback from the driver
into PXA code (used for the Psion Teklogix Netbook device) and it worked
really well, but what you can't do is use the standard I2C interfaces
for slave mode.

I have a question here. Since the same framework can work for both
master and slave, is there any technical limitations I have overseen
which prevents the slave mode to work?

I don't really call your description above as "working" - it sounds like
a bodge - it sounds like trying to bend a layer designed for master mode
to sort-of-maybe-if-the-wind-is-in-the-right-direction-and-the-cows-are-
all-standing-up-work.  What if the application is trying to read in slave
mode while the master is also trying to read?  How do you deal with that?
What about the converse?  What if the application is trying to write data
and the master also issues a write request?

Finally, what about a multi-master situation?  I can see no way for your
implementation to have any hope of working there because there is no
distinction between operating the interface in master mode and slave mode.