Re: Broadcom 43340

[Arend van Spriel <arend@broadcom.com>]

On 03/22/15 21:14, Jürgen Bausa wrote:
> Arend van Spriel<arend@...>  writes:
>
>>
>> On 03/21/15 21:38, Jürgen Bausa wrote:
>>> 1. the nvram file under /sys/firmware/efi/efivars/ has a wrong MAC address.
>>> I changed it to the correct one. However, I am not sure if this is really
>>> necassary.
>>
>> That MAC address is only used for device that do have mac address in the
>> device so you can ignore that one.
>
> You are right, found it out mayself in the meantime. There is no need to
> change the MAC address.
>
>>
>>> 2. Found the following on the web:
>>>
>>>> rmmod brcmfmac
>>>> rmmod brcmutil
>>>> echo on>   /sys/bus/platform/drivers/sdhci-acpi/INT33BB\:00/power/control
>>>> modprobe brcmfmac
>>>
>>> After this, I can connect to wlan!
>>
>> Ah, I was wondering what type of sdio host controller was used. When
>> sdio host controller uses runtime-pm it affect communication with wlan
>> device. I recently posted a patch for that [1].
>
> So, do I understand correctly, that with your patch the above workaround
> will no longer be needed? In which kernel will your patch be included? As
> wifi is working now, I would avoid installing the patch and instead wait for
> the next kernel.

Indeed. The patch basically does the same thing as the workaround. It is 
applied to wireless-drivers-next tree so it will be in 4.1 kernel. So it 
will take a while before that gets released by Linus. 4.1-rc1 will 
probably take approx. 6-7 wks.

>>
>>> Does this give you enough information to find out, what the problem is? Or
>>> do you still need DBG output from the driver? if so, just tell me and I will
>>> try to compile and install the kernel with DBG turnded on. Its not a big
>>> deal but I stopped working on it as I found this workaround.
>>>
>>> At the momment I am trying to put these commands to rc,local. With limited
>>> success until now, But this may be caused by the fact, that they are
>>> executed too early. Will add some sleep.
>>
>> Might be the driver is already loaded before root file system is loaded
>> (from initramfs).
>
> I now got it working. Just put 'sleeep 20' before the commands and now it
> works perfectly.

Holding the boot for 20s is steep, but I guess a working device trumps a 
fast boot ;-)

>>
>>> Another thing I found out is, that the system sometimes comes up without
>>> wlan0. It seems I have it only on every second boot. However, this could be
>>> just by incident and it is not exactly every second boot but about 50 % of
>>> all boots.
>>
>> Is that after reboot or really after powerup. Curious whether there is a
>> difference between the two regarding this issue.
>>
>
> It was after reboot and at cold boot.
>
> However, this problem seems to be gone. wlan0 is up on every boot. In the
> meantime i upgraded to rc4. Could this be the reason?

Nothing in brcmfmac is changed that would explain this. Maybe something 
was fixed in sdio host controller, but it is all speculation.

> Do you still need some dbg information from my machine? If so, just tell me
> and I will install a kernel with the needed options. Otherwise, I will stay
> with the current situation.

If you are happy and the issue seems resolved there is no need. Thanks.

>>> Ok, thanks. Will the driver also enable bluetooth? As I read, the
>>> bcm43341 also has Bluetooth capabilities.
>>
>> It has, but no clue what host interface is used. Anyway, it will have
>> a separate driver.
>
> Do you now, if there is some development going on for the bluetooth driver?
> Who could I conact?

I am not sure what host-interface is used to bt part. Is it usb or uart? 
I know there are plans to mainline the bt uart driver, but not sure when 
that will make its way into the kernel. If it is usb you should be able 
to use btusb driver, but you need firmware. They added support for 
handling firmware in btusb recently.

Regards,
Arend