On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
> On 03.12.2012, devendra.aaru wrote:
>
>> Add more CC's
>
> Thanks!
>
> This is a real showstopper for me, it occurs in every session now.
> Booting with "i915.i915_enable_rc6=0" doesn't help
https://bugs.freedesktop.org/show_bug.cgi?id=55984
i
On Tue, Dec 4, 2012 at 10:27 AM, Dave Airlie wrote:
> On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
>> On 03.12.2012, devendra.aaru wrote:
>>
>>> Add more CC's
>>
>> Thanks!
>>
>> This is a real showstopper for me, it occurs in every session now.
>> Booting with "i915.i915_enable_rc6=0" does
https://bugs.freedesktop.org/show_bug.cgi?id=39308
--- Comment #6 from Tomasz P. ---
(In reply to comment #4)
> I don't have full access to my old machine with the rv350 anymore (I gave it
> to my father), but I'll try to test vdpau on it. If I don't answer in a
> month, feel free to close this b
Changelog v2:
fix page fault issue.
- defer to unreference old fb to avoid page fault issue.
So with this fixup, new fb would be updated to hardware
prior to old fb unreferencing. And it removes unnecessary
patch, "drm/exynos: Unreference fb in exynos_disable_plane()"
Changelog v1:
This patch rele
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing
On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
> On 04.12.2012, Daniel Vetter wrote:
>
> > Yeah, if anyone can somewhat reliably reproduce this
>
> Ok, I see. So the beginning would be to reliably reproduce the the
> hang. I have encountered it in any possbile situasjon, both when
On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae wrote:
> Changelog v2:
> fix page fault issue.
> - defer to unreference old fb to avoid page fault issue.
> So with this fixup, new fb would be updated to hardware
> prior to old fb unreferencing. And it removes unnecessary
> patch, "drm/exynos: Unreferenc
https://bugs.freedesktop.org/show_bug.cgi?id=57875
Priority: medium
Bug ID: 57875
Assignee: dri-devel@lists.freedesktop.org
Summary: Second Life viewer bad rendering with git-ec83535
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #1 from Piero Finizio ---
Created attachment 70995
--> https://bugs.freedesktop.org/attachment.cgi?id=70995&action=edit
The "blue triangles"
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #2 from Marek Olšák ---
Does reverting the commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 help?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mai
https://bugs.freedesktop.org/show_bug.cgi?id=41051
--- Comment #2 from Scott Moreau ---
(In reply to comment #1)
> Still you have the same problem ?
Yes, it's still the same problem with ubuntu 12.04, kernel 3.0.0, Mesa 9.1 and
wine 1.4.
--
You are receiving this mail because:
You are the assi
On 03.12.2012, devendra.aaru wrote:
> Add more CC's
Thanks!
This is a real showstopper for me, it occurs in every session now.
Booting with "i915.i915_enable_rc6=0" doesn't help either..
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
https://bugs.freedesktop.org/show_bug.cgi?id=57875
--- Comment #3 from Piero Finizio ---
Yes, reverting commit e866bd1adea2c3b4971ad68e69c644752f2ab7b6 works.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mail
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 release)
Currently wait_for_vblank is set as an overlay_op which is not
correct since wait for vblank is not dependant on any particular
overlay. It should be grouped with enable/disable vblank calls
inside manager_ops.
Also if wait for vblank is a manager op, the check for DPMS_OFF
of encoder can be remove
The crtc disable function should not disable the overlays if the
crtc is already in DPMS_OFF as this will lead to register access
when clock is off.
Also the crtc disable function should not call DPMS OFF of the
crtc. This is required to ensure we are able to wait for vblank
before freeing any fram
This patchset fixes a few issues with use of wait for vblank in
exynos drm.
Please apply these three patches without "drm/exynos: release fb pended by page
flip"
patch.
Patch 1: modify wait for vsync functions to use wait queues
This modifies the wait_for_vblank functions to use wait queues
thu
2012/12/4 Prathyush K
>
>
>
> On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae wrote:
>
>> Changelog v2:
>> fix page fault issue.
>> - defer to unreference old fb to avoid page fault issue.
>> So with this fixup, new fb would be updated to hardware
>> prior to old fb unreferencing. And it removes unnece
Hi,
I mentioned in a reply to Terje's patch series for 2D acceleration that
I had prototyped some libdrm support a few weeks back. I've spent a bit
of time cleaning it up and decided to post it for early review.
There's really not much interesting code here. A basic API is provided
along with two
Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.
Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.
Signed-off-by: Thierry Reding
---
Makefile.am | 6 +-
configure.ac | 15 ++-
in
On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
wrote:
> +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t size,
> +struct drm_tegra_bo **bop)
> +{
> + struct drm_tegra_gem_create args;
> + struct drm_tegra_bo *bo;
> + struct tegra_bo *pr
On Tue, Dec 04, 2012 at 09:28:25AM -0600, Rob Clark wrote:
> On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
> wrote:
> > +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t
> > size,
> > +struct drm_tegra_bo **bop)
> > +{
> > + struct drm_tegra_gem_c
https://bugs.freedesktop.org/show_bug.cgi?id=36554
Scott Moreau changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
From: Damien Lespiau
Instead of just printing "status updated from 1 to 2", make those enum
numbers immediately readable.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/drm_crtc_helper.c | 17 +++--
1 file changed, 15 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/d
On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae wrote:
> Changelog v2:
> fix page fault issue.
> - defer to unreference old fb to avoid page fault issue.
> So with this fixup, new fb would be updated to hardware
> prior to old fb unreferencing. And it removes unnecessary
> patch, "drm/exynos: Unreference
2012/12/5 Prathyush K
> This patchset fixes a few issues with use of wait for vblank in
> exynos drm.
>
> Please apply these three patches without "drm/exynos: release fb pended by
> page flip"
> patch.
>
> Patch 1: modify wait for vsync functions to use wait queues
> This modifies the wait_for_v
https://bugs.freedesktop.org/show_bug.cgi?id=37220
--- Comment #5 from Tomasz P. ---
(In reply to comment #4)
> I compiled latest mesa (git-51d0892) on my other, desktop computer with ATI
> Technologies Inc RV350 AR [Radeon 9600] and it has the same problem. Xorg
> server is 1.10.2, Linux kernel
2012/12/5 Daniel Vetter
> On Tue, Dec 4, 2012 at 1:14 PM, Inki Dae wrote:
> > Changelog v2:
> > fix page fault issue.
> > - defer to unreference old fb to avoid page fault issue.
> > So with this fixup, new fb would be updated to hardware
> > prior to old fb unreferencing. And it removes unneces
https://bugzilla.kernel.org/show_bug.cgi?id=51301
--- Comment #4 from Peter Hurley 2012-12-04
16:48:22 ---
Not sure why I picked kvm/nouveau for this OOM ;)
Could be any number of apps over a 3.5 period...
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
---
https://bugs.freedesktop.org/show_bug.cgi?id=36952
--- Comment #17 from Tomasz P. ---
I just instaled xscreensaver and run crackberg on rv350 / radeon 9600
agp.Normal memory usage nothing special.No warnings in logs. Animation works
without any artefacts or screen flashing.
--
You are receiving
https://bugs.freedesktop.org/show_bug.cgi?id=37485
--- Comment #2 from Tomasz P. ---
(In reply to comment #1)
> Is this still an issue with current Mesa git?
I playing with supertuxcart today.The game is boring so I don't test all
tracks,but I cannot see any rendering errors with hyperz on. I ru
On Tue, Dec 04, 2012 at 04:00:17PM +, Damien Lespiau wrote:
> From: Damien Lespiau
>
> Instead of just printing "status updated from 1 to 2", make those enum
> numbers immediately readable.
>
> Signed-off-by: Damien Lespiau
I like, stupid me can never remember the magic values. For the pat
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Priority: medium
Bug ID: 57888
Assignee: dri-devel@lists.freedesktop.org
Summary: Amnesia shader compiler errors on RV350
Severity: normal
Classification: Unclassified
OS: Li
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Scott Moreau changed:
What|Removed |Added
Attachment #71005|0 |1
is obsolete|
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #2 from Alex Deucher ---
If the game uses compressed textures, you may need to install libtxc_dxtn.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #3 from Tom Stellard ---
Could you run the program with the environment variable RADEON_DEBUG=fp and
then post the output.
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=34097
--- Comment #6 from Tomasz P. ---
on rv350 rendering in blender looks normal with mesa-git, is the situation
changed with current mesa ?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #3 from Roland Scheidegger ---
FWIW the relevant commit fixing this bug was
de694b6b10b7ce23a00cd7296a955f162704ee62.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #4 from Scott Moreau ---
Created attachment 71007
--> https://bugs.freedesktop.org/attachment.cgi?id=71007&action=edit
amnesia output with RADEON_DEBUG=fp
(In reply to comment #3)
> Could you run the program with the environment va
https://bugs.freedesktop.org/show_bug.cgi?id=57888
Andreas Boll changed:
What|Removed |Added
Attachment #71005|text/plain |image/png
mime type|
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #1 from Roland Scheidegger ---
Hmm this is odd I can't see anything wrong with the culling setup wrt fbos.
The viewport, window handling though seems somewhat bogus.
First, r200UpdateViewportOffset() has no callers (it is used in
rade
On Tue, Dec 4, 2012 at 9:41 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 13:35:22 Heinz Diehl wrote:
>> Btw: which kernel is known to be the "last good one"?
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
>
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #2 from Roland Scheidegger ---
Created attachment 71014
--> https://bugs.freedesktop.org/attachment.cgi?id=71014&action=edit
potential fixes for viewport trouble
I had something like this in mind. Untested though and all that viewp
On 04.12.2012, Lekensteyn wrote:
> As mentioned in the linked bug [1], I bisected it to:
>
> commit 504c7267a1e84b157cbd7e9c1b805e1bc0c2c846
> Author: Chris Wilson
> Date: Thu Aug 23 13:12:52 2012 +0100
>
> drm/i915: Use cpu relocations if the object is in the GTT but not mappable
Ok, b
On 04.12.2012, Daniel Vetter wrote:
> The important part is to not enable rc6 (on ironlake at least) when
> bisecting.
A shot in the dark: could it be that all the machines wich encounter
this hang have nvidia's optimus? Mine has. Could that somehow be
related? (I'm by no means a programmer or a
On Mon, Dec 03, 2012 at 12:23:32PM -0700, Stephen Warren wrote:
> On 12/01/2012 07:58 AM, Thierry Reding wrote:
> > On Sat, Dec 01, 2012 at 01:31:02PM +0200, Terje Bergström wrote:
> ...
> >> I was thinking of definitions like this:
> >>
> >> static inline u32 host1x_sync_cfpeek_ctrl_cfpeek_addr_f
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Marcelo Tosatti changed:
What|Removed |Added
CC||mtosa...@redhat.com
--- Comment #5
From: Alex Deucher
Need to use the adjusted mode since we are sending native
timing and using the scaler for non-native modes.
Signed-off-by: Alex Deucher
cc: sta...@vger.kernel.org
---
drivers/gpu/drm/radeon/atombios_encoders.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff
https://bugzilla.kernel.org/show_bug.cgi?id=51301
Alan changed:
What|Removed |Added
CC||a...@lxorguk.ukuu.org.uk
Component|kvm
On Tue, Dec 4, 2012 at 4:53 PM, wrote:
> From: Alex Deucher
>
> Need to use the adjusted mode since we are sending native
> timing and using the scaler for non-native modes.
>
> Signed-off-by: Alex Deucher
Reviewed-by: Jerome Glisse
> cc: sta...@vger.kernel.org
> ---
> drivers/gpu/drm/radeon/
On Tue, Dec 4, 2012 at 11:09 PM, Lekensteyn wrote:
> On Tuesday 04 December 2012 22:08:45 Heinz Diehl wrote:
>> Ok, but in comment 11 in the same thread you mention that reverting
>> this patch didn't fix the issue for you:
>>
>> "Reverting that commit on top of 3.7-rc4 did not fix the hang issue.
https://bugs.freedesktop.org/show_bug.cgi?id=37485
gsr.bugs changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugzilla.kernel.org/show_bug.cgi?id=51301
--- Comment #6 from Peter Hurley 2012-12-05
00:57:08 ---
This is filesystem/block or memory manager-related.
I just built -next-20121204 and by the end of the build a 10gb machine had <
100mb of zone DMA32 and < 70mb zone
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #5 from Tom Stellard ---
Created attachment 71019
--> https://bugs.freedesktop.org/attachment.cgi?id=71019&action=edit
Possible fix
Does this patch help?
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #6 from Scott Moreau ---
(In reply to comment #5)
> Created attachment 71019 [details] [review]
> Possible fix
>
> Does this patch help?
Yes this fixes the problem. The shaders work without error and the content is
rendered which ma
2012/12/5 Inki Dae
>
>
> 2012/12/4 Prathyush K
>
>>
>>
>>
>> On Tue, Dec 4, 2012 at 5:44 PM, Inki Dae wrote:
>>
>>> Changelog v2:
>>> fix page fault issue.
>>> - defer to unreference old fb to avoid page fault issue.
>>> So with this fixup, new fb would be updated to hardware
>>> prior to old f
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>> This patchset fixes a few issues with use of wait for vblank in
>> exynos drm.
>>
>> Please apply these three patches without "drm/exynos: release fb pended
>> by page flip"
>> patch.
>>
>> Patch 1: modify wait for vsync functions to use wait q
Hi,
Please check the reference counts for framebuffers: This is for one
modetest (without flipping)
Bootup:
[2.31] KP: drm_framebuffer_init edb86900 - fb0
refcount 1
[2.31] KP: drm_framebuffer_reference edb86900 - fb0
refcount 2
Modetest:
[ 26.56]
On 05.12.2012, Lekensteyn wrote:
> > I have now i915.i915_enable_rc6=0 in grub.cfg and disabled the XFCE
> > compositor. Now I'm trying to hit the bug again...
> Do you have a reliable reproduce method? As you can see in the linked bug it
> was caused by relatively low memory pressure combined wi
On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>
>
> 2012/12/5 Inki Dae
>
>>
>>
>> 2012/12/5 Prathyush K
>>
>>> This patchset fixes a few issues with use of wait for vblank in
>>> exynos drm.
>>>
>>> Please apply these three patches without "drm/exynos: release fb pended
>>> by page flip"
>>>
Hi
2012/12/5 Prathyush K
> Hi,
>
> Please check the reference counts for framebuffers: This is for one
> modetest (without flipping)
>
> Bootup:
> [2.31] KP: drm_framebuffer_init edb86900 - fb0
> refcount 1
> [2.31] KP: drm_framebuffer_reference edb86900
2012/12/5 Prathyush K
>
>
>
> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>
>>
>>
>> 2012/12/5 Inki Dae
>>
>>>
>>>
>>> 2012/12/5 Prathyush K
>>>
This patchset fixes a few issues with use of wait for vblank in
exynos drm.
Please apply these three patches without "drm/ex
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>>
>>
>>
>> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>>
>>>
>>>
>>> 2012/12/5 Inki Dae
>>>
2012/12/5 Prathyush K
> This patchset fixes a few issues with use of wait for vblank in
> exynos drm.
>
> Ple
2012/12/5 Inki Dae
>
>
> 2012/12/5 Inki Dae
>
>>
>>
>> 2012/12/5 Prathyush K
>>
>>>
>>>
>>>
>>> On Wed, Dec 5, 2012 at 11:40 AM, Inki Dae wrote:
>>>
2012/12/5 Inki Dae
>
>
> 2012/12/5 Prathyush K
>
>> This patchset fixes a few issues with use of wait f
On Wed, Dec 05, 2012 at 09:39:11AM +0200, Arto Merilainen wrote:
> On 12/04/2012 05:13 PM, Thierry Reding wrote:
> >+int drm_tegra_open(const char *path, struct drm_tegra **devicep)
> >+{
> >+ struct drm_tegra *device;
> >+ int err;
> >+
> >+ if (!path || !devicep)
> >+
Hello Steffen,
Any update on version 16 ?
Best Wishes,
Leela Krishna Amudala.
On Mon, Nov 26, 2012 at 2:37 PM, Steffen Trumtrar
wrote:
> Hi!
>
> Changes since v14:
> - fix "const struct *" warning
> (reported by: Leela Krishna Amudala )
> - return -EINVAL when ht
g 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/20121204/20c8b80f/attachment.html>
g 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/20121204/63254344/attachment.html>
On 12/03/2012 05:40 PM, Daniel Vetter wrote:
> On Mon, Dec 3, 2012 at 10:30 AM, Mark Zhang wrote:
>> I'm new in kernel development. Could you tell me or give me some
>> materials to read that why we need to align the size of IOCTL structures
>> to 64bit? I can understand if we're working in a 64bi
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>> I think there's room for letting Terje's complete knowledge of future
>> chips guide the design of the current code that's sent upstream.
>> Certainly we shouldn't add a ton of unnecessary abstraction layers
>> right now that aren't needed for
On 12/04/2012 05:03 AM, Thierry Reding wrote:
[...]
>
> One other thing that such a design can help with is refactoring common
> code or parameterizing code. Maybe newer generations are not compatible
> but can easily be made to work with existing code by introducing a
> variable such as register
On 11/28/2012 02:37 PM, Mark Zhang wrote:
> On 11/28/2012 05:39 AM, Stephen Warren wrote:
>> On 11/27/2012 11:17 AM, Stephen Warren wrote:
>>> On 11/26/2012 08:16 PM, Mark Zhang wrote:
On 11/27/2012 06:37 AM, Stephen Warren wrote:
> On 11/22/2012 12:37 PM, Thierry Reding wrote:
>> Inst
On 12/04/2012 11:50 AM, Stephen Warren wrote:
> On 12/03/2012 08:00 PM, Mark Zhang wrote:
>> On 11/28/2012 02:37 PM, Mark Zhang wrote:
>>> On 11/28/2012 05:39 AM, Stephen Warren wrote:
On 11/27/2012 11:17 AM, Stephen Warren wrote:
> On 11/26/2012 08:16 PM, Mark Zhang wrote:
>> On 11/27
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5e766406/attachment.html>
; /* manager */
> + .iommu_on = mixer_iommu_on,
> .enable_vblank = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = &pdev->dev;
> + ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/170f18c4/attachment-0001.html>
Changelog v2:
move iommu support feature to mixer side.
And below is Prathyush's comment.
According to the new IOMMU framework for exynos sysmmus,
the owner of the sysmmu-tv is mixer (which is the actual
device that does DMA) and not hdmi.
The mmu-master in sysmmu-tv node is set as below in exynos
r_res;
> @@ -866,6 +887,7 @@ static void mixer_win_disable(void *ctx, int win)
>
> static struct exynos_mixer_ops mixer_ops = {
> /* manager */
> + .iommu_on = mixer_iommu_on,
> .enable_vblank = mixer_enable_vblank,
> .disable_vblank = mixer_disable_vblank,
> .dpms = mixer_dpms,
> @@ -1149,6 +1171,7 @@ static int __devinit mixer_probe(struct
> platform_device *pdev)
> }
>
> ctx->dev = &pdev->dev;
> + ctx->parent_ctx = (void *)drm_hdmi_ctx;
> drm_hdmi_ctx->ctx = (void *)ctx;
> ctx->vp_enabled = drv->is_vp_enabled;
> ctx->mxr_ver = drv->version;
> --
> 1.7.0.4
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5f8a7a94/attachment-0001.html>
On 03.12.2012 23:03, Thierry Reding wrote:
> What's really difficult to follow is if an ops structure is accessed via
> some global macro. It also breaks encapsulation because you have a
> global ops structure. That may even work fine for now, but it will break
> once you have more than a single ho
On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
> On 03.12.2012, devendra.aaru wrote:
>
>> Add more CC's
>
> Thanks!
>
> This is a real showstopper for me, it occurs in every session now.
> Booting with "i915.i915_enable_rc6=0" doesn't help
https://bugs.freedesktop.org/show_bug.cgi?id=55984
i
On Tue, Dec 4, 2012 at 10:27 AM, Dave Airlie wrote:
> On Tue, Dec 4, 2012 at 6:36 PM, Heinz Diehl wrote:
>> On 03.12.2012, devendra.aaru wrote:
>>
>>> Add more CC's
>>
>> Thanks!
>>
>> This is a real showstopper for me, it occurs in every session now.
>> Booting with "i915.i915_enable_rc6=0" does
is 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/20121204/76afc31e/attachment.html>
Changelog v2:
fix page fault issue.
- defer to unreference old fb to avoid page fault issue.
So with this fixup, new fb would be updated to hardware
prior to old fb unreferencing. And it removes unnecessary
patch, "drm/exynos: Unreference fb in exynos_disable_plane()"
Changelog v1:
This patch rele
On 04.12.2012, Daniel Vetter wrote:
> Yeah, if anyone can somewhat reliably reproduce this
Ok, I see. So the beginning would be to reliably reproduce the the
hang. I have encountered it in any possbile situasjon, both when
watching videos on Youtube and right after booting the machine and
doing
On Tue, Dec 04, 2012 at 01:35:22PM +0100, Heinz Diehl wrote:
> On 04.12.2012, Daniel Vetter wrote:
>
> > Yeah, if anyone can somewhat reliably reproduce this
>
> Ok, I see. So the beginning would be to reliably reproduce the the
> hang. I have encountered it in any possbile situasjon, both when
e the fb.
> +*
> +* This means that memory region to the fb isn't accessed by the
> dma
> +* of this plane anymore.
> +*/
> + if (plane->fb)
> + drm_framebuffer_unreference(plane->fb);
> +
> + plane->fb = fb;
> +
> return 0;
> }
>
> @@ -215,6 +233,14 @@ static int exynos_disable_plane(struct drm_plane
> *plane)
> {
> DRM_DEBUG_KMS("[%d] %s\n", __LINE__, __func__);
>
> + /*
> +* Unreference the (current)fb if plane->fb is existed.
> +* In exynos_update_plane(), the new fb reference count can be
> bigger
> +* than 1. So it can't be removed for that reference count.
> +*/
> + if (plane->fb)
> + drm_framebuffer_unreference(plane->fb);
> +
> exynos_plane_dpms(plane, DRM_MODE_DPMS_OFF);
>
> return 0;
> --
> 1.7.4.1
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/5d0cc13a/attachment-0001.html>
chment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/f1437b97/attachment.html>
ignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/e0a0613f/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/a17f42a3/attachment.html>
are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/ef1fb19d/attachment.html>
On 03.12.2012, devendra.aaru wrote:
> Add more CC's
Thanks!
This is a real showstopper for me, it occurs in every session now.
Booting with "i915.i915_enable_rc6=0" doesn't help either..
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/e6ba0598/attachment.html>
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 release)
Currently wait_for_vblank is set as an overlay_op which is not
correct since wait for vblank is not dependant on any particular
overlay. It should be grouped with enable/disable vblank calls
inside manager_ops.
Also if wait for vblank is a manager op, the check for DPMS_OFF
of encoder can be remove
The crtc disable function should not disable the overlays if the
crtc is already in DPMS_OFF as this will lead to register access
when clock is off.
Also the crtc disable function should not call DPMS OFF of the
crtc. This is required to ensure we are able to wait for vblank
before freeing any fram
This patchset fixes a few issues with use of wait for vblank in
exynos drm.
Please apply these three patches without "drm/exynos: release fb pended by page
flip"
patch.
Patch 1: modify wait for vsync functions to use wait queues
This modifies the wait_for_vblank functions to use wait queues
thu
Hi,
I mentioned in a reply to Terje's patch series for 2D acceleration that
I had prototyped some libdrm support a few weeks back. I've spent a bit
of time cleaning it up and decided to post it for early review.
There's really not much interesting code here. A basic API is provided
along with two
Add the libdrm_tegra helper library to encapsulate Tegra-specific
interfaces to the DRM.
Furthermore, Tegra is added to the list of supported chips in the
modetest and vbltest programs.
Signed-off-by: Thierry Reding
---
Makefile.am | 6 +-
configure.ac | 15 ++-
in
On Tue, Dec 4, 2012 at 9:13 AM, Thierry Reding
wrote:
> +int drm_tegra_bo_new(struct drm_tegra *device, uint32_t flags, uint32_t size,
> +struct drm_tegra_bo **bop)
> +{
> + struct drm_tegra_gem_create args;
> + struct drm_tegra_bo *bo;
> + struct tegra_bo *pr
GEM objects are backed by CMA, and
therefore the offset will be created along with the GEM anyway.
With Terje's upcoming rework that handles all the allocations in host1x
this should become more important, especially when the mapping is done
through the Tegra30's IOMMU.
I'll rework that. Thanks for the quick reply.
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/20121204/4e69453b/attachment-0001.pgp>
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121204/d1af243a/attachment.html>
1 - 100 of 130 matches
Mail list logo
