[Bug 103544] Graphical glitches r600 in game this war of mine linux native

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

--- Comment #6 from Ilia Mirkin  ---
(In reply to Roland Scheidegger from comment #5)
> I've actually got that game myself here.
> So I did the bisect and the winner is:
> ce7a045feeef8cad155f1c9aa07f166e146e3d00 is the first bad commit
> commit ce7a045feeef8cad155f1c9aa07f166e146e3d00
> Author: Ilia Mirkin 
> Date:   Mon Jan 23 20:53:50 2017 -0500
> 
> r600g: use ieee variants of multiplication instructions
> 
> This matches the behavior of most other drivers, including nouveau,
> radeonsi, and i965.
> 
> Signed-off-by: Ilia Mirkin 
> Reviewed-by: Nicolai Hähnle 
> 
> Looks like some numerical issue then, albeit I don't know if the game is at
> fault here.

Apologies for the trouble.

The main difference between IEEE and non-IEEE is whether 0 * infinity = 0 or
NaN. IEEE makes it mean NaN. DX9 behavior is 0. I added a flag to be used by
st/nine to enable the DX9 behavior optionally, but leave the IEEE behavior for
GLSL. (There was some additional desire to expose that in a GL ext for WINE to
use, but it got shot down pretty quickly.)

Perhaps there are other changes from using the IEEE instruction variants, e.g.
denorms, which would be undesirable. I was never too familiar with the R600
ISA.

-- 
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 103544] Graphical glitches r600 in game this war of mine linux native

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

--- Comment #5 from Roland Scheidegger  ---
I've actually got that game myself here.
So I did the bisect and the winner is:
ce7a045feeef8cad155f1c9aa07f166e146e3d00 is the first bad commit
commit ce7a045feeef8cad155f1c9aa07f166e146e3d00
Author: Ilia Mirkin 
Date:   Mon Jan 23 20:53:50 2017 -0500

r600g: use ieee variants of multiplication instructions

This matches the behavior of most other drivers, including nouveau,
radeonsi, and i965.

Signed-off-by: Ilia Mirkin 
Reviewed-by: Nicolai Hähnle 

Looks like some numerical issue then, albeit I don't know if the game is at
fault here.

-- 
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


[radeon-alex:sound-for-next-stoney 1/3] acp-pcm-dma.c:undefined reference to `__umoddi3'

2017-11-03 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git sound-for-next-stoney
head:   d01a736c0b1595c5e65b2f2b16fe2da87ec3bc4c
commit: 41f9cb7a4d2aaf31aad6a87278f028add9d2d1a6 [1/3] ASoC: amd: Report 
accurate hw_ptr during dma
config: i386-allyesconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 41f9cb7a4d2aaf31aad6a87278f028add9d2d1a6
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   sound/soc/amd/acp-pcm-dma.o: In function `acp_dma_pointer':
>> acp-pcm-dma.c:(.text+0x3d7): undefined reference to `__umoddi3'
   acp-pcm-dma.c:(.text+0x3fc): undefined reference to `__umoddi3'

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102507] WARNING: CPU: 1 PID: 336 at drivers/gpu/drm/drm_mode_object.c:237 drm_object_property_set_value+0x5d/0x70 [drm]

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

--- Comment #5 from Vedran Miletić  ---
Fixed for me with Nov 2 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


[Bug 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

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

Vedran Miletić  changed:

   What|Removed |Added

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

--- Comment #5 from Vedran Miletić  ---
Whoops, wrong bug.

-- 
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 103316] [Hawaii, FirePro, radeon] WARNING: CPU: 1 PID: 18632 at drivers/gpu/drm/ttm/ttm_page_alloc_dma.c:548 ttm_dma_free_pool.part.8+0x128/0x130 [ttm]

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

Vedran Miletić  changed:

   What|Removed |Added

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

--- Comment #4 from Vedran Miletić  ---
Fixed with yesterday's or today's 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


[radeon-alex:sound-for-next-stoney 2/3] ERROR: "__umoddi3" [sound/soc/amd/acp_audio_dma.ko] undefined!

2017-11-03 Thread kbuild test robot
tree:   git://people.freedesktop.org/~agd5f/linux.git sound-for-next-stoney
head:   d01a736c0b1595c5e65b2f2b16fe2da87ec3bc4c
commit: d22c814cbe57c05d8b21b83840dc5537f3b3ccff [2/3] ASoC: AMD: Make the 
driver name consistent across files
config: i386-randconfig-s0-201744 (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout d22c814cbe57c05d8b21b83840dc5537f3b3ccff
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

>> ERROR: "__umoddi3" [sound/soc/amd/acp_audio_dma.ko] undefined!

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

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

--- Comment #34 from Thomas Hellström  ---
(In reply to haro41 from comment #33)
> No freezes, works great for me.

Want to add a Tested-by: tag?

/Thomas

-- 
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 0/3] Fixes for AMD Stoney ACP audio

2017-11-03 Thread Alex Deucher
This patch set is just a couple fixes for the Audio CoProcessor (ACP)
on AMD Stoney platforms and a small general fix for the rt5645
codec driver.

The entire patch set can also be viewed here:
https://cgit.freedesktop.org/~agd5f/linux/log/?h=sound-for-next-stoney

Thanks!

Alex

Akshu Agrawal (2):
  ASoC: AMD: Make the driver name consistent across files
  ASoC: rt5645: Wait for 400msec before concluding on value of
RT5645_VENDOR_ID2

Vijendar Mukunda (1):
  ASoC: amd: Report accurate hw_ptr during dma

 sound/soc/amd/Makefile  |  4 +--
 sound/soc/amd/acp-pcm-dma.c | 77 -
 sound/soc/amd/acp.h | 10 ++
 sound/soc/codecs/rt5645.c   | 12 +++
 4 files changed, 73 insertions(+), 30 deletions(-)

-- 
2.5.5

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


[PATCH 3/3] ASoC: rt5645: Wait for 400msec before concluding on value of RT5645_VENDOR_ID2

2017-11-03 Thread Alex Deucher
From: Akshu Agrawal 

Minimum time required between power On of codec and read
of RT5645_VENDOR_ID2 is 400msec. We should wait and attempt
before erroring out.

BUG=b:66978383
TEST=Cold boot the device and check for sound device.

Signed-off-by: Akshu Agrawal 
Signed-off-by: Bard Liao 
Signed-off-by: Alex Deucher 
---
 sound/soc/codecs/rt5645.c | 12 
 1 file changed, 12 insertions(+)

diff --git a/sound/soc/codecs/rt5645.c b/sound/soc/codecs/rt5645.c
index 23cc2cb..2da0b33 100644
--- a/sound/soc/codecs/rt5645.c
+++ b/sound/soc/codecs/rt5645.c
@@ -55,6 +55,8 @@ MODULE_PARM_DESC(quirk, "RT5645 pdata quirk override");
 
 #define RT5645_HWEQ_NUM 57
 
+#define TIME_TO_POWER_MS 400
+
 static const struct regmap_range_cfg rt5645_ranges[] = {
{
.name = "PR",
@@ -3712,6 +3714,7 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
int ret, i;
unsigned int val;
struct regmap *regmap;
+   int timeout = TIME_TO_POWER_MS;
 
rt5645 = devm_kzalloc(>dev, sizeof(struct rt5645_priv),
GFP_KERNEL);
@@ -3786,6 +3789,15 @@ static int rt5645_i2c_probe(struct i2c_client *i2c,
}
regmap_read(regmap, RT5645_VENDOR_ID2, );
 
+   /*
+* Read for 400msec, as it is the interval required between
+* read and power On.
+*/
+   while (val != RT5645_DEVICE_ID && val != RT5650_DEVICE_ID && --timeout) 
{
+   msleep(1);
+   regmap_read(regmap, RT5645_VENDOR_ID2, );
+   }
+
switch (val) {
case RT5645_DEVICE_ID:
rt5645->regmap = devm_regmap_init_i2c(i2c, _regmap);
-- 
2.5.5

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


[PATCH 2/3] ASoC: AMD: Make the driver name consistent across files

2017-11-03 Thread Alex Deucher
From: Akshu Agrawal 

This fixes the issue of driver not getting auto loaded with
MODULE_ALIAS.
find /sys/devices -name modalias -print0 | xargs -0 grep 'audio'
/sys/devices/pci:00/:00:01.0/acp_audio_dma.0.auto/modalias:platform:acp_audio_dma

BUG=b:62103837
TEST=boot and check for device in lsmod

Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/678278
Tested-by: Jason Clinton 
Reviewed-by: Jason Clinton 
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/Makefile  | 4 ++--
 sound/soc/amd/acp-pcm-dma.c | 6 --
 2 files changed, 6 insertions(+), 4 deletions(-)

diff --git a/sound/soc/amd/Makefile b/sound/soc/amd/Makefile
index eed64ff..f07fd2e 100644
--- a/sound/soc/amd/Makefile
+++ b/sound/soc/amd/Makefile
@@ -1,5 +1,5 @@
-snd-soc-acp-pcm-objs   := acp-pcm-dma.o
+acp_audio_dma-objs := acp-pcm-dma.o
 snd-soc-acp-rt5645-mach-objs := acp-rt5645.o
 
-obj-$(CONFIG_SND_SOC_AMD_ACP) += snd-soc-acp-pcm.o
+obj-$(CONFIG_SND_SOC_AMD_ACP) += acp_audio_dma.o
 obj-$(CONFIG_SND_SOC_AMD_CZ_RT5645_MACH) += snd-soc-acp-rt5645-mach.o
diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index e19f281..13d040a 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -40,6 +40,8 @@
 #define ST_MAX_BUFFER (ST_PLAYBACK_MAX_PERIOD_SIZE * PLAYBACK_MAX_NUM_PERIODS)
 #define ST_MIN_BUFFER ST_MAX_BUFFER
 
+#define DRV_NAME "acp_audio_dma"
+
 static const struct snd_pcm_hardware acp_pcm_hardware_playback = {
.info = SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER | SNDRV_PCM_INFO_MMAP |
@@ -1189,7 +1191,7 @@ static struct platform_driver acp_dma_driver = {
.probe = acp_audio_probe,
.remove = acp_audio_remove,
.driver = {
-   .name = "acp_audio_dma",
+   .name = DRV_NAME,
.pm = _pm_ops,
},
 };
@@ -1200,4 +1202,4 @@ MODULE_AUTHOR("vijendar.muku...@amd.com");
 MODULE_AUTHOR("maruthi.bayyavar...@amd.com");
 MODULE_DESCRIPTION("AMD ACP PCM Driver");
 MODULE_LICENSE("GPL v2");
-MODULE_ALIAS("platform:acp-dma-audio");
+MODULE_ALIAS("platform:"DRV_NAME);
-- 
2.5.5

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


[PATCH 1/3] ASoC: amd: Report accurate hw_ptr during dma

2017-11-03 Thread Alex Deucher
From: Vijendar Mukunda 

Using hw register to read transmitted byte count and report
accordingly the hw pointer.

BUG=b:63121716
TEST=
modprobe snd-soc-acp-pcm.ko
modprobe snd-soc-acp-rt5645.ko
aplay 

Signed-off-by: Vijendar Mukunda 
Signed-off-by: Akshu Agrawal 
Reviewed-on: https://chromium-review.googlesource.com/659699
Commit-Ready: Akshu Agrawal 
Tested-by: Akshu Agrawal 
Reviewed-by: Jason Clinton 
Reviewed-on: https://chromium-review.googlesource.com/676627
Signed-off-by: Alex Deucher 
---
 sound/soc/amd/acp-pcm-dma.c | 71 -
 sound/soc/amd/acp.h | 10 +++
 2 files changed, 55 insertions(+), 26 deletions(-)

diff --git a/sound/soc/amd/acp-pcm-dma.c b/sound/soc/amd/acp-pcm-dma.c
index 73b58ee..e19f281 100644
--- a/sound/soc/amd/acp-pcm-dma.c
+++ b/sound/soc/amd/acp-pcm-dma.c
@@ -817,39 +817,48 @@ static int acp_dma_hw_free(struct snd_pcm_substream 
*substream)
return snd_pcm_lib_free_pages(substream);
 }
 
+static u64 acp_get_byte_count(void __iomem *acp_mmio, int stream)
+{
+   union acp_dma_count playback_dma_count;
+   union acp_dma_count capture_dma_count;
+   u64 bytescount = 0;
+
+   if (stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   playback_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_HIGH);
+   playback_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_TRANSMIT_BYTE_CNT_LOW);
+   bytescount = playback_dma_count.bytescount;
+   } else {
+   capture_dma_count.bcount.high = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_HIGH);
+   capture_dma_count.bcount.low  = acp_reg_read(acp_mmio,
+   mmACP_I2S_RECEIVED_BYTE_CNT_LOW);
+   bytescount = capture_dma_count.bytescount;
+   }
+   return bytescount;
+}
+
 static snd_pcm_uframes_t acp_dma_pointer(struct snd_pcm_substream *substream)
 {
-   u16 dscr;
-   u32 mul, dma_config, period_bytes;
+   u32 buffersize;
u32 pos = 0;
+   u64 bytescount = 0;
 
struct snd_pcm_runtime *runtime = substream->runtime;
struct audio_substream_data *rtd = runtime->private_data;
 
-   period_bytes = frames_to_bytes(runtime, runtime->period_size);
-   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
-   dscr = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CUR_DSCR_13);
+   buffersize = frames_to_bytes(runtime, runtime->buffer_size);
+   bytescount = acp_get_byte_count(rtd->acp_mmio, substream->stream);
 
-   if (dscr == PLAYBACK_START_DMA_DESCR_CH13)
-   mul = 0;
-   else
-   mul = 1;
-   pos =  (mul * period_bytes);
+   if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if (bytescount > rtd->renderbytescount)
+   bytescount = bytescount - rtd->renderbytescount;
+   pos =  bytescount % buffersize;
} else {
-   dma_config = acp_reg_read(rtd->acp_mmio, mmACP_DMA_CNTL_14);
-   if (dma_config != 0) {
-   dscr = acp_reg_read(rtd->acp_mmio,
-   mmACP_DMA_CUR_DSCR_14);
-   if (dscr == CAPTURE_START_DMA_DESCR_CH14)
-   mul = 1;
-   else
-   mul = 2;
-   pos = (mul * period_bytes);
-   }
-
-   if (pos >= (2 * period_bytes))
-   pos = 0;
-
+   if (bytescount > rtd->capturebytescount)
+   bytescount = bytescount - rtd->capturebytescount;
+   pos = bytescount % buffersize;
}
return bytes_to_frames(runtime, pos);
 }
