Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On 20-09-2022 13:05, Jani Nikula wrote:
> On Tue, 20 Sep 2022, Aravind Iddamsetty wrote:
>> As an integrated GPU, MTL does not have local memory and
>> HAS_LMEM() returns false. However the platform's stolen memory
>> is presented via BAR2 (i.e., the BAR we traditionally consider
>> to be the LMEM BAR) and should be managed by the driver the same
>> way that local memory is on dgpu platforms (which includes
>> setting the "lmem" bit on page table entries). We use the term
>> "local stolen memory" to refer to this model.
>>
>> Cc: Matt Roper
>> Cc: Lucas De Marchi
>>
>> Signed-off-by: CQ Tang
>> Signed-off-by: Aravind Iddamsetty
>> Original-author: CQ Tang
>> ---
>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
>> drivers/gpu/drm/i915/i915_drv.h| 3 +
>> 3 files changed, 100 insertions(+), 18 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>> index acc561c0f0aa..bad5250fb764 100644
>> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
>> *i915,
>> mutex_unlock(&i915->mm.stolen_lock);
>> }
>>
>> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource
>> *dsm)
>
> Abstracting this as a separate function looks like a separate patch.
>
> I generally recommend using positive naming, "is dsm valid", to avoid
> any double negatives that might pop up, now or in the
> future. !is_dsm_invalid() gets slower for human brains to parse.
sure will change it.
Thanks,
Aravind.
>
> BR,
> Jani.
>
>
>> +{
>> +if (!HAS_BAR2_SMEM_STOLEN(i915)) {
>> +if (dsm->start == 0)
>> +return true;
>> +}
>> +
>> +if (dsm->end <= dsm->start)
>> +return true;
>> +
>> +return false;
>> +}
>> +
>> static int i915_adjust_stolen(struct drm_i915_private *i915,
>>struct resource *dsm)
>> {
>> @@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private
>> *i915,
>> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>> struct resource *r;
>>
>> -if (dsm->start == 0 || dsm->end <= dsm->start)
>> +if (is_dsm_invalid(i915, dsm))
>> return -EINVAL;
>>
>> /*
>> @@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private
>> *i915,
>> * overlaps with the non-stolen system memory range, since lmem is local
>> * to the gpu.
>> */
>> -if (HAS_LMEM(i915))
>> +if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
>> return 0;
>>
>> /*
>> @@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct
>> drm_i915_private *i915,
>>
>> drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>>
>> -*base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>> -
>> switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>> case GEN8_STOLEN_RESERVED_1M:
>> *size = 1024 * 1024;
>> @@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
>> drm_i915_private *i915,
>> *size = 8 * 1024 * 1024;
>> MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
>> }
>> +
>> +if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
>> +/* the base is initialized to stolen top so subtract size to
>> get base */
>> +*base -= *size;
>> +else
>> +*base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>> }
>>
>> static int i915_gem_init_stolen(struct intel_memory_region *mem)
>> @@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct
>> intel_memory_region *mem)
>> if (i915_adjust_stolen(i915, &i915->dsm))
>> return 0;
>>
>> -GEM_BUG_ON(i915->dsm.start == 0);
>> -GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
>> +GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
>>
>> stolen_top = i915->dsm.end + 1;
>> reserved_base = stolen_top;
>> @@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
>> i915_region_stolen_lmem_ops = {
>> .init_object = _i915_gem_object_stolen_init,
>> };
>>
>> +static int get_mtl_gms_size(struct intel_uncore *uncore)
>> +{
>> +u16 ggc, gms;
>> +
>> +ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
>> +
>> +/* check GGMS, should be fixed 0x3 (8MB) */
>> +if ((ggc & 0xc0) != 0xc0)
>> +return -EIO;
>> +
>> +/* return valid GMS value, -EIO if invalid */
>> +gms = ggc >> 8;
>> +switch (gms) {
>> +case 0x0 ... 0x10:
>> +return gms * 32;
>> +case 0x20:
>> +return 1024;
>> +case 0x30:
>> +return 1536;
>> +case 0x40:
>> +return 2048;
>> +case 0xf0 ... 0xfe:
>> +return (gms - 0xf0 + 1) * 4;
>> +default:
>> +return -E
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
replying here for earlier comments too.
On 21-09-2022 01:35, Lucas De Marchi wrote:
> On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
>> On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
>>> As an integrated GPU, MTL does not have local memory and
>>> HAS_LMEM() returns false. However the platform's stolen memory
>>> is presented via BAR2 (i.e., the BAR we traditionally consider
>>> to be the LMEM BAR) and should be managed by the driver the same
>>> way that local memory is on dgpu platforms (which includes
>>> setting the "lmem" bit on page table entries). We use the term
>>> "local stolen memory" to refer to this model.
>>>
>>> Cc: Matt Roper
>>> Cc: Lucas De Marchi
>>>
>>> Signed-off-by: CQ Tang
>>> Signed-off-by: Aravind Iddamsetty
>>> Original-author: CQ Tang
>>> ---
>>> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
>>> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
>>> drivers/gpu/drm/i915/i915_drv.h | 3 +
>>> 3 files changed, 100 insertions(+), 18 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> index acc561c0f0aa..bad5250fb764 100644
>>> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
>>> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct
>>> drm_i915_private *i915,
>>> mutex_unlock(&i915->mm.stolen_lock);
>>> }
>>>
>>> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct
>>> resource *dsm)
>>> +{
>>> + if (!HAS_BAR2_SMEM_STOLEN(i915)) {
>>
>> I called a similar function as is_dsm_valid() in
>> https://patchwork.freedesktop.org/series/108620/
>>
>> sounds weird with "invalid" and the double negation on return early
>> style.
sure, will change it hope i can use that from your patch.
>>
>>> + if (dsm->start == 0)
>>> + return true;
>>> + }
>>> +
>>> + if (dsm->end <= dsm->start)
>>> + return true;
>>> +
>>> + return false;
>>> +}
>>> +
>>> static int i915_adjust_stolen(struct drm_i915_private *i915,
>>> struct resource *dsm)
>>> {
>>> @@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct
>>> drm_i915_private *i915,
>>> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>>> struct resource *r;
>>>
>>> - if (dsm->start == 0 || dsm->end <= dsm->start)
>>> + if (is_dsm_invalid(i915, dsm))
>>> return -EINVAL;
>>>
>>> /*
>>> @@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct
>>> drm_i915_private *i915,
>>> * overlaps with the non-stolen system memory range, since lmem
>>> is local
>>> * to the gpu.
>>> */
>>> - if (HAS_LMEM(i915))
>>> + if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
>>
>> comment above makes no sense when you add this. For this specific case
>> it's still system memory, reserved by the BIOS and that we access by
>> mapping the lmembar
thanks for catching this.
>>
>>> return 0;
>>>
>>> /*
>>> @@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct
>>> drm_i915_private *i915,
>>>
>>> drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>>>
>>> - *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>>> -
>>> switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
>>> case GEN8_STOLEN_RESERVED_1M:
>>> *size = 1024 * 1024;
>>> @@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
>>> drm_i915_private *i915,
>>> *size = 8 * 1024 * 1024;
>>> MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
>>> }
>>> +
>>> + if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
>>> + /* the base is initialized to stolen top so subtract size to
>>> get base */
>>> + *base -= *size;
>>
>> that doesn't necessarily holds true. According to the spec the wopcm
>> base is 1MB aligned so even if it is "at the top", it may not mean it
>> is at the
>> very very top that we can just subtract the size.
well here the reserved_base is not to the top of the BAR, we got the
stolen size from GGC register so base is initialized to end of that
stolen size. hence we subtract the reserved size from it.
>>
>>
>>> + else
>>> + *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
>>> }
>>>
>>> static int i915_gem_init_stolen(struct intel_memory_region *mem)
>>> @@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct
>>> intel_memory_region *mem)
>>> if (i915_adjust_stolen(i915, &i915->dsm))
>>> return 0;
>>>
>>> - GEM_BUG_ON(i915->dsm.start == 0);
>>> - GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
>>> + GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
>>>
>>> stolen_top = i915->dsm.end + 1;
>>> reserved_base = stolen_top;
>>> @@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
>>> i915_region_stolen_lmem_ops = {
>>> .init_object = _i915_gem_object_stolen_init,
>>> };
>>>
>>> +static int get_mtl_gms_size(struct
[Intel-gfx] [PATCH] drm/i915/psr: Fix PSR_IMR/IIR field handling
Current PSR code is assuming TRANSCODER_EDP == 0. This is not the case
and all fields in PSR_IMR and PSR_IIR are shifted incorrectly if
DISPLAY_VER >= 12.
Fix this by using TRANSCODER_EDP definition instead of 0.
Cc: Mika Kahola
Cc: José Roberto de Souza
Signed-off-by: Jouni Högander
---
drivers/gpu/drm/i915/display/intel_psr.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 9def8d9fade6..9ecf1a9a1120 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -129,7 +129,7 @@ static void psr_irq_control(struct intel_dp *intel_dp)
* 0 shift in bit definition
*/
if (DISPLAY_VER(dev_priv) >= 12) {
- trans_shift = 0;
+ trans_shift = TRANSCODER_EDP;
imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
} else {
trans_shift = intel_dp->psr.transcoder;
@@ -195,7 +195,7 @@ void intel_psr_irq_handler(struct intel_dp *intel_dp, u32
psr_iir)
i915_reg_t imr_reg;
if (DISPLAY_VER(dev_priv) >= 12) {
- trans_shift = 0;
+ trans_shift = TRANSCODER_EDP;
imr_reg = TRANS_PSR_IMR(intel_dp->psr.transcoder);
} else {
trans_shift = intel_dp->psr.transcoder;
@@ -1197,7 +1197,7 @@ static bool psr_interrupt_error_check(struct intel_dp
*intel_dp)
if (DISPLAY_VER(dev_priv) >= 12) {
val = intel_de_read(dev_priv,
TRANS_PSR_IIR(intel_dp->psr.transcoder));
- val &= EDP_PSR_ERROR(0);
+ val &= EDP_PSR_ERROR(TRANSCODER_EDP);
} else {
val = intel_de_read(dev_priv, EDP_PSR_IIR);
val &= EDP_PSR_ERROR(intel_dp->psr.transcoder);
--
2.34.1
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dgfx: Release mmap on rpm suspend
> -Original Message-
> From: Matthew Auld
> Sent: Tuesday, September 20, 2022 7:30 PM
> To: Gupta, Anshuman
> Cc: intel-gfx@lists.freedesktop.org; ch...@chris-wilson.co.uk; Auld, Matthew
> ; Vivi, Rodrigo
> Subject: Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dgfx: Release mmap on rpm
> suspend
>
> On Tue, 13 Sept 2022 at 16:27, Anshuman Gupta
> wrote:
> >
> > Release all mmap mapping for all lmem objects which are associated
> > with userfault such that, while pcie function in D3hot, any access to
> > memory mappings will raise a userfault.
> >
> > Runtime resume the dgpu(when gem object lies in lmem).
> > This will transition the dgpu graphics function to D0 state if it was
> > in D3 in order to access the mmap memory mappings.
> >
> > v2:
> > - Squashes the patches. [Matt Auld]
> > - Add adequate locking for lmem_userfault_list addition. [Matt Auld]
> > - Reused obj->userfault_count to avoid double addition. [Matt Auld]
> > - Added i915_gem_object_lock to check
> > i915_gem_object_is_lmem. [Matt Auld]
> >
> > v3:
> > - Use i915_ttm_cpu_maps_iomem. [Matt Auld]
> > - Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld]
> > - Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld]
> > - Delete the mmaped obj from lmem_userfault_list in obj
> > destruction path. [Matt Auld]
> > - Get a wakeref for object destruction patch. [Matt Auld]
> > - Use intel_wakeref_auto to delay runtime PM. [Matt Auld]
> >
> > v4:
> > - Avoid using mmo offset to get the vma_node. [Matt Auld]
> > - Added comment to use the lmem_userfault_lock. [Matt Auld]
> > - Get lmem_userfault_lock in i915_gem_object_release_mmap_offset.
> > [Matt Auld]
> > - Fixed kernel test robot generated warning.
> >
> > v5:
> > - Addressed the cosmetics comments. [Andi]
> > - Changed i915_gem_runtime_pm_object_release_mmap_offset() name to
> > i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic.
> >
> > PCIe Specs 5.3.1.4.1
> >
> > Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
> > Cc: Matthew Auld
> > Cc: Rodrigo Vivi
> > Signed-off-by: Anshuman Gupta
> > Reviewed-by: Andi Shyti
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_mman.c | 21 +++
> > drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 +
> > drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
> > .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
> > drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 36 +--
> > drivers/gpu/drm/i915/gt/intel_gt.c| 2 ++
> > drivers/gpu/drm/i915/gt/intel_gt_types.h | 14
> > drivers/gpu/drm/i915/i915_gem.c | 4 +++
> > 8 files changed, 79 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > index b55befda3387..73d9eda1d6b7 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> > @@ -550,6 +550,20 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
> > intel_runtime_pm_put(&i915->runtime_pm, wakeref); }
> >
> > +void i915_gem_object_runtime_pm_release_mmap_offset(struct
> > +drm_i915_gem_object *obj) {
> > + struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> > + struct ttm_device *bdev = bo->bdev;
> > +
> > + drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
> > +
> > + if (obj->userfault_count) {
> > + /* rpm wakeref provide exclusive access */
> > + list_del(&obj->userfault_link);
> > + obj->userfault_count = 0;
> > + }
> > +}
> > +
> > void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object
> > *obj) {
> > struct i915_mmap_offset *mmo, *mn; @@ -573,6 +587,13 @@ void
> > i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
> > spin_lock(&obj->mmo.lock);
> > }
> > spin_unlock(&obj->mmo.lock);
> > +
> > + if (obj->userfault_count) {
> > +
> > mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
> > + list_del(&obj->userfault_link);
> > + mutex_unlock(&to_gt(to_i915(obj->base.dev))-
> >lmem_userfault_lock);
> > + obj->userfault_count = 0;
> > + }
>
> Sorry for the late reply, I was out last week. This looks like it's missing
> holding
> the runtime pm AFAICT. We are holding the runtime pm for object destruction,
> but this is also called when a move is triggered (very common). If so, this
> can
> race against the runtime pm also touching the list concurrently. We are
> chasing
> some crazy looking NULL deref bugs, so wondering if this is somehow related...
Yes it is called from i915_ttm_move_notify(), I missed it thinking of
__i915_gem_object_pages_fini
Would be sufficient to protect against runtime PM.
Having said that, it ok to remove the wakeref from i915_ttm_delete_mem_notify
and having only
in one place in i915_gem_ob
Re: [Intel-gfx] [PATCH v6 0/3] Enable Pipewriteback
Hi Jani, All patches have been reviewed by Arun it would be great if you could have a Look and give an ACK. Regards, Suraj Kandpal > Subject: [PATCH v6 0/3] Enable Pipewriteback > > A patch series was floated in the drm mailing list which aimed to change the > drm_connector and drm_encoder fields to pointer in the > drm_connector_writeback structure, this received a huge pushback from the > community but since i915 expects each connector present in the drm_device > list to be a intel_connector but drm_writeback framework makes us have a > connector which cannot be embedded in an intel_connector structure. > [1] > https://patchwork.kernel.org/project/dri- > devel/patch/20220202081702.22119-1-suraj.kand...@intel.com/ > [2] > https://patchwork.kernel.org/project/dri- > devel/patch/20220202085429.22261-6-suraj.kand...@intel.com/ > Since no one had an issue with encoder field being changed into a pointer it > was decided to break the connector and encoder pointer changes into two > different series.The encoder field changes is currently being worked upon by > Abhinav Kumar and the changes have been merged. > [3]https://patchwork.kernel.org/project/dri-devel/list/?series=633565 > Going forward we use a drm_connector which is not embedded in > intel_connector. > We also create a intel_encoder to avoid changes to many iterators but no > intel_connector. We also changed all iterators that > > ---v2 > solving BAT issues > > ---v3 > -removing unecessary comments from i915_reg.h [Arun] -moving wd_init into > its own if condition [Arun] -fixing comment styling and alignment in > intel_wd.c > [Arun] -removing continue from loop and calling function if condition is met > [Arun] -removing useless arguments from intel_queue_writeback_job and > intel_enabling_capture [Arun] > > --v4 > Adding Reviewed-by to patches which were previously reviewd > > --v5 > Adding Reviewed-by for patch 3 > > --v6 > Solving BAT issue > changes for checkpatch to pass > > Suraj Kandpal (3): > drm/i915: Define WD trancoder for i915 > drm/i915 : Changing intel_connector iterators > drm/i915: Enabling WD Transcoder > > drivers/gpu/drm/i915/Makefile | 1 + > drivers/gpu/drm/i915/display/intel_acpi.c | 8 +- > drivers/gpu/drm/i915/display/intel_crtc.c | 6 + > .../drm/i915/display/intel_crtc_state_dump.c | 1 + > drivers/gpu/drm/i915/display/intel_ddi.c | 6 + > drivers/gpu/drm/i915/display/intel_display.c | 68 +- > drivers/gpu/drm/i915/display/intel_display.h | 18 +- > .../drm/i915/display/intel_display_debugfs.c | 13 +- > .../drm/i915/display/intel_display_types.h| 32 +- > drivers/gpu/drm/i915/display/intel_dpll.c | 6 + > .../drm/i915/display/intel_modeset_setup.c| 119 ++- > .../drm/i915/display/intel_modeset_verify.c | 17 +- > drivers/gpu/drm/i915/display/intel_opregion.c | 3 + > drivers/gpu/drm/i915/display/intel_wd.c | 694 ++ > drivers/gpu/drm/i915/display/intel_wd.h | 48 ++ > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_irq.c | 8 +- > drivers/gpu/drm/i915/i915_pci.c | 7 +- > drivers/gpu/drm/i915/i915_reg.h | 137 > 19 files changed, 1137 insertions(+), 56 deletions(-) create mode 100644 > drivers/gpu/drm/i915/display/intel_wd.c > create mode 100644 drivers/gpu/drm/i915/display/intel_wd.h > > -- > 2.25.1
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Tidy up vfio_device life cycle (rev7)
== Series Details == Series: Tidy up vfio_device life cycle (rev7) URL : https://patchwork.freedesktop.org/series/107838/ State : failure == Summary == Error: patch https://patchwork.freedesktop.org/api/1.0/series/107838/revisions/7/mbox/ not applied Applying: vfio: Add helpers for unifying vfio_device life cycle Applying: vfio/pci: Use the new device life cycle helpers Applying: vfio/mlx5: Use the new device life cycle helpers Using index info to reconstruct a base tree... M drivers/vfio/pci/mlx5/main.c Falling back to patching base and 3-way merge... Auto-merging drivers/vfio/pci/mlx5/main.c CONFLICT (content): Merge conflict in drivers/vfio/pci/mlx5/main.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0003 vfio/mlx5: Use the new device life cycle helpers When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort".
[Intel-gfx] ✓ Fi.CI.IGT: success for Enable Pipewriteback (rev9)
== Series Details ==
Series: Enable Pipewriteback (rev9)
URL : https://patchwork.freedesktop.org/series/107440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12162_full -> Patchwork_107440v9_full
Summary
---
**WARNING**
Minor unknown changes coming with Patchwork_107440v9_full need to be verified
manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107440v9_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (11 -> 11)
--
No changes in participating hosts
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107440v9_full:
### IGT changes ###
Warnings
* igt@kms_writeback@writeback-check-output:
- shard-tglb: [SKIP][1] ([i915#2437]) -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglb3/igt@kms_writeb...@writeback-check-output.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglb1/igt@kms_writeb...@writeback-check-output.html
* igt@kms_writeback@writeback-fb-id:
- shard-tglb: [SKIP][3] ([i915#2437]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglb2/igt@kms_writeb...@writeback-fb-id.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglb8/igt@kms_writeb...@writeback-fb-id.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_prime@basic-crc-vgem@second-to-first:
- {shard-tglu}: [PASS][5] -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglu-6/igt@kms_prime@basic-crc-v...@second-to-first.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglu-6/igt@kms_prime@basic-crc-v...@second-to-first.html
* igt@kms_writeback@writeback-check-output:
- {shard-tglu}: [SKIP][7] ([i915#2437]) -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglu-4/igt@kms_writeb...@writeback-check-output.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglu-4/igt@kms_writeb...@writeback-check-output.html
* igt@kms_writeback@writeback-fb-id:
- {shard-tglu}: [SKIP][9] ([i915#2437]) -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglu-6/igt@kms_writeb...@writeback-fb-id.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglu-3/igt@kms_writeb...@writeback-fb-id.html
Known issues
Here are the changes found in Patchwork_107440v9_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_eio@reset-stress:
- shard-tglb: [PASS][11] -> [FAIL][12] ([i915#5784])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglb7/igt@gem_...@reset-stress.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-tglb5/igt@gem_...@reset-stress.html
* igt@gem_exec_balancer@parallel-keep-in-fence:
- shard-iclb: [PASS][13] -> [SKIP][14] ([i915#4525]) +2 similar
issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-iclb2/igt@gem_exec_balan...@parallel-keep-in-fence.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-iclb5/igt@gem_exec_balan...@parallel-keep-in-fence.html
* igt@gem_exec_fair@basic-none@rcs0:
- shard-glk: NOTRUN -> [FAIL][15] ([i915#2842])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-glk7/igt@gem_exec_fair@basic-n...@rcs0.html
* igt@gem_lmem_swapping@massive-random:
- shard-glk: NOTRUN -> [SKIP][16] ([fdo#109271] / [i915#4613]) +1
similar issue
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-glk7/igt@gem_lmem_swapp...@massive-random.html
- shard-apl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#4613])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-apl1/igt@gem_lmem_swapp...@massive-random.html
* igt@gen9_exec_parse@allowed-single:
- shard-apl: [PASS][18] -> [DMESG-WARN][19] ([i915#5566] /
[i915#716])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-apl7/igt@gen9_exec_pa...@allowed-single.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/shard-apl8/igt@gen9_exec_pa...@allowed-single.html
* igt@i915_selftest@live@hangcheck:
- shard-tglb: [PASS][20] -> [DMESG-WARN][21] ([i915#5591])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/shard-tglb7/igt@i915_selftest@l...@hangcheck.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-ti
[Intel-gfx] [PATCH v4 14/15] vfio: Rename vfio_device_put() and vfio_device_try_get()
With the addition of vfio_put_device() now the names become confusing.
vfio_put_device() is clear from object life cycle p.o.v given kref.
vfio_device_put()/vfio_device_try_get() are helpers for tracking
users on a registered device.
Now rename them:
- vfio_device_put() -> vfio_device_put_registration()
- vfio_device_try_get() -> vfio_device_try_get_registration()
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_main.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 12952858d903..c27449613a1d 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -453,13 +453,13 @@ static void vfio_group_get(struct vfio_group *group)
* Device objects - create, release, get, put, search
*/
/* Device reference always implies a group reference */
-static void vfio_device_put(struct vfio_device *device)
+static void vfio_device_put_registration(struct vfio_device *device)
{
if (refcount_dec_and_test(&device->refcount))
complete(&device->comp);
}
-static bool vfio_device_try_get(struct vfio_device *device)
+static bool vfio_device_try_get_registration(struct vfio_device *device)
{
return refcount_inc_not_zero(&device->refcount);
}
@@ -471,7 +471,8 @@ static struct vfio_device *vfio_group_get_device(struct
vfio_group *group,
mutex_lock(&group->device_lock);
list_for_each_entry(device, &group->device_list, group_next) {
- if (device->dev == dev && vfio_device_try_get(device)) {
+ if (device->dev == dev &&
+ vfio_device_try_get_registration(device)) {
mutex_unlock(&group->device_lock);
return device;
}
@@ -673,7 +674,7 @@ static int __vfio_register_dev(struct vfio_device *device,
if (existing_device) {
dev_WARN(device->dev, "Device already exists on group %d\n",
iommu_group_id(group->iommu_group));
- vfio_device_put(existing_device);
+ vfio_device_put_registration(existing_device);
if (group->type == VFIO_NO_IOMMU ||
group->type == VFIO_EMULATED_IOMMU)
iommu_group_remove_device(device->dev);
@@ -731,7 +732,7 @@ static struct vfio_device *vfio_device_get_from_name(struct
vfio_group *group,
ret = !strcmp(dev_name(it->dev), buf);
}
- if (ret && vfio_device_try_get(it)) {
+ if (ret && vfio_device_try_get_registration(it)) {
device = it;
break;
}
@@ -751,7 +752,7 @@ void vfio_unregister_group_dev(struct vfio_device *device)
bool interrupted = false;
long rc;
- vfio_device_put(device);
+ vfio_device_put_registration(device);
rc = try_wait_for_completion(&device->comp);
while (rc <= 0) {
if (device->ops->request)
@@ -1311,7 +1312,7 @@ static int vfio_group_ioctl_get_device_fd(struct
vfio_group *group,
err_put_fdno:
put_unused_fd(fdno);
err_put_device:
- vfio_device_put(device);
+ vfio_device_put_registration(device);
return ret;
}
@@ -1493,7 +1494,7 @@ static int vfio_device_fops_release(struct inode *inode,
struct file *filep)
vfio_device_unassign_container(device);
- vfio_device_put(device);
+ vfio_device_put_registration(device);
return 0;
}
--
2.21.3
[Intel-gfx] [PATCH v4 15/15] vfio: Add struct device to vfio_device
From: Yi Liu
and replace kref. With it a 'vfio-dev/vfioX' node is created under the
sysfs path of the parent, indicating the device is bound to a vfio
driver, e.g.:
/sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0
It is also a preparatory step toward adding cdev for supporting future
device-oriented uAPI.
Add Documentation/ABI/testing/sysfs-devices-vfio-dev.
Suggested-by: Jason Gunthorpe
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
.../ABI/testing/sysfs-devices-vfio-dev| 8 +++
MAINTAINERS | 1 +
drivers/vfio/vfio_main.c | 64 +++
include/linux/vfio.h | 6 +-
4 files changed, 65 insertions(+), 14 deletions(-)
create mode 100644 Documentation/ABI/testing/sysfs-devices-vfio-dev
diff --git a/Documentation/ABI/testing/sysfs-devices-vfio-dev
b/Documentation/ABI/testing/sysfs-devices-vfio-dev
new file mode 100644
index ..e21424fd9666
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-devices-vfio-dev
@@ -0,0 +1,8 @@
+What: /sys/...//vfio-dev/vfioX/
+Date: September 2022
+Contact:Yi Liu
+Description:
+This directory is created when the device is bound to a
+vfio driver. The layout under this directory matches what
+exists for a standard 'struct device'. 'X' is a unique
+index marking this device in vfio.
diff --git a/MAINTAINERS b/MAINTAINERS
index d30f26e07cd3..02c8f11b1c17 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -21312,6 +21312,7 @@ R: Cornelia Huck
L: k...@vger.kernel.org
S: Maintained
T: git git://github.com/awilliam/linux-vfio.git
+F: Documentation/ABI/testing/sysfs-devices-vfio-dev
F: Documentation/driver-api/vfio.rst
F: drivers/vfio/
F: include/linux/vfio.h
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index c27449613a1d..f9d10dbcf3e6 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -49,6 +49,8 @@ static struct vfio {
struct mutexgroup_lock; /* locks group_list */
struct ida group_ida;
dev_t group_devt;
+ struct class*device_class;
+ struct ida device_ida;
} vfio;
struct vfio_iommu_driver {
@@ -485,12 +487,13 @@ static struct vfio_device *vfio_group_get_device(struct
vfio_group *group,
* VFIO driver API
*/
/* Release helper called by vfio_put_device() */
-void vfio_device_release(struct kref *kref)
+static void vfio_device_release(struct device *dev)
{
struct vfio_device *device =
- container_of(kref, struct vfio_device, kref);
+ container_of(dev, struct vfio_device, device);
vfio_release_device_set(device);
+ ida_free(&vfio.device_ida, device->index);
/*
* kvfree() cannot be done here due to a life cycle mess in
@@ -500,7 +503,6 @@ void vfio_device_release(struct kref *kref)
*/
device->ops->release(device);
}
-EXPORT_SYMBOL_GPL(vfio_device_release);
/*
* Allocate and initialize vfio_device so it can be registered to vfio
@@ -548,6 +550,13 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
{
int ret;
+ ret = ida_alloc_max(&vfio.device_ida, MINORMASK, GFP_KERNEL);
+ if (ret < 0) {
+ dev_dbg(dev, "Error to alloc index\n");
+ return ret;
+ }
+
+ device->index = ret;
init_completion(&device->comp);
device->dev = dev;
device->ops = ops;
@@ -558,11 +567,15 @@ int vfio_init_device(struct vfio_device *device, struct
device *dev,
goto out_uninit;
}
- kref_init(&device->kref);
+ device_initialize(&device->device);
+ device->device.release = vfio_device_release;
+ device->device.class = vfio.device_class;
+ device->device.parent = device->dev;
return 0;
out_uninit:
vfio_release_device_set(device);
+ ida_free(&vfio.device_ida, device->index);
return ret;
}
EXPORT_SYMBOL_GPL(vfio_init_device);
@@ -659,6 +672,7 @@ static int __vfio_register_dev(struct vfio_device *device,
struct vfio_group *group)
{
struct vfio_device *existing_device;
+ int ret;
if (IS_ERR(group))
return PTR_ERR(group);
@@ -675,16 +689,21 @@ static int __vfio_register_dev(struct vfio_device *device,
dev_WARN(device->dev, "Device already exists on group %d\n",
iommu_group_id(group->iommu_group));
vfio_device_put_registration(existing_device);
- if (group->type == VFIO_NO_IOMMU ||
- group->type == VFIO_EMULATED_IOMMU)
- iommu_group_remove_device(device->dev);
-
[Intel-gfx] [PATCH v4 12/15] vfio/amba: Use the new device life cycle helpers
Implement amba's own vfio_device_ops.
Remove vfio_platform_probe/remove_common() given no user now.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/platform/vfio_amba.c | 72 ++-
drivers/vfio/platform/vfio_platform_common.c | 60
drivers/vfio/platform/vfio_platform_private.h | 3 -
3 files changed, 55 insertions(+), 80 deletions(-)
diff --git a/drivers/vfio/platform/vfio_amba.c
b/drivers/vfio/platform/vfio_amba.c
index 1aaa4f721bd2..eaea63e5294c 100644
--- a/drivers/vfio/platform/vfio_amba.c
+++ b/drivers/vfio/platform/vfio_amba.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "vfio_platform_private.h"
@@ -40,20 +41,16 @@ static int get_amba_irq(struct vfio_platform_device *vdev,
int i)
return ret ? ret : -ENXIO;
}
-static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+static int vfio_amba_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_platform_device *vdev;
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+ struct amba_device *adev = to_amba_device(core_vdev->dev);
int ret;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
-
vdev->name = kasprintf(GFP_KERNEL, "vfio-amba-%08x", adev->periphid);
- if (!vdev->name) {
- kfree(vdev);
+ if (!vdev->name)
return -ENOMEM;
- }
vdev->opaque = (void *) adev;
vdev->flags = VFIO_DEVICE_FLAGS_AMBA;
@@ -61,26 +58,67 @@ static int vfio_amba_probe(struct amba_device *adev, const
struct amba_id *id)
vdev->get_irq = get_amba_irq;
vdev->reset_required = false;
- ret = vfio_platform_probe_common(vdev, &adev->dev);
- if (ret) {
+ ret = vfio_platform_init_common(vdev);
+ if (ret)
kfree(vdev->name);
- kfree(vdev);
- return ret;
- }
+ return ret;
+}
+
+static const struct vfio_device_ops vfio_amba_ops;
+static int vfio_amba_probe(struct amba_device *adev, const struct amba_id *id)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_platform_device, vdev, &adev->dev,
+&vfio_amba_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+ ret = vfio_register_group_dev(&vdev->vdev);
+ if (ret)
+ goto out_put_vdev;
+
+ pm_runtime_enable(&adev->dev);
dev_set_drvdata(&adev->dev, vdev);
return 0;
+
+out_put_vdev:
+ vfio_put_device(&vdev->vdev);
+ return ret;
+}
+
+static void vfio_amba_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+
+ vfio_platform_release_common(vdev);
+ kfree(vdev->name);
+ vfio_free_device(core_vdev);
}
static void vfio_amba_remove(struct amba_device *adev)
{
struct vfio_platform_device *vdev = dev_get_drvdata(&adev->dev);
- vfio_platform_remove_common(vdev);
- kfree(vdev->name);
- kfree(vdev);
+ vfio_unregister_group_dev(&vdev->vdev);
+ pm_runtime_disable(vdev->device);
+ vfio_put_device(&vdev->vdev);
}
+static const struct vfio_device_ops vfio_amba_ops = {
+ .name = "vfio-amba",
+ .init = vfio_amba_init_dev,
+ .release= vfio_amba_release_dev,
+ .open_device= vfio_platform_open_device,
+ .close_device = vfio_platform_close_device,
+ .ioctl = vfio_platform_ioctl,
+ .read = vfio_platform_read,
+ .write = vfio_platform_write,
+ .mmap = vfio_platform_mmap,
+};
+
static const struct amba_id pl330_ids[] = {
{ 0, 0 },
};
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform/vfio_platform_common.c
index 4c01bf0adebb..55dc4f43c31e 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -605,16 +605,6 @@ int vfio_platform_mmap(struct vfio_device *core_vdev,
struct vm_area_struct *vma
}
EXPORT_SYMBOL_GPL(vfio_platform_mmap);
-static const struct vfio_device_ops vfio_platform_ops = {
- .name = "vfio-platform",
- .open_device= vfio_platform_open_device,
- .close_device = vfio_platform_close_device,
- .ioctl = vfio_platform_ioctl,
- .read = vfio_platform_read,
- .write = vfio_platform_write,
- .mmap = vfio_platform_mmap,
-};
-
static int vfio_platform_of_probe(struct vfio_platform_device *vdev,
struct device *dev)
{
@@ -674,56 +664,6 @@ void vfio_platform_release_common(struct
vfio_platform_device
[Intel-gfx] [PATCH v4 13/15] vfio/ccw: Use the new device life cycle helpers
ccw is the only exception which cannot use vfio_alloc_device() because
its private device structure is designed to serve both mdev and parent.
Life cycle of the parent is managed by css_driver so vfio_ccw_private
must be allocated/freed in css_driver probe/remove path instead of
conforming to vfio core life cycle for mdev.
Given that use a wait/completion scheme so the mdev remove path waits
after vfio_put_device() until receiving a completion notification from
@release. The completion indicates that all active references on
vfio_device have been released.
After that point although free of vfio_ccw_private is delayed to
css_driver it's at least guaranteed to have no parallel reference on
released vfio device part from other code paths.
memset() in @probe is removed. vfio_device is either already cleared
when probed for the first time or cleared in @release from last probe.
The right fix is to introduce separate structures for mdev and parent,
but this won't happen in short term per prior discussions.
Remove vfio_init/uninit_group_dev() as no user now.
Suggested-by: Jason Gunthorpe
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Farman
---
drivers/s390/cio/vfio_ccw_ops.c | 52 +
drivers/s390/cio/vfio_ccw_private.h | 3 ++
drivers/vfio/vfio_main.c| 23 +++--
include/linux/vfio.h| 3 --
4 files changed, 53 insertions(+), 28 deletions(-)
diff --git a/drivers/s390/cio/vfio_ccw_ops.c b/drivers/s390/cio/vfio_ccw_ops.c
index 4a806a2273b5..9f8486c0d3d3 100644
--- a/drivers/s390/cio/vfio_ccw_ops.c
+++ b/drivers/s390/cio/vfio_ccw_ops.c
@@ -87,6 +87,15 @@ static struct attribute_group *mdev_type_groups[] = {
NULL,
};
+static int vfio_ccw_mdev_init_dev(struct vfio_device *vdev)
+{
+ struct vfio_ccw_private *private =
+ container_of(vdev, struct vfio_ccw_private, vdev);
+
+ init_completion(&private->release_comp);
+ return 0;
+}
+
static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
{
struct vfio_ccw_private *private = dev_get_drvdata(mdev->dev.parent);
@@ -98,9 +107,9 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
if (atomic_dec_if_positive(&private->avail) < 0)
return -EPERM;
- memset(&private->vdev, 0, sizeof(private->vdev));
- vfio_init_group_dev(&private->vdev, &mdev->dev,
- &vfio_ccw_dev_ops);
+ ret = vfio_init_device(&private->vdev, &mdev->dev, &vfio_ccw_dev_ops);
+ if (ret)
+ return ret;
VFIO_CCW_MSG_EVENT(2, "sch %x.%x.%04x: create\n",
private->sch->schid.cssid,
@@ -109,16 +118,33 @@ static int vfio_ccw_mdev_probe(struct mdev_device *mdev)
ret = vfio_register_emulated_iommu_dev(&private->vdev);
if (ret)
- goto err_atomic;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, private);
return 0;
-err_atomic:
- vfio_uninit_group_dev(&private->vdev);
+err_put_vdev:
+ vfio_put_device(&private->vdev);
atomic_inc(&private->avail);
return ret;
}
+static void vfio_ccw_mdev_release_dev(struct vfio_device *vdev)
+{
+ struct vfio_ccw_private *private =
+ container_of(vdev, struct vfio_ccw_private, vdev);
+
+ /*
+* We cannot free vfio_ccw_private here because it includes
+* parent info which must be free'ed by css driver.
+*
+* Use a workaround by memset'ing the core device part and
+* then notifying the remove path that all active references
+* to this device have been released.
+*/
+ memset(vdev, 0, sizeof(*vdev));
+ complete(&private->release_comp);
+}
+
static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
{
struct vfio_ccw_private *private = dev_get_drvdata(mdev->dev.parent);
@@ -130,7 +156,17 @@ static void vfio_ccw_mdev_remove(struct mdev_device *mdev)
vfio_unregister_group_dev(&private->vdev);
- vfio_uninit_group_dev(&private->vdev);
+ vfio_put_device(&private->vdev);
+ /*
+* Wait for all active references on mdev are released so it
+* is safe to defer kfree() to a later point.
+*
+* TODO: the clean fix is to split parent/mdev info from ccw
+* private structure so each can be managed in its own life
+* cycle.
+*/
+ wait_for_completion(&private->release_comp);
+
atomic_inc(&private->avail);
}
@@ -592,6 +628,8 @@ static void vfio_ccw_mdev_request(struct vfio_device *vdev,
unsigned int count)
}
static const struct vfio_device_ops vfio_ccw_dev_ops = {
+ .init = vfio_ccw_mdev_init_dev,
+ .release = vfio_ccw_mdev_release_dev,
.open_device = vfio_ccw_mdev_open_device,
.close_device = vfio_ccw_mdev_close_device,
.read = vfio_ccw_mdev_read,
diff --git a/drivers/s390/cio/vfio_ccw_private.h
[Intel-gfx] [PATCH v4 11/15] vfio/platform: Use the new device life cycle helpers
Move vfio_device_ops from platform core to platform drivers so device
specific init/cleanup can be added.
Introduce two new helpers vfio_platform_init/release_common() for the
use in driver @init/@release.
vfio_platform_probe/remove_common() will be deprecated.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
Tested-by: Eric Auger
---
drivers/vfio/platform/vfio_platform.c | 66 +++
drivers/vfio/platform/vfio_platform_common.c | 53 ---
drivers/vfio/platform/vfio_platform_private.h | 15 +
3 files changed, 111 insertions(+), 23 deletions(-)
diff --git a/drivers/vfio/platform/vfio_platform.c
b/drivers/vfio/platform/vfio_platform.c
index 04f40c5acfd6..82cedcebfd90 100644
--- a/drivers/vfio/platform/vfio_platform.c
+++ b/drivers/vfio/platform/vfio_platform.c
@@ -7,6 +7,7 @@
#include
#include
#include
+#include
#include
#include "vfio_platform_private.h"
@@ -36,14 +37,11 @@ static int get_platform_irq(struct vfio_platform_device
*vdev, int i)
return platform_get_irq_optional(pdev, i);
}
-static int vfio_platform_probe(struct platform_device *pdev)
+static int vfio_platform_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_platform_device *vdev;
- int ret;
-
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+ struct platform_device *pdev = to_platform_device(core_vdev->dev);
vdev->opaque = (void *) pdev;
vdev->name = pdev->name;
@@ -52,24 +50,64 @@ static int vfio_platform_probe(struct platform_device *pdev)
vdev->get_irq = get_platform_irq;
vdev->reset_required = reset_required;
- ret = vfio_platform_probe_common(vdev, &pdev->dev);
- if (ret) {
- kfree(vdev);
- return ret;
- }
+ return vfio_platform_init_common(vdev);
+}
+
+static const struct vfio_device_ops vfio_platform_ops;
+static int vfio_platform_probe(struct platform_device *pdev)
+{
+ struct vfio_platform_device *vdev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_platform_device, vdev, &pdev->dev,
+&vfio_platform_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
+
+ ret = vfio_register_group_dev(&vdev->vdev);
+ if (ret)
+ goto out_put_vdev;
+
+ pm_runtime_enable(&pdev->dev);
dev_set_drvdata(&pdev->dev, vdev);
return 0;
+
+out_put_vdev:
+ vfio_put_device(&vdev->vdev);
+ return ret;
+}
+
+static void vfio_platform_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_platform_device *vdev =
+ container_of(core_vdev, struct vfio_platform_device, vdev);
+
+ vfio_platform_release_common(vdev);
+ vfio_free_device(core_vdev);
}
static int vfio_platform_remove(struct platform_device *pdev)
{
struct vfio_platform_device *vdev = dev_get_drvdata(&pdev->dev);
- vfio_platform_remove_common(vdev);
- kfree(vdev);
+ vfio_unregister_group_dev(&vdev->vdev);
+ pm_runtime_disable(vdev->device);
+ vfio_put_device(&vdev->vdev);
return 0;
}
+static const struct vfio_device_ops vfio_platform_ops = {
+ .name = "vfio-platform",
+ .init = vfio_platform_init_dev,
+ .release= vfio_platform_release_dev,
+ .open_device= vfio_platform_open_device,
+ .close_device = vfio_platform_close_device,
+ .ioctl = vfio_platform_ioctl,
+ .read = vfio_platform_read,
+ .write = vfio_platform_write,
+ .mmap = vfio_platform_mmap,
+};
+
static struct platform_driver vfio_platform_driver = {
.probe = vfio_platform_probe,
.remove = vfio_platform_remove,
diff --git a/drivers/vfio/platform/vfio_platform_common.c
b/drivers/vfio/platform/vfio_platform_common.c
index 256f55b84e70..4c01bf0adebb 100644
--- a/drivers/vfio/platform/vfio_platform_common.c
+++ b/drivers/vfio/platform/vfio_platform_common.c
@@ -218,7 +218,7 @@ static int vfio_platform_call_reset(struct
vfio_platform_device *vdev,
return -EINVAL;
}
-static void vfio_platform_close_device(struct vfio_device *core_vdev)
+void vfio_platform_close_device(struct vfio_device *core_vdev)
{
struct vfio_platform_device *vdev =
container_of(core_vdev, struct vfio_platform_device, vdev);
@@ -236,8 +236,9 @@ static void vfio_platform_close_device(struct vfio_device
*core_vdev)
vfio_platform_regions_cleanup(vdev);
vfio_platform_irq_cleanup(vdev);
}
+EXPORT_SYMBOL_GPL(vfio_platform_close_device);
-static int vfio_platform_open_device(struct vfio_device *core_vdev)
+int vfio_platform_open_device(struct vfio_device *core_vdev)
{
struct vfi
[Intel-gfx] [PATCH v4 10/15] vfio/fsl-mc: Use the new device life cycle helpers
From: Yi Liu
Also add a comment to mark that vfio core releases device_set if @init
fails.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/fsl-mc/vfio_fsl_mc.c | 85 ++-
1 file changed, 49 insertions(+), 36 deletions(-)
diff --git a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
index 42b344bd7cd5..b16874e913e4 100644
--- a/drivers/vfio/fsl-mc/vfio_fsl_mc.c
+++ b/drivers/vfio/fsl-mc/vfio_fsl_mc.c
@@ -418,16 +418,7 @@ static int vfio_fsl_mc_mmap(struct vfio_device *core_vdev,
return vfio_fsl_mc_mmap_mmio(vdev->regions[index], vma);
}
-static const struct vfio_device_ops vfio_fsl_mc_ops = {
- .name = "vfio-fsl-mc",
- .open_device= vfio_fsl_mc_open_device,
- .close_device = vfio_fsl_mc_close_device,
- .ioctl = vfio_fsl_mc_ioctl,
- .read = vfio_fsl_mc_read,
- .write = vfio_fsl_mc_write,
- .mmap = vfio_fsl_mc_mmap,
-};
-
+static const struct vfio_device_ops vfio_fsl_mc_ops;
static int vfio_fsl_mc_bus_notifier(struct notifier_block *nb,
unsigned long action, void *data)
{
@@ -518,35 +509,43 @@ static void vfio_fsl_uninit_device(struct
vfio_fsl_mc_device *vdev)
bus_unregister_notifier(&fsl_mc_bus_type, &vdev->nb);
}
-static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
+static int vfio_fsl_mc_init_dev(struct vfio_device *core_vdev)
{
- struct vfio_fsl_mc_device *vdev;
- struct device *dev = &mc_dev->dev;
+ struct vfio_fsl_mc_device *vdev =
+ container_of(core_vdev, struct vfio_fsl_mc_device, vdev);
+ struct fsl_mc_device *mc_dev = to_fsl_mc_device(core_vdev->dev);
int ret;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
-
- vfio_init_group_dev(&vdev->vdev, dev, &vfio_fsl_mc_ops);
vdev->mc_dev = mc_dev;
mutex_init(&vdev->igate);
if (is_fsl_mc_bus_dprc(mc_dev))
- ret = vfio_assign_device_set(&vdev->vdev, &mc_dev->dev);
+ ret = vfio_assign_device_set(core_vdev, &mc_dev->dev);
else
- ret = vfio_assign_device_set(&vdev->vdev, mc_dev->dev.parent);
- if (ret)
- goto out_uninit;
+ ret = vfio_assign_device_set(core_vdev, mc_dev->dev.parent);
- ret = vfio_fsl_mc_init_device(vdev);
if (ret)
- goto out_uninit;
+ return ret;
+
+ /* device_set is released by vfio core if @init fails */
+ return vfio_fsl_mc_init_device(vdev);
+}
+
+static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
+{
+ struct vfio_fsl_mc_device *vdev;
+ struct device *dev = &mc_dev->dev;
+ int ret;
+
+ vdev = vfio_alloc_device(vfio_fsl_mc_device, vdev, dev,
+&vfio_fsl_mc_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
ret = vfio_register_group_dev(&vdev->vdev);
if (ret) {
dev_err(dev, "VFIO_FSL_MC: Failed to add to vfio group\n");
- goto out_device;
+ goto out_put_vdev;
}
ret = vfio_fsl_mc_scan_container(mc_dev);
@@ -557,30 +556,44 @@ static int vfio_fsl_mc_probe(struct fsl_mc_device *mc_dev)
out_group_dev:
vfio_unregister_group_dev(&vdev->vdev);
-out_device:
- vfio_fsl_uninit_device(vdev);
-out_uninit:
- vfio_uninit_group_dev(&vdev->vdev);
- kfree(vdev);
+out_put_vdev:
+ vfio_put_device(&vdev->vdev);
return ret;
}
+static void vfio_fsl_mc_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_fsl_mc_device *vdev =
+ container_of(core_vdev, struct vfio_fsl_mc_device, vdev);
+
+ vfio_fsl_uninit_device(vdev);
+ mutex_destroy(&vdev->igate);
+ vfio_free_device(core_vdev);
+}
+
static int vfio_fsl_mc_remove(struct fsl_mc_device *mc_dev)
{
struct device *dev = &mc_dev->dev;
struct vfio_fsl_mc_device *vdev = dev_get_drvdata(dev);
vfio_unregister_group_dev(&vdev->vdev);
- mutex_destroy(&vdev->igate);
-
dprc_remove_devices(mc_dev, NULL, 0);
- vfio_fsl_uninit_device(vdev);
-
- vfio_uninit_group_dev(&vdev->vdev);
- kfree(vdev);
+ vfio_put_device(&vdev->vdev);
return 0;
}
+static const struct vfio_device_ops vfio_fsl_mc_ops = {
+ .name = "vfio-fsl-mc",
+ .init = vfio_fsl_mc_init_dev,
+ .release= vfio_fsl_mc_release_dev,
+ .open_device= vfio_fsl_mc_open_device,
+ .close_device = vfio_fsl_mc_close_device,
+ .ioctl = vfio_fsl_mc_ioctl,
+ .read = vfio_fsl_mc_read,
+ .write = vfio_fsl_mc_write,
+ .mmap = vfio_fsl_mc_mmap,
+};
+
static struct fsl_mc_driver vfio_fsl_mc_driver = {
.probe
[Intel-gfx] [PATCH v4 09/15] vfio/ap: Use the new device life cycle helpers
From: Yi Liu
and manage available_instances inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
---
drivers/s390/crypto/vfio_ap_ops.c | 50 ++-
1 file changed, 29 insertions(+), 21 deletions(-)
diff --git a/drivers/s390/crypto/vfio_ap_ops.c
b/drivers/s390/crypto/vfio_ap_ops.c
index 6c8c41fac4e1..161597357a64 100644
--- a/drivers/s390/crypto/vfio_ap_ops.c
+++ b/drivers/s390/crypto/vfio_ap_ops.c
@@ -684,42 +684,44 @@ static bool vfio_ap_mdev_filter_matrix(unsigned long
*apm, unsigned long *aqm,
AP_DOMAINS);
}
-static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+static int vfio_ap_mdev_init_dev(struct vfio_device *vdev)
{
- struct ap_matrix_mdev *matrix_mdev;
- int ret;
+ struct ap_matrix_mdev *matrix_mdev =
+ container_of(vdev, struct ap_matrix_mdev, vdev);
if ((atomic_dec_if_positive(&matrix_dev->available_instances) < 0))
return -EPERM;
- matrix_mdev = kzalloc(sizeof(*matrix_mdev), GFP_KERNEL);
- if (!matrix_mdev) {
- ret = -ENOMEM;
- goto err_dec_available;
- }
- vfio_init_group_dev(&matrix_mdev->vdev, &mdev->dev,
- &vfio_ap_matrix_dev_ops);
-
- matrix_mdev->mdev = mdev;
+ matrix_mdev->mdev = to_mdev_device(vdev->dev);
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->matrix);
matrix_mdev->pqap_hook = handle_pqap;
vfio_ap_matrix_init(&matrix_dev->info, &matrix_mdev->shadow_apcb);
hash_init(matrix_mdev->qtable.queues);
+ return 0;
+}
+
+static int vfio_ap_mdev_probe(struct mdev_device *mdev)
+{
+ struct ap_matrix_mdev *matrix_mdev;
+ int ret;
+
+ matrix_mdev = vfio_alloc_device(ap_matrix_mdev, vdev, &mdev->dev,
+ &vfio_ap_matrix_dev_ops);
+ if (IS_ERR(matrix_mdev))
+ return PTR_ERR(matrix_mdev);
+
ret = vfio_register_emulated_iommu_dev(&matrix_mdev->vdev);
if (ret)
- goto err_list;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, matrix_mdev);
mutex_lock(&matrix_dev->mdevs_lock);
list_add(&matrix_mdev->node, &matrix_dev->mdev_list);
mutex_unlock(&matrix_dev->mdevs_lock);
return 0;
-err_list:
- vfio_uninit_group_dev(&matrix_mdev->vdev);
- kfree(matrix_mdev);
-err_dec_available:
- atomic_inc(&matrix_dev->available_instances);
+err_put_vdev:
+ vfio_put_device(&matrix_mdev->vdev);
return ret;
}
@@ -766,6 +768,12 @@ static void vfio_ap_mdev_unlink_fr_queues(struct
ap_matrix_mdev *matrix_mdev)
}
}
+static void vfio_ap_mdev_release_dev(struct vfio_device *vdev)
+{
+ atomic_inc(&matrix_dev->available_instances);
+ vfio_free_device(vdev);
+}
+
static void vfio_ap_mdev_remove(struct mdev_device *mdev)
{
struct ap_matrix_mdev *matrix_mdev = dev_get_drvdata(&mdev->dev);
@@ -779,9 +787,7 @@ static void vfio_ap_mdev_remove(struct mdev_device *mdev)
list_del(&matrix_mdev->node);
mutex_unlock(&matrix_dev->mdevs_lock);
mutex_unlock(&matrix_dev->guests_lock);
- vfio_uninit_group_dev(&matrix_mdev->vdev);
- kfree(matrix_mdev);
- atomic_inc(&matrix_dev->available_instances);
+ vfio_put_device(&matrix_mdev->vdev);
}
static ssize_t name_show(struct mdev_type *mtype,
@@ -1794,6 +1800,8 @@ static const struct attribute_group vfio_queue_attr_group
= {
};
static const struct vfio_device_ops vfio_ap_matrix_dev_ops = {
+ .init = vfio_ap_mdev_init_dev,
+ .release = vfio_ap_mdev_release_dev,
.open_device = vfio_ap_mdev_open_device,
.close_device = vfio_ap_mdev_close_device,
.ioctl = vfio_ap_mdev_ioctl,
--
2.21.3
[Intel-gfx] [PATCH v4 07/15] vfio/mbochs: Use the new device life cycle helpers
From: Yi Liu
and manage avail_mbytes inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mbochs.c | 73 --
1 file changed, 46 insertions(+), 27 deletions(-)
diff --git a/samples/vfio-mdev/mbochs.c b/samples/vfio-mdev/mbochs.c
index 344c2901a82b..6901947e27d2 100644
--- a/samples/vfio-mdev/mbochs.c
+++ b/samples/vfio-mdev/mbochs.c
@@ -505,13 +505,14 @@ static int mbochs_reset(struct mdev_state *mdev_state)
return 0;
}
-static int mbochs_probe(struct mdev_device *mdev)
+static int mbochs_init_dev(struct vfio_device *vdev)
{
- int avail_mbytes = atomic_read(&mbochs_avail_mbytes);
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
const struct mbochs_type *type =
&mbochs_types[mdev_get_type_group_id(mdev)];
- struct device *dev = mdev_dev(mdev);
- struct mdev_state *mdev_state;
+ int avail_mbytes = atomic_read(&mbochs_avail_mbytes);
int ret = -ENOMEM;
do {
@@ -520,14 +521,9 @@ static int mbochs_probe(struct mdev_device *mdev)
} while (!atomic_try_cmpxchg(&mbochs_avail_mbytes, &avail_mbytes,
avail_mbytes - type->mbytes));
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL)
- goto err_avail;
- vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mbochs_dev_ops);
-
mdev_state->vconfig = kzalloc(MBOCHS_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL)
- goto err_mem;
+ if (!mdev_state->vconfig)
+ goto err_avail;
mdev_state->memsize = type->mbytes * 1024 * 1024;
mdev_state->pagecount = mdev_state->memsize >> PAGE_SHIFT;
@@ -535,10 +531,7 @@ static int mbochs_probe(struct mdev_device *mdev)
sizeof(struct page *),
GFP_KERNEL);
if (!mdev_state->pages)
- goto err_mem;
-
- dev_info(dev, "%s: %s, %d MB, %ld pages\n", __func__,
-type->name, type->mbytes, mdev_state->pagecount);
+ goto err_vconfig;
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
@@ -553,19 +546,47 @@ static int mbochs_probe(struct mdev_device *mdev)
mbochs_create_config_space(mdev_state);
mbochs_reset(mdev_state);
+ dev_info(vdev->dev, "%s: %s, %d MB, %ld pages\n", __func__,
+type->name, type->mbytes, mdev_state->pagecount);
+ return 0;
+
+err_vconfig:
+ kfree(mdev_state->vconfig);
+err_avail:
+ atomic_add(type->mbytes, &mbochs_avail_mbytes);
+ return ret;
+}
+
+static int mbochs_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret = -ENOMEM;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, &mdev->dev,
+ &mbochs_dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
+
ret = vfio_register_emulated_iommu_dev(&mdev_state->vdev);
if (ret)
- goto err_mem;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
-err_mem:
- vfio_uninit_group_dev(&mdev_state->vdev);
+
+err_put_vdev:
+ vfio_put_device(&mdev_state->vdev);
+ return ret;
+}
+
+static void mbochs_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
+ atomic_add(mdev_state->type->mbytes, &mbochs_avail_mbytes);
kfree(mdev_state->pages);
kfree(mdev_state->vconfig);
- kfree(mdev_state);
-err_avail:
- atomic_add(type->mbytes, &mbochs_avail_mbytes);
- return ret;
+ vfio_free_device(vdev);
}
static void mbochs_remove(struct mdev_device *mdev)
@@ -573,11 +594,7 @@ static void mbochs_remove(struct mdev_device *mdev)
struct mdev_state *mdev_state = dev_get_drvdata(&mdev->dev);
vfio_unregister_group_dev(&mdev_state->vdev);
- vfio_uninit_group_dev(&mdev_state->vdev);
- atomic_add(mdev_state->type->mbytes, &mbochs_avail_mbytes);
- kfree(mdev_state->pages);
- kfree(mdev_state->vconfig);
- kfree(mdev_state);
+ vfio_put_device(&mdev_state->vdev);
}
static ssize_t mbochs_read(struct vfio_device *vdev, char __user *buf,
@@ -1397,6 +1414,8 @@ static struct attribute_group *mdev_type_groups[] = {
static const struct vfio_device_ops mbochs_dev_ops = {
.close_device = mbochs_close_device,
+ .init = mbochs_init_dev,
+ .release = mbochs_release_dev,
.read = mbochs_read,
.write = mbochs_write,
.ioctl = mbochs_ioctl,
--
2.21.3
[Intel-gfx] [PATCH v4 08/15] drm/i915/gvt: Use the new device life cycle helpers
Move vfio_device to the start of intel_vgpu as required by the new
helpers.
Change intel_gvt_create_vgpu() to use intel_vgpu as the first param
as other vgpu helpers do.
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Zhenyu Wang
---
drivers/gpu/drm/i915/gvt/gvt.h | 5 ++-
drivers/gpu/drm/i915/gvt/kvmgt.c | 52 ++--
drivers/gpu/drm/i915/gvt/vgpu.c | 33
3 files changed, 50 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/gvt.h b/drivers/gpu/drm/i915/gvt/gvt.h
index 705689e64011..89fab7896fc6 100644
--- a/drivers/gpu/drm/i915/gvt/gvt.h
+++ b/drivers/gpu/drm/i915/gvt/gvt.h
@@ -172,6 +172,7 @@ struct intel_vgpu_submission {
#define KVMGT_DEBUGFS_FILENAME "kvmgt_nr_cache_entries"
struct intel_vgpu {
+ struct vfio_device vfio_device;
struct intel_gvt *gvt;
struct mutex vgpu_lock;
int id;
@@ -211,7 +212,6 @@ struct intel_vgpu {
u32 scan_nonprivbb;
- struct vfio_device vfio_device;
struct vfio_region *region;
int num_regions;
struct eventfd_ctx *intx_trigger;
@@ -494,8 +494,7 @@ void intel_gvt_clean_vgpu_types(struct intel_gvt *gvt);
struct intel_vgpu *intel_gvt_create_idle_vgpu(struct intel_gvt *gvt);
void intel_gvt_destroy_idle_vgpu(struct intel_vgpu *vgpu);
-struct intel_vgpu *intel_gvt_create_vgpu(struct intel_gvt *gvt,
-struct intel_vgpu_type *type);
+int intel_gvt_create_vgpu(struct intel_vgpu *vgpu, struct intel_vgpu_type
*type);
void intel_gvt_destroy_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_release_vgpu(struct intel_vgpu *vgpu);
void intel_gvt_reset_vgpu_locked(struct intel_vgpu *vgpu, bool dmlr,
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index e3cd58946477..41bba40feef8 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -1546,7 +1546,33 @@ static const struct attribute_group *intel_vgpu_groups[]
= {
NULL,
};
+static int intel_vgpu_init_dev(struct vfio_device *vfio_dev)
+{
+ struct mdev_device *mdev = to_mdev_device(vfio_dev->dev);
+ struct device *pdev = mdev_parent_dev(mdev);
+ struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
+ struct intel_vgpu_type *type;
+ struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
+
+ type = &gvt->types[mdev_get_type_group_id(mdev)];
+ if (!type)
+ return -EINVAL;
+
+ vgpu->gvt = gvt;
+ return intel_gvt_create_vgpu(vgpu, type);
+}
+
+static void intel_vgpu_release_dev(struct vfio_device *vfio_dev)
+{
+ struct intel_vgpu *vgpu = vfio_dev_to_vgpu(vfio_dev);
+
+ intel_gvt_destroy_vgpu(vgpu);
+ vfio_free_device(vfio_dev);
+}
+
static const struct vfio_device_ops intel_vgpu_dev_ops = {
+ .init = intel_vgpu_init_dev,
+ .release= intel_vgpu_release_dev,
.open_device= intel_vgpu_open_device,
.close_device = intel_vgpu_close_device,
.read = intel_vgpu_read,
@@ -1558,35 +1584,28 @@ static const struct vfio_device_ops intel_vgpu_dev_ops
= {
static int intel_vgpu_probe(struct mdev_device *mdev)
{
- struct device *pdev = mdev_parent_dev(mdev);
- struct intel_gvt *gvt = kdev_to_i915(pdev)->gvt;
- struct intel_vgpu_type *type;
struct intel_vgpu *vgpu;
int ret;
- type = &gvt->types[mdev_get_type_group_id(mdev)];
- if (!type)
- return -EINVAL;
-
- vgpu = intel_gvt_create_vgpu(gvt, type);
+ vgpu = vfio_alloc_device(intel_vgpu, vfio_device, &mdev->dev,
+&intel_vgpu_dev_ops);
if (IS_ERR(vgpu)) {
gvt_err("failed to create intel vgpu: %ld\n", PTR_ERR(vgpu));
return PTR_ERR(vgpu);
}
- vfio_init_group_dev(&vgpu->vfio_device, &mdev->dev,
- &intel_vgpu_dev_ops);
-
dev_set_drvdata(&mdev->dev, vgpu);
ret = vfio_register_emulated_iommu_dev(&vgpu->vfio_device);
- if (ret) {
- intel_gvt_destroy_vgpu(vgpu);
- return ret;
- }
+ if (ret)
+ goto out_put_vdev;
gvt_dbg_core("intel_vgpu_create succeeded for mdev: %s\n",
dev_name(mdev_dev(mdev)));
return 0;
+
+out_put_vdev:
+ vfio_put_device(&vgpu->vfio_device);
+ return ret;
}
static void intel_vgpu_remove(struct mdev_device *mdev)
@@ -1595,7 +1614,8 @@ static void intel_vgpu_remove(struct mdev_device *mdev)
if (WARN_ON_ONCE(vgpu->attached))
return;
- intel_gvt_destroy_vgpu(vgpu);
+
+ vfio_put_device(&vgpu->vfio_device);
}
static struct mdev_driver intel_vgpu_mdev_driver = {
diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 46da19b3225d..5c533fbc2c8d 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.
[Intel-gfx] [PATCH v4 06/15] vfio/mtty: Use the new device life cycle helpers
From: Yi Liu
and manage available ports inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mtty.c | 67 +++-
1 file changed, 39 insertions(+), 28 deletions(-)
diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
index f42a59ed2e3f..d151928e4f21 100644
--- a/samples/vfio-mdev/mtty.c
+++ b/samples/vfio-mdev/mtty.c
@@ -703,9 +703,11 @@ static ssize_t mdev_access(struct mdev_state *mdev_state,
u8 *buf, size_t count,
return ret;
}
-static int mtty_probe(struct mdev_device *mdev)
+static int mtty_init_dev(struct vfio_device *vdev)
{
- struct mdev_state *mdev_state;
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
int nr_ports = mdev_get_type_group_id(mdev) + 1;
int avail_ports = atomic_read(&mdev_avail_ports);
int ret;
@@ -716,58 +718,65 @@ static int mtty_probe(struct mdev_device *mdev)
} while (!atomic_try_cmpxchg(&mdev_avail_ports,
&avail_ports, avail_ports - nr_ports));
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL) {
- ret = -ENOMEM;
- goto err_nr_ports;
- }
-
- vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mtty_dev_ops);
-
mdev_state->nr_ports = nr_ports;
mdev_state->irq_index = -1;
mdev_state->s[0].max_fifo_size = MAX_FIFO_SIZE;
mdev_state->s[1].max_fifo_size = MAX_FIFO_SIZE;
mutex_init(&mdev_state->rxtx_lock);
- mdev_state->vconfig = kzalloc(MTTY_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL) {
+ mdev_state->vconfig = kzalloc(MTTY_CONFIG_SPACE_SIZE, GFP_KERNEL);
+ if (!mdev_state->vconfig) {
ret = -ENOMEM;
- goto err_state;
+ goto err_nr_ports;
}
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
-
mtty_create_config_space(mdev_state);
+ return 0;
+
+err_nr_ports:
+ atomic_add(nr_ports, &mdev_avail_ports);
+ return ret;
+}
+
+static int mtty_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, &mdev->dev,
+ &mtty_dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
ret = vfio_register_emulated_iommu_dev(&mdev_state->vdev);
if (ret)
- goto err_vconfig;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
-err_vconfig:
- kfree(mdev_state->vconfig);
-err_state:
- vfio_uninit_group_dev(&mdev_state->vdev);
- kfree(mdev_state);
-err_nr_ports:
- atomic_add(nr_ports, &mdev_avail_ports);
+err_put_vdev:
+ vfio_put_device(&mdev_state->vdev);
return ret;
}
+static void mtty_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
+ atomic_add(mdev_state->nr_ports, &mdev_avail_ports);
+ kfree(mdev_state->vconfig);
+ vfio_free_device(vdev);
+}
+
static void mtty_remove(struct mdev_device *mdev)
{
struct mdev_state *mdev_state = dev_get_drvdata(&mdev->dev);
- int nr_ports = mdev_state->nr_ports;
vfio_unregister_group_dev(&mdev_state->vdev);
-
- kfree(mdev_state->vconfig);
- vfio_uninit_group_dev(&mdev_state->vdev);
- kfree(mdev_state);
- atomic_add(nr_ports, &mdev_avail_ports);
+ vfio_put_device(&mdev_state->vdev);
}
static int mtty_reset(struct mdev_state *mdev_state)
@@ -1287,6 +1296,8 @@ static struct attribute_group *mdev_type_groups[] = {
static const struct vfio_device_ops mtty_dev_ops = {
.name = "vfio-mtty",
+ .init = mtty_init_dev,
+ .release = mtty_release_dev,
.read = mtty_read,
.write = mtty_write,
.ioctl = mtty_ioctl,
--
2.21.3
[Intel-gfx] [PATCH v4 05/15] vfio/mdpy: Use the new device life cycle helpers
From: Yi Liu
and manage mdpy_count inside @init/@release.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
samples/vfio-mdev/mdpy.c | 81 +++-
1 file changed, 47 insertions(+), 34 deletions(-)
diff --git a/samples/vfio-mdev/mdpy.c b/samples/vfio-mdev/mdpy.c
index e8c46eb2e246..bb2af1ec0f7c 100644
--- a/samples/vfio-mdev/mdpy.c
+++ b/samples/vfio-mdev/mdpy.c
@@ -216,61 +216,77 @@ static int mdpy_reset(struct mdev_state *mdev_state)
return 0;
}
-static int mdpy_probe(struct mdev_device *mdev)
+static int mdpy_init_dev(struct vfio_device *vdev)
{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+ struct mdev_device *mdev = to_mdev_device(vdev->dev);
const struct mdpy_type *type =
&mdpy_types[mdev_get_type_group_id(mdev)];
- struct device *dev = mdev_dev(mdev);
- struct mdev_state *mdev_state;
u32 fbsize;
- int ret;
+ int ret = -ENOMEM;
if (mdpy_count >= max_devices)
- return -ENOMEM;
-
- mdev_state = kzalloc(sizeof(struct mdev_state), GFP_KERNEL);
- if (mdev_state == NULL)
- return -ENOMEM;
- vfio_init_group_dev(&mdev_state->vdev, &mdev->dev, &mdpy_dev_ops);
+ return ret;
mdev_state->vconfig = kzalloc(MDPY_CONFIG_SPACE_SIZE, GFP_KERNEL);
- if (mdev_state->vconfig == NULL) {
- ret = -ENOMEM;
- goto err_state;
- }
+ if (!mdev_state->vconfig)
+ return ret;
fbsize = roundup_pow_of_two(type->width * type->height * type->bytepp);
mdev_state->memblk = vmalloc_user(fbsize);
- if (!mdev_state->memblk) {
- ret = -ENOMEM;
- goto err_vconfig;
- }
- dev_info(dev, "%s: %s (%dx%d)\n", __func__, type->name, type->width,
-type->height);
+ if (!mdev_state->memblk)
+ goto out_vconfig;
mutex_init(&mdev_state->ops_lock);
mdev_state->mdev = mdev;
- mdev_state->type= type;
+ mdev_state->type = type;
mdev_state->memsize = fbsize;
mdpy_create_config_space(mdev_state);
mdpy_reset(mdev_state);
+ dev_info(vdev->dev, "%s: %s (%dx%d)\n", __func__, type->name,
type->width,
+type->height);
+
mdpy_count++;
+ return 0;
+
+out_vconfig:
+ kfree(mdev_state->vconfig);
+ return ret;
+}
+
+static int mdpy_probe(struct mdev_device *mdev)
+{
+ struct mdev_state *mdev_state;
+ int ret;
+
+ mdev_state = vfio_alloc_device(mdev_state, vdev, &mdev->dev,
+ &mdpy_dev_ops);
+ if (IS_ERR(mdev_state))
+ return PTR_ERR(mdev_state);
ret = vfio_register_emulated_iommu_dev(&mdev_state->vdev);
if (ret)
- goto err_mem;
+ goto err_put_vdev;
dev_set_drvdata(&mdev->dev, mdev_state);
return 0;
-err_mem:
+
+err_put_vdev:
+ vfio_put_device(&mdev_state->vdev);
+ return ret;
+}
+
+static void mdpy_release_dev(struct vfio_device *vdev)
+{
+ struct mdev_state *mdev_state =
+ container_of(vdev, struct mdev_state, vdev);
+
+ mdpy_count--;
vfree(mdev_state->memblk);
-err_vconfig:
kfree(mdev_state->vconfig);
-err_state:
- vfio_uninit_group_dev(&mdev_state->vdev);
- kfree(mdev_state);
- return ret;
+ vfio_free_device(vdev);
}
static void mdpy_remove(struct mdev_device *mdev)
@@ -280,12 +296,7 @@ static void mdpy_remove(struct mdev_device *mdev)
dev_info(&mdev->dev, "%s\n", __func__);
vfio_unregister_group_dev(&mdev_state->vdev);
- vfree(mdev_state->memblk);
- kfree(mdev_state->vconfig);
- vfio_uninit_group_dev(&mdev_state->vdev);
- kfree(mdev_state);
-
- mdpy_count--;
+ vfio_put_device(&mdev_state->vdev);
}
static ssize_t mdpy_read(struct vfio_device *vdev, char __user *buf,
@@ -708,6 +719,8 @@ static struct attribute_group *mdev_type_groups[] = {
};
static const struct vfio_device_ops mdpy_dev_ops = {
+ .init = mdpy_init_dev,
+ .release = mdpy_release_dev,
.read = mdpy_read,
.write = mdpy_write,
.ioctl = mdpy_ioctl,
--
2.21.3
[Intel-gfx] [PATCH v4 04/15] vfio/hisi_acc: Use the new device life cycle helpers
From: Yi Liu
Tidy up @probe so all migration specific initialization logic is moved
to migration specific @init callback.
Remove vfio_pci_core_{un}init_device() given no user now.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
Reviewed-by: Shameer Kolothum
---
.../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 +--
drivers/vfio/pci/vfio_pci_core.c | 30 ---
include/linux/vfio_pci_core.h | 4 -
3 files changed, 37 insertions(+), 77 deletions(-)
diff --git a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
index 258cae0863ea..47174e2b61bd 100644
--- a/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
+++ b/drivers/vfio/pci/hisilicon/hisi_acc_vfio_pci.c
@@ -1213,8 +1213,28 @@ static const struct vfio_migration_ops
hisi_acc_vfio_pci_migrn_state_ops = {
.migration_get_state = hisi_acc_vfio_pci_get_device_state,
};
+static int hisi_acc_vfio_pci_migrn_init_dev(struct vfio_device *core_vdev)
+{
+ struct hisi_acc_vf_core_device *hisi_acc_vdev = container_of(core_vdev,
+ struct hisi_acc_vf_core_device, core_device.vdev);
+ struct pci_dev *pdev = to_pci_dev(core_vdev->dev);
+ struct hisi_qm *pf_qm = hisi_acc_get_pf_qm(pdev);
+
+ hisi_acc_vdev->vf_id = pci_iov_vf_id(pdev) + 1;
+ hisi_acc_vdev->pf_qm = pf_qm;
+ hisi_acc_vdev->vf_dev = pdev;
+ mutex_init(&hisi_acc_vdev->state_mutex);
+
+ core_vdev->migration_flags = VFIO_MIGRATION_STOP_COPY;
+ core_vdev->mig_ops = &hisi_acc_vfio_pci_migrn_state_ops;
+
+ return vfio_pci_core_init_dev(core_vdev);
+}
+
static const struct vfio_device_ops hisi_acc_vfio_pci_migrn_ops = {
.name = "hisi-acc-vfio-pci-migration",
+ .init = hisi_acc_vfio_pci_migrn_init_dev,
+ .release = vfio_pci_core_release_dev,
.open_device = hisi_acc_vfio_pci_open_device,
.close_device = hisi_acc_vfio_pci_close_device,
.ioctl = hisi_acc_vfio_pci_ioctl,
@@ -1228,6 +1248,8 @@ static const struct vfio_device_ops
hisi_acc_vfio_pci_migrn_ops = {
static const struct vfio_device_ops hisi_acc_vfio_pci_ops = {
.name = "hisi-acc-vfio-pci",
+ .init = vfio_pci_core_init_dev,
+ .release = vfio_pci_core_release_dev,
.open_device = hisi_acc_vfio_pci_open_device,
.close_device = vfio_pci_core_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -1239,63 +1261,36 @@ static const struct vfio_device_ops
hisi_acc_vfio_pci_ops = {
.match = vfio_pci_core_match,
};
-static int
-hisi_acc_vfio_pci_migrn_init(struct hisi_acc_vf_core_device *hisi_acc_vdev,
-struct pci_dev *pdev, struct hisi_qm *pf_qm)
-{
- int vf_id;
-
- vf_id = pci_iov_vf_id(pdev);
- if (vf_id < 0)
- return vf_id;
-
- hisi_acc_vdev->vf_id = vf_id + 1;
- hisi_acc_vdev->core_device.vdev.migration_flags =
- VFIO_MIGRATION_STOP_COPY;
- hisi_acc_vdev->pf_qm = pf_qm;
- hisi_acc_vdev->vf_dev = pdev;
- mutex_init(&hisi_acc_vdev->state_mutex);
-
- return 0;
-}
-
static int hisi_acc_vfio_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *id)
{
struct hisi_acc_vf_core_device *hisi_acc_vdev;
+ const struct vfio_device_ops *ops = &hisi_acc_vfio_pci_ops;
struct hisi_qm *pf_qm;
+ int vf_id;
int ret;
- hisi_acc_vdev = kzalloc(sizeof(*hisi_acc_vdev), GFP_KERNEL);
- if (!hisi_acc_vdev)
- return -ENOMEM;
-
pf_qm = hisi_acc_get_pf_qm(pdev);
if (pf_qm && pf_qm->ver >= QM_HW_V3) {
- ret = hisi_acc_vfio_pci_migrn_init(hisi_acc_vdev, pdev, pf_qm);
- if (!ret) {
- vfio_pci_core_init_device(&hisi_acc_vdev->core_device,
pdev,
- &hisi_acc_vfio_pci_migrn_ops);
- hisi_acc_vdev->core_device.vdev.mig_ops =
- &hisi_acc_vfio_pci_migrn_state_ops;
- } else {
+ vf_id = pci_iov_vf_id(pdev);
+ if (vf_id >= 0)
+ ops = &hisi_acc_vfio_pci_migrn_ops;
+ else
pci_warn(pdev, "migration support failed, continue with
generic interface\n");
- vfio_pci_core_init_device(&hisi_acc_vdev->core_device,
pdev,
- &hisi_acc_vfio_pci_ops);
- }
- } else {
- vfio_pci_core_init_device(&hisi_acc_vdev->core_device, pdev,
- &hisi_acc_vfio_pci_ops);
}
+ hisi_acc_vdev = vfio_alloc_device(hisi_acc_vf_core_device,
+ core_device.vdev, &pdev->dev, ops);
+ if (IS_ERR(hisi_acc_vdev))
+ return PTR_ERR(hisi_acc_vdev);
+
[Intel-gfx] [PATCH v4 03/15] vfio/mlx5: Use the new device life cycle helpers
From: Yi Liu
mlx5 has its own @init/@release for handling migration cap.
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/pci/mlx5/main.c | 50 ++--
1 file changed, 36 insertions(+), 14 deletions(-)
diff --git a/drivers/vfio/pci/mlx5/main.c b/drivers/vfio/pci/mlx5/main.c
index 759a5f5f7b3f..fd6ccb8454a2 100644
--- a/drivers/vfio/pci/mlx5/main.c
+++ b/drivers/vfio/pci/mlx5/main.c
@@ -585,8 +585,35 @@ static const struct vfio_log_ops mlx5vf_pci_log_ops = {
.log_read_and_clear = mlx5vf_tracker_read_and_clear,
};
+static int mlx5vf_pci_init_dev(struct vfio_device *core_vdev)
+{
+ struct mlx5vf_pci_core_device *mvdev = container_of(core_vdev,
+ struct mlx5vf_pci_core_device, core_device.vdev);
+ int ret;
+
+ ret = vfio_pci_core_init_dev(core_vdev);
+ if (ret)
+ return ret;
+
+ mlx5vf_cmd_set_migratable(mvdev, &mlx5vf_pci_mig_ops,
+ &mlx5vf_pci_log_ops);
+
+ return 0;
+}
+
+static void mlx5vf_pci_release_dev(struct vfio_device *core_vdev)
+{
+ struct mlx5vf_pci_core_device *mvdev = container_of(core_vdev,
+ struct mlx5vf_pci_core_device, core_device.vdev);
+
+ mlx5vf_cmd_remove_migratable(mvdev);
+ vfio_pci_core_release_dev(core_vdev);
+}
+
static const struct vfio_device_ops mlx5vf_pci_ops = {
.name = "mlx5-vfio-pci",
+ .init = mlx5vf_pci_init_dev,
+ .release = mlx5vf_pci_release_dev,
.open_device = mlx5vf_pci_open_device,
.close_device = mlx5vf_pci_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -604,22 +631,19 @@ static int mlx5vf_pci_probe(struct pci_dev *pdev,
struct mlx5vf_pci_core_device *mvdev;
int ret;
- mvdev = kzalloc(sizeof(*mvdev), GFP_KERNEL);
- if (!mvdev)
- return -ENOMEM;
- vfio_pci_core_init_device(&mvdev->core_device, pdev, &mlx5vf_pci_ops);
- mlx5vf_cmd_set_migratable(mvdev, &mlx5vf_pci_mig_ops,
- &mlx5vf_pci_log_ops);
+ mvdev = vfio_alloc_device(mlx5vf_pci_core_device, core_device.vdev,
+ &pdev->dev, &mlx5vf_pci_ops);
+ if (IS_ERR(mvdev))
+ return PTR_ERR(mvdev);
+
dev_set_drvdata(&pdev->dev, &mvdev->core_device);
ret = vfio_pci_core_register_device(&mvdev->core_device);
if (ret)
- goto out_free;
+ goto out_put_vdev;
return 0;
-out_free:
- mlx5vf_cmd_remove_migratable(mvdev);
- vfio_pci_core_uninit_device(&mvdev->core_device);
- kfree(mvdev);
+out_put_vdev:
+ vfio_put_device(&mvdev->core_device.vdev);
return ret;
}
@@ -628,9 +652,7 @@ static void mlx5vf_pci_remove(struct pci_dev *pdev)
struct mlx5vf_pci_core_device *mvdev = mlx5vf_drvdata(pdev);
vfio_pci_core_unregister_device(&mvdev->core_device);
- mlx5vf_cmd_remove_migratable(mvdev);
- vfio_pci_core_uninit_device(&mvdev->core_device);
- kfree(mvdev);
+ vfio_put_device(&mvdev->core_device.vdev);
}
static const struct pci_device_id mlx5vf_pci_table[] = {
--
2.21.3
[Intel-gfx] [PATCH v4 02/15] vfio/pci: Use the new device life cycle helpers
From: Yi Liu
Also introduce two pci core helpers as @init/@release for pci drivers:
- vfio_pci_core_init_dev()
- vfio_pci_core_release_dev()
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Jason Gunthorpe
---
drivers/vfio/pci/vfio_pci.c | 20 +-
drivers/vfio/pci/vfio_pci_core.c | 35
include/linux/vfio_pci_core.h| 2 ++
3 files changed, 47 insertions(+), 10 deletions(-)
diff --git a/drivers/vfio/pci/vfio_pci.c b/drivers/vfio/pci/vfio_pci.c
index d9b5c03f8d5b..1d4919edfbde 100644
--- a/drivers/vfio/pci/vfio_pci.c
+++ b/drivers/vfio/pci/vfio_pci.c
@@ -127,6 +127,8 @@ static int vfio_pci_open_device(struct vfio_device
*core_vdev)
static const struct vfio_device_ops vfio_pci_ops = {
.name = "vfio-pci",
+ .init = vfio_pci_core_init_dev,
+ .release= vfio_pci_core_release_dev,
.open_device= vfio_pci_open_device,
.close_device = vfio_pci_core_close_device,
.ioctl = vfio_pci_core_ioctl,
@@ -146,20 +148,19 @@ static int vfio_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *id)
if (vfio_pci_is_denylisted(pdev))
return -EINVAL;
- vdev = kzalloc(sizeof(*vdev), GFP_KERNEL);
- if (!vdev)
- return -ENOMEM;
- vfio_pci_core_init_device(vdev, pdev, &vfio_pci_ops);
+ vdev = vfio_alloc_device(vfio_pci_core_device, vdev, &pdev->dev,
+&vfio_pci_ops);
+ if (IS_ERR(vdev))
+ return PTR_ERR(vdev);
dev_set_drvdata(&pdev->dev, vdev);
ret = vfio_pci_core_register_device(vdev);
if (ret)
- goto out_free;
+ goto out_put_vdev;
return 0;
-out_free:
- vfio_pci_core_uninit_device(vdev);
- kfree(vdev);
+out_put_vdev:
+ vfio_put_device(&vdev->vdev);
return ret;
}
@@ -168,8 +169,7 @@ static void vfio_pci_remove(struct pci_dev *pdev)
struct vfio_pci_core_device *vdev = dev_get_drvdata(&pdev->dev);
vfio_pci_core_unregister_device(vdev);
- vfio_pci_core_uninit_device(vdev);
- kfree(vdev);
+ vfio_put_device(&vdev->vdev);
}
static int vfio_pci_sriov_configure(struct pci_dev *pdev, int nr_virtfn)
diff --git a/drivers/vfio/pci/vfio_pci_core.c b/drivers/vfio/pci/vfio_pci_core.c
index 0a801aee2f2d..77d33739c6e8 100644
--- a/drivers/vfio/pci/vfio_pci_core.c
+++ b/drivers/vfio/pci/vfio_pci_core.c
@@ -2078,6 +2078,41 @@ static void vfio_pci_vga_uninit(struct
vfio_pci_core_device *vdev)
VGA_RSRC_LEGACY_MEM);
}
+int vfio_pci_core_init_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_pci_core_device *vdev =
+ container_of(core_vdev, struct vfio_pci_core_device, vdev);
+
+ vdev->pdev = to_pci_dev(core_vdev->dev);
+ vdev->irq_type = VFIO_PCI_NUM_IRQS;
+ mutex_init(&vdev->igate);
+ spin_lock_init(&vdev->irqlock);
+ mutex_init(&vdev->ioeventfds_lock);
+ INIT_LIST_HEAD(&vdev->dummy_resources_list);
+ INIT_LIST_HEAD(&vdev->ioeventfds_list);
+ mutex_init(&vdev->vma_lock);
+ INIT_LIST_HEAD(&vdev->vma_list);
+ INIT_LIST_HEAD(&vdev->sriov_pfs_item);
+ init_rwsem(&vdev->memory_lock);
+
+ return 0;
+}
+EXPORT_SYMBOL_GPL(vfio_pci_core_init_dev);
+
+void vfio_pci_core_release_dev(struct vfio_device *core_vdev)
+{
+ struct vfio_pci_core_device *vdev =
+ container_of(core_vdev, struct vfio_pci_core_device, vdev);
+
+ mutex_destroy(&vdev->igate);
+ mutex_destroy(&vdev->ioeventfds_lock);
+ mutex_destroy(&vdev->vma_lock);
+ kfree(vdev->region);
+ kfree(vdev->pm_save);
+ vfio_free_device(core_vdev);
+}
+EXPORT_SYMBOL_GPL(vfio_pci_core_release_dev);
+
void vfio_pci_core_init_device(struct vfio_pci_core_device *vdev,
struct pci_dev *pdev,
const struct vfio_device_ops *vfio_pci_ops)
diff --git a/include/linux/vfio_pci_core.h b/include/linux/vfio_pci_core.h
index 089b603bcfdc..0499ea836058 100644
--- a/include/linux/vfio_pci_core.h
+++ b/include/linux/vfio_pci_core.h
@@ -109,6 +109,8 @@ void vfio_pci_core_close_device(struct vfio_device
*core_vdev);
void vfio_pci_core_init_device(struct vfio_pci_core_device *vdev,
struct pci_dev *pdev,
const struct vfio_device_ops *vfio_pci_ops);
+int vfio_pci_core_init_dev(struct vfio_device *core_vdev);
+void vfio_pci_core_release_dev(struct vfio_device *core_vdev);
int vfio_pci_core_register_device(struct vfio_pci_core_device *vdev);
void vfio_pci_core_uninit_device(struct vfio_pci_core_device *vdev);
void vfio_pci_core_unregister_device(struct vfio_pci_core_device *vdev);
--
2.21.3
[Intel-gfx] [PATCH v4 01/15] vfio: Add helpers for unifying vfio_device life cycle
The idea is to let vfio core manage the vfio_device life cycle instead
of duplicating the logic cross drivers. This is also a preparatory
step for adding struct device into vfio_device.
New pair of helpers together with a kref in vfio_device:
- vfio_alloc_device()
- vfio_put_device()
Drivers can register @init/@release callbacks to manage any private
state wrapping the vfio_device.
However vfio-ccw doesn't fit this model due to a life cycle mess
that its private structure mixes both parent and mdev info hence must
be allocated/freed outside of the life cycle of vfio device.
Per prior discussions this won't be fixed in short term by IBM folks.
Instead of waiting for those modifications introduce another helper
vfio_init_device() so ccw can call it to initialize a pre-allocated
vfio_device.
Further implication of the ccw trick is that vfio_device cannot be
freed uniformly in vfio core. Instead, require *EVERY* driver to
implement @release and free vfio_device inside. Then ccw can choose
to delay the free at its own discretion.
Another trick down the road is that kvzalloc() is used to accommodate
the need of gvt which uses vzalloc() while all others use kzalloc().
So drivers should call a helper vfio_free_device() to free the
vfio_device instead of assuming that kfree() or vfree() is appliable.
Later once the ccw mess is fixed we can remove those tricks and
fully handle structure alloc/free in vfio core.
Existing vfio_{un}init_group_dev() will be deprecated after all
existing usages are converted to the new model.
Suggested-by: Jason Gunthorpe
Co-developed-by: Yi Liu
Signed-off-by: Yi Liu
Signed-off-by: Kevin Tian
Reviewed-by: Tony Krowiak
Reviewed-by: Jason Gunthorpe
Reviewed-by: Eric Auger
---
drivers/vfio/vfio_main.c | 92
include/linux/vfio.h | 25 ++-
2 files changed, 116 insertions(+), 1 deletion(-)
diff --git a/drivers/vfio/vfio_main.c b/drivers/vfio/vfio_main.c
index 27d9186f35d5..b9c6a97d647a 100644
--- a/drivers/vfio/vfio_main.c
+++ b/drivers/vfio/vfio_main.c
@@ -498,6 +498,98 @@ void vfio_uninit_group_dev(struct vfio_device *device)
}
EXPORT_SYMBOL_GPL(vfio_uninit_group_dev);
+/* Release helper called by vfio_put_device() */
+void vfio_device_release(struct kref *kref)
+{
+ struct vfio_device *device =
+ container_of(kref, struct vfio_device, kref);
+
+ vfio_uninit_group_dev(device);
+
+ /*
+* kvfree() cannot be done here due to a life cycle mess in
+* vfio-ccw. Before the ccw part is fixed all drivers are
+* required to support @release and call vfio_free_device()
+* from there.
+*/
+ device->ops->release(device);
+}
+EXPORT_SYMBOL_GPL(vfio_device_release);
+
+/*
+ * Allocate and initialize vfio_device so it can be registered to vfio
+ * core.
+ *
+ * Drivers should use the wrapper vfio_alloc_device() for allocation.
+ * @size is the size of the structure to be allocated, including any
+ * private data used by the driver.
+ *
+ * Driver may provide an @init callback to cover device private data.
+ *
+ * Use vfio_put_device() to release the structure after success return.
+ */
+struct vfio_device *_vfio_alloc_device(size_t size, struct device *dev,
+ const struct vfio_device_ops *ops)
+{
+ struct vfio_device *device;
+ int ret;
+
+ if (WARN_ON(size < sizeof(struct vfio_device)))
+ return ERR_PTR(-EINVAL);
+
+ device = kvzalloc(size, GFP_KERNEL);
+ if (!device)
+ return ERR_PTR(-ENOMEM);
+
+ ret = vfio_init_device(device, dev, ops);
+ if (ret)
+ goto out_free;
+ return device;
+
+out_free:
+ kvfree(device);
+ return ERR_PTR(ret);
+}
+EXPORT_SYMBOL_GPL(_vfio_alloc_device);
+
+/*
+ * Initialize a vfio_device so it can be registered to vfio core.
+ *
+ * Only vfio-ccw driver should call this interface.
+ */
+int vfio_init_device(struct vfio_device *device, struct device *dev,
+const struct vfio_device_ops *ops)
+{
+ int ret;
+
+ vfio_init_group_dev(device, dev, ops);
+
+ if (ops->init) {
+ ret = ops->init(device);
+ if (ret)
+ goto out_uninit;
+ }
+
+ kref_init(&device->kref);
+ return 0;
+
+out_uninit:
+ vfio_uninit_group_dev(device);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(vfio_init_device);
+
+/*
+ * The helper called by driver @release callback to free the device
+ * structure. Drivers which don't have private data to clean can
+ * simply use this helper as its @release.
+ */
+void vfio_free_device(struct vfio_device *device)
+{
+ kvfree(device);
+}
+EXPORT_SYMBOL_GPL(vfio_free_device);
+
static struct vfio_group *vfio_noiommu_group_alloc(struct device *dev,
enum vfio_group_type type)
{
diff --git a/include/linux/vfio.h b/include/linux/vfio.h
index 0e2826559091..f6
[Intel-gfx] [PATCH v4 00/15] Tidy up vfio_device life cycle
The idea is to let vfio core manage the vfio_device life cycle instead of duplicating the logic cross drivers. Besides cleaner code in driver side this also allows adding struct device to vfio_device as the first step toward adding cdev uAPI in the future. Another benefit is that user can now look at sysfs to decide whether a device is bound to vfio [1], e.g.: /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 Though most drivers can fit the new model naturally: - vfio_alloc_device() to allocate and initialize vfio_device - vfio_put_device() to release vfio_device - dev_ops->init() for driver private initialization - dev_ops->release() for driver private cleanup vfio-ccw is the only exception due to a life cycle mess that its private structure mixes both parent and mdev info hence must be alloc/freed outside of the life cycle of vfio device. Per prior discussions this won't be fixed in short term by IBM folks [2]. Instead of waiting this series introduces a few tricks to move forward: - vfio_init_device() to initialize a pre-allocated device structure; - require *EVERY* driver to implement @release and free vfio_device inside. Then vfio-ccw can use a completion mechanism to delay the free to css driver; The second trick is not a real burden to other drivers because they all require a @release for private cleanup anyway. Later once the ccw mess is fixed a simple cleanup can be done by moving free from @release to vfio core. Thanks Kevin [1] https://listman.redhat.com/archives/libvir-list/2022-August/233482.html [2] https://lore.kernel.org/all/0ee29bd6583f17f0ee4ec0769fa50e8ea6703623.ca...@linux.ibm.com/ v4: - fix use-after-free issue in @release of mtty/mbochs and also change mdpy/ap to free vfio-device as the last thing in @release (Alex) - revert the rename from 'vfio' to 'vfio_group' in procfs (Alex) v3: - https://lore.kernel.org/lkml/20220909102247.67324-1-kevin.t...@intel.com/ - rebase to vfio-next after resolving conflicts with Yishai's series - add missing fixes for two checkpatch errors - fix grammar issues (Eric Auger) - add more r-b's v2: - https://lore.kernel.org/lkml/20220901143747.32858-1-kevin.t...@intel.com/ - rebase to 6.0-rc3 - fix build warnings (lkp) - patch1: remove unnecessary forward reference (Jason) - patch10: leave device_set released by vfio core (Jason) - patch13: add Suggested-by - patch15: add ABI file sysfs-devices-vfio-dev (Alex) - patch15: rename 'vfio' to 'vfio_group' in procfs (Jason) v1: https://lore.kernel.org/lkml/20220827171037.30297-1-kevin.t...@intel.com/ Kevin Tian (6): vfio: Add helpers for unifying vfio_device life cycle drm/i915/gvt: Use the new device life cycle helpers vfio/platform: Use the new device life cycle helpers vfio/amba: Use the new device life cycle helpers vfio/ccw: Use the new device life cycle helpers vfio: Rename vfio_device_put() and vfio_device_try_get() Yi Liu (9): vfio/pci: Use the new device life cycle helpers vfio/mlx5: Use the new device life cycle helpers vfio/hisi_acc: Use the new device life cycle helpers vfio/mdpy: Use the new device life cycle helpers vfio/mtty: Use the new device life cycle helpers vfio/mbochs: Use the new device life cycle helpers vfio/ap: Use the new device life cycle helpers vfio/fsl-mc: Use the new device life cycle helpers vfio: Add struct device to vfio_device .../ABI/testing/sysfs-devices-vfio-dev| 8 + MAINTAINERS | 1 + drivers/gpu/drm/i915/gvt/gvt.h| 5 +- drivers/gpu/drm/i915/gvt/kvmgt.c | 52 -- drivers/gpu/drm/i915/gvt/vgpu.c | 33 ++-- drivers/s390/cio/vfio_ccw_ops.c | 52 +- drivers/s390/cio/vfio_ccw_private.h | 3 + drivers/s390/crypto/vfio_ap_ops.c | 50 +++--- drivers/vfio/fsl-mc/vfio_fsl_mc.c | 85 + .../vfio/pci/hisilicon/hisi_acc_vfio_pci.c| 80 - drivers/vfio/pci/mlx5/main.c | 50 -- drivers/vfio/pci/vfio_pci.c | 20 +-- drivers/vfio/pci/vfio_pci_core.c | 23 ++- drivers/vfio/platform/vfio_amba.c | 72 ++-- drivers/vfio/platform/vfio_platform.c | 66 +-- drivers/vfio/platform/vfio_platform_common.c | 71 +++- drivers/vfio/platform/vfio_platform_private.h | 18 +- drivers/vfio/vfio_main.c | 164 +++--- include/linux/vfio.h | 28 ++- include/linux/vfio_pci_core.h | 6 +- samples/vfio-mdev/mbochs.c| 73 +--- samples/vfio-mdev/mdpy.c | 81 + samples/vfio-mdev/mtty.c | 67 --- 23 files changed, 728 insertions(+), 380 deletions(-) create mode 100644 Documentation/ABI/testing/sysfs-devices-vfio-dev base-commit: f39856aacb078c1c93acef011a37121b17d54fe0 -- 2.21.3
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Pipewriteback (rev9)
== Series Details ==
Series: Enable Pipewriteback (rev9)
URL : https://patchwork.freedesktop.org/series/107440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12162 -> Patchwork_107440v9
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/index.html
Participating hosts (44 -> 42)
--
Additional (1): fi-tgl-dsi
Missing(3): fi-icl-u2 fi-bdw-samus fi-tgl-u2
Known issues
Here are the changes found in Patchwork_107440v9 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[PASS][1] -> [INCOMPLETE][2] ([i915#4785])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-bdw-5557u: [PASS][3] -> [INCOMPLETE][4] ([i915#146] /
[i915#6712])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/fi-bdw-5557u/igt@i915_susp...@basic-s3-without-i915.html
* igt@runner@aborted:
- fi-hsw-4770:NOTRUN -> [FAIL][5] ([fdo#109271] / [i915#4312] /
[i915#5594] / [i915#6246])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/fi-hsw-4770/igt@run...@aborted.html
Possible fixes
* igt@gem_exec_suspend@basic-s0@smem:
- {bat-adlm-1}: [DMESG-WARN][6] ([i915#2867]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/bat-adlm-1/igt@gem_exec_suspend@basic...@smem.html
* igt@i915_selftest@live@reset:
- {bat-rpls-1}: [DMESG-FAIL][8] ([i915#4983]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/bat-rpls-1/igt@i915_selftest@l...@reset.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/bat-rpls-1/igt@i915_selftest@l...@reset.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][10] ([i915#6298]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12162/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#146]: https://gitlab.freedesktop.org/drm/intel/issues/146
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2582]: https://gitlab.freedesktop.org/drm/intel/issues/2582
[i915#2867]: https://gitlab.freedesktop.org/drm/intel/issues/2867
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#4983]: https://gitlab.freedesktop.org/drm/intel/issues/4983
[i915#5122]: https://gitlab.freedesktop.org/drm/intel/issues/5122
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#5278]: https://gitlab.freedesktop.org/drm/intel/issues/5278
[i915#5594]: https://gitlab.freedesktop.org/drm/intel/issues/5594
[i915#6246]: https://gitlab.freedesktop.org/drm/intel/issues/6246
[i915#6298]: https://gitlab.freedesktop.org/drm/intel/issues/6298
[i915#6712]: https://gitlab.freedesktop.org/drm/intel/issues/6712
Build changes
-
* Linux: CI_DRM_12162 -> Patchwork_107440v9
CI-20190529: 20190529
CI_DRM_12162: 1d049fe35537d9239f350ab1b728b5c0dda5907c @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6659: 1becf700a737a7a98555a0cfbe8566355377afb2 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107440v9: 1d049fe35537d9239f350ab1b728b5c0dda5907c @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
21eae8e7e462 drm/i915: Enabling WD Transcoder
e9d0f9eda842 drm/i915 : Changing intel_connector iterators
0ca8f93389fb drm/i915: Define WD trancoder for i915
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v9/index.html
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable Pipewriteback (rev9)
== Series Details == Series: Enable Pipewriteback (rev9) URL : https://patchwork.freedesktop.org/series/107440/ 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.CHECKPATCH: warning for Enable Pipewriteback (rev9)
== Series Details ==
Series: Enable Pipewriteback (rev9)
URL : https://patchwork.freedesktop.org/series/107440/
State : warning
== Summary ==
Error: dim checkpatch failed
aaa52a3b740d drm/i915: Define WD trancoder for i915
f81ac46ac2d3 drm/i915 : Changing intel_connector iterators
-:76: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#76: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1507:
+#define to_intel_connector(x) (((x->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)) ? \
+ NULL : container_of(x, struct intel_connector,
base))
-:76: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#76: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1507:
+#define to_intel_connector(x) (((x->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)) ? \
+ NULL : container_of(x, struct intel_connector,
base))
-:104: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#104: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:2093:
+
+ }
total: 0 errors, 0 warnings, 3 checks, 104 lines checked
42c5bd3fff8c drm/i915: Enabling WD Transcoder
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
Traceback (most recent call last):
File "scripts/spdxcheck.py", line 11, in
import git
ModuleNotFoundError: No module named 'git'
-:559: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#559:
new file mode 100644
-:597: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!job"
#597: FILE: drivers/gpu/drm/i915/display/intel_wd.c:34:
+ if (job == NULL) {
-:634: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#634: FILE: drivers/gpu/drm/i915/display/intel_wd.c:71:
+ DRM_ERROR("unsupported pixel format %x!\n",
+ pixel_format);
-:712: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#712: FILE: drivers/gpu/drm/i915/display/intel_wd.c:149:
+ intel_de_write(i915, WD_STREAMCAP_CTL(intel_wd->trans),
+ *tmp);
-:735: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#735: FILE: drivers/gpu/drm/i915/display/intel_wd.c:172:
+ memcpy(pipe_config, intel_crtc->config,
+ sizeof(*pipe_config));
-:786: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#786: FILE: drivers/gpu/drm/i915/display/intel_wd.c:223:
+ wakeref = intel_display_power_get_if_enabled(dev_priv,
+ encoder->power_domain);
-:827: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#827: FILE: drivers/gpu/drm/i915/display/intel_wd.c:264:
+ drm_dbg_kms(&i915->drm, "Invalid framebuffer size %ux%u\n",
+ fb->width, fb->height);
-:834: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#834: FILE: drivers/gpu/drm/i915/display/intel_wd.c:271:
+ drm_dbg_kms(&i915->drm, "Unsupported framebuffer format %08x\n",
+ fb->format->format);
-:875: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#875: FILE: drivers/gpu/drm/i915/display/intel_wd.c:312:
+static bool intel_fastset_dis(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
-:929: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#929: FILE: drivers/gpu/drm/i915/display/intel_wd.c:366:
+ drm_encoder_helper_add(drm_enc,
+ &wd_encoder_helper_funcs);
-:944: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#944: FILE: drivers/gpu/drm/i915/display/intel_wd.c:381:
+ err = drm_writeback_connector_init_with_encoder(&i915->drm,
+ wb_conn, drm_enc, &wb_connector_funcs,
-:962: WARNING:RETURN_VOID: void function return statements are not generally
useful
#962: FILE: drivers/gpu/drm/i915/display/intel_wd.c:399:
+ return;
+}
-:1008: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1008: FILE: drivers/gpu/drm/i915/display/intel_wd.c:445:
+ intel_de_write(dev_priv, WD_SURF(intel_wd->trans),
+ i915_ggtt_offset(intel_wd->vma));
-:1019: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1019: FILE: drivers/gpu/drm/i915/display/intel_wd.c:456:
+ tmp = intel_de_read(dev_priv,
+ WD_STREAMCAP_CTL(intel_wd->trans));
-:1108: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1108: FILE: drivers/gpu/drm/i915/display/intel_wd.c:545:
+ if (intel_de_wait_for_set(dev_priv, PIPECONF(intel_wd->trans),
+ WD_TRANS_ACTIVE, 10))
-:1130: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match
Re: [Intel-gfx] [PATCH 4/7] drm/i915/hwmon: Show device level energy usage
On Tue, 13 Sep 2022 01:50:08 -0700, Tvrtko Ursulin wrote: > Hi Tvrtko, > On 25/08/2022 14:21, Badal Nilawar wrote: > > From: Dale B Stimson > > > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > index 9a2d10edfce8..03d71c6869d3 100644 > > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > > @@ -25,3 +25,11 @@ Contact: dri-de...@lists.freedesktop.org > > Description: RO. Card default power limit (default TDP setting). > > Only supported for particular Intel i915 graphics > > platforms. > > + > > +What: /sys/devices/.../hwmon/hwmon/energy1_input > > +Date: June 2022 > > +KernelVersion: 5.19 > > Date and kernel version will need updating throughout I think. > > But why I am here actually is to ask if there are plans to make > intel_gpu_top support this? It would be nice to have since it reports power > for integrated. There were no plans but now Riana has an IGT patch series which exposes a unified inteface for rapl/hwmon (igfx/dgfx): https://patchwork.freedesktop.org/series/108185/ So perhaps we can either have intel_gpu_top use this IGT lib or if it doesn't, copy some functions to intel_gpu_top. Thanks. -- Ashutosh
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/dg2: introduce Wa_22015475538
== Series Details ==
Series: drm/i915/dg2: introduce Wa_22015475538
URL : https://patchwork.freedesktop.org/series/108795/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12161_full -> Patchwork_108795v1_full
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_108795v1_full absolutely need
to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_108795v1_full, please notify your bug team to allow
them
to document this new failure mode, which will reduce false positives in CI.
Participating hosts (9 -> 11)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108795v1_full:
### IGT changes ###
Possible regressions
* igt@i915_pm_rpm@reg-read-ioctl:
- shard-tglb: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-tglb7/igt@i915_pm_...@reg-read-ioctl.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglb8/igt@i915_pm_...@reg-read-ioctl.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_color@ctm-0-75@pipe-a-hdmi-a-1:
- {shard-tglu}: NOTRUN -> [FAIL][3] +7 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/shard-tglu-6/igt@kms_color@ctm-0...@pipe-a-hdmi-a-1.html
New tests
-
New tests have been introduced between CI_DRM_12161_full and
Patchwork_108795v1_full:
### New IGT tests (2) ###
* igt@kms_lease@lease_revoke@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.05] s
* igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.15] s
Known issues
Here are the changes found in Patchwork_108795v1_full that come from known
issues:
### CI changes ###
Possible fixes
* boot:
- shard-glk: ([PASS][4], [PASS][5], [PASS][6], [PASS][7],
[PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13],
[PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19],
[PASS][20], [PASS][21], [PASS][22], [PASS][23], [FAIL][24], [PASS][25],
[PASS][26], [PASS][27], [PASS][28]) ([i915#4392]) -> ([PASS][29], [PASS][30],
[PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk7/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk6/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk5/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk3/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk2/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk1/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk9/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk9/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk9/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-glk8/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patc
Re: [Intel-gfx] [PATCH 2/7] drm/i915/hwmon: Add HWMON current voltage support
On Thu, 15 Sep 2022 07:40:37 -0700, Nilawar, Badal wrote:
>
> On 29-08-2022 23:00, Dixit, Ashutosh wrote:
> > On Thu, 25 Aug 2022 06:21:13 -0700, Badal Nilawar wrote:
> >>
> >> +static int
> >> +hwm_in_read(struct hwm_drvdata *ddat, u32 attr, long *val)
> >> +{
> >> + struct i915_hwmon *hwmon = ddat->hwmon;
> >> + intel_wakeref_t wakeref;
> >> + u32 reg_value;
> >> +
> >> + switch (attr) {
> >> + case hwmon_in_input:
> >> + with_intel_runtime_pm(ddat->uncore->rpm, wakeref)
> >> + reg_value = intel_uncore_read(ddat->uncore,
> >> hwmon->rg.gt_perf_status);
> >> + /* In units of 2.5 millivolt */
> >> + *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK,
> >> reg_value) * 25, 10);
>
> And use above scale factors here.
> *val = DIV_ROUND_CLOSEST(REG_FIELD_GET(GEN12_VOLTAGE_MASK, reg_value) *
> SF_VOLTAGE_MUL, SF_VOLTAGE_DIV);
> Regards,
> Badal
> >
> > Let's complete this comment to so that it is clear what's happening:
> >
> > /* HW register value is in units of 2.5 millivolt */
This was missed in the latest rev so if we could remember to add this that
would be great.
Re: [Intel-gfx] [PATCH 3/7] drm/i915/hwmon: Power PL1 limit and TDP setting
On Fri, 16 Sep 2022 08:00:50 -0700, Badal Nilawar wrote: > > diff --git a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > index e2974f928e58..bc061238e35c 100644 > --- a/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > +++ b/Documentation/ABI/testing/sysfs-driver-intel-i915-hwmon > @@ -5,3 +5,23 @@ Contact: dri-de...@lists.freedesktop.org > Description: RO. Current Voltage in millivolt. > > Only supported for particular Intel i915 graphics platforms. > + > +What:/sys/devices/.../hwmon/hwmon/power1_max > +Date:September 2022 > +KernelVersion: 6 Maybe we should ask someone but even if we merge this today to drm-tip this will appear in kernel.org Linus' version only in 6.2. So I think we should set this as 6.2 on all patches. Except for this, thanks for making the changes, this is: Reviewed-by: Ashutosh Dixit
Re: [Intel-gfx] Intel Arc A370M vs Linux 5.19
On Fri, 16 Sept 2022 at 00:35, Tvrtko Ursulin wrote: >> On 15/09/2022 15:54, Rodrigo Vivi wrote: > > On Thu, Sep 15, 2022 at 10:40:59PM +0800, Daniel J Blueman wrote: > >> On Thu, 15 Sept 2022 at 22:09, Rodrigo Vivi wrote: > >>> On Thu, Sep 15, 2022 at 09:08:08PM +0800, Daniel J Blueman wrote: > Dear Intel et al, > > With a HP Spectre x360 16 16-f1xxx/891D (Intel i7-1260P) with an Arc > A370M GPU [1] running the latest Ubuntu 22.10 5.19.0-15-generic > kernel, we see: > > i915 :03:00.0: Your graphics device 5693 is not properly supported > by the driver in this kernel version. To force driver probe anyway, > use i915.force_probe=5693 > > Since the GPU is unmanaged, battery life is around 30% of what it > could be. Unsurprisingly, adding i915.force_probe=5693 causes > additional issues. Given a lack of BIOS option to disable the GPU, is > there any advice for Linux support or at least putting the GPU into > D3? I see only Windows drivers on the official support page [2], and > Linux 6.0-rc5 isn't buildable [3]. > >>> > >>> I believe this is what you are looking for: > >>> > >>> echo auto | sudo tee /sys/bus/pci/devices/\:03\:00.0/power/control > >>> > >>> In Linux the default is to keep the unmanaged devices in D0. > >>> But changing the rpm to auto should transition the device to D3. > >>> > >>> You can go further and check with the lspci -vv if there are other > >>> unmanaged devices in the same pci root tree and also add them to the > >>> 'auto' rpm so you can even achieve D3cold in that whole device, what > >>> gives you extra power savings. > >>> > >>> I hope this helps for now. > >> > >> Yes, I was also hoping this would work as we see D3hot is supported: > >> > >> # echo auto > /sys/bus/pci/devices/\:03\:00.0/power/control > >> # lspci -vvvs 03:00.0 > >> ... > >> Capabilities: [d0] Power Management version 3 > >> Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA > >> PME(D0+,D1-,D2-,D3hot+,D3cold-) > >> Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME- > >> ^^ > >> > >> However it stays in D0 with PME disabled as we see. "Kernel modules: > >> i915" may suggest the i915 driver holds a reference to it, preventing > >> the transition. > > > > Oh, yes. I was thinking more on using the command line I sent when > > the i915 is not probed. i.e. without using the force probe. your first > > scenario. > > Could it help to bind DG2 to vfio-pci and so prevent i915 touching it? Bingo! Booting with vfio-pci.ids=8086:5693 in my case left the dGPU in D3, giving the expected battery runtime. Many thanks Tvrtko, Dan -- Daniel J Blueman
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do not cleanup obj with NULL bo->resource
== Series Details ==
Series: drm/i915: Do not cleanup obj with NULL bo->resource
URL : https://patchwork.freedesktop.org/series/108792/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12161_full -> Patchwork_108792v1_full
Summary
---
**SUCCESS**
No regressions found.
Participating hosts (9 -> 11)
--
Additional (2): shard-rkl shard-tglu
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_108792v1_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@kms_color@ctm-0-75@pipe-a-hdmi-a-1:
- {shard-tglu}: NOTRUN -> [FAIL][1] +7 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-tglu-6/igt@kms_color@ctm-0...@pipe-a-hdmi-a-1.html
New tests
-
New tests have been introduced between CI_DRM_12161_full and
Patchwork_108792v1_full:
### New IGT tests (2) ###
* igt@kms_lease@lease_revoke@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.05] s
* igt@kms_lease@page_flip_implicit_plane@pipe-d-hdmi-a-1:
- Statuses : 1 pass(s)
- Exec time: [0.15] s
Known issues
Here are the changes found in Patchwork_108792v1_full that come from known
issues:
### CI changes ###
Issues hit
* boot:
- shard-apl: ([PASS][2], [PASS][3], [PASS][4], [PASS][5],
[PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12],
[PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18],
[PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24],
[PASS][25], [PASS][26]) -> ([PASS][27], [PASS][28], [PASS][29], [PASS][30],
[PASS][31], [FAIL][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36],
[PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42],
[PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48],
[PASS][49], [PASS][50], [PASS][51]) ([i915#4386])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl7/boot.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl6/boot.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl3/boot.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl2/boot.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl3/boot.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl3/boot.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl1/boot.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl1/boot.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl8/boot.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl1/boot.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl8/boot.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl8/boot.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl8/boot.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl1/boot.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl7/boot.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl7/boot.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl7/boot.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl2/boot.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl3/boot.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl2/boot.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl6/boot.html
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl6/boot.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl6/boot.html
[25]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl6/boot.html
[26]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/shard-apl2/boot.html
[27]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl1/boot.html
[28]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl1/boot.html
[29]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl1/boot.html
[30]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl1/boot.html
[31]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl2/boot.html
[32]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl2/boot.html
[33]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl2/boot.html
[34]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/shard-apl2/boot.h
Re: [Intel-gfx] [PATCH v3 15/15] vfio: Add struct device to vfio_device
> From: Alex Williamson > Sent: Wednesday, September 21, 2022 4:27 AM > > On Fri, 9 Sep 2022 18:22:47 +0800 > Kevin Tian wrote: > > > From: Yi Liu > > > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > > sysfs path of the parent, indicating the device is bound to a vfio > > driver, e.g.: > > > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > > > It is also a preparatory step toward adding cdev for supporting future > > device-oriented uAPI. > > > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > > /proc/devices. > > What's the risk/reward here, is this just more aesthetically pleasing > symmetry vs 'vfio-dev'? The char major number to name association in > /proc/devices seems pretty obscure, but what due diligence have we done > to make sure this doesn't break anyone? Thanks, > I'm not sure whether the content of /proc/devices is considered as ABI. @Jason? But to be safe I can remove this change in next version. If it's the right thing to do such change after discussion then it can be done in a separate patch after.
Re: [Intel-gfx] [PATCH v3 06/15] vfio/mtty: Use the new device life cycle helpers
> From: Alex Williamson
> Sent: Wednesday, September 21, 2022 3:17 AM
>
> On Fri, 9 Sep 2022 18:22:38 +0800
> Kevin Tian wrote:
>
> > From: Yi Liu
> >
> > and manage available ports inside @init/@release.
> >
> > Signed-off-by: Yi Liu
> > Signed-off-by: Kevin Tian
> > Reviewed-by: Jason Gunthorpe
> > ---
> > samples/vfio-mdev/mtty.c | 67 +++-
> > 1 file changed, 39 insertions(+), 28 deletions(-)
> >
> > diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> > index f42a59ed2e3f..41301d50b247 100644
> > --- a/samples/vfio-mdev/mtty.c
> > +++ b/samples/vfio-mdev/mtty.c
> ...
> > +static int mtty_probe(struct mdev_device *mdev)
> > +{
> > + struct mdev_state *mdev_state;
> > + int ret;
> > +
> > + mdev_state = vfio_alloc_device(mdev_state, vdev, &mdev->dev,
> > + &mtty_dev_ops);
> > + if (IS_ERR(mdev_state))
> > + return PTR_ERR(mdev_state);
> >
> > ret = vfio_register_emulated_iommu_dev(&mdev_state->vdev);
> > if (ret)
> > - goto err_vconfig;
> > + goto err_put_vdev;
> > dev_set_drvdata(&mdev->dev, mdev_state);
> > return 0;
> >
> > -err_vconfig:
> > - kfree(mdev_state->vconfig);
> > -err_state:
> > - vfio_uninit_group_dev(&mdev_state->vdev);
> > - kfree(mdev_state);
> > -err_nr_ports:
> > - atomic_add(nr_ports, &mdev_avail_ports);
> > +err_put_vdev:
> > + vfio_put_device(&mdev_state->vdev);
> > return ret;
> > }
> >
> > +static void mtty_release_dev(struct vfio_device *vdev)
> > +{
> > + struct mdev_state *mdev_state =
> > + container_of(vdev, struct mdev_state, vdev);
> > +
> > + kfree(mdev_state->vconfig);
> > + vfio_free_device(vdev);
> > + atomic_add(mdev_state->nr_ports, &mdev_avail_ports);
>
> I must be missing something, isn't this a use-after-free?
Yes, it's a use-after-free indeed. Thanks for catching it!
>
> mdev_state is allocated via vfio_alloc_device(), where vdev is the
> first entry in that structure, so this is equivalent to
> kvfree(mdev_state). mbochs has the same issue. mdpy and vfio-ap
> adjust global counters after vfio_free_device(), which I think muddies
> the situation. Shouldn't we look suspiciously at any .release callback
> where vfio_free_device() isn't the last thing executed? Thanks,
>
Yes. I'll scrutinize it again. To be consistent I'll make sure the free
is the last line in all .release callbacks though not required for
some (e.g. mdpy and vfio-ap).
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering
On Tue, Sep 20, 2022 at 10:18:20AM +, Patchwork wrote: > == Series Details == > > Series: Explicit MCR handling and MTL steering > URL : https://patchwork.freedesktop.org/series/108755/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_108755v1_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_108755v1_full absolutely need > to be > verified manually. > > If you think the reported changes have nothing to do with the changes > introduced in Patchwork_108755v1_full, please notify your bug team to allow > them > to document this new failure mode, which will reduce false positives in CI. > > > > Participating hosts (10 -> 10) > -- > > No changes in participating hosts > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_108755v1_full: > > ### IGT changes ### > > Possible regressions > > * igt@i915_suspend@debugfs-reader: > - shard-tglb: [PASS][1] -> [INCOMPLETE][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb3/igt@i915_susp...@debugfs-reader.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-tglb1/igt@i915_susp...@debugfs-reader.html Looks like the system simply never came back from suspend; no errors in dmesg. Does not appear related to this series. Matt > > > Warnings > > * igt@runner@aborted: > - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], > [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], > [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], > [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], > [FAIL][25], [FAIL][26], [FAIL][27]) ([i915#6599]) -> ([FAIL][28], [FAIL][29], > [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], > [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], > [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], > [FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52]) >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html >[21]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html >[22]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html >[23]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html >[24]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html >[25]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html >[26]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html >[27]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html >[28]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl10/igt@run...@aborted.html >[29]: > https://intel-gfx-ci.01.or
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
Hi Matt, Lucas,
thanks for your feedback,
> > > + switch (gms) {
> > > + case 0x0 ... 0x10:
> > > + return gms * 32;
> > > + case 0x20:
> > > + return 1024;
> > > + case 0x30:
> > > + return 1536;
> > > + case 0x40:
> > > + return 2048;
> > > + case 0xf0 ... 0xfe:
> >
> > just a bit puzzled by the fact that case ranges are not standard
> > and are supported only by GCC, unless, of course, I miss
> > something. Do we still want to use them as they are widely used
> > around the kernel?
>
> i915 already has 17 other uses of this notation and the DRM subsystem in
> general has about 50 today. So it's not super common, but I think it
> should be okay to use. I believe clang supports this language extension
> as well and the coding style doc doesn't say anything one way or the
> other.
I thought clang supports it for C++ rather than C, but I'm not a
clang expert, so that I might be wrong.
The fact that it is widely used is never a convincing argument
and if gcc supports it, then it does it against the standard,
both C11 and C17 (this is what puzzles me everytime I see these C
tricks offered by gcc).
Anyway, I'm not against it (nor in favour) as the ellipsis is
becoming very commonly used. My comment, by the way, did not mean
to block the patch, I just wanted to check what other people
think about.
Thanks,
Andi
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
On Tue, Sep 20, 2022 at 06:48:46PM +, Srivatsa, Anusha wrote: > > > > -Original Message- > > From: Ville Syrjälä > > Sent: Tuesday, September 20, 2022 1:20 AM > > To: Srivatsa, Anusha > > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > > ; Vivi, Rodrigo > > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > > This is a prep series for the actual cdclk refactoring that will be > > > sent following this. Idea is to have a struct - cdclk_step that holds > > > the following: > > > - cdclk action (squash, crawl or modeset) > > > - cdclk frequency > > > which gets populated in atomic check. Driver uses the populated values > > > during atomic commit to do the suitable sequence of actions like > > > programming squash ctl registers in case of squashing or PLL sequence > > > incase of modeset and so on. > > > > > > This series just addresses the initial idea. The actual plumming in > > > the atomic commit phase will be sent shortly. > > > > OK, people keep ignoring what I say so I just typed up the code quickly. > > This > > to me seems like the most straightforward way to do what we need: > > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > > > Totally untested ofc, apart from me doing a quick scan through our cdclk > > tables for the crawl+squahs platforms to make sure that this approach > > should produce sane values. > Ville, > Why have a mid cdclk_config? Cant we use the new-cdclk-config for this > purpose? You either - start at old, crawl to mid, then squash to new - start at old, squash to mid, then crawl to new -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915: Perf_limit_reasons are only available for Gen11+
On Mon, Sep 19, 2022 at 09:24:01AM -0700, Ashutosh Dixit wrote:
> Register GT0_PERF_LIMIT_REASONS (0x1381a8) is available only for
> Gen11+. Therefore ensure perf_limit_reasons sysfs/debugfs files are created
> only for Gen11+. Otherwise on Gen < 5 accessing these files results in the
> following oops:
>
> <1> [88.829420] BUG: unable to handle page fault for address: c9bb81a8
> <1> [88.829438] #PF: supervisor read access in kernel mode
> <1> [88.829447] #PF: error_code(0x) - not-present page
>
> Bspec: 20008
> Bug: https://gitlab.freedesktop.org/drm/intel/-/issues/6863
> Fixes: fe5979665f64 ("drm/i915/debugfs: Add perf_limit_reasons in debugfs")
> Fixes: fa68bff7cf27 ("drm/i915/gt: Add sysfs throttle frequency interfaces")
> Signed-off-by: Ashutosh Dixit
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/gt/intel_gt.c| 4
> drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 10 +-
> drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 15 +++
> 3 files changed, 24 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index 5ddae95d4886..b367cfff48d5 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -233,6 +233,10 @@ static void gen6_clear_engine_error_register(struct
> intel_engine_cs *engine)
>
> i915_reg_t intel_gt_perf_limit_reasons_reg(struct intel_gt *gt)
> {
> + /* GT0_PERF_LIMIT_REASONS is available only for Gen11+ */
> + if (GRAPHICS_VER(gt->i915) < 11)
> + return INVALID_MMIO_REG;
> +
> return gt->type == GT_MEDIA ?
> MTL_MEDIA_PERF_LIMIT_REASONS : GT0_PERF_LIMIT_REASONS;
> }
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> index 68310881a793..10f680dbd7b6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
> @@ -682,6 +682,14 @@ static int perf_limit_reasons_clear(void *data, u64 val)
>
> return 0;
> }
> +
> +static bool perf_limit_reasons_eval(void *data)
> +{
> + struct intel_gt *gt = data;
> +
> + return i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt));
> +}
> +
> DEFINE_SIMPLE_ATTRIBUTE(perf_limit_reasons_fops, perf_limit_reasons_get,
> perf_limit_reasons_clear, "%llu\n");
>
> @@ -694,7 +702,7 @@ void intel_gt_pm_debugfs_register(struct intel_gt *gt,
> struct dentry *root)
> { "forcewake_user", &forcewake_user_fops, NULL},
> { "llc", &llc_fops, llc_eval },
> { "rps_boost", &rps_boost_fops, rps_eval },
> - { "perf_limit_reasons", &perf_limit_reasons_fops, NULL },
> + { "perf_limit_reasons", &perf_limit_reasons_fops,
> perf_limit_reasons_eval },
> };
>
> intel_gt_debugfs_register_files(root, files, ARRAY_SIZE(files), gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> index 54deae45d81f..904160952369 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c
> @@ -545,8 +545,7 @@ static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_ratl,
> RATL_MASK);
> static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_thermalert,
> VR_THERMALERT_MASK);
> static INTEL_GT_RPS_BOOL_ATTR_RO(throttle_reason_vr_tdc, VR_TDC_MASK);
>
> -static const struct attribute *freq_attrs[] = {
> - &dev_attr_punit_req_freq_mhz.attr,
> +static const struct attribute *throttle_reason_attrs[] = {
> &attr_throttle_reason_status.attr,
> &attr_throttle_reason_pl1.attr,
> &attr_throttle_reason_pl2.attr,
> @@ -791,12 +790,20 @@ void intel_gt_sysfs_pm_init(struct intel_gt *gt, struct
> kobject *kobj)
> if (!is_object_gt(kobj))
> return;
>
> - ret = sysfs_create_files(kobj, freq_attrs);
> + ret = sysfs_create_file(kobj, &dev_attr_punit_req_freq_mhz.attr);
> if (ret)
> drm_warn(>->i915->drm,
> - "failed to create gt%u throttle sysfs files (%pe)",
> + "failed to create gt%u punit_req_freq_mhz sysfs (%pe)",
>gt->info.id, ERR_PTR(ret));
>
> + if (i915_mmio_reg_valid(intel_gt_perf_limit_reasons_reg(gt))) {
> + ret = sysfs_create_files(kobj, throttle_reason_attrs);
> + if (ret)
> + drm_warn(>->i915->drm,
> + "failed to create gt%u throttle sysfs files
> (%pe)",
> + gt->info.id, ERR_PTR(ret));
> + }
> +
> if (HAS_MEDIA_RATIO_MODE(gt->i915) && intel_uc_uses_guc_slpc(>->uc)) {
> ret = sysfs_create_files(kobj, media_perf_power_attrs);
> if (ret)
> --
> 2.34.1
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dg2: introduce Wa_22015475538
== Series Details ==
Series: drm/i915/dg2: introduce Wa_22015475538
URL : https://patchwork.freedesktop.org/series/108795/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12161 -> Patchwork_108795v1
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/index.html
Participating hosts (44 -> 42)
--
Additional (1): fi-rkl-11600
Missing(3): fi-ctg-p8600 fi-icl-u2 fi-bdw-samus
Known issues
Here are the changes found in Patchwork_108795v1 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_huc_copy@huc-copy:
- fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html
* igt@gem_lmem_swapping@basic:
- fi-bdw-gvtdvm: NOTRUN -> [SKIP][2] ([fdo#109271]) +19 similar issues
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-bdw-gvtdvm/igt@gem_lmem_swapp...@basic.html
- fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html
* igt@gem_tiled_pread_basic:
- fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html
* igt@i915_pm_backlight@basic-brightness:
- fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3012])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html
* igt@i915_selftest@live@gt_heartbeat:
- fi-skl-6600u: [PASS][6] -> [DMESG-FAIL][7] ([i915#5334])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-skl-6600u/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_suspend@basic-s2idle-without-i915:
- fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][8] ([i915#4817])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html
* igt@i915_suspend@basic-s3-without-i915:
- fi-rkl-11600: NOTRUN -> [INCOMPLETE][9] ([i915#5982])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][10] ([fdo#109271] / [fdo#111827])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-edid-read:
- fi-rkl-11600: NOTRUN -> [SKIP][11] ([fdo#111827]) +7 similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_cursor_legacy@basic-busy-flip-before-cursor:
- fi-rkl-11600: NOTRUN -> [SKIP][12] ([i915#4103])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-rkl-11600: NOTRUN -> [SKIP][13] ([fdo#109285] / [i915#4098])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_psr@primary_page_flip:
- fi-rkl-11600: NOTRUN -> [SKIP][14] ([i915#1072]) +3 similar issues
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html
* igt@kms_setmode@basic-clone-single-crtc:
- fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#3555] / [i915#4098])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@kms_setm...@basic-clone-single-crtc.html
* igt@prime_vgem@basic-read:
- fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109295] / [i915#3291] /
[i915#3708]) +2 similar issues
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@prime_v...@basic-read.html
* igt@prime_vgem@basic-userptr:
- fi-rkl-11600: NOTRUN -> [SKIP][17] ([fdo#109295] / [i915#3301] /
[i915#3708])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-rkl-11600/igt@prime_v...@basic-userptr.html
* igt@runner@aborted:
- fi-bdw-5557u: NOTRUN -> [FAIL][18] ([i915#4312])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108795v1/fi-bdw-5557u/igt@run...@aborted.html
Possible fixes
* igt@fbdev@info:
- {fi-tgl-mst}: [SKIP][19] ([i915#2582]) -> [PASS][20] +1 similar
issue
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_
[Intel-gfx] [PATCH] drm/i915/dg2: introduce Wa_22015475538
Wa_22015475538 applies to all DG2 (and ATSM) skus. The workaround
implementation is identical to Wa_16011620976. LSC_CHICKEN_BIT_0_UDW is
a general render register instead of rcs so adding this move to the
proper wa init function.
bspec:54077
Signed-off-by: Matt Atwood
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 6d2003d598e6..c16e9e3f0d6c 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -2108,9 +2108,6 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
if (IS_DG2_GRAPHICS_STEP(i915, G11, STEP_A0, STEP_B0)) {
/* Wa_14013392000:dg2_g11 */
wa_masked_en(wal, GEN7_ROW_CHICKEN2,
GEN12_ENABLE_LARGE_GRF_MODE);
-
- /* Wa_16011620976:dg2_g11 */
- wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
}
if (IS_DG2_GRAPHICS_STEP(i915, G10, STEP_B0, STEP_FOREVER) ||
@@ -2780,6 +2777,14 @@ general_render_compute_wa_init(struct intel_engine_cs
*engine, struct i915_wa_li
wa_write_or(wal, VDBX_MOD_CTRL, FORCE_MISS_FTLB);
wa_write_or(wal, VEBX_MOD_CTRL, FORCE_MISS_FTLB);
}
+
+ if (IS_DG2(i915)) {
+ /*
+* Wa_16011620976:dg2_g11
+* Wa_22015475538:dg2
+*/
+ wa_write_or(wal, LSC_CHICKEN_BIT_0_UDW, DIS_CHAIN_2XSIMD8);
+ }
}
static void
--
2.37.3
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 06:57:46PM +0200, Andi Shyti wrote:
> Hi Aravind,
>
> > +static int get_mtl_gms_size(struct intel_uncore *uncore)
> > +{
> > + u16 ggc, gms;
> > +
> > + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
> > +
> > + /* check GGMS, should be fixed 0x3 (8MB) */
> > + if ((ggc & 0xc0) != 0xc0)
> > + return -EIO;
> > +
> > + /* return valid GMS value, -EIO if invalid */
> > + gms = ggc >> 8;
> > + switch (gms) {
> > + case 0x0 ... 0x10:
> > + return gms * 32;
> > + case 0x20:
> > + return 1024;
> > + case 0x30:
> > + return 1536;
> > + case 0x40:
> > + return 2048;
> > + case 0xf0 ... 0xfe:
>
> just a bit puzzled by the fact that case ranges are not standard
> and are supported only by GCC, unless, of course, I miss
> something. Do we still want to use them as they are widely used
> around the kernel?
i915 already has 17 other uses of this notation and the DRM subsystem in
general has about 50 today. So it's not super common, but I think it
should be okay to use. I believe clang supports this language extension
as well and the coding style doc doesn't say anything one way or the
other.
Matt
>
> Andi
>
> > + return (gms - 0xf0 + 1) * 4;
> > + default:
> > + return -EIO;
> > + }
> > +}
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
[Intel-gfx] PR for new GuC v70.5.1 and GuC/HuC with new names
The following changes since commit f09bebf31b0590bdc875d7236aa705279510cfd0: amdgpu: update yellow carp DMCUB firmware (2022-09-13 08:02:23 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_70.5.1_huc_nover for you to fetch changes up to 51fff4e69b4554dd3fee21e3c55a0f94937293e3: i915: Add versionless HuC files for current platforms (2022-09-16 08:52:30 -0700) John Harrison (2): i915: Add GuC v70.5.1 for DG1, DG2, TGL and ADL-P i915: Add versionless HuC files for current platforms WHENCE | 18 ++ i915/adlp_guc_70.bin | Bin 0 -> 297984 bytes i915/dg1_guc_70.bin | Bin 0 -> 272512 bytes i915/dg1_huc.bin | Bin 0 -> 589888 bytes i915/dg2_guc_70.bin | Bin 0 -> 369600 bytes i915/tgl_guc_70.bin | Bin 0 -> 285888 bytes i915/tgl_huc.bin | Bin 0 -> 589888 bytes 7 files changed, 18 insertions(+) create mode 100644 i915/adlp_guc_70.bin create mode 100644 i915/dg1_guc_70.bin create mode 100644 i915/dg1_huc.bin create mode 100644 i915/dg2_guc_70.bin create mode 100644 i915/tgl_guc_70.bin create mode 100644 i915/tgl_huc.bin
Re: [Intel-gfx] [PATCH v3 15/15] vfio: Add struct device to vfio_device
On Fri, 9 Sep 2022 18:22:47 +0800 Kevin Tian wrote: > From: Yi Liu > > and replace kref. With it a 'vfio-dev/vfioX' node is created under the > sysfs path of the parent, indicating the device is bound to a vfio > driver, e.g.: > > /sys/devices/pci\:6f/\:6f\:01.0/vfio-dev/vfio0 > > It is also a preparatory step toward adding cdev for supporting future > device-oriented uAPI. > > Add Documentation/ABI/testing/sysfs-devices-vfio-dev. > > Also take this chance to rename chardev 'vfio' to 'vfio-group' in > /proc/devices. What's the risk/reward here, is this just more aesthetically pleasing symmetry vs 'vfio-dev'? The char major number to name association in /proc/devices seems pretty obscure, but what due diligence have we done to make sure this doesn't break anyone? Thanks, Alex
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable Pipewriteback (rev8)
== Series Details == Series: Enable Pipewriteback (rev8) URL : https://patchwork.freedesktop.org/series/107440/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12160_full -> Patchwork_107440v8_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107440v8_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107440v8_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 9) -- Missing(1): shard-tglu Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107440v8_full: ### IGT changes ### Possible regressions * igt@kms_plane_scaling@plane-scaler-with-modifiers-unity-scaling@pipe-c-edp-1: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-tglb3/igt@kms_plane_scaling@plane-scaler-with-modifiers-unity-scal...@pipe-c-edp-1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/shard-tglb8/igt@kms_plane_scaling@plane-scaler-with-modifiers-unity-scal...@pipe-c-edp-1.html Warnings * igt@kms_writeback@writeback-check-output: - shard-tglb: [SKIP][3] ([i915#2437]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-tglb2/igt@kms_writeb...@writeback-check-output.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/shard-tglb5/igt@kms_writeb...@writeback-check-output.html * igt@kms_writeback@writeback-fb-id: - shard-tglb: [SKIP][5] ([i915#2437]) -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-tglb5/igt@kms_writeb...@writeback-fb-id.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/shard-tglb3/igt@kms_writeb...@writeback-fb-id.html Known issues Here are the changes found in Patchwork_107440v8_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-skl: ([PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25], [PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30]) -> ([PASS][31], [PASS][32], [PASS][33], [PASS][34], [FAIL][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [PASS][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50], [PASS][51], [PASS][52], [PASS][53], [PASS][54], [PASS][55]) ([i915#5032]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl10/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl10/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl10/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl10/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl1/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl1/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl1/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl2/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl2/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl2/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl4/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl4/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl4/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl5/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl5/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl5/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl6/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl6/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl7/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl7/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl7/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl9/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl9/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/shard-skl9/boot.html [31]: https://intel-gfx-ci.01.org/
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 01:31:49AM -0700, Lucas De Marchi wrote:
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
+ if (dsm->start == 0)
+ return true;
+ }
+
+ if (dsm->end <= dsm->start)
+ return true;
+
+ return false;
+}
+
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (is_dsm_invalid(i915, dsm))
return -EINVAL;
/*
@@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
* overlaps with the non-stolen system memory range, since lmem is local
* to the gpu.
*/
- if (HAS_LMEM(i915))
+ if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
comment above makes no sense when you add this. For this specific case
it's still system memory, reserved by the BIOS and that we access by
mapping the lmembar
return 0;
/*
@@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
- *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+ if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
+ /* the base is initialized to stolen top so subtract size to
get base */
+ *base -= *size;
that doesn't necessarily holds true. According to the spec the wopcm
base is 1MB aligned so even if it is "at the top", it may not mean it is at the
very very top that we can just subtract the size.
+ else
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
}
static int i915_gem_init_stolen(struct intel_memory_region *mem)
@@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
??
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
+ return (gms - 0xf0 + 1) * 4;
+
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 06:57:46PM +0200, Andi Shyti wrote:
Hi Aravind,
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
just a bit puzzled by the fact that case ranges are not standard
and are supported only by GCC, unless, of course, I miss
clang also supports it and can build the kernel (or a great portion of
it).
Lucas De Marchi
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/dgfx: Make failure to setup stolen non-fatal
On 9/16/22 10:36 AM, Lucas De Marchi wrote:
There is no reason to consider the setup of Data Stolen Memory fatal on
dgfx and non-fatal on integrated. Move the debug and error propagation
around so both have the same behavior: non-fatal. Before this change,
loading i915 on a system with TGL + DG2 would result in just TGL
succeeding the initialization (without stolen).
Now loading i915 on the same system with an injected failure in
i915_gem_init_stolen():
$ dmesg | grep stolen
i915 :00:02.0: [drm] Injected failure, disabling use of stolen
memory
i915 :00:02.0: [drm:init_stolen_smem [i915]] Skip stolen region:
failed to setup
i915 :03:00.0: [drm] Injected failure, disabling use of stolen
memory
i915 :03:00.0: [drm:init_stolen_lmem [i915]] Skip stolen region:
failed to setup
Both GPUs are still available:
$ sudo build/tools/lsgpu
card1Intel Dg2 (Gen12)
drm:/dev/dri/card1
└─renderD129
drm:/dev/dri/renderD129
card0Intel Tigerlake (Gen12)
drm:/dev/dri/card0
└─renderD128
drm:/dev/dri/renderD128
Signed-off-by: Lucas De Marchi
Reviewed-by: Wayne Boyer
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 6edf4e374f54..c5a4035c99cd 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -494,26 +494,26 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
drm_notice(&i915->drm,
"%s, disabling use of stolen memory\n",
"iGVT-g active");
- return 0;
+ return -ENOSPC;
}
if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
drm_notice(&i915->drm,
"%s, disabling use of stolen memory\n",
"DMAR active");
- return 0;
+ return -ENOSPC;
}
if (adjust_stolen(i915, &mem->region))
- return 0;
+ return -ENOSPC;
if (request_smem_stolen(i915, &mem->region))
- return 0;
+ return -ENOSPC;
i915->dsm = mem->region;
if (init_reserved_stolen(i915))
- return 0;
+ return -ENOSPC;
/* Exclude the reserved region from driver use */
mem->region.end = i915->dsm_reserved.start - 1;
@@ -527,7 +527,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
(u64)i915->stolen_usable_size >> 10);
if (i915->stolen_usable_size == 0)
- return 0;
+ return -ENOSPC;
/* Basic memrange allocator for stolen space. */
drm_mm_init(&i915->mm.stolen, 0, i915->stolen_usable_size);
@@ -765,11 +765,17 @@ i915_gem_object_create_stolen(struct drm_i915_private
*i915,
static int init_stolen_smem(struct intel_memory_region *mem)
{
+ int err;
+
/*
* Initialise stolen early so that we may reserve preallocated
* objects for the BIOS to KMS transition.
*/
- return i915_gem_init_stolen(mem);
+ err = i915_gem_init_stolen(mem);
+ if (err)
+ drm_dbg(&mem->i915->drm, "Skip stolen region: failed to
setup\n");
+
+ return 0;
}
static int release_stolen_smem(struct intel_memory_region *mem)
@@ -786,21 +792,25 @@ static const struct intel_memory_region_ops
i915_region_stolen_smem_ops = {
static int init_stolen_lmem(struct intel_memory_region *mem)
{
+ struct drm_i915_private *i915 = mem->i915;
int err;
if (GEM_WARN_ON(resource_size(&mem->region) == 0))
- return -ENODEV;
+ return 0;
err = i915_gem_init_stolen(mem);
- if (err)
- return err;
+ if (err) {
+ drm_dbg(&mem->i915->drm, "Skip stolen region: failed to
setup\n");
+ return 0;
+ }
- if (mem->io_size && !io_mapping_init_wc(&mem->iomap,
- mem->io_start,
- mem->io_size)) {
- err = -EIO;
+ if (mem->io_size &&
+ !io_mapping_init_wc(&mem->iomap, mem->io_start, mem->io_size))
goto err_cleanup;
- }
+
+ drm_dbg(&i915->drm, "Stolen Local memory IO start: %pa\n",
+ &mem->io_start);
+ drm_dbg(&i915->drm, "Stolen Local DSM base: %pa\n", &mem->region.start);
return 0;
@@ -874,16 +884,6 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
if (IS_ERR(mem))
return mem;
- /*
-* TODO: consider creating common helper to just print all the
-* interesting stuff from intel_memory_region,
Re: [Intel-gfx] [PATCH v3 06/15] vfio/mtty: Use the new device life cycle helpers
On Fri, 9 Sep 2022 18:22:38 +0800
Kevin Tian wrote:
> From: Yi Liu
>
> and manage available ports inside @init/@release.
>
> Signed-off-by: Yi Liu
> Signed-off-by: Kevin Tian
> Reviewed-by: Jason Gunthorpe
> ---
> samples/vfio-mdev/mtty.c | 67 +++-
> 1 file changed, 39 insertions(+), 28 deletions(-)
>
> diff --git a/samples/vfio-mdev/mtty.c b/samples/vfio-mdev/mtty.c
> index f42a59ed2e3f..41301d50b247 100644
> --- a/samples/vfio-mdev/mtty.c
> +++ b/samples/vfio-mdev/mtty.c
...
> +static int mtty_probe(struct mdev_device *mdev)
> +{
> + struct mdev_state *mdev_state;
> + int ret;
> +
> + mdev_state = vfio_alloc_device(mdev_state, vdev, &mdev->dev,
> +&mtty_dev_ops);
> + if (IS_ERR(mdev_state))
> + return PTR_ERR(mdev_state);
>
> ret = vfio_register_emulated_iommu_dev(&mdev_state->vdev);
> if (ret)
> - goto err_vconfig;
> + goto err_put_vdev;
> dev_set_drvdata(&mdev->dev, mdev_state);
> return 0;
>
> -err_vconfig:
> - kfree(mdev_state->vconfig);
> -err_state:
> - vfio_uninit_group_dev(&mdev_state->vdev);
> - kfree(mdev_state);
> -err_nr_ports:
> - atomic_add(nr_ports, &mdev_avail_ports);
> +err_put_vdev:
> + vfio_put_device(&mdev_state->vdev);
> return ret;
> }
>
> +static void mtty_release_dev(struct vfio_device *vdev)
> +{
> + struct mdev_state *mdev_state =
> + container_of(vdev, struct mdev_state, vdev);
> +
> + kfree(mdev_state->vconfig);
> + vfio_free_device(vdev);
> + atomic_add(mdev_state->nr_ports, &mdev_avail_ports);
I must be missing something, isn't this a use-after-free?
mdev_state is allocated via vfio_alloc_device(), where vdev is the
first entry in that structure, so this is equivalent to
kvfree(mdev_state). mbochs has the same issue. mdpy and vfio-ap
adjust global counters after vfio_free_device(), which I think muddies
the situation. Shouldn't we look suspiciously at any .release callback
where vfio_free_device() isn't the last thing executed? Thanks,
Alex
Re: [Intel-gfx] [PATCH v2 2/3] drm/i915: Split i915_gem_init_stolen()
On 9/16/22 10:36 AM, Lucas De Marchi wrote:
Add some helpers: adjust_stolen(), request_smem_stolen_() and
init_reserved_stolen() that are now called by i915_gem_init_stolen() to
initialize each part of the Data Stolen Memory region.
Main goal is to split the reserved part within the stolen, also known as
WOPCM, as its calculation changes often per platform and is a big source
of confusion when handling stolen memory.
Signed-off-by: Lucas De Marchi
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index 3665f9b035bb..6edf4e374f54 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,22 +77,26 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
-static int i915_adjust_stolen(struct drm_i915_private *i915,
- struct resource *dsm)
+static bool valid_stolen_size(struct resource *dsm)
+{
+ return dsm->start != 0 && dsm->end > dsm->start;
+}
+
+static int adjust_stolen(struct drm_i915_private *i915,
+struct resource *dsm)
{
struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
- struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (!valid_stolen_size(dsm))
return -EINVAL;
/*
+* Make sure we don't clobber the GTT if it's within stolen memory
+*
* TODO: We have yet too encounter the case where the GTT wasn't at the
nit: as long as you're updating this comment block, s/too/to/
Otherwise,
Reviewed-by: Wayne Boyer
* end of stolen. With that assumption we could simplify this.
*/
-
- /* Make sure we don't clobber the GTT if it's within stolen memory */
if (GRAPHICS_VER(i915) <= 4 &&
!IS_G33(i915) && !IS_PINEVIEW(i915) && !IS_G4X(i915)) {
struct resource stolen[2] = {*dsm, *dsm};
@@ -131,10 +135,20 @@ static int i915_adjust_stolen(struct drm_i915_private
*i915,
}
}
+ if (!valid_stolen_size(dsm))
+ return -EINVAL;
+
+ return 0;
+}
+
+static int request_smem_stolen(struct drm_i915_private *i915,
+ struct resource *dsm)
+{
+ struct resource *r;
+
/*
-* With stolen lmem, we don't need to check if the address range
-* overlaps with the non-stolen system memory range, since lmem is local
-* to the gpu.
+* With stolen lmem, we don't need to request system memory for the
+* address range since it's local to the gpu.
*/
if (HAS_LMEM(i915))
return 0;
@@ -392,39 +406,22 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
}
}
-static int i915_gem_init_stolen(struct intel_memory_region *mem)
+/*
+ * Initialize i915->dsm_reserved to contain the reserved space within the Data
+ * Stolen Memory. This is a range on the top of DSM that is reserved, not to
+ * be used by driver, so must be excluded from the region passed to the
+ * allocator later. In the spec this is also called as WOPCM.
+ *
+ * Our expectation is that the reserved space is at the top of the stolen
+ * region, as it has been the case for every platform, and *never* at the
+ * bottom, so the calculation here can be simplified.
+ */
+static int init_reserved_stolen(struct drm_i915_private *i915)
{
- struct drm_i915_private *i915 = mem->i915;
struct intel_uncore *uncore = &i915->uncore;
resource_size_t reserved_base, stolen_top;
- resource_size_t reserved_total, reserved_size;
-
- mutex_init(&i915->mm.stolen_lock);
-
- if (intel_vgpu_active(i915)) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "iGVT-g active");
- return 0;
- }
-
- if (i915_vtd_active(i915) && GRAPHICS_VER(i915) < 8) {
- drm_notice(&i915->drm,
- "%s, disabling use of stolen memory\n",
- "DMAR active");
- return 0;
- }
-
- if (resource_size(&mem->region) == 0)
- return 0;
-
- i915->dsm = mem->region;
-
- if (i915_adjust_stolen(i915, &i915->dsm))
- return 0;
-
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ resource_size_t reserved_size;
+ int ret = 0;
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -455,17 +452,16 @@ static int i915_gem_init_stolen(struct
intel_memory_region *mem)
&reserved_base, &reserved_size);
}
- /*
-* Our expectation is that the reserved space is at the top of the
-* stolen region and *never* at the bottom.
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add missing mask when reading GEN12_DSMBASE
On 9/16/22 10:36 AM, Lucas De Marchi wrote:
DSMBASE register is defined so BDSM bitfield contains the bits 63 to 20
of the base address of stolen. For the supported platforms bits 0-19 are
zero but that may not be true in future. Add the missing mask.
v2: Use REG_GENMASK64()
Acked-by: Aravind Iddamsetty
Reviewed-by: Caz Yokoyama
Signed-off-by: Lucas De Marchi
Reviewed-by: Wayne Boyer
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..3665f9b035bb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -814,7 +814,7 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
return ERR_PTR(-ENXIO);
/* Use DSM base address instead for stolen memory */
- dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE);
+ dsm_base = intel_uncore_read64(uncore, GEN12_DSMBASE) & GEN12_BDSM_MASK;
if (IS_DG1(uncore->i915)) {
lmem_size = pci_resource_len(pdev, GEN12_LMEM_BAR);
if (WARN_ON(lmem_size < dsm_base))
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1a9bd829fc7e..9584a50ed612 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7953,6 +7953,7 @@ enum skl_power_gate {
#define GEN12_GSMBASE _MMIO(0x108100)
#define GEN12_DSMBASE _MMIO(0x1080C0)
+#define GEN12_BDSM_MASK REG_GENMASK64(63, 20)
#define XEHP_CLOCK_GATE_DIS _MMIO(0x101014)
#define SGSI_SIDECLK_DISREG_BIT(17)
--
--
Wayne Boyer
Graphics Software Engineer
VTT-OSGC Platform Enablement
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
> -Original Message- > From: Ville Syrjälä > Sent: Tuesday, September 20, 2022 1:20 AM > To: Srivatsa, Anusha > Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma > ; Vivi, Rodrigo > Subject: Re: [PATCH 0/6] Introduce struct cdclk_step > > On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > > This is a prep series for the actual cdclk refactoring that will be > > sent following this. Idea is to have a struct - cdclk_step that holds > > the following: > > - cdclk action (squash, crawl or modeset) > > - cdclk frequency > > which gets populated in atomic check. Driver uses the populated values > > during atomic commit to do the suitable sequence of actions like > > programming squash ctl registers in case of squashing or PLL sequence > > incase of modeset and so on. > > > > This series just addresses the initial idea. The actual plumming in > > the atomic commit phase will be sent shortly. > > OK, people keep ignoring what I say so I just typed up the code quickly. This > to me seems like the most straightforward way to do what we need: > https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash > > Totally untested ofc, apart from me doing a quick scan through our cdclk > tables for the crawl+squahs platforms to make sure that this approach > should produce sane values. Ville, Why have a mid cdclk_config? Cant we use the new-cdclk-config for this purpose? Anusha > > > > Cc: Ville Syrjälä > > Cc: Uma Shankar > > Cc: Rodrigo Vivi > > > > Anusha Srivatsa (6): > > drm/i915/display Add dg2_prog_squash_ctl() helper > > drm/i915/display: add cdclk action struct to cdclk_config > > drm/i915/display: Embed the new struct steps for squashing > > drm/i915/display: Embed the new struct steps for crawling > > drm/i915/display: Embed the new struct steps for modeset > > drm/i915/display: Dump the new cdclk config values > > > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 > > +- drivers/gpu/drm/i915/display/intel_cdclk.h | > > 16 - > > 2 files changed, 74 insertions(+), 19 deletions(-) > > > > -- > > 2.25.1 > > -- > Ville Syrjälä > Intel
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk config values
> -Original Message-
> From: Jani Nikula
> Sent: Tuesday, September 20, 2022 12:27 AM
> To: Srivatsa, Anusha ; intel-
> g...@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk
> config values
>
> On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> > Add a helper function to get stringify values of the desired cdclk
> > action and dump it with rest of the cdclk config values
> >
> > Signed-off-by: Anusha Srivatsa
> > ---
> > drivers/gpu/drm/i915/display/intel_cdclk.c | 18 --
> > 1 file changed, 16 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > index bc627daade3e..12f5e4d23245 100644
> > --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> > +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> > @@ -1688,6 +1688,19 @@ static u32 cdclk_squash_waveform(struct
> > drm_i915_private *dev_priv,
> >
> > return 0x;
> > }
> > +static const char *cdclk_sequence_to_string(enum cdclk_sequence
> > +cdclk_sequence)
>
> For any enum foobar, this would be customarily called foobar_name(), i.e.
> cdclk_sequence_name(). (Though the enum should probably be renamed as
> mentioned earlier.)
Will do. The initial change and then change here.
> > +{
> > + switch (cdclk_sequence) {
> > + case CDCLK_SQUASH_ONLY:
> > + return "Squash only";
> > + case CDCLK_CRAWL_ONLY:
> > + return "Crawl only";
> > + case CDCLK_LEGACY:
> > + return "Legacy method";
> > + default:
> > + return "Not a valid cdclk sequence";
> > + }
> > +}
> >
> > static void dg2_prog_squash_ctl(struct drm_i915_private *i915, u16
> > waveform) { @@ -2083,10 +2096,11 @@ void
> > intel_cdclk_dump_config(struct drm_i915_private *i915,
> > const struct intel_cdclk_config *cdclk_config,
> > const char *context)
> > {
> > - drm_dbg_kms(&i915->drm, "%s %d kHz, VCO %d kHz, ref %d kHz,
> bypass %d kHz, voltage level %d\n",
> > + drm_dbg_kms(&i915->drm, "%s %d kHz, VCO %d kHz, ref %d kHz,
> bypass
> > +%d kHz, voltage level %d, %s action\n",
>
> "%s action" leads to:
>
> Squash only action
> Crawl only action
> Legacy method action
> Not a valid cdclk sequence action
>
> A bit odd perhaps. *shrug*
Yeah now I see it.
Will thin over what can be a better replacement.
Anusha
> BR,
> Jani.
>
> > context, cdclk_config->cdclk, cdclk_config->vco,
> > cdclk_config->ref, cdclk_config->bypass,
> > - cdclk_config->voltage_level);
> > + cdclk_config->voltage_level,
> > + cdclk_sequence_to_string(cdclk_config->steps->action));
> > }
> >
> > /**
>
> --
> Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper
On Tue, Sep 20, 2022 at 02:04:33PM -0300, Gustavo Sousa wrote:
Hi, Jani.
On Tue, Sep 20, 2022 at 10:19:53AM +0300, Jani Nikula wrote:
On Mon, 19 Sep 2022, Gustavo Sousa wrote:
> Make the code more readable, which will be more apparent as new
> platforms with different hotplug inversion needs are added.
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/i915_irq.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index de06f293e173..c53d21ae197f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct
drm_i915_private *dev_priv)
>spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
> +{
> + u32 invert_bits;
> +
> + if (HAS_PCH_DG1(dev_priv))
> + invert_bits = INVERT_DDIA_HPD |
> +INVERT_DDIB_HPD |
> +INVERT_DDIC_HPD |
> +INVERT_DDID_HPD;
Nitpick, the indentation will be off compared to automated indentation.
What do you mean by automated indentation?
> + else
> + return;
> +
> + intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
> +}
> +
> static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
> enum hpd_pin pin)
> {
> @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct
drm_i915_private *i915,
>
> static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> - u32 val;
> -
> - val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
> - val |= (INVERT_DDIA_HPD |
> - INVERT_DDIB_HPD |
> - INVERT_DDIC_HPD |
> - INVERT_DDID_HPD);
> - intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
> -
> + setup_hotplug_inversion(dev_priv);
Since you're already in a platform specific function here, seems a bit
odd to call a new generic function that needs to have another if ladder
platform check. What are we gaining here? The end result is
de-duplicating just one line of intel_uncore_rmw(). I'm not convinced.
It is true that the proposed refactor repeats a platform check, but the proposed
refactor has its benefits. As more platforms with hotplug inversion needs are
added (e.g. MTL), we will have a common place for the logic of hotplug
inversion. That arguably makes the code more readable and makes future refactors
easier when we need split a function that has become too complex due to platform
checks.
To make that last point clearer, I am quoting Lucas' (copied here as well)
comment (which was what convinced me) from a discussion regarding the advantage
of using such a helper:
that is what helpers are for, so you don't have to open code it in every
platform-fork of the function that needs it. See how the various
"Sequences to initialize display" are done in the driver... When we are
extending it to a future platform, if the change is small enough we just
add e few if/else in the same function. But it doesn't take too long for
those functions to become unreadable if there are several branches the
code path may take. So then we "fork" the function for a new platform,
but reuse the helpers doing the individual steps.
the missing information here is that there are changes in the pipeline
for platforms that have different bits to be inverted, or none at
all, with a different register to program. Adding the if/else in this
function seems unrelated churn.
Another possibility would be to just let the caller handle the if/else
decision, passing the bits (and possibly register) to invert. The noise
in xxx_hpd_irq_setup() function may be avoid by
#define INVERT_DII_HPD (INVERT_DDIA_HPD | INVERT_DDIB_HPD |
INVERT_DDIC_HPD | INVERT_DDID_HPD)
#define XXX_INVERT_DII_HPD (...)
Third possibility since the function is already very small is to just go
ahead and use another _setup() for the next platforms.
Lucas De Marchi
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not cleanup obj with NULL bo->resource
== Series Details == Series: drm/i915: Do not cleanup obj with NULL bo->resource URL : https://patchwork.freedesktop.org/series/108792/ State : success == Summary == CI Bug Log - changes from CI_DRM_12161 -> Patchwork_108792v1 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/index.html Participating hosts (44 -> 42) -- Additional (1): fi-rkl-11600 Missing(3): fi-ctg-p8600 fi-hsw-4770 fi-bdw-samus Known issues Here are the changes found in Patchwork_108792v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_huc_copy@huc-copy: - fi-rkl-11600: NOTRUN -> [SKIP][1] ([i915#2190]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@basic: - fi-bdw-gvtdvm: NOTRUN -> [SKIP][2] ([fdo#109271]) +19 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-bdw-gvtdvm/igt@gem_lmem_swapp...@basic.html - fi-rkl-11600: NOTRUN -> [SKIP][3] ([i915#4613]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@gem_lmem_swapp...@basic.html * igt@gem_tiled_pread_basic: - fi-rkl-11600: NOTRUN -> [SKIP][4] ([i915#3282]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@gem_tiled_pread_basic.html * igt@i915_pm_backlight@basic-brightness: - fi-rkl-11600: NOTRUN -> [SKIP][5] ([i915#3012]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@i915_pm_backli...@basic-brightness.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][6] -> [DMESG-FAIL][7] ([i915#62]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@late_gt_pm: - fi-cfl-8109u: [PASS][8] -> [DMESG-WARN][9] ([i915#5904]) +30 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-cfl-8109u/igt@i915_selftest@live@late_gt_pm.html * igt@i915_suspend@basic-s2idle-without-i915: - fi-cfl-8109u: [PASS][10] -> [DMESG-WARN][11] ([i915#5904] / [i915#62]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-cfl-8109u/igt@i915_susp...@basic-s2idle-without-i915.html - fi-bdw-gvtdvm: NOTRUN -> [INCOMPLETE][12] ([i915#4817]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-bdw-gvtdvm/igt@i915_susp...@basic-s2idle-without-i915.html * igt@i915_suspend@basic-s3-without-i915: - fi-rkl-11600: NOTRUN -> [INCOMPLETE][13] ([i915#5982]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@i915_susp...@basic-s3-without-i915.html * igt@kms_chamelium@hdmi-edid-read: - fi-rkl-11600: NOTRUN -> [SKIP][14] ([fdo#111827]) +7 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@kms_chamel...@hdmi-edid-read.html * igt@kms_cursor_legacy@basic-busy-flip-before-cursor: - fi-rkl-11600: NOTRUN -> [SKIP][15] ([i915#4103]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@kms_cursor_leg...@basic-busy-flip-before-cursor.html * igt@kms_force_connector_basic@force-load-detect: - fi-rkl-11600: NOTRUN -> [SKIP][16] ([fdo#109285] / [i915#4098]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_frontbuffer_tracking@basic: - fi-cfl-8109u: [PASS][17] -> [DMESG-WARN][18] ([i915#62]) +11 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12161/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-cfl-8109u/igt@kms_frontbuffer_track...@basic.html * igt@kms_psr@primary_page_flip: - fi-pnv-d510:NOTRUN -> [SKIP][19] ([fdo#109271]) +43 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-pnv-d510/igt@kms_psr@primary_page_flip.html - fi-rkl-11600: NOTRUN -> [SKIP][20] ([i915#1072]) +3 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108792v1/fi-rkl-11600/igt@kms_psr@primary_page_flip.html * igt@kms_setmode@basic-clone-single-crtc: - fi-rkl-11600: NOTRUN -> [SKIP][21] ([i915#3555] / [i9
Re: [Intel-gfx] [PATCH] drm/i915: Do not cleanup obj with NULL bo->resource
On 20/09/2022 18:06, Nirmoy Das wrote:
For delayed BO release i915_ttm_delete_mem_notify()
gets called twice, once with proper bo->resource and
another time with NULL. We shouldn't do anything for
the 2nd time as we already cleanedup the obj once.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850
Signed-off-by: Nirmoy Das
Reviewed-by: Matthew Auld
Christian, as per above it looks like ttm calls into the
delete_mem_notify() hook twice if the object ends up on the delayed
destroy list, is that expected/normal?
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0544b0a4a43a..e3fc38dd5db0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -511,7 +511,7 @@ static void i915_ttm_delete_mem_notify(struct
ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
intel_wakeref_t wakeref = 0;
- if (likely(obj)) {
+ if (bo->resource && likely(obj)) {
/* ttm_bo_release() already has dma_resv_lock */
if (i915_ttm_cpu_maps_iomem(bo->resource))
wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
[Intel-gfx] [PATCH] drm/i915: Do not cleanup obj with NULL bo->resource
For delayed BO release i915_ttm_delete_mem_notify()
gets called twice, once with proper bo->resource and
another time with NULL. We shouldn't do anything for
the 2nd time as we already cleanedup the obj once.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0544b0a4a43a..e3fc38dd5db0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -511,7 +511,7 @@ static void i915_ttm_delete_mem_notify(struct
ttm_buffer_object *bo)
struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
intel_wakeref_t wakeref = 0;
- if (likely(obj)) {
+ if (bo->resource && likely(obj)) {
/* ttm_bo_release() already has dma_resv_lock */
if (i915_ttm_cpu_maps_iomem(bo->resource))
wakeref =
intel_runtime_pm_get(&to_i915(obj->base.dev)->runtime_pm);
--
2.37.3
Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper
Hi, Jani.
On Tue, Sep 20, 2022 at 10:19:53AM +0300, Jani Nikula wrote:
> On Mon, 19 Sep 2022, Gustavo Sousa wrote:
> > Make the code more readable, which will be more apparent as new
> > platforms with different hotplug inversion needs are added.
> >
> > Signed-off-by: Gustavo Sousa
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 25 -
> > 1 file changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index de06f293e173..c53d21ae197f 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct
> > drm_i915_private *dev_priv)
> > spin_unlock_irq(&dev_priv->irq_lock);
> > }
> >
> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
> > +{
> > + u32 invert_bits;
> > +
> > + if (HAS_PCH_DG1(dev_priv))
> > + invert_bits = INVERT_DDIA_HPD |
> > + INVERT_DDIB_HPD |
> > + INVERT_DDIC_HPD |
> > + INVERT_DDID_HPD;
>
> Nitpick, the indentation will be off compared to automated indentation.
What do you mean by automated indentation?
>
> > + else
> > + return;
> > +
> > + intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
> > +}
> > +
> > static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
> >enum hpd_pin pin)
> > {
> > @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct
> > drm_i915_private *i915,
> >
> > static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> > {
> > - u32 val;
> > -
> > - val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
> > - val |= (INVERT_DDIA_HPD |
> > - INVERT_DDIB_HPD |
> > - INVERT_DDIC_HPD |
> > - INVERT_DDID_HPD);
> > - intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
> > -
> > + setup_hotplug_inversion(dev_priv);
>
> Since you're already in a platform specific function here, seems a bit
> odd to call a new generic function that needs to have another if ladder
> platform check. What are we gaining here? The end result is
> de-duplicating just one line of intel_uncore_rmw(). I'm not convinced.
It is true that the proposed refactor repeats a platform check, but the proposed
refactor has its benefits. As more platforms with hotplug inversion needs are
added (e.g. MTL), we will have a common place for the logic of hotplug
inversion. That arguably makes the code more readable and makes future refactors
easier when we need split a function that has become too complex due to platform
checks.
To make that last point clearer, I am quoting Lucas' (copied here as well)
comment (which was what convinced me) from a discussion regarding the advantage
of using such a helper:
that is what helpers are for, so you don't have to open code it in every
platform-fork of the function that needs it. See how the various
"Sequences to initialize display" are done in the driver... When we are
extending it to a future platform, if the change is small enough we just
add e few if/else in the same function. But it doesn't take too long for
those functions to become unreadable if there are several branches the
code path may take. So then we "fork" the function for a new platform,
but reuse the helpers doing the individual steps.
--
Gustavo Sousa
Re: [Intel-gfx] [PATCH] drm/i915: move i915_coherent_map_type() to i915_gem_pages.c and un-inline
On 15/09/2022 08:49, Tvrtko Ursulin wrote:
On 14/09/2022 17:35, Jani Nikula wrote:
The inline function has no place in i915_drv.h. Move it away, un-inline,
and untangle some header dependencies while at it.
Cc: Matthew Auld
Cc: Tvrtko Ursulin
Signed-off-by: Jani Nikula
---
I don't know where this belongs, I just know it doesn't belong in
i915_drv.h.
Don't know either.. it straddles the line between objects and platforms
by definition. Maybe Matt will have an idea or opinion.
gem_pages.c seems like a good enough spot to me.
Acked-by: Matthew Auld
Regards,
Tvrtko
I first tried moving it as inline, but it's really annoying as an inline
because it needs to pull in i915_drv.h, i915_gem_lmem.h, and
i915_gem_object_types.h.
---
drivers/gpu/drm/i915/display/intel_dpt.c | 1 +
drivers/gpu/drm/i915/gem/i915_gem_object.h | 4
drivers/gpu/drm/i915/gem/i915_gem_pages.c | 12
drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c | 1 +
drivers/gpu/drm/i915/gt/intel_gsc.c | 1 +
drivers/gpu/drm/i915/gt/intel_migrate.c | 1 +
drivers/gpu/drm/i915/gt/selftest_migrate.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 1 +
drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c | 1 +
drivers/gpu/drm/i915/i915_drv.h | 13 -
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 1 +
11 files changed, 24 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c
b/drivers/gpu/drm/i915/display/intel_dpt.c
index ac587647e1f5..ad1a37b515fb 100644
--- a/drivers/gpu/drm/i915/display/intel_dpt.c
+++ b/drivers/gpu/drm/i915/display/intel_dpt.c
@@ -5,6 +5,7 @@
#include "gem/i915_gem_domain.h"
#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_lmem.h"
#include "gt/gen8_ppgtt.h"
#include "i915_drv.h"
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.h
b/drivers/gpu/drm/i915/gem/i915_gem_object.h
index 7317d4102955..a3b7551a57fc 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.h
@@ -482,6 +482,10 @@ void *__must_check i915_gem_object_pin_map(struct
drm_i915_gem_object *obj,
void *__must_check i915_gem_object_pin_map_unlocked(struct
drm_i915_gem_object *obj,
enum i915_map_type type);
+enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,
+ struct drm_i915_gem_object *obj,
+ bool always_coherent);
+
void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
unsigned long offset,
unsigned long size);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 4df50b049cea..16f845663ff2 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -466,6 +466,18 @@ void *i915_gem_object_pin_map_unlocked(struct
drm_i915_gem_object *obj,
return ret;
}
+enum i915_map_type i915_coherent_map_type(struct drm_i915_private *i915,
+ struct drm_i915_gem_object *obj,
+ bool always_coherent)
+{
+ if (i915_gem_object_is_lmem(obj))
+ return I915_MAP_WC;
+ if (HAS_LLC(i915) || always_coherent)
+ return I915_MAP_WB;
+ else
+ return I915_MAP_WC;
+}
+
void __i915_gem_object_flush_map(struct drm_i915_gem_object *obj,
unsigned long offset,
unsigned long size)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
index b73c91aa5450..1cae24349a96 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -8,6 +8,7 @@
#include
#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "gem/i915_gem_ttm.h"
#include "gem/i915_gem_ttm_move.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gsc.c
b/drivers/gpu/drm/i915/gt/intel_gsc.c
index 7af6db3194dd..d56f75b605d8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gsc.c
+++ b/drivers/gpu/drm/i915/gt/intel_gsc.c
@@ -7,6 +7,7 @@
#include
#include "i915_drv.h"
#include "i915_reg.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_region.h"
#include "gt/intel_gsc.h"
#include "gt/intel_gt.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index aaaf1906026c..b405a04135ca 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -10,6 +10,7 @@
#include "intel_gtt.h"
#include "intel_migrate.h"
#include "intel_ring.h"
+#include "gem/i915_gem_lmem.h"
struct insert_pte_data {
u64 offset;
diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c
b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index 2b0c8749..0dc5309c90a
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
Hi Aravind,
> +static int get_mtl_gms_size(struct intel_uncore *uncore)
> +{
> + u16 ggc, gms;
> +
> + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
> +
> + /* check GGMS, should be fixed 0x3 (8MB) */
> + if ((ggc & 0xc0) != 0xc0)
> + return -EIO;
> +
> + /* return valid GMS value, -EIO if invalid */
> + gms = ggc >> 8;
> + switch (gms) {
> + case 0x0 ... 0x10:
> + return gms * 32;
> + case 0x20:
> + return 1024;
> + case 0x30:
> + return 1536;
> + case 0x40:
> + return 2048;
> + case 0xf0 ... 0xfe:
just a bit puzzled by the fact that case ranges are not standard
and are supported only by GCC, unless, of course, I miss
something. Do we still want to use them as they are widely used
around the kernel?
Andi
> + return (gms - 0xf0 + 1) * 4;
> + default:
> + return -EIO;
> + }
> +}
Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper
On Tue, Sep 20, 2022 at 12:01:36AM -0700, Lucas De Marchi wrote:
> On Mon, Sep 19, 2022 at 11:56:59AM -0300, Gustavo Sousa wrote:
> > Make the code more readable, which will be more apparent as new
> > platforms with different hotplug inversion needs are added.
> >
> > Signed-off-by: Gustavo Sousa
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 25 -
> > 1 file changed, 16 insertions(+), 9 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index de06f293e173..c53d21ae197f 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct
> > drm_i915_private *dev_priv)
> > spin_unlock_irq(&dev_priv->irq_lock);
> > }
> >
> > +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
>
> new users of drm_i915_private should use "i915" as variable name rather
> than dev_priv.
Thanks. I will update this.
Is there any documentation where we can find information like this?
>
> other than that, Reviewed-by: Lucas De Marchi
>
>
> Lucas De Marchi
>
> > +{
> > + u32 invert_bits;
> > +
> > + if (HAS_PCH_DG1(dev_priv))
> > + invert_bits = INVERT_DDIA_HPD |
> > + INVERT_DDIB_HPD |
> > + INVERT_DDIC_HPD |
> > + INVERT_DDID_HPD;
> > + else
> > + return;
> > +
> > + intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
> > +}
> > +
> > static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
> >enum hpd_pin pin)
> > {
> > @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct
> > drm_i915_private *i915,
> >
> > static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> > {
> > - u32 val;
> > -
> > - val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
> > - val |= (INVERT_DDIA_HPD |
> > - INVERT_DDIB_HPD |
> > - INVERT_DDIC_HPD |
> > - INVERT_DDID_HPD);
> > - intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
> > -
> > + setup_hotplug_inversion(dev_priv);
> > icp_hpd_irq_setup(dev_priv);
> > }
> >
> > --
> > 2.37.3
> >
[Intel-gfx] ✓ Fi.CI.BAT: success for Enable Pipewriteback (rev8)
== Series Details ==
Series: Enable Pipewriteback (rev8)
URL : https://patchwork.freedesktop.org/series/107440/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_12160 -> Patchwork_107440v8
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/index.html
Participating hosts (48 -> 35)
--
Missing(13): fi-cml-u2 bat-dg1-5 fi-hsw-4200u bat-dg2-8 bat-adlm-1
bat-dg2-9 bat-adlp-6 fi-ctg-p8600 bat-adln-1 fi-kbl-x1275 bat-rpls-1
fi-bdw-samus bat-jsl-1
Known issues
Here are the changes found in Patchwork_107440v8 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-pnv-d510:[PASS][1] -> [INCOMPLETE][2] ([i915#6863])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
* igt@i915_selftest@live@late_gt_pm:
- fi-glk-j4005: [PASS][3] -> [DMESG-FAIL][4] ([i915#6217])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][6] ([i915#2403] / [i915#4312])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-pnv-d510/igt@run...@aborted.html
- fi-glk-j4005: NOTRUN -> [FAIL][7] ([i915#4312] / [i915#5257] /
[i915#6884])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-glk-j4005/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][8] ([i915#4785]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@runner@aborted:
- fi-kbl-guc: [FAIL][10] ([i915#6219]) -> [FAIL][11] ([i915#6219] /
[i915#6884])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-guc/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-8809g: [FAIL][12] ([i915#6219]) -> [FAIL][13] ([i915#6219] /
[i915#6884])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-8809g/igt@run...@aborted.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-8809g/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][14] ([i915#6219]) -> [FAIL][15] ([i915#6219] /
[i915#6884])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-soraka/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-soraka/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issues/5257
[i915#6217]: https://gitlab.freedesktop.org/drm/intel/issues/6217
[i915#6219]: https://gitlab.freedesktop.org/drm/intel/issues/6219
[i915#6863]: https://gitlab.freedesktop.org/drm/intel/issues/6863
[i915#6884]: https://gitlab.freedesktop.org/drm/intel/issues/6884
[i915#6886]: https://gitlab.freedesktop.org/drm/intel/issues/6886
Build changes
-
* Linux: CI_DRM_12160 -> Patchwork_107440v8
CI-20190529: 20190529
CI_DRM_12160: 33a5599358a6f7bc7bff21369c758303639b5bab @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6658: c27dcb9e0baca05abce8527c245b513f7a8f1059 @
https://gitlab.freedesktop.org/drm/igt-gpu-tools.git
Patchwork_107440v8: 33a5599358a6f7bc7bff21369c758303639b5bab @
git://anongit.freedesktop.org/gfx-ci/linux
### Linux commits
5b8505f71d82 drm/i915: Enabling WD Transcoder
65873bc1d616 drm/i915 : Changing intel_connector iterators
a43d1e0e0e7d drm/i915: Defin
[Intel-gfx] ✗ Fi.CI.BAT: failure for Enable Pipewriteback (rev8)
== Series Details ==
Series: Enable Pipewriteback (rev8)
URL : https://patchwork.freedesktop.org/series/107440/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12160 -> Patchwork_107440v8
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_107440v8 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_107440v8, 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_107440v8/index.html
Participating hosts (48 -> 35)
--
Missing(13): fi-cml-u2 bat-dg1-5 fi-hsw-4200u bat-dg2-8 bat-adlm-1
bat-dg2-9 bat-adlp-6 fi-ctg-p8600 bat-adln-1 fi-kbl-x1275 bat-rpls-1
fi-bdw-samus bat-jsl-1
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_107440v8:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live@late_gt_pm:
- fi-glk-j4005: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-glk-j4005/igt@i915_selftest@live@late_gt_pm.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_module_load@load:
- {fi-tgl-mst}: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-tgl-mst/igt@i915_module_l...@load.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-tgl-mst/igt@i915_module_l...@load.html
Known issues
Here are the changes found in Patchwork_107440v8 that come from known issues:
### IGT changes ###
Issues hit
* igt@debugfs_test@read_all_entries:
- fi-pnv-d510:[PASS][5] -> [INCOMPLETE][6] ([i915#6863])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-pnv-d510/igt@debugfs_test@read_all_entries.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][7] ([fdo#109271] / [fdo#111827])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@runner@aborted:
- fi-pnv-d510:NOTRUN -> [FAIL][8] ([i915#2403] / [i915#4312])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-pnv-d510/igt@run...@aborted.html
- fi-glk-j4005: NOTRUN -> [FAIL][9] ([i915#4312] / [i915#5257] /
[i915#6884])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-glk-j4005/igt@run...@aborted.html
Possible fixes
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][10] ([i915#4785]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
Warnings
* igt@runner@aborted:
- fi-kbl-guc: [FAIL][12] ([i915#6219]) -> [FAIL][13] ([i915#6219] /
[i915#6884])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-guc/igt@run...@aborted.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-guc/igt@run...@aborted.html
- fi-kbl-8809g: [FAIL][14] ([i915#6219]) -> [FAIL][15] ([i915#6219] /
[i915#6884])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-8809g/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-8809g/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][16] ([i915#6219]) -> [FAIL][17] ([i915#6219] /
[i915#6884])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12160/fi-kbl-soraka/igt@run...@aborted.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v8/fi-kbl-soraka/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1982]: https://gitlab.freedesktop.org/drm/intel/issues/1982
[i915#2403]: https://gitlab.freedesktop.org/drm/intel/issues/2403
[i915#4312]: https://gitlab.freedesktop.org/drm/intel/issues/4312
[i915#4785]: https://gitlab.freedesktop.org/drm/intel/issues/4785
[i915#5257]: https://gitlab.freedesktop.org/drm/intel/issue
Re: [Intel-gfx] [PATCH 1/1] drm/i915/guc: Delay disabling guc_id scheduling for better hysteresis
On 16/09/2022 16:36, Ceraolo Spurio, Daniele wrote: On 9/16/2022 1:58 AM, Tvrtko Ursulin wrote: On 16/09/2022 08:53, Teres Alexis, Alan Previn wrote: [snip] + /* + * If the context gets closed while the execbuf is ongoing, the context + * close code will race with the below code to cancel the delayed work. + * If the context close wins the race and cancels the work, it will + * immediately call the sched disable (see guc_context_close), so there + * is a chance we can get past this check while the sched_disable code + * is being executed. To make sure that code completes before we check + * the status further down, we wait for the close process to complete. + */ + if (cancel_delayed_work_sync(&ce->guc_state.sched_disable_delay)) + intel_context_sched_disable_unpin(ce); + else if (intel_context_is_closed(ce)) + wait_for(context_close_done(ce), 1); Comment makes it sounds important to handle the race, althought it doesn't really explain the consequences. But most importantly, what if close doesn't complete in 1ms? will add the consequence (i believe the consequence is that we could prematurely read context flags bit indicating its gucid is still registered and after skipping re-registration, find that context gets closed and guc-id freed). Yes the 1 second is arbitrary and unnervingly short. Just spent sometime trying to One millisecond even. :) Normally 1ms is not a slow time for this. We can only hit the wait if the context_close call has already called the cancel_delayed_work, so the only thing left to do in that function is to send the H2G, which is relatively fast. However, I've just realized that if the H2G buffer is full the H2G will stall, so in that case it can take longer (maximum stall time before a hang is declared is 1.5s). What would be the consequence of prematurely reading the still registered context flag? Execbuf fails? GuC hangs? Kernel crashes? Something else? i915 thinks that a request pending with the GuC, while GuC thinks we disabled it (because the completion of the delayed_disable happens after the new request has been submitted). The heartbeat will still go through, so no reset will be triggered, the request is just lost. A new request submission on the same context should be able to recover it, but we didn't test that. And why cant' this race with context close happen at any other point than this particular spot in guc_request_alloc? Immediately after the added checks? After atomic_add_unless? The race is tied to the canceling of the delayed work. context_close only does something if it cancels the delayed work, so if the cancel_delayed_work_sync here does the cancelling then context_close is a no-op. It's a bit involved* to follow so I'll give up and declare a "whatever" if that's okay with you. *) intel_context_close set_bit(CONTEXT_CLOSED_BIT, &ce->flags) ->guc_context_close if (test_bit(CONTEXT_GUC_INIT, &ce->flags) && cancel_delayed_work(&ce->guc_state.sched_disable_delay)) __delay_sched_disable(&ce->guc_state.sched_disable_delay.work); ((which is: spin_lock_irqsave(&ce->guc_state.lock, flags); ..stuff.. unlock )) spin_lock_irqsave(&ce->guc_state.lock, flags); set_context_close_done(ce); spin_unlock_irqrestore(&ce->guc_state.lock, flags); Takes and releases the same lock two times so I have no idea why twice, and less so whether it is safe and race free. Regards, Tvrtko
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Enable Pipewriteback (rev8)
== Series Details == Series: Enable Pipewriteback (rev8) URL : https://patchwork.freedesktop.org/series/107440/ 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.CHECKPATCH: warning for Enable Pipewriteback (rev8)
== Series Details ==
Series: Enable Pipewriteback (rev8)
URL : https://patchwork.freedesktop.org/series/107440/
State : warning
== Summary ==
Error: dim checkpatch failed
ad3709400df3 drm/i915: Define WD trancoder for i915
eace4fd2c2e8 drm/i915 : Changing intel_connector iterators
-:76: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'x' - possible side-effects?
#76: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1507:
+#define to_intel_connector(x) (((x->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)) ? \
+ NULL : container_of(x, struct intel_connector,
base))
-:76: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'x' may be better as '(x)' to
avoid precedence issues
#76: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:1507:
+#define to_intel_connector(x) (((x->connector_type ==
DRM_MODE_CONNECTOR_WRITEBACK)) ? \
+ NULL : container_of(x, struct intel_connector,
base))
-:104: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#104: FILE: drivers/gpu/drm/i915/display/intel_display_types.h:2093:
+
+ }
total: 0 errors, 0 warnings, 3 checks, 104 lines checked
323af4b42ef5 drm/i915: Enabling WD Transcoder
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'
-:559: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does
MAINTAINERS need updating?
#559:
new file mode 100644
-:597: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!job"
#597: FILE: drivers/gpu/drm/i915/display/intel_wd.c:34:
+ if (job == NULL) {
-:634: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#634: FILE: drivers/gpu/drm/i915/display/intel_wd.c:71:
+ DRM_ERROR("unsupported pixel format %x!\n",
+ pixel_format);
-:712: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#712: FILE: drivers/gpu/drm/i915/display/intel_wd.c:149:
+ intel_de_write(i915, WD_STREAMCAP_CTL(intel_wd->trans),
+ *tmp);
-:735: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#735: FILE: drivers/gpu/drm/i915/display/intel_wd.c:172:
+ memcpy(pipe_config, intel_crtc->config,
+ sizeof(*pipe_config));
-:786: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#786: FILE: drivers/gpu/drm/i915/display/intel_wd.c:223:
+ wakeref = intel_display_power_get_if_enabled(dev_priv,
+ encoder->power_domain);
-:827: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#827: FILE: drivers/gpu/drm/i915/display/intel_wd.c:264:
+ drm_dbg_kms(&i915->drm, "Invalid framebuffer size %ux%u\n",
+ fb->width, fb->height);
-:834: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#834: FILE: drivers/gpu/drm/i915/display/intel_wd.c:271:
+ drm_dbg_kms(&i915->drm, "Unsupported framebuffer format %08x\n",
+ fb->format->format);
-:875: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#875: FILE: drivers/gpu/drm/i915/display/intel_wd.c:312:
+static bool intel_fastset_dis(struct intel_encoder *encoder,
+ struct intel_crtc_state *pipe_config)
-:929: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#929: FILE: drivers/gpu/drm/i915/display/intel_wd.c:366:
+ drm_encoder_helper_add(drm_enc,
+ &wd_encoder_helper_funcs);
-:944: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#944: FILE: drivers/gpu/drm/i915/display/intel_wd.c:381:
+ err = drm_writeback_connector_init_with_encoder(&i915->drm,
+ wb_conn, drm_enc, &wb_connector_funcs,
-:962: WARNING:RETURN_VOID: void function return statements are not generally
useful
#962: FILE: drivers/gpu/drm/i915/display/intel_wd.c:399:
+ return;
+}
-:1008: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1008: FILE: drivers/gpu/drm/i915/display/intel_wd.c:445:
+ intel_de_write(dev_priv, WD_SURF(intel_wd->trans),
+ i915_ggtt_offset(intel_wd->vma));
-:1019: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1019: FILE: drivers/gpu/drm/i915/display/intel_wd.c:456:
+ tmp = intel_de_read(dev_priv,
+ WD_STREAMCAP_CTL(intel_wd->trans));
-:1108: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis
#1108: FILE: drivers/gpu/drm/i915/display/intel_wd.c:545:
+ if (intel_de_wait_for_set(dev_priv, PIPECONF(intel_wd->trans),
+ WD_TRANS_ACTIVE, 10))
-:1130: CHECK:PARENTHESIS_ALIGNM
Re: [Intel-gfx] [PATCH v5 00/21] Move all drivers to a common dma-buf locking convention
Hi Dmitry, On Wed, 14 Sept 2022 at 00:58, Dmitry Osipenko wrote: > > Hello, > > This series moves all drivers to a dynamic dma-buf locking specification. > From now on all dma-buf importers are made responsible for holding > dma-buf's reservation lock around all operations performed over dma-bufs > in accordance to the locking specification. This allows us to utilize > reservation lock more broadly around kernel without fearing of a potential > deadlocks. Thank you for the excellent work on this series - apart from a minor nit in patch 15, please feel free to add my: Acked-by: Sumit Semwal for the relevant dma-buf patches (1, 2, 15-19, 21). Best regards, Sumit. > > This patchset passes all i915 selftests. It was also tested using VirtIO, > Panfrost, Lima, Tegra, udmabuf, AMDGPU and Nouveau drivers. I tested cases > of display+GPU, display+V4L and GPU+V4L dma-buf sharing (where appropriate), > which covers majority of kernel drivers since rest of the drivers share > same or similar code paths. > > Changelog: > > v5: - Added acks and r-bs that were given to v4. > > - Changed i915 preparation patch like was suggested by Michael Ruhl. > The scope of reservation locking is smaller now. > > v4: - Added dma_buf_mmap() to the "locking convention" documentation, > which was missed by accident in v3. > > - Added acks from Christian König, Tomasz Figa and Hans Verkuil that > they gave to couple v3 patches. > > - Dropped the "_unlocked" postfix from function names that don't have > the locked variant, as was requested by Christian König. > > - Factored out the per-driver preparations into separate patches > to ease reviewing of the changes, which is now doable without the > global dma-buf functions renaming. > > - Factored out the dynamic locking convention enforcements into separate > patches which add the final dma_resv_assert_held(dmabuf->resv) to the > dma-buf API functions. > > v3: - Factored out dma_buf_mmap_unlocked() and attachment functions > into aseparate patches, like was suggested by Christian König. > > - Corrected and factored out dma-buf locking documentation into > a separate patch, like was suggested by Christian König. > > - Intel driver dropped the reservation locking fews days ago from > its BO-release code path, but we need that locking for the imported > GEMs because in the end that code path unmaps the imported GEM. > So I added back the locking needed by the imported GEMs, updating > the "dma-buf attachment locking specification" patch appropriately. > > - Tested Nouveau+Intel dma-buf import/export combo. > > - Tested udmabuf import to i915/Nouveau/AMDGPU. > > - Fixed few places in Etnaviv, Panfrost and Lima drivers that I missed > to switch to locked dma-buf vmapping in the drm/gem: Take reservation > lock for vmap/vunmap operations" patch. In a result invalidated the > Christian's r-b that he gave to v2. > > - Added locked dma-buf vmap/vunmap functions that are needed for fixing > vmappping of Etnaviv, Panfrost and Lima drivers mentioned above. > I actually had this change stashed for the drm-shmem shrinker patchset, > but then realized that it's already needed by the dma-buf patches. > Also improved my tests to better cover these code paths. > > v2: - Changed locking specification to avoid problems with a cross-driver > ww locking, like was suggested by Christian König. Now the attach/detach > callbacks are invoked without the held lock and exporter should take the > lock. > > - Added "locking convention" documentation that explains which dma-buf > functions and callbacks are locked/unlocked for importers and exporters, > which was requested by Christian König. > > - Added ack from Tomasz Figa to the V4L patches that he gave to v1. > > Dmitry Osipenko (21): > dma-buf: Add unlocked variant of vmapping functions > dma-buf: Add unlocked variant of attachment-mapping functions > drm/gem: Take reservation lock for vmap/vunmap operations > drm/prime: Prepare to dynamic dma-buf locking specification > drm/armada: Prepare to dynamic dma-buf locking specification > drm/i915: Prepare to dynamic dma-buf locking specification > drm/omapdrm: Prepare to dynamic dma-buf locking specification > drm/tegra: Prepare to dynamic dma-buf locking specification > drm/etnaviv: Prepare to dynamic dma-buf locking specification > RDMA/umem: Prepare to dynamic dma-buf locking specification > misc: fastrpc: Prepare to dynamic dma-buf locking specification > xen/gntdev: Prepare to dynamic dma-buf locking specification > media: videobuf2: Prepare to dynamic dma-buf locking specification > media: tegra-vde: Prepare to dynamic dma-buf locking specification > dma-buf: Move dma_buf_vmap() to dynamic locking specification > dma-buf: Move dma_buf_attach() to dynamic locking specificatio
Re: [Intel-gfx] [PATCH v5 15/21] dma-buf: Move dma_buf_vmap() to dynamic locking specification
Hi Dmitry, Thanks very much for the series. On Wed, 14 Sept 2022 at 00:59, Dmitry Osipenko wrote: > > Move dma_buf_vmap/vunmap_unlocked() functions to the dynamic locking > specification by asserting that the reservation lock is held. Thanks for the patch; just a minor nit - I think you mean dma_buf_vmap / vunmap() here, and not _unlocked? Best, Sumit. > > Acked-by: Christian König > Signed-off-by: Dmitry Osipenko > --- > drivers/dma-buf/dma-buf.c | 4 > 1 file changed, 4 insertions(+) > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 50db7571dc4b..80fd6ccc88c6 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -1450,6 +1450,8 @@ int dma_buf_vmap(struct dma_buf *dmabuf, struct > iosys_map *map) > if (WARN_ON(!dmabuf)) > return -EINVAL; > > + dma_resv_assert_held(dmabuf->resv); > + > if (!dmabuf->ops->vmap) > return -EINVAL; > > @@ -1510,6 +1512,8 @@ void dma_buf_vunmap(struct dma_buf *dmabuf, struct > iosys_map *map) > if (WARN_ON(!dmabuf)) > return; > > + dma_resv_assert_held(dmabuf->resv); > + > BUG_ON(iosys_map_is_null(&dmabuf->vmap_ptr)); > BUG_ON(dmabuf->vmapping_counter == 0); > BUG_ON(!iosys_map_is_equal(&dmabuf->vmap_ptr, map)); > -- > 2.37.3 > -- Thanks and regards, Sumit Semwal (he / him) Tech Lead - LCG, Vertical Technologies Linaro.org │ Open source software for ARM SoCs
Re: [Intel-gfx] [PATCH v5 2/2] drm/i915/dgfx: Release mmap on rpm suspend
On Tue, 13 Sept 2022 at 16:27, Anshuman Gupta wrote:
>
> Release all mmap mapping for all lmem objects which are associated
> with userfault such that, while pcie function in D3hot, any access
> to memory mappings will raise a userfault.
>
> Runtime resume the dgpu(when gem object lies in lmem).
> This will transition the dgpu graphics function to D0
> state if it was in D3 in order to access the mmap memory
> mappings.
>
> v2:
> - Squashes the patches. [Matt Auld]
> - Add adequate locking for lmem_userfault_list addition. [Matt Auld]
> - Reused obj->userfault_count to avoid double addition. [Matt Auld]
> - Added i915_gem_object_lock to check
> i915_gem_object_is_lmem. [Matt Auld]
>
> v3:
> - Use i915_ttm_cpu_maps_iomem. [Matt Auld]
> - Fix 'ret == 0 to ret == VM_FAULT_NOPAGE'. [Matt Auld]
> - Reuse obj->userfault_count as a bool 0 or 1. [Matt Auld]
> - Delete the mmaped obj from lmem_userfault_list in obj
> destruction path. [Matt Auld]
> - Get a wakeref for object destruction patch. [Matt Auld]
> - Use intel_wakeref_auto to delay runtime PM. [Matt Auld]
>
> v4:
> - Avoid using mmo offset to get the vma_node. [Matt Auld]
> - Added comment to use the lmem_userfault_lock. [Matt Auld]
> - Get lmem_userfault_lock in i915_gem_object_release_mmap_offset.
> [Matt Auld]
> - Fixed kernel test robot generated warning.
>
> v5:
> - Addressed the cosmetics comments. [Andi]
> - Changed i915_gem_runtime_pm_object_release_mmap_offset() name to
> i915_gem_object_runtime_pm_release_mmap_offset() to be rhythmic.
>
> PCIe Specs 5.3.1.4.1
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/6331
> Cc: Matthew Auld
> Cc: Rodrigo Vivi
> Signed-off-by: Anshuman Gupta
> Reviewed-by: Andi Shyti
> ---
> drivers/gpu/drm/i915/gem/i915_gem_mman.c | 21 +++
> drivers/gpu/drm/i915/gem/i915_gem_mman.h | 1 +
> drivers/gpu/drm/i915/gem/i915_gem_object.c| 2 +-
> .../gpu/drm/i915/gem/i915_gem_object_types.h | 3 +-
> drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 36 +--
> drivers/gpu/drm/i915/gt/intel_gt.c| 2 ++
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 14
> drivers/gpu/drm/i915/i915_gem.c | 4 +++
> 8 files changed, 79 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> index b55befda3387..73d9eda1d6b7 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
> @@ -550,6 +550,20 @@ void i915_gem_object_release_mmap_gtt(struct
> drm_i915_gem_object *obj)
> intel_runtime_pm_put(&i915->runtime_pm, wakeref);
> }
>
> +void i915_gem_object_runtime_pm_release_mmap_offset(struct
> drm_i915_gem_object *obj)
> +{
> + struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
> + struct ttm_device *bdev = bo->bdev;
> +
> + drm_vma_node_unmap(&bo->base.vma_node, bdev->dev_mapping);
> +
> + if (obj->userfault_count) {
> + /* rpm wakeref provide exclusive access */
> + list_del(&obj->userfault_link);
> + obj->userfault_count = 0;
> + }
> +}
> +
> void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj)
> {
> struct i915_mmap_offset *mmo, *mn;
> @@ -573,6 +587,13 @@ void i915_gem_object_release_mmap_offset(struct
> drm_i915_gem_object *obj)
> spin_lock(&obj->mmo.lock);
> }
> spin_unlock(&obj->mmo.lock);
> +
> + if (obj->userfault_count) {
> +
> mutex_lock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
> + list_del(&obj->userfault_link);
> +
> mutex_unlock(&to_gt(to_i915(obj->base.dev))->lmem_userfault_lock);
> + obj->userfault_count = 0;
> + }
Sorry for the late reply, I was out last week. This looks like it's
missing holding the runtime pm AFAICT. We are holding the runtime pm
for object destruction, but this is also called when a move is
triggered (very common). If so, this can race against the runtime pm
also touching the list concurrently. We are chasing some crazy looking
NULL deref bugs, so wondering if this is somehow related...
> }
>
> static struct i915_mmap_offset *
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> index efee9e0d2508..1fa91b3033b3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.h
> @@ -27,6 +27,7 @@ int i915_gem_dumb_mmap_offset(struct drm_file *file_priv,
> void __i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
> void i915_gem_object_release_mmap_gtt(struct drm_i915_gem_object *obj);
>
> +void i915_gem_object_runtime_pm_release_mmap_offset(struct
> drm_i915_gem_object *obj);
> void i915_gem_object_release_mmap_offset(struct drm_i915_gem_object *obj);
>
> #endif
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i9
Re: [Intel-gfx] [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
> -Original Message-
> From: Nikula, Jani
> Sent: Friday, September 16, 2022 5:00 PM
> To: Manna, Animesh ; Ville Syrjälä
>
> Cc: intel-gfx@lists.freedesktop.org; Shankar, Uma
> Subject: RE: [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP scenario
>
> On Fri, 16 Sep 2022, "Manna, Animesh" wrote:
> >> -Original Message-
> >> From: Ville Syrjälä
> >> Sent: Friday, September 16, 2022 2:28 PM
> >> To: Manna, Animesh
> >> Cc: intel-gfx@lists.freedesktop.org; Nikula, Jani
> >> ; Shankar, Uma
> >> Subject: Re: [PATCH 2/2] drm/i915/pps: Enable 2nd pps for dual EDP
> >> scenario
> >>
> >> On Fri, Sep 16, 2022 at 02:01:02PM +0530, Animesh Manna wrote:
> >> > >From display gen12 onwards to support dual EDP two instances of pps
> added.
> >> > Currently backlight controller and pps instance can be mapped
> >> > together for a specific panel. Extended support for gen12 for dual EDP
> usage.
> >> >
> >> > v1: Iniital revision
> >> > v2: Called intel_bios_panel_init w/o PNPID before intel_pps_init.
> >> > [Jani]
> >> >
> >> > Cc: Jani Nikula
> >> > Cc: Ville Syrjälä
> >> > Cc: Uma Shankar
> >> > Signed-off-by: Animesh Manna
> >> > ---
> >> > drivers/gpu/drm/i915/display/intel_bios.c | 7 ---
> >> > drivers/gpu/drm/i915/display/intel_bios.h | 7 +++
> >> > drivers/gpu/drm/i915/display/intel_dp.c | 9 ++---
> >> > drivers/gpu/drm/i915/display/intel_pps.c | 2 +-
> >> > 4 files changed, 14 insertions(+), 11 deletions(-)
> >> >
> >> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> >> > b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > index 28bdb936cd1f..5fd4c09dfa96 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> >> > @@ -706,13 +706,6 @@ static int fallback_get_panel_type(struct
> >> drm_i915_private *i915,
> >> > return 0;
> >> > }
> >> >
> >> > -enum panel_type {
> >> > - PANEL_TYPE_OPREGION,
> >> > - PANEL_TYPE_VBT,
> >> > - PANEL_TYPE_PNPID,
> >> > - PANEL_TYPE_FALLBACK,
> >> > -};
> >> > -
> >> > static int get_panel_type(struct drm_i915_private *i915,
> >> > const struct intel_bios_encoder_data *devdata,
> >> > const struct edid *edid) diff --git
> >> > a/drivers/gpu/drm/i915/display/intel_bios.h
> >> > b/drivers/gpu/drm/i915/display/intel_bios.h
> >> > index e375405a7828..da01b13260ae 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_bios.h
> >> > +++ b/drivers/gpu/drm/i915/display/intel_bios.h
> >> > @@ -231,6 +231,13 @@ struct mipi_pps_data {
> >> > u16 panel_power_cycle_delay;
> >> > } __packed;
> >> >
> >> > +enum panel_type {
> >> > + PANEL_TYPE_OPREGION,
> >> > + PANEL_TYPE_VBT,
> >> > + PANEL_TYPE_PNPID,
> >> > + PANEL_TYPE_FALLBACK,
> >> > +};
> >> > +
>
> I don't want enum panel_type exposed from intel_bios.c at all, there's no
> reason
> for that.
Hi Jani,
Thanks for your inputs. I have made the changes as per your suggestion.
I have a doubt which is mentioned below, currently have sent to trybot for
quick feedback.
https://patchwork.freedesktop.org/patch/503759/?series=108786&rev=1
>
> >> > void intel_bios_init(struct drm_i915_private *dev_priv); void
> >> > intel_bios_init_panel(struct drm_i915_private *dev_priv,
> >> >struct intel_panel *panel, diff --git
> >> > a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > index c19e99ee06b6..6f7afa75ec4d 100644
> >> > --- a/drivers/gpu/drm/i915/display/intel_dp.c
> >> > +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> >> > @@ -5222,6 +5222,9 @@ static bool intel_edp_init_connector(struct
> >> > intel_dp
> >> *intel_dp,
> >> > return false;
> >> > }
> >> >
> >> > + intel_bios_init_panel(dev_priv, &intel_connector->panel,
> >> > + encoder->devdata, NULL);
> >>
> >> We don't want to go for the fallback type here if we the VBT wants us
> >> to use pnpid. Maybe we should just remove the fallback type entirely?
> >> Or perhaps only use it if the VBT panel type is entirely invalid?
> >
> > Ok, Can I add like below?
> > If (!PANEL_TYPE_FALLBACK)
> > intel_pps_init(intel_dp);
> >
> > But to read EDID pps_init should be called before it. Or else I can enable
> > both
> the pps and later disable the unused one.
>
> The first call should init everything if it can (panel type is *not* pnpid).
> Fallback is
> fine in that case too.
First time intel_bios_init_panel() will be called with null edid and panel type
will be set to PANEL_TYPE_FALLBACK.
>
> If panel type indicates pnpid, intel_bios_init_panel() should set the pps id
> to, say,
> -1, so intel_pps_init() or more specifically
> bxt_power_sequencer_idx() can use some default or look at the hardware or
> whatever.
Currently checking for PANEL_TYPE_PNPID in intel_bios_init_panel() and setting
pps id to -1.
But I am not sure why special handling is needed in bxt_power_sequencer_idx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915/mtl: enable local stolen memory
== Series Details == Series: series starting with [1/1] drm/i915/mtl: enable local stolen memory URL : https://patchwork.freedesktop.org/series/108767/ State : success == Summary == CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_108767v1_full Summary --- **SUCCESS** No regressions found. Participating hosts (10 -> 11) -- Additional (1): shard-rkl Known issues Here are the changes found in Patchwork_108767v1_full that come from known issues: ### CI changes ### Issues hit * boot: - shard-glk: ([PASS][1], [PASS][2], [PASS][3], [PASS][4], [PASS][5], [PASS][6], [PASS][7], [PASS][8], [PASS][9], [PASS][10], [PASS][11], [PASS][12], [PASS][13], [PASS][14], [PASS][15], [PASS][16], [PASS][17], [PASS][18], [PASS][19], [PASS][20], [PASS][21], [PASS][22], [PASS][23], [PASS][24], [PASS][25]) -> ([PASS][26], [PASS][27], [PASS][28], [PASS][29], [PASS][30], [PASS][31], [PASS][32], [PASS][33], [PASS][34], [PASS][35], [PASS][36], [PASS][37], [PASS][38], [PASS][39], [PASS][40], [PASS][41], [PASS][42], [PASS][43], [FAIL][44], [PASS][45], [PASS][46], [PASS][47], [PASS][48], [PASS][49], [PASS][50]) ([i915#4392]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk1/boot.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk1/boot.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk1/boot.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk2/boot.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk2/boot.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk2/boot.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk2/boot.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk3/boot.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk3/boot.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk3/boot.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk5/boot.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk5/boot.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk5/boot.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk6/boot.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk6/boot.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk6/boot.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk7/boot.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk7/boot.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk7/boot.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk8/boot.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk8/boot.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk8/boot.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk9/boot.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk9/boot.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-glk9/boot.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk5/boot.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk6/boot.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk6/boot.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk6/boot.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk7/boot.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk7/boot.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk7/boot.html [33]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk8/boot.html [34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk8/boot.html [35]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk8/boot.html [36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk9/boot.html [37]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk9/boot.html [38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk9/boot.html [39]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk1/boot.html [40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk2/boot.html [41]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk2/boot.html [42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/shard-glk2/boot.html [43]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork
[Intel-gfx] ✗ Fi.CI.IGT: failure for Explicit MCR handling and MTL steering
== Series Details == Series: Explicit MCR handling and MTL steering URL : https://patchwork.freedesktop.org/series/108755/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_108755v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108755v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108755v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 10) -- No changes in participating hosts Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108755v1_full: ### IGT changes ### Possible regressions * igt@i915_suspend@debugfs-reader: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb3/igt@i915_susp...@debugfs-reader.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-tglb1/igt@i915_susp...@debugfs-reader.html Warnings * igt@runner@aborted: - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27]) ([i915#6599]) -> ([FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], [FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl10/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl7/igt@run...@aborted.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl10/igt@run...@aborted.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl4/igt@run...@aborted.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108755v1/shard-skl6/igt@run...@aborted.html [33]: https://intel-gfx-ci.01.o
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Perf_limit_reasons are only available for Gen11+
== Series Details == Series: drm/i915: Perf_limit_reasons are only available for Gen11+ URL : https://patchwork.freedesktop.org/series/108747/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_108747v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108747v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108747v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 11) -- Additional (1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108747v1_full: ### IGT changes ### Possible regressions * igt@api_intel_allocator@two-level-inception: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb8/igt@api_intel_alloca...@two-level-inception.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-tglb8/igt@api_intel_alloca...@two-level-inception.html Warnings * igt@runner@aborted: - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27]) ([i915#6599]) -> ([FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], [FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-skl10/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-skl10/igt@run...@aborted.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-skl1/igt@run...@aborted.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-skl6/igt@run...@aborted.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108747v1/shard-skl4/igt@run...
[Intel-gfx] ✗ Fi.CI.IGT: failure for Enable Pipewriteback (rev7)
== Series Details == Series: Enable Pipewriteback (rev7) URL : https://patchwork.freedesktop.org/series/107440/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_107440v7_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_107440v7_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_107440v7_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 11) -- Additional (1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_107440v7_full: ### IGT changes ### Possible regressions * igt@i915_suspend@basic-s3-without-i915: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-iclb6/igt@i915_susp...@basic-s3-without-i915.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v7/shard-iclb3/igt@i915_susp...@basic-s3-without-i915.html Warnings * igt@kms_writeback@writeback-check-output: - shard-tglb: [SKIP][3] ([i915#2437]) -> [INCOMPLETE][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb3/igt@kms_writeb...@writeback-check-output.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v7/shard-tglb1/igt@kms_writeb...@writeback-check-output.html * igt@kms_writeback@writeback-fb-id: - shard-tglb: [SKIP][5] ([i915#2437]) -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb2/igt@kms_writeb...@writeback-fb-id.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_107440v7/shard-tglb8/igt@kms_writeb...@writeback-fb-id.html * igt@runner@aborted: - shard-skl: ([FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31]) ([i915#6599]) -> ([FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], [FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52], [FAIL][53], [FAIL][54], [FAIL][55], [FAIL][56]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [30]: https://intel-gfx-ci.01.org/tree/drm-t
Re: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Use lockdep_assert_held()
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Monday, June 20, 2022 9:29 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915/fbc: Use lockdep_assert_held()
>
> From: Ville Syrjälä
>
> Replace the mutex_is_locked() stuff with lockdep_assert_held() since that's
> what
> it's there for.
>
> Asoo sprinkle these around so that we have more or less mirrored coverate for
> the enable vs. disable instead of the current situation where the asserts
> seem to
> be more or less randomly thrown around.
>
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 17 ++---
> 1 file changed, 10 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 77669e03b9f7..db1c0eb508fa 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -669,6 +669,7 @@ static void intel_fbc_nuke(struct intel_fbc *fbc) {
> struct drm_i915_private *i915 = fbc->i915;
>
> + lockdep_assert_held(&fbc->lock);
> drm_WARN_ON(&i915->drm, fbc->flip_pending);
>
> trace_intel_fbc_nuke(fbc->state.plane);
> @@ -678,6 +679,8 @@ static void intel_fbc_nuke(struct intel_fbc *fbc)
>
> static void intel_fbc_activate(struct intel_fbc *fbc) {
> + lockdep_assert_held(&fbc->lock);
> +
> intel_fbc_hw_activate(fbc);
> intel_fbc_nuke(fbc);
>
> @@ -686,9 +689,7 @@ static void intel_fbc_activate(struct intel_fbc *fbc)
>
> static void intel_fbc_deactivate(struct intel_fbc *fbc, const char *reason)
> {
> - struct drm_i915_private *i915 = fbc->i915;
> -
> - drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
> + lockdep_assert_held(&fbc->lock);
>
> if (fbc->active)
> intel_fbc_hw_deactivate(fbc);
> @@ -1220,6 +1221,8 @@ static bool __intel_fbc_pre_update(struct
> intel_atomic_state *state,
> struct intel_fbc *fbc = plane->fbc;
> bool need_vblank_wait = false;
>
> + lockdep_assert_held(&fbc->lock);
> +
> fbc->flip_pending = true;
>
> if (intel_fbc_can_flip_nuke(state, crtc, plane)) @@ -1277,7 +1280,7 @@
> static void __intel_fbc_disable(struct intel_fbc *fbc)
> struct drm_i915_private *i915 = fbc->i915;
> struct intel_plane *plane = fbc->state.plane;
>
> - drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
> + lockdep_assert_held(&fbc->lock);
> drm_WARN_ON(&i915->drm, fbc->active);
>
> drm_dbg_kms(&i915->drm, "Disabling FBC on [PLANE:%d:%s]\n", @@ -
> 1292,9 +1295,7 @@ static void __intel_fbc_disable(struct intel_fbc *fbc)
>
> static void __intel_fbc_post_update(struct intel_fbc *fbc) {
> - struct drm_i915_private *i915 = fbc->i915;
> -
> - drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
> + lockdep_assert_held(&fbc->lock);
>
> fbc->flip_pending = false;
>
> @@ -1430,6 +1431,8 @@ static void __intel_fbc_enable(struct
> intel_atomic_state *state,
> intel_atomic_get_new_plane_state(state, plane);
> struct intel_fbc *fbc = plane->fbc;
>
> + lockdep_assert_held(&fbc->lock);
> +
> if (fbc->state.plane) {
> if (fbc->state.plane != plane)
> return;
> --
> 2.35.1
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, Sep 20, 2022 at 12:49:40PM +0530, Aravind Iddamsetty wrote:
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
I called a similar function as is_dsm_valid() in
https://patchwork.freedesktop.org/series/108620/
sounds weird with "invalid" and the double negation on return early
style.
+ if (dsm->start == 0)
+ return true;
+ }
+
+ if (dsm->end <= dsm->start)
+ return true;
+
+ return false;
+}
+
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (is_dsm_invalid(i915, dsm))
return -EINVAL;
/*
@@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
* overlaps with the non-stolen system memory range, since lmem is local
* to the gpu.
*/
- if (HAS_LMEM(i915))
+ if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
comment above makes no sense when you add this. For this specific case
it's still system memory, reserved by the BIOS and that we access by
mapping the lmembar
return 0;
/*
@@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
- *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+ if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
+ /* the base is initialized to stolen top so subtract size to
get base */
+ *base -= *size;
that doesn't necessarily holds true. According to the spec the wopcm
base is 1MB aligned so even if it is "at the top", it may not mean it is at the
very very top that we can just subtract the size.
+ else
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
}
static int i915_gem_init_stolen(struct intel_memory_region *mem)
@@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
??
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
+ return (gms - 0xf0 + 1) * 4;
+ default:
+ return -EIO;
+ }
+}
+
+static inli
Re: [Intel-gfx] [PATCH 1/2] drm/i915/fbc: Move flip_pending assignmnt
> -Original Message-
> From: Intel-gfx On Behalf Of Ville
> Syrjala
> Sent: Monday, June 20, 2022 9:29 PM
> To: intel-gfx@lists.freedesktop.org
> Subject: [Intel-gfx] [PATCH 1/2] drm/i915/fbc: Move flip_pending assignmnt
>
> From: Ville Syrjälä
>
> Move the flip_pending assignment into __intel_fbc_post_update() from
> intel_fbc_post_update(). Now mirrors the pre_update() side.
>
> The only reason the assignment was in the higher level function is that we
> used
> to call __intel_fbc_post_update() from elsewhere as well. That got cleaned up
> in
> commit b39d2c620242 ("drm/i915/fbc:
> Call intel_fbc_activate() directly from frontbuffer flush")
>
Reviewed-by: Mika Kahola
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_fbc.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c
> b/drivers/gpu/drm/i915/display/intel_fbc.c
> index 8b807284cde1..77669e03b9f7 100644
> --- a/drivers/gpu/drm/i915/display/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/display/intel_fbc.c
> @@ -1296,6 +1296,8 @@ static void __intel_fbc_post_update(struct intel_fbc
> *fbc)
>
> drm_WARN_ON(&i915->drm, !mutex_is_locked(&fbc->lock));
>
> + fbc->flip_pending = false;
> +
> if (!fbc->busy_bits)
> intel_fbc_activate(fbc);
> else
> @@ -1317,10 +1319,8 @@ void intel_fbc_post_update(struct
> intel_atomic_state *state,
>
> mutex_lock(&fbc->lock);
>
> - if (fbc->state.plane == plane) {
> - fbc->flip_pending = false;
> + if (fbc->state.plane == plane)
> __intel_fbc_post_update(fbc);
> - }
>
> mutex_unlock(&fbc->lock);
> }
> --
> 2.35.1
Re: [Intel-gfx] [PATCH 0/6] Introduce struct cdclk_step
On Fri, Sep 16, 2022 at 05:43:58PM -0700, Anusha Srivatsa wrote: > This is a prep series for the actual cdclk refactoring > that will be sent following this. Idea is to have a > struct - cdclk_step that holds the following: > - cdclk action (squash, crawl or modeset) > - cdclk frequency > which gets populated in atomic check. Driver > uses the populated values during atomic commit > to do the suitable sequence of actions like > programming squash ctl registers in case of squashing > or PLL sequence incase of modeset and so on. > > This series just addresses the initial idea. The actual plumming > in the atomic commit phase will be sent shortly. OK, people keep ignoring what I say so I just typed up the code quickly. This to me seems like the most straightforward way to do what we need: https://github.com/vsyrjala/linux.git cdclk_crawl_and_squash Totally untested ofc, apart from me doing a quick scan through our cdclk tables for the crawl+squahs platforms to make sure that this approach should produce sane values. > > Cc: Ville Syrjälä > Cc: Uma Shankar > Cc: Rodrigo Vivi > > Anusha Srivatsa (6): > drm/i915/display Add dg2_prog_squash_ctl() helper > drm/i915/display: add cdclk action struct to cdclk_config > drm/i915/display: Embed the new struct steps for squashing > drm/i915/display: Embed the new struct steps for crawling > drm/i915/display: Embed the new struct steps for modeset > drm/i915/display: Dump the new cdclk config values > > drivers/gpu/drm/i915/display/intel_cdclk.c | 77 +- > drivers/gpu/drm/i915/display/intel_cdclk.h | 16 - > 2 files changed, 74 insertions(+), 19 deletions(-) > > -- > 2.25.1 -- Ville Syrjälä Intel
Re: [Intel-gfx] [PATCH] drm/i915: Do not dereference NULL bo->resource
On 9/19/2022 5:29 PM, Gupta, Anshuman wrote:
-Original Message-
From: Das, Nirmoy
Sent: Monday, September 19, 2022 8:33 PM
To: intel-gfx@lists.freedesktop.org
Cc: dri-de...@lists.freedesktop.org; Auld, Matthew
; Gupta, Anshuman
Subject: [PATCH] drm/i915: Do not dereference NULL bo->resource
bo->resource could be NULL hence add a NULL check for resource before
bo->dereferencing it.
Will bo->resource will be NULL only in case of object is smem or it can be NULL
even in lmem case as well ?
It can happen with lmem too. I think we should just use
i915_gem_object_is_lmem() instead of i915_ttm_cpu_maps_iomem here.
Nirmoy
Thanks,
Anshuman Gupta.
References: https://gitlab.freedesktop.org/drm/intel/-/issues/6850
Fixes: ad74457a6b5a96 ("drm/i915/dgfx: Release mmap on rpm suspend")
Signed-off-by: Nirmoy Das
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 0544b0a4a43a..8608801cd9ab 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -513,7 +513,7 @@ static void i915_ttm_delete_mem_notify(struct
ttm_buffer_object *bo)
if (likely(obj)) {
/* ttm_bo_release() already has dma_resv_lock */
- if (i915_ttm_cpu_maps_iomem(bo->resource))
+ if (bo->resource && i915_ttm_cpu_maps_iomem(bo-
resource))
wakeref = intel_runtime_pm_get(&to_i915(obj-
base.dev)->runtime_pm);
__i915_gem_object_pages_fini(obj);
--
2.37.3
Re: [Intel-gfx] [PATCH 2/2] drm/i915/mtl: Add C6 residency support for MTL SAMedia
On Mon, 19 Sep 2022, "Dixit, Ashutosh" wrote:
> On Mon, 19 Sep 2022 05:13:18 -0700, Jani Nikula wrote:
>>
>> On Mon, 19 Sep 2022, Badal Nilawar wrote:
>> > For MTL SAMedia updated relevant functions and places in the code to get
>> > Media C6 residency.
>> >
>> > v2: Fixed review comments (Ashutosh)
>> >
>> > Cc: Vinay Belgaumkar
>> > Cc: Ashutosh Dixit
>> > Cc: Chris Wilson
>> > Signed-off-by: Badal Nilawar
>> > ---
>> > drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c | 60 +++
>> > drivers/gpu/drm/i915/gt/intel_gt_regs.h | 10
>> > drivers/gpu/drm/i915/gt/intel_gt_sysfs_pm.c | 9 ++-
>> > drivers/gpu/drm/i915/gt/intel_rc6.c | 5 +-
>> > drivers/gpu/drm/i915/gt/selftest_rc6.c| 9 ++-
>> > drivers/gpu/drm/i915/i915_pmu.c | 8 ++-
>> > 6 files changed, 97 insertions(+), 4 deletions(-)
>> >
>> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>> > b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>> > index 68310881a793..053167b506a9 100644
>> > --- a/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>> > +++ b/drivers/gpu/drm/i915/gt/intel_gt_pm_debugfs.c
>> > @@ -269,6 +269,64 @@ static int ilk_drpc(struct seq_file *m)
>> >return 0;
>> > }
>> >
>> > +static int mtl_drpc(struct seq_file *m)
>> > +{
>> > + struct intel_gt *gt = m->private;
>> > + struct intel_uncore *uncore = gt->uncore;
>> > + u32 gt_core_status, rcctl1, global_forcewake;
>> > + u32 mtl_powergate_enable = 0, mtl_powergate_status = 0;
>> > + i915_reg_t reg;
>> > +
>> > + gt_core_status = intel_uncore_read(uncore, MTL_MIRROR_TARGET_WP1);
>> > +
>> > + global_forcewake = intel_uncore_read(uncore, FORCEWAKE_GT_GEN9);
>> > +
>> > + rcctl1 = intel_uncore_read(uncore, GEN6_RC_CONTROL);
>> > + mtl_powergate_enable = intel_uncore_read(uncore, GEN9_PG_ENABLE);
>> > + mtl_powergate_status = intel_uncore_read(uncore,
>> > + GEN9_PWRGT_DOMAIN_STATUS);
>> > +
>> > + seq_printf(m, "RC6 Enabled: %s\n",
>> > + str_yes_no(rcctl1 & GEN6_RC_CTL_RC6_ENABLE));
>> > + if (gt->type == GT_MEDIA) {
>> > + seq_printf(m, "Media Well Gating Enabled: %s\n",
>> > + str_yes_no(mtl_powergate_enable &
>> > GEN9_MEDIA_PG_ENABLE));
>> > + } else {
>> > + seq_printf(m, "Render Well Gating Enabled: %s\n",
>> > + str_yes_no(mtl_powergate_enable &
>> > GEN9_RENDER_PG_ENABLE));
>> > + }
>> > +
>> > + seq_puts(m, "Current RC state: ");
>> > +
>> > + switch ((gt_core_status & MTL_CC_MASK) >> MTL_CC_SHIFT) {
>> > + case MTL_CC0:
>> > + seq_puts(m, "on\n");
>> > + break;
>> > + case MTL_CC6:
>> > + seq_puts(m, "RC6\n");
>> > + break;
>> > + default:
>> > + seq_puts(m, "Unknown\n");
>> > + break;
>> > + }
>> > +
>> > + if (gt->type == GT_MEDIA)
>> > + seq_printf(m, "Media Power Well: %s\n",
>> > + (mtl_powergate_status &
>> > + GEN9_PWRGT_MEDIA_STATUS_MASK) ? "Up" : "Down");
>> > + else
>> > + seq_printf(m, "Render Power Well: %s\n",
>> > + (mtl_powergate_status &
>> > + GEN9_PWRGT_RENDER_STATUS_MASK) ? "Up" : "Down");
>> > +
>> > + reg = (gt->type == GT_MEDIA) ? MTL_MEDIA_MC6 : GEN6_GT_GFX_RC6;
>> > + print_rc6_res(m, "RC6 residency since boot:", reg);
>>
>> Cc: Tvrtko, Joonas, Rodrigo
>>
>
> Hi Jani,
>
>> IMO the register is not a good abstraction to build interfaces on. I see
>> that this is not where the idea is introduced, but it'll probably get
>> you in trouble later on.
>
> By "this is not where the idea is introduced" are you referring to what we
> did here:
>
> https://patchwork.freedesktop.org/patch/502372/?series=108091&rev=5
>
> in intel_gt_perf_limit_reasons_reg()?
>
> Or, should we follow the schema of centralizing the register selection
> depending on gt type in a single function here too (since this register
> selection is repeated throughout this patch)?
I'm looking at print_rc6_res(), for example.
It takes the register, reads it, and also passes the register around,
eventually to intel_rc6_residency_ns(). That does magic on the register
offset, so it assumes a certain multi-register layout, and relative from
GEN6_GT_GFX_RC6_LOCKED. Then it assumes the register contents are
different on different platforms.
So why did we pass around the register to begin with? The knowledge
about the register offsets and contents are spread around. What if
another platform gets added with a different register contents or layout
or offsets?
Registers are a really low level of abstraction, and IMO usually should
not be passed around like this.
BR,
Jani.
>
> Thanks.
> --
> Ashutosh
>
>
>
>>
>> BR,
>> Jani.
>>
>> > +
>> > + seq_printf(m, "Global Forcewake Requests: 0x%x\n", global_forcewake);
>> > +
>> > + return fw_domains_show(m, NULL);
>> > +}
>> > +
>> > static int drpc_show(struct seq_file *m, void *unused)
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915/mtl: enable local stolen memory
== Series Details == Series: series starting with [1/1] drm/i915/mtl: enable local stolen memory URL : https://patchwork.freedesktop.org/series/108767/ State : success == Summary == CI Bug Log - changes from CI_DRM_12158 -> Patchwork_108767v1 Summary --- **WARNING** Minor unknown changes coming with Patchwork_108767v1 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108767v1, 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_108767v1/index.html Participating hosts (42 -> 43) -- Additional (5): fi-cml-u2 fi-icl-u2 fi-cfl-guc fi-icl-y bat-dg2-11 Missing(4): fi-ctg-p8600 bat-jsl-3 fi-kbl-guc bat-dg1-5 Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108767v1: ### IGT changes ### Warnings * igt@runner@aborted: - fi-apl-guc: [FAIL][1] ([i915#6599]) -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-apl-guc/igt@run...@aborted.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-apl-guc/igt@run...@aborted.html - fi-skl-guc: [FAIL][3] ([i915#6599]) -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-skl-guc/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-skl-guc/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_108767v1 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_fence@basic-busy@bcs0: - fi-cml-u2: NOTRUN -> [SKIP][5] ([i915#1208]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cml-u2/igt@gem_exec_fence@basic-b...@bcs0.html * igt@gem_huc_copy@huc-copy: - fi-icl-y: NOTRUN -> [SKIP][6] ([i915#2190]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-icl-y/igt@gem_huc_c...@huc-copy.html - fi-icl-u2: NOTRUN -> [SKIP][7] ([i915#2190]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-icl-u2/igt@gem_huc_c...@huc-copy.html - fi-cml-u2: NOTRUN -> [SKIP][8] ([i915#2190]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cml-u2/igt@gem_huc_c...@huc-copy.html * igt@gem_lmem_swapping@parallel-random-engines: - fi-cml-u2: NOTRUN -> [SKIP][9] ([i915#4613]) +3 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cml-u2/igt@gem_lmem_swapp...@parallel-random-engines.html * igt@gem_lmem_swapping@random-engines: - fi-icl-u2: NOTRUN -> [SKIP][10] ([i915#4613]) +3 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-icl-u2/igt@gem_lmem_swapp...@random-engines.html * igt@gem_lmem_swapping@verify-random: - fi-cfl-guc: NOTRUN -> [SKIP][11] ([fdo#109271] / [i915#4613]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cfl-guc/igt@gem_lmem_swapp...@verify-random.html - fi-icl-y: NOTRUN -> [SKIP][12] ([i915#4613]) +3 similar issues [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-icl-y/igt@gem_lmem_swapp...@verify-random.html * igt@i915_module_load@load: - fi-bdw-gvtdvm: [PASS][13] -> [DMESG-WARN][14] ([i915#6540]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-bdw-gvtdvm/igt@i915_module_l...@load.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-bdw-gvtdvm/igt@i915_module_l...@load.html * igt@i915_pm_rpm@module-reload: - fi-cfl-8109u: [PASS][15] -> [DMESG-FAIL][16] ([i915#62]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-cfl-8109u/igt@i915_pm_...@module-reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cfl-8109u/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live: - fi-cfl-8109u: NOTRUN -> [INCOMPLETE][17] ([i915#6114]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cfl-8109u/igt@i915_selft...@live.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-hsw-4770:NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: NOTRUN -> [SKIP][19] ([fdo#109284] / [fdo#111827]) +8 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108767v1/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html * igt@kms_chamelium@dp-edid-read: - fi-cfl-guc: NOTRUN ->
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Do not dereference NULL bo->resource
== Series Details == Series: drm/i915: Do not dereference NULL bo->resource URL : https://patchwork.freedesktop.org/series/108744/ State : failure == Summary == CI Bug Log - changes from CI_DRM_12158_full -> Patchwork_108744v1_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_108744v1_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_108744v1_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Participating hosts (10 -> 11) -- Additional (1): shard-rkl Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_108744v1_full: ### IGT changes ### Possible regressions * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-indfb-plflip-blt: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-plflip-blt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108744v1/shard-tglb3/igt@kms_frontbuffer_track...@fbc-1p-primscrn-indfb-plflip-blt.html Warnings * igt@runner@aborted: - shard-skl: ([FAIL][3], [FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8], [FAIL][9], [FAIL][10], [FAIL][11], [FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27]) ([i915#6599]) -> ([FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], [FAIL][48], [FAIL][49], [FAIL][50], [FAIL][51], [FAIL][52]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl1/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl10/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl6/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl4/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl7/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/shard-skl9/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108744v1/shard-skl9/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108744v1/shard-skl1/igt@run...@aborted.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108744v1/shard-skl7/igt@run...@aborted.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_108744v1/shard-skl7/igt@run...@aborted.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/
Re: [Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
On Tue, 20 Sep 2022, Aravind Iddamsetty wrote:
> As an integrated GPU, MTL does not have local memory and
> HAS_LMEM() returns false. However the platform's stolen memory
> is presented via BAR2 (i.e., the BAR we traditionally consider
> to be the LMEM BAR) and should be managed by the driver the same
> way that local memory is on dgpu platforms (which includes
> setting the "lmem" bit on page table entries). We use the term
> "local stolen memory" to refer to this model.
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
>
> Signed-off-by: CQ Tang
> Signed-off-by: Aravind Iddamsetty
> Original-author: CQ Tang
> ---
> drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h| 3 +
> 3 files changed, 100 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> index acc561c0f0aa..bad5250fb764 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
> @@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
> *i915,
> mutex_unlock(&i915->mm.stolen_lock);
> }
>
> +static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource
> *dsm)
Abstracting this as a separate function looks like a separate patch.
I generally recommend using positive naming, "is dsm valid", to avoid
any double negatives that might pop up, now or in the
future. !is_dsm_invalid() gets slower for human brains to parse.
BR,
Jani.
> +{
> + if (!HAS_BAR2_SMEM_STOLEN(i915)) {
> + if (dsm->start == 0)
> + return true;
> + }
> +
> + if (dsm->end <= dsm->start)
> + return true;
> +
> + return false;
> +}
> +
> static int i915_adjust_stolen(struct drm_i915_private *i915,
> struct resource *dsm)
> {
> @@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
> struct intel_uncore *uncore = ggtt->vm.gt->uncore;
> struct resource *r;
>
> - if (dsm->start == 0 || dsm->end <= dsm->start)
> + if (is_dsm_invalid(i915, dsm))
> return -EINVAL;
>
> /*
> @@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private
> *i915,
>* overlaps with the non-stolen system memory range, since lmem is local
>* to the gpu.
>*/
> - if (HAS_LMEM(i915))
> + if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
> return 0;
>
> /*
> @@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct
> drm_i915_private *i915,
>
> drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
>
> - *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
> -
> switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
> case GEN8_STOLEN_RESERVED_1M:
> *size = 1024 * 1024;
> @@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
> drm_i915_private *i915,
> *size = 8 * 1024 * 1024;
> MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
> }
> +
> + if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
> + /* the base is initialized to stolen top so subtract size to
> get base */
> + *base -= *size;
> + else
> + *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
> }
>
> static int i915_gem_init_stolen(struct intel_memory_region *mem)
> @@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct
> intel_memory_region *mem)
> if (i915_adjust_stolen(i915, &i915->dsm))
> return 0;
>
> - GEM_BUG_ON(i915->dsm.start == 0);
> - GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
> + GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
>
> stolen_top = i915->dsm.end + 1;
> reserved_base = stolen_top;
> @@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
> i915_region_stolen_lmem_ops = {
> .init_object = _i915_gem_object_stolen_init,
> };
>
> +static int get_mtl_gms_size(struct intel_uncore *uncore)
> +{
> + u16 ggc, gms;
> +
> + ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
> +
> + /* check GGMS, should be fixed 0x3 (8MB) */
> + if ((ggc & 0xc0) != 0xc0)
> + return -EIO;
> +
> + /* return valid GMS value, -EIO if invalid */
> + gms = ggc >> 8;
> + switch (gms) {
> + case 0x0 ... 0x10:
> + return gms * 32;
> + case 0x20:
> + return 1024;
> + case 0x30:
> + return 1536;
> + case 0x40:
> + return 2048;
> + case 0xf0 ... 0xfe:
> + return (gms - 0xf0 + 1) * 4;
> + default:
> + return -EIO;
> + }
> +}
> +
> +static inline bool lmembar_is_igpu_stolen(struct drm_i915_private *i915)
> +{
> + u32 regions = RUNTIME_INFO(i915)->memory_regions;
> +
> + if (r
Re: [Intel-gfx] [PATCH 0/4] drm/atomic: Lockless blocking commits
On Fri, 16 Sep 2022 19:33:27 +0300 Ville Syrjala wrote: > From: Ville Syrjälä > > I've talked about making blocking commits lockless a few > times in the past, so here's finally an attempt at it. > The main benefit I see from this is that TEST_ONLY commits > no longer getting blocked on the mutexes by parallel blocking > commits. > > I have a small test here that spools up two threads, > one does just TEST_ONLY commits in a loop, the other > does either blocking or non-blocking page flips. Results > came out as follows on a snb machine here: > > test-only-vs-non-blocking: > -85319 TEST_ONLY commits in 200 usecs, 23 usecs / commit > +87144 TEST_ONLY commits in 206 usecs, 22 usecs / commit > > test-only-vs-blocking: > -219 TEST_ONLY commits in 2001768 usecs, 9140 usecs / commit > +82442 TEST_ONLY commits in 211 usecs, 24 usecs / commit > > Now, I have no idea if anyone actually cares about lack > of parallelism due to locked blocking commits or not. Hence > Cc'd some compositor folks as well. I guess this is more of > an RFC at this point. > > Also curious to see if CI goes up in smoke or not... Hi Ville, thanks for thinking about this. If I understand correctly, the issue you are solving here happens only when a blocking commit is underway while TEST_ONLY commits are done. This can only happen if userspace does the blocking commits from one thread, while another thread is doing TEST_ONLY probing on the same DRM device. It is inconsequential whether the two threads target distinct CRTCs or same CRTCs. If so, this is not a problem for Weston for two reasons: - Weston is fundamentally single-threaded, so if it does use a blocking commit, it's not going to do anything else at the same time. - Weston practically always uses non-blocking commits. I cannot imagine those two facts to change. Ah, but there is a case: KMS leasing! With leasing you have two processes poking distinct CRTCs on the same device at the same time. Even if Weston never blocks, an arbitrary leasing client might, and I presume that would then stall Weston's TEST_ONLY commits. I believe working on optimising this could be useful for KMS leasing use cases, assuming lessees do blocking commits. I don't know if any do. Thanks, pq > > Cc: Daniel Vetter > Cc: Maarten Lankhorst > Cc: Rob Clark > Cc: Simon Ser > Cc: Pekka Paalanen > Cc: Jonas Ådahl > > Ville Syrjälä (4): > drm/atomic: Treat a nonblocking commit following a blocking commit as > blocking commit > drm/i915: Don't reuse commit_work for the cleanup > drm/atomic: Allow lockless blocking commits > drm/i915: Make blocking commits lockless > > drivers/gpu/drm/drm_atomic.c | 32 +-- > drivers/gpu/drm/drm_atomic_helper.c | 19 +++ > drivers/gpu/drm/drm_atomic_uapi.c | 11 +-- > drivers/gpu/drm/i915/display/intel_display.c | 15 +++-- > .../drm/i915/display/intel_display_types.h| 1 + > include/drm/drm_atomic.h | 8 + > 6 files changed, 64 insertions(+), 22 deletions(-) > pgpUla9o_qfMW.pgp Description: OpenPGP digital signature
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/1] drm/i915/mtl: enable local stolen memory
== Series Details == Series: series starting with [1/1] drm/i915/mtl: enable local stolen memory URL : https://patchwork.freedesktop.org/series/108767/ 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.CHECKPATCH: warning for series starting with [1/1] drm/i915/mtl: enable local stolen memory
== Series Details == Series: series starting with [1/1] drm/i915/mtl: enable local stolen memory URL : https://patchwork.freedesktop.org/series/108767/ State : warning == Summary == Error: dim checkpatch failed 7dfaf4034615 drm/i915/mtl: enable local stolen memory -:231: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'i915' - possible side-effects? #231: FILE: drivers/gpu/drm/i915/i915_drv.h:976: +#define HAS_BAR2_SMEM_STOLEN(i915) (!HAS_LMEM(i915) && \ + GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) total: 0 errors, 0 warnings, 1 checks, 193 lines checked
Re: [Intel-gfx] [PATCH 6/6] drm/i915/display: Dump the new cdclk config values
On Fri, 16 Sep 2022, Anusha Srivatsa wrote:
> Add a helper function to get stringify values of the
> desired cdclk action and dump it with rest of the
> cdclk config values
>
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 18 --
> 1 file changed, 16 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index bc627daade3e..12f5e4d23245 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -1688,6 +1688,19 @@ static u32 cdclk_squash_waveform(struct
> drm_i915_private *dev_priv,
>
> return 0x;
> }
> +static const char *cdclk_sequence_to_string(enum cdclk_sequence
> cdclk_sequence)
For any enum foobar, this would be customarily called foobar_name(),
i.e. cdclk_sequence_name(). (Though the enum should probably be renamed
as mentioned earlier.)
> +{
> + switch (cdclk_sequence) {
> + case CDCLK_SQUASH_ONLY:
> + return "Squash only";
> + case CDCLK_CRAWL_ONLY:
> + return "Crawl only";
> + case CDCLK_LEGACY:
> + return "Legacy method";
> + default:
> + return "Not a valid cdclk sequence";
> + }
> +}
>
> static void dg2_prog_squash_ctl(struct drm_i915_private *i915, u16 waveform)
> {
> @@ -2083,10 +2096,11 @@ void intel_cdclk_dump_config(struct drm_i915_private
> *i915,
>const struct intel_cdclk_config *cdclk_config,
>const char *context)
> {
> - drm_dbg_kms(&i915->drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> kHz, voltage level %d\n",
> + drm_dbg_kms(&i915->drm, "%s %d kHz, VCO %d kHz, ref %d kHz, bypass %d
> kHz, voltage level %d, %s action\n",
"%s action" leads to:
Squash only action
Crawl only action
Legacy method action
Not a valid cdclk sequence action
A bit odd perhaps. *shrug*
BR,
Jani.
> context, cdclk_config->cdclk, cdclk_config->vco,
> cdclk_config->ref, cdclk_config->bypass,
> - cdclk_config->voltage_level);
> + cdclk_config->voltage_level,
> + cdclk_sequence_to_string(cdclk_config->steps->action));
> }
>
> /**
--
Jani Nikula, Intel Open Source Graphics Center
Re: [Intel-gfx] [PATCH] drm/i915: fix device info for devices without display
On Mon, Sep 19, 2022 at 11:10:53AM +0300, Jani Nikula wrote:
On Fri, 16 Sep 2022, Lucas De Marchi wrote:
On Fri, Sep 16, 2022 at 11:26:42AM +0300, Jani Nikula wrote:
Commit 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask
to runtime info") moved the pipe_mask member from struct
intel_device_info to intel_runtime_info, but overlooked some of our
platforms initializing device info .display = {}. This is significant,
as pipe_mask is the single point of truth for a device having a display
or not; the platforms in question left pipe_mask to whatever was set for
the platforms they "inherit" from in the complex macro scheme we have.
Add new NO_DISPLAY macro initializing .__runtime.pipe_mask = 0, which
will cause the device info .display sub-struct to be zeroed in
intel_device_info_runtime_init(). A better solution (or simply audit of
proper use of HAS_DISPLAY() checks) is required before moving forward
with [1].
Also clear all the display related members in runtime info if there's no
display. The latter is a bit tedious, but it's for completeness at this
time, to ensure similar functionality as before.
[1]
https://lore.kernel.org/r/dfda1bf67f02ceb07c280b7a13216405fd1f7a34.1660137416.git.jani.nik...@intel.com
Fixes: 00c6cbfd4e8a ("drm/i915: move pipe_mask and cpu_transcoder_mask to runtime
info")
Cc: Lucas De Marchi
Cc: Maarten Lankhort
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_pci.c | 11 ++-
drivers/gpu/drm/i915/intel_device_info.c | 6 ++
2 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 77e7df21f539..cd4487a1d3be 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -41,6 +41,8 @@
.__runtime.media.ip.ver = (x), \
.__runtime.display.ip.ver = (x)
+#define NO_DISPLAY .__runtime.pipe_mask = 0
+
#define I845_PIPE_OFFSETS \
.display.pipe_offsets = { \
[TRANSCODER_A] = PIPE_A_OFFSET, \
@@ -519,9 +521,8 @@ static const struct intel_device_info ivb_m_gt2_info = {
static const struct intel_device_info ivb_q_info = {
GEN7_FEATURES,
PLATFORM(INTEL_IVYBRIDGE),
+ NO_DISPLAY,
.gt = 2,
- .__runtime.pipe_mask = 0, /* legal, last one wins */
- .__runtime.cpu_transcoder_mask = 0,
.has_l3_dpf = 1,
};
@@ -1039,7 +1040,7 @@ static const struct intel_device_info xehpsdv_info = {
XE_HPM_FEATURES,
DGFX_FEATURES,
PLATFORM(INTEL_XEHPSDV),
- .display = { },
+ NO_DISPLAY,
.has_64k_pages = 1,
.needs_compact_pt = 1,
.has_media_ratio_mode = 1,
@@ -1081,7 +1082,7 @@ static const struct intel_device_info dg2_info = {
static const struct intel_device_info ats_m_info = {
DG2_FEATURES,
- .display = { 0 },
+ NO_DISPLAY,
.require_force_probe = 1,
.tuning_thread_rr_after_dep = 1,
};
@@ -1103,7 +1104,7 @@ static const struct intel_device_info pvc_info = {
.__runtime.graphics.ip.rel = 60,
.__runtime.media.ip.rel = 60,
PLATFORM(INTEL_PONTEVECCHIO),
- .display = { 0 },
+ NO_DISPLAY,
.has_flat_ccs = 0,
.__runtime.platform_engine_mask =
BIT(BCS0) |
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 1434dc33cf49..20575eb77ea7 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -433,8 +433,14 @@ void intel_device_info_runtime_init(struct
drm_i915_private *dev_priv)
dev_priv->drm.driver_features &= ~(DRIVER_MODESET |
DRIVER_ATOMIC);
memset(&info->display, 0, sizeof(info->display));
+
+ runtime->cpu_transcoder_mask = 0;
memset(runtime->num_sprites, 0, sizeof(runtime->num_sprites));
memset(runtime->num_scalers, 0, sizeof(runtime->num_scalers));
+ runtime->fbc_mask = 0;
+ runtime->has_hdcp = false;
+ runtime->has_dmc = false;
+ runtime->has_dsc = false;
why are these not inside __runtime.display?
The short answer, because there isn't one. It's an anonymous struct for
now.
/me confused... that doesn't really answer the question. Why would we
not move these inside a display substruct? When moving stuff out of
device_info.display.x, it seems the better place would be inside
__runtime.display.x, not __runtime.x.
I must be missing something here. We had a "recent" move of these flags
lying around in device_info to be inside a display substruct -
commit d53db442db36 ("drm/i915: Move display device info capabilities to its
own struct") - to be able to keep the display flags together
and zero them together.
Lucas De Marchi
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/edid: ignore the CEA modes not defined in CEA-861-D (rev3)
== Series Details ==
Series: drm/edid: ignore the CEA modes not defined in CEA-861-D (rev3)
URL : https://patchwork.freedesktop.org/series/104539/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_12158 -> Patchwork_104539v3
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_104539v3 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_104539v3, 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_104539v3/index.html
Participating hosts (42 -> 39)
--
Missing(3): fi-ctg-p8600 bat-jsl-3 bat-dg1-5
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_104539v3:
### IGT changes ###
Possible regressions
* igt@kms_cursor_legacy@basic-flip-before-cursor@toggle:
- fi-bsw-kefka: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-bsw-kefka/igt@kms_cursor_legacy@basic-flip-before-cur...@toggle.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-bsw-kefka/igt@kms_cursor_legacy@basic-flip-before-cur...@toggle.html
Warnings
* igt@runner@aborted:
- fi-apl-guc: [FAIL][3] ([i915#6599]) -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-apl-guc/igt@run...@aborted.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-apl-guc/igt@run...@aborted.html
- fi-skl-guc: [FAIL][5] ([i915#6599]) -> [FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-skl-guc/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-skl-guc/igt@run...@aborted.html
Known issues
Here are the changes found in Patchwork_104539v3 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@load:
- fi-bdw-gvtdvm: [PASS][7] -> [DMESG-WARN][8] ([i915#6540])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-bdw-gvtdvm/igt@i915_module_l...@load.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-hsw-4770:NOTRUN -> [SKIP][9] ([fdo#109271] / [fdo#111827])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-hsw-4770/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-connector-state:
- fi-bdw-gvtdvm: [PASS][10] -> [DMESG-WARN][11] ([i915#5922])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-bdw-gvtdvm/igt@kms_force_connector_ba...@force-connector-state.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-bdw-gvtdvm/igt@kms_force_connector_ba...@force-connector-state.html
* igt@runner@aborted:
- fi-bdw-gvtdvm: NOTRUN -> [FAIL][12] ([i915#4312])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-bdw-gvtdvm/igt@run...@aborted.html
Possible fixes
* igt@fbdev@write:
- {fi-tgl-mst}: [SKIP][13] ([i915#2582]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-tgl-mst/igt@fb...@write.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-tgl-mst/igt@fb...@write.html
* igt@gem_ctx_create@basic-files:
- {fi-tgl-mst}: [DMESG-WARN][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-tgl-mst/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live@hangcheck:
- fi-hsw-4770:[INCOMPLETE][17] ([i915#4785]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/fi-hsw-4770/igt@i915_selftest@l...@hangcheck.html
* igt@i915_selftest@live@slpc:
- {bat-rpls-1}: [DMESG-FAIL][19] ([i915#6367]) -> [PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/bat-rpls-1/igt@i915_selftest@l...@slpc.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_104539v3/bat-rpls-1/igt@i915_selftest@l...@slpc.html
*
igt@kms_cursor_legacy@basic-busy-flip-before-cursor@atomic-transitions-varying-size:
- fi-bsw-kefka: [FAIL][21] ([i915#6298]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_12158/fi-bsw-kefka/igt@kms_cursor_legacy@basic-busy-flip-before-cur...@atomic-transitions-varying-size.html
[22]:
https://intel-gfx-ci.0
Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper
On Mon, 19 Sep 2022, Gustavo Sousa wrote:
> Make the code more readable, which will be more apparent as new
> platforms with different hotplug inversion needs are added.
>
> Signed-off-by: Gustavo Sousa
> ---
> drivers/gpu/drm/i915/i915_irq.c | 25 -
> 1 file changed, 16 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index de06f293e173..c53d21ae197f 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct
> drm_i915_private *dev_priv)
> spin_unlock_irq(&dev_priv->irq_lock);
> }
>
> +static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
> +{
> + u32 invert_bits;
> +
> + if (HAS_PCH_DG1(dev_priv))
> + invert_bits = INVERT_DDIA_HPD |
> + INVERT_DDIB_HPD |
> + INVERT_DDIC_HPD |
> + INVERT_DDID_HPD;
Nitpick, the indentation will be off compared to automated indentation.
> + else
> + return;
> +
> + intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
> +}
> +
> static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
> enum hpd_pin pin)
> {
> @@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct
> drm_i915_private *i915,
>
> static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
> {
> - u32 val;
> -
> - val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
> - val |= (INVERT_DDIA_HPD |
> - INVERT_DDIB_HPD |
> - INVERT_DDIC_HPD |
> - INVERT_DDID_HPD);
> - intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
> -
> + setup_hotplug_inversion(dev_priv);
Since you're already in a platform specific function here, seems a bit
odd to call a new generic function that needs to have another if ladder
platform check. What are we gaining here? The end result is
de-duplicating just one line of intel_uncore_rmw(). I'm not convinced.
BR,
Jani.
> icp_hpd_irq_setup(dev_priv);
> }
--
Jani Nikula, Intel Open Source Graphics Center
[Intel-gfx] [PATCH 1/1] drm/i915/mtl: enable local stolen memory
As an integrated GPU, MTL does not have local memory and
HAS_LMEM() returns false. However the platform's stolen memory
is presented via BAR2 (i.e., the BAR we traditionally consider
to be the LMEM BAR) and should be managed by the driver the same
way that local memory is on dgpu platforms (which includes
setting the "lmem" bit on page table entries). We use the term
"local stolen memory" to refer to this model.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: CQ Tang
Signed-off-by: Aravind Iddamsetty
Original-author: CQ Tang
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c | 113 +
drivers/gpu/drm/i915/gt/intel_ggtt.c | 2 +-
drivers/gpu/drm/i915/i915_drv.h| 3 +
3 files changed, 100 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index acc561c0f0aa..bad5250fb764 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -77,6 +77,19 @@ void i915_gem_stolen_remove_node(struct drm_i915_private
*i915,
mutex_unlock(&i915->mm.stolen_lock);
}
+static bool is_dsm_invalid(struct drm_i915_private *i915, struct resource *dsm)
+{
+ if (!HAS_BAR2_SMEM_STOLEN(i915)) {
+ if (dsm->start == 0)
+ return true;
+ }
+
+ if (dsm->end <= dsm->start)
+ return true;
+
+ return false;
+}
+
static int i915_adjust_stolen(struct drm_i915_private *i915,
struct resource *dsm)
{
@@ -84,7 +97,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct resource *r;
- if (dsm->start == 0 || dsm->end <= dsm->start)
+ if (is_dsm_invalid(i915, dsm))
return -EINVAL;
/*
@@ -136,7 +149,7 @@ static int i915_adjust_stolen(struct drm_i915_private *i915,
* overlaps with the non-stolen system memory range, since lmem is local
* to the gpu.
*/
- if (HAS_LMEM(i915))
+ if (HAS_LMEM(i915) || HAS_BAR2_SMEM_STOLEN(i915))
return 0;
/*
@@ -371,8 +384,6 @@ static void icl_get_stolen_reserved(struct drm_i915_private
*i915,
drm_dbg(&i915->drm, "GEN6_STOLEN_RESERVED = 0x%016llx\n", reg_val);
- *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
-
switch (reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK) {
case GEN8_STOLEN_RESERVED_1M:
*size = 1024 * 1024;
@@ -390,6 +401,12 @@ static void icl_get_stolen_reserved(struct
drm_i915_private *i915,
*size = 8 * 1024 * 1024;
MISSING_CASE(reg_val & GEN8_STOLEN_RESERVED_SIZE_MASK);
}
+
+ if ((GRAPHICS_VER_FULL(i915) >= IP_VER(12, 70)) && !IS_DGFX(i915))
+ /* the base is initialized to stolen top so subtract size to
get base */
+ *base -= *size;
+ else
+ *base = reg_val & GEN11_STOLEN_RESERVED_ADDR_MASK;
}
static int i915_gem_init_stolen(struct intel_memory_region *mem)
@@ -423,8 +440,7 @@ static int i915_gem_init_stolen(struct intel_memory_region
*mem)
if (i915_adjust_stolen(i915, &i915->dsm))
return 0;
- GEM_BUG_ON(i915->dsm.start == 0);
- GEM_BUG_ON(i915->dsm.end <= i915->dsm.start);
+ GEM_BUG_ON(is_dsm_invalid(i915, &i915->dsm));
stolen_top = i915->dsm.end + 1;
reserved_base = stolen_top;
@@ -796,6 +812,46 @@ static const struct intel_memory_region_ops
i915_region_stolen_lmem_ops = {
.init_object = _i915_gem_object_stolen_init,
};
+static int get_mtl_gms_size(struct intel_uncore *uncore)
+{
+ u16 ggc, gms;
+
+ ggc = intel_uncore_read16(uncore, _MMIO(0x108040));
+
+ /* check GGMS, should be fixed 0x3 (8MB) */
+ if ((ggc & 0xc0) != 0xc0)
+ return -EIO;
+
+ /* return valid GMS value, -EIO if invalid */
+ gms = ggc >> 8;
+ switch (gms) {
+ case 0x0 ... 0x10:
+ return gms * 32;
+ case 0x20:
+ return 1024;
+ case 0x30:
+ return 1536;
+ case 0x40:
+ return 2048;
+ case 0xf0 ... 0xfe:
+ return (gms - 0xf0 + 1) * 4;
+ default:
+ return -EIO;
+ }
+}
+
+static inline bool lmembar_is_igpu_stolen(struct drm_i915_private *i915)
+{
+ u32 regions = RUNTIME_INFO(i915)->memory_regions;
+
+ if (regions & REGION_LMEM)
+ return false;
+
+ drm_WARN_ON(&i915->drm, (regions & REGION_STOLEN_LMEM) == 0);
+
+ return true;
+}
+
struct intel_memory_region *
i915_gem_stolen_lmem_setup(struct drm_i915_private *i915, u16 type,
u16 instance)
@@ -806,19 +862,16 @@ i915_gem_stolen_lmem_setup(struct drm_i915_private *i915,
u16 type,
struct intel_memory_region *mem;
resource_size_t io_start, io_size;
Re: [Intel-gfx] [PATCH] drm/i915: Move hotplug inversion logic into separate helper
On Mon, Sep 19, 2022 at 11:56:59AM -0300, Gustavo Sousa wrote:
Make the code more readable, which will be more apparent as new
platforms with different hotplug inversion needs are added.
Signed-off-by: Gustavo Sousa
---
drivers/gpu/drm/i915/i915_irq.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index de06f293e173..c53d21ae197f 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -3263,6 +3263,21 @@ static void cherryview_irq_reset(struct drm_i915_private
*dev_priv)
spin_unlock_irq(&dev_priv->irq_lock);
}
+static void setup_hotplug_inversion(struct drm_i915_private *dev_priv)
new users of drm_i915_private should use "i915" as variable name rather
than dev_priv.
other than that, Reviewed-by: Lucas De Marchi
Lucas De Marchi
+{
+ u32 invert_bits;
+
+ if (HAS_PCH_DG1(dev_priv))
+ invert_bits = INVERT_DDIA_HPD |
+ INVERT_DDIB_HPD |
+ INVERT_DDIC_HPD |
+ INVERT_DDID_HPD;
+ else
+ return;
+
+ intel_uncore_rmw(&dev_priv->uncore, SOUTH_CHICKEN1, 0, invert_bits);
+}
+
static u32 ibx_hotplug_enables(struct drm_i915_private *i915,
enum hpd_pin pin)
{
@@ -3413,15 +3428,7 @@ static u32 gen11_hotplug_enables(struct drm_i915_private
*i915,
static void dg1_hpd_irq_setup(struct drm_i915_private *dev_priv)
{
- u32 val;
-
- val = intel_uncore_read(&dev_priv->uncore, SOUTH_CHICKEN1);
- val |= (INVERT_DDIA_HPD |
- INVERT_DDIB_HPD |
- INVERT_DDIC_HPD |
- INVERT_DDID_HPD);
- intel_uncore_write(&dev_priv->uncore, SOUTH_CHICKEN1, val);
-
+ setup_hotplug_inversion(dev_priv);
icp_hpd_irq_setup(dev_priv);
}
--
2.37.3
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/edid: ignore the CEA modes not defined in CEA-861-D (rev3)
== Series Details == Series: drm/edid: ignore the CEA modes not defined in CEA-861-D (rev3) URL : https://patchwork.freedesktop.org/series/104539/ State : warning == Summary == Error: dim checkpatch failed 894ed59a7b31 drm/edid: ignore the CEA modes not defined in CEA-861-D -:72: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #72: FILE: drivers/gpu/drm/drm_edid.c:6790: + frame->video_code = drm_mode_cea_vic(connector, mode, + is_hdmi2_sink(connector)); total: 0 errors, 0 warnings, 1 checks, 34 lines checked
