Do not hardcode beamformee 4 space-time streams support, because
DBDC can only support up to 2.
Fixes: 00b2e16e0063 ("mt76: mt7915: add TxBF capabilities")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
mt7915 does not have a per-band number of chains unlike the other chips,
it only has a total number of chains. Yet the current code would
consider the total number as a per-band number.
For example, it would report that a 2x2 + 2x2 DBDC card have 4 chains on
each band and set chainmask to 0b1111 for the first interface and
0b11110000 for the second.
Fixes: 99ad32a4ca3a ("mt76: mt7915: add support for MT7986")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
If the nss value is zero in the eeprom, set it to the max.
This eeprom fragment from a mt7915 DBDC shows the problem:
00000190: 24 24 08 00 28 00 00 15 00 00 00 00 00 00 00 00
Fixes: 51a87540232c ("wifi: mt76: mt7915: rework eeprom tx paths and streams init")
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
By default, mt7915e does not enable thermal management until the default
thermal zone does not reach a trip point. If the rest of the system
have better cooling than the wireless hardware, then it is possible that
the wireless chip can overheat while the rest of the system is fine.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
The firmware-controlled actual throttle state was previously available
by reading the cooling_device, but this confused the thermal subsystem.
Add a hwmon attribute to get it instead.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
mt7915e registers a cooling_device with wrong semantics:
1. cooling_device expect that higher states values should cool more, but
mt7915e did the opposite... with the exception of state == 0, which
should "disable thermal management", but does not seem to have any
effect since the previous state is kept.
The result is that when the thermal zone heats up a bit and bumps the
cooling_device state from 0 to 1 to cool a bit, the performance is
destroyed, and when going back from 1 to 0, the performance stays bad.
2. Reading the cooling_device state does not always return the last
written state, but can return the actual hardware throttle state,
which is different.
This is a problem because the mt7915 firmware actually implement the
equivalent of a thermal zone with trip points. Setting the cooling
device state actually changes the throttles at each trip point, so the
following could occur if the first issue is fixed:
- thermal subsystem set state to 100% power (state=0)
- mt7915e driver set trip throttles to [100%, 50%, 25%, 12%]
- hardware heats up and decides to switch to 50% power
- thermal subsystem see that power is 50% (state=50), decide to increase
it to 60% (state=40) because the rest of the system is cool.
- mt7915e driver set trip throttle to [60%, 30%, 15%, 7%]
- hardware thus switches to 30% power
[race to the bottom continues...]
This patch corrects the semantics of the cooling_device to the one that
the thermal subsystem expect it.
Signed-off-by: Nicolas Cavallari <[email protected]>
Signed-off-by: Felix Fietkau <[email protected]>
