2009/1/6 Maxim Levitsky <maximlevit...@gmail.com>:
>
> Glad to hear that.
>
> That what I meant btw, that this is related to phy (or radio as they
> call it)
>
>
> The chip that is on aspire one seems to be AR5007EG
> which consist of AR5212 (mac) and AR2425 (phy,radio,analog part..)
>

I have such a chip from an eeepc and it works fine here (only the rate
problem you also report), your reset problem probably has to do with
phy calibration and various enviromental issues or other card related
issues (not chip related) that we haven't worked on yet. The way i see
it this is the issue here, not the tx performance. Your reset problem
is something new...

>
> Btw while reading the sources I find that it might be worth to put part
> specific code in separate parts, it is hard to understand, and on top of
> that there are many different versions for different chipsets, so what
> do you think.
>

These parts are not that different, it's easier to maintain the code
this way, helps you have a bigger picture and keeps the whole code
updated. If you see HAL sources they are full of duplicated code and
you can see that some parts are more frequently updated than others,
it's a mess trust me. Our code also supports 5211 for example (and i
get full 27Mbits) without having to maintain a separate directory,
different rfregs functions and reset sequence (eg. RF5111 is used also
with 5212 chips) etc. The fact is that there are very few differences
and all of them are commented on the code and handled fine (only some
5210 stuff is missing but it's a really old chip and it's not a
priority right now). Various PHY versions have some differences but we
also handle them fine with this design.

> Btw, the hal although opensource contains so many 'magic numbers', it
> hardly describes any registers there, and there is an intial register
> dump that isn't documented at all.
>

The initial register dump is nothing weird, it's just the default set
of settings to get the card working, check out initvals.c, we try to
make it easier than hal to understand what's going on. Some parts are
really low level, there are some registers that aren't documented and
eg some tables that are just filled with increasing numbers etc but it
doesn't affect us, we only know that we have to write this thing
during reset and it works ;-) Rf registers are even worse (you won't
find anything on rf registers, not even Atheros's TLAs have docs on
that) but we still are fine as long as these settings work (and i've
verified that their ndis driver is doing the same thing). I'll do an
update on initvals and phy.c to follow legacy-hal and sam's hal but
it's not a priority right now (tests have shown that initvals are fine
-we took them from binary hal and ndis driver via rev. engineering
anyway-).

Our hw problems right now are to fix PHY stuff (tx power calibration
and rf regs update), then make a few other fixes, update reset
sequence and put ANI support (and then fix 5210 support and move on
with other things). It'll take some time but it's on the way.

> So I would suggest (but this might be large work, to create a central
> table for each chip and document all known registers there, like a
> name/description for known regs, and 'working values'/different values
> for different modes for unknown ones, maybe even create a wiki, so dumps
> form different drivers might be put there.
>

We are doing this already on reg.h, eeprom.h and initvals.c, we can't
put the whole documentation on the driver, what we have right now is
enough to work with. If you want something more specific you can
always ask.

> It just that speed issues like I was worried are connected to wrong
> setup of the phy, and with little documentation it is hard to to know
> what to do
>

We now know what we have to do, only a few questions remain and i
expect Atheros to answer them soon so i can go on and finish tx power
stuff asap. They 've already provided help with ANI issues etc so no
problem there. It's just a matter of time...

-- 
GPG ID: 0xD21DB2DB
As you read this post global entropy rises. Have Fun ;-)
Nick
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel

Reply via email to