Kconfig says fbcon is required by drm_kms_helper.  If radeon, fbcon,
and drm_kms_helper are all modules, radeon is auto loaded (by PCI id?),
drm_kms_helper is loaded because of the module dependency, but fbcon
isn't loaded leaving the console unusable.  Since fbcon is required
and there isn't an explicit module dependency, request the module
to be loaded from drm_kms_helper.
Signed-off-by: NDavid Fries <david@fries.net>
Cc: David Airlie <airlied@linux.ie>
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: NDave Airlie <airlied@redhat.com>

Readability cleanup and fix debugging output, no
functional change.
Reported-by: NFrank Huang <FrankR.Huang@amd.com>
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Works more like DCE4.0 despite what the docs say.
This fixes blank screen issues when changing crtc
routing due to incorrect crtc to dig mapping.

v2: only two DIGx blocks, routing is hardcoded
based on link.
Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

add to the 2.8 bump for pageflip

The purpose of these regs is to work around a TX hw bug in R520.
Signed-off-by: NMarek Olšák <maraeo@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

In drivers/gpu/drm/radeon/r100d.h R_0003C2_GENMO_WT is defined as 0x3C0.
I think this should be 0x3C2.
Signed-off-by: NDave Airlie <airlied@redhat.com>

For the fbdev api if the struct fb_var_screeninfo accel_flags field is set
to FB_ACCELF_TEXT then userland applications can not mmap the mmio region.
Since it is a bad idea for DRM drivers to expose the mmio region via the
fbdev layer we always set the accel_flags to prevent this. Please apply.
Signed-off-by: NJames Simmons <jsimmons@infradead.org>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

Signed-off-by: NAlex Deucher <alexdeucher@gmail.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

* 'nouveau/drm-nouveau-next' of ../drm-nouveau-next: (93 commits)
  drm/nv50: fix a couple of vm init issues
  drm/nv04-nv40: Fix up PCI(E) GART DMA object bus address calculation.
  drm/nouveau: kick vram functions out into an "engine"
  drm/nouveau: allow gpuobj vinst to be a virtual address when necessary
  drm/nv50: tidy up PCIEGART implementation
  drm/nv50: enable non-contig vram allocations where requested
  drm/nv50: enable 4KiB pages for small vram allocations
  drm/nv50: implement global channel address space on new VM code
  drm/nv50: implement BAR1/BAR3 management on top of new VM code
  drm/nv50: import new vm code
  drm/nv50: implement custom vram mm
  drm/nouveau: Avoid potential race between nouveau_fence_update() and context takedown.
  drm/nouveau: fix use of drm_mm_node in semaphore object
  drm/nouveau: wrap calls to ttm_bo_validate()
  drm/nouveau: no need to zero dma objects, we fill them completely anyway
  drm/nouveau: introduce a util function to wait on reg != val
  drm/nouveau: implicitly insert non-DMA objects into RAMHT
  drm/nouveau: make fifo.create_context() responsible for mapping control regs
  drm/nouveau: Spin for a bit in nouveau_fence_wait() before yielding the CPU.
  drm/nouveau: Use WC memory on the AGP GART.
  ...

Drivers using their own implementation of io_mem_reserve/io_mem_free are
likely to store the tracking information for the map in mem.mm_node, so
it can't be freed while still mapped.

Signed-off-by: Ben Skeggs<bskeggs@redhat.com>
Reviewed-by: NThomas Hellstrom <thellstrom@vmware.com>
Signed-off-by: NDave Airlie <airlied@redhat.com>

this adds a bo create, and fence seq tracking tracepoints.

This is just an initial set to play around with, we should investigate
what others we need would be useful.
Signed-off-by: NDave Airlie <airlied@redhat.com>

Fixes overwriting the first page table entry when testing that the PRAMIN
BAR can be correctly read/written, and adds an additional bar flush after
poking the BAR3 control regs.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

NVC0 will be able to share some of nv50's paths this way.  This also makes
it the card-specific vram code responsible for deciding if a given set
of tile_flags is valid, rather than duplicating the allowed types in
nv50_vram.c and nouveau_gem.c
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

As of this commit, it's guaranteed that if an object is in VRAM that its
GPU virtual address will be constant.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This is required on nv50 as we need to be able to have more precise control
over physical VRAM allocations to avoid buffer corruption when using
buffers of mixed memory types.

This removes some nasty overallocation/alignment that we were previously
using to "control" this problem.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

At some point in the future, this bo won't necessarily be backed by
a drm_mm_node, so use the start/size fields of the ttm_mem_reg instead.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

This will be used later to fixup bo.offset with a buffer's fixed GPU
virtual address.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

The regs belong to PFIFO, they're different for pretty much the same
generations we need different PFIFO control for, and NVC0 is going
to be even more different than the rest.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Sleeping doesn't pay off for very short delays in comparison with the
minimum granularity of schedule_timeout().
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

There have been reports of PFIFO cache errors during context take down
(fdo bug 31637). They are caused by some GPU objects being taken out
while the channel is still potentially processing commands. Make sure
that all the previous rendering has landed before releasing a GPU
object.
Reported-by: NGrzesiek Sójka <pld@pfu.pl>
Reported-by: NPatrice Mandin <patmandin@gmail.com>
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Acked-by: NBen Skeggs <bskeggs@redhat.com>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

nvxx_graph_isr is already taking care of it. In some cases this
could've made you miss PGRAPH interrupts (e.g. when you were supposed
to get several IRQs of the same kind in a row).
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

No functional changes, just simplify some code paths a bit.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

In typical Apple fashion there's no standard information about what
encoders are present on this machine, this patch adds a quirk to
provide it.
Signed-off-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Reviewed-by: NFrancisco Jerez <currojerez@riseup.net>
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

These have been unused since UMS support was ripped out, so lets remove
them completely.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Fix running of destroy_context() when create_context() has never been
called for the channel, and fill in engine's tlb_flush() function pointer.
Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>

Signed-off-by: NBen Skeggs <bskeggs@redhat.com>