From: Robert Marko <email@example.com>
To: Christian Lamparter <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com,
firstname.lastname@example.org, open list <email@example.com>
Subject: Re: [PATCH] ath10k: support bus and device specific API 1 BDF selection
Date: Thu, 14 Oct 2021 14:01:58 +0200 [thread overview]
Message-ID: <CAOX2RU7VaxdU3VykTZER-pdpu6pnk3tbVrBmkGU=jPQo6rL3Xg@mail.gmail.com> (raw)
On Thu, 14 Oct 2021 at 13:54, Christian Lamparter <firstname.lastname@example.org> wrote:
> On 10/10/2021 00:17, Robert Marko wrote:
> > Some ath10k IPQ40xx devices like the MikroTik hAP ac2 and ac3 require the
> > BDF-s to be extracted from the device storage instead of shipping packaged
> > API 2 BDF-s.
> > This is required as MikroTik has started shipping boards that require BDF-s
> > to be updated, as otherwise their WLAN performance really suffers.
> > This is however impossible as the devices that require this are release
> > under the same revision and its not possible to differentiate them from
> > devices using the older BDF-s.
> > In OpenWrt we are extracting the calibration data during runtime and we are
> > able to extract the BDF-s in the same manner, however we cannot package the
> > BDF-s to API 2 format on the fly and can only use API 1 to provide BDF-s on
> > the fly.
> > This is an issue as the ath10k driver explicitly looks only for the
> > board.bin file and not for something like board-bus-device.bin like it does
> > for pre-cal data.
> > Due to this we have no way of providing correct BDF-s on the fly, so lets
> > extend the ath10k driver to first look for BDF-s in the
> > board-bus-device.bin format, for example: board-ahb-a800000.wifi.bin
> > If that fails, look for the default board file name as defined previously.
> > Signed-off-by: Robert Marko <email@example.com>
> > ---
> As mentioned in Robert's OpenWrt Pull request:
> It looks like the data comes from an mtd-partition parser.
> So the board data takes an extra detour through userspace
> for this.
> Maybe it would be great, if that BDF (and likewise pre-cal)
> files could be fetched via an nvmem-consumer there?
> (Kalle: like the ath9k-nvmem patches)
Christian, in this case, NVMEM wont work as this is not just read from
an MTD device, it first needs to be parsed from the MikroTik TLV, and
then decompressed as they use LZO with RLE to compress the caldata
> This would help with many other devices as well, since currently
> in OpenWrt all pre-cal data has to be extracted by userspace
> helpers, while it could be easily accessible through nvmem.
Yeah, for non-MikroTik stuff pre-cal data via NVMEM would be great.
> What do you think?
next prev parent reply other threads:[~2021-10-14 12:02 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-10-09 22:17 [PATCH] ath10k: support bus and device specific API 1 BDF selection Robert Marko
2021-10-14 11:54 ` Christian Lamparter
2021-10-14 12:01 ` Robert Marko [this message]
2021-10-14 13:23 ` Christian Lamparter
2021-12-07 18:06 ` Kalle Valo
2021-12-07 18:09 ` Kalle Valo
2021-12-08 12:21 ` Robert Marko
2021-12-08 14:07 ` Christian Lamparter
2021-12-17 12:06 ` Robert Marko
2021-12-17 12:25 ` Thibaut
2022-02-02 18:49 ` Robert Marko
2022-02-16 13:38 ` Robert Marko
2022-02-16 21:19 ` Christian Lamparter
2022-02-16 21:55 ` Thibaut
2022-05-03 15:58 ` Robert Marko
2022-05-04 7:48 ` Kalle Valo
2022-05-06 6:19 ` Kalle Valo
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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;
as well as URLs for NNTP newsgroup(s).