From: Mark Brown <broonie@kernel.org>
To: Markus Pargmann <mpa@pengutronix.de>,
Henry Chen <henryc.chen@mediatek.com>
Cc: linux-kernel@vger.kernel.org, Mark Brown <broonie@kernel.org>
Subject: [PATCH] regmap: Support bulk reads for devices without raw formatting
Date: Fri, 28 Aug 2015 20:11:04 +0100 [thread overview]
Message-ID: <1440789064-11098-1-git-send-email-broonie@kernel.org> (raw)
When doing a bulk read from a device which lacks raw I/O support we fall
back to doing register at a time reads but we still use the raw
formatters in order to render the data into the word size used by the
device (since bulk reads still operate on the device word size rather
than unsigned ints). This means that devices without raw formatting
such as those that provide reg_read() are not supported. Provide
handling for them by copying the values read into native endian values
of the appropriate size.
Signed-off-by: Mark Brown <broonie@kernel.org>
---
This is tested with my "hey, look - it compiles!" test plan. Based on
looking at the users and the other ways formatting is used this is the
interface that makes most sense to me, we'll need similar handling for
the write case. Does this solve the problems you are seeing?
drivers/base/regmap/regmap.c | 29 ++++++++++++++++++++++++++++-
1 file changed, 28 insertions(+), 1 deletion(-)
diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index c13b1f2..62e3d7c 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -2364,7 +2364,34 @@ int regmap_bulk_read(struct regmap *map, unsigned int reg, void *val,
&ival);
if (ret != 0)
return ret;
- map->format.format_val(val + (i * val_bytes), ival, 0);
+
+ if (map->format.format_val) {
+ map->format.format_val(val + (i * val_bytes), ival, 0);
+ } else {
+ /* Devices providing read and write
+ * operations can use the bulk I/O
+ * functions if they define a val_bytes,
+ * we assume that the values are native
+ * endian.
+ */
+ u32 *u32 = val;
+ u16 *u16 = val;
+ u8 *u8 = val;
+
+ switch (map->format.val_bytes) {
+ case 4:
+ u32[i] = ival;
+ break;
+ case 2:
+ u16[i] = ival;
+ break;
+ case 1:
+ u8[i] = ival;
+ break;
+ default:
+ return -EINVAL;
+ }
+ }
}
}
--
2.5.0
next reply other threads:[~2015-08-28 19:11 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-28 19:11 Mark Brown [this message]
2015-08-31 5:18 ` Henry Chen
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=1440789064-11098-1-git-send-email-broonie@kernel.org \
--to=broonie@kernel.org \
--cc=henryc.chen@mediatek.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mpa@pengutronix.de \
/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®