From: Andy Lutomirski <luto@amacapital.net>
To: Kalle Valo <kvalo@qca.qualcomm.com>, Mark Rutland <mark.rutland@arm.com>
Cc: devicetree@vger.kernel.org, ath10k@lists.infradead.org
Subject: Re: ath10k: calibration data through Device Tree?
Date: Thu, 02 Oct 2014 12:05:27 -0700 [thread overview]
Message-ID: <542DA1F7.9090904@amacapital.net> (raw)
In-Reply-To: <87ppeamvr9.fsf@kamboji.qca.qualcomm.com>
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.
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.
--Andy
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2014-10-02 19:05 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 [this message]
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
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=542DA1F7.9090904@amacapital.net \
--to=luto@amacapital.net \
--cc=ath10k@lists.infradead.org \
--cc=devicetree@vger.kernel.org \
--cc=kvalo@qca.qualcomm.com \
--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