Message-ID: <20150320074214.GD10068@pengutronix.de>
Date:	Fri, 20 Mar 2015 08:42:14 +0100
From:	Uwe Kleine-König 
	<u.kleine-koenig@...gutronix.de>
To:	Wolfram Sang <wsa@...-dreams.de>
Cc:	linux-i2c@...r.kernel.org, linux-sh@...r.kernel.org,
	Magnus Damm <magnus.damm@...il.com>,
	Simon Horman <horms@...ge.net.au>,
	Laurent Pinchart <laurent.pinchart@...asonboard.com>,
	Geert Uytterhoeven <geert@...ux-m68k.org>,
	Andrey Danin <danindrey@...l.ru>,
	Marc Dietrich <marvin24@....de>,
	Debora Grosse <debora@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] Documentation: i2c: describe the new slave mode

Hello Wolfram,

On Fri, Mar 20, 2015 at 08:30:13AM +0100, Wolfram Sang wrote:
> 
> > > +Finally, Linux can also be an I2C slave in case I2C controllers have slave
> > > +support. Besides this HW requirement, one also needs a software backend
> > I wouldn't have written "Finally, ...". While it's great that we have
> > slave support now, being enthusiastic here looks strange if someone
> > reads it while slave support has become "normal".
> 
> OK.
> 
> > > +providing the actual functionality. An example for this is the slave-eeprom
> > > +driver, which acts as a dual memory driver. While another I2C master on the bus
> > > +can access it like a regular eeprom, the Linux I2C slave can access the content
> > > +via sysfs and retrieve/provide information as needed. The software backend
> > > +driver and the I2C bus driver communicate via events. Here is a small graph
> > > +visualizing the data flow and the means by which data is transported. The
> > > +dotted line marks only one example. The backend could also use e.g. a character
> > > +device, or use in-kernel mechanisms only, or something completely different:
> > Or something self contained, so the userspace part is actually optional
> > (but probably present most of the time).
> 
> With "in-kernel mechanisms" I meant self-contained. Maybe "be in-kernel
> only"?
I'm sure "in-kernel mechanisms" wasn't in the mail I replied to. (Hmm,
or I must have missed that while reading.)

> > Another slave backend I have in mind is a bus-driver tester. That
> > wouldn't necessarily need a userspace part.
> 
> Yes, I envisioned that, too.
> 
> > 
> > > +              e.g. sysfs        I2C slave events        I/O registers
> > > +  +-----------+   v    +---------+     v     +--------+  v  +------------+
> > > +  | Userspace +........+ Backend +-----------+ Driver +-----+ Controller |
> > > +  +-----------+        +---------+           +--------+     +------------+
> > > +                                                                | |
> > > +  ----------------------------------------------------------------+--  I2C
> > > +  --------------------------------------------------------------+----  Bus
> > > +
> > > +Note: Technically, there is also the I2C core between the backend and the
> > > +driver. However, at this time of writing, the layer is transparent.
> > s/this/the/ ?
> 
> Maybe.
> 
> > > +The bus driver sends an event to the backend using the following function:
> > > +
> > > +	ret = i2c_slave_event(client, event, &val)
> > > +
> > > +'client' describes the i2c slave device. 'event' is one of the special event
> > > +types described hereafter. 'val' holds an u8 value for the data byte to be
> > > +read/written and is thus bidirectional. The pointer to val must always be
> > > +provided even if val is not used for an event. 'ret' is the return value from
> > Does that mean that I have to pass a valid address, or can I use NULL,
> > too?
> 
> Is NULL a valid pointer to val?
NULL is a pointer and you didn't wrote about "valid" above. I just
wondered if the necessity just comes from the fact that the function
takes 3 parameters and so you have to give it 3 (this wouldn't needed to
be pointed out IMHO) or if the value must be valid (then the wording
isn't optimal).
Is there a technical reason to require val to be valid?

> > I didn't look into the actual implementation yet, but if I understand
> > correctly a slave driver only sees I2C_SLAVE_READ_REQUESTED once and
> > then only one I2C_SLAVE_READ_PROCESSED per byte, right? Does the slave
> 
> Right.
> 
> > driver gets noticed somehow if a previously requested byte doesn't make
> > it on the wire? Otherwise you cannot correctly maintain e.g. the current
> 
> Some HW can do this, but not all. That would maybe be another candidate
> for an optional event. Although, people should try hard to not need it.
> 
> > read position of the eeprom driver, do you? (That's a bit like one of
> > the problems with buffer support you pointed out further down.)
> 
> You need to assume that if the next byte is requested, the previous byte
> made it to the bus. So, you should do pre-increment in
> I2C_SLAVE_READ_PROCESSED, not post-increment. I didn't want to write
This might be a correctness problem, right? If we cannot fix it (with
the current slave abstraction) should this be pointed out somewhere; at
least in the eeprom driver as this will probably be the reference for
the next backend?

> this example so explicit because not all slave-backends will have a
> position pointer. And besides, it might make sense to extract the code for
> managing a position pointer from the slave-eeprom driver. Then, we'd
> have only one trusted implementation of EEPROM-alike behaviour and
> people can concentrate on reacting to reads/writes.

Best regards
Uwe

-- 
Pengutronix e.K.                           | Uwe Kleine-König            |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
--
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