On 06/11/18 19:40, Trent Piepho wrote: > On Tue, 2018-11-06 at 16:00 +0000, Marc Zyngier wrote: >> >> It is hard to decide what the right solution is without understanding >> exactly what this particular write actually does. It seems to be some >> form of acknowledgement, but I'm only making an educated guess, and some >> of the defines suggest that there might be another register for that. > > Unfortunately, there are no docs for this controller. I've determined > that it sets a bit in this register when an MSI is received. Once set, > it acts as a mask and the controller will generate no interrupts when > the same MSI is subsequently received. Writing a 1 to a bit clears > that mask bit, obviously so that each bit can be cleared atomically vs > a non-atomic RMW. The controller does not queue any MSIs received > while the interrupt was masked. I'm not sure this is really a mask, as the controller seems to have other ways of really masking the interrupt. It looks a lot more like either an ACK, but I need to understand how this interacts with the masking register. And I do not want to guess it. I want actual information from people who build this IP. >> What I'm interested in is the relationship this has with the mask/unmask >> callbacks, and whether masking the interrupt before acking it would help. > > >> >> Gustavo, can you help here? >> >> In any way, moving the action of acknowledging the interrupt to its >> right spot in the kernel (dw_pci_bottom_ack) would be a good start. > > What about stable kernels that don't have the hierarchical API? My goal is to fix mainline first. Once we have something that works on mainline, we can look at propagating the fix to other versions. But mainline always comes first. Thanks, M. -- Jazz is not dead. It just smells funny...
