Re: Waiting for a bit in a register to be cleared: which strategy?

[Rocky Hotas <rockyhotas%firemail.cc@localhost>]

On lug 03 11:15, Mouse wrote:

> I'm not sure what's "brutal" about those, but OK...

My ignorance about this kind of operations. Now I better understood,
thanks to your and Taylor's comments.

> Actually, because of your "& (uint32_t) NOT_CLEARED", it works
> regardless of the other bits in register A: you are masking off all but
> the low bit.

Oh, my fault. You are right.

> The other 31 bits - you're using bus_space_read_4, so it's reading 31
> bits.  If register A is an 8-bit register

No, in this case it is a 32 bit register: this is why I used
bus_space_read_4.

> Efficient in terms of what resource?  That is, what measure of
> efficiency are you interested in here?

Above all, the code complexity (not the hardware resource consumption).

> I'm having trouble thinking of one for which there's anything
> wrong with what you have.

OK, this is good!

> Check out the definition of __BIT - it is no different in practice
> from more or less what you're already doing.

Yes, now I better understood.

> There are multiple ways to do this.
> 
> The simplest is probably to just put a limit on the iteration count:
[...] 
> But this makes the timeout inherently dependent on the host CPU speed.

Yes, I excluded this because I would like to avoid using the CPU for
(potentially) millions of cycles and - as you said - because of the
CPU-dependent variable increment.

> If that's a problem, you could add a delay in the loop

I think this is the best in my case.

> If the device can be made to generate an interrupt when the bit
> changes, another answer is to make your driver enable that interrupt
> and go to sleep waiting for it.  The changes for that are too large for
> me to give here; depending on the surrounding code structure, they may
> involve significant rearrangement.

Yes, check out my answer to Taylor, with a link to the device
documentation. Interrupts are maybe the ideal solution, but I'm
completely unable to handle them in a driver. I'm a complete newbie.

> The last two options have the advantage that they release the CPU to do
> other useful work while waiting.  They have the disadvantage that they
> decrease responsiveness - the delay from the bit changing to the code
> reading register B increases significantly.

Yes, of coure.

> One is that busy-waiting is inefficient in that it does not allow the
> CPU to do any other useful work while waiting; if the delay is long
> compared to the time required to context-switch to doing other useful
> work, and there is, or might be, other useful work to do, this can be
> significant.

I think the bit is cleared almost immediately, according to how I guess
the device works, so this could not be the case.

> The other is that, as I wrote, for some buses and some devices, you
> have to access a register as the correct width or it will not work
[...]
> I don't
> know enough about your setup to tell whether it's an actual mismatch,
> nor, if it is, whether the difference matters.

I am sure that a 32 bit access is correct. My reply to Taylor (see the
bottom of the text) should provide all the elements to evaluate the
device.

Thanks for your help!

Rocky