[ANNOUNCE] libdrm 2.4.66
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 libdrm 2.4.66 release, mainly for new nouveau API. lots of other changes in here as well though. Ben Skeggs (14): nouveau: import and install a selection of nvif headers from the kernel nouveau: move more abi16-specific logic into abi16.c nouveau: move object functions up, to avoid future foward decls nouveau: make it possible to init object in pre-allocated memory nouveau: add interface to call an object's methods nouveau: add interfaces to query information about supported classes nouveau: introduce object to represent the kernel client nouveau: stack legacy nouveau_device on top of nouveau_drm nouveau: make use of nouveau_drm::fd instead of nouveau_device::fd nouveau: remove nouveau_object_find() nouveau: add new interface to create a nouveau_device nouveau: add support for newer kernel interfaces nouveau: clean up nouveau.h, noting deprecated members/functions Bump version for release Ben Widawsky (2): intel: Add SKL GT4 PCI IDs intel: Cleanup SKL PCI ID definitions. Chih-Wei Huang (1): intel: add the missing include Dave Airlie (1): drm: add virtgpu_drm.h Emil Velikov (17): automake: set --enable-valgrind during make distcheck xf86drmMode: smoke-test the atomic API tests/drmdevice: add new 'test' xf86drm: flex platform specifics into drmParsePciBusInfo xf86drm: move platform details to drmParsePciDeviceInfo() xf86drm: move the final linux specific bits out of drmGetDevices xf86drm: rename drmSameDevice to drmCompareBusInfo util_math: add MAX3 macro xf86drm: rework drmGetDevices() xf86drm: move ifdef __linux__ guards where needed xf86drm: warn on missing drmGetMinorNameForFD implementation xf86drm: split out drmProcessPciDevice and drmFoldDuplicatedDevices xf86drm: add drm{Get,Free}Device tests/drmdevice: add drm{Get,Free}Device() example Fix SunOS/NetBSD atomic macro xf86drm: remove makedev() hack/workaround configure.ac: test for the same atomic function as the one we use Felix Janda (1): xf86drm: include for PATH_MAX Jammy Zhou (1): amdgpu: fix overflow for timeout calculation Jonathan Gray (1): configure.ac: rework compiler builtin atomic tests Kristian Høgsberg Kristensen (3): intel: Update i915_drm.h Add tests/drmdevice to .gitignore intel: Add drm_intel_bo_set_softpin_offset to intel-symbol-check Matt Roper (3): xf86drm: Fix error handling for drmGetDevices() xf86drm: Fix error handling for drmGetDevice() xf86drm: Handle unrecognized subsystems safely in drmGetDevice[s]() MichaŠWiniarski (2): intel: Add support for softpin intel: Restore formatting of offsets in debug statements Michel Dänzer (2): Fix void pointer arithmetic in drmProcessPciDevice radeon: Handle surface offsets exceeding 32 bits correctly Michel Thierry (2): intel: 48b ppgtt support (EXEC_OBJECT_SUPPORTS_48B_ADDRESS flag) intel: add drm_intel_bo_use_48b_address_range to symbol-check test Rob Clark (3): freedreno: don't reuse exported buffers freedreno: drop exported dmabuf fd tracking freedreno: debug msg cleanup Stefan Agner (1): tests: remove missleading comments Thierry Reding (10): tests: Split helpers into library tests: Move name tables to libutil proptest: Add Android support tests: Add libkms-test library tests: kms: Implement CRTC stealing test tests: kms: Implement universal planes test tests: Add helper to open a device/module modetest: Use util_open() proptest: Use util_open() vbltest: Use util_open() Tobias Jakobi (18): exynos/fimg2d: fix empty buffer handling in g2d_flush() exynos/fimg2d: simplify base address submission in g2d_scale_and_blend() exynos/fimg2d: add g2d_check_space() exynos/fimg2d: add g2d_validate_xyz() functions exynos/fimg2d: remove default case from g2d_get_blend_op() exynos/fimg2d: remove superfluous initialization of g2d_point_val exynos/fimg2d: make g2d_add_cmd() less heavy exynos/fimg2d: add message prefix exynos/fimg2d: remove g2d_context from public header exynos: Introduce exynos_handle_event() tests/exynos: add fimg2d performance analysis exynos/fimg2d: add g2d_config_event tests/exynos: add fimg2d event test tests/exynos: use XRGB for framebuffer exynos: fimg2d: add g2d_set_direction exynos/fimg2d: add g2d_move tests/exynos: add test for g2d_move exynos: bump version number Tom St Denis (4): amdgpu: Unlock mutex if base_required is invalid amdgpu: Fix use-after-free bug in vamgr_deinit amdgpu: Cleanly handle ENOMEM on result in amdgpu_bo_list_create() amdgpu: Make amdgpu_cs_calculate_timeout() return some
[GIT PULL] drm/rockchip: new features
Hi Dave These patches convert drm/rockchip to atomic API and add rk3036 vop support. drm/rockchip: covert to support atomic API: https://lkml.org/lkml/2015/12/16/824 add rk3036 vop support: https://lkml.org/lkml/2015/12/16/851 These patch tested on popmetal board(rk3288) and kylin board(rk3036). Now seems there is no doubt on these patches, and rk3036 dt-bindings got Acked-by from Rob Herring. So I'd like you can land these patches. Thanks. The following changes since commit 20f8e032e6dc7053ab803f488e2a8839cd2f69a6: Backmerge drm-fixes merge into Linus's tree into drm-next. (2015-12-24 08:08:47 +1000) are available in the git repository at: https://github.com/markyzq/kernel-drm-rockchip.git drm-rockchip-next-2015-12-28 for you to fetch changes up to d4d3c6cbc289d78a9f5b54378beb338eb35d927e: dt-bindings: add document for rk3036-vop (2015-12-28 09:08:53 +0800) Mark Yao (14): drm/rockchip: Use new vblank api drm_crtc_vblank_* drm/rockchip: vop: replace dpms with enable/disable drm/rockchip: Convert to support atomic API drm/rockchip: Optimization vop mode set drm/rockchip: support atomic asynchronous commit drm/rockchip: direct config connecter gate and out_mode drm: bridge/dw_hdmi: add atomic API support drm/rockchip: dw_hdmi: use encoder enable function drm/rockchip: vop: merge vop cfg_done into vop_data drm/rockchip: vop: move interrupt registers into vop_data drm/rockchip: vop: spilt register related into rockchip_reg_vop.c drm/rockchip: vop: spilt scale regsters drm/rockchip: vop: add rk3036 vop support dt-bindings: add document for rk3036-vop -- ï¼ark Yao
[PATCH] drm: Clean up drm Makefile
This patch clean up the drm root directory's Makefile. Make core and device drivers configuration list sorted Alphabetically. Signed-off-by: Xinliang Liu Reviewed-by: Xinwei Kong Reviewed-by: Yifan Liu --- drivers/gpu/drm/Makefile | 84 +--- 1 file changed, 43 insertions(+), 41 deletions(-) diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 1e9ff4c3e3db..600df604e767 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -2,6 +2,9 @@ # Makefile for the drm device driver. This driver provides support for the # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher. +# core. Please keep this list sorted alphabetically +drm-$(CONFIG_PCI) += ati_pcigart.o + drm-y := drm_auth.o drm_bufs.o drm_cache.o \ drm_context.o drm_dma.o \ drm_fops.o drm_gem.o drm_ioctl.o drm_irq.o \ @@ -13,65 +16,64 @@ drm-y := drm_auth.o drm_bufs.o drm_cache.o \ drm_trace_points.o drm_global.o drm_prime.o \ drm_rect.o drm_vma_manager.o drm_flip_work.o \ drm_modeset_lock.o drm_atomic.o drm_bridge.o +obj-$(CONFIG_DRM) += drm.o +drm-y += $(drm-m) -drm-$(CONFIG_COMPAT) += drm_ioc32.o -drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o -drm-$(CONFIG_PCI) += ati_pcigart.o -drm-$(CONFIG_DRM_PANEL) += drm_panel.o -drm-$(CONFIG_OF) += drm_of.o drm-$(CONFIG_AGP) += drm_agpsupport.o - -drm-y += $(drm-m) +drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o +drm-$(CONFIG_COMPAT) += drm_ioc32.o drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o \ drm_plane_helper.o drm_dp_mst_topology.o drm_atomic_helper.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_FBDEV_EMULATION) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o - obj-$(CONFIG_DRM_KMS_HELPER) += drm_kms_helper.o -CFLAGS_drm_trace_points.o := -I$(src) - -obj-$(CONFIG_DRM) += drm.o obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o +drm-$(CONFIG_OF) += drm_of.o +drm-$(CONFIG_DRM_PANEL) += drm_panel.o obj-$(CONFIG_DRM_TTM) += ttm/ -obj-$(CONFIG_DRM_TDFX) += tdfx/ -obj-$(CONFIG_DRM_R128) += r128/ -obj-$(CONFIG_HSA_AMD) += amd/amdkfd/ -obj-$(CONFIG_DRM_RADEON)+= radeon/ + +CFLAGS_drm_trace_points.o := -I$(src) + +# device drivers. Please keep this list sorted alphabetically obj-$(CONFIG_DRM_AMDGPU)+= amd/amdgpu/ -obj-$(CONFIG_DRM_MGA) += mga/ +obj-$(CONFIG_HSA_AMD) += amd/amdkfd/ +obj-$(CONFIG_DRM_ARMADA) += armada/ +obj-$(CONFIG_DRM_AST) += ast/ +obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/ +obj-$(CONFIG_DRM_BOCHS) += bochs/ +obj-y += bridge/ +obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ +obj-$(CONFIG_DRM_EXYNOS) += exynos/ +obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ +obj-$(CONFIG_DRM_GMA500) += gma500/ +obj-y += i2c/ obj-$(CONFIG_DRM_I810) += i810/ obj-$(CONFIG_DRM_I915) += i915/ +obj-$(CONFIG_DRM_IMX) += imx/ +obj-$(CONFIG_DRM_MGA) += mga/ obj-$(CONFIG_DRM_MGAG200) += mgag200/ -obj-$(CONFIG_DRM_VC4) += vc4/ -obj-$(CONFIG_DRM_CIRRUS_QEMU) += cirrus/ -obj-$(CONFIG_DRM_SIS) += sis/ -obj-$(CONFIG_DRM_SAVAGE)+= savage/ -obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ -obj-$(CONFIG_DRM_VIA) +=via/ -obj-$(CONFIG_DRM_VGEM) += vgem/ +obj-$(CONFIG_DRM_MSM) += msm/ obj-$(CONFIG_DRM_NOUVEAU) +=nouveau/ -obj-$(CONFIG_DRM_EXYNOS) +=exynos/ -obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ -obj-$(CONFIG_DRM_GMA500) += gma500/ -obj-$(CONFIG_DRM_UDL) += udl/ -obj-$(CONFIG_DRM_AST) += ast/ -obj-$(CONFIG_DRM_ARMADA) += armada/ -obj-$(CONFIG_DRM_ATMEL_HLCDC) += atmel-hlcdc/ +obj-$(CONFIG_DRM_OMAP) += omapdrm/ +obj-y += panel/ +obj-$(CONFIG_DRM_QXL) += qxl/ +obj-$(CONFIG_DRM_R128) += r128/ +obj-$(CONFIG_DRM_RADEON)+= radeon/ obj-$(CONFIG_DRM_RCAR_DU) += rcar-du/ +obj-$(CONFIG_DRM_ROCKCHIP) +=rockchip/ +obj-$(CONFIG_DRM_SAVAGE)+= savage/ obj-$(CONFIG_DRM_SHMOBILE) +=shmobile/ -obj-$(CONFIG_DRM_OMAP) += omapdrm/ +obj-$(CONFIG_DRM_SIS) += sis/ +obj-$(CONFIG_DRM_STI) += sti/ +obj-$(CONFIG_DRM_TDFX) += tdfx/ +obj-$(CONFIG_DRM_TEGRA) += tegra/ obj-y += tilcdc/ -obj-$(CONFIG_DRM_QXL) += qxl/ -obj-$(CONFIG_DRM_BOCHS) += bochs/ +obj-$(CONFIG_DRM_UDL) += udl/ +obj-$(CONFIG_DRM_VC4) += vc4/ +obj-$(CONFIG_DRM_VGEM) += vgem/ +obj-$(CONFIG_DRM_VIA) +=via/ obj-$(CONFIG_DRM_VIRTIO_GPU) += virtio/ -obj-$(CONFIG_DRM_MSM) += msm/ -obj-$(CONFIG_DRM_TEGRA) += tegra/ -obj-$(CONFIG_DRM_STI) += sti/ -obj-$(CONFIG_DRM_IMX) += imx/ -obj-y += i2c/ -obj-y += panel/ -obj-y += bridge/ -obj-$(CONFIG_DRM_FSL_DCU) += fsl-dcu/ +obj-$(CONFIG_DRM_VMWGFX)+= vmwgfx/ -- 1.9.1
[PATCH] drm/docs: more leftovers from the big vtable documentation pile
* >* This callback is only used by the CRTC helpers and deprecated. > @@ -439,6 +447,12 @@ struct drm_encoder_helper_funcs { >* Atomic drivers which need to inspect and adjust more state should >* instead use the @atomic_check callback. >* > + * Also beware that the core nor helpers filters mode before passing the > + * to the driver. More specifically modes rejected by the ->mode_valid > + * callback from #drm_connector_helper_funcs can still be requested by > + * userspace and therefore also need to be rejected in either this hook, > + * or the one in #drm_crtc_helper_funcs. Same comments as for struct drm_crtc_helper_funcs. > + * >* RETURNS: >* >* True if an acceptable configuration is possible, false if the modeset > @@ -640,8 +654,16 @@ struct drm_connector_helper_funcs { >* In this function drivers then parse the modes in the EDID and add >* them by calling drm_add_edid_modes(). But connectors that driver a >* fixed panel can also manually add specific modes using > - * drm_mode_probed_add(). Finally drivers that support audio probably > - * want to update the ELD data, too, using drm_edid_to_eld(). > + * drm_mode_probed_add(). Drivers who manually add modes should also "drivers which" or "drivers that", I think. > + * make sure that the @display_info, @width_mm and @height_mm fields of > the > + * struct #drm_connector are filled out. I think "filled in" is slightly more appropriate in this case. > + * > + * Virtual drivers who just want some standard VESA mode with a given "drivers which" or "drivers that". Thierry -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/8f66bc39/attachment.sig>
[PATCH v3 1/7] drm/exynos: rename zpos to index
Hello, On 2015-12-24 09:15, Inki Dae wrote: > Seems this patch could be more cleaned up. > > Each ctx object of each crtc driver has its own plane config object which > includes already zpos value. > So I think we wouldn't need to keep zpos of the plane config and index of the > plane object. > How about removing index from exynos plane structure and using zpos of exynos > plane config structure instead? > > Below patch can be applied on top of your patch, If you want I can move 'index' entry to config object, but the initial zpos value should also be there. Please note that index is not always equal to the initial zpos and having initial zpos configurable is also needed. There were already concerns if mixer's dedicated video plane should be below or above the primary gfx plane in the default configuration. > (...) Best regards -- Marek Szyprowski, PhD Samsung R&D Institute Poland
[Bug 91278] Tonga GPU lock/reset fail with Unigine Valley
https://bugs.freedesktop.org/show_bug.cgi?id=91278 EoD changed: What|Removed |Added CC||EoD at xmw.de --- Comment #48 from EoD --- I don't get any lockups with kernel 4.4-rc6 and current mesa git on my R380X. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/1cd75582/attachment-0001.html>
[Bug 93522] Tonga has only black virtual terminals
https://bugs.freedesktop.org/show_bug.cgi?id=93522 Bug ID: 93522 Summary: Tonga has only black virtual terminals Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel at lists.freedesktop.org Reporter: EoD at xmw.de When I boot the kernel via grub everything is fine, once the kernel is loading there is only a black screen until X starts. When I switch back to the VT (via Ctrl+Alt+F1) I still see everything from X, except the mouse. When I switch back to X everything works fine again. I am using current mesa-git and kernel 4.4-rc6. glxinfo, dmesg, etc: can be found here: https://gist.github.com/EoD/ecb3e28fc004d740daa1 This might be a duplicate of Bug 91202. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/3987/attachment.html>
[RESEND 1/3] drm: fsl-dcu: Fix no fb check bug
Hi Stefan, On Sunday, 27 December 2015, Stefan Agner wrote: > > However, I think with my patch "drm/fsl-dcu: Fix no fb check bug", this > situation can be avoided completely: > https://lkml.org/lkml/2015/11/18/950 > > With that patch applied, and a non-existing panel assigned, the DRM > driver already fails at probe time gracefully: > [0.488291] [drm] Initialized drm 1.1.0 20060810 > [0.501576] fsl-dcu 40058000.dcu: failed to initialize mode setting > > So I think that a state->fb check for NULL is not necessary at all... > > Can you test my patch to see if it fixes the issue for you too? > This is still required; state->fb being NULL means the plane is being disabled. Cheers, Daniel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/7c43fb37/attachment.html>
[PATCH] include/linux/amd-iommu.h: Move to arch/x86/include/asm
On Sat, Dec 26, 2015 at 09:26:32PM +0800, chengang at emindsoft.com.cn wrote: > From: Chen Gang > > It is architecture specific mechanism header, not generic header, so > move it to arch/x86/include/asm. There might be future non-x86 hardware which also has an amd iommu, so the header file should stay where it is for now. Joerg
[BUG] Radeon TAHITI_vce.bin firmware casuses oops on Acube Sam460ex amcc 460ex power board
] drm_dev_register+0x84/0xc8 [7.539946] [ea84dd80] [c02efd24] drm_get_pci_dev+0xf0/0x18c [7.545632] [ea84dda0] [c028a264] pci_device_probe+0x78/0xcc [7.551318] [ea84ddc0] [c03fa014] driver_probe_device+0x11c/0x264 [7.557437] [ea84ddf0] [c03fa1d4] __driver_attach+0x78/0xa0 [7.563036] [ea84de10] [c03f8598] bus_for_each_dev+0x8c/0x9c [7.568722] [ea84de40] [c03f974c] bus_add_driver+0xe0/0x1f0 [7.574321] [ea84de60] [c03fa8cc] driver_register+0xb4/0xf8 [7.579919] [ea84de80] [c00016f4] do_one_initcall+0x118/0x1a0 [7.585692] [ea84def0] [c09aeaac] kernel_init_freeable+0x130/0x1cc [7.591899] [ea84df30] [c0001cf8] kernel_init+0x14/0xf4 [7.597151] [ea84df40] [c000ad90] ret_from_kernel_thread+0x5c/0x64 [7.603353] Instruction dump: [7.606341] 614a0017 4808 614a0015 811d0008 3be0 2f88 39280001 40bc0024 [7.614222] 3921 481c 1cff0028 7cfd3a14 <80e7000c> 7f075000 419a0014 3bff0001 [7.622306] ---[ end trace fcdb15e53089034a ]--- [7.626939] [8.628614] Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b [8.628614] [8.637786] Rebooting in 180 seconds.. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/9cfc8363/attachment-0001.html>
[Bug 91294] [R7 370] DPM and power profile change crash the system
https://bugs.freedesktop.org/show_bug.cgi?id=91294 --- Comment #9 from Elia Argentieri --- Indeed I also tried with higher clock speeds like 1400 and 1300, but all my attempts had the same outcome. I don't really understand why an higher clock frequency would lock completely the system as the radeon module is loaded... I think MSI is doing nasty things like putting a limit inside their firmware to make the GPU unusable with higher frequencies. I won't ever buy again an MSI product. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/66f8b7e1/attachment.html>
[Bug 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #47 from Lauri Gustafsson --- (In reply to John Frei from comment #44) > I found out some interesting fact on my system: > > If I start in textmode (runlevel 3) with no specific kernel parameter like > 'radeon.dpm=0', set power_dm_force_perofrmance_level to 'high' and > power_dpm_state to 'performance' and finally start the gdm service, the > system works without crash. I was even able to play some games. > > If I boot in textmode with radeon.dpm=0 and try to set power_profile to > 'high', I get a crash immediately. I cannot even start gdm in this case. Ah, setting the force_performance_level was the key, now I can get >70fps in Unigine heaven without any crashes! I hope dpm gets fixed and trickles down to Arch Linux soon, it's a bit of a waste to be running my card at full power all the time... -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/018d1544/attachment.html>
[Bug 93525] [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume
https://bugs.freedesktop.org/show_bug.cgi?id=93525 Bug ID: 93525 Summary: [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume Product: DRI Version: XOrg git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: rafaelrcenteio at gmail.com Created attachment 120720 --> https://bugs.freedesktop.org/attachment.cgi?id=120720&action=edit dmesg output. I am receiving the following message on boot: "[ 13.198262] [drm:evergreen_resume [radeon]] *ERROR* evergreen startup failed on resume" uname -a Linux rafael 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-3~bpo8+2 (2015-12-14) x86_64 GNU/Linux lspci In attachment: dmesg's output. >From dmidecode: Vendor: Hewlett-Packard Version: F.48 Release Date: 11/09/2011 ROM Size: 2048 kB ... BIOS Revision: 15.48 Firmware Revision: 60.80 Worth mentioning that the behaviour of the fans and the temperatures change a lot after suspension/hibernation. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151228/667c5744/attachment.html>