Re: [PATCH v8 07/15] mm/gup: migrate device coherent pages when pinning instead of failing

2022-07-13 Thread Alistair Popple


David Hildenbrand  writes:

> On 07.07.22 21:03, Alex Sierra wrote:
>> From: Alistair Popple 
>>
>> Currently any attempts to pin a device coherent page will fail. This is
>> because device coherent pages need to be managed by a device driver, and
>> pinning them would prevent a driver from migrating them off the device.
>>
>> However this is no reason to fail pinning of these pages. These are
>> coherent and accessible from the CPU so can be migrated just like
>> pinning ZONE_MOVABLE pages. So instead of failing all attempts to pin
>> them first try migrating them out of ZONE_DEVICE.
>>
>> Signed-off-by: Alistair Popple 
>> Acked-by: Felix Kuehling 
>> [hch: rebased to the split device memory checks,
>>   moved migrate_device_page to migrate_device.c]
>> Signed-off-by: Christoph Hellwig 
>> ---
>>  mm/gup.c| 47 +++-
>>  mm/internal.h   |  1 +
>>  mm/migrate_device.c | 53 +
>>  3 files changed, 96 insertions(+), 5 deletions(-)
>>
>> diff --git a/mm/gup.c b/mm/gup.c
>> index b65fe8bf5af4..9b6b9923d22d 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1891,9 +1891,43 @@ static long check_and_migrate_movable_pages(unsigned 
>> long nr_pages,
>>  continue;
>>  prev_folio = folio;
>>
>> -if (folio_is_longterm_pinnable(folio))
>> +/*
>> + * Device private pages will get faulted in during gup so it
>> + * shouldn't be possible to see one here.
>> + */
>> +if (WARN_ON_ONCE(folio_is_device_private(folio))) {
>> +ret = -EFAULT;
>> +goto unpin_pages;
>> +}
>
> I'd just drop that. Device private pages are never part of a present PTE. So 
> if we
> could actually get a grab of one via GUP we would be in bigger trouble ...
> already before this patch.

Fair.

>> +
>> +/*
>> + * Device coherent pages are managed by a driver and should not
>> + * be pinned indefinitely as it prevents the driver moving the
>> + * page. So when trying to pin with FOLL_LONGTERM instead try
>> + * to migrate the page out of device memory.
>> + */
>> +if (folio_is_device_coherent(folio)) {
>> +WARN_ON_ONCE(PageCompound(&folio->page));
>
> Maybe that belongs into migrate_device_page()?

Ok (noting Matthew's comment there as well).

>> +
>> +/*
>> + * Migration will fail if the page is pinned, so convert
>
> [...]
>
>>  /*
>>   * mm/gup.c
>> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
>> index cf9668376c5a..5decd26dd551 100644
>> --- a/mm/migrate_device.c
>> +++ b/mm/migrate_device.c
>> @@ -794,3 +794,56 @@ void migrate_vma_finalize(struct migrate_vma *migrate)
>>  }
>>  }
>>  EXPORT_SYMBOL(migrate_vma_finalize);
>> +
>> +/*
>> + * Migrate a device coherent page back to normal memory.  The caller should 
>> have
>> + * a reference on page which will be copied to the new page if migration is
>> + * successful or dropped on failure.
>> + */
>> +struct page *migrate_device_page(struct page *page, unsigned int gup_flags)
>
> Function name should most probably indicate that we're dealing with coherent 
> pages here?

Ok.

>> +{
>> +unsigned long src_pfn, dst_pfn = 0;
>> +struct migrate_vma args;
>> +struct page *dpage;
>> +
>> +lock_page(page);
>> +src_pfn = migrate_pfn(page_to_pfn(page)) | MIGRATE_PFN_MIGRATE;
>> +args.src = &src_pfn;
>> +args.dst = &dst_pfn;
>> +args.cpages = 1;
>> +args.npages = 1;
>> +args.vma = NULL;
>> +migrate_vma_setup(&args);
>> +if (!(src_pfn & MIGRATE_PFN_MIGRATE))
>> +return NULL;
>
> Wow, these refcount and page locking/unlocking rules with this migrate_* api 
> are
> confusing now. And the usage here of sometimes returning and sometimes falling
> trough don't make it particularly easier to understand here.
>
> I'm not 100% happy about reusing migrate_vma_setup() usage if there *is no 
> VMA*.
> That's just absolutely confusing, because usually migrate_vma_setup() itself
> would do the collection step and ref+lock pages. :/
>
> In general, I can see why/how we're reusing the migrate_vma_* API here, but 
> there
> is absolutely no VMA ... not sure what to improve besides providing a second 
> API
> that does a simple single-page migration. But that can be changed later ...

Yeah, as noted in your other response I think it should be ok to just
call migrate_vma_unmap() directly from migrate_device_page() so I assume
that would adequately deal with this.

>> +
>> +dpage = alloc_pages(GFP_USER | __GFP_NOWARN, 0);
>> +
>
> alloc_page()
>
>> +/*
>> + * get/pin the new page now so we don't have to retry gup after
>> + * migrating. We already have a reference so this should never fail.
>> + */
>> +if (dpage && WARN_ON_ONCE(!try_grab_page(

Re: [PATCH v2 5/7] arm64: dts: qcom: sc7280: Update gpu register list

2022-07-13 Thread Akhil P Oommen

On 7/12/2022 4:57 AM, Doug Anderson wrote:

Hi,

On Fri, Jul 8, 2022 at 11:00 PM Akhil P Oommen  wrote:

Update gpu register array with gpucc memory region.

Signed-off-by: Akhil P Oommen 
---

(no changes since v1)

  arch/arm64/boot/dts/qcom/sc7280.dtsi | 6 --
  1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sc7280.dtsi 
b/arch/arm64/boot/dts/qcom/sc7280.dtsi
index e66fc67..defdb25 100644
--- a/arch/arm64/boot/dts/qcom/sc7280.dtsi
+++ b/arch/arm64/boot/dts/qcom/sc7280.dtsi
@@ -2228,10 +2228,12 @@
 compatible = "qcom,adreno-635.0", "qcom,adreno";
 reg = <0 0x03d0 0 0x4>,
   <0 0x03d9e000 0 0x1000>,
- <0 0x03d61000 0 0x800>;
+ <0 0x03d61000 0 0x800>,
+ <0 0x03d9 0 0x2000>;
 reg-names = "kgsl_3d0_reg_memory",
 "cx_mem",
-   "cx_dbgc";
+   "cx_dbgc",
+   "gpucc";

This doesn't seem right. Shouldn't you be coordinating with the
existing gpucc instead of reaching into its registers?

-Doug
IIUC, qcom gdsc driver doesn't ensure hardware is collapsed since they 
are vote-able switches. Ideally, we should ensure that the hw has 
collapsed for gpu recovery because there could be transient votes from 
other subsystems like hypervisor using their vote register.


I am not sure how complex the plumbing to gpucc driver would be to allow 
gpu driver to check hw status. OTOH, with this patch, gpu driver does a 
read operation on a gpucc register which is in always-on domain. That 
means we don't need to vote any resource to access this register.


Stephen/Rajendra/Taniya, any suggestion?

-Akhil.




Re: [PATCH v8 06/15] mm: remove the vma check in migrate_vma_setup()

2022-07-13 Thread Alistair Popple


David Hildenbrand  writes:

> On 07.07.22 21:03, Alex Sierra wrote:
>> From: Alistair Popple 
>>
>> migrate_vma_setup() checks that a valid vma is passed so that the page
>> tables can be walked to find the pfns associated with a given address
>> range. However in some cases the pfns are already known, such as when
>> migrating device coherent pages during pin_user_pages() meaning a valid
>> vma isn't required.
>
> As raised in my other reply, without a VMA ... it feels odd to use a
> "migrate_vma" API. For an internal (mm/migrate_device.c) use case it is
> ok I guess, but it certainly adds a bit of confusion. For example,
> because migrate_vma_setup() will undo ref+lock not obtained by it.
>
> I guess the interesting point is that
>
> a) Besides migrate_vma_pages() and migrate_vma_setup(), the ->vma is unused.
>
> b) migrate_vma_setup() does collect+unmap+cleanup if unmap failed.
>
> c) With our source page in our hands, we cannot be processing a hole in
> a VMA.
>
>
>
> Not sure if it's better. but I would
>
> a) Enforce in migrate_vma_setup() that there is a VMA. Code outside of
> mm/migrate_device.c shouldn't be doing some hacks like this.
>
> b) Don't call migrate_vma_setup() from migrate_device_page(), but
> directly migrate_vma_unmap() and add a comment.
>
>
> That will leave a single change to this patch (migrate_vma_pages()). But
> is that even required? Because 
>
>> @@ -685,7 +685,7 @@ void migrate_vma_pages(struct migrate_vma *migrate)
>>  continue;
>>  }
>>
>> -if (!page) {
>> +if (!page && migrate->vma) {
>
> How could we ever have !page in case of migrate_device_page()?

Oh good point. This patch was originally part of a larger series I was
working on at the time but you're right - for migrate_device_page() we
should never hit this case. I will respin the next patch (number 7 in
this series) to include this.

> Instead, I think a VM_BUG_ON(migrate->vma); should hold and you can just
> simplify.
>
>>  if (!(migrate->src[i] & MIGRATE_PFN_MIGRATE))
>>  continue;
>>  if (!notified) {


RE: [PATCH v6 07/10] drm/bridge: add psr support for panel bridge callbacks

2022-07-13 Thread Vinod Polimera
Gentle reminder to review this patch.

Thanks,
Vinod P.

> -Original Message-
> From: Vinod Polimera 
> Sent: Monday, July 11, 2022 6:27 PM
> To: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
> Cc: Vinod Polimera (QUIC) ; linux-
> ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> swb...@chromium.org; Kalyan Thota (QUIC) ;
> dmitry.barysh...@linaro.org; Kuogee Hsieh (QUIC)
> ; Vishnuvardhan Prodduturi (QUIC)
> ; bjorn.anders...@linaro.org; Aravind
> Venkateswaran (QUIC) ; Abhinav Kumar
> (QUIC) ; Sankeerth Billakanti (QUIC)
> 
> Subject: [PATCH v6 07/10] drm/bridge: add psr support for panel bridge
> callbacks
> 
> This change will handle the psr entry exit cases in the panel
> bridge atomic callback functions. For example, the panel power
> should not turn off if the panel is entering psr.
> 
> Signed-off-by: Sankeerth Billakanti 
> Signed-off-by: Vinod Polimera 
> ---
>  drivers/gpu/drm/bridge/panel.c | 48
> ++
>  1 file changed, 48 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/panel.c
> b/drivers/gpu/drm/bridge/panel.c
> index eeb9546..9770b8c 100644
> --- a/drivers/gpu/drm/bridge/panel.c
> +++ b/drivers/gpu/drm/bridge/panel.c
> @@ -112,6 +112,18 @@ static void panel_bridge_atomic_pre_enable(struct
> drm_bridge *bridge,
>   struct drm_bridge_state *old_bridge_state)
>  {
>   struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state-
> >base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *old_crtc_state;
> +
> + crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state,
> encoder);
> + if (!crtc)
> + return;
> +
> + old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state,
> crtc);
> + if (old_crtc_state && old_crtc_state->self_refresh_active)
> + return;
> 
>   drm_panel_prepare(panel_bridge->panel);
>  }
> @@ -120,6 +132,18 @@ static void panel_bridge_atomic_enable(struct
> drm_bridge *bridge,
>   struct drm_bridge_state *old_bridge_state)
>  {
>   struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state-
> >base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *old_crtc_state;
> +
> + crtc = drm_atomic_get_new_crtc_for_encoder(atomic_state,
> encoder);
> + if (!crtc)
> + return;
> +
> + old_crtc_state = drm_atomic_get_old_crtc_state(atomic_state,
> crtc);
> + if (old_crtc_state && old_crtc_state->self_refresh_active)
> + return;
> 
>   drm_panel_enable(panel_bridge->panel);
>  }
> @@ -128,6 +152,18 @@ static void panel_bridge_atomic_disable(struct
> drm_bridge *bridge,
>   struct drm_bridge_state *old_bridge_state)
>  {
>   struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state-
> >base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> +
> + crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state,
> encoder);
> + if (!crtc)
> + return;
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state,
> crtc);
> + if (new_crtc_state && new_crtc_state->self_refresh_active)
> + return;
> 
>   drm_panel_disable(panel_bridge->panel);
>  }
> @@ -136,6 +172,18 @@ static void panel_bridge_atomic_post_disable(struct
> drm_bridge *bridge,
>   struct drm_bridge_state *old_bridge_state)
>  {
>   struct panel_bridge *panel_bridge =
> drm_bridge_to_panel_bridge(bridge);
> + struct drm_atomic_state *atomic_state = old_bridge_state-
> >base.state;
> + struct drm_encoder *encoder = bridge->encoder;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *new_crtc_state;
> +
> + crtc = drm_atomic_get_old_crtc_for_encoder(atomic_state,
> encoder);
> + if (!crtc)
> + return;
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(atomic_state,
> crtc);
> + if (new_crtc_state && new_crtc_state->self_refresh_active)
> + return;
> 
>   drm_panel_unprepare(panel_bridge->panel);
>  }
> --
> 2.7.4



RE: [PATCH v6 01/10] drm/msm/disp/dpu: clear dpu_assign_crtc and get crtc from connector state instead of dpu_enc

2022-07-13 Thread Vinod Polimera
Gentle reminder to review this patch.

Thanks,
Vinod P.

> -Original Message-
> From: Vinod Polimera 
> Sent: Monday, July 11, 2022 6:27 PM
> To: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
> Cc: Vinod Polimera (QUIC) ; linux-
> ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> swb...@chromium.org; Kalyan Thota (QUIC) ;
> dmitry.barysh...@linaro.org; Kuogee Hsieh (QUIC)
> ; Vishnuvardhan Prodduturi (QUIC)
> ; bjorn.anders...@linaro.org; Aravind
> Venkateswaran (QUIC) ; Abhinav Kumar
> (QUIC) ; Sankeerth Billakanti (QUIC)
> 
> Subject: [PATCH v6 01/10] drm/msm/disp/dpu: clear dpu_assign_crtc and get
> crtc from connector state instead of dpu_enc
> 
> Update crtc retrieval from dpu_enc to dpu_enc connector state,
> since new links get set as part of the dpu enc virt mode set.
> The dpu_enc->crtc cache is no more needed, hence cleaning it as
> part of this change.
> 
> Signed-off-by: Vinod Polimera 
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c|  4 
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 30 ++
> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.h |  8 
>  3 files changed, 14 insertions(+), 28 deletions(-)
> 
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> index b56f777..f91e3d1 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_crtc.c
> @@ -972,7 +972,6 @@ static void dpu_crtc_disable(struct drm_crtc *crtc,
>*/
>   if (dpu_encoder_get_intf_mode(encoder) ==
> INTF_MODE_VIDEO)
>   release_bandwidth = true;
> - dpu_encoder_assign_crtc(encoder, NULL);
>   }
> 
>   /* wait for frame_event_done completion */
> @@ -1042,9 +1041,6 @@ static void dpu_crtc_enable(struct drm_crtc *crtc,
>   trace_dpu_crtc_enable(DRMID(crtc), true, dpu_crtc);
>   dpu_crtc->enabled = true;
> 
> - drm_for_each_encoder_mask(encoder, crtc->dev, crtc->state-
> >encoder_mask)
> - dpu_encoder_assign_crtc(encoder, crtc);
> -
>   /* Enable/restore vblank irq handling */
>   drm_crtc_vblank_on(crtc);
>  }
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> index 52516eb..0fddc9d 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
> @@ -181,7 +181,6 @@ struct dpu_encoder_virt {
> 
>   bool intfs_swapped;
> 
> - struct drm_crtc *crtc;
>   struct drm_connector *connector;
> 
>   struct dentry *debugfs_root;
> @@ -1245,6 +1244,7 @@ static void dpu_encoder_vblank_callback(struct
> drm_encoder *drm_enc,
>   struct dpu_encoder_phys *phy_enc)
>  {
>   struct dpu_encoder_virt *dpu_enc = NULL;
> + struct drm_crtc *crtc;
>   unsigned long lock_flags;
> 
>   if (!drm_enc || !phy_enc)
> @@ -1253,9 +1253,14 @@ static void dpu_encoder_vblank_callback(struct
> drm_encoder *drm_enc,
>   DPU_ATRACE_BEGIN("encoder_vblank_callback");
>   dpu_enc = to_dpu_encoder_virt(drm_enc);
> 
> + if (!dpu_enc->connector || !dpu_enc->connector->state)
> + return;
> +
> + crtc = dpu_enc->connector->state->crtc;
> +
>   spin_lock_irqsave(&dpu_enc->enc_spinlock, lock_flags);
> - if (dpu_enc->crtc)
> - dpu_crtc_vblank_callback(dpu_enc->crtc);
> + if (crtc)
> + dpu_crtc_vblank_callback(crtc);
>   spin_unlock_irqrestore(&dpu_enc->enc_spinlock, lock_flags);
> 
>   atomic_inc(&phy_enc->vsync_cnt);
> @@ -1280,29 +1285,22 @@ static void
> dpu_encoder_underrun_callback(struct drm_encoder *drm_enc,
>   DPU_ATRACE_END("encoder_underrun_callback");
>  }
> 
> -void dpu_encoder_assign_crtc(struct drm_encoder *drm_enc, struct
> drm_crtc *crtc)
> -{
> - struct dpu_encoder_virt *dpu_enc =
> to_dpu_encoder_virt(drm_enc);
> - unsigned long lock_flags;
> -
> - spin_lock_irqsave(&dpu_enc->enc_spinlock, lock_flags);
> - /* crtc should always be cleared before re-assigning */
> - WARN_ON(crtc && dpu_enc->crtc);
> - dpu_enc->crtc = crtc;
> - spin_unlock_irqrestore(&dpu_enc->enc_spinlock, lock_flags);
> -}
> -
>  void dpu_encoder_toggle_vblank_for_crtc(struct drm_encoder *drm_enc,
>   struct drm_crtc *crtc, bool enable)
>  {
>   struct dpu_encoder_virt *dpu_enc =
> to_dpu_encoder_virt(drm_enc);
> + struct drm_crtc *new_crtc;
>   unsigned long lock_flags;
>   int i;
> 
>   trace_dpu_enc_vblank_cb(DRMID(drm_enc), enable);
> 
> + if (!dpu_enc->connector || !dpu_enc->connector->state)
> + return;
> +
> + new_crtc = dpu_enc->connector->state->crtc;
>   spin_lock_irqsave(&dpu_enc->enc_spinlock, lock_flags);
> - if (dpu_enc->crtc != crtc) {
> + if (!new_crtc || new_crtc != crtc) {
>   spin_unlock_ir

RE: [PATCH v6 02/10] drm: add helper functions to retrieve old and new crtc

2022-07-13 Thread Vinod Polimera
Gentle reminder to review this patch.

Thanks,
Vinod P.

> -Original Message-
> From: Vinod Polimera 
> Sent: Monday, July 11, 2022 6:27 PM
> To: dri-devel@lists.freedesktop.org; linux-arm-...@vger.kernel.org;
> freedr...@lists.freedesktop.org; devicet...@vger.kernel.org
> Cc: Vinod Polimera (QUIC) ; linux-
> ker...@vger.kernel.org; robdcl...@gmail.com; diand...@chromium.org;
> swb...@chromium.org; Kalyan Thota (QUIC) ;
> dmitry.barysh...@linaro.org; Kuogee Hsieh (QUIC)
> ; Vishnuvardhan Prodduturi (QUIC)
> ; bjorn.anders...@linaro.org; Aravind
> Venkateswaran (QUIC) ; Abhinav Kumar
> (QUIC) ; Sankeerth Billakanti (QUIC)
> 
> Subject: [PATCH v6 02/10] drm: add helper functions to retrieve old and new
> crtc
> 
> Add new helper functions, drm_atomic_get_old_crtc_for_encoder
> and drm_atomic_get_new_crtc_for_encoder to retrieve the
> corresponding crtc for the encoder.
> 
> Signed-off-by: Sankeerth Billakanti 
> Signed-off-by: Vinod Polimera 
> ---
>  drivers/gpu/drm/drm_atomic.c | 60
> 
>  include/drm/drm_atomic.h |  7 ++
>  2 files changed, 67 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 58c0283..87fcb55 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -983,6 +983,66 @@
> drm_atomic_get_new_connector_for_encoder(struct drm_atomic_state
> *state,
>  EXPORT_SYMBOL(drm_atomic_get_new_connector_for_encoder);
> 
>  /**
> + * drm_atomic_get_old_crtc_for_encoder - Get old crtc for an encoder
> + * @state: Atomic state
> + * @encoder: The encoder to fetch the crtc state for
> + *
> + * This function finds and returns the crtc that was connected to @encoder
> + * as specified by the @state.
> + *
> + * Returns: The old crtc connected to @encoder, or NULL if the encoder is
> + * not connected.
> + */
> +struct drm_crtc *
> +drm_atomic_get_old_crtc_for_encoder(struct drm_atomic_state *state,
> + struct drm_encoder *encoder)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> +
> + connector = drm_atomic_get_old_connector_for_encoder(state,
> encoder);
> + if (!connector)
> + return NULL;
> +
> + conn_state = drm_atomic_get_old_connector_state(state,
> connector);
> + if (!conn_state)
> + return NULL;
> +
> + return conn_state->crtc;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_old_crtc_for_encoder);
> +
> +/**
> + * drm_atomic_get_new_crtc_for_encoder - Get new crtc for an encoder
> + * @state: Atomic state
> + * @encoder: The encoder to fetch the crtc state for
> + *
> + * This function finds and returns the crtc that will be connected to
> @encoder
> + * as specified by the @state.
> + *
> + * Returns: The new crtc connected to @encoder, or NULL if the encoder is
> + * not connected.
> + */
> +struct drm_crtc *
> +drm_atomic_get_new_crtc_for_encoder(struct drm_atomic_state *state,
> + struct drm_encoder *encoder)
> +{
> + struct drm_connector *connector;
> + struct drm_connector_state *conn_state;
> +
> + connector = drm_atomic_get_new_connector_for_encoder(state,
> encoder);
> + if (!connector)
> + return NULL;
> +
> + conn_state = drm_atomic_get_new_connector_state(state,
> connector);
> + if (!conn_state)
> + return NULL;
> +
> + return conn_state->crtc;
> +}
> +EXPORT_SYMBOL(drm_atomic_get_new_crtc_for_encoder);
> +
> +/**
>   * drm_atomic_get_connector_state - get connector state
>   * @state: global atomic state object
>   * @connector: connector to get state object for
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 025..7001f12 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -528,6 +528,13 @@ struct drm_connector *
>  drm_atomic_get_new_connector_for_encoder(struct drm_atomic_state
> *state,
>struct drm_encoder *encoder);
> 
> +struct drm_crtc *
> +drm_atomic_get_old_crtc_for_encoder(struct drm_atomic_state *state,
> +  struct drm_encoder *encoder);
> +struct drm_crtc *
> +drm_atomic_get_new_crtc_for_encoder(struct drm_atomic_state *state,
> +  struct drm_encoder *encoder);
> +
>  /**
>   * drm_atomic_get_existing_crtc_state - get CRTC state, if it exists
>   * @state: global atomic state object
> --
> 2.7.4



Re: [PATCH v2 07/39] drm/i915: gvt: fix kernel-doc trivial warnings

2022-07-13 Thread Zhenyu Wang
On 2022.07.13 09:11:55 +0100, Mauro Carvalho Chehab wrote:
> Some functions seem to have been renamed without updating the kernel-doc
> markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
> properly documented, but has a kerneld-doc markup.
> 
> Fix those warnings:
>   drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting 
> prototype for inte_gvt_free_vgpu_resource(). Prototype was for 
> intel_vgpu_free_resource() instead
>   drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting 
> prototype for intel_alloc_vgpu_resource(). Prototype was for 
> intel_vgpu_alloc_resource() instead
>   drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype 
> for intel_vgpu_emulate_cfg_read(). Prototype was for 
> intel_vgpu_emulate_cfg_write() instead
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'info' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'kref' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'initref' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'list' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype 
> for intel_t_default_mmio_write(). Prototype was for 
> intel_vgpu_default_mmio_write() instead
>   drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting 
> prototype for intel_gvt_switch_render_mmio(). Prototype was for 
> intel_gvt_switch_mmio() instead
>   drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype 
> for intel_vgpu_enable_page_track(). Prototype was for 
> intel_vgpu_disable_page_track() instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for 
> intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for 
> intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() 
> instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for 
> intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() 
> instead
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gvt/cfg_space.c  | 2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
>  drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c   | 6 +++---
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
> b/drivers/gpu/drm/i915/gvt/cfg_space.c
> index dad3a6054335..a0fc6d356588 100644
> --- a/drivers/gpu/drm/i915/gvt/cfg_space.c
> +++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
> @@ -243,7 +243,7 @@ static void emulate_pci_bar_write(struct intel_vgpu 
> *vgpu, unsigned int offset,
>  }
>  
>  /**
> - * intel_vgpu_emulate_cfg_read - emulate vGPU configuration space write
> + * intel_vgpu_emulate_cfg_write - emulate vGPU configuration space write
>   * @vgpu: target vgpu
>   * @offset: offset
>   * @p_data: write data ptr
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h 
> b/drivers/gpu/drm/i915/gvt/dmabuf.h
> index 5f8f03fb1d1b..3dcdb6570eda 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.h
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
> @@ -48,7 +48,7 @@ struct intel_vgpu_fb_info {
>   struct intel_vgpu_dmabuf_obj *obj;
>  };
>  
> -/**
> +/*
>   * struct intel_vgpu_dmabuf_obj- Intel vGPU device buffer object
>   */
>  struct intel_vgpu_dmabuf_obj {
> diff --git a/drivers/gpu/drm/i915/gvt/page_track.c 
> b/drivers/gpu/drm/i915/gvt/page_track.c
> index 3375b51c75f1..df34e73cba41 100644
> --- a/drivers/gpu/drm/i915/gvt/page_track.c
> +++ b/drivers/gpu/drm/i915/gvt/page_track.c
> @@ -120,7 +120,7 @@ int intel_vgpu_enable_page_track(struct intel_vgpu *vgpu, 
> unsigned long gfn)
>  }
>  
>  /**
> - * intel_vgpu_enable_page_track - cancel write-protection on guest page
> + * intel_vgpu_disable_page_track - cancel write-protection on guest page
>   * @vgpu: a vGPU
>   * @gfn: the gfn of guest page
>   *
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index 46da19b3225d..8e71cda19995 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -205,7 +205,7 @@ static void intel_gvt_update_vgpu_types(struct intel_gvt

RE: [PATCH v3 3/3] drm/i915/display: add hotplug.suspended flag

2022-07-13 Thread Murthy, Arun R
> -Original Message-
> From: Hajda, Andrzej 
> Sent: Wednesday, July 13, 2022 8:50 PM
> To: Jani Nikula ; Ville Syrjälä
> ; Murthy, Arun R 
> Cc: Hajda, Andrzej ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; Daniel Vetter
> ; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH v3 3/3] drm/i915/display: add hotplug.suspended flag
> 
> HPD events during driver removal can be generated by hardware and
> software frameworks - drm_dp_mst, the former we can avoid by disabling
> interrupts, the latter can be triggered by any drm_dp_mst transaction, and
> this is too late. Introducing suspended flag allows to solve this chicken-egg
> problem.
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
> Signed-off-by: Andrzej Hajda 
> ---
Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy



RE: [PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev unregistration

2022-07-13 Thread Murthy, Arun R
> -Original Message-
> From: Hajda, Andrzej 
> Sent: Wednesday, July 13, 2022 8:50 PM
> To: Jani Nikula ; Ville Syrjälä
> ; Murthy, Arun R 
> Cc: Hajda, Andrzej ; Joonas Lahtinen
> ; Vivi, Rodrigo ;
> Tvrtko Ursulin ; Daniel Vetter
> ; intel-...@lists.freedesktop.org; dri-
> de...@lists.freedesktop.org
> Subject: [PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev
> unregistration
> 
> HPD event after fbdev unregistration can cause registration of deferred fbdev
> which will not be unregistered later, causing use-after-free.
> To avoid it HPD handling should be suspended before fbdev unregistration.
> 
> It should fix following GPF:
> [272.634530] general protection fault, probably for non-canonical address
> 0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
> [272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
> 5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
> [272.634541] Hardware name: Intel Corporation Raptor Lake Client
> Platform/RPL-S ADP-S DDR5 UDIMM CRB, BIOS
> RPLSFWI1.R00.2397.A01.2109300731 09/30/2021 [272.634545] RIP:
> 0010:fb_do_apertures_overlap.part.14+0x26/0x60
> ...
> [272.634582] Call Trace:
> [272.634583]  
> [272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
> [272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
> [272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
> [272.634595]
> drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
> [272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]
> 
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
> Signed-off-by: Andrzej Hajda 
> ---
Reviewed-by: Arun R Murthy 

Thanks and Regards,
Arun R Murthy



[linux-next:master] BUILD REGRESSION 4662b7adea50bb62e993a67f611f3be625d3df0d

2022-07-13 Thread kernel test robot
tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 4662b7adea50bb62e993a67f611f3be625d3df0d  Add linux-next specific 
files for 20220713

Error/Warning reports:

https://lore.kernel.org/linux-doc/202207021352.ppktuy8v-...@intel.com
https://lore.kernel.org/linux-doc/202207031437.qih6lfcx-...@intel.com
https://lore.kernel.org/linux-doc/202207051821.3f0erisl-...@intel.com
https://lore.kernel.org/linux-doc/202207140742.gtpk4u8i-...@intel.com
https://lore.kernel.org/linux-mm/202206292052.lsfui3zo-...@intel.com
https://lore.kernel.org/linux-mm/202207140042.ck3tlk6j-...@intel.com
https://lore.kernel.org/llvm/202207090100.acxdj79h-...@intel.com

Error/Warning: (recently discovered and may have been fixed)

Documentation/PCI/endpoint/pci-vntb-function.rst:82: WARNING: Unexpected 
indentation.
Documentation/PCI/endpoint/pci-vntb-howto.rst:131: WARNING: Title underline too 
short.
Documentation/filesystems/netfs_library.rst:384: WARNING: Inline emphasis 
start-string without end-string.
Documentation/filesystems/netfs_library:609: fs/netfs/buffered_read.c:318: 
WARNING: Inline emphasis start-string without end-string.
Documentation/virt/kvm/api.rst:8256: WARNING: Title underline too short.
Documentation/virt/kvm/api.rst:8263: WARNING: Unexpected indentation.
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:2837:6: warning: no previous 
prototype for function 'dc_reset_state' [-Wmissing-prototypes]
drivers/mmc/host/sdhci-of-aspeed-test.c:10: undefined reference to 
`kunit_binary_assert_format'
drivers/pci/endpoint/functions/pci-epf-vntb.c:975:5: warning: no previous 
prototype for 'pci_read' [-Wmissing-prototypes]
drivers/pci/endpoint/functions/pci-epf-vntb.c:984:5: warning: no previous 
prototype for 'pci_write' [-Wmissing-prototypes]
drivers/vfio/vfio_iommu_type1.c:2141:35: warning: cast to smaller integer type 
'enum iommu_cap' from 'void *' [-Wvoid-pointer-to-enum-cast]
fs/ntfs/attrib.c:705:18: warning: Either the condition '!al' is redundant or 
there is pointer arithmetic with NULL pointer. 
[nullPointerArithmeticRedundantCheck]
fs/ntfs/layout.h:126:43: warning: Parameter 'p' can be declared with const 
[constParameter]
fs/ntfs/ntfs.h:144:3: warning: Assignment of function parameter has no effect 
outside the function. [uselessAssignmentArg]
fs/super.c:1310:57: warning: Parameter 'data' can be declared with const 
[constParameter]
fs/super.c:750:52: warning: Parameter 'bdev' can be declared with const 
[constParameter]
ipc/shm.c:158:0: warning: failed to expand 'ipc_init_proc_interface', it is 
invalid to use a preprocessor directive as macro parameter 
[preprocessorErrorDirective]
kernel/bpf/task_iter.c:152:11: warning: Redundant initialization for 'curr_fd'. 
The initialized value is overwritten before it is read. 
[redundantInitialization]
kernel/bpf/task_iter.c:498:59: warning: Parameter 'v' can be declared with 
const [constParameter]
kernel/fork.c:3256:42: warning: Parameter 'table' can be declared with const 
[constParameter]
kernel/fork.c:942:33: warning: Parameter 'src' can be declared with const 
[constParameter]
kernel/sched/fair.c:5081:25: warning: Uninitialized variables: cfs_rq.load, 
cfs_rq.nr_running, cfs_rq.h_nr_running, cfs_rq.idle_nr_running, 
cfs_rq.idle_h_nr_running, cfs_rq.exec_clock, cfs_rq.min_vruntime, 
cfs_rq.min_vruntime_copy, cfs_rq.tasks_timeline, cfs_rq.curr, cfs_rq.next, 
cfs_rq.last, cfs_rq.skip [uninitvar]
kernel/sched/fair.c:6967:7: warning: Local variable 'min_vruntime' shadows 
outer function [shadowFunction]
lib/maple_tree.c:1522:52: warning: Parameter 'gaps' can be declared with const 
[constParameter]
lib/maple_tree.c:1871:21: warning: Array index 'split' is used before limits 
check. [arrayIndexThenCheck]
lib/maple_tree.c:2033:55: warning: Parameter 'mas' can be declared with const 
[constParameter]
lib/maple_tree.c:2426:8: warning: Redundant initialization for 'r_tmp'. The 
initialized value is overwritten before it is read. [redundantInitialization]
lib/maple_tree.c:2427:8: warning: Redundant initialization for 'l_tmp'. The 
initialized value is overwritten before it is read. [redundantInitialization]
lib/maple_tree.c:3160:22: warning: Found suspicious operator ',' 
[constStatement]
lib/maple_tree.c:3208:11: warning: Size of pointer 'pivs' used instead of size 
of its data. [pointerSize]
lib/maple_tree.c:326:2: warning: Assignment of function parameter has no effect 
outside the function. Did you forget dereferencing it? [uselessAssignmentPtrArg]
lib/maple_tree.c:4266:15: warning: The if condition is the same as the previous 
if condition [duplicateCondition]
lib/maple_tree.c:4302:23: warning: Boolean result is used in bitwise operation. 
Clarify expression with parentheses. [clarifyCondition]

Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Alex Deucher
On Wed, Jul 13, 2022 at 7:09 PM Guenter Roeck  wrote:
>
> On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
> > >
> > > The problem is not the FPU operations, but the fact that soft-float
> > > and hard-float compiled code is linked together. The soft-float and
> > > hard-float ABIs on powerpc are not compatible, so one ends up with
> > > an object file which is partially soft-float and partially hard-float
> > > compiled and thus uses different ABIs. That can only create chaos,
> > > so the linker complains about it.
> >
> > I get that, I just don't see why only DCN 3.1.x files have this
> > problem.  The DCN 2.x files should as well.
> >
>
> Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile:
>
> # prevent build errors regarding soft-float vs hard-float FP ABI tags
> # this code is currently unused on ppc64, as it applies to Renoir APUs only
> ifdef CONFIG_PPC64
> CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
> cc-option,-mno-gnu-attribute)
> endif
>
> Does that explain it ?

I would expect to see it in dcn20_resource.c and dcn30_clk_mgr.c for
example.  They follow the same pattern as the dcn 3.1.x files.  They
call functions that use FP, but maybe there is some FP code still in
those functions that we missed somehow.

Alex


Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Guenter Roeck
On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
> >
> > The problem is not the FPU operations, but the fact that soft-float
> > and hard-float compiled code is linked together. The soft-float and
> > hard-float ABIs on powerpc are not compatible, so one ends up with
> > an object file which is partially soft-float and partially hard-float
> > compiled and thus uses different ABIs. That can only create chaos,
> > so the linker complains about it.
> 
> I get that, I just don't see why only DCN 3.1.x files have this
> problem.  The DCN 2.x files should as well.
> 

Seen in drivers/gpu/drm/amd/display/dc/clk_mgr/Makefile:

# prevent build errors regarding soft-float vs hard-float FP ABI tags
# this code is currently unused on ppc64, as it applies to Renoir APUs only
ifdef CONFIG_PPC64
CFLAGS_$(AMDDALPATH)/dc/clk_mgr/dcn21/rn_clk_mgr.o := $(call 
cc-option,-mno-gnu-attribute)
endif

Does that explain it ?

Guenter


Re: [Intel-gfx] [PATCH v2 09/39] drm/i915: intel_wakeref.h: fix some kernel-doc markups

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:57AM +0100, Mauro Carvalho Chehab wrote:
> Two documented functions don't match the kernel-doc comments,
> as reported by kernel-doc:
> 
>   drivers/gpu/drm/i915/intel_wakeref.h:117: warning: expecting prototype 
> for intel_wakeref_get_if_in_use(). Prototype was for 
> intel_wakeref_get_if_active() instead
>   drivers/gpu/drm/i915/intel_wakeref.h:149: warning: expecting prototype 
> for intel_wakeref_put_flags(). Prototype was for __intel_wakeref_put() instead
> 
> Fix them.
> 
> Additionally, improve title for intel_wakeref_get_if_active().
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/intel_wakeref.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_wakeref.h 
> b/drivers/gpu/drm/i915/intel_wakeref.h
> index 4f4c2e15e736..63e539c9b1f3 100644
> --- a/drivers/gpu/drm/i915/intel_wakeref.h
> +++ b/drivers/gpu/drm/i915/intel_wakeref.h
> @@ -104,7 +104,7 @@ __intel_wakeref_get(struct intel_wakeref *wf)
>  }
>  
>  /**
> - * intel_wakeref_get_if_in_use: Acquire the wakeref
> + * intel_wakeref_get_if_active: Acquire the wakeref if active
>   * @wf: the wakeref
>   *
>   * Acquire a hold on the wakeref, but only if the wakeref is already
> @@ -130,7 +130,7 @@ intel_wakeref_might_get(struct intel_wakeref *wf)
>  }
>  
>  /**
> - * intel_wakeref_put_flags: Release the wakeref
> + * __intel_wakeref_put: Release the wakeref
>   * @wf: the wakeref
>   * @flags: control flags
>   *
> -- 
> 2.36.1
> 


Re: [PATCH v2 07/39] drm/i915: gvt: fix kernel-doc trivial warnings

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:55AM +0100, Mauro Carvalho Chehab wrote:
> Some functions seem to have been renamed without updating the kernel-doc
> markup causing warnings. Also, struct intel_vgpu_dmabuf_obj is not
> properly documented, but has a kerneld-doc markup.
> 
> Fix those warnings:
>   drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting 
> prototype for inte_gvt_free_vgpu_resource(). Prototype was for 
> intel_vgpu_free_resource() instead
>   drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting 
> prototype for intel_alloc_vgpu_resource(). Prototype was for 
> intel_vgpu_alloc_resource() instead
>   drivers/gpu/drm/i915/gvt/cfg_space.c:257: warning: expecting prototype 
> for intel_vgpu_emulate_cfg_read(). Prototype was for 
> intel_vgpu_emulate_cfg_write() instead
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'vgpu' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'info' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'dmabuf_id' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'kref' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'initref' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/dmabuf.h:61: warning: Function parameter or 
> member 'list' not described in 'intel_vgpu_dmabuf_obj'
>   drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype 
> for intel_t_default_mmio_write(). Prototype was for 
> intel_vgpu_default_mmio_write() instead
>   drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting 
> prototype for intel_gvt_switch_render_mmio(). Prototype was for 
> intel_gvt_switch_mmio() instead
>   drivers/gpu/drm/i915/gvt/page_track.c:131: warning: expecting prototype 
> for intel_vgpu_enable_page_track(). Prototype was for 
> intel_vgpu_disable_page_track() instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:215: warning: expecting prototype for 
> intel_gvt_active_vgpu(). Prototype was for intel_gvt_activate_vgpu() instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:230: warning: expecting prototype for 
> intel_gvt_deactive_vgpu(). Prototype was for intel_gvt_deactivate_vgpu() 
> instead
>   drivers/gpu/drm/i915/gvt/vgpu.c:358: warning: expecting prototype for 
> intel_gvt_destroy_vgpu(). Prototype was for intel_gvt_destroy_idle_vgpu() 
> instead
> 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gvt/cfg_space.c  | 2 +-
>  drivers/gpu/drm/i915/gvt/dmabuf.h | 2 +-
>  drivers/gpu/drm/i915/gvt/page_track.c | 2 +-
>  drivers/gpu/drm/i915/gvt/vgpu.c   | 6 +++---
>  4 files changed, 6 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cfg_space.c 
> b/drivers/gpu/drm/i915/gvt/cfg_space.c
> index dad3a6054335..a0fc6d356588 100644
> --- a/drivers/gpu/drm/i915/gvt/cfg_space.c
> +++ b/drivers/gpu/drm/i915/gvt/cfg_space.c
> @@ -243,7 +243,7 @@ static void emulate_pci_bar_write(struct intel_vgpu 
> *vgpu, unsigned int offset,
>  }
>  
>  /**
> - * intel_vgpu_emulate_cfg_read - emulate vGPU configuration space write
> + * intel_vgpu_emulate_cfg_write - emulate vGPU configuration space write
>   * @vgpu: target vgpu
>   * @offset: offset
>   * @p_data: write data ptr
> diff --git a/drivers/gpu/drm/i915/gvt/dmabuf.h 
> b/drivers/gpu/drm/i915/gvt/dmabuf.h
> index 5f8f03fb1d1b..3dcdb6570eda 100644
> --- a/drivers/gpu/drm/i915/gvt/dmabuf.h
> +++ b/drivers/gpu/drm/i915/gvt/dmabuf.h
> @@ -48,7 +48,7 @@ struct intel_vgpu_fb_info {
>   struct intel_vgpu_dmabuf_obj *obj;
>  };
>  
> -/**
> +/*
>   * struct intel_vgpu_dmabuf_obj- Intel vGPU device buffer object
>   */
>  struct intel_vgpu_dmabuf_obj {
> diff --git a/drivers/gpu/drm/i915/gvt/page_track.c 
> b/drivers/gpu/drm/i915/gvt/page_track.c
> index 3375b51c75f1..df34e73cba41 100644
> --- a/drivers/gpu/drm/i915/gvt/page_track.c
> +++ b/drivers/gpu/drm/i915/gvt/page_track.c
> @@ -120,7 +120,7 @@ int intel_vgpu_enable_page_track(struct intel_vgpu *vgpu, 
> unsigned long gfn)
>  }
>  
>  /**
> - * intel_vgpu_enable_page_track - cancel write-protection on guest page
> + * intel_vgpu_disable_page_track - cancel write-protection on guest page
>   * @vgpu: a vGPU
>   * @gfn: the gfn of guest page
>   *
> diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
> index 46da19b3225d..8e71cda19995 100644
> --- a/drivers/gpu/drm/i915/gvt/vgpu.c
> +++ b/drivers/gpu/drm/i915/gvt/vgpu.c
> @@ -205,7 +205,7 @@ static void int

Re: [Intel-gfx] [PATCH v2 06/39] drm/i915: gt: fix some Kernel-doc issues

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:54AM +0100, Mauro Carvalho Chehab wrote:
> There are several trivial warnings there, due to trivial things:
>   - lack of function name at the kerneldoc markup;
>   - undocumented structs with kernel-doc markups;
>   - wrong parameter syntax.
> 
> Fix such warnings:
> 
>   drivers/gpu/drm/i915/gt/intel_context.h:107: warning: Function 
> parameter or member 'ce' not described in 'intel_context_lock_pinned'
>   drivers/gpu/drm/i915/gt/intel_context.h:122: warning: Function 
> parameter or member 'ce' not described in 'intel_context_is_pinned'
>   drivers/gpu/drm/i915/gt/intel_context.h:141: warning: Function 
> parameter or member 'ce' not described in 'intel_context_unlock_pinned'
>   drivers/gpu/drm/i915/gt/intel_gtt.h:510: warning: Function parameter or 
> member 'vm' not described in 'i915_vm_resv_put'
>   drivers/gpu/drm/i915/gt/intel_gtt.h:510: warning: Excess function 
> parameter 'resv' description in 'i915_vm_resv_put'
>   drivers/gpu/drm/i915/gt/intel_gtt.h:615: warning: Function parameter or 
> member 'i915' not described in 'i915_ggtt_mark_pte_lost'
>   drivers/gpu/drm/i915/gt/intel_gtt.h:615: warning: Function parameter or 
> member 'val' not described in 'i915_ggtt_mark_pte_lost'
>   drivers/gpu/drm/i915/gt/intel_rps.c:2343: warning: This comment starts 
> with '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Tells the intel_ips driver that the i915 driver is now loaded, if
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function 
> parameter or member 'size' not described in '__guc_capture_bufstate'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function 
> parameter or member 'data' not described in '__guc_capture_bufstate'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function 
> parameter or member 'rd' not described in '__guc_capture_bufstate'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:28: warning: Function 
> parameter or member 'wr' not described in '__guc_capture_bufstate'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'link' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'is_partial' not described in 
> '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'eng_class' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'eng_inst' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'guc_id' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'lrca' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:60: warning: Function 
> parameter or member 'reginfo' not described in '__guc_capture_parsed_output'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:63: warning: wrong 
> kernel-doc identifier on line:
>* struct guc_debug_capture_list_header / struct guc_debug_capture_list
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:81: warning: wrong 
> kernel-doc identifier on line:
>* struct __guc_mmio_reg_descr / struct __guc_mmio_reg_descr_group
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:106: warning: wrong 
> kernel-doc identifier on line:
>* struct guc_state_capture_header_t / struct guc_state_capture_t /
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function 
> parameter or member 'is_valid' not described in '__guc_capture_ads_cache'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function 
> parameter or member 'ptr' not described in '__guc_capture_ads_cache'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function 
> parameter or member 'size' not described in '__guc_capture_ads_cache'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:164: warning: Function 
> parameter or member 'status' not described in '__guc_capture_ads_cache'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:217: warning: Function 
> parameter or member 'ads_null_cache' not described in 
> 'intel_guc_state_capture'
>   drivers/gpu/drm/i915/gt/uc/guc_capture_fwif.h:217: warning: Function 
> parameter or member 'max_mmio_per_node' not described in 
> 'intel_guc_state_capture'
>   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function 
> parameter or member 'marker' not described in 'guc_log_buffer_state'
>   drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h:401: warning: Function 
> parameter or member 'read_ptr' not described in 'guc_log_buffer_stat

Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Guenter Roeck
On Wed, Jul 13, 2022 at 05:20:40PM -0400, Alex Deucher wrote:
[ ... ]
> > The problem is not the FPU operations, but the fact that soft-float
> > and hard-float compiled code is linked together. The soft-float and
> > hard-float ABIs on powerpc are not compatible, so one ends up with
> > an object file which is partially soft-float and partially hard-float
> > compiled and thus uses different ABIs. That can only create chaos,
> > so the linker complains about it.
> 
> I get that, I just don't see why only DCN 3.1.x files have this
> problem.  The DCN 2.x files should as well.
> 

No idea. Maybe ppc:allmodconfig only builds DCN 3.1.x, and other builds
don't use -Werror and the warning is ignored.

Guenter


Re: [PATCH v2 05/39] drm/i915: display: fix kernel-doc markup warnings

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:53AM +0100, Mauro Carvalho Chehab wrote:
> There are a couple of issues at i915 display kernel-doc markups:
> 
>   drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: 
> Function parameter or member 'intel_connector' not described in 
> 'intel_connector_debugfs_add'
>   drivers/gpu/drm/i915/display/intel_display_debugfs.c:2238: warning: 
> Excess function parameter 'connector' description in 
> 'intel_connector_debugfs_add'
>   drivers/gpu/drm/i915/display/intel_display_power.c:700: warning: 
> expecting prototype for intel_display_power_put_async(). Prototype was for 
> __intel_display_power_put_async() instead
>   drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Function 
> parameter or member 'work' not described in 
> 'intel_tc_port_disconnect_phy_work'
>   drivers/gpu/drm/i915/display/intel_tc.c:807: warning: Excess function 
> parameter 'dig_port' description in 'intel_tc_port_disconnect_phy_work'
> 
> Those are due to wrong parameter of function name. Address them.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 +-
>  drivers/gpu/drm/i915/display/intel_display_power.c   | 2 +-
>  drivers/gpu/drm/i915/display/intel_tc.c  | 2 +-
>  3 files changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c 
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 6c3954479047..1e35eb01742b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -2229,7 +2229,7 @@ DEFINE_SHOW_ATTRIBUTE(i915_current_bpc);
>  
>  /**
>   * intel_connector_debugfs_add - add i915 specific connector debugfs files
> - * @connector: pointer to a registered drm_connector
> + * @intel_connector: pointer to a registered drm_connector
>   *
>   * Cleanup will be done by drm_connector_unregister() through a call to
>   * drm_debugfs_connector_remove().
> diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c 
> b/drivers/gpu/drm/i915/display/intel_display_power.c
> index 589af257edeb..fd6b71160a06 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_power.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_power.c
> @@ -685,7 +685,7 @@ intel_display_power_put_async_work(struct work_struct 
> *work)
>  }
>  
>  /**
> - * intel_display_power_put_async - release a power domain reference 
> asynchronously
> + * __intel_display_power_put_async - release a power domain reference 
> asynchronously

oh, we are really using __ prefix for non-static functions?! o.O

anyway, with that ditto "()" consistency,

Reviewed-by: Rodrigo Vivi 



>   * @i915: i915 device instance
>   * @domain: power domain to reference
>   * @wakeref: wakeref acquired for the reference that is being released
> diff --git a/drivers/gpu/drm/i915/display/intel_tc.c 
> b/drivers/gpu/drm/i915/display/intel_tc.c
> index 6773840f6cc7..7ce0cbe0de05 100644
> --- a/drivers/gpu/drm/i915/display/intel_tc.c
> +++ b/drivers/gpu/drm/i915/display/intel_tc.c
> @@ -797,7 +797,7 @@ void intel_tc_port_lock(struct intel_digital_port 
> *dig_port)
>  
>  /**
>   * intel_tc_port_disconnect_phy_work: disconnect TypeC PHY from display port
> - * @dig_port: digital port
> + * @work: workqueue struct
>   *
>   * Disconnect the given digital port from its TypeC PHY (handing back the
>   * control of the PHY to the TypeC subsystem). This will happen in a delayed
> -- 
> 2.36.1
> 


Re: [PATCH v2 03/39] drm/i915/gvt: Fix kernel-doc for intel_vgpu_*_resource()

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:51AM +0100, Mauro Carvalho Chehab wrote:
> From: Jiapeng Chong 
> 
> Fix the following W=1 kernel warnings:
> 
> drivers/gpu/drm/i915/gvt/aperture_gm.c:308: warning: expecting prototype
> for inte_gvt_free_vgpu_resource(). Prototype was for
> intel_vgpu_free_resource() instead.
> 
> drivers/gpu/drm/i915/gvt/aperture_gm.c:344: warning: expecting prototype
> for intel_alloc_vgpu_resource(). Prototype was for
> intel_vgpu_alloc_resource() instead.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> Acked-by: Zhenyu Wang 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gvt/aperture_gm.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c 
> b/drivers/gpu/drm/i915/gvt/aperture_gm.c
> index 557f3314291a..3b81a6d35a7b 100644
> --- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
> +++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
> @@ -298,7 +298,7 @@ static int alloc_resource(struct intel_vgpu *vgpu,
>  }
>  
>  /**
> - * inte_gvt_free_vgpu_resource - free HW resource owned by a vGPU
> + * intel_vgpu_free_resource() - free HW resource owned by a vGPU

with the consistency in the usage of "()" feel free to use

Reviewed-by: Rodrigo Vivi 



>   * @vgpu: a vGPU
>   *
>   * This function is used to free the HW resource owned by a vGPU.
> @@ -328,7 +328,7 @@ void intel_vgpu_reset_resource(struct intel_vgpu *vgpu)
>  }
>  
>  /**
> - * intel_alloc_vgpu_resource - allocate HW resource for a vGPU
> + * intel_vgpu_alloc_resource() - allocate HW resource for a vGPU
>   * @vgpu: vGPU
>   * @param: vGPU creation params
>   *
> -- 
> 2.36.1
> 


Re: [PATCH v2 04/39] drm/i915: fix kernel-doc trivial warnings on i915/*.[ch] files

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:52AM +0100, Mauro Carvalho Chehab wrote:
> There are several trivial warnings there, due to trivial things:
>   - lack of function name at the kerneldoc markup;
>   - renamed functions;
>   - wrong parameter syntax.
> 
> Fix such warnings:
>   drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or 
> member 'active' not described in '__i915_active_fence_init'
>   drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or 
> member 'fence' not described in '__i915_active_fence_init'
>   drivers/gpu/drm/i915/i915_active.h:66: warning: Function parameter or 
> member 'fn' not described in '__i915_active_fence_init'
>   drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or 
> member 'active' not described in 'i915_active_fence_set'
>   drivers/gpu/drm/i915/i915_active.h:89: warning: Function parameter or 
> member 'rq' not described in 'i915_active_fence_set'
>   drivers/gpu/drm/i915/i915_active.h:102: warning: Function parameter or 
> member 'active' not described in 'i915_active_fence_get'
>   drivers/gpu/drm/i915/i915_active.h:122: warning: Function parameter or 
> member 'active' not described in 'i915_active_fence_isset'
>   drivers/gpu/drm/i915/i915_gem.c:443: warning: This comment starts with 
> '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Reads data from the object referenced by handle.
>   drivers/gpu/drm/i915/i915_gem.c:532: warning: This comment starts with 
> '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* This is the fast pwrite path, where we copy the data directly from 
> the
>   drivers/gpu/drm/i915/i915_gem.c:717: warning: This comment starts with 
> '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Writes data to the object referenced by handle.
>   drivers/gpu/drm/i915/i915_gem.c:802: warning: This comment starts with 
> '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Called when user space has done writes to this buffer
>   drivers/gpu/drm/i915/i915_pmu.h:22: warning: cannot understand function 
> prototype: 'enum i915_pmu_tracked_events '
>   drivers/gpu/drm/i915/i915_pmu.h:33: warning: cannot understand function 
> prototype: 'enum '
>   drivers/gpu/drm/i915/i915_pmu.h:42: warning: This comment starts with 
> '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* How many different events we track in the global PMU mask.
>   drivers/gpu/drm/i915/i915_request.h:177: warning: This comment starts 
> with '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Request queue structure.
>   drivers/gpu/drm/i915/i915_request.h:473: warning: This comment starts 
> with '/**', but isn't a kernel-doc comment. Refer 
> Documentation/doc-guide/kernel-doc.rst
>* Returns true if seq1 is later than seq2.
>   drivers/gpu/drm/i915/i915_scatterlist.c:63: warning: Function parameter 
> or member 'size' not described in 'i915_refct_sgt_init'
>   drivers/gpu/drm/i915/i915_scatterlist.h:153: warning: Incorrect use of 
> kernel-doc format:  * release() - Free the memory of the struct 
> i915_refct_sgt
>   drivers/gpu/drm/i915/i915_scatterlist.h:157: warning: Function 
> parameter or member 'release' not described in 'i915_refct_sgt_ops'
>   drivers/gpu/drm/i915/i915_scatterlist.h:180: warning: Function 
> parameter or member 'rsgt' not described in 'i915_refct_sgt_put'
>   drivers/gpu/drm/i915/i915_scatterlist.h:191: warning: Function 
> parameter or member 'rsgt' not described in 'i915_refct_sgt_get'
>   drivers/gpu/drm/i915/i915_scatterlist.h:207: warning: Function 
> parameter or member 'rsgt' not described in '__i915_refct_sgt_init'
>   drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or 
> member 'OP' not described in '__wait_for'
>   drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or 
> member 'COND' not described in '__wait_for'
>   drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or 
> member 'US' not described in '__wait_for'
>   drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or 
> member 'Wmin' not described in '__wait_for'
>   drivers/gpu/drm/i915/i915_utils.h:291: warning: Function parameter or 
> member 'Wmax' not described in '__wait_for'
>   drivers/gpu/drm/i915/i915_vma_resource.h:88: warning: Incorrect use of 
> kernel-doc format:  * struct i915_vma_bindinfo - Information needed 
> for async bind
>   drivers/gpu/drm/i915/i915_vma_resource.h:123: warning: Function 
> parameter or member 'bi' not described in 'i915_vma_resource'
> 
> Signed-off-by: Mauro Carvalho Chehab 

functions should change to have "()" or not?
whatev

Re: [PATCH v2 01/39] drm/i915/gvt: Fix kernel-doc for intel_gvt_switch_mmio()

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 05:54:44PM -0400, Rodrigo Vivi wrote:
> On Wed, Jul 13, 2022 at 09:11:49AM +0100, Mauro Carvalho Chehab wrote:
> > From: Jiapeng Chong 
> > 
> > Fix the following W=1 kernel warnings:
> > 
> > drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
> > prototype for intel_gvt_switch_render_mmio(). Prototype was for
> > intel_gvt_switch_mmio() instead.
> > 
> > Reported-by: Abaci Robot 
> > Signed-off-by: Jiapeng Chong 
> > Acked-by: Zhenyu Wang 
> > Signed-off-by: Mauro Carvalho Chehab 
> 
> Reviewed-by: Rodrigo Vivi 

I actually changed my mind after seeing that in most cases you use "()"
for the functions and you didn't use for this case...

which one should we pick for consistency?

> 
> > ---
> > 
> > To avoid mailbombing on a large number of people, only mailing lists were 
> > C/C on the cover.
> > See [PATCH v2 00/39] at: 
> > https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> > 
> >  drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
> > b/drivers/gpu/drm/i915/gvt/mmio_context.c
> > index c85bafe7539e..1c6e941c9666 100644
> > --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> > +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> > @@ -546,7 +546,7 @@ static void switch_mmio(struct intel_vgpu *pre,
> >  }
> >  
> >  /**
> > - * intel_gvt_switch_render_mmio - switch mmio context of specific engine
> > + * intel_gvt_switch_mmio - switch mmio context of specific engine
> >   * @pre: the last vGPU that own the engine
> >   * @next: the vGPU to switch to
> >   * @engine: the engine
> > -- 
> > 2.36.1
> > 


Re: [PATCH v5 1/9] dt-bindings: usb: Add Type-C switch binding

2022-07-13 Thread Prashant Malani
On Tue, Jul 12, 2022 at 10:45 AM Rob Herring  wrote:
>
> > I agree with you; I'm saying my interpretation of the comments of this
> > thread are that it's not the intended usage of the it6505 part, so the 
> > driver
> > shouldn't be updated to support that.
>
> That's not the right interpretation. There should not be some Type-C
> specific child mux/switch node because the device has no such h/w within
> it. Assuming all the possibilities Stephen outlined are valid, it's
> clear this lane selection has nothing to do with Type-C. It does have an
> output port for its DP output already and using that to describe the
> connection to DP connector(s) and/or Type-C connector(s) should be
> handled.

Got it. Thanks for the clarification.

>
> Whether the driver is type-C aware is a separate question from the
> binding. I would think the driver just needs to be told (or it can ask)
> which endpoint should be active and it just enables output on the
> corresponding lanes for that endpoint.

Is it acceptable to tag the end-points with a "mode-switch" /
"orientation-switch"
property? Something like the following:

```
dp-bridge@5c {
compatible = "ite,it6505";
...
port {
#adderss-cells = <1>;
#size-cells = <0>;

ite_typec0: endpoint@0 {
reg = <0>;
mode-switch;
remote-endpoint = <&typec_connector0>;
};
ite_typec1: endpoint@1 {
reg = <1>;
mode-switch;
remote-endpoint = <&typec_connector1>;
};
};
};
```
Or should the DRM bridge device binding not have those properties in
the end-points either?
The reasons those are required are:
- The Type-C matching code looks for the "mode-switch" identifier in
the fwnode while performing the switch matching [1]
- While we can look up whether the remote-endpoint is a
"usb-c-connector" in the bridge driver the
"mode-switch"/"orientation-switch" property tells the bridge driver
whether to register just a mode-switch, an orientation switch or both.

Best regards,

- Prashant

[1] 
https://elixir.bootlin.com/linux/v5.19-rc6/source/drivers/usb/typec/mux.c#L347


Re: [Intel-gfx] [PATCH v2 02/39] drm/i915/gvt: Fix kernel-doc for intel_vgpu_default_mmio_write

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:50AM +0100, Mauro Carvalho Chehab wrote:
> From: Jiapeng Chong 
> 
> Fix the following W=1 kernel warnings:
> 
> drivers/gpu/drm/i915/gvt/handlers.c:3066: warning: expecting prototype
> for intel_t_default_mmio_write(). Prototype was for
> intel_vgpu_default_mmio_write() instead.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> Acked-by: Zhenyu Wang 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gvt/handlers.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c 
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index beea5895e499..9c8dde079cb4 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -3052,7 +3052,7 @@ int intel_vgpu_default_mmio_read(struct intel_vgpu 
> *vgpu, unsigned int offset,
>  }
>  
>  /**
> - * intel_t_default_mmio_write - default MMIO write handler
> + * intel_vgpu_default_mmio_write() - default MMIO write handler
>   * @vgpu: a vGPU
>   * @offset: access offset
>   * @p_data: write data buffer
> -- 
> 2.36.1
> 


Re: [PATCH v2 01/39] drm/i915/gvt: Fix kernel-doc for intel_gvt_switch_mmio()

2022-07-13 Thread Rodrigo Vivi
On Wed, Jul 13, 2022 at 09:11:49AM +0100, Mauro Carvalho Chehab wrote:
> From: Jiapeng Chong 
> 
> Fix the following W=1 kernel warnings:
> 
> drivers/gpu/drm/i915/gvt/mmio_context.c:560: warning: expecting
> prototype for intel_gvt_switch_render_mmio(). Prototype was for
> intel_gvt_switch_mmio() instead.
> 
> Reported-by: Abaci Robot 
> Signed-off-by: Jiapeng Chong 
> Acked-by: Zhenyu Wang 
> Signed-off-by: Mauro Carvalho Chehab 

Reviewed-by: Rodrigo Vivi 

> ---
> 
> To avoid mailbombing on a large number of people, only mailing lists were C/C 
> on the cover.
> See [PATCH v2 00/39] at: 
> https://lore.kernel.org/all/cover.1657699522.git.mche...@kernel.org/
> 
>  drivers/gpu/drm/i915/gvt/mmio_context.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/mmio_context.c 
> b/drivers/gpu/drm/i915/gvt/mmio_context.c
> index c85bafe7539e..1c6e941c9666 100644
> --- a/drivers/gpu/drm/i915/gvt/mmio_context.c
> +++ b/drivers/gpu/drm/i915/gvt/mmio_context.c
> @@ -546,7 +546,7 @@ static void switch_mmio(struct intel_vgpu *pre,
>  }
>  
>  /**
> - * intel_gvt_switch_render_mmio - switch mmio context of specific engine
> + * intel_gvt_switch_mmio - switch mmio context of specific engine
>   * @pre: the last vGPU that own the engine
>   * @next: the vGPU to switch to
>   * @engine: the engine
> -- 
> 2.36.1
> 


RE: [Intel-gfx] [PATCH] drm/i915/guc: Check for ct enabled while waiting for response

2022-07-13 Thread Dong, Zhanjun



> -Original Message-
> From: Dixit, Ashutosh 
> Sent: July 12, 2022 3:48 PM
> To: Dong, Zhanjun 
> Cc: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH] drm/i915/guc: Check for ct enabled while
> waiting for response
> 
> On Thu, 16 Jun 2022 21:50:55 -0700, Dixit, Ashutosh wrote:
> >
> > On Thu, 16 Jun 2022 15:01:59 -0700, Zhanjun Dong wrote:
> > >
> > > We are seeing error message of "No response for request". Some cases
> > > happened while waiting for response and reset/suspend action was
> triggered.
> > > In this case, no response is not an error, active requests will be
> > > cancelled.
> > >
> > > This patch will handle this condition and change the error message
> > > into debug message.
> > >
> > > Signed-off-by: Zhanjun Dong 
> > > ---
> > >  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24
> > > ---
> > >  1 file changed, 17 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > index f01325cd1b62..f07a7666b1ad 100644
> > > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > > @@ -455,6 +455,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > >
> > >  /**
> > >   * wait_for_ct_request_update - Wait for CT request state update.
> > > + * @ct:  pointer to CT
> > >   * @req: pointer to pending request
> > >   * @status:  placeholder for status
> > >   *
> > > @@ -467,9 +468,10 @@ static int ct_write(struct intel_guc_ct *ct,
> > >   * * 0 response received (status is valid)
> > >   * * -ETIMEDOUT no response within hardcoded timeout
> > >   */
> > > -static int wait_for_ct_request_update(struct ct_request *req, u32
> > > *status)
> > > +static int wait_for_ct_request_update(struct intel_guc_ct *ct,
> > > +struct ct_request *req, u32 *status)
> > >  {
> > >   int err;
> > > + bool ct_enabled;
> > >
> > >   /*
> > >* Fast commands should complete in less than 10us, so sample
> > >quickly  @@ -481,12 +483,15 @@ static int
> > >wait_for_ct_request_update(struct ct_request *req, u32 *status)
> > >  #define GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS 10
> > >  #define GUC_CTB_RESPONSE_TIMEOUT_LONG_MS 1000
> > >  #define done \
> > > - (FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) ==
> \
> > > + (!(ct_enabled = intel_guc_ct_enabled(ct)) || \
> > > +  FIELD_GET(GUC_HXG_MSG_0_ORIGIN, READ_ONCE(req->status)) ==
> \
> > >GUC_HXG_ORIGIN_GUC)
> > >   err = wait_for_us(done, GUC_CTB_RESPONSE_TIMEOUT_SHORT_MS);
> > >   if (err)
> > >   err = wait_for(done,
> GUC_CTB_RESPONSE_TIMEOUT_LONG_MS);
> > >  #undef done
> > > + if (!ct_enabled)
> > > + err = -ECANCELED;
> >
> > Actually here's an even simpler suggestion. We could just do:
> >
> > if (!ct_enabled)
> > CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is
> disabled\n",
> >...);
> >
> > And return 0 as before. This way we won't have to make any changes in
> > either ct_send() or intel_guc_ct_send(). So intel_guc_ct_enabled()
> > just serves to get us out of the wait early and prevent the -ETIMEDOUT
> > return (and 0 return avoids all the error messages we are trying to
> eliminate).
> 
> Actually will need to unlink the request too, so it will be something like:
> 
>   if (!ct_enabled) {
>   CT_DEBUG(ct, "Request %#x (fence %u) cancelled as CTB is
> disabled\n", ...);
> 
>   spin_lock_irqsave(&ct->requests.lock, flags);
>   list_del(&request.link);
>   spin_unlock_irqrestore(&ct->requests.lock, flags);
>   }

I agree, the caller function need the err is non-zero to know the request is 
not success, and unlink the request.
The caller function ct_send will do the unlink.

For the err code ECANCELED, while in intel_guc_ct_send, it returns ENODEV if ct 
is disabled. This patch will be changed to ENODEV to match it.


[PULL] drm-intel-fixes

2022-07-13 Thread Rodrigo Vivi
Hi Dave and Daniel,

On behalf of Jani, here goes the drm-intel-fixes targeting
5.19-rc7.

Please notice that this also includes the patches you already
pulled last week. But for some reason they are not in the
5.19-rc6 yet.

Well, we always use the official -rc as the base, but if it
gets easier for you to use the drm/drm-fixes this round just
let me know that I can force-push and generate another one
tomorrow.

But I hope the official dim flow works.

Thanks,
Rodrigo.

drm-intel-fixes-2022-07-13:
- Selftest fix (Andrzej)
- TTM fix sg_table construction (Matt Auld)
- Error return fixes (Dan)
- Fix a performance regression related to waitboost (Chri\
s)
- Fix GT resets (Chris)
- Fix a possible refcount leak in DP MST connector (Hangy\
u)
- Fix on loading guc on ADL-N (Daniele)
- Fix vm use-after-free in vma destruction (Thomas)

Thanks,
Rodrigo.

The following changes since commit 32346491ddf24599decca06190ebca03ff9de7f8:

  Linux 5.19-rc6 (2022-07-10 14:40:51 -0700)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-fixes-2022-07-13

for you to fetch changes up to 333991c4e66b3d4b5613315f18016da80344f659:

  drm/i915/selftests: fix subtraction overflow bug (2022-07-12 18:21:58 -0400)


- Selftest fix (Andrzej)
- TTM fix sg_table construction (Matt Auld)
- Error return fixes (Dan)
- Fix a performance regression related to waitboost (Chri\
s)
- Fix GT resets (Chris)
- Fix a possible refcount leak in DP MST connector (Hangy\
u)
- Fix on loading guc on ADL-N (Daniele)
- Fix vm use-after-free in vma destruction (Thomas)


Andrzej Hajda (1):
  drm/i915/selftests: fix subtraction overflow bug

Chris Wilson (3):
  drm/i915/gt: Serialize GRDOM access between multiple engine resets
  drm/i915/gt: Serialize TLB invalidates with GT resets
  drm/i915/gem: Look for waitboosting across the whole object prior to 
individual waits

Dan Carpenter (2):
  drm/i915/gvt: IS_ERR() vs NULL bug in intel_gvt_update_reg_whitelist()
  drm/i915/selftests: fix a couple IS_ERR() vs NULL tests

Daniele Ceraolo Spurio (1):
  drm/i915/guc: ADL-N should use the same GuC FW as ADL-S

Hangyu Hua (1):
  drm/i915: fix a possible refcount leak in intel_dp_add_mst_connector()

Matthew Auld (1):
  drm/i915/ttm: fix sg_table construction

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2022-07-11' of https://github.com/intel/gvt-linux 
into drm-intel-fixes

Thomas Hellström (1):
  drm/i915: Fix vm use-after-free in vma destruction

 drivers/gpu/drm/i915/display/intel_dp_mst.c|  1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c| 11 +--
 drivers/gpu/drm/i915/gem/i915_gem_wait.c   | 34 
 drivers/gpu/drm/i915/gt/intel_gt.c | 15 -
 drivers/gpu/drm/i915/gt/intel_reset.c  | 37 --
 drivers/gpu/drm/i915/gt/selftest_lrc.c |  8 ++---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c   |  9 ++
 drivers/gpu/drm/i915/gvt/cmd_parser.c  |  6 ++--
 drivers/gpu/drm/i915/i915_scatterlist.c| 19 ---
 drivers/gpu/drm/i915/i915_scatterlist.h|  6 ++--
 drivers/gpu/drm/i915/i915_vma.c| 12 ---
 drivers/gpu/drm/i915/intel_region_ttm.c| 10 --
 drivers/gpu/drm/i915/intel_region_ttm.h|  3 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c  |  2 +-
 .../gpu/drm/i915/selftests/intel_memory_region.c   | 21 ++--
 drivers/gpu/drm/i915/selftests/mock_region.c   |  3 +-
 16 files changed, 160 insertions(+), 37 deletions(-)


[PULL] drm-intel-gt-next

2022-07-13 Thread Rodrigo Vivi
Hi Dave and Daniel,

On behalf of Tvrtko, who is recovering from Covid,
here goes the latest drm-intel-gt-next pull request
targeting 5.20.

Thanks,
Rodrigo.

Driver uAPI changes:
- All related to the Small BAR support: (and all by Matt Auld)
 * add probed_cpu_visible_size
 * expose the avail memory region tracking
 * apply ALLOC_GPU only by default
 * add NEEDS_CPU_ACCESS hint
 * tweak error capture on recoverable contexts

Driver highlights:
- Add Small BAR support (Matt)
- Add MeteorLake support (RK)
- Add support for LMEM PCIe resizable BAR (Akeem)

Driver important fixes:
- ttm related fixes (Matt Auld)
- Fix a performance regression related to waitboost (Chris)
- Fix GT resets (Chris)

Driver others:
- Adding GuC SLPC selftest (Vinay)
- Fix ADL-N GuC load (Daniele)
- Add platform workaround (Gustavo, Matt Roper)
- DG2 and ATS-M device ID updates (Matt Roper)
- Add VM_BIND doc rfc with uAPI documentation (Niranjana)
- Fix user-after-free in vma destruction (Thomas)
- Async flush of GuC log regions (Alan)
- Fixes in selftests (Chris, Dan, Andrzej)
- Convert to drm_dbg (Umesh)
- Disable OA sseu config param for newer hardware (Umesh)
- Multi-cast register steering changes (Matt Roper)
- Add lmem_bar_size modparam (Priyanka)

Thanks,
Rodrigo.

The following changes since commit a06968563775181690125091f470a8655742dcbf:

  drm/i915: Fix a lockdep warning at error capture (2022-06-29 14:52:50 +0530)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-gt-next-2022-07-13

for you to fetch changes up to 17cd10a44a8962860ff4ba351b2a290e752dbbde:

  drm/i915: Add lmem_bar_size modparam (2022-07-13 17:47:51 +0100)


Driver uAPI changes:
- All related to the Small BAR support: (and all by Matt Auld)
 * add probed_cpu_visible_size
 * expose the avail memory region tracking
 * apply ALLOC_GPU only by default
 * add NEEDS_CPU_ACCESS hint
 * tweak error capture on recoverable contexts

Driver highlights:
- Add Small BAR support (Matt)
- Add MeteorLake support (RK)
- Add support for LMEM PCIe resizable BAR (Akeem)

Driver important fixes:
- ttm related fixes (Matt Auld)
- Fix a performance regression related to waitboost (Chris)
- Fix GT resets (Chris)

Driver others:
- Adding GuC SLPC selftest (Vinay)
- Fix ADL-N GuC load (Daniele)
- Add platform workaround (Gustavo, Matt Roper)
- DG2 and ATS-M device ID updates (Matt Roper)
- Add VM_BIND doc rfc with uAPI documentation (Niranjana)
- Fix user-after-free in vma destruction (Thomas)
- Async flush of GuC log regions (Alan)
- Fixes in selftests (Chris, Dan, Andrzej)
- Convert to drm_dbg (Umesh)
- Disable OA sseu config param for newer hardware (Umesh)
- Multi-cast register steering changes (Matt Roper)
- Add lmem_bar_size modparam (Priyanka)


Akeem G Abodunrin (1):
  drm/i915: Add support for LMEM PCIe resizable bar

Alan Previn (1):
  drm/i915/guc: Asynchronous flush of GuC log regions

Andrzej Hajda (1):
  drm/i915/selftests: fix subtraction overflow bug

Chris Wilson (6):
  drm/i915/selftests: Grab the runtime pm in shrink_thp
  drm/i915/gt: Serialize GRDOM access between multiple engine resets
  drm/i915/gt: Serialize TLB invalidates with GT resets
  drm/i915/gem: Look for waitboosting across the whole object prior to 
individual waits
  drm/i915: Bump GT idling delay to 2 jiffies
  drm/i915/gt: Only kick the signal worker if there's been an update

Dan Carpenter (1):
  drm/i915/selftests: fix a couple IS_ERR() vs NULL tests

Daniele Ceraolo Spurio (1):
  drm/i915/guc: ADL-N should use the same GuC FW as ADL-S

Gustavo Sousa (1):
  drm/i915/pvc: Implement w/a 16016694945

Matt Roper (4):
  drm/i915: DG2 and ATS-M device ID updates
  drm/i915/gt: Add general DSS steering iterator to intel_gt_mcr
  drm/i915/dg2: Add Wa_15010599737
  drm/i915: Correct ss -> steering calculation for pre-Xe_HP platforms

Matthew Auld (15):
  drm/doc: add rfc section for small BAR uapi
  drm/i915/uapi: add probed_cpu_visible_size
  drm/i915/uapi: expose the avail tracking
  drm/i915: remove intel_memory_region avail
  drm/i915/uapi: apply ALLOC_GPU_ONLY by default
  drm/i915/uapi: add NEEDS_CPU_ACCESS hint
  drm/i915/error: skip non-mappable pages
  drm/i915/uapi: tweak error capture on recoverable contexts
  drm/i915/selftests: skip the mman tests for stolen
  drm/i915/selftests: ensure we reserve a fence slot
  drm/i915/ttm: handle blitter failure on DG2
  drm/i915/ttm: disallow CPU fallback mode for ccs pages
  drm/i915: turn on small BAR support
  drm/i915/ttm: fix sg_table construction
  drm/i915/ttm: fix 32b build

Niranjana Vishwanathapura (3):
  drm/doc/rfc: VM_BIND feature design document
  drm/i915: Update i915 uapi documentation
  drm/doc/rfc: VM_BIND uapi definition


Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Alex Deucher
On Wed, Jul 13, 2022 at 5:18 PM Guenter Roeck  wrote:
>
> On 7/13/22 13:57, Alex Deucher wrote:
> > On Thu, Jun 30, 2022 at 5:01 PM Rodrigo Siqueira Jordao
> >  wrote:
> >>
> >>
> >>
> >> On 2022-06-18 19:27, Guenter Roeck wrote:
> >>> ppc:allmodconfig builds fail with the following error.
> >>>
> >>> powerpc64-linux-ld:
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >>>uses hard float,
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> >>>uses soft float
> >>> powerpc64-linux-ld:
> >>>failed to merge target specific data of file
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> >>> powerpc64-linux-ld:
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >>>uses hard float,
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> >>>uses soft float
> >>> powerpc64-linux-ld:
> >>>failed to merge target specific data of
> >>>file 
> >>> drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> >>> powerpc64-linux-ld:
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >>>uses hard float,
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >>>uses soft float
> >>> powerpc64-linux-ld:
> >>>failed to merge target specific data of file
> >>>drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >>>
> >>> The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> >>> 64-bit outline-only KASAN support") which adds support for KASAN. This
> >>> commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> >>> KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> >>> compiled which lack the selection of hard-float.
> >>>
> >>> Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
> >>> Cc: Michael Ellerman 
> >>> Cc: Daniel Axtens 
> >>> Signed-off-by: Guenter Roeck 
> >>> ---
> >>>drivers/gpu/drm/amd/display/dc/dcn31/Makefile  | 4 
> >>>drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4 
> >>>drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4 
> >>>3 files changed, 12 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile 
> >>> b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> >>> index ec041e3cda30..74be02114ae4 100644
> >>> --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> >>> +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> >>> @@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o 
> >>> dcn31_init.o dcn31_hubp.o
> >>>dcn31_apg.o dcn31_hpo_dp_stream_encoder.o 
> >>> dcn31_hpo_dp_link_encoder.o \
> >>>dcn31_afmt.o dcn31_vpg.o
> >>>
> >>> +ifdef CONFIG_PPC64
> >>> +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
> >>> +endif
> >>> +
> >>>AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
> >>>
> >>>AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
> >>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile 
> >>> b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> >>> index 59381d24800b..1395c1ced8c5 100644
> >>> --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> >>> +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> >>> @@ -25,6 +25,10 @@
> >>>
> >>>DCN315 = dcn315_resource.o
> >>>
> >>> +ifdef CONFIG_PPC64
> >>> +CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float 
> >>> -maltivec
> >>> +endif
> >>> +
> >>>AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
> >>>
> >>>AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
> >>> diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile 
> >>> b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> >>> index 819d44a9439b..c3d2dd78f1e2 100644
> >>> --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> >>> +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> >>> @@ -25,6 +25,10 @@
> >>>
> >>>DCN316 = dcn316_resource.o
> >>>
> >>> +ifdef CONFIG_PPC64
> >>> +CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float 
> >>> -maltivec
> >>> +endif
> >>> +
> >>>AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
> >>>
> >>>AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
> >>
> >> Hi,
> >>
> >> I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316
> >> since we fully isolate FPU operations for those ASICs inside the DML
> >
> > I don't understand why we don't need to add the hard-float flags back
> > on the other DCN blocks.  Did we miss something in the DML cleanup for
> > DCN 3.1.x?  Anyway, at this point, the patch is:
> > Acked-by: Alex Deucher 
> > We can sort the rest out for 5.20.
> >
>
> The problem is not the FPU operations, but the fact that soft-float
> and hard-float compiled code is linked together. The soft-float and
> hard-float ABIs on powerpc 

Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Guenter Roeck

On 7/13/22 13:57, Alex Deucher wrote:

On Thu, Jun 30, 2022 at 5:01 PM Rodrigo Siqueira Jordao
 wrote:




On 2022-06-18 19:27, Guenter Roeck wrote:

ppc:allmodconfig builds fail with the following error.

powerpc64-linux-ld:
   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
   uses hard float,
   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
   uses soft float
powerpc64-linux-ld:
   failed to merge target specific data of file
   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
powerpc64-linux-ld:
   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
   uses hard float,
   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
   uses soft float
powerpc64-linux-ld:
   failed to merge target specific data of
   file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
powerpc64-linux-ld:
   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
   uses hard float,
   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
   uses soft float
powerpc64-linux-ld:
   failed to merge target specific data of file
   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o

The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
64-bit outline-only KASAN support") which adds support for KASAN. This
commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
compiled which lack the selection of hard-float.

Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
Cc: Michael Ellerman 
Cc: Daniel Axtens 
Signed-off-by: Guenter Roeck 
---
   drivers/gpu/drm/amd/display/dc/dcn31/Makefile  | 4 
   drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4 
   drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4 
   3 files changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
index ec041e3cda30..74be02114ae4 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
@@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o 
dcn31_init.o dcn31_hubp.o
   dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o \
   dcn31_afmt.o dcn31_vpg.o

+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
+endif
+
   AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))

   AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
index 59381d24800b..1395c1ced8c5 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
@@ -25,6 +25,10 @@

   DCN315 = dcn315_resource.o

+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
+endif
+
   AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))

   AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile 
b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
index 819d44a9439b..c3d2dd78f1e2 100644
--- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
+++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
@@ -25,6 +25,10 @@

   DCN316 = dcn316_resource.o

+ifdef CONFIG_PPC64
+CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
+endif
+
   AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))

   AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)


Hi,

I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316
since we fully isolate FPU operations for those ASICs inside the DML


I don't understand why we don't need to add the hard-float flags back
on the other DCN blocks.  Did we miss something in the DML cleanup for
DCN 3.1.x?  Anyway, at this point, the patch is:
Acked-by: Alex Deucher 
We can sort the rest out for 5.20.



The problem is not the FPU operations, but the fact that soft-float
and hard-float compiled code is linked together. The soft-float and
hard-float ABIs on powerpc are not compatible, so one ends up with
an object file which is partially soft-float and partially hard-float
compiled and thus uses different ABIs. That can only create chaos,
so the linker complains about it.

Guenter


Re: [PATCH] drm/amd/display: Add missing hard-float compile flags for PPC64 builds

2022-07-13 Thread Alex Deucher
On Thu, Jun 30, 2022 at 5:01 PM Rodrigo Siqueira Jordao
 wrote:
>
>
>
> On 2022-06-18 19:27, Guenter Roeck wrote:
> > ppc:allmodconfig builds fail with the following error.
> >
> > powerpc64-linux-ld:
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >   uses hard float,
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> >   uses soft float
> > powerpc64-linux-ld:
> >   failed to merge target specific data of file
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn31/dcn31_resource.o
> > powerpc64-linux-ld:
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >   uses hard float,
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> >   uses soft float
> > powerpc64-linux-ld:
> >   failed to merge target specific data of
> >   file drivers/gpu/drm/amd/amdgpu/../display/dc/dcn315/dcn315_resource.o
> > powerpc64-linux-ld:
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dml/display_mode_lib.o
> >   uses hard float,
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >   uses soft float
> > powerpc64-linux-ld:
> >   failed to merge target specific data of file
> >   drivers/gpu/drm/amd/amdgpu/../display/dc/dcn316/dcn316_resource.o
> >
> > The problem was introduced with commit 41b7a347bf14 ("powerpc: Book3S
> > 64-bit outline-only KASAN support") which adds support for KASAN. This
> > commit in turn enables DRM_AMD_DC_DCN because KCOV_INSTRUMENT_ALL and
> > KCOV_ENABLE_COMPARISONS are no longer enabled. As result, new files are
> > compiled which lack the selection of hard-float.
> >
> > Fixes: 41b7a347bf14 ("powerpc: Book3S 64-bit outline-only KASAN support")
> > Cc: Michael Ellerman 
> > Cc: Daniel Axtens 
> > Signed-off-by: Guenter Roeck 
> > ---
> >   drivers/gpu/drm/amd/display/dc/dcn31/Makefile  | 4 
> >   drivers/gpu/drm/amd/display/dc/dcn315/Makefile | 4 
> >   drivers/gpu/drm/amd/display/dc/dcn316/Makefile | 4 
> >   3 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > index ec041e3cda30..74be02114ae4 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn31/Makefile
> > @@ -15,6 +15,10 @@ DCN31 = dcn31_resource.o dcn31_hubbub.o dcn31_hwseq.o 
> > dcn31_init.o dcn31_hubp.o
> >   dcn31_apg.o dcn31_hpo_dp_stream_encoder.o dcn31_hpo_dp_link_encoder.o 
> > \
> >   dcn31_afmt.o dcn31_vpg.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn31/dcn31_resource.o := -mhard-float -maltivec
> > +endif
> > +
> >   AMD_DAL_DCN31 = $(addprefix $(AMDDALPATH)/dc/dcn31/,$(DCN31))
> >
> >   AMD_DISPLAY_FILES += $(AMD_DAL_DCN31)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > index 59381d24800b..1395c1ced8c5 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn315/Makefile
> > @@ -25,6 +25,10 @@
> >
> >   DCN315 = dcn315_resource.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn315/dcn315_resource.o := -mhard-float -maltivec
> > +endif
> > +
> >   AMD_DAL_DCN315 = $(addprefix $(AMDDALPATH)/dc/dcn315/,$(DCN315))
> >
> >   AMD_DISPLAY_FILES += $(AMD_DAL_DCN315)
> > diff --git a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile 
> > b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > index 819d44a9439b..c3d2dd78f1e2 100644
> > --- a/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > +++ b/drivers/gpu/drm/amd/display/dc/dcn316/Makefile
> > @@ -25,6 +25,10 @@
> >
> >   DCN316 = dcn316_resource.o
> >
> > +ifdef CONFIG_PPC64
> > +CFLAGS_$(AMDDALPATH)/dc/dcn316/dcn316_resource.o := -mhard-float -maltivec
> > +endif
> > +
> >   AMD_DAL_DCN316 = $(addprefix $(AMDDALPATH)/dc/dcn316/,$(DCN316))
> >
> >   AMD_DISPLAY_FILES += $(AMD_DAL_DCN316)
>
> Hi,
>
> I don't want to re-introduce those FPU flags for DCN31/DCN314/DCN316
> since we fully isolate FPU operations for those ASICs inside the DML

I don't understand why we don't need to add the hard-float flags back
on the other DCN blocks.  Did we miss something in the DML cleanup for
DCN 3.1.x?  Anyway, at this point, the patch is:
Acked-by: Alex Deucher 
We can sort the rest out for 5.20.

Alex

> folder. Notice that we have the PPC64 in the DML Makefile:
>
> https://gitlab.freedesktop.org/agd5f/linux/-/blob/amd-staging-drm-next/drivers/gpu/drm/amd/display/dc/dml/Makefile
>
> Could you share what you see without your patch in the
> amd-staging-drm-next? Also:
> * Are you using cross-compilation? If so, could you share your setup?
> * Which GCC/Clang version are you using?
>
> Thanks
> Siqueira
>


Re: [PATCH] drm/amd/display: Enable building new display engine with KCOV enabled

2022-07-13 Thread Harry Wentland
On 2022-07-12 18:42, Guenter Roeck wrote:
> The new display engine uses floating point math, which is not supported
> by KCOV. Commit 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov
> is enabled") tried to work around the problem by disabling
> CONFIG_DRM_AMD_DC_DCN if KCOV_INSTRUMENT_ALL and KCOV_ENABLE_COMPARISONS
> are enabled. The result is that KCOV can not be enabled on systems which
> require this display engine. A much simpler and less invasive solution is
> to disable KCOV selectively when compiling the display enagine while
> keeping it enabled for the rest of the kernel.
> 
> Fixes: 9d1d02ff3678 ("drm/amd/display: Don't build DCN1 when kcov is enabled")
> Cc: Arnd Bergmann 
> Cc: Leo Li 
> Signed-off-by: Guenter Roeck 

Reviewed-by: Harry Wentland 

Harry

> ---
>  drivers/gpu/drm/amd/display/Kconfig | 2 +-
>  drivers/gpu/drm/amd/display/dc/Makefile | 3 +++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/display/Kconfig 
> b/drivers/gpu/drm/amd/display/Kconfig
> index b4029c0d5d8c..96cbc87f7b6b 100644
> --- a/drivers/gpu/drm/amd/display/Kconfig
> +++ b/drivers/gpu/drm/amd/display/Kconfig
> @@ -6,7 +6,7 @@ config DRM_AMD_DC
>   bool "AMD DC - Enable new display engine"
>   default y
>   select SND_HDA_COMPONENT if SND_HDA_CORE
> - select DRM_AMD_DC_DCN if (X86 || PPC64) && !(KCOV_INSTRUMENT_ALL && 
> KCOV_ENABLE_COMPARISONS)
> + select DRM_AMD_DC_DCN if (X86 || PPC64)
>   help
> Choose this option if you want to use the new display engine
> support for AMDGPU. This adds required support for Vega and
> diff --git a/drivers/gpu/drm/amd/display/dc/Makefile 
> b/drivers/gpu/drm/amd/display/dc/Makefile
> index b4eca0236435..b801973749d2 100644
> --- a/drivers/gpu/drm/amd/display/dc/Makefile
> +++ b/drivers/gpu/drm/amd/display/dc/Makefile
> @@ -26,6 +26,9 @@
>  DC_LIBS = basics bios dml clk_mgr dce gpio irq link virtual
>  
>  ifdef CONFIG_DRM_AMD_DC_DCN
> +
> +KCOV_INSTRUMENT := n
> +
>  DC_LIBS += dcn20
>  DC_LIBS += dsc
>  DC_LIBS += dcn10



[pull] amdgpu drm-fixes-5.19

2022-07-13 Thread Alex Deucher
Hi Dave, Daniel,

Fixes for 5.19.

The following changes since commit 3590b44b9434af1b9c81c3f40189087ed4fe3635:

  Merge tag 'drm-misc-fixes-2022-07-07-1' of 
ssh://git.freedesktop.org/git/drm/drm-misc into drm-fixes (2022-07-12 10:44:40 
+1000)

are available in the Git repository at:

  https://gitlab.freedesktop.org/agd5f/linux.git 
tags/amd-drm-fixes-5.19-2022-07-13

for you to fetch changes up to 3283c83eb6fcfbda8ea03d7149d8e42e71c5d45e:

  drm/amd/display: Ensure valid event timestamp for cursor-only commits 
(2022-07-13 12:20:37 -0400)


amd-drm-fixes-5.19-2022-07-13:

amdgpu:
- DP MST blank screen fix for specific platforms
- MEC firmware check fix for GC 10.3.7
- Deep color fix for DCE
- Fix possible divide by 0
- Coverage blend mode fix
- Fix cursor only commit timestamps


Fangzhi Zuo (1):
  drm/amd/display: Ignore First MST Sideband Message Return Error

Mario Kleiner (1):
  drm/amd/display: Only use depth 36 bpp linebuffers on DCN display engines.

Melissa Wen (1):
  drm/amd/display: correct check of coverage blend mode

Michel Dänzer (1):
  drm/amd/display: Ensure valid event timestamp for cursor-only commits

Prike Liang (1):
  drm/amdkfd: correct the MEC atomic support firmware checking for GC 10.3.7

Yefim Barashkin (1):
  drm/amd/pm: Prevent divide by zero

 drivers/gpu/drm/amd/amdkfd/kfd_device.c|  2 +
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c  | 84 --
 drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h  |  8 +++
 .../amd/display/amdgpu_dm/amdgpu_dm_mst_types.c| 17 +
 drivers/gpu/drm/amd/display/dc/core/dc_resource.c  | 11 +--
 drivers/gpu/drm/amd/pm/swsmu/smu11/smu_v11_0.c |  2 +
 6 files changed, 115 insertions(+), 9 deletions(-)


RE: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks

2022-07-13 Thread Limonciello, Mario
[Public]



> -Original Message-
> From: Werner Sembach 
> Sent: Wednesday, July 13, 2022 12:08
> To: Hans de Goede ; Ben Skeggs
> ; Karol Herbst ; Lyude
> ; Daniel Dadap ; Maarten
> Lankhorst ; Maxime Ripard
> ; Thomas Zimmermann ;
> Jani Nikula ; Joonas Lahtinen
> ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Deucher, Alexander
> ; Koenig, Christian
> ; p...@vger.kernel.org; Pan, Xinhui
> ; Rafael J . Wysocki ; Mika
> Westerberg ; Lukas Wunner
> ; Mark Gross ; Andy
> Shevchenko 
> Cc: nouv...@lists.freedesktop.org; Daniel Vetter ; David
> Airlie ; intel-gfx ; dri-
> de...@lists.freedesktop.org; amd-...@lists.freedesktop.org; Len Brown
> ; linux-a...@vger.kernel.org; platform-driver-
> x...@vger.kernel.org
> Subject: Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and
> NL5xNU acpi_backlight=native quirks
> 
> Hi,
> 
> On 7/12/22 21:39, Hans de Goede wrote:
> > acpi_backlight=native is the default for these, but as the comment
> > explains the quirk was still necessary because even briefly registering
> > the acpi_video0 backlight; and then unregistering it once the native
> > driver showed up, was leading to issues.
> >
> > After the "ACPI: video: Make backlight class device registration
> > a separate step" patch from earlier in this patch-series, we no
> > longer briefly register the acpi_video0 backlight on systems where
> > the native driver should be used.
> >
> > So this is no longer an issue an the quirks are no longer needed.
> >
> > Cc: Werner Sembach 
> > Signed-off-by: Hans de Goede 
> 
> Tested and can confirm: The quirks are no longer needed with this Patchset.
> 
> Tested-by: Werner Sembach 

Probably should include this link tag in this commit too then as it fixes
the Tong Fang systems too.

Link: https://bugzilla.kernel.org/show_bug.cgi?id=215683

> 
> Kind Regards,
> 
> Werner Sembach
> 
> > ---
> >   drivers/acpi/video_detect.c | 75 -
> >   1 file changed, 75 deletions(-)
> >
> > diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
> > index 2a4d376a703e..4b9395d1bda7 100644
> > --- a/drivers/acpi/video_detect.c
> > +++ b/drivers/acpi/video_detect.c
> > @@ -599,81 +599,6 @@ static const struct dmi_system_id
> video_detect_dmi_table[] = {
> > DMI_MATCH(DMI_BOARD_NAME, "N250P"),
> > },
> > },
> > -   /*
> > -* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have
> both a
> > -* working native and video interface. However the default detection
> > -* mechanism first registers the video interface before unregistering
> > -* it again and switching to the native interface during boot. This
> > -* results in a dangling SBIOS request for backlight change for some
> > -* reason, causing the backlight to switch to ~2% once per boot on
> the
> > -* first power cord connect or disconnect event. Setting the native
> > -* interface explicitly circumvents this buggy behaviour, by avoiding
> > -* the unregistering process.
> > -*/
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xRU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xRU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR,
> "SchenkerTechnologiesGmbH"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xRU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xRU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xRU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xNU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xNU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR,
> "SchenkerTechnologiesGmbH"),
> > -   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
> > -   },
> > -   },
> > -   {
> > -   .callback = video_detect_force_native,
> > -   .ident = "Clevo NL5xNU",
> > -   .matches = {
> > -   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
> > -   DMI_MATCH(DMI_BO

Re: [PATCH v2 27/29] ACPI: video: Drop Clevo/TUXEDO NL5xRU and NL5xNU acpi_backlight=native quirks

2022-07-13 Thread Werner Sembach

Hi,

On 7/12/22 21:39, Hans de Goede wrote:

acpi_backlight=native is the default for these, but as the comment
explains the quirk was still necessary because even briefly registering
the acpi_video0 backlight; and then unregistering it once the native
driver showed up, was leading to issues.

After the "ACPI: video: Make backlight class device registration
a separate step" patch from earlier in this patch-series, we no
longer briefly register the acpi_video0 backlight on systems where
the native driver should be used.

So this is no longer an issue an the quirks are no longer needed.

Cc: Werner Sembach 
Signed-off-by: Hans de Goede 


Tested and can confirm: The quirks are no longer needed with this Patchset.

Tested-by: Werner Sembach 

Kind Regards,

Werner Sembach


---
  drivers/acpi/video_detect.c | 75 -
  1 file changed, 75 deletions(-)

diff --git a/drivers/acpi/video_detect.c b/drivers/acpi/video_detect.c
index 2a4d376a703e..4b9395d1bda7 100644
--- a/drivers/acpi/video_detect.c
+++ b/drivers/acpi/video_detect.c
@@ -599,81 +599,6 @@ static const struct dmi_system_id video_detect_dmi_table[] 
= {
DMI_MATCH(DMI_BOARD_NAME, "N250P"),
},
},
-   /*
-* Clevo NL5xRU and NL5xNU/TUXEDO Aura 15 Gen1 and Gen2 have both a
-* working native and video interface. However the default detection
-* mechanism first registers the video interface before unregistering
-* it again and switching to the native interface during boot. This
-* results in a dangling SBIOS request for backlight change for some
-* reason, causing the backlight to switch to ~2% once per boot on the
-* first power cord connect or disconnect event. Setting the native
-* interface explicitly circumvents this buggy behaviour, by avoiding
-* the unregistering process.
-*/
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xRU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "AURA1501"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xRU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "EDUBOOK1502"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "TUXEDO"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "SchenkerTechnologiesGmbH"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
-   {
-   .callback = video_detect_force_native,
-   .ident = "Clevo NL5xNU",
-   .matches = {
-   DMI_MATCH(DMI_SYS_VENDOR, "Notebook"),
-   DMI_MATCH(DMI_BOARD_NAME, "NL5xNU"),
-   },
-   },
  
  	/*

 * Desktops which falsely report a backlight and which our heuristics


[PATCH v2 13/13] drm/via: Fix style issues in via_3d_reg header

2022-07-13 Thread Sam Ravnborg
- Fix comments using wrong style
- Drop repeated word

This fixes all checkpatch complains and makes the file a little
bit easier to read - as the eye is not distracted by the style
violations.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Sam Ravnborg 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/via_3d_reg.h | 26 +-
 1 file changed, 13 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/via/via_3d_reg.h b/drivers/gpu/drm/via/via_3d_reg.h
index 4a884384e5b8..eb848508b12b 100644
--- a/drivers/gpu/drm/via/via_3d_reg.h
+++ b/drivers/gpu/drm/via/via_3d_reg.h
@@ -156,7 +156,7 @@
 #define HC_HSPXOS_SHIFT 12
 #define HC_HSPYOS_MASK  0x0fff
 
-/* Command
+/*
  * Command A
  */
 #define HC_HCmdHeader_MASK  0xfe00  /*0xffe0 */
@@ -1342,8 +1342,8 @@
 #define HC_HFthRTXA_MASK0x00ff
 
 /
-** Define the Halcyon Internal register access constants. For simulator only.
-/
+ * Define the Halcyon Internal register access constants. For simulator only.
+ ***/
 #define HC_SIMA_HAGPBstL0x
 #define HC_SIMA_HAGPBendL   0x0001
 #define HC_SIMA_HAGPCMNT0x0002
@@ -1592,8 +1592,8 @@
 #define HC_SIMA_FIFOstatus  0x0446
 
 /
-** Define the AGP command header.
-/
+ * Define the AGP command header.
+ ***/
 #define HC_ACMD_MASK0xfe00
 #define HC_ACMD_SUB_MASK0x0c00
 #define HC_ACMD_HCmdA   0xee00
@@ -1617,17 +1617,17 @@
 #define HC_ACMD_H4COUNT_SHIFT   9
 
 /*
-** Define Header
-*/
+ * Define Header
+ /
 #define HC_HEADER20xF210F110
 
 /*
-** Define Dummy Value
-*/
+ * Define Dummy Value
+ /
 #define HC_DUMMY0x
 /*
-** Define for DMA use
-*/
+ * Define for DMA use
+ /
 #define HALCYON_HEADER2 0XF210F110
 #define HALCYON_FIRECMD 0XEE10
 #define HALCYON_FIREMASK0XFFF0
@@ -1661,8 +1661,8 @@
 #define VIA_VIDEOMASK   0x
 
 /*
-** Define for H5 DMA use
-*/
+ * Define for H5 DMA use
+ /
 #define H5_HC_DUMMY0xCC00
 
 /* Command Header Type */
-- 
2.34.1



[PATCH v2 10/13] drm/via: Update to the latest via_3d_reg header

2022-07-13 Thread Sam Ravnborg
Updated the 3d_reg header file to match what is used by the openchrome
driver.
This verifies that the two drivers can use the same header file.

The file is a verbatim copy from the openchrome repo - a few style
issues will be fixed in following commits.

Signed-off-by: Sam Ravnborg 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/via_3d_reg.h | 395 ---
 1 file changed, 304 insertions(+), 91 deletions(-)

diff --git a/drivers/gpu/drm/via/via_3d_reg.h b/drivers/gpu/drm/via/via_3d_reg.h
index 462375d543b9..fc74647f512a 100644
--- a/drivers/gpu/drm/via/via_3d_reg.h
+++ b/drivers/gpu/drm/via/via_3d_reg.h
@@ -1,6 +1,6 @@
 /*
- * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
- * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
+ * Copyright 1998-2011 VIA Technologies, Inc. All Rights Reserved.
+ * Copyright 2001-2011 S3 Graphics, Inc. All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
@@ -16,7 +16,7 @@
  * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
  * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
  * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * VIA, S3 GRAPHICS, AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * THE AUTHOR(S) OR COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
  * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
  * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
  * DEALINGS IN THE SOFTWARE.
@@ -50,6 +50,7 @@
 #define HC_ParaType_Palette 0x0003
 #define HC_ParaType_PreCR   0x0010
 #define HC_ParaType_Auto0x00fe
+#define INV_ParaType_Dummy  0x0030
 
 /* Transmission Space
  */
@@ -176,7 +177,7 @@
 /* Command
  * Command A
  */
-#define HC_HCmdHeader_MASK  0xfe00 /*0xffe0 */
+#define HC_HCmdHeader_MASK  0xfe00  /*0xffe0 */
 #define HC_HE3Fire_MASK 0x0010
 #define HC_HPMType_MASK 0x000f
 #define HC_HEFlag_MASK  0xe000
@@ -236,6 +237,8 @@
 /* Enable Setting
  */
 #define HC_SubA_HEnable 0x
+#define HC_HenForce1P_MASK  0x0080  /* [Force 1 Pipe] */
+#define HC_HenZDCheck_MASK  0x0040  /* [Z dirty bit settings] */
 #define HC_HenTXEnvMap_MASK 0x0020
 #define HC_HenVertexCNT_MASK0x0010
 #define HC_HenCPUDAZ_MASK   0x0008
@@ -682,6 +685,12 @@
 #define HC_FogDenst_MASK0x001fff00
 #define HC_FogEndL_MASK 0x00ff
 
+/* Texture subtype definitions
+ */
+#define HC_SubType_Samp00x0020
+#define HC_SubType_Samp10x0021
+
+
 /* Texture subtype definitions
  */
 #define HC_SubType_Tex0 0x
@@ -762,7 +771,13 @@
 #define HC_SubA_HTXnBumpM10 0x0092
 #define HC_SubA_HTXnBumpM11 0x0093
 #define HC_SubA_HTXnLScale  0x0094
-#define HC_SubA_HTXSMD  0x
+
+#define HC_SubA_HTXSMD 0x
+#define HC_SubA_HTXYUV2RGB10x0001
+#define HC_SubA_HTXYUV2RGB20x0002
+#define HC_SubA_HTXYUV2RGB30x0003
+#define HTXYUV2RGB4BT601   (1<<23)
+#define HTXYUV2RGB4BT709   (1<<22)
 /* HC_SubA_HTXnL012BasH0x0020
  */
 #define HC_HTXnL0BasH_MASK  0x00ff
@@ -965,6 +980,7 @@
 #define HC_HTXnFM_Lum   0x0010
 #define HC_HTXnFM_Alpha 0x0018
 #define HC_HTXnFM_DX0x0028
+#define HC_HTXnFM_YUV   0x0030
 #define HC_HTXnFM_ARGB160x0088
 #define HC_HTXnFM_ARGB320x0098
 #define HC_HTXnFM_ABGR160x00a8
@@ -995,6 +1011,12 @@
 #define HC_HTXnFM_DX1   (HC_HTXnFM_DX| 0x0001)
 #define HC_HTXnFM_DX23  (HC_HTXnFM_DX| 0x0002)
 #define HC_HTXnFM_DX45  (HC_HTXnFM_DX| 0x0003)
+/* YUV package mode */
+#define HC_HTXnFM_YUY2  (HC_HTXnFM_YUV   | 0x)
+/* YUV planner mode */
+#define HC_HTXnFM_YV12  (HC_HTXnFM_YUV   | 0x0004)
+/* YUV planner mode */
+#define HC_HTXnFM_IYUV  (HC_HTXnFM_YUV   | 0x0004)
 #define HC_HTXnFM_RGB555(HC_HTXnFM_ARGB16| 0x)
 #define HC_HTXnFM_RGB565(HC_HTXnFM_ARGB16| 0x0001)
 #define HC_HTXnFM_ARGB1555  (HC_HTXnFM_ARGB16| 0x0002)
@@ -1023,6 +1045,13 @@
 #define HC_HTXnLoc_Local0x
 #define HC_HTXnLoc_Sys  0x0002
 #define HC_HTXnLoc_AGP  0x0003
+
+/* Video Texture */
+#define HC_HTXnYUV2RGBMode_RGB  0x
+#define HC_HTXnYUV2RGBMode_SDTV 0x0001
+#define HC_HTXnYUV2RGBMode_HDTV 0x0002
+#define HC_HTXnYUV2RGBMode_TABLE0x0003
+
 /* HC_SubA_HTXnTRAH0x007f
  */
 #define HC_HTXnTRAH_MASK0x00ff
@@ -1330,9 +1359,9 @@
  */
 #define HC_HFthRTXA_MASK0x00ff
 
-/

[PATCH v2 12/13] drm/via: Make macros readable in the via_3d_reg header

2022-07-13 Thread Sam Ravnborg
The macros for texture 1 settinig all used continuation on a new line,
resulting in a highly ureadable definition.
Merge the lines so they are on a single line each.

As a nice side-effect this fixes a number of checkpatch warnings:
"WARNING: please, no spaces at the start of a line"i.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Sam Ravnborg 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/via_3d_reg.h | 222 +++
 1 file changed, 74 insertions(+), 148 deletions(-)

diff --git a/drivers/gpu/drm/via/via_3d_reg.h b/drivers/gpu/drm/via/via_3d_reg.h
index 8796fc9fd44b..4a884384e5b8 100644
--- a/drivers/gpu/drm/via/via_3d_reg.h
+++ b/drivers/gpu/drm/via/via_3d_reg.h
@@ -1488,154 +1488,80 @@
 #define HC_SIMA_TX0TX1_OFF  0x0050
 /* start of texture 1 setting 
  */
-#define HC_SIMA_HTX1L0BasL  \
-(HC_SIMA_HTX0L0BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L1BasL  \
-(HC_SIMA_HTX0L1BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L2BasL  \
-(HC_SIMA_HTX0L2BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L3BasL  \
-(HC_SIMA_HTX0L3BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L4BasL  (\
-HC_SIMA_HTX0L4BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L5BasL  \
-(HC_SIMA_HTX0L5BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L6BasL  \
-(HC_SIMA_HTX0L6BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L7BasL  \
-(HC_SIMA_HTX0L7BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L8BasL  \
-(HC_SIMA_HTX0L8BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L9BasL  \
-(HC_SIMA_HTX0L9BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LaBasL  \
-(HC_SIMA_HTX0LaBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LbBasL  \
-(HC_SIMA_HTX0LbBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LcBasL  \
-(HC_SIMA_HTX0LcBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LdBasL  \
-(HC_SIMA_HTX0LdBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LeBasL  \
-(HC_SIMA_HTX0LeBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LfBasL  \
-(HC_SIMA_HTX0LfBasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L10BasL \
-(HC_SIMA_HTX0L10BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L11BasL \
-(HC_SIMA_HTX0L11BasL + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L012BasH\
-(HC_SIMA_HTX0L012BasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L345BasH\
-(HC_SIMA_HTX0L345BasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L678BasH\
-(HC_SIMA_HTX0L678BasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L9abBasH\
-(HC_SIMA_HTX0L9abBasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LcdeBasH\
-(HC_SIMA_HTX0LcdeBasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1Lf1011BasH  \
-(HC_SIMA_HTX0Lf1011BasH + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L0Pit   \
-(HC_SIMA_HTX0L0Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L1Pit   \
-(HC_SIMA_HTX0L1Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L2Pit   \
-(HC_SIMA_HTX0L2Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L3Pit   \
-(HC_SIMA_HTX0L3Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L4Pit   \
-(HC_SIMA_HTX0L4Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L5Pit   \
-(HC_SIMA_HTX0L5Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L6Pit   \
-(HC_SIMA_HTX0L6Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L7Pit   \
-(HC_SIMA_HTX0L7Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L8Pit   \
-(HC_SIMA_HTX0L8Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L9Pit   \
-(HC_SIMA_HTX0L9Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LaPit   \
-(HC_SIMA_HTX0LaPit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LbPit   \
-(HC_SIMA_HTX0LbPit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LcPit   \
-(HC_SIMA_HTX0LcPit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LdPit   \
-(HC_SIMA_HTX0LdPit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LePit   \
-(HC_SIMA_HTX0LePit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1LfPit   \
-(HC_SIMA_HTX0LfPit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L10Pit  \
-(HC_SIMA_HTX0L10Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L11Pit  \
-(HC_SIMA_HTX0L11Pit + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L0_5WE  \
-(HC_SIMA_HTX0L0_5WE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L6_bWE  \
-(HC_SIMA_HTX0L6_bWE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1Lc_11WE \
-(HC_SIMA_HTX0Lc_11WE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L0_5HE  \
-(HC_SIMA_HTX0L0_5HE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L6_bHE  \
-(HC_SIMA_HTX0L6_bHE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1Lc_11HE  \
-(HC_SIMA_HTX0Lc_11HE + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1L0OS\
-(HC_SIMA_HTX0L0OS + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1TB  \
-(HC_SIMA_HTX0TB + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_HTX1MPMD\
-(HC_SIMA_HTX0MPMD + HC_SIMA_TX0TX1_OFF)
-#define HC_SIMA_

[PATCH v2 11/13] drm/via: Use SPDX tag for MIT license in via_3d_reg header

2022-07-13 Thread Sam Ravnborg
The license for the via_3d_reg header is MIT - so use the
shorter SPDX tag to identify the license.

Suggested-by: Thomas Zimmermann 
Signed-off-by: Sam Ravnborg 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/via_3d_reg.h | 20 +---
 1 file changed, 1 insertion(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/via/via_3d_reg.h b/drivers/gpu/drm/via/via_3d_reg.h
index fc74647f512a..8796fc9fd44b 100644
--- a/drivers/gpu/drm/via/via_3d_reg.h
+++ b/drivers/gpu/drm/via/via_3d_reg.h
@@ -1,25 +1,7 @@
+/* SPDX-License-Identifier: MIT */
 /*
  * Copyright 1998-2011 VIA Technologies, Inc. All Rights Reserved.
  * Copyright 2001-2011 S3 Graphics, Inc. All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sub license,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE AUTHOR(S) OR COPYRIGHT HOLDER(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
- * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
- * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
- * DEALINGS IN THE SOFTWARE.
  */
 
 #ifndef VIA_3D_REG_H
-- 
2.34.1



[PATCH v2 09/13] drm/via: Embed via_drv.h in via_dri1

2022-07-13 Thread Sam Ravnborg
With this change the driver is now a signle file driver.
The only remaning heder file describes the HW and can be shared with the
new openchrome driver.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/via_dri1.c | 229 +++-
 drivers/gpu/drm/via/via_drv.h  | 265 -
 2 files changed, 228 insertions(+), 266 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_drv.h

diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index f9285cc3e1c7..d695d9291ece 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -36,13 +36,240 @@
 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include 
+#include 
 #include 
 #include 
 
-#include "via_drv.h"
 #include "via_3d_reg.h"
 
+#define DRIVER_AUTHOR  "Various"
+
+#define DRIVER_NAME"via"
+#define DRIVER_DESC"VIA Unichrome / Pro"
+#define DRIVER_DATE"20070202"
+
+#define DRIVER_MAJOR   2
+#define DRIVER_MINOR   11
+#define DRIVER_PATCHLEVEL  1
+
+typedef enum {
+   no_sequence = 0,
+   z_address,
+   dest_address,
+   tex_address
+} drm_via_sequence_t;
+
+typedef struct {
+   unsigned texture;
+   uint32_t z_addr;
+   uint32_t d_addr;
+   uint32_t t_addr[2][10];
+   uint32_t pitch[2][10];
+   uint32_t height[2][10];
+   uint32_t tex_level_lo[2];
+   uint32_t tex_level_hi[2];
+   uint32_t tex_palette_size[2];
+   uint32_t tex_npot[2];
+   drm_via_sequence_t unfinished;
+   int agp_texture;
+   int multitex;
+   struct drm_device *dev;
+   drm_local_map_t *map_cache;
+   uint32_t vertex_count;
+   int agp;
+   const uint32_t *buf_start;
+} drm_via_state_t;
+
+#define VIA_PCI_BUF_SIZE 6
+#define VIA_FIRE_BUF_SIZE  1024
+#define VIA_NUM_IRQS 4
+
+
+#define VIA_NUM_BLIT_ENGINES 2
+#define VIA_NUM_BLIT_SLOTS 8
+
+struct _drm_via_descriptor;
+
+typedef struct _drm_via_sg_info {
+   struct page **pages;
+   unsigned long num_pages;
+   struct _drm_via_descriptor **desc_pages;
+   int num_desc_pages;
+   int num_desc;
+   enum dma_data_direction direction;
+   unsigned char *bounce_buffer;
+   dma_addr_t chain_start;
+   uint32_t free_on_sequence;
+   unsigned int descriptors_per_page;
+   int aborted;
+   enum {
+   dr_via_device_mapped,
+   dr_via_desc_pages_alloc,
+   dr_via_pages_locked,
+   dr_via_pages_alloc,
+   dr_via_sg_init
+   } state;
+} drm_via_sg_info_t;
+
+typedef struct _drm_via_blitq {
+   struct drm_device *dev;
+   uint32_t cur_blit_handle;
+   uint32_t done_blit_handle;
+   unsigned serviced;
+   unsigned head;
+   unsigned cur;
+   unsigned num_free;
+   unsigned num_outstanding;
+   unsigned long end;
+   int aborting;
+   int is_active;
+   drm_via_sg_info_t *blits[VIA_NUM_BLIT_SLOTS];
+   spinlock_t blit_lock;
+   wait_queue_head_t blit_queue[VIA_NUM_BLIT_SLOTS];
+   wait_queue_head_t busy_queue;
+   struct work_struct wq;
+   struct timer_list poll_timer;
+} drm_via_blitq_t;
+
+typedef struct drm_via_ring_buffer {
+   drm_local_map_t map;
+   char *virtual_start;
+} drm_via_ring_buffer_t;
+
+typedef uint32_t maskarray_t[5];
+
+typedef struct drm_via_irq {
+   atomic_t irq_received;
+   uint32_t pending_mask;
+   uint32_t enable_mask;
+   wait_queue_head_t irq_queue;
+} drm_via_irq_t;
+
+typedef struct drm_via_private {
+   drm_via_sarea_t *sarea_priv;
+   drm_local_map_t *sarea;
+   drm_local_map_t *fb;
+   drm_local_map_t *mmio;
+   unsigned long agpAddr;
+   wait_queue_head_t decoder_queue[VIA_NR_XVMC_LOCKS];
+   char *dma_ptr;
+   unsigned int dma_low;
+   unsigned int dma_high;
+   unsigned int dma_offset;
+   uint32_t dma_wrap;
+   volatile uint32_t *last_pause_ptr;
+   volatile uint32_t *hw_addr_ptr;
+   drm_via_ring_buffer_t ring;
+   ktime_t last_vblank;
+   int last_vblank_valid;
+   ktime_t nsec_per_vblank;
+   atomic_t vbl_received;
+   drm_via_state_t hc_state;
+   char pci_buf[VIA_PCI_BUF_SIZE];
+   const uint32_t *fire_offsets[VIA_FIRE_BUF_SIZE];
+   uint32_t num_fire_offsets;
+   int chipset;
+   drm_via_irq_t via_irqs[VIA_NUM_IRQS];
+   unsigned num_irqs;
+   maskarray_t *irq_masks;
+   uint32_t irq_enable_mask;
+   uint32_t irq_pending_mask;
+   int *irq_map;
+   unsigned int idle_fault;
+   int vram_initialized;
+   struct drm_mm vram_mm;
+   int agp_initialized;
+   struct drm_mm agp_mm;
+   /** Mapping of userspace keys to mm objects */
+   struct idr object_idr;
+   unsigned long vram_offset;
+   unsigned long agp_offset;
+   drm_via_blitq_t blit_queues[VIA_NUM_BLIT_ENGI

[PATCH v2 07/13] drm/via: Embed via_dmablit in via_dri1

2022-07-13 Thread Sam Ravnborg
Embed some of the header file in via_drv.h and
the rest in via_dri1.c
While embedding deleted extra empty lines and functions that
has no external users are made static.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile  |   2 +-
 drivers/gpu/drm/via/via_dmablit.c | 807 --
 drivers/gpu/drm/via/via_dmablit.h | 140 --
 drivers/gpu/drm/via/via_dri1.c| 786 +
 drivers/gpu/drm/via/via_drv.h |  56 ++-
 5 files changed, 835 insertions(+), 956 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_dmablit.c
 delete mode 100644 drivers/gpu/drm/via/via_dmablit.h

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index dd75ea8a1423..66125b150478 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_dri1.o via_verifier.o via_dmablit.o
+via-y:= via_dri1.o via_verifier.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dmablit.c 
b/drivers/gpu/drm/via/via_dmablit.c
deleted file mode 100644
index e016a4d62090..
--- a/drivers/gpu/drm/via/via_dmablit.c
+++ /dev/null
@@ -1,807 +0,0 @@
-/* via_dmablit.c -- PCI DMA BitBlt support for the VIA Unichrome/Pro
- *
- * Copyright (C) 2005 Thomas Hellstrom, All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sub license,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- *Thomas Hellstrom.
- *Partially based on code obtained from Digeo Inc.
- */
-
-
-/*
- * Unmaps the DMA mappings.
- * FIXME: Is this a NoOp on x86? Also
- * FIXME: What happens if this one is called and a pending blit has previously 
done
- * the same DMA mappings?
- */
-
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include "via_dmablit.h"
-#include "via_drv.h"
-
-#define VIA_PGDN(x) (((unsigned long)(x)) & PAGE_MASK)
-#define VIA_PGOFF(x)   (((unsigned long)(x)) & ~PAGE_MASK)
-#define VIA_PFN(x)   ((unsigned long)(x) >> PAGE_SHIFT)
-
-typedef struct _drm_via_descriptor {
-   uint32_t mem_addr;
-   uint32_t dev_addr;
-   uint32_t size;
-   uint32_t next;
-} drm_via_descriptor_t;
-
-
-/*
- * Unmap a DMA mapping.
- */
-
-
-
-static void
-via_unmap_blit_from_device(struct pci_dev *pdev, drm_via_sg_info_t *vsg)
-{
-   int num_desc = vsg->num_desc;
-   unsigned cur_descriptor_page = num_desc / vsg->descriptors_per_page;
-   unsigned descriptor_this_page = num_desc % vsg->descriptors_per_page;
-   drm_via_descriptor_t *desc_ptr = vsg->desc_pages[cur_descriptor_page] +
-   descriptor_this_page;
-   dma_addr_t next = vsg->chain_start;
-
-   while (num_desc--) {
-   if (descriptor_this_page-- == 0) {
-   cur_descriptor_page--;
-   descriptor_this_page = vsg->descriptors_per_page - 1;
-   desc_ptr = vsg->desc_pages[cur_descriptor_page] +
-   descriptor_this_page;
-   }
-   dma_unmap_single(&pdev->dev, next, sizeof(*desc_ptr), 
DMA_TO_DEVICE);
-   dma_unmap_page(&pdev->dev, desc_ptr->mem_addr, desc_ptr->size, 
vsg->direction);
-   next = (dma_addr_t) desc_ptr->next;
-   desc_ptr--;
-   }
-}
-
-/*
- * If mode = 0, count how many descriptors are needed.
- * If mode = 1, Map the DMA pages for the device, put together and map also 
the descriptors.
- * Descriptors are run in reverse order by the hardware because we are not 
allowed to update the
- * 'next' field without syncing calls when the descriptor is already mapped.
- */
-
-static void
-via_map_blit_for_device(struct pci_dev *pdev,
-  const drm_via_dma

[PATCH v2 08/13] drm/via: Embed via_verifier in via_dri1

2022-07-13 Thread Sam Ravnborg
Embed the header file in via_drv.h and the code in via_dri1.
All functions are made static as there are no more external users.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile   |2 +-
 drivers/gpu/drm/via/via_dri1.c | 1071 +++
 drivers/gpu/drm/via/via_drv.h  |   29 +-
 drivers/gpu/drm/via/via_verifier.c | 1110 
 drivers/gpu/drm/via/via_verifier.h |   62 --
 5 files changed, 1099 insertions(+), 1175 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_verifier.c
 delete mode 100644 drivers/gpu/drm/via/via_verifier.h

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index 66125b150478..8b978dd51a25 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_dri1.o via_verifier.o
+via-y:= via_dri1.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index f8b1f837feb1..f9285cc3e1c7 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -201,7 +201,1078 @@ typedef struct _drm_via_descriptor {
uint32_t next;
 } drm_via_descriptor_t;
 
+typedef enum {
+   state_command,
+   state_header2,
+   state_header1,
+   state_vheader5,
+   state_vheader6,
+   state_error
+} verifier_state_t;
+
+typedef enum {
+   no_check = 0,
+   check_for_header2,
+   check_for_header1,
+   check_for_header2_err,
+   check_for_header1_err,
+   check_for_fire,
+   check_z_buffer_addr0,
+   check_z_buffer_addr1,
+   check_z_buffer_addr_mode,
+   check_destination_addr0,
+   check_destination_addr1,
+   check_destination_addr_mode,
+   check_for_dummy,
+   check_for_dd,
+   check_texture_addr0,
+   check_texture_addr1,
+   check_texture_addr2,
+   check_texture_addr3,
+   check_texture_addr4,
+   check_texture_addr5,
+   check_texture_addr6,
+   check_texture_addr7,
+   check_texture_addr8,
+   check_texture_addr_mode,
+   check_for_vertex_count,
+   check_number_texunits,
+   forbidden_command
+} hazard_t;
 
+/*
+ * Associates each hazard above with a possible multi-command
+ * sequence. For example an address that is split over multiple
+ * commands and that needs to be checked at the first command
+ * that does not include any part of the address.
+ */
+
+static drm_via_sequence_t seqs[] = {
+   no_sequence,
+   no_sequence,
+   no_sequence,
+   no_sequence,
+   no_sequence,
+   no_sequence,
+   z_address,
+   z_address,
+   z_address,
+   dest_address,
+   dest_address,
+   dest_address,
+   no_sequence,
+   no_sequence,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   tex_address,
+   no_sequence
+};
+
+typedef struct {
+   unsigned int code;
+   hazard_t hz;
+} hz_init_t;
+
+static hz_init_t init_table1[] = {
+   {0xf2, check_for_header2_err},
+   {0xf0, check_for_header1_err},
+   {0xee, check_for_fire},
+   {0xcc, check_for_dummy},
+   {0xdd, check_for_dd},
+   {0x00, no_check},
+   {0x10, check_z_buffer_addr0},
+   {0x11, check_z_buffer_addr1},
+   {0x12, check_z_buffer_addr_mode},
+   {0x13, no_check},
+   {0x14, no_check},
+   {0x15, no_check},
+   {0x23, no_check},
+   {0x24, no_check},
+   {0x33, no_check},
+   {0x34, no_check},
+   {0x35, no_check},
+   {0x36, no_check},
+   {0x37, no_check},
+   {0x38, no_check},
+   {0x39, no_check},
+   {0x3A, no_check},
+   {0x3B, no_check},
+   {0x3C, no_check},
+   {0x3D, no_check},
+   {0x3E, no_check},
+   {0x40, check_destination_addr0},
+   {0x41, check_destination_addr1},
+   {0x42, check_destination_addr_mode},
+   {0x43, no_check},
+   {0x44, no_check},
+   {0x50, no_check},
+   {0x51, no_check},
+   {0x52, no_check},
+   {0x53, no_check},
+   {0x54, no_check},
+   {0x55, no_check},
+   {0x56, no_check},
+   {0x57, no_check},
+   {0x58, no_check},
+   {0x70, no_check},
+   {0x71, no_check},
+   {0x78, no_check},
+   {0x79, no_check},
+   {0x7A, no_check},
+   {0x7B, no_check},
+   {0x7C, no_check},
+   {0x7D, check_for_vertex_count}
+};
+
+static hz_init_t init_table2[] = {
+   {0xf2, check_for_header2_err},
+   {0xf0, check_for_header1_err},
+   {0xee, check_for_fire},
+   {0xcc, check_for_dummy},
+   {0x00, check_texture_addr0},
+   {0x01, check_texture_addr0},
+   {0x02

[PATCH v2 04/13] drm/via: Embed via_mm in via_dri1

2022-07-13 Thread Sam Ravnborg
All functions was made static as there are no external users.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile   |   2 +-
 drivers/gpu/drm/via/via_dri1.c | 208 
 drivers/gpu/drm/via/via_drv.h  |   9 --
 drivers/gpu/drm/via/via_mm.c   | 241 -
 4 files changed, 209 insertions(+), 251 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_mm.c

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index be12cbfa4d7f..daadc0d3233f 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_dri1.o via_mm.o via_verifier.o via_video.o 
via_dmablit.o
+via-y:= via_irq.o via_dri1.o via_verifier.o via_video.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index 2fa22359b1f6..3ebe17649ec2 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -2,6 +2,7 @@
  * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
  * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
  * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. All Rights 
Reserved.
+ * Copyright 2006 Tungsten Graphics Inc., Bismarck, ND., USA.
  * Copyright 2004 Digeo, Inc., Palo Alto, CA, U.S.A. All Rights Reserved.
  * Copyright 2004 The Unichrome project. All Rights Reserved.
   *
@@ -67,6 +68,213 @@
dev_priv->dma_low += 8; \
 } while (0)
 
+#define VIA_MM_ALIGN_SHIFT 4
+#define VIA_MM_ALIGN_MASK ((1 << VIA_MM_ALIGN_SHIFT) - 1)
+
+struct via_memblock {
+   struct drm_mm_node mm_node;
+   struct list_head owner_list;
+};
+
+static int via_agp_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
+{
+   drm_via_agp_t *agp = data;
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+
+   mutex_lock(&dev->struct_mutex);
+   drm_mm_init(&dev_priv->agp_mm, 0, agp->size >> VIA_MM_ALIGN_SHIFT);
+
+   dev_priv->agp_initialized = 1;
+   dev_priv->agp_offset = agp->offset;
+   mutex_unlock(&dev->struct_mutex);
+
+   DRM_DEBUG("offset = %u, size = %u\n", agp->offset, agp->size);
+   return 0;
+}
+
+static int via_fb_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
+{
+   drm_via_fb_t *fb = data;
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+
+   mutex_lock(&dev->struct_mutex);
+   drm_mm_init(&dev_priv->vram_mm, 0, fb->size >> VIA_MM_ALIGN_SHIFT);
+
+   dev_priv->vram_initialized = 1;
+   dev_priv->vram_offset = fb->offset;
+
+   mutex_unlock(&dev->struct_mutex);
+   DRM_DEBUG("offset = %u, size = %u\n", fb->offset, fb->size);
+
+   return 0;
+
+}
+
+static int via_final_context(struct drm_device *dev, int context)
+{
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+
+   via_release_futex(dev_priv, context);
+
+   /* Linux specific until context tracking code gets ported to BSD */
+   /* Last context, perform cleanup */
+   if (list_is_singular(&dev->ctxlist)) {
+   DRM_DEBUG("Last Context\n");
+   drm_legacy_irq_uninstall(dev);
+   via_cleanup_futex(dev_priv);
+   via_do_cleanup_map(dev);
+   }
+   return 1;
+}
+
+static void via_lastclose(struct drm_device *dev)
+{
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+
+   if (!dev_priv)
+   return;
+
+   mutex_lock(&dev->struct_mutex);
+   if (dev_priv->vram_initialized) {
+   drm_mm_takedown(&dev_priv->vram_mm);
+   dev_priv->vram_initialized = 0;
+   }
+   if (dev_priv->agp_initialized) {
+   drm_mm_takedown(&dev_priv->agp_mm);
+   dev_priv->agp_initialized = 0;
+   }
+   mutex_unlock(&dev->struct_mutex);
+}
+
+static int via_mem_alloc(struct drm_device *dev, void *data,
+ struct drm_file *file)
+{
+   drm_via_mem_t *mem = data;
+   int retval = 0, user_key;
+   struct via_memblock *item;
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+   struct via_file_private *file_priv = file->driver_priv;
+   unsigned long tmpSize;
+
+   if (mem->type > VIA_MEM_AGP) {
+   DRM_ERROR("Unknown memory type allocation\n");
+   return -EINVAL;
+   }
+   mutex_lock(&dev->struct_mutex);
+   if (0 == ((mem->type == VIA_MEM_VIDEO) ? dev_priv->vram_initialized :
+ dev_priv->agp_initialized)) {
+   mutex_unlock(&dev->struct_mutex);
+   DRM_ERROR
+   ("Attempt to allocate from uninitialized memo

[PATCH v2 05/13] drm/via: Embed via_video in via_dri1

2022-07-13 Thread Sam Ravnborg
All functions are made static as there are no more external users.
The file had a new copyright that is kept.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile|  2 +-
 drivers/gpu/drm/via/via_dri1.c  | 66 ++-
 drivers/gpu/drm/via/via_drv.h   |  4 --
 drivers/gpu/drm/via/via_video.c | 94 -
 4 files changed, 66 insertions(+), 100 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_video.c

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index daadc0d3233f..398be21c6df8 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_dri1.o via_verifier.o via_video.o via_dmablit.o
+via-y:= via_irq.o via_dri1.o via_verifier.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index 3ebe17649ec2..4c5517330110 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -5,7 +5,8 @@
  * Copyright 2006 Tungsten Graphics Inc., Bismarck, ND., USA.
  * Copyright 2004 Digeo, Inc., Palo Alto, CA, U.S.A. All Rights Reserved.
  * Copyright 2004 The Unichrome project. All Rights Reserved.
-  *
+ * Copyright 2005 Thomas Hellstrom. All Rights Reserved.
+ *
  * Permission is hereby granted, free of charge, to any person obtaining a
  * copy of this software and associated documentation files (the "Software"),
  * to deal in the Software without restriction, including without limitation
@@ -76,6 +77,69 @@ struct via_memblock {
struct list_head owner_list;
 };
 
+static void via_init_futex(drm_via_private_t *dev_priv)
+{
+   unsigned int i;
+
+   DRM_DEBUG("\n");
+
+   for (i = 0; i < VIA_NR_XVMC_LOCKS; ++i) {
+   init_waitqueue_head(&(dev_priv->decoder_queue[i]));
+   XVMCLOCKPTR(dev_priv->sarea_priv, i)->lock = 0;
+   }
+}
+
+static void via_cleanup_futex(drm_via_private_t *dev_priv)
+{
+}
+
+static void via_release_futex(drm_via_private_t *dev_priv, int context)
+{
+   unsigned int i;
+   volatile int *lock;
+
+   if (!dev_priv->sarea_priv)
+   return;
+
+   for (i = 0; i < VIA_NR_XVMC_LOCKS; ++i) {
+   lock = (volatile int *)XVMCLOCKPTR(dev_priv->sarea_priv, i);
+   if ((_DRM_LOCKING_CONTEXT(*lock) == context)) {
+   if (_DRM_LOCK_IS_HELD(*lock)
+   && (*lock & _DRM_LOCK_CONT)) {
+   wake_up(&(dev_priv->decoder_queue[i]));
+   }
+   *lock = 0;
+   }
+   }
+}
+
+static int via_decoder_futex(struct drm_device *dev, void *data, struct 
drm_file *file_priv)
+{
+   drm_via_futex_t *fx = data;
+   volatile int *lock;
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+   drm_via_sarea_t *sAPriv = dev_priv->sarea_priv;
+   int ret = 0;
+
+   DRM_DEBUG("\n");
+
+   if (fx->lock >= VIA_NR_XVMC_LOCKS)
+   return -EFAULT;
+
+   lock = (volatile int *)XVMCLOCKPTR(sAPriv, fx->lock);
+
+   switch (fx->func) {
+   case VIA_FUTEX_WAIT:
+   VIA_WAIT_ON(ret, dev_priv->decoder_queue[fx->lock],
+   (fx->ms / 10) * (HZ / 100), *lock != fx->val);
+   return ret;
+   case VIA_FUTEX_WAKE:
+   wake_up(&(dev_priv->decoder_queue[fx->lock]));
+   return 0;
+   }
+   return 0;
+}
+
 static int via_agp_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
 {
drm_via_agp_t *agp = data;
diff --git a/drivers/gpu/drm/via/via_drv.h b/drivers/gpu/drm/via/via_drv.h
index c1a5fdf0bc4b..312e86b850f6 100644
--- a/drivers/gpu/drm/via/via_drv.h
+++ b/drivers/gpu/drm/via/via_drv.h
@@ -183,7 +183,6 @@ do {
\
remove_wait_queue(&(queue), &entry);\
 } while (0)
 
-extern int via_decoder_futex(struct drm_device *dev, void *data, struct 
drm_file *file_priv);
 extern int via_wait_irq(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
 extern int via_dma_blit_sync(struct drm_device *dev, void *data, struct 
drm_file *file_priv);
 extern int via_dma_blit(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
@@ -203,9 +202,6 @@ extern void via_driver_irq_uninstall(struct drm_device 
*dev);
 extern int via_dma_cleanup(struct drm_device *dev);
 extern void via_init_command_verifier(void);
 extern int via_driver_dma_quiescent(struct drm_device *dev);
-extern void via_init_futex(drm_via_private_t *dev_priv);
-extern void via_cleanup_futex(drm_via_private_t *dev_priv);
-extern void via_release_futex(drm_via_private_

[PATCH v2 06/13] drm/via: Embed via_irq in via_dri1

2022-07-13 Thread Sam Ravnborg
All functions are made static as there are no more external users.
The file had new copyrights that are kept.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile   |   2 +-
 drivers/gpu/drm/via/via_dri1.c | 347 +
 drivers/gpu/drm/via/via_drv.h  |   9 -
 drivers/gpu/drm/via/via_irq.c  | 388 -
 4 files changed, 348 insertions(+), 398 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_irq.c

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index 398be21c6df8..dd75ea8a1423 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_dri1.o via_verifier.o via_dmablit.o
+via-y:= via_dri1.o via_verifier.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index 4c5517330110..32aae172c6f3 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -1,10 +1,12 @@
 /*
  * Copyright 1998-2003 VIA Technologies, Inc. All Rights Reserved.
  * Copyright 2001-2003 S3 Graphics, Inc. All Rights Reserved.
+ * Copyright 2002 Tungsten Graphics, Inc.
  * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas. All Rights 
Reserved.
  * Copyright 2006 Tungsten Graphics Inc., Bismarck, ND., USA.
  * Copyright 2004 Digeo, Inc., Palo Alto, CA, U.S.A. All Rights Reserved.
  * Copyright 2004 The Unichrome project. All Rights Reserved.
+ * Copyright 2004 BEAM Ltd.
  * Copyright 2005 Thomas Hellstrom. All Rights Reserved.
  *
  * Permission is hereby granted, free of charge, to any person obtaining a
@@ -77,6 +79,351 @@ struct via_memblock {
struct list_head owner_list;
 };
 
+#define VIA_REG_INTERRUPT   0x200
+
+/* VIA_REG_INTERRUPT */
+#define VIA_IRQ_GLOBAL   (1 << 31)
+#define VIA_IRQ_VBLANK_ENABLE   (1 << 19)
+#define VIA_IRQ_VBLANK_PENDING  (1 << 3)
+#define VIA_IRQ_HQV0_ENABLE (1 << 11)
+#define VIA_IRQ_HQV1_ENABLE (1 << 25)
+#define VIA_IRQ_HQV0_PENDING(1 << 9)
+#define VIA_IRQ_HQV1_PENDING(1 << 10)
+#define VIA_IRQ_DMA0_DD_ENABLE  (1 << 20)
+#define VIA_IRQ_DMA0_TD_ENABLE  (1 << 21)
+#define VIA_IRQ_DMA1_DD_ENABLE  (1 << 22)
+#define VIA_IRQ_DMA1_TD_ENABLE  (1 << 23)
+#define VIA_IRQ_DMA0_DD_PENDING (1 << 4)
+#define VIA_IRQ_DMA0_TD_PENDING (1 << 5)
+#define VIA_IRQ_DMA1_DD_PENDING (1 << 6)
+#define VIA_IRQ_DMA1_TD_PENDING (1 << 7)
+
+/*
+ * Device-specific IRQs go here. This type might need to be extended with
+ * the register if there are multiple IRQ control registers.
+ * Currently we activate the HQV interrupts of  Unichrome Pro group A.
+ */
+
+static maskarray_t via_pro_group_a_irqs[] = {
+   {VIA_IRQ_HQV0_ENABLE, VIA_IRQ_HQV0_PENDING, 0x03D0, 0x8010,
+0x },
+   {VIA_IRQ_HQV1_ENABLE, VIA_IRQ_HQV1_PENDING, 0x13D0, 0x8010,
+0x },
+   {VIA_IRQ_DMA0_TD_ENABLE, VIA_IRQ_DMA0_TD_PENDING, VIA_PCI_DMA_CSR0,
+VIA_DMA_CSR_TA | VIA_DMA_CSR_TD, 0x0008},
+   {VIA_IRQ_DMA1_TD_ENABLE, VIA_IRQ_DMA1_TD_PENDING, VIA_PCI_DMA_CSR1,
+VIA_DMA_CSR_TA | VIA_DMA_CSR_TD, 0x0008},
+};
+static int via_num_pro_group_a = ARRAY_SIZE(via_pro_group_a_irqs);
+static int via_irqmap_pro_group_a[] = {0, 1, -1, 2, -1, 3};
+
+static maskarray_t via_unichrome_irqs[] = {
+   {VIA_IRQ_DMA0_TD_ENABLE, VIA_IRQ_DMA0_TD_PENDING, VIA_PCI_DMA_CSR0,
+VIA_DMA_CSR_TA | VIA_DMA_CSR_TD, 0x0008},
+   {VIA_IRQ_DMA1_TD_ENABLE, VIA_IRQ_DMA1_TD_PENDING, VIA_PCI_DMA_CSR1,
+VIA_DMA_CSR_TA | VIA_DMA_CSR_TD, 0x0008}
+};
+static int via_num_unichrome = ARRAY_SIZE(via_unichrome_irqs);
+static int via_irqmap_unichrome[] = {-1, -1, -1, 0, -1, 1};
+
+
+static u32 via_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
+{
+   drm_via_private_t *dev_priv = dev->dev_private;
+
+   if (pipe != 0)
+   return 0;
+
+   return atomic_read(&dev_priv->vbl_received);
+}
+
+static irqreturn_t via_driver_irq_handler(int irq, void *arg)
+{
+   struct drm_device *dev = (struct drm_device *) arg;
+   drm_via_private_t *dev_priv = (drm_via_private_t *) dev->dev_private;
+   u32 status;
+   int handled = 0;
+   ktime_t cur_vblank;
+   drm_via_irq_t *cur_irq = dev_priv->via_irqs;
+   int i;
+
+   status = via_read(dev_priv, VIA_REG_INTERRUPT);
+   if (status & VIA_IRQ_VBLANK_PENDING) {
+   atomic_inc(&dev_priv->vbl_received);
+   if (!(atomic_read(&dev_priv->vbl_received) & 0x0F)) {
+   cur_vblank = ktime_get();
+   if (dev_priv->last_vblank_valid) {
+   dev_priv->nsec_per_vblank =
+   ktime_sub(cur_vblank,
+  

[PATCH v2 03/13] drm/via: Embed via_map in via_dri1

2022-07-13 Thread Sam Ravnborg
A few functions has no external use and are made static.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile   |   2 +-
 drivers/gpu/drm/via/via_dri1.c | 102 +
 drivers/gpu/drm/via/via_drv.h  |   4 -
 drivers/gpu/drm/via/via_map.c  | 132 -
 4 files changed, 103 insertions(+), 137 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_map.c

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index 824198c0c2ea..be12cbfa4d7f 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_dri1.o via_map.o via_mm.o via_verifier.o via_video.o 
via_dmablit.o
+via-y:= via_irq.o via_dri1.o via_mm.o via_verifier.o via_video.o 
via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dri1.c b/drivers/gpu/drm/via/via_dri1.c
index d5d4a64437da..2fa22359b1f6 100644
--- a/drivers/gpu/drm/via/via_dri1.c
+++ b/drivers/gpu/drm/via/via_dri1.c
@@ -32,6 +32,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #include "via_drv.h"
@@ -66,6 +67,107 @@
dev_priv->dma_low += 8; \
 } while (0)
 
+static int via_do_init_map(struct drm_device *dev, drm_via_init_t *init)
+{
+   drm_via_private_t *dev_priv = dev->dev_private;
+
+   DRM_DEBUG("\n");
+
+   dev_priv->sarea = drm_legacy_getsarea(dev);
+   if (!dev_priv->sarea) {
+   DRM_ERROR("could not find sarea!\n");
+   dev->dev_private = (void *)dev_priv;
+   via_do_cleanup_map(dev);
+   return -EINVAL;
+   }
+
+   dev_priv->fb = drm_legacy_findmap(dev, init->fb_offset);
+   if (!dev_priv->fb) {
+   DRM_ERROR("could not find framebuffer!\n");
+   dev->dev_private = (void *)dev_priv;
+   via_do_cleanup_map(dev);
+   return -EINVAL;
+   }
+   dev_priv->mmio = drm_legacy_findmap(dev, init->mmio_offset);
+   if (!dev_priv->mmio) {
+   DRM_ERROR("could not find mmio region!\n");
+   dev->dev_private = (void *)dev_priv;
+   via_do_cleanup_map(dev);
+   return -EINVAL;
+   }
+
+   dev_priv->sarea_priv =
+   (drm_via_sarea_t *) ((u8 *) dev_priv->sarea->handle +
+init->sarea_priv_offset);
+
+   dev_priv->agpAddr = init->agpAddr;
+
+   via_init_futex(dev_priv);
+
+   via_init_dmablit(dev);
+
+   dev->dev_private = (void *)dev_priv;
+   return 0;
+}
+
+int via_do_cleanup_map(struct drm_device *dev)
+{
+   via_dma_cleanup(dev);
+
+   return 0;
+}
+
+static int via_map_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv)
+{
+   drm_via_init_t *init = data;
+
+   DRM_DEBUG("\n");
+
+   switch (init->func) {
+   case VIA_INIT_MAP:
+   return via_do_init_map(dev, init);
+   case VIA_CLEANUP_MAP:
+   return via_do_cleanup_map(dev);
+   }
+
+   return -EINVAL;
+}
+
+static int via_driver_load(struct drm_device *dev, unsigned long chipset)
+{
+   struct pci_dev *pdev = to_pci_dev(dev->dev);
+   drm_via_private_t *dev_priv;
+   int ret = 0;
+
+   dev_priv = kzalloc(sizeof(drm_via_private_t), GFP_KERNEL);
+   if (dev_priv == NULL)
+   return -ENOMEM;
+
+   idr_init(&dev_priv->object_idr);
+   dev->dev_private = (void *)dev_priv;
+
+   dev_priv->chipset = chipset;
+
+   pci_set_master(pdev);
+
+   ret = drm_vblank_init(dev, 1);
+   if (ret) {
+   kfree(dev_priv);
+   return ret;
+   }
+
+   return 0;
+}
+
+static void via_driver_unload(struct drm_device *dev)
+{
+   drm_via_private_t *dev_priv = dev->dev_private;
+
+   idr_destroy(&dev_priv->object_idr);
+
+   kfree(dev_priv);
+}
+
 static void via_cmdbuf_start(drm_via_private_t *dev_priv);
 static void via_cmdbuf_pause(drm_via_private_t *dev_priv);
 static void via_cmdbuf_reset(drm_via_private_t *dev_priv);
diff --git a/drivers/gpu/drm/via/via_drv.h b/drivers/gpu/drm/via/via_drv.h
index 5757422ea634..4eaad17c0e02 100644
--- a/drivers/gpu/drm/via/via_drv.h
+++ b/drivers/gpu/drm/via/via_drv.h
@@ -187,15 +187,11 @@ extern int via_fb_init(struct drm_device *dev, void 
*data, struct drm_file *file
 extern int via_mem_alloc(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
 extern int via_mem_free(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
 extern int via_agp_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
-extern int via_map_init(struct drm_device *dev, void *data, struct drm_file 
*file_priv);
 extern int via_decoder_futex(struct drm_device *dev, void *data, struct 
drm_file *

[PATCH v2 02/13] drm/via: Embed via_dma in via_dri1

2022-07-13 Thread Sam Ravnborg
Moved the copyright notices so all copyrights are kept.
A few variables was made static as there are no more users outside this
file.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile   |   2 +-
 drivers/gpu/drm/via/via_dma.c  | 744 -
 drivers/gpu/drm/via/via_dri1.c | 703 ++-
 drivers/gpu/drm/via/via_drv.h  |   3 -
 4 files changed, 703 insertions(+), 749 deletions(-)
 delete mode 100644 drivers/gpu/drm/via/via_dma.c

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index acfd916541ea..824198c0c2ea 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_dri1.o via_map.o via_mm.o via_dma.o via_verifier.o 
via_video.o via_dmablit.o
+via-y:= via_irq.o via_dri1.o via_map.o via_mm.o via_verifier.o via_video.o 
via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_dma.c b/drivers/gpu/drm/via/via_dma.c
deleted file mode 100644
index 177b0499abf1..
--- a/drivers/gpu/drm/via/via_dma.c
+++ /dev/null
@@ -1,744 +0,0 @@
-/* via_dma.c -- DMA support for the VIA Unichrome/Pro
- *
- * Copyright 2003 Tungsten Graphics, Inc., Cedar Park, Texas.
- * All Rights Reserved.
- *
- * Copyright 2004 Digeo, Inc., Palo Alto, CA, U.S.A.
- * All Rights Reserved.
- *
- * Copyright 2004 The Unichrome project.
- * All Rights Reserved.
- *
- * Permission is hereby granted, free of charge, to any person obtaining a
- * copy of this software and associated documentation files (the "Software"),
- * to deal in the Software without restriction, including without limitation
- * the rights to use, copy, modify, merge, publish, distribute, sub license,
- * and/or sell copies of the Software, and to permit persons to whom the
- * Software is furnished to do so, subject to the following conditions:
- *
- * The above copyright notice and this permission notice (including the
- * next paragraph) shall be included in all copies or substantial portions
- * of the Software.
- *
- * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
- * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
- * FITNESS FOR A PARTICULAR PURPOSE AND NON-INFRINGEMENT. IN NO EVENT SHALL
- * THE COPYRIGHT HOLDERS, AUTHORS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM,
- * DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR
- * OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE
- * USE OR OTHER DEALINGS IN THE SOFTWARE.
- *
- * Authors:
- *Tungsten Graphics,
- *Erdi Chen,
- *Thomas Hellstrom.
- */
-
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-
-#include "via_drv.h"
-#include "via_3d_reg.h"
-
-#define CMDBUF_ALIGNMENT_SIZE   (0x100)
-#define CMDBUF_ALIGNMENT_MASK   (0x0ff)
-
-/* defines for VIA 3D registers */
-#define VIA_REG_STATUS  0x400
-#define VIA_REG_TRANSET 0x43C
-#define VIA_REG_TRANSPACE   0x440
-
-/* VIA_REG_STATUS(0x400): Engine Status */
-#define VIA_CMD_RGTR_BUSY   0x0080 /* Command Regulator is busy */
-#define VIA_2D_ENG_BUSY 0x0001 /* 2D Engine is busy */
-#define VIA_3D_ENG_BUSY 0x0002 /* 3D Engine is busy */
-#define VIA_VR_QUEUE_BUSY   0x0002 /* Virtual Queue is busy */
-
-#define SetReg2DAGP(nReg, nData) { \
-   *((uint32_t *)(vb)) = ((nReg) >> 2) | HALCYON_HEADER1;  \
-   *((uint32_t *)(vb) + 1) = (nData);  \
-   vb = ((uint32_t *)vb) + 2;  \
-   dev_priv->dma_low += 8; \
-}
-
-#define via_flush_write_combine() mb()
-
-#define VIA_OUT_RING_QW(w1, w2)do {\
-   *vb++ = (w1);   \
-   *vb++ = (w2);   \
-   dev_priv->dma_low += 8; \
-} while (0)
-
-static void via_cmdbuf_start(drm_via_private_t *dev_priv);
-static void via_cmdbuf_pause(drm_via_private_t *dev_priv);
-static void via_cmdbuf_reset(drm_via_private_t *dev_priv);
-static void via_cmdbuf_rewind(drm_via_private_t *dev_priv);
-static int via_wait_idle(drm_via_private_t *dev_priv);
-static void via_pad_cache(drm_via_private_t *dev_priv, int qwords);
-
-/*
- * Free space in command buffer.
- */
-
-static uint32_t via_cmdbuf_space(drm_via_private_t *dev_priv)
-{
-   uint32_t agp_base = dev_priv->dma_offset + (uint32_t) dev_priv->agpAddr;
-   uint32_t hw_addr = *(dev_priv->hw_addr_ptr) - agp_base;
-
-   return ((hw_addr <= dev_priv->dma_low) ?
-   (dev_priv->dma_high + hw_addr - dev_priv->dma_low) :
-   (hw_addr - dev_priv->dma_low));
-}
-
-/*
- * How much does the comm

[PATCH v2 01/13] drm/via: Rename via_drv to via_dri1

2022-07-13 Thread Sam Ravnborg
The via driver implements the DRI1 interface, and we have a new
implementation of the via driver coming that supports atomic
modesetting.

It is not acceptable just to replace the existing driver so
this is first step to make it a single-file implementation allowing
it to stay without interfering with the new driver.

Signed-off-by: Sam Ravnborg 
Acked-by: Thomas Zimmermann 
Cc: Kevin Brace 
---
 drivers/gpu/drm/via/Makefile  | 2 +-
 drivers/gpu/drm/via/{via_drv.c => via_dri1.c} | 0
 2 files changed, 1 insertion(+), 1 deletion(-)
 rename drivers/gpu/drm/via/{via_drv.c => via_dri1.c} (100%)

diff --git a/drivers/gpu/drm/via/Makefile b/drivers/gpu/drm/via/Makefile
index 84db4eee7828..acfd916541ea 100644
--- a/drivers/gpu/drm/via/Makefile
+++ b/drivers/gpu/drm/via/Makefile
@@ -3,6 +3,6 @@
 # Makefile for the drm device driver.  This driver provides support for the
 # Direct Rendering Infrastructure (DRI) in XFree86 4.1.0 and higher.
 
-via-y:= via_irq.o via_drv.o via_map.o via_mm.o via_dma.o via_verifier.o 
via_video.o via_dmablit.o
+via-y:= via_irq.o via_dri1.o via_map.o via_mm.o via_dma.o via_verifier.o 
via_video.o via_dmablit.o
 
 obj-$(CONFIG_DRM_VIA)  +=via.o
diff --git a/drivers/gpu/drm/via/via_drv.c b/drivers/gpu/drm/via/via_dri1.c
similarity index 100%
rename from drivers/gpu/drm/via/via_drv.c
rename to drivers/gpu/drm/via/via_dri1.c
-- 
2.34.1



[PATCH v2 0/11] drm/via: Make via a single file driver

2022-07-13 Thread Sam Ravnborg
We have an upcoming openchrome driver for VIA where some
of the files conflicts with the existing via driver.

It is not acceptable to just delete the existing DRI1
based driver as there are most likely users out there,
so a different approach was required.

It was disccussed what to do and the least invasive
solution was to keep the DRI1 driver in the current
directory as a single file.

Thomas Zimmermann already posted a patch to do the
same but it attemped to have a single driver
for the DRI1 and the upcoming new driver.

This patchset embeds the files one by one to make the
diffs remotely readable and end up with an independent
DRI1 driver.

The driver was built tested for each step.

v2:
  - Drop the rename of the driver - keep the name via.
We can name the new driver viakms or openchrome so
there is no confusion in userspace if the old or
the new driver is used.
  - Add a few patches to make via_3d_reg more readable,
which has the nice side-effect that it is now checkpatch
clean.
  - Added Kevin as cc: on all patches

This set of patches should make it simpler to add the new
openchrome driver, and I am happy to assist if there are
open questions how to do it.

Note: The patches has seen zero run-time testing - I only
know they builds in my setup (for several archs).

Sam

Sam Ravnborg (13):
  drm/via: Rename via_drv to via_dri1
  drm/via: Embed via_dma in via_dri1
  drm/via: Embed via_map in via_dri1
  drm/via: Embed via_mm in via_dri1
  drm/via: Embed via_video in via_dri1
  drm/via: Embed via_irq in via_dri1
  drm/via: Embed via_dmablit in via_dri1
  drm/via: Embed via_verifier in via_dri1
  drm/via: Embed via_drv.h in via_dri1
  drm/via: Update to the latest via_3d_reg header
  drm/via: Use SPDX tag for MIT license in via_3d_reg header
  drm/via: Make macros readable in the via_3d_reg header
  drm/via: Fix style issues in via_3d_reg header

 drivers/gpu/drm/via/Makefile   |2 +-
 drivers/gpu/drm/via/via_3d_reg.h   |  349 ++--
 drivers/gpu/drm/via/via_dma.c  |  744 
 drivers/gpu/drm/via/via_dmablit.c  |  807 
 drivers/gpu/drm/via/via_dmablit.h  |  140 --
 drivers/gpu/drm/via/via_dri1.c | 3630 
 drivers/gpu/drm/via/via_drv.c  |  124 --
 drivers/gpu/drm/via/via_drv.h  |  229 ---
 drivers/gpu/drm/via/via_irq.c  |  388 
 drivers/gpu/drm/via/via_map.c  |  132 --
 drivers/gpu/drm/via/via_mm.c   |  241 ---
 drivers/gpu/drm/via/via_verifier.c | 1110 ---
 drivers/gpu/drm/via/via_verifier.h |   62 -
 drivers/gpu/drm/via/via_video.c|   94 -
 14 files changed, 3866 insertions(+), 4186 deletions(-)




Re: [Intel-gfx] [PATCH v3 2/7] drm: Add drm_memcpy_from_wc() variant which accepts destination address

2022-07-13 Thread Lucas De Marchi

On Tue, Apr 26, 2022 at 10:21:43PM +0530, Balasubramani Vivekanandan wrote:

Fast copy using non-temporal instructions for x86 currently exists at two
locations. One is implemented in i915 driver at i915/i915_memcpy.c and
another copy at drm_cache.c. The plan is to remove the duplicate
implementation in i915 driver and use the functions from drm_cache.c.

A variant of drm_memcpy_from_wc() is added in drm_cache.c which accepts
address as argument instead of iosys_map for destination. It is a very
common scenario in i915 to copy from a WC memory type, which may be an
io memory or a system memory to a destination address pointing to system
memory. To avoid the overhead of creating iosys_map type for the
destination, new variant is created to accept the address directly.

Also a new function is exported in drm_cache.c to find if the fast copy
is supported by the platform or not. It is required for i915.

v2: Added a new argument to drm_memcpy_from_wc_vaddr() which provides
the offset into the src address to start copy from.

Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Thomas Hellstr_m 


   ^ utf-8 error?



Signed-off-by: Balasubramani Vivekanandan 
Reviewed-by: Lucas De Marchi 
Reviewed-by: Nirmoy Das 
---
drivers/gpu/drm/drm_cache.c | 55 +
include/drm/drm_cache.h |  3 ++
2 files changed, 58 insertions(+)

diff --git a/drivers/gpu/drm/drm_cache.c b/drivers/gpu/drm/drm_cache.c
index 2e2545df3310..8c7af755f7bc 100644
--- a/drivers/gpu/drm/drm_cache.c
+++ b/drivers/gpu/drm/drm_cache.c
@@ -358,6 +358,55 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
}
EXPORT_SYMBOL(drm_memcpy_from_wc);

+/**
+ * drm_memcpy_from_wc_vaddr - Perform the fastest available memcpy from a 
source
+ * that may be WC to a destination in system memory.
+ * @dst: The destination pointer
+ * @src: The source pointer
+ * @src_offset: The offset from which to copy
+ * @len: The size of the area to transfer in bytes
+ *
+ * Same as drm_memcpy_from_wc except destination is accepted as system memory
+ * address. Useful in situations where passing destination address as iosys_map
+ * is simply an overhead and can be avoided.
+ */
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ size_t src_offset, unsigned long len)
+{
+   const void *src_addr = src->is_iomem ?
+   (void const __force *)src->vaddr_iomem :
+   src->vaddr;


checking this again... this is a layer violation. We do have some in
the codebase, but it'd be good not to add more.

later I'd like these memcpy variants to be moved iosys-map. I'm not sure
if Thomas Zimmermann or Christian agree. Cc'ing them here.

Maybe we could scan the codebase and add a function in iosys-map like:

void *iosys_map_get_ptr(struct iosys_map *map, bool is_lmem)

... which is similar to the ttm_kmap_obj_virtual() function we have in
ttm.

so the cases where the layer is violated at least they come from a
single function call in iosys_map API rather than directly accessing
is_iomem/vaddr_iomem/vaddr. Thomas/Christian, any opinion here?

Lucas De Marchi


+
+   if (WARN_ON(in_interrupt())) {
+   iosys_map_memcpy_from(dst, src, src_offset, len);
+   return;
+   }
+
+   if (static_branch_likely(&has_movntdqa)) {
+   __drm_memcpy_from_wc(dst, src_addr + src_offset, len);
+   return;
+   }
+
+   iosys_map_memcpy_from(dst, src, src_offset, len);
+}
+EXPORT_SYMBOL(drm_memcpy_from_wc_vaddr);
+
+/*
+ * drm_memcpy_fastcopy_supported - Returns if fast copy using non-temporal
+ * instructions is supported
+ *
+ * Returns true if platform has support for fast copying from wc memory type
+ * using non-temporal instructions. Else false.
+ */
+bool drm_memcpy_fastcopy_supported(void)
+{
+   if (static_branch_likely(&has_movntdqa))
+   return true;
+
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
/*
 * drm_memcpy_init_early - One time initialization of the WC memcpy code
 */
@@ -382,6 +431,12 @@ void drm_memcpy_from_wc(struct iosys_map *dst,
}
EXPORT_SYMBOL(drm_memcpy_from_wc);

+bool drm_memcpy_fastcopy_supported(void)
+{
+   return false;
+}
+EXPORT_SYMBOL(drm_memcpy_fastcopy_supported);
+
void drm_memcpy_init_early(void)
{
}
diff --git a/include/drm/drm_cache.h b/include/drm/drm_cache.h
index 22deb216b59c..d1b57c84a659 100644
--- a/include/drm/drm_cache.h
+++ b/include/drm/drm_cache.h
@@ -77,4 +77,7 @@ void drm_memcpy_init_early(void);
void drm_memcpy_from_wc(struct iosys_map *dst,
const struct iosys_map *src,
unsigned long len);
+bool drm_memcpy_fastcopy_supported(void);
+void drm_memcpy_from_wc_vaddr(void *dst, const struct iosys_map *src,
+ size_t src_offset, unsigned long len);
#endif
--
2.25.1


Re: [PATCH] drm/i915: Correct ss -> steering calculation for pre-Xe_HP platforms

2022-07-13 Thread Lucas De Marchi

On Tue, Jul 12, 2022 at 03:05:13PM -0700, Matt Roper wrote:

Accidental use of a "SLICE" macro where a "SUBSLICE" macro was intended
causes the group ID for steering to be calculated incorrectly on
pre-Xe_HP platforms.

Fixes: 9a92732f040a ("drm/i915/gt: Add general DSS steering iterator to 
intel_gt_mcr")
Signed-off-by: Matt Roper 



Reviewed-by: Lucas De Marchi 

Lucas De Marchi


---
drivers/gpu/drm/i915/gt/intel_gt_mcr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c 
b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
index f8c64ab9d3ca..e79405a45312 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_mcr.c
@@ -515,7 +515,7 @@ void intel_gt_mcr_get_ss_steering(struct intel_gt *gt, 
unsigned int dss,
*group = dss / GEN_DSS_PER_GSLICE;
*instance = dss % GEN_DSS_PER_GSLICE;
} else {
-   *group = dss / GEN_MAX_HSW_SLICES;
+   *group = dss / GEN_MAX_SS_PER_HSW_SLICE;
*instance = dss % GEN_MAX_SS_PER_HSW_SLICE;
return;
}
--
2.36.1



[PATCH v3 3/3] drm/i915/display: add hotplug.suspended flag

2022-07-13 Thread Andrzej Hajda
HPD events during driver removal can be generated by hardware and
software frameworks - drm_dp_mst, the former we can avoid by disabling
interrupts, the latter can be triggered by any drm_dp_mst transaction,
and this is too late. Introducing suspended flag allows to solve this
chicken-egg problem.

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5950
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_display.c |  2 +-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 13 -
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 5 files changed, 18 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index ec8e59b3adaea7..b969635b212ba9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9008,7 +9008,7 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
/* MST is the last user of HPD work */
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.c 
b/drivers/gpu/drm/i915/display/intel_hotplug.c
index 5f8b4f481cff9a..2d505db1f6476b 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.c
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.c
@@ -353,6 +353,10 @@ void intel_hpd_trigger_irq(struct intel_digital_port 
*dig_port)
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
 
spin_lock_irq(&i915->irq_lock);
+   if (i915->hotplug.suspended) {
+   spin_unlock_irq(&i915->irq_lock);
+   return;
+   }
i915->hotplug.short_port_mask |= BIT(dig_port->base.port);
spin_unlock_irq(&i915->irq_lock);
 
@@ -475,6 +479,11 @@ void intel_hpd_irq_handler(struct drm_i915_private 
*dev_priv,
 
spin_lock(&dev_priv->irq_lock);
 
+   if (dev_priv->hotplug.suspended) {
+   spin_unlock(&dev_priv->irq_lock);
+   return;
+   }
+
/*
 * Determine whether ->hpd_pulse() exists for each pin, and
 * whether we have a short or a long pulse. This is needed
@@ -603,6 +612,7 @@ void intel_hpd_init(struct drm_i915_private *dev_priv)
 * just to make the assert_spin_locked checks happy.
 */
spin_lock_irq(&dev_priv->irq_lock);
+   dev_priv->hotplug.suspended = false;
intel_hpd_irq_setup(dev_priv);
spin_unlock_irq(&dev_priv->irq_lock);
 }
@@ -721,13 +731,14 @@ void intel_hpd_init_work(struct drm_i915_private 
*dev_priv)
  intel_hpd_irq_storm_reenable_work);
 }
 
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv)
+void intel_hpd_suspend(struct drm_i915_private *dev_priv)
 {
if (!HAS_DISPLAY(dev_priv))
return;
 
spin_lock_irq(&dev_priv->irq_lock);
 
+   dev_priv->hotplug.suspended = true;
dev_priv->hotplug.long_port_mask = 0;
dev_priv->hotplug.short_port_mask = 0;
dev_priv->hotplug.event_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_hotplug.h 
b/drivers/gpu/drm/i915/display/intel_hotplug.h
index b87e95d606e668..54bddc4dd63421 100644
--- a/drivers/gpu/drm/i915/display/intel_hotplug.h
+++ b/drivers/gpu/drm/i915/display/intel_hotplug.h
@@ -23,7 +23,7 @@ void intel_hpd_irq_handler(struct drm_i915_private *dev_priv,
 void intel_hpd_trigger_irq(struct intel_digital_port *dig_port);
 void intel_hpd_init(struct drm_i915_private *dev_priv);
 void intel_hpd_init_work(struct drm_i915_private *dev_priv);
-void intel_hpd_cancel_work(struct drm_i915_private *dev_priv);
+void intel_hpd_suspend(struct drm_i915_private *dev_priv);
 enum hpd_pin intel_hpd_pin_default(struct drm_i915_private *dev_priv,
   enum port port);
 bool intel_hpd_disable(struct drm_i915_private *dev_priv, enum hpd_pin pin);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index be932a6d9c7dfa..5f87719a74337c 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1079,7 +1079,7 @@ void i915_driver_shutdown(struct drm_i915_private *i915)
intel_dp_mst_suspend(i915);
 
intel_runtime_pm_disable_interrupts(i915);
-   intel_hpd_cancel_work(i915);
+   intel_hpd_suspend(i915);
 
intel_suspend_encoders(i915);
intel_shutdown_encoders(i915);
@@ -1148,7 +1148,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_dp_mst_suspend(dev_priv);
 
intel_runtime_pm_disable_interrupts(dev_priv);
-   intel_hpd_cancel_work(dev_priv);
+   intel_hpd_suspend(dev_priv);
 
intel_suspend_encoders(dev_priv);
 
diff --git a/

[PATCH v3 2/3] drm/i915/fbdev: suspend HPD before fbdev unregistration

2022-07-13 Thread Andrzej Hajda
HPD event after fbdev unregistration can cause registration of deferred
fbdev which will not be unregistered later, causing use-after-free.
To avoid it HPD handling should be suspended before fbdev unregistration.

It should fix following GPF:
[272.634530] general protection fault, probably for non-canonical address 
0x6b6b6b6b6b6b6b6b:  [#1] PREEMPT SMP NOPTI
[272.634536] CPU: 0 PID: 6030 Comm: i915_selftest Tainted: G U
5.18.0-rc5-CI_DRM_11603-g12dccf4f5eef+ #1
[272.634541] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[272.634545] RIP: 0010:fb_do_apertures_overlap.part.14+0x26/0x60
...
[272.634582] Call Trace:
[272.634583]  
[272.634585]  do_remove_conflicting_framebuffers+0x59/0xa0
[272.634589]  remove_conflicting_framebuffers+0x2d/0xc0
[272.634592]  remove_conflicting_pci_framebuffers+0xc8/0x110
[272.634595]  drm_aperture_remove_conflicting_pci_framebuffers+0x52/0x70
[272.634604]  i915_driver_probe+0x63a/0xdd0 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5329
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5510
Signed-off-by: Andrzej Hajda 
---
 drivers/gpu/drm/i915/display/intel_fbdev.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbdev.c 
b/drivers/gpu/drm/i915/display/intel_fbdev.c
index 221336178991f0..b682fd72d4bf25 100644
--- a/drivers/gpu/drm/i915/display/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/display/intel_fbdev.c
@@ -573,7 +573,8 @@ void intel_fbdev_unregister(struct drm_i915_private 
*dev_priv)
if (!ifbdev)
return;
 
-   cancel_work_sync(&dev_priv->fbdev_suspend_work);
+   intel_fbdev_set_suspend(&dev_priv->drm, FBINFO_STATE_SUSPENDED, true);
+
if (!current_is_async())
intel_fbdev_sync(ifbdev);
 
-- 
2.25.1



[PATCH v3 1/3] drm/i915/hpd: postpone HPD cancel work after last user suspension

2022-07-13 Thread Andrzej Hajda
i915->hotplug.dig_port_work can be queued from intel_hpd_irq_handler
called by IRQ handler or by intel_hpd_trigger_irq called from dp_mst.
Since dp_mst is suspended after irq handler uninstall, a cleaner approach
is to cancel hpd work after intel_dp_mst_suspend, otherwise we risk
use-after-free.

It should fix following WARNINGS:
[283.405824] cpu_latency_qos_update_request called for unknown object
[283.405866] WARNING: CPU: 2 PID: 240 at kernel/power/qos.c:296 
cpu_latency_qos_update_request+0x2d/0x100
[283.405912] CPU: 2 PID: 240 Comm: kworker/u64:9 Not tainted 
5.18.0-rc6-Patchwork_103738v3-g1672d1c43e43+ #1
[283.405915] Hardware name: Intel Corporation Raptor Lake Client Platform/RPL-S 
ADP-S DDR5 UDIMM CRB, BIOS RPLSFWI1.R00.2397.A01.2109300731 09/30/2021
[283.405916] Workqueue: i915-dp i915_digport_work_func [i915]
[283.406020] RIP: 0010:cpu_latency_qos_update_request+0x2d/0x100
...
[283.406040] Call Trace:
[283.406041]  
[283.406044]  intel_dp_aux_xfer+0x60e/0x8e0 [i915]
[283.406131]  ? finish_swait+0x80/0x80
[283.406139]  intel_dp_aux_transfer+0xc5/0x2b0 [i915]
[283.406218]  drm_dp_dpcd_access+0x79/0x130 [drm_display_helper]
[283.406227]  drm_dp_dpcd_read+0xe2/0xf0 [drm_display_helper]
[283.406233]  intel_dp_hpd_pulse+0x134/0x570 [i915]
[283.406308]  ? __down_killable+0x70/0x140
[283.406313]  i915_digport_work_func+0xba/0x150 [i915]

Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/4586
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/5558
Signed-off-by: Andrzej Hajda 
Reviewed-by: Arun R Murthy 
---
 drivers/gpu/drm/i915/display/intel_display.c | 3 +++
 drivers/gpu/drm/i915/i915_irq.c  | 1 -
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/display/intel_display.c 
b/drivers/gpu/drm/i915/display/intel_display.c
index 903226e2a6260d..ec8e59b3adaea7 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -9007,6 +9007,9 @@ void intel_modeset_driver_remove_noirq(struct 
drm_i915_private *i915)
 */
intel_dp_mst_suspend(i915);
 
+   /* MST is the last user of HPD work */
+   intel_hpd_cancel_work(i915);
+
/* poll work can call into fbdev, hence clean that up afterwards */
intel_fbdev_fini(i915);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 73cebc6aa65072..db14787aef95dd 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4597,7 +4597,6 @@ void intel_irq_uninstall(struct drm_i915_private 
*dev_priv)
 
free_irq(irq, dev_priv);
 
-   intel_hpd_cancel_work(dev_priv);
dev_priv->runtime_pm.irqs_enabled = false;
 }
 
-- 
2.25.1



[PATCH v3 0/3] drm/i915/display: stop HPD workers before display driver unregister

2022-07-13 Thread Andrzej Hajda
Hi Jani, Ville, Arun,

This patchset is replacement of patch
"drm/i915/display: disable HPD workers before display driver unregister" [1].
Ive decided to split patch into two parts - fbdev and MST, there are different
issues.
Ive also dropped shutdown path, as it has slightly different requirements,
and more importantly I am not able to test properly.

v2 (thx Arun for review):
  - reword of commit message (Arun)
  - intel_fbdev_hpd_set_suspend replaced with intel_fbdev_set_suspend (Arun)
v3:
  - new patch adding suspended flag, to handle
https://gitlab.freedesktop.org/drm/intel/-/issues/5950

[1]: https://patchwork.freedesktop.org/series/103811/

Regards
Andrzej


Andrzej Hajda (3):
  drm/i915/hpd: postpone HPD cancel work after last user suspension
  drm/i915/fbdev: suspend HPD before fbdev unregistration
  drm/i915/display: add hotplug.suspended flag

 drivers/gpu/drm/i915/display/intel_display.c |  3 +++
 drivers/gpu/drm/i915/display/intel_fbdev.c   |  3 ++-
 drivers/gpu/drm/i915/display/intel_hotplug.c | 13 -
 drivers/gpu/drm/i915/display/intel_hotplug.h |  2 +-
 drivers/gpu/drm/i915/i915_driver.c   |  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  2 ++
 drivers/gpu/drm/i915/i915_irq.c  |  1 -
 7 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.25.1



Re: [PATCH 2/2] gpu/drm/panel: Add Sony TD4353 JDI panel driver

2022-07-13 Thread Sam Ravnborg
Hi Konrad,

thanks for submitting this driver. I know a new version is pending with
the bindings changes but here is a few more things to address.

Sam


On Tue, Jul 12, 2022 at 10:02:41PM +0200, Konrad Dybcio wrote:
> Add support for the Sony TD4353 JDI 2160x1080 display panel used in
> some Sony Xperia XZ2 and XZ2 Compact smartphones. Due to the specifics
> of smartphone manufacturing, it is impossible to retrieve a better name
> for this panel.
> 
> This revision adds support for the default 60 Hz configuration, however
> there could possibly be some room for expansion, as the display panels
> used on Sony devices have historically been capable of >2x refresh rate
> overclocking.
> ---
>  drivers/gpu/drm/panel/Kconfig |  10 +
>  drivers/gpu/drm/panel/Makefile|   1 +
>  drivers/gpu/drm/panel/panel-sony-td4353-jdi.c | 352 ++
>  3 files changed, 363 insertions(+)
>  create mode 100644 drivers/gpu/drm/panel/panel-sony-td4353-jdi.c
> 
> diff --git a/drivers/gpu/drm/panel/Kconfig b/drivers/gpu/drm/panel/Kconfig
> index 38799effd00a..1baa0a2c36bd 100644
> --- a/drivers/gpu/drm/panel/Kconfig
> +++ b/drivers/gpu/drm/panel/Kconfig
> @@ -624,6 +624,16 @@ config DRM_PANEL_SONY_ACX565AKM
> Say Y here if you want to enable support for the Sony ACX565AKM
> 800x600 3.5" panel (found on the Nokia N900).
>  
> +config DRM_PANEL_SONY_TD4353_JDI
> + tristate "Sony TD4353 JDI panel"
> + depends on GPIOLIB && OF
> + depends on DRM_MIPI_DSI
> + depends on BACKLIGHT_CLASS_DEVICE
> + help
> +   Say Y here if you want to enable support for the Sony Tama
> +   TD4353 JDI command mode panel as found on some Sony Xperia
> +   XZ2 and XZ2 Compact smartphones.
> +
>  config DRM_PANEL_SONY_TULIP_TRULY_NT35521
>   tristate "Sony Tulip Truly NT35521 panel"
>   depends on GPIOLIB && OF
> diff --git a/drivers/gpu/drm/panel/Makefile b/drivers/gpu/drm/panel/Makefile
> index eabd4d6a1845..df8a6b707dbb 100644
> --- a/drivers/gpu/drm/panel/Makefile
> +++ b/drivers/gpu/drm/panel/Makefile
> @@ -63,6 +63,7 @@ obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7701) += 
> panel-sitronix-st7701.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7703) += panel-sitronix-st7703.o
>  obj-$(CONFIG_DRM_PANEL_SITRONIX_ST7789V) += panel-sitronix-st7789v.o
>  obj-$(CONFIG_DRM_PANEL_SONY_ACX565AKM) += panel-sony-acx565akm.o
> +obj-$(CONFIG_DRM_PANEL_SONY_TD4353_JDI) += panel-sony-td4353-jdi.o
>  obj-$(CONFIG_DRM_PANEL_SONY_TULIP_TRULY_NT35521) += 
> panel-sony-tulip-truly-nt35521.o
>  obj-$(CONFIG_DRM_PANEL_TDO_TL070WSH30) += panel-tdo-tl070wsh30.o
>  obj-$(CONFIG_DRM_PANEL_TPO_TD028TTEC1) += panel-tpo-td028ttec1.o
> diff --git a/drivers/gpu/drm/panel/panel-sony-td4353-jdi.c 
> b/drivers/gpu/drm/panel/panel-sony-td4353-jdi.c
> new file mode 100644
> index ..8bc2e55af63c
> --- /dev/null
> +++ b/drivers/gpu/drm/panel/panel-sony-td4353-jdi.c
> @@ -0,0 +1,352 @@
> +// SPDX-License-Identifier: GPL-2.0-only
> +/*
> + * Copyright (c) 2022 Konrad Dybcio 
> + *
> + * Generated with linux-mdss-dsi-panel-driver-generator with a
> + * substantial amount of manual adjustments.
> + *
> + * SONY Downstream kernel calls this one:
> + * - "JDI ID3" for Akari
> + * - "JDI ID4" for Apollo
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include 
> +
> +#include 
> +#include 
> +#include 
> +
> +enum {
> + TYPE_AKARI_60HZ,
> + TYPE_APOLLO_60HZ
> +};
> +
> +struct sony_td4353_jdi {
> + struct drm_panel panel;
> + struct mipi_dsi_device *dsi;
> + struct regulator_bulk_data supplies[3];
> + struct gpio_desc *preset_gpio;
> + struct gpio_desc *treset_gpio;
> + bool prepared;
> + int type;
> +};
> +
> +static inline struct sony_td4353_jdi *to_sony_td4353_jdi(struct drm_panel 
> *panel)
> +{
> + return container_of(panel, struct sony_td4353_jdi, panel);
> +}
> +
> +#define dsi_dcs_write_seq(dsi, seq...) do {  \
> + static const u8 d[] = { seq };  \
> + int ret;\
> + ret = mipi_dsi_dcs_write_buffer(dsi, d, ARRAY_SIZE(d)); \
> + if (ret < 0)\
> + return ret; \
> + } while (0)
Use the one already defined in drm_mipi_dsi - we do not want extra
copies of the same.


> +
> +static int sony_td4353_jdi_on(struct sony_td4353_jdi *ctx)

Maybe this is just me, but I had expected that a function named "on"
would enable the power supply.

> +{
> + struct mipi_dsi_device *dsi = ctx->dsi;
> + struct device *dev = &dsi->dev;
> + int ret;
> +
> + dsi->mode_flags |= MIPI_DSI_MODE_LPM;
> +
> + ret = mipi_dsi_dcs_set_column_address(dsi, 0x, 0x0437);
> + if (ret < 0) {
> + dev_err(dev, "Failed to set column address: %d\n", ret);
> +  

[PATCH] drm/amd/debugfs: Expose GFXOFF state to userspace

2022-07-13 Thread André Almeida
GFXOFF has two different "state" values: one to define if the GPU is
allowed/disallowed to enter GFXOFF, usually called state; and another
one to define if currently GFXOFF is being used, usually called status.
Even when GFXOFF is allowed, GPU firmware can decide to not used it
accordingly to the GPU load.

Userspace can allow/disallow GPUs to enter into GFXOFF via debugfs. The
kernel maintains a counter of requests for GFXOFF (gfx_off_req_count)
that should be decreased to allow GFXOFF and increased to disallow.

The issue with this interface is that userspace can't be sure if GFXOFF
is currently allowed. Even by checking amdgpu_gfxoff file, one might get
an ambiguous 2, that means that GPU is currently out of GFXOFF, but that
can be either because it's currently disallowed or because it's allowed
but given the current GPU load it's enabled. Then, userspace needs to
rely on the fact that GFXOFF is enabled by default on boot and to track
this information.

To make userspace life easier and GFXOFF more reliable, return the
current state of GFXOFF to userspace when reading amdgpu_gfxoff with the
same semantics of writing: 0 means not allowed, not 0 means allowed.

Expose the current status of GFXOFF through a new file,
amdgpu_gfxoff_status.

Signed-off-by: André Almeida 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 49 -
 1 file changed, 47 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f3b3c688e4e7..e2eec985adb3 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
@@ -1117,13 +1117,50 @@ static ssize_t amdgpu_debugfs_gfxoff_read(struct file 
*f, char __user *buf,
}
 
while (size) {
-   uint32_t value;
+   u32 value = adev->gfx.gfx_off_state;
+
+   r = put_user(value, (u32 *)buf);
+   if (r)
+   goto out;
+
+   result += 4;
+   buf += 4;
+   *pos += 4;
+   size -= 4;
+   }
+
+   r = result;
+out:
+   pm_runtime_mark_last_busy(adev_to_drm(adev)->dev);
+   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+
+   return r;
+}
+
+static ssize_t amdgpu_debugfs_gfxoff_status_read(struct file *f, char __user 
*buf,
+size_t size, loff_t *pos)
+{
+   struct amdgpu_device *adev = file_inode(f)->i_private;
+   ssize_t result = 0;
+   int r;
+
+   if (size & 0x3 || *pos & 0x3)
+   return -EINVAL;
+
+   r = pm_runtime_get_sync(adev_to_drm(adev)->dev);
+   if (r < 0) {
+   pm_runtime_put_autosuspend(adev_to_drm(adev)->dev);
+   return r;
+   }
+
+   while (size) {
+   u32 value;
 
r = amdgpu_get_gfx_off_status(adev, &value);
if (r)
goto out;
 
-   r = put_user(value, (uint32_t *)buf);
+   r = put_user(value, (u32 *)buf);
if (r)
goto out;
 
@@ -1206,6 +1243,12 @@ static const struct file_operations 
amdgpu_debugfs_gfxoff_fops = {
.llseek = default_llseek
 };
 
+static const struct file_operations amdgpu_debugfs_gfxoff_status_fops = {
+   .owner = THIS_MODULE,
+   .read = amdgpu_debugfs_gfxoff_status_read,
+   .llseek = default_llseek
+};
+
 static const struct file_operations *debugfs_regs[] = {
&amdgpu_debugfs_regs_fops,
&amdgpu_debugfs_regs2_fops,
@@ -1217,6 +1260,7 @@ static const struct file_operations *debugfs_regs[] = {
&amdgpu_debugfs_wave_fops,
&amdgpu_debugfs_gpr_fops,
&amdgpu_debugfs_gfxoff_fops,
+   &amdgpu_debugfs_gfxoff_status_fops,
 };
 
 static const char *debugfs_regs_names[] = {
@@ -1230,6 +1274,7 @@ static const char *debugfs_regs_names[] = {
"amdgpu_wave",
"amdgpu_gpr",
"amdgpu_gfxoff",
+   "amdgpu_gfxoff_status",
 };
 
 /**
-- 
2.37.0



Re: [PATCH] drm/i915/ttm: fix 32b build

2022-07-13 Thread Das, Nirmoy

Reviewed-by: Nirmoy Das 

On 7/12/2022 7:40 PM, Matthew Auld wrote:

Since segment_pages is no longer a compile time constant, it looks the
DIV_ROUND_UP(node->size, segment_pages) breaks the 32b build. Simplest
is just to use the ULL variant, but really we should need not need more
than u32 for the page alignment (also we are limited by that due to the
sg->length type), so also make it all u32.

Reported-by: Ville Syrjälä 
Fixes: bc99f1209f19 ("drm/i915/ttm: fix sg_table construction")
Signed-off-by: Matthew Auld 
Cc: Nirmoy Das 
---
  drivers/gpu/drm/i915/gem/i915_gem_region.c |  2 ++
  drivers/gpu/drm/i915/gem/i915_gem_ttm.c|  2 +-
  drivers/gpu/drm/i915/i915_scatterlist.c| 16 
  drivers/gpu/drm/i915/i915_scatterlist.h|  4 ++--
  drivers/gpu/drm/i915/intel_region_ttm.c|  2 +-
  drivers/gpu/drm/i915/intel_region_ttm.h|  2 +-
  6 files changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_region.c 
b/drivers/gpu/drm/i915/gem/i915_gem_region.c
index f46ee16a323a..a4fb577eceb4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_region.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_region.c
@@ -60,6 +60,8 @@ __i915_gem_object_create_region(struct intel_memory_region 
*mem,
if (page_size)
default_page_size = page_size;
  
+	/* We should be able to fit a page within an sg entry */

+   GEM_BUG_ON(overflows_type(default_page_size, u32));
GEM_BUG_ON(!is_power_of_2_u64(default_page_size));
GEM_BUG_ON(default_page_size < PAGE_SIZE);
  
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c

index 053b0022ddd0..5a5cf332d8a5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -602,7 +602,7 @@ i915_ttm_resource_get_st(struct drm_i915_gem_object *obj,
 struct ttm_resource *res)
  {
struct ttm_buffer_object *bo = i915_gem_to_ttm(obj);
-   u64 page_alignment;
+   u32 page_alignment;
  
  	if (!i915_ttm_gtt_binds_lmem(res))

return i915_ttm_tt_get_st(bo->ttm);
diff --git a/drivers/gpu/drm/i915/i915_scatterlist.c 
b/drivers/gpu/drm/i915/i915_scatterlist.c
index f63b50b71e10..dcc081874ec8 100644
--- a/drivers/gpu/drm/i915/i915_scatterlist.c
+++ b/drivers/gpu/drm/i915/i915_scatterlist.c
@@ -79,10 +79,10 @@ void i915_refct_sgt_init(struct i915_refct_sgt *rsgt, 
size_t size)
   */
  struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,
  u64 region_start,
- u64 page_alignment)
+ u32 page_alignment)
  {
-   const u64 max_segment = round_down(UINT_MAX, page_alignment);
-   u64 segment_pages = max_segment >> PAGE_SHIFT;
+   const u32 max_segment = round_down(UINT_MAX, page_alignment);
+   const u32 segment_pages = max_segment >> PAGE_SHIFT;
u64 block_size, offset, prev_end;
struct i915_refct_sgt *rsgt;
struct sg_table *st;
@@ -96,7 +96,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct 
drm_mm_node *node,
  
  	i915_refct_sgt_init(rsgt, node->size << PAGE_SHIFT);

st = &rsgt->table;
-   if (sg_alloc_table(st, DIV_ROUND_UP(node->size, segment_pages),
+   if (sg_alloc_table(st, DIV_ROUND_UP_ULL(node->size, segment_pages),
   GFP_KERNEL)) {
i915_refct_sgt_put(rsgt);
return ERR_PTR(-ENOMEM);
@@ -123,7 +123,7 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct 
drm_mm_node *node,
st->nents++;
}
  
-		len = min(block_size, max_segment - sg->length);

+   len = min_t(u64, block_size, max_segment - sg->length);
sg->length += len;
sg_dma_len(sg) += len;
  
@@ -155,11 +155,11 @@ struct i915_refct_sgt *i915_rsgt_from_mm_node(const struct drm_mm_node *node,

   */
  struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct ttm_resource *res,
 u64 region_start,
-u64 page_alignment)
+u32 page_alignment)
  {
struct i915_ttm_buddy_resource *bman_res = to_ttm_buddy_resource(res);
const u64 size = res->num_pages << PAGE_SHIFT;
-   const u64 max_segment = round_down(UINT_MAX, page_alignment);
+   const u32 max_segment = round_down(UINT_MAX, page_alignment);
struct drm_buddy *mm = bman_res->mm;
struct list_head *blocks = &bman_res->blocks;
struct drm_buddy_block *block;
@@ -207,7 +207,7 @@ struct i915_refct_sgt *i915_rsgt_from_buddy_resource(struct 
ttm_resource *res,
st->nents++;
}
  
-			len = min(block_size, max_segment - sg->length);

+   len = min_t(u

[PATCH v11 05/10] drm/i915: sanitize mem_flags for stolen buffers

2022-07-13 Thread Robert Beckett
Stolen regions are not page backed or considered iomem.
Prevent flags indicating such.
This correctly prevents stolen buffers from attempting to directly map
them.

See i915_gem_object_has_struct_page() and i915_gem_object_has_iomem()
usage for where it would break otherwise.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 2cc2c08bd50f..18d574ac167f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -14,6 +14,7 @@
 #include "gem/i915_gem_region.h"
 #include "gem/i915_gem_ttm.h"
 #include "gem/i915_gem_ttm_move.h"
+#include "gem/i915_gem_stolen.h"
 
 #include "gt/intel_engine_pm.h"
 #include "gt/intel_gt.h"
@@ -130,8 +131,9 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
 
obj->mem_flags &= ~(I915_BO_FLAG_STRUCT_PAGE | I915_BO_FLAG_IOMEM);
 
-   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
-   I915_BO_FLAG_STRUCT_PAGE;
+   if (!i915_gem_object_is_stolen(obj))
+   obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
+   I915_BO_FLAG_STRUCT_PAGE;
 
if (!obj->ttm.cache_level_override) {
cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
-- 
2.25.1



[PATCH v11 08/10] drm/i915/selftest: don't attempt engine reset of guc submission engines

2022-07-13 Thread Robert Beckett
igt_reset_engines_stolen tries to reset engines without checking if it
is possible.
Engines using GuC submission are not able to be reset from the host.

In this scenario, the reset exits early, then on the next iteration of
the each engine loop, the async teardown of the spinner request
context's ring occurs while the next engine is under test.

This is seen as a stolen memory corruption as the ring buffer was busy
initially, but free during the confirmation check and had been poisoned
during cleanup.

Fix this by not testing GuC submission using engines.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/selftest_reset.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c 
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 37c38bdd5f47..55f3b34e5f6e 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -194,6 +194,8 @@ static int igt_reset_engines_stolen(void *arg)
return 0;
 
for_each_engine(engine, gt, id) {
+   if (intel_engine_uses_guc(engine))
+   continue;
err = __igt_reset_stolen(gt, engine->mask, engine->name);
if (err)
return err;
-- 
2.25.1



[PATCH v11 07/10] drm/i915/ttm: add buffer pin on alloc flag

2022-07-13 Thread Robert Beckett
For situations where allocations need to fail on alloc instead of
delayed get_pages, add a new alloc flag to pin the ttm bo.
This makes sure that the resource has been allocated during buffer
creation, allowing it to fail with an error if the placement is
exhausted.
This allows existing fallback options for stolen backend allocation like
create_ring_vma to work as expected.

Signed-off-by: Robert Beckett 
---
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 13 ++
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   | 25 ++-
 2 files changed, 32 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 14937cf1daaa..283a4b84971a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -325,17 +325,20 @@ struct drm_i915_gem_object {
  * dealing with userspace objects the CPU fault handler is free to ignore this.
  */
 #define I915_BO_ALLOC_GPU_ONLY   BIT(6)
+/* object should be pinned in destination region from allocation */
+#define I915_BO_ALLOC_PINNED BIT(7)
 #define I915_BO_ALLOC_FLAGS (I915_BO_ALLOC_CONTIGUOUS | \
 I915_BO_ALLOC_VOLATILE | \
 I915_BO_ALLOC_CPU_CLEAR | \
 I915_BO_ALLOC_USER | \
 I915_BO_ALLOC_PM_VOLATILE | \
 I915_BO_ALLOC_PM_EARLY | \
-I915_BO_ALLOC_GPU_ONLY)
-#define I915_BO_READONLY  BIT(7)
-#define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */
-#define I915_BO_PROTECTED BIT(9)
-#define I915_BO_WAS_BOUND_BIT 10
+I915_BO_ALLOC_GPU_ONLY | \
+I915_BO_ALLOC_PINNED)
+#define I915_BO_READONLY  BIT(8)
+#define I915_TILING_QUIRK_BIT 9 /* unknown swizzling; do not release! */
+#define I915_BO_PROTECTED BIT(10)
+#define I915_BO_WAS_BOUND_BIT 11
/**
 * @mem_flags - Mutable placement-related flags
 *
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index b6c3fc25d9d1..d34ebe9fcff8 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1011,6 +1011,13 @@ static void i915_ttm_delayed_free(struct 
drm_i915_gem_object *obj)
 {
GEM_BUG_ON(!obj->ttm.created);
 
+   /* stolen objects are pinned for lifetime. Unpin before putting */
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   ttm_bo_reserve(i915_gem_to_ttm(obj), true, false, NULL);
+   ttm_bo_unpin(i915_gem_to_ttm(obj));
+   ttm_bo_unreserve(i915_gem_to_ttm(obj));
+   }
+
ttm_bo_put(i915_gem_to_ttm(obj));
 }
 
@@ -1206,6 +1213,9 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
.no_wait_gpu = false,
};
enum ttm_bo_type bo_type;
+   struct ttm_place _place;
+   struct ttm_placement _placement;
+   struct ttm_placement *placement;
int ret;
 
drm_gem_private_object_init(&i915->drm, &obj->base, size);
@@ -1235,6 +1245,17 @@ int __i915_gem_ttm_object_init(struct 
intel_memory_region *mem,
 */
i915_gem_object_make_unshrinkable(obj);
 
+   if (obj->flags & I915_BO_ALLOC_PINNED) {
+   i915_ttm_place_from_region(mem, &_place, obj->bo_offset,
+  obj->base.size, obj->flags);
+   _placement.num_placement = 1;
+   _placement.placement = &_place;
+   _placement.num_busy_placement = 0;
+   _placement.busy_placement = NULL;
+   placement = &_placement;
+   } else {
+   placement = &i915_sys_placement;
+   }
/*
 * If this function fails, it will call the destructor, but
 * our caller still owns the object. So no freeing in the
@@ -1243,7 +1264,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
 * until successful initialization.
 */
ret = ttm_bo_init_reserved(&i915->bdev, i915_gem_to_ttm(obj), bo_type,
-  &i915_sys_placement, page_size >> PAGE_SHIFT,
+  placement, page_size >> PAGE_SHIFT,
   &ctx, NULL, NULL, i915_ttm_bo_destroy);
if (ret)
return i915_ttm_err_to_gem(ret);
@@ -1254,6 +1275,8 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
obj->ttm.cache_level_override = false;
+   if (obj->flags & I915_BO_ALLOC_PINNED)
+   ttm_bo_pin(i915_gem_to_ttm(obj));
i915_gem_object_unlock(obj);
 
return 0;
-- 
2.25.1



[PATCH v11 09/10] drm/i915/selftest: maintain context ref during reset test

2022-07-13 Thread Robert Beckett
Commit "bcb9aa45d5a0 Revert "drm/i915: Hold reference to intel_context over 
life of i915_request""
Stopped requests from maintaining a ref on the context.
This caused the contexts to be freed, releasing stolen memory while
under test, leading to false positive detection of stolen corruption.
Fix this by maintaining a ref on the contexts until testing is complete.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/selftest_reset.c | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_reset.c 
b/drivers/gpu/drm/i915/gt/selftest_reset.c
index 55f3b34e5f6e..ba536e8a2e32 100644
--- a/drivers/gpu/drm/i915/gt/selftest_reset.c
+++ b/drivers/gpu/drm/i915/gt/selftest_reset.c
@@ -6,6 +6,7 @@
 #include 
 
 #include "gem/i915_gem_stolen.h"
+#include "gt/intel_gt.h"
 
 #include "i915_memcpy.h"
 #include "i915_selftest.h"
@@ -26,6 +27,7 @@ __igt_reset_stolen(struct intel_gt *gt,
intel_wakeref_t wakeref;
enum intel_engine_id id;
struct igt_spinner spin;
+   struct intel_context *contexts[I915_NUM_ENGINES] = {0};
long max, count;
void *tmp;
u32 *crc;
@@ -71,12 +73,12 @@ __igt_reset_stolen(struct intel_gt *gt,
goto err_spin;
}
rq = igt_spinner_create_request(&spin, ce, MI_ARB_CHECK);
-   intel_context_put(ce);
if (IS_ERR(rq)) {
err = PTR_ERR(rq);
goto err_spin;
}
i915_request_add(rq);
+   contexts[id] = ce;
}
 
for (page = 0; page < num_pages; page++) {
@@ -165,8 +167,21 @@ __igt_reset_stolen(struct intel_gt *gt,
err = -EINVAL;
}
 
+   err = intel_gt_wait_for_idle(gt, HZ);
+   if (err < 0) {
+   pr_err("%s failed to wait for gt idle: %d\n", msg, err);
+   goto err_spin;
+   }
+
+   err = 0;
+
 err_spin:
igt_spinner_fini(&spin);
+   for (id = 0; id < I915_NUM_ENGINES; id++) {
+   if (!contexts[id])
+   continue;
+   intel_context_put(contexts[id]);
+   }
 
 err_lock:
intel_runtime_pm_put(gt->uncore->rpm, wakeref);
-- 
2.25.1



[PATCH v11 10/10] drm/i915: stolen memory use ttm backend

2022-07-13 Thread Robert Beckett
refactor stolen memory region to use ttm.
this necessitates using ttm resources to track reserved stolen regions
instead of drm_mm_nodes.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   2 -
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 425 ++
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   3 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  16 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   6 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |  42 +-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |  12 +-
 13 files changed, 280 insertions(+), 351 deletions(-)

diff --git a/drivers/gpu/drm/i915/display/intel_fbc.c 
b/drivers/gpu/drm/i915/display/intel_fbc.c
index 16537830ccf0..7dd42b11f4b8 100644
--- a/drivers/gpu/drm/i915/display/intel_fbc.c
+++ b/drivers/gpu/drm/i915/display/intel_fbc.c
@@ -38,6 +38,7 @@
  * forcibly disable it to allow proper screen updates.
  */
 
+#include "gem/i915_gem_stolen.h"
 #include 
 
 #include 
@@ -52,6 +53,7 @@
 #include "intel_display_types.h"
 #include "intel_fbc.h"
 #include "intel_frontbuffer.h"
+#include "gem/i915_gem_region.h"
 
 #define for_each_fbc_id(__dev_priv, __fbc_id) \
for ((__fbc_id) = INTEL_FBC_A; (__fbc_id) < I915_MAX_FBCS; 
(__fbc_id)++) \
@@ -93,8 +95,8 @@ struct intel_fbc {
struct mutex lock;
unsigned int busy_bits;
 
-   struct drm_mm_node compressed_fb;
-   struct drm_mm_node compressed_llb;
+   struct ttm_resource *compressed_fb;
+   struct ttm_resource *compressed_llb;
 
enum intel_fbc_id id;
 
@@ -332,16 +334,20 @@ static void i8xx_fbc_nuke(struct intel_fbc *fbc)
 static void i8xx_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
+   u64 llb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_llb);
 
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   GEM_BUG_ON(llb_offset == I915_BO_INVALID_OFFSET);
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_fb.start, U32_MAX));
+fb_offset, U32_MAX));
GEM_BUG_ON(range_overflows_end_t(u64, i915->dsm.start,
-fbc->compressed_llb.start, U32_MAX));
+llb_offset, U32_MAX));
 
intel_de_write(i915, FBC_CFB_BASE,
-  i915->dsm.start + fbc->compressed_fb.start);
+  i915->dsm.start + fb_offset);
intel_de_write(i915, FBC_LL_BASE,
-  i915->dsm.start + fbc->compressed_llb.start);
+  i915->dsm.start + llb_offset);
 }
 
 static const struct intel_fbc_funcs i8xx_fbc_funcs = {
@@ -449,8 +455,10 @@ static bool g4x_fbc_is_compressing(struct intel_fbc *fbc)
 static void g4x_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, DPFC_CB_BASE, fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, DPFC_CB_BASE, fb_offset);
 }
 
 static const struct intel_fbc_funcs g4x_fbc_funcs = {
@@ -500,8 +508,10 @@ static bool ilk_fbc_is_compressing(struct intel_fbc *fbc)
 static void ilk_fbc_program_cfb(struct intel_fbc *fbc)
 {
struct drm_i915_private *i915 = fbc->i915;
+   u64 fb_offset = i915_gem_stolen_reserve_offset(fbc->compressed_fb);
 
-   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), 
fbc->compressed_fb.start);
+   GEM_BUG_ON(fb_offset == I915_BO_INVALID_OFFSET);
+   intel_de_write(i915, ILK_DPFC_CB_BASE(fbc->id), fb_offset);
 }
 
 static const struct intel_fbc_funcs ilk_fbc_funcs = {
@@ -745,21 +755,24 @@ static int find_compression_limit(struct intel_fbc *fbc,
 {
struct drm_i915_private *i915 = fbc->i915;
u64 end = intel_fbc_stolen_end(i915);
-   int ret, limit = min_limit;
+   int limit = min_limit;
+   struct ttm_resource *res;
 
size /= limit;
 
/* Try to over-allocate to reduce reallocations and fragmentation. */
-   ret = i915_gem_stolen_insert_node_in_range(i915, &fbc->compressed_fb,
-  size <<= 1, 4096, 0, end);
-   if (ret == 0)
+   res = i915_gem_stolen_reserve_range(i915, size <<= 1, 0, end);
+   if (!IS_ERR(res)) {
+   fbc->compressed_fb = res;
return limit;
+   }
 
for (; limit <= i

[PATCH v11 04/10] drm/i915: instantiate ttm ranger manager for stolen memory

2022-07-13 Thread Robert Beckett
prepare for ttm based stolen region by using ttm range manager
as the resource manager for stolen region.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c |  6 ++--
 drivers/gpu/drm/i915/intel_region_ttm.c  | 31 +++-
 2 files changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index a949594237d9..2cc2c08bd50f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -66,11 +66,13 @@ i915_ttm_region(struct ttm_device *bdev, int ttm_mem_type)
struct drm_i915_private *i915 = container_of(bdev, typeof(*i915), bdev);
 
/* There's some room for optimization here... */
-   GEM_BUG_ON(ttm_mem_type != I915_PL_SYSTEM &&
-  ttm_mem_type < I915_PL_LMEM0);
+   GEM_BUG_ON(ttm_mem_type == I915_PL_GGTT);
+
if (ttm_mem_type == I915_PL_SYSTEM)
return intel_memory_region_lookup(i915, INTEL_MEMORY_SYSTEM,
  0);
+   if (ttm_mem_type == I915_PL_STOLEN)
+   return i915->mm.stolen_region;
 
return intel_memory_region_lookup(i915, INTEL_MEMORY_LOCAL,
  ttm_mem_type - I915_PL_LMEM0);
diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 642cd1587976..caac110a0a2c 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -54,7 +54,7 @@ void intel_region_ttm_device_fini(struct drm_i915_private 
*dev_priv)
 
 /*
  * Map the i915 memory regions to TTM memory types. We use the
- * driver-private types for now, reserving TTM_PL_VRAM for stolen
+ * driver-private types for now, reserving I915_PL_STOLEN for stolen
  * memory and TTM_PL_TT for GGTT use if decided to implement this.
  */
 int intel_region_to_ttm_type(const struct intel_memory_region *mem)
@@ -63,11 +63,17 @@ int intel_region_to_ttm_type(const struct 
intel_memory_region *mem)
 
GEM_BUG_ON(mem->type != INTEL_MEMORY_LOCAL &&
   mem->type != INTEL_MEMORY_MOCK &&
-  mem->type != INTEL_MEMORY_SYSTEM);
+  mem->type != INTEL_MEMORY_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_SYSTEM &&
+  mem->type != INTEL_MEMORY_STOLEN_LOCAL);
 
if (mem->type == INTEL_MEMORY_SYSTEM)
return TTM_PL_SYSTEM;
 
+   if (mem->type == INTEL_MEMORY_STOLEN_SYSTEM ||
+   mem->type == INTEL_MEMORY_STOLEN_LOCAL)
+   return I915_PL_STOLEN;
+
type = mem->instance + TTM_PL_PRIV;
GEM_BUG_ON(type >= TTM_NUM_MEM_TYPES);
 
@@ -91,10 +97,16 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
int mem_type = intel_region_to_ttm_type(mem);
int ret;
 
-   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
- resource_size(&mem->region),
- mem->io_size,
- mem->min_page_size, PAGE_SIZE);
+   if (mem_type == I915_PL_STOLEN) {
+   ret = ttm_range_man_init(bdev, mem_type, false,
+resource_size(&mem->region) >> 
PAGE_SHIFT);
+   mem->is_range_manager = true;
+   } else {
+   ret = i915_ttm_buddy_man_init(bdev, mem_type, false,
+ resource_size(&mem->region),
+ mem->io_size,
+ mem->min_page_size, PAGE_SIZE);
+   }
if (ret)
return ret;
 
@@ -114,6 +126,7 @@ int intel_region_ttm_init(struct intel_memory_region *mem)
 int intel_region_ttm_fini(struct intel_memory_region *mem)
 {
struct ttm_resource_manager *man = mem->region_private;
+   int mem_type = intel_region_to_ttm_type(mem);
int ret = -EBUSY;
int count;
 
@@ -144,8 +157,10 @@ int intel_region_ttm_fini(struct intel_memory_region *mem)
if (ret || !man)
return ret;
 
-   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev,
- intel_region_to_ttm_type(mem));
+   if (mem_type == I915_PL_STOLEN)
+   ret = ttm_range_man_fini(&mem->i915->bdev, mem_type);
+   else
+   ret = i915_ttm_buddy_man_fini(&mem->i915->bdev, mem_type);
GEM_WARN_ON(ret);
mem->region_private = NULL;
 
-- 
2.25.1



[PATCH v11 03/10] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

2022-07-13 Thread Robert Beckett
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 042c2237e287..a949594237d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -52,7 +52,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.25.1



[PATCH v11 06/10] drm/i915: ttm move/clear logic fix

2022-07-13 Thread Robert Beckett
ttm managed buffers start off with system resource definitions and ttm_tt
tracking structures allocated (though unpopulated).
currently this prevents clearing of buffers on first move to desired
placements.

The desired behaviour is to clear user allocated buffers and any kernel
buffers that specifically requests it only.
Make the logic match the desired behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 22 +++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 18d574ac167f..6671345b2abe 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -3,6 +3,7 @@
  * Copyright © 2021 Intel Corporation
  */
 
+#include "drm/ttm/ttm_tt.h"
 #include 
 
 #include "i915_deps.h"
@@ -546,6 +547,25 @@ __i915_ttm_move(struct ttm_buffer_object *bo,
return fence;
 }
 
+static bool
+allow_clear(struct drm_i915_gem_object *obj, struct ttm_tt *ttm, struct 
ttm_resource *dst_mem)
+{
+   /* never clear stolen */
+   if (dst_mem->mem_type == I915_PL_STOLEN)
+   return false;
+   /*
+* we want to clear user buffers and any kernel buffers
+* that specifically request clearing.
+*/
+   if (obj->flags & I915_BO_ALLOC_USER)
+   return true;
+
+   if (ttm && ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC)
+   return true;
+
+   return false;
+}
+
 /**
  * i915_ttm_move - The TTM move callback used by i915.
  * @bo: The buffer object.
@@ -596,7 +616,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool evict,
return PTR_ERR(dst_rsgt);
 
clear = !i915_ttm_cpu_maps_iomem(bo->resource) && (!ttm || 
!ttm_tt_is_populated(ttm));
-   if (!(clear && ttm && !(ttm->page_flags & TTM_TT_FLAG_ZERO_ALLOC))) {
+   if (!clear || allow_clear(obj, ttm, dst_mem)) {
struct i915_deps deps;
 
i915_deps_init(&deps, GFP_KERNEL | __GFP_NORETRY | 
__GFP_NOWARN);
-- 
2.25.1



[PATCH v11 02/10] drm/i915: limit ttm to dma32 for i965G[M]

2022-07-13 Thread Robert Beckett
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 6873808a7015..642cd1587976 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = &dev_priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.25.1



[PATCH v11 01/10] drm/i915/ttm: dont trample cache_level overrides during ttm move

2022-07-13 Thread Robert Beckett
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index ccec4055fde3..966ac2d778d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5cf36a130061..14937cf1daaa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -623,6 +623,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 053b0022ddd0..b6c3fc25d9d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1253,6 +1253,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84..042c2237e287 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -129,9 +129,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.25.1



[PATCH v11 00/10] drm/i915: ttm for stolen

2022-07-13 Thread Robert Beckett
This series refactors i915's stolen memory region to use ttm.

v2: handle disabled stolen similar to legacy version.
relying on ttm to fail allocs works fine, but is dmesg noisy and causes 
testing
dmesg warning regressions.

v3: rebase to latest drm-tip.
fix v2 code refactor which could leave a buffer pinned.
locally passes fftl again now.

v4: - Allow memory regions creators to do allocation. Allows stolen region 
to track
  it's own reservations.
- Pre-reserve first page of stolen mem (add back 
WaSkipStolenMemoryFirstPage:bdw+)
- Improve commit descritpion for "drm/i915: sanitize mem_flags for 
stolen buffers"
- replace i915_gem_object_pin_pages_unlocked() call with manual locking 
and pinning.
  this avoids ww ctx class reuse during context creation -> ring vma 
obj alloc.

v5: - detect both types of stolen as stolen buffers in
  "drm/i915: sanitize mem_flags for stolen buffers"
- in stolen_object_init limit page size to mem region minimum.
  The range allocator expects the page_size to define the
  alignment

v6: - Share first 4 patches from ttm for internal series as generic
  i915 ttm fixes
- Drop patch 4 from v5. We don't need separate object ops just
  to satisfy test interfaces. The tests have now been fixed via
  checking whether the memory region is private to decide
  whether to mmap
- Add new buffer pin alloc flag to allow creation of buffers in
  their final ttm placement instead of deferring until
  get_pages. This fixes legacy fallback paths for buffer
  allocations during stolen memory pressure.

v7: - fix mock_region_get_pages() to correctly handle I915_BO_INVALID_OFFSET

v8: - Reserve I915_GEM_STOLEN_BIAS area from stolen

v9: - drop patch 8 "drm/i915: allow memory region creators to alloc and 
free the region"
  store bias reservation in drm_i915_private instead.
- Restrict reset selftest to only test !GuC engines.
  Resetting individual GuC engines from host is not supported
- Wait for outstanding requests in reset selftest
  This prevents previous engine test context cleanup appearing
  as false positive stolen corruption check

v10:- Fix wiating on requests early error path during reset selftest
  If a single request fails to complete, the others would not be
  put, resulting in leaks. Make sure all requests are put before
  test exit.

v11:- rebased to latest drm-tip
- commit "bcb9aa45d5a0 Revert "drm/i915: Hold reference to 
intel_context over life of i915_request""
  broke the selftest@live@reset test, causing the context ringbuffer to
  be freed during testing. Fixed via maintinaing context ref
  during testing.
- drop patch 4 "drm/i915/gem: selftest should not attempt mmap of 
private regions"
  it is no longer needed.

Robert Beckett (10):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level
  drm/i915: instantiate ttm ranger manager for stolen memory
  drm/i915: sanitize mem_flags for stolen buffers
  drm/i915: ttm move/clear logic fix
  drm/i915/ttm: add buffer pin on alloc flag
  drm/i915/selftest: don't attempt engine reset of guc submission
engines
  drm/i915/selftest: maintain context ref during reset test
  drm/i915: stolen memory use ttm backend

 drivers/gpu/drm/i915/display/intel_fbc.c  |  78 ++--
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  16 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 425 ++
 drivers/gpu/drm/i915/gem/i915_gem_stolen.h|  21 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |  29 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm.h   |   7 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  47 +-
 drivers/gpu/drm/i915/gt/intel_rc6.c   |   4 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  35 +-
 drivers/gpu/drm/i915/i915_debugfs.c   |   7 +-
 drivers/gpu/drm/i915/i915_drv.h   |   6 +-
 drivers/gpu/drm/i915/intel_region_ttm.c   |  80 +++-
 drivers/gpu/drm/i915/intel_region_ttm.h   |   8 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |  12 +-
 15 files changed, 400 insertions(+), 376 deletions(-)

-- 
2.25.1



[PATCH v4 8/8] drm/i915: internal buffers use ttm backend

2022-07-13 Thread Robert Beckett
Create a kernel only internal memory region that uses ttm pool allocator to
allocate volatile system pages.
Refactor internal buffer backend to simply allocate from this new
region.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  | 187 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.h  |   5 -
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   8 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +-
 6 files changed, 17 insertions(+), 191 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_internal.c 
b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
index c698f95af15f..a83751867ac7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_internal.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_internal.c
@@ -4,188 +4,9 @@
  * Copyright © 2014-2016 Intel Corporation
  */
 
-#include 
-#include 
-#include 
-
+#include "gem/i915_gem_internal.h"
+#include "gem/i915_gem_region.h"
 #include "i915_drv.h"
-#include "i915_gem.h"
-#include "i915_gem_internal.h"
-#include "i915_gem_object.h"
-#include "i915_scatterlist.h"
-#include "i915_utils.h"
-
-#define QUIET (__GFP_NORETRY | __GFP_NOWARN)
-#define MAYFAIL (__GFP_RETRY_MAYFAIL | __GFP_NOWARN)
-
-static void internal_free_pages(struct sg_table *st)
-{
-   struct scatterlist *sg;
-
-   for (sg = st->sgl; sg; sg = __sg_next(sg)) {
-   if (sg_page(sg))
-   __free_pages(sg_page(sg), get_order(sg->length));
-   }
-
-   sg_free_table(st);
-   kfree(st);
-}
-
-static int i915_gem_object_get_pages_internal(struct drm_i915_gem_object *obj)
-{
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct sg_table *st;
-   struct scatterlist *sg;
-   unsigned int sg_page_sizes;
-   unsigned int npages;
-   int max_order;
-   gfp_t gfp;
-
-   max_order = MAX_ORDER;
-#ifdef CONFIG_SWIOTLB
-   if (is_swiotlb_active(obj->base.dev->dev)) {
-   unsigned int max_segment;
-
-   max_segment = swiotlb_max_segment();
-   if (max_segment) {
-   max_segment = max_t(unsigned int, max_segment,
-   PAGE_SIZE) >> PAGE_SHIFT;
-   max_order = min(max_order, ilog2(max_segment));
-   }
-   }
-#endif
-
-   gfp = GFP_KERNEL | __GFP_HIGHMEM | __GFP_RECLAIMABLE;
-   if (IS_I965GM(i915) || IS_I965G(i915)) {
-   /* 965gm cannot relocate objects above 4GiB. */
-   gfp &= ~__GFP_HIGHMEM;
-   gfp |= __GFP_DMA32;
-   }
-
-create_st:
-   st = kmalloc(sizeof(*st), GFP_KERNEL);
-   if (!st)
-   return -ENOMEM;
-
-   npages = obj->base.size / PAGE_SIZE;
-   if (sg_alloc_table(st, npages, GFP_KERNEL)) {
-   kfree(st);
-   return -ENOMEM;
-   }
-
-   sg = st->sgl;
-   st->nents = 0;
-   sg_page_sizes = 0;
-
-   do {
-   int order = min(fls(npages) - 1, max_order);
-   struct page *page;
-
-   do {
-   page = alloc_pages(gfp | (order ? QUIET : MAYFAIL),
-  order);
-   if (page)
-   break;
-   if (!order--)
-   goto err;
-
-   /* Limit subsequent allocations as well */
-   max_order = order;
-   } while (1);
-
-   sg_set_page(sg, page, PAGE_SIZE << order, 0);
-   sg_page_sizes |= PAGE_SIZE << order;
-   st->nents++;
-
-   npages -= 1 << order;
-   if (!npages) {
-   sg_mark_end(sg);
-   break;
-   }
-
-   sg = __sg_next(sg);
-   } while (1);
-
-   if (i915_gem_gtt_prepare_pages(obj, st)) {
-   /* Failed to dma-map try again with single page sg segments */
-   if (get_order(st->sgl->length)) {
-   internal_free_pages(st);
-   max_order = 0;
-   goto create_st;
-   }
-   goto err;
-   }
-
-   __i915_gem_object_set_pages(obj, st, sg_page_sizes);
-
-   return 0;
-
-err:
-   sg_set_page(sg, NULL, 0, 0);
-   sg_mark_end(sg);
-   internal_free_pages(st);
-
-   return -ENOMEM;
-}
-
-static void i915_gem_object_put_pages_internal(struct drm_i915_gem_object *obj,
-  struct sg_table *pages)
-{
-   i915_gem_gtt_finish_pages(obj, pages);
-   internal_free_pages(pages);
-
-   obj->mm.dirty = false;
-
-   __start_cpu_write(obj);
-}
-
-static const struct drm_i915_gem_object_ops i915_gem_object_internal_ops = {
-   .name = "i915_gem_object_internal",
-   .flags = I

[PATCH v4 5/8] drm/i915: setup ggtt scratch page after memory regions

2022-07-13 Thread Robert Beckett
Reorder scratch page allocation so that memory regions are available
to allocate the buffers

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 20 ++--
 drivers/gpu/drm/i915/gt/intel_gtt.h  |  1 +
 drivers/gpu/drm/i915/i915_driver.c   | 16 ++--
 3 files changed, 29 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 15a915bb4088..c4ad03e53236 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -866,8 +866,6 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
struct drm_i915_private *i915 = ggtt->vm.i915;
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
phys_addr_t phys_addr;
-   u32 pte_flags;
-   int ret;
 
GEM_WARN_ON(pci_resource_len(pdev, 0) != gen6_gttmmadr_size(i915));
phys_addr = pci_resource_start(pdev, 0) + gen6_gttadr_offset(i915);
@@ -889,6 +887,24 @@ static int ggtt_probe_common(struct i915_ggtt *ggtt, u64 
size)
}
 
kref_init(&ggtt->vm.resv_ref);
+
+   return 0;
+}
+
+/**
+ * i915_ggtt_setup_scratch_page - setup ggtt scratch page
+ * @i915: i915 device
+ */
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915)
+{
+   struct i915_ggtt *ggtt = to_gt(i915)->ggtt;
+   u32 pte_flags;
+   int ret;
+
+   /* gen5- scratch setup currently happens in @intel_gtt_init */
+   if (GRAPHICS_VER(i915) <= 5)
+   return 0;
+
ret = setup_scratch_page(&ggtt->vm);
if (ret) {
drm_err(&i915->drm, "Scratch setup failed\n");
diff --git a/drivers/gpu/drm/i915/gt/intel_gtt.h 
b/drivers/gpu/drm/i915/gt/intel_gtt.h
index e639434e97fd..4ebdf70b5273 100644
--- a/drivers/gpu/drm/i915/gt/intel_gtt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gtt.h
@@ -579,6 +579,7 @@ void intel_ggtt_unbind_vma(struct i915_address_space *vm,
   struct i915_vma_resource *vma_res);
 
 int i915_ggtt_probe_hw(struct drm_i915_private *i915);
+int i915_ggtt_setup_scratch_page(struct drm_i915_private *i915);
 int i915_ggtt_init_hw(struct drm_i915_private *i915);
 int i915_ggtt_enable_hw(struct drm_i915_private *i915);
 void i915_ggtt_enable_guc(struct i915_ggtt *ggtt);
diff --git a/drivers/gpu/drm/i915/i915_driver.c 
b/drivers/gpu/drm/i915/i915_driver.c
index deb8a8b76965..fa0956840fcc 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -69,6 +69,7 @@
 #include "gem/i915_gem_mman.h"
 #include "gem/i915_gem_pm.h"
 #include "gt/intel_gt.h"
+#include "gt/intel_gtt.h"
 #include "gt/intel_gt_pm.h"
 #include "gt/intel_rc6.h"
 
@@ -609,12 +610,16 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 
ret = intel_gt_tiles_init(dev_priv);
if (ret)
-   goto err_mem_regions;
+   goto err_ggtt;
+
+   ret = i915_ggtt_setup_scratch_page(dev_priv);
+   if (ret)
+   goto err_ggtt;
 
ret = i915_ggtt_enable_hw(dev_priv);
if (ret) {
drm_err(&dev_priv->drm, "failed to enable GGTT\n");
-   goto err_mem_regions;
+   goto err_ggtt;
}
 
pci_set_master(pdev);
@@ -675,11 +680,10 @@ static int i915_driver_hw_probe(struct drm_i915_private 
*dev_priv)
 err_msi:
if (pdev->msi_enabled)
pci_disable_msi(pdev);
-err_mem_regions:
-   intel_memory_regions_driver_release(dev_priv);
 err_ggtt:
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 err_perf:
i915_perf_fini(dev_priv);
@@ -928,9 +932,9 @@ int i915_driver_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent)
intel_modeset_driver_remove_nogem(i915);
 out_cleanup_hw:
i915_driver_hw_remove(i915);
-   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_release(i915);
i915_gem_drain_freed_objects(i915);
+   intel_memory_regions_driver_release(i915);
i915_ggtt_driver_late_release(i915);
 out_cleanup_mmio:
i915_driver_mmio_release(i915);
@@ -987,9 +991,9 @@ static void i915_driver_release(struct drm_device *dev)
 
i915_gem_driver_release(dev_priv);
 
-   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_release(dev_priv);
i915_gem_drain_freed_objects(dev_priv);
+   intel_memory_regions_driver_release(dev_priv);
i915_ggtt_driver_late_release(dev_priv);
 
i915_driver_mmio_release(dev_priv);
-- 
2.25.1



[PATCH v4 4/8] drm/i915: add gen6 ppgtt dummy creation function

2022-07-13 Thread Robert Beckett
Internal gem objects will soon just be volatile system memory region
objects.
To enable this, create a separate dummy object creation function
for gen6 ppgtt. The object only exists as a fake object pointing to ggtt
and gains no benefit in going via the internal backend.
Instead, create a dummy gem object and avoid having to maintain a custom
ops api in the internal backend, which makes later refactoring easier.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c | 43 ++--
 1 file changed, 40 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c 
b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
index 1bb766c79dcb..f3b660cfeb7f 100644
--- a/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/gen6_ppgtt.c
@@ -372,6 +372,45 @@ static const struct drm_i915_gem_object_ops 
pd_dummy_obj_ops = {
.put_pages = pd_dummy_obj_put_pages,
 };
 
+static struct drm_i915_gem_object *
+i915_gem_object_create_dummy(struct drm_i915_private *i915, phys_addr_t size)
+{
+   static struct lock_class_key lock_class;
+   struct drm_i915_gem_object *obj;
+   unsigned int cache_level;
+
+   GEM_BUG_ON(!size);
+   GEM_BUG_ON(!IS_ALIGNED(size, PAGE_SIZE));
+
+   if (overflows_type(size, obj->base.size))
+   return ERR_PTR(-E2BIG);
+
+   obj = i915_gem_object_alloc();
+   if (!obj)
+   return ERR_PTR(-ENOMEM);
+
+   drm_gem_private_object_init(&i915->drm, &obj->base, size);
+   i915_gem_object_init(obj, &pd_dummy_obj_ops, &lock_class, 0);
+   obj->mem_flags |= I915_BO_FLAG_STRUCT_PAGE;
+
+   /*
+* Mark the object as volatile, such that the pages are marked as
+* dontneed whilst they are still pinned. As soon as they are unpinned
+* they are allowed to be reaped by the shrinker, and the caller is
+* expected to repopulate - the contents of this object are only valid
+* whilst active and pinned.
+*/
+   i915_gem_object_set_volatile(obj);
+
+   obj->read_domains = I915_GEM_DOMAIN_CPU;
+   obj->write_domain = I915_GEM_DOMAIN_CPU;
+
+   cache_level = HAS_LLC(i915) ? I915_CACHE_LLC : I915_CACHE_NONE;
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+
+   return obj;
+}
+
 static struct i915_page_directory *
 gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
 {
@@ -383,9 +422,7 @@ gen6_alloc_top_pd(struct gen6_ppgtt *ppgtt)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
 
-   pd->pt.base = __i915_gem_object_create_internal(ppgtt->base.vm.gt->i915,
-   &pd_dummy_obj_ops,
-   I915_PDES * SZ_4K);
+   pd->pt.base = i915_gem_object_create_dummy(ppgtt->base.vm.gt->i915, 
I915_PDES * SZ_4K);
if (IS_ERR(pd->pt.base)) {
err = PTR_ERR(pd->pt.base);
pd->pt.base = NULL;
-- 
2.25.1



[PATCH v4 7/8] drm/i915/gem: further fix mman selftest

2022-07-13 Thread Robert Beckett
In commit 450cede7f380 ("drm/i915/gem: Fix the mman selftest") we fixed up
the mman selftest to allocate user buffers via smem only if we have lmem,
otherwise it uses internal buffers.

As the commit message asserts, we should only be using buffers that
userland should be able to create.
Internal buffers are not intended to be used by userland.

Instead, fix the code to always create buffers from smem.
In the case of integrated, this will create them from the shmem non-ttm
backend, which is fine.

This also fixes up the code to allow conversion of internal backend to
ttm without breaking this test.

Signed-off-by: Robert Beckett 
---
 .../gpu/drm/i915/gem/selftests/i915_gem_mman.c  | 17 ++---
 1 file changed, 6 insertions(+), 11 deletions(-)

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 3ced9948a331..e529eb8461ff 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_mman.c
@@ -596,17 +596,12 @@ static enum i915_mmap_type default_mapping(struct 
drm_i915_private *i915)
 }
 
 static struct drm_i915_gem_object *
-create_sys_or_internal(struct drm_i915_private *i915,
-  unsigned long size)
+create_sys(struct drm_i915_private *i915, unsigned long size)
 {
-   if (HAS_LMEM(i915)) {
-   struct intel_memory_region *sys_region =
-   i915->mm.regions[INTEL_REGION_SMEM];
+   struct intel_memory_region *sys_region =
+   i915->mm.regions[INTEL_REGION_SMEM];
 
-   return __i915_gem_object_create_user(i915, size, &sys_region, 
1);
-   }
-
-   return i915_gem_object_create_internal(i915, size);
+   return __i915_gem_object_create_user(i915, size, &sys_region, 1);
 }
 
 static bool assert_mmap_offset(struct drm_i915_private *i915,
@@ -617,7 +612,7 @@ static bool assert_mmap_offset(struct drm_i915_private 
*i915,
u64 offset;
int ret;
 
-   obj = create_sys_or_internal(i915, size);
+   obj = create_sys(i915, size);
if (IS_ERR(obj))
return expected && expected == PTR_ERR(obj);
 
@@ -719,7 +714,7 @@ static int igt_mmap_offset_exhaustion(void *arg)
}
 
/* Fill the hole, further allocation attempts should then fail */
-   obj = create_sys_or_internal(i915, PAGE_SIZE);
+   obj = create_sys(i915, PAGE_SIZE);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
pr_err("Unable to create object for reclaimed hole\n");
-- 
2.25.1



[PATCH v4 6/8] drm/i915: allow volatile buffers to use ttm pool allocator

2022-07-13 Thread Robert Beckett
Internal/volatile buffers should not be shmem backed.
If a volatile buffer is requested, allow ttm to use the pool allocator
to provide volatile pages as backing.
Fix i915_ttm_shrink to handle !is_shmem volatile buffers by purging.

Signed-off-by: Robert Beckett 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index b6c3fc25d9d1..599ed2713359 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -291,7 +291,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;
 
caching = i915_ttm_select_tt_caching(obj);
-   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached) {
+   if (i915_gem_object_is_shrinkable(obj) && caching == ttm_cached &&
+   !i915_gem_object_is_volatile(obj)) {
page_flags |= TTM_TT_FLAG_EXTERNAL |
  TTM_TT_FLAG_EXTERNAL_MAPPABLE;
i915_tt->is_shmem = true;
@@ -513,9 +514,9 @@ static int i915_ttm_shrink(struct drm_i915_gem_object *obj, 
unsigned int flags)
if (!bo->ttm || bo->resource->mem_type != TTM_PL_SYSTEM)
return 0;
 
-   GEM_BUG_ON(!i915_tt->is_shmem);
+   GEM_BUG_ON(!i915_tt->is_shmem && obj->mm.madv != I915_MADV_DONTNEED);
 
-   if (!i915_tt->filp)
+   if (i915_tt->is_shmem && !i915_tt->filp)
return 0;
 
ret = ttm_bo_wait_ctx(bo, &ctx);
-- 
2.25.1



[PATCH v4 3/8] drm/i915/ttm: only trust snooping for dgfx when deciding default cache_level

2022-07-13 Thread Robert Beckett
By default i915_ttm_cache_level() decides I915_CACHE_LLC if HAS_SNOOP.
This is divergent from existing backends code which only considers
HAS_LLC.
Testing shows that trusting snooping on gen5- is unreliable and bsw via
ggtt mappings, so limit DGFX for now and maintain previous behaviour.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 042c2237e287..a949594237d9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -52,7 +52,9 @@ static enum i915_cache_level
 i915_ttm_cache_level(struct drm_i915_private *i915, struct ttm_resource *res,
 struct ttm_tt *ttm)
 {
-   return ((HAS_LLC(i915) || HAS_SNOOP(i915)) &&
+   bool can_snoop = HAS_SNOOP(i915) && IS_DGFX(i915);
+
+   return ((HAS_LLC(i915) || can_snoop) &&
!i915_ttm_gtt_binds_lmem(res) &&
ttm->caching == ttm_cached) ? I915_CACHE_LLC :
I915_CACHE_NONE;
-- 
2.25.1



[PATCH v4 0/8] drm/i915: ttm for internal

2022-07-13 Thread Robert Beckett
This series refactors i915's internal buffer backend to use ttm.
It uses ttm's pool allocator to allocate volatile pages in place of the
old code which rolled its own via alloc_pages.
This is continuing progress to align all backends on using ttm.

v2: - commit message improvements to add detail
- fix i915_ttm_shrink to purge !is_shmem volatile buffers
- limit ttm pool allocator to using dma32 on i965G[M]
- fix mman selftest to always use smem buffers
- create new internal memory region
- make internal backend allocate from internal region
- Fixed various issues with tests and i915 ttm usage as a result
  of supporting regions other than lmem via ttm.

v3: - limit i915 ttm default cache_level selection to only trust
  HAS_SNOOP on DGFX.

v4: - rebase to drm-tip and handle conflicts

Robert Beckett (8):
  drm/i915/ttm: dont trample cache_level overrides during ttm move
  drm/i915: limit ttm to dma32 for i965G[M]
  drm/i915/ttm: only trust snooping for dgfx when deciding default
cache_level
  drm/i915: add gen6 ppgtt dummy creation function
  drm/i915: setup ggtt scratch page after memory regions
  drm/i915: allow volatile buffers to use ttm pool allocator
  drm/i915/gem: further fix mman selftest
  drm/i915: internal buffers use ttm backend

 drivers/gpu/drm/i915/gem/i915_gem_internal.c  | 187 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.h  |   5 -
 drivers/gpu/drm/i915/gem/i915_gem_object.c|   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c   |   8 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  13 +-
 .../drm/i915/gem/selftests/i915_gem_mman.c|  17 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |  43 +++-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  20 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   1 +
 drivers/gpu/drm/i915/i915_driver.c|  16 +-
 drivers/gpu/drm/i915/i915_pci.c   |   4 +-
 drivers/gpu/drm/i915/intel_memory_region.c|   8 +-
 drivers/gpu/drm/i915/intel_memory_region.h|   2 +
 drivers/gpu/drm/i915/intel_region_ttm.c   |   7 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |   2 +-
 16 files changed, 114 insertions(+), 221 deletions(-)

-- 
2.25.1



[PATCH v4 1/8] drm/i915/ttm: dont trample cache_level overrides during ttm move

2022-07-13 Thread Robert Beckett
Various places within the driver override the default chosen cache_level.
Before ttm, these overrides were permanent until explicitly changed again
or for the lifetime of the buffer.

TTM movement code came along and decided that it could make that
decision at that time, which is usually well after object creation, so
overrode the cache_level decision and reverted it back to its default
decision.

Add logic to indicate whether the caching mode has been set by anything
other than the move logic. If so, assume that the code that overrode the
defaults knows best and keep it.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gem/i915_gem_object.c   | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 1 +
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 9 ++---
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c 
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index ccec4055fde3..966ac2d778d5 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -125,6 +125,7 @@ void i915_gem_object_set_cache_coherency(struct 
drm_i915_gem_object *obj,
struct drm_i915_private *i915 = to_i915(obj->base.dev);
 
obj->cache_level = cache_level;
+   obj->ttm.cache_level_override = true;
 
if (cache_level != I915_CACHE_NONE)
obj->cache_coherent = (I915_BO_CACHE_COHERENT_FOR_READ |
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5cf36a130061..14937cf1daaa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -623,6 +623,7 @@ struct drm_i915_gem_object {
struct i915_gem_object_page_iter get_io_page;
struct drm_i915_gem_object *backup;
bool created:1;
+   bool cache_level_override:1;
} ttm;
 
/*
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index 053b0022ddd0..b6c3fc25d9d1 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -1253,6 +1253,7 @@ int __i915_gem_ttm_object_init(struct intel_memory_region 
*mem,
i915_gem_object_init_memory_region(obj, mem);
i915_ttm_adjust_domains_after_move(obj);
i915_ttm_adjust_gem_after_move(obj);
+   obj->ttm.cache_level_override = false;
i915_gem_object_unlock(obj);
 
return 0;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
index 9a7e50534b84..042c2237e287 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
@@ -129,9 +129,12 @@ void i915_ttm_adjust_gem_after_move(struct 
drm_i915_gem_object *obj)
obj->mem_flags |= i915_ttm_cpu_maps_iomem(bo->resource) ? 
I915_BO_FLAG_IOMEM :
I915_BO_FLAG_STRUCT_PAGE;
 
-   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev), bo->resource,
-  bo->ttm);
-   i915_gem_object_set_cache_coherency(obj, cache_level);
+   if (!obj->ttm.cache_level_override) {
+   cache_level = i915_ttm_cache_level(to_i915(bo->base.dev),
+  bo->resource, bo->ttm);
+   i915_gem_object_set_cache_coherency(obj, cache_level);
+   obj->ttm.cache_level_override = false;
+   }
 }
 
 /**
-- 
2.25.1



[PATCH v4 2/8] drm/i915: limit ttm to dma32 for i965G[M]

2022-07-13 Thread Robert Beckett
i965G[M] cannot relocate objects above 4GiB.
Ensure ttm uses dma32 on these systems.

Signed-off-by: Robert Beckett 
Reviewed-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/intel_region_ttm.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_region_ttm.c 
b/drivers/gpu/drm/i915/intel_region_ttm.c
index 6873808a7015..642cd1587976 100644
--- a/drivers/gpu/drm/i915/intel_region_ttm.c
+++ b/drivers/gpu/drm/i915/intel_region_ttm.c
@@ -32,10 +32,15 @@
 int intel_region_ttm_device_init(struct drm_i915_private *dev_priv)
 {
struct drm_device *drm = &dev_priv->drm;
+   bool use_dma32 = false;
+
+   /* i965g[m] cannot relocate objects above 4GiB. */
+   if (IS_I965GM(dev_priv) || IS_I965G(dev_priv))
+   use_dma32 = true;
 
return ttm_device_init(&dev_priv->bdev, i915_ttm_driver(),
   drm->dev, drm->anon_inode->i_mapping,
-  drm->vma_offset_manager, false, false);
+  drm->vma_offset_manager, false, use_dma32);
 }
 
 /**
-- 
2.25.1



Re: [PATCH v2 5/8] drm/vboxvideo: Use the hotspot properties from cursor planes

2022-07-13 Thread Zack Rusin
On Wed, 2022-07-13 at 10:20 +0300, Pekka Paalanen wrote:
> On Wed, 13 Jul 2022 03:35:57 +
> Zack Rusin  wrote:
> 
> > On Tue, 2022-07-12 at 10:56 +0300, Pekka Paalanen wrote:
> > > On Mon, 11 Jul 2022 23:32:43 -0400
> > > Zack Rusin  wrote:
> > >   
> > > > From: Zack Rusin 
> > > > 
> > > > Atomic modesetting got support for mouse hotspots via the hotspot
> > > > properties. Port the legacy kms hotspot handling to the new properties
> > > > on cursor planes.
> > > > 
> > > > Signed-off-by: Zack Rusin 
> > > > Cc: Hans de Goede 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > ---
> > > >  drivers/gpu/drm/vboxvideo/vbox_mode.c | 4 ++--
> > > >  1 file changed, 2 insertions(+), 2 deletions(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c 
> > > > b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > > index fa0d73ce07bc..ca3134adb104 100644
> > > > --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > > +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> > > > @@ -429,8 +429,8 @@ static void vbox_cursor_atomic_update(struct 
> > > > drm_plane *plane,
> > > > flags = VBOX_MOUSE_POINTER_VISIBLE | VBOX_MOUSE_POINTER_SHAPE |
> > > > VBOX_MOUSE_POINTER_ALPHA;
> > > > hgsmi_update_pointer_shape(vbox->guest_pool, flags,
> > > > -  min_t(u32, max(fb->hot_x, 0), width),
> > > > -  min_t(u32, max(fb->hot_y, 0), 
> > > > height),
> > > > +  min_t(u32, max(new_state->hotspot_x, 
> > > > 0), width),
> > > > +  min_t(u32, max(new_state->hotspot_y, 
> > > > 0), height),
> > > >width, height, vbox->cursor_data, 
> > > > data_size);
> > > >  
> > > > mutex_unlock(&vbox->hw_mutex);  
> > > 
> > > Hi,
> > > 
> > > this looks like silent clamping of the hotspot coordinates.
> > > 
> > > Should the DRM core perhaps already ensure that the hotspot must reside
> > > inside the plane (fb) boundaries and reject the atomic (TEST_ONLY)
> > > commit when it's outside?
> > > 
> > > Or if this restriction is not universal, maybe this driver should
> > > reject invalid hotspots rather than silently mangle them?  
> > 
> > TBH, I'm not really sure why vboxvideo is clamping those values. I didn't 
> > want to
> > introduce any regressions by changing it here, but the hotspot code never 
> > specified
> > that the hotspot offsets have to be positive or even within the plane. In a 
> > quick
> > search I couldn't find real world cursors that were doing anything like 
> > that though
> > so I just left it.
> > 
> > > Also, if supports_virtual_cursor_plane is false, should there not be
> > > somewhere code that will ignore the values set to the atomic hotspot
> > > properties?  
> > 
> > Hmm, good question. I'm not sure if there's a case where that could be 
> > possible:
> > without supports_virtual_cursor we either won't have a cursor plane or the 
> > client
> > won't be atomic and will only be allowed to use the old legacy kms ioctl's, 
> > i.e.
> > drmModeSetCursor2.
> > 
> > > When one KMS client switches to another, the first one being hotspot
> > > aware and the latter not, and both atomic, then the latter KMS client
> > > who doesn't know to drive the hotspot will inherit potentially invalid
> > > hotspot from the previous KMS client. Does something prevent that from
> > > being a problem?  
> > 
> > That switch will result in plane state reset, ending in
> > __drm_atomic_helper_plane_state_reset which will reset both hotspot 
> > properties (set
> > them to 0).
> 
> It will?
> 
> To my knowledge, KMS has never reset anything when one KMS client
> switches to the next, so that's new.
> 
> What triggers it?
> 
> Only if you actually switch to fbdev/fbcon instead of another userspace
> KMS client, the fbdev code might reset some things, but not all.
> 
> > > The old KMS client may have left the virtual cursor plane visible, and
> > > the new KMS client doesn't even know the virtual cursor plane exists
> > > because it doesn't set the DRM client cap. Something should probably
> > > ensure the virtual cursor plane gets disabled, right?  
> > 
> > Hah, that's also a good question. I *think* the same code to above would be 
> > ran,
> > i.e. plane reset which should result in the plane disappearing and the new 
> > client
> > not being able to drive it anymore. At least when running gnome-shell, 
> > switching to
> > weston and then switching to gnome-shell things look ok, but I haven't 
> > tried running
> > such clients at the same time.
> 
> That's an interesting experiment, but how is "at the same time"
> different from what you tested?
> 
> As i mentioned above, if you switch to fbcon in between, then you are
> not switching from one userspace KMS client to the next.

FWIW, running weston inside gnome-shell as a window also works fine. And 
running 
weston-simple-damage --width=60 --height=60 which, currently would 

Re: [PATCH v4 13/13] video: backlight: mt6370: Add Mediatek MT6370 support

2022-07-13 Thread Lee Jones
On Wed, 13 Jul 2022, Andy Shevchenko wrote:

> On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu  wrote:
> > Andy Shevchenko  於 2022年7月5日 週二 清晨5:14寫道:
> > > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu  wrote:
> 
> Please, remove unneeded context when replying!
> 
> ...
> 
> > > > +   brightness_val[0] = (brightness - 1) & 
> > > > MT6370_BL_DIM2_MASK;
> > > > +   brightness_val[1] = (brightness - 1)
> > > > +   >> fls(MT6370_BL_DIM2_MASK);
> > >
> > > Bad indentation. One line?
> >
> > Well... if indent to one line, it will be over 80 characters(or called 
> > columns?)
> > From my understanding, it is not allowed, right??
> 
> It's allowed to some extent.Use your common sense.
> Here it's obviously broken indentation.

Refrain from going crazy though - hard limit is 100 chars.

-- 
Lee Jones [李琼斯]
Principal Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog


linux-next: build failure after merge of the drm-intel-fixes tree

2022-07-13 Thread Stephen Rothwell
Hi all,

After merging the drm-intel-fixes tree, today's linux-next build (i386
defconfig) failed like this:

x86_64-linux-gnu-ld: drivers/gpu/drm/i915/i915_scatterlist.o: in function 
`i915_rsgt_from_mm_node':
i915_scatterlist.c:(.text+0x196): undefined reference to `__udivdi3'

Caused by commit

  aff1e0b09b54 ("drm/i915/ttm: fix sg_table construction")

I have reverted that commit for today.

-- 
Cheers,
Stephen Rothwell


pgpXxstowNATl.pgp
Description: OpenPGP digital signature


Re: [PATCH v4 13/13] video: backlight: mt6370: Add Mediatek MT6370 support

2022-07-13 Thread Andy Shevchenko
On Wed, Jul 13, 2022 at 12:53 PM ChiaEn Wu  wrote:
> Andy Shevchenko  於 2022年7月5日 週二 清晨5:14寫道:
> > On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu  wrote:

Please, remove unneeded context when replying!

...

> > > +   brightness_val[0] = (brightness - 1) & 
> > > MT6370_BL_DIM2_MASK;
> > > +   brightness_val[1] = (brightness - 1)
> > > +   >> fls(MT6370_BL_DIM2_MASK);
> >
> > Bad indentation. One line?
>
> Well... if indent to one line, it will be over 80 characters(or called 
> columns?)
> From my understanding, it is not allowed, right??

It's allowed to some extent.Use your common sense.
Here it's obviously broken indentation.

...

> > > +   prop_val = (ilog2(roundup_pow_of_two(prop_val)) + 1) >> 1;
> >
> > Isn't something closer to get_order() or fls()?
>
> I will revise it to "(get_order(prop_va * PAGE_SIZE) + 1) / 2" and
> this change is meet your expectations??

Nope. Try again. What about fls()?

...

> > > +   props->max_brightness = min_t(u32, brightness,
> > > + MT6370_BL_MAX_BRIGHTNESS);
> >
> > One line?
>
>  Ditto, it will be over 80 characters...

As per above.

-- 
With Best Regards,
Andy Shevchenko


Re: [Linaro-mm-sig] [PATCH] dma-buf/dma_resv_usage: update explicit sync documentation

2022-07-13 Thread Bas Nieuwenhuizen
With that changed

Reviewed-by: Bas Nieuwenhuizen 

Thanks!

On Tue, Jul 12, 2022 at 3:23 PM Christian König
 wrote:
>
> Am 12.07.22 um 15:20 schrieb Alex Deucher:
> > On Tue, Jul 12, 2022 at 9:12 AM Christian König
> >  wrote:
> >> Make it clear that DMA_RESV_USAGE_BOOKMARK can be used for explicit synced
> > DMA_RESV_USAGE_BOOKKEEP?
>
> Crappy autocorrect and copy&paste. Thanks for pointing that out.
>
> Christian.
>
> >
> >> user space submissions as well and document the rules around adding the
> >> same fence with different usages.
> >>
> >> Signed-off-by: Christian König 
> >> ---
> >>   include/linux/dma-resv.h | 16 +---
> >>   1 file changed, 13 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
> >> index c8ccbc94d5d2..264e27e56dff 100644
> >> --- a/include/linux/dma-resv.h
> >> +++ b/include/linux/dma-resv.h
> >> @@ -62,6 +62,11 @@ struct dma_resv_list;
> >>* For example when asking for WRITE fences then the KERNEL fences are 
> >> returned
> >>* as well. Similar when asked for READ fences then both WRITE and KERNEL
> >>* fences are returned as well.
> >> + *
> >> + * Already used fences can be promoted in the sense that a fence with
> >> + * DMA_RESV_USAGE_BOOKMARK could become DMA_RESV_USAGE_READ by adding it 
> >> again
> > Same here.
> >
> > With that fixed,
> > Acked-by: Alex Deucher 
> >
> > Alex
> >
> >> + * with this usage. But fences can never be degraded in the sense that a 
> >> fence
> >> + * with DMA_RESV_USAGE_WRITE could become DMA_RESV_USAGE_READ.
> >>*/
> >>   enum dma_resv_usage {
> >>  /**
> >> @@ -98,10 +103,15 @@ enum dma_resv_usage {
> >>   * @DMA_RESV_USAGE_BOOKKEEP: No implicit sync.
> >>   *
> >>   * This should be used by submissions which don't want to 
> >> participate in
> >> -* implicit synchronization.
> >> +* any implicit synchronization.
> >> +*
> >> +* The most common case are preemption fences, page table updates, 
> >> TLB
> >> +* flushes as well as explicit synced user submissions.
> >>   *
> >> -* The most common case are preemption fences as well as page table
> >> -* updates and their TLB flushes.
> >> +* Explicit synced user user submissions can be promoted to
> >> +* DMA_RESV_USAGE_READ or DMA_RESV_USAGE_WRITE as needed using
> >> +* dma_buf_import_sync_file() when implicit synchronization should
> >> +* become necessary after initial adding of the fence.
> >>   */
> >>  DMA_RESV_USAGE_BOOKKEEP
> >>   };
> >> --
> >> 2.25.1
> >>
> >> ___
> >> Linaro-mm-sig mailing list -- linaro-mm-...@lists.linaro.org
> >> To unsubscribe send an email to linaro-mm-sig-le...@lists.linaro.org
>


Re: [PATCH v4 13/13] video: backlight: mt6370: Add Mediatek MT6370 support

2022-07-13 Thread ChiaEn Wu
Hi Andy,
Thanks for your reply! I have some questions want to ask you below.

Andy Shevchenko  於 2022年7月5日 週二 清晨5:14寫道:
>
> On Mon, Jul 4, 2022 at 7:43 AM ChiaEn Wu  wrote:
> >
> > From: ChiaEn Wu 
> >
> > Add Mediatek MT6370 Backlight support.
>
> ...
>
> > + This driver can also be built as a module. If so the module
>
> If so,
>
> > + will be called "mt6370-backlight.ko".
>
> No ".ko" part.
>
> ...
>
> > +#include 
>
> Can you elaborate on this?
>
> > +#include 
> > +#include 
> > +#include 
> > +#include 
>
> > +#include 
>
> Can you elaborate on this?
>
> > +#include 
> > +#include 
>
> Missed mod_devicetable.h.
>
> ...
>
> > +   brightness_val[0] = (brightness - 1) & MT6370_BL_DIM2_MASK;
> > +   brightness_val[1] = (brightness - 1)
> > +   >> fls(MT6370_BL_DIM2_MASK);
>
> Bad indentation. One line?

Well... if indent to one line, it will be over 80 characters(or called columns?)
>From my understanding, it is not allowed, right??

>
> ...
>
> > +   if (priv->enable_gpio)
>
> Dup check.
>
> > +   gpiod_set_value(priv->enable_gpio, brightness ? 1 : 0);
>
> ...
>
> > +   brightness = brightness_val[1] << fls(MT6370_BL_DIM2_MASK);
> > +   brightness += (brightness_val[0] & MT6370_BL_DIM2_MASK);
>
> Too many parentheses.
>
> ...
>
> > +   /*
> > +* prop_val =  1  -->  1 steps --> 0x00
> > +* prop_val =  2 ~  4 -->  4 steps --> 0x01
> > +* prop_val =  5 ~ 16 --> 16 steps --> 0x10
> > +* prop_val = 17 ~ 64 --> 64 steps --> 0x11
> > +*/
> > +   prop_val = (ilog2(roundup_pow_of_two(prop_val)) + 1) >> 1;
>
> Isn't something closer to get_order() or fls()?

I will revise it to "(get_order(prop_va * PAGE_SIZE) + 1) / 2" and
this change is meet your expectations??

>
> ...
>
> > +   props->max_brightness = min_t(u32, brightness,
> > + MT6370_BL_MAX_BRIGHTNESS);
>
> One line?

 Ditto, it will be over 80 characters...

>
> ...
>
> > +   val = 0;
>
> Do you need this here?
>
> > +   prop_val = 0;
>
> Useless.
>
> > +   ret = device_property_read_u8(dev, "mediatek,bled-channel-use",
> > + &prop_val);
> > +   if (ret) {
> > +   dev_err(dev, "mediatek,bled-channel-use DT property 
> > missing\n");
> > +   return ret;
> > +   }
> > +
> > +   if (!prop_val || prop_val > MT6370_BL_MAX_CH) {
> > +   dev_err(dev,
> > +   "No channel specified or over than upper bound 
> > (%d)\n",
> > +   prop_val);
> > +   return -EINVAL;
> > +   }
>
> ...
>
> > +static int mt6370_bl_probe(struct platform_device *pdev)
> > +{
> > +   struct mt6370_priv *priv;
> > +   struct backlight_properties props = {
> > +   .type = BACKLIGHT_RAW,
> > +   .scale = BACKLIGHT_SCALE_LINEAR,
> > +   };
> > +   int ret;
>
>   struct device *dev = &pdev->dev;
>
> will save you a few LoCs.
>
> --
> With Best Regards,
> Andy Shevchenko

Best regards,
ChiaEn Wu


Re: [PATCH 1/3] drm/i915: audit bo->resource usage

2022-07-13 Thread Matthew Auld
On Tue, 12 Jul 2022 at 12:46, Christian König
 wrote:
>
> Make sure we can at least move and alloc TT objects without backing store.
>
> Signed-off-by: Christian König 
> ---
>  drivers/gpu/drm/i915/gem/i915_gem_ttm.c  | 6 ++
>  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c | 2 +-
>  2 files changed, 3 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> index 70e2ed4e99df..5449738c262f 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
> @@ -289,8 +289,6 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
> ttm_buffer_object *bo,
>  {
> struct drm_i915_private *i915 = container_of(bo->bdev, typeof(*i915),
>  bdev);
> -   struct ttm_resource_manager *man =
> -   ttm_manager_type(bo->bdev, bo->resource->mem_type);
> struct drm_i915_gem_object *obj = i915_ttm_to_gem(bo);
> unsigned long ccs_pages = 0;
> enum ttm_caching caching;
> @@ -304,8 +302,8 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
> ttm_buffer_object *bo,
> if (!i915_tt)
> return NULL;
>
> -   if (obj->flags & I915_BO_ALLOC_CPU_CLEAR &&
> -   man->use_tt)
> +   if (obj->flags & I915_BO_ALLOC_CPU_CLEAR && bo->resource &&
> +   ttm_manager_type(bo->bdev, bo->resource->mem_type)->use_tt)
> page_flags |= TTM_TT_FLAG_ZERO_ALLOC;

AFAICT it should be safe to make this:

if (obj->flags & I915_BO_ALLOC_CPU_CLEAR)
page_flags |= TTM_TT_FLAG_ZERO_ALLOC;

Hopefully that fixes the igt_lmem_create_cleared_cpu subtest?

>
> caching = i915_ttm_select_tt_caching(obj);
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c 
> b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> index a10716f4e717..dcb838dffd7b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c
> @@ -490,7 +490,7 @@ int i915_ttm_move(struct ttm_buffer_object *bo, bool 
> evict,
> bool clear;
> int ret;
>
> -   if (GEM_WARN_ON(!obj)) {
> +   if (!bo->resource || GEM_WARN_ON(!obj)) {

IIUC in patch 3 we now nuke the bo->resource when doing the "pipeline
gutting" thing, but I think i915 is (ab)using that when swapping out
shmem objects (see i915_ttm_shrink), so I think here we need to
somehow inspect the tt to see if something needs to be swapped in? We
might also need to move it back to lmem after. Or maybe this is
already handled somehow? CI should hopefully be able to confirm
(gem_lmem_swapping).

> ttm_bo_move_null(bo, dst_mem);
> return 0;
> }
> --
> 2.25.1
>


Re: [PATCH 4/5] drm/modes: Add support for driver-specific named modes

2022-07-13 Thread Maxime Ripard
Hi Geert,

On Mon, Jul 11, 2022 at 02:08:06PM +0200, Geert Uytterhoeven wrote:
> On Mon, Jul 11, 2022 at 2:02 PM Maxime Ripard  wrote:
> > On Mon, Jul 11, 2022 at 01:59:28PM +0200, Geert Uytterhoeven wrote:
> > > On Mon, Jul 11, 2022 at 1:42 PM Maxime Ripard  wrote:
> > > > On Mon, Jul 11, 2022 at 01:11:14PM +0200, Thomas Zimmermann wrote:
> > > > > Am 11.07.22 um 11:35 schrieb Maxime Ripard:
> > > > > > On Mon, Jul 11, 2022 at 11:03:38AM +0200, Thomas Zimmermann wrote:
> > > > > > > Am 08.07.22 um 20:21 schrieb Geert Uytterhoeven:
> > > > > > > > The mode parsing code recognizes named modes only if they are 
> > > > > > > > explicitly
> > > > > > > > listed in the internal whitelist, which is currently limited to 
> > > > > > > > "NTSC"
> > > > > > > > and "PAL".
> > > > > > > >
> > > > > > > > Provide a mechanism for drivers to override this list to 
> > > > > > > > support custom
> > > > > > > > mode names.
> > > > > > > >
> > > > > > > > Ideally, this list should just come from the driver's actual 
> > > > > > > > list of
> > > > > > > > modes, but connector->probed_modes is not yet populated at the 
> > > > > > > > time of
> > > > > > > > parsing.
> > > > > > >
> > > > > > > I've looked for code that uses these names, couldn't find any. 
> > > > > > > How is this
> > > > > > > being used in practice? For example, if I say "PAL" on the 
> > > > > > > command line, is
> > > > > > > there DRM code that fills in the PAL mode parameters?
> > > > > >
> > > > > > We have some code to deal with this in sun4i:
> > > > > > https://elixir.bootlin.com/linux/latest/source/drivers/gpu/drm/sun4i/sun4i_tv.c#L292
> > > > > >
> > > > > > It's a bit off topic, but for TV standards, I'm still not sure what 
> > > > > > the
> > > > > > best course of action is. There's several interactions that make 
> > > > > > this a
> > > > > > bit troublesome:
> > > > > >
> > > > > >* Some TV standards differ by their mode (ie, PAL vs NSTC), but 
> > > > > > some
> > > > > >  other differ by parameters that are not part of 
> > > > > > drm_display_mode
> > > > > >  (NTSC vs NSTC-J where the only difference is the black and 
> > > > > > blanking
> > > > > >  signal levels for example).
> > > > > >
> > > > > >* The mode names allow to provide a fairly convenient way to add 
> > > > > > that
> > > > > >  extra information, but the userspace is free to create its own 
> > > > > > mode
> > > > > >  and might omit the mode name entirely.
> > > > > >
> > > > > > So in the code above, if the name has been preserved we match by 
> > > > > > name,
> > > > > > but we fall back to matching by mode if it hasn't been, which in 
> > > > > > this
> > > > > > case means that we have no way to differentiate between NTSC, 
> > > > > > NTSC-J,
> > > > > > PAL-M in this case.
> > > > > >
> > > > > > We have some patches downstream for the RaspberryPi that has the TV
> > > > > > standard as a property. There's a few extra logic required for the
> > > > > > userspace (like setting the PAL property, with the NTSC mode) so 
> > > > > > I'm not
> > > > > > sure it's preferable.
> > > > > >
> > > > > > Or we could do something like a property to try that standard, and
> > > > > > another that reports the one we actually chose.
> > > > > >
> > > > > > > And another question I have is whether this whitelist belongs 
> > > > > > > into the
> > > > > > > driver at all. Standard modes exist independent from drivers or 
> > > > > > > hardware.
> > > > > > > Shouldn't there simply be a global list of all possible mode 
> > > > > > > names? Drivers
> > > > > > > would filter out the unsupported modes anyway.
> > > > > >
> > > > > > We should totally do something like that, yeah
> > > > >
> > > > > That sun code already looks like sometihng the DRM core/helpers 
> > > > > should be
> > > > > doing. And if we want to support named modes well, there's a long 
> > > > > list of
> > > > > modes in Wikipedia.
> > > > >
> > > > > https://en.wikipedia.org/wiki/Video_Graphics_Array#/media/File:Vector_Video_Standards2.svg
> > > >
> > > > Yeah, and NTSC is missing :)
> > >
> > > And that diagram is about the "digital" variant of PAL.
> > > If you go the analog route, the only fixed parts are vfreq/hfreq,
> > > number of lines, and synchronization. Other parameters like overscan
> > > can vary.  The actual dot clock can vary wildly: while there is an
> > > upper limit due to bandwidth limitations, you can come up with an
> > > almost infinite number of video modes that can be called PAL, which
> > > is one of the reasons why I don't want hardware-specific variants to
> > > end up in a global video mode database.
> >
> > Do you have an example of what that would look like?
> 
> You mean a PAL mode that does not use 768x576?

I meant what the almost infinite number of video modes that can be
called PAL and would have to be defined in drivers

> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/video/fbdev/amifb.c#n834

But th

Re: [PATCH v3 07/14] mfd: mt6370: Add Mediatek MT6370 support

2022-07-13 Thread ChiaEn Wu
Hi Lee,

Lee Jones  於 2022年7月13日 週三 下午4:04寫道:
>
> On Wed, 13 Jul 2022, ChiaEn Wu wrote:
>
> > Hi Lee,
> >
> > Thanks for your reply.
> >
> > Lee Jones  於 2022年7月12日 週二 晚上11:29寫道:
> > >
> > > On Thu, 23 Jun 2022, ChiaEn Wu wrote:
> > >
> > > > From: ChiYuan Huang 
> > > >
> > > > Add Mediatek MT6370 MFD support.
> > >
> > > No such thing as "MFD support".
> > >
> > > And you're not getting away with submitting a 370 line patch with a 5
> > > word change log either. :)
> > >
> > > Please at least tell us what the device is and what it's used for.
> >
> > I sincerely apologize.
> > We will add more descriptions of the MT6370 feature in the v5 patch.
> >
> > >
> > > > Signed-off-by: ChiYuan Huang 
> > > > ---
> > > >
> > > > v3
> > > > - Refine Kconfig help text
> > > > - Refine error message of unknown vendor ID in
> > > >   mt6370_check_vendor_info()
> > > > - Refine return value handling of mt6370_regmap_read()
> > > > - Refine all probe error by using dev_err_probe()
> > > > - Refine "bank_idx" and "bank_addr" in mt6370_regmap_read() and
> > > >   mt6370_regmap_write()
> > > > - Add "#define VENID*" and drop the comments in
> > > >   mt6370_check_vendor_info()
> > > > - Drop "MFD" in MODULE_DESCRIPTION()
> > > > ---
> > > >  drivers/mfd/Kconfig  |  13 ++
> > > >  drivers/mfd/Makefile |   1 +
> > > >  drivers/mfd/mt6370.c | 358 
> > > > +++
> > > >  3 files changed, 372 insertions(+)
> > > >  create mode 100644 drivers/mfd/mt6370.c
>
> [...]
>
> > > > +static const struct mfd_cell mt6370_devices[] = {
> > > > + MFD_CELL_OF("adc", NULL, NULL, 0, 0, "mediatek,mt6370-adc"),
> > > > + MFD_CELL_OF("charger", NULL, NULL, 0, 0, 
> > > > "mediatek,mt6370-charger"),
> > > > + MFD_CELL_OF("backlight", NULL, NULL, 0, 0, 
> > > > "mediatek,mt6370-backlight"),
> > > > + MFD_CELL_OF("flashlight", NULL, NULL, 0, 0, 
> > > > "mediatek,mt6370-flashlight"),
> > > > + MFD_CELL_OF("indicator", NULL, NULL, 0, 0, 
> > > > "mediatek,mt6370-indicator"),
> > > > + MFD_CELL_OF("tcpc", NULL, NULL, 0, 0, "mediatek,mt6370-tcpc"),
> > > > + MFD_CELL_RES("regulator", mt6370_regulator_irqs)
> > >
> > > The first parameters here should be prepended with something, perhaps
> > > "mt6370_"?
>
> > OK, we will add the prefix in the next patch.

Sorry, I forgot to ask a question in the last mail.
I wonder if using "mt6370-xxx" (dash) is better than using "mt6370_"
(underline) ??
Thanks.

> [...]
>
> > > > +static int mt6370_probe(struct i2c_client *i2c)
> > > > +{
> > > > + struct mt6370_info *info;
> > > > + struct i2c_client *usbc_i2c;
> > > > + int ret;
> > > > +
> > > > + info = devm_kzalloc(&i2c->dev, sizeof(*info), GFP_KERNEL);
> > > > + if (!info)
> > > > + return -ENOMEM;
> > > > +
> > > > + info->dev = &i2c->dev;
> > > > +
> > > > + usbc_i2c = devm_i2c_new_dummy_device(&i2c->dev, i2c->adapter,
> > > > +  MT6370_USBC_I2CADDR);
> > > > + if (IS_ERR(usbc_i2c))
> > > > + return dev_err_probe(&i2c->dev, PTR_ERR(usbc_i2c),
> > > > +  "Failed to register USBC I2C 
> > > > client\n");
> > > > +
> > > > + /* Assign I2C client for PMU and TypeC */
> > > > + info->i2c[MT6370_PMU_I2C] = i2c;
> > > > + info->i2c[MT6370_USBC_I2C] = usbc_i2c;
> > > > +
> > > > + info->regmap = devm_regmap_init(&i2c->dev, &mt6370_regmap_bus, 
> > > > info,
> > > > + &mt6370_regmap_config);
> > >
> > > Apart from in mt6370_check_vendor_info() where is this actually used?
> >
> > Well... from my understanding, we use this MFD driver to make other
> > drivers of MT6370 (e.g. charger, ADC, led...) use the same regmap
> > settings.
> > Thus, this regmap is not only used in mt6370_check_vendor_info().
>
> Well for that to happen you need to store the data somewhere for the
> child devices to fetch from.  I don't see that happening in this
> patch?  What did I miss?

hmmm... I got your point... I will let regmap be a local var in
probe() in the next patch.
Thank you so much!

>
> --
> Lee Jones [李琼斯]
> Principal Technical Lead - Developer Services
> Linaro.org │ Open source software for Arm SoCs
> Follow Linaro: Facebook | Twitter | Blog

Best regards,
ChiaEn Wu


[PATCH 19/21] drm/i915/gt: document TLB cache invalidation functions

2022-07-13 Thread Mauro Carvalho Chehab
Add a description for the kAPI functions inside intel_tlb.c.

Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/intel_tlb.c | 36 +
 1 file changed, 36 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index 15ed83226676..aa2e0086ae88 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -146,6 +146,18 @@ static void mmio_invalidate_full(struct intel_gt *gt)
intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
 }
 
+/**
+ * intel_gt_invalidate_tlb_full - do full TLB cache invalidation
+ * @gt: GT structure
+ * @seqno: sequence number
+ *
+ * Do a full TLB cache invalidation if the @seqno is bigger than the last
+ * full TLB cache invalidation.
+ *
+ * Note:
+ * The TLB cache invalidation logic depends on GEN-specific registers.
+ * It currently supports GEN8 to GEN12 and GuC-based TLB cache invalidation.
+ */
 void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 seqno)
 {
intel_wakeref_t wakeref;
@@ -220,6 +232,17 @@ static bool mmio_invalidate_range(struct intel_gt *gt, u64 
start, u64 length)
return err == 0;
 }
 
+/**
+ * intel_gt_invalidate_tlb_range - do full TLB cache invalidation
+ * @gt: GT structure
+ * @start: range start
+ * @length: range length
+ *
+ * Do a selected TLB cache invalidation on a range pointed by @start
+ * with @length size.
+ *
+ * Only some GuC-based GPUs can do a selective cache invalidation.
+ */
 bool intel_gt_invalidate_tlb_range(struct intel_gt *gt,
   u64 start, u64 length)
 {
@@ -247,12 +270,25 @@ bool intel_gt_invalidate_tlb_range(struct intel_gt *gt,
return true;
 }
 
+/**
+ * intel_gt_init_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * TLB cache invalidation logic internally uses some resources that require
+ * initialization. Should be called before doing any TLB cache invalidation.
+ */
 void intel_gt_init_tlb(struct intel_gt *gt)
 {
mutex_init(>->tlb.invalidate_lock);
seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
 }
 
+/**
+ * intel_gt_fini_tlb - initialize TLB-specific vars
+ * @gt: GT structure
+ *
+ * Frees any resources needed by TLB cache invalidation logic.
+ */
 void intel_gt_fini_tlb(struct intel_gt *gt)
 {
mutex_destroy(>->tlb.invalidate_lock);
-- 
2.36.1



[PATCH 13/21] drm/i915: Invalidate the TLBs on each GT

2022-07-13 Thread Mauro Carvalho Chehab
From: Chris Wilson 

With multi-GT devices, the object may have been bound on each GT.
Invalidate the TLBs across all GT before releasing the pages
back to the system.

Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/i915_gem_object_types.h |  4 +++-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c| 13 -
 drivers/gpu/drm/i915/gt/intel_engine.h   |  1 +
 drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h   |  3 ++-
 drivers/gpu/drm/i915/gt/intel_gt_defines.h   | 11 +++
 drivers/gpu/drm/i915/gt/intel_gt_types.h |  4 +++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c|  4 ++--
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/i915_vma.c  | 14 +++---
 drivers/gpu/drm/i915/i915_vma.h  |  2 +-
 10 files changed, 42 insertions(+), 15 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_defines.h

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 9f6b14ec189a..3c1d0b750a67 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -17,6 +17,8 @@
 #include "i915_selftest.h"
 #include "i915_vma_resource.h"
 
+#include "gt/intel_gt_defines.h"
+
 struct drm_i915_gem_object;
 struct intel_fronbuffer;
 struct intel_memory_region;
@@ -616,7 +618,7 @@ struct drm_i915_gem_object {
 */
bool dirty:1;
 
-   u32 tlb;
+   u32 tlb[I915_MAX_GT];
} mm;
 
struct {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 1cd76cc5d9f3..4a6a2f2e8148 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -194,13 +194,16 @@ static void unmap_object(struct drm_i915_gem_object *obj, 
void *ptr)
 static void flush_tlb_invalidate(struct drm_i915_gem_object *obj)
 {
struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct intel_gt *gt = to_gt(i915);
+   struct intel_gt *gt;
+   int id;
 
-   if (!obj->mm.tlb)
-   return;
+   for_each_gt(gt, i915, id) {
+   if (!obj->mm.tlb[id])
+   continue;
 
-   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
-   obj->mm.tlb = 0;
+   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb[id]);
+   obj->mm.tlb[id] = 0;
+   }
 }
 
 struct sg_table *
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index 04e435bce79b..fe1dc55bf8f7 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -18,6 +18,7 @@
 #include "intel_gt_types.h"
 #include "intel_timeline.h"
 #include "intel_workarounds.h"
+#include "uc/intel_guc_submission.h"
 
 struct drm_printer;
 struct intel_context;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h 
b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
index 487b8a5520f1..8d41cf0c937a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_buffer_pool.h
@@ -11,8 +11,9 @@
 #include "i915_active.h"
 #include "intel_gt_buffer_pool_types.h"
 
-struct intel_gt;
+enum i915_map_type;
 struct i915_request;
+struct intel_gt;
 
 struct intel_gt_buffer_pool_node *
 intel_gt_get_buffer_pool(struct intel_gt *gt, size_t size,
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_defines.h 
b/drivers/gpu/drm/i915/gt/intel_gt_defines.h
new file mode 100644
index ..7c711726d663
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_gt_defines.h
@@ -0,0 +1,11 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2019 Intel Corporation
+ */
+
+#ifndef __INTEL_GT_DEFINES__
+#define __INTEL_GT_DEFINES__
+
+#define I915_MAX_GT 4
+
+#endif
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h 
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 3804a583382b..b857c3972251 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -19,7 +19,6 @@
 #include "uc/intel_uc.h"
 #include "intel_gsc.h"
 
-#include "i915_vma.h"
 #include "intel_engine_types.h"
 #include "intel_gt_buffer_pool_types.h"
 #include "intel_hwconfig.h"
@@ -31,8 +30,11 @@
 #include "intel_wakeref.h"
 #include "pxp/intel_pxp_types.h"
 
+#include "intel_gt_defines.h"
+
 struct drm_i915_private;
 struct i915_ggtt;
+struct i915_vma;
 struct intel_engine_cs;
 struct intel_uncore;
 
diff --git a/drivers/gpu/drm/i915/gt/intel_ppgtt.c 
b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
index 2da6c82a8bd2..f764d250e929 100644
--- a/drivers/gpu/drm/i915/gt/intel_ppgtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ppgtt.c
@@ -8,6 +8,7 @@
 #include "gem/i915_gem_lmem.h"
 
 #include "i915_trace.h"
+#include "intel_gt.h"

[PATCH 06/21] drm/i915/gt: Batch TLB invalidations

2022-07-13 Thread Mauro Carvalho Chehab
From: Chris Wilson 

Invalidate TLB in patch, in order to reduce performance regressions.

Currently, every caller performs a full barrier around a TLB
invalidation, ignoring all other invalidations that may have already
removed their PTEs from the cache. As this is a synchronous operation
and can be quite slow, we cause multiple threads to contend on the TLB
invalidate mutex blocking userspace.

We only need to invalidate the TLB once after replacing our PTE to
ensure that there is no possible continued access to the physical
address before releasing our pages. By tracking a seqno for each full
TLB invalidate we can quickly determine if one has been performed since
rewriting the PTE, and only if necessary trigger one for ourselves.

That helps to reduce the performance regression introduced by TLB
invalidate logic.

[mchehab: rebased to not require moving the code to a separate file]

Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Suggested-by: Tvrtko Ursulin 
Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 .../gpu/drm/i915/gem/i915_gem_object_types.h  |  3 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c | 21 +---
 drivers/gpu/drm/i915/gt/intel_gt.c| 53 ++-
 drivers/gpu/drm/i915/gt/intel_gt.h| 12 -
 drivers/gpu/drm/i915/gt/intel_gt_types.h  | 18 ++-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |  8 ++-
 drivers/gpu/drm/i915/i915_vma.c   | 34 +---
 drivers/gpu/drm/i915/i915_vma.h   |  1 +
 drivers/gpu/drm/i915/i915_vma_resource.c  |  5 +-
 drivers/gpu/drm/i915/i915_vma_resource.h  |  6 ++-
 10 files changed, 125 insertions(+), 36 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 5cf36a130061..9f6b14ec189a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -335,7 +335,6 @@ struct drm_i915_gem_object {
 #define I915_BO_READONLY  BIT(7)
 #define I915_TILING_QUIRK_BIT 8 /* unknown swizzling; do not release! */
 #define I915_BO_PROTECTED BIT(9)
-#define I915_BO_WAS_BOUND_BIT 10
/**
 * @mem_flags - Mutable placement-related flags
 *
@@ -616,6 +615,8 @@ struct drm_i915_gem_object {
 * pages were last acquired.
 */
bool dirty:1;
+
+   u32 tlb;
} mm;
 
struct {
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 6835279943df..8357dbdcab5c 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -191,6 +191,18 @@ static void unmap_object(struct drm_i915_gem_object *obj, 
void *ptr)
vunmap(ptr);
 }
 
+static void flush_tlb_invalidate(struct drm_i915_gem_object *obj)
+{
+   struct drm_i915_private *i915 = to_i915(obj->base.dev);
+   struct intel_gt *gt = to_gt(i915);
+
+   if (!obj->mm.tlb)
+   return;
+
+   intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+   obj->mm.tlb = 0;
+}
+
 struct sg_table *
 __i915_gem_object_unset_pages(struct drm_i915_gem_object *obj)
 {
@@ -216,14 +228,7 @@ __i915_gem_object_unset_pages(struct drm_i915_gem_object 
*obj)
__i915_gem_object_reset_page_iter(obj);
obj->mm.page_sizes.phys = obj->mm.page_sizes.sg = 0;
 
-   if (test_and_clear_bit(I915_BO_WAS_BOUND_BIT, &obj->flags)) {
-   struct drm_i915_private *i915 = to_i915(obj->base.dev);
-   struct intel_gt *gt = to_gt(i915);
-   intel_wakeref_t wakeref;
-
-   with_intel_gt_pm_if_awake(gt, wakeref)
-   intel_gt_invalidate_tlbs(gt);
-   }
+   flush_tlb_invalidate(obj);
 
return pages;
 }
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index 5c55a90672f4..f435e06125aa 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -38,8 +38,6 @@ static void __intel_gt_init_early(struct intel_gt *gt)
 {
spin_lock_init(>->irq_lock);
 
-   mutex_init(>->tlb_invalidate_lock);
-
INIT_LIST_HEAD(>->closed_vma);
spin_lock_init(>->closed_lock);
 
@@ -50,6 +48,8 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
+   mutex_init(>->tlb.invalidate_lock);
+   seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
intel_gt_pm_init_early(gt);
 
intel_uc_init_early(>->uc);
@@ -770,6 +770,7 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_f

[PATCH 09/21] drm/i915/guc: Define CTB based TLB invalidation routines

2022-07-13 Thread Mauro Carvalho Chehab
From: Prathap Kumar Valsan 

Add routines to interface with GuC firmware for TLB invalidation.

Signed-off-by: Prathap Kumar Valsan 
Cc: Bruce Chang 
Cc: Michal Wajdeczko 
Cc: Matthew Brost 
Cc: Chris Wilson 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  | 35 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 90 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 13 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 24 -
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  6 ++
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 91 ++-
 6 files changed, 253 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 4ef9990ed7f8..2e39d8df4c82 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -134,6 +134,10 @@ enum intel_guc_action {
INTEL_GUC_ACTION_REGISTER_CONTEXT_MULTI_LRC = 0x4601,
INTEL_GUC_ACTION_CLIENT_SOFT_RESET = 0x5507,
INTEL_GUC_ACTION_SET_ENG_UTIL_BUFF = 0x550A,
+   INTEL_GUC_ACTION_NOTIFY_MEMORY_CAT_ERROR = 0x6000,
+   INTEL_GUC_ACTION_PAGE_FAULT_NOTIFICATION = 0x6001,
+   INTEL_GUC_ACTION_TLB_INVALIDATION = 0x7000,
+   INTEL_GUC_ACTION_TLB_INVALIDATION_DONE = 0x7001,
INTEL_GUC_ACTION_STATE_CAPTURE_NOTIFICATION = 0x8002,
INTEL_GUC_ACTION_NOTIFY_FLUSH_LOG_BUFFER_TO_FILE = 0x8003,
INTEL_GUC_ACTION_NOTIFY_CRASH_DUMP_POSTED = 0x8004,
@@ -177,4 +181,35 @@ enum intel_guc_state_capture_event_status {
 
 #define INTEL_GUC_STATE_CAPTURE_EVENT_STATUS_MASK  0x00FF
 
+#define INTEL_GUC_TLB_INVAL_TYPE_SHIFT 0
+#define INTEL_GUC_TLB_INVAL_MODE_SHIFT 8
+/* Flush PPC or SMRO caches along with TLB invalidation request */
+#define INTEL_GUC_TLB_INVAL_FLUSH_CACHE (1 << 31)
+
+enum intel_guc_tlb_invalidation_type {
+   INTEL_GUC_TLB_INVAL_GUC = 0x3,
+};
+
+/*
+ * 0: Heavy mode of Invalidation:
+ * The pipeline of the engine(s) for which the invalidation is targeted to is
+ * blocked, and all the in-flight transactions are guaranteed to be Globally
+ * Observed before completing the TLB invalidation
+ * 1: Lite mode of Invalidation:
+ * TLBs of the targeted engine(s) are immediately invalidated.
+ * In-flight transactions are NOT guaranteed to be Globally Observed before
+ * completing TLB invalidation.
+ * Light Invalidation Mode is to be used only when
+ * it can be guaranteed (by SW) that the address translations remain invariant
+ * for the in-flight transactions across the TLB invalidation. In other words,
+ * this mode can be used when the TLB invalidation is intended to clear out the
+ * stale cached translations that are no longer in use. Light Invalidation Mode
+ * is much faster than the Heavy Invalidation Mode, as it does not wait for the
+ * in-flight transactions to be GOd.
+ */
+enum intel_guc_tlb_inval_mode {
+   INTEL_GUC_TLB_INVAL_MODE_HEAVY = 0x0,
+   INTEL_GUC_TLB_INVAL_MODE_LITE = 0x1,
+};
+
 #endif /* _ABI_GUC_ACTIONS_ABI_H */
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 2706a8c65090..5c59f9b144a3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -855,6 +855,96 @@ int intel_guc_self_cfg64(struct intel_guc *guc, u16 key, 
u64 value)
return __guc_self_cfg(guc, key, 2, value);
 }
 
+static int guc_send_invalidate_tlb(struct intel_guc *guc, u32 *action, u32 
size)
+{
+   struct intel_guc_tlb_wait _wq, *wq = &_wq;
+   DEFINE_WAIT_FUNC(wait, woken_wake_function);
+   int err = 0;
+   u32 seqno;
+
+   init_waitqueue_head(&_wq.wq);
+
+   if (xa_alloc_cyclic_irq(&guc->tlb_lookup, &seqno, wq,
+   xa_limit_32b, &guc->next_seqno,
+   GFP_ATOMIC | __GFP_NOWARN) < 0) {
+   /* Under severe memory pressure? Serialise TLB allocations */
+   xa_lock_irq(&guc->tlb_lookup);
+   wq = xa_load(&guc->tlb_lookup, guc->serial_slot);
+   wait_event_lock_irq(wq->wq,
+   !READ_ONCE(wq->status),
+   guc->tlb_lookup.xa_lock);
+   /*
+* Update wq->status under lock to ensure only one waiter can
+* issue the tlb invalidation command using the serial slot at a
+* time. The condition is set to false before releasing the lock
+* so that other caller continue to wait until woken up again.
+*/
+   wq->status = 1;
+   xa_unlock_irq(&guc->tlb_lookup);
+
+   seqno = guc->serial_slot;
+   }
+
+   action[1] = seqno;
+
+   add_wait_queue(&wq->wq, &wait);
+
+   err = intel_guc_send_bus

[PATCH 21/21] drm/i915/guc: document TLB cache invalidation functions

2022-07-13 Thread Mauro Carvalho Chehab
Add documentation for the kAPI functions that do TLB cache
invalidation via GuC.

Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/uc/intel_guc.c | 52 ++
 1 file changed, 45 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 98260a7bc90b..173833bc3a62 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -923,7 +923,14 @@ static int guc_send_invalidate_tlb(struct intel_guc *guc, 
u32 *action, u32 size)
return err;
 }
 
- /* Full TLB invalidation */
+/**
+ * intel_guc_invalidate_tlb_full - GuC full TLB invalidation
+ *
+ * @guc: the guc
+ * @mode: mode of TLB cache invalidation (heavy or lite)
+ *
+ * Use GuC to do a full TLB cache invalidation if supported.
+ */
 int intel_guc_invalidate_tlb_full(struct intel_guc *guc,
  enum intel_guc_tlb_inval_mode mode)
 {
@@ -943,8 +950,17 @@ int intel_guc_invalidate_tlb_full(struct intel_guc *guc,
return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
 }
 
-/*
- * Selective TLB Invalidation for Address Range:
+/**
+ * intel_guc_invalidate_tlb_page_selective - GuC selective TLB invalidation
+ * for an address range
+ *
+ * @guc: the guc
+ * @mode: mode of TLB cache invalidation (heavy or lite)
+ * @start: range start
+ * @length: range length
+ *
+ * Use GuC to do a selective TLB invalidation if supported.
+ *
  * TLB's in the Address Range is Invalidated across all engines.
  */
 int intel_guc_invalidate_tlb_page_selective(struct intel_guc *guc,
@@ -978,8 +994,18 @@ int intel_guc_invalidate_tlb_page_selective(struct 
intel_guc *guc,
return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
 }
 
-/*
- * Selective TLB Invalidation for Context:
+/**
+ * intel_guc_invalidate_tlb_page_selective_ctx - GuC selective TLB
+ * invalidation for a context
+ *
+ * @guc: the guc
+ * @mode: mode of TLB cache invalidation (heavy or lite)
+ * @start: range start
+ * @length: range length
+ * @ctxid: context ID
+ *
+ * Use GuC to do a selective TLB invalidation on a context if supported.
+ *
  * Invalidates all TLB's for a specific context across all engines.
  */
 int intel_guc_invalidate_tlb_page_selective_ctx(struct intel_guc *guc,
@@ -1013,8 +1039,13 @@ int intel_guc_invalidate_tlb_page_selective_ctx(struct 
intel_guc *guc,
return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
 }
 
-/*
- * Guc TLB Invalidation: Invalidate the TLB's of GuC itself.
+/**
+ * intel_guc_invalidate_tlb_guc - GuC self TLB invalidation
+ *
+ * @guc: the guc
+ * @mode: mode of TLB cache invalidation (heavy or lite)
+ *
+ * Use GuC to invalidate the TLB's of GuC itself.
  */
 int intel_guc_invalidate_tlb_guc(struct intel_guc *guc,
 enum intel_guc_tlb_inval_mode mode)
@@ -1035,6 +1066,13 @@ int intel_guc_invalidate_tlb_guc(struct intel_guc *guc,
return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
 }
 
+/**
+ * intel_guc_invalidate_tlb_all - GuC global TLB invalidation
+ *
+ * @guc: the guc
+ *
+ * Use GuC to do a complete TLB invalidation on all tables
+ */
 int intel_guc_invalidate_tlb_all(struct intel_guc *guc)
 {
u32 action[] = {
-- 
2.36.1



[PATCH 00/21] Fix performance regressions with TLB and add GuC support

2022-07-13 Thread Mauro Carvalho Chehab
TLB invalidation is a slow operation. It should not be doing lightly, as it
causes performance regressions, like this:

[178.821002] i915 :00:02.0: [drm] *ERROR* rcs0 TLB invalidation did not 
complete in 4ms!

This series contain 

1) some patches that makes TLB invalidation to happen only on
active, non-wedged engines, doing cache invalidation in batch 
and only when GT objects are exposed to userspace:

  drm/i915/gt: Ignore TLB invalidations on idle engines
  drm/i915/gt: Only invalidate TLBs exposed to user manipulation
  drm/i915/gt: Skip TLB invalidations once wedged
  drm/i915/gt: Batch TLB invalidations
  drm/i915/gt: Move TLB invalidation to its own file

2) It fixes two bugs, being the first a workaround:

  drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
  drm/i915: Invalidate the TLBs on each GT

  drm/i915/guc: Introduce TLB_INVALIDATION_ALL action

3) It adds GuC support. Besides providing TLB invalidation on some
additional hardware, this should also help serializing GuC operations
with TLB invalidation:

  drm/i915/guc: Introduce TLB_INVALIDATION_ALL action
  drm/i915/guc: Define CTB based TLB invalidation routines
  drm/i915: Add platform macro for selective tlb flush
  drm/i915: Define GuC Based TLB invalidation routines
  drm/i915: Add generic interface for tlb invalidation for XeHP
  drm/i915: Use selective tlb invalidations where supported

4) It adds the corresponding kernel-doc markups for the kAPI
used for TLB invalidation.

While I could have split this into smaller pieces, I'm opting to send
them altogether, in order for CI trybot to better verify what issues
will be closed with this series.

---

Chris Wilson (7):
  drm/i915/gt: Ignore TLB invalidations on idle engines
  drm/i915/gt: Invalidate TLB of the OA unit at TLB invalidations
  drm/i915/gt: Only invalidate TLBs exposed to user manipulation
  drm/i915/gt: Skip TLB invalidations once wedged
  drm/i915/gt: Batch TLB invalidations
  drm/i915/gt: Move TLB invalidation to its own file
  drm/i915: Invalidate the TLBs on each GT

Mauro Carvalho Chehab (8):
  drm/i915/gt: document with_intel_gt_pm_if_awake()
  drm/i915/gt: describe the new tlb parameter at i915_vma_resource
  drm/i915/guc: use kernel-doc for enum intel_guc_tlb_inval_mode
  drm/i915/guc: document the TLB invalidation struct members
  drm/i915: document tlb field at struct drm_i915_gem_object
  drm/i915/gt: document TLB cache invalidation functions
  drm/i915/guc: describe enum intel_guc_tlb_invalidation_type
  drm/i915/guc: document TLB cache invalidation functions

Piotr Piórkowski (1):
  drm/i915/guc: Introduce TLB_INVALIDATION_ALL action

Prathap Kumar Valsan (5):
  drm/i915/guc: Define CTB based TLB invalidation routines
  drm/i915: Add platform macro for selective tlb flush
  drm/i915: Define GuC Based TLB invalidation routines
  drm/i915: Add generic interface for tlb invalidation for XeHP
  drm/i915: Use selective tlb invalidations where supported

 drivers/gpu/drm/i915/Makefile |   1 +
 .../gpu/drm/i915/gem/i915_gem_object_types.h  |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |  28 +-
 drivers/gpu/drm/i915/gt/intel_engine.h|   1 +
 drivers/gpu/drm/i915/gt/intel_gt.c| 125 +---
 drivers/gpu/drm/i915/gt/intel_gt.h|   2 -
 .../gpu/drm/i915/gt/intel_gt_buffer_pool.h|   3 +-
 drivers/gpu/drm/i915/gt/intel_gt_defines.h|  11 +
 drivers/gpu/drm/i915/gt/intel_gt_pm.h |  10 +
 drivers/gpu/drm/i915/gt/intel_gt_regs.h   |   8 +
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  22 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   8 +-
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 295 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   |  30 ++
 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  54 
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 232 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h|  36 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c |  24 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |   9 +
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  91 +-
 drivers/gpu/drm/i915/i915_drv.h   |   4 +-
 drivers/gpu/drm/i915/i915_pci.c   |   1 +
 drivers/gpu/drm/i915/i915_vma.c   |  46 ++-
 drivers/gpu/drm/i915/i915_vma.h   |   2 +
 drivers/gpu/drm/i915/i915_vma_resource.c  |   9 +-
 drivers/gpu/drm/i915/i915_vma_resource.h  |   6 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   1 +
 27 files changed, 910 insertions(+), 155 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_gt_defines.h
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

-- 
2.36.1




[PATCH 07/21] drm/i915/gt: describe the new tlb parameter at i915_vma_resource

2022-07-13 Thread Mauro Carvalho Chehab
TLB cache invalidation can happen on two different situations:

1. synchronously, at __vma_put_pages();
2. asynchronously.

On the first case, TLB cache invalidation happens inside
__vma_put_pages(). So, no need to do it later on.

However, on the second case, the pages will keep in memory
until __i915_vma_evict() is called.

So, we need to store the TLB data at struct i915_vma_resource,
in order to do a TLB cache invalidation before allowing
userspace to re-use the same memory.

So, i915_vma_resource_unbind() has gained a new parameter
in order to store the TLB data at the second case.

Document it.

Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/i915_vma_resource.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma_resource.c 
b/drivers/gpu/drm/i915/i915_vma_resource.c
index 5a67995ea5fe..4fe09ea0a825 100644
--- a/drivers/gpu/drm/i915/i915_vma_resource.c
+++ b/drivers/gpu/drm/i915/i915_vma_resource.c
@@ -216,6 +216,10 @@ i915_vma_resource_fence_notify(struct i915_sw_fence *fence,
 /**
  * i915_vma_resource_unbind - Unbind a vma resource
  * @vma_res: The vma resource to unbind.
+ * @tlb: pointer to vma->obj->mm.tlb associated with the resource
+ *  to be stored at vma_res->tlb. When not-NULL, it will be used
+ *  to do TLB cache invalidation before freeing a VMA resource.
+ *  used only for async unbind.
  *
  * At this point this function does little more than publish a fence that
  * signals immediately unless signaling is held back.
-- 
2.36.1



[PATCH 12/21] drm/i915/guc: Introduce TLB_INVALIDATION_ALL action

2022-07-13 Thread Mauro Carvalho Chehab
From: Piotr Piórkowski 

Add a new way to invalidate TLB via GuC using actions 0x7002
(TLB_INVALIDATION_ALL).

Those actions will be used on upcoming patches.

Signed-off-by: Piotr Piórkowski 
Cc: Michal Wajdeczko 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h |  1 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c   | 14 ++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h   |  1 +
 3 files changed, 16 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 14e35a2f8306..fb0af33e43cc 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -138,6 +138,7 @@ enum intel_guc_action {
INTEL_GUC_ACTION_PAGE_FAULT_NOTIFICATION = 0x6001,
INTEL_GUC_ACTION_TLB_INVALIDATION = 0x7000,
INTEL_GUC_ACTION_TLB_INVALIDATION_DONE = 0x7001,
+   INTEL_GUC_ACTION_TLB_INVALIDATION_ALL = 0x7002,
INTEL_GUC_ACTION_STATE_CAPTURE_NOTIFICATION = 0x8002,
INTEL_GUC_ACTION_NOTIFY_FLUSH_LOG_BUFFER_TO_FILE = 0x8003,
INTEL_GUC_ACTION_NOTIFY_CRASH_DUMP_POSTED = 0x8004,
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 5c59f9b144a3..8a104a292598 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -945,6 +945,20 @@ int intel_guc_invalidate_tlb_guc(struct intel_guc *guc,
return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
 }
 
+int intel_guc_invalidate_tlb_all(struct intel_guc *guc)
+{
+   u32 action[] = {
+   INTEL_GUC_ACTION_TLB_INVALIDATION_ALL,
+   0,
+   INTEL_GUC_TLB_INVAL_MODE_HEAVY << 
INTEL_GUC_TLB_INVAL_MODE_SHIFT |
+   INTEL_GUC_TLB_INVAL_FLUSH_CACHE,
+   };
+
+   GEM_BUG_ON(!INTEL_GUC_SUPPORTS_TLB_INVALIDATION(guc));
+
+   return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
+}
+
 /**
  * intel_guc_load_status - dump information about GuC load status
  * @guc: the GuC
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
index 73c46d405dc4..01c6478451cc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.h
@@ -386,6 +386,7 @@ int intel_guc_self_cfg64(struct intel_guc *guc, u16 key, 
u64 value);
 
 int intel_guc_invalidate_tlb_guc(struct intel_guc *guc,
 enum intel_guc_tlb_inval_mode mode);
+int intel_guc_invalidate_tlb_all(struct intel_guc *guc);
 
 static inline bool intel_guc_is_supported(struct intel_guc *guc)
 {
-- 
2.36.1



[PATCH 04/21] drm/i915/gt: Only invalidate TLBs exposed to user manipulation

2022-07-13 Thread Mauro Carvalho Chehab
From: Chris Wilson 

Don't flush TLBs when the buffer is only used in the GGTT under full
control of the kernel, as there's no risk of concurrent access
and stale access from prefetch.

We only need to invalidate the TLB if they are accessible by the user.
That helps to reduce the performance regression introduced by TLB
invalidate logic.

Cc: sta...@vger.kernel.org
Fixes: 7938d61591d3 ("drm/i915: Flush TLBs before releasing backing store")
Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Cc: Andi Shyti 
Acked-by: Thomas Hellström 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/i915_vma.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index ef3b04c7e153..646f419b2035 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -538,7 +538,8 @@ int i915_vma_bind(struct i915_vma *vma,
   bind_flags);
}
 
-   set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
+   if (bind_flags & I915_VMA_LOCAL_BIND)
+   set_bit(I915_BO_WAS_BOUND_BIT, &vma->obj->flags);
 
atomic_or(bind_flags, &vma->flags);
return 0;
-- 
2.36.1



[PATCH 20/21] drm/i915/guc: describe enum intel_guc_tlb_invalidation_type

2022-07-13 Thread Mauro Carvalho Chehab
Add a description for intel_guc_tlb_invalidation_type enum.

Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h | 12 
 1 file changed, 12 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index 5c019856a269..e97065c62d28 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -187,6 +187,18 @@ enum intel_guc_state_capture_event_status {
 /* Flush PPC or SMRO caches along with TLB invalidation request */
 #define INTEL_GUC_TLB_INVAL_FLUSH_CACHE (1 << 31)
 
+/**
+ * enum intel_guc_tlb_invalidation_type - type of TLB cache invalidation
+ *
+ * @INTEL_GUC_TLB_INVAL_FULL:
+ * Global TLB invalidation
+ * @INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE:
+ * Page-selective TLB cache invalidation
+ * @INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE_CTX:
+ * Context-selective TLB cache invalidation
+ * @INTEL_GUC_TLB_INVAL_GUC:
+ * Invalidate TLB on GuC itself
+ */
 enum intel_guc_tlb_invalidation_type {
INTEL_GUC_TLB_INVAL_FULL = 0x0,
INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE = 0x1,
-- 
2.36.1



[PATCH 14/21] drm/i915: document tlb field at struct drm_i915_gem_object

2022-07-13 Thread Mauro Carvalho Chehab
Add documentation to the TLB field inside
struct drm_i915_gem_object.

Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gem/i915_gem_object_types.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h 
b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
index 3c1d0b750a67..6f5b9e34a4d7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object_types.h
@@ -618,6 +618,7 @@ struct drm_i915_gem_object {
 */
bool dirty:1;
 
+   /** @mm.tlb: array with TLB invalidate IDs */
u32 tlb[I915_MAX_GT];
} mm;
 
-- 
2.36.1



[PATCH 17/21] drm/i915: Add generic interface for tlb invalidation for XeHP

2022-07-13 Thread Mauro Carvalho Chehab
From: Prathap Kumar Valsan 

Add an interface for GuC TLB actions, supporting both selective and
full TLB invalidations. After this change, when GuC is enabled,
tlb invalidations use GuC ct. Otherwise, use mmio interface.

Signed-off-by: Prathap Kumar Valsan 
Cc: Niranjana Vishwanathapura 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/gt/intel_gt_regs.h |  8 +++
 drivers/gpu/drm/i915/gt/intel_tlb.c | 78 -
 drivers/gpu/drm/i915/gt/intel_tlb.h |  1 +
 3 files changed, 86 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h 
b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
index 60d6eb5f245b..52508a9c23e5 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
@@ -1054,6 +1054,14 @@
 
 #define GEN12_GAM_DONE _MMIO(0xcf68)
 
+#define XEHP_TLB_INV_DESC0 _MMIO(0xcf7c)
+#define   XEHP_TLB_INV_DESC0_ADDR_LO   REG_GENMASK(31, 12)
+#define   XEHP_TLB_INV_DESC0_ADDR_MASK REG_GENMASK(8, 3)
+#define   XEHP_TLB_INV_DESC0_G REG_GENMASK(2, 1)
+#define   XEHP_TLB_INV_DESC0_VALID REG_BIT(0)
+#define XEHP_TLB_INV_DESC1 _MMIO(0xcf80)
+#define   XEHP_TLB_INV_DESC0_ADDR_HI   REG_GENMASK(31, 0)
+
 #define GEN7_HALF_SLICE_CHICKEN1   _MMIO(0xe100) /* IVB GT1 + VLV 
*/
 #define   GEN7_MAX_PS_THREAD_DEP   (8 << 12)
 #define   GEN7_SINGLE_SUBSCAN_DISPATCH_ENABLE  (1 << 10)
diff --git a/drivers/gpu/drm/i915/gt/intel_tlb.c 
b/drivers/gpu/drm/i915/gt/intel_tlb.c
index af8cae979489..15ed83226676 100644
--- a/drivers/gpu/drm/i915/gt/intel_tlb.c
+++ b/drivers/gpu/drm/i915/gt/intel_tlb.c
@@ -10,6 +10,7 @@
 #include "intel_gt_pm.h"
 #include "intel_gt_regs.h"
 #include "intel_tlb.h"
+#include "uc/intel_guc.h"
 
 struct reg_and_bit {
i915_reg_t reg;
@@ -159,11 +160,16 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, 
u32 seqno)
return;
 
with_intel_gt_pm_if_awake(gt, wakeref) {
+   struct intel_guc *guc = >->uc.guc;
+
mutex_lock(>->tlb.invalidate_lock);
if (tlb_seqno_passed(gt, seqno))
goto unlock;
 
-   mmio_invalidate_full(gt);
+   if (INTEL_GUC_SUPPORTS_TLB_INVALIDATION(guc))
+   intel_guc_invalidate_tlb_full(guc, 
INTEL_GUC_TLB_INVAL_MODE_HEAVY);
+   else
+   mmio_invalidate_full(gt);
 
write_seqcount_invalidate(>->tlb.seqno);
 unlock:
@@ -171,6 +177,76 @@ void intel_gt_invalidate_tlb_full(struct intel_gt *gt, u32 
seqno)
}
 }
 
+static bool mmio_invalidate_range(struct intel_gt *gt, u64 start, u64 length)
+{
+   u32 address_mask = (ilog2(length) - ilog2(I915_GTT_PAGE_SIZE_4K));
+   u64 vm_total = BIT_ULL(INTEL_INFO(gt->i915)->ppgtt_size);
+   intel_wakeref_t wakeref;
+   u32 dw0, dw1;
+   int err;
+
+   GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE_4K));
+   GEM_BUG_ON(!IS_ALIGNED(length, I915_GTT_PAGE_SIZE_4K));
+   GEM_BUG_ON(range_overflows(start, length, vm_total));
+
+   dw0 = FIELD_PREP(XEHP_TLB_INV_DESC0_ADDR_LO, (lower_32_bits(start) >> 
12)) |
+   FIELD_PREP(XEHP_TLB_INV_DESC0_ADDR_MASK, address_mask) |
+   FIELD_PREP(XEHP_TLB_INV_DESC0_G, 0x3) |
+   FIELD_PREP(XEHP_TLB_INV_DESC0_VALID, 0x1);
+   dw1 = upper_32_bits(start);
+
+   err = 0;
+   with_intel_gt_pm_if_awake(gt, wakeref) {
+   struct intel_uncore *uncore = gt->uncore;
+
+   intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
+
+   mutex_lock(>->tlb.invalidate_lock);
+   intel_uncore_write_fw(uncore, XEHP_TLB_INV_DESC1, dw1);
+   intel_uncore_write_fw(uncore, XEHP_TLB_INV_DESC0, dw0);
+   err = __intel_wait_for_register_fw(uncore,
+  XEHP_TLB_INV_DESC0,
+  XEHP_TLB_INV_DESC0_VALID,
+  0, 100, 10, NULL);
+   mutex_unlock(>->tlb.invalidate_lock);
+
+   intel_uncore_forcewake_put_delayed(uncore, FORCEWAKE_ALL);
+   }
+
+   if (err)
+   drm_err_ratelimited(>->i915->drm,
+   "TLB invalidation response timed out\n");
+
+   return err == 0;
+}
+
+bool intel_gt_invalidate_tlb_range(struct intel_gt *gt,
+  u64 start, u64 length)
+{
+   struct intel_guc *guc = >->uc.guc;
+   intel_wakeref_t wakeref;
+
+   if (intel_gt_is_wedged(gt))
+   return true;
+
+   if (!INTEL_GUC_SUPPORTS_TLB_INVALIDATION_SELECTIVE(guc))
+   return false;
+
+   /*XXX: We are seeing timeouts on g

[PATCH 16/21] drm/i915: Define GuC Based TLB invalidation routines

2022-07-13 Thread Mauro Carvalho Chehab
From: Prathap Kumar Valsan 

Add routines to interface with GuC firmware for selective TLB invalidation
supported on XeHP.

Signed-off-by: Prathap Kumar Valsan 
Cc: Matthew Brost 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 .../gpu/drm/i915/gt/uc/abi/guc_actions_abi.h  |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_guc.c| 90 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc.h| 10 +++
 drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h   |  3 +
 4 files changed, 106 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h 
b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
index fb0af33e43cc..5c019856a269 100644
--- a/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/abi/guc_actions_abi.h
@@ -188,6 +188,9 @@ enum intel_guc_state_capture_event_status {
 #define INTEL_GUC_TLB_INVAL_FLUSH_CACHE (1 << 31)
 
 enum intel_guc_tlb_invalidation_type {
+   INTEL_GUC_TLB_INVAL_FULL = 0x0,
+   INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE = 0x1,
+   INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE_CTX = 0x2,
INTEL_GUC_TLB_INVAL_GUC = 0x3,
 };
 
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
index 8a104a292598..98260a7bc90b 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc.c
@@ -923,6 +923,96 @@ static int guc_send_invalidate_tlb(struct intel_guc *guc, 
u32 *action, u32 size)
return err;
 }
 
+ /* Full TLB invalidation */
+int intel_guc_invalidate_tlb_full(struct intel_guc *guc,
+ enum intel_guc_tlb_inval_mode mode)
+{
+   u32 action[] = {
+   INTEL_GUC_ACTION_TLB_INVALIDATION,
+   0,
+   INTEL_GUC_TLB_INVAL_FULL << INTEL_GUC_TLB_INVAL_TYPE_SHIFT |
+   mode << INTEL_GUC_TLB_INVAL_MODE_SHIFT |
+   INTEL_GUC_TLB_INVAL_FLUSH_CACHE,
+   };
+
+   if (!INTEL_GUC_SUPPORTS_TLB_INVALIDATION(guc)) {
+   DRM_ERROR("Tlb invalidation: Operation not supported in this 
platform!\n");
+   return 0;
+   }
+
+   return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
+}
+
+/*
+ * Selective TLB Invalidation for Address Range:
+ * TLB's in the Address Range is Invalidated across all engines.
+ */
+int intel_guc_invalidate_tlb_page_selective(struct intel_guc *guc,
+   enum intel_guc_tlb_inval_mode mode,
+   u64 start, u64 length)
+{
+   u64 vm_total = BIT_ULL(INTEL_INFO(guc_to_gt(guc)->i915)->ppgtt_size);
+   u32 address_mask = (ilog2(length) - ilog2(I915_GTT_PAGE_SIZE_4K));
+   u32 full_range = vm_total == length;
+   u32 action[] = {
+   INTEL_GUC_ACTION_TLB_INVALIDATION,
+   0,
+   INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE << 
INTEL_GUC_TLB_INVAL_TYPE_SHIFT |
+   mode << INTEL_GUC_TLB_INVAL_MODE_SHIFT |
+   INTEL_GUC_TLB_INVAL_FLUSH_CACHE,
+   0,
+   full_range ? full_range : lower_32_bits(start),
+   full_range ? 0 : upper_32_bits(start),
+   full_range ? 0 : address_mask,
+   };
+
+   if (!INTEL_GUC_SUPPORTS_TLB_INVALIDATION_SELECTIVE(guc)) {
+   DRM_ERROR("Tlb invalidation: Operation not supported in this 
platform!\n");
+   return 0;
+   }
+
+   GEM_BUG_ON(!IS_ALIGNED(start, I915_GTT_PAGE_SIZE_4K));
+   GEM_BUG_ON(!IS_ALIGNED(length, I915_GTT_PAGE_SIZE_4K));
+   GEM_BUG_ON(range_overflows(start, length, vm_total));
+
+   return guc_send_invalidate_tlb(guc, action, ARRAY_SIZE(action));
+}
+
+/*
+ * Selective TLB Invalidation for Context:
+ * Invalidates all TLB's for a specific context across all engines.
+ */
+int intel_guc_invalidate_tlb_page_selective_ctx(struct intel_guc *guc,
+   enum intel_guc_tlb_inval_mode 
mode,
+   u64 start, u64 length, u32 
ctxid)
+{
+   u64 vm_total = BIT_ULL(INTEL_INFO(guc_to_gt(guc)->i915)->ppgtt_size);
+   u32 address_mask = (ilog2(length) - ilog2(I915_GTT_PAGE_SIZE_4K));
+   u32 full_range = vm_total == length;
+   u32 action[] = {
+   INTEL_GUC_ACTION_TLB_INVALIDATION,
+   0,
+   INTEL_GUC_TLB_INVAL_PAGE_SELECTIVE_CTX << 
INTEL_GUC_TLB_INVAL_TYPE_SHIFT |
+   mode << INTEL_GUC_TLB_INVAL_MODE_SHIFT |
+   INTEL_GUC_TLB_INVAL_FLUSH_CACHE,
+   ctxid,
+   full_range ? full_range : lower_32_bits(start),
+   full_range ? 0 : upper_32_bits(start),
+   full_range ? 0 : address_mask,
+   };
+
+   if (!INTEL_GUC_SUPPORTS_TLB_INVALIDATION_SELECTIVE(guc)) {
+   DRM_ERROR("Tlb invalidation: Operation not sup

[PATCH 08/21] drm/i915/gt: Move TLB invalidation to its own file

2022-07-13 Thread Mauro Carvalho Chehab
From: Chris Wilson 

Prepare for supporting more TLB invalidation scenarios by moving
the current MMIO invalidation to its own file.

Signed-off-by: Chris Wilson 
Cc: Fei Yang 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pages.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gt.c| 168 +---
 drivers/gpu/drm/i915/gt/intel_gt.h|  12 --
 drivers/gpu/drm/i915/gt/intel_tlb.c   | 183 ++
 drivers/gpu/drm/i915/gt/intel_tlb.h   |  29 
 drivers/gpu/drm/i915/i915_vma.c   |   1 +
 7 files changed, 219 insertions(+), 179 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.c
 create mode 100644 drivers/gpu/drm/i915/gt/intel_tlb.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 522ef9b4aff3..d3df9832d1f7 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -126,6 +126,7 @@ gt-y += \
gt/intel_sseu.o \
gt/intel_sseu_debugfs.o \
gt/intel_timeline.o \
+   gt/intel_tlb.o \
gt/intel_workarounds.o \
gt/shmem_utils.o \
gt/sysfs_engines.o
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pages.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
index 8357dbdcab5c..1cd76cc5d9f3 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pages.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pages.c
@@ -7,7 +7,7 @@
 #include 
 
 #include "gt/intel_gt.h"
-#include "gt/intel_gt_pm.h"
+#include "gt/intel_tlb.h"
 
 #include "i915_drv.h"
 #include "i915_gem_object.h"
@@ -199,7 +199,7 @@ static void flush_tlb_invalidate(struct drm_i915_gem_object 
*obj)
if (!obj->mm.tlb)
return;
 
-   intel_gt_invalidate_tlb(gt, obj->mm.tlb);
+   intel_gt_invalidate_tlb_full(gt, obj->mm.tlb);
obj->mm.tlb = 0;
 }
 
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index f435e06125aa..18d82cd620bd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -11,9 +11,7 @@
 #include "pxp/intel_pxp.h"
 
 #include "i915_drv.h"
-#include "i915_perf_oa_regs.h"
 #include "intel_context.h"
-#include "intel_engine_pm.h"
 #include "intel_engine_regs.h"
 #include "intel_ggtt_gmch.h"
 #include "intel_gt.h"
@@ -31,6 +29,7 @@
 #include "intel_renderstate.h"
 #include "intel_rps.h"
 #include "intel_gt_sysfs.h"
+#include "intel_tlb.h"
 #include "intel_uncore.h"
 #include "shmem_utils.h"
 
@@ -48,8 +47,7 @@ static void __intel_gt_init_early(struct intel_gt *gt)
intel_gt_init_reset(gt);
intel_gt_init_requests(gt);
intel_gt_init_timelines(gt);
-   mutex_init(>->tlb.invalidate_lock);
-   seqcount_mutex_init(>->tlb.seqno, >->tlb.invalidate_lock);
+   intel_gt_init_tlb(gt);
intel_gt_pm_init_early(gt);
 
intel_uc_init_early(>->uc);
@@ -770,7 +768,7 @@ void intel_gt_driver_late_release_all(struct 
drm_i915_private *i915)
intel_gt_fini_requests(gt);
intel_gt_fini_reset(gt);
intel_gt_fini_timelines(gt);
-   mutex_destroy(>->tlb.invalidate_lock);
+   intel_gt_fini_tlb(gt);
intel_engines_free(gt);
}
 }
@@ -881,163 +879,3 @@ void intel_gt_info_print(const struct intel_gt_info *info,
 
intel_sseu_dump(&info->sseu, p);
 }
-
-struct reg_and_bit {
-   i915_reg_t reg;
-   u32 bit;
-};
-
-static struct reg_and_bit
-get_reg_and_bit(const struct intel_engine_cs *engine, const bool gen8,
-   const i915_reg_t *regs, const unsigned int num)
-{
-   const unsigned int class = engine->class;
-   struct reg_and_bit rb = { };
-
-   if (drm_WARN_ON_ONCE(&engine->i915->drm,
-class >= num || !regs[class].reg))
-   return rb;
-
-   rb.reg = regs[class];
-   if (gen8 && class == VIDEO_DECODE_CLASS)
-   rb.reg.reg += 4 * engine->instance; /* GEN8_M2TCR */
-   else
-   rb.bit = engine->instance;
-
-   rb.bit = BIT(rb.bit);
-
-   return rb;
-}
-
-static void mmio_invalidate_full(struct intel_gt *gt)
-{
-   static const i915_reg_t gen8_regs[] = {
-   [RENDER_CLASS]  = GEN8_RTCR,
-   [VIDEO_DECODE_CLASS]= GEN8_M1TCR, /* , GEN8_M2TCR */
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN8_VTCR,
-   [COPY_ENGINE_CLASS] = GEN8_BTCR,
-   };
-   static const i915_reg_t gen12_regs[] = {
-   [RENDER_CLASS]  = GEN12_GFX_TLB_INV_CR,
-   [VIDEO_DECODE_CLASS]= GEN12_VD_TLB_INV_CR,
-   [VIDEO_ENHANCEMENT_CLASS]   = GEN12_VE_TLB_INV_CR,
-   [COPY_ENGINE_CLASS] = GEN12_BLT_TLB_INV_CR,
-   [COMPUTE_CLASS] = G

[PATCH 15/21] drm/i915: Add platform macro for selective tlb flush

2022-07-13 Thread Mauro Carvalho Chehab
From: Prathap Kumar Valsan 

Add support for selective TLB invalidation, which is a platform
feature supported on XeHP.

Signed-off-by: Prathap Kumar Valsan 
Cc: Niranjana Vishwanathapura 
Signed-off-by: Mauro Carvalho Chehab 
---

See [PATCH 00/21] at: 
https://lore.kernel.org/all/cover.1657703926.git.mche...@kernel.org/

 drivers/gpu/drm/i915/i915_drv.h  | 3 +++
 drivers/gpu/drm/i915/i915_pci.c  | 1 +
 drivers/gpu/drm/i915/intel_device_info.h | 1 +
 3 files changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index f1f70257dbe0..73494960a3a8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1312,6 +1312,9 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
 
 #define HAS_GT_UC(dev_priv)(INTEL_INFO(dev_priv)->has_gt_uc)
 
+#define HAS_SELECTIVE_TLB_INVALIDATION(dev_priv) \
+   (INTEL_INFO(dev_priv)->has_selective_tlb_invalidation)
+
 #define HAS_POOLED_EU(dev_priv)(INTEL_INFO(dev_priv)->has_pooled_eu)
 
 #define HAS_GLOBAL_MOCS_REGISTERS(dev_priv)
(INTEL_INFO(dev_priv)->has_global_mocs)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index aacc10f2e73f..30d945fe384b 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1022,6 +1022,7 @@ static const struct intel_device_info adl_p_info = {
.has_reset_engine = 1, \
.has_rps = 1, \
.has_runtime_pm = 1, \
+   .has_selective_tlb_invalidation = 1, \
.ppgtt_size = 48, \
.ppgtt_type = INTEL_PPGTT_FULL
 
diff --git a/drivers/gpu/drm/i915/intel_device_info.h 
b/drivers/gpu/drm/i915/intel_device_info.h
index 23bf230aa104..92a38b8f7c47 100644
--- a/drivers/gpu/drm/i915/intel_device_info.h
+++ b/drivers/gpu/drm/i915/intel_device_info.h
@@ -170,6 +170,7 @@ enum intel_ppgtt_type {
func(has_rc6p); \
func(has_rps); \
func(has_runtime_pm); \
+   func(has_selective_tlb_invalidation); \
func(has_snoop); \
func(has_coherent_ggtt); \
func(unfenced_needs_alignment); \
-- 
2.36.1



  1   2   >