- 20 Feb, 2013 40 commits
-
-
Marcin Slusarz authored
Found by smatch. Signed-off-by:
Marcin Slusarz <marcin.slusarz@gmail.com> Signed-off-by:
Ben Skeggs <bskeggs@redhat.com>
-
Marcin Slusarz authored
Avoids potential null pointer dereference. Signed-off-by:
-
Marcin Slusarz authored
Avoids potential null pointer dereference. Signed-off-by:
-
Cong Ding authored
the variable chan is dereferenced in line 190, so it is no reason to check null again in line 198. Signed-off-by:
Cong Ding <dinggnu@gmail.com> Signed-off-by:
-
Marcin Slusarz authored
It's safe to call kfree(NULL). Found by smatch. Signed-off-by:
-
Marcin Slusarz authored
fan->get returns int, but we write it to unsigned variable, and then check whether it's >= 0 (it always is) Found by smatch: drivers/gpu/drm/nouveau/core/subdev/therm/fan.c:61 nouveau_fan_update() warn: always true condition '(duty >= 0) => (0-u32max >= 0)' Signed-off-by:
-
Marcin Slusarz authored
Signed-off-by:
-
Marcin Slusarz authored
COPY_ZM_REG: destination and source addresses were swapped RAM_RESTRICT_ZM_REG_GROUP: missing 0x prefix for register address Signed-off-by:
-
Marcin Slusarz authored
...and fix all warnings Signed-off-by:
-
Marcin Slusarz authored
We already rely on them having the same fields and layout. Signed-off-by:
-
Martin Peres authored
This fixes a bug where, when temperature is outside of the linear range, fan pwm would be outside of the allowed range ([0, 100]) and could get negative in some cases. It seems like a regression that happened when we re-worked the fan management logic before merging. Tested-by:
Ozan Çağlayan <ozancag@gmail.com> Signed-off-by:
Martin Peres <martin.peres@labri.fr> Signed-off-by:
-
Marcin Slusarz authored
Signed-off-by:
-
Marcin Slusarz authored
- record channel owner process name - add some helpers for accessing this information - let nouveau_enum hold additional value (will be needed in the next patch) Signed-off-by:
-
Marcin Slusarz authored
Signed-off-by:
-
Marcin Slusarz authored
Signed-off-by:
-
Martin Peres authored
This should avoid the situation where a user gets its kernel logs flooded when temperature oscillates around a threshold with 0°C hysteresis. This patch is just meant to fix broken vbios (as reported on a nv4e on sysfs hwmon interface. Signed-off-by:
-
Emil Velikov authored
Commit 767baf82 drm/nouveau: remove some more unnecessary legacy bios code has introduced a regression my misplacing the code that sets the major/chip versions, which are used whist parsing the bmp/bit structure in vbios Signed-off-by:
Emil Velikov <emil.l.velikov@gmail.com> Signed-off-by:
-
Ben Skeggs authored
My GTX660 has the GPIO_FAN function, but it's configured in input-mode; presumably to monitor the frequency set by an I2C fan controller? Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
From browsing my /sys, a few other things seem to do this, and it looks cleaner this way too :) Signed-off-by: -
Ben Skeggs authored
Fan speed info now shown by sensors. Signed-off-by: -
Ben Skeggs authored
Signed-off-by:
-
Martin Peres authored
Signed-off-by:
-
Martin Peres authored
Expose all the hysteresis parameters + shutdown (emergency) + fan_boost (fixed pwm trip point). Signed-off-by:
-
Martin Peres authored
For now, we only boost the fan speed to the maximum and auto-mode when hitting the FAN_BOOST threshold and halt the computer when it reaches the shutdown temperature. The downclock and critical thresholds do nothing. On nv43:50 and nva3+, temperature is polled because of the limited hardware. I'll improve the nva3+ situation by implementing alarm management in PDAEMON whenever I can but polling once every second shouldn't be such a problem. v2 (Ben Skeggs): - rebased v3: fixed false-detections and threshold reprogrammation handling on nv50:nvc0 Signed-off-by:
-
Martin Peres authored
Based on Ben Skeggs's nvc0 patch. Tested on my nv4b, 84 and 92. Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Martin Peres authored
We are going to use PTHERM's IRQs for thermal monitoring but we need to route them first. On nv31-50, PBUS's IRQ line is shared with GPIOs IRQs. It seems like nv10-31 GPIO interruptions aren't well handled. I kept the original behaviour but it is wrong and may lead to an IRQ storm. Since we enable all PBUS IRQs, we need a way to avoid being stormed if we don't handle them. The solution I used was to mask the IRQs that have not been handled. This will also print one message in the logs to let us know. v2: drop the shared intr handler because of was racy v3: style fixes v4: drop a useless construct in the chipset-dependent INTR v5: add BUS to the disable mask v6 (Ben Skeggs): - general tidy to match the rest of the driver's style - nva3->nvc0, nva3 can be serviced just fine with nv50.c, rnndb even notes that the THERM_ALARM bit got left in the hw until fermi anyway.. so, it's not going to conflict - removed the peephole and user stuff, for the moment.. will handle them later if we find a good reason to actually care.. - limited INTR_EN to just what we can handle for now, mostly to prevent spam of unknown status bits (seen on at least nv4x) Signed-off-by:
-
Martin Peres authored
v2: improved design but drops safety monitoring (to be in a later patch) v3: fix locking and mode management v4: gently fallback to the no-control mode when temperature cannot be got and use kernel-provided min/max macros v5 (Ben Skeggs): - rebased on my previous patches v6: fix hysterisis management in trip-based auto fan management This commit also forbids access to fan management to nvc0+ chipsets as fan management is already taken care of my PDAEMON's default fw. Signed-off-by: -
Martin Peres authored
v2 (Ben Skeggs): - split from larger patch - fixed to not require alarm resched patch Signed-off-by:
-
Martin Peres authored
Signed-off-by:
-
Martin Peres authored
v2: change percent from int to atomic_t v3: random fixes v4 (Ben Skeggs): - adapted for split-out fan-control "protocol" structure - removed need for timer resched - support for forcing 'toggle' control on PWM boards Signed-off-by:
-
Ben Skeggs authored
Signed-off-by:
-
Ben Skeggs authored
Mostly to allow for the possibility of testing 'toggle' fan control easily. Signed-off-by:
-
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
Signed-off-by: -
Ben Skeggs authored
This info will be used by two more implementations in upcoming commits. Signed-off-by:
-
