summaryrefslogtreecommitdiffstats
path: root/sys/dev/drm2
Commit message (Collapse)AuthorAgeFilesLines
* MFC r307218:kib2016-10-202-3/+3
| | | | Fix a race in vm_page_busy_sleep(9).
* MFC r305344:dim2016-09-071-2/+10
| | | | | | | | Define drmP.h's __OS_HAS_AGP and __OS_HAS_MTRR macros in a defined and portable way. Reviewed by: dumbbell Differential Revision: https://reviews.freebsd.org/D7770
* MFC r298931, r298981, r299375:pfg2016-05-172-2/+2
| | | | | | | Minor spelling fixes in: sys/dev, sys/sys Many of these have user-visible strings.
* MFC r298334:ngie2016-05-131-1/+3
| | | | | | | | | | r298334 (by cem): drm2(4): Fix double-free in low-memory error path Reallocf frees 'block'; don't attempt to free it again. CID: 1091165
* drm: Fix dev->ioctl_count references leakdumbbell2016-03-181-0/+4
| | | | | | | | | | This fixes the following error: kernel: error: [drm:pid1167:drm_release] *ERROR* Device busy: 2 Because of that, drm_lastclose() was not called, leading to a few memory leaks once the driver was unloaded. MFC of: r296674
* drm/i915: Restore pci_enable_busmaster() call in the init pathdumbbell2016-02-155-13/+7
| | | | | | | | | | | | | | This fixes a GPU hang on i945GM. While here, merge some minor fixes to DRM core and i915: * Remove obsolete drm_agp_*_memory() prototypes * Fix comment in drm_fops.c (outisde -> outside) * Fix some formatting issues in drm_stub.c (spaces -> tabs) Approved by: re (marius) MFC of: r288653, r288952, r293851 Submitted by: <s3erios@gmail.com> Differential Revision: https://reviews.freebsd.org/D3413
* MFC 292409:jhb2016-01-181-2/+1
| | | | | | | | | It seems certain Intel GPUs use GPIO bitbanging over a child device instead of GMBUS access for I2C transfers. The GMBUS driver falls back to this mode when a transfer times out. However, the first transfer to timeout was sending the request back to itself resulting in an panic due to recursing on a lock. Fix it to forward the request on to the proper device. This appears to have been accidentally changed in r277487.
* drm/i915: Remove "Attempting to unbind pinned buffer" messagedumbbell2016-01-131-3/+1
| | | | | | | | This error message is removed in later versions of Linux and currently, it spams users. PR: 200712 MFC of: r289109
* MFC 288452,289719:jhb2015-11-061-12/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 288452: Most error cases in i915_gem_do_execbuffer() jump to one of two labels to release resources (such as unholding pages) when errors occur. Some recently added error checks return immediately instead of jumping to a label resulting in leaks. Fix these to jump to a label to do cleanup instead. Note that stable/9 does not have the "recently added" error checks, but it does have some older error checks (that were are no longer present in stable/10 and head) that have the same bug and this fixes those instead. 289719: i915_gem_do_execbuffer() holds the pages backing each relocation region for various reasons while executing user commands. After these commands are completed, the pages backing the relocation regions are unheld. Since relocation regions do not have to be page aligned, the code in validate_exec_list() allocates 2 extra page pointers in the array of held pages populated by vm_fault_quick_hold_pages(). However, the cleanup code that unheld the pages always assumed that only the buffer size / PAGE_SIZE pages were used. This meant that non-page aligned buffers would not unheld the last 1 or 2 pages in the list. Fix this by saving the number of held pages returned by vm_fault_quick_hold_pages() for each relocation region and using this count during cleanup.
* MFC r287673: radeon_suspend_kms: don't mess with pci stateavg2015-10-231-8/+0
|
* MFC r278153,284416: ttm memory allocation improvementsavg2015-07-012-21/+74
| | | | | | | | | | | | | | | | | If the vm_page_alloc_contig() failed in the ttm page allocators, do what other callers of vm_page_alloc_contig() do, retry after vm_pageout_grow_cache(). ttm_vm_page_alloc: use vm_page_alloc for pages without dma32 restriction This change re-organizes code a little bit to extract common pieces of ttm_alloc_new_pages() and ttm_get_pages() into dedicated functions. Also, for requests without address restrictions regular vm_page_alloc() is used. Lastly, when vm_page_alloc_contig() fails we call VM_WAIT before calling vm_pageout_grow_cache() to ensure that there is enough free pages at all. Note: no MFC to stable/9 because it lacks vm_pageout_grow_cache().
* drm: Update the device-independent code to match Linux 3.8.13dumbbell2015-04-28154-8488/+10617
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This update brings few features: o Support for the setmaster/dropmaster ioctls. For instance, they are used to run multiple X servers simultaneously. o Support for minor devices. The only user-visible change is a new entry in /dev/dri but it is useless at the moment. This is a first step to support render nodes [1]. The main benefit is to greatly reduce the diff with Linux (at the expense of an unreadable commit diff). Hopefully, next upgrades will be easier. No updates were made to the drivers, beside adapting them to API changes. [1] https://en.wikipedia.org/wiki/Direct_Rendering_Manager#Render_nodes r280814 is merged at the same time to avoid a short window where RANDR might be broken: drm: Import Linux commit 9bc3cd5673d84d29272fa7181a4dfca83cbb48c1 Author: Ville Syrjälä <ville.syrjala@linux.intel.com> Date: Fri May 31 12:17:08 2013 +0000 drm: Sort connector modes based on vrefresh Keeping the modes sorted by vrefresh before the pixel clock makes the mode list somehow more pleasing to the eye. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Dave Airlie <airlied@redhat.com> PR: 198936 (r280814) Tested by: Many people MFC of: r280183, r280187 (original commit by glebius), r280814 Relnotes: yes
* DRM2: fix off-by-one overflow in ioctl processingdumbbell2015-04-281-1/+1
| | | | | | | | | | Call to the driver-specific ioctl used to process ioctl number that will lead to the out-of-bounds access to the ioctl handler array. PR: 193367 Approved by: kib MFC of: r275209 (original commit by rea)
* drm: Import Linux commit b7ea85a4fed37835eec78a7be3039c8dc22b8178dumbbell2015-04-281-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Author: Huacai Chen <chenhc@lemote.com> Date: Tue May 21 06:23:43 2013 +0000 drm: fix a use-after-free when GPU acceleration disabled When GPU acceleration is disabled, drm_vblank_cleanup() will free the vblank-related data, such as vblank_refcount, vblank_inmodeset, etc. But we found that drm_vblank_post_modeset() may be called after the cleanup, which use vblank_refcount and vblank_inmodeset. And this will cause a kernel panic. Fix this by return immediately if dev->num_crtcs is zero. This is the same thing that drm_vblank_pre_modeset() does. Call trace of a drm_vblank_post_modeset() after drm_vblank_cleanup(): [ 62.628906] [<ffffffff804868d0>] drm_vblank_post_modeset+0x34/0xb4 [ 62.628906] [<ffffffff804c7008>] atombios_crtc_dpms+0xb4/0x174 [ 62.628906] [<ffffffff804c70e0>] atombios_crtc_commit+0x18/0x38 [ 62.628906] [<ffffffff8047f038>] drm_crtc_helper_set_mode+0x304/0x3cc [ 62.628906] [<ffffffff8047f92c>] drm_crtc_helper_set_config+0x6d8/0x988 [ 62.628906] [<ffffffff8047dd40>] drm_fb_helper_set_par+0x94/0x104 [ 62.628906] [<ffffffff80439d14>] fbcon_init+0x424/0x57c [ 62.628906] [<ffffffff8046a638>] visual_init+0xb8/0x118 [ 62.628906] [<ffffffff8046b9f8>] take_over_console+0x238/0x384 [ 62.628906] [<ffffffff80436df8>] fbcon_takeover+0x7c/0xdc [ 62.628906] [<ffffffff8024fa20>] notifier_call_chain+0x44/0x94 [ 62.628906] [<ffffffff8024fcbc>] __blocking_notifier_call_chain+0x48/0x68 [ 62.628906] [<ffffffff8042d990>] register_framebuffer+0x228/0x260 [ 62.628906] [<ffffffff8047e010>] drm_fb_helper_single_fb_probe+0x260/0x314 [ 62.628906] [<ffffffff8047e2c4>] drm_fb_helper_initial_config+0x200/0x234 [ 62.628906] [<ffffffff804e5560>] radeon_fbdev_init+0xd4/0xf4 [ 62.628906] [<ffffffff804e0e08>] radeon_modeset_init+0x9bc/0xa18 [ 62.628906] [<ffffffff804bfc14>] radeon_driver_load_kms+0xdc/0x12c [ 62.628906] [<ffffffff8048b548>] drm_get_pci_dev+0x148/0x238 [ 62.628906] [<ffffffff80423564>] local_pci_probe+0x5c/0xd0 [ 62.628906] [<ffffffff80241ac4>] work_for_cpu_fn+0x1c/0x30 [ 62.628906] [<ffffffff802427c8>] process_one_work+0x274/0x3bc [ 62.628906] [<ffffffff80242934>] process_scheduled_works+0x24/0x44 [ 62.628906] [<ffffffff8024515c>] worker_thread+0x31c/0x3f4 [ 62.628906] [<ffffffff802497a8>] kthread+0x88/0x90 [ 62.628906] [<ffffffff80206794>] kernel_thread_helper+0x10/0x18 Signed-off-by: Huacai Chen <chenhc@lemote.com> Signed-off-by: Binbin Zhou <zhoubb@lemote.com> Cc: <stable@vger.kernel.org> Reviewed-by: Michel Dänzer <michel.daenzer@amd.com> Acked-by: Paul Menzel <paulepanter@users.sourceforge.net> Signed-off-by: Dave Airlie <airlied@gmail.com> Reported by: J.R. Oldroyd <fbsd@opal.com> MFC of: r279599
* MFC r277487:kib2015-03-2353-7106/+12366
| | | | | | | | | | | | | | | | | | | | | | An update for the i915 GPU driver, which brings the code up to Linux commit 4d93914ae3db4a897ead4b. MFC r277959 (by adrian): Fix backlight for ivybridge based laptops (and whatever else comes through this codepath.) MFC r278146: Do not attach to the unsupported chipsets, unless magic tunable is frobbed. MFC r278147, r278148: Fix sign for the error code returned from the driver-specific code. MFC r278152: Do not access gmbus_ports array past its end. MFC r278159 (by emaste): Remove duplicate intel_fbc_enabled prototype.
* MFC r279919: Using parent DMA tag in drm_pci_alloc(). This can allowjah2015-03-221-1/+3
| | | | | | | drm2 devices to work with Intel DMAR enabled for the system, as long as DMAR is disabled for the drm2 device. Reviewed by: kib (mentor)
* MFC 270516:jhb2015-03-133-31/+82
| | | | | | | | | | | | | | | i915 driver - enable opregion handle; program CADL. add opregion handling for drm2 - which exposes some ACPI video configuration pieces that some Lenovo laptop models use to flesh out which video device to speak to. This enables the brightness control in ACPI to work these models. The CADL bits are also important - it's used to figure out which ACPI events to hook the brightness buttons into. It doesn't yet seem to work for me, but it does for the OP. PR: 190186, 198551 Submitted by: Henry Hu <henry.hu.sh@gmail.com>
* MFC r278004:dim2015-02-122-9/+9
| | | | | | | | | | | | | | | | | | | | Constify a number of accesses in drm2's radeon drivers to avoid -Wcast-qual warnings. No functional change. Reviewed by: dumbbell Differential Revision: https://reviews.freebsd.org/D1727 MFC r278438: After r278004 was committed, Bruce Evans noted that the casts were actually completely unnecessary, here: https://lists.freebsd.org/pipermail/svn-src-all/2015-February/098478.html Remove the casts, and just assign &xxx_io_mc_regs[0][0] directly. Reviewed by: dumbbell Differential Revision: https://reviews.freebsd.org/D1748
* MFC r269634:tijl2014-12-022-4/+10
| | | | | | | | | | | | | | drm: fix usage of vm_phys_fictitious_to_vm_page vm_phys_fictitious_to_vm_page should not be called directly, even when operating on a range that has been registered using vm_phys_fictitious_reg_range. PHYS_TO_VM_PAGE should be used instead because on arches that use VM_PHYSSEG_DENSE the page might come directly from vm_page_array. Reported by: nwhitehorn Tested by: nwhitehorn, David Mackay <davidm.jx8p@gmail.com> Sponsored by: Citrix Systems R&D
* MFC r273969:tijl2014-12-021-2/+1
| | | | Use default memory type for TTM buffer objects that may be cached.
* MFC r273862,273902:tijl2014-12-027-60/+55
| | | | | | | | | | | | | | | Port the TTM AGP backend to the FreeBSD agp driver and enable AGP support in the radeonkms driver. Note: In PCI mode virtual addresses on the graphics card that map to system RAM are translated to physical addresses by the graphics card itself. In AGP mode address translation is done by the AGP chipset so fictitious addresses appear on the system bus. For the CPU cache management to work correctly when the CPU accesses this memory it needs to use the same fictitious addresses (and let the chipset translate them) instead of using the physical addresses directly. Reviewed by: kib
* drm: Take vt(4) default mode from loader tunablesdumbbell2014-11-222-182/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default, vt(4) gets the "preferred mode" from DRM, when using a DRM video driver as its backend. The preferred mode is usually the native screen resolution. Now, if this mode isn't appropriate, a user can use loader tunables to select a mode. The tunables are read in the following order: 1. kern.vt.fb.modes.$connector_name 2. kern.vt.fb.default_mode For example, to set a 1024x768 mode, no matter the connector: kern.vt.fb.default_mode="1024x768" To set a 800x600 mode only on the laptop builtin screen: kern.vt.fb.modes.LVDS-1="800x600" Beside r274031, this MFC includes: r274049: drm: When reading connector mode tunables, list connectors ... and their associated tunables. This gives a way to know the list of available connectors, no matter the driver. The problem is that xrandr(1) can list connectors but it uses a different naming. r274050: vt(4): Document kern.vt.fb.default_mode and kern.vt.fb.modes.* Those tunables are used to set a specific mode in vt(4) instead of using the default mode. Differential Revision: https://reviews.freebsd.org/D1098 Reviewed by: ak@, emaste@, kwm@ r274051: vt(4): Improve the description of kern.vt.fb.modes.$connector Differential Revision: https://reviews.freebsd.org/D1098 Submitted by: emaste@ r274053: vt(4): Start new sentences on their own lines Submitted by: brueffer@ MFC of: r274031, r274049, r274050, r274051, r274053
* drm: Lower priority of three messages related to invalid EDIDdumbbell2014-11-222-4/+4
| | | | | | | | | Like in r259717, the prority goes from "error" to "debug" to avoid spamming logs when the connectors are polled. PR: 194770 Submitted by: Larry Rosenman <ler@lerctr.org> MFC of: r273962, r274587
* MFC r272761:kib2014-10-151-2/+2
| | | | | | | | | Add an argument to the x86 pmap_invalidate_cache_range() to request forced invalidation of the cache range regardless of the presence of self-snoop feature. MFC r272943: MFi386 r272761.
* MFC r268981ray2014-09-251-31/+0
| | | | | | | | | Remove #ifdef-s to reduce difference to upstream. Pointed by: kib Approved by: re (glebius) Sponsored by: The FreeBSD Foundation
* drm/i915: Add HW context supportdumbbell2014-09-1814-29/+761
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This feature is required by Mesa 9.2+. Without this, a GL application crashes with the following message: # glxinfo name of display: :0.0 Gen6+ requires Kernel 3.6 or later. Assertion failed: (ctx->Version > 0), function handle_first_current, file ../../src/mesa/main/context.c, line 1498. Abort (core dumped) Now, Mesa 10.2.4 and 10.3-rc3 works fine: # glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes ... OpenGL renderer string: Mesa DRI Intel(R) 965GM OpenGL version string: 2.1 Mesa 10.2.4 ... The code was imported from Linux 3.8.13. This an MFC of r271705. Approved by: re (glebius) Reviewed by: kib@ Tested by: kwm@, danfe@, Henry Hu, Lundberg, Johannes <johannes@brilliantservice.co.jp>, Johannes Dieterich <dieterich.joh@gmail.com>, Lutz Bichler <lutz.bichler@gmail.com>, Relnotes: yes
* vt(4): Merge several bug fixes and improvementsdumbbell2014-09-181-1/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | SVN revisions in this MFC: 269779 270705 270706 271180 271250 271253 271682 271684 Detailed commit list: r269779: fbd: Fix a bug where vt_fb_attach() success would be considered a failure vt_fb_attach() currently always returns 0, but it could return a code defined in errno.h. However, it doesn't return a CN_* code. So checking its return value against CN_DEAD (which is 0) is incorrect, and in this case, a success becomes a failure. The consequence was unimportant, because the caller (drm_fb_helper.c) would only log an error message in this case. The console would still work. Approved by: nwhitehorn r270705: vt(4): Add cngrab() and cnungrab() callbacks They are used when a panic occurs or when entering a DDB session for instance. cngrab() forces a vt-switch to the console window, no matter if the original window is another terminal or an X session. However, cnungrab() doesn't vt-switch back to the original window currently. r270706: drm: Don't "taskqueue" vt-switch if under DDB/panic situation If DDB is active, we can't use a taskqueue thread to switch away from the X window, because this thread can't run. Reviewed by: ray@ Approved by: ray@ r271180: vt_vga: vd_setpixel_t and vd_drawrect_t are noop in text mode r271250: vt(4): Change the terminal and buffer sizes, even without a font This fixes a bug where scroll lock would not work for tty #0 when using vt_vga's textmode. The reason was that this window is created with a static 256x100 buffer, larger than the real size of 80x25. Now, in vt_change_font() and vt_compute_drawable_area(), we still perform operations even of the window has no font loaded (this is the case in textmode here vw->vw_font == NULL). One of these operation resizes the buffer accordingly. In vt_compute_drawable_area(), we take the terminal size as is (ie. 80x25) for the drawable area. The font argument to vt_set_border() is removed (it was never used) and the code now uses the computed drawable area instead of re-doing its own calculation. Reported by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de> Tested by: Harald Schmalzbauer <h.schmalzbauer_omnilan.de> r271253: pause_sbt(): Take the cold path (ie. use DELAY()) if KDB is active This fixes a panic in the i915 driver when one uses debug.kdb.enter=1 under vt(4). PR: 193269 Reported by: emaste@ Submitted by: avg@ r271682: vt(4): Fix a LOR which occurs during a call to vt_upgrade() Reported by: kib@ Review: https://reviews.freebsd.org/D785 Reviewed by: ray@ Approved by: ray@ r271684: vt(4): Use vt_fb_drawrect() and vt_fb_setpixel() in all vt_fb-derivative Review: https://reviews.freebsd.org/D789 Reviewed by: nwhitehorn Approved by: nwhitehorn Approved by: re (gjb)
* drm/radeon: Fix a memory leak when radeonkms is unloadeddumbbell2014-09-041-0/+1
| | | | This an MFC of r270750.
* MFC r268954sbruno2014-08-102-22/+5
| | | | | | | | Merge change from upstream linux kernel submitted by OpenBSD: drm/radeon: fix-up some float to fixed conversion thinkos Remove #ifdef DUMBBELL_WIP in favor of upstream fix.
* MFC r268947: Hide syscons-specific workaround under DEV_SCemaste2014-07-241-0/+5
|
* MFC: r266792marius2014-06-041-2/+2
| | | | | | | | | | | | | | | | | | | Fix DMA handling in radeon_dummy_page_init(): - Based on actual usage and on what Linux does, dummy_page.addr should contain the physical bus address of the dummy page rather than its virtual one. As a side-effect, correcting this bug fixes compilation with PAE support enabled by getting rid of an inappropriate cast. - Also based on actual usage of dummy_page.addr, theoretically Radeon devices could do a maximum of 44-bit DMA. In reality, though, it is more likely that they only support 32-bit DMA, at least that is what radeon_gart_table_ram_alloc() sets up for, too. However, passing ~0 to drm_pci_alloc() as maxaddr parameter translates to 64-bit DMA on amd64/64-bit machines. Thus, use BUS_SPACE_MAXSIZE_32BIT instead, which the existing 32-bit DMA limits within the drm2 code spelled as 0xFFFFFFFF should also be changed to. Reviewed by: dumbbell Sponsored by: Bally Wulff Games & Entertainment GmbH
* drm/radeon: Add 32bit ioctls supportdumbbell2014-05-232-259/+166
| | | | | | | This allows to run 32bit applications on a 64bit host. This was tested successfully with Wine (emulators/i386-wine-devel) and StarCraft II. Submitted by: Jan Kokemüller <jan.kokemueller@gmail.com>
* MFC r265102:kib2014-05-061-1/+1
| | | | | Fix two cases of recursive acquisitions of the vm object lock, only possible in rare failure situations.
* MFC 259016,259019,259049,259071,259102,259110,259129,259130,259178,259179,jhb2014-03-069-83/+164
| | | | | | | | | 259203,259221,259261,259532,259615,259650,259651,259667,259680,259727, 259761,259772,259776,259777,259830,259882,259915,260160,260449,260450, 260688,260888,260953,261269,261547,261551,261552,261553,261585: Merge the vt(4) driver (newcons) to stable/10. Approved by: ray
* MFC r261497:rmh2014-02-122-0/+12
| | | | | | | Abort when firmware isn't present in R600+ models. More details at: http://anonscm.debian.org/viewvc/kernel/dists/trunk/linux/debian/patches/bugfix/all/radeon-firmware-is-required-for-drm-and-kms-on-r600-onward.patch?revision=20909&view=co
* MFC r258779,r258780,r258787,r258822:eadler2014-02-0419-125/+125
| | | | | | | | | | | | | Fix undefined behavior: (1 << 31) is not defined as 1 is an int and this shifts into the sign bit. Instead use (1U << 31) which gets the expected result. Similar to the (1 << 31) case it is not defined to do (2 << 30). 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.
* MFC r259612: ttm_bo_vm_lookup_rb: actually make use of the red-black treeavg2014-01-161-2/+5
|
* MFC r259717:dumbbell2013-12-221-1/+1
| | | | | | | | | | | | | | | | drm: Lower priority of "EDID checksum is invalid" message The priority goes from "error" to "debug". Connectors are polled every 10 seconds. Reading EDID is part of this polling. However, when an invalid EDID is returned, this error message is logged. When using Newcons for instance, having a kernel message every 10 seconds is getting annoying. Now that it's a debug message, it'll be logged only if hw.dri.debug is enabled. This fix console spamming for some users. Tested by: Larry Rosenman <ler@lerctr.org>
* MFC r259684:dumbbell2013-12-224-2/+18
| | | | | | | | | | | | | | | | | drm/ttm, drm/radeon: Replace EINTR/ERESTART by ERESTARTSYS... ... for msleep/cv_*wait() return values, where wait_event*() is used on Linux. ERESTARTSYS is the return code expected by callers when the operation was interrupted. For instance, this is the case of radeon_cs_ioctl() (radeon_cs.c): if an error occurs, and the code isn't ERESTARTSYS (eg. EINTR), it logs an error. Note that ERESTARTSYS is defined as ERESTART, but this keeps callers' code close to Linux. Submitted by: avg@ (previous version)
* MFC r259003:rmh2013-12-131-0/+7
| | | | Initialize modesetting sysctls in radeonkms.
* MFC r258930:dumbbell2013-12-111-1/+5
| | | | | | drm: Read PCIER_LINK_CAP/PCIER_LINK_CAP2 from the PCI bridge Before this fix, capabilities were read from vgapci and were incorrect.
* MFC r259104:dumbbell2013-12-111-1/+1
| | | | | | | | | | drm/radeon: radeon_dp_i2c_aux_ch() must return 0 on FreeBSD 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. Tested by: Mikaël Urankar <mikael.urankar@gmail.com>
* MFC r259101:dumbbell2013-12-111-3/+3
| | | | | | | | | | drm/radeon: agp_info->ai_aperture_size is in bytes, not Mbytes 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@
* MFC r258549 and r258553:dumbbell2013-11-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | drm: Dereference pointers given to qsort_r()'s cmp callback 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. Approved by: re (kib)
* MFC r258262:dumbbell2013-11-284-0/+12
| | | | | | | | | | | drm: Support DRM_CAP_TIMESTAMP_MONOTONIC capability 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> Approved by: re (kib)
* MFC r257870:dumbbell2013-11-121-3/+1
| | | | | | | | | drm/radeon: Wake up userland after page flip For instance, this caused issues in KDE, such as stuttered animations (with desktop effects enabled). Approved by: re (kib)
* MFC r257869:dumbbell2013-11-122-0/+2
| | | | | | | | | drm: Initialize "handle" to 0 before calling drm_gem_handle_create() This is variable is being checked in drm_gem_name_create() before being set. Approved by: re (delphij)
* MFC r256771:dumbbell2013-10-291-0/+1
| | | | | | | drm/radeon: radeonkms depends on firmware(9) Submitted by: tijl@ Approved by: re (kib)
* MFC r256848:kib2013-10-291-1/+1
| | | | | | | Use plain register read for waiting of the reset completion notification, to avoid gt_lock recursion. Approved by: re (glebius)
* drm/radeon: Add missing "return false" after unmapping invalid BIOSdumbbell2013-09-151-0/+1
| | | | | | | Without that, we would try to copy the unmapped BIOS. Submitted by: Christoph Mallon <christoph.mallon@gmx.de> Approved by: re (blanket)
OpenPOWER on IntegriCloud