linux-wireless.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Alban Browaeys <prahal@yahoo.com>
To: Ivo van Doorn <ivdoorn@gmail.com>
Cc: Pavel Roskin <proski@gnu.org>,
	John Linville <linville@tuxdriver.com>,
	rt2x00 Users List <users@rt2x00.serialmonkey.com>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	Gertjan van Wingerde <gwingerde@gmail.com>,
	Josef Bacik <josef@redhat.com>
Subject: Re: [PATCH 1/2] rt2x00 : hw support txdone implementation. (without fallback change)
Date: Fri, 26 Feb 2010 00:37:19 +0100	[thread overview]
Message-ID: <4B8709AF.70001@yahoo.com> (raw)
In-Reply-To: <201002252146.22846.IvDoorn@gmail.com>

On 25/02/2010 21:46, Ivo van Doorn wrote:
> Hi,
>
> Overall this patch has great similarities to something which Josef (CC added)
> has posted earlier. The patch in question was not merged due to some issues,
> but he is working on an updated. You might want to synchronize your work
> with him. :)
>
>    
The patch :
http://article.gmane.org/gmane.linux.kernel.wireless.general/46713

if so it has nothing in common. The patch from benoit papillault you 
rejected a year ago due to
another part of the patch that was modifying the meaning of the fallback 
flag si the one I am reworking.
I just removed this fallback part.

Also it relies on DMA<number> interrupt which are triggered even if the 
packet is rejected
by the hw engine. Only tx_sta_fifo triggered tells the thing was sent in 
the end.
So it ignores the errors from the hw, tells success always to mac layer and
  remove any sanity check about the packet descriptor.

With this one there is no way to tell success, failure, fallback or else.
A DMA<number> interrupt without TX_STA_FIFO to follow it means an 
incorrect txdesc.
Uses to be padding issues. COuld also be wrong headroom calculation in 
write_tx_desc.


If we handle txdone in DMA<number> interrupts we are killing any chances 
to get status (success, failure).


The other TBTT fix is indeed a great step in the right direction (I 
ignored beacons issues for a long time
as  not top priority and as I knew few about it but it is a great fix :
http://article.gmane.org/gmane.linux.kernel.wireless.general/42949

Both of those patches were not sent to the rt2x00 ML so I missed them.


>>>> +	for (i=0; i<256; i++) {
>>>>
>>>>          
>>> checkpatch.pl complains about spacing.  There should be spaces around
>>> "=" and"<"
>>>        
> Also I prefer the:
> 	while (!rt2x00queue_empty(queue)) {
>
> version from Josef's patch.
>    

Note that this one construct requires to use DMA<number> interrupt to 
call txdone.
I should not go this way knowing that it prevents any success/failure 
status handling.
Also I found a year ago that emptying the queue at each packet 
processing is killing packets.
We tag as unsuccessfull packets that have not yet been acknowledged by a 
tx sta fifo status (as dma<number> interrupts
and adhoc tx sta fifo interrupt are not synchronized).


>>>> +		rt2x00_desc_read(txwi, 1,&word);
>>>> +		tx_wcid = rt2x00_get_field32(word, TXWI_W1_WIRELESS_CLI_ID);
>>>> +		tx_ack  = rt2x00_get_field32(word, TXWI_W1_ACK);
>>>> +		tx_pid  = rt2x00_get_field32(word, TXWI_W1_PACKETID);
>>>> +
>>>> +		if ((wcid != tx_wcid) || (ack != tx_ack) || (pid != tx_pid))
>>>> +			WARNING(rt2x00dev, "invalid TX_STA_FIFO content\n");
>>>>
>>>>          
>>> Can we make this sanity check optional?
>>>
>>>
>>>        
>> Is this a showstopper ? Do you mean only enabling this message telling
>> something totally
>> unexpected happened in debug mode ? The sanity of the queue is pretty
>> critical for operation.
>>      
> I don't think this should be a showstopper, in fact how often would this error be printed?
> Is it regularly, like the rt61pci bug where not all TX done events were raised, or is it really
> a very rare case?
>
>    

It should never happens except while hacking the driver and making 
mistake in the descriptor writing or such.
Which well happens in the development process . Or for testers.


BR
Alban

      parent reply	other threads:[~2010-02-25 23:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-25  4:19 [PATCH 1/2] rt2x00 : hw support txdone implementation. (without fallback change) Alban Browaeys
2010-02-25 17:22 ` Gertjan van Wingerde
2010-02-25 18:54   ` Alban Browaeys
2010-02-25 17:48 ` Pavel Roskin
2010-02-25 19:34   ` Alban Browaeys
2010-02-25 20:21     ` Pavel Roskin
2010-02-25 23:56       ` Alban Browaeys
2010-02-25 20:46     ` Ivo van Doorn
2010-02-25 20:53       ` Josef Bacik
2010-02-26  1:21         ` Alban Browaeys
2010-02-25 23:37       ` Alban Browaeys [this message]

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=4B8709AF.70001@yahoo.com \
    --to=prahal@yahoo.com \
    --cc=gwingerde@gmail.com \
    --cc=ivdoorn@gmail.com \
    --cc=josef@redhat.com \
    --cc=linux-wireless@vger.kernel.org \
    --cc=linville@tuxdriver.com \
    --cc=proski@gnu.org \
    --cc=users@rt2x00.serialmonkey.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;
as well as URLs for NNTP newsgroup(s).