[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[kang haiyang]

hi,

  i saw some configurations in this file, but don't know the function of
them.
  Where can i found the document about them,  and are they hardware
independent?
  i mean that they are valid for all board with the corresponding radio
chip.

best regards,
kang haiyang

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Adrian Chadd]

On 10 May 2011 22:26, kang haiyang <hykang@dongniannetworks.com> wrote:
> hi,
>
> ?i saw some configurations in this file, but don't know the function of
> them.
> ?Where can i found the document about them, ?and are they hardware
> independent?
> ?i mean that they are valid for all board with the corresponding radio
> chip.

The ini values are register values written to the hardware to set it
up for use. This way there doesn't need to be a lot more code which
individually sets up all of those registers.

There's a bunch of different init values:

* Modes - the values which change based on the operating mode (a, bg,
na/40, ng/40, etc)
* Common - common register values which don't depend upon the operating mode
* BankX - for the older chips, they're involved with setting up the radio
* Addac - something radio/baseband ? I'm not sure.
* RFGain - setting up the baseband RF gain registers

There are other tables, such as Merlin rx and tx gain.

Yes, the initialisation values can be chip dependent. Some registers
won't be (eg the examples below should be be the same for all chips)
but there's plenty of register settings which are specific to a
particular mac/radio.

In terms of in-depth public documentation, you're not going to get a
lot of it. The stuff in Modes and Common are straight registers - the
first column is the register, the second (and later) values are
register contents. If the register name is defined in reg.h then you
can (partially) decode what the fields mean.

Eg from ar5008_initvals.h:

        {0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160,
0x000001e0},
        {0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c,
0x000001e0},

0x1030 is AR_D_GBL_IFS_SIFS, and you can see from the other related
#defines that the lower four bits are the SIFS duration. If you look
at the code which writes to that register, you can see its in clocks,
rather than microseconds. So different values are needed based on
operating mode; 11b is 22mhz, 11g is 44mhz, 11a is 40mhz for non-fast
clock and 44mhz for fast-clock, it's double that for HT/40 modes.

0x1070 is AR_D_GBL_IFS_SLOT; same deal - lower four bits are the slot
duration in clock cycles. Same reason why they're different based on
operating mode.

Take a look at ar5008_hw_process_ini() to see how they're written to
the hardware.

HTH,


Adrian

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Mohammed Shafi]

On Tue, May 10, 2011 at 7:56 PM, kang haiyang
<hykang@dongniannetworks.com> wrote:
> hi
>
> ?i saw some configurations in this file, but don't know the function of
> them.

those are to be configured in hw for initialization of device (ath9k_hw_init)

> ?Where can i found the document about them, ?and are they hardware
> independent?

most of them are internal docs.

> ?i mean that they are valid for all board with the corresponding radio
> chip.

we have for ar9002 families

>
> best regards,
> kang haiyang
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Mohammed Shafi]

On Tue, May 10, 2011 at 8:54 PM, Adrian Chadd <adrian@freebsd.org> wrote:
> On 10 May 2011 22:26, kang haiyang <hykang@dongniannetworks.com> wrote:
>> hi,
>>
>> ?i saw some configurations in this file, but don't know the function of
>> them.
>> ?Where can i found the document about them, ?and are they hardware
>> independent?
>> ?i mean that they are valid for all board with the corresponding radio
>> chip.
>
> The ini values are register values written to the hardware to set it
> up for use. This way there doesn't need to be a lot more code which
> individually sets up all of those registers.
>
> There's a bunch of different init values:
>
> * Modes - the values which change based on the operating mode (a, bg,
> na/40, ng/40, etc)
> * Common - common register values which don't depend upon the operating mode
> * BankX - for the older chips, they're involved with setting up the radio
> * Addac - something radio/baseband ? I'm not sure.
> * RFGain - setting up the baseband RF gain registers
>
> There are other tables, such as Merlin rx and tx gain.
>
> Yes, the initialisation values can be chip dependent. Some registers
> won't be (eg the examples below should be be the same for all chips)
> but there's plenty of register settings which are specific to a
> particular mac/radio.
>
> In terms of in-depth public documentation, you're not going to get a
> lot of it. The stuff in Modes and Common are straight registers - the
> first column is the register, the second (and later) values are
> register contents. If the register name is defined in reg.h then you
> can (partially) decode what the fields mean.
>
> Eg from ar5008_initvals.h:
>
> ? ? ? ?{0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160,
> 0x000001e0},
> ? ? ? ?{0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c,
> 0x000001e0},
>
> 0x1030 is AR_D_GBL_IFS_SIFS, and you can see from the other related
> #defines that the lower four bits are the SIFS duration. If you look
> at the code which writes to that register, you can see its in clocks,
> rather than microseconds. So different values are needed based on
> operating mode; 11b is 22mhz, 11g is 44mhz, 11a is 40mhz for non-fast
> clock and 44mhz for fast-clock, it's double that for HT/40 modes.
>
> 0x1070 is AR_D_GBL_IFS_SLOT; same deal - lower four bits are the slot
> duration in clock cycles. Same reason why they're different based on
> operating mode.
>
> Take a look at ar5008_hw_process_ini() to see how they're written to
> the hardware.

Adrian,
        thanks a lot for the explanation. no one better explain more than this.

regards,
shafi

>
> HTH,
>
>
> Adrian
> _______________________________________________
> ath9k-devel mailing list
> ath9k-devel at lists.ath9k.org
> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[kang haiyang]

Thanks you all.  Great explanations.

On 05/10/2011 11:35 PM, Mohammed Shafi wrote:
> On Tue, May 10, 2011 at 8:54 PM, Adrian Chadd <adrian@freebsd.org> wrote:
>> On 10 May 2011 22:26, kang haiyang <hykang@dongniannetworks.com> wrote:
>>> hi,
>>>
>>>  i saw some configurations in this file, but don't know the function of
>>> them.
>>>  Where can i found the document about them,  and are they hardware
>>> independent?
>>>  i mean that they are valid for all board with the corresponding radio
>>> chip.
>> The ini values are register values written to the hardware to set it
>> up for use. This way there doesn't need to be a lot more code which
>> individually sets up all of those registers.
>>
>> There's a bunch of different init values:
>>
>> * Modes - the values which change based on the operating mode (a, bg,
>> na/40, ng/40, etc)
>> * Common - common register values which don't depend upon the operating mode
>> * BankX - for the older chips, they're involved with setting up the radio
>> * Addac - something radio/baseband ? I'm not sure.
>> * RFGain - setting up the baseband RF gain registers
>>
>> There are other tables, such as Merlin rx and tx gain.
>>
>> Yes, the initialisation values can be chip dependent. Some registers
>> won't be (eg the examples below should be be the same for all chips)
>> but there's plenty of register settings which are specific to a
>> particular mac/radio.
>>
>> In terms of in-depth public documentation, you're not going to get a
>> lot of it. The stuff in Modes and Common are straight registers - the
>> first column is the register, the second (and later) values are
>> register contents. If the register name is defined in reg.h then you
>> can (partially) decode what the fields mean.
>>
>> Eg from ar5008_initvals.h:
>>
>>        {0x00001030, 0x00000230, 0x00000460, 0x000002c0, 0x00000160,
>> 0x000001e0},
>>        {0x00001070, 0x00000168, 0x000002d0, 0x00000318, 0x0000018c,
>> 0x000001e0},
>>
>> 0x1030 is AR_D_GBL_IFS_SIFS, and you can see from the other related
>> #defines that the lower four bits are the SIFS duration. If you look
>> at the code which writes to that register, you can see its in clocks,
>> rather than microseconds. So different values are needed based on
>> operating mode; 11b is 22mhz, 11g is 44mhz, 11a is 40mhz for non-fast
>> clock and 44mhz for fast-clock, it's double that for HT/40 modes.
>>
>> 0x1070 is AR_D_GBL_IFS_SLOT; same deal - lower four bits are the slot
>> duration in clock cycles. Same reason why they're different based on
>> operating mode.
>>
>> Take a look at ar5008_hw_process_ini() to see how they're written to
>> the hardware.
> Adrian,
>         thanks a lot for the explanation. no one better explain more than this.
>
> regards,
> shafi
>
>> HTH,
>>
>>
>> Adrian
>> _______________________________________________
>> ath9k-devel mailing list
>> ath9k-devel at lists.ath9k.org
>> https://lists.ath9k.org/mailman/listinfo/ath9k-devel
>>

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Peter Stuge]

Mohammed Shafi wrote:
> Adrian,
> thanks a lot for the explanation. no one better explain more than this.

My disappointment is fundamentally because of these things needing to
be reverse engineered outside Atheros, *despite* you guys being on
this list.

It is in a way deeply disrespectful, but my guess is rather that some
legal department really doesn't dare let developers do open source
"for real."

Don't worry. From what I read Intel is doing worse. They communicate
more, but with no significant content. They seem to have lots of
serious problems.

Another don't worry. I'm about to switch to a new computer. I'll get
a shiny new AR9380 for it, and give ath9k another go on what must be
a less broken PCI bus than the one in my current system.

I am particularly interested in the adaptive power management behavior.
I can't help to maintain small hope, but on the other hand I do not
dare to assume that it will work in Linux, and the card is too new for
FreeBSD; still much reverse engineering of older ones that remains.

Did I mention how I hate that it seems to *always* be neccessary to
reverse engineer things to make them work halfway decently?

Last don't worry. Rant ends here. :)


Kind regards

//Peter

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Adrian Chadd]

On 11 May 2011 09:08, Peter Stuge <peter@stuge.se> wrote:

> My disappointment is fundamentally because of these things needing to
> be reverse engineered outside Atheros, *despite* you guys being on
> this list.

Who says I'm reverse engineering everything now? :-)

> It is in a way deeply disrespectful, but my guess is rather that some
> legal department really doesn't dare let developers do open source
> "for real."

You'd be very, very surprised. Atheros can and are liasing with open
source developers. It's happening. I'm standing up here and saying
"Hi, Atheros is providing me with what I need to get the job done."
:-)

> Another don't worry. I'm about to switch to a new computer. I'll get
> a shiny new AR9380 for it, and give ath9k another go on what must be
> a less broken PCI bus than the one in my current system.

> I am particularly interested in the adaptive power management behavior.
> I can't help to maintain small hope, but on the other hand I do not
> dare to assume that it will work in Linux, and the card is too new for
> FreeBSD; still much reverse engineering of older ones that remains.

I understand your frustration - and as for FreeBSD and AR9300/AR9400
support (and the other missing chips for that matter), it'll grow
support for it, but only after I finish my exams and once I've
finished off the basic 11n support and fixing bugs in the currently
supported chips. Yup, this includes AR5416/AR5418, blergh. :)

But Peter, make no mistake, you may not see it here (yet), but Atheros
can and is helping out open source developers. It isn't as bad as you
think.



Adrian

[ath9k-devel] Question about ar9002_initvals.h file in ath9k driver

[Ben Greear]

On 05/10/2011 06:08 PM, Peter Stuge wrote:
> Mohammed Shafi wrote:
>> Adrian,
>> thanks a lot for the explanation. no one better explain more than this.

> Don't worry. From what I read Intel is doing worse. They communicate
> more, but with no significant content. They seem to have lots of
> serious problems.

Intel NICs can't do all the clever virtualization that Atheros
5k and 9k can, so what fun would they be anyway :)

>
> Another don't worry. I'm about to switch to a new computer. I'll get
> a shiny new AR9380 for it, and give ath9k another go on what must be
> a less broken PCI bus than the one in my current system.

The AR9380 NIC (sparklan 127N) I just started testing on 39-rc7-wl has been very
solid..once we fixed a few regressions that popped into the 39-wl
tree.

And, haven't seen any of those scary DMA splats either..I think Felix
and others must have finally squished that bug!

And, aside from one dodgy Ubiquity NIC, various other ath9k
cards have been working well too.

So, hopefully you'll start having better luck as well...

Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com