[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #12 from Alex Deucher --- looks like https://bugs.freedesktop.org/show_bug.cgi?id=84500 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #11 from Michael Mair-Keimberger --- Created attachment 155841 --> https://bugzilla.kernel.org/attachment.cgi?id=155841&action=edit dmesg output Don't know if this helps but i just saw that i got strange (?) output in dmesg. This output showed up about 20min after i made that benchmark mentioned before (mesa-10.3.2/kernel-3.18rc1). As far as i can remember i didn't do anything specific that moment - just internet surfing. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #206 from Aaron B --- I believe Firefox and Chromium both suffer from the same issue myself, we've been treating it that way at least, and Firefox users have never reported any changes different with patches and updates, so I believe the same issue is being talked about as with Chromium. I think it has to do with video being sent to the GPU at all, which with RadeonSI and any modern browsers, any accelerated browser probably will have the same problems. -- 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/20141029/b12bb0c0/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #205 from agapito --- (In reply to Alex Deucher from comment #204) > crash what do you mean? Segfault? System hang? GPU hang? GPU page fault? > Something else? My bug is not Chromium related. 4 months ago, my browser was Firefox and i had the same bug. Always is the same behaviour. Sometimes with videos, or games, flash content... It´s totally random. I think it happens often when I click anywhere or i resize a windows with vdpau content, then my system is freezed 5 seconds (I can move the mouse, but the windows or programs are not responding) after 5 seconds, my screen shows garbage like this: https://bugs.freedesktop.org/attachment.cgi?id=101226 or my monitor turns off completely. Sometimes i can reboot with reisub, sometimes i need a hard reset. Some months ago i posted a picture of my dmesg output https://bugs.freedesktop.org/attachment.cgi?id=104145 -- 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/20141029/9cd30802/attachment.html>
[Bug 85596] SB is used only after GPR check / GPR max is not dynamic
https://bugs.freedesktop.org/show_bug.cgi?id=85596 --- Comment #2 from Vadim Girlin --- (In reply to Lauri Kasanen from comment #0) > Many big shaders that currently fail with > r600_shader_select - Failed to build shader variant (type=1) -12 > r600_shader_from_tgsi - GPR limit exceeded - shader requires foo registers > > would actually work if the GPR check was moved to after SB, as SB reduces > the GPR usage quite nicely. > > Another thing is that 128 is the lowest common denominator, and many cards > have 192 or 256, which could be checked with the radeon_info ioctl. As Alex said, ISA encoding doesn't allow to address more than 128 registers in the instructions. IIRC we also by default reserve 4 GPRs as temporary (they are not preserved between ALU clauses), so the actual limit is 124 (or even 120?). It's also the reason why we can't simply move the GPR check, the shader is passed from TGSI translator to SB in the ISA encoding which can't represent the code that uses more than 128 registers. If anyone would like to revive a direct TGSI->SB translator that solves the problem, here is the branch: http://cgit.freedesktop.org/~vadimg/mesa/log/?h=wip-sb-tgsi There were no piglit regressions with that branch on evergreen when it was implemented, but now I suspect it's a bit outdated. -- 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/20141029/dc9f4468/attachment-0001.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #204 from Alex Deucher --- (In reply to agapito from comment #203) > (In reply to Jacob from comment #199) > > (In reply to agapito from comment #198) > > > 2 days without crashes... Now 2 crashes in 5 minutes. I will start using > > > my > > > intel graphic card again. > > > > Do you know what exactly you're doing when the crashes occur? > > Yeah, on both occasions, I was trying to write a message in a forum. > (Chromium) If it's happens mostly with chromium, it may be bug 81644. When you say crash what do you mean? Segfault? System hang? GPU hang? GPU page fault? Something else? -- 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/20141029/06d24292/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #203 from agapito --- (In reply to Jacob from comment #199) > (In reply to agapito from comment #198) > > 2 days without crashes... Now 2 crashes in 5 minutes. I will start using my > > intel graphic card again. > > Do you know what exactly you're doing when the crashes occur? Yeah, on both occasions, I was trying to write a message in a forum. (Chromium) (In reply to farmboy0+freedesktop from comment #202) > I am declaring kernel 3.18-rc2 preliminary stable for me again. > My card is an HD 7750 Pro Cape Verde. > I am using 3.18-rc2 with the lower-cased firmware for verde + TAHITI_uvd. > Mesa and Llvm is from recent git. I thought 3.18-rc2 was stable, but is not... -- 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/20141029/612b53a8/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #202 from farmboy0+freedesktop at googlemail.com --- I am declaring kernel 3.18-rc2 preliminary stable for me again. My card is an HD 7750 Pro Cape Verde. I am using 3.18-rc2 with the lower-cased firmware for verde + TAHITI_uvd. Mesa and Llvm is from recent git. -- 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/20141029/ce0df673/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #201 from Aaron B --- Not that it is very prominent, but I also plan on switching to a 780 Ti or similar, if the AMD guys can show their management how many people are not only going to hurt the company, but support the competition it might show AMD it's worth it to get you guys more help over 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/20141029/cc6c8c7a/attachment.html>
[Bug 85613] still getting segfault with vdpau and r600g on Radeon 3850HD - have sample video
https://bugs.freedesktop.org/show_bug.cgi?id=85613 --- Comment #2 from Arthur Marsh --- This problem is with mesa 10.3.2-1 which has that patch applied. -- 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/20141029/156c19dc/attachment.html>
[Bug 85579] [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 --- Comment #5 from sarnex --- Created attachment 108646 --> https://bugs.freedesktop.org/attachment.cgi?id=108646&action=edit backtrace (In reply to Michel Dänzer from comment #4) > Can you run the test in gdb and attach a backtrace? From the logs you > attached, the command line for running the test on your system is: > > /usr/local/lib/piglit/bin/shader_runner > /usr/local/bin/../lib/piglit/tests/spec/glsl-1.50/execution/geometry/max- > input-components.shader_test -auto Hi Michel, I compiled LLVM3.5 debug and Mesa debug, so hopefully there is enough information here. The backtrace is attached. Thanks, sarnex -- 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/20141029/78d64ebb/attachment.html>
[Bug 83861] radeon power management cause audio skips and glitch
https://bugzilla.kernel.org/show_bug.cgi?id=83861 --- Comment #7 from Yomi --- It would seem my particular issue is related to pulseaudio. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73338] Fan speed in idle at 40% with radeonsi and at 18% with catalyst
https://bugs.freedesktop.org/show_bug.cgi?id=73338 --- Comment #47 from Alex Deucher --- Sorry for the delay, my initial patches are here: http://people.freedesktop.org/~agd5f/fan_cntl/ -- 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/20141029/672b491a/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #200 from darkbasic --- I had the very same behaviour with any 3.17+ kernel: sometimes it doesn't crashes for days, others it crashes multiple times per minute. It doesn't matter what you do, it just crashes (even starting your desktop environment is enough sometimes). I will probably buy a Nvidia GTX 970 while waiting for the new unified driver, then I will try the open source path once again: hopefully having the proprietary driver using the very same kernel code will force AMD to take stability into higher consideration. -- 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/20141029/99cc4e21/attachment.html>
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #10 from Michael Mair-Keimberger --- (In reply to Michel Dänzer from comment #7) > Does Mesa 10.3.2 work better, specifically commit > 64c2bdc334ba472603b1e7cd2c3046cfbce285b6? I'll get slightly better results with 10.3.2 (with 3.18rc1): FPS: 16.6 Score: 694 Min FPS: 3.7 Max FPS: 33.1 But honestly, watching the demo feels like it got even worse. Still very long lag's, especially at the beginning of new scene's (before it starts to render). (In reply to Dieter Nützel from comment #8) > Alex's drm-next-3.19-wip (it shows 3.17-rc5 ;-) for example: > git clone git://people.freedesktop.org/~agd5f/linux/ drm-next-3.19-wip > > If you have it already, get it or change it to another tree: > cd drm-next-3.19-wip > git checkout -b drm-next-3.19-wip remotes/origin/drm-next-3.19-wip > > Sometimes you need this: > git fetch origin > git reset --hard origin/drm-next-3.19-wip I've just started cloning drm-next-3.19 but freedesktop seems to be quite slow - looks like i can start testing it tomorrow :/ -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Wed, 2014-10-29 at 09:54 +0200, Jani Nikula wrote: > On Wed, 29 Oct 2014, Michael Ellerman wrote: > > On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: > >> On 10/27/14 06:13, Tomi Valkeinen wrote: > >> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || > >> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds > >> > like a hack to me =). > >> > >> It does exactly what is needed and it is used in many places in kernel > >> Kconfig files. > > > > Is there any reason you can't do: > > > > depends on BACKLIGHT_CLASS_DEVICE != m > > That's not the same thing. The FOO || FOO=n allows for all options, but > forbids it being a module when the option depending on it is > built-in. OK right. Because "BAR depends on FOO" is short for "depends on FOO=y || FOO=m", but also adds the implicit condition that if FOO=m then BAR must also be m. Thanks for clueing me in. cheers
[Bug 85613] still getting segfault with vdpau and r600g on Radeon 3850HD - have sample video
https://bugs.freedesktop.org/show_bug.cgi?id=85613 --- Comment #1 from Alex Deucher --- this sounds like a duplicate of bug 85267. Does this patch help? http://cgit.freedesktop.org/mesa/mesa/commit/?id=ae879718c4086fc5905070e7f26dfa2757df0c86 -- 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/20141029/0e1f508d/attachment.html>
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #46 from Alex Deucher --- The original issue reported was fixed. Please file a new bug if you are having an issue. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #199 from Jacob --- (In reply to agapito from comment #198) > 2 days without crashes... Now 2 crashes in 5 minutes. I will start using my > intel graphic card again. Do you know what exactly you're doing when the crashes occur? -- 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/20141029/9ac6d2cf/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #198 from agapito --- 2 days without crashes... Now 2 crashes in 5 minutes. I will start using my intel graphic card again. -- 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/20141029/aa43cc11/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #197 from agapito --- After 2 days,3.18 rc2 crashed... Arggg this bug is crazy. -- 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/20141029/ee5c0b05/attachment.html>
[patch] drm/radeon: remove some buggy dead code
The calculation of "num_shader_engines" has a precedence bug because
the right shift happens before the mask, but this variable is never used
so we can just delete it.
Signed-off-by: Dan Carpenter
diff --git a/drivers/gpu/drm/radeon/evergreen.c
b/drivers/gpu/drm/radeon/evergreen.c
index a31f1ca..f37d39d 100644
--- a/drivers/gpu/drm/radeon/evergreen.c
+++ b/drivers/gpu/drm/radeon/evergreen.c
@@ -3005,7 +3005,7 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
u32 vgt_cache_invalidation;
u32 hdp_host_path_cntl, tmp;
u32 disabled_rb_mask;
- int i, j, num_shader_engines, ps_thread_count;
+ int i, j, ps_thread_count;
switch (rdev->family) {
case CHIP_CYPRESS:
@@ -3303,8 +3303,6 @@ static void evergreen_gpu_init(struct radeon_device *rdev)
rdev->config.evergreen.tile_config |=
((gb_addr_config & 0x3000) >> 28) << 12;
- num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) + 1;
-
if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) {
u32 efuse_straps_4;
u32 efuse_straps_3;
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 J changed: What|Removed |Added CC||joerg.schaible at gmx.de --- Comment #45 from J --- I suffer from the same problem with vanilla-sources from 3.13.0 to 3.17.1, however, this issue is closed as solved ... since when? -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/radeon: Clean up radeon_uvd_force_into_uvd_segment
On 28.10.2014 19:32, Christian König wrote: > Am 28.10.2014 um 10:28 schrieb Michel Dänzer: >> From: Michel Dänzer >> >> It was adding a second placement for the second 256MB segment of VRAM, >> which is not a good idea for several reasons: >> >> * It fills up the first 256MB segment (which is also typically the CPU >>accessible part) of VRAM first, even for BOs which could go into the >>second 256MB segment. Only once there is no space in the first segment >>does it fall back to the second segment. >> * It doesn't work with RADEON_GEM_NO_CPU_ACCESS BOs, which already use >>two VRAM placements. >> >> Change it to instead restrict the range for each VRAM placement. If the >> BO can go into the second 256MB segment, set up the range to include >> both segments, and set the TTM_PL_FLAG_TOPDOWN flag. That should result >> in preferring the second segment for those BOs, falling back to the >> first segment. >> >> Signed-off-by: Michel Dänzer > > I'm not sure if this will work correctly. Please keep in mind that even > if BOs can be in the second segment they are not allowed to cross > segment borders. > > E.g. if you just set lpfn = (2 * 256 * 1024 * 1024) >> PAGE_SHIFT it > might happen that the first halve of a BO lands in the first 256MB > segment and the second halve of a BO in the second 256MB segment. > > Have you considered that as well? No, I wasn't aware of that restriction. Looking at the current code again, it returns early if (allowed_domains == RADEON_GEM_DOMAIN_VRAM || rbo->placement.num_placement > 1). I think both of these conditions can only be false if allowed_domains == RADEON_GEM_DOMAIN_GTT, so can the second 256MB segment only be used for GTT? -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[Bug 85613] New: still getting segfault with vdpau and r600g on Radeon 3850HD - have sample video
https://bugs.freedesktop.org/show_bug.cgi?id=85613 Bug ID: 85613 Summary: still getting segfault with vdpau and r600g on Radeon 3850HD - have sample video Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: arthur.marsh at internode.on.net I have a video sample online that still gives me a segfault when playing back under vlc. It plays back fine under mpv and mplayer using vdpau. Debian bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=766058 VLC bug report: https://trac.videolan.org/vlc/ticket/12644 VLC have closed the bug on their side claiming that it's a vdpau driver issue. video sample: http://www.users.on.net/~arthur.marsh/VTS_01_1.VOB (152 Megabytes) I'm using vlc 2.2.0~pre4-2 on Debian unstable with mesa 10.3.2-1 using a Radeon 3850HD card and am happy to run further tests and rebuild mesa with patches. Arthur. -- 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/20141029/1f0920d5/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #196 from Alex Deucher --- There are other bug reports related to stability issues specifically with chrome, firefox, and video playback in certain cases which may not be related. Those bugs may be better fits depending on the exact nature of the issue you are seeing. -- 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/20141029/f2faacea/attachment.html>
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #9 from Alex Deucher --- (In reply to Dieter Nützel from comment #8) > > Yes, looks much better, but the code shouldn't touch any relevant > (radeonsi/r600g) code paths. - Michel? > > On r600g (RV730 AGP) I do NOT see any (real) change with this revert... > Maybe we do not hit the real BAD commit. What issue are you seeing and what makes you think it has anything to do with this bug? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #195 from Aaron B --- Assuming my issue is separate, and your fixes were fixed, ever since my issue was the only issue pertaining to random crashes, mostly by video players/web browsers, it seemed the AMD guys never could reproduce it. After some time with nobody else on the bug report, a few appeared with the same problem, and reported the exact same results. Somewhere after that though, I think there were more "Random crashes" bugs. I'd bet the ones who joined in a little later have the same bug as me, the more current random crashes are probably not the same though. Maybe we should kill these reports, and make a couple with titles more appropriate, funnel people there, and start over. :) -- 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/20141029/0d9e2d8e/attachment.html>
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 --- Comment #8 from Dieter Nützel --- (In reply to Michael Mair-Keimberger from comment #6) > (In reply to Dieter Nützel from comment #5) > > Can you please test with one of kernel git | 3.18-rc2 | drm-next together > > with > > git revert 59bc1d8? > > I've tried it with kernel git 3.18rc2 with a pull a few minutes ago and with > `git revert 59bc1d8`. The result looks promising. I've made two benchmarks: > > 1st 2nd > FPS: 18.318.1 > Score: 765 757 > Min FPS: 5.9 6.3 > Max FPS: 32.431.9 Yes, looks much better, but the code shouldn't touch any relevant (radeonsi/r600g) code paths. - Michel? On r600g (RV730 AGP) I do NOT see any (real) change with this revert... Maybe we do not hit the real BAD commit. > I didn't include drm-next simply because i don't know how todo that. :) If > you want me to test drm-next as well please point me to some documentation > how to include it. :) Alex's drm-next-3.19-wip (it shows 3.17-rc5 ;-) for example: git clone git://people.freedesktop.org/~agd5f/linux/ drm-next-3.19-wip If you have it already, get it or change it to another tree: cd drm-next-3.19-wip git checkout -b drm-next-3.19-wip remotes/origin/drm-next-3.19-wip Sometimes you need this: git fetch origin git reset --hard origin/drm-next-3.19-wip -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
From: Dave Airlie
Ivybridge + 30" monitor prints a drm error on every modeset, since
IVB doesn't support DP3 we should even bother trying to use it.
Reviewed-by: Daniel Vetter (on irc)
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index f6a3fdd..87cfb92 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
void
intel_dp_complete_link_train(struct intel_dp *intel_dp)
{
+ struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
+ struct drm_device *dev = encoder->dev;
bool channel_eq = false;
int tries, cr_tries;
uint32_t DP = intel_dp->DP;
uint32_t training_pattern = DP_TRAINING_PATTERN_2;
/* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
- if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
+ if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
!HAS_DDI(dev))
training_pattern = DP_TRAINING_PATTERN_3;
/* channel equalization */
--
1.9.3
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #194 from Marti Raudsepp --- (In reply to Alex Deucher from comment #193) > Unfortunately, this bug has become a dumping ground for any kind of > stability issue with radeonsi so I'm not really sure how useful it is > anymore. I suspect there are actually multiple issues that are now all > mixed up. What's the way forward? Shouldn't it be up to the developers to try and make sense of the reports and split up the bug entry appropriately? Should there be one report per affected user, or is there a better way to group them together? Christian König from comment #175 made one suggestion, is that what we should be doing? > In general you can split the issues into two categories one is with VM > faults in the logs and the other ones are without. -- 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/20141029/6a564b17/attachment-0001.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #193 from Alex Deucher --- (In reply to Aaron B from comment #192) > I guess it is possible there are many different crash types. I'm still > crashing left and right. Is everyone else still stable? If so, looks like > I'll leave you guys here alone to mark your problem fixedand find which > one I need to be living in for bug reports again. :) Unfortunately, this bug has become a dumping ground for any kind of stability issue with radeonsi so I'm not really sure how useful it is anymore. I suspect there are actually multiple issues that are now all mixed up. -- 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/20141029/8cb04d56/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #192 from Aaron B --- I guess it is possible there are many different crash types. I'm still crashing left and right. Is everyone else still stable? If so, looks like I'll leave you guys here alone to mark your problem fixedand find which one I need to be living in for bug reports again. :) -- 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/20141029/7c759d6c/attachment.html>
[PATCH] drm/tegra: DPMS off/on in encoder prepare/commit
Previously the panel and output were only enabled on encoder->dpms(). If
userspace called dpms on before doing a modeset, the driver would get into
a state where the connector had a dpms state of ON, but the encoder and output
were not enabled (because the encoder is not yet attached to the connector).
Subsequent dpms ON calls are ignored b/c the connector's state already matches
the desired state.
This patch enables/disables the panel and output on modeset as well, so we
can catch the above case.
Signed-off-by: Sean Paul
---
drivers/gpu/drm/tegra/output.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/tegra/output.c b/drivers/gpu/drm/tegra/output.c
index 0c67d7e..937a0ea 100644
--- a/drivers/gpu/drm/tegra/output.c
+++ b/drivers/gpu/drm/tegra/output.c
@@ -157,10 +157,12 @@ static bool tegra_encoder_mode_fixup(struct drm_encoder
*encoder,
static void tegra_encoder_prepare(struct drm_encoder *encoder)
{
+ tegra_encoder_dpms(encoder, DRM_MODE_DPMS_OFF);
}
static void tegra_encoder_commit(struct drm_encoder *encoder)
{
+ tegra_encoder_dpms(encoder, DRM_MODE_DPMS_ON);
}
static void tegra_encoder_mode_set(struct drm_encoder *encoder,
--
2.1.1
[Bug 85579] [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 --- Comment #4 from Michel Dänzer --- Can you run the test in gdb and attach a backtrace? From the logs you attached, the command line for running the test on your system is: /usr/local/lib/piglit/bin/shader_runner /usr/local/bin/../lib/piglit/tests/spec/glsl-1.50/execution/geometry/max-input-components.shader_test -auto -- 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/20141029/8c1cc2d3/attachment.html>
[Bug 79980] Random radeonsi crashes
https://bugs.freedesktop.org/show_bug.cgi?id=79980 --- Comment #191 from agapito --- 3.17.1 still affected :S I had a crash just 5 minutes ago. Well, i will use 3.18 rc2 because i didn't have any crash yet. -- 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/20141029/8f958ca1/attachment.html>
[RFC] drm: Add utility function to check for edp1.4
On Wed, Oct 22, 2014 at 11:45:23AM +0530, sonika.jindal at intel.com wrote:
> From: Sonika Jindal
>
> v2: Reading DP_EDP_REV, only when DISPLAY_CONTROL_CAPABLE field is set
> (Satheesh)
>
> v3: Moving the utility function to drm_dp_helper (Daniel)
>
> Signed-off-by: Sonika Jindal
> ---
> drivers/gpu/drm/drm_dp_helper.c | 15 +++
> include/drm/drm_dp_helper.h |2 ++
> 2 files changed, 17 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 08e33b8..a54a760 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -768,3 +768,18 @@ void drm_dp_aux_unregister(struct drm_dp_aux *aux)
> i2c_del_adapter(&aux->ddc);
> }
> EXPORT_SYMBOL(drm_dp_aux_unregister);
> +
> +bool drm_dp_is_edp_v1_4(struct drm_dp_aux *aux, const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
I'd prefer if this didn't take a dpcd argument but rather directly
accessed the DP_EDP_CONFIGURATION_CAP register so that it can be used
directly rather than rely on the driver to have read a dpcd block in the
appropriate format.
> +{
> + uint8_t reg;
> +
> + if (dpcd[DP_EDP_CONFIGURATION_CAP] &
> + DP_DPCD_DISPLAY_CONTROL_CAPABLE) {
> +
> + if (drm_dp_dpcd_read(aux, DP_EDP_REV, ®, 1))
> + if (reg == 0x03)
> + return true;
> + }
> + return false;
> +}
> +EXPORT_SYMBOL(drm_dp_is_edp_v1_4);
Does it make sense to have a function that checks for a specific
version? Why not add one that returns the revision so that it can be
compared, something like:
u8 value;
drm_dp_dpcd_read(aux, DP_EDP_REV, &value, 1);
return value;
Then we can do something like:
#define DP_EDP_REV_1_1 0x00
#define DP_EDP_REV_1_2 0x01
#define DP_EDP_REV_1_3 0x02
#define DP_EDP_REV_1_4 0x03
And code can simply compare against that:
drm_dp_get_edp_revision(aux, &rev);
if (rev >= DP_EDP_REV_1_4) {
...
}
The check in your variant will only match v1.4 exactly, but presumably
v1.5 will be backwards compatible. Having a direct check on the revision
code will allow code to continue to work with future, backwards-
compatible revisions.
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index 8edeed0..b017e1e 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -102,6 +102,8 @@
>
> #define DP_EDP_CONFIGURATION_CAP0x00d /* XXX 1.2? */
> #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */
> +#define DP_DPCD_DISPLAY_CONTROL_CAPABLE (1 << 3)
This seems to be a field in the DP_EDP_CONFIGURATION_CAP register, so it
should be sorted below that register, not DP_TRAINING_AUX_RD_INTERVAL.
> +#define DP_EDP_REV 0x700
And this belongs further down, so it properly sorts into the list of
registers.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/2822532e/attachment-0001.sig>
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: > On 10/27/14 06:13, Tomi Valkeinen wrote: > > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || > > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds > > like a hack to me =). > > It does exactly what is needed and it is used in many places in kernel > Kconfig files. Is there any reason you can't do: depends on BACKLIGHT_CLASS_DEVICE != m cheers
[PATCH 1/5] MAINTAINERS: Add entry for MIPI DSI bus
On Mon, Oct 27, 2014 at 03:17:17PM +0100, Daniel Vetter wrote: > On Mon, Oct 27, 2014 at 10:48:26AM +0100, Andrzej Hajda wrote: > > Signed-off-by: Andrzej Hajda > > --- > > MAINTAINERS | 7 +++ > > 1 file changed, 7 insertions(+) > > > > diff --git a/MAINTAINERS b/MAINTAINERS > > index dd31933..476679c 100644 > > --- a/MAINTAINERS > > +++ b/MAINTAINERS > > @@ -3071,6 +3071,13 @@ F: drivers/gpu/vga/ > > F: include/drm/ > > F: include/uapi/drm/ > > > > +DRM MIPI DSI BUS > > +M: Andrzej Hajda > > +L: dri-devel at lists.freedesktop.org > > +S: Supported > > +F: drivers/gpu/drm/drm_mipi_dsi.c > > +F: include/drm/drm_mipi_dsi.h > > I really prefer when common infrastructure like this doesn't get > maintainer by a vendor. And I care with my intel hat on since we also ahve > a dsi driver that sooner or later needs to be converted to to this stuff. > > Why doesn't the usual model of merging stuff through Dave's tree, or if > that doesn't work well due to patch depencies, through vendor trees with > Dave's ack? FWIW, I've merged DSI changes through the panel tree in the past after discussing it with Dave on IRC. It seemed like a good fit and it was most relevant for panels anyway. Given that I had expected that Dave would give it a closer look before pulling than any of the vendor trees anyway, so it would be as good as an explicit Acked-by anyway. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/7298afe0/attachment.sig>
[Bug 85596] SB is used only after GPR check / GPR max is not dynamic
https://bugs.freedesktop.org/show_bug.cgi?id=85596 --- Comment #1 from Alex Deucher --- (In reply to Lauri Kasanen from comment #0) > Many big shaders that currently fail with > r600_shader_select - Failed to build shader variant (type=1) -12 > r600_shader_from_tgsi - GPR limit exceeded - shader requires foo registers > > would actually work if the GPR check was moved to after SB, as SB reduces > the GPR usage quite nicely. > > Another thing is that 128 is the lowest common denominator, and many cards > have 192 or 256, which could be checked with the radeon_info ioctl. >From an ISA perspective, there are only 128 GPRs. The higher limits are hw internal details. -- 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/20141029/33b83cae/attachment-0001.html>
[Bug 85579] [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 --- Comment #3 from sarnex --- Created attachment 108624 --> https://bugs.freedesktop.org/attachment.cgi?id=108624&action=edit patch crash (In reply to Michel Dänzer from comment #2) > Created attachment 108612 [details] > radeonsi: If compiling the vertex or geometry shader fails, skip the draw > > Does this patch fix the crash? Hi Michel, Unfortunately, it appears the patch has no effect. But, after updating my mesa to today's version, the test crashes very quickly, when it used to take over 3 minutes to fail or crash. Maybe this is related to the other llvm change? I attached a log. Thanks, sarnex -- 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/20141029/d657f424/attachment.html>
[patch] drm/radeon: remove some buggy dead code
On Wed, Oct 29, 2014 at 11:47 AM, Dan Carpenter
wrote:
> The calculation of "num_shader_engines" has a precedence bug because
> the right shift happens before the mask, but this variable is never used
> so we can just delete it.
>
> Signed-off-by: Dan Carpenter
Applied in preference to Joe Perches's patch.
Thanks!
Alex
>
> diff --git a/drivers/gpu/drm/radeon/evergreen.c
> b/drivers/gpu/drm/radeon/evergreen.c
> index a31f1ca..f37d39d 100644
> --- a/drivers/gpu/drm/radeon/evergreen.c
> +++ b/drivers/gpu/drm/radeon/evergreen.c
> @@ -3005,7 +3005,7 @@ static void evergreen_gpu_init(struct radeon_device
> *rdev)
> u32 vgt_cache_invalidation;
> u32 hdp_host_path_cntl, tmp;
> u32 disabled_rb_mask;
> - int i, j, num_shader_engines, ps_thread_count;
> + int i, j, ps_thread_count;
>
> switch (rdev->family) {
> case CHIP_CYPRESS:
> @@ -3303,8 +3303,6 @@ static void evergreen_gpu_init(struct radeon_device
> *rdev)
> rdev->config.evergreen.tile_config |=
> ((gb_addr_config & 0x3000) >> 28) << 12;
>
> - num_shader_engines = (gb_addr_config & NUM_SHADER_ENGINES(3) >> 12) +
> 1;
> -
> if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK)) {
> u32 efuse_straps_4;
> u32 efuse_straps_3;
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/11 V2] radeon: evergreen: Fix probable mask then right shift defect
On 28.10.2014 23:06, Alex Deucher wrote: > On Mon, Oct 27, 2014 at 10:14 AM, Joe Perches wrote: >> Precedence of & and >> is not the same and is not left to right. >> shift has higher precedence and should be done after the mask. >> >> Add parentheses around the mask. >> >> Use the already #defined values instead of hardcoding. >> >> Signed-off-by: Joe Perches >> --- >>> I think this should be NUM_SHADER_ENGINES_SHIFT? >> >> (Joe can't type) >> >> exactly right, thanks Michel > > Applied with a compile fix. Joe, in the future please make sure your patches compile before submitting them. -- Earthling Michel Dänzer| http://www.amd.com Libre software enthusiast |Mesa and X developer
[PATCH] allow 32bpp framebuffers for cirrus drm
On Di, 2014-10-28 at 17:04 +, Zachary Reizner wrote: > revision bump would be needed when adding a new interface (not > present > in real hardware) to allow for larger pitches, so you could > use 32bpp > with the default (1024x768) resolution. > I did not change the pitch mechanism. Sure. That was Adams idea to make the patch more useful. > The hardware is limited to less than a 4KB pitch because of the > registers, so I kept that limitation in the driver. That means no > revision bump is necessary. Yes, but it also implies that 32bpp will work on very low resolutions only (excluding the default res of 1024x768). I don't think the patch is very useful because of that. Nevertheless no objections to include it from my side. cheers, Gerd
[Bug 85596] SB is used only after GPR check / GPR max is not dynamic
https://bugs.freedesktop.org/show_bug.cgi?id=85596 Lauri Kasanen changed: What|Removed |Added Depends on||74868, 81683, 69623 -- 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/20141029/7519777f/attachment.html>
[Bug 69623] Pink Pony misrenders - - shader requires 126 registers
https://bugs.freedesktop.org/show_bug.cgi?id=69623 Lauri Kasanen changed: What|Removed |Added Blocks||85596 -- 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/20141029/8df4725d/attachment.html>
[Bug 74868] r600g: Diablo III Crashes After a few minutes
https://bugs.freedesktop.org/show_bug.cgi?id=74868 Lauri Kasanen changed: What|Removed |Added Blocks||85596 -- 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/20141029/729f489b/attachment.html>
[Bug 81683] [r600g] graphic glitches in Skyrim - failed to build shader
https://bugs.freedesktop.org/show_bug.cgi?id=81683 Lauri Kasanen changed: What|Removed |Added Blocks||85596 -- 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/20141029/2eb7b14f/attachment.html>
[Bug 85596] New: SB is used only after GPR check / GPR max is not dynamic
https://bugs.freedesktop.org/show_bug.cgi?id=85596 Bug ID: 85596 Summary: SB is used only after GPR check / GPR max is not dynamic Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: curaga at operamail.com Many big shaders that currently fail with r600_shader_select - Failed to build shader variant (type=1) -12 r600_shader_from_tgsi - GPR limit exceeded - shader requires foo registers would actually work if the GPR check was moved to after SB, as SB reduces the GPR usage quite nicely. Another thing is that 128 is the lowest common denominator, and many cards have 192 or 256, which could be checked with the radeon_info ioctl. -- 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/20141029/507dd7f8/attachment-0001.html>
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, 29 Oct 2014, Ville Syrjälä wrote:
> On Wed, Oct 29, 2014 at 10:23:50AM +0200, Jani Nikula wrote:
>> On Wed, 29 Oct 2014, Ville Syrjälä
>> wrote:
>> > On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
>> >> From: Dave Airlie
>> >>
>> >> Ivybridge + 30" monitor prints a drm error on every modeset, since
>> >> IVB doesn't support DP3 we should even bother trying to use it.
>> >>
>> >> Reviewed-by: Daniel Vetter (on irc)
>> >> Signed-off-by: Dave Airlie
>> >> ---
>> >> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>> >> 1 file changed, 3 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> >> b/drivers/gpu/drm/i915/intel_dp.c
>> >> index f6a3fdd..87cfb92 100644
>> >> --- a/drivers/gpu/drm/i915/intel_dp.c
>> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> >> @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp
>> >> *intel_dp)
>> >> void
>> >> intel_dp_complete_link_train(struct intel_dp *intel_dp)
>> >> {
>> >> + struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
>> >> + struct drm_device *dev = encoder->dev;
>> >> bool channel_eq = false;
>> >> int tries, cr_tries;
>> >> uint32_t DP = intel_dp->DP;
>> >> uint32_t training_pattern = DP_TRAINING_PATTERN_2;
>> >>
>> >> /* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
>> >> - if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
>> >> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
>> >> !HAS_DDI(dev))
>> >
>> > CHV has pattern 3.
>>
>> Is "supports tps3" the same set of platforms as "supports 5.4 Gbps"? We
>> should abstract the check from intel_dp_max_link_bw.
>
> Not quite. HSW-ULX supports pattern 3 even though it doesn't do 5.4 Gbps.
How about [1] instead? I forgot --in-reply-to, sorry.
BR,
Jani.
[1] http://mid.gmane.org/1414573406-17071-1-git-send-email-jani.nikula at
intel.com
--
Jani Nikula, Intel Open Source Technology Center
[PATCH v2] allow 32bpp framebuffers for cirrus drm
This patch allows framebuffers for cirrus to be created with
32bpp pixel formats provided that they do not violate certain
restrictions of the cirrus hardware.
v2: Use pci resource length for vram size.
Signed-off-by: Zach Reizner
---
drivers/gpu/drm/cirrus/cirrus_drv.h | 3 +++
drivers/gpu/drm/cirrus/cirrus_fbdev.c | 5 -
drivers/gpu/drm/cirrus/cirrus_main.c | 27 +++
3 files changed, 30 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus_drv.h
b/drivers/gpu/drm/cirrus/cirrus_drv.h
index d44e69d..693a456 100644
--- a/drivers/gpu/drm/cirrus/cirrus_drv.h
+++ b/drivers/gpu/drm/cirrus/cirrus_drv.h
@@ -210,6 +210,9 @@ int cirrus_framebuffer_init(struct drm_device *dev,
struct drm_mode_fb_cmd2 *mode_cmd,
struct drm_gem_object *obj);
+bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int
height,
+ int bpp, int pitch);
+
/* cirrus_display.c */
int cirrus_modeset_init(struct cirrus_device *cdev);
void cirrus_modeset_fini(struct cirrus_device *cdev);
diff --git a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
index d231b1c..502a89e 100644
--- a/drivers/gpu/drm/cirrus/cirrus_fbdev.c
+++ b/drivers/gpu/drm/cirrus/cirrus_fbdev.c
@@ -139,6 +139,7 @@ static int cirrusfb_create_object(struct cirrus_fbdev
*afbdev,
struct drm_gem_object **gobj_p)
{
struct drm_device *dev = afbdev->helper.dev;
+ struct cirrus_device *cdev = dev->dev_private;
u32 bpp, depth;
u32 size;
struct drm_gem_object *gobj;
@@ -146,8 +147,10 @@ static int cirrusfb_create_object(struct cirrus_fbdev
*afbdev,
int ret = 0;
drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
- if (bpp > 24)
+ if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
+ bpp, mode_cmd->pitches[0]))
return -EINVAL;
+
size = mode_cmd->pitches[0] * mode_cmd->height;
ret = cirrus_gem_create(dev, size, true, &gobj);
if (ret)
diff --git a/drivers/gpu/drm/cirrus/cirrus_main.c
b/drivers/gpu/drm/cirrus/cirrus_main.c
index 99c1983..d9590fc 100644
--- a/drivers/gpu/drm/cirrus/cirrus_main.c
+++ b/drivers/gpu/drm/cirrus/cirrus_main.c
@@ -49,14 +49,16 @@ cirrus_user_framebuffer_create(struct drm_device *dev,
struct drm_file *filp,
struct drm_mode_fb_cmd2 *mode_cmd)
{
+ struct cirrus_device *cdev = dev->dev_private;
struct drm_gem_object *obj;
struct cirrus_framebuffer *cirrus_fb;
int ret;
u32 bpp, depth;
drm_fb_get_bpp_depth(mode_cmd->pixel_format, &depth, &bpp);
- /* cirrus can't handle > 24bpp framebuffers at all */
- if (bpp > 24)
+
+ if (!cirrus_check_framebuffer(cdev, mode_cmd->width, mode_cmd->height,
+ bpp, mode_cmd->pitches[0]))
return ERR_PTR(-EINVAL);
obj = drm_gem_object_lookup(dev, filp, mode_cmd->handles[0]);
@@ -96,8 +98,7 @@ static int cirrus_vram_init(struct cirrus_device *cdev)
{
/* BAR 0 is VRAM */
cdev->mc.vram_base = pci_resource_start(cdev->dev->pdev, 0);
- /* We have 4MB of VRAM */
- cdev->mc.vram_size = 4 * 1024 * 1024;
+ cdev->mc.vram_size = pci_resource_len(cdev->dev->pdev, 0);
if (!request_mem_region(cdev->mc.vram_base, cdev->mc.vram_size,
"cirrusdrmfb_vram")) {
@@ -307,3 +308,21 @@ out_unlock:
return ret;
}
+
+bool cirrus_check_framebuffer(struct cirrus_device *cdev, int width, int
height,
+ int bpp, int pitch)
+{
+ const int max_pitch = 0x1FF << 3; /* (4096 - 1) & ~111b bytes */
+ const int max_size = cdev->mc.vram_size;
+
+ if (bpp > 32)
+ return false;
+
+ if (pitch > max_pitch)
+ return false;
+
+ if (pitch * height > max_size)
+ return false;
+
+ return true;
+}
--
2.1.0.rc2.206.gedb03e5
[RFC 1/2] PM / Domains: Power on domain early during system resume
Krzysztof Kozlowski writes: > When resuming the system the power domain has to be powered on early so > any runtime PM aware devices could resume. > > This fixes following scenario reproduced on Exynos DRM: > 1. Power domain is off before suspending the system. > 2. System is suspended to RAM. > 3. Resuming starts. The Exynos DRM driver resume callback is called. > 4. The Exynos DRM driver calls drm_helper_resume_force_mode which turns >the screen on by calling exynos_dsi_dpms with DRM_MODE_DPMS_ON. Dumb Q: if the device (and power domain) were off before (and during) suspend, why are they being resumed? Shouldn't the resume path restore things to the same state they were before suspend? Kevin
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, Oct 29, 2014 at 10:23:50AM +0200, Jani Nikula wrote:
> On Wed, 29 Oct 2014, Ville Syrjälä wrote:
> > On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
> >> From: Dave Airlie
> >>
> >> Ivybridge + 30" monitor prints a drm error on every modeset, since
> >> IVB doesn't support DP3 we should even bother trying to use it.
> >>
> >> Reviewed-by: Daniel Vetter (on irc)
> >> Signed-off-by: Dave Airlie
> >> ---
> >> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> >> 1 file changed, 3 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> >> b/drivers/gpu/drm/i915/intel_dp.c
> >> index f6a3fdd..87cfb92 100644
> >> --- a/drivers/gpu/drm/i915/intel_dp.c
> >> +++ b/drivers/gpu/drm/i915/intel_dp.c
> >> @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp
> >> *intel_dp)
> >> void
> >> intel_dp_complete_link_train(struct intel_dp *intel_dp)
> >> {
> >> + struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
> >> + struct drm_device *dev = encoder->dev;
> >>bool channel_eq = false;
> >>int tries, cr_tries;
> >>uint32_t DP = intel_dp->DP;
> >>uint32_t training_pattern = DP_TRAINING_PATTERN_2;
> >>
> >>/* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
> >> - if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> >> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
> >> !HAS_DDI(dev))
> >
> > CHV has pattern 3.
>
> Is "supports tps3" the same set of platforms as "supports 5.4 Gbps"? We
> should abstract the check from intel_dp_max_link_bw.
Not quite. HSW-ULX supports pattern 3 even though it doesn't do 5.4 Gbps.
>
> Jani.
>
>
> >
> >>training_pattern = DP_TRAINING_PATTERN_3;
> >>
> >>/* channel equalization */
> >> --
> >> 1.9.3
> >>
> >> ___
> >> Intel-gfx mailing list
> >> Intel-gfx at lists.freedesktop.org
> >> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
> >
> > --
> > Ville Syrjälä
> > Intel OTC
> > ___
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Technology Center
--
Ville Syrjälä
Intel OTC
[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)
https://bugs.freedesktop.org/show_bug.cgi?id=84740 --- Comment #9 from Germano Massullo --- Created attachment 108615 --> https://bugs.freedesktop.org/attachment.cgi?id=108615&action=edit intel_reg_dumper > after_suspend.txt -- 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/20141029/e86e42d9/attachment.html>
[Bug 84740] black screen after Grub loads a kernel entry (Intel Atom D2xxx/N2xxx Integrated Graphics Controller)
https://bugs.freedesktop.org/show_bug.cgi?id=84740 --- Comment #8 from Germano Massullo --- Created attachment 108614 --> https://bugs.freedesktop.org/attachment.cgi?id=108614&action=edit intel_reg_dumper > before_suspend.txt -- 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/20141029/c05e9048/attachment.html>
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, 29 Oct 2014, Ville Syrjälä wrote:
> On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
>> From: Dave Airlie
>>
>> Ivybridge + 30" monitor prints a drm error on every modeset, since
>> IVB doesn't support DP3 we should even bother trying to use it.
>>
>> Reviewed-by: Daniel Vetter (on irc)
>> Signed-off-by: Dave Airlie
>> ---
>> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_dp.c
>> b/drivers/gpu/drm/i915/intel_dp.c
>> index f6a3fdd..87cfb92 100644
>> --- a/drivers/gpu/drm/i915/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/intel_dp.c
>> @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
>> void
>> intel_dp_complete_link_train(struct intel_dp *intel_dp)
>> {
>> +struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
>> +struct drm_device *dev = encoder->dev;
>> bool channel_eq = false;
>> int tries, cr_tries;
>> uint32_t DP = intel_dp->DP;
>> uint32_t training_pattern = DP_TRAINING_PATTERN_2;
>>
>> /* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
>> -if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
>> +if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
>> !HAS_DDI(dev))
>
> CHV has pattern 3.
Is "supports tps3" the same set of platforms as "supports 5.4 Gbps"? We
should abstract the check from intel_dp_max_link_bw.
Jani.
>
>> training_pattern = DP_TRAINING_PATTERN_3;
>>
>> /* channel equalization */
>> --
>> 1.9.3
>>
>> ___
>> Intel-gfx mailing list
>> Intel-gfx at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Jani Nikula, Intel Open Source Technology Center
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, Oct 29, 2014 at 10:15:01AM +0200, Ville Syrjälä wrote:
> On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
> > From: Dave Airlie
> >
> > Ivybridge + 30" monitor prints a drm error on every modeset, since
> > IVB doesn't support DP3 we should even bother trying to use it.
> >
> > Reviewed-by: Daniel Vetter (on irc)
> > Signed-off-by: Dave Airlie
> > ---
> > drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> > 1 file changed, 3 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index f6a3fdd..87cfb92 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> > void
> > intel_dp_complete_link_train(struct intel_dp *intel_dp)
> > {
> > + struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
> > + struct drm_device *dev = encoder->dev;
> > bool channel_eq = false;
> > int tries, cr_tries;
> > uint32_t DP = intel_dp->DP;
> > uint32_t training_pattern = DP_TRAINING_PATTERN_2;
> >
> > /* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
> > - if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> > + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
> > !HAS_DDI(dev))
>
> CHV has pattern 3.
Also what's that '!' doing there?
>
> > training_pattern = DP_TRAINING_PATTERN_3;
> >
> > /* channel equalization */
> > --
> > 1.9.3
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Wed, Oct 29, 2014 at 08:51:27AM +0100, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> > On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > wrote:
> > > >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > > >>> * @driver_private: pointer to the bridge driver's internal context
> > > >>> */
> > > >>> struct drm_bridge {
> > > >>> - struct drm_device *dev;
> > > >>> + struct device *dev;
> > > >>
> > > >> Please don't rename the ->dev pointer into drm. Because _all_ the other
> > > >> drm structures still call it ->dev. Also, can't we use struct
> > > >> device_node
> > > >> here like we do in the of helpers Russell added? See 7e435aad38083
> > > >>
> > > >
> > > > I think this is modeled after the naming in drm_panel, FWIW. However,
> > > > seems reasonable to keep the device_node instead.
> > >
> > > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > > drm_crtc drop the struct device and go directly to a struct
> > > device_node. Since we don't really need the sturct device, the only
> > > thing we care about is the of_node. For added bonus wrap an #ifdef
> > > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > > Should be all fairly simple to pull off with cocci.
> > >
> > > Thierry?
> >
> > The struct device * is in DRM panel because there's nothing device tree
> > specific about the concept. Having a struct device_node * instead would
> > indicate that it can only be used with a device tree, whereas the
> > framework doesn't care the tiniest bit what type of device we have.
> >
> > While the trend clearly is to use more device tree, I don't think we
> > should make it impossible for anybody else to use these frameworks.
> >
> > There are other advantages to keeping a struct device *, like having
> > access to the proper device and its name. Also you get access to the
> > device_node * via dev->of_node anyway. I don't see any advantage in
> > switching to just a struct device_node *, only disadvantages.
>
> Well the idea is to make the lookup key specific, and conditional on
> #CONFIG_OF. If there's going to be another neat way to enumerate platform
> devices then I think we should add that, too. Or maybe we should have a
> void *platform_data or so.
>
> The reason I really don't want a struct device * in core drm structures is
> that two releases down the road people will have found tons of really
> great ways to abuse them and re-create a midlayer. DRM core really should
> only care about the sw objects and not be hw specific at all. Heck there's
> not even an requirement to have any piece of actual hw, you could write a
> completely fake drm driver (for e.g. testing like the new v4l driver).
>
> Tbh I wonder a bit why we even have this registery embedded into the core
> drm objects. Essentially the only thing you're doing is a list that maps
> some platform specific key onto some subsystem specific driver structure
> or fails the lookup. So instead of putting all these low-level details
> into drm core structures can't we just have a generic hashtable/list for
> this, plus some static inline helpers that cast the void * you get into
> the one you want?
>
> I also get the feeling that this really should be in the driver core (like
> the component helpers), and that we should think a lot harder about
> lifetimes and refcounting (see my other reply on that).
Yes, that sounds very useful indeed. Also see my reply to yours. =)
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/6ea7a4ff/attachment.sig>
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Ivybridge + 30" monitor prints a drm error on every modeset, since
> IVB doesn't support DP3 we should even bother trying to use it.
>
> Reviewed-by: Daniel Vetter (on irc)
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f6a3fdd..87cfb92 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> void
> intel_dp_complete_link_train(struct intel_dp *intel_dp)
> {
> + struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
> + struct drm_device *dev = encoder->dev;
> bool channel_eq = false;
> int tries, cr_tries;
> uint32_t DP = intel_dp->DP;
> uint32_t training_pattern = DP_TRAINING_PATTERN_2;
>
> /* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
> - if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
> !HAS_DDI(dev))
CHV has pattern 3.
> training_pattern = DP_TRAINING_PATTERN_3;
>
> /* channel equalization */
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel OTC
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
dge/panel pointer you've just returned is freed memory.
Ah yes, I see now.
> I think we nee try_get_module for the code and kref on the actual data
> structures.
Agreed, that should do the trick. We'd probably need some sort of logic
to also make operations return something like -ENODEV when the
underlying device has disappeared. I think David had introduced
something similar for DRM device not so long ago?
> That makes the entire thing a bit non-trivial, which is why I think it
> would be better as some generic helper. Which then gets embedded or
> instantiated for specific cases, like dt&drm_panel or dt&drm_bridge.
> Or maybe even acpi&drm_bridge, who knows ;-)
I worry a little about type safety. How will this generic helper know
what registry to look in for? Or conversely, if all these resources are
added to a single registry how do you know that they're of the correct
type? Failing to ensure this could cause situations where you're asking
for a panel and get a bridge in return because you've wrongly wired it
up in device tree for example.
But perhaps if both the registry and the device parts are turned into
helpers we could still have a single core implementation and then
instantiate that for each type, something roughly like this:
struct registry {
struct list_head list;
struct mutex lock;
};
struct registry_record {
struct list_head list;
struct module *owner;
struct kref *ref;
struct device *dev;
};
int registry_add(struct registry *registry, struct registry_record
*record)
{
...
try_module_get(record->owner);
...
}
struct registry_record *registry_find_by_of_node(struct registry
*registry,
struct device_node *np)
{
...
kref_get(...);
...
}
That way it should be possible to embed these into other structures,
like so:
struct drm_panel {
struct registry_record record;
...
};
static struct registry drm_panels;
int drm_panel_add(struct drm_panel *panel)
{
return registry_add(&drm_panels, &panel->record);
}
struct drm_panel *of_drm_panel_find(struct device_node *np)
{
struct registry_record *record;
record = registry_find_by_of_node(&drm_panels, np);
return container_of(record, struct drm_panel, record);
}
Is that what you had in mind?
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/9de7c54d/attachment-0001.sig>
[PATCH 3/3] drm/modeset_lock: document trylock_only in kerneldoc
I've forgotten to do this in: commit cb597bb3a2fbfc871cc1c703fb330d247bd21394 Author: Daniel Vetter Date: Sun Jul 27 19:09:33 2014 +0200 drm: trylock modest locking for fbdev panics Oops, fix this asap. In my defense kerneldoc is really awful and there's no way it can pick up structured comments per struct member. Which means we need both since people won't scroll up even a few lines. Signed-off-by: Daniel Vetter --- include/drm/drm_modeset_lock.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_modeset_lock.h b/include/drm/drm_modeset_lock.h index 75a5c45e21c7..28931a23d96c 100644 --- a/include/drm/drm_modeset_lock.h +++ b/include/drm/drm_modeset_lock.h @@ -33,6 +33,7 @@ struct drm_modeset_lock; * @ww_ctx: base acquire ctx * @contended: used internally for -EDEADLK handling * @locked: list of held locks + * @trylock_only: trylock mode used in atomic contexts/panic notifiers * * Each thread competing for a set of locks must use one acquire * ctx. And if any lock fxn returns -EDEADLK, it must backoff and -- 2.1.1
[PATCH 2/3] drm: fixup kerneldoc in drm_crtc.h
I've tried to cc all the people who have recently added new stuff
but forgotten to update documentation.
I've also decided not to bother documenting the massive property list
in struct drm_mode_config. If that beast keeps on growing we might want
to extract it into a separate structure which we won't document.
Cc: Thomas Wood
Cc: Sean Paul
Cc: Russell King
Signed-off-by: Daniel Vetter
---
include/drm/drm_crtc.h | 51 +++---
1 file changed, 36 insertions(+), 15 deletions(-)
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 21a15850a4d5..a68e02be7e37 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -231,6 +231,7 @@ struct drm_bridge;
* @restore: restore CRTC state
* @reset: reset CRTC after state has been invalidated (e.g. resume)
* @cursor_set: setup the cursor
+ * @cursor_set2: setup the cursor with hotspot, superseeds @cursor_set if set
* @cursor_move: move the cursor
* @gamma_set: specify color ramp for CRTC
* @destroy: deinit and free object
@@ -292,11 +293,14 @@ struct drm_crtc_funcs {
/**
* struct drm_crtc - central CRTC control structure
* @dev: parent DRM device
+ * @port: OF node used by drm_of_find_possible_crtcs()
* @head: list management
* @mutex: per-CRTC locking
* @base: base KMS object for ID tracking etc.
* @primary: primary plane for this CRTC
* @cursor: cursor plane for this CRTC
+ * @cursor_x: current x position of the cursor, used for universal cursor
planes
+ * @cursor_y: current y position of the cursor, used for universal cursor
planes
* @enabled: is this CRTC enabled?
* @mode: current mode timings
* @hwmode: mode timings as programmed to hw regs
@@ -309,10 +313,12 @@ struct drm_crtc_funcs {
* @gamma_size: size of gamma ramp
* @gamma_store: gamma ramp values
* @framedur_ns: precise frame timing
- * @framedur_ns: precise line timing
+ * @linedur_ns: precise line timing
* @pixeldur_ns: precise pixel timing
* @helper_private: mid-layer private data
* @properties: property tracking for this CRTC
+ * @acquire_ctx: per-CRTC implicit acquire context used by atomic drivers for
+ * legacy ioctls
*
* Each CRTC may have one or more connectors associated with it. This
structure
* allows the CRTC to be controlled.
@@ -483,6 +489,7 @@ struct drm_encoder {
* @connector_type_id: index into connector type enum
* @interlace_allowed: can this connector handle interlaced modes?
* @doublescan_allowed: can this connector handle doublescan?
+ * @stereo_allowed: can this connector handle stereo modes?
* @modes: modes available on this connector (from fill_modes() + user)
* @status: one of the drm_connector_status enums (connected, not, or unknown)
* @probed_modes: list of modes derived directly from the display
@@ -490,10 +497,13 @@ struct drm_encoder {
* @funcs: connector control functions
* @edid_blob_ptr: DRM property containing EDID if present
* @properties: property tracking for this connector
+ * @path_blob_ptr: DRM blob property data for the DP MST path property
* @polled: a %DRM_CONNECTOR_POLL_ value for core driven polling
* @dpms: current dpms state
* @helper_private: mid-layer private data
+ * @cmdline_mode: mode line parsed from the kernel cmdline for this connector
* @force: a %DRM_FORCE_ state for forced mode sets
+ * @override_edid: has the EDID been overwritten through debugfs for testing?
* @encoder_ids: valid encoders for this connector
* @encoder: encoder driving this connector, if any
* @eld: EDID-like data, if present
@@ -503,6 +513,8 @@ struct drm_encoder {
* @video_latency: video latency info from ELD, if found
* @audio_latency: audio latency info from ELD, if found
* @null_edid_counter: track sinks that give us all zeros for the EDID
+ * @bad_edid_counter: track sinks that give us an EDID with invalid checksum
+ * @debugfs_entry: debugfs directory for this connector
*
* Each connector may be connected to one or more CRTCs, or may be clonable by
* another connector if they can share a CRTC. Each connector also has a
specific
@@ -570,6 +582,7 @@ struct drm_connector {
* @update_plane: update the plane configuration
* @disable_plane: shut down the plane
* @destroy: clean up plane resources
+ * @reset: reset plane after state has been invalidated (e.g. resume)
* @set_property: called when a property is changed
*/
struct drm_plane_funcs {
@@ -603,6 +616,8 @@ enum drm_plane_type {
* @format_count: number of formats supported
* @crtc: currently bound CRTC
* @fb: currently bound fb
+ * @old_fb: Temporary tracking of the old fb while a modeset is ongoing. Used
by
+ * drm_mode_set_config_internal() to implement correct refcounting.
* @funcs: helper functions
* @properties: property tracking for this plane
* @type: type of plane (overlay, primary, cursor)
@@ -620,8 +635,6 @@ struct drm_plane {
struct drm_crtc *crtc;
struct drm_framebuffer *fb;
- /* Tempora
[PATCH 1/3] drm: Pull drm_crtc.h into the kerneldoc template
While writing atomic docs I've noticed that I don't get any errors
for my screw-ups in drm_crtc.h. Fix this immediately.
This just does the bare minimum to get starts, lots of stuff isn't
properly documented yet unfortunately.
Signed-off-by: Daniel Vetter
---
Documentation/DocBook/drm.tmpl | 4
include/drm/drm_crtc.h | 26 +-
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl
index be35bc328b77..89829ae58e97 100644
--- a/Documentation/DocBook/drm.tmpl
+++ b/Documentation/DocBook/drm.tmpl
@@ -1827,6 +1827,10 @@ void intel_crt_init(struct drm_device *dev)
!Edrivers/gpu/drm/drm_crtc.c
+ KMS Data Structures
+!Iinclude/drm/drm_crtc.h
+
+
KMS Locking
!Pdrivers/gpu/drm/drm_modeset_lock.c kms locking
!Iinclude/drm/drm_modeset_lock.h
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 44c57d2a64ec..21a15850a4d5 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -142,7 +142,7 @@ struct drm_framebuffer_funcs {
int (*create_handle)(struct drm_framebuffer *fb,
struct drm_file *file_priv,
unsigned int *handle);
- /**
+ /*
* Optinal callback for the dirty fb ioctl.
*
* Userspace can notify the driver via this callback
@@ -226,7 +226,7 @@ struct drm_plane;
struct drm_bridge;
/**
- * drm_crtc_funcs - control CRTCs for a given device
+ * struct drm_crtc_funcs - control CRTCs for a given device
* @save: save CRTC state
* @restore: restore CRTC state
* @reset: reset CRTC after state has been invalidated (e.g. resume)
@@ -290,7 +290,7 @@ struct drm_crtc_funcs {
};
/**
- * drm_crtc - central CRTC control structure
+ * struct drm_crtc - central CRTC control structure
* @dev: parent DRM device
* @head: list management
* @mutex: per-CRTC locking
@@ -322,7 +322,7 @@ struct drm_crtc {
struct device_node *port;
struct list_head head;
- /**
+ /*
* crtc mutex
*
* This provides a read lock for the overall crtc state (mode, dpms
@@ -377,7 +377,7 @@ struct drm_crtc {
/**
- * drm_connector_funcs - control connectors on a given device
+ * struct drm_connector_funcs - control connectors on a given device
* @dpms: set power state (see drm_crtc_funcs above)
* @save: save connector state
* @restore: restore connector state
@@ -414,7 +414,7 @@ struct drm_connector_funcs {
};
/**
- * drm_encoder_funcs - encoder controls
+ * struct drm_encoder_funcs - encoder controls
* @reset: reset state (e.g. at init or resume time)
* @destroy: cleanup and free associated data
*
@@ -428,7 +428,7 @@ struct drm_encoder_funcs {
#define DRM_CONNECTOR_MAX_ENCODER 3
/**
- * drm_encoder - central DRM encoder structure
+ * struct drm_encoder - central DRM encoder structure
* @dev: parent DRM device
* @head: list management
* @base: base KMS object
@@ -472,7 +472,7 @@ struct drm_encoder {
#define MAX_ELD_BYTES 128
/**
- * drm_connector - central DRM connector control structure
+ * struct drm_connector - central DRM connector control structure
* @dev: parent DRM device
* @kdev: kernel device for sysfs attributes
* @attr: sysfs attributes
@@ -566,7 +566,7 @@ struct drm_connector {
};
/**
- * drm_plane_funcs - driver plane control functions
+ * struct drm_plane_funcs - driver plane control functions
* @update_plane: update the plane configuration
* @disable_plane: shut down the plane
* @destroy: clean up plane resources
@@ -594,7 +594,7 @@ enum drm_plane_type {
};
/**
- * drm_plane - central DRM plane control structure
+ * struct drm_plane - central DRM plane control structure
* @dev: DRM device this plane belongs to
* @head: for list management
* @base: base mode object
@@ -632,7 +632,7 @@ struct drm_plane {
};
/**
- * drm_bridge_funcs - drm_bridge control functions
+ * struct drm_bridge_funcs - drm_bridge control functions
* @attach: Called during drm_bridge_attach
* @mode_fixup: Try to fixup (or reject entirely) proposed mode for this bridge
* @disable: Called right before encoder prepare, disables the bridge
@@ -658,7 +658,7 @@ struct drm_bridge_funcs {
};
/**
- * drm_bridge - central DRM bridge control structure
+ * struct drm_bridge - central DRM bridge control structure
* @dev: DRM device this bridge belongs to
* @head: list management
* @base: base mode object
@@ -679,7 +679,7 @@ struct drm_bridge {
};
/**
- * drm_mode_set - new values for a CRTC config change
+ * struct drm_mode_set - new values for a CRTC config change
* @head: list management
* @fb: framebuffer to use for new config
* @crtc: CRTC whose configuration we're about to change
--
2.1.1
[PATCH] drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
Just a bit of OCD cleanup on headers - this function isn't the core
interface any more but just a helper for drivers who haven't yet
transitioned to universal planes. Put the declaration at the right
spot and sprinkle necessary #includes over all drivers.
Maybe this helps to encourage driver maintainers to do the switch.
Cc: Matt Roper
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/armada/armada_crtc.c | 1 +
drivers/gpu/drm/ast/ast_mode.c | 1 +
drivers/gpu/drm/bochs/bochs_kms.c | 1 +
drivers/gpu/drm/cirrus/cirrus_mode.c | 1 +
drivers/gpu/drm/gma500/psb_intel_display.c | 1 +
drivers/gpu/drm/mgag200/mgag200_mode.c | 1 +
drivers/gpu/drm/nouveau/dispnv04/crtc.c| 1 +
drivers/gpu/drm/nouveau/nv50_display.c | 1 +
drivers/gpu/drm/omapdrm/omap_crtc.c| 1 +
drivers/gpu/drm/qxl/qxl_display.c | 1 +
drivers/gpu/drm/radeon/radeon_display.c| 1 +
drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 +
drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 +
drivers/gpu/drm/sti/sti_drm_crtc.c | 1 +
drivers/gpu/drm/tegra/dc.c | 1 +
drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 +
drivers/gpu/drm/udl/udl_modeset.c | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 +
drivers/staging/imx-drm/imx-drm-core.c | 1 +
include/drm/drm_crtc.h | 3 ---
include/drm/drm_plane_helper.h | 4
22 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/armada/armada_crtc.c
b/drivers/gpu/drm/armada/armada_crtc.c
index 9a0cc09e6653..0b164fb1c107 100644
--- a/drivers/gpu/drm/armada/armada_crtc.c
+++ b/drivers/gpu/drm/armada/armada_crtc.c
@@ -12,6 +12,7 @@
#include
#include
#include
+#include
#include "armada_crtc.h"
#include "armada_drm.h"
#include "armada_fb.h"
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 19ada0bbe319..df986498d376 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include "ast_drv.h"
#include "ast_tables.h"
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 6b7efcf363d6..5ffd4895d040 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -6,6 +6,7 @@
*/
#include "bochs.h"
+#include
static int defx = 1024;
static int defy = 768;
diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c
b/drivers/gpu/drm/cirrus/cirrus_mode.c
index c7c5a9d91fa0..99d4a74ffeaf 100644
--- a/drivers/gpu/drm/cirrus/cirrus_mode.c
+++ b/drivers/gpu/drm/cirrus/cirrus_mode.c
@@ -16,6 +16,7 @@
*/
#include
#include
+#include
#include
diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c
b/drivers/gpu/drm/gma500/psb_intel_display.c
index 87b50ba64ed4..b21a09451d1d 100644
--- a/drivers/gpu/drm/gma500/psb_intel_display.c
+++ b/drivers/gpu/drm/gma500/psb_intel_display.c
@@ -21,6 +21,7 @@
#include
#include
+#include
#include "framebuffer.h"
#include "psb_drv.h"
#include "psb_intel_drv.h"
diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c
b/drivers/gpu/drm/mgag200/mgag200_mode.c
index 83485ab81ce8..9872ba9abf1a 100644
--- a/drivers/gpu/drm/mgag200/mgag200_mode.c
+++ b/drivers/gpu/drm/mgag200/mgag200_mode.c
@@ -15,6 +15,7 @@
#include
#include
+#include
#include "mgag200_drv.h"
diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
index b90aa5c1f90a..07acb36235cd 100644
--- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c
+++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include "nouveau_drm.h"
#include "nouveau_reg.h"
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c
b/drivers/gpu/drm/nouveau/nv50_display.c
index fdb3e1adea1e..a1fd99589ce3 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -26,6 +26,7 @@
#include
#include
+#include
#include
#include
diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c
b/drivers/gpu/drm/omapdrm/omap_crtc.c
index 2d28dc337cfb..b0566a1ca28f 100644
--- a/drivers/gpu/drm/omapdrm/omap_crtc.c
+++ b/drivers/gpu/drm/omapdrm/omap_crtc.c
@@ -20,6 +20,7 @@
#include "omap_drv.h"
#include
+#include
#include "drm_crtc.h"
#include "drm_crtc_helper.h"
diff --git a/drivers/gpu/drm/qxl/qxl_display.c
b/drivers/gpu/drm/qxl/qxl_display.c
index af9e78546688..b7b728e758b8 100644
--- a/drivers/gpu/drm/qxl/qxl_display.c
+++ b/drivers/gpu/drm/qxl/qxl_display.c
@@ -29,6 +29,7 @@
#include "qxl_drv.h"
#include "qxl_object.h"
#include "drm_crtc_helper.h"
+#include
static bool qxl_head_enabled(struct qxl_head *head)
{
diff --git a/drivers/gpu/drm/radeon/radeon_display.c
b/drivers/gpu/drm/radeon/radeon_display.c
index 4eb37976f879..ad24536ee4ce 100644
--- a/drivers/gpu/drm/radeon/radeon_display.c
+++ b/drivers/gpu/drm/radeon/radeon_d
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On 10/29/2014 08:58 AM, Daniel Vetter wrote: > On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote: >> On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote: >>> On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding >>> wrote: On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: > On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar wrote: >> On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter >> wrote: [...] >>> Hm, if you do this can you pls also update drm_panel accordingly? It >>> shouldn't be a lot of fuzz and would make things around drm+dt more >>> consistent. >> Are you talking about using struct device_node instead of struct device? >> I guess you have misplaced the comment under the wrong section! > > Yeah, that should have been one up ;-) Like I said earlier, I don't think dropping struct device * in favour of struct device_node * is a good idea. >>> I am not sure about drm_panel. >>> But, I am not really doing anything with the struct device pointer in >>> case of bridge. >>> So, just wondering if it is really needed? >> >> I think it's useful to have it just to send the right message. DRM panel >> and DRM bridge aren't specific to device tree. They are completely >> generic and can work with any type of device, whether it was >> instantiated from the device tree or some other infrastructure. Dropping >> struct device * will make it effectively useless on anything but DT. I >> don't think we should strive for that, even if only DT-enabled platforms >> currently use them. > > See my other reply, but I now think we should put neither into drm > structures. This "find me the driver structures for this device" problem > looks really generic, and it has nothing to do with the drm structures and > concepts like bridges/panels at all. It shouldn't be in there at all. > > Adding it looks very much like reintroducing the drm midlayer that we just > finally made obsolete, just not at the top-level (struct drm_device) but > at a bunch of leaf nodes. I expect all the same issues though. And I'm > definitely not looking to de-midlayer more stuff that we're just adding. > > Imo this should be solved as a separate helper thing, maybe in the driver > core akin to the component helpers from Russell. > -Daniel > As I understand you want something generic to look for panels, bridges, whatever and, like components, it should allow to safe hot plug/unplug. I have proposed such thing few months ago [1]. Have you looked at it? [1]: https://lkml.org/lkml/2014/4/30/345 Regards Andrzej
[Bug 85454] Unigine Sanctuary with Wine crashes on Mesa Git
https://bugs.freedesktop.org/show_bug.cgi?id=85454 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Michel Dänzer --- Module: Mesa Branch: master Commit: 402ab50bedf9fba7654e63a6f2e808714714284d URL: http://cgit.freedesktop.org/mesa/mesa/commit/?id=402ab50bedf9fba7654e63a6f2e808714714284d Author: Michel Dänzer Date: Tue Oct 28 11:28:29 2014 +0900 radeon/llvm: Dynamically allocate branch/loop stack arrays -- 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/20141029/3c9f4336/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Wed, Oct 29, 2014 at 09:38:23AM +0100, Thierry Reding wrote:
> On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
> > On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> > > On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > > > On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter
> > > > wrote:
> > > > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > > > wrote:
> > > > @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > > > * @driver_private: pointer to the bridge driver's internal
> > > > context
> > > > */
> > > > struct drm_bridge {
> > > > - struct drm_device *dev;
> > > > + struct device *dev;
> > > > >>>
> > > > >>> Please don't rename the ->dev pointer into drm. Because _all_ the
> > > > >>> other
> > > > >>> drm structures still call it ->dev. Also, can't we use struct
> > > > >>> device_node
> > > > >>> here like we do in the of helpers Russell added? See 7e435aad38083
> > > > >>>
> > > > >>
> > > > >> I think this is modeled after the naming in drm_panel, FWIW. However,
> > > > >> seems reasonable to keep the device_node instead.
> > > > >
> > > > > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > > > > drm_crtc drop the struct device and go directly to a struct
> > > > > device_node. Since we don't really need the sturct device, the only
> > > > > thing we care about is the of_node. For added bonus wrap an #ifdef
> > > > > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > > > > Should be all fairly simple to pull off with cocci.
> > > > >
> > > > > Thierry?
> > > >
> > > > Looking at the of_drm_find_panel function I actually wonder how that
> > > > works - the drm_panel doesn't really need to stick around afaics.
> > > > After all panel_list is global so some other driver can unload.
> > > > Russell's of support for possible_crtcs code works differently since
> > > > it only looks at per-drm_device lists.
> > >
> > > I don't understand. Panels are global resources that get registered by
> > > some driver that isn't tied to the DRM device until attached. It can't
> > > be in a per-DRM device list, because it's external to the device.
> > >
> > > And yes, they can go away when a driver is unloaded, though it's not the
> > > typical use-case.
> > >
> > > > This bridge code here though suffers from the same. So to me this
> > > > looks rather fishy.
> > >
> > > Well, this version of the DRM bridge support was written to be close to
> > > DRM panel, so it isn't really surprising that it's similar =), but like
> > > I said, I don't really understand what you think is wrong with it.
> >
> > You have a mutex to protect the global list of bridges/panels. But if you
> > do a lookup you don't grab a reference count on the panel, so the moment
> > you drop the list mutex the panel/bridge can go away.
> >
> > Yes usually you don't unload a driver on a soc but soc isn't everything
> > and designing new stuff to not be hotunplug save isn't great either.
>
> Yeah, I certainly agree that adding proper reference counting would be a
> good thing. I think perhaps we could just take a reference on the struct
> device * to prevent it from disappearing.
>
> Although perhaps I misunderstand what you mean by "go away".
I meant the drm_panel/bridge could go away any second, since nothing
prevents a module unload of the panel/bridge driver. So in theory you
could get the unregister call right after you've done the lookup. Which
means the bridge/panel pointer you've just returned is freed memory.
I think we nee try_get_module for the code and kref on the actual data
structures. That makes the entire thing a bit non-trivial, which is why I
think it would be better as some generic helper. Which then gets embedded
or instantiated for specific cases, like dt&drm_panel or dt&drm_bridge. Or
maybe even acpi&drm_bridge, who knows ;-)
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drivers: depend on instead of select BACKLIGHT_CLASS_DEVICE and ACPI_VIDEO
On Wed, 29 Oct 2014, Michael Ellerman wrote: > On Tue, 2014-10-28 at 13:29 -0700, Randy Dunlap wrote: >> On 10/27/14 06:13, Tomi Valkeinen wrote: >> > I also think the 'depends on BACKLIGHT_CLASS_DEVICE || >> > BACKLIGHT_CLASS_DEVICE=n' pattern is quite... interesting (i.e. sounds >> > like a hack to me =). >> >> It does exactly what is needed and it is used in many places in kernel >> Kconfig files. > > Is there any reason you can't do: > > depends on BACKLIGHT_CLASS_DEVICE != m That's not the same thing. The FOO || FOO=n allows for all options, but forbids it being a module when the option depending on it is built-in. Obviously something that's built-in can't depend on something built as a module. BR, Jani. -- Jani Nikula, Intel Open Source Technology Center
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Wed, Oct 29, 2014 at 08:43:14AM +0100, Daniel Vetter wrote:
> On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> > On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter
> > > wrote:
> > > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > > wrote:
> > > >>>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > > >>>> * @driver_private: pointer to the bridge driver's internal context
> > > >>>> */
> > > >>>> struct drm_bridge {
> > > >>>> - struct drm_device *dev;
> > > >>>> + struct device *dev;
> > > >>>
> > > >>> Please don't rename the ->dev pointer into drm. Because _all_ the
> > > >>> other
> > > >>> drm structures still call it ->dev. Also, can't we use struct
> > > >>> device_node
> > > >>> here like we do in the of helpers Russell added? See 7e435aad38083
> > > >>>
> > > >>
> > > >> I think this is modeled after the naming in drm_panel, FWIW. However,
> > > >> seems reasonable to keep the device_node instead.
> > > >
> > > > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > > > drm_crtc drop the struct device and go directly to a struct
> > > > device_node. Since we don't really need the sturct device, the only
> > > > thing we care about is the of_node. For added bonus wrap an #ifdef
> > > > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > > > Should be all fairly simple to pull off with cocci.
> > > >
> > > > Thierry?
> > >
> > > Looking at the of_drm_find_panel function I actually wonder how that
> > > works - the drm_panel doesn't really need to stick around afaics.
> > > After all panel_list is global so some other driver can unload.
> > > Russell's of support for possible_crtcs code works differently since
> > > it only looks at per-drm_device lists.
> >
> > I don't understand. Panels are global resources that get registered by
> > some driver that isn't tied to the DRM device until attached. It can't
> > be in a per-DRM device list, because it's external to the device.
> >
> > And yes, they can go away when a driver is unloaded, though it's not the
> > typical use-case.
> >
> > > This bridge code here though suffers from the same. So to me this
> > > looks rather fishy.
> >
> > Well, this version of the DRM bridge support was written to be close to
> > DRM panel, so it isn't really surprising that it's similar =), but like
> > I said, I don't really understand what you think is wrong with it.
>
> You have a mutex to protect the global list of bridges/panels. But if you
> do a lookup you don't grab a reference count on the panel, so the moment
> you drop the list mutex the panel/bridge can go away.
>
> Yes usually you don't unload a driver on a soc but soc isn't everything
> and designing new stuff to not be hotunplug save isn't great either.
Yeah, I certainly agree that adding proper reference counting would be a
good thing. I think perhaps we could just take a reference on the struct
device * to prevent it from disappearing.
Although perhaps I misunderstand what you mean by "go away".
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/16e89f9b/attachment.sig>
[Intel-gfx] [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver
On Tue, Oct 28, 2014 at 04:56:03PM +, Daniel Stone wrote: > Hi, > > On 17 October 2014 01:36, Jiang, Fei wrote: > > > Thanks for Emil's suggestion. You are right, we need make sure structure > > size aligned on 8 bytes, which is important for 32bit-64bit compatible case. > > > While you're at it, please don't use enum as a type inside ioctls, since > the size can vary by compiler. Please use a uint32_t or whatever instead, > assigning enum values to that. Quick correction: You must use __u32 and friends, since using the standard C typesdef might collide with some program which defines them a different way. The double underscore ones are explicit ok per the C standard as private types for the system library. So they're the only ones we can use in userspace headers. I've thought checkpatch would bitch about this if you get it wrong, now that we have the uapi split ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 04:05:34PM +0100, Thierry Reding wrote: > On Tue, Oct 28, 2014 at 08:16:44PM +0530, Ajay kumar wrote: > > On Tue, Oct 28, 2014 at 8:11 PM, Thierry Reding > > wrote: > > > On Tue, Oct 28, 2014 at 03:19:36PM +0100, Daniel Vetter wrote: > > >> On Tue, Oct 28, 2014 at 1:28 PM, Ajay kumar > > >> wrote: > > >> > On Tue, Oct 28, 2014 at 3:31 PM, Daniel Vetter > > >> > wrote: > > > [...] > > >> >> Hm, if you do this can you pls also update drm_panel accordingly? It > > >> >> shouldn't be a lot of fuzz and would make things around drm+dt more > > >> >> consistent. > > >> > Are you talking about using struct device_node instead of struct > > >> > device? > > >> > I guess you have misplaced the comment under the wrong section! > > >> > > >> Yeah, that should have been one up ;-) > > > > > > Like I said earlier, I don't think dropping struct device * in favour of > > > struct device_node * is a good idea. > > I am not sure about drm_panel. > > But, I am not really doing anything with the struct device pointer in > > case of bridge. > > So, just wondering if it is really needed? > > I think it's useful to have it just to send the right message. DRM panel > and DRM bridge aren't specific to device tree. They are completely > generic and can work with any type of device, whether it was > instantiated from the device tree or some other infrastructure. Dropping > struct device * will make it effectively useless on anything but DT. I > don't think we should strive for that, even if only DT-enabled platforms > currently use them. See my other reply, but I now think we should put neither into drm structures. This "find me the driver structures for this device" problem looks really generic, and it has nothing to do with the drm structures and concepts like bridges/panels at all. It shouldn't be in there at all. Adding it looks very much like reintroducing the drm midlayer that we just finally made obsolete, just not at the top-level (struct drm_device) but at a bunch of leaf nodes. I expect all the same issues though. And I'm definitely not looking to de-midlayer more stuff that we're just adding. Imo this should be solved as a separate helper thing, maybe in the driver core akin to the component helpers from Russell. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 03:29:47PM +0100, Thierry Reding wrote:
> On Mon, Oct 27, 2014 at 11:20:31PM +0100, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul wrote:
> > >>> @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > >>> * @driver_private: pointer to the bridge driver's internal context
> > >>> */
> > >>> struct drm_bridge {
> > >>> - struct drm_device *dev;
> > >>> + struct device *dev;
> > >>
> > >> Please don't rename the ->dev pointer into drm. Because _all_ the other
> > >> drm structures still call it ->dev. Also, can't we use struct device_node
> > >> here like we do in the of helpers Russell added? See 7e435aad38083
> > >>
> > >
> > > I think this is modeled after the naming in drm_panel, FWIW. However,
> > > seems reasonable to keep the device_node instead.
> >
> > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > drm_crtc drop the struct device and go directly to a struct
> > device_node. Since we don't really need the sturct device, the only
> > thing we care about is the of_node. For added bonus wrap an #ifdef
> > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > Should be all fairly simple to pull off with cocci.
> >
> > Thierry?
>
> The struct device * is in DRM panel because there's nothing device tree
> specific about the concept. Having a struct device_node * instead would
> indicate that it can only be used with a device tree, whereas the
> framework doesn't care the tiniest bit what type of device we have.
>
> While the trend clearly is to use more device tree, I don't think we
> should make it impossible for anybody else to use these frameworks.
>
> There are other advantages to keeping a struct device *, like having
> access to the proper device and its name. Also you get access to the
> device_node * via dev->of_node anyway. I don't see any advantage in
> switching to just a struct device_node *, only disadvantages.
Well the idea is to make the lookup key specific, and conditional on
#CONFIG_OF. If there's going to be another neat way to enumerate platform
devices then I think we should add that, too. Or maybe we should have a
void *platform_data or so.
The reason I really don't want a struct device * in core drm structures is
that two releases down the road people will have found tons of really
great ways to abuse them and re-create a midlayer. DRM core really should
only care about the sw objects and not be hw specific at all. Heck there's
not even an requirement to have any piece of actual hw, you could write a
completely fake drm driver (for e.g. testing like the new v4l driver).
Tbh I wonder a bit why we even have this registery embedded into the core
drm objects. Essentially the only thing you're doing is a list that maps
some platform specific key onto some subsystem specific driver structure
or fails the lookup. So instead of putting all these low-level details
into drm core structures can't we just have a generic hashtable/list for
this, plus some static inline helpers that cast the void * you get into
the one you want?
I also get the feeling that this really should be in the driver core (like
the component helpers), and that we should think a lot harder about
lifetimes and refcounting (see my other reply on that).
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 86891] AMD/ATI Tahiti XT 7970 - long lags/stutters in games
https://bugzilla.kernel.org/show_bug.cgi?id=86891 Michel Dänzer changed: What|Removed |Added CC||curaga at operamail.com --- Comment #7 from Michel Dänzer --- Does Mesa 10.3.2 work better, specifically commit 64c2bdc334ba472603b1e7cd2c3046cfbce285b6? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 85579] [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 --- Comment #2 from Michel Dänzer --- Created attachment 108612 --> https://bugs.freedesktop.org/attachment.cgi?id=108612&action=edit radeonsi: If compiling the vertex or geometry shader fails, skip the draw Does this patch fix the crash? -- 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/20141029/20421b0c/attachment.html>
[PATCH V7 03/12] drm/bridge: Add helper functions for drm_bridge
On Tue, Oct 28, 2014 at 03:35:50PM +0100, Thierry Reding wrote:
> On Mon, Oct 27, 2014 at 11:26:30PM +0100, Daniel Vetter wrote:
> > On Mon, Oct 27, 2014 at 11:20 PM, Daniel Vetter wrote:
> > > On Mon, Oct 27, 2014 at 8:58 PM, Sean Paul
> > > wrote:
> > @@ -660,8 +662,11 @@ struct drm_bridge_funcs {
> > * @driver_private: pointer to the bridge driver's internal context
> > */
> > struct drm_bridge {
> > - struct drm_device *dev;
> > + struct device *dev;
> > >>>
> > >>> Please don't rename the ->dev pointer into drm. Because _all_ the other
> > >>> drm structures still call it ->dev. Also, can't we use struct
> > >>> device_node
> > >>> here like we do in the of helpers Russell added? See 7e435aad38083
> > >>>
> > >>
> > >> I think this is modeled after the naming in drm_panel, FWIW. However,
> > >> seems reasonable to keep the device_node instead.
> > >
> > > Hm, indeed. Tbh I vote to rename drm_panel->drm to ->dev and like with
> > > drm_crtc drop the struct device and go directly to a struct
> > > device_node. Since we don't really need the sturct device, the only
> > > thing we care about is the of_node. For added bonus wrap an #ifdef
> > > CONFIG_OF around all the various struct device_node in drm_foo.h.
> > > Should be all fairly simple to pull off with cocci.
> > >
> > > Thierry?
> >
> > Looking at the of_drm_find_panel function I actually wonder how that
> > works - the drm_panel doesn't really need to stick around afaics.
> > After all panel_list is global so some other driver can unload.
> > Russell's of support for possible_crtcs code works differently since
> > it only looks at per-drm_device lists.
>
> I don't understand. Panels are global resources that get registered by
> some driver that isn't tied to the DRM device until attached. It can't
> be in a per-DRM device list, because it's external to the device.
>
> And yes, they can go away when a driver is unloaded, though it's not the
> typical use-case.
>
> > This bridge code here though suffers from the same. So to me this
> > looks rather fishy.
>
> Well, this version of the DRM bridge support was written to be close to
> DRM panel, so it isn't really surprising that it's similar =), but like
> I said, I don't really understand what you think is wrong with it.
You have a mutex to protect the global list of bridges/panels. But if you
do a lookup you don't grab a reference count on the panel, so the moment
you drop the list mutex the panel/bridge can go away.
Yes usually you don't unload a driver on a soc but soc isn't everything
and designing new stuff to not be hotunplug save isn't great either.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
NULL derefs after failed suspend (i915, pm, ext4, slub)
On Tue, Oct 28, 2014 at 05:06:01PM +0200, Jani Nikula wrote: > On Tue, 28 Oct 2014, Johan Hovold wrote: > > Hi, > > > > I have had some problems with crashes involving suspend-to-disk after > > updating to v3.16. > > > > Below is a log with 3.16.6 from a failed suspend attempt after which I > > get a NULL deref in ext4 code. > > > > A couple of weeks ago I got something similar, with backtraces from > > ext4 (ext4_alloc_inode) and NULL-derefs in vfs (vfs_get_attr_nosec) when > > trying to do IO after resuming from suspend. That was with 3.16.3 and I > > was hoping that whatever it was would have been fixed in 3.16.6 (there > > were some ext4 error handling patches in there). I only got photos of > > those oopses but it involved kmem_cache_alloc (slub) and a NULL-deref in > > vfs_get_attr_nosec. I can put the photos up somewhere. That time I also > > got back to X and could issue a dmesg in an xterm, but any process trying > > to do IO died. > > > > Something similar happened with 3.16.1 but unfortunately I do not have > > any logs from that. > > > > I also have experienced occasional hangs during suspend, but I believe I > > have seen this with older kernels as well so not sure if related. Seems > > to be more frequent with 3.16. > > > > This is my main machine so not keen on trying to bisect this on it. > > > > It's an i7-4770 on an Intel DH87MC using the integrated HD Graphics 4600. > > > > I'm CCing the Intel graphics guys due to some errors drm errors in the > > logs, and reports of other people having problems involving suspend and > > this driver. > > My first suggestion would be to try to reproduce the NULL deref without > i915 loaded, and track the issues you have independently. I actually don't think this is i915 related, the new drm errors after failed suspend could possibly just be a side effect of whatever is causing the apparent memory corruption. As I mentioned, the first log I have of this do not seem to point at i915 (even if backlight-restore happens when tasks are restarted). > Please file any i915 issues against DRM/Intel at [1]. I'll see if I can get around to that. There are bug reports in various distro tracker about the intel_ddi_pll_enable warning dating back to April. It's there on every resume. For instance this morning: [108109.324398] WARNING: CPU: 1 PID: 7298 at /home/johan/src/linux/linux-xi/drivers/gpu/drm/i915/intel_ddi.c:911 intel_ddi_pll_enable+0x233/0x240() [108109.324398] WRPLL1 already enabled [108109.324399] Modules linked in: [108109.324400] CPU: 1 PID: 7298 Comm: kworker/u16:8 Tainted: GW 3.16.6 #1 [108109.324401] Hardware name: /DH87MC, BIOS MCH8710H.86A.0154.2014.0123.1542 01/23/2014 [108109.324403] Workqueue: events_unbound async_run_entry_fn [108109.324405] 0009 81739c03 88053e89baf8 [108109.324405] 810850f6 8807fadf b035061f 0001 [108109.324406] 00046040 81a10a41 810851d5 81a10a83 [108109.324407] Call Trace: [108109.324410] [] ? dump_stack+0x49/0x6a [108109.324412] [] ? warn_slowpath_common+0x86/0xb0 [108109.324414] [] ? warn_slowpath_fmt+0x45/0x50 [108109.324415] [] ? intel_ddi_pll_enable+0x233/0x240 [108109.324417] [] ? haswell_crtc_mode_set+0x1a/0x30 [108109.324419] [] ? __intel_set_mode+0x6a8/0x1590 [108109.324420] [] ? intel_modeset_setup_hw_state+0x817/0xd10 [108109.324422] [] ? drm_modeset_lock_all_crtcs+0x39/0x50 [108109.324424] [] ? pci_pm_suspend_noirq+0x1b0/0x1b0 [108109.324426] [] ? __i915_drm_thaw+0x11e/0x1a0 [108109.324426] [] ? i915_resume+0x1f/0x40 [108109.324428] [] ? dpm_run_callback+0x4f/0x150 [108109.324428] [] ? device_resume+0x93/0x1d0 [108109.324429] [] ? async_resume+0x14/0x40 [108109.324430] [] ? async_run_entry_fn+0x2d/0x120 [108109.324433] [] ? process_one_work+0x158/0x410 [108109.324434] [] ? worker_thread+0x116/0x510 [108109.324435] [] ? __wake_up_common+0x4c/0x80 [108109.324436] [] ? init_pwq+0x160/0x160 [108109.324437] [] ? kthread+0xbc/0xe0 [108109.324439] [] ? workqueue_sysfs_register+0x110/0x150 [108109.324440] [] ? kthread_freezable_should_stop+0x60/0x60 [108109.324442] [] ? ret_from_fork+0x7c/0xb0 [108109.324443] [] ? kthread_freezable_should_stop+0x60/0x60 Thanks, Johan
[Intel-gfx] [PATCH] drm/i915: don't try using training pattern 3 on pre-haswell
On Wed, Oct 29, 2014 at 05:02:50PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Ivybridge + 30" monitor prints a drm error on every modeset, since
> IVB doesn't support DP3 we should even bother trying to use it.
>
> Reviewed-by: Daniel Vetter (on irc)
> Signed-off-by: Dave Airlie
This regression has been introduced in
commit 06ea66b6bb445043dc25a9626254d5c130093199
Author: Todd Previte
Date: Mon Jan 20 10:19:39 2014 -0700
drm/i915: Enable 5.4Ghz (HBR2) link rate for Displayport 1.2-capable devices
Cc: Todd Previte
Cc: stable at vger.kernel.org
Jani, can you please pick this one up?
-Daniel
> ---
> drivers/gpu/drm/i915/intel_dp.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index f6a3fdd..87cfb92 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -3547,13 +3547,15 @@ intel_dp_start_link_train(struct intel_dp *intel_dp)
> void
> intel_dp_complete_link_train(struct intel_dp *intel_dp)
> {
> + struct drm_encoder *encoder = &dp_to_dig_port(intel_dp)->base.base;
> + struct drm_device *dev = encoder->dev;
> bool channel_eq = false;
> int tries, cr_tries;
> uint32_t DP = intel_dp->DP;
> uint32_t training_pattern = DP_TRAINING_PATTERN_2;
>
> /* Training Pattern 3 for HBR2 ot 1.2 devices that support it*/
> - if (intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3)
> + if ((intel_dp->link_bw == DP_LINK_BW_5_4 || intel_dp->use_tps3) &&
> !HAS_DDI(dev))
> training_pattern = DP_TRAINING_PATTERN_3;
>
> /* channel equalization */
> --
> 1.9.3
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 85580] [RadeonSI] Bad performance in TF2.
https://bugs.freedesktop.org/show_bug.cgi?id=85580 --- Comment #1 from Michel Dänzer --- (In reply to Aaron B from comment #0) > Polygon count just makes it too heavy to what it used to be, dipping down to > 20FPS or so when moving objects and such. Have you double-checked that direct rendering and hardware acceleration are working for 32-bit processes? Did you build 32-bit Mesa as well? > I don't have time to bisect, [...] So it's a regression? In what kind of time-frame? -- 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/20141029/9ba7260e/attachment.html>
[PATCH] drm: Move drm_crtc_init from drm_crtc.h to drm_plane_helper.h
On Wed, Oct 29, 2014 at 10:11:25AM +0100, Daniel Vetter wrote: > Just a bit of OCD cleanup on headers - this function isn't the core > interface any more but just a helper for drivers who haven't yet > transitioned to universal planes. Put the declaration at the right > spot and sprinkle necessary #includes over all drivers. > > Maybe this helps to encourage driver maintainers to do the switch. > > Cc: Matt Roper > Signed-off-by: Daniel Vetter Reviewed-by: Matt Roper > --- > drivers/gpu/drm/armada/armada_crtc.c | 1 + > drivers/gpu/drm/ast/ast_mode.c | 1 + > drivers/gpu/drm/bochs/bochs_kms.c | 1 + > drivers/gpu/drm/cirrus/cirrus_mode.c | 1 + > drivers/gpu/drm/gma500/psb_intel_display.c | 1 + > drivers/gpu/drm/mgag200/mgag200_mode.c | 1 + > drivers/gpu/drm/nouveau/dispnv04/crtc.c| 1 + > drivers/gpu/drm/nouveau/nv50_display.c | 1 + > drivers/gpu/drm/omapdrm/omap_crtc.c| 1 + > drivers/gpu/drm/qxl/qxl_display.c | 1 + > drivers/gpu/drm/radeon/radeon_display.c| 1 + > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 1 + > drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 1 + > drivers/gpu/drm/sti/sti_drm_crtc.c | 1 + > drivers/gpu/drm/tegra/dc.c | 1 + > drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 1 + > drivers/gpu/drm/udl/udl_modeset.c | 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c| 1 + > drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 1 + > drivers/staging/imx-drm/imx-drm-core.c | 1 + > include/drm/drm_crtc.h | 3 --- > include/drm/drm_plane_helper.h | 4 > 22 files changed, 24 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/armada/armada_crtc.c > b/drivers/gpu/drm/armada/armada_crtc.c > index 9a0cc09e6653..0b164fb1c107 100644 > --- a/drivers/gpu/drm/armada/armada_crtc.c > +++ b/drivers/gpu/drm/armada/armada_crtc.c > @@ -12,6 +12,7 @@ > #include > #include > #include > +#include > #include "armada_crtc.h" > #include "armada_drm.h" > #include "armada_fb.h" > diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c > index 19ada0bbe319..df986498d376 100644 > --- a/drivers/gpu/drm/ast/ast_mode.c > +++ b/drivers/gpu/drm/ast/ast_mode.c > @@ -31,6 +31,7 @@ > #include > #include > #include > +#include > #include "ast_drv.h" > > #include "ast_tables.h" > diff --git a/drivers/gpu/drm/bochs/bochs_kms.c > b/drivers/gpu/drm/bochs/bochs_kms.c > index 6b7efcf363d6..5ffd4895d040 100644 > --- a/drivers/gpu/drm/bochs/bochs_kms.c > +++ b/drivers/gpu/drm/bochs/bochs_kms.c > @@ -6,6 +6,7 @@ > */ > > #include "bochs.h" > +#include > > static int defx = 1024; > static int defy = 768; > diff --git a/drivers/gpu/drm/cirrus/cirrus_mode.c > b/drivers/gpu/drm/cirrus/cirrus_mode.c > index c7c5a9d91fa0..99d4a74ffeaf 100644 > --- a/drivers/gpu/drm/cirrus/cirrus_mode.c > +++ b/drivers/gpu/drm/cirrus/cirrus_mode.c > @@ -16,6 +16,7 @@ > */ > #include > #include > +#include > > #include > > diff --git a/drivers/gpu/drm/gma500/psb_intel_display.c > b/drivers/gpu/drm/gma500/psb_intel_display.c > index 87b50ba64ed4..b21a09451d1d 100644 > --- a/drivers/gpu/drm/gma500/psb_intel_display.c > +++ b/drivers/gpu/drm/gma500/psb_intel_display.c > @@ -21,6 +21,7 @@ > #include > > #include > +#include > #include "framebuffer.h" > #include "psb_drv.h" > #include "psb_intel_drv.h" > diff --git a/drivers/gpu/drm/mgag200/mgag200_mode.c > b/drivers/gpu/drm/mgag200/mgag200_mode.c > index 83485ab81ce8..9872ba9abf1a 100644 > --- a/drivers/gpu/drm/mgag200/mgag200_mode.c > +++ b/drivers/gpu/drm/mgag200/mgag200_mode.c > @@ -15,6 +15,7 @@ > > #include > #include > +#include > > #include "mgag200_drv.h" > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > index b90aa5c1f90a..07acb36235cd 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/crtc.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/crtc.c > @@ -26,6 +26,7 @@ > > #include > #include > +#include > > #include "nouveau_drm.h" > #include "nouveau_reg.h" > diff --git a/drivers/gpu/drm/nouveau/nv50_display.c > b/drivers/gpu/drm/nouveau/nv50_display.c > index fdb3e1adea1e..a1fd99589ce3 100644 > --- a/drivers/gpu/drm/nouveau/nv50_display.c > +++ b/drivers/gpu/drm/nouveau/nv50_display.c > @@ -26,6 +26,7 @@ > > #include > #include > +#include > #include > > #include > diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c > b/drivers/gpu/drm/omapdrm/omap_crtc.c > index 2d28dc337cfb..b0566a1ca28f 100644 > --- a/drivers/gpu/drm/omapdrm/omap_crtc.c > +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c > @@ -20,6 +20,7 @@ > #include "omap_drv.h" > > #include > +#include > #include "drm_crtc.h" > #include "drm_crtc_helper.h" > > diff --git a/drivers/gpu/drm/qxl/qxl_display.c > b/drivers/gpu/drm/qxl/qxl_display.c > index af9e78546688..b7b728e758b8 100644 > --- a/drivers/gpu/drm/qxl/qxl_display.c > +++ b/d
[RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver
Hi Daniel, weâve resolved this in patch v2. From: Daniel Stone [mailto:dan...@fooishbar.org] Sent: Wednesday, October 29, 2014 0:56 To: Jiang, Fei Cc: Emil Velikov; Cheng, Yao; intel-gfx at lists.freedesktop.org; Vetter, Daniel; dri-devel at lists.freedesktop.org Subject: Re: [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver Hi, On 17 October 2014 01:36, Jiang, Fei mailto:fei.jiang at intel.com>> wrote: Thanks for Emil's suggestion. You are right, we need make sure structure size aligned on 8 bytes, which is important for 32bit-64bit compatible case. While you're at it, please don't use enum as a type inside ioctls, since the size can vary by compiler. Please use a uint32_t or whatever instead, assigning enum values to that. Cheers, Daniel Fei -Original Message- From: Emil Velikov [mailto:emil.l.velikov at gmail.com<mailto:emil.l.veli...@gmail.com>] Sent: Thursday, October 16, 2014 11:20 PM To: Cheng, Yao; intel-gfx at lists.freedesktop.org<mailto:intel-gfx at lists.freedesktop.org> Cc: emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>; Jiang, Fei; dri-devel at lists.freedesktop.org<mailto:dri-devel at lists.freedesktop.org>; Vetter, Daniel Subject: Re: [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm driver On 16/10/14 15:33, Cheng, Yao wrote: > Hi Emil, > Sorry, what do you mean by "correctly aligned"? does it mean the paddings in > this data structure? > Afaict for compatibility reasons the struct size have to be "aligned" (multiple of 8 bytes), or if you prefer - the struct is missing the required padding :) I've only skimmed through the patch so it may be that other structs are having this issue. Cheers, Emil >> -Original Message- >> From: Emil Velikov [mailto:emil.l.velikov at gmail.com<mailto:emil.l.velikov >> at gmail.com>] >> Sent: Wednesday, October 15, 2014 5:24 PM >> To: Cheng, Yao; intel-gfx at lists.freedesktop.org<mailto:intel-gfx at >> lists.freedesktop.org> >> Cc: emil.l.velikov at gmail.com<mailto:emil.l.velikov at gmail.com>; Jiang, >> Fei; >> dri-devel at lists.freedesktop.org<mailto:dri-devel at >> lists.freedesktop.org>; Vetter, Daniel >> Subject: Re: [RFC PATCH 3/3] libdrm: user mode helper for ipvr drm >> driver >> >> Hi Yao, >> >> struct drm_ipvr_gem_userptr does not seem to be correctly aligned - >> is that intentional ? Might be worth checking if anything else in >> ipvr_drm.h and ipvr_bufmgr.h is in the same boat. >> >> Cheers, >> Emil >> ___ dri-devel mailing list dri-devel at lists.freedesktop.org<mailto:dri-devel at lists.freedesktop.org> http://lists.freedesktop.org/mailman/listinfo/dri-devel -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141029/abc06763/attachment.html>
[Bug 82109] Firefox crashes Google Maps, likely related to graphics driver
https://bugs.freedesktop.org/show_bug.cgi?id=82109 Michel Dänzer changed: What|Removed |Added Status|NEW |NEEDINFO CC||fabrizio.ge at tiscali.it --- Comment #5 from Michel Dänzer --- Let me point out bug 81680 again. It may be the same bug, but if the fix for it doesn't help for this problem, please resolve the symbols for the crash report as described there. -- 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/20141029/c0746245/attachment.html>
[Bug 85580] New: [RadeonSI] Bad performance in TF2.
https://bugs.freedesktop.org/show_bug.cgi?id=85580 Bug ID: 85580 Summary: [RadeonSI] Bad performance in TF2. Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel at lists.freedesktop.org Reporter: aaronbottegal at gmail.com I built Mesa just a few days ago with LLVM 3.5, git mesa, 3.18-rc2 kernel. Performance is just horrible with tons of dips when playing TF2, and probably other Valve games. Polygon count just makes it too heavy to what it used to be, dipping down to 20FPS or so when moving objects and such. I don't have time to bisect, don't even know how much longer I will be using this R9 270X, so any tests I can do without a recompile I can try. Benchmarks like glmark2 are fine, but in-game performance is just bad. -- 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/20141029/f2e573eb/attachment-0001.html>
[Bug 85526] Screen corruptions in OpenGL reliant applications
https://bugs.freedesktop.org/show_bug.cgi?id=85526 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #18 from Michel Dänzer --- *** This bug has been marked as a duplicate of bug 84627 *** -- 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/20141029/28dee80c/attachment.html>
[Bug 84627] (bisected) 32bit corruption with PIPE_USAGE_STREAM reverted
https://bugs.freedesktop.org/show_bug.cgi?id=84627 Michel Dänzer changed: What|Removed |Added CC||hamish at icculus.org --- Comment #26 from Michel Dänzer --- *** Bug 85526 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/20141029/fb31afff/attachment.html>
[Bug 85579] [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 --- Comment #1 from sarnex --- Created attachment 108603 --> https://bugs.freedesktop.org/attachment.cgi?id=108603&action=edit log when the test crashes -- 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/20141029/9aa1b090/attachment-0001.html>
[Bug 85579] New: [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components
https://bugs.freedesktop.org/show_bug.cgi?id=85579 Bug ID: 85579 Summary: [bisected] piglit test crashes in spec/glsl-1.50/execution/geometry/max-input-components 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: commendsarnex at gmail.com Created attachment 108602 --> https://bugs.freedesktop.org/attachment.cgi?id=108602&action=edit log when the test fails Hi again guys. I've been getting some very weird piglit crashes, including one lockup, which I haven't yet been able to bisect. Anyway, here's one I've been able to bisect. The test spec/glsl-1.50/execution/geometry/max-input-components fails before commit 54de7099115502c561f5f51095e08dc0a52c71b7, and always crashes on commits after. I have attached the piglit result logs from both versions. I'm not sure if the LLVM Register Spilling spam is relating to my other problems, or not. Let me know if you need any more information. Thanks, sarnex -- 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/20141029/694cee2a/attachment.html>
[Bug 85421] radeon stalled, GPU lockup, reset and failed on resume; crashed by firefox.
https://bugzilla.kernel.org/show_bug.cgi?id=85421 --- Comment #9 from Hin-Tak Leung --- FWIW, I am glad I haven't had a lock up since the last time I wrote (over two weeks ago). FWIW, all the patches I mentioned in comment 1 except two are integrated and therefore dropped with my current kernel 3.16.6- (and I haven't upgraded/downgraded anything else actively); so it looks like improvements are being made. I hope I don't see that error again :-). -- You are receiving this mail because: You are watching the assignee of the bug.