@@ -904,6 +913,7 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
 {
int ret;
u32 loops = 1000;
+   u64 bytescount = 0;
 
struct snd_pcm_runtime *runtime = substream->runtime;
struct snd_soc_pcm_runtime *prtd = substream->private_data;
@@ -915,7 +925,11 @@ static int acp_dma_trigger(struct snd_pcm_substream 
*substream, int cmd)
case SNDRV_PCM_TRIGGER_START:
case SNDRV_PCM_TRIGGER_PAUSE_RELEASE:
case SNDRV_PCM_TRIGGER_RESUME:
+   bytescount = acp_get_byte_count(rtd->acp_mmio,
+   substream->stream);
if (substream->stream == SNDRV_PCM_STREAM_PLAYBACK) {
+   if (rtd->renderbytescount == 0)
+   rtd->renderbytescount = bytescount;

Re: [PATCH] drm/vc4: Convert timers to use timer_setup()

2017-11-03 Thread Eric Anholt
Kees Cook <keesc...@chromium.org> writes:

> On Mon, Oct 30, 2017 at 4:49 PM, Eric Anholt <e...@anholt.net> wrote:
>> Kees Cook <keesc...@chromium.org> writes:
>>
>>> In preparation for unconditionally passing the struct timer_list pointer to
>>> all timer callbacks, switch to using the new timer_setup() and from_timer()
>>> to pass the timer pointer explicitly.
>>
>> Reviewed and applied to drm-misc-next.  Thanks!
>
> Thanks!
>
> I happened to notice that this was in next-20171102, but missing in
> next-20171103. Did it get removed, or am I misunderstanding something?

I don't know.  It's in drm-misc-next, though, so it'll flow upstream
without my intervention.


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


[Git PULL] vmwgfx-fixes

2017-11-03 Thread Sinclair Yeh
Hi Dave,

The following changes since commit 25dd1aa3b4cf0c361147aa45ff4dd1d335259ac1:

  Merge branch 'linux-4.14' of git://github.com/skeggsb/linux into drm-fixes 
(2017-11-01 10:05:03 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~syeh/repos_linux drm-vmwgfx-fixes

for you to fetch changes up to cef75036c40408ba3bc308bcb00a3d440da713fc:

  drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue (2017-11-01 10:56:53 
-0700)


Arvind Yadav (1):
  drm/vmwgfx: constify vmw_fence_ops

Sinclair Yeh (1):
  drm/vmwgfx: Fix Ubuntu 17.10 Wayland black screen issue

 drivers/gpu/drm/vmwgfx/vmwgfx_drv.c   | 2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)



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


[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

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

--- Comment #33 from har...@gmx.de ---
No freezes, works great for me.

-- 
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] drm: i915: remove timeval users

2017-11-03 Thread Arnd Bergmann
struct timeval is deprecated because it cannot represent times
past 2038. In this driver, the only use of this structure is
to capture debug information. This is easily changed to ktime_t,
which we then format as needed when printing it later.

Signed-off-by: Arnd Bergmann 
---
 drivers/gpu/drm/i915/i915_drv.h   |  6 +++---
 drivers/gpu/drm/i915/i915_gpu_error.c | 25 ++---
 2 files changed, 17 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 72bb5b51035a..a407c673dd10 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -896,9 +896,9 @@ struct intel_display_error_state;
 
 struct i915_gpu_state {
struct kref ref;
-   struct timeval time;
-   struct timeval boottime;
-   struct timeval uptime;
+   ktime_t time;
+   ktime_t boottime;
+   ktime_t uptime;
 
struct drm_i915_private *i915;
 
diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 653fb69e7ecb..65f781e3b63f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -594,6 +594,7 @@ int i915_error_state_to_str(struct drm_i915_error_state_buf 
*m,
 {
struct drm_i915_private *dev_priv = m->i915;
struct drm_i915_error_object *obj;
+   struct timespec64 ts;
int i, j;
 
if (!error) {
@@ -604,12 +605,15 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
if (*error->error_msg)
err_printf(m, "%s\n", error->error_msg);
err_printf(m, "Kernel: " UTS_RELEASE "\n");
-   err_printf(m, "Time: %ld s %ld us\n",
-  error->time.tv_sec, error->time.tv_usec);
-   err_printf(m, "Boottime: %ld s %ld us\n",
-  error->boottime.tv_sec, error->boottime.tv_usec);
-   err_printf(m, "Uptime: %ld s %ld us\n",
-  error->uptime.tv_sec, error->uptime.tv_usec);
+   ts = ktime_to_timespec64(error->time);
+   err_printf(m, "Time: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
+   ts = ktime_to_timespec64(error->boottime);
+   err_printf(m, "Boottime: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
+   ts = ktime_to_timespec64(error->uptime);
+   err_printf(m, "Uptime: %lld s %ld us\n",
+  (s64)ts.tv_sec, ts.tv_nsec / NSEC_PER_USEC);
 
for (i = 0; i < ARRAY_SIZE(error->engine); i++) {
if (error->engine[i].hangcheck_stalled &&
@@ -1699,11 +1703,10 @@ static int capture(void *data)
 {
struct i915_gpu_state *error = data;
 
-   do_gettimeofday(>time);
-   error->boottime = ktime_to_timeval(ktime_get_boottime());
-   error->uptime =
-   ktime_to_timeval(ktime_sub(ktime_get(),
-  error->i915->gt.last_init_time));
+   error->time = ktime_get_real();
+   error->boottime = ktime_get_boottime();
+   error->uptime = ktime_sub(ktime_get(),
+ error->i915->gt.last_init_time);
 
error->params = i915_modparams;
 #define DUP(T, x, ...) dup_param(#T, >params.x);
-- 
2.9.0

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


[Bug 42117] R200 driver performance, UMS, all mesa versions from 7.6

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

--- Comment #17 from mirh  ---
xf86-video-ati 6.14.4 supposedly added KMS tiling
https://wiki.freedesktop.org/xorg/radeon/

Could this get performance back to a satisfactorily enough level that we can
consider this nonetheless fixed?

Or.. Why here instead the thing is still crossed out?
https://www.x.org/wiki/RadeonFeature/

-- 
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 v2 1/7] drm/bridge: tc358767: do no fail on hi-res displays

2017-11-03 Thread Andrey Gusakov
Do not fail data rates higher than 2.7 and more than 2 lanes.
Try to fall back to 2.7Gbps and 2 lanes.
---
 drivers/gpu/drm/bridge/tc358767.c |   14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 8571cfd..d52cd41 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -603,8 +603,15 @@ static int tc_get_display_props(struct tc_data *tc)
ret = drm_dp_link_probe(>aux, >link.base);
if (ret < 0)
goto err_dpcd_read;
-   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27))
-   goto err_dpcd_inval;
+   if ((tc->link.base.rate != 162000) && (tc->link.base.rate != 27)) {
+   dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
+   tc->link.base.rate = 27;
+   }
+
+   if (tc->link.base.num_lanes > 2) {
+   dev_dbg(tc->dev, "Falling to 2 lanes\n");
+   tc->link.base.num_lanes = 2;
+   }
 
ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, tmp);
if (ret < 0)
@@ -637,9 +644,6 @@ static int tc_get_display_props(struct tc_data *tc)
 err_dpcd_read:
dev_err(tc->dev, "failed to read DPCD: %d\n", ret);
return ret;
-err_dpcd_inval:
-   dev_err(tc->dev, "invalid DPCD\n");
-   return -EINVAL;
 }
 
 static int tc_set_video_mode(struct tc_data *tc, struct drm_display_mode *mode)
-- 
1.7.10.4

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


[PATCH v2 4/7] drm/bridge: tc358767: fix timing calculations

2017-11-03 Thread Andrey Gusakov
Fields in HTIM01 and HTIM02 regs should be even.
Recomended thresh_dly value is max_tu_symbol.
---
 drivers/gpu/drm/bridge/tc358767.c |   34 --
 1 file changed, 20 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 90d6b49..319d582 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -659,6 +659,14 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
int lower_margin = mode->vsync_start - mode->vdisplay;
int vsync_len = mode->vsync_end - mode->vsync_start;
 
+   /*
+* Recommended maximum number of symbols transferred in a transfer unit:
+* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
+*  (output active video bandwidth in bytes))
+* Must be less than tu_size.
+*/
+   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
+
dev_dbg(tc->dev, "set mode %dx%d\n",
mode->hdisplay, mode->vdisplay);
dev_dbg(tc->dev, "H margin %d,%d sync %d\n",
@@ -668,13 +676,18 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
dev_dbg(tc->dev, "total: %dx%d\n", mode->htotal, mode->vtotal);
 
 
-   /* LCD Ctl Frame Size */
-   tc_write(VPCTRL0, (0x40 << 20) /* VSDELAY */ |
+   /*
+* LCD Ctl Frame Size
+* datasheet is not clear of vsdelay in case of DPI
+* assume we do not need any delay when DPI is a source of
+* sync signals
+*/
+   tc_write(VPCTRL0, (0 << 20) /* VSDELAY */ |
 OPXLFMT_RGB888 | FRMSYNC_DISABLED | MSF_DISABLED);
-   tc_write(HTIM01, (left_margin << 16) |  /* H back porch */
-(hsync_len << 0)); /* Hsync */
-   tc_write(HTIM02, (right_margin << 16) | /* H front porch */
-(mode->hdisplay << 0));/* width */
+   tc_write(HTIM01, (ALIGN(left_margin, 2) << 16) | /* H back porch */
+(ALIGN(hsync_len, 2) << 0));/* Hsync */
+   tc_write(HTIM02, (ALIGN(right_margin, 2) << 16) |  /* H front porch */
+(ALIGN(mode->hdisplay, 2) << 0)); /* width */
tc_write(VTIM01, (upper_margin << 16) | /* V back porch */
 (vsync_len << 0)); /* Vsync */
tc_write(VTIM02, (lower_margin << 16) | /* V front porch */
@@ -693,7 +706,7 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
/* DP Main Stream Attributes */
vid_sync_dly = hsync_len + left_margin + mode->hdisplay;
tc_write(DP0_VIDSYNCDELAY,
-(0x003e << 16) |   /* thresh_dly */
+(max_tu_symbol << 16) |/* thresh_dly */
 (vid_sync_dly << 0));
 
tc_write(DP0_TOTALVAL, (mode->vtotal << 16) | (mode->htotal));
@@ -709,13 +722,6 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
tc_write(DPIPXLFMT, VS_POL_ACTIVE_LOW | HS_POL_ACTIVE_LOW |
 DE_POL_ACTIVE_HIGH | SUB_CFG_TYPE_CONFIG1 | DPI_BPP_RGB888);
 
-   /*
-* Recommended maximum number of symbols transferred in a transfer unit:
-* DIV_ROUND_UP((input active video bandwidth in bytes) * tu_size,
-*  (output active video bandwidth in bytes))
-* Must be less than tu_size.
-*/
-   max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
   BPC_8);
 
-- 
1.7.10.4

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


[PATCH v2 2/7] drm/bridge: tc358767: filter out too high modes

2017-11-03 Thread Andrey Gusakov
Minimum pixel clock period is 6.5 nS for DPI. Do not accept  modes
with lower pixel clock period.
---
 drivers/gpu/drm/bridge/tc358767.c |5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index d52cd41..7f9c2e0 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -1103,7 +1103,10 @@ static bool tc_bridge_mode_fixup(struct drm_bridge 
*bridge,
 static int tc_connector_mode_valid(struct drm_connector *connector,
   struct drm_display_mode *mode)
 {
-   /* Accept any mode */
+   /* PCLK limitation = 6.5 nS */
+   if (mode->clock > 154000)
+   return MODE_CLOCK_HIGH;
+
return MODE_OK;
 }
 
-- 
1.7.10.4

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


[PATCH v2 3/7] drm/bridge: tc358767: fix DP0_MISC register set

2017-11-03 Thread Andrey Gusakov
Remove shift from TU_SIZE_RECOMMENDED define as it used to
calculate max_tu_symbols.
---
 drivers/gpu/drm/bridge/tc358767.c |5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 7f9c2e0..90d6b49 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -97,7 +97,7 @@
 #define DP0_ACTIVEVAL  0x0650
 #define DP0_SYNCVAL0x0654
 #define DP0_MISC   0x0658
-#define TU_SIZE_RECOMMENDED(0x3f << 16) /* LSCLK cycles per TU */
+#define TU_SIZE_RECOMMENDED(63) /* LSCLK cycles per TU */
 #define BPC_6  (0 << 5)
 #define BPC_8  (1 << 5)
 
@@ -716,7 +716,8 @@ static int tc_set_video_mode(struct tc_data *tc, struct 
drm_display_mode *mode)
 * Must be less than tu_size.
 */
max_tu_symbol = TU_SIZE_RECOMMENDED - 1;
-   tc_write(DP0_MISC, (max_tu_symbol << 23) | TU_SIZE_RECOMMENDED | BPC_8);
+   tc_write(DP0_MISC, (max_tu_symbol << 23) | (TU_SIZE_RECOMMENDED << 16) |
+  BPC_8);
 
return 0;
 err:
-- 
1.7.10.4

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


[PATCH v2 7/7] drm/bridge: tc358767: add copyright lines

2017-11-03 Thread Andrey Gusakov
Add copyright lines for Zodiac who paid for driver development.

Signed-off-by: Andrey Gusakov 
---
 drivers/gpu/drm/bridge/tc358767.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 1e677be..d98d717 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -6,6 +6,8 @@
  *
  * Copyright (C) 2016 Pengutronix, Philipp Zabel 
  *
+ * Copyright (C) 2016 Zodiac Inflight Innovations
+ *
  * Initially based on: drivers/gpu/drm/i2c/tda998x_drv.c
  *
  * Copyright (C) 2012 Texas Instruments
-- 
1.7.10.4

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


[PATCH v2 5/7] drm/bridge: tc358767: fix AUXDATAn registers access

2017-11-03 Thread Andrey Gusakov
First four bytes should go to DP0_AUXWDATA0. Due to bug if
len > 4 first four bytes was writen to DP0_AUXWDATA1 and all
data get shifted by 4 bytes. Fix it.
---
 drivers/gpu/drm/bridge/tc358767.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 319d582..4394131 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -318,7 +318,7 @@ static ssize_t tc_aux_transfer(struct drm_dp_aux *aux,
tmp = (tmp << 8) | buf[i];
i++;
if (((i % 4) == 0) || (i == size)) {
-   tc_write(DP0_AUXWDATA(i >> 2), tmp);
+   tc_write(DP0_AUXWDATA((i - 1) >> 2), tmp);
tmp = 0;
}
}
-- 
1.7.10.4

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


[PATCH v2 6/7] drm/bridge: tc358767: fix 1-lane behavior

2017-11-03 Thread Andrey Gusakov
Use drm_dp_channel_eq_ok helper
---
 drivers/gpu/drm/bridge/tc358767.c |   13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/bridge/tc358767.c 
b/drivers/gpu/drm/bridge/tc358767.c
index 4394131..1e677be 100644
--- a/drivers/gpu/drm/bridge/tc358767.c
+++ b/drivers/gpu/drm/bridge/tc358767.c
@@ -819,8 +819,6 @@ static int tc_main_link_setup(struct tc_data *tc)
unsigned int rate;
u32 dp_phy_ctrl;
int timeout;
-   bool aligned;
-   bool ready;
u32 value;
int ret;
u8 tmp[8];
@@ -965,16 +963,15 @@ static int tc_main_link_setup(struct tc_data *tc)
ret = drm_dp_dpcd_read_link_status(aux, tmp + 2);
if (ret < 0)
goto err_dpcd_read;
-   ready = (tmp[2] == ((DP_CHANNEL_EQ_BITS << 4) | /* Lane1 */
-DP_CHANNEL_EQ_BITS));  /* Lane0 */
-   aligned = tmp[4] & DP_INTERLANE_ALIGN_DONE;
-   } while ((--timeout) && !(ready && aligned));
+   } while ((--timeout) &&
+!(drm_dp_channel_eq_ok(tmp + 2,  tc->link.base.num_lanes)));
 
if (timeout == 0) {
/* Read DPCD 0x200-0x201 */
ret = drm_dp_dpcd_read(aux, DP_SINK_COUNT, tmp, 2);
if (ret < 0)
goto err_dpcd_read;
+   dev_err(dev, "channel(s) EQ not ok\n");
dev_info(dev, "0x0200 SINK_COUNT: 0x%02x\n", tmp[0]);
dev_info(dev, "0x0201 DEVICE_SERVICE_IRQ_VECTOR: 0x%02x\n",
 tmp[1]);
@@ -985,10 +982,6 @@ static int tc_main_link_setup(struct tc_data *tc)
dev_info(dev, "0x0206 ADJUST_REQUEST_LANE0_1: 0x%02x\n",
 tmp[6]);
 
-   if (!ready)
-   dev_err(dev, "Lane0/1 not ready\n");
-   if (!aligned)
-   dev_err(dev, "Lane0/1 not aligned\n");
return -EAGAIN;
}
 
-- 
1.7.10.4

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


[PATCH v2 0/7] drm/bridge: tc358767: fixes and improvements (resend)

2017-11-03 Thread Andrey Gusakov
This set of patches fixes several issues that was found during testing
tc358767 with desktop DisplayPort displays.

Changes in V2:
- fixed maximum pixelclock frequency
- copyright patch added

Andrey Gusakov (7):
  drm/bridge: tc358767: do no fail on hi-res displays
  drm/bridge: tc358767: filter out too high modes
  drm/bridge: tc358767: fix DP0_MISC register set
  drm/bridge: tc358767: fix timing calculations
  drm/bridge: tc358767: fix AUXDATAn registers access
  drm/bridge: tc358767: fix 1-lane behavior
  drm/bridge: tc358767: add copyright lines

 drivers/gpu/drm/bridge/tc358767.c |   75 +
 1 file changed, 42 insertions(+), 33 deletions(-)

-- 
1.7.10.4

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


[ANNOUNCE] libdrm 2.4.88

2017-11-03 Thread Marek Olšák

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


libdrm 2.4.88 has been released.


Andrey Grodzovsky (1):
  amdgpu: Fix wrappers for AMDGPU_VM IOCTL.

Marek Olšák (1):
  configure.ac: bump version for release

git tag: libdrm-2.4.88

https://dri.freedesktop.org/libdrm/libdrm-2.4.88.tar.bz2
MD5:  fe4d5c77f1468ee73d0bbb30d76945d7  libdrm-2.4.88.tar.bz2
SHA1: 9cac721d33eb1e65a89a764cb71a7a63ceb6d7c1  libdrm-2.4.88.tar.bz2
SHA256: b5e55dbac2124e742e639f5b8553e8b7395863bf73dab4f77e99fe2fc25572b5  
libdrm-2.4.88.tar.bz2
SHA512: 
0d9d4bcc0d9be1fb6b1ca075339b22b0f927288a4c02bbcbf95406b5c095051890f3d2e0d32e529ef9b6952ce1250afd1e0765ad3188c2bac924dda8c33afabb
  libdrm-2.4.88.tar.bz2
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.88.tar.bz2.sig

https://dri.freedesktop.org/libdrm/libdrm-2.4.88.tar.gz
MD5:  090c1a93d92a1549df2514de0566cd50  libdrm-2.4.88.tar.gz
SHA1: 4c187a55ce622c623491c6f873fc672a96b60a15  libdrm-2.4.88.tar.gz
SHA256: a8b458db6a73c717baee2e249d39511fb6f5c0f5f24dee2770935eddeda1a017  
libdrm-2.4.88.tar.gz
SHA512: 
126ae9bb2f3ea45a90d46792a083db44a6ca550ca71697272dfc480f536377749c8f6ae6d92464537d0720bd058dc9a23f34c8e35043472a7a279193b1512abc
  libdrm-2.4.88.tar.gz
PGP:  https://dri.freedesktop.org/libdrm/libdrm-2.4.88.tar.gz.sig

-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQEcBAEBAgAGBQJZ/J3ZAAoJEP3RXVrO8PKxIPwH/0kaRQ7ZBdw7NFPTRRr12Fml
EWbJN2RWqI7SlosEHAl/P2LPtvnnwVibLv6o4ZaosPLJn/uCdAU3IVYDQ4icUI65
v+ZQqKDTo08n9xZJcwaF8xWGpM5jh5c0eJs8dlytBi8pqJW+YEZg5TaY9et369hU
w5iBRYnsnO3qzE44OVKtCgUZXjGXsLCZ8kiE7T249QzfLXWZYmxwdClgZz5S4/Kq
MyidYv8k12VcCEX7egKlhXdrdHOLZEblHTk62UQRteVGYjlaw/Qy4fFmyAAOPdp4
iMabQhzSCCBHZqgkL+MG/BTLbtLfR/PHsineC++TZK+JlQ7tbskE/GVqS0ZszYo=
=CyiB
-END PGP SIGNATURE-
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 29322] Very slow rendering with UMS on radeon 9000 AGP (rv250)

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

--- Comment #4 from mirh  ---
Would say this is a duplicate of bug 42117 ?

-- 
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 92790] Radeon.mst error

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

--- Comment #5 from Adrian  ---
It still doesn't work on Ubuntu 17.10 (4.13.0-16-lowlatency).

-- 
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 103544] Graphical glitches r600 in game this war of mine linux native

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

--- Comment #4 from Roland Scheidegger  ---
(In reply to Vitalii from comment #3)
> (In reply to Emil Velikov from comment #1)
> > Vitalii can you bisect Mesa to the commit that broke the game? There aren't
> > many developer working on r600 - so this would be greatly beneficial.
> 
> tell me how and what to do and I'll try

git bisect is easy, albeit building 32bit mesa on a 64bit distro might be
somewhere from challenging to near impossible depending on the distro...
You just do
git bisect start (probably on mesa master branch, but 17.2 branch should work
too)
git bisect good ___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


[Bug 102885] regression - 17.2 sparkle grid in shadows

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

--- Comment #10 from Thomas J. Moore  ---
(In reply to Samuel Pitoiset from comment #9)
> No, the bug should be fixed. I just didn't have much time to work on it to
> be honest.

OK, no hurry.  It's not like it's corrupting memory or anything, and the
workaround does work.  I was just concerned it would never be fixed.

-- 
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 103562] QXL driver disables IRQ and locks up when starting multihead weston, kernel 4.13

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

Vasilis LIaskovitis  changed:

   What|Removed |Added

Version|XOrg git|unspecified

-- 
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 103562] QXL driver disables IRQ and locks up when starting multihead weston, kernel 4.13

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

Bug ID: 103562
   Summary: QXL driver disables IRQ and locks up when starting
multihead weston, kernel 4.13
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/other
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: vliaskovi...@suse.com

Kernel 4.13.9
Weston 3.0.0-1.1

The qxl driver has its IRQ disabled (and the screen locks up not suprisingly)
when trying to start weston on a VM with dual-head qxl setup. Video card config
of vm:


  
  


Same dual-head setup works for gnome-shell/mutter though. So I am not sure if
DRI/drm is the correct product/component.

These are the kernel messages seen when weston is started:

[   66.719393] irq 11: nobody cared (try booting with the "irqpoll" option)
[   66.719396] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.13.9-1-default #1
[   66.719397] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.0.0-prebuilt.qemu-project.org 04/01/2014
[   66.719397] Call Trace:
[   66.719404]  
[   66.719408]  dump_stack+0x5c/0x85
[   66.719423]  __report_bad_irq+0x33/0xc0
[   66.719424]  note_interrupt+0x244/0x290
[   66.719425]  handle_irq_event_percpu+0x44/0x50
[   66.719426]  handle_irq_event+0x3a/0x60
[   66.719428]  handle_fasteoi_irq+0x8c/0x150
[   66.719429]  handle_irq+0x19/0x30
[   66.719430]  do_IRQ+0x41/0xc0
[   66.719432]  common_interrupt+0x8c/0x8c
[   66.719433] RIP: 0010:__do_softirq+0x6d/0x2da
[   66.719434] RSP: 0018:98a4bfd03f80 EFLAGS: 0206 ORIG_RAX:
ff2e
[   66.719435] RAX: 00019ec0 RBX:  RCX:
00200042
[   66.719436] RDX: 0047 RSI: bf861cc4 RDI:
06e0
[   66.719436] RBP: 0002 R08: 0023af4b5043 R09:
0020
[   66.719437] R10: 0004 R11: 01d8 R12:

[   66.719437] R13:  R14:  R15:

[   66.719440]  ? hrtimer_interrupt+0x116/0x1f0
[   66.719442]  irq_exit+0xae/0xb0
[   66.719443]  smp_apic_timer_interrupt+0x39/0x50
[   66.719444]  apic_timer_interrupt+0x8c/0xa0
[   66.719445]  
[   66.719446] RIP: 0010:native_safe_halt+0x2/0x10
[   66.719447] RSP: 0018:a6c0c0697ee0 EFLAGS: 0246 ORIG_RAX:
ff10
[   66.719448] RAX:  RBX: b6d573e0 RCX:

[   66.719448] RDX:  RSI:  RDI:

[   66.719448] RBP: 0002 R08: 0023ad4d9a22 R09:
98a49a797f00
[   66.719449] R10:  R11: 00dcc76ca5fb R12:

[   66.719449] R13:  R14:  R15:

[   66.719451]  default_idle+0x1a/0x130
[   66.719453]  do_idle+0x167/0x1e0
[   66.719454]  cpu_startup_entry+0x5f/0x70
[   66.719456]  start_secondary+0x146/0x170
[   66.719458]  secondary_startup_64+0x9f/0xa0
[   66.719459] handlers:
[   66.719466] [] usb_hcd_irq [usbcore]
[   66.719468] [] qxl_irq_handler [qxl]
[   66.719472] [] usb_hcd_irq [usbcore]
[   66.719473] Disabling IRQ #11
[   83.163774] [drm:drm_atomic_helper_swap_state [drm_kms_helper]] *ERROR*
[CRTC:36:crtc-1] hw_done timed out
[   91.616818] [ cut here ]
[   91.616826] WARNING: CPU: 3 PID: 2176 at
../drivers/gpu/drm/drm_atomic_helper.c:1682
drm_atomic_helper_commit_hw_done+0x8a/0x90 [drm_kms_helper]
[   91.616826] Modules linked in: nls_utf8 isofs fuse joydev uinput af_packet
iscsi_ibft iscsi_boot_sysfs snd_hda_codec_generic crct10dif_pclmul xfs
crc32_pclmul ghash_clmulni_intel pcbc snd_hda_intel snd_hda_codec libcrc32c
snd_hda_core snd_hwdep snd_pcm ppdev snd_timer snd aesni_intel aes_x86_64
crypto_simd glue_helper cryptd parport_pc parport soundcore virtio_net button
serio_raw virtio_balloon qemu_fw_cfg i2c_piix4 pcspkr btrfs xor sr_mod cdrom
ata_generic raid6_pq floppy crc32c_intel virtio_blk ata_piix virtio_rng qxl
uhci_hcd drm_kms_helper syscopyarea sysfillrect sysimgblt fb_sys_fops ttm
ehci_pci ehci_hcd drm usbcore sg
[   91.616846] CPU: 3 PID: 2176 Comm: kworker/u8:7 Not tainted 4.13.9-1-default
#1
[   91.616847] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.0.0-prebuilt.qemu-project.org 04/01/2014
[   91.616851] Workqueue: events_unbound commit_work [drm_kms_helper]
[   91.616852] task: 98a43934a000 task.stack: a6c0c246
[   91.616855] RIP: 0010:drm_atomic_helper_commit_hw_done+0x8a/0x90
[drm_kms_helper]
[   91.616856] RSP: 0018:a6c0c2463e40 EFLAGS: 00010286
[   91.616856] RAX: 98a4293f7400 RBX: 98a422711700 RCX:
98a4b9ce8000
[   91.616857] RDX: 98a4291b5a00 RSI: 98a422711700 RDI:
98a4b510f800
[   91.616857] RBP: 0001 R08:  R09:
98a4b7457000
[   91.616858] R10: 0003 R11: f006 R12:

Re: [PATCH] exynos: drm: use monotonic timestamps

2017-11-03 Thread Tobias Jakobi
Hello Arnd,

I guess you could coordinate the IPP changes with Marek, who is rewriting the
IPP subsystem anyway (added Marek to Cc).

Here is the most recent IPPv2 series:
https://www.spinics.net/lists/linux-samsung-soc/msg61066.html

Concerning the G2D changes, I don't think anything in userspace uses the
timestamps (e.g. for synchronisation).

With best wishes,
Tobias


Arnd Bergmann wrote:
> The exynos DRM driver uses real-time 'struct timeval' values
> for exporting its timestamps to user space. This has multiple
> problems:
> 
> 1. signed seconds overflow in y2038
> 2. the 'struct timeval' definition is deprecated in the kernel
> 3. time may jump or go backwards after a 'settimeofday()' syscall
> 4. other DRM timestamps are in CLOCK_MONOTONIC domain, so they
>can't be compared
> 5. exporting microseconds requires a division by 1000, which may
>be slow on some architectures.
> 
> Ideally timestamps should just use 64-bit nanoseconds instead, but
> of course we can't change that now. Instead, this tries to address
> the first four points above by using monotonic 'timespec' values.
> 
> The downside is that there is a small risk of breaking user space
> if that expects the absolute timestamp numbers to relate to the
> result of 'gettimeofday()'. Please review the user space driver
> before applying this patch to ensure this works.
> 
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/exynos/exynos_drm_g2d.c | 6 +++---
>  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 8 
>  2 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_g2d.c 
> b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> index 2b8bf2dd6387..9effe40f5fa5 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_g2d.c
> @@ -926,7 +926,7 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   struct drm_device *drm_dev = g2d->subdrv.drm_dev;
>   struct g2d_runqueue_node *runqueue_node = g2d->runqueue_node;
>   struct drm_exynos_pending_g2d_event *e;
> - struct timeval now;
> + struct timespec64 now;
>  
>   if (list_empty(_node->event_list))
>   return;
> @@ -934,9 +934,9 @@ static void g2d_finish_event(struct g2d_data *g2d, u32 
> cmdlist_no)
>   e = list_first_entry(_node->event_list,
>struct drm_exynos_pending_g2d_event, base.link);
>  
> - do_gettimeofday();
> + ktime_get_ts64();
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.cmdlist_no = cmdlist_no;
>  
>   drm_send_event(drm_dev, >base);
> diff --git a/drivers/gpu/drm/exynos/exynos_drm_ipp.c 
> b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> index 3edda18cc2d2..3f9d8d79bbde 100644
> --- a/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> +++ b/drivers/gpu/drm/exynos/exynos_drm_ipp.c
> @@ -1406,7 +1406,7 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
> *ippdrv,
>   struct drm_exynos_ipp_queue_buf qbuf;
>   struct drm_exynos_ipp_send_event *e;
>   struct list_head *head;
> - struct timeval now;
> + struct timespec64 now;
>   u32 tbuf_id[EXYNOS_DRM_OPS_MAX] = {0, };
>   int ret, i;
>  
> @@ -1509,10 +1509,10 @@ static int ipp_send_event(struct exynos_drm_ippdrv 
> *ippdrv,
>   e = list_first_entry(_node->event_list,
>   struct drm_exynos_ipp_send_event, base.link);
>  
> - do_gettimeofday();
> - DRM_DEBUG_KMS("tv_sec[%ld]tv_usec[%ld]\n", now.tv_sec, now.tv_usec);
> + ktime_get_ts64();
> + DRM_DEBUG_KMS("tv_sec[%lld]tv_nsec[%ld]\n", (s64)now.tv_sec, 
> now.tv_nsec);
>   e->event.tv_sec = now.tv_sec;
> - e->event.tv_usec = now.tv_usec;
> + e->event.tv_usec = now.tv_nsec / NSEC_PER_USEC;
>   e->event.prop_id = property->prop_id;
>  
>   /* set buffer id about source destination */
> 

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


Re: [PATCH libdrm] exynos: change the license to X11/MIT

2017-11-03 Thread Emil Velikov
On 3 November 2017 at 13:59, Tobias Jakobi
 wrote:
> Inki Dae wrote:
>> Hi Email,
>>
>> Since I posted this patch, much time has been passed.
>> But no answer. We got already many Acked-by so could you merge this patch?
> I think you need Acked-by by all authors. And it looks like you ignored my 
> comments.
>
Thanks for the poke guys, I've forgot about this.

I'll copy the justification (thank for the link Tobias) + address the
typos before pushing in a few minutes.

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


[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

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

--- Comment #32 from Thomas Hellström  ---
Slightly polished patch available here...


https://lists.freedesktop.org/archives/mesa-dev/2017-November/175373.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


Re: [PATCH libdrm] exynos: change the license to X11/MIT

2017-11-03 Thread Tobias Jakobi
Inki Dae wrote:
> Hi Email,
> 
> Since I posted this patch, much time has been passed.
> But no answer. We got already many Acked-by so could you merge this patch?
I think you need Acked-by by all authors. And it looks like you ignored my 
comments.

- Tobias


> 
> Thanks,
> Inki Dae
> 
> 
> 2017년 08월 10일 13:52에 Inki Dae 이(가) 쓴 글:
>> Chnage GPL license of Exynos relevant code to X11/MIT.
>>
>> I'd like to keep license consistency to all Exynos code
>> because License checker notices two more licenses exist
>> in libdrm.
>>
>> For the license change I need to get your agree - all committers.
>> So please give me Acked-by if you agree with me.
>>
>> Signed-off-by: Inki Dae 
>> Acked-by: Hyungwon Hwang 
>> Acked-by: SooChan Lim 
>> Acked-by: Sangjin LEE 
>> Acked-by: Boram Park 
>> Acked-by: Seung-Woo Kim 
>> Acked-by: Joonyoung Shim 
>> Acked-by: Emil Velikov 
>> ---
>>  exynos/exynos_fimg2d.c | 21 +
>>  exynos/exynos_fimg2d.h | 21 +
>>  exynos/fimg2d_reg.h| 21 +
>>  libkms/exynos.c| 22 ++
>>  tests/exynos/exynos_fimg2d_event.c | 27 +--
>>  tests/exynos/exynos_fimg2d_perf.c  | 27 +--
>>  tests/exynos/exynos_fimg2d_test.c  | 21 +
>>  7 files changed, 120 insertions(+), 40 deletions(-)
>>
>> diff --git a/exynos/exynos_fimg2d.c b/exynos/exynos_fimg2d.c
>> index 61340c3..5658a48 100644
>> --- a/exynos/exynos_fimg2d.c
>> +++ b/exynos/exynos_fimg2d.c
>> @@ -3,11 +3,24 @@
>>   * Authors:
>>   *  Inki Dae 
>>   *
>> - * This program is free software; you can redistribute  it and/or modify it
>> - * under  the terms of  the GNU General  Public License as published by the
>> - * Free Software Foundation;  either version 2 of the  License, or (at your
>> - * option) any later version.
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>>   *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
>> + * OTHER DEALINGS IN THE SOFTWARE.
>>   */
>>  
>>  #ifdef HAVE_CONFIG_H
>> diff --git a/exynos/exynos_fimg2d.h b/exynos/exynos_fimg2d.h
>> index a825c68..a4dfbe7 100644
>> --- a/exynos/exynos_fimg2d.h
>> +++ b/exynos/exynos_fimg2d.h
>> @@ -3,11 +3,24 @@
>>   * Authors:
>>   *  Inki Dae 
>>   *
>> - * This program is free software; you can redistribute  it and/or modify it
>> - * under  the terms of  the GNU General  Public License as published by the
>> - * Free Software Foundation;  either version 2 of the  License, or (at your
>> - * option) any later version.
>> + * Permission is hereby granted, free of charge, to any person obtaining a
>> + * copy of this software and associated documentation files (the 
>> "Software"),
>> + * to deal in the Software without restriction, including without limitation
>> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
>> + * and/or sell copies of the Software, and to permit persons to whom the
>> + * Software is furnished to do so, subject to the following conditions:
>>   *
>> + * The above copyright notice and this permission notice (including the next
>> + * paragraph) shall be included in all copies or substantial portions of the
>> + * Software.
>> + *
>> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS 
>> OR
>> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
>> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
>> + * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
>> + * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
>> + * ARISING FROM, OUT OF OR IN CONNECTION WITH 

[PATCH 1/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00h-0fh) Processors

2017-11-03 Thread Christian König
From: Christian König 

Just add the extra PCI-ID to the existing fixup.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 7b6bd76..1d2238d 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -639,7 +639,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
quirk_apple_mbp_poweroff);
  * configuring host bridge windows using the _PRS and _SRS methods.
  *
  * But this is rarely implemented, so we manually enable a large 64bit BAR for
- * PCIe device on AMD Family 15h (Models 30h-3fh) Processors here.
+ * PCIe device on AMD Family 15h (Models 00h-0fh, 30h-3fh) Processors here.
  */
 static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 {
@@ -696,5 +696,6 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
pci_bus_add_resource(dev->bus, res, 0);
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
 
 #endif
-- 
2.7.4

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


[PATCH 4/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 70h-7fh) Processors

2017-11-03 Thread Christian König
Just add the extra PCI-ID to the existing fixup.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 3eebb0e..894d73d 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -639,7 +639,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
quirk_apple_mbp_poweroff);
  * configuring host bridge windows using the _PRS and _SRS methods.
  *
  * But this is rarely implemented, so we manually enable a large 64bit BAR for
- * PCIe device on AMD Family 15h (Models 00h-1fh, 30h-3fh, 60h-6fh) Processors
+ * PCIe device on AMD Family 15h (Models 00h-1fh, 30h-3fh, 60h-7fh) Processors
  * here.
  */
 static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
@@ -699,6 +699,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1401, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1571, pci_amd_enable_64bit_bar);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x15b1, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
 
 #endif
-- 
2.7.4

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


[PATCH 2/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 10h-1fh) Processors

2017-11-03 Thread Christian König
Just add the extra PCI-ID to the existing fixup.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 1d2238d..aa8b20e 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -639,7 +639,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
quirk_apple_mbp_poweroff);
  * configuring host bridge windows using the _PRS and _SRS methods.
  *
  * But this is rarely implemented, so we manually enable a large 64bit BAR for
- * PCIe device on AMD Family 15h (Models 00h-0fh, 30h-3fh) Processors here.
+ * PCIe device on AMD Family 15h (Models 00h-1fh, 30h-3fh) Processors here.
  */
 static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 {
@@ -695,6 +695,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 
pci_bus_add_resource(dev->bus, res, 0);
 }
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1401, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
 
-- 
2.7.4

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


[PATCH 3/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 60h-6fh) Processors

2017-11-03 Thread Christian König
Just add the extra PCI-ID to the existing fixup.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index aa8b20e..3eebb0e 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -639,7 +639,8 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
quirk_apple_mbp_poweroff);
  * configuring host bridge windows using the _PRS and _SRS methods.
  *
  * But this is rarely implemented, so we manually enable a large 64bit BAR for
- * PCIe device on AMD Family 15h (Models 00h-1fh, 30h-3fh) Processors here.
+ * PCIe device on AMD Family 15h (Models 00h-1fh, 30h-3fh, 60h-6fh) Processors
+ * here.
  */
 static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 {
@@ -697,6 +698,7 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1401, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1571, pci_amd_enable_64bit_bar);
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
 
 #endif
-- 
2.7.4

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


[PATCH 1/4] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 00h-0fh) Processors

2017-11-03 Thread Christian König
Just add the extra PCI-ID to the existing fixup.

Signed-off-by: Christian König 
---
 arch/x86/pci/fixup.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/pci/fixup.c b/arch/x86/pci/fixup.c
index 7b6bd76..1d2238d 100644
--- a/arch/x86/pci/fixup.c
+++ b/arch/x86/pci/fixup.c
@@ -639,7 +639,7 @@ DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, 0x8c10, 
quirk_apple_mbp_poweroff);
  * configuring host bridge windows using the _PRS and _SRS methods.
  *
  * But this is rarely implemented, so we manually enable a large 64bit BAR for
- * PCIe device on AMD Family 15h (Models 30h-3fh) Processors here.
+ * PCIe device on AMD Family 15h (Models 00h-0fh, 30h-3fh) Processors here.
  */
 static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
 {
@@ -696,5 +696,6 @@ static void pci_amd_enable_64bit_bar(struct pci_dev *dev)
pci_bus_add_resource(dev->bus, res, 0);
 }
 DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x141b, pci_amd_enable_64bit_bar);
