[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #7 from Darren Salt --- Can't do that (radeon module is built in, and no debug symbols ? should switch that on), but ksymoops output (below) is clear enough for me to determine that the marked line is where the bug makes itself known:

[PATCH] Use signed location for drmModeSetPlane

DRM_IOCTL_MODE_SETPLANE crtc_x, crtc_y are s32. This is to allow a destination location that is partially off screen. Make this more obvious to users of libdrm by using signed crtc_x/_y parameters for drmModeSetPlane() as well. Signed-off-by: Daniel Kurtz --- xf86drmMode.c | 2 +-

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #3 from Clemens Ladisch --- 3.14: 16205, pll dividers - fb: 135.8 ref: 2, post 6 With the patch: 162000 - 161990, pll dividers - fb: 271.5 ref: 4, post 6 And the patch indeed fixes this. -- You are receiving this mail because: You

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

> /* defines number of bits in page table versus page directory, >* a page is 4KB so we have 12 bits offset, 9 bits in the page >* table and the remaining 19 bits are in the page directory */ > -#define RADEON_VM_BLOCK_SIZE 9 > +#define RADEON_VM_BLOCK_SIZE 12 > I would first do a

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

From: Christian K?nig This patch makes it possible to decide how many address bits are spend on the page directory vs the page tables. Signed-off-by: Christian K?nig --- drivers/gpu/drm/radeon/cik.c | 1 + drivers/gpu/drm/radeon/cikd.h | 1 +

[PATCH 1/2] drm/radeon: add large PTE support for NI, SI and CIK v4

From: Christian K?nig This patch implements support for VRAM page table entry compression. PTE construction is enhanced to identify physically contiguous page ranges and mark them in the PTE fragment field. L1 TLB and L2 cache support is enabled for 64KB (SI/CIK) and

[Bug 77930] radeon regression after update to kernel 3.13.7 (stable)

, it boots! -- 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/20140501/7f05671e/attachment.html>

[Bug 78163] Opencl app with multiprecision math return wrong results

|.org| -- 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/20140501/964afac5/attachment.html>

[Bug 78163] New: Opencl app with multiprecision math return wrong results

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/20140501/d64cc020/attachment-0001.html>

[PATCH v3 0/9] drm/nouveau: support for GK20A, cont'd

On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot wrote: > Changes since v2: > - Enabled software class > - Removed unneeded changes to nouveau_accel_init() > - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with > the portable page_to_phys()/phys_to_page() page_to_phys()

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #6 from Christian K?nig --- And please provide the output of: gdb /lib/modules/$(uname -r)/kernel/drivers/gpu/drm/radeon/radeon.ko -ex 'list *(radeon_compute_pll_avivo+0xb6)' -ex q Thanks in advance, Christian. -- You are

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 --- Comment #2 from Christian K?nig --- Created attachment 134611 --> https://bugzilla.kernel.org/attachment.cgi?id=134611=edit Possible fix. Please try the attached patch, it might fix the issue. -- You are receiving this mail because: You

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #5 from Christian K?nig --- (In reply to Darren Salt from comment #4) > It appears that you do actually need mismatched builds of xserver git and > xf86-video-ati git, the latter built against (ideally) 1.15.99.902, to > trigger this

[PATCH v3 0/9] drm/nouveau: support for GK20A, cont'd

On 05/01/2014 04:11 PM, Ben Skeggs wrote: > On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot > wrote: >> Changes since v2: >> - Enabled software class >> - Removed unneeded changes to nouveau_accel_init() >> - Replaced use of architecture-private pfn_to_dma() and dma_to_pfn() with >>the

[pull] radeon drm-fixes-3.15

Hi Dave, this is the next pull quested for stashed up radeon fixes for 3.15. Highlights this time are: 1. Support for Mullins. Handled like Kabini, so only PCI-IDs and a new enum that needs to be added on various locations. 2. DPM updates for Kabini. 3. One more patch to better handle PLL

[PATCH 0/8] Add support for Mullins and Beema

I've added the patches to my 3.15 queue. Christian. Am 01.05.2014 00:40, schrieb Alex Deucher: > This patch set adds support for the new Mullins and > Beema APUs. > > Alex Deucher (1): >drm/radeon: dpm updates for KV/KB > > Leo Liu (1): >drm/radeon: add Mullins VCE support > > Samuel Li

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #4 from Darren Salt --- It appears that you do actually need mismatched builds of xserver git and xf86-video-ati git, the latter built against (ideally) 1.15.99.902, to trigger this kernel bug... I wonder why it's gone apparently

[Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware

On Thu, May 1, 2014 at 2:53 PM, Alexandre Courbot wrote: > On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs wrote: >> On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot >> wrote: >>> nvc0_graph_ctor() would only let the graphics engine be enabled if its >>> oclass has a proper microcode linked to

[Bug 75241] radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 Christian K?nig changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment

[PATCH] drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip

op 01-05-14 13:58, Maarten Lankhorst schreef: > Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking > issues in page flipping paths". > chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix > this by moving mutex_unlock down. > > Cc: stable at

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #3 from Darren Salt --- I didn't rebuild the DDX. (May be worth doing just to see if the kernel bug is still triggered.) -- You are receiving this mail because: You are watching the assignee of the bug.

[PATCH] drm/nouveau: fix another lock unbalance in nouveau_crtc_page_flip

Fixes a regression introduced by 060810d7abaabca "drm/nouveau: fix locking issues in page flipping paths". chan->cli->mutex is unlocked a second time in the fail_unreserve path, fix this by moving mutex_unlock down. Cc: stable at vger.kernel.org # v3.11+ --- diff --git

[Nouveau] [PATCH v3 6/9] drm/nouveau/graph: enable when using external firmware

On Mon, Apr 28, 2014 at 11:10 AM, Ben Skeggs wrote: > On Fri, Apr 25, 2014 at 5:19 PM, Alexandre Courbot > wrote: >> nvc0_graph_ctor() would only let the graphics engine be enabled if its >> oclass has a proper microcode linked to it. This prevents GR from being >> enabled at all on chips that

[Bug 75241] New: radeon_compute_pll_avivo broken in 3.15-rc3

https://bugzilla.kernel.org/show_bug.cgi?id=75241 Bug ID: 75241 Summary: radeon_compute_pll_avivo broken in 3.15-rc3 Product: Drivers Version: 2.5 Kernel Version: 3.15-rc3 Hardware: All OS: Linux Tree:

[PATCH v2 04/10] drm/nouveau/fb: add GK20A support

On Mon, Apr 28, 2014 at 8:44 PM, Thierry Reding wrote: > On Wed, Apr 23, 2014 at 03:11:01PM +0900, Alexandre Courbot wrote: >> On Wed, Apr 23, 2014 at 11:07 AM, Alexandre Courbot >> wrote: >> > On 04/22/2014 07:40 PM, Thierry Reding wrote: >> >> >> >> * PGP Signed by an unknown key >> >> >> >>

[PATCH 2/2] drm/radeon: add proper support for RADEON_VM_BLOCK_SIZE

On Thu, May 01, 2014 at 06:52:33PM +0200, Christian K?nig wrote: > From: Christian K?nig > > This patch makes it possible to decide how many address > bits are spend on the page directory vs the page tables. > > Signed-off-by: Christian K?nig NAK on the basis you are modifying default

[PATCH 1/2] drm/radeon: add large PTE support for NI, SI and CIK v4

On 2014-05-01 11:52, Christian K?nig wrote: Some minor comment fixes inline. I've been using v3 of this patch on SI for quite a while, with no visible failures. Thanks for pushing this. > From: Christian K?nig > > This patch implements support for VRAM page table entry compression. > PTE

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

On Thu, May 01, 2014 at 09:04:19AM +0200, Andrzej Hajda wrote: > 2. You replace calls of component_add and component_del with calls > to interface_tracker_ifup(dev, INTERFACE_TRACKER_TYPE_COMPONENT, > _component_ops), > or interface_tracker_ifdown. > Thats all for components. How does the

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 Christian K?nig changed: What|Removed |Added CC||deathsimple at vodafone.de --- Comment

[Bug 75211] Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 --- Comment #1 from Michel D?nzer --- (In reply to Darren Salt from comment #0) > I'm seeing a divide error during X startup, causing X to hang (requiring > reboot to clear). The trigger is a commit in xserver git: > > commit

[PULL] drm-intel-next

> As discussed on irc this contains a (not yet fully tuned and also not yet > in granting mode) cmd parser for gen7. Performance is still a bit rough, > but not quite as bad as originally feared (Ken later on discovered that he > also changed something in his glamour setup which made things

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

Russell King - ARM Linux wrote, On 01.05.2014 00:28: > On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote: >> The main problem with component framework is that componentization >> significantly changes every driver and changes it in a way which is not >> compatible with traditional

[RFC 1/3] atmel: drm: added drm driver for the atmel hlcd controller

Hi Boris, On 04/28/2014 09:22 PM, Boris BREZILLON wrote: > > > Hi, > > This is a first review, from someone who's clearly not a DRM/KMS expert > but who already thought about this specific driver :-). > > I strongly recommend that you wait for DRM/KMS maintainers and/or > experienced

[RFC 0/2] drm/bridge: panel and chaining

e/Makefile | 2 + > >> > drivers/gpu/drm/bridge/drm_bridge_util.c | 251 > +++ > >> > drivers/gpu/drm/bridge/drm_bridge_util.h | 29 > >> > drivers/gpu/drm/bridge/ptn3460.c | 39 - > >> > include/drm/bridge/ptn3460.h | 6 +- > >> > 5 files changed, 319 insertions(+), 8 deletions(-) > >> > create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.c > >> > create mode 100644 drivers/gpu/drm/bridge/drm_bridge_util.h > >> > > >> > -- > >> > 1.9.0 > >> > > >> > ___ > >> > dri-devel mailing list > >> > dri-devel at lists.freedesktop.org <javascript:;> > >> > http://lists.freedesktop.org/mailman/listinfo/dri-devel > >> > >> > >> > >> > >> > >> > > > > > -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/df78f2fe/attachment-0001.html>

[Bug 75211] New: Division error in radeon_compute_pll_avivo (X hang)

https://bugzilla.kernel.org/show_bug.cgi?id=75211 Bug ID: 75211 Summary: Division error in radeon_compute_pll_avivo (X hang) Product: Drivers Version: 2.5 Kernel Version: 3.15-rc3 Hardware: x86-64 OS: Linux

[PATCH 0/2] libdrm_radeon support for Mullins

For the series: Reviewed-by: Marek Ol??k Marek On Thu, May 1, 2014 at 12:44 AM, Alex Deucher wrote: > This adds support for the new Mullins and Beema APUs. > > Samuel Li (2): > radeon: add Mullins chip family > radeon: add Mullins pci ids > > radeon/r600_pci_ids.h | 17

[PATCH 2/4] clk: exynos4: export sclk_hdmiphy clock

On 04.04.2014 16:53, Tomasz Stanislawski wrote: > Export sclk_hdmiphy clock to be usable from DT. > > Signed-off-by: Tomasz Stanislawski > --- > drivers/clk/samsung/clk-exynos4.c |2 +- > include/dt-bindings/clock/exynos4.h |1 + > 2 files changed, 2 insertions(+), 1 deletion(-) >

[PATCH 1/4] clk: propagate parent change up one level

Mike, On 08.04.2014 17:45, Tomasz Figa wrote: > Hi, > > On 04.04.2014 16:53, Tomasz Stanislawski wrote: >> This patch adds support for propagation of setup of clock's parent one >> level >> up. >> >> This feature is helpful when a driver changes topology of its clocks >> using >>

[RFC 0/5] drm/tegra: Convert to master/component framework

44 drivers/base/interface.c > delete mode 100644 drivers/gpu/drm/tegra/bus.c > delete mode 100644 drivers/gpu/host1x/bus.c > delete mode 100644 drivers/gpu/host1x/bus.h > create mode 100644 include/linux/interface.h > > -- > 1.9.2 > -- next part -- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 836 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20140501/4c447241/attachment.sig>

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

Hi Greg, Thanks for comments. I CC Laurent, I hope it could be interesting for him also. Greg Kroah-Hartman wrote, On 30.04.2014 17:49: > On Wed, Apr 30, 2014 at 04:02:50PM +0200, Andrzej Hajda wrote: >> Generic framework for tracking internal interfaces >>

[RFC PATCH 0/4] drivers/base: Generic framework for tracking internal interfaces

On Wed, Apr 30, 2014 at 11:42:09PM +0200, Andrzej Hajda wrote: > The main problem with component framework is that componentization > significantly changes every driver and changes it in a way which is not > compatible with traditional drivers, so devices which are intended to > work with