[Bug 103544] Graphical glitches r600 in game this war of mine linux native
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
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'
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]
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]
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]
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!
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)
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
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
From: Akshu AgrawalMinimum 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
From: Akshu AgrawalThis 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
From: Vijendar MukundaUsing 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()
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
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)
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
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
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
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
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
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
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
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
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
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)
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
-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)
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
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
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
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
https://bugs.freedesktop.org/show_bug.cgi?id=103562 Vasilis LIaskovitischanged: 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
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
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
On 3 November 2017 at 13:59, Tobias Jakobiwrote: > 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)
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
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
From: Christian KönigJust 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
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
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
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
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
On 03.11.2017 13:57, PrasannaKumar Muralidharan wrote: Hi, On 3 November 2017 at 16:56, Stephan Baurothwrote: 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
Hi, On 3 November 2017 at 16:56, Stephan Baurothwrote: > 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)
https://bugs.freedesktop.org/show_bug.cgi?id=103550 Daniel Stonechanged: 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
On Thu, Nov 2, 2017 at 11:45 PM, Chih-Wei Huangwrote: > 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
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
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
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 SzyprowskiTested-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
Reviewed-By: Xiangliang YuThanks! > -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)
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()
Den 02.11.2017 21.09, skrev Noralf Trønnes: These helpers take care of output polling, fbdev and atomic state. Cc: Stefan AgnerCc: 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
From: John Stultzcommit 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
From: John Stultzcommit 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
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
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
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
From: Aleksandar MarkovicAdd 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
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
From: John Stultzcommit 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
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
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