[ath9k-devel] AR9220: how do I wake it up? :)

[ath9k-devel] AR9220: how do I wake it up? :)

[Adrian Chadd]

Hi all,

I'm trying to make the AR9220 work under FreeBSD but I get all manner
of strange 0xdeadc0de's in from register reads.

[ath9k-devel] AR9220: how do I wake it up? :)

[Adrian Chadd]

For posterity, it turns out to be the AR_AN_TOP2 patch.

Found here:

https://patchwork.kernel.org/patch/90926/

Would someone mind letting me know what this particular fix does and
why it's needed?



adrian

On 22 January 2011 00:53, Adrian Chadd <adrian@freebsd.org> wrote:
> Hi all,
>
> I'm trying to make the AR9220 work under FreeBSD but I get all manner
> of strange 0xdeadc0de's in from register reads.
>
> From my understanding of things, I'm guessing the chip or parts of the
> chip haven't been woken up.
>
> The AR9280 support works (for values of "work") in FreeBSD, so I'm
> thinking the local code is missing a couple of relevant register
> settings to enable the thing.
>
> Does anyone know off-hand what I may need to glimpse at to make it
> work? What's different between the AR9280 and AR9220 initialisation
> sequences? I couldn't see anything AR9220 specific in ath9k.
>
> Thanks,
>
>
> Adrian
>

[ath9k-devel] AR9220: how do I wake it up? :)

[Adrian Chadd]

Also, reading from AR_PHY_DAG_CTRLCCK (0xA228, defined in
ar5212/ar5212.h) causes a bus error. Does this register mean anything
on chips > AR5212, and why would it be causing a bus error on the
AR9280 but not the AR9220? (or is it, but my AR9280 NIC, being in an
i386 eeepc, isn't causing a fatal bus exception.)

Thanks again, and sorry for the non-linux noise. :)


adrian

[ath9k-devel] AR9220: how do I wake it up? :)

[Pavel Roskin]

On 01/21/2011 12:09 PM, Adrian Chadd wrote:
> For posterity, it turns out to be the AR_AN_TOP2 patch.
>
> Found here:
>
> https://patchwork.kernel.org/patch/90926/
>
> Would someone mind letting me know what this particular fix does and
> why it's needed?

There is a lot of data written to the chip.  Most of it is the same for 
the same chip revision, but some bits need to be different based on the 
EEPROM contents or on whether the device is connected to PCIe or PCI bus.

I don't know much about the meaning of that bit.  My patch only changes 
the way the fixup is applied.  Instead of modifying the common table 
that is shares between all devices, the bit is changed when the data is 
written to the register.  This allows peaceful coexistence of the 
devices with different EEPROM in the same system.

My patch also was a step towards declaring the init tables constant, but 
there is another fixup for AR9160 that is harder to fix.  I never had 
time to do the later.

-- 
Regards,
Pavel Roskin

[ath9k-devel] AR9220: how do I wake it up? :)

[Adrian Chadd]

On 22 January 2011 01:53, Pavel Roskin <proski@gnu.org> wrote:

>> Would someone mind letting me know what this particular fix does and
>> why it's needed?

> I don't know much about the meaning of that bit. ?My patch only changes the
> way the fixup is applied. ?Instead of modifying the common table that is
> shares between all devices, the bit is changed when the data is written to
> the register. ?This allows peaceful coexistence of the devices with
> different EEPROM in the same system.

Yup. I saw that's why you did it. I was just wondering what the
particular value in the EEPROM means.

> My patch also was a step towards declaring the init tables constant, but
> there is another fixup for AR9160 that is harder to fix. ?I never had time
> to do the later.

I'm thinking of doing the same to the FreeBSD HAL. I may take a copy
of the init tables rather than a reference to them. Then they can be
fiddled as needed.

There's another eeprom value base fix to the AR9160 code which I
haven't yet put into the freebsd HAL (some baseband bias level) which
also fiddles with an ini array (a radio init one.) That also needs to
be fixed for similar reasons. I wonder if ath9k does the same.


Adrian

[ath9k-devel] AR9220: how do I wake it up? :)

[Pavel Roskin]

On 01/22/2011 07:28 AM, Adrian Chadd wrote:
> On 22 January 2011 01:53, Pavel Roskin<proski@gnu.org>  wrote:
>
>>> Would someone mind letting me know what this particular fix does and
>>> why it's needed?
>
>> I don't know much about the meaning of that bit.  My patch only changes the
>> way the fixup is applied.  Instead of modifying the common table that is
>> shares between all devices, the bit is changed when the data is written to
>> the register.  This allows peaceful coexistence of the devices with
>> different EEPROM in the same system.
>
> Yup. I saw that's why you did it. I was just wondering what the
> particular value in the EEPROM means.

It has something to do with the bus clock.

>> My patch also was a step towards declaring the init tables constant, but
>> there is another fixup for AR9160 that is harder to fix.  I never had time
>> to do the later.
>
> I'm thinking of doing the same to the FreeBSD HAL. I may take a copy
> of the init tables rather than a reference to them. Then they can be
> fiddled as needed.
>
> There's another eeprom value base fix to the AR9160 code which I
> haven't yet put into the freebsd HAL (some baseband bias level) which
> also fiddles with an ini array (a radio init one.) That also needs to
> be fixed for similar reasons. I wonder if ath9k does the same.

Perhaps you misread my words.  I believe ath9k still needs to be fixed 
with regard to AR9160 fixups.

As for the copying, it's probably a very high cost if only a few values 
need to be adjusted.  I'd rather go with a list of values to adjust. 
Initialization is not performance critical (as long as we are not 
talking about tenths of a second or more), but embedded systems may be 
short on memory.

-- 
Regards,
Pavel Roskin