Age | Commit message (Collapse) | Author |
|
Removes need for M2MF subchannel usage on NVC0+.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
I want to be able to use REF_CNT from other places in the kernel without
pushing a fence object onto the list of emitted fences.
The current code makes an assumption that every time the acked sequence is
bumped that there's at least one fence on the list that'll be signalled.
This will no longer be true in the near future.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
These are FIFO methods, it doesn't matter what subchannel is being used.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There was once good reasons for wanting the drm to be able to use M2MF etc
on user channels, but they're not relevant anymore. For the general
buffer move case, we've already lost by transferring between vram/sysmem
already so the context switching overhead is minimal in comparison.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
NVIDIA appear to do these around the same place they do the MODE_CTRL
methods, and for DP at least we need to bash some extra bits in "syncs"
to keep EVO happy.
It's a bit of a guess as to the 6/8bpc, but i have no better idea yet.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
GF119 will use this too.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
The shift from hwsq_data = 0x1400 to 0x080000 actually happened in nv94, not nv92
This fixes some reclocking issues on my newly acquired nv92
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Off-chip encoders (which we don't support yet anyway), and newer chipsets
(such as NVD9...), will need their own code for this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
More code to do the same thing, but will make it easier to handle various
changes that could possibly happen the the VBIOS tables.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Refactored to allow shadowing of VBIOS images longer than 64KiB, which
allows us to pass the VBIOS checksum test on certain boards.
There's also a workaround for reading the PROM VBIOS on some chipsets.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There's cards out there with completely messed up PCIROM images that have
a perfectly valid signature.. Sigh!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Theoretically handles CRTC2/CRTC3, should any GF119 out there actually
have them enabled. The room is there for the regs etc, so why not :)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
This patch fixes two small issues in timing generation as spotted on
several NVCx cards.
In addition, the header of the file is updated to also contain (some of)
the current developers of this code.
Signed-off-by: Roy Spliet <r.spliet@student.tudelft.nl>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Fixes reclocking failure on some chips where we attempted to set PDAEMON
to PLL mode.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
The comparison (lpre == DP_TRAIN_PRE_EMPHASIS_9_5) is always false:
lpre is initialized as (lane & 0x0c) >> 2, which is at most 3, while
DP_TRAIN_PRE_EMPHASIS_9_5 is defined as (3 << 3).
Signed-off-by: Xi Wang <xi.wang@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
There's a HP laptop out there where the MXM version in the VBIOS doesn't
match what the ACPI implementation is expecting. These tables will accept
0x00 to MXMS to return latest version, but *only* if MXMI has been called
first..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
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>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Christoph Bumiller <e0425955@student.tuwien.ac.at>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
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>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
|
|
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>
|
|
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>
|
|
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|
|
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>
|
|
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@labri.fr>
|
|
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>
|
|
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>
|
|
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>
|
|
Signed-off-by: Martin Peres <martin.peres@labri.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
|