All of lore.kernel.org
 help / color / mirror / Atom feed
From: Joel Fernandes <joelf@ti.com>
To: Sekhar Nori <nsekhar@ti.com>
Cc: Tony Lindgren <tony@atomide.com>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Sricharan R <r.sricharan@ti.com>, Rajendra Nayak <rnayak@ti.com>,
	Lokesh Vutla <lokeshvutla@ti.com>,
	Matt Porter <matt@ohporter.com>,
	Grant Likely <grant.likely@secretlab.ca>,
	Rob Herring <rob.herring@calxeda.com>,
	Vinod Koul <vinod.koul@intel.com>, Dan Williams <djbw@fb.com>,
	Mark Brown <broonie@linaro.org>,
	Benoit Cousson <benoit.cousson@linaro.org>,
	Russell King <linux@arm.linux.org.uk>,
	Arnd Bergmann <arnd@arndb.de>, Olof Johansson <olof@lixom.net>,
	Balaji TK <balajitk@ti.com>,
	Gururaja Hebbar <gururaja.hebbar@ti.com>,
	Chris Ball <cjb@laptop.org>,
	Jason Kridner <jkridner@beagleboard.org>,
	Linux OMAP List <linux-omap@vger.kernel.org>,
	Linux ARM Kernel List <linux-arm-kernel@lists.infradead.org>,
	Linux DaVinci Kernel List 
	<davinci-linux-open-source@linux.davincidsp.com>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linux MMC List <linux-mmc@vger.kernel.org>
Subject: Re: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
Date: Wed, 31 Jul 2013 00:05:15 -0500	[thread overview]
Message-ID: <51F89B0B.4080803@ti.com> (raw)
In-Reply-To: <51F77982.7030601@ti.com>

On 07/30/2013 03:29 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> We certainly don't want error conditions to be cleared anywhere
> 
> 'anywhere' is a really loaded term.
> 
>> as this will make us 'forget' about missed events. We depend on
>> knowing which events were missed in order to be able to reissue them.
> 
>> This fixes a race condition where the EMR was being cleared
>> by the transfer completion interrupt handler.
>>
>> Basically, what was happening was:
>>
>>             Missed event
>>              |
>>              |
>>              V
>> SG1-SG2-SG3-Null
>>          \
>>           \__TC Interrupt (Almost same time as ARM is executing
>> TC interrupt handler, an event got missed and also forgotten
>> by clearing the EMR).
> 
> Sorry, but I dont see how edma_stop() is coming into picture in the race
> you describe?

In edma_callback function, for the case of DMA_COMPLETE (Transfer
completion interrupt), edma_stop() is called when all sets have been
processed. This had the effect of clearing the EMR.

This has 2 problems:

1.
If error interrupt is also pending and TC interrupt clears the EMR.

Due to this the ARM will execute the error interrupt even though the EMR
is clear. As a result, the following if condition in dma_ccerr_handler
will be true and IRQ_NONE is returned.

        if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
            (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
            (edma_read(ctlr, EDMA_QEMR) == 0) &&
            (edma_read(ctlr, EDMA_CCERR) == 0))
                return IRQ_NONE;

If this happens enough number of times, IRQ subsystem disables the
interrupt thinking its spurious which creates serious problems.

2.
If the above if statement condition is removed, then EMR is 0 so the
callback function will not be called in dma_ccerr_handler thus the event
is forgotten, never triggered manually or never sets missed flag of the
channel.

So about the race: TC interrupt handler executing before the error
interrupt handler can result in clearing the EMR and creates these problems.

>> The EMR is ultimately being cleared by the Error interrupt
>> handler once it is handled so we don't have to do it in edma_stop.
> 
> This, I agree with. edma_clean_channel() also there to re-initialize the
> channel so doing it in edma_stop() certainly seems superfluous.

Sure.

Thanks,

-Joel

