[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
2015-03-31 14:15 GMT-03:00 Todd Previte : > For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source > device must attempt at least 7 times to read the EDID when it receives an > I2C defer. The normal DRM code makes only 7 retries, regardless of whether > or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails > since there are native defers interspersed with the I2C defers which > results in less than 7 EDID read attempts. > > The solution is to decrement the retry counter when an I2C DEFER is returned > such that another read attempt will be made. This situation should normally > only occur in compliance testing, however, as a worse case real-world > scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers) > for a single transaction to complete. The net result is a slightly slower > response to an EDID read that shouldn't significantly impact overall > performance. > > Signed-off-by: Todd Previte > Cc: dri-devel at lists.freedesktop.org > --- > drivers/gpu/drm/drm_dp_helper.c | 5 + > 1 file changed, 5 insertions(+) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 79968e3..0539758 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, > struct drm_dp_aux_msg *msg) > case DP_AUX_I2C_REPLY_DEFER: > DRM_DEBUG_KMS("I2C defer\n"); > aux->i2c_defer_count++; > + /* DP Compliance Test 4.2.2.5 Requirement: > +* Must have at least 7 retries for I2C defers on the > +* transaction to pass this test > +*/ > + retry--; I wouldn't be surprised if someone discovers a monitor or some sort of dongle that keeps sending I2C defer errors forever, keeping us in an infinite loop. Shouldn't we count each error in separate? Or maybe just loop up to 14 times, in case that doesn't violate any spec (I didn't check)? > usleep_range(400, 500); > continue; > > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel -- Paulo Zanoni
[PATCH -v3 00/11] drm/exynos: Add atomic modesetting support
On 2015ë 04ì 04ì¼ 03:09, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Here goes the full support for atomic modesetting on exynos. I've > split the patches in the various phases of atomic support. > > These patches sits on top of the clean up patches I've sent yesterday > to this mailing list[1]. > > v2: fixes comments by Joonyoung > - remove unused var in patch 09 > - use ->disable instead of outdated ->dpms in hdmi code > - remove WARN_ON from crtc enable/disable > > v3: fixes comment by Joonyoung > - move the removal of drm_helper_disable_unused_functions() to > separated patch With this patch series, Kernel booting is halted at end of kernel booting. I tested this patch series on Trats2 board based on Exynos4412 SoC. Below is a part of full booting logs, which was halted, [1.992015] exynos-drm-ipp exynos-drm-ipp: drm ipp registered successfully. [1.993009] exynos-drm exynos-drm: bound exynos-drm-vidi (ops vidi_component_ops) [1.993036] exynos-drm exynos-drm: bound 11c0.fimd (ops fimd_component_ops) [1.993385] exynos-drm exynos-drm: bound 11c8.dsi (ops exynos_dsi_component_ops) [1.993390] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). [1.993393] [drm] No driver support for vblank timestamp query. [1.993442] [drm] Initialized exynos 1.0.0 20110530 on minor 0 [2.043358] WARNING: CPU: 2 PID: 1209 at drivers/clk/clk.c:898 clk_unprepare+0x24/0x2c() [2.051412] Modules linked in: [2.054422] CPU: 2 PID: 1209 Comm: kworker/2:1 Tainted: GW 4.0.0-rc6-00526-gc49d7de-dirty #1278 [2.064337] Hardware name: SAMSUNG EXYNOS (Flattened Device Tree) [2.070428] Workqueue: pm pm_runtime_work> After that, I tested it again without FIMD and the booting is ok. So I guess that this atomic feature has a bug to FIMD driver. Thanks, Inki Dae > > Gustavo > --- > > Gustavo Padovan (11): > drm/exynos: atomic phase 1: use drm_plane_helper_update() > drm/exynos: atomic phase 1: use drm_plane_helper_disable() > drm/exynos: atomic phase 1: add .mode_set_nofb() callback > drm/exynos: atomic phase 2: wire up state reset(), duplicate() and > destroy() > drm/exynos: atomic phase 2: keep track of framebuffer pointer > drm/exynos: atomic phase 3: atomic updates of planes > drm/exynos: atomic phase 3: use atomic .set_config helper > drm/exynos: atomic phase 3: convert page flips > drm/exynos: remove exported functions from exynos_drm_plane > drm/exynos: don't disable unused functions at init > drm/exynos: atomic dpms support > > drivers/gpu/drm/bridge/ptn3460.c | 4 + > drivers/gpu/drm/exynos/exynos_dp_core.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_connector.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 226 > -- > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c | 2 + > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 6 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 +-- > drivers/gpu/drm/exynos/exynos_drm_fb.c| 12 +- > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 3 - > drivers/gpu/drm/exynos/exynos_drm_plane.c | 113 +++-- > drivers/gpu/drm/exynos/exynos_drm_plane.h | 11 -- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 6 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 10 +- > 15 files changed, 187 insertions(+), 255 deletions(-) >
[PATCH 3/3] drm/exynos: mixer: add 2x scaling to mixer_graph_buffer
Hello Emil, Emil Velikov wrote: > Hi Tobias, > > On 1 April 2015 at 14:29, Tobias Jakobi > wrote: >> diff --git a/drivers/gpu/drm/exynos/exynos_mixer.c >> b/drivers/gpu/drm/exynos/exynos_mixer.c >> index 5ab0e32..6822b36 100644 >> --- a/drivers/gpu/drm/exynos/exynos_mixer.c >> +++ b/drivers/gpu/drm/exynos/exynos_mixer.c > >> @@ -528,9 +552,8 @@ static void mixer_graph_buffer(struct mixer_context >> *ctx, int win) >> fmt = ARGB; >> } >> >> - /* 2x scaling feature */ >> - x_ratio = 0; >> - y_ratio = 0; >> + /* check if mixer supports requested scaling setup */ >> + if (mixer_setup_scale(plane, _ratio, _ratio)) return; >> > Having return on the same line as the if statement will make > checkpatch.pl unhappy :-( right, I'm going to fix this and resend the series. With best wishes, Tobias
[PATCH -v4 0/8] drm/exynos: clean up patches (preparing for atomic)
On 2015ë 04ì 02ì¼ 01:02, Gustavo Padovan wrote: > From: Gustavo Padovan > > Hi, > > Here goes some clean ups to the exynos drivers. The main clean ups is > the presetting and zpos making the property immutable and the removal > of *_win_data structures. > > v2 contains a extra patch to fix alpha setting for planes in fimd, so > now fimd works fine even after the removal of struct fimd_win_data. > > v3 removes a leftover var in the first commit and address the comment from > Joonyoung about checking the return value of exynos_plane_init() > > v4 rebases on top of Daniel Stone patch, currently only applied to > exynos-drm-fixes Applied. Thanks, Inki Dae > > Gustavo Padovan (7): > drm/exynos: fimd: fix alpha setting for XR24 pixel format > drm/exynos: remove unused exynos_crtc->win_enable() callback > drm/exynos: remove struct *_win_data abstraction on planes > drm/exynos: preset zpos value for overlay planes > drm/exynos: make zpos property immutable > drm/exynos: remove exynos_plane_destroy() > drm/exynos: remove leftover functions declarations > > Mandeep Singh Baines (1): > drm/exynos: track vblank events on a per crtc basis > > drivers/gpu/drm/exynos/exynos7_drm_decon.c | 178 -- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 101 ++--- > drivers/gpu/drm/exynos/exynos_drm_crtc.h | 7 +- > drivers/gpu/drm/exynos/exynos_drm_drv.c| 27 > drivers/gpu/drm/exynos/exynos_drm_drv.h| 20 +-- > drivers/gpu/drm/exynos/exynos_drm_fimd.c | 230 > - > drivers/gpu/drm/exynos/exynos_drm_plane.c | 66 ++--- > drivers/gpu/drm/exynos/exynos_drm_plane.h | 7 +- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 136 + > drivers/gpu/drm/exynos/exynos_mixer.c | 221 ++- > include/video/samsung_fimd.h | 5 + > 11 files changed, 345 insertions(+), 653 deletions(-) >
[PATCH 07/11] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source device must attempt at least 7 times to read the EDID when it receives an I2C defer. The normal DRM code makes only 7 retries, regardless of whether or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails since there are native defers interspersed with the I2C defers which results in less than 7 EDID read attempts. The solution is to decrement the retry counter when an I2C DEFER is returned such that another read attempt will be made. This situation should normally only occur in compliance testing, however, as a worse case real-world scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers) for a single transaction to complete. The net result is a slightly slower response to an EDID read that shouldn't significantly impact overall performance. V2: - Added a check on the number of I2C Defers to limit the number of times that the retries variable will be decremented. This is to address review feedback regarding possible infinite loops from misbehaving sink devices. Signed-off-by: Todd Previte Cc: dri-devel at lists.freedesktop.org --- drivers/gpu/drm/drm_dp_helper.c | 6 ++ 1 file changed, 6 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c index 79968e3..23025cf 100644 --- a/drivers/gpu/drm/drm_dp_helper.c +++ b/drivers/gpu/drm/drm_dp_helper.c @@ -469,6 +469,12 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, struct drm_dp_aux_msg *msg) case DP_AUX_I2C_REPLY_DEFER: DRM_DEBUG_KMS("I2C defer\n"); aux->i2c_defer_count++; + /* DP Compliance Test 4.2.2.5 Requirement: +* Must have at least 7 retries for I2C defers on the +* transaction to pass this test +*/ + if (aux->i2c_defer_count < 8) + retry--; usleep_range(400, 500); continue; -- 1.9.1
[PATCH 7/9] drm/i915: Fix for DP CTS test 4.2.2.5 - I2C DEFER handling
On 4/6/15 5:05 PM, Paulo Zanoni wrote: > 2015-03-31 14:15 GMT-03:00 Todd Previte : >> For test 4.2.2.5 to pass per the Link CTS Core 1.2 rev1.1 spec, the source >> device must attempt at least 7 times to read the EDID when it receives an >> I2C defer. The normal DRM code makes only 7 retries, regardless of whether >> or not the response is a native defer or an I2C defer. Test 4.2.2.5 fails >> since there are native defers interspersed with the I2C defers which >> results in less than 7 EDID read attempts. >> >> The solution is to decrement the retry counter when an I2C DEFER is returned >> such that another read attempt will be made. This situation should normally >> only occur in compliance testing, however, as a worse case real-world >> scenario, it would result in 13 attempts ( 6 native defers, 7 I2C defers) >> for a single transaction to complete. The net result is a slightly slower >> response to an EDID read that shouldn't significantly impact overall >> performance. >> >> Signed-off-by: Todd Previte >> Cc: dri-devel at lists.freedesktop.org >> --- >> drivers/gpu/drm/drm_dp_helper.c | 5 + >> 1 file changed, 5 insertions(+) >> >> diff --git a/drivers/gpu/drm/drm_dp_helper.c >> b/drivers/gpu/drm/drm_dp_helper.c >> index 79968e3..0539758 100644 >> --- a/drivers/gpu/drm/drm_dp_helper.c >> +++ b/drivers/gpu/drm/drm_dp_helper.c >> @@ -469,6 +469,11 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, >> struct drm_dp_aux_msg *msg) >> case DP_AUX_I2C_REPLY_DEFER: >> DRM_DEBUG_KMS("I2C defer\n"); >> aux->i2c_defer_count++; >> + /* DP Compliance Test 4.2.2.5 Requirement: >> +* Must have at least 7 retries for I2C defers on the >> +* transaction to pass this test >> +*/ >> + retry--; > I wouldn't be surprised if someone discovers a monitor or some sort of > dongle that keeps sending I2C defer errors forever, keeping us in an > infinite loop. Shouldn't we count each error in separate? Or maybe > just loop up to 14 times, in case that doesn't violate any spec (I > didn't check)? I think the safest thing to do would be to put a failsafe on the i2c_defer_counter. That would ensure that the compliance test gets its 7 retries and that if we do encounter a misbehaving device, the driver won't let the unending defers cause an infinite loop. Updated patch shortly. >> usleep_range(400, 500); >> continue; >> >> -- >> 1.9.1 >> >> ___ >> dri-devel mailing list >> dri-devel at lists.freedesktop.org >> http://lists.freedesktop.org/mailman/listinfo/dri-devel > >
[Intel-gfx] [PATCH 9/9] drm: Fix the 'native defer' message in drm_dp_i2c_do_msg()
2015-03-31 14:15 GMT-03:00 Todd Previte : > The debug message is missing a newline at the end and it makes the > logs hard to read when a device defers a lot. Simple 2-character fix > adds the newline at the end. > > Signed-off-by: Todd Previte > Cc: dri-devel at lists.freedesktop.org Why in some logs there is in fact a newline, such as here: https://bugs.freedesktop.org/attachment.cgi?id=110049 ? Anyway, it looks correct, so: Reviewed-by: Paulo Zanoni > --- > drivers/gpu/drm/drm_dp_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c > index 0539758..281bb67 100644 > --- a/drivers/gpu/drm/drm_dp_helper.c > +++ b/drivers/gpu/drm/drm_dp_helper.c > @@ -433,7 +433,7 @@ static int drm_dp_i2c_do_msg(struct drm_dp_aux *aux, > struct drm_dp_aux_msg *msg) > return -EREMOTEIO; > > case DP_AUX_NATIVE_REPLY_DEFER: > - DRM_DEBUG_KMS("native defer"); > + DRM_DEBUG_KMS("native defer\n"); > /* > * We could check for I2C bit rate capabilities and if > * available adjust this interval. We could also be > -- > 1.9.1 > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Paulo Zanoni
gma500_gfx: spread spectrum clocking?
emgd had an option to enable spread spectrum clocking on LVDS. The documentation is vague but the setting that works is: Option "ALL/1/Port/4/Attr/43""7" Anyone have any idea how to set this with gma500_gfx or if it doesn't support it, how to put the hardware in this mode? Thanks, George McCollister
[PATCH -v3 11/11] drm/exynos: atomic dpms support
Hi Inki, 2015-04-05 Inki Dae : > Hi, > > 2015-04-04 3:09 GMT+09:00 Gustavo Padovan : > > From: Gustavo Padovan > > > > Run dpms operations through the atomic intefaces. This basically removes > > the .dpms() callback from econders and crtcs and use .disable() and > > .enable() to turn the crtc on and off. > > > > v2: Address comments by Joonyoung: > > - make hdmi code call ->disable() instead of ->dpms() > > - do not use WARN_ON on crtc enable/disable > > > > Signed-off-by: Gustavo Padovan > > --- > > drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 99 > > +++ > > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- > > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++-- > > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- > > 9 files changed, 70 insertions(+), 76 deletions(-) > > > > ...snip... > > > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > > b/drivers/gpu/drm/exynos/exynos_hdmi.c > > index 5b597bc..2ea7d01 100644 > > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > > @@ -1051,7 +1051,7 @@ static void hdmi_connector_destroy(struct > > drm_connector *connector) > > } > > > > static struct drm_connector_funcs hdmi_connector_funcs = { > > - .dpms = drm_helper_connector_dpms, > > + .dpms = drm_atomic_helper_connector_dpms, > > .fill_modes = drm_helper_probe_single_connector_modes, > > .detect = hdmi_detect, > > .destroy = hdmi_connector_destroy, > > @@ -2127,8 +2127,8 @@ static void hdmi_dpms(struct exynos_drm_display > > *display, int mode) > > */ > > if (crtc) > > funcs = crtc->helper_private; > > - if (funcs && funcs->dpms) > > - (*funcs->dpms)(crtc, mode); > > + if (funcs && funcs->disable) > > + (*funcs->disable)(crtc, mode); > > This patch makes funcs->disable callback to be called instead of > funcs->dpms callback. However, funcs->disable callback isn't required > for second argument so the build is failed like below, > > drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms': > drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments > to function 'funcs->disable' > > Please, keep in mind that you should build it and at least have a > basic test before posting. Sure, I think this happened because I've been using exynos_defconfig to test my kernels and HDMI is not there. Maybe should we add the EXYNOS_DRM_HDMI to defconfig? What do you think? Gustavo
[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock
https://bugs.freedesktop.org/show_bug.cgi?id=89734 --- Comment #17 from Daniel Stone --- (In reply to Christian König from comment #16) > (In reply to poub365-bugzilla from comment #15) > > The program 'dolphin-emu' received an X Window System error. > > This probably reflects a bug in the program. > > The error was 'BadWindow (invalid Window parameter)'. > > (Details: serial 8835 error_code 3 request_code 38 minor_code 0) > > (Note to programmers: normally, X errors are reported asynchronously; > >that is, you will receive the error a while after causing it. > >To debug your program, run it with the --sync command line > >option to change this behavior. You can then get a meaningful > >backtrace from your debugger if you break on the gdk_x_error() function.) > > terminate called without an active exception > > Abandon (core dumped) > > > > I attach my dmesg and xorg.log just in case. > > That's a completely different issue, not even sure if it is a driver problem > at all. It's not - request #38 is XQueryPointer, which GL drivers don't do. -- 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/20150406/7f5b2731/attachment.html>
[Bug 89734] GL_AMD_pinned_memory extension causing a kernel hardlock
https://bugs.freedesktop.org/show_bug.cgi?id=89734 --- Comment #16 from Christian König --- (In reply to poub365-bugzilla from comment #15) > Created attachment 114842 [details] > dmesg with patch > > Very strange: I booted on the patch kernel today to get a Xlog. No > flickering on desktop neither on fullscreen game. I didn't upgrade any > component since last time. Dolphin is working fine from my quick test. Mhm, could be an uninitialized variable or something like this. Not sure off hand. But if it works fine now it's unlikely that this is a driver problem. > > So, I can now exit dolphin without freezing. I get this message on the > console: > > The program 'dolphin-emu' received an X Window System error. > This probably reflects a bug in the program. > The error was 'BadWindow (invalid Window parameter)'. > (Details: serial 8835 error_code 3 request_code 38 minor_code 0) > (Note to programmers: normally, X errors are reported asynchronously; >that is, you will receive the error a while after causing it. >To debug your program, run it with the --sync command line >option to change this behavior. You can then get a meaningful >backtrace from your debugger if you break on the gdk_x_error() function.) > terminate called without an active exception > Abandon (core dumped) > > I attach my dmesg and xorg.log just in case. That's a completely different issue, not even sure if it is a driver problem at all. -- 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/20150406/1b7f6607/attachment.html>
[PATCH v2 1/4] break kconfig dependency loop
On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: > I think part of the problem is that "select" is often used not as > documented [1] but rather as "show my config in menuconfig for > convenience even if my dependency is not met, and select the dependency > even though I know it can screw up the dependency chain". Perhaps people use select because it offers, given the problem they face, a reasonable way to make the kconfig tools generate a sensible .config. It helps them to spend less time fiddling with Kconfig files. And they expect that it helps others to configure their build more easily, as it might save those others some work. > In the big picture, it feels like menuconfig needs a way to display > items whose dependencies are not met, and a way to recursively enable > said items and all their dependencies when told. How could that work its way through (multiple levels of) things like: depends on FOO || (BAZ && BAR) > This would reduce the > resistance to sticking with "select" when clearly "depends" is what's > meant. I had drafted a rather verbose response to this. But I think I'm not really sure what you're saying here, probably because "select" and "depends on" are rather different. How would you know that the actual intention was to use "depends on"? Paul Bolle
[Bug 89916] DRI PRIME renders only black window
https://bugs.freedesktop.org/show_bug.cgi?id=89916 Bug ID: 89916 Summary: DRI PRIME renders only black window Product: DRI Version: DRI 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: towo at siduction.org a have a Lenovo Notebook which contains a FX-7500. There are 2 graphics devices in: root at lenovo-nb:/home/towo# lspci | egrep -i "displ|vga" 00:01.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Kaveri [Radeon R6/R7 Graphics] 01:00.0 Display controller: Advanced Micro Devices, Inc. [AMD/ATI] Jet PRO [Radeon R5 M230] (rev ff) The system is using the Kaveri graphics. towo:lenovo-nb> glxinfo | grep "OpenGL renderer string" OpenGL renderer string: Gallium 0.4 on AMD KAVERI towo:lenovo-nb> xrandr --listproviders Providers: number : 2 Provider 0: id: 0x86 cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 4 outputs: 3 associated providers: 1 name:radeon Provider 1: id: 0x4f cap: 0xf, Source Output, Sink Output, Source Offload, Sink Offload crtcs: 0 outputs: 0 associated providers: 1 name:radeon both devices are listed. xrandr --setprovideroffloadsink 0x4f 0x86 towo:lenovo-nb> DRI_PRIME=1 glxinfo | grep "renderer string" OpenGL renderer string: Gallium 0.4 on AMD HAINAN seems to work correct. DRI_PRIME=1 glxgears shows only a black window, but the fps are shown in the terminal, i start from. towo:lenovo-nb> LIBGL_DEBUG=verbose DRI_PRIME=1 glxgears libGL: screen 0 does not appear to be DRI3 capable libGL: pci id for fd 4: 1002:6665, driver radeonsi libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/tls/radeonsi_dri.so libGL: OpenDriver: trying /usr/lib/x86_64-linux-gnu/dri/radeonsi_dri.so Running synchronized to the vertical refresh. The framerate should be approximately the same as the monitor refresh rate. 8793 frames in 5.0 seconds = 1758.569 FPS doesn't even give any error, but the windows stayes black. I use xfce 4.12 and have tryed 3 different compositors, with all i get the same black window. Resizing the windows does not help (that i read in many bug reports). kernel is 4.0.0-rc6, xserver is 1.16.4, mesa is 10.6-git and radeon driver is 7.5.0 There are zero errors in the terminal or logfiles. -- 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/20150406/bed530e3/attachment.html>
[PATCH v2 1/4] break kconfig dependency loop
Em Mon, 06 Apr 2015 11:50:21 +0200 Paul Bolle escreveu: > On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote: > > I think part of the problem is that "select" is often used not as > > documented [1] but rather as "show my config in menuconfig for > > convenience even if my dependency is not met, and select the dependency > > even though I know it can screw up the dependency chain". > > Perhaps people use select because it offers, given the problem they > face, a reasonable way to make the kconfig tools generate a > sensible .config. It helps them to spend less time fiddling with Kconfig > files. And they expect that it helps others to configure their build > more easily, as it might save those others some work. At least on media, the main usage of select is to handle complex hardware where lots of drivers are needed in order to have support for all boards supported by a given board. On a practical example, let's take a look at em28xx driver. This is a bridge driver for media boards. It supports ~100 different boards. Each board may have different tuners, different analog TV demods, different digital TV demods, eeproms attached into one of its I2C buses. As this is an USB stick, the normal user will never know what are the other components of the board without some hard work (by opening the USB stick by seeking for the information at the Internet until he discovers all the components). Even after knowing the hardware components, he has to figure out what drivers implement support for each component. So, for the normal user, we offer a way for the user to select all possible combinations via MEDIA_SUBDRV_AUTOSELECT. This way, he'll know for sure that all boards supported by em28xx will be available. For those that would embedded em28xx on some hardware (like a TV PVR box), he can disable such option and manually select the specific components his hardware uses. For obvious reasons, we recommend distros to always enable MEDIA_SUBDRV_AUTOSELECT. So, yes, select saves a lot of work to configure the build what they want on an easy and sane way. That's said, while it would be possible to convert select into depends on, the result would be really ugly, and very hard to be maintained, as I2C drivers that don't actually depend on the bridge drivers would need a fake depends on list: config DVB_MB86A20S tristate "Fujitsu mb86a20s" # real dependency chain depends on DVB_CORE && I2C # fake dependency chain depends on (!MEDIA_SUBDRV_AUTOSELECT || CONFIG_VIDEO_CX23885_DVB || CONFIG_VIDEO_CX231XX_DVB || CONFIG_VIDEO_EM28xx_DVB) I got here an easy example of an ISDB-T driver, with is not used on many boards. There are other I2C drivers that are used by almost all media drivers, with would result on a very complex fake dependency chain. The worse thing with such ugly fake dependency chain is that people adding a new driver (or support for a new board) would need to remember to dig into drivers that weren't touched, adding new stuff on their Kconfig. > > In the big picture, it feels like menuconfig needs a way to display > > items whose dependencies are not met, and a way to recursively enable > > said items and all their dependencies when told. I believe so. > How could that work its way through (multiple levels of) things like: > depends on FOO || (BAZ && BAR) At least for our typical use case, the dependency chain should not have things like the above, as we use this mainly for I2C drivers, and the bridge drivers also depend on I2C. I would say that, if Kconfig adds a recursive select implementation, such implementation should: - stop recursion if the depends condition was met; - if the depends condition is unmet and has two or more possible options to satisfy (like on your above example), it should prompt the user about what option it would want. If it can't do it (for example, for a "silent" type of config, where it shouldn't be expected any userspace interaction), it should print a warning and not enable the driver. Granted, this is easier said than done. We have this problem mapped for a long time, but none was brave enough (or had enough time) to actually try to implement something like that. So, what we generally do, as a workaround, is to try to simplify the Kconfig stuff to avoid complex use cases. We do that by adding fake dependencies to drivers that might require another driver for some board to work. For example, several USB media drivers now depends on I2C_MUX just because a few of the possible drivers it may need should select I2C_MUX. Btw, I2C_MUX is an optional feature of the I2C core. There's no way for a normal user to know if a driver would need such feature or not, as it basically depends on how the device was internally wired and if the Kernel driver would use it (older drivers have their own solution without using the I2C_MUX new way). There are a few other such options at the I2C sub-system. All of them depends on I2C
[PATCH] wayland-drm: add a description for every item.
On Wed, 25 Mar 2015 13:10:24 +0100 Emmanuel Gil Peyrot wrote: > This makes the generated protocol headers a lot more readable. > --- > src/egl/wayland/wayland-drm/wayland-drm.xml | 159 > +--- > 1 file changed, 100 insertions(+), 59 deletions(-) > > diff --git a/src/egl/wayland/wayland-drm/wayland-drm.xml > b/src/egl/wayland/wayland-drm/wayland-drm.xml > index 5e64622..7cf06d9 100644 > --- a/src/egl/wayland/wayland-drm/wayland-drm.xml > +++ b/src/egl/wayland/wayland-drm/wayland-drm.xml > @@ -27,19 +27,31 @@ > THIS SOFTWARE. > > > - > > + > + This object is created by the server and published using the > + display's global event. Hi, you can say that a lot shorter: "This is a global object interface." But you could also say more: - is this a singleton? - this is a detail of an EGL implementation - this is specific to Mesa, an internal implementation detail that no-one outside Mesa is supposed to access. > + > + > > - > - > - > + > +These errors can be emitted in response to wl_drm requests. That's obvious, isn't it? > + > + + summary="authentication failure"/> > + + summary="buffer format is not supported"/> > + + summary="invalid name for buffer creation"/> Ok. > > > > - > + > +The drm format codes match the #defines in drm_fourcc.h. > + > +The formats actually supported by the compositor will be > +reported by the format event. > + Ok. > > > > @@ -100,84 +112,113 @@ > > > > - > > - > + > +Call this request with the magic received from drmGetMagic(). > + > +It will be passed on to the drmAuthMagic() or > +DRIAuthConnection() call. This authentication must be > +completed before create_buffer could be used. > + > + Ok. > > > - > > - > - > - > - > - > - > + > +Create a wayland buffer for the named DRM buffer. > + > +The DRM surface must have a name using the flink ioctl. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + Would be much more explicit to say that is a flink name, not just any freely chosen unique number. > + > + Units? > + Units? Without specifying the units, you are not really adding any information here. > + > > > - > > - > - > - > - > - > - > - > - > - > - > - > + > +Create a wayland buffer for the named planar DRM buffer. > + > +The DRM surface must have a name using the flink ioctl. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + Flink name. > + > + > + > + > + > + > + > + > + Units? > > > - > > - > + > +Notification of the path of the drm device which is used by the > +server. > + > +The client should use this device for creating local buffers. > +Only buffers created from this device should be be passed to > +the server using this drm object's create_buffer request. > + > + Ok. > > > > - > + > +Informs the client about a valid pixel format that can be used > +for buffers. > + > + > > > - > - > + > + > +Raised if the authenticate request succeeded. > + > + Ok. > > > - > -Bitmask of capabilities. > + > +Lists the available capabilities the server can expose. You lost the most important word of the description: "bitmask". It tells how to add new values to this enum. > > > > > > - > + > +Bitmask of capabilities supported by the server. > + > + Ok. Might add "see wl_drm_capability". > > > > > - > > - > - > - > - > - > - > - > - > - > - > - > + > +Create a wayland buffer for the prime fd. > + > +Use for regular and planar buffers. Pass 0 for offset and > +stride for unused planes. > + > + + summary="wl_buffer assigned to this drm buffer"/> > + I'm not really sure what a "prime fd" is, care to explain it in the description? Is it a dmabuf fd? Any additional semantics or constraints? > + > + > + > + > + > + > + > + > + > > > I don't mind if you don't add the extra information I asked for. So, if you put the "bitmask" back, then this would be: Revieved-by: Pekka Paalanen Thanks, pq PS. the proper mailing lists
of_parse_phandle: "could not find phandle"
On 04/05/2015 04:14 PM, Steve Longerbeam wrote: > Hi all, > > If --strip-disabled option is passed to dtc, of_parse_phandle() emits > this error message for disabled nodes. > NM, I mistakenly thought the strip-disabled patch was merged, it isn't. Steve
Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
On 04/05/15 11:33, randyf at sibernet.com wrote: > > > On Sun, 5 Apr 2015, Emil Velikov wrote: > >>> Note that the move of KMS drivers to this repo is recent, so there >>> is little >>> history of their evolution. >>> >> Right, so things are a few newer than I thought, but still a bit off >> from upstream drm. Not too shocking though considering the amount of >> work that goes in there ;-) > > It is a bit overwhelming, so I (currently) tend to scan this list > irregularly, and look for some source snapshot for porting reference. > > >> The thing that struck me is that every drm driver comes with its own >> version of core drm. Not critisizing, just a bit unusual. > > So technically, only one driver has it's own version, and that is > mostly driven by a lack of hardware to verify it continues to work as > drm changes (and is slated for removal as the hardware is obsolete and > unavailable). > > With (currently) only one other drm driver, it would appear that the > drm core is unique to it (and to some extent it is), but the evolution > would be to be towards a common drm. > > >>> >>> AFAICT, we aren't that bad. And where we divert is probably more >>> driven >>> by our lack of knowlege at the time than the ability to properly >>> converge, >>> but I have lots of ground to cover before I can properly resolve the >>> differences. >>> >> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe >> not all places are updated/ported to KMS ? Not a big deal though. >> > > We're hopeful that this will change in the near future (we have > someone working on a radeon KMS port, which is expected to use a > common drm). > > >>> >>> For the most part, I have no problem with killing off any legacy >>> layers >>> that should go, as we will catch up (we do have the ability to at least >>> offer a working frozen solution in the intrim). At least in the >>> near term, >>> there are bodies actively working on getting the above driver source >>> in sync >>> with what the community has. >>> >> Great - glad to hear. Meanwhile I've noticed a few workarounds for >> libdrm in the hg repo: >> - Force use of GCC and GNU make. >> - Disabled tests. >> >> If you can provide some more information that would be appreciated. >> Wouldn't mind squashing some bugs :-) > IIRC, we had issues with getting drm.7 without using GNU make. And the build of libdrm_radeon was failing without using gcc. I'll revert back to Studio and get you the failures since its been a while having made the switch. We had disabled tests because of parfait failures which is part of our build process. But I think we should be able to enable it now since we have an updated version of parfait that we are building with. Thanks Niveditha
[PATCH -v3 11/11] drm/exynos: atomic dpms support
Hi, 2015-04-04 3:09 GMT+09:00 Gustavo Padovan : > From: Gustavo Padovan > > Run dpms operations through the atomic intefaces. This basically removes > the .dpms() callback from econders and crtcs and use .disable() and > .enable() to turn the crtc on and off. > > v2: Address comments by Joonyoung: > - make hdmi code call ->disable() instead of ->dpms() > - do not use WARN_ON on crtc enable/disable > > Signed-off-by: Gustavo Padovan > --- > drivers/gpu/drm/exynos/exynos_dp_core.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_connector.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_crtc.c | 99 > +++ > drivers/gpu/drm/exynos/exynos_drm_dpi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_drv.h | 4 +- > drivers/gpu/drm/exynos/exynos_drm_dsi.c | 2 +- > drivers/gpu/drm/exynos/exynos_drm_encoder.c | 27 ++-- > drivers/gpu/drm/exynos/exynos_drm_vidi.c | 2 +- > drivers/gpu/drm/exynos/exynos_hdmi.c | 6 +- > 9 files changed, 70 insertions(+), 76 deletions(-) > ...snip... > diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c > b/drivers/gpu/drm/exynos/exynos_hdmi.c > index 5b597bc..2ea7d01 100644 > --- a/drivers/gpu/drm/exynos/exynos_hdmi.c > +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c > @@ -1051,7 +1051,7 @@ static void hdmi_connector_destroy(struct drm_connector > *connector) > } > > static struct drm_connector_funcs hdmi_connector_funcs = { > - .dpms = drm_helper_connector_dpms, > + .dpms = drm_atomic_helper_connector_dpms, > .fill_modes = drm_helper_probe_single_connector_modes, > .detect = hdmi_detect, > .destroy = hdmi_connector_destroy, > @@ -2127,8 +2127,8 @@ static void hdmi_dpms(struct exynos_drm_display > *display, int mode) > */ > if (crtc) > funcs = crtc->helper_private; > - if (funcs && funcs->dpms) > - (*funcs->dpms)(crtc, mode); > + if (funcs && funcs->disable) > + (*funcs->disable)(crtc, mode); This patch makes funcs->disable callback to be called instead of funcs->dpms callback. However, funcs->disable callback isn't required for second argument so the build is failed like below, drivers/gpu/drm/exynos/exynos_hdmi.c: In function 'hdmi_dpms': drivers/gpu/drm/exynos/exynos_hdmi.c:2131:4: error: too many arguments to function 'funcs->disable' Please, keep in mind that you should build it and at least have a basic test before posting. Thanks, Inki Dae > > hdmi_poweroff(hdata); > break; > -- > 2.1.0 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel