On 07/11/2018 11:07, Lorenzo Pieralisi wrote: > On Tue, Nov 06, 2018 at 07:40:18PM +0000, 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 would like to understand if this is the expected behaviour across > dwc controllers but to understand that, as Marc mentioned, we would > need some input from Synopsys (if that's not customizable option). > > Side note: what's the register at offset PCIE_MSI_INTR0_MASK > supposed to do ? It seems unused in the current kernel, with > a macro name hinting at MSI masking so I am asking. That's the interrupt mask for the controller #0 offset. Currently it's not used. Gustavo > >>> 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? > > We will have to backport the patches. > > Lorenzo >
