Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Julian Calaby]

Hi Arend,

I watch the linux-sunxi list where we're trying to support a certain
family of ARM chips and the boards they're on with open source,
community maintained kernels. They're at the cheaper end of the
spectrum so they usually end up with chipsets which are bought for
their price point and Android compatibility, not their ease of use by
people doing "generic" Linux.

On Fri, Dec 6, 2013 at 2:27 AM, Olliver Schinagl
<oliver+list@schinagl.nl> wrote:
> On 05-12-13 14:25, Neal Peacock wrote:
>>
>>
>> On Dec 5, 2013 4:02 AM, "Olliver Schinagl" <oliver+list@schinagl.nl
>> <mailto:oliver%2Blist@schinagl.nl>> wrote:
>>  >
>>  > Hey Benn,
>>  >
>>  > it appears as if the bluetooth module requires specific firmware to
>> operate, it's likly the FM module requires it too?
>>  >
>>  > Can you confirm this or wether the firmware for the wifi module also
>> contains the BT and FM firmwares?
>>  >
>> Which WiFi chip is this for?
>
> Wifi is mostly handled by extracting it from the broadcom drivers I belive
> via a script, but BT we are in the dark for.

So, the AMPAK AP6210 Wifi+BT combo device contains one of:
1. BCM43362 / BCM20710
2. BCM4330 / BCM40183
3. BCM4329 / BCM40181

Depending on who you talk to. I can only find one reference for
options #1 and #3, so I suspect it's the BCM4330 based chipset,
however I don't have one of these I can crack open so I'm not sure.

Firstly, are there any plans to support the BCM43362 chipset with the
brcmfmac driver in the near future?

Secondly, is there an upstream driver for the bluetooth parts of these
chipsets, and if so, do we need firmware and where can we get it from?
If there isn't, are there any plans to add support for them?

Thanks,

-- 
Julian Calaby

Email: julian.calaby@gmail.com
Profile: http://www.google.com/profiles/julian.calaby/
.Plan: http://sites.google.com/site/juliancalaby/

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 12/05/2013 10:46 PM, Julian Calaby wrote:
> Hi Arend,
>
> I watch the linux-sunxi list where we're trying to support a certain
> family of ARM chips and the boards they're on with open source,
> community maintained kernels. They're at the cheaper end of the
> spectrum so they usually end up with chipsets which are bought for
> their price point and Android compatibility, not their ease of use by
> people doing "generic" Linux.
>
> On Fri, Dec 6, 2013 at 2:27 AM, Olliver Schinagl
> <oliver+list@schinagl.nl> wrote:
>> On 05-12-13 14:25, Neal Peacock wrote:
>>>
>>>
>>> On Dec 5, 2013 4:02 AM, "Olliver Schinagl" <oliver+list@schinagl.nl
>>> <mailto:oliver%2Blist@schinagl.nl>> wrote:
>>>   >
>>>   > Hey Benn,
>>>   >
>>>   > it appears as if the bluetooth module requires specific firmware to
>>> operate, it's likly the FM module requires it too?
>>>   >
>>>   > Can you confirm this or wether the firmware for the wifi module also
>>> contains the BT and FM firmwares?
>>>   >
>>> Which WiFi chip is this for?
>>
>> Wifi is mostly handled by extracting it from the broadcom drivers I belive
>> via a script, but BT we are in the dark for.
>
> So, the AMPAK AP6210 Wifi+BT combo device contains one of:
> 1. BCM43362 / BCM20710
> 2. BCM4330 / BCM40183
> 3. BCM4329 / BCM40181
>
> Depending on who you talk to. I can only find one reference for
> options #1 and #3, so I suspect it's the BCM4330 based chipset,
> however I don't have one of these I can crack open so I'm not sure.

All these options are SDIO, right?

> Firstly, are there any plans to support the BCM43362 chipset with the
> brcmfmac driver in the near future?

We had someone from the community asking about that earlier and it 
looked trivial to add it. I will get back on this.

> Secondly, is there an upstream driver for the bluetooth parts of these
> chipsets, and if so, do we need firmware and where can we get it from?
> If there isn't, are there any plans to add support for them?

The BT part is done by another group within broadcom so I have no idea 
about their plans. I suspect they can be supported by generic btsdio 
driver, but I may be totally mistaken.

Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 12/05/2013 10:46 PM, Julian Calaby wrote:
> Firstly, are there any plans to support the BCM43362 chipset with the
> brcmfmac driver in the near future?

Hi Julian,

I am working on a patch to support this chip. It is looking promising.
Just have to go after a firmware image to be sure.

Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 12/18/2013 11:31 AM, Arend van Spriel wrote:
> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>> Firstly, are there any plans to support the BCM43362 chipset with the
>> brcmfmac driver in the near future?
>
> Hi Julian,
>
> I am working on a patch to support this chip. It is looking promising.
> Just have to go after a firmware image to be sure.

Cool. Do you have a cubietruck? With my latest wip tree:
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next

We've mmc/sdio controller support on top of 3.13-rc4, it would be
nice if we could also get the wifi and bluetooth to work here.

I'm certainly willing to give some patches for this a try. Do you
have an example of what the dts file for a board with broadcom sdio
wifi looks like ?

Regards,

Hans


p.s.

Your last name seems Dutch, are you Dutch, and if so, are you
located in the Netherlands?

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 12/18/2013 02:12 PM, Hans de Goede wrote:
> Hi,
> 
> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>> brcmfmac driver in the near future?
>>
>> Hi Julian,
>>
>> I am working on a patch to support this chip. It is looking promising.
>> Just have to go after a firmware image to be sure.
> 
> Cool. Do you have a cubietruck? With my latest wip tree:
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next

No cubietruck here. I googled the term last week because it came up and
found embeddedcomputer.nl selling it.

> We've mmc/sdio controller support on top of 3.13-rc4, it would be
> nice if we could also get the wifi and bluetooth to work here.
> 
> I'm certainly willing to give some patches for this a try. Do you
> have an example of what the dts file for a board with broadcom sdio
> wifi looks like ?

I am still struggling with dts changes for a Pandaboard. As I understood
the cubietruck uses AP6210 module and the dts really depends on how
things are wired up with it. Apart from the SDIO lines it may have an
additional GPIO output to power the module and GPIO inputs to wakeup the
host and interrupt line.

> Regards,
> 
> Hans
> 
> 
> p.s.
> 
> Your last name seems Dutch, are you Dutch, and if so, are you
> located in the Netherlands?

Geboren en getogen. We hebben idd een Broadcom vestiging in Nederland.

Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>> brcmfmac driver in the near future?
>>>
>>> Hi Julian,
>>>
>>> I am working on a patch to support this chip. It is looking promising.
>>> Just have to go after a firmware image to be sure.
>>
>> Cool. Do you have a cubietruck? With my latest wip tree:
>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>
> No cubietruck here. I googled the term last week because it came up and
> found embeddedcomputer.nl selling it.
>
>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I'm certainly willing to give some patches for this a try. Do you
>> have an example of what the dts file for a board with broadcom sdio
>> wifi looks like ?
>
> I am still struggling with dts changes for a Pandaboard. As I understood
> the cubietruck uses AP6210 module and the dts really depends on how
> things are wired up with it. Apart from the SDIO lines it may have an
> additional GPIO output to power the module and GPIO inputs to wakeup the
> host and interrupt line.

Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
to the driver. Last, it takes a clock output out of the A20 for the
low power 32k clock. Not sure if this is mandatory?

I've read the schematics more than a few times. I can get a dts out
tomorrow. I was planning on doing the clock output and rfkill part
first.


Regards,

ChenYu


>
>> Regards,
>>
>> Hans
>>
>>
>> p.s.
>>
>> Your last name seems Dutch, are you Dutch, and if so, are you
>> located in the Netherlands?
>
> Geboren en getogen. We hebben idd een Broadcom vestiging in Nederland.
>
> Gr. AvS
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>> brcmfmac driver in the near future?
>>>>
>>>> Hi Julian,
>>>>
>>>> I am working on a patch to support this chip. It is looking promising.
>>>> Just have to go after a firmware image to be sure.
>>>
>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>
>> No cubietruck here. I googled the term last week because it came up and
>> found embeddedcomputer.nl selling it.
>>
>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>> nice if we could also get the wifi and bluetooth to work here.

I got the chip to respond to probing. It is BCM43362 for sure.

  root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
  0xa962
  root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
  0x02d0

Vendor ID is Broadcom. Device ID is 43362.
But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
if this is normal or not.

Bluetooth still isn't responding.

>>> I'm certainly willing to give some patches for this a try. Do you
>>> have an example of what the dts file for a board with broadcom sdio
>>> wifi looks like ?
>>
>> I am still struggling with dts changes for a Pandaboard. As I understood
>> the cubietruck uses AP6210 module and the dts really depends on how
>> things are wired up with it. Apart from the SDIO lines it may have an
>> additional GPIO output to power the module and GPIO inputs to wakeup the
>> host and interrupt line.
>
> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
> to the driver. Last, it takes a clock output out of the A20 for the
> low power 32k clock. Not sure if this is mandatory?
>
> I've read the schematics more than a few times. I can get a dts out
> tomorrow. I was planning on doing the clock output and rfkill part
> first.

Here's my tree, in case anyone wants to play around. It will be rebased
a lot.

  https://github.com/wens/linux/tree/wip/sunxi-next-wifi

The DT is not finished yet. External interrupts and low power clock are
still missing. Can anyone provide an example for useing the PIO EINT
interrupt pins?


Cheers,

ChenYu

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>> brcmfmac driver in the near future?
>>>>>
>>>>> Hi Julian,
>>>>>
>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>> Just have to go after a firmware image to be sure.
>>>>
>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>
>>> No cubietruck here. I googled the term last week because it came up and
>>> found embeddedcomputer.nl selling it.
>>>
>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>> nice if we could also get the wifi and bluetooth to work here.
>
> I got the chip to respond to probing. It is BCM43362 for sure.
>
>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>   0xa962
>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>   0x02d0
>
> Vendor ID is Broadcom. Device ID is 43362.
> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
> if this is normal or not.

Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
brcmfmac driver. I only tested managed mode. Monitor mode does not work.
You can use firmware from CubieTech images.

Things missing:

  1. output clock is using default 32KHz from 24M / 750.
     need to find some place to put clk_set_rate call.

  2. BCM43362 out-of-band interrupts not supported.
     OOB interrupt in brcmfmac is set using platform data.
     Need to put this is board code, or add device tree support.

Core ID and addresses were found using bcmdhd driver debug output.
Arend might want to take a look at the patch:

  https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865

Working tree:

  https://github.com/wens/linux/tree/wip/sunxi-next-wifi

Comments welcome :)


ChenYu

>
> Bluetooth still isn't responding.

Bluetooth still not working. :(
Has anyone had any luck with this?

>
>>>> I'm certainly willing to give some patches for this a try. Do you
>>>> have an example of what the dts file for a board with broadcom sdio
>>>> wifi looks like ?
>>>
>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>> the cubietruck uses AP6210 module and the dts really depends on how
>>> things are wired up with it. Apart from the SDIO lines it may have an
>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>> host and interrupt line.
>>
>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>> to the driver. Last, it takes a clock output out of the A20 for the
>> low power 32k clock. Not sure if this is mandatory?
>>
>> I've read the schematics more than a few times. I can get a dts out
>> tomorrow. I was planning on doing the clock output and rfkill part
>> first.
>
> Here's my tree, in case anyone wants to play around. It will be rebased
> a lot.
>
>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> The DT is not finished yet. External interrupts and low power clock are
> still missing. Can anyone provide an example for useing the PIO EINT
> interrupt pins?
>
>
> Cheers,
>
> ChenYu

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>> brcmfmac driver in the near future?
>>>>>>
>>>>>> Hi Julian,
>>>>>>
>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>> Just have to go after a firmware image to be sure.
>>>>>
>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>
>>>> No cubietruck here. I googled the term last week because it came up and
>>>> found embeddedcomputer.nl selling it.
>>>>
>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I got the chip to respond to probing. It is BCM43362 for sure.
>>
>>    root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>    0xa962
>>    root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>    0x02d0
>>
>> Vendor ID is Broadcom. Device ID is 43362.
>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>> if this is normal or not.
>
> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
> You can use firmware from CubieTech images.
>
> Things missing:
>
>    1. output clock is using default 32KHz from 24M / 750.
>       need to find some place to put clk_set_rate call.
>
>    2. BCM43362 out-of-band interrupts not supported.
>       OOB interrupt in brcmfmac is set using platform data.
>       Need to put this is board code, or add device tree support.
>
> Core ID and addresses were found using bcmdhd driver debug output.
> Arend might want to take a look at the patch:
>
>    https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>
> Working tree:
>
>    https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> Comments welcome :)

Awesome! So now we have this working in upstream before we have it working with
3.4 kernels (at-least I've never managed to get it to work with 3.4 kernels).

Very nice Christmas present, thanks :)

I'll give this a spin and add it to the sunxi-devel branch.

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

[-- Attachment #1: Type: text/plain, Size: 4881 bytes --]

On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>> brcmfmac driver in the near future?
>>>>>>
>>>>>> Hi Julian,
>>>>>>
>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>> Just have to go after a firmware image to be sure.
>>>>>
>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>
>>>> No cubietruck here. I googled the term last week because it came up and
>>>> found embeddedcomputer.nl selling it.
>>>>
>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>> nice if we could also get the wifi and bluetooth to work here.
>>
>> I got the chip to respond to probing. It is BCM43362 for sure.
>>
>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>   0xa962
>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>   0x02d0
>>
>> Vendor ID is Broadcom. Device ID is 43362.
>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>> if this is normal or not.

There might be three devices/functions. The last digit of the device
indicates the SDIO function number. Function 1 allows access to F1
registers in the SDIO core of the device and F2 is for WLAN
functionality. F3 could be providing BT functionality, but I am not
familiar with that part.

> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
> You can use firmware from CubieTech images.

brcmfmac does not support monitor mode. It does support AP mode and P2P
modes.

> Things missing:
> 
>   1. output clock is using default 32KHz from 24M / 750.
>      need to find some place to put clk_set_rate call.

What clock is this? You mean there is a clock output driven by the
AP6210 module or Cubieboard provides it to the module.

>   2. BCM43362 out-of-band interrupts not supported.
>      OOB interrupt in brcmfmac is set using platform data.
>      Need to put this is board code, or add device tree support.

It would be good to add device tree support so the driver can first look
for device tree data and have platform data and in-band as backup mechanism.

> Core ID and addresses were found using bcmdhd driver debug output.
> Arend might want to take a look at the patch:
> 
>   https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865

I have different addresses from the chip documentation, but my test spin
went poorly. So much for hardware documentation. I will give these
values a try. In my patch there is also bcm43362 specific SDIO drive
strength programming (see attachment). The patch won't apply as my tree
is a bit different due to some rework in the SDIO part of brcmfmac. So
you probably need to pick the missing part from it.

> Working tree:
> 
>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
> 
> Comments welcome :)

No comment, but: Nice work!

Gr. AvS

>>
>> Bluetooth still isn't responding.
> 
> Bluetooth still not working. :(
> Has anyone had any luck with this?
> 
>>
>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>> wifi looks like ?
>>>>
>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>> host and interrupt line.
>>>
>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>> to the driver. Last, it takes a clock output out of the A20 for the
>>> low power 32k clock. Not sure if this is mandatory?
>>>
>>> I've read the schematics more than a few times. I can get a dts out
>>> tomorrow. I was planning on doing the clock output and rfkill part
>>> first.
>>
>> Here's my tree, in case anyone wants to play around. It will be rebased
>> a lot.
>>
>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>
>> The DT is not finished yet. External interrupts and low power clock are
>> still missing. Can anyone provide an example for useing the PIO EINT
>> interrupt pins?
>>
>>
>> Cheers,
>>
>> ChenYu


[-- Attachment #2: 0001-brcmfmac-add-support-for-bcm43362-device.patch --]
[-- Type: text/x-patch, Size: 6048 bytes --]

>From 0bad779042b7807f0476e9b5098f943d4ace33ee Mon Sep 17 00:00:00 2001
From: Arend van Spriel <arend@broadcom.com>
Date: Tue, 17 Dec 2013 20:33:43 +0100
Subject: [PATCH] brcmfmac: add support for bcm43362 device

This patch adds support for the bcm43362 1x1 11n chipset.

Reviewed-by: Franky Lin <frankyl@broadcom.com>
Reviewed-by: Pieter-Paul Giesberts <pieterpg@broadcom.com>
Reviewed-by: Hante Meuleman <meuleman@broadcom.com>
Signed-off-by: Arend van Spriel <arend@broadcom.com>
---
 drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c   |    1 +
 drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c |    5 +++
 .../net/wireless/brcm80211/brcmfmac/sdio_chip.c    |   33 ++++++++++++++++++++
 .../net/wireless/brcm80211/brcmfmac/sdio_chip.h    |    1 +
 .../net/wireless/brcm80211/include/brcm_hw_ids.h   |    1 +
 5 files changed, 41 insertions(+)

diff --git a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
index ae0e0c9..d8dc356 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/bcmsdh.c
@@ -948,6 +948,7 @@ static const struct sdio_device_id brcmf_sdmmc_ids[] = {
 	{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4329)},
 	{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4330)},
 	{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_4334)},
+	{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM, SDIO_DEVICE_ID_BROADCOM_43362)},
 	{SDIO_DEVICE(SDIO_VENDOR_ID_BROADCOM,
 		     SDIO_DEVICE_ID_BROADCOM_4335_4339)},
 	{ /* end: all zeroes */ },
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
index 270cf9b..d7655eb 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/dhd_sdio.c
@@ -511,6 +511,8 @@ enum brcmf_sdio_frmtype {
 #define BCM4335_NVRAM_NAME		"brcm/brcmfmac4335-sdio.txt"
 #define BCM4339_FIRMWARE_NAME		"brcm/brcmfmac4339-sdio.bin"
 #define BCM4339_NVRAM_NAME		"brcm/brcmfmac4339-sdio.txt"
+#define BCM43362_FIRMWARE_NAME		"brcm/brcmfmac43362-sdio.bin"
+#define BCM43362_NVRAM_NAME		"brcm/brcmfmac43362-sdio.txt"
 
 MODULE_FIRMWARE(BCM43143_FIRMWARE_NAME);
 MODULE_FIRMWARE(BCM43143_NVRAM_NAME);
@@ -528,6 +530,8 @@ MODULE_FIRMWARE(BCM4335_FIRMWARE_NAME);
 MODULE_FIRMWARE(BCM4335_NVRAM_NAME);
 MODULE_FIRMWARE(BCM4339_FIRMWARE_NAME);
 MODULE_FIRMWARE(BCM4339_NVRAM_NAME);
+MODULE_FIRMWARE(BCM43362_FIRMWARE_NAME);
+MODULE_FIRMWARE(BCM43362_NVRAM_NAME);
 
 struct brcmf_firmware_names {
 	u32 chipid;
@@ -552,6 +556,7 @@ static const struct brcmf_firmware_names brcmf_fwname_data[] = {
 	{ BCM4330_CHIP_ID, 0xFFFFFFFF, BRCMF_FIRMWARE_NVRAM(BCM4330) },
 	{ BCM4334_CHIP_ID, 0xFFFFFFFF, BRCMF_FIRMWARE_NVRAM(BCM4334) },
 	{ BCM4335_CHIP_ID, 0xFFFFFFFF, BRCMF_FIRMWARE_NVRAM(BCM4335) },
+	{ BCM43362_CHIP_ID, 0xFFFFFFFF, BRCMF_FIRMWARE_NVRAM(BCM43362) },
 	{ BCM4339_CHIP_ID, 0xFFFFFFFF, BRCMF_FIRMWARE_NVRAM(BCM4339) }
 };
 
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
index 5f39f28..2243b02 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.c
@@ -83,6 +83,17 @@ static const struct sdiod_drive_str sdiod_drvstr_tab1_1v8[] = {
 	{0, 0x1}
 };
 
+/* SDIO Drive Strength to sel value table for PMU Rev 13 (1.8v) */
+static const struct sdiod_drive_str sdiod_drive_strength_tab5_1v8[] = {
+        {6, 0x7},
+        {5, 0x6},
+        {4, 0x5},
+        {3, 0x4},
+        {2, 0x2},
+        {1, 0x1},
+        {0, 0x0}
+};
+
 /* SDIO Drive Strength to sel value table for 43143 PMU Rev 17 (3.3V) */
 static const struct sdiod_drive_str sdiod_drvstr_tab2_3v3[] = {
 	{16, 0x7},
@@ -569,6 +580,23 @@ static int brcmf_sdio_chip_recognition(struct brcmf_sdio_dev *sdiodev,
 		ci->ramsize = 0xc0000;
 		ci->rambase = 0x180000;
 		break;
+	case BCM43362_CHIP_ID:
+		ci->c_inf[0].wrapbase = 0x18100000;
+		ci->c_inf[0].cib = 0x1c004211;
+		ci->c_inf[1].id = BCMA_CORE_SDIO_DEV;
+		ci->c_inf[1].base = 0x18002000;
+		ci->c_inf[1].wrapbase = 0x18102000;
+		ci->c_inf[1].cib = 0x01004211;
+		ci->c_inf[2].id = BCMA_CORE_INTERNAL_MEM;
+		ci->c_inf[2].base = 0x18004000;
+		ci->c_inf[2].wrapbase = 0x18104000;
+		ci->c_inf[2].cib = 0x06080401;
+		ci->c_inf[3].id = BCMA_CORE_ARM_CM3;
+		ci->c_inf[3].base = 0x18003000;
+		ci->c_inf[3].wrapbase = 0x18103000;
+		ci->c_inf[3].cib = 0x01004211;
+		ci->ramsize = 0x3C000;
+		break;
 	default:
 		brcmf_err("chipid 0x%x is not supported\n", ci->chip);
 		return -ENODEV;
@@ -769,6 +797,11 @@ brcmf_sdio_chip_drivestrengthinit(struct brcmf_sdio_dev *sdiodev,
 				  brcmf_sdio_chip_name(ci->chip, chn, 8),
 				  drivestrength);
 		break;
+	case SDIOD_DRVSTR_KEY(BCM43362_CHIP_ID, 13):
+		str_tab = sdiod_drive_strength_tab5_1v8;
+		str_mask = 0x00003800;
+		str_shift = 11;
+		break;
 	default:
 		brcmf_err("No SDIO Drive strength init done for chip %s rev %d pmurev %d\n",
 			  brcmf_sdio_chip_name(ci->chip, chn, 8),
diff --git a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.h b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.h
index d0f4b45..d0253af 100644
--- a/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.h
+++ b/drivers/net/wireless/brcm80211/brcmfmac/sdio_chip.h
@@ -61,6 +61,7 @@
 #define SDIO_DEVICE_ID_BROADCOM_4330		0x4330
 #define SDIO_DEVICE_ID_BROADCOM_4334		0x4334
 #define SDIO_DEVICE_ID_BROADCOM_4335_4339	0x4335
+#define SDIO_DEVICE_ID_BROADCOM_43362		43362
 
 struct chip_core_info {
 	u16 id;
diff --git a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
index 84113ea..1039f7e 100644
--- a/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
+++ b/drivers/net/wireless/brcm80211/include/brcm_hw_ids.h
@@ -42,5 +42,6 @@
 #define BCM4334_CHIP_ID		0x4334
 #define BCM4335_CHIP_ID		0x4335
 #define BCM4339_CHIP_ID		0x4339
+#define BCM43362_CHIP_ID	43362
 
 #endif				/* _BRCM_HW_IDS_H_ */
-- 
1.7.10.4

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>>> brcmfmac driver in the near future?
>>>>>>>
>>>>>>> Hi Julian,
>>>>>>>
>>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>>> Just have to go after a firmware image to be sure.
>>>>>>
>>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>>
>>>>> No cubietruck here. I googled the term last week because it came up and
>>>>> found embeddedcomputer.nl selling it.
>>>>>
>>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>>> nice if we could also get the wifi and bluetooth to work here.
>>>
>>> I got the chip to respond to probing. It is BCM43362 for sure.
>>>
>>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>>   0xa962
>>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>>   0x02d0
>>>
>>> Vendor ID is Broadcom. Device ID is 43362.
>>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>>> if this is normal or not.
>
> There might be three devices/functions. The last digit of the device
> indicates the SDIO function number. Function 1 allows access to F1
> registers in the SDIO core of the device and F2 is for WLAN
> functionality. F3 could be providing BT functionality, but I am not
> familiar with that part.
>
>> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
>> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
>> You can use firmware from CubieTech images.
>
> brcmfmac does not support monitor mode. It does support AP mode and P2P
> modes.
>
>> Things missing:
>>
>>   1. output clock is using default 32KHz from 24M / 750.
>>      need to find some place to put clk_set_rate call.
>
> What clock is this? You mean there is a clock output driven by the
> AP6210 module or Cubieboard provides it to the module.

Cubieboard provides it to the module.

BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz
clock as low power clock. They can also use internal oscillator for
this, so it is optional. But according to BCM20710 datasheet, this
external clock is required to auto-detect the frequency of the main
oscillator if it's not the default 20MHz. On the CubieTruck, it is
26 MHz. For just WiFi, I think we don't need it.

>>   2. BCM43362 out-of-band interrupts not supported.
>>      OOB interrupt in brcmfmac is set using platform data.
>>      Need to put this is board code, or add device tree support.
>
> It would be good to add device tree support so the driver can first look
> for device tree data and have platform data and in-band as backup mechanism.

I'm not sure how to add support. Add a child node to the SD/MMC
controller, perhaps? I thought SDIO devices were like USB, in
that the system scans the bus and detects them.

>> Core ID and addresses were found using bcmdhd driver debug output.
>> Arend might want to take a look at the patch:
>>
>>   https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>
> I have different addresses from the chip documentation, but my test spin
> went poorly. So much for hardware documentation. I will give these
> values a try. In my patch there is also bcm43362 specific SDIO drive
> strength programming (see attachment). The patch won't apply as my tree
> is a bit different due to some rework in the SDIO part of brcmfmac. So
> you probably need to pick the missing part from it.

Maybe it's a remarked chip? (is that possible?)
The firmware CubieTech has is for a BCM40181 though.

Added the drive strength programming by hand. Changed the table variable
name to match the others. Pushed on to my tree. Beware there are some
hacks trying to get BT to work. :p

>
>> Working tree:
>>
>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>
>> Comments welcome :)
>
> No comment, but: Nice work!

Thanks. BTW, who should submit the patch? :)


ChenYu

>
> Gr. AvS
>
>>>
>>> Bluetooth still isn't responding.
>>
>> Bluetooth still not working. :(
>> Has anyone had any luck with this?
>>
>>>
>>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>>> wifi looks like ?
>>>>>
>>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>>> host and interrupt line.
>>>>
>>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>>> to the driver. Last, it takes a clock output out of the A20 for the
>>>> low power 32k clock. Not sure if this is mandatory?
>>>>
>>>> I've read the schematics more than a few times. I can get a dts out
>>>> tomorrow. I was planning on doing the clock output and rfkill part
>>>> first.
>>>
>>> Here's my tree, in case anyone wants to play around. It will be rebased
>>> a lot.
>>>
>>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>
>>> The DT is not finished yet. External interrupts and low power clock are
>>> still missing. Can anyone provide an example for useing the PIO EINT
>>> interrupt pins?
>>>
>>>
>>> Cheers,
>>>
>>> ChenYu
>
> --
> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
> Hi,
> 
> On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 12/26/2013 05:13 PM, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Thu, Dec 19, 2013 at 6:12 PM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>> Hi,
>>>>
>>>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>>>>> Hi,
>>>>>
>>>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>>>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>>>>> brcmfmac driver in the near future?
>>>>>>>>
>>>>>>>> Hi Julian,
>>>>>>>>
>>>>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>>>>> Just have to go after a firmware image to be sure.
>>>>>>>
>>>>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>>>>
>>>>>> No cubietruck here. I googled the term last week because it came up and
>>>>>> found embeddedcomputer.nl selling it.
>>>>>>
>>>>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>>>>> nice if we could also get the wifi and bluetooth to work here.
>>>>
>>>> I got the chip to respond to probing. It is BCM43362 for sure.
>>>>
>>>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>>>>   0xa962
>>>>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>>>>   0x02d0
>>>>
>>>> Vendor ID is Broadcom. Device ID is 43362.
>>>> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
>>>> if this is normal or not.
>>
>> There might be three devices/functions. The last digit of the device
>> indicates the SDIO function number. Function 1 allows access to F1
>> registers in the SDIO core of the device and F2 is for WLAN
>> functionality. F3 could be providing BT functionality, but I am not
>> familiar with that part.
>>
>>> Merry Christmas everyone. I got AP6210 (BCM43362) to work with mainline
>>> brcmfmac driver. I only tested managed mode. Monitor mode does not work.
>>> You can use firmware from CubieTech images.
>>
>> brcmfmac does not support monitor mode. It does support AP mode and P2P
>> modes.
>>
>>> Things missing:
>>>
>>>   1. output clock is using default 32KHz from 24M / 750.
>>>      need to find some place to put clk_set_rate call.
>>
>> What clock is this? You mean there is a clock output driven by the
>> AP6210 module or Cubieboard provides it to the module.
> 
> Cubieboard provides it to the module.
> 
> BCM43362 (WiFi) and BCM20710 (BT) both accept an external 32768 Hz
> clock as low power clock. They can also use internal oscillator for
> this, so it is optional. But according to BCM20710 datasheet, this
> external clock is required to auto-detect the frequency of the main
> oscillator if it's not the default 20MHz. On the CubieTruck, it is
> 26 MHz. For just WiFi, I think we don't need it.
> 
>>>   2. BCM43362 out-of-band interrupts not supported.
>>>      OOB interrupt in brcmfmac is set using platform data.
>>>      Need to put this is board code, or add device tree support.
>>
>> It would be good to add device tree support so the driver can first look
>> for device tree data and have platform data and in-band as backup mechanism.
> 
> I'm not sure how to add support. Add a child node to the SD/MMC
> controller, perhaps? I thought SDIO devices were like USB, in
> that the system scans the bus and detects them.
> 
>>> Core ID and addresses were found using bcmdhd driver debug output.
>>> Arend might want to take a look at the patch:
>>>
>>>   https://github.com/wens/linux/commit/d945809d27de930eba5db0ca4bb7936e3ca88865
>>
>> I have different addresses from the chip documentation, but my test spin
>> went poorly. So much for hardware documentation. I will give these
>> values a try. In my patch there is also bcm43362 specific SDIO drive
>> strength programming (see attachment). The patch won't apply as my tree
>> is a bit different due to some rework in the SDIO part of brcmfmac. So
>> you probably need to pick the missing part from it.
> 
> Maybe it's a remarked chip? (is that possible?)
> The firmware CubieTech has is for a BCM40181 though.
> 
> Added the drive strength programming by hand. Changed the table variable
> name to match the others. Pushed on to my tree. Beware there are some
> hacks trying to get BT to work. :p
> 
>>
>>> Working tree:
>>>
>>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>
>>> Comments welcome :)
>>
>> No comment, but: Nice work!
> 
> Thanks. BTW, who should submit the patch? :)

Hi Chen-Yu,

I confirmed the patch is working with a revision 0 of the device. What
chip revision does it give in your log (need to load brcmfmac with
module parameter debug=4).

Regards,
Arend

>>
>>>>
>>>> Bluetooth still isn't responding.
>>>
>>> Bluetooth still not working. :(
>>> Has anyone had any luck with this?
>>>
>>>>
>>>>>>> I'm certainly willing to give some patches for this a try. Do you
>>>>>>> have an example of what the dts file for a board with broadcom sdio
>>>>>>> wifi looks like ?
>>>>>>
>>>>>> I am still struggling with dts changes for a Pandaboard. As I understood
>>>>>> the cubietruck uses AP6210 module and the dts really depends on how
>>>>>> things are wired up with it. Apart from the SDIO lines it may have an
>>>>>> additional GPIO output to power the module and GPIO inputs to wakeup the
>>>>>> host and interrupt line.
>>>>>
>>>>> Yes it does. 2 GPIO lines for power, 1 for WiFi, 1 for BT.
>>>>> Also takes 2 GPIO inputs for interrupts. Not sure how to feed this
>>>>> to the driver. Last, it takes a clock output out of the A20 for the
>>>>> low power 32k clock. Not sure if this is mandatory?
>>>>>
>>>>> I've read the schematics more than a few times. I can get a dts out
>>>>> tomorrow. I was planning on doing the clock output and rfkill part
>>>>> first.
>>>>
>>>> Here's my tree, in case anyone wants to play around. It will be rebased
>>>> a lot.
>>>>
>>>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>
>>>> The DT is not finished yet. External interrupts and low power clock are
>>>> still missing. Can anyone provide an example for useing the PIO EINT
>>>> interrupt pins?
>>>>
>>>>
>>>> Cheers,
>>>>
>>>> ChenYu
>>
>> --
>> You received this message because you are subscribed to the Google Groups "linux-sunxi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to linux-sunxi+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <arend@broadcom.com> wrote:
[snip]
> Hi Chen-Yu,
>
> I confirmed the patch is working with a revision 0 of the device. What
> chip revision does it give in your log (need to load brcmfmac with
> module parameter debug=4).

Mine is revision 1. Managed mode confirmed working.

Logs:
brcmfmac: F1 signature read @0x18000000=0x1591a962
brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
rev/type=10/0x829


ChenYu

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Michal Suchanek]

On 2 January 2014 20:22, Rosimildo DaSilva <rosimildo@gmail.com> wrote:
> It would be nice to be precise about what is working:
>
> a) Wifi + BT
> b) WIFI only
> c) BT only
>
> Reading the thread, it seems you got (a) WIFI + BT working. Is this correct

No, it's b)

There is some bit missing for BT. Possibly setting the power and reset
gpio pins correctly. Or maybe the uart is set up with wrong
parameters.

Thanks

Michal

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/02/2014 08:22 PM, Rosimildo DaSilva wrote:
> It would be nice to be precise about what is working:
> 
> a) Wifi + BT
> b) WIFI only
> c) BT only
> 
> Reading the thread, it seems you got (a) WIFI + BT working. Is this correct 
> ?

I think you need to read the thread once more. Wifi is working, no life
sign from the BT using UART, ie. (b).

Gr. AvS

> R
> 
> 
> On Thursday, January 2, 2014 11:09:12 AM UTC-6, Chen-Yu Tsai wrote:
>>
>> Hi, 
>>
>> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <ar...@broadcom.com<javascript:>> 
>> wrote: 
>> [snip] 
>>> Hi Chen-Yu, 
>>>
>>> I confirmed the patch is working with a revision 0 of the device. What 
>>> chip revision does it give in your log (need to load brcmfmac with 
>>> module parameter debug=4). 
>>
>> Mine is revision 1. Managed mode confirmed working. 
>>
>> Logs: 
>> brcmfmac: F1 signature read @0x18000000=0x1591a962 
>> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1 
>> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore 
>> rev/type=10/0x829 
>>
>>
>> ChenYu 
>>
> 

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote:
> Hi,
> 
> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <arend@broadcom.com> wrote:
> [snip]
>> Hi Chen-Yu,
>>
>> I confirmed the patch is working with a revision 0 of the device. What
>> chip revision does it give in your log (need to load brcmfmac with
>> module parameter debug=4).
> 
> Mine is revision 1. Managed mode confirmed working.

Which firmware did you use. Can you provide 'hexdump -C' output
(especially the last part).

Gr. AvS

> Logs:
> brcmfmac: F1 signature read @0x18000000=0x1591a962
> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
> rev/type=10/0x829
> 
> 
> ChenYu
> 

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Fri, Jan 3, 2014 at 5:03 AM, Arend van Spriel <arend@broadcom.com> wrote:
> On 01/02/2014 06:09 PM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> [snip]
>>> Hi Chen-Yu,
>>>
>>> I confirmed the patch is working with a revision 0 of the device. What
>>> chip revision does it give in your log (need to load brcmfmac with
>>> module parameter debug=4).
>>
>> Mine is revision 1. Managed mode confirmed working.
>
> Which firmware did you use. Can you provide 'hexdump -C' output
> (especially the last part).
>

I used fw_bcm40181a2.bin.

MD5 sum: ce95e81aa95f9dc1a32fb8acf691dbd8  fw_bcm40181a2.bin

Here's the last part of the dump.

root@cubietruck:/lib/firmware/brcm# hexdump -C brcmfmac43362-sdio.bin | tail
00035920  01 bd 32 08 01 00 34 33  33 36 32 61 32 2d 72 6f  |..2...43362a2-ro|
00035930  6d 6c 2f 73 64 69 6f 2d  67 2d 70 6e 6f 2d 70 6b  |ml/sdio-g-pno-pk|
00035940  74 66 69 6c 74 65 72 2d  6b 65 65 70 61 6c 69 76  |tfilter-keepaliv|
00035950  65 2d 77 61 70 69 2d 77  6d 65 2d 70 32 70 20 56  |e-wapi-wme-p2p V|
00035960  65 72 73 69 6f 6e 3a 20  35 2e 39 30 2e 31 39 35  |ersion: 5.90.195|
00035970  2e 38 39 20 43 52 43 3a  20 62 64 31 65 33 65 35  |.89 CRC: bd1e3e5|
00035980  61 20 44 61 74 65 3a 20  4d 6f 6e 20 32 30 31 33  |a Date: Mon 2013|
00035990  2d 30 34 2d 32 32 20 31  37 3a 32 34 3a 34 34 20  |-04-22 17:24:44 |
000359a0  43 53 54 7d 00                                    |CST}.|
000359a5


ChenYu

> Gr. AvS
>
>> Logs:
>> brcmfmac: F1 signature read @0x18000000=0x1591a962
>> brcmfmac: brcmf_sdio_chip_recognition chipid=0xa962 chiprev=1
>> brcmfmac: brcmf_sdio_chip_buscoresetup ccrev=39, pmurev=13, buscore
>> rev/type=10/0x829
>>
>>
>> ChenYu
>>
>

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>> >> Working tree:
>>> >>
>>> >>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>> >>
>>> >> Comments welcome :)
>> >
>> > No comment, but: Nice work!
> Thanks. BTW, who should submit the patch? :)

Hi Chen-Yu

I will submit the patch today.

Regards,
Arend

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>> >> Working tree:
>>>> >>
>>>> >>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>> >>
>>>> >> Comments welcome :)
>>> >
>>> > No comment, but: Nice work!
>> Thanks. BTW, who should submit the patch? :)
>
> Hi Chen-Yu
>
> I will submit the patch today.

Great!

I added device tree support for brcmfmac SDIO devices,
to be able to specify external out-of-band interrupts.
Unfortunately it's not working. I get the following output:

brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
brcmfmac: brcmf_fil_cmd_data: Failed err=-110
brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
brcmfmac: brcmf_bus_start: failed: -110
brcmfmac: brcmf_sdbrcm_probe: dongle is not responding
brcmfmac: brcmf_sdio_probe: device attach failed
brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...

Should we add device tree support for the brcmf platform driver,
so we can enable power, clocks, etc. before the SDIO driver is probed?

Not sure if this is the right way. Maxime mentioned on IRC that some
mmc host drivers take a vmmc regulator property.

Currently I am using rfkill-gpio to do this. But brcmfmac also
registers an rfkill of its own.

Also, I have bluetooth working. Turns out it was a wrong pinctrl
setting in my dt. For those who want to try:

  Get and compile brcm_patchram_plus from
  http://code.google.com/p/broadcom-bluetooth/

  Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
  and hciattach /dev/ttyS1

  If brcm_patchram_plus hangs, you may need to reset the controller
  by blocking then unblocking the bluetooth rfkill switch.

I pushed all my work out already. Here's the link again:

  https://github.com/wens/linux/tree/wip/sunxi-next-wifi


Cheers
ChenYu

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/08/2014 10:23 AM, Chen-Yu Tsai wrote:
> On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>>>>> Working tree:
>>>>>>>
>>>>>>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>>>>
>>>>>>> Comments welcome :)
>>>>>
>>>>> No comment, but: Nice work!
>>> Thanks. BTW, who should submit the patch? :)
>>
>> Hi Chen-Yu
>>
>> I will submit the patch today.
> 
> Great!
> 
> I added device tree support for brcmfmac SDIO devices,
> to be able to specify external out-of-band interrupts.
> Unfortunately it's not working. I get the following output:
> 
> brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
> brcmfmac: brcmf_fil_cmd_data: Failed err=-110
> brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
> brcmfmac: brcmf_bus_start: failed: -110
> brcmfmac: brcmf_sdbrcm_probe: dongle is not responding

This is typeical behaviour when interrupt is not picked up.

> brcmfmac: brcmf_sdio_probe: device attach failed
> brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
> 
> Should we add device tree support for the brcmf platform driver,
> so we can enable power, clocks, etc. before the SDIO driver is probed?

How does the device-tree change for oob interrupt look like.

> Not sure if this is the right way. Maxime mentioned on IRC that some
> mmc host drivers take a vmmc regulator property.
> 
> Currently I am using rfkill-gpio to do this. But brcmfmac also
> registers an rfkill of its own.

Not sure what you mean here. The only thing I am aware of is that
cfg80211 registers brcmfmac as wifi transmitter in the rfkill framework,
which is unrelated to gpio's.

> Also, I have bluetooth working. Turns out it was a wrong pinctrl
> setting in my dt. For those who want to try:
> 
>   Get and compile brcm_patchram_plus from
>   http://code.google.com/p/broadcom-bluetooth/
> 
>   Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
>   and hciattach /dev/ttyS1
> 
>   If brcm_patchram_plus hangs, you may need to reset the controller
>   by blocking then unblocking the bluetooth rfkill switch.
> 
> I pushed all my work out already. Here's the link again:
> 
>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi

I will take a look.

Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

On Wed, Jan 8, 2014 at 5:33 PM, Arend van Spriel <arend@broadcom.com> wrote:
> On 01/08/2014 10:23 AM, Chen-Yu Tsai wrote:
>> On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote:
>>>>>>>> Working tree:
>>>>>>>>
>>>>>>>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>>>>>>>>
>>>>>>>> Comments welcome :)
>>>>>>
>>>>>> No comment, but: Nice work!
>>>> Thanks. BTW, who should submit the patch? :)
>>>
>>> Hi Chen-Yu
>>>
>>> I will submit the patch today.
>>
>> Great!
>>
>> I added device tree support for brcmfmac SDIO devices,
>> to be able to specify external out-of-band interrupts.
>> Unfortunately it's not working. I get the following output:
>>
>> brcmfmac: brcmf_sdbrcm_bus_rxctl: resumed on timeout
>> brcmfmac: brcmf_fil_cmd_data: Failed err=-110
>> brcmfmac: brcmf_c_preinit_dcmds: Retreiving cur_etheraddr failed, -110
>> brcmfmac: brcmf_bus_start: failed: -110
>> brcmfmac: brcmf_sdbrcm_probe: dongle is not responding
>
> This is typeical behaviour when interrupt is not picked up.

Maxime said the pinctrl irq chip driver wasn't tested,
so not picking up an interrupt isn't a big surprise.

>> brcmfmac: brcmf_sdio_probe: device attach failed
>> brcmfmac: brcmf_ops_sdio_probe: F2 error, probe failed -19...
>>
>> Should we add device tree support for the brcmf platform driver,
>> so we can enable power, clocks, etc. before the SDIO driver is probed?
>
> How does the device-tree change for oob interrupt look like.

See https://github.com/wens/linux/blob/wip/sunxi-next-wifi/arch/arm/boot/dts/sun7i-a20-cubietruck.dts#L38


The platform driver device node would be something like:

/{
        brcmf {
                compatible = "broadcom,brcmf";
                vbat-supply = <&wifi_pwr_regulator>;
                /* maybe other regulators */
                clocks = <&wifi_main>, <&wifi_lpo>;
                clock-names = "main", "lpo";
                reset-gpio = <&gpio A B C>;
        };
};

>> Not sure if this is the right way. Maxime mentioned on IRC that some
>> mmc host drivers take a vmmc regulator property.
>>
>> Currently I am using rfkill-gpio to do this. But brcmfmac also
>> registers an rfkill of its own.
>
> Not sure what you mean here. The only thing I am aware of is that
> cfg80211 registers brcmfmac as wifi transmitter in the rfkill framework,
> which is unrelated to gpio's.

They are unrelated, but overlapping I suppose.

https://github.com/wens/linux/blob/wip/sunxi-next-wifi/arch/arm/boot/dts/sun7i-a20-cubietruck.dts#L220

Here I register a wifi rfkill that switches the brcmfmac device on or off.
If it is off the device disappears from the system. Not sure if the kernel
would detect it when we turn it back on.

IMO the rfkill framework by design should only turn off the RF part of the
device, not the controller altogether.

Feedback on this or other patches in my tree is much appreciated.


Thanks
ChenYu

>> Also, I have bluetooth working. Turns out it was a wrong pinctrl
>> setting in my dt. For those who want to try:
>>
>>   Get and compile brcm_patchram_plus from
>>   http://code.google.com/p/broadcom-bluetooth/
>>
>>   Run brcm_patchram_plus --patchram bcm20710a1.hcd --no2bytes /dev/ttyS1
>>   and hciattach /dev/ttyS1
>>
>>   If brcm_patchram_plus hangs, you may need to reset the controller
>>   by blocking then unblocking the bluetooth rfkill switch.
>>
>> I pushed all my work out already. Here's the link again:
>>
>>   https://github.com/wens/linux/tree/wip/sunxi-next-wifi
>
> I will take a look.
>
> Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

I've been working on updating sunxi-devel to include more
recent versions if your gmac patches, as well as adding support
for the wifi + bluetooth found on the cubietruck.

Here is my current work on this:

https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel

It is close to working, but unfortunately it does not work,
here is what I get in dmesg when I modprove the module:

[   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
[  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0: Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
[  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
[  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
[  100.322508] usbcore: registered new interface driver brcmfmac
[  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
...

This is using the firmware + nvram found here:
http://dl.cubieboard.org/public/Cubieboard/benn/firmware/ap6210/

Wens' can you give my tree a try? And which version of the firmware +
nvram are you using ?

Thanks & Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/23/2014 11:39 PM, Hans de Goede wrote:
> Hi,
> 
> I've been working on updating sunxi-devel to include more
> recent versions if your gmac patches, as well as adding support
> for the wifi + bluetooth found on the cubietruck.
> 
> Here is my current work on this:
> 
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
> 
> It is close to working, but unfortunately it does not work,
> here is what I get in dmesg when I modprove the module:
> 
> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
> [  100.322508] usbcore: registered new interface driver brcmfmac
> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)

Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
a look.

Regards,
Arend

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/24/2014 11:25 AM, Arend van Spriel wrote:
> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>> Hi,
>>
>> I've been working on updating sunxi-devel to include more
>> recent versions if your gmac patches, as well as adding support
>> for the wifi + bluetooth found on the cubietruck.
>>
>> Here is my current work on this:
>>
>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>
>> It is close to working, but unfortunately it does not work,
>> here is what I get in dmesg when I modprove the module:
>>
>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>> [  100.322508] usbcore: registered new interface driver brcmfmac
>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>
> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
> a look.

I've captured a log with these flags until the first "Scanning already"
message, you can find it here:

http://people.fedoraproject.org/~jwrdegoede/log2

Thanks for looking into this.

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/24/2014 05:34 PM, Hans de Goede wrote:
> Hi,
> 
> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> I've been working on updating sunxi-devel to include more
>>> recent versions if your gmac patches, as well as adding support
>>> for the wifi + bluetooth found on the cubietruck.
>>>
>>> Here is my current work on this:
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>
>>> It is close to working, but unfortunately it does not work,
>>> here is what I get in dmesg when I modprove the module:
>>>
>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>
>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>> a look.
> 
> I've captured a log with these flags until the first "Scanning already"
> message, you can find it here:

Bedankt, Hans

Looking at the log it looks more or less ok. wpa_supplicant (assume you
use that) first does three regular scans which end with no APs found.
Not sure why that happens unless you are in a shielded room :-) After
those scans wpa_supplicant tries to tell the device to do a so-called
scheduled scan. Basically, it is a scan offload. However, the driver
still thinks there is a regular scan ongoing. This needs to be
investigated more. I tried to get your repo from github, but got:

error: The requested URL returned error: 403 Forbidden while accessing
https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel/info/refs
fatal: HTTP request failed

Gr. AvS

> http://people.fedoraproject.org/~jwrdegoede/log2
> 
> Thanks for looking into this.
> 
> Regards,
> 
> Hans
> -- 
> To unsubscribe from this list: send the line "unsubscribe
> linux-wireless" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> still thinks there is a regular scan ongoing. This needs to be
> investigated more. I tried to get your repo from github, but got:
> 
> error: The requested URL returned error: 403 Forbidden while accessing
> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel/info/refs
> fatal: HTTP request failed

Never mind. Was using the wrong URL.

Gr. AvS

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-) After
> those scans wpa_supplicant tries to tell the device to do a so-called
> scheduled scan. Basically, it is a scan offload. However, the driver
> still thinks there is a regular scan ongoing. This needs to be
> investigated more.

Thanks for looking into this. I've nothing scheduled this entire Sunday
except working on hobby projects. If there is anything I can do to help,
you can find me in #linux-sunxi on freenode irc. My nick is hansg.

I would really like to get this working, so feel free to poke me to run
any tests / debug log gathering exercises you think will be helpful.

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/26/2014 11:23 AM, Hans de Goede wrote:
> Hi,
> 
> On 01/26/2014 09:53 AM, Arend van Spriel wrote:
>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> I've been working on updating sunxi-devel to include more
>>>>> recent versions if your gmac patches, as well as adding support
>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>
>>>>> Here is my current work on this:
>>>>>
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>
>>>>> It is close to working, but unfortunately it does not work,
>>>>> here is what I get in dmesg when I modprove the module:
>>>>>
>>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>> wl0:
>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>
>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>> have
>>>> a look.
>>>
>>> I've captured a log with these flags until the first "Scanning already"
>>> message, you can find it here:
>>
>> Bedankt, Hans
>>
>> Looking at the log it looks more or less ok. wpa_supplicant (assume you
>> use that) first does three regular scans which end with no APs found.
>> Not sure why that happens unless you are in a shielded room :-) After
>> those scans wpa_supplicant tries to tell the device to do a so-called
>> scheduled scan. Basically, it is a scan offload. However, the driver
>> still thinks there is a regular scan ongoing. This needs to be
>> investigated more.
> 
> Thanks for looking into this. I've nothing scheduled this entire Sunday
> except working on hobby projects. If there is anything I can do to help,
> you can find me in #linux-sunxi on freenode irc. My nick is hansg.
> 
> I would really like to get this working, so feel free to poke me to run
> any tests / debug log gathering exercises you think will be helpful.

I did a quick diff between your brcmfmac folder and mine. I am curious
what your results are after the merge window. There has been a lot of
rework in SDIO part of brcmfmac driver.

Regards,
Arend

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/26/2014 01:58 PM, Arend van Spriel wrote:
> On 01/26/2014 11:23 AM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/26/2014 09:53 AM, Arend van Spriel wrote:
>>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've been working on updating sunxi-devel to include more
>>>>>> recent versions if your gmac patches, as well as adding support
>>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>>
>>>>>> Here is my current work on this:
>>>>>>
>>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>>
>>>>>> It is close to working, but unfortunately it does not work,
>>>>>> here is what I get in dmesg when I modprove the module:
>>>>>>
>>>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>>> wl0:
>>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>>> already: status (1)
>>>>>
>>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>>> have
>>>>> a look.
>>>>
>>>> I've captured a log with these flags until the first "Scanning already"
>>>> message, you can find it here:
>>>
>>> Bedankt, Hans
>>>
>>> Looking at the log it looks more or less ok. wpa_supplicant (assume you
>>> use that) first does three regular scans which end with no APs found.
>>> Not sure why that happens unless you are in a shielded room :-) After
>>> those scans wpa_supplicant tries to tell the device to do a so-called
>>> scheduled scan. Basically, it is a scan offload. However, the driver
>>> still thinks there is a regular scan ongoing. This needs to be
>>> investigated more.
>>
>> Thanks for looking into this. I've nothing scheduled this entire Sunday
>> except working on hobby projects. If there is anything I can do to help,
>> you can find me in #linux-sunxi on freenode irc. My nick is hansg.
>>
>> I would really like to get this working, so feel free to poke me to run
>> any tests / debug log gathering exercises you think will be helpful.
>
> I did a quick diff between your brcmfmac folder and mine. I am curious
> what your results are after the merge window. There has been a lot of
> rework in SDIO part of brcmfmac driver.

Ok, I plan to rebase my tree on 3.14-rc1 when it is released. I'll run
some more tests then and let you know how things go.

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-)

Actually it seems that wifi reception in my room, combined with the low
yield of the chip antenna on the cubietruck is actually so bad that
it is possible for the list to show up empty.

I've verified this with the android image on the cubietruck, and after
moving the cubietruck around a bit to get better reception I now have
things working :)

I do wonder about the brcmf_fil_cmd_data errors though, IMHO those should
be avoided if possible.

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/26/2014 09:53 AM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Bedankt, Hans
>
> Looking at the log it looks more or less ok. wpa_supplicant (assume you
> use that) first does three regular scans which end with no APs found.
> Not sure why that happens unless you are in a shielded room :-)

One last update, although everything works now, after some more testing
I'm also seeing these messages:

[  262.533803] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4)
[  262.540078] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5)
[ 1059.641594] brcmfmac: brcmf_cfg80211_del_key: invalid key index (4)
[ 1059.647872] brcmfmac: brcmf_cfg80211_del_key: invalid key index (5)
[ 1061.563182] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 1068.564755] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning already: status (1)
[ 1075.389881] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1075.396192] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[ 1078.172085] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1078.178394] brcmfmac: brcmf_cfg80211_scan: scan error (-11)
[ 1079.194131] brcmfmac: brcmf_cfg80211_escan: Connecting: status (3)
[ 1079.200428] brcmfmac: brcmf_cfg80211_scan: scan error (-11)

etc.

Regards,

Hans







Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/24/2014 05:34 PM, Hans de Goede wrote:
> Hi,
> 
> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> I've been working on updating sunxi-devel to include more
>>> recent versions if your gmac patches, as well as adding support
>>> for the wifi + bluetooth found on the cubietruck.
>>>
>>> Here is my current work on this:
>>>
>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>
>>> It is close to working, but unfortunately it does not work,
>>> here is what I get in dmesg when I modprove the module:
>>>
>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>> already: status (1)
>>
>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>> a look.
> 
> I've captured a log with these flags until the first "Scanning already"
> message, you can find it here:

Hi Hans,

The log looks confusing.

[  543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
[  543.512840] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0
status 0 reason 0
[  543.512849] brcmutil: event payload, len=12
[  543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
  ....m...4...
[  543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
[  543.512880] brcmfmac: brcmf_notify_escan_complete Enter
[  543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
scan: Done
[  543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
[  543.512919] brcmutil: data
[  543.512928] 00000000: 01 00 00 00
  ....
[  543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
[  543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
[  543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter

The trace messages above indicate completion of regular scan and after
that the code does:

	if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
		brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");

[  543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
n_match_sets:0 n_ssids:0
[  543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
already: status (1)

So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
That makes no sense to me or test_and_clear_bit() does something else
than I expect. Either way the scheduled scan request would be rejected
because it has 0 match_sets and ssids. Maybe this is intended to
indicate any AP is to be reported. Will look in cfg80211 whether that is
the case.

Regards,
Arend

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/26/2014 12:04 PM, Arend van Spriel wrote:
> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>> Hi,
>>
>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> I've been working on updating sunxi-devel to include more
>>>> recent versions if your gmac patches, as well as adding support
>>>> for the wifi + bluetooth found on the cubietruck.
>>>>
>>>> Here is my current work on this:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>
>>>> It is close to working, but unfortunately it does not work,
>>>> here is what I get in dmesg when I modprove the module:
>>>>
>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version = wl0:
>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>> already: status (1)
>>>
>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can have
>>> a look.
>>
>> I've captured a log with these flags until the first "Scanning already"
>> message, you can find it here:
>
> Hi Hans,
>
> The log looks confusing.
>
> [  543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
> ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
> [  543.512840] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0
> status 0 reason 0
> [  543.512849] brcmutil: event payload, len=12
> [  543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
>    ....m...4...
> [  543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
> [  543.512880] brcmfmac: brcmf_notify_escan_complete Enter
> [  543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
> scan: Done
> [  543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
> [  543.512919] brcmutil: data
> [  543.512928] 00000000: 01 00 00 00
>    ....
> [  543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
> [  543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
> [  543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter
>
> The trace messages above indicate completion of regular scan and after
> that the code does:
>
> 	if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
> 		brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");
>
> [  543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
> n_match_sets:0 n_ssids:0
> [  543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
> already: status (1)
>
> So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
> That makes no sense to me or test_and_clear_bit() does something else
> than I expect.

Once I've successfully associated these messages go away, so it is
possible that this is a bug which has been around for a while, but people
normally never see because the code path is not entered.

Or could it be that this bug gets triggered by the regular scan turning
up with 0 access points, maybe that causes it to enter a path where it
does not clear the bit in question ?

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/26/2014 01:09 PM, Hans de Goede wrote:
> Hi,
> 
> On 01/26/2014 12:04 PM, Arend van Spriel wrote:
>> On 01/24/2014 05:34 PM, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 01/24/2014 11:25 AM, Arend van Spriel wrote:
>>>> On 01/23/2014 11:39 PM, Hans de Goede wrote:
>>>>> Hi,
>>>>>
>>>>> I've been working on updating sunxi-devel to include more
>>>>> recent versions if your gmac patches, as well as adding support
>>>>> for the wifi + bluetooth found on the cubietruck.
>>>>>
>>>>> Here is my current work on this:
>>>>>
>>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-devel
>>>>>
>>>>> It is close to working, but unfortunately it does not work,
>>>>> here is what I get in dmesg when I modprove the module:
>>>>>
>>>>> [   99.700889] brcmfmac_sdio mmc1:0001:1: device tree node not found
>>>>> [  100.020984] brcmfmac: brcmf_c_preinit_dcmds: Firmware version =
>>>>> wl0:
>>>>> Apr 22 2013 14:50:00 version 5.90.195.89.6 FWID 01-b30a427d
>>>>> [  100.260948] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [  100.281260] brcmfmac: brcmf_fil_cmd_data: Failed err=-23
>>>>> [  100.322508] usbcore: registered new interface driver brcmfmac
>>>>> [  160.445215] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [  203.445404] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>> [  256.445140] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>>>>> already: status (1)
>>>>
>>>> Can you enable debug logging in brcmfmac, ie. debug=0xd416 so I can
>>>> have
>>>> a look.
>>>
>>> I've captured a log with these flags until the first "Scanning already"
>>> message, you can find it here:
>>
>> Hi Hans,
>>
>> The log looks confusing.
>>
>> [  543.512827] brcmfmac: brcmf_fweh_event_worker event ESCAN_RESULT (69)
>> ifidx 0 bsscfg 0 addr 02:00:00:00:00:00
>> [  543.512840] brcmfmac: brcmf_fweh_event_worker   version 2 flags 0
>> status 0 reason 0
>> [  543.512849] brcmutil: event payload, len=12
>> [  543.512860] 00000000: 0c 00 00 00 6d 00 00 00 34 12 00 00
>>    ....m...4...
>> [  543.512872] brcmfmac: brcmf_inform_bss scanned AP count (0)
>> [  543.512880] brcmfmac: brcmf_notify_escan_complete Enter
>> [  543.512891] brcmfmac: brcmf_notify_escan_complete ESCAN Completed
>> scan: Done
>> [  543.512911] brcmfmac: brcmf_fil_iovar_data_set name=mpc, len=4
>> [  543.512919] brcmutil: data
>> [  543.512928] 00000000: 01 00 00 00
>>    ....
>> [  543.512941] brcmfmac: brcmf_sdbrcm_bus_txctl Enter
>> [  543.512951] brcmfmac: brcmf_sdbrcm_bus_sleep Enter
>> [  543.513018] brcmfmac: brcmf_sdbrcm_bus_rxctl Enter
>>
>> The trace messages above indicate completion of regular scan and after
>> that the code does:
>>
>>     if (!test_and_clear_bit(BRCMF_SCAN_STATUS_BUSY, &cfg->scan_status))
>>         brcmf_dbg(SCAN, "Scan complete, probably P2P scan\n");
>>
>> [  543.514758] brcmfmac: brcmf_cfg80211_sched_scan_start Enter
>> n_match_sets:0 n_ssids:0
>> [  543.514777] brcmfmac: brcmf_cfg80211_sched_scan_start: Scanning
>> already: status (1)
>>
>> So the bit SCAN_STATUS_BUSY should be cleared, but you get this message.
>> That makes no sense to me or test_and_clear_bit() does something else
>> than I expect.
> 
> Once I've successfully associated these messages go away, so it is
> possible that this is a bug which has been around for a while, but people
> normally never see because the code path is not entered.
> 
> Or could it be that this bug gets triggered by the regular scan turning
> up with 0 access points, maybe that causes it to enter a path where it
> does not clear the bit in question ?

I think that is partly true or some trace messages were missing, but I
think the trigger is the 0 APs. Thanks for letting me know.

Regards,
Arend

Re: Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
> Hi,
> 
> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>> Hi,
>>
>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>
>> <snip>
>>
>>
>>>> Quick update, I've just tested:
>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>
>>>
>>> About this, I would like to move WiFi power control to a regulator,
>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>
>>
>> Actually the sunxi-mci.c driver already has support for an optional
>> regulator called vmmc.
>>
>> I like this idea, I've done a version of the dt patch using a regulator
>> instead of rfkill here:
>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>
>> This works as advertised and IMHO is the better solution.
> 
> I have a version in another branch I haven't pushed. I had it using an
> always-on regulator. I can adjust it to use vmmc.
> 
> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
> in mmc core.
> We should re-use code if possible, wouldn't you agree?
> 
>>>> About the oob interrupt stuff not working, AFAIK you should set a pinctrl
>>>> function (not input, but a function like mmc is a function) on the pin in
>>>> question
>>>> for it to work as external interrupt, I believe you're not doing so in
>>>> your
>>>> dts.
>>>
>>>
>>> The pinctrl driver seems to set the function when the interrupt is
>>> enabled.
>>> Unfortunately we don't have any documentation/examples on how to use them.
>>> I will look into that later.
>>
>>
>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>> gpio-input,
>> maybe that conflicts ?
> 
> I made a version with pinctrl entry setup as "irq", got an interrupt,
> but then the whole thing hung. Looks like pinctrl irqchip was not
> properly handling chained interrupts. I have done a simple fix, and I
> hope to test it tomorrow. Then I'll do some more testing with different
> configurations and hopefully write some documents.

Hi Chen-Yu,

I had a look at github tree from Hans with your DT support patch for
brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
the bindings are still experimental, but I would prefer you to use brcm
instead of broadcom in the 'compatible' entry as found in
Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
but I guess that train has left and it is tricky to change it now.
In the brcmfmac patch you also use multiple of_device ids. Could we make
it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
or whatever...

Regards,
Arend

Re: Firmware for Bluetooth (and wifi)

[Tomasz Figa]

Hi Chen-Yu, Arend,

On 26.01.2014 22:39, Arend van Spriel wrote:
> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>> Hi,
>>
>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
>>> Hi,
>>>
>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>
>>> <snip>
>>>
>>>
>>>>> Quick update, I've just tested:
>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>
>>>>
>>>> About this, I would like to move WiFi power control to a regulator,
>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>
>>>
>>> Actually the sunxi-mci.c driver already has support for an optional
>>> regulator called vmmc.
>>>
>>> I like this idea, I've done a version of the dt patch using a regulator
>>> instead of rfkill here:
>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>
>>> This works as advertised and IMHO is the better solution.
>>
>> I have a version in another branch I haven't pushed. I had it using an
>> always-on regulator. I can adjust it to use vmmc.
>>
>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>> in mmc core.
>> We should re-use code if possible, wouldn't you agree?
>>
>>>>> About the oob interrupt stuff not working, AFAIK you should set a pinctrl
>>>>> function (not input, but a function like mmc is a function) on the pin in
>>>>> question
>>>>> for it to work as external interrupt, I believe you're not doing so in
>>>>> your
>>>>> dts.
>>>>
>>>>
>>>> The pinctrl driver seems to set the function when the interrupt is
>>>> enabled.
>>>> Unfortunately we don't have any documentation/examples on how to use them.
>>>> I will look into that later.
>>>
>>>
>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>> gpio-input,
>>> maybe that conflicts ?
>>
>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>> but then the whole thing hung. Looks like pinctrl irqchip was not
>> properly handling chained interrupts. I have done a simple fix, and I
>> hope to test it tomorrow. Then I'll do some more testing with different
>> configurations and hopefully write some documents.
>
> Hi Chen-Yu,
>
> I had a look at github tree from Hans with your DT support patch for
> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
> the bindings are still experimental, but I would prefer you to use brcm
> instead of broadcom in the 'compatible' entry as found in
> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
> but I guess that train has left and it is tricky to change it now.
> In the brcmfmac patch you also use multiple of_device ids. Could we make
> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
> or whatever...

brcmfmac and wifi-fullmac strings sound to generic for me. What happens 
if an incompatible brcmfmac chip shows up? I'd rather use something like 
"bcm43xx" to cover existing chip family, if all the bcm43xx chips are 
compatible, or something more specific otherwise.

By the way, you might find this thread interesting:

http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783

In addition to the general idea of handling power control, I have also 
posted a link to my patch adding DT support to brcmfmac driver.

Best regards,
Tomasz

Re: Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi Arend, Tomasz,

On Mon, Jan 27, 2014 at 8:20 AM, Tomasz Figa <tomasz.figa-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi Chen-Yu, Arend,
>
>
> On 26.01.2014 22:39, Arend van Spriel wrote:
>>
>> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>>>
>>> Hi,
>>>
>>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> wrote:
>>>>
>>>> Hi,
>>>>
>>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>>> Quick update, I've just tested:
>>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>>
>>>>>
>>>>>
>>>>> About this, I would like to move WiFi power control to a regulator,
>>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>>
>>>>
>>>>
>>>> Actually the sunxi-mci.c driver already has support for an optional
>>>> regulator called vmmc.
>>>>
>>>> I like this idea, I've done a version of the dt patch using a regulator
>>>> instead of rfkill here:
>>>>
>>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>>
>>>> This works as advertised and IMHO is the better solution.
>>>
>>>
>>> I have a version in another branch I haven't pushed. I had it using an
>>> always-on regulator. I can adjust it to use vmmc.
>>>
>>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>>> in mmc core.
>>> We should re-use code if possible, wouldn't you agree?
>>>
>>>>>> About the oob interrupt stuff not working, AFAIK you should set a
>>>>>> pinctrl
>>>>>> function (not input, but a function like mmc is a function) on the pin
>>>>>> in
>>>>>> question
>>>>>> for it to work as external interrupt, I believe you're not doing so in
>>>>>> your
>>>>>> dts.
>>>>>
>>>>>
>>>>>
>>>>> The pinctrl driver seems to set the function when the interrupt is
>>>>> enabled.
>>>>> Unfortunately we don't have any documentation/examples on how to use
>>>>> them.
>>>>> I will look into that later.
>>>>
>>>>
>>>>
>>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>>> gpio-input,
>>>> maybe that conflicts ?
>>>
>>>
>>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>>> but then the whole thing hung. Looks like pinctrl irqchip was not
>>> properly handling chained interrupts. I have done a simple fix, and I
>>> hope to test it tomorrow. Then I'll do some more testing with different
>>> configurations and hopefully write some documents.
>>
>>
>> Hi Chen-Yu,
>>
>> I had a look at github tree from Hans with your DT support patch for
>> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
>> the bindings are still experimental, but I would prefer you to use brcm
>> instead of broadcom in the 'compatible' entry as found in
>> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
>> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
>> but I guess that train has left and it is tricky to change it now.

I will fix this, though the only reason I did this is for the
OOB interrupts.

>> In the brcmfmac patch you also use multiple of_device ids. Could we make
>> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
>> or whatever...
>
>
> brcmfmac and wifi-fullmac strings sound to generic for me. What happens if
> an incompatible brcmfmac chip shows up? I'd rather use something like
> "bcm43xx" to cover existing chip family, if all the bcm43xx chips are
> compatible, or something more specific otherwise.
>
> By the way, you might find this thread interesting:
>
> http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783

Yeah I've been following this thread.

> In addition to the general idea of handling power control, I have also
> posted a link to my patch adding DT support to brcmfmac driver.

Actually since that thread started, I prefer handling the regulators and
possibly clocks in the mmc controller, as Olof posted. But that's just
my opinion.


Cheers,
ChenYu

Re: Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/27/2014 01:20 AM, Tomasz Figa wrote:
> Hi Chen-Yu, Arend,
> 
> On 26.01.2014 22:39, Arend van Spriel wrote:
>> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>>> Hi,
>>>
>>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>> wrote:
>>>> Hi,
>>>>
>>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>>
>>>> <snip>
>>>>
>>>>
>>>>>> Quick update, I've just tested:
>>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>>
>>>>>
>>>>> About this, I would like to move WiFi power control to a regulator,
>>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>>
>>>>
>>>> Actually the sunxi-mci.c driver already has support for an optional
>>>> regulator called vmmc.
>>>>
>>>> I like this idea, I've done a version of the dt patch using a regulator
>>>> instead of rfkill here:
>>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>>
>>>>
>>>> This works as advertised and IMHO is the better solution.
>>>
>>> I have a version in another branch I haven't pushed. I had it using an
>>> always-on regulator. I can adjust it to use vmmc.
>>>
>>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>>> in mmc core.
>>> We should re-use code if possible, wouldn't you agree?
>>>
>>>>>> About the oob interrupt stuff not working, AFAIK you should set a
>>>>>> pinctrl
>>>>>> function (not input, but a function like mmc is a function) on the
>>>>>> pin in
>>>>>> question
>>>>>> for it to work as external interrupt, I believe you're not doing
>>>>>> so in
>>>>>> your
>>>>>> dts.
>>>>>
>>>>>
>>>>> The pinctrl driver seems to set the function when the interrupt is
>>>>> enabled.
>>>>> Unfortunately we don't have any documentation/examples on how to
>>>>> use them.
>>>>> I will look into that later.
>>>>
>>>>
>>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>>> gpio-input,
>>>> maybe that conflicts ?
>>>
>>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>>> but then the whole thing hung. Looks like pinctrl irqchip was not
>>> properly handling chained interrupts. I have done a simple fix, and I
>>> hope to test it tomorrow. Then I'll do some more testing with different
>>> configurations and hopefully write some documents.
>>
>> Hi Chen-Yu,
>>
>> I had a look at github tree from Hans with your DT support patch for
>> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
>> the bindings are still experimental, but I would prefer you to use brcm
>> instead of broadcom in the 'compatible' entry as found in
>> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
>> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
>> but I guess that train has left and it is tricky to change it now.
>> In the brcmfmac patch you also use multiple of_device ids. Could we make
>> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
>> or whatever...
> 
> brcmfmac and wifi-fullmac strings sound to generic for me. What happens
> if an incompatible brcmfmac chip shows up? I'd rather use something like
> "bcm43xx" to cover existing chip family, if all the bcm43xx chips are
> compatible, or something more specific otherwise.

The brcmfmac driver that consumes these DT nodes will have a closer look
at the device obtaining the chipid during the probe and determine if it
can support it. So the compatible string indicates that the device needs
a so-called fullmac wireless driver opposed to a mac80211 aka. softmac
wireless driver.

> By the way, you might find this thread interesting:
> 
> http://thread.gmane.org/gmane.linux.kernel.mmc/24728/focus=24783
> 
> In addition to the general idea of handling power control, I have also
> posted a link to my patch adding DT support to brcmfmac driver.

You peaked my interest and I will catch up reading the thread.

Regards,
Arend

Re: Firmware for Bluetooth (and wifi)

[Tomasz Figa]

On 27.01.2014 10:21, Arend van Spriel wrote:
> On 01/27/2014 01:20 AM, Tomasz Figa wrote:
>> Hi Chen-Yu, Arend,
>>
>> On 26.01.2014 22:39, Arend van Spriel wrote:
>>> On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote:
>>>> Hi,
>>>>
>>>> On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede <hdegoede-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> On 01/24/2014 04:38 AM, Chen-Yu Tsai wrote:
>>>>>
>>>>> <snip>
>>>>>
>>>>>
>>>>>>> Quick update, I've just tested:
>>>>>>> https://github.com/wens/linux/commits/wip/sunxi-next-wifi
>>>>>>
>>>>>>
>>>>>> About this, I would like to move WiFi power control to a regulator,
>>>>>> and controlled by sunxi-mci via vmmc-supply (not supported ATM)
>>>>>
>>>>>
>>>>> Actually the sunxi-mci.c driver already has support for an optional
>>>>> regulator called vmmc.
>>>>>
>>>>> I like this idea, I've done a version of the dt patch using a regulator
>>>>> instead of rfkill here:
>>>>> https://github.com/jwrdegoede/linux-sunxi/commit/8d200113b573549cdcdc1b2d5a5a1cad15cfbe07
>>>>>
>>>>>
>>>>> This works as advertised and IMHO is the better solution.
>>>>
>>>> I have a version in another branch I haven't pushed. I had it using an
>>>> always-on regulator. I can adjust it to use vmmc.
>>>>
>>>> BTW, I'd like to do a patch for sunxi-mci to use the DT parsing code
>>>> in mmc core.
>>>> We should re-use code if possible, wouldn't you agree?
>>>>
>>>>>>> About the oob interrupt stuff not working, AFAIK you should set a
>>>>>>> pinctrl
>>>>>>> function (not input, but a function like mmc is a function) on the
>>>>>>> pin in
>>>>>>> question
>>>>>>> for it to work as external interrupt, I believe you're not doing
>>>>>>> so in
>>>>>>> your
>>>>>>> dts.
>>>>>>
>>>>>>
>>>>>> The pinctrl driver seems to set the function when the interrupt is
>>>>>> enabled.
>>>>>> Unfortunately we don't have any documentation/examples on how to
>>>>>> use them.
>>>>>> I will look into that later.
>>>>>
>>>>>
>>>>> Hmm, but you also have a pinctrl entry in the dts setting it up as
>>>>> gpio-input,
>>>>> maybe that conflicts ?
>>>>
>>>> I made a version with pinctrl entry setup as "irq", got an interrupt,
>>>> but then the whole thing hung. Looks like pinctrl irqchip was not
>>>> properly handling chained interrupts. I have done a simple fix, and I
>>>> hope to test it tomorrow. Then I'll do some more testing with different
>>>> configurations and hopefully write some documents.
>>>
>>> Hi Chen-Yu,
>>>
>>> I had a look at github tree from Hans with your DT support patch for
>>> brcmfmac. I applied it to my 3.14 tree and modified it a little. I guess
>>> the bindings are still experimental, but I would prefer you to use brcm
>>> instead of broadcom in the 'compatible' entry as found in
>>> Documentation/devicetree/bindings/vendor-prefixes.txt. There is an
>>> exception to this rule in the bindings (in net/broadcom-bcm87xx.txt),
>>> but I guess that train has left and it is tricky to change it now.
>>> In the brcmfmac patch you also use multiple of_device ids. Could we make
>>> it more generic, ie. compatible = "brcm,brcmfmac" or "brcm,wifi-fullmac"
>>> or whatever...
>>
>> brcmfmac and wifi-fullmac strings sound to generic for me. What happens
>> if an incompatible brcmfmac chip shows up? I'd rather use something like
>> "bcm43xx" to cover existing chip family, if all the bcm43xx chips are
>> compatible, or something more specific otherwise.
>
> The brcmfmac driver that consumes these DT nodes will have a closer look
> at the device obtaining the chipid during the probe and determine if it
> can support it. So the compatible string indicates that the device needs
> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac
> wireless driver.

The compatible string should guarantee that the chip ID register holds a 
valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to 
me. The string must specify the family of chips with this chip ID scheme 
in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a 
risk of, say, BCM43999 showing up, which would be a completely different 
chip. while having the model matching the pattern.

However this is something for you Broadcom guys to know better, so feel 
free to suggest anything better.

Best regards,
Tomasz

Re: Firmware for Bluetooth (and wifi)

[Arend van Spriel]

On 01/27/2014 11:12 AM, Tomasz Figa wrote:
>> The brcmfmac driver that consumes these DT nodes will have a closer look
>> at the device obtaining the chipid during the probe and determine if it
>> can support it. So the compatible string indicates that the device needs
>> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac
>> wireless driver.
> 
> The compatible string should guarantee that the chip ID register holds a
> valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to

I am not sure I understand this requirement. Is the DT node claimed
somehow after of_find_matching_node() and unavailable to other drivers.

> me. The string must specify the family of chips with this chip ID scheme
> in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a
> risk of, say, BCM43999 showing up, which would be a completely different
> chip. while having the model matching the pattern.

If a completely different chip, ie. BCM43999, shows up in a board the
device tree should not use "brcm,bcm43xx-fmac". That would be an error
in the dts file, right? All the devices listed in your bindings patch
are treated the same, ie. *compatible* on DT level and hence can have
the same compatible property.

In my opinion that is what the compatible property is about. It
identifies how a specific category of devices is accessed/configured. As
an example please see [1]. It shows one compatible string for a binding
that is used for different MPIC controllers.

Just to be clear, I like your suggestion to use "brcm,bcm43xx-fmac", but
felt you did not so added my explanation/point of view.

Regards,
Arend

[1] Documentation/devicetree/bindings/powerpc/fsl/mpic.txt

Re: Firmware for Bluetooth (and wifi)

[Hans de Goede]

Hi,

On 01/28/2014 11:11 AM, Arend van Spriel wrote:
> On 01/27/2014 11:12 AM, Tomasz Figa wrote:
>>> The brcmfmac driver that consumes these DT nodes will have a closer look
>>> at the device obtaining the chipid during the probe and determine if it
>>> can support it. So the compatible string indicates that the device needs
>>> a so-called fullmac wireless driver opposed to a mac80211 aka. softmac
>>> wireless driver.
>>
>> The compatible string should guarantee that the chip ID register holds a
>> valid value, so just "wifi-fullmac" or "brcmfmac" sounds too generic to
> 
> I am not sure I understand this requirement. Is the DT node claimed
> somehow after of_find_matching_node() and unavailable to other drivers.
> 
>> me. The string must specify the family of chips with this chip ID scheme
>> in a reasonably precise way. "brcm,bcm43xx-fmac" maybe? I still see a
>> risk of, say, BCM43999 showing up, which would be a completely different
>> chip. while having the model matching the pattern.
> 
> If a completely different chip, ie. BCM43999, shows up in a board the
> device tree should not use "brcm,bcm43xx-fmac". That would be an error
> in the dts file, right? All the devices listed in your bindings patch
> are treated the same, ie. *compatible* on DT level and hence can have
> the same compatible property.
> 
> In my opinion that is what the compatible property is about. It
> identifies how a specific category of devices is accessed/configured. As
> an example please see [1]. It shows one compatible string for a binding
> that is used for different MPIC controllers.
> 
> Just to be clear, I like your suggestion to use "brcm,bcm43xx-fmac", but
> felt you did not so added my explanation/point of view.

The usual way to solve this is to have the dts file have a list of
compatibility strings going from specific to more generic, so for ie the
wifi on the cubietruck the dts file would contain:

compatible = "brcm,bcm43362", "brcm,bcm43xx-fmac";

And then the brcmfmac driver will contain .compatible = "brcm,bcm43xx-fmac"

If we then ever need to have some specific quirks in the driver the driver
can use of_device_is_compatible(dev->of_node, "brcm,bcm43362") to check for
the 43362.

Their could even be a completely separate driver for the "brcm,bcm43362",
with brcmfmac still claiming "brcm,bcm43xx-fmac", as matching is done
from left to right, so if there is a specific driver and a more generic
one the specific driver will win (assuming both are built-in / loaded
at probe time).

TL;DR: dts file should have:
  compatible = "brcm,bcm43362", "brcm,bcm43xx-fmac";
brcmfmac should have:
  .compatible = "brcm,bcm43xx-fmac",
So that we can add device specific quirks later (if necessary).

Regards,

Hans

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Michal Suchanek]

Hello,

On 19 December 2013 11:12, Chen-Yu Tsai <wens@csie.org> wrote:
> Hi,
>
> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@csie.org> wrote:
>> Hi,
>>
>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@broadcom.com> wrote:
>>> On 12/18/2013 02:12 PM, Hans de Goede wrote:
>>>> Hi,
>>>>
>>>> On 12/18/2013 11:31 AM, Arend van Spriel wrote:
>>>>> On 12/05/2013 10:46 PM, Julian Calaby wrote:
>>>>>> Firstly, are there any plans to support the BCM43362 chipset with the
>>>>>> brcmfmac driver in the near future?
>>>>>
>>>>> Hi Julian,
>>>>>
>>>>> I am working on a patch to support this chip. It is looking promising.
>>>>> Just have to go after a firmware image to be sure.
>>>>
>>>> Cool. Do you have a cubietruck? With my latest wip tree:
>>>> https://github.com/jwrdegoede/linux-sunxi/commits/sunxi-next
>>>
>>> No cubietruck here. I googled the term last week because it came up and
>>> found embeddedcomputer.nl selling it.
>>>
>>>> We've mmc/sdio controller support on top of 3.13-rc4, it would be
>>>> nice if we could also get the wifi and bluetooth to work here.
>
> I got the chip to respond to probing. It is BCM43362 for sure.
>
>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat device
>   0xa962
>   root@cubietruck:/sys/bus/mmc/devices/mmc1:0001/mmc1:0001:1# cat vendor
>   0x02d0
>
> Vendor ID is Broadcom. Device ID is 43362.
> But I get two devices, mmc1:0001:1 and mmc1:0001:2. I don't know
> if this is normal or not.
>
> Bluetooth still isn't responding.
>

Well, bluetooth is supposed to be attached to an UART, not SDIO.
That's what the datasheets of the chip I found looked like.

Not sure how firmware is supposed to fit in in this case but this
would not be the first serial BT chip requiring firmware, would it?

Thanks

Michal

Re: [linux-sunxi] Firmware for Bluetooth (and wifi)

[Chen-Yu Tsai]

Hi,

On Fri, Jan 3, 2014 at 12:52 AM, Michal Suchanek <hramrach@gmail.com> wrote:
> Hello,
>
> On 19 December 2013 11:12, Chen-Yu Tsai <wens@csie.org> wrote:
[snip]
>> Bluetooth still isn't responding.
>>
>
> Well, bluetooth is supposed to be attached to an UART, not SDIO.
> That's what the datasheets of the chip I found looked like.

Correct. CubieTruck schematics indicate it's connected to UART2.

> Not sure how firmware is supposed to fit in in this case but this
> would not be the first serial BT chip requiring firmware, would it?

Broadcom has a utility called brcm_patchram_plus that loads the
firmware. However I can't get my chip to respond to its first
reset command.


ChenYu