From: Hans Verkuil
Preliminary ARC and CDC support. Untested and experimental!
Signed-off-by: Hans Verkuil
---
.../DocBook/media/v4l/cec-ioc-adap-g-caps.xml | 10 ++
Documentation/DocBook/media/v4l/cec-ioc-g-mode.xml | 36
Documentation/cec.txt | 75 ++
On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> Add some utility functions for struct drm_clip_rect.
Looks like mostly you're just duplicating the drm_rect stuff. Why can't
you use what's there already?
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_rect.c |
Den 25.04.2016 14:39, skrev Ville Syrjälä:
> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
>> Add some utility functions for struct drm_clip_rect.
> Looks like mostly you're just duplicating the drm_rect stuff. Why can't
> you use what's there already?
That's because the fram
https://bugzilla.kernel.org/show_bug.cgi?id=117171
Bug ID: 117171
Summary: Radeon GPU lockup in X windows after resuming from
blank screen
Product: Drivers
Version: 2.5
Kernel Version: 4.6 rc5 from
http://kern
https://bugzilla.kernel.org/show_bug.cgi?id=117171
--- Comment #1 from erik.brangs at gmx.de ---
Created attachment 214001
--> https://bugzilla.kernel.org/attachment.cgi?id=214001&action=edit
Xorg log
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=117171
--- Comment #2 from erik.brangs at gmx.de ---
Created attachment 214011
--> https://bugzilla.kernel.org/attachment.cgi?id=214011&action=edit
glxinfo from working system
--
You are receiving this mail because:
You are watching the assignee of t
On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> > On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
> >> Add some utility functions for struct drm_clip_rect.
> > Looks like mostly you're just duplicating the drm_rec
A cleanup for the rcar-du driver left an unused variable behind:
drm/rcar-du/rcar_du_drv.c: In function 'rcar_du_probe':
drm/rcar-du/rcar_du_drv.c:300:24: error: unused variable 'connector'
[-Werror=unused-variable]
This removes the variable.
Signed-off-by: Arnd Bergmann
Fixes: d63c25e4245a ("
Hi everyone,
The Allwinner SoCs (except for the very latest ones) all share the
same set of controllers, loosely coupled together to form the display
pipeline.
Depending on the SoC, the number of instances of the controller will
change (2 instances of each in the A10, only one in the A13, for
exa
The TCON, tv-encoder and display engine backends and frontends are combined
to create our display pipeline.
Add them to the R8 DTSI. It's supposed to be perfectly compatible with the
A10s and A13, but since we haven't tested it on them yet, it's safer to
just enable it on the R8. Eventually, it sh
The A10 SoCs and its relatives has a special clock controller to drive the
display engines (both frontend and backend), that have a lot in common with
the clock to drive the first TCON channel.
Add a driver to support both.
Signed-off-by: Maxime Ripard
Acked-by: Rob Herring
---
Documentation/d
The display pipeline of the Allwinner A10 is involving several loosely
coupled components.
Add a documentation for the bindings.
Signed-off-by: Maxime Ripard
---
.../bindings/display/sunxi/sun4i-drm.txt | 258 +
1 file changed, 258 insertions(+)
create mode 100644
Now that we have support for the composite output, we can start adding new
supported standards. Start with PAL, and we will add other eventually.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 42
1 file changed, 42 insertions(+)
dif
The CHIP has a composite output available muxed with the microphone in the
micro-jack plug.
Enable the composite output in its DTS.
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-r8-chip.dts | 12
1 file changed, 12 insertions(+)
diff --git a/arch/arm/boot/dts/sun5i-r8-c
Enable the display and TCON (channel 0 and channel 1) clocks that are going
to be needed to drive the display engine, tcon and TV encoders.
Acked-by: Chen-Yu Tsai
Signed-off-by: Maxime Ripard
---
arch/arm/boot/dts/sun5i-a13.dtsi | 39 +--
arch/arm/boot/dts/su
One of the A10 display pipeline possible output is an RGB interface to
drive LCD panels directly. This is done through the first channel of the
TCON that will output our video signals directly.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 1 +
drivers/gpu/drm/sun4i/sun
The Allwinner A10 and subsequent SoCs share the same display pipeline, with
variations in the number of controllers (1 or 2), or the presence or not of
some output (HDMI, TV, VGA) or not.
Add a driver with a limited set of features for now, and we will hopefully
support all of them eventually
Sig
Some Allwinner SoCs have an IP called the TV encoder that is used to output
composite and VGA signals. In such a case, we need to use the second TCON
channel.
Add support for that TV encoder.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/Makefile | 2 +
drivers/gpu/drm/sun4i/sun4i_
Add the settings to support the NTSC standard.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 45
1 file changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tv.c b/drivers/gpu/drm/sun4i/sun4i_tv.c
index ccf275a90132..b
Otherwise, building with DEBUG_FS enabled will trigger a build warning
because we're using a structure that has not been declared.
Signed-off-by: Maxime Ripard
---
include/drm/drm_fb_cma_helper.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_fb_cma_helper.h b/include/drm/
On 4/25/2016 10:25 AM, Geert Uytterhoeven wrote:
>> The TCNE2 bit of the DEFR6 register was renamed to TCNE1 in the R-Car gen2
>> manuals -- which makes more sense as that bit controls whether DU1, not DU2
>> is connected to TCON.
>>
>> While at it, add the TCNE0 bit which controls whether DU0
Provide a small convenience wrapper that transmits
ia set_tear_scanline command as suggested by
Thierry Reding.
Also includes small build fixes from Sumit Semwal.
Cc: Archit Taneja
Cc: John Stultz
Cc: Thierry Reding
Cc: Sumit Semwal
Signed-off-by: Vinay Simha BN
---
v2:
* Added fix for com
VERSION_OVERRIDE=4.3 MESA_GLSL_VERSION_OVERRIDE=430.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/8b476ef5/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #6 f
Den 25.04.2016 15:02, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
>> Den 25.04.2016 14:39, skrev Ville Syrjälä:
>>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes wrote:
Add some utility functions for struct drm_clip_rect.
>>> Looks l
Add MAINTAINERS entry for ARM Mali-DP driver and update the
HDLCD file matching pattern to cover only HDLCD rather than
the whole drivers/gpu/drm/arm directory.
Signed-off-by: Liviu Dudau
---
MAINTAINERS | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/MAINTAINERS b/
Hello,
This is the second revision of the driver for the Mali Display Processors (Mali
DP).
Currently, the driver supports the Display Engine found in Mali DP500, DP550
and DP650, with up to 3 planes that can be rotated by the hardware. There are
features that the hardware supports that are not c
Add support for the new family of Display Processors from ARM Ltd.
This commit adds basic support for Mali DP500, DP550 and DP650
parts, with only the display engine being supported at the moment.
Cc: David Brown
Cc: Brian Starkey
Signed-off-by: Liviu Dudau
---
drivers/gpu/drm/arm/Kconfig
Add DT bindings documentation for the Mali Display Processor. The bindings
describe the Mali DP500, DP550 and DP650 processors from ARM Ltd.
Cc: Rob Herring
Cc: Pawel Moll
Cc: Mark Rutland
Cc: Ian Campbell
Cc: Kumar Gala
Signed-off-by: Liviu Dudau
---
.../devicetree/bindings/display/arm,ma
attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/8d8b6e09/attachment.html>
org/archives/dri-devel/attachments/20160425/215576e0/attachment.html>
ves/dri-devel/attachments/20160425/06592ce9/attachment.html>
ves/dri-devel/attachments/20160425/112f54fc/attachment.html>
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/6aef418b/attachment.html>
On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> >> Den 25.04.2016 14:39, skrev Ville Syrjälä:
> >>> On Sun, Apr 24, 2016 at 10:48:55PM +0200, Noralf Trønnes w
https://bugzilla.kernel.org/show_bug.cgi?id=117111
Alex Deucher changed:
What|Removed |Added
CC||alexdeucher at gmail.com
--- Comment #1 f
On Sun, Apr 24, 2016 at 11:12:28AM +0100, Emil Velikov wrote:
> On 22 April 2016 at 15:22, Sinclair Yeh wrote:
> > Hi,
> >
> > On Fri, Apr 22, 2016 at 12:04:00AM +0100, Emil Velikov wrote:
> >> Thomas is one of the original authors of the driver, with recent
> >> contributions from Sinclair and Br
org/archives/dri-devel/attachments/20160425/95ea0939/attachment.html>
org/archives/dri-devel/attachments/20160425/e375fc26/attachment.html>
On Sun, Apr 17, 2016 at 10:15 AM, Moritz Kühner
wrote:
> I got myself a 380X recently and started reading random mesa and kernel
> code in the hopes that I would find something that I can fix or improve,
> and something actually caught my eye. Some of the error handling in
> tonga_get_evv_voltage
Hi Maxime,
On 25 April 2016 at 14:22, Maxime Ripard
wrote:
> Documentation/devicetree/bindings/clock/sunxi.txt | 2 +
> .../bindings/display/sunxi/sun4i-drm.txt | 258
> arch/arm/boot/dts/sun5i-a13.dtsi | 39 +-
> arch/arm/boot/dts/sun5i-r8-chip.dts
op.org/archives/dri-devel/attachments/20160425/14c02077/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/bf631032/attachment.html>
mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f62c4b02/attachment.html>
On 25 April 2016 at 15:19, Liviu Dudau wrote:
> Add MAINTAINERS entry for ARM Mali-DP driver and update the
> HDLCD file matching pattern to cover only HDLCD rather than
> the whole drivers/gpu/drm/arm directory.
>
> Signed-off-by: Liviu Dudau
> ---
> MAINTAINERS | 10 +-
> 1 file change
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/233ef7bc/attachment-0001.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117111
MichaÅ Pecio changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> >
> > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > On Mon, Apr 25, 2016 at 02:55:52PM +0200, Noralf Trønnes wrote:
> > >> Den 25.04.2016 14:39, skrev Ville S
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a7c33cde/attachment.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/47875db4/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/1b9f4b9f/attachment-0001.html>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/05e483c1/attachment-0001.html>
the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/d9592bd8/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117181
Bug ID: 117181
Summary: graphic glitches for Kernel > 4.2 Intel HD 5xx and
skylake
Product: Drivers
Version: 2.5
Kernel Version: 4.5.2
Hardware: Intel
O
On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> > On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
> > >
> > > Den 25.04.2016 15:02, skrev Ville Syrjälä:
> > > > On Mon, Apr 25, 2016 at 02:55:52PM
Hi Arnd,
Thank you for the patch.
On Monday 25 Apr 2016 15:11:08 Arnd Bergmann wrote:
> A cleanup for the rcar-du driver left an unused variable behind:
>
> drm/rcar-du/rcar_du_drv.c: In function 'rcar_du_probe':
> drm/rcar-du/rcar_du_drv.c:300:24: error: unused variable 'connector'
> [-Werror=u
On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
> On 25 April 2016 at 15:19, Liviu Dudau wrote:
> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
> > HDLCD file matching pattern to cover only HDLCD rather than
> > the whole drivers/gpu/drm/arm directory.
> >
> > Signed-
nt was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/2e0abace/attachment-0001.html>
l/attachments/20160425/9cfcde54/attachment.html>
fers often.
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/487c3031/attachment.html>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/86496701/attachment.html>
|RESOLVED
--
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/739f179b/attachment.html>
tps://lists.freedesktop.org/archives/dri-devel/attachments/20160425/ccca2221/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #7 from Jason Vas Dias ---
(In reply to Alex Deucher from comment #6)
> Your system is muxless so there is no mux to switch. The displays are only
> connected to the IGP. You need to use the xserver PRIME stuff to render
> with the
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #8 from Jason Vas Dias ---
As stated on the web-page quoted above ,
( https://wiki.archlinux.org/index.php/PRIME )
an example xorg.conf to use the discrete card
as primary GPU is:
# Discrete Card as Primary GPU
Section "ServerLayo
:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/057e8dbf/attachment.html>
On 25 April 2016 at 18:08, Liviu Dudau wrote:
> On Mon, Apr 25, 2016 at 05:00:02PM +0100, Emil Velikov wrote:
>> On 25 April 2016 at 15:19, Liviu Dudau wrote:
>> > Add MAINTAINERS entry for ARM Mali-DP driver and update the
>> > HDLCD file matching pattern to cover only HDLCD rather than
>> > the
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #9 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #8)
> As stated on the web-page quoted above ,
> ( https://wiki.archlinux.org/index.php/PRIME )
> an example xorg.conf to use the discrete card
> as primary GPU is:
>
--
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f6edfeaf/attachment.html>
Den 25.04.2016 18:38, skrev Ville Syrjälä:
> On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
>> On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
>>> On Mon, Apr 25, 2016 at 04:03:13PM +0200, Noralf Trønnes wrote:
Den 25.04.2016 15:02, skrev Ville Syrjälä:
>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #10 from Jason Vas Dias ---
OK, fine, I have to use FGLRX to use the Radeon as the primary display
as I do under OEL7 (Linux 3.10) -
what a terrific new open source radeon driver Linux 4.5 has.
But I cannot even get the Intel card
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #11 from Alex Deucher ---
(In reply to Jason Vas Dias from comment #10)
> OK, fine, I have to use FGLRX to use the Radeon as the primary display
> as I do under OEL7 (Linux 3.10) -
> what a terrific new open source radeon driver Lin
On Mon, Apr 25, 2016 at 08:35:18PM +0200, Noralf Trønnes wrote:
>
> Den 25.04.2016 18:38, skrev Ville Syrjälä:
> >On Mon, Apr 25, 2016 at 06:05:20PM +0200, Daniel Vetter wrote:
> >>On Mon, Apr 25, 2016 at 06:09:44PM +0300, Ville Syrjälä wrote:
> >>>On Mon, Apr 25, 2016 at 04:03:13PM +0200, No
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #12 from Jason Vas Dias ---
Created attachment 214151
--> https://bugzilla.kernel.org/attachment.cgi?id=214151&action=edit
dmesg boot log
Boot DMESG log as requested
--
You are receiving this mail because:
You are watching the as
.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/367eb80d/attachment.html>
Some more tables with constant data were added with the polaris support
v2: missed a few
Signed-off-by: Nils Wallménius
---
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32 --
.../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.h | 2 +-
.../drm/amd/powerplay/hwmgr/po
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #13 from Jason Vas Dias ---
Yes, radeon.runpm=0 has stopped the ACPI problem - but the latest Xorg
xf86-video-intel driver ( 2.99.917 ) apparently does not work with the
latest xorg server (1.18.3) and gets a segmentation violation o
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #1 from yves.dufournaud at gmail.com ---
there is another issue: resuming from suspend to ram is failing, I would have
filled a separate bug, but apparently it can be linked to graphics.
following the instruction here:
https://01.org/
On Mon, Apr 25, 2016 at 3:31 PM, Nils Wallménius
wrote:
> Some more tables with constant data were added with the polaris support
>
> v2: missed a few
>
> Signed-off-by: Nils Wallménius
Applied. thanks!
Alex
> ---
> .../gpu/drm/amd/powerplay/hwmgr/polaris10_hwmgr.c | 32
> ---
On Sun, Apr 24, 2016 at 7:21 AM, Nils Wallménius
wrote:
> Signed-off-by: Nils Wallménius
Applied, thanks!
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/cz_clockpowergating.h
On Sun, Apr 24, 2016 at 7:22 AM, Nils Wallménius
wrote:
> Signed-off-by: Nils Wallménius
Let me check with the powerplay team and make sure they are planning
to use these in the near future.
Alex
> ---
> drivers/gpu/drm/amd/powerplay/hwmgr/ppevvmath.h | 59
> +
> 1
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #14 from Alex Deucher ---
It sounds like it's a bug in the intel driver. The radeon driver appears to be
loading fine. Can you get any display on the intel card at all? You can
blacklist the radeon driver (append modeprobe.blanklis
You are receiving this mail because:
You are the assignee for the bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/41fe6d14/attachment.html>
bug.
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/e8cabb76/attachment.html>
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #15 from 3pb33h+1ymmkx54pslys at sharklasers.com ---
Seems like alex made an typo i think it should be modprobe.blacklist=radeon
--
You are receiving this mail because:
You are watching the assignee of the bug.
https://bugzilla.kernel.org/show_bug.cgi?id=117131
--- Comment #16 from Alex Deucher ---
(In reply to 3pb33h+1ymmkx54pslys from comment #15)
> Seems like alex made an typo i think it should be modprobe.blacklist=radeon
Yes you are correct, sorry about that.
--
You are receiving this mail becau
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #2 from yves.dufournaud at gmail.com ---
tested with CONFIG_PM_DEBUG with core/processors/device
dmesg > dmesg_before; echo mem > /sys/power/state; dmesg > dmesg_after
machine resume after few second, but mouse pointer is lost (not v
https://bugzilla.kernel.org/show_bug.cgi?id=117181
--- Comment #3 from yves.dufournaud at gmail.com ---
Created attachment 214301
--> https://bugzilla.kernel.org/attachment.cgi?id=214301&action=edit
dmesg_after.txt
output of dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >
dmesg_after
HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/a178d2b0/attachment.html>
From: Gustavo Padovan
Hi,
Currently the Linux Kernel only have an implicit fencing mechanism
where the fence are attached directly to buffers and userspace is unaware of
what is happening. On the other hand explicit fencing which is not supported
yet by Linux but it expose fences to the userspac
From: Gustavo Padovan
Creates a function that given an sync file descriptor returns a
fence_collection containing all fences in the sync_file.
If there is only one fence in the sync_file this fence itself is returned,
however if there is more than one, a fence_collection fence is returned.
v2:
From: Gustavo Padovan
struct fence_collection inherits from struct fence and carries a
collection of fences that needs to be waited together.
It is useful to translate a sync_file to a fence to remove the complexity
of dealing with sync_files on DRM drivers. So even if there are many
fences in t
From: Gustavo Padovan
Support DRM out-fences creating a sync_file with a fence for each crtc
update with the DRM_MODE_ATOMIC_OUT_FENCE flag.
We then send an struct drm_out_fences array with the out-fences fds back in
the drm_atomic_ioctl() as an out arg in the out_fences_ptr field.
struct drm_o
From: Gustavo Padovan
Include fence-collection files in the DocBook.
Signed-off-by: Gustavo Padovan
---
Documentation/DocBook/device-drivers.tmpl | 2 ++
1 file changed, 2 insertions(+)
diff --git a/Documentation/DocBook/device-drivers.tmpl
b/Documentation/DocBook/device-drivers.tmpl
index 5
From: Gustavo Padovan
If userspace is running an synchronously atomic commit and interrupts the
atomic operation during fence_wait() it will hang until the timer expires,
so here we change the wait to be interruptible so it stop immediately when
userspace wants to quit.
Also adds the necessary e
From: Gustavo Padovan
There is now a new property called FENCE_FD attached to every plane
state that receives the sync_file fd from userspace via the atomic commit
IOCTL.
The fd is then translated to a fence (that may be a fence_collection
subclass or just a normal fence) and then used by DRM to
From: Gustavo Padovan
Create one timeline context for each CRTC to be able to handle out-fences
and signal them. It adds a few members to struct drm_crtc: fence_context,
where we store the context we get from fence_context_alloc(), the
fence seqno and the fence lock, that we pass in fence_init()
From: Gustavo Padovan
Now a drm_pending_event can either send a real drm_event or signal a
fence, or both. It allow us to signal via fences when the buffer is
displayed on the screen. Which in turn means that the previous buffer
is not in use anymore and can be freed or sent back to another drive
scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/f667fc1c/attachment.html>
ode.h | 11 +-
> 17 files changed, 600 insertions(+), 22 deletions(-)
> create mode 100644 drivers/dma-buf/fence-collection.c
> create mode 100644 include/linux/fence-collection.h
>
> --
> 2.5.5
>
> ___
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
-- next part --
An HTML attachment was scrubbed...
URL:
<https://lists.freedesktop.org/archives/dri-devel/attachments/20160425/356c86d0/attachment-0001.html>
1 - 100 of 172 matches
Mail list logo
