kernel/git/stable/linux.git/drivers/video/nvidia/nvidia.c, branch master

video: move fbdev to drivers/video/fbdev

2014-04-17T05:10:19+00:00

The drivers/video directory is a mess. It contains generic video related files, directories for backlight, console, linux logo, lots of fbdev device drivers, fbdev framework files. Make some order into the chaos by creating drivers/video/fbdev directory, and move all fbdev related files there. No functionality is changed, although I guess it is possible that some subtle Makefile build order related issue could be created by this patch. Signed-off-by: Tomi Valkeinen Acked-by: Laurent Pinchart Acked-by: Geert Uytterhoeven Acked-by: Rob Clark Acked-by: Jingoo Han Acked-by: Daniel Vetter

video: nvidiafb: remove unnecessary pci_set_drvdata()

2014-01-17T08:57:39+00:00

The driver core clears the driver data to NULL after device_release or on probe failure. Thus, it is not needed to manually clear the device driver data to NULL. Signed-off-by: Jingoo Han Signed-off-by: Tomi Valkeinen

Drivers: video: remove __dev* attributes.

2013-01-03T23:57:01+00:00

CONFIG_HOTPLUG is going away as an option. As a result, the __dev* markings need to be removed. This change removes the use of __devinit, __devexit_p, __devinitdata, __devinitconst, and __devexit from these drivers. Based on patches originally written by Bill Pemberton, but redone by me in order to handle some of the coding style issues better, by hand. Cc: Bill Pemberton Signed-off-by: Greg Kroah-Hartman

drivers/video/nvidia/nvidia.c: fix warning

2012-01-13T04:13:03+00:00

Fix the int/bool confusion in there. drivers/video/nvidia/nvidia.c:1602: warning: return from incompatible pointer type Cc: Florian Tobias Schandinat Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

console: rename acquire/release_console_sem() to console_lock/unlock()

2011-01-26T00:50:06+00:00

The -rt patches change the console_semaphore to console_mutex. As a result, a quite large chunk of the patches changes all acquire/release_console_sem() to acquire/release_console_mutex() This commit makes things use more neutral function names which dont make implications about the underlying lock. The only real change is the return value of console_trylock which is inverted from try_acquire_console_sem() This patch also paves the way to switching console_sem from a semaphore to a mutex. [akpm@linux-foundation.org: coding-style fixes] [akpm@linux-foundation.org: make console_trylock return 1 on success, per Geert] Signed-off-by: Torben Hohn Cc: Thomas Gleixner Cc: Greg KH Cc: Ingo Molnar Cc: Geert Uytterhoeven Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

nvidiafb: remove open_lock mutex

2009-04-01T15:59:34+00:00

Remove mutex from the nvidiafb_open/nvidiafb_release functions as these operations are mutexed at fb layer. Signed-off-by: Alessio Igor Bogani Cc: Krzysztof Helt Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

video: replace remaining FUNCTION occurrences

2008-04-28T15:58:42+00:00

__FUNCTION__ is gcc-specific, use __func__ Signed-off-by: Harvey Harrison Cc: "Antonino A. Daplas" Cc: Krzysztof Helt Cc: Antonino Daplas Cc: Antonino A. Daplas Cc: Antonino Daplas Cc: Richard Purdie Cc: Jean Delvare Cc: Adrian Bunk Cc: Russell King Cc: Benjamin Herrenschmidt Cc: Ben Dooks Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

fbdev: nv: drop useless MODULE ifdefs

2008-04-28T15:58:40+00:00

Signed-off-by: Alexey Dobriyan Cc: Antonino A. Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds

PM: Introduce PM_EVENT_HIBERNATE callback state

2008-02-23T18:40:04+00:00

During the last step of hibernation in the "platform" mode (with the help of ACPI) we use the suspend code, including the devices' ->suspend() methods, to prepare the system for entering the ACPI S4 system sleep state. But at least for some devices the operations performed by the ->suspend() callback in that case must be different from its operations during regular suspend. For this reason, introduce the new PM event type PM_EVENT_HIBERNATE and pass it to the device drivers' ->suspend() methods during the last phase of hibernation, so that they can distinguish this case and handle it as appropriate. Modify the drivers that handle PM_EVENT_SUSPEND in a special way and need to handle PM_EVENT_HIBERNATE in the same way. These changes are necessary to fix a hibernation regression related to the i915 driver (ref. http://lkml.org/lkml/2008/2/22/488). Signed-off-by: Rafael J. Wysocki Acked-by: Pavel Machek Tested-by: Jeff Chua Signed-off-by: Linus Torvalds

fb: nvidiafb: Try harder at initial mode setting.

2008-02-06T18:41:16+00:00

The current nvidiafb_check_var() simply bails out if the selected mode is out of range of the panel dimensions. A good question would be why the bogus mode is being selected in the first place -- the panel dimensions that are read back are certainly bogus, but alas, I have no idea where to even begin looking at the i2c/EDID/DDC mess: nvidiafb: Device ID: 10de0165 nvidiafb: CRTC0 analog not found nvidiafb: CRTC1 analog not found nvidiafb: EDID found from BUS1 nvidiafb: CRTC 0 is currently programmed for DFP nvidiafb: Using DFP on CRTC 0 nvidiafb: Panel size is 1280 x 1024 nvidiafb: Panel is TMDS nvidiafb: unable to setup MTRR nvidiafb: Flat panel dithering disabled nvidiafb: PCI nVidia NV16 framebuffer (64MB @ 0xC0000000) In my .config I presently have: CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=y CONFIG_FB_NVIDIA_I2C=y I've not tried fiddling with these options, as I haven't the vaguest idea what I should be looking at. As a workaround, simply groveling for a new mode based on the probed dimensions seems to work ok. While it would be nice to debug this further and sort out why the panel information is bogus, I think it's still worth retrying the mode based on the panel information at hand as a last-ditch effort, rather than simply bailing out completely. Signed-off-by: Paul Mundt Cc: Antonino A. Daplas Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds