ar9170-fw II

ar9170-fw II

[David H. Lynch Jr.]

     I have ethernet driver experience but not wifi. I have a project to 
add some features to the ar9170 that will require additions to the 
firmware. I would appreciate pointers for docs etc. to get me started.

What is available for the ar9170 itself ?
How does the firmware and the linux driver communicate?
  Is there an overview of the firmware - what is where ?

-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: ar9170-fw II

[Christian Lamparter]

On Saturday 01 May 2010 12:19:11 David H. Lynch Jr. wrote:
> I have ethernet driver experience but not wifi. I have a project to 
> add some features to the ar9170 that will require additions to the 
> firmware. I would appreciate pointers for docs etc. to get me started.

Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
and a AR900x PHY/Radio. Therefore the phy code and registers
are very similar to those #definitions you can find in ath9k.
And for the MAC code & registers you can look into zd1211rw,
or look into drivers/staging/otus (original vendor driver,
shares some code with their windows drivers)

AFAICT, there are no technical documents about the AR9170 
solution available w/o signing a NDA with Atheros
(probably because the devices are still produced and sold in high quantities?).

> What is available for the ar9170 itself ?
> How does the firmware and the linux driver communicate?
>   Is there an overview of the firmware - what is where ?

not really, apart from the headers of the original firmware 
and vendor drivers.

But if you really need to implement some of your 'features'
(what are they, if I may ask?) into the firmware you could
save some time by migrating to carl9170 code base:
( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5 
  + linville's wireless-testing.git )

The advantages over the original firmware code (from a developers POV) are:
 * customizable/configurable fw
	+ driver can auto detect all selected fw features

 * userspace testbench ( carlu ) for the usb subsystem
   (allows you to run usb stress-test, dump the device's eeprom content
    to stdout and of course: you can implement your own routines
    and test & develop without crashing the kernel)

 * all hardware & firmware interface definitions are all located 
   in a single directory /include/shared/*.h

	version.h	- carl9170 API/ABI version
	eeprom.h	- eeprom layout
	phy.h		- AR900x PHY/Radio definitions
	fwcmd.h		- implemented firmware commands
	fwdesc.h	- layout of the firmware descriptor (e.g. available/activated features)
	hw.h		- ZD1221 MAC + (Faraday USB) definitions
		wlan.h	- (part of hw.h & phy.h) contains all the information about
				  tx & rx frame formats.

 * (tiny) printf + hexdump (obviously, you want those ;-) )

 * follows linux' kernel coding style :-D

Regards,
	Chr

Re: ar9170-fw II

[David H. Lynch Jr.]

On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>
> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> and a AR900x PHY/Radio. Therefore the phy code and registers
> are very similar to those #definitions you can find in ath9k.
> And for the MAC code&  registers you can look into zd1211rw,
> or look into drivers/staging/otus (original vendor driver,
> shares some code with their windows drivers)
>
> AFAICT, there are no technical documents about the AR9170
> solution available w/o signing a NDA with Atheros
> (probably because the devices are still produced and sold in high quantities?).
>    
     Thanks;
         I did just discover a reasonably good 150p spec. in what I 
received from my client.
         If I can I will share it. I am under an NDA, but the client 
also told me that they received no cooperation from atheros.
>> What is available for the ar9170 itself ?
>> How does the firmware and the linux driver communicate?
>>    Is there an overview of the firmware - what is where ?
>>      
> not really, apart from the headers of the original firmware
> and vendor drivers.
>
> But if you really need to implement some of your 'features'
> (what are they, if I may ask?)
     I think I can tell you what I am supposed add - I need to be able 
to provide userspace apps with precise timing information for each packet.
     Since i am working on GPL'd code and the results are going to be 
provided to third parties whatever I do is GPL'd too.
     Why gets into the NDA.

     Right now i have an NDA with a new client and though I am 
exercising care. But they seem fairly mellow. I am probably just being 
overly cautious.


> into the firmware you could
> save some time by migrating to carl9170 code base:
> ( http://www.kernel.org/pub/linux/kernel/people/chr/carl9170/1.0.5
>    + linville's wireless-testing.git )
>    
     The carl9170 code is the expected future of the ar9170 in Linux ?
     If so that is where I want to be working.
> The advantages over the original firmware code (from a developers POV) are:
>   * customizable/configurable fw
> 	+ driver can auto detect all selected fw features
>
>   * userspace testbench ( carlu ) for the usb subsystem
>     (allows you to run usb stress-test, dump the device's eeprom content
>      to stdout and of course: you can implement your own routines
>      and test&  develop without crashing the kernel)
>
>   * all hardware&  firmware interface definitions are all located
>     in a single directory /include/shared/*.h
>
> 	version.h	- carl9170 API/ABI version
> 	eeprom.h	- eeprom layout
> 	phy.h		- AR900x PHY/Radio definitions
> 	fwcmd.h		- implemented firmware commands
> 	fwdesc.h	- layout of the firmware descriptor (e.g. available/activated features)
> 	hw.h		- ZD1221 MAC + (Faraday USB) definitions
> 		wlan.h	- (part of hw.h&  phy.h) contains all the information about
> 				  tx&  rx frame formats.
>
>   * (tiny) printf + hexdump (obviously, you want those ;-) )
>
>   * follows linux' kernel coding style :-D
>    
     Thanks alot.
         I will look seriously at that.
         While I want to keep the scope of what I am doing small, and as 
narrowly confined as a I can,
     it would be nice if atleast some of my work was useful beyond the 
unique needs of my client.

> Regards,
> 	Chr
>    


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: ar9170-fw II

[Christian Lamparter]

On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
> >
> > Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
> > and a AR900x PHY/Radio. Therefore the phy code and registers
> > are very similar to those #definitions you can find in ath9k.
> > And for the MAC code&  registers you can look into zd1211rw,
> > or look into drivers/staging/otus (original vendor driver,
> > shares some code with their windows drivers)
> >
> > AFAICT, there are no technical documents about the AR9170
> > solution available w/o signing a NDA with Atheros
> > (probably because the devices are still produced and sold in high quantities?).
> >    
> Thanks;
>
> I did just discover a reasonably good 150p spec. In what I received from 
> my client. If I can I will share it. I am under an NDA, but the client also
> told me that they received no cooperation from atheros.

hmm, only 150 pages? That's sounds a bit thin, as a matter of
fact I know that the ath5k docs (rf+mac+eeprom) are at least
around 300-400 pages.

Well, we'll see. But just in case, we already have a small
library of hardware docs (but most from different vendors):
http://wireless.kernel.org/en/developers/Documentation/specs

and we would welcome such an addition ;-)

> >> What is available for the ar9170 itself ?
> >> How does the firmware and the linux driver communicate?
> >>    Is there an overview of the firmware - what is where ?
> >>      
> > not really, apart from the headers of the original firmware
> > and vendor drivers.
> >
> > But if you really need to implement some of your 'features'
> > (what are they, if I may ask?)
>
> I think I can tell you what I am supposed add - I need to be able 
> to provide userspace apps with precise timing information for each packet.
> Since i am working on GPL'd code and the results are going to be 
> provided to third parties whatever I do is GPL'd too.

if by precise timing you mean "exact mac time in TU/usecs when frame
was received at the radio", then you might have a _problem_.
You see, the firmware already receives fully packed frames from
the MAC processor and only _forwards_ them all [as is] in
one big DMA to the USB subsystem.
(this is done in src/wlan.c handle_rx())

So, unless the HW has a _magic_ flag to enable this capability...
you are sort of screwed :-/.

> Why gets into the NDA. 
> Right now i have an NDA with a new client and though I am 
> exercising care. But they seem fairly mellow. I am probably just being 
> overly cautious.
k, understood.

Re: ar9170-fw II

[Benoit Papillault]

Le 01/05/2010 22:45, Christian Lamparter a écrit :
> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>> I think I can tell you what I am supposed add - I need to be able
>> to provide userspace apps with precise timing information for each packet.
>> Since i am working on GPL'd code and the results are going to be
>> provided to third parties whatever I do is GPL'd too.
>
> if by precise timing you mean "exact mac time in TU/usecs when frame
> was received at the radio", then you might have a _problem_.
> You see, the firmware already receives fully packed frames from
> the MAC processor and only _forwards_ them all [as is] in
> one big DMA to the USB subsystem.
> (this is done in src/wlan.c handle_rx())
>
> So, unless the HW has a _magic_ flag to enable this capability...
> you are sort of screwed :-/.

I would love this feature as well. I have a device to test if that can 
help. I share the feeling of Christian however... but maybe your 
documentation says something about a special flag.

Regards,
Benoit

Re: ar9170-fw II

[David H. Lynch Jr.]

On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> Le 01/05/2010 22:45, Christian Lamparter a écrit :
>> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>>> I think I can tell you what I am supposed add - I need to be able
>>> to provide userspace apps with precise timing information for each 
>>> packet.
>>> Since i am working on GPL'd code and the results are going to be
>>> provided to third parties whatever I do is GPL'd too.
>>
>> if by precise timing you mean "exact mac time in TU/usecs when frame
>> was received at the radio", then you might have a _problem_.
>> You see, the firmware already receives fully packed frames from
>> the MAC processor and only _forwards_ them all [as is] in
>> one big DMA to the USB subsystem.
>> (this is done in src/wlan.c handle_rx())
>>
>> So, unless the HW has a _magic_ flag to enable this capability...
>> you are sort of screwed :-/.
>
> I would love this feature as well. I have a device to test if that can 
> help. I share the feeling of Christian however... but maybe your 
> documentation says something about a special flag.
    I am interested in round trip time as measured from some fixed point 
in the sending process to some fixed point in the packet acknowledgement.
    The more accurate the better. Preferably measured by events at the 
radio rather than on the linux side. I am interested in tx packets 
rather than rx packets.
     If necessary I can measure the times myself as delta's from one 
event to another withing the SH2.

     I have not digested the docs I have thoroughly yet but a cursory 
review suggests a less than trivial project.
     I have not yet found a good high resolution clock inside the ar9170 
there are alot of clocks but they all seem to be 16bit. Probably that 
will make things harder.

     I was expecting to have to make changes to the ar9170 firmware. I 
was expecting to have to devise some means of passing that information 
to the Linux driver and to the userspace application.  I would be happy 
to do that in some fashion that conformed to an existing or future 
standard, but I was not anticipating a broad desire for what I am 
doing.  Variable latencies are highly undesirable in this application, 
but the userspace application will be aggregating large amounts of 
information, if latencies in what is measured are constrained and the 
unit of time measurement is small enough everything will work.
     If it comes to that we switch to different hardware, but my project 
is bringing a concept that was demonstrated with an expensive SDR to an 
ar9170.

      I am still coming up to speed on some aspects of Wireless - I am 
not a complete noob, I have done ethernet drivers, and other very low 
level work. I have also worked with non-802.11 wireless, and network 
communications.  But three days ago I had only cursory understanding of 
how 802.11 works.

     I already greatly appreciate your assistance.



>
> Regards,
> Benoit
> -- 
> To unsubscribe from this list: send the line "unsubscribe 
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: ar9170-fw II

[Christian Lamparter]

On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
> > Le 01/05/2010 22:45, Christian Lamparter a écrit :
> >> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
> >>> I think I can tell you what I am supposed add - I need to be able
> >>> to provide userspace apps with precise timing information for each 
> >>> packet.
> >>> Since i am working on GPL'd code and the results are going to be
> >>> provided to third parties whatever I do is GPL'd too.
> >>
> >> if by precise timing you mean "exact mac time in TU/usecs when frame
> >> was received at the radio", then you might have a _problem_.
> >> You see, the firmware already receives fully packed frames from
> >> the MAC processor and only _forwards_ them all [as is] in
> >> one big DMA to the USB subsystem.
> >> (this is done in src/wlan.c handle_rx())
> >>
> >> So, unless the HW has a _magic_ flag to enable this capability...
> >> you are sort of screwed :-/.
> >
> > I would love this feature as well. I have a device to test if that can 
> > help. I share the feeling of Christian however... but maybe your 
> > documentation says something about a special flag.
>     I am interested in round trip time as measured from some fixed point 
> in the sending process to some fixed point in the packet acknowledgement.
>     The more accurate the better. Preferably measured by events at the 
> radio rather than on the linux side.

> I am interested in tx packets rather than rx packets.
ahh, well... there goes' benoit interest ;).

>      If necessary I can measure the times myself as delta's from one 
> event to another withing the SH2.
> 
>      I have not digested the docs I have thoroughly yet but a cursory 
> review suggests a less than trivial project.
>      I have not yet found a good high resolution clock inside the ar9170 
> there are alot of clocks but they all seem to be 16bit. Probably that 
> will make things harder.
TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
or equal to +/- 0.01%.

The register address are at:
 - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
 - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)

But it comes at a small price: this timer is sometimes
update & synchronized (802.11 11.1.3.4 and 11.1.4) in
station or ad-hoc mode. The exact details are hidden
inside MAC chip, but it should be possible to disable
both by selecting the monitor mode.

>      I was expecting to have to make changes to the ar9170 firmware. I 
> was expecting to have to devise some means of passing that information 
> to the Linux driver and to the userspace application.
Well, then you have two more good reasons why to use carl9170:

 * the ar9170usb driver and ar9170 firmware don't track tx frames.
   carl9170 on the other hand does (every frame has a 8 bit "cookie").
   This feature was necessary to generate an accurate tx transmission
   feedback report for every individual frame for the driver.

 * carl9170 has the ability to store additional per-frame data.
   In fact, if you don't need to have a different retry rates
   you could realloc the 3 * 32 bit "rr" (as in retry rate)
   array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
   struct (see wlan.h) for your purposes (storage for your time values).

   And if you fetched all the data, everything will be sent
   with an ordinary tx status feedback report to the application 
   (add the timer fields into carl9170_tx_status and _carl9170_tx_status
    struct - see fwcmd.h)
   
(* talked about this earlier, but you never know...

   carlu _tool_ already provides a low-level HW driver for userspace.
   This has the obvious advantage that you won't need to mess with
   the kernel driver and network stacks.

   The only work you'll have to do is: get the kernel code for
   the MAC & PHY initialization and put it into carlu.
   But the framework is already there so it's mostly copy + paste )

> I would be happy to do that in some fashion that conformed to an existing
> or future standard, but I was not anticipating a broad desire for what I am 
> doing.  Variable latencies are highly undesirable in this application, 
> but the userspace application will be aggregating large amounts of 
> information, if latencies in what is measured are constrained and the 
> unit of time measurement is small enough everything will work.
> If it comes to that we switch to different hardware, but my project 
> is bringing a concept that was demonstrated with an expensive SDR to an 
> ar9170.

It's always nice to have some "added value" for cheap and generic devices.
e.g.: Atheros AR92xx chips can be used as among other stuff as a 
      full range spectrum analyzer.

Regards,
	Chr

Re: ar9170-fw II

[David H. Lynch Jr.]

On 05/02/2010 08:52 AM, Christian Lamparter wrote:
>
>    
>>       If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>>       I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>>       I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>      
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
>   - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
>   - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update&  synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>    

     I will have to look into that it might work.
     I beleive this project is in ad-hoc mode,
     but if the timer is not being altered between the transmission of a 
packet and the receipt of its ACK I am fine,
     the worst case would be that it is and delta T becomes artificially 
smaller.  One characteristic of my problem is that
     almost all the error is positive delta T overly large.
>    
>>       I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>      
> Well, then you have two more good reasons why to use carl9170:
>
>   * the ar9170usb driver and ar9170 firmware don't track tx frames.
>     carl9170 on the other hand does (every frame has a 8 bit "cookie").
>     This feature was necessary to generate an accurate tx transmission
>     feedback report for every individual frame for the driver.
>    
    That would be necescary in my application and I have started to work 
with the carl9170 driver.
     I built the toolchain compiler the firmware and I am building a 
linux kernel right now.
>   * carl9170 has the ability to store additional per-frame data.
>     In fact, if you don't need to have a different retry rates
>     you could realloc the 3 * 32 bit "rr" (as in retry rate)
>     array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
>     struct (see wlan.h) for your purposes (storage for your time values).
>
>     And if you fetched all the data, everything will be sent
>     with an ordinary tx status feedback report to the application
>     (add the timer fields into carl9170_tx_status and _carl9170_tx_status
>      struct - see fwcmd.h)
>    
     I need a delta T between some fixed point during the send and some 
fixed point during the ACK.
     And the MAC address of the device I was sending to. The latter 
already is obviously already known, I just have to tie to it.
>
> (* talked about this earlier, but you never know...
>
>     carlu _tool_ already provides a low-level HW driver for userspace.
>     This has the obvious advantage that you won't need to mess with
>     the kernel driver and network stacks.
>
>     The only work you'll have to do is: get the kernel code for
>     the MAC&  PHY initialization and put it into carlu.
>     But the framework is already there so it's mostly copy + paste )
>    
     I beleive you are using DEBUGFS and that was already part of my spec.
     Regardless, I am comfortable on the Linux driver side.
     The closer I get to the Linux side the more comfortable I am.

     Further though the actual timing of each send's delta T needs to be 
as accurate and fine grained as possible,
     everything else in this project is non-critical.  Within reason it 
is unimportant how long it takes to propigate data from the AR9170 
through to userspace,
     Clean and simple will take precedence over any other technical demands.
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing.  Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>      
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
>        full range spectrum analyzer.
>    
     And my ability to get consulting work is strongly effected by the 
extent I can contribute to Linux.
     References, and lists of skills and qualifications on my web site 
are dwarfed by
     Dave Lynch, DLA Systems <dhlii@dlasys.net> appearing inside the 
kernel tree.

     I love this work. I love working for myself, I want to continue to 
do so.
     I would contribute as I can regardless, but self interest helps.


> Regards,
> 	Chr
>    


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: ar9170-fw II

[Luis R. Rodriguez]

On Sat, May 1, 2010 at 11:23 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
> On 05/01/2010 01:19 PM, Christian Lamparter wrote:
>>
>> Well, for starters the ar9170 uses a ZyDas MAC (aka ZD1221)
>> and a AR900x PHY/Radio. Therefore the phy code and registers
>> are very similar to those #definitions you can find in ath9k.
>> And for the MAC code&  registers you can look into zd1211rw,
>> or look into drivers/staging/otus (original vendor driver,
>> shares some code with their windows drivers)
>>
>> AFAICT, there are no technical documents about the AR9170
>> solution available w/o signing a NDA with Atheros
>> (probably because the devices are still produced and sold in high
>> quantities?).
>>
>
>    Thanks;
>        I did just discover a reasonably good 150p spec. in what I received
> from my client. If I can I will share it. I am under an NDA, but the client also told
> me that they received no cooperation from atheros.

You should be more specific. Atheros did GPL their ar9170 driver after
all, so it is in fact the first hardware vendor to ever have GPL'd
firmware for *any* device driver upstream. Releasing more docs takes
time, you are better off working directly with the upstream Atheros
developers than just subjectively claiming lack of cooperation.

  Luis

carl9170 1.0.5.1

[David H. Lynch Jr.]

     I am trying to build a kernel using the carl9170 driver/firmware.
     I am not particular about what kernel or how so long as I can get 
it running.

     When I build out of the wireless-testing git tree (puled today) 
2.6.34-rc6
     using my current systems .config I get a very quick error on boot 
about PCI bridge windows.
     googling the error indicates this is a know 2.6.34 problem and that 
there are fixes in other 2.6.34 trees.
     I have been unable to find the actual patches or I would just apply 
them to wireless-testing.

     Alternately, I tried to build out of the ubuntu-lucid git tree. 
2.6.32 again with my existing .config.
     I the carl9170 driver does not build. While I found patches at 
OpenWRT that are supposed to allow building carl9170 with 2.6.33 or less,
     the errors are unrelated to what is changed by those patches.

     I have also tried using linux-source-2.6.32 pulled from cannonical 
via apt for my install rather than the ubuntu-lucid git tree
     with similar results.

On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> On Sunday 02 May 2010 13:14:59 David H. Lynch Jr. wrote:
>    
>> On 05/02/2010 03:47 AM, Benoit Papillault wrote:
>>      
>>> Le 01/05/2010 22:45, Christian Lamparter a écrit :
>>>        
>>>> On Saturday 01 May 2010 20:23:26 David H. Lynch Jr. wrote:
>>>>          
>>>>> I think I can tell you what I am supposed add - I need to be able
>>>>> to provide userspace apps with precise timing information for each
>>>>> packet.
>>>>> Since i am working on GPL'd code and the results are going to be
>>>>> provided to third parties whatever I do is GPL'd too.
>>>>>            
>>>> if by precise timing you mean "exact mac time in TU/usecs when frame
>>>> was received at the radio", then you might have a _problem_.
>>>> You see, the firmware already receives fully packed frames from
>>>> the MAC processor and only _forwards_ them all [as is] in
>>>> one big DMA to the USB subsystem.
>>>> (this is done in src/wlan.c handle_rx())
>>>>
>>>> So, unless the HW has a _magic_ flag to enable this capability...
>>>> you are sort of screwed :-/.
>>>>          
>>> I would love this feature as well. I have a device to test if that can
>>> help. I share the feeling of Christian however... but maybe your
>>> documentation says something about a special flag.
>>>        
>>      I am interested in round trip time as measured from some fixed point
>> in the sending process to some fixed point in the packet acknowledgement.
>>      The more accurate the better. Preferably measured by events at the
>> radio rather than on the linux side.
>>      
>    
>> I am interested in tx packets rather than rx packets.
>>      
> ahh, well... there goes' benoit interest ;).
>
>    
>>       If necessary I can measure the times myself as delta's from one
>> event to another withing the SH2.
>>
>>       I have not digested the docs I have thoroughly yet but a cursory
>> review suggests a less than trivial project.
>>       I have not yet found a good high resolution clock inside the ar9170
>> there are alot of clocks but they all seem to be 16bit. Probably that
>> will make things harder.
>>      
> TSF timer could be used for this. (see 802.11-2007, Section 11 et seq.)
> It's a 2^64 bit timer with a 1us resolution and a accuracy _better_
> or equal to +/- 0.01%.
>
> The register address are at:
>   - 0x1c3514 (low, AR9170_MAC_REG_TSF_L, read only)
>   - 0x1c3518 (high, AR9170_MAC_REG_TSF_H, read only)
>
> But it comes at a small price: this timer is sometimes
> update&  synchronized (802.11 11.1.3.4 and 11.1.4) in
> station or ad-hoc mode. The exact details are hidden
> inside MAC chip, but it should be possible to disable
> both by selecting the monitor mode.
>
>    
>>       I was expecting to have to make changes to the ar9170 firmware. I
>> was expecting to have to devise some means of passing that information
>> to the Linux driver and to the userspace application.
>>      
> Well, then you have two more good reasons why to use carl9170:
>
>   * the ar9170usb driver and ar9170 firmware don't track tx frames.
>     carl9170 on the other hand does (every frame has a 8 bit "cookie").
>     This feature was necessary to generate an accurate tx transmission
>     feedback report for every individual frame for the driver.
>
>   * carl9170 has the ability to store additional per-frame data.
>     In fact, if you don't need to have a different retry rates
>     you could realloc the 3 * 32 bit "rr" (as in retry rate)
>     array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
>     struct (see wlan.h) for your purposes (storage for your time values).
>
>     And if you fetched all the data, everything will be sent
>     with an ordinary tx status feedback report to the application
>     (add the timer fields into carl9170_tx_status and _carl9170_tx_status
>      struct - see fwcmd.h)
>
> (* talked about this earlier, but you never know...
>
>     carlu _tool_ already provides a low-level HW driver for userspace.
>     This has the obvious advantage that you won't need to mess with
>     the kernel driver and network stacks.
>
>     The only work you'll have to do is: get the kernel code for
>     the MAC&  PHY initialization and put it into carlu.
>     But the framework is already there so it's mostly copy + paste )
>
>    
>> I would be happy to do that in some fashion that conformed to an existing
>> or future standard, but I was not anticipating a broad desire for what I am
>> doing.  Variable latencies are highly undesirable in this application,
>> but the userspace application will be aggregating large amounts of
>> information, if latencies in what is measured are constrained and the
>> unit of time measurement is small enough everything will work.
>> If it comes to that we switch to different hardware, but my project
>> is bringing a concept that was demonstrated with an expensive SDR to an
>> ar9170.
>>      
> It's always nice to have some "added value" for cheap and generic devices.
> e.g.: Atheros AR92xx chips can be used as among other stuff as a
>        full range spectrum analyzer.
>
> Regards,
> 	Chr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>    


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: 2.6.34-rc6 pci bridge problems

[Christian Lamparter]

On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> When I build out of the wireless-testing git tree (puled today) 
> 2.6.34-rc6 using my current systems .config I get a very quick error
> on boot about PCI bridge windows.
> googling the error indicates this is a know 2.6.34 problem and that 
> there are fixes in other 2.6.34 trees.
> I have been unable to find the actual patches or I would just apply 
> them to wireless-testing.
so? If there is already a patch available, then the linux-pci people
have to know something about it. I'm sure they can help you out there.
Just describe your problem in detail (a extensive checklist is located in
your kernel's root directory "REPORTING-BUGS" file) as a reply to this mail.

I simply can't give you any support for problems I know nothing about.
So please, concentrate your questions around this particular device and
interaction with firmware and driver. But as I said in my previous mail,
you don't need a special kernel driver. *carlu* really is a userspace-only
application that can communicate with the device (through the use of
libusb) at the "lowest level". It may be even possible to port the code to
other platforms (FreeBSD & Mac OS X, Windows) with little effort.

Regards,
	Chr

Re: carl9170 1.0.5.1

[Luis R. Rodriguez]

On Wed, May 5, 2010 at 11:41 AM, David H. Lynch Jr. <dhlii@dlasys.net> wrote:
>    I am trying to build a kernel using the carl9170 driver/firmware.
>    I am not particular about what kernel or how so long as I can get it
> running.
>
>    When I build out of the wireless-testing git tree (puled today)
> 2.6.34-rc6
>    using my current systems .config I get a very quick error on boot about
> PCI bridge windows.
>    googling the error indicates this is a know 2.6.34 problem and that there
> are fixes in other 2.6.34 trees.
>    I have been unable to find the actual patches or I would just apply them
> to wireless-testing.
>
>    Alternately, I tried to build out of the ubuntu-lucid git tree. 2.6.32
> again with my existing .config.
>    I the carl9170 driver does not build. While I found patches at OpenWRT
> that are supposed to allow building carl9170 with 2.6.33 or less,
>    the errors are unrelated to what is changed by those patches.
>
>    I have also tried using linux-source-2.6.32 pulled from cannonical via
> apt for my install rather than the ubuntu-lucid git tree
>    with similar results.

You can build the driver with compat-wireless so that way you can keep
your existing functional kernel and only backport the driver. We did
this way back when we first started doing development on ath9k and it
worked well.

  Luis

Re: 2.6.34-rc6 pci bridge problems

[Bjorn Helgaas]

On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > When I build out of the wireless-testing git tree (puled today) 
> > 2.6.34-rc6 using my current systems .config I get a very quick error
> > on boot about PCI bridge windows.
> > googling the error indicates this is a know 2.6.34 problem and that 
> > there are fixes in other 2.6.34 trees.
> > I have been unable to find the actual patches or I would just apply 
> > them to wireless-testing.

I made significant changes in the way we handle PCI bridge windows,
and I'm eager to fix any issues in that area.  But "very quick error
on boot" doesn't give me any information to work with.

Please attach your complete dmesg output, serial console log (with
"ignore_loglevel"), digital photo of the error, or other specific
details.

Bjorn

Re: 2.6.34-rc6 pci bridge problems

[Bjorn Helgaas]

On Thursday, May 06, 2010 09:09:58 am Bjorn Helgaas wrote:
> On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> > On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > > When I build out of the wireless-testing git tree (puled today) 
> > > 2.6.34-rc6 using my current systems .config I get a very quick error
> > > on boot about PCI bridge windows.
> > > googling the error indicates this is a know 2.6.34 problem and that 
> > > there are fixes in other 2.6.34 trees.
> > > I have been unable to find the actual patches or I would just apply 
> > > them to wireless-testing.
> 
> I made significant changes in the way we handle PCI bridge windows,
> and I'm eager to fix any issues in that area.  But "very quick error
> on boot" doesn't give me any information to work with.
> 
> Please attach your complete dmesg output, serial console log (with
> "ignore_loglevel"), digital photo of the error, or other specific
> details.

Ping!  If there's a problem here, I want to fix it as soon as possible.
Do you have any more details?  What error message did you google?

Thanks,
  Bjorn

Re: 2.6.34-rc6 pci bridge problems

[Christian Lamparter]

On Friday 07 May 2010 17:46:41 Bjorn Helgaas wrote:
> On Thursday, May 06, 2010 09:09:58 am Bjorn Helgaas wrote:
> > On Wednesday, May 05, 2010 01:59:55 pm Christian Lamparter wrote:
> > > On Wednesday 05 May 2010 20:41:26 David H. Lynch Jr. wrote:
> > > > When I build out of the wireless-testing git tree (puled today) 
> > > > 2.6.34-rc6 using my current systems .config I get a very quick error
> > > > on boot about PCI bridge windows.
> > > > googling the error indicates this is a know 2.6.34 problem and that 
> > > > there are fixes in other 2.6.34 trees.
> > > > I have been unable to find the actual patches or I would just apply 
> > > > them to wireless-testing.
> > 
> > I made significant changes in the way we handle PCI bridge windows,
> > and I'm eager to fix any issues in that area.  But "very quick error
> > on boot" doesn't give me any information to work with.
> > 
> > Please attach your complete dmesg output, serial console log (with
> > "ignore_loglevel"), digital photo of the error, or other specific
> > details.
> 
> Ping!  If there's a problem here, I want to fix it as soon as possible.
> Do you have any more details?  What error message did you google?

Pong! Unfortunately, I haven't heard any news about this pci bridge issue
from "David H. Lynch Jr.". But as you say: "Time for patching 2.6.34-rcX
regressions is running out". Therefore, David: please hurry up and post
what you are seeing. Most of oopses, can be easily captured with a serial
console (a setup is described in Documentation/serial-console.txt )

Regards,
	Chr

Re: ar9170-fw II

[David H. Lynch Jr.]

On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> Well, then you have two more good reasons why to use carl9170:
>   * carl9170 has the ability to store additional per-frame data.
>     In fact, if you don't need to have a different retry rates
>     you could realloc the 3 * 32 bit "rr" (as in retry rate)
>     array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
>     struct (see wlan.h) for your purposes (storage for your time values).
>
>     And if you fetched all the data, everything will be sent
>     with an ordinary tx status feedback report to the application
>     (add the timer fields into carl9170_tx_status and _carl9170_tx_status
>      struct - see fwcmd.h)
     cmd.h __check() tests for sizeof(carl9170_tx_status) != 2
     is there an assumption somewhere that carl9170_tx_status == 2 ?


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

Re: ar9170-fw II

[Christian Lamparter]

On Wednesday 12 May 2010 00:02:03 David H. Lynch Jr. wrote:
> On 05/02/2010 08:52 AM, Christian Lamparter wrote:
> > Well, then you have two more good reasons why to use carl9170:
> >   * carl9170 has the ability to store additional per-frame data.
> >     In fact, if you don't need to have a different retry rates
> >     you could realloc the 3 * 32 bit "rr" (as in retry rate)
> >     array in the carl9170_tx_superdesc and _carl9170_tx_superdesc
> >     struct (see wlan.h) for your purposes (storage for your time values).
> >
> >     And if you fetched all the data, everything will be sent
> >     with an ordinary tx status feedback report to the application
> >     (add the timer fields into carl9170_tx_status and _carl9170_tx_status
> >      struct - see fwcmd.h)
>      cmd.h __check() tests for sizeof(carl9170_tx_status) != 2
>      is there an assumption somewhere that carl9170_tx_status == 2 ?
good catch!

I have now replace some of those meaningless numerical values with
precalculated #defines *_SIZE.

This way, firmware and drivers can verify the structs sizes
and check whenever the compiler really did what it was supposed
to do.

Regards,
	Chr

carl9170 1.0.6

[David H. Lynch Jr.]

firmware_ssource/include/config.h
tests CARL9170_TX_STATUS_NUM - the number of status entries in the 
response to see if it is an even number.
Does the max number of status entries actually have to be even ?
I had to add a fill byte to tx_status to get an even result.

	> BUILD_BUG_ON(CARL9170_TX_STATUS_NUM % 2 || !CARL9170_TX_STATUS_NUM);





-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies 
toonumerous to list.

"Any intelligent fool can make things bigger and more complex... It 
takes a touch of genius - and a lot of courage to move in the opposite 
direction."
Albert Einstein

--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

carl9170 1.0.6 carl9170_tx_superdesc

[David H. Lynch Jr.]

	I need to track a new value for each tx frame only in the firmware.
	It appears I should be adding it to carl9170_tx_superdesc. But that 
structure seems to be used on both the Linux and firmware side, and I 
have not been able to successfully add to it without breaking something 
elsewhere either in the firmware or Linux driver or between them.
	Alternately I can create a private array to hold my data, but then I 
need to be able to find items in it using a carl9170_tx_superframe 
pointer. I am gathering that the cookie and queue number constitute a 
unique identifier, but that seems like alot of work to avoid adding a 
u16 to carl9170_tx_superdesc.
	Any other ideas about tracking a u16 value for each tx frame only on 
the firmware side without substantial complexity ?





-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies 
toonumerous to list.

"Any intelligent fool can make things bigger and more complex... It 
takes a touch of genius - and a lot of courage to move in the opposite 
direction."
Albert Einstein

Re: carl9170 1.0.6 carl9170_tx_superdesc

[Christian Lamparter]

On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
> I need to track a new value for each tx frame only in the firmware.
> It appears I should be adding it to carl9170_tx_superdesc.
> But that structure seems to be used on both the Linux and firmware side,
> and I have not been able to successfully add to it without breaking
> something elsewhere either in the firmware or Linux driver or between them.
there are two superdesc structures:
	carl9170_tx_superdesc and _carl9170_tx_superdesc.

This is due to the bit-field packing bug which is present
in all GCC version prior to 4.4.

Now, for the firmware we have a special toolchain and
a BUILD_BUG check, so no problem is there.

But kernel driver & userspace tools might be compiled by
an older version.

Therefore, if you want to introduce new fields, you have
to update both structures accordingly.

(And of course, always check that you're using your
 custom firmware and driver.)

> 	Alternately I can create a private array to hold my data, but then I 
> need to be able to find items in it using a carl9170_tx_superframe 
> pointer. I am gathering that the cookie and queue number constitute a 
> unique identifier, but that seems like alot of work to avoid adding a 
> u16 to carl9170_tx_superdesc.
It might not be visible at first glance, but carl9170_tx_superframe
has two distinct header descriptors.
 * ar9170_tx_hwdesc
 * carl9170_tx_superdesc

variables of those headers can not be mixed. This is because the
layout of ar9170_tx_hwdesc is dictated by the hardware design.

Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
whereas the "cookie" is intended to be used by the firmware code.
(In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV) 
 
> 	Any other ideas about tracking a u16 value for each tx frame only on 
> the firmware side without substantial complexity ?
Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
from your employer cover this subject in great detail since this is a
well-known limitation.

What you could try - on the other hand - u32.
even if you don't need the extra 2 bytes that come with this
bigger storage class.


BTW:
Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
But let me run some experiments. Just to be on the safe side.

Regards,
	Chr

Re: carl9170 1.0.6 carl9170_tx_superdesc

[David H. Lynch Jr.]

On 05/21/2010 06:55 PM, Christian Lamparter wrote:
> On Friday 21 May 2010 23:35:13 David H. Lynch Jr. wrote:
>    
>> I need to track a new value for each tx frame only in the firmware.
>> It appears I should be adding it to carl9170_tx_superdesc.
>> But that structure seems to be used on both the Linux and firmware side,
>> and I have not been able to successfully add to it without breaking
>> something elsewhere either in the firmware or Linux driver or between them.
>>      
> there are two superdesc structures:
> 	carl9170_tx_superdesc and _carl9170_tx_superdesc.
>
> This is due to the bit-field packing bug which is present
> in all GCC version prior to 4.4.
>
> Now, for the firmware we have a special toolchain and
> a BUILD_BUG check, so no problem is there.
>
> But kernel driver&  userspace tools might be compiled by
> an older version.
>
> Therefore, if you want to introduce new fields, you have
> to update both structures accordingly.
>
> (And of course, always check that you're using your
>   custom firmware and driver.)
>    
     For the moment I have found another way of resolving the issue.
     I am not concerned that there are two versions of the structures 
under Linux.
     My problem was that it appears to add a field to the firmware I 
must also add it to linux.

     During a TX I am looking to track something in firmware, and then 
return it to Linux.
     If I have this correct the carl9170_tx_superframe is passed from 
Linux to the firmware and the carl9170_tx_status is passed back to Linux.

     I do not need the extra field in carl9170_tx_superframe in Linux. i 
do need it at several different points prior to having a 
carl9170_tx_status record, in the firmware. And then I need to return 
the value to Linux in the carl9170_tx_status field.

      I am gathering that whether I need or not that 
carl9170_tx_superframe must match perfectly between Linux and the 
firmware. And there is no other per packet data being managed in the 
firmware.

     My second problem is that even after adding it to both sides and 
adjusting for all the alignment and other issues, I end up with 
something that does not work.
      I am being careful to keep the driver and firmware aligned. I 
grasp that is an issue.


>    
>> 	Alternately I can create a private array to hold my data, but then I
>> need to be able to find items in it using a carl9170_tx_superframe
>> pointer. I am gathering that the cookie and queue number constitute a
>> unique identifier, but that seems like alot of work to avoid adding a
>> u16 to carl9170_tx_superdesc.
>>      
> It might not be visible at first glance, but carl9170_tx_superframe
> has two distinct header descriptors.
>   * ar9170_tx_hwdesc
>   * carl9170_tx_superdesc
>
> variables of those headers can not be mixed. This is because the
> layout of ar9170_tx_hwdesc is dictated by the hardware design.
>
> Therefore the queue number goes into ar9170_tx_hwdesc.mac.QoS,
> whereas the "cookie" is intended to be used by the firmware code.
> (In fact, carl9170_tx_superdesc is _hidden_ from the hardware POV)
>
>    
>> 	Any other ideas about tracking a u16 value for each tx frame only on
>> the firmware side without substantial complexity ?
>>      
> Erm, adding a single u16 is a bad idea. I'm pretty sure that the documents
> from your employer cover this subject in great detail since this is a
> well-known limitation.
>    
     Pardon my sensitivity, but I am a consultant. I have clients not 
employers.
     The parts of the AR9170 spec I have read do not address this, but I 
have not read everything thoroughly.
     My project deals almost exclusively with timing. And I am trying 
not to touch things I do not need to.


> What you could try - on the other hand - u32.
> even if you don't need the extra 2 bytes that come with this
> bigger storage class.
>    
         I may need to do that anyway. 25ns * 65K is 1.6ms before 
overflow, that is almost too short.

>
> BTW:
> Yes, the (CARL9170_TX_STATUS_NUM % 2) check can be safely disabled now.
> But let me run some experiments. Just to be on the safe side.
>    
     Thanks.

> Regards,
> 	Chr
>    


-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

carl9170 1.0.9

[David H. Lynch Jr.]

	
some items I have found while making my changes to the code.


	In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF 
timer to make sure there is no roll over. According to the docs I have 
when TSF_LOW is read, TSF_HI is automatically concurrently copied to a 
temp register so that an immediate read of TSF_HI will get the value 
that was present when TSF_LO was read.

	Presuming the docs are correct - and this feature is common in 
multi-word timers you should be able to save some code.
	Also with some complex casting or another pointer you can read directly 
to your destination and save a memcpy()

	I beleive the timer_init() routine in carlfw/src/timer.c can not be 
called for more than one timer. Any subsequent call will clear the 
interrupt and mode bits for the previous timer.

	I have not completely tracked these down, but the new config system 
must be missing some dependencies, because I can configure and build 
firmware that will not load.
	In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with 
CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.



-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies 
toonumerous to list.

"Any intelligent fool can make things bigger and more complex... It 
takes a touch of genius - and a lot of courage to move in the opposite 
direction."
Albert Einstein

Re: carl9170 1.0.9

[Christian Lamparter]

On Saturday 22 May 2010 21:13:50 David H. Lynch Jr. wrote:
> 
> some items I have found while making my changes to the code.
patches are welcome :-D

> 	In firmware_source/carlfw/src/wlan.c you have aloop to read the TSF 
> timer to make sure there is no roll over. According to the docs I have 
> when TSF_LOW is read, TSF_HI is automatically concurrently copied to a 
> temp register so that an immediate read of TSF_HI will get the value 
> that was present when TSF_LO was read.
Thanks for that clarification. The code in question was actually a
adaptation from ar9170_op_get_tsf (patch author included in CC).

Since this is now settled, I made the necessary chances to the
kernel driver as well. (with a reference to your previous mail)

> 	I beleive the timer_init() routine in carlfw/src/timer.c can not be 
> called for more than one timer. Any subsequent call will clear the 
> interrupt and mode bits for the previous timer.

there's more than that.
Take a look at the (timer << 2) and so forth...

> 	I have not completely tracked these down, but the new config system 
> must be missing some dependencies, because I can configure and build 
> firmware that will not load.
> 	In carlfw/src/cmd.c the CARL9170_CMD_PSM case needs ifdef'd with 
> CONFIG_CARL9170FW_PSM or it will not build with PSM disabled.
> 
fixed.

Thanks for your comments. I've just released 1.0.9.1, which
contains fixes for all of your comments and some additional changes.


BTW:
> I have been playing with the assorted timers in the ar9170.
> My preliminary observations seem to be indicating that
> AR9170_TIMER_REG_TIMER0 might actually be running at 40mhz/25ns,
> But that all the other timers seem to be running far slower - i.e. 
> maybe they are cascaded of the overflow on timer0.
>
> I have specifically looked at timer1-4 and tic_timer and clock_low 
> and they all seem to be running very slow.
> The docs that I have imply but do not state that all these clocks 
> are directly off the 25ns/40mhz superH clock.
> Have you had any experience with the clocks and their rates ?

based on observation: Some timers(1-4) are *driven* by the cpu clock.
Which is of course determined by the operation mode and phy band.
As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
 * 40MHz (refclock)
 * 20MHz (PSM, 5GHz) & 22MHz (PSM, 2.4GHz)
 * 40MHz (11an, 5GHz, HT20) & 44Mhz (11bgn, 2.4GHz, HT20)
 * 80MHz (11an, 5GHz, HT40) & 88MHz (11bgn, 2.4GHz, HT40)

Regards,
	Chr

Re: carl9170 1.0.9

[David H. Lynch Jr.]

On 05/22/2010 09:34 PM, Christian Lamparter wrote:
>> 	I beleive the timer_init() routine in carlfw/src/timer.c can not be
>> called for more than one timer. Any subsequent call will clear the
>> interrupt and mode bits for the previous timer.
>>      
> there's more than that.
> Take a look at the (timer<<  2) and so forth...
>    
     The control and interrupt registers are bitmasks.
     When you set the bit for the current timer you are clearing all the 
others.
> based on observation: Some timers(1-4) are *driven* by the cpu clock.
> Which is of course determined by the operation mode and phy band.
> As you know there are 7 (1 + 2 * 3) possible AHB/CPU clock settings:
>   * 40MHz (refclock)
>   * 20MHz (PSM, 5GHz)&  22MHz (PSM, 2.4GHz)
>   * 40MHz (11an, 5GHz, HT20)&  44Mhz (11bgn, 2.4GHz, HT20)
>   * 80MHz (11an, 5GHz, HT40)&  88MHz (11bgn, 2.4GHz, HT40)
>    
     Thanks I have been working alot more with the timers today.
     TSF follows the docs and is 1us.
     My docs say that CCR is 25ns and only 16 bit.
     But your code and that of the original ar9710-fw has it as 2 16 bit 
registers making 32bits.
     I have verified that and verified that it is pretty close to 25ns. 
in my system.

     But the remainder of the timers seem to be much much slower. My dos 
do not specify that they are tied to anything specific.

     I tripped over the AHB/CPU clock in the code. I need to look much 
more thoroughly at that, and I am going to need to work out exactly how 
it effects the other timers. I need the fastest timer I can get for my 
application.

     Thanks alot.

     i will pull 1.0.9.1 shortly








-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein

carl9170 1.0.9.1

[David H. Lynch Jr.]

     When I was attempting to push my ll_temac driver, I was told to use 
dev_err(), dev_warn(), and dev_info() rather than printk(KERN_XXXX. I 
beleive the ar9170 driver already in the kernel tree is doing that. I 
beleive these I tend to create DBG(), ERR() and WARN() macros, because 
during debugging I have been known to reroute the error handling through 
a uart or some other debug port - kind of like you are printf'ing 
through USB in the firmware. Putting it in a macro makes global changes 
easier. Though I think heavy use of macros is now frowned on.

     Just my .02




-- 
Dave Lynch 					  	    DLA Systems
Software Development:  				         Embedded Linux
717.587.7774 	       dhlii@dlasys.net 	  http://www.dlasys.net
Over 25 years' experience in platforms, languages, and technologies too numerous to list.

"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein