This series contains some patches needed to get brcmsmac working on
SoCs like the BCM4718.
The last part which adds core rev 17 (used in the BCM4718) to the list
of supported cores is missing, because we do not have a firmware
supporting this core yet, but I extended the b43 fwcutter to generate
a firmware which brcmsmac accepts. With this firmware my BCM4718
works. I would appreciate an official firmware release from Broadcom
adding support for this core.
The final patch adding support for the BCM43224 is missing because
the PCIe host controller on the BCM4718 still causes problems and I
have to add some more read after writes into the code, for now it uses
an ugly hack and sometimes the problems still occur.
The wifi is not stable on the BCM4718, I had no problems connecting to
my ath9k driven access point but I have problems connecting to my
BCM47186 based AP running the vendor firmware with the Broadcom
proprietary driver.
I get 12MBit/s max with the BCM4718 connected to ath9k on the 2.4 GHz
band and 35 MBit/s max with the BCM43224 on the 5Ghz band connected to
a Broadcom based AP running the proprietary driver. This seams to be
CPU bounced as I have over 50% sirq in both cases.
brcmsmac starts on the BCM47186 (id: 0x5357), but it does not tx or rx
any traffic.
One patch extends the xmtfifo_sz array for more core revs, I just toke
the values from the other phy-n cores and hope this is correct.
These patches are depending on: "[PATCH 0/8] bcma misc updates" and
based on wireless-testing.
Hauke Mehrtens (18):
brcmsmac: remove PCIE() makro
brcmsmac: remove PCI_FORCEHT() makro
brcmsmac: remove ai_get_buscore{type,rev}()
brcmsmac: use container_of instead of cast
brcmsmac: remove ai_findcore()
brcmsmac: remove si_pmu_init() and si_pmu_res_init()
brcmsmac: remove si_pmu_spuravoid_pllupdate()
brcmsmac: remove some redundant chip common workarounds
brcmsmac: use core id constants from bcma
brcmsmac: use chip and package id constants from bcma
brcmsmac: remove some unnessessacry casts and void pointer
brcmsmac: add a conditions for core rev 17 again
brcmsmac: add some workarounds for other chips again
brcmsmac: extend xmtfifo_sz array
brcmsmac: fix DMA on SoCs
brcmsmac: do not call brcms_c_chipmatch() for non PCI
brcmsmac: fix read in write_phy_reg
brcmsmac: handle non PCI devices in the phy code
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 128 ++-------------
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 16 --
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 18 +-
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 22 ++-
drivers/net/wireless/brcm80211/brcmsmac/main.c | 67 ++++++--
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 38 +++--
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 153 +++++++++++------
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 172 +-------------------
drivers/net/wireless/brcm80211/brcmsmac/pmu.h | 3 -
drivers/net/wireless/brcm80211/include/soc.h | 62 -------
10 files changed, 230 insertions(+), 449 deletions(-)
--
1.7.9.5
Instead of checking if there is a PCIe core on the bus, better check if
hosttype is PCIe.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 9 ++++-----
1 file changed, 4 insertions(+), 5 deletions(-)
The BCM4716 is a SoC and does not have a PCI client interface, so this
condition is never true.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 19 -------------------
1 file changed, 19 deletions(-)
@@ -782,16 +770,9 @@ void ai_pci_up(struct si_pub *sih)voidai_pci_down(structsi_pub*sih){structsi_info*sii;-structbcma_device*cc;sii=(structsi_info*)sih;-/* release FORCEHT since chip is going to "down" state */-if(PCI_FORCEHT(sih)){-cc=ai_findcore(&sii->pub,BCMA_CORE_CHIPCOMMON,0);-bcma_core_set_clockmode(cc,BCMA_CLKMODE_DYNAMIC);-}-if(sii->icbus->hosttype==BCMA_HOSTTYPE_PCI)bcma_core_pci_extend_L1timer(&sii->icbus->drv_pci,false);}
These two functions are not used any more.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 15 ---------------
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 4 ----
2 files changed, 19 deletions(-)
@@ -168,7 +168,6 @@ struct si_info {structsi_pubpub;/* back plane public state (must be first) */structbcma_bus*icbus;/* handle to soc interconnect bus */structpci_dev*pcibus;/* handle to pci bus */-structbcma_device*buscore;u32chipst;/* chip status */};
bcma also stores a pointer to the chipcommon core in its struct,
brcmsmac should use it and not search for the core by its own.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 31 ++++-----------------
drivers/net/wireless/brcm80211/brcmsmac/aiutils.h | 2 --
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 12 +++++---
3 files changed, 14 insertions(+), 31 deletions(-)
@@ -590,27 +590,6 @@ void ai_detach(struct si_pub *sih)kfree(sii);}-/* return index of coreid or BADIDX if not found */-structbcma_device*ai_findcore(structsi_pub*sih,u16coreid,u16coreunit)-{-structbcma_device*core;-structsi_info*sii;-uintfound;--sii=container_of(sih,structsi_info,pub);--found=0;--list_for_each_entry(core,&sii->icbus->cores,list)-if(core->id.id==coreid){-if(found==coreunit)-returncore;-found++;-}--returnNULL;-}-/**read/modifychipcommoncoreregister.*/
@@ -687,12 +666,13 @@ ai_clkctl_setdelay(struct si_pub *sih, struct bcma_device *cc)/* initialize power control delay registers */voidai_clkctl_init(structsi_pub*sih){+structsi_info*sii=container_of(sih,structsi_info,pub);structbcma_device*cc;if(!(ai_get_cccaps(sih)&CC_CAP_PWR_CTL))return;-cc=ai_findcore(sih,BCMA_CORE_CHIPCOMMON,0);+cc=sii->icbus->drv_cc.core;if(cc==NULL)return;
@@ -284,51 +253,6 @@ u32 si_pmu_alp_clock(struct si_pub *sih)returnclock;}-/* initialize PMU */-voidsi_pmu_init(structsi_pub*sih)-{-structsi_info*sii=container_of(sih,structsi_info,pub);-structbcma_device*core;--/* select chipc */-core=sii->icbus->drv_cc.core;--if(ai_get_pmurev(sih)==1)-bcma_mask32(core,CHIPCREGOFFS(pmucontrol),-~PCTL_NOILP_ON_WAIT);-elseif(ai_get_pmurev(sih)>=2)-bcma_set32(core,CHIPCREGOFFS(pmucontrol),PCTL_NOILP_ON_WAIT);-}--/* initialize PMU resources */-voidsi_pmu_res_init(structsi_pub*sih)-{-structsi_info*sii=container_of(sih,structsi_info,pub);-structbcma_device*core;-u32min_mask=0,max_mask=0;--/* select to chipc */-core=sii->icbus->drv_cc.core;--/* Determine min/max rsrc masks */-si_pmu_res_masks(sih,&min_mask,&max_mask);--/* It is required to program max_mask first and then min_mask */--/* Program max resource mask */--if(max_mask)-bcma_write32(core,CHIPCREGOFFS(max_res_mask),max_mask);--/* Program min resource mask */--if(min_mask)-bcma_write32(core,CHIPCREGOFFS(min_res_mask),min_mask);--/* Add some delay; allow resources to come up and settle. */-mdelay(2);-}-u32si_pmu_measure_alpclk(structsi_pub*sih){structsi_info*sii=container_of(sih,structsi_info,pub);
si_pmu_spuravoid_pllupdate() is now replaced by
bcma_pmu_spuravoid_pllupdate() which does the same thing, but supports
more chips.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 3 +-
drivers/net/wireless/brcm80211/brcmsmac/pmu.c | 84 --------------------
drivers/net/wireless/brcm80211/brcmsmac/pmu.h | 1 -
3 files changed, 2 insertions(+), 86 deletions(-)
The removed workarounds are already performed in bcma_pmu_workarounds()
and bcma_core_chipcommon_init()
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/aiutils.c | 42 ---------------------
1 file changed, 42 deletions(-)
This reverts some changes made in this commit:
commit 7234592364e2efe8b4ac1040c99b1d7ef01cf502
Author: Roland Vossen [off-list ref]
Date: Mon Feb 14 12:16:45 2011 +0100
staging: brcm80211: removal of inactive d11 code
The bcm4716 has a rev 17 wireless core and this condition is needed.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
patch expect the part with the workaround for the BCM43236, which is an
usb chip and will be unsupported by brcmsmac.
commit c2c724977f95135f397fe0cb45f3c041d26b91e1
Author: Arend van Spriel [off-list ref]
Date: Wed Jun 29 16:46:35 2011 -0700
staging: brcm80211: remove unsupported chipset code from brcmsmac phy
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 14 +-
.../net/wireless/brcm80211/brcmsmac/phy/phy_n.c | 144 ++++++++++++++------
2 files changed, 109 insertions(+), 49 deletions(-)
The xmtfifo_sz array contains the queue sizes for the different chip
revs. This array missed the sizes for the core rev 17 and 28. This
patch extends the array to also include these sizes and adds a warning
if no queue size is stored in the array for the given core rev.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/main.c | 38 +++++++++++++++++++++++-
1 file changed, 37 insertions(+), 1 deletion(-)
@@ -4609,8 +4641,12 @@ static int brcms_b_attach(struct brcms_c_info *wlc, struct bcma_device *core,wlc_hw->machwcap_backup=wlc_hw->machwcap;/* init tx fifo size */+WARN_ON((wlc_hw->corerev-XMTFIFOTBL_STARTREV)<0||+(wlc_hw->corerev-XMTFIFOTBL_STARTREV)>+ARRAY_SIZE(xmtfifo_sz));wlc_hw->xmtfifo_sz=xmtfifo_sz[(wlc_hw->corerev-XMTFIFOTBL_STARTREV)];+WARN_ON(!wlc_hw->xmtfifo_sz[0]);/* Get a phy for this band */wlc_hw->band->pi=
These extra offsets are only needed by PCIe devices and not when
running on an SoC.
This partly reverts commit:
commit 821e4e93172e4f7d5ac1eade04665c3dc5049c4a
Author: Roland Vossen [off-list ref]
Date: Mon Aug 8 15:58:58 2011 +0200
staging: brcm80211: removed unused bus code from softmac
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
drivers/net/wireless/brcm80211/brcmsmac/dma.c | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
@@ -633,11 +634,14 @@ struct dma_pub *dma_attach(char *name, struct si_pub *sih,*/di->ddoffsetlow=0;di->dataoffsetlow=0;-/* add offset for pcie with DMA64 bus */-di->ddoffsetlow=0;-di->ddoffsethigh=SI_PCIE_DMA_H32;-di->dataoffsetlow=di->ddoffsetlow;-di->dataoffsethigh=di->ddoffsethigh;+/* for pci bus, add offset */+if(sii->icbus->hosttype==BCMA_HOSTTYPE_PCI){+/* add offset for pcie with DMA64 bus */+di->ddoffsetlow=0;+di->ddoffsethigh=SI_PCIE_DMA_H32;+di->dataoffsetlow=di->ddoffsetlow;+di->dataoffsethigh=di->ddoffsethigh;+}/* WAR64450 : DMACtl.Addr ext fields are not supported in SDIOD core. */if((core->id.id==BCMA_CORE_SDIO_DEV)&&((rev>0)&&(rev<=2)))
brcms_c_chipmatch() just works for PCIe devices and returns false for
non PCIe devices. This stops brcms_ops_stop() from calling it when the
devices is not a PCIe device.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
.../net/wireless/brcm80211/brcmsmac/mac80211_if.c | 22 +++++++++++++-------
1 file changed, 14 insertions(+), 8 deletions(-)
Some code in write_{radio,radio}_reg() should just be run if this is a
pci based device. Add the condition again which was removed in commit:
commit 821e4e93172e4f7d5ac1eade04665c3dc5049c4a
Author: Roland Vossen [off-list ref]
Date: Mon Aug 8 15:58:58 2011 +0200
staging: brcm80211: removed unused bus code from softmac
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
---
.../net/wireless/brcm80211/brcmsmac/phy/phy_cmn.c | 20 ++++++++++++++------
1 file changed, 14 insertions(+), 6 deletions(-)
From: Arend van Spriel <hidden> Date: 2012-06-06 10:03:48
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
Has brcmsmac been tested for all these chips? At this moment I do not
have any bandwidth to do that. I am not too comfortable adding this code
without having some testing coverage. It was the reason to remove the
snippets from brcmsmac.
patch expect the part with the workaround for the BCM43236, which is an
usb chip and will be unsupported by brcmsmac.
'expect' should be 'except'. Indeed, BCM43236 is a fullmac usb chip and
as such supported by brcmfmac.
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-06-06 11:23:34
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
brcms_c_chipmatch() just works for PCIe devices and returns false for
non PCIe devices. This stops brcms_ops_stop() from calling it when the
devices is not a PCIe device.
Although this is true you may want to consider what this function
provides. The intent is to have a more accurate filter to determine
support the device by the driver, ie. more accurate than what is in the
driver device table.
So in brcms_c_chipmatch() we may want a host-type independent filtering
and validate bcma_device_id, bcma_chipinfo, and possibly bcma_boardinfo.
From: Arend van Spriel <hidden> Date: 2012-06-06 11:39:17
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
This reverts a unintended change mad in commit.
commit 4b006b11ca18995677c5f1cd03cc9c42fbe80693
Author: Arend van Spriel [off-list ref]
Date: Thu Dec 8 15:06:54 2011 -0800
brcm80211: smac: use bcma functions for register access in phy code
Hi Arend,
On 06/06/2012 01:23 PM, Arend van Spriel wrote:
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
brcms_c_chipmatch() just works for PCIe devices and returns false for
non PCIe devices. This stops brcms_ops_stop() from calling it when the
devices is not a PCIe device.
Although this is true you may want to consider what this function
provides. The intent is to have a more accurate filter to determine
support the device by the driver, ie. more accurate than what is in the
driver device table.
So in brcms_c_chipmatch() we may want a host-type independent filtering
and validate bcma_device_id, bcma_chipinfo, and possibly bcma_boardinfo.
I do not like this function at all. ;-)
Are these restrictions in this function really needed? I would more like
to restrict it to something like core revs, which is done in the device
table and the phy types and versions. A restriction by chipid would also
be reasonable as some chips are needing some special workarounds, these
checks could also be done for SoCs.
In my opinion this functions results in preventing users from running
this driver with some device which is working with this driver but which
is not in this list of supported devices, because some board vendor just
changed some id and no developer got such a card to test it and change
the detection code.
It is like with the PCIe card I found connected to my BCM4718, this card
is working expect for some problems with the PCIe host controller on the
BCM4716, but brcms_c_chipmatch() returned false for it.
By the way, why is a call to this function in brcms_ops_stop() in
addition to the call in the init code? In this case the device was
already started.
The xmtfifo_sz array contains the queue sizes for the different chip
revs. This array missed the sizes for the core rev 17 and 28. This
Should probably use core revs instead of chip revs and I think we are
talking about the 80211 core rev here.
Yes I will change this comment.
Are there any devices with the same phy type using different fifo sizes?
If this is not the case I think it is better to do this based on the phy
type.
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
Has brcmsmac been tested for all these chips? At this moment I do not
have any bandwidth to do that. I am not too comfortable adding this code
without having some testing coverage. It was the reason to remove the
snippets from brcmsmac.
I have just tested BCM4716 and BCM5357, BCM5357 is not working. ;-)
I do not have all the devices to test this and for the BCM6362 some
infrastructure code is still missing.
The adding of the BCM5357 is part of my start adding support for that
chip, which is not complete. As the device detection code in brcmsmac
is not changed in this commit, no more devices are detected by brcmsmac
now. I talked to Jonas Gorski about the BCM6362 and he thinks about
adding support for that device to the Linux kernel in some time.
I could reduce the code into adding support for the BCM4716 and BCM5357
if that is fine with you and if someone else wants to add support for
some other chip in the future he has to add the code again.
quoted
patch expect the part with the workaround for the BCM43236, which is an
usb chip and will be unsupported by brcmsmac.
'expect' should be 'except'. Indeed, BCM43236 is a fullmac usb chip and
as such supported by brcmfmac.
Yes that's the reason I removed it here because this will never be
supported by this code.
This patch depends on the two patches before this in the patch series,
without them this patch will not apply. Is your Acked-by also for these
patches?
From: Arend van Spriel <hidden> Date: 2012-06-07 19:06:44
On 06/07/2012 03:19 PM, Hauke Mehrtens wrote:
Hi Arend,
On 06/06/2012 01:23 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
brcms_c_chipmatch() just works for PCIe devices and returns false for
non PCIe devices. This stops brcms_ops_stop() from calling it when the
devices is not a PCIe device.
Although this is true you may want to consider what this function
provides. The intent is to have a more accurate filter to determine
support the device by the driver, ie. more accurate than what is in the
driver device table.
So in brcms_c_chipmatch() we may want a host-type independent filtering
and validate bcma_device_id, bcma_chipinfo, and possibly bcma_boardinfo.
I do not like this function at all. ;-)
Are these restrictions in this function really needed? I would more like
to restrict it to something like core revs, which is done in the device
table and the phy types and versions. A restriction by chipid would also
be reasonable as some chips are needing some special workarounds, these
checks could also be done for SoCs.
I look where the function came from and it is called in several places
in our proprietary driver, which has a pretty coarse filter in the
device table.
The BCMA device table in brcmsmac is more finegrained and currently has
entries for the different 80211 core revisions. However, the brcmsmac
may have additional revision requirement for chipcommon and other cores
inside the chip so this function may have it merits for checking that.
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-06-07 19:21:48
On 06/07/2012 03:33 PM, Hauke Mehrtens wrote:
On 06/06/2012 12:24 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
The xmtfifo_sz array contains the queue sizes for the different chip
revs. This array missed the sizes for the core rev 17 and 28. This
Should probably use core revs instead of chip revs and I think we are
talking about the 80211 core rev here.
Yes I will change this comment.
Are there any devices with the same phy type using different fifo sizes?
If this is not the case I think it is better to do this based on the phy
type.
I dived into this and basically there is no correlation to the phy type.
There are chips with same 80211 core rev and different phy type as there
are chips with different 80211 core rev and the same phy type.
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-06-07 19:34:36
On 06/07/2012 03:45 PM, Hauke Mehrtens wrote:
On 06/06/2012 12:03 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
Has brcmsmac been tested for all these chips? At this moment I do not
have any bandwidth to do that. I am not too comfortable adding this code
without having some testing coverage. It was the reason to remove the
snippets from brcmsmac.
I have just tested BCM4716 and BCM5357, BCM5357 is not working. ;-)
I do not have all the devices to test this and for the BCM6362 some
infrastructure code is still missing.
The adding of the BCM5357 is part of my start adding support for that
chip, which is not complete. As the device detection code in brcmsmac
is not changed in this commit, no more devices are detected by brcmsmac
now. I talked to Jonas Gorski about the BCM6362 and he thinks about
adding support for that device to the Linux kernel in some time.
Yes. Jonas tested brcmsmac on bcm6362 host during our mainlining days.
I could reduce the code into adding support for the BCM4716 and BCM5357
if that is fine with you and if someone else wants to add support for
some other chip in the future he has to add the code again.
I prefer that over adding the code untested even if it is not yet active
code so please do.
quoted
quoted
patch expect the part with the workaround for the BCM43236, which is an
usb chip and will be unsupported by brcmsmac.
'expect' should be 'except'. Indeed, BCM43236 is a fullmac usb chip and
as such supported by brcmfmac.
Yes that's the reason I removed it here because this will never be
supported by this code.
From: Arend van Spriel <hidden> Date: 2012-06-07 19:36:58
On 06/07/2012 03:48 PM, Hauke Mehrtens wrote:
On 06/06/2012 11:17 AM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
These two functions are not used any more.
Acked-by: Arend van Spriel <redacted>
This patch depends on the two patches before this in the patch series,
without them this patch will not apply. Is your Acked-by also for these
patches?
I was looking a bit more carefully to the first two so let me get to
that. Thanks for reminding me ;-)
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-06-07 20:05:45
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
Instead of checking if there is a PCIe core on the bus, better check if
hosttype is PCIe.
I was under the impression that the macro was used for code needed when
the chip has a PCIe core instead of a PCI core. Maybe BCMA only supports
chips with PCIe core and in the respect checking the hosttype is
essentially the same, but I would not necessarily call it better.
From: Arend van Spriel <hidden> Date: 2012-06-07 20:12:29
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
The BCM4716 is a SoC and does not have a PCI client interface, so this
condition is never true.
This patch and the first one in the series use the word 'makro' instead
of 'macro'. Probably your native language seeping through ;-)
Acked-by: Arend van Spriel <redacted>
From: Jonas Gorski <jonas.gorski@gmail.com> Date: 2012-06-08 11:32:15
On 7 June 2012 21:34, Arend van Spriel [off-list ref] wrote:
On 06/07/2012 03:45 PM, Hauke Mehrtens wrote:
quoted
On 06/06/2012 12:03 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
Has brcmsmac been tested for all these chips? At this moment I do not
have any bandwidth to do that. I am not too comfortable adding this code
without having some testing coverage. It was the reason to remove the
snippets from brcmsmac.
I have just tested BCM4716 and BCM5357, BCM5357 is not working. ;-)
I do not have all the devices to test this and for the BCM6362 some
infrastructure code is still missing.
The adding of the BCM5357 is part of my start adding support for that
chip, which is not complete. As the device detection code in brcmsmac
is not changed in this commit, no more devices are detected by brcmsmac
now. I talked to Jonas Gorski about the BCM6362 and he thinks about
adding support for that device to the Linux kernel in some time.
Yes. Jonas tested brcmsmac on bcm6362 host during our mainlining days.
Wait, no, I didn't. It was bcm6328 with an external pcie connected
bcm4313, so not really anything special there.
BCM6362 (and BCM63168) is a totally different beast; its wifi is
integrated into the SoC connected through its internal UBUS. It has an
hardwired erom which is almost parsable through the bcma erom parsing
routines, but it lacks the AMBA extended registers present in real
bcma devices, and all cores are controlled through the wlan shim core.
Also it is completely big endian (as bcm63xx is big endian).
I hacked bcma to properly parse the erom and translate the amba
register accesses to the appropriate wlan shim registers (which was
rather easy, since the register layout is very similar, and there are
only three amba registers actually used), which made bcma successfully
detect three cores (chipcommon, ieee80211 and wlan shim). I "tested"
it with b43, but it supports neither the core rev nor the radio (iirc
0x2057). I did not try brcmsmac, since it didn't even use bcma at that
time. It probably needs some more special handling, as there is an OTP
core present, and my gut feeling says the wifi driver needs/uses it,
but since I don't have sources for the proprietary driver I can't
really check this ;).
TL;DR: BCM6362 isn't real bcma, so it's unlikely the bcma code will
ever see it (unless the translation hacks get accepted ;). Feel free
to drop any BCM6362 handling here.
@Arend: Which probably also means that brcm{s,f]mac will likely never
support it, right? :-/
Jonas
From: Arend van Spriel <hidden> Date: 2012-06-08 16:55:03
On 06/08/2012 01:31 PM, Jonas Gorski wrote:
On 7 June 2012 21:34, Arend van Spriel [off-list ref] wrote:
quoted
On 06/07/2012 03:45 PM, Hauke Mehrtens wrote:
quoted
On 06/06/2012 12:03 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
This adds some workarounds for the BCM4716, BCM47162, BCM43421, BCM5357
and BCM6362 to the phy code again. This patch reverts the following
Has brcmsmac been tested for all these chips? At this moment I do not
have any bandwidth to do that. I am not too comfortable adding this code
without having some testing coverage. It was the reason to remove the
snippets from brcmsmac.
I have just tested BCM4716 and BCM5357, BCM5357 is not working. ;-)
I do not have all the devices to test this and for the BCM6362 some
infrastructure code is still missing.
The adding of the BCM5357 is part of my start adding support for that
chip, which is not complete. As the device detection code in brcmsmac
is not changed in this commit, no more devices are detected by brcmsmac
now. I talked to Jonas Gorski about the BCM6362 and he thinks about
adding support for that device to the Linux kernel in some time.
Yes. Jonas tested brcmsmac on bcm6362 host during our mainlining days.
Wait, no, I didn't. It was bcm6328 with an external pcie connected
bcm4313, so not really anything special there.
Yes. I know it was with external card connected through PCIe. Did not
recall exactly which BCM63xx you used for big-endian mips test.
0x2057). I did not try brcmsmac, since it didn't even use bcma at that
time. It probably needs some more special handling, as there is an OTP
core present, and my gut feeling says the wifi driver needs/uses it,
but since I don't have sources for the proprietary driver I can't
really check this ;).
brcmsmac had OTP code, but I added OTP processing to BCMA. It is daily
tested on powerpc64 so that should work.
TL;DR: BCM6362 isn't real bcma, so it's unlikely the bcma code will
ever see it (unless the translation hacks get accepted ;). Feel free
to drop any BCM6362 handling here.
@Arend: Which probably also means that brcm{s,f]mac will likely never
support it, right? :-/
What silicon backplane does it have? Sonics? I tried to look it up, but
did not find the info.
Do you know the chip revision of your bcm6362?
Gr. AvS
From: Jonas Gorski <jonas.gorski@gmail.com> Date: 2012-06-08 17:49:55
On 8 June 2012 18:54, Arend van Spriel [off-list ref] wrote:
On 06/08/2012 01:31 PM, Jonas Gorski wrote:
quoted
0x2057). I did not try brcmsmac, since it didn't even use bcma at that
time. It probably needs some more special handling, as there is an OTP
core present, and my gut feeling says the wifi driver needs/uses it,
but since I don't have sources for the proprietary driver I can't
really check this ;).
brcmsmac had OTP code, but I added OTP processing to BCMA. It is daily
tested on powerpc64 so that should work.
Maybe it isn't needed by the wifi, though it has a bit that says
whether wifi is available. The wifi driver itself seems to include an
sprom for bcm6362 though, so it's likely a red herring.
quoted
TL;DR: BCM6362 isn't real bcma, so it's unlikely the bcma code will
ever see it (unless the translation hacks get accepted ;). Feel free
to drop any BCM6362 handling here.
@Arend: Which probably also means that brcm{s,f]mac will likely never
support it, right? :-/
What silicon backplane does it have? Sonics? I tried to look it up, but
did not find the info.
It's neither bcma nor ssb, but ubus, the bcm63xx silicon backplane.
You should find the appropriate ub_scan, ub_flag, etc functions in the
proprietary driver as the third backplane type supported by it. The
public parts only have them as empty functions, but still reference
them.
Do you know the chip revision of your bcm6362?
IIRC b0 (haven't booted it in the last few weeks, currently busy with
bcm6328 stuff - one chip at a time ;). Since recent bcm63xx LDKs
removed the a0 register layouts it looks like the a0 revision never
actually made it into a product.
Jonas
Hi Arend,
On 06/06/2012 01:23 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
brcms_c_chipmatch() just works for PCIe devices and returns false for
non PCIe devices. This stops brcms_ops_stop() from calling it when the
devices is not a PCIe device.
Although this is true you may want to consider what this function
provides. The intent is to have a more accurate filter to determine
support the device by the driver, ie. more accurate than what is in the
driver device table.
So in brcms_c_chipmatch() we may want a host-type independent filtering
and validate bcma_device_id, bcma_chipinfo, and possibly bcma_boardinfo.
I do not like this function at all. ;-)
Are these restrictions in this function really needed? I would more like
to restrict it to something like core revs, which is done in the device
table and the phy types and versions. A restriction by chipid would also
be reasonable as some chips are needing some special workarounds, these
checks could also be done for SoCs.
I look where the function came from and it is called in several places
in our proprietary driver, which has a pretty coarse filter in the
device table.
The BCMA device table in brcmsmac is more finegrained and currently has
entries for the different 80211 core revisions. However, the brcmsmac
may have additional revision requirement for chipcommon and other cores
inside the chip so this function may have it merits for checking that.
Gr. AvS
Hi Arend,
ok, then I will extend it somehow to also handle the SoCs based on the
chip id and rev in that function.
Hauke
The xmtfifo_sz array contains the queue sizes for the different chip
revs. This array missed the sizes for the core rev 17 and 28. This
Should probably use core revs instead of chip revs and I think we are
talking about the 80211 core rev here.
Yes I will change this comment.
Are there any devices with the same phy type using different fifo sizes?
If this is not the case I think it is better to do this based on the phy
type.
I dived into this and basically there is no correlation to the phy type.
There are chips with same 80211 core rev and different phy type as there
are chips with different 80211 core rev and the same phy type.
Gr. AvS
Hi Arend,
Ok, then I will leave it based on the core rev like it is now. Are the
values I added there for core rev 17 and 28 correct? They are just
copied from the other phy-n device which has the same values set after
powering up and before they are explicitly set. The core rev 17 device
is working for me, but the core rev 28 is not, but I do not know why. I
was unable to find these values in b43 or the spec b43 is based on.
Hauke
Instead of checking if there is a PCIe core on the bus, better check if
hosttype is PCIe.
I was under the impression that the macro was used for code needed when
the chip has a PCIe core instead of a PCI core. Maybe BCMA only supports
chips with PCIe core and in the respect checking the hosttype is
essentially the same, but I would not necessarily call it better.
The code from the initial submission to staging looked like this:
#define PCIE(si) ((BUSTYPE((si)->pub.bustype) == PCI_BUS) && \
((si)->pub.buscoretype == PCIE_CORE_ID))
I have never seen a device using the AI bus (bcma) and a PCI core and
not a PCIe core and I do not think bcma will work with a PCI device or
core. The bustype in your old code is the same as the hosttype in bcma,
so under the assumption that all device are using PCIe that are coming
to this code the code now does the same as in the initial submission to
staging.
buscore in brcmsmac contained a reference to a PCIe core on the bus, if
there was any. On a SoC with a PCIe core in host mode this also
contained this PCIe core, but it was not the buscore and the hosttype
was not PCIE, nor the bustype when using your SDK would be PCI_BUS, but
SI_BUS.
So this patch is also more or less a bugfix for brcmsmac when you are
not on a PCIe connected device, like a SoC. The old code also caused a
null pointer in ai_get_buscoretype() and ai_get_buscorerev() if buscore
was not set because there was no PCIe core on the bus.
From: Arend van Spriel <hidden> Date: 2012-06-11 07:52:16
On 06/10/2012 03:28 PM, Hauke Mehrtens wrote:
On 06/07/2012 10:05 PM, Arend van Spriel wrote:
quoted
On 06/06/2012 01:07 AM, Hauke Mehrtens wrote:
quoted
Instead of checking if there is a PCIe core on the bus, better check if
hosttype is PCIe.
I was under the impression that the macro was used for code needed when
the chip has a PCIe core instead of a PCI core. Maybe BCMA only supports
chips with PCIe core and in the respect checking the hosttype is
essentially the same, but I would not necessarily call it better.
The code from the initial submission to staging looked like this:
#define PCIE(si) ((BUSTYPE((si)->pub.bustype) == PCI_BUS) && \
((si)->pub.buscoretype == PCIE_CORE_ID))
I have never seen a device using the AI bus (bcma) and a PCI core and
not a PCIe core and I do not think bcma will work with a PCI device or
core. The bustype in your old code is the same as the hosttype in bcma,
so under the assumption that all device are using PCIe that are coming
to this code the code now does the same as in the initial submission to
staging.
If bcma does not work with a PCI core, maybe we could/should add a
WARN_ON() in host_pci.c when it has no PCIe core.
Gr. AvS
From: Arend van Spriel <hidden> Date: 2012-06-11 07:59:21
On 06/10/2012 03:10 PM, Hauke Mehrtens wrote:
On 06/07/2012 09:21 PM, Arend van Spriel wrote:
quoted
I dived into this and basically there is no correlation to the phy type.
There are chips with same 80211 core rev and different phy type as there
are chips with different 80211 core rev and the same phy type.
Gr. AvS
Hi Arend,
Ok, then I will leave it based on the core rev like it is now. Are the
values I added there for core rev 17 and 28 correct? They are just
copied from the other phy-n device which has the same values set after
powering up and before they are explicitly set. The core rev 17 device
is working for me, but the core rev 28 is not, but I do not know why. I
was unable to find these values in b43 or the spec b43 is based on.
Hauke
Dug up the values and for corerev 17 they are fine, but corerev 28 has
different values:
{ 9, 58, 22, 14, 14, 5 }, /* corerev 28 */
Gr. AvS
Instead of checking if there is a PCIe core on the bus, better check if
hosttype is PCIe.
I was under the impression that the macro was used for code needed when
the chip has a PCIe core instead of a PCI core. Maybe BCMA only supports
chips with PCIe core and in the respect checking the hosttype is
essentially the same, but I would not necessarily call it better.
The code from the initial submission to staging looked like this:
#define PCIE(si) ((BUSTYPE((si)->pub.bustype) == PCI_BUS) && \
((si)->pub.buscoretype == PCIE_CORE_ID))
I have never seen a device using the AI bus (bcma) and a PCI core and
not a PCIe core and I do not think bcma will work with a PCI device or
core. The bustype in your old code is the same as the hosttype in bcma,
so under the assumption that all device are using PCIe that are coming
to this code the code now does the same as in the initial submission to
staging.
If bcma does not work with a PCI core, maybe we could/should add a
WARN_ON() in host_pci.c when it has no PCIe core.
Gr. AvS
That sounds good, for now bcma displays this warning if it detects a PCI
and not a PCIe card: "PCI card detected, report problems." adding a
warning looks better to me. bcma_core_pci_init() is just run for PCIE
cores and not for PCI cores, so I do not think PCI cores will work with
the current code.
Hauke
I dived into this and basically there is no correlation to the phy type.
There are chips with same 80211 core rev and different phy type as there
are chips with different 80211 core rev and the same phy type.
Gr. AvS
Hi Arend,
Ok, then I will leave it based on the core rev like it is now. Are the
values I added there for core rev 17 and 28 correct? They are just
copied from the other phy-n device which has the same values set after
powering up and before they are explicitly set. The core rev 17 device
is working for me, but the core rev 28 is not, but I do not know why. I
was unable to find these values in b43 or the spec b43 is based on.
Hauke
Dug up the values and for corerev 17 they are fine, but corerev 28 has
different values:
{ 9, 58, 22, 14, 14, 5 }, /* corerev 28 */
Gr. AvS