On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This is used when reading Display Control capability Registers on the sink
> device.
>
> cc: Jani Nikula
> cc: dri-de...@lists.freedesktop.org
> Signed-off-by: Yetunde Adebisi
Reviewed-by: Jani Nikula
> ---
> include/drm/drm_dp_helper.h | 1 +
>
Hi Guenter,
On Wed, 30 Mar 2016 15:52:44 -0700
Guenter Roeck wrote:
> On Wed, Mar 30, 2016 at 10:03:31PM +0200, Boris Brezillon wrote:
> > The PWM framework has clarified the concept of reference PWM config
> > (the platform dependent config retrieved from the DT or the PWM
> > lookup table) and
On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd wrote:
> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> > };
> >
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarit
Hi Boris,
On 03/30/2016 10:03 PM, Boris Brezillon wrote:
The PWM framework has clarified the concept of reference PWM config
(the platform dependent config retrieved from the DT or the PWM
lookup table) and real PWM state.
Use pwm_get_args() when the PWM user wants to retrieve this reference
co
Hello Lukas,
The problem with the results in your link is that there is no HSW, ILK, IVB or
SNB results. This might give the impression that everything is well.
Most damning is lack of HSW-gt2 and SNB-dellxps: those machines hang on to
APC, and have run quite stably for every Patchwork run. The
On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
>
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if
On Wed, 30 Mar 2016, Yetunde Adebisi wrote:
> This patch enables support for DPCD backlight control for DP connectors.
> The VESA spec defines DPCD backlight control only for eDP but some add-on
> cards like the Chrontel CH7511B DP-LVDS cards have the display control
> DPCD registers enabled.
> Th
== Series Details ==
Series: legacy gamma code cleanup
URL : https://patchwork.freedesktop.org/series/5037/
State : failure
== Summary ==
Series 5037v1 legacy gamma code cleanup
http://patchwork.freedesktop.org/api/1.0/series/5037/revisions/1/mbox/
Test kms_flip:
Subgroup basic-flip-v
On 31.03.2016 00:35, Lukas Wunner wrote:
Hi Gabriel,
On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote:
This commit causes a hang while running kms suspend tests
(kms_pipe_crc_basic@suspend-read-crc-pipe-*) on ILK/SNB/IVB, affecting CI.
This happened with v1 but not with v2 of
On Wed, 30 Mar 2016 14:55:10 -0700
Stephen Boyd wrote:
> On 03/30, Boris Brezillon wrote:
> > @@ -74,6 +74,23 @@ enum pwm_polarity {
> > PWM_POLARITY_INVERSED,
> > };
> >
> > +/**
> > + * struct pwm_args - PWM arguments
> > + * @period: reference period
> > + * @polarity: reference polarit
== Series Details ==
Series: drm/i915: Unbind objects in shrinker only if device is runtime active
URL : https://patchwork.freedesktop.org/series/5038/
State : failure
== Summary ==
Series 5038v1 drm/i915: Unbind objects in shrinker only if device is runtime
active
http://patchwork.freedeskto
On 03/30, Boris Brezillon wrote:
> diff --git a/drivers/clk/clk-pwm.c b/drivers/clk/clk-pwm.c
> index ebcd738..49ec5b1 100644
> --- a/drivers/clk/clk-pwm.c
> +++ b/drivers/clk/clk-pwm.c
> @@ -28,15 +28,29 @@ static inline struct clk_pwm *to_clk_pwm(struct clk_hw
> *hw)
> static int clk_pwm_prepar
On 03/30, Boris Brezillon wrote:
> @@ -74,6 +74,23 @@ enum pwm_polarity {
> PWM_POLARITY_INVERSED,
> };
>
> +/**
> + * struct pwm_args - PWM arguments
> + * @period: reference period
> + * @polarity: reference polarity
> + *
> + * This structure describe board-dependent arguments attached
On 03/30, Boris Brezillon wrote:
> The PWM framework has clarified the concept of reference PWM config
> (the platform dependent config retrieved from the DT or the PWM
> lookup table) and real PWM state.
>
> Use pwm_get_args() when the PWM user wants to retrieve this reference
> config and not th
On 30/03/2016 at 22:03:49 +0200, Boris Brezillon wrote :
> Implement ->get_state() instead of only initializing the polarity in
> the probe function.
>
> This implementation also takes care of keeping the PWM clk enabled if at
> least one of the PWM exported by the PWM chip is already enabled, whi
If we fail to create the anon file, we need to remember to release the
module reference on the owner.
Signed-off-by: Chris Wilson
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
---
drivers/dma-buf/dma-bu
On Thursday 31 March 2016 12:04 PM, Jani Nikula wrote:
[aggressively trimmed the recipient list, can't seem to be able to send
this otherwise]
On Wed, 30 Mar 2016, Boris Brezillon wrote:
pwm_config/enable/disable() have been deprecated and should be replaced
by pwm_apply_state().
Signed-off-
== Series Details ==
Series: drm/i915: fix deadlock on lid open
URL : https://patchwork.freedesktop.org/series/5025/
State : failure
== Summary ==
Series 5025v1 drm/i915: fix deadlock on lid open
http://patchwork.freedesktop.org/api/1.0/series/5025/revisions/1/mbox/
Test pm_rpm:
Subgr
On Wed, Mar 30, 2016 at 11:51:25AM +0200, Daniel Vetter wrote:
> tegra doesn't have any functions to set gamma tables, so this is
> completely defunct.
>
> Not nice to lie to userspace, so let's stop!
>
> Cc: Thierry Reding
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/tegra/dc.c | 1
On 30/03/16 17:41, Lionel Landwerlin wrote:
On 30/03/16 16:16, Maarten Lankhorst wrote:
Without this a vblank may occur between updating color management
and planes, which should be prevented.
intel_color_set_csc was called in update pipe config because the
handover from hardware may not have a
On 30/03/16 17:41, Lionel Landwerlin wrote:
On 30/03/16 16:16, Maarten Lankhorst wrote:
Without this a vblank may occur between updating color management
and planes, which should be prevented.
intel_color_set_csc was called in update pipe config because the
handover from hardware may not have a
On 24/03/16 12:47, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 12:29:32PM +, Dave Gordon wrote:
On 24/03/16 09:54, Chris Wilson wrote:
On Thu, Mar 24, 2016 at 10:34:58AM +0100, Sedat Dilek wrote:
[ build-script, build and config logs attached ]
Hi Chris,
I am just seeing this (or noticed
This patch sets the invert bit for hpd detection for each port
based on VBT configuration. Since each AOB can be designed to
depend on invert bit or not, it is expected if an AOB requires
invert bit, the user will set respective bit in VBT.
v2: Separated VBT parsing from the rest of the logic. (Ja
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivastava
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_bios.c | 15 ++-
drivers/gpu/drm
== Series Details ==
Series: drm/i915: Add rpm get/put in i915_shrinker_oom
URL : https://patchwork.freedesktop.org/series/5039/
State : failure
== Summary ==
Series 5039v1 drm/i915: Add rpm get/put in i915_shrinker_oom
http://patchwork.freedesktop.org/api/1.0/series/5039/revisions/1/mbox/
Te
On Wednesday 30 March 2016 08:18 PM, Jani Nikula wrote:
On Fri, 25 Mar 2016, Shubhangi Shrivastava
wrote:
This patch adds new fields that are not yet added in drm code
in child devices struct
Signed-off-by: Sivakumar Thulasimani
Signed-off-by: Durgadoss R
Signed-off-by: Shubhangi Shrivast
A fault in a user provided buffer may lead anywhere, and lockdep warns
that we have a potential deadlock between the mm->mmap_sem and the
kernfs file mutex:
[ 82.811702] ==
[ 82.811705] [ INFO: possible circular locking dependency detected ]
It turns out that preserving framebuffers after the rmfb call breaks
vmwgfx userspace. This was originally introduced because it was thought
nobody relied on the behavior, but unfortunately it seems there are
exceptions.
drm_framebuffer_remove may fail with -EINTR now, so a straight revert
is impo
On 29/03/16 12:48, Daniel Vetter wrote:
On Thu, Mar 24, 2016 at 06:40:15PM +, Dave Gordon wrote:
After a suspend-resume cycle, the resumed kernel has no idea what the
booted kernel may have done to the GuC before replacing itself with the
resumed image. In particular, it may have already loa
== Series Details ==
Series: drm/i915: Rename __force_wake_get to __force_wake_auto
URL : https://patchwork.freedesktop.org/series/4864/
State : failure
== Summary ==
Series 4864v1 drm/i915: Rename __force_wake_get to __force_wake_auto
2016-03-30T10:43:14.185826
http://patchwork.freedesktop.o
This seems to be more in-line with what the function actually does, this
also makes it more consistent with i915_gem_obj_to_vma.
Cc: Joonas Lahtinen
Cc: Chris Wilson
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/i915_drv.h | 6 +++---
drivers/gpu/drm/i915/i915_gem.c | 8 --
This almost fixes the problem , but with this:
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 5029f92..a6d3c58 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -123,8 +123,9 @@ static struct intel_fbdev
*int
On Thu, Mar 31, 2016 at 12:46:07PM +0100, Matthew Auld wrote:
> This seems to be more in-line with what the function actually does, this
> also makes it more consistent with i915_gem_obj_to_vma.
All of these functions have been deleted in patches on the list that fix
the bugs in partial vma and fu
On ti, 2016-03-29 at 15:03 +0300, Imre Deak wrote:
> On ke, 2016-03-23 at 04:43 +, Kannan, Vandana wrote:
> > > -Original Message-
> > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com]
> > > Sent: Monday, March 21, 2016 7:34 PM
> > > To: Kannan, Vandana
> > > Cc: intel-gfx@l
== Series Details ==
Series: series starting with [1/5] drm/i915: Splitting intel_dp_detect
URL : https://patchwork.freedesktop.org/series/5044/
State : success
== Summary ==
Series 5044v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5044/revisions/1/mbox/
Test
The current driver exposes only a single adaptor port so that only one
xv video can be played on sprite at a time. This change will allow
available hardware sprites to be used.
v4: re-formatted code, renamed sprite_disable_unlock() to sprite_unlock()
to be clearer. Also moved the sprite lockin
== Series Details ==
Series: series starting with [2/2] drm/i915/BXT: Get pipe conf from the port
registers (rev3)
URL : https://patchwork.freedesktop.org/series/5006/
State : failure
== Summary ==
CC [M] drivers/net/ethernet/intel/igb/e1000_mac.o
CC [M] drivers/net/ethernet/intel/e1000
On Thu, Mar 31, 2016 at 02:08:03PM +0100, Michael Hadley wrote:
> The current driver exposes only a single adaptor port so that only one
> xv video can be played on sprite at a time. This change will allow
> available hardware sprites to be used.
It's a bad change in semantics as you no longer gua
On Wednesday 30 March 2016 04:39 PM, Ander Conselvan De Oliveira wrote:
On Thu, 2016-03-24 at 12:21 +, Shrivastava, Shubhangi wrote:
Hi Daniel,
Is something else required for this patch series (5 patches) to be merged?
It needs to please CI. The errors reported are probably not caused by
== Series Details ==
Series: series starting with [1/2] drm/i915: Add struct_mutex locking for
debugs/i915_gem_framebuffer
URL : https://patchwork.freedesktop.org/series/5053/
State : success
== Summary ==
Series 5053v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/seri
Since the suspend_work is entirely internal to intel_fbdev.c, move it
from the top level drm_i915_private and into struct intel_fbdev. This
requires splitting the internal interface for the suspend worker from
the external interface used by the higher layers to initiate suspend.
Signed-off-by: Chr
If the initialisation fails, we may be left with a dangling pointer with
an incomplete fbdev structure. Here we want to disable internal calls
into fbdev. Similarly, the initialisation may be slow and we haven't yet
enabled the fbdev (e.g. quick suspend or last-close before the async init
completes
Welcome Rob!
On Thu, Mar 31, 2016 at 3:35 PM, Robert Foss wrote:
> Hey,
>
> I'm new to DRM development, but was thinking about getting into the shallow
> side of pool, and doing some DRMJanitors development.
>
> Do you have a preference for a task for me to look at? Is there one that
> would be p
== Series Details ==
Series: series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
URL : https://patchwork.freedesktop.org/series/4790/
State : warning
== Summary ==
Series 4790v5 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/4790/revisions/5/mbox/
On to, 2016-03-31 at 13:44 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2] drm/i915: Rename GGTT init functions (rev5)
> URL : https://patchwork.freedesktop.org/series/4790/
> State : warning
>
> == Summary ==
>
> Series 4790v5 Series without cover letter
>
== Series Details ==
Series: DPCD Backlight Control (rev5)
URL : https://patchwork.freedesktop.org/series/1864/
State : success
== Summary ==
Series 1864v5 DPCD Backlight Control
http://patchwork.freedesktop.org/api/1.0/series/1864/revisions/5/mbox/
bdw-nuci7total:196 pass:184 dwar
== Series Details ==
Series: drm/i915: Protect fbdev across slow or failed initialisation (rev2)
URL : https://patchwork.freedesktop.org/series/5065/
State : failure
== Summary ==
Series 5065v2 drm/i915: Protect fbdev across slow or failed initialisation
http://patchwork.freedesktop.org/api/1.
This should make the code less fragile by synchronizing only up to the
relevant cookie. Otherwise we risk deadlocks particularly during suspend
and resume.
Signed-off-by: Lukas Wunner
---
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/intel_fbdev.c | 14 +-
2 files c
Hi Gabriel,
On Thu, Mar 31, 2016 at 10:42:37AM +0300, Gabriel Feceoru wrote:
> On 31.03.2016 00:35, Lukas Wunner wrote:
> >On Wed, Mar 30, 2016 at 08:20:26PM +0300, Gabriel Feceoru wrote:
> >>This commit causes a hang while running kms suspend tests
> >>(kms_pipe_crc_basic@suspend-read-crc-pipe-*)
On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> Since the suspend_work is entirely internal to intel_fbdev.c, move it
> from the top level drm_i915_private and into struct intel_fbdev. This
> requires splitting the internal interface for the suspend worker from
> the external interface used
On Thu, Mar 31, 2016 at 06:22:01PM +0300, Joonas Lahtinen wrote:
> On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > static void intel_fbdev_suspend_worker(struct work_struct *work)
> > {
> > - intel_fbdev_set_suspend(container_of(work,
> > - struc
On to, 2016-03-31 at 16:30 +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 06:22:01PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > >
> > > static void intel_fbdev_suspend_worker(struct work_struct *work)
> > > {
> > > - intel_fbdev_set_sus
On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> If the initialisation fails, we may be left with a dangling pointer with
> an incomplete fbdev structure. Here we want to disable internal calls
> into fbdev. Similarly, the initialisation may be slow and we haven't yet
> enabled the fbdev (e.
On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > void intel_fbdev_restore_mode(struct drm_device *dev)
> > {
> > - int ret;
> > - struct drm_i915_private *dev_priv = dev->dev_private;
> > - struct intel_fbdev *ifbde
On to, 2016-03-31 at 09:35 +0100, Chris Wilson wrote:
> If we fail to create the anon file, we need to remember to release the
> module reference on the owner.
>
> Signed-off-by: Chris Wilson
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: linux-me...@vger.kernel.org
> Cc: dri-de...@lists.freedesk
On to, 2016-03-31 at 17:13 +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> >
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > >
> > > void intel_fbdev_restore_mode(struct drm_device *dev)
> > > {
> > > - int ret;
> > > - struct drm_i9
Hi Chris,
On Thu, Mar 31, 2016 at 05:13:55PM +0100, Chris Wilson wrote:
> On Thu, Mar 31, 2016 at 07:05:21PM +0300, Joonas Lahtinen wrote:
> > On to, 2016-03-31 at 14:57 +0100, Chris Wilson wrote:
> > > void intel_fbdev_restore_mode(struct drm_device *dev)
> > > {
> > > - int ret;
> > > - struct
== Series Details ==
Series: pwm: add support for atomic update
URL : https://patchwork.freedesktop.org/series/5071/
State : failure
== Summary ==
Series 5071v1 pwm: add support for atomic update
http://patchwork.freedesktop.org/api/1.0/series/5071/revisions/1/mbox/
Test gem_exec_suspend:
== Series Details ==
Series: dma-buf: Release module reference on creation failure
URL : https://patchwork.freedesktop.org/series/5088/
State : failure
== Summary ==
Series 5088v1 dma-buf: Release module reference on creation failure
http://patchwork.freedesktop.org/api/1.0/series/5088/revisio
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.
v2: use wait_for_us instead of the atomic call.
On to, 2016-03-31 at 22:40 +0530, Vandana Kannan wrote:
> According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
> checked to ensure that the register is in accessible state.
> Also, based on a BSpec update, changing the timeout value to
> check iphypwrgood, from 10ms to wait f
> -Original Message-
> From: Deak, Imre
> Sent: Thursday, March 31, 2016 9:45 AM
> To: Kannan, Vandana ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: Re: [PATCH v2] drm/i915: BXT DDI PHY sequence BUN
>
> On to, 2016-03-31 at 22:40 +0530, Vandana Kannan wrote:
> > Acc
dev_priv is what the macro works hard to extract, pass it directly.
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_uncore.c | 2 +-
4 files chang
On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote:
> A fault in a user provided buffer may lead anywhere, and lockdep warns
> that we have a potential deadlock between the mm->mmap_sem and the
> kernfs file mutex:
...
> Reported-by: Ville Syrjälä
> Bugzilla: https://bugs.freedesktop.org
As we have the function with error checking, use it.
Cc: Daniel Vetter
Signed-off-by: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 36
1 file changed, 12 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers
On to, 2016-03-31 at 19:47 +0300, Kannan, Vandana wrote:
> > -Original Message-
> > From: Deak, Imre
> > Sent: Thursday, March 31, 2016 9:45 AM
> > To: Kannan, Vandana ; intel-
> > g...@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: Re: [PATCH v2] drm/i915: BXT DDI PHY sequence BU
== Series Details ==
Series: series starting with [1/2] drm/i915: Update VBT fields for child devices
URL : https://patchwork.freedesktop.org/series/5095/
State : failure
== Summary ==
Series 5095v1 Series without cover letter
http://patchwork.freedesktop.org/api/1.0/series/5095/revisions/1/mb
On Thu, Mar 31, 2016 at 07:49:38PM +0300, Joonas Lahtinen wrote:
> As we have the function with error checking, use it.
However, that error checking turns up in the profiles for some GL
benchmarks. Crazy huh!
Note also that you missed an opportunity in
i915_gem_restore_gtt_mappins()
Please let's
On Thu, Mar 31, 2016 at 07:49:39PM +0300, Joonas Lahtinen wrote:
> dev_priv is what the macro works hard to extract, pass it directly.
=0 haswell:/usr/src/linux (tasklet)$ git grep -e '[A-Z].*(dev_priv->dev)' --
drivers/gpu/drm/i915/
drivers/gpu/drm/i915/i915_debugfs.c:if (!HAS_GUC_UCODE(dev_
According to the BSpec update, bit 7 of PORT_CL1CM_DW0 register needs to be
checked to ensure that the register is in accessible state.
Also, based on a BSpec update, changing the timeout value to
check iphypwrgood, from 10ms to wait for up to 100us.
v2: [Ville] use wait_for_us instead of the atom
On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote:
> On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote:
> >
> > A fault in a user provided buffer may lead anywhere, and lockdep warns
> > that we have a potential deadlock between the mm->mmap_sem and the
> > kernfs file mutex:
> ...
> >
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> Prefix those function as deprecated to encourage all existing users to
> switch to pwm_apply_state().
Why not keep at least some of them as wrappers where we do not need to
chnage several parameters at once? It is much e
Hi Boris,
On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> pwm_config/enable/disable() have been deprecated and should be replaced
> by pwm_apply_state().
>
> Signed-off-by: Boris Brezillon
> ---
> drivers/input/misc/max77693-haptic.c | 23 +--
> 1 file cha
Hi Dmitry,
On Thu, 31 Mar 2016 10:38:58 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:55PM +0200, Boris Brezillon wrote:
> > Prefix those function as deprecated to encourage all existing users to
> > switch to pwm_apply_state().
>
> Why not keep at least some of th
On Thu, 31 Mar 2016 10:48:01 -0700
Dmitry Torokhov wrote:
> Hi Boris,
>
> On Wed, Mar 30, 2016 at 10:03:59PM +0200, Boris Brezillon wrote:
> > pwm_config/enable/disable() have been deprecated and should be replaced
> > by pwm_apply_state().
> >
> > Signed-off-by: Boris Brezillon
> > ---
> > d
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> Add a helper which aids in he identification of DP dual mode (aka.
> DP++)
> adaptors. There are several types of adaptors specified:
> type 1 DVI, type 1 HDMI, type 2 DVI, type 2 HDMI
>
> Type 1
Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> To save a bit of power, let's try to turn off the TMDS output buffers
> in DP++ adaptors when we're not driving the port.
>
> v2: Let's not forget DDI, toss in a debug message while at it
>
> Si
On Thu, Mar 31, 2016 at 08:30:05PM +0300, Joonas Lahtinen wrote:
> On to, 2016-03-31 at 12:49 -0400, Tejun Heo wrote:
> > On Thu, Mar 31, 2016 at 11:45:06AM +0100, Chris Wilson wrote:
> > >
> > > A fault in a user provided buffer may lead anywhere, and lockdep warns
> > > that we have a potential
Hi Tomi,
On Thu, Mar 31, 2016 at 10:21:16AM +0300, Tomi Sarvela wrote:
> The problem with the results in your link is that there is no HSW, ILK, IVB
> or SNB results. This might give the impression that everything is well.
>
> Most damning is lack of HSW-gt2 and SNB-dellxps: those machines hang o
On Thu, Mar 31, 2016 at 07:25:36PM +, Zanoni, Paulo R wrote:
> Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > Add a helper which aids in he identification of DP dual mode (aka.
> > DP++)
> > adaptors. There are several types of ada
On Thu, Mar 31, 2016 at 07:26:25PM +, Zanoni, Paulo R wrote:
> Em Qui, 2016-02-25 às 14:51 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä
> >
> > To save a bit of power, let's try to turn off the TMDS output buffers
> > in DP++ adaptors when we're not driving the por
Currently, our implementation of drm_connector_funcs.detect is
based on getting a valid EDID.
This requirement makes the driver fail to detect connected
connectors in case of EDID corruption, which prevents from falling
back to modes provided by builtin or user-provided EDIDs.
Let's fix this by i
Em Ter, 2016-02-23 às 18:46 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä
>
> DP dual mode type 1 DVI adaptors aren't required to implement any
> registers, so it's a bit hard to detect them. The best way would
> be to check the state of the CONFIG1 pin, but we have no way
This series moves DDB allocation and watermark calculation for SKL-style
platforms to the atomic 'check' phase. This is important for two reasons,
described in more detail below.
1.) It allows us to reject atomic updates that would exceed the watermark
capabilities of the platform.
2.) Avoi
Reorganize the nested structures and unions we have for pipe watermark
data in intel_crtc_state so that platform-specific data can be added in
a more sensible manner (and save a bit of memory at the same time).
The change basically changes the organization from:
union {
st
When we added atomic watermarks, we added a new display vfunc
'compute_pipe_wm' that is used to compute any pipe-specific watermark
information that we can at atomic check time. This was a somewhat poor
naming choice since we already had a 'skl_compute_pipe_wm' function that
doesn't quite fit this
Slightly easier to work with than an array of bools.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 10 +-
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_
We eventually want to calculate watermark values at atomic 'check' time
instead of atomic 'commit' time so that any requested configurations
that result in impossible watermark requirements are properly rejected.
The first step along this path is to allocate the DDB at atomic 'check'
time. As we p
At the moment the CRTC state passed to skl_plane_relative_data_rate() is
always the committed state so intel_crtc->config and cstate are
equivalent. However going forward, we'd like to be able to call this
function on in-flight state objects, so make sure we use the parameter.
Signed-off-by: Matt
In an upcoming patch we'll move this calculation to the atomic 'check'
phase so that the display update can be rejected early if no valid
watermark programming is possible.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_drv.h | 21 +
drivers/gpu/drm/i915/intel_pm.c
Our skl_get_total_relative_data_rate() function gets passed a crtc state
object to calculate the data rate for, but it currently always looks
up the committed plane states that correspond to that CRTC. Let's
check whether the CRTC state is an in-flight state (meaning
cstate->state is non-NULL) and
Calculate the DDB blocks needed to satisfy the current atomic
transaction at atomic check time. This is a prerequisite to calculating
SKL watermarks during the 'check' phase and rejecting any configurations
that we can't find valid watermarks for.
Due to the nature of DDB allocation, it's possibl
If we can't find any valid level 0 watermark values for the requested
atomic transaction, reject the configuration before we try to start
programming the hardware.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
di
We currently only setup intel_state->active_crtcs if we plan to modify
it and write the modification back to dev_priv. Let's ensure that
this value is always valid, even when it isn't changing as part of an
atomic transaction.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c |
Once we move watermark calculation to the atomic check phase, we'll want
to start rejecting display configurations that exceed out watermark
limits. At the moment we just assume that there's always a valid set of
watermarks, even though this may not actually be true. Let's prepare by
passing retu
We calculate the watermark config into intel_atomic_state and then save
it into dev_priv, but never actually use it from there. This is
left-over from some early ILK-style watermark programming designs that
got changed over time.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/i915_drv.h
Moving watermark calculation into the check phase will allow us to to
reject display configurations for which there are no valid watermark
values before we start trying to program the hardware (although those
tests will come in a subsequent patch).
Another advantage of moving this calculation to t
In a future patch we'll want to calculate plane watermarks for in-flight
atomic state rather than the already-committed state.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_pm.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i
Now that we're properly pre-allocating the DDB during the atomic check
phase and we trust that the allocation is appropriate, let's actually
use the allocation computed and not duplicate that work during the
commit phase.
Signed-off-by: Matt Roper
---
drivers/gpu/drm/i915/intel_display.c | 14 +-
From: "Kumar, Mahesh"
Use plane size for relative data rate calculation. don't always use
pipe source width & height.
adjust height & width according to rotation.
use plane size for watermark calculations also.
v2: Address Matt's comments.
Use intel_plane_state->visible to avoid divide-by-ze
1 - 100 of 101 matches
Mail list logo
