mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Mark Brown <broonie@kernel.org>
To: Lars-Peter Clausen <lars@metafoo.de>
Cc: Boris BREZILLON <boris.brezillon@free-electrons.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Maxime Ripard <maxime.ripard@free-electrons.com>,
	Shuge <shuge@allwinnertech.com>,
	kevin@allwinnertech.com, Chen-Yu Tsai <wens@csie.org>,
	Hans de Goede <hdegoede@redhat.com>,
	Carlo Caione <carlo@caione.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, dev@linux-sunxi.org
Subject: Re: [RFC PATCH v2] regmap: smbus: add support for regmap over smbus
Date: Tue, 15 Apr 2014 17:46:13 +0100	[thread overview]
Message-ID: <20140415164613.GF12304@sirena.org.uk> (raw)
In-Reply-To: <534D357F.9040906@metafoo.de>

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

On Tue, Apr 15, 2014 at 03:34:55PM +0200, Lars-Peter Clausen wrote:
> On 04/15/2014 02:56 PM, Mark Brown wrote:

> >  - 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.

> 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

Please note what I said about convenience - if lots of devices have
exactly the same set of constraints to set up it's possible sensible to
have a standard way of specifying them.  It's going to be a bit easier
to just say it's smbus than to remember exactly what that means.

> 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.

Right, that's why I said it's probably only worth it if the controller
does smbus natively.

> 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.

It's not clear to me that if the controller supports smbus we shouldn't
use it; presumably it's adding some value to have written the code to
take advantage of it.  That would mean another case for device is smbus
only and controller has explicit smbus support.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2014-04-15 16:47 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
2014-04-15 16:46                 ` Mark Brown [this message]
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=20140415164613.GF12304@sirena.org.uk \
    --to=broonie@kernel.org \
    --cc=boris.brezillon@free-electrons.com \
    --cc=carlo@caione.org \
    --cc=dev@linux-sunxi.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hdegoede@redhat.com \
    --cc=kevin@allwinnertech.com \
    --cc=lars@metafoo.de \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maxime.ripard@free-electrons.com \
    --cc=shuge@allwinnertech.com \
    --cc=wens@csie.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

all inboxes | Powered by JetHome®