From: Chi Ding
This function will be used not only by SKL but also VLV/CHV.
Therefore it's renamed.
Signed-off-by: Chi Ding
cc: Ville Syrjälä
cc: matthew.d.ro...@intel.com
cc: yetundex.adeb...@intel.com
---
drivers/gpu/drm/i915/intel_pm.c | 59 +
1 fil
From: Maarten Lankhorst
This patch prepares for two-level watermark support in the next commit
Change the code to use the optimal field
This patch adds optimal field, but doesn't change the code to use
two-level watermark yet
The patch is based on Maarten Lankhorst's code and created by Chi Di
From: Maarten Lankhorst
Rename vlv_compute_wm to vlv_compute_pipe_wm to compute optimal watermark
Add vlv_compute_intermediate_wm to computer intermediate watermark
Add vlv_initial_watermarks to write intermediate watermark into hardware
Add vlv_optimize_watermarks to write optimal watermark into
From: Maarten Lankhorst
This patch doesn't change the code to use two-level watermark yet,
With this patch the watermarks are saved for each plane and the wm
state, instead of previously only for the plane
The patch is based on Maarten Lankhorst's work and created by Chi Ding
Signed-off-by: Maa
From: Chi Ding
Everything except fifo_size is unused and therefore removed
This is the first patch of two-level watermark for VLV/CHV
v2: Split the first patch of v1 into the following patches
- Remove unused parameters from intel_plane_wm_parameters.
- Rename skl_plane_id to wm_plane_id.
- Mov
[RFC 1/5] Remove unused parameters from intel_plane_wm_parameters
[RFC 2/5] Rename skl_plane_id to wm_plane_id
[RFC 3/5] Move fifo_size from intel_plane_wm_parameters to
[RFC 4/5] Add optimal field in intel_crtc_wm_state for VLV
[RFC 5/5] Add intermediate field in intel_crtc_wm_state and handlers
If the VBT says that a certain port should be eDP (and hence fused off
from HDMI), but in reality it isn't, we need to try and acquire the HDMI
connection instead. So only trust the VBT edp setting if we can connect
to an eDP device on that port.
Fixes: d2182a6608 (drm/i915: Don't register HDMI co
Hi Dave,
Frist -misc pull for 4.8, with pretty much just random all over plus a few
more lockless gem BO patches acked/reviewed by driver maintainers.
I'm starting a bit earlier this time around because there's a few invasive
patch series to land (nonblocking atomic prep work, fence prep work,
rs
== Series Details ==
Series: series starting with [RFC,1/5] Remove unused parameters from
intel_plane_wm_parameters
URL : https://patchwork.freedesktop.org/series/8078/
State : warning
== Summary ==
Series 8078v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/8078
Hi Dave,
lockless gem bo freeing patches (and the oddball related patch) for all
the drivers who's maintainers are asleep at the helm - includes you ;-)
I based this on top of drm-fixes to include Chris' fix for the cma issue.
Cheers, Daniel
The following changes since commit d3922b69617b62bb2
== Series Details ==
Series: drm/i915: Only ignore eDP ports that are connected
URL : https://patchwork.freedesktop.org/series/8080/
State : warning
== Summary ==
Series 8080v1 drm/i915: Only ignore eDP ports that are connected
http://patchwork.freedesktop.org/api/1.0/series/8080/revisions/1/m
These warnings are too not related to the patch.
Kindly push this patch.
On 5/31/2016 4:35 PM, Patchwork wrote:
== Series Details ==
Series: series starting with [1/1] drm/i915: Never fully mask the the EI up rps
interrupt on SNB/IVB
URL : https://patchwork.freedesktop.org/series/7990/
State
On 6/1/2016 12:24 PM, Chris Wilson wrote:
On Tue, May 31, 2016 at 04:18:34PM -0700, Matt Roper wrote:
On Tue, May 31, 2016 at 09:51:53AM +0100, Chris Wilson wrote:
On Tue, May 31, 2016 at 01:58:27PM +0530, Sagar Arun Kamble wrote:
On Loading, GuC sets PM interrupts routing (bit 31) and clear
On Wed, Jun 01, 2016 at 08:27:50AM +0100, Chris Wilson wrote:
> If the VBT says that a certain port should be eDP (and hence fused off
> from HDMI), but in reality it isn't, we need to try and acquire the HDMI
> connection instead. So only trust the VBT edp setting if we can connect
> to an eDP dev
Hi Dave,
drm-intel-next-2016-05-22:
- cmd-parser support for direct reg->reg loads (Ken Graunke)
- better handle DP++ smart dongles (Ville)
- bxt guc fw loading support (Nick Hoathe)
- remove a bunch of struct typedefs from dpll code (Ander)
- tons of small work all over to avoid casting between d
On Wed, Jun 01, 2016 at 11:20:04AM +0300, Ville Syrjälä wrote:
> On Wed, Jun 01, 2016 at 08:27:50AM +0100, Chris Wilson wrote:
> > If the VBT says that a certain port should be eDP (and hence fused off
> > from HDMI), but in reality it isn't, we need to try and acquire the HDMI
> > connection inste
On Wed, Jun 01, 2016 at 11:20:04AM +0300, Ville Syrjälä wrote:
> On Wed, Jun 01, 2016 at 08:27:50AM +0100, Chris Wilson wrote:
> > If the VBT says that a certain port should be eDP (and hence fused off
> > from HDMI), but in reality it isn't, we need to try and acquire the HDMI
> > connection inste
Regards
Shashank
On 5/31/2016 10:00 PM, Ville Syrjälä wrote:
On Tue, May 31, 2016 at 02:55:44PM +0530, Shashank Sharma wrote:
lspcon is a tricky device to detect.
When in LS mode:
It should be detected as a HDMI device, by reading EDID, on
I2C over Aux chanel
When in PCON mode:
Regards
Shashank
On 5/31/2016 10:02 PM, Ville Syrjälä wrote:
On Tue, May 31, 2016 at 02:55:45PM +0530, Shashank Sharma wrote:
Many GEN9 boards come with on-board lspcon cards.
Fot these boards, VBT configuration should properly point out
if a particular port contains lspcon device, so that driv
Regards
Shashank
On 5/31/2016 10:04 PM, Ville Syrjälä wrote:
On Tue, May 31, 2016 at 02:55:46PM +0530, Shashank Sharma wrote:
This patch adds initialization code for lspcon.
What we are doing here is:
- Check if lspcon is configured in VBT for this port
- If lspcon is configured
On Mon, May 30, 2016 at 09:38:21AM +0100, Chris Wilson wrote:
> Protect against drivers that may try to register the connector more
> than once, or who try to unregister it multiple times.
>
> Signed-off-by: Chris Wilson
> Cc: dri-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/drm_crtc.c |
On Mon, May 30, 2016 at 09:38:22AM +0100, Chris Wilson wrote:
> As we now can call drm_connector_unregister() multiple times, provide a
> failsafe unregister for a connector when cleaning it up.
>
> Signed-off-by: Chris Wilson
> Cc: dri-de...@lists.freedesktop.org
Reviewed-by: Daniel Vetter
Ma
On Mon, May 30, 2016 at 09:38:23AM +0100, Chris Wilson wrote:
> When trying to split up the initialisation phase and the registration
> phase, one immediate problem encountered is trying to use our own i2c
> devices before registration with userspace. drm_dp_aux in particular
> only offers an inter
On Wed, Jun 01, 2016 at 11:49:03AM +0200, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 09:38:23AM +0100, Chris Wilson wrote:
> > When trying to split up the initialisation phase and the registration
> > phase, one immediate problem encountered is trying to use our own i2c
> > devices before regis
On Mon, May 30, 2016 at 09:38:20AM +0100, Chris Wilson wrote:
> If a driver wants to more precisely control its initialisation and in
> particular, defer registering its interfaces with userspace until after
> everything is setup, it also needs to defer registering the connectors.
> As some devices
On Mon, May 30, 2016 at 09:38:19AM +0100, Chris Wilson wrote:
> In order to allow drivers to pack their privates and drm_device into one
> struct (e.g. for subclassing), export the initialisation routines for
> struct drm_device.
>
> v2: Missed return ret. That error path had only one job to do!
>
On Wed, Jun 01, 2016 at 12:01:44PM +0200, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 09:38:19AM +0100, Chris Wilson wrote:
> > In order to allow drivers to pack their privates and drm_device into one
> > struct (e.g. for subclassing), export the initialisation routines for
> > struct drm_device
Between acquiring the this_cpu_ptr() and using it, ideally we don't want
to be preempted and work on another CPU's private data. If we disable
preemption around this_cpu_ptr, we do not need the CPU local spinlock -
so long as take care that no other CPU is running that code as do perform
the cross-
On Wed, Jun 01, 2016 at 12:01:44PM +0200, Daniel Vetter wrote:
> With the one bug in the error handling fixed, and the kerneldoc augmented:
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index f0553ccd4f71..4f3d3bba08f7 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/d
On 31/05/16 07:19, ankitprasad.r.sha...@intel.com wrote:
From: Ankitprasad Sharma
When constructing a batchbuffer, it is sometimes crucial to know the
largest hole into which we can fit a fenceable buffer (for example when
handling very large objects on gen2 and gen3). This depends on the
frag
On Wed, Jun 01, 2016 at 11:57:09AM +0200, Daniel Vetter wrote:
> On Mon, May 30, 2016 at 09:38:20AM +0100, Chris Wilson wrote:
> > If a driver wants to more precisely control its initialisation and in
> > particular, defer registering its interfaces with userspace until after
> > everything is setu
== Series Details ==
Series: iommu: Disable preemption around use of this_cpu_ptr() (rev2)
URL : https://patchwork.freedesktop.org/series/8052/
State : success
== Summary ==
Series 8052v2 iommu: Disable preemption around use of this_cpu_ptr()
http://patchwork.freedesktop.org/api/1.0/series/805
Between acquiring the this_cpu_ptr() and using it, ideally we don't want
to be preempted and work on another CPU's private data. this_cpu_ptr()
checks whether or not preemption is disable, and get_cpu_ptr() provides
a convenient wrapper for operating on the cpu ptr inside a preemption
disabled crit
By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
having a spinlock inside the per-cpu struct. The only place where we
actually may touch another CPU's data is when performing a cache flush
after running out of memory. Here, we can instead schedule a task to run
on the other CPU t
[+Daniel Vetter]
Hi Ankitprasad,
On 31 May 2016 at 07:19, wrote:
> Signed-off-by: Chris Wilson
> Signed-off-by: Rodrigo Vivi
Seems like you've picked the patch from the mailing list, which does
s/@/ at /. You might want to revert that and normalise the emails.
> --- a/include/uapi/drm/i915_
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> Between acquiring the this_cpu_ptr() and using it, ideally we don't want
> to be preempted and work on another CPU's private data. this_cpu_ptr()
> checks whether or not preemption is disable, and get_cpu_ptr() provides
> a convenient wrapper
On 1 June 2016 at 13:11, Emil Velikov wrote:
> [+Daniel Vetter]
>
> Hi Ankitprasad,
>
> On 31 May 2016 at 07:19, wrote:
>
>> Signed-off-by: Chris Wilson
>> Signed-off-by: Rodrigo Vivi
> Seems like you've picked the patch from the mailing list, which does
> s/@/ at /. You might want to revert t
On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> >> On Tue, May 24, 2016 at 06:03:27PM +0200, Lukas Wunner wrote:
> >> > When a drm_crtc structure is destroyed
On ke, 2016-06-01 at 12:10 +0100, Chris Wilson wrote:
> By avoiding cross-CPU usage of the per-cpu iova cache, we can forgo
> having a spinlock inside the per-cpu struct. The only place where we
> actually may touch another CPU's data is when performing a cache flush
> after running out of memory.
On ti, 2016-05-31 at 22:01 +0800, Zhiyuan Lv wrote:
> Hi Joonas,
>
> On Fri, May 27, 2016 at 02:32:25PM +0300, Joonas Lahtinen wrote:
> >
> > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > >
> > > For me I think maybe i915 could save the snapshot for GVT, then GVT-g
> > > patch the sn
On Mon, May 30, 2016 at 06:10:20PM +0300, Mika Kuoppala wrote:
> According to bspec this prevents screen corruption when fbc is
> used.
>
> v2: This workaround has a name, use it (Ville)
> v3: remove bogus gen check on ilk/vlv wm path (Ville)
>
> References: HSD#213, HSD#2137270, BSID#562
> C
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Kumar Mahesh
On Tuesday 31 May 2016 10:28 PM, Matt Roper wrote:
From: "Kumar, Mahesh"
don't always use 8 ddb as minimum, instead calculate using proper
algorithm.
v2: optimizations as per Matt's comments.
v3 (by Matt):
- Fix boolean logic for !fb test in skl_ddb_min_alloc()
On Wed, Jun 01, 2016 at 07:54:42AM +0100, Chris Wilson wrote:
> On Tue, May 31, 2016 at 04:18:34PM -0700, Matt Roper wrote:
> > On Tue, May 31, 2016 at 09:51:53AM +0100, Chris Wilson wrote:
> > > On Tue, May 31, 2016 at 01:58:27PM +0530, Sagar Arun Kamble wrote:
> > > > On Loading, GuC sets PM inte
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
On Wed, Jun 01, 2016 at 02:36:41PM +0200, Lukas Wunner wrote:
> On Wed, May 25, 2016 at 03:43:42PM +0200, Daniel Vetter wrote:
> > On Wed, May 25, 2016 at 12:51 PM, Lukas Wunner wrote:
> > > On Tue, May 24, 2016 at 11:30:42PM +0200, Daniel Vetter wrote:
> > >> On Tue, May 24, 2016 at 06:03:27PM +0
On Wed, Jun 01, 2016 at 07:55:18PM +0530, Mahesh Kumar wrote:
> Reviewed-by: Kumar Mahesh
Merged to dinq; thanks for the review (and thanks for doing the initial
work this series was based on).
Matt
>
> On Tuesday 31 May 2016 10:28 PM, Matt Roper wrote:
> >From: "Kumar, Mahesh"
> >
> >don't
On Wed, Jun 01, 2016 at 11:38:03AM +0100, Chris Wilson wrote:
> On Wed, Jun 01, 2016 at 11:57:09AM +0200, Daniel Vetter wrote:
> > On Mon, May 30, 2016 at 09:38:20AM +0100, Chris Wilson wrote:
> > > If a driver wants to more precisely control its initialisation and in
> > > particular, defer regist
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Joonas,
On Wed, Jun 01, 2016 at 03:49:59PM +0300, Joonas Lahtinen wrote:
> On ti, 2016-05-31 at 22:01 +0800, Zhiyuan Lv wrote:
> > Hi Joonas,
> >
> > On Fri, May 27, 2016 at 02:32:25PM +0300, Joonas Lahtinen wrote:
> > >
> > > On pe, 2016-05-27 at 10:05 +, Wang, Zhi A wrote:
> > > >
> >
On Fri, May 27, 2016 at 05:27:03PM +0300, Mika Kuoppala wrote:
> Bspec states that we need to set nuke on modify all to prevent
> screen corruption with fbc on skl and kbl.
>
> v2: proper workaround name
>
> References: HSD#2227109, HSDES#1404569388
> Signed-off-by: Mika Kuoppala
Reviewed-by: V
On Fri, May 27, 2016 at 05:27:02PM +0300, Mika Kuoppala wrote:
> Set bit 8 in 0x43224 to prevent screen corruption and system
> hangs on high memory bandwidth conditions. The same wa also suggest
> setting bit 31 on ARB_CTL. According to another workaround we gain
> better idle power savings when F
s/tho/though/
s/regarless/regardless/
Seems reasonable so:
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
We exit early if has_aliasing_ppgtt is 0, so towards the end of the
function has_aliasing_ppgtt can only be 1.
Also:
if (foo)
return 1;
else
return 0;
when foo is already a bool is really just:
return foo;
Signed-off-by: Damien Lespiau
-
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Hi Daniel,
On Sun, May 29, 2016 at 08:35:16PM +0200, Daniel Vetter wrote:
> atomic_flush seems to be the right place, right after we commit the
> plane updates. Again use the fullproof version, since the pipe might
> be off.
This looks fine.
How can that be tested? modetest requires async vblank
On Wed, Jun 01, 2016 at 05:01:13PM +0100, Damien Lespiau wrote:
> We exit early if has_aliasing_ppgtt is 0, so towards the end of the
> function has_aliasing_ppgtt can only be 1.
>
> Also:
>
> if (foo)
> return 1;
> else
> return 0;
>
> when foo is already
From: John Harrison
The intended usage model for struct fence is that the signalled status
should be set on demand rather than polled. That is, there should not
be a need for a 'signaled' function to be called everytime the status
is queried. Instead, 'something' should be done to enable a signal
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
The change to the implementation of i915_gem_request_completed() means
that the lazy coherency flag is no longer used. This can now be
removed to simplify the interface.
v6: Updated to newer nightly and resolved conflicts.
v7: Updated to newer nightly (lots of ring -> engine
From: John Harrison
The notify function can be called many times without the seqno
changing. Some are to prevent races due to the requirement of not
enabling interrupts until requested. However, when interrupts are
enabled the IRQ handler can be called multiple times without the
ring's seqno valu
From: John Harrison
There is a construct in the linux kernel called 'struct fence' that is
intended to keep track of work that is executed on hardware. I.e. it
solves the basic problem that the drivers 'struct
drm_i915_gem_request' is trying to address. The request structure does
quite a lot more
From: John Harrison
Added the '_complete' trace event which occurs when a fence/request is
signaled as complete. Also moved the notify event from the IRQ handler
code to inside the notify function itself.
v3: Added the current ring seqno to the notify trace point.
v5: Line wrapping to keep the
My old 845g complains that the child_device_size inside its VBT,
version 110, is incorrect. Let's fiddle with the version matching such
that it works with this VBT (i.e. treat BIOS v110 as having the same size
as v108).
Fixes [drm:intel_bios_init] *ERROR* Unexpected child device config
size 27 (ex
From: John Harrison
The purpose of this patch series is to convert the requst structure to
use fence objects for the underlying completion tracking. The fence
object requires a sequence number. The ultimate aim is to use the same
sequence number as for the request itself (or rather, to remove the
On Wed, Jun 01, 2016 at 06:08:43PM +0100, Chris Wilson wrote:
> My old 845g complains that the child_device_size inside its VBT,
> version 110, is incorrect. Let's fiddle with the version matching such
> that it works with this VBT (i.e. treat BIOS v110 as having the same size
> as v108).
>
> Fixe
On Wed, Jun 01, 2016 at 06:18:59PM +0200, Maxime Ripard wrote:
> Hi Daniel,
>
> On Sun, May 29, 2016 at 08:35:16PM +0200, Daniel Vetter wrote:
> > atomic_flush seems to be the right place, right after we commit the
> > plane updates. Again use the fullproof version, since the pipe might
> > be off
Ping, any update on this?
On Wed, 2016-05-18 at 17:35 -0400, Lyude wrote:
> From: Lyude Paul
>
> DRM does not always update the status of each connector during a
> hotplug event, and it's generally expected that userspace is supposed
> to
> handle that by reprobing. This happens in a couple situ
Hi all,
Now without the RFC tag, but with polish:
- kerneldoc for everything!
- tested on virtio, hdlcd, rockchip and i915.
The big upshot is still that the helpers are really picky about drivers sending
out drm events correctly, and that is the area where most of the debug work was
needed in tes
... and use it in msm&vc4. Again just want to encapsulate
drm_atomic_state internals a bit.
The const threading is a bit awkward in vc4 since C sucks, but I still
think it's worth to enforce this. Eventually I want to make all the
obj->state pointers const too, but that's a lot more work ...
Cc:
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-connector state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more
It's silly to have 2 mallocs when we could tie these two together.
Also, Gustavo adds another one in his per-crtc out-fence patches. And
I want to add more stuff here for nonblocking commit helpers.
In the future we can use this to store a pointer to the preceeding
state, making an atomic update
We want to hide drm_atomic_state internals better.
Cc: Laurent Pinchart
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/rcar-du/rcar_du_kms.c | 8
drivers/gpu/drm/rcar-du/rcar_du_plane.c | 20
2 files changed, 12 insertions(+), 16 deletions(-)
diff --git a/dri
- dev is redundant, we have state->atomic
- add stall parameter, which must be set when swapping needs to stall
for preceeding commits to stop looking at ->state pointers. Currently
all drivers need this to be, just prep work for a glorious future.
Signed-off-by: Daniel Vetter
---
drivers/gp
We want to hide drm_atomic_stat internals a bit better.
Cc: Laurent Pinchart
Cc: Tomi Valkeinen
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/omapdrm/omap_drv.c | 11 +--
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/
We want to hide drm_atomic_state internals
Cc: Rob Clark
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/msm/mdp/mdp4/mdp4_kms.c| 20 +++--
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 12 +++---
drivers/gpu/drm/msm/msm_atomic.c | 35 ++
It's kinda pointless to have 2 separate mallocs for these. And when we
add more per-plane state in the future it's even more pointless.
Right now there's no such thing planned, but both Gustavo's per-crtc
fence patches, and some nonblocking commit helpers I'm playing around
with will add more per-
We want to hide drm_atomic_stat internals a bit better.
Cc: Eric Anholt
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index cb37751bc99f.
We want to encapsulate the drm_atomic_state internals.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_atomic.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic.c
b/drivers/gpu/drm/i915/intel_atomic.c
index 50ff90aea721..3e6d9f
This avois leaking drm_atomic_state internals into the helpers. The
only place where this still happens after this patch is
drm_atomic_helper_swap_state().
It's unavoidable there, and maybe a good indicator we should actually
move that function into drm_atomic.c.
Signed-off-by: Daniel Vetter
---
We want to hide drm_atomic_state internals better.
Cc: Inki Dae
Acked-by: Inki Dae
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exy
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
Design ideas:
- split up the actual commit into different phases, and have
completions for each of them. This will be useful for the future
when we want to interleave phases much more aggressively, for e.g.
queue depth > 1. For not it's just a minimal optimization compared
to current commo
This is part of what atomic must implement. And it's also required
to be able to use the helper nonblocking support.
v2: Always send out the drm event, remove the planes_changed check.
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/i915/intel_display.c | 13 ++---
drivers/gpu/drm/i915
With the fixed up drm event handling for crtc_state->event we can just
use the helper support for nonblocking commits.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_drv.c | 8 +---
1 file changed, 1 insertion(+), 7
atomic_flush seems to be the right place, right after we commit the
plane updates. Again use the fullproof version, since the pipe might
be off.
Cc: Boris Brezillon
Cc: Maxime Ripard
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/sun4i/sun4i_crtc.c | 12
1 file changed, 12 inser
No idea how exactly fsl-du commits hw state changes, but here in flush
is probably the safest place.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away.
Cc: Stefan Agner
Signed-off-by: Daniel Vetter
---
drivers/g
event_list just reimplemented what drm_crtc_arm_vblank_event does. And
we also need to send out drm events when shutting down a pipe.
With this it's possible to use the new nonblocking commit support in
the helpers.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Da
This was somehow lost between v3 and the merged version in Maarten's
patch merged as:
commit f2d580b9a8149735cbc4b59c4a8df60173658140
Author: Maarten Lankhorst
Date: Wed May 4 14:38:26 2016 +0200
drm/core: Do not preserve framebuffer on rmfb, v4.
Actual code copied from Maarten's patch, b
Note that I didn't start garbage collecting all the legacy flip code
yet, to make it easier to revert this. But there will be _lots_ of
code that can be removed once this is tested on all platforms.
FIXME: obj->frontbuffer_bits gets out of whack when pipelining
commits too hard.
Signed-off-by: Da
Committing with block it is not.
Thanks to the fixed up vblank event handling we can just use the
helper support for nonblocking commits now.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps-...@lists.infradead.org
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arc/arcpgu_drv.c | 8 +--
atomic_flush seems to be the right place, but I'm not entirely sure
whether this will catch them all. It could be that when disabling the
crtc we'll miss the vblank.
While at it nuke the dummy functions.
v2: Be more robust and either arm, when the CRTC is on, or just send
the event out right away
Rockchip just blew up here on testing, because I removed some "is this
crtc already disabled/enabled" state tracking from callbacks (not needed
with atomic). Turns out that was needed to work around rockchip still
calling legacy helper code.
Since me explaining on irc/mailing-list plus kerneldoc i
The drm core has a nice ready-made helper for exactly the simple case
where it should fire on the next vblank.
Note that arming the vblank event in _begin is probably too early, and
might easily result in the vblank firing too early, before the new set
of planes are actually disabled. But that's k
Now that the core helpers support nonblocking atomic commits there's
no need to invent that wheel separately (instead of fixing the bug in
the atomic implementation of virtio, as it should have been done!).
Cc: Gerd Hoffmann
Tested-by: Gerd Hoffmann
Reviewed-by: Gerd Hoffmann
Signed-off-by: Dan
Currently it's part of prepare_fb, still in the first phase of
atomic_commit which might fail. Which means that we need to have some
heuristics in cleanup_fb to figure out whether things failed, or
whether we just clean up the old fbs.
That's fragile, and worse, once we start pipelining commits ge
This is just used for cleanup in preclose, and with the reworked event
handling code this is now done properly by the core.
Nuke it!
But it also shows that arc totally fails at sending out drm events for
flips. Next patch will hack that up.
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: linux-snps
Just a bit of drive-by ocd.
Signed-off-by: Daniel Vetter
---
include/drm/drm_atomic.h | 7 +++
1 file changed, 7 insertions(+)
diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index d9504dfcd1cc..465a1212f4f0 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic
Those are all no longer needed for a pure atomic driver.
Cc: Liviu Dudau
Tested-by: Liviu Dudau
Acked-by: Liviu Dudau
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/arm/hdlcd_crtc.c | 19 ---
1 file changed, 19 deletions(-)
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/dr
1 - 100 of 127 matches
Mail list logo
