* Regmap bulk read styles.
@ 2011-09-05 14:49 Jonathan Cameron
2011-09-05 15:19 ` Mark Brown
0 siblings, 1 reply; 3+ messages in thread
From: Jonathan Cameron @ 2011-09-05 14:49 UTC (permalink / raw)
To: Mark Brown; +Cc: LKML
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Regmap bulk read styles.
2011-09-05 14:49 Regmap bulk read styles Jonathan Cameron
@ 2011-09-05 15:19 ` Mark Brown
2011-09-05 15:36 ` Jonathan Cameron
0 siblings, 1 reply; 3+ messages in thread
From: Mark Brown @ 2011-09-05 15:19 UTC (permalink / raw)
To: Jonathan Cameron; +Cc: LKML
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.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Regmap bulk read styles.
2011-09-05 15:19 ` Mark Brown
@ 2011-09-05 15:36 ` Jonathan Cameron
0 siblings, 0 replies; 3+ messages in thread
From: Jonathan Cameron @ 2011-09-05 15:36 UTC (permalink / raw)
To: Mark Brown; +Cc: LKML
On 09/05/11 16:19, Mark Brown wrote:
> 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.
Cool. If no one else does it in the meantime I'll add that one.
>
>> 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.
I'll have a think at some point and get back to you.
>
>> 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.
>
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2011-09-05 15:28 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-09-05 14:49 Regmap bulk read styles Jonathan Cameron
2011-09-05 15:19 ` Mark Brown
2011-09-05 15:36 ` Jonathan Cameron
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox