All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Jonathan Cameron <jic23@cam.ac.uk>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Regmap bulk read styles.
Date: Mon, 5 Sep 2011 08:19:24 -0700	[thread overview]
Message-ID: <20110905151917.GD3889@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <4E64E16A.6060401@cam.ac.uk>

On Mon, Sep 05, 2011 at 03:49:14PM +0100, Jonathan Cameron wrote:

> 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.

Yes, that's the assumption the code is making for all buses.

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

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

If you can come up with a tasteful interface for doing this I wouldn't
object but my suspicion is that it's going to be easier to reimplement.
It does seem useful, I'm just worried about how the interface would
look.

> 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?)

On the write side it's generally a gather (reading from different
locations and writing out a continuous stream) while on the read side
it's generally a scatter (reading a continuous data stream and writing
it to multiple locations).  The gather here refers to getting data from
more than one place and using it to transmit a single byte stream.

  reply	other threads:[~2011-09-05 15:19 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-05 14:49 Regmap bulk read styles Jonathan Cameron
2011-09-05 15:19 ` Mark Brown [this message]
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=20110905151917.GD3889@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=jic23@cam.ac.uk \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.