--
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/35da2c28/attachment.html>
next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/26c70650/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/d64ee215/attachment.html>
.
--
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/20140926/0e728f5c/attachment.html>
very other verification passes OK and it
goes down to the very end.
--
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/2014
---
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/097405f8/attachment.html>
we'll continue more tomorrow. :)
--
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/20140926/ed3fe02b/attachment.html>
very other verification passes OK and it
goes down to the very end.
--
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/2014
On 09/26/2014 12:48 AM, Stephen Warren wrote:
> On 09/25/2014 07:27 AM, Sjoerd Simons wrote:
>> Playing a bit with todays linux-next on my jetson, it seems this patch is
>> still required for enabling the GPU. Is there anything blocking it
>> (firmware
>> not available yet in liux-firmware?)
>
> I
e:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/052864bb/attachment-0001.html>
On 09/26/2014 01:52 AM, Peter Hurley wrote:
> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
>> There are six ttm patches queued for 3.16.4:
>>
>> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
>> drm-ttm-fix-handling-of-ttm_pl_flag_topdown-v2.patch
>> drm-ttm-fix-possible
add gpio bitbanging i2c adapter on LPC device of atom e6xx
gpu chipset to access lvds EDID
tested on SECO QuadMo747-E6xx-EXTREME Qseven platform
Cc: Patrik Jakobsson
Signed-off-by: Jan Safrata
---
drivers/gpu/drm/gma500/Makefile| 1 +
drivers/gpu/drm/gma500/oaktrail_lvds.c |
onable requirement on bootloaders to me. If it's clear
that the device will not work without an initialized VPR region, part of
the "boot protocol" should be for the bootloader to tell the kernel when
it's safe to enable the GPU.
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/20140926/3813d982/attachment.sig>
Hi guys,
I'd like to start a new thread about explicit fence synchronization. This time
with a Nouveau twist. :-)
First, let me define what I understand by implicit/explicit sync:
Implicit synchronization
* Fences are attached to buffers
* Kernel manages fences automatically based on buffer r
he VPR and disable it otherwise?
>
> I guess in that case the vdd-supply should still be added to the dts
> with u-boot toggling the status field of the node?
Yes, if that's what we decide on then this patch should be modified to
remove the status = "okay" line.
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/20140926/d408be81/attachment.sig>
Modify sync_fence_create to accept an array of 'struct fence' objects.
This will allow drm drivers to create sync_fence objects and pass sync
fd's between user space with minimal modifications, without ever creating
sync_timeline or sync_pt objects, and without implementing the
sync_timeline_ops in
Split nouveau_fence_sync to two functions:
* nouveau_fence_sync, which only adds a fence wait to the channel
command stream, and
* nouveau_bo_sync, which gets the fences from the reservation object
and passes them to nouveau_fence_sync.
Signed-off-by: Lauri Peltonen
---
drm/nouveau_bo.c
Add nouveau_fence_install, which installs a drm fence as a file
descriptor that can be returned to user space.
Add nouveau_fence_sync_fd, which pushes semaphore wait commands for
each Nouveau fence contained within the sync fd. If the sync fd
contains non-Nouveau fences, those are waited on the C
Add a new NOUVEAU_GEM_PUSHBUF_2 ioctl that accepts and emits a sync
fence fd from/to user space if the user space requests it by passing
corresponding flags.
Signed-off-by: Lauri Peltonen
---
drm/nouveau_drm.c | 1 +
drm/nouveau_gem.c | 46 +
Add a new nouveau_pushbuf_kick_fence function that takes and emits
a sync fence fd. The fence fd can be waited on, or merged with
other fence fd's, or passed back to kernel as a prerquisite for a
subsequent hw operation.
Signed-off-by: Lauri Peltonen
---
include/drm/nouveau_drm.h | 10 +
no
Do not attach fences automatically to buffers that are marked for
explicit synchronization.
Signed-off-by: Lauri Peltonen
---
drm/nouveau_bo.c | 8
drm/nouveau_bo.h | 4 ++--
drm/nouveau_drm.c | 1 +
drm/nouveau_gem.c | 47 +++
Allow user space to provide an explicit sync fence fd when exporting
a dma-buf from gem handle. The fence will be stored as the explicit
fence to the reservation object.
Signed-off-by: Lauri Peltonen
---
drivers/gpu/drm/drm_prime.c | 41 +
include/uapi/dr
On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
> On Fri, 26 Sep 2014 09:15:57 +0200
> Thomas Hellstrom wrote:
>
>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
>>> On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
There are six ttm patches queued for 3.16.4:
drm-ttm-choose-a-pool-to-shrink-co
On 05/08/14 21:35, Gabbay, Oded wrote:
>
>
> On 05/08/14 20:11, David Herrmann wrote:
>> Hi
>>
>> On Tue, Aug 5, 2014 at 5:30 PM, Oded Gabbay wrote:
>>> Hi,
>>> Here is the v3 patch set of amdkfd.
>>>
>>> This version contains changes and fixes to code, as agreed on during the
>>> review
>>>
Hi Philipp,
On Thursday 25 September 2014 15:09:13 Philipp Zabel wrote:
> Am Mittwoch, den 24.09.2014, 23:04 +0300 schrieb Laurent Pinchart:
> > Hello,
> >
> > This patch set adds support for the HDMI output port present on the
> > Renesas Koelsch board. Doing so requires two components, a driver
nt.
--
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/20140926/54efee6b/attachment.html>
On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
wrote:
> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>> On Fri, 26 Sep 2014 09:15:57 +0200
>> Thomas Hellstrom wrote:
>>
>>> On 09/26/2014 01:52 AM, Peter Hurley wrote:
On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> There are six ttm patc
Hi Geert,
On Thursday 25 September 2014 12:10:59 Geert Uytterhoeven wrote:
> On Thu, Sep 25, 2014 at 11:57 AM, Laurent Pinchart wrote:
> > On Thursday 25 September 2014 09:06:46 Geert Uytterhoeven wrote:
> >> On Wed, Sep 24, 2014 at 10:04 PM, Laurent Pinchart
> >>
> >> wrote:
> >> > +- adi,input
On 09/26/2014 02:28 PM, Rob Clark wrote:
> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
> wrote:
>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>>> On Fri, 26 Sep 2014 09:15:57 +0200
>>> Thomas Hellstrom wrote:
>>>
On 09/26/2014 01:52 AM, Peter Hurley wrote:
> On 09/25/2014 03:35 P
v2: Add more PCI IDs (Michael H. Nguyen)
v3: Synchronize one more with the kernel PCI IDs (Damien)
Signed-off-by: Damien Lespiau
Signed-off-by: Ben Widawsky
Signed-off-by: Michael H. Nguyen
---
intel/intel_chipset.h | 43 ++-
1 file changed, 42 insertion
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_bufmgr_gem.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
index ba65527..a6fa224 100644
--- a/intel/intel_bufmgr_gem.c
+++ b/intel/
Signed-off-by: Damien Lespiau
Reviewed-by: Kenneth Graunke
Signed-off-by: Ben Widawsky
---
intel/intel_decode.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/intel/intel_decode.c b/intel/intel_decode.c
index a5d6e04..7d5cbe5 100644
--- a/intel/intel_decode.c
+++ b/intel
On Fri, Sep 26, 2014 at 8:34 AM, Thomas Hellstrom
wrote:
> On 09/26/2014 02:28 PM, Rob Clark wrote:
>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>> wrote:
>>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
On Fri, 26 Sep 2014 09:15:57 +0200
Thomas Hellstrom wrote:
> On
[ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ]
On 09/26/2014 08:40 AM, Rik van Riel wrote:
> On 09/26/2014 08:28 AM, Rob Clark wrote:
>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>> wrote:
>>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
On Fri, 26 Sep 2014 09
the issue, unfortunately.
--
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/20140926/8aa76a0e/attachment.html>
as scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/ff68ce17/attachment.html>
From: Clint Taylor
CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.
Signed-off-by: Clint Taylor
---
drivers/gpu/drm/drm_edid.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 1bdbfd0..3bf9991 10064
.0)
This is LLVM bug and it is partially fixed in LLVM 3.5
--
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/20140926/3f2406d3/attachment.html>
On Fri, Sep 26, 2014 at 09:55:24AM -0700, clinton.a.taylor at intel.com wrote:
> From: Clint Taylor
>
> CEA VICs 44 and 45 were missing DRM_MODE_FLAG_INTERLACE.
>
> Signed-off-by: Clint Taylor
Reviewed-by: Ville Syrj?l?
> ---
> drivers/gpu/drm/drm_edid.c |4 ++--
> 1 file changed, 2 ins
Make sure we initialize the dsi PHY_TIMING and BTA_TIMING registers
when we setup the clocks, as opposed to in dsi_configure. The phy
timings must be initialized before drm_panel prepare() so that any
DCS commands sent at this time are using the appropriate timings.
Signed-off-by: Sean Paul
---
On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>> Adding proper people and mailing lists..
>>
>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>> BenH, and I have no idea if adding PCI_CLASS_DISPLAY_3D is
>> appro
On Mon, Sep 8, 2014 at 4:43 AM, 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 display controller supports at least one primary plane and might
> p
On Fri, Sep 26, 2014 at 5:08 PM, Aaron Plattner wrote:
> On 09/23/2014 01:29 PM, Benjamin Herrenschmidt wrote:
>>
>> On Mon, 2014-09-22 at 13:43 -0700, Linus Torvalds wrote:
>>>
>>> Adding proper people and mailing lists..
>>>
>>> The PCI_CLASS_DISPLAY_VGA test goes back to the very beginning by
>
edesktop.org/archives/dri-devel/attachments/20140926/1cc3c4d6/attachment.html>
...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/fb2cbb72/attachment-0001.html>
something coming this way to expose
these functionality?
--
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/20140926/a668d366/attachment.html>
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/20140926/66c9a249/attachment.html>
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/69fffe4a/attachment-0001.html>
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4: None
Changes in
From: Mark yao
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices hav
From: Mark yao
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subs
From: Mark yao
This adds binding documentation for Rockchip SoC VOP driver.
Signed-off-by: Mark Yao
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- rename "lcdc" to "vop"
- add vop reset
- add iommu node
- add port for display-subsystem
Changes in v3: None
Changes in v4:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/26/2014 08:28 AM, Rob Clark wrote:
> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
> wrote:
>> On 09/26/2014 12:40 PM, Chuck Ebbert wrote:
>>> On Fri, 26 Sep 2014 09:15:57 +0200 Thomas Hellstrom
>>> wrote:
>>>
On 09/26/2014 01:52 AM,
ail.
> maybe we can add "base->crtc = crtc" at update_plane, but it seems not
> good.
> so I think still use "rockchip_plane->ctx" would be better.
>
> -Mark
I found that: plane->crtc will be set if update_plane success, and will
be set NULL if disable_plane success.
so disable_plane must after update_plane.
disable_plane get crtc==NULL problem is that disable_plane was called
before update_plane or been called twice.
for this reason we can just check if crtc is NULL at disable_plane.
-Mark
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.freedesktop.org/archives/dri-devel/attachments/20140926/2b73fb2e/attachment.html>
On 09/26/2014 03:58 AM, Rafael J. Wysocki wrote:
> On Thursday, September 25, 2014 11:15:35 AM Aaron Lu wrote:
>> Hi Hans,
>>
>> Thanks for following up and explaining the situation to Pali.
>>
>> On 09/25/2014 02:21 AM, Pali Roh?r wrote:
>>> On Wednesday 24 September 2014 16:34:21 Hans de Goede wr
This add a display subsystem comprise the all display interface nodes.
Signed-off-by: Mark Yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- add DRM master device node to list all display nodes that comprise
the graphics subsystem.
Changes i
On Fri, 26 Sep 2014 09:15:57 +0200
Thomas Hellstrom wrote:
> On 09/26/2014 01:52 AM, Peter Hurley wrote:
> > On 09/25/2014 03:35 PM, Chuck Ebbert wrote:
> >> There are six ttm patches queued for 3.16.4:
> >>
> >> drm-ttm-choose-a-pool-to-shrink-correctly-in-ttm_dma_pool_shrink_scan.patch
> >> drm
Quoting Tomi Valkeinen (2014-09-19 06:25:48)
> On 19/09/14 16:12, Nishanth Menon wrote:
> > On 09/19/2014 08:07 AM, Tomi Valkeinen wrote:
> >> On 16/09/14 23:40, Jyri Sarha wrote:
> >>> The added ti,gpio-gate-clock is a basic clock that can be enabled and
> >>> disabled trough a gpio output. The DT
Some of the Thinkpads' firmware will issue a backlight change request
through i915 operation region unconditionally on AC plug/unplug, the
backlight level used is arbitrary and thus should be ignored. This is
handled by commit 0b9f7d93ca61 (ACPI / i915: ignore firmware requests
for backlight change
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
This a series of patches is a DRM Driver for Rockchip Socs, add support
for vop devices. Future patches will add additional encoders/connectors,
such as eDP, HDMI.
The basic "crtc" for rockchip is a "VOP" - Video Output Processor.
the vop devices found on Rockchip rk3288 Soc, rk3288 soc have two s
On Fri, Sep 26, 2014 at 7:10 AM, Peter Hurley
wrote:
> [ +cc Leann Ogasawara, Marek Szyprowski, Kyungmin Park, Arnd Bergmann ]
>
> On 09/26/2014 08:40 AM, Rik van Riel wrote:
>> On 09/26/2014 08:28 AM, Rob Clark wrote:
>>> On Fri, Sep 26, 2014 at 6:45 AM, Thomas Hellstrom
>>> wrote:
On 09/2
On Friday, September 26, 2014 10:30:08 AM Aaron Lu wrote:
> Some of the Thinkpads' firmware will issue a backlight change request
> through i915 operation region unconditionally on AC plug/unplug, the
> backlight level used is arbitrary and thus should be ignored. This is
> handled by commit 0b9f7d
This patch adds the basic structure of a DRM Driver for Rockchip Socs.
Signed-off-by: Mark yao
Signed-off-by: Daniel Kurtz
Acked-by: Daniel Vetter
Reviewed-by: Rob Clark
---
Changes in v2:
- use the component framework to defer main drm driver probe
until all VOP devices have been probed.
-
64 matches
Mail list logo
