[Bug 78641] New: Radeon makes Flash player with VDPAU enabled hang at vlVdpDecoderDestroy → flush → radeon_drm_ws_queue_cs
https://bugs.freedesktop.org/show_bug.cgi?id=78641 Priority: medium Bug ID: 78641 Assignee: dri-devel at lists.freedesktop.org Summary: Radeon makes Flash player with VDPAU enabled hang at vlVdpDecoderDestroy ? flush ? radeon_drm_ws_queue_cs Severity: normal Classification: Unclassified OS: All Reporter: mail at 3v1n0.net Hardware: Other Status: NEW Version: 10.1 Component: Drivers/Gallium/r600 Product: Mesa Created attachment 98951 --> https://bugs.freedesktop.org/attachment.cgi?id=98951&action=edit Radeon deadlock with Flash + VDPAU 1) Enable VDPAU support in flash player [1] 2) Visit web pages such as [2] (in that page the hang happens when the AD has been played and the actual video should start). At this point the flash player hangs (plugin-container process with firefox), and there's no way to resume it other than killing the parent process. It seems like a deadlock, see the attached backtrace; not sure if this has something in common with Bug 70123. This is when using mesa 10.1 (4a86465) in Ubuntu 14.04. [1] echo -e "EnableLinuxHWVideoDecode = 1\nOverrideGPUValidation = 1" >> /etc/adobe/mms.cfg [2] http://video.corriere.it/i-ragazzi-anni-90-come-eravamo/9fd1a13c-d9b5-11e3-8b8a-dcb35a431922 -- 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/20140512/0d5ebb1c/attachment.html>
[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)
https://bugs.freedesktop.org/show_bug.cgi?id=78242 --- Comment #5 from Emil Velikov --- (In reply to comment #4) > > It's a steam bug, not a mesa one > > I disagree: this (na?vely linking LLVM) is a change in mesa that breaks many > binary software packages, not just Steam. While the steam-runtime will > likely get a fix for this at some point, some older games may not be so > lucky. > I would say that both parties are to "blame" on this one. AFAICS the topic of to ship libgcc_s/libstdc++ or not has always been a interesting one. [snip] > What you are doing here is introducing additional problems where none > existed before. > I beg to disagree here. Mesa has linked against libgcc_s and libstdc++ since forever. Whereas the static/shared linking against LLVM has always been a configure time decision. > Please reconsider statically linking libLLVM and required > C++/GCC libs into *_dri.so or finding some other solution to not conflict > with programs loading libGL. (An even stricter RTLD_LOCAL that completely > namespaces libs would be nice to have here ?) > Static linking against gcc/c++ seems like a bit of a pain as libtool, unconditionally appends "-lgcc -lgcc_s -lstdc++" (as defined by postdeps), thus -Wl,--static.. and/or -static-lib{gcc,stdc++} does not really help. If you have any solid suggestion please put them forward. -- 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/20140512/0c32e185/attachment.html>
[Bug 60523] Radeon DPM not working with 2 monitors attached to Radeon HD5770 (Juniper)
https://bugzilla.kernel.org/show_bug.cgi?id=60523 Vasco Gervasi changed: What|Removed |Added CC||yellowhat46 at gmail.com --- Comment #52 from Vasco Gervasi --- Same problem with a HD6870 and two monitor. I am using 3.15-rc5. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH] Documentation/dma-buf-sharing.txt: update API descriptions
From: "gioh.kim" update some descriptions for API arguments and descriptions. Signed-off-by: Gioh Kim --- Documentation/dma-buf-sharing.txt | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/Documentation/dma-buf-sharing.txt b/Documentation/dma-buf-sharing.txt index 505e711..1ea89b8 100644 --- a/Documentation/dma-buf-sharing.txt +++ b/Documentation/dma-buf-sharing.txt @@ -56,7 +56,7 @@ The dma_buf buffer sharing API usage contains the following steps: size_t size, int flags, const char *exp_name) - If this succeeds, dma_buf_export allocates a dma_buf structure, and returns a + If this succeeds, dma_buf_export_named allocates a dma_buf structure, and returns a pointer to the same. It also associates an anonymous file with this buffer, so it can be exported. On failure to allocate the dma_buf object, it returns NULL. @@ -66,7 +66,7 @@ The dma_buf buffer sharing API usage contains the following steps: Exporting modules which do not wish to provide any specific name may use the helper define 'dma_buf_export()', with the same arguments as above, but - without the last argument; a __FILE__ pre-processor directive will be + without the last argument; a KBUILD_MODNAME pre-processor directive will be inserted in place of 'exp_name' instead. 2. Userspace gets a handle to pass around to potential buffer-users @@ -76,7 +76,7 @@ The dma_buf buffer sharing API usage contains the following steps: drivers and/or processes. Interface: - int dma_buf_fd(struct dma_buf *dmabuf) + int dma_buf_fd(struct dma_buf *dmabuf, int flags) This API installs an fd for the anonymous file associated with this buffer; returns either 'fd', or error. @@ -157,7 +157,9 @@ to request use of buffer for allocation. "dma_buf->ops->" indirection from the users of this interface. In struct dma_buf_ops, unmap_dma_buf is defined as - void (*unmap_dma_buf)(struct dma_buf_attachment *, struct sg_table *); + void (*unmap_dma_buf)(struct dma_buf_attachment *, +struct sg_table *, +enum dma_data_direction); unmap_dma_buf signifies the end-of-DMA for the attachment provided. Like map_dma_buf, this API also must be implemented by the exporter. -- 1.7.9.5
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
On 12 May 2014 19:42, Rafa? Mi?ecki wrote: > On 12 May 2014 17:57, Alex Deucher wrote: >> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote: >>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed >>> in a slightly different way. Moving support to separated file will >>> allow use to use rv770d.h header in the future and adjust code as well. >> >> Any reason not to split it at DCE3.2 rather than 3.1? It seems like >> most (all?) of the changes are DCE3.2 specific rather than DCE3.1. >> Otherwise, seems fine to me. > > I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed > in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The > biggest difference is that DCE 3.1 doesn't seem to have > AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0. After looking closer... maybe I have to review it again. It seems programming order of DCE 3.1 is much more like DCE 3.2, but registers of DCE 3.1 are more like DCE 2.0/3.0. Maybe we'll need even one more split. I'll review it and come back.
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
On 12 May 2014 17:57, Alex Deucher wrote: > On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote: >> DCE 3.1 and 3.2 have different HDMI registers and should be programmed >> in a slightly different way. Moving support to separated file will >> allow use to use rv770d.h header in the future and adjust code as well. > > Any reason not to split it at DCE3.2 rather than 3.1? It seems like > most (all?) of the changes are DCE3.2 specific rather than DCE3.1. > Otherwise, seems fine to me. I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The biggest difference is that DCE 3.1 doesn't seem to have AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0. Take a look at defines for DCE 3.2. Even they are placed in rv770d.h, which is the DCE 3.1 chipset.
[RFC] DisplayPort MST v0.3
On 12 May 2014 16:46, Dave Airlie wrote: > Hi, > > A repost of the current state of the displayport MST support for > i915, mainly targetted the Lenovo docks. Also in git at http://cgit.freedesktop.org/~airlied/linux/log/?h=drm-i915-mst-support Dave.
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
>> >> If we decide to go for property documentation inside the source code then I >> believe we'll have to create our own format, as creating a properties table >> from kerneldoc information extracted from comments is probably not possible. > > Can comeone pick up the ball here and figure out what needs to be done? > > The reason why I want a central place for the documentation is to force > people to collaborate outside their own sandbox when adding properties. > Whether that's docbook or some text file I don't care so much at this > point. The fact that it's a central place should mandate that the > patches changing it will go through dri-devel and so everyone should se > them, and when adding new properties it would make the patch author more > likely to look around a bit before adding another slighty incompatible > version of the same property. If someone has a better suggestion how to > encforce this I'm all ears. > > Of course this idea can still fail if our esteemed maintainer merges > stuff without checking for violations of this policy. Dave, any thoughts > on the subject? Yeah I'm happy to block merging stuff, if we can spot new properties when stuff is posted on dri-devel, so much the better, most drivers still send everything via dri-devel anyways, its only really Intel I have to worry about so far, But we should definitely add it to the new driver review checklist as well. I'm also on the side of this patch is ugly and makes my eyes burn, please please get a plan to use something else ASAP, I'm willing to merge this but I'm tempted to give it a lifetime of a kernel or two before I burn it. Dave.
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #36 from Alex Deucher --- (In reply to Dieter N?tzel from comment #35) > (In reply to Alex Deucher from comment #33) > > I wonder if UVD uses the reference clock directly, or if it uses xclk. If > > it uses xclk, they may explain the problems. Can you post your dmesg output > > with this patch applied? > > Here is mine (with latest stuff from Christian): > > [ 11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495 > 0x174B:0x0028). > > [ 11.257005] [drm] ref: 2700, xclk: 2700 On your board (and most boards) they are the same, so your board would not be affected if this proves to be an issue. > > [ 11.263794] radeon :01:00.0: WB disabled <--- Is this intended? On AGP cards, WB is disabled. -- You are receiving this mail because: You are watching the assignee of the bug.
OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
Hi Tomi, Thank a lot for your inputs and patch info. It seems I cannot apply those patches straight away as it is based on 3.6-rc4 and I am using 3.4.25, between these two, it seems significant code changes for DSS related code. I am using 3.4.25 kernel from TI for OMAP5 evm, it has been modified as per our platform requirement which is having OMAP5 ES2.0 revision. I am trying to use the panel driver for DPI interface(i.e. Kernel\drivers\video\omap2\displays\panel-generic-dpi.c). So DSS and panel driver path are as follows Kernel\drivers\video\omap2\dss\dpi.c,dss.c,display.c,dss_features.c etc Kernel\drivers\video\omap2\displays\panel-generic-dpi.c soc specific: Kernel\arch\arm\mach-omap2\omap5_es2\clkt_clksel.c, clkt_dpll.c,clock.c,cm44xx_54xx.c etc omapdrm path: Kernel\drivers\staging\omapdrm In case for working HDMI port, we are using: Kernel\drivers\video\omap2\dss\hdmi.c Kernel\drivers\video\omap2\dss\hdmi_panel.c I think this would require considerable amount of understanding on dss architecture and effort to backport some of the things, write new driver fro TDF19988 and make DPI interface working for our platform for someone like me who has just started working on DSS/Display. Regards, Vikash On Mon, May 12, 2014 at 5:28 PM, Tomi Valkeinen wrote: > On 12/05/14 14:33, Vikas Patil wrote: > > Hi, > > > > Re-posting as previous posting was rejected due to length. > > > > Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI > > conversion. > > I have build the driver for it from > > > https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c > . > > Is this the correct driver for it? > > That driver cannot be used with omapdrm, which uses omapdss. There's no > TDF19988 driver for omapdss (at least in the mainline), so you need to > write one. > > > Also I am trying to use the generic-dpi-panel driver for this with > > OMAP5. It seems I also need to add support for TDF19988 somewhere in > > omapdrm or lcd/panel driver by calling drm_i2c_encoder_init to > > initialize it. Can I use somecode from ticldc driver or driver itself? > > Could you please give some inputs, how should I proceed further to > > adding support for TDF19988 for which the input is coming from DPI > > interface? > > You need to write a driver for it. Something similar to > drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c, except tfp410 > is quite simple one. > > But I think you said you're based on some old customized kernel, so I > don't know which kind of omapdss driver you have there, so the mainline > tfp410 cannot probably be used as an example. Most likely the omapdss > drivers for your kernel are located in drivers/video/omap2/displays/ > directory. > > Tomi > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/c5afa535/attachment.html>
[Intel-gfx] Design review request: DRM color manager
Hi On Mon, May 12, 2014 at 5:28 PM, Daniel Vetter wrote: > Those are all just reasons for atomic modeset and maybe an atomic modeget > ioctl which transfers the entire blob of things. Maybe we should start > with the atomic modeget to get things rolling. Otoh you can always do that > in userspace since we assume there's only one display manager. DRM_MODE_OBJ_GET_PROPERTIES is already available and allows atomic retrieval of 'n' properties (as it calls drm_modeset_lock_all()). I guess that qualifies as what you describe with "atomic modeget"? > And for modeset we can throw efficiency of the marshalling/de-marshalling > over board (within some limits of course) since we do about 60*num_pipes > modeset/pageflip calls per second at most. And the overhead of the > encoding/decoding of the properties will be completely washed out by all > the register i/o we need to do to UC pci bars. Yepp, I fully agree. And if properties turn out to become a bottleneck, we should optimize them. Thanks David
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: > On 05/12/2014 01:58 AM, Daniel Vetter wrote: > > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > > If we decide to go for property documentation inside the source code > then I > believe we'll have to create our own format, as creating a properties > table > from kerneldoc information extracted from comments is probably not > possible. > >>> > >>> Can comeone pick up the ball here and figure out what needs to be done? > >>> > >>> The reason why I want a central place for the documentation is to force > >>> people to collaborate outside their own sandbox when adding properties. > >>> Whether that's docbook or some text file I don't care so much at this > >>> point. The fact that it's a central place should mandate that the > >>> patches changing it will go through dri-devel and so everyone should se > >>> them, and when adding new properties it would make the patch author more > >>> likely to look around a bit before adding another slighty incompatible > >>> version of the same property. If someone has a better suggestion how to > >>> encforce this I'm all ears. > >>> > >>> Of course this idea can still fail if our esteemed maintainer merges > >>> stuff without checking for violations of this policy. Dave, any thoughts > >>> on the subject? > >> > >> Yeah I'm happy to block merging stuff, if we can spot new properties > >> when stuff is posted on dri-devel, so much the better, > >> > >> most drivers still send everything via dri-devel anyways, its only > >> really Intel I have to worry about so far, > > > > I'll enforce that all prop stuff gets cc: dri-devel and that it has > > updates for the prop docs. > > > >> But we should definitely add it to the new driver review checklist as well. > >> > >> I'm also on the side of this patch is ugly and makes my eyes burn, > >> please please get a plan to use something else ASAP, I'm willing to > >> merge this but I'm tempted to give it a lifetime of a kernel or two > >> before I burn it. > > > > Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe > > find someone to do it for me internally ;-) > > -Daniel > > > > I certainly have no objections to making kerneldoc suck less. > There was already an attempt to use asciidoc (like git uses) for kernel-doc > (a few years ago, by Sam Ravnborg). I support(ed) that effort. Hm, do you have pointers to those? My google-fu seems lacking ... Ok, let's move this to the top and start discussions. The past few months I've written piles of kerneldoc comments for the DRM DocBook (all pulled in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: sections are really useful to pull all the actual documentation out of the docbook xml into kerneldoc. But I've also done piles of docs for intel-gpu-tools, which is using gtkdoc. And there are some clear deficiencies: - No markdown for inline coments. Lack of lists and tables is hurting especially badly. If we add this (and I don't care one iota whether it's markdown or asciidoc or something else as long as it's readable plain text in comments) we should be able to move all the existing docbook xml paragraphs/lists/tables into kerneldoc comments. - Automatic cross-referencing of functions. If you place e.g. function() or #struct anywhere in a documentation comment gtk-doc automatically inserts a hyperlink to the relevant documentation page across the entire project. Really powerful and makes overview sections much more useful entry points for beginners since they can easily jump back&forth betweeen the high-level overview and low-level per-function documentation. - In a really perfect world it would help if kerneldoc could collect structure member kerneldoc from per-member comments. Especially for large structures with lots of comments this would bring the kerneldoc and struct member much closer together. So that's my wishlist. > OTOH, I would only want to add another way to do kernel-doc if it can be a > full replacement for all of our docbook usage, i.e., it should provide a > way that we can eliminate docbook and stop using it completely. Hm, I don't mind docbook at all, as long as all the real content is embedded into source files as kerneldoc and the docbook template just pulls in all the right bits and pieces. Even gtkdoc allos you to do that and pull in the different libararies (== header files with declarations for C) in the order you want. So imo the docbook toolchain is good enough for my needs. Or what do you mean by getting rid of all docbook usage? -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 78242] Steam cannot load mesa drivers (libGL error: driver pointer missing)
cc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6 (0x7f37f0e61000) /usr/lib/mesa/r600g_dri.so: libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1 (0x7f37f059f000) /usr/lib/mesa/radeon_dri.so:libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6 (0x7f5528868000) /usr/lib/mesa/radeon_dri.so:libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1 (0x7f5527fa6000) /usr/lib/mesa/radeonsi_dri.so: libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6 (0x7f4021a96000) /usr/lib/mesa/radeonsi_dri.so: libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1 (0x7f40211d4000) /usr/lib/mesa/swrast_dri.so:libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6 (0x7f3bf7cc8000) /usr/lib/mesa/swrast_dri.so:libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1 (0x7f3bf7406000) /usr/lib/mesa/swrastg_dri.so: libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libstdc++.so.6 (0x7fd0b4263000) /usr/lib/mesa/swrastg_dri.so: libgcc_s.so.1 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0-pre/libgcc_s.so.1 (0x7fd0b39a1000) This search includes fglrx's libGL by the way: The proprietary AMD (and I'm sure NVIDIA) drivers have long used C++ internally, but have taken care not to pollute the global namespace with the C++ standard library or GCC helper library. I think this shows even more precedent that these libraries should not be considered safe to use in base system libraries without additional precautions. What you are doing here is introducing additional problems where none existed before. Please reconsider statically linking libLLVM and required C++/GCC libs into *_dri.so or finding some other solution to not conflict with programs loading libGL. (An even stricter RTLD_LOCAL that completely namespaces libs would be nice to have here ?) For reference, here are a few more bugs caused by this: #30192, #30901, #38182, #38783, #43964, #66955 -- 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/20140512/4aa8f562/attachment.html>
[Intel-gfx] Design review request: DRM color manager
Thanks for your time and the comments David. please find mine inline. Regards Shashank On 5/12/2014 5:20 PM, David Herrmann wrote: > Hi > > On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank > wrote: >> Benefits of using color manager: >> >> 1. Unique framework for all the color correction properties, across all >> DRM drivers, across various platforms. >> 2. Only one set/get call for all kind of properties using the common >> protocol. One get call can tell what are the color correction capabilities >> of the SOC, registered by driver. > > What's the advantage of that? We should add a > DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things, > instead of adding huge payloads. > The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass limited value. But there are few properties like gamma correction which need a full LUT(256 vals) to be passed according to the correction values. The plan here is pretty much aligned to your suggestion, ie to use DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from the blob based on a protocol. Why do you think its a huge payload ? > I really think we should define one property for each color-correction > interface. I cannot see any downside of that except that we should add > DRM_MODE_OBJ_SET_PROPERTIES. As I was discussing, if there are 10 color correction properties a SOC supports, we have to create 10 properties which doesn't look good, when all the properties will do the same (set/reset few registers as correction). We already have a case where we expose 6 different type of corrections. One more benefit is, this part is centrally controlled, so you can always know what's the state of color correction in single shot at any time. This will also provide us to do a lot of common things to do at the same place, like floating point arithmetic to register value conversion in a supporting userspace library, which might be required for many cases. INHO, its always good to have a controlled interface/ framework to have similar things aligned to. But afaik that's already the plan for > atomic-modesetting, right? > > Thanks > David > AFAIK color management is not a part of atomic modeset, but once we create such an interface, it would be really easy to club that in the atomic modeset.
[Intel-gfx] Design review request: DRM color manager
On Mon, May 12, 2014 at 05:35:13PM +0530, Sharma, Shashank wrote: > Thanks for your time and the comments David. > please find mine inline. > > Regards > Shashank > On 5/12/2014 5:20 PM, David Herrmann wrote: > >Hi > > > >On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank > > wrote: > >>Benefits of using color manager: > >> > >>1. Unique framework for all the color correction properties, across all > >>DRM drivers, across various platforms. > >>2. Only one set/get call for all kind of properties using the common > >>protocol. One get call can tell what are the color correction capabilities > >>of the SOC, registered by driver. > > > >What's the advantage of that? We should add a > >DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things, > >instead of adding huge payloads. > > > The problem here is a DRM_OBJECT_MODE_SET_PROPERTIES call can pass limited > value. But there are few properties like gamma correction which need a full > LUT(256 vals) to be passed according to the correction values. The plan here > is pretty much aligned to your suggestion, ie to use > DRM_OBJECT_MODE_SET_BLOB kind of property, and extract the data from the > blob based on a protocol. > Why do you think its a huge payload ? Gamma correction lut is already supported. For the other stuff we can use SET_BLOB (or fix it if it doesn't work). > >I really think we should define one property for each color-correction > >interface. I cannot see any downside of that except that we should add > >DRM_MODE_OBJ_SET_PROPERTIES. > > As I was discussing, if there are 10 color correction properties a SOC > supports, we have to create 10 properties which doesn't look good, when all > the properties will do the same (set/reset few registers as correction). We > already have a case where we expose 6 different type of corrections. > > One more benefit is, this part is centrally controlled, so you can always > know what's the state of color correction in single shot at any time. This > will also provide us to do a lot of common things to do at the same place, > like floating point arithmetic to register value conversion in a supporting > userspace library, which might be required for many cases. > > INHO, its always good to have a controlled interface/ framework to have > similar things aligned to. Those are all just reasons for atomic modeset and maybe an atomic modeget ioctl which transfers the entire blob of things. Maybe we should start with the atomic modeget to get things rolling. Otoh you can always do that in userspace since we assume there's only one display manager. And we absolutely want color correction to be part of the atomic modeset stuff (since some hw has e.g. per-plane gamma correction). So adding a new way to set them despite that the current atomic modeset proposal is fully centered on properties and that we've added all these properties for just this reasons is important. I still don't see what you can do with the color manager that's impossible to do with properties. And having a large pile of properties imo doesn't count as a good reason, since with the color manager you still have all these settings. But maybe just encoded differently, e.g. in a bitfield or something. Changing the way you set stuff doesn't fundamentally change things at all. And for modeset we can throw efficiency of the marshalling/de-marshalling over board (within some limits of course) since we do about 60*num_pipes modeset/pageflip calls per second at most. And the overhead of the encoding/decoding of the properties will be completely washed out by all the register i/o we need to do to UC pci bars. > But afaik that's already the plan for > >atomic-modesetting, right? > > > >Thanks > >David > > > AFAIK color management is not a part of atomic modeset, but once we create > such an interface, it would be really easy to club that in the atomic > modeset. See above, this is a reason to _not_ add a separate color manager. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #35 from Dieter N?tzel --- (In reply to Alex Deucher from comment #33) > I wonder if UVD uses the reference clock directly, or if it uses xclk. If > it uses xclk, they may explain the problems. Can you post your dmesg output > with this patch applied? Here is mine (with latest stuff from Christian): [ 11.159443] [drm] initializing kernel modesetting (RV730 0x1002:0x9495 0x174B:0x0028). [ 11.257005] [drm] ref: 2700, xclk: 2700 [ 11.263794] radeon :01:00.0: WB disabled <--- Is this intended? 01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RV730 [Radeon HD 4600 AGP Series] (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited / Sapphire Technology Radeon HD 4650 AGP DDR2 Flags: bus master, 66MHz, medium devsel, latency 32, IRQ 16 Memory at c000 (32-bit, prefetchable) [size=256M] I/O ports at a800 [size=256] Memory at dfdf (32-bit, non-prefetchable) [size=64K] Expansion ROM at dfdc [disabled] [size=128K] Capabilities: [50] Power Management version 3 Capabilities: [58] AGP version 3.0 Kernel driver in use: radeon Kernel modules: radeon -- You are receiving this mail because: You are watching the assignee of the bug.
OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
Hi, Re-posting as previous posting was rejected due to length. Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI conversion. I have build the driver for it from https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c. Is this the correct driver for it? Also I am trying to use the generic-dpi-panel driver for this with OMAP5. It seems I also need to add support for TDF19988 somewhere in omapdrm or lcd/panel driver by calling drm_i2c_encoder_init to initialize it. Can I use somecode from ticldc driver or driver itself? Could you please give some inputs, how should I proceed further to adding support for TDF19988 for which the input is coming from DPI interface? Thanks & Regards, Vikash On Mon, May 12, 2014 at 2:11 PM, Vikas Patil wrote: > Hi Tomi, > > How could I confirm for OMAP5 DPI support apart form enabling > CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned > config builds components from Kernel\drivers\video\omap2\dss and > kernel\drivers\video\omap2\displays only. Is there any support needs to be > available under kernel\arch\arm\mach-omap2? > > Regards, > Vikash > > > > On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen ti.com>wrote: > >> On 08/05/14 13:07, Vikas Patil wrote: >> > Hi, >> > >> > I am working on to enable the second display output for customized OMAP5 >> > based platform and linux 3.4.25. First display which is HDMI/tv is >> > working fine. Second display out is coming via DPI interface. To enable >> > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and >> > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and >> > omap_dss_board_info and removed the HDMI device and disabled >> > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly, >> > however when I try to run kmscube app and it seems to be running, >> > noticing following error and till now nothing on display. >> >> Does the kernel have support for OMAP5 DPI? I remember there were some >> bits that had to be added to make it work. >> >> Tomi >> >> >> > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/941666e7/attachment-0001.html>
[PATCH v3] drm/i915: restore backlight precision when converting from opregion
On 05/04/2014 03:22 PM, Chris Wilson wrote: > 32b * 32b = 32b > > n = (u64)level * freq; to avoid overflow as you claim. Updated patch to fix this problem is here, thanks! >From a0f41a92d949c814c203672ff7efe219a90ca6df Mon Sep 17 00:00:00 2001 From: Aaron Lu Date: Mon, 28 Apr 2014 11:02:52 +0800 Subject: [PATCH] drm/i915: restore backlight precision when converting from ACPI When we set backlight on behalf of ACPI opregion, we will convert the backlight value in the 0-255 range defined in opregion to the actual hardware level. Commit 22505b82a2 (drm/i915: avoid brightness overflow when doing scale) is meant to fix the overflow problem when doing the conversion, but it also caused a problem that the converted hardware level doesn't quite represent the intended value: say user wants maximum backlight level(255 in opregion's range), then we will calculate the actual hardware level to be: level = freq / max * level, where freq is the hardware's max backlight level(937 on an user's box), and max and level are all 255. The converted value should be 937 but the above calculation will yield 765. To fix this issue, just use 64 bits to do the calculation to keep the precision and avoid overflow at the same time. Buglink: https://bugzilla.kernel.org/show_bug.cgi?id=72491 Reported-by: Nico Schottelius Signed-off-by: Aaron Lu --- drivers/gpu/drm/i915/intel_panel.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_panel.c b/drivers/gpu/drm/i915/intel_panel.c index 0eead16aeda7..cb8cfb7e0974 100644 --- a/drivers/gpu/drm/i915/intel_panel.c +++ b/drivers/gpu/drm/i915/intel_panel.c @@ -492,6 +492,7 @@ void intel_panel_set_backlight(struct intel_connector *connector, u32 level, enum pipe pipe = intel_get_pipe_from_connector(connector); u32 freq; unsigned long flags; + u64 n; if (!panel->backlight.present || pipe == INVALID_PIPE) return; @@ -502,10 +503,9 @@ void intel_panel_set_backlight(struct intel_connector *connector, u32 level, /* scale to hardware max, but be careful to not overflow */ freq = panel->backlight.max; - if (freq < max) - level = level * freq / max; - else - level = freq / max * level; + n = (u64)level * freq; + do_div(n, max); + level = n; panel->backlight.level = level; if (panel->backlight.device) -- 1.9.0
[PATCH 10/10] i915: mst topology dumper in debugfs
From: Dave Airlie use the mst helper code to dump the topology in debugfs. Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_debugfs.c | 26 ++ 1 file changed, 26 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 88e944f..b8a9a51 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2378,6 +2378,31 @@ struct pipe_crc_info { enum pipe pipe; }; +static int i915_dp_mst_info(struct seq_file *m, void *unused) +{ + struct drm_info_node *node = (struct drm_info_node *) m->private; + struct drm_device *dev = node->minor->dev; + struct drm_encoder *encoder; + struct intel_encoder *intel_encoder; + struct intel_digital_port *intel_dig_port; + drm_modeset_lock_all(dev); + list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) { + intel_encoder = to_intel_encoder(encoder); + if (intel_encoder->type != INTEL_OUTPUT_DISPLAYPORT) + continue; + intel_dig_port = enc_to_dig_port(encoder); + if (!intel_dig_port->dp.can_mst) + continue; + + if (!intel_dig_port->dp.is_mst) + continue; + + drm_dp_mst_dump_topology(m, &intel_dig_port->dp.mst_mgr); + } + drm_modeset_unlock_all(dev); + return 0; +} + static int i915_pipe_crc_open(struct inode *inode, struct file *filep) { struct pipe_crc_info *info = inode->i_private; @@ -3813,6 +3838,7 @@ static const struct drm_info_list i915_debugfs_list[] = { {"i915_pc8_status", i915_pc8_status, 0}, {"i915_power_domain_info", i915_power_domain_info, 0}, {"i915_display_info", i915_display_info, 0}, + {"i915_dp_mst_info", i915_dp_mst_info, 0}, }; #define I915_DEBUGFS_ENTRIES ARRAY_SIZE(i915_debugfs_list) -- 1.9.0
[PATCH 09/10] i915: add DP 1.2 MST support (v0.3)
From: Dave Airlie This adds DP 1.2 MST support on Haswell systems. Notes: a) this reworks irq handling for DP MST ports, so that we can avoid the mode config locking in the current hpd handlers, as we need to process up/down msgs at a better time. b) it introduces a new MST output type. c) it really annoys the state checker, as the connector that is connected at the start, goes into disconnected, and its encoder it active, and things blow up, need to look into how to solve that. d) the intel userspace driver needs changes to use this, -modesetting should work okay. e) it might contain a race condition big enough to eat you. f) its hardcoded to 4 lanes 5.4Ghz. - TODO. Changes since v0.1: use PORT_PCH_HOTPLUG to detect short vs long pulses add a workqueue to deal with digital events as they can get blocked on the main workqueue beyong mode_config mutex fix a bunch of modeset checker warnings acks irqs in the driver cleanup the MST encoders Changes since v0.3 check irq status again in work handler move around bring up and tear down to fix DPMS on/off use path properties. TODO: further state checker fixes Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_dma.c | 10 + drivers/gpu/drm/i915/i915_drv.h | 14 + drivers/gpu/drm/i915/i915_irq.c | 106 ++- drivers/gpu/drm/i915/intel_ddi.c | 111 +-- drivers/gpu/drm/i915/intel_display.c | 59 +++- drivers/gpu/drm/i915/intel_dp.c | 213 +- drivers/gpu/drm/i915/intel_dp_mst.c | 530 ++ drivers/gpu/drm/i915/intel_drv.h | 42 ++- drivers/gpu/drm/i915/intel_opregion.c | 1 + 10 files changed, 1041 insertions(+), 46 deletions(-) create mode 100644 drivers/gpu/drm/i915/intel_dp_mst.c diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile index b1445b7..6cf2b95 100644 --- a/drivers/gpu/drm/i915/Makefile +++ b/drivers/gpu/drm/i915/Makefile @@ -52,6 +52,7 @@ i915-y += dvo_ch7017.o \ intel_crt.o \ intel_ddi.o \ intel_dp.o \ + intel_dp_mst.o \ intel_dsi_cmd.o \ intel_dsi.o \ intel_dsi_pll.o \ diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c index 58f2c46..3040869 100644 --- a/drivers/gpu/drm/i915/i915_dma.c +++ b/drivers/gpu/drm/i915/i915_dma.c @@ -1677,6 +1677,13 @@ int i915_driver_load(struct drm_device *dev, unsigned long flags) goto out_mtrrfree; } + dev_priv->dp_wq = alloc_ordered_workqueue("i915-dp", 0); + if (dev_priv->dp_wq == NULL) { + DRM_ERROR("Failed to create our dp workqueue.\n"); + ret = -ENOMEM; + goto out_freewq; + } + intel_irq_init(dev); intel_uncore_sanitize(dev); @@ -1752,6 +1759,8 @@ out_gem_unload: intel_teardown_gmbus(dev); intel_teardown_mchbar(dev); pm_qos_remove_request(&dev_priv->pm_qos); + destroy_workqueue(dev_priv->dp_wq); +out_freewq: destroy_workqueue(dev_priv->wq); out_mtrrfree: arch_phys_wc_del(dev_priv->gtt.mtrr); @@ -1856,6 +1865,7 @@ int i915_driver_unload(struct drm_device *dev) intel_teardown_gmbus(dev); intel_teardown_mchbar(dev); + destroy_workqueue(dev_priv->dp_wq); destroy_workqueue(dev_priv->wq); pm_qos_remove_request(&dev_priv->pm_qos); diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 7d6acb4..b3b5864c 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -1468,6 +1468,18 @@ struct drm_i915_private { struct i915_runtime_pm pm; + struct intel_digital_port *hpd_irq_port[I915_MAX_PORTS]; + u32 hpd_port; + struct work_struct dig_port_work; + /* +* if we get a HPD irq from DP and a HPD irq from non-DP +* the non-DP HPD could block the workqueue on a mode config +* mutex getting, that userspace may have taken. However +* userspace is waiting on the DP workqueue to run which is +* blocked behind the non-DP one. +*/ + struct workqueue_struct *dp_wq; + /* Old dri1 support infrastructure, beware the dragons ya fools entering * here! */ struct i915_dri1_state dri1; @@ -1999,6 +2011,8 @@ i915_disable_pipestat(struct drm_i915_private *dev_priv, enum pipe pipe, void valleyview_enable_display_irqs(struct drm_i915_private *dev_priv); void valleyview_disable_display_irqs(struct drm_i915_private *dev_priv); +bool intel_hpd_irq_event(struct drm_device *dev, +struct drm_connector *connector); /* i915_gem.c */ int i915_gem_init_ioctl(struct drm_device *dev, void *data, diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5852dee..0b16d41 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -963,8 +963,8 @@ static int i9
[PATCH 08/10] drm/i915: check connector->encoder before using it.
From: Dave Airlie DP MST will need connectors that aren't connected to specific encoders, add some checks in advance to avoid oopses. Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_debugfs.c | 16 +--- drivers/gpu/drm/i915/i915_irq.c | 4 drivers/gpu/drm/i915/intel_display.c | 25 ++--- 3 files changed, 27 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index 1e83ae4..88e944f 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -2279,13 +2279,15 @@ static void intel_connector_info(struct seq_file *m, seq_printf(m, "\tCEA rev: %d\n", connector->display_info.cea_rev); } - if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT || - intel_encoder->type == INTEL_OUTPUT_EDP) - intel_dp_info(m, intel_connector); - else if (intel_encoder->type == INTEL_OUTPUT_HDMI) - intel_hdmi_info(m, intel_connector); - else if (intel_encoder->type == INTEL_OUTPUT_LVDS) - intel_lvds_info(m, intel_connector); + if (intel_encoder) { + if (intel_encoder->type == INTEL_OUTPUT_DISPLAYPORT || + intel_encoder->type == INTEL_OUTPUT_EDP) + intel_dp_info(m, intel_connector); + else if (intel_encoder->type == INTEL_OUTPUT_HDMI) + intel_hdmi_info(m, intel_connector); + else if (intel_encoder->type == INTEL_OUTPUT_LVDS) + intel_lvds_info(m, intel_connector); + } seq_printf(m, "\tmodes:\n"); list_for_each_entry(mode, &connector->modes, head) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index afa5519..5852dee 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -1016,6 +1016,8 @@ static void i915_hotplug_work_func(struct work_struct *work) dev_priv->hpd_event_bits = 0; list_for_each_entry(connector, &mode_config->connector_list, head) { intel_connector = to_intel_connector(connector); + if (!intel_connector->encoder) + continue; intel_encoder = intel_connector->encoder; if (intel_encoder->hpd_pin > HPD_NONE && dev_priv->hpd_stats[intel_encoder->hpd_pin].hpd_mark == HPD_MARK_DISABLED && @@ -1046,6 +1048,8 @@ static void i915_hotplug_work_func(struct work_struct *work) list_for_each_entry(connector, &mode_config->connector_list, head) { intel_connector = to_intel_connector(connector); + if (!intel_connector->encoder) + continue; intel_encoder = intel_connector->encoder; if (hpd_event_bits & (1 << intel_encoder->hpd_pin)) { if (intel_encoder->hot_plug) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index b39d036..75b2aaf 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -4600,20 +4600,23 @@ static void intel_connector_check_state(struct intel_connector *connector) "wrong connector dpms state\n"); WARN(connector->base.encoder != &encoder->base, "active connector not linked to encoder\n"); - WARN(!encoder->connectors_active, -"encoder->connectors_active not set\n"); - encoder_enabled = encoder->get_hw_state(encoder, &pipe); - WARN(!encoder_enabled, "encoder not enabled\n"); - if (WARN_ON(!encoder->base.crtc)) - return; + if (encoder) { + WARN(!encoder->connectors_active, +"encoder->connectors_active not set\n"); + + encoder_enabled = encoder->get_hw_state(encoder, &pipe); + WARN(!encoder_enabled, "encoder not enabled\n"); + if (WARN_ON(!encoder->base.crtc)) + return; - crtc = encoder->base.crtc; + crtc = encoder->base.crtc; - WARN(!crtc->enabled, "crtc not enabled\n"); - WARN(!to_intel_crtc(crtc)->active, "crtc not active\n"); - WARN(pipe != to_intel_crtc(crtc)->pipe, -"encoder active on the wrong pipe\n"); + WARN(!crtc->enabled, "crtc not enabled\n"); + WARN(!to_intel_crtc(crtc)->active, "crtc not active\n"); + WARN(pipe != to_intel_crtc(crtc)->pipe, +"encoder active on the wrong pipe\n"); + } } } -- 1.9.0
[PATCH 07/10] i915: split some DP modesetting code into a separate function
From: Dave Airlie this is just prep work for mst support. Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/intel_ddi.c | 20 +--- drivers/gpu/drm/i915/intel_drv.h | 1 + 2 files changed, 14 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c index 0ad4e96..a5b8b76 100644 --- a/drivers/gpu/drm/i915/intel_ddi.c +++ b/drivers/gpu/drm/i915/intel_ddi.c @@ -364,6 +364,18 @@ void hsw_fdi_link_train(struct drm_crtc *crtc) DRM_ERROR("FDI link training failed!\n"); } +void intel_ddi_mode_set_dp(struct intel_encoder *encoder) +{ + struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); + struct intel_digital_port *intel_dig_port = + enc_to_dig_port(&encoder->base); + + intel_dp->DP = intel_dig_port->saved_port_bits | + DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW; + intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count); + +} + static void intel_ddi_mode_set(struct intel_encoder *encoder) { struct intel_crtc *crtc = to_intel_crtc(encoder->base.crtc); @@ -378,13 +390,7 @@ static void intel_ddi_mode_set(struct intel_encoder *encoder) crtc->eld_vld = false; if (type == INTEL_OUTPUT_DISPLAYPORT || type == INTEL_OUTPUT_EDP) { struct intel_dp *intel_dp = enc_to_intel_dp(&encoder->base); - struct intel_digital_port *intel_dig_port = - enc_to_dig_port(&encoder->base); - - intel_dp->DP = intel_dig_port->saved_port_bits | - DDI_BUF_CTL_ENABLE | DDI_BUF_EMP_400MV_0DB_HSW; - intel_dp->DP |= DDI_PORT_WIDTH(intel_dp->lane_count); - + intel_ddi_mode_set_dp(encoder); if (intel_dp->has_audio) { DRM_DEBUG_DRIVER("DP audio on pipe %c on DDI\n", pipe_name(crtc->pipe)); diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h index b885df1..8e41cdc 100644 --- a/drivers/gpu/drm/i915/intel_drv.h +++ b/drivers/gpu/drm/i915/intel_drv.h @@ -683,6 +683,7 @@ void intel_ddi_fdi_disable(struct drm_crtc *crtc); void intel_ddi_get_config(struct intel_encoder *encoder, struct intel_crtc_config *pipe_config); +void intel_ddi_mode_set_dp(struct intel_encoder *encoder); /* intel_display.c */ const char *intel_output_name(int output); -- 1.9.0
[PATCH 06/10] drm/helper: add Displayport multi-stream helper (v0.3)
From: Dave Airlie This is the initial import of the helper for displayport multistream. It consists of a topology manager, init/destroy/set mst state It supports DP 1.2 MST sideband msg protocol handler - via hpd irqs connector detect and edid retrieval interface. It supports i2c device over DP 1.2 sideband msg protocol (EDID reads only) bandwidth manager API via vcpi allocation and payload updating, along with a helper to check the ACT status. Objects: MST topology manager - one per toplevel MST capable GPU port - not sure if this should be higher level again MST branch unit - one instance per plugged branching unit - one at top of hierarchy - others hanging from ports MST port - one port per port reported by branching units, can have MST units hanging from them as well. Changes since initial posting: a) add a mutex responsbile for the queues, it locks the sideband and msg slots, and msgs to transmit state b) add worker to handle connection state change events, for MST device chaining and hotplug c) add a payload spinlock d) add path sideband msg support e) fixup enum path resources transmit f) reduce max dpcd msg to 16, as per DP1.2 spec. g) separate tx queue kicking from irq processing and move irq acking back to drivers. Changes since v0.2: a) reorganise code, b) drop ACT forcing code c) add connector naming interface using path property d) add topology dumper helper e) proper reference counting and lookup for ports and mstbs. f) move tx kicking into a workq g) add aux locking - this should be redone h) split teardown into two parts i) start working on documentation on interface. TODO: misc features Signed-off-by: Dave Airlie --- Documentation/DocBook/drm.tmpl|6 + drivers/gpu/drm/Makefile |2 +- drivers/gpu/drm/drm_dp_mst_topology.c | 2536 + include/drm/drm_dp_mst_helper.h | 503 +++ 4 files changed, 3046 insertions(+), 1 deletion(-) create mode 100644 drivers/gpu/drm/drm_dp_mst_topology.c create mode 100644 include/drm/drm_dp_mst_helper.h diff --git a/Documentation/DocBook/drm.tmpl b/Documentation/DocBook/drm.tmpl index 83dd0b0..1883976 100644 --- a/Documentation/DocBook/drm.tmpl +++ b/Documentation/DocBook/drm.tmpl @@ -2296,6 +2296,12 @@ void intel_crt_init(struct drm_device *dev) !Edrivers/gpu/drm/drm_dp_helper.c + Display Port MST Helper Functions Reference +!Pdrivers/gpu/drm/drm_dp_mst_topology.c dp mst helper +!Iinclude/drm/drm_dp_mst_helper.h +!Edrivers/gpu/drm/drm_dp_mst_topology.c + + EDID Helper Functions Reference !Edrivers/gpu/drm/drm_edid.c diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile index 48e38ba..712b73e 100644 --- a/drivers/gpu/drm/Makefile +++ b/drivers/gpu/drm/Makefile @@ -23,7 +23,7 @@ drm-$(CONFIG_DRM_PANEL) += drm_panel.o drm-usb-y := drm_usb.o -drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o +drm_kms_helper-y := drm_crtc_helper.o drm_dp_helper.o drm_probe_helper.o drm_dp_mst_topology.o drm_kms_helper-$(CONFIG_DRM_LOAD_EDID_FIRMWARE) += drm_edid_load.o drm_kms_helper-$(CONFIG_DRM_KMS_FB_HELPER) += drm_fb_helper.o drm_kms_helper-$(CONFIG_DRM_KMS_CMA_HELPER) += drm_fb_cma_helper.o diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c new file mode 100644 index 000..ca5c593 --- /dev/null +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -0,0 +1,2536 @@ +/* + * Copyright ? 2014 Red Hat + * + * Permission to use, copy, modify, distribute, and sell this software and its + * documentation for any purpose is hereby granted without fee, provided that + * the above copyright notice appear in all copies and that both that copyright + * notice and this permission notice appear in supporting documentation, and + * that the name of the copyright holders not be used in advertising or + * publicity pertaining to distribution of the software without specific, + * written prior permission. The copyright holders make no representations + * about the suitability of this software for any purpose. It is provided "as + * is" without express or implied warranty. + * + * THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, + * INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO + * EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY SPECIAL, INDIRECT OR + * CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, + * DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER + * TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE + * OF THIS SOFTWARE. + */ + +#include +#include +#include +#include +#include +#include +#include +#include + +#include + +/** + * DOC: dp mst helper + * + * These functions contain parts of the DisplayPort 1.2a MultiStream Transport + * protocol. The helpers contain a topology manager and bandwidth manager. + * The helpers encapsulate the sendin
[PATCH 05/10] drm: add a path blob property
From: Dave Airlie This property will be used by the MST code to provide userspace with a path to parse so it can recognise connectors around hotplugs. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_crtc.c | 26 ++ include/drm/drm_crtc.h | 5 + 2 files changed, 31 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index 8bf87a6..06b9255 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1165,6 +1165,7 @@ static int drm_mode_create_standard_connector_properties(struct drm_device *dev) { struct drm_property *edid; struct drm_property *dpms; + struct drm_property *dev_path; /* * Standard properties (apply to all connectors) @@ -1179,6 +1180,12 @@ static int drm_mode_create_standard_connector_properties(struct drm_device *dev) ARRAY_SIZE(drm_dpms_enum_list)); dev->mode_config.dpms_property = dpms; + dev_path = drm_property_create(dev, + DRM_MODE_PROP_BLOB | + DRM_MODE_PROP_IMMUTABLE, + "PATH", 0); + dev->mode_config.path_property = dev_path; + return 0; } @@ -3637,6 +3644,25 @@ done: return ret; } +int drm_mode_connector_set_path_property(struct drm_connector *connector, +char *path) +{ + struct drm_device *dev = connector->dev; + int ret, size; + size = strlen(path) + 1; + + connector->path_blob_ptr = drm_property_create_blob(connector->dev, + size, path); + if (!connector->path_blob_ptr) + return -EINVAL; + + ret = drm_object_property_set_value(&connector->base, + dev->mode_config.path_property, + connector->path_blob_ptr->base.id); + return ret; +} +EXPORT_SYMBOL(drm_mode_connector_set_path_property); + /** * drm_mode_connector_update_edid_property - update the edid property of a connector * @connector: drm connector diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index 55bc523..e33959b 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -500,6 +500,8 @@ struct drm_connector { struct drm_property_blob *edid_blob_ptr; struct drm_object_properties properties; + struct drm_property_blob *path_blob_ptr; + uint8_t polled; /* DRM_CONNECTOR_POLL_* */ /* requested DPMS state */ @@ -774,6 +776,7 @@ struct drm_mode_config { struct list_head property_blob_list; struct drm_property *edid_property; struct drm_property *dpms_property; + struct drm_property *path_property; struct drm_property *plane_type_property; /* DVI-I properties */ @@ -926,6 +929,8 @@ extern void drm_mode_config_init(struct drm_device *dev); extern void drm_mode_config_reset(struct drm_device *dev); extern void drm_mode_config_cleanup(struct drm_device *dev); +extern int drm_mode_connector_set_path_property(struct drm_connector *connector, + char *path); extern int drm_mode_connector_update_edid_property(struct drm_connector *connector, struct edid *edid); extern int drm_object_property_set_value(struct drm_mode_object *obj, -- 1.9.0
[PATCH 04/10] drm/crtc: add interface to reinitialise the legacy mode group
From: Dave Airlie This can be called to update things after dynamic connectors/encoders are created/deleted. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_crtc.c | 9 + include/drm/drm_crtc.h | 1 + 2 files changed, 10 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index f1753e6..8bf87a6 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -1421,6 +1421,15 @@ int drm_mode_group_init_legacy_group(struct drm_device *dev, } EXPORT_SYMBOL(drm_mode_group_init_legacy_group); +void drm_reinit_primary_mode_group(struct drm_device *dev) +{ + drm_modeset_lock_all(dev); + drm_mode_group_destroy(&dev->primary->mode_group); + drm_mode_group_init_legacy_group(dev, &dev->primary->mode_group); + drm_modeset_unlock_all(dev); +} +EXPORT_SYMBOL(drm_reinit_primary_mode_group); + /** * drm_crtc_convert_to_umode - convert a drm_display_mode into a modeinfo * @out: drm_mode_modeinfo struct to return to the user diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h index c6b9e8a..55bc523 100644 --- a/include/drm/drm_crtc.h +++ b/include/drm/drm_crtc.h @@ -916,6 +916,7 @@ extern const char *drm_get_tv_select_name(int val); extern void drm_fb_release(struct drm_file *file_priv); extern int drm_mode_group_init_legacy_group(struct drm_device *dev, struct drm_mode_group *group); extern void drm_mode_group_destroy(struct drm_mode_group *group); +extern void drm_reinit_primary_mode_group(struct drm_device *dev); extern bool drm_probe_ddc(struct i2c_adapter *adapter); extern struct edid *drm_get_edid(struct drm_connector *connector, struct i2c_adapter *adapter); -- 1.9.0
[PATCH 03/10] drm/i915: add some registers need for displayport MST support.
From: Dave Airlie These are just from the Haswell spec. Signed-off-by: Dave Airlie --- drivers/gpu/drm/i915/i915_reg.h | 11 +-- 1 file changed, 9 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index 8f84555..557b37a 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -5386,6 +5386,7 @@ enum punit_power_well { #define TRANS_DDI_EDP_INPUT_A_ONOFF (4<<12) #define TRANS_DDI_EDP_INPUT_B_ONOFF (5<<12) #define TRANS_DDI_EDP_INPUT_C_ONOFF (6<<12) +#define TRANS_DDI_DP_VC_PAYLOAD_ALLOC (1<<8) #define TRANS_DDI_BFI_ENABLE (1<<4) /* DisplayPort Transport Control */ @@ -5395,6 +5396,7 @@ enum punit_power_well { #define DP_TP_CTL_ENABLE (1<<31) #define DP_TP_CTL_MODE_SST(0<<27) #define DP_TP_CTL_MODE_MST(1<<27) +#define DP_TP_CTL_FORCE_ACT (1<<25) #define DP_TP_CTL_ENHANCED_FRAME_ENABLE (1<<18) #define DP_TP_CTL_FDI_AUTOTRAIN (1<<15) #define DP_TP_CTL_LINK_TRAIN_MASK (7<<8) @@ -5409,8 +5411,13 @@ enum punit_power_well { #define DP_TP_STATUS_A 0x64044 #define DP_TP_STATUS_B 0x64144 #define DP_TP_STATUS(port) _PORT(port, DP_TP_STATUS_A, DP_TP_STATUS_B) -#define DP_TP_STATUS_IDLE_DONE(1<<25) -#define DP_TP_STATUS_AUTOTRAIN_DONE (1<<12) +#define DP_TP_STATUS_IDLE_DONE(1<<25) +#define DP_TP_STATUS_ACT_SENT (1<<24) +#define DP_TP_STATUS_MODE_STATUS_MST (1<<23) +#define DP_TP_STATUS_AUTOTRAIN_DONE (1<<12) +#define DP_TP_STATUS_PAYLOAD_MAPPING_VC2 (3 << 8) +#define DP_TP_STATUS_PAYLOAD_MAPPING_VC1 (3 << 4) +#define DP_TP_STATUS_PAYLOAD_MAPPING_VC0 (3 << 0) /* DDI Buffer Control */ #define DDI_BUF_CTL_A 0x64000 -- 1.9.0
[PATCH 02/10] drm: add DP MST encoder type
From: Dave Airlie This adds an encoder type for DP MST encoders. Signed-off-by: Dave Airlie --- drivers/gpu/drm/drm_crtc.c | 1 + include/uapi/drm/drm_mode.h | 1 + 2 files changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index a3fe324..f1753e6 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -227,6 +227,7 @@ static const struct drm_prop_enum_list drm_encoder_enum_list[] = { DRM_MODE_ENCODER_TVDAC, "TV" }, { DRM_MODE_ENCODER_VIRTUAL, "Virtual" }, { DRM_MODE_ENCODER_DSI, "DSI" }, + { DRM_MODE_ENCODER_DPMST, "DP MST" }, }; static const struct drm_prop_enum_list drm_subpixel_enum_list[] = diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h index f104c26..719add4 100644 --- a/include/uapi/drm/drm_mode.h +++ b/include/uapi/drm/drm_mode.h @@ -181,6 +181,7 @@ struct drm_mode_get_plane_res { #define DRM_MODE_ENCODER_TVDAC 4 #define DRM_MODE_ENCODER_VIRTUAL 5 #define DRM_MODE_ENCODER_DSI 6 +#define DRM_MODE_ENCODER_DPMST 7 struct drm_mode_get_encoder { __u32 encoder_id; -- 1.9.0
[PATCH 01/10] drm/dp_helper: add defines for DP 1.2 and MST support.
From: Dave Airlie This just adds the defines from the DP 1.2 spec, which we will use later. Signed-off-by: Dave Airlie --- include/drm/drm_dp_helper.h | 78 + 1 file changed, 78 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index cfcacec..879836d 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -37,6 +37,7 @@ * eDP: Embedded DisplayPort version 1 * DPI: DisplayPort Interoperability Guideline v1.1a * 1.2: DisplayPort 1.2 + * MST: Multistream Transport - part of DP 1.2a * * 1.2 formally includes both eDP and DPI definitions. */ @@ -103,9 +104,14 @@ #define DP_TRAINING_AUX_RD_INTERVAL 0x00e /* XXX 1.2? */ /* Multiple stream transport */ +#define DP_FAUX_CAP0x020 /* 1.2 */ +# define DP_FAUX_CAP_1 (1 << 0) + #define DP_MSTM_CAP0x021 /* 1.2 */ # define DP_MST_CAP(1 << 0) +#define DP_GUID0x030 /* 1.2 */ + #define DP_PSR_SUPPORT 0x070 /* XXX 1.2? */ # define DP_PSR_IS_SUPPORTED1 #define DP_PSR_CAPS 0x071 /* XXX 1.2? */ @@ -221,6 +227,16 @@ # define DP_PSR_CRC_VERIFICATION (1 << 2) # define DP_PSR_FRAME_CAPTURE (1 << 3) +#define DP_ADAPTER_CTRL0x1a0 +# define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) + +#define DP_BRANCH_DEVICE_CTRL 0x1a1 +# define DP_BRANCH_DEVICE_IRQ_HPD (1 << 0) + +#define DP_PAYLOAD_ALLOCATE_SET0x1c0 +#define DP_PAYLOAD_ALLOCATE_START_TIME_SLOT 0x1c1 +#define DP_PAYLOAD_ALLOCATE_TIME_SLOT_COUNT 0x1c2 + #define DP_SINK_COUNT 0x200 /* prior to 1.2 bit 7 was reserved mbz */ # define DP_GET_SINK_COUNT(x) x) & 0x80) >> 1) | ((x) & 0x3f)) @@ -230,6 +246,9 @@ # define DP_REMOTE_CONTROL_COMMAND_PENDING (1 << 0) # define DP_AUTOMATED_TEST_REQUEST (1 << 1) # define DP_CP_IRQ (1 << 2) +# define DP_MCCS_IRQ (1 << 3) +# define DP_DOWN_REP_MSG_RDY (1 << 4) /* DP MST */ +# define DP_UP_REQ_MSG_RDY (1 << 5) /* DP MST */ # define DP_SINK_SPECIFIC_IRQ (1 << 6) #define DP_LANE0_1_STATUS 0x202 @@ -294,6 +313,13 @@ #define DP_TEST_SINK 0x270 #define DP_TEST_SINK_START (1 << 0) +#define DP_PAYLOAD_TABLE_UPDATE_STATUS 0x2c0 /* 1.2 MST */ +# define DP_PAYLOAD_TABLE_UPDATED (1 << 0) +# define DP_PAYLOAD_ACT_HANDLED (1 << 1) + +#define DP_VC_PAYLOAD_ID_SLOT_1 0x2c1 /* 1.2 MST */ +/* up to ID_SLOT_63 at 0x2ff */ + #define DP_SOURCE_OUI 0x300 #define DP_SINK_OUI0x400 #define DP_BRANCH_OUI 0x500 @@ -303,6 +329,21 @@ # define DP_SET_POWER_D30x2 # define DP_SET_POWER_MASK 0x3 +#define DP_SIDEBAND_MSG_DOWN_REQ_BASE 0x1000 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_UP_REP_BASE0x1200 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_DOWN_REP_BASE 0x1400 /* 1.2 MST */ +#define DP_SIDEBAND_MSG_UP_REQ_BASE0x1600 /* 1.2 MST */ + +#define DP_SINK_COUNT_ESI 0x2002 /* 1.2 */ +/* 0-5 sink count */ +# define DP_SINK_COUNT_CP_READY (1 << 6) + +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI0 0x2003 /* 1.2 */ + +#define DP_DEVICE_SERVICE_IRQ_VECTOR_ESI1 0x2004 /* 1.2 */ + +#define DP_LINK_SERVICE_IRQ_VECTOR_ESI0 0x2005 /* 1.2 */ + #define DP_PSR_ERROR_STATUS 0x2006 /* XXX 1.2? */ # define DP_PSR_LINK_CRC_ERROR (1 << 0) # define DP_PSR_RFB_STORAGE_ERROR (1 << 1) @@ -319,6 +360,43 @@ # define DP_PSR_SINK_INTERNAL_ERROR 7 # define DP_PSR_SINK_STATE_MASK 0x07 +/* DP 1.2 Sideband message defines */ +/* peer device type - DP 1.2a Table 2-92 */ +#define DP_PEER_DEVICE_NONE0x0 +#define DP_PEER_DEVICE_SOURCE_OR_SST 0x1 +#define DP_PEER_DEVICE_MST_BRANCHING 0x2 +#define DP_PEER_DEVICE_SST_SINK0x3 +#define DP_PEER_DEVICE_DP_LEGACY_CONV 0x4 + +/* DP 1.2 MST sideband request names DP 1.2a Table 2-80 */ +#define DP_LINK_ADDRESS0x01 +#define DP_CONNECTION_STATUS_NOTIFY0x02 +#define DP_ENUM_PATH_RESOURCES 0x10 +#define DP_ALLOCATE_PAYLOAD0x11 +#define DP_QUERY_PAYLOAD 0x12 +#define DP_RESOURCE_STATUS_NOTIFY 0x13 +#define DP_CLEAR_PAYLOAD_ID_TABLE 0x14 +#define DP_REMOTE_DPCD_READ0x20 +#define DP_REMOTE_DPCD_WRITE 0x21 +#define DP_REMOTE_I2C_READ 0x22 +#define DP_REMOTE_I2C_WRITE0x23 +#define DP_POWER_UP_PHY0x24 +#define DP_POWER_DOWN_PHY 0x25 +#define DP_SINK_EVENT_NOTIFY
[RFC] DisplayPort MST v0.3
Hi, A repost of the current state of the displayport MST support for i915, mainly targetted the Lenovo docks. Major changes since last posting: add a path blob property for userspace to use to track topology provide reference counting, locking and lookups for branch and port structs. some DocBook! fix i915 problems with DPMS - ordering of link bring up. aux channel locking - this should be pushed down I think into the aux helpers, TODO: fbcon support: fix non 4 lane 5.4Ghz. fix more of state checker harder. Dave.
[PATCH] drm/qxl: return IRQ_NONE if it was not our irq
Return IRQ_NONE if it was not our irq. This is necessary for the case when qxl is sharing irq line with a device A in a crash kernel. If qxl is initialized before A and A's irq was raised during this gap, returning IRQ_HANDLED in this case will cause this irq to be raised again after EOI since kernel think it was handled but in fact it was not. Cc: Gerd Hoffmann Cc: stable at vger.kernel.org Signed-off-by: Jason Wang --- drivers/gpu/drm/qxl/qxl_irq.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/qxl/qxl_irq.c b/drivers/gpu/drm/qxl/qxl_irq.c index 28f84b4..3485bdc 100644 --- a/drivers/gpu/drm/qxl/qxl_irq.c +++ b/drivers/gpu/drm/qxl/qxl_irq.c @@ -33,6 +33,9 @@ irqreturn_t qxl_irq_handler(int irq, void *arg) pending = xchg(&qdev->ram_header->int_pending, 0); + if (!pending) + return IRQ_NONE; + atomic_inc(&qdev->irq_received); if (pending & QXL_INTERRUPT_DISPLAY) { -- 1.9.1
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
On 12 May 2014 16:19, Christian K?nig wrote: > Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki: > >> DCE 3.1 and 3.2 have different HDMI registers and should be programmed >> in a slightly different way. Moving support to separated file will >> allow use to use rv770d.h header in the future and adjust code as well. > > Looks like a valid cleanup to me. Should probably go into 3.16. Thanks for review. Of course it's 3.16 material, no rush. I'll re-send with Signed-off-by in a bigger patchset, after extra testing.
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
Am 12.05.2014 15:54, schrieb Rafa? Mi?ecki: > DCE 3.1 and 3.2 have different HDMI registers and should be programmed > in a slightly different way. Moving support to separated file will > allow use to use rv770d.h header in the future and adjust code as well. Looks like a valid cleanup to me. Should probably go into 3.16. Christian. > --- > drivers/gpu/drm/radeon/Makefile | 2 +- > drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 > +++ > drivers/gpu/drm/radeon/r600_hdmi.c | 130 + > drivers/gpu/drm/radeon/radeon_asic.c | 2 +- > drivers/gpu/drm/radeon/radeon_asic.h | 7 ++ > 5 files changed, 235 insertions(+), 127 deletions(-) > create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c > > diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile > index 0943353..dbcbfe8 100644 > --- a/drivers/gpu/drm/radeon/Makefile > +++ b/drivers/gpu/drm/radeon/Makefile > @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \ > radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \ > rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \ > r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \ > - radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \ > + radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \ > evergreen.o evergreen_cs.o evergreen_blit_shaders.o \ > evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \ > atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \ > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c > b/drivers/gpu/drm/radeon/dce3_1_afmt.c > new file mode 100644 > index 000..4e3a8b7 > --- /dev/null > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c > @@ -0,0 +1,221 @@ > +#include > +#include "radeon.h" > +#include "radeon_asic.h" > +#include "r600d.h" > + > +static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder) > +{ > + struct radeon_device *rdev = encoder->dev->dev_private; > + struct drm_connector *connector; > + struct radeon_connector *radeon_connector = NULL; > + u32 tmp; > + u8 *sadb; > + int sad_count; > + > + list_for_each_entry(connector, > &encoder->dev->mode_config.connector_list, head) { > + if (connector->encoder == encoder) { > + radeon_connector = to_radeon_connector(connector); > + break; > + } > + } > + > + if (!radeon_connector) { > + DRM_ERROR("Couldn't find encoder's connector\n"); > + return; > + } > + > + sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, > &sadb); > + if (sad_count < 0) { > + DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", > sad_count); > + return; > + } > + > + /* program the speaker allocation */ > + tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER); > + tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); > + /* set HDMI mode */ > + tmp |= HDMI_CONNECTION; > + if (sad_count) > + tmp |= SPEAKER_ALLOCATION(sadb[0]); > + else > + tmp |= SPEAKER_ALLOCATION(5); /* stereo */ > + WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); > + > + kfree(sadb); > +} > + > +static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder) > +{ > + struct radeon_device *rdev = encoder->dev->dev_private; > + struct drm_connector *connector; > + struct radeon_connector *radeon_connector = NULL; > + struct cea_sad *sads; > + int i, sad_count; > + > + static const u16 eld_reg_to_type[][2] = { > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, > HDMI_AUDIO_CODING_TYPE_PCM }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, > HDMI_AUDIO_CODING_TYPE_AC3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, > HDMI_AUDIO_CODING_TYPE_MPEG1 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, > HDMI_AUDIO_CODING_TYPE_MP3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, > HDMI_AUDIO_CODING_TYPE_MPEG2 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, > HDMI_AUDIO_CODING_TYPE_AAC_LC }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, > HDMI_AUDIO_CODING_TYPE_DTS }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, > HDMI_AUDIO_CODING_TYPE_ATRAC }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, > HDMI_AUDIO_CODING_TYPE_EAC3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, > HDMI_AUDIO_CODING_TYPE_DTS_HD }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, > HDMI_AUDIO_CODING_TYPE_MLP }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, > HDMI_AUDIO_CODING_TYPE_WMA_PRO }, > + }; > + > + list_for_each_entry(connector, > &encoder->dev->mode_config.connector_list, head) { > +
[Bug 75841] radeon (radeonsi): GPU crash and resulting kernel problems (hangs etc.)
https://bugzilla.kernel.org/show_bug.cgi?id=75841 --- Comment #6 from Darren Salt --- http://lists.freedesktop.org/archives/dri-devel/2014-May/059365.html Testing with that patch series applied ? no problems noticed so far. Looks like we might have a fix for this bug here. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] Design review request: DRM color manager
Hello Daniel, Please find the actual problem statement and design overview : == 1. There are different color correction methods, supported by various SOCs, across various platforms. 2. These properties vary platform-by-platform, driver-to-driver. For example, one of the Intel SOC support CSC correction, Gamma correction, Hue and Saturation correction, Brightness and Contrast correction. One other Intel SOC supports two of above mentioned properties, and 2 other properties. Hardly any of these properties are exposed properly to userspace to be used to its real potential due to lack of proper interface. 3. Even if we go for a direct DRM property interface for each of the correction possible, if some hardware supports 10 color correction properties, a driver is supposed to create 10 DRM properties corresponding to each. But most of the time what these color correction properties do is, apply some correction values on some hardware registers, and enable / disable the property. 4. Color manager is the one common interface for all such properties supported by all these drivers, which follows a particular protocol, to extract this color correction information from the userspace call, call the drivers apply method with all the required Information. Benefits of using color manager: 1. Unique framework for all the color correction properties, across all DRM drivers, across various platforms. 2. Only one set/get call for all kind of properties using the common protocol. One get call can tell what are the color correction capabilities of the SOC, registered by driver. 3. The corrections value range that can be covered using this can be single valued to any no. We can apply from single values brightness/contrast to full range LUT of a gamma correction using the same interface. 4. Hardware specific quirks can be applied on specific corrections. 5. A few of color corrections(like gamma correction) deal with floating point values, which is not easy to handle in Kernel. We can always delegate this FP conversion work to some userspace library, and get the direct register values using the interface. This kind of library can be expanded for various facilities to provide color-support. We have implemented color manager implementation for one of the MCG code line, and lot of commercial solutions are using those color properties using the simple interface for Brightness, CSC and Gamma correction, and fine tuning to the best display experience for their panel. This part was not very well used due to lack of proper interface. I think this design will help us to expose color correction capabilities of various SOCs and drivers, and will give an centrally controlled interface for ease of access also. Please let me know if this makes a point. Regards Shashank On 5/12/2014 2:21 PM, Daniel Vetter wrote: > Re-adding dri-devel, all drm core stuff must be discussed there. > > But on the actual issue at hand I still don't understand what you're > trying to solve. You add a complete new set of properties, using Intel > names (pipes, planes) for some attributes which at first seems > completely redundant to all the properties we already have. > > What's the technical reasons for adding this interface? Your proposal > is only describing how it works, so is lacking this crucial > information. > -Daniel > > On Wed, May 7, 2014 at 4:22 PM, Sharma, Shashank > wrote: >> Hello all, >> >> As per previous discussions, I am sending the drm-color-manager design for >> review, as inline text. Please have a look and let me know your feedback. >> >> (I tried hard to align the inline text diagram in mail, hope you can see the >> proper picture too) >> >> = >> DRM Color Manager >> = >> >> - Color manager provides a common interface for all color correction / >>enhancement properties supported by various hardwares. >> - Color manager will be one Umbrella DRM property (blob type) >> - Driver can register the color correction properties of its HW during >>the init time, and all the corrections can be applied using the same >>interface. >> >> How does a driver register color properties with DRM color manager: >> --- >> >> - A DRM driver will call drm_register_color_manager() function with >> following information: >> .prop_set_handler >> .prop_get_hanlder >> .color_prop_identifier structure >> {porp_name, prop_id} >> {porp_name, prop_id} >> {porp_name, prop_id} >> >> For example: I915 driver can register as: >> .prop_set_handler = intel_clrmgr_set() >> .prop_get_hanlder = intel_clrmgr_get() >> .color_prop_identifier structure >> {gamma_correction, 0} >> {csc_correction,
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
DCE 3.1 and 3.2 have different HDMI registers and should be programmed in a slightly different way. Moving support to separated file will allow use to use rv770d.h header in the future and adjust code as well. --- drivers/gpu/drm/radeon/Makefile | 2 +- drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 +++ drivers/gpu/drm/radeon/r600_hdmi.c | 130 + drivers/gpu/drm/radeon/radeon_asic.c | 2 +- drivers/gpu/drm/radeon/radeon_asic.h | 7 ++ 5 files changed, 235 insertions(+), 127 deletions(-) create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile index 0943353..dbcbfe8 100644 --- a/drivers/gpu/drm/radeon/Makefile +++ b/drivers/gpu/drm/radeon/Makefile @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \ radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \ rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \ r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \ - radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \ + radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \ evergreen.o evergreen_cs.o evergreen_blit_shaders.o \ evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \ atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o si.o \ diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c b/drivers/gpu/drm/radeon/dce3_1_afmt.c new file mode 100644 index 000..4e3a8b7 --- /dev/null +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c @@ -0,0 +1,221 @@ +#include +#include "radeon.h" +#include "radeon_asic.h" +#include "r600d.h" + +static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder) +{ + struct radeon_device *rdev = encoder->dev->dev_private; + struct drm_connector *connector; + struct radeon_connector *radeon_connector = NULL; + u32 tmp; + u8 *sadb; + int sad_count; + + list_for_each_entry(connector, &encoder->dev->mode_config.connector_list, head) { + if (connector->encoder == encoder) { + radeon_connector = to_radeon_connector(connector); + break; + } + } + + if (!radeon_connector) { + DRM_ERROR("Couldn't find encoder's connector\n"); + return; + } + + sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, &sadb); + if (sad_count < 0) { + DRM_ERROR("Couldn't read Speaker Allocation Data Block: %d\n", sad_count); + return; + } + + /* program the speaker allocation */ + tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER); + tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); + /* set HDMI mode */ + tmp |= HDMI_CONNECTION; + if (sad_count) + tmp |= SPEAKER_ALLOCATION(sadb[0]); + else + tmp |= SPEAKER_ALLOCATION(5); /* stereo */ + WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); + + kfree(sadb); +} + +static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder) +{ + struct radeon_device *rdev = encoder->dev->dev_private; + struct drm_connector *connector; + struct radeon_connector *radeon_connector = NULL; + struct cea_sad *sads; + int i, sad_count; + + static const u16 eld_reg_to_type[][2] = { + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, HDMI_AUDIO_CODING_TYPE_PCM }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, HDMI_AUDIO_CODING_TYPE_AC3 }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, HDMI_AUDIO_CODING_TYPE_MPEG1 }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, HDMI_AUDIO_CODING_TYPE_MP3 }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, HDMI_AUDIO_CODING_TYPE_MPEG2 }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, HDMI_AUDIO_CODING_TYPE_AAC_LC }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, HDMI_AUDIO_CODING_TYPE_DTS }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, HDMI_AUDIO_CODING_TYPE_ATRAC }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, HDMI_AUDIO_CODING_TYPE_EAC3 }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, HDMI_AUDIO_CODING_TYPE_DTS_HD }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, HDMI_AUDIO_CODING_TYPE_MLP }, + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR13, HDMI_AUDIO_CODING_TYPE_WMA_PRO }, + }; + + list_for_each_entry(connector, &encoder->dev->mode_config.connector_list, head) { + if (connector->encoder == encoder) { + radeon_connector = to_radeon_connector(connector); + break; + } + } + + if (!radeon_connector) { + DRM_ERROR("Cou
[PATCH 2/2] drm/radeon: fix buffer placement under memory pressure v2
From: Christian K?nig Some buffers (UVD/VM page tables) must be placed in VRAM, but the byte restriction for moving buffers didn't took this into account. v2: keep closer to the original code Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_object.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_object.c b/drivers/gpu/drm/radeon/radeon_object.c index 72705fb..4faa4d6 100644 --- a/drivers/gpu/drm/radeon/radeon_object.c +++ b/drivers/gpu/drm/radeon/radeon_object.c @@ -458,7 +458,7 @@ int radeon_bo_list_validate(struct radeon_device *rdev, * into account. We don't want to disallow buffer moves * completely. */ - if (current_domain != RADEON_GEM_DOMAIN_CPU && + if ((lobj->alt_domain & current_domain) != 0 && (domain & current_domain) == 0 && /* will be moved */ bytes_moved > bytes_moved_threshold) { /* don't move it */ -- 1.9.1
[PATCH 1/2] drm/radeon: fix page directory update size estimation
From: Christian K?nig Take padding into account as well. Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75651 Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/radeon_vm.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_vm.c b/drivers/gpu/drm/radeon/radeon_vm.c index 2aae6ce..d9ab99f 100644 --- a/drivers/gpu/drm/radeon/radeon_vm.c +++ b/drivers/gpu/drm/radeon/radeon_vm.c @@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_device *rdev, ndw = 64; /* assume the worst case */ - ndw += vm->max_pde_used * 12; + ndw += vm->max_pde_used * 16; /* update too big for an IB */ if (ndw > 0xf) -- 1.9.1
[PATCH] drm/radeon: add a i2c bus mutex
Am 08.05.2014 16:58, schrieb Alex Deucher: > The i2c and aux buses use the same pads so add > a mutex to protect access to the pads. > > Signed-off-by: Alex Deucher I've applied this one, "drm/radeon: fix DCE83 check for mullins" and "drm/radeon: handle non-VGA class pci devices with ATRM" my 3.15 queue. Thanks, Christian. > --- > drivers/gpu/drm/radeon/atombios_dp.c | 18 ++ > drivers/gpu/drm/radeon/atombios_i2c.c | 17 + > drivers/gpu/drm/radeon/radeon_i2c.c | 9 + > drivers/gpu/drm/radeon/radeon_mode.h | 1 + > 4 files changed, 37 insertions(+), 8 deletions(-) > > diff --git a/drivers/gpu/drm/radeon/atombios_dp.c > b/drivers/gpu/drm/radeon/atombios_dp.c > index 54e4f52..3bb0933 100644 > --- a/drivers/gpu/drm/radeon/atombios_dp.c > +++ b/drivers/gpu/drm/radeon/atombios_dp.c > @@ -95,9 +95,12 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan > *chan, > int index = GetIndexIntoMasterTable(COMMAND, > ProcessAuxChannelTransaction); > unsigned char *base; > int recv_bytes; > + int r = 0; > > memset(&args, 0, sizeof(args)); > > + mutex_lock(&chan->mutex); > + > base = (unsigned char *)(rdev->mode_info.atom_context->scratch + 1); > > radeon_atom_copy_swap(base, send, send_bytes, true); > @@ -117,19 +120,22 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan > *chan, > /* timeout */ > if (args.v1.ucReplyStatus == 1) { > DRM_DEBUG_KMS("dp_aux_ch timeout\n"); > - return -ETIMEDOUT; > + r = -ETIMEDOUT; > + goto done; > } > > /* flags not zero */ > if (args.v1.ucReplyStatus == 2) { > DRM_DEBUG_KMS("dp_aux_ch flags not zero\n"); > - return -EBUSY; > + r = -EBUSY; > + goto done; > } > > /* error */ > if (args.v1.ucReplyStatus == 3) { > DRM_DEBUG_KMS("dp_aux_ch error\n"); > - return -EIO; > + r = -EIO; > + goto done; > } > > recv_bytes = args.v1.ucDataOutLen; > @@ -139,7 +145,11 @@ static int radeon_process_aux_ch(struct radeon_i2c_chan > *chan, > if (recv && recv_size) > radeon_atom_copy_swap(recv, base + 16, recv_bytes, false); > > - return recv_bytes; > + r = recv_bytes; > +done: > + mutex_unlock(&chan->mutex); > + > + return r; > } > > #define BARE_ADDRESS_SIZE 3 > diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c > b/drivers/gpu/drm/radeon/atombios_i2c.c > index b5162c3..9c570fb 100644 > --- a/drivers/gpu/drm/radeon/atombios_i2c.c > +++ b/drivers/gpu/drm/radeon/atombios_i2c.c > @@ -43,15 +43,19 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan > *chan, > int index = GetIndexIntoMasterTable(COMMAND, > ProcessI2cChannelTransaction); > unsigned char *base; > u16 out = cpu_to_le16(0); > + int r = 0; > > memset(&args, 0, sizeof(args)); > > + mutex_lock(&chan->mutex); > + > base = (unsigned char *)rdev->mode_info.atom_context->scratch; > > if (flags & HW_I2C_WRITE) { > if (num > ATOM_MAX_HW_I2C_WRITE) { > DRM_ERROR("hw i2c: tried to write too many bytes (%d vs > 3)\n", num); > - return -EINVAL; > + r = -EINVAL; > + goto done; > } > if (buf == NULL) > args.ucRegIndex = 0; > @@ -65,7 +69,8 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan > *chan, > } else { > if (num > ATOM_MAX_HW_I2C_READ) { > DRM_ERROR("hw i2c: tried to read too many bytes (%d vs > 255)\n", num); > - return -EINVAL; > + r = -EINVAL; > + goto done; > } > args.ucRegIndex = 0; > args.lpI2CDataOut = 0; > @@ -82,13 +87,17 @@ static int radeon_process_i2c_ch(struct radeon_i2c_chan > *chan, > /* error */ > if (args.ucStatus != HW_ASSISTED_I2C_STATUS_SUCCESS) { > DRM_DEBUG_KMS("hw_i2c error\n"); > - return -EIO; > + r = -EIO; > + goto done; > } > > if (!(flags & HW_I2C_WRITE)) > radeon_atom_copy_swap(buf, base, num, false); > > - return 0; > +done: > + mutex_unlock(&chan->mutex); > + > + return r; > } > > int radeon_atom_hw_i2c_xfer(struct i2c_adapter *i2c_adap, > diff --git a/drivers/gpu/drm/radeon/radeon_i2c.c > b/drivers/gpu/drm/radeon/radeon_i2c.c > index 7b94414..427ee4d 100644 > --- a/drivers/gpu/drm/radeon/radeon_i2c.c > +++ b/drivers/gpu/drm/radeon/radeon_i2c.c > @@ -94,6 +94,8 @@ static int pre_xfer(struct i2c_adapter *i2c_adap) > struct radeon_i2c_bus_rec *rec = &i2c->rec; > uint32_t temp; > > + mutex_lock(&i2c->mutex); > + > /* RV410 appears to have a bug where t
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #34 from Christian K?nig --- (In reply to Alex Deucher from comment #33) > I wonder if UVD uses the reference clock directly, or if it uses xclk. If > it uses xclk, they may explain the problems. They can be different? Yeah that would indeed explain the issue. AFAIK RV730 uses XTALIN directly for the UVD PLLs. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC PATCH 1/2] drm/panel: add support for simple-panel description definition using DT
On 09/05/2014 16:16, Boris BREZILLON wrote: > Currently, the only way to add new panel descriptions to the simple panel > driver is to add new entries in the platform_of_match table. > > Add support for panel description retrieval from the DT. > > Signed-off-by: Boris BREZILLON > --- > drivers/gpu/drm/panel/Kconfig| 1 + > drivers/gpu/drm/panel/panel-simple.c | 70 > > 2 files changed, 71 insertions(+) > > diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig > index 4ec874d..4fe3d48 100644 > --- a/drivers/gpu/drm/panel/Kconfig > +++ b/drivers/gpu/drm/panel/Kconfig > @@ -1,6 +1,7 @@ > config DRM_PANEL > bool > depends on DRM > + select VIDEOMODE_HELPERS > help > Panel registration and lookup framework. > > diff --git a/drivers/gpu/drm/panel/panel-simple.c > b/drivers/gpu/drm/panel/panel-simple.c > index 309f29e..fcf648d 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -33,6 +33,10 @@ > #include > #include > > +#include > +#include > +#include > + > struct panel_desc { > const struct drm_display_mode *modes; > unsigned int num_modes; > @@ -168,6 +172,61 @@ static const struct drm_panel_funcs panel_simple_funcs = > { > .get_modes = panel_simple_get_modes, > }; > > +static struct panel_desc *of_panel_desc_init(struct device *dev) > +{ > + struct display_timings *timings; > + struct panel_desc *desc; > + u32 width, height; > + int err; > + int i; > + > + err = of_property_read_u32(dev->of_node, "width", &width); > + if (err) > + return ERR_PTR(err); > + > + err = of_property_read_u32(dev->of_node, "height", &height); > + if (err) > + return ERR_PTR(err); > + > + desc = devm_kzalloc(dev, sizeof(*desc), GFP_KERNEL); > + if (!desc) > + return ERR_PTR(-ENOMEM); > + > + timings = of_get_display_timings(dev->of_node); > + if (timings) { > + struct drm_display_mode *modes = > + devm_kzalloc(dev, > + timings->num_timings * > + sizeof(*desc->modes), > + GFP_KERNEL); > + > + if (!modes) > + return ERR_PTR(-ENOMEM); > + > + for (i = 0; i < timings->num_timings; i++) { > + struct videomode vm; > + > + if (videomode_from_timings(timings, &vm, i)) > + break; > + > + drm_display_mode_from_videomode(&vm, modes + i); > + > + modes[i].type = DRM_MODE_TYPE_DRIVER; > + > + if (timings->native_mode == i) > + modes[i].type |= DRM_MODE_TYPE_PREFERRED; > + desc->num_modes++; > + } Oops, I forgot to add: desc->modes = modes; > + > + kfree(timings); > + } > + > + desc->size.width = width; > + desc->size.height = height; > + > + return desc; > +} > + > static int panel_simple_probe(struct device *dev, const struct panel_desc > *desc) > { > struct device_node *backlight, *ddc; > @@ -178,6 +237,17 @@ static int panel_simple_probe(struct device *dev, const > struct panel_desc *desc) > if (!panel) > return -ENOMEM; > > + if (!desc) { > + desc = of_panel_desc_init(dev); > + /* > + * Do not fail on DT panel desc retrieval error because > + * some systems do not need a panel description to work > + * properly. > + */ > + if (IS_ERR(desc)) > + desc = NULL; > + } > + > panel->enabled = false; > panel->desc = desc; > -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #33 from Alex Deucher --- I wonder if UVD uses the reference clock directly, or if it uses xclk. If it uses xclk, they may explain the problems. Can you post your dmesg output with this patch applied? diff --git a/drivers/gpu/drm/radeon/rv770.c b/drivers/gpu/drm/radeon/rv770.c index fef3107..bda9137 100644 --- a/drivers/gpu/drm/radeon/rv770.c +++ b/drivers/gpu/drm/radeon/rv770.c @@ -1594,6 +1594,9 @@ static void rv770_gpu_init(struct radeon_device *rdev) WREG32(PA_CL_ENHANCE, (CLIP_VTX_REORDER_ENA | NUM_CLIP_SEQ(3))); WREG32(VC_ENHANCE, 0); + + DRM_INFO("ref: %u, xclk: %u\n", +rdev->clock.spll.reference_freq, rv770_get_xclk(rdev)); } void r700_vram_gtt_location(struct radeon_device *rdev, struct radeon_mc *mc) -- You are receiving this mail because: You are watching the assignee of the bug.
OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
On 12/05/14 14:33, Vikas Patil wrote: > Hi, > > Re-posting as previous posting was rejected due to length. > > Forgot to mention, DPI pins are connected to TDF19988 chip for HDMI > conversion. > I have build the driver for it from > https://gitorious.org/thierryreding/linux/source/e7792ce2da5ded80861db787ace9b57ecf7bc96c:drivers/gpu/drm/i2c/tda998x_drv.c. > Is this the correct driver for it? That driver cannot be used with omapdrm, which uses omapdss. There's no TDF19988 driver for omapdss (at least in the mainline), so you need to write one. > Also I am trying to use the generic-dpi-panel driver for this with > OMAP5. It seems I also need to add support for TDF19988 somewhere in > omapdrm or lcd/panel driver by calling drm_i2c_encoder_init to > initialize it. Can I use somecode from ticldc driver or driver itself? > Could you please give some inputs, how should I proceed further to > adding support for TDF19988 for which the input is coming from DPI > interface? You need to write a driver for it. Something similar to drivers/video/fbdev/omap2/displays-new/encoder-tfp410.c, except tfp410 is quite simple one. But I think you said you're based on some old customized kernel, so I don't know which kind of omapdss driver you have there, so the mainline tfp410 cannot probably be used as an example. Most likely the omapdss drivers for your kernel are located in drivers/video/omap2/displays/ directory. Tomi -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/e8ac1a4c/attachment.sig>
CIK hangs with kernel 3.15, bisected
I could reproduce the problem with xonotic and I think I've found the issue. Please test the attached patch. Thanks, Christian. Am 11.05.2014 11:06, schrieb Christian K?nig: >> I have tested it and it doesn't fix the hangs. > Yeah, thought so. Well it was just a guess. > >> (Also, I don't like the patch, because it reverts the behavior I added >> for userspace buffers.) > Actually it shouldn't affect that. The alternative domain always > contains GART even when userspace only specified VRAM as placement (as > long as it is technical possible to do so). > > So what should happen is that TTM sees the current placement, matches > that with the desired placement and should find that it doesn't need > to move the buffer (we should just test if this behavior really works > as expected). > > Christian. > > Am 10.05.2014 23:38, schrieb Marek Ol??k: >> Hi Christian, >> >> I have tested it and it doesn't fix the hangs. >> >> (Also, I don't like the patch, because it reverts the behavior I added >> for userspace buffers.) >> >> Marek >> >> >> >> On Sat, May 10, 2014 at 6:34 PM, Christian K?nig >> wrote: >>> Couldn't reproduce the issue so far. So the attached patch is just a >>> complete shoot into the dark found by rereading the code, but it might >>> actually be the problem. >>> >>> Please give it a try. >>> >>> Going to keep testing in the meantime, >>> Christian. >>> >>> Am 10.05.2014 10:23, schrieb Christian K?nig: >>> >>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if >>>>> I boot >>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high >>>>> settings. >>>>> I haven't had a chance to bisect it yet, but it might be a similar >>>>> problem. >>>> Sounds like the same issue to me. Thx for the good test case. >>>> >>>>> Any idea what is wrong with it? >>>> Actually I already wondered that it went so smooth without any >>>> regression >>>> so far, didn't noticed the bug in bugzilla.kernel.org yet. >>>> >>>>> Some of the tests allocate a lot of MSAA textures and the tests also >>>>> run in parallel, which creates a lot of memory pressure and probably >>>>> causes buffer evictions. >>>> Sounds like the underlying problem to me. We probably evict some >>>> part of a >>>> page table without updating the page directory. Going to dig into >>>> it today, >>>> it's probably just a one liner missing somewhere in the VM code. >>>> >>>> Christian. >>>> >>>> Am 09.05.2014 23:39, schrieb Grigori Goronzy: >>>>> On 09.05.2014 20:03, Marek Ol??k wrote: >>>>>> >>>>>> This commit which first appeared in 3.15-rc1 causes hangs on >>>>>> Bonaire: >>>>>> [...] >>>>>> >>>>>> The simplest way to reproduce the hangs is to run piglit with these >>>>>> parameters: >>>>>> -t texelFetch.fs >>>>>> >>>>>> Some of the tests allocate a lot of MSAA textures and the tests also >>>>>> run in parallel, which creates a lot of memory pressure and probably >>>>>> causes buffer evictions. >>>>>> >>>>> I see hangs with kernel 3.15 and SI under memory pressure, e.g. if >>>>> I boot >>>>> with radeon.vramlimit=256 and then run Xonotic timedemo with high >>>>> settings. >>>>> I haven't had a chance to bisect it yet, but it might be a similar >>>>> problem. >>>>> >>>>> Grigori >>>> > -- next part -- A non-text attachment was scrubbed... Name: 0001-drm-radeon-fix-page-directory-update-size-estimation.patch Type: text/x-diff Size: 986 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/35410e95/attachment.patch>
[Bug 78366] [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore)
https://bugs.freedesktop.org/show_bug.cgi?id=78366 --- Comment #3 from Alex Deucher --- (In reply to comment #2) > > Apparently, memory is recovered by closing Firefox. Top doesn't show it > using that much memory, but it somehow does in less traceable ways. Server side resources: http://www.freedesktop.org/wiki/Software/xrestop/ -- 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/20140512/7d10e9f2/attachment.html>
[Bug 74551] Unable to enable ACPI
https://bugzilla.kernel.org/show_bug.cgi?id=74551 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #2 from Alex Deucher --- (In reply to maxis11 from comment #1) > acer aspire 5560g has problem with gpt, so I convert using gdisk gpt to mbr, > and problem seems fixed. But there is another problem, computer freezes > during boot with radeon.runpm=1. Should I create another bug report? Is that still and issue with a 3.15 kernel? I believe that should be fixed now (with patches destined for stable as well). -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75951] Radeon HD, GPU CP Stall on "Octodad - Dadliest catch"
https://bugzilla.kernel.org/show_bug.cgi?id=75951 Alex Deucher changed: What|Removed |Added CC||alexdeucher at gmail.com --- Comment #1 from Alex Deucher --- This is a mesa bug rather than a kernel bug: https://bugs.freedesktop.org/show_bug.cgi?id=75784 -- You are receiving this mail because: You are watching the assignee of the bug.
OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
Well, there's at least a bit in the dss that needs to be configured for DPI to be routed correctly. Commit de09e492986219132b518c3f7834a28823cd in the mainline does that. Then, if using DSI PLL, the clock routing needs to be fixed for OMAP5, mainline commit f8ad984ce0372f43006f5c700310c2d6f301085d does that. I'm not sure if there are any other OMAP5 DPI specific things, those are the ones I remember. Tomi On 12/05/14 11:41, Vikas Patil wrote: > Hi Tomi, > > How could I confirm for OMAP5 DPI support apart form enabling > CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned > config builds components from Kernel\drivers\video\omap2\dss and > kernel\drivers\video\omap2\displays only. Is there any support needs to > be available under kernel\arch\arm\mach-omap2? > > Regards, > Vikash > > > On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen <mailto:tomi.valkeinen at ti.com>> wrote: > > On 08/05/14 13:07, Vikas Patil wrote: > > Hi, > > > > I am working on to enable the second display output for customized > OMAP5 > > based platform and linux 3.4.25. First display which is HDMI/tv is > > working fine. Second display out is coming via DPI interface. To > enable > > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and > > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and > > omap_dss_board_info and removed the HDMI device and disabled > > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly, > > however when I try to run kmscube app and it seems to be running, > > noticing following error and till now nothing on display. > > Does the kernel have support for OMAP5 DPI? I remember there were some > bits that had to be added to make it work. > > Tomi > > > -- next part -- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/977f4bf9/attachment-0001.sig>
[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels
https://bugzilla.kernel.org/show_bug.cgi?id=74751 --- Comment #19 from William Shuman --- try the patch mentioned in https://bugzilla.kernel.org/show_bug.cgi?id=75651 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 74751] resume from suspend broken with 3.15-rc1 and rc2 kernels
https://bugzilla.kernel.org/show_bug.cgi?id=74751 --- Comment #18 from Tasev Nikola --- Hi Just tested now 3.15-rc5, still not working. -- You are receiving this mail because: You are watching the assignee of the bug.
OMAPDSS: omap5 SYNC_LOST error with DPI/LCD
Hi Tomi, How could I confirm for OMAP5 DPI support apart form enabling CONFIG_OMAP2_DSS_DPI and CONFIG_PANEL_GENERIC_DPI? Enabling mentioned config builds components from Kernel\drivers\video\omap2\dss and kernel\drivers\video\omap2\displays only. Is there any support needs to be available under kernel\arch\arm\mach-omap2? Regards, Vikash On Fri, May 9, 2014 at 4:49 PM, Tomi Valkeinen wrote: > On 08/05/14 13:07, Vikas Patil wrote: > > Hi, > > > > I am working on to enable the second display output for customized OMAP5 > > based platform and linux 3.4.25. First display which is HDMI/tv is > > working fine. Second display out is coming via DPI interface. To enable > > DPI interface I enabled CONFIG_OMAP2_DSS_DPI and > > CONFIG_PANEL_GENERIC_DPI and added that in omap_dss_device and > > omap_dss_board_info and removed the HDMI device and disabled > > CONFIG_OMAP5_DSS_HDMI. With his kernel seems to be booting correctly, > > however when I try to run kmscube app and it seems to be running, > > noticing following error and till now nothing on display. > > Does the kernel have support for OMAP5 DPI? I remember there were some > bits that had to be added to make it work. > > Tomi > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/6f567d1f/attachment.html>
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
On Mon, May 12, 2014 at 1:42 PM, Rafa? Mi?ecki wrote: > On 12 May 2014 17:57, Alex Deucher wrote: >> On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote: >>> DCE 3.1 and 3.2 have different HDMI registers and should be programmed >>> in a slightly different way. Moving support to separated file will >>> allow use to use rv770d.h header in the future and adjust code as well. >> >> Any reason not to split it at DCE3.2 rather than 3.1? It seems like >> most (all?) of the changes are DCE3.2 specific rather than DCE3.1. >> Otherwise, seems fine to me. > > I believe DCE 3.1 has HDMI much more like DCE 3.2 and it's programmed > in a very similar way. Also it has 3.2 regs like DESCRIPTORs. The > biggest difference is that DCE 3.1 doesn't seem to have > AFMT_AUDIO_PACKET_CONTROL and AFMT_INFOFRAME_CONTROL0. > > Take a look at defines for DCE 3.2. Even they are placed in rv770d.h, > which is the DCE 3.1 chipset. Well, they were placed in there since rv770d.h was used by all r7xx asics which is a mix of DCE3.1 and 3.2. As far as I recall, 3.1 is pretty much the same as 3.0 from a programming perspective, but it's been a while since I looked at it in detail. The current hdmi code doesn't seem to have any DCE3.1 specific code at the moment. Alex
[Bug 78287] [drm:radeon_cs_ioctl] *ERROR* Failed to parse relocation -12!
https://bugs.freedesktop.org/show_bug.cgi?id=78287 --- Comment #4 from Alex Deucher --- In this actually a failure to allocate regular system memory (kalloc or drm_malloc_ab). -- 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/20140512/d91fb3de/attachment.html>
[Intel-gfx] Design review request: DRM color manager
Hi On Mon, May 12, 2014 at 12:26 PM, Sharma, Shashank wrote: > Benefits of using color manager: > > 1. Unique framework for all the color correction properties, across all >DRM drivers, across various platforms. > 2. Only one set/get call for all kind of properties using the common > protocol. One get call can tell what are the color correction capabilities > of the SOC, registered by driver. What's the advantage of that? We should add a DRM_MODE_OBJ_SET_PROPERTIES call if we want to accelerate things, instead of adding huge payloads. I really think we should define one property for each color-correction interface. I cannot see any downside of that except that we should add DRM_MODE_OBJ_SET_PROPERTIES. But afaik that's already the plan for atomic-modesetting, right? Thanks David
[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected
https://bugzilla.kernel.org/show_bug.cgi?id=75651 William Shuman changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |PATCH_ALREADY_AVAILABLE -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected
https://bugzilla.kernel.org/show_bug.cgi?id=75651 --- Comment #9 from Christian K?nig --- Thanks for the info, so we can close this bug now? -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected
https://bugzilla.kernel.org/show_bug.cgi?id=75651 --- Comment #8 from William Shuman --- This fixed this issue. Thanks for your work. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 75651] resume from suspend failing 3.15(rc1,rc2,rc3,rc4) bisected
https://bugzilla.kernel.org/show_bug.cgi?id=75651 Christian K?nig changed: What|Removed |Added Attachment #135731|0 |1 is obsolete|| --- Comment #7 from Christian K?nig --- Created attachment 135881 --> https://bugzilla.kernel.org/attachment.cgi?id=135881&action=edit Possible fix. Please try this one instead. It fixes an issue with the commit mentioned, so it might fix this one as well. -- You are receiving this mail because: You are watching the assignee of the bug.
[RFC V2 0/3] drm/bridge: panel and chaining
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda wrote: > On 05/09/2014 05:05 PM, Ajay kumar wrote: >> On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote: >>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda >>> wrote: On 05/08/2014 08:24 PM, Rob Clark wrote: > On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda > wrote: >> On 05/05/2014 09:52 PM, Ajay Kumar wrote: >>> This patchset is based on exynos-drm-next-todo branch of Inki Dae's >>> tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> I have just put up Rob's and Sean's idea of chaining up the bridges >>> in code, and have implemented basic panel controls as a chained bridge. >>> This works well with ptn3460 bridge chip on exynos5250-snow board. >>> >>> Still need to make use of standard list calls and figure out proper way >>> of deleting the bridge chain. So, this is just a rough version. >> As I understand this patchset tries to solve two things: >> 1. Implement panel as drm_bridge, to ease support for hardware chains: >> Crtc -> Encoder -> Bridge -> Panel >> 2. Add support to drm_bridge chaining, to allow software chains: >> drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel >> >> It is done using Russian doll schema, ops from the bridge calls the same >> ops from the next bridge and the next bridge ops can do the same. >> >> This schema means that all the bridges including the last one are seen >> from the drm core point of view as a one big drm_bridge. Additionally in >> this particular case, the first bridge (ptn3460) implements connector >> so it is hard to guess what is the location of the 2nd bridge in video >> stream chain, sometimes it is after the connector, sometimes before. >> All this is quite confusing. >> >> But if you look at the bridge from upstream video interface point of >> view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its >> video input side acts as a panel. On the output side it expects a panel, >> lvds panel in this case. > tbh, this is mostly about what we call it. Perhaps "bridge" isn't the > best name.. I wouldn't object to changing it. > > But my thinking was to leave in drm_panel_funcs things that are just > needed by the connector (get_modes().. and maybe some day we need > detect/etc). Then leave everything else in drm_bridge_funcs. A panel > could (if needed) implement both interfaces. > > That is basically the same as what you are proposing, but without > renaming bridge to panel ;-) Good to hear that. However there are points which are not clear for me. But first lets clarify names, I will use panel and bridge words to describe the hardware, and drm_panel, drm_bridge to describe the software interfaces. What bothers me: 1. You want to leave connector related callbacks in drm_panel and the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460 must implement connector internally because of this limitation. I guess it is quite typical bridge. This problem does not exists in case of using drm_panel for ptn3460. 2. drm_bridge is attached to the encoder, this and the callback order suggests the video data flow should be as below: drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel] ptn3460 implements drm_bridge and drm_connector so it suggests its drm_bridge should be the last one, so there should be no place to add lvds panel implemented as a drm_bridge after it, as it is done in this patchset. Additionally it clearly shows that there should be two categories of drm_bridges - non-terminal and terminal. 3. drm_dev uses all-or-nothing approach, ie. it will start only when all its components are up. It simplifies synchronization but is quite fragile - the whole drm will be down due to error in some of its components. For this reason I prefer drm_panel as it is not real drm component it can be attached/detached to/from drm_connector anytime. I am not really sure but drm_bridge does not allow for that. >>> So I do think we need to stick to this all-or-nothing approach for >>> anything that is visible to userspace >>> (drm_{plane,crtc,encoder,connector}). We don't currently have a way >>> to "hotplug" those so I don't see a real smooth upgrade path to add >>> that in a backwards compatible way that won't cause problems with old >>> userspace. >>> >>> But, that said, we have more flexibility with things not visible to >>> userspace (drm_{panel,bridge}). I'm not sure how much we want to >>> allow things to be completely dynamic (we already have some hard >>> enough locking fun). But proposals/rfcs/etc welcome. >>> >>> I guess I'm not completely familiar w/ ptn3460, but the fact that it >>> needs to impleme
[RFC][PATCH] drm/radeon/hdmi: use separated file for DCE 3.1+ hw
On Mon, May 12, 2014 at 9:54 AM, Rafa? Mi?ecki wrote: > DCE 3.1 and 3.2 have different HDMI registers and should be programmed > in a slightly different way. Moving support to separated file will > allow use to use rv770d.h header in the future and adjust code as well. Any reason not to split it at DCE3.2 rather than 3.1? It seems like most (all?) of the changes are DCE3.2 specific rather than DCE3.1. Otherwise, seems fine to me. Alex > --- > drivers/gpu/drm/radeon/Makefile | 2 +- > drivers/gpu/drm/radeon/dce3_1_afmt.c | 221 > +++ > drivers/gpu/drm/radeon/r600_hdmi.c | 130 + > drivers/gpu/drm/radeon/radeon_asic.c | 2 +- > drivers/gpu/drm/radeon/radeon_asic.h | 7 ++ > 5 files changed, 235 insertions(+), 127 deletions(-) > create mode 100644 drivers/gpu/drm/radeon/dce3_1_afmt.c > > diff --git a/drivers/gpu/drm/radeon/Makefile b/drivers/gpu/drm/radeon/Makefile > index 0943353..dbcbfe8 100644 > --- a/drivers/gpu/drm/radeon/Makefile > +++ b/drivers/gpu/drm/radeon/Makefile > @@ -72,7 +72,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \ > radeon_cs.o radeon_bios.o radeon_benchmark.o r100.o r300.o r420.o \ > rs400.o rs600.o rs690.o rv515.o r520.o r600.o rv770.o radeon_test.o \ > r200.o radeon_legacy_tv.o r600_cs.o r600_blit_shaders.o \ > - radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o \ > + radeon_pm.o atombios_dp.o r600_audio.o r600_hdmi.o dce3_1_afmt.o \ > evergreen.o evergreen_cs.o evergreen_blit_shaders.o \ > evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \ > atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o > si.o \ > diff --git a/drivers/gpu/drm/radeon/dce3_1_afmt.c > b/drivers/gpu/drm/radeon/dce3_1_afmt.c > new file mode 100644 > index 000..4e3a8b7 > --- /dev/null > +++ b/drivers/gpu/drm/radeon/dce3_1_afmt.c > @@ -0,0 +1,221 @@ > +#include > +#include "radeon.h" > +#include "radeon_asic.h" > +#include "r600d.h" > + > +static void dce3_2_afmt_write_speaker_allocation(struct drm_encoder *encoder) > +{ > + struct radeon_device *rdev = encoder->dev->dev_private; > + struct drm_connector *connector; > + struct radeon_connector *radeon_connector = NULL; > + u32 tmp; > + u8 *sadb; > + int sad_count; > + > + list_for_each_entry(connector, > &encoder->dev->mode_config.connector_list, head) { > + if (connector->encoder == encoder) { > + radeon_connector = to_radeon_connector(connector); > + break; > + } > + } > + > + if (!radeon_connector) { > + DRM_ERROR("Couldn't find encoder's connector\n"); > + return; > + } > + > + sad_count = drm_edid_to_speaker_allocation(radeon_connector->edid, > &sadb); > + if (sad_count < 0) { > + DRM_ERROR("Couldn't read Speaker Allocation Data Block: > %d\n", sad_count); > + return; > + } > + > + /* program the speaker allocation */ > + tmp = RREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER); > + tmp &= ~(DP_CONNECTION | SPEAKER_ALLOCATION_MASK); > + /* set HDMI mode */ > + tmp |= HDMI_CONNECTION; > + if (sad_count) > + tmp |= SPEAKER_ALLOCATION(sadb[0]); > + else > + tmp |= SPEAKER_ALLOCATION(5); /* stereo */ > + WREG32(AZ_F0_CODEC_PIN0_CONTROL_CHANNEL_SPEAKER, tmp); > + > + kfree(sadb); > +} > + > +static void dce3_2_afmt_write_sad_regs(struct drm_encoder *encoder) > +{ > + struct radeon_device *rdev = encoder->dev->dev_private; > + struct drm_connector *connector; > + struct radeon_connector *radeon_connector = NULL; > + struct cea_sad *sads; > + int i, sad_count; > + > + static const u16 eld_reg_to_type[][2] = { > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR0, > HDMI_AUDIO_CODING_TYPE_PCM }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR1, > HDMI_AUDIO_CODING_TYPE_AC3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR2, > HDMI_AUDIO_CODING_TYPE_MPEG1 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR3, > HDMI_AUDIO_CODING_TYPE_MP3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR4, > HDMI_AUDIO_CODING_TYPE_MPEG2 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR5, > HDMI_AUDIO_CODING_TYPE_AAC_LC }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR6, > HDMI_AUDIO_CODING_TYPE_DTS }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR7, > HDMI_AUDIO_CODING_TYPE_ATRAC }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR9, > HDMI_AUDIO_CODING_TYPE_EAC3 }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR10, > HDMI_AUDIO_CODING_TYPE_DTS_HD }, > + { AZ_F0_CODEC_PIN0_CONTROL_AUDIO_DESCRIPTOR11, > HDMI_AUDIO_CODING_TYPE_MLP
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
I support approach using docbook to start since there are not lot of properties. Laurent has ack'ed this one. Can we go ahead with this? http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html Adding description of new property is not very complex (assuming table format is understood and being comfortable with HTML row/table manipulation). Adding description of each property in their source might be time consuming task. thanks, Sagar On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote: > On Sat, May 10, 2014 at 6:39 AM, Ville Syrj?l? > wrote: > > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote: > >> Hi Sagar, > >> > >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote: > >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote: > >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote: > >> > > > On Wed, Mar 5, 2014 at 11:56 AM, > >> > > > wrote: > >> > > > > + > >> > > > > + > >> > > > > + > >> > > > > +Owner Module/Drivers > >> > > > > +Group > >> > > > > +Property Object > >> > > > > +Property Name > >> > > > > +Type > >> > > > > +Property Values > >> > > > > +Object attached > >> > > > > +Description > >> > > > > + > >> > > > > >> > > > In my opinion this is a horrible way to write property documentations > >> > > > - explicitly constructing html tables is error prone and really hard > >> > > > to read in the source. Imo docbook in general is rather horrible, > >> > > > which is way I write almost all my docs as kerneldoc ;-) > >> > > > > >> > > > I think a simple asciidoc/markdown would be much simpler, with a bit > >> > > > of free-form structure to group properties into relevant groups. > >> > > > Long-term we might even need to split it up into different spec files > >> > > > to keep a good overview. > >> > > > >> > > Docbook is indeed hard to read and write when it comes to such tables. > >> > > However I like having the properties documented in the DRM core > >> > > documentation. Maybe we could come up with a simpler text format that > >> > > would be transformed into docbook when compiling the documentation ? > >> > > >> > Does this mean we need to create comment block with "Doc: drm > >> > properties" style section in each driver where drm properties are > >> > instantiated. And then in drm.tmpl collect all these using !P escape > >> > sequence? > >> > How do create table out of these across all drivers? > >> > >> I don't have a strong preference here. Documenting properties in source > >> code > >> comments would be fine, so would an external central documentation file in > >> a > >> non Docbook format. For the record I'm personally fine with using Docbook > >> as > >> in this patch :-) > >> > >> If we decide to go for property documentation inside the source code then I > >> believe we'll have to create our own format, as creating a properties table > >> from kerneldoc information extracted from comments is probably not > >> possible. > > > > Can comeone pick up the ball here and figure out what needs to be done? > > > > The reason why I want a central place for the documentation is to force > > people to collaborate outside their own sandbox when adding properties. > > Whether that's docbook or some text file I don't care so much at this > > point. The fact that it's a central place should mandate that the > > patches changing it will go through dri-devel and so everyone should se > > them, and when adding new properties it would make the patch author more > > likely to look around a bit before adding another slighty incompatible > > version of the same property. If someone has a better suggestion how to > > encforce this I'm all ears. > > > > Of course this idea can still fail if our esteemed maintainer merges > > stuff without checking for violations of this policy. Dave, any thoughts > > on the subject? > > > > Either way I can tell you that I'm not very enthusiastic about reviewing > > any property patches until some kind of decision about this is reached, > > be it "docbook", "text", "plan c", or "fuck it, let the world burn!". > > any of the first three options would be vastly superior to what we do now > > tbh, I'd suggest imposing a no-new-properties-without-docs rule even > if we haven't finished bikeshedding about the docs format. That might > motivate someone to hurry up and just pick one. > > We can change the format, figure out some way to get it into docbook, > etc, later.. it's not such a huge volume of words we have to type here > that we can't reformat it later. > > BR, > -R > > > > > > -- > > Ville Syrj?l? > > Intel OTC > > ___ > > dri-devel mailing list > > dri-devel at lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/radeon: fix page directory update size estimation
On Mon, May 12, 2014 at 9:30 AM, Christian K?nig wrote: > From: Christian K?nig > > Take padding into account as well. > > Fixes: https://bugzilla.kernel.org/show_bug.cgi?id=75651 > > Signed-off-by: Christian K?nig For the series: Reviewed-by: Alex Deucher > --- > drivers/gpu/drm/radeon/radeon_vm.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/radeon/radeon_vm.c > b/drivers/gpu/drm/radeon/radeon_vm.c > index 2aae6ce..d9ab99f 100644 > --- a/drivers/gpu/drm/radeon/radeon_vm.c > +++ b/drivers/gpu/drm/radeon/radeon_vm.c > @@ -595,7 +595,7 @@ int radeon_vm_update_page_directory(struct radeon_device > *rdev, > ndw = 64; > > /* assume the worst case */ > - ndw += vm->max_pde_used * 12; > + ndw += vm->max_pde_used * 16; > > /* update too big for an IB */ > if (ndw > 0xf) > -- > 1.9.1 > > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On 05/12/2014 08:54 AM, Daniel Vetter wrote: > On Mon, May 12, 2014 at 08:23:45AM -0700, Randy Dunlap wrote: >> On 05/12/2014 01:58 AM, Daniel Vetter wrote: >>> On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: >> >> If we decide to go for property documentation inside the source code >> then I >> believe we'll have to create our own format, as creating a properties >> table >> from kerneldoc information extracted from comments is probably not >> possible. > > Can comeone pick up the ball here and figure out what needs to be done? > > The reason why I want a central place for the documentation is to force > people to collaborate outside their own sandbox when adding properties. > Whether that's docbook or some text file I don't care so much at this > point. The fact that it's a central place should mandate that the > patches changing it will go through dri-devel and so everyone should se > them, and when adding new properties it would make the patch author more > likely to look around a bit before adding another slighty incompatible > version of the same property. If someone has a better suggestion how to > encforce this I'm all ears. > > Of course this idea can still fail if our esteemed maintainer merges > stuff without checking for violations of this policy. Dave, any thoughts > on the subject? Yeah I'm happy to block merging stuff, if we can spot new properties when stuff is posted on dri-devel, so much the better, most drivers still send everything via dri-devel anyways, its only really Intel I have to worry about so far, >>> >>> I'll enforce that all prop stuff gets cc: dri-devel and that it has >>> updates for the prop docs. >>> But we should definitely add it to the new driver review checklist as well. I'm also on the side of this patch is ugly and makes my eyes burn, please please get a plan to use something else ASAP, I'm willing to merge this but I'm tempted to give it a lifetime of a kernel or two before I burn it. >>> >>> Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe >>> find someone to do it for me internally ;-) >>> -Daniel >>> >> >> I certainly have no objections to making kerneldoc suck less. >> There was already an attempt to use asciidoc (like git uses) for kernel-doc >> (a few years ago, by Sam Ravnborg). I support(ed) that effort. > > Hm, do you have pointers to those? My google-fu seems lacking ... I googled for /kernel doc asciidoc ravnborg/ and found several hits for them. > Ok, let's move this to the top and start discussions. The past few months > I've written piles of kerneldoc comments for the DRM DocBook (all pulled > in as kerneldoc, docbook .tmpl has just the chapter structure). DOC: > sections are really useful to pull all the actual documentation out of the > docbook xml into kerneldoc. > > But I've also done piles of docs for intel-gpu-tools, which is using > gtkdoc. And there are some clear deficiencies: > > - No markdown for inline coments. Lack of lists and tables is hurting > especially badly. If we add this (and I don't care one iota whether it's Yes, I've tried to add lists to kernel-doc notation but have failed so far. > markdown or asciidoc or something else as long as it's readable plain > text in comments) we should be able to move all the existing docbook xml > paragraphs/lists/tables into kerneldoc comments. > > - Automatic cross-referencing of functions. If you place e.g. function() > or #struct anywhere in a documentation comment gtk-doc automatically > inserts a hyperlink to the relevant documentation page across the entire > project. Really powerful and makes overview sections much more useful > entry points for beginners since they can easily jump back&forth > betweeen the high-level overview and low-level per-function > documentation. > That's a nice-to-have IMO, but a really nice one. > - In a really perfect world it would help if kerneldoc could collect > structure member kerneldoc from per-member comments. Especially for > large structures with lots of comments this would bring the kerneldoc > and struct member much closer together. > > So that's my wishlist. > >> OTOH, I would only want to add another way to do kernel-doc if it can be a >> full replacement for all of our docbook usage, i.e., it should provide a >> way that we can eliminate docbook and stop using it completely. > > Hm, I don't mind docbook at all, as long as all the real content is > embedded into source files as kerneldoc and the docbook template just > pulls in all the right bits and pieces. Even gtkdoc allos you to do that > and pull in the different libararies (== header files with declarations > for C) in the order you want. So imo the docbook toolchain is good enough > for my needs. > > Or what do you mean by getting rid of all docbook usage? I
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: > >> > >> If we decide to go for property documentation inside the source code then I > >> believe we'll have to create our own format, as creating a properties table > >> from kerneldoc information extracted from comments is probably not > >> possible. > > > > Can comeone pick up the ball here and figure out what needs to be done? > > > > The reason why I want a central place for the documentation is to force > > people to collaborate outside their own sandbox when adding properties. > > Whether that's docbook or some text file I don't care so much at this > > point. The fact that it's a central place should mandate that the > > patches changing it will go through dri-devel and so everyone should se > > them, and when adding new properties it would make the patch author more > > likely to look around a bit before adding another slighty incompatible > > version of the same property. If someone has a better suggestion how to > > encforce this I'm all ears. > > > > Of course this idea can still fail if our esteemed maintainer merges > > stuff without checking for violations of this policy. Dave, any thoughts > > on the subject? > > Yeah I'm happy to block merging stuff, if we can spot new properties > when stuff is posted on dri-devel, so much the better, > > most drivers still send everything via dri-devel anyways, its only > really Intel I have to worry about so far, I'll enforce that all prop stuff gets cc: dri-devel and that it has updates for the prop docs. > But we should definitely add it to the new driver review checklist as well. > > I'm also on the side of this patch is ugly and makes my eyes burn, > please please get a plan to use something else ASAP, I'm willing to > merge this but I'm tempted to give it a lifetime of a kernel or two > before I burn it. Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe find someone to do it for me internally ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 66281] DRI_PRIME=1 glxinfo crashes and causes session to restart
https://bugzilla.kernel.org/show_bug.cgi?id=66281 --- Comment #7 from Ilia Mirkin --- (In reply to Gaurav Shukla from comment #6) > (In reply to Ilia Mirkin from comment #5) > > (In reply to Gaurav Shukla from comment #4) > > > (c) How do I check that runtime pm and vga switcheroo are enabled in my > > > kernel. (Sorry, but I am a newbie to Linux). > > > > If you have your .config (which, depending on options, may be visible from > > /proc/config.gz), you can look for > > > > CONFIG_VGA_SWITCHEROO > > CONFIG_PM_RUNTIME > > > > Make sure both of those are set to 'y'. (This is only for optimus-type > > systems, of which I'm assuming yours is one.) > > > > There is no config.gz file in my system. I have tried using "locate" as > well. Is there some other way I can find this out. http://nouveau.freedesktop.org/wiki/Optimus/ Check /sys/kernel/debug/vgaswitcheroo/switch /sys/class/drm/card1/power/runtime_status If both files are there, that means that you have both of those options. Further you can check dmesg for references to 'optimus'. > > > > > xf86-video-nouveau is the xorg ddx which interacts with the kernel driver. > > In some distros, for maximal confusion, it is called something else, like > > xorg-xserver-video-nouveau or something like that (don't have the exact > > name, sorry). > > Can you please tell me how to find out (or search) if this is the case. Even > if you can tell me where and how to look for, I will follow. A quick way to find out the version of xf86-video-nouveau is to look in your Xorg.0.log file (often located in /var/log). There should be a section like [ 7.016] (II) Loading /usr/lib64/xorg/modules/drivers/nouveau_drv.so [ 7.019] (II) Module nouveau: vendor="X.Org Foundation" [ 7.019]compiled for 1.15.0, module version = 1.0.10 [ 7.019]Module class: X.Org Video Driver [ 7.019]ABI class: X.Org Video Driver, version 15.0 Note the "module version". Make sure yours is 1.0.10. Earlier versions did not support GK208. > > > > > Actually I am working on some OpenGL/GLSL projects, for which I need GLSL > > > 4.3, which I believe is still not available in nouveau driver. I was > > > looking > > > forward to be able to install the latest NVIDIA drivers. Will mesa > > > 10,2-rcl > > > solve this issue? Can you please recommend any other solution. > > The latest mesa based DRI drivers through yum is listed as 10.1.1. Will it > work? A large number of shader opcode generation issues for GK110/GK208 are fixed in the 10.2 release. 10.1.x will work enough for like glxgears though. The final 10.2 release should be out on May 30 or so, dunno how long it takes to get into distros though. -- You are receiving this mail because: You are watching the assignee of the bug.
[Intel-gfx] Design review request: DRM color manager
Re-adding dri-devel, all drm core stuff must be discussed there. But on the actual issue at hand I still don't understand what you're trying to solve. You add a complete new set of properties, using Intel names (pipes, planes) for some attributes which at first seems completely redundant to all the properties we already have. What's the technical reasons for adding this interface? Your proposal is only describing how it works, so is lacking this crucial information. -Daniel On Wed, May 7, 2014 at 4:22 PM, Sharma, Shashank wrote: > Hello all, > > As per previous discussions, I am sending the drm-color-manager design for > review, as inline text. Please have a look and let me know your feedback. > > (I tried hard to align the inline text diagram in mail, hope you can see the > proper picture too) > > = > DRM Color Manager > = > > - Color manager provides a common interface for all color correction / > enhancement properties supported by various hardwares. > - Color manager will be one Umbrella DRM property (blob type) > - Driver can register the color correction properties of its HW during > the init time, and all the corrections can be applied using the same > interface. > > How does a driver register color properties with DRM color manager: > --- > > - A DRM driver will call drm_register_color_manager() function with > following information: > .prop_set_handler > .prop_get_hanlder > .color_prop_identifier structure > {porp_name, prop_id} > {porp_name, prop_id} > {porp_name, prop_id} > > For example: I915 driver can register as: > .prop_set_handler = intel_clrmgr_set() > .prop_get_hanlder = intel_clrmgr_get() > .color_prop_identifier structure > {gamma_correction, 0} > {csc_correction, 1} > {hue_saturation, 2} > > > > How will color_manager_set/get() functions work: > - > > Color EDID: > == > || property || Enable/ || Pipe/Plane/ || No of|| > || ID || Disable || Identifier || Data bytes ||data.. > || <1 Byte> || <1 Byte> || <1 Byte> || <1 Byte> || > == > > - Color EDID is a protocol to extract the color correction > characterictics from a blob, coming from DRM layer > as property_set_blob() or loading a blob for property_get_blob() > > - Userspace will load this blob with corresponding values and use the > drm_set_blob(color-manager) interface. > - DRM layer of get/set_color_manager() will validate the entry, extract > the following information from blob > - property > - enable/disable > - identifier > - ptr to start of raw data > - With this information, drm_get/set_color_manager() layer will call > driver's .get/set_handler() > which will do the correction using those values. > - Based on the driver's requirement, user space can send any type of > values in byte stream, like > direct reg values, correction coefficients or any other form of data. > > Benefits of this common interface: > -- > - Single interface for all color properties. No need to create multiple > properties. > - HW agonist. Its in hands of driver to register the properties. > - Any no of properties can be registered. > - Can be clubbed with modeset implementations. > > > > > Regards > Shashank > > On 5/7/2014 7:41 PM, Sharma, Shashank wrote: >> >> FYI >> >> >> -Original Message- >> From: Sharma, Shashank >> Sent: Tuesday, April 22, 2014 8:32 PM >> To: Daniel Vetter >> Cc: David Herrmann; intel-gfx at lists.freedesktop.org; Cn, Ramakrishnan; >> Jindal, Sonika; Shankar, Uma >> Subject: RE: [Intel-gfx] Design review request: DRM color manager >> >> David, >> My apologies for starting a pre-mature design discussion. >> >> Daniel, >> Thanks for pointing out first two things, It was not known to me, I will >> take care of this in future. >> >> First time I presented color-manager design, in internal display design >> forum, where most of the reviewers were not there. >> We took the feedback from people who were present, and implemented the >> design. >> >> When we shared color manager implementation, that design was rejected and >> one of the feedbacks was that it would be better to discuss it on dri-devel >> where people outside Intel can give their opinion, and that?s the only >> reason why I added dri-devel for the new design (Please see the attached >> mail, I replied to all who were in last communication). >> Please let me know how do we want to proceed now. >> >> >> Regards >> Shashank >> -Original Message- >> From: Daniel Vetter [mailto:daniel.vetter at ffwll.ch
[PATCH 1/2] drm/ast: Fix double lock at PM resume
On Fri, May 09, 2014 at 08:14:14AM +0200, Takashi Iwai wrote: > The recent commit [3ea87855: drm/helper: lock all around force mode > restore] introduced drm_modeset_lock_all() in > drm_helper_resume_force_mode() itself, while ast driver still takes > this lock before calling it. Remove the caller side lock for avoid a > fatal deadlock. > > Signed-off-by: Takashi Iwai Oops, failed to do the audit correctly. Thanks for catching this. Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/ast/ast_drv.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/ast/ast_drv.c b/drivers/gpu/drm/ast/ast_drv.c > index 5137f15dba19..27e56dda476d 100644 > --- a/drivers/gpu/drm/ast/ast_drv.c > +++ b/drivers/gpu/drm/ast/ast_drv.c > @@ -94,9 +94,7 @@ static int ast_drm_thaw(struct drm_device *dev) > ast_post_gpu(dev); > > drm_mode_config_reset(dev); > - drm_modeset_lock_all(dev); > drm_helper_resume_force_mode(dev); > - drm_modeset_unlock_all(dev); > > console_lock(); > ast_fbdev_set_suspend(dev, 0); > -- > 1.9.2 > -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On Mon, May 12, 2014 at 11:37:53AM +0530, Sagar Arun Kamble wrote: > I support approach using docbook to start since there are not lot of > properties. Laurent has ack'ed this one. Can we go ahead with this? > http://lists.freedesktop.org/archives/intel-gfx/2014-March/041527.html > > Adding description of new property is not very complex (assuming table > format is understood and being comfortable with HTML row/table > manipulation). > > Adding description of each property in their source might be time > consuming task. Yeah I'm ok with docbook for the time being. My long-term plan is to fix up kerneldoc to support markdown and then we can move such neat tables into the code. There's lots other places that would benefit from proper list formatting and tables. So Ack from my side on both the docbook patch and the no-more-props-without-doc-patch rule (which is kinda what I've been doing thus far). -Daniel > > thanks, > Sagar > > > On Sat, 2014-05-10 at 06:56 -0400, Rob Clark wrote: > > On Sat, May 10, 2014 at 6:39 AM, Ville Syrj?l? > > wrote: > > > On Wed, Mar 12, 2014 at 12:25:06PM +0100, Laurent Pinchart wrote: > > >> Hi Sagar, > > >> > > >> On Wednesday 12 March 2014 16:46:05 Sagar Arun Kamble wrote: > > >> > On Mon, 2014-03-10 at 15:36 +0100, Laurent Pinchart wrote: > > >> > > On Monday 10 March 2014 06:21:49 Daniel Vetter wrote: > > >> > > > On Wed, Mar 5, 2014 at 11:56 AM, > > >> > > > wrote: > > >> > > > > + > > >> > > > > + > > >> > > > > + > > >> > > > > +Owner Module/Drivers > > >> > > > > +Group > > >> > > > > +Property Object > > >> > > > > +Property Name > > >> > > > > +Type > > >> > > > > +Property Values > > >> > > > > +Object attached > > >> > > > > +Description > > >> > > > > + > > >> > > > > > >> > > > In my opinion this is a horrible way to write property > > >> > > > documentations > > >> > > > - explicitly constructing html tables is error prone and really > > >> > > > hard > > >> > > > to read in the source. Imo docbook in general is rather horrible, > > >> > > > which is way I write almost all my docs as kerneldoc ;-) > > >> > > > > > >> > > > I think a simple asciidoc/markdown would be much simpler, with a > > >> > > > bit > > >> > > > of free-form structure to group properties into relevant groups. > > >> > > > Long-term we might even need to split it up into different spec > > >> > > > files > > >> > > > to keep a good overview. > > >> > > > > >> > > Docbook is indeed hard to read and write when it comes to such > > >> > > tables. > > >> > > However I like having the properties documented in the DRM core > > >> > > documentation. Maybe we could come up with a simpler text format that > > >> > > would be transformed into docbook when compiling the documentation ? > > >> > > > >> > Does this mean we need to create comment block with "Doc: drm > > >> > properties" style section in each driver where drm properties are > > >> > instantiated. And then in drm.tmpl collect all these using !P escape > > >> > sequence? > > >> > How do create table out of these across all drivers? > > >> > > >> I don't have a strong preference here. Documenting properties in source > > >> code > > >> comments would be fine, so would an external central documentation file > > >> in a > > >> non Docbook format. For the record I'm personally fine with using > > >> Docbook as > > >> in this patch :-) > > >> > > >> If we decide to go for property documentation inside the source code > > >> then I > > >> believe we'll have to create our own format, as creating a properties > > >> table > > >> from kerneldoc information extracted from comments is probably not > > >> possible. > > > > > > Can comeone pick up the ball here and figure out what needs to be done? > > > > > > The reason why I want a central place for the documentation is to force > > > people to collaborate outside their own sandbox when adding properties. > > > Whether that's docbook or some text file I don't care so much at this > > > point. The fact that it's a central place should mandate that the > > > patches changing it will go through dri-devel and so everyone should se > > > them, and when adding new properties it would make the patch author more > > > likely to look around a bit before adding another slighty incompatible > > > version of the same property. If someone has a better suggestion how to > > > encforce this I'm all ears. > > > > > > Of course this idea can still fail if our esteemed maintainer merges > > > stuff without checking for violations of this policy. Dave, any thoughts > > > on the subject? > > > > > > Either way I can tell you that I'm not very enthusiastic about reviewing > > > any property patches until some kind of decision about this is reached, > > > be it "docbook", "text", "plan c", or "fuck it, let the world burn!". > > > > any of the first three options would be vastly superior to what we do now > > > > tbh, I'd suggest imposing a no-new-properties-without-docs rule even > > if we haven't finis
[PATCH v2] nouveau: Don't check acpi_video_backlight_support() before registering backlight
Hi, On 05/12/2014 09:32 AM, Hans de Goede wrote: > acpi_video_backlight_support() is supposed to be called by other (vendor > specific) firmware backlight controls, not by native / raw backlight controls > like nv_backlight. > > Userspace will normally prefer firmware interfaces over raw interfaces, so > if acpi_video backlight support is present it will use that even if > nv_backlight is registered as well. > > Except when video.use_native_backlight is present on the kernel cmdline > (or enabled through a dmi based quirk). As the name indicates the goal here > is to make only the raw interface available to userspace so that it will use > that (it only does this when it sees a win8 compliant bios). > > This is done by: > 1) Not registering any acpi_video# backlight devices; and > 2) Making acpi_video_backlight_support() return true so that other firmware > drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their > own vender specific interfaces. > > Currently nouveau breaks this setup, as when acpi_video_backlight_support() > returns true, it does not register itself, resulting in no backlight control > at all. > > This is esp. going to be a problem with 3.16 which will default to > video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios > will get no backlight control at all. > > This also likely explains why the previous attempt to make > video.use_native_backlight=1 the default was not a success, as without this > patch having a default of video.use_native_backlight=1 will cause regressions. > > Note this effectively reverts commit 5bead799 > > Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171 > > Signed-off-by: Hans de Goede Ignore the v2 in the subject please it is bogus. Question should this also go to stable ? I guess that for old / broken userspace it may lead to userspace doing the wrong thing in some cases. So that goes against adding it to stable. OTOH the intel driver has been always registering its native backlight interface for ages, so userspace should know better; and this fix is needed (together with a quirk to set video.use_native_backlight=1 by default), to get the backlight control to work on the ThinkPad W530. Regards, Hans
[PATCH v2] nouveau: Don't check acpi_video_backlight_support() before registering backlight
acpi_video_backlight_support() is supposed to be called by other (vendor specific) firmware backlight controls, not by native / raw backlight controls like nv_backlight. Userspace will normally prefer firmware interfaces over raw interfaces, so if acpi_video backlight support is present it will use that even if nv_backlight is registered as well. Except when video.use_native_backlight is present on the kernel cmdline (or enabled through a dmi based quirk). As the name indicates the goal here is to make only the raw interface available to userspace so that it will use that (it only does this when it sees a win8 compliant bios). This is done by: 1) Not registering any acpi_video# backlight devices; and 2) Making acpi_video_backlight_support() return true so that other firmware drivers, ie acer_wmi, thinkpad_acpi, dell_laptop, etc. Don't register their own vender specific interfaces. Currently nouveau breaks this setup, as when acpi_video_backlight_support() returns true, it does not register itself, resulting in no backlight control at all. This is esp. going to be a problem with 3.16 which will default to video.use_native_backlight=1, and thus nouveau based laptops with a win8 bios will get no backlight control at all. This also likely explains why the previous attempt to make video.use_native_backlight=1 the default was not a success, as without this patch having a default of video.use_native_backlight=1 will cause regressions. Note this effectively reverts commit 5bead799 Also see: https://bugzilla.redhat.com/show_bug.cgi?id=1093171 Signed-off-by: Hans de Goede --- drivers/gpu/drm/nouveau/nouveau_backlight.c | 9 - 1 file changed, 9 deletions(-) diff --git a/drivers/gpu/drm/nouveau/nouveau_backlight.c b/drivers/gpu/drm/nouveau/nouveau_backlight.c index 630f6e8..2c1e4aa 100644 --- a/drivers/gpu/drm/nouveau/nouveau_backlight.c +++ b/drivers/gpu/drm/nouveau/nouveau_backlight.c @@ -31,7 +31,6 @@ */ #include -#include #include "nouveau_drm.h" #include "nouveau_reg.h" @@ -222,14 +221,6 @@ nouveau_backlight_init(struct drm_device *dev) struct nouveau_device *device = nv_device(drm->device); struct drm_connector *connector; -#ifdef CONFIG_ACPI - if (acpi_video_backlight_support()) { - NV_INFO(drm, "ACPI backlight interface available, " -"not registering our own\n"); - return 0; - } -#endif - list_for_each_entry(connector, &dev->mode_config.connector_list, head) { if (connector->connector_type != DRM_MODE_CONNECTOR_LVDS && connector->connector_type != DRM_MODE_CONNECTOR_eDP) -- 1.9.0
[RFC V2 0/3] drm/bridge: panel and chaining
On 05/09/2014 05:05 PM, Ajay kumar wrote: > On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote: >> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda wrote: >>> On 05/08/2014 08:24 PM, Rob Clark wrote: On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda wrote: > On 05/05/2014 09:52 PM, Ajay Kumar wrote: >> This patchset is based on exynos-drm-next-todo branch of Inki Dae's tree >> at: >> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >> >> I have just put up Rob's and Sean's idea of chaining up the bridges >> in code, and have implemented basic panel controls as a chained bridge. >> This works well with ptn3460 bridge chip on exynos5250-snow board. >> >> Still need to make use of standard list calls and figure out proper way >> of deleting the bridge chain. So, this is just a rough version. > As I understand this patchset tries to solve two things: > 1. Implement panel as drm_bridge, to ease support for hardware chains: > Crtc -> Encoder -> Bridge -> Panel > 2. Add support to drm_bridge chaining, to allow software chains: > drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel > > It is done using Russian doll schema, ops from the bridge calls the same > ops from the next bridge and the next bridge ops can do the same. > > This schema means that all the bridges including the last one are seen > from the drm core point of view as a one big drm_bridge. Additionally in > this particular case, the first bridge (ptn3460) implements connector > so it is hard to guess what is the location of the 2nd bridge in video > stream chain, sometimes it is after the connector, sometimes before. > All this is quite confusing. > > But if you look at the bridge from upstream video interface point of > view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its > video input side acts as a panel. On the output side it expects a panel, > lvds panel in this case. tbh, this is mostly about what we call it. Perhaps "bridge" isn't the best name.. I wouldn't object to changing it. But my thinking was to leave in drm_panel_funcs things that are just needed by the connector (get_modes().. and maybe some day we need detect/etc). Then leave everything else in drm_bridge_funcs. A panel could (if needed) implement both interfaces. That is basically the same as what you are proposing, but without renaming bridge to panel ;-) >>> Good to hear that. However there are points which are not clear for me. >>> But first lets clarify names, I will use panel and bridge words >>> to describe the hardware, and drm_panel, drm_bridge to describe the >>> software interfaces. >>> >>> What bothers me: >>> 1. You want to leave connector related callbacks in drm_panel and >>> the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460 >>> must implement connector internally because of this limitation. I guess >>> it is quite typical bridge. This problem does not exists in case >>> of using drm_panel for ptn3460. >>> >>> 2. drm_bridge is attached to the encoder, this and the callback order >>> suggests the video data flow should be as below: >>> drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel] >>> >>> ptn3460 implements drm_bridge and drm_connector so it suggests its >>> drm_bridge should be the last one, so there should be no place to add >>> lvds panel implemented as a drm_bridge after it, as it is done in this >>> patchset. >>> >>> Additionally it clearly shows that there should be two categories of >>> drm_bridges - non-terminal and terminal. >>> >>> 3. drm_dev uses all-or-nothing approach, ie. it will start only when all >>> its components are up. It simplifies synchronization but is quite >>> fragile - the whole drm will be down due to error in some of its components. >>> For this reason I prefer drm_panel as it is not real drm component >>> it can be attached/detached to/from drm_connector anytime. I am not >>> really sure but drm_bridge does not allow for that. >> So I do think we need to stick to this all-or-nothing approach for >> anything that is visible to userspace >> (drm_{plane,crtc,encoder,connector}). We don't currently have a way >> to "hotplug" those so I don't see a real smooth upgrade path to add >> that in a backwards compatible way that won't cause problems with old >> userspace. >> >> But, that said, we have more flexibility with things not visible to >> userspace (drm_{panel,bridge}). I'm not sure how much we want to >> allow things to be completely dynamic (we already have some hard >> enough locking fun). But proposals/rfcs/etc welcome. >> >> I guess I'm not completely familiar w/ ptn3460, but the fact that it >> needs to implement drm_connector makes me a bit suspicious. Seems >> like a symptom of missing things in drm_panel_funcs. It would be >> better to always create the connect
[RFC V2 0/3] drm/bridge: panel and chaining
On Mon, May 12, 2014 at 3:06 AM, Andrzej Hajda wrote: > On 05/09/2014 05:05 PM, Ajay kumar wrote: >> On Fri, May 9, 2014 at 7:29 PM, Rob Clark wrote: >>> On Fri, May 9, 2014 at 5:08 AM, Andrzej Hajda >>> wrote: On 05/08/2014 08:24 PM, Rob Clark wrote: > On Thu, May 8, 2014 at 2:41 AM, Andrzej Hajda > wrote: >> On 05/05/2014 09:52 PM, Ajay Kumar wrote: >>> This patchset is based on exynos-drm-next-todo branch of Inki Dae's >>> tree at: >>> git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos.git >>> >>> I have just put up Rob's and Sean's idea of chaining up the bridges >>> in code, and have implemented basic panel controls as a chained bridge. >>> This works well with ptn3460 bridge chip on exynos5250-snow board. >>> >>> Still need to make use of standard list calls and figure out proper way >>> of deleting the bridge chain. So, this is just a rough version. >> As I understand this patchset tries to solve two things: >> 1. Implement panel as drm_bridge, to ease support for hardware chains: >> Crtc -> Encoder -> Bridge -> Panel >> 2. Add support to drm_bridge chaining, to allow software chains: >> drm_crtc -> drm_encoder -> drm_bridge -> drm_bridge,panel >> >> It is done using Russian doll schema, ops from the bridge calls the same >> ops from the next bridge and the next bridge ops can do the same. >> >> This schema means that all the bridges including the last one are seen >> from the drm core point of view as a one big drm_bridge. Additionally in >> this particular case, the first bridge (ptn3460) implements connector >> so it is hard to guess what is the location of the 2nd bridge in video >> stream chain, sometimes it is after the connector, sometimes before. >> All this is quite confusing. >> >> But if you look at the bridge from upstream video interface point of >> view it is just a panel, edp panel in case of ptn3460, ie ptn3460 on its >> video input side acts as a panel. On the output side it expects a panel, >> lvds panel in this case. > tbh, this is mostly about what we call it. Perhaps "bridge" isn't the > best name.. I wouldn't object to changing it. > > But my thinking was to leave in drm_panel_funcs things that are just > needed by the connector (get_modes().. and maybe some day we need > detect/etc). Then leave everything else in drm_bridge_funcs. A panel > could (if needed) implement both interfaces. > > That is basically the same as what you are proposing, but without > renaming bridge to panel ;-) Good to hear that. However there are points which are not clear for me. But first lets clarify names, I will use panel and bridge words to describe the hardware, and drm_panel, drm_bridge to describe the software interfaces. What bothers me: 1. You want to leave connector related callbacks in drm_panel and the rest in drm_bridge. In case of ptn3460 it does not work, ptn3460 must implement connector internally because of this limitation. I guess it is quite typical bridge. This problem does not exists in case of using drm_panel for ptn3460. 2. drm_bridge is attached to the encoder, this and the callback order suggests the video data flow should be as below: drm_crtc -> drm_encoder [-> drm_bridge] -> drm_connector [-> drm_panel] ptn3460 implements drm_bridge and drm_connector so it suggests its drm_bridge should be the last one, so there should be no place to add lvds panel implemented as a drm_bridge after it, as it is done in this patchset. Additionally it clearly shows that there should be two categories of drm_bridges - non-terminal and terminal. 3. drm_dev uses all-or-nothing approach, ie. it will start only when all its components are up. It simplifies synchronization but is quite fragile - the whole drm will be down due to error in some of its components. For this reason I prefer drm_panel as it is not real drm component it can be attached/detached to/from drm_connector anytime. I am not really sure but drm_bridge does not allow for that. >>> So I do think we need to stick to this all-or-nothing approach for >>> anything that is visible to userspace >>> (drm_{plane,crtc,encoder,connector}). We don't currently have a way >>> to "hotplug" those so I don't see a real smooth upgrade path to add >>> that in a backwards compatible way that won't cause problems with old >>> userspace. >>> >>> But, that said, we have more flexibility with things not visible to >>> userspace (drm_{panel,bridge}). I'm not sure how much we want to >>> allow things to be completely dynamic (we already have some hard >>> enough locking fun). But proposals/rfcs/etc welcome. >>> >>> I guess I'm not completely familiar w/ ptn3460, but the fact that it >>> needs to impleme
[Bug 66281] DRI_PRIME=1 glxinfo crashes and causes session to restart
https://bugzilla.kernel.org/show_bug.cgi?id=66281 --- Comment #6 from Gaurav Shukla --- (In reply to Ilia Mirkin from comment #5) > (In reply to Gaurav Shukla from comment #4) > > (c) How do I check that runtime pm and vga switcheroo are enabled in my > > kernel. (Sorry, but I am a newbie to Linux). > > If you have your .config (which, depending on options, may be visible from > /proc/config.gz), you can look for > > CONFIG_VGA_SWITCHEROO > CONFIG_PM_RUNTIME > > Make sure both of those are set to 'y'. (This is only for optimus-type > systems, of which I'm assuming yours is one.) > > > > > (d) I cannot be sure about this as well. AFAIK, the nouveau module is built > > into the kernel. The modinfo result is as below: There is no config.gz file in my system. I have tried using "locate" as well. Is there some other way I can find this out. > > xf86-video-nouveau is the xorg ddx which interacts with the kernel driver. > In some distros, for maximal confusion, it is called something else, like > xorg-xserver-video-nouveau or something like that (don't have the exact > name, sorry). Can you please tell me how to find out (or search) if this is the case. Even if you can tell me where and how to look for, I will follow. > > > Actually I am working on some OpenGL/GLSL projects, for which I need GLSL > > 4.3, which I believe is still not available in nouveau driver. I was looking > > forward to be able to install the latest NVIDIA drivers. Will mesa 10,2-rcl > > solve this issue? Can you please recommend any other solution. The latest mesa based DRI drivers through yum is listed as 10.1.1. Will it work? > > Mesa 10.2 will support a few more extensions which are part of GL4+, but > will not provide all the features required to advertise GL 4.0 support (or > GL 4.3, obviously). You can see the general progress of things at > http://cgit.freedesktop.org/mesa/mesa/tree/docs/GL3.txt. > > However it's rare to need ALL of the features available in GL 4.3, so > chances are you could restrict yourself to a lower, supported version + a > few extensions. > > Also note that GK208, while covered by the nvc0 driver, has en some > extra-special issues that the GK10x cards (and GF1xx cards) don't have. > Hopefully they'll be resolved semi-soon, but the hardware is not easily > available. -- You are receiving this mail because: You are watching the assignee of the bug.
[PATCH 1/1] Documentation: drm: describing drm properties exposed by various drivers
On 05/12/2014 01:58 AM, Daniel Vetter wrote: > On Mon, May 12, 2014 at 06:24:57PM +1000, Dave Airlie wrote: If we decide to go for property documentation inside the source code then I believe we'll have to create our own format, as creating a properties table from kerneldoc information extracted from comments is probably not possible. >>> >>> Can comeone pick up the ball here and figure out what needs to be done? >>> >>> The reason why I want a central place for the documentation is to force >>> people to collaborate outside their own sandbox when adding properties. >>> Whether that's docbook or some text file I don't care so much at this >>> point. The fact that it's a central place should mandate that the >>> patches changing it will go through dri-devel and so everyone should se >>> them, and when adding new properties it would make the patch author more >>> likely to look around a bit before adding another slighty incompatible >>> version of the same property. If someone has a better suggestion how to >>> encforce this I'm all ears. >>> >>> Of course this idea can still fail if our esteemed maintainer merges >>> stuff without checking for violations of this policy. Dave, any thoughts >>> on the subject? >> >> Yeah I'm happy to block merging stuff, if we can spot new properties >> when stuff is posted on dri-devel, so much the better, >> >> most drivers still send everything via dri-devel anyways, its only >> really Intel I have to worry about so far, > > I'll enforce that all prop stuff gets cc: dri-devel and that it has > updates for the prop docs. > >> But we should definitely add it to the new driver review checklist as well. >> >> I'm also on the side of this patch is ugly and makes my eyes burn, >> please please get a plan to use something else ASAP, I'm willing to >> merge this but I'm tempted to give it a lifetime of a kernel or two >> before I burn it. > > Ok, I'll try to move "make kerneldoc suck less" up the task list and maybe > find someone to do it for me internally ;-) > -Daniel > I certainly have no objections to making kerneldoc suck less. There was already an attempt to use asciidoc (like git uses) for kernel-doc (a few years ago, by Sam Ravnborg). I support(ed) that effort. OTOH, I would only want to add another way to do kernel-doc if it can be a full replacement for all of our docbook usage, i.e., it should provide a way that we can eliminate docbook and stop using it completely. thanks, -- ~Randy
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #32 from Christian K?nig --- (In reply to sdh from comment #30) > Hi. Any update on this? I've pushed the workaround upstream. So you should at least have a booting system. Just don't try to use any accelerated video decoding since that would crash the box again. My best guess is that the information in the BIOS about the reference frequency is wrong, but without having the hardware here I can't do much else to get UVD working properly. (In reply to sdh from comment #31) > I just noticed I'm getting the following errors during the sleep and wake up > cycle: > > [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low > [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed > > Kernel is 3.14.2-1-git-dirty with above patch Sounds like an unrelated DPM problem to me, but who knows. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 78453] [HAWAII] Get acceleration working
https://bugs.freedesktop.org/show_bug.cgi?id=78453 --- Comment #12 from Michel D?nzer --- Note that 2D contents use 3D hardware acceleration as well via glamor. For these tests, it might be best to use as little 2D as possible, e.g. just a bare X server without -retro and glxgears, or even something like es2gears without X at all. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140512/5c7d3646/attachment.html>
[Bug 71891] 3.13 fails to boot with the radeon module
https://bugzilla.kernel.org/show_bug.cgi?id=71891 --- Comment #31 from sdh --- I just noticed I'm getting the following errors during the sleep and wake up cycle: [drm:rv730_stop_dpm] *ERROR* Could not force DPM to low [drm:rv770_dpm_set_power_state] *ERROR* rv770_set_sw_state failed Kernel is 3.14.2-1-git-dirty with above patch -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 70569] DOTA2 background and other missing elements on HD4850 GPU
https://bugs.freedesktop.org/show_bug.cgi?id=70569 Roc Vall?s Dom?nech changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Roc Vall?s Dom?nech --- Fixed by not using LLVM, which is the case as of Mesa 10.1.2. -- 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/20140512/401debf6/attachment.html>
[Bug 78366] [r600g] Memory leak desktop usage RV770 (HD4850) with 10.1.2 (related to not using LLVM anymore)
https://bugs.freedesktop.org/show_bug.cgi?id=78366 Roc Vall?s Dom?nech changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |NOTOURBUG --- Comment #2 from Roc Vall?s Dom?nech --- After trying with older mesa/llvm and experimenting around, I've figured out it's not the same thing I used to have. Apparently, memory is recovered by closing Firefox. Top doesn't show it using that much memory, but it somehow does in less traceable ways. Damn firefox 29... I'm seriously considering moving to chromium now. Closing 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/20140512/17279ffe/attachment.html>
[Bug 75112] Meta Bug for HyperZ issues on r600g and radeonsi
https://bugs.freedesktop.org/show_bug.cgi?id=75112 --- Comment #17 from Michel D?nzer --- (In reply to comment #16) > I browsed bug reports and non of them is APU related, so maybe give a shot for > these? Did you test the games referenced in those bug reports? -- 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/20140512/1487537c/attachment.html>
[Bug 78537] no anisotropic filtering in a native Half-Life 2
https://bugs.freedesktop.org/show_bug.cgi?id=78537 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 Component|Driver/Radeon |Drivers/Gallium/radeonsi -- 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/20140512/5af7fcdd/attachment.html>
[PATCH] drm/crtc-helper: skip locking checks in panicking path
Hello! Below is my patch for drm. Here is a photo of kernel output I had: http://s17.postimg.org/k0301hgf3/Untitled.jpg to illustrate what I am writing in the description. --- Subject: [PATCH] drm/crtc-helper: skip locking checks in panicking path Skip locking checks in drm_helper_*_in_use() if they are called in panicking path. See similar code in drm_warn_on_modeset_not_all_locked(). After panic information has been output, these WARN_ONs go off outputing a lot of lines and scrolling the panic information out of the screen. Here is a partial call trace showing how execution reaches them: ? drm_helper_crtc_in_use() ? __drm_helper_disable_unused_functions() ? several *_set_config functions ? drm_fb_helper_restore_fbdev_mode() Cc: Dave Airlie Cc: Daniel Vetter Signed-off-by: Sergei Antonov --- drivers/gpu/drm/drm_crtc_helper.c | 17 +++-- 1 file changed, 15 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/drm_crtc_helper.c b/drivers/gpu/drm/drm_crtc_helper.c index df281b5..872ba11 100644 --- a/drivers/gpu/drm/drm_crtc_helper.c +++ b/drivers/gpu/drm/drm_crtc_helper.c @@ -29,6 +29,7 @@ * Jesse Barnes */ +#include #include #include @@ -88,7 +89,13 @@ bool drm_helper_encoder_in_use(struct drm_encoder *encoder) struct drm_connector *connector; struct drm_device *dev = encoder->dev; - WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); + /* +* We can expect this mutex to be locked if we are not panicking. +* Locking is currently fubar in the panic handler. +*/ + if (!oops_in_progress) + WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); + list_for_each_entry(connector, &dev->mode_config.connector_list, head) if (connector->encoder == encoder) return true; @@ -112,7 +119,13 @@ bool drm_helper_crtc_in_use(struct drm_crtc *crtc) struct drm_encoder *encoder; struct drm_device *dev = crtc->dev; - WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); + /* +* We can expect this mutex to be locked if we are not panicking. +* Locking is currently fubar in the panic handler. +*/ + if (!oops_in_progress) + WARN_ON(!mutex_is_locked(&dev->mode_config.mutex)); + list_for_each_entry(encoder, &dev->mode_config.encoder_list, head) if (encoder->crtc == crtc && drm_helper_encoder_in_use(encoder)) return true; -- 1.9.0