We were not allowing the thermal state to be set when we were in D0i3
mode.  It was not very clearly specified how it should work, but now a
decision was made to allow the state to be set in D0i3 (which will
cause a brief wake up).  Remove the check in the set_cur_state
operation.
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The driver can read the current state during D0I3,
therefore there is no reason not to do it.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Use RX_HANDLER_ASYNC_UNLOCKED instead of unlock and re-lock
the mutex independently.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

iwl_mvm_tcool_get_cur_state is the function that returns the
cooling state index to the sysfs handler. This function returns
mvm->cooling_dev.cur_state but that variable was set to the
budget and not the cooling state index. Fix that.
Add a missing blank line while at it.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add debugfs entries to get the ctdp budget average
and to stop ctdp.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Thermal zone device registration can fail, and in this case
we don't want to remove WiFi functionality. This is why the
thermal zone registration function is void, and the flows
continue even if the thermal zone device registration failed.
Same applies for the cooling device.

This means that we at least need to remember that the thermal
zone device didn't register properly and take the minimal
precautions to avoid panic'ing when we access it.

This was missing.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Register cooling device in order to have the Thermal
Manager handle the device's power budget according to the sent
notifications.
The interface adds a new thermal cooling device to
/sys/class/thermal/ folder.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Register to thermal_zone interface and implement the
thermal ops.
The thermal handles the device throttling, and sets the
the temperature thresholds the Thermal Manager would be
notified of crossing.
The thermal interface adds a new thermal zone device sensor
under /sys/class/thermal/ folder.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Up to today the driver was notified of the temperature from the FW
and decided whether to enter CT-kill or not.
From now on, the FW will decide when to enter CT-kill and will notify
the driver.
Add support for this notification.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The driver should support also negative temperatures.
So there is a need to separate between the return value and
temperature in order to be able to distinguish between
a negative temperature and error value.
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This notification will be extended with extra data, so just
check that it has a minimum length, not the exact length;
we might later add handling for the extra fields added and
have more code to handle both versions.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

ilw@linux.intel.com is not available anymore.
linuxwifi@intel.com should be used instead.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Part of reorganising wireless drivers directory and Kconfig.
Signed-off-by: NKalle Valo <kvalo@codeaurora.org>

Since the 8000 series, the DTS measurement request command has been
changed. Use an ucode capability flag to determine which version is
supported and send the extended command when needed.
Signed-off-by: NArik Nemtsov <arikx.nemtsov@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Move the DTS measurement command and notification from short
command header to the new PHY command group for firmware
supporting the extended command headers.
Signed-off-by: NAviya Erenfeld <aviya.erenfeld@intel.com>
Signed-off-by: NLuca Coelho <luciano.coelho@intel.com>

Add support for extended command id in notification system.
Extended command id header contains group id in addition to command id.
Signed-off-by: NSara Sharon <sara.sharon@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

In the mvm driver, neither the old command nor the return value
are used, so remove them.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The thermal throttling parameters were constant and hardcoded, not allowing
changes for different NIC families.
Change this so that the values are part of the NIC family configuration and
are not constant (so they can be changed dynamically in the future).
Signed-off-by: NChaya Rachel Ivgi <chaya.rachel.ivgi@intel.com>
Reviewed-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Clear the thermal throttling values when entering CT-kill, since
everything will be reinitialized anyway when we exit CT-kill.

Additionally, clear the dynamic_smps value in the initialization
funciton, for consistency.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Currently, the firmware only sends temperature notificaitions inside
RX statistics notifications, which are tied to beacon filtering.  This
is a problem because beacon filtering is not used with vifs that don't
receive beacons (e.g. P2P GO and AP), so the driver doesn't receive
temperature notifications in those cases.  To solve that, the firmware
will be changed so that it sends DTS_MEASUREMENT_NOTIFICATIONs,
independently from the beacon filtering flows.

To support that, the driver needs to also handle unsolicited
DTS_MEASUREMENT_NOTIFICATIONs, that are not triggered by
DTS_TRIGGER_CMD_FLAGS_TEMP requests.

This change is backwards compatible and will simply not be used with
firmware versions that do not send the notifications.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Refactor the temperature handling code so that it is easier to reuse
it with other notification flows.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

We used to need to include some headers in order to read the registers
and do all the calculations by ourselves, but this is not done anymore
(i.e. we let the firmware do this for us), so we don't need to include
those headers anymore.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When read, this new debugfs entry requests the current temperature
from the firmware and outputs it.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Reading the temperature directly from the hardware, without the help
of the firmware, is a complex process and is not entirely the same for
different hardware.  Also, some NICs don't easily allow access to the
sensors when the firmware is not running, which would add even more
complexity to the code.

To reduce the code complexity and to avoid code duplication between
the firmware and the driver, boot the firmware briefly to read the
current temperature while in CT kill mode.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Our legal structure changed at some point (see wikipedia), but
we forgot to immediately switch over to the new copyright
notice.

For files that we have modified in the time since the change,
add the proper copyright notice now.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

If we're manually testing the CT kill functionality via debugfs, we
shouldn't schedule the work to recheck the temperature after the
ct_kill_duration period has passed.
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Since we can't read the actual temperature when the firmware is
running, just set the temperature to 0 when the test is disabled and
disable CT Kill if it was enabled.

Additionally, since we rely on iwl_mvm_tt_handler() to exit CT kill
when in test mode, call iwl_mvm_exit_ctkill() in that function if the
temperature is low again.  Also make the iwl_mvm_enter_ctkill() and
iwl_mvm_exit_ctkill() return if called when not necessary anymore
(e.g. when iwl_mvm_exit_ctkill() is called when we're not in CT-kill).
Signed-off-by: NLuciano Coelho <luciano.coelho@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Add iwl_mvm_ref_sync() calls (with new ref types) to
flows that might access the device directly.

These calls make sure the device is out of d0i3,
and the bus is available for direct access.

Since some of these functions are reentrant, convert
the refs_bitmap to a ref counter, so multiple refs
of the same type could be taken concurrently.
Signed-off-by: NEliad Peller <eliadx.peller@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

As part of thermal throttling, some data is being read from NVM.
The offset is in words, but was addressed as in octets. fixed.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

CMD_SYNC is really 0 which is confusing:

if (cmd.flags & CMD_SYNC) is always false.
Fix this by simply removing its definition.
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When NIC is exiting from thermal throttling state (i.e. after
heating and then cooling down), tx-backoff values are assigned
to be zero, instead of being restored to the minimal value. Fixed.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When NIC exit thermal throttling while having minimal tx-backoff
restriction, the warning message that indicate about that state
won't show up. Fixed.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The tx backoff settings used by the thermal throttling mechanism can
also be used for enforcing a limit on the power consumption of the module.

Handle the platform PCIe power limitation by translating the limit
(measured in mw) to its respective tx backoff value. The translation is
module specific.

The resulting tx backoff value is sent to the ucode, and also serves as the
minimal backoff value that can be set by the thermal throttling mechanism.
Signed-off-by: NIdo Yariv <idox.yariv@intel.com>
Reviewed-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

Happy new year!
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

The stop_hw trans callback is not well defined. It is missing in many
cleanup flows and the division of labor between stop_device/stop_hw
is cumbersome. Remove stop_hw and use stop_device to perform both.
Implement this for all current transports.

PCIE needs some extra configuration the op-mode is leaving to configure
RF kill. Expose this explicitly as a new op_mode_leave trans callback.
Take the call to stop_device outside iwl_run_mvm_init_ucode, this
makes more sense and WARN when we want to run the INIT firmware while
it has run already.
Signed-off-by: NArik Nemtsov <arik@wizery.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

This is just a helper function to go from the mac80211
station struct to our internal one, to later allow us
to avoid temporary 'mvmsta' variables.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>

When the NIC is expected to operate in high temperature,
it is advisable to put more aggresive thermal throttling
parameters, in order to prevent CT-kill.
Signed-off-by: Neytan lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The LQ command argument isn't needed, it's always taken from the
station struct that's already passed, remove the argument.
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes@sipsolutions.net>

Add prints visible to the user when entering and exiting
thrermal throttling, because so users can tell that the
NIC is getting too hot (and throughput will decrease.)
Signed-off-by: Neytan lifshitz <eytan.lifshitz@intel.com>
Reviewed-by: NEmmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>

The Thermal Throttling code could do that, fix it.
Signed-off-by: NEytan Lifshitz <eytan.lifshitz@intel.com>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>