[alsa-devel] [PATCH] ASoC: Add delay information for Samsung IISv2 DAIs

jassi brar jassisinghbrar at gmail.com
Thu Mar 4 15:16:37 CET 2010


On Thu, Mar 4, 2010 at 11:01 PM, Mark Brown
<broonie at opensource.wolfsonmicro.com> wrote:
> On Thu, Mar 04, 2010 at 10:38:39PM +0900, jassi brar wrote:
>> On Thu, Mar 4, 2010 at 10:24 PM, Mark Brown
>> > On Thu, Mar 04, 2010 at 10:18:59PM +0900, jassi brar wrote:
>
>> >> I am trying to make functions in s3c-i2s-v2.c re-entrant as much as possible,
>> >> 'delay' too seems to be a good candidate.
>
>> > Could you expand on what you mean by this?
>
>> I mean, 'delay' is such a trival func that it can perhaps do
>> controller specific stuff
>> after checking some flag(new) in s3c_i2sv2_info.
>
> OK, that's nothing to do with the normal definition of "reentrant" -
> normally reentrancy means the ability to handle simultaneous calls from
> multiple threads of execution which is not at all relevant here since
> supporting more hardware is an orthogonal issue.
That is but one out of many criteria, another is that the func works
only on the data
provided to it by the caller.

>> > All we're doing here is
>> > directly reporting a value read from a memory mapped register so there's
>> > nothing to be worried about from a locking point of view unless there
>> > were a multi-core system and the bus to the IP needed some locking,
>> > which is vanishingly unlikely to ever happen.
>
>> As I said, I am OK. I just see this func being modified soon to handle
>> i2sv4 too.
>
> Looking at the hardware I suspect that all you'd be able to do would be
> try to take a guess as to which of the FIFOs you might want to report on
> or faff around averaging them but given that everything is clocked in
> lockstep I'm not sure it's worth bothering.
I see.


More information about the Alsa-devel mailing list