[Bug 91656] Pillars of Eternity glitch in maps

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91656

--- Comment #5 from Daniel Scharrer  ---
I can reproduce this on my TAHITI - renders fine with llvmpipe though. Bisected
to:

commit c1de7df6d4086070e63369ab0af3950f53a03592
Author: Brian Paul 
Date:   Mon Jun 22 14:04:09 2015 -0600

st/mesa: remove unneeded pipe_surface_release() in st_render_texture()

This caused us to always free the pipe_surface for the renderbuffer.
The subsequent call to st_update_renderbuffer_surface() would typically
just recreate it.  Remove the call to pipe_surface_release() and let
st_update_renderbuffer_surface() take care of freeing the old surface
if it needs to be replaced (because of change to mipmap level, etc).

This can save quite a few calls to pipe_context::create_surface() and
surface_destroy().

Reviewed-by: Marek Olšák 
Reviewed-by: Jose Fonseca 

-- 
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/20150927/a1779cd0/attachment.html>

[PATCH 1/1] xf86drm.c: Include limits.h to fix build error on Solaris and with musl

[Bernd Kuhls]

musl's strict implementation requires #include  for PATH_MAX.

Patch suggested by evgeny for Solaris:
https://bugs.freedesktop.org/show_bug.cgi?id=92082

A similar patch is needed for musl:
http://git.buildroot.net/buildroot/tree/package/btrfs-progs/0003-compile-fix-undefined-PATH_MAX-under-musl.patch

Signed-off-by: Bernd Kuhls 
---
 xf86drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xf86drm.c b/xf86drm.c
index a9f5c29..ec985eb 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -53,6 +53,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef HAVE_SYS_MKDEV_H
 # include  /* defines major(), minor(), and makedev() on Solaris 
*/
 #endif
-- 
2.5.3

[Bug 76490] Hang during boot when DPM is on (R9 270X)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=76490

--- Comment #56 from Kevin McCormack  ---
Hey guys, I am just wondering if there is any news about this? I noticed a new
commit for an MSI R7 370 here
https://github.com/torvalds/linux/commit/e78654799135a788a941bacad3452fbd7083e518
that makes my patch now not work. So it looks like this may be a gpu bios
issue. Should I update my bios? If so, how do I do this? Thanks!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150927/a351a846/attachment.html>

[Bug 92082] Build on Solaris: xf86drm.c:3021: error: 'PATH_MAX' undeclared (first use in this function)

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92082

--- Comment #2 from Bernd Kuhls  ---
Using a musl toolchain this bug triggers as well and is fixed by
http://lists.freedesktop.org/archives/dri-devel/2015-September/091104.html

-- 
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/20150927/fd3d2b11/attachment.html>

[PATCH] drm/exynos: Avoid NULL pointer dereference in resume if bind failed

[Charles Keepax]

If binding failed calling exynos_dp_enable in exynos_dp_resume will
result in several NULL pointer dereferences. It is much better to
simply skip suspend/resume handling if bind has failed, do so by
checking if a drm_dev exists.

Signed-off-by: Charles Keepax 
---
 drivers/gpu/drm/exynos/exynos_dp_core.c |6 ++
 1 files changed, 6 insertions(+), 0 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_dp_core.c 
b/drivers/gpu/drm/exynos/exynos_dp_core.c
index d66ade0..48baf07 100644
--- a/drivers/gpu/drm/exynos/exynos_dp_core.c
+++ b/drivers/gpu/drm/exynos/exynos_dp_core.c
@@ -1388,6 +1388,9 @@ static int exynos_dp_suspend(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

+   if (!dp->drm_dev)
+   return 0;
+
exynos_dp_disable(>encoder);
return 0;
 }
@@ -1396,6 +1399,9 @@ static int exynos_dp_resume(struct device *dev)
 {
struct exynos_dp_device *dp = dev_get_drvdata(dev);

+   if (!dp->drm_dev)
+   return 0;
+
exynos_dp_enable(>encoder);
return 0;
 }
-- 
1.7.2.5

No more new fbdev drivers, please

[Emil Velikov]

Hi all,

On 27 September 2015 at 14:09, Noralf Trønnes  wrote:
>
> Den 24.09.2015 14:27, skrev Tomi Valkeinen:
>>
>> Hi all,
>>
>> fbdev is (more or less) maintained, but it's a deprecated framework. All
>> new Linux display drivers should be done on DRM.
>>
>> So let's not add any more new fbdev drivers.
>>
>> I will continue to maintain the current fbdev drivers, and I don't mind
>> adding some new features to those current drivers, as long as the amount
>> of code required to add the features stays sensible.
>>
>> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
>> and the question is what to do with those.
>>
>> xgifb was added in 2010, and is still in staging.
>>
>> fbtft looks like maybe some kind of framework on top of fbdev, with
>> fbtft specific subdrivers... I didn't look at it in detail, but my gut
>> says "never".
>
>
> I have done some work [1] to try and make fbtft look more like the rest
> of the kernel (doc [2]), but that work will result in an almost complete
> rewrite of fbtft.
>From a very quick skim fbtft looks pretty much like drm/panel. We
presently have 30+ 'simple' dsi panels, plus a bunch of spi ones. Have
you had a look at these ?

Cheers,
Emil

[PATCH RFC v2 3/3] drm/dp: Add a drm_aux-dev module for reading/writing dpcd registers.

[Daniel Vetter]

On Fri, Sep 25, 2015 at 04:53:47PM -0700, Rafael Antognolli wrote:
> On Tue, Sep 22, 2015 at 02:17:51PM +0200, Daniel Vetter wrote:
> > On Tue, Sep 22, 2015 at 03:00:54PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 15, 2015 at 04:55:04PM -0700, Rafael Antognolli wrote:
> > > > This module is heavily based on i2c-dev. Once loaded, it provides one
> > > > dev node per DP AUX channel, named drm_aux-N.
> > > > 
> > > > It's possible to know which connector owns this aux channel by looking
> > > > at the respective sysfs /sys/class/drm_aux-dev/drm_aux-N/connector, if
> > > > the connector device pointer was correctly set in the aux helper struct.
> > > > 
> > > > Two main operations are provided on the registers: read and write. The
> > > > address of the register to be read or written is given using lseek.
> > > > Reading or writing does not update the offset of the file.
> > > > 
> > > > Signed-off-by: Rafael Antognolli 
> > > > ---
> > > >  drivers/gpu/drm/Kconfig   |   4 +
> > > >  drivers/gpu/drm/Makefile  |   1 +
> > > >  drivers/gpu/drm/drm_aux-dev.c | 326 
> > > > ++
> > > >  3 files changed, 331 insertions(+)
> > > >  create mode 100644 drivers/gpu/drm/drm_aux-dev.c
> > > > 
> > > > diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
> > > > index 1a0a8df..eae847c 100644
> > > > --- a/drivers/gpu/drm/Kconfig
> > > > +++ b/drivers/gpu/drm/Kconfig
> > > > @@ -25,6 +25,10 @@ config DRM_MIPI_DSI
> > > > bool
> > > > depends on DRM
> > > >  
> > > > +config DRM_AUX_CHARDEV
> > > > +   tristate "DRM DP AUX Interface"
> > > > +   depends on DRM
> > > > +
> > > >  config DRM_KMS_HELPER
> > > > tristate
> > > > depends on DRM
> > > > diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
> > > > index 45e7719..a1a94306 100644
> > > > --- a/drivers/gpu/drm/Makefile
> > > > +++ b/drivers/gpu/drm/Makefile
> > > > @@ -32,6 +32,7 @@ CFLAGS_drm_trace_points.o := -I$(src)
> > > >  
> > > >  obj-$(CONFIG_DRM)  += drm.o
> > > >  obj-$(CONFIG_DRM_MIPI_DSI) += drm_mipi_dsi.o
> > > > +obj-$(CONFIG_DRM_AUX_CHARDEV) += drm_aux-dev.o
> > > >  obj-$(CONFIG_DRM_TTM)  += ttm/
> > > >  obj-$(CONFIG_DRM_TDFX) += tdfx/
> > > >  obj-$(CONFIG_DRM_R128) += r128/
> > > > diff --git a/drivers/gpu/drm/drm_aux-dev.c 
> > > > b/drivers/gpu/drm/drm_aux-dev.c
> > > > new file mode 100644
> > > > index 000..fcc334a
> > > > --- /dev/null
> > > > +++ b/drivers/gpu/drm/drm_aux-dev.c
> > > > @@ -0,0 +1,326 @@
> > > > +/*
> > > > + * Copyright © 2015 Intel Corporation
> > > > + *
> > > > + * Permission is hereby granted, free of charge, to any person 
> > > > obtaining a
> > > > + * copy of this software and associated documentation files (the 
> > > > "Software"),
> > > > + * to deal in the Software without restriction, including without 
> > > > limitation
> > > > + * the rights to use, copy, modify, merge, publish, distribute, 
> > > > sublicense,
> > > > + * and/or sell copies of the Software, and to permit persons to whom 
> > > > the
> > > > + * Software is furnished to do so, subject to the following conditions:
> > > > + *
> > > > + * The above copyright notice and this permission notice (including 
> > > > the next
> > > > + * paragraph) shall be included in all copies or substantial portions 
> > > > of the
> > > > + * Software.
> > > > + *
> > > > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, 
> > > > EXPRESS OR
> > > > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF 
> > > > MERCHANTABILITY,
> > > > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT 
> > > > SHALL
> > > > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES 
> > > > OR OTHER
> > > > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, 
> > > > ARISING
> > > > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> > > > DEALINGS
> > > > + * IN THE SOFTWARE.
> > > > + *
> > > > + * Authors:
> > > > + *Rafael Antognolli 
> > > > + *
> > > > + */
> > > > +
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +#include 
> > > > +
> > > > +struct drm_aux_dev {
> > > > +   struct list_head list;
> > > > +   unsigned index;
> > > > +   struct drm_dp_aux *aux;
> > > > +   struct device *dev;
> > > > +};
> > > > +
> > > > +#define DRM_AUX_MINORS 256
> > > > +static int drm_aux_dev_count = 0;
> > > > +static LIST_HEAD(drm_aux_dev_list);
> > > > +static DEFINE_SPINLOCK(drm_aux_dev_list_lock);
> > > > +
> > > > +static struct drm_aux_dev *drm_aux_dev_get_by_minor(unsigned index)
> > > > +{
> > > > +   struct drm_aux_dev *aux_dev;
> > > > +
> > > > +   spin_lock(_aux_dev_list_lock);
> > > > +   list_for_each_entry(aux_dev, _aux_dev_list, list) {
> > > > +   if (aux_dev->index == index)
> > > > +

No more new fbdev drivers, please

[Noralf Trønnes]

Den 24.09.2015 14:27, skrev Tomi Valkeinen:
> Hi all,
>
> fbdev is (more or less) maintained, but it's a deprecated framework. All
> new Linux display drivers should be done on DRM.
>
> So let's not add any more new fbdev drivers.
>
> I will continue to maintain the current fbdev drivers, and I don't mind
> adding some new features to those current drivers, as long as the amount
> of code required to add the features stays sensible.
>
> I see we have three fbdev drivers in staging: xgifb, fbtft and sm750fb,
> and the question is what to do with those.
>
> xgifb was added in 2010, and is still in staging.
>
> fbtft looks like maybe some kind of framework on top of fbdev, with
> fbtft specific subdrivers... I didn't look at it in detail, but my gut
> says "never".

I have done some work [1] to try and make fbtft look more like the rest
of the kernel (doc [2]), but that work will result in an almost complete
rewrite of fbtft. When Tomi showed reluctance to move sm712fb out of
staging [3], I started to look at DRM to see if I could find my way
through the myriad of helpers and objects/structs.

I now have this simplified view of DRM [4]:

struct tinydrm_device {
 struct drm_device *base;
 struct drm_plane plane;
 struct drm_crtc crtc;
 struct drm_encoder encoder;
 struct drm_connector connector;
 struct drm_fbdev_cma *fbdev_cma;
 bool enabled;
 u32 width, height;
 void *dev_private;

 int (*enable)(struct tinydrm_device *tdev);
 int (*disable)(struct tinydrm_device *tdev);

 int (*dirty)(struct drm_framebuffer *fb,
  struct drm_gem_cma_object *cma_obj,
  unsigned flags, unsigned color,
  struct drm_clip_rect *clips, unsigned num_clips);
 /* blank() is missing */
 /* maybe some modeset() function to set hw rotation */
};

Currently I'm able to get fbdev framebuffer changes through as dirty()
calls. Next step is to hook up some of the rewritten fbtft code to
actually get something on the display.

This is the display controller abstraction I use in the rewritten fbtft:

struct lcdctrl {
 struct lcdreg *lcdreg;
 u32 width;
 u32 height;
 u32 rotation;
 bool enabled;
 struct regulator *power_supply;
 void *driver_private;
 u64 flags;

 int (*poweron)(struct lcdctrl *ctrl);
 void (*poweroff)(struct lcdctrl *ctrl);
 int (*update)(struct lcdctrl *ctrl, struct lcdctrl_update *update);
 int (*rotate)(struct lcdctrl *ctrl, u32 rotation);
 int (*blank)(struct lcdctrl *ctrl, bool blank);
 bool (*check)(struct lcdctrl *ctrl, u32 value);
};

So what I would like, is to have a simple struct like this to hide the
complexity of the graphics subsystem. Leaving the driver with just a
few lines of code to setup the controller:

static int ada_mipifb_1480_poweron(struct lcdctrl *ctrl)
{
 lcdreg_reset(reg);
 lcdreg_writereg(reg, ILI9340_PWCTRL1, 0x23);
[...]
}

static int ada_mipifb_probe(struct spi_device *spi)
{
 cfg.width = 240;
 cfg.height = 320;
 cfg.addr_mode0 = ILI9340_MADCTL_MX;
 cfg.addr_mode90 = ILI9340_MADCTL_MV | ILI9340_MADCTL_MY |
   ILI9340_MADCTL_MX;
 cfg.addr_mode180 = ILI9340_MADCTL_MY;
 cfg.addr_mode270 = ILI9340_MADCTL_MV;
 cfg.bgr = true;

 reg = devm_lcdreg_spi_init(spi, LCDREG_SPI_4WIRE);

 ctrl = devm_mipi_dbi_init(reg, );
 ctrl->poweron = ada_mipifb_1480_poweron;

 return devm_lcdctrl_register(ctrl);
}


For me personally it doesn't matter whether these drivers are drm or fbdev.
fbdev has everything these drivers need, but maybe it's not such a good 
choice
for the future.


Noralf.


[1] https://github.com/notro/linux-staging/commits/next
[2] 
https://github.com/notro/linux-staging/blob/next/drivers/staging/fbtft/Documentation/fb/fbtft.txt
[3] https://lkml.org/lkml/2015/9/1/274
[4] https://gist.github.com/notro/59e0c064bc512e85e9b2

No more new fbdev drivers, please

[Dave Airlie]

On 27 September 2015 at 06:49, Rob Clark  wrote:
> On Sat, Sep 26, 2015 at 2:46 PM, Geert Uytterhoeven
>  wrote:
>> Hi David,
>>
>> On Sat, Sep 26, 2015 at 8:13 PM, David Herrmann  
>> wrote:
>>> On Sat, Sep 26, 2015 at 8:01 PM, Geert Uytterhoeven
>>>  wrote:
 On Sat, Sep 26, 2015 at 7:07 PM, Alex Deucher  
 wrote:
> On Sat, Sep 26, 2015 at 4:28 AM, Geert Uytterhoeven
>  wrote:
>> For the (mailing list) record, can you please provide some explicit 
>> pointers
>> to these existing really simple drivers?
>
> See the tilcdc, ast, mgag200, and udl drivers for example.

 Thanks for the list!

 The smallest of these (udl) still counts in at ca. 2800 LoC, while there 
 are
 several fbdev drivers that have less than 200 LoC.
 Granted, these really small ones support a single fixed video mode only, 
 but
 you can write a simple fbdev driver with mode setting in less than 1000 
 LoC.

 I'm sure DRM can do better?
>>>
>>> Is counting lines really the level of the discussion to go here?
>>
>> LoC is not the most important. But if the smallest DRM driver needs an order
>> of magnitude more LoC than the smallest fbdev driver, I start to wonder.
>
> I think most of the drm/kms drivers are bigger due to more features..
> iirc original tilcdc was ~2k loc (compared to ~1.6kloc for da8xx-fb),
> but it already supported multiple modes, page flipping, vblank
> notification, etc.  It has grown since then.  Although still probably
> smaller than downstream da8xx-fb + tda998x hdmi bridge (and re-using
> the same tda998x bridge code with several other drivers too, compared
> to downstream solution for the same)..
>
> Probably there is room for more helpers for even more restrictive hw.

My main worry for having helpers for "simple" hw, is that people start
using them
to have a minimal 400loc driver, but once they add any feature outside
the helper
they have to rewrite their driver to avoid the helpers.

Most of the drm driver is boilerplate, we could possibly reduce the boilerplate,
but I'm not sure it's worth the effort to save somebody a small bit of
trouble at
bringup.

loc is a pointless tool for measuring this, a small drm driver will be as simple
as a small fbdev driver, and will likely provide more features that people need.

Dave.

[Bug 91656] Pillars of Eternity glitch in maps

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=91656

--- Comment #4 from Sasha  ---
I have same problem.
Radeon HD5670.
Mesa 11.1.0-devel

-- 
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/20150927/f864677d/attachment.html>

[Bug 92005] Linux 4.2 DisplayPort MST deadlock?

[bugzilla-dae...@freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=92005

--- Comment #4 from Adam J. Richter  ---
Hi, Dave.

I have tried the patch you attached to this bug report on 2015-09-16 on a
couple of different systems with Linux 4.3-rc2, and confirm that I have so far
not seen any DP-MST related kernel null pointer dereferences.  I do see such
oopses on Linux-4.3-rc2 without your patch.  So, I would encourage you to send
it or something similar upstream if you have not done so already.

By the way, just to warn you that not everything is perfect, I still see
apparently invalid video from one of two DP-MST hubs that I have been using
with 4.3-rc2 + your patch, but that is outside the scope of this
freedesktop.org bug report.  So, I expect to test a little more and close this
bug as "resolved" once your patch or the equivalent appears in a mainline Linux
release candidate.

Thank you very much for your help!

-- 
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.freedesktop.org/archives/dri-devel/attachments/20150927/e5c19644/attachment.html>

[PATCH] [Bug 92082] Solaris fix: 'PATH_MAX' undeclared

[evgeny litvinenko]

Hi Emil,

> Including limits.h does seem like the right way forward. Can you send a git
> format-patch created fix to the ML [1]?
Output of format-patch is at the end of the email.

I added '#include ' right before '#include '
because on Debian 8 (jessie) the file dirent.h includes bits/posix1_lim.h
which indirectly includes limits.h.
Also bits/posix1_lim.h has the comment - 'Never include this file
directly; use  instead.'

After the patch I built and run make check; make distcheck on Debian -
no errors.

> Additionally you should have noticed a bunch of warnings (missing
> implementation of XXX) on non-linux platforms.
> If you'd like to solve these but you're unsure what exactly the functions are
> supposed to do, let me know and I can help out. You can also catch me at
> #dri-devel (freenode), look for xexaxo.

Thanks!
Yes I'd like and will try to solve these 'missing implementation',
I'll ask you if I have questions.


--- Output of format-patch --
>From 0b491abb893d0faf1a9fe0e3052255bf5ad72592 Mon Sep 17 00:00:00 2001
From: Evgeny Litvinenko 
Date: Sat, 26 Sep 2015 22:58:15 +0300
Subject: [PATCH] [Bug 92082] Solaris fix: 'PATH_MAX' undeclared

---
 xf86drm.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xf86drm.c b/xf86drm.c
index a9f5c29..54b808b 100644
--- a/xf86drm.c
+++ b/xf86drm.c
@@ -41,6 +41,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
-- 
2.4.2.341.g4109cf9