| Message ID | e692c4a9-6320-b9e0-d6e7-f58bbe6ba867@siemens.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On Thu, Jan 19, 2017 at 08:37:40PM +0100, Jan Kiszka wrote: > When using the a device with edge-triggered interrupts, such as MSIs, > the interrupt handler has to ensure that there is a point in time during I'm missing patches 1 and 3, what's going on here?
On Thu, 2017-01-19 at 19:57 +0000, Mark Brown wrote: > On Thu, Jan 19, 2017 at 08:37:40PM +0100, Jan Kiszka wrote: > > When using the a device with edge-triggered interrupts, such as > > MSIs, > > the interrupt handler has to ensure that there is a point in time > > during > > I'm missing patches 1 and 3, what's going on here? Patch 1 had been applied by you. I think Jan just needs to resend with proper version and set of patches.
Jan Kiszka <jan.kiszka@siemens.com> writes: > When using the a device with edge-triggered interrupts, such as MSIs, > the interrupt handler has to ensure that there is a point in time during > its execution where all interrupts sources are silent so that a new > event can trigger a new interrupt again. > > This is achieved here by disabling all interrupt sources for a moment > before processing them according to the status register. If a new > interrupt should have arrived after we read the status, it will now > re-trigger the interrupt, even in edge mode. > > Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> Acked-by: Robert Jarzmik <robert.jarzmik@free.fr> Cheers. -- Robert -- To unsubscribe from this list: send the line "unsubscribe linux-spi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Jan 19, 2017 at 10:04:32PM +0200, Andy Shevchenko wrote: > On Thu, 2017-01-19 at 19:57 +0000, Mark Brown wrote: > > I'm missing patches 1 and 3, what's going on here? > Patch 1 had been applied by you. I think Jan just needs to resend with > proper version and set of patches. OK - Jan, the purpose of numbering patches in a series is so we can tell what order they come in. That's it. If the set of patches gets changed due to things being added or removed the numbers will be different but that's totally OK as their only relevance is in ordering things within a given posting.
On 2017-01-20 13:21, Mark Brown wrote: > On Thu, Jan 19, 2017 at 10:04:32PM +0200, Andy Shevchenko wrote: >> On Thu, 2017-01-19 at 19:57 +0000, Mark Brown wrote: > >>> I'm missing patches 1 and 3, what's going on here? > >> Patch 1 had been applied by you. I think Jan just needs to resend with >> proper version and set of patches. > > OK - Jan, the purpose of numbering patches in a series is so we can tell > what order they come in. That's it. If the set of patches gets changed > due to things being added or removed the numbers will be different but > that's totally OK as their only relevance is in ordering things within a > given posting. Sorry if the numbering was confusing for you, it was, of course, a selective update. Just tell me, if you need a new round with of patches 2 and 3 (as 1 and 2). Jan
On Fri, Jan 20, 2017 at 04:29:28PM +0100, Jan Kiszka wrote: > Sorry if the numbering was confusing for you, it was, of course, a > selective update. Just tell me, if you need a new round with of patches > 2 and 3 (as 1 and 2). Please resend.
diff --git a/drivers/spi/spi-pxa2xx.c b/drivers/spi/spi-pxa2xx.c index 0d10090..f9c2329 100644 --- a/drivers/spi/spi-pxa2xx.c +++ b/drivers/spi/spi-pxa2xx.c @@ -785,6 +785,9 @@ static irqreturn_t ssp_int(int irq, void *dev_id) if (!(status & mask)) return IRQ_NONE; + pxa2xx_spi_write(drv_data, SSCR1, sccr1_reg & ~drv_data->int_cr1); + pxa2xx_spi_write(drv_data, SSCR1, sccr1_reg); + if (!drv_data->master->cur_msg) { handle_bad_msg(drv_data); /* Never fail */
When using the a device with edge-triggered interrupts, such as MSIs, the interrupt handler has to ensure that there is a point in time during its execution where all interrupts sources are silent so that a new event can trigger a new interrupt again. This is achieved here by disabling all interrupt sources for a moment before processing them according to the status register. If a new interrupt should have arrived after we read the status, it will now re-trigger the interrupt, even in edge mode. Signed-off-by: Jan Kiszka <jan.kiszka@siemens.com> --- Successfully tested by now. Changes to v2: - avoid inner looping by making the hardware retrigger on "forgotten" IRQ sources drivers/spi/spi-pxa2xx.c | 3 +++ 1 file changed, 3 insertions(+)