All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stanislaw Gruszka <sgruszka@redhat.com>
To: "Grumbach, Emmanuel" <emmanuel.grumbach@intel.com>
Cc: "ilw@linux.intel.com" <ilw@linux.intel.com>,
	"linux-wireless@vger.kernel.org" <linux-wireless@vger.kernel.org>
Subject: Re: [Ilw] Question about iwl_pcie_rxq_inc_wr_ptr
Date: Mon, 19 Aug 2013 12:33:00 +0200	[thread overview]
Message-ID: <20130819103300.GA10723@redhat.com> (raw)
In-Reply-To: <0BA3FCBA62E2DC44AF3030971E174FB301A2954B@HASMSX103.ger.corp.intel.com>

On Mon, Aug 19, 2013 at 09:32:58AM +0000, Grumbach, Emmanuel wrote:
> > 
> > I would like to ask if below change is safe (I'm considering to do that change
> > on iwlegacy):
> > 
> > diff --git a/drivers/net/wireless/iwlwifi/pcie/rx.c
> > b/drivers/net/wireless/iwlwifi/pcie/rx.c
> > index 567e67a..1ebdb83 100644
> > --- a/drivers/net/wireless/iwlwifi/pcie/rx.c
> > +++ b/drivers/net/wireless/iwlwifi/pcie/rx.c
> > @@ -183,7 +183,7 @@ static void iwl_pcie_rxq_inc_wr_ptr(struct iwl_trans
> > *trans, struct iwl_rxq *q)
> >  		} else {
> >  			/* Device expects a multiple of 8 */
> >  			q->write_actual = (q->write & ~0x7);
> > -			iwl_write_direct32(trans, FH_RSCSR_CHNL0_WPTR,
> > +			iwl_write32(trans, FH_RSCSR_CHNL0_WPTR,
> >  				q->write_actual);
> >  		}
> >  	}
> > 
> > This register seems to be only read by firmware, so maybe we can modify it
> > without grab nic access. We are doing that on iwl_pcie_txq_inc_wr_ptr().
> > 
> 
> I am not sure...
> I am not sure what would be the behavior: not updating the value at all, or having the HW use an old value for a while.
> Does this cost you so much CPU that it justifies such a change?

I have those bug reports:

https://bugzilla.redhat.com/show_bug.cgi?id=863386
https://bugzilla.redhat.com/show_bug.cgi?id=889467
https://bugzilla.redhat.com/show_bug.cgi?id=895650
https://bugzilla.redhat.com/show_bug.cgi?id=989025

All are 4965 specific - I haven't seen similar traces on iwlwifi. On
some cases use nohz=off boot option helped with the problem, so this
could be also some kernel issue when udelay() is not working as
expected. Anyway I'm considering to remove grab_nic_access from that
path and would like to know possible consequences from firmware
perspective.

Stanislaw

  reply	other threads:[~2013-08-19 10:32 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-02  8:42 Question about iwl_pcie_rxq_inc_wr_ptr Stanislaw Gruszka
2013-08-19  9:32 ` [Ilw] " Grumbach, Emmanuel
2013-08-19 10:33   ` Stanislaw Gruszka [this message]
2013-08-19 10:34     ` Grumbach, Emmanuel

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=20130819103300.GA10723@redhat.com \
    --to=sgruszka@redhat.com \
    --cc=emmanuel.grumbach@intel.com \
    --cc=ilw@linux.intel.com \
    --cc=linux-wireless@vger.kernel.org \
    /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.