Re: ath10k: calibration data through Device Tree?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi Mark,

Mark Rutland <mark.rutland@xxxxxxx> 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
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Device Tree Compilter]     [Device Tree Spec]     [Linux Driver Backports]     [Video for Linux]     [Linux USB Devel]     [Linux PCI Devel]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Yosemite Backpacking]
  Powered by Linux