QCA4019: calibration files and board files

[Christian Lamparter]

On Thursday, March 9, 2017 1:46:00 PM CET Sven Eckelmann wrote:
> On Donnerstag, 9. März 2017 11:51:13 CET Valo, Kalle wrote:
> [...]
> > I haven't followed the discussion very closely, so I might be way off,
> > but for laptop SMBIOS implementations Waldemar added a variant field to
> > board-2.bin so that we can have multiple images for the same subsystem
> > id. Could it help here also?
> > 
> > https://git.kernel.org/cgit/linux/kernel/git/kvalo/ath.git/commit/
> > ?h=ath-next&id=1657b8f84ed9fc1d2a100671f1d42d6286f20073
> 
> Thanks for the pointer.
I've added Waldemar.

From what I can tell, adding something like a variant to the bmi-id would
help. I looked at the patch note and it strikes me a bit odd that the
used variant was a non-descriptive "DE_1AB" string? Isn't this bit arbitrary?
What is encoded in these variant strings? Are these variants "unique"? 
Who will distribute these special board-2.bin that contain all the 
different variants?

Also the patch says that if the variant isn't found, it will fall back to
the default. In case of the Asus RT-AC58U, this will not really work.
From what I can tell, ASUS added a PA chip and 5 dBi Antennas. They had to
redo the calibration and ended up with different values for the PA, AGC, 
Edges, Slobes, the lot... However, they kept the the project/customer id.
So the board-2.bin found on codeaurora and in the ath10k-repository will
not work.

> 
> I also saw this morning but haven't invested a lot of time when I saw it. But 
> let's play around with some ideas around "variant". Maybe someone else has 
> some better ideas or comments.
> 
> The information about the variant has to come from somewhere. Currently, the 
> OTP binary is returning only the bmi-chip-id and bmi-board-id. There doesn't 
> seem to be any "project"/"customer" id returned by it (even when it exists in 
> the EEPROM). And even when there would be, the already existing devices don't 
> seem to have it and i don't know if QCA actually allocates them for customers. 
> I would therefore postpone the use of pre-cal data to generate the the variant 
> string for now (but I will ask the ODM to get some info from QCA).
> 
> Let us see how the SMBIOS does it. dmi_walk is used to go through the entries 
> and search for the entry. We don't have this here. So let's check what we have 
> with the QCA4019
> 
> This looks at least like a doable thing with the device tree. It must be a 
> string but this can easily be stored in the device tree itself. 
> 
> The RT-AC58U  could therefore have following entries:
> 
>     		wifi at a000000 {
>     			status = "okay";
>     			qcom,ath10k-calibration-variant = "RT-AC58U";
>     		};
>     
>     		wifi at a800000 {
>     			status = "okay";
>     			qcom,ath10k-calibration-variant = "RT-AC58U";
>     		};
> 
> Some code has to be added to ath10k_core_probe_fw. I can prepare this later 
> (when I find the time).
> 
> The board-2.bin would then require entries for bus=ahb,bmi-chip-id=0,bmi-
> board-id=16,variant=RT-AC58U and bus=ahb,bmi-chip-id=0,bmi-board-
> id=17,variant=RT-AC58U.
This brings up a issue: Who will distribute these board-2.bin?
I would prefer them being added to the codeaurora or the
ath10k-firmware repository. Will this be possible? 

Thanks,
Christian