Performance of BCM43224 (14e4:4353)

Performance of BCM43224 (14e4:4353)

[Larry Finger]

Guys,

I just added the patches that let brcmsmac use bcma, and tested the TX and RX 
rates using netperf. The results are

Driver			RX		TX

brcmsmac		21.7		6.2
b43			15.0		6.0
wl			43.5		73.5

The AP is running in 802.11n mode and has throughput of 40-60 Mbps in both 
directions with an RTL8192CE, thus both open-source drivers have room for 
improvement.

I am using the following firmware:
b43-phy0: Loading firmware version 666.2 (2011-02-23 01:15:07)


With b43 and mac80211 debugging turned on, I see a lot of

wlan13: detected beacon loss from AP - sending probe request

Larry

Performance of BCM43224 (14e4:4353)

[Larry Finger]

On 12/09/2011 04:27 AM, Arend van Spriel wrote:
>
> Hi Larry
>
> Could you perform your benchmark test on brcmsmac without the bcma
> patches. It kind of surprises me that we are that far off compared to
> the wl driver.

I wondered about that myself. Upon investigation, my test with bcma/brcmsmac 
never worked. Without the patches, my netperf numbers for brcmsmac are RX 40.0 
and TX 59.7 Mbps.In all cases, the reported number is the maximum of 10 tries of 
3 sec each.

With the patches, my dmesg contains the following:

[  908.282281] bcma: Bus registered
[  908.353242] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22
[  908.380164] ieee80211 phy0: wl0: brcms_b_attach: si_attach failed
[  908.380184] ieee80211 phy0: wl0: brcms_b_attach: failed with err 11
[  908.380192] ieee80211 phy0: wl0: brcms_c_attach: failed with err 11
[  908.380316] ieee80211 phy0: brcmsmac: attach() failed with code 11
[  908.380379] brcmsmac: brcms_bcma_probe: brcms_attach failed!
[  908.381715] brcms_module_init: register returned 0

As b43 is also loaded, which may be a second problem, it is run instead of brcmsmac.

Larry

Performance of BCM43224 (14e4:4353)

[Larry Finger]

On 12/09/2011 11:32 AM, Arend van Spriel wrote:

> With the submitted patches brcmsmac claims any revision of 802.11 cores.
> Not sure what b43 claims. I have a patch internally to claim only
> revisions 23 and 24, which are used in bcm43224, bcm43225, and bcm4313.

The problem is that ai_doattach() is returning NULL. I added pr_err() statements 
to each of the places that this could happen and found that the error in in this 
fragment:

         /* scan for cores */
         if (socitype == SOCI_AI) {
                 SI_MSG("Found chip type AI (0x%08x)\n", w);
                 /* pass chipc address instead of original core base */
                 ai_scan(&sii->pub, pbus);
         } else {
                 /* Found chip of unknown type */
                 pr_err("Found chip of type %d\n", socitype);
                 return NULL;
         }

This one logs "brcmsmac: Found chip of type 4". As SOC_AI is the only SOCI_XX 
that is defined, I am not sure that I will be able to get further.

Larry

Performance of BCM43224 (14e4:4353)

[Larry Finger]

Arend,

I got a little further. The error message was modified as below:

         /* scan for cores */
         if (socitype == SOCI_AI) {
                 SI_MSG("Found chip type AI (0x%08x)\n", w);
                 /* pass chipc address instead of original core base */
                 ai_scan(&sii->pub, pbus);
         } else {
                 /* Found chip of unknown type */
                 pr_err("Found chip of type %d, chipid is 0x%x\n", socitype, w);
                 return NULL;
         }

This one logs "brcmsmac: Found chip of type 4, chipid is 0x4bf80001". That is a 
very strange chip ID.

Larry

Performance of BCM43224 (14e4:4353)

[Larry Finger]

On 12/09/2011 01:31 PM, Arend van Spriel wrote:
>
> That is an unexpected code path especially as brcmsmac is probed from
> bcma so SoC interface type should be AI (aka. AMBA AXI). Checked with
> the proprietary driver and there is no type 4.
>
> Can you provide the bcma_device_id information that bcma has collected
> and the bcma_chipinfo for your device?

The bcma core scan provides:

bcma: Core 0 found: ChipCommon (manuf 0x4BF, id 0x800, rev 0x22, class 0x0)
bcma: Core 1 found: IEEE 802.11 (manuf 0x4BF, id 0x812, rev 0x17, class 0x0)
bcma: Core 2 found: PCIe (manuf 0x4BF, id 0x820, rev 0x0F, class 0x0)

b43 reports:

b43-phy0: Broadcom 43224 WLAN found (core revision 23)
b43-phy0 debug: Found PHY: Analog 8, Type 4, Revision 6

brcmsmac shows:

brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 22

I hope this provides what you need. I did not see anything else in the logs.

Larry

Performance of BCM43224 (14e4:4353)

[Larry Finger]

On 12/09/2011 02:04 PM, Arend van Spriel wrote:
>
> Indeed. What is more strange is that this looks like value from
> enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
> It seems the BAR window is wrong. Can you read PCI_BAR window in the
> ai_doattach() before reading the chip id.

I would like a hint on how to do this. I tried some things that failed.

Larry

Performance of BCM43224 (14e4:4353)

[Rafał Miłecki]

2011/12/9 Larry Finger <Larry.Finger@lwfinger.net>:
> On 12/09/2011 02:04 PM, Arend van Spriel wrote:
>>
>>
>> Indeed. What is more strange is that this looks like value from
>> enumeration rom. 0x4bf is BCMA_MANUF_BCM, 0x800 is BCMA_CORE_CHIPCOMMON.
>> It seems the BAR window is wrong. Can you read PCI_BAR window in the
>> ai_doattach() before reading the chip id.
>
>
> I would like a hint on how to do this. I tried some things that failed.

Have you tried
u32 value;
pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN, &value);
pr_info();
pci_write_config_dword(core->bus->host_pci, BCMA_PCI_BAR0_WIN2, &value);
pr_info();

You should also hack bcma_bus_scan to display addr and wrap.
pr_info("Core %d addr: 0x%X, wrap 0x%X\n", core->core_index,
core->addr, core->wrap);
(put is inside the while, after existing pr_info)

-- 
Rafa?

Performance of BCM43224 (14e4:4353)

[Larry Finger]

On 12/10/2011 05:04 AM, Arend van Spriel wrote:
>
> Obviously it should be a pci_read_config_dword(). I found out that I can
> reproduce the problem over here so I added the print statements:
>
> [61359.893254] brcmsmac bcma0:0: mfg 4bf core 812 rev 23 class 0 irq 17
> [61359.897801] core[2] id=0x820 addr=18002000 wrap=18102000
> [61359.897808] core[1] id=0x812 addr=18001000 wrap=18101000
> [61359.897814] core[0] id=0x800 addr=18000000 wrap=18100000
> [61359.897822] PCI_BAR0_WIN=18107000
>
> Not sure how it got programmed to this value, but it definitely is wrong.

I put pr_info() and dump_stack() at every place where PCI_BAR_WIN0 is changed. 
The one place in drivers/bcma/host_pci.c is never called - only the location in 
drivers/bcma/scan.c.

The logged data is

[  813.683905] bcma: BCMA_PCI_BAR0_WIN set to 0x18000000
[  813.683910] Pid: 8989, comm: work_for_cpu Tainted: G           O 
3.2.0-rc4-wl+ #146
[  813.683913] Call Trace:
[  813.683926]  [<ffffffffa0389af6>] 
bcma_scan_switch_core.isra.9.part.10+0x36/0x40 [bcma]
[  813.683933]  [<ffffffffa0389bde>] bcma_init_bus+0x6e/0x70 [bcma]
[  813.683940]  [<ffffffffa0389c04>] bcma_bus_scan+0x24/0x210 [bcma]
[  813.683946]  [<ffffffff81028f11>] ? __ioremap_caller+0x2b1/0x390
[  813.683951]  [<ffffffff811dded0>] ? pci_iomap+0x80/0xc0
[  813.683958]  [<ffffffffa0389209>] bcma_bus_register+0x19/0x2e0 [bcma]
[  813.683964]  [<ffffffffa038b800>] bcma_host_pci_probe+0x120/0x1c0 [bcma]
[  813.683970]  [<ffffffff810636b0>] ? cwq_activate_first_delayed+0x110/0x110
[  813.683976]  [<ffffffff811f17b2>] local_pci_probe+0x12/0x20
[  813.683980]  [<ffffffff810636c3>] do_work_for_cpu+0x13/0x30
[  813.683984]  [<ffffffff8106bb07>] kthread+0x87/0x90
[  813.683990]  [<ffffffff81384f74>] kernel_thread_helper+0x4/0x10
[  813.683995]  [<ffffffff8138269d>] ? retint_restore_args+0xe/0xe
[  813.683999]  [<ffffffff8106ba80>] ? __init_kthread_worker+0x70/0x70
[  813.684041]  [<ffffffff81384f70>] ? gs_change+0xb/0xb
[  813.684048] bcma: BCMA_PCI_BAR0_WIN set to 0x18107000

The stack trace is identical for the second entry. It is never remapped, which 
is why it is wrong in brcmsmac.

Question: Don't you need to change the R_REG macro to use bcma? It is still 
doing read{b,w,l} operations, and is not checking the mapping.

Larry