linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: lars@metafoo.de (Lars-Peter Clausen)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH v2] regmap: smbus: add support for regmap over smbus
Date: Tue, 15 Apr 2014 15:34:55 +0200	[thread overview]
Message-ID: <534D357F.9040906@metafoo.de> (raw)
In-Reply-To: <20140415125654.GD12304@sirena.org.uk>

On 04/15/2014 02:56 PM, Mark Brown wrote:
[...]
>> My suggestion is that in regmap_init_i2c() you check the capabilities of the
>> I2C adapter. If it supports native I2C you setup the regmap with the
>> regmap_i2c struct just as it does right now. If the adapter does not support
>> native I2C, check if the device can be supported by smbus (reg_bytes == 8 &&
>> val_bytes % 8 == 0). For each type of smbus operations have one regmap_bus
>> struct, and if you can fallback to smbus choose the bus depending on the
>> config's val_bytes.
>
> That'd definitely be useful but potentially orthogonal, we can also do
> both and expose smbus explicitly with I2C falling back to it
> transparently.
>
> If the device *is* limited to smbus and the controller supports both
> (some do) I'd naively have expected that the native smbus support would
> do a little better - otherwise why bother using it?  We could identify
> the constraint set automatically for I2C devices though it's more for
> the client driver to specify.
>
> This means there's two changes to consider here:
>
>   - Providing APIs for registering actual smbus devices as a convenience
>     for devices with that constraint, regardless of how that is done
>     behind the scenes.
>
>   - Having the I2C implementation automatically use the smbus APIs if
>     it can and either the controller is smbus only or it makes sense to
>     do so for optimisation.
>
> both of which are independently useful.
>

I don't think it makes sense to expose smbus explicitly. We can already 
describe smbus restricted devices just fine with the current regmap_config 
and already support them with the current I2C regmap implementation. Using 
native I2C to access these devices will be more efficient than going through 
the smbus emulation layer. The smbus emulation layer essentially does the 
same as we do in regmap, so using the smbus emulation layer through regmap 
means doing the same thing twice.

What we currently do not support is devices which are restricted to block 
transfers and I think adding support for this should be handled by a 
separate patchset. As far as I understood it this patchset is about making 
it possible to use smbus controllers with regmap devices which are smbus 
compatible.

As I see it there are currently 3 cases:

1) Device is strictly smbus only and the controller supports native smbus
    => Use smbus
2) The device is smbus compatible but has extensions (e.g. support for multi 
register writes) and the controller supports only smbus.
    => Use smbus
3) For every other case
    => Use native I2C.

- Lars

  reply	other threads:[~2014-04-15 13:34 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-12  8:45 [RFC PATCH] regmap: smbus: add support for regmap over SMBus Boris BREZILLON
2014-04-12  9:02 ` Boris BREZILLON
2014-04-14 13:08 ` [RFC PATCH v2] " Boris BREZILLON
2014-04-14 21:04   ` Mark Brown
2014-04-15  7:36     ` Boris BREZILLON
2014-04-15 10:09       ` Mark Brown
2014-04-15 11:54         ` Boris BREZILLON
2014-04-15 12:10           ` Mark Brown
2014-04-15 12:25           ` Lars-Peter Clausen
2014-04-15 12:40             ` Boris BREZILLON
2014-04-15 13:08               ` Lars-Peter Clausen
2014-04-15 12:56             ` [RFC PATCH v2] regmap: smbus: add support for regmap over smbus Mark Brown
2014-04-15 13:34               ` Lars-Peter Clausen [this message]
2014-04-15 16:46                 ` Mark Brown
2014-04-15 19:18                   ` Lars-Peter Clausen
2014-04-15 22:38                     ` Mark Brown
2014-04-16  8:16                       ` [PATCH] regmap: i2c: fallback to SMBus if the adapter does not support standard I2C Boris BREZILLON
2014-04-16 17:06                         ` Mark Brown
2014-04-16 17:16                           ` Boris BREZILLON
2014-04-16 21:00                             ` Mark Brown

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=534D357F.9040906@metafoo.de \
    --to=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    /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).