[Bug 58840] rendering error with MSAA on HD6850

|| -- 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/20130102/669d4675/attachment.html>

[Bug 58840] rendering error with MSAA on HD6850

t;http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/07cba45c/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: > Please affected people can you test if patch : > http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch > > Fix the issue, you need to make sure you don't have the patch that > disable dma on r6xx

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #12 from Fernando Chaves 2013-01-02 23:36:38 --- Created an attachment (id=90231) --> (https://bugzilla.kernel.org/attachment.cgi?id=90231) Xorg.0.log from Ubuntu - Without Xen -- Configure bugmail:

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #11 from Fernando Chaves 2013-01-02 23:35:40 --- Created an attachment (id=90221) --> (https://bugzilla.kernel.org/attachment.cgi?id=90221) dmesg output in Ubuntu (after typing "startx"), with tons of error messages - Without

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #10 from Fernando Chaves 2013-01-02 23:33:23 --- Created an attachment (id=90211) --> (https://bugzilla.kernel.org/attachment.cgi?id=90211) dmesg output in Ubuntu (before typing "startx") - Without Xen -- Configure bugmail:

[Bug 58959] kernel 3.6.4 and r600_dri.so from mesa 8.0.5 are incompatible

vice section of your xorg.conf -- 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/20130102/e2c09b60/attachment.html>

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #9 from Fernando Chaves 2013-01-02 23:31:28 --- Created an attachment (id=90201) --> (https://bugzilla.kernel.org/attachment.cgi?id=90201) List of loaded modules in Ubuntu - without Xen -- Configure bugmail:

[Bug 58959] New: kernel 3.6.4 and r600_dri.so from mesa 8.0.5 are incompatible

nts/20130102/b5dcda43/attachment.html>

[Bug 58840] rendering error with MSAA on HD6850

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/de0b4b14/attachment.html>

[Bug 58839] errors about too many fences printed while playing neverball

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/9ef2c6af/attachment.html>

[Bug 58839] errors about too many fences printed while playing neverball

art -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/75b4db1d/attachment.html>

[Bug 58839] errors about too many fences printed while playing neverball

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

[Bug 58958] Kernel crash: Error to handle paging request

|| -- 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/20130102/2595e6a0/attachment.html>

[Bug 57842] r200: Culling is broken when rendering to an FBO

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/20130102/db13846c/attachment.html>

[Bug 58958] New: Kernel crash: Error to handle paging request

ure taken with camera showing the crash. System crashes. Picture attached. -- 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

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Fernando Chaves changed: What|Removed |Added Attachment #89931|lspci_and_xorg-fixed.log| filename|

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Fernando Chaves changed: What|Removed |Added Attachment #90161|My current kernel .config |My current kernel .config

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Fernando Chaves changed: What|Removed |Added Attachment #90181|content from "dmesg"|content from "dmesg" from

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Fernando Chaves changed: What|Removed |Added Attachment #90171|content of "xl dmesg" |content of "xl dmesg" from

[Bug 58925] compis/kwin crashes on nouveau due to msaa

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

[Bug 58839] errors about too many fences printed while playing neverball

-- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/0238bef2/attachment.html>

[PATCH v2] drm/exynos: let drm handle edid allocations

2013/1/2 Rahul Sharma : > There's no need to allocate edid twice and do a memcpy when drm helpers > exist to do just that. This patch cleans that interaction up, and > doesn't keep the edid hanging around in the connector. > > v2: > - changed vidi_get_edid callback inside vidi driver. > >

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 01/02/2013 07:19 PM, Jerome Glisse wrote: > On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov wrote: >> On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote: >>> I ended up also that same commit after bisecting from current 3.8 >>> master. >>> >>> 01:05.0 VGA compatible controller:

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 6:58 PM, Shuah Khan wrote: > On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: >> On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf >> wrote: >>> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: Please affected people can you test if patch :

[PATCH 2/2] [RFC] video: display: Adding frame related ops to MIPI DSI video source struct

From: Vikas Sajjan Signed-off-by: Vikas Sajjan --- include/video/display.h |6 ++ 1 file changed, 6 insertions(+) diff --git a/include/video/display.h b/include/video/display.h index b639fd0..fb2f437 100644 --- a/include/video/display.h +++

[PATCH 1/2] [RFC] video: exynos mipi dsi: Making Exynos MIPI Complaint with CDF

From: Vikas Sajjan Signed-off-by: Vikas Sajjan --- drivers/video/exynos/exynos_mipi_dsi.c| 46 ++--- drivers/video/exynos/exynos_mipi_dsi_common.c | 22 drivers/video/exynos/exynos_mipi_dsi_common.h | 12 +++

[PATCH 0/2] Making Exynos MIPI Complaint with Common Display Framework

From: Vikas Sajjan This patchset contains 2 RFCs, 1st RFC has modiifications in exynos MIPI DSI driver. 2nd RFC has additions done to video source struct as per exynos requirements. I have NOT tested the patch yet, as i am yet recieve the MIPI DSI panel. This based on

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

ix-DMA-engine-for-ttm-bo-transfers.patch Type: text/x-patch Size: 1110 bytes Desc: not available URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/86ebb238/attachment.bin>

[PATCH 12/12] drm/radeon: consolidate redundant macros and constants

After refactoring the _cs logic, we ended up with many macros and constants that #define the same thing. Clean'em up. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/evergreen_cs.c | 18 +- drivers/gpu/drm/radeon/evergreend.h | 13 ++---

[PATCH 11/12] drm/radeon: use common next_reloc function

This patch eliminates ASIC-specific ***_cs_packet_next_reloc functions and hooks up the new common function. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/evergreen_cs.c | 129 +-- drivers/gpu/drm/radeon/r100.c | 76 +++-

[PATCH 10/12] drm/radeon: pull out common next_reloc function

next_reloc function does the same thing in all ASICs with the exception of R600 which has a special case in legacy mode. Pull out the common function in preparation for refactoring. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/radeon.h| 3 +++ drivers/gpu/drm/radeon/radeon_cs.c |

[PATCH 09/12] drm/radeon: rename r100_cs_dump_packet to radeon_cs_dump_packet

This function is not limited to r100, but it can dump a (raw) packet for any ASIC. Rename it accordingly and move its declaration to radeon.h Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/r100.c | 52 ++--- drivers/gpu/drm/radeon/r100_track.h | 2

[PATCH 08/12] drm/radeon: add a check to wait_reg_mem command

WAIT_REG_MEM on register does not allow the use of PFP. Enforce this restriction when checking packets sent from userland. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/evergreen_cs.c | 3 +++ drivers/gpu/drm/radeon/r600_cs.c | 8 2 files changed, 11 insertions(+) diff

[PATCH 07/12] drm/radeon: refactor vline packet parsing function

vline packet parsing function for R600 and Evergreen+ are the same, except that they use different registers. Factor out the algorithm into a common function that uses register table passed from ASIC-specific caller. This reduces ASIC-specific function to (trivial) setup of register table and

[PATCH 06/12] drm/radeon: factor out cs_next_is_pkt3_nop function

Once we factored out radeon_cs_packet_parse function, evergreen_cs_next_is_pkt3_nop and r600_cs_next_is_pkt3_nop functions became identical, so they can be factored out into a common function. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/evergreen_cs.c | 23 +--

[PATCH 05/12] drm/radeon: use common cs packet parse function

We now have a common radeon_cs_packet_parse function that is good for all ASICs. Hook it up and eliminate ASIC-specific versions. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/evergreen_cs.c | 57 +++-- drivers/gpu/drm/radeon/r100.c | 55

[PATCH 04/12] drm/radeon: implement common cs packet parse function

CS packet parse functions have a lot of in common across all ASICs. Implement a common function and take care of small differences between families inside the function. This patch is a prep for major refactoring and consolidation of CS parsing code. Signed-off-by: Ilija Hadzic ---

[PATCH 03/12] drm/radeon: fix formatting

Preparatory patch: patches to follow will touch a piece of code that had broken indentication, so fix it before touching it. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/r100.c | 45 +-- 1 file changed, 22 insertions(+), 23 deletions(-) diff

[PATCH 02/12] drm/radeon: remove unused prototype from radeon_cs

Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/radeon_cs.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/drivers/gpu/drm/radeon/radeon_cs.c b/drivers/gpu/drm/radeon/radeon_cs.c index 4be64e0..8b03f1c 100644 --- a/drivers/gpu/drm/radeon/radeon_cs.c +++

[PATCH 01/12] drm/radeon: remove unecessary assignment

length_dw field was assigned twice. While at it, move user_ptr assignment together with all other assignments to p->chunks[i] structure to make the code more readable. Signed-off-by: Ilija Hadzic --- drivers/gpu/drm/radeon/radeon_cs.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-)

radeon CS parser refactoring

The following set of patches refactor the CS-parser logic in an effort to consolidate the code that is repeated across ASIC-specific files. All patches except #8 are function-neutral, that is they preserve the existing functionality of the driver. Patch #8 adds one extra check for WAIT_REG_MEM

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #8 from Konrad Rzeszutek Wilk 2013-01-02 18:10:37 --- There looks to be something odd with the base value. Can you also run baremetal and collect the 'dmesg' and the 'xorg.log' please? Thank you. -- Configure bugmail:

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 4:59 PM, Alex Deucher wrote: >>> >> >> Catching up with this thread. I reverted the >> >> drm/radeon: use async dma for ttm buffer moves on 6xx-SI >> commit id: 2d6cc7296d4ee128ab0fa3b715f0afde511f49c2 >> >> Do I need to apply this patch without reverting >>

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #7 from Fernando Chaves 2013-01-02 17:31:59 --- Created an attachment (id=90181) --> (https://bugzilla.kernel.org/attachment.cgi?id=90181) content from "dmesg" -- Configure bugmail:

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #6 from Fernando Chaves 2013-01-02 17:31:36 --- Created an attachment (id=90171) --> (https://bugzilla.kernel.org/attachment.cgi?id=90171) content of "xl dmesg" -- Configure bugmail:

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

Please affected people can you test if patch : http://people.freedesktop.org/~glisse/0003-drm-radeon-fix-dma-copy-on-r6xx-r7xx-evergen-ni-si-g.patch Fix the issue, you need to make sure you don't have the patch that disable dma on r6xx ie that line 977-978 & 1061-1062 in radeon_asic.c is :

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #5 from Fernando Chaves 2013-01-02 17:31:09 --- Created an attachment (id=90161) --> (https://bugzilla.kernel.org/attachment.cgi?id=90161) My current kernel .config -- Configure bugmail:

[PATCHv4 3/8] gpu: host1x: Add channel support

On 01/02/2013 05:31 PM, Terje Bergstr?m wrote: > On 02.01.2013 09:40, Mark Zhang wrote: >> On 12/21/2012 07:39 PM, Terje Bergstrom wrote: >>> Add support for host1x client modules, and host1x channels to submit >>> work to the clients. The work is submitted in GEM CMA buffers, so >>> this patch

[PATCH 2/2] drm/radeon: reset dma engine on gpu reset

From: Jerome Glisse This try to reset the dma engine when performing gpu reset. Hopefully bringing back the gpu dma engine in sane state. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/evergreen.c | 30 +-

[PATCH 1/2] drm/radeon: improve ring debugfs printing

From: Jerome Glisse Print 32dword before last know rptr as problem most likely comes from previous command. Also small cosmetic change to the printing. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_ring.c | 20 +--- 1 file changed, 13

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Konrad Rzeszutek Wilk changed: What|Removed |Added CC||konrad.wilk at oracle.com

[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID

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

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 4:37 PM, Alex Deucher wrote: > On Wed, Jan 2, 2013 at 5:38 PM, Markus Trippelsdorf > wrote: >> On 2013.01.02 at 17:31 -0500, Jerome Glisse wrote: >>> Please affected people can you test if patch : >>>

[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch. Only useful item in dmesg is: [ 33.922807] radeon :01:00.0: Refused to change power state, currently in D3 I did some

Resume regression with nouveau 3.8rc1 (bisected)

Hi, Starting with 3.8rc1 I get a black screen when resuming after suspend. The kernel is alive because I can switch to VT1 and reboot with ctrl-alt-delete. I bisected the problem down to this commit: 186ecad21: drm/nv50/disp: move remaining interrupt handling into core Hardware is 8400M GS

[PATCHv4 3/8] gpu: host1x: Add channel support

Just one minor issue. Check below. On 12/21/2012 07:39 PM, Terje Bergstrom wrote: > Add support for host1x client modules, and host1x channels to submit > work to the clients. The work is submitted in GEM CMA buffers, so > this patch adds support for them. > > Signed-off-by: Terje Bergstrom >

[PATCH 2/2] drm/radeon: print dma status reg on lockup

From: Jerome Glisse To help debug dma related lockup. Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/evergreen.c | 4 drivers/gpu/drm/radeon/evergreend.h | 3 +++ drivers/gpu/drm/radeon/ni.c | 4 drivers/gpu/drm/radeon/nid.h| 1 -

[PATCH 1/2] drm/radeon: add debugfs file for dma rings

From: Jerome Glisse Signed-off-by: Jerome Glisse --- drivers/gpu/drm/radeon/radeon_ring.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/radeon/radeon_ring.c b/drivers/gpu/drm/radeon/radeon_ring.c index ebd6956..9410e43 100644 ---

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #3 from Fernando Chaves 2013-01-02 15:02:44 --- UPDATE: Tested Xen 4.2.1 with Ubuntu 12.10 32-bit kernel 3.7.1 and I got the following results: - Xorg with Unity works with poor performance with Xen hypervisor loaded. - Xorg

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk

[RFC,libdrm 1/3] tegra: Add stream library

On 01/02/2013 02:31 PM, Terje Bergstr?m wrote: > On 02.01.2013 04:44, Mark Zhang wrote: >> Agree. If we are able to do something dynamically, normally that'll be >> better. >> >> Terje, we can get the Tegra version in FUSE. I think we don't need this >> kind of try-catch logics. > > We'd need to

[Bug 52071] Random kernel crashes when using Xorg with radeon module

https://bugzilla.kernel.org/show_bug.cgi?id=52071 Alan changed: What|Removed |Added CC||alan at lxorguk.ukuu.org.uk

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

ones you want to start X on. -- 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/20130102/752ea0f5/attachment.html>

[Bug 58840] rendering error with MSAA on HD6850

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20130102/d852a7dd/attachment.html>

[PATCH 4/8] drm/exynos: fimd: clear channel before enabling iommu

On Wed, Dec 26, 2012 at 3:27 AM, Prathyush K wrote: > From: Akshu Agrawal > > If any fimd channel was already active, initializing iommu will result > in a PAGE FAULT (e.g. u-boot could have turned on the display and > not disabled it before the kernel starts). This patch checks if any > channel

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote: > I ended up also that same commit after bisecting from current 3.8 > master. > > 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon > 3000] It is ASUS M5A78L-M/USB3 with integrated GPU. > > I cannot even boot

[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID

org/archives/dri-devel/attachments/20130102/6ef32777/attachment.html>

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On Wed, Jan 2, 2013 at 7:02 AM, Borislav Petkov wrote: > On Wed, Jan 02, 2013 at 03:42:20AM +0200, Antti Palosaari wrote: >> I ended up also that same commit after bisecting from current 3.8 >> master. >> >> 01:05.0 VGA compatible controller: ATI Technologies Inc 760G [Radeon >> 3000] It is ASUS

[PATCH 3/4] drm/exynos: mixer: set correct mode for range of resolutions

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote: > With this patch, mixer driver find the correct resolution mode for > the range of resolutions, upto 1080 vertical lines. Resolution will > be categorized to NTSC SD, PAL SD or HD and the correct mode is > set to the mixer configuration

[PATCH 2/4] drm/exynos: implement display-mode-check callback in mixer driver

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote: > This patch adds the implementation of check_mode callback in the mixer > driver. Based on the mixer version, correct set of restrictions will be > exposed by the mixer driver. A resolution will be acceptable only if passes > the criteria set

[PATCH 1/4] drm/exynos: add display-mode-check operation to exynos_mixer_ops struct

On Thu, Dec 27, 2012 at 6:38 AM, Rahul Sharma wrote: > This patch adds the display mode check operation to exynos_mixer_ops > in drm-common-hdmi. In Exynos SoCs, mixer IP can put certain restrictions > on the proposed display modes. These restriction needs to be considered > during mode

[PATCH 8/8] drm/exynos: fimd: add complete_scanout function

On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K wrote: > The wait_for_vblank interface is modified to the complete_scanout > function in fimd. This patch adds the fimd_complete_scanout function > > Inside fimd_complete_scanout, we read the shadow register for each > window and compare it with the

[Bug 58914] Cannot start Radeon driver: "drmOpenByBusid: drmGetBusid reports " no bus ID

: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130102/4c20d550/attachment-0001.html>

[PATCHv4 3/8] gpu: host1x: Add channel support

On 02.01.2013 11:31, Mark Zhang wrote: > On 01/02/2013 05:31 PM, Terje Bergstr?m wrote: >> That's intentional. Writing a job to channel is atomic, so lock is taken >> from host1x_cdma_begin() until host1x_cdma_end(). >> > > Okay. So can we consider that lock and unlock this mutex in the function

[PATCHv4 0/8] Support for Tegra 2D hardware

On 28.12.2012 11:14, Mark Zhang wrote: > diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c > index a936902..c3ded60 100644 > --- a/drivers/gpu/drm/tegra/gr2d.c > +++ b/drivers/gpu/drm/tegra/gr2d.c > @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context >

[PATCH 7/8] drm/exynos: hdmi: add complete_scanout function

On Wed, Dec 26, 2012 at 6:27 AM, Prathyush K wrote: > The wait_for_vblank interface is modified to the complete_scanout > function in hdmi. This inturn calls the complete_scanout mixer op. > This patch also adds the mixer_complete_scanout function. > > Inside mixer_complete_scanout, we read the

[PATCHv4 3/8] gpu: host1x: Add channel support

On 02.01.2013 09:40, Mark Zhang wrote: > On 12/21/2012 07:39 PM, Terje Bergstrom wrote: >> Add support for host1x client modules, and host1x channels to submit >> work to the clients. The work is submitted in GEM CMA buffers, so >> this patch adds support for them. >> >> Signed-off-by: Terje

[PATCHv4 3/8] gpu: host1x: Add channel support

On 22.12.2012 06:17, Steven Rostedt wrote: > On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote: >> +TRACE_EVENT(host1x_cdma_begin, >> +TP_PROTO(const char *name), >> + >> +TP_ARGS(name), >> + >> +TP_STRUCT__entry( >> +__field(const char *, name) >> +), >> + >> +

[PATCHv4 0/8] Support for Tegra 2D hardware

On 26.12.2012 11:42, Mark Zhang wrote: > diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c > index a936902..28954b3 100644 > --- a/drivers/gpu/drm/tegra/gr2d.c > +++ b/drivers/gpu/drm/tegra/gr2d.c > @@ -247,6 +247,10 @@ static int __devinit gr2d_probe(struct >

[RFC,libdrm 1/3] tegra: Add stream library

On 12/31/2012 02:22 PM, Terje Bergstr?m wrote: > On 28.12.2012 22:48, Thierry Reding wrote: >> I disagree. We shouldn't be hiding this kind of detail behind an #ifdef. >> Instead it should be detected at runtime. Otherwise you'll need to build >> different versions of libdrm for every generation

[PATCH] drm/exynos: let drm handle edid allocations

On Wed, Jan 2, 2013 at 6:05 AM, ??? wrote: > Hi Rahul, > > On 2012? 12? 28? 16:01, Rahul Sharma wrote: >> There's no need to allocate edid twice and do a memcpy when drm helpers >> exist to do just that. This patch cleans that interaction up, and >> doesn't keep the edid hanging around in the

[PATCH] drm/exynos: let drm handle edid allocations

Hi Rahul, On 2012? 12? 28? 16:01, Rahul Sharma wrote: > There's no need to allocate edid twice and do a memcpy when drm helpers > exist to do just that. This patch cleans that interaction up, and > doesn't keep the edid hanging around in the connector. Basically, I agree about this idea. But

[RFC,libdrm 1/3] tegra: Add stream library

On 02.01.2013 04:44, Mark Zhang wrote: > Agree. If we are able to do something dynamically, normally that'll be > better. > > Terje, we can get the Tegra version in FUSE. I think we don't need this > kind of try-catch logics. We'd need to have in user space a map of SoC version -> number of sync

[RFC v2 6/8] gpu: drm: tegra: Remove redundant host1x

On 21.12.2012 23:19, Stephen Warren wrote: > * There's host1x hardware. > > * There's a low-level driver just for host1x itself; the host1x driver. > > * There's a high-level driver for the entire host1x complex of devices. > That is tegradrm. There may be more high-level drivers in the future >

[PATCH v3] drm/exynos: let drm handle edid allocations

There's no need to allocate edid twice and do a memcpy when drm helpers exist to do just that. This patch cleans that interaction up, and doesn't keep the edid hanging around in the connector. v3: - removed MAX_EDID as it is not used anymore. v2: - changed vidi_get_edid callback inside vidi

radeon 0000:02:00.0: GPU lockup CP stall for more than 10000msec

On 12/25/2012 06:50 AM, Shuah Khan wrote: > On Sun, Dec 23, 2012 at 6:31 AM, Borislav Petkov wrote: >> On Sun, Dec 23, 2012 at 01:22:12PM +0100, Borislav Petkov wrote: >>> Right, let me try that and report back. >> >> Yep, looks like reverting the above commit fixes it - the boston.com >> website

[PATCH v2] drm/exynos: let drm handle edid allocations

There's no need to allocate edid twice and do a memcpy when drm helpers exist to do just that. This patch cleans that interaction up, and doesn't keep the edid hanging around in the connector. v2: - changed vidi_get_edid callback inside vidi driver. Signed-off-by: Sean Paul Signed-off-by: Rahul

[PATCH v2] drm/exynos: let drm handle edid allocations

There's no need to allocate edid twice and do a memcpy when drm helpers exist to do just that. This patch cleans that interaction up, and doesn't keep the edid hanging around in the connector. v2: - changed vidi_get_edid callback inside vidi driver. Signed-off-by: Sean Paul seanp...@chromium.org

Re: [PATCHv4 0/8] Support for Tegra 2D hardware

On 26.12.2012 11:42, Mark Zhang wrote: diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c index a936902..28954b3 100644 --- a/drivers/gpu/drm/tegra/gr2d.c +++ b/drivers/gpu/drm/tegra/gr2d.c @@ -247,6 +247,10 @@ static int __devinit gr2d_probe(struct platform_device

Re: [PATCHv4 3/8] gpu: host1x: Add channel support

On 22.12.2012 06:17, Steven Rostedt wrote: On Fri, 2012-12-21 at 13:39 +0200, Terje Bergstrom wrote: +TRACE_EVENT(host1x_cdma_begin, +TP_PROTO(const char *name), + +TP_ARGS(name), + +TP_STRUCT__entry( +__field(const char *, name) +), + +TP_fast_assign( +

Re: [PATCHv4 3/8] gpu: host1x: Add channel support

On 02.01.2013 09:40, Mark Zhang wrote: On 12/21/2012 07:39 PM, Terje Bergstrom wrote: Add support for host1x client modules, and host1x channels to submit work to the clients. The work is submitted in GEM CMA buffers, so this patch adds support for them. Signed-off-by: Terje Bergstrom

Re: [PATCHv4 3/8] gpu: host1x: Add channel support

On 01/02/2013 05:31 PM, Terje Bergström wrote: On 02.01.2013 09:40, Mark Zhang wrote: On 12/21/2012 07:39 PM, Terje Bergstrom wrote: Add support for host1x client modules, and host1x channels to submit work to the clients. The work is submitted in GEM CMA buffers, so this patch adds support

Re: [PATCHv4 0/8] Support for Tegra 2D hardware

On 28.12.2012 11:14, Mark Zhang wrote: diff --git a/drivers/gpu/drm/tegra/gr2d.c b/drivers/gpu/drm/tegra/gr2d.c index a936902..c3ded60 100644 --- a/drivers/gpu/drm/tegra/gr2d.c +++ b/drivers/gpu/drm/tegra/gr2d.c @@ -131,6 +131,14 @@ static int gr2d_submit(struct tegra_drm_context *context,

[Bug 58914] Cannot start Radeon driver: drmOpenByBusid: drmGetBusid reports no bus ID

https://bugs.freedesktop.org/show_bug.cgi?id=58914 --- Comment #1 from Michel Dänzer mic...@daenzer.net --- Please attach the corresponding dmesg output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing

[Bug 58840] rendering error with MSAA on HD6850

https://bugs.freedesktop.org/show_bug.cgi?id=58840 --- Comment #1 from Alex Deucher ag...@yahoo.com --- Please attach your xorg log and dmesg output. -- You are receiving this mail because: You are the assignee for the bug. ___ dri-devel mailing list

[Bug 26891] Radeon KMS fails with inaccessible AtomBIOS on systems with (U)EFI boot

https://bugs.freedesktop.org/show_bug.cgi?id=26891 --- Comment #48 from Alex Deucher ag...@yahoo.com --- (In reply to comment #46) Radeon now works for me on a MBP 8,2 booted from efistub in Linux 3.8.x. Can anyone else confirm this? You just need to make sure you add the PCI IDs to the xorg

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 Alan a...@lxorguk.ukuu.org.uk changed: What|Removed |Added CC||a...@lxorguk.ukuu.org.uk

[Bug 52121] mgag200 driver does not work properly with Xen in new Intel Server Board

https://bugzilla.kernel.org/show_bug.cgi?id=52121 --- Comment #3 from Fernando Chaves ferna...@supergg.com.br 2013-01-02 15:02:44 --- UPDATE: Tested Xen 4.2.1 with Ubuntu 12.10 32-bit kernel 3.7.1 and I got the following results: - Xorg with Unity works with poor performance with Xen

[RFC PATCH] drm/radeon: increase d3 delay to 20 ms during switcheroo poweron

vga-switcheroo with apple-gmux does not switch correctly on my system. The PCI configuration space is not restored correctly, resulting in MSI not working after switch. Only useful item in dmesg is: [ 33.922807] radeon :01:00.0: Refused to change power state, currently in D3 I did some

  1   2   >