[Bug 57875] Second Life viewer bad rendering with git-ec83535

_viewport_state, which is applied after clipping and converts coordinates from the clip space to the window space. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.o

[PATCH 1/4] drm: add prime helpers

On Thu, Dec 06, 2012 at 10:46:30PM +0100, Daniel Vetter wrote: > On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote: > > Instead of reimplementing all of the dma_buf functionality in every driver, > > create helpers drm_prime_import and drm_prime_export that implement them in > > terms

[PATCH 1/4] drm: add prime helpers

On Thu, Dec 06, 2012 at 10:07:48AM -0800, Aaron Plattner wrote: > Instead of reimplementing all of the dma_buf functionality in every driver, > create helpers drm_prime_import and drm_prime_export that implement them in > terms of new, lower-level hook functions: > > gem_prime_pin: callback

[PATCH 3.7-rc8] ttm: Fix possible _manager memory allocation oops

On Thu, Dec 6, 2012 at 4:20 PM, Tim Gardner wrote: > Memory for _manager is allocated using kzalloc() but the result is not > checked. > > Free _manager on error lest memory become orphaned. > > I was led to scrutinize ttm_page_alloc_init() from a smatch warning: > >

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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/20121206/2b607d28/attachment.html>

[Bug 57875] Second Life viewer bad rendering with git-ec83535

ng 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/20121206/67939f7d/attachment.html>

[PATCH 7/7] drm/exynos: clear windows in fimd dpms off

When fimd is turned off, we disable the clocks which will stop the dma. Now if we remove the current framebuffer, we cannot disable the overlay but the current framebuffer will still be freed. When fimd resumes, the dma will continue from where it left off and will throw a PAGE FAULT since the

[PATCH 6/7] drm/exynos: clear windows in mixer dpms off

When mixer is turned off, we disable the clocks which will stop the dma. Now if we remove the current framebuffer, we cannot disable the overlay but the current framebuffer will still be freed. When mixer resumes, the dma will continue from where it left off and will throw a PAGE FAULT since the

[PATCH 5/7] drm/exynos: modify wait_for_vblank of fimd

It is more optimium to use wait queues while waiting for vsync so that the current task is put to sleep. This way, the task wont hog the CPU while waiting. We use wait_event_timeout and not an interruptible function since we dont want the function to exit when a signal is pending (e.g. drm

[PATCH 4/7] drm/exynos: modify wait_for_vblank of mixer

It is more optimium to use wait queues while waiting for vsync so that the current task is put to sleep. This way, the task wont hog the CPU while waiting. We use wait_event_timeout and not an interruptible function since we dont want the function to exit when a signal is pending (e.g. drm

[PATCH 3/7] drm/exynos: move fimd wait_for_vblank to manager_ops

The wait for vblank callback is moved from overlay_ops to manager_ops for fimd. Signed-off-by: Prathyush K --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/exynos/exynos_drm_fimd.c

[PATCH 2/7] drm/exynos: move hdmi's wait_for_vblank to manager_ops

The wait_for_vblank callback of hdmi and mixer is now moved from overlay_ops to manager_ops. Signed-off-by: Prathyush K --- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 +++--- drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +- drivers/gpu/drm/exynos/exynos_mixer.c| 26

[PATCH 1/7] drm/exynos: make wait_for_vblank a manager op

The wait_for_vblank callback is moved from overlay ops to manager ops of exynos drm driver. Also, the check for DPMS OFF of encoder is removed before calling wait_for_vblank. Signed-off-by: Prathyush K --- drivers/gpu/drm/exynos/exynos_drm_drv.h |6 +++---

[PATCH v2 0/7] drm/exynos: modify wait_for_vblank and clear windows in dpms off

This patchset fixes the various issues which result in getting a PAGE FAULT while using fimd and hdmi in exynos drm. Changelog v2: Seperated patches into drm framework and fimd/mixer patches. Not using patch drm/exynos: do not disable crtc if already off Added two new patches for clearing windows

i915 freakout with latest 3.7 git

On 06.12.2012, Heinz Diehl wrote: [] Ok, the last one for today. After extensive testing with heavy load and I/O while watching HD videos, I can almost safely conclude with the following: 1.) The hang does *never* occur with 3.6.9 vanilla 2.) The hang does *always* occur with 3.7-rc8+ /

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

ld be easier, but I think won't work as the geometry would be clipped before it reaches the fragment stage. -- 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/

[Bug 57875] Second Life viewer bad rendering with git-ec83535

ttp://lists.freedesktop.org/archives/dri-devel/attachments/20121206/b10db43e/attachment-0001.html>

[PATCH 3/3] drm: mie: add mie driver for exynos

From: "R. Chandrasekar" Adding driver for the Mobile Image Enhancement (MIE) module of exynos SoC. This cl scope is limited to dithereing. mie dithering function is enabled from fimd Signed-off-by: R. Chandrasekar Change-Id: I05be2a2a5484719ff7bdeff722d95223191b077f ---

[PATCH 2/3] drm: fimd: add mie plugin support for dithering

From: "R. Chandrasekar" mie provides the dithereing functionality, fimd need to call the mie dithering function is required when panel uses lesser bits per pixel (bpp) of fimd. This cl adds the functions to add the mie plugin, and calls the mie dithereing function.

[PATCH 1/3] DTS: exynos: add device tree support for exynos mie

From: "R. Chandrasekar" adding device tree support for mobile image enhancement (mie) module of exynos SoC. driver fetches the base address of mie from the device tree. Signed-off-by: R. Chandrasekar --- arch/arm/boot/dts/exynos5250.dtsi |7 ++- 1 file changed, 6

[PATCH 0/3] add mie driver for exynos

From: "R. Chandrasekar" this patch set adds the driver support for the dithering functionality of the mobile image enhancement (mie) module. device tree support is added for mie. fimd adds the mie module as plugin and calls the dithering function. dithere is required when

i915 freakout with latest 3.7 git

On 06.12.2012, Heinz Diehl wrote: [] Here are some more error-logs, inkl. dmesg after booting with drm debug options turned on: http://www.fritha.org/i915/gpu-hang.tar.bz2

[PATCH] gpu: drm/nouveau/core/engine/disp/dacnv50.c: fix var uninit issue

the variable "ret" might be uninitialized in the "default" branch of "switch" Signed-off-by: Cong Ding --- drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/gpu/drm/nouveau/core/engine/disp/dacnv50.c

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

[Bug 57875] Second Life viewer bad rendering with git-ec83535

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

[RFC v2 3/5] drm: Add HDMI infoframe helpers

- 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/20121206/512f7495/attachment-0001.pgp>

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

e. But there's always the possibility that I've broken things horribly here since the patch is rather messy, so it's good that you look closely and some testing will certainly be good to validate that things still work as before. Thierry -- next part -- A non-text atta

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

On Thu, Dec 6, 2012 at 3:23 PM, Thierry Reding wrote: >> > - /* sdvo spec says that the ecc is handled by the hw, and it looks like >> > -* we must not send the ecc field, either. */ >> > - memcpy(sdvo_data, _if, 3); >> > - sdvo_data[3] = avi_if.checksum; >> >> This difference between

[Bug 57875] Second Life viewer bad rendering with git-ec83535

the aforementioned bug 39251. -- 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/20121206/8e7ec90e/attachment.html>

[RFC v2 3/5] drm: Add HDMI infoframe helpers

On Thu, Dec 6, 2012 at 3:28 PM, Thierry Reding wrote: >> Note that the intel avi infoframe in intel_hdmi_set_avi_infoframe also >> sets the pixel repeat for double clocked modes with: >> >> if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) >> avi_if.body.avi.YQ_CN_PR |=

[Intel-gfx] [PATCH] drm: Preallocate mm node for GTT mmap offset

On Thu, Dec 6, 2012 at 4:25 PM, Daniel Vetter wrote: > On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson > wrote: >> As the shrinker may be invoked for the allocation, and it may reap >> neighbouring objects in the offset range mm, we need to be careful in >> the order in which we allocate the node,

[Intel-gfx] [PATCH] drm: Preallocate mm node for GTT mmap offset

On Thu, Dec 6, 2012 at 3:54 PM, Chris Wilson wrote: > As the shrinker may be invoked for the allocation, and it may reap > neighbouring objects in the offset range mm, we need to be careful in > the order in which we allocate the node, search for free space and then > insert the node into the

First version of host1x intro

On 12/06/2012 04:00 PM, Lucas Stach wrote: > Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: [...] >> >> OK. So these relocation addresses are used to let userspace tells kernel >> which buffers mentioned in the command should be relocated to addresses >> which host1x clients able

[PATCH 3.7-rc8] ttm: Fix possible _manager memory allocation oops

On 12/06/2012 03:46 PM, Dave Airlie wrote: >> >> ttm_page_pool_init_locked(&_manager->wc_pool, GFP_HIGHUSER, "wc"); >> >> @@ -817,6 +821,7 @@ int ttm_page_alloc_init(struct ttm_mem_global *glob, >> unsigned max_pages) >> >kobj, "pool"); >> if

[Bug 57875] Second Life viewer bad rendering with git-ec83535

was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20121206/c89b9b1b/attachment.html>

First version of host1x intro

On 12/06/2012 03:20 PM, Lucas Stach wrote: > Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: > [...] >>> First action taken is taking a reference to all buffers in the command >>> stream. This includes the command stream buffers themselves, but also >>> the target buffers. We also

[RFC v2 3/5] drm: Add HDMI infoframe helpers

o > sets the pixel repeat for double clocked modes with: > > if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK) > avi_if.body.avi.YQ_CN_PR |= DIP_AVI_PR_2; I left that in place in the Intel driver, but I suppose we can just as well move it to the infoframe helpers since it should be a generic option. Thierry -- 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/20121206/0362c588/attachment.pgp>

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

andled by the respective drivers. So in fact the code should be working fine for HDMI and SDVO, since for the HDMI ports I explicitly left the fourth byte of the header empty, while for SDVO, the checksum is the one as computed by hdmi_avi_infoframe_pack(), which is at byte 3 and therefore matches th

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

On Wed, Dec 05, 2012 at 05:45:44PM +0100, Thierry Reding wrote: > Use the generic HDMI infoframe helpers to get rid of the duplicate > implementation in the i915 driver. > > Signed-off-by: Thierry Reding > diff --git a/drivers/gpu/drm/i915/intel_sdvo.c > b/drivers/gpu/drm/i915/intel_sdvo.c >

[RFC v2 3/5] drm: Add HDMI infoframe helpers

On Wed, Dec 05, 2012 at 05:45:42PM +0100, Thierry Reding wrote: > Add a generic helper to fill in an HDMI AVI infoframe with data > extracted from a DRM display mode. > > Signed-off-by: Thierry Reding A few quick comments below. > --- > Changes in v2: > - reuse CEA modes defined in

First version of host1x intro

On 12/05/2012 05:47 PM, Terje Bergstr?m wrote: > Hi, > [...] > > Channels > > > Channel is a push buffer containing HOST1X opcodes. The push buffer > boundaries are defined with `HOST1X_CHANNEL_DMASTART_0` and > `HOST1X_CHANNEL_DMAEND_0`. `HOST1X_CHANNEL_DMAGET_0` indicates the next >

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

Hi 2012/12/6 Paulo Zanoni : > Hi > > 2012/12/5 Thierry Reding : >> Use the generic HDMI infoframe helpers to get rid of the duplicate >> implementation in the i915 driver. > > A few comments: > > - I've compiled your patches and now "intel_infoframes -d" tells my my > infoframes are full of

[PATCH] drm: Preallocate mm node for GTT mmap offset

As the shrinker may be invoked for the allocation, and it may reap neighbouring objects in the offset range mm, we need to be careful in the order in which we allocate the node, search for free space and then insert the node into the mmap offset range manager. Signed-off-by: Chris Wilson Cc:

[RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

Hi 2012/12/5 Thierry Reding : > Use the generic HDMI infoframe helpers to get rid of the duplicate > implementation in the i915 driver. A few comments: - I've compiled your patches and now "intel_infoframes -d" tells my my infoframes are full of zeroes. So there's a bug somewhere... I have to

i915 freakout with latest 3.7 git

On 04.12.2012, Daniel Vetter wrote: > Yeah, if anyone can somewhat reliably reproduce this While writing a big file with dd and watching high resolution videos on youtube, I've managed to reproduce the hang. Unfortunately, it doesn't occur within seconds. Some playing around is neccessary, and

First version of host1x intro

On 06.12.2012 09:06, Mark Zhang wrote: > Thank you for the doc. So here I have questions: > > Push buffer contains a lot of opcodes for this channel. So when multiple > userspace processes submit jobs to this channel, all these jobs will be > saved in the push buffer and return, right? I mean,

First version of host1x intro

Am Donnerstag, den 06.12.2012, 16:13 +0800 schrieb Mark Zhang: > On 12/06/2012 04:00 PM, Lucas Stach wrote: [...] > > > > Or maybe I'm misunderstanding you and you mean it the other way around. > > You don't let userspace dictate the addresses, the relocation > > information just tells the kernel

[PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

Op 06-12-12 02:36, Jerome Glisse schreef: > On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst > wrote: >> This requires re-use of the seqno, which increases fairness slightly. >> Instead of spinning with a new seqno every time we keep the current one, >> but still drop all other reservations we

First version of host1x intro

On 12/06/2012 01:13 AM, Mark Zhang wrote: > On 12/06/2012 04:00 PM, Lucas Stach wrote: >> Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: > [...] >>> >>> OK. So these relocation addresses are used to let userspace tells kernel >>> which buffers mentioned in the command should be

[PATCH 1/6] drm/ttm: remove lru_lock around ttm_bo_reserve

Op 06-12-12 02:19, Jerome Glisse schreef: > On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst > wrote: >> There should no longer be assumptions that reserve will always succeed >> with the lru lock held, so we can safely break the whole atomic >> reserve/lru thing. As a bonus this fixes most

[PATCH v2] drm/exynos: use prime helpers

Simplify the Exynos prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. Signed-off-by: Aaron Plattner --- v2: fix dumb mistakes now that I have a toolchain that can compile-test this drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 156

[PATCH linux-next] i915: intel_set_mode: Reduce stack allocation from 500 bytes to 2 pointers

smatch warning: drivers/gpu/drm/i915/intel_display.c:7019 intel_set_mode() warn: function puts 500 bytes on stack Refactor so that saved_mode and saved_hwmode are dynamically allocated as opposed to being automatic variables. 500 bytes seems like it could run the potential for blowing the

[PATCH 3.7-rc8] drm: Fix possible EDID memory allocation oops

On Wed, Dec 5, 2012 at 2:00 PM, Tim Gardner wrote: > The result of drm_property_create_blob() is not checked for success > which could lead to a NULL pointer dereference. > > I was led to this by a smatch warning: > > drivers/gpu/drm/drm_crtc.c:3186 drm_mode_connector_update_edid_property() >

[PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

On Thu, Dec 6, 2012 at 5:52 AM, Maarten Lankhorst wrote: > Op 06-12-12 02:36, Jerome Glisse schreef: >> On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst >> wrote: >>> This requires re-use of the seqno, which increases fairness slightly. >>> Instead of spinning with a new seqno every time we

i915 freakout with latest 3.7 git

On 05.12.2012, Daniel Vetter wrote: > Nope, we could only reproduce quickly with rc6 enabled :( Could reproduce it today this way: dd if=/dev/zero of=deleteme bs=1M count=5 while watching several HD videos on Youtube. Just tried once, so I'm not shure if this will work all the way. Will

[PATCH 4/4] drm/exynos: use prime helpers

Simplify the Exynos prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. Signed-off-by: Aaron Plattner --- I still need to find a system to test this. drivers/gpu/drm/exynos/exynos_drm_dmabuf.c | 151 ++---

[PATCH 3/4] drm/radeon: use prime helpers

Simplify the Radeon prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. Signed-off-by: Aaron Plattner --- drivers/gpu/drm/radeon/radeon_drv.c | 17 ++-- drivers/gpu/drm/radeon/radeon_prime.c | 169 +- 2

[PATCH 2/4] drm/nouveau: use prime helpers

Simplify the Nouveau prime implementation by using the default behavior provided by drm_gem_prime_import and drm_gem_prime_export. Signed-off-by: Aaron Plattner --- drivers/gpu/drm/nouveau/nouveau_bo.h| 1 - drivers/gpu/drm/nouveau/nouveau_drm.c | 9 +-

[PATCH 1/4] drm: add prime helpers

Instead of reimplementing all of the dma_buf functionality in every driver, create helpers drm_prime_import and drm_prime_export that implement them in terms of new, lower-level hook functions: gem_prime_pin: callback when a buffer is created, used to pin buffers into GTT gem_prime_get_pages:

[PATCH 0/4] Prime helpers

This series adds helper functions that abstract the core parts of .gem_prime_import and .gem_prime_export so that drivers don't have to worry about the low-level details. These helpers are optional. A driver can use them by plugging in drm_gem_prime_import and drm_gem_prime_export into the

[PATCHv15 2/7] video: add display_timing and videomode

On Mon, 26 Nov 2012 16:39:58 +0100, Steffen Trumtrar wrote: > On Mon, Nov 26, 2012 at 02:37:26PM +0200, Tomi Valkeinen wrote: > > On 2012-11-26 11:07, Steffen Trumtrar wrote: > > > > > +/* > > > + * Subsystem independent description of a videomode. > > > + * Can be generated from struct

[RFC v2 3/5] drm: Add HDMI infoframe helpers

On 12/06/2012 08:28 AM, Thierry Reding wrote: > On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote: >> On 12/05/2012 05:45 PM, Thierry Reding wrote: >>> Add a generic helper to fill in an HDMI AVI infoframe with data >>> extracted from a DRM display mode. >> >> That's a very nice

[PATCH 3.7-rc8] ttm: Fix possible _manager memory allocation oops

Memory for _manager is allocated using kzalloc() but the result is not checked. Free _manager on error lest memory become orphaned. I was led to scrutinize ttm_page_alloc_init() from a smatch warning: drivers/gpu/drm/ttm/ttm_page_alloc.c:799 ttm_page_alloc_init() error: potential null

First version of host1x intro

Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: > On 12/06/2012 03:20 PM, Lucas Stach wrote: > > Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: > > [...] > >>> First action taken is taking a reference to all buffers in the command > >>> stream. This includes the

[RFC v2 3/5] drm: Add HDMI infoframe helpers

is? Thierry -- 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/20121206/9078e564/attachment.pgp>

First version of host1x intro

Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: [...] > > First action taken is taking a reference to all buffers in the command > > stream. This includes the command stream buffers themselves, but also > > the target buffers. We also map each buffer to target hardware to get a > >

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

On Wed, Dec 05, 2012 at 05:34:30PM +0100, Daniel Vetter wrote: On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding thierry.red...@avionic-design.de wrote: Imo that's worse, since now drm manages even more of the driver-hw binding process. In my dream world the drm driver just registers a normal

[Bug 55919] fatal error: nouveau/nouveau_device.h: No such file or directory

https://bugs.freedesktop.org/show_bug.cgi?id=55919 Tomasz P. son_of_the_osi...@interia.pl changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 35446] Problem with Blender and big textures

https://bugs.freedesktop.org/show_bug.cgi?id=35446 Tomasz P. son_of_the_osi...@interia.pl changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 57888] Amnesia shader compiler errors on RV350

https://bugs.freedesktop.org/show_bug.cgi?id=57888 --- Comment #10 from Tomasz P. son_of_the_osi...@interia.pl --- Created attachment 71054 -- https://bugs.freedesktop.org/attachment.cgi?id=71054action=edit fishbowl screenshot -- You are receiving this mail because: You are the assignee for

[Bug 57888] Amnesia shader compiler errors on RV350

https://bugs.freedesktop.org/show_bug.cgi?id=57888 --- Comment #11 from Tomasz P. son_of_the_osi...@interia.pl --- (In reply to comment #5) Created attachment 71019 [details] [review] Possible fix Does this patch help? The patch fixes compiler warning that there is too many ALU instructions

[Bug 57888] Amnesia shader compiler errors on RV350

https://bugs.freedesktop.org/show_bug.cgi?id=57888 --- Comment #12 from Tomasz P. son_of_the_osi...@interia.pl --- Ok I have got better screenshots from Amnesia. Mesa-git.png shows that there are textures missing but light is ok. with-patch.png shows textures but light is corrupted. -- You are

[Bug 57888] Amnesia shader compiler errors on RV350

https://bugs.freedesktop.org/show_bug.cgi?id=57888 --- Comment #13 from Tomasz P. son_of_the_osi...@interia.pl --- Created attachment 71059 -- https://bugs.freedesktop.org/attachment.cgi?id=71059action=edit before patch -- You are receiving this mail because: You are the assignee for the bug.

[Bug 57888] Amnesia shader compiler errors on RV350

https://bugs.freedesktop.org/show_bug.cgi?id=57888 --- Comment #14 from Tomasz P. son_of_the_osi...@interia.pl --- Created attachment 71060 -- https://bugs.freedesktop.org/attachment.cgi?id=71060action=edit with-patch -- You are receiving this mail because: You are the assignee for the bug.

[PATCH 3.7-rc8] drm: Fix possible EDID memory allocation oops

The result of drm_property_create_blob() is not checked for success which could lead to a NULL pointer dereference. I was led to this by a smatch warning: drivers/gpu/drm/drm_crtc.c:3186 drm_mode_connector_update_edid_property() error: potential null dereference 'connector-edid_blob_ptr'.

Re: [PATCH 0/6] drm/ttm: lru lock atomicity removal

On Fri, Nov 30, 2012 at 7:11 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the lru lists any more. As such we can finally fix the locking primitives

Re: [PATCH 1/6] drm/ttm: remove lru_lock around ttm_bo_reserve

On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this fixes most lockdep annotations for

Re: [PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other reservations we hold. Only when we succeed,

Re: [PATCH 0/6] drm/ttm: lru lock atomicity removal

On Wed, Dec 5, 2012 at 8:15 PM, Jerome Glisse j.gli...@gmail.com wrote: On Fri, Nov 30, 2012 at 7:11 AM, Maarten Lankhorst maarten.lankho...@canonical.com wrote: With all the previous patches there shouldn't be anything lying on the reservations being atomic with removal of the bo's from the

Re: First version of host1x intro

On 12/05/2012 05:47 PM, Terje Bergström wrote: Hi, [...] Channels Channel is a push buffer containing HOST1X opcodes. The push buffer boundaries are defined with `HOST1X_CHANNEL_DMASTART_0` and `HOST1X_CHANNEL_DMAEND_0`. `HOST1X_CHANNEL_DMAGET_0` indicates the next position

Re: First version of host1x intro

Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: [...] First action taken is taking a reference to all buffers in the command stream. This includes the command stream buffers themselves, but also the target buffers. We also map each buffer to target hardware to get a device

Re: [RFC v2 3/5] drm: Add HDMI infoframe helpers

On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote: On 12/05/2012 05:45 PM, Thierry Reding wrote: Add a generic helper to fill in an HDMI AVI infoframe with data extracted from a DRM display mode. That's a very nice patch series, comes in pretty handy. Thanks :) I've

Re: First version of host1x intro

On 12/06/2012 03:20 PM, Lucas Stach wrote: Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: [...] First action taken is taking a reference to all buffers in the command stream. This includes the command stream buffers themselves, but also the target buffers. We also map each

Re: First version of host1x intro

Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: On 12/06/2012 03:20 PM, Lucas Stach wrote: Am Donnerstag, den 06.12.2012, 15:06 +0800 schrieb Mark Zhang: [...] First action taken is taking a reference to all buffers in the command stream. This includes the command stream

Re: First version of host1x intro

On 12/06/2012 04:00 PM, Lucas Stach wrote: Am Donnerstag, den 06.12.2012, 15:49 +0800 schrieb Mark Zhang: [...] OK. So these relocation addresses are used to let userspace tells kernel which buffers mentioned in the command should be relocated to addresses which host1x clients able to reach.

Re: [RFC v2 3/5] drm: Add HDMI infoframe helpers

On 12/06/2012 08:28 AM, Thierry Reding wrote: On Wed, Dec 05, 2012 at 06:51:20PM +0100, Lars-Peter Clausen wrote: On 12/05/2012 05:45 PM, Thierry Reding wrote: Add a generic helper to fill in an HDMI AVI infoframe with data extracted from a DRM display mode. That's a very nice patch series,

Re: [PATCH 1/6] drm/ttm: remove lru_lock around ttm_bo_reserve

Op 06-12-12 02:19, Jerome Glisse schreef: On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: There should no longer be assumptions that reserve will always succeed with the lru lock held, so we can safely break the whole atomic reserve/lru thing. As a bonus this

Re: [PATCH 4/6] drm/ttm: use ttm_bo_reserve_slowpath_nolru in ttm_eu_reserve_buffers

Op 06-12-12 02:36, Jerome Glisse schreef: On Fri, Nov 30, 2012 at 7:12 AM, Maarten Lankhorst m.b.lankho...@gmail.com wrote: This requires re-use of the seqno, which increases fairness slightly. Instead of spinning with a new seqno every time we keep the current one, but still drop all other

Re: First version of host1x intro

Am Donnerstag, den 06.12.2012, 16:13 +0800 schrieb Mark Zhang: On 12/06/2012 04:00 PM, Lucas Stach wrote: [...] Or maybe I'm misunderstanding you and you mean it the other way around. You don't let userspace dictate the addresses, the relocation information just tells the kernel to find

Re: First version of host1x intro

On 06.12.2012 09:06, Mark Zhang wrote: Thank you for the doc. So here I have questions: Push buffer contains a lot of opcodes for this channel. So when multiple userspace processes submit jobs to this channel, all these jobs will be saved in the push buffer and return, right? I mean, nvhost

Re: [RFC v2 3/5] drm: Add HDMI infoframe helpers

On Wed, Dec 05, 2012 at 05:45:42PM +0100, Thierry Reding wrote: Add a generic helper to fill in an HDMI AVI infoframe with data extracted from a DRM display mode. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de A few quick comments below. --- Changes in v2: - reuse CEA

Re: [RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

On Wed, Dec 05, 2012 at 05:45:44PM +0100, Thierry Reding wrote: Use the generic HDMI infoframe helpers to get rid of the duplicate implementation in the i915 driver. Signed-off-by: Thierry Reding thierry.red...@avionic-design.de diff --git a/drivers/gpu/drm/i915/intel_sdvo.c

Re: [RFC v2 5/5] drm/i915: Use generic HDMI infoframe helpers

On Thu, Dec 06, 2012 at 03:16:31PM +0100, Daniel Vetter wrote: On Wed, Dec 05, 2012 at 05:45:44PM +0100, Thierry Reding wrote: Use the generic HDMI infoframe helpers to get rid of the duplicate implementation in the i915 driver. Signed-off-by: Thierry Reding

[PATCH v2 0/7] drm/exynos: modify wait_for_vblank and clear windows in dpms off

This patchset fixes the various issues which result in getting a PAGE FAULT while using fimd and hdmi in exynos drm. Changelog v2: Seperated patches into drm framework and fimd/mixer patches. Not using patch drm/exynos: do not disable crtc if already off Added two new patches for clearing windows

[PATCH 1/7] drm/exynos: make wait_for_vblank a manager op

The wait_for_vblank callback is moved from overlay ops to manager ops of exynos drm driver. Also, the check for DPMS OFF of encoder is removed before calling wait_for_vblank. Signed-off-by: Prathyush K prathyus...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_drv.h |6 +++---

[PATCH 2/7] drm/exynos: move hdmi's wait_for_vblank to manager_ops

The wait_for_vblank callback of hdmi and mixer is now moved from overlay_ops to manager_ops. Signed-off-by: Prathyush K prathyus...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_hdmi.c | 22 +++--- drivers/gpu/drm/exynos/exynos_drm_hdmi.h |2 +-

[PATCH 3/7] drm/exynos: move fimd wait_for_vblank to manager_ops

The wait for vblank callback is moved from overlay_ops to manager_ops for fimd. Signed-off-by: Prathyush K prathyus...@samsung.com --- drivers/gpu/drm/exynos/exynos_drm_fimd.c | 24 1 files changed, 12 insertions(+), 12 deletions(-) diff --git

[PATCH 4/7] drm/exynos: modify wait_for_vblank of mixer

It is more optimium to use wait queues while waiting for vsync so that the current task is put to sleep. This way, the task wont hog the CPU while waiting. We use wait_event_timeout and not an interruptible function since we dont want the function to exit when a signal is pending (e.g. drm

[PATCH 5/7] drm/exynos: modify wait_for_vblank of fimd

It is more optimium to use wait queues while waiting for vsync so that the current task is put to sleep. This way, the task wont hog the CPU while waiting. We use wait_event_timeout and not an interruptible function since we dont want the function to exit when a signal is pending (e.g. drm

  1   2   >