ath10k: calibration data through Device Tree?

Arnd Bergmann arnd at arndb.de
Fri Oct 3 08:29:54 PDT 2014


On Thursday 02 October 2014 12:05:27 Andy Lutomirski wrote:
> On 10/02/2014 06:44 AM, Kalle Valo wrote:
> > Hi Mark,
> > 
> > Mark Rutland <mark.rutland-5wv7dgnIgG8 at public.gmane.org> 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.
> 
> To give an actual concrete example that might be what Kalle is talking
> about:
> 
> I have a TP-Link Archer C7, which has a mips cpu and an ath10k minipcie
> device.  For whatever reason (I honestly have no clue whatsoever why the
> hardware works this way), the calibration data is on a host flash
> partition, not on the minipcie device's ROM or flash or whatever it is.

Just to clarify: is this data specific to the design of the device and
identical for all parts in a manufacture run, or does each individual
board have to be calibrated separately?

> Needless to say, the mainline ath10k driver won't load on it.  (An old
> version used to load without calibration data.  It didn't work very well.)
> 
> Presuambly the idea is that, if things like this used DT (which mine
> doesn't, I presume), then ath10k could get the calibration data via DT.
>  And maybe some vendors of ARM-based wifi devices are planning on
> playing similar games, and they do use DT.

Yes, this makes sense. I would also very much love to see DT support for
arch/mips/ath79 in general, it seems like a nice platform that is used
in a lot of devices with good openwrt support, and using DT would make
it easier to support additional devices.

>From a system design point, it's still horrible that you have to use
DT for a device that is on a discoverable bus like PCI, but as you describe,
the reality is that products are shipping that use ath10k PCI devices
without this data in them.

	Arnd



More information about the ath10k mailing list