brcmsmac on BCM47XX SoCs

brcmsmac on BCM47XX SoCs

[Hauke Mehrtens]

Hi Arend,

I am currently trying to get brcmsmac running on my SoC (bcm4718 +
bcm43224). Using the sprom from bcma and not fetching it in brcmsmac was
not a big problem, are you interested in the patch?
I want to remove the pci code from brcmsmac as it should go into bcma
and some/most parts of the code are already there. I already did some of
this but I still have problems with my device, have you already started
this? I do not know if these problems  are related to my changes or some
other problems with my devices and brcmsmac.

I want to get AP mode working on these device with brcmsmac, but for now
I do not even get station mode running. ;-)

Are there any devices with a ccrev < 20 supported by brcmsmac, the
lowest version I saw was 31 and there are some conditions in brcmsmac
for < 6, < 10 and < 20?

What are your plans to support phy_ht in brcmsmac, for now it is just
supported by b43?

I am a little confused by the vendorid/vid and vendorid/did and the
boardvendor and boardtype members. brcms_c_chipmatch() uses vendorid and
vendorid from the pci config space, but what is the equivalent for SoCs
not on pci bus? boardvendor and boardtype are fetched in
ai_nvram_process and are fetched from nvram when an SoC is used and from
pci config space on a pci device at least that is the way it is done in
the Boradcom SDK.

Hauke

Re: brcmsmac on BCM47XX SoCs

[Arend van Spriel]

On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
> Hi Arend,
>
> I am currently trying to get brcmsmac running on my SoC (bcm4718 +
> bcm43224). Using the sprom from bcma and not fetching it in brcmsmac was
> not a big problem, are you interested in the patch?

Great. Some time ago I sent out a patch for parsing the sprom in bcma 
supporting newer sprom revisions and cutting loose from SSB. While in 
transit back from the collab summit last week I worked on v2 of that 
patch. That probably would affect your nvram work, ie. struct bcma_sprom 
iso ssb_sprom.

> I want to remove the pci code from brcmsmac as it should go into bcma
> and some/most parts of the code are already there. I already did some of
> this but I still have problems with my device, have you already started
> this? I do not know if these problems  are related to my changes or some
> other problems with my devices and brcmsmac.

True. host bus specific code should go. I did change brcmsmac to use the 
DMA-API instead of the pci-dma interface, but there is still stuff to do 
there. I have a 4718 reference design on my desk, but did not get to put 
it to use. What embedded distro are you using?

> I want to get AP mode working on these device with brcmsmac, but for now
> I do not even get station mode running. ;-)

I see why you want AP mode.

> Are there any devices with a ccrev<  20 supported by brcmsmac, the
> lowest version I saw was 31 and there are some conditions in brcmsmac
> for<  6,<  10 and<  20?

brcmsmac is targetted for bcm4313, bcm43224, and bcm43225 so the lowest 
is ccrev 32. The bcm4718 seems to have ccrev 31.

> What are your plans to support phy_ht in brcmsmac, for now it is just
> supported by b43?

I have not been paying good attention to community feedback on b43 
phy_ht support. As b43 support bcm4331 with that phy we decided to stay 
clear from that device. We are to add new phy code for new devices. Not 
sure if that includes the phy_ht.

> I am a little confused by the vendorid/vid and vendorid/did and the
> boardvendor and boardtype members. brcms_c_chipmatch() uses vendorid and
> vendorid from the pci config space, but what is the equivalent for SoCs
> not on pci bus? boardvendor and boardtype are fetched in
> ai_nvram_process and are fetched from nvram when an SoC is used and from
> pci config space on a pci device at least that is the way it is done in
> the Boradcom SDK.

I have to dive into this one. For now, happy Easter.

Gr. AvS

ps: Boradcom. I am making that typo all the time.

Re: brcmsmac on BCM47XX SoCs

[Rafał Miłecki]

2012/4/8 Arend van Spriel <arend@broadcom.com>:
> On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
>> What are your plans to support phy_ht in brcmsmac, for now it is just
>> supported by b43?
>
>
> I have not been paying good attention to community feedback on b43 phy_ht
> support. As b43 support bcm4331 with that phy we decided to stay clear from
> that device. We are to add new phy code for new devices. Not sure if that
> includes the phy_ht.

Whoops, that's extremely too bad. HT support is really wanted for a
lot of routers. What we have in b43 is support coming from watching
mmio ops only, there is no way for it to be complete. I believe you
really should think and releasing HT PHY code, a lot of ppl will be
interested in that.

-- 
Rafał

Re: brcmsmac on BCM47XX SoCs

[Hauke Mehrtens]

On 04/08/2012 09:54 PM, Rafał Miłecki wrote:
> 2012/4/8 Arend van Spriel <arend@broadcom.com>:
>> On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
>>> What are your plans to support phy_ht in brcmsmac, for now it is just
>>> supported by b43?
>>
>>
>> I have not been paying good attention to community feedback on b43 phy_ht
>> support. As b43 support bcm4331 with that phy we decided to stay clear from
>> that device. We are to add new phy code for new devices. Not sure if that
>> includes the phy_ht.
> 
> Whoops, that's extremely too bad. HT support is really wanted for a
> lot of routers. What we have in b43 is support coming from watching
> mmio ops only, there is no way for it to be complete. I believe you
> really should think and releasing HT PHY code, a lot of ppl will be
> interested in that.
> 
The TODO list for brcmsmac in the wireless wiki [0] says "Add support
for more chips, including (near term) BCM43227, BCM43228, and BCM4331."
The BCM4331 uses a HT-Phy, but b43 does not support 802.11n speed (the
chip supports up to 450MBit/s) and 5GHz wifi and I do not think b43 will
support these features in the near future, if it will ever support these
features.

I do not think it is a big problem if brcmsmac supports some chips b43
also supports as b43 misses some important features, for now some
devices IDs for devices supported by brcmsmac and b43 they are
deactivated in b43 by default so brcmsmac is used every time. I would
like to see brcmsmac supporting all wifi chips using bcma (ai bus).

Hauke

[0]:
http://linuxwireless.org/en/users/Drivers/brcm80211#Developer_information

Re: brcmsmac on BCM47XX SoCs

[Arend van Spriel]

On 04/09/2012 01:56 PM, Hauke Mehrtens wrote:
> On 04/08/2012 09:54 PM, Rafał Miłecki wrote:
>> 2012/4/8 Arend van Spriel<arend@broadcom.com>:
>>> On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
>>>> What are your plans to support phy_ht in brcmsmac, for now it is just
>>>> supported by b43?
>>>
>>>
>>> I have not been paying good attention to community feedback on b43 phy_ht
>>> support. As b43 support bcm4331 with that phy we decided to stay clear from
>>> that device. We are to add new phy code for new devices. Not sure if that
>>> includes the phy_ht.
>>
>> Whoops, that's extremely too bad. HT support is really wanted for a
>> lot of routers. What we have in b43 is support coming from watching
>> mmio ops only, there is no way for it to be complete. I believe you
>> really should think and releasing HT PHY code, a lot of ppl will be
>> interested in that.
>>
> The TODO list for brcmsmac in the wireless wiki [0] says "Add support
> for more chips, including (near term) BCM43227, BCM43228, and BCM4331."
> The BCM4331 uses a HT-Phy, but b43 does not support 802.11n speed (the
> chip supports up to 450MBit/s) and 5GHz wifi and I do not think b43 will
> support these features in the near future, if it will ever support these
> features.

Yes. bcm4331 was/is on our TODO list, but when b43 added support for it 
we were unsure how to move forward.

> I do not think it is a big problem if brcmsmac supports some chips b43
> also supports as b43 misses some important features, for now some
> devices IDs for devices supported by brcmsmac and b43 they are
> deactivated in b43 by default so brcmsmac is used every time. I would
> like to see brcmsmac supporting all wifi chips using bcma (ai bus).

I am 100% with you and counting the votes I think we should add bcm4331 
as well ;-)

Gr. AvS

Re: brcmsmac on BCM47XX SoCs

[Seth Forshee]

On Sun, Apr 08, 2012 at 09:54:31PM +0200, Rafał Miłecki wrote:
> 2012/4/8 Arend van Spriel <arend@broadcom.com>:
> > On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
> >> What are your plans to support phy_ht in brcmsmac, for now it is just
> >> supported by b43?
> >
> >
> > I have not been paying good attention to community feedback on b43 phy_ht
> > support. As b43 support bcm4331 with that phy we decided to stay clear from
> > that device. We are to add new phy code for new devices. Not sure if that
> > includes the phy_ht.
> 
> Whoops, that's extremely too bad. HT support is really wanted for a
> lot of routers. What we have in b43 is support coming from watching
> mmio ops only, there is no way for it to be complete. I believe you
> really should think and releasing HT PHY code, a lot of ppl will be
> interested in that.

I second this. Besides routers, some recent MacBooks use bcm4331 and
lack support for HT or for the 5 GHz band. Plus on the model I'm working
with at least (MacBook Pro 8,2) Tx stops working completely after S3
unless b43 and bcma are reloaded, and I haven't had any luck finding a
fix for it.

Seth

Re: brcmsmac on BCM47XX SoCs

[Hauke Mehrtens]

On 04/08/2012 10:51 AM, Arend van Spriel wrote:
> On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
>> Hi Arend,
>>
>> I am currently trying to get brcmsmac running on my SoC (bcm4718 +
>> bcm43224). Using the sprom from bcma and not fetching it in brcmsmac was
>> not a big problem, are you interested in the patch?
> 
> Great. Some time ago I sent out a patch for parsing the sprom in bcma
> supporting newer sprom revisions and cutting loose from SSB. While in
> transit back from the collab summit last week I worked on v2 of that
> patch. That probably would affect your nvram work, ie. struct bcma_sprom
> iso ssb_sprom.

I used the content of struct ssb_sprom, as it is filled with all values
needed by brcmsmac from the nvram, I haven't check if they are filled by
the pci parsing code.
Moving to an other struct for bcma will result in some changes in
arch/mips/bcm47xx/sprom.c, but that should be doable. For my device it
looks like it also works with struct ssb_sprom.

How is the country code handelt? The nvram of my device contains
"ccode=EU" 5 times with all sort of prefixes. EU does not seam to be a
real regularity domain as most of the countries in the EU have their own
regulations and the Linux regulation databases does not know the key EU.
I haven't looked deeper into that topic I just saw some error message
because of EU being unknown.

>> I want to remove the pci code from brcmsmac as it should go into bcma
>> and some/most parts of the code are already there. I already did some of
>> this but I still have problems with my device, have you already started
>> this? I do not know if these problems  are related to my changes or some
>> other problems with my devices and brcmsmac.
> 
> True. host bus specific code should go. I did change brcmsmac to use the
> DMA-API instead of the pci-dma interface, but there is still stuff to do
> there. I have a 4718 reference design on my desk, but did not get to put
> it to use. What embedded distro are you using?

I think it is manageable to get it working on SoCs. The first thing I
see is to get the code from nicpci.c merged into bcma and then remove
nicpci.c, otp.c and srom.c from brcmsmac.

I am using OpenWrt trunk and it should work on your device, if it is
similar to the devices sold to end users from Asus, Netgear and so one,
expect for Ethernet, there are still the legal problems with that, but
USB works.

>> I want to get AP mode working on these device with brcmsmac, but for now
>> I do not even get station mode running. ;-)
> 
> I see why you want AP mode.
> 
>> Are there any devices with a ccrev<  20 supported by brcmsmac, the
>> lowest version I saw was 31 and there are some conditions in brcmsmac
>> for<  6,<  10 and<  20?
> 
> brcmsmac is targetted for bcm4313, bcm43224, and bcm43225 so the lowest
> is ccrev 32. The bcm4718 seems to have ccrev 31.

Ok, so the code for the old ccrevs can be removed, some, sometimes pci
depended, code less to worry about.

>> What are your plans to support phy_ht in brcmsmac, for now it is just
>> supported by b43?
> 
> I have not been paying good attention to community feedback on b43
> phy_ht support. As b43 support bcm4331 with that phy we decided to stay
> clear from that device. We are to add new phy code for new devices. Not
> sure if that includes the phy_ht.
> 
>> I am a little confused by the vendorid/vid and vendorid/did and the
>> boardvendor and boardtype members. brcms_c_chipmatch() uses vendorid and
>> vendorid from the pci config space, but what is the equivalent for SoCs
>> not on pci bus? boardvendor and boardtype are fetched in
>> ai_nvram_process and are fetched from nvram when an SoC is used and from
>> pci config space on a pci device at least that is the way it is done in
>> the Boradcom SDK.
> 
> I have to dive into this one. For now, happy Easter.
> 
> Gr. AvS
> 
> ps: Boradcom. I am making that typo all the time.
I should add that to by spell checker, as this is not the first time. ;-)

Happy Easter you too,

Hauke

Re: brcmsmac on BCM47XX SoCs

[Hauke Mehrtens]

On 04/08/2012 10:51 AM, Arend van Spriel wrote:
> On 04/06/2012 11:43 PM, Hauke Mehrtens wrote:
>> Are there any devices with a ccrev<  20 supported by brcmsmac, the
>> lowest version I saw was 31 and there are some conditions in brcmsmac
>> for<  6,<  10 and<  20?
> 
> brcmsmac is targetted for bcm4313, bcm43224, and bcm43225 so the lowest
> is ccrev 32. The bcm4718 seems to have ccrev 31.
> 

Now I am at the pci core rev. Are there any bcma/ai based devices with a
PCI not PCIE core on the chip? The PCIE cores of my devices are rev 14
(BCM4718) and 15 (BCM43224) are there any devices with a bus supported
by bcma available with a revision less than 14? In brcmsmac is lots of
code to do something different on devices with such PCI(E) core revs.

Hauke