On Mon, May 19, 2014 at 6:22 PM, David Herrmann
wrote:
>
> On Mon, May 19, 2014 at 4:53 PM, Daniel Vetter wrote:
>> On Mon, May 19, 2014 at 04:44:15PM +0200, David Herrmann wrote:
>>> On Mon, May 19, 2014 at 4:41 PM, Thomas Wood
>>> wrote:
>>> > It was intended as a debug/testing feature to al
or the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/9326efd7/attachment.html>
ves/dri-devel/attachments/20140519/9816a249/attachment.html>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/8cf2f420/attachment-0001.html>
nee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/0b903d74/attachment.html>
|--- |FIXED
--
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/20140519/c937fbd3/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/65b61cbb/attachment.html>
On Mon, Feb 24, 2014 at 8:29 AM, Maarten Lankhorst
wrote:
> Just to show it's easy.
>
> Android syncpoints can be mapped to a timeline. This removes the need
> to maintain a separate api for synchronization. I've left the android
> trace events in place, but the core fence events should already be
panel
> > power up sequence diagram that doesn't mean we have to implement it as
> > part of the panel driver.
> That is not "some spec". I believe all the AUO panels share the same
> sequence!
Just because some specs mention the backlight enable pin in some panel
power up sequence diagram that doesn't mean we have to implement it as
part of the panel driver.
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/20140519/2692ab97/attachment.sig>
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> Add the device tree binding documentation for the GK20A GPU used in
> Tegra K1 SoCs.
A few minor nits, but otherwise,
Acked-by: Stephen Warren
> diff --git a/Documentation/devicetree/bindings/gpu/nvidia,gk20a.txt
> b/Documentation/devicetree/bi
On 05/19/2014 03:24 AM, Alexandre Courbot wrote:
> From: Thierry Reding
>
> Add the GK20A device node to Tegra124's device tree.
At a quick glance, patches 3-5 look fine too. I'll hold off on applying
them until patches 1-2 have been applied to the DRM/... tree.
Ravier ---
My laptop is dead, I can not test this anymore.
--
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/20140519/e9d57
Pull the parameter checking from drm_primary_helper_update() out into
its own function; drivers that provide their own setplane()
implementations rather than using the helper may still want to share
this parameter checking logic.
A few of the checks here were also updated based on suggestions by
V
On Sat, May 17, 2014 at 12:43:04AM +0200, Daniel Vetter wrote:
> On Sat, May 17, 2014 at 12:38 AM, Matt Roper
> wrote:
> > + if (ret) {
> > + if (req->flags & DRM_MODE_CURSOR_BO)
> > + drm_mode_rmfb(dev, &fb->base.id, file_priv);
> > + retur
u are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140519/5224c2c6/attachment.html>
When the PX card is off don't try and access it. Avoid hw access
to the card while it's off (e.g., reading back invalid temperature).
v2: be less strict
bug:
https://bugzilla.kernel.org/show_bug.cgi?id=76321
Signed-off-by: Alex Deucher
Cc: stable at vger.kernel.org
---
drivers/gpu/drm/radeon/r
why glxinfo, eglinfo and es2_info crash the gpu or at least
disable subsequent invocations of anything accelerated.
--
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/20140519/3a22d03f/attachment.html>
Refactor DRM framebuffer creation into a new function that returns a
struct drm_framebuffer directly. The upcoming universal cursor support
will want to create framebuffers internally to wrap cursor buffers, so
we want to be able to share that framebuffer creation with the
drm_mode_addfb2 ioctl ha
Universal plane support had placeholders for cursor planes, but didn't
actually do anything with them. Save the cursor plane reference inside
the crtc and update the cursor plane parameter from void* to drm_plane.
Reviewed-by: Daniel Vetter
Signed-off-by: Matt Roper
---
drivers/gpu/drm/drm_crt
Refactor cursor buffer setting such that the code to actually update the
cursor lives in a new function, intel_crtc_cursor_set_obj(), and takes
a GEM object as a parameter. The existing legacy cursor ioctl handler,
intel_crtc_cursor_set() will now perform the userspace handle lookup and
then call
Refactor DRM setplane code into a new setplane_internal() function that
takes DRM objects directly as parameters rather than looking them up by
ID. We'll use this in a future patch when we implement legacy cursor
ioctls on top of the universal plane interface.
v2:
- Allow planes to be disabled w
(respinning the whole patch series to pull the entire set back together now
that a couple patches have been added at the beginning)
Cursor planes are a bit trickier to support via the universal plane interface
than primary planes were. Legacy cursor ioctls take handles to driver buffers
directly
If drivers support universal planes and have registered a cursor plane
with the DRM core, we should use that universal plane support when
handling legacy cursor ioctls. Drivers that transition to universal
planes won't have to maintain separate legacy ioctl handling; drivers
that don't transition
The DRM core will translate calls to legacy cursor ioctls into universal
cursor calls automatically, so there's no need to maintain the legacy
cursor support. This greatly simplifies the transition since we don't
have to handle reference counting differently depending on which cursor
interface was
Am 19.05.2014 01:04, schrieb Dave Airlie:
> On 16 May 2014 23:54, Christian K?nig wrote:
>> Hi Dave,
>>
>> this is the next pull quested for stashed up radeon fixes for 3.15.
>>
>> Highlights are:
>> 1. Avoid sending SIGBUS on CPU access just because kernel can't handle
>> buffer placement.
>> 2.
101 - 125 of 125 matches
Mail list logo
