On 09/23/12 03:40 PM, David Herrmann wrote:
> Hi
>
> This tries to continue the effort to document libdrm. I actually removed the
> X11-like man-page generation code as autotools now support man_MANS. The
> previous approach required every manpage to be in the same man-group. However,
> API calls
t 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/20120924/5d889810/attachment.pgp>
2012/9/22 Stephen Warren :
> On 09/21/2012 01:22 AM, Inki Dae wrote:
>> 2012/9/21 Stephen Warren :
>>> On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver modification to handle platform
On Mon, Sep 24, 2012 at 10:18:39AM -0500, Rob Herring wrote:
> On 09/24/2012 09:12 AM, Sascha Hauer wrote:
> >>
> >> A major piece missing is the LCD controller to display interface width
> >> and component ordering.
> >
> > Psst. We silently skipped this for now...
> >
> > I think having such a
the results?
--
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/20120924/a864cf43/attachment.html>
Changelog v2:
remove static prefix so that exynos_drm_best_encoder function
could be called by other modules.
Changelog v1:
this patch fixes the issue that display power callback isn't called.
with DRM_IOCTL_MODE_RMFB request, encoder->connector becomes NULL
so display_ops->power_on() wouldn't be
this patch fixes the issue that display power callback isn't called.
with DRM_IOCTL_MODE_RMFB request, encoder->connector becomes NULL
so display_ops->power_on() wouldn't be called so this patch makes
exynos_drm_best_encoder function to be used to get a valid encoder
of each connector.
Hi Michel
On Mon, Sep 24, 2012 at 9:45 AM, Michel D?nzer wrote:
> On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
>> +
>> +.SS TTM
>> +.B TTM
>> +stands for
>> +.B Translation Table Manager
>> +and is another generic memory-manager provided by the kernel. Only the
>> radeon
>> +driver
Backend-independent videomode. At the moment this is not very different
from fb_mode or drm_mode.
It is supposed to be a generic description of videomodes and conversion
step to the desired backend video mode representation.
At the moment, only really makes sense when used with of_display
Parse a display-node with timings and hardware-specs from devictree.
Signed-off-by: Steffen Trumtrar
---
Documentation/devicetree/bindings/video/display | 208 +++
drivers/of/Kconfig |5 +
drivers/of/Makefile |
Hi!
After the feedback I got on v4, I thought about the current state of the
videomode helper and decided to reengineer it. The most confusion seems to
stem from the fact, that a videomode does not have ranges. And that is correct.
Therefore the description of the display now uses a list of
On 09/24/2012 12:26 PM, Rob Herring wrote:
> On 09/24/2012 10:45 AM, Stephen Warren wrote:
>> On 09/24/2012 07:42 AM, Rob Herring wrote:
>>> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the
devicetree.
The videomode
Hi Rob,
On Mon, Sep 24, 2012 at 08:42:12AM -0500, Rob Herring wrote:
> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
> > This patch adds a helper function for parsing videomodes from the
> > devicetree.
> > The videomode can be either converted to a struct drm_display_mode or a
> > struct
On Mon, 2012-09-24 at 14:54 +0200, Daniel Vetter wrote:
> I've read through the patches and I'm hoping you don't volunteer me to
> pick these up ... ;-)
Worth a try, right? :-)
> But there doesn't seem to be anything that would
> get worse through this lockdep annotation patch, right?
No
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra wrote:
> On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
>> On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
>> > - In the printk code there's a special trylock, only used to kick off
>> > the logbuffer printk'ing in
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
> On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> > - In the printk code there's a special trylock, only used to kick off
> > the logbuffer printk'ing in console_unlock. But all that happens
> > while lockdep is disable (since
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
> - In the printk code there's a special trylock, only used to kick off
> the logbuffer printk'ing in console_unlock. But all that happens
> while lockdep is disable (since printk does a few other evil
> tricks). So no issue there,
Hi Hans,
Thank you for review.
On 08/22/2012 12:47 PM, Hans Verkuil wrote:
> On Tue August 14 2012 17:34:32 Tomasz Stanislawski wrote:
>> This patch adds description and usage examples for importing
>> DMABUF file descriptor in V4L2.
>>
>> Signed-off-by: Tomasz Stanislawski
>> Signed-off-by:
On Sat, Sep 22, 2012 at 01:06:29PM -0700, Greg KH wrote:
> On Sat, Sep 22, 2012 at 07:52:11PM +0200, Daniel Vetter wrote:
> > Dave Airlie recently discovered a locking bug in the fbcon layer,
> > where a timer_del_sync (for the blinking cursor) deadlocks with the
> > timer itself, since both (want
On 09/24/2012 10:45 AM, Stephen Warren wrote:
> On 09/24/2012 07:42 AM, Rob Herring wrote:
>> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
>>> This patch adds a helper function for parsing videomodes from the
>>> devicetree.
>>> The videomode can be either converted to a struct
)
- AR register handling (see load_ar() in r600_asm.c)
--
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/20120924/7e6f1
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120924/c8ff73df/attachment.pgp>
ner -auto bug.shader_test
PIGLIT: {'result': 'pass' }
--
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/20120924/2109b580/attachment.html>
On 09/24/2012 09:12 AM, Sascha Hauer wrote:
> Hi Rob,
>
> On Mon, Sep 24, 2012 at 08:42:12AM -0500, Rob Herring wrote:
>> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
>>> This patch adds a helper function for parsing videomodes from the
>>> devicetree.
>>> The videomode can be either
he bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120924/32c71ca6/attachment.html>
ttp://lists.freedesktop.org/archives/dri-devel/attachments/20120924/6e50540c/attachment.html>
was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20120924/ad7fcea5/attachment.html>
On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
> +
> +.SS TTM
> +.B TTM
> +stands for
> +.B Translation Table Manager
> +and is another generic memory-manager provided by the kernel. Only the radeon
> +driver uses it. See the radeon manpages for more information on
> +memory-management
On 09/24/2012 07:42 AM, Rob Herring wrote:
> On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
>> This patch adds a helper function for parsing videomodes from the devicetree.
>> The videomode can be either converted to a struct drm_display_mode or a
>> struct fb_videomode.
>> +++
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
> This patch adds a helper function for parsing videomodes from the devicetree.
> The videomode can be either converted to a struct drm_display_mode or a
> struct fb_videomode.
>
> Signed-off-by: Sascha Hauer
> Signed-off-by: Steffen Trumtrar
>
On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
+
+.SS TTM
+.B TTM
+stands for
+.B Translation Table Manager
+and is another generic memory-manager provided by the kernel. Only the radeon
+driver uses it. See the radeon manpages for more information on
+memory-management with
https://bugs.freedesktop.org/show_bug.cgi?id=55207
Michel Dänzer mic...@daenzer.net changed:
What|Removed |Added
Status|NEW |RESOLVED
https://bugs.freedesktop.org/show_bug.cgi?id=55206
--- Comment #2 from Michel Dänzer mic...@daenzer.net ---
*** Bug 55207 has been marked as a duplicate of this bug. ***
--
You are receiving this mail because:
You are the assignee for the bug.
___
https://bugs.freedesktop.org/show_bug.cgi?id=55256
--- Comment #6 from Török Edwin edwin+m...@etorok.net ---
Created attachment 67624
-- https://bugs.freedesktop.org/attachment.cgi?id=67624action=edit
bug.shader_test
A small piglit .shader_test that reproduces the bug:
$ bin/shader_runner
this patch fixes the issue that display power callback isn't called.
with DRM_IOCTL_MODE_RMFB request, encoder-connector becomes NULL
so display_ops-power_on() wouldn't be called so this patch makes
exynos_drm_best_encoder function to be used to get a valid encoder
of each connector.
Changelog v2:
remove static prefix so that exynos_drm_best_encoder function
could be called by other modules.
Changelog v1:
this patch fixes the issue that display power callback isn't called.
with DRM_IOCTL_MODE_RMFB request, encoder-connector becomes NULL
so display_ops-power_on() wouldn't be
2012/9/22 Stephen Warren swar...@wwwdotorg.org:
On 09/21/2012 01:22 AM, Inki Dae wrote:
2012/9/21 Stephen Warren swar...@wwwdotorg.org:
On 09/21/2012 05:22 AM, Leela Krishna Amudala wrote:
This patch adds device tree based discovery support for exynos DRM-FIMD
driver which includes driver
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk
On Mon, Sep 24, 2012 at 2:24 PM, Peter Zijlstra pet...@infradead.org wrote:
On Mon, 2012-09-24 at 14:17 +0200, Peter Zijlstra wrote:
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in
https://bugs.freedesktop.org/show_bug.cgi?id=55256
--- Comment #7 from Alex Deucher ag...@yahoo.com ---
There are some asic specific shader instruction behaviors for r6xx/r7xx chips
that need to be ported to the LLVM backend. A couple that come to mind:
- Trig functions (see tgsi_setup_trig() in
On Mon, 2012-09-24 at 14:54 +0200, Daniel Vetter wrote:
I've read through the patches and I'm hoping you don't volunteer me to
pick these up ... ;-)
Worth a try, right? :-)
But there doesn't seem to be anything that would
get worse through this lockdep annotation patch, right?
No indeed,
Hi Rob,
On Mon, Sep 24, 2012 at 08:42:12AM -0500, Rob Herring wrote:
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the
devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
On Sat, 2012-09-22 at 23:34 -0500, Ian Pilcher wrote:
On 09/12/2012 08:44 PM, Dave Airlie wrote:
Ajax, I think Ian still has an open request on how to proceed with the
infoframes quirk nightmare.
Indeed.
I'm sorry, I thought I was clearer. Daniel posted a patch to fix the
Intel driver
On Tue, 2012-09-18 at 01:03 +0200, Daniel Vetter wrote:
- In the printk code there's a special trylock, only used to kick off
the logbuffer printk'ing in console_unlock. But all that happens
while lockdep is disable (since printk does a few other evil
tricks). So no issue there, either.
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
Signed-off-by: Sascha Hauer s.ha...@pengutronix.de
Signed-off-by:
On 09/24/2012 09:12 AM, Sascha Hauer wrote:
Hi Rob,
On Mon, Sep 24, 2012 at 08:42:12AM -0500, Rob Herring wrote:
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the
devicetree.
The videomode can be either converted to a struct
Hi!
After the feedback I got on v4, I thought about the current state of the
videomode helper and decided to reengineer it. The most confusion seems to
stem from the fact, that a videomode does not have ranges. And that is correct.
Therefore the description of the display now uses a list of
Parse a display-node with timings and hardware-specs from devictree.
Signed-off-by: Steffen Trumtrar s.trumt...@pengutronix.de
---
Documentation/devicetree/bindings/video/display | 208 +++
drivers/of/Kconfig |5 +
drivers/of/Makefile
Backend-independent videomode. At the moment this is not very different
from fb_mode or drm_mode.
It is supposed to be a generic description of videomodes and conversion
step to the desired backend video mode representation.
At the moment, only really makes sense when used with of_display
On 09/24/2012 07:42 AM, Rob Herring wrote:
On 09/19/2012 03:20 AM, Steffen Trumtrar wrote:
This patch adds a helper function for parsing videomodes from the devicetree.
The videomode can be either converted to a struct drm_display_mode or a
struct fb_videomode.
+++
Hi Michel
On Mon, Sep 24, 2012 at 9:45 AM, Michel Dänzer mic...@daenzer.net wrote:
On Son, 2012-09-23 at 16:40 +0200, David Herrmann wrote:
+
+.SS TTM
+.B TTM
+stands for
+.B Translation Table Manager
+and is another generic memory-manager provided by the kernel. Only the
radeon
+driver
On Mon, Sep 24, 2012 at 10:18:39AM -0500, Rob Herring wrote:
On 09/24/2012 09:12 AM, Sascha Hauer wrote:
A major piece missing is the LCD controller to display interface width
and component ordering.
Psst. We silently skipped this for now...
I think having such a videomode helper
On Sun, Sep 23, 2012 at 04:40:03PM +0200, David Herrmann wrote:
Hi
This tries to continue the effort to document libdrm. I actually removed the
X11-like man-page generation code as autotools now support man_MANS. The
previous approach required every manpage to be in the same man-group.
https://bugs.freedesktop.org/show_bug.cgi?id=43829
--- Comment #14 from LRN lrn1...@gmail.com ---
I seem to be having this issue with A6-4400M (at least symptoms are all the
same).
At first i thought that it's the same issue as #52256, but apparently it is not
so simple.
I've tried merging
Hi Thierry
On Mon, Sep 24, 2012 at 9:51 PM, Thierry Reding
thierry.red...@avionic-design.de wrote:
On Sun, Sep 23, 2012 at 04:40:03PM +0200, David Herrmann wrote:
Hi
This tries to continue the effort to document libdrm. I actually removed the
X11-like man-page generation code as autotools
On 09/23/12 03:40 PM, David Herrmann wrote:
Hi
This tries to continue the effort to document libdrm. I actually removed the
X11-like man-page generation code as autotools now support man_MANS. The
previous approach required every manpage to be in the same man-group. However,
API calls belong in
This is required to make streamout work there.
Signed-off-by: Marek Olšák mar...@gmail.com
---
drivers/gpu/drm/radeon/r600_cs.c|3 ++-
drivers/gpu/drm/radeon/radeon_drv.c |3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c
https://bugs.freedesktop.org/show_bug.cgi?id=55172
--- Comment #2 from Darren Salt bugs...@moreofthesa.me.uk ---
It does; the problem appears to be fixed.
--
You are receiving this mail because:
You are the assignee for the bug.
___
dri-devel mailing
MIP_ADDRESS should point to the resolved FMASK for an MSAA texture.
Setting MIP_ADDRESS to 0 means the FMASK pointer is invalid (the GPU
won't read the memory then).
The userspace has to set MIP_ADDRESS to 0 and *not* emit any relocation
for it.
Signed-off-by: Marek Olšák mar...@gmail.com
---
59 matches
Mail list logo
