Tested-By: Intel Graphics QA PRTS (Patch Regression Test System Contact:
shuang...@intel.com)
Task id: 6432
-Summary-
Platform Delta drm-intel-nightly Series Applied
PNV
The values that ultimately get passed to
intel_update_sprite_watermarks() are pulled out of the plane state
(which has already been swapped into plane->state) as we update the
plane programming. Drop the function parameters and just pull the
relevant values out of the state structure inside the fu
Rather that just comparing and then throwing away the pipe watermark
values we precomputed at atomic check time, actually use those values
when we program watermarks.
FIXME: This should be squashed into the previous patch eventually, once
we're convinced that pre-computed watermarks get the prope
Use the new vblank job infrastructure to schedule watermark programming
to happen when the next vblank occurs.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 7 +++
drivers/gpu/drm/i915/intel_display.c | 38 +++-
drivers/gpu/drm/i915/int
From: Ville Syrjälä
Split ilk_update_wm() into two parts; one doing the programming
and the other the calculations.
v2: Fix typo in commit message
v3 (by Matt): Heavily rebased for current codebase.
Reviewed-by(v2): Paulo Zanoni
Signed-off-by: Ville Syrjälä
Signed-off-by: Matt Roper
---
dr
Just pull the info out of the CRTC state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 98 ++---
1 file changed, 34 insertions(+), 64 deletions(-)
diff --git a/drivers/gpu/drm/i915
We never removed the sprite watermark updates from our low-level
foo_update_plane() functions; since our hardware updates happen under
vblank evasion, we're not supposed to be calling potentially sleeping
functions there (since interrupts are disabled). Ensure that we
properly set the atomic.updat
Various places in the driver need the ability to schedule actions to run
on a future vblank (updating watermarks, unpinning buffers, etc.). The
long term goal is to add such a mechanism in the DRM core that can be
shared by all drivers. Paulo Zanoni has already written some
preliminary patches to
Our atomic transaction maintains a bitmask of planes that we need to
update sprite watermarks for once vblank evasion is complete. When we
actually go to make use of that bitmask, we've been comparing against
the plane index rather than the plane mask; we need to update our
comparison to check '(1
Various places in the atomic plane code obtain the CRTC via
plane_state->crtc. But plane_state->crtc is NULL when disabling the
plane, so the code will fall back to looking at the old CRTC value in
plane->crtc in that case. This isn't going to work when we start
supporting non-blocking flips (sin
Note that we rename them to 'target' since 'active' isn't really an
accurate term given that we're precomputing these well before they get
committed and become active.
Since we allocate a few CRTC states on the stack, also switch the 'wm'
struct here to be a union so that we're not wasting stack s
Just pull the info out of the plane state structure rather than staging
it in an additional structure.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++
drivers/gpu/drm/i915/intel_pm.c | 135 +---
2 files changed, 75 insertions(+), 64 del
From: Matt Roper
In addition to calculating final watermarks, let's also pre-calculate a
set of 'intermediate' watermark values. These intermediate watermarks
merge the watermarks of the old state and the new state such that they
will satisfy the requirements of both states. This means they can
In preparation for refactoring watermark computation out to the atomic
'check' phase, we need to allow that computation to operate on the
in-flight state stored in a drm_atomic_state, rather than
already-committed CRTC and plane states (eventually the drm_atomic_state
should be the only source, but
Our atomic plane code currently uses intel_crtc->active to determine
how/when to update some derived state values. This works fine for pure
plane updates at the moment since the CRTC state itself isn't changed as
part of the operation. However as we convert more of our driver
internals over to at
Here's an early RFC series for transitioning watermark updates to an atomic
model. The general idea is that we want to move calculation of a pipe's
watermark values to the atomic check phase rather than doing it at the commit
stage as we do today, but we actually want to calculate two sets of valu
Calculate pipe watermarks during atomic calculation phase, based on the
contents of the atomic transaction's state structure.
FIXME: For now we just dump this in a temporary structure and don't do
anything with it except compare it to the values we re-calculate later.
Ultimately we should squash
> -Original Message-
> From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter
> Sent: Wednesday, May 20, 2015 12:37 AM
> To: Konduru, Chandra
> Cc: Daniel Vetter; intel-gfx@lists.freedesktop.org; Vetter, Daniel; Syrjala,
> Ville
> Subject: Re: [Intel-gfx] [PATCH 0
Passive DP->DVI/HDMI dongles show up to the system as HDMI devices, as they
do not have a sink device in them to respond to any AUX traffic. When
probing these dongles over the DDC, sometimes they will NAK the first attempt
even though the transaction is valid and they support the DDC protocol. The
On Tue, May 19, 2015 at 3:53 PM, Peter Zijlstra wrote:
> On Fri, May 15, 2015 at 02:07:29AM +0100, Robert Bragg wrote:
>> On Fri, May 8, 2015 at 5:24 PM, Peter Zijlstra wrote:
>> > On Thu, May 07, 2015 at 03:15:43PM +0100, Robert Bragg wrote:
>> >
>> >> I've changed the uapi for configuring the i
Hi Jim,
I checked the BSpec as well and there's nothing indicating that these
two bits are mutually exclusive. They are both sticky though, and if the
loop times out 5 times, both _DONE and _TIMEOUT may very well be set. In
that case the current code would just exit and never bother to change
On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
> Signed-off-by: Anuj Phogat
> ---
> intel/intel_bufmgr_gem.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/intel/intel_bufmgr_gem.c b/intel/intel_bufmgr_gem.c
> index 51d87ae..92701a5 100644
> --- a/intel/intel_b
On Fri, Apr 10, 2015 at 5:20 PM, Anuj Phogat wrote:
> and use it to initialize the align variable in drm_intel_bo.
>
> In case of YF/YS tiled buffers libdrm need not know about the tiling
> format because these buffers don't have hardware support to be tiled
> or detiled through a fenced region. B
On Wed, May 20, 2015 at 08:38:25PM +, Vivi, Rodrigo wrote:
> On Wed, 2015-05-20 at 20:26 +0300, Ville Syrjälä wrote:
> > On Wed, May 20, 2015 at 09:42:57AM -0700, Rodrigo Vivi wrote:
> > > Broadwell Workaround : Do not enable IPS when the pipe pixel rate is
> > > greater than
> > > 95% of the C
2015-05-20 17:40 GMT-03:00 Rodrigo Vivi :
> I'm convinced Unclaimed regs Paulo saw came from somewhere else since
> I just got it with pm_rpm rte with no patch applied
>
> So I'd suggest to merge this patch... Although it also doesn't fix the
> flicker I see here so the bug would still be open.
I'm convinced Unclaimed regs Paulo saw came from somewhere else since
I just got it with pm_rpm rte with no patch applied
So I'd suggest to merge this patch... Although it also doesn't fix the
flicker I see here so the bug would still be open...
Anyway,
Reviewed-by: Rodrigo Vivi
On Thu, Sep
On Wed, 2015-05-20 at 20:26 +0300, Ville Syrjälä wrote:
> On Wed, May 20, 2015 at 09:42:57AM -0700, Rodrigo Vivi wrote:
> > Broadwell Workaround : Do not enable IPS when the pipe pixel rate is
> > greater than
> > 95% of the CDCLK frequency. The pipe pixel rate is the port pixel rate
> > multiplie
On Wed, May 20, 2015 at 09:42:57AM -0700, Rodrigo Vivi wrote:
> Broadwell Workaround : Do not enable IPS when the pipe pixel rate is
> greater than
> 95% of the CDCLK frequency. The pipe pixel rate is the port pixel rate
> multiplied by the pipe scaler down scale amount.
Or just merge my patch do
> Two things:
> - Can you please boot with drm.debug=0xff and enable full debug output
> to the console with dmesg -n debug and try to recapture? I'd like to
> know what exactly happened right before. There should be lots of debug
> output right before the oops.
There ya go. dmesg with drm.debug=0
On Fri, 15 May 2015 12:39:20 +0300
Ville Syrjälä wrote:
> On Tue, Feb 24, 2015 at 09:52:16PM +0100, Daniel Vetter wrote:
> > On Tue, Feb 24, 2015 at 10:37:10AM -0800, Bob Paauwe wrote:
> > > On Tue, 24 Feb 2015 14:57:48 +0100
> > > Daniel Vetter wrote:
> > > > As Jani points out we already have
On Wed, May 20, 2015 at 6:00 PM, Nicolas Kalkhof wrote:
> Hi Daniel,
>
> ok here is the first oops showing up on the screen. Image is not too good
> though. http://imgur.com/O0kutIE
>
> Btw. did you take a look at the stacktrace I've posted below complaining
> about complaining about pipe state
On Wed, May 20, 2015 at 06:39:26PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 6:00 PM, Nicolas Kalkhof wrote:
> > Hi Daniel,
> >
> > ok here is the first oops showing up on the screen. Image is not too good
> > though. http://imgur.com/O0kutIE
> >
> > Btw. did you take a look at the st
Broadwell Workaround : Do not enable IPS when the pipe pixel rate is
greater than
95% of the CDCLK frequency. The pipe pixel rate is the port pixel rate
multiplied by the pipe scaler down scale amount.
Signed-off-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/intel_display.c | 9 +
drivers/g
On Wed, May 20, 2015 at 06:00:43PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > > This patch series (one patc
From: Maarten Lankhorst
This is a preparation for passing crtc state to the helpers.
When converting all users of crtc->config to use the old or
new state it's easier to find regressions when swap_state is
done first.
If crtc->config is swapped at the same place as swap_state
bugs will never be
From: Maarten Lankhorst
crtc->config is updated to always contain to the active crtc_state
and only differs from crtc_state during crtc_disable. It will
eventually be removed, so start with some low hanging fruit.
For crtc->active the situation is the same; it will be removed
eventually. Instead
From: Maarten Lankhorst
intel_crtc->config will be removed eventually, so use crtc->hwmode.
drm_atomic_helper_update_legacy_modeset_state updates hwmode,
but crtc->active will eventually be gone too. Set dotclock to zero
to indicate the crtc is inactive.
Changes since v1:
- With the hwmode updat
From: Maarten Lankhorst
Repeated calls to begin_crtc_commit can cause warnings like this:
[ 169.127746] BUG: sleeping function called from invalid context at
kernel/locking/mutex.c:616
[ 169.127835] in_atomic(): 0, irqs_disabled(): 1, pid: 1947, name: kms_flip
[ 169.127840] 3 locks held by km
From: Ander Conselvan de Oliveira
Compute new pipe_configs for all crtcs in the atomic state. The commit
part of the mode set (__intel_set_mode()) is already enabled to support
multiple pipes, the only thing missing was calculating a new pipe_config
for every crtc.
Signed-off-by: Maarten Lankhor
From: Maarten Lankhorst
crtc->active will be gone eventually, and this check should be just as good.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/g
From: Ander Conselvan de Oliveira
Now that we can subclass drm_atomic_state we can also use it to keep
track of all the pll settings. atomic_state is a better place to hold
all shared state than keeping pll->new_config everywhere.
Changes since v1:
- Assert connection_mutex is held.
Signed-off-
From: Maarten Lankhorst
And update crtc->config to point to the new state. There is no point
in swapping only part of the state when the rest of the state
should be untouched.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_atomic.c | 44 ++---
1
From: Ander Conselvan de Oliveira
It makes more sense there, since these are computation steps that can
fail.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 70 ++--
1 file changed, 35 insertions(+), 35 deletions(-)
diff --git a/dri
From: Maarten Lankhorst
This is a small behavioral change because it leaves DVO_2X_MODE
set between crtc_disable and crtc_enable. This is probably harmless
though and if not should be fixed by calculating 2x mode before
enable/disable pll.
This is needed because intel_crtc->active will be remove
From: Maarten Lankhorst
This needs to be a global check because at the time of crtc checking
not all modesets have to be calculated yet. Use intel_crtc->atomic
because there's no reason to keep it in state.
Changes since v1:
- Use intel_crtc->atomic as a place to put hsw_workaround_pipe.
- Mak
From: Maarten Lankhorst
Assume the callers lock everything with drm_modeset_lock_all.
This change had to be done after converting suspend/resume to
use atomic_state so the atomic state is preserved, otherwise
all transitional state is erased.
Now all callers of .crtc_enable and .crtc_disable go
From: Ander Conselvan de Oliveira
To make this work we load the new hardware state into the
atomic_state, then swap it with the sw state.
This lets us change the force restore path in setup_hw_state()
to use a single call to intel_mode_set() to restore all the
previous state.
As a nice bonus th
Hi Daniel,
ok here is the first oops showing up on the screen. Image is not too good
though. http://imgur.com/O0kutIE
Btw. did you take a look at the stacktrace I've posted below complaining about
complaining about pipe state doesn't match?
Regards
Nic
Gesendet: Mittwoch, 20. Mai 2015 um 17:3
On Wed, May 20, 2015 at 03:14:06PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> > On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > > This patch series (one patch each for libdrm, the kernel, and beignet)
> > > aims to provide a mea
On Wed, May 20, 2015 at 05:53:42PM +0200, Daniel Vetter wrote:
> On Wed, May 20, 2015 at 02:45:17PM +0100, Damien Lespiau wrote:
> > Right not we don't initialize the stored CDCLK on DDI platforms. Fix
> > that.
> >
> > Signed-off-by: Damien Lespiau
>
> Merged up to this patch, thanks, Daniel
I
On Wed, May 20, 2015 at 02:45:17PM +0100, Damien Lespiau wrote:
> Right not we don't initialize the stored CDCLK on DDI platforms. Fix
> that.
>
> Signed-off-by: Damien Lespiau
Merged up to this patch, thanks, Daniel
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
> 1 file changed, 2 insert
On Wed, May 20, 2015 at 5:05 PM, Nicolas Kalkhof wrote:
> Hallo,
>
> I'm still getting oops with drm-intel-nightly when I try to connect my Laptop
> to its docking station or when I boot up and the Laptop is already connected.
>
> kdump doesn't seem to work with current drm-intel-nightly so I've
On Wed, 20 May 2015 10:36:32 +0200
Daniel Vetter wrote:
> In
>
> commit f02ad907cd9e7fe3a6405d2d005840912f1ed258
> Author: Daniel Vetter
> Date: Thu Jan 22 16:36:23 2015 +0100
>
> drm/atomic-helpers: Recover full cursor plane behaviour
>
> we've added a hack to atomic helpers to never t
On Thu, May 7, 2015 at 12:49 PM, Shobhit Kumar wrote:
> On Wed, May 6, 2015 at 5:44 PM, Thierry Reding
> wrote:
>> On Tue, May 05, 2015 at 03:08:36PM +0530, Shobhit Kumar wrote:
>>> The Crystalcove PMIC controls PWM signals and this driver exports that
>>
>> You say signal_s_ here, but you only
Hallo,
I'm still getting oops with drm-intel-nightly when I try to connect my Laptop
to its docking station or when I boot up and the Laptop is already connected.
kdump doesn't seem to work with current drm-intel-nightly so I've attached an
Image (sorry for the bad quality). http://imgur.com/46
Unfortunately old userspace didn't clear this properly, but since
we've added fb modifiers that's fixed. Checking properly that unused
fields is important for abi extensions, and just right now there's a
bunch of discussions going on about how exactly the additional aux
planes for render compressio
Signed-off-by: Daniel Vetter
---
tests/kms_addfb.c | 67 ++-
1 file changed, 61 insertions(+), 6 deletions(-)
diff --git a/tests/kms_addfb.c b/tests/kms_addfb.c
index 28afdf0a1ea3..42ee63283812 100644
--- a/tests/kms_addfb.c
+++ b/tests/kms_add
On Wed, May 20, 2015 at 02:55:35PM +0100, Damien Lespiau wrote:
> On Wed, May 20, 2015 at 02:12:47PM +0100, Chris Wilson wrote:
> > Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
> > it would be beneficial if the compiler threw an error rather than a
> > warning when it f
On Wed, May 20, 2015 at 9:53 AM, Jani Nikula wrote:
> On Wed, 20 May 2015, Ander Conselvan de Oliveira
> wrote:
>> On Fedora 21 or 22, when the transition from the X server to the wayland
>> compositor is done, the CRTC with the login screen is left active with a
>> disabled fb. A cursor ioctl a
On Wed, May 20, 2015 at 03:09:43PM +0100, Chris Wilson wrote:
> On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> > This patch series (one patch each for libdrm, the kernel, and beignet)
> > aims to provide a means to add a context-specific means to prevent
> > a mapping to GPU vir
On Wed, May 20, 2015 at 04:54:19PM +0300, David Weinehall wrote:
> This patch series (one patch each for libdrm, the kernel, and beignet)
> aims to provide a means to add a context-specific means to prevent
> a mapping to GPU virtual address zero. This is needed at least by
> Beignet (possibly in
Set the I915_CONTEXT_PARAM_NO_ZEROMAP context parameter to disable
zero mappings if libdrm is new enough to expose such functionality.
Signed-off-by: David Weinehall
---
CMakeLists.txt |6 ++
src/CMakeLists.txt |5 +
src/intel/intel_driver.c |4
3 files c
On Wed, May 20, 2015 at 01:19:34PM +0530, Jindal, Sonika wrote:
>
>
> On 5/13/2015 9:57 AM, Jindal, Sonika wrote:
> >
> >
> > On 5/12/2015 6:20 PM, Ville Syrjälä wrote:
> >> On Wed, Apr 15, 2015 at 04:05:19PM +0530, Sonika Jindal wrote:
> >>> Cc: dri-de...@lists.freedesktop.org
> >>> Signed-off-b
Provide helper functions for the context_{get,set}param ioctls,
as well as the I915_CONTEXT_PARAM_NO_ZEROMAP parameter.
Signed-off-by: David Weinehall
---
configure.ac |2 -
include/drm/i915_drm.h |1
intel/intel_bufmgr.h |4 +++
intel/intel_bufmgr_gem.c | 57 +++
Export a new context parameter that can be set/queried through the
context_{get,set}param ioctls. This parameter is passed as a context
flag and decides whether or not a GPU address mapping is allowed to
be made at address zero. The default is to allow such mappings.
Signed-off-by: David Weineha
This patch series (one patch each for libdrm, the kernel, and beignet)
aims to provide a means to add a context-specific means to prevent
a mapping to GPU virtual address zero. This is needed at least by
Beignet (possibly in other use-cases too, though I don't know of any
other) to allow use of ad
On Wed, May 20, 2015 at 02:12:47PM +0100, Chris Wilson wrote:
> Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
> it would be beneficial if the compiler threw an error rather than a
> warning when it found a piece of suspect code. (I use this to
> compile-check patch serie
On Wed, 20 May 2015, Ander Conselvan de Oliveira
wrote:
> On Fedora 21 or 22, when the transition from the X server to the wayland
> compositor is done, the CRTC with the login screen is left active with a
> disabled fb. A cursor ioctl after the transition causes the watermarks
> to be updated, b
Right not we don't initialize the stored CDCLK on DDI platforms. Fix
that.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/intel_ddi.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index d602db2.
Currently bxt_resume_prepare() is only used in the runtime-resume path.
Add it to the full S3/S4 path as well.
v2: Rebase on top of the vlv_resume_prepare() shuffling around
Cc: Imre Deak
Reviewed-by: Imre Deak (v1)
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.c | 7 +--
The macros we use there are the magic ones that can take either dev or
dev_priv. We'd like to move as much as possible towards dev_priv though.
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.c | 9 -
1 file changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/g
I fell into a well crafted trap in the previous series, breaking a resume
ordering constraint for VLV/CHV. Might as well split the series in two then as
we really want the SKL S3 stuff in sooner rather than later.
--
Damien
Damien Lespiau (5):
drm/i915/bxt: Also add bxt_resume_prepare() to the
Couldn't let it go!
Signed-off-by: Damien Lespiau
---
drivers/gpu/drm/i915/i915_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 77f9818..442dd6c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/
We need to re-init the display hardware when going out of suspend. This
includes:
- Hooking the PCH to the reset logic
- Restoring CDCDLK
- Enabling the DDB power
Among those, only the CDCDLK one is a bit tricky. There's some
complexity in that:
- DPLL0 (which is the source for CDCLK) ha
Dave -
My Haswell oopses when power cycling an MST enabled Dell P2415Q display.
I haven't been able to get a picture on screen when either the sink or
the source has MST enabled, but one thing at a time...
Below is the only snippet of dmesg I've been able to squeeze out at this
time, maybe it g
Now that the dpll updates are (mostly) atomic, the .off() code is a noop,
and intel_crtc_disable does mostly the same as intel_modeset_update_state.
Move all logic for connectors_active and setting dpms to that function.
Changes since v1:
- Move drm_atomic_helper_swap_state up.
Changes since v2:
Having a single path for everything makes it a lot easier to keep
crtc_state->active in sync with intel_crtc->active.
A crtc cannot be changed to active when not enabled, because it means
no mode is set and no connectors are connected.
This should also make intel_crtc->active match crtc_state->ac
The primary plane can still be configured when crtc is off,
furthermore this is also a noop now that affected planes are
added on modesets.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_di
From: Ander Conselvan de Oliveira
With the use of drm_atomic_helper_update_legacy_modeset_state the
last user of modeset_crtc is removed from this function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
Now that the pll updates are staged the put_shared_dpll function
consists only of checks that are done in check_shared_dpll_state
after a modeset too.
The changes to pll->config are overwritten by
intel_shared_dpll_commit, so this entire function is a noop.
Signed-off-by: Maarten Lankhorst
---
From: Ander Conselvan de Oliveira
A follow up patch will make intel_modeset_compute_config() deal with
multiple crtcs, so move crtc specific stuff into the lower level crtc
specific function.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 51 ---
Now that the helper is exported there's no need to duplicate
this code any more.
Changes since v1:
- move intel_modeset_update_staged_output_state call to the right place.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 61 +++-
1 file
The goal of this patch series is to implement hardware readout using
atomic state, and restore sw state with a single call to intel_set_mode.
After that's done intel_crtc_control can be safely converted to
atomic modeset, because nothing relies on transitional state any
more.
This patch series sl
crtc_state->enable means a crtc is configured, but it may be turned
off for dpms. Until the commit "use intel_crtc_control everywhere"
crtc_state->active was not updated on crtc off, but now
crtc_state->active should be used for tracking whether a crtc is
scanning out or not.
A few commits from no
This should be much cleaner, with the same effects.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_display.c | 46 ++--
1 file changed, 7 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/int
On Fedora 21 or 22, when the transition from the X server to the wayland
compositor is done, the CRTC with the login screen is left active with a
disabled fb. A cursor ioctl after the transition causes the watermarks
to be updated, but due to the logic in intel_crtc_active() checking for
the primar
On Wed, May 20, 2015 at 02:12:37PM +0100, Chris Wilson wrote:
> When we pin the execlists context on queuing, it the ideal time to map
> the register page that we need to update when we submit the request to
> the hardware (and keep it around for future requests).
>
> This avoids having to do an a
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
When we pin the execlists context on queuing, it the ideal time to map
the register page that we need to update when we submit the request to
the hardware (and keep it around for future requests).
This avoids having to do an atomic kmap on every submission. On the
other hand, it does depend upon c
On Wed, May 20, 2015 at 11:35:28AM +0100, Chris Wilson wrote:
> Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
> it would be beneficial if the compiler threw an error rather than a
> warning when it found a piece of suspect code. (I use this to
> compile-check patch serie
On Mon, May 18, 2015 at 07:19:19PM +, Runyan, Arthur J wrote:
> The statement is correct - " the X offset must always be even for
> YUV422+NV12, and the Y offset must be even when rotated 90/270 degrees."
Hmm. Can you elaborate a bit? I'm curious where this limitation comes
from.
>
> >From:
Fixed variables incorrectly declared as int instead of size_t.
v2: Addressed comments from Tim Gore
v3: Removed 'unused parameter' changes
v4: Changed to size_t
Signed-off-by: Derek Morton
---
lib/igt_core.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/lib/
* Robert Bragg wrote:
> To allow for pmus that may have internal buffering (e.g. the hardware
> itself writes out data to its own circular buffer which is only
> periodically forwarded to userspace via perf) this ioctl enables
> userspace to explicitly ensure it has received all samples before a
On Wed, 20 May 2015, "Gore, Tim" wrote:
>> -Original Message-
>> From: Lespiau, Damien
>> Sent: Wednesday, May 20, 2015 10:48 AM
>> To: Morton, Derek J
>> Cc: Daniel Vetter; Gore, Tim; intel-gfx@lists.freedesktop.org; Wood, Thomas
>> Subject: Re: [Intel-gfx] [PATCH i-g-t] libs/igt_core.c:
Our driver compiles clean (nowadays thanks to 0day) but for me, at least,
it would be beneficial if the compiler threw an error rather than a
warning when it found a piece of suspect code. (I use this to
compile-check patch series and want to break on the first compiler error
in order to fix the pa
> -Original Message-
> From: Lespiau, Damien
> Sent: Wednesday, May 20, 2015 10:48 AM
> To: Morton, Derek J
> Cc: Daniel Vetter; Gore, Tim; intel-gfx@lists.freedesktop.org; Wood, Thomas
> Subject: Re: [Intel-gfx] [PATCH i-g-t] libs/igt_core.c: Fix compile warnings
> in
> igt_core.c
>
>
On Wed, May 20, 2015 at 08:37:56AM +, Morton, Derek J wrote:
>
> >> > -Original Message-
> >> > From: Morton, Derek J
> >> > Sent: Tuesday, May 19, 2015 12:21 PM
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
> >> > Subject: [PATCH i-g-t
On Wed, May 20, 2015 at 08:37:56AM +, Morton, Derek J wrote:
> >> > -Original Message-
> >> > From: Morton, Derek J
> >> > Sent: Tuesday, May 19, 2015 12:21 PM
> >> > To: intel-gfx@lists.freedesktop.org
> >> > Cc: Wood, Thomas; Gore, Tim; Morton, Derek J
> >> > Subject: [PATCH i-g-t] li
On Wed, May 20, 2015 at 01:40:48PM +0530, Sonika Jindal wrote:
> Since DRM_ROTATE is counter clockwise (which is compliant with Xrandr),
> and HW rotation is clockwise, swapping 90/270 to work as expected from
> userspace.
>
> v2: Rebased
>
> Suggested-by: Ville Syrjälä
> Cc: Ville Syrjälä
> Si
On Wed, May 20, 2015 at 10:00:31AM +0100, Derek Morton wrote:
> Fixed variables incorrectly declared as signed instead of unsigned.
Objection. If those array_sizes were larger than INT_MAX we have serious
problems. It would have been cleaner to keep the int (since you cast to
it anyway as the syst
1 - 100 of 116 matches
Mail list logo
