[PATCH 1/2] dt: bindings: add new dt entry for ath10k calibration variant

Tue Mar 21 07:33:43 PDT 2017

On Dienstag, 21. März 2017 08:00:34 CET Rob Herring wrote:
[...]
> > It would then up with something like this as compatibility string:
> >
> >  * qcom,ipq4019-wifi-asus-rt-ac58u
> >  * qcom,ipq4019-wifi-fritzbox-4040
> >  * qcom,ipq4019-wifi-netgear-whatever
> >  * qcom,ipq4019-wifi-openmesh-i-have-no-idea
> >  * ...
> 
> Are these all the same board design or variations? In the latter case,
> you should have specific compatibles anyway. Now if the variants are
> the same hardware, but different configurations say for different
> regions or something, then I'd say a separate property is fine.
> 
> We already have a "firmware-name" property. Would that work for you?

Hm, maybe we should specify some names better:

"qcom,ipq4019-wifi" == compatibility string for WiFi hardware inside the SoC. 
It is the one which ath10k supports on the Atheros Host Bus (ahb) of the 
QCA4019.

The ath10k driver will use the information from these nodes to initialize the 
device. It will basically:

1. load a firmware(-5).bin from /lib/firmware/ath10k/QCA4019/hw1.0/
2. load the pre-cal (aka first part of calibration) data from
   /lib/firmware/ath10k/pre-cal-*
3. do some firmware magic to identify the reference design
4. load board data "files" (BDF) for this reference design from
    /lib/firmware/ath10k/QCA4019/hw1.0/board-2.bin
5. send the BDF data to the firmware to let it compute the final calibration
   data
6. start the actual wifi stuff

The IPQ4018/4019 SoC doesn't contain the actual RF parts. There are a couple 
of reference designs (SoC+RF parts) from QCA which got official numbers. These 
numbers identify the BDFs inside the board-2.bin. And the board-2.bin is not 
the firmware - it is a container for multiple BDFs.

To summarize:

 * pre-cal is some data stored in a special partition of the devices and will
   not be overwritten on updates
 * board-2.bin are multiple BDF files containing the second part of the
   calibration data
 * pre-cal + BDF (+ some OTP stuff) are getting combined to form the complete
   calibration data

Asus RT-AC58U, Fritzbox 4040 and ZyXEL NBG6617 are products based on the same 
reference design. But of course, some (all?) fiddled around with the RF parts 
and therefore require special BDFs. They still use the same SoC and require 
that the closed source ath10k firmware behaves like on the official reference 
designs. Only the BDFs have to be different.

So you could say that the wifi-chip hardware (part of the QCA4018/4019 SoC) is 
the same between these different products. But the hardware around the SoC is 
different and therefore requires a different "configuration"/calibration for 
the surrounding RF hardware. It is not a perfect match for your "separate 
property is fine" compromise. Maybe you still meant this - I let you decide.

This is not only a problem on QCA4019 but also for other devices supported by 
ath10k. Waldemar Rymarkiewicz introduced the concept of BDF variants for
this [1] and implemented the support for SMBIOS. The variant string (generated 
from the SMBIOS data) is then used by ath10k when it searches for the correct 
BDFs in the board-2.bin. Kalle Valo suggested to use the same mechanism for 
QCA401X based boards (which don't use SMBIOS).

The "qcom,ath10k-calibration-variant" is now the (more or less) equivalent of 
the SMBIOS entry - but for device tree users. Let us assume that the variant 
string would be "RT-AC58U" for the Asus RT-AC58U and the first wifi device 
(bmi-board-id=16) gets initialized [2]. Then the step 4 would get splitted in 
following steps:

4.1. Get the the qcom,ath10k-calibration-variant content
4.2. jump to 4.5. when there is no qcom,ath10k-calibration-variant
4.3. calculate BDF search name with variant string
     "bus=ahb,bmi-chip-id=0,bmi-board-id=16,variant=RT-AC58U"
4.4. load BDF and when found, jump to 5.
4.5. calculate BDF search name without variant string
     "bus=ahb,bmi-chip-id=0,bmi-board-id=16"
4.6. load the BDF

There would be no changes in ath10k when adding a new BDF calibration variant 
using qcom,ath10k-calibration-variant. Only the device tree node would have to 
be updated:

 * device tree (simplified):
    / {
      model = "ASUS RT-AC58U";

      soc {
        wifi at a000000 {
          compatible = "qcom,ipq4019-wifi";
          reg = <0xa000000 0x200000>;
          status = "okay";
          qcom,ath10k-calibration-variant = "RT-AC58U";
        };

        wifi at a800000 {
          compatible = "qcom,ipq4019-wifi";
          reg = <0xa800000 0x200000>;
          status = "okay";
          qcom,ath10k-calibration-variant = "RT-AC58U";
        };
      };
    };
 * ath10k + ath10k-firmware
   <no change>

This about how the calibration [insert swearword] works for
"qcom,ipq4019-wifi" and why the "qcom,ath10k-calibration-variant" was used in
my first implementation. But then you've suggested to "use a more specific
compatible string". This information was not enough for me to understand what
you've actually meant. I was therefore proposing some examples which show what
you maybe could have meant. These were following things:

> >  * qcom,ipq4019-wifi-asus-rt-ac58u
> >  * qcom,ipq4019-wifi-fritzbox-4040
> >  * qcom,ipq4019-wifi-netgear-whatever
> >  * qcom,ipq4019-wifi-openmesh-i-have-no-idea

They are basically "qcom,ipq4019-wifi" + a product specific string. The first 
part is therefore the string which identifies the wifi device(s) in the 
QCA4018/4019 SoC. The product specific string is simply the part (or a 
variation of it) which would been used before in
"qcom,ath10k-calibration-variant" - just to make it "use a more specific 
compatible string".

I have no idea if this is really what you meant. I just wanted to give you 
some examples and explanations why I don't feel that this a good idea. I 
thought that this would help you to point me in the right direction and 
explain better what you've meant.

Right now it looks to me like following must be done for your(?) proposal for 
each new board:

 * device tree (simplified):
    / {
      model = "ASUS RT-AC58U";

      soc {
        wifi at a000000 {
          compatible = "qcom,ipq4019-wifi-asus-rt-ac58u";
          reg = <0xa000000 0x200000>;
          status = "okay";
        };

        wifi at a800000 {
          compatible = "qcom,ipq4019-wifi-asus-rt-ac58u";
          reg = <0xa800000 0x200000>;
          status = "okay";
        };
      };
    };
 * ath10k + ath10k-firmware
   - add qcom,ipq4019-wifi-asus-rt-ac58u to
     Documentation/devicetree/bindings/net/wireless/qcom,ath10k.txt
   - add qcom,ipq4019-wifi-asus-rt-ac58u to ath10k_ahb_of_match in
     drivers/net/wireless/ath/ath10k/ahb.c
   - add a mapping from qcom,ipq4019-wifi-asus-rt-ac58u to the RT-AC58U
     variant string somewhere in ath10k

I hope this is enough to understand it a little bit better.

Kind regards,
	Sven

[1] https://git.kernel.org/pub/scm/linux/kernel/git/kvalo/ath.git/commit/?id=1657b8f84ed9fc1d2a100671f1d42d6286f20073
[2] the second wifi device for this reference design would be 17. But there
    are a lot more for the other reference designs from QCA
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.infradead.org/pipermail/ath10k/attachments/20170321/fd4bc00f/attachment.sig>