== Series Details ==
Series: series starting with [01/33] drm/i915: Add smp_rmb() to busy ioctl's
RCU dance (rev6)
URL : https://patchwork.freedesktop.org/series/10770/
State : failure
== Summary ==
Applying: drm/i915: Add smp_rmb() to busy ioctl's RCU dance
Using index info to reconstruct a
== Series Details ==
Series: more drm doc work (rev2)
URL : https://patchwork.freedesktop.org/series/10844/
State : failure
== Summary ==
Applying: drm/doc: Fix more kerneldoc/sphinx warnings
Applying: drm/doc: Light drm-kms-helper.rst cleanup
Applying: drm/kms-helpers: Extract drm_modeset_hel
== Series Details ==
Series: drm/i915/guc: use symbolic names for module parameter values (rev2)
URL : https://patchwork.freedesktop.org/series/10188/
State : failure
== Summary ==
Series 10188v2 drm/i915/guc: use symbolic names for module parameter values
http://patchwork.freedesktop.org/api/
With commit 4aa7fb9c ("drm/i915/dmc: Step away from symbolic
links") we started loading the firmware version directly
instead of symbolic links.
With this VERSION_REQUIRED variables changed the meaning
from minimal required to exact version required. Along
with this change we started using the lat
On Tue, Aug 9, 2016 at 1:48 AM, Jani Nikula wrote:
> On Tue, 09 Aug 2016, Daniel Klaffenbach wrote:
>> Hi,
>>
>> which one is the correct DMC version to load for Linux 4.8-rc1? The
>> binary blob in linux-firmware.git is v1.26, which is also the latest
>> version available for download at the lin
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Add smp_rmb() to busy ioctl's
RCU dance
URL : https://patchwork.freedesktop.org/series/10828/
State : failure
== Summary ==
Applying: drm/i915: Add smp_rmb() to busy ioctl's RCU dance
Using index info to reconstruct a base t
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Remove unused
i915_gem_active_peek_rcu()
URL : https://patchwork.freedesktop.org/series/10826/
State : failure
== Summary ==
Applying: drm/i915: Remove unused i915_gem_active_peek_rcu()
Using index info to reconstruct a base
On Tue, 2016-08-09 at 23:08 +0100, Chris Wilson wrote:
> On Tue, Aug 09, 2016 at 03:06:10PM -0700, Dhinakaran Pandiyan wrote:
> > No functional change, just adding braces to all branches of conditional
> > statement because one of them already had.
> > ---
> > drivers/gpu/drm/i915/intel_audio.c |
On Tue, Aug 09, 2016 at 03:06:10PM -0700, Dhinakaran Pandiyan wrote:
> No functional change, just adding braces to all branches of conditional
> statement because one of them already had.
> ---
> drivers/gpu/drm/i915/intel_audio.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>
No functional change, just adding braces to all branches of conditional
statement because one of them already had.
---
drivers/gpu/drm/i915/intel_audio.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_audio.c
b/drivers/gpu/drm/i915/intel_audio
DP MST provides the capability to send multiple video and audio streams
through a single port. This requires the API's between i915 and audio
drivers to distinguish between multiple audio capable displays that can be
connected to a port. Currently only the port identity is shared in the
APIs. This
On Tue, Aug 9, 2016 at 9:53 PM, Chris Wilson wrote:
> On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote:
>> Recent versions of gcc say this:
>>
>> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
>> requires 37 bits to represent, but ‘int’ only has 32 bits
>> [-Wshift-overf
On Tue, Aug 09, 2016 at 06:35:10PM +0100, Dave Gordon wrote:
> Recent versions of gcc say this:
>
> include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
> requires 37 bits to represent, but ‘int’ only has 32 bits
> [-Wshift-overflow=]
>
> Reported-by: David Binderman
> Signed-off-by: D
From: Jim Bride
Split the PLL selection code out of the BXT upfront link training
implementation and into a stand-alone function in order to allow
for the implementation of a platform neutral upfront link training
function, and then enable upfront link training for Skylake.
Signed-off-by: Jim Br
Get the PLLs for HSW/BDW using the platform specific function
and add hooks for enabling upfront link training on HSW and BDW.
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_ddi.c | 2 ++
drivers/gpu/drm/i915/intel_dp.c | 4 +++-
2 files changed, 5 insertions(+), 1 deletion(-)
dif
From: Durgadoss R
Split out of bxt_ddi_pll_select() the logic that calculates the pll
dividers and dpll_hw_state into a new function that doesn't depend on
crtc state. This will be used for enabling the port pll when doing
upfront link training.
v2:
* Refactored code so that bxt_clk_div need not
From: Durgadoss R
To support USB type C alternate DP mode, the display driver needs to
know the number of lanes required by the DP panel as well as number
of lanes that can be supported by the type-C cable. Sometimes, the
type-C cable may limit the bandwidth even if Panel can support
more lanes.
From: Ander Conselvan de Oliveira
Split intel_ddi_pre_enable() into encoder type specific versions that
don't depend on crtc_state. The necessary parameters are passed as
function arguments. This split will be necessary for implementing DP
upfront link training.
v2:
* Rebased onto kernel v4.7 (J
From: Ander Conselvan de Oliveira
The value of ddi_pll_sel is derived from the selection of shared dpll,
so just calculate the final value when necessary.
v2: Actually remove it from crtc state and delete remaining usages. (CI)
Reviewed-by: Durgadoss R
Signed-off-by: Ander Conselvan de Oliveir
From: Jim Bride
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code does not directly depend on
crtc state, so that the code can be used for upfront link training.
Signed-off-by: Jim Bride
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 131 ++
Split out the DisplayPort and HDMI pll setup code into separate
functions and refactor the DP code that calculates the pll
so that it doesn't depend on crtc state.
This will be used for acquiring port pll when doing
upfront link training.
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/int
From: Ander Conselvan de Oliveira
Decouple intel_dp_set_link_params() from struct intel_crtc_state. This
will be useful for implementing DP upfront link training.
Reviewed-by: Durgadoss R
Signed-off-by: Ander Conselvan de Oliveira
---
drivers/gpu/drm/i915/intel_ddi.c| 5 -
drivers/g
This patch series enables upfront link training on DDI platforms
(SKL/BDW/HSW/BXT). They are based on some of the patches submitted
earlier by Ander and Durgadoss.
The upfront link training had to be factored out of long pulse
hanlder because of deadlock issues seen on DP MST cases.
Now the upfron
On Tue, Aug 09, 2016 at 11:45:11AM -0700, Carlos Santa wrote:
> No need for HAS_CORE_RING_FREQ as that flag is actually the same as
> .has_llc. Feedback from V. Syrjala.
>
> Signed-off-by: Carlos Santa
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
> drivers/gpu/drm/i915/i915_drv.h | 4
Atm the LVDS encoder depends on the PPS HW context being saved/restored
from generic suspend/resume code. Since the PPS is specific to the LVDS
and eDP encoders a cleaner way is to reinitialize it during encoder
enabling, so do this here for LVDS. Follow-up patches will init the PPS
for the eDP enc
Atm, we apply this workaround somewhat inconsistently at the following
points: driver loading, LVDS init, eDP PPS init, system resume. As this
workaround also affects registers other than PPS (timing, PLL) a more
consistent way is to apply it early after the PPS HW context is known to
be lost: driv
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drive
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drive
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Feedback from V. Syrjala: remove runtime PM support for snb as it breaks
Based on the GEN7_FEATURES changes from Ben W.
Use it for i965g, i965gm, g45 and gm45.
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_pci.c | 36 ++--
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/dri
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
Based on the GEN7_FEATURES changes from Ben w.
Use it for ilk.
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_pci.c | 21 ++---
1 file changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ba0f
- organize most GPU features so that they are easy to group by platforms.
It seems some of the ground work was already done for Gen7 features.
- make most of these GPU features now a device_info flag also based on
previous work done by others. The idea is here is to have a central place
w
Based on the GEN7_FEATURES from Ben W.
Use it for i915g, i915gm, i945g, i945gm, g33 and pnv.
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_pci.c | 30 ++
1 file changed, 14 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/dri
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platform
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
driver
As recommended by Ville Syrjala removing .is_mobile field from the
platform struct definition for vlv and hsw+ GPUs as there's no need to
make the distinction in later hardware anymore. Keep it for older GPUs
as it is still needed for ilk-ivb.
Signed-off-by: Carlos Santa
---
arch/x86/kernel/earl
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++--
driv
Moving all GPU features to the platform definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drive
[patch series] Moving all GPU features to the platform struct definition
allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct definition
Signed-off-by: Carlos Santa
Reviewed-by: Rodrigo Vivi
---
drivers/
Make the .hws_needs_physical the exception by switching the flag
on earlier platforms since they are fewer to support. Remove the flag on
later GPUs hardware since they all use GTT hws by default.
Switch the logic as well in the driver to reflect this change.
Signed-off-by: Carlos Santa
---
dri
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 4 ++-
Based on the GEN7_FEATURES changes from Ben W.
Use it for 830, 845g, i85x, i865g.
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_pci.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers
No need for HAS_CORE_RING_FREQ as that flag is actually the same as
.has_llc. Feedback from V. Syrjala.
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
drivers/gpu/drm/i915/i915_drv.h | 4
2 files changed, 2 insertions(+), 5 deletions(-)
diff --git a/driver
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
Moving all GPU features to the platform struct definition allows for
- standard place when adding new features from new platforms
- possible to see supported features when dumping struct
definitions
Signed-off-by: Carlos Santa
---
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
Based on the GEN7_FEATURES changes from Ben W.
Use it for snb.
Signed-off-by: Carlos Santa
Reviewed-by: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_pci.c | 26 --
1 file changed, 12 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gp
On Tue, Aug 09, 2016 at 02:34:12PM +0300, Imre Deak wrote:
> In the preceeding patches we made sure that:
> - the LVDS encoder takes care of reiniting both the LVDS register
> and its PPS
> - the eDP encoder takes care of reiniting its PPS
> - the PPS register unlocking workaround is applied explic
This patch series had some git format-patch issues due to which
it did not apply cleanly in CI system. So please disregard this patch set.
I will be sending a new patch series for enabling upfront link
training.
Regards
Manasi
On Mon, Aug 08, 2016 at 07:33:09PM -0700, Manasi Navare wrote:
> This
On Tue, Aug 09, 2016 at 02:34:08PM +0300, Imre Deak wrote:
> These two flags mean the same thing, so remove the duplication.
>
> Signed-off-by: Imre Deak
Reviewed-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 -
> drivers/gpu/drm/i915/intel_dp.c | 6 +++---
> drivers/gpu/d
On Tue, Aug 09, 2016 at 08:21:31PM +0300, Imre Deak wrote:
> The PPS registers are pretty much the same everywhere, the differences
> being:
> - Register fields appearing, disappearing from one platform to the
> next: panel-reset-on-powerdown, backlight-on, panel-port,
> register-unlock
> - Dif
On Tue, Aug 09, 2016 at 08:21:33PM +0300, Imre Deak wrote:
> Similarly to the previous patch, initialize the PPS from the DP
> encoder's resume hook. Note that as opposed to LVDS we can't do this
> during encoder enabling, since we need the PPS for DP detection as well.
> The PPS init code is now t
On Tue, Aug 09, 2016 at 08:21:32PM +0300, Imre Deak wrote:
> Atm the LVDS encoder depends on the PPS HW context being saved/restored
> from generic suspend/resume code. Since the PPS is specific to the LVDS
> and eDP encoders a cleaner way is to reinitialize it during encoder
> enabling, so do this
On Tue, Aug 09, 2016 at 08:21:34PM +0300, Imre Deak wrote:
> Atm, we apply this workaround somewhat inconsistently at the following
> points: driver loading, LVDS init, eDP PPS init, system resume. As this
> workaround also affects registers other than PPS (timing, PLL) a more
> consistent way is t
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, but ‘int’ only has 32 bits
[-Wshift-overflow=]
Reported-by: David Binderman
Signed-off-by: Dave Gordon
Cc: Dave Airlie
---
include/drm/i915_drm.h | 2 +-
1 file chang
Atm the LVDS encoder depends on the PPS HW context being saved/restored
from generic suspend/resume code. Since the PPS is specific to the LVDS
and eDP encoders a cleaner way is to reinitialize it during encoder
enabling, so do this here for LVDS. Follow-up patches will init the PPS
for the eDP enc
The PPS registers are pretty much the same everywhere, the differences
being:
- Register fields appearing, disappearing from one platform to the
next: panel-reset-on-powerdown, backlight-on, panel-port,
register-unlock
- Different register base addresses
- Different number of PPS instances: 2 o
Atm, we apply this workaround somewhat inconsistently at the following
points: driver loading, LVDS init, eDP PPS init, system resume. As this
workaround also affects registers other than PPS (timing, PLL) a more
consistent way is to apply it early after the PPS HW context is known to
be lost: driv
Similarly to the previous patch, initialize the PPS from the DP
encoder's resume hook. Note that as opposed to LVDS we can't do this
during encoder enabling, since we need the PPS for DP detection as well.
The PPS init code is now the same for init and resume, so factor out a
new intel_dp_pps_init(
One of the few guarantees we want the busy ioctl to provide is that the
reported busy writer is included in the set of busy read engines. This
should be provided by the ordering of setting and retiring the active
trackers, but we can do better by explicitly setting the busy read
engine flag for the
In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from
idle-worker") the racy detection of missed interrupts was removed when
we went idle. This however opened up the issue that the stuck waiters
were not being reported, causing a test case failure. If we move the
stuck waiter dete
The bottom-half we use for processing the breadcrumb interrupt is a
task, which is an RCU protected struct. When accessing this struct, we
need to be holding the RCU read lock to prevent it disappearing beneath
us. We can use the RCU annotation to mark our irq_seqno_bh pointer as
being under RCU gu
One of the few guarantees we want the busy ioctl to provide is that the
reported busy writer is included in the set of busy read engines. This
should be provided by the ordering of setting and retiring the active
trackers, but we can do better by explicitly setting the busy read
engine flag for the
On Tue, Aug 9, 2016 at 9:41 AM, Daniel Vetter wrote:
> - Move the common vtable stuff to the top
> - Move "Tile Group" to a more appropriate heading level
> - Throw away the old intro for the crtc helpers (it's entirely stale,
> e.g. helpers have become modular years ago), and replace it with a
== Series Details ==
Series: Enable upfront link training on DDI platforms
URL : https://patchwork.freedesktop.org/series/10821/
State : failure
== Summary ==
Applying: drm/i915: Don't pass crtc_state to intel_dp_set_link_params()
Applying: drm/i915: Remove ddi_pll_sel from intel_crtc_state
Ap
On Tue, Aug 09, 2016 at 06:53:16PM +0300, Mika Kuoppala wrote:
> Chris Wilson writes:
>
> > request->batch_obj is only set by execbuffer for the convenience of
> > debugging hangs. By moving that operation to the callsite, we can
> > simplify all other callers and future patches. We also move the
I mistyped and added an extra _request_ to __i915_gem_active_get_rcu()
Also, the same happened to another comment for i915_gem_active_get_rcu()
Reported-by: Mika Kuoppala
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_request.c | 2 +-
drivers/gpu/drm/
On 09/08/16 03:59, Dave Airlie wrote:
On 8 August 2016 at 19:40, Daniel Vetter wrote:
On Mon, Aug 08, 2016 at 10:31:32AM +0100, David Binderman wrote:
Hello there,
Recent versions of gcc say this:
include/drm/i915_drm.h:96:34: warning: result of ‘65535 << 20’
requires 37 bits to represent, b
== Series Details ==
Series: drm/i915: Use connector atomic state in encoders.
URL : https://patchwork.freedesktop.org/series/10853/
State : failure
== Summary ==
Applying: drm/i915: handle DP_MST correctly in bxt_get_dpll
Applying: drm/i915: Pass atomic state to crtc enable/disable functions
Chris Wilson writes:
> request->batch_obj is only set by execbuffer for the convenience of
> debugging hangs. By moving that operation to the callsite, we can
> simplify all other callers and future patches. We also move the
> complications of reference handling of the request->batch_obj next to
On 09/08/16 15:55, Patchwork wrote:
== Series Details ==
Series: Accommodate multiple GuC submission clients
URL : https://patchwork.freedesktop.org/series/10847/
State : failure
== Summary ==
Series 10847v1 Accommodate multiple GuC submission clients
http://patchwork.freedesktop.org/api/1.0
On 09/08/16 12:25, Patchwork wrote:
== Series Details ==
Series: drm/i915/guc: use symbolic names for module parameter values (rev2)
URL : https://patchwork.freedesktop.org/series/10188/
State : warning
== Summary ==
Series 10188v2 drm/i915/guc: use symbolic names for module parameter values
With debugobjects enabled and using SLAB_DESTROY_BY_RCU, when a
kmem_cache_node is destroyed the call_rcu() may trigger a slab
allocation to fill the debug object pool (__debug_object_init:fill_pool).
Everywhere but during kmem_cache_destroy(), discard_slab() is performed
outside of the kmem_cache_
Chris Wilson writes:
> In commit 2529d57050af ("drm/i915: Drop racy markup of missed-irqs from
> idle-worker") the racy detection of missed interrupts was removed when
> we went idle. This however opened up the issue that the stuck waiters
> were not being reported, causing a test case failure. I
== Series Details ==
Series: Picture aspect ratio support in DRM layer
URL : https://patchwork.freedesktop.org/series/10849/
State : success
== Summary ==
Series 10849v1 Picture aspect ratio support in DRM layer
http://patchwork.freedesktop.org/api/1.0/series/10849/revisions/1/mbox
fi-hsw-i7
On ti, 2016-08-09 at 16:01 +0300, Ville Syrjälä wrote:
> On Tue, Aug 09, 2016 at 02:34:11PM +0300, Imre Deak wrote:
> > Atm, we apply this workaround somewhat inconsistently at the following
> > points: driver loading, LVDS init, eDP PPS init, system resume. As this
> > workaround also affects regi
On ti, 2016-08-09 at 15:52 +0300, Ville Syrjälä wrote:
> On Tue, Aug 09, 2016 at 02:34:10PM +0300, Imre Deak wrote:
> > Similarly to the previous patch, initialize the PPS from the DP
> > encoder's resume hook. Note that as opposed to LVDS we can't do this
> > during encoder enabling, since we need
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_drv.h | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1ad2e2c5f580..0e53cc1fd5cc 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/in
On Fri, Aug 05, 2016 at 11:28:26PM +0300, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä
>
> I got annoyed at the pre-g4x gpu reset regression again, so I
> picked up the latest (I think it was the latest anyway) version of
> Maarten's locking fix from the list and rebased it. I also
On Fri, Aug 05, 2016 at 10:22:48PM +0200, Daniel Vetter wrote:
> On Fri, Aug 05, 2016 at 08:00:17PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > Marking PCH transcoder FIFO underrun reporting as disabled for
> > transcoder B/C on LPT-H will block us from enabling th
On Fri, Aug 05, 2016 at 06:49:26PM +0100, Chris Wilson wrote:
> On Fri, Aug 05, 2016 at 08:41:34PM +0300, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä
> >
> > intel_enable_pipe() looks rather confusing when one side doesn't have
> > the curly braces, and the other one does. And wh
This cleans up another possible use of the connector list,
encoder->crtc is legacy state and should not be used.
With the atomic state as argument it's easy to find the encoder from
the connector it belongs to.
intel_opregion_notify_encoder is a noop for !HAS_DDI, so it's harmless
to unconditiona
Some places iterate over connector_state to find the right
connector, pass it along as argument.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 3 ++-
drivers/gpu/drm/i915/intel_ddi.c | 7 ---
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_lvds.c | 22 ++
1 file changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lvds.c
b/drivers/gpu/drm/i915/intel_lvds.c
index bfeec045579e..f5747a901ecc 100644
--- a/drivers/gpu/drm/
This is required for supporting nonblocking modesets. Iterating over
the connector list will no longer be allowed when we don't hold
connection_mutex, so we have to use the atomic state.
Fix disable_noatomic by populating the minimal state required to
disable a connector.
Signed-off-by: Maarten L
crtc_state is already passed around, use it instead of crtc->config.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_color.c | 24 ++--
1 file changed, 14 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_color.c
b/drivers/gpu/drm/i915/i
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_sdvo.c | 27 +++
1 file changed, 11 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_sdvo.c
b/drivers/gpu/drm/i915/intel_sdvo.c
index 7c08d555f35d..74a7c6c9b974 100644
--- a/drivers/gpu
This is mostly code churn, with exception of a few places:
- intel_display.c has changes in intel_sanitize_encoder
- intel_ddi.c has intel_ddi_fdi_disable calling intel_ddi_post_disable,
and required a function change. Also affects intel_display.c
- intel_dp_mst.c passes a NULL crtc_state and con
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_crt.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_crt.c b/drivers/gpu/drm/i915/intel_crt.c
index 8fe36d049d2f..1daf2d9c937e 100644
--- a/drivers/gpu/drm/i915/intel_crt.c
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 48 ++---
1 file changed, 18 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 1fb741a02813..b2f0ef5db64b 100644
-
No idea if it supports it, but this is the minimum required from get_dpll.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dpll_mgr.c | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
b/drivers/gpu/drm/i915/intel
Slightly less straightforward. Some of the drrs calls are done from
workers or from intel_ddi.c, pass along crtc_state when we can,
or crtc->config when we can't.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_ddi.c | 4 +-
drivers/gpu/drm/i915/intel_dp.c | 123 ++
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dsi.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index 1a2e1dcbff1a..8ffa6154e9c6 100644
--- a/drivers/gpu/drm/i915
conn_state is passed as argument now, if anything required conn_state
they can get it without having to look it up.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dp_mst.c | 19 +--
1 file changed, 1 insertion(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i91
This is required for supporting nonblocking modeset and atomic connector
properties.
Connector properties will need the connector state to be passed or it will not
work
as intended.
Nonblocking modesets need to iterate over the atomic state, instead of relying
on
the legacy state fixed up by at
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/intel_dvo.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dvo.c b/drivers/gpu/drm/i915/intel_dvo.c
index 141483fdcf7b..642c5550a1e5 100644
--- a/drivers/gpu/drm/i915/intel_dvo.c
On Tue, Aug 09, 2016 at 05:40:32PM +0300, Imre Deak wrote:
> On ti, 2016-08-09 at 15:48 +0300, Ville Syrjälä wrote:
> > On Tue, Aug 09, 2016 at 02:34:09PM +0300, Imre Deak wrote:
> > > Atm the LVDS encoder depends on the PPS HW context being saved/restored
> > > from generic suspend/resume code. Si
== Series Details ==
Series: Accommodate multiple GuC submission clients
URL : https://patchwork.freedesktop.org/series/10847/
State : failure
== Summary ==
Series 10847v1 Accommodate multiple GuC submission clients
http://patchwork.freedesktop.org/api/1.0/series/10847/revisions/1/mbox
Test d
HDMI 2.0/CEA-861-F introduces two new aspect ratios:
- 64:27
- 256:135
This patch adds enumeration for the new aspect ratios
in the existing aspect ratio list.
V2: rebase
Signed-off-by: Shashank Sharma
Reviewed-by: Sean Paul
Cc: Daniel Vetter
Cc: Emil Velikov
---
drivers/video/hdmi.c | 4 ++
1 - 100 of 208 matches
Mail list logo
