Re: [PATCH 00/13] Switch realtek target to upstream platform
I have not experienced a single lock-up when booting with this patch, but I also didn't stress-test the machine or even used the switch part. Do you guys have more details on why it locks up, or how exactly these lock-ups can be resolved? so far we found out it was related to the ethernet driver. but this is all part of the work we spended into it the last months and recently again since i'm back on this projects if you do performance tests in addition the mainline still uses 4kc as cpu architecture, which is simply wrong for anything else but 838x Wrong or suboptimal? I don't currently experience any obvious issues, using the same toolchain for 8380, 8390 and 9300. below suboptimal. i mean it decreases performance in a significant amount and fixing this issue is more than just easy Best, Sander ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [PATCH 00/13] Switch realtek target to upstream platform
I've provided a patch below that enables VPE support for RTL839x. Since RTL930x uses the same CPU architecture, I expect it to also bring up both threads there. Like you note RTL930x requires a specific clocksource driver, but it should be possible to run your current code for that on top of this (ammended) series. I will respin the series with some small changes, and add that VSMP-support patch. Please let us know if you can get your reworked IRQ driver and timer code working on top of the v2. That way, you wouldn't have to take a step back in your development, and we could continue providing support through upstream. just enabling vsmp in that way is not enough. it looks simple and this is how we started too but you will quickly find out that it will cause lockups and hangs. if you do performance tests in addition the mainline still uses 4kc as cpu architecture, which is simply wrong for anything else but 838x ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Am 25.05.2020 um 11:22 schrieb Sven Eckelmann:
On Wednesday, 20 May 2020 09:39:45 CEST Sebastian Gottschall wrote:
[...]
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch
was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did
[...]
This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
Just noticed that there was a copy and paste error in my message. The 5GHz was
an QCA9888 [1,2] and not an QCA4019. Otherwise the _pci error wouldn't have made
any sense.
And I can only say at the moment (remember that this was observer 14 months
ago), that it could be reproduced easily on IPQ40xx with an QCA9888 and the
given config running OpenWrt reboot-9440-g0f89c17b57. The diffconfig (seed) of
the installation was:
CONFIG_TARGET_ipq40xx=y
CONFIG_TARGET_ipq40xx_generic=y
CONFIG_TARGET_ipq40xx_generic_DEVICE_openmesh_a62=y
CONFIG_ATH10K_LEDS=y
CONFIG_PACKAGE_ath10k-firmware-qca4019=y
# CONFIG_PACKAGE_ath10k-firmware-qca4019-ct is not set
CONFIG_PACKAGE_ath10k-firmware-qca9888=y
# CONFIG_PACKAGE_ath10k-firmware-qca9888-ct is not set
CONFIG_PACKAGE_kmod-ath10k=y
# CONFIG_PACKAGE_kmod-ath10k-ct is not set
# CONFIG_PACKAGE_kmod-hwmon-core is not set
And it still can with this OpenWrt version. But it doesn't seem to happen with
the most recent OpenWrt reboot-13353-gb1604b744b. But there are nearly 4000
commits inbetween. So no idea what changed (just a timing thing or an actual
fix - no idea).
Btw. the wireless config was given in the original mail [2,3]
Kind regards,
Sven
maybe openwrt installs a default trigger which doesnt make sense if
nothing is connected to the cards gpio.
we can also modify the patch to exclude the 9888 from led support. you
just need to remove the led_pin defintion from the hw definition.
this patch is mainly for wireless routers like the netgear r7800, r9000
and some tplink archer models. it also works on mikrotik qca988x cards.
but even if the led_pin is set, it should not trigger any action until a
led trigger is set with sysfs. such configurations should be
architecture specific in any way
Sebastian
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Am 22.05.2020 um 12:29 schrieb Kalle Valo: (please don't top post) Sebastian Gottschall writes: this code is not in use in its original form for ipq4019. i have seen that his patch is also dropped from ath.git but is still in use by openwrt. could somone clarify the state here and why it was dropped? I dropped the patch because of the bug report from openwrt. can you show me the bug report? and openwrt is still using it as out of tree patch which is confusing here. personally i'm using the patch on qca988x, qca9884 and also ipq40xx devices (40xx doesnt make any use of it of course) any chipset which doesnt make use of the gpio_pin definition is unable to make use of it. if there is no trigger set, its also not used (hopefully) but in any way i'm willig to fix any issue of there is a reproduceable issue. Sebastian ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Am 20.05.2020 um 21:05 schrieb Vincent Wiemann:
Hi Sebastian,
On 20.05.20 15:00, Sebastian Gottschall wrote:
Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:
Hi Sebastian,
I don't know why it was dropped, but I can say that the LED control
code was kind of
annoying me. Even when the LED was turned of, it "flickered" when it
was set disabled.
Unfortunately I didn't have time to look into it, yet.
the led code will just be used if you set a trigger. otherwise it
doesnt touch the gpios.
the code itself was written to make use of the led's builtin to
several routers. if you dont set a led trigger, nothing will happen
Thank you for your quick response... I'll try to reproduce the issue
without your patch.
Maybe it's unrelated and a firmware-specific issue (official QCA9887).
One thing I've seen with your patch is that if I set the ath10k GPIO
"steady on" it sometimes
(quite randomly) turns it off for a fraction of a second. It happens
about 3 times a minute.
It's not a big deal. But maybe it's related to the flickering
I've observed and possibly also a firmware issue...
my code only sets the gpio state based on the led trigger code. so
basicly linux is handling it, my code just provides the code to access
the gpios. but i know that the firmware will reset the gpio state on
certain events like channel reset/channel change.
but as i said. if you dont set a trigger, my code will not control the
gpio of the chipset in any way and keeps it untouched.
so whatever you see, can only be caused by the firmware itself. what i
can say is that on qca988x chipsets i have never seen
such a behaviour. the connected led on pin 1 is always off without a
trigger and with a trigger its doing what it should do. and the 988x is
basicly
identical to the qca9887, just the amount of antennas is different
Best,
Vincent
Best,
Vincent
On 20.05.20 09:39, Sebastian Gottschall wrote:
this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is
still in use by openwrt.
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the
patch was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i
did take care of
Sebastian
Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
From: Sebastian Gottschall
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0,
9984 based
chipsets with on chipset connected led's using WMI Firmware API.
The LED
device will get available named as "ath10k-phyX" at sysfs and can
be controlled
with various triggers. adds also debugfs interface for gpio
control.
Signed-off-by: Sebastian Gottschall
Reviewed-by: Steve deRosier
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo
This patch was imported to OpenWrt in commit 61d57a2f88b9
("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and
QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
[ 221.620803] ath10k_pci :01:00.0: wmi command 36967
timeout, restarting hardware
[ 221.744056] ieee80211 phy0: Hardware restart was requested
[ 225.130829] ath10k_pci :01:00.0: failed to receive
control response completion, polling..
[ 226.170824] ath10k_pci :01:00.0: Service connect
timeout
[ 226.170871] ath10k_pci :01:00.0: failed to connect
htt (-110)
[ 226.252248] ath10k_pci :01:00.0: Could not init
core: -110
This was tested on an A62 with following wireless config:
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path
'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/soc/a00.wifi'
option htmode 'HT20'
option disabled '0'
option country US
config wifi-device 'radio2'
option type 'mac80211'
option channel '149'
option hwmode '11a'
option path 'platform/soc/a80.wifi'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none'
config wifi-iface
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
Am 20.05.2020 um 12:40 schrieb Vincent Wiemann:
Hi Sebastian,
I don't know why it was dropped, but I can say that the LED control code was
kind of
annoying me. Even when the LED was turned of, it "flickered" when it was set
disabled.
Unfortunately I didn't have time to look into it, yet.
the led code will just be used if you set a trigger. otherwise it doesnt
touch the gpios.
the code itself was written to make use of the led's builtin to several
routers. if you dont set a led trigger, nothing will happen
Best,
Vincent
On 20.05.20 09:39, Sebastian Gottschall wrote:
this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is still in use by
openwrt.
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch was
later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did take care
of
Sebastian
Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
From: Sebastian Gottschall
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's using WMI Firmware API. The LED
device will get available named as "ath10k-phyX" at sysfs and can be controlled
with various triggers. adds also debugfs interface for gpio control.
Signed-off-by: Sebastian Gottschall
Reviewed-by: Steve deRosier
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo
This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
[ 221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout,
restarting hardware
[ 221.744056] ieee80211 phy0: Hardware restart was requested
[ 225.130829] ath10k_pci :01:00.0: failed to receive control
response completion, polling..
[ 226.170824] ath10k_pci :01:00.0: Service connect timeout
[ 226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
[ 226.252248] ath10k_pci :01:00.0: Could not init core: -110
This was tested on an A62 with following wireless config:
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path
'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/soc/a00.wifi'
option htmode 'HT20'
option disabled '0'
option country US
config wifi-device 'radio2'
option type 'mac80211'
option channel '149'
option hwmode '11a'
option path 'platform/soc/a80.wifi'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none'
config wifi-iface 'mesh1'
option device 'radio1'
option ifname 'mesh1'
option network 'nwi_mesh1'
option mode 'mesh'
option mesh_id 'TestMesh'
option encryption 'none'
config wifi-iface 'mesh2'
option device 'radio2'
option ifname 'mesh2'
option network 'nwi_mesh2'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none
Kind regards,
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: [OpenWrt-Devel] [PATCH v13] ath10k: add LED and GPIO controlling support for various chipsets
this code is not in use in its original form for ipq4019.
i have seen that his patch is also dropped from ath.git but is still in
use by openwrt.
could somone clarify the state here and why it was dropped?
the original patch i wrote does exclude the soc chipsets, but the patch
was later reorganized and some part have been rewritten
so i'm not sure if it covers the scenario mentioned here, which i did
take care of
Sebastian
Am 26.02.2019 um 10:16 schrieb Sven Eckelmann:
On Friday, 6 April 2018 17:17:55 CET Kalle Valo wrote:
From: Sebastian Gottschall
Adds LED and GPIO Control support for 988x, 9887, 9888, 99x0, 9984 based
chipsets with on chipset connected led's using WMI Firmware API. The LED
device will get available named as "ath10k-phyX" at sysfs and can be controlled
with various triggers. adds also debugfs interface for gpio control.
Signed-off-by: Sebastian Gottschall
Reviewed-by: Steve deRosier
[kvalo: major reorg and cleanup]
Signed-off-by: Kalle Valo
This patch was imported to OpenWrt in commit 61d57a2f88b9 ("mac80211: ath10k
add leds support") and broke the 11s support for IPQ4019 and QCA4019 (5GHz)
firmware versions 10.4-3.5.3-00053, 10.4-3.5.3-00057, 10.4-3.6-00140:
[ 221.620803] ath10k_pci :01:00.0: wmi command 36967 timeout,
restarting hardware
[ 221.744056] ieee80211 phy0: Hardware restart was requested
[ 225.130829] ath10k_pci :01:00.0: failed to receive control response
completion, polling..
[ 226.170824] ath10k_pci :01:00.0: Service connect timeout
[ 226.170871] ath10k_pci :01:00.0: failed to connect htt (-110)
[ 226.252248] ath10k_pci :01:00.0: Could not init core: -110
This was tested on an A62 with following wireless config:
config wifi-device 'radio0'
option type 'mac80211'
option channel '36'
option hwmode '11a'
option path 'soc/4000.pci/pci:00/:00:00.0/:01:00.0'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-device 'radio1'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/soc/a00.wifi'
option htmode 'HT20'
option disabled '0'
option country US
config wifi-device 'radio2'
option type 'mac80211'
option channel '149'
option hwmode '11a'
option path 'platform/soc/a80.wifi'
option htmode 'VHT80'
option disabled '0'
option country US
config wifi-iface 'mesh0'
option device 'radio0'
option ifname 'mesh0'
option network 'nwi_mesh0'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none'
config wifi-iface 'mesh1'
option device 'radio1'
option ifname 'mesh1'
option network 'nwi_mesh1'
option mode 'mesh'
option mesh_id 'TestMesh'
option encryption 'none'
config wifi-iface 'mesh2'
option device 'radio2'
option ifname 'mesh2'
option network 'nwi_mesh2'
option mode 'mesh'
option mesh_id 'TestMesh'
option mesh_fwding '1'
option encryption 'none
Kind regards,
Sven
___
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel
