On 18-04-23, 15:06, Charles Keepax wrote:
It makes sense to have only a single point responsible for ensuring that all currently pending IRQs are handled. The current code in sdw_handle_slave_alerts confusingly splits this process in two. This code will loop until the asserted IRQs are cleared but it will only handle IRQs that were already asserted when it was called. This means the caller must also loop (either manually, or through its IRQ mechanism) until the IRQs are all handled. It makes sense to either do all the looping in sdw_handle_slave_alerts or do no looping there and let the host controller repeatedly call it until things are handled.
There are realistically two sensible host controllers, those that will generate an IRQ when the alert status changes and those that will generate an IRQ continuously whilst the alert status is high. The current code will work fine for the second of those systems but not the first with out additional looping in the host controller. Removing the code that filters out new IRQs whilst the handler is running enables both types of host controller to be supported and simplifies the code. The code will still only loop up to SDW_READ_INTR_CLEAR_RETRY times, so it shouldn't be possible for it to get completely stuck handling IRQs forever, and if you are generating IRQs faster than you can handle them you likely have bigger problems anyway.
This fixes an issue on the Cadence SoundWire IP, which only generates IRQs on an alert status change, where an alert which arrives whilst another alert is being handled will never be handled and will block all future alerts from being handled.
Applied, thanks