[Bug 93144] [radeonsi] Alien: Isolation bug
https://bugs.freedesktop.org/show_bug.cgi?id=93144 --- Comment #11 from Stepan Bakshaev --- I used page https://www.opengl.org/wiki/Compute_Shader to find out compute shared api calls in opengl. I searched for glDispatchCompute and glDispatchComputeIndirectâwith qapitrace. Both were not located in the apitrace. -- 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/20151213/c32cbf78/attachment.html>
[Bug 93079] Tonga faults and oopses on agd5f drm-fixes-4.4 since fix incorrect mutex usage v3
https://bugs.freedesktop.org/show_bug.cgi?id=93079 Andy Furniss changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Andy Furniss --- Still seems good -- 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/20151213/d4ff10c1/attachment.html>
[Bug 93364] texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096)
https://bugs.freedesktop.org/show_bug.cgi?id=93364 Bug ID: 93364 Summary: texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096) Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel at lists.freedesktop.org Reporter: bjourne at gmail.com QA Contact: dri-devel at lists.freedesktop.org I'm getting the following errors in dmesg: [947174.086041] radeon :01:05.0: alignments 64 1 1 1 [947174.086071] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [947185.227119] radeon :01:05.0: texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096) [947185.227132] radeon :01:05.0: alignments 64 1 1 1 [947185.227197] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [947197.584009] radeon :01:05.0: texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096) [947197.584016] radeon :01:05.0: alignments 64 1 1 1 [947197.584056] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! [947243.179560] radeon :01:05.0: texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096) [947243.179567] radeon :01:05.0: alignments 64 1 1 1 [947243.179605] [drm:radeon_cs_ioctl [radeon]] *ERROR* Invalid command stream ! When tooltips are shown in Chromium, their windows contain garbled and uninitialized pixels. No idea if that is relevant. I'm using Ubuntu 15.10 with KDE. There were other bugs referencing the "texture bo too small" message, but they are all very old or marked fixed so I don't think this bug is a dupe. -- 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/20151213/1e63f0ef/attachment.html>
[Bug 93364] texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096)
https://bugs.freedesktop.org/show_bug.cgi?id=93364 --- Comment #1 from Björn Lindqvist --- 01:05.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] RS880 [Radeon HD 4200] -- 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/20151213/c41631bb/attachment-0001.html>
AMD guys: commit messages?
There are a few useful prerequisites for contributing to Mesa and being efficient: 1) Know OpenGL and GLSL Tutorials: http://ogldev.atspace.co.uk/ You need to know the API one way or another. Eventually, you want to switch to the official OpenGL, GLSL, and extension specifications as your primary source of information. 2) Know the graphics pipeline Articles: https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ I was surprised about how accurately Z/Stencil optimizations were described in part 7. It seems pretty dense. Oh and BTW, it's about DX11, but I see that as an advantage. The hardware documentation uses DX11 naming conventions, so why not just get to use them now. 3) Know the Mesa code base Knowing the code and the overall architecture is 50% of success. This applies to any project. 4) Know the hardware registers and ISA There is open documentation, but it doesn't contain everything. In such case, the code is the documentation. Marek On Tue, Dec 8, 2015 at 2:43 PM, Ernst Sjöstrand wrote: > Hello list! > > I lurk here and try to follow Mesa/DRI and most specifically Radeon > driver development, report bugs, test new stuff and help get the bugs > closed and so on... > > However I see that the commit messages for AMD/Radeon are often very > unhelpful. They don't state the motivation behind the commits. Is this > a optimization, a nice-to-have cleanup or does this actually fix > something? What does this fix? > Are there tests or bugreports related? > > Improving this could make it easier for new developers to start > contributing in the long run also! > > Examples: > > http://cgit.freedesktop.org/mesa/mesa/commit/?id=d5a5dbd71f0e8756494809025ba2119efdf26373 > http://cgit.freedesktop.org/mesa/mesa/commit/?id=338d7bf0531a10d90db75ad333f7e0a31693641f > http://cgit.freedesktop.org/mesa/mesa/commit/?id=4ebcf5194d98b47bd9e8a72b7418054708b14750 > > This is also in the mesa dev guidelines, www.mesa3d.org/devinfo.html : > "Patch fix is not clearly described. For example, a commit message of > only a single line, no description of the bug, no mention of bugzilla, > etc." > > Regards! > //Ernst > ___ > dri-devel mailing list > dri-devel at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 93364] texture bo too small ((899 721) (1 1) 0 26 0 -> 2592716 have 4096)
https://bugs.freedesktop.org/show_bug.cgi?id=93364 Björn Lindqvist changed: What|Removed |Added CC||bjourne at gmail.com --- Comment #2 from Björn Lindqvist --- Created attachment 120487 --> https://bugs.freedesktop.org/attachment.cgi?id=120487&action=edit Showing a graphics bug Please see the bad pixels in the Amarok menu. -- 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/20151213/5508f926/attachment.html>
[Bug 93073] 1002:68a0 After suspend-resume graphics are sluggish and input lags with displayport connected
https://bugs.freedesktop.org/show_bug.cgi?id=93073 Michiel Janssens changed: What|Removed |Added Component|Driver/Radeon |DRM/Radeon Assignee|xorg-driver-ati at lists.x.org |dri-devel at lists.freedesktop ||.org Product|xorg|DRI QA Contact|xorg-team at lists.x.org | -- 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/20151213/94f801d1/attachment.html>
[Bug 93073] [regression bisected] 1002:68a0 After suspend-resume graphics are sluggish and input lags with displayport connected
https://bugs.freedesktop.org/show_bug.cgi?id=93073 Michiel Janssens changed: What|Removed |Added Summary|1002:68a0 After |[regression bisected] |suspend-resume graphics are |1002:68a0 After |sluggish and input lags |suspend-resume graphics are |with displayport connected |sluggish and input lags ||with displayport connected -- 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/20151213/614ee99f/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352
--- Comment #12 from Jürgen Scholz ---
Thanks for the hint. Using the --enable-debug build does not work. Reverting to
the standard packages from the padoka PPA works, when the command line options
for the game in the steam client is set to "LANG=C
LD_PRELOAD="../lib/x86_64/libtcmalloc_minimal.so:${LD_PRELOAD}" %command%"
The caveat is that the game only works, if I turn on the windowed mode and if I
set the resolution to 1920x1080, which is hardly ideal since I have a 3440x1440
monitor.
--
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/20151213/d0c42292/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 sarnex changed: What|Removed |Added CC||commendsarnex at gmail.com --- Comment #3 from sarnex --- Created attachment 120488 --> https://bugs.freedesktop.org/attachment.cgi?id=120488&action=edit R600_DEBUG=vs,gs,ps Hello. I have the exact same issue. The assert in LLVM is llvm::IndexListEntry* llvm::SlotIndex::listEntry() const: Assertion `isValid() && "Attempt to compare reserved index."' failed. I've attached my R600_DEBUG=vs,gs,ps also. I have a HD 7950/Tahiti. I hope this helps. Thanks, sarnex -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151213/3308d336/attachment.html>
[Bug 93352] GRID Autosport crashes on start of race
https://bugs.freedesktop.org/show_bug.cgi?id=93352 --- Comment #13 from Ilia Mirkin --- I've pushed out a fix for the issue that triggers this assertion: GridAutosport: ../../../../src/mesa/state_tracker/st_glsl_to_tgsi.cpp:2342: virtual void glsl_to_tgsi_visitor::visit(ir_dereference_variable*): Assertion `var->data.location != -1' failed. But it sounds like there are additional issues too? I would encourage you to continue using --enable-debug as that is a lot better at identifying problems at their source. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151213/efda6d49/attachment-0001.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 Ilia Mirkin changed: What|Removed |Added Attachment #120484|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151213/1fd1a4bc/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 Ilia Mirkin changed: What|Removed |Added Attachment #120483|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151213/6c638f63/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 Ilia Mirkin changed: What|Removed |Added Attachment #120482|text/plain |application/octet-stream mime type|| -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20151213/891a1261/attachment.html>
[Bug 93353] GRID Autosport crash on loading screen with an HD 6950
https://bugs.freedesktop.org/show_bug.cgi?id=93353 --- Comment #8 from Ilia Mirkin --- The errors relating to r600 indicate it's having trouble converting some TGSI shader. However those don't appear to be printed without --enable-debug. I've pushed out a fix for another assertion, so try a mesa git head build (make sure it includes commit eca8f38dcffb7), with --enable-debug, and run with ST_DEBUG=tgsi -- that should hopefully show which shader r600 is having trouble compiling. -- 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/20151213/71259747/attachment.html>
[Bug 106901] Brightness / WIFI Key does not generate any events
https://bugzilla.kernel.org/show_bug.cgi?id=106901 --- Comment #18 from Roman Gruber --- Linux ASUS-G75VW 4.3.2-gentoo_2015-12-13 #1 SMP Sun Dec 13 18:22:15 CET 2015 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux Same behaviour -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 106901] Brightness / WIFI Key does not generate any events
https://bugzilla.kernel.org/show_bug.cgi?id=106901 Roman Gruber changed: What|Removed |Added Kernel Version|Linux ASUS-G75VW|Linux ASUS-G75VW |4.3.0-gentoo_2015-11-19 #1 |4.3.2-gentoo_2015-12-13 #1 |SMP Thu Nov 19 13:21:56 CET |SMP Sun Dec 13 18:22:15 CET |2015 x86_64 Intel(R)|2015 x86_64 Intel(R) |Core(TM) i7-3610QM CPU @|Core(TM) i7-3610QM CPU @ |2.30GHz GenuineIntel|2.30GHz GenuineIntel |GNU/Linux |GNU/LinuxLinux ASUS-G75VW ||4.3.2-gentoo_2015-12-13 #1 ||SMP Sun Dec 13 18:22:15 CET ||2015 x86_64 Intel(R) ||Core(TM) i7-36 -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 106901] Brightness / WIFI Key does not generate any events
https://bugzilla.kernel.org/show_bug.cgi?id=106901 --- Comment #19 from Roman Gruber --- Created bug report at nvidia page now too. https://devtalk.nvidia.com/default/topic/902979/linux/nvidia-drivers-does-not-handle-brightness-keys-properly/ Offered to provide additional information if any are needed. -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 106901] Brightness / WIFI Key does not generate any events
https://bugzilla.kernel.org/show_bug.cgi?id=106901 --- Comment #20 from Roman Gruber --- glxinfo |grep OpenGL\ version\ string: OpenGL version string: 4.5.0 NVIDIA 358.16 glxinfo |grep Yes direct rendering: Yes uname -a Linux ASUS-G75VW 4.3.2-gentoo_2015-12-13 #1 SMP Sun Dec 13 18:22:15 CET 2015 x86_64 Intel(R) Core(TM) i7-3610QM CPU @ 2.30GHz GenuineIntel GNU/Linux (updated to latest nvidia-drivers and kernel) -- You are receiving this mail because: You are watching the assignee of the bug.
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 --- Comment #4 from Tobias Droste --- I found out why the last CS update caused this issue. They siwtched all graphic options to "auto" with the last update and for my graphics card it figured out that the highest preference in every setting should be the best ones. And with these settings CS:GO is crashing. I switched backed everything to "low" and I can at least play the game again. But the driver should crash with everything set to high. -- 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/20151213/3d96cc56/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 --- Comment #5 from Tobias Droste --- (In reply to Tobias Droste from comment #4) > I found out why the last CS update caused this issue. > They siwtched all graphic options to "auto" with the last update and for my > graphics card it figured out that the highest preference in every setting > should be the best ones. And with these settings CS:GO is crashing. > > I switched backed everything to "low" and I can at least play the game > again. But the driver should crash with everything set to high. "should *not* crash" of course :-) -- 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/20151213/94930693/attachment.html>
[Bug 93360] [radeonsi/llvm] Segfault in CS:GO
https://bugs.freedesktop.org/show_bug.cgi?id=93360 --- Comment #6 from Nicolai Hähnle --- Thank you for posting the workaround! I can confirm that the logs of both of you contain (different) shaders that crash with standalone llc, making this bug easy to reproduce at least. -- 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/20151213/68b722db/attachment.html>
[PATCH 1/2] video:omap2:dss: fix timings for VENC to match what omapdrm expects
Hi Tomi,
Am 09.12.2015 um 09:18 schrieb Tomi Valkeinen :
>
> On 13/11/15 12:29, H. Nikolaus Schaller wrote:
>> Otherwise check_timings fails and we get a "has no modes" message
>> from xrandr.
>>
>> This fix makes the venc assume PAL and NTSC timings that match the
>> timings synthetized by copy_timings_drm_to_omap() from omapdrm
>> mode settings so that check_timings() succeeds.
>>
>> Tested on: BeagleBoard XM, GTA04 and OpenPandora
>>
>> Signed-off-by: H. Nikolaus Schaller
>> ---
>> drivers/video/fbdev/omap2/dss/venc.c | 12
>> 1 file changed, 12 insertions(+)
>
> I've picked this up.
Thanks!
>
> With this patch and the one below I can get tv-out working on my very old
> beagleboard, and it seems to work with X also. It doesn't start automatically
> as the connection state is unknown, but doing "xrandr --output None-1 --auto"
> was all I needed to enable it.
Great that you did find the real reason of the problem.
I have tested it on the GTA04 and it also works.
Will the patches arrive in 4.5?
So thanks a lot,
Nikolaus
>
> Tomi
>
> From a4274600a5a67256b91266b0d2624b9c9028909b Mon Sep 17 00:00:00 2001
> From: Tomi Valkeinen
> Date: Tue, 8 Dec 2015 18:32:14 +0200
> Subject: [PATCH] drm/omap: fix fbdev pix format to support all platforms
>
> omap_fbdev always creates a framebuffer with ARGB pixel format. On
> OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
> OMAP2 none of the overlays support ARGB888.
>
> This patch changes the omap_fbdev's fb to XRGB, which is supported
> by all platforms.
>
> Signed-off-by: Tomi Valkeinen
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> index b8e4cdec28c3..24f92bea39c7 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper,
> dma_addr_t paddr;
> int ret;
>
> - /* only doing ARGB32 since this is what is needed to alpha-blend
> - * with video overlays:
> - */
> sizes->surface_bpp = 32;
> - sizes->surface_depth = 32;
> + sizes->surface_depth = 24;
>
> DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
> sizes->surface_height, sizes->surface_bpp,
>
[PATCH 7/7] drm/omap: fix fbdev pix format to support all platforms
Hi Tomi,
Thank you for the patch.
On Wednesday 09 December 2015 17:38:11 Tomi Valkeinen wrote:
> omap_fbdev always creates a framebuffer with ARGB pixel format. On
> OMAP3 we have VIDEO1 overlay that does not support ARGB, and on
> OMAP2 none of the overlays support ARGB888.
>
> This patch changes the omap_fbdev's fb to XRGB, which is supported
> by all platforms.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_fbdev.c | 5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> b/drivers/gpu/drm/omapdrm/omap_fbdev.c index b8e4cdec28c3..24f92bea39c7
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_fbdev.c
> +++ b/drivers/gpu/drm/omapdrm/omap_fbdev.c
> @@ -112,11 +112,8 @@ static int omap_fbdev_create(struct drm_fb_helper
> *helper, dma_addr_t paddr;
> int ret;
>
> - /* only doing ARGB32 since this is what is needed to alpha-blend
> - * with video overlays:
> - */
> sizes->surface_bpp = 32;
> - sizes->surface_depth = 32;
> + sizes->surface_depth = 24;
>
> DBG("create fbdev: %dx%d@%d (%dx%d)", sizes->surface_width,
> sizes->surface_height, sizes->surface_bpp,
--
Regards,
Laurent Pinchart
[PATCH 01/15] drm: omapdrm: Fix plane state free in plane reset handler
Hi Tomi,
On Wednesday 09 December 2015 14:43:19 Tomi Valkeinen wrote:
> On 05/12/15 00:27, Laurent Pinchart wrote:
> > The plane reset handler frees the plane state and allocates a new
> > default state, but when doing so attempt to free the plane state using
> > the base plane state pointer instead of casting it to the
> > driver-specific state object that has been allocated. Fix it by using
> > the omap_plane_atomic_destroy_state() function to destroy the plane
> > state instead of duplicating the code.
> >
> > Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/drm/omapdrm/omap_plane.c | 53 ---
> > 1 file changed, 26 insertions(+), 27 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c
> > b/drivers/gpu/drm/omapdrm/omap_plane.c index 3054bda72688..11d406b160e1
> > 100644
> > --- a/drivers/gpu/drm/omapdrm/omap_plane.c
> > +++ b/drivers/gpu/drm/omapdrm/omap_plane.c
> > @@ -188,33 +188,6 @@ static const struct drm_plane_helper_funcs
> > omap_plane_helper_funcs = {
> > .atomic_disable = omap_plane_atomic_disable,
> > };
> >
> > -static void omap_plane_reset(struct drm_plane *plane)
> > -{
> > - struct omap_plane *omap_plane = to_omap_plane(plane);
> > - struct omap_plane_state *omap_state;
> > -
> > - if (plane->state && plane->state->fb)
> > - drm_framebuffer_unreference(plane->state->fb);
> > -
> > - kfree(plane->state);
> > - plane->state = NULL;
> > -
> > - omap_state = kzalloc(sizeof(*omap_state), GFP_KERNEL);
> > - if (omap_state == NULL)
> > - return;
> > -
> > - /*
> > -* Set defaults depending on whether we are a primary or overlay
> > -* plane.
> > -*/
> > - omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY
> > - ? 0 : omap_plane->id;
> > - omap_state->base.rotation = BIT(DRM_ROTATE_0);
> > -
> > - plane->state = &omap_state->base;
> > - plane->state->plane = plane;
> > -}
> > -
> > static void omap_plane_destroy(struct drm_plane *plane)
> > {
> > struct omap_plane *omap_plane = to_omap_plane(plane);
> > @@ -270,6 +243,32 @@ static void omap_plane_atomic_destroy_state(struct
> > drm_plane *plane,
> > kfree(to_omap_plane_state(state));
> > }
> >
> > +static void omap_plane_reset(struct drm_plane *plane)
> > +{
> > + struct omap_plane *omap_plane = to_omap_plane(plane);
> > + struct omap_plane_state *omap_state;
> > +
> > + if (plane->state) {
> > + omap_plane_atomic_destroy_state(plane, plane->state);
> > + plane->state = NULL;
> > + }
> > +
> > + omap_state = kzalloc(sizeof(*omap_state), GFP_KERNEL);
> > + if (omap_state == NULL)
> > + return;
> > +
> > + /*
> > +* Set defaults depending on whether we are a primary or overlay
> > +* plane.
> > +*/
> > + omap_state->zorder = plane->type == DRM_PLANE_TYPE_PRIMARY
> > + ? 0 : omap_plane->id;
> > + omap_state->base.rotation = BIT(DRM_ROTATE_0);
> > +
> > + plane->state = &omap_state->base;
> > + plane->state->plane = plane;
> > +}
> > +
> > static int omap_plane_atomic_set_property(struct drm_plane *plane,
> > struct drm_plane_state *state,
> > struct drm_property *property,
>
> This one moves the function, so it's pretty hard to see what actually
> was changed.
It's unfortunately needed if we want to avoid forward declarations. I could
split the patch in two, but given the size of the function and the extent of
the change I thought it wouldn't be worth it.
--
Regards,
Laurent Pinchart
[PATCH 5/7] drm/omap: set DRIVER_ATOMIC for omapdrm
Hi Tomi,
Thank you for the patch.
On Wednesday 09 December 2015 17:38:09 Tomi Valkeinen wrote:
> omapdrm supports atomic modesetting, and it seems to work ok. So let's
> set the flag to enable the atomic modesetting API support.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index c93c13e2c22d..06e9c9193309
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -858,7 +858,8 @@ static const struct file_operations omapdriver_fops = {
> };
>
> static struct drm_driver omap_drm_driver = {
> - .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME,
> + .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_PRIME |
> + DRIVER_ATOMIC,
> .load = dev_load,
> .unload = dev_unload,
> .open = dev_open,
--
Regards,
Laurent Pinchart
[PATCH 4/7] drm/omap: remove unused plugin defines
Hi Tomi,
Thank you for the patch.
On Wednesday 09 December 2015 17:38:08 Tomi Valkeinen wrote:
> Remove unused defines related to SGX plugin which are not used.
>
> Signed-off-by: Tomi Valkeinen
Acked-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/omap_drv.h | 6 --
> include/uapi/drm/omap_drm.h| 6 --
> 2 files changed, 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.h
> b/drivers/gpu/drm/omapdrm/omap_drv.h index 5c367aad8a6e..038a27f349d9
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.h
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.h
> @@ -36,12 +36,6 @@
>
> #define MODULE_NAME "omapdrm"
>
> -/* max # of mapper-id's that can be assigned.. todo, come up with a better
> - * (but still inexpensive) way to store/access per-buffer mapper private
> - * data..
> - */
> -#define MAX_MAPPERS 2
> -
> /* parameters which describe (unrotated) coordinates of scanout within a
> fb: */ struct omap_drm_window {
> uint32_t rotation;
> diff --git a/include/uapi/drm/omap_drm.h b/include/uapi/drm/omap_drm.h
> index 1d0b1172664e..72e461e1e5bc 100644
> --- a/include/uapi/drm/omap_drm.h
> +++ b/include/uapi/drm/omap_drm.h
> @@ -101,9 +101,6 @@ struct drm_omap_gem_info {
>
> #define DRM_OMAP_GET_PARAM 0x00
> #define DRM_OMAP_SET_PARAM 0x01
> -/* placeholder for plugin-api
> -#define DRM_OMAP_GET_BASE0x02
> -*/
> #define DRM_OMAP_GEM_NEW 0x03
> #define DRM_OMAP_GEM_CPU_PREP0x04
> #define DRM_OMAP_GEM_CPU_FINI0x05
> @@ -112,9 +109,6 @@ struct drm_omap_gem_info {
>
> #define DRM_IOCTL_OMAP_GET_PARAM DRM_IOWR(DRM_COMMAND_BASE +
> DRM_OMAP_GET_PARAM, struct drm_omap_param) #define
> DRM_IOCTL_OMAP_SET_PARAM DRM_IOW (DRM_COMMAND_BASE + DRM_OMAP_SET_PARAM,
> struct drm_omap_param) -/* placeholder for plugin-api
> -#define DRM_IOCTL_OMAP_GET_BASE DRM_IOWR(DRM_COMMAND_BASE +
> DRM_OMAP_GET_BASE, struct drm_omap_get_base) -*/
> #define DRM_IOCTL_OMAP_GEM_NEW DRM_IOWR(DRM_COMMAND_BASE +
> DRM_OMAP_GEM_NEW, struct drm_omap_gem_new) #define
> DRM_IOCTL_OMAP_GEM_CPU_PREP DRM_IOW (DRM_COMMAND_BASE +
> DRM_OMAP_GEM_CPU_PREP, struct drm_omap_gem_cpu_prep) #define
> DRM_IOCTL_OMAP_GEM_CPU_FINI DRM_IOW (DRM_COMMAND_BASE +
> DRM_OMAP_GEM_CPU_FINI, struct drm_omap_gem_cpu_fini)
--
Regards,
Laurent Pinchart
[PATCH 2/7] drm/omap: remove extra drm_gem_free_mmap_offset() call
Hi Tomi, Thank you for the patch. On Wednesday 09 December 2015 17:38:06 Tomi Valkeinen wrote: > drm_gem_object_release() calls drm_gem_free_mmap_offset(), so there's no > need to call drm_gem_free_mmap_offset() in omap_gem_free_object(). > > This patch removes the extra drm_gem_free_mmap_offset() call, and should > have no side effects. > > Signed-off-by: Tomi Valkeinen See "[PATCH 11/15] drm: omapdrm: gem: Don't free mmap offset twice" from my dmabuf import series ;-) > --- > drivers/gpu/drm/omapdrm/omap_gem.c | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c > b/drivers/gpu/drm/omapdrm/omap_gem.c index 7ed08fdc4c42..f9ddbf53345c > 100644 > --- a/drivers/gpu/drm/omapdrm/omap_gem.c > +++ b/drivers/gpu/drm/omapdrm/omap_gem.c > @@ -1282,8 +1282,6 @@ void omap_gem_free_object(struct drm_gem_object *obj) > list_del(&omap_obj->mm_list); > spin_unlock(&priv->list_lock); > > - drm_gem_free_mmap_offset(obj); > - > /* this means the object is still pinned.. which really should >* not happen. I think.. >*/ -- Regards, Laurent Pinchart
[PATCH 1/7] drm/omap: ensure all displays have been probed
Hi Tomi,
Thank you for the patch.
On Wednesday 09 December 2015 17:38:05 Tomi Valkeinen wrote:
> DRM offers no ways to add new displays after the DRM driver has been
> loaded. This causes issues on boards that have multiple displays, and
> omapdrm is loaded when some of them are loaded but not all. The result
> is that omapdrm starts with the displays that were loaded at that time,
> ignoring the displays loaded later.
>
> This patch changes the behavior so that omapdrm ensures all display are
> loaded which have an alias in the .dts file.
>
> The downside is that this prevents omapdrm from loading if, say, the
> user has not compiled a kernel module for one of the displays, or
> there's some kind of failure in one of the displays. Thus, after this
> patch, all the displays have to work, or none does.
>
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/gpu/drm/omapdrm/omap_drv.c | 27 +++
> 1 file changed, 27 insertions(+)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
> b/drivers/gpu/drm/omapdrm/omap_drv.c index 5c6609cbb6a2..c93c13e2c22d
> 100644
> --- a/drivers/gpu/drm/omapdrm/omap_drv.c
> +++ b/drivers/gpu/drm/omapdrm/omap_drv.c
> @@ -242,11 +242,38 @@ static void omap_disconnect_dssdevs(void)
> dssdev->driver->disconnect(dssdev);
> }
>
> +static bool dssdev_with_alias_exists(const char *alias)
> +{
> + struct omap_dss_device *dssdev = NULL;
> +
> + for_each_dss_dev(dssdev) {
> + if (strcmp(alias, dssdev->alias) == 0) {
> + omap_dss_put_device(dssdev);
> + return true;
> + }
> + }
> +
> + return false;
> +}
> +
> static int omap_connect_dssdevs(void)
> {
> int r;
> struct omap_dss_device *dssdev = NULL;
> bool no_displays = true;
> + struct device_node *aliases;
> + struct property *pp;
> +
> + aliases = of_find_node_by_path("/aliases");
> + if (aliases) {
> + for_each_property_of_node(aliases, pp) {
> + if (strncmp(pp->name, "display", 7) != 0)
> + continue;
> +
> + if (dssdev_with_alias_exists(pp->name) == false)
> + return -EPROBE_DEFER;
> + }
> + }
The DSS bindings document the aliases as optional, so this won't work in the
general case. The best solution would be to travel the display graph through
the ports and use the components framework, but that would be more complex to
implement.
>
> for_each_dss_dev(dssdev) {
> r = dssdev->driver->connect(dssdev);
--
Regards,
Laurent Pinchart
[PATCH RFC 7/9] omapfb: move vrfb into omapfb
Hi Tomi,
Thank you for the patch.
On Thursday 10 December 2015 16:25:33 Tomi Valkeinen wrote:
> VRFB is only used by omapfb, so we can move it under omapfb's directory.
Do you see any specific blocker for support of vrfb in omapdss, apart from
finding time (and a reason) to implement it ?
> Signed-off-by: Tomi Valkeinen
> ---
> drivers/video/fbdev/omap2/Kconfig | 3 ---
> drivers/video/fbdev/omap2/Makefile| 2 --
> drivers/video/fbdev/omap2/omapfb/Kconfig | 3 +++
> drivers/video/fbdev/omap2/omapfb/Makefile | 1 +
> drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c | 0
> 5 files changed, 4 insertions(+), 5 deletions(-)
> rename drivers/video/fbdev/omap2/{ => omapfb}/vrfb.c (100%)
>
> diff --git a/drivers/video/fbdev/omap2/Kconfig
> b/drivers/video/fbdev/omap2/Kconfig index c22955d2de9a..7fbdb583de8c 100644
> --- a/drivers/video/fbdev/omap2/Kconfig
> +++ b/drivers/video/fbdev/omap2/Kconfig
> @@ -1,6 +1,3 @@
> -config OMAP2_VRFB
> - bool
> -
> if ARCH_OMAP2PLUS
>
> source "drivers/video/fbdev/omap2/dss/Kconfig"
> diff --git a/drivers/video/fbdev/omap2/Makefile
> b/drivers/video/fbdev/omap2/Makefile index c73a1e864ae8..a52b716a40c1
> 100644
> --- a/drivers/video/fbdev/omap2/Makefile
> +++ b/drivers/video/fbdev/omap2/Makefile
> @@ -1,5 +1,3 @@
> -obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
> -
> obj-y += dss/
> obj-y += displays-new/
> obj-y += omapfb/
> diff --git a/drivers/video/fbdev/omap2/omapfb/Kconfig
> b/drivers/video/fbdev/omap2/omapfb/Kconfig index 13d99a9e6198..e6226aeed17e
> 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Kconfig
> +++ b/drivers/video/fbdev/omap2/omapfb/Kconfig
> @@ -1,3 +1,6 @@
> +config OMAP2_VRFB
> + bool
> +
> menuconfig FB_OMAP2
> tristate "OMAP2+ frame buffer support"
> depends on FB
> diff --git a/drivers/video/fbdev/omap2/omapfb/Makefile
> b/drivers/video/fbdev/omap2/omapfb/Makefile index
> 0490951f95b3..ad68ecf141af 100644
> --- a/drivers/video/fbdev/omap2/omapfb/Makefile
> +++ b/drivers/video/fbdev/omap2/omapfb/Makefile
> @@ -1,3 +1,4 @@
> +obj-$(CONFIG_OMAP2_VRFB) += vrfb.o
> obj-y += dss/
> obj-y += displays/
> obj-$(CONFIG_FB_OMAP2) += omapfb.o
> diff --git a/drivers/video/fbdev/omap2/vrfb.c
> b/drivers/video/fbdev/omap2/omapfb/vrfb.c similarity index 100%
> rename from drivers/video/fbdev/omap2/vrfb.c
> rename to drivers/video/fbdev/omap2/omapfb/vrfb.c
--
Regards,
Laurent Pinchart
[PATCH RFC 8/9] drm/omap: move omapdss & displays under omapdrm
Hi Tomi, Thank you for the patch. On Thursday 10 December 2015 16:25:34 Tomi Valkeinen wrote: > Now that omapfb has its own copy of omapdss and display drivers, we can > move omapdss and display drivers which omapdrm uses to omapdrm's > directory. > > We also need to change the main drm Makefile so that omapdrm directory > is always entered, because omapdss has a file that always needs to be > built-in. Which file is that ? omapdss-boot-init.c ? I would say "that can't be built as a module' instead of 'that always needs to be built-in' as the later implies (at least for me) that the file always have to be built-in regardless of whether omapdss support is enabled or not. > Signed-off-by: Tomi Valkeinen -- Regards, Laurent Pinchart
[Intel-gfx] [RFC libdrm] intel: Add support for softpin
On Sun, Dec 13, 2015 at 7:17 PM, Song, Ruiling wrote: >> -Original Message- >> From: Intel-gfx [mailto:intel-gfx-bounces at lists.freedesktop.org] On Behalf >> Of Micha? Winiarski >> Sent: Wednesday, September 9, 2015 10:07 PM >> To: intel-gfx at lists.freedesktop.org >> Cc: Ben Widawsky ; dri-devel at lists.freedesktop.org; >> mesa-dev at lists.freedesktop.org >> Subject: [Intel-gfx] [RFC libdrm] intel: Add support for softpin >> >> Softpin allows userspace to take greater control of GPU virtual address >> space and eliminates the need of relocations. It can also be used to >> mirror addresses between GPU and CPU (shared virtual memory). >> Calls to drm_intel_bo_emit_reloc are still required to build the list of >> drm_i915_gem_exec_objects at exec time, but no entries in relocs are >> created. Self-relocs don't make any sense for softpinned objects and can >> indicate a programming errors, thus are forbidden. Softpinned objects >> are marked by asterisk in debug dumps. >> >> Cc: Thomas Daniel >> Cc: Kristian Høgsberg >> Cc: Zou Nanhai >> Cc: Michel Thierry >> Cc: Ben Widawsky >> Cc: Chris Wilson >> Signed-off-by: MichaŠWiniarski >> --- >> include/drm/i915_drm.h| 4 +- >> intel/intel_bufmgr.c | 9 +++ >> intel/intel_bufmgr.h | 1 + >> intel/intel_bufmgr_gem.c | 176 >> -- >> intel/intel_bufmgr_priv.h | 7 ++ >> 5 files changed, 173 insertions(+), 24 deletions(-) > > Will anybody help to push the patch to libdrm? Beignet highly depend on this > to implement ocl2.0 svm. Is the kernel patch upstream? > Thanks! > Ruiling > > ___ > Intel-gfx mailing list > Intel-gfx at lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx
