linux-iio.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Brian Masney <masneyb@onstation.org>
To: Jonathan Cameron <jic23@kernel.org>
Cc: linux-iio@vger.kernel.org
Subject: Re: regmap and i2c_smbus_write_byte question
Date: Sat, 5 Nov 2016 10:29:00 -0400	[thread overview]
Message-ID: <20161105142900.GA6844@basecamp.onstation.org> (raw)
In-Reply-To: <6a764449-63a3-e7a3-8bd4-d20c436bed3f@kernel.org>

On Sat, Nov 05, 2016 at 12:53:02PM +0000, Jonathan Cameron wrote:
> On 05/11/16 11:38, Brian Masney wrote:
> > I am investigating converting the tsl2583 staging driver over to use
> > the regmap API. I ran into an issue converting the following call to
> > i2c_smbus_write_byte() over to the regmap API:
> > 
> > struct tsl2583_chip {
> >         struct i2c_client *client;
> >         ...
> > }
> > 
> > /*
> >  * clear status, really interrupt status (interrupts are off), but
> >  * we use the bit anyway - don't forget 0x80 - this is a command
> >  */      
> > ret = i2c_smbus_write_byte(chip->client,
> >                            (TSL258X_CMD_REG | TSL258X_CMD_SPL_FN |
> >                             TSL258X_CMD_ALS_INT_CLR));
> > 
> > I don't see a way to do this in the regmap API.  
> > drivers/input/touchscreen/tsc2004.c has this same issue and that code
> > directly calls i2c_smbus_write_byte() along with the regmap API. Am I
> > missing something? This doesn't feel right to me to bypass the regmap
> > API and directly access the i2c client.
> > 
> > The data sheet for the tsl2583 sensor is available here:
> > http://media.digikey.com/PDF/Data%20Sheets/Austriamicrosystems%20PDFs/TSL2581,83.pdf
> > Page 10 has the table that describes clearing the interrupt bit. The
> > sensor will not take additional readings until that bit is cleared
> > (even though interrupts are off).
> Bit of a tangential question but why do a regmap conversion for this device?
> It's i2c only so we don't gain from easy support for multiple bus types.
> There aren't all that many registers and we don't have reason to
> often read/write the ones that aren't volatile.
> 
> Hence I'd argue there is little point in doing a regmap conversion in
> the first place.
> 
> If there is a good reason to do it then there isn't an easy way around
> these 'odd' diversions from what is otherwise a nice register
> based interface.
> 
> Hence another reason to not do a regmap conversion.

I totally agree that it does not make sense to do the regmap conversion
for this driver. The only reason that I initially looked into doing it
was that there are other light drivers in mainline (with few registers)
that use the regmap API.

My tsl2583 patch set that I sent out a few days ago is still valid even
though the cover sheet says it lays the ground work for the regmap
conversion.

Thanks,

Brian


      reply	other threads:[~2016-11-05 14:29 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-05 11:38 regmap and i2c_smbus_write_byte question Brian Masney
2016-11-05 12:53 ` Jonathan Cameron
2016-11-05 14:29   ` Brian Masney [this message]

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=20161105142900.GA6844@basecamp.onstation.org \
    --to=masneyb@onstation.org \
    --cc=jic23@kernel.org \
    --cc=linux-iio@vger.kernel.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).