+DECLARE_PCI_FIXUP_EARLY(PCI_VENDOR_ID_AMD, 0x1601, pci_amd_enable_64bit_bar);
 
 #endif
-- 
2.7.4

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


Re: [Advice Needed] splash on i.MX IPU

2017-11-03 Thread Stephan Bauroth

On 03.11.2017 13:57, PrasannaKumar Muralidharan wrote:

Hi,

On 3 November 2017 at 16:56, Stephan Bauroth  wrote:

Dear dri-devel, spec. Dear i.MX folks,

I would like to display a splash screen on an i.MX6 based board from the
kernel as soon as the display hardware is initialized. But I'm having
trouble finding some kind of 'take this buffer and display it' function
within the IPU driver. (And I see no way of specifying such thing within the
device tree)

I tried to trace a userspace write to /dev/fb0 to see where it ends up, but
didn't succeed in finding the right entry point. I am aware of the fact that
the bootloader typically displays a splash and linux then doesn't touch it,
but this solution is not feasible for me, mostly because it would include
duplicating the functionality of a display driver when the kernel offers a
working one.

Has anybody built a splash from the kernel before? Or can anyone give me a
few pointers where to look for a start within the driver? Any help is
appreciated.

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

Please take a look at
http://lkml.iu.edu/hypermail/linux/kernel/1710.3/01542.html. I think
your need is similar to this. The solution is not mainline yet.

Thanks,
PrasannaKumar

That indeed looks promising, I will look into it. Thanks!

Stephan

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


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


Re: [Advice Needed] splash on i.MX IPU

2017-11-03 Thread PrasannaKumar Muralidharan
Hi,

On 3 November 2017 at 16:56, Stephan Bauroth  wrote:
> Dear dri-devel, spec. Dear i.MX folks,
>
> I would like to display a splash screen on an i.MX6 based board from the
> kernel as soon as the display hardware is initialized. But I'm having
> trouble finding some kind of 'take this buffer and display it' function
> within the IPU driver. (And I see no way of specifying such thing within the
> device tree)
>
> I tried to trace a userspace write to /dev/fb0 to see where it ends up, but
> didn't succeed in finding the right entry point. I am aware of the fact that
> the bootloader typically displays a splash and linux then doesn't touch it,
> but this solution is not feasible for me, mostly because it would include
> duplicating the functionality of a display driver when the kernel offers a
> working one.
>
> Has anybody built a splash from the kernel before? Or can anyone give me a
> few pointers where to look for a start within the driver? Any help is
> appreciated.
>
> regards,
> Stephan
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

Please take a look at
http://lkml.iu.edu/hypermail/linux/kernel/1710.3/01542.html. I think
your need is similar to this. The solution is not mainline yet.

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


