> From: Liu, Yi L
> Sent: Wednesday, March 8, 2023 3:47 PM
>
> > From: Tian, Kevin
> > Sent: Wednesday, March 8, 2023 3:26 PM
> >
> > > From: Liu, Yi L
> > > Sent: Tuesday, March 7, 2023 9:29 PM
> > >
> > > >
> > > > I really prefer the 'use the iommufd option' still exist, it is so
> > > >
> From: Tian, Kevin
> Sent: Wednesday, March 8, 2023 3:26 PM
>
> > From: Liu, Yi L
> > Sent: Tuesday, March 7, 2023 9:29 PM
> >
> > >
> > > I really prefer the 'use the iommufd option' still exist, it is so
> > > much cleaner and easier for the actual users of this API. We've lost
> > > the
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:29 PM
>
> >
> > I really prefer the 'use the iommufd option' still exist, it is so
> > much cleaner and easier for the actual users of this API. We've lost
> > the point by worrying about no iommu.
>
> Hmmm, so you are suggesting to have both
> From: Liu, Yi L
> Sent: Tuesday, March 7, 2023 9:04 PM
>
> > From: Jason Gunthorpe
> > Sent: Tuesday, March 7, 2023 8:38 PM
> >
> > On Tue, Mar 07, 2023 at 06:38:59AM +, Tian, Kevin wrote:
> > > > From: Liu, Yi L
> > > > Sent: Friday, March 3, 2023 2:58 PM
> > > >
> > > > > What should
> -Original Message-
> From: Intel-gfx On Behalf Of Kahola,
> Mika
> Sent: Tuesday, March 7, 2023 3:24 PM
> To: De Marchi, Lucas
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg
> file
> for PICA registers
>
> >
Am 08.03.23 um 03:26 schrieb Steven Rostedt:
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
Looks like there was a lock possibly used after free. But as commit
9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
workers") changed a lot of this code, I figured it
== Series Details ==
Series: drm/i915/pmu: Use common freq functions with sysfs
URL : https://patchwork.freedesktop.org/series/114814/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114814v1
Summary
On 3/7/2023 9:33 PM, Ashutosh Dixit wrote:
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
For the requested_freq, we read it only if actual_freq is zero below
(meaning, GT is in C6). So then what is
On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from
>
> Would it be more accurate to say 'SLPC does not use rps->cur_freq' rather
> than it not using struct
On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote:
>
Hi Tvrtko,
> On 04/03/2023 01:27, Ashutosh Dixit wrote:
> > On newer generations, the GEN12_RPSTAT1 register contains more than freq
> > information, e.g. see GEN12_VOLTAGE_MASK. Therefore use only the freq bits
> > to decide whether to
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generation (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU
Using common freq functions with sysfs in PMU (but without taking
forcewake) solves the following issues (a) missing support for MTL (b)
missing support for older generations (prior to Gen6) (c) missing support
for slpc when freq sampling has to fall back to requested freq. It also
makes the PMU
Expose intel_rps_get_requested_frequency_fw to read the requested freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support both host
turbo
Expose intel_rps_read_actual_frequency_fw to read the actual/granted freq
without taking forcewake. This is done for use by PMU which does not take
forcewake when reading freq. The code is refactored to use a common set of
functions across sysfs and PMU. It also allows PMU to support MTL as well
On Tue, 7 Mar 2023 21:22:23 -0500
Steven Rostedt wrote:
> Looks like there was a lock possibly used after free. But as commit
> 9bff18d13473a9fdf81d5158248472a9d8ecf2bd ("drm/ttm: use per BO cleanup
> workers") changed a lot of this code, I figured it may be the culprit.
If I bothered to look
In a report for a regression in my code, I tried to run v6.3-rc1 through my
tests. It crashed at boot up on my first test (my start up tests do take a
long time, hence the 206 seconds of boot!).
[ 206.238782] [ cut here ]
[ 206.277786] DEBUG_LOCKS_WARN_ON(lock->magic
On Tue, 07 Mar 2023 12:16:10 -0800, Umesh Nerlige Ramappa wrote:
>
Hi Umesh,
> + /* Defaults when class:instance is not passed */
> + class = I915_ENGINE_CLASS_RENDER;
> + instance = 0;
> +
> for (i = 0; i < n_props; i++) {
> u64 oa_period, oa_freq_hz;
>
== Series Details ==
Series: Fix a couple of issues with the GSC worker timing (rev2)
URL : https://patchwork.freedesktop.org/series/114306/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114306v2
Summary
== Series Details ==
Series: Fix a couple of issues with the GSC worker timing (rev2)
URL : https://patchwork.freedesktop.org/series/114306/
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/dmc: Load DMC on MTL (rev2)
URL : https://patchwork.freedesktop.org/series/114576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12827 -> Patchwork_114576v2
Summary
---
== Series Details ==
Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has
been added to the 5.15-stable tree
URL : https://patchwork.freedesktop.org/series/114787/
State : failure
== Summary ==
Error: patch
On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> If we unload the driver and wedge before the GSC worker is complete,
> the worker will hit an error on its submission to the GSC engine and
> then exit. This is hard to hit for a user, but it is reproducible
> with skipping
== Series Details ==
Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has
been added to the 6.1-stable tree
URL : https://patchwork.freedesktop.org/series/114785/
State : failure
== Summary ==
Error: patch
== Series Details ==
Series: Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has
been added to the 6.1-stable tree
URL : https://patchwork.freedesktop.org/series/114784/
State : failure
== Summary ==
Error: patch
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Don't switch to TPS1 when
disabling DP_TP_CTL (rev2)
URL : https://patchwork.freedesktop.org/series/114011/
State : failure
== Summary ==
Error: patch
On Tue, Mar 07, 2023 at 10:50:49AM +0200, Jani Nikula wrote:
> On Tue, 21 Feb 2023, Imre Deak wrote:
> > Call the opregion register/unregister functions during driver
> > loading/unloading on !HAS_DISPLAY platforms. These functions will send
> > the opregion adapter power state notifications
== Series Details ==
Series: Patch "drm/i915: Don't use stolen memory for ring buffers with LLC" has
been added to the 6.2-stable tree
URL : https://patchwork.freedesktop.org/series/114782/
State : failure
== Summary ==
Error: patch
== Series Details ==
Series: Patch "drm/i915: Don't use BAR mappings for ring buffers with LLC" has
been added to the 6.2-stable tree
URL : https://patchwork.freedesktop.org/series/114781/
State : failure
== Summary ==
Error: patch
Hi Dave and Daniel,
Here goes our first pull request towards 6.3.
drm-intel-next-2023-03-07:
Cross-subsystem Changes:
- MEI patches to fix suspend/resume issues with the i915's PXP. (Alexander)
Driver Changes:
- Registers helpers and clean-ups. (Lucas)
- PXP fixes and clean-ups. (Alan,
On Thu, 2023-02-23 at 09:21 -0800, Ceraolo Spurio, Daniele wrote:
> The GSC FW load is a slow process (up to 250 ms), so we defer it to a
> dedicated worker to avoid stalling the init flow for that long. However,
> we currently start this worker before the HW init is complete, so there
> is a
== Series Details ==
Series: drm/ttm: Small fixes / cleanups in prep for shrinking
URL : https://patchwork.freedesktop.org/series/114774/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12824 -> Patchwork_114774v1
Summary
== Series Details ==
Series: drm/i915/selftest: Remove avoidable init assignment
URL : https://patchwork.freedesktop.org/series/114755/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114755v1_full
On Tue, Mar 07, 2023 at 05:23:37PM -0300, Gustavo Sousa wrote:
> On Tue, Mar 07, 2023 at 12:12:46PM -0800, Matt Roper wrote:
> > On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> > > Wa_1606376872 applies to all Xe_LP IPs.
> >
> > "...except DG1"
>
> Oh, okay. I thought there was
On Tue, Mar 07, 2023 at 12:12:46PM -0800, Matt Roper wrote:
> On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> > Wa_1606376872 applies to all Xe_LP IPs.
>
> "...except DG1"
Oh, okay. I thought there was distinction between Xe_LP and Xe_LP+.
>
> Aside from that,
>
>
MTL introduces additional OA units dedicated to media use cases. Add
support for programming these OA units by passing the media engine class
and instance parameters.
UMD specific changes for GPUvis support:
https://patchwork.freedesktop.org/patch/522827/?series=114023
With an intention to add more engines that are supported by OA, add
helper to check for supported OA engines.
v2: (Ashutosh)
- Update commit message
- Drop virtual engine check since we support only one render engine
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
i915_perf_init can fail due to OOM. Fail driver init if i915_perf_init
fails.
v2: (Jani)
- Reorder patch in the series
Signed-off-by: Umesh Nerlige Ramappa
Reviewed-by: Ashutosh Dixit
---
drivers/gpu/drm/i915/i915_driver.c | 4 +++-
drivers/gpu/drm/i915/i915_perf.c | 8 ++--
Once OA supports media engine class:instance, the engine can only be
validated outside the switch since class and instance parameters are
separate entities. Since OA sseu config depends on engine
class:instance, validate OA sseu config outside the switch.
v2: (Ashutosh)
- Clarify commit message
-
The OAM unit captures OA reports specific to the media engines. Add support to
program the OAM unit on media tile on MTL.
The OAM unit is selected by passing the class:instance of a media engine to perf
parameters. Corresponding UMD changes are posted to the igt-dev repo as part of
supporting the
Some of the newer OA formats are not powers of 2. For those formats,
adjust the hw_tail accordingly when checking for new reports.
v2: (Ashutosh)
- Switch to OA_TAKEN for diff calculation
- Use OA_BUFFER_SIZE instead of the vma size
- Update comments
Signed-off-by: Umesh Nerlige Ramappa
Now that OA formats come in flavor of 64 bit reports, the report header
has 64 bit report-id, timestamp, context-id and gpu-ticks fields. When
filtering these reports, use the right width for these fields.
Note that upper dword of context id is reserved, so squash lower dword
only.
v2:
One or more engines map to a specific OA unit. All reports from these
engines are captured in the OA buffer managed by this OA unit.
Current i915 OA implementation supports only the OAG unit. OAG primarily
caters to render engine, so i915 OA uses render as the default engine
in the OA
Now that we may have multiple OA units in a single GT as well as on
separate GTs, create an engine group that maps to a single OA unit.
v2: (Jani)
- Drop warning on ENOMEM
- Reorder patch in the series
v3: (Ashutosh)
- Remove unused members from perf structs
- Update comments
- Update
From: Chris Wilson
If we fail to adjust the GuC run-control on opening the perf stream,
make sure we unwind the wakeref just taken.
v2: Retain old goto label names (Ashutosh)
Fixes: 01e742746785 ("drm/i915/guc: Support OA when Wa_16011777198 is enabled")
Signed-off-by: Chris Wilson
On Tue, Mar 07, 2023 at 12:22:38AM -0300, Gustavo Sousa wrote:
> Wa_1606376872 applies to all Xe_LP IPs.
"...except DG1"
Aside from that,
Reviewed-by: Matt Roper
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/gt/intel_gt_regs.h | 3 +++
>
== Series Details ==
Series: drm/i915/display: Set correct voltage level for 480MHz CDCLK
URL : https://patchwork.freedesktop.org/series/114752/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114752v1_full
On Tue, Mar 07, 2023 at 04:51:11PM -0300, Gustavo Sousa wrote:
> From: Madhumitha Tolakanahalli Pradeep
>
>
> Add support to load DMC on MTL.
>
> According to the spec and based on tests done on real hardware, 0x7000
> is a reasonable size limit that covers each possible payload.
>
> v2:
>
From: Madhumitha Tolakanahalli Pradeep
Add support to load DMC on MTL.
According to the spec and based on tests done on real hardware, 0x7000
is a reasonable size limit that covers each possible payload.
v2:
- Tighten payload size limit. (Matt, Rodrigo)
- Use a better name for the defined
, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Thomas-Hellstr-m/drm-ttm-Fix-a-NULL-pointer-dereference/20230307-224931
base: git://anongit.freedesktop.org/drm/drm-misc drm-misc
From: John Harrison
commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
From: John Harrison
commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
From: John Harrison
commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is
On 3/7/23 21:25, Dmitry Osipenko wrote:
>> Not really a problem with this patchset, but having such branches looks
>> like a bug in the driver's GEM design. Whatever your GEM object needs or
>> does, it should be hidden in the implementation. Why is virtio doing this?
> There is another "VRAM"
On 3/7/23 13:42, Thomas Zimmermann wrote:
> Hi
>
> Am 05.03.23 um 23:10 schrieb Dmitry Osipenko:
> [...]
>> *bo_ptr = bo;
>> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c
>> b/drivers/gpu/drm/virtio/virtgpu_plane.c
>> index 4c09e313bebc..3f21512ff153 100644
>> ---
From: John Harrison
commit 85636167e3206c3fbd52254fc432991cc4e90194 upstream.
Direction from hardware is that ring buffers should never be mapped
via the BAR on systems with LLC. There are too many caching pitfalls
due to the way BAR accesses are routed. So it is safest to just not
use it.
From: John Harrison
commit 690e0ec8e63da9a29b39fedc6ed5da09c7c82651 upstream.
Direction from hardware is that stolen memory should never be used for
ring buffer allocations on platforms with LLC. There are too many
caching pitfalls due to the way stolen memory accesses are routed. So
it is
On 3/7/23 17:55, Christian König wrote:
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock,
== Series Details ==
Series: Enable HDCP2.x via GSC CS (rev11)
URL : https://patchwork.freedesktop.org/series/111876/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_111876v11_full
Summary
---
Am 07.03.23 um 15:46 schrieb Thomas Hellström:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the
This is a note to let you know that I've just added the patch titled
drm/i915: Don't use BAR mappings for ring buffers with LLC
to the 5.15-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/i915: Don't use BAR mappings for ring buffers with LLC
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/i915: Don't use stolen memory for ring buffers with LLC
to the 6.1-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
From: Ville Syrjälä
AFAICS Bspec has never asked us to switch to TPS1 when *disabling*
DP_TP_CTL. Let's stop doing that in case it confuses something.
We do have to switch before we *enable* DP_TP_CTL, but that
is already being handled correctly.
v2: Do the same for FDI
Reviewed-by: Imre Deak
This is a note to let you know that I've just added the patch titled
drm/i915: Don't use stolen memory for ring buffers with LLC
to the 6.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
drm/i915: Don't use BAR mappings for ring buffers with LLC
to the 6.2-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
== Series Details ==
Series: drm/i915/xelp: Implement Wa_1606376872
URL : https://patchwork.freedesktop.org/series/114745/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12820_full -> Patchwork_114745v1_full
Summary
---
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap
framebuffer obj
URL : https://patchwork.freedesktop.org/series/114775/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12821 -> Patchwork_114775v1
Hi,
On Thu, Feb 16, 2023 at 12:12:13PM +0100, Daniel Vetter wrote:
> The stuff never really worked, and leads to lots of fun because it
> out-of-order frees atomic states. Which upsets KASAN, among other
> things.
>
> For async updates we now have a more solid solution with the
>
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap
framebuffer obj
URL : https://patchwork.freedesktop.org/series/114775/
State : warning
== Summary ==
Error: dim sparse failed
Sparse version: v0.6.2
Fast mode used, each commit won't be checked
== Series Details ==
Series: series starting with [RFC,1/2] drm/i915: Add a function to mmap
framebuffer obj
URL : https://patchwork.freedesktop.org/series/114775/
State : warning
== Summary ==
Error: dim checkpatch failed
d0b102d9dd12 drm/i915: Add a function to mmap framebuffer obj
-:120:
Hi Ville,
On 3/6/2023 3:32 PM, Ville Syrjälä wrote:
On Mon, Mar 06, 2023 at 11:28:50AM +0100, Nirmoy Das wrote:
If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no
When swapping in, or under memory pressure ttm_tt_populate() may sleep
for a substantiable amount of time. Allow interrupts during the sleep.
This will also allow us to inject -EINTR errors during swapin in upcoming
patches.
Also avoid returning VM_FAULT_OOM, since that will confuse the core
mm,
When swapping out, we will split multi-order pages both in order to
move them to the swap-cache and to be able to return memory to the
swap cache as soon as possible on a page-by-page basis.
Reduce the page max order to the system PMD size, as we can then be nicer
to the system and avoid splitting
Avoid printing an error message if eviction was interrupted by,
for example, the user pressing CTRL-C. That may happen if eviction
is waiting for something, like for example a free batch-buffer.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_bo.c | 3 ++-
1 file changed, 2
Unexport ttm_global_swapout() since it is not used outside of TTM.
Signed-off-by: Thomas Hellström
---
drivers/gpu/drm/ttm/ttm_device.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_device.c b/drivers/gpu/drm/ttm/ttm_device.c
index ae2f19dc9f81..64a59f46f6c3 100644
New code is recommended to use the BIT macro instead of the explicit
shifts. Change the older defines so that we can keep the style consistent
with upcoming changes.
v2:
- Also change the value of the _PRIV_POPULATED bit (Christian König)
Signed-off-by: Thomas Hellström
---
When hitting an error, the error path forgot to unmap dma mappings and
could call set_pages_wb() on already uncached pages.
Fix this by introducing a common __ttm_pool_free() function that
does the right thing.
v2:
- Simplify __ttm_pool_free() (Christian König)
Fixes: d099fc8f540a ("drm/ttm:
The LRU mechanism may look up a resource in the process of being removed
from an object. The locking rules here are a bit unclear but it looks
currently like res->bo assignment is protected by the LRU lock, whereas
bo->resource is protected by the object lock, while *clearing* of
bo->resource is
If stolen memory allocation fails for fbdev, the driver will
fallback to system memory. Calculation of smem_start is wrong
for such framebuffer objs if the platform comes with no gmadr or
no aperture. Solve this by adding fb_mmap callback which will
use GTT if aperture is available otherwise will
Implement i915_gem_fb_mmap() to enable fb_ops.fb_mmap()
callback for i915's framebuffer objects.
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 121 ++-
drivers/gpu/drm/i915/gem/i915_gem_mman.h | 2 +-
2 files changed, 77 insertions(+), 46
I collected the, from my POW, uncontroversial patches from V1 of the TTM
shrinker series, some corrected after the initial patch submission, one
patch added from the Xe RFC ("drm/ttm: Don't print error message if
eviction was interrupted"). It would be nice to have these reviewed and
merged while
On Tue, 07 Mar 2023, Ville Syrjälä wrote:
> On Tue, Mar 07, 2023 at 02:24:08PM +0200, Jani Nikula wrote:
>> On Mon, 06 Mar 2023, Ville Syrjala wrote:
>> > From: Ville Syrjälä
>> >
>> > Add some (probably overkill) locking to protect the vblank
>> > timestamping constants updates during seamless
On Tue, Mar 07, 2023 at 02:24:08PM +0200, Jani Nikula wrote:
> On Mon, 06 Mar 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Add some (probably overkill) locking to protect the vblank
> > timestamping constants updates during seamless M/N fastsets.
> >
> > As everything should be
On Tue, Mar 07, 2023 at 02:16:48PM +0200, Jani Nikula wrote:
> On Mon, 06 Mar 2023, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > When we change the M/N values seamlessly during a fastset we should
> > also update the vblank timestamping stuff to make sure the vblank
> > timestamp
Add a helper setting config values which are typically constant across
operating modes (table E-4 of the standard) and mux_word_size (which is
a const according to 3.5.2).
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 21 +
Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 438 +++
include/drm/display/drm_dsc_helper.h | 2 +
2 files changed, 440 insertions(+)
diff --git
Use new DRM DSC helpers to setup DSI DSC configuration. The
initial_scale_value needs to be adjusted according to the standard, but
this is a separate change.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/msm/dsi/dsi_host.c | 61 --
1 file changed, 8
DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 72
1 file changed, 72 insertions(+)
diff --git
Stop using an interim structure rc_parameters for storing calculated
params and then setting drm_dsc_config using that structure. Instead put
calculated params into the struct drm_dsc_config directly.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
Next commits are going to add support for additional RC parameter lookup
tables. These tables are going to use different bpp/bpc combinations,
thus it makes little sense to keep the 2d array for RC parameters.
Switch to using the flat array.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry
The array of rc_parameters contains a mixture of parameters from DSC 1.1
and DSC 1.2 standards. Split these tow configuration arrays in
preparation to adding more configuration data.
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 127 ++
The rc_buf_thresh values are common to all DSC implementations. Move
them to the common helper together with the code to propagage them to
the drm_dsc_config.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 35 +++
After cross-checking DSC models (20150914, 20161212, 20210623) change
values in rc_parameters tables to follow config files present inside
the DSC model. Handle two places, where i915 tables diverged from the
model, by patching the rc values in the code.
Note: I left one case uncorrected,
Move DSC RC tables to DRM DSC helper. No additional code changes
and/or cleanups are a part of this commit, it will be cleaned up in the
followup commits.
Reviewed-by: Jani Nikula
Signed-off-by: Dmitry Baryshkov
---
drivers/gpu/drm/display/drm_dsc_helper.c | 372 ++
Other platforms (msm) will benefit from sharing the DSC config setup
functions. This series moves parts of static DSC config data from the
i915 driver to the common helpers to be used by other drivers.
Note: the RC parameters were cross-checked against config files found in
DSC model 2021062,
On 07-03-2023 01:50, Rodrigo Vivi wrote:
On Mon, Mar 06, 2023 at 08:33:04AM +, Gupta, Anshuman wrote:
-Original Message-
From: Nilawar, Badal
Sent: Saturday, March 4, 2023 9:48 PM
To: intel-gfx@lists.freedesktop.org
Cc: Gupta, Anshuman ; Ewins, Jon
; Belgaumkar, Vinay ;
Vivi,
On 28/02/2023 18:31, Jani Nikula wrote:
On Tue, 28 Feb 2023, Dmitry Baryshkov wrote:
DSC model contains pre-SCR RC parameters for other bpp/bpc combinations,
include them here for completeness.
Need to run now, note to self:
Does i915 use the arrays to limit the bpp/bpc combos supported by
On Tue, Mar 07, 2023 at 03:16:43PM +0530, Tejas Upadhyay wrote:
> We can skip the assignment and i915 variable
> altogether and use refernce directly. Also used at
> single place only.
>
> Signed-off-by: Tejas Upadhyay
trusting the compiler,
Reviewed-by: Rodrigo Vivi
> ---
>
> From: Jason Gunthorpe
> Sent: Tuesday, March 7, 2023 8:37 PM
>
> On Tue, Mar 07, 2023 at 02:31:11AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Monday, March 6, 2023 9:17 PM
> > >
> > > On Fri, Mar 03, 2023 at 09:55:42AM -0700, Alex Williamson wrote:
> > >
> > > > I
> -Original Message-
> From: De Marchi, Lucas
> Sent: Wednesday, March 1, 2023 1:27 AM
> To: Kahola, Mika
> Cc: intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH v4 03/22] drm/i915/mtl: Create separate reg
> file
> for PICA registers
>
> On Fri, Feb 24, 2023 at
1 - 100 of 142 matches
Mail list logo
