linux-i2c.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Wolfram Sang <wsa@the-dreams.de>
To: Kachalov Anton <mouse@mayc.ru>
Cc: linux-i2c@vger.kernel.org
Subject: Re: i2c: slave support framework improvements
Date: Sat, 23 Jul 2016 21:51:14 +0200	[thread overview]
Message-ID: <20160723195114.GA2104@katana> (raw)
In-Reply-To: <137031469256709@web4j.yandex.ru>

[-- Attachment #1: Type: text/plain, Size: 1899 bytes --]

Hi,

> I'm working on multi-master i2c support in Aspeed SoC (AST2150,
> AST2300 and so on) and succeed with event passing to the slave
> software backend. Besides AST has two operation modes: byte transfer

Which upstream driver does that SoC use?

> and buffer transfer. While i2c slave framework operates over bytes. In
> current scheme I would able to receive an interrupt on buffer fill
> then call N-times event function with one byte. It is a little
> overhead there. What we can do there?

Let me quote from Documentation/i2c/slave-interface:

About buffers
-------------

During development of this API, the question of using buffers instead of just
bytes came up. Such an extension might be possible, usefulness is unclear at
this time of writing. Some points to keep in mind when using buffers:

* Buffers should be opt-in and slave drivers will always have to support
  byte-based transactions as the ultimate fallback because this is how the
  majority of HW works.

* For backends simulating hardware registers, buffers are not helpful because
  on writes an action should be immediately triggered. For reads, the data in
  the buffer might get stale.

* A master can send STOP at any time. For partially transferred buffers, this
  means additional code to handle this exception. Such code tends to be
  error-prone.

> Second one thing that I want to point is a slave support in I2C MUX/switch
> drivers. For instance I use PCA9548 switch and want to have N (N <= 8) slaves
> (one per channel)

How do the other masters know that their channel is currently muxed then? And
what if two of them want to access two of your slaves at the same time?

This setup may work for one specific case but in general sounds pretty fragile
to me. This fragility shows in all the hacks needed to work around the proper
abstractions. I don't think much can be done about that.

Regards,

   Wolfram


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

  reply	other threads:[~2016-07-23 19:51 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-23  6:51 i2c: slave support framework improvements Kachalov Anton
2016-07-23 19:51 ` Wolfram Sang [this message]
2016-07-25  7:02   ` Kachalov Anton
2016-07-25  7:21     ` Wolfram Sang
2016-07-25  7:47       ` Kachalov Anton
2016-07-25  8:28         ` Wolfram Sang
2016-07-25  9:11           ` Kachalov Anton
2016-07-25  9:41             ` Wolfram Sang
2016-07-25 10:00               ` Kachalov Anton
2016-07-26  9:50                 ` Peter Rosin
2016-07-26 16:51                   ` Kachalov Anton
2016-07-28  6:55                     ` Peter Rosin
2016-07-28  8:25                       ` Peter Rosin
2016-07-28 14:39                       ` Kachalov Anton
2016-07-28  7:41                     ` Wolfram Sang
2016-07-28  8:20                       ` Peter Rosin
2016-07-28  8:39                         ` Wolfram Sang
2016-07-28  8:54                           ` Peter Rosin
2016-07-28  9:15                             ` Wolfram Sang
2016-07-28  9:39                               ` Peter Rosin
2016-08-01 10:46                                 ` Wolfram Sang
2016-08-15  8:58                                 ` Peter Rosin
2016-08-16 12:12                                   ` Wolfram Sang
2016-08-16 13:33                                     ` Peter Rosin
2016-08-16 13:53                                       ` Kachalov Anton
2016-07-28 14:44                       ` Kachalov Anton

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160723195114.GA2104@katana \
    --to=wsa@the-dreams.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=mouse@mayc.ru \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).