r600_dma_ring_test() failed - synchronization problem with write-combining memory

09.10.2014, 21:42, "Christian K?nig" : > Hi Alexander, > > in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into > registers, not VRAM. > > And the register bar shouldn't be accessed write combined, cause that > could lead to a couple of ordering problems. Why do you think the access

AMD GPU new API for new module

Thanks for the input. I do _not_ intend to fork IOCTLs for new H/W generations, if possible. i.e, our driver now supports 2 h/w generations with the exact same set of IOCTLs and I don't see how that would change in the future.. What I'm more worried about is supporting different sets of UMD,

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

y the stutter is not completely gone (even though my BL2 experience is good). -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/ee0e6382/attachment.html>

r600_dma_ring_test() failed - synchronization problem with write-combining memory

Am 09.10.2014 um 20:15 schrieb Alexander Fyodorov: > 09.10.2014, 21:42, "Christian K?nig" : >> Hi Alexander, >> >> in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into >> registers, not VRAM. >> >> And the register bar shouldn't be accessed write combined, cause that >> could lead to

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

r just became smaller? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/f01c169a/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

RL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4ff10197/attachment.html>

r600_dma_ring_test() failed - synchronization problem with write-combining memory

Hi Alexander, in the ring test we write the value 0xDEADBEEF and 0xCAFEDEAD into registers, not VRAM. And the register bar shouldn't be accessed write combined, cause that could lead to a couple of ordering problems. Why do you think the access is done write combined? For VRAM it is true

[Bug 79980] Random radeonsi crashes

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4be51a04/attachment.html>

[PATCH] drm/exynos: fix vblank handling during dpms off

On Thu, Oct 9, 2014 at 7:08 PM, Thierry Reding wrote: > On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote: >> On 10/02/2014 08:52 PM, Andrzej Hajda wrote: >> >Hi, >> > >> >+CC possible victims >> > >> >On 10/02/2014 12:52 PM, Inki Dae wrote: >> >>On 2014? 10? 02? 17:58, Joonyoung

[PATCH 2/2] drm/radeon: Try evicting from CPU accessible to inaccessible VRAM first

From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_ttm.c | 25 - 1 file changed, 24 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c b/drivers/gpu/drm/radeon/radeon_ttm.c index

[PATCH 1/2] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

From: Michel D?nzer This avoids them getting in the way of BOs which might be accessed by the CPU. They can still go to the CPU accessible part of VRAM though if there's no space outside of it. Signed-off-by: Michel D?nzer --- drivers/gpu/drm/radeon/radeon_object.c |

[PATCH] drm: tegra: Check return value of drm_vblank_get()

drm_vblank_get() can return an error, which we should propagate. Signed-off-by: Alexandre Courbot --- drivers/gpu/drm/tegra/dc.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/tegra/dc.c b/drivers/gpu/drm/tegra/dc.c index 6553fd238685..b08df07cad47

AMD GPU new API for new module

On Thu, Oct 9, 2014 at 12:15 PM, Oded Gabbay wrote: > Well, I don't expect to reach 100 ioctls anytime soon, but I can tell > you that for the features we have in the pipeline, I can see the IOCTL > number go up to 20-30, just for the current H/W generation. So our Android folks seem to

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

We have test with and without gpio and we haven't seen any difference. To be honest I prefer simplify the bindings which is already complex and so remove gpio. But I will in mind your advice if one day I have debounce issues. Regards, Benjamin 2014-10-09 14:10 GMT+02:00 Rob Clark : > On Thu,

[Bug 82711] After update to kernel soft lockup (oops) and incomplete boot and shutdown fail

https://bugzilla.kernel.org/show_bug.cgi?id=82711 --- Comment #12 from Mike Cloaked --- The only way I can get the laptop to behave sensibly on shutdown is to blacklist the nouveau module at boot using modprobe.blacklist=nouveau on the kernel line, or to add to the file

[Bug 79980] Random radeonsi crashes

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/4f57558f/attachment.html>

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

On Thu, Oct 9, 2014 at 3:56 PM, Vivek Gautam wrote: > Ajay, > > > On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar wrote: >> Hi, >> >> On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam >> wrote: >>> These patches are based on 'for-next' branch of kgene's linux-samsung tree. >>> >>> Refactoring the

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

Ajay, On Thu, Oct 9, 2014 at 3:48 PM, Ajay kumar wrote: > Hi, > > On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam > wrote: >> These patches are based on 'for-next' branch of kgene's linux-samsung tree. >> >> Refactoring the exynos-dp-video phy to use pmu-system-controller handle >> and access

[Bug 79980] Random radeonsi crashes

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/9958d0f0/attachment.html>

[PATCH 0/3] drm-exynos-dp/phy-exynos-dp: Refactor to use pmu-system-controller and dp driver cleanup

Hi, On Mon, Sep 15, 2014 at 6:43 PM, Vivek Gautam wrote: > These patches are based on 'for-next' branch of kgene's linux-samsung tree. > > Refactoring the exynos-dp-video phy to use pmu-system-controller handle > and access the register using mfd-syscon and regmap. > Simultaneously, removing

[Bug 79980] Random radeonsi crashes

. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/993f137e/attachment.html>

[Bug 79980] Random radeonsi crashes

are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/b791cb35/attachment.html>

r600_dma_ring_test() failed - synchronization problem with write-combining memory

Hi David, I'm using 3.10.53-rt56 kernel and encounter a problem in r600_dma_ring_test() when vram memory is mapped as write-combining: no matter how long the polling is done, old value (0xCAFEDEAD) is read. Looking with hardware analyzer at what actually happens in the PCI-E bus, the memory is

[PATCH] imx-drm: currently only IPUv3 is supported, make it mandatory

As long as only IPUv3 is supported in imx-drm, hide the separate DRM_IMX_IPUV3 option and make DRM_IMX depend on IMX_IPUV3_CORE. Reported-by: Michael Olbrich Signed-off-by: Philipp Zabel --- drivers/staging/imx-drm/Kconfig | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff

[PATCH] drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat

From: Michel D?nzer Signed-off-by: Michel D?nzer --- drivers/gpu/drm/ttm/ttm_bo.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c index 407fa2d..d395b0b 100644 ---

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

From: Michel D?nzer The radeon driver uses placement range restrictions for several reasons, in particular to make sure BOs in VRAM can be accessed by the CPU, e.g. during a page fault. Without this change, TTM could evict other BOs while trying to satisfy the requested

[PATCH] drm/exynos: fix vblank handling during dpms off

On 10/02/2014 08:52 PM, Andrzej Hajda wrote: > Hi, > > +CC possible victims > > On 10/02/2014 12:52 PM, Inki Dae wrote: >> On 2014? 10? 02? 17:58, Joonyoung Shim wrote: >>> Hi Andrzej, >>> >>> On 10/01/2014 05:14 PM, Andrzej Hajda wrote: The patch disables vblanks during dpms off only if

[PATCH 1/2] drm/radeon: Try placing NO_CPU_ACCESS BOs outside of CPU accessible VRAM

Am 09.10.2014 um 11:55 schrieb Michel D?nzer: > From: Michel D?nzer > > This avoids them getting in the way of BOs which might be accessed by > the CPU. They can still go to the CPU accessible part of VRAM though if > there's no space outside of it. That sounds to me like you want to increase

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/3f4d867c/attachment.html>

[Bug 84836] New: VERDE lockup with Unigine Valley/Heaven if ARB_sample_shading is enabled

ons: kernel-3.14.20 mesa-10.3.0 llvm-3.5 xf86-video-ati 7.4.0 libdrm-2.4.56 -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20

AMD GPU new API for new module

On 09/10/14 11:02, Jerome Glisse wrote: > On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote: >> Hi Jerome, >> >> Do you think your proposed change should also be applied to amdkfd's >> IOCTLs ? > > It might make sense it really depends on the lifespan you expect for > amdkfd, do you

[Bug 79980] Random radeonsi crashes

part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/a17383b5/attachment.html>

[Bug 84662] Long pauses with Unreal demo Elemental on R9270X since : Always flush the HDP cache before submitting a CS to the GPU

ecause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/484c9001/attachment.html>

[Bug 53971] radeon:Soft reset GPU in StarCraft2 under Wine

https://bugzilla.kernel.org/show_bug.cgi?id=53971 Zhuravlev Uriy changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

'drop clk/voltage dependency filters for SI' breaks factory-over-clocked Cape Verde

Hi Alex, your kernel commit 186b1b2ba2a0684e3d2d3703427a993a3b35b16d ('drm/radeon/dpm: drop clk/voltage dependency filters for SI') causes my factory-over-clocked Cape Verde card to lock up pretty quickly when running e.g. Unigine Valley or the PTS Xonotic benchmark. Everything's fine again

[PATCH] drm/exynos: fix vblank handling during dpms off

sed to react to this situation? It shouldn't happen. If drm_vblank_off() and drm_vblank_on() are called around a modeset they should never conflict with drm_vblank_get(), at least on Tegra, because the modeset and page-flip IOCTLs will be serialized. Thierry -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/ebf4cbdc/attachment.sig>

[PATCH] video/hdmi: Relicense header under MIT license

Am 08.10.2014 um 18:45 schrieb Thierry Reding: > From: Thierry Reding > > OpenBSD wants to reuse this file but needs the license to be more > permissive. > > Acked-by: Alban Bedel > Acked-by: Daniel Vetter > Signed-off-by: Thierry Reding Not sure if it's necessary, but it might be that some

[PATCH] drm/exynos: fix vblank handling during dpms off

A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/630135f4/attachment.sig>

[PATCH] drm/ttm: Don't skip fpfn check if lpfn is 0 in ttm_bo_mem_compat

Am 09.10.2014 um 08:03 schrieb Michel D?nzer: > From: Michel D?nzer > > Signed-off-by: Michel D?nzer Reviewed-by: Christian K?nig > --- > drivers/gpu/drm/ttm/ttm_bo.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/ttm/ttm_bo.c

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

Am 09.10.2014 um 08:02 schrieb Michel D?nzer: > From: Michel D?nzer > > The radeon driver uses placement range restrictions for several reasons, > in particular to make sure BOs in VRAM can be accessed by the CPU, e.g. > during a page fault. > > Without this change, TTM could evict other BOs

AMD GPU new API for new module

Am 09.10.2014 um 09:54 schrieb Jerome Glisse: > On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: >> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: >>> So idea is simple, each ioctl would use some struct like : >>> >>> struct radeon_ioctl { >>> u32 version; >>>

[Bug 84835] New: GL_PRIMITIVE_RESTART_FIXED_INDEX uses glPrimitiveRestartIndex value and not fixed value

ause: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/58234f0f/attachment-0001.html>

[PATCH] drm/ttm: Don't evict BOs outside of the requested placement range

On 2014-10-09 07:02, Michel D?nzer wrote: > From: Michel D?nzer > > The radeon driver uses placement range restrictions for several > reasons, > in particular to make sure BOs in VRAM can be accessed by the CPU, e.g. > during a page fault. > > Without this change, TTM could evict other BOs

AMD GPU new API for new module

On Wed, Oct 8, 2014 at 6:00 PM, Jerome Glisse wrote: > > struct radeon_ioctl { > u32 version; > u32 size; > }; How is this any different from just another ioctl multiplexer and why can't we just add a new version if an ioctl needs to be revised? E.g. in i915 we've just

[PATCH] drm: sti: allow to change hdmi ddc i2c adapter

Depending of the board configuration i2c for ddc could change, this patch allow to use a phandle to specify which i2c controller to use. Signed-off-by: Benjamin Gaignard --- .../devicetree/bindings/gpu/st,stih4xx.txt | 1 + drivers/gpu/drm/sti/sti_hdmi.c | 40

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

gpio used for HDMI hot plug detection is useless, HDMI_STI register contains an hot plug detection status bit. Fix binding documentation. Signed-off-by: Benjamin Gaignard --- Documentation/devicetree/bindings/gpu/st,stih4xx.txt | 2 -- drivers/gpu/drm/sti/sti_hdmi.c | 11

[PATCH] drm: sti: use drm_crtc_vblank_{on/off} instead of drm_vblank_{on/off}

Make sure that vblank is enabled when crtc commit is call. Replace drm_vblank_off() by drm_crtc_vblank_off() Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/sti/sti_drm_crtc.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/sti/sti_drm_crtc.c

AMD GPU new API for new module

Hi Jerome, Do you think your proposed change should also be applied to amdkfd's IOCTLs ? Oded On 08/10/14 19:00, Jerome Glisse wrote: > Hi, > > So if i do not start the discussion now it might be already too late. Given > plan to converge open source driver and closed source driver to

[PATCH] drm/exynos: fix vblank handling during dpms off

On Thu, Oct 09, 2014 at 02:43:02PM +0900, Alexandre Courbot wrote: > But there might be another issue, which is that calls to > drm_vblank_get() will return -EINVAL if invoked between drm_blank_off > and drm_blank_on. Is this really the desired behavior? Can it at least > happen? If so, how

[PATCH] video/hdmi: Relicense header under MIT license

On Wed, Oct 08, 2014 at 06:45:01PM +0200, Thierry Reding wrote: > From: Thierry Reding > > OpenBSD wants to reuse this file but needs the license to be more > permissive. > > Acked-by: Alban Bedel > Acked-by: Daniel Vetter Also Acked-by: Daniel Vetter for the entire Intel team. -Daniel >

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

These counters are used for Displayort complinace testing to detect error conditions when executing certain compliance tests. Currently these are used in the EDID tests to determine if the video mode needs to be set to the preferred mode or the failsafe mode. Cc: dri-devel at

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

Sorry for the spam - Ignore the duplicates. There will be one more coming when I post this series to intel-gfx. -T -Original Message- From: Todd Previte [mailto:tprev...@gmail.com] Sent: Thursday, October 09, 2014 8:33 AM To: tprevite at gmail.com Cc: dri-devel at lists.freedesktop.org

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

having a .drirc under $HOME without the workaround overrides one in /etc with it. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/atta

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

These counters are used for Displayort complinace testing to detect error conditions when executing certain compliance tests. Currently these are used in the EDID tests to determine if the video mode needs to be set to the preferred mode or the failsafe mode. Cc: dri-devel at

[PATCH 02/10] drm/i915: Add counters in the drm_dp_aux struct for I2C NACKs and DEFERs

These counters are used for Displayort complinace testing to detect error conditions when executing certain compliance tests. Currently these are used in the EDID tests to determine if the video mode needs to be set to the preferred mode or the failsafe mode. Cc: dri-devel at

[Bug 84232] PHINode containing itself causes segfault in LLVM when compiling Blender OpenCL kernel with R600 backend

040cd98 in main () -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/3adf3ebf/attachment.html>

AMD GPU new API for new module

On Thu, Oct 9, 2014 at 3:54 AM, Jerome Glisse wrote: > On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: >> On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: >> > >> > So idea is simple, each ioctl would use some struct like : >> > >> > struct radeon_ioctl { >> > u32

[PATCH] drm: sti: remove gpio for HDMI hot plug detection

On Thu, Oct 9, 2014 at 4:42 AM, Benjamin Gaignard wrote: > gpio used for HDMI hot plug detection is useless, > HDMI_STI register contains an hot plug detection status bit. > Fix binding documentation. Random thought, but depending on how much you trust your hw designers you may want to at least

[Bug 84663] high cpu usage, poor performance in Borderlands 2 with radeonsi, PRIME

bbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/f1bd400c/attachment.html>

[Bug 79659] R9 270X lockup with unigine valley since radeonsi: enable ARB_sample_shading

le_shading is causing GPU lockup on VERDE. Should I open a separate bug for this issue? -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachm

AMD GPU new API for new module

On Thu, Oct 09, 2014 at 09:54:14AM +0300, Oded Gabbay wrote: > Hi Jerome, > > Do you think your proposed change should also be applied to amdkfd's > IOCTLs ? It might make sense it really depends on the lifespan you expect for amdkfd, do you expect that you will need substential API evolution

AMD GPU new API for new module

On Thu, Oct 09, 2014 at 03:32:26AM -0400, Rob Clark wrote: > On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: > > > > So idea is simple, each ioctl would use some struct like : > > > > struct radeon_ioctl { > > u32 version; > > u32 size; > > }; > > > fwiw,

AMD GPU new API for new module

On Wed, Oct 8, 2014 at 12:00 PM, Jerome Glisse wrote: > > So idea is simple, each ioctl would use some struct like : > > struct radeon_ioctl { > u32 version; > u32 size; > }; fwiw, drm_ioctl() will do the right thing (zero-pad) for growing ioctls these days.. BR, -R

[Bug 84140] mplayer crashes playing some files using vdpau output

'll do some debug runs. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20141009/88e25212/attachment.html>

[PATCH] video/hdmi: Relicense header under MIT license

> -Original Message- > From: Thierry Reding [mailto:thierry.reding at gmail.com] > Sent: Wednesday, October 08, 2014 12:45 PM > To: David Airlie > Cc: Daniel Vetter; Deucher, Alexander; Alban Bedel; dri- > devel at lists.freedesktop.org > Subject: [PATCH] video/hdmi: Relicense header under