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@xxxxxxxxxxxx> 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@xxxxxxxx> wrote: >>>> Hi, >>>> >>>> On Thu, Dec 19, 2013 at 12:39 AM, Chen-Yu Tsai <wens@xxxxxxxx> wrote: >>>>> Hi, >>>>> >>>>> On Thu, Dec 19, 2013 at 12:16 AM, Arend van Spriel <arend@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxx. >> 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@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
