Question about iwl_pcie_rxq_inc_wr_ptr

Question about iwl_pcie_rxq_inc_wr_ptr

[Stanislaw Gruszka]

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().

Stanislaw 

RE: [Ilw] Question about iwl_pcie_rxq_inc_wr_ptr

[Grumbach, Emmanuel]

> 
> 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?

Re: [Ilw] Question about iwl_pcie_rxq_inc_wr_ptr

[Stanislaw Gruszka]

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

RE: [Ilw] Question about iwl_pcie_rxq_inc_wr_ptr

[Grumbach, Emmanuel]

> 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.
> 
I see... I am sorry to tell you that I can't be sure on the exact consequences, but I am pretty sure that it is not a good idea to do that...