On Tue, 2009-01-06 at 02:50 +0200, Nick Kossifidis wrote:
> 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...
I agree with you, and I have nothing against current code, I just would
like to see all 5112 specific functions moved into a seperate file, and
common functions can live where they are now.
Like having a file that contains all 5112 init values, functions that
set specific settings in it, etc...
Same for ar2425, also a file with its specific functions.
when newer part uses functions that are same as old part, then leave the
function in the oldest device for that function, and so on.
Current driver is broken by parts it interfaces , which is also nice,
but it is a bit difficult to see many versions of same function, and
find which one is used.
Anyway it isn't that importaint, I just want to tell you big thanks, and
thanks again.
Best regards,
Maxim Levitsky
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
