From: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>
To: Marek Vasut <marek.vasut@gmail.com>,
Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
"H. Nikolaus Schaller" <hns@goldelico.com>,
Mark Brown <broonie@kernel.org>
Cc: linux-gpio@vger.kernel.org
Subject: register access issues in pca953x gpio driver
Date: Fri, 27 Mar 2020 08:49:22 +0100 [thread overview]
Message-ID: <20200327074922.vrxbcjw2xlrv2bkb@pengutronix.de> (raw)
Hello,
I have an issue with an pca9505 when the .set_multiple callback is used.
That chip has a bit ("AI") in the register address that makes the
address increment automatically on subsequent reads and writes.
The problem (that was already noticed in commit 3b00691cc46a ("gpio:
pca953x: hack to fix 24 bit gpio expanders")) is that the regmap stuff
isn't aware of this bit and so register accesses that make use of the auto
incrementing are not matched to those without it.
Additionally there is a bug in pca953x_recalc_addr() that results in the
AI bit only be set for register writes. (That's the issue that made me
notice this problem. The result is that in .set_multiple the read
accesses bank 0's register only (when the hardware is hit) or uses the
read cache from a location without AI set and then writes using AI set.)
I didn't try to understand if fixing pca953x_recalc_addr() to not set AI
depending on write fixes all issues. But to make the register access in
the driver robust I'm convinced we need to fix the regmap stuff to
understand the AI bit.
@broonie: I don't know regmap good enough to instantly know the right
magic to do this. Can you give a rough overview what would be needed?
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | https://www.pengutronix.de/ |
next reply other threads:[~2020-03-27 7:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-27 7:49 Uwe Kleine-König [this message]
2020-03-27 10:26 ` register access issues in pca953x gpio driver Andy Shevchenko
2020-03-27 13:49 ` Uwe Kleine-König
2020-03-27 13:03 ` Mark Brown
2020-03-27 13:46 ` Uwe Kleine-König
2020-03-27 13:58 ` Mark Brown
2020-03-27 17:22 ` [PATCH v1 0/2] gpio: pca953x: fix handling of automatic address incrementing Uwe Kleine-König
2020-03-27 17:22 ` [PATCH v1 1/2] [RFC] " Uwe Kleine-König
2020-03-27 17:22 ` [PATCH v1 2/2] [RFC] gpio: pca953x: drop unused parameters of pca953x_recalc_addr() Uwe Kleine-König
2020-03-27 22:06 ` H. Nikolaus Schaller
2020-03-28 9:27 ` Uwe Kleine-König
2020-03-28 19:41 ` Andy Shevchenko
2020-03-30 14:07 ` Andy Shevchenko
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=20200327074922.vrxbcjw2xlrv2bkb@pengutronix.de \
--to=u.kleine-koenig@pengutronix.de \
--cc=andriy.shevchenko@linux.intel.com \
--cc=broonie@kernel.org \
--cc=hns@goldelico.com \
--cc=linux-gpio@vger.kernel.org \
--cc=marek.vasut@gmail.com \
/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).