Some small improvements to future-proof the initialization around the
register state context.
Lucas De Marchi (3):
drm/i915: Fix __gen125_emit_bb_start() without WA
drm/i915/gt: Document function to decode register state context
drm/i915/gt: Fix platform prefix
ce->wa_bb_page is allocated only for graphics version 12. However
__gen125_emit_bb_start() is used for any graphics version >= 12.50. For
the currently supported platforms this is not an issue, but for future
ones there's a mismatch causing the jump to
`wa_offset + DG2_PREDICATE_RESULT_BB` to be
Different handling for XeHP and later platforms should be using the
xehp prefix, not gen125. Rename them.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 24 +--
drivers/gpu/drm/i915/gt/gen8_engine_cs.h | 12 +-
It's no obviously clear how the encode/decode of the per platform tables
is done. Document it so while adding tables for new platforms people can
be confident they right things is being done.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 24
1
Hi Niranjana,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[cannot apply to drm-intel/for-linux-next drm/drm-next
drm-exynos/exynos-drm-next drm-misc/drm-misc-next linus/master v6.0-rc7
next-20220927]
[If your patch is applied to the wrong git
== Series Details ==
Series: drm/i915: Add HWMON support (rev8)
URL : https://patchwork.freedesktop.org/series/104278/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12185_full -> Patchwork_104278v8_full
Summary
---
== Series Details ==
Series: Fix Guc-Err-Capture sizing warning
URL : https://patchwork.freedesktop.org/series/109276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12202 -> Patchwork_109276v1
Summary
---
== Series Details ==
Series: Improve anti-pre-emption w/a for compute workloads (rev7)
URL : https://patchwork.freedesktop.org/series/100428/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12197_full -> Patchwork_100428v7_full
> From: Alex Williamson
> Sent: Friday, September 30, 2022 2:24 AM
>
> On Thu, 29 Sep 2022 14:49:56 -0300
> Jason Gunthorpe wrote:
>
> > On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > > Hi Kevin,
> > >
> > > This introduced the regression discovered here:
> > >
> > >
>
> From: Jason Gunthorpe
> Sent: Friday, September 30, 2022 1:49 AM
>
> When converting to directly create the vfio_device the mdev driver has to
> put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
> vfio_unregister_group_dev() in the remove.
>
> This was missed for gvt, add
GuC Error capture initialization calculates an estimation
buffer size for worst case scenario of all engines getting
reset. Fix the calculation change from drm_warn to drm_dbg
since its a corner case
Alan Previn (1):
drm/i915/guc: Fix GuC error capture sizing estimation and reporting
During GuC error capture initialization, we estimate the amount of size
we need for the error-capture-region of the shared GuC-log-buffer.
This calculation was incorrect so fix that. Additionally, if the size
was insufficient, don't drm_warn or drm_notice, just drm_debug since
actually running out
== Series Details ==
Series: Move all drivers to a common dma-buf locking convention
URL : https://patchwork.freedesktop.org/series/109205/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12197_full -> Patchwork_109205v1_full
On Wed, Sep 28, 2022 at 08:55:11AM -0700, Radhakrishna Sripada wrote:
From: Matt Roper
The part of the media and blitter engine contexts that we care about for
setting up an initial state on MTL are nearly similar to DG2 (and PVC).
The difference being PRT_BB_STATE being replaced with NOP.
On Fri, Sep 30, 2022 at 12:34:41AM +0200, Andrzej Hajda wrote:
> On 22.09.2022 21:51, Nathan Chancellor wrote:
> > When booting with clang's kernel control flow integrity series [1],
> > there are numerous violations when accessing the files under
> >
On 22.09.2022 21:51, Nathan Chancellor wrote:
When booting with clang's kernel control flow integrity series [1],
there are numerous violations when accessing the files under
/sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0:
$ cd /sys/devices/pci:00/:00:02.0/drm/card0/gt/gt0
On Thu, Sep 29, 2022 at 05:16:58PM +0530, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and HAS_LMEM()
> returns false. However the platform's stolen memory is presented via
> BAR2 (i.e., the BAR we traditionally consider to be the GMADR on IGFX)
> and should be
== Series Details ==
Series: drm/i915/mtl: Add C10 phy support
URL : https://patchwork.freedesktop.org/series/109248/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109248v1
Summary
---
**SUCCESS**
== Series Details ==
Series: drm/i915/gvt: Add missing vfio_unregister_group_dev() call
URL : https://patchwork.freedesktop.org/series/109264/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/109264/revisions/1/mbox/ not
applied
Applying:
== Series Details ==
Series: drm: Analog TV Improvements (rev3)
URL : https://patchwork.freedesktop.org/series/107892/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/107892/revisions/3/mbox/ not
applied
Applying: drm/docs: Remove unused TV
== Series Details ==
Series: drm/i915/mtl: Add C10 phy support
URL : https://patchwork.freedesktop.org/series/109248/
State : warning
== Summary ==
Error: dim checkpatch failed
7a245d0165a3 drm/i915/mtl: Add Support for C10, C20 PHY Message Bus
Traceback (most recent call last):
File
== Series Details ==
Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)
URL : https://patchwork.freedesktop.org/series/108732/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12199 -> Patchwork_108732v3
On Thu, 29 Sep 2022 14:49:56 -0300
Jason Gunthorpe wrote:
> On Thu, Sep 29, 2022 at 10:55:19AM -0600, Alex Williamson wrote:
> > Hi Kevin,
> >
> > This introduced the regression discovered here:
> >
> > https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
> >
> >
== Series Details ==
Series: drm/i915/gvt: fix double-free bug in split_2MB_gtt_entry (rev3)
URL : https://patchwork.freedesktop.org/series/108732/
State : warning
== Summary ==
Error: dim checkpatch failed
4b8a44dfb06a drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
-:54:
== Series Details ==
Series: drm/i915/mtl: enable local stolen memory (rev5)
URL : https://patchwork.freedesktop.org/series/109066/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109066v5
Summary
---
On Thu, Sep 29, 2022 at 06:28:39PM +0100, Matthew Auld wrote:
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
When converting to directly create the vfio_device the mdev driver has to
put a vfio_register_emulated_iommu_dev() in the probe() and a pairing
vfio_unregister_group_dev() in the remove.
This was missed for gvt, add it.
Cc: sta...@vger.kernel.org
Fixes: 978cf586ac35 ("drm/i915/gvt: convert to
== Series Details ==
Series: drm/i915/mtl: enable local stolen memory (rev5)
URL : https://patchwork.freedesktop.org/series/109066/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked separately.
== Series Details ==
Series: drm/i915/mtl: enable local stolen memory (rev5)
URL : https://patchwork.freedesktop.org/series/109066/
State : warning
== Summary ==
Error: dim checkpatch failed
7e639baeef13 drm/i915/mtl: enable local stolen memory
-:230: CHECK:MACRO_ARG_REUSE: Macro argument
On 29/09/2022 17:38, Niranjana Vishwanathapura wrote:
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Support eviction by maintaining a list of evicted persistent vmas
for rebinding during next submission. Ensure the list do not
include persistent vmas that are being purged.
Signed-off-by: Niranjana Vishwanathapura
Signed-off-by: Andi Shyti
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add i915_vma_instance_persistent() to create persistent vmas.
Persistent vmas will use i915_gtt_view to support partial binding.
vma_lookup is tied to segment of the object instead of section
of VA space. Hence, it do not support aliasing.
== Series Details ==
Series: iommu: Remove iova cpu hotplugging flushing (rev2)
URL : https://patchwork.freedesktop.org/series/108880/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_108880v2_full
== Series Details ==
Series: drm/i915/gt: Flush to global observation point before breadcrumb write
(rev2)
URL : https://patchwork.freedesktop.org/series/109133/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12199 -> Patchwork_109133v2
== Series Details ==
Series: drm/i915/mtl: Add C10 support
URL : https://patchwork.freedesktop.org/series/109241/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
Hi Kevin,
This introduced the regression discovered here:
https://lore.kernel.org/all/20220928125650.0a2ea297.alex.william...@redhat.com/
Seems we're not releasing the resources when removing an mdev. This is
a regression, so it needs to be fixed or reverted before the merge
window. Thanks,
On Thu, Sep 29, 2022 at 06:46:34PM +0200, Andi Shyti wrote:
> Hi Nathan,
>
> thanks for this refactoring... looks good even though i would
> have split it in more patches as this is doing quite many things.
Right, sorry about that :/ I initially thought the problem was much
simpler and the diff
On 9/29/2022 01:22, Tvrtko Ursulin wrote:
On 28/09/2022 19:27, John Harrison wrote:
On 9/28/2022 00:19, Tvrtko Ursulin wrote:
On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:
On 9/27/2022 12:45 AM, Tvrtko Ursulin wrote:
On 27/09/2022 07:49, Andrzej Hajda wrote:
On 27.09.2022 01:34,
Hi Nathan,
thanks for this refactoring... looks good even though i would
have split it in more patches as this is doing quite many things.
But I will not be stubborn, I understand that it's not trivial to
have things split. I will give my r-b for now but I will check it
again before applying it
== Series Details ==
Series: drm/i915/gt: Flush to global observation point before breadcrumb write
(rev2)
URL : https://patchwork.freedesktop.org/series/109133/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
On Thu, Sep 29, 2022 at 11:49:30AM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and implement support for bind and unbind of an
object at the specified GPU virtual addresses.
The vm_bind mode is not supported in legacy execbuf2 ioctl.
It will be
The current code to deal with named modes will only set the mode name, and
then it's up to drivers to try to match that name to whatever mode or
configuration they see fit.
The plan is to remove that need and move the named mode handling out of
drivers and into the core, and only rely on modes
The analog TV connector drivers share some atomic_check logic, and the new
TV standard property have created some boilerplate that can be be shared
across drivers too.
Let's create an atomic_check helper for those use cases.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
From: Mateusz Kwiatkowski
The VEC can accept pretty much any relatively reasonable mode, but still
has a bunch of constraints to meet.
Let's create an atomic_check() implementation that will make sure we
don't end up accepting a non-functional mode.
Acked-by: Noralf Trønnes
Signed-off-by:
Now that the core can deal fine with analog TV modes, let's convert the
sun4i TV driver to leverage those new features.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/sun4i/sun4i_tv.c | 148 ++-
drivers/gpu/drm/vc4/vc4_vec.c| 5 +-
2 files changed, 54
Now that we can easily extend the named modes list, let's add a few more
analog TV modes that were used in the wild, and some unit tests to make
sure it works as intended.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 2 +
The drm_tv_create_properties() function will create a bunch of properties,
but it's up to each and every driver using that function to properly reset
the state of these properties leading to inconsistent behaviours.
Let's create a helper that will take care of it.
Reviewed-by: Noralf Trønnes
The framework will get the drm_display_mode from the drm_cmdline_mode it
got by parsing the video command line argument by calling
drm_connector_pick_cmdline_mode().
The heavy lifting will then be done by the drm_mode_create_from_cmdline_mode()
function.
In the case of the named modes though,
Our new tv mode option allows to specify the TV mode from a property.
However, it can still be useful, for example to avoid any boot time
artifact, to set that property directly from the kernel command line.
Let's add some code to allow it, and some unit tests to exercise that code.
From: Mateusz Kwiatkowski
Add support for the following composite output modes (all of them are
somewhat more obscure than the previously defined ones):
- NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
4.43361875 MHz (the PAL subcarrier frequency). Never used for
Now that the core can deal fine with analog TV modes, let's convert the vc4
VEC driver to leverage those new features.
We've added some backward compatibility to support the old TV mode property
and translate it into the new TV norm property. We're also making use of
the new analog TV
As part of the command line parsing rework coming in the next patches,
we'll need to lookup drm_connector_tv_mode values by their name, already
defined in drm_tv_mode_enum_list.
In order to avoid any code duplication, let's do a function that will
perform a lookup of a TV mode name and return its
The analog TV properties created by the drm_mode_create_tv_properties() are
not properly initialised at reset. Let's switch our implementation to call
drm_atomic_helper_connector_tv_reset().
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/vc4/vc4_vec.c | 8 +++-
From: Mateusz Kwiatkowski
PAL-M is a Brazilian analog TV standard that uses a PAL-style chroma
subcarrier at 3.575611[888111] MHz on top of 525-line (480i60) timings.
This commit makes the driver actually use the proper VEC preset for this
mode instead of just changing PAL subcarrier frequency.
The current named mode parsing relies only the mode name, and doesn't allow
to specify any other parameter.
Let's convert that string list to an array of a custom structure that will
hold the name and some additional parameters in the future.
Signed-off-by: Maxime Ripard
---
The current construction of the named mode parsing doesn't allow to extend
it easily. Let's move it to a separate function so we can add more
parameters and modes.
In order for the tests to still pass, some extra checks are needed, so
it's not a 1:1 move.
Signed-off-by: Maxime Ripard
---
We'll need to get the pixel clock to generate proper display modes for
all the current named modes. Let's add it to struct drm_cmdline_mode and
fill it when parsing the named mode.
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/drm_modes.c | 9 ++---
include/drm/drm_connector.h | 7
From: Geert Uytterhoeven
It is fairly common for named video modes to contain dashes (e.g.
"tt-mid" on Atari, "dblntsc-ff" on Amiga). Currently such mode names
are not recognized, as the dash is considered to be a separator between
mode name and bpp.
Fix this by skipping any dashes that are
The TV mode property has been around for a while now to select and get the
current TV mode output on an analog TV connector.
Despite that property name being generic, its content isn't and has been
driver-specific which makes it hard to build any generic behaviour on top
of it, both in kernel and
Multiple drivers (meson, vc4, sun4i) define analog TV 525-lines and
625-lines modes in their drivers.
Since those modes are fairly standard, and that we'll need to use them
in more places in the future, it makes sense to move their definition
into the core framework.
However, analog display
drm_mode_create_tv_properties(), among other things, will create the
"mode" property that stores the analog TV mode that connector is
supposed to output.
However, that property is getting deprecated, so let's rename that
function to mention it's deprecated. We'll introduce a new variant of
that
drm_connector_pick_cmdline_mode() is in charge of finding a proper
drm_display_mode from the definition we got in the video= command line
argument.
Let's add some unit tests to make sure we're not getting any regressions
there.
Signed-off-by: Maxime Ripard
---
Changes in v4:
- Removed MODULE
The drm_create_tv_properties() will create the TV mode property
unconditionally.
However, since we'll gradually phase it out, let's register it only if we
have a list passed as an argument. This will make the transition easier.
Acked-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
Some video= options might have a value that contains a dash. However, the
command line parsing mode considers all dashes as the separator between the
mode and the bpp count.
Let's rework the parsing code a bit to only consider a dash as the bpp
separator if it before a comma, the options
The current tv_mode has driver-specific values that don't allow to
easily share code using it, either at the userspace or kernel level.
Since we're going to introduce a new, generic, property that fit the
same purpose, let's rename this one to legacy_tv_mode to make it
obvious we should move away
The subconnector property was created by drm_mode_create_tv_properties(),
but wasn't exposed to the userspace through the generic
atomic_get/set_property implementation, and wasn't stored in any generic
state structure.
Let's solve this.
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
There is two TV subconnector related properties registered by
drm_mode_create_tv_properties(): subconnector and select subconnector.
While the select subconnector property is stored in the kernel by the
drm_tv_connector_state structure, the subconnector property isn't stored
anywhere.
Worse, the
We currently have two sets of TV properties.
The first one is there to deal with analog TV properties, creating
properties such as the TV mode, subconnectors, saturation, hue and so on.
It's created by calling the drm_mode_create_tv_properties() function.
The second one is there to deal with
As the number of kunit tests in KMS grows further, we start to have
multiple test suites that, for example, need to register a mock DRM
driver to interact with the KMS function they are supposed to test.
Let's add a file meant to provide those kind of helpers to avoid
duplication.
Signed-off-by:
Since we've recently added a ton of tests, the list starts to be a bit
of a mess and creates unneeded conflicts.
Let's order it alphabetically.
Acked-by: Thomas Zimmermann
Reviewed-by: Noralf Trønnes
Signed-off-by: Maxime Ripard
---
drivers/gpu/drm/tests/Makefile | 14 +++---
1 file
That property is not used or exposed by any driver in the kernel. Remove
it from the documentation.
Signed-off-by: Maxime Ripard
---
Changes in v4:
- New patch
---
Documentation/gpu/kms-properties.csv | 1 -
1 file changed, 1 deletion(-)
diff --git a/Documentation/gpu/kms-properties.csv
Hi,
Here's a series aiming at improving the command line named modes support,
and more importantly how we deal with all the analog TV variants.
The named modes support were initially introduced to allow to specify the
analog TV mode to be used.
However, this was causing multiple issues:
*
On 9/29/2022 00:42, Tvrtko Ursulin wrote:
On 29/09/2022 03:18, john.c.harri...@intel.com wrote:
From: John Harrison
Compute workloads are inherently not pre-emptible for long periods on
current hardware. As a workaround for this, the pre-emption timeout
for compute capable engines was
On Thu, Sep 29, 2022 at 04:00:47PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not
Hi Dave and Daniel,
Here goes drm-intel-fixes-2022-09-29:
- Restrict forced preemption to the active context (Chris)
- Restrict perf_limit_reasons to the supported platforms - gen11+ (Ashutosh)
Thanks,
Rodrigo.
The following changes since commit f76349cf41451c5c42a99f18a9163377e4b364ff:
== Series Details ==
Series: drm/i915/mtl: Define engine context layouts
URL : https://patchwork.freedesktop.org/series/109190/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109190v1_full
Summary
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Implement new execbuf3 ioctl (I915_GEM_EXECBUFFER3) which only
works in vm_bind mode. The vm_bind mode only works with
this new execbuf3 ioctl.
The new execbuf3 ioctl will not have any list of objects to validate
bind as all required objects
Hi Dave and Daniel,
this is the PR for drm-misc-fixes for this week.
Best regards
Thomas
drm-misc-fixes-2022-09-29:
Short summary of fixes pull:
* bridge/analogix: Revert earlier suspend fix
* bridge/lt8912b: Fix corrupt display output
The following changes since commit
On Wed, Sep 28, 2022 at 06:54:27PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Each VM creates a root_obj and shares it with all of its private objects
to use it as dma_resv object. This has a performance advantage as it
requires a single dma_resv object
On 9/29/2022 3:40 AM, Tvrtko Ursulin wrote:
On 29/09/2022 10:49, Andrzej Hajda wrote:
On 29.09.2022 10:22, Tvrtko Ursulin wrote:
On 28/09/2022 19:27, John Harrison wrote:
On 9/28/2022 00:19, Tvrtko Ursulin wrote:
On 27/09/2022 22:36, Ceraolo Spurio, Daniele wrote:
On 9/27/2022 12:45 AM,
Hi Dave, Daniel,
A few fixes for the upcoming merge window. Not many but most are pretty
important.
Another rather important one is missing due being too conflicty, but will
arrive via drm-intel-fixes (7738be973fc4 ("drm/i915/gt: Perf_limit_reasons
are only available for Gen11+")).
Regards,
On Thu, Sep 29, 2022 at 11:51:51AM +0100, Matthew Auld wrote:
On 29/09/2022 10:03, Matthew Auld wrote:
On 29/09/2022 06:24, Niranjana Vishwanathapura wrote:
On Wed, Sep 28, 2022 at 06:52:21PM +0100, Matthew Auld wrote:
On 28/09/2022 07:19, Niranjana Vishwanathapura wrote:
Add uapi and
== Series Details ==
Series: drm/i915: Reject excessive dotclocks early (rev2)
URL : https://patchwork.freedesktop.org/series/109141/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109141v2_full
Hi Nirmoy,
> From: Prathap Kumar Valsan
>
> Add flag to pipecontrol instruction to ensure in-flight writes are
> flushed to global observation point. Also split the pipecontrol
> instruction like we have in gen8.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/5886
>
From: Radhakrishna Sripada
C10 phys uses direct mapping internally for voltage and pre-emphasis levels.
Program the levels directly to the fields in the VDR Registers.
Bspec: 65449
Cc: Imre Deak
Cc: Mika Kahola
Cc: Uma Shankar
Signed-off-by: Clint Taylor
Signed-off-by: Radhakrishna Sripada
From: Radhakrishna Sripada
XELPDP has C10 and C20 phys from Synopsys to drive displays. Each phy
has a dedicated PIPE 5.2 Message bus for configuration. This message
bus is used to configure the phy internal registers.
Bspec: 64599, 65100, 65101, 67610, 67636
Cc: Mika Kahola
Cc: Imre Deak
From: Radhakrishna Sripada
Like DG2, we still don't have a proper algorithm that can be used
for calculating PHY settings, but we do have tables of register
values for a handful of the more common link rates. Some support is
better than none, so let's go ahead and add/use these tables when we
From: Radhakrishna Sripada
XELPDP has C10 phys to drive output to the EDP and the native output
from the display engine. Add structures, programming hardware state
readout logic. Port clock calculations are similar to DG2. Use the DG2
formulae to calculate the port clock but use the relevant pll
From: Radhakrishna Sripada
Add sequences for C10 phy enable/disable phy lane reset,
powerdown change sequence and phy lane programming.
Bspec: 64539, 67636, 65451, 65450, 64568
Cc: Imre Deak
Cc: Mika Kahola
Cc: Uma Shankar
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Mika Kahola
PHY programming support for message bus and phy programming.
Updates for HDMI programming and vswing tables.
Radhakrishna Sripada (5):
drm/i915/mtl: Add Support for C10,C20 PHY Message Bus
drm/i915/mtl: Add PLL programming support for C10 phy
drm/i915/mtl: Add support for C10 phy
On Thu, 2022-09-29 at 06:16 -0700, José Roberto de Souza wrote:
> On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> > Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> > bits in PSR_IMR/IIR registers:
> >
> > /*
> > * gen12+ has registers relative to transcoder
On Tue, 2022-09-27 at 14:09 +0300, Jouni Högander wrote:
> Current PSR code is supposed to use TRANSCODER_EDP to force 0 shift for
> bits in PSR_IMR/IIR registers:
>
> /*
> * gen12+ has registers relative to transcoder and one per transcoder
> * using the same bit definition: handle it as
If intel_gvt_dma_map_guest_page failed, it will call
ppgtt_invalidate_spt, which will finally free the spt.
But the caller does not notice that, it will free spt again in error path.
Fix this by only freeing spt in ppgtt_invalidate_spt in good case.
Fixes: b901b252b6cf ("drm/i915/gvt: Add 2M
Hi folks,
We are excited to welcome you in person to the 2022 X.Org Developers
Conference, held in conjunction with WineConf and FOSS XR conference.
The conference will start officially on Tuesday morning, October 4th.
The program is here:
== Series Details ==
Series: drm/i915/mtl: enable local stolen memory (rev4)
URL : https://patchwork.freedesktop.org/series/109066/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12193_full -> Patchwork_109066v4_full
On Thu, 29 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Make glk_load_degamma_lut() more like most everyone else and
> pass in the LUT explicitly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 17 ++---
On Thu, 29 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove a bunch of pointless curly brackets and do
> the s/dev_priv/i915/ while at it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 43 +++---
On Thu, 29 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Get rid of the funny hsw vs. ivb extra indentation level in
> intel_color_init_hooks().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_color.c | 11 +--
> 1 file
On Thu, 29 Sep 2022, Jani Nikula wrote:
> On Thu, 29 Sep 2022, Ville Syrjala wrote:
>> From: Ville Syrjälä
>>
>> intel_color_init() does both device level and crtc level stuff.
>> Split it up accordingly.
>>
>> Signed-off-by: Ville Syrjälä
>> ---
>> drivers/gpu/drm/i915/display/intel_color.c
On Thu, 29 Sep 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> .load_luts() potentially runs from the vblank worker, and is
> under a deadline to complete within the vblank. Thus we can't
> do expesive stuff like talk to the Punit, etc.
>
> To that end get rid of the
1 - 100 of 138 matches
Mail list logo
