On Thu, Mar 4, 2010 at 11:01 PM, Mark Brown broonie@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.