2014-06-20 0:13 GMT+09:00 Rahul Sharma :
> This situation arises when userspace remove the frambuffer object
> and call setmode ioctl.
>
> drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL;
> and
> drm_mode_setcrtc --> exynos_plane_commit --> passes plane->crtc to
> exynos_drm_crtc_p
Thanks for patch.
2014-07-04 19:33 GMT+09:00 Tushar Behera :
> Under some conditions (when IOMMU is enabled), fimd_bind() accesses
> hardware registers and power-domain should be enabled during that time.
>
> fimd_bind --> fimd_mgr_initialize --> fimd_clear_channel
>
> If the power-domain is disab
2014-07-08 9:39 GMT+09:00 YoungJun Cho :
> To support MIPI command mode based I80 interface panel,
> FIMD should do followings:
> - Sets LCD I80 interface timings configuration.
> - Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
> - Sets LCD block configuration for I80 inter
2014-07-08 22:37 GMT+09:00 Daniel Vetter :
> On Wed, Jul 02, 2014 at 11:25:19AM -0400, Jerome Glisse wrote:
>> Anyway as this is upstream i guess you can keep it. This is just an horrible
>> API that allow to circumvant any limit set by memcg for page locking and all.
>> But anyway GPU driver never
To support MIPI command mode based I80 interface panel,
FIMD should do followings:
- Sets LCD I80 interface timings configuration.
- Uses "lcd_sys" as an IRQ resource and sets relevant IRQ configuration.
- Sets LCD block configuration for I80 interface.
- Sets ideal(pixel) clock is 2 times faster t
ould do would be to bisect the
problem from upstream Mesa Git.
--
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/20140709/355131cc/attachment.html>
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/20140709/919f50f0/attachment.html>
dri-devel/attachments/20140709/f0c376cf/attachment.html>
install the corresponding
32 bit development packages, you can create the symlinks manually.
--
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
Hi Daniel, Thierry and Rob,
Currently, the following boards are working fine with the bridge chip series:
- snow
- spring
- peach_pit
- peach_pi
And, I did change my original patchset based on your comments here:
(1) [RFC V2 0/3] drm/bridge: panel and chaining
http://www.spinics.net/lists/
ping
On Mon, Jun 30, 2014 at 9:39 PM, Inki Dae wrote:
> 2014-06-30 14:31 GMT+09:00 Andrzej Hajda :
>> On 06/30/2014 03:14 AM, Jingoo Han wrote:
>>> On Friday, June 27, 2014 10:03 PM, Ajay kumar wrote:
On Fri, Jun 27, 2014 at 6:14 PM, Andrzej Hajda
wrote:
> On 06/27/2014 01:48 PM,
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/15ace0cf/attachment.html>
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove some
opencoded defines.
Signed-off-by: Chris Wilson
---
configu
Hi Matt,
On Tue, 8 Jul 2014 16:51:24 -0700
Matt Roper wrote:
> Hi Boris.
>
> I haven't really looked at any of your driver in depth, but from a quick
> glance it looks like you're registering a cursor drm_plane (i.e., making
> use of the new universal plane infrastructure), but you're also
> pr
On Wed, Jul 09, 2014 at 10:44:17AM +0300, Pekka Paalanen wrote:
> On Wed, 9 Jul 2014 08:00:21 +0100
> Chris Wilson wrote:
>
> > With the advent of universal drm planes and the introduction of generic
> > plane properties for rotations, we can query and program the hardware
> > for native rotatio
On Mon, 7 Jul 2014 23:45:54 -0400
Rob Clark wrote:
> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
> wrote:
> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
> > at91sam9n12, at91sam9x5 family or sama5d3 family) provides a display
> > controller device.
> >
> > This
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, su
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/0dc335e5/attachment.html>
Hi Dave,
Fixes for regressions and black screens, cc: stable where applicapable
(the last minute rebase was to sprinkle missing stable tags). A bit more
than what I'd wish for, but excluding vlv and that the first 3 patches are
just quirks for 1 regression it looks much better.
There's still a "o
for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/2dc0b1f7/attachment.html>
Can you confirm?
--
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/20140709/9fa6f0e5/attachment-0001.html>
part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/dca9a1c3/attachment.html>
On Tue, Jul 8, 2014 at 6:20 PM, Inki Dae wrote:
> 2014-07-08 22:37 GMT+09:00 Daniel Vetter :
>> On Wed, Jul 02, 2014 at 11:25:19AM -0400, Jerome Glisse wrote:
>>> Anyway as this is upstream i guess you can keep it. This is just an horrible
>>> API that allow to circumvant any limit set by memcg fo
On Sun, Jul 06, 2014 at 11:46:56AM +0200, Sebastian Hesselbarth wrote:
> On 07/05/2014 02:21 PM, Russell King - ARM Linux wrote:
> > There's also the issue whether the output can cope with fractional
> > clock-skipping dividers - entirely synchronous display systems can
> > (such as synchronously c
On Wed, Jul 09, 2014 at 12:57:12PM +0300, Pekka Paalanen wrote:
> On Wed, 9 Jul 2014 09:19:08 +0100
> Chris Wilson wrote:
>
> > With the advent of universal drm planes and the introduction of generic
> > plane properties for rotations, we can query and program the hardware
> > for native rotatio
crubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/ace73bba/attachment.html>
On Wed, Jul 9, 2014 at 5:34 AM, Russell King wrote:
> David,
>
> Please incorporate the latest msm drm update for component changes, which can
> be found at:
>
> git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-drm
>
> with SHA1 84448288546d13d7e06fd6638fb78ddff559b399.
>
> This upda
On 8 July 2014 21:25, Inki Dae wrote:
> 2014-06-20 0:13 GMT+09:00 Rahul Sharma :
>> This situation arises when userspace remove the frambuffer object
>> and call setmode ioctl.
>>
>> drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL;
>> and
>> drm_mode_setcrtc --> exynos_plane_commi
With the advent of universal drm planes and the introduction of generic
plane properties for rotations, we can query and program the hardware
for native rotation support.
NOTE: this depends upon the next release of libdrm to remove one
opencoded define.
v2: Use enum to determine primary plane, su
On Wed, Jul 9, 2014 at 4:18 AM, Boris BREZILLON
wrote:
> On Mon, 7 Jul 2014 23:45:54 -0400
> Rob Clark wrote:
>
>> On Mon, Jul 7, 2014 at 12:42 PM, Boris BREZILLON
>> wrote:
>> > The Atmel HLCDC (HLCD Controller) IP available on some Atmel SoCs (i.e.
>> > at91sam9n12, at91sam9x5 family or sama5d
u 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/20140709/1715e57e/attachment.html>
On Wed, Jul 09, 2014 at 06:56:14AM -0400, Rob Clark wrote:
> On Wed, Jul 9, 2014 at 5:34 AM, Russell King wrote:
> > David,
> >
> > Please incorporate the latest msm drm update for component changes, which
> > can be found at:
> >
> > git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-
This series applies on top of the driver-core-next branch of
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/driver-core.git
Before converting ttm to the new fence interface I had to fix some
drivers to require a reservation before poking with fence_obj.
After flipping the switch RCU becomes
It seems some drivers really want this as a parameter,
like vmwgfx.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c|2 +-
drivers/gpu/drm/radeon/radeon_object.c |2 +-
drivers/gpu/drm/radeon/radeon_uvd.c |2 +-
drivers/gpu/drm/radeon/radeon_vm.c
This reorders the list to keep track of what buffers are reserved,
so previous members are always unreserved.
This gets rid of some bookkeeping that's no longer needed,
while simplifying the code some.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/qxl_release.c |1
drivers
Apart from some code inside ttm itself and nouveau_bo_vma_del,
this is the only place where ttm_bo_wait is used without a reservation.
Fix this so we can remove the fence_lock later on.
After the switch to rcu the reservation lock will be
removed again.
Signed-off-by: Maarten Lankhorst
---
driv
This will ensure we always hold the required lock when calling those functions.
---
drivers/gpu/drm/nouveau/nouveau_bo.c |2 ++
drivers/gpu/drm/nouveau/nouveau_display.c | 17 +
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouve
This is the last remaining function that doesn't use the reservation
lock completely to fence off access to a buffer.
---
drivers/gpu/drm/ttm/ttm_bo.c | 25 -
1 file changed, 12 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/tt
No users are left, kill it off! :D
Conversion to the reservation api is next on the list, after
that the functionality can be restored with rcu.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 25 +++---
drivers/gpu/drm/nouveau/nouveau_display.c |6 --
From: Maarten Lankhorst
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/core/core/event.c |4
drivers/gpu/drm/nouveau/nouveau_bo.c |6
drivers/gpu/drm/nouveau/nouveau_display.c |4
drivers/gpu/drm/nouveau/nouveau_fence.c | 435 -
d
This makes it possible to wait for a specific amount of time,
rather than wait until infinity.
Signed-off-by: Maarten Lankhorst
Reviewed-by: Christian K?nig
---
drivers/gpu/drm/radeon/radeon_fence.c | 60 ++---
1 file changed, 40 insertions(+), 20 deletions(-)
dif
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon.h| 15 +-
drivers/gpu/drm/radeon/radeon_device.c | 60 -
drivers/gpu/drm/radeon/radeon_fence.c | 223 ++--
3 files changed, 248 insertions(+), 50 deletions(-)
diff --git a/drivers
Final driver! \o/
This is not a proper dma_fence because the hardware may never signal
anything, so don't use dma-buf with qxl, ever.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/qxl/Makefile |2
drivers/gpu/drm/qxl/qxl_cmd.c |5 -
drivers/gpu/drm/qxl/qxl_debugfs.c |
Only one type was ever used. This is needed to simplify the fence
support in the next commit.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_buffer.c |5 +--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h |1 -
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 14 ++---
drive
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c |2
drivers/gpu/drm/vmwgfx/vmwgfx_fence.c| 299 ++
drivers/gpu/drm/vmwgfx/vmwgfx_fence.h| 29 ++-
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c |9 -
4 files changed, 200 inser
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
drivers/gpu/drm/nouveau/nouveau_fence.c | 24 +---
drivers/gpu/drm/nouveau/nouveau_fence.h |2
drivers/gpu/drm/nouveau/nouveau_gem.c| 16 ++-
drivers/gpu/drm/qxl/qxl_debugfs.c|6 +
drivers/gpu/drm/qxl/qxl_drv
With the conversion to the reservation api this should be safe.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/nouveau/nouveau_gem.c | 28
1 file changed, 12 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_gem.c
b/drivers/gpu/drm
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/radeon/radeon_gem.c | 19 ++-
1 file changed, 14 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_gem.c
b/drivers/gpu/drm/radeon/radeon_gem.c
index d09650c1d720..7ba883843668 100644
--- a/drivers/gpu/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/vmwgfx/vmwgfx_resource.c | 17 ++---
1 file changed, 10 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index 20a1a866ceeb..79e950df3018 100644
--- a
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/ttm/ttm_bo.c | 76 +++---
1 file changed, 13 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 31c4a6dd722d..6fe1f4bf37ed 100644
--- a/drivers/gp
Hello Thomas Hellstrom,
The patch 18e4a4669c50: "drm/vmwgfx: Fix compat shader namespace"
from Jun 9, 2014, leads to the following static checker warning:
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:477 vmw_cmd_res_reloc_add()
warn: missing error code here? 'kzalloc()' failed.
driver
1256 insertions(+), 1150 deletions(-)
> delete mode 100644 drivers/gpu/drm/qxl/qxl_fence.c
>
> --
> Signature
> ___
> 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/20140709/bd03dd6a/attachment-0001.html>
> -Original Message-
> From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com]
> Sent: Wednesday, July 09, 2014 8:30 AM
> To: airlied at linux.ie
> Cc: thellstrom at vmware.com; nouveau at lists.freedesktop.org; linux-
> kernel at vger.kernel.org; dri-devel at lists.freedeskto
op 09-07-14 15:09, Mike Lothian schreef:
> Hi Maarten
>
> Will this stop the stuttering I've been seeing with DRI3 and PRIME? Or will
> other patches / plumbing be required
>
No, that testing was with the whole series including the parts where you
synchronized intel with radeon (iirc).
Although it
op 09-07-14 14:57, Deucher, Alexander schreef:
>>
>> +static const char *radeon_fence_get_timeline_name(struct fence *f)
>> +{
>> +struct radeon_fence *fence = to_radeon_fence(f);
>> +switch (fence->ring) {
>> +case RADEON_RING_TYPE_GFX_INDEX: return "radeon.gfx";
>> +case CAYMAN_R
On Tue, Jul 8, 2014 at 10:27 PM, Alexandre Demers
wrote:
> It reverts commit c745fe611ca42295c9d91d8e305d27983e9132ef now that
> Cayman is stable since VDDCI fix. Spread spectrum was not the culprit.
>
> Signed-off-by: Alexandre Demers
Applied. thanks!
Alex
>
> ---
> drivers/gpu/drm/radeon/r
On Wed, Jul 9, 2014 at 8:26 AM, Russell King - ARM Linux
wrote:
> On Wed, Jul 09, 2014 at 06:56:14AM -0400, Rob Clark wrote:
>> On Wed, Jul 9, 2014 at 5:34 AM, Russell King wrote:
>> > David,
>> >
>> > Please incorporate the latest msm drm update for component changes, which
>> > can be found at
patch, for example
performance in Unigine Sanctuary goes down by ~40% for me :).
--
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/20140709/f554f666/attachment.html>
On Wed, Jul 09, 2014 at 09:14:24AM +0200, Boris BREZILLON wrote:
> Hi Matt,
>
> On Tue, 8 Jul 2014 16:51:24 -0700
> Matt Roper wrote:
>
> > Hi Boris.
> >
> > I haven't really looked at any of your driver in depth, but from a quick
> > glance it looks like you're registering a cursor drm_plane (
ly from ssh console.
--
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/20140709/a70e8ddb/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=79011
--- Comment #15 from Fabian Pas ---
(In reply to Paul Menzel from comment #13)
> (In reply to Fabian Pas from comment #0)
>
> > I am running 64 bit Arch Linux on kernel 3.15, the bug also occured with
> > 3.14, with Intel i5 processor and a AMD R
On 2014? 07? 09? 20:06, Rahul Sharma wrote:
> On 8 July 2014 21:25, Inki Dae wrote:
>> 2014-06-20 0:13 GMT+09:00 Rahul Sharma :
>>> This situation arises when userspace remove the frambuffer object
>>> and call setmode ioctl.
>>>
>>> drm_mode_rmfb --> drm_plane_force_disable --> plane->crtc = NULL
On 2014? 07? 03? 22:10, Andrzej Hajda wrote:
> This set of independent patches contains various improvement and fixes
> for exynos_drm ipp framework.
> The patchset is based on exynos-drm-next branch.
>
Did you test ipp module using libdrm? If so, can you share the app? I
would try to test this p
On Thu, Jul 03, 2014 at 06:36:47PM -0400, Rob Clark wrote:
> On Thu, Jul 3, 2014 at 12:49 PM, Russell King
> wrote:
> > Add a helper to allow encoders to find their possible CRTCs from the
> > OF graph without having to re-implement this functionality. We add a
> > device_node to drm_crtc which c
controller implementation
possibly).
Laurent also asked you to split this up into two patches, one for the
core part, the other for the Exynos driver parts, yet this patch
contains both changes.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/a3ed2b89/attachment.sig>
to patch 5.
Thierry
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/1015550e/attachment.sig>
scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/3e475957/attachment.html>
nts/20140709/ca281615/attachment-0001.html>
bed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/0ed56bcd/attachment.html>
:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/b7ad32d8/attachment.html>
This enables the display scaler on all connectors for r5xx
and newer asics. Previously we only enabled the scaler for
fixed mode displays (eDP or LVDS) since they have to use the
scaler to support non-native modes. Most other displays
are multi-sync or have a built in scaler to support non-native
This enables the display scaler on all connectors for r5xx
and newer asics. Previously we only enabled the scaler for
fixed mode displays (eDP or LVDS) since they have to use the
scaler to support non-native modes. Most other displays
are multi-sync or have a built in scaler to support non-native
They are identical.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/radeon_connectors.c | 15 +--
1 file changed, 1 insertion(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_connectors.c
b/drivers/gpu/drm/radeon/radeon_connectors.c
index 05d9d06..9bcd243 10064
xt part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140709/bc332a87/attachment.html>
On Wed, Jul 9, 2014 at 11:16 AM, Russell King - ARM Linux
wrote:
> On Thu, Jul 03, 2014 at 06:36:47PM -0400, Rob Clark wrote:
>> On Thu, Jul 3, 2014 at 12:49 PM, Russell King
>> wrote:
>> > Add a helper to allow encoders to find their possible CRTCs from the
>> > OF graph without having to re-imp
From: Christian K?nig
Signed-off-by: Christian K?nig
---
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r300.c| 8 ++--
drivers/gpu/drm/radeon/radeon.h | 8
drivers/gpu/drm/radeon/radeon_asic.h | 8
drivers/gpu/drm/radeon/radeon_gart.c | 4
From: Christian K?nig
This patch adds an IOCTL for turning a pointer supplied by
userspace into a buffer object.
It imposes several restrictions upon the memory being mapped:
1. It must be page aligned (both start/end addresses, i.e ptr and size).
2. It must be normal system memory, not a poin
From: Michel D?nzer
Doesn't seem necessary, the GART table memory should be persistent.
Signed-off-by: Michel D?nzer
---
drivers/gpu/drm/radeon/cik.c | 1 -
drivers/gpu/drm/radeon/evergreen.c | 1 -
drivers/gpu/drm/radeon/ni.c | 1 -
drivers/gpu/drm/radeon/r100.c|
On Wed, Jul 09, 2014 at 02:11:18PM -0400, Rob Clark wrote:
> On Wed, Jul 9, 2014 at 11:16 AM, Russell King - ARM Linux
> wrote:
> > Warning(.../include/drm/drm_flip_work.h:68): No description found for
> > parameter ')'
> > Warning(.../include/drm/drm_flip_work.h:68): Excess
> > struct/union/enu
On Wed, Jul 9, 2014 at 2:15 PM, Christian K?nig
wrote:
> From: Michel D?nzer
>
> Doesn't seem necessary, the GART table memory should be persistent.
>
> Signed-off-by: Michel D?nzer
Reviewed-by: Alex Deucher
I'll add this one to my drm-next tree. Separate comments on the other patches.
Ale
On Wed, Jul 9, 2014 at 2:15 PM, Christian K?nig
wrote:
> From: Christian K?nig
>
> Signed-off-by: Christian K?nig
> ---
> drivers/gpu/drm/radeon/r100.c| 2 +-
> drivers/gpu/drm/radeon/r300.c| 8 ++--
> drivers/gpu/drm/radeon/radeon.h | 8
> drivers/gpu/drm/rad
Daniel, looks like this series has some r-bs; iirc this fixed some Asus
HDMI monitors too (and who knows how many TVs).
Jesse
On Thu, 22 May 2014 16:50:48 +0530
Vandana Kannan wrote:
> Added a property to enable user space to set aspect ratio.
> This patch contains declaration of the property a
On 2014-07-09 14:48, Dan Carpenter wrote:
> Hello Thomas Hellstrom,
>
> The patch 18e4a4669c50: "drm/vmwgfx: Fix compat shader namespace"
> from Jun 9, 2014, leads to the following static checker warning:
>
> drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c:477 vmw_cmd_res_reloc_add()
> warn: m
nch to every single sampler.
--
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/20140709/0554e843/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=78661
--- Comment #11 from Nikolaus Waxweiler ---
Created attachment 142621
--> https://bugzilla.kernel.org/attachment.cgi?id=142621&action=edit
Got a temporary hang again on boot-up, managed to reboot...
--
You are receiving this mail because:
You
On Wed, 9 Jul 2014 08:00:21 +0100
Chris Wilson wrote:
> With the advent of universal drm planes and the introduction of generic
> plane properties for rotations, we can query and program the hardware
> for native rotation support.
>
> NOTE: this depends upon the next release of libdrm to remove
Commit 34ea3d386347 ("drm: add register and unregister functions
for connectors") probably missed out converting the
drm_sysfs_connector_remove instances in the following files.
Without this patch we get the following compilation error:
ERROR: "drm_sysfs_connector_remove" [drivers/gpu/drm/tilcdc/ti
Provide monitor name and product/manufacturer id to alsa hda driver. The output
matches the fglrx settings, short of the port_id. As the latter is not
standardized,
leave it out for now.
Corresponding alsa code is already in place.
Signed-off-by: Stefan Br?ns
---
The fglrx register settings whe
Building with the attached random configuration file,
drivers/gpu/drm/drm_dp_mst_topology.c: In function ?drm_dp_mst_dump_mstb?:
drivers/gpu/drm/drm_dp_mst_topology.c:2431:2: error: implicit
declaration of function ?seq_printf?
[-Werror=implicit-function-declaration]
seq_printf(m, "%smst: %p, %d
On Wed, 9 Jul 2014 09:19:08 +0100
Chris Wilson wrote:
> With the advent of universal drm planes and the introduction of generic
> plane properties for rotations, we can query and program the hardware
> for native rotation support.
>
> NOTE: this depends upon the next release of libdrm to remove
On Mon, 07 Jul 2014, Boris BREZILLON wrote:
> The HLCDC IP available on some Atmel SoCs (i.e. at91sam9n12, at91sam9x5
> family or sama5d3 family) exposes 2 subdevices:
> - a display controller (controlled by a DRM driver)
> - a PWM chip
>
> The MFD device provides a regmap and several clocks (tho
David,
Please incorporate the latest msm drm update for component changes, which can
be found at:
git://ftp.arm.linux.org.uk/~rmk/linux-arm.git component-for-drm
with SHA1 84448288546d13d7e06fd6638fb78ddff559b399.
This updates the MSM's DRM driver for the updates merged in Greg's
driver-core
92 matches
Mail list logo
