> -Original Message-
> From: Srinivas, Vidya
> Sent: Wednesday, May 25, 2022 2:50 PM
> To: Jani Nikula ; Souza, Jose
> ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Syrjala, Ville
>
> Subject: RE: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless
> mode switch
>
>
== Series Details ==
Series: drm/i915/hwconfig: Future-proof platform checks
URL : https://patchwork.freedesktop.org/series/104338/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11696_full -> Patchwork_104338v1_full
Hi Matthew,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-tip/drm-tip]
[also build test WARNING on v5.18 next-20220525]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note
Filed a new issue https://gitlab.freedesktop.org/drm/intel/-/issues/6085
igt@kms_cursor_crc@pipe-a-cursor-256x256-sliding - incomplete - No
warnings/errors
Thanks,
Lakshmi.
-Original Message-
From: Roper, Matthew D
Sent: Tuesday, May 24, 2022 4:56 PM
To:
Filed a new issue https://gitlab.freedesktop.org/drm/intel/-/issues/6086
igt@kms_atomic_transition@modeset-transition-nonblocking-fencing@1x-outputs -
incomplete - No warnings/errors
Thanks,
Lakshmi.
-Original Message-
From: Roper, Matthew D
Sent: Wednesday, May 25, 2022 8:23 AM
To:
== Series Details ==
Series: drm/i915/hwconfig: Report no hwconfig support on ADL-N
URL : https://patchwork.freedesktop.org/series/104270/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11690_full -> Patchwork_104270v1_full
== Series Details ==
Series: drm/i915/tc: Prevent system hang when modesetting disconnected Type-C
ports (rev2)
URL : https://patchwork.freedesktop.org/series/104019/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11701 -> Patchwork_104019v2
On 3/10/2022 16:43, Alan Previn wrote:
Fix our pointer offset usage in error_state_read
when there is no i915_gpu_coredump but buf offset
is non-zero.
Fixes: 0e39037b3165 ("drm/i915: Cache the error string")
This fixes a kernel page fault can happen when
multiple tests are running concurrently
Commit 30e114ef4b16 ("drm/i915/tc: Check for DP-alt, legacy sinks before
taking PHY ownership") defaults any disconnected Type-C ports to TBT-alt
mode which presents a problem (which could most likely result in a system
hang) when userspace forces a modeset on a Type-C port that is wired for
The following patch tries to prevent a system hang when a modeset
is forced by userspace (Weston) on legacy Type-C ports that are
disconnected. This issue was accidentally discovered while trying
to modeset one of the HDMI ports on the TGL based Gigabyte system
Hi Imre,
> On Tue, May 24, 2022 at 11:29:54AM +0300, Kasireddy, Vivek wrote:
> > Hi Imre,
> >
> > > On Fri, May 20, 2022 at 10:28:31AM +0300, Kasireddy, Vivek wrote:
> > > > Hi Imre,
> > > > [...]
> > > > > > > > @@ -131,6 +137,20 @@ int
> > > > > > > >
Hi Matthew,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-tip/drm-tip]
[also build test ERROR on v5.18 next-20220525]
[cannot apply to drm-intel/for-linux-next drm/drm-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when
On Tue, May 24, 2022 at 04:59:06PM -0700, Matt Roper wrote:
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new
== Series Details ==
Series: drm/syncobj: flatten dma_fence_chains on transfer (rev2)
URL : https://patchwork.freedesktop.org/series/100110/
State : failure
== Summary ==
Error: patch
https://patchwork.freedesktop.org/api/1.0/series/100110/revisions/2/mbox/ not
applied
Applying:
On Wed, May 25, 2022 at 12:38:51PM +0200, Christian König wrote:
Am 25.05.22 um 11:35 schrieb Lionel Landwerlin:
On 25/05/2022 12:26, Lionel Landwerlin wrote:
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König
== Series Details ==
Series: drm/i915/hwconfig: Future-proof platform checks
URL : https://patchwork.freedesktop.org/series/104338/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11696_full -> Patchwork_104338v1_full
== Series Details ==
Series: small BAR uapi bits
URL : https://patchwork.freedesktop.org/series/104369/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11700 -> Patchwork_104369v1
Summary
---
**SUCCESS**
No
On Wed, May 25, 2022 at 08:23:19AM -0700, Matt Roper wrote:
> On Wed, May 25, 2022 at 06:41:11AM +, Patchwork wrote:
> > == Series Details ==
> >
> > Series: drm/i915/hwconfig: Future-proof platform checks
> > URL : https://patchwork.freedesktop.org/series/104338/
> > State : failure
> >
>
== Series Details ==
Series: small BAR uapi bits
URL : https://patchwork.freedesktop.org/series/104369/
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: small BAR uapi bits
URL : https://patchwork.freedesktop.org/series/104369/
State : warning
== Summary ==
Error: dim checkpatch failed
66b32284c514 drm/doc: add rfc section for small BAR uapi
-:39: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
On 5/24/2022 16:59, Matt Roper wrote:
PVC also has a hwconfig table. Actually the current expectation is that
all future platforms will have hwconfig, so let's just change the
condition to an IP version check so that we don't need to keep updating
this for each new platform that shows up.
Cc:
Just for CI.
Signed-off-by: Matthew Auld
---
drivers/gpu/drm/i915/gt/intel_region_lmem.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_region_lmem.c
b/drivers/gpu/drm/i915/gt/intel_region_lmem.c
index 6c6f8cbd7321..119e53f5d9b1 100644
---
With the uAPI in place we should now have enough in place to ensure a
working system on small BAR configurations.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem
A non-recoverable context must be used if the user wants proper error
capture on discrete platforms. In the future the kernel may want to blit
the contents of some objects when later doing the capture stage.
Testcase: igt@gem_exec_capture@capture-recoverable-discrete
Signed-off-by: Matthew Auld
Skip capturing any lmem pages that can't be copied using the CPU. This
in now only best effort on platforms that have small BAR.
Testcase: igt@gem-exec-capture@capture-invisible
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc:
If set, force the allocation to be placed in the mappable portion of
I915_MEMORY_CLASS_DEVICE. One big restriction here is that system memory
(i.e I915_MEMORY_CLASS_SYSTEM) must be given as a potential placement for the
object, that way we can always spill the object into system memory if we
can't
On small BAR configurations, when dealing with I915_MEMORY_CLASS_DEVICE
allocations, we assume that by default, all userspace allocations should
be placed in the non-CPU visible portion. Note that dumb buffers are
not included here, since these are not "GPU accelerated" and likely need
CPU
No longer used.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
Cc: Lionel Landwerlin
Cc: Tvrtko Ursulin
Cc: Jon Bloomfield
Cc: Daniel Vetter
Cc: Jordan Justen
Cc: Kenneth Graunke
Cc: Akeem G Abodunrin
---
drivers/gpu/drm/i915/intel_memory_region.c | 4 +---
Vulkan would like to have a rough measure of how much device memory can
in theory be allocated. Also add unallocated_cpu_visible_size to track
the visible portion, in case the device is using small BAR.
Testcase: igt@i915_query@query-regions-unallocated
Testcase:
Userspace wants to know the size of CPU visible portion of device
local-memory, and on small BAR devices the probed_size is no longer
enough. In Vulkan, for example, it would like to know the size in bytes
for CPU visible VkMemoryHeap. We already track the io_size for each
region, so it's just
Add an entry for the new uapi needed for small BAR on DG2+.
v2:
- Some spelling fixes and other small tweaks. (Akeem & Thomas)
- Rework error capture interactions, including no longer needing
NEEDS_CPU_ACCESS for objects marked for capture. (Thomas)
- Add probed_cpu_visible_size.
Test-with: 20220525183702.490989-1-matthew.a...@intel.com
--
2.34.3
== Series Details ==
Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev10)
URL : https://patchwork.freedesktop.org/series/102665/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11698 -> Patchwork_102665v10
Add some basic tests for this new flag.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
tests/i915/gem_create.c | 309 +++-
1 file changed, 308 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_create.c b/tests/i915/gem_create.c
index
Most users shouldn't care about such an interface, but where required,
this should be useful to aid in setting NEEDS_CPU_ACCESS for a given BO.
Underneath we try to smooth over needing to provide an explicit SMEM
region, or if this is SMEM-only, we don't want the kernel to throw an
error.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
tests/i915/i915_query.c | 273 +++-
1 file changed, 272 insertions(+), 1 deletion(-)
diff --git a/tests/i915/i915_query.c b/tests/i915/i915_query.c
index 6b036241..77cbd93e 100644
---
Add some basic sanity checks for this, like checking if this falls
within the probed_size. On older kernels the value reported here should
be zero.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
tests/i915/i915_query.c | 19 ---
1 file changed, 16 insertions(+), 3
For now limit to direct callers.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
lib/i915/gem_create.c | 9 ++---
lib/i915/gem_create.h | 5 +++--
lib/i915/intel_memory_region.c | 2 +-
tests/i915/gem_create.c| 24
--
2.34.3
For now dump into i915_drm_local.h. Once the uapi on the kernel side is
merged, and is part of drm-next, we can sync the kernel headers and
remove this.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
lib/i915/i915_drm_local.h | 21 +
1 file changed, 21 insertions(+)
kms_frontbuffer_tracking@basic falls over if the fb needs to be migrated
from non-mappable device memory, to the mappable part, due to being
temporarily pinned for scanout, when hitting the CPU fault handler,
which just gives us SIGBUS. If the device has a small BAR let's attempt
to use the
We should mark the objects that need to be captured with
NEEDS_CPU_ACCESS to ensure we can capture them if they are allocated in
lmem. We also need to consider that capture only properly works on
non-recoverable context, for discrete platforms. We can now also expect
CPU invisible objects to be
Will be useful later.
Signed-off-by: Matthew Auld
Cc: Thomas Hellström
---
lib/i915/intel_memory_region.c | 2 ++
lib/i915/intel_memory_region.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/lib/i915/intel_memory_region.c b/lib/i915/intel_memory_region.c
index da81650d..2dd4c156 100644
On Wed, May 25, 2022 at 02:30:55PM +0300, Jani Nikula wrote:
> On Tue, 03 May 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > No idea why the DG2 PLL DP link frequency calculation is allowing
> > a non-exact match. That makes no sense so get rid of it.
>
> Cc: Matt.
>
> This also
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
On Wed, May 25, 2022 at 05:03:13PM +0100, Tvrtko Ursulin wrote:
>
> On 24/05/2022 18:51, Matt Roper wrote:
> > On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
> > > From: Tvrtko Ursulin
> > >
> > > Catch and log any garbage in the register, including no tiles marked, or
> > >
On 24/05/2022 18:51, Matt Roper wrote:
On Tue, May 24, 2022 at 10:43:39AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Catch and log any garbage in the register, including no tiles marked, or
multiple tiles marked.
Signed-off-by: Tvrtko Ursulin
Cc: Matt Roper
---
We caught garbage
On Wed, May 25, 2022 at 06:41:11AM +, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915/hwconfig: Future-proof platform checks
> URL : https://patchwork.freedesktop.org/series/104338/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_11696_full ->
On Wed, May 18, 2022 at 01:12:33PM +0300, Jani Nikula wrote:
> On Wed, 18 May 2022, Hans de Goede wrote:
> > Hi,
> >
> > On 5/18/22 10:44, Jani Nikula wrote:
> >> On Tue, 17 May 2022, Hans de Goede wrote:
> >>> Hi All,
> >>>
> >>> As mentioned in my RFC titled "drm/kms: control display
On Mon, May 16, 2022 at 04:56:13PM -0600, Jim Cromie wrote:
> DRM.debug API is 23 macros, issuing 10 exclusive categories of debug
> messages. By rough count, they are used 5140 times in the kernel.
> These all call drm_dbg or drm_devdbg, which call drm_debug_enabled(),
> which checks bits in
On Wed, May 25, 2022 at 01:34:01PM +0530, Ankit Nautiyal wrote:
> From: Vandita Kulkarni
>
> This patch adds a fix to support 297MHz of dot clock by calculating
> the pll values using synopsis algorithm.
> This will help to support 4k@30 mode for HDMI monitors on DG2.
>
> v2: As per the
== Series Details ==
Series: drm/i915/dg2: Support 4k@30 on HDMI (rev3)
URL : https://patchwork.freedesktop.org/series/103862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11698_full -> Patchwork_103862v3_full
Summary
== Series Details ==
Series: drm/i915: Individualize fences before adding to dma_resv obj (rev5)
URL : https://patchwork.freedesktop.org/series/104074/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11698 -> Patchwork_104074v5
== Series Details ==
Series: drm/i915: Media freq factor and per-gt enhancements/fixes (rev10)
URL : https://patchwork.freedesktop.org/series/102665/
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: Media freq factor and per-gt enhancements/fixes (rev10)
URL : https://patchwork.freedesktop.org/series/102665/
State : warning
== Summary ==
Error: dim checkpatch failed
64b997bebbd8 drm/i915/gt: Add media freq factor to per-gt sysfs
3f974c2ce37c
From: Dale B Stimson
Retrieve RP0 and RPn freq for media IP from PCODE and display in per-gt
sysfs. This patch adds the following files to gt/gtN sysfs:
* media_RP0_freq_mhz
* media_RPn_freq_mhz
v2: Fixed commit author (Rodrigo)
v3: Convert to new uncore interface for pcode functions
v4: Adapt
Expose new sysfs to program and retrieve media freq factor. Factor values
of 0 (dynamic), 0.5 and 1.0 are supported via a u8.8 fixed point
representation (corresponding to integer values of 0, 128 and 256
respectively).
Media freq factor is converted to media_ratio_mode for GuC. It is
programmed
All kmalloc'd kobjects need a kobject_put() to free memory. For example in
previous code, kobj_gt_release() never gets called. The requirement of
kobject_put() now results in a slightly different code organization.
v2: s/gtn/gt/ (Andi)
Fixes: b770bcfae9ad ("drm/i915/gt: create per-tile sysfs
Extend pcode initialization to pcode on different gt's.
Cc: Tvrtko Ursulin
Cc: Jani Nikula
Signed-off-by: Ashutosh Dixit
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 20 ++--
1 file changed, 18 insertions(+), 2 deletions(-)
diff --git
Some recent Intel dGfx platforms allow media IP to work at a different
frequency from the base GT. This patch series exposes sysfs controls for
this functionality in the new per-gt sysfs. Some enhancements and fixes to
previous per-gt functionality are also included to complete the new
On Mon, 23 May 2022 01:57:51 -0700, Tvrtko Ursulin wrote:
>
> On 13/05/2022 02:36, Ashutosh Dixit wrote:
> > Some recent Intel dGfx platforms allow media IP to work at a different
> > frequency from the base GT. This patch series exposes sysfs controls for
> > this functionality in the new per-gt
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No idea why the DG2 PLL DP link frequency calculation is allowing
> a non-exact match. That makes no sense so get rid of it.
Cc: Matt.
This also makes the hdmi link rate check in the same function redundant.
Reviewed-by: Jani
On Wed, May 25, 2022 at 01:53:38PM +0300, Jani Nikula wrote:
> On Tue, 03 May 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
> > frequency we're going to be getting from the hardware. This will
> > let us accurately
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On BDW+ M/N are double buffered and so we can easily reprogram them
> during a fastset. So for eDP panels that support seamless DRRS we
> can just change these without a full modeset.
>
> For earlier platforms we'd need to play
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add a function to get the fixed_mode with the highest clock.
> The plan is to use this for the link bw calculation on seamless
> DRRS panels so that we alwasy end up with the same link params
> regardless of the requested
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Don't see a real reson not to check hw.active and hw.enable in
> intel_pipe_config_compare(). We do have some checks for them
> at a higher level, but I think better check them also in
> intel_pipe_config_compare() in case
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No sense in calling intel_modeset_pipe_config_late() for a disabled
> pipe.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 8 +---
> 1 file changed, 5
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we no longer do the fuzzy clock and M/N checks we can
> get rid of the fastset state copy hacks.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 28
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make the fastboot checks at least somewhat sensible let's mark
> the expected DPLL as the active one right after we finished the
> state computation. Otherwise intel_pipe_config_compare() will
> always be comparing things
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we backfeed the actual DPLL frequency into the
> compute crtc state all our clocks should come out exact.
/me looks at where intel_fuzzy_clock_check() is still used, and it's of
course DSI. Maybe we could move the
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Now that we no longer fuzz M/N during fastset these should
> match exctly.
>
> TODO: we may need to do something for fastboot here as the
> VBIOS/GOP may not compute M/N exactly the same way we do.
> Though I guess we could try
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The VBIOS/GOP may not program the FDI M/n vs. dotclock entirely
> consistently. Eg. on a SNB Thinkpad X220 LVDS I see dotclock of
> 69.286 MHz (the best the DPLL can do) vs. FDI M/N 69.3 MHz
> (matches what the EDID actually
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Do the DPLL computation before fastset checks. This should
> allow us to get rid of all that horrible fuzzy clock handling
> for fastsets. Who knows how many bugs there are caused by our
> state not actually matching what the
On Wed, 25 May 2022, Ville Syrjälä wrote:
> On Wed, May 25, 2022 at 11:44:05AM +0300, Jani Nikula wrote:
>> On Tue, 10 May 2022, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Move the panel specific VBT parsing to happen during the
>> > output probing stage. Needs to be done because
On Tue, 03 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Fill port_clock and hw.adjusted_mode.crtc_clock with the actual
> frequency we're going to be getting from the hardware. This will
> let us accurately compute all derived state that depends on those.
This patch (and to be
On Wed, May 25, 2022 at 11:44:05AM +0300, Jani Nikula wrote:
> On Tue, 10 May 2022, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Move the panel specific VBT parsing to happen during the
> > output probing stage. Needs to be done because the VBT
> > parsing will need to look at the EDID
== Series Details ==
Series: drm/i915/dg2: Support 4k@30 on HDMI (rev3)
URL : https://patchwork.freedesktop.org/series/103862/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_11698 -> Patchwork_103862v3
Summary
---
_i915_vma_move_to_active() can receive > 1 fences for
multiple batch buffers submission. Because dma_resv_add_fence()
can only accept one fence at a time, change _i915_vma_move_to_active()
to be aware of multiple fences so that it can add individual
fences to the dma resv object.
v6: fix
On 25/05/2022 12:26, Lionel Landwerlin wrote:
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array
On 25/05/2022 11:24, Christian König wrote:
Am 25.05.22 um 08:47 schrieb Lionel Landwerlin:
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
Signed-off-by: Christian König
---
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, May 25, 2022 2:26 PM
> To: Srinivas, Vidya ; Souza, Jose
> ; intel-gfx@lists.freedesktop.org
> Cc: Sean Paul ; Syrjala, Ville
>
> Subject: Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/display: Implement seamless
> mode switch
>
>
On Wed, 25 May 2022, "Srinivas, Vidya" wrote:
> Hello,
>
> Apologies for bothering. May we kindly know if this solution is approved?
> I have provided the Tested-by. Thanks much.
IIUC the more complete solution is [1].
BR,
Jani.
[1] https://patchwork.freedesktop.org/series/103491/
>
>
On 25.05.22 10:37, Jan Beulich wrote:
> On 25.05.2022 09:45, Thorsten Leemhuis wrote:
>> On 24.05.22 20:32, Chuck Zmudzinski wrote:
>>> On 5/21/22 6:47 AM, Thorsten Leemhuis wrote:
I'm not a developer and I'm don't known the details of this thread and
the backstory of the regression, but
On Tue, 24 May 2022, "Sarvela, Tomi P" wrote:
> Both links work. Patchwork posting is done before results are synced to
> upstream service. This is noticeable with 404 if the transfer is slow.
> The issue is known and will be fixed when priorities allow.
Right, I was just being impatient hitting
On Tue, 10 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Handle VBT panel_type=0xff, ie. extract the panel PNPID from
> the EDID and match it againts the VBT panel PNPIDs to determine
> the actual panel_type.
>
> We need to massage the PPS init code a bit to make sure it
> works
On Tue, 10 May 2022, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Move the panel specific VBT parsing to happen during the
> output probing stage. Needs to be done because the VBT
> parsing will need to look at the EDID to determine
> the correct panel_type on some machines.
>
> We split the
From: Vandita Kulkarni
This patch adds a fix to support 297MHz of dot clock by calculating
the pll values using synopsis algorithm.
This will help to support 4k@30 mode for HDMI monitors on DG2.
v2: As per the algorithm, set MPLLB VCO range control bits to 3,
in register SNPS_PHY_MPLLB_DIV for
== Series Details ==
Series: drm/i915/dg2: Support 4k@30 on HDMI (rev2)
URL : https://patchwork.freedesktop.org/series/103862/
State : failure
== Summary ==
Error: make failed
CALLscripts/checksyscalls.sh
CALLscripts/atomic/check-atomics.sh
DESCEND objtool
CHK
From: Vandita Kulkarni
This patch adds a fix to support 297MHz of dot clock by calculating
the pll values using synopsis algorithm.
This will help to support 4k@30 mode for HDMI monitors on DG2.
v2: As per the algorithm, set MPLLB VCO range control bits to 3,
in register SNPS_PHY_MPLLB_DIV for
On 24.05.22 20:32, Chuck Zmudzinski wrote:
> On 5/21/22 6:47 AM, Thorsten Leemhuis wrote:
>> On 20.05.22 16:48, Chuck Zmudzinski wrote:
>>> On 5/20/2022 10:06 AM, Jan Beulich wrote:
On 20.05.2022 15:33, Chuck Zmudzinski wrote:
> On 5/20/2022 5:41 AM, Jan Beulich wrote:
>> On
On 5/21/2022 12:50 AM, Matt Roper wrote:
On Wed, May 11, 2022 at 02:01:21PM +0530, Ankit Nautiyal wrote:
From: Vandita Kulkarni
This patch adds a fix to support 297MHz of dot clock by calculating
the pll values using synopsis algorithm.
This will help to support 4k@30 mode for HDMI monitors
On 09/02/2022 20:26, Christian König wrote:
It is illegal to add a dma_fence_chain as timeline point. Flatten out
the fences into a dma_fence_array instead.
Signed-off-by: Christian König
---
drivers/gpu/drm/drm_syncobj.c | 61 ---
1 file changed, 56
== Series Details ==
Series: drm/i915/hwconfig: Future-proof platform checks
URL : https://patchwork.freedesktop.org/series/104338/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_11696_full -> Patchwork_104338v1_full
93 matches
Mail list logo
