Hi Jun, Felipe Balbi <balbi@xxxxxxxxxx> writes: >> In any case, increasing the timeout should be fine with me. It maybe >> difficult to determine the max timeout base on the slowest clock rate >> and number of cycles. Different controller and controller versions >> behave differently and may have different number of clock cycles to >> complete a command. >> >> The RTL engineer recommended timeout to be at least 1ms (which maybe >> more than the polling rate of this patch). I'm fine with either the rate >> provided by this tested patch or higher. > > A whole ms waiting for a command to complete? Wow, that's a lot of time > blocking the CPU. It looks like, perhaps, we should move to command > completion interrupts. The difficulty here is that we issue commands > from within the interrupt handler and, as such, can't > wait_for_completion(). > > Meanwhile, we will take the timeout increase I guess, otherwise NXP > won't have a working setup. patch 1 in this series doesn't apply to testing/next. Care to rebase and resend? Thank you -- balbi
Attachment:
signature.asc
Description: PGP signature
