Quoting Jani Nikula (2022-02-07 12:48:08)
> On Mon, 07 Feb 2022, Christoph Hellwig wrote:
> > On Mon, Feb 07, 2022 at 08:28:13AM +, Wang, Zhi A wrote:
> >> 1) About having the mmio_table.h, I would like to keep the stuff in a
> >> dedicated header as putting them in intel_gvt.h might needs i91
On Tue, Feb 8, 2022 at 3:52 PM Ville Syrjälä
wrote:
>
> On Tue, Feb 08, 2022 at 03:37:12PM +0800, Hsin-Yi Wang wrote:
> > +int drm_connector_init_panel_orientation_property(
> > + struct drm_connector *connector)
> > +{
> > + struct drm_device *dev = connector->dev;
> > + struct drm_pr
== Series Details ==
Series: series starting with [v7,1/3] gpu: drm: separate panel orientation
property creating and value setting
URL : https://patchwork.freedesktop.org/series/99815/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11199 -> Patchwork_22198
===
drm_dev_register() sets connector->registration_state to
DRM_CONNECTOR_REGISTERED and dev->registered to true. If
drm_connector_set_panel_orientation() is first called after
drm_dev_register(), it will fail several checks and results in following
warning.
Add a function to create panel orientation
Init panel orientation property after connector is initialized. Let the
panel driver decides the orientation value later.
Signed-off-by: Hsin-Yi Wang
Acked-by: Chun-Kuang Hu
---
drivers/gpu/drm/mediatek/mtk_dsi.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/drivers/gpu/drm/mediate
krane, kakadu, and kodama boards have a default panel rotation.
Signed-off-by: Hsin-Yi Wang
Reviewed-by: Enric Balletbo i Serra
Tested-by: Enric Balletbo i Serra
---
arch/arm64/boot/dts/mediatek/mt8183-kukui.dtsi | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/boot/dts/mediatek/
== Series Details ==
Series: drm/i915/guc: Use temporary memory for regset
URL : https://patchwork.freedesktop.org/series/99813/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11199_full -> Patchwork_22197_full
Summary
-
On 07/02/2022 12:44, Jani Nikula wrote:
On Mon, 07 Feb 2022, Tvrtko Ursulin wrote:
On 04/02/2022 16:37, Michael Cheng wrote:
This patch series re-work a few i915 functions to use drm_clflush_virt_range
instead of calling clflush or clflushopt directly. This will prevent errors
when building
On Fri, 04 Feb 2022, Ville Syrjälä wrote:
> On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
>> The DP 2.0 errata completely overhauls the 128b/132b link training, with
>> no provisions for backward compatibility with the original DP 2.0
>> specification.
>>
>> The changes are too int
On 07/02/2022 19:28, Jordan Justen wrote:
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
---
include/uapi/drm/i915_drm.h | 24
1 file changed, 24 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h
Hi,
Commit message please.
Will GuC folks be reviewing this work?
Quick sanity check maybe makes sense, given data is being "sent" to
userspace directly, I am just not sure if it is worth having in
non-debug builds of i915. Though I will agree not having it in
production then largely defea
On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
> >> The DP 2.0 errata completely overhauls the 128b/132b link training, with
> >> no provisions for backward compatibility with
On 08/02/2022 02:07, john.c.harri...@intel.com wrote:
From: John Harrison
A flag query helper was actually writing to the flags word rather than
just reading. Fix that. Also update the function's comment as it was
out of date.
Fixes: 0f7976506de61 ("drm/i915/guc: Rework and simplify locking"
On 03/02/2022 13:32, Arunpravin wrote:
add a test to check the maximum allocation limit
Signed-off-by: Arunpravin
---
.../gpu/drm/selftests/drm_buddy_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_buddy.c| 60 +++
2 files changed, 61 insertions(+)
diff --git a
== Series Details ==
Series: series starting with [v8,1/3] gpu: drm: separate panel orientation
property creating and value setting
URL : https://patchwork.freedesktop.org/series/99828/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
a832dc08d88f gpu: drm: separate panel orienta
On Wed, 2 Feb 2022 at 16:26, Laurent Pinchart
wrote:
>
> Hi Jani,
>
> On Wed, Feb 02, 2022 at 03:15:03PM +0200, Jani Nikula wrote:
> > On Wed, 02 Feb 2022, Laurent Pinchart wrote:
> > > On Wed, Feb 02, 2022 at 02:24:28PM +0530, Kandpal Suraj wrote:
> > >> Changing rcar_du driver to accomadate the
The Qualcomm DisplayPort driver contains traces of the necessary
plumbing to hook up USB HPD, in the form of the dp_hpd module and the
dp_usbpd_cb struct. Use this as basis for implementing the
oob_hotplug_event() callback, by amending the dp_hpd module with the
missing logic.
Overall the solution
In some implementations, such as the Qualcomm platforms, the display
driver has no way to query the current HPD state and as such it's
impossible to distinguish between disconnect and attention events.
Add a parameter to drm_connector_oob_hotplug_event() to pass the HPD
state.
Also push the test
== Series Details ==
Series: series starting with [v8,1/3] gpu: drm: separate panel orientation
property creating and value setting
URL : https://patchwork.freedesktop.org/series/99828/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, eac
On 03/02/2022 13:32, Arunpravin wrote:
- add a test to check the range allocation
- export get_buddy() function in drm_buddy.c
- export drm_prandom_u32_max_state() in lib/drm_random.c
- include helper functions
- include prime number header file
Signed-off-by: Arunpravin
---
drivers/gpu/drm/d
On 03/02/2022 13:32, Arunpravin wrote:
create a mm with one block of each order available, and
try to allocate them all.
Signed-off-by: Arunpravin
Reviewed-by: Matthew Auld
== Series Details ==
Series: series starting with [v8,1/3] gpu: drm: separate panel orientation
property creating and value setting
URL : https://patchwork.freedesktop.org/series/99828/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22199
===
On 03/02/2022 13:32, Arunpravin wrote:
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left.
Signed-off-by: Arunpravin
---
.../gpu/drm/selftests/drm_buddy_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_buddy.c
== Series Details ==
Series: series starting with [1/2] drm: Add HPD state to
drm_connector_oob_hotplug_event()
URL : https://patchwork.freedesktop.org/series/99830/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
74980bd036b7 drm: Add HPD state to drm_connector_oob_hotplug_even
On 07/02/2022 20:11, Michael Cheng wrote:
Use flush_tlb_kernel_range when invoking drm_clflush_virt_range on
arm64 platforms. Using flush_tlb_kernel_range will:
1. Make sure prior page-table updates have been completed
2. Invalidate the TLB
3. Check if the TLB invalidation has been completed
== Series Details ==
Series: series starting with [1/2] drm: Add HPD state to
drm_connector_oob_hotplug_event()
URL : https://patchwork.freedesktop.org/series/99830/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be ch
On 03/02/2022 13:32, Arunpravin wrote:
- add a test to ascertain that the critical functionalities
of the program is working fine
- add a timeout helper function
Signed-off-by: Arunpravin
---
.../gpu/drm/selftests/drm_buddy_selftests.h | 1 +
drivers/gpu/drm/selftests/test-drm_buddy.c
On 03/02/2022 13:32, Arunpravin wrote:
create a pot-sized mm, then allocate one of each possible
order within. This should leave the mm with exactly one
page left. Free the largest block, then whittle down again.
Eventually we will have a fully 50% fragmented mm.
Signed-off-by: Arunpravin
---
On 02/02/2022 16:26, Lucas De Marchi wrote:
On Wed, Feb 02, 2022 at 10:26:46AM +, Tvrtko Ursulin wrote:
On 01/02/2022 17:28, Lucas De Marchi wrote:
On Tue, Feb 01, 2022 at 07:09:14PM +0200, Jani Nikula wrote:
On Tue, 01 Feb 2022, Lucas De Marchi wrote:
On Tue, Feb 01, 2022 at 11:15:31
On 03/02/2022 13:32, Arunpravin wrote:
- move i915 buddy selftests into drm selftests folder
- add Makefile and Kconfig support
- add sanitycheck testcase
Prerequisites
- These series of selftests patches are created on top of
drm buddy series
- Enable kselftests for DRM as a module in .confi
On Mon, Feb 07, 2022 at 08:43:27PM -0800, Bjorn Andersson wrote:
> In some implementations, such as the Qualcomm platforms, the display
> driver has no way to query the current HPD state and as such it's
> impossible to distinguish between disconnect and attention events.
>
> Add a parameter to dr
v1: https://patchwork.freedesktop.org/series/99378/
v2: https://patchwork.freedesktop.org/series/99711/
Main from previous version:
- Rename to iosys-map is already applied
- Rewrite IOSYS_MAP_INIT_OFFSET() and eliminate most of its
users, favoring a offset variable to k
First the simplest ones:
- iosys_map_memset(): when abstracting system and I/O memory,
just like the memcpy() use case, memset() also has dedicated
functions to be called for using IO memory.
- iosys_map_memcpy_from(): we may need to copy data from I/O
Use iosys_map to read fields from the dma_blob so access to IO and
system memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_
Add a variant of shmem_read() that takes a iosys_map pointer rather
than a plain pointer as argument. It's mostly a copy __shmem_rw() but
adapting the api and removing the write support since there's currently
only need to use iosys_map as destination.
Reworking __shmem_rw() to share the implement
Use iosys_map to write the fields system_info.mapping_table[][].
Since we already have the info_map around where needed, just use it
instead of going through guc->ads_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Sig
Add helpers on top of iosys_map_read_field() /
iosys_map_write_field() functions so they always use the right
arguments and make code easier to read.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De M
Now the map is saved during creation, so use it to initialize the
golden context, reading from shmem and writing to either system or IO
memory.
v2: Do not use a map iterator: add an offset to keep track of
destination
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc:
Use the saved ads_map to prepare the golden context. One difference from
the init context is that this function can be called before there is a
gem object (and thus the guc->ads_map) to calculare the size of the
golden context that should be allocated for that object.
So in this case the function
The ADS initialitazion was using 2 passes to calculate the regset sent
to GuC to initialize each engine: the first pass to just have the final
object size and the second to set each register in place in the final
gem object.
However in order to maintain an ordered set of registers to pass to guc,
In certain situations it's useful to be able to write to an
offset of the mapping. Add a dst_offset to iosys_map_memcpy_to().
Cc: Sumit Semwal
Cc: Christian König
Cc: Thomas Zimmermann
Cc: dri-de...@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Lucas De Marchi
Reviewed-
Use iosys_map to write the policies update so access to IO and system
memory is abstracted away.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.
Use iosys_map to write the fields ads.capture_*.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 10 +-
1 file changed, 5 insertions(
Now that the regset list is prepared, convert guc_mmio_reg_state_init()
to use iosys_map to copy the array to the final location and
initialize additional fields in ads.reg_state_list.
v2: Just use an offset instead of temporary iosys_map.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Convert intel_guc_ads_create() and initialization to use iosys_map
rather than plain pointer and save it in the guc struct. This will help
with additional updates to the ads_blob after the
creation/initialization by abstracting the IO vs system memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Dan
Currently guc_mmio_reg_add() relies on having enough memory available in
the array to add a new slot. It uses
`GEM_BUG_ON(count >= regset->size);` to protect going above the
threshold.
In order to allow guc_mmio_reg_add() to handle the memory allocation by
itself, it must return an error in case o
In the other places in this function, guc->ads_map is being protected
from access when it's not yet set. However the last check is actually
about guc->ads_golden_ctxt_size been set before. These checks should
always match as the size is initialized on the first call to
guc_prep_golden_context(), b
Now we have the access to content of GuC ADS either using iosys_map
API or using a temporary buffer. Remove guc->ads_blob as there shouldn't
be updates using the bare pointer anymore.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo
Use iosys_map_memset() to zero the private data as ADS may be either
on system or IO memory.
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c |
Now that all the called functions from __guc_ads_init() are converted to
use ads_map, stop using ads_blob in __guc_ads_init().
Cc: Matt Roper
Cc: Thomas Hellström
Cc: Daniel Vetter
Cc: John Harrison
Cc: Matthew Brost
Cc: Daniele Ceraolo Spurio
Signed-off-by: Lucas De Marchi
---
drivers/gpu
== Series Details ==
Series: series starting with [1/2] drm: Add HPD state to
drm_connector_oob_hotplug_event()
URL : https://patchwork.freedesktop.org/series/99830/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22200
===
This is John/Rodrigo's 2 patches with some minor changes, and I added
2 patches.
"drm/i915/uapi: Add query for hwconfig blob" was changed:
* Rename DRM_I915_QUERY_HWCONFIG_TABLE to DRM_I915_QUERY_HWCONFIG_BLOB
as requested by Joonas.
* Reword commit message
* I added Acked-by to this patc
From: John Harrison
Implement support for fetching the hardware description table from the
GuC. The call is made twice - once without a destination buffer to
query the size and then a second time to fill in the buffer.
Note that the table is only available on ADL-P and later platforms.
Cc: Mich
From: Rodrigo Vivi
The DRM_I915_QUERY_HWCONFIG_BLOB query item returns a blob of data
which it receives from the GuC software. This blob provides some
useful data about the hardware for drivers.
Although the blob is not fully documented at this time, the basic
format is an array of u32 values. T
Also, document DRM_I915_QUERY_HWCONFIG_BLOB with this struct.
Cc: Daniel Vetter
Signed-off-by: Jordan Justen
---
include/uapi/drm/i915_drm.h | 30 ++
1 file changed, 30 insertions(+)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 069d2f
i915_drm.h now defines the format of the returned
DRM_I915_QUERY_HWCONFIG_BLOB query item. Since i915 receives this from
the black box GuC software, it should verify that the data matches
that format before sending it to user-space.
The verification makes a single simple pass through the blob cont
Hello Paul,
On Mon, 2022-02-07 at 16:38 -0500, Lyude Paul wrote:
> As we've unfortunately started to come to expect from PSR on Intel
> platforms, PSR2 selective fetch is not at all ready to be enabled on
> Tigerlake as it results in severe flickering issues - at least on
> this
> ThinkPad X1 Carb
Save the initial HW state snapshot in i915 so that the rest code of GVT-g
can be moved into a dedicated module while it can still get a clean
initial HW state saved at the correct time during the initialization of
i915. The futhrer vGPU created by GVT-g will use this HW state as the
initial HW stat
From: Zhi Wang
To support the new mdev interfaces and the re-factor patches from
Christoph, which moves the GVT-g code into a dedicated module, the GVT-g
initialization path has to be separated into two phases:
a) Early initialization.
The early initialization of GVT requires to be done when lo
The code of saving initial HW state snapshot has been moved into i915.
Let the GVT-g core logic use that snapshot.
Cc: Christoph Hellwig
Cc: Jason Gunthorpe
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Vivi Rodrigo
Cc: Zhenyu Wang
Cc: Zhi Wang
Signed-off-by: Zhi Wang
---
drivers/gpu/drm/i915/g
== Series Details ==
Series: series starting with [v8,1/3] gpu: drm: separate panel orientation
property creating and value setting
URL : https://patchwork.freedesktop.org/series/99828/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11200_full -> Patchwork_22199_full
=
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/99711/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
80cfc4e5862f iosys-map: Add offset to iosys_map_memcpy_to()
2997557ba29b iosys-map: Add a f
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/99711/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
Instead of open-coding the call of the power wells' enable()/disable()
hooks use the corresponding helper functions. This will also ensure that
the power well's cached-enable state is always up-to-date. Luckily the
lack of this updating hasn't been a problem, since the state either
didn't change (i
Commit d5ce34da31456a
("drm/i915: Add state verification for the TypeC port mode")
added a verification to the TypeC AUX power well enable()/disable()
hooks to check if the TypeC port related to this power well is properly
locked. If the disabling happens asynchronously the verification is
skipped,
The POWER_DOMAIN_TRANSCODER() macro depends on the
POWER_DOMAIN_TRANSCODER_A/B .. DSI_A/C enum values to be consecutive,
move POWER_DOMAIN_TRANSCODER_VDSC_PW2 after these to ensure this. The
wrong order didn't cause a problem, since the DSI_A/C domains are in
always-on power wells on all relevant p
Move the power well get/put/enable/disable hooks to the new
intel_display_power_well.c file. The motivation is to reduce the clutter
in intel_display_power.c, keeping the functionality related to power
domains in that file and moving the low-level power well functionality
to intel_display_power_wel
Add a function to call a power well's sync_hw() hook, instead of
open-coding the same, as a step towards making the low-level
power well internals (i915_power_well_ops/desc structs) hidden.
The cached-enable state should be always up-to-date, so update it
whenever sync_hw() is called.
No function
Move intel_display_power_well_is_enabled() to intel_power_well.c, as a step
towards making the low-level power well internals (i915_power_well_ops/desc
structs) hidden.
Eventually the call to this function and in general accessing power
wells directly from elsewhere in the driver should be replace
Move the i915_power_well_regs struct into i915_power_well_ops. Most of
the power wells use the same ops/regs combination, so this saves some
space and also simplifies the platform power domain->power well
definitions.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_power.c| 2
This is v2 of [1] addressing the review comments from Jani, moving the
power well ops/desc struct accessor functions and implementation of the
platform specific power well hooks to a separate file.
[1] https://patchwork.freedesktop.org/series/99476/
Cc: Jani Nikula
Imre Deak (26):
drm/i915: F
Add functions to get a power well's actual- and cached-enabled state,
name, domain mask and refcount, as a step towards making the low-level
power well internals (i915_power_well_ops/desc structs) hidden.
No functional change.
Suggested-by: Jani Nikula
Cc: Jani Nikula
Signed-off-by: Imre Deak
Save some space by grouping the HSW power well descriptor flags along
with other flags in one bitfield.
This change also lets simplifying the definition of power well
descriptors sharing the same flags in an upcoming patch.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c
Move the implementation of platform specific power well hooks to
intel_display_power_well.c, to reduce the clutter in
intel_display_power.c.
No functional change.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_power.c| 1759
.../i915/display/intel_display_p
The for_each_power_well() macros are only used in intel_display_power.c
and intel_display_power_well.c, so unexport them.
Signed-off-by: Imre Deak
---
.../drm/i915/display/intel_display_power.c| 8
.../drm/i915/display/intel_display_power.h| 20 ---
.../i915/dis
The next patch converts the i915_power_well_desc::domain mask from a u64
mask to a bitmap. I didn't find a reasonably simple way to initialize
bitmaps statically, so prepare for the next patch here by converting the
masks to an array of domain enums and initing the masks from these
arrays during mo
Make all power domain names end with the pipe/port instance for
consistency.
No functional changes.
Signed-off-by: Imre Deak
---
drivers/gpu/drm/i915/display/icl_dsi.c| 8 +-
drivers/gpu/drm/i915/display/intel_ddi.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 34 ++
Move the list of platform specific power domain -> power well
definitions to intel_display_power_map.c. While at it group the
platforms' power domain macros with the corresponding power well lists
and keep all the power domain lists in the same order (matching the enum
order).
No functional change
Use the shortest descriptive name for all power wells for simplicity and
to use the same name for the same type of power wells on multiple
platforms.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 254 +-
1 file changed, 127 insertions(+), 127 deleti
To remove the aliasing of the power domain enum values in a follow-up
patch in this patchset (requiring a bigger mask) and allow for defining
additional power domains in the future (at least some upcoming TypeC
changes requires this) convert the u64 i915_power_well_desc::domains
mask to a bitmap.
The DG2 fixed delay duration is always 600usec, so save some space in
the power well descriptors by converting the parameter to a flag. While
at it also use a bitfield for both the always_on and fixed_enable_delay
flag.
This change also lets simplifying the definiton of power wells sharing
the sam
All the port specific AUX/DDI_IO power wells share the same power well
ops struct and flags, so we can save some space and simplify the
definition of these by listing for all such power wells only the params
specific to them (name, domains, power well register index, id). Move
these params to a new
Simplify the definition of DG1 power wells by reusing the identical
RKL DDI/AUX descriptors.
This reorders the DG1 DDI/AUX vs. PW4/5 power wells, but this shouldn't
make a difference (it is the order on RKL and the DDI/AUX power wells
don't have a dependency on PW4/5).
Signed-off-by: Imre Deak
-
Atm the port -> DDI and AUX power domain mapping is specified by relying
on the aliasing of the platform specific intel_display_power_domain enum
values. For instance D12+ platforms refer to the 'D' port and power
domain instances, which doesn't match the bspec terminology, on these
platforms the c
Some power wells - like always-on and skl+/icl+ PW_1 - with the same
name, domain list, flags, ops are used by multiple platforms, so allow
platforms to reuse the descriptors of such power wells.
This change also lets the follow up patches to simplify the DG1/RKL
power well definitions, and remove
The DDI and AUX domain -> power well mappings are identical for a few
platforms/power well instances, reuse the mappings of earlier platforms
for these removing the duplicate mapping of new platforms.
Signed-off-by: Imre Deak
---
.../i915/display/intel_display_power_map.c| 89 +++
The spec calls the ICL TBT AUX power well instances TBT1-4 (similarly to
all later platforms), align the power domain names with the spec.
Signed-off-by: Imre Deak
---
.../gpu/drm/i915/display/intel_display_power.c | 10 +-
.../gpu/drm/i915/display/intel_display_power.h | 4
..
Aliasing the intel_display_power_domain enum values was required because
of the u64 power domain mask size limit. This makes the dmesg/debugfs
printouts of the domain names somewhat unclear, for instance domain
names for port D are shown on D12+ platforms where the corresponding
port is called TC1.
The spec calls the XELPD_D/E ports just D/E, the platform prefix in the
domain names was only needed by the port->domain mapping relying on
matching enum values for the whole port/domain range (and the
corresponding aliasing between the platform specific domain enums).
Since a previous patch we can
Instead of the skip_mask special casing of the ADL-S power well
descriptors, add a power well descriptor list for ADL-S as well reusing
the TGL descriptors, w/o the TC-cold power well. ADL-S doesn't have
TypeC PHYs, so a better way would be having ADL-S specific AUX
descriptors, but I left changing
If we are unlucky and somehow can't allocate enough memory when
splitting blocks, where we temporarily end up with the given block and
its buddy on the respective free list, then we need to ensure we delete
both blocks, and not just the buddy, before potentially freeing them.
v2: rebase on i915_bu
== Series Details ==
Series: drm/i915/guc: Refactor ADS access to use iosys_map (rev2)
URL : https://patchwork.freedesktop.org/series/99711/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22201
Summary
---
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
0d55eb6c8da5 drm/i915/guc: Add fetch of hwconfig table
-:78: WARNING:FILE_PATH_CHANGES: added, moved or delete
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
>> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
>> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
>> >> +
>> >> + if (timeout) {
>> >> + intel_dp_dump_link
== Series Details ==
Series: series starting with [v6,1/3] i915/gvt: Introduce the mmio table to
support VFIO new mdev API
URL : https://patchwork.freedesktop.org/series/99838/
State : failure
== Summary ==
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND o
== Series Details ==
Series: GuC HWCONFIG with documentation (rev2)
URL : https://patchwork.freedesktop.org/series/99787/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11200 -> Patchwork_22202
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915: Refactor the display power domain mappings (rev2)
URL : https://patchwork.freedesktop.org/series/99476/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
fa34bdc13d82 drm/i915: Fix the VDSC_PW2 power domain enum value
69200c39d539 drm/i915: Sa
== Series Details ==
Series: drm/i915: Refactor the display power domain mappings (rev2)
URL : https://patchwork.freedesktop.org/series/99476/
State : warning
== Summary ==
$ dim sparse --fast origin/drm-tip
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
On Tue, Feb 08, 2022 at 02:12:33PM +0200, Jani Nikula wrote:
> On Tue, 08 Feb 2022, Ville Syrjälä wrote:
> > On Tue, Feb 08, 2022 at 11:17:22AM +0200, Jani Nikula wrote:
> >> On Fri, 04 Feb 2022, Ville Syrjälä wrote:
> >> > On Thu, Feb 03, 2022 at 11:03:54AM +0200, Jani Nikula wrote:
> >> >> +
>
1 - 100 of 280 matches
Mail list logo
