Jonas Bonn wrote: > I did see that enable_clock is called multiple times... it's called > once per request, even when the clock is already enabled. Conversely, > disable_clock is called just once. This doesn't seem to be an issue, > though.
What you're seeing is a data transfer that requires a stop command be sent to the card upon completion, resulting in a back-to-back pair of transactions. It would be silly to disable the clock in this case, as it would be re-enabled just a few microseconds later. We could avoid the extraneous clock enable when the stop command is sent, but it also seemed silly to me to introduce additional complexity to test if the clock is already running, or to restructure the original code to make for "nicer" places to enable/disable the clocks. (It would be easier if the code didn't have so many "return" statements sprinkled in the middle of functions.) > I agree, the ISR doesn't touch the register... but it schedules > pio_tasklet, which does. Can pio_tasklet be scheduled ahead of the > interrupted task in this case? Good question; my head hurts as I try to sort that. I left the spin lock in -- best to be defensive. Regards, Mike (mwester)
