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
prev parent 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).