[Bug 103550] system boots really slow with 4.9.x kernel or greater (tested on 4.14 rc7)

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

Daniel Stone  changed:

   What|Removed |Added

Product|Wayland |DRI
  Component|wayland |DRM/AMDgpu
   Assignee|wayland-bugs@lists.freedesk |dri-devel@lists.freedesktop
   |top.org |.org

-- 
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 hwc] Android: add CleanSpec.mk

2017-11-03 Thread Rob Herring
On Thu, Nov 2, 2017 at 11:45 PM, Chih-Wei Huang  wrote:
> The file contains rules that are executed on incremental builds.
> Since commit 4f7dc9b6 the library was moved to /vendor so
> the old file must be removed.
>
> Signed-off-by: Chih-Wei Huang 
> ---
>  CleanSpec.mk | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 CleanSpec.mk
>
> diff --git a/CleanSpec.mk b/CleanSpec.mk
> new file mode 100644
> index 000..99dcecd
> --- /dev/null
> +++ b/CleanSpec.mk
> @@ -0,0 +1 @@
> +$(call add-clean-step, rm -rf $(TARGET_OUT)/lib*/hw/hwcomposer.drm.so)

Seems a bit silly to add forever an explicit file to clean for a
transient problem.

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


Re: [PATCH v4 5/9] drm/exynos: Add generic support for devices shared with V4L2 subsystem

