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 -- ~Vinod
