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@a000000 {
> status = "okay";
> qcom,ath10k-calibration-variant = "RT-AC58U";
> };
>
> wifi@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
_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k