2017-11-03 Thread Marek Szyprowski

Hi Inki,

On 2017-11-01 07:26, Inki Dae wrote:

2017년 10월 23일 16:54에 Marek Szyprowski 이(가) 쓴 글:

Some hardware modules, like FIMC in Exynos4 series are shared between
V4L2 (camera support) and DRM (memory-to-memory processing) subsystems.
This patch provides a simple check to let such drivers to be used in the
driver components framework.

Signed-off-by: Marek Szyprowski 
---
  drivers/gpu/drm/exynos/exynos_drm_drv.c | 17 -
  drivers/gpu/drm/exynos/exynos_drm_drv.h |  2 ++
  2 files changed, 18 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index cac0d84385d3..60ae6ae06eb2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -216,6 +216,7 @@ struct exynos_drm_driver_info {
  #define DRM_COMPONENT_DRIVER  BIT(0)  /* supports component framework */
  #define DRM_VIRTUAL_DEVICEBIT(1)  /* create virtual platform device */
  #define DRM_DMA_DEVICEBIT(2)  /* can be used for dma 
allocations */
+#define DRM_SHARED_DEVICE  BIT(3)  /* devices shared with V4L2 subsystem */
  
  #define DRV_PTR(drv, cond) (IS_ENABLED(cond) ?  : NULL)
  
@@ -267,6 +268,17 @@ static struct exynos_drm_driver_info exynos_drm_drivers[] = {

}
  };
  
+int exynos_drm_check_shared_device(struct device *dev)

+{
+   /*
+* Exynos DRM drivers handle only devices that support
+* the LCD Writeback data path, rest is handled by V4L2 driver
+*/
+   if (!of_property_read_bool(dev->of_node, "samsung,lcd-wb"))
+   return -ENODEV;
+   return 0;
+}
+
  static int compare_dev(struct device *dev, void *data)
  {
return dev == (struct device *)data;
@@ -288,7 +300,10 @@ static struct component_match *exynos_drm_match_add(struct 
device *dev)
>driver->driver,
(void *)platform_bus_type.match))) {
put_device(p);
-   component_match_add(dev, , compare_dev, d);
+
+   if (!(info->flags & DRM_SHARED_DEVICE) ||
+   exynos_drm_check_shared_device(d) == 0)
+   component_match_add(dev, , compare_dev, 
d);

Seems above line make fimc device driver to be bound only when fimc device node has 
"samsung,lcd-wb" property. However, Exynos DRM FIMC driver is able to various 
transfomations such as color space conversion, scaling up/down and rotation.
And this driver is used as mem to mem device driver. However, 'writeback' 
feature means 'dma to memory', which delivers one blended image in display 
controller into system memory.


This patch is only to bind fimc.2 and fimc.3 devices to DRM and fimc.0
and fimc.1 to V4L2. Exactly the same checks are in V4l2 and old DRM FIMC
drivers.



Thanks,
Inki Dae


p = d;
}
put_device(p);
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h 
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index b47f810d64d2..8b3b31d35168 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,6 +275,8 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
  }
  #endif
  
+int exynos_drm_check_shared_device(struct device *dev);

+
  int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state 
*state,
 bool nonblock);
  int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state 
*state);





Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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


[Advice Needed] splash on i.MX IPU

2017-11-03 Thread Stephan Bauroth

Dear dri-devel, spec. Dear i.MX folks,

I would like to display a splash screen on an i.MX6 based board from the 
kernel as soon as the display hardware is initialized. But I'm having 
trouble finding some kind of 'take this buffer and display it' function 
within the IPU driver. (And I see no way of specifying such thing within 
the device tree)


I tried to trace a userspace write to /dev/fb0 to see where it ends up, 
but didn't succeed in finding the right entry point. I am aware of the 
fact that the bootloader typically displays a splash and linux then 
doesn't touch it, but this solution is not feasible for me, mostly 
because it would include duplicating the functionality of a display 
driver when the kernel offers a working one.


Has anybody built a splash from the kernel before? Or can anyone give me 
a few pointers where to look for a start within the driver? Any help is 
appreciated.


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


Re: [PATCH v4 2/9] drm/exynos: ipp: Add IPP v2 framework

2017-11-03 Thread Marek Szyprowski



On 2017-11-01 02:13, Inki Dae wrote:

Hi Marek,

Thanks for your effort and sorry for late. Below are trivial my comments,

2017년 10월 23일 16:54에 Marek Szyprowski 이(가) 쓴 글:

This patch adds Exynos IPP v2 subsystem and userspace API.

New userspace API is focused ONLY on memory-to-memory image processing.
The two remainging IPP operation modes (framebuffer writeback and
local-path output with image processing) can be implemented using
standard DRM features: writeback connectors and additional DRM planes with
scaling features.

V2 IPP userspace API is not compatible with old IPP ioctls. This is a
significant change, but the old IPP subsystem in mainline Linux kernel was
partially disfunctional anyway and not used in any open-source project.

V2 IPP userspace API is based on stateless approach, which much better fits
to memory-to-memory image processing model. It also provides support for
all image formats, which are both already defined in DRM API and supported
by the existing IPP hardware modules.

The API consists of the following ioctls:
- DRM_IOCTL_EXYNOS_IPP_GET_RESOURCES: to enumerate all available image
   processing modules,
- DRM_IOCTL_EXYNOS_IPP_GET_CAPS: to query capabilities and supported image
   formats of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_GET_LIMITS: to query hardware limitiations for
   selected image format of given IPP module,
- DRM_IOCTL_EXYNOS_IPP_COMMIT: to perform operation described by the
   provided structures (source and destination buffers, operation rectangle,
   transformation, etc).

The proposed userspace API is extensible. In the future more advanced image
processing operations can be defined to support for example blending.

Userspace API is fully functional also on DRM render nodes, so it is not
limited to the root/privileged client.

Internal driver API also has been completely rewritten. New IPP core
performs all possible input validation, checks and object life-time
control. The drivers can focus only on writing configuration to hardware
registers. Stateless nature of DRM_IOCTL_EXYNOS_IPP_COMMIT ioctl simplifies
the driver API. Minimal driver needs to provide a single callback for
starting processing and an array with supported image formats.

Signed-off-by: Marek Szyprowski 
Tested-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/Kconfig  |   3 +
  drivers/gpu/drm/exynos/Makefile |   1 +
  drivers/gpu/drm/exynos/exynos_drm_drv.c |   9 +
  drivers/gpu/drm/exynos/exynos_drm_ipp.c | 911 
  drivers/gpu/drm/exynos/exynos_drm_ipp.h | 195 +++
  include/uapi/drm/exynos_drm.h   | 238 +
  6 files changed, 1357 insertions(+)
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.c
  create mode 100644 drivers/gpu/drm/exynos/exynos_drm_ipp.h

diff --git a/drivers/gpu/drm/exynos/Kconfig b/drivers/gpu/drm/exynos/Kconfig
index 88cff0e039b6..2e097a81df12 100644
--- a/drivers/gpu/drm/exynos/Kconfig
+++ b/drivers/gpu/drm/exynos/Kconfig
@@ -94,6 +94,9 @@ config DRM_EXYNOS_G2D
help
  Choose this option if you want to use Exynos G2D for DRM.
  
+config DRM_EXYNOS_IPP

+   bool
+
  config DRM_EXYNOS_FIMC
bool "FIMC"
depends on BROKEN && MFD_SYSCON
diff --git a/drivers/gpu/drm/exynos/Makefile b/drivers/gpu/drm/exynos/Makefile
index 09bb002c9555..f663490e949d 100644
--- a/drivers/gpu/drm/exynos/Makefile
+++ b/drivers/gpu/drm/exynos/Makefile
@@ -17,6 +17,7 @@ exynosdrm-$(CONFIG_DRM_EXYNOS_MIXER)  += exynos_mixer.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_HDMI)   += exynos_hdmi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_VIDI)   += exynos_drm_vidi.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_G2D)+= exynos_drm_g2d.o
+exynosdrm-$(CONFIG_DRM_EXYNOS_IPP) += exynos_drm_ipp.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_FIMC)   += exynos_drm_fimc.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_ROTATOR)+= exynos_drm_rotator.o
  exynosdrm-$(CONFIG_DRM_EXYNOS_GSC)+= exynos_drm_gsc.o
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c 
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index 2fc5d3c01390..de4cce258a5b 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -26,6 +26,7 @@
  #include "exynos_drm_fb.h"
  #include "exynos_drm_gem.h"
  #include "exynos_drm_plane.h"
