From: Kalle Valo <kvalo@kernel.org>
To: Dmitry Baryshkov <dmitry.baryshkov@linaro.org>
Cc: ath10k@lists.infradead.org,
"open list:DRM DRIVER FOR MSM ADRENO GPU"
<linux-arm-msm@vger.kernel.org>
Subject: Re: ath10k / WCN3990: firmware-5.bin and wlanmdsp.mbn being out of sync
Date: Tue, 05 Dec 2023 14:37:17 +0200 [thread overview]
Message-ID: <87r0k0q0zm.fsf@kernel.org> (raw)
In-Reply-To: <CAA8EJpoeozL_Vo0ivV6Gc3sPvANjz69e9jLrSgiegbv5LJUFXw@mail.gmail.com> (Dmitry Baryshkov's message of "Mon, 4 Dec 2023 18:49:00 +0200")
Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
> On Mon, 4 Dec 2023 at 18:14, Kalle Valo <kvalo@kernel.org> wrote:
>
>>
>> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
>>
>> > On Mon, 4 Dec 2023 at 14:56, Kalle Valo <kvalo@kernel.org> wrote:
>> >
>> >>
>> >> Hi Dmitry,
>> >>
>> >> Dmitry Baryshkov <dmitry.baryshkov@linaro.org> writes:
>> >>
>> >> > I wanted to ask your opinion regarding one of the issues we stumbled
>> >> > upon on the Qualcomm RB1 and RB2 platforms. These platforms use ath10k
>> >> > snoc (WCN3990) WiFi "card". We noticed the following messages being
>> >> > spawned on the console, which I traced it to the
>> >> > ATH10K_FW_FEATURE_SINGLE_CHAN_INFO_PER_CHANNEL feature:
>> >> >
>> >> > ath10k_snoc c800000.wifi: chan info: invalid frequency 0 (idx 41 out of bounds)
>> >> >
>> >> > As a reminder, on this platform the wlan firmware and firmware-N.bin
>> >> > files come separately.
>> >> > The wlanmdsp.mbn is downloaded by the onboard modem DSP via the
>> >> > tqftpserv request (which is served from the board-specific folder
>> >> > qcom/qcm2210). The firmware-N.bin file is loaded by the WiFi driver
>> >> > itself from the generic folder, ath10k/WCN3990/hw1.0. Current
>> >> > firmware-5.bin file was provided with the sdm845's wlanmdsp.mbn, which
>> >> > is older than qcm2210/qrb4210's wlanmdsp.mbn.
>> >> >
>> >> > I'm looking for suggestions on how to make ath10k driver load
>> >> > firmware-N.bin file which corresponds to the board-specific
>> >> > wlanmdsp.mbn.
>> >>
>> >> We have had similar discussions in the past but it didn't go very far.
>> >> It would be so nice if you could finally fix this :) At one point we
>> >> even had a discussion that we might need something similar for ath11k
>> >> but it didn't go anywhere.
>> >>
>> >> > In particular I'd like to hear your opinion on the following proposal:
>> >> >
>> >> > Add the optional property to the board DT, that specifies:
>> >> > firmware-name = "path/to/wlanmdsp.mbn". The property, if present,
>> >> > will be used as an override for the firmware directory. So, while the
>> >> > ath10k driver will not load wlanmdsp.mbn on its own, it will still
>> >> > look for the firmware-N files in the specified directory.
>> >>
>> >> Back in the day I was thinking something like below, please let me know
>> >> what you think.
>> >>
>> >> So the normal firmware path for WCN3990 is:
>> >>
>> >> ath10k/WCN3990/hw1.0/
>> >>
>> >> My idea was that if we could extend it for different "platforms" (not
>> >> sure what's the proper term for this) by having platform specific
>> >> directories:
>> >>
>> >> ath10k/WCN3990/hw1.0-platform/
>> >>
>> >> (Replace "platform" with a unique name for the platform, for example
>> >> "acme-kv7" for a product from Acme with model name kv7.)
>> >>
>> >> Then DT could inform ath10k about this "platform" string and ath10k
>> >> would then download boath firmware-N.bin and board-2.bin from the
>> >> platform specific directory.
>> >>
>> >> And even cleaner if we could have the *.mbn firmware files in the same
>> >> directory, even if ath10k doesn't access them directly.
>> >
>> > We can, and a symlink from qcom/SoC/.../dir to that subdir.
>> >
>> > So, for example, for Pixel-3, using your schema we will have:
>> >
>> > ath10k/WCN3990/hw1.0-blueline/wlanmdsp.mbn
>> > ath10k/WCN3990/hw1.0-blueline/firmware-5.bin
>> > ath10k/WCN3990/hw1.0-blueline/board-2.bin
>> >
>> > qcom/sdm845/Google/blueline/wlanmdsp.mbn ->
>> > ../../../../ath10k/WCN3990/hw1.0-blueline/wlanmdsp.mbn
>> >
>> > This sounds mostly fine to me. My only suggestions is to change it as following:
>> >
>> > ath10k/WCN3990/hw1.0/board-2.bin
>> >
>> > ath10k/WCN3990/hw1.0/blueline/wlanmdsp.mbn
>> > ath10k/WCN3990/hw1.0/blueline/firmware-5.bin
>> > ath10k/WCN3990/hw1.0/blueline/board-2.bin
>> >
>> > qcom/sdm845/Google/blueline/wlanmdsp.mbn ->
>> > ../../../../ath10k/WCN3990/hw1.0/blueline/wlanmdsp.mbn
>>
>> Is there a specific reason why you propose adding a new subdirectory?
>> Personally I find it confusing that hw1.0 directory contains the
>> firmware files and then there's a subdirectory which also contains
>> similar firmware files.
>
> My main idea was to allow fallback at least for board-2.bin. I don't
> think we should have 10 instances of the file (or load it from the
> platform-specific location).
A very good point, I didn't think of board files. I agree, we should
avoid having several board-2.bin files. But I don't see how a
subdirectory would solve that? What if we have symlinks for board-2.bin
file:
ath10k/WCN3990/hw1.0-blueline/board-2.bin -> ath10k/WCN3990/hw1.0/board-2.bin
That way we can have just one board-2.bin file to maintain. And I
suspect this would be easier to implement in ath10k driver.
In my previous mail I forgot to mention about backwards compatibility
which is important. So we need to be careful that older kernels continue
to work.
--
https://patchwork.kernel.org/project/linux-wireless/list/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
next prev parent reply other threads:[~2023-12-05 12:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-25 3:23 ath10k / WCN3990: firmware-5.bin and wlanmdsp.mbn being out of sync Dmitry Baryshkov
2023-11-25 3:23 ` Dmitry Baryshkov
2023-12-04 12:56 ` Kalle Valo
2023-12-04 13:27 ` Dmitry Baryshkov
2023-12-04 16:14 ` Kalle Valo
2023-12-04 16:49 ` Dmitry Baryshkov
2023-12-05 12:37 ` Kalle Valo [this message]
2023-12-05 12:40 ` Dmitry Baryshkov
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=87r0k0q0zm.fsf@kernel.org \
--to=kvalo@kernel.org \
--cc=ath10k@lists.infradead.org \
--cc=dmitry.baryshkov@linaro.org \
--cc=linux-arm-msm@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.