public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@cam.ac.uk>
To: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Regmap bulk read styles.
Date: Mon, 05 Sep 2011 15:49:14 +0100	[thread overview]
Message-ID: <4E64E16A.6060401@cam.ac.uk> (raw)

Hi Mark,

I'm looking at the using your regmap stuff for IIO.
Other than the minor queries in the other emails I've sent,
the big issue for me is that of bulk reading.

The two most common forms we have are 'burst read'
and what might be termed a 'gather read'.

The burst read is pretty much what you have covered by
regmap_bulk_read. I assume an implementation for spi
doing

TX Addr1 XXXXX XXXXX XXXXX XXXXX
RX XXXXX Data1 Data2 Data3 Data4 ...

would be general enough to be worth providing? Any device
that doesn't understand this should simply not use it.

The second is more interesting.  It actually looks quite like
your gather write.  We have a set of registers that we need
to read.  A classic example is that a coherent set will only
be received (e.g. valid at an instant in time) if we read
all channels of an accelerometer in one go (between chip selects).

typically involves either

TX  Addr1  Addr2  Addr3  XXXXX
RX  XXXXX  Data1  Data2  Data3

Or

TX Addr1  00000 Addr2 00000
RX XXXXX  Data1 XXXXX Data2

One slight complexity is cs_change, but that probably needs fixing
in the spi core which doesn't currently allowing setting up a
default for that.  This second case would be a set of transfers
(read then writes effectively).

Would you be in favour of an interface to handle this use case
or is it better just to bypass regmap for this use case?
(which would be a pity as it leads to duplication as all the
configuration stuff fits nicely).

As an aside, isn't your gather write more typically described
as a scatter write?  (writes one coherent set to a number of
disjoint locations?)

Alternatively should I just be bypassing regmap entirely for
read only data registers like these?  Caching is kind of pointless
other than for debugging purposes (though that would be nice).

Thanks,

Jonathan

             reply	other threads:[~2011-09-05 14:41 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-05 14:49 Jonathan Cameron [this message]
2011-09-05 15:19 ` Regmap bulk read styles Mark Brown
2011-09-05 15:36   ` Jonathan Cameron

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=4E64E16A.6060401@cam.ac.uk \
    --to=jic23@cam.ac.uk \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@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