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
Date: Thu Aug 23 13:12:52 2012 +0100
drm/i915: Use cpu
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."
The bisected commit was from between rc2 and rc3:
$ git
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)
+ return -EINVAL;
+
+ device = calloc(1, sizeof(*device));
+ if (!device
On Mon, Nov 26, 2012 at 03:19:12PM +0200, Terje Bergstrom wrote:
> From: Arto Merilainen
>
> This patch removes the redundant host1x driver from tegradrm and
> makes necessary bindings to the separate host driver.
>
> This modification introduces a regression: Because there is no
> general frame
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #3 from Stefan Dösinger ---
Created attachment 71022
--> https://bugs.freedesktop.org/attachment.cgi?id=71022&action=edit
Fix for attachment 71014
The patch needed this small fix to compile. It seems that my gcc doesn't like
logica
https://bugs.freedesktop.org/show_bug.cgi?id=57842
--- Comment #4 from Stefan Dösinger ---
(In reply to comment #3)
> Clipping is still broken.
Sorry, this should read "culling is still broken".
--
You are receiving this mail because:
You are the assignee for the bug.
__
Hi Leela,
unfortunately, nothing new as of yet. I have to work on other stuff at the
moment.
Regards,
Steffen
On Wed, Dec 05, 2012 at 01:25:30PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> Any update on version 16 ?
>
> Best Wishes,
> Leela Krishna Amudala.
>
> On Mon, Nov 26,
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #4 from Stefan Dösinger ---
Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the
hardware have a nicer way to deal with this?
It's now also applying ATI_fragment_shader shaders when clearing. I'll send a
patch f
Hi,
I created a base for host1x introduction text, and pasted it into
https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction. For
convenience, I also copy it below.
As I've worked with all of this for so long, I cannot know what areas
are most interesting to you, so I just tried to put in
On 05.12.2012 10:33, Thierry Reding wrote:
> I've been thinking about this some more and came to the conclusion that
> since we will already have a tight coupling between host1x and tegra-drm
> we may just as well keep the client registration code in host1x. The way
> I imagine this to work would b
On Wed, Dec 05, 2012 at 12:10:50PM +0200, Terje Bergström wrote:
> On 05.12.2012 10:33, Thierry Reding wrote:
> > I've been thinking about this some more and came to the conclusion that
> > since we will already have a tight coupling between host1x and tegra-drm
> > we may just as well keep the cli
On 05.12.2012 13:13, Thierry Reding wrote:
> What I propose is to move the client registration code that is currently
> in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may
> not end up in drivers/gpu/host1x.
Ok.
>
>> host1x hardware access must be encapsulated in host1x driv
Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergström:
[...]
>
> > The problem that this solves is that the DRM driver needs to be bound to
> > a specific platform device. None of the DRM subdevices are suitable
> > because they are only part of the whole DRM device. I think that host1x
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström wrote:
> You're right in that binding to a sub-device is not a nice way. DRM
> framework just needs a "struct device" to bind to. exynos seems to solve
> this by introducing a virtual device and bind to that. I'm not sure if
> this is the best way,
Dear Prathyush
Thank's your clarification.
I have one opinion about your [PATCH 1/3]
How about to add atomic_read() condition in each irq_handler ?
like this.
e.g)
+ if (atomic_read(&ctx->wait_vsync_event)) {
+ /* set wait vsync event to zero and wake up queue. */
+
On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> On 05.12.2012 13:13, Thierry Reding wrote:
[...]
> > Oh well, at the time nobody from NVIDIA was involved so I wrote that
> > code in preparation for proper host1x support that I thought I would
> > have to add myself at some point.
On Wed, Dec 5, 2012 at 5:33 PM, Eunchul Kim wrote:
> Dear Prathyush
>
> Thank's your clarification.
>
> I have one opinion about your [PATCH 1/3]
> How about to add atomic_read() condition in each irq_handler ?
> like this.
>
> e.g)
>
Hi Eunchul,
Yes, I think this is better. I'll modify this in
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual dev
On Wed, Dec 05, 2012 at 01:03:14PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergström
> wrote:
> > You're right in that binding to a sub-device is not a nice way. DRM
> > framework just needs a "struct device" to bind to. exynos seems to solve
> > this by introducing a
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
wrote:
> Maybe something more elaborate could help, though. Suppose we add
> functionality to DRM to instantiate a DRM device. We could call such a
> function from the host1x driver to add a device which the tegra-drm
> driver could bind to. This woul
On Wed, Dec 05, 2012 at 01:31:54PM +0100, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
> wrote:
> > Maybe something more elaborate could help, though. Suppose we add
> > functionality to DRM to instantiate a DRM device. We could call such a
> > function from the host1x dri
On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae wrote:
> 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
https://bugs.freedesktop.org/show_bug.cgi?id=40554
--- Comment #5 from Roland Scheidegger ---
(In reply to comment #4)
> Clearing by drawing geometry? Isn't that somewhat inefficient? Doesn't the
> hardware have a nicer way to deal with this?
There are two normal methods how you can do ordinary b
On 05.12.2012 14:04, Thierry Reding wrote:
> On Wed, Dec 05, 2012 at 01:47:38PM +0200, Terje Bergström wrote:
> Yes, but there's more. For instance I went to great lengths to make sure
> there's no global data whatsoever. So all the data is bound to the
> host1x device in the current code. I know m
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #13 from Tomasz P. ---
Do you have s3tc support enabled?
For me only in lower as possible graphics options game is playable and most
textures looks normal(game is quite dark so hard to say).In higher graphics
detail indeed textures ar
https://bugs.freedesktop.org/show_bug.cgi?id=34097
Sven Arvidsson changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #14 from Tomasz P. ---
> (In reply to comment #10)
> > Do you have still the same problem with current mesa ? On my rv350 works
> > good.
>
> Can you say what distro, kernel and mesa version you're using?
Arch linux x64 , mesa-git,
https://bugs.freedesktop.org/show_bug.cgi?id=37220
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=36952
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=41579
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=42622
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=42002
--- Comment #7 from Tomasz P. ---
Xorg state tracker is deprecated, so I think we can close this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=42002
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=42009
--- Comment #4 from Tomasz P. ---
Xorg state tracker is deprecated, so I think we can close this bug.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing li
https://bugs.freedesktop.org/show_bug.cgi?id=42009
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #7 from Tomasz P. ---
I also waiting to merge this patch to master. :)
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
On Wed, Dec 5, 2012 at 2:28 PM, Thierry Reding
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 driver at module load time directly with whatever bus it's
>> interested in, and then, from i
https://bugs.freedesktop.org/show_bug.cgi?id=54767
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
During the development of this series I ran into a couple of build
failures caused by missing forward declarations. They are added in the
first patch of this series.
Patch 2 adds generic helpers to pack a structures that describe HDMI
AVI, audio, vendor-specific or SPD infoframes into the binary f
The drm_file and drm_clip_rect structures are used throughout the file
but they are never declared nor pulled in through an include. Add
forward declarations to make them available.
Signed-off-by: Thierry Reding
---
include/drm/drm_crtc.h | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
Add generic helpers to pack HDMI infoframes into binary buffers.
Signed-off-by: Thierry Reding
---
Changes in v2:
- add support for audio, vendor-specific and SPD infoframes
- add various validity checks on infoframes
- factor out checksum computation
drivers/video/Kconfig | 3 +
drivers/vid
Add a generic helper to fill in an HDMI AVI infoframe with data
extracted from a DRM display mode.
Signed-off-by: Thierry Reding
---
Changes in v2:
- reuse CEA modes defined in drm_edid_modes.h
drivers/gpu/drm/Kconfig| 7 +
drivers/gpu/drm/Makefile | 1 +
drivers/gpu/drm/drm_hdmi.c
Use the generic HDMI infoframe helpers to get rid of the duplicate
implementation in the i915 driver.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/Kconfig | 2 +
drivers/gpu/drm/i915/intel_drv.h | 62 +
drivers/gpu/drm/i915/intel_hdmi.c | 268 +-
Use the generic HDMI infoframe helpers to get rid of the NVIDIA Tegra
reimplementation.
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/tegra/Kconfig | 1 +
drivers/gpu/drm/tegra/hdmi.c | 226 --
drivers/gpu/drm/tegra/hdmi.h | 189 ---
https://bugs.freedesktop.org/show_bug.cgi?id=30401
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=36554
--- Comment #15 from Scott Moreau ---
(In reply to comment #13)
> Do you have s3tc support enabled?
Yes.
> For me only in lower as possible graphics options game is playable and most
> textures looks normal(game is quite dark so hard to say).In
https://bugs.freedesktop.org/show_bug.cgi?id=55606
Tomasz P. changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://bugs.freedesktop.org/show_bug.cgi?id=35446
--- Comment #7 from Tomasz P. ---
Is there still a problem with that?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.o
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 just one comment.
> [...]
> +static inline enum hdmi_picture_aspect
> +drm_d
https://bugs.freedesktop.org/show_bug.cgi?id=57918
Priority: medium
Bug ID: 57918
Assignee: dri-devel@lists.freedesktop.org
Summary: Amnesia causes shader compiler errors on RV350 with
high graphics settings
Severity: normal
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #8 from Scott Moreau ---
(In reply to comment #6)
> (In reply to comment #5)
> > Created attachment 71019 [details] [review] [review]
> > Possible fix
> >
> > Does this patch help?
>
> Yes this fixes the problem. The shaders work wi
https://bugs.freedesktop.org/show_bug.cgi?id=57919
Priority: medium
Bug ID: 57919
Assignee: dri-devel@lists.freedesktop.org
Summary: Visual glitches in unity with Radeon HD 7600M
Severity: normal
Classification: Unclassified
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #1 from Thilo Cestonaro ---
Created attachment 71036
--> https://bugs.freedesktop.org/attachment.cgi?id=71036&action=edit
LIBGL_DEBUG=verbose glxinfo >glxinfo_libgl_debug_verbose.txt 2>&1
--
You are receiving this mail because:
Yo
https://bugs.freedesktop.org/show_bug.cgi?id=57919
--- Comment #2 from Thilo Cestonaro ---
Created attachment 71037
--> https://bugs.freedesktop.org/attachment.cgi?id=71037&action=edit
Xorg log
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=57919
Thilo Cestonaro changed:
What|Removed |Added
Hardware|Other |x86-64 (AMD64)
OS|All
https://bugs.freedesktop.org/show_bug.cgi?id=35446
--- Comment #8 from Václav Čermák ---
That old machine with Radeon X1400 is gone now (machine works, I can log in
through ssh, but display shows nothing, it is hardware failure, because is does
not show even setup), so I cannot test it. In new la
https://bugs.freedesktop.org/show_bug.cgi?id=57888
--- Comment #9 from Tomasz P. ---
I also noticed that there is some graphical problems...but game require Radeon
X1000/GeForce 6, so rv350 is'nt supported...
http://www.amnesiagame.com/#buy
--
You are receiving this mail because:
You are the a
https://bugs.freedesktop.org/show_bug.cgi?id=38692
--- Comment #1 from Tomasz P. ---
Is the problem still exists ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
htt
https://bugs.freedesktop.org/show_bug.cgi?id=36723
--- Comment #2 from Tomasz P. ---
The problem still exists with current mesa-git ?
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing list
dri-devel@lists.
https://bugs.freedesktop.org/show_bug.cgi?id=36723
--- Comment #3 from Pavel Ondračka ---
(In reply to comment #2)
> The problem still exists with current mesa-git ?
Yeah, the broken fog is still there.
--
You are receiving this mail because:
You are the assignee for the bug.
_
https://bugs.freedesktop.org/show_bug.cgi?id=36723
--- Comment #4 from Marek Olšák ---
This is not a compiler issue. The fog isn't rendered properly, because there
are not enough varyings. I have a patch that reuses unused color varyings for
texcoords. It fixes the fog, but it also breaks a lot o
Dear Inki Dae
Sorry. I was too late. I have some issue about another part.
Thank's for comments.
I make some comments and checked IPP routine for comment out.
almost finished. so, I can sent RFC v2 until this week.
I added little comment of your comments. please check that.
Thank's
BR
Eunchul K
return ret;
>>
>> - plane->crtc = crtc;
>> + /*
>> +* Take a reference to new fb.
>> +*
>> +* Taking a reference means that this plane's dma is going to
>> access
>> +* memory region to the new fb.
>> +*/
>> + drm_framebuffer_reference(fb);
>>
>> + plane->crtc = crtc;
>> exynos_plane_commit(plane);
>> exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
>>
>> + /*
>> +* If plane->fb is existed, unreference 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
>>
>
>
> ___
> 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/20121205/fec84bf3/attachment-0001.html>
___
> 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/20121205/10833684/attachment.html>
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
> ___
> 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/20121205/46f9f9bc/attachment-0001.html>
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 NORMAL.
--
Confi
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121205/74931355/attachment.html>
op.org/archives/dri-devel/attachments/20121205/6de41bf0/attachment-0001.html>
return;
>>>
>>> drm_fb_helper_restore_fbdev_mode(private->fb_helper);
>>> +
>>> + mutex_lock(&dev->mode_config.mutex);
>>> +
>>> + /* Release fb pended by page flip. */
>>> + list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list,
>>> head)
>>> + exynos_drm_release_pended_fb(fb);
>>> +
>>> + mutex_unlock(&dev->mode_config.mutex);
>>> }
>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> index 862ca1e..81d7323 100644
>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>> @@ -203,11 +203,29 @@ exynos_update_plane(struct drm_plane *plane,
>>> struct drm_crtc *crtc,
>>> if (ret < 0)
>>> return ret;
>>>
>>> - plane->crtc = crtc;
>>> + /*
>>> +* Take a reference to new fb.
>>> +*
>>> +* Taking a reference means that this plane's dma is going to
>>> access
>>> +* memory region to the new fb.
>>> +*/
>>> + drm_framebuffer_reference(fb);
>>>
>>> + plane->crtc = crtc;
>>> exynos_plane_commit(plane);
>>> exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
>>>
>>> + /*
>>> +* If plane->fb is existed, unreference 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
>>>
>>
>>
>> ___
>> 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/20121205/cae8647f/attachment-0001.html>
>> 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 | 37
>> +++++-
>> 7 files changed, 73 insertions(+), 66 deletions(-)
>>
>> ___
>> 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/20121205/e1b4b67f/attachment.html>
truct drm_framebuffer *fb);
>>>> +
>>>> /* get memory information of a drm framebuffer */
>>>> struct exynos_drm_gem_buf *exynos_drm_fb_buffer(struct drm_framebuffer
>>>> *fb,
>>>> int index);
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>> index e7466c4..62f3b9e 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>> @@ -314,9 +314,18 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
>>>> void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
>>>> {
>>>> struct exynos_drm_private *private = dev->dev_private;
>>>> + struct drm_framebuffer *fb, *fbt;
>>>>
>>>> if (!private || !private->fb_helper)
>>>> return;
>>>>
>>>> drm_fb_helper_restore_fbdev_mode(private->fb_helper);
>>>> +
>>>> + mutex_lock(&dev->mode_config.mutex);
>>>> +
>>>> + /* Release fb pended by page flip. */
>>>> + list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list,
>>>> head)
>>>> + exynos_drm_release_pended_fb(fb);
>>>> +
>>>> + mutex_unlock(&dev->mode_config.mutex);
>>>> }
>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>> index 862ca1e..81d7323 100644
>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>> @@ -203,11 +203,29 @@ exynos_update_plane(struct drm_plane *plane,
>>>> struct drm_crtc *crtc,
>>>> if (ret < 0)
>>>> return ret;
>>>>
>>>> - plane->crtc = crtc;
>>>> + /*
>>>> +* Take a reference to new fb.
>>>> +*
>>>> +* Taking a reference means that this plane's dma is going to
>>>> access
>>>> +* memory region to the new fb.
>>>> +*/
>>>> + drm_framebuffer_reference(fb);
>>>>
>>>> + plane->crtc = crtc;
>>>> exynos_plane_commit(plane);
>>>> exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
>>>>
>>>> + /*
>>>> +* If plane->fb is existed, unreference 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
>>>>
>>>
>>>
>>> ___
>>> 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/20121205/fc6374b9/attachment-0001.html>
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
| 20 ++
>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 15 +++
>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 37
>>> ++
>>> drivers/gpu/drm/exynos/exynos_drm_hdmi.c| 22
>>> drivers/gpu/drm/exynos/exynos_drm_hdm
/drivers/gpu/drm/exynos/exynos_drm_fb.h
>>>>> index 96262e5..6b63bb1 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fb.h
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fb.h
>>>>> @@ -33,6 +33,12 @@ exynos_drm_framebuffer_init(struct drm_device *dev,
>>>>> struct drm_mode_fb_cmd2 *mode_cmd,
>>>>> struct drm_gem_object *obj);
>>>>>
>>>>> +/* set fb->pending variable to desired value. */
>>>>> +void exynos_drm_fb_set_pending(struct drm_framebuffer *fb, bool
>>>>> pending);
>>>>> +
>>>>> +/* release a fb pended by page flip. */
>>>>> +void exynos_drm_release_pended_fb(struct drm_framebuffer *fb);
>>>>> +
>>>>> /* get memory information of a drm framebuffer */
>>>>> struct exynos_drm_gem_buf *exynos_drm_fb_buffer(struct
>>>>> drm_framebuffer *fb,
>>>>> int index);
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>>> b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>>> index e7466c4..62f3b9e 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
>>>>> @@ -314,9 +314,18 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
>>>>> void exynos_drm_fbdev_restore_mode(struct drm_device *dev)
>>>>> {
>>>>> struct exynos_drm_private *private = dev->dev_private;
>>>>> + struct drm_framebuffer *fb, *fbt;
>>>>>
>>>>> if (!private || !private->fb_helper)
>>>>> return;
>>>>>
>>>>> drm_fb_helper_restore_fbdev_mode(private->fb_helper);
>>>>> +
>>>>> + mutex_lock(&dev->mode_config.mutex);
>>>>> +
>>>>> + /* Release fb pended by page flip. */
>>>>> + list_for_each_entry_safe(fb, fbt, &dev->mode_config.fb_list,
>>>>> head)
>>>>> + exynos_drm_release_pended_fb(fb);
>>>>> +
>>>>> + mutex_unlock(&dev->mode_config.mutex);
>>>>> }
>>>>> diff --git a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>>> b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>>> index 862ca1e..81d7323 100644
>>>>> --- a/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>>> +++ b/drivers/gpu/drm/exynos/exynos_drm_plane.c
>>>>> @@ -203,11 +203,29 @@ exynos_update_plane(struct drm_plane *plane,
>>>>> struct drm_crtc *crtc,
>>>>> if (ret < 0)
>>>>> return ret;
>>>>>
>>>>> - plane->crtc = crtc;
>>>>> + /*
>>>>> +* Take a reference to new fb.
>>>>> +*
>>>>> +* Taking a reference means that this plane's dma is going to
>>>>> access
>>>>> +* memory region to the new fb.
>>>>> +*/
>>>>> + drm_framebuffer_reference(fb);
>>>>>
>>>>> + plane->crtc = crtc;
>>>>> exynos_plane_commit(plane);
>>>>> exynos_plane_dpms(plane, DRM_MODE_DPMS_ON);
>>>>>
>>>>> + /*
>>>>> +* If plane->fb is existed, unreference 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
>>>>>
>>>>
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>>
>>>
>>
>
> ___
> 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/20121205/01c35b45/attachment-0001.html>
_crtc.c|6 +++-
>>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 ++
>>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 15 +++
>>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 37
>>>> ++
>>>> 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 | 37
>>>> +-
>>>> 7 files changed, 73 insertions(+), 66 deletions(-)
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>
>>>
>>
>> ___
>> dri-devel mailing list
>> dri-devel at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>
>>
>
> ___
> 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/20121205/5ffcd1dd/attachment.html>
rds,
>> Prathyush
>>
>>
>>
>>> Thanks,
>>> Inki Dae
>>>
>>> Thanks,
>>>> Inki Dae
>>>>
>>>>
>>>>> Prathyush K (3)
>>>>> drm/exynos: modify wait for vsync functions to use wait queues
>>>>> drm/exynos: move w
ding only hdmi driver part.
>>>> 4. the patch including exception code.(previous Patch 3)
>>>>
>>>> Please, re-send them.
>>>>
>>>> Sure. I'll post them again as requested.
>>>
>>> Regards,
>>> Prathyush
>>>
>>>
>>>
>>>> Thanks,
>>>> Inki Dae
>>>>
>>>> Thanks,
>>>>> Inki Dae
>>>>>
>>>>>
>>>>>> Prathyush K (3)
>>>>>> drm/exynos: modify wait for vsync functions to use wait queues
>>>>>> drm/exynos: move wait_for_vblank to manager_ops
>>>>>> drm/exynos: do not disable crtc if already off
>>>>>>
>>>>>> drivers/gpu/drm/exynos/exynos_drm_crtc.c|6 +++-
>>>>>> drivers/gpu/drm/exynos/exynos_drm_drv.h | 20 ++
>>>>>> drivers/gpu/drm/exynos/exynos_drm_encoder.c | 15 +++
>>>>>> drivers/gpu/drm/exynos/exynos_drm_fimd.c| 37
>>>>>> ++
>>>>>> 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 | 37
>>>>>> +-
>>>>>> 7 files changed, 73 insertions(+), 66 deletions(-)
>>>>>>
>>>>>> ___
>>>>>> dri-devel mailing list
>>>>>> dri-devel at lists.freedesktop.org
>>>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>>>
>>>>>
>>>>>
>>>>
>>>> ___
>>>> dri-devel mailing list
>>>> dri-devel at lists.freedesktop.org
>>>> http://lists.freedesktop.org/mailman/listinfo/dri-devel
>>>>
>>>>
>>>
>>> ___
>>> 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/20121205/64bd8d16/attachment.html>
the fd as a parameter. That way
> the DDX could easily access also all generic libdrm functions.
Good points, I'll take those into account.
Thanks,
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/20121205/345465a6/attachment.pgp>
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 samsung.com>)
> - return -E
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)
> + return -EINVAL;
> +
> + device = calloc(1, sizeof(*device));
> +
On Mon, Nov 26, 2012 at 03:19:12PM +0200, Terje Bergstrom wrote:
> From: Arto Merilainen
>
> This patch removes the redundant host1x driver from tegradrm and
> makes necessary bindings to the separate host driver.
>
> This modification introduces a regression: Because there is no
> general frame
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121205/1234b1ba/attachment.html>
--- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20121205/109f80b7/attachment.html>
Hi Leela,
unfortunately, nothing new as of yet. I have to work on other stuff at the
moment.
Regards,
Steffen
On Wed, Dec 05, 2012 at 01:25:30PM +0530, Leela Krishna Amudala wrote:
> Hello Steffen,
>
> Any update on version 16 ?
>
> Best Wishes,
> Leela Krishna Amudala.
>
> On Mon, Nov 26,
#x27;ll send a
patch for that.
--
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/20121205/10419078/attachment.html>
Hi,
I created a base for host1x introduction text, and pasted it into
https://gitorious.org/linux-tegra-drm/pages/Host1xIntroduction. For
convenience, I also copy it below.
As I've worked with all of this for so long, I cannot know what areas
are most interesting to you, so I just tried to put in
On 05.12.2012 10:33, Thierry Reding wrote:
> I've been thinking about this some more and came to the conclusion that
> since we will already have a tight coupling between host1x and tegra-drm
> we may just as well keep the client registration code in host1x. The way
> I imagine this to work would b
the DRM device is registered
at the proper hierarchical location.
The circular dependency is indeed a problem, though. Quite frankly I
have no idea how to solve this. However the approach taken in the
current patch will break several other requirements as I already
explained.
Thierry
---
On 05.12.2012 13:13, Thierry Reding wrote:
> What I propose is to move the client registration code that is currently
> in drivers/gpu/drm/tegra/host1x.c to the host1x driver, which may or may
> not end up in drivers/gpu/host1x.
Ok.
>
>> host1x hardware access must be encapsulated in host1x driv
Am Mittwoch, den 05.12.2012, 13:47 +0200 schrieb Terje Bergstr?m:
[...]
>
> > The problem that this solves is that the DRM driver needs to be bound to
> > a specific platform device. None of the DRM subdevices are suitable
> > because they are only part of the whole DRM device. I think that host1x
On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergstr?m
wrote:
> You're right in that binding to a sub-device is not a nice way. DRM
> framework just needs a "struct device" to bind to. exynos seems to solve
> this by introducing a virtual device and bind to that. I'm not sure if
> this is the best way,
Dear Prathyush
Thank's your clarification.
I have one opinion about your [PATCH 1/3]
How about to add atomic_read() condition in each irq_handler ?
like this.
e.g)
+ if (atomic_read(&ctx->wait_vsync_event)) {
+ /* set wait vsync event to zero and wake up queue. */
+
that. But I abandoned it in favour of fixing the DRM
platform support code. The approach also didn't provide for the proper
encapsulation.
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/20121205/990cb51a/attachment.pgp>
gt;>>>
>>>> Hope I correctly understood the issue you mentioned.
>>>>>
>>>>>
>>>>>
>>>>> Anyway I removed the patch, "drm/exynos: release fb pended by page
>>>>>> flip". And I hope this issue
On Wed, Dec 5, 2012 at 1:03 PM, Daniel Vetter wrote:
> On Wed, Dec 5, 2012 at 12:47 PM, Terje Bergstr?m
> wrote:
>> You're right in that binding to a sub-device is not a nice way. DRM
>> framework just needs a "struct device" to bind to. exynos seems to solve
>> this by introducing a virtual dev
the two calls.
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/20121205/2621c3bd/attachment.pgp>
On Wed, Dec 5, 2012 at 1:22 PM, Thierry Reding
wrote:
> Maybe something more elaborate could help, though. Suppose we add
> functionality to DRM to instantiate a DRM device. We could call such a
> function from the host1x driver to add a device which the tegra-drm
> driver could bind to. This woul
ould be wrapped into an #ifdef CONFIG_TEGRADRM.
This is what I originally proposed. However, since tegra-drm will need
to call functions provided by host1x we have a cyclic dependency.
Wouldn't that prevent either module from being unloaded?
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/20121205/f31f160d/attachment.pgp>
On Wed, Dec 5, 2012 at 12:55 AM, Inki Dae wrote:
> 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
learing. I'll send
> a patch for that.
Hmm yes that sounds wrong.
--
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/20121205/cd2e1040/attachment.html>
1 - 100 of 151 matches
Mail list logo
