summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau
Commit message (Collapse)AuthorAgeFilesLines
...
* | drm/nouveau/pm: init only after display subsystem has been createdBen Skeggs2012-03-131-7/+5
| | | | | | | | | | | | | | | | This patch fixes an oops cause by pm_trigger accessing the (uninitialised) crtc list. Reported-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nvc0/fb: detect presense of second rankBen Skeggs2012-03-131-0/+1
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv50/display: expose color vibrance controlChristoph Bumiller2012-03-136-3/+85
| | | | | | | | | | Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv50-nvc0/vm: support unsnooped system memoryBen Skeggs2012-03-133-17/+17
| | | | | | | | | | | | | | | | | | | | v2 (Emil Velikov <emil.l.velikov@gmail.com>): - Fixed a regression on certain nv50 IGP due to not passing the correct target type to nv50_vm_addr() Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com> Tested-by: Johannes Obermayr <johannesobermayr@gmx.de>
* | drm/nouveau: recognise DCB connector type for DP+DVI+VGA DMS-59Ben Skeggs2012-03-132-1/+7
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/mem: handle dll_off for ddr2/ddr3Ben Skeggs2012-03-131-11/+23
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: extend profile interface for destroy/init/finiBen Skeggs2012-03-132-0/+25
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: rework to allow selecting separate profiles for ac/batteryBen Skeggs2012-03-134-46/+120
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: fix dll off -> dll on transitionsBen Skeggs2012-03-131-2/+7
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: detect when we need dll disabled for gddr3Ben Skeggs2012-03-133-1/+12
| | | | | | | | | | | | | | Fixes minor flickering on NVS295 when at perflvl 0. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nv50: fix detection of second vram rankBen Skeggs2012-03-131-1/+1
| | | | | | | | | | | | | | Goes a long way to correcting NVS295 memory reclocking issues. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: track mr2 for gddr3Ben Skeggs2012-03-131-1/+4
| | | | | | | | | | | | | | | | | | There's some "extended" GDDR3 chipsets out there with EMRS2 settings that change the layout of MRS/EMRS1 bitmaps.. Sigh.. Still need to track down how exactly we're supposed to handle this. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nv50/pm: wait for all fifo-connected engines to idle before reclockingMartin Peres2012-03-131-0/+2
| | | | | | | | | | Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv50/pm: use hwsq for engine reclocking tooBen Skeggs2012-03-131-87/+98
| | | | | | | | | | | | | | | | | | | | Idea from Martin Peres, different implementation by me. v2: Martin Peres: - fix mast calculation Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nv50/disp: more accurate function to determine active crtcsBen Skeggs2012-03-133-8/+28
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nv50/pm: initial work towards proper memory reclocking, with timingsBen Skeggs2012-03-131-46/+154
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: introduce ram reclocking helperBen Skeggs2012-03-132-0/+114
| | | | | | | | | | | | | | | | | | | | | | This will probably result in more lines of code, however, we're going to have at least 3 slightly different implementations of this very soon and I'd rather keep the ram reclocking logic separate from the hw specifics. DDR2/DDR3/GDDR3 implemented thus far, others will be added as necessary. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: embed timings into perflvl structsBen Skeggs2012-03-134-58/+54
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: calculate memory timings at perflvl creation timeBen Skeggs2012-03-135-298/+132
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Statically generating the PFB register and MR values for each timing set turns out to be insufficient. There's at least one (so far) known piece of information which effects MR values which is stored in the perflvl entry on some chipsets (and in another table on later ones), which is disconnected from the timing table entries. After this change we will generate a timing set based on an input clock frequency instead, and have this data stored in the performance level data. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: readback boot perflvl *before* parsing vbiosBen Skeggs2012-03-131-11/+19
| | | | | | | | | | | | | | We might want/need the boot data to generate the other perflevels. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: implement DDR2/DDR3/GDDR3/GDDR5 MR generation and validationRoy Spliet2012-03-134-152/+476
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Roy Spliet: - Implement according to specs - Simplify - Make array for mc latency registers Martin Peres: - squash and split all the commits from Roy - rework following Ben Skeggs comments - add a form of timings validation - store the initial timings for later use Ben Skeggs - merge slightly modified tidy-up patch with this one - remove perflvl-dropping logic for the moment Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/pm: restructure bios table parsingBen Skeggs2012-03-131-173/+217
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It turns out we need access to some additional information in various VBIOS tables to handle PFB memory timings correctly. Rather than hack in parsing of the new stuff in some kludgy way, I've restructured the VBIOS parsing to be more primitive, so we can use them in more flexible ways in the future. The perflvl->timing association code is disabled for the moment until it can be reworked. We don't use this stuff yet anyway, so no harm done. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau/pm: avoid potential divide-by-zeroBen Skeggs2012-03-131-1/+1
| | | | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Martin Peres <martin.peres@labri.fr>
* | drm/nouveau: Fix module parameter description formatsJean Delvare2012-03-131-7/+7
| | | | | | | | | | | | | | | | | | | | Module parameter descriptions don't take a trailing \n, otherwise it breaks formatting of modinfo's output. Also remove trailing space. Signed-off-by: Jean Delvare <jdelvare@suse.de> Cc: David Airlie <airlied@linux.ie> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/pm: improve memory timing generationRoy Spliet2012-03-132-65/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Rename several VBIOS entries to closer match the real world - Add the missing 0x100238 and 0x100240 register values - Parse bit 14 of the VBIOS timing table - "Magic value" -> tCWL, fixing some minor bugs in the process - Also name a few more by their name rather than their number. - Some values seem to be dependent on the memory type. Fix Edits by Martin Peres <martin.peres@labri.fr>: - this is a squash commit - reworked for fixing some style issues Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl> Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/pm: improve the reclocking logs' readabilityMartin Peres2012-03-131-5/+25
| | | | | | | | | | Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: move pwm_divisor to the nouveau_pm_fan structMartin Peres2012-03-133-3/+3
| | | | | | | | | | Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/pm: restore fan speed after suspendMartin Peres2012-03-132-1/+9
| | | | | | | | | | Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau/pm: style fixesMartin Peres2012-03-134-70/+110
| | | | | | | | | | Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: rework the init/takedown orderingBen Skeggs2012-03-131-40/+41
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nvc0: add initial memory type detectionBen Skeggs2012-03-131-0/+2
| | | | | | | | | | | | | | | | Uses only the VBIOS tables, from what I can tell this is what NVIDIA do too, I was able to change the detected memory type by modifying this table on a NVC1 chipset. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv50: hopefully handle the DDR2/DDR3 memtype detection somewhat betterBen Skeggs2012-03-133-3/+27
| | | | | | | | | | | | | | | | | | | | | | M version 2 appears to have a table with some form of memory type info available. NVIDIA appear to ignore the table information except for this DDR2/DDR3 case (which has the same value in 0x100714). My guess is this is due to some of the supported memory types not being represented in the table. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv50: add memory type detectionBen Skeggs2012-03-131-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | DDR1/DDR[23] confirmed on NVA8 (see note about DDR3 in source) by changing the value and watching the binary driver's behaviour. GDDR3/4 values confirmed on a NV96 via the same method above. That GDDR4 is present is interesting, as far as I can see no boards using it were ever released. GDDR5 value is based on VBIOS images of known GDDR5 boards. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv20-nv40: add memory type detectionBen Skeggs2012-03-134-2/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NV20/NV30 is partially educated guesswork at this point, based on any information around about available memory types and a horribly unspeakable amount of vbios image scouring. I'm not entirely certain the GDDR3 define is correct, I have not spotted a single vbios with that value yet (though it is mentioned in some 1218-using nv4x vbios), but there are reports that some nv3x did use it.. NV40(100914) confirmed by switching an NV49 to DDR1/DDR2 values and making sure that the binary driver behaviour showed it had detected DDR1/DDR2 instead of GDDR3 before dying horribly. NV40(100474) confirmed by doing much the same task as above on an NV44, except this was *much* easier as changing the values didn't seem to have any noticable effect on the memory controller aside from changing the binary driver's behaviour. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nv20: split PFB code out of nv10_fb.cBen Skeggs2012-03-135-131/+198
| | | | | | | | | | | | | | Most functions were quite different between NV10/NV20 already, and they're about to get even more so. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: memory type detection for the really old chipsetsBen Skeggs2012-03-132-0/+13
| | | | | | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* | drm/nouveau: move vram detection funcs to chipset-specific fb codeBen Skeggs2012-03-136-76/+127
|/ | | | | | | Also, display detected memory type in logs - though, we don't even try to detect this yet. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm: move pci bus master enable into driver.Dave Airlie2012-02-161-0/+2
| | | | | | | | | | | | | | | The current enabling of bus mastering in the drm midlayer allows a large race condition under kexec. When a kexec'ed kernel re-enables bus mastering for the GPU, previously setup dma blocks may cause writes to random pieces of memory. On radeon the writeback mechanism can cause these sorts of issues. This patch doesn't fix the problem, but it moves the bus master enable under the individual drivers control so they can move enabling it until later in their load cycle and close the race. Fix for radeon kms driver will be in a follow-up patch. Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: do not set fb_info->pixmap fieldsSascha Hauer2012-02-091-5/+1
| | | | | | | | | | | | The drm drivers set the fb_info->pixmap fields without setting fb_info->pixmap.addr. If this is not set the fb core will overwrite these all fb_info->pixmap fields anyway, so there is not much point in setting them in the first place. [airlied: dropped nvidiafb piece - not mine] Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: add convenience function to create an range propertySascha Hauer2012-02-091-8/+2
| | | | | | | | Creating a range property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm: add convenience function to create an enum propertySascha Hauer2012-02-091-5/+5
| | | | | | | | Creating an enum property is a common pattern, so create a convenience function for this and use it where appropriate. Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nv50/pm: signedness bug in nv50_pm_clocks_pre()Dan Carpenter2012-02-011-2/+2
| | | | | | | | | | | | calc_mclk() returns zero on success and negative on failure but clk is a u32. v2: Martin Peres: - clk should be an int, not a u32 Signed-off-by: Martin Peres <martin.peres@labri.fr> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/gem: fix fence_sync race / oopsBen Skeggs2012-02-011-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Due to a race it was possible for a fence to be destroyed while another thread was trying to synchronise with it. If this happened in the fallback non-semaphore path, it lead to the following oops due to fence->channel being NULL. BUG: unable to handle kernel NULL pointer dereference at (null) IP: [<fa9632ce>] nouveau_fence_update+0xe/0xe0 [nouveau] *pde = a649c067 SMP Modules linked in: fuse nouveau(O) ttm(O) drm_kms_helper(O) drm(O) mxm_wmi video wmi netconsole configfs lockd bnep bluetooth rfkill ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack ip6table_filter ip6_tables snd_hda_codec_realtek snd_hda_intel snd_hda_cobinfmt_misc uinput ata_generic pata_acpi pata_aet2c_algo_bit i2c_core [last unloaded: wmi] Pid: 2255, comm: gnome-shell Tainted: G O 3.2.0-0.rc5.git0.1.fc17.i686 #1 System manufacturer System Product Name/M2A-VM EIP: 0060:[<fa9632ce>] EFLAGS: 00010296 CPU: 1 EIP is at nouveau_fence_update+0xe/0xe0 [nouveau] EAX: 00000000 EBX: ddfc6dd0 ECX: dd111580 EDX: 00000000 ESI: 00003e80 EDI: dd111580 EBP: dd121d00 ESP: dd121ce8 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 Process gnome-shell (pid: 2255, ti=dd120000 task=dd111580 task.ti=dd120000) Stack: 7dc86c76 00000000 00003e80 ddfc6dd0 00003e80 dd111580 dd121d0c fa96371f 00000000 dd121d3c fa963773 dd111580 01000246 000ec53d 00000000 ddfc6dd0 00001f40 00000000 ddfc6dd0 00000010 dc7df840 dd121d6c fa9639a0 00000000 Call Trace: [<fa96371f>] __nouveau_fence_signalled+0x1f/0x30 [nouveau] [<fa963773>] __nouveau_fence_wait+0x43/0xd0 [nouveau] [<fa9639a0>] nouveau_fence_sync+0x1a0/0x1c0 [nouveau] [<fa964046>] validate_list+0x176/0x300 [nouveau] [<f7d9c9c0>] ? ttm_bo_mem_put+0x30/0x30 [ttm] [<fa964b8a>] nouveau_gem_ioctl_pushbuf+0x48a/0xfd0 [nouveau] [<c0406481>] ? die+0x31/0x80 [<f7c93d98>] drm_ioctl+0x388/0x490 [drm] [<c0406481>] ? die+0x31/0x80 [<fa964700>] ? nouveau_gem_ioctl_new+0x150/0x150 [nouveau] [<c0635c7b>] ? file_has_perm+0xcb/0xe0 [<f7c93a10>] ? drm_copy_field+0x80/0x80 [drm] [<c0564f56>] do_vfs_ioctl+0x86/0x5b0 [<c0406481>] ? die+0x31/0x80 [<c0635f22>] ? selinux_file_ioctl+0x62/0x130 [<c0554f30>] ? fget_light+0x30/0x340 [<c05654ef>] sys_ioctl+0x6f/0x80 [<c099e3a4>] syscall_call+0x7/0xb [<c0406481>] ? die+0x31/0x80 [<c0406481>] ? die+0x31/0x80 Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Cc: stable@vger.kernel.org
* drm/nouveau: fix typo on mxmdcb optionBen Skeggs2012-02-011-1/+1
| | | | Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/mxm: pretend to succeed, even if we can't shadow the MXM-SISBen Skeggs2012-02-011-0/+9
| | | | | | | | | There's at least one known case where our shadowing code is buggy, and we fail init. Until we can be confident we're doing all this correctly, lets succeed and risk crazy bios tables rather than failing for perfectly valid configs too. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/nouveau/disp: check that panel power gpio is enabled at init timeBen Skeggs2012-02-012-2/+13
| | | | | Reported-by: Yuriy Khomchik <homyur@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* drm/ttm: fix two regressions since move_notify changesBen Skeggs2012-01-251-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Both changes in dc97b3409a790d2a21aac6e5cdb99558b5944119 cause serious regressions in the nouveau driver. move_notify() was originally able to presume that bo->mem is the old node, and new_mem is the new node. The above commit moves the call to move_notify() to after move() has been done, which means that now, sometimes, new_mem isn't the new node at all, bo->mem is, and new_mem points at a stale, possibly-just-been-killed-by-move node. This is clearly not a good situation. This patch reverts this change, and replaces it with a cleanup in the move() failure path instead. The second issue is that the call to move_notify() from cleanup_memtype_use() causes the TTM ghost objects to get passed into the driver. This is clearly bad as the driver knows nothing about these "fake" TTM BOs, and ends up accessing uninitialised memory. I worked around this in nouveau's move_notify() hook by ensuring the BO destructor was nouveau's. I don't particularly like this solution, and would rather TTM never pass the driver these objects. However, I don't clearly understand the reason why we're calling move_notify() here anyway and am happy to work around the problem in nouveau instead of breaking the behaviour expected by other drivers. Signed-off-by: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com> Cc: Jerome Glisse <j.glisse@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* nouveau: Support Optimus models for vga_switcherooPeter Lekensteyn2012-01-133-5/+42
| | | | | | | | | | | Newer nVidia cards with Optimus do not support/use the DSM switching functions. Instead, it require a DSM function to be called prior to bringing a device into D3 state. No other _DSM calls are necessary before/after enabling/disabling a device. Switching between discrete and integrated GPU is not supported by this Optimus _DSM call, therefore return on the switching method. Signed-off-by: Peter Lekensteyn <lekensteyn@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* nouveau: properly check for _DSM function supportPeter Lekensteyn2012-01-131-13/+22
| | | | | | | | | | According to the ACPI spec version 4, section 9.14.1, _DSM functions must return a value with the first bit enabled if any DSM functions are supported for the given UUID and revision ID. For a given function index n to be marked supported, bit n must be enabled. Signed-off-by: Peter Lekensteyn <lekensteyn@gmail.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
* drm/nouveau/pm: fix build with HWMON offDave Airlie2012-01-101-1/+1
| | | | | Reported-by: Randy Dunlap <rdunlap@xenotime.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
OpenPOWER on IntegriCloud