Avoid a global idle barrier by reconfiguring each context by rewriting
them with MI_STORE_DWORD from the kernel context.
v2: We only need to determine the desired register values once, they are
the same for all contexts.
Signed-off-by: Chris Wilson
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Revi
Trust that we now have adequate protection over the low level structures
via the engine->active.lock to allow ourselves to capture the GPU error
state without the heavy hammer of stop_machine(). Sadly this does mean
that we have to forgo some of the lesser used information (not derived
from the act
Modifying a remote context requires careful serialisation with requests
on that context, and that serialisation requires us to take their
timeline->mutex. Make it so.
Note that while struct_mutex rules, we can't create more than one
request in parallel, but that age is soon coming to an end.
v2:
We cannot let the request be retired and freed while we are trying to
dump it during error capture. It is not sufficient just to grab a
reference to the request, as during retirement we may free the ring
which we are also dumping. So take the engine lock to prevent retiring
and freeing of the reque
Convert the list manipulation of active to use spinlocks so that we can
perform the updates from underneath a quick interrupt callback.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c| 13 ++---
drivers/gpu/drm/i
Lift moving the timeline to/from the active_list on enter/exit in order
to shorten the active tracking span in comparison to the existing
pin/unpin.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_pm.c| 1 -
drivers/gpu/drm/i915/gt/intel_context.c | 2 +
drivers
We use timeline->mutex to protect modifications to
context->active_count, and the associated enable/disable callbacks.
Due to complications with engine-pm barrier there is a path where we used
a "superlock" to provide serialised protect and so could not
unconditionally assert with lockdep that it w
In preparation for removing struct_mutex from around context retirement,
we need to make timeline pinning safe. Since multiple engines/contexts
can share a single timeline, it needs to be protected by a mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 27 +++
Forgo the struct_mutex requirement for request retirement as we have
been transitioning over to only using the timeline->mutex for
controlling the lifetime of a request on that timeline.
Signed-off-by: Chris Wilson
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 192 ++
drive
Right idea, wrong lock. We already drop struct_mutex before we free the
mmap_offset when freeing the object, so we need to take the vma manager
lock when manipulating the mmap_offset address space for our selftests.
Fixes: 8221d21b0664 ("drm/i915/selftests: Lock the drm_mm while modifying")
Signed
In the next patch, we would like to couple into the engine wakeref to
free the batch pool on idling. The caveat here is that we therefore want
to track the engine wakeref more precisely and to hold it instead of the
broader GT wakeref as we process the ioctl.
Signed-off-by: Chris Wilson
---
.../
Switch to tracking activity via i915_active on individual nodes, only
keeping a list of retired objects in the cache, and reaping the cache
when the engine itself idles.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/Makefile | 2 +-
.../gpu/drm
Put back the preemption counters lost in commit 22b7a426bbe1
("drm/i915/execlists: Preempt-to-busy") so that our selftests that
assert no preemption took place continue to function.
v2: But a timeslice is only a "soft" preemption!
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Signed
Quoting Tvrtko Ursulin (2019-07-10 07:21:19)
>
> On 09/07/2019 22:09, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-07-09 22:06:17)
> >> From: Tvrtko Ursulin
> >>
> >> fls returns bit positions starting from one for the lsb and the MCR
> >> register expects zero based (sub)slice addressing
On 09/07/2019 22:09, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-07-09 22:06:17)
From: Tvrtko Ursulin
fls returns bit positions starting from one for the lsb and the MCR
register expects zero based (sub)slice addressing.
Incorrent MCR programming can have the effect of directing MMIO re
== Series Details ==
Series: drm/i915/selftests: Hold the vma manager lock while modifying
mmap_offset (rev3)
URL : https://patchwork.freedesktop.org/series/63443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6443_full -> Patchwork_13584_full
== Series Details ==
Series: drm/i915: Lock the engine while dumping the active request (rev2)
URL : https://patchwork.freedesktop.org/series/63442/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6441_full -> Patchwork_13583_full
== Series Details ==
Series: Panel rotation patches (rev7)
URL : https://patchwork.freedesktop.org/series/61870/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
AR drivers/g
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 43 +
include/drm/drm_panel.h | 9
2 files changed, 52 insertions(+)
diff --git a/driv
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connec
This adds the plumbing for reading panel rotation from the devicetree
and sets up adding a panel property for the panel orientation on
Mediatek SoCs when a rotation is present.
v7 changes:
-forgot to add static inline
v6 changes:
-added enum declaration to drm_panel.h header
v5 changes:
-rebased
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function.
== Series Details ==
Series: GT-fy the uc code
URL : https://patchwork.freedesktop.org/series/63460/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6446 -> Patchwork_13594
Summary
---
**FAILURE**
Serious unknown ch
== Series Details ==
Series: drm/i915: Vulkan performance query support (rev8)
URL : https://patchwork.freedesktop.org/series/60916/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6440_full -> Patchwork_13580_full
Summary
--
== Series Details ==
Series: GT-fy the uc code
URL : https://patchwork.freedesktop.org/series/63460/
State : warning
== Summary ==
$ dim sparse origin/drm-tip
Sparse version: v0.5.2
Commit: drm/i915/guc: Remove preemption support for current fw
-./drivers/gpu/drm/i915/i915_scheduler.h:70:23: w
== Series Details ==
Series: GT-fy the uc code
URL : https://patchwork.freedesktop.org/series/63460/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
418baf3690fe drm/i915/guc: Remove preemption support for current fw
caf053260254 drm/i915/guc: simplify guc client
363bd5df02b4 drm
On 7/8/19 2:08 PM, Anusha Srivatsa wrote:
Load GuC for Comet Lake. Depending on the REVID,
we load either the KBL firmware or the CML firmware.
v2: Use CFL for CML platform check.(Michal)
Cc: Michal Wajdeczko
Cc: Daniele Ceraolo Spurio
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i
Get rid of them to avoid more users being added while the guc code
transitions to use gt more than i915.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_guc.c | 8
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 3 ++-
drivers/gpu/drm/
We can get rid of a few more guc_to_i915 and start compartmentalizing
interrupt management a bit more. We should be able to move more code in
the future once the gt_pm code is also moved across to gt.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 2 +
driv
From: Chris Wilson
Preemption via GuC submission is not being supported with its current
legacy incarnation. The current FW does support a similar pre-emption
flow via H2G, but it is class-based instead of being instance-based,
which doesn't fit well with the i915 tracking. To fix this, the
firmw
GuC and HuC are a subunits of the GT HW, so it makes sense for the
relevant structures to be inside intel_gt. This series introduces a new
intel_uc structure under intel_gt and moves the GuC/HuC structures in
there. All the general uc code is then encapsulated, working on intel_uc
instead of i915.
The "misc" terminology doesn't clearly explain what we intend to cover
in this phase. The only thing we do in there apart from FW fetch is
initializing the log workqueue, with the latter being required only in
the very rare case where we enable the log relay. To clean this up, we
can move the wq in
With our HW interface logic moving from i915 to gt and with GuC and HuC
being part of the gt HW, it makes sense to use the intel_gt structure
instead of i915 as our reference object in GuC/HuC paths.
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/intel_gt
No functional change, just moving the guc_to_i915 from the caller into
the irq function. This will help with the upcoming move of guc under
intel_gt.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_irq.c | 40 +---
drivers/gpu/drm/i915/i915_irq.h
The 16-bit guc irq vector is unchanged across gens, the only thing that
moved is its position (from the upper 16 bits of the PM regs to its own
register). Instead of duplicating all defines and functions to handle
the 2 different positions, we can work on the vector and shift it as
appropriate. Whi
Both microcontrollers are part of the GT HW and are closely related to
GT operations. To keep all the files cleanly together, they've been
placed in their own subdir inside the gt/ folder
Signed-off-by: Daniele Ceraolo Spurio
Cc: Michal Wajdeczko
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makef
We originally added support, in some cases partial, for different modes
of operations via guc clients:
- proxy vs direct submission;
- variable engine mask per-client.
We only ever used one flow (all submissions via a single proxy), so the
other code paths haven't been exercised and are most like
Instead of always checking in the device config is GuC and HuC are
supported or not, we can save the state in the uc_fw structure and
avoid going through i915 every time from the low-level uc management
code. while at it FIRMWARE_NONE has been renamed to better indicate that
we haven't started the
Being part of the GT HW, it make sense to keep the guc/huc structures
inside the GT structure. To help with the encapsulation work done by the
following patches, both structures are placed inside a new intel_uc
container. Although this results in code with ugly nested dereferences
(i915->gt.uc.guc.
All the intel_uc_* can now be moved to work on the intel_uc structure
for better encapsulation of uc-related actions.
Note: I've introduced uc_to_gt instead of uc_to_i915 because the aim is
to move everything to be gt-focused in the medium term, so we would've
had to replace it soon anyway.
Signe
== Series Details ==
Series: series starting with [v2] drm/i915/display/tgl: Bump up the mode
vertical limits to support 8K (rev2)
URL : https://patchwork.freedesktop.org/series/63458/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6446 -> Patchwork_13593
=
== Series Details ==
Series: drm/i915: Remove unused i915_gem_context_lookup_engine
URL : https://patchwork.freedesktop.org/series/63437/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6440_full -> Patchwork_13579_full
Summa
On TGL+ we support 8K display resolution, hence bump up the vertical
active limits to 4320 in intel_mode_valid()
v2:
* Checkpatch warning (Manasi)
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +++--
1 file change
On Tue, 2019-07-09 at 14:47 -0700, Manasi Navare wrote:
> On TGL+, the plane height for 8K planes can be 4320, so bump it up
> To support 4320, we need to increase the number of bits used to
> read plane_height to 13 as opposed to older 12 bits.
>
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Si
On Tue, 2019-07-09 at 14:47 -0700, Manasi Navare wrote:
> On TGL+ we support 8K display resolution, hence bump up the vertical
> active limits to 4320 in intel_mode_valid()
>
> Cc: Maarten Lankhorst
> Cc: Ville Syrjälä
> Signed-off-by: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_d
== Series Details ==
Series: Panel rotation patches (rev6)
URL : https://patchwork.freedesktop.org/series/61870/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK include/generated/compile.h
AR drivers/g
Devicetree systems can set panel orientation via a panel binding, but
there's no way, as is, to propagate this setting to the connector,
where the property need to be added.
To address this, this patch sets orientation, as well as other fixed
values for the panel, in the drm_panel_attach function.
This adds the plumbing for reading panel rotation from the devicetree
and sets up adding a panel property for the panel orientation on
Mediatek SoCs when a rotation is present.
v6 changes:
-added enum declaration to drm_panel.h header
v5 changes:
-rebased
v4 changes:
-fixed some changes made to
This inits the panel orientation property for the mediatek dsi driver
if the panel orientation (connector.display_info.panel_orientation) is
not DRM_MODE_PANEL_ORIENTATION_UNKNOWN.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 8
1 file changed, 8 insertions(+)
This adds a helper function for reading the rotation (panel
orientation) from the device tree.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_panel.c | 43 +
include/drm/drm_panel.h | 9
2 files changed, 52 insertions(+)
diff --git a/driv
Not every platform needs quirk detection for panel orientation, so
split the drm_connector_init_panel_orientation_property into two
functions. One for platforms without the need for quirks, and the
other for platforms that need quirks.
Signed-off-by: Derek Basehore
---
drivers/gpu/drm/drm_connec
== Series Details ==
Series: series starting with [1/2] drm/i915/display/tgl: Bump up the mode
vertical limits to support 8K
URL : https://patchwork.freedesktop.org/series/63458/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6446 -> Patchwork_13591
===
== Series Details ==
Series: MCR fixes
URL : https://patchwork.freedesktop.org/series/63457/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6446 -> Patchwork_13590
Summary
---
**SUCCESS**
No regressions found.
E
== Series Details ==
Series: series starting with [1/2] drm/i915/display/tgl: Bump up the mode
vertical limits to support 8K
URL : https://patchwork.freedesktop.org/series/63458/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
90e13413f8fd drm/i915/display/tgl: Bump up the mode
On TGL+ we support 8K display resolution, hence bump up the vertical
active limits to 4320 in intel_mode_valid()
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_display.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
On TGL+, the plane height for 8K planes can be 4320, so bump it up
To support 4320, we need to increase the number of bits used to
read plane_height to 13 as opposed to older 12 bits.
Cc: Maarten Lankhorst
Cc: Ville Syrjälä
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_di
Quoting Tvrtko Ursulin (2019-07-09 22:06:20)
> From: Tvrtko Ursulin
>
> Having fixed the incorect MCR programming in an earlier patch, we can now
> stop ignoring read back of GEN8_L3SQCREG4 during engine workaround
> verification.
>
> Signed-off-by: Tvrtko Ursulin
Our testing is useful for som
Quoting Tvrtko Ursulin (2019-07-09 22:06:19)
> From: Tvrtko Ursulin
>
> It is a more appropriate home for it.
>
> Signed-off-by: Tvrtko Ursulin
> Suggested-by: Chris Wilson
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.
Quoting Tvrtko Ursulin (2019-07-09 22:06:18)
> From: Tvrtko Ursulin
>
> Two issues in this code:
>
> 1.
> fls() usage is incorrect causing off by one in subslice mask lookup,
> which in other words means subslice mask of all zeroes is always used
> (subslice mask of a slice which is not present,
Quoting Tvrtko Ursulin (2019-07-09 22:06:17)
> From: Tvrtko Ursulin
>
> fls returns bit positions starting from one for the lsb and the MCR
> register expects zero based (sub)slice addressing.
>
> Incorrent MCR programming can have the effect of directing MMIO reads of
> registers in the 0xb100-
From: Tvrtko Ursulin
Having fixed the incorect MCR programming in an earlier patch, we can now
stop ignoring read back of GEN8_L3SQCREG4 during engine workaround
verification.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 27 +
1 file chang
From: Tvrtko Ursulin
It is a more appropriate home for it.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 24 ---
drivers/gpu/drm/i915/gt/intel_sseu.c | 24 +++
drivers/gpu/drm/i915/gt/intel
From: Tvrtko Ursulin
Two issues in this code:
1.
fls() usage is incorrect causing off by one in subslice mask lookup,
which in other words means subslice mask of all zeroes is always used
(subslice mask of a slice which is not present, or even out of bounds
array access), rendering the checks in
From: Tvrtko Ursulin
A few bugs in programming the MCR register sneaked in past review.
First of all fls() usage is wrong and suffers from off-by-one problem.
Secondly the assert in WaProgramMgsrForL3BankSpecificMmioReads is also wrong
due inverted logic.
With MCR programming fixed we can stop
From: Tvrtko Ursulin
fls returns bit positions starting from one for the lsb and the MCR
register expects zero based (sub)slice addressing.
Incorrent MCR programming can have the effect of directing MMIO reads of
registers in the 0xb100-0xb3ff range to invalid subslice returning zeroes
instead o
== Series Details ==
Series: drm/i915/execlists: Disable preemption under GVT (rev6)
URL : https://patchwork.freedesktop.org/series/62533/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6438_full -> Patchwork_13578_full
Summ
Quoting Chris Wilson (2019-07-09 10:32:57)
> Quoting Tvrtko Ursulin (2019-07-09 10:31:05)
> > From: Tvrtko Ursulin
> >
> > There are no known plans to start using it either.
> >
> > Signed-off-by: Tvrtko Ursulin
>
> I think I used it in the patch/series and you talked me out of it.
> Reviewed-
Quoting Lionel Landwerlin (2019-07-09 13:33:38)
> drm/i915/perf: ensure we keep a reference on the driver
> drm/i915: enumerate scratch fields
> drm/i915: add infrastructure to hold off preemption on a request
These 3 looked to be standalone, so pushed. Thanks,
-Chris
___
On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> According to the spec when initializing the display in TGL we should
> not
> set PORT_CL_DW12 for the Aux channel of the combo PHYs. We will re-
> use the
> power well hooks from ICL so just check for IS_TIGERLAKE() inside it.
BSpec: 430
== Series Details ==
Series: drm/i915: Enable HDCP 1.4 and 2.2 on Gen12+ (rev2)
URL : https://patchwork.freedesktop.org/series/63432/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6438_full -> Patchwork_13577_full
Summary
-
On Tue, Jul 09, 2019 at 01:07:17AM +, Souza, Jose wrote:
> On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> > From: José Roberto de Souza
> >
> > On TGL the special EDP transcoder is gone and it should be handled by
> > transcoder A.
> >
> > v2 (Lucas):
> > - Reuse POWER_DOMAIN_
On Tue, Jul 09, 2019 at 12:49:21PM -0700, Jose Souza wrote:
FYI
https://patchwork.freedesktop.org/patch/316805/?series=62492&rev=7
Is just waiting CI feedback to get merged and it is doing the same job
as this patch.
But that depends on the enum phy infra. Is that entering now?? This
would me
On 2019-07-09 at 16:26:31 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 14:42:29 +0530
> Ramalingam C wrote:
>
> > On 2019-07-08 at 12:59:59 +0300, Pekka Paalanen wrote:
> > > On Mon, 8 Jul 2019 12:52:17 +0300
> > > Pekka Paalanen wrote:
> > >
> > > > On Fri, 5 Jul 2019 06:16:37 +0530
>
On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> From: Mahesh Kumar
>
> TGL has 3 combophy ports, so extend check for tigerlake in
> intel_port_is_combophy/tc function.
Reviewed-by: José Roberto de Souza
>
> Cc: Mika Kahola
> Signed-off-by: Mahesh Kumar
> Signed-off-by: Lucas De
On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> From: Mahesh Kumar
>
> This patch initializes DDI PORT A, B & C for Tiger lake. Other
> TC ports need to be initialized later once corresponding code is
> there.
Reviewed-by: José Roberto de Souza
>
> Cc: Madhav Chauhan
> Signed-off
FYI
https://patchwork.freedesktop.org/patch/316805/?series=62492&rev=7
Is just waiting CI feedback to get merged and it is doing the same job
as this patch.
On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> From: Mahesh Kumar
>
> In GEN 12 PORT_C DDI clk_off bit is not equally distan
On 2019-07-09 at 17:31:10 +0300, Pekka Paalanen wrote:
> On Mon, 8 Jul 2019 16:51:11 +0530
> Ramalingam C wrote:
>
> > This patch adds a DRM ENUM property to the selected connectors.
> > This property is used for mentioning the protected content's type
> > from userspace to kernel HDCP authentic
== Series Details ==
Series: EHL port programming (rev7)
URL : https://patchwork.freedesktop.org/series/62492/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6444 -> Patchwork_13589
Summary
---
**SUCCESS**
No regre
On Mon, 2019-07-08 at 16:16 -0700, Lucas De Marchi wrote:
> From: Vandita Kulkarni
>
> There are 2 new additional typeC ports in Tiger Lake and PORT-C is
> now a
> combophy port. This results in 6 typeC ports and 3 combophy ports.
> These 6 TC ports can be DP alternate mode, DP over thunderbolt,
== Series Details ==
Series: EHL port programming (rev7)
URL : https://patchwork.freedesktop.org/series/62492/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0cd776d3f169 drm/i915/gen11: Start distinguishing 'phy' from 'port'
97ceed65bf2b drm/i915/gen11: Program ICL_DPCLKA_CFGCR
== Series Details ==
Series: Initial support for Tiger Lake (rev3)
URL : https://patchwork.freedesktop.org/series/62726/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6444 -> Patchwork_13588
Summary
---
**SUCCESS**
Transition the remaining uses of intel_port_is_* over to the equivalent
intel_phy_is_* functions and drop the port functions.
v5: Fix a call in a debug function that's only called when
CONFIG_DRM_I915_DEBUG_RUNTIME_PM is on. (CI)
Cc: José Roberto de Souza
Cc: Lucas De Marchi
Signed-off-by:
Our past DDI-based Intel platforms have had a fixed DDI<->PHY mapping.
Because of this, both the bspec documentation and our i915 code has used
the term "port" when talking about either DDI's or PHY's; it was always
easy to tell what terms like "Port A" were referring to from the
context.
Unfortun
Convert the code that operates directly on gen11 combo PHY's to use the
new namespace. Combo PHY registers are those named "ICL_PORT_*" plus
ICL_DPHY_CHKN.
Note that a lot of the PHY programming happens in the MIPI DSI code.
For clarity I've added a for_each_dsi_phy() to loop over the phys used
b
EHL has four DDI's (DDI-A and DDI-D share combo PHY A).
Cc: José Roberto de Souza
Signed-off-by: Matt Roper
Reviewed-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/dr
Although the register name implies that it operates on DDI's,
DPCLKA_CFGCR0_ICL actually needs to be programmed according to the PHY
that's in use. I.e., when using EHL's DDI-D on combo PHY A, the bits
described as "port A" in the bspec are what we need to set. The bspec
clarifies:
"[For
Final revision which incorporates Jose's minor suggestions (renaming a
register and dropping one #include) and triggers a final CI run. All
patches are reviewed so this should be ready to apply once CI finishes.
Previous series revisions were here:
v4/5: https://lists.freedesktop.org/archives/i
Hi Ville,
now somebody just needs to merge these two 10 bit gamma lut patches
into intel-ddx?
thanks,
-mario
On Fri, May 17, 2019 at 3:51 PM Ville Syrjala
wrote:
>
> From: Ville Syrjälä
>
> Probe the GAMMA_LUT/GAMMA_LUT_SIZE props and utilize them when
> the running with > 8bpc.
>
> v2: s/sna_
== Series Details ==
Series: drm/i915/userptr: Don't mark readonly objects as dirty
URL : https://patchwork.freedesktop.org/series/63434/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6437_full -> Patchwork_13576_full
Summa
== Series Details ==
Series: Initial support for Tiger Lake (rev3)
URL : https://patchwork.freedesktop.org/series/62726/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
5c5e5e6008d1 drm/i915: Add 4th pipe and transcoder
0cd4b6f0f2d1 drm/i915/tgl: add initial Tiger Lake definition
== Series Details ==
Series: drm/i915/execlists: Record preemption counting for selftests (rev2)
URL : https://patchwork.freedesktop.org/series/63452/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6443 -> Patchwork_13587
Su
== Series Details ==
Series: drm/i915: add infrastructure to hold off preemption on a request
URL : https://patchwork.freedesktop.org/series/63451/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6443 -> Patchwork_13586
Summa
On Tue, 2019-07-09 at 12:26 +0300, Timo Aaltonen wrote:
> On 2.7.2019 23.41, Souza, Jose wrote:
> > On Tue, 2019-07-02 at 23:29 +0300, Timo Aaltonen wrote:
> > > On 2.7.2019 22.54, Souza, Jose wrote:
> > > > Here a dmesg output of this patch working in a unpowered type-c
> > > > dongle:
> > > > htt
== Series Details ==
Series: Modular FIA (rev3)
URL : https://patchwork.freedesktop.org/series/63175/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6443 -> Patchwork_13585
Summary
---
**SUCCESS**
No regressions fo
== Series Details ==
Series: drm/i915/selftests: Hold the vma manager lock while modifying
mmap_offset (rev3)
URL : https://patchwork.freedesktop.org/series/63443/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6443 -> Patchwork_13584
==
== Series Details ==
Series: drm/i915: Fix reporting of size of created GEM object
URL : https://patchwork.freedesktop.org/series/63421/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6436_full -> Patchwork_13575_full
Summar
Make the icl function generic so it is based on phy type and can be
applied to tgl as well.
I checked if this could not apply to EHL as well, but unfortunately
there the HPD and DDC/GMBUS pins for DDI C are mapped to TypeC Port 1
even though it doesn't have TC phy.
v2: don't add a separate functi
Put back the preemption counters lost in commit 22b7a426bbe1
("drm/i915/execlists: Preempt-to-busy") so that our selftests that
assert no preemption took place continue to function.
v2: But a timeslice is only a "soft" preemption!
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Signed
Put back the preemption counters lost in commit 22b7a426bbe1
("drm/i915/execlists: Preempt-to-busy") so that our selftests that
assert no preemption took place continue to function.
Fixes: 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mik
1 - 100 of 229 matches
Mail list logo
