ath10k: calibration data through Device Tree?

[Kalle Valo]

Hi Mark,

Mark Rutland <mark.rutland at arm.com> writes:

>> ath10k is a wireless driver for Qualcomm Atheros 802.11ac hardware and
>> located in drivers/net/wireless/ath/ath10k/. Currently it only supports
>> PCI devices.
>> 
>> Some of the devices store the calibration data to the host flash and the
>> bootloader reads the data from the flash. And now we need a method to
>> deliver the calibration data from bootloader to ath10k. 
>
> What does this calibration data consist of?

>From ath10k point of view it's just a binary blob which we push to the
firmware before we start it. ath10k does not parse it in any way.

> What happens if you don't have the calibration data? Is it a critical
> requirement for the use of the device, or does its absence simply result
> in degraded performance?

>From my point of view the device should not be used if it doesn't
contain the correct calibration data. I guess it could work somehow but
there's no guarantee about the perfomance.

> What do you do on non-DT systems? Where does the information come from
> in that case?

Currently ath10k only supports having the calibration data in the OTP
area inside the QCA98XX chip. But some manufacturers want to store it on
the host file, I assume because of the flexibility it provides. And
that's why we have the need for Device Tree support.

> I'm somewhat puzzled as to why a discoverable PCI device would require
> non-discoverable information to use.

ath9k has a similar model as well, but it doesn't support Device Tree
(at least not yet).

>> * The calibration data is now 2116 bytes, in the future it might be
>>   longer. The data is unique for each radio and is created at the
>>   factory.
>
> Why would this change in future? Who is in charge of providing this
> information, and deciding upon the format thereof?

That's up to the firmare and hardware teams working on the chipsets.
Basically ath10k just needs the data and the length of the data.

>> * ath10k must be able to reliably map the PCI device (=radio) to the
>>   correct calibration data. Maybe with using PCI bus and slot numbers?
>
> I guess we'd have to do something along those lines.
>
> I'd like to get a better understanding of the problem before we start
> figuring out how to pass an arbitrary blob of information around.

I hope my answers helped.

-- 
Kalle Valo