unable to force transmission rate on injection

[Oleksij Rempel]

Am 16.06.2013 21:10, schrieb George Nychis:
> These two options make the most sense.  I am thinking about what the
> best way to go about this is while I'm just reading the code to
> understand what it does. As the code stands now, the radiotap header
> is, or is not, passed to the firmware?
>
>
> I don't have any sort of jtag or serial hardware to debug this in any
> easy way.  Do you know of any unused or open registers that I could
> write some simple debugging info to and read it from the kernel
> driver?  I dug around some of the register definitions but I didn't
> see anything marked as unused, and I don't think that the datasheet is
> public.

Currently there is no usb debug interface. Can be implemented, if you 
have time for it ;) But it will have one disadvantage, if firmware will 
crash, you wont get last message.

What do you mean by serial hardware? You will need some cheep usb to 
uart adapter, some thing like this:
http://www.ebay.de/itm/USB-2-0-an-RS232-TTL-UART-Module-Konverter-6PIN-Serial-/251125751211?pt=DE_Computing_USB_Kabel_Hubs_Adapter&hash=item3a7842ddab

And here are description of pins you will need for work:
http://wikidevi.com/wiki/AR7010
http://wikidevi.com/wiki/AR9271
https://github.com/qca/open-ath9k-htc-firmware/blob/master/docs/uart


> On Sun, Jun 16, 2013 at 12:43 PM, Oleksij Rempel <linux at rempel-privat.de> wrote:
>> Am 16.06.2013 16:36, schrieb George Nychis:
>>
>>> I'm trying to think of the appropriate way to pass the desired rate.  If
>>> the radiotap header is not passed on, then this becomes more complicated!
>>
>>
>> Well, there are two ways to fix that: short way; and proper ;)
>>
>> - short one: add some way to pass radiotap flags, so build in rate
>> controller can make proper decision.
>> - nuke rate controller from firmware and make use of ath9k code as match as
>> possible.
>>
>> Here is why. Basically ath9k_htc is just embedded cpu with pcie interface
>> and attached ath9k adapter to it. This construction reduce usb traffic. All
>> beacons and retries handled by firmware on embedded cpu. This was advantage.
>> Disadvantage - we have lots of out of sync duplicated code. If we will just
>> remove everything from firmware, then we will get simple usp-to-pcie
>> converter and all functionality which is available in ath9k driver, but we
>> will lost performance. May be there is a way to make sort of
>> usp-to-pcie-proxy.
>>
>> --
>> Regards,
>> Oleksij


-- 
Regards,
Oleksij