We previously assumed (incorrectly a lot of the time) that PTIMER would
be programmed at a frequency which'd give its 64-bit timestamps in
nanoseconds.
By programming PTIMER ourselves, we avoid this problem.
Reviewed-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The set will be replaced with a wait on the same flag by a subsequent
commit in order to halt a ctxprog's execution temporarily.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This is probably better than having to tell the common code about all the
clocks that exist on every chipset.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
This commit resolves a possible 'NULL pointer dereference'
It uses the same approach as radeon, intel and nouveau/nv50
Fixes bug 'Nouveau: Kernel oops when unplugging external monitor'
https://bugs.freedesktop.org/show_bug.cgi?id=40336
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
nv04_sgdma_bind binds the same page multiple times on
architectures where PAGE_SIZE != 4096.
Let's fix it.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not cleaning after alloc failure would result in crash on destroy,
because nouveau_sgdma_clear assumes "ttm_alloced" to be not null when
"pages" is not null.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Cc: stable@kernel.org
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Sometimes we want to know whether a buffer is busy and wait for it (bo_wait).
However, sometimes it would be more useful to be able to query whether
a buffer is busy and being either read or written, and wait until it's stopped
being either read or written. The point of this is to be able to avoid
unnecessary waiting, e.g. if a GPU has written something to a buffer and is now
reading that buffer, and a CPU wants to map that buffer for read, it needs to
only wait for the last write. If there were no write, there wouldn't be any
waiting needed.
This, or course, requires user space drivers to send read/write flags
with each relocation (like we have read/write domains in radeon, so we can
actually use those for something useful now).
Now how this patch works:
The read/write flags should passed to ttm_validate_buffer. TTM maintains
separate sync objects of the last read and write for each buffer, in addition
to the sync object of the last use of a buffer. ttm_bo_wait then operates
with one the sync objects.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (135 commits)
drm/radeon/kms: fix DP training for DPEncoderService revision bigger than 1.1
drm/radeon/kms: add missing vddci setting on NI+
drm/radeon: Add a rmb() in IH processing
drm/radeon: ATOM Endian fix for atombios_crtc_program_pll()
drm/radeon: Fix the definition of RADEON_BUF_SWAP_32BIT
drm/radeon: Do an MMIO read on interrupts when not uisng MSIs
drm/radeon: Writeback endian fixes
drm/radeon: Remove a bunch of useless _iomem casts
drm/gem: add support for private objects
DRM: clean up and document parsing of video= parameter
DRM: Radeon: Fix section mismatch.
drm: really make debug levels match in edid failure code
drm/radeon/kms: fix i2c map for rv250/280
drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
drm/nouveau: pass flag to engine fini() method on suspend
drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
drm/nv40/gr: rewrite/split context takedown functions
drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
drm/nouveau: Add a quirk for Gigabyte NX86T
...
* 'drm-nouveau-next' of git://anongit.freedesktop.org/git/nouveau/linux-2.6:
drm/nouveau/gr: disable fifo access and idle before suspend ctx unload
drm/nouveau: pass flag to engine fini() method on suspend
drm/nouveau: replace nv04_graph_fifo_access() use with direct reg bashing
drm/nv40/gr: rewrite/split context takedown functions
drm/nouveau: detect disabled device in irq handler and return IRQ_NONE
drm/nouveau: ignore connector type when deciding digital/analog on DVI-I
drm/nouveau: Add a quirk for Gigabyte NX86T
drm/nouveau: do not leak in nv20_graph_create
drm/nv50/dp: fix hack to work for macbooks booted via EFI
It may not be necessary to fail in certain cases (such as failing to idle)
on module unload, whereas on suspend it's important to ensure a consistent
state can be restored on resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's completely pointless to save the PGRAPH context when destroying a
channel, so don't bother.
This commit should also fix kernel.org bug 39422, where the DRM channel
state was incorrectly being saved because we left PGRAPH FIFO access
enabled while running the ctxprog.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If the connector table is lying, which it often does on the boards of a
particular manufacturer, we may end up doing the wrong thing. Listen
to the encoder table instead, it's more reliable.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The connector table lies, the card has DVI-I not HDMI
Fixes bug https://bugs.freedesktop.org/show_bug.cgi?id=35675
v2: Mention the bugreport
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
If we return due to an unknown chipset in
drivers/gpu/drm/nouveau/nv20_graph.c:nv20_graph_create() we'll leak the
memory allocated to 'pgraph'.
This patch should fix the leak.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Reviewed-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
drm_pci_device_is_pcie duplicates the funcationality of pci_is_pcie.
Convert callers of the former to the latter. This has the side benefit
of removing an unnecessary search in the PCI configuration space due to
using a saved PCIe capability offset.
[airlied: update for new callsite]
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Two of these error paths returned without freeing "ctx".
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
'drm/nouveau: rework vram init/fini ordering a little' changed
the order of instmem.init() and nouveau_mem_vram_init() which
resulted in using ramin_rsvd_vram before it was calculated and
failing to init any accel on pre-NV50 cards.
Since it's only used on <NV50 just calculate it where it's needed
and leave it as default 0 for NV50.
Signed-off-by: Younes Manton <younes.m@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
It's a regression from "drm/nouveau: create temp vmas for both src and
dst of bo moves".
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Many (all?) of the coefficients related to calculating the
correct temperature are signed integers
This patch correcly parses and stores those values
It also ensures that the default offset is 0 (previously 1)
Affected cards - the original nv50 and the nv40 family
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Commit "drm/nouveau: add some debug output if nouveau_mm busy at destroy time"
revealed an issue where vram mm takedown would actually fail due to there
still being nodes present, causing nouveau to leak a small amount of memory
on module unload.
This splits TTM/nouveau_mm a bit more cleanly and ensures nouveau_mm fini
isn't done until all gpuobjs are also destroyed.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
GPU virtual addresses are constant now so this should never be getting hit
anyway and userspace shouldn't break from them being ignored.
This is being done in preference to teaching the code how to deal with BOs
that exist at different virtual addresses within separate VMs.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Greatly simplifies a number of things, particularly once per-client GPU
address spaces are involved.
May add this back later once I know what things'll look like.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Was previously assuming a page size of 4KiB unless a VMA was present to
override it. Eventually, a buffer won't necessarily have a VMA at all at
some stages of its life, so we need to store this info elsewhere.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Abuses existing gpuobj_new() chan argument for this, which in turn forces
all NVOBJ_FLAG_VM allocations to be done from the global heap, not
suballocated from the channel's private heap. Not a problem though in
practise.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Userspace hasn't passed us a channel_hint for a long long time now, and
there isn't actually a need to do so anymore anyway.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
On chipsets using nouveau_vm, the virtual address stays constant, so
the value set at bo creation time is fine.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's lots of boards (all recent ones) that don't have this anymore, so
punt the message to debug loglevel.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Not a clue what it is yet, but we get the same numbers as NVIDIA now.
My 465 didn't seem to care to greatly *what* I bashed into these registers..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The ability to use NVIDIA's fuc has been retained *temporarily* in order
to better debug any issues that may be lingering in our initial attempt
at writing this ucode. Once I'm fairly confident we're okay, it'll be
removed.
There's a number of things not implemented by this fuc currently, but
most of it is sets of state that our context setup would not have used
anyway. No doubt we'll find out what they're for at some point, and
implement it if required.
This has been tested on 0xc0/0xc4 thus far, and from what I could tell
it worked as well as NVIDIA's. It's also been tested on 0xc1, but even
with NVIDIA's fuc that chipset doesn't work correctly with nouveau yet.
0xc3/0xc8/0xce should in theory be supported too, but I don't have the
hardware to check that.
There's no doubt numerous bugs to squash yet, please report any!
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need the physical VRAM address in vinst, even for objects mapped into
a vm, as the gpuobj suspend/resume code uses PMEM to access the object.
Previously, vinst was overloaded to mean "VRAM address" for !VM objects,
and "VM address" for VM objects, causing the wrong data to be accessed
during suspend/resume.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Until we know these should work properly, would much rather default to
noaccel than risk giving people corruption/hangs out of the box..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
There's issues with certain 3D apps still, unknown whether this is a kernel
issue or not.. It does appear that it may be in the 3D driver however.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Fixes DMAR faults during accel, more than likely a similar problem to what
was solved on nv50 previously.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Many stupid corrections of duplicated includes based on the output of
scripts/checkincludes.pl.
Signed-off-by: Vitaliy Ivanov <vitalivanov@gmail.com>
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
The DDX modifies DMA_SEMAPHORE on nv50 in order to implement sync-to-vblank,
things will go very wrong for cross-channel sync after this.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
While parsing the perf table, there is no check if
the num of entries read from the vbios is less than
the currently allocated number.
In case of a buggy vbios this will cause overwriting
of kernel memory, causing aditional problems.
Add a simple check in order to prevent the case
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
PCI(E)GART isn't quite stable it seems, fall back to old method until I get
the time to sort it out properly.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Should hopefully get modesetting at least from this, it appears these are
GF119 chipsets. Accel will come eventually, once I order a board.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
* 'drm-core-next' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6: (169 commits)
drivers/gpu/drm/radeon/atom.c: fix warning
drm/radeon/kms: bump kms version number
drm/radeon/kms: properly set num banks for fusion asics
drm/radeon/kms/atom: move dig phy init out of modesetting
drm/radeon/kms/cayman: fix typo in register mask
drm/radeon/kms: fix typo in spread spectrum code
drm/radeon/kms: fix tile_config value reported to userspace on cayman.
drm/radeon/kms: fix incorrect comparison in cayman setup code.
drm/radeon/kms: add wait idle ioctl for eg->cayman
drm/radeon/cayman: setup hdp to invalidate and flush when asked
drm/radeon/evergreen/btc/fusion: setup hdp to invalidate and flush when asked
agp/uninorth: Fix lockups with radeon KMS and >1x.
drm/radeon/kms: the SS_Id field in the LCD table if for LVDS only
drm/radeon/kms: properly set the CLK_REF bit for DCE3 devices
drm/radeon/kms: fixup eDP connector handling
drm/radeon/kms: bail early for eDP in hotplug callback
drm/radeon/kms: simplify hotplug handler logic
drm/radeon/kms: rewrite DP handling
drm/radeon/kms/atom: add support for setting DP panel mode
drm/radeon/kms: atombios.h updates for DP panel mode
...
Fix build errors when CONFIG_ACPI is enabled but MXM_WMI is not enabled
by selecting both MXM_WMI and ACPI_WMI (the latter just for kconfig
dependencies):
nouveau_acpi.c:(.text+0x2400c8): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2400cf): undefined reference to `mxm_wmi_call_mxds'
nouveau_acpi.c:(.text+0x2400fe): undefined reference to `mxm_wmi_call_mxmx'
nouveau_acpi.c:(.text+0x2402ba): undefined reference to `mxm_wmi_supported
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
When xorg state tracker wants to hide the cursor it calls set_cursor
with NULL buffer_handle and size=0x0, but nouveau refuses to hide it
because size is not 64x64... which is a bit odd. Both radeon and intel
check buffer_handle before validating size of cursor, so make nouveau
implementation consistent with them.
Signed-off-by: Marcin Slusarz <marcin.slusarz@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
The core/mem/shader clocks don't support the fractional feedback divider,
causing our calculated clocks to be off by quite a lot in some cases. To
solve this we will switch to a search-based algorithm when fN is NULL.
For my NVA8 at PL3, this actually generates identical cooefficients to
the binary driver. Hopefully that's a good sign, and that does not
break VPLL calculation for someone..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Hopefully this is how we're supposed to correctly handle when the RAMCFG
strap is above the number of entries in timing-related tables.
It's rather difficult to confirm without finding a configuration where
the ram restrict table doesn't map 8-15 back onto 0-7 anyway. There's
not a single vbios in the repo which is configured differently..
In any case, this is probably still better than potentially reading
outside of the bounds of various tables..
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
We need to parse some of these other entries still, but I've yet to
determine exactly which PLLs the rest map to.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Really not necessary here, we want to be able to see if/how we managed to
match a timingset to a performance level, even if we can't currently
program it.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
v2 (Ben Skeggs): fix ramcfg strap, and remove bogus handling of perf 0x40
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Again, doesn't quite match NVIDIA's, but not sure it really matters. This
will however, match the same rules we use to calculate the other related
grctx magics.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
After looking at a number of different logs, it appears 0x41 likely
indicates the presense of an LVDS panel following the SPWG spec
(http://www.spwg.org/)
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
NV40 and older cards (pre NV50) reserve a vram bo for the vga memory at
card init. This bo is then freed at card shutdown. The problem is that
the ttm bo vram manager was already freed. So a crash occurs when the
vga bo is freed. The fix is to free the vga bo prior to freeing the ttm
bo vram manager. There might be other solutions but this seemed the
simplest to me.
Signed-off-by: Jimmy Rentz <jb17bsome@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Definitely not 100% correct, but, for the configurations I've seen used
it'll read back the correct clocks now.
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Many of the nv50 cards have their shader and/or memory pll
disabled at some stage.
This patch addresses those cases, so that the function
returns the correct frequency.
When the shader pll is disabled, the blob reports 2*core clock
Whereas for memory, the data stored in the vbios. This action
is incorrect as some vbioses store a clock value that is less
than the refference clock of the pll.
Thus we are reporting the reff_clk as it is the frequency the
pll actually operates
v2 - Convert NV_INFO() messages to NV_DEBUG()
Provide more information in the actuall message
Signed-off-by: Emil Velikov <emil.l.velikov@gmail.com>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Martin Peres <martin.peres@ensi-bourges.fr>
Reported-by: Stratos Psomadakis <psomas@ece.ntua.gr>
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