+#include "exynos_drm_ipp.h"
  #include "exynos_drm_vidi.h"
  #include "exynos_drm_g2d.h"
  #include "exynos_drm_iommu.h"
@@ -114,6 +115,14 @@ static const struct drm_ioctl_desc exynos_ioctls[] = {
DRM_AUTH | DRM_RENDER_ALLOW),
DRM_IOCTL_DEF_DRV(EXYNOS_G2D_EXEC, exynos_g2d_exec_ioctl,
DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_RESOURCES, 
exynos_drm_ipp_get_res_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   DRM_IOCTL_DEF_DRV(EXYNOS_IPP_GET_CAPS, exynos_drm_ipp_get_caps_ioctl,
+   DRM_AUTH | DRM_RENDER_ALLOW),
+   

RE: [PATCH] drm/amdgpu/virt: don't dereference undefined 'module' struct

2017-11-03 Thread Yu, Xiangliang
Reviewed-By: Xiangliang Yu 

Thanks!

> -Original Message-
> From: Arnd Bergmann [mailto:a...@arndb.de]
> Sent: Thursday, November 02, 2017 7:26 PM
> To: Deucher, Alexander ; Koenig, Christian
> 
> Cc: Arnd Bergmann ; David Airlie ; Liu,
> Monk ; Yu, Xiangliang ;
> Chen, Horace ; amd-...@lists.freedesktop.org;
> dri-devel@lists.freedesktop.org; linux-ker...@vger.kernel.org
> Subject: [PATCH] drm/amdgpu/virt: don't dereference undefined 'module'
> struct
> 
> Accessing the THIS_MODULE directly is only possible when modules are
> enabled, otherwise we get a build failure:
> 
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c: In function
> 'amdgpu_virt_init_data_exchange':
> drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c:331:20: error: dereferencing
> pointer to incomplete type 'struct module'
> 
> Further, THIS_MODULE is NULL when the driver is built-in, so the code would
> likely cause a NULL pointer dereference.
> 
> This adds an #ifdef check to avoid the compile-time error, plus a NULL
> pointer check before dereferencing THIS_MODULE. It might be better to find
> a way to avoid using the module version altogether.
> 
> Fixes: 2dc8f81e4f82 ("drm/amdgpu: SR-IOV data exchange between PF")
> Signed-off-by: Arnd Bergmann 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> index e97f80f86005..4e4a476593e8 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_virt.c
> @@ -328,9 +328,11 @@ void amdgpu_virt_init_data_exchange(struct
> amdgpu_device *adev)
>   sizeof(amdgim_vf2pf_info));
>   AMDGPU_FW_VRAM_VF2PF_READ(adev,
> driver_version,
>   );
> +#ifdef MODULE
>   if (THIS_MODULE->version != NULL)
>   strcpy(str, THIS_MODULE->version);
>   else
> +#endif
>   strcpy(str, "N/A");
>   AMDGPU_FW_VRAM_VF2PF_WRITE(adev,
> driver_cert,
>   0);
> --
> 2.9.0

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


[Bug 196197] [drm:r600_ring_test [radeon]] *ERROR* radeon: ring 0 test failed (scratch(0x8504)=0xCAFEDEAD)

2017-11-03 Thread bugzilla-daemon
https://bugzilla.kernel.org/show_bug.cgi?id=196197

--- Comment #12 from Michel Dänzer (mic...@daenzer.net) ---
(In reply to Andreas Brogle from comment #7)
> The last 7 turns caused a kernel panic, all the 4.10.0-rc1 versions. I
> declared them as bad with git bisect.

In cases like this, where it's not possible to test a commit for the problem
being bisected, one needs to run

 git bisect skip

instead of "bad".


> 0fc1223f0e77a748f7040562faaa7027f7db71ca is the first bad commit
> commit 0fc1223f0e77a748f7040562faaa7027f7db71ca
> Author: Rajat Jain 
> Date:   Mon Jan 2 22:34:10 2017 -0800
> 
> PCI/ASPM: Add L1 substate capability structure register definitions

Does this commit boot and exhibit the problem? If so, does the previous commit
boot and not exhibit the problem?

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


Re: [PATCH 4/6] drm/fsl-dcu: Use drm_mode_config_helper_suspend/resume()

2017-11-03 Thread Noralf Trønnes


Den 02.11.2017 21.09, skrev Noralf Trønnes:

These helpers take care of output polling, fbdev and atomic state.

Cc: Stefan Agner 
Cc: Alison Wang 
Signed-off-by: Noralf Trønnes 
---
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c | 23 +--
  drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h |  1 -
  2 files changed, 5 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
index 58e9e0601a61..0738d9c6f1aa 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.c
@@ -27,6 +27,7 @@
  #include 
  #include 
  #include 
+#include 
  
  #include "fsl_dcu_drm_crtc.h"

  #include "fsl_dcu_drm_drv.h"
@@ -193,21 +194,11 @@ static int fsl_dcu_drm_pm_suspend(struct device *dev)
return 0;
  


Somehow I missed that ret wasn't declared here.

    int ret;

Will fix in the next version.

Noralf.


disable_irq(fsl_dev->irq);
-   drm_kms_helper_poll_disable(fsl_dev->drm);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 1);
-   console_unlock();
-
-   fsl_dev->state = drm_atomic_helper_suspend(fsl_dev->drm);
-   if (IS_ERR(fsl_dev->state)) {
-   console_lock();
-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
-
-   drm_kms_helper_poll_enable(fsl_dev->drm);
+   ret = drm_mode_config_helper_suspend(fsl_dev->drm);
+   if (ret) {
enable_irq(fsl_dev->irq);
-   return PTR_ERR(fsl_dev->state);
+   return ret;
}
  
  	clk_disable_unprepare(fsl_dev->pix_clk);

@@ -233,13 +224,9 @@ static int fsl_dcu_drm_pm_resume(struct device *dev)
if (fsl_dev->tcon)
fsl_tcon_bypass_enable(fsl_dev->tcon);
fsl_dcu_drm_init_planes(fsl_dev->drm);
-   drm_atomic_helper_resume(fsl_dev->drm, fsl_dev->state);
  
-	console_lock();

-   drm_fbdev_cma_set_suspend(fsl_dev->fbdev, 0);
-   console_unlock();
+   drm_mode_config_helper_resume(fsl_dev->drm);
  
-	drm_kms_helper_poll_enable(fsl_dev->drm);

enable_irq(fsl_dev->irq);
  
  	return 0;

diff --git a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h 
b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
index da9bfd432ca6..93bfb98012d4 100644
--- a/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
+++ b/drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_drv.h
@@ -196,7 +196,6 @@ struct fsl_dcu_drm_device {
struct drm_encoder encoder;
struct fsl_dcu_drm_connector connector;
const struct fsl_dcu_soc_data *soc;
-   struct drm_atomic_state *state;
  };
  
  int fsl_dcu_drm_modeset_init(struct fsl_dcu_drm_device *fsl_dev);


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


[PATCH 4.9.y 3/3] drm/bridge: adv7511: Re-write the i2c address before EDID probing

2017-11-03 Thread Nhan Nguyen
From: John Stultz 

commit 3587c856675c45809010c2cee5b21096f6e8e938 upstream.

I've found that by just turning the chip on and off via the
POWER_DOWN register, I end up getting i2c_transfer errors on
HiKey.

Investigating further, it turns out that some of the register
state in hardware is getting lost, as the device registers are
reset when the chip is powered down.

Thus this patch simply re-writes the i2c address to the
ADV7511_REG_EDID_I2C_ADDR register to ensure its properly set
before we try to read the EDID data.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-7-git-send-email-john.stu...@linaro.org
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 17b9e98..f75ab62 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,9 +573,17 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
unsigned int count;
 
/* Reading the EDID only works if the device is powered */
-   if (!adv7511->powered)
+   if (!adv7511->powered) {
+   unsigned int edid_i2c_addr =
+   (adv7511->i2c_main->addr << 1) + 4;
+
__adv7511_power_on(adv7511);
 
+   /* Reset the EDID_I2C_ADDR register as it might be cleared */
+   regmap_write(adv7511->regmap, ADV7511_REG_EDID_I2C_ADDR,
+edid_i2c_addr);
+   }
+
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
 
if (!adv7511->powered)
-- 
2.7.4

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


[PATCH 4.9.y 2/3] drm/bridge: adv7511: Reuse __adv7511_power_on/off() when probing EDID

2017-11-03 Thread Nhan Nguyen
From: John Stultz 

commit 4226d9b127cf4758ba0e07931b3f0d59f1b1a50c upstream.

Thus this patch changes the EDID probing logic so that we
re-use the __adv7511_power_on/off() calls instead of duplciating
logic.

This does change behavior slightly as it adds the HPD signal
pulse to the EDID probe path, but Archit has had a patch to
add HPD signal pulse to the EDID probe path before, so this
should address the cases where that helped. Another difference
is that regcache_mark_dirty() is also called in the power off
path once EDID is probed.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Reviewed-by: Laurent Pinchart 
Tested-by: Laurent Pinchart 
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-6-git-send-email-john.stu...@linaro.org
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 17 +++--
 1 file changed, 3 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 545ceff..17b9e98 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -573,24 +573,13 @@ static int adv7511_get_modes(struct adv7511 *adv7511,
unsigned int count;
 
/* Reading the EDID only works if the device is powered */
-   if (!adv7511->powered) {
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN, 0);
-   if (adv7511->i2c_main->irq) {
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(0),
-ADV7511_INT0_EDID_READY);
-   regmap_write(adv7511->regmap, ADV7511_REG_INT_ENABLE(1),
-ADV7511_INT1_DDC_ERROR);
-   }
-   adv7511->current_edid_segment = -1;
-   }
+   if (!adv7511->powered)
+   __adv7511_power_on(adv7511);
 
edid = drm_do_get_edid(connector, adv7511_get_edid_block, adv7511);
 
if (!adv7511->powered)
-   regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
-  ADV7511_POWER_POWER_DOWN,
-  ADV7511_POWER_POWER_DOWN);
+   __adv7511_power_off(adv7511);
 
kfree(adv7511->edid);
adv7511->edid = edid;
-- 
2.7.4

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


[PATCH] drm/nouveau/devinit/nv04: mark expected switch fall-throughs

2017-11-03 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 143119
Addresses-Coverity-ID: 143120
Addresses-Coverity-ID: 143121
Addresses-Coverity-ID: 143122
Addresses-Coverity-ID: 143123
Addresses-Coverity-ID: 143124
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c
index 158977f..c3dae05 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/devinit/nv04.c
@@ -119,11 +119,11 @@ powerctrl_1_shift(int chip_version, int reg)
 
