Hi,
>> Hi,
>>
>> > Hi Wojciech,
>> >
>> >>> Hi all,
>> >>>
>> >>> I am trying to switch from madwifi to ath5k on AR2315 WiSoC (Fon
>> >>> 2100A) using patches from Wojciech and Felix but at module
>> loading
>> >>> the
>> >>> driver is not able to attach the HW. In particular it seems that
>> >>> ath5k
>> >>> is not capable to recognize the right mac/phy version/revision in
>> the
>> >>> ath5k_hw_init()
>> >>>
>> >>> ath5k phy0: Couldn't identify radio revision.
>> >>> ar231x-wmac ar231x-wmac.0: failed to attach device, err=-19
>> >>>
>> >>> I am not sure about the right values for these fields and so I
>> used
>> >>> the ones I obtained from madwifi-r3314
>> >>>
>> >>> ah_devid 0x86
>> >>> ah_subvendorid 0x168c
>> >>> ah_macVersion 0xb
>> >>> ah_macRev 0x0
>> >>> ah_phyRev 0x48
>> >>> ah_analog5GhzRev 0x70
>> >>>
>> >>> but now the driver hangs in ath5k_hw_post() because it seems it
>> is
>> >>> not
>> >>> able to write correctly in the defined registers.
>> >>
>> >> Can you check what ath5k_hw_read_srev(ah) (or
>> ath5k_bus_read_srev(ah))
>> >> reads from board configuration? It has be valid because we cannot
>> read
>> >> registers until we reset and we need to know srev already before.
>> >>
>> >
>> > From ath5k_bus_read_srev() I obtain:
>> >
>> > ath5k_hw_init[143]: ah->ah_mac_srev 0x86 ah->ah_version 0x2
>> > ath5k_hw_init[159]: ah->ah_mac_version 0x8 ah->ah_mac_revision
>> 0x6
>> > ath5k_hw_init[169]: ah->ah_phy_revision 0x1 ah->ah_phy 0x9800
>> > ah->ah_radio_5ghz_revision 0x0
>> >
>>
>> obviously I printed these values before the switch statement in
>> ath5k_hw_init()
>
> To me it looks like the reset doesn't work. I have looked through
> madwifi driver and documentation and the only thing which comes to
> my mind is to add and extra line to reset function.
Unfortunately it does not fix the issue :(
> At least documentation says that hardware can become confused if
> you don't read non-WMAC register immediately before and immediately
> after reset register write when you do warm reset without performing
> cold one. It says so for older chipsets so I am not sure it's necessary.
> At least it seems to work without on my AR5312 system.
>
> Otherwise the sequence looks almost exactly like in madwifi i.e.
>
> -setup ahb arbitration (AR2316 and up specific)
> -setup wmac byteswapping on ahb (AR2316 and up specific)
> -wakeup wmac through pci (AR2316 and up specific)
> -reset baseband and mac
> -wakeup chip
> -reset chip again and setup descriptor config register
>
> from now on it should be ready for active register reads and writes
>
>
> Do you have PCI bus enabled at the same time? It could change the
> way ahb is working.
>
If I try to disable the PCI support, the system will always crash in
ath5k_hw_register_timeout() during the ath5k_hw_nic_wakeup()
(2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(2457000 KHz - 2482000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Data bus error, epc == 803cc010, ra == 803cc42c
Oops[#1]:
Cpu 0
$ 0 : 00000000 10009c00 c02a0000 00000086
$ 4 : c02a8004 00000000 00000001 000000a0
$ 8 : 00000000 800454f0 0000004b 00000002
$12 : ffffffff 80320000 00008000 00200200
$16 : 80330000 00000000 00000086 00000001
$20 : 00000000 00000003 00000000 2ab77f10
$24 : 00000000 b000e5df
$28 : 80ec4000 80ec5ca8 7fd6d818 803cc42c
Hi : 00000000
Lo : 0000238c
epc : 803cc010 ath5k_hw_register_timeout+0x2a0/0x3b0 [ath5k]
Not tainted
ra : 803cc42c ath5k_hw_nic_wakeup+0x16c/0x424 [ath5k]
Status: 10009c03 KERNEL EXL IE
Cause : 1080041c
PrId : 00019064 (MIPS 4KEc)
Modules linked in: ath5k(+) ath mac80211 crc_ccitt cfg80211
compat_firmware_class compat arc4 aes_generic deflate ecb cbc
Process insmod (pid: 408, threadinfo=80ec4000, task=80881a18, tls=00000000)
Stack : 00000000 00000000 8028f9d4 8033e780 80330000 00000000 00000086 00000001
00000000 00000003 00000000 803cc42c 00000004 8033e780 00000003 8028f9d4
00000080 803d34c4 80330000 80320d00 00000086 00000000 00000000 803cdbcc
ffffffff 00000004 00000000 00000002 80320d00 803dca60 00000002 80320d00
803dca60 80320200 80330000 803d197c ffffffff ffffffff 803b09d3 00000005
...
Call Trace:
[<803cc010>] ath5k_hw_register_timeout+0x2a0/0x3b0 [ath5k]
Code: 34048004 00442021 2c650086 <8c930000> 14a00003 24444004
3c04b010 34844004 8c840000
Disabling lock debugging due to kernel taint
AHB fatal error
whereas if I compile the PCI support the system will not recognize the
phy/mac version/revision
(2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
(5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
(5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
ath5k phy0: Couldn't identify radio revision.
ar231x-wmac ar231x-wmac.0: failed to attach device, err=-19
> Br,
> Wojtek
>
>
> ---
> --- a/drivers/net/wireless/ath/ath5k/reset.c
> +++ b/drivers/net/wireless/ath/ath5k/reset.c
> @@ -405,6 +405,7 @@ static int ath5k_hw_wisoc_reset(struct ath5k_hw *ah, u32
> flags)
> udelay(100);
>
> /* Bring BB/MAC out of reset */
> + regval = __raw_readl(reg);
> __raw_writel(regval & ~val, reg);
> regval = __raw_readl(reg);
>
> ---
>
>>
>> > but if I do not overwrite these values with ones from madwifi the
>> > system hangs in ath5k_hw_init()
>> >
>> > "ath5k phy0: Couldn't identify radio revision.
>> > ar231x-wmac ar231x-wmac.0: failed to attach device, err=-19"
>> >
>> > However if I modify mac/phy version/revision in ath5k_hw_init the
>> > system is not able to write and read coherently in ath5k_hw_post()
>> > also with your latest patch.
>> >
>> >> For reset I have now checked with madwifi and there is a
>> difference
>> >> in enabling wmac ahb. Can you try following change and see if it
>> >> helps?
>> >> I have just copied code for waking up WMAC.
>> >>
>> >> Br,
>> >> Wojtek
>> >>
>> >> ---
>> >> diff --git a/drivers/net/wireless/ath/ath5k/ahb.c
>> b/drivers/net/wireless/ath/ath5k/ahb.c
>> >> index 707cde1..06c1b8b 100644
>> >> --- a/drivers/net/wireless/ath/ath5k/ahb.c
>> >> +++ b/drivers/net/wireless/ath/ath5k/ahb.c
>> >> @@ -132,6 +132,21 @@ static int ath_ahb_probe(struct
>> platform_device *pdev)
>> >> reg = __raw_readl((void __iomem *)
>> AR5K_AR2315_BYTESWAP);
>> >> reg |= AR5K_AR2315_BYTESWAP_WMAC;
>> >> __raw_writel(reg, (void __iomem *)
>> AR5K_AR2315_BYTESWAP);
>> >> +
>> >> +
>> >> + /* wake up the MAC */
>> >> + /* NOTE: for the following write to succeed the
>> >> + * RST_AHB_ARB_CTL should be set to 0. This driver
>> >> + * assumes that the register has been set to 0 by
>> boot loader
>> >> + */
>> >> + reg = __raw_readl((void __iomem *)
>> AR5K_AR2315_PCI_MAC_SCR);
>> >> + reg = (reg & ~AR5K_AR2315_PCI_MAC_SCR_SLMODE_M) |
>> >> + (AR5K_AR2315_PCI_MAC_SCR_SLM_FWAKE <<
>> AR5K_AR2315_PCI_MAC_SCR_SLMODE_S);
>> >> + __raw_writel(reg, (void __iomem *)
>> AR5K_AR2315_PCI_MAC_SCR);
>> >> +
>> >> + /* wait for the MAC to wakeup */
>> >> + while ( __raw_readl((void __iomem *)
>> AR5K_AR2315_PCI_MAC_PCICFG) & AR5K_AR2315_PCI_MAC_PCICFG_SPWR_DN);
>> >> +
>> >> } else {
>> >> /* Enable WMAC DMA access (assuming 5312 or 231x*/
>> >> /* TODO: check other platforms */
>> >> diff --git a/drivers/net/wireless/ath/ath5k/reg.h
>> b/drivers/net/wireless/ath/ath5k/reg.h
>> >> index 7ad05d4..9fc63a5 100644
>> >> --- a/drivers/net/wireless/ath/ath5k/reg.h
>> >> +++ b/drivers/net/wireless/ath/ath5k/reg.h
>> >> @@ -2587,3 +2587,12 @@
>> >>
>> >> #define AR5K_AR2315_BYTESWAP 0xb100000c
>> >> #define AR5K_AR2315_BYTESWAP_WMAC 0x00000002
>> >> +
>> >> +#define AR5K_AR2315_PCI 0xb0100000
>> >> +#define AR5K_AR2315_PCI_MAC_SCR (AR5K_AR2315_PCI + 0x4004)
>> >> +#define AR5K_AR2315_PCI_MAC_SCR_SLMODE_M 0x00030000
>> >> +#define AR5K_AR2315_PCI_MAC_SCR_SLMODE_S 16
>> >> +#define AR5K_AR2315_PCI_MAC_SCR_SLM_FWAKE 0
>> >> +
>> >> +#define AR5K_AR2315_PCI_MAC_PCICFG (AR5K_AR2315_PCI + 0x4010)
>> >> +#define AR5K_AR2315_PCI_MAC_PCICFG_SPWR_DN 0x00010000
>> >> ---
>> >>
>> >>
>> >>
>> >>>
>> >>> Any idea about these issues? I am using OpenWrt trunk,
>> >>> compat-wireless-2010-11-20, kernel 2.6.32.26.
>> >>>
>> >>> Best regards
>> >>>
>> >>> Lorenzo
>> >>
>> >
>> > I am going to bisect the issue in more detail by next few days
>> >
>> > Best regards
>> >
>> > Lorenzo
>> >
>>
>> Best regards
>>
>> Lorenzo
>
> --
> Wojciech Dubowik
> Senior Software Engineer
> Neratec Solutions AG
> Rosswiesstr. 29, CH-8608 Bubikon, Switzerland
> Tel: +41 55 253 2096 (office)
> Fax: +41 55 253 2070
> wojciech.dubo...@neratec.com
> http://www.neratec.com
>
Best regards
Lorenzo
_______________________________________________
ath5k-devel mailing list
ath5k-devel@lists.ath5k.org
https://lists.ath5k.org/mailman/listinfo/ath5k-devel
