[ath9k-devel] ath5k tx completion

[ath9k-devel] ath5k tx completion

[Adrian Chadd]

On 6 November 2013 05:41, Bob Copeland <me@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

[ath9k-devel] ath5k tx completion

[Bob Copeland]

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

> * 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? :)

-- 
Bob Copeland %% www.bobcopeland.com

[ath9k-devel] ath5k tx completion

[Adrian Chadd]

On 7 November 2013 06:20, Bob Copeland <me@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

[ath9k-devel] ath5k tx completion

[Peter Stuge]

Adrian Chadd wrote:
> 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.

Many thanks for that.


//Peter

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

2013/11/7 Adrian Chadd <adrian@freebsd.org>:
> On 7 November 2013 06:20, Bob Copeland <me@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 at 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Adrian Chadd]

On 9 November 2013 05:40, Nick Kossifidis <mickflemm@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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Bob Copeland]

On Sat, Nov 09, 2013 at 07:54:31AM -0800, Adrian Chadd wrote:
> On 9 November 2013 05:40, Nick Kossifidis <mickflemm@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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

2013/11/9 Bob Copeland <me@bobcopeland.com>:
> On Sat, Nov 09, 2013 at 07:54:31AM -0800, Adrian Chadd wrote:
>> On 9 November 2013 05:40, Nick Kossifidis <mickflemm@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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Bob Copeland]

On Sat, Nov 09, 2013 at 05:55:00PM +0000, Nick Kossifidis wrote:
> Are you ok to go for this period (December - March) or the next one
> (June - September) ?

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

On 09/11/13 19:14, Bob Copeland wrote:
> On Sat, Nov 09, 2013 at 05:55:00PM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Sarah Sharp]

On Mon, Feb 24, 2014 at 10:19:20AM +0000, Nick Kossifidis wrote:
> On 09/11/13 19:14, Bob Copeland wrote:
> > On Sat, Nov 09, 2013 at 05:55:00PM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Adrian Chadd]

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.sharp@intel.com> wrote:
> On Mon, Feb 24, 2014 at 10:19:20AM +0000, Nick Kossifidis wrote:
>> On 09/11/13 19:14, Bob Copeland wrote:
>> > On Sat, Nov 09, 2013 at 05:55:00PM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

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 <adrian@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.sharp@intel.com> wrote:
>> On Mon, Feb 24, 2014 at 10:19:20AM +0000, Nick Kossifidis wrote:
>>> On 09/11/13 19:14, Bob Copeland wrote:
>>> > On Sat, Nov 09, 2013 at 05:55:00PM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Adrian Chadd]

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 <mickflemm@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 <adrian@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.sharp@intel.com> wrote:
>>> On Mon, Feb 24, 2014 at 10:19:20AM +0000, Nick Kossifidis wrote:
>>>> On 09/11/13 19:14, Bob Copeland wrote:
>>>> > On Sat, Nov 09, 2013 at 05:55:00PM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Bob Copeland]

On Tue, Feb 25, 2014 at 09:23:38AM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

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 <me@bobcopeland.com>:
> On Tue, Feb 25, 2014 at 09:23:38AM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Adrian Chadd]

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 <mickflemm@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 <me@bobcopeland.com>:
>> On Tue, Feb 25, 2014 at 09:23:38AM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Sarah Sharp]

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 <mickflemm@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 <me@bobcopeland.com>:
> >> On Tue, Feb 25, 2014 at 09:23:38AM +0000, 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

[ath9k-devel] [ath5k-devel] ath5k tx completion

[Nick Kossifidis]

2013/11/9 Adrian Chadd <adrian@freebsd.org>:
> On 9 November 2013 05:40, Nick Kossifidis <mickflemm@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