Selecting memory manager for embedded DRM device
Hello, I'm looking onto writing DRM/KMS drivers for few pieces of embedded equipment. I stumbled upon selecting GEM/TTM/whatever for them. Could you please guide me? >From my point of view, there are two major cases: 1) Device with embedded/separate VRAM. 2) Device using system memory w/o any restrictions. Those are embedded devices hanging on memory bus, so no such things as AGP, aperture exist. I'm looking for advice on selecting proper MM. -- With best wishes Dmitry
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On 02/03/2014 04:10 AM, Ilia Mirkin wrote: > Hi Alexandre, > > On Fri, Jan 31, 2014 at 10:16 PM, Alexandre Courbot > wrote: >> I guess my email address might surprise some of you, so let me anticipate >> some >> questions you might have. :P Yes, this work is endorsed by NVIDIA. Several >> other >> NVIDIAns (CC'd), including core GPU experts, have provided significant >> technical >> guidance and will continue their involvement. Special thanks go to Terje >> Bergstrom and Ken Adams for their invaluable GPU expertise, and Thierry >> Reding >> (at FOSDEM this weekend) for help with debugging and user-space testing. >> >> Let me also stress that although very exciting, this effort is still >> experimental, so I would like to make sure that nobody makes excessive >> expectations based on these few patches. The scope of this work is strictly >> limited to Tegra (although given the similarities desktop GPU support will >> certainly benefit from it indirectly), and we do not have any plan to work on >> user-space support. So do not uninstall that proprietary driver just yet. ;) >> >> With this being clarified, we are looking forward to getting your feedback >> and >> working with you guys to bring and improve Tegra K1 support into Nouveau! :) > > I've sent a couple of fairly trivial comments, as you saw, and I > suspect that others with a better understanding of the guts will have > more substantial architectural feedback, esp after the weekend/FOSDEM. > However, since no one's said it already -- welcome to Nouveau! Thanks! ^_^v One beginner question: is it appropriate to send kernel patches to the nouveau list in addition to dri-devel? The moderation messages I receive make me think that this list might rather be intended for general discussion. > From the looks of it, you could bring up a full open-source stack with > your patches (i.e. Xorg + nouveau DDX + mesa) and use PRIME to render > stuff (assuming the actual display hw has an X ddx). Although I > suspect that you're going to want to use your own drivers. Still a > little curious if you've tried the open-source stack and whether it > worked. [Not sure what the status is of render-node support is in > mesa, but perhaps it's enough to try running piglit tests, if you > can't get X going with the display HW.] We are still testing things at libdrm level, but are eventually interested in bringing up the existing open-source stack. Our guess (and hope) is that it will work nicely almost as-is, minus the fact that the display hardware is not handled by Nouveau and we only support render nodes (I have yet to look at what the state of render nodes in Mesa is). For X, Thierry is IIUC working on the display driver, and at some point these efforts should join to connect tegradrm and Nouveau using PRIME. We are not quite there yet, and since we are working with limited resources it will likely require some time, but the fact we could bring up a (seemingly) working Nouveau kernel driver with so little code is encouraging. Thanks, Alex.
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Mon, Feb 3, 2014 at 1:14 PM, Ilia Mirkin wrote: > On Sun, Feb 2, 2014 at 9:44 PM, Alexandre Courbot > wrote: >> One beginner question: is it appropriate to send kernel patches to the >> nouveau list in addition to dri-devel? The moderation messages I receive >> make me think that this list might rather be intended for general >> discussion. > > I usually do. The main thing is to make sure that they're To: Ben, > since he's the one who will be ultimately be picking them up. I think > that if you're not subscribed, all the lists.freedesktop.org lists > moderate you, but dri-devel is configured not to tell you about it. > Also I've been getting bounce messages from nouveau@ complaining of > too many cc's and so it's getting auto-moderated -- not sure who, if > anyone, is an admin of the nouveau list. Hopefully someone :) The Nouveau list seems the most appropriate. There's not really any need to explicitly CC me either, I do watch the list :) > > -ilia > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74347] openra screen corruption on a HD2600
https://bugs.freedesktop.org/show_bug.cgi?id=74347 higuita at gmx.net changed: What|Removed |Added Component|Drivers/Gallium/r600|Drivers/DRI/Radeon --- Comment #2 from higuita at gmx.net --- with R600_DEBUG=noinvalrange the screen show up fine, without any corruption.. but the game seems slower (but i might be wrong) So what do i do with this? add to the openra startup script or this was just to help debuging? thanks for the help. -- 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/20140203/afc79522/attachment.html>
[Bug 73418] OpenCL hangs graphics on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=73418 --- Comment #11 from chris --- Worked for me too with dev branch. Thanks! -- 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/20140203/464495be/attachment.html>
[Bug 74428] System crashes from Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 Michel D?nzer changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|Mesa Version|7.3 (2007.09) |git Component|Driver/Radeon |Drivers/Gallium/r600 -- 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/20140203/80fe815e/attachment.html>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 Michel D?nzer changed: What|Removed |Added Component|Drivers/DRI/R600|Drivers/Gallium/r600 --- Comment #1 from Michel D?nzer --- Please attach your Xorg.0.log file and the output of dmesg. -- 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/20140203/e2c6feb0/attachment.html>
[Bug 74420] EQ overflowing - recurring total X crash
https://bugs.freedesktop.org/show_bug.cgi?id=74420 --- Comment #2 from lockheed --- Created attachment 93265 --> https://bugs.freedesktop.org/attachment.cgi?id=93265&action=edit Xorg.0.log Xorg log up until the manual reboot after 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/20140203/ee8a8d0b/attachment.html>
[Bug 73530] Asus U38N: Black screen with Radeon driver in Linux 3.10, 3.11, 3.12, 3.13
https://bugs.freedesktop.org/show_bug.cgi?id=73530 --- Comment #59 from Paul Menzel --- One other though, could you talk with your appartment to get you an Asus U38N-C4010 laptop so you can work with it (probably quicker than relying on and relaying stuff to me) and so you also have it in your test equipment for your QA (quality assurance)? -- 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/20140203/f68880d6/attachment-0001.html>
[Bug 74347] openra screen corruption on a HD2600
https://bugs.freedesktop.org/show_bug.cgi?id=74347 --- Comment #4 from Alex Deucher --- Can you also try disabling AGP? Boot with radeon.agpmode=-1 on the kernel command line in grub. -- 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/20140203/04a04b7b/attachment-0001.html>
[PATCH 1/1] drm/exynos: Fix build error in exynos_hdmi.c
2014-01-31 Josh Boyer :
> On Fri, Jan 31, 2014 at 1:09 AM, Sachin Kamat
> wrote:
>> 'hdmi_infoframe' is already defined in include/linux/hdmi.h.
>> Rename the local variable to avoid the following build error:
>> drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe' defined
>> as wrong kind of tag
>> struct hdmi_infoframe {
>>
>> Signed-off-by: Sachin Kamat
>> Reported-by: Josh Boyer
>
> This does fix the build error I saw. I don't have hardware to test
> the results with, but it now compiles correctly. Thanks for the quick
> turn around!
>
Hi,
Thanks for report and patch. But Sean posted already below patch,
[PATCH v4 01/34] drm/exynos: Rename hdmi_infoframe to avoid collision
Thanks,
Inki Dae
> josh
>
>> ---
>> drivers/gpu/drm/exynos/exynos_hdmi.c |6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> index a0e10ae..0d4407c 100644
>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>> @@ -379,7 +379,7 @@ static const struct hdmiphy_config hdmiphy_v14_configs[]
>> = {
>> },
>> };
>>
>> -struct hdmi_infoframe {
>> +struct hdmi_frameinfo {
>> enum HDMI_PACKET_TYPE type;
>> u8 ver;
>> u8 len;
>> @@ -682,7 +682,7 @@ static u8 hdmi_chksum(struct hdmi_context *hdata,
>> }
>>
>> static void hdmi_reg_infoframe(struct hdmi_context *hdata,
>> - struct hdmi_infoframe *infoframe)
>> + struct hdmi_frameinfo *infoframe)
>> {
>> u32 hdr_sum;
>> u8 chksum;
>> @@ -985,7 +985,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
>>
>> static void hdmi_conf_init(struct hdmi_context *hdata)
>> {
>> - struct hdmi_infoframe infoframe;
>> + struct hdmi_frameinfo infoframe;
>>
>> /* disable HPD interrupts from HDMI IP block, use GPIO instead */
>> hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
>> --
>> 1.7.9.5
>>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74428] System crashes from Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 --- Comment #3 from Alex Deucher --- Does disabling hyperz help? set env var: R600_DEBUG=nohyperz -- 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/20140203/3c986bca/attachment-0001.html>
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
Hi [..snip..] > Finally, support for probing GK20A is added in the last 2 patches. It should > be > noted that contrary to what Nouveau currently expects, GK20A does not embed > any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's > instantiation > of Nouveau into a render-node only driver without breaking support for > existing > desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which > we > should try to get rid of. You cannot get rid of cardX currently. It is implied by DRIVER_MODESET and that flag should actually be called NOT_A_LEGACY_DRIVER. So you cannot remove it. I did try to replace DRIVER_MODESET by an inverted DRIVER_LEGACY flag some time ago, but I thought it's not worth it. Anyhow, you can easily add a new flag to make drm_dev_register()/drm_dev_alloc() not create the drm_minor for DRM_MINOR_LEGACY, which would prevent the card0 node from showing up. But people started using the cardX interface as base interface so mesa might not be able to open render-nodes if the related card-node is not available (which is a bug in their code, so no reason to support that by not adding stand-alone render-nodes). Long story short: If you want to do it properly, just add a flag to DRM core that prevents DRM_MINOR_LEGACY from showing up. If you just want it to work, simply keep a dummy card0. Thanks David
[PATCH] dma-buf: update debugfs output
Russell King observed 'wierd' looking output from debugfs, and also suggested
better ways of getting device names (use KBUILD_MODNAME, dev_name())
This patch addresses these issues to make the debugfs output correct and better
looking.
Signed-off-by: Sumit Semwal
---
drivers/base/dma-buf.c | 18 --
include/linux/dma-buf.h | 2 +-
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/drivers/base/dma-buf.c b/drivers/base/dma-buf.c
index cfe1d8b..bf89fe3 100644
--- a/drivers/base/dma-buf.c
+++ b/drivers/base/dma-buf.c
@@ -621,7 +621,7 @@ static int dma_buf_describe(struct seq_file *s)
return ret;
seq_printf(s, "\nDma-buf Objects:\n");
- seq_printf(s, "\texp_name\tsize\tflags\tmode\tcount\n");
+ seq_printf(s, "size\tflags\tmode\tcount\texp_name\n");
list_for_each_entry(buf_obj, &db_list.head, list_node) {
ret = mutex_lock_interruptible(&buf_obj->lock);
@@ -632,24 +632,22 @@ static int dma_buf_describe(struct seq_file *s)
continue;
}
- seq_printf(s, "\t");
-
- seq_printf(s, "\t%s\t%08zu\t%08x\t%08x\t%08ld\n",
- buf_obj->exp_name, buf_obj->size,
+ seq_printf(s, "%08zu\t%08x\t%08x\t%08ld\t%s\n",
+ buf_obj->size,
buf_obj->file->f_flags, buf_obj->file->f_mode,
- (long)(buf_obj->file->f_count.counter));
+ (long)(buf_obj->file->f_count.counter),
buf_obj->exp_name);
- seq_printf(s, "\t\tAttached Devices:\n");
+ seq_printf(s, "\tAttached Devices:\n");
attach_count = 0;
list_for_each_entry(attach_obj, &buf_obj->attachments, node) {
- seq_printf(s, "\t\t");
+ seq_printf(s, "\t");
- seq_printf(s, "%s\n", attach_obj->dev->init_name);
+ seq_printf(s, "%s\n", dev_name(attach_obj->dev));
attach_count++;
}
- seq_printf(s, "\n\t\tTotal %d devices attached\n",
+ seq_printf(s, "\nTotal %d devices attached\n",
attach_count);
count++;
diff --git a/include/linux/dma-buf.h b/include/linux/dma-buf.h
index dfac5ed..f886985 100644
--- a/include/linux/dma-buf.h
+++ b/include/linux/dma-buf.h
@@ -171,7 +171,7 @@ struct dma_buf *dma_buf_export_named(void *priv, const
struct dma_buf_ops *ops,
size_t size, int flags, const char *);
#define dma_buf_export(priv, ops, size, flags) \
- dma_buf_export_named(priv, ops, size, flags, __FILE__)
+ dma_buf_export_named(priv, ops, size, flags, KBUILD_MODNAME)
int dma_buf_fd(struct dma_buf *dmabuf, int flags);
struct dma_buf *dma_buf_get(int fd);
--
1.8.3.2
[Bug 74347] openra screen corruption on a HD2600
https://bugs.freedesktop.org/show_bug.cgi?id=74347 Marek Ol??k changed: What|Removed |Added Component|Drivers/DRI/Radeon |Drivers/Gallium/r600 --- Comment #3 from Marek Ol??k --- Please don't change the bug component. DRI/Radeon is R100. You have R600 and your driver is part of Gallium. The variable was just to help debugging. Please try also this: R600_DEBUG=nocpdma -- 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/20140203/f4d44d1c/attachment.html>
[Bug 69301] no screen on update from 3.12.0
https://bugzilla.kernel.org/show_bug.cgi?id=69301 --- Comment #13 from Alex Deucher --- (In reply to Jakob Kummerow from comment #12) > Bisection result: > > commit 56684ec5b050e6a392cb3e5324eda12a13413a57 > Author: Alex Deucher > Date: Wed Oct 30 10:18:37 2013 -0400 > > drm/radeon: enable DPM by default on BTC asics > > Seems to be stable on them. > > > Which makes sense in so far as I have a Barts card, but obviously this > commit did not introduce the actual problem. I guess I'll have to bisect > again with an explicit radeon.dpm=1 kernel parameter. > > FWIW, on 3.12 and earlier, I used to "echo low > > /sys/class/drm/card0/device/power_profile" by means of an init script, and > never had any issues with that. Jakub, you are seeing bug 68571 since you have a BTC card. Jan is seeing an issue with an SI card. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 73739] RV630 flickering on "Wargame European Escalation"
https://bugs.freedesktop.org/show_bug.cgi?id=73739 --- Comment #5 from John --- Created attachment 93283 --> https://bugs.freedesktop.org/attachment.cgi?id=93283&action=edit In game with flickering recorded video http://www.youtube.com/watch?v=CHWLol70sYs -- 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/20140203/1f16b224/attachment.html>
[Bug 69301] no screen on update from 3.12.0
https://bugzilla.kernel.org/show_bug.cgi?id=69301 --- Comment #14 from Alex Deucher --- Created attachment 124331 --> https://bugzilla.kernel.org/attachment.cgi?id=124331&action=edit possible fix for SI Jan, does this patch help? -- You are receiving this mail because: You are watching the assignee of the bug.
Selecting memory manager for embedded DRM device
On Sun, Feb 2, 2014 at 6:50 PM, Dmitry Eremin-Solenikov wrote: > Hello, > > I'm looking onto writing DRM/KMS drivers for few pieces of > embedded equipment. I stumbled upon selecting GEM/TTM/whatever > for them. Could you please guide me? The common choices are either: * TTM + GEM userspace interface (nouveau and radeon) * or just GEM (intel, and most of the ARM devices) TTM seems to be mostly advantageous if you need to manage migration between VRAM / GART / system RAM. But it sounds like you are talking about a UMA system, so maybe TTM doesn't help you as much. BR, -R > From my point of view, there are two major cases: > > 1) Device with embedded/separate VRAM. > > 2) Device using system memory w/o any restrictions. > > Those are embedded devices hanging on memory bus, > so no such things as AGP, aperture exist. > > I'm looking for advice on selecting proper MM. > > -- > With best wishes > Dmitry > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74335] [UVD] vdpau hangs the system on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=74335 --- Comment #1 from Christian K?nig --- Video works perfectly on my 7870. Are you sure that's not an unrelated bug? Please try running it without any desktop effects. Best way to narrow it down would be a pure X server without anything else started. -- 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/20140203/c4a844c2/attachment-0001.html>
Selecting memory manager for embedded DRM device
On Mon, Feb 3, 2014 at 11:16 AM, Dmitry Eremin-Solenikov wrote: > Hello, > > On Mon, Feb 3, 2014 at 7:49 PM, Rob Clark wrote: >> On Sun, Feb 2, 2014 at 6:50 PM, Dmitry Eremin-Solenikov >> wrote: >>> Hello, >>> >>> I'm looking onto writing DRM/KMS drivers for few pieces of >>> embedded equipment. I stumbled upon selecting GEM/TTM/whatever >>> for them. Could you please guide me? >> >> The common choices are either: >> >> * TTM + GEM userspace interface (nouveau and radeon) >> * or just GEM (intel, and most of the ARM devices) >> >> TTM seems to be mostly advantageous if you need to manage migration >> between VRAM / GART / system RAM. But it sounds like you are talking >> about a UMA system, so maybe TTM doesn't help you as much. > > Thank you for the answer. Indeed I had the feeling that just GEM would be > work for UMA devices. I'm interested about the driver for my second hardware. > It's a separate graphics chip with separate VRAM, no access to system > memory and nearly no advanced capabilities (few 2D accelerations, > but nothing fancy). Would that require TTM, some special setup of GEM > or something completely different? > for the VRAM device, it seems like TTM could be useful. I guess start with that device and checkout TTM. By the time you've done that, you'll know TTM well enough to decide if you also want to use it for the UMA device. BR, -R > > -- > With best wishes > Dmitry
[Bug 74335] [UVD] vdpau hangs the system on radeonsi (HD 7950)
https://bugs.freedesktop.org/show_bug.cgi?id=74335 --- Comment #2 from darkbasic --- Created attachment 93297 --> https://bugs.freedesktop.org/attachment.cgi?id=93297&action=edit startx This is my pure X server so I fear it's not going to happen. Anyway I just got two more crashes with KDE (one with desktop effects ON and one with desktop effects OFF) and then it worked for a couple of times. Anyway it's way too slow (I get "Your system is too SLOW to play this!" in mplayer). -- 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/20140203/644b7877/attachment.html>
[RFC 00/16] drm/nouveau: initial support for GK20A (Tegra K1)
On Sat, Feb 1, 2014 at 4:16 AM, Alexandre Courbot wrote: > Finally, support for probing GK20A is added in the last 2 patches. It should > be > noted that contrary to what Nouveau currently expects, GK20A does not embed > any > display hardware (that part being handled by tegradrm). So this driver should > really be only used through DRM render-nodes and collaborate with the display > driver using PRIME. I have not yet figured out how to turn GK20A's > instantiation > of Nouveau into a render-node only driver without breaking support for > existing > desktop GPUs, and consequently the driver spawns a /dev/dri/cardX node which > we > should try to get rid of. tbh I wouldn't care about the lagecy dev nodes - we have hw platforms on intel with similar setup (i.e. just rendering and no outputs) and we don't bother to hide the legacy node. kms ioctl will still be there, but as long as no encoder/connector/crtc/... gets set up by the driver the only thing userspace can do is create framebuffers. Which is rather harmless ;-) And having legacy dev nodes around helps on older userspace (e.g. X/Prime with dri2 which uses flink). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 74469] New: [opencl] OpenCL fails on Kabini Radeon 8330
https://bugs.freedesktop.org/show_bug.cgi?id=74469 Priority: medium Bug ID: 74469 Assignee: dri-devel at lists.freedesktop.org Summary: [opencl] OpenCL fails on Kabini Radeon 8330 Severity: normal Classification: Unclassified OS: All Reporter: mike at fireburn.co.uk Hardware: Other Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa The opencl-example if_* tests all fail I'm not sure if this is related to bug 65085 I tried running bfgminer but the program segfaults once I did opencl:auto I'll happily try piglet if you think it might be useful -- 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/20140203/3ef7fb27/attachment-0001.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #12 from Marti Raudsepp --- Alex, I spent many hours setting up the bisect environment and doing all the builds. It would be fair if you would spend some of your time to at least give me a reply. Thomas, you have a different card and the symptoms are different. Unless you have good reasons to believe otherwise, I think you're experiencing a different issue. -- 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/20140203/fcec4e47/attachment.html>
[Bug 73110] [BISECTED] commit "r600g: use shader-based MSAA resolving when hw-based one cannot be used" crashes some games when R600_LLVM=1 with LLVM < 3.4
https://bugs.freedesktop.org/show_bug.cgi?id=73110 --- Comment #14 from Alexandre Demers --- (In reply to comment #13) > Alternatively, LLVM 3.4 could be required as the minimum version on r600 and > radeonsi, there are other bugs I remember only happens with 3.3. Since LLVM 3.4 is officially out, I would go with this solution. Otherwise, could we wrap 696229523d919de15ebc25d0f475bf56d7dad4a9 code in a if (LLVM >= 3.4) kind of condition? -- 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/20140203/d127f89b/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #13 from Alex Deucher --- The audio hardware doesn't interact with the memory controller (or 3D engine for that matter) so I don't really see how it could cause a GPU page fault. Also, the fact that disabling audio on a newer kernel doesn't break things leads me to believe it's not related to the audio at all. Maybe some stale mesa stuff floating around on your system? Nothing else really comes to mind. -- 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/20140203/4890751a/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #14 from Marti Raudsepp --- (In reply to comment #13) > Also, the fact that disabling audio on a newer kernel doesn't break things If I disable audio, shouldn't the Radeon HDMI ALSA device disappear? That didn't happen for me when I set radeon.audio=0. Am I doing something wrong? > The audio hardware doesn't interact with the memory controller (or 3D engine > for that matter) so I don't really see how it could cause a GPU page fault. Could it be a timing issue? Audio init delays startup enough that it doesn't hit some races anymore? A broken system sometimes managed to recover after coming back from suspend, though rarely. -- 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/20140203/348a1c7b/attachment.html>
[Bug 73110] [BISECTED] commit "r600g: use shader-based MSAA resolving when hw-based one cannot be used" crashes some games when R600_LLVM=1 with LLVM < 3.4
https://bugs.freedesktop.org/show_bug.cgi?id=73110 --- Comment #15 from Marek Ol??k --- No, the code would be too complex. -- 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/20140203/e2674b07/attachment.html>
[Bug 73848] [Radeon] Blank screen after boot with kernel 3.12.x, xorg 1.15
https://bugs.freedesktop.org/show_bug.cgi?id=73848 --- Comment #15 from Alex Deucher --- (In reply to comment #14) > (In reply to comment #13) > > Also, the fact that disabling audio on a newer kernel doesn't break things > > If I disable audio, shouldn't the Radeon HDMI ALSA device disappear? That > didn't happen for me when I set radeon.audio=0. Am I doing something wrong? > No. disabling audio in the radeon driver just disables the audio stream in the hdmi stream. The audio device itself can't be disabled. > > The audio hardware doesn't interact with the memory controller (or 3D engine > > for that matter) so I don't really see how it could cause a GPU page fault. > > Could it be a timing issue? Audio init delays startup enough that it doesn't > hit some races anymore? If you disable acceleration (add Option "NoAccel" "true" to the device section of your xorg config) do you still get the problems? It's most likely some issue related to the 3D engine set up in mesa. -- 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/20140203/484defb1/attachment.html>
[Bug 73911] Color Banding on R600 (7660G + 7670M)
https://bugs.freedesktop.org/show_bug.cgi?id=73911 Alex Deucher changed: What|Removed |Added Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org QA Contact|xorg-team at lists.x.org | Product|xorg|DRI Version|git |unspecified Component|Driver/Radeon |DRM/Radeon --- Comment #9 from Alex Deucher --- Are you only having problems with the built in display on the laptop? -- 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/20140203/34d47e2b/attachment.html>
[Bug 73911] Color Banding on R600 (7660G + 7670M)
https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #10 from Alex Deucher --- Created attachment 93321 --> https://bugs.freedesktop.org/attachment.cgi?id=93321&action=edit testing patch Does this kernel patch help? -- 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/20140203/dc2e2e6c/attachment.html>
[Bug 74476] New: libGL complains about missing symbol __driDriverGetExtensions_radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=74476 Priority: medium Bug ID: 74476 Assignee: dri-devel at lists.freedesktop.org Summary: libGL complains about missing symbol __driDriverGetExtensions_radeonsi Severity: normal Classification: Unclassified OS: Linux (All) Reporter: farmboy0+freedesktop at googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/radeonsi Product: Mesa The complete message is: libGL: OpenDriver: trying /usr/lib64/dri/tls/radeonsi_dri.so libGL: OpenDriver: trying /usr/lib64/dri/radeonsi_dri.so libGL: driver does not expose __driDriverGetExtensions_radeonsi(): /usr/lib64/dri/radeonsi_dri.so: undefined symbol: __driDriverGetExtensions_radeonsi Mesa is build from Git. libdrm is 2.4.52 The message appears for any application using OpenGL like glxinfo glxgears Unigine Heaven benchmark. I have LIBGL_DEBUG=verbose in my environment. -- 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/20140203/1dbc9757/attachment.html>
[Bug 73127] [r600g] Possible memory leak when playing WoW with CAICOS
https://bugs.freedesktop.org/show_bug.cgi?id=73127 --- Comment #8 from Chris Rankin --- Created attachment 93322 --> https://bugs.freedesktop.org/attachment.cgi?id=93322&action=edit Memory being leaked with RV790 WoW is definitely leaking memory with current Mesa-git. I have attached the dmesg log that results after playing WoW for < 1 hour. Mesa head is: commit 9bace99d77642f8fbd46b1f0be025ad758f83f5e Author: Zack Rusin Date: Tue Jan 28 16:34:18 2014 -0500 gallivm: fix opcode and function nesting but the problem began before this. -- 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/20140203/80a671de/attachment-0001.html>
[Bug 74428] System crashes from Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 --- Comment #4 from vimregisters at gmail.com --- Yes. Nothing goes wrong with hyperz disabled. -- 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/20140203/751d5009/attachment.html>
[Bug 73911] Color Banding on R600 (7660G + 7670M)
https://bugs.freedesktop.org/show_bug.cgi?id=73911 --- Comment #11 from Inti Alonso --- Right now Im at the office, I will test with a external screen when I get home. Im not experienced with patching the Kernel, I gonna do some reading so I can try the patch. -- 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/20140203/7677f2ac/attachment.html>
[Bug 74428] hyperz causes gpu hang in Counter-strike: Source
https://bugs.freedesktop.org/show_bug.cgi?id=74428 Alex Deucher changed: What|Removed |Added Summary|System crashes from |hyperz causes gpu hang in |Counter-strike: Source |Counter-strike: Source -- 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/20140203/6f929b58/attachment.html>
[PATCH 1/1] drm/exynos: Fix build error in exynos_hdmi.c
On Mon, Feb 3, 2014 at 7:14 AM, Inki Dae wrote:
> 2014-01-31 Josh Boyer :
>> On Fri, Jan 31, 2014 at 1:09 AM, Sachin Kamat
>> wrote:
>>> 'hdmi_infoframe' is already defined in include/linux/hdmi.h.
>>> Rename the local variable to avoid the following build error:
>>> drivers/gpu/drm/exynos/exynos_hdmi.c:382:8: error: 'hdmi_infoframe' defined
>>> as wrong kind of tag
>>> struct hdmi_infoframe {
>>>
>>> Signed-off-by: Sachin Kamat
>>> Reported-by: Josh Boyer
>>
>> This does fix the build error I saw. I don't have hardware to test
>> the results with, but it now compiles correctly. Thanks for the quick
>> turn around!
>>
>
> Hi,
>
> Thanks for report and patch. But Sean posted already below patch,
> [PATCH v4 01/34] drm/exynos: Rename hdmi_infoframe to avoid collision
>
Yeah, sorry, I just tucked it in with the rest of my stuff :)
Sean
> Thanks,
> Inki Dae
>
>
>> josh
>>
>>> ---
>>> drivers/gpu/drm/exynos/exynos_hdmi.c |6 +++---
>>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> index a0e10ae..0d4407c 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_hdmi.c
>>> @@ -379,7 +379,7 @@ static const struct hdmiphy_config
>>> hdmiphy_v14_configs[] = {
>>> },
>>> };
>>>
>>> -struct hdmi_infoframe {
>>> +struct hdmi_frameinfo {
>>> enum HDMI_PACKET_TYPE type;
>>> u8 ver;
>>> u8 len;
>>> @@ -682,7 +682,7 @@ static u8 hdmi_chksum(struct hdmi_context *hdata,
>>> }
>>>
>>> static void hdmi_reg_infoframe(struct hdmi_context *hdata,
>>> - struct hdmi_infoframe *infoframe)
>>> + struct hdmi_frameinfo *infoframe)
>>> {
>>> u32 hdr_sum;
>>> u8 chksum;
>>> @@ -985,7 +985,7 @@ static void hdmi_conf_reset(struct hdmi_context *hdata)
>>>
>>> static void hdmi_conf_init(struct hdmi_context *hdata)
>>> {
>>> - struct hdmi_infoframe infoframe;
>>> + struct hdmi_frameinfo infoframe;
>>>
>>> /* disable HPD interrupts from HDMI IP block, use GPIO instead */
>>> hdmi_reg_writemask(hdata, HDMI_INTC_CON, 0, HDMI_INTC_EN_GLOBAL |
>>> --
>>> 1.7.9.5
>>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 68451] Texture flicker in native Dota2 in mesa 9.2.0rc1
https://bugs.freedesktop.org/show_bug.cgi?id=68451 --- Comment #53 from Marek Ol??k --- Created attachment 93328 --> https://bugs.freedesktop.org/attachment.cgi?id=93328&action=edit fix 2 (In reply to comment #52) > (In reply to comment #51) > > R600_DEBUG=noinvalrange > > Yes, that one fixes the problem. Please try the attached patch with and without: R600_DEBUG=nodma,nocpdma -- 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/20140203/974be937/attachment.html>
[3.14-rc1] cirrus driver problem (qemu)
When I boot 3.14-rc1 in qemu, I get the trace below. The console stops updating and I don't get a login prompt. I can login, but I can't see what I'm doing. I can login normally via SSH. If I revert the last commit in drivers/gpu/drm/cirrus: f4b4718b61d1d5a7442a4fd6863ea80c3a10e508 drm: ast,cirrus,mgag200: use drm_can_sleep the problem is solved. [1.749341] [ cut here ] [1.749347] WARNING: CPU: 0 PID: 0 at kernel/locking/mutex.c:856 mutex_trylock+0x1e5/0x250() [1.749348] DEBUG_LOCKS_WARN_ON(in_interrupt()) [1.749360] Modules linked in: ppdev cirrus syscopyarea sysfillrect sysimgblt drm_kms_helper evdev psmouse microcode serio_raw pcspkr ttm e1000 parport_pc parport processor button intel_agp drm intel_gtt i2c_piix4 ipv6 ext4 crc16 mbcache jbd2 sd_mod sr_mod cdrom ata_generic pata_acpi ata_piix 9pnet_virtio 9pnet libata scsi_mod [1.749362] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 3.14.0-rc1-t1 #34 [1.749364] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [1.749366] 0009 88001fc038c8 814e8456 88001fc03910 [1.749367] 88001fc03900 8106a0dd 88001d3ff990 0010 [1.749368] 01e0 88001cc3b000 88001fc03960 [1.749369] Call Trace: [1.749372][] dump_stack+0x4d/0x6f [1.749374] [] warn_slowpath_common+0x7d/0xa0 [1.749375] [] warn_slowpath_fmt+0x4c/0x50 [1.749377] [] mutex_trylock+0x1e5/0x250 [1.749380] [] cirrus_dirty_update+0x7c/0x2f0 [cirrus] [1.749381] [] cirrus_imageblit+0x2f/0x40 [cirrus] [1.749388] [] soft_cursor+0x1b4/0x250 [1.749390] [] bit_cursor+0x613/0x650 [1.749391] [] ? get_color.isra.15+0x31/0x140 [1.749392] [] fbcon_cursor+0x13b/0x1c0 [1.749393] [] ? update_attr.isra.2+0x90/0x90 [1.749398] [] hide_cursor+0x28/0xa0 [1.749400] [] vt_console_print+0x398/0x3d0 [1.749405] [] ? print_prefix+0x6f/0xb0 [1.749407] [] call_console_drivers.constprop.18+0x93/0x110 [1.749409] [] console_unlock+0x3cf/0x410 [1.749410] [] vprintk_emit+0x181/0x4f0 [1.749412] [] printk+0x54/0x56 [1.749414] [] credit_entropy_bits+0x2ea/0x300 [1.749415] [] ? mix_pool_bytes.constprop.30+0x56/0xc0 [1.749416] [] add_timer_randomness+0xee/0x120 [1.749418] [] add_disk_randomness+0x33/0xb0 [1.749424] [] blk_update_bidi_request+0x5c/0x80 [1.749426] [] blk_end_bidi_request+0x1f/0x60 [1.749427] [] blk_end_request+0x10/0x20 [1.749433] [] scsi_io_completion+0xa9/0x640 [scsi_mod] [1.749436] [] scsi_finish_command+0xa2/0xe0 [scsi_mod] [1.749440] [] scsi_softirq_done+0x10e/0x130 [scsi_mod] [1.749441] [] blk_done_softirq+0x93/0xb0 [1.749443] [] __do_softirq+0x105/0x2f0 [1.749444] [] irq_exit+0x92/0xc0 [1.749446] [] do_IRQ+0x58/0xf0 [1.749447] [] common_interrupt+0x6d/0x6d [1.749450][] ? native_safe_halt+0x6/0x10 [1.749453] [] default_idle+0x2d/0x110 [1.749454] [] arch_cpu_idle+0x2e/0x40 [1.749455] [] cpu_startup_entry+0xa5/0x2e0 [1.749464] [] ? early_idt_handlers+0x120/0x120 [1.749466] [] rest_init+0x84/0x90 [1.749467] [] start_kernel+0x443/0x44e [1.749468] [] ? repair_env_string+0x5c/0x5c [1.749469] [] x86_64_start_reservations+0x2a/0x2c [1.749470] [] x86_64_start_kernel+0x169/0x178 [1.749471] ---[ end trace d478ba7c30908d4d ]--- -- Sabrina Dubroca
[PATCH v5 00/23]
On Sun, Feb 02, 2014 at 07:06:06PM +0100, Jean-Francois Moine wrote: > - the .of_match_table is not needed because the i2c client is created by > the i2c subsystem from the 'reg' in the DT, It's generally better to have an explict set of OF IDs even if the default does work - matching purely on the device name does work almost all the time but there are collisions out there with different manufacturers using the same prefix for their chips (the example I always trot out is that both Wolfson and Wondermedia use "wm"). -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 836 bytes Desc: Digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140203/201b93b6/attachment.pgp>
Selecting memory manager for embedded DRM device
Hello, On Mon, Feb 3, 2014 at 7:49 PM, Rob Clark wrote: > On Sun, Feb 2, 2014 at 6:50 PM, Dmitry Eremin-Solenikov > wrote: >> Hello, >> >> I'm looking onto writing DRM/KMS drivers for few pieces of >> embedded equipment. I stumbled upon selecting GEM/TTM/whatever >> for them. Could you please guide me? > > The common choices are either: > > * TTM + GEM userspace interface (nouveau and radeon) > * or just GEM (intel, and most of the ARM devices) > > TTM seems to be mostly advantageous if you need to manage migration > between VRAM / GART / system RAM. But it sounds like you are talking > about a UMA system, so maybe TTM doesn't help you as much. Thank you for the answer. Indeed I had the feeling that just GEM would be work for UMA devices. I'm interested about the driver for my second hardware. It's a separate graphics chip with separate VRAM, no access to system memory and nearly no advanced capabilities (few 2D accelerations, but nothing fancy). Would that require TTM, some special setup of GEM or something completely different? -- With best wishes Dmitry
