public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Dave Jiang <dave.jiang@intel.com>
To: Dan Williams <djbw@fb.com>
Cc: "vinod.koul@intel.com" <vinod.koul@intel.com>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 09/10] ioatdma: Adding write back descriptor error status support for ioatdma 3.3
Date: Tue, 26 Mar 2013 16:55:16 -0700	[thread overview]
Message-ID: <51523564.30605@intel.com> (raw)
In-Reply-To: <84A937D219C2B44EB8EA44831ACA1E49171F50DF@PRN-MBX01-3.TheFacebook.com>

On 03/26/2013 04:47 PM, Dan Williams wrote:
>
> On 3/26/13 3:43 PM, "Dave Jiang" <dave.jiang@intel.com> wrote:
>
>> v3.3 provides support for write back descriptor error status. This allows
>> reporting of errors in a descriptor field. In supporting this, certain
>> errors such as P/Q validation errors no longer halts the channel. The DMA
>> engine can continue to execute until the end of the chain and allow
>> software
>> to report the "errors" up the stack. We are also going to mask those error
>> interrupts and handle them when the "chain" has completed at the end.
>>
>> Signed-off-by: Dave Jiang <dave.jiang@intel.com>
>> ---
>> drivers/dma/ioat/dma_v3.c    |   87
>> ++++++++++++++++++++++++++++++++++++------
>> drivers/dma/ioat/hw.h        |   17 +++++++-
>> drivers/dma/ioat/registers.h |    1
>> 3 files changed, 90 insertions(+), 15 deletions(-)
>>
>> diff --git a/drivers/dma/ioat/dma_v3.c b/drivers/dma/ioat/dma_v3.c
>> index 230a8bc..83d44f3 100644
>> --- a/drivers/dma/ioat/dma_v3.c
>> +++ b/drivers/dma/ioat/dma_v3.c
>> @@ -498,6 +498,32 @@ static bool ioat3_cleanup_preamble(struct
>> ioat_chan_common *chan,
>> 	return true;
>> }
>>
>> +static void desc_get_errstat(struct ioat_ring_ent *desc)
>> +{
>> +	struct ioat_dma_descriptor *hw = desc->hw;
>> +
>> +	switch (hw->ctl_f.op) {
>> +	case IOAT_OP_PQ_VAL:
>> +	case IOAT_OP_PQ_VAL_16S:
>> +	{
>> +		struct ioat_pq_descriptor *pq = desc->pq;
>> +
>> +		/* check if there's error written */
>> +		if (!pq->dwbes_f.wbes)
>> +			return;
>> +
>> +		if (pq->dwbes_f.p_val_err)
>> +			*desc->result |= SUM_CHECK_P_RESULT;
>> +
>> +		if (pq->dwbes_f.q_val_err)
>> +			*desc->result |= SUM_CHECK_Q_RESULT;
>> +		return;
>> +	}
>> +	default:
>> +		return;
>> +	}
>> +}
>> +
>> /**
>>   * __cleanup - reclaim used descriptors
>>   * @ioat: channel (ring) to clean
>> @@ -535,6 +561,10 @@ static void __cleanup(struct ioat2_dma_chan *ioat,
>> dma_addr_t phys_complete)
>> 		prefetch(ioat2_get_ring_ent(ioat, idx + i + 1));
>> 		desc = ioat2_get_ring_ent(ioat, idx + i);
>> 		dump_desc_dbg(ioat, desc);
>> +
>> +		/* set err stat if we are using dwbes */
>> +		desc_get_errstat(desc);
>> +
>> 		tx = &desc->txd;
>> 		if (tx->cookie) {
>> 			dma_cookie_complete(tx);
>> @@ -580,14 +610,15 @@ static void ioat3_cleanup(struct ioat2_dma_chan
>> *ioat)
>> {
>> 	struct ioat_chan_common *chan = &ioat->base;
>> 	u64 phys_complete;
>> +	u32 chanerr;
>>
>> 	spin_lock_bh(&chan->cleanup_lock);
>>
>> 	if (ioat3_cleanup_preamble(chan, &phys_complete))
>> 		__cleanup(ioat, phys_complete);
>>
>> +	chanerr = readl(chan->reg_base + IOAT_CHANERR_OFFSET);
>> 	if (is_ioat_halted(*chan->completion)) {
>> -		u32 chanerr = readl(chan->reg_base + IOAT_CHANERR_OFFSET);
>>
>> 		if (chanerr & IOAT_CHANERR_HANDLE_MASK) {
>> 			mod_timer(&chan->timer, jiffies + IDLE_TIMEOUT);
> This is now incurring a mmio read for every cleanup which somewhat defeats
> the point of posting the completion status to memory.  Should be able to
> get away with just writel(IOAT_CHANERR_HANDLE_MASK) iff cleanup found came
> across an error-writeback.
Ok I'll fix that.

>
>
>> @@ -595,6 +626,15 @@ static void ioat3_cleanup(struct ioat2_dma_chan
>> *ioat)
>> 		}
>> 	}
>>
>> +	/*
>> +	 * with DWBES we must clear the chanerr register at the end of the
>> +	 * chain in order to be able to issue the next command.
>> +	 */
>> +	if (chanerr) {
>> +		writel(chanerr & IOAT_CHANERR_HANDLE_MASK,
>> +		       chan->reg_base + IOAT_CHANERR_OFFSET);
>> +	}
>> +
>   Does this also mean we need to re-write dmacount?  I.e. are writes to
> dmacount ignored while chanerr is non-zero?
>
I don't believe so. At least that hasn't been an issue with testing. I 
have asked them to remove that "feature" with future silicon.

  reply	other threads:[~2013-03-26 23:55 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-26 22:42 [PATCH 00/10] Add Intel Atom S1200 seris ioatdma support Dave Jiang
2013-03-26 22:42 ` [PATCH 01/10] ioatdma: Adding PCI IDs for Intel Atom S1200 product family ioatdma devices Dave Jiang
2013-03-26 22:42 ` [PATCH 02/10] ioatdma: Add 64bit chansts register read for ioat v3.3 Dave Jiang
2013-03-26 22:42 ` [PATCH 03/10] ioatdma: channel reset scheme fixup on Intel Atom S1200 platforms Dave Jiang
2013-03-26 22:42 ` [PATCH 04/10] ioatdma: Removing hw bug workaround for CB3.x .2 and earlier Dave Jiang
2013-03-26 22:42 ` [PATCH 05/10] ioatdma: skip legacy reset bits since v3.3 plattform doesn't need it Dave Jiang
2013-03-26 22:43 ` [PATCH 06/10] ioatdma: Removing PQ val disable for cb3.3 Dave Jiang
2013-03-27 18:48   ` Dan Williams
2013-03-29 17:31     ` Dave Jiang
2013-03-26 22:43 ` [PATCH 07/10] ioatdma: skip silicon bug workaround for pq_align " Dave Jiang
2013-03-26 22:43 ` [PATCH 08/10] ioatdma: Adding support for 16 src PQ ops and super extended descriptors Dave Jiang
2013-03-26 22:43 ` [PATCH 09/10] ioatdma: Adding write back descriptor error status support for ioatdma 3.3 Dave Jiang
2013-03-26 23:47   ` Dan Williams
2013-03-26 23:55     ` Dave Jiang [this message]
2013-03-28 22:25     ` [PATCH 09/10 v2] " Jiang, Dave
2013-03-26 22:43 ` [PATCH 10/10] ioatdma: S1200 platforms ioatdma channel 2 and 3 falsely advertise RAID cap Dave Jiang
2013-04-09  7:28 ` [PATCH 00/10] Add Intel Atom S1200 seris ioatdma support Vinod Koul
2013-04-10  0:56   ` Dan Williams
     [not found]   ` <CAA9_cmftcvYN_g0Sj12tMa4T8LxbPdk6wDxwkbTrgQPUUfc0FA@mail.gmail.com>
2013-04-10  5:00     ` Vinod Koul
2013-04-10  5:10       ` Vinod Koul
2013-04-10  5:33       ` Jiang, Dave

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=51523564.30605@intel.com \
    --to=dave.jiang@intel.com \
    --cc=djbw@fb.com \
    --cc=linux-kernel@vger.kernel.org \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox