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>
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>
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>
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>
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>
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>
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>
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>
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>
- 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>
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>
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>
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>
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>
I'd like to export the corresponding functions from the i2c core
so that I can use them in fallback bit-banging in i915.ko
v2: Adapt to new i2c export patch.
Cc: nouveau@lists.freedesktop.org
Acked-by: Dave Airlie <airlied@gmail.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
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>
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>
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>
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>
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>
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>
Both changes in dc97b3409a 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>
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>
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>
ttm tt rework modified the way we allocate and populate the
ttm_tt structure, the AGP side was missing some bit to properly
work. Fix those and fix radeon and nouveau AGP support.
Tested on radeon only so far.
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
"drm/ttm: callback move_notify any time bo placement change v4" failed to
avoid a NULL pointer dereference in nouveau caused by move_notify being
expected to handle that case now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
- moves out of nouveau_bios.c and demagics the logical state definitions
- simplifies chipset-specific driver interface
- makes most of gpio irq handling common, will use for nv4x hpd later
- api extended to allow both direct gpio access, and access using the
logical function states
- api extended to allow for future use of gpio extender chips
- pre-nv50 was handled very badly, the main issue being that all GPIOs
were being treated as output-only.
- fixes nvd0 so gpio changes actually stick, magic reg needs bashing
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We don't need more than the line id to determine the PWM controller, and
the GPIO interfaces are about to change somewhat.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
More work needs to be done on supporting the different memory types.
v2 (Ben Skeggs):
- fixed up conflicts from not having pausing patch first
- restructured code somewhat to fit with how all the other code works
- fixed bug where incorrect mpll_ctrl could get set sometimes
- removed stuff that's cargo-culted from the binary driver
- merged nv92+ display disable into hwsq
- fixed incorrect opcode 0x5f magic at end of ucode
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The DCB table provided by the VBIOS on most MXM chips has a number of
entries which either need to be disabled, or modified according to the
MXM-SIS Output Device Descriptors.
The x86 vbios code usually takes care of this for us, however, with the
large number of laptops now with switchable graphics or optimus, a lot
of the time nouveau is responsible for POSTing the card instead - leaving
some fun situations like, plugging in a monitor and having nouveau decide
3 connectors actually just got plugged in..
No MXM-SIS fetching methods implemented yet.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Another case where we parsed vbios data to some structs, then again use
that info once to construct another set of data. Skip the intermediate
step.
This is also slightly improved in that we can now use DCB 3.x connector
table info, which will allow NV4x to gain hotplug support, and to make
quirks for SPWG LVDS panels unnecessary.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
i2c-algo-bit doesn't actually work very well on one card I have access to
(NVS 300), random single-bit errors occur most of the time - what we're
doing now is closer to what xf86i2c.c does.
The original plan was to figure out why i2c-algo-bit fails on the NVS 300,
and fix it. However, while investigating I discovered i2c-algo-bit calls
cond_resched(), which makes it a bad idea for us to be using as we execute
VBIOS scripts from a tasklet, and there may very well be i2c transfers as
a result.
So, since I already wrote this code in userspace to track down the NVS 300
bug, and it's not really much code - lets use it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was using nv_mask, which is bad. Reading the reg senses the current line
states, which aren't necessarily the states we're trying to drive the
lines to.
Fixed to store SCL driver state just as we already do for SDA.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not much point parsing the vbios data into a struct which is only used once
to parse the data into another struct, go directly from vbios to
nouveau_i2c_chan.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This primary reason for this was mostly to avoid duplication of some of
this stuff by the MXM-SIS parser. However, some other cleanups will also
follow this as a result.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Spotted while messing with overlay channels (probably as a result of
sending a similar "disable" sequence as we do for the flip channels).
The value in 0x61008c was 0x20, which one would reasonably guess is
"bit 5 == something to report about evo channel 5" - but who knows.
Spotted the binary driver getting this too, and it appears to not do
anything exciting as a result. So, handle it the same way and avoid
an IRQ storm.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Pre-nva3 will likely require far more extensive setup, and nvd9 needs to
be checked to find its SOR_HDMI/SOR_AUDIO blocks.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
read_pll_ref() needs to take into account the refclk src bits in 0xc040 on
some chipsets, it wasn't doing this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This area is horrifically complicated on these chipsets, and it's likely we
will need at least a few more tweaks yet.
Oh yes, and it's completely disabled on IGPs for the moment. From traces,
things look potentially different there yet again. Sigh...
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Following to "drm/nv50/pm: s/unk05/vdec/", let's rename the PLL to PLL_VDEC
PLL names are purely indicative and are based on the most important engine
it clocks.
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reporting an error is better than silently refusing to reclock.
V2: Use the same logic on nv40
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes a case where we don't get separate supervisor interrupt sequences for
disconnect and modeset events.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Should fix issues with kexec, and as a nice side bonus, the code to avoid
having PDISP disappear will also fix hibernate on those effected systems.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This has the effect of ensuring the encoders which were active before we
loaded get disconnected properly before we start reprogramming them.
Also removing a bit of cargo-cult from the initial evo pushbuf.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
PDISP doesn't like it when disabled CRTCs are poked.
Fixes external output not coming to life when it has cursor on.
https://bugs.freedesktop.org/show_bug.cgi?id=41608
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Otherwice code that responsible for idling the card can't work.
BIOS init tables are supposed to init the clocks to correct values,
so that shouldn't cause any problems (we don't reclock by default anyway)
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Because doing polling while hardware is disabled is a bad idea...
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Exposes the same connector properties as the Radeon implementation, however
their behaviour isn't exactly the same. The primary difference being that
unless both hborder/vborder have been defined by the user, the driver will
keep the aspect ratio of the overscanned area the same as the mode the
display is programmed for.
Enabled for digital outputs on GeForce 8 and up, excluding GF119.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
A NV49 appeared a while back that was using the "nv41 style" pwm registers,
rather than the "nv40 style" ones my board is using. This disproves the
previous theory that the pwm controller choice is chipset-specific.
So, after looking at a bunch of vbios images it appears that the next viable
theory is that we should select the pwm controller to use based on the gpio
line the fan is tied to, just like we do on nv50.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The handling of the internal pwm fan controller is similar enough between
current chipsets that it makes sense to share the logic, and bugfixes :)
No hw backends converted yet, will automatically fall-through to the
"old" per-chipset fanspeed hooks for now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Exposes the following sysfs entries:
- fan0_input: read the rotational speed of the fan (poll a bit during 250ms)
- pwm0: set the pwm duty cycle
- pwm0_min/max: set the minimum/maximum pwm value
v2 (Ben Skeggs):
- nv50 pwm controller code removed in favour of other more complete code
- FAN_RPM -> FAN_SENSE
- merged FAN_SENSE readout into common code, not at all nv50-specific
- protected fanspeed changes with perflvl_wr
- formatting tidying
- added some comments where things are shaky
v3 (Martin Peres)
- ensure duty min/max from thermal table are sane
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Merge in the upstream tree to bring in the mainline fixes.
Conflicts:
drivers/gpu/drm/exynos/exynos_drm_fbdev.c
drivers/gpu/drm/nouveau/nouveau_sgdma.c
Otherwise each driver would need to keep the information inside
their own framebuffer object structure. Also add offsets[]. BOs
on the other hand are driver specific, so those can be kept in
driver specific structures.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Previously we were calling back move_notify in error path when the
bo is returned to it's original position or when destroy the bo.
When destroying the bo set the new mem placement as NULL when calling
back in the driver.
Updating nouveau to deal with NULL placement properly.
v2: reserve the object before calling move_notify in bo destroy path
at that point ttm should be the only piece of code interacting
with the object so atomic_set is safe here.
v3: callback move notify only once the bo is in its new position
call move notify want swaping out the buffer
v4:- don't call move_notify when swapin out bo, assume driver should
do what is appropriate in swap notify
- move move_notify call back to ttm_bo_cleanup_memtype_use for
destroy path
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Provide helper function to compute the kernel memory size needed
for each buffer object. Move all the accounting inside ttm, simplifying
driver and avoiding code duplication accross them.
v2 fix accounting of ghost object, one would have thought that i
would have run into the issue since a longtime but it seems
ghost object are rare when you have plenty of vram ;)
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
Move dma data to a superset ttm_dma_tt structure which herit
from ttm_tt. This allow driver that don't use dma functionalities
to not have to waste memory for it.
V2 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V3 Make sure page list is initialized empty
V4 typo/syntax fixes
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
If the card is capable of more than 32-bit, then use the default
TTM page pool code which allocates from anywhere in the memory.
Note: If the 'ttm.no_dma' parameter is set, the override is ignored
and the default TTM pool is used.
V2 use pci_set_consistent_dma_mask
V3 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
CC: Ben Skeggs <bskeggs@redhat.com>
CC: Francisco Jerez <currojerez@riseup.net>
CC: Dave Airlie <airlied@redhat.com>
Signed-off-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Move the page allocation and freeing to driver callback and
provide ttm code helper function for those.
Most intrusive change, is the fact that we now only fully
populate an object this simplify some of code designed around
the page fault design.
V2 Rebase on top of memory accounting overhaul
V3 New rebase on top of more memory accouting changes
V4 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
ttm_backend will only exist with a ttm_tt, and ttm_tt
will only be of interest when bound to a backend. Merge them
to avoid code and data duplication.
V2 Rebase on top of memory accounting overhaul
V3 Rebase on top of more memory accounting changes
V4 Rebase on top of no memory account changes (where/when is my
delorean when i need it ?)
V5 make sure ttm is unbound before destroying, change commit
message on suggestion from Tormod Volden
Signed-off-by: Jerome Glisse <jglisse@redhat.com>
Reviewed-by: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
Reviewed-by: Thomas Hellstrom <thellstrom@vmware.com>
NFI why this only started appearing now. The use of the uninitialised var
can't actually happen, so perhaps my compiler just got stupider.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The entire RAMIN is allocated to be 'size', but the heap is
specified as 'base' + 'size' inside RAMIN, so it will overflow
past RAMIN by 'base' bytes on NV50+ and clobber other allocatons
unless it's size is adjusted.
Signed-off-by: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Without this, they return bytes written since the last update of
the offset, but we want the full offset.
Trace shows setting this on GPC[0]/TP[0] is enough.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file. Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.
v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
pull in Ville's fix for the memcpy in drm_plane_init
apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>
From fdf1fdebaa00f81de18c227f32f8074c8b352d50 Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sun, 30 Oct 2011 19:06:07 -0700
Subject: [PATCH] drm: Make the per-driver file_operations struct const
The DRM layer keeps a copy of struct file_operations inside its
big driver struct... which prevents it from being consistent and static.
For consistency (and the general security objective of having such things
static), it's desirable to get this fixed.
This patch splits out the file_operations field to its own struct,
which is then "static const", and just stick a pointer to this into
the driver struct, making it more consistent with how the rest of the
kernel does this.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Framebuffer's BPP is not that important but can waste significant part
of memory on low-VRAM cards. Lower it to 8bpp on < 32MB cards and to
16bpp on 64MB cards. It can still be overridden by video= option.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes the framebuffer memory allocation failure seen on some
low-memory cards, followed by X refusing to start.
https://bugs.freedesktop.org/show_bug.cgi?id=42384
Reported-by: Chris Paulson-Ellis <chris@edesix.com>
Signed-off-by: Francisco Jerez <currojerez@riseup.net>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Most serious is for chips with only 1 TPC, we'd get stuck in an infinite
loop. The fix here will slightly change the setup for all other chipsets
too, but, it shouldn't matter too much, and this all needs figuring out
and likely redone anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
memtimings is a valid pointer here, the intent was to test for
kcalloc() failure.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Confirmed to fix random hangs while running all Unegine demos on NV86.
Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fence lock needs to be initialized before any call to nouveau_channel_put
because it calls nouveau_channel_idle->nouveau_fence_update which uses
fence lock.
BUG: spinlock bad magic on CPU#0, test/24134
lock: ffff88019f90dba8, .magic: 00000000, .owner: <none>/-1, .owner_cpu: 0
Pid: 24134, comm: test Not tainted 3.0.0-nv+ #800
Call Trace:
spin_bug+0x9c/0xa3
do_raw_spin_lock+0x29/0x13c
_raw_spin_lock+0x1e/0x22
nouveau_fence_update+0x2d/0xf1
nouveau_channel_idle+0x22/0xa0
nouveau_channel_put_unlocked+0x84/0x1bd
nouveau_channel_put+0x20/0x24
nouveau_channel_alloc+0x4ec/0x585
nouveau_ioctl_fifo_alloc+0x50/0x130
drm_ioctl+0x289/0x361
do_vfs_ioctl+0x4dd/0x52c
sys_ioctl+0x42/0x65
system_call_fastpath+0x16/0x1b
It's easily triggerable from userspace.
Additionally remove double initialization of chan->fence.pending.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Reportedly this has been causing stability and corruption issues after
resuming from suspend for a few people.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This reverts commit dfadbbdb57.
Further upstream discussion between Marek and Thomas decided this wasn't
fully baked and needed further work, so revert it before it hits mainline.
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-nouveau-next' of git://git.freedesktop.org/git/nouveau/linux-2.6: (353 commits)
drm/nouveau: remove allocations from gart populate() hook
drm/nvc0/fb: slightly improve PMFB intr handling, move out of nvc0_graph.c
drm/nvc0/fifo: avoid touching missing subfifos
drm/nvd9/disp: bail out of mode_set_base if no fb bound to crtc
drm/nvd9/disp: stub some more api hooks so we don't oops on resume
drm/nouveau: fix printk typo in ioremap failure path
drm/nvc0/pm: minor clock readback fixes
drm/nv40/pm: execute memory reset script from vbios
drm/nv50/gr: refactor initialisation
drm/nouveau: if requested, try harder at disabling sysmem pushbufs
drm/nv50/gr: enable ctxprog xfer only when we need it to save power
drm/nouveau/dp: add support for displayport table 0x30
drm/nouveau/dp: return master dp table pointer too when looking up encoder
drm/nouveau/bios: simplify U/d table hash matching func to just match
drm/nouveau/dp: preserve non-pattern bits in DP_TRAINING_PATTERN_SET
drm/nvc0/gr: remove MODULE_FIRMWARE() lines
drm/nouveau/dp: use alternate lane mask for nvaf
drm/nouveau/dp: link rate scripts are selected with a comparison table
drm/nv40/pm: write nv40-specific reclocking routines
drm/nv40/pm: parse geometric delta clock from vbios
...
Since some somewhat questionable changes a while back, TTM provides a
completely empty array of struct dma_address that stays around for the
entire lifetime of the TTM object.
Lets use this array, *always*, rather than wasting yet more memory on
another array who's purpose is identical, as well as yet another bool array
of the same size saying *which* of the previous two arrays to use...
This change will also solve the high order allocation failures seen by
some people while using nouveau.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This patch adds instructions to ctxprog and by doing, impacts context
switching performance. My testcase showed a 1% performance cost using
glxgears that is a context-switch bound application.
Please test and report bugs/performance/power/other.
Many thanks to Maxim Levitsky for his dedicated work on lowering power
consumption with nouveau.
More patches are coming thanks to his work:
https://bugs.freedesktop.org/show_bug.cgi?id=37922
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Written from observations of my NVD9's vbios, completely untested due to
my NVD9 lacking actual DisplayPort connectors..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Will need to be able to distinguish 2.0/2.1 from 3.0 soon. Also, move
the vbios parsing to nouveau_dp where it belongs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We don't use these by default anymore, and there's been complaints from a
number of places thinking that the firmware blobs are required still.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
