Question about iwl_pcie_rxq_inc_wr_ptr
I would like to ask if below change is safe (I'm considering to do that change on iwlegacy):
drivers/net/wireless/iwlwifi/pcie/rx.c +1 -1
@@ -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
Quoted 20 lines
I would like to ask if below change is safe (I'm considering to do that change on iwlegacy):
drivers/net/wireless/iwlwifi/pcie/rx.c +1
-1@@ -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); }}
Quoted 3 lines
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?
Quoted 20 lines · Emmanuel
Quoted 20 lines
I would like to ask if below change is safe (I'm considering to do that change on iwlegacy):
drivers/net/wireless/iwlwifi/pcie/rx.c +1
-1@@ -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); }}
Quoted 7 lines
Quoted 3 lines
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
Quoted 38 lines · Emmanuel
Quoted 20 lines
Quoted 20 lines
I would like to ask if below change is safe (I'm considering to do that change on iwlegacy):
drivers/net/wireless/iwlwifi/pcie/rx.c +1
-1@@ -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); }}
Quoted 2 lines
Quoted 2 lines
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().Quoted 4 lines
Quoted 1 line
I am not sure...
I am not sure what would be the behavior: not updating the value at all, orhaving the HW use an old value for a while.
Quoted 1 line
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
Quoted 6 lines
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 removegrab_nic_accessfrom 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...