On 12/15/2019 05:09 AM, Christian Lamparter wrote:
On Sunday, 15 December 2019 13:01:14 CET Paul Fertser wrote:
Thank you for the answer Christian,
On Sun, Dec 15, 2019 at 12:00:48PM +0100, Christian Lamparter wrote:
I think for this to have any chance of moving forward you'll need to
pressure your ODMs and if that doesn't work: Go with a different WIFI
chip vendor that supports low memory devices, or add more RAM.
From what I can tell, Qualcomm nowadays gets what they want "for free"
and for the past four-five years, they certainly didn't feel pressured
to add "low memory" support to ath10k.
FWIW, OpenWrt's ath10k vendor is CT now, not QCA, so it's not much
relevant what do ODMs and (whatever is left from) QCA say, I guess.
Well, not sure what you are trying to say here. But I think Ben is free
to do what he wants as well. For example see the:
"ath10k: add LED and GPIO controlling support for various chipsets"
patch that OpenWrt has been carrying because neither upstream (linux-wireless)
nor CT wants to integrate it.
<https://github.com/openwrt/openwrt/blob/master/package/kernel/ath10k-ct/patches/201-ath10k-4.16_add-LED-and-GPIO-controlling-support-for-various-chipsets.patch>
The situation with the "low memory" support wasn't much better. Because
from what I remember, there was a discussion about this very topic between
Ben an Hauke in the past (and you can see how it played out, since you wouldn't
have posted this series if it was integrated back then).
But it seems that Ben had a change of heart in this regard. I don't know the
details or why, But it makes sense because it would enable his company to save
some money for the systems his company sells:
<https://www.candelatech.com/lf_systems.php> so there is some value
in supporting these devices, especially if someone else does all the work
for it.
My goal is to have stable and fully featured ath10k that works well for higher
powered
systems by default (our test rigs are typically powerful x86 with gigs of RAM
running
Fedora or similar).
OpenWRT is all about adding patches on top of upstream projects for specific
platforms, so that
would easily work with ath10k-ct too.
And, if someone wants to write a patch that either modifies ath10k-ct for
OpenWRT
to work better on certain systems, then by all means, go ahead. This should be
just
as easy as doing the same thing for upstream ath10k.
If someone writes a patch that conditionally compiles for OpenWRT and/or allows
OpenWRT to configure smaller memory usage, then I will apply that to my
ath10k-ct
driver (with caveat that defaults for non openwrt systems needs to remain as
is).
Thanks,
Ben
--
Ben Greear <gree...@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
