[Intel-gfx] [PULL] drm-intel-fixes
Hi Dave & Daniel - One DSI fix, stable material. drm-intel-fixes-2023-04-13: drm/i915 fixes for v6.3-rc7: - Fix dual link DSI for TGL+ BR, Jani. The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-04-13 for you to fetch changes up to 6b8446859c971a5783a2cdc90adf32e64de3bd23: drm/i915/dsi: fix DSS CTL register offsets for TGL+ (2023-04-11 11:41:57 +0300) drm/i915 fixes for v6.3-rc7: - Fix dual link DSI for TGL+ Jani Nikula (1): drm/i915/dsi: fix DSS CTL register offsets for TGL+ drivers/gpu/drm/i915/display/icl_dsi.c | 20 1 file changed, 16 insertions(+), 4 deletions(-) -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Fix memory leaks in i915 selftests
On Thu, 13 Apr 2023, Andrzej Hajda wrote:
> On 13.04.2023 05:13, Cong Liu wrote:
A commit message is still needed.
>> Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
>> creation")
>>
No blank line here.
BR,
Jani.
>> Signed-off-by: Cong Liu
>> ---
>
> Reviewed-by: Andrzej Hajda
>
> Regards
> Andrzej
>> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> index 5361ce70d3f2..154801f1c468 100644
>> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> @@ -69,8 +69,10 @@ static int fake_get_pages(struct drm_i915_gem_object *obj)
>>
>> rem = round_up(obj->base.size, BIT(31)) >> 31;
>> /* restricted by sg_alloc_table */
>> -if (overflows_type(rem, unsigned int))
>> +if (overflows_type(rem, unsigned int)) {
>> +kfree(pages);
>> return -E2BIG;
>> +}
>>
>> if (sg_alloc_table(pages, rem, GFP)) {
>> kfree(pages);
>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Fix memory leaks in i915 selftests
Hi Cong,
> Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
> creation")
>
> Signed-off-by: Cong Liu
As Jani suggested we need a commit message here. Would something
like this work for you?
"
We forget to free 'pages' after checking for overflow. Be sure to
properly free the allocated memory before exiting the
fake_free_pages() function.
"
If it's OK for you, then I can add this message and fix the blank
space before pushing this patch.
In any case:
Reviewed-by: Andi Shyti
Andi
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 5361ce70d3f2..154801f1c468 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -69,8 +69,10 @@ static int fake_get_pages(struct drm_i915_gem_object *obj)
>
> rem = round_up(obj->base.size, BIT(31)) >> 31;
> /* restricted by sg_alloc_table */
> - if (overflows_type(rem, unsigned int))
> + if (overflows_type(rem, unsigned int)) {
> + kfree(pages);
> return -E2BIG;
> + }
>
> if (sg_alloc_table(pages, rem, GFP)) {
> kfree(pages);
> --
> 2.34.1
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
Re: [Intel-gfx] [Intel-xe] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path
On Wed, 12 Apr 2023, "Souza, Jose" wrote: > On Tue, 2023-04-11 at 14:20 -0700, Lucas De Marchi wrote: >> On Tue, Apr 11, 2023 at 08:07:12PM +, Jose Souza wrote: >> > On Tue, 2023-04-11 at 12:59 -0700, Lucas De Marchi wrote: >> > > On Tue, Apr 11, 2023 at 10:51:04AM -0400, Rodrigo Vivi wrote: >> > > > On Tue, Apr 11, 2023 at 12:14:36PM +0300, Jani Nikula wrote: >> > > > > On Tue, 11 Apr 2023, Ville Syrjälä >> > > > > wrote: >> > > > > > On Tue, Apr 11, 2023 at 11:51:33AM +0300, Jani Nikula wrote: >> > > > > > > On Tue, 11 Apr 2023, Ville Syrjälä >> > > > > > > wrote: >> > > > > > > > On Mon, Apr 10, 2023 at 11:32:14AM -0700, José Roberto de >> > > > > > > > Souza wrote: >> > > > > > > > > Start to move the initialization of some lock from >> > > > > > > > > i915_driver_early_probe(). >> > > > > > > > > No dkl function is called prior to intel_setup_outputs(), so >> > > > > > > > > this is >> > > > > > > > > a good place to initialize it. >> > > > > > > > >> > > > > > > > I disagree. We don't want to sprinke these all over the place. >> > > > > > > >> > > > > > > I'm thinking if only foo.c uses a lock, foo.c should initialize >> > > > > > > it, not >> > > > > > > someone else. >> > > > > > >> > > > > > Perhaps. But I think there should be some consistent place in the >> > > > > > higher >> > > > > > level code where all such things get called instead of dropping >> > > > > > each one >> > > > > > individually into some random spot in the overlall display init >> > > > > > flow. >> > > > > >> > > > > Agreed. >> > > > >> > > > Ops, I just saw this now, right after I cc'ed you in the other thread. >> > > > >> > > > So, probably good to hold this and do the entire refactor together of >> > > > all >> > > > those locks initialization so we find this common consistent place >> > > > apparently... >> > > >> > > "internal" sw initialization of display-related stuff. It doesn't belong >> > > in >> > > i915_driver_early_probe(), it makes harder to follow the sequence if we >> > > sprinkle >> > > them around, like here in intel_setup_outputs. >> > > >> > > But I don't see why this couldn't be done in a higher level "sw >> > > initialization of display-related stuff". Should we add an equivalent >> > > of i915_driver_early_probe(), e.g. intel_display_early_probe()[1], and >> > > move the display-related things from i915_driver_early_probe()? >> > > >> > > In that case, from xe we would call this function rather than >> > > initializing these fields in xe_display_create() >> > >> > Sent another version, added intel_display_locks_init() that is called in >> > the beginning of intel_modeset_init_noirq(). >> > https://patchwork.freedesktop.org/series/116326/ >> >> modeset? why? That is after we are already probing the hw > > That called during probe, called from i915_driver_probe(). > >> and what does that have to do with modeset? > > The name is misleading but intel_modeset_init_noirq() is the first generic > display initialization function called. > There is other display functions called before it but they are very > specific(intel_dram_detect(), intel_bw_init_hw() and > intel_device_info_runtime_init()). See [1]. BR, Jani. [1] https://lore.kernel.org/r/87ile1cjh8@intel.com > >> >> Lucas De Marchi >> >> > >> > If this is accepted we can then move the other display locks from >> > i915_driver_early_probe(). >> > >> > > >> > > Lucas De Marchi >> > > >> > > [1] I don't like the name, but it follows what is already there >> > > >> > > > >> > > > > >> > > > > -- >> > > > > Jani Nikula, Intel Open Source Graphics Center >> > > -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Jason Gunthorpe
> Sent: Thursday, April 13, 2023 4:07 AM
>
>
> > in which case we need c) a way to
> > report the overall set of affected devices regardless of ownership in
> > support of 4), BDF?
>
> Yes, continue to use INFO unmodified.
>
> > Are we back to replacing group-ids with dev-ids in the INFO structure,
> > where an invalid dev-id either indicates an affected device with
> > implied ownership (ok) or a gap in ownership (bad) and a flag somewhere
> > is meant to indicate the overall disposition based on the availability
> > of reset?
>
> As you explore in the following this gets ugly. I prefer to keep INFO
> unchanged and add INFO2.
>
INFO needs a change when VFIO_GROUP is disabled. Now it assumes
a valid iommu group always exists:
vfio_pci_fill_devs()
{
...
iommu_group = iommu_group_get(&pdev->dev);
if (!iommu_group)
return -EPERM; /* Cannot reset non-isolated devices */
...
}
Probably we need a special value e.g. -1 to represent noiommu case
given valid group ids are positive.
with that plus BDF cap, I'm curious what is the actual purpose of
INFO2 or why cannot requirement#3 reuse the information collected
via existing INFO?
For each opened device Qemu can find the related group id via
sysfs (if group exists) or an optional GROUP cap and use that id to
match the group id in INFO.
For noiommu it has a group id if VFIO_GROUP=y then same case.
For noiommu if VFIO_GROUP=n just do exact match based on BDF.
Either way the information returned by INFO is a superset of knowing
the reset scope between opened devices.
Thanks
Kevin
Re: [Intel-gfx] [PATCH] drm/i915: Fix memory leaks in i915 selftests
On Thu, Apr 13, 2023 at 03:55:26PM +0800, Cong Liu wrote:
> This patch fixes memory leaks on error escapes in function fake_get_pages
>
> Fixes: c3bfba9a2225 ("drm/i915: Check for integer truncation on scatterlist
> creation")
> Signed-off-by: Cong Liu
OK, while I was proposing the adjustments suggested by Jani you
already replied to the e-mail. I will keep your version.
Anyway, next time, please, do not forget to add the r-b's, in
this case it was Andrzej's.
Andi
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 5361ce70d3f2..154801f1c468 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -69,8 +69,10 @@ static int fake_get_pages(struct drm_i915_gem_object *obj)
>
> rem = round_up(obj->base.size, BIT(31)) >> 31;
> /* restricted by sg_alloc_table */
> - if (overflows_type(rem, unsigned int))
> + if (overflows_type(rem, unsigned int)) {
> + kfree(pages);
> return -E2BIG;
> + }
>
> if (sg_alloc_table(pages, rem, GFP)) {
> kfree(pages);
> --
> 2.34.1
>
>
> No virus found
> Checked by Hillstone Network AntiVirus
Re: [Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
On Wed, 12 Apr 2023 at 16:18, Christian König wrote:
>
> Am 12.04.23 um 11:08 schrieb Daniel Vetter:
> > On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote:
> >> On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
> >>> Am 11.04.23 um 11:51 schrieb Daniel Vetter:
> On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
> > 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 gigantic pages.
> >
> > Looking forward to when we might be able to swap out PMD size folios
> > without splitting, this will also be a benefit.
> >
> > v2:
> > - Include all orders up to the PMD size (Christian König)
> > v3:
> > - Avoid compilation errors for architectures with special PFN_SHIFTs
> >
> > Signed-off-by: Thomas Hellström
> > Reviewed-by: Christian König
> Apparently this fails on ppc build testing. Please supply build fix asap
> (or I guess we need to revert). I'm kinda not clear why this only showed
> up when I merged the drm-misc-next pr into drm-next ...
> >>> I'm really wondering this as well. It looks like PMD_SHIFT isn't a
> >>> constant
> >>> on this particular platform.
> >>>
> >>> But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
> >>> to be a constant.
> >>>
> >>> So how exactly can that here break?
> >> There's some in-flight patches to rework MAX_ORDER and other things in
> >> linux-next, maybe it's recent? If you check out linux-next then you need
> >> to reapply the patch (since sfr reverted it).
> > So I looked and on ppc64 PMD_SHIFT is defined in terms of
> > PTE_INDEX_SIZE, which is defined (for book3s) in terms of the variable
> > __pte_index_size. This is in 6.3 already and seems pretty old.
>
> Ah! I missed that one, thanks.
>
> > So revert? Or fixup patch to make this work on ppc?
>
> I think for now just revert or change it so that we check if PMD_SHIFT
> is a constant.
>
> Thomas do you have any quick solution?
I guess Thomas is on vacations. Can you pls do the revert and push it
to drm-misc-next-fixes so this won't get lost?
Acked-by: Daniel Vetter
preemptively for that. Normally I think we could wait a bit more but
it's really close to merge window PR and I don't like handing too many
open things to Dave when he's back :-)
-Daniel
>
> Christian.
>
> >
> >
> > ---
> >drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
> >1 file changed, 19 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/ttm/ttm_pool.c
> > b/drivers/gpu/drm/ttm/ttm_pool.c
> > index dfce896c4bae..18c342a919a2 100644
> > --- a/drivers/gpu/drm/ttm/ttm_pool.c
> > +++ b/drivers/gpu/drm/ttm/ttm_pool.c
> > @@ -47,6 +47,11 @@
> >#include "ttm_module.h"
> > +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
> > +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
> > +/* Some architectures have a weird PMD_SHIFT */
> > +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER
> > : MAX_ORDER)
> > +
> >/**
> > * struct ttm_pool_dma - Helper object for coherent DMA mappings
> > *
> > @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
> >static atomic_long_t allocated_pages;
> > -static struct ttm_pool_type global_write_combined[MAX_ORDER];
> > -static struct ttm_pool_type global_uncached[MAX_ORDER];
> > +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
> > +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
> > -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
> > -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
> > +static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
> > +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
> >static spinlock_t shrinker_lock;
> >static struct list_head shrinker_list;
> > @@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct
> > ttm_tt *tt,
> >else
> >gfp_flags |= GFP_HIGHUSER;
> > - for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
> > + for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
> > num_pages;
> > order = min_t(unsigned int, order, __fls(num_pages))) {
> >struct ttm_pool_type *pt;
> > @@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct
> > device *dev,
> >if (use_dma_alloc) {
> >for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
> > - for (j = 0; j
Re: [Intel-gfx] [PATCH v5 2/5] drm/i915: Create the locked version of the request create
Hi Andrzej,
> > Make version of the request creation that doesn't hold any
> > lock.
> >
> > Signed-off-by: Andi Shyti
> > Cc: sta...@vger.kernel.org
> > Reviewed-by: Nirmoy Das
> > ---
> > drivers/gpu/drm/i915/i915_request.c | 38 +
> > drivers/gpu/drm/i915/i915_request.h | 2 ++
> > 2 files changed, 30 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index 630a732aaecca..58662360ac34e 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -1028,15 +1028,11 @@ __i915_request_create(struct intel_context *ce,
> > gfp_t gfp)
> > return ERR_PTR(ret);
> > }
> > -struct i915_request *
> > -i915_request_create(struct intel_context *ce)
> > +static struct i915_request *
> > +__i915_request_create_locked(struct intel_context *ce)
> > {
> > + struct intel_timeline *tl = ce->timeline;
> > struct i915_request *rq;
> > - struct intel_timeline *tl;
> > -
> > - tl = intel_context_timeline_lock(ce);
> > - if (IS_ERR(tl))
> > - return ERR_CAST(tl);
> > /* Move our oldest request to the slab-cache (if not in use!) */
> > rq = list_first_entry(&tl->requests, typeof(*rq), link);
> > @@ -1046,16 +1042,38 @@ i915_request_create(struct intel_context *ce)
> > intel_context_enter(ce);
> > rq = __i915_request_create(ce, GFP_KERNEL);
> > intel_context_exit(ce); /* active reference transferred to request */
> > +
> > if (IS_ERR(rq))
> > - goto err_unlock;
> > + return rq;
> > /* Check that we do not interrupt ourselves with a new request */
> > rq->cookie = lockdep_pin_lock(&tl->mutex);
> > return rq;
> > +}
> > +
> > +struct i915_request *
> > +i915_request_create_locked(struct intel_context *ce)
> > +{
> > + intel_context_assert_timeline_is_locked(ce->timeline);
> > +
> > + return __i915_request_create_locked(ce);
> > +}
>
> I wonder if we really need to have such granularity? Leaving only
> i915_request_create_locked and removing __i915_request_create_locked would
> simplify little bit the code,
> I guess the cost of calling intel_context_assert_timeline_is_locked twice
> sometimes is not big, or maybe it can be re-arranged, up to you.
There is some usage of such granularity in patch 4. I am adding
here the throttle on the timeline. I am adding it in the
"_locked" version to avoid potential deadlocks coming from
selftests (and from realworld?).
Here I'd love to have some comments from Chris and Matt.
I might still add this in the commit message:
"i915_request_create_locked() is now empty but will be used in
later commits where a throttle on the ringspace will be executed
to ensure exclusive ownership of the timeline."
> Reviewed-by: Andrzej Hajda
Thanks!
Andi
Re: [Intel-gfx] [PATCH v5 3/5] drm/i915: Create the locked version of the request add
Hi Andrzej, On Wed, Apr 12, 2023 at 03:06:42PM +0200, Andrzej Hajda wrote: > On 12.04.2023 13:33, Andi Shyti wrote: > > i915_request_add() assumes that the timeline is locked whtn the > *when > > function is called. Before exiting it releases the lock. But in > > the next commit we have one case where releasing the timeline > > mutex is not necessary and we don't want that. > > > > Make a new i915_request_add_locked() version of the function > > where the lock is not released. > > > > Signed-off-by: Andi Shyti > > Cc: sta...@vger.kernel.org > > Have you looked for other potential users of these new helpers? not yet, will do! > Reviewed-by: Andrzej Hajda Thanks! Andi
[Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
From: Paulo Zanoni
In multitile systems IRQ need to be reset and enabled per GT.
Although in MTL the GUnit misc interrupts register set are
available only in GT-0, we need to loop through all the GT's
in order to initialize the media engine which lies on a different
GT.
Signed-off-by: Paulo Zanoni
Cc: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
proposing again this patch, apparently GuC needs this patch to
initialize the media GT.
Andi
Changelog
=
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d24bdea65a3dc..524d64bf5d186 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2764,14 +2764,19 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
- gen11_display_irq_reset(dev_priv);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_reset(gt);
- GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
- GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ uncore = gt->uncore;
+ GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+ GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ }
+
+ gen11_display_irq_reset(dev_priv);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3425,13 +3430,16 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_postinstall(gt);
- GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+ GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+ }
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3440,8 +3448,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(uncore->regs);
- intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
+ intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
--
2.39.2
Re: [Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
Am 13.04.23 um 10:48 schrieb Daniel Vetter:
On Wed, 12 Apr 2023 at 16:18, Christian König wrote:
Am 12.04.23 um 11:08 schrieb Daniel Vetter:
On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote:
On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote:
Am 11.04.23 um 11:51 schrieb Daniel Vetter:
On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote:
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 gigantic pages.
Looking forward to when we might be able to swap out PMD size folios
without splitting, this will also be a benefit.
v2:
- Include all orders up to the PMD size (Christian König)
v3:
- Avoid compilation errors for architectures with special PFN_SHIFTs
Signed-off-by: Thomas Hellström
Reviewed-by: Christian König
Apparently this fails on ppc build testing. Please supply build fix asap
(or I guess we need to revert). I'm kinda not clear why this only showed
up when I merged the drm-misc-next pr into drm-next ...
I'm really wondering this as well. It looks like PMD_SHIFT isn't a constant
on this particular platform.
But from what I can find in the upstream 6.2 kernel PMD_SHIFT always seems
to be a constant.
So how exactly can that here break?
There's some in-flight patches to rework MAX_ORDER and other things in
linux-next, maybe it's recent? If you check out linux-next then you need
to reapply the patch (since sfr reverted it).
So I looked and on ppc64 PMD_SHIFT is defined in terms of
PTE_INDEX_SIZE, which is defined (for book3s) in terms of the variable
__pte_index_size. This is in 6.3 already and seems pretty old.
Ah! I missed that one, thanks.
So revert? Or fixup patch to make this work on ppc?
I think for now just revert or change it so that we check if PMD_SHIFT
is a constant.
Thomas do you have any quick solution?
I guess Thomas is on vacations. Can you pls do the revert and push it
to drm-misc-next-fixes so this won't get lost?
The offending patch hasn't showed up in drm-misc-next-fixes nor
drm-misc-fixes yet. Looks like the branches are lacking behind.
I can revert it on drm-misc-next, but I', not 100% sure that will then
get picked up in time.
Christian.
Acked-by: Daniel Vetter
preemptively for that. Normally I think we could wait a bit more but
it's really close to merge window PR and I don't like handing too many
open things to Dave when he's back :-)
-Daniel
Christian.
---
drivers/gpu/drm/ttm/ttm_pool.c | 30 +++---
1 file changed, 19 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_pool.c b/drivers/gpu/drm/ttm/ttm_pool.c
index dfce896c4bae..18c342a919a2 100644
--- a/drivers/gpu/drm/ttm/ttm_pool.c
+++ b/drivers/gpu/drm/ttm/ttm_pool.c
@@ -47,6 +47,11 @@
#include "ttm_module.h"
+#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT)
+#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1)
+/* Some architectures have a weird PMD_SHIFT */
+#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? __TTM_DIM_ORDER :
MAX_ORDER)
+
/**
* struct ttm_pool_dma - Helper object for coherent DMA mappings
*
@@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644);
static atomic_long_t allocated_pages;
-static struct ttm_pool_type global_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_uncached[MAX_ORDER];
+static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_uncached[TTM_DIM_ORDER];
-static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER];
-static struct ttm_pool_type global_dma32_uncached[MAX_ORDER];
+static struct ttm_pool_type global_dma32_write_combined[TTM_DIM_ORDER];
+static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER];
static spinlock_t shrinker_lock;
static struct list_head shrinker_list;
@@ -444,7 +449,7 @@ int ttm_pool_alloc(struct ttm_pool *pool, struct ttm_tt *tt,
else
gfp_flags |= GFP_HIGHUSER;
- for (order = min_t(unsigned int, MAX_ORDER - 1, __fls(num_pages));
+ for (order = min_t(unsigned int, TTM_MAX_ORDER, __fls(num_pages));
num_pages;
order = min_t(unsigned int, order, __fls(num_pages))) {
struct ttm_pool_type *pt;
@@ -563,7 +568,7 @@ void ttm_pool_init(struct ttm_pool *pool, struct device
*dev,
if (use_dma_alloc) {
for (i = 0; i < TTM_NUM_CACHING_TYPES; ++i)
- for (j = 0; j < MAX_ORDER; ++j)
+ for (j = 0; j < TTM_DIM_ORDER; ++j)
ttm_pool_type_init(&pool->caching[i].orders[j],
pool, i, j);
}
@@ -583,7 +588,7 @@ void ttm_pool_fini(struct ttm_pool *pool)
if (pool->use_dma_a
[Intel-gfx] [PATCH 00/10] drm/i915/display: split out high level display entry points
Add intel_display_driver.[ch] and move the high level display code entry points there. Also split out intel_display_reset.[ch]. And declutter intel_display.c by nearly 700 lines. BR, Jani. Jani Nikula (10): drm/i915/display: remove intel_display_commit_duplicated_state() drm/i915/display: start high level display driver file drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch] drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer() drm/i915/display: move modeset probe/remove functions to intel_display_driver.c drm/i915/display: rename intel_display_driver_* functions drm/i915/display: add intel_display_reset.[ch] drm/i915/display: move display suspend/resume to intel_display_driver.[ch] drm/i915/display: rename intel_display_driver_suspend/resume functions drm/i915/display: add intel_display_driver_early_probe() drivers/gpu/drm/i915/Makefile | 2 + drivers/gpu/drm/i915/display/intel_display.c | 691 +- drivers/gpu/drm/i915/display/intel_display.h | 31 +- .../drm/i915/display/intel_display_driver.c | 581 +++ .../drm/i915/display/intel_display_driver.h | 36 + .../drm/i915/display/intel_display_reset.c| 135 .../drm/i915/display/intel_display_reset.h| 14 + drivers/gpu/drm/i915/gt/intel_reset.c | 6 +- drivers/gpu/drm/i915/i915_driver.c| 30 +- drivers/gpu/drm/i915/i915_pci.c | 3 +- 10 files changed, 816 insertions(+), 713 deletions(-) create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.c create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.h create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.c create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.h -- 2.39.2
[Intel-gfx] [PATCH 01/10] drm/i915/display: remove intel_display_commit_duplicated_state()
This seems like an unnecessary wrapper layer. Removing it will be
helpful later.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
1 file changed, 10 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 27b47680573a..1c0149adcf49 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -701,20 +701,6 @@ intel_plane_fence_y_offset(const struct intel_plane_state
*plane_state)
return y;
}
-static int
-intel_display_commit_duplicated_state(struct intel_atomic_state *state,
- struct drm_modeset_acquire_ctx *ctx)
-{
- struct drm_i915_private *i915 = to_i915(state->base.dev);
- int ret;
-
- ret = drm_atomic_helper_commit_duplicated_state(&state->base, ctx);
-
- drm_WARN_ON(&i915->drm, ret == -EDEADLK);
-
- return ret;
-}
-
static int
__intel_display_resume(struct drm_i915_private *i915,
struct drm_atomic_state *state,
@@ -722,7 +708,7 @@ __intel_display_resume(struct drm_i915_private *i915,
{
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
- int i;
+ int ret, i;
intel_modeset_setup_hw_state(i915, ctx);
intel_vga_redisable(i915);
@@ -748,7 +734,11 @@ __intel_display_resume(struct drm_i915_private *i915,
if (!HAS_GMCH(i915))
to_intel_atomic_state(state)->skip_intermediate_wm = true;
- return
intel_display_commit_duplicated_state(to_intel_atomic_state(state), ctx);
+ ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
+
+ drm_WARN_ON(&i915->drm, ret == -EDEADLK);
+
+ return ret;
}
static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
@@ -839,10 +829,12 @@ void intel_display_finish_reset(struct drm_i915_private
*i915)
/* reset doesn't touch the display */
if (!gpu_reset_clobbers_display(i915)) {
/* for testing only restore the display */
- ret =
intel_display_commit_duplicated_state(to_intel_atomic_state(state), ctx);
- if (ret)
+ ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
+ if (ret) {
+ drm_WARN_ON(&i915->drm, ret == -EDEADLK);
drm_err(&i915->drm,
"Restoring old state failed with %i\n", ret);
+ }
} else {
/*
* The display has been reset as well,
--
2.39.2
[Intel-gfx] [PATCH 02/10] drm/i915/display: start high level display driver file
The only way to truly clean up intel_display.[ch] is to move stuff out
of them until there's absolutely nothing left.
Start moving the high level display driver entry points, i.e. functions
called from top level driver code only, to a new file, which we'll call
intel_display_driver.c. The intention is that there's no low-level
display code or details here. This is an in-between layer.
Initially, move intel_display_driver_register() and
intel_display_driver_unregister() there.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 53 --
drivers/gpu/drm/i915/display/intel_display.h | 3 -
.../drm/i915/display/intel_display_driver.c | 71 +++
.../drm/i915/display/intel_display_driver.h | 15
drivers/gpu/drm/i915/i915_driver.c| 1 +
6 files changed, 88 insertions(+), 56 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.c
create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 97b0d4ae221a..91f0c214ef28 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -237,6 +237,7 @@ i915-y += \
display/intel_crtc_state_dump.o \
display/intel_cursor.o \
display/intel_display.o \
+ display/intel_display_driver.o \
display/intel_display_power.o \
display/intel_display_power_map.o \
display/intel_display_power_well.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1c0149adcf49..7c66b9ce0db5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -32,7 +32,6 @@
#include
#include
#include
-#include
#include
#include
@@ -70,7 +69,6 @@
#include "intel_crtc_state_dump.h"
#include "intel_ddi.h"
#include "intel_de.h"
-#include "intel_display_debugfs.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dmc.h"
@@ -8833,57 +8831,6 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
return false;
}
-void intel_display_driver_register(struct drm_i915_private *i915)
-{
- if (!HAS_DISPLAY(i915))
- return;
-
- /* Must be done after probing outputs */
- intel_opregion_register(i915);
- intel_acpi_video_register(i915);
-
- intel_audio_init(i915);
-
- intel_display_debugfs_register(i915);
-
- /*
-* Some ports require correctly set-up hpd registers for
-* detection to work properly (leading to ghost connected
-* connector status), e.g. VGA on gm45. Hence we can only set
-* up the initial fbdev config after hpd irqs are fully
-* enabled. We do it last so that the async config cannot run
-* before the connectors are registered.
-*/
- intel_fbdev_initial_config_async(i915);
-
- /*
-* We need to coordinate the hotplugs with the asynchronous
-* fbdev configuration, for which we use the
-* fbdev->async_cookie.
-*/
- drm_kms_helper_poll_init(&i915->drm);
-}
-
-void intel_display_driver_unregister(struct drm_i915_private *i915)
-{
- if (!HAS_DISPLAY(i915))
- return;
-
- intel_fbdev_unregister(i915);
- intel_audio_deinit(i915);
-
- /*
-* After flushing the fbdev (incl. a late async config which
-* will have delayed queuing of a hotplug event), then flush
-* the hotplug events.
-*/
- drm_kms_helper_poll_fini(&i915->drm);
- drm_atomic_helper_shutdown(&i915->drm);
-
- acpi_video_unregister();
- intel_opregion_unregister(i915);
-}
-
bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 6 && i915_vtd_active(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 287159bdeb0d..e46732d26b7c 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -518,9 +518,6 @@ void intel_set_plane_visible(struct intel_crtc_state
*crtc_state,
bool visible);
void intel_plane_fixup_bitmasks(struct intel_crtc_state *crtc_state);
-void intel_display_driver_register(struct drm_i915_private *i915);
-void intel_display_driver_unregister(struct drm_i915_private *i915);
-
void intel_update_watermarks(struct drm_i915_private *i915);
/* modesetting */
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
new file mode 100644
index ..d4a1893e9218
--- /dev/null
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -0,0 +1,71 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022-2023 Intel Corporation
+ *
+ * High leve
[Intel-gfx] [PATCH 03/10] drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch]
High level display functionality only called from driver top level code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 23 ---
drivers/gpu/drm/i915/display/intel_display.h | 1 -
.../drm/i915/display/intel_display_driver.c | 23 +++
.../drm/i915/display/intel_display_driver.h | 4
drivers/gpu/drm/i915/i915_pci.c | 1 +
5 files changed, 28 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7c66b9ce0db5..dfec17bb3a7a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -31,7 +31,6 @@
#include
#include
#include
-#include
#include
#include
@@ -40,7 +39,6 @@
#include
#include
#include
-#include
#include
#include
@@ -8810,27 +8808,6 @@ void intel_modeset_driver_remove_nogem(struct
drm_i915_private *i915)
intel_bios_driver_remove(i915);
}
-bool intel_modeset_probe_defer(struct pci_dev *pdev)
-{
- struct drm_privacy_screen *privacy_screen;
-
- /*
-* apple-gmux is needed on dual GPU MacBook Pro
-* to probe the panel if we're the inactive GPU.
-*/
- if (vga_switcheroo_client_probe_defer(pdev))
- return true;
-
- /* If the LCD panel has a privacy-screen, wait for it */
- privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
- if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
- return true;
-
- drm_privacy_screen_put(privacy_screen);
-
- return false;
-}
-
bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915)
{
return DISPLAY_VER(i915) >= 6 && i915_vtd_active(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e46732d26b7c..6ff8faa1b5ac 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -521,7 +521,6 @@ void intel_plane_fixup_bitmasks(struct intel_crtc_state
*crtc_state);
void intel_update_watermarks(struct drm_i915_private *i915);
/* modesetting */
-bool intel_modeset_probe_defer(struct pci_dev *pdev);
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init_noirq(struct drm_i915_private *i915);
int intel_modeset_init_nogem(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index d4a1893e9218..1386f2001613 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -7,8 +7,10 @@
* details here.
*/
+#include
#include
#include
+#include
#include
#include "i915_drv.h"
@@ -19,6 +21,27 @@
#include "intel_fbdev.h"
#include "intel_opregion.h"
+bool intel_modeset_probe_defer(struct pci_dev *pdev)
+{
+ struct drm_privacy_screen *privacy_screen;
+
+ /*
+* apple-gmux is needed on dual GPU MacBook Pro
+* to probe the panel if we're the inactive GPU.
+*/
+ if (vga_switcheroo_client_probe_defer(pdev))
+ return true;
+
+ /* If the LCD panel has a privacy-screen, wait for it */
+ privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
+ if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
+ return true;
+
+ drm_privacy_screen_put(privacy_screen);
+
+ return false;
+}
+
void intel_display_driver_register(struct drm_i915_private *i915)
{
if (!HAS_DISPLAY(i915))
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
b/drivers/gpu/drm/i915/display/intel_display_driver.h
index 4f6deef5a23f..4c18792fcafd 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.h
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
@@ -6,8 +6,12 @@
#ifndef __INTEL_DISPLAY_DRIVER_H__
#define __INTEL_DISPLAY_DRIVER_H__
+#include
+
struct drm_i915_private;
+struct pci_dev;
+bool intel_modeset_probe_defer(struct pci_dev *pdev);
void intel_display_driver_register(struct drm_i915_private *i915);
void intel_display_driver_unregister(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cddb6e197972..bda5caa33f12 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -27,6 +27,7 @@
#include
#include "display/intel_display.h"
+#include "display/intel_display_driver.h"
#include "gt/intel_gt_regs.h"
#include "gt/intel_sa_media.h"
--
2.39.2
[Intel-gfx] [PATCH 04/10] drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer()
Follow the usual naming conventions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display_driver.c | 2 +-
drivers/gpu/drm/i915/display/intel_display_driver.h | 2 +-
drivers/gpu/drm/i915/i915_pci.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index 1386f2001613..882a2586aba4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -21,7 +21,7 @@
#include "intel_fbdev.h"
#include "intel_opregion.h"
-bool intel_modeset_probe_defer(struct pci_dev *pdev)
+bool intel_display_driver_probe_defer(struct pci_dev *pdev)
{
struct drm_privacy_screen *privacy_screen;
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
b/drivers/gpu/drm/i915/display/intel_display_driver.h
index 4c18792fcafd..744117b04ed4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.h
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
@@ -11,7 +11,7 @@
struct drm_i915_private;
struct pci_dev;
-bool intel_modeset_probe_defer(struct pci_dev *pdev);
+bool intel_display_driver_probe_defer(struct pci_dev *pdev);
void intel_display_driver_register(struct drm_i915_private *i915);
void intel_display_driver_unregister(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index bda5caa33f12..d64e074d7457 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1355,7 +1355,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
return -ENXIO;
/* Detect if we need to wait for other drivers early on */
- if (intel_modeset_probe_defer(pdev))
+ if (intel_display_driver_probe_defer(pdev))
return -EPROBE_DEFER;
err = i915_driver_probe(pdev, ent);
--
2.39.2
[Intel-gfx] [PATCH 05/10] drm/i915/display: move modeset probe/remove functions to intel_display_driver.c
High level display functionality only called from driver top level code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 373 +
drivers/gpu/drm/i915/display/intel_display.h | 23 +-
.../drm/i915/display/intel_display_driver.c | 374 ++
.../drm/i915/display/intel_display_driver.h | 7 +
4 files changed, 408 insertions(+), 369 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index dfec17bb3a7a..56e3aab7e1c6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -54,7 +54,6 @@
#include "i9xx_plane.h"
#include "i9xx_wm.h"
#include "icl_dsi.h"
-#include "intel_acpi.h"
#include "intel_atomic.h"
#include "intel_atomic_plane.h"
#include "intel_audio.h"
@@ -67,6 +66,7 @@
#include "intel_crtc_state_dump.h"
#include "intel_ddi.h"
#include "intel_de.h"
+#include "intel_display_driver.h"
#include "intel_display_power.h"
#include "intel_display_types.h"
#include "intel_dmc.h"
@@ -86,11 +86,8 @@
#include "intel_fdi.h"
#include "intel_fifo_underrun.h"
#include "intel_frontbuffer.h"
-#include "intel_gmbus.h"
-#include "intel_hdcp.h"
#include "intel_hdmi.h"
#include "intel_hotplug.h"
-#include "intel_hti.h"
#include "intel_lvds.h"
#include "intel_lvds_regs.h"
#include "intel_modeset_setup.h"
@@ -104,7 +101,6 @@
#include "intel_plane_initial.h"
#include "intel_pps.h"
#include "intel_psr.h"
-#include "intel_quirks.h"
#include "intel_sdvo.h"
#include "intel_snps_phy.h"
#include "intel_tc.h"
@@ -174,7 +170,7 @@ int vlv_get_cck_clock_hpll(struct drm_i915_private
*dev_priv,
return hpll;
}
-static void intel_update_czclk(struct drm_i915_private *dev_priv)
+void intel_update_czclk(struct drm_i915_private *dev_priv)
{
if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
return;
@@ -2582,7 +2578,7 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
0x8);
}
-static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
+void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
{
/*
* There may be no VBT; and if the BIOS enabled SSC we can
@@ -7225,7 +7221,7 @@ static void intel_atomic_helper_free_state(struct
drm_i915_private *dev_priv)
drm_atomic_state_put(&state->base);
}
-static void intel_atomic_helper_free_state_worker(struct work_struct *work)
+void intel_atomic_helper_free_state_worker(struct work_struct *work)
{
struct drm_i915_private *dev_priv =
container_of(work, typeof(*dev_priv),
display.atomic_helper.free_work);
@@ -7573,9 +7569,8 @@ static void intel_atomic_track_fbs(struct
intel_atomic_state *state)
plane->frontbuffer_bit);
}
-static int intel_atomic_commit(struct drm_device *dev,
- struct drm_atomic_state *_state,
- bool nonblock)
+int intel_atomic_commit(struct drm_device *dev, struct drm_atomic_state
*_state,
+ bool nonblock)
{
struct intel_atomic_state *state = to_intel_atomic_state(_state);
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -7677,19 +7672,6 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
}
-static void intel_plane_possible_crtcs_init(struct drm_i915_private *dev_priv)
-{
- struct intel_plane *plane;
-
- for_each_intel_plane(&dev_priv->drm, plane) {
- struct intel_crtc *crtc = intel_crtc_for_pipe(dev_priv,
- plane->pipe);
-
- plane->base.possible_crtcs = drm_crtc_mask(&crtc->base);
- }
-}
-
-
int intel_get_pipe_from_crtc_id_ioctl(struct drm_device *dev, void *data,
struct drm_file *file)
{
@@ -7769,7 +7751,7 @@ static bool intel_ddi_crt_present(struct drm_i915_private
*dev_priv)
return true;
}
-static void intel_setup_outputs(struct drm_i915_private *dev_priv)
+void intel_setup_outputs(struct drm_i915_private *dev_priv)
{
struct intel_encoder *encoder;
bool dpd_is_edp = false;
@@ -8021,9 +8003,8 @@ static int max_dotclock(struct drm_i915_private *i915)
return max_dotclock;
}
-static enum drm_mode_status
-intel_mode_valid(struct drm_device *dev,
-const struct drm_display_mode *mode)
+enum drm_mode_status intel_mode_valid(struct drm_device *dev,
+ const struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = to_i915(dev);
int hdisplay_max, htotal_max;
@@ -8163,18 +8144,6 @@ intel_mode_valid_max_plane_size(struct drm_i915_private
*dev_priv,
return MODE_OK;
}
-static const struct drm_mode_config_funcs intel_mode_funcs = {
- .fb_create = intel_user_framebuffe
[Intel-gfx] [PATCH 06/10] drm/i915/display: rename intel_display_driver_* functions
Follow the usual naming conventions.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 +-
.../drm/i915/display/intel_display_driver.c | 16 +++---
.../drm/i915/display/intel_display_driver.h | 14 ++---
drivers/gpu/drm/i915/i915_driver.c| 21 ++-
4 files changed, 27 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 56e3aab7e1c6..f425e5ed155b 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -833,7 +833,7 @@ void intel_display_finish_reset(struct drm_i915_private
*i915)
* so need a full re-initialization.
*/
intel_pps_unlock_regs_wa(i915);
- intel_modeset_init_hw(i915);
+ intel_display_driver_init_hw(i915);
intel_clock_gating_init(i915);
intel_hpd_init(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index f7805c6f1b63..45e425100385 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -72,7 +72,7 @@ bool intel_display_driver_probe_defer(struct pci_dev *pdev)
return false;
}
-void intel_modeset_init_hw(struct drm_i915_private *i915)
+void intel_display_driver_init_hw(struct drm_i915_private *i915)
{
struct intel_cdclk_state *cdclk_state;
@@ -170,7 +170,7 @@ static void intel_plane_possible_crtcs_init(struct
drm_i915_private *dev_priv)
}
/* part #1: call before irq install */
-int intel_modeset_init_noirq(struct drm_i915_private *i915)
+int intel_display_driver_probe_noirq(struct drm_i915_private *i915)
{
int ret;
@@ -246,7 +246,7 @@ int intel_modeset_init_noirq(struct drm_i915_private *i915)
}
/* part #2: call after irq install, but before gem init */
-int intel_modeset_init_nogem(struct drm_i915_private *i915)
+int intel_display_driver_probe_nogem(struct drm_i915_private *i915)
{
struct drm_device *dev = &i915->drm;
enum pipe pipe;
@@ -281,7 +281,7 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915)
intel_fdi_pll_freq_update(i915);
intel_update_czclk(i915);
- intel_modeset_init_hw(i915);
+ intel_display_driver_init_hw(i915);
intel_dpll_update_ref_clks(i915);
intel_hdcp_component_init(i915);
@@ -318,7 +318,7 @@ int intel_modeset_init_nogem(struct drm_i915_private *i915)
}
/* part #3: call after gem init */
-int intel_modeset_init(struct drm_i915_private *i915)
+int intel_display_driver_probe(struct drm_i915_private *i915)
{
int ret;
@@ -382,7 +382,7 @@ void intel_display_driver_register(struct drm_i915_private
*i915)
}
/* part #1: call before irq uninstall */
-void intel_modeset_driver_remove(struct drm_i915_private *i915)
+void intel_display_driver_remove(struct drm_i915_private *i915)
{
if (!HAS_DISPLAY(i915))
return;
@@ -402,7 +402,7 @@ void intel_modeset_driver_remove(struct drm_i915_private
*i915)
}
/* part #2: call after irq uninstall */
-void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915)
+void intel_display_driver_remove_noirq(struct drm_i915_private *i915)
{
if (!HAS_DISPLAY(i915))
return;
@@ -436,7 +436,7 @@ void intel_modeset_driver_remove_noirq(struct
drm_i915_private *i915)
}
/* part #3: call after gem init */
-void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915)
+void intel_display_driver_remove_nogem(struct drm_i915_private *i915)
{
intel_dmc_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
b/drivers/gpu/drm/i915/display/intel_display_driver.h
index 947b666575ee..aab498617b90 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.h
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
@@ -12,14 +12,14 @@ struct drm_i915_private;
struct pci_dev;
bool intel_display_driver_probe_defer(struct pci_dev *pdev);
-void intel_modeset_init_hw(struct drm_i915_private *i915);
-int intel_modeset_init_noirq(struct drm_i915_private *i915);
-int intel_modeset_init_nogem(struct drm_i915_private *i915);
-int intel_modeset_init(struct drm_i915_private *i915);
+void intel_display_driver_init_hw(struct drm_i915_private *i915);
+int intel_display_driver_probe_noirq(struct drm_i915_private *i915);
+int intel_display_driver_probe_nogem(struct drm_i915_private *i915);
+int intel_display_driver_probe(struct drm_i915_private *i915);
void intel_display_driver_register(struct drm_i915_private *i915);
-void intel_modeset_driver_remove(struct drm_i915_private *i915);
-void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915);
-void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915);
+void intel_display_driver_remove(stru
[Intel-gfx] [PATCH 07/10] drm/i915/display: add intel_display_reset.[ch]
Split out the display reset functionality to a separate file to
declutter intel_display.c. Rename the functions accordingly. The minor
downside is having to expose __intel_display_resume().
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/display/intel_display.c | 123 +---
drivers/gpu/drm/i915/display/intel_display.h | 8 +-
.../drm/i915/display/intel_display_reset.c| 135 ++
.../drm/i915/display/intel_display_reset.h| 14 ++
drivers/gpu/drm/i915/gt/intel_reset.c | 6 +-
6 files changed, 160 insertions(+), 127 deletions(-)
create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.c
create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 91f0c214ef28..39e22cf85e55 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -241,6 +241,7 @@ i915-y += \
display/intel_display_power.o \
display/intel_display_power_map.o \
display/intel_display_power_well.o \
+ display/intel_display_reset.o \
display/intel_display_rps.o \
display/intel_dmc.o \
display/intel_dpio_phy.o \
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f425e5ed155b..e89e9473a744 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -693,7 +693,7 @@ intel_plane_fence_y_offset(const struct intel_plane_state
*plane_state)
return y;
}
-static int
+int
__intel_display_resume(struct drm_i915_private *i915,
struct drm_atomic_state *state,
struct drm_modeset_acquire_ctx *ctx)
@@ -733,127 +733,6 @@ __intel_display_resume(struct drm_i915_private *i915,
return ret;
}
-static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
-{
- return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
- intel_has_gpu_reset(to_gt(dev_priv)));
-}
-
-void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
-{
- struct drm_modeset_acquire_ctx *ctx =
&dev_priv->display.restore.reset_ctx;
- struct drm_atomic_state *state;
- int ret;
-
- if (!HAS_DISPLAY(dev_priv))
- return;
-
- /* reset doesn't touch the display */
- if (!dev_priv->params.force_reset_modeset_test &&
- !gpu_reset_clobbers_display(dev_priv))
- return;
-
- /* We have a modeset vs reset deadlock, defensively unbreak it. */
- set_bit(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags);
- smp_mb__after_atomic();
- wake_up_bit(&to_gt(dev_priv)->reset.flags, I915_RESET_MODESET);
-
- if (atomic_read(&dev_priv->gpu_error.pending_fb_pin)) {
- drm_dbg_kms(&dev_priv->drm,
- "Modeset potentially stuck, unbreaking through
wedging\n");
- intel_gt_set_wedged(to_gt(dev_priv));
- }
-
- /*
-* Need mode_config.mutex so that we don't
-* trample ongoing ->detect() and whatnot.
-*/
- mutex_lock(&dev_priv->drm.mode_config.mutex);
- drm_modeset_acquire_init(ctx, 0);
- while (1) {
- ret = drm_modeset_lock_all_ctx(&dev_priv->drm, ctx);
- if (ret != -EDEADLK)
- break;
-
- drm_modeset_backoff(ctx);
- }
- /*
-* Disabling the crtcs gracefully seems nicer. Also the
-* g33 docs say we should at least disable all the planes.
-*/
- state = drm_atomic_helper_duplicate_state(&dev_priv->drm, ctx);
- if (IS_ERR(state)) {
- ret = PTR_ERR(state);
- drm_err(&dev_priv->drm, "Duplicating state failed with %i\n",
- ret);
- return;
- }
-
- ret = drm_atomic_helper_disable_all(&dev_priv->drm, ctx);
- if (ret) {
- drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
- ret);
- drm_atomic_state_put(state);
- return;
- }
-
- dev_priv->display.restore.modeset_state = state;
- state->acquire_ctx = ctx;
-}
-
-void intel_display_finish_reset(struct drm_i915_private *i915)
-{
- struct drm_modeset_acquire_ctx *ctx = &i915->display.restore.reset_ctx;
- struct drm_atomic_state *state;
- int ret;
-
- if (!HAS_DISPLAY(i915))
- return;
-
- /* reset doesn't touch the display */
- if (!test_bit(I915_RESET_MODESET, &to_gt(i915)->reset.flags))
- return;
-
- state = fetch_and_zero(&i915->display.restore.modeset_state);
- if (!state)
- goto unlock;
-
- /* reset doesn't touch the display */
- if (!gpu_reset_clobbers_display(i915)) {
- /* for testing on
[Intel-gfx] [PATCH 08/10] drm/i915/display: move display suspend/resume to intel_display_driver.[ch]
High level display functionality only called from driver top level code.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 102 --
drivers/gpu/drm/i915/display/intel_display.h | 8 --
.../drm/i915/display/intel_display_driver.c | 101 +
.../drm/i915/display/intel_display_driver.h | 10 ++
4 files changed, 111 insertions(+), 110 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index e89e9473a744..9eb9898885bb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -693,46 +693,6 @@ intel_plane_fence_y_offset(const struct intel_plane_state
*plane_state)
return y;
}
-int
-__intel_display_resume(struct drm_i915_private *i915,
- struct drm_atomic_state *state,
- struct drm_modeset_acquire_ctx *ctx)
-{
- struct drm_crtc_state *crtc_state;
- struct drm_crtc *crtc;
- int ret, i;
-
- intel_modeset_setup_hw_state(i915, ctx);
- intel_vga_redisable(i915);
-
- if (!state)
- return 0;
-
- /*
-* We've duplicated the state, pointers to the old state are invalid.
-*
-* Don't attempt to use the old state until we commit the duplicated
state.
-*/
- for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
- /*
-* Force recalculation even if we restore
-* current state. With fast modeset this may not result
-* in a modeset when the state is compatible.
-*/
- crtc_state->mode_changed = true;
- }
-
- /* ignore any reset values/BIOS leftovers in the WM registers */
- if (!HAS_GMCH(i915))
- to_intel_atomic_state(state)->skip_intermediate_wm = true;
-
- ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
-
- drm_WARN_ON(&i915->drm, ret == -EDEADLK);
-
- return ret;
-}
-
static void icl_set_pipe_chicken(const struct intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
@@ -2104,30 +2064,6 @@ static void i9xx_crtc_disable(struct intel_atomic_state
*state,
i830_enable_pipe(dev_priv, pipe);
}
-
-/*
- * turn all crtc's off, but do not adjust state
- * This has to be paired with a call to intel_modeset_setup_hw_state.
- */
-int intel_display_suspend(struct drm_device *dev)
-{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct drm_atomic_state *state;
- int ret;
-
- if (!HAS_DISPLAY(dev_priv))
- return 0;
-
- state = drm_atomic_helper_suspend(dev);
- ret = PTR_ERR_OR_ZERO(state);
- if (ret)
- drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
- ret);
- else
- dev_priv->display.restore.modeset_state = state;
- return ret;
-}
-
void intel_encoder_destroy(struct drm_encoder *encoder)
{
struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
@@ -8280,44 +8216,6 @@ void i830_disable_pipe(struct drm_i915_private
*dev_priv, enum pipe pipe)
intel_de_posting_read(dev_priv, DPLL(pipe));
}
-void intel_display_resume(struct drm_device *dev)
-{
- struct drm_i915_private *i915 = to_i915(dev);
- struct drm_atomic_state *state = i915->display.restore.modeset_state;
- struct drm_modeset_acquire_ctx ctx;
- int ret;
-
- if (!HAS_DISPLAY(i915))
- return;
-
- i915->display.restore.modeset_state = NULL;
- if (state)
- state->acquire_ctx = &ctx;
-
- drm_modeset_acquire_init(&ctx, 0);
-
- while (1) {
- ret = drm_modeset_lock_all_ctx(dev, &ctx);
- if (ret != -EDEADLK)
- break;
-
- drm_modeset_backoff(&ctx);
- }
-
- if (!ret)
- ret = __intel_display_resume(i915, state, &ctx);
-
- skl_watermark_ipc_update(i915);
- drm_modeset_drop_locks(&ctx);
- drm_modeset_acquire_fini(&ctx);
-
- if (ret)
- drm_err(&i915->drm,
- "Restoring old state failed with %i\n", ret);
- if (state)
- drm_atomic_state_put(state);
-}
-
void intel_hpd_poll_fini(struct drm_i915_private *i915)
{
struct intel_connector *connector;
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e5bf8ef8e06b..c7b1e220e84d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -438,7 +438,6 @@ void intel_add_fb_offsets(int *x, int *y,
unsigned int intel_rotation_info_size(const struct intel_rotation_info
*rot_info);
unsigned int intel_remapped_info_size(const struct intel_remapped_info
*rem_info);
bool intel_h
[Intel-gfx] [PATCH 09/10] drm/i915/display: rename intel_display_driver_suspend/resume functions
Follow the usual naming conventions. Switch to i915 arguments and naming
while at it.
Signed-off-by: Jani Nikula
---
.../drm/i915/display/intel_display_driver.c | 24 +--
.../drm/i915/display/intel_display_driver.h | 11 -
.../drm/i915/display/intel_display_reset.c| 2 +-
drivers/gpu/drm/i915/i915_driver.c| 6 ++---
4 files changed, 20 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index eb03b0a87d5a..d20a279fdf51 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -471,29 +471,28 @@ void intel_display_driver_unregister(struct
drm_i915_private *i915)
* turn all crtc's off, but do not adjust state
* This has to be paired with a call to intel_modeset_setup_hw_state.
*/
-int intel_display_suspend(struct drm_device *dev)
+int intel_display_driver_suspend(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
struct drm_atomic_state *state;
int ret;
- if (!HAS_DISPLAY(dev_priv))
+ if (!HAS_DISPLAY(i915))
return 0;
- state = drm_atomic_helper_suspend(dev);
+ state = drm_atomic_helper_suspend(&i915->drm);
ret = PTR_ERR_OR_ZERO(state);
if (ret)
- drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
+ drm_err(&i915->drm, "Suspending crtc's failed with %i\n",
ret);
else
- dev_priv->display.restore.modeset_state = state;
+ i915->display.restore.modeset_state = state;
return ret;
}
int
-__intel_display_resume(struct drm_i915_private *i915,
- struct drm_atomic_state *state,
- struct drm_modeset_acquire_ctx *ctx)
+__intel_display_driver_resume(struct drm_i915_private *i915,
+ struct drm_atomic_state *state,
+ struct drm_modeset_acquire_ctx *ctx)
{
struct drm_crtc_state *crtc_state;
struct drm_crtc *crtc;
@@ -530,9 +529,8 @@ __intel_display_resume(struct drm_i915_private *i915,
return ret;
}
-void intel_display_resume(struct drm_device *dev)
+void intel_display_driver_resume(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = to_i915(dev);
struct drm_atomic_state *state = i915->display.restore.modeset_state;
struct drm_modeset_acquire_ctx ctx;
int ret;
@@ -547,7 +545,7 @@ void intel_display_resume(struct drm_device *dev)
drm_modeset_acquire_init(&ctx, 0);
while (1) {
- ret = drm_modeset_lock_all_ctx(dev, &ctx);
+ ret = drm_modeset_lock_all_ctx(&i915->drm, &ctx);
if (ret != -EDEADLK)
break;
@@ -555,7 +553,7 @@ void intel_display_resume(struct drm_device *dev)
}
if (!ret)
- ret = __intel_display_resume(i915, state, &ctx);
+ ret = __intel_display_driver_resume(i915, state, &ctx);
skl_watermark_ipc_update(i915);
drm_modeset_drop_locks(&ctx);
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
b/drivers/gpu/drm/i915/display/intel_display_driver.h
index 7b5ff4309dec..84e7977f265a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.h
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
@@ -9,7 +9,6 @@
#include
struct drm_atomic_state;
-struct drm_device;
struct drm_i915_private;
struct drm_modeset_acquire_ctx;
struct pci_dev;
@@ -24,13 +23,13 @@ void intel_display_driver_remove(struct drm_i915_private
*i915);
void intel_display_driver_remove_noirq(struct drm_i915_private *i915);
void intel_display_driver_remove_nogem(struct drm_i915_private *i915);
void intel_display_driver_unregister(struct drm_i915_private *i915);
-int intel_display_suspend(struct drm_device *dev);
-void intel_display_resume(struct drm_device *dev);
+int intel_display_driver_suspend(struct drm_i915_private *i915);
+void intel_display_driver_resume(struct drm_i915_private *i915);
/* interface for intel_display_reset.c */
-int __intel_display_resume(struct drm_i915_private *i915,
- struct drm_atomic_state *state,
- struct drm_modeset_acquire_ctx *ctx);
+int __intel_display_driver_resume(struct drm_i915_private *i915,
+ struct drm_atomic_state *state,
+ struct drm_modeset_acquire_ctx *ctx);
#endif /* __INTEL_DISPLAY_DRIVER_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_reset.c
b/drivers/gpu/drm/i915/display/intel_display_reset.c
index 166aa0cab1fc..17178d5d7788 100644
--- a/drivers/gpu/drm/i915/display/intel_display_reset.c
+++ b/drivers/gpu/drm/i915/display/intel_display_reset.c
@@ -117,7 +117,7 @@ void intel_display_
[Intel-gfx] [PATCH 10/10] drm/i915/display: add intel_display_driver_early_probe()
Add intel_display_driver_early_probe() as the early probe call to
replace intel_init_display_hooks(). The latter will be "demoted" to
setting up hooks in intel_display.c only.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 11 ---
.../gpu/drm/i915/display/intel_display_driver.c| 14 ++
.../gpu/drm/i915/display/intel_display_driver.h| 1 +
drivers/gpu/drm/i915/i915_driver.c | 2 +-
4 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 9eb9898885bb..afc5bc38d006 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -8005,15 +8005,6 @@ static const struct intel_display_funcs
i9xx_display_funcs = {
*/
void intel_init_display_hooks(struct drm_i915_private *dev_priv)
{
- if (!HAS_DISPLAY(dev_priv))
- return;
-
- intel_color_init_hooks(dev_priv);
- intel_init_cdclk_hooks(dev_priv);
- intel_audio_hooks_init(dev_priv);
-
- intel_dpll_init_clock_hook(dev_priv);
-
if (DISPLAY_VER(dev_priv) >= 9) {
dev_priv->display.funcs.display = &skl_display_funcs;
} else if (HAS_DDI(dev_priv)) {
@@ -8026,8 +8017,6 @@ void intel_init_display_hooks(struct drm_i915_private
*dev_priv)
} else {
dev_priv->display.funcs.display = &i9xx_display_funcs;
}
-
- intel_fdi_init_hook(dev_priv);
}
int intel_initial_commit(struct drm_device *dev)
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
b/drivers/gpu/drm/i915/display/intel_display_driver.c
index d20a279fdf51..b3dbfe2a892e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.c
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
@@ -32,6 +32,7 @@
#include "intel_display_types.h"
#include "intel_dmc.h"
#include "intel_dp.h"
+#include "intel_dpll.h"
#include "intel_dpll_mgr.h"
#include "intel_fb.h"
#include "intel_fbc.h"
@@ -169,6 +170,19 @@ static void intel_plane_possible_crtcs_init(struct
drm_i915_private *dev_priv)
}
}
+void intel_display_driver_early_probe(struct drm_i915_private *i915)
+{
+ if (!HAS_DISPLAY(i915))
+ return;
+
+ intel_color_init_hooks(i915);
+ intel_init_cdclk_hooks(i915);
+ intel_audio_hooks_init(i915);
+ intel_dpll_init_clock_hook(i915);
+ intel_init_display_hooks(i915);
+ intel_fdi_init_hook(i915);
+}
+
/* part #1: call before irq install */
int intel_display_driver_probe_noirq(struct drm_i915_private *i915)
{
diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
b/drivers/gpu/drm/i915/display/intel_display_driver.h
index 84e7977f265a..c276a58ee329 100644
--- a/drivers/gpu/drm/i915/display/intel_display_driver.h
+++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
@@ -15,6 +15,7 @@ struct pci_dev;
bool intel_display_driver_probe_defer(struct pci_dev *pdev);
void intel_display_driver_init_hw(struct drm_i915_private *i915);
+void intel_display_driver_early_probe(struct drm_i915_private *i915);
int intel_display_driver_probe_noirq(struct drm_i915_private *i915);
int intel_display_driver_probe_nogem(struct drm_i915_private *i915);
int intel_display_driver_probe(struct drm_i915_private *i915);
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 082393ea3833..8a0a893443b4 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -252,7 +252,7 @@ static int i915_driver_early_probe(struct drm_i915_private
*dev_priv)
intel_detect_pch(dev_priv);
intel_irq_init(dev_priv);
- intel_init_display_hooks(dev_priv);
+ intel_display_driver_early_probe(dev_priv);
intel_clock_gating_hooks_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
--
2.39.2
Re: [Intel-gfx] [Intel-xe] [PATCH v3 1/6] drm/i915: Initialize dkl_phy spin lock from display code path
On Thu, 13 Apr 2023, Jani Nikula wrote: > On Wed, 12 Apr 2023, "Souza, Jose" wrote: >> The name is misleading but intel_modeset_init_noirq() is the first generic >> display initialization function called. >> There is other display functions called before it but they are very >> specific(intel_dram_detect(), intel_bw_init_hw() and >> intel_device_info_runtime_init()). > > See [1]. > > BR, > Jani. > > > [1] https://lore.kernel.org/r/87ile1cjh8@intel.com All of this is cleaned up in https://patchwork.freedesktop.org/series/116431/ BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915/mtl: Add support for PM DEMAND
On Wed, 12 Apr 2023, Jani Nikula wrote: > On Wed, 12 Apr 2023, Gustavo Sousa wrote: >> Quoting Jani Nikula (2023-04-12 06:33:54) >>> On Tue, 11 Apr 2023, Gustavo Sousa wrote: >>> > Quoting Mika Kahola (2023-04-03 05:50:43) >>> >> @@ -8250,6 +8259,7 @@ void intel_init_display_hooks(struct >>> >> drm_i915_private *dev_priv) >>> >> intel_color_init_hooks(dev_priv); >>> >> intel_init_cdclk_hooks(dev_priv); >>> >> intel_audio_hooks_init(dev_priv); >>> >> + intel_init_pmdemand(dev_priv); >>> > >>> > I think intel_init_display_hooks() is meant to call functions setting up >>> > function pointers, right? That would not be the case for >>> > intel_init_pmdemand(). >>> > >>> > I think we could rename intel_init_pmdemand() to >>> > intel_pmdemand_init_early() and call it inside i915_driver_early_probe(). >>> >>> Please let's not add new direct calls to display from top level driver >>> code. See also [1]. >> >> Okay. What would be the suggested place to do this SW-only initialization? >> >> Should we just merge the two init functions into one named >> intel_pmdemand_init() >> and call the new function under intel_modeset_init_noirq()? > > Or add a new function intel_display_early_probe() or somesuch, which > will call the early pmdemand init as well as intel_init_display_hooks() > that is currently called from i915_driver_early_probe(). > > Bottom line, there should only be one high level call from > i915_driver_early_probe(). > > There are similar needs for other things [1]. > > BR, > Jani. > > > [1] > https://lore.kernel.org/r/20230411195918.hdxyir5w7dp2q...@ldmartin-desk2.lan All of this is cleaned up in https://patchwork.freedesktop.org/series/116431/ BR, Jani. > > >> >> -- >> Gustavo Sousa -- Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [V2 1/1] drm/i915/debugfs: New debugfs for display clock frequencies
On Wed, 12 Apr 2023, Jani Nikula wrote:
> On Wed, 12 Apr 2023, Bhanuprakash Modem wrote:
>> Instead of mixing display & non-display stuff together, move
>> display specific clock info to new debugfs. This patch will
>> create a new debugfs "i915_cdclk_info" to expose Current & Max
>> cdclk and Max pixel clock frequency info.
>>
>> Example:
>> $ cat /sys/kernel/debug/dri/0/i915_cdclk_info
>> Current CD clock frequency: 163200 kHz
>> Max CD clock frequency: 652800 kHz
>> Max pixel clock frequency: 1305600 kHz
>>
>> V2: - s/i915_display_clock_info/i915_cdclk_info/ (Jani)
>> - Move the logic to intel_cdclk.c (Jani)
>> - Don't remove info from i915_frequency_info (Jani)
>>
>> Cc: Jani Nikula
>> Signed-off-by: Bhanuprakash Modem
>> ---
>> drivers/gpu/drm/i915/display/intel_cdclk.c| 25 +++
>> drivers/gpu/drm/i915/display/intel_cdclk.h| 1 +
>> .../drm/i915/display/intel_display_debugfs.c | 1 +
>> 3 files changed, 27 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> index 084a483f9776..c3ad7837fa09 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
>> @@ -3235,6 +3235,31 @@ u32 intel_read_rawclk(struct drm_i915_private
>> *dev_priv)
>> return freq;
>> }
>>
>> +static int i915_cdclk_info_show(struct seq_file *m, void *unused)
>> +{
>> +struct drm_i915_private *i915 = m->private;
>> +
>> +drm_modeset_lock_all(&i915->drm);
>
> Mmmh, I wonder how important that really is?
With the locking removed, this is
Reviewed-by: Jani Nikula
>
> BR,
> Jani.
>
>
>> +
>> +seq_printf(m, "Current CD clock frequency: %d kHz\n",
>> i915->display.cdclk.hw.cdclk);
>> +seq_printf(m, "Max CD clock frequency: %d kHz\n",
>> i915->display.cdclk.max_cdclk_freq);
>> +seq_printf(m, "Max pixel clock frequency: %d kHz\n",
>> i915->max_dotclk_freq);
>> +
>> +drm_modeset_unlock_all(&i915->drm);
>> +
>> +return 0;
>> +}
>> +
>> +DEFINE_SHOW_ATTRIBUTE(i915_cdclk_info);
>> +
>> +void intel_cdclk_debugfs_register(struct drm_i915_private *i915)
>> +{
>> +struct drm_minor *minor = i915->drm.primary;
>> +
>> +debugfs_create_file("i915_cdclk_info", 0444, minor->debugfs_root,
>> +i915, &i915_cdclk_info_fops);
>> +}
>> +
>> static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
>> .get_cdclk = bxt_get_cdclk,
>> .set_cdclk = bxt_set_cdclk,
>> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
>> b/drivers/gpu/drm/i915/display/intel_cdclk.h
>> index 51e2f6a11ce4..48fd7d39e0cd 100644
>> --- a/drivers/gpu/drm/i915/display/intel_cdclk.h
>> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
>> @@ -82,5 +82,6 @@ intel_atomic_get_cdclk_state(struct intel_atomic_state
>> *state);
>> to_intel_cdclk_state(intel_atomic_get_new_global_obj_state(state,
>> &to_i915(state->base.dev)->display.cdclk.obj))
>>
>> int intel_cdclk_init(struct drm_i915_private *dev_priv);
>> +void intel_cdclk_debugfs_register(struct drm_i915_private *i915);
>>
>> #endif /* __INTEL_CDCLK_H__ */
>> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> index 45113ae107ba..abd16a2b1f7a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
>> @@ -1094,6 +1094,7 @@ void intel_display_debugfs_register(struct
>> drm_i915_private *i915)
>> ARRAY_SIZE(intel_display_debugfs_list),
>> minor->debugfs_root, minor);
>>
>> +intel_cdclk_debugfs_register(i915);
>> intel_dmc_debugfs_register(i915);
>> intel_fbc_debugfs_register(i915);
>> intel_hpd_debugfs_register(i915);
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 13/04/2023 10:20, Andi Shyti wrote:
From: Paulo Zanoni
In multitile systems IRQ need to be reset and enabled per GT.
Although in MTL the GUnit misc interrupts register set are
available only in GT-0, we need to loop through all the GT's
in order to initialize the media engine which lies on a different
GT.
Signed-off-by: Paulo Zanoni
Cc: Tvrtko Ursulin
Signed-off-by: Andi Shyti
---
Hi,
proposing again this patch, apparently GuC needs this patch to
initialize the media GT.
What is the resolution for Matt's concern that this is wrong for MTL?
Regards,
Tvrtko
Changelog
=
v1 -> v2
- improve description in the commit log.
drivers/gpu/drm/i915/i915_irq.c | 28 ++--
1 file changed, 18 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index d24bdea65a3dc..524d64bf5d186 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2764,14 +2764,19 @@ static void dg1_irq_reset(struct drm_i915_private
*dev_priv)
{
struct intel_gt *gt = to_gt(dev_priv);
struct intel_uncore *uncore = gt->uncore;
+ unsigned int i;
dg1_master_intr_disable(dev_priv->uncore.regs);
- gen11_gt_irq_reset(gt);
- gen11_display_irq_reset(dev_priv);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_reset(gt);
- GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
- GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ uncore = gt->uncore;
+ GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
+ GEN3_IRQ_RESET(uncore, GEN8_PCU_);
+ }
+
+ gen11_display_irq_reset(dev_priv);
}
void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
@@ -3425,13 +3430,16 @@ static void gen11_irq_postinstall(struct
drm_i915_private *dev_priv)
static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
{
- struct intel_gt *gt = to_gt(dev_priv);
- struct intel_uncore *uncore = gt->uncore;
u32 gu_misc_masked = GEN11_GU_MISC_GSE;
+ struct intel_gt *gt;
+ unsigned int i;
- gen11_gt_irq_postinstall(gt);
+ for_each_gt(gt, dev_priv, i) {
+ gen11_gt_irq_postinstall(gt);
- GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
+ GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
+ gu_misc_masked);
+ }
if (HAS_DISPLAY(dev_priv)) {
icp_irq_postinstall(dev_priv);
@@ -3440,8 +3448,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
*dev_priv)
GEN11_DISPLAY_IRQ_ENABLE);
}
- dg1_master_intr_enable(uncore->regs);
- intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
+ dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
+ intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
}
static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
Re: [Intel-gfx] [PATCH] drm/i915: Flag purely internal commits to not clear crtc_state->inherited
On Tue, 2023-03-28 at 15:23 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > If we have to force the hardware to go through a full modeset > due to eg. cdclk reprogramming, we need to preserve > crtc_state->inherited for all crtcs that have not otherwise > gone through the whole compute_config() stuff after connectors > have been detected. > > Otherwise eg. cdclk induced modeset glk_force_audio_cdclk() > will clear the inherited flag, and thus the first real commit > coming from userspace later on will not be forced through > the full .compute_config() path and so eg. audio state may > not get properly recomputed. > > But instead of adding all kinds of ad-hoc crtc_state->inherited > preservation hacks all over, let's change things so that we > only clear it for the crtcs directly included in userspace/client > initiated commits. > > Should be far less fragile since now we just need to remember > to flag the internal commits, and not worry about where new > crtcs might get pulled in. > > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5260 > Signed-off-by: Ville Syrjälä > --- Looks good to me. Reviewed-by: Luca Coelho -- Cheers, Luca.
Re: [Intel-gfx] [PATCH v4 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 12/04/2023 14:10, Rodrigo Vivi wrote:
On Wed, Apr 12, 2023 at 12:56:26PM +0200, Andi Shyti wrote:
Hi Rodrigo,
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Try to find from which kernel version this needs to go in. For instance
if we look at cf586021642d80 it would be v5.15+, but actually in that
commit there are no users apart from selftests. So I think find the
first user which can be user facing and mark the appropriate kernel
version in the stable tag.
Reviewed-by: Matthew Auld
With Matt's comment regarding missing lock in intel_context_migrate_clear
addressed, this is:
Acked-by: Nirmoy Das
Nack!
Please get some ack from Joonas or Tvrtko before merging this series.
There is no architectural change... of course, Joonas and Tvrtko
are more than welcome (and actually invited) to look into this
patch.
And, btw, there are still some discussions ongoing on this whole
series, so that I'm not going to merge it any time soon. I'm just
happy to revive the discussion.
It is a big series targeting stable o.O where the revisions in the cover
letter are not helping me to be confident that this is the right approach
instead of simply reverting the original offending commit:
cf586021642d ("drm/i915/gt: Pipelined page migration")
Why should we remove all the migration completely? What about the
copy?
Is there any other alternative that doesn't hurt the Linux stable rules?
I honestly fail to see this one here is "obviously corrected and tested"
and it looks to me that it has more "than 100 lines, with context".
Does this series really "fix only one thing" with 5 patches?
This is challenging.
Fix to me looks needed on the high level (haven't read the patch details
yet), but when a series sent to stable can go quite badly and we had
such problem very recently with only a two patch series. And it is also
indeed quite large.
Reverting cf586021642d80 definitely isn't an option because stuff
depends on the code added by it and would need an alternative
implementation. Losing async clear/migrate which would be bad and could
also a large patch to implement the alternative.
So since I think we are indeed stuck with fixing this - would it be
better to squash it all into one patch for easier backporting?
We can also look if there are ways to make the diff smaller.
Regards,
Tvrtko
It looks to me that we are adding magic on top of magic to workaround
the deadlocks, but then adding more waits inside locks... And this with
the hang checks vs heartbeats, is this really an issue on current upstream
code? or was only on DII?
There is no real magic happening here. It's just that the error
message was not reaching the end of the operation while this
patch is passing it over.
Where was the bug report to start with?
Matt has reported this, I will give to you the necessary links to
it offline.
It would be really good to have a report to see if this is
"real bug that bothers people (not a, “This could be a problem…” type thing)."
All quotes above are from:
https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html
Thanks for looking into this,
Andi
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Make IRQ reset and postinstall multi-gt aware (rev2)
== Series Details == Series: drm/i915: Make IRQ reset and postinstall multi-gt aware (rev2) URL : https://patchwork.freedesktop.org/series/115465/ State : failure == Summary == CI Bug Log - changes from CI_DRM_13000 -> Patchwork_115465v2 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_115465v2 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_115465v2, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/index.html Participating hosts (37 -> 36) -- Missing(1): fi-snb-2520m Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_115465v2: ### IGT changes ### Possible regressions * igt@core_hotunplug@unbind-rebind: - fi-apl-guc: [PASS][1] -> [ABORT][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13000/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/fi-apl-guc/igt@core_hotunp...@unbind-rebind.html Known issues Here are the changes found in Patchwork_115465v2 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][3] -> [FAIL][4] ([i915#8308]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13000/bat-dg2-11/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@slpc: - bat-rpls-1: NOTRUN -> [DMESG-FAIL][5] ([i915#6367]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1: - bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13000/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][9] ([i915#1845]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@i915_selftest@live@reset: - bat-rpls-1: [ABORT][10] ([i915#4983]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13000/bat-rpls-1/igt@i915_selftest@l...@reset.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-rpls-1/igt@i915_selftest@l...@reset.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-2: [DMESG-FAIL][12] ([i915#6997] / [i915#7913]) -> [DMESG-FAIL][13] ([i915#6367] / [i915#7913]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13000/bat-rpls-2/igt@i915_selftest@l...@slpc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/bat-rpls-2/igt@i915_selftest@l...@slpc.html [i915#1845]: https://gitlab.freedesktop.org/drm/intel/issues/1845 [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6997]: https://gitlab.freedesktop.org/drm/intel/issues/6997 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_13000 -> Patchwork_115465v2 CI-20190529: 20190529 CI_DRM_13000: 5d4d06561ff5328f2e8fa1608434360a1b6de471 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7253: 1a619e8dbc6ca887f2ae24b2d7f1ac536342f58c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_115465v2: 5d4d06561ff5328f2e8fa1608434360a1b6de471 @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 4cdb0bb094b8 drm/i915: Make IRQ reset and postinstall multi-gt aware == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_115465v2/index.html
[Intel-gfx] [V3 1/1] drm/i915/debugfs: New debugfs for display clock frequencies
Instead of mixing display & non-display stuff together, move
display specific clock info to new debugfs. This patch will
create a new debugfs "i915_cdclk_info" to expose Current & Max
cdclk and Max pixel clock frequency info.
Example:
$ cat /sys/kernel/debug/dri/0/i915_cdclk_info
Current CD clock frequency: 163200 kHz
Max CD clock frequency: 652800 kHz
Max pixel clock frequency: 1305600 kHz
V2: - s/i915_display_clock_info/i915_cdclk_info/ (Jani)
- Move the logic to intel_cdclk.c (Jani)
- Don't remove info from i915_frequency_info (Jani)
V3: - Drop locking (Jani)
Cc: Jani Nikula
Signed-off-by: Bhanuprakash Modem
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 21 +++
drivers/gpu/drm/i915/display/intel_cdclk.h| 1 +
.../drm/i915/display/intel_display_debugfs.c | 1 +
3 files changed, 23 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 084a483f9776..f6223d8f13b8 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -3235,6 +3235,27 @@ u32 intel_read_rawclk(struct drm_i915_private *dev_priv)
return freq;
}
+static int i915_cdclk_info_show(struct seq_file *m, void *unused)
+{
+ struct drm_i915_private *i915 = m->private;
+
+ seq_printf(m, "Current CD clock frequency: %d kHz\n",
i915->display.cdclk.hw.cdclk);
+ seq_printf(m, "Max CD clock frequency: %d kHz\n",
i915->display.cdclk.max_cdclk_freq);
+ seq_printf(m, "Max pixel clock frequency: %d kHz\n",
i915->max_dotclk_freq);
+
+ return 0;
+}
+
+DEFINE_SHOW_ATTRIBUTE(i915_cdclk_info);
+
+void intel_cdclk_debugfs_register(struct drm_i915_private *i915)
+{
+ struct drm_minor *minor = i915->drm.primary;
+
+ debugfs_create_file("i915_cdclk_info", 0444, minor->debugfs_root,
+ i915, &i915_cdclk_info_fops);
+}
+
static const struct intel_cdclk_funcs mtl_cdclk_funcs = {
.get_cdclk = bxt_get_cdclk,
.set_cdclk = bxt_set_cdclk,
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.h
b/drivers/gpu/drm/i915/display/intel_cdclk.h
index 51e2f6a11ce4..48fd7d39e0cd 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.h
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.h
@@ -82,5 +82,6 @@ intel_atomic_get_cdclk_state(struct intel_atomic_state
*state);
to_intel_cdclk_state(intel_atomic_get_new_global_obj_state(state,
&to_i915(state->base.dev)->display.cdclk.obj))
int intel_cdclk_init(struct drm_i915_private *dev_priv);
+void intel_cdclk_debugfs_register(struct drm_i915_private *i915);
#endif /* __INTEL_CDCLK_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 45113ae107ba..abd16a2b1f7a 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -1094,6 +1094,7 @@ void intel_display_debugfs_register(struct
drm_i915_private *i915)
ARRAY_SIZE(intel_display_debugfs_list),
minor->debugfs_root, minor);
+ intel_cdclk_debugfs_register(i915);
intel_dmc_debugfs_register(i915);
intel_fbc_debugfs_register(i915);
intel_hpd_debugfs_register(i915);
--
2.40.0
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Thu, Apr 13, 2023 at 08:25:52AM +, Tian, Kevin wrote:
> > From: Jason Gunthorpe
> > Sent: Thursday, April 13, 2023 4:07 AM
> >
> >
> > > in which case we need c) a way to
> > > report the overall set of affected devices regardless of ownership in
> > > support of 4), BDF?
> >
> > Yes, continue to use INFO unmodified.
> >
> > > Are we back to replacing group-ids with dev-ids in the INFO structure,
> > > where an invalid dev-id either indicates an affected device with
> > > implied ownership (ok) or a gap in ownership (bad) and a flag somewhere
> > > is meant to indicate the overall disposition based on the availability
> > > of reset?
> >
> > As you explore in the following this gets ugly. I prefer to keep INFO
> > unchanged and add INFO2.
> >
>
> INFO needs a change when VFIO_GROUP is disabled. Now it assumes
> a valid iommu group always exists:
>
> vfio_pci_fill_devs()
> {
> ...
> iommu_group = iommu_group_get(&pdev->dev);
> if (!iommu_group)
> return -EPERM; /* Cannot reset non-isolated devices */
> ...
> }
This can still work in a ugly way. With a INFO2 the only purpose of
INFO would be debugging, so if someone uses no-iommu, with hotreset
and misconfigures it then the only downside is they don't get the
debugging print. But we know of nothing that uses this combination
anyhow..
> with that plus BDF cap, I'm curious what is the actual purpose of
> INFO2 or why cannot requirement#3 reuse the information collected
> via existing INFO?
It can - it is just more complicated for userspace to do it, it has to
extract and match the BDFs and then run some algorithm to determine if
the opened devices cover the right set of devices in the reset group,
and it has to have some special code for no-iommu.
VS info2 would return the dev_id's and a single yes/no if the right
set is present. Kernel runs the algorithm instead of userspace, it
seems more abstract this way.
Also, if we make iommufd return a 'ioas dev_id group' as well it
composes nicely that userspace just needs one translation from dev_id.
Jason
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 12/04/2023 12:33, Andi Shyti wrote:
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
Above two paragraphs seems to have redundancy in the message they convey.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
These two too. So I think commit message can be a bit polished.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++--
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..668c95af8cbcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context *ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context *ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
+ i915_sw_fence_await(&rq->submit);
+ i915_request_get(rq);
+ i915_request_add_locked(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
i915_request_put(*out);
Could you help me understand this please. I have a few questions -
first, what are the actual mechanics of fence error transfer here? I see
the submit fence is being blocked until the next request is submitted -
effectively previous request is only allowed to get on the hardware
after the next one has been queued up. But I don't immediately see what
that does in practice.
Second question relates to the need to hold the timeline mutex
throughout. Presumably this is so two copy or migrate operations on the
same context do not interleave, which can otherwise happen?
Would the error propagation be doable without the lock held by chaining
on the previous request _completion_ fence? If so I am sure that would
have a performance impact, because chunk by chunk would need a GPU<->CPU
round trip to schedule. How much of an impact I don't know. Maybe
enlarging CHUNK_SZ to compensate is an option?
Or if the perf hit would be bearable for stable backports only (much
smaller patch) and then for tip we can do this full speed solution.
But yes, I would first want to understand the actual error propagation
mechanism because sadly my working knowledge is a bit rusty.
- *out = i915_request_get(rq);
- i915_request_add(rq);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(&ce->timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct intel_context *ce,
if (HAS_64K_PAGES(i915) && is_lmem)
offset = CHUNK_SZ;
+ /*
+* While building the chain of requests, we need to ensure
+* that no one can sneak into the timeline unnoticed.
+*/
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
[Intel-gfx] [PATCH] drm/i915/aux: clean up aux name initialization
Split intel_dp_aux_name() to a separate function to declutter
intel_dp_aux_init(), and only have the if ladder to pick the one
character instead of duplicating the whole kasprintf() call.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_dp_aux.c | 32 -
1 file changed, 18 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
b/drivers/gpu/drm/i915/display/intel_dp_aux.c
index 705915d50565..2fee5b79c0b7 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
@@ -718,12 +718,27 @@ void intel_dp_aux_fini(struct intel_dp *intel_dp)
kfree(intel_dp->aux.name);
}
-void intel_dp_aux_init(struct intel_dp *intel_dp)
+static const char *intel_dp_aux_name(struct intel_dp *intel_dp)
{
- struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
+ struct drm_i915_private *i915 = dp_to_i915(intel_dp);
struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
struct intel_encoder *encoder = &dig_port->base;
enum aux_ch aux_ch = dig_port->aux_ch;
+ char aux_char;
+
+ if (DISPLAY_VER(i915) >= 13 && aux_ch >= AUX_CH_D_XELPD)
+ aux_char = aux_ch_name(aux_ch - AUX_CH_D_XELPD + AUX_CH_D);
+ else if (DISPLAY_VER(i915) >= 12 && aux_ch >= AUX_CH_USBC1)
+ aux_char = aux_ch - AUX_CH_USBC1 + '1';
+ else
+ aux_char = aux_ch_name(aux_ch);
+
+ return kasprintf(GFP_KERNEL, "AUX %c/%s", aux_char, encoder->base.name);
+}
+
+void intel_dp_aux_init(struct intel_dp *intel_dp)
+{
+ struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
if (DISPLAY_VER(dev_priv) >= 14) {
intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
@@ -760,18 +775,7 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
drm_dp_aux_init(&intel_dp->aux);
/* Failure to allocate our preferred name is not critical */
- if (DISPLAY_VER(dev_priv) >= 13 && aux_ch >= AUX_CH_D_XELPD)
- intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
- aux_ch_name(aux_ch -
AUX_CH_D_XELPD + AUX_CH_D),
- encoder->base.name);
- else if (DISPLAY_VER(dev_priv) >= 12 && aux_ch >= AUX_CH_USBC1)
- intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX USBC%c/%s",
- aux_ch - AUX_CH_USBC1 + '1',
- encoder->base.name);
- else
- intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
- aux_ch_name(aux_ch),
- encoder->base.name);
+ intel_dp->aux.name = intel_dp_aux_name(intel_dp);
intel_dp->aux.transfer = intel_dp_aux_transfer;
cpu_latency_qos_add_request(&intel_dp->pm_qos, PM_QOS_DEFAULT_VALUE);
--
2.39.2
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave & Daniel, Just one Cc:stable fix for indirect sampler state this week on drm-intel-next-fixes. Regards, Joonas *** drm-intel-next-fixes-2023-04-13: Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. The following changes since commit 55bf14961db9da61220e6f04bc9919c94b1a6585: Merge tag 'mediatek-drm-next-6.4' of https://git.kernel.org/pub/scm/linux/kernel/git/chunkuang.hu/linux into drm-next (2023-04-11 12:28:10 +0200) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2023-04-13 for you to fetch changes up to 81900e3a37750d8c6ad705045310e002f6dd0356: drm/i915: disable sampler indirect state in bindless heap (2023-04-12 11:36:09 +0300) Short summary of fixes pull (less than what git shortlog provides): Just one Cc:stable fix for sampler indirect state in bindless heap. Lionel Landwerlin (1): drm/i915: disable sampler indirect state in bindless heap drivers/gpu/drm/i915/gt/intel_gt_regs.h | 1 + drivers/gpu/drm/i915/gt/intel_workarounds.c | 19 +++ 2 files changed, 20 insertions(+)
Re: [Intel-gfx] [RESEND] drm/i915: hide mkwrite_device_info() better
On 11/04/2023 11:56, Jani Nikula wrote:
The goal has been to just make device info a pointer to static const
data, i.e. the static const structs in i915_pci.c. See [1]. However,
there were issues with intel_device_info_runtime_init() clearing the
display sub-struct of device info on the !HAS_DISPLAY() path, which
consequently disables a lot of display functionality, like it
should. Looks like we'd have to cover all those paths, and maybe
sprinkle HAS_DISPLAY() checks in them, which we haven't gotten around
to.
In the mean time, hide mkwrite_device_info() better within
intel_device_info.c by adding a intel_device_info_driver_create() for
the very early initialization of the device info and initial runtime
info. This also lets us declutter i915_drv.h a bit, and stops promoting
mkwrite_device_info() as something that could be used.
[1]
https://lore.kernel.org/r/a0422f0a8ac055f65b7922bcd3119b180a41e79e.1655712106.git.jani.nik...@intel.com
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_driver.c | 12 ++
drivers/gpu/drm/i915/i915_drv.h | 7 --
drivers/gpu/drm/i915/intel_device_info.c | 29
drivers/gpu/drm/i915/intel_device_info.h | 2 ++
4 files changed, 33 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index 93fdc40d724f..2980ccdef6cd 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -720,8 +720,6 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
{
const struct intel_device_info *match_info =
(struct intel_device_info *)ent->driver_data;
- struct intel_device_info *device_info;
- struct intel_runtime_info *runtime;
struct drm_i915_private *i915;
i915 = devm_drm_dev_alloc(&pdev->dev, &i915_drm_driver,
@@ -734,14 +732,8 @@ i915_driver_create(struct pci_dev *pdev, const struct
pci_device_id *ent)
/* Device parameters start as a copy of module parameters. */
i915_params_copy(&i915->params, &i915_modparams);
- /* Setup the write-once "constant" device info */
- device_info = mkwrite_device_info(i915);
- memcpy(device_info, match_info, sizeof(*device_info));
-
- /* Initialize initial runtime info from static const data and pdev. */
- runtime = RUNTIME_INFO(i915);
- memcpy(runtime, &INTEL_INFO(i915)->__runtime, sizeof(*runtime));
- runtime->device_id = pdev->device;
+ /* Set up device info and initial runtime info. */
+ intel_device_info_driver_create(i915, pdev->device, match_info);
return i915;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index e771fdc3099c..fe7eeafe9cff 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -931,11 +931,4 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
#define HAS_LMEMBAR_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \
GRAPHICS_VER_FULL(i915) >= IP_VER(12,
70))
-/* intel_device_info.c */
-static inline struct intel_device_info *
-mkwrite_device_info(struct drm_i915_private *dev_priv)
-{
- return (struct intel_device_info *)INTEL_INFO(dev_priv);
-}
-
#endif
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index fc5cd14adfcc..4e23be2995bf 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -381,6 +381,13 @@ void intel_device_info_runtime_init_early(struct
drm_i915_private *i915)
intel_device_info_subplatform_init(i915);
}
+/* FIXME: Remove this, and make device info a const pointer to rodata. */
+static struct intel_device_info *
+mkwrite_device_info(struct drm_i915_private *i915)
+{
+ return (struct intel_device_info *)INTEL_INFO(i915);
+}
+
/**
* intel_device_info_runtime_init - initialize runtime info
* @dev_priv: the i915 device
@@ -548,6 +555,28 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
dev_priv->drm.driver_features &= ~DRIVER_ATOMIC;
}
+/*
+ * Set up device info and initial runtime info at driver create.
+ *
+ * Note: i915 is only an allocated blob of memory at this point.
+ */
+void intel_device_info_driver_create(struct drm_i915_private *i915,
+u16 device_id,
+const struct intel_device_info *match_info)
+{
+ struct intel_device_info *info;
+ struct intel_runtime_info *runtime;
+
+ /* Setup the write-once "constant" device info */
+ info = mkwrite_device_info(i915);
+ memcpy(info, match_info, sizeof(*info));
+
+ /* Initialize initial runtime info from static const data and pdev. */
+ runtime = RUNTIME_INFO(i915);
+ memcpy(runtime, &INTEL_INFO(i915)->__runtime, sizeof(*runtime));
+ runtime->device_id = device_i
Re: [Intel-gfx] [PATCH] drm/i915/aux: clean up aux name initialization
Quoting Jani Nikula (2023-04-13 09:11:13)
> Split intel_dp_aux_name() to a separate function to declutter
> intel_dp_aux_init(), and only have the if ladder to pick the one
> character instead of duplicating the whole kasprintf() call.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_dp_aux.c | 32 -
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> index 705915d50565..2fee5b79c0b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
> @@ -718,12 +718,27 @@ void intel_dp_aux_fini(struct intel_dp *intel_dp)
> kfree(intel_dp->aux.name);
> }
>
> -void intel_dp_aux_init(struct intel_dp *intel_dp)
> +static const char *intel_dp_aux_name(struct intel_dp *intel_dp)
> {
> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
> struct intel_encoder *encoder = &dig_port->base;
> enum aux_ch aux_ch = dig_port->aux_ch;
> + char aux_char;
> +
> + if (DISPLAY_VER(i915) >= 13 && aux_ch >= AUX_CH_D_XELPD)
> + aux_char = aux_ch_name(aux_ch - AUX_CH_D_XELPD + AUX_CH_D);
> + else if (DISPLAY_VER(i915) >= 12 && aux_ch >= AUX_CH_USBC1)
> + aux_char = aux_ch - AUX_CH_USBC1 + '1';
> + else
> + aux_char = aux_ch_name(aux_ch);
> +
> + return kasprintf(GFP_KERNEL, "AUX %c/%s", aux_char, encoder->base.name);
Is the drop of " USBC" in the format string for the second case in the ladder
intentional?
> +}
> +
> +void intel_dp_aux_init(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>
> if (DISPLAY_VER(dev_priv) >= 14) {
> intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
> @@ -760,18 +775,7 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
> drm_dp_aux_init(&intel_dp->aux);
>
> /* Failure to allocate our preferred name is not critical */
> - if (DISPLAY_VER(dev_priv) >= 13 && aux_ch >= AUX_CH_D_XELPD)
> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
> - aux_ch_name(aux_ch - AUX_CH_D_XELPD
> + AUX_CH_D),
> - encoder->base.name);
> - else if (DISPLAY_VER(dev_priv) >= 12 && aux_ch >= AUX_CH_USBC1)
> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX USBC%c/%s",
> - aux_ch - AUX_CH_USBC1 + '1',
> - encoder->base.name);
> - else
> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
> - aux_ch_name(aux_ch),
> - encoder->base.name);
> + intel_dp->aux.name = intel_dp_aux_name(intel_dp);
>
> intel_dp->aux.transfer = intel_dp_aux_transfer;
> cpu_latency_qos_add_request(&intel_dp->pm_qos, PM_QOS_DEFAULT_VALUE);
> --
> 2.39.2
>
Re: [Intel-gfx] [PATCH] drm/i915/aux: clean up aux name initialization
On Thu, 13 Apr 2023, Gustavo Sousa wrote:
> Quoting Jani Nikula (2023-04-13 09:11:13)
>> Split intel_dp_aux_name() to a separate function to declutter
>> intel_dp_aux_init(), and only have the if ladder to pick the one
>> character instead of duplicating the whole kasprintf() call.
>>
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_aux.c | 32 -
>> 1 file changed, 18 insertions(+), 14 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> b/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> index 705915d50565..2fee5b79c0b7 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_aux.c
>> @@ -718,12 +718,27 @@ void intel_dp_aux_fini(struct intel_dp *intel_dp)
>> kfree(intel_dp->aux.name);
>> }
>>
>> -void intel_dp_aux_init(struct intel_dp *intel_dp)
>> +static const char *intel_dp_aux_name(struct intel_dp *intel_dp)
>> {
>> - struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>> + struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp);
>> struct intel_encoder *encoder = &dig_port->base;
>> enum aux_ch aux_ch = dig_port->aux_ch;
>> + char aux_char;
>> +
>> + if (DISPLAY_VER(i915) >= 13 && aux_ch >= AUX_CH_D_XELPD)
>> + aux_char = aux_ch_name(aux_ch - AUX_CH_D_XELPD + AUX_CH_D);
>> + else if (DISPLAY_VER(i915) >= 12 && aux_ch >= AUX_CH_USBC1)
>> + aux_char = aux_ch - AUX_CH_USBC1 + '1';
>> + else
>> + aux_char = aux_ch_name(aux_ch);
>> +
>> + return kasprintf(GFP_KERNEL, "AUX %c/%s", aux_char, encoder->base.name);
>
> Is the drop of " USBC" in the format string for the second case in the ladder
> intentional?
No. Either I goofed it up originally or during a rebase. :/
Thanks for spotting it,
Jani.
>
>> +}
>> +
>> +void intel_dp_aux_init(struct intel_dp *intel_dp)
>> +{
>> + struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
>>
>> if (DISPLAY_VER(dev_priv) >= 14) {
>> intel_dp->aux_ch_ctl_reg = xelpdp_aux_ctl_reg;
>> @@ -760,18 +775,7 @@ void intel_dp_aux_init(struct intel_dp *intel_dp)
>> drm_dp_aux_init(&intel_dp->aux);
>>
>> /* Failure to allocate our preferred name is not critical */
>> - if (DISPLAY_VER(dev_priv) >= 13 && aux_ch >= AUX_CH_D_XELPD)
>> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
>> - aux_ch_name(aux_ch -
>> AUX_CH_D_XELPD + AUX_CH_D),
>> - encoder->base.name);
>> - else if (DISPLAY_VER(dev_priv) >= 12 && aux_ch >= AUX_CH_USBC1)
>> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX USBC%c/%s",
>> - aux_ch - AUX_CH_USBC1 + '1',
>> - encoder->base.name);
>> - else
>> - intel_dp->aux.name = kasprintf(GFP_KERNEL, "AUX %c/%s",
>> - aux_ch_name(aux_ch),
>> - encoder->base.name);
>> + intel_dp->aux.name = intel_dp_aux_name(intel_dp);
>>
>> intel_dp->aux.transfer = intel_dp_aux_transfer;
>> cpu_latency_qos_add_request(&intel_dp->pm_qos, PM_QOS_DEFAULT_VALUE);
>> --
>> 2.39.2
>>
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH v5 5/5] drm/i915/gt: Make sure that errors are propagated through request chains
On 13/04/2023 12:56, Tvrtko Ursulin wrote:
On 12/04/2023 12:33, Andi Shyti wrote:
Currently, when we perform operations such as clearing or copying
large blocks of memory, we generate multiple requests that are
executed in a chain.
However, if one of these requests fails, we may not realize it
unless it happens to be the last request in the chain. This is
because errors are not properly propagated.
For this we need to keep propagating the chain of fence
notification in order to always reach the final fence associated
to the final request.
To address this issue, we need to ensure that the chain of fence
notifications is always propagated so that we can reach the final
fence associated with the last request. By doing so, we will be
able to detect any memory operation failures and determine
whether the memory is still invalid.
Above two paragraphs seems to have redundancy in the message they convey.
On copy and clear migration signal fences upon completion.
On copy and clear migration, signal fences upon request
completion to ensure that we have a reliable perpetuation of the
operation outcome.
These two too. So I think commit message can be a bit polished.
Fixes: cf586021642d80 ("drm/i915/gt: Pipelined page migration")
Reported-by: Matthew Auld
Suggested-by: Chris Wilson
Signed-off-by: Andi Shyti
Cc: sta...@vger.kernel.org
Reviewed-by: Matthew Auld
Acked-by: Nirmoy Das
---
drivers/gpu/drm/i915/gt/intel_migrate.c | 51 +++--
1 file changed, 39 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 3f638f1987968..668c95af8cbcf 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -742,13 +742,19 @@ intel_context_migrate_copy(struct intel_context
*ce,
dst_offset = 2 * CHUNK_SZ;
}
+ /*
+ * While building the chain of requests, we need to ensure
+ * that no one can sneak into the timeline unnoticed.
+ */
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_create(ce);
+ rq = i915_request_create_locked(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
- goto out_ce;
+ break;
}
if (deps) {
@@ -878,10 +884,14 @@ intel_context_migrate_copy(struct intel_context
*ce,
/* Arbitration is re-enabled between requests. */
out_rq:
- if (*out)
+ i915_sw_fence_await(&rq->submit);
+ i915_request_get(rq);
+ i915_request_add_locked(rq);
+ if (*out) {
+ i915_sw_fence_complete(&(*out)->submit);
i915_request_put(*out);
Could you help me understand this please. I have a few questions -
first, what are the actual mechanics of fence error transfer here? I see
the submit fence is being blocked until the next request is submitted -
effectively previous request is only allowed to get on the hardware
after the next one has been queued up. But I don't immediately see what
that does in practice.
Second question relates to the need to hold the timeline mutex
throughout. Presumably this is so two copy or migrate operations on the
same context do not interleave, which can otherwise happen?
Would the error propagation be doable without the lock held by chaining
on the previous request _completion_ fence? If so I am sure that would
have a performance impact, because chunk by chunk would need a GPU<->CPU
round trip to schedule. How much of an impact I don't know. Maybe
enlarging CHUNK_SZ to compensate is an option?
Or if the perf hit would be bearable for stable backports only (much
smaller patch) and then for tip we can do this full speed solution.
But yes, I would first want to understand the actual error propagation
mechanism because sadly my working knowledge is a bit rusty.
Another option - maybe - is this related to revert of fence error
propagation? If it is and having that would avoid the need for this
invasive fix, maybe we unrevert 3761baae908a7b5012be08d70fa553cc2eb82305
with edits to limit to special contexts? If doable..
Regards,
Tvrtko
- *out = i915_request_get(rq);
- i915_request_add(rq);
+ }
+ *out = rq;
if (err)
break;
@@ -905,7 +915,10 @@ intel_context_migrate_copy(struct intel_context *ce,
cond_resched();
} while (1);
-out_ce:
+ mutex_unlock(&ce->timeline->mutex);
+
+ if (*out)
+ i915_sw_fence_complete(&(*out)->submit);
return err;
}
@@ -999,13 +1012,19 @@ intel_context_migrate_clear(struct
intel_context *ce,
if (HAS_64K_PAGES(i915) && is_lmem)
offset = CHUNK_SZ;
+ /*
+ * While building the chain of requests, we need to ensure
+ * that no one can sneak into the timeline unnoticed.
+ */
+ mutex_lock(&ce->timeline->mutex);
+
do {
int len;
- rq = i915_request_creat
Re: [Intel-gfx] [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
On 12/04/2023 23:42, Rob Clark wrote:
From: Rob Clark
There is more do to here to remove my client->id fully (would now be
dead code) so maybe easiest if you drop this patch and I do it after you
land this and it propagates to our branches? I'd like to avoid pain with
conflicts if possible..
Regards,
Tvrtko
Signed-off-by: Rob Clark
---
drivers/gpu/drm/i915/i915_driver.c | 3 ++-
drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
3 files changed, 8 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index db7a86def7e2..0d91f85f8b97 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops = {
.compat_ioctl = i915_ioc32_compat_ioctl,
.llseek = noop_llseek,
#ifdef CONFIG_PROC_FS
- .show_fdinfo = i915_drm_client_fdinfo,
+ .show_fdinfo = drm_show_fdinfo,
#endif
};
@@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
.open = i915_driver_open,
.lastclose = i915_driver_lastclose,
.postclose = i915_driver_postclose,
+ .show_fdinfo = i915_drm_client_fdinfo,
.prime_handle_to_fd = drm_gem_prime_handle_to_fd,
.prime_fd_to_handle = drm_gem_prime_fd_to_handle,
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index b09d1d386574..4a77e5e47f79 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx, unsigned
int class)
}
static void
-show_client_class(struct seq_file *m,
+show_client_class(struct drm_printer *p,
struct i915_drm_client *client,
unsigned int class)
{
@@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
rcu_read_unlock();
if (capacity)
- seq_printf(m, "drm-engine-%s:\t%llu ns\n",
+ drm_printf(p, "drm-engine-%s:\t%llu ns\n",
uabi_class_names[class], total);
if (capacity > 1)
- seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
+ drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
uabi_class_names[class],
capacity);
}
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
{
- struct drm_file *file = f->private_data;
struct drm_i915_file_private *file_priv = file->driver_priv;
struct drm_i915_private *i915 = file_priv->dev_priv;
struct i915_drm_client *client = file_priv->client;
- struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
unsigned int i;
/*
@@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
file *f)
* **
*/
- seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
- seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
- pci_domain_nr(pdev->bus), pdev->bus->number,
- PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
- seq_printf(m, "drm-client-id:\t%u\n", client->id);
-
/*
* Temporarily skip showing client engine information with GuC
submission till
* fetching engine busyness is implemented in the GuC submission backend
@@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct file
*f)
return;
for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
- show_client_class(m, client, i);
+ show_client_class(p, client, i);
}
#endif
diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
b/drivers/gpu/drm/i915/i915_drm_client.h
index 69496af996d9..ef85fef45de5 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.h
+++ b/drivers/gpu/drm/i915/i915_drm_client.h
@@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct i915_drm_client
*client)
struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients *clients);
#ifdef CONFIG_PROC_FS
-void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
+void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
#endif
void i915_drm_clients_fini(struct i915_drm_clients *clients);
Re: [Intel-gfx] [PULL] drm-intel-fixes
On Thu, Apr 13, 2023 at 10:13:57AM +0300, Jani Nikula wrote: > > Hi Dave & Daniel - > > One DSI fix, stable material. > > drm-intel-fixes-2023-04-13: > drm/i915 fixes for v6.3-rc7: > - Fix dual link DSI for TGL+ > > BR, > Jani. > > The following changes since commit 09a9639e56c01c7a00d6c0ca63f4c7c41abe075d: > > Linux 6.3-rc6 (2023-04-09 11:15:57 -0700) > > are available in the Git repository at: > > git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2023-04-13 Pulled, thanks > > for you to fetch changes up to 6b8446859c971a5783a2cdc90adf32e64de3bd23: > > drm/i915/dsi: fix DSS CTL register offsets for TGL+ (2023-04-11 11:41:57 > +0300) > > > drm/i915 fixes for v6.3-rc7: > - Fix dual link DSI for TGL+ > > > Jani Nikula (1): > drm/i915/dsi: fix DSS CTL register offsets for TGL+ > > drivers/gpu/drm/i915/display/icl_dsi.c | 20 > 1 file changed, 16 insertions(+), 4 deletions(-) > > -- > Jani Nikula, Intel Open Source Graphics Center -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch
Re: [Intel-gfx] [PATCH RESEND v3 2/3] drm/ttm: Reduce the number of used allocation orders for TTM pages
On Thu, 13 Apr 2023 at 11:46, Christian König wrote: > > Am 13.04.23 um 10:48 schrieb Daniel Vetter: > > On Wed, 12 Apr 2023 at 16:18, Christian König > > wrote: > >> Am 12.04.23 um 11:08 schrieb Daniel Vetter: > >>> On Tue, 11 Apr 2023 at 15:45, Daniel Vetter wrote: > On Tue, Apr 11, 2023 at 02:11:18PM +0200, Christian König wrote: > > Am 11.04.23 um 11:51 schrieb Daniel Vetter: > >> On Tue, Apr 04, 2023 at 10:06:49PM +0200, Thomas Hellström wrote: > >>> 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 gigantic pages. > >>> > >>> Looking forward to when we might be able to swap out PMD size folios > >>> without splitting, this will also be a benefit. > >>> > >>> v2: > >>> - Include all orders up to the PMD size (Christian König) > >>> v3: > >>> - Avoid compilation errors for architectures with special PFN_SHIFTs > >>> > >>> Signed-off-by: Thomas Hellström > >>> Reviewed-by: Christian König > >> Apparently this fails on ppc build testing. Please supply build fix > >> asap > >> (or I guess we need to revert). I'm kinda not clear why this only > >> showed > >> up when I merged the drm-misc-next pr into drm-next ... > > I'm really wondering this as well. It looks like PMD_SHIFT isn't a > > constant > > on this particular platform. > > > > But from what I can find in the upstream 6.2 kernel PMD_SHIFT always > > seems > > to be a constant. > > > > So how exactly can that here break? > There's some in-flight patches to rework MAX_ORDER and other things in > linux-next, maybe it's recent? If you check out linux-next then you need > to reapply the patch (since sfr reverted it). > >>> So I looked and on ppc64 PMD_SHIFT is defined in terms of > >>> PTE_INDEX_SIZE, which is defined (for book3s) in terms of the variable > >>> __pte_index_size. This is in 6.3 already and seems pretty old. > >> Ah! I missed that one, thanks. > >> > >>> So revert? Or fixup patch to make this work on ppc? > >> I think for now just revert or change it so that we check if PMD_SHIFT > >> is a constant. > >> > >> Thomas do you have any quick solution? > > I guess Thomas is on vacations. Can you pls do the revert and push it > > to drm-misc-next-fixes so this won't get lost? > > The offending patch hasn't showed up in drm-misc-next-fixes nor > drm-misc-fixes yet. Looks like the branches are lacking behind. > > I can revert it on drm-misc-next, but I', not 100% sure that will then > get picked up in time. It's there now, Maarten forwarded drm-misc-next-fixes this morning. That's why I pinged here again, trees are ready to land the revert :-) -Daniel > > Christian. > > > > > Acked-by: Daniel Vetter > > > > preemptively for that. Normally I think we could wait a bit more but > > it's really close to merge window PR and I don't like handing too many > > open things to Dave when he's back :-) > > -Daniel > > > >> Christian. > >> > >>> > >>> --- > >>> drivers/gpu/drm/ttm/ttm_pool.c | 30 +++--- > >>> 1 file changed, 19 insertions(+), 11 deletions(-) > >>> > >>> diff --git a/drivers/gpu/drm/ttm/ttm_pool.c > >>> b/drivers/gpu/drm/ttm/ttm_pool.c > >>> index dfce896c4bae..18c342a919a2 100644 > >>> --- a/drivers/gpu/drm/ttm/ttm_pool.c > >>> +++ b/drivers/gpu/drm/ttm/ttm_pool.c > >>> @@ -47,6 +47,11 @@ > >>> #include "ttm_module.h" > >>> +#define TTM_MAX_ORDER (PMD_SHIFT - PAGE_SHIFT) > >>> +#define __TTM_DIM_ORDER (TTM_MAX_ORDER + 1) > >>> +/* Some architectures have a weird PMD_SHIFT */ > >>> +#define TTM_DIM_ORDER (__TTM_DIM_ORDER <= MAX_ORDER ? > >>> __TTM_DIM_ORDER : MAX_ORDER) > >>> + > >>> /** > >>> * struct ttm_pool_dma - Helper object for coherent DMA mappings > >>> * > >>> @@ -65,11 +70,11 @@ module_param(page_pool_size, ulong, 0644); > >>> static atomic_long_t allocated_pages; > >>> -static struct ttm_pool_type global_write_combined[MAX_ORDER]; > >>> -static struct ttm_pool_type global_uncached[MAX_ORDER]; > >>> +static struct ttm_pool_type global_write_combined[TTM_DIM_ORDER]; > >>> +static struct ttm_pool_type global_uncached[TTM_DIM_ORDER]; > >>> -static struct ttm_pool_type global_dma32_write_combined[MAX_ORDER]; > >>> -static struct ttm_pool_type global_dma32_uncached[MAX_ORDER]; > >>> +static struct ttm_pool_type > >>> global_dma32_write_combined[TTM_DIM_ORDER]; > >>> +static struct ttm_pool_type global_dma32_uncached[TTM_DIM_ORDER]; > >>> static spinlock_t shrinker_lock; > >>> static struct list_head shrinke
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/display: split out high level display entry points
== Series Details == Series: drm/i915/display: split out high level display entry points URL : https://patchwork.freedesktop.org/series/116431/ State : warning == Summary == Error: dim checkpatch failed fbb7502dc824 drm/i915/display: remove intel_display_commit_duplicated_state() f16b8371b8f4 drm/i915/display: start high level display driver file Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:124: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #124: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 180 lines checked 8a9ef874b10f drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch] 43949ccaacb2 drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer() e5556962b69b drm/i915/display: move modeset probe/remove functions to intel_display_driver.c -:617: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #617: FILE: drivers/gpu/drm/i915/display/intel_display_driver.c:86: + cdclk_state->logical = cdclk_state->actual = i915->display.cdclk.hw; total: 0 errors, 0 warnings, 1 checks, 929 lines checked 96de27eb41aa drm/i915/display: rename intel_display_driver_* functions a02c04b793b4 drm/i915/display: add intel_display_reset.[ch] Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' Traceback (most recent call last): File "scripts/spdxcheck.py", line 6, in from ply import lex, yacc ModuleNotFoundError: No module named 'ply' -:192: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #192: new file mode 100644 -:234: WARNING:MEMORY_BARRIER: memory barrier without comment #234: FILE: drivers/gpu/drm/i915/display/intel_display_reset.c:38: + smp_mb__after_atomic(); total: 0 errors, 2 warnings, 0 checks, 332 lines checked ffc17a84f51d drm/i915/display: move display suspend/resume to intel_display_driver.[ch] 607713a78bc3 drm/i915/display: rename intel_display_driver_suspend/resume functions 4bad69e7cd40 drm/i915/display: add intel_display_driver_early_probe()
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/display: split out high level display entry points
== Series Details == Series: drm/i915/display: split out high level display entry points URL : https://patchwork.freedesktop.org/series/116431/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./arch/x86/include/asm/bitops.h:117:1: warning: unreplaced symbol 'return' +./
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/display: split out high level display entry points
== Series Details == Series: drm/i915/display: split out high level display entry points URL : https://patchwork.freedesktop.org/series/116431/ State : success == Summary == CI Bug Log - changes from CI_DRM_13001 -> Patchwork_116431v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116431v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [PASS][1] -> [ABORT][2] ([i915#6687] / [i915#7978]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_pm_rps@basic-api: - bat-dg2-11: [PASS][3] -> [FAIL][4] ([i915#8308]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/bat-dg2-11/igt@i915_pm_...@basic-api.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/bat-dg2-11/igt@i915_pm_...@basic-api.html * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][5] -> [DMESG-WARN][6] ([i915#7699]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/bat-dg2-11/igt@i915_selftest@l...@migrate.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@reset: - bat-rpls-2: [PASS][7] -> [ABORT][8] ([i915#4983] / [i915#7913]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/bat-rpls-2/igt@i915_selftest@l...@reset.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [PASS][9] -> [DMESG-FAIL][10] ([i915#6367]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/bat-rpls-1/igt@i915_selftest@l...@slpc.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html [i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687 [i915#7699]: https://gitlab.freedesktop.org/drm/intel/issues/7699 [i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913 [i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978 [i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308 Build changes - * Linux: CI_DRM_13001 -> Patchwork_116431v1 CI-20190529: 20190529 CI_DRM_13001: 8366fd94bd551dd4b283708a23fa9b90f3a24b9e @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7253: 1a619e8dbc6ca887f2ae24b2d7f1ac536342f58c @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116431v1: 8366fd94bd551dd4b283708a23fa9b90f3a24b9e @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits 5bd0f29239f9 drm/i915/display: add intel_display_driver_early_probe() a4b7f535dcc7 drm/i915/display: rename intel_display_driver_suspend/resume functions e98ba3c94399 drm/i915/display: move display suspend/resume to intel_display_driver.[ch] d453e80588d3 drm/i915/display: add intel_display_reset.[ch] dba6f6eb4ac3 drm/i915/display: rename intel_display_driver_* functions 6bcb9e3f6f74 drm/i915/display: move modeset probe/remove functions to intel_display_driver.c d8cc26c6c668 drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer() 07539c75c344 drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch] 3f8138dd141d drm/i915/display: start high level display driver file fce1d4ac8964 drm/i915/display: remove intel_display_commit_duplicated_state() == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/index.html
Re: [Intel-gfx] [PATCH 05/10] drm/i915/display: move modeset probe/remove functions to intel_display_driver.c
Quoting Jani Nikula (2023-04-13 06:47:31)
> High level display functionality only called from driver top level code.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 373 +
> drivers/gpu/drm/i915/display/intel_display.h | 23 +-
> .../drm/i915/display/intel_display_driver.c | 374 ++
> .../drm/i915/display/intel_display_driver.h | 7 +
> 4 files changed, 408 insertions(+), 369 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index dfec17bb3a7a..56e3aab7e1c6 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -54,7 +54,6 @@
> #include "i9xx_plane.h"
> #include "i9xx_wm.h"
> #include "icl_dsi.h"
> -#include "intel_acpi.h"
> #include "intel_atomic.h"
> #include "intel_atomic_plane.h"
> #include "intel_audio.h"
> @@ -67,6 +66,7 @@
> #include "intel_crtc_state_dump.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> +#include "intel_display_driver.h"
> #include "intel_display_power.h"
> #include "intel_display_types.h"
> #include "intel_dmc.h"
> @@ -86,11 +86,8 @@
> #include "intel_fdi.h"
> #include "intel_fifo_underrun.h"
> #include "intel_frontbuffer.h"
> -#include "intel_gmbus.h"
> -#include "intel_hdcp.h"
> #include "intel_hdmi.h"
> #include "intel_hotplug.h"
> -#include "intel_hti.h"
> #include "intel_lvds.h"
> #include "intel_lvds_regs.h"
> #include "intel_modeset_setup.h"
> @@ -104,7 +101,6 @@
> #include "intel_plane_initial.h"
> #include "intel_pps.h"
> #include "intel_psr.h"
> -#include "intel_quirks.h"
> #include "intel_sdvo.h"
> #include "intel_snps_phy.h"
> #include "intel_tc.h"
> @@ -174,7 +170,7 @@ int vlv_get_cck_clock_hpll(struct drm_i915_private
> *dev_priv,
> return hpll;
> }
>
> -static void intel_update_czclk(struct drm_i915_private *dev_priv)
> +void intel_update_czclk(struct drm_i915_private *dev_priv)
> {
> if (!(IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv)))
> return;
> @@ -2582,7 +2578,7 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
> 0x8);
> }
>
> -static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
> +void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
> {
> /*
> * There may be no VBT; and if the BIOS enabled SSC we can
> @@ -7225,7 +7221,7 @@ static void intel_atomic_helper_free_state(struct
> drm_i915_private *dev_priv)
> drm_atomic_state_put(&state->base);
> }
>
> -static void intel_atomic_helper_free_state_worker(struct work_struct *work)
> +void intel_atomic_helper_free_state_worker(struct work_struct *work)
> {
> struct drm_i915_private *dev_priv =
> container_of(work, typeof(*dev_priv),
> display.atomic_helper.free_work);
> @@ -7573,9 +7569,8 @@ static void intel_atomic_track_fbs(struct
> intel_atomic_state *state)
> plane->frontbuffer_bit);
> }
>
> -static int intel_atomic_commit(struct drm_device *dev,
> - struct drm_atomic_state *_state,
> - bool nonblock)
> +int intel_atomic_commit(struct drm_device *dev, struct drm_atomic_state
> *_state,
> + bool nonblock)
> {
> struct intel_atomic_state *state = to_intel_atomic_state(_state);
> struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -7677,19 +7672,6 @@ void intel_plane_destroy(struct drm_plane *plane)
> kfree(to_intel_plane(plane));
> }
>
> -static void intel_plane_possible_crtcs_init(struct drm_i915_private
> *dev_priv)
> -{
> - struct intel_plane *plane;
> -
> - for_each_intel_plane(&dev_priv->drm, plane) {
> - struct intel_crtc *crtc = intel_crtc_for_pipe(dev_priv,
> -plane->pipe);
> -
> - plane->base.possible_crtcs = drm_crtc_mask(&crtc->base);
> - }
> -}
> -
> -
> int intel_get_pipe_from_crtc_id_ioctl(struct drm_device *dev, void *data,
> struct drm_file *file)
> {
> @@ -7769,7 +7751,7 @@ static bool intel_ddi_crt_present(struct
> drm_i915_private *dev_priv)
> return true;
> }
>
> -static void intel_setup_outputs(struct drm_i915_private *dev_priv)
> +void intel_setup_outputs(struct drm_i915_private *dev_priv)
> {
> struct intel_encoder *encoder;
> bool dpd_is_edp = false;
> @@ -8021,9 +8003,8 @@ static int max_dotclock(struct drm_i915_private *i915)
> return max_dotclock;
> }
>
> -static enum drm_mode_status
> -intel_mode_valid(struct drm_device *dev,
> - const struct drm_display_mode *mode)
> +enum drm_mode_status intel_mode_valid(struct drm_device *dev,
> +const struct drm_display_mode *mode)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
>
Re: [Intel-gfx] [PATCH 06/10] drm/i915/display: rename intel_display_driver_* functions
Quoting Jani Nikula (2023-04-13 06:47:32)
> Follow the usual naming conventions.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 2 +-
> .../drm/i915/display/intel_display_driver.c | 16 +++---
> .../drm/i915/display/intel_display_driver.h | 14 ++---
> drivers/gpu/drm/i915/i915_driver.c| 21 ++-
> 4 files changed, 27 insertions(+), 26 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 56e3aab7e1c6..f425e5ed155b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -833,7 +833,7 @@ void intel_display_finish_reset(struct drm_i915_private
> *i915)
> * so need a full re-initialization.
> */
> intel_pps_unlock_regs_wa(i915);
> - intel_modeset_init_hw(i915);
> + intel_display_driver_init_hw(i915);
> intel_clock_gating_init(i915);
> intel_hpd_init(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index f7805c6f1b63..45e425100385 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -72,7 +72,7 @@ bool intel_display_driver_probe_defer(struct pci_dev *pdev)
> return false;
> }
>
> -void intel_modeset_init_hw(struct drm_i915_private *i915)
> +void intel_display_driver_init_hw(struct drm_i915_private *i915)
> {
> struct intel_cdclk_state *cdclk_state;
>
> @@ -170,7 +170,7 @@ static void intel_plane_possible_crtcs_init(struct
> drm_i915_private *dev_priv)
> }
>
> /* part #1: call before irq install */
> -int intel_modeset_init_noirq(struct drm_i915_private *i915)
> +int intel_display_driver_probe_noirq(struct drm_i915_private *i915)
> {
> int ret;
>
> @@ -246,7 +246,7 @@ int intel_modeset_init_noirq(struct drm_i915_private
> *i915)
> }
>
> /* part #2: call after irq install, but before gem init */
> -int intel_modeset_init_nogem(struct drm_i915_private *i915)
> +int intel_display_driver_probe_nogem(struct drm_i915_private *i915)
> {
> struct drm_device *dev = &i915->drm;
> enum pipe pipe;
> @@ -281,7 +281,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
> *i915)
> intel_fdi_pll_freq_update(i915);
>
> intel_update_czclk(i915);
> - intel_modeset_init_hw(i915);
> + intel_display_driver_init_hw(i915);
> intel_dpll_update_ref_clks(i915);
>
> intel_hdcp_component_init(i915);
> @@ -318,7 +318,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
> *i915)
> }
>
> /* part #3: call after gem init */
> -int intel_modeset_init(struct drm_i915_private *i915)
> +int intel_display_driver_probe(struct drm_i915_private *i915)
> {
> int ret;
>
> @@ -382,7 +382,7 @@ void intel_display_driver_register(struct
> drm_i915_private *i915)
> }
>
> /* part #1: call before irq uninstall */
> -void intel_modeset_driver_remove(struct drm_i915_private *i915)
> +void intel_display_driver_remove(struct drm_i915_private *i915)
> {
> if (!HAS_DISPLAY(i915))
> return;
> @@ -402,7 +402,7 @@ void intel_modeset_driver_remove(struct drm_i915_private
> *i915)
> }
>
> /* part #2: call after irq uninstall */
> -void intel_modeset_driver_remove_noirq(struct drm_i915_private *i915)
> +void intel_display_driver_remove_noirq(struct drm_i915_private *i915)
> {
> if (!HAS_DISPLAY(i915))
> return;
> @@ -436,7 +436,7 @@ void intel_modeset_driver_remove_noirq(struct
> drm_i915_private *i915)
> }
>
> /* part #3: call after gem init */
> -void intel_modeset_driver_remove_nogem(struct drm_i915_private *i915)
> +void intel_display_driver_remove_nogem(struct drm_i915_private *i915)
> {
> intel_dmc_fini(i915);
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
> b/drivers/gpu/drm/i915/display/intel_display_driver.h
> index 947b666575ee..aab498617b90 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
> @@ -12,14 +12,14 @@ struct drm_i915_private;
> struct pci_dev;
>
> bool intel_display_driver_probe_defer(struct pci_dev *pdev);
> -void intel_modeset_init_hw(struct drm_i915_private *i915);
> -int intel_modeset_init_noirq(struct drm_i915_private *i915);
> -int intel_modeset_init_nogem(struct drm_i915_private *i915);
> -int intel_modeset_init(struct drm_i915_private *i915);
> +void intel_display_driver_init_hw(struct drm_i915_private *i915);
> +int intel_display_driver_probe_noirq(struct drm_i915_private *i915);
> +int intel_display_driver_probe_nogem(struct drm_i915_private *i915);
> +int intel_display_driver_probe(struct drm_i915_private *i915);
> void intel_display_driver_register(s
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > On 13/04/2023 10:20, Andi Shyti wrote: > > From: Paulo Zanoni > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > Although in MTL the GUnit misc interrupts register set are > > available only in GT-0, we need to loop through all the GT's > > in order to initialize the media engine which lies on a different > > GT. > > > > Signed-off-by: Paulo Zanoni > > Cc: Tvrtko Ursulin > > Signed-off-by: Andi Shyti > > --- > > Hi, > > > > proposing again this patch, apparently GuC needs this patch to > > initialize the media GT. > > What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. Thanks, Andi (*) [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) status=0X0 [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT [drm] *ERROR* GT1: Enabling uc failed (-5) [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
Re: [Intel-gfx] [PATCH 0/7] Enable YCbCr420 format for VDSC
Hi Suraj, On 07/04/2023 06:11, Kandpal, Suraj wrote: Hi Dmitry -Original Message- From: Dmitry Baryshkov Sent: Friday, April 7, 2023 8:28 AM To: Kandpal, Suraj ; Jani Nikula ; dri-de...@lists.freedesktop.org; intel- g...@lists.freedesktop.org Cc: Nautiyal, Ankit K ; Shankar, Uma ; Maarten Lankhorst Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC Hi Suraj On 28/03/2023 16:20, Kandpal, Suraj wrote: -Original Message- From: dri-devel On Behalf Of Jani Nikula Sent: Wednesday, March 8, 2023 5:00 PM To: Kandpal, Suraj ; dri- de...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org Cc: Dmitry Baryshkov ; Nautiyal, Ankit K ; Shankar, Uma ; Kandpal, Suraj Subject: Re: [PATCH 0/7] Enable YCbCr420 format for VDSC On Wed, 22 Feb 2023, Suraj Kandpal wrote: This patch series aims to enable the YCbCr420 format for DSC. Changes are mostly compute params related for hdmi,dp and dsi along with the addition of new rc_tables for native_420 and corresponding changes to macros used to fetch them. There have been discussions prior to this series in which some patches have gotten rb and can be found in the below link https://patchwork.freedesktop.org/series/113729 I think it would be useful to get [1] from Dmitry merged to drm-misc-next first, have that in drm-next, and again backmerged to drm-intel-next before this. At least patches 1-5. There's not much point in all drivers duplicating the parameters, and we need to move towards common code. Dmitry has been helpful in contributing this to us. BR, Jani. Hi Jani, Maarten has acked the patch series to be merged through drm-intel and in the meantime I will work with Dmitry to pull the common code to avoid duplication I wanted to check, are there any updates from your side regarding the series at [1] ? Will have a look and float comments if any by Monday Please excuse me for being slightly stubborn here. We are slowly getting other patches piled up with dependency on this series. It is fine that it doesn't get into 6.4 (which it probably definitely missed by now), but we would like to know if we have to redo/update anything or if it is fine as is and it is going to be merged by i915 in 6.5 cycle. Thank you for the understanding. Regards, Suraj Kandpal [1] https://patchwork.freedesktop.org/series/114473/ -- With best wishes Dmitry Regards, Suraj Kandpal -- With best wishes Dmitry
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 13/04/2023 14:56, Andi Shyti wrote: Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: On 13/04/2023 10:20, Andi Shyti wrote: From: Paulo Zanoni In multitile systems IRQ need to be reset and enabled per GT. Although in MTL the GUnit misc interrupts register set are available only in GT-0, we need to loop through all the GT's in order to initialize the media engine which lies on a different GT. Signed-off-by: Paulo Zanoni Cc: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi, proposing again this patch, apparently GuC needs this patch to initialize the media GT. What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. I see. It does not sound too challenging to handle with a little bit of refactoring. Move writes engine registers to a helper and add a MTL specific reset/postinstall? Then MTL can do the engine ones outside the for_each_gt loop and the replicated ones under it. Give or take, I did not look into the details. Regards, Tvrtko
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
> From: Jason Gunthorpe
> Sent: Thursday, April 13, 2023 7:51 PM
>
> On Thu, Apr 13, 2023 at 08:25:52AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 13, 2023 4:07 AM
> > >
> > >
> > > > in which case we need c) a way to
> > > > report the overall set of affected devices regardless of ownership in
> > > > support of 4), BDF?
> > >
> > > Yes, continue to use INFO unmodified.
> > >
> > > > Are we back to replacing group-ids with dev-ids in the INFO structure,
> > > > where an invalid dev-id either indicates an affected device with
> > > > implied ownership (ok) or a gap in ownership (bad) and a flag somewhere
> > > > is meant to indicate the overall disposition based on the availability
> > > > of reset?
> > >
> > > As you explore in the following this gets ugly. I prefer to keep INFO
> > > unchanged and add INFO2.
> > >
> >
> > INFO needs a change when VFIO_GROUP is disabled. Now it assumes
> > a valid iommu group always exists:
> >
> > vfio_pci_fill_devs()
> > {
> > ...
> > iommu_group = iommu_group_get(&pdev->dev);
> > if (!iommu_group)
> > return -EPERM; /* Cannot reset non-isolated devices */
> > ...
> > }
>
> This can still work in a ugly way. With a INFO2 the only purpose of
> INFO would be debugging, so if someone uses no-iommu, with hotreset
> and misconfigures it then the only downside is they don't get the
> debugging print. But we know of nothing that uses this combination
> anyhow..
Today, at least QEMU will not go to do hot-reset if _INFO fails. I think
this check may need to be relaxed if want _INFO work when there is
no VFIO_GROUP (also no fake iommu_group).
Regards,
Yi Liu
[Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats: Don't allow request watchdog to interfere
A user reported recently that some subtests are failing. The test was
blocklisted in 2018, so we've lost CI feedback on its results since then.
In 2021, request watchdog with 20 seconds timeout was introduced to i915.
Kernel logs from failed subtest runs indicate that the request watchdog
interfers with engine heartbeat and request preemption used by the test
for exercising reset statistics.
Disable request watchdog during the test execution.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8310
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_reset_stats.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_reset_stats.c b/tests/i915/gem_reset_stats.c
index baa101517d..7b003d88b6 100644
--- a/tests/i915/gem_reset_stats.c
+++ b/tests/i915/gem_reset_stats.c
@@ -906,6 +906,7 @@ igt_main
igt_fixture {
bool has_reset_stats;
bool using_full_reset;
+ char *tmp;
device = drm_open_driver(DRIVER_INTEL);
devid = intel_get_drm_devid(device);
@@ -922,6 +923,12 @@ igt_main
"No reset stats ioctl support. Too old
kernel?\n");
igt_require_f(using_full_reset,
"Full GPU reset is not enabled. Is
enable_hangcheck set?\n");
+
+ /* Don't allow request watchdog to interfere */
+ tmp = __igt_params_get(device, "request_timeout_ms");
+ if (tmp && atoi(tmp))
+ igt_params_save_and_set(device, "request_timeout_ms",
"%u", 0);
+ free(tmp);
}
igt_subtest("params")
--
2.25.1
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Thu, Apr 13, 2023 at 02:35:57PM +, Liu, Yi L wrote: > Today, at least QEMU will not go to do hot-reset if _INFO fails. I think > this check may need to be relaxed if want _INFO work when there is > no VFIO_GROUP (also no fake iommu_group). Current qemu does not work if there is no VFIO_GROUP, so it doesn't matter. In cdev mode qemu should work differently, we can make the kernel return -1 for group_id and qemu can ignore group_id for the debug print, or we can just make it fail. Given qemu doesn't, and can't, support no-iommu this is pretty fringe stuff. Jason
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/debugfs: New debugfs for display clock frequencies (rev2)
== Series Details == Series: drm/i915/debugfs: New debugfs for display clock frequencies (rev2) URL : https://patchwork.freedesktop.org/series/116372/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/debugfs: New debugfs for display clock frequencies (rev2)
== Series Details ==
Series: drm/i915/debugfs: New debugfs for display clock frequencies (rev2)
URL : https://patchwork.freedesktop.org/series/116372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13002 -> Patchwork_116372v2
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/index.html
Participating hosts (36 -> 36)
--
Additional (1): bat-mtlp-8
Missing(1): fi-snb-2520m
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_116372v2:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {bat-mtlp-8}: NOTRUN -> [ABORT][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-mtlp-8/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_116372v2 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3@smem:
- bat-rpls-1: NOTRUN -> [ABORT][2] ([i915#6687] / [i915#7978])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@reset:
- bat-rpls-2: NOTRUN -> [ABORT][3] ([i915#4983] / [i915#7913])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-2/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@slpc:
- bat-rpls-1: NOTRUN -> [DMESG-FAIL][4] ([i915#6367])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-1/igt@i915_selftest@l...@slpc.html
* igt@kms_chamelium_hpd@common-hpd-after-suspend:
- bat-jsl-1: NOTRUN -> [SKIP][5] ([i915#7828])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-jsl-1/igt@kms_chamelium_...@common-hpd-after-suspend.html
Possible fixes
* igt@i915_pm_rps@basic-api:
- bat-dg2-11: [FAIL][6] ([i915#8308]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/bat-dg2-11/igt@i915_pm_...@basic-api.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-dg2-11/igt@i915_pm_...@basic-api.html
* igt@i915_selftest@live@requests:
- bat-rpls-2: [ABORT][8] ([i915#7913] / [i915#7982]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/bat-rpls-2/igt@i915_selftest@l...@requests.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-2/igt@i915_selftest@l...@requests.html
* igt@i915_selftest@live@reset:
- bat-rpls-1: [ABORT][10] ([i915#4983]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/bat-rpls-1/igt@i915_selftest@l...@reset.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-1/igt@i915_selftest@l...@reset.html
* igt@i915_selftest@live@workarounds:
- bat-rpls-1: [DMESG-FAIL][12] ([i915#6763]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/bat-rpls-1/igt@i915_selftest@l...@workarounds.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367
[i915#6687]: https://gitlab.freedesktop.org/drm/intel/issues/6687
[i915#6763]: https://gitlab.freedesktop.org/drm/intel/issues/6763
[i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828
[i915#7913]: https://gitlab.freedesktop.org/drm/intel/issues/7913
[i915#7978]: https://gitlab.freedesktop.org/drm/intel/issues/7978
[i915#7982]: https://gitlab.freedesktop.org/drm/intel/issues/7982
[i915#8308]: https://gitlab.freedesktop.org/drm/intel/issues/8308
Build changes
-
* IGT: IGT_7253 -> IGTPW_8788
* Linux: CI_DRM_13002 -> Patchwork_116372v2
CI-20190529: 20190529
CI_DRM_13002: 687357dbd79393e4cd9a36c84d6efb1eb375da70 @
git://anongit.freedesktop.org/gfx-ci/linux
IGTPW_8788: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_8788/index.html
IGT_7253: 1a619e8dbc6ca887f2ae24b2d7f1ac536342f58c @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_116372v2: 687357dbd79393e4cd9a36c84d6efb1eb375da70 @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
06f56db51c49 drm/i915/debugfs: New debugfs for display clock frequencies
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/index.html
Re: [Intel-gfx] [PATCH] drm/i915/display: Return correct err code for bpc < 0
On Tue, Apr 11, 2023 at 10:22 PM Ville Syrjälä wrote: > > On Tue, Apr 11, 2023 at 05:07:01PM -0700, Manasi Navare wrote: > > On Tue, Apr 11, 2023 at 10:42 AM Ville Syrjälä > > wrote: > > > > > > On Tue, Apr 11, 2023 at 05:34:08PM +, Manasi Navare wrote: > > > > In the function intel_dp_max_bpp(), currently if bpc < 0 in case of > > > > error, > > > > we return 0 instead of returning an err code of -EINVAL. > > > > This throws off the logic in the calling function. > > > > > > What logic? The caller doesn't expect to get an error. > > > > If this returns a 0, we end up using limits.max_bpp = 0 and in > > intel_dp_compute_link_config_wide(), > > since max_bpp is 0, it exits this for loop: > > > > for (bpp = limits->max_bpp; bpp >= limits->min_bpp; bpp -= 2 * 3) and > > returns > > -EINVAL which then wrongly goes to enable DSC even when link BW is > > sufficient without DSC. > > And how woud max_bpp<0 prevent that? > > The real problem seems to be that the DSC code totally > ignores bpp limits. Hi Ville, So I see a few concerns/questions: - Why is the Max bpp value 0 in intel_dp_max_bpp, is that a valid case and how should our link configurations handle that case when max_bpp is 0? - This is happening in a bug I am looking at with HDMI PCON, @Ankit Nautiyal have we ever seen something similar where max_bpp for HDMi PCON is returned 0? - I dont think its a problem with DSC code, but rather intel_dp_compute_link_config() outer for loop where we vary from max_bpp to min_bpp and see if any bpp works with available link bw, how should we handle this when max_bpp = 0 if you are saying thats a valid case? - In this patch if I return -EINVAL instead of 0, then atleast the entire encoder_config will fail and that will fail the modeset, since it assumes max_bpp cannot be 0 Could you please help answer above concerns and how to handle max bpp = 0 case if that is valid? This patch is simply making that invalid resulting into modeset failure Manasi > > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH] drm/i915/color: Fix typo for Plane CSC indexes
> -Original Message-
> From: Intel-gfx On Behalf Of
> Shankar, Uma
> Sent: Friday, March 31, 2023 1:52 AM
> To: Borah, Chaitanya Kumar ; intel-
> g...@lists.freedesktop.org
> Cc: sta...@vger.kernel.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/color: Fix typo for Plane CSC
> indexes
>
>
>
> > -Original Message-
> > From: Borah, Chaitanya Kumar
> > Sent: Thursday, March 30, 2023 8:31 PM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Shankar, Uma ; Borah, Chaitanya Kumar
> > ; sta...@vger.kernel.org
> > Subject: [PATCH] drm/i915/color: Fix typo for Plane CSC indexes
> >
> > Replace _PLANE_INPUT_CSC_RY_GY_2_* with _PLANE_CSC_RY_GY_2_* for
> Plane
> > CSC
> >
> > Fixes: 6eba56f64d5d ("drm/i915/pxp: black pixels on pxp disabled")
>
> Looks Good, thanks for catching it.
> Reviewed-by: Uma Shankar
Pushed the changes to din. Thanks
Regards,
Animesh
>
> > Cc:
> >
> > Signed-off-by: Chaitanya Kumar Borah
>
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index 8e4aca888b7a..85885b01e6ac
> > 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -7496,8 +7496,8 @@ enum skl_power_gate {
> >
> > #define _PLANE_CSC_RY_GY_1(pipe) _PIPE(pipe, _PLANE_CSC_RY_GY_1_A,
> \
> > _PLANE_CSC_RY_GY_1_B)
> > -#define _PLANE_CSC_RY_GY_2(pipe) _PIPE(pipe,
> > _PLANE_INPUT_CSC_RY_GY_2_A, \
> > - _PLANE_INPUT_CSC_RY_GY_2_B)
> > +#define _PLANE_CSC_RY_GY_2(pipe) _PIPE(pipe,
> _PLANE_CSC_RY_GY_2_A, \
> > + _PLANE_CSC_RY_GY_2_B)
> > #define PLANE_CSC_COEFF(pipe, plane, index)
> _MMIO_PLANE(plane, \
> >
> > _PLANE_CSC_RY_GY_1(pipe) + (index) * 4, \
> >
> > _PLANE_CSC_RY_GY_2(pipe) + (index) * 4)
> > --
> > 2.25.1
Re: [Intel-gfx] [PATCH i-g-t] tests/gem_reset_stats: Don't allow request watchdog to interfere
On 13.04.2023 16:36, Janusz Krzysztofik wrote:
A user reported recently that some subtests are failing. The test was
blocklisted in 2018, so we've lost CI feedback on its results since then.
In 2021, request watchdog with 20 seconds timeout was introduced to i915.
Kernel logs from failed subtest runs indicate that the request watchdog
interfers with engine heartbeat and request preemption used by the test
for exercising reset statistics.
Disable request watchdog during the test execution.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/8310
Signed-off-by: Janusz Krzysztofik
---
tests/i915/gem_reset_stats.c | 7 +++
1 file changed, 7 insertions(+)
diff --git a/tests/i915/gem_reset_stats.c b/tests/i915/gem_reset_stats.c
index baa101517d..7b003d88b6 100644
--- a/tests/i915/gem_reset_stats.c
+++ b/tests/i915/gem_reset_stats.c
@@ -906,6 +906,7 @@ igt_main
igt_fixture {
bool has_reset_stats;
bool using_full_reset;
+ char *tmp;
device = drm_open_driver(DRIVER_INTEL);
devid = intel_get_drm_devid(device);
@@ -922,6 +923,12 @@ igt_main
"No reset stats ioctl support. Too old
kernel?\n");
igt_require_f(using_full_reset,
"Full GPU reset is not enabled. Is enable_hangcheck
set?\n");
+
+ /* Don't allow request watchdog to interfere */
+ tmp = __igt_params_get(device, "request_timeout_ms");
With presence of igt_params_scanf it would be simpler.
Reviewed-by: Andrzej Hajda
Regards
Andrzej
+ if (tmp && atoi(tmp))
+ igt_params_save_and_set(device, "request_timeout_ms",
"%u", 0);
+ free(tmp);
}
igt_subtest("params")
Re: [Intel-gfx] [PATCH v4 4/6] drm/i915: Switch to fdinfo helper
On Thu, Apr 13, 2023 at 6:07 AM Tvrtko Ursulin
wrote:
>
>
> On 12/04/2023 23:42, Rob Clark wrote:
> > From: Rob Clark
>
> There is more do to here to remove my client->id fully (would now be
> dead code) so maybe easiest if you drop this patch and I do it after you
> land this and it propagates to our branches? I'd like to avoid pain with
> conflicts if possible..
That is fine by me
BR,
-R
> Regards,
>
> Tvrtko
>
> >
> > Signed-off-by: Rob Clark
> > ---
> > drivers/gpu/drm/i915/i915_driver.c | 3 ++-
> > drivers/gpu/drm/i915/i915_drm_client.c | 18 +-
> > drivers/gpu/drm/i915/i915_drm_client.h | 2 +-
> > 3 files changed, 8 insertions(+), 15 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_driver.c
> > b/drivers/gpu/drm/i915/i915_driver.c
> > index db7a86def7e2..0d91f85f8b97 100644
> > --- a/drivers/gpu/drm/i915/i915_driver.c
> > +++ b/drivers/gpu/drm/i915/i915_driver.c
> > @@ -1696,7 +1696,7 @@ static const struct file_operations i915_driver_fops
> > = {
> > .compat_ioctl = i915_ioc32_compat_ioctl,
> > .llseek = noop_llseek,
> > #ifdef CONFIG_PROC_FS
> > - .show_fdinfo = i915_drm_client_fdinfo,
> > + .show_fdinfo = drm_show_fdinfo,
> > #endif
> > };
> >
> > @@ -1796,6 +1796,7 @@ static const struct drm_driver i915_drm_driver = {
> > .open = i915_driver_open,
> > .lastclose = i915_driver_lastclose,
> > .postclose = i915_driver_postclose,
> > + .show_fdinfo = i915_drm_client_fdinfo,
> >
> > .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> > .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
> > b/drivers/gpu/drm/i915/i915_drm_client.c
> > index b09d1d386574..4a77e5e47f79 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.c
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.c
> > @@ -101,7 +101,7 @@ static u64 busy_add(struct i915_gem_context *ctx,
> > unsigned int class)
> > }
> >
> > static void
> > -show_client_class(struct seq_file *m,
> > +show_client_class(struct drm_printer *p,
> > struct i915_drm_client *client,
> > unsigned int class)
> > {
> > @@ -117,22 +117,20 @@ show_client_class(struct seq_file *m,
> > rcu_read_unlock();
> >
> > if (capacity)
> > - seq_printf(m, "drm-engine-%s:\t%llu ns\n",
> > + drm_printf(p, "drm-engine-%s:\t%llu ns\n",
> > uabi_class_names[class], total);
> >
> > if (capacity > 1)
> > - seq_printf(m, "drm-engine-capacity-%s:\t%u\n",
> > + drm_printf(p, "drm-engine-capacity-%s:\t%u\n",
> > uabi_class_names[class],
> > capacity);
> > }
> >
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f)
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file)
> > {
> > - struct drm_file *file = f->private_data;
> > struct drm_i915_file_private *file_priv = file->driver_priv;
> > struct drm_i915_private *i915 = file_priv->dev_priv;
> > struct i915_drm_client *client = file_priv->client;
> > - struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> > unsigned int i;
> >
> > /*
> > @@ -141,12 +139,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> >* **
> >*/
> >
> > - seq_printf(m, "drm-driver:\t%s\n", i915->drm.driver->name);
> > - seq_printf(m, "drm-pdev:\t%04x:%02x:%02x.%d\n",
> > -pci_domain_nr(pdev->bus), pdev->bus->number,
> > -PCI_SLOT(pdev->devfn), PCI_FUNC(pdev->devfn));
> > - seq_printf(m, "drm-client-id:\t%u\n", client->id);
> > -
> > /*
> >* Temporarily skip showing client engine information with GuC
> > submission till
> >* fetching engine busyness is implemented in the GuC submission
> > backend
> > @@ -155,6 +147,6 @@ void i915_drm_client_fdinfo(struct seq_file *m, struct
> > file *f)
> > return;
> >
> > for (i = 0; i < ARRAY_SIZE(uabi_class_names); i++)
> > - show_client_class(m, client, i);
> > + show_client_class(p, client, i);
> > }
> > #endif
> > diff --git a/drivers/gpu/drm/i915/i915_drm_client.h
> > b/drivers/gpu/drm/i915/i915_drm_client.h
> > index 69496af996d9..ef85fef45de5 100644
> > --- a/drivers/gpu/drm/i915/i915_drm_client.h
> > +++ b/drivers/gpu/drm/i915/i915_drm_client.h
> > @@ -60,7 +60,7 @@ static inline void i915_drm_client_put(struct
> > i915_drm_client *client)
> > struct i915_drm_client *i915_drm_client_add(struct i915_drm_clients
> > *clients);
> >
> > #ifdef CONFIG_PROC_FS
> > -void i915_drm_client_fdinfo(struct seq_file *m, struct file *f);
> > +void i915_drm_client_fdinfo(struct drm_printer *p, struct drm_file *file);
> > #endif
> >
> > void i915_drm_clients_fini(struct i915_drm_clients *clients);
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > Hi Tvrtko, > > (I forgot to CC Daniele) > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > From: Paulo Zanoni > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > Although in MTL the GUnit misc interrupts register set are > > > available only in GT-0, we need to loop through all the GT's > > > in order to initialize the media engine which lies on a different > > > GT. > > > > > > Signed-off-by: Paulo Zanoni > > > Cc: Tvrtko Ursulin > > > Signed-off-by: Andi Shyti > > > --- > > > Hi, > > > > > > proposing again this patch, apparently GuC needs this patch to > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > There are two explanations, one easy and one less easy. > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > The second explanation is that in MTL the media engine has it's > own set of misc irq's registers and those are on a different GT > (Daniele pointed this out). Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; it's just a single sgunit register (0x1900e8) that has different bitfields for the primary GuC and the media GuC. So I still think we should avoid looping over GTs; it's actually much simpler to handle things in a single pass since we can just determine the single register value once (all fields) and write it directly, instead of doing two separate RMW updates to the same register to try to avoid clobbering the other GuC's settings. For pre-MTL platforms, it's the same register, except that the bitfield now devoted to the media GuC was previously used for something else (scatter/gather). Matt > > I sent this patch not to bypass any review, but to restart the > discussion as this patch was just dropped. > > Thanks, > Andi > > > (*) > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > status=0X0 > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > [drm] *ERROR* GT1: Enabling uc failed (-5) > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged! -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH 4/9] drm/i915/mtl: Add vswing programming for C10 phys
On Wed, Apr 12, 2023 at 03:49:20PM -0700, Radhakrishna Sripada wrote:
> From: Mika Kahola
>
> 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
>
> v2: From table "C10: Tx EQ settings for DP 1.4x" it shows level 1
> and preemphasis 1 instead of two times of level 1 preemphasis 0.
> Fix this in the driver code as well.
> v3: VSwing update (Clint)
> v4: Add vboost termination ctl programming(Imre)
> Fix tx llogic and other nits
> Restrict C10 vdr ctl register access for C10 phy(RK)
>
> Cc: Imre Deak
> Cc: Uma Shankar
> Signed-off-by: Clint Taylor
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
> Reviewed-by: Imre Deak (v3)
> ---
> drivers/gpu/drm/i915/display/intel_cx0_phy.c | 102 +-
> drivers/gpu/drm/i915/display/intel_cx0_phy.h | 2 +
> .../gpu/drm/i915/display/intel_cx0_phy_regs.h | 14 ++-
> drivers/gpu/drm/i915/display/intel_ddi.c | 4 +-
> .../drm/i915/display/intel_ddi_buf_trans.c| 31 +-
> 5 files changed, 143 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> index 9ab1e686a40b..ca7626eadd7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_cx0_phy.c
> @@ -6,6 +6,8 @@
> #include "i915_reg.h"
> #include "intel_cx0_phy.h"
> #include "intel_cx0_phy_regs.h"
> +#include "intel_ddi.h"
> +#include "intel_ddi_buf_trans.h"
> #include "intel_de.h"
> #include "intel_display_types.h"
> #include "intel_dp.h"
> @@ -292,6 +294,97 @@ static void intel_cx0_rmw(struct drm_i915_private *i915,
> enum port port,
> __intel_cx0_rmw(i915, port, lane, addr, clear, set, committed);
> }
>
> +static u8 intel_c10_get_tx_vboost_lvl(const struct intel_crtc_state
> *crtc_state)
> +{
> + if (intel_crtc_has_dp_encoder(crtc_state)) {
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
> + (crtc_state->port_clock == 54 ||
> + crtc_state->port_clock == 81))
> + return 5;
> + else
> + return 4;
> + } else {
> + return 5;
> + }
> +}
> +
> +static u8 intel_c10_get_tx_term_ctl(const struct intel_crtc_state
> *crtc_state)
> +{
> + if (intel_crtc_has_dp_encoder(crtc_state)) {
> + if (!intel_crtc_has_type(crtc_state, INTEL_OUTPUT_EDP) &&
> + (crtc_state->port_clock == 54 ||
> + crtc_state->port_clock == 81))
> + return 5;
> + else
> + return 2;
> + } else {
> + return 6;
> + }
> +}
> +
> +void intel_cx0_phy_set_signal_levels(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> + const struct intel_ddi_buf_trans *trans;
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> + intel_wakeref_t wakeref;
> + int n_entries, ln;
> +
> + wakeref = intel_cx0_phy_transaction_begin(encoder);
> +
> + trans = encoder->get_buf_trans(encoder, crtc_state, &n_entries);
> + if (drm_WARN_ON_ONCE(&i915->drm, !trans)) {
> + intel_cx0_phy_transaction_end(encoder, wakeref);
> + return;
> + }
> +
> + if (intel_is_c10phy(i915, phy)) {
> + intel_cx0_rmw(i915, encoder->port, INTEL_CX0_BOTH_LANES,
> PHY_C10_VDR_CONTROL(1),
> + 0, C10_VDR_CTRL_MSGBUS_ACCESS,
> MB_WRITE_COMMITTED);
> + intel_cx0_rmw(i915, encoder->port, INTEL_CX0_LANE0,
> PHY_C10_VDR_CMN(3),
> + C10_CMN3_TXVBOOST_MASK,
> +
> C10_CMN3_TXVBOOST(intel_c10_get_tx_vboost_lvl(crtc_state)),
> + MB_WRITE_UNCOMMITTED);
> + intel_cx0_rmw(i915, encoder->port, INTEL_CX0_LANE0,
> PHY_C10_VDR_TX(1),
> + C10_TX1_TERMCTL_MASK,
> +
> C10_TX1_TERMCTL(intel_c10_get_tx_term_ctl(crtc_state)),
> + MB_WRITE_COMMITTED);
Both PHY lanes need to be programmed for all these vswing settings.
> + }
> +
> + for (ln = 0; ln < crtc_state->lane_count; ln++) {
> + int level = intel_ddi_level(encoder, crtc_state, ln);
> + int lane, tx;
> +
> + lane = ln / 2;
> + tx = ln % 2;
> +
> + intel_cx0_rmw(i915, encoder->port, BIT(lane),
> PHY_CX0_VDROVRD_CTL(lane, tx, 0),
> + C10_PHY_OVRD_LEVEL_MASK,
> +
> C10_PHY_OVRD_LEVEL(trans->entries[level].snps.pre_cursor),
> + MB_WRITE_COMMITTED);
> + intel_cx0_rmw(i915, encoder->port, BIT(lane),
> PHY_CX0_VDR
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, 2023-04-13 at 11:20 +0200, Andi Shyti wrote:
> From: Paulo Zanoni
Hi
https://en.wikipedia.org/wiki/Ship_of_Theseus
My original patch was written in 2018. Since then, the implementation
has been rebased and changed multiple times, the commit message has
been changed, the subject line has been changed, yet none of that is
documented in the patch's revision history: it was all removed and it
now looks like I'm the author of the version that was submitted this
month. I never liked this "erase the internal patch's changelog before
submitting it upstream for the first time" process, I think it erases
crucial information and misleads people.
I know I said something different earlier in private, but after further
reflection, I concluded I do not feel comfortable having my name as the
Author or as the Signed-off-by in this patch. Please remove it. You can
add a "Based-on-patch-by: Paulo Zanoni " if
you want, but that's not necessary.
This should also help in case some bug is bisected to this patch, then
I won't need to spend time researching who I should forward the emails
to.
Thanks,
Paulo
>
> In multitile systems IRQ need to be reset and enabled per GT.
>
> Although in MTL the GUnit misc interrupts register set are
> available only in GT-0, we need to loop through all the GT's
> in order to initialize the media engine which lies on a different
> GT.
>
> Signed-off-by: Paulo Zanoni
> Cc: Tvrtko Ursulin
> Signed-off-by: Andi Shyti
> ---
> Hi,
>
> proposing again this patch, apparently GuC needs this patch to
> initialize the media GT.
>
> Andi
>
> Changelog
> =
> v1 -> v2
> - improve description in the commit log.
>
> drivers/gpu/drm/i915/i915_irq.c | 28 ++--
> 1 file changed, 18 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d24bdea65a3dc..524d64bf5d186 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -2764,14 +2764,19 @@ static void dg1_irq_reset(struct drm_i915_private
> *dev_priv)
> {
> struct intel_gt *gt = to_gt(dev_priv);
> struct intel_uncore *uncore = gt->uncore;
> + unsigned int i;
>
>
>
>
> dg1_master_intr_disable(dev_priv->uncore.regs);
>
>
>
>
> - gen11_gt_irq_reset(gt);
> - gen11_display_irq_reset(dev_priv);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_reset(gt);
>
>
>
>
> - GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> - GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + uncore = gt->uncore;
> + GEN3_IRQ_RESET(uncore, GEN11_GU_MISC_);
> + GEN3_IRQ_RESET(uncore, GEN8_PCU_);
> + }
> +
> + gen11_display_irq_reset(dev_priv);
> }
>
>
>
>
> void gen8_irq_power_well_post_enable(struct drm_i915_private *dev_priv,
> @@ -3425,13 +3430,16 @@ static void gen11_irq_postinstall(struct
> drm_i915_private *dev_priv)
>
>
>
>
> static void dg1_irq_postinstall(struct drm_i915_private *dev_priv)
> {
> - struct intel_gt *gt = to_gt(dev_priv);
> - struct intel_uncore *uncore = gt->uncore;
> u32 gu_misc_masked = GEN11_GU_MISC_GSE;
> + struct intel_gt *gt;
> + unsigned int i;
>
>
>
>
> - gen11_gt_irq_postinstall(gt);
> + for_each_gt(gt, dev_priv, i) {
> + gen11_gt_irq_postinstall(gt);
>
>
>
>
> - GEN3_IRQ_INIT(uncore, GEN11_GU_MISC_, ~gu_misc_masked, gu_misc_masked);
> + GEN3_IRQ_INIT(gt->uncore, GEN11_GU_MISC_, ~gu_misc_masked,
> + gu_misc_masked);
> + }
>
>
>
>
> if (HAS_DISPLAY(dev_priv)) {
> icp_irq_postinstall(dev_priv);
> @@ -3440,8 +3448,8 @@ static void dg1_irq_postinstall(struct drm_i915_private
> *dev_priv)
> GEN11_DISPLAY_IRQ_ENABLE);
> }
>
>
>
>
> - dg1_master_intr_enable(uncore->regs);
> - intel_uncore_posting_read(uncore, DG1_MSTR_TILE_INTR);
> + dg1_master_intr_enable(to_gt(dev_priv)->uncore->regs);
> + intel_uncore_posting_read(to_gt(dev_priv)->uncore, DG1_MSTR_TILE_INTR);
> }
>
>
>
>
> static void cherryview_irq_postinstall(struct drm_i915_private *dev_priv)
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On 4/13/2023 8:52 AM, Matt Roper wrote: On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: Hi Tvrtko, (I forgot to CC Daniele) On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: On 13/04/2023 10:20, Andi Shyti wrote: From: Paulo Zanoni In multitile systems IRQ need to be reset and enabled per GT. Although in MTL the GUnit misc interrupts register set are available only in GT-0, we need to loop through all the GT's in order to initialize the media engine which lies on a different GT. Signed-off-by: Paulo Zanoni Cc: Tvrtko Ursulin Signed-off-by: Andi Shyti --- Hi, proposing again this patch, apparently GuC needs this patch to initialize the media GT. What is the resolution for Matt's concern that this is wrong for MTL? There are two explanations, one easy and one less easy. The easy one: without this patch i915 doesn't boot on MTL!(*) The second explanation is that in MTL the media engine has it's own set of misc irq's registers and those are on a different GT (Daniele pointed this out). Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; it's just a single sgunit register (0x1900e8) that has different bitfields for the primary GuC and the media GuC. So I still think we should avoid looping over GTs; it's actually much simpler to handle things in a single pass since we can just determine the single register value once (all fields) and write it directly, instead of doing two separate RMW updates to the same register to try to avoid clobbering the other GuC's settings. For pre-MTL platforms, it's the same register, except that the bitfield now devoted to the media GuC was previously used for something else (scatter/gather). It's not just the GuC, the VCS/VECS engine programming is also tied to the media GT (via the HAS_ENGINE checks). It looks like we unconditionally program VCS 0 and 2, so it'll still work for MTL, but if we get a device with more VCS engines it'll break. Maybe we can add a MTL version of the function that just programs everything unconditionally? Going forward it should be ok to program things for engines that don't exist, but I'm not sure we can do that for older platforms that came before the extra engines were ever defined in HW. Daniele Matt I sent this patch not to bypass any review, but to restart the discussion as this patch was just dropped. Thanks, Andi (*) [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) status=0X0 [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT [drm] *ERROR* GT1: Enabling uc failed (-5) [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/display: split out high level display entry points
== Series Details ==
Series: drm/i915/display: split out high level display entry points
URL : https://patchwork.freedesktop.org/series/116431/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13001_full -> Patchwork_116431v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116431v1_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-deadline:
- shard-glk: NOTRUN -> [FAIL][1] ([i915#2846])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk2/igt@gem_exec_f...@basic-deadline.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- shard-glk: [PASS][2] -> [FAIL][3] ([i915#2842])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-glk3/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gem_lmem_swapping@verify-ccs:
- shard-glk: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#4613])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk2/igt@gem_lmem_swapp...@verify-ccs.html
* igt@gen9_exec_parse@allowed-all:
- shard-glk: [PASS][5] -> [ABORT][6] ([i915#5566]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-glk4/igt@gen9_exec_pa...@allowed-all.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk9/igt@gen9_exec_pa...@allowed-all.html
* igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#3886]) +3
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk2/igt@kms_ccs@pipe-a-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@2x-long-flip-vs-cursor-legacy:
- shard-glk: [PASS][8] -> [FAIL][9] ([i915#72])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-glk5/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk4/igt@kms_cursor_leg...@2x-long-flip-vs-cursor-legacy.html
* igt@kms_psr2_sf@overlay-primary-update-sf-dmg-area:
- shard-glk: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#658])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk2/igt@kms_psr2...@overlay-primary-update-sf-dmg-area.html
* igt@kms_vrr@negative-basic:
- shard-glk: NOTRUN -> [SKIP][11] ([fdo#109271]) +67 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-glk2/igt@kms_...@negative-basic.html
Possible fixes
* igt@gem_exec_fair@basic-none-solo@rcs0:
- shard-apl: [FAIL][12] ([i915#2842]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-apl7/igt@gem_exec_fair@basic-none-s...@rcs0.html
* igt@gem_exec_fair@basic-none@vcs0:
- {shard-rkl}:[FAIL][14] ([i915#2842]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-rkl-7/igt@gem_exec_fair@basic-n...@vcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-rkl-4/igt@gem_exec_fair@basic-n...@vcs0.html
* igt@gem_exec_suspend@basic-s4-devices@smem:
- {shard-tglu}: [ABORT][16] ([i915#7975]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-tglu-10/igt@gem_exec_suspend@basic-s4-devi...@smem.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-tglu-5/igt@gem_exec_suspend@basic-s4-devi...@smem.html
* igt@i915_pm_rpm@modeset-lpsp:
- {shard-rkl}:[SKIP][18] ([i915#1397]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-rkl-2/igt@i915_pm_...@modeset-lpsp.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-rkl-7/igt@i915_pm_...@modeset-lpsp.html
* igt@kms_big_fb@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip:
- {shard-rkl}:[FAIL][20] ([i915#3743]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13001/shard-rkl-7/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116431v1/shard-rkl-4/igt@kms_big...@x-tiled-max-hw-stride-64bpp-rotate-0-async-flip.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [FAIL][22] ([i915#2346]) -> [PASS][23]
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_
Re: [Intel-gfx] [PATCH 01/10] drm/i915/display: remove intel_display_commit_duplicated_state()
Quoting Jani Nikula (2023-04-13 06:47:27)
> This seems like an unnecessary wrapper layer. Removing it will be
> helpful later.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 28 +++-
> 1 file changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 27b47680573a..1c0149adcf49 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -701,20 +701,6 @@ intel_plane_fence_y_offset(const struct
> intel_plane_state *plane_state)
> return y;
> }
>
> -static int
> -intel_display_commit_duplicated_state(struct intel_atomic_state *state,
> -struct drm_modeset_acquire_ctx *ctx)
> -{
> - struct drm_i915_private *i915 = to_i915(state->base.dev);
> - int ret;
> -
> - ret = drm_atomic_helper_commit_duplicated_state(&state->base, ctx);
> -
> - drm_WARN_ON(&i915->drm, ret == -EDEADLK);
> -
> - return ret;
> -}
> -
> static int
> __intel_display_resume(struct drm_i915_private *i915,
>struct drm_atomic_state *state,
> @@ -722,7 +708,7 @@ __intel_display_resume(struct drm_i915_private *i915,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_crtc *crtc;
> - int i;
> + int ret, i;
>
> intel_modeset_setup_hw_state(i915, ctx);
> intel_vga_redisable(i915);
> @@ -748,7 +734,11 @@ __intel_display_resume(struct drm_i915_private *i915,
> if (!HAS_GMCH(i915))
> to_intel_atomic_state(state)->skip_intermediate_wm = true;
>
> - return intel_display_commit_duplicated_state(to_intel_atomic_state(state),
> ctx);
> + ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
> +
> + drm_WARN_ON(&i915->drm, ret == -EDEADLK);
> +
> + return ret;
> }
>
> static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
> @@ -839,10 +829,12 @@ void intel_display_finish_reset(struct drm_i915_private
> *i915)
> /* reset doesn't touch the display */
> if (!gpu_reset_clobbers_display(i915)) {
> /* for testing only restore the display */
> - ret =
> intel_display_commit_duplicated_state(to_intel_atomic_state(state), ctx);
> - if (ret)
> + ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
> + if (ret) {
> + drm_WARN_ON(&i915->drm, ret == -EDEADLK);
> drm_err(&i915->drm,
> "Restoring old state failed with %i\n", ret);
> + }
> } else {
> /*
> * The display has been reset as well,
> --
> 2.39.2
>
Re: [Intel-gfx] [PATCH 7/9] drm/i915/mtl: Initial DDI port setup
On Wed, Apr 12, 2023 at 03:49:23PM -0700, Radhakrishna Sripada wrote:
Could you move this to the end of the patchset?
> From: Clint Taylor
>
> Initialization sequences and C10 phy are in place to be able to enable
> the first 2 ports of MTL. The other ports use C20 phy that still need
> to be properly added. Enable the first ports for now, keeping a TODO
> comment about the others.
>
> Reviewed-by: Lucas De Marchi
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 6 +-
> 1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 27b47680573a..1fec49c5d23a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7791,7 +7791,11 @@ static void intel_setup_outputs(struct
> drm_i915_private *dev_priv)
> if (!HAS_DISPLAY(dev_priv))
> return;
>
> - if (IS_DG2(dev_priv)) {
> + if (IS_METEORLAKE(dev_priv)) {
> + /* TODO: initialize TC ports as well */
> + intel_ddi_init(dev_priv, PORT_A);
> + intel_ddi_init(dev_priv, PORT_B);
> + } else if (IS_DG2(dev_priv)) {
> intel_ddi_init(dev_priv, PORT_A);
> intel_ddi_init(dev_priv, PORT_B);
> intel_ddi_init(dev_priv, PORT_C);
> --
> 2.34.1
>
Re: [Intel-gfx] [PATCH 6/9] drm/i915/mtl/display: Implement DisplayPort sequences
On Wed, Apr 12, 2023 at 03:49:22PM -0700, Radhakrishna Sripada wrote:
> [...]
> +static void mtl_disable_ddi_buf(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum port port = encoder->port;
> + u32 val;
> +
> + /* 3.b Clear DDI_CTL_DE Enable to 0. */
> + val = intel_de_read(dev_priv, DDI_BUF_CTL(port));
> + if (val & DDI_BUF_CTL_ENABLE) {
> + val &= ~DDI_BUF_CTL_ENABLE;
> + intel_de_write(dev_priv, DDI_BUF_CTL(port), val);
> +
> + /* 3.c Poll for PORT_BUF_CTL Idle Status == 1, timeout after
> 100us */
> + mtl_wait_ddi_buf_idle(dev_priv, port);
> + }
> +
> + /* 3.d Disable D2D Link */
> + mtl_ddi_disable_d2d_link(encoder);
> +
> + /* 3.e Disable DP_TP_CTL */
> + if (intel_crtc_has_dp_encoder(crtc_state)) {
> + val = intel_de_read(dev_priv, dp_tp_ctl_reg(encoder,
> crtc_state));
> + val &= ~(DP_TP_CTL_ENABLE | DP_TP_CTL_LINK_TRAIN_MASK);
Only DP_TP_CTL_ENABLE should be cleared and could use intel_de_rmw().
> + intel_de_write(dev_priv, dp_tp_ctl_reg(encoder, crtc_state),
> val);
> + }
> +}
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote: > > > On 4/13/2023 8:52 AM, Matt Roper wrote: > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > > > Hi Tvrtko, > > > > > > (I forgot to CC Daniele) > > > > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > > > From: Paulo Zanoni > > > > > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > > > > > Although in MTL the GUnit misc interrupts register set are > > > > > available only in GT-0, we need to loop through all the GT's > > > > > in order to initialize the media engine which lies on a different > > > > > GT. > > > > > > > > > > Signed-off-by: Paulo Zanoni > > > > > Cc: Tvrtko Ursulin > > > > > Signed-off-by: Andi Shyti > > > > > --- > > > > > Hi, > > > > > > > > > > proposing again this patch, apparently GuC needs this patch to > > > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > > There are two explanations, one easy and one less easy. > > > > > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > > > > > The second explanation is that in MTL the media engine has it's > > > own set of misc irq's registers and those are on a different GT > > > (Daniele pointed this out). > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; > > it's just a single sgunit register (0x1900e8) that has different > > bitfields for the primary GuC and the media GuC. So I still think we > > should avoid looping over GTs; it's actually much simpler to handle > > things in a single pass since we can just determine the single register > > value once (all fields) and write it directly, instead of doing two > > separate RMW updates to the same register to try to avoid clobbering > > the other GuC's settings. if we handle exceptions in a single pass wouldn't we have many exceptions to handle in the long run? > > For pre-MTL platforms, it's the same register, except that the bitfield > > now devoted to the media GuC was previously used for something else > > (scatter/gather). > > It's not just the GuC, the VCS/VECS engine programming is also tied to the > media GT (via the HAS_ENGINE checks). It looks like we unconditionally > program VCS 0 and 2, so it'll still work for MTL, but if we get a device > with more VCS engines it'll break. Maybe we can add a MTL version of the > function that just programs everything unconditionally? Going forward it > should be ok to program things for engines that don't exist, but I'm not > sure we can do that for older platforms that came before the extra engines > were ever defined in HW. This is more or less what Tvrtko has suggested, as well. Looks to me like replicating some code... anyway, I will try and see how it looks like. Andi PS Thanks Matt, Daniele and Tvrtko for the feedback. > Daniele > > > > > > > Matt > > > > > I sent this patch not to bypass any review, but to restart the > > > discussion as this patch was just dropped. > > > > > > Thanks, > > > Andi > > > > > > > > > (*) > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > > > status=0X0 > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > > > [drm] *ERROR* GT1: Enabling uc failed (-5) > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
Hi Paulo, > https://en.wikipedia.org/wiki/Ship_of_Theseus > > My original patch was written in 2018. Since then, the implementation > has been rebased and changed multiple times, the commit message has > been changed, the subject line has been changed, yet none of that is > documented in the patch's revision history: it was all removed and it > now looks like I'm the author of the version that was submitted this > month. I never liked this "erase the internal patch's changelog before > submitting it upstream for the first time" process, I think it erases > crucial information and misleads people. > > I know I said something different earlier in private, but after further > reflection, I concluded I do not feel comfortable having my name as the > Author or as the Signed-off-by in this patch. Please remove it. You can > add a "Based-on-patch-by: Paulo Zanoni " if > you want, but that's not necessary. > > This should also help in case some bug is bisected to this patch, then > I won't need to spend time researching who I should forward the emails > to. Sure! When porting and back porting patches I try to preserve as much as possible the original authorship. But, if you feel more comfortable, I can take it on me. Andi > Thanks, > Paulo > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > Although in MTL the GUnit misc interrupts register set are > > available only in GT-0, we need to loop through all the GT's > > in order to initialize the media engine which lies on a different > > GT. > > > > Signed-off-by: Paulo Zanoni > > Cc: Tvrtko Ursulin > > Signed-off-by: Andi Shyti
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote: > > > On 4/13/2023 8:52 AM, Matt Roper wrote: > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote: > > > Hi Tvrtko, > > > > > > (I forgot to CC Daniele) > > > > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote: > > > > On 13/04/2023 10:20, Andi Shyti wrote: > > > > > From: Paulo Zanoni > > > > > > > > > > In multitile systems IRQ need to be reset and enabled per GT. > > > > > > > > > > Although in MTL the GUnit misc interrupts register set are > > > > > available only in GT-0, we need to loop through all the GT's > > > > > in order to initialize the media engine which lies on a different > > > > > GT. > > > > > > > > > > Signed-off-by: Paulo Zanoni > > > > > Cc: Tvrtko Ursulin > > > > > Signed-off-by: Andi Shyti > > > > > --- > > > > > Hi, > > > > > > > > > > proposing again this patch, apparently GuC needs this patch to > > > > > initialize the media GT. > > > > What is the resolution for Matt's concern that this is wrong for MTL? > > > There are two explanations, one easy and one less easy. > > > > > > The easy one: without this patch i915 doesn't boot on MTL!(*) > > > > > > The second explanation is that in MTL the media engine has it's > > > own set of misc irq's registers and those are on a different GT > > > (Daniele pointed this out). > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true; > > it's just a single sgunit register (0x1900e8) that has different > > bitfields for the primary GuC and the media GuC. So I still think we > > should avoid looping over GTs; it's actually much simpler to handle > > things in a single pass since we can just determine the single register > > value once (all fields) and write it directly, instead of doing two > > separate RMW updates to the same register to try to avoid clobbering > > the other GuC's settings. > > > > For pre-MTL platforms, it's the same register, except that the bitfield > > now devoted to the media GuC was previously used for something else > > (scatter/gather). > > It's not just the GuC, the VCS/VECS engine programming is also tied to the > media GT (via the HAS_ENGINE checks). It looks like we unconditionally > program VCS 0 and 2, so it'll still work for MTL, but if we get a device > with more VCS engines it'll break. Maybe we can add a MTL version of the > function that just programs everything unconditionally? Going forward it > should be ok to program things for engines that don't exist, but I'm not > sure we can do that for older platforms that came before the extra engines > were ever defined in HW. Right, so I think the engine handling is already correct for MTL today; the main concern would be how it might need to change for other future platforms if more media engines show back up on a media GT. I think we can wait and cross that bridge if/when we get to it. With focus moving over to the Xe KMD, we might be on a completely different driver by the time the hardware adds back in more media engines that aren't already covered unconditionally. Matt > > Daniele > > > > > > > Matt > > > > > I sent this patch not to bypass any review, but to restart the > > > discussion as this patch was just dropped. > > > > > > Thanks, > > > Andi > > > > > > > > > (*) > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7) > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT) > > > status=0X0 > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT > > > [drm] *ERROR* GT1: Enabling uc failed (-5) > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged! > -- Matt Roper Graphics Software Engineer Linux GPU Platform Enablement Intel Corporation
Re: [Intel-gfx] [PATCH 8/9] drm/i915/mtl: Add C10 phy programming for HDMI
On Wed, Apr 12, 2023 at 03:49:24PM -0700, Radhakrishna Sripada wrote:
> [...]
> +/* Precomputed C10 HDMI PLL tables */
> +static const struct intel_c10pll_state mtl_c10_hdmi_25175 = {
> + .clock = 25175,
> + .tx = 0x10,
> + .cmn = 0x1,
> + .pll[0] = 0x34,
> + .pll[1] = 0x00,
> + .pll[2] = 0xB0,
> + .pll[3] = 0x00,
> + .pll[4] = 0x00,
> + .pll[5] = 0x00,
> + .pll[6] = 0x00,
> + .pll[7] = 0x00,
> + .pll[8] = 0x20,
> + .pll[9] = 0xFF,
> + .pll[10] = 0xFF,
> + .pll[11] = 0x55,
> + .pll[12] = 0xE5,
> + .pll[13] = 0x55,
> + .pll[14] = 0x55,
> + .pll[15] = 0x0D,
> + .pll[16] = 0x09,
> + .pll[17] = 0x8F,
> + .pll[18] = 0x84,
> + .pll[19] = 0x23,
> +};
Something off with the above table,
intel_c10pll_calc_port_clock() calculates 25200 clock rate for it. So
either .clock above needs to be the same rate, or the PLL params need to
be corrected for the 25175 rate.
> [...]
> @@ -690,9 +1315,20 @@ static void intel_c10pll_update_pll(struct
> intel_crtc_state *crtc_state,
> static int intel_c10pll_calc_state(struct intel_crtc_state *crtc_state,
> struct intel_encoder *encoder)
> {
> + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> const struct intel_c10pll_state * const *tables;
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> int i;
>
> + if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI)) {
> + if (intel_c10_phy_check_hdmi_link_rate(crtc_state->port_clock)
> + != MODE_OK) {
> + drm_dbg_kms(&i915->drm, "Can't support HDMI link rate
> %d on phy %c.\n",
> + crtc_state->port_clock, phy_name(phy));
> + return -EINVAL;
> + }
> + }
The above check is not needed, covered already by the loop later in
the function.
> +
> tables = intel_c10pll_tables_get(crtc_state, encoder);
> if (!tables)
> return -EINVAL;
Re: [Intel-gfx] [PATCH v2] drm/i915: Make IRQ reset and postinstall multi-gt aware
On Thu, Apr 13, 2023 at 06:19:16PM +0200, Andi Shyti wrote:
> On Thu, Apr 13, 2023 at 09:03:29AM -0700, Ceraolo Spurio, Daniele wrote:
> >
> >
> > On 4/13/2023 8:52 AM, Matt Roper wrote:
> > > On Thu, Apr 13, 2023 at 03:56:21PM +0200, Andi Shyti wrote:
> > > > Hi Tvrtko,
> > > >
> > > > (I forgot to CC Daniele)
> > > >
> > > > On Thu, Apr 13, 2023 at 11:41:28AM +0100, Tvrtko Ursulin wrote:
> > > > > On 13/04/2023 10:20, Andi Shyti wrote:
> > > > > > From: Paulo Zanoni
> > > > > >
> > > > > > In multitile systems IRQ need to be reset and enabled per GT.
> > > > > >
> > > > > > Although in MTL the GUnit misc interrupts register set are
> > > > > > available only in GT-0, we need to loop through all the GT's
> > > > > > in order to initialize the media engine which lies on a different
> > > > > > GT.
> > > > > >
> > > > > > Signed-off-by: Paulo Zanoni
> > > > > > Cc: Tvrtko Ursulin
> > > > > > Signed-off-by: Andi Shyti
> > > > > > ---
> > > > > > Hi,
> > > > > >
> > > > > > proposing again this patch, apparently GuC needs this patch to
> > > > > > initialize the media GT.
> > > > > What is the resolution for Matt's concern that this is wrong for MTL?
> > > > There are two explanations, one easy and one less easy.
> > > >
> > > > The easy one: without this patch i915 doesn't boot on MTL!(*)
> > > >
> > > > The second explanation is that in MTL the media engine has it's
> > > > own set of misc irq's registers and those are on a different GT
> > > > (Daniele pointed this out).
> > > Assuming you're talking about MTL_GUC_MGUC_INTR_MASK, that's not true;
> > > it's just a single sgunit register (0x1900e8) that has different
> > > bitfields for the primary GuC and the media GuC. So I still think we
> > > should avoid looping over GTs; it's actually much simpler to handle
> > > things in a single pass since we can just determine the single register
> > > value once (all fields) and write it directly, instead of doing two
> > > separate RMW updates to the same register to try to avoid clobbering
> > > the other GuC's settings.
>
> if we handle exceptions in a single pass wouldn't we have many
> exceptions to handle in the long run?
I don't think so, it basically boils down to something along the lines
of
if (MEDIA_VER(i915) >= 13)
val = HIGH_BITS | LOW_BITS;
else
val = HIGH_BITS;
...
intel_uncore_write(val);
which isn't really any more complicated than today's logic:
called for each gt {
...
if (gt is MEDIA)
bits = LOW_BITS;
else
bits = HIGH_BITS;
...
intel_uncore_rmw(bits);
}
Matt
>
> > > For pre-MTL platforms, it's the same register, except that the bitfield
> > > now devoted to the media GuC was previously used for something else
> > > (scatter/gather).
> >
> > It's not just the GuC, the VCS/VECS engine programming is also tied to the
> > media GT (via the HAS_ENGINE checks). It looks like we unconditionally
> > program VCS 0 and 2, so it'll still work for MTL, but if we get a device
> > with more VCS engines it'll break. Maybe we can add a MTL version of the
> > function that just programs everything unconditionally? Going forward it
> > should be ok to program things for engines that don't exist, but I'm not
> > sure we can do that for older platforms that came before the extra engines
> > were ever defined in HW.
>
> This is more or less what Tvrtko has suggested, as well. Looks to
> me like replicating some code... anyway, I will try and see how
> it looks like.
>
> Andi
>
> PS Thanks Matt, Daniele and Tvrtko for the feedback.
>
> > Daniele
> >
> > >
> > >
> > > Matt
> > >
> > > > I sent this patch not to bypass any review, but to restart the
> > > > discussion as this patch was just dropped.
> > > >
> > > > Thanks,
> > > > Andi
> > > >
> > > >
> > > > (*)
> > > > [drm] *ERROR* GT1: GUC: CT: No response for request 0x550a (fence 7)
> > > > [drm] *ERROR* GT1: GUC: CT: Sending action 0x550a failed (-ETIMEDOUT)
> > > > status=0X0
> > > > [drm] *ERROR* GT1: GUC: Failed to enable usage stats: -ETIMEDOUT
> > > > [drm] *ERROR* GT1: GuC initialization failed -ETIMEDOUT
> > > > [drm] *ERROR* GT1: Enabling uc failed (-5)
> > > > [drm] *ERROR* GT1: Failed to initialize GPU, declaring it wedged!
--
Matt Roper
Graphics Software Engineer
Linux GPU Platform Enablement
Intel Corporation
[Intel-gfx] [PATCH v2 0/7] drm/i915: CTM stuff mostly
From: Ville Syrjälä Mostly some CTM stuff: - document the uapi better - fix CHV CSC negative coefficients - expose CTM on ilk/snb/vlv - a bonus gamma patch for gen3 - cure CGM CSC underruns on CHV (new in v2) Test-with: 20230411161555.10001-1-ville.syrj...@linux.intel.com Ville Syrjälä (7): drm/uapi: Document CTM matrix better drm/i915: Expose crtc CTM property on ilk/snb drm/i915: Fix CHV CGM CSC coefficient sign handling drm/i915: Always enable CGM CSC on CHV drm/i915: Implement CTM property support for VLV drm/i915: No 10bit gamma on desktop gen3 parts drm/i915: Do state check for color management changes drivers/gpu/drm/i915/display/intel_color.c| 237 -- .../drm/i915/display/intel_crtc_state_dump.c | 6 +- drivers/gpu/drm/i915/display/intel_display.c | 8 + .../drm/i915/display/intel_display_types.h| 3 + .../drm/i915/display/intel_modeset_verify.c | 2 + drivers/gpu/drm/i915/i915_pci.c | 8 +- drivers/gpu/drm/i915/i915_reg.h | 15 ++ include/uapi/drm/drm_mode.h | 5 + 8 files changed, 260 insertions(+), 24 deletions(-) -- 2.39.2
[Intel-gfx] [PATCH v2 2/7] drm/i915: Expose crtc CTM property on ilk/snb
From: Ville Syrjälä The ilk/snb code is internally fully capable of handling the CTM property, so expose it. Note that we still choose not to expose DEGAMMA_LUT though. The hardware is capable if degamma or gamma, but not both similtanously due to lack of the split gamma mode. Exposing both LUTs might encourage userspace to try enabling both at the same time. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_color.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/display/intel_color.c b/drivers/gpu/drm/i915/display/intel_color.c index 07f1afe1d406..4fc16cac052d 100644 --- a/drivers/gpu/drm/i915/display/intel_color.c +++ b/drivers/gpu/drm/i915/display/intel_color.c @@ -3473,7 +3473,7 @@ void intel_color_crtc_init(struct intel_crtc *crtc) gamma_lut_size = INTEL_INFO(i915)->display.color.gamma_lut_size; degamma_lut_size = INTEL_INFO(i915)->display.color.degamma_lut_size; - has_ctm = degamma_lut_size != 0; + has_ctm = DISPLAY_VER(i915) >= 5 && !IS_VALLEYVIEW(i915); /* * "DPALETTE_A: NOTE: The 8-bit (non-10-bit) mode is the -- 2.39.2
[Intel-gfx] [PATCH v2 1/7] drm/uapi: Document CTM matrix better
From: Ville Syrjälä
Document in which order the CTM matrix elements are stored.
Signed-off-by: Ville Syrjälä
---
include/uapi/drm/drm_mode.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 46becedf5b2f..43691058d28f 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -834,6 +834,11 @@ struct drm_color_ctm {
/*
* Conversion matrix in S31.32 sign-magnitude
* (not two's complement!) format.
+*
+* out matrixin
+* |R| |0 1 2| |R|
+* |G| = |3 4 5| x |G|
+* |B| |6 7 8| |B|
*/
__u64 matrix[9];
};
--
2.39.2
[Intel-gfx] [PATCH v2 6/7] drm/i915: No 10bit gamma on desktop gen3 parts
From: Ville Syrjälä
Apparently desktop gen3 parts don't support the
10bit gamma mode at all. Stop claiming otherwise.
As is the case with pipe A on gen3 mobile parts, the
PIPECONF gamma mode bit can be set but it has no
effect on the output.
PNV seems to be the only slight exception, but generally
the desktop PNV variant looks more like a mobile part so
this is not entirely surprising.
Fixes: 67630bacae23 ("drm/i915: Add 10bit gamma mode for gen2/3")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_pci.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index cddb6e197972..305c05c3f93b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -250,13 +250,13 @@ static const struct intel_device_info i865g_info = {
.dma_mask_size = 32, \
I9XX_PIPE_OFFSETS, \
I9XX_CURSOR_OFFSETS, \
- I9XX_COLORS, \
GEN_DEFAULT_PAGE_SIZES, \
GEN_DEFAULT_REGIONS
static const struct intel_device_info i915g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915G),
+ I845_COLORS,
.has_coherent_ggtt = false,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -268,6 +268,7 @@ static const struct intel_device_info i915g_info = {
static const struct intel_device_info i915gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I915GM),
+ I9XX_COLORS,
.is_mobile = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -281,6 +282,7 @@ static const struct intel_device_info i915gm_info = {
static const struct intel_device_info i945g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945G),
+ I845_COLORS,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
.display.has_overlay = 1,
@@ -292,6 +294,7 @@ static const struct intel_device_info i945g_info = {
static const struct intel_device_info i945gm_info = {
GEN3_FEATURES,
PLATFORM(INTEL_I945GM),
+ I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.cursor_needs_physical = 1,
@@ -306,6 +309,7 @@ static const struct intel_device_info i945gm_info = {
static const struct intel_device_info g33_info = {
GEN3_FEATURES,
PLATFORM(INTEL_G33),
+ I845_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -314,6 +318,7 @@ static const struct intel_device_info g33_info = {
static const struct intel_device_info pnv_g_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+ I9XX_COLORS,
.display.has_hotplug = 1,
.display.has_overlay = 1,
.dma_mask_size = 36,
@@ -322,6 +327,7 @@ static const struct intel_device_info pnv_g_info = {
static const struct intel_device_info pnv_m_info = {
GEN3_FEATURES,
PLATFORM(INTEL_PINEVIEW),
+ I9XX_COLORS,
.is_mobile = 1,
.display.has_hotplug = 1,
.display.has_overlay = 1,
--
2.39.2
[Intel-gfx] [PATCH v2 4/7] drm/i915: Always enable CGM CSC on CHV
From: Ville Syrjälä
On CHV toggling the CGM CSC on/off while the pipe is running leads
to underruns. Looks like we'd have to do the toggling strictly inside
the start_of_vblank-frame_start window to avoid this, but that window
is less than a scanline so there's no way we can guarantee hitting it.
As a workaround let's just leave the CGM CSC permanently enabled.
Fortunately the CGM gamma/degamma units don't seem to suffer from
this malady.
I also tried turning off CGM unit clock gating, but that did not
help.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 21 +++--
1 file changed, 19 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 63141f4ed372..7a705e7d8776 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -605,6 +605,16 @@ static void chv_cgm_csc_convert_ctm(const struct
intel_crtc_state *crtc_state,
csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
}
+#define CHV_CGM_CSC_COEFF_1_0 (1 << 12)
+
+static const struct intel_csc_matrix chv_cgm_csc_matrix_identity = {
+ .coeff = {
+ CHV_CGM_CSC_COEFF_1_0, 0, 0,
+ 0, CHV_CGM_CSC_COEFF_1_0, 0,
+ 0, 0, CHV_CGM_CSC_COEFF_1_0,
+ },
+};
+
static void chv_load_cgm_csc(struct intel_crtc *crtc,
const struct intel_csc_matrix *csc)
{
@@ -667,9 +677,9 @@ static void chv_assign_csc(struct intel_crtc_state
*crtc_state)
chv_cgm_csc_convert_ctm(crtc_state, &crtc_state->csc);
} else {
- drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
CGM_PIPE_MODE_CSC) != 0);
+ drm_WARN_ON(&i915->drm, (crtc_state->cgm_mode &
CGM_PIPE_MODE_CSC) == 0);
- intel_csc_clear(&crtc_state->csc);
+ crtc_state->csc = chv_cgm_csc_matrix_identity;
}
}
@@ -2033,6 +2043,13 @@ static u32 chv_cgm_mode(const struct intel_crtc_state
*crtc_state)
!lut_is_legacy(crtc_state->hw.gamma_lut))
cgm_mode |= CGM_PIPE_MODE_GAMMA;
+ /*
+* Toggling the CGM CSC on/off outside of the tiny window
+* between start of vblank and frame start causes underruns.
+* Always enable the CGM CSC as a workaround.
+*/
+ cgm_mode |= CGM_PIPE_MODE_CSC;
+
return cgm_mode;
}
--
2.39.2
[Intel-gfx] [PATCH v2 5/7] drm/i915: Implement CTM property support for VLV
From: Ville Syrjälä
VLV has a so called "wide gamut color correction" unit (WGC).
What it is is a 3x3 matrix similar to the later CHV CGM
CSC, which less precisions/range. In fact CHV also has the WGC
but using it there doesn't reall make sense when you have the
superior CGM CSC around.
Hook up the necessary stuff to expose the WGC as the CTM
crtc property.
One additional crazy idea that came to mind would be to use
the WGC as an output CSC on CHV for YCbCr output. But it
would be incompatible with the legacy LUT usage. In fact
since the WGC lacks post-offsets we'd probably have to
use the legacy LUT to do that final part of the RGB->YCbCr
conversion. Sounds doable, but perhaps not worth the hassle.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c| 170 +-
.../drm/i915/display/intel_crtc_state_dump.c | 6 +-
drivers/gpu/drm/i915/display/intel_display.c | 8 +
.../drm/i915/display/intel_display_types.h| 3 +
drivers/gpu/drm/i915/i915_reg.h | 15 ++
5 files changed, 198 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 7a705e7d8776..e36d8c248b84 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -587,6 +587,98 @@ static u16 ctm_to_twos_complement(u64 coeff, int int_bits,
int frac_bits)
return c & (BIT(int_bits + frac_bits) - 1);
}
+/*
+ * VLV/CHV Wide Gamut Color Correction (WGC) CSC
+ * |r| | c0 c1 c2 | |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b| | c6 c7 c8 | |b|
+ *
+ * Coefficients are two's complement s2.10.
+ */
+static void vlv_wgc_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
+ struct intel_csc_matrix *csc)
+{
+ const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
+ int i;
+
+ for (i = 0; i < 9; i++)
+ csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 2, 10);
+}
+
+static void vlv_load_wgc_csc(struct intel_crtc *crtc,
+const struct intel_csc_matrix *csc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C01_C00(pipe),
+ csc->coeff[1] << 16 | csc->coeff[0]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C02(pipe),
+ csc->coeff[2]);
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C11_C10(pipe),
+ csc->coeff[4] << 16 | csc->coeff[3]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C12(pipe),
+ csc->coeff[5]);
+
+ intel_de_write_fw(dev_priv, PIPE_WGC_C21_C20(pipe),
+ csc->coeff[7] << 16 | csc->coeff[6]);
+ intel_de_write_fw(dev_priv, PIPE_WGC_C22(pipe),
+ csc->coeff[8]);
+}
+
+static void vlv_read_wgc_csc(struct intel_crtc *crtc,
+struct intel_csc_matrix *csc)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ enum pipe pipe = crtc->pipe;
+ u32 tmp;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C01_C00(pipe));
+ csc->coeff[0] = tmp & 0x;
+ csc->coeff[1] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C02(pipe));
+ csc->coeff[2] = tmp & 0x;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C11_C10(pipe));
+ csc->coeff[3] = tmp & 0x;
+ csc->coeff[4] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C12(pipe));
+ csc->coeff[5] = tmp & 0x;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C21_C20(pipe));
+ csc->coeff[6] = tmp & 0x;
+ csc->coeff[7] = tmp >> 16;
+
+ tmp = intel_de_read_fw(dev_priv, PIPE_WGC_C22(pipe));
+ csc->coeff[8] = tmp & 0x;
+}
+
+static void vlv_read_csc(struct intel_crtc_state *crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
+
+ if (crtc_state->wgc_enable)
+ vlv_read_wgc_csc(crtc, &crtc_state->csc);
+}
+
+static void vlv_assign_csc(struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+
+ if (crtc_state->hw.ctm) {
+ drm_WARN_ON(&i915->drm, !crtc_state->wgc_enable);
+
+ vlv_wgc_csc_convert_ctm(crtc_state, &crtc_state->csc);
+ } else {
+ drm_WARN_ON(&i915->drm, crtc_state->wgc_enable);
+
+ intel_csc_clear(&crtc_state->csc);
+ }
+}
+
/*
* CHV Color Gamut Mapping (CGM) CSC
* |r| | c0 c1 c2 | |r|
@@ -672,6 +764,8 @@ static void chv_assign_csc(struct intel_crtc_state
*crtc_state)
{
struct drm_i915_private *i915 = to_i915(crtc_state->uapi.crtc->dev);
+ drm_WARN_ON(&i915->drm, crtc_state->wgc_enable);
+
if (crtc_state->hw.ctm) {
drm_WARN_ON(&i915->drm, (crtc_
[Intel-gfx] [PATCH v2 3/7] drm/i915: Fix CHV CGM CSC coefficient sign handling
From: Ville Syrjälä
The CHV CGM CSC coefficients are in s4.12 two's complement
format. Fix the CTM->CGM conversion to handle that correctly
instead of pretending that the hw coefficients are also
in some sign-magnitude format.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 46 ++
1 file changed, 29 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 4fc16cac052d..63141f4ed372 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -568,29 +568,41 @@ static void icl_load_csc_matrix(const struct
intel_crtc_state *crtc_state)
icl_update_output_csc(crtc, &crtc_state->output_csc);
}
+static u16 ctm_to_twos_complement(u64 coeff, int int_bits, int frac_bits)
+{
+ s64 c = CTM_COEFF_ABS(coeff);
+
+ /* leave an extra bit for rounding */
+ c >>= 32 - frac_bits - 1;
+
+ /* round and drop the extra bit */
+ c = (c + 1) >> 1;
+
+ if (CTM_COEFF_NEGATIVE(coeff))
+ c = -c;
+
+ c = clamp(c, -(s64)BIT(int_bits + frac_bits - 1),
+ (s64)(BIT(int_bits + frac_bits - 1) - 1));
+
+ return c & (BIT(int_bits + frac_bits) - 1);
+}
+
+/*
+ * CHV Color Gamut Mapping (CGM) CSC
+ * |r| | c0 c1 c2 | |r|
+ * |g| = | c3 c4 c5 | x |g|
+ * |b| | c6 c7 c8 | |b|
+ *
+ * Coefficients are two's complement s4.12.
+ */
static void chv_cgm_csc_convert_ctm(const struct intel_crtc_state *crtc_state,
struct intel_csc_matrix *csc)
{
const struct drm_color_ctm *ctm = crtc_state->hw.ctm->data;
int i;
- for (i = 0; i < 9; i++) {
- u64 abs_coeff = ((1ULL << 63) - 1) & ctm->matrix[i];
-
- /* Round coefficient. */
- abs_coeff += 1 << (32 - 13);
- /* Clamp to hardware limits. */
- abs_coeff = clamp_val(abs_coeff, 0, CTM_COEFF_8_0 - 1);
-
- csc->coeff[i] = 0;
-
- /* Write coefficients in S3.12 format. */
- if (ctm->matrix[i] & (1ULL << 63))
- csc->coeff[i] |= 1 << 15;
-
- csc->coeff[i] |= ((abs_coeff >> 32) & 7) << 12;
- csc->coeff[i] |= (abs_coeff >> 20) & 0xfff;
- }
+ for (i = 0; i < 9; i++)
+ csc->coeff[i] = ctm_to_twos_complement(ctm->matrix[i], 4, 12);
}
static void chv_load_cgm_csc(struct intel_crtc *crtc,
--
2.39.2
[Intel-gfx] [PATCH v2 7/7] drm/i915: Do state check for color management changes
From: Ville Syrjälä
In order to validate LUT programming more thoroughly let's
do a state check for all color management updates as well.
Not sure we really want this outside CI. It is rather heavy
and color management updates could become rather common
with all the HDR/etc. stuff happening. Maybe we should have
an extra knob for this that we could enable in CI?
v2: Skip for initial_commit to avoid FDI dotclock
sanity checks/etc. tripping up
Reviewed-by: Uma Shankar
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_modeset_verify.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
index 842d70f0dfd2..9e4767e1b900 100644
--- a/drivers/gpu/drm/i915/display/intel_modeset_verify.c
+++ b/drivers/gpu/drm/i915/display/intel_modeset_verify.c
@@ -228,6 +228,8 @@ void intel_modeset_verify_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *new_crtc_state)
{
if (!intel_crtc_needs_modeset(new_crtc_state) &&
+ (!intel_crtc_needs_color_update(new_crtc_state) ||
+new_crtc_state->inherited) &&
!intel_crtc_needs_fastset(new_crtc_state))
return;
--
2.39.2
Re: [Intel-gfx] [PATCH 3/9] drm/i915/mtl: Add Support for C10 PHY message bus and pll programming
On Wed, Apr 12, 2023 at 03:49:19PM -0700, Radhakrishna Sripada wrote:
> [...]
> @@ -980,21 +981,38 @@ static int hsw_crtc_get_shared_dpll(struct
> intel_atomic_state *state,
> static int dg2_crtc_compute_clock(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> + struct drm_i915_private *i915 = to_i915(state->base.dev);
> struct intel_crtc_state *crtc_state =
> intel_atomic_get_new_crtc_state(state, crtc);
> struct intel_encoder *encoder =
> intel_get_crtc_new_encoder(state, crtc_state);
> + enum phy phy = intel_port_to_phy(i915, encoder->port);
> int ret;
>
> ret = intel_mpllb_calc_state(crtc_state, encoder);
> if (ret)
> return ret;
>
> + /* TODO: Do the readback via intel_compute_shared_dplls() */
> + if (intel_is_c10phy(i915, phy))
> + crtc_state->port_clock = intel_c10pll_calc_port_clock(encoder,
> &crtc_state->cx0pll_state.c10);
> +
Added to the wrong function.
> crtc_state->hw.adjusted_mode.crtc_clock =
> intel_crtc_dotclock(crtc_state);
The above is also missing for mtl.
>
> return 0;
> }
>
> +static int mtl_crtc_compute_clock(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
> +{
> + struct intel_crtc_state *crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + struct intel_encoder *encoder =
> + intel_get_crtc_new_encoder(state, crtc_state);
> +
> + return intel_cx0pll_calc_state(crtc_state, encoder);
> +}
> +
>
> [...]
>
> +/**
> + * REG_FIELD_PREP8() - Prepare a u8 bitfield value
> + * @__mask: shifted mask defining the field's length and position
> + * @__val: value to put in the field
> + *
> + * Local copy of FIELD_PREP8() to generate an integer constant expression,
> force
Local copy of FIELD_PREP()
> + * u8 and for consistency with REG_FIELD_GET8(), REG_BIT8() and
> REG_GENMASK8().
> + *
> + * @return: @__val masked and shifted into the field defined by @__mask.
> + */
> +#define REG_FIELD_PREP8(__mask, __val)
>\
> + ((u8)typeof(__mask))(__val) << __bf_shf(__mask)) & (__mask)) +
> \
> +BUILD_BUG_ON_ZERO(!__is_constexpr(__mask)) + \
> +BUILD_BUG_ON_ZERO((__mask) == 0 || (__mask) > U8_MAX) +
> \
> +BUILD_BUG_ON_ZERO(!IS_POWER_OF_2((__mask) + (1ULL <<
> __bf_shf(__mask + \
> +BUILD_BUG_ON_ZERO(__builtin_choose_expr(__is_constexpr(__val),
> (~((__mask) >> __bf_shf(__mask)) & (__val)), 0
> +
> /**
> * REG_FIELD_GET() - Extract a u32 bitfield value
> * @__mask: shifted mask defining the field's length and position
> @@ -155,6 +200,18 @@
> */
> #define _PICK(__index, ...) (((const u32 []){ __VA_ARGS__ })[__index])
>
Re: [Intel-gfx] [PATCH 9/9] drm/i915/display/mtl: Fill port width in DDI_BUF_/TRANS_DDI_FUNC_/PORT_BUF_CTL for HDMI
On Wed, Apr 12, 2023 at 03:49:25PM -0700, Radhakrishna Sripada wrote:
> From: Ankit Nautiyal
>
> MTL requires the PORT_CTL_WIDTH, TRANS_DDI_FUNC_CTL and DDI_BUF_CTL
> to be filled with 4 lanes for TMDS mode.
> This patch enables D2D link and fills PORT_WIDTH in appropriate
> registers.
>
> v2:
> - Added fixes from Clint's Add HDMI implementation changes.
> - Modified commit message.
> v3:
> - Use TRANS_DDI_PORT_WIDTH() instead of DDI_PORT_WIDTH() for the value
> of TRANS_DDI_FUNC_CTL_*. (Gustavo)
>
> Cc: Taylor, Clinton A
> Signed-off-by: Ankit Nautiyal
> Signed-off-by: Radhakrishna Sripada
> Signed-off-by: Mika Kahola
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 32 ++--
> drivers/gpu/drm/i915/i915_reg.h | 2 ++
> 2 files changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 9df3da46fdca..c5d210a6fb94 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -541,6 +541,8 @@ intel_ddi_transcoder_func_reg_val_get(struct
> intel_encoder *encoder,
> temp |= TRANS_DDI_HDMI_SCRAMBLING;
> if (crtc_state->hdmi_high_tmds_clock_ratio)
> temp |= TRANS_DDI_HIGH_TMDS_CHAR_RATE;
> + if (DISPLAY_VER(dev_priv) >= 14)
> + temp |= TRANS_DDI_PORT_WIDTH(crtc_state->lane_count);
> } else if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_ANALOG)) {
> temp |= TRANS_DDI_MODE_SELECT_FDI_OR_128B132B;
> temp |= (crtc_state->fdi_lanes - 1) << 1;
> @@ -3158,6 +3160,10 @@ static void intel_enable_ddi_hdmi(struct
> intel_atomic_state *state,
> if (has_buf_trans_select(dev_priv))
> hsw_prepare_hdmi_ddi_buffers(encoder, crtc_state);
>
> + /* e. Enable D2D Link for C10/C20 Phy */
> + if (DISPLAY_VER(dev_priv) >= 14)
> + mtl_ddi_enable_d2d(encoder);
> +
> encoder->set_signal_levels(encoder, crtc_state);
>
> /* Display WA #1143: skl,kbl,cfl */
> @@ -3203,12 +3209,30 @@ static void intel_enable_ddi_hdmi(struct
> intel_atomic_state *state,
>*
>* On ADL_P the PHY link rate and lane count must be programmed but
>* these are both 0 for HDMI.
> + *
> + * But MTL onwards HDMI2.1 is supported and in TMDS mode this
> + * is filled with lane count, already set in the crtc_state.
> + * The same is required to be filled in PORT_BUF_CTL for C10/20 Phy.
>*/
> buf_ctl = dig_port->saved_port_bits | DDI_BUF_CTL_ENABLE;
> - if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) {
> + if (DISPLAY_VER(dev_priv) >= 14) {
> + u8 lane_count = mtl_get_port_width(crtc_state->lane_count);
> + u32 port_buf = 0;
> +
> + port_buf |= XELPDP_PORT_WIDTH(lane_count);
> +
> + if (dig_port->saved_port_bits & DDI_BUF_PORT_REVERSAL)
> + port_buf |= XELPDP_PORT_REVERSAL;
> +
> + intel_de_rmw(dev_priv, XELPDP_PORT_BUF_CTL1(port),
> + XELPDP_PORT_WIDTH_MASK | XELPDP_PORT_REVERSAL,
> port_buf);
> +
> + buf_ctl |= DDI_PORT_WIDTH(lane_count);
> + } else if (IS_ALDERLAKE_P(dev_priv) && intel_phy_is_tc(dev_priv, phy)) {
> drm_WARN_ON(&dev_priv->drm,
> !intel_tc_port_in_legacy_mode(dig_port));
> buf_ctl |= DDI_BUF_CTL_TC_PHY_OWNERSHIP;
> }
> +
> intel_de_write(dev_priv, DDI_BUF_CTL(port), buf_ctl);
>
> intel_wait_ddi_buf_active(dev_priv, port);
> @@ -3669,7 +3693,11 @@ static void intel_ddi_read_func_ctl(struct
> intel_encoder *encoder,
> fallthrough;
> case TRANS_DDI_MODE_SELECT_DVI:
> pipe_config->output_types |= BIT(INTEL_OUTPUT_HDMI);
> - pipe_config->lane_count = 4;
> + if (DISPLAY_VER(dev_priv) >= 14)
> + pipe_config->lane_count =
> + ((temp & DDI_PORT_WIDTH_MASK) >>
> DDI_PORT_WIDTH_SHIFT) + 1;
> + else
> + pipe_config->lane_count = 4;
> break;
> case TRANS_DDI_MODE_SELECT_DP_SST:
> if (encoder->type == INTEL_OUTPUT_EDP)
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index d917353d4161..2f0371f8bcf0 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5596,6 +5596,8 @@ enum skl_power_gate {
> #define TRANS_DDI_HDCP_SELECT REG_BIT(5)
> #define TRANS_DDI_BFI_ENABLE(1 << 4)
> #define TRANS_DDI_HIGH_TMDS_CHAR_RATE (1 << 4)
> +#define TRANS_DDI_PORT_WIDTH_MASK REG_GENMASK(3, 1)
> +#define TRANS_DDI_PORT_WIDTH(width)
> REG_FIELD_PREP(TRANS_DDI_PORT_WIDTH_MASK, (width) - 1)
> #define TRANS_DDI_HDMI_SCRAMBLING (1 << 0)
> #define TRANS_DDI
Re: [Intel-gfx] [PATCH 02/10] drm/i915/display: start high level display driver file
Quoting Jani Nikula (2023-04-13 06:47:28)
> The only way to truly clean up intel_display.[ch] is to move stuff out
> of them until there's absolutely nothing left.
>
> Start moving the high level display driver entry points, i.e. functions
> called from top level driver code only, to a new file, which we'll call
> intel_display_driver.c. The intention is that there's no low-level
> display code or details here. This is an in-between layer.
>
> Initially, move intel_display_driver_register() and
> intel_display_driver_unregister() there.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 53 --
> drivers/gpu/drm/i915/display/intel_display.h | 3 -
> .../drm/i915/display/intel_display_driver.c | 71 +++
> .../drm/i915/display/intel_display_driver.h | 15
> drivers/gpu/drm/i915/i915_driver.c| 1 +
> 6 files changed, 88 insertions(+), 56 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_driver.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 97b0d4ae221a..91f0c214ef28 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -237,6 +237,7 @@ i915-y += \
> display/intel_crtc_state_dump.o \
> display/intel_cursor.o \
> display/intel_display.o \
> + display/intel_display_driver.o \
> display/intel_display_power.o \
> display/intel_display_power_map.o \
> display/intel_display_power_well.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 1c0149adcf49..7c66b9ce0db5 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -32,7 +32,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -70,7 +69,6 @@
> #include "intel_crtc_state_dump.h"
> #include "intel_ddi.h"
> #include "intel_de.h"
> -#include "intel_display_debugfs.h"
> #include "intel_display_power.h"
> #include "intel_display_types.h"
> #include "intel_dmc.h"
> @@ -8833,57 +8831,6 @@ bool intel_modeset_probe_defer(struct pci_dev *pdev)
> return false;
> }
>
> -void intel_display_driver_register(struct drm_i915_private *i915)
> -{
> - if (!HAS_DISPLAY(i915))
> - return;
> -
> - /* Must be done after probing outputs */
> - intel_opregion_register(i915);
> - intel_acpi_video_register(i915);
> -
> - intel_audio_init(i915);
> -
> - intel_display_debugfs_register(i915);
> -
> - /*
> - * Some ports require correctly set-up hpd registers for
> - * detection to work properly (leading to ghost connected
> - * connector status), e.g. VGA on gm45. Hence we can only set
> - * up the initial fbdev config after hpd irqs are fully
> - * enabled. We do it last so that the async config cannot run
> - * before the connectors are registered.
> - */
> - intel_fbdev_initial_config_async(i915);
> -
> - /*
> - * We need to coordinate the hotplugs with the asynchronous
> - * fbdev configuration, for which we use the
> - * fbdev->async_cookie.
> - */
> - drm_kms_helper_poll_init(&i915->drm);
> -}
> -
> -void intel_display_driver_unregister(struct drm_i915_private *i915)
> -{
> - if (!HAS_DISPLAY(i915))
> - return;
> -
> - intel_fbdev_unregister(i915);
> - intel_audio_deinit(i915);
> -
> - /*
> - * After flushing the fbdev (incl. a late async config which
> - * will have delayed queuing of a hotplug event), then flush
> - * the hotplug events.
> - */
> - drm_kms_helper_poll_fini(&i915->drm);
> - drm_atomic_helper_shutdown(&i915->drm);
> -
> - acpi_video_unregister();
> - intel_opregion_unregister(i915);
> -}
> -
> bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915)
> {
> return DISPLAY_VER(i915) >= 6 && i915_vtd_active(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index 287159bdeb0d..e46732d26b7c 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -518,9 +518,6 @@ void intel_set_plane_visible(struct intel_crtc_state
> *crtc_state,
> bool visible);
> void intel_plane_fixup_bitmasks(struct intel_crtc_state *crtc_state);
>
> -void intel_display_driver_register(struct drm_i915_private *i915);
> -void intel_display_driver_unregister(struct drm_i915_private *i915);
> -
> void intel_update_watermarks(struct drm_i915_private *i915);
>
> /* modesetting */
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> new file mode 100644
> index ..d4a1893e9218
> --- /dev/null
> +++ b/dri
Re: [Intel-gfx] [PATCH 03/10] drm/i915/display: move intel_modeset_probe_defer() to intel_display_driver.[ch]
Quoting Jani Nikula (2023-04-13 06:47:29)
> High level display functionality only called from driver top level code.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 23 ---
> drivers/gpu/drm/i915/display/intel_display.h | 1 -
> .../drm/i915/display/intel_display_driver.c | 23 +++
> .../drm/i915/display/intel_display_driver.h | 4
> drivers/gpu/drm/i915/i915_pci.c | 1 +
> 5 files changed, 28 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 7c66b9ce0db5..dfec17bb3a7a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -31,7 +31,6 @@
> #include
> #include
> #include
> -#include
>
> #include
> #include
> @@ -40,7 +39,6 @@
> #include
> #include
> #include
> -#include
> #include
> #include
>
> @@ -8810,27 +8808,6 @@ void intel_modeset_driver_remove_nogem(struct
> drm_i915_private *i915)
> intel_bios_driver_remove(i915);
> }
>
> -bool intel_modeset_probe_defer(struct pci_dev *pdev)
> -{
> - struct drm_privacy_screen *privacy_screen;
> -
> - /*
> - * apple-gmux is needed on dual GPU MacBook Pro
> - * to probe the panel if we're the inactive GPU.
> - */
> - if (vga_switcheroo_client_probe_defer(pdev))
> - return true;
> -
> - /* If the LCD panel has a privacy-screen, wait for it */
> - privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
> - if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
> - return true;
> -
> - drm_privacy_screen_put(privacy_screen);
> -
> - return false;
> -}
> -
> bool intel_scanout_needs_vtd_wa(struct drm_i915_private *i915)
> {
> return DISPLAY_VER(i915) >= 6 && i915_vtd_active(i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e46732d26b7c..6ff8faa1b5ac 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -521,7 +521,6 @@ void intel_plane_fixup_bitmasks(struct intel_crtc_state
> *crtc_state);
> void intel_update_watermarks(struct drm_i915_private *i915);
>
> /* modesetting */
> -bool intel_modeset_probe_defer(struct pci_dev *pdev);
> void intel_modeset_init_hw(struct drm_i915_private *i915);
> int intel_modeset_init_noirq(struct drm_i915_private *i915);
> int intel_modeset_init_nogem(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index d4a1893e9218..1386f2001613 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -7,8 +7,10 @@
> * details here.
> */
>
> +#include
> #include
> #include
> +#include
> #include
>
> #include "i915_drv.h"
> @@ -19,6 +21,27 @@
> #include "intel_fbdev.h"
> #include "intel_opregion.h"
>
> +bool intel_modeset_probe_defer(struct pci_dev *pdev)
> +{
> + struct drm_privacy_screen *privacy_screen;
> +
> + /*
> + * apple-gmux is needed on dual GPU MacBook Pro
> + * to probe the panel if we're the inactive GPU.
> + */
> + if (vga_switcheroo_client_probe_defer(pdev))
> + return true;
> +
> + /* If the LCD panel has a privacy-screen, wait for it */
> + privacy_screen = drm_privacy_screen_get(&pdev->dev, NULL);
> + if (IS_ERR(privacy_screen) && PTR_ERR(privacy_screen) == -EPROBE_DEFER)
> + return true;
> +
> + drm_privacy_screen_put(privacy_screen);
> +
> + return false;
> +}
> +
> void intel_display_driver_register(struct drm_i915_private *i915)
> {
> if (!HAS_DISPLAY(i915))
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
> b/drivers/gpu/drm/i915/display/intel_display_driver.h
> index 4f6deef5a23f..4c18792fcafd 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
> @@ -6,8 +6,12 @@
> #ifndef __INTEL_DISPLAY_DRIVER_H__
> #define __INTEL_DISPLAY_DRIVER_H__
>
> +#include
> +
> struct drm_i915_private;
> +struct pci_dev;
>
> +bool intel_modeset_probe_defer(struct pci_dev *pdev);
> void intel_display_driver_register(struct drm_i915_private *i915);
> void intel_display_driver_unregister(struct drm_i915_private *i915);
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index cddb6e197972..bda5caa33f12 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -27,6 +27,7 @@
> #include
>
> #include "display/intel_display.h"
> +#include "display/intel_display_driver.h"
> #include "gt/intel_gt_regs.h"
> #include "gt/intel_sa_media.h"
>
> --
> 2.39.2
>
Re: [Intel-gfx] [PATCH 04/10] drm/i915/display: rename intel_modeset_probe_defer() -> intel_display_driver_probe_defer()
Quoting Jani Nikula (2023-04-13 06:47:30)
> Follow the usual naming conventions.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_display_driver.c | 2 +-
> drivers/gpu/drm/i915/display/intel_display_driver.h | 2 +-
> drivers/gpu/drm/i915/i915_pci.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index 1386f2001613..882a2586aba4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -21,7 +21,7 @@
> #include "intel_fbdev.h"
> #include "intel_opregion.h"
>
> -bool intel_modeset_probe_defer(struct pci_dev *pdev)
> +bool intel_display_driver_probe_defer(struct pci_dev *pdev)
> {
> struct drm_privacy_screen *privacy_screen;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
> b/drivers/gpu/drm/i915/display/intel_display_driver.h
> index 4c18792fcafd..744117b04ed4 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
> @@ -11,7 +11,7 @@
> struct drm_i915_private;
> struct pci_dev;
>
> -bool intel_modeset_probe_defer(struct pci_dev *pdev);
> +bool intel_display_driver_probe_defer(struct pci_dev *pdev);
> void intel_display_driver_register(struct drm_i915_private *i915);
> void intel_display_driver_unregister(struct drm_i915_private *i915);
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index bda5caa33f12..d64e074d7457 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -1355,7 +1355,7 @@ static int i915_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> return -ENXIO;
>
> /* Detect if we need to wait for other drivers early on */
> - if (intel_modeset_probe_defer(pdev))
> + if (intel_display_driver_probe_defer(pdev))
> return -EPROBE_DEFER;
>
> err = i915_driver_probe(pdev, ent);
> --
> 2.39.2
>
Re: [Intel-gfx] [PATCH 07/10] drm/i915/display: add intel_display_reset.[ch]
Quoting Jani Nikula (2023-04-13 06:47:33)
> Split out the display reset functionality to a separate file to
> declutter intel_display.c. Rename the functions accordingly. The minor
> downside is having to expose __intel_display_resume().
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> drivers/gpu/drm/i915/display/intel_display.c | 123 +---
> drivers/gpu/drm/i915/display/intel_display.h | 8 +-
> .../drm/i915/display/intel_display_reset.c| 135 ++
> .../drm/i915/display/intel_display_reset.h| 14 ++
> drivers/gpu/drm/i915/gt/intel_reset.c | 6 +-
> 6 files changed, 160 insertions(+), 127 deletions(-)
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_display_reset.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 91f0c214ef28..39e22cf85e55 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -241,6 +241,7 @@ i915-y += \
> display/intel_display_power.o \
> display/intel_display_power_map.o \
> display/intel_display_power_well.o \
> + display/intel_display_reset.o \
> display/intel_display_rps.o \
> display/intel_dmc.o \
> display/intel_dpio_phy.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index f425e5ed155b..e89e9473a744 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -693,7 +693,7 @@ intel_plane_fence_y_offset(const struct intel_plane_state
> *plane_state)
> return y;
> }
>
> -static int
> +int
> __intel_display_resume(struct drm_i915_private *i915,
>struct drm_atomic_state *state,
>struct drm_modeset_acquire_ctx *ctx)
> @@ -733,127 +733,6 @@ __intel_display_resume(struct drm_i915_private *i915,
> return ret;
> }
>
> -static bool gpu_reset_clobbers_display(struct drm_i915_private *dev_priv)
> -{
> - return (INTEL_INFO(dev_priv)->gpu_reset_clobbers_display &&
> - intel_has_gpu_reset(to_gt(dev_priv)));
> -}
> -
> -void intel_display_prepare_reset(struct drm_i915_private *dev_priv)
> -{
> - struct drm_modeset_acquire_ctx *ctx = &dev_priv->display.restore.reset_ctx;
> - struct drm_atomic_state *state;
> - int ret;
> -
> - if (!HAS_DISPLAY(dev_priv))
> - return;
> -
> - /* reset doesn't touch the display */
> - if (!dev_priv->params.force_reset_modeset_test &&
> - !gpu_reset_clobbers_display(dev_priv))
> - return;
> -
> - /* We have a modeset vs reset deadlock, defensively unbreak it. */
> - set_bit(I915_RESET_MODESET, &to_gt(dev_priv)->reset.flags);
> - smp_mb__after_atomic();
> - wake_up_bit(&to_gt(dev_priv)->reset.flags, I915_RESET_MODESET);
> -
> - if (atomic_read(&dev_priv->gpu_error.pending_fb_pin)) {
> - drm_dbg_kms(&dev_priv->drm,
> - "Modeset potentially stuck, unbreaking through
> wedging\n");
> - intel_gt_set_wedged(to_gt(dev_priv));
> - }
> -
> - /*
> - * Need mode_config.mutex so that we don't
> - * trample ongoing ->detect() and whatnot.
> - */
> - mutex_lock(&dev_priv->drm.mode_config.mutex);
> - drm_modeset_acquire_init(ctx, 0);
> - while (1) {
> - ret = drm_modeset_lock_all_ctx(&dev_priv->drm, ctx);
> - if (ret != -EDEADLK)
> - break;
> -
> - drm_modeset_backoff(ctx);
> - }
> - /*
> - * Disabling the crtcs gracefully seems nicer. Also the
> - * g33 docs say we should at least disable all the planes.
> - */
> - state = drm_atomic_helper_duplicate_state(&dev_priv->drm, ctx);
> - if (IS_ERR(state)) {
> - ret = PTR_ERR(state);
> - drm_err(&dev_priv->drm, "Duplicating state failed with %i\n",
> - ret);
> - return;
> - }
> -
> - ret = drm_atomic_helper_disable_all(&dev_priv->drm, ctx);
> - if (ret) {
> - drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
> - ret);
> - drm_atomic_state_put(state);
> - return;
> - }
> -
> - dev_priv->display.restore.modeset_state = state;
> - state->acquire_ctx = ctx;
> -}
> -
> -void intel_display_finish_reset(struct drm_i915_private *i915)
> -{
> - struct drm_modeset_acquire_ctx *ctx = &i915->display.restore.reset_ctx;
> - struct drm_atomic_state *state;
> - int ret;
> -
> - if (!HAS_DISPLAY(i915))
> - return;
> -
> - /* reset doesn't touch the display */
> - if (!test_bit(I915_RESET_MODESET, &to_gt(i915)->reset.flags))
> - return;
> -
> - state = fetch_and_zero(&i915->display.restore.modeset_state);
> - if (!state)
> - goto unlock;
> -
> - /* reset doesn't touch the display */
> - if (!gpu_reset_clobbers_display(i915)) {
> - /* for te
Re: [Intel-gfx] [PATCH 08/10] drm/i915/display: move display suspend/resume to intel_display_driver.[ch]
Quoting Jani Nikula (2023-04-13 06:47:34)
> High level display functionality only called from driver top level code.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 102 --
> drivers/gpu/drm/i915/display/intel_display.h | 8 --
> .../drm/i915/display/intel_display_driver.c | 101 +
> .../drm/i915/display/intel_display_driver.h | 10 ++
> 4 files changed, 111 insertions(+), 110 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index e89e9473a744..9eb9898885bb 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -693,46 +693,6 @@ intel_plane_fence_y_offset(const struct
> intel_plane_state *plane_state)
> return y;
> }
>
> -int
> -__intel_display_resume(struct drm_i915_private *i915,
> - struct drm_atomic_state *state,
> - struct drm_modeset_acquire_ctx *ctx)
> -{
> - struct drm_crtc_state *crtc_state;
> - struct drm_crtc *crtc;
> - int ret, i;
> -
> - intel_modeset_setup_hw_state(i915, ctx);
> - intel_vga_redisable(i915);
> -
> - if (!state)
> - return 0;
> -
> - /*
> - * We've duplicated the state, pointers to the old state are invalid.
> - *
> - * Don't attempt to use the old state until we commit the duplicated state.
> - */
> - for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> - /*
> - * Force recalculation even if we restore
> - * current state. With fast modeset this may not result
> - * in a modeset when the state is compatible.
> - */
> - crtc_state->mode_changed = true;
> - }
> -
> - /* ignore any reset values/BIOS leftovers in the WM registers */
> - if (!HAS_GMCH(i915))
> - to_intel_atomic_state(state)->skip_intermediate_wm = true;
> -
> - ret = drm_atomic_helper_commit_duplicated_state(state, ctx);
> -
> - drm_WARN_ON(&i915->drm, ret == -EDEADLK);
> -
> - return ret;
> -}
> -
> static void icl_set_pipe_chicken(const struct intel_crtc_state *crtc_state)
> {
> struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
> @@ -2104,30 +2064,6 @@ static void i9xx_crtc_disable(struct
> intel_atomic_state *state,
> i830_enable_pipe(dev_priv, pipe);
> }
>
> -
> -/*
> - * turn all crtc's off, but do not adjust state
> - * This has to be paired with a call to intel_modeset_setup_hw_state.
> - */
> -int intel_display_suspend(struct drm_device *dev)
> -{
> - struct drm_i915_private *dev_priv = to_i915(dev);
> - struct drm_atomic_state *state;
> - int ret;
> -
> - if (!HAS_DISPLAY(dev_priv))
> - return 0;
> -
> - state = drm_atomic_helper_suspend(dev);
> - ret = PTR_ERR_OR_ZERO(state);
> - if (ret)
> - drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
> - ret);
> - else
> - dev_priv->display.restore.modeset_state = state;
> - return ret;
> -}
> -
> void intel_encoder_destroy(struct drm_encoder *encoder)
> {
> struct intel_encoder *intel_encoder = to_intel_encoder(encoder);
> @@ -8280,44 +8216,6 @@ void i830_disable_pipe(struct drm_i915_private
> *dev_priv, enum pipe pipe)
> intel_de_posting_read(dev_priv, DPLL(pipe));
> }
>
> -void intel_display_resume(struct drm_device *dev)
> -{
> - struct drm_i915_private *i915 = to_i915(dev);
> - struct drm_atomic_state *state = i915->display.restore.modeset_state;
> - struct drm_modeset_acquire_ctx ctx;
> - int ret;
> -
> - if (!HAS_DISPLAY(i915))
> - return;
> -
> - i915->display.restore.modeset_state = NULL;
> - if (state)
> - state->acquire_ctx = &ctx;
> -
> - drm_modeset_acquire_init(&ctx, 0);
> -
> - while (1) {
> - ret = drm_modeset_lock_all_ctx(dev, &ctx);
> - if (ret != -EDEADLK)
> - break;
> -
> - drm_modeset_backoff(&ctx);
> - }
> -
> - if (!ret)
> - ret = __intel_display_resume(i915, state, &ctx);
> -
> - skl_watermark_ipc_update(i915);
> - drm_modeset_drop_locks(&ctx);
> - drm_modeset_acquire_fini(&ctx);
> -
> - if (ret)
> - drm_err(&i915->drm,
> - "Restoring old state failed with %i\n", ret);
> - if (state)
> - drm_atomic_state_put(state);
> -}
> -
> void intel_hpd_poll_fini(struct drm_i915_private *i915)
> {
> struct intel_connector *connector;
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e5bf8ef8e06b..c7b1e220e84d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -438,7 +438,6 @@ void intel_add_fb_offsets(int *x, int *y,
> unsigned int intel_rotation_info_size(const struct intel_rotation_info
> *rot_info);
> unsigned int intel_remapped_info_size(const struct intel_rema
Re: [Intel-gfx] [PATCH 09/10] drm/i915/display: rename intel_display_driver_suspend/resume functions
Quoting Jani Nikula (2023-04-13 06:47:35)
> Follow the usual naming conventions. Switch to i915 arguments and naming
> while at it.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> .../drm/i915/display/intel_display_driver.c | 24 +--
> .../drm/i915/display/intel_display_driver.h | 11 -
> .../drm/i915/display/intel_display_reset.c| 2 +-
> drivers/gpu/drm/i915/i915_driver.c| 6 ++---
> 4 files changed, 20 insertions(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index eb03b0a87d5a..d20a279fdf51 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -471,29 +471,28 @@ void intel_display_driver_unregister(struct
> drm_i915_private *i915)
> * turn all crtc's off, but do not adjust state
> * This has to be paired with a call to intel_modeset_setup_hw_state.
> */
> -int intel_display_suspend(struct drm_device *dev)
> +int intel_display_driver_suspend(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *dev_priv = to_i915(dev);
> struct drm_atomic_state *state;
> int ret;
>
> - if (!HAS_DISPLAY(dev_priv))
> + if (!HAS_DISPLAY(i915))
> return 0;
>
> - state = drm_atomic_helper_suspend(dev);
> + state = drm_atomic_helper_suspend(&i915->drm);
> ret = PTR_ERR_OR_ZERO(state);
> if (ret)
> - drm_err(&dev_priv->drm, "Suspending crtc's failed with %i\n",
> + drm_err(&i915->drm, "Suspending crtc's failed with %i\n",
> ret);
> else
> - dev_priv->display.restore.modeset_state = state;
> + i915->display.restore.modeset_state = state;
> return ret;
> }
>
> int
> -__intel_display_resume(struct drm_i915_private *i915,
> - struct drm_atomic_state *state,
> - struct drm_modeset_acquire_ctx *ctx)
> +__intel_display_driver_resume(struct drm_i915_private *i915,
> +struct drm_atomic_state *state,
> +struct drm_modeset_acquire_ctx *ctx)
> {
> struct drm_crtc_state *crtc_state;
> struct drm_crtc *crtc;
> @@ -530,9 +529,8 @@ __intel_display_resume(struct drm_i915_private *i915,
> return ret;
> }
>
> -void intel_display_resume(struct drm_device *dev)
> +void intel_display_driver_resume(struct drm_i915_private *i915)
> {
> - struct drm_i915_private *i915 = to_i915(dev);
> struct drm_atomic_state *state = i915->display.restore.modeset_state;
> struct drm_modeset_acquire_ctx ctx;
> int ret;
> @@ -547,7 +545,7 @@ void intel_display_resume(struct drm_device *dev)
> drm_modeset_acquire_init(&ctx, 0);
>
> while (1) {
> - ret = drm_modeset_lock_all_ctx(dev, &ctx);
> + ret = drm_modeset_lock_all_ctx(&i915->drm, &ctx);
> if (ret != -EDEADLK)
> break;
>
> @@ -555,7 +553,7 @@ void intel_display_resume(struct drm_device *dev)
> }
>
> if (!ret)
> - ret = __intel_display_resume(i915, state, &ctx);
> + ret = __intel_display_driver_resume(i915, state, &ctx);
>
> skl_watermark_ipc_update(i915);
> drm_modeset_drop_locks(&ctx);
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
> b/drivers/gpu/drm/i915/display/intel_display_driver.h
> index 7b5ff4309dec..84e7977f265a 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
> @@ -9,7 +9,6 @@
> #include
>
> struct drm_atomic_state;
> -struct drm_device;
> struct drm_i915_private;
> struct drm_modeset_acquire_ctx;
> struct pci_dev;
> @@ -24,13 +23,13 @@ void intel_display_driver_remove(struct drm_i915_private
> *i915);
> void intel_display_driver_remove_noirq(struct drm_i915_private *i915);
> void intel_display_driver_remove_nogem(struct drm_i915_private *i915);
> void intel_display_driver_unregister(struct drm_i915_private *i915);
> -int intel_display_suspend(struct drm_device *dev);
> -void intel_display_resume(struct drm_device *dev);
> +int intel_display_driver_suspend(struct drm_i915_private *i915);
> +void intel_display_driver_resume(struct drm_i915_private *i915);
>
> /* interface for intel_display_reset.c */
> -int __intel_display_resume(struct drm_i915_private *i915,
> - struct drm_atomic_state *state,
> - struct drm_modeset_acquire_ctx *ctx);
> +int __intel_display_driver_resume(struct drm_i915_private *i915,
> +struct drm_atomic_state *state,
> +struct drm_modeset_acquire_ctx *ctx);
>
> #endif /* __INTEL_DISPLAY_DRIVER_H__ */
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display_reset.c
> b/drivers/gpu/drm/i915/display/intel_display_r
Re: [Intel-gfx] [PATCH 10/10] drm/i915/display: add intel_display_driver_early_probe()
Quoting Jani Nikula (2023-04-13 06:47:36)
> Add intel_display_driver_early_probe() as the early probe call to
> replace intel_init_display_hooks(). The latter will be "demoted" to
> setting up hooks in intel_display.c only.
>
> Signed-off-by: Jani Nikula
Reviewed-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 11 ---
> .../gpu/drm/i915/display/intel_display_driver.c| 14 ++
> .../gpu/drm/i915/display/intel_display_driver.h| 1 +
> drivers/gpu/drm/i915/i915_driver.c | 2 +-
> 4 files changed, 16 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 9eb9898885bb..afc5bc38d006 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -8005,15 +8005,6 @@ static const struct intel_display_funcs
> i9xx_display_funcs = {
> */
> void intel_init_display_hooks(struct drm_i915_private *dev_priv)
> {
> - if (!HAS_DISPLAY(dev_priv))
> - return;
> -
> - intel_color_init_hooks(dev_priv);
> - intel_init_cdclk_hooks(dev_priv);
> - intel_audio_hooks_init(dev_priv);
> -
> - intel_dpll_init_clock_hook(dev_priv);
> -
> if (DISPLAY_VER(dev_priv) >= 9) {
> dev_priv->display.funcs.display = &skl_display_funcs;
> } else if (HAS_DDI(dev_priv)) {
> @@ -8026,8 +8017,6 @@ void intel_init_display_hooks(struct drm_i915_private
> *dev_priv)
> } else {
> dev_priv->display.funcs.display = &i9xx_display_funcs;
> }
> -
> - intel_fdi_init_hook(dev_priv);
> }
>
> int intel_initial_commit(struct drm_device *dev)
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.c
> b/drivers/gpu/drm/i915/display/intel_display_driver.c
> index d20a279fdf51..b3dbfe2a892e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.c
> @@ -32,6 +32,7 @@
> #include "intel_display_types.h"
> #include "intel_dmc.h"
> #include "intel_dp.h"
> +#include "intel_dpll.h"
> #include "intel_dpll_mgr.h"
> #include "intel_fb.h"
> #include "intel_fbc.h"
> @@ -169,6 +170,19 @@ static void intel_plane_possible_crtcs_init(struct
> drm_i915_private *dev_priv)
> }
> }
>
> +void intel_display_driver_early_probe(struct drm_i915_private *i915)
> +{
> + if (!HAS_DISPLAY(i915))
> + return;
> +
> + intel_color_init_hooks(i915);
> + intel_init_cdclk_hooks(i915);
> + intel_audio_hooks_init(i915);
> + intel_dpll_init_clock_hook(i915);
> + intel_init_display_hooks(i915);
> + intel_fdi_init_hook(i915);
> +}
> +
> /* part #1: call before irq install */
> int intel_display_driver_probe_noirq(struct drm_i915_private *i915)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_display_driver.h
> b/drivers/gpu/drm/i915/display/intel_display_driver.h
> index 84e7977f265a..c276a58ee329 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_driver.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_driver.h
> @@ -15,6 +15,7 @@ struct pci_dev;
>
> bool intel_display_driver_probe_defer(struct pci_dev *pdev);
> void intel_display_driver_init_hw(struct drm_i915_private *i915);
> +void intel_display_driver_early_probe(struct drm_i915_private *i915);
> int intel_display_driver_probe_noirq(struct drm_i915_private *i915);
> int intel_display_driver_probe_nogem(struct drm_i915_private *i915);
> int intel_display_driver_probe(struct drm_i915_private *i915);
> diff --git a/drivers/gpu/drm/i915/i915_driver.c
> b/drivers/gpu/drm/i915/i915_driver.c
> index 082393ea3833..8a0a893443b4 100644
> --- a/drivers/gpu/drm/i915/i915_driver.c
> +++ b/drivers/gpu/drm/i915/i915_driver.c
> @@ -252,7 +252,7 @@ static int i915_driver_early_probe(struct
> drm_i915_private *dev_priv)
> intel_detect_pch(dev_priv);
>
> intel_irq_init(dev_priv);
> - intel_init_display_hooks(dev_priv);
> + intel_display_driver_early_probe(dev_priv);
> intel_clock_gating_hooks_init(dev_priv);
>
> intel_detect_preproduction_hw(dev_priv);
> --
> 2.39.2
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/aux: clean up aux name initialization
== Series Details == Series: drm/i915/aux: clean up aux name initialization URL : https://patchwork.freedesktop.org/series/116436/ State : success == Summary == CI Bug Log - changes from CI_DRM_13003 -> Patchwork_116436v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/index.html Participating hosts (36 -> 36) -- Additional (1): fi-kbl-soraka Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_116436v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-kbl-soraka: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-kbl-soraka/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-kbl-soraka: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#4613]) +3 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-kbl-soraka/igt@gem_lmem_swapp...@basic.html * igt@i915_selftest@live@gt_heartbeat: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][3] ([i915#5334] / [i915#7872]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-kbl-soraka/igt@i915_selftest@live@gt_heartbeat.html - fi-apl-guc: [PASS][4] -> [DMESG-FAIL][5] ([i915#5334]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-apl-guc/igt@i915_selftest@live@gt_heartbeat.html * igt@i915_selftest@live@gt_pm: - fi-kbl-soraka: NOTRUN -> [DMESG-FAIL][6] ([i915#1886]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-kbl-soraka/igt@i915_selftest@live@gt_pm.html * igt@kms_chamelium_frames@hdmi-crc-fast: - fi-kbl-soraka: NOTRUN -> [SKIP][7] ([fdo#109271]) +16 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/fi-kbl-soraka/igt@kms_chamelium_fra...@hdmi-crc-fast.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-adlp-9: NOTRUN -> [SKIP][8] ([i915#7828]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/bat-adlp-9/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1: - bat-dg2-8: [PASS][9] -> [FAIL][10] ([i915#7932]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html Possible fixes * igt@i915_selftest@live@uncore: - bat-adlp-9: [ABORT][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-adlp-9/igt@i915_selftest@l...@uncore.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/bat-adlp-9/igt@i915_selftest@l...@uncore.html Warnings * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][13] ([i915#6367]) -> [DMESG-FAIL][14] ([i915#6367] / [i915#7996]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-rpls-1/igt@i915_selftest@l...@slpc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/bat-rpls-1/igt@i915_selftest@l...@slpc.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1886]: https://gitlab.freedesktop.org/drm/intel/issues/1886 [i915#2190]: https://gitlab.freedesktop.org/drm/intel/issues/2190 [i915#4613]: https://gitlab.freedesktop.org/drm/intel/issues/4613 [i915#5334]: https://gitlab.freedesktop.org/drm/intel/issues/5334 [i915#6367]: https://gitlab.freedesktop.org/drm/intel/issues/6367 [i915#7828]: https://gitlab.freedesktop.org/drm/intel/issues/7828 [i915#7872]: https://gitlab.freedesktop.org/drm/intel/issues/7872 [i915#7932]: https://gitlab.freedesktop.org/drm/intel/issues/7932 [i915#7996]: https://gitlab.freedesktop.org/drm/intel/issues/7996 Build changes - * Linux: CI_DRM_13003 -> Patchwork_116436v1 CI-20190529: 20190529 CI_DRM_13003: 9452fe4b47da924d60188cd39d263e5a980db5df @ git://anongit.freedesktop.org/gfx-ci/linux IGT_7254: 7fab01340a3f360abacd7914015be1ad485363d7 @ https://gitlab.freedesktop.org/drm/igt-gpu-tools.git Patchwork_116436v1: 9452fe4b47da924d60188cd39d263e5a980db5df @ git://anongit.freedesktop.org/gfx-ci/linux ### Linux commits a01481818bdf drm/i915/aux: clean up aux name initialization == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116436v1/index.html
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Allow arbitrary refresh rates with VRR eDP panels
Hi Ville,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 04 April 2023 23:24
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/3] drm/i915: Allow arbitrary refresh rates with
> VRR eDP panels
>
> From: Ville Syrjälä
>
> If the panel supports VRR it must be capable of accepting timings with
> arbitrary vblank length, within the valid VRR range. Use that fact to allow
> the
> user to request any refresh rate they like. We simply pick the next highest
> fixed mode from our list, and adjust the vblank to get the desired refresh
> rate in the end.
>
> Of course currently everything to do with the vrefresh is using 1Hz precision,
> so might not be exact. But we can improve that in the future by just upping
> our vrefresh precision.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_panel.c | 80 ++
> 1 file changed, 66 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_panel.c
> b/drivers/gpu/drm/i915/display/intel_panel.c
> index ce2a34a25211..9acdd68b2dbc 100644
> --- a/drivers/gpu/drm/i915/display/intel_panel.c
> +++ b/drivers/gpu/drm/i915/display/intel_panel.c
> @@ -42,6 +42,7 @@
> #include "intel_lvds_regs.h"
> #include "intel_panel.h"
> #include "intel_quirks.h"
> +#include "intel_vrr.h"
>
> bool intel_panel_use_ssc(struct drm_i915_private *i915) { @@ -58,6 +59,38
> @@ intel_panel_preferred_fixed_mode(struct intel_connector *connector)
> struct drm_display_mode, head);
> }
>
> +static bool is_in_vrr_range(struct intel_connector *connector, int
> +vrefresh) {
> + const struct drm_display_info *info = &connector-
> >base.display_info;
> +
> + return intel_vrr_is_capable(connector) &&
> + vrefresh >= info->monitor_range.min_vfreq &&
> + vrefresh <= info->monitor_range.max_vfreq; }
> +
> +static bool is_best_fixed_mode(struct intel_connector *connector,
> +int vrefresh, int fixed_mode_vrefresh,
> +const struct drm_display_mode *best_mode) {
> + /* we want to always return something */
> + if (!best_mode)
> + return true;
> +
> + /*
> + * With VRR always pick a mode with equal/higher than requested
> + * vrefresh, which we can then reduce to match the requested
> + * vrefresh by extending the vblank length.
> + */
> + if (is_in_vrr_range(connector, vrefresh) &&
> + is_in_vrr_range(connector, fixed_mode_vrefresh) &&
> + fixed_mode_vrefresh < vrefresh)
> + return false;
> +
> + /* pick the fixed_mode that is closest in terms of vrefresh */
> + return abs(fixed_mode_vrefresh - vrefresh) <
> + abs(drm_mode_vrefresh(best_mode) - vrefresh); }
> +
> const struct drm_display_mode *
> intel_panel_fixed_mode(struct intel_connector *connector,
> const struct drm_display_mode *mode) @@ -65,11
> +98,11 @@ intel_panel_fixed_mode(struct intel_connector *connector,
> const struct drm_display_mode *fixed_mode, *best_mode = NULL;
> int vrefresh = drm_mode_vrefresh(mode);
>
> - /* pick the fixed_mode that is closest in terms of vrefresh */
> list_for_each_entry(fixed_mode, &connector->panel.fixed_modes,
> head) {
> - if (!best_mode ||
> - abs(drm_mode_vrefresh(fixed_mode) - vrefresh) <
> - abs(drm_mode_vrefresh(best_mode) - vrefresh))
> + int fixed_mode_vrefresh =
> drm_mode_vrefresh(fixed_mode);
> +
> + if (is_best_fixed_mode(connector, vrefresh,
> +fixed_mode_vrefresh, best_mode))
> best_mode = fixed_mode;
> }
>
> @@ -178,27 +211,46 @@ int intel_panel_compute_config(struct
> intel_connector *connector, {
> const struct drm_display_mode *fixed_mode =
> intel_panel_fixed_mode(connector, adjusted_mode);
> + int vrefresh, fixed_mode_vrefresh;
> + bool is_vrr;
>
> if (!fixed_mode)
> return 0;
>
> + vrefresh = drm_mode_vrefresh(adjusted_mode);
> + fixed_mode_vrefresh = drm_mode_vrefresh(fixed_mode);
> +
> /*
> - * We don't want to lie too much to the user about the refresh
> - * rate they're going to get. But we have to allow a bit of latitude
> - * for Xorg since it likes to automagically cook up modes with slightly
> - * off refresh rates.
> + * Assume that we shouldn't muck about with the
> + * timings if they don't land in the VRR range.
>*/
> - if (abs(drm_mode_vrefresh(adjusted_mode) -
> drm_mode_vrefresh(fixed_mode)) > 1) {
> - drm_dbg_kms(connector->base.dev,
> - "[CONNECTOR:%d:%s] Requested mode vrefresh
> (%d Hz) does not match fixed mode vrefresh (%d Hz)\n",
> - connector->base.base.id, connector->base.name,
> -
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Evade transcoder's vblank when doing seamless M/N changes
Hi Ville,
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: 04 April 2023 23:25
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/3] drm/i915: Evade transcoder's vblank when
> doing seamless M/N changes
>
> From: Ville Syrjälä
>
> The transcoder M/N values are double buffered on the transcoder's
> undelayed vblank. So when doing seamless M/N fastsets we need to evade
> also that.
>
> Not that currently the pipe's delayed vblank == transcoder's undelayed
> vblank, so this is still a nop change. But in the future when we may have to
> delay the pipe's vblank to create a register programming window
> ("window2") for the DSB.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_crtc.c | 7 +++
> 1 file changed, 7 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_crtc.c
> b/drivers/gpu/drm/i915/display/intel_crtc.c
> index ed45a6934854..f3b836829296 100644
> --- a/drivers/gpu/drm/i915/display/intel_crtc.c
> +++ b/drivers/gpu/drm/i915/display/intel_crtc.c
> @@ -510,6 +510,13 @@ void intel_pipe_update_start(struct intel_crtc_state
> *new_crtc_state)
>
> VBLANK_EVASION_TIME_US);
> max = vblank_start - 1;
>
> + /*
> + * M/N is double buffered on the transcoder's undelayed vblank,
> + * so with seamless M/N we must evade both vblanks.
> + */
> + if (new_crtc_state->seamless_m_n &&
> intel_crtc_needs_fastset(new_crtc_state))
> + min -= adjusted_mode->crtc_vblank_start -
> +adjusted_mode->crtc_vdisplay;
> +
changes LGTM.
Thanks
Reviewed-by: Mitul Golani > if (min <= 0 || max <= 0)
> goto irq_disable;
>
> --
> 2.39.2
Re: [Intel-gfx] [PATCH v4 08/12] drm/display/dsc: add YCbCr 4:2:2 and 4:2:0 RC parameters
Hi,
> Include RC parameters for YCbCr 4:2:2 and 4:2:0 configurations.
>
Looks Good to me
Reviewed-by: Suraj Kandpal
> 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 a/drivers/gpu/drm/display/drm_dsc_helper.c
> b/drivers/gpu/drm/display/drm_dsc_helper.c
> index aec6f8c201af..65e810a54257 100644
> --- a/drivers/gpu/drm/display/drm_dsc_helper.c
> +++ b/drivers/gpu/drm/display/drm_dsc_helper.c
> @@ -740,6 +740,438 @@ static const struct rc_parameters_data
> rc_parameters_1_2_444[] = {
> { /* sentinel */ }
> };
>
> +static const struct rc_parameters_data rc_parameters_1_2_422[] = {
> + {
> + .bpp = DSC_BPP(6), .bpc = 8,
> + { 512, 15, 6144, 3, 12, 11, 11, {
> + { 0, 4, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 1, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 10, -10 }, { 5, 10, -10 }, { 5, 11,
> -12 },
> + { 5, 11, -12 }, { 9, 12, -12 }, { 12, 13, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 10,
> + { 512, 15, 6144, 7, 16, 15, 15, {
> + { 0, 8, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 5, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
> -8 },
> + { 7, 13, -8 }, { 7, 14, -10 }, { 9, 14, -10 }, { 9, 15,
> -12 },
> + { 9, 15, -12 }, { 13, 16, -12 }, { 16, 17, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 12,
> + { 512, 15, 6144, 11, 20, 19, 19, {
> + { 0, 12, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 9, 14, -2 },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
> 16, -8 },
> + { 11, 17, -8 }, { 11, 18, -10 }, { 13, 18, -10 },
> + { 13, 19, -12 }, { 13, 19, -12 }, { 17, 20, -12 },
> + { 20, 21, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 14,
> + { 512, 15, 6144, 15, 24, 23, 23, {
> + { 0, 12, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 12, 17, -2
> },
> + { 15, 19, -4 }, { 15, 19, -6 }, { 15, 19, -8 }, { 15,
> 20, -8 },
> + { 15, 21, -8 }, { 15, 22, -10 }, { 17, 22, -10 },
> + { 17, 23, -12 }, { 17, 23, -12 }, { 21, 24, -12 },
> + { 24, 25, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(6), .bpc = 16,
> + { 512, 15, 6144, 19, 28, 27, 27, {
> + { 0, 12, 2 }, { 6, 14, 0 }, { 13, 17, 0 }, { 15, 20, -2
> },
> + { 19, 23, -4 }, { 19, 23, -6 }, { 19, 23, -8 }, { 19,
> 24, -8 },
> + { 19, 25, -8 }, { 19, 26, -10 }, { 21, 26, -10 },
> + { 21, 27, -12 }, { 21, 27, -12 }, { 25, 28, -12 },
> + { 28, 29, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 8,
> + { 410, 15, 5632, 3, 12, 11, 11, {
> + { 0, 3, 2 }, { 0, 4, 0 }, { 1, 5, 0 }, { 2, 6, -2 },
> + { 3, 7, -4 }, { 3, 7, -6 }, { 3, 7, -8 }, { 3, 8, -8 },
> + { 3, 9, -8 }, { 3, 9, -10 }, { 5, 10, -10 }, { 5, 10,
> -10 },
> + { 5, 11, -12 }, { 7, 11, -12 }, { 11, 12, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 10,
> + { 410, 15, 5632, 7, 16, 15, 15, {
> + { 0, 7, 2 }, { 4, 8, 0 }, { 5, 9, 0 }, { 6, 10, -2 },
> + { 7, 11, -4 }, { 7, 11, -6 }, { 7, 11, -8 }, { 7, 12,
> -8 },
> + { 7, 13, -8 }, { 7, 13, -10 }, { 9, 14, -10 }, { 9, 14,
> -10 },
> + { 9, 15, -12 }, { 11, 15, -12 }, { 15, 16, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 12,
> + { 410, 15, 5632, 11, 20, 19, 19, {
> + { 0, 11, 2 }, { 4, 12, 0 }, { 9, 13, 0 }, { 10, 14, -2
> },
> + { 11, 15, -4 }, { 11, 15, -6 }, { 11, 15, -8 }, { 11,
> 16, -8 },
> + { 11, 17, -8 }, { 11, 17, -10 }, { 13, 18, -10 },
> + { 13, 18, -10 }, { 13, 19, -12 }, { 15, 19, -12 },
> + { 19, 20, -12 }
> + }
> + }
> + },
> + {
> + .bpp = DSC_BPP(7), .bpc = 14,
> + { 410, 15, 5632, 15, 24, 23, 23, {
> + { 0, 11, 2 }, { 5, 13, 0 }, { 11, 15, 0 }, { 13, 18, -2
>
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Use min() instead of hand rolling it
Hi Ville > -Original Message- > From: Intel-gfx On Behalf Of Ville > Syrjala > Sent: 04 April 2023 23:25 > To: intel-gfx@lists.freedesktop.org > Subject: [Intel-gfx] [PATCH 3/3] drm/i915: Use min() instead of hand rolling > it > > From: Ville Syrjälä > > Most places in the vblank code use min() to clamp scanline counters below > vtotal. But we missed one in the gen3/4 pixel counter based codepath. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/i915/display/intel_vblank.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/display/intel_vblank.c > b/drivers/gpu/drm/i915/display/intel_vblank.c > index f8bf9810527d..136393d99298 100644 > --- a/drivers/gpu/drm/i915/display/intel_vblank.c > +++ b/drivers/gpu/drm/i915/display/intel_vblank.c > @@ -340,8 +340,7 @@ static bool i915_get_crtc_scanoutpos(struct drm_crtc > *_crtc, >* matches how the scanline counter based position works > since >* the scanline counter doesn't count the two half lines. >*/ > - if (position >= vtotal) > - position = vtotal - 1; > + position = min(position, vtotal - 1); changes LGTM. Thanks Reviewed-by: Mitul Golani > > /* >* Start of vblank interrupt is triggered at start of hsync, > -- > 2.39.2
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: hide mkwrite_device_info() better (rev3)
== Series Details == Series: drm/i915: hide mkwrite_device_info() better (rev3) URL : https://patchwork.freedesktop.org/series/113017/ State : warning == Summary == Error: dim checkpatch failed 33d6eac19e2e drm/i915: hide mkwrite_device_info() better -:21: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #21: [1] https://lore.kernel.org/r/a0422f0a8ac055f65b7922bcd3119b180a41e79e.1655712106.git.jani.nik...@intel.com total: 0 errors, 1 warnings, 0 checks, 84 lines checked
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: hide mkwrite_device_info() better (rev3)
== Series Details == Series: drm/i915: hide mkwrite_device_info() better (rev3) URL : https://patchwork.freedesktop.org/series/113017/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
Re: [Intel-gfx] [PATCH v3 12/12] vfio/pci: Report dev_id in VFIO_DEVICE_GET_PCI_HOT_RESET_INFO
On Thu, 13 Apr 2023 08:50:45 -0300
Jason Gunthorpe wrote:
> On Thu, Apr 13, 2023 at 08:25:52AM +, Tian, Kevin wrote:
> > > From: Jason Gunthorpe
> > > Sent: Thursday, April 13, 2023 4:07 AM
> > >
> > >
> > > > in which case we need c) a way to
> > > > report the overall set of affected devices regardless of ownership in
> > > > support of 4), BDF?
> > >
> > > Yes, continue to use INFO unmodified.
> > >
> > > > Are we back to replacing group-ids with dev-ids in the INFO structure,
> > > > where an invalid dev-id either indicates an affected device with
> > > > implied ownership (ok) or a gap in ownership (bad) and a flag somewhere
> > > > is meant to indicate the overall disposition based on the availability
> > > > of reset?
> > >
> > > As you explore in the following this gets ugly. I prefer to keep INFO
> > > unchanged and add INFO2.
> > >
> >
> > INFO needs a change when VFIO_GROUP is disabled. Now it assumes
> > a valid iommu group always exists:
> >
> > vfio_pci_fill_devs()
> > {
> > ...
> > iommu_group = iommu_group_get(&pdev->dev);
> > if (!iommu_group)
> > return -EPERM; /* Cannot reset non-isolated devices */
> > ...
> > }
>
> This can still work in a ugly way. With a INFO2 the only purpose of
> INFO would be debugging, so if someone uses no-iommu, with hotreset
> and misconfigures it then the only downside is they don't get the
> debugging print. But we know of nothing that uses this combination
> anyhow..
>
> > with that plus BDF cap, I'm curious what is the actual purpose of
> > INFO2 or why cannot requirement#3 reuse the information collected
> > via existing INFO?
>
> It can - it is just more complicated for userspace to do it, it has to
> extract and match the BDFs and then run some algorithm to determine if
> the opened devices cover the right set of devices in the reset group,
> and it has to have some special code for no-iommu.
>
> VS info2 would return the dev_id's and a single yes/no if the right
> set is present. Kernel runs the algorithm instead of userspace, it
> seems more abstract this way.
>
> Also, if we make iommufd return a 'ioas dev_id group' as well it
> composes nicely that userspace just needs one translation from dev_id.
IIUC, the semantics we're proposing is that an INFO2 ioctl would return
success or failure indicating whether the user has sufficient ownership
of the affected devices, and in the success case returns an array of
affected dev-ids within the user's iommufd_ctx. Unopened, affected
devices, are not reported via INFO2, and unopened, affected devices
outside the user's scope of ownership (ie. outside the owned IOMMU
group) will generate a failure condition.
As for the INFO ioctl, it's described as unchanged, which does raise
the question of what is reported for IOMMU groups and how does the
value there coherently relate to anything else in the cdev-exclusive
vfio API...
We had already iterated a proposal where the group-id is replaced with
a dev-id in the existing ioctl and a flag indicates when the return
value is a dev-id vs group-id. This had a gap that userspace cannot
determine if a reset is available given this information since un-owned
devices report an invalid dev-id and userspace can't know if it has
implicit ownership.
It seems cleaner to me though that we would could still re-use INFO in
a similar way, simply defining a new flag bit which is valid only in
the case of returning dev-ids and indicates if the reset is available.
Therefore in one ioctl, userspace knows if hot-reset is available
(based on a kernel determination) and can pull valid dev-ids from the
array to associate affected, owned devices, and still has the
equivalent information to know that one or more of the devices listed
with an invalid dev-id are preventing the hot-reset from being
available.
Is that an option? Thanks,
Alex
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: hide mkwrite_device_info() better (rev3)
== Series Details == Series: drm/i915: hide mkwrite_device_info() better (rev3) URL : https://patchwork.freedesktop.org/series/113017/ State : success == Summary == CI Bug Log - changes from CI_DRM_13003 -> Patchwork_113017v3 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/index.html Participating hosts (36 -> 35) -- Missing(1): fi-snb-2520m Known issues Here are the changes found in Patchwork_113017v3 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@migrate: - bat-dg2-11: [PASS][1] -> [DMESG-WARN][2] ([i915#7699]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-dg2-11/igt@i915_selftest@l...@migrate.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-dg2-11/igt@i915_selftest@l...@migrate.html * igt@i915_selftest@live@slpc: - bat-rpls-2: NOTRUN -> [DMESG-FAIL][3] ([i915#6367] / [i915#7913] / [i915#7996]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-2/igt@i915_selftest@l...@slpc.html * igt@kms_chamelium_hpd@common-hpd-after-suspend: - bat-rpls-2: NOTRUN -> [SKIP][4] ([i915#7828]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-2/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-adlp-9: NOTRUN -> [SKIP][5] ([i915#7828]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-adlp-9/igt@kms_chamelium_...@common-hpd-after-suspend.html - bat-rpls-1: NOTRUN -> [SKIP][6] ([i915#7828]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-1/igt@kms_chamelium_...@common-hpd-after-suspend.html * igt@kms_pipe_crc_basic@nonblocking-crc-frame-sequence@pipe-c-dp-1: - bat-dg2-8: [PASS][7] -> [FAIL][8] ([i915#7932]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-crc-frame-seque...@pipe-c-dp-1.html * igt@kms_pipe_crc_basic@read-crc: - bat-adlp-9: NOTRUN -> [SKIP][9] ([i915#3546]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-adlp-9/igt@kms_pipe_crc_ba...@read-crc.html * igt@kms_pipe_crc_basic@read-crc-frame-sequence: - bat-dg2-11: NOTRUN -> [SKIP][10] ([i915#5354]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-dg2-11/igt@kms_pipe_crc_ba...@read-crc-frame-sequence.html * igt@kms_pipe_crc_basic@suspend-read-crc: - bat-rpls-1: NOTRUN -> [SKIP][11] ([i915#1845]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-1/igt@kms_pipe_crc_ba...@suspend-read-crc.html - bat-rpls-2: NOTRUN -> [SKIP][12] ([i915#1845]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-2/igt@kms_pipe_crc_ba...@suspend-read-crc.html Possible fixes * igt@gem_exec_suspend@basic-s3@smem: - bat-rpls-1: [ABORT][13] ([i915#6687] / [i915#7978]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-1/igt@gem_exec_suspend@basic...@smem.html * igt@i915_selftest@live@reset: - bat-rpls-2: [ABORT][15] ([i915#4983] / [i915#7913] / [i915#7981]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-rpls-2/igt@i915_selftest@l...@reset.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-2/igt@i915_selftest@l...@reset.html * igt@i915_selftest@live@slpc: - bat-rpls-1: [DMESG-FAIL][17] ([i915#6367]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-rpls-1/igt@i915_selftest@l...@slpc.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html * igt@i915_selftest@live@uncore: - bat-adlp-9: [ABORT][19] -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-adlp-9/igt@i915_selftest@l...@uncore.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-adlp-9/igt@i915_selftest@l...@uncore.html * igt@kms_pipe_crc_basic@nonblocking-crc@pipe-c-dp-1: - bat-dg2-8: [FAIL][21] ([i915#7932]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13003/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_113017v3/bat-dg2-8/igt@kms_pipe_crc_basic@nonblocking-...@pipe-c-dp-1.html [i915#1845]: htt
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: CTM stuff mostly (rev3)
== Series Details == Series: drm/i915: CTM stuff mostly (rev3) URL : https://patchwork.freedesktop.org/series/116345/ State : warning == Summary == Error: dim checkpatch failed 78b5c06e6a08 drm/uapi: Document CTM matrix better 040d34333d15 drm/i915: Expose crtc CTM property on ilk/snb 025b0a294b12 drm/i915: Fix CHV CGM CSC coefficient sign handling 4c183dda16bc drm/i915: Always enable CGM CSC on CHV 9b4ab15ce12b drm/i915: Implement CTM property support for VLV -:10: WARNING:REPEATED_WORD: Possible repeated word: 'is' #10: What it is is a 3x3 matrix similar to the later CHV CGM total: 0 errors, 1 warnings, 0 checks, 310 lines checked 28846b2d788c drm/i915: No 10bit gamma on desktop gen3 parts deec600a1da5 drm/i915: Do state check for color management changes
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: CTM stuff mostly (rev3)
== Series Details == Series: drm/i915: CTM stuff mostly (rev3) URL : https://patchwork.freedesktop.org/series/116345/ State : warning == Summary == Error: dim sparse failed Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately.
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/debugfs: New debugfs for display clock frequencies (rev2)
== Series Details ==
Series: drm/i915/debugfs: New debugfs for display clock frequencies (rev2)
URL : https://patchwork.freedesktop.org/series/116372/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_13002_full -> Patchwork_116372v2_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (7 -> 7)
--
No changes in participating hosts
Known issues
Here are the changes found in Patchwork_116372v2_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_fair@basic-pace-share@rcs0:
- shard-glk: [PASS][1] -> [FAIL][2] ([i915#2842]) +3 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk8/igt@gem_exec_fair@basic-pace-sh...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][3] -> [ABORT][4] ([i915#5566])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs:
- shard-apl: NOTRUN -> [SKIP][5] ([fdo#109271]) +1 similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-apl6/igt@kms_ccs@pipe-b-bad-aux-stride-y_tiled_gen12_rc_ccs.html
* igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs:
- shard-glk: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#3886]) +1
similar issue
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk2/igt@kms_ccs@pipe-b-missing-ccs-buffer-y_tiled_gen12_mc_ccs.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions:
- shard-glk: [PASS][7] -> [FAIL][8] ([i915#2346])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#2346]) +1 similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-apl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-apl7/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible@a-hdmi-a2:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#79])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-glk9/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk4/igt@kms_flip@flip-vs-expired-vblank-interrupti...@a-hdmi-a2.html
* igt@kms_frontbuffer_tracking@psr-1p-pri-indfb-multidraw:
- shard-glk: NOTRUN -> [SKIP][13] ([fdo#109271]) +40 similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk4/igt@kms_frontbuffer_track...@psr-1p-pri-indfb-multidraw.html
Possible fixes
* igt@drm_fdinfo@most-busy-idle-check-all@rcs0:
- {shard-rkl}:[FAIL][14] ([i915#7742]) -> [PASS][15]
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-rkl-6/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-rkl-4/igt@drm_fdinfo@most-busy-idle-check-...@rcs0.html
* igt@gem_exec_fair@basic-pace-solo@rcs0:
- {shard-rkl}:[FAIL][16] ([i915#2842]) -> [PASS][17]
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-rkl-2/igt@gem_exec_fair@basic-pace-s...@rcs0.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-rkl-6/igt@gem_exec_fair@basic-pace-s...@rcs0.html
* igt@gen9_exec_parse@allowed-single:
- shard-glk: [ABORT][18] ([i915#5566]) -> [PASS][19]
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-glk7/igt@gen9_exec_pa...@allowed-single.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk1/igt@gen9_exec_pa...@allowed-single.html
* igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size:
- shard-glk: [FAIL][20] ([i915#2346]) -> [PASS][21]
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_13002/shard-glk9/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_116372v2/shard-glk3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transi
