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 14:25:15 +0200	[thread overview]
Message-ID: <534D252B.8060009@metafoo.de> (raw)
In-Reply-To: <534D1DDA.40207@free-electrons.com>

On 04/15/2014 01:54 PM, Boris BREZILLON wrote:
>
>
> On 15/04/2014 12:09, Mark Brown wrote:
>> On Tue, Apr 15, 2014 at 09:36:13AM +0200, Boris BREZILLON wrote:
>>> On 14/04/2014 23:04, Mark Brown wrote:
>
>>>> The transfer type gets set once per device at init time so why not
>>>> just parameterise based on val_bytes?
>
>>> Actually, you may want to transfer 1 byte registers using the block
>>> method (if your device only support block transfers). This depends on
>>> the device being accessed and what it supports, but I'm not sure we can
>>> assume 1 byte registers will always be transferred using SMBUS byte
>>> transfers.
>
>> OK, so if this a realistic issue then it seems like it's better to
>> implement three different buses - there is not really any common code
>> between the various paths.
>
> Okay, I'll create 4 different busses (one for each access type).
> BTW, should I keep these implementations in the same source file
> (regmap-smbus.c) ?
> And, should I keep one method to register an smbus regmap or should I
> provide one method per access type and get rid of the
> regmap_smbus_transfer_type enum ?

I don't think we should leave the decision which bus to use to the driver. 
Neither should the driver have to choose whether to use smbus or native I2C. 
We want to use native I2C when available, because it is more efficient than 
going through the smbus emulation layer. On the other hand we want to 
automatically switch to smbus when native I2C is not available and the 
device can work fine with smbus. Also I'm afraid that we'll otherwise soon 
see code popping up like:

if (of_property_read_bool(np, "use-smbus-regmap"))
	regmap = regmap_init_smbus(...)
else
	regmap = regmap_init_i2c(...)

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.

- Lars

  parent reply	other threads:[~2014-04-15 12:25 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 [this message]
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
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=534D252B.8060009@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).