WARNING: multiple messages have this Message-ID (diff)
From: Joel Fernandes <joelf-l0cyMroinI0@public.gmane.org>
To: Sekhar Nori <nsekhar-l0cyMroinI0@public.gmane.org>
Cc: Mark Brown <broonie-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>,
	Tony Lindgren <tony-4v6yS6AI5VpBDgjK7y7TUQ@public.gmane.org>,
	Grant Likely
	<grant.likely-s3s/WqlpOiPyB63q8FvJNQ@public.gmane.org>,
	Sricharan R <r.sricharan-l0cyMroinI0@public.gmane.org>,
	Russell King <linux-lFZ/pmaqli7XmaaqVzeoHQ@public.gmane.org>,
	Vinod Koul <vinod.koul-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Lokesh Vutla <lokeshvutla-l0cyMroinI0@public.gmane.org>,
	Chris Ball <cjb-2X9k7bc8m7Mdnm+yROfE0A@public.gmane.org>,
	Arnd Bergmann <arnd-r2nGTMty4D4@public.gmane.org>,
	Rajendra Nayak <rnayak-l0cyMroinI0@public.gmane.org>,
	Rob Herring <rob.herring-bsGFqQB8/DxBDgjK7y7TUQ@public.gmane.org>,
	Jason Kridner <jkridner-hcmAuCOw+vXj4SYmN/TMmA@public.gmane.org>,
	Linux OMAP List
	<linux-omap-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux ARM Kernel List
	<linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org>,
	Linux DaVinci Kernel List
	<davinci-linux-open-source-VycZQUHpC/PFrsHnngEfi1aTQe2KTcn/@public.gmane.org>,
	Balaji TK <balajitk-l0cyMroinI0@public.gmane.org>,
	Linux MMC List
	<linux-mmc-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Linux Kernel Mailing List
	<linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
	Santosh Shilimkar <santosh.shilim>
Subject: Re: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
Date: Wed, 31 Jul 2013 00:05:15 -0500	[thread overview]
Message-ID: <51F89B0B.4080803@ti.com> (raw)
In-Reply-To: <51F77982.7030601-l0cyMroinI0@public.gmane.org>

On 07/30/2013 03:29 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> We certainly don't want error conditions to be cleared anywhere
> 
> 'anywhere' is a really loaded term.
> 
>> as this will make us 'forget' about missed events. We depend on
>> knowing which events were missed in order to be able to reissue them.
> 
>> This fixes a race condition where the EMR was being cleared
>> by the transfer completion interrupt handler.
>>
>> Basically, what was happening was:
>>
>>             Missed event
>>              |
>>              |
>>              V
>> SG1-SG2-SG3-Null
>>          \
>>           \__TC Interrupt (Almost same time as ARM is executing
>> TC interrupt handler, an event got missed and also forgotten
>> by clearing the EMR).
> 
> Sorry, but I dont see how edma_stop() is coming into picture in the race
> you describe?

In edma_callback function, for the case of DMA_COMPLETE (Transfer
completion interrupt), edma_stop() is called when all sets have been
processed. This had the effect of clearing the EMR.

This has 2 problems:

1.
If error interrupt is also pending and TC interrupt clears the EMR.

Due to this the ARM will execute the error interrupt even though the EMR
is clear. As a result, the following if condition in dma_ccerr_handler
will be true and IRQ_NONE is returned.

        if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
            (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
            (edma_read(ctlr, EDMA_QEMR) == 0) &&
            (edma_read(ctlr, EDMA_CCERR) == 0))
                return IRQ_NONE;

If this happens enough number of times, IRQ subsystem disables the
interrupt thinking its spurious which creates serious problems.

2.
If the above if statement condition is removed, then EMR is 0 so the
callback function will not be called in dma_ccerr_handler thus the event
is forgotten, never triggered manually or never sets missed flag of the
channel.

So about the race: TC interrupt handler executing before the error
interrupt handler can result in clearing the EMR and creates these problems.

>> The EMR is ultimately being cleared by the Error interrupt
>> handler once it is handled so we don't have to do it in edma_stop.
> 
> This, I agree with. edma_clean_channel() also there to re-initialize the
> channel so doing it in edma_stop() certainly seems superfluous.

Sure.

Thanks,

-Joel

WARNING: multiple messages have this Message-ID (diff)
From: joelf@ti.com (Joel Fernandes)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop
Date: Wed, 31 Jul 2013 00:05:15 -0500	[thread overview]
Message-ID: <51F89B0B.4080803@ti.com> (raw)
In-Reply-To: <51F77982.7030601@ti.com>

On 07/30/2013 03:29 AM, Sekhar Nori wrote:
> On Monday 29 July 2013 06:59 PM, Joel Fernandes wrote:
>> We certainly don't want error conditions to be cleared anywhere
> 
> 'anywhere' is a really loaded term.
> 
>> as this will make us 'forget' about missed events. We depend on
>> knowing which events were missed in order to be able to reissue them.
> 
>> This fixes a race condition where the EMR was being cleared
>> by the transfer completion interrupt handler.
>>
>> Basically, what was happening was:
>>
>>             Missed event
>>              |
>>              |
>>              V
>> SG1-SG2-SG3-Null
>>          \
>>           \__TC Interrupt (Almost same time as ARM is executing
>> TC interrupt handler, an event got missed and also forgotten
>> by clearing the EMR).
> 
> Sorry, but I dont see how edma_stop() is coming into picture in the race
> you describe?

In edma_callback function, for the case of DMA_COMPLETE (Transfer
completion interrupt), edma_stop() is called when all sets have been
processed. This had the effect of clearing the EMR.

This has 2 problems:

1.
If error interrupt is also pending and TC interrupt clears the EMR.

Due to this the ARM will execute the error interrupt even though the EMR
is clear. As a result, the following if condition in dma_ccerr_handler
will be true and IRQ_NONE is returned.

        if ((edma_read_array(ctlr, EDMA_EMR, 0) == 0) &&
            (edma_read_array(ctlr, EDMA_EMR, 1) == 0) &&
            (edma_read(ctlr, EDMA_QEMR) == 0) &&
            (edma_read(ctlr, EDMA_CCERR) == 0))
                return IRQ_NONE;

If this happens enough number of times, IRQ subsystem disables the
interrupt thinking its spurious which creates serious problems.

2.
If the above if statement condition is removed, then EMR is 0 so the
callback function will not be called in dma_ccerr_handler thus the event
is forgotten, never triggered manually or never sets missed flag of the
channel.

So about the race: TC interrupt handler executing before the error
interrupt handler can result in clearing the EMR and creates these problems.

>> The EMR is ultimately being cleared by the Error interrupt
>> handler once it is handled so we don't have to do it in edma_stop.
> 
> This, I agree with. edma_clean_channel() also there to re-initialize the
> channel so doing it in edma_stop() certainly seems superfluous.

Sure.

Thanks,

-Joel

  reply	other threads:[~2013-07-31  5:22 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-07-29 13:29 [PATCH 0/9] dma: edma: Support scatter-lists of any length Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
2013-07-29 13:29 ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 1/9] dma: edma: Setup parameters to DMA MAX_NR_SG at a time Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 2/9] dma: edma: Write out and handle MAX_NR_SG at a given time Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 3/9] ARM: edma: Add function to manually trigger an EDMA channel Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-30  5:18   ` Sekhar Nori
2013-07-30  5:18     ` Sekhar Nori
2013-07-30  5:18     ` Sekhar Nori
2013-07-31  4:30     ` Joel Fernandes
2013-07-31  4:30       ` Joel Fernandes
2013-07-31  4:30       ` Joel Fernandes
2013-07-31  5:23       ` Sekhar Nori
2013-07-31  5:23         ` Sekhar Nori
2013-07-31  5:23         ` Sekhar Nori
     [not found]         ` <51F89F5E.2050605-l0cyMroinI0@public.gmane.org>
2013-07-31  5:34           ` Fernandes, Joel
2013-07-31  5:34             ` Fernandes, Joel
2013-07-29 13:29 ` [PATCH 4/9] dma: edma: Find missed events and issue them Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-30  7:05   ` Sekhar Nori
2013-07-30  7:05     ` Sekhar Nori
2013-07-30  7:05     ` Sekhar Nori
2013-07-31  4:49     ` Joel Fernandes
2013-07-31  4:49       ` Joel Fernandes
2013-07-31  4:49       ` Joel Fernandes
2013-07-31  9:18       ` Sekhar Nori
2013-07-31  9:18         ` Sekhar Nori
2013-07-31  9:18         ` Sekhar Nori
2013-08-01  2:27         ` Joel Fernandes
2013-08-01  2:27           ` Joel Fernandes
2013-08-01  2:27           ` Joel Fernandes
2013-08-01  3:43           ` Joel Fernandes
2013-08-01  3:43             ` Joel Fernandes
2013-08-01  3:43             ` Joel Fernandes
2013-08-01  4:39           ` Joel Fernandes
2013-08-01  4:39             ` Joel Fernandes
2013-08-01  4:39             ` Joel Fernandes
2013-08-01  6:13           ` Sekhar Nori
2013-08-01  6:13             ` Sekhar Nori
2013-08-01  6:13             ` Sekhar Nori
2013-08-01 20:28             ` Joel Fernandes
2013-08-01 20:28               ` Joel Fernandes
2013-08-01 20:28               ` Joel Fernandes
2013-08-01 20:48               ` Joel Fernandes
2013-08-01 20:48                 ` Joel Fernandes
2013-08-01 20:48                 ` Joel Fernandes
2013-08-02 13:26               ` Sekhar Nori
2013-08-02 13:26                 ` Sekhar Nori
2013-08-02 13:26                 ` Sekhar Nori
2013-08-02 18:15                 ` Joel Fernandes
2013-08-02 18:15                   ` Joel Fernandes
2013-08-02 18:15                   ` Joel Fernandes
2013-08-02 23:00                   ` Joel Fernandes
2013-08-02 23:00                     ` Joel Fernandes
2013-08-02 23:00                     ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 5/9] dma: edma: Leave linked to Null slot instead of DUMMY slot Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 6/9] dma: edma: Detect null slot errors and handle them correctly Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 7/9] ARM: edma: Don't clear EMR of channel in edma_stop Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-30  8:29   ` Sekhar Nori
2013-07-30  8:29     ` Sekhar Nori
2013-07-30  8:29     ` Sekhar Nori
2013-07-31  5:05     ` Joel Fernandes [this message]
2013-07-31  5:05       ` Joel Fernandes
2013-07-31  5:05       ` Joel Fernandes
2013-07-31  9:35       ` Sekhar Nori
2013-07-31  9:35         ` Sekhar Nori
2013-07-31  9:35         ` Sekhar Nori
2013-08-01  1:59         ` Joel Fernandes
2013-08-01  1:59           ` Joel Fernandes
2013-08-01  1:59           ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 8/9] dma: edma: Link to dummy slot only for last SG list split Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29 ` [PATCH 9/9] dma: edma: remove limits on number of slots Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes
2013-07-29 13:29   ` Joel Fernandes

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=51F89B0B.4080803@ti.com \
    --to=joelf@ti.com \
    --cc=arnd@arndb.de \
    --cc=balajitk@ti.com \
    --cc=benoit.cousson@linaro.org \
    --cc=broonie@linaro.org \
    --cc=cjb@laptop.org \
    --cc=davinci-linux-open-source@linux.davincidsp.com \
    --cc=djbw@fb.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gururaja.hebbar@ti.com \
    --cc=jkridner@beagleboard.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=lokeshvutla@ti.com \
    --cc=matt@ohporter.com \
    --cc=nsekhar@ti.com \
    --cc=olof@lixom.net \
    --cc=r.sricharan@ti.com \
    --cc=rnayak@ti.com \
    --cc=rob.herring@calxeda.com \
    --cc=santosh.shilimkar@ti.com \
    --cc=tony@atomide.com \
    --cc=vinod.koul@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.