Re: [PATCH 12/13] drm/sun4i: use simpler remove_conflicting_framebuffers(NULL)

2017-11-26 Thread Maxime Ripard 
On Fri, Nov 24, 2017 at 06:53:34PM +0100, Michał Mirosław wrote:
> Use remove_conflicting_framebuffers(NULL) instead of duplicating it.
> 
> Signed-off-by: Michał Mirosław 

Acked-by: Maxime Ripard 

Thanks!
Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com


signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: PROBLEM: Asus C201 video mode problems on HDMI hotplug (regression)

2017-11-26 Thread Archit Taneja 

Hi,

On 11/16/2017 11:58 AM, Nick Bowler wrote:

Hi,

Any ideas on this issue?  Are there any additional tests I can perform
to help debug this?

On 2017-11-05 11:41 -0500, Nick Bowler wrote:

I completed bisecting this issue.  See below.

On 2017-11-02, Nick Bowler  wrote:

~50% of the time after a hotplug, there is a vertical pink bar on the
left of the display area and audio is not working at all.  According to
the sink device the display size is 1282x720 which seems pretty wrong
(normal and working situation is 1280x720).

I posted photos of non-working versus working states here:

   https://imgur.com/a/qhAZG

Unplugging and plugging the cable again will correct the issue (it seems
to, for the most part, alternate between working and not-working states,
although not always).  It always works on power up with the cable initially
connected.

This is a regression from 4.11, where hotplug works perfectly every time.


Bisection implicates the following commit:

181e0ef092a4952aa523c5b9cb21394cf43bcd46 is the first bad commit
commit 181e0ef092a4952aa523c5b9cb21394cf43bcd46
Author: Laurent Pinchart 
Date:   Mon Mar 6 01:35:57 2017 +0200

 drm: bridge: dw-hdmi: Fix the PHY power up sequence

 When powering the PHY up we need to wait for the PLL to lock. This is
 done by polling the TX_PHY_LOCK bit in the HDMI_PHY_STAT0 register
 (interrupt-based wait could be implemented as well but is likely
 overkill). The bit is asserted when the PLL locks, but the current code
 incorrectly waits for the bit to be deasserted. Fix it, and while at it,
 replace the udelay() with a sleep as the code never runs in
 non-sleepable context.

 To be consistent with the power down implementation move the poll loop
 to the power off function.


The two main things the commit below does it to a) correctly wait on the
TX_PHY_LOCK bit to be asserted and b) use usleep_range() instead of udelay().

I don't see (b) being a problem. About (a), it's possible that the bit above
is interpreted differently on a rockchip SoC versus a renesas chip. Could you
print the value of HDMI_PHY_STAT0 that's read back?

If the code returns an -ETIMEDOUT, hdmi->phy.ops->init() will return an 
-ETIMEDOUT.
This will cause dw_hdmi_setup() to bail out early, before we get a chance to
configure the AVI infoframe and other stuff. I've seen other HDMI HW throwing 
up pink
strips if the AVI infoframe stuff isn't configured properly.

As an experiment, could you forcefully return 0 instead of -ETIMEDOUT and see 
if things
return back to normal?

Thanks,
Archit




 Signed-off-by: Laurent Pinchart 
 Tested-by: Neil Armstrong 
 Reviewed-by: Jose Abreu 
 Signed-off-by: Archit Taneja 
 Link: 
http://patchwork.freedesktop.org/patch/msgid/20170305233557.11945-1-laurent.pinchart+rene...@ideasonboard.com

:04 04 0defad9d1a61c0355f49c679b18eebae2c4b9495
5d260e6db25d6abc1211d61ec3405be99e693a23 M  drivers

This commit does not revert cleanly, but on top of latest master (which has
the problem) I manually changed the relevant code back to its original state
and the problem is fixed, like this:

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..6618aac95a51 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1100,37 +1100,34 @@ static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)

  static int dw_hdmi_phy_power_on(struct dw_hdmi *hdmi)
  {
-   const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
-   unsigned int i;
-   u8 val;
+   u8 val, msec;

-   if (phy->gen == 1) {
-   dw_hdmi_phy_enable_powerdown(hdmi, false);
+   dw_hdmi_phy_enable_powerdown(hdmi, false);

-   /* Toggle TMDS enable. */
-   dw_hdmi_phy_enable_tmds(hdmi, 0);
-   dw_hdmi_phy_enable_tmds(hdmi, 1);
-   return 0;
-   }
+   /* toggle TMDS enable */
+   dw_hdmi_phy_enable_tmds(hdmi, 0);
+   dw_hdmi_phy_enable_tmds(hdmi, 1);

+   /* gen2 tx power on */
dw_hdmi_phy_gen2_txpwron(hdmi, 1);
dw_hdmi_phy_gen2_pddq(hdmi, 0);

/* Wait for PHY PLL lock */
-   for (i = 0; i < 5; ++i) {
+   msec = 5;
+   do {
val = hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_TX_PHY_LOCK;
-   if (val)
+   if (!val)
break;

-   usleep_range(1000, 2000);
-   }
+   if (msec == 0) {
+   dev_err(hdmi->dev, "PHY PLL not locked\n");
+   return -ETIMEDOUT;
+   }

-   if (!val) {
-   dev_err(hdmi->dev, "PHY PLL failed to lock\n");
-   return -ETIMEDOUT;
-   }
+

Re: [PATCH] drm/bridge: analogix dp: Fix runtime PM state in get_modes() callback

2017-11-26 Thread Archit Taneja 



On 11/21/2017 01:19 PM, Marek Szyprowski wrote:

get_modes() callback might be called asynchronously from the DRM core and
it is not synchronized with bridge_enable(), which sets proper runtime PM
state of the main DP device. Fix this by calling pm_runtime_get_sync()
before calling drm_get_edid(), which in turn calls drm_dp_i2c_xfer() and
analogix_dp_transfer() to ensure that main DP device is runtime active
when doing any access to its registers.


Looks good to me. Would be nice to get an ack from rockchip too. Will queue it
to drm-misc-fixes (so that it's merged for 4.15-rc2) if no one has any
objections.

Thanks,
Archit



This fixes the following kernel issue on Samsung Exynos5250 Snow board:
Unhandled fault: imprecise external abort (0x406) at 0x
pgd = c0004000
[] *pgd=
Internal error: : 406 [#1] PREEMPT SMP ARM
Modules linked in:
CPU: 0 PID: 62 Comm: kworker/0:2 Not tainted 4.13.0-rc2-00364-g4a97a3da420b 
#3357
Hardware name: SAMSUNG EXYNOS (Flattened Device Tree)
Workqueue: events output_poll_execute
task: edc14800 task.stack: edcb2000
PC is at analogix_dp_transfer+0x15c/0x2fc
LR is at analogix_dp_transfer+0x134/0x2fc
pc : []lr : []psr: 6013
sp : edcb3be8  ip : 002a  fp : 0001
r10:   r9 : edcb3cd8  r8 : edcb3c40
r7 :   r6 : edd3b380  r5 : edd3b010  r4 : 0064
r3 :   r2 : f0ad3000  r1 : edcb3c40  r0 : edd3b010
Flags: nZCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Control: 10c5387d  Table: 4000406a  DAC: 0051
Process kworker/0:2 (pid: 62, stack limit = 0xedcb2210)
Stack: (0xedcb3be8 to 0xedcb4000)
[] (analogix_dp_transfer) from [] 
(drm_dp_i2c_do_msg+0x8c/0x2b4)
[] (drm_dp_i2c_do_msg) from [] (drm_dp_i2c_xfer+0x98/0x214)
[] (drm_dp_i2c_xfer) from [] (__i2c_transfer+0x140/0x29c)
[] (__i2c_transfer) from [] (i2c_transfer+0x70/0xe4)
[] (i2c_transfer) from [] (drm_do_probe_ddc_edid+0xb4/0x114)
[] (drm_do_probe_ddc_edid) from [] (drm_probe_ddc+0x18/0x28)
[] (drm_probe_ddc) from [] (drm_get_edid+0x124/0x2d4)
[] (drm_get_edid) from [] (analogix_dp_get_modes+0x90/0x114)
[] (analogix_dp_get_modes) from [] 
(drm_helper_probe_single_connector_modes+0x198/0x68c)
[] (drm_helper_probe_single_connector_modes) from [] 
(drm_setup_crtcs+0x1b4/0xd18)
[] (drm_setup_crtcs) from [] 
(drm_fb_helper_hotplug_event+0x94/0xd0)
[] (drm_fb_helper_hotplug_event) from [] 
(drm_kms_helper_hotplug_event+0x24/0x28)
[] (drm_kms_helper_hotplug_event) from [] 
(output_poll_execute+0x6c/0x174)
[] (output_poll_execute) from [] 
(process_one_work+0x188/0x3fc)
[] (process_one_work) from [] (worker_thread+0x30/0x4b8)
[] (worker_thread) from [] (kthread+0x128/0x164)
[] (kthread) from [] (ret_from_fork+0x14/0x24)
Code: 0a02 ea09 e2544001 0a4a (e59537c8)
---[ end trace cddc7919c79f7878 ]---

Reported-by: Misha Komarovskiy 
CC: sta...@vger.kernel.org # v4.10+
Signed-off-by: Marek Szyprowski 
---
This issue was there from the beginning, but recent changes to DRM
core revealed it. It makes sense to backport it to patch f0a8b49c03d2
("drm/bridge: analogix dp: Fix runtime PM state on driver bind"),
which fixed similar issue on driver bind, thus I've marked it for
stable v4.10+.

Best regards
Marek Szyprowski
Samsung R Institute Poland
---
  drivers/gpu/drm/bridge/analogix/analogix_dp_core.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c 
b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
index 5dd3f1cd074a..a8905049b9da 100644
--- a/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
+++ b/drivers/gpu/drm/bridge/analogix/analogix_dp_core.c
@@ -946,7 +946,9 @@ static int analogix_dp_get_modes(struct drm_connector 
*connector)
return 0;
}
  
+		pm_runtime_get_sync(dp->dev);

edid = drm_get_edid(connector, >aux.ddc);
+   pm_runtime_put(dp->dev);
if (edid) {
drm_mode_connector_update_edid_property(>connector,
edid);



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] MAINTAINERS: change maintainer for Rockchip drm drivers

2017-11-26 Thread Sandy Huang 

Hi Daniel,
I register the account and get the drm-misc commit rights now, thanks.

在 2017/11/24 22:51, Daniel Vetter 写道:

On Fri, Nov 24, 2017 at 09:28:59AM +0100, Heiko Stuebner wrote:

Hi Daniel,

[somehow my email address seems to have gotten lost, so
only saw this by chance on the list itself now.
I've also re-added Sandy to the recipients]

Am Montag, 20. November 2017, 08:48:48 CET schrieb Daniel Vetter:

On Mon, Nov 13, 2017 at 06:15:31PM +0800, Mark Yao wrote:

For personal reasons, Mark Yao will leave rockchip,
can not continue maintain drm/rockchip, Sandy Huang
will take over the drm/rockchip.

Cc: Sandy Huang 
Cc: Heiko Stuebner 

Signed-off-by: Mark Yao 


Since rockchip is in drm-misc that means we need a new maintainer who also
has drm-misc commit rights. Sandy doesn't yet, so if Sandy is going to be
the new maintainer we need to fix that.

Also, Heiko, are you interested in becoming co-maintainer? With commit
rights and all.


I always feel somewhat inadequate judging the fast-paced drm stuff, as in
the past once I got my head wrapped around something, drm always
somehow moved another mile already ;-) .

But somewhere I read that drm-pace for big changes is supposed to slow a
bit now that atomic modesetting is done in a lot of places, so we could give
co-maintainership for the Rockchip-drm a try - with Sandy wearing the
actual hat for big changes though ;-) .


Yeah I think on the modeset side it calmed down a lot. We're still
fine-tuning the helper libraries as we're figuring out better ways to
write drivers. But right now I think a lot of the action is all in details
not relevant for many drivers.

If Sandy's ok with that too pls request an fd.o account for drm-misc and
set up the tooling per our quickstart guide:

https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html#quickstart

Thanks, Daniel



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/1 v2] drm/rockchip: dw-mipi-dsi: fix possible un-balanced runtime PM enable

2017-11-26 Thread Sandy Huang 

Thanks, pushed to drm-misc-fixes.

在 2017/11/15 16:24, Mirza Krak 写道:

In the case where the bind gets deferred we would end up with a
un-balanced runtime PM enable call.

Fix this by simply moving the pm_runtime_enable call to the end of
the bind function when all paths have succeeded.

Signed-off-by: Mirza Krak 
---

Changes in v2:
- typos in commit message

  drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
index 9a20b9d..f7fc652 100644
--- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
+++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
@@ -1275,8 +1275,6 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
          goto err_pllref;
      }

-    pm_runtime_enable(dev);
-
      dsi->dsi_host.ops = _mipi_dsi_host_ops;
      dsi->dsi_host.dev = dev;
      ret = mipi_dsi_host_register(>dsi_host);
@@ -1291,6 +1289,7 @@ static int dw_mipi_dsi_bind(struct device *dev, struct 
device *master,
      }

      dev_set_drvdata(dev, dsi);
+    pm_runtime_enable(dev);
      return 0;

  err_mipi_dsi_host:




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/rockchip: dma-mapping: Use vma_pages helper

2017-11-26 Thread Sandy Huang 

Thanks, this update has merged to drm-misc-next months ago:

https://patchwork.freedesktop.org/patch/178255/


在 2017/11/22 23:24, Vasyl Gomonovych 写道:

Use vma_pages function on vma object instead of explicit computation.
./drivers/gpu/drm/rockchip/rockchip_drm_gem.c:223:34-40: WARNING: Consider 
using vma_pages helper on vma
Generated by: scripts/coccinelle/api/vma_pages.cocci

Signed-off-by: Vasyl Gomonovych 
---
  drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
index 1869c8bb76c8..1d9655576b6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
@@ -220,7 +220,7 @@ static int rockchip_drm_gem_object_mmap_iommu(struct 
drm_gem_object *obj,
  {
      struct rockchip_gem_object *rk_obj = to_rockchip_obj(obj);
      unsigned int i, count = obj->size >> PAGE_SHIFT;
-    unsigned long user_count = (vma->vm_end - vma->vm_start) >> PAGE_SHIFT;
+    unsigned long user_count = vma_pages(vma);
      unsigned long uaddr = vma->vm_start;
      unsigned long offset = vma->vm_pgoff;
      unsigned long end = user_count + offset;




___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

2017-11-26 Thread Eric Anholt 
Boris Brezillon  writes:

> Hi Kees,
>
> On Sat, 25 Nov 2017 12:57:04 -0800
> Kees Cook  wrote:
>
>> On Wed, Nov 22, 2017 at 11:57 PM, Daniel Vetter  wrote:
>> > On Wed, Nov 22, 2017 at 07:21:00PM +0100, Boris Brezillon wrote:  
>> >> On Wed, 22 Nov 2017 19:13:09 +0100
>> >> Daniel Vetter  wrote:
>> >>  
>> >> > On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon
>> >> >  wrote:  
>> >> > > Hi Stefan,
>> >> > >
>> >> > > On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
>> >> > > Stefan Wahren  wrote:
>> >> > >  
>> >> > >> Hi Boris,
>> >> > >> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) 
>> >> > >> with sufficient CMA memory (32 MB), i'll get this warning during 
>> >> > >> boot:
>> >> > >>
>> >> > >> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops 
>> >> > >> vc4_hdmi_ops [vc4])
>> >> > >> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops 
>> >> > >> [vc4])
>> >> > >> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops 
>> >> > >> [vc4])
>> >> > >> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops 
>> >> > >> vc4_crtc_ops [vc4])
>> >> > >> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops 
>> >> > >> vc4_crtc_ops [vc4])
>> >> > >> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops 
>> >> > >> vc4_crtc_ops [vc4])
>> >> > >> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops 
>> >> > >> [vc4])
>> >> > >> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on 
>> >> > >> minor 0
>> >> > >> [7.750841] [drm] Supports vblank timestamp caching Rev 2 
>> >> > >> (21.10.2013).
>> >> > >> [7.757620] [drm] Driver supports precise vblank timestamp query.
>> >> > >> [7.811775] [ cut here ]
>> >> > >> [7.811780] refcount_t: increment on 0; use-after-free.
>> >> > >> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
>> >> > >> refcount_inc+0x44/0x50
>> >> > >> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper 
>> >> > >> smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma 
>> >> > >> crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
>> >> > >> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
>> >> > >> 4.14.0-next-20171122 #1
>> >> > >> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
>> >> > >> [7.811958] task: 800036b91c00 task.stack: 0d6f
>> >> > >> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
>> >> > >> [7.811974] pc : refcount_inc+0x44/0x50
>> >> > >> [7.811981] lr : refcount_inc+0x44/0x50
>> >> > >> [7.811984] sp : 0d6f3300
>> >> > >> [7.811988] x29: 0d6f3300 x28: 
>> >> > >> [7.811996] x27: 0003 x26: 800037107800
>> >> > >> [7.812004] x25: 0001 x24: 800035afdc00
>> >> > >> [7.812012] x23:  x22: 800035dfa600
>> >> > >> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4
>> >> > >> [7.812027] x19:  x18: 
>> >> > >> [7.812034] x17: 0001 x16: 0019
>> >> > >> [7.812042] x15: 0001 x14: fff0
>> >> > >> [7.812049] x13: 090ae840 x12: 08fa2d50
>> >> > >> [7.812057] x11: 08fa2000 x10: 090ad000
>> >> > >> [7.812064] x9 :  x8 : 090b5c2f
>> >> > >> [7.812072] x7 :  x6 : 0015ee00
>> >> > >> [7.812079] x5 :  x4 : 
>> >> > >> [7.812087] x3 :  x2 : 800030047000
>> >> > >> [7.812094] x1 : 800036b91c00 x0 : 002b
>> >> > >> [7.812102] Call trace:
>> >> > >> [7.812109]  refcount_inc+0x44/0x50
>> >> > >> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
>> >> > >> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
>> >> > >> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 
>> >> > >> [drm_kms_helper]
>> >> > >> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
>> >> > >> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
>> >> > >> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 
>> >> > >> [drm_kms_helper]
>> >> > >> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
>> >> > >> [7.813223]  
>> >> > >> drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
>> >> > >> [drm_kms_helper]
>> >> > >> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
>> >> > >> [7.813346]  fbcon_init+0x4e8/0x538
>> >> > >> [7.813357]  visual_init+0xb4/0x108
>> >> > >> [7.813366]  do_bind_con_driver+0x1b8/0x3a0
>> >> > >> [7.813373]  do_take_over_console+0x150/0x1d0
>> >> > >> [7.813380]  do_fbcon_takeover+0x6c/0xf0
>> >> > >> [7.813387]  fbcon_event_notify+0x8fc/0x928
>> >>

[Bug 101442] Piglit shaders@ssa@fs-if-def-else-break fails with sb but passes with R600_DEBUG=nosb

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=101442

--- Comment #3 from romain.na...@gmail.com ---
Hello,

I'm using an HD6310 graphic card and when I'm running piglit with
mesa-17.3-rc5, I have the same error.

What's the status of this bug ?

Best regards,
Romain Naour

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: matroxfb: Delete an error message for a failed memory allocation in matroxfb_crtc2_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 22:13:55 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/matrox/matroxfb_crtc2.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/matrox/matroxfb_crtc2.c 
b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
index 02796a4317a9..f64e1d55d7a1 100644
--- a/drivers/video/fbdev/matrox/matroxfb_crtc2.c
+++ b/drivers/video/fbdev/matrox/matroxfb_crtc2.c
@@ -696,10 +696,9 @@ static void* matroxfb_crtc2_probe(struct matrox_fb_info* 
minfo) {
if (!minfo->devflags.crtc2)
return NULL;
m2info = kzalloc(sizeof(*m2info), GFP_KERNEL);
-   if (!m2info) {
-   printk(KERN_ERR "matroxfb_crtc2: Not enough memory for CRTC2 
control structs\n");
+   if (!m2info)
return NULL;
-   }
+
m2info->primary_dev = minfo;
if (matroxfb_dh_registerfb(m2info)) {
kfree(m2info);
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103913] DRM/Radeon GPU hang

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103913

Alex Deucher  changed:

   What|Removed |Added

Summary|DRM/Radeon driver not   |DRM/Radeon GPU hang
   |resilient to poor monitor   |
   |connections |

--- Comment #1 from Alex Deucher  ---
The monitor connections have nothing to do with GPU hangs.  Can you narrow down
what application causes the GPU hang?

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] video: fbdev-MMP: Improve a size determination in path_init()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:21:33 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c 
b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
index 9f912ea0bfce..fcdbb2df137f 100644
--- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
@@ -406,7 +406,7 @@ static int path_init(struct mmphw_path_plat *path_plat,
dev_info(ctrl->dev, "%s: %s\n", __func__, config->name);
 
/* init driver data */
-   path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
+   path_info = kzalloc(sizeof(*path_info), GFP_KERNEL);
if (!path_info)
return 0;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] video: fbdev-MMP: Delete an error message for a failed memory allocation in two functions

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:16:30 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/mmp/fb/mmpfb.c| 5 ++---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 6 ++
 2 files changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/mmp/fb/mmpfb.c 
b/drivers/video/fbdev/mmp/fb/mmpfb.c
index 92279e02dd94..292b3e403044 100644
--- a/drivers/video/fbdev/mmp/fb/mmpfb.c
+++ b/drivers/video/fbdev/mmp/fb/mmpfb.c
@@ -495,10 +495,9 @@ static int modes_setup(struct mmpfb_info *fbi)
/* put videomode list to info structure */
videomodes = kzalloc(sizeof(struct fb_videomode) * videomode_num,
GFP_KERNEL);
-   if (!videomodes) {
-   dev_err(fbi->dev, "can't malloc video modes\n");
+   if (!videomodes)
return -ENOMEM;
-   }
+
for (i = 0; i < videomode_num; i++)
mmpmode_to_fbmode([i], _modes[i]);
fb_videomode_to_modelist(videomodes, videomode_num, >modelist);
diff --git a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c 
b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
index b6f83d5df9fd..9f912ea0bfce 100644
--- a/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
+++ b/drivers/video/fbdev/mmp/hw/mmp_ctrl.c
@@ -407,11 +407,9 @@ static int path_init(struct mmphw_path_plat *path_plat,
 
/* init driver data */
path_info = kzalloc(sizeof(struct mmp_path_info), GFP_KERNEL);
-   if (!path_info) {
-   dev_err(ctrl->dev, "%s: unable to alloc path_info for %s\n",
-   __func__, config->name);
+   if (!path_info)
return 0;
-   }
+
path_info->name = config->name;
path_info->id = path_plat->id;
path_info->dev = ctrl->dev;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] video/fbdev/mmp: Adjustments for two function implementations

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 21:38:42 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation in two functions
  Improve a size determination in path_init()

 drivers/video/fbdev/mmp/fb/mmpfb.c| 5 ++---
 drivers/video/fbdev/mmp/hw/mmp_ctrl.c | 8 +++-
 2 files changed, 5 insertions(+), 8 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [BUG] drm: vc4: refcount_t: increment on 0; use-after-free.

2017-11-26 Thread Boris Brezillon 
Hi Kees,

On Sat, 25 Nov 2017 12:57:04 -0800
Kees Cook  wrote:

> On Wed, Nov 22, 2017 at 11:57 PM, Daniel Vetter  wrote:
> > On Wed, Nov 22, 2017 at 07:21:00PM +0100, Boris Brezillon wrote:  
> >> On Wed, 22 Nov 2017 19:13:09 +0100
> >> Daniel Vetter  wrote:
> >>  
> >> > On Wed, Nov 22, 2017 at 6:51 PM, Boris Brezillon
> >> >  wrote:  
> >> > > Hi Stefan,
> >> > >
> >> > > On Wed, 22 Nov 2017 17:43:35 +0100 (CET)
> >> > > Stefan Wahren  wrote:
> >> > >  
> >> > >> Hi Boris,
> >> > >> if i boot Raspberry Pi 3 (ARM64, defconfig, linux-next-20171122) with 
> >> > >> sufficient CMA memory (32 MB), i'll get this warning during boot:
> >> > >>
> >> > >> [7.623510] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops 
> >> > >> [vc4])
> >> > >> [7.632453] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops 
> >> > >> [vc4])
> >> > >> [7.639707] vc4-drm soc:gpu: bound 3f40.hvs (ops vc4_hvs_ops 
> >> > >> [vc4])
> >> > >> [7.647364] vc4-drm soc:gpu: bound 3f206000.pixelvalve (ops 
> >> > >> vc4_crtc_ops [vc4])
> >> > >> [7.655451] vc4-drm soc:gpu: bound 3f207000.pixelvalve (ops 
> >> > >> vc4_crtc_ops [vc4])
> >> > >> [7.663415] vc4-drm soc:gpu: bound 3f807000.pixelvalve (ops 
> >> > >> vc4_crtc_ops [vc4])
> >> > >> [7.730580] vc4-drm soc:gpu: bound 3fc0.v3d (ops vc4_v3d_ops 
> >> > >> [vc4])
> >> > >> [7.743965] [drm] Initialized vc4 0.0.0 20140616 for soc:gpu on 
> >> > >> minor 0
> >> > >> [7.750841] [drm] Supports vblank timestamp caching Rev 2 
> >> > >> (21.10.2013).
> >> > >> [7.757620] [drm] Driver supports precise vblank timestamp query.
> >> > >> [7.811775] [ cut here ]
> >> > >> [7.811780] refcount_t: increment on 0; use-after-free.
> >> > >> [7.811881] WARNING: CPU: 2 PID: 2188 at lib/refcount.c:153 
> >> > >> refcount_inc+0x44/0x50
> >> > >> [7.811884] Modules linked in: vc4(+) cfg80211 cec drm_kms_helper 
> >> > >> smsc95xx usbnet drm rfkill brcmutil bcm2835_rng rng_core bcm2835_dma 
> >> > >> crc32_ce i2c_bcm2835 pwm_bcm2835 ip_tables x_tables ipv6
> >> > >> [7.811950] CPU: 2 PID: 2188 Comm: systemd-udevd Not tainted 
> >> > >> 4.14.0-next-20171122 #1
> >> > >> [7.811953] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
> >> > >> [7.811958] task: 800036b91c00 task.stack: 0d6f
> >> > >> [7.811967] pstate: 2005 (nzCv daif -PAN -UAO)
> >> > >> [7.811974] pc : refcount_inc+0x44/0x50
> >> > >> [7.811981] lr : refcount_inc+0x44/0x50
> >> > >> [7.811984] sp : 0d6f3300
> >> > >> [7.811988] x29: 0d6f3300 x28: 
> >> > >> [7.811996] x27: 0003 x26: 800037107800
> >> > >> [7.812004] x25: 0001 x24: 800035afdc00
> >> > >> [7.812012] x23:  x22: 800035dfa600
> >> > >> [7.812020] x21: 800035afd9b0 x20: 800035afd9a4
> >> > >> [7.812027] x19:  x18: 
> >> > >> [7.812034] x17: 0001 x16: 0019
> >> > >> [7.812042] x15: 0001 x14: fff0
> >> > >> [7.812049] x13: 090ae840 x12: 08fa2d50
> >> > >> [7.812057] x11: 08fa2000 x10: 090ad000
> >> > >> [7.812064] x9 :  x8 : 090b5c2f
> >> > >> [7.812072] x7 :  x6 : 0015ee00
> >> > >> [7.812079] x5 :  x4 : 
> >> > >> [7.812087] x3 :  x2 : 800030047000
> >> > >> [7.812094] x1 : 800036b91c00 x0 : 002b
> >> > >> [7.812102] Call trace:
> >> > >> [7.812109]  refcount_inc+0x44/0x50
> >> > >> [7.812226]  vc4_bo_inc_usecnt+0x84/0x88 [vc4]
> >> > >> [7.812310]  vc4_prepare_fb+0x40/0xf0 [vc4]
> >> > >> [7.812460]  drm_atomic_helper_prepare_planes+0x54/0xf0 
> >> > >> [drm_kms_helper]
> >> > >> [7.812543]  vc4_atomic_commit+0x88/0x130 [vc4]
> >> > >> [7.812868]  drm_atomic_commit+0x48/0x68 [drm]
> >> > >> [7.813002]  restore_fbdev_mode_atomic+0x1d8/0x1e8 [drm_kms_helper]
> >> > >> [7.813113]  restore_fbdev_mode+0x28/0x160 [drm_kms_helper]
> >> > >> [7.813223]  
> >> > >> drm_fb_helper_restore_fbdev_mode_unlocked.part.24+0x28/0x90 
> >> > >> [drm_kms_helper]
> >> > >> [7.813331]  drm_fb_helper_set_par+0x54/0xa8 [drm_kms_helper]
> >> > >> [7.813346]  fbcon_init+0x4e8/0x538
> >> > >> [7.813357]  visual_init+0xb4/0x108
> >> > >> [7.813366]  do_bind_con_driver+0x1b8/0x3a0
> >> > >> [7.813373]  do_take_over_console+0x150/0x1d0
> >> > >> [7.813380]  do_fbcon_takeover+0x6c/0xf0
> >> > >> [7.813387]  fbcon_event_notify+0x8fc/0x928
> >> > >> [7.813399]  notifier_call_chain+0x50/0x90
> >> > >> [7.813406]  __blocking_notifier_call_chain+0x4c/0x90
> >> > >> [7.813413]

[Bug 103902] Portal 2 game hangs at startup with latest mesa dev

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103902

fin4...@hotmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from fin4...@hotmail.com ---
Oibaf ppa has above fix for this bug and Portal 2 is working fine.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 4/5] ARM: dts: Add support for emtrion emCON-MX6 series

2017-11-26 Thread Rob Herring 
On Thu, Nov 23, 2017 at 01:55:54PM +0100, Jan Tuerk wrote:
> This patch adds support for the emtrion GmbH emCON-MX6 modules.
> They are available with imx.6 Solo, Dual-Lite, Dual and Quad
> equipped with Memory from 512MB to 2GB (configured by U-Boot).
> 
> Our default developer-Kit ships with the Avari baseboard and the
> EDT ETM0700G0BDH6 Display (imx6[q|dl]-emcon-avari).
> 
> The devicetree is split into the common part providing all module
> components and the basic support for all SoC versions
> (imx6qdl-emcon.dtsi) and parts which are i.mx6 S|DL and D|Q relevant.
> Finally the support for the avari baseboard in the developer-kit
> configuration is provided by the emcon-avari dts files.
> 
> Signed-off-by: Jan Tuerk 
> ---
>  Documentation/devicetree/bindings/arm/emtrion.txt |  13 +
>  arch/arm/boot/dts/Makefile|   2 +
>  arch/arm/boot/dts/imx6dl-emcon-avari.dts  | 233 ++
>  arch/arm/boot/dts/imx6dl-emcon.dtsi   |  37 +
>  arch/arm/boot/dts/imx6q-emcon-avari.dts   | 233 ++
>  arch/arm/boot/dts/imx6q-emcon.dtsi|  37 +
>  arch/arm/boot/dts/imx6qdl-emcon.dtsi  | 849 
> ++
>  7 files changed, 1404 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/arm/emtrion.txt
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6dl-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon-avari.dts
>  create mode 100644 arch/arm/boot/dts/imx6q-emcon.dtsi
>  create mode 100644 arch/arm/boot/dts/imx6qdl-emcon.dtsi
> 
> diff --git a/Documentation/devicetree/bindings/arm/emtrion.txt 
> b/Documentation/devicetree/bindings/arm/emtrion.txt
> new file mode 100644
> index ..3ff6c6c2034d
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/arm/emtrion.txt
> @@ -0,0 +1,13 @@
> +Emtrion Devicetree Bindings
> +===
> +
> +emCON Series:
> +-
> +
> +Required root node properties
> +   - compatible:
> +   - "emtrion,emcon-mx6", "fsl,imx6q", "fsl,imx6dl"; : emCON-MX6 Generic 
> SoM
> +   - "emtrion,emcon-mx6", "fsl,imx6q"; : emCON-MX6D or 
> emCON-MX6Q SoM
> +   - "emtrion,emcon-mx6-avari", "fsl,imx6q";   : emCON-MX6D or 
> emCON-MX6Q SoM on Avari Base
> +   - "emtrion,emcon-mx6", "fsl,imx6dl";: emCON-MX6S or 
> emCON-MX6DL SoM
> +   - "emtrion,emcon-mx6-avari", "fsl,imx6dl";  : emCON-MX6S or 
> emCON-MX6DL SoM on Avari Base
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index d0381e9caf21..5ce643ece228 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -373,6 +373,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6dl-colibri-eval-v3.dtb \
> imx6dl-cubox-i.dtb \
> imx6dl-dfi-fs700-m60.dtb \
> +   imx6dl-emcon-avari.dtb \
> imx6dl-gw51xx.dtb \
> imx6dl-gw52xx.dtb \
> imx6dl-gw53xx.dtb \
> @@ -424,6 +425,7 @@ dtb-$(CONFIG_SOC_IMX6Q) += \
> imx6q-dfi-fs700-m60.dtb \
> imx6q-display5-tianma-tm070-1280x768.dtb \
> imx6q-dmo-edmqmx6.dtb \
> +   imx6q-emcon-avari.dtb \
> imx6q-evi.dtb \
> imx6q-gk802.dtb \
> imx6q-gw51xx.dtb \
> diff --git a/arch/arm/boot/dts/imx6dl-emcon-avari.dts 
> b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> new file mode 100644
> index ..f8ca63258eda
> --- /dev/null
> +++ b/arch/arm/boot/dts/imx6dl-emcon-avari.dts
> @@ -0,0 +1,233 @@
> +/*
> + * Copyright (C) 2017 emtrion GmbH
> + * Author: Jan Tuerk  
> + *
> + * The code contained herein is licensed under the GNU General Public
> + * License. You may obtain a copy of the GNU General Public License
> + * Version 2 or later at the following locations:
> + *
> + * http://www.opensource.org/licenses/gpl-license.html
> + * http://www.gnu.org/copyleft/gpl.html
> + *
> + * SPDX-License-Identifier: GPL-2.0
> + *
> + */
> +
> +/dts-v1/;
> +#include "imx6dl.dtsi"
> +#include "imx6qdl-emcon.dtsi"
> +#include "imx6dl-emcon.dtsi" /*Include camera2 pinmux*/
> +
> +/ {
> +   model = "emtrion SoM emCON-MX6 Solo/Dual-Lite Avari";
> +   compatible = "emtrion,emcon-mx6-avari", "fsl,imx6dl";
> +
> +   aliases {
> +   mmc0 = 
> +   mmc2 = 
> +   mmc1 = 
> +   mmc3 = 
> +   };
> +
> +   chosen {
> +   stdout-path = <>;
> +   };
> +
> +   memory {
> +   reg = <0x1000 0x4000>;
> +   };
> +
> +   supplies {
> +   compatible = "simple-bus";
> +   #address-cells = <1>;
> +   #size-cells = <0>;
> +
> +   wallplug5p0: supply@0 {
> +   compatible = "regulator-fixed";
> +   reg = <0>;
> +   regulator-name = "WALL-PLUG";
> +   regulator-min-microvolt = <500>;
> +

Re: [PATCH 2/5] dt-bindings: Add vendor prefix for emtrion GmbH

2017-11-26 Thread Rob Herring 
On Thu, Nov 23, 2017 at 01:55:52PM +0100, Jan Tuerk wrote:
> emtrion is a system integrator and manufacturer of embedded systems.
> 
> Website: https://www.emtrion.de
> 
> Signed-off-by: Jan Tuerk 
> ---
>  Documentation/devicetree/bindings/vendor-prefixes.txt | 1 +
>  1 file changed, 1 insertion(+)

Acked-by: Rob Herring 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 1/5] drm/panel: Add support for the EDT ETM0700G0BDH6

2017-11-26 Thread Rob Herring 
On Thu, Nov 23, 2017 at 01:55:51PM +0100, Jan Tuerk wrote:
> The Emerging Display Technology ETM0700G0BDH6 is exactly
> the same display as the ETM0700G0DH6, exept the pixelclock
> polarity. Therefore re-use the ETM0700G0DH6 modes. It is
> used by default on emtrion Avari based development kits.
> 
> Signed-off-by: Jan Tuerk 
> ---
>  .../bindings/display/panel/edt,etm0700g0bdh6.txt  |  9 +
>  drivers/gpu/drm/panel/panel-simple.c  | 15 
> +++
>  2 files changed, 24 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt 
> b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
> new file mode 100644
> index ..099e30bfa17f
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/panel/edt,etm0700g0bdh6.txt
> @@ -0,0 +1,9 @@
> +Emerging Display Technology Corp. ETM0700G0BDH6 7.0" WVGA TFT LCD panel
> +
> +Required properties:
> +   compatible: "edt,etm0700g0bdh6"
> +
> +This panel is exactly the same as ETM0700G0DH6 except the pixelclock 
> polarity.

Perhaps document them together.

> +
> +This binding is compatible with the simple-panel binding, which is specified
> +in simple-panel.txt in this directory.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] omapfb/dss: Delete an error message for a failed memory allocation in three functions

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 19:46:09 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap2/omapfb/dss/dispc.c| 4 +---
 drivers/video/fbdev/omap2/omapfb/dss/dss.c  | 4 +---
 drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c | 4 +---
 3 files changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
index 7a75dfda9845..10164a3bae4a 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dispc.c
@@ -3982,10 +3982,8 @@ static int dispc_init_features(struct platform_device 
*pdev)
struct dispc_features *dst;
 
dst = devm_kzalloc(>dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(>dev, "Failed to allocate DISPC Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
index 48c6500c24e1..a5de13777e2b 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
@@ -893,10 +893,8 @@ static int dss_init_features(struct platform_device *pdev)
struct dss_features *dst;
 
dst = devm_kzalloc(>dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(>dev, "Failed to allocate local DSS Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP24xx:
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c 
b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
index 9a13c35fd6d8..d25eea10c665 100644
--- a/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
+++ b/drivers/video/fbdev/omap2/omapfb/dss/hdmi_phy.c
@@ -195,10 +195,8 @@ static int hdmi_phy_init_features(struct platform_device 
*pdev)
const struct hdmi_phy_features *src;
 
dst = devm_kzalloc(>dev, sizeof(*dst), GFP_KERNEL);
-   if (!dst) {
-   dev_err(>dev, "Failed to allocate HDMI PHY Features\n");
+   if (!dst)
return -ENOMEM;
-   }
 
switch (omapdss_get_version()) {
case OMAPDSS_VER_OMAP4430_ES1:
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] video: omap: Delete an error message for a failed memory allocation in mipid_spi_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:21:25 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap/lcd_mipid.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/omap/lcd_mipid.c 
b/drivers/video/fbdev/omap/lcd_mipid.c
index e3a85432f926..e71b674b47d8 100644
--- a/drivers/video/fbdev/omap/lcd_mipid.c
+++ b/drivers/video/fbdev/omap/lcd_mipid.c
@@ -564,10 +564,8 @@ static int mipid_spi_probe(struct spi_device *spi)
int r;
 
md = kzalloc(sizeof(*md), GFP_KERNEL);
-   if (md == NULL) {
-   dev_err(>dev, "out of memory\n");
+   if (!md)
return -ENOMEM;
-   }
 
spi->mode = SPI_MODE_0;
md->spi = spi;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] video: omap: Improve a size determination in omapfb_do_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:16:20 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index b0d91524bf6c..c47059430ca8 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1645,7 +1645,7 @@ static int omapfb_do_probe(struct platform_device *pdev,
goto cleanup;
}
 
-   fbdev = kzalloc(sizeof(struct omapfb_device), GFP_KERNEL);
+   fbdev = kzalloc(sizeof(*fbdev), GFP_KERNEL);
if (fbdev == NULL) {
r = -ENOMEM;
goto cleanup;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] video: omap: Delete an error message for a failed memory allocation in omapfb_do_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:09:15 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/omap/omapfb_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/video/fbdev/omap/omapfb_main.c 
b/drivers/video/fbdev/omap/omapfb_main.c
index 3479a47a3082..b0d91524bf6c 100644
--- a/drivers/video/fbdev/omap/omapfb_main.c
+++ b/drivers/video/fbdev/omap/omapfb_main.c
@@ -1647,8 +1647,6 @@ static int omapfb_do_probe(struct platform_device *pdev,
 
fbdev = kzalloc(sizeof(struct omapfb_device), GFP_KERNEL);
if (fbdev == NULL) {
-   dev_err(>dev,
-   "unable to allocate memory for device info\n");
r = -ENOMEM;
goto cleanup;
}
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] video/fbdev/omap: Adjustments for two function implementations

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 18:38:48 +0100

Three update suggestions were taken into account
from static source code analysis.

Markus Elfring (3):
  Delete an error message for a failed memory allocation in omapfb_do_probe()
  Improve a size determination in omapfb_do_probe()
  Delete an error message for a failed memory allocation in mipid_spi_probe()

 drivers/video/fbdev/omap/lcd_mipid.c   | 4 +---
 drivers/video/fbdev/omap/omapfb_main.c | 4 +---
 2 files changed, 2 insertions(+), 6 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102962] GPU crash running Overwatch in wine-staging

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=102962

--- Comment #4 from sander.s...@gmail.com ---
I created a ticket on Wine for the same issue which contains a full log of the
wine session.


Relevant Wine Bug Ticket

https://bugs.winehq.org/show_bug.cgi?id=44077


System info
---
* wine-2.21 (Staging)
* Linux oribi 4.13.12-1-ARCH #1 SMP PREEMPT Wed Nov 8 11:54:06 CET 2017 x86_64
GNU/Linux
* Advanced Micro Devices [AMD/ATI] Ellesmere [Radeon RX 470/480/570/580]
* Display Server: x11 (X.Org 1.19.5 ) drivers: nvidia (unloaded:
modesetting,fbdev,nv,vesa,nouveau)
* Resolution: 1920x1200@59.95hz
* OpenGL: renderer: AMD Radeon RX 480 Graphics (AMD POLARIS10 / DRM 3.18.0 /
4.13.12-1-ARCH, LLVM 5.0.0)
* version: 4.5 Mesa 17.2.5

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103919] Corrupted rendering in wine

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103919

--- Comment #1 from Felix Hellmann  ---
GPU: Amd RX 480

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103919] Corrupted rendering in wine

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103919

Bug ID: 103919
   Summary: Corrupted rendering in wine
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: pri...@cirk2.de
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135730
  --> https://bugs.freedesktop.org/attachment.cgi?id=135730=edit
apitrace for path of exile

At least two Wine applications (WoW and Path of Exile) have corrupted rendering
in mesa git since some point ~3-4 Weeks ago. The stable mesa 17.2.5 does not
have the issue.

I captured an apitrace (32 nit) in Path of Exile. Replaying the trace several
times shows slightly different corruption each time for me.

I haven't had the time to set up a bisect yet.

Distro: Arch Linux
Kernel: 4.14.0-mainline
Mesa: Commit 0bd83d0461
llvm: svn r318871

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103917] [gfx9/Vega] Performance regression in master, 17.3 works fine

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103917

Bug ID: 103917
   Summary: [gfx9/Vega] Performance regression in master, 17.3
works fine
   Product: Mesa
   Version: git
  Hardware: All
OS: All
Status: NEW
  Severity: critical
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ved...@miletic.net
QA Contact: dri-devel@lists.freedesktop.org

I'm using Fedora rawhide (to become 28) along with Mesa 17.3.0-rc3, LLVM 5.0.0
and Kernel 4.15-git. If I install Mesa 17.3.0-rc5, everything still works fine.
If I install Mesa git, everything works fine with 17.3-rc3 running desktop and
17.4 running games.

After rebo a reboot, however, with Mesa git running both the desktop and games,
performance in games is very bad, rougly 1 fps.

I tried to bisect, but wasn't able to figure out what commit exactly is causing
the problem. I compile Mesa with

./autogen.sh --enable-egl --enable-driglx-direct --disable-gles1 --enable-gles2
--enable-shared-glapi --enable-glx-tls --enable-dri --enable-texture-float
--with-dri-drivers="" --with-egl-platforms=drm,wayland,surfaceless,x11
--with-gallium-drivers=r600,radeonsi,swrast --with-vulkan-drivers=radeon
--enable-opencl --enable-opencl-icd PKG_CONFIG_PATH=/usr/local/lib64/pkgconfig
--enable-nine --enable-gbm --enable-va --enable-vdpau
--libdir=/usr/local/lib64; make clean; make -j4; make -j4 check

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/2] video: s3c-fb: Improve a size determination in s3c_fb_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 15:03:03 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/s3c-fb.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 0914c973cbd9..8c7623d63eb1 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1383,7 +1383,7 @@ static int s3c_fb_probe(struct platform_device *pdev)
return -EINVAL;
}
 
-   sfb = devm_kzalloc(dev, sizeof(struct s3c_fb), GFP_KERNEL);
+   sfb = devm_kzalloc(dev, sizeof(*sfb), GFP_KERNEL);
if (!sfb)
return -ENOMEM;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/2] video: s3c-fb: Delete an error message for a failed memory allocation in s3c_fb_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 15:00:16 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/s3c-fb.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/s3c-fb.c b/drivers/video/fbdev/s3c-fb.c
index 5f4f696c2ecf..0914c973cbd9 100644
--- a/drivers/video/fbdev/s3c-fb.c
+++ b/drivers/video/fbdev/s3c-fb.c
@@ -1384,10 +1384,8 @@ static int s3c_fb_probe(struct platform_device *pdev)
}
 
sfb = devm_kzalloc(dev, sizeof(struct s3c_fb), GFP_KERNEL);
-   if (!sfb) {
-   dev_err(dev, "no memory for framebuffers\n");
+   if (!sfb)
return -ENOMEM;
-   }
 
dev_dbg(dev, "allocate new framebuffer %p\n", sfb);
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/2] video: s3c-fb: Adjustments for s3c_fb_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 15:12:34 +0100

Two update suggestions were taken into account
from static source code analysis.

Markus Elfring (2):
  Delete an error message for a failed memory allocation
  Improve a size determination

 drivers/video/fbdev/s3c-fb.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 09/15] drm/msm/mdp5: Use drm_mode_get_hv_timing() to populate plane clip rectangle

2017-11-26 Thread Archit Taneja 



On 11/24/2017 12:34 AM, Ville Syrjala wrote:

From: Ville Syrjälä 

Use drm_mode_get_hv_timing() to fill out the plane clip rectangle.

Note that this replaces crtc_state->adjusted_mode usage with
crtc_state->mode. The latter is the correct choice since that's the
mode the user provided and it matches the plane crtc coordinates
the user also provided.

Once everyone agrees on this we can move the clip handling into
drm_atomic_helper_check_plane_state().


For this and the msm change in patch # 15/15:

Reviewed-by: Archit Taneja 

Thanks,
Archit



Cc: Laurent Pinchart 
Cc: Rob Clark 
Cc: Archit Taneja 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
  drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 20 ++--
  1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c 
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
index ee41423baeb7..09f758e7bb1b 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c
@@ -286,7 +286,7 @@ static int mdp5_plane_atomic_check_with_state(struct 
drm_crtc_state *crtc_state,
uint32_t max_width, max_height;
bool out_of_bounds = false;
uint32_t caps = 0;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
  
@@ -320,13 +320,13 @@ static int mdp5_plane_atomic_check_with_state(struct drm_crtc_state *crtc_state,

return -ERANGE;
}
  
-	clip.x1 = 0;

-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
  
+	if (crtc_state->enable)

+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);
@@ -471,7 +471,7 @@ static int mdp5_plane_atomic_async_check(struct drm_plane 
*plane,
  {
struct mdp5_plane_state *mdp5_state = to_mdp5_plane_state(state);
struct drm_crtc_state *crtc_state;
-   struct drm_rect clip;
+   struct drm_rect clip = {};
int min_scale, max_scale;
int ret;
  
@@ -499,13 +499,13 @@ static int mdp5_plane_atomic_async_check(struct drm_plane *plane,

plane->state->fb != state->fb)
return -EINVAL;
  
-	clip.x1 = 0;

-   clip.y1 = 0;
-   clip.x2 = crtc_state->adjusted_mode.hdisplay;
-   clip.y2 = crtc_state->adjusted_mode.vdisplay;
min_scale = FRAC_16_16(1, 8);
max_scale = FRAC_16_16(8, 1);
  
+	if (crtc_state->enable)

+   drm_mode_get_hv_timing(_state->mode,
+  , );
+
ret = drm_atomic_helper_check_plane_state(state, crtc_state, ,
  min_scale, max_scale,
  true, true);



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] video: sh_mobile_lcdcfb: Delete an error message for a failed memory allocation in two functions

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 13:48:55 +0100

Omit an extra message for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sh_mobile_lcdcfb.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/drivers/video/fbdev/sh_mobile_lcdcfb.c 
b/drivers/video/fbdev/sh_mobile_lcdcfb.c
index c3a46506e47e..0f9b37034eaf 100644
--- a/drivers/video/fbdev/sh_mobile_lcdcfb.c
+++ b/drivers/video/fbdev/sh_mobile_lcdcfb.c
@@ -2149,10 +2149,8 @@ sh_mobile_lcdc_channel_fb_register(struct 
sh_mobile_lcdc_chan *ch)
if (info->fbdefio) {
ch->sglist = vmalloc(sizeof(struct scatterlist) *
 ch->fb_size >> PAGE_SHIFT);
-   if (!ch->sglist) {
-   dev_err(ch->lcdc->dev, "cannot allocate sglist\n");
+   if (!ch->sglist)
return -ENOMEM;
-   }
}
 
info->bl_dev = ch->bl;
@@ -2718,10 +2716,8 @@ static int sh_mobile_lcdc_probe(struct platform_device 
*pdev)
}
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(>dev, "cannot allocate device data\n");
+   if (!priv)
return -ENOMEM;
-   }
 
priv->dev = >dev;
priv->meram_dev = pdata->meram_dev;
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [RFC][PATCH] drm: adv7511/33: Fix adv7511_cec_init() failure handling

2017-11-26 Thread Archit Taneja 

Hi,

On 11/17/2017 04:29 AM, John Stultz wrote:

From: Arnd Bergmann 

An otherwise correct cleanup patch from Dan Carpenter turned a broken
failure handling from a feature patch by Hans Verkuil into a kernel
Oops, so bisection points to commit 7af35b0addbc ("drm/kirin: Checking
for IS_ERR() instead of NULL") rather than 3b1b975003e4 ("drm:
adv7511/33: add HDMI CEC support").

I've managed to piece together several partial problems, though
I'm still struggling with the bigger picture:

adv7511_probe() registers a drm_bridge structure that was allocated
with devm_kzalloc(). It calls adv7511_cec_init(), which fails for an
unknown reason, which in turn triggers the registered structure to be
removed.

Elsewhere, kirin_drm_platform_probe() gets called, which calls
of_graph_get_remote_node(), and that returns NULL. Before Dan's
patch we would go on with a NULL pointer here and register that,
now kirin_drm_platform_probe() fails with -ENODEV.

In a third driver, dsi_parse_dt() calls drm_of_find_panel_or_bridge(),
which after not finding a panel goes on to call of_drm_find_bridge(),
and that crashes due to the earlier list corruption.

This addresses the first issue by making sure that adv7511_probe()
does not completely fail when the adv7511_cec_init() function fails,
and instead we just disable the CEC feature. This avoids having the
driver entirely fail to load if just the CEC initialization fails.

Reported-by: Naresh Kamboju 
Cc: Xinliang Liu 
Cc: Dan Carpenter 
Cc: Sean Paul 
Cc: Hans Verkuil 
Cc: Archit Taneja 
Link: https://bugs.linaro.org/show_bug.cgi?id=3345
Link: https://lkft.validation.linaro.org/scheduler/job/48017#L3551
Fixes: 7af35b0addbc ("drm/kirin: Checking for IS_ERR() instead of NULL")
Fixes: 3b1b975003e4 ("drm: adv7511/33: add HDMI CEC support")
Signed-off-by: Arnd Bergmann 
[jstultz: Reworked so when adv7511_cec_init() fails, we disable the feature 
instead
of disabling the entire driver, which causes graphics to not funciton]
Signed-off-by: John Stultz 
---
Just wanted to send out my rework of Arnd's patch here.
Feedback would be welcome.

thanks
-john

  drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 0e14f15..939c3b9 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -1203,12 +1203,12 @@ static int adv7511_probe(struct i2c_client *i2c, const 
struct i2c_device_id *id)
  
  #ifdef CONFIG_DRM_I2C_ADV7511_CEC

ret = adv7511_cec_init(dev, adv7511, offset);
-   if (ret)
-   goto err_unregister_cec;
  #else
-   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
-ADV7511_CEC_CTRL_POWER_DOWN);
+   ret = 1;
  #endif
+   if (ret)
+   regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
+ADV7511_CEC_CTRL_POWER_DOWN);


This would force CEC to be powered off even if adv7511_cec_init() returned 0, 
right?
We wouldn't want that if we want to use CEC on a platform that supports it.

Do we know why the call to adv7511_cec_init() is failing on the Hikey board? If 
it's
because there isn't a "cec" clock specified in DT, it's not really a fatal 
error, it
just means that the platform hasn't been set up to support CEC. In that case, we
should just power down the CEC block. So, if adv7511_cec_init() would return a
-ENOENT, which we could use as a hint to power down CEC. So, maybe something 
like this?:

#ifdef CONFIG_DRM_I2C_ADV7511_CEC
ret = adv7511_cec_init(dev, adv7511, offset);
if (ret && ret != -ENOENT)  
goto err_unregister_cec;
#endif
if (ret)
regmap_write(adv7511->regmap, ADV7511_REG_CEC_CTRL + offset,
ADV7511_CEC_CTRL_POWER_DOWN);

Apart from this, we should also move adv7511_cec_init() up in the probe so that
it's called before the drm_bridge is registered.

Thanks,
Archit

  
  	return 0;
  



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103915] Undertale crashes on startup (compiling shaders?)

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103915

--- Comment #1 from fin4...@hotmail.com ---
You are using really old kernel with latest Mesa code and old Debian and that
can cause problems. Use Debian testing Xfce and a custom kernel from kernel.org
or from https://cgit.freedesktop.org/~agd5f/linux

Also use Mesa dev, you can use Oipaf ppa Artful version with Debian testing.
https://launchpad.net/~oibaf/+archive/ubuntu/graphics-drivers
http://www.webupd8.org/2014/10/how-to-add-launchpad-ppas-in-debian-via.html

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4] drm: drm_vblank_cleanup: WARN when refcount > 0

2017-11-26 Thread PrasannaKumar Muralidharan 
Warn when refcount is > 0 in drm_vblank_cleanup.

Signed-off-by: PrasannaKumar Muralidharan 
---
Changes in v4:
* Print refcount value.

Changes in v3:
* Dropped i915 patch that is used for testing this.

No changes in v2.


 drivers/gpu/drm/drm_vblank.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
index 3e61aeb..062cc17 100644
--- a/drivers/gpu/drm/drm_vblank.c
+++ b/drivers/gpu/drm/drm_vblank.c
@@ -403,9 +403,15 @@ void drm_vblank_cleanup(struct drm_device *dev)
return;
 
for (pipe = 0; pipe < dev->num_crtcs; pipe++) {
+   unsigned int refcount;
struct drm_vblank_crtc *vblank = >vblank[pipe];
 
-   WARN_ON(atomic_read(>refcount) > 0);
+   refcount = atomic_read(>refcount);
+   if (refcount > 0) {
+   DRM_DEBUG("vblank refcount: %u in %s\n", refcount,
+  __func__);
+   WARN_ON(refcount > 0);
+   }
 
WARN_ON(READ_ONCE(vblank->enabled) &&
drm_core_check_feature(dev, DRIVER_MODESET));
-- 
2.10.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4] drm: bridge: synopsys/dw-hdmi: Enable cec clock

2017-11-26 Thread Archit Taneja 



On 11/26/2017 01:48 AM, Pierre-Hugues Husson wrote:

Support the "cec" optional clock. The documentation already mentions "cec"
optional clock and it is used by several boards, but currently the driver
doesn't enable it, thus preventing cec from working on those boards.

And even worse: a /dev/cecX device will appear for those boards, but it
won't be functioning without configuring this clock.


Thanks for the updating the commit message. I will queue this to drm-misc-fixes 
once
it's updated with the 4.15-rc1 tag.

Thanks,
Archit



Changes:
v4:
- Change commit message to stress the importance of this patch

v3:
- Drop useless braces

v2:
- Separate ENOENT errors from others
- Propagate other errors (especially -EPROBE_DEFER)

Signed-off-by: Pierre-Hugues Husson 
---
  drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 25 +
  1 file changed, 25 insertions(+)

diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c 
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index bf14214fa464..d82b9747a979 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -138,6 +138,7 @@ struct dw_hdmi {
struct device *dev;
struct clk *isfr_clk;
struct clk *iahb_clk;
+   struct clk *cec_clk;
struct dw_hdmi_i2c *i2c;
  
  	struct hdmi_data_info hdmi_data;

@@ -2382,6 +2383,26 @@ __dw_hdmi_probe(struct platform_device *pdev,
goto err_isfr;
}
  
+	hdmi->cec_clk = devm_clk_get(hdmi->dev, "cec");

+   if (PTR_ERR(hdmi->cec_clk) == -ENOENT) {
+   hdmi->cec_clk = NULL;
+   } else if (IS_ERR(hdmi->cec_clk)) {
+   ret = PTR_ERR(hdmi->cec_clk);
+   if (ret != -EPROBE_DEFER)
+   dev_err(hdmi->dev, "Cannot get HDMI cec clock: %d\n",
+   ret);
+
+   hdmi->cec_clk = NULL;
+   goto err_iahb;
+   } else {
+   ret = clk_prepare_enable(hdmi->cec_clk);
+   if (ret) {
+   dev_err(hdmi->dev, "Cannot enable HDMI cec clock: %d\n",
+   ret);
+   goto err_iahb;
+   }
+   }
+
/* Product and revision IDs */
hdmi->version = (hdmi_readb(hdmi, HDMI_DESIGN_ID) << 8)
  | (hdmi_readb(hdmi, HDMI_REVISION_ID) << 0);
@@ -2518,6 +2539,8 @@ __dw_hdmi_probe(struct platform_device *pdev,
cec_notifier_put(hdmi->cec_notifier);
  
  	clk_disable_unprepare(hdmi->iahb_clk);

+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
  err_isfr:
clk_disable_unprepare(hdmi->isfr_clk);
  err_res:
@@ -2541,6 +2564,8 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
  
  	clk_disable_unprepare(hdmi->iahb_clk);

clk_disable_unprepare(hdmi->isfr_clk);
+   if (hdmi->cec_clk)
+   clk_disable_unprepare(hdmi->cec_clk);
  
  	if (hdmi->i2c)

i2c_del_adapter(>i2c->adap);



--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103915] Undertale crashes on startup (compiling shaders?)

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103915

Bug ID: 103915
   Summary: Undertale crashes on startup (compiling shaders?)
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: tooj...@toojays.net
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 135727
  --> https://bugs.freedesktop.org/attachment.cgi?id=135727=edit
thread apply all bt full

Mesa 17.2.6 self-compiled, running on Debian Stretch
OpenGL renderer string: AMD Radeon (TM) RX 480 Graphics (AMD POLARIS10 / DRM
3.10.0 / 4.11.0-0.bpo.1-amd64, LLVM 5.0.0)

I picked up Undertale 
today, tried to play it but it crashes on startup with the following backtrace:

Core was generated by `/pool/toojays/steam/SteamApps/common/Undertale/runner'.
Program terminated with signal SIGSEGV, Segmentation fault.

Thread 9 (Thread 0xe817fb40 (LWP 28800)):
#0  0xf775bc89 in __kernel_vsyscall ()
#1  0xf73fcb9b in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xef9a21da in cnd_wait (mtx=0xa74e410, cond=0xa74e428) at
../../include/c11/threads_posix.h:159
#3  util_queue_thread_func (input=0xa5a98a8) at u_queue.c:171
#4  0xf73f727a in start_thread (arg=0xe817fb40) at pthread_create.c:333
#5  0xf6f12b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 8 (Thread 0xe91e1b40 (LWP 28798)):
#0  0xf775bc89 in __kernel_vsyscall ()
#1  0xf73fcb9b in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xef9a21da in cnd_wait (mtx=0xa6b2324, cond=0xa6b233c) at
../../include/c11/threads_posix.h:159
#3  util_queue_thread_func (input=0xa5d1580) at u_queue.c:171
#4  0xf73f727a in start_thread (arg=0xe91e1b40) at pthread_create.c:333
#5  0xf6f12b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 7 (Thread 0xebb5eb40 (LWP 28793)):
#0  0xf775bc89 in __kernel_vsyscall ()
#1  0xf73fcb9b in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xef9a21da in cnd_wait (mtx=0xa6b1874, cond=0xa6b188c) at
../../include/c11/threads_posix.h:159
#3  util_queue_thread_func (input=0xa5cf958) at u_queue.c:171
#4  0xf73f727a in start_thread (arg=0xebb5eb40) at pthread_create.c:333
#5  0xf6f12b56 in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:110

Thread 6 (Thread 0xf6be5700 (LWP 28792)):
#0  0xf775bc89 in __kernel_vsyscall ()
#1  0xf73fcb9b in pthread_cond_wait@@GLIBC_2.3.2 () at
../sysdeps/unix/sysv/linux/i386/pthread_cond_wait.S:187
#2  0xef9a258a in cnd_wait (mtx=0xa7ac650, cond=0xa7ac668) at
../../include/c11/threads_posix.h:159
#3  util_queue_fence_wait (fence=0xa7ac650) at u_queue.c:106
#4  0xefbf991c in si_shader_select_with_key (sscreen=0xa6b1e50,
state=state@entry=0xa6cd97c, compiler_state=compiler_state@entry=0xffea3dec,
key=0xffea3ca4, thread_index=-1) at si_state_shaders.c:1596
#5  0xefbfa3c9 in si_shader_select (ctx=ctx@entry=0xa6ccec0,
state=state@entry=0xa6cd97c, compiler_state=compiler_state@entry=0xffea3dec) at
si_state_shaders.c:1753
#6  0xefbfc76f in si_update_shaders (sctx=0xa6ccec0) at si_state_shaders.c:3222
#7  0xefbf45e6 in si_draw_vbo (ctx=, info=) at
si_state_draw.c:1266
#8  0xefaa2f91 in util_draw_arrays (start=0, count=3, mode=PIPE_PRIM_MAX,
pipe=0xa6ccec0) at ./util/u_draw.h:66
#9  util_draw_vertex_buffer (pipe=0xa6ccec0, cso=0x0, vbuf=0xa7ac4a0,
vbuf_slot=0, offset=0, prim_type=15, num_verts=3, num_attribs=2) at
util/u_draw_quad.c:68
#10 0xefc32c6d in r600_draw_rectangle (blitter=0xa6976f0, x1=0, y1=0, x2=640,
y2=480, depth=1, type=UTIL_BLITTER_ATTRIB_COLOR, attrib=0xa74e56c) at
r600_pipe_common.c:239
#11 0xefa9f22b in util_blitter_clear_custom (blitter=0xa6976f0, width=640,
height=480, num_layers=1, clear_buffers=7, color=0xa74e56c, depth=1, stencil=0,
custom_dsa=0x0, custom_blend=0x0) at util/u_blitter.c:1406
#12 0xefa9f333 in util_blitter_clear (blitter=, width=, height=, num_layers=,
clear_buffers=, color=, depth=,
stencil=0) at util/u_blitter.c:1422
#13 0xefbc2102 in si_clear (ctx=0xa6ccec0, buffers=,
color=0xa74e56c, depth=1, stencil=0) at si_blit.c:893
#14 0xefac48e1 in tc_call_clear (pipe=0xa6ccec0, payload=0xa74e568) at
util/u_threaded_context.c:2073
#15 0xefac51bf in tc_batch_execute (thread_index=0, job=0xa74e4c0) at
util/u_threaded_context.c:94
#16 _tc_sync (tc=tc@entry=0xa74e220, func=, info=) at util/u_threaded_context.c:185
#17 0xefac in tc_texture_subdata (_pipe=0xa74e220, resource=0xa7a8ad0,
level=0, usage=0, box=0xffea4208, data=0xa7a83d0, stride=64, layer_stride=1024)
at util/u_threaded_context.c:1631
#18 0xef8ae3ba in st_TexSubImage (ctx=0xa756088, dims=2, texImage=, xoffset=0, yoffset=, zoffset=0, width=16,
height=, depth=1,

[PATCH] video: sh_mobile_meram: Delete an error message for a failed memory allocation in sh_mobile_meram_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 13:08:43 +0100

Omit an extra message for a memory allocation failure in this function.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sh_mobile_meram.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/video/fbdev/sh_mobile_meram.c 
b/drivers/video/fbdev/sh_mobile_meram.c
index baadfb207b2e..b5a6735aeb87 100644
--- a/drivers/video/fbdev/sh_mobile_meram.c
+++ b/drivers/video/fbdev/sh_mobile_meram.c
@@ -644,10 +644,8 @@ static int sh_mobile_meram_probe(struct platform_device 
*pdev)
}
 
priv = kzalloc(sizeof(*priv), GFP_KERNEL);
-   if (!priv) {
-   dev_err(>dev, "cannot allocate device data\n");
+   if (!priv)
return -ENOMEM;
-   }
 
/* Initialize private data. */
mutex_init(>lock);
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] amdkfd fixes 4.15

2017-11-26 Thread Oded Gabbay 
Hi Dave,

This is amdkfd pull request for -rc2. It contains three small fixes to the
CIK SDMA code, compilation error fix in kfd_ioctl.h and fix to accessing
a pointer after it was released.

Thanks,
Oded

The following changes since commit c209101fc1c91a318422733a3721ff6a9ff7899f:

  Merge tag 'drm-misc-fixes-2017-11-20' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2017-11-24 11:33:29 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~gabbayo/linux tags/drm-amdkfd-fixes-2017-11-26

for you to fetch changes up to b4d085201d86af69cbda2214c6dafc0be240ef9f:

  uapi: fix linux/kfd_ioctl.h userspace compilation errors (2017-11-26 11:31:32 
+0200)


Dmitry V. Levin (1):
  uapi: fix linux/kfd_ioctl.h userspace compilation errors

Felix Kuehling (2):
  drm/amdgpu: Fix SDMA load/unload sequence on HWS disabled mode
  drm/amdkfd: Fix SDMA oversubsription handling

Randy Dunlap (1):
  drm/amdkfd: fix amdkfd use-after-free GP fault

shaoyunl (1):
  drm/amdkfd: Fix SDMA ring buffer size calculation

 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c  | 47 --
 drivers/gpu/drm/amd/amdkfd/kfd_module.c|  3 +-
 drivers/gpu/drm/amd/amdkfd/kfd_mqd_manager_cik.c   |  4 +-
 .../gpu/drm/amd/amdkfd/kfd_process_queue_manager.c | 18 +
 include/uapi/linux/kfd_ioctl.h | 22 +-
 5 files changed, 67 insertions(+), 27 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 0/2] R-Car DU: Clip planes to screen boundaries

2017-11-26 Thread Laurent Pinchart 
Hello,

This patch series fixes support for planes that cross the screen boundaries.
The KMS API supports such a configuration, but the DU and VSP hardware
doesn't. This leads to different kind of dispay artifacts or hangs.

The series starts with a bit of refactoring to share existing code and make it
easier to share new code. The second patch then clips planes that are either
partially or fully off-screen, disabling planes that end up being completely
invisible.

Compared to v2, the series has been rebased on top of the latest drm+drm-misc
to benefit from Ville's rework of the plane state check helper, and now
actually uses the clipped source and destination rectangles (and hence passes
the tests).

Compared to v1, fully off-screen planes are now accepted (but obviously not
shown).

The patches are based on top of Dave's latest master branch.

The series has been tested on a Salvator-XS board.

Laurent Pinchart (2):
  drm: rcar-du: Share plane atomic check code between Gen2 and Gen3
  drm: rcar-du: Clip planes to screen boundaries

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 75 +++--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 ++
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 64 +++-
 4 files changed, 83 insertions(+), 63 deletions(-)

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/2] drm: rcar-du: Share plane atomic check code between Gen2 and Gen3

2017-11-26 Thread Laurent Pinchart 
The plane atomic check implementation is identical on Gen2 (DU planes)
and Gen3 (VSP planes), but two separate functions exist as they operate
on different data structures. Refactor the code to share the
implementation.

Signed-off-by: Laurent Pinchart 
Tested-by: Kieran Bingham 
Reviewed-by: Kieran Bingham 
---
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 27 +--
 drivers/gpu/drm/rcar-du/rcar_du_plane.h |  4 
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 22 +-
 3 files changed, 22 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 61833cc1c699..4f076c364f25 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -565,27 +565,26 @@ void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
}
 }
 
-static int rcar_du_plane_atomic_check(struct drm_plane *plane,
- struct drm_plane_state *state)
+int __rcar_du_plane_atomic_check(struct drm_plane *plane,
+struct drm_plane_state *state,
+const struct rcar_du_format_info **format)
 {
-   struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
-   struct rcar_du_plane *rplane = to_rcar_plane(plane);
-   struct rcar_du_device *rcdu = rplane->group->dev;
+   struct drm_device *dev = plane->dev;
 
if (!state->fb || !state->crtc) {
-   rstate->format = NULL;
+   *format = NULL;
return 0;
}
 
if (state->src_w >> 16 != state->crtc_w ||
state->src_h >> 16 != state->crtc_h) {
-   dev_dbg(rcdu->dev, "%s: scaling not supported\n", __func__);
+   dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
return -EINVAL;
}
 
-   rstate->format = rcar_du_format_info(state->fb->format->format);
-   if (rstate->format == NULL) {
-   dev_dbg(rcdu->dev, "%s: unsupported format %08x\n", __func__,
+   *format = rcar_du_format_info(state->fb->format->format);
+   if (*format == NULL) {
+   dev_dbg(dev->dev, "%s: unsupported format %08x\n", __func__,
state->fb->format->format);
return -EINVAL;
}
@@ -593,6 +592,14 @@ static int rcar_du_plane_atomic_check(struct drm_plane 
*plane,
return 0;
 }
 
+static int rcar_du_plane_atomic_check(struct drm_plane *plane,
+ struct drm_plane_state *state)
+{
+   struct rcar_du_plane_state *rstate = to_rcar_plane_state(state);
+
+   return __rcar_du_plane_atomic_check(plane, state, >format);
+}
+
 static void rcar_du_plane_atomic_update(struct drm_plane *plane,
struct drm_plane_state *old_state)
 {
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.h 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
index f62e09f195de..890321b4665d 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.h
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.h
@@ -73,6 +73,10 @@ to_rcar_plane_state(struct drm_plane_state *state)
 int rcar_du_atomic_check_planes(struct drm_device *dev,
struct drm_atomic_state *state);
 
+int __rcar_du_plane_atomic_check(struct drm_plane *plane,
+struct drm_plane_state *state,
+const struct rcar_du_format_info **format);
+
 int rcar_du_planes_init(struct rcar_du_group *rgrp);
 
 void __rcar_du_plane_setup(struct rcar_du_group *rgrp,
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c 
b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
index 2c96147bc444..dd66dcb8da23 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_vsp.c
@@ -268,28 +268,8 @@ static int rcar_du_vsp_plane_atomic_check(struct drm_plane 
*plane,
  struct drm_plane_state *state)
 {
struct rcar_du_vsp_plane_state *rstate = to_rcar_vsp_plane_state(state);
-   struct rcar_du_vsp_plane *rplane = to_rcar_vsp_plane(plane);
-   struct rcar_du_device *rcdu = rplane->vsp->dev;
-
-   if (!state->fb || !state->crtc) {
-   rstate->format = NULL;
-   return 0;
-   }
 
-   if (state->src_w >> 16 != state->crtc_w ||
-   state->src_h >> 16 != state->crtc_h) {
-   dev_dbg(rcdu->dev, "%s: scaling not supported\n", __func__);
-   return -EINVAL;
-   }
-
-   rstate->format = rcar_du_format_info(state->fb->format->format);
-   if (rstate->format == NULL) {
-   dev_dbg(rcdu->dev, "%s: unsupported format %08x\n", __func__,
-   state->fb->format->format);
-   return -EINVAL;
-   }
-
-   return 0;
+

[PATCH v3 2/2] drm: rcar-du: Clip planes to screen boundaries

2017-11-26 Thread Laurent Pinchart 
Unlike the KMS API, the hardware doesn't support planes exceeding the
screen boundaries or planes being located fully off-screen. We need to
clip plane coordinates to support the use case.

Fortunately the DRM core offers a drm_atomic_helper_check_plane_state()
helper that valides the scaling factor and clips the plane coordinates.
Use it to implement the plane atomic check and use the clipped source
and destination rectangles from the plane state instead of the unclipped
source and CRTC coordinates to configure the device.

Signed-off-by: Laurent Pinchart 
---
Changes since v2:

- Actually use the clipped source and destination rectangles
- Use drm_crtc_state::mode instead of drm_crtc_state::adjusted_mode
  where applicable
- Removed spurious semicolon
- Rebased on top of latest drm+drm-misc
---
 drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c | 50 -
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 42 ++-
 3 files changed, 62 insertions(+), 33 deletions(-)

diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c 
b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
index b492063a6e1f..5685d5af6998 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
@@ -319,7 +319,8 @@ static void rcar_du_crtc_update_planes(struct rcar_du_crtc 
*rcrtc)
struct rcar_du_plane *plane = >group->planes[i];
unsigned int j;
 
-   if (plane->plane.state->crtc != >crtc)
+   if (plane->plane.state->crtc != >crtc ||
+   !plane->plane.state->visible)
continue;
 
/* Insert the plane in the sorted planes array. */
diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c 
b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
index 4f076c364f25..4a3d16cf3ed6 100644
--- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
+++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
@@ -332,8 +332,8 @@ static void rcar_du_plane_write(struct rcar_du_group *rgrp,
 static void rcar_du_plane_setup_scanout(struct rcar_du_group *rgrp,
const struct rcar_du_plane_state *state)
 {
-   unsigned int src_x = state->state.src_x >> 16;
-   unsigned int src_y = state->state.src_y >> 16;
+   unsigned int src_x = state->state.src.x1 >> 16;
+   unsigned int src_y = state->state.src.y1 >> 16;
unsigned int index = state->hwindex;
unsigned int pitch;
bool interlaced;
@@ -357,7 +357,7 @@ static void rcar_du_plane_setup_scanout(struct 
rcar_du_group *rgrp,
dma[i] = gem->paddr + fb->offsets[i];
}
} else {
-   pitch = state->state.src_w >> 16;
+   pitch = drm_rect_width(>state.src) >> 16;
dma[0] = 0;
dma[1] = 0;
}
@@ -521,6 +521,7 @@ static void rcar_du_plane_setup_format(struct rcar_du_group 
*rgrp,
   const struct rcar_du_plane_state *state)
 {
struct rcar_du_device *rcdu = rgrp->dev;
+   const struct drm_rect *dst = >state.dst;
 
if (rcdu->info->gen < 3)
rcar_du_plane_setup_format_gen2(rgrp, index, state);
@@ -528,10 +529,10 @@ static void rcar_du_plane_setup_format(struct 
rcar_du_group *rgrp,
rcar_du_plane_setup_format_gen3(rgrp, index, state);
 
/* Destination position and size */
-   rcar_du_plane_write(rgrp, index, PnDSXR, state->state.crtc_w);
-   rcar_du_plane_write(rgrp, index, PnDSYR, state->state.crtc_h);
-   rcar_du_plane_write(rgrp, index, PnDPXR, state->state.crtc_x);
-   rcar_du_plane_write(rgrp, index, PnDPYR, state->state.crtc_y);
+   rcar_du_plane_write(rgrp, index, PnDSXR, drm_rect_width(dst));
+   rcar_du_plane_write(rgrp, index, PnDSYR, drm_rect_height(dst));
+   rcar_du_plane_write(rgrp, index, PnDPXR, dst->x1);
+   rcar_du_plane_write(rgrp, index, PnDPYR, dst->y1);
 
if (rcdu->info->gen < 3) {
/* Wrap-around and blinking, disabled */
@@ -570,16 +571,39 @@ int __rcar_du_plane_atomic_check(struct drm_plane *plane,
 const struct rcar_du_format_info **format)
 {
struct drm_device *dev = plane->dev;
+   struct drm_crtc_state *crtc_state;
+   struct drm_rect clip;
+   int ret;
 
-   if (!state->fb || !state->crtc) {
+   if (!state->crtc) {
+   /*
+* The visible field is not reset by the DRM core but only
+* updated by drm_plane_helper_check_state(), set it manually.
+*/
+   state->visible = false;
*format = NULL;
return 0;
}
 
-   if (state->src_w >> 16 != state->crtc_w ||
-   state->src_h >> 16 != state->crtc_h) {
-   dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
-

Re: [PATCH v2 2/2] drm: rcar-du: Clip planes to screen boundaries

2017-11-26 Thread Laurent Pinchart 
Hi Ville,

On Thursday, 16 November 2017 19:04:26 EET Ville Syrjälä wrote:
> On Mon, Nov 13, 2017 at 10:47:00AM +0200, Laurent Pinchart wrote:
> > Unlike the KMS API, the hardware doesn't support planes exceeding the
> > screen boundaries or planes being located fully off-screen. We need to
> > clip plane coordinates to support the use case.
> > 
> > Fortunately the DRM core offers the drm_plane_helper_check_state()
> > helper that valides the scaling factor and clips the plane coordinates.
> > Use it to implement the plane atomic check and use the clipped source
> > and destination rectangles from the plane state instead of the unclipped
> > source and CRTC coordinates to configure the device.
> > 
> > Signed-off-by: Laurent Pinchart
> > 
> > ---
> > 
> >  drivers/gpu/drm/rcar-du/rcar_du_crtc.c  |  3 ++-
> >  drivers/gpu/drm/rcar-du/rcar_du_plane.c | 37 +---
> >  drivers/gpu/drm/rcar-du/rcar_du_vsp.c   | 10 ++---
> >  3 files changed, 39 insertions(+), 11 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c index b492063a6e1f..5685d5af6998
> > 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_crtc.c
> > @@ -319,7 +319,8 @@ static void rcar_du_crtc_update_planes(struct
> > rcar_du_crtc *rcrtc)> 
> > struct rcar_du_plane *plane = >group->planes[i];
> > unsigned int j;
> > 
> > -   if (plane->plane.state->crtc != >crtc)
> > +   if (plane->plane.state->crtc != >crtc ||
> > +   !plane->plane.state->visible)
> > 
> > continue;
> > 
> > /* Insert the plane in the sorted planes array. */
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_plane.c index
> > 4f076c364f25..9cf02b44902d 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_plane.c
> > @@ -570,16 +570,39 @@ int __rcar_du_plane_atomic_check(struct drm_plane
> > *plane,
> >  const struct rcar_du_format_info **format)
> >  {
> > struct drm_device *dev = plane->dev;
> > +   struct drm_crtc_state *crtc_state;
> > +   struct drm_rect clip;
> > +   int ret;
> > 
> > -   if (!state->fb || !state->crtc) {
> > +   if (!state->crtc) {
> > +   /*
> > +* The visible field is not reset by the DRM core but only
> > +* updated by drm_plane_helper_check_state(), set it manually.
> > +*/
> > +   state->visible = false;
> > *format = NULL;
> > return 0;
> > -   }
> > +   };
> 
> spurious ;

Oops, my bad, I'll fix that.

> > -   if (state->src_w >> 16 != state->crtc_w ||
> > -   state->src_h >> 16 != state->crtc_h) {
> > -   dev_dbg(dev->dev, "%s: scaling not supported\n", __func__);
> > -   return -EINVAL;
> > +   crtc_state = drm_atomic_get_crtc_state(state->state, state->crtc);
> > +   if (IS_ERR(crtc_state))
> > +   return PTR_ERR(crtc_state);
> > +
> > +   clip.x1 = 0;
> > +   clip.y1 = 0;
> > +   clip.x2 = crtc_state->adjusted_mode.hdisplay;
> > +   clip.y2 = crtc_state->adjusted_mode.vdisplay;
> 
> crtc_state->mode would be more correct. I messed that up too in my
> recent vmwgfx fix [1]. But this should probably work just as well
> if you don't have a crtc scaler in your pipeline.

Indeed, my CRTC can't scale, so this works, but I'll fix it nonetheless.

> Also you may want to leave the clip empty when !crtc_state->enable.
> That way you'll be guaranteed to get visible==false. The helper is
> currently a bit broken wrt. the crtc->enable vs. crtc_state->enable.
> I've fixed that in [1] as well but those patches haven't been pushed
> yet.

[1] has landed in drm-misc, I'll rebase this series on top of that, and will 
send a pull request when drm-misc gets merged in Dave's tree.

> After getting that stuff in, I'm going to attempt moving this
> clipping stuff entirely into the helper to avoid these kinds of
> mistakes in the future.

Good idea, thanks.

> [1] https://patchwork.freedesktop.org/series/33001/
> 
> > +
> > +   ret = drm_plane_helper_check_state(state, ,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  DRM_PLANE_HELPER_NO_SCALING,
> > +  true, true);
> > +   if (ret < 0)
> > +   return ret;
> > +
> > +   if (!state->visible) {
> > +   *format = NULL;
> > +   return 0;
> > }
> > 
> > *format = rcar_du_format_info(state->fb->format->format);

-- 
Regards,

Laurent Pinchart

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103913] DRM/Radeon driver not resilient to poor monitor connections

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103913

Bug ID: 103913
   Summary: DRM/Radeon driver not resilient to poor monitor
connections
   Product: DRI
   Version: XOrg git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: ro...@beardandsandals.co.uk

Disconnecting and reconnecting HDMI/DVI connectors, or a loose connection, can
cause the driver to stall in a loop with the following messages being logged
approximately every 500ms in syslog.

Nov 25 16:13:30 dragon kernel: [363196.855813] radeon :02:00.0: ring 0
stalled for more than 1710608msec
Nov 25 16:13:30 dragon kernel: [363196.855818] radeon :02:00.0: GPU lockup
(current fence id 0x00284cb5 last fence id 0x00284cb6 on ring
0)

This causes the screen to blank. A reboot is required to clear this.

It would seem more sensible to reset the driver if it has been locked on the
same fence for a long time.

=

(II) Module radeon: vendor="X.Org Foundation"[82.693]compiled
for 1.19.3, module version = 7.10.0  [82.693]Module class: X.Org
Video Driver  [82.693]ABI class: X.Org Video Driver,
version 23.0   [82.693] (II) 

roger@dragon:/var/log$ sudo lshw -c video  
*-display
   description: VGA compatible controller
   product: RV770 [Radeon HD 4850]
   vendor: Advanced Micro Devices, Inc. [AMD/ATI]
   physical id: 0
   bus info: pci@:02:00.0
   version: 00
   width: 64 bits
   clock: 33MHz
   capabilities: pm pciexpress msi vga_controller bus_master cap_list rom
   configuration: driver=radeon latency=0
   resources: irq:26 memory:d000-dfff memory:fbae-fbae
ioport:b000(size=256) memory:c-d


Roger

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100726

--- Comment #5 from hiwatari.se...@gmail.com ---
Created attachment 135725
  --> https://bugs.freedesktop.org/attachment.cgi?id=135725=edit
New Bisect log

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 100726] [REGRESSION][BISECTED] Severe flickering with an R9 290

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=100726

hiwatari.se...@gmail.com changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #4 from hiwatari.se...@gmail.com ---
I was wrong, unfortunately. This error is still present.
A friend of mine is having the same problem with a Fury X card.

So I did another bisect, waiting longer before declaring a commit as good.
But at some point, the build always crashed with:

kernel/built-in.o: In function `update_wall_time':
(.text+0x52c37): undefined reference to `ilog2_NaN'
make: *** [Makefile:961: vmlinux] Error 1

So I had to skip all remaining commits.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 4/4] video: sm501fb: Adjust 15 checks for null pointers

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 10:56:46 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

The script “checkpatch.pl” pointed information out like the following.

Comparison to NULL could be written !…

Thus fix the affected source code places.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sm501fb.c | 31 ++-
 1 file changed, 14 insertions(+), 17 deletions(-)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index f38e3773ccc0..313acc83bb71 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1484,7 +1484,7 @@ static int sm501_init_cursor(struct fb_info *fbi, 
unsigned int reg_base)
struct sm501fb_info *info;
int ret;
 
-   if (fbi == NULL)
+   if (!fbi)
return 0;
 
par = fbi->par;
@@ -1532,7 +1532,7 @@ static int sm501fb_start(struct sm501fb_info *info,
/* allocate, reserve and remap resources for display
 * controller registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
-   if (res == NULL) {
+   if (!res) {
dev_err(dev, "no resource definition for registers\n");
ret = -ENOENT;
goto err_release;
@@ -1541,15 +1541,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->regs_res = request_mem_region(res->start,
resource_size(res),
pdev->name);
-
-   if (info->regs_res == NULL) {
+   if (!info->regs_res) {
dev_err(dev, "cannot claim registers\n");
ret = -ENXIO;
goto err_release;
}
 
info->regs = ioremap(res->start, resource_size(res));
-   if (info->regs == NULL) {
+   if (!info->regs) {
dev_err(dev, "cannot remap registers\n");
ret = -ENXIO;
goto err_regs_res;
@@ -1558,7 +1557,7 @@ static int sm501fb_start(struct sm501fb_info *info,
/* allocate, reserve and remap resources for 2d
 * controller registers */
res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
-   if (res == NULL) {
+   if (!res) {
dev_err(dev, "no resource definition for 2d registers\n");
ret = -ENOENT;
goto err_regs_map;
@@ -1567,15 +1566,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->regs2d_res = request_mem_region(res->start,
  resource_size(res),
  pdev->name);
-
-   if (info->regs2d_res == NULL) {
+   if (!info->regs2d_res) {
dev_err(dev, "cannot claim registers\n");
ret = -ENXIO;
goto err_regs_map;
}
 
info->regs2d = ioremap(res->start, resource_size(res));
-   if (info->regs2d == NULL) {
+   if (!info->regs2d) {
dev_err(dev, "cannot remap registers\n");
ret = -ENXIO;
goto err_regs2d_res;
@@ -1583,7 +1581,7 @@ static int sm501fb_start(struct sm501fb_info *info,
 
/* allocate, reserve resources for framebuffer */
res = platform_get_resource(pdev, IORESOURCE_MEM, 2);
-   if (res == NULL) {
+   if (!res) {
dev_err(dev, "no memory resource defined\n");
ret = -ENXIO;
goto err_regs2d_map;
@@ -1592,14 +1590,14 @@ static int sm501fb_start(struct sm501fb_info *info,
info->fbmem_res = request_mem_region(res->start,
 resource_size(res),
 pdev->name);
-   if (info->fbmem_res == NULL) {
+   if (!info->fbmem_res) {
dev_err(dev, "cannot claim framebuffer\n");
ret = -ENXIO;
goto err_regs2d_map;
}
 
info->fbmem = ioremap(res->start, resource_size(res));
-   if (info->fbmem == NULL) {
+   if (!info->fbmem) {
dev_err(dev, "cannot remap framebuffer\n");
ret = -ENXIO;
goto err_mem_res;
@@ -1862,13 +1860,13 @@ static int sm501fb_probe_one(struct sm501fb_info *info,
pd = (head == HEAD_CRT) ? info->pdata->fb_crt : info->pdata->fb_pnl;
 
/* Do not initialise if we've not been given any platform data */
-   if (pd == NULL) {
+   if (!pd) {
dev_info(info->dev, "no data for fb %s (disabled)\n", name);
return 0;
}
 
fbi = framebuffer_alloc(sizeof(struct sm501fb_par), info->dev);
-   if (fbi == NULL) {
+   if (!fbi) {
dev_err(info->dev, "cannot allocate %s framebuffer\n", name);
return -ENOMEM;
}
@@ -1944,7 +1942,7 @@ static int sm501fb_probe(struct

[PATCH 3/4] video: sm501fb: Combine substrings for four messages

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 10:43:36 +0100

The script "checkpatch.pl" pointed information out like the following.

WARNING: quoted string split across lines

Thus fix four source code places.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sm501fb.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 80bda5a655c0..f38e3773ccc0 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -510,10 +510,10 @@ static int sm501fb_set_par_common(struct fb_info *info,
/* update fb layer with actual clock used */
var->pixclock = sm501fb_hz_to_ps(sm501pixclock);
 
-   dev_dbg(fbi->dev, "%s: pixclock(ps) = %u, pixclock(Hz)  = %lu, "
-  "sm501pixclock = %lu,  error = %ld%%\n",
-  __func__, var->pixclock, pixclock, sm501pixclock,
-  ((pixclock - sm501pixclock)*100)/pixclock);
+   dev_dbg(fbi->dev,
+   "%s: pixclock(ps) = %u, pixclock(Hz)  = %lu, sm501pixclock = 
%lu,  error = %ld%%\n",
+   __func__, var->pixclock, pixclock, sm501pixclock,
+   ((pixclock - sm501pixclock) * 100) / pixclock);
 
return 0;
 }
@@ -1789,16 +1789,16 @@ static int sm501fb_init_fb(struct fb_info *fb, enum 
sm501_controller head,
 
switch (ret) {
case 1:
-   dev_info(info->dev, "using mode specified in "
-   "@mode\n");
+   dev_info(info->dev,
+"using mode specified in @mode\n");
break;
case 2:
-   dev_info(info->dev, "using mode specified in "
-   "@mode with ignored refresh rate\n");
+   dev_info(info->dev,
+"using mode specified in @mode with 
ignored refresh rate\n");
break;
case 3:
-   dev_info(info->dev, "using mode default "
-   "mode\n");
+   dev_info(info->dev,
+"using mode default mode\n");
break;
case 4:
dev_info(info->dev, "using mode from list\n");
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/4] video: sm501fb: Improve a size determination in sm501fb_probe()

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 10:22:37 +0100

Replace the specification of a data structure by a pointer dereference
as the parameter for the operator "sizeof" to make the corresponding size
determination a bit safer according to the Linux coding style convention.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sm501fb.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index e8301c4e7d44..80bda5a655c0 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1932,8 +1932,7 @@ static int sm501fb_probe(struct platform_device *pdev)
int ret;
 
/* allocate our framebuffers */
-
-   info = kzalloc(sizeof(struct sm501fb_info), GFP_KERNEL);
+   info = kzalloc(sizeof(*info), GFP_KERNEL);
if (!info)
return -ENOMEM;
 
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/4] video: sm501fb: Delete error messages for a failed memory allocation in two functions

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 10:10:31 +0100

Omit extra messages for a memory allocation failure in these functions.

This issue was detected by using the Coccinelle software.

Signed-off-by: Markus Elfring 
---
 drivers/video/fbdev/sm501fb.c | 12 +++-
 1 file changed, 3 insertions(+), 9 deletions(-)

diff --git a/drivers/video/fbdev/sm501fb.c b/drivers/video/fbdev/sm501fb.c
index 6f0a19501c6a..e8301c4e7d44 100644
--- a/drivers/video/fbdev/sm501fb.c
+++ b/drivers/video/fbdev/sm501fb.c
@@ -1934,10 +1934,8 @@ static int sm501fb_probe(struct platform_device *pdev)
/* allocate our framebuffers */
 
info = kzalloc(sizeof(struct sm501fb_info), GFP_KERNEL);
-   if (!info) {
-   dev_err(dev, "failed to allocate state\n");
+   if (!info)
return -ENOMEM;
-   }
 
info->dev = dev = >dev;
platform_set_drvdata(pdev, info);
@@ -2121,16 +2119,12 @@ static int sm501fb_suspend_fb(struct sm501fb_info *info,
/* backup copies in case chip is powered down over suspend */
 
par->store_fb = vmalloc(par->screen.size);
-   if (par->store_fb == NULL) {
-   dev_err(info->dev, "no memory to store screen\n");
+   if (!par->store_fb)
return -ENOMEM;
-   }
 
par->store_cursor = vmalloc(par->cursor.size);
-   if (par->store_cursor == NULL) {
-   dev_err(info->dev, "no memory to store cursor\n");
+   if (!par->store_cursor)
goto err_nocursor;
-   }
 
dev_dbg(info->dev, "suspending screen to %p\n", par->store_fb);
dev_dbg(info->dev, "suspending cursor to %p\n", par->store_cursor);
-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/4] video: sm501fb: Adjustments for seven function implementations

2017-11-26 Thread SF Markus Elfring 
From: Markus Elfring 
Date: Sun, 26 Nov 2017 11:10:01 +0100

A few update suggestions were taken into account
from static source code analysis.

Markus Elfring (4):
  Delete error messages for a failed memory allocation in two functions
  Improve a size determination in sm501fb_probe()
  Combine substrings for four messages
  Adjust 15 checks for null pointers

 drivers/video/fbdev/sm501fb.c | 66 ++-
 1 file changed, 28 insertions(+), 38 deletions(-)

-- 
2.15.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 103911] r600/eg: egd_tables.h missing from 17.2.x tarballs

2017-11-26 Thread bugzilla-daemon 
https://bugs.freedesktop.org/show_bug.cgi?id=103911

Bug ID: 103911
   Summary: r600/eg: egd_tables.h missing from 17.2.x tarballs
   Product: Mesa
   Version: 17.2
  Hardware: Other
OS: OpenBSD
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: j...@openbsd.org
QA Contact: dri-devel@lists.freedesktop.org

The src/gallium/drivers/r600/egd_tables.h file is missing from the Mesa 17.2.x
tarballs.  This has needlessly introduced a build time requirement of python.

I can not easily test the dist targets myself as they break in srg/egl when
wayland is not present.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel