ATH10K Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Andy Lutomirski <luto@amacapital.net>
Cc: Mark Rutland <mark.rutland@arm.com>,
	devicetree@vger.kernel.org, Kalle Valo <kvalo@qca.qualcomm.com>,
	ath10k@lists.infradead.org
Subject: Re: ath10k: calibration data through Device Tree?
Date: Fri, 03 Oct 2014 17:29:54 +0200	[thread overview]
Message-ID: <2386503.dNPayhXJTQ@wuerfel> (raw)
In-Reply-To: <542DA1F7.9090904@amacapital.net>

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@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

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

  parent reply	other threads:[~2014-10-03 15:30 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 13:14 ath10k: calibration data through Device Tree? Kalle Valo
2014-10-02 13:27 ` Arnd Bergmann
2014-10-02 13:47   ` Kalle Valo
2014-10-02 14:19     ` Arnd Bergmann
2014-10-02 14:55       ` Kalle Valo
2014-10-02 15:58         ` Arnd Bergmann
2014-10-02 13:29 ` Mark Rutland
2014-10-02 13:44   ` Kalle Valo
2014-10-02 15:07     ` Mark Rutland
2014-10-02 19:05     ` Andy Lutomirski
2014-10-02 19:28       ` Adrian Chadd
2014-10-02 19:35         ` Andy Lutomirski
2014-10-07 16:44           ` Kalle Valo
2014-10-17 12:25             ` Kumar Gala
2014-10-22 12:02               ` Kalle Valo
2014-10-03 15:29       ` Arnd Bergmann [this message]
2014-10-03 16:24         ` Andy Lutomirski
2014-10-03 16:25         ` Mark Rutland
2014-10-03 16:42           ` Arnd Bergmann
2014-10-03 16:54             ` Andy Lutomirski
2014-10-03 17:21               ` Adrian Chadd
  -- strict thread matches above, loose matches on Subject: below --
2014-10-02 13:05 Kalle Valo
2014-10-02 13:09 ` Kalle Valo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=2386503.dNPayhXJTQ@wuerfel \
    --to=arnd@arndb.de \
    --cc=ath10k@lists.infradead.org \
    --cc=devicetree@vger.kernel.org \
    --cc=kvalo@qca.qualcomm.com \
    --cc=luto@amacapital.net \
    --cc=mark.rutland@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox