Driver support for QCA6174 chip using SDIO interface
annlo.tech at gmail.com
Fri May 12 10:30:41 PDT 2017
Thanks Erik for your reply. Your information is very useful to us.
On Fri, May 12, 2017 at 7:51 AM, Erik Stromdahl
<erik.stromdahl at gmail.com> wrote:
> On 2017-05-12 02:20, Ann Lo wrote:
>> Hi Erik,
>> We are hoping to use your new SDIO patches for QCA9377 on kernel
>> version 4.1.36. There appears to be version 7 patches according to the
>> following email:
>> Would you advise on the followings?
>> 1) What is the status of ath10k SDIO for QCA9377? The above email has
>> the comment "With this patch we have the low level HTC protocol
>> working and it's possible to boot the firmware, but it's still not
>> possible to connect or anything like." Do you have an estimate of the
>> time for full functionality, that wpa_supplicant and hostapd will run
>> successfully? How much further work is needed?
> Well, first of all, the patches on the ath10k master only contain the
> HIF layer (which is not that useful by itself). You will need a bunch
> of generic HL (High Latency) patches as well. These patches are common
> for both USB and SDIO and has not yet been integrated into the ath
> These patches are available on my ath repo on github:
> They should be treated as very experimental though!
> There are a few known issues with the QCA9377 SDIO chip.
> I have as of today not been able to associate with an AP (which
> kind of limits the usefulness of the device, at least when operating
> in STA mode :).
> QCA9377 USB (Linksys WUSB6100M) works much better, but is unfortunately
> not fully stable either since I am only capable of transmit/receive
> ~3Mbytes before it goes deaf (but at least I can associate and authenticate
> to an AP with WPA2 PSK security).
> So what remains to be done then?
> Well, it seems as if the sdio chipset won't work that well with the
> generic parts of ath10k. The setup of a device is HIF layer independent
> (mostly implemented in mac.c) and has been tested thoroughly with the
> PCIe devices. When looking at qcacld (another driver that is not part
> of the Linux kernel), the setup is very different (different internal
> parameters are configured and commands are executed in a different order).
> From my point of view I think the following things needs to be done:
> 1. Make mac.c work with high latency devices (SDIO and USB). I suspect
> that the setup of SDIO and USB is similar.
> 2. Add support for newer version of the WMI protocol. qcacld uses a
> different ABI version for the WMI messages.
> Since I am doing this work as a spare time activity only, I can't make
> any commitments or estimates of when everything is fully implemented.
>> 2) Our BSP uses kernel version 4.1.36. Can we apply your patches to
>> this version? Or, do we need to backport a newer version for QCA9377?
> I would be very surprised if the patches applies on a 4.1.36 kernel.
> ath10k is a very active project and much has happened since 4.1.36.
> Besides, you would need a few other patches as well that has already
> been integrated.
> Perhaps the best way forward is the ath10k backports project?
>> We are trying to prepare the software so that we can test when our
>> hardware is ready.
>> On Sun, Jan 29, 2017 at 1:16 PM, Erik Stromdahl
>> <erik.stromdahl at gmail.com> wrote:
>>> If you are interested in trying the latest version of the sdio code
>>> you can clone the below repo:
>>> I have just pushed some updates for QCA9377 SDIO (that might work with
>>> QCA6174 chipsets as well).
>>> I will do some more testing of this code during the weeks to come.
>>> If you could try it out and give me feedback it would be great!
>>> On 2017-01-27 16:36, Valo, Kalle wrote:
>>>> Akesh M Chacko <akesh.chacko at vvdntech.in> writes:
>>>>> We are using QCA6174 chip on our embedded platform using SDIO
>>>>> interface. could you please help us to get the SDIO support for
>>>>> QCA6174 driver.
>>>> Erik Stromdahl is working on adding SDIO support to ath10k:
>>>> But it's still WIP.
More information about the ath10k