The code was unmodified compared to Linux and returned the amount of
received bytes from the i2c bus. This led to non-working i2c bus and
failure to eg. read monitor's EDID, if connected to DisplayPort.
MFC after: 3 days
Tested by: Mikaël Urankar <mikael.urankar@gmail.com>
This fixes radeon_agp_init() and gtt_size is now correct. However, this
is not enough to make Radeon AGP cards work: ttm_agp_backend.c isn't
implemented yet.
Submitted by: tijl@
The directory sys/dev/drm2/i915 is apperently contributed code.
Revert to the broken version of this file to make future imports easier.
Requested by: kib
shifts into the sign bit. Instead use (1U << 31) which gets the
expected result.
This fix is not ideal as it assumes a 32 bit int, but does fix the issue
for most cases.
A similar change was made in OpenBSD.
Discussed with: -arch, rdivacky
Reviewed by: cperciva
The code was easier to read without __DECONST and clang didn't report
any error. I thought the cast was enough...
MFC after: 3 days
X-MFC-With: r258549
drm_le_cmp() (qsort_r()'s callback) receives pointers to elements in the
array passed to qsort_r(), not the elements themselves.
Before this fix, the use of qsort_r() shuffled the array, not sorted it,
because the compare callback accessed random memory locations, not the
expected elements.
This bug triggered an infinite loop in KDE/xserver:
1. KDE has a kded module called "randrmonitor" which queries xserver
for current monitors at startup and then listens to RandR
notifications from xserver.
2. xserver handles the query from "randrmonitor" by polling the
video device using the "drm_mode_getconnector()" ioctl. This
ioctl returns a list of connectors and, for those with a
connected monitor, the available modes. Each modes list is sorted
by the kernel before returning. When xserver gets the connectors
list, it sorts the modes lists again.
In the case of this bug, when two modes are equal (in xserver's
compare function PoV), their order is kept stable (ie. the
kernel order is kept for those two modes). And because the list
was shuffled by the kernel, the order of two equal modes was
frequently changed in the final modes list in xserver.
3. xserver compares the returned connectors list with the list
obtained earlier. In particular, it compares the sorted
modes lists for each connector. If a property of a connector
changes (eg. modes), xserver sends a "RRNotify_OutputChange"
notification.
Because of the change of order between equal modes, xserver sent
a notification after each polling of the connectors.
4. "randrmonitor" receives a notification, triggered by its query. The
notification doesn't contain the new connectors list, therefore, it
asks for the new list using the same function: go back to step #2.
MFC after: 3 days
This fixes DPMS with KDE and radeonkms. Without this, the display would
freeze when the monitor is put into sleep state, and only resumes after
several dozens of minutes once the monitor is powered on again.
Tested by: Mathias Picker <Mathias.Picker@virtual-earth.de>
already. Also, according to the specs, GDRST register is not in the
power well, so the forcewake for reset status read is excessive for
this reason.
Use plain register read for waiting of the reset completion
notification, to avoid gt_lock recursion. Linux upstream did the
similar change, but their code was already restructured.
Reported by: ray
Sponsored by: The FreeBSD Foundation
MFC after: 1 week
Calling those functions with the drmn device as argument causes a panic,
because it's not a direct child of pci$N. They must be called with the
vgapci device instead.
This fix is not enough to make suspend/resume work reliably.
Approved by: re (blanket)
vga_pci_(un)map_bios() takes a vgapci device as argument, not a drmn
one. This fixes a bug where the BIOS couldn't be mapped if the device
wasn't the boot display.
Approved by: re (kib; blanket for following drm2/radeon commits)
an address in the first 2GB of the process's address space. This flag should
have the same semantics as the same flag on Linux.
To facilitate this, add a new parameter to vm_map_find() that specifies an
optional maximum virtual address. While here, fix several callers of
vm_map_find() to use a VMFS_* constant for the findspace argument instead of
TRUE and FALSE.
Reviewed by: alc
Approved by: re (kib)
- Relax atomic_read() and atomic_set() macros. Linux does not require any
memory barrier. Also, these macros may be even reordered or optimized away
according to the API documentation:
https://www.kernel.org/doc/Documentation/atomic_ops.txt
This driver is based on Linux 3.8 and a previous effort by kan@.
More informations about this project can be found on the FreeBSD wiki:
https://wiki.freebsd.org/AMD_GPU
The driver is split into:
sys/dev/drm2:
The driver sources.
sys/modules/drm2/radeonkmw:
The driver main kernel module's Makefile.
sys/modules/drm2/radeonkmsfw:
All firmware kernel module Makefiles. There's one directory and one
Makefile for each firmware.
sys/contrib/dev/drm2/radeonkmsfw:
All firmware binary sources.
tools/tools/drm/radeon
Tools to update firmwares or regenerate some headers.
Merging the driver to FreeBSD 9.x may be possible but not a priority for
now.
Help from: kib@, kan@
Tested by: avg@, kwm@, ray@,
Alexander Yerenkow <yerenkow@gmail.com>,
Anders Bolt-Evensen <andersbo87@me.com>,
Denis Djubajlo <stdedjub@googlemail.com>,
J.R. Oldroyd <fbsd@opal.com>,
Mikaël Urankar <mikael.urankar@gmail.com>,
Pierre-Emmanuel Pédron <pepcitron@gmail.com>,
Sam Fourman Jr. <sfourman@gmail.com>,
Wade <wade-is-great@live.com>,
(probably other I forgot...)
HW donations: kyzh, Yakaz
Add a new ttm_bo_release_mmap() function to unmap pages in a
vm_object_t. Pages are freed when the buffer object is later released.
This function is called in ttm_bo_unmap_virtual_locked(), replacing
Linux' unmap_mapping_range(). In particular this is called when a buffer
object is about to be moved, so that its mapping is invalidated.
However, we don't use this function in ttm_bo_vm_dtor(), because the
vm_object_t is already marked as OBJ_DEAD and the pages will be
unmapped.
Approved by: kib@
This fixes a crash where a SIGLALRM, heavily used by X.Org, would
interrupt the wait, causing the page fault to fail and the "Xorg"
process to receive a SIGSEGV.
Approved by: kib@
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Mon Jan 14 15:08:14 2013 +0100
drm/ttm: fix fence locking in ttm_buffer_object_transfer, 2nd try
This fixes up
commit e8e89622ed361c46bf90ba4828e685a8b603f7e5
Author: Daniel Vetter <daniel.vetter@ffwll.ch>
Date: Tue Dec 18 22:25:11 2012 +0100
drm/ttm: fix fence locking in ttm_buffer_object_transfer
which leaves behind a might_sleep in atomic context, since the
fence_lock spinlock is held over a kmalloc(GFP_KERNEL) call. The fix
is to revert the above commit and only take the lock where we need it,
around the call to ->sync_obj_ref.
v2: Fixup things noticed by Maarten Lankhorst:
- Brown paper bag locking bug.
- No need for kzalloc if we clear the entire thing on the next line.
- check for bo->sync_obj (totally unlikely race, but still someone
else could have snuck in) and clear fbo->sync_obj if it's cleared
already.
Reported-by: Dave Airlie <airlied@gmail.com>
Cc: Jerome Glisse <jglisse@redhat.com>
Cc: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Approved by: kib@
Author: Dave Airlie <airlied@gmail.com>
Date: Wed Jan 16 15:58:34 2013 +1000
ttm: on move memory failure don't leave a node dangling
if we have a move notify callback, when moving fails, we call move notify
the opposite way around, however this ends up with *mem containing the mm_node
from the bo, which means we double free it. This is a follow on to the previous
fix.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Approved by: kib@
Author: Dave Airlie <airlied@gmail.com>
Date: Wed Jan 16 14:25:44 2013 +1000
ttm: don't destroy old mm_node on memcpy failure
When we are using memcpy to move objects around, and we fail to memcpy
due to lack of memory to populate or failure to finish the copy, we don't
want to destroy the mm_node that has been copied into old_copy.
While working on a new kms driver that uses memcpy, if I overallocated bo's
up to the memory limits, and eviction failed, then machine would oops soon
after due to having an active bo with an already freed drm_mm embedded in it,
freeing it a second time didn't end well.
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Approved by: kib@
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jan 15 14:57:28 2013 +0100
drm/ttm: unexport ttm_bo_wait_unreserved
All legitimate users of this function outside ttm_bo.c are gone, now
it's only an implementation detail.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Approved by: kib@
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jan 15 14:57:10 2013 +0100
drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers, v2
This requires re-use of the seqno, which increases fairness slightly.
Instead of spinning with a new seqno every time we keep the current one,
but still drop all other reservations we hold. Only when we succeed,
we try to get back our other reservations again.
This should increase fairness slightly as well.
Changes since v1:
- Increase val_seq before calling ttm_bo_reserve_slowpath_nolru and
retrying to take all entries to prevent a race.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Approved by: kib@
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jan 15 14:57:05 2013 +0100
drm/ttm: add ttm_bo_reserve_slowpath
Instead of dropping everything, waiting for the bo to be unreserved
and trying over, a better strategy would be to do a blocking wait.
This can be mapped a lot better to a mutex_lock-like call.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Approved by: kib@
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jan 15 14:56:48 2013 +0100
drm/ttm: cleanup ttm_eu_reserve_buffers handling
With the lru lock no longer required for protecting reservations we
can just do a ttm_bo_reserve_nolru on -EBUSY, and handle all errors
in a single path.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Author: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Date: Tue Jan 15 14:56:37 2013 +0100
drm/ttm: remove lru_lock around ttm_bo_reserve
There should no longer be assumptions that reserve will always succeed
with the lru lock held, so we can safely break the whole atomic
reserve/lru thing. As a bonus this fixes most lockdep annotations for
reservations.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@canonical.com>
Reviewed-by: Jerome Glisse <jglisse@redhat.com>
Some of the FreeBSD-specific definitions are moved to drm_os_freebsd.h.
But there's still work to do to clean it up and reduce the diff with
Linux' drmP.h.
