[Bug 90861] Panic on suspend from KDE with radeon
https://bugzilla.kernel.org/show_bug.cgi?id=90861 --- Comment #12 from Jon Arne Jørgensen --- I tested attachment 164421 from bug 90741, and can report that the patch seems to fix the crash. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #24 from Jon Arne Jørgensen --- I just commented out the trace_fence_enable_signal call to get it to compile. Figured I don't need the tracepoint debug to test the patch. I also uncommented the sw_irq_get and sw_irq_put calls, and can report that the patch seems to fix bug 90861. I guess this is proof that the bug is related. I didn't try the patch with sw_irq_get/set disabled. Just ask, and I will give it a try. -- You are receiving this mail because: You are watching the assignee of the bug.
[GIT PULL] exynos-drm-next
Hi Dave, This pull request includes some code refactoring which removes Exynos specific structure names and uses generic structure names instead, and makes all plane updating to be done by only exynos_update_plane function. And also it includes some cleanup and fixup patches. Please kindly let me know if there is any problem. Thanks, Inki Dae The following changes since commit 281d1bbd34b734e4f22b30b6f3b673dda46a7470: Merge remote-tracking branch 'origin/master' into drm-next (2015-01-22 10:44:41 +1000) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git exynos-drm-next for you to fetch changes up to efa75bcdad59fc796152a4c73bb65ae2ab7ce035: drm/exynos: fimd: check error status for drm_iommu_attach_device (2015-01-25 21:28:09 +0900) Ajay Kumar (1): drm/exynos: fimd: check error status for drm_iommu_attach_device Gustavo Padovan (21): drm/exynos: move to_exynos_crtc() macro to main header drm/exynos: expose struct exynos_drm_crtc drm/exynos: remove exynos_drm_crtc_plane_* wrappers drm/exynos: remove struct exynos_drm_overlay drm/exynos/fimd: don't initialize 'ret' variable in fimd_probe() drm/exynos/vidi: remove useless ops->commit() drm/exynos: Don't touch DPMS when updating overlay planes drm/exynos: don't do any DPMS operation while updating planes drm/exynos: remove exynos_plane_commit() wrapper drm/exynos: unify plane update on exynos_update_plane() drm/exynos: call exynos_update_plane() directly on page flips drm/exynos: remove exynos_drm_crtc_mode_set_commit() drm/exynos: rename base object of struct exynos_drm_crtc to 'base' drm/exynos: add pipe param to exynos_drm_crtc_create() drm/exynos: remove pipe member of struct exynos_drm_manager drm/exynos: move 'type' from manager to crtc struct drm/exynos: remove drm_dev from struct exynos_drm_manager drm/exynos: remove struct exynos_drm_manager drm/exynos: don't duplicate drm_display_mode in fimd context drm/exynos: remove mode_set() ops from exynos_crtc drm/exynos: create exynos_check_plane() drivers/gpu/drm/exynos/exynos_drm_crtc.c | 185 +-- drivers/gpu/drm/exynos/exynos_drm_crtc.h |8 +- drivers/gpu/drm/exynos/exynos_drm_drv.h | 83 +++- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 196 ++--- drivers/gpu/drm/exynos/exynos_drm_plane.c | 138 ++-- drivers/gpu/drm/exynos/exynos_drm_plane.h | 17 ++- drivers/gpu/drm/exynos/exynos_drm_vidi.c | 135 +--- drivers/gpu/drm/exynos/exynos_mixer.c | 159 --- 8 files changed, 426 insertions(+), 495 deletions(-)
[PATCH] drm/msm: Remove CRTC .mode_set and .mode_set_base helpers
The helpers are not used anymore with atomic updates, remove them.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c | 2 --
drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c | 2 --
2 files changed, 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
index 20ae503..67b42a4 100644
--- a/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp4/mdp4_crtc.c
@@ -507,8 +507,6 @@ static const struct drm_crtc_helper_funcs
mdp4_crtc_helper_funcs = {
.dpms = mdp4_crtc_dpms,
.mode_fixup = mdp4_crtc_mode_fixup,
.mode_set_nofb = mdp4_crtc_mode_set_nofb,
- .mode_set = drm_helper_crtc_mode_set,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.prepare = mdp4_crtc_prepare,
.commit = mdp4_crtc_commit,
.atomic_check = mdp4_crtc_atomic_check,
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
index 6b25f9f..47f101d 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_crtc.c
@@ -394,8 +394,6 @@ static const struct drm_crtc_helper_funcs
mdp5_crtc_helper_funcs = {
.dpms = mdp5_crtc_dpms,
.mode_fixup = mdp5_crtc_mode_fixup,
.mode_set_nofb = mdp5_crtc_mode_set_nofb,
- .mode_set = drm_helper_crtc_mode_set,
- .mode_set_base = drm_helper_crtc_mode_set_base,
.prepare = mdp5_crtc_prepare,
.commit = mdp5_crtc_commit,
.atomic_check = mdp5_crtc_atomic_check,
--
Regards,
Laurent Pinchart
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #23 from Jon Arne Jørgensen --- @Gustaw: ~/Development/c/kernel/src% git describe --long --tags v3.19-rc5-0-gec6f34e So, that should be 3.19-rc5 :) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 90741] Radeon: System pauses on TAHITI
https://bugzilla.kernel.org/show_bug.cgi?id=90741 --- Comment #22 from Gustaw Smolarczyk --- @Maarten Lankhorst The "Clear irqs..." patch doesn't seem to help. Also, the WARN_ON_ONCE() doesn't seem to be hit (I have added 'WARN_ON_ONCE(1);' in the else block). The dmesg doesn't have anything related to it. Am I right that the WARN_ON_ONCE line should appear in dmesg in case it is reached? @Jon Arne Jørgensen About patch compilation: I have applied it on top of 3.19-rc5. Are you by any chance using 3.18? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/nouveau/subdev: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c:50:5-8: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci CC: Martin Peres Signed-off-by: Fengguang Wu --- gm107.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c +++ b/drivers/gpu/drm/nouveau/core/subdev/fuse/gm107.c @@ -47,10 +47,7 @@ gm107_fuse_ctor(struct nouveau_object *p ret = nouveau_fuse_create(parent, engine, oclass, ); *pobject = nv_object(priv); - if (ret) - return ret; - - return 0; + return ret; } struct nouveau_oclass
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #4 from Woody Suwalski --- Created attachment 112805 --> https://bugs.freedesktop.org/attachment.cgi?id=112805=edit lspci -vvnn -- 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/20150125/e1048e3d/attachment.html>
[PATCH] drm/nouveau/bar: fix simple_return.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/bar/base.c:132:5-8: WARNING: end returns can be simpified Simplify a trivial if-return sequence. Possibly combine with a preceding function call. Generated by: scripts/coccinelle/misc/simple_return.cocci Signed-off-by: Fengguang Wu --- base.c |5 + 1 file changed, 1 insertion(+), 4 deletions(-) --- a/drivers/gpu/drm/nouveau/core/subdev/bar/base.c +++ b/drivers/gpu/drm/nouveau/core/subdev/bar/base.c @@ -129,10 +129,7 @@ nouveau_bar_create_(struct nouveau_objec ret = nouveau_subdev_create_(parent, engine, oclass, 0, "BARCTL", "bar", length, pobject); bar = *pobject; - if (ret) - return ret; - - return 0; + return ret; } void
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 Woody Suwalski changed: What|Removed |Added Attachment #112800|0 |1 is obsolete|| --- Comment #3 from Woody Suwalski --- Created attachment 112802 --> https://bugs.freedesktop.org/attachment.cgi?id=112802=edit Xorg log - uneventfull - stops at DRM -- 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/20150125/9dd6ee5f/attachment.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #2 from Woody Suwalski --- Created attachment 112801 --> https://bugs.freedesktop.org/attachment.cgi?id=112801=edit Kernel config 32-bit, all DRM built in -- 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/20150125/4a5582be/attachment.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 --- Comment #1 from Woody Suwalski --- Created attachment 112800 --> https://bugs.freedesktop.org/attachment.cgi?id=112800=edit Xorg log - uneventfull - stops at DRM -- 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/20150125/bfc9d913/attachment.html>
[Bug 88786] Radeon Hawaii crash on a 32-bit kernel
https://bugs.freedesktop.org/show_bug.cgi?id=88786 Bug ID: 88786 Summary: Radeon Hawaii crash on a 32-bit kernel Product: DRI Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: DRM/Radeon Assignee: dri-devel at lists.freedesktop.org Reporter: terraluna977 at gmail.com QA Contact: terraluna977 at gmail.com Created attachment 112799 --> https://bugs.freedesktop.org/attachment.cgi?id=112799=edit dmesg booted with drm.debug The new MSI Hawaii board, used single or 2-headed. The crash in [5.654006] kernel BUG at drivers/gpu/drm/radeon/radeon_sa.c:321! [5.654008] invalid opcode: [#1] PREEMPT SMP The crash is 100% repeatable. The system will boot OK to X with radeon.modeset=0. The kernel has added trace to verify the firmware requested. Unclear about 64-bit behavior, since I am booting a live USB distro. Distro based on Debian Jessie, with X.Org X Server 1.16.2.901 (1.16.3 RC 1) Release Date: 2014-12-09 -- 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/20150125/117ef028/attachment-0001.html>
[PATCH] drm/probe-helper: don't lose hotplug event
On Wed, Jan 21, 2015 at 4:40 PM, Rob Clark wrote: > On Wed, Jan 21, 2015 at 9:41 AM, Daniel Vetter > wrote: >> There's a race window (small for hpd, 10s large for polled outputs) >> where userspace could sneak in with an unrelated connnector probe >> ioctl call and eat the hotplug event (since neither the hpd nor the >> poll code see a state change). >> >> To avoid this, check whether the connector state changes in all other >> ->detect calls (in the current helper code that's only probe_single) >> and if that's the case, fire off a hotplug event. Note that we can't >> directly call the hotplug event handler, since that expects that no >> locks are held (due to reentrancy with the fb code to update the kms >> console). >> >> Also, this requires that drivers using the probe_single helper >> function set up the poll work. All current drivers do that already, >> and with the reworked hpd handling there'll be no downside to >> unconditionally setting up the poll work any more. >> >> v2: Review from Rob Clark >> - Don't bail out of the output poll work immediately if it's disabled >> to make sure we deliver the delayed hoptplug events. Instead just >> jump to the tail. >> - Don't scheduel the work when it's not set up. Would be a driver bug >> since using probe helpers for anything dynamic without them >> initialized makes them all noops. >> >> Reviewed-by: Chris Wilson (v1) >> Cc: Rob Clark >> Signed-off-by: Daniel Vetter > > Reviewed-by: Rob Clark > > and with the monitor that started all this, plus the addition of: > http://lists.freedesktop.org/archives/dri-devel/2015-January/075901.html > > Tested-by: Rob Clark bleh, but on latest upstream (plus drm-next, etc).. possibly just not caught earlier due to insufficient debug stuff enabled.. I could probably solve this by moving drm_kms_helper_poll_init() earlier.. otoh that might cause other surprises and other drivers also seem to do this late in their load.. [4.053197] WARNING: CPU: 3 PID: 52 at ../kernel/workqueue.c:1427 __queue_delayed_work+0x14c/0x15c() [4.058040] Modules linked in: [4.070017] CPU: 3 PID: 52 Comm: kworker/u8:1 Tainted: G U 3.19.0-rc5-00821-g415f9e0-dirty #1113 [4.070107] Hardware name: Qualcomm (Flattened Device Tree) [4.080016] Workqueue: deferwq deferred_probe_work_func [4.090549] [] (unwind_backtrace) from [] (show_stack+0x10/0x14) [4.090714] [] (show_stack) from [] (dump_stack+0x8c/0x9c) [4.098519] [] (dump_stack) from [] (warn_slowpath_common+0x84/0xb4) [4.105547] [] (warn_slowpath_common) from [] (warn_slowpath_null+0x1c/0x24) [4.113790] [] (warn_slowpath_null) from [] (__queue_delayed_work+0x14c/0x15c) [4.122556] [] (__queue_delayed_work) from [] (queue_delayed_work_on+0x50/0x5c) [4.131337] [] (queue_delayed_work_on) from [] (drm_helper_probe_single_connector_modes_merge_bits+0x2fc/0x49c) [4.140290] [] (drm_helper_probe_single_connector_modes_merge_bits) from [] (drm_fb_helper_probe_connector_modes.isra.5+0x4c/0x6c) [4.152089] [] (drm_fb_helper_probe_connector_modes.isra.5) from [] (drm_fb_helper_initial_config+0x34/0x3d8) [4.165624] [] (drm_fb_helper_initial_config) from [] (msm_fbdev_init+0x70/0xa0) [4.177342] [] (msm_fbdev_init) from [] (msm_load+0x268/0x36c) [4.186537] [] (msm_load) from [] (drm_dev_register+0xa8/0x104) [4.193912] [] (drm_dev_register) from [] (drm_platform_init+0x44/0xd8) [4.201475] [] (drm_platform_init) from [] (try_to_bring_up_master.part.3+0xc8/0x108) [4.209804] [] (try_to_bring_up_master.part.3) from [] (component_master_add_with_match+0xac/0x124) [4.219525] [] (component_master_add_with_match) from [] (msm_pdev_probe+0x64/0x70) [4.230116] [] (msm_pdev_probe) from [] (platform_drv_probe+0x44/0xa4) [4.239485] [] (platform_drv_probe) from [] (driver_probe_device+0x108/0x23c) [4.247813] [] (driver_probe_device) from [] (bus_for_each_drv+0x64/0x98) [4.256752] [] (bus_for_each_drv) from [] (device_attach+0x74/0x88) [4.265259] [] (device_attach) from [] (bus_probe_device+0x84/0xa8) [4.273071] [] (bus_probe_device) from [] (deferred_probe_work_func+0x64/0x94) [4.281064] [] (deferred_probe_work_func) from [] (process_one_work+0x134/0x334) [4.290091] [] (process_one_work) from [] (worker_thread+0x4c/0x4b0) [4.299383] [] (worker_thread) from [] (kthread+0xdc/0xf4) [4.307459] [] (kthread) from [] (ret_from_fork+0x14/0x3c) BR, -R > >> --- >> drivers/gpu/drm/drm_probe_helper.c | 36 ++-- >> include/drm/drm_crtc.h | 1 + >> 2 files changed, 35 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c >> b/drivers/gpu/drm/drm_probe_helper.c >> index 2fbdcca7ca9a..33bf550a1d3f 100644 >> --- a/drivers/gpu/drm/drm_probe_helper.c >> +++ b/drivers/gpu/drm/drm_probe_helper.c >> @@ -103,6 +103,7 @@ static int >> drm_helper_probe_single_connector_modes_merge_bits(struct drm_connect >> int count =
[Bug 88784] radeonsi: Brütal Legend crashs after about 10-15 sec. (GPU fault detected: 147 0x0618c001)
https://bugs.freedesktop.org/show_bug.cgi?id=88784 Laurent carlier changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Laurent carlier --- *** This bug has been marked as a duplicate of bug 88456 *** -- 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/20150125/66b33773/attachment.html>
[Bug 88456] Brütal Legend lockup
https://bugs.freedesktop.org/show_bug.cgi?id=88456 Laurent carlier changed: What|Removed |Added CC||bu9zilla at gmail.com --- Comment #3 from Laurent carlier --- *** Bug 88784 has been marked as a duplicate of this bug. *** -- 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/20150125/c8344afc/attachment.html>
[Bug 88784] radeonsi: Brütal Legend crashs after about 10-15 sec. (GPU fault detected: 147 0x0618c001)
https://bugs.freedesktop.org/show_bug.cgi?id=88784 Laurent carlier changed: What|Removed |Added Attachment #112797|text/plain |image/jpeg mime type|| -- 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/20150125/f247fe3e/attachment.html>
[Bug 88784] radeonsi: Brütal Legend crashs after about 10-15 sec. (GPU fault detected: 147 0x0618c001)
https://bugs.freedesktop.org/show_bug.cgi?id=88784 --- Comment #2 from Michael Mair-Keimberger --- Created attachment 112797 --> https://bugs.freedesktop.org/attachment.cgi?id=112797=edit picture taken with phone -- 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/20150125/129d6c6d/attachment.html>
[Bug 88784] radeonsi: Brütal Legend crashs after about 10-15 sec. (GPU fault detected: 147 0x0618c001)
https://bugs.freedesktop.org/show_bug.cgi?id=88784 --- Comment #1 from Michael Mair-Keimberger --- Created attachment 112796 --> https://bugs.freedesktop.org/attachment.cgi?id=112796=edit radeontop log -- 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/20150125/a1ffa3c2/attachment.html>
[Bug 88784] radeonsi: Brütal Legend crashs after about 10-15 sec. (GPU fault detected: 147 0x0618c001)
-pipe" GENTOO_MIRRORS="http://distfiles.gentoo.org; LANG="en_US.utf8" LDFLAGS="-Wl,-O1 -Wl,--as-needed" MAKEOPTS="-j9" PKGDIR="/usr/portage/packages" PORTAGE_CONFIGROOT="/" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/media/public/overlays/local /media/public/overlays/layman/tox-overlay /media/public/overlays/layman/raiagent" SYNC="rsync://192.168.2.1/gentoo-portage" USE="acl alsa amd64 avx berkdb bzip2 cli cracklib crypt cxx dbus dri exif flac gallium gdbm glamor graphite iconv icu ipv6 jpeg kde kipi lzma mmx mmxext modules mp3 multilib ncurses nls nptl openal opengl openmp otr pam pcre png qt4 readline sdl session sse sse2 sse3 sse4_1 sse4_2 sse4a ssl ssse3 svg tcpd threads tiff truetype unicode vdpau vim-syntax xinerama zlib" ABI_X86="64" ALSA_CARDS="ali5451 als4000 atiixp atiixp-modem bt87x ca0106 cmipci emu10k1x ens1370 ens1371 es1938 es1968 fm801 hda-intel intel8x0 intel8x0m maestro3 trident usb-audio via82xx via82xx-modem ymfpci" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="krita sheets words karbon" CAMERAS="ptp2" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf superstar2 timing tsip tripmate tnt ublox ubx" GRUB_PLATFORMS="pc" INPUT_DEVICES="evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" LINGUAS="en" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-5" PYTHON_SINGLE_TARGET="python2_7" PYTHON_TARGETS="python2_7 python3_3" RUBY_TARGETS="ruby19 ruby20" USERLAND="GNU" VIDEO_CARDS="radeon radeonsi" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LC_ALL, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS, USE_PYTHON = Package Settings = media-libs/mesa-10.4.2 was built with the following: USE="classic dri3 egl gallium gbm gles2 llvm nptl opencl openmax r600-llvm-compiler udev vdpau xa xvmc -bindist -debug -gles1 -osmesa -pax_kernel -pic (-selinux) -vaapi -wayland" ABI_X86="32 64 -x32" VIDEO_CARDS="radeon radeonsi -freedreno -i915 -i965 -ilo -intel -nouveau -r100 -r200 -r300 -r600 -vmware" x11-drivers/xf86-video-ati-7.5.0 was built with the following: USE="glamor udev" ABI_X86="64" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,lazy" x11-libs/libdrm-2.4.58 was built with the following: USE="libkms -static-libs" ABI_X86="32 64 -x32" VIDEO_CARDS="radeon -exynos -freedreno -intel -nouveau -omap -vmware" x11-base/xorg-server-1.16.3-r1 was built with the following: USE="glamor ipv6 kdrive nptl suid udev xorg -dmx -doc -minimal (-selinux) -static-libs -systemd -tslib -unwind -wayland -xnest -xvfb" ABI_X86="64" LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,-z,lazy" sys-devel/llvm-3.5.1 was built with the following: USE="clang libffi ncurses static-analyzer -debug -doc -gold -libedit -multitarget -ocaml -python -test -xml" ABI_X86="32 64 -x32" PYTHON_TARGETS="python2_7 -pypy" VIDEO_CARDS="radeon" -- 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/20150125/a54c8d10/attachment-0001.html>
[GIT PULL] qcom SoC changes for v3.20
On Sun, Jan 25, 2015 at 11:03 AM, Rob Clark wrote: > On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson wrote: I'd be OK with merging this, send a request and tag. Would that let the DRM folks make progress too? >>> >>> Will do, I donât think it will address the DRM folks needs as they need >>> access to make firmware calls from the DRM driver. >>> If you need a common place for this, drivers/firmware seems like a better home than drivers/soc. >>> >>> Agreed, whatâs you take than on moving to use firmware_ops as defined in >>> arch/arm and extended it or just leaving this as a qcom specific firmware >>> interface? >> >> Are there any other SoCs out there with similar requirements on >> firmware interfaces? I think most of them so far have been fairly >> simple compared to the complexity of the qualcomm firmware. > > I think the question is probably "how do downstream HDCP > implementations work on these other SoCs".. so far, I think qcom is > the first to try to upstream HDCP support, but I know there have to be > at least a few downstream implementations lurking out there. > This isn't a concern on exynos, fwiw. > And I'm sure as some others come out of the woodwork there will be > some things to refactor.. like possibly shared helpers for > implementing the state machine, etc. > Shared helpers would be useful to have once there's another hdcp implementation upstream. I haven't looked at our downstream hdcp implementation in a while, so it's difficult to say how much could be factored out. It's on my TODO stack... somewhere. Sean > BR, > -R > >> Would it make sense to use firmware_ops for the common pieces and have >> direct smc calls for the rest? I'm not sure that would buy us all that >> much. Hm. >> >> Well, at least it's an internal implementation detail. If we move it >> now and find a better way to do it down the road it can be refactored.
[GIT PULL] qcom SoC changes for v3.20
On Fri, Jan 23, 2015 at 1:43 PM, Olof Johansson wrote: >>> I'd be OK with merging this, send a request and tag. Would that let >>> the DRM folks make progress too? >> >> Will do, I donât think it will address the DRM folks needs as they need >> access to make firmware calls from the DRM driver. >> >>> If you need a common place for this, drivers/firmware seems like a >>> better home than drivers/soc. >> >> Agreed, whatâs you take than on moving to use firmware_ops as defined in >> arch/arm and extended it or just leaving this as a qcom specific firmware >> interface? > > Are there any other SoCs out there with similar requirements on > firmware interfaces? I think most of them so far have been fairly > simple compared to the complexity of the qualcomm firmware. I think the question is probably "how do downstream HDCP implementations work on these other SoCs".. so far, I think qcom is the first to try to upstream HDCP support, but I know there have to be at least a few downstream implementations lurking out there. And I'm sure as some others come out of the woodwork there will be some things to refactor.. like possibly shared helpers for implementing the state machine, etc. BR, -R > Would it make sense to use firmware_ops for the common pieces and have > direct smc calls for the rest? I'm not sure that would buy us all that > much. Hm. > > Well, at least it's an internal implementation detail. If we move it > now and find a better way to do it down the road it can be refactored.
[Bug 88781] Unity3D based games exhibit problems with texture scaling in menus on high resolutions
https://bugs.freedesktop.org/show_bug.cgi?id=88781 Bug ID: 88781 Summary: Unity3D based games exhibit problems with texture scaling in menus on high resolutions Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: kai at dev.carbon-project.org QA Contact: dri-devel at lists.freedesktop.org Blocks: 77449 Created attachment 112788 --> https://bugs.freedesktop.org/attachment.cgi?id=112788=edit Various badly scaled textures in Jagged Alliance: Flashback I've noticed, that several Unity3D based games seem to have issues with scaling textures for high resolutions in menus. Dreamfall Chapters exhibits this in the load savegame menu, where the preview images of the scene are just a few large blurry pixels. Jagged Alliance: Flashback has this in the inventory, the command overlay (see the mini map or the merc data in the attached screenshot; ignore the blueish rendering, that's bug 88780). As soon as I reduce the resolution to, say, 1920Ã1080 from my native 2560Ã1440, everything looks fine. My current stack (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/d2811c29da libdrm: Git:master/libdrm-2.4.59 LLVM: SVN:trunk/r226934 (3.7 devel) X.Org: Git:master/6672606420 Linux: Git::drm-fixes/67cf2d3912 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/d73f33b736 DDX: Git:master/c9f8f642fd -- 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/20150125/4d8ed0aa/attachment.html>
[Bug 88780] Several Unity3D-based games render with "foggy blueish overlay"
https://bugs.freedesktop.org/show_bug.cgi?id=88780 Kai changed: What|Removed |Added Blocks||77449 -- 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/20150125/2cf9fb59/attachment-0001.html>
[Bug 88780] Several Unity3D-based games render with "foggy blueish overlay"
https://bugs.freedesktop.org/show_bug.cgi?id=88780 Kai changed: What|Removed |Added Attachment #112787|text/plain |image/jpeg mime type|| -- 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/20150125/6483105f/attachment.html>
[PATCH] drm/nouveau/i2c: fix semicolon.cocci warnings
drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c:74:26-27: Unneeded semicolon Removes unneeded semicolon. Generated by: scripts/coccinelle/misc/semicolon.cocci Signed-off-by: Fengguang Wu --- padnv94.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c +++ b/drivers/gpu/drm/nouveau/core/subdev/i2c/padnv94.c @@ -71,7 +71,7 @@ nv94_i2c_pad_ctor(struct nouveau_object if (ret) return ret; - pad->addr = index * 0x50;; + pad->addr = index * 0x50; return 0; }
[Bug 88780] Several Unity3D-based games render with "foggy blueish overlay"
https://bugs.freedesktop.org/show_bug.cgi?id=88780 Bug ID: 88780 Summary: Several Unity3D-based games render with "foggy blueish overlay" Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: kai at dev.carbon-project.org QA Contact: dri-devel at lists.freedesktop.org Created attachment 112787 --> https://bugs.freedesktop.org/attachment.cgi?id=112787=edit Blue overlay with Dreamfall Chapters in the lab scene With the stack detailed below (AFAICT this is *NOT* a regression, because I seem to remember having these hazy blue scenes with older versions of Mesa as well) several Unity3D-based games (e.g. Jagged Alliance: Flashback or Dreamfall Chapters) render either entirely or only some scenes as if there was some fog overlay with a blue hue. For Dreamfall Chapters (from which the attached screenshot originates), it's only for some scenes, sometimes even dependant on the camera angle. For example, in the Queenie scene only some camera angles exhibit this problem, while in the lab scene, you have it constantly. With Dreamfall Chapters this bug can be seen mostly indoors. Games like Jagged Alliance render all 3D scenes with this blue hue overlay. This is, every sector you go into shows this problem. My current stack (Debian testing as a base): GPU: Hawaii PRO [Radeon R9 290] (ChipID = 0x67b1) Mesa: Git:master/d2811c29da libdrm: Git:master/libdrm-2.4.59 LLVM: SVN:trunk/r226934 (3.7 devel) X.Org: Git:master/6672606420 Linux: Git::drm-fixes/67cf2d3912 Firmware: <http://people.freedesktop.org/~agd5f/radeon_ucode/> > 9e05820da42549ce9c89d147cf1f8e19 hawaii_ce.bin > c8bab593090fc54f239c8d7596c8d846 hawaii_mc.bin > 3618dbb955d8a84970e262bb2e6d2a16 hawaii_me.bin > c000b0fc9ff6582145f66504b0ec9597 hawaii_mec.bin > 0643ad24b3beff2214cce533e094c1b7 hawaii_pfp.bin > ba6054b7d78184a74602fd81607e1386 hawaii_rlc.bin > 11288f635737331b69de9ee82fe04898 hawaii_sdma.bin > 284429675a5560e0fad42aa982965fc2 hawaii_smc.bin libclc: Git:master/d73f33b736 DDX: Git:master/c9f8f642fd -- 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/20150125/4369d38f/attachment.html>
[Bug 41762] radeon default power_profile "default" makes laptop overheat (Mobility Radeon HD 3650)
https://bugs.freedesktop.org/show_bug.cgi?id=41762 Dmitri Kolobov changed: What|Removed |Added CC||disjunctor at gmail.com --- Comment #12 from Dmitri Kolobov --- I have exactly the same problem as described by previous posts (Radeon 3650, Asus F8Va laptop. OpenSuSE 12-13.2, Fedora). With low profile the temperature is about 70°C, and with the default one the temperature (idle system) goes to 80-85°C. DPM mode shows the same behavior. -- 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/20150125/ea308b35/attachment.html>
[PATCH libdrm 08/11] tests: modetest: Accept connector names
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:21 Thierry Reding wrote:
> From: Thierry Reding
>
> Allow connector names to be used in the specification of the -s option.
> This requires storing the string passed on the command-line so that it
> can later be resolved to a connector ID (after the DRM device has been
> opened).
>
> Signed-off-by: Thierry Reding
> ---
> tests/modetest/modetest.c | 134 +++
> 1 file changed, 123 insertions(+), 11 deletions(-)
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index d5fd99ebe1fd..a7cc94f8938c 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
[snip]
> @@ -327,7 +328,7 @@ static void dump_connectors(struct device *dev)
> int i, j;
>
> printf("Connectors:\n");
> - printf("id\tencoder\tstatus\t\ttype\tsize (mm)\tmodes\tencoders\n");
> + printf("id\tencoder\tstatus\t\tname\t\tsize (mm)\tmodes\tencoders\n");
> for (i = 0; i < dev->resources->res->count_connectors; i++) {
> struct connector *_connector = >resources->connectors[i];
> drmModeConnector *connector = _connector->connector;
> @@ -338,7 +339,7 @@ static void dump_connectors(struct device *dev)
> connector->connector_id,
> connector->encoder_id,
> util_lookup_connector_status_name(connector->connection),
> -
> util_lookup_connector_type_name(connector->connector_type),
> +_connector->name,
> connector->mmWidth, connector->mmHeight,
> connector->count_modes);
As this is a low-level test tool I believe it would be useful to print both
the name and the ID. Maybe something like "name (id)" ?
[snip]
> @@ -511,6 +516,47 @@ static void free_resources(struct resources *res)
> free(res);
> }
>
> +static unsigned int get_connector_index(struct resources *res, uint32_t
> type)
> +{
> + unsigned int index = 0;
> + int i;
> +
> + for (i = 0; i < res->res->count_connectors; i++)
> + if (res->connectors[i].connector->connector_type == type)
> + index++;
> +
> + return index - 1;
> +}
> +
> +static unsigned int get_order(unsigned int value)
> +{
> + unsigned int order = 0;
> +
> + do {
> + value /= 10;
> + order++;
> + } while (value > 0);
> +
> + return order - 1;
> +}
> +
> +static void connector_set_name(struct connector *connector,
> +struct resources *res)
> +{
> + uint32_t type = connector->connector->connector_type;
> + const char *type_name;
> + unsigned int index;
> + int len;
> +
> + type_name = util_lookup_connector_type_name(type);
> + index = get_connector_index(res, type);
The kernel's connector name is created using connector_type_id, not the
connector index. Shouldn't we do the same here ?
> + len = strlen(type_name) + get_order(index) + 2;
This looks like an over-optimization to me, can't you just add 9 to account
for the largest possible index ? Or, even better, use asprintf ? The function
is a GNU extension but is available on BSD according to its manpage.
> + connector->name = malloc(len + 1);
> + if (connector->name)
> + snprintf(connector->name, len + 1, "%s-%u", type_name, index);
> +}
> +
> static struct resources *get_resources(struct device *dev)
> {
> struct resources *res;
[snip]
> @@ -1405,6 +1483,32 @@ static int cursor_supported(void)
> return 1;
> }
>
> +static int pipe_resolve_connectors(struct pipe_arg *pipe, struct device
> *dev)
> +{
> + drmModeConnector *connector;
> + unsigned int i;
> + uint32_t id;
> + char *endp;
> +
> + for (i = 0; i < pipe->num_cons; i++) {
> + id = strtoul(pipe->cons[i], , 10);
> + if (endp == pipe->cons[i]) {
This won't have the expected behaviour for 9-pin DIN connectors, as the name
starts with a digit. You should instead test for *endp == '\0'.
> + connector = get_connector_by_name(dev, pipe->cons[i]);
> + if (!connector) {
> + fprintf(stderr, "no connector named %s\n",
> + pipe->cons[i]);
> + return -ENODEV;
> + }
> +
> + id = connector->connector_id;
> + }
> +
> + pipe->con_ids[i] = id;
> + }
> +
> + return 0;
> +}
Could update the help text in usage() to reflect the new usage ?
--
Regards,
Laurent Pinchart
[PATCH libdrm 07/11] xf86drmMode.h: Add DisplayPort MST encoder type
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:20 Thierry Reding wrote:
> From: Thierry Reding
>
> This brings xf86drmMode.h in sync with include/drm/drm_mode.h.
> Eventually we really should only have a single set of definitions rather
> than duplicating this in two files.
The purpose of these duplicate definitions is to avoid application build
breakages when compiled against an old drm.h header that doesn't include
drm_modes.h. Given that drm_modes.h has been introduced in 2.6.39 more than 6
years ago, wouldn't it be time to drop this ?
If we need to support old distributions (such as RHEL 5 for instance) shipping
kernel headers older than 2.6.39, do we still need to keep the definitions in
sync with newer kernel headers ? Build breakages would only occur when
compiling an application that makes use of the new definitions against old
kernel headers. If the distribution is stuck on <2.6.39 I doubt it will ship
applications using recent DRM features.
> Signed-off-by: Thierry Reding
> ---
> xf86drmMode.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index e70c16d437f4..70f14a1ae506 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -130,6 +130,7 @@ extern "C" {
> #define DRM_MODE_ENCODER_TVDAC 4
> #define DRM_MODE_ENCODER_VIRTUAL 5
> #define DRM_MODE_ENCODER_DSI 6
> +#define DRM_MODE_ENCODER_DPMST 7
>
> #define DRM_MODE_SUBCONNECTOR_Automatic 0
> #define DRM_MODE_SUBCONNECTOR_Unknown 0
--
Regards,
Laurent Pinchart
[PATCH libdrm 06/11] xf86drmMode.h: Use consistent padding
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:19 Thierry Reding wrote:
> From: Thierry Reding
>
> Signed-off-by: Thierry Reding
> ---
> xf86drmMode.h | 16
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/xf86drmMode.h b/xf86drmMode.h
> index 856a6bb0f569..e70c16d437f4 100644
> --- a/xf86drmMode.h
> +++ b/xf86drmMode.h
> @@ -123,13 +123,13 @@ extern "C" {
> #define DRM_MODE_DITHERING_OFF 0
> #define DRM_MODE_DITHERING_ON 1
>
> -#define DRM_MODE_ENCODER_NONE 0
> -#define DRM_MODE_ENCODER_DAC1
> -#define DRM_MODE_ENCODER_TMDS 2
> -#define DRM_MODE_ENCODER_LVDS 3
> -#define DRM_MODE_ENCODER_TVDAC 4
> +#define DRM_MODE_ENCODER_NONE0
> +#define DRM_MODE_ENCODER_DAC 1
> +#define DRM_MODE_ENCODER_TMDS2
> +#define DRM_MODE_ENCODER_LVDS3
> +#define DRM_MODE_ENCODER_TVDAC 4
> #define DRM_MODE_ENCODER_VIRTUAL 5
> -#define DRM_MODE_ENCODER_DSI 6
> +#define DRM_MODE_ENCODER_DSI 6
Nitpicking here, I would have aligned everything on the same column for every
block of #define's, but that's up to you.
>
> #define DRM_MODE_SUBCONNECTOR_Automatic 0
> #define DRM_MODE_SUBCONNECTOR_Unknown 0
> @@ -153,8 +153,8 @@ extern "C" {
> #define DRM_MODE_CONNECTOR_DisplayPort 10
> #define DRM_MODE_CONNECTOR_HDMIA11
> #define DRM_MODE_CONNECTOR_HDMIB12
> -#define DRM_MODE_CONNECTOR_TV13
> -#define DRM_MODE_CONNECTOR_eDP 14
> +#define DRM_MODE_CONNECTOR_TV 13
> +#define DRM_MODE_CONNECTOR_eDP 14
> #define DRM_MODE_CONNECTOR_VIRTUAL 15
> #define DRM_MODE_CONNECTOR_DSI 16
--
Regards,
Laurent Pinchart
[PATCH libdrm 05/11] tests: Move name tables to libutil
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:18 Thierry Reding wrote:
> From: Thierry Reding
>
> These tables are duplicated in several places, so move them into libutil
> so that they can be shared.
>
> Signed-off-by: Thierry Reding
Acked-by: Laurent Pinchart
> ---
> tests/modetest/modetest.c | 50 ++-
> tests/proptest/Makefile.am | 4 +-
> tests/proptest/proptest.c | 40 +--
> tests/util/Makefile.am | 2 +
> tests/util/kms.c | 122 ++
> tests/util/kms.h | 33
> 6 files changed, 165 insertions(+), 86 deletions(-)
> create mode 100644 tests/util/kms.c
> create mode 100644 tests/util/kms.h
>
> diff --git a/tests/modetest/modetest.c b/tests/modetest/modetest.c
> index b610956adfcb..d5fd99ebe1fd 100644
> --- a/tests/modetest/modetest.c
> +++ b/tests/modetest/modetest.c
> @@ -61,6 +61,7 @@
>
> #include "util/common.h"
> #include "util/format.h"
> +#include "util/kms.h"
> #include "util/pattern.h"
>
> #include "buffers.h"
> @@ -123,11 +124,6 @@ static inline int64_t U642I64(uint64_t val)
> return (int64_t)*((int64_t *));
> }
>
> -struct type_name {
> - int type;
> - const char *name;
> -};
> -
> #define type_name_fn(res) \
> const char * res##_str(int type) { \
> unsigned int i; \
> @@ -138,44 +134,6 @@ const char * res##_str(int type) {
> \
> return "(invalid)"; \
> }
>
> -struct type_name encoder_type_names[] = {
> - { DRM_MODE_ENCODER_NONE, "none" },
> - { DRM_MODE_ENCODER_DAC, "DAC" },
> - { DRM_MODE_ENCODER_TMDS, "TMDS" },
> - { DRM_MODE_ENCODER_LVDS, "LVDS" },
> - { DRM_MODE_ENCODER_TVDAC, "TVDAC" },
> -};
> -
> -static type_name_fn(encoder_type)
> -
> -struct type_name connector_status_names[] = {
> - { DRM_MODE_CONNECTED, "connected" },
> - { DRM_MODE_DISCONNECTED, "disconnected" },
> - { DRM_MODE_UNKNOWNCONNECTION, "unknown" },
> -};
> -
> -static type_name_fn(connector_status)
> -
> -struct type_name connector_type_names[] = {
> - { DRM_MODE_CONNECTOR_Unknown, "unknown" },
> - { DRM_MODE_CONNECTOR_VGA, "VGA" },
> - { DRM_MODE_CONNECTOR_DVII, "DVI-I" },
> - { DRM_MODE_CONNECTOR_DVID, "DVI-D" },
> - { DRM_MODE_CONNECTOR_DVIA, "DVI-A" },
> - { DRM_MODE_CONNECTOR_Composite, "composite" },
> - { DRM_MODE_CONNECTOR_SVIDEO, "s-video" },
> - { DRM_MODE_CONNECTOR_LVDS, "LVDS" },
> - { DRM_MODE_CONNECTOR_Component, "component" },
> - { DRM_MODE_CONNECTOR_9PinDIN, "9-pin DIN" },
> - { DRM_MODE_CONNECTOR_DisplayPort, "DP" },
> - { DRM_MODE_CONNECTOR_HDMIA, "HDMI-A" },
> - { DRM_MODE_CONNECTOR_HDMIB, "HDMI-B" },
> - { DRM_MODE_CONNECTOR_TV, "TV" },
> - { DRM_MODE_CONNECTOR_eDP, "eDP" },
> -};
> -
> -static type_name_fn(connector_type)
> -
> #define bit_name_fn(res) \
> const char * res##_str(int type) { \
> unsigned int i; \
> @@ -235,7 +193,7 @@ static void dump_encoders(struct device *dev)
> printf("%d\t%d\t%s\t0x%08x\t0x%08x\n",
> encoder->encoder_id,
> encoder->crtc_id,
> -encoder_type_str(encoder->encoder_type),
> +util_lookup_encoder_type_name(encoder->encoder_type),
> encoder->possible_crtcs,
> encoder->possible_clones);
> }
> @@ -379,8 +337,8 @@ static void dump_connectors(struct device *dev)
> printf("%d\t%d\t%s\t%s\t%dx%d\t\t%d\t",
> connector->connector_id,
> connector->encoder_id,
> -connector_status_str(connector->connection),
> -connector_type_str(connector->connector_type),
> +util_lookup_connector_status_name(connector->connection),
> +
> util_lookup_connector_type_name(connector->connector_type),
> connector->mmWidth, connector->mmHeight,
> connector->count_modes);
>
> diff --git a/tests/proptest/Makefile.am b/tests/proptest/Makefile.am
> index f81a3c00846b..c615489b9a92 100644
> --- a/tests/proptest/Makefile.am
> +++ b/tests/proptest/Makefile.am
> @@ -1,5 +1,6 @@
> AM_CFLAGS = \
> -I$(top_srcdir)/include/drm \
> + -I$(top_srcdir)/tests \
> -I$(top_srcdir)
>
> noinst_PROGRAMS = \
> @@ -8,4 +9,5 @@ noinst_PROGRAMS = \
> proptest_SOURCES = \
> proptest.c
> proptest_LDADD = \
> - $(top_builddir)/libdrm.la
> + $(top_builddir)/libdrm.la \
> + $(top_builddir)/tests/util/libutil.la
> diff --git a/tests/proptest/proptest.c b/tests/proptest/proptest.c
> index ee3fa408a310..b442d583d528 100644
> --- a/tests/proptest/proptest.c
> +++ b/tests/proptest/proptest.c
> @@
[PATCH libdrm 04/11] tests: Split helpers into library
Hi Thierry, On Friday 23 January 2015 17:08:17 Thierry Reding wrote: > From: Thierry Reding > > Some of the helpers, such as the pattern drawing helpers or the format > lookup helpers, have potential to be reused. Move them into a separate > library to make it easier to share them. > > Signed-off-by: Thierry Reding Acked-by: Laurent Pinchart > --- > configure.ac| 1 + > tests/Makefile.am | 2 +- > tests/modeprint/Makefile.am | 1 + > tests/modeprint/modeprint.c | 2 +- > tests/modetest/Makefile.am | 2 + > tests/modetest/buffers.c| 956 + > tests/modetest/buffers.h| 12 +- > tests/modetest/cursor.c | 4 +- > tests/modetest/modetest.c | 25 +- > tests/proptest/proptest.c | 3 +- > tests/util/Makefile.am | 19 + > tests/util/common.h | 33 ++ > tests/util/format.c | 119 ++ > tests/util/format.h | 65 +++ > tests/util/pattern.c| 870 > tests/util/pattern.h| 39 ++ > tests/vbltest/Makefile.am | 1 + > tests/vbltest/vbltest.c | 2 +- > 18 files changed, 1177 insertions(+), 979 deletions(-) > create mode 100644 tests/util/Makefile.am > create mode 100644 tests/util/common.h > create mode 100644 tests/util/format.c > create mode 100644 tests/util/format.h > create mode 100644 tests/util/pattern.c > create mode 100644 tests/util/pattern.h -- Regards, Laurent Pinchart
[PATCH libdrm 03/11] libdrm: Make indentation consistent
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:16 Thierry Reding wrote:
> From: Thierry Reding
>
> Signed-off-by: Thierry Reding
Acked-by: Laurent Pinchart
> ---
> xf86drmMode.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index 7e228b3e7aa3..3d6b9cc307d1 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -250,7 +250,7 @@ err_allocs:
> }
>
> int drmModeAddFB(int fd, uint32_t width, uint32_t height, uint8_t depth,
> - uint8_t bpp, uint32_t pitch, uint32_t bo_handle,
> + uint8_t bpp, uint32_t pitch, uint32_t bo_handle,
>uint32_t *buf_id)
> {
> struct drm_mode_fb_cmd f;
> @@ -374,7 +374,7 @@ drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId)
> }
>
> int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t bufferId,
> - uint32_t x, uint32_t y, uint32_t *connectors, int count,
> +uint32_t x, uint32_t y, uint32_t *connectors, int count,
> drmModeModeInfoPtr mode)
> {
> struct drm_mode_crtc crtc;
--
Regards,
Laurent Pinchart
[PATCH libdrm 02/11] libdrm: Remove gratuitous blank lines
Hi Thierry,
Thank you for the patch.
On Friday 23 January 2015 17:08:15 Thierry Reding wrote:
> From: Thierry Reding
>
> Usage of blank lines can be a matter of taste, of course, but for these
> we can surely all agree that they're not needed and inconsistent.
>
> Signed-off-by: Thierry Reding
Acked-by: Laurent Pinchart
> ---
> xf86drmMode.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/xf86drmMode.c b/xf86drmMode.c
> index f6e4416b88b5..7e228b3e7aa3 100644
> --- a/xf86drmMode.c
> +++ b/xf86drmMode.c
> @@ -115,7 +115,6 @@ void drmModeFreeResources(drmModeResPtr ptr)
> drmFree(ptr->connectors);
> drmFree(ptr->encoders);
> drmFree(ptr);
> -
> }
>
> void drmModeFreeFB(drmModeFBPtr ptr)
> @@ -133,7 +132,6 @@ void drmModeFreeCrtc(drmModeCrtcPtr ptr)
> return;
>
> drmFree(ptr);
> -
> }
>
> void drmModeFreeConnector(drmModeConnectorPtr ptr)
> @@ -146,7 +144,6 @@ void drmModeFreeConnector(drmModeConnectorPtr ptr)
> drmFree(ptr->props);
> drmFree(ptr->modes);
> drmFree(ptr);
> -
> }
>
> void drmModeFreeEncoder(drmModeEncoderPtr ptr)
> @@ -301,8 +298,6 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t
> height, int drmModeRmFB(int fd, uint32_t bufferId)
> {
> return DRM_IOCTL(fd, DRM_IOCTL_MODE_RMFB, );
> -
> -
> }
>
> drmModeFBPtr drmModeGetFB(int fd, uint32_t buf)
> @@ -342,7 +337,6 @@ int drmModeDirtyFB(int fd, uint32_t bufferId,
> return DRM_IOCTL(fd, DRM_IOCTL_MODE_DIRTYFB, );
> }
>
> -
> /*
> * Crtc functions
> */
> @@ -379,7 +373,6 @@ drmModeCrtcPtr drmModeGetCrtc(int fd, uint32_t crtcId)
> return r;
> }
>
> -
> int drmModeSetCrtc(int fd, uint32_t crtcId, uint32_t bufferId,
> uint32_t x, uint32_t y, uint32_t *connectors, int count,
> drmModeModeInfoPtr mode)
> @@ -594,7 +587,6 @@ int drmModeDetachMode(int fd, uint32_t connector_id,
> drmModeModeInfoPtr mode_inf return DRM_IOCTL(fd, DRM_IOCTL_MODE_DETACHMODE,
> );
> }
>
> -
> drmModePropertyPtr drmModeGetProperty(int fd, uint32_t property_id)
> {
> struct drm_mode_get_property prop;
> @@ -812,7 +804,6 @@ int drmCheckModesettingSupported(const char *busid)
> return 0;
> #endif
> return -ENOSYS;
> -
> }
>
> int drmModeCrtcGetGamma(int fd, uint32_t crtc_id, uint32_t size,
> @@ -914,7 +905,6 @@ int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t
> crtc_id, uint32_t crtc_w, uint32_t crtc_h,
> uint32_t src_x, uint32_t src_y,
> uint32_t src_w, uint32_t src_h)
> -
> {
> struct drm_mode_set_plane s;
>
> @@ -934,7 +924,6 @@ int drmModeSetPlane(int fd, uint32_t plane_id, uint32_t
> crtc_id, return DRM_IOCTL(fd, DRM_IOCTL_MODE_SETPLANE, );
> }
>
> -
> drmModePlanePtr drmModeGetPlane(int fd, uint32_t plane_id)
> {
> struct drm_mode_get_plane ovr, counts;
--
Regards,
Laurent Pinchart
[PATCH libdrm 01/11] libdrm: valgrind-clear a few more IOCTL arguments
Hi Thierry, Thank you for the patch. On Friday 23 January 2015 17:08:14 Thierry Reding wrote: > From: Thierry Reding > > Fixes a few complaints raised by valgrind when running the Tegra tests. > > Signed-off-by: Thierry Reding I agree that a fix is needed, and that this patch matches the rest of the code, so Acked-by: Laurent Pinchart However, shouldn't structures be memset to 0 unconditionally, especially considering the recent discussion regarding reserved fields that should be initialized to default values by userspace ? This can be fixed by a separate patch. > --- > xf86drmMode.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/xf86drmMode.c b/xf86drmMode.c > index 60ce3699f3e3..f6e4416b88b5 100644 > --- a/xf86drmMode.c > +++ b/xf86drmMode.c > @@ -282,6 +282,7 @@ int drmModeAddFB2(int fd, uint32_t width, uint32_t > height, struct drm_mode_fb_cmd2 f; > int ret; > > + VG_CLEAR(f); > f.width = width; > f.height = height; > f.pixel_format = pixel_format; > @@ -309,6 +310,7 @@ drmModeFBPtr drmModeGetFB(int fd, uint32_t buf) > struct drm_mode_fb_cmd info; > drmModeFBPtr r; > > + VG_CLEAR(info); > info.fb_id = buf; > > if (drmIoctl(fd, DRM_IOCTL_MODE_GETFB, )) -- Regards, Laurent Pinchart