switch (reg) {
case 0x680520:
-   shift += 4;
+   shift += 4; /* fall through */
case 0x680508:
-   shift += 4;
+   shift += 4; /* fall through */
case 0x680504:
-   shift += 4;
+   shift += 4; /* fall through */
case 0x680500:
shift += 4;
}
@@ -245,11 +245,11 @@ setPLL_double_highregs(struct nvkm_devinit *init, u32 
reg1,
 
switch (reg1) {
case 0x680504:
-   shift_c040 += 2;
+   shift_c040 += 2; /* fall through */
case 0x680500:
-   shift_c040 += 2;
+   shift_c040 += 2; /* fall through */
case 0x680520:
-   shift_c040 += 2;
+   shift_c040 += 2; /* fall through */
case 0x680508:
shift_c040 += 2;
}
-- 
2.7.4

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


[PATCH] drm/via/via_dmablit: mark expected switch fall-throughs

2017-11-03 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 114740
Addresses-Coverity-ID: 114741
Addresses-Coverity-ID: 114742
Addresses-Coverity-ID: 114743
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/via/via_dmablit.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/via/via_dmablit.c 
b/drivers/gpu/drm/via/via_dmablit.c
index 98aae98..d3ff3ec 100644
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ b/drivers/gpu/drm/via/via_dmablit.c
@@ -177,12 +177,14 @@ via_free_sg_info(struct pci_dev *pdev, drm_via_sg_info_t 
*vsg)
switch (vsg->state) {
case dr_via_device_mapped:
via_unmap_blit_from_device(pdev, vsg);
+   /* fall through */
case dr_via_desc_pages_alloc:
for (i = 0; i < vsg->num_desc_pages; ++i) {
if (vsg->desc_pages[i] != NULL)
free_page((unsigned long)vsg->desc_pages[i]);
}
kfree(vsg->desc_pages);
+   /* fall through */
case dr_via_pages_locked:
for (i = 0; i < vsg->num_pages; ++i) {
if (NULL != (page = vsg->pages[i])) {
@@ -191,8 +193,10 @@ via_free_sg_info(struct pci_dev *pdev, drm_via_sg_info_t 
*vsg)
put_page(page);
}
}
+   /* fall through */
case dr_via_pages_alloc:
vfree(vsg->pages);
+   /* fall through */
default:
vsg->state = dr_via_sg_init;
}
-- 
2.7.4

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


[PATCH] drm/nouveau/bios/timing: mark expected switch fall-throughs

2017-11-03 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 1260018
Addresses-Coverity-ID: 1260019
Addresses-Coverity-ID: 1260022
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c 
b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c
index 7e83c39..20ff517 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/bios/timing.c
@@ -115,16 +115,21 @@ nvbios_timingEp(struct nvkm_bios *bios, int idx,
switch (min_t(u8, *hdr, 25)) {
case 25:
p->timing_10_24  = nvbios_rd08(bios, data + 0x18);
+   /* fall through */
case 24:
case 23:
case 22:
p->timing_10_21  = nvbios_rd08(bios, data + 0x15);
+   /* fall through */
case 21:
p->timing_10_20  = nvbios_rd08(bios, data + 0x14);
+   /* fall through */
case 20:
p->timing_10_CWL = nvbios_rd08(bios, data + 0x13);
+   /* fall through */
case 19:
p->timing_10_18  = nvbios_rd08(bios, data + 0x12);
+   /* fall through */
case 18:
case 17:
p->timing_10_16  = nvbios_rd08(bios, data + 0x10);
-- 
2.7.4

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


[PATCH v7 3/5] Documentation: Add device tree binding for Goldfish FB driver

2017-11-03 Thread Aleksandar Markovic
From: Aleksandar Markovic 

Add documentation for DT binding of Goldfish FB driver. The compatible
string used by OS for binding the driver is "google,goldfish-fb".

Signed-off-by: Miodrag Dinic 
Signed-off-by: Goran Ferenc 
Signed-off-by: Aleksandar Markovic 
Acked-by: Rob Herring 
---
 .../devicetree/bindings/display/google,goldfish-fb.txt  | 17 +
 1 file changed, 17 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/google,goldfish-fb.txt

diff --git a/Documentation/devicetree/bindings/display/google,goldfish-fb.txt 
b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt
new file mode 100644
index 000..751fa9f
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/google,goldfish-fb.txt
@@ -0,0 +1,17 @@
+Android Goldfish framebuffer
+
+Android Goldfish framebuffer device used by Android emulator.
+
+Required properties:
+
+- compatible : should contain "google,goldfish-fb"
+- reg: 
+- interrupts : 
+
+Example:
+
+   display-controller@1f008000 {
+   compatible = "google,goldfish-fb";
+   interrupts = <0x10>;
+   reg = <0x1f008000 0x100>;
+   };
-- 
2.7.4

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


[PATCH] drm/savage/savage_state: mark expected switch fall-throughs

2017-11-03 Thread Gustavo A. R. Silva
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.

Addresses-Coverity-ID: 114735
Addresses-Coverity-ID: 114736
Addresses-Coverity-ID: 114737
Addresses-Coverity-ID: 114738
Signed-off-by: Gustavo A. R. Silva 
---
 drivers/gpu/drm/savage/savage_state.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/savage/savage_state.c 
b/drivers/gpu/drm/savage/savage_state.c
index 2db89be..0d13d60 100644
--- a/drivers/gpu/drm/savage/savage_state.c
+++ b/drivers/gpu/drm/savage/savage_state.c
@@ -299,6 +299,7 @@ static int savage_dispatch_dma_prim(drm_savage_private_t * 
dev_priv,
case SAVAGE_PRIM_TRILIST_201:
reorder = 1;
prim = SAVAGE_PRIM_TRILIST;
+   /* fall through */
case SAVAGE_PRIM_TRILIST:
if (n % 3 != 0) {
DRM_ERROR("wrong number of vertices %u in TRILIST\n",
@@ -436,6 +437,7 @@ static int savage_dispatch_vb_prim(drm_savage_private_t * 
dev_priv,
case SAVAGE_PRIM_TRILIST_201:
reorder = 1;
prim = SAVAGE_PRIM_TRILIST;
+   /* fall through */
case SAVAGE_PRIM_TRILIST:
if (n % 3 != 0) {
DRM_ERROR("wrong number of vertices %u in TRILIST\n",
@@ -557,6 +559,7 @@ static int savage_dispatch_dma_idx(drm_savage_private_t * 
dev_priv,
case SAVAGE_PRIM_TRILIST_201:
reorder = 1;
prim = SAVAGE_PRIM_TRILIST;
+   /* fall through */
case SAVAGE_PRIM_TRILIST:
if (n % 3 != 0) {
DRM_ERROR("wrong number of indices %u in TRILIST\n", n);
@@ -695,6 +698,7 @@ static int savage_dispatch_vb_idx(drm_savage_private_t * 
dev_priv,
case SAVAGE_PRIM_TRILIST_201:
reorder = 1;
prim = SAVAGE_PRIM_TRILIST;
+   /* fall through */
case SAVAGE_PRIM_TRILIST:
if (n % 3 != 0) {
DRM_ERROR("wrong number of indices %u in TRILIST\n", n);
-- 
2.7.4

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


[PATCH 4.9.y 1/3] drm/bridge: adv7511: Rework adv7511_power_on/off() so they can be reused internally

2017-11-03 Thread Nhan Nguyen
From: John Stultz 

commit 651e4769ba2a9f20c4b8a823ae2727bf7fa9c9f0 upstream.

In chasing down issues with EDID probing, I found some
duplicated but incomplete logic used to power the chip on and
off.

This patch refactors the adv7511_power_on/off functions, so
they can be used for internal needs.

Cc: David Airlie 
Cc: Archit Taneja 
Cc: Wolfram Sang 
Cc: Lars-Peter Clausen 
Cc: Laurent Pinchart 
Cc: dri-devel@lists.freedesktop.org
Cc: sta...@vger.kernel.org
Signed-off-by: John Stultz 
Signed-off-by: Archit Taneja 
Signed-off-by: Thong Ho 
Signed-off-by: Nhan Nguyen 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1484614372-15342-5-git-send-email-john.stu...@linaro.org
---
 drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c 
b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
index 72939d4..545ceff 100644
--- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
+++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c
@@ -325,7 +325,7 @@ static void adv7511_set_link_config(struct adv7511 *adv7511,
adv7511->rgb = config->input_colorspace == HDMI_COLORSPACE_RGB;
 }
 
-static void adv7511_power_on(struct adv7511 *adv7511)
+static void __adv7511_power_on(struct adv7511 *adv7511)
 {
adv7511->current_edid_segment = -1;
 
@@ -354,6 +354,11 @@ static void adv7511_power_on(struct adv7511 *adv7511)
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER2,
   ADV7511_REG_POWER2_HPD_SRC_MASK,
   ADV7511_REG_POWER2_HPD_SRC_NONE);
+}
+
+static void adv7511_power_on(struct adv7511 *adv7511)
+{
+   __adv7511_power_on(adv7511);
 
/*
 * Most of the registers are reset during power down or when HPD is low.
@@ -362,21 +367,23 @@ static void adv7511_power_on(struct adv7511 *adv7511)
 
if (adv7511->type == ADV7533)
adv7533_dsi_power_on(adv7511);
-
adv7511->powered = true;
 }
 
-static void adv7511_power_off(struct adv7511 *adv7511)
+static void __adv7511_power_off(struct adv7511 *adv7511)
 {
/* TODO: setup additional power down modes */
regmap_update_bits(adv7511->regmap, ADV7511_REG_POWER,
   ADV7511_POWER_POWER_DOWN,
   ADV7511_POWER_POWER_DOWN);
regcache_mark_dirty(adv7511->regmap);
+}
 
+static void adv7511_power_off(struct adv7511 *adv7511)
+{
+   __adv7511_power_off(adv7511);
if (adv7511->type == ADV7533)
adv7533_dsi_power_off(adv7511);
-
adv7511->powered = false;
 }
 
-- 
2.7.4

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


Re: [PATCH 0/4] dma-buf: Silence dma_fence __rcu sparse warnings

2017-11-03 Thread Christian König

Patch #4 is Reviewed-by: Christian König .

The rest is Acked-by: Christian König .

Regards,
Christian.

Am 02.11.2017 um 21:03 schrieb Ville Syrjala:

From: Ville Syrjälä 

When building drm+i915 I get around 150 lines of sparse noise from
dma_fence __rcu warnings. This series eliminates all of that.

The first two patches were already posted by Chris, but there wasn't
any real reaction, so I figured I'd repost with a wider Cc list.

As for the other two patches, I'm no expert on dma_fence and I didn't
spend a lot of time looking at it so I can't be sure I annotated all
the accesses correctly. But I figured someone will scream at me if
I got it wrong ;)

Cc: Dave Airlie 
Cc: Jason Ekstrand 
Cc: linaro-mm-...@lists.linaro.org
Cc: linux-me...@vger.kernel.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Sumit Semwal 
Cc: Chris Wilson 

Chris Wilson (2):
   drm/syncobj: Mark up the fence as an RCU protected pointer
   dma-buf/fence: Sparse wants __rcu on the object itself

Ville Syrjälä (2):
   drm/syncobj: Use proper methods for accessing rcu protected pointers
   dma-buf: Use rcu_assign_pointer() to set rcu protected pointers

  drivers/dma-buf/reservation.c |  2 +-
  drivers/gpu/drm/drm_syncobj.c | 11 +++
  include/drm/drm_syncobj.h |  2 +-
  include/linux/dma-fence.h |  2 +-
  4 files changed, 10 insertions(+), 7 deletions(-)



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


[Bug 102885] regression - 17.2 sparkle grid in shadows

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

--- Comment #9 from Samuel Pitoiset  ---
No, the bug should be fixed. I just didn't have much time to work on it to be
honest.

-- 
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