Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On Mon, Jan 27, 2014 at 3:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com 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? I would agree, except that mmc_regulator_get_supply makes vmmc mandatory, it will log and return an error when it is not there, and it will not set ocr_avail. Almost all Allwinnner boards don't have a separate vmmc, so making vmmc mandatory just leads to devicetree containing unnecessary fixed regulators for this. I suppose we could still reuse all the property parsing bits in mmc_of_parse(). This one handles the GPIOs, bus width and host capabilities. 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. Great, that sounds like progress to me :) I think it was a fluke. Now I'm not getting any interrupts. :( Anyway, I am resuming work on musb. I'll get back to this once 3.14-rc1 is out, and sunxi-devel is rebased. I can probably use OTG ID pin to test external interrupts. Cheers, ChenYu 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. Thanks for working on this. Regards, Hans -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out. -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On 01/27/2014 09:14 AM, Chen-Yu Tsai wrote: On Mon, Jan 27, 2014 at 3:31 PM, Hans de Goede hdego...@redhat.com wrote: Hi, On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com 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? I would agree, except that mmc_regulator_get_supply makes vmmc mandatory, it will log and return an error when it is not there, and it will not set ocr_avail. Almost all Allwinnner boards don't have a separate vmmc, so making vmmc mandatory just leads to devicetree containing unnecessary fixed regulators for this. I suppose we could still reuse all the property parsing bits in mmc_of_parse(). This one handles the GPIOs, bus width and host capabilities. Ah, I did not know about that one, yes that seems like a good idea. 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. Great, that sounds like progress to me :) I think it was a fluke. Now I'm not getting any interrupts. :( Anyway, I am resuming work on musb. I'll get back to this once 3.14-rc1 is out, and sunxi-devel is rebased. I can probably use OTG ID pin to test external interrupts. If you do a patch for mmc to use mmc_of_parse you will end up using external interrupts for sdcard detection by default (which should work on most boards, but has never been tested AFAIK), which would be another way to check the external interrupt functionality. Regards, Hans -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 hdego...@redhat.com 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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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] : 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] : 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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com 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. Cheers, ChenYu Off topic but, is the USB PHY driver final? I believe there's an issue in the probe error checking code: https://github.com/wens/linux/commit/349b8903e8909455d6f91fbad046fddc2d9326a5 No, I need to do another revision and send that upstream, I hope to do so one of the coming days. Regards, Hans -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On 01/26/2014 05:58 PM, Chen-Yu Tsai wrote: Hi, On Mon, Jan 27, 2014 at 12:34 AM, Hans de Goede hdego...@redhat.com 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? I would agree, except that mmc_regulator_get_supply makes vmmc mandatory, it will log and return an error when it is not there, and it will not set ocr_avail. Almost all Allwinnner boards don't have a separate vmmc, so making vmmc mandatory just leads to devicetree containing unnecessary fixed regulators for this. 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. Great, that sounds like progress to me :) 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. Thanks for working on this. Regards, Hans -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On Wed, Jan 8, 2014 at 4:56 PM, Arend van Spriel ar...@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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 12/27/2013 01:36 PM, Chen-Yu Tsai wrote: Hi, On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel ar...@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 w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel ar...@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
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hello, On 19 December 2013 11:12, Chen-Yu Tsai w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel ar...@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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Thu, Jan 2, 2014 at 9:59 PM, Arend van Spriel ar...@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 @0x1800=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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Hi, On Fri, Jan 3, 2014 at 12:52 AM, Michal Suchanek hramr...@gmail.com wrote: Hello, On 19 December 2013 11:12, Chen-Yu Tsai w...@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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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 ? 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.comjavascript: 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 @0x1800=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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
On 2 January 2014 20:22, Rosimildo DaSilva rosimi...@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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
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.comjavascript: 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 @0x1800=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 -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
Re: [linux-sunxi] Firmware for Bluetooth (and wifi)
Sorry to not post inline, I'm on my phone but didn't want to forget to comment. Have you looked into differences in bluez between the working Android and not working Linux? On my a31 devices that was the Bluetooth fix for a similar chip set. Bluez had to support a different serial protocol if I remember right. It all took place in userspace though. On Dec 27, 2013 7:36 AM, Chen-Yu Tsai w...@csie.org wrote: Hi, On Fri, Dec 27, 2013 at 7:47 PM, Arend van Spriel ar...@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 w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai w...@csie.org wrote: Hi, On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel ar...@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
