Re: [ath5k-devel] ath5k tx completion
Hi, I've just created AdrianChadd. Please go forth and add me to the relevant bits. :P -a On 26 February 2014 01:50, Nick Kossifidis mickfl...@gmail.com wrote: So will you edit the OPW wiki (http://kernelnewbies.org/OPWIntro) or should I do it ? I've already added a project description for AR5513 support and added me and Adrian as mentors. You can create an account on http://kernelnewbies.org and talk with Sarah to get edit access and invitations to the relevant mailing lists ;-) 2014-02-25 12:24 GMT+00:00 Bob Copeland m...@bobcopeland.com: On Tue, Feb 25, 2014 at 09:23:38AM +, Nick Kossifidis wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Yes, I'm happy to mentor for power saving. -- Bob Copeland %% www.bobcopeland.com -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On Wed, Feb 26, 2014 at 09:37:14AM -0800, Adrian Chadd wrote: Hi, I've just created AdrianChadd. Please go forth and add me to the relevant bits. :P Adrian, you should have edit access now. Bob, can you make an account and send me your username? Sarah On 26 February 2014 01:50, Nick Kossifidis mickfl...@gmail.com wrote: So will you edit the OPW wiki (http://kernelnewbies.org/OPWIntro) or should I do it ? I've already added a project description for AR5513 support and added me and Adrian as mentors. You can create an account on http://kernelnewbies.org and talk with Sarah to get edit access and invitations to the relevant mailing lists ;-) 2014-02-25 12:24 GMT+00:00 Bob Copeland m...@bobcopeland.com: On Tue, Feb 25, 2014 at 09:23:38AM +, Nick Kossifidis wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Yes, I'm happy to mentor for power saving. -- Bob Copeland %% www.bobcopeland.com -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Is anyone interested in working on DFS ? 2014-02-25 5:30 GMT+00:00 Adrian Chadd adr...@freebsd.org: I'm happy to be a mentor for the AR5523 support. Who knows, I may end up learning how the hardware works! I'll see if I can dig up my AR5523 and get the basic probe/attach working. -a On 24 February 2014 10:39, Sarah Sharp sarah.a.sh...@intel.com wrote: On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
sorry, I meant AR5513. :-P And I can help with DFS, but since the spec changed after the 11n chips came out, it's going to be hard to make a spec-compliant DFS implementation for the pre-11n chips. The short pulses and the chirps are the two things these chips have no real chance of handling well.. -a On 25 February 2014 01:23, Nick Kossifidis mickfl...@gmail.com wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Is anyone interested in working on DFS ? 2014-02-25 5:30 GMT+00:00 Adrian Chadd adr...@freebsd.org: I'm happy to be a mentor for the AR5523 support. Who knows, I may end up learning how the hardware works! I'll see if I can dig up my AR5523 and get the basic probe/attach working. -a On 24 February 2014 10:39, Sarah Sharp sarah.a.sh...@intel.com wrote: On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On Tue, Feb 25, 2014 at 09:23:38AM +, Nick Kossifidis wrote: That should be fun ! Have in mind there is already a driver (STA only) included since 3.8 - http://wireless.kernel.org/en/users/Drivers/ar5523 so probe/attach should be fine. Bob are you still interested in power saving stuff ? Yes, I'm happy to mentor for power saving. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
I'm happy to be a mentor for the AR5523 support. Who knows, I may end up learning how the hardware works! I'll see if I can dig up my AR5523 and get the basic probe/attach working. -a On 24 February 2014 10:39, Sarah Sharp sarah.a.sh...@intel.com wrote: On Mon, Feb 24, 2014 at 10:19:20AM +, Nick Kossifidis wrote: On 09/11/13 19:14, Bob Copeland wrote: On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. Hello all, So the application period for the next OPW round starts tomorrow, I'm CCing Sarah Sharp who is coordinating things to let you know about the details in case anyone else is interested. I'm already in on AR5513 support and we can also go for power saving, tx completion etc stuff (Bob ?) and more. It sounds like Luis might be interested in volunteering to be a mentor too. Looks like there are plenty of ath5k/ath9k project ideas, so it would be fine to have multiple mentors (or have two people co-mentor an intern). Bob and Adrian, if you're interested in being an OPW mentor, please take a look at this page: http://kernelnewbies.org/OPWMentor As Nick mentioned, the application period opens tomorrow (Feb 25th), and continues until March 19th. After that interns will be selected, and the internships will run from May 19th to August 19th. If anyone is interested in being a mentor with Nick, let me know and I'll start the process of subscribing you to lists, etc. Nick, can you update http://kernelnewbies.org/OPWIntro with a project description for the AR5513 support? I'd like to at least have that project description in place before the application period starts. Thanks, Sarah Sharp ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
2013/11/7 Adrian Chadd adr...@freebsd.org: On 7 November 2013 06:20, Bob Copeland m...@bobcopeland.com wrote: On Wed, Nov 06, 2013 at 09:17:46AM -0800, Adrian Chadd wrote: The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is a goldmine -- thank you for taking the time to write it up! I believe we can clean up ath5k's transmit loop a lot now... You're very welcome. I spent quite a lot of time waist deep in this crap. It turns out I had to go to the hardware guys and wade through the verilog to figure out what the hell was actually going on. * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked One thing at a time for me... but do we even want to know? :) If you want to avoid crazy crashes and hangs, yes? :) Also, ask me about key cache corruption too. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm planing to submit ar5513 support and ar5210 fixes there and mentor (for the next period -June to September-). -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 9 November 2013 05:40, Nick Kossifidis mickfl...@gmail.com wrote: Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm happy to provide guidance for the technical / chip side of things, sure. I'm planing to submit ar5513 support and ar5210 fixes there and mentor (for the next period -June to September-). Cool! I hope you beat me to ar5513 support. The HAL is sufficiently different that even bringing it up on the latest madwifi or freebsd requires a lot of manual love. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On Sat, Nov 09, 2013 at 07:54:31AM -0800, Adrian Chadd wrote: On 9 November 2013 05:40, Nick Kossifidis mickfl...@gmail.com wrote: Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm happy to provide guidance for the technical / chip side of things, sure. Sounds intriguing -- yes I'd consider formally mentoring such a project. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
2013/11/9 Adrian Chadd adr...@freebsd.org: On 9 November 2013 05:40, Nick Kossifidis mickfl...@gmail.com wrote: Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm happy to provide guidance for the technical / chip side of things, sure. I'm planing to submit ar5513 support and ar5210 fixes there and mentor (for the next period -June to September-). Cool! I hope you beat me to ar5513 support. The HAL is sufficiently different that even bringing it up on the latest madwifi or freebsd requires a lot of manual love. Thanks m8 ! The idea is to allocate some time to study the code and any related docs (if you have any please share, I'll ping Atheros too), come up with a plan (especially for the PHY/RF part) and be prepared to mentor on the next period, that is June to September 2014. I know it's far away from now but I don't have any time to work on this at the moment and I don't want to risk any bad mentoring, plus we'll have hw by that time (Pavel already offered to help on this) and all that's needed. Where do you plan on working on this for FreeBSD ? -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
2013/11/9 Bob Copeland m...@bobcopeland.com: On Sat, Nov 09, 2013 at 07:54:31AM -0800, Adrian Chadd wrote: On 9 November 2013 05:40, Nick Kossifidis mickfl...@gmail.com wrote: Adrian/Bob, these fixes (along with power saving etc) are very interesting projects and I was thinking to submit them in OPW (http://kernelnewbies.org/OPWIntro). Are you interested in mentoring (http://kernelnewbies.org/OPWMentor) ? I'm happy to provide guidance for the technical / chip side of things, sure. Sounds intriguing -- yes I'd consider formally mentoring such a project. Cool ! Are you ok to go for this period (December - March) or the next one (June - September) ? -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On Sat, Nov 09, 2013 at 05:55:00PM +, Nick Kossifidis wrote: Are you ok to go for this period (December - March) or the next one (June - September) ? From the site it looks a little late for this term (looks like final selection is just a few days away) -- but June would be better anyway. -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 7 November 2013 06:20, Bob Copeland m...@bobcopeland.com wrote: On Wed, Nov 06, 2013 at 09:17:46AM -0800, Adrian Chadd wrote: The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is a goldmine -- thank you for taking the time to write it up! I believe we can clean up ath5k's transmit loop a lot now... You're very welcome. I spent quite a lot of time waist deep in this crap. It turns out I had to go to the hardware guys and wade through the verilog to figure out what the hell was actually going on. * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked One thing at a time for me... but do we even want to know? :) If you want to avoid crazy crashes and hangs, yes? :) Also, ask me about key cache corruption too. -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
[ath5k-devel] ath5k tx completion
Hi Adrian (and anyone else who wants to chime in), I'm looking to fix some accounting issues in the ath5k tx path, which arise because we always try to keep one descriptor available at the end for the hardware's sake. I believe you have some concrete, hard-won knowledge about when the hardware marks a descriptor complete versus when the 'next' pointer in the descriptor is accessed -- do you mind sharing? -- Bob Copeland %% www.bobcopeland.com ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
Re: [ath5k-devel] ath5k tx completion
On 6 November 2013 05:41, Bob Copeland m...@bobcopeland.com wrote: Hi Adrian (and anyone else who wants to chime in), I'm looking to fix some accounting issues in the ath5k tx path, which arise because we always try to keep one descriptor available at the end for the hardware's sake. I believe you have some concrete, hard-won knowledge about when the hardware marks a descriptor complete versus when the 'next' pointer in the descriptor is accessed -- do you mind sharing? Sure! The TL;DR version - you need to keep the the final descriptor around for each hardware queue. The legacy madwifi/freebsd way of doing it was to keep the last descriptor that was handled. This wasn't enough. It needs to be per TX queue. You also must never program TxDP after you've programmed it once - you can only program it again after you've completely torn down TX DMA for the particular queue. This is relevant for ath5k _and_ ath9k chips! The long version: The DMA engine follows the TX descriptor link list to process things. Once it finishes a descriptor, it'll read the link descriptor pointer to see what the next descriptor is. If it's NULL, it'll keep the address of the link pointer around so it can re-read it when it needs to start DMA again. The reason for this is because TX DMA can restart at any time for any reason. It can be gated by timers, by beacon reception, by burst / ready time, etc; it can be pre-empted by traffic from a higher priority queue. It stores this per QCU, so you need to store the last descriptor per QCU, rather than just the last it handled. Now, since the intended use case is that software will just write to the link pointer if there's a new packet to transmit, it needs to be handled in an atomic way. So, here are the conditions: * no transmit, no past transmit. TxDP[n] is 0x0. It's never transmitted anything before. You queue a frame to TxDP[n], set TxE[n] to 1, and it starts. * transmit is going on, TxDP[n] is non-NULL. You add something to the link pointer and then you set TxE[n] to 1 to kick things along. The DMA engine was NOT already sending the final frame in the queue to the air, so it'll just keep reading the list as normal. * transmit is going on, TxDP[n] is non-NULL and it points to the last frame. You sneak in an update to the link pointer before the hardware completes the frame, tickle TxE[n] and the hardware will keep going. * transmit is going on, TxDP[n] is non-NULL and it points to the last frame. It fnishes it, reads the NULL pointer, sees its NULL, stops transmitting. You update the link pointer, tickle TxE[n], but .. and here's the problem. So to make the last option work, the only sane way is for the hardware to re-read the link pointer to see if it's updated. It'll then always do the right thing - if it's just read a NULL link pointer it'll re-read it to see the updated value and continue transmitting. The _other_ option (which i think freebsd/madwifi did) was to just update link pointer and write a new TxDP before transmitting. The TDMA code in FreeBSD did this. Now this would also get around the race, right? If you hit the end of the list and it hit NULL, then you write a new TxDP[n] and set TxE to 1, it should start the new list, right? Then, comes the weird crap' I found when digging through the RTL (chip source.) There are erm, situations where the chip won't actually process a TxDP update. Thus, even if you write a new TxDP out, even if the hardware is not transmitting, it may ignore the write. This is why I took the time in FreeBSD to do this: * staging descriptor is now per-QCU; * if i've never transmitted before, I will update TxDP * otherwise, if I've transmitted before, I will always append a frame to the transmit queue by adding it to the last descriptor (and if this is a done staging descriptor, so be it), and poke TxE[n] This works really, really well. Now for the ath9k relevant bits! All the ath9k chips behave the same. Even the EDMA chips. So, for EDMA, you _can_ just queue one frame per TX FIFO slot. You don't have the above behaviour. However, if you queue multiple frames to a TX FIFO slot (_not_ A-MPDU frames, but say, you append 15 frames to the cabq or 15 non-aggregate frames to a normal data queue by appending 15 frames to one TX FIFO entry, rather than one frame per FIFO entry) then the same behaviour as above may occur. You still need to keep a staging descriptor around whilst you're processing TX completions, as TX completions are per-frame, _not_ per TX FIFO slot. Once you've processed the whole slot, you don't need to keep the staging descriptor around for the next slot. FreeBSD does this for TX EDMA descriptor handling. I hope this clears things up! Next - ask me about: * read-and-clear bugs * PHY register read problems, and why ANI may occasionally look whacked -adrian ___ ath5k-devel mailing list ath5k-devel@lists.ath5k.org
