Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)

[Paul Menzel]

Dear Christian,


Am 05.04.22 um 08:54 schrieb Christian König:

Am 05.04.22 um 08:45 schrieb Paul Menzel:



Am 04.04.22 um 23:42 schrieb Philip Yang:

bo_adev is NULL for system memory mapping to GPU.

Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)


Sorry, where can I find that commit?


Well that's expected, the development branch is not public.


Well obviously, it was unexpected for me. How should I have known? Where 
is that documented? If the patches are publicly posted to the mailing 
list, why is that development branch not public?


The current situation is really frustrating for non-AMD employees. How 
can the current situation be improved?



Kind regards,

Paul


I do not see it in drm-next from agd5f git archive 
g...@gitlab.freedesktop.org:agd5f/linux.git.


    $ git log --oneline -1
    e45422695c19 (HEAD, agd5f/drm-next) drm/amdkfd: Create file 
descriptor after client is added to smi_clients list



Kind regards,

Paul



Signed-off-by: Philip Yang 
---
  drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c

index 907b02045824..d3fb2d0b5a25 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
@@ -1281,7 +1281,7 @@ svm_range_map_to_gpu(struct kfd_process_device 
*pdd, struct svm_range *prange,

 last_start, prange->start + i,
 pte_flags,
 last_start - prange->start,
-   bo_adev->vm_manager.vram_base_offset,
+   bo_adev ? 
bo_adev->vm_manager.vram_base_offset : 0,

 NULL, dma_addr, &vm->last_update);
    for (j = last_start - prange->start; j <= i; j++)

Re: [PATCH 06/23] drm/nouveau: stop using dma_resv_excl_fence

[Christian König]

Am 04.04.22 um 13:47 schrieb Karol Herbst:

On Sun, Apr 3, 2022 at 5:59 PM Christian König  wrote:

Just a gentle ping to the nouveau guys.

Any more comments on this? Otherwise I'm pushing that with Daniels rb.


It looks fine, but given that this area broke in the past I will try
to do some testing either before or after you push it. As long as we
do so before 5.19 it should be okay I think.


Ok that's sounds good enough to me. Going to push it to drm-misc-next now.

Thanks,
Christian.



Unless somebody knowing more about this code has anything else to say.


Thanks,
Christian.

Am 21.03.22 um 14:58 schrieb Christian König:

Instead use the new dma_resv_get_singleton function.

Signed-off-by: Christian König 
Reviewed-by: Daniel Vetter 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: nouv...@lists.freedesktop.org
---
   drivers/gpu/drm/nouveau/nouveau_bo.c | 9 -
   1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c 
b/drivers/gpu/drm/nouveau/nouveau_bo.c
index fa73fe57f97b..74f8652d2bd3 100644
--- a/drivers/gpu/drm/nouveau/nouveau_bo.c
+++ b/drivers/gpu/drm/nouveau/nouveau_bo.c
@@ -959,7 +959,14 @@ nouveau_bo_vm_cleanup(struct ttm_buffer_object *bo,
   {
   struct nouveau_drm *drm = nouveau_bdev(bo->bdev);
   struct drm_device *dev = drm->dev;
- struct dma_fence *fence = dma_resv_excl_fence(bo->base.resv);
+ struct dma_fence *fence;
+ int ret;
+
+ /* TODO: This is actually a memory management dependency */
+ ret = dma_resv_get_singleton(bo->base.resv, false, &fence);
+ if (ret)
+ dma_resv_wait_timeout(bo->base.resv, false, false,
+   MAX_SCHEDULE_TIMEOUT);

   nv10_bo_put_tile_region(dev, *old_tile, fence);
   *old_tile = new_tile;

[PATCH 5.17 0186/1126] drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB

[Greg Kroah-Hartman]

From: Thomas Zimmermann 

commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.

Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)

For shadow buffers, also set the FBINFO_READS_FAST hint.

v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag

Signed-off-by: Thomas Zimmermann 
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe 
function")
Reviewed-by: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_fb_helper.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = sizes->surface_height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
 
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
 
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
 
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
 
/*
 * Shamelessly leak the physical address to user-space. As

Re: (subset) [PATCH] dt-bindings: display: bridge: Drop requirement on input port for DSI devices

[Maxime Ripard]

On Wed, 23 Mar 2022 16:48:23 +0100, Maxime Ripard wrote:
> MIPI-DSI devices, if they are controlled through the bus itself, have to
> be described as a child node of the controller they are attached to.
> 
> Thus, there's no requirement on the controller having an OF-Graph output
> port to model the data stream: it's assumed that it would go from the
> parent to the child.
> 
> [...]

Applied to drm/drm-misc (drm-misc-fixes).

Thanks!
Maxime

Re: [PATCH v13 00/13] Add GuC Error Capture Support

[Tvrtko Ursulin]

On 23/03/2022 13:19, Tvrtko Ursulin wrote:


Hi,

On 21/03/2022 16:45, Alan Previn wrote:

This series:
   1. Enables support of GuC to report error-state-capture
  using a list of MMIO registers the driver registers
  and GuC will dump, log and notify right before a GuC
  triggered engine-reset event.
   2. Updates the ADS blob creation to register said lists
  of global, engine class and engine instance registers
  with GuC.
   3. Defines tables of register lists that are global or
  engine class or engine instance in scope.
   4. Updates usage and buffer-state data for the regions
  of the shared GuC log-buffer to accomdate both
  the existing relay logging of general debug logs
  along with the new error state capture usage.
   5. Using a pool of preallocated memory, provide ability
  to extract and format the GuC reported register-capture
  data into chunks consistent with existing i915 error-
  state collection flows and structures.
   6. Connects the i915_gpu_coredump reporting function
  to the GuC error capture module to print all GuC
  error state capture dumps that is reported.


Story is finished with this series and we have everything on feature 
parity? Intel_error_decode handles it fine?


Would you have an example error capture at hand, I am curious how it looks?


Ping? I need to write a meaningful pull request text in ~2 weeks time 
when submitting the feature to drm-next so looking for a high level 
statement as described - does it complete the work and is error capture 
now at feature parity and all usual userspace tools to access it handle it?


Regards,

Tvrtko





Regards,

Tvrtko



This is the 13th rev of this series where the first 3 revs
are RFC

Prior receipts of rvb's:
   - Patch #2, #3, #4, #5, #10, #11, #12, #13 have received
 R-v-b's from Umesh Nerlige Ramappa 
   - Patch #1, #6, #7, #8, #9 has received an R-v-b from Matthew Brost
 . NOTE: some of these came in on the
 trybot series. https://patchwork.freedesktop.org/series/100831/

Changes from prior revs:
   v13:- Fixing register list definition styling as per Jani's request.
   v12:- Re-sending it because previous revs only got to intel-gfx,
 and only cover letter was in dri-devel. Also rebased again.
   v11:- Rebase again on latest drm-tip to fix merge error.
   v10:- Rebase on latest drm-tip again. Fix a number of checkpatch
 warnings and an error Reported-by: kernel test robot 
.

   v9: - Rebase on latest drm-tip to solve CI merge-build error.
   v8: - Fix a bug found by CI in rev7: Create a cached ADS
 capture list for null-header like the other lists.
   - Fixed a bug on the ggtt offset calculation in the
 ADS population loop. Thanks to Matt Brost.
   - Change the storage uses for initial allocation and
 caching of the ADS register lists so we only store
 a regular pointer instead of file handle.
   - Multiple improvements on code styling, variable names,
 comments and code reduction from Umesh suggestions
 across multiple patches.

   v7: - Rebased on lastest drm_tip that has the ADS now using
 shmem based ads_blob_write utilities. Stress test
 was performed with this patch included to fix a
 legacy bug:
 https://patchwork.freedesktop.org/series/100768/

   v6: - In patch #1, ADS reg-list population, we now alloc
 regular memory to create the lists and cache them for
 simpler and faster use by GuC ADS module at init,
 suspend-resume and reset cycles. This was in response
 to review comments from Lucas De Marchi that also
 wanted to ensure the GuC ADS module owns the final
 copying into the ADS phyical memory.
   - Thanks to Jani Nikula for pointing out that patch #2
 and #3 should ensure static tables as constant and
 dynamic lists should be allocated and cached but
 attached to the GT level for the case of multiple
 cards with different fusings for steered registers.
 These are addressed now along with multiple code
 style fixups (thanks to review comment from Umesh)
 and splitting the steered register list generation
 as a seperate patch.
   - The extraction functionality, Patch #10 and #11 (was
 patch #7), has fixed all of Umesh's review comments
 related to the code styling. Additionally, it was
 discovered during stress tests that the extraction
 function could be called by the ct processing thread
 at the same time as the start of a GT reset event.
 Thus, a redesign was done whereby the linked list of
 processed capture-output-nodes are allocated up
 front and reused throughout the driver's life to
 ensure no memory locks are taken during extraction.
   - For patch #6 (now 7, 8 and 9), updates to
 intel_guc_log was split into smalle

Re: [PATCH 10/23] dma-buf: finally make dma_resv_excl_fence private v2

[Christian König]

Am 23.03.22 um 14:36 schrieb Daniel Vetter:

On Mon, Mar 21, 2022 at 02:58:43PM +0100, Christian König wrote:

Drivers should never touch this directly.

v2: fix rebase clash

Signed-off-by: Christian König 

Reviewed-by: Daniel Vetter 

I guess as soon as we have the rdma ack you can land up to this patch?


It also needed the nouveau and vmwgfx acks, but I just pushed it. Finally :)

Christian.


-Daniel


---
  drivers/dma-buf/dma-resv.c |  6 ++
  include/linux/dma-resv.h   | 17 -
  2 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index c09fd8da0c85..1c9af97fe904 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -140,6 +140,12 @@ void dma_resv_fini(struct dma_resv *obj)
  }
  EXPORT_SYMBOL(dma_resv_fini);
  
+static inline struct dma_fence *

+dma_resv_excl_fence(struct dma_resv *obj)
+{
+   return rcu_dereference_check(obj->fence_excl, dma_resv_held(obj));
+}
+
  static inline struct dma_resv_list *dma_resv_shared_list(struct dma_resv *obj)
  {
return rcu_dereference_check(obj->fence, dma_resv_held(obj));
diff --git a/include/linux/dma-resv.h b/include/linux/dma-resv.h
index 08512c1e215d..20e13f36710a 100644
--- a/include/linux/dma-resv.h
+++ b/include/linux/dma-resv.h
@@ -423,23 +423,6 @@ static inline void dma_resv_unlock(struct dma_resv *obj)
ww_mutex_unlock(&obj->lock);
  }
  
-/**

- * dma_resv_excl_fence - return the object's exclusive fence
- * @obj: the reservation object
- *
- * Returns the exclusive fence (if any). Caller must either hold the objects
- * through dma_resv_lock() or the RCU read side lock through rcu_read_lock(),
- * or one of the variants of each
- *
- * RETURNS
- * The exclusive fence or NULL
- */
-static inline struct dma_fence *
-dma_resv_excl_fence(struct dma_resv *obj)
-{
-   return rcu_dereference_check(obj->fence_excl, dma_resv_held(obj));
-}
-
  void dma_resv_init(struct dma_resv *obj);
  void dma_resv_fini(struct dma_resv *obj);
  int dma_resv_reserve_shared(struct dma_resv *obj, unsigned int num_fences);
--
2.25.1

Re: [PATCH] drm: bridge: icn6211: Fix DSI-to-DPI PLL configuration

[Maxime Ripard]

On Sat, Apr 02, 2022 at 02:41:18AM +0200, Marek Vasut wrote:
> The datasheet for this bridge is not available, the PLL behavior has been
> inferred from [1] and [2] and by analyzing the DPI pixel clock with scope.
> After further testing with other displays and different DSI data lane count,
> it turns out the P-factor is not 1/2^N divider, but rather only 1/N divider.
> It also turns out the input into the PLL seem to be ByteClock instead of DSI
> HS clock.
> 
> Rework the P-factor calculation such that the PLL calculation code handles
> P-factor from 1..32 with P-factors above 16 must be even. In case P-factor
> is even, enable built-in 1:2 divider and program P-factor/2 to PLL_REF_DIV,
> otherwise configure only the P-factor into PLL_REF_DIV register.
> 
> Switch the PLL factor calculation from kHz to Hz to maintain precision.
> 
> [1] 
> https://github.com/rockchip-linux/kernel/blob/develop-4.19/drivers/gpu/drm/bridge/icn6211.c
> [2] https://github.com/tdjastrzebski/ICN6211-Configurator
> 
> Fixes: f30cf0ece691 ("drm: bridge: icn6211: Add generic DSI-to-DPI PLL 
> configuration")
> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 
> Cc: Maxime Ripard 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: Thomas Zimmermann 
> To: dri-devel@lists.freedesktop.org

Acked-by: Maxime Ripard 

Maxime


signature.asc
Description: PGP signature

[PATCH 5.17 0604/1126] drm/dp: Fix OOB read when handling Post Cursor2 register

[Greg Kroah-Hartman]

From: Kees Cook 

[ Upstream commit a2151490cc6c57b368d7974ffd447a8b36ade639 ]

The link_status array was not large enough to read the Adjust Request
Post Cursor2 register, so remove the common helper function to avoid
an OOB read, found with a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 
'drm_dp_get_adjust_request_post_cursor':
drivers/gpu/drm/drm_dp_helper.c:59:27: error: array subscript 10 is outside 
array bounds of 'const u8[6]' {aka 'const unsigned char[6]'} 
[-Werror=array-bounds]
   59 | return link_status[r - DP_LANE0_1_STATUS];
  |~~~^~~
drivers/gpu/drm/drm_dp_helper.c:147:51: note: while referencing 'link_status'
  147 | u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZE],
  |  
~^~~~

Replace the only user of the helper with an open-coded fetch and decode,
similar to drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c.

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Fixes: 79465e0ffeb9 ("drm/dp: Add helper to get post-cursor adjustments")
Signed-off-by: Kees Cook 
Reviewed-by: Gustavo A. R. Silva 
Reviewed-by: Jani Nikula 
Link: https://lore.kernel.org/r/20220105173507.2420910-1-keesc...@chromium.org
Signed-off-by: Thierry Reding 
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/drm_dp_helper.c | 10 --
 drivers/gpu/drm/tegra/dp.c  | 11 ++-
 include/drm/drm_dp_helper.h |  2 --
 3 files changed, 10 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
index 23f9073bc473..c9528aa62c9c 100644
--- a/drivers/gpu/drm/drm_dp_helper.c
+++ b/drivers/gpu/drm/drm_dp_helper.c
@@ -144,16 +144,6 @@ u8 drm_dp_get_adjust_tx_ffe_preset(const u8 
link_status[DP_LINK_STATUS_SIZE],
 }
 EXPORT_SYMBOL(drm_dp_get_adjust_tx_ffe_preset);
 
-u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane)
-{
-   unsigned int offset = DP_ADJUST_REQUEST_POST_CURSOR2;
-   u8 value = dp_link_status(link_status, offset);
-
-   return (value >> (lane << 1)) & 0x3;
-}
-EXPORT_SYMBOL(drm_dp_get_adjust_request_post_cursor);
-
 static int __8b10b_clock_recovery_delay_us(const struct drm_dp_aux *aux, u8 
rd_interval)
 {
if (rd_interval > 4)
diff --git a/drivers/gpu/drm/tegra/dp.c b/drivers/gpu/drm/tegra/dp.c
index 70dfb7d1dec5..f5535eb04c6b 100644
--- a/drivers/gpu/drm/tegra/dp.c
+++ b/drivers/gpu/drm/tegra/dp.c
@@ -549,6 +549,15 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link 
*link,
 {
struct drm_dp_link_train_set *adjust = &link->train.adjust;
unsigned int i;
+   u8 post_cursor;
+   int err;
+
+   err = drm_dp_dpcd_read(link->aux, DP_ADJUST_REQUEST_POST_CURSOR2,
+  &post_cursor, sizeof(post_cursor));
+   if (err < 0) {
+   DRM_ERROR("failed to read post_cursor2: %d\n", err);
+   post_cursor = 0;
+   }
 
for (i = 0; i < link->lanes; i++) {
adjust->voltage_swing[i] =
@@ -560,7 +569,7 @@ static void drm_dp_link_get_adjustments(struct drm_dp_link 
*link,
DP_TRAIN_PRE_EMPHASIS_SHIFT;
 
adjust->post_cursor[i] =
-   drm_dp_get_adjust_request_post_cursor(status, i);
+   (post_cursor >> (i << 1)) & 0x3;
}
 }
 
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index 30359e434c3f..28378db676c8 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -1528,8 +1528,6 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8 
link_status[DP_LINK_STATUS_SI
  int lane);
 u8 drm_dp_get_adjust_tx_ffe_preset(const u8 link_status[DP_LINK_STATUS_SIZE],
   int lane);
-u8 drm_dp_get_adjust_request_post_cursor(const u8 
link_status[DP_LINK_STATUS_SIZE],
-unsigned int lane);
 
 #define DP_BRANCH_OUI_HEADER_SIZE  0xc
 #define DP_RECEIVER_CAP_SIZE   0xf
-- 
2.34.1

Re: [Intel-gfx] [CI 8/8] drm/i915: Expose client engine utilisation via fdinfo

[Tvrtko Ursulin]

On 04/04/2022 16:36, Daniel Vetter wrote:

On Mon, Apr 04, 2022 at 10:23:53AM +0100, Tvrtko Ursulin wrote:


+ Dave and Daniel

Guys, are you okay with merging this via drm-intel-gt-next? It is one new
file at Documentation/gpu/drm-usage-stats.rst only which is outside i915. It
has acks from Christian and Rob.


Acked-by: Daniel Vetter 


Thanks, pushed now.

Rob - you can proceed with your driver at your leisure. I will re-send 
the rebased gputop to igt-dev shortly and copy you.


Regards,

Tvrtko



Daniel, series is also fully reviewed and IGT reviewed and ready. Rob also
demonstrated the approach works for msm when using the vendor agnosstic
gputop tool I sketched out (see
20220225202614.225197-3-robdcl...@gmail.com).

My plan is to merge the i915 support with the common spec and intel_gpu_top
on the IGT side. Then follow-up with vendor agnostic gputop and later yet
potentially re-visit the AMD side by re-sending the patch which tweaks the
fdinfo format there and adds support for relative engine utilisation as
provided by amdgpu.

Regards,

Tvrtko

On 04/04/2022 10:12, Tvrtko Ursulin wrote:


On 01/04/2022 15:22, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Similar to AMD commit
874442541133 ("drm/amdgpu: Add show_fdinfo() interface"), using the
infrastructure added in previous patches, we add basic client info
and GPU engine utilisation for i915.

Example of the output:

    pos:    0
    flags:  012
    mnt_id: 21
    drm-driver: i915
    drm-pdev:   :00:02.0
    drm-client-id:  7
    drm-engine-render:  9288864723 ns
    drm-engine-copy:    2035071108 ns
    drm-engine-video:   0 ns
    drm-engine-video-enhance:   0 ns

v2:
   * Update for removal of name and pid.

v3:
   * Use drm_driver.name.

v4:
   * Added drm-engine-capacity- tag.
   * Fix typo. (Umesh)

v5:
   * Don't output engine data before Gen8.

Signed-off-by: Tvrtko Ursulin 
Cc: David M Nieto 
Cc: Christian König 
Cc: Daniel Vetter 
Cc: Chris Healy 
Acked-by: Christian König 
Reviewed-by: Umesh Nerlige Ramappa 


Forgot to apply an earlier:

Acked-by: Rob Clark 

Regards,

Tvrtko


---
   Documentation/gpu/drm-usage-stats.rst  |  6 ++
   Documentation/gpu/i915.rst | 28 +
   drivers/gpu/drm/i915/i915_driver.c |  3 +
   drivers/gpu/drm/i915/i915_drm_client.c | 84 ++
   drivers/gpu/drm/i915/i915_drm_client.h |  4 ++
   5 files changed, 125 insertions(+)

diff --git a/Documentation/gpu/drm-usage-stats.rst
b/Documentation/gpu/drm-usage-stats.rst
index b8cc28f4da6f..6c9f166a8d6f 100644
--- a/Documentation/gpu/drm-usage-stats.rst
+++ b/Documentation/gpu/drm-usage-stats.rst
@@ -104,3 +104,9 @@ object belong to this client, in the respective
memory region.
   Default unit shall be bytes with optional unit specifiers of 'KiB'
or 'MiB'
   indicating kibi- or mebi-bytes.
+
+===
+Driver specific implementations
+===
+
+:ref:`i915-usage-stats`
diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
index 0f08693d05cd..54060cd6c419 100644
--- a/Documentation/gpu/i915.rst
+++ b/Documentation/gpu/i915.rst
@@ -697,3 +697,31 @@ The style guide for ``i915_reg.h``.
   .. kernel-doc:: drivers/gpu/drm/i915/i915_reg.h
  :doc: The i915 register macro definition style guide
+
+.. _i915-usage-stats:
+
+i915 DRM client usage stats implementation
+==
+
+The drm/i915 driver implements the DRM client usage stats
specification as
+documented in :ref:`drm-client-usage-stats`.
+
+Example of the output showing the implemented key value pairs and
entirety of
+the currently possible format options:
+
+::
+
+  pos:    0
+  flags:  012
+  mnt_id: 21
+  drm-driver: i915
+  drm-pdev:   :00:02.0
+  drm-client-id:  7
+  drm-engine-render:  9288864723 ns
+  drm-engine-copy:    2035071108 ns
+  drm-engine-video:   0 ns
+  drm-engine-capacity-video:   2
+  drm-engine-video-enhance:   0 ns
+
+Possible `drm-engine-` key names are: `render`, `copy`, `video` and
+`video-enhance`.
diff --git a/drivers/gpu/drm/i915/i915_driver.c
b/drivers/gpu/drm/i915/i915_driver.c
index b2df273e6d7b..3ffb617d75c9 100644
--- a/drivers/gpu/drm/i915/i915_driver.c
+++ b/drivers/gpu/drm/i915/i915_driver.c
@@ -1745,6 +1745,9 @@ static const struct file_operations
i915_driver_fops = {
   .read = drm_read,
   .compat_ioctl = i915_ioc32_compat_ioctl,
   .llseek = noop_llseek,
+#ifdef CONFIG_PROC_FS
+    .show_fdinfo = i915_drm_client_fdinfo,
+#endif
   };
   static int
diff --git a/drivers/gpu/drm/i915/i915_drm_client.c
b/drivers/gpu/drm/i915/i915_drm_client.c
index 91a8559bebf7..e539f6b23060 100644
--- a/drivers/gpu/drm/i915/i915_drm_client.c
+++ b/drivers/gpu/drm/i915/i915_drm_client.c
@@ -7,7 +7,13 @@
   #include 
   #include 
+#include 
+
+#include 
+
+#include "gem/i915_gem_context.h"
   #include "i915_drm_client.h"
+#include "i915_file_private.h"
   #include "i915_g

[PATCH 5.17 0902/1126] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

[Greg Kroah-Hartman]

From: Tim Gardner 

[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]

Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.

Cc: Antonino Daplas 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c 
b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, 
const char *name,
 {
int rc;
 
-   strcpy(chan->adapter.name, name);
+   strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
-- 
2.34.1

[PATCH 5.17 0966/1126] drm/dp: Fix off-by-one in register cache size

[Greg Kroah-Hartman]

From: Kees Cook 

commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.

The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside 
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'} 
[-Werror=array-bounds]
 3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
  |   ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
 3126 | int drm_dp_pcon_dsc_bpp_incr(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
  |  
~^~~

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for 
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva 
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman 
---
 include/drm/drm_dp_helper.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -456,7 +456,7 @@ struct drm_panel;
 #define DP_FEC_CAPABILITY_10x091   /* 2.0 */
 
 /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
 #define DP_PCON_DSC_ENCODER 0x092
 # define DP_PCON_DSC_ENCODER_SUPPORTED  (1 << 0)
 # define DP_PCON_DSC_PPS_ENC_OVERRIDE   (1 << 1)

Re: [PATCH] dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory

[Noralf Trønnes]

Den 04.04.2022 21.21, skrev Marek Vasut:
> Make the width-mm/height-mm panel properties mandatory
> to correctly report the panel dimensions to the OS.
> 
> Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI 
> compatible SPI panels")
> Signed-off-by: Marek Vasut 
> Cc: Christoph Niedermaier 
> Cc: Daniel Vetter 
> Cc: Dmitry Osipenko 
> Cc: Laurent Pinchart 
> Cc: Noralf Trønnes 
> Cc: Rob Herring 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: Thomas Zimmermann 
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org
> ---

Acked-by: Noralf Trønnes 

>  .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml   | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> index f29789994b180..c2df8d28aaf5f 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -83,6 +83,8 @@ properties:
>  required:
>- compatible
>- reg
> +  - width-mm
> +  - height-mm
>- panel-timing
>  
>  unevaluatedProperties: false

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Daniel Vetter]

On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
> On 2/8/22 22:08, Daniel Vetter wrote:
> > This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
> > 
> > With
> > 
> > commit 27599aacbaefcbf2af7b06b0029459bbf682000d
> > Author: Thomas Zimmermann 
> > Date:   Tue Jan 25 10:12:18 2022 +0100
> > 
> > fbdev: Hot-unplug firmware fb devices on forced removal
> > 
> > this should be fixed properly and we can remove this somewhat hackish
> > check here (e.g. this won't catch drm drivers if fbdev emulation isn't
> > enabled).
> >
> 
> Unfortunately this hack can't be reverted yet. Thomas' patch solves the issue
> of platform devices matched with fbdev drivers to be properly unregistered if
> a DRM driver attempts to remove all the conflicting framebuffers.
> 
> But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers if
> a FB is already registered") worked around is different. It happens when the
> DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
> kicking out of conflicting framebuffers already happened and these drivers
> will be allowed to probe even when a DRM driver is already present.
> 
> We need a clearer way to prevent it, but can't revert fb561bf9abde until that.

Yeah that entire area is a mess still, ideally we'd have something else
creating the platform devices, and efifb/offb and all these would just
bind against them.

Hm one idea that just crossed my mind: Could we have a flag in fb_info for
fw drivers, and check this in framebuffer_register? Then at least all the
logic would be in the fbdev core.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Daniel Vetter]

On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
> On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
> > On 2/8/22 22:08, Daniel Vetter wrote:
> > > This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
> > > 
> > > With
> > > 
> > > commit 27599aacbaefcbf2af7b06b0029459bbf682000d
> > > Author: Thomas Zimmermann 
> > > Date:   Tue Jan 25 10:12:18 2022 +0100
> > > 
> > > fbdev: Hot-unplug firmware fb devices on forced removal
> > > 
> > > this should be fixed properly and we can remove this somewhat hackish
> > > check here (e.g. this won't catch drm drivers if fbdev emulation isn't
> > > enabled).
> > >
> > 
> > Unfortunately this hack can't be reverted yet. Thomas' patch solves the 
> > issue
> > of platform devices matched with fbdev drivers to be properly unregistered 
> > if
> > a DRM driver attempts to remove all the conflicting framebuffers.
> > 
> > But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers 
> > if
> > a FB is already registered") worked around is different. It happens when the
> > DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
> > kicking out of conflicting framebuffers already happened and these drivers
> > will be allowed to probe even when a DRM driver is already present.
> > 
> > We need a clearer way to prevent it, but can't revert fb561bf9abde until 
> > that.
> 
> Yeah that entire area is a mess still, ideally we'd have something else
> creating the platform devices, and efifb/offb and all these would just
> bind against them.
> 
> Hm one idea that just crossed my mind: Could we have a flag in fb_info for
> fw drivers, and check this in framebuffer_register? Then at least all the
> logic would be in the fbdev core.

Ok coffee just kicked in, how exactly does your scenario work?

This code I'm reverting here is in the platform_dev->probe function.
Thomas' patch removes the platform_dev. How exactly can you still probe
against a platform dev if that platform dev is gone?

Iow, now that I reponder your case after a few weeks I'm no longer sure
things work like you claim.

There is the issue that offb still bidns without a platform_dev, but
that's not affected by this patch here.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

[PATCH 5.16 0189/1017] drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB

[Greg Kroah-Hartman]

From: Thomas Zimmermann 

commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.

Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)

For shadow buffers, also set the FBINFO_READS_FAST hint.

v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag

Signed-off-by: Thomas Zimmermann 
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe 
function")
Reviewed-by: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_fb_helper.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = fb->height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
 
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
 
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
 
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
 
/*
 * Shamelessly leak the physical address to user-space. As

Re: [PATCH v2 09/19] fbcon: Extract fbcon_open/release helpers

[Daniel Vetter]

On Thu, Feb 10, 2022 at 12:46:32PM +0100, Thomas Zimmermann wrote:
> Hi
> 
> Am 08.02.22 um 22:08 schrieb Daniel Vetter:
> > There's two minor behaviour changes in here:
> > - in error paths we now consistently call fb_ops->fb_release
> > - fb_release really can't fail (fbmem.c ignores it too) and there's no
> >reasonable cleanup we can do anyway.
> > 
> > Note that everything in fbcon.c is protected by the big console_lock()
> > lock (especially all the global variables), so the minor changes in
> > ordering of setup/cleanup do not matter.
> > 
> > v2: Explain a bit better why this is all correct (Sam)
> > 
> > Acked-by: Sam Ravnborg 
> > Signed-off-by: Daniel Vetter 
> > Cc: Daniel Vetter 
> > Cc: Claudio Suarez 
> > Cc: Greg Kroah-Hartman 
> > Cc: Tetsuo Handa 
> > Cc: Du Cheng 
> > ---
> >   drivers/video/fbdev/core/fbcon.c | 107 +++
> >   1 file changed, 53 insertions(+), 54 deletions(-)
> > 
> > diff --git a/drivers/video/fbdev/core/fbcon.c 
> > b/drivers/video/fbdev/core/fbcon.c
> > index 058e885d24f6..3e1a3e7bf527 100644
> > --- a/drivers/video/fbdev/core/fbcon.c
> > +++ b/drivers/video/fbdev/core/fbcon.c
> > @@ -682,19 +682,37 @@ static int fbcon_invalid_charcount(struct fb_info 
> > *info, unsigned charcount)
> >   #endif /* CONFIG_MISC_TILEBLITTING */
> > +static int fbcon_open(struct fb_info *info)
> > +{
> > +   if (!try_module_get(info->fbops->owner))
> > +   return -ENODEV;
> > +
> > +   if (info->fbops->fb_open &&
> > +   info->fbops->fb_open(info, 0)) {
> > +   module_put(info->fbops->owner);
> > +   return -ENODEV;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> > +static void fbcon_release(struct fb_info *info)
> > +{
> > +   if (info->fbops->fb_release)
> > +   info->fbops->fb_release(info, 0);
> > +
> > +   module_put(info->fbops->owner);
> > +}
> >   static int con2fb_acquire_newinfo(struct vc_data *vc, struct fb_info 
> > *info,
> >   int unit, int oldidx)
> >   {
> > struct fbcon_ops *ops = NULL;
> > -   int err = 0;
> > -
> > -   if (!try_module_get(info->fbops->owner))
> > -   err = -ENODEV;
> > +   int err;
> > -   if (!err && info->fbops->fb_open &&
> > -   info->fbops->fb_open(info, 0))
> > -   err = -ENODEV;
> > +   err = fbcon_open(info);
> > +   if (err)
> > +   return err;
> > if (!err) {
> > ops = kzalloc(sizeof(struct fbcon_ops), GFP_KERNEL);
> > @@ -715,7 +733,7 @@ static int con2fb_acquire_newinfo(struct vc_data *vc, 
> > struct fb_info *info,
> > if (err) {
> > con2fb_map[unit] = oldidx;
> > -   module_put(info->fbops->owner);
> > +   fbcon_release(info);
> > }
> > return err;
> > @@ -726,45 +744,34 @@ static int con2fb_release_oldinfo(struct vc_data *vc, 
> > struct fb_info *oldinfo,
> >   int oldidx, int found)
> >   {
> > struct fbcon_ops *ops = oldinfo->fbcon_par;
> > -   int err = 0, ret;
> > +   int ret;
> > -   if (oldinfo->fbops->fb_release &&
> > -   oldinfo->fbops->fb_release(oldinfo, 0)) {
> > -   con2fb_map[unit] = oldidx;
> 
> We don't need oldidx any longer?
> 
> There's some logic wrt to the parameter 'found' here and in set_con2fb_map()
> that appears to be relevant.

Yeah further patches clean this up more. Or did you see a potential bug
here? I did ditch the fb_release error handling, simply because there's
not really much we can do anyway, it shouldn't ever fail (that's a driver
bug) and it was convoluting the code for no gain. But I might have missed
something in this cargo-cult.
-Daniel

> 
> Best regards
> Thomas
> 
> 
> > -   if (!found && newinfo->fbops->fb_release)
> > -   newinfo->fbops->fb_release(newinfo, 0);
> > -   if (!found)
> > -   module_put(newinfo->fbops->owner);
> > -   err = -ENODEV;
> > -   }
> > +   fbcon_release(oldinfo);
> > -   if (!err) {
> > -   fbcon_del_cursor_work(oldinfo);
> > -   kfree(ops->cursor_state.mask);
> > -   kfree(ops->cursor_data);
> > -   kfree(ops->cursor_src);
> > -   kfree(ops->fontbuffer);
> > -   kfree(oldinfo->fbcon_par);
> > -   oldinfo->fbcon_par = NULL;
> > -   module_put(oldinfo->fbops->owner);
> > -   /*
> > - If oldinfo and newinfo are driving the same hardware,
> > - the fb_release() method of oldinfo may attempt to
> > - restore the hardware state.  This will leave the
> > - newinfo in an undefined state. Thus, a call to
> > - fb_set_par() may be needed for the newinfo.
> > -   */
> > -   if (newinfo && newinfo->fbops->fb_set_par) {
> > -   ret = newinfo->fbops->fb_set_par(newinfo);
> > +   fbcon_del_cursor_work(oldinfo);
> > +   kfree(ops->cursor_state.mask);
> > +   kfree(ops->cursor_data);
> > +   kfree(ops->cursor_src);
> > +   kfree(ops->fontbuffer)

Re: [PATCH] fbdev: Fix unregistering of framebuffers without device

[Daniel Vetter]

On Mon, Apr 04, 2022 at 09:44:02PM +0200, Thomas Zimmermann wrote:
> OF framebuffers do not have an underlying device in the Linux
> device hierarchy. Do a regular unregister call instead of hot
> unplugging such a non-existing device. Fixes a NULL dereference.
> An example error message on ppc64le is shown below.
> 
>   BUG: Kernel NULL pointer dereference on read at 0x0060
>   Faulting instruction address: 0xc080dfa4
>   Oops: Kernel access of bad area, sig: 11 [#1]
>   LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>   [...]
>   CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
>   NIP:  c080dfa4 LR: c080df9c CTR: c0797430
>   REGS: c4132fe0 TRAP: 0300   Not tainted  (5.17.0-ae085d7f9365)
>   MSR:  82009033   CR: 28228282  XER: 
> 2000
>   CFAR: c000c80c DAR: 0060 DSISR: 4000 IRQMASK: 0
>   GPR00: c080df9c c4133280 c169d200 0029
>   GPR04: efff c4132f90 c4132f88 
>   GPR08: c15658f8 c15cd200 c14f57d0 48228283
>   GPR12:  c0003fffe300 2000 
>   GPR16:  000113fc4a40 0005 000113fcfb80
>   GPR20: 01000f7283b0  c0e4a588 c0e4a5b0
>   GPR24: 0001 000a c00800db0168 c21f6ec0
>   GPR28: c16d65a8 c4b36460  c16d64b0
>   NIP [c080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
>   [c4133280] [c080df9c] 
> do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
>   [c4133350] [c080e4d0] 
> remove_conflicting_framebuffers+0x60/0x150
>   [c41333a0] [c080e6f4] 
> remove_conflicting_pci_framebuffers+0x134/0x1b0
>   [c4133450] [c00800e70438] 
> drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
>   [c4133490] [c00800da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
>   [...]
>   [c4133db0] [c002aaa0] system_call_exception+0x170/0x2d0
>   [c4133e10] [c000c3cc] system_call_common+0xec/0x250
> 
> The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
> firmware fb devices on forced removal"). Most firmware framebuffers
> have an underlying platform device, which can be hot-unplugged
> before loading the native graphics driver. OF framebuffers do not
> (yet) have that device. Fix the code by unregistering the framebuffer
> as before without a hot unplug.
> 
> Tested with 5.17 on qemu ppc64le emulation.
> 
> Signed-off-by: Thomas Zimmermann 
> Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced 
> removal")
> Reported-by: Sudip Mukherjee 
> Cc: Zack Rusin 
> Cc: Javier Martinez Canillas 
> Cc: Hans de Goede 
> Cc: sta...@vger.kernel.org # v5.11+
> Cc: Helge Deller 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Zheyu Ma 
> Cc: Xiyu Yang 
> Cc: Zhen Lei 
> Cc: Matthew Wilcox 
> Cc: Alex Deucher 
> Cc: Tetsuo Handa 
> Cc: Guenter Roeck 
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
> ---
>  drivers/video/fbdev/core/fbmem.c | 9 -
>  1 file changed, 8 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/video/fbdev/core/fbmem.c 
> b/drivers/video/fbdev/core/fbmem.c
> index 34d6bb1bf82e..a6bb0e438216 100644
> --- a/drivers/video/fbdev/core/fbmem.c
> +++ b/drivers/video/fbdev/core/fbmem.c
> @@ -1579,7 +1579,14 @@ static void do_remove_conflicting_framebuffers(struct 
> apertures_struct *a,
>* If it's not a platform device, at least print a 
> warning. A
>* fix would add code to remove the device from the 
> system.
>*/
> - if (dev_is_platform(device)) {
> + if (!device) {
> + /* TODO: Represent each OF framebuffer as its 
> own
> +  * device in the device hierarchy. For now, offb
> +  * doesn't have such a device, so unregister the
> +  * framebuffer as before without warning.
> +  */
> + do_unregister_framebuffer(registered_fb[i]);

Reviewed-by: Daniel Vetter 

Might be good to have a fb_info flag for offb and then check in
register_framebuffer that everyone else does have a device? Just to make
sure we don't have more surprises here ...
-Daniel


> + } else if (dev_is_platform(device)) {
>   registered_fb[i]->forced_out = true;
>   
> platform_device_unregister(to_platform_device(device));
>   } else {
> -- 
> 2.35.1
> 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll

Re: [PATCH v9 20/23] drm/rockchip: Make VOP driver optional

[Sascha Hauer]

On Sat, Apr 02, 2022 at 09:25:33AM +0800, Andy Yan wrote:
> Hi Sascha:
> 
> On 4/1/22 20:55, Sascha Hauer wrote:
> > On Thu, Mar 31, 2022 at 07:00:34PM +0800, Andy Yan wrote:
> > > Hi:
> > > 
> > > On 3/31/22 16:18, Sascha Hauer wrote:
> > > > On Thu, Mar 31, 2022 at 03:20:37PM +0800, Andy Yan wrote:
> > > > > Hi Sascha:
> > > > > 
> > > > > On 3/31/22 15:06, Sascha Hauer wrote:
> > > > > > On Wed, Mar 30, 2022 at 08:50:09PM +0800, Andy Yan wrote:
> > > > > > > Hi Sascha:
> > > > > > > 
> > > > > > > On 3/30/22 14:39, Sascha Hauer wrote:
> > > > > > > > Hi Andy,
> > > > > > > > 
> > > > > > > > On Tue, Mar 29, 2022 at 07:56:27PM +0800, Andy Yan wrote:
> > > > > > > > > Hi Sascha:
> > > > > > > > > 
> > > > > > > > > On 3/28/22 23:11, Sascha Hauer wrote:
> > > > > > > > > > With upcoming VOP2 support VOP won't be the only choice 
> > > > > > > > > > anymore, so make
> > > > > > > > > > the VOP driver optional.
> > > > > > > > > > 
> > > > > > > > > > Signed-off-by: Sascha Hauer 
> > > > > > > > > > ---
> > > > > > > > > >   drivers/gpu/drm/rockchip/Kconfig| 8 
> > > > > > > > > > 
> > > > > > > > > >   drivers/gpu/drm/rockchip/Makefile   | 3 ++-
> > > > > > > > > >   drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 2 +-
> > > > > > > > > >   3 files changed, 11 insertions(+), 2 deletions(-)
> > > > > > > > > > 
> > > > > > > > > > diff --git a/drivers/gpu/drm/rockchip/Kconfig 
> > > > > > > > > > b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > index fa5cfda4e90e3..7d22e2997a571 100644
> > > > > > > > > > --- a/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > +++ b/drivers/gpu/drm/rockchip/Kconfig
> > > > > > > > > > @@ -23,8 +23,16 @@ config DRM_ROCKCHIP
> > > > > > > > > >   if DRM_ROCKCHIP
> > > > > > > > > > +config ROCKCHIP_VOP
> > > > > > > > > > +   bool "Rockchip VOP driver"
> > > > > > > > > > +   default y
> > > > > > > > > > +   help
> > > > > > > > > > + This selects support for the VOP driver. You should 
> > > > > > > > > > enable it
> > > > > > > > > > + on all older SoCs up to RK3399.
> > > > > > > > That reminds me that I wanted to rephrase this. Will change in 
> > > > > > > > next
> > > > > > > > round.
> > > > > > > > 
> > > > > > > > > > +
> > > > > > > > > >   config ROCKCHIP_ANALOGIX_DP
> > > > > > > > > > bool "Rockchip specific extensions for Analogix 
> > > > > > > > > > DP driver"
> > > > > > > > > > +   depends on ROCKCHIP_VOP
> > > > > > > > > Aanlogix dp is also on vop2 base soc such as  rk356x and 
> > > > > > > > > rk3588.
> > > > > > BTW I just looked at the downstream driver. Here we have the same
> > > > > > situation that the analogix dp driver calls 
> > > > > > rockchip_drm_wait_vact_end()
> > > > > > which is implemented in the VOP driver, so when the analogix dp 
> > > > > > driver
> > > > > > is actually used on a VOP2 SoC then it is either used in a way that
> > > > > > rockchip_drm_wait_vact_end() will never be called or it explodes in 
> > > > > > all
> > > > > > colours.
> > > > > > 
> > > > > > > > I added the dependency because analogix_dp-rockchip.c calls
> > > > > > > > rockchip_drm_wait_vact_end() which is implemented in the VOP 
> > > > > > > > driver,
> > > > > > > > so this driver currenty can't work with the VOP2 driver and 
> > > > > > > > can't
> > > > > > > > be linked without the VOP driver being present.
> > > > > > > > I'll add a few words to the commit message.
> > > > > > > Maybe a better direction is move rockchip_drm_wait_vact_end from 
> > > > > > > the VOP
> > > > > > > driver to rockchip_drm_drv.c
> > > > > > I am not sure if that's really worth it. Yes, the direction might 
> > > > > > be the
> > > > > > right one, but I would really prefer when somebody does the change 
> > > > > > who
> > > > > > can test and confirm that the analogix dp really works with VOP2 in 
> > > > > > the
> > > > > > end.
> > > > > If follow this point, the current DW_MIPI also has not been tested for
> > > > > confirm that it
> > > > > 
> > > > > can really work with VOP2, so you should also make it depends on
> > > > > ROCKCHIP_VOP.

Here you are suggesting to add even more Kconfig dependencies.

> > > > Well at least I have patches here which make DW_MIPI work with VOP2 ;)
> > > 
> > > But you DW_MIPI patches for rk356x didn't come. So this is not keep
> > > consistency with this point.
> > > 
> > > > What about the others, like LVDS and RGB?
> > > 
> > > Yes, we also have other interface , RK356X has LVDS/RGB/BT1120/BT656, 
> > > RK3588
> > > has BT1120/BT656, no LVDS or RGB.
> > > 
> > > > > I think the current solution is just a workaround to make your patch 
> > > > > pass
> > > > > the kernel compile
> > > > Indeed.
> > > > 
> > > > I agree that it would be good to add a note somewhere which outputs
> > > > work with the VOP2 driver (currently only HDMI), but I wonder if Kconfig
> > > > dependencies is the right place for it, because only people who 
> > > > deliberately
> > > >

[PATCH] drm/amdkfd: Fix potential NULL pointer dereference

[Grigory Vasilyev]

In the amdgpu_amdkfd_get_xgmi_bandwidth_mbytes function,
the peer_adev pointer can be NULL and is passed to amdgpu_xgmi_get_num_links.

In amdgpu_xgmi_get_num_links, peer_adev pointer is dereferenced
without any checks: peer_adev->gmc.xgmi.node_id .

Signed-off-by: Grigory Vasilyev 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
index be1a55f8b8c5..1a1006b18016 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
@@ -541,11 +541,10 @@ int amdgpu_amdkfd_get_xgmi_bandwidth_mbytes(struct 
amdgpu_device *dst,
struct amdgpu_device *adev = dst, *peer_adev;
int num_links;
 
-   if (adev->asic_type != CHIP_ALDEBARAN)
+   if (!src || adev->asic_type != CHIP_ALDEBARAN)
return 0;
 
-   if (src)
-   peer_adev = src;
+   peer_adev = src;
 
/* num links returns 0 for indirect peers since indirect route is 
unknown. */
num_links = is_min ? 1 : amdgpu_xgmi_get_num_links(adev, peer_adev);
-- 
2.35.1

[PATCH] drm/amdgpu: Junk code

[Grigory Vasilyev]

Variable igp_lane_info always is 0. 0 & any value = 0 and false.
In this way, all сonditional statements will false.
Therefore, it is not clear what this code does.

Signed-off-by: Grigory Vasilyev 
---
 .../gpu/drm/amd/amdgpu/atombios_encoders.c| 21 ---
 1 file changed, 21 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
index 2b0cc793291c..100bad2f5901 100644
--- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
+++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
@@ -769,7 +769,6 @@ amdgpu_atombios_encoder_setup_dig_transmitter(struct 
drm_encoder *encoder, int a
int dp_clock = 0;
int dp_lane_count = 0;
int connector_object_id = 0;
-   int igp_lane_info = 0;
int dig_encoder = dig->dig_encoder;
int hpd_id = AMDGPU_HPD_NONE;
 
@@ -852,26 +851,6 @@ amdgpu_atombios_encoder_setup_dig_transmitter(struct 
drm_encoder *encoder, int a
else
args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
 
-   if ((adev->flags & AMD_IS_APU) &&
-   (amdgpu_encoder->encoder_id == 
ENCODER_OBJECT_ID_INTERNAL_UNIPHY)) {
-   if (is_dp ||
-   !amdgpu_dig_monitor_is_duallink(encoder, 
amdgpu_encoder->pixel_clock)) {
-   if (igp_lane_info & 0x1)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_0_3;
-   else if (igp_lane_info & 0x2)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_4_7;
-   else if (igp_lane_info & 0x4)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_8_11;
-   else if (igp_lane_info & 0x8)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_12_15;
-   } else {
-   if (igp_lane_info & 0x3)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_0_7;
-   else if (igp_lane_info & 0xc)
-   args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LANE_8_15;
-   }
-   }
-
if (dig->linkb)
args.v1.ucConfig |= 
ATOM_TRANSMITTER_CONFIG_LINKB;
else
-- 
2.35.1

[PATCH 5.16 0816/1017] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

[Greg Kroah-Hartman]

From: Tim Gardner 

[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]

Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.

Cc: Antonino Daplas 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c 
b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, 
const char *name,
 {
int rc;
 
-   strcpy(chan->adapter.name, name);
+   strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
-- 
2.34.1

Re: [PATCH] dt-bindings: display: panel: mipi-dbi-spi: Make width-mm/height-mm mandatory

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Mon, Apr 04, 2022 at 09:21:05PM +0200, Marek Vasut wrote:
> Make the width-mm/height-mm panel properties mandatory
> to correctly report the panel dimensions to the OS.
> 
> Fixes: 2f3468b82db97 ("dt-bindings: display: add bindings for MIPI DBI 
> compatible SPI panels")
> Signed-off-by: Marek Vasut 
> Cc: Christoph Niedermaier 
> Cc: Daniel Vetter 
> Cc: Dmitry Osipenko 
> Cc: Laurent Pinchart 
> Cc: Noralf Trønnes 
> Cc: Rob Herring 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: Thomas Zimmermann 
> Cc: devicet...@vger.kernel.org
> To: dri-devel@lists.freedesktop.org

Reviewed-by: Laurent Pinchart 

> ---
>  .../devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml   | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml 
> b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> index f29789994b180..c2df8d28aaf5f 100644
> --- a/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> +++ b/Documentation/devicetree/bindings/display/panel/panel-mipi-dbi-spi.yaml
> @@ -83,6 +83,8 @@ properties:
>  required:
>- compatible
>- reg
> +  - width-mm
> +  - height-mm
>- panel-timing
>  
>  unevaluatedProperties: false

-- 
Regards,

Laurent Pinchart

[PATCH 5.16 0871/1017] drm/dp: Fix off-by-one in register cache size

[Greg Kroah-Hartman]

From: Kees Cook 

commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.

The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside 
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'} 
[-Werror=array-bounds]
 3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
  |   ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
 3126 | int drm_dp_pcon_dsc_bpp_incr(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
  |  
~^~~

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for 
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva 
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman 
---
 include/drm/drm_dp_helper.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -456,7 +456,7 @@ struct drm_panel;
 #define DP_FEC_CAPABILITY_10x091   /* 2.0 */
 
 /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
 #define DP_PCON_DSC_ENCODER 0x092
 # define DP_PCON_DSC_ENCODER_SUPPORTED  (1 << 0)
 # define DP_PCON_DSC_PPS_ENC_OVERRIDE   (1 << 1)

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Javier Martinez Canillas]

Hello Daniel,

On 4/5/22 10:40, Daniel Vetter wrote:
> On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
>> On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
>>> On 2/8/22 22:08, Daniel Vetter wrote:
 This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.

 With

 commit 27599aacbaefcbf2af7b06b0029459bbf682000d
 Author: Thomas Zimmermann 
 Date:   Tue Jan 25 10:12:18 2022 +0100

 fbdev: Hot-unplug firmware fb devices on forced removal

 this should be fixed properly and we can remove this somewhat hackish
 check here (e.g. this won't catch drm drivers if fbdev emulation isn't
 enabled).

>>>
>>> Unfortunately this hack can't be reverted yet. Thomas' patch solves the 
>>> issue
>>> of platform devices matched with fbdev drivers to be properly unregistered 
>>> if
>>> a DRM driver attempts to remove all the conflicting framebuffers.
>>>
>>> But the problem that fb561bf9abde ("fbdev: Prevent probing generic drivers 
>>> if
>>> a FB is already registered") worked around is different. It happens when the
>>> DRM driver is probed before the {efi,simple}fb and other fbdev drivers, the
>>> kicking out of conflicting framebuffers already happened and these drivers
>>> will be allowed to probe even when a DRM driver is already present.
>>>
>>> We need a clearer way to prevent it, but can't revert fb561bf9abde until 
>>> that.
>>
>> Yeah that entire area is a mess still, ideally we'd have something else
>> creating the platform devices, and efifb/offb and all these would just
>> bind against them.
>>
>> Hm one idea that just crossed my mind: Could we have a flag in fb_info for
>> fw drivers, and check this in framebuffer_register? Then at least all the
>> logic would be in the fbdev core.
>

I can't answer right away since I've since forgotten this part of the code
and will require to do a detailed read to refresh my memory.

I'll answer later but preferred to mention the other question ASAP.
 
> Ok coffee just kicked in, how exactly does your scenario work?
> 
> This code I'm reverting here is in the platform_dev->probe function.
> Thomas' patch removes the platform_dev. How exactly can you still probe
> against a platform dev if that platform dev is gone?
>

Because the platform was not even registered by the time the DRM driver
probed and all the devices for the conflicting drivers were unregistered.
 
> Iow, now that I reponder your case after a few weeks I'm no longer sure
> things work like you claim.
>

This is how I think that work, please let me know if you see something
wrong in my logic:

1) A PCI device of OF device is registered for the GPU, this attempt to
   match a registered driver but no driver was registered that match yet.

2) The efifb driver is built-in, will be initialized according to the link
   order of the objects under drivers/video and the fbdev driver is registered.

   There is no platform device or PCI/OF device registered that matches.

3) The DRM driver is built-in, will be initialized according to the link
   order of the objects under drivers/gpu and the DRM driver is registered.
   
   This matches the device registered in (1) and the DRM driver probes.

4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
   before registering the DRM device.

   There are no conflicting drivers or platform device at this point.

5) Latter at some point the drivers/firmware/sysfb.c init function is
   executed, and this registers a platform device for the generic fb.

   This device matches the efifb driver registered in (2) and the fbdev
   driver probes.
   
   Since that happens *after* the DRM driver already matched, probed
   and registered the DRM device, that is a bug and what the reverted
   patch worked around.

So we need to prevent (5) if (1) and (3) already happened. Having a flag
set in the fbdev core somewhere when remove_conflicting_framebuffers()
is called could be a solution indeed.

That is, the fbdev core needs to know that a DRM driver already probed
and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE

I can attempt to write a patch for that.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Daniel Vetter]

On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
 wrote:
>
> Hello Daniel,
>
> On 4/5/22 10:40, Daniel Vetter wrote:
> > On Tue, Apr 05, 2022 at 10:36:35AM +0200, Daniel Vetter wrote:
> >> On Wed, Feb 09, 2022 at 01:19:26AM +0100, Javier Martinez Canillas wrote:
> >>> On 2/8/22 22:08, Daniel Vetter wrote:
>  This reverts commit fb561bf9abde49f7e00fdbf9ed2ccf2d86cac8ee.
> 
>  With
> 
>  commit 27599aacbaefcbf2af7b06b0029459bbf682000d
>  Author: Thomas Zimmermann 
>  Date:   Tue Jan 25 10:12:18 2022 +0100
> 
>  fbdev: Hot-unplug firmware fb devices on forced removal
> 
>  this should be fixed properly and we can remove this somewhat hackish
>  check here (e.g. this won't catch drm drivers if fbdev emulation isn't
>  enabled).
> 
> >>>
> >>> Unfortunately this hack can't be reverted yet. Thomas' patch solves the 
> >>> issue
> >>> of platform devices matched with fbdev drivers to be properly 
> >>> unregistered if
> >>> a DRM driver attempts to remove all the conflicting framebuffers.
> >>>
> >>> But the problem that fb561bf9abde ("fbdev: Prevent probing generic 
> >>> drivers if
> >>> a FB is already registered") worked around is different. It happens when 
> >>> the
> >>> DRM driver is probed before the {efi,simple}fb and other fbdev drivers, 
> >>> the
> >>> kicking out of conflicting framebuffers already happened and these drivers
> >>> will be allowed to probe even when a DRM driver is already present.
> >>>
> >>> We need a clearer way to prevent it, but can't revert fb561bf9abde until 
> >>> that.
> >>
> >> Yeah that entire area is a mess still, ideally we'd have something else
> >> creating the platform devices, and efifb/offb and all these would just
> >> bind against them.
> >>
> >> Hm one idea that just crossed my mind: Could we have a flag in fb_info for
> >> fw drivers, and check this in framebuffer_register? Then at least all the
> >> logic would be in the fbdev core.
> >
>
> I can't answer right away since I've since forgotten this part of the code
> and will require to do a detailed read to refresh my memory.
>
> I'll answer later but preferred to mention the other question ASAP.
>
> > Ok coffee just kicked in, how exactly does your scenario work?
> >
> > This code I'm reverting here is in the platform_dev->probe function.
> > Thomas' patch removes the platform_dev. How exactly can you still probe
> > against a platform dev if that platform dev is gone?
> >
>
> Because the platform was not even registered by the time the DRM driver
> probed and all the devices for the conflicting drivers were unregistered.
>
> > Iow, now that I reponder your case after a few weeks I'm no longer sure
> > things work like you claim.
> >
>
> This is how I think that work, please let me know if you see something
> wrong in my logic:
>
> 1) A PCI device of OF device is registered for the GPU, this attempt to
>match a registered driver but no driver was registered that match yet.
>
> 2) The efifb driver is built-in, will be initialized according to the link
>order of the objects under drivers/video and the fbdev driver is 
> registered.
>
>There is no platform device or PCI/OF device registered that matches.
>
> 3) The DRM driver is built-in, will be initialized according to the link
>order of the objects under drivers/gpu and the DRM driver is registered.
>
>This matches the device registered in (1) and the DRM driver probes.
>
> 4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
>before registering the DRM device.
>
>There are no conflicting drivers or platform device at this point.
>
> 5) Latter at some point the drivers/firmware/sysfb.c init function is
>executed, and this registers a platform device for the generic fb.
>
>This device matches the efifb driver registered in (2) and the fbdev
>driver probes.
>
>Since that happens *after* the DRM driver already matched, probed
>and registered the DRM device, that is a bug and what the reverted
>patch worked around.
>
> So we need to prevent (5) if (1) and (3) already happened. Having a flag
> set in the fbdev core somewhere when remove_conflicting_framebuffers()
> is called could be a solution indeed.
>
> That is, the fbdev core needs to know that a DRM driver already probed
> and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
>
> I can attempt to write a patch for that.

Ah yeah that could be an issue. I think the right fix is to replace
the platform dev unregister with a sysfb_unregister() function in
sysfb.c, which is synced with a common lock with the sysfb_init
function and a small boolean. I think I can type that up quickly for
v3.
-Daniel

>
> --
> Best regards,
>
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH 23/23] drm/ttm: remove bo->moving

[Christian König]

Am 29.03.22 um 18:02 schrieb Daniel Vetter:

On Mon, Mar 21, 2022 at 02:58:56PM +0100, Christian König wrote:
[SNIP]

  static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
index f999fdd927df..c6d02c98a19a 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
@@ -1163,12 +1163,6 @@ int vmw_resources_clean(struct vmw_buffer_object *vbo, 
pgoff_t start,
*num_prefault = __KERNEL_DIV_ROUND_UP(last_cleaned - res_start,
  PAGE_SIZE);
vmw_bo_fence_single(bo, NULL);
-   if (bo->moving)
-   dma_fence_put(bo->moving);
-
-   return dma_resv_get_singleton(bo->base.resv,
- DMA_RESV_USAGE_KERNEL,
- &bo->moving);

This seems to be entirely misplaced and I'm pretty sure doesn't even
compile interim.


Mhm, removing that is correctly placed as far as I can see.

What VMWGFX does here is to update bo->moving to please TTM, but since 
we now drop the bo->moving fence from TTM and always wait for all fences 
with DMA_RESV_USAGE_KERNEL before allowing CPU access that workaround 
isn't necessary any more.



}
  
  	return 0;

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index c17b2df9178b..4c7134550262 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -97,7 +97,6 @@ struct ttm_tt;
   * @lru: List head for the lru list.
   * @ddestroy: List head for the delayed destroy list.
   * @swap: List head for swap LRU list.
- * @moving: Fence set when BO is moving
   * @offset: The current GPU offset, which can have different meanings
   * depending on the memory type. For SYSTEM type memory, it should be 0.
   * @cur_placement: Hint of current placement.
@@ -150,7 +149,6 @@ struct ttm_buffer_object {
 * Members protected by a bo reservation.
 */
  
-	struct dma_fence *moving;

unsigned priority;
unsigned pin_count;

Aside from the vmwgfx thing this looks good. With the vmwgfx patch split
issue (I think it's just that) fixed:

Reviewed-by: Daniel Vetter 


Is it enough if I explain why we update VMWGFX in the commit message?

Thanks,
Christian.



  
--

2.25.1

[PATCH 5.15 178/913] drm/fb-helper: Mark screen buffers in system memory with FBINFO_VIRTFB

[Greg Kroah-Hartman]

From: Thomas Zimmermann 

commit cd9f7f7ac5932129fe81b4c7559cfcb226ec7c5c upstream.

Mark screen buffers in system memory with FBINFO_VIRTFB. Otherwise, fbdev
deferred I/O marks mmap'ed areas of system memory with VM_IO. (There's an
inverse relationship between the two flags.)

For shadow buffers, also set the FBINFO_READS_FAST hint.

v3:
* change FB_ to FBINFO_ in commit description
v2:
* updated commit description (Daniel)
* added Fixes tag

Signed-off-by: Thomas Zimmermann 
Fixes: d536540f304c ("drm/fb-helper: Add generic fbdev emulation .fb_probe 
function")
Reviewed-by: Daniel Vetter 
Cc: dri-devel@lists.freedesktop.org
Cc:  # v4.19+
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220201115305.9333-1-tzimmerm...@suse.de
Signed-off-by: Greg Kroah-Hartman 
---
 drivers/gpu/drm/drm_fb_helper.c |9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

--- a/drivers/gpu/drm/drm_fb_helper.c
+++ b/drivers/gpu/drm/drm_fb_helper.c
@@ -2346,6 +2346,7 @@ static int drm_fb_helper_generic_probe(s
fbi->fbops = &drm_fbdev_fb_ops;
fbi->screen_size = fb->height * fb->pitches[0];
fbi->fix.smem_len = fbi->screen_size;
+   fbi->flags = FBINFO_DEFAULT;
 
drm_fb_helper_fill_info(fbi, fb_helper, sizes);
 
@@ -2353,19 +2354,21 @@ static int drm_fb_helper_generic_probe(s
fbi->screen_buffer = vzalloc(fbi->screen_size);
if (!fbi->screen_buffer)
return -ENOMEM;
+   fbi->flags |= FBINFO_VIRTFB | FBINFO_READS_FAST;
 
fbi->fbdefio = &drm_fbdev_defio;
-
fb_deferred_io_init(fbi);
} else {
/* buffer is mapped for HW framebuffer */
ret = drm_client_buffer_vmap(fb_helper->buffer, &map);
if (ret)
return ret;
-   if (map.is_iomem)
+   if (map.is_iomem) {
fbi->screen_base = map.vaddr_iomem;
-   else
+   } else {
fbi->screen_buffer = map.vaddr;
+   fbi->flags |= FBINFO_VIRTFB;
+   }
 
/*
 * Shamelessly leak the physical address to user-space. As

Re: [PATCH v9 00/23] drm/rockchip: RK356x VOP2 support

[Sascha Hauer]

On Sat, Apr 02, 2022 at 09:37:17AM +0800, Andy Yan wrote:
> Hi Sacha:
> 
> On 4/1/22 20:52, Sascha Hauer wrote:
> > -- 
> > >From cbc03073623a7180243331ac24c3afaf9dec7522 Mon Sep 17 00:00:00 2001
> > From: Sascha Hauer
> > Date: Fri, 1 Apr 2022 14:48:49 +0200
> > Subject: [PATCH] fixup! drm: rockchip: Add VOP2 driver
> > 
> > ---
> >   drivers/gpu/drm/rockchip/rockchip_drm_vop2.c | 14 ++
> >   1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c 
> > b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > index 7dba7b9b63dc6..1421bf2f133f1 100644
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop2.c
> > @@ -2287,6 +2287,20 @@ static int vop2_create_crtc(struct vop2 *vop2)
> > }
> > }
> > +   if (vop2->data->soc_id == 3566) {
> > +   /*
> > +* On RK3566 these windows don't have an independent
> > +* framebuffer. They share the framebuffer with smart0,
> > +* esmart0 and cluster0 respectively.
> > +*/
> > +   switch (win->data->phys_id) {
> > +   case ROCKCHIP_VOP2_SMART1:
> > +   case ROCKCHIP_VOP2_ESMART1:
> > +   case ROCKCHIP_VOP2_CLUSTER1:
> > +   continue;
> > +   }
> 
> 
> Think about this , there maybe other upcoming vop2 base soc, they may only
> have
> 
> mirror window Smart1 Esmart1, or Smart1, Esmart1, Esmart2, Cluster1.
> 
> I think this should add WIN_FEATURE at the platform description file
> rockchip_vop2_reg.c, then
> 
> check the FEATURE to decide whether the driver should give this window a
> special treatment.
> 
> this can make one code run for different soc with different platform
> description. or we should add
> 
> the same code logic for different soc again and again.

You mean like done in the downstream Kernel? Here indeed we have a
WIN_FEATURE_MIRROR flag added to the platform description. This is then
evaluated with:

static bool vop2_is_mirror_win(struct vop2_win *win)
{
return soc_is_rk3566() && (win->feature & WIN_FEATURE_MIRROR);
}

So a flag is added and afterwards its evaluation is SoC specific. That
doesn't help at all and only obfuscates things.

Besides, experience shows that you can't predict a good abstraction for
future hardware revisions, the hardware guys are just too creative in
creating hardware that breaks existing abstractions.

Sascha

-- 
Pengutronix e.K.   | |
Steuerwalder Str. 21   | http://www.pengutronix.de/  |
31137 Hildesheim, Germany  | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH] i2c: at91: use dma safe buffers

[Michael Walle]

Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:

On 03.03.2022 18:17, Michael Walle wrote:
EXTERNAL EMAIL: Do not click links or open attachments unless you know 
the content is safe


The supplied buffer might be on the stack and we get the following 
error

message:
[3.312058] at91_i2c e0070600.i2c: rejecting DMA map of vmalloc 
memory


Use i2c_{get,put}_dma_safe_msg_buf() to get a DMA-able memory region 
if

necessary.

Cc: sta...@vger.kernel.org
Signed-off-by: Michael Walle 


Reviewed-by: Codrin Ciubotariu 


Thanks!

I'm not sure if or which Fixes: tag I should add to this patch. The 
issue
seems to be since a very long time, but nobody seem to have triggered 
it.

FWIW, I'm using the sff,sfp driver, which triggers this.


I think it should be:
Fixes: 60937b2cdbf9 ("i2c: at91: add dma support")


+   if (dev->use_dma) {
+   dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);


If you want, you could just dev->buf = i2c_get_dma_safe...


But where is the error handling in that case? dev->buf will
be NULL, which is eventually passed to dma_map_single().

Also, I need the dma_buf for the i2c_put_dma_safe_msg_buf()
call anyway, because dev->buf will be modified during
processing.

-michael

Re: [PATCH v7 3/9] drm/i915/gt: Optimize the migration and clear loop

[Balasubramani Vivekanandan]

On 01.04.2022 18:07, Ramalingam C wrote:
> Move the static calculations out of the loops for copy and clear.
> 
> Signed-off-by: Ramalingam C 
> Reviewed-by: Thomas Hellstrom 
> ---
>  drivers/gpu/drm/i915/gt/intel_migrate.c | 40 -
>  1 file changed, 19 insertions(+), 21 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
> b/drivers/gpu/drm/i915/gt/intel_migrate.c
> index e81f20266f62..580b4cf1efa2 100644
> --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> @@ -526,6 +526,7 @@ intel_context_migrate_copy(struct intel_context *ce,
>  struct i915_request **out)
>  {
>   struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst);
> + u32 src_offset, dst_offset;
>   struct i915_request *rq;
>   int err;
>  
> @@ -535,8 +536,18 @@ intel_context_migrate_copy(struct intel_context *ce,
>  
>   GEM_BUG_ON(ce->ring->size < SZ_64K);
>  
> + src_offset = 0;
> + dst_offset = CHUNK_SZ;
> + if (HAS_64K_PAGES(ce->engine->i915)) {
> + src_offset = 0;
> + dst_offset = 0;
> + if (src_is_lmem)
> + src_offset = CHUNK_SZ;
> + if (dst_is_lmem)
> + dst_offset = 2 * CHUNK_SZ;
> + }
> +
>   do {
> - u32 src_offset, dst_offset;
>   int len;
>  
>   rq = i915_request_create(ce);
> @@ -564,17 +575,6 @@ intel_context_migrate_copy(struct intel_context *ce,
>   if (err)
>   goto out_rq;
>  
> - src_offset = 0;
> - dst_offset = CHUNK_SZ;
> - if (HAS_64K_PAGES(ce->engine->i915)) {
> - src_offset = 0;
> - dst_offset = 0;
> - if (src_is_lmem)
> - src_offset = CHUNK_SZ;
> - if (dst_is_lmem)
> - dst_offset = 2 * CHUNK_SZ;
> - }
> -
>   len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
>  src_offset, CHUNK_SZ);
>   if (len <= 0) {
> @@ -584,12 +584,10 @@ intel_context_migrate_copy(struct intel_context *ce,
>  
>   err = emit_pte(rq, &it_dst, dst_cache_level, dst_is_lmem,
>  dst_offset, len);
> - if (err < 0)
> - goto out_rq;
> - if (err < len) {
> + if (err < len)
>   err = -EINVAL;
> + if (err < 0)
>   goto out_rq;
> - }
did you take a look at my comment at 
https://patchwork.freedesktop.org/patch/479847/?series=101106&rev=6?
Above change looks like a regression, can you check again?

Regards,
Bala

>  
>   err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
>   if (err)
> @@ -690,6 +688,7 @@ intel_context_migrate_clear(struct intel_context *ce,
>  {
>   struct sgt_dma it = sg_sgt(sg);
>   struct i915_request *rq;
> + u32 offset;
>   int err;
>  
>   GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
> @@ -697,8 +696,11 @@ intel_context_migrate_clear(struct intel_context *ce,
>  
>   GEM_BUG_ON(ce->ring->size < SZ_64K);
>  
> + offset = 0;
> + if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
> + offset = CHUNK_SZ;
> +
>   do {
> - u32 offset;
>   int len;
>  
>   rq = i915_request_create(ce);
> @@ -726,10 +728,6 @@ intel_context_migrate_clear(struct intel_context *ce,
>   if (err)
>   goto out_rq;
>  
> - offset = 0;
> - if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
> - offset = CHUNK_SZ;
> -
>   len = emit_pte(rq, &it, cache_level, is_lmem, offset, CHUNK_SZ);
>   if (len <= 0) {
>   err = len;
> -- 
> 2.20.1
> 

[PATCH 5.15 737/913] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

[Greg Kroah-Hartman]

From: Tim Gardner 

[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]

Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.

Cc: Antonino Daplas 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c 
b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, 
const char *name,
 {
int rc;
 
-   strcpy(chan->adapter.name, name);
+   strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
-- 
2.34.1

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Javier Martinez Canillas]

On 4/5/22 11:24, Daniel Vetter wrote:
> On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas

[snip]

>>
>> This is how I think that work, please let me know if you see something
>> wrong in my logic:
>>
>> 1) A PCI device of OF device is registered for the GPU, this attempt to
>>match a registered driver but no driver was registered that match yet.
>>
>> 2) The efifb driver is built-in, will be initialized according to the link
>>order of the objects under drivers/video and the fbdev driver is 
>> registered.
>>
>>There is no platform device or PCI/OF device registered that matches.
>>
>> 3) The DRM driver is built-in, will be initialized according to the link
>>order of the objects under drivers/gpu and the DRM driver is registered.
>>
>>This matches the device registered in (1) and the DRM driver probes.
>>
>> 4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
>>before registering the DRM device.
>>
>>There are no conflicting drivers or platform device at this point.
>>
>> 5) Latter at some point the drivers/firmware/sysfb.c init function is
>>executed, and this registers a platform device for the generic fb.
>>
>>This device matches the efifb driver registered in (2) and the fbdev
>>driver probes.
>>
>>Since that happens *after* the DRM driver already matched, probed
>>and registered the DRM device, that is a bug and what the reverted
>>patch worked around.
>>
>> So we need to prevent (5) if (1) and (3) already happened. Having a flag
>> set in the fbdev core somewhere when remove_conflicting_framebuffers()
>> is called could be a solution indeed.
>>
>> That is, the fbdev core needs to know that a DRM driver already probed
>> and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
>>
>> I can attempt to write a patch for that.
> 
> Ah yeah that could be an issue. I think the right fix is to replace
> the platform dev unregister with a sysfb_unregister() function in
> sysfb.c, which is synced with a common lock with the sysfb_init
> function and a small boolean. I think I can type that up quickly for
> v3.

It's more complicated than that since sysfb is just *one* of the several
places where platform devices can be registered for video devices.

For instance, the vga16fb driver registers its own platform device in
its module_init() function so that can also happen after the conflicting
framebuffers (and associated devices) were removed by a DRM driver probe.

I tried to minimize the issue for that particular driver with commit:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f

But the point stands, it all boils down to the fact that you have two
different subsystems registering video drivers and they don't know all
about each other to take a proper decision.

Right now the drm_aperture_remove_conflicting_framebuffers() call signals
in one direction from DRM to fbdev but there isn't a communication in the
other direction, from fbdev to DRM.

I believe the correct fix would be for the fbdev core to keep a list of
the apertures struct that are passed to remove_conflicting_framebuffers(),
that way it will know what apertures are not available anymore and prevent
to register any fbdev framebuffer that conflicts with one already present.

Let me know if you think that makes sense and I can attempt to write a fix.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH 5.15 783/913] drm/dp: Fix off-by-one in register cache size

[Greg Kroah-Hartman]

From: Kees Cook 

commit d4da1f27396fb1dde079447a3612f4f512caed07 upstream.

The pcon_dsc_dpcd array holds 13 registers (0x92 through 0x9E). Fix the
math to calculate the max size. Found from a -Warray-bounds build:

drivers/gpu/drm/drm_dp_helper.c: In function 'drm_dp_pcon_dsc_bpp_incr':
drivers/gpu/drm/drm_dp_helper.c:3130:28: error: array subscript 12 is outside 
array bounds of 'const u8[12]' {aka 'const unsigned char[12]'} 
[-Werror=array-bounds]
 3130 | buf = pcon_dsc_dpcd[DP_PCON_DSC_BPP_INCR - DP_PCON_DSC_ENCODER];
  |   ~^~~~
drivers/gpu/drm/drm_dp_helper.c:3126:39: note: while referencing 'pcon_dsc_dpcd'
 3126 | int drm_dp_pcon_dsc_bpp_incr(const u8 
pcon_dsc_dpcd[DP_PCON_DSC_ENCODER_CAP_SIZE])
  |  
~^~~

Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: David Airlie 
Cc: dri-devel@lists.freedesktop.org
Fixes: e2e16da398d9 ("drm/dp_helper: Add support for Configuring DSC for 
HDMI2.1 Pcon")
Cc: sta...@vger.kernel.org
Reviewed-by: Gustavo A. R. Silva 
Link: https://lore.kernel.org/lkml/20211214001849.GA62559@embeddedor/
Signed-off-by: Kees Cook 
Link: https://lore.kernel.org/r/20220105173310.2420598-1-keesc...@chromium.org
Signed-off-by: Thierry Reding 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20220225035610.2552144-2-keesc...@chromium.org
Signed-off-by: Greg Kroah-Hartman 
---
 include/drm/drm_dp_helper.h |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -455,7 +455,7 @@ struct drm_panel;
 # define DP_FEC_BIT_ERROR_COUNT_CAP(1 << 3)
 
 /* DP-HDMI2.1 PCON DSC ENCODER SUPPORT */
-#define DP_PCON_DSC_ENCODER_CAP_SIZE0xC/* 0x9E - 0x92 */
+#define DP_PCON_DSC_ENCODER_CAP_SIZE0xD/* 0x92 through 0x9E */
 #define DP_PCON_DSC_ENCODER 0x092
 # define DP_PCON_DSC_ENCODER_SUPPORTED  (1 << 0)
 # define DP_PCON_DSC_PPS_ENC_OVERRIDE   (1 << 1)

Re: [PATCH v7 3/9] drm/i915/gt: Optimize the migration and clear loop

[Ramalingam C]

On 2022-03-29 at 18:53:42 +0530, Balasubramani Vivekanandan wrote:
> On 29.03.2022 00:37, Ramalingam C wrote:
> > Move the static calculations out of the loops for copy and clear.
> > 
> > Signed-off-by: Ramalingam C 
> > Reviewed-by: Thomas Hellström 
> > ---
> >  drivers/gpu/drm/i915/gt/intel_migrate.c | 44 -
> >  1 file changed, 21 insertions(+), 23 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
> > b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > index 17dd372a47d1..ec9a9e7cb388 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_migrate.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
> > @@ -526,6 +526,7 @@ intel_context_migrate_copy(struct intel_context *ce,
> >struct i915_request **out)
> >  {
> > struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst);
> > +   u32 src_offset, dst_offset;
> > struct i915_request *rq;
> > int err;
> >  
> > @@ -534,8 +535,20 @@ intel_context_migrate_copy(struct intel_context *ce,
> >  
> > GEM_BUG_ON(ce->ring->size < SZ_64K);
> >  
> > +   src_offset = 0;
> > +   dst_offset = CHUNK_SZ;
> > +   if (HAS_64K_PAGES(ce->engine->i915)) {
> > +   GEM_BUG_ON(!src_is_lmem && !dst_is_lmem);
> > +
> > +   src_offset = 0;
> > +   dst_offset = 0;
> > +   if (src_is_lmem)
> > +   src_offset = CHUNK_SZ;
> > +   if (dst_is_lmem)
> > +   dst_offset = 2 * CHUNK_SZ;
> > +   }
> > +
> > do {
> > -   u32 src_offset, dst_offset;
> > int len;
> >  
> > rq = i915_request_create(ce);
> > @@ -563,19 +576,6 @@ intel_context_migrate_copy(struct intel_context *ce,
> > if (err)
> > goto out_rq;
> >  
> > -   src_offset = 0;
> > -   dst_offset = CHUNK_SZ;
> > -   if (HAS_64K_PAGES(ce->engine->i915)) {
> > -   GEM_BUG_ON(!src_is_lmem && !dst_is_lmem);
> > -
> > -   src_offset = 0;
> > -   dst_offset = 0;
> > -   if (src_is_lmem)
> > -   src_offset = CHUNK_SZ;
> > -   if (dst_is_lmem)
> > -   dst_offset = 2 * CHUNK_SZ;
> > -   }
> > -
> > len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
> >src_offset, CHUNK_SZ);
> > if (len <= 0) {
> > @@ -585,12 +585,10 @@ intel_context_migrate_copy(struct intel_context *ce,
> >  
> > err = emit_pte(rq, &it_dst, dst_cache_level, dst_is_lmem,
> >dst_offset, len);
> > -   if (err < 0)
> > -   goto out_rq;
> > -   if (err < len) {
> > +   if (err < len)
> > err = -EINVAL;
> > +   if (err < 0)
> > goto out_rq;
> > -   }
> With this change, for the case 0 < err < len, now the code does not
> reach `goto out_rq`.

With this change, flow will land into out_rq for all err < len.
But just now i am noticing we are overwriding all error code with
-EINVAL. I will fix that.

Ram.
> Is it the expected behavior? If yes, can you please add some details
> regarding this change in the commit description.
> 
> Regards,
> Bala
> >  
> > err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
> > if (err)
> > @@ -691,6 +689,7 @@ intel_context_migrate_clear(struct intel_context *ce,
> >  {
> > struct sgt_dma it = sg_sgt(sg);
> > struct i915_request *rq;
> > +   u32 offset;
> > int err;
> >  
> > GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
> > @@ -698,8 +697,11 @@ intel_context_migrate_clear(struct intel_context *ce,
> >  
> > GEM_BUG_ON(ce->ring->size < SZ_64K);
> >  
> > +   offset = 0;
> > +   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
> > +   offset = CHUNK_SZ;
> > +
> > do {
> > -   u32 offset;
> > int len;
> >  
> > rq = i915_request_create(ce);
> > @@ -727,10 +729,6 @@ intel_context_migrate_clear(struct intel_context *ce,
> > if (err)
> > goto out_rq;
> >  
> > -   offset = 0;
> > -   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
> > -   offset = CHUNK_SZ;
> > -
> > len = emit_pte(rq, &it, cache_level, is_lmem, offset, CHUNK_SZ);
> > if (len <= 0) {
> > err = len;
> > -- 
> > 2.20.1
> > 

Re: [PATCH] drm/msm: use orig_nents to iterate over scatterlist with per-process tables

[Robin Murphy]

On 2022-03-28 13:55, Jonathan Marek wrote:

This matches the implementation of iommu_map_sgtable() used for the
non-per-process page tables path.

This works around the dma_map_sgtable() call (used to invalidate cache)
overwriting sgt->nents with 1 (which is probably a separate issue).


FWIW that's expected behaviour. The sgtable APIs use nents to keep track 
of the number of DMA segments, while orig_nents represents the physical 
segments. IIUC you're not actually using the DMA mapping, just relying 
on its side-effects, so it's still the physical segments that you care 
about for your private IOMMU mapping here.



Fixes: b145c6e65eb0 ("drm/msm: Add support to create a local pagetable")
Signed-off-by: Jonathan Marek 
---
  drivers/gpu/drm/msm/msm_iommu.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index bcaddbba564df..22935ef26a3a1 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -58,7 +58,7 @@ static int msm_iommu_pagetable_map(struct msm_mmu *mmu, u64 
iova,
u64 addr = iova;
unsigned int i;
  
-	for_each_sg(sgt->sgl, sg, sgt->nents, i) {

+   for_each_sg(sgt->sgl, sg, sgt->orig_nents, i) {


Even better would be to use for_each_sgtable_sg(), which exists 
primarily for the sake of avoiding this exact confusion.


Robin.


size_t size = sg->length;
phys_addr_t phys = sg_phys(sg);
  

[PATCH 5.10 483/599] video: fbdev: nvidiafb: Use strscpy() to prevent buffer overflow

[Greg Kroah-Hartman]

From: Tim Gardner 

[ Upstream commit 37a1a2e6eeeb101285cd34e12e48a881524701aa ]

Coverity complains of a possible buffer overflow. However,
given the 'static' scope of nvidia_setup_i2c_bus() it looks
like that can't happen after examiniing the call sites.

CID 19036 (#1 of 1): Copy into fixed size buffer (STRING_OVERFLOW)
1. fixed_size_dest: You might overrun the 48-character fixed-size string
  chan->adapter.name by copying name without checking the length.
2. parameter_as_source: Note: This defect has an elevated risk because the
  source argument is a parameter of the current function.
 89strcpy(chan->adapter.name, name);

Fix this warning by using strscpy() which will silence the warning and
prevent any future buffer overflows should the names used to identify the
channel become much longer.

Cc: Antonino Daplas 
Cc: linux-fb...@vger.kernel.org
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Signed-off-by: Tim Gardner 
Signed-off-by: Helge Deller 
Signed-off-by: Sasha Levin 
---
 drivers/video/fbdev/nvidia/nv_i2c.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c 
b/drivers/video/fbdev/nvidia/nv_i2c.c
index d7994a173245..0b48965a6420 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -86,7 +86,7 @@ static int nvidia_setup_i2c_bus(struct nvidia_i2c_chan *chan, 
const char *name,
 {
int rc;
 
-   strcpy(chan->adapter.name, name);
+   strscpy(chan->adapter.name, name, sizeof(chan->adapter.name));
chan->adapter.owner = THIS_MODULE;
chan->adapter.class = i2c_class;
chan->adapter.algo_data = &chan->algo;
-- 
2.34.1

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Daniel Vetter]

On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
 wrote:
>
> On 4/5/22 11:24, Daniel Vetter wrote:
> > On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
>
> [snip]
>
> >>
> >> This is how I think that work, please let me know if you see something
> >> wrong in my logic:
> >>
> >> 1) A PCI device of OF device is registered for the GPU, this attempt to
> >>match a registered driver but no driver was registered that match yet.
> >>
> >> 2) The efifb driver is built-in, will be initialized according to the link
> >>order of the objects under drivers/video and the fbdev driver is 
> >> registered.
> >>
> >>There is no platform device or PCI/OF device registered that matches.
> >>
> >> 3) The DRM driver is built-in, will be initialized according to the link
> >>order of the objects under drivers/gpu and the DRM driver is registered.
> >>
> >>This matches the device registered in (1) and the DRM driver probes.
> >>
> >> 4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
> >>before registering the DRM device.
> >>
> >>There are no conflicting drivers or platform device at this point.
> >>
> >> 5) Latter at some point the drivers/firmware/sysfb.c init function is
> >>executed, and this registers a platform device for the generic fb.
> >>
> >>This device matches the efifb driver registered in (2) and the fbdev
> >>driver probes.
> >>
> >>Since that happens *after* the DRM driver already matched, probed
> >>and registered the DRM device, that is a bug and what the reverted
> >>patch worked around.
> >>
> >> So we need to prevent (5) if (1) and (3) already happened. Having a flag
> >> set in the fbdev core somewhere when remove_conflicting_framebuffers()
> >> is called could be a solution indeed.
> >>
> >> That is, the fbdev core needs to know that a DRM driver already probed
> >> and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
> >>
> >> I can attempt to write a patch for that.
> >
> > Ah yeah that could be an issue. I think the right fix is to replace
> > the platform dev unregister with a sysfb_unregister() function in
> > sysfb.c, which is synced with a common lock with the sysfb_init
> > function and a small boolean. I think I can type that up quickly for
> > v3.
>
> It's more complicated than that since sysfb is just *one* of the several
> places where platform devices can be registered for video devices.
>
> For instance, the vga16fb driver registers its own platform device in
> its module_init() function so that can also happen after the conflicting
> framebuffers (and associated devices) were removed by a DRM driver probe.
>
> I tried to minimize the issue for that particular driver with commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
>
> But the point stands, it all boils down to the fact that you have two
> different subsystems registering video drivers and they don't know all
> about each other to take a proper decision.
>
> Right now the drm_aperture_remove_conflicting_framebuffers() call signals
> in one direction from DRM to fbdev but there isn't a communication in the
> other direction, from fbdev to DRM.
>
> I believe the correct fix would be for the fbdev core to keep a list of
> the apertures struct that are passed to remove_conflicting_framebuffers(),
> that way it will know what apertures are not available anymore and prevent
> to register any fbdev framebuffer that conflicts with one already present.

Hm that still feels like reinventing a driver model, badly.

I think there's two cleaner solutions:
- move all the firmware driver platform_dev into sysfb.c, and then
just bind the special cases against that (e.g. offb, vga16fb and all
these). Then we'd have one sysfb_try_unregister(struct device *dev)
interface that fbmem.c uses.
- let fbmem.c call into each of these firmware device providers, which
means some loops most likely (like we can't call into vga16fb), so
probably need to move that into fbmem.c and it all gets a bit messy.

> Let me know if you think that makes sense and I can attempt to write a fix.

I still think unregistering the platform_dev properly makes the most
sense, and feels like the most proper linux device model solution
instead of hacks on top - if the firmware fb is unuseable because a
native driver has taken over, we should nuke that. And also the
firmware fb driver would then just bind to that platform_dev if it
exists, and only if it exists. Also I think it should be the
responsibility of whichever piece of code that registers these
platform devices to ensure that platform_dev actually still exists.
That's why I think pushing all that code into sysfb.c is probably the
cleanest solution.

fbdev predates all that stuff by a lot, hence the hand-rolling.

But maybe Greg has some more thoughts here too?
-Daniel

>
> --
> Best regards,
>
> Javier Martinez Canillas
> Linux Engineering
> Red Hat
>


-- 
Daniel Vetter
So

[PATCH] drm/i915: Improve on suspend / resume time with VT-d enabled

[Thomas Hellström]

When DMAR / VT-d is enabled, the display engine uses overfetching,
presumably to deal with the increased latency. To avoid display engine
errors and DMAR faults, as a workaround the GGTT is populated with scatch
PTEs when VT-d is enabled. However starting with gen10, Write-combined
writing of scratch PTES is no longer possible and as a result, populating
the full GGTT with scratch PTEs like on resume becomes very slow as
uncached access is needed.

Therefore, on integrated GPUs utilize the fact that the PTEs are stored in
stolen memory which retain content across S3 suspend. Don't clear the PTEs
on suspend and resume. This improves on resume time with around 100 ms.
While 100+ms might appear like a short time it's 10% to 20% of total resume
time and important in some applications.

One notable exception is Intel Rapid Start Technology which may cause
stolen memory to be lost across what the OS percieves as S3 suspend.
If IRST is enabled or if we can't detect whether IRST is enabled, retain
the old workaround, clearing and re-instating PTEs.

As an additional measure, if we detect that the last ggtt pte was lost
during suspend, print a warning and re-populate the GGTT ptes

On discrete GPUs, the display engine scans out from LMEM which isn't
subject to DMAR, and presumably the workaround is therefore not needed,
but that needs to be verified and disabling the workaround for dGPU,
if possible, will be deferred to a follow-up patch.

v2:
- Rely on retained ptes to also speed up suspend and resume re-binding.
- Re-build GGTT ptes if Intel rst is enabled.
v3:
- Re-build GGTT ptes also if we can't detect whether Intel rst is enabled,
  and if the guard page PTE and end of GGTT was lost.

Signed-off-by: Thomas Hellström 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c | 56 +---
 drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++
 drivers/gpu/drm/i915/i915_driver.c   | 16 
 3 files changed, 86 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 04191fe2ee34..98441b1c1b75 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -23,6 +23,13 @@
 #include "intel_gtt.h"
 #include "gen8_ppgtt.h"
 
+static inline bool suspend_retains_ptes(struct i915_address_space *vm)
+{
+   return GRAPHICS_VER(vm->i915) >= 8 &&
+   !HAS_LMEM(vm->i915) &&
+   vm->is_ggtt;
+}
+
 static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
   unsigned long color,
   u64 *start,
@@ -116,6 +123,23 @@ static bool needs_idle_maps(struct drm_i915_private *i915)
return false;
 }
 
+/*
+ * Return the value of the last GGTT pte cast to an u64, if
+ * the system is supposed to retain ptes across resume. 0 otherwise.
+ */
+static u64 read_last_pte(struct i915_address_space *vm)
+{
+   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
+   gen8_pte_t __iomem *ptep;
+
+   if (!suspend_retains_ptes(vm))
+   return 0;
+
+   GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
+   ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
+   return readq(ptep);
+}
+
 /**
  * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
  * @vm: The VM to suspend the mappings for
@@ -179,7 +203,10 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
i915_gem_object_unlock(obj);
}
 
-   vm->clear_range(vm, 0, vm->total);
+   if (!suspend_retains_ptes(vm))
+   vm->clear_range(vm, 0, vm->total);
+   else
+   i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
 
vm->skip_pte_rewrite = save_skip_rewrite;
 
@@ -578,6 +605,8 @@ static int init_ggtt(struct i915_ggtt *ggtt)
struct drm_mm_node *entry;
int ret;
 
+   ggtt->pte_lost = true;
+
/*
 * GuC requires all resources that we're sharing with it to be placed in
 * non-WOPCM memory. If GuC is not present or not in use we still need a
@@ -1309,11 +1338,20 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
 {
struct i915_vma *vma;
bool write_domain_objs = false;
+   bool retained_ptes;
 
drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
 
-   /* First fill our portion of the GTT with scratch pages */
-   vm->clear_range(vm, 0, vm->total);
+   /*
+* First fill our portion of the GTT with scratch pages if
+* they were not retained across suspend.
+*/
+   retained_ptes = suspend_retains_ptes(vm) &&
+   !i915_vm_to_ggtt(vm)->pte_lost &&
+   !GEM_WARN_ON(i915_vm_to_ggtt(vm)->probed_pte != 
read_last_pte(vm));
+
+   if (!retained_ptes)
+   vm->clear_range(vm, 0, vm->total);
 
/* clflush objects bound into the GGTT and rebind them. */
list_for_each_entry(vma, &vm->bound_list, vm_link) {

Re: [PATCH] i2c: at91: use dma safe buffers

[Michael Walle]

Am 2022-04-05 12:02, schrieb codrin.ciubota...@microchip.com:

On 05.04.2022 12:38, Michael Walle wrote:

Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:

+   if (dev->use_dma) {
+   dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);


If you want, you could just dev->buf = i2c_get_dma_safe...


But where is the error handling in that case? dev->buf will
be NULL, which is eventually passed to dma_map_single().

Also, I need the dma_buf for the i2c_put_dma_safe_msg_buf()
call anyway, because dev->buf will be modified during
processing.


You still:
if (!dev->buf) {
ret = -ENOMEM;
goto out;
}

So, at91_do_twi_transfer()/dma_map_single() will not be called.


Ahh, I misunderstood you. Yes, but as I said, I need the dma_buf
temporary variable anyway, because dev->buf is modified, eg. see
at91_twi_read_data_dma_callback().

-michael

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Laurent Pinchart]

Hi Marek,

Thank you for the patch.

On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> In rare cases, the bridge may not start up correctly, which usually
> leads to no display output. In case this happens, warn about it in
> the kernel log.

Do you know what this is caused by ? It's a bit annoying to add a 10+ms
delay at start time just to be notified of rare cases.

> Signed-off-by: Marek Vasut 
> Cc: Jagan Teki 
> Cc: Laurent Pinchart 
> Cc: Linus Walleij 
> Cc: Robert Foss 
> Cc: Sam Ravnborg 
> Cc: dri-devel@lists.freedesktop.org
> ---
>  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
> b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> index 19daaddd29a41..1d7c154ea1d79 100644
> --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct drm_bridge 
> *bridge,
>   /* Clear all errors that got asserted during initialization. */
>   regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
>   regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> +
> + usleep_range(1, 12000);
> + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> + if (pval)
> + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval);
>  }
>  
>  static void sn65dsi83_atomic_disable(struct drm_bridge *bridge,

-- 
Regards,

Laurent Pinchart

Re: [PATCH V2 0/3] DSI host and peripheral initialisation ordering

[Dave Stevenson]

On Fri, 18 Mar 2022 at 12:25, Dave Stevenson
 wrote:
>
> On Fri, 4 Mar 2022 at 15:18, Dave Stevenson
>  wrote:
> >
> > Hi All
>
> A gentle ping on this series. Any comments on the approach?
> Thanks.

I realise the merge window has just closed and therefore folks have
been busy, but no responses on this after a month?

Do I give up and submit a patch to document that DSI is broken and no one cares?

  Dave

> > Changes from v1:
> > - New patch to refactor drm_bridge_chain_post_disable and 
> > drm_bridge_chain_pre_enable
> >   to reuse drm_atomic_bridge_chain_post_disable / 
> > drm_atomic_bridge_chain_pre_enable
> >   but with a NULL state.
> > - New patch that adds a pre_enable_upstream_first to drm_panel.
> > - changed from an OPS flag to a bool "pre_enable_upstream_first" in 
> > drm_bridge.
> > - Followed Andrzej's suggestion of using continue in the main loop to avoid
> >   needing 2 additional loops (one forward to find the last bridge wanting
> >   upstream first, and the second backwards again).
> > - Actioned Laurent's review comments on docs patch.
> >
> > Original cover letter:
> >
> > Hopefully I've cc'ed all those that have bashed this problem around 
> > previously,
> > or are otherwise linked to DRM bridges.
> >
> > There have been numerous discussions around how DSI support is currently 
> > broken
> > as it doesn't support initialising the PHY to LP-11 and potentially the 
> > clock
> > lane to HS prior to configuring the DSI peripheral. There is no op where the
> > interface is initialised but HS video isn't also being sent.
> > Currently you have:
> > - peripheral pre_enable (host not initialised yet)
> > - host pre_enable
> > - encoder enable
> > - host enable
> > - peripheral enable (video already running)
> >
> > vc4 and exynos currently implement the DSI host as an encoder, and split the
> > bridge_chain. This fails if you want to switch to being a bridge and/or use
> > atomic calls as the state of all the elements split off are not added by
> > drm_atomic_add_encoder_bridges.
> >
> > dw-mipi-dsi[1] and now msm[2] use the mode_set hook to initialise the PHY, 
> > so
> > the bridge/panel pre_enable can send commands. In their post_disable they 
> > then
> > call the downstream bridge/panel post_disable op manually so that shutdown
> > commands can be sent before shutting down the PHY. Nothing handles that 
> > fact,
> > so the framework then continues down the bridge chain and calls the 
> > post_disable
> > again, so we get unbalanced panel prepare/unprepare calls being reported 
> > [3].
> >
> > There have been patches[4] proposing reversing the entire direction of
> > pre_enable and post_disable, but that risks driving voltage into devices 
> > that
> > have yet to be powered up.
> > There have been discussions about adding either a pre_pre_enable, or adding 
> > a
> > DSI host_op to initialise the host[5]. Both require significant reworking 
> > to all
> > existing drivers in moving initialisation phases.
> > We have patches that look like they may well be addressing race conditions 
> > in
> > starting up a DSI peripheral[6].
> >
> > This patch takes a hybrid of the two: an optional reversing of the order for
> > specific links within the bridge chain within pre_enable and post_disable 
> > done
> > within the drm_bridge framework.
> > I'm more than happy to move where the flag exists in structures (currently 
> > as
> > DRM_BRIDGE_OP_UPSTREAM_FIRST in drm_bridge_ops, but it isn't an op), but 
> > does
> > this solve the problem posed? If not, then can you describe the actual 
> > scenario
> > it doesn't cover?
> > A DSI peripheral can set the flag to get the DSI host initialised first, and
> > therefore it has a stable LP-11 state before pre_enable. Likewise the 
> > peripheral
> > can still send shutdown commands prior to the DSI host being shut down in
> > post_disable. It also handles the case where there are multiple devices in 
> > the
> > chain that all want their upstream bridge enabled first, so should there be 
> > a
> > DSI mux between host and peripheral, then it can still get the host to the
> > correct state.
> >
> > An example tree is at [7] which is drm-misc-next with these patches and 
> > then a
> > conversion of vc4_dsi to use the atomic bridge functions (will be upstreamed
> > once we're over this hurdle). It is working happily with the Toshiba 
> > TC358762 on
> > a Raspberry Pi 7" panel.
> > The same approach but on our vendor 5.15 tree[8] has also been tested
> > successfully on a TI SN65DSI83 and LVDS panel.
> >
> > Whilst here, I've also documented the expected behaviour of DSI hosts and
> > peripherals to aid those who come along after.
> >
> > Thanks
> >   Dave
> >
> > [1] 
> > https://github.com/torvalds/linux/blob/master/drivers/gpu/drm/bridge/synopsys/dw-mipi-dsi.c#L940
> > [2] 
> > https://lists.freedesktop.org/archives/dri-devel/2022-January/337769.html
> > [3] 
> > https://lists.freedesktop.org/archives/dri-devel/2021-December/333908.html
> > [4]

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Marek Vasut]

On 4/5/22 13:42, Laurent Pinchart wrote:

Hi Marek,


Hi,


Thank you for the patch.

On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:

In rare cases, the bridge may not start up correctly, which usually
leads to no display output. In case this happens, warn about it in
the kernel log.


Do you know what this is caused by ? It's a bit annoying to add a 10+ms
delay at start time just to be notified of rare cases.


Could be anything, broken DSI bridge driver, misconfigured DSI link, 
etc. This at least informs the user that the bridge failed to come up, 
before this patch, there was no information about such failure.

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Dave Stevenson]

Hi Laurent

On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart
 wrote:
>
> Hi Marek,
>
> Thank you for the patch.
>
> On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> > In rare cases, the bridge may not start up correctly, which usually
> > leads to no display output. In case this happens, warn about it in
> > the kernel log.
>
> Do you know what this is caused by ? It's a bit annoying to add a 10+ms
> delay at start time just to be notified of rare cases.

The datasheet [1] section 7.4.2 Initialization Sequence states in step 2
"After power is applied and stable, the DSI CLK lanes MUST be in HS
state and the DSI data lanes MUST be driven
to LP11 state"
Data lanes shouldn't go to HS until step 8 after the DSI83 has been configured.

Configuration from the driver is being done from atomic_enable,
therefore the data lanes are likely in HS mode and sending video, not
LP11.

Deviate from the specified initialisation sequence at your peril!

The SN65DSI8[3|4|5] is one of the DSI devices that I'd been looking at
with the DSI ordering patches [2] so that we could initialise it in
the way specified in the datasheet. I've had no responses to v2 of
those patches though.

  Dave

[1] https://www.ti.com/lit/ds/symlink/sn65dsi83.pdf
[2] https://patchwork.freedesktop.org/series/100252/#rev2

> > Signed-off-by: Marek Vasut 
> > Cc: Jagan Teki 
> > Cc: Laurent Pinchart 
> > Cc: Linus Walleij 
> > Cc: Robert Foss 
> > Cc: Sam Ravnborg 
> > Cc: dri-devel@lists.freedesktop.org
> > ---
> >  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
> > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > index 19daaddd29a41..1d7c154ea1d79 100644
> > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct drm_bridge 
> > *bridge,
> >   /* Clear all errors that got asserted during initialization. */
> >   regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> >   regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> > +
> > + usleep_range(1, 12000);
> > + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> > + if (pval)
> > + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval);
> >  }
> >
> >  static void sn65dsi83_atomic_disable(struct drm_bridge *bridge,
>
> --
> Regards,
>
> Laurent Pinchart

Re: [Intel-gfx] [PATCH] drm/i915: Improve on suspend / resume time with VT-d enabled

[Daniel Vetter]

On Tue, 5 Apr 2022 at 13:00, Thomas Hellström
 wrote:
>
> When DMAR / VT-d is enabled, the display engine uses overfetching,
> presumably to deal with the increased latency. To avoid display engine
> errors and DMAR faults, as a workaround the GGTT is populated with scatch
> PTEs when VT-d is enabled. However starting with gen10, Write-combined
> writing of scratch PTES is no longer possible and as a result, populating
> the full GGTT with scratch PTEs like on resume becomes very slow as
> uncached access is needed.
>
> Therefore, on integrated GPUs utilize the fact that the PTEs are stored in
> stolen memory which retain content across S3 suspend. Don't clear the PTEs
> on suspend and resume. This improves on resume time with around 100 ms.
> While 100+ms might appear like a short time it's 10% to 20% of total resume
> time and important in some applications.
>
> One notable exception is Intel Rapid Start Technology which may cause
> stolen memory to be lost across what the OS percieves as S3 suspend.
> If IRST is enabled or if we can't detect whether IRST is enabled, retain
> the old workaround, clearing and re-instating PTEs.
>
> As an additional measure, if we detect that the last ggtt pte was lost
> during suspend, print a warning and re-populate the GGTT ptes
>
> On discrete GPUs, the display engine scans out from LMEM which isn't
> subject to DMAR, and presumably the workaround is therefore not needed,
> but that needs to be verified and disabling the workaround for dGPU,
> if possible, will be deferred to a follow-up patch.
>
> v2:
> - Rely on retained ptes to also speed up suspend and resume re-binding.
> - Re-build GGTT ptes if Intel rst is enabled.
> v3:
> - Re-build GGTT ptes also if we can't detect whether Intel rst is enabled,
>   and if the guard page PTE and end of GGTT was lost.
>
> Signed-off-by: Thomas Hellström 

It's not great, but I think it's better than building another
complication into our allocator just to handle this all.

Acked-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/i915/gt/intel_ggtt.c | 56 +---
>  drivers/gpu/drm/i915/gt/intel_gtt.h  | 20 ++
>  drivers/gpu/drm/i915/i915_driver.c   | 16 
>  3 files changed, 86 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> index 04191fe2ee34..98441b1c1b75 100644
> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
> @@ -23,6 +23,13 @@
>  #include "intel_gtt.h"
>  #include "gen8_ppgtt.h"
>
> +static inline bool suspend_retains_ptes(struct i915_address_space *vm)
> +{
> +   return GRAPHICS_VER(vm->i915) >= 8 &&
> +   !HAS_LMEM(vm->i915) &&
> +   vm->is_ggtt;
> +}
> +
>  static void i915_ggtt_color_adjust(const struct drm_mm_node *node,
>unsigned long color,
>u64 *start,
> @@ -116,6 +123,23 @@ static bool needs_idle_maps(struct drm_i915_private 
> *i915)
> return false;
>  }
>
> +/*
> + * Return the value of the last GGTT pte cast to an u64, if
> + * the system is supposed to retain ptes across resume. 0 otherwise.
> + */
> +static u64 read_last_pte(struct i915_address_space *vm)
> +{
> +   struct i915_ggtt *ggtt = i915_vm_to_ggtt(vm);
> +   gen8_pte_t __iomem *ptep;
> +
> +   if (!suspend_retains_ptes(vm))
> +   return 0;
> +
> +   GEM_BUG_ON(GRAPHICS_VER(vm->i915) < 8);
> +   ptep = (typeof(ptep))ggtt->gsm + (ggtt_total_entries(ggtt) - 1);
> +   return readq(ptep);
> +}
> +
>  /**
>   * i915_ggtt_suspend_vm - Suspend the memory mappings for a GGTT or DPT VM
>   * @vm: The VM to suspend the mappings for
> @@ -179,7 +203,10 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
> i915_gem_object_unlock(obj);
> }
>
> -   vm->clear_range(vm, 0, vm->total);
> +   if (!suspend_retains_ptes(vm))
> +   vm->clear_range(vm, 0, vm->total);
> +   else
> +   i915_vm_to_ggtt(vm)->probed_pte = read_last_pte(vm);
>
> vm->skip_pte_rewrite = save_skip_rewrite;
>
> @@ -578,6 +605,8 @@ static int init_ggtt(struct i915_ggtt *ggtt)
> struct drm_mm_node *entry;
> int ret;
>
> +   ggtt->pte_lost = true;
> +
> /*
>  * GuC requires all resources that we're sharing with it to be placed 
> in
>  * non-WOPCM memory. If GuC is not present or not in use we still 
> need a
> @@ -1309,11 +1338,20 @@ bool i915_ggtt_resume_vm(struct i915_address_space 
> *vm)
>  {
> struct i915_vma *vma;
> bool write_domain_objs = false;
> +   bool retained_ptes;
>
> drm_WARN_ON(&vm->i915->drm, !vm->is_ggtt && !vm->is_dpt);
>
> -   /* First fill our portion of the GTT with scratch pages */
> -   vm->clear_range(vm, 0, vm->total);
> +   /*
> +* First fill our portion of the GTT with scratch pages if
> +* they were not retain

Re: [PATCH 23/23] drm/ttm: remove bo->moving

[Daniel Vetter]

On Tue, 5 Apr 2022 at 11:25, Christian König  wrote:
>
> Am 29.03.22 um 18:02 schrieb Daniel Vetter:
> > On Mon, Mar 21, 2022 at 02:58:56PM +0100, Christian König wrote:
> > [SNIP]
> >>   static unsigned long ttm_bo_io_mem_pfn(struct ttm_buffer_object *bo,
> >> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c 
> >> b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> >> index f999fdd927df..c6d02c98a19a 100644
> >> --- a/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> >> +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_resource.c
> >> @@ -1163,12 +1163,6 @@ int vmw_resources_clean(struct vmw_buffer_object 
> >> *vbo, pgoff_t start,
> >>  *num_prefault = __KERNEL_DIV_ROUND_UP(last_cleaned - 
> >> res_start,
> >>PAGE_SIZE);
> >>  vmw_bo_fence_single(bo, NULL);
> >> -if (bo->moving)
> >> -dma_fence_put(bo->moving);
> >> -
> >> -return dma_resv_get_singleton(bo->base.resv,
> >> -  DMA_RESV_USAGE_KERNEL,
> >> -  &bo->moving);
> > This seems to be entirely misplaced and I'm pretty sure doesn't even
> > compile interim.
>
> Mhm, removing that is correctly placed as far as I can see.
>
> What VMWGFX does here is to update bo->moving to please TTM, but since
> we now drop the bo->moving fence from TTM and always wait for all fences
> with DMA_RESV_USAGE_KERNEL before allowing CPU access that workaround
> isn't necessary any more.

Hm yeah that makes sense. Just out of paranoid would be good if you
can get an ack on the previous patch that downgrades from USAGE_WRITE
to USAGE_KERNEL here from vmwgfx folks, but I guess that should be
fine.

Just from reading the commit that introduce this is looks a little bit
like the intent is actually to make any USAGE_WRITE a mandatory fence
you can never cheat out of, but maybe I got this all wrong.

>
> >>  }
> >>
> >>  return 0;
> >> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> >> index c17b2df9178b..4c7134550262 100644
> >> --- a/include/drm/ttm/ttm_bo_api.h
> >> +++ b/include/drm/ttm/ttm_bo_api.h
> >> @@ -97,7 +97,6 @@ struct ttm_tt;
> >>* @lru: List head for the lru list.
> >>* @ddestroy: List head for the delayed destroy list.
> >>* @swap: List head for swap LRU list.
> >> - * @moving: Fence set when BO is moving
> >>* @offset: The current GPU offset, which can have different meanings
> >>* depending on the memory type. For SYSTEM type memory, it should be 0.
> >>* @cur_placement: Hint of current placement.
> >> @@ -150,7 +149,6 @@ struct ttm_buffer_object {
> >>   * Members protected by a bo reservation.
> >>   */
> >>
> >> -struct dma_fence *moving;
> >>  unsigned priority;
> >>  unsigned pin_count;
> > Aside from the vmwgfx thing this looks good. With the vmwgfx patch split
> > issue (I think it's just that) fixed:
> >
> > Reviewed-by: Daniel Vetter 
>
> Is it enough if I explain why we update VMWGFX in the commit message?

Yeah sounds fine to me, this patch isn't a functional change now that
you explained it that's clear. I'm still wondering whether there's
something fishy going on, but that's on earlier patches.
-Daniel

>
> Thanks,
> Christian.
>
> >
> >>
> >> --
> >> 2.25.1
> >>
>


-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch

Re: [PATCH v6 1/8] drm/msm/dp: Add eDP support via aux_bus

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 23:53, Doug Anderson  wrote:
>
> Hi,
>
> On Sat, Apr 2, 2022 at 1:26 PM Dmitry Baryshkov
>  wrote:
> >
> > On Sat, 2 Apr 2022 at 20:06, Doug Anderson  wrote:
> > >
> > > Hi,
> > >
> > > On Sat, Apr 2, 2022 at 3:37 AM Dmitry Baryshkov
> > >  wrote:
> > > >
> > > > On 01/04/2022 02:22, Doug Anderson wrote:
> > > > > Hi,
> > > > >
> > > > > On Wed, Mar 30, 2022 at 9:03 AM Sankeerth Billakanti
> > > > >  wrote:
> > > > >>
> > > > >> @@ -1547,6 +1593,10 @@ int msm_dp_modeset_init(struct msm_dp 
> > > > >> *dp_display, struct drm_device *dev,
> > > > >>
> > > > >>  dp_display->encoder = encoder;
> > > > >>
> > > > >> +   ret = dp_display_get_next_bridge(dp_display);
> > > > >> +   if (ret)
> > > > >> +   return ret;
> > > > >
> > > > > It feels weird to me that this is in a function called "modeset_init",
> > > > > though I certainly don't know the structure of the MSM display code
> > > > > well enough to fully comment.
> > > >
> > > > It's called modeset_init() as it initializes KMS objects used by DP
> > > > driver. We have similar functions for dsi and hdmi
> > >
> > > Sorry, I wasn't meaning to imply that modeset_init() was a bad name or
> > > anything. Mostly saying that I wasn't sure that modeset init was the
> > > proper time to populate the aux bus. ...but then again, perhaps it is
> > > given the current structure of this driver?
> > >
> > >
> > > > > My expectation would have been that
> > > > > devm_of_dp_aux_populate_ep_devices() would have been called from your
> > > > > probe routine and then you would have returned -EPROBE_DEFER from your
> > > > > probe if you were unable to find the panel afterwards.
> > > >
> > > > I don't think it's possible to call it from probe() since
> > > > drm_dp_aux_register() is called only from dp_display_bind().
> > > > The PHY also isn't initialized at that moment, so we can not probe AUX
> > > > devices.
> > > >
> > > > The overall semantics of the AUX bus is not clear to me.
> > > > Typically the bus is populated (and probed) when devices are accessible.
> > > > But for the display related buses this might not be the case.
> > >
> > > In general the AUX bus is modeled much like the i2c bus. You probe the
> > > sub-device when you're able to transfer. Then you can confirm that the
> > > device is actually there and init the device.
> > >
> > >
> > > > For example for the DSI bus we clearly define that DSI transfer are not
> > > > possible before the corresponding bridge's (or panel's) enable call.
> > > >
> > > > Maybe the same approach should be adopted for the AUX bus. This would
> > > > allow us to populate the AUX bus before hardware access is actually
> > > > possible, thus creating all the DRM bridges before the hardware is
> > > > actually up and running.
> > >
> > > So I guess what you're proposing is that you could probe the devices
> > > under the AUX bus and they could acquire resources (and possibly
> > > return EPROBE_DEFER) at a point in time _before_ it's actually
> > > possible to transfer. Then I guess you'd later do the transfer?
> >
> > Exactly.
> >
> > >
> > > I guess conceivably one could re-design the DRM subsystem like that,
> > > but I don't think it's trivial.
> >
> > The problem is that the DRM subsystem is already designed like that.
> > All the bridge chains are static. They are created during the device
> > probe. And the modes are populated later (via the get_modes()
> > callback), after the HPD signal is delivered.
> > For the encoder/bridge chains it is explicitly stated that the display
> > pipe (clocks and timing signals) are not running before bridge's
> > enable() callback or after the disable() callback being called.
> >
> > > Why? I believe that we need to know
> > > things about the panel at probe time. For instance, we need to be able
> > > to populate the panel's modes.
> >
> > As I said, panel modes are not needed at the probe time. The fact that
> > most (if not all) of the panel drivers provide them in the platform
> > data (and thus modes are typically populated at the probe time) comes
> > from the fact that the panel is usually a known static piece of
> > hardware. With the generic edp-panel this is no longer the case. A
> > single device handles a (probed) variety of panels.
>
> OK, so I misspoke when I said that the modes are populated during
> probe time for edp-panel. They're not and I guess I managed to confuse
> myself when I wrote my previous email. Instead they (and everything
> else that comes from the EDID) isn't needed until the panel's
> get_modes() is called, as you said. So, ignoring the backlight problem
> talked about below, we could conceivably delay the reading of the EDID
> until get_modes.

Yes.

>
> ...but I think something still isn't quite right with your description
> of how it works. Specifically:
>
> 1. I'm 99% certain that get_modes() is called _before_ enable, even
> for the DP case. I have no idea how that works for you for DP if the
> cloc

Re: fbdev: Fix unregistering of framebuffers without device

[Sudip Mukherjee]

On Mon, Apr 04, 2022 at 09:44:02PM +0200, Thomas Zimmermann wrote:
> OF framebuffers do not have an underlying device in the Linux
> device hierarchy. Do a regular unregister call instead of hot
> unplugging such a non-existing device. Fixes a NULL dereference.
> An example error message on ppc64le is shown below.
> 



> 
> Tested with 5.17 on qemu ppc64le emulation.
> 
> Signed-off-by: Thomas Zimmermann 
> Fixes: 27599aacbaef ("fbdev: Hot-unplug firmware fb devices on forced 
> removal")
> Reported-by: Sudip Mukherjee 
> Cc: Zack Rusin 
> Cc: Javier Martinez Canillas 
> Cc: Hans de Goede 
> Cc: sta...@vger.kernel.org # v5.11+
> Cc: Helge Deller 
> Cc: Daniel Vetter 
> Cc: Sam Ravnborg 
> Cc: Zheyu Ma 
> Cc: Xiyu Yang 
> Cc: Zhen Lei 
> Cc: Matthew Wilcox 
> Cc: Alex Deucher 
> Cc: Tetsuo Handa 
> Cc: Guenter Roeck 
> Cc: linux-fb...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Link: https://lore.kernel.org/all/YkHXO6LGHAN0p1pq@debian/ # [1]
> Reviewed-by: Daniel Vetter 
> ---

Tested-by: Sudip Mukherjee 

--
Regards
Sudip

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Laurent Pinchart]

Hi Dave,

On Tue, Apr 05, 2022 at 01:00:28PM +0100, Dave Stevenson wrote:
> On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart wrote:
> > On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> > > In rare cases, the bridge may not start up correctly, which usually
> > > leads to no display output. In case this happens, warn about it in
> > > the kernel log.
> >
> > Do you know what this is caused by ? It's a bit annoying to add a 10+ms
> > delay at start time just to be notified of rare cases.
> 
> The datasheet [1] section 7.4.2 Initialization Sequence states in step 2
> "After power is applied and stable, the DSI CLK lanes MUST be in HS
> state and the DSI data lanes MUST be driven
> to LP11 state"
> Data lanes shouldn't go to HS until step 8 after the DSI83 has been 
> configured.
> 
> Configuration from the driver is being done from atomic_enable,
> therefore the data lanes are likely in HS mode and sending video, not
> LP11.
> 
> Deviate from the specified initialisation sequence at your peril!
> 
> The SN65DSI8[3|4|5] is one of the DSI devices that I'd been looking at
> with the DSI ordering patches [2] so that we could initialise it in
> the way specified in the datasheet. I've had no responses to v2 of
> those patches though.

Sounds like I need to review that :-) It's still in my queue, I'll try
to push it to the top.

Do you think this patch could then be reverted ?

> [1] https://www.ti.com/lit/ds/symlink/sn65dsi83.pdf
> [2] https://patchwork.freedesktop.org/series/100252/#rev2
> 
> > > Signed-off-by: Marek Vasut 
> > > Cc: Jagan Teki 
> > > Cc: Laurent Pinchart 
> > > Cc: Linus Walleij 
> > > Cc: Robert Foss 
> > > Cc: Sam Ravnborg 
> > > Cc: dri-devel@lists.freedesktop.org
> > > ---
> > >  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 +
> > >  1 file changed, 5 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
> > > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > index 19daaddd29a41..1d7c154ea1d79 100644
> > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct 
> > > drm_bridge *bridge,
> > >   /* Clear all errors that got asserted during initialization. */
> > >   regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> > >   regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> > > +
> > > + usleep_range(1, 12000);
> > > + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> > > + if (pval)
> > > + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", pval);
> > >  }
> > >
> > >  static void sn65dsi83_atomic_disable(struct drm_bridge *bridge,

-- 
Regards,

Laurent Pinchart

Re: Public patches but non-public development branch (Re: [PATCH 1/1] drm/amdkfd: Add missing NULL check in svm_range_map_to_gpu)

[Alex Deucher]

On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel  wrote:
>
> Dear Christian,
>
>
> Am 05.04.22 um 08:54 schrieb Christian König:
> > Am 05.04.22 um 08:45 schrieb Paul Menzel:
>
> >> Am 04.04.22 um 23:42 schrieb Philip Yang:
> >>> bo_adev is NULL for system memory mapping to GPU.
> >>>
> >>> Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
> >>
> >> Sorry, where can I find that commit?
> >
> > Well that's expected, the development branch is not public.
>
> Well obviously, it was unexpected for me. How should I have known? Where
> is that documented? If the patches are publicly posted to the mailing
> list, why is that development branch not public?
>
> The current situation is really frustrating for non-AMD employees. How
> can the current situation be improved?

Our development branch
(https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
is available publicly.  There can be a day or so of lag depending on
when it gets mirrored (e.g., over the weekend).

Alex

>
>
> Kind regards,
>
> Paul
>
>
> >> I do not see it in drm-next from agd5f git archive
> >> g...@gitlab.freedesktop.org:agd5f/linux.git.
> >>
> >> $ git log --oneline -1
> >> e45422695c19 (HEAD, agd5f/drm-next) drm/amdkfd: Create file
> >> descriptor after client is added to smi_clients list
> >>
> >>
> >> Kind regards,
> >>
> >> Paul
> >>
> >>
> >>> Signed-off-by: Philip Yang 
> >>> ---
> >>>   drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 2 +-
> >>>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> index 907b02045824..d3fb2d0b5a25 100644
> >>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_svm.c
> >>> @@ -1281,7 +1281,7 @@ svm_range_map_to_gpu(struct kfd_process_device
> >>> *pdd, struct svm_range *prange,
> >>>  last_start, prange->start + i,
> >>>  pte_flags,
> >>>  last_start - prange->start,
> >>> -   bo_adev->vm_manager.vram_base_offset,
> >>> +   bo_adev ?
> >>> bo_adev->vm_manager.vram_base_offset : 0,
> >>>  NULL, dma_addr, &vm->last_update);
> >>> for (j = last_start - prange->start; j <= i; j++)

Re: [PATCH] drm/radeon: simplify if-if to if-else

[Alex Deucher]

Applied.  Thanks!

Alex

On Thu, Mar 31, 2022 at 11:00 PM Guo Zhengkui  wrote:
>
> Replace `if (!ret)` with `else` for simplification.
>
> Signed-off-by: Guo Zhengkui 
> ---
>  drivers/gpu/drm/radeon/radeon_pm.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/radeon/radeon_pm.c 
> b/drivers/gpu/drm/radeon/radeon_pm.c
> index c67b6ddb29a4..e765abcb3b01 100644
> --- a/drivers/gpu/drm/radeon/radeon_pm.c
> +++ b/drivers/gpu/drm/radeon/radeon_pm.c
> @@ -1629,7 +1629,7 @@ int radeon_pm_late_init(struct radeon_device *rdev)
> ret = device_create_file(rdev->dev, 
> &dev_attr_power_method);
> if (ret)
> DRM_ERROR("failed to create device file for 
> power method\n");
> -   if (!ret)
> +   else
> rdev->pm.sysfs_initialized = true;
> }
> }
> --
> 2.20.1
>

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Geert Uytterhoeven]

Hi Daniel,

On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter  wrote:
> On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
>  wrote:
> > On 4/5/22 11:24, Daniel Vetter wrote:
> > > On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
> > >> This is how I think that work, please let me know if you see something
> > >> wrong in my logic:
> > >>
> > >> 1) A PCI device of OF device is registered for the GPU, this attempt to
> > >>match a registered driver but no driver was registered that match yet.
> > >>
> > >> 2) The efifb driver is built-in, will be initialized according to the 
> > >> link
> > >>order of the objects under drivers/video and the fbdev driver is 
> > >> registered.
> > >>
> > >>There is no platform device or PCI/OF device registered that matches.
> > >>
> > >> 3) The DRM driver is built-in, will be initialized according to the link
> > >>order of the objects under drivers/gpu and the DRM driver is 
> > >> registered.
> > >>
> > >>This matches the device registered in (1) and the DRM driver probes.
> > >>
> > >> 4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
> > >>before registering the DRM device.
> > >>
> > >>There are no conflicting drivers or platform device at this point.
> > >>
> > >> 5) Latter at some point the drivers/firmware/sysfb.c init function is
> > >>executed, and this registers a platform device for the generic fb.
> > >>
> > >>This device matches the efifb driver registered in (2) and the fbdev
> > >>driver probes.
> > >>
> > >>Since that happens *after* the DRM driver already matched, probed
> > >>and registered the DRM device, that is a bug and what the reverted
> > >>patch worked around.
> > >>
> > >> So we need to prevent (5) if (1) and (3) already happened. Having a flag
> > >> set in the fbdev core somewhere when remove_conflicting_framebuffers()
> > >> is called could be a solution indeed.
> > >>
> > >> That is, the fbdev core needs to know that a DRM driver already probed
> > >> and make register_framebuffer() fail if info->flag & FBINFO_MISC_FIRMWARE
> > >>
> > >> I can attempt to write a patch for that.
> > >
> > > Ah yeah that could be an issue. I think the right fix is to replace
> > > the platform dev unregister with a sysfb_unregister() function in
> > > sysfb.c, which is synced with a common lock with the sysfb_init
> > > function and a small boolean. I think I can type that up quickly for
> > > v3.
> >
> > It's more complicated than that since sysfb is just *one* of the several
> > places where platform devices can be registered for video devices.
> >
> > For instance, the vga16fb driver registers its own platform device in
> > its module_init() function so that can also happen after the conflicting
> > framebuffers (and associated devices) were removed by a DRM driver probe.
> >
> > I tried to minimize the issue for that particular driver with commit:
> >
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
> >
> > But the point stands, it all boils down to the fact that you have two
> > different subsystems registering video drivers and they don't know all
> > about each other to take a proper decision.
> >
> > Right now the drm_aperture_remove_conflicting_framebuffers() call signals
> > in one direction from DRM to fbdev but there isn't a communication in the
> > other direction, from fbdev to DRM.
> >
> > I believe the correct fix would be for the fbdev core to keep a list of
> > the apertures struct that are passed to remove_conflicting_framebuffers(),
> > that way it will know what apertures are not available anymore and prevent
> > to register any fbdev framebuffer that conflicts with one already present.
>
> Hm that still feels like reinventing a driver model, badly.
>
> I think there's two cleaner solutions:
> - move all the firmware driver platform_dev into sysfb.c, and then
> just bind the special cases against that (e.g. offb, vga16fb and all
> these). Then we'd have one sysfb_try_unregister(struct device *dev)
> interface that fbmem.c uses.
> - let fbmem.c call into each of these firmware device providers, which
> means some loops most likely (like we can't call into vga16fb), so
> probably need to move that into fbmem.c and it all gets a bit messy.
>
> > Let me know if you think that makes sense and I can attempt to write a fix.
>
> I still think unregistering the platform_dev properly makes the most

That doesn't sound very driver-model-aware to me. The device is what
the driver binds to; it does not cease to exist.

> sense, and feels like the most proper linux device model solution
> instead of hacks on top - if the firmware fb is unuseable because a
> native driver has taken over, we should nuke that. And also the
> firmware fb driver would then just bind to that platform_dev if it
> exists, and only if it exists. Also I think it should be the
> responsibility of whichever piece of code that registers these
> platform devices 

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Dave Stevenson]

On Tue, 5 Apr 2022 at 14:08, Laurent Pinchart
 wrote:
>
> Hi Dave,
>
> On Tue, Apr 05, 2022 at 01:00:28PM +0100, Dave Stevenson wrote:
> > On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart wrote:
> > > On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> > > > In rare cases, the bridge may not start up correctly, which usually
> > > > leads to no display output. In case this happens, warn about it in
> > > > the kernel log.
> > >
> > > Do you know what this is caused by ? It's a bit annoying to add a 10+ms
> > > delay at start time just to be notified of rare cases.
> >
> > The datasheet [1] section 7.4.2 Initialization Sequence states in step 2
> > "After power is applied and stable, the DSI CLK lanes MUST be in HS
> > state and the DSI data lanes MUST be driven
> > to LP11 state"
> > Data lanes shouldn't go to HS until step 8 after the DSI83 has been 
> > configured.
> >
> > Configuration from the driver is being done from atomic_enable,
> > therefore the data lanes are likely in HS mode and sending video, not
> > LP11.
> >
> > Deviate from the specified initialisation sequence at your peril!
> >
> > The SN65DSI8[3|4|5] is one of the DSI devices that I'd been looking at
> > with the DSI ordering patches [2] so that we could initialise it in
> > the way specified in the datasheet. I've had no responses to v2 of
> > those patches though.
>
> Sounds like I need to review that :-) It's still in my queue, I'll try
> to push it to the top.
>
> Do you think this patch could then be reverted ?

If we can initialise the DSI host before the bridge for the
pre_enable, then all the configuration moves to the atomic_pre_enable
and there should be no need to have the delay.

I can't 100% guarantee that, but one of the folks on the Pi forums is
using [1] which does that, and is reporting it working well. (He's
also using the DSI85 to take 2 DSI links and drive 2 LVDS single link
panels)

  Dave

[1] https://github.com/6by9/linux/commits/rpi-5.15.y-sn65dsi8x

> > [1] https://www.ti.com/lit/ds/symlink/sn65dsi83.pdf
> > [2] https://patchwork.freedesktop.org/series/100252/#rev2
> >
> > > > Signed-off-by: Marek Vasut 
> > > > Cc: Jagan Teki 
> > > > Cc: Laurent Pinchart 
> > > > Cc: Linus Walleij 
> > > > Cc: Robert Foss 
> > > > Cc: Sam Ravnborg 
> > > > Cc: dri-devel@lists.freedesktop.org
> > > > ---
> > > >  drivers/gpu/drm/bridge/ti-sn65dsi83.c | 5 +
> > > >  1 file changed, 5 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/bridge/ti-sn65dsi83.c 
> > > > b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > index 19daaddd29a41..1d7c154ea1d79 100644
> > > > --- a/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > +++ b/drivers/gpu/drm/bridge/ti-sn65dsi83.c
> > > > @@ -488,6 +488,11 @@ static void sn65dsi83_atomic_enable(struct 
> > > > drm_bridge *bridge,
> > > >   /* Clear all errors that got asserted during initialization. */
> > > >   regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> > > >   regmap_write(ctx->regmap, REG_IRQ_STAT, pval);
> > > > +
> > > > + usleep_range(1, 12000);
> > > > + regmap_read(ctx->regmap, REG_IRQ_STAT, &pval);
> > > > + if (pval)
> > > > + dev_err(ctx->dev, "Unexpected link status 0x%02x\n", 
> > > > pval);
> > > >  }
> > > >
> > > >  static void sn65dsi83_atomic_disable(struct drm_bridge *bridge,
>
> --
> Regards,
>
> Laurent Pinchart

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Javier Martinez Canillas]

On 4/5/22 12:34, Daniel Vetter wrote:
> On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
>  wrote:

[snip]

>>
>> I believe the correct fix would be for the fbdev core to keep a list of
>> the apertures struct that are passed to remove_conflicting_framebuffers(),
>> that way it will know what apertures are not available anymore and prevent
>> to register any fbdev framebuffer that conflicts with one already present.
> 
> Hm that still feels like reinventing a driver model, badly.
>

Yeah, you are correct.
 
> I think there's two cleaner solutions:
> - move all the firmware driver platform_dev into sysfb.c, and then
> just bind the special cases against that (e.g. offb, vga16fb and all
> these). Then we'd have one sysfb_try_unregister(struct device *dev)
> interface that fbmem.c uses.

I think this is the cleaner option. And makes sense to consolidate all
the firmware drivers platform device registration to sysfb.c.

Already does for VIDEO_TYPE_EFI ("efi-framebuffer") and VIDEO_TYPE_VLFB
("vesa-framebuffer"), so need to also make it cope with VIDEO_TYPE_EGAC
and VIDEO_TYPE_VGAC ("vga16fb").

For offb is less clear since currently the offb driver does not really
use the Linux device model, that is the driver does not match a device
that's registered, there's no device which is the bug that was reported
to Thomas in the other thread.

It's unclear how to properly fix that since we will need to convert the
offb driver to register a platform driver and match against a device that
is registered by some platform code that parses the OF...

> - let fbmem.c call into each of these firmware device providers, which
> means some loops most likely (like we can't call into vga16fb), so
> probably need to move that into fbmem.c and it all gets a bit messy.
> 

Yup, that would get messy indeed so not a good option.

>> Let me know if you think that makes sense and I can attempt to write a fix.
> 
> I still think unregistering the platform_dev properly makes the most
> sense, and feels like the most proper linux device model solution
> instead of hacks on top - if the firmware fb is unuseable because a
> native driver has taken over, we should nuke that. And also the
> firmware fb driver would then just bind to that platform_dev if it
> exists, and only if it exists. Also I think it should be the
> responsibility of whichever piece of code that registers these
> platform devices to ensure that platform_dev actually still exists.
> That's why I think pushing all that code into sysfb.c is probably the
> cleanest solution.
>

Agreed. Not registering the platform devices if there is already a DRM
driver for the same device is what makes the most sense. What I don't
understand is how sysfb would know that if run after a DRM registration.

The only way that could know is if sysfb would keep a list of apertures
for all the DRM drivers registered or if the DRM core somewhat notifies
to sysfb that a native driver was already registered.

Another option and probably the cleanest although the harder solution is
to finally bite the bullet and make all the DRM drivers to request their
memory region.

Or as you mentioned in the past, to move that logic into the device model
and then not allow to register devices that require an overlapping region.

And there could be a request_mem_region_remove_conflicting() or something
that real DRM drivers could use to force a memory region request and make
the device model to unregister any device that may already have that mem.

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

Re: [PATCH v2] drm/radeon: change si_default_state table from global to static

[Alex Deucher]

Applied.  Thanks!

Alex

On Tue, Apr 5, 2022 at 2:04 AM Christian König  wrote:
>
> Am 05.04.22 um 00:57 schrieb Tom Rix:
> > Smatch reports these issues
> > si_blit_shaders.c:31:11: warning: symbol 'si_default_state'
> >was not declared. Should it be static?
> > si_blit_shaders.c:253:11: warning: symbol 'si_default_size'
> >was not declared. Should it be static?
> >
> > Both symbols are only used in si.c.  Single file symbols
> > should be static.  So move the definition of
> > si_default_state and si_default_size to si_blit_shader.h
> > and change their storage-class-specifier to static.
> >
> > Remove unneeded si_blit_shader.c
> >
> > Signed-off-by: Tom Rix 
>
> Reviewed-by: Christian König 
>
> > ---
> > v2: move definitions to header
> >
> >   drivers/gpu/drm/radeon/Makefile  |   2 +-
> >   drivers/gpu/drm/radeon/si_blit_shaders.c | 253 ---
> >   drivers/gpu/drm/radeon/si_blit_shaders.h | 223 +++-
> >   3 files changed, 222 insertions(+), 256 deletions(-)
> >   delete mode 100644 drivers/gpu/drm/radeon/si_blit_shaders.c
> >
> > diff --git a/drivers/gpu/drm/radeon/Makefile 
> > b/drivers/gpu/drm/radeon/Makefile
> > index 11c97edde54d..664381f4eb07 100644
> > --- a/drivers/gpu/drm/radeon/Makefile
> > +++ b/drivers/gpu/drm/radeon/Makefile
> > @@ -44,7 +44,7 @@ radeon-y += radeon_device.o radeon_asic.o radeon_kms.o \
> >   evergreen.o evergreen_cs.o evergreen_blit_shaders.o \
> >   evergreen_hdmi.o radeon_trace_points.o ni.o cayman_blit_shaders.o \
> >   atombios_encoders.o radeon_semaphore.o radeon_sa.o atombios_i2c.o 
> > si.o \
> > - si_blit_shaders.o radeon_prime.o cik.o cik_blit_shaders.o \
> > + radeon_prime.o cik.o cik_blit_shaders.o \
> >   r600_dpm.o rs780_dpm.o rv6xx_dpm.o rv770_dpm.o rv730_dpm.o 
> > rv740_dpm.o \
> >   rv770_smc.o cypress_dpm.o btc_dpm.o sumo_dpm.o sumo_smc.o 
> > trinity_dpm.o \
> >   trinity_smc.o ni_dpm.o si_smc.o si_dpm.o kv_smc.o kv_dpm.o ci_smc.o \
> > diff --git a/drivers/gpu/drm/radeon/si_blit_shaders.c 
> > b/drivers/gpu/drm/radeon/si_blit_shaders.c
> > deleted file mode 100644
> > index ec415e7dfa4b..
> > --- a/drivers/gpu/drm/radeon/si_blit_shaders.c
> > +++ /dev/null
> > @@ -1,253 +0,0 @@
> > -/*
> > - * Copyright 2011 Advanced Micro Devices, Inc.
> > - *
> > - * 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, sublicense,
> > - * 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 NONINFRINGEMENT.  IN NO EVENT SHALL
> > - * THE COPYRIGHT HOLDER(S) 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:
> > - * Alex Deucher 
> > - */
> > -
> > -#include 
> > -#include 
> > -#include 
> > -
> > -const u32 si_default_state[] =
> > -{
> > - 0xc0066900,
> > - 0x,
> > - 0x0060, /* DB_RENDER_CONTROL */
> > - 0x, /* DB_COUNT_CONTROL */
> > - 0x, /* DB_DEPTH_VIEW */
> > - 0x002a, /* DB_RENDER_OVERRIDE */
> > - 0x, /* DB_RENDER_OVERRIDE2 */
> > - 0x, /* DB_HTILE_DATA_BASE */
> > -
> > - 0xc0046900,
> > - 0x0008,
> > - 0x, /* DB_DEPTH_BOUNDS_MIN */
> > - 0x, /* DB_DEPTH_BOUNDS_MAX */
> > - 0x, /* DB_STENCIL_CLEAR */
> > - 0x, /* DB_DEPTH_CLEAR */
> > -
> > - 0xc0036900,
> > - 0x000f,
> > - 0x, /* DB_DEPTH_INFO */
> > - 0x, /* DB_Z_INFO */
> > - 0x, /* DB_STENCIL_INFO */
> > -
> > - 0xc0016900,
> > - 0x0080,
> > - 0x, /* PA_SC_WINDOW_OFFSET */
> > -
> > - 0xc00d6900,
> > - 0x0083,
> > - 0x, /* PA_SC_CLIPRECT_RULE */
> > - 0x, /* PA_SC_CLIPRECT_0_TL */
> > - 0x20002000, /* PA_SC_CLIPRECT_0_BR */
> > - 0x,
> > - 0x20002000,
> > - 0x,
> > - 0x20002000,
> > - 0x,
> > - 0x20002000,
> > - 0x, /* PA_SC_EDGERULE */
> > - 0x, /* PA_SU_HARDWARE_SCREEN_OFFSET */
> > - 0x

Re: [PATCH v2 18/19] Revert "fbdev: Prevent probing generic drivers if a FB is already registered"

[Greg KH]

On Tue, Apr 05, 2022 at 03:24:40PM +0200, Geert Uytterhoeven wrote:
> Hi Daniel,
> 
> On Tue, Apr 5, 2022 at 1:48 PM Daniel Vetter  wrote:
> > On Tue, 5 Apr 2022 at 11:52, Javier Martinez Canillas
> >  wrote:
> > > On 4/5/22 11:24, Daniel Vetter wrote:
> > > > On Tue, 5 Apr 2022 at 11:19, Javier Martinez Canillas
> > > >> This is how I think that work, please let me know if you see something
> > > >> wrong in my logic:
> > > >>
> > > >> 1) A PCI device of OF device is registered for the GPU, this attempt to
> > > >>match a registered driver but no driver was registered that match 
> > > >> yet.
> > > >>
> > > >> 2) The efifb driver is built-in, will be initialized according to the 
> > > >> link
> > > >>order of the objects under drivers/video and the fbdev driver is 
> > > >> registered.
> > > >>
> > > >>There is no platform device or PCI/OF device registered that 
> > > >> matches.
> > > >>
> > > >> 3) The DRM driver is built-in, will be initialized according to the 
> > > >> link
> > > >>order of the objects under drivers/gpu and the DRM driver is 
> > > >> registered.
> > > >>
> > > >>This matches the device registered in (1) and the DRM driver probes.
> > > >>
> > > >> 4) The DRM driver .probe kicks out any conflicting DRM drivers and pdev
> > > >>before registering the DRM device.
> > > >>
> > > >>There are no conflicting drivers or platform device at this point.
> > > >>
> > > >> 5) Latter at some point the drivers/firmware/sysfb.c init function is
> > > >>executed, and this registers a platform device for the generic fb.
> > > >>
> > > >>This device matches the efifb driver registered in (2) and the fbdev
> > > >>driver probes.
> > > >>
> > > >>Since that happens *after* the DRM driver already matched, probed
> > > >>and registered the DRM device, that is a bug and what the reverted
> > > >>patch worked around.
> > > >>
> > > >> So we need to prevent (5) if (1) and (3) already happened. Having a 
> > > >> flag
> > > >> set in the fbdev core somewhere when remove_conflicting_framebuffers()
> > > >> is called could be a solution indeed.
> > > >>
> > > >> That is, the fbdev core needs to know that a DRM driver already probed
> > > >> and make register_framebuffer() fail if info->flag & 
> > > >> FBINFO_MISC_FIRMWARE
> > > >>
> > > >> I can attempt to write a patch for that.
> > > >
> > > > Ah yeah that could be an issue. I think the right fix is to replace
> > > > the platform dev unregister with a sysfb_unregister() function in
> > > > sysfb.c, which is synced with a common lock with the sysfb_init
> > > > function and a small boolean. I think I can type that up quickly for
> > > > v3.
> > >
> > > It's more complicated than that since sysfb is just *one* of the several
> > > places where platform devices can be registered for video devices.
> > >
> > > For instance, the vga16fb driver registers its own platform device in
> > > its module_init() function so that can also happen after the conflicting
> > > framebuffers (and associated devices) were removed by a DRM driver probe.
> > >
> > > I tried to minimize the issue for that particular driver with commit:
> > >
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0499f419b76f
> > >
> > > But the point stands, it all boils down to the fact that you have two
> > > different subsystems registering video drivers and they don't know all
> > > about each other to take a proper decision.
> > >
> > > Right now the drm_aperture_remove_conflicting_framebuffers() call signals
> > > in one direction from DRM to fbdev but there isn't a communication in the
> > > other direction, from fbdev to DRM.
> > >
> > > I believe the correct fix would be for the fbdev core to keep a list of
> > > the apertures struct that are passed to remove_conflicting_framebuffers(),
> > > that way it will know what apertures are not available anymore and prevent
> > > to register any fbdev framebuffer that conflicts with one already present.
> >
> > Hm that still feels like reinventing a driver model, badly.
> >
> > I think there's two cleaner solutions:
> > - move all the firmware driver platform_dev into sysfb.c, and then
> > just bind the special cases against that (e.g. offb, vga16fb and all
> > these). Then we'd have one sysfb_try_unregister(struct device *dev)
> > interface that fbmem.c uses.
> > - let fbmem.c call into each of these firmware device providers, which
> > means some loops most likely (like we can't call into vga16fb), so
> > probably need to move that into fbmem.c and it all gets a bit messy.
> >
> > > Let me know if you think that makes sense and I can attempt to write a 
> > > fix.
> >
> > I still think unregistering the platform_dev properly makes the most
> 
> That doesn't sound very driver-model-aware to me. The device is what
> the driver binds to; it does not cease to exist.

I agree, that sounds odd.

The device should always stick around (as the bus creates it), it's up
to 

Re: [PATCH v2] media: mediatek: vcodec: Fix v4l2 compliance decoder cmd test fail

[AngeloGioacchino Del Regno]

Il 01/04/22 10:13, Yunfei Dong ha scritto:

Will return -EINVAL using standard framework api when test stateless
decoder with cmd VIDIOC_(TRY)DECODER_CMD.

Using another return value to adjust v4l2 compliance test for user
driver(GStreamer/Chrome) won't use decoder cmd.

Fixes: 8cdc3794b2e3 ("media: mtk-vcodec: vdec: support stateless API")
Signed-off-by: Yunfei Dong 


Reviewed-by: AngeloGioacchino Del Regno 

[PATCH v7 0/2] Add inline rotation support for sc7280

[Vinod Polimera]

Changes in RFC:
- Rebase changes to the latest code base.
- Append rotation config variables with v2 and
remove unused variables.(Dmitry)
- Move pixel_ext setup separately from scaler3 config.(Dmitry)
- Add 270 degree rotation to supported rotation list.(Dmitry)

Changes in V2:
- Remove unused macros and fix indentation.
- Add check if 90 rotation is supported and
add supported rotations to rot_cfg.

Changes in V3:
- Fix indentation.
- Move rot_supported to sspp capabilities. (Dmitry)
- Config pixel_ext based on src_h/src_w directly. (Dmitry)
- Misc changes.

Changes in V4:
- Pass boolean value to sspp blk based on supported rotations for each hw.

Changes in V5:
- Update boolean value to true/false and add it for qcm2290.

Changes in V6:
- Add changes that are missed as part of v5.
- Add dpu_find_format inline function to find valid format. (Dmitry)

Changes in V7:
- Move dpu_find_format inline function to separate commit. (Dmitry)
- Remove rot_cfg from SSPP_BLK and use DPU_SSPP_INLINE_ROTATION caps
to append supported rotations. (Dmitry)
- Misc Changes.

Co-developed-by: Kalyan Thota 
Signed-off-by: Kalyan Thota 
Signed-off-by: Vinod Polimera 

Vinod Polimera (2):
  drm/msm/disp/dpu1: add inline function to validate format support
  drm/msm/disp/dpu1: add inline rotation support for sc7280

 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h|  22 
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 173 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 139 +++-
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   2 +
 5 files changed, 251 insertions(+), 101 deletions(-)

-- 
2.7.4

[PATCH v7 2/2] drm/msm/disp/dpu1: add inline rotation support for sc7280

[Vinod Polimera]

- Some DPU versions support inline rot90. It is supported only for
limited amount of UBWC formats.
- There are two versions of inline rotators, v1 (present on sm8250 and
sm7250) and v2 (sc7280). These versions differ in the list of supported
formats and in the scaler possibilities.

Co-developed-by: Kalyan Thota 
Signed-off-by: Kalyan Thota 
Signed-off-by: Vinod Polimera 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 173 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 +++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 129 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   2 +
 4 files changed, 226 insertions(+), 94 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index a4fe77c..65ce505 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -35,6 +35,9 @@
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
 
+#define VIG_SC7280_MASK \
+   (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
+
 #define DMA_SDM845_MASK \
(BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
@@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
DRM_FORMAT_YVU420,
 };
 
+static const u32 rotation_v2_formats[] = {
+   DRM_FORMAT_NV12,
+   /* TODO add formats after validation */
+};
+
 /*
  * DPU sub blocks config
  */
@@ -642,7 +650,6 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
  */
 
 /* SSPP common configuration */
-
 #define _VIG_SBLK(num, sdma_pri, qseed_ver) \
{ \
.maxdwnscale = MAX_DOWNSCALE_RATIO, \
@@ -660,6 +667,27 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
.num_formats = ARRAY_SIZE(plane_formats_yuv), \
.virt_format_list = plane_formats, \
.virt_num_formats = ARRAY_SIZE(plane_formats), \
+   .rotation_cfg = NULL, \
+   }
+
+#define _VIG_SBLK_ROT(num, sdma_pri, qseed_ver, rot_cfg) \
+   { \
+   .maxdwnscale = MAX_DOWNSCALE_RATIO, \
+   .maxupscale = MAX_UPSCALE_RATIO, \
+   .smart_dma_priority = sdma_pri, \
+   .src_blk = {.name = STRCAT("sspp_src_", num), \
+   .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
+   .scaler_blk = {.name = STRCAT("sspp_scaler", num), \
+   .id = qseed_ver, \
+   .base = 0xa00, .len = 0xa0,}, \
+   .csc_blk = {.name = STRCAT("sspp_csc", num), \
+   .id = DPU_SSPP_CSC_10BIT, \
+   .base = 0x1a00, .len = 0x100,}, \
+   .format_list = plane_formats_yuv, \
+   .num_formats = ARRAY_SIZE(plane_formats_yuv), \
+   .virt_format_list = plane_formats, \
+   .virt_num_formats = ARRAY_SIZE(plane_formats), \
+   .rotation_cfg = rot_cfg, \
}
 
 #define _DMA_SBLK(num, sdma_pri) \
@@ -684,6 +712,12 @@ static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 =
 static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
_VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
 
+static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
+   .rot_maxheight = 1088,
+   .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
+   .rot_format_list = rotation_v2_formats,
+};
+
 static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
_VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
 static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
@@ -707,59 +741,62 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 = 
_DMA_SBLK("11", 4);
.sblk = &_sblk, \
.xin_id = _xinid, \
.type = _type, \
-   .clk_ctrl = _clkctrl \
+   .clk_ctrl = _clkctrl, \
}
 
 static const struct dpu_sspp_cfg msm8998_sspp[] = {
-   SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_MSM8998_MASK,
-   msm8998_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
-   SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_MSM8998_MASK,
-   msm8998_vig_sblk_1, 4,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
-   SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_MSM8998_MASK,
-   msm8998_vig_sblk_2, 8, SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG2),
-   SSPP_BLK("sspp_3", SSPP_VIG3, 0xa000, VIG_MSM8998_MASK,
-   msm8998_vig_sblk_3, 12,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG3),
-   SSPP_BLK("sspp_8", SSPP_DMA0, 0x24000,  DMA_MSM8998_MASK,
-   sdm845_dma_sblk_0, 1, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA0),
-   SSPP_BLK("sspp_9", SSPP_DMA1, 0x26000,  DMA_MSM8998_MASK,
-   sdm845_dma_sblk_1, 5, SSPP_TYPE_DMA, DPU_CLK_CTRL_DMA1),
-   SSPP_BLK("sspp_10", SSPP_DMA2, 0x28000,  DMA_CURSOR_M

[PATCH v7 1/2] drm/msm/disp/dpu1: add inline function to validate format support

[Vinod Polimera]

Check if the dpu format is supported or not using dpu_find_format.

Co-developed-by: Kalyan Thota 
Signed-off-by: Kalyan Thota 
Signed-off-by: Vinod Polimera 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h | 22 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 10 +++---
 2 files changed, 25 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
index 418f5ae..84b8b32 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
@@ -21,6 +21,28 @@ const struct dpu_format *dpu_get_dpu_format_ext(
 #define dpu_get_dpu_format(f) dpu_get_dpu_format_ext(f, 0)
 
 /**
+ * dpu_find_format - validate if the pixel format is supported
+ * @format:dpu format
+ * @supported_formats: supported formats by dpu HW
+ * @num_formatss:  total number of formats
+ *
+ * Return: false if not valid format, true on success
+ */
+static inline bool dpu_find_format(u32 format, const u32 *supported_formats,
+   size_t num_formats)
+{
+   int i;
+
+   for (i = 0; i < num_formats; i++) {
+   /* check for valid formats supported */
+   if (format == supported_formats[i])
+   return true;
+   }
+
+   return false;
+}
+
+/**
  * dpu_get_msm_format - get an dpu_format by its msm_format base
  * callback function registers with the msm_kms layer
  * @kms: kms driver
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
index 6565682..3216cda 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
@@ -1411,13 +1411,9 @@ static bool dpu_plane_format_mod_supported(struct 
drm_plane *plane,
if (modifier == DRM_FORMAT_MOD_LINEAR)
return true;
 
-   if (modifier == DRM_FORMAT_MOD_QCOM_COMPRESSED) {
-   int i;
-   for (i = 0; i < ARRAY_SIZE(qcom_compressed_supported_formats); 
i++) {
-   if (format == qcom_compressed_supported_formats[i])
-   return true;
-   }
-   }
+   if (modifier == DRM_FORMAT_MOD_QCOM_COMPRESSED)
+   return dpu_find_format(format, 
qcom_compressed_supported_formats,
+   ARRAY_SIZE(qcom_compressed_supported_formats));
 
return false;
 }
-- 
2.7.4

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Marek Vasut]

On 4/5/22 15:25, Dave Stevenson wrote:

On Tue, 5 Apr 2022 at 14:08, Laurent Pinchart
 wrote:


Hi Dave,

On Tue, Apr 05, 2022 at 01:00:28PM +0100, Dave Stevenson wrote:

On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart wrote:

On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:

In rare cases, the bridge may not start up correctly, which usually
leads to no display output. In case this happens, warn about it in
the kernel log.


Do you know what this is caused by ? It's a bit annoying to add a 10+ms
delay at start time just to be notified of rare cases.


The datasheet [1] section 7.4.2 Initialization Sequence states in step 2
"After power is applied and stable, the DSI CLK lanes MUST be in HS
state and the DSI data lanes MUST be driven
to LP11 state"
Data lanes shouldn't go to HS until step 8 after the DSI83 has been configured.

Configuration from the driver is being done from atomic_enable,
therefore the data lanes are likely in HS mode and sending video, not
LP11.

Deviate from the specified initialisation sequence at your peril!

The SN65DSI8[3|4|5] is one of the DSI devices that I'd been looking at
with the DSI ordering patches [2] so that we could initialise it in
the way specified in the datasheet. I've had no responses to v2 of
those patches though.


Sounds like I need to review that :-) It's still in my queue, I'll try
to push it to the top.

Do you think this patch could then be reverted ?


If we can initialise the DSI host before the bridge for the
pre_enable, then all the configuration moves to the atomic_pre_enable
and there should be no need to have the delay.

I can't 100% guarantee that, but one of the folks on the Pi forums is
using [1] which does that, and is reporting it working well. (He's
also using the DSI85 to take 2 DSI links and drive 2 LVDS single link
panels)


It seems to me that checking whether the bridge got correctly 
initialized is orthogonal to the aforementioned patchset though ?

Re: [PATCH v7 1/2] drm/msm/disp/dpu1: add inline function to validate format support

[Dmitry Baryshkov]

On Tue, 5 Apr 2022 at 16:41, Vinod Polimera  wrote:
>
> Check if the dpu format is supported or not using dpu_find_format.
>
> Co-developed-by: Kalyan Thota 
> Signed-off-by: Kalyan Thota 
> Signed-off-by: Vinod Polimera 

Reviewed-by: Dmitry Baryshkov 

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h | 22 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c   | 10 +++---
>  2 files changed, 25 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
> index 418f5ae..84b8b32 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_formats.h
> @@ -21,6 +21,28 @@ const struct dpu_format *dpu_get_dpu_format_ext(
>  #define dpu_get_dpu_format(f) dpu_get_dpu_format_ext(f, 0)
>
>  /**
> + * dpu_find_format - validate if the pixel format is supported
> + * @format:dpu format
> + * @supported_formats: supported formats by dpu HW
> + * @num_formatss:  total number of formats
> + *
> + * Return: false if not valid format, true on success
> + */
> +static inline bool dpu_find_format(u32 format, const u32 *supported_formats,
> +   size_t num_formats)
> +{
> +   int i;
> +
> +   for (i = 0; i < num_formats; i++) {
> +   /* check for valid formats supported */
> +   if (format == supported_formats[i])
> +   return true;
> +   }
> +
> +   return false;
> +}
> +
> +/**
>   * dpu_get_msm_format - get an dpu_format by its msm_format base
>   * callback function registers with the msm_kms layer
>   * @kms: kms driver
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> index 6565682..3216cda 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c
> @@ -1411,13 +1411,9 @@ static bool dpu_plane_format_mod_supported(struct 
> drm_plane *plane,
> if (modifier == DRM_FORMAT_MOD_LINEAR)
> return true;
>
> -   if (modifier == DRM_FORMAT_MOD_QCOM_COMPRESSED) {
> -   int i;
> -   for (i = 0; i < 
> ARRAY_SIZE(qcom_compressed_supported_formats); i++) {
> -   if (format == qcom_compressed_supported_formats[i])
> -   return true;
> -   }
> -   }
> +   if (modifier == DRM_FORMAT_MOD_QCOM_COMPRESSED)
> +   return dpu_find_format(format, 
> qcom_compressed_supported_formats,
> +   
> ARRAY_SIZE(qcom_compressed_supported_formats));
>
> return false;
>  }
> --
> 2.7.4
>


-- 
With best wishes
Dmitry

Re: [PATCH v7 2/2] drm/msm/disp/dpu1: add inline rotation support for sc7280

[Dmitry Baryshkov]

On Tue, 5 Apr 2022 at 16:41, Vinod Polimera  wrote:
>
> - Some DPU versions support inline rot90. It is supported only for
> limited amount of UBWC formats.
> - There are two versions of inline rotators, v1 (present on sm8250 and
> sm7250) and v2 (sc7280). These versions differ in the list of supported
> formats and in the scaler possibilities.
>
> Co-developed-by: Kalyan Thota 
> Signed-off-by: Kalyan Thota 
> Signed-off-by: Vinod Polimera 

Few minor comments below. Otherwise it looks really good now.

> ---
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 173 
> +++--
>  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |  16 +++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c  | 129 ++
>  drivers/gpu/drm/msm/disp/dpu1/dpu_plane.h  |   2 +
>  4 files changed, 226 insertions(+), 94 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
> b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> index a4fe77c..65ce505 100644
> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
> @@ -35,6 +35,9 @@
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> BIT(DPU_SSPP_CDP) | BIT(DPU_SSPP_EXCL_RECT))
>
> +#define VIG_SC7280_MASK \
> +   (VIG_SC7180_MASK | BIT(DPU_SSPP_INLINE_ROTATION))
> +
>  #define DMA_SDM845_MASK \
> (BIT(DPU_SSPP_SRC) | BIT(DPU_SSPP_QOS) | BIT(DPU_SSPP_QOS_8LVL) |\
> BIT(DPU_SSPP_TS_PREFILL) | BIT(DPU_SSPP_TS_PREFILL_REC1) |\
> @@ -203,6 +206,11 @@ static const uint32_t plane_formats_yuv[] = {
> DRM_FORMAT_YVU420,
>  };
>
> +static const u32 rotation_v2_formats[] = {
> +   DRM_FORMAT_NV12,
> +   /* TODO add formats after validation */
> +};
> +
>  /*
>   * DPU sub blocks config
>   */
> @@ -642,7 +650,6 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
>   */
>
>  /* SSPP common configuration */
> -
>  #define _VIG_SBLK(num, sdma_pri, qseed_ver) \
> { \
> .maxdwnscale = MAX_DOWNSCALE_RATIO, \
> @@ -660,6 +667,27 @@ static const struct dpu_ctl_cfg qcm2290_ctl[] = {
> .num_formats = ARRAY_SIZE(plane_formats_yuv), \
> .virt_format_list = plane_formats, \
> .virt_num_formats = ARRAY_SIZE(plane_formats), \
> +   .rotation_cfg = NULL, \
> +   }
> +
> +#define _VIG_SBLK_ROT(num, sdma_pri, qseed_ver, rot_cfg) \
> +   { \
> +   .maxdwnscale = MAX_DOWNSCALE_RATIO, \
> +   .maxupscale = MAX_UPSCALE_RATIO, \
> +   .smart_dma_priority = sdma_pri, \
> +   .src_blk = {.name = STRCAT("sspp_src_", num), \
> +   .id = DPU_SSPP_SRC, .base = 0x00, .len = 0x150,}, \
> +   .scaler_blk = {.name = STRCAT("sspp_scaler", num), \
> +   .id = qseed_ver, \
> +   .base = 0xa00, .len = 0xa0,}, \
> +   .csc_blk = {.name = STRCAT("sspp_csc", num), \
> +   .id = DPU_SSPP_CSC_10BIT, \
> +   .base = 0x1a00, .len = 0x100,}, \
> +   .format_list = plane_formats_yuv, \
> +   .num_formats = ARRAY_SIZE(plane_formats_yuv), \
> +   .virt_format_list = plane_formats, \
> +   .virt_num_formats = ARRAY_SIZE(plane_formats), \
> +   .rotation_cfg = rot_cfg, \
> }
>
>  #define _DMA_SBLK(num, sdma_pri) \
> @@ -684,6 +712,12 @@ static const struct dpu_sspp_sub_blks msm8998_vig_sblk_2 
> =
>  static const struct dpu_sspp_sub_blks msm8998_vig_sblk_3 =
> _VIG_SBLK("3", 0, DPU_SSPP_SCALER_QSEED3);
>
> +static const struct dpu_rotation_cfg dpu_rot_sc7280_cfg_v2 = {
> +   .rot_maxheight = 1088,
> +   .rot_num_formats = ARRAY_SIZE(rotation_v2_formats),
> +   .rot_format_list = rotation_v2_formats,
> +};
> +
>  static const struct dpu_sspp_sub_blks sdm845_vig_sblk_0 =
> _VIG_SBLK("0", 5, DPU_SSPP_SCALER_QSEED3);
>  static const struct dpu_sspp_sub_blks sdm845_vig_sblk_1 =
> @@ -707,59 +741,62 @@ static const struct dpu_sspp_sub_blks sdm845_dma_sblk_3 
> = _DMA_SBLK("11", 4);
> .sblk = &_sblk, \
> .xin_id = _xinid, \
> .type = _type, \
> -   .clk_ctrl = _clkctrl \
> +   .clk_ctrl = _clkctrl, \

You don't need this change. And also you don't need to change SSPP_BLK
lines that follow. Could you please drop these changes and resend?

The only chunk in this part that you really need is the addition of
sc7280_vig_sblk_0.

> }
>
>  static const struct dpu_sspp_cfg msm8998_sspp[] = {
> -   SSPP_BLK("sspp_0", SSPP_VIG0, 0x4000, VIG_MSM8998_MASK,
> -   msm8998_vig_sblk_0, 0,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG0),
> -   SSPP_BLK("sspp_1", SSPP_VIG1, 0x6000, VIG_MSM8998_MASK,
> -   msm8998_vig_sblk_1, 4,  SSPP_TYPE_VIG, DPU_CLK_CTRL_VIG1),
> -   SSPP_BLK("sspp_2", SSPP_VIG2, 0x8000, VIG_MSM8998_MASK,
>

Re: [PATCH] drm/amdgpu: Junk code

[Alex Deucher]

On Tue, Apr 5, 2022 at 5:07 AM Grigory Vasilyev  wrote:
>
> Variable igp_lane_info always is 0. 0 & any value = 0 and false.
> In this way, all сonditional statements will false.
> Therefore, it is not clear what this code does.

It was leftover from when the code was ported from radeon.  The igp
lane info was available from the vbios on older APUs.  It's not
relevant on any asics supported by amdgpu.  I've applied the patch and
clarified the commit message.

Thanks,

Alex

>
> Signed-off-by: Grigory Vasilyev 
> ---
>  .../gpu/drm/amd/amdgpu/atombios_encoders.c| 21 ---
>  1 file changed, 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c 
> b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> index 2b0cc793291c..100bad2f5901 100644
> --- a/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> +++ b/drivers/gpu/drm/amd/amdgpu/atombios_encoders.c
> @@ -769,7 +769,6 @@ amdgpu_atombios_encoder_setup_dig_transmitter(struct 
> drm_encoder *encoder, int a
> int dp_clock = 0;
> int dp_lane_count = 0;
> int connector_object_id = 0;
> -   int igp_lane_info = 0;
> int dig_encoder = dig->dig_encoder;
> int hpd_id = AMDGPU_HPD_NONE;
>
> @@ -852,26 +851,6 @@ amdgpu_atombios_encoder_setup_dig_transmitter(struct 
> drm_encoder *encoder, int a
> else
> args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_DIG1_ENCODER;
>
> -   if ((adev->flags & AMD_IS_APU) &&
> -   (amdgpu_encoder->encoder_id == 
> ENCODER_OBJECT_ID_INTERNAL_UNIPHY)) {
> -   if (is_dp ||
> -   !amdgpu_dig_monitor_is_duallink(encoder, 
> amdgpu_encoder->pixel_clock)) {
> -   if (igp_lane_info & 0x1)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_0_3;
> -   else if (igp_lane_info & 0x2)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_4_7;
> -   else if (igp_lane_info & 0x4)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_8_11;
> -   else if (igp_lane_info & 0x8)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_12_15;
> -   } else {
> -   if (igp_lane_info & 0x3)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_0_7;
> -   else if (igp_lane_info & 0xc)
> -   args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LANE_8_15;
> -   }
> -   }
> -
> if (dig->linkb)
> args.v1.ucConfig |= 
> ATOM_TRANSMITTER_CONFIG_LINKB;
> else
> --
> 2.35.1
>

Re: [PATCH v6 13/14] drm/msm: Update generated headers

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 19:35, Vinod Koul  wrote:
>
> Update headers from mesa commit:
>
>   commit 28ae397be111c37c6ced397e12d453a7695701bd
>   Author: Vinod Koul 
>   Date:   Fri Apr 1 16:53:04 2022 +0530
>
>   freedreno/registers: update dsi registers to support dsc
>
>   Display Stream compression (DSC) compresses the display stream in
>   host which is later decoded by panel. This requires addition of 3 new
>   DSI registers to support DSC over DSI.
>
>   Signed-off-by: Vinod Koul 
>   Part-of: 
> 
>
> Signed-off-by: Vinod Koul 

Reviewed-by: Dmitry Baryshkov 


> ---
>  drivers/gpu/drm/msm/dsi/dsi.xml.h | 80 +++
>  1 file changed, 80 insertions(+)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi.xml.h 
> b/drivers/gpu/drm/msm/dsi/dsi.xml.h
> index 4dee6f0bdda6..d1b2a17b0a66 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi.xml.h
> +++ b/drivers/gpu/drm/msm/dsi/dsi.xml.h
> @@ -704,5 +704,85 @@ static inline uint32_t DSI_VERSION_MAJOR(uint32_t val)
>
>  #define REG_DSI_CPHY_MODE_CTRL 0x02d4
>
> +#define REG_DSI_VIDEO_COMPRESSION_MODE_CTRL0x029c
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK   0x
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT  16
> +static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_WC(uint32_t val)
> +{
> +   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__SHIFT) & 
> DSI_VIDEO_COMPRESSION_MODE_CTRL_WC__MASK;
> +}
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK 0x3f00
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT8
> +static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(uint32_t val)
> +{
> +   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__SHIFT) & 
> DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE__MASK;
> +}
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK 0x00c0
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT6
> +static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(uint32_t 
> val)
> +{
> +   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__SHIFT) 
> & DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE__MASK;
> +}
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK 0x0030
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT4
> +static inline uint32_t DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(uint32_t 
> val)
> +{
> +   return ((val) << DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__SHIFT) 
> & DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM__MASK;
> +}
> +#define DSI_VIDEO_COMPRESSION_MODE_CTRL_EN 0x0001
> +
> +#define REG_DSI_COMMAND_COMPRESSION_MODE_CTRL  0x02a4
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK   
> 0x3f00
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT  24
> +static inline uint32_t 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE(uint32_t val)
> +{
> +   return ((val) << 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__SHIFT) & 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_DATATYPE__MASK;
> +}
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK   
> 0x00c0
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT  22
> +static inline uint32_t 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE(uint32_t val)
> +{
> +   return ((val) << 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__SHIFT) & 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_PKT_PER_LINE__MASK;
> +}
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK   
> 0x0030
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT  20
> +static inline uint32_t 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM(uint32_t val)
> +{
> +   return ((val) << 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__SHIFT) & 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EOL_BYTE_NUM__MASK;
> +}
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM1_EN   0x0001
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK   
> 0x3f00
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT  8
> +static inline uint32_t 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(uint32_t val)
> +{
> +   return ((val) << 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__SHIFT) & 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE__MASK;
> +}
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__MASK   
> 0x00c0
> +#define DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE__SHIFT  6
> +static inline uint32_t 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_LINE(uint32_t val)
> +{
> +   return ((val) << 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_PKT_PER_

Re: [PATCH v6 14/14] drm/msm/dsi: Add support for DSC configuration

[Dmitry Baryshkov]

On Mon, 4 Apr 2022 at 19:35, Vinod Koul  wrote:
>
> When DSC is enabled, we need to configure DSI registers accordingly and
> configure the respective stream compression registers.
>
> Add support to calculate the register setting based on DSC params and
> timing information and configure these registers.
>
> Signed-off-by: Dmitry Baryshkov 
> Signed-off-by: Vinod Koul 

Reviewed-by: Dmitry Baryshkov 


> ---
>  drivers/gpu/drm/msm/dsi/dsi_host.c | 98 +-
>  1 file changed, 97 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index eb0be34add45..f3ed6c40b9e1 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -912,6 +912,65 @@ static void dsi_ctrl_config(struct msm_dsi_host 
> *msm_host, bool enable,
> dsi_write(msm_host, REG_DSI_CPHY_MODE_CTRL, BIT(0));
>  }
>
> +static void dsi_update_dsc_timing(struct msm_dsi_host *msm_host, bool 
> is_cmd_mode, u32 hdisplay)
> +{
> +   struct msm_display_dsc_config *dsc = msm_host->dsc;
> +   u32 reg, intf_width, reg_ctrl, reg_ctrl2;
> +   u32 slice_per_intf, total_bytes_per_intf;
> +   u32 pkt_per_line;
> +   u32 bytes_in_slice;
> +   u32 eol_byte_num;
> +
> +   /* first calculate dsc parameters and then program
> +* compress mode registers
> +*/
> +   intf_width = hdisplay;
> +   slice_per_intf = DIV_ROUND_UP(intf_width, dsc->drm->slice_width);
> +
> +   /* If slice_per_pkt is greater than slice_per_intf
> +* then default to 1. This can happen during partial
> +* update.
> +*/
> +   if (slice_per_intf > dsc->drm->slice_count)
> +   dsc->drm->slice_count = 1;
> +
> +   slice_per_intf = DIV_ROUND_UP(hdisplay, dsc->drm->slice_width);
> +   bytes_in_slice = DIV_ROUND_UP(dsc->drm->slice_width * 
> dsc->drm->bits_per_pixel, 8);
> +
> +   dsc->drm->slice_chunk_size = bytes_in_slice;
> +
> +   total_bytes_per_intf = bytes_in_slice * slice_per_intf;
> +
> +   eol_byte_num = total_bytes_per_intf % 3;
> +   pkt_per_line = slice_per_intf / dsc->drm->slice_count;
> +
> +   if (is_cmd_mode) /* packet data type */
> +   reg = 
> DSI_COMMAND_COMPRESSION_MODE_CTRL_STREAM0_DATATYPE(MIPI_DSI_DCS_LONG_WRITE);
> +   else
> +   reg = 
> DSI_VIDEO_COMPRESSION_MODE_CTRL_DATATYPE(MIPI_DSI_COMPRESSED_PIXEL_STREAM);
> +
> +   /* DSI_VIDEO_COMPRESSION_MODE & DSI_COMMAND_COMPRESSION_MODE
> +* registers have similar offsets, so for below common code use
> +* DSI_VIDEO_COMPRESSION_MODE_ for setting bits
> +*/
> +   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_PKT_PER_LINE(pkt_per_line >> 
> 1);
> +   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EOL_BYTE_NUM(eol_byte_num);
> +   reg |= DSI_VIDEO_COMPRESSION_MODE_CTRL_EN;
> +
> +   if (is_cmd_mode) {
> +   reg_ctrl = dsi_read(msm_host, 
> REG_DSI_COMMAND_COMPRESSION_MODE_CTRL);
> +   reg_ctrl2 = dsi_read(msm_host, 
> REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2);
> +
> +   reg_ctrl |= reg;
> +   reg_ctrl2 |= 
> DSI_COMMAND_COMPRESSION_MODE_CTRL2_STREAM0_SLICE_WIDTH(bytes_in_slice);
> +
> +   dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL, 
> reg);
> +   dsi_write(msm_host, REG_DSI_COMMAND_COMPRESSION_MODE_CTRL2, 
> reg_ctrl2);
> +   } else {
> +   dsi_write(msm_host, REG_DSI_VIDEO_COMPRESSION_MODE_CTRL, reg);
> +   }
> +}
> +
>  static void dsi_timing_setup(struct msm_dsi_host *msm_host, bool 
> is_bonded_dsi)
>  {
> struct drm_display_mode *mode = msm_host->mode;
> @@ -944,7 +1003,38 @@ static void dsi_timing_setup(struct msm_dsi_host 
> *msm_host, bool is_bonded_dsi)
> hdisplay /= 2;
> }
>
> +   if (msm_host->dsc) {
> +   struct msm_display_dsc_config *dsc = msm_host->dsc;
> +
> +   /* update dsc params with timing params */
> +   if (!dsc || !mode->hdisplay || !mode->vdisplay) {
> +   pr_err("DSI: invalid input: pic_width: %d pic_height: 
> %d\n",
> +  mode->hdisplay, mode->vdisplay);
> +   return;
> +   }
> +
> +   dsc->drm->pic_width = mode->hdisplay;
> +   dsc->drm->pic_height = mode->vdisplay;
> +   DBG("Mode %dx%d\n", dsc->drm->pic_width, 
> dsc->drm->pic_height);
> +
> +   /* we do the calculations for dsc parameters here so that
> +* panel can use these parameters
> +*/
> +   dsi_populate_dsc_params(dsc);
> +
> +   /* Divide the display by 3 but keep back/font porch and
> +* pulse width same
> +*/
> +   h_total -= hdisplay;
> +   hdisplay /= 3;
> +   h_total += hdisplay;
> + 

Re: [PATCH 1/3] drm/vmwgfx: Add debugfs entries for ttm placements

[Zack Rusin]

On Mon, 2022-04-04 at 17:38 +0200, Daniel Vetter wrote:
> On Fri, Apr 01, 2022 at 04:56:00PM -0400, Zack Rusin wrote:
> > From: Zack Rusin 
> > 
> > Add a few debugfs entries for every used TTM placement that vmwgfx
> > is
> > using. This allows basic tracking of memory usage inside vmwgfx,
> > e.g.
> > 'cat /sys/kernel/debug/dri/0/mob_ttm' will display mob memory
> > usage.
> > 
> > Signed-off-by: Zack Rusin 
> > Reviewed-by: Martin Krastev 
> > ---
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.c    |  1 +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_drv.h    |  1 +
> >  drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 97
> > +-
> >  3 files changed, 98 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > index 791f9a5f3868..6d675855f065 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
> > @@ -1632,6 +1632,7 @@ static int vmw_probe(struct pci_dev *pdev,
> > const struct pci_device_id *ent)
> >   goto out_unload;
> > 
> >   vmw_debugfs_gem_init(vmw);
> > + vmw_ttm_debugfs_init(vmw);
> > 
> >   return 0;
> >  out_unload:
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > index be19aa6e1f13..eabe3e8e9cf9 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
> > @@ -1085,6 +1085,7 @@ vmw_bo_sg_table(struct ttm_buffer_object
> > *bo);
> >  extern int vmw_bo_create_and_populate(struct vmw_private
> > *dev_priv,
> >     unsigned long bo_size,
> >     struct ttm_buffer_object
> > **bo_p);
> > +void vmw_ttm_debugfs_init(struct vmw_private *vdev);
> > 
> >  extern void vmw_piter_start(struct vmw_piter *viter,
> >   const struct vmw_sg_table *vsgt,
> > diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > index b84ecc6d6611..355414595e52 100644
> > --- a/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c
> > @@ -1,7 +1,7 @@
> >  // SPDX-License-Identifier: GPL-2.0 OR MIT
> >  /*
> > *
> >   *
> > - * Copyright 2009-2015 VMware, Inc., Palo Alto, CA., USA
> > + * Copyright 2009-2022 VMware, Inc., Palo Alto, CA., USA
> >   *
> >   * Permission is hereby granted, free of charge, to any person
> > obtaining a
> >   * copy of this software and associated documentation files (the
> > @@ -677,3 +677,98 @@ int vmw_bo_create_and_populate(struct
> > vmw_private *dev_priv,
> >   *bo_p = bo;
> >   return ret;
> >  }
> > +
> > +#if defined(CONFIG_DEBUG_FS)
> > +
> > +static int vmw_ttm_vram_table_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private *vdev = (struct vmw_private *)m->private;
> > + struct ttm_resource_manager *man = ttm_manager_type(&vdev-
> > >bdev,
> > +
> > TTM_PL_VRAM);
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + ttm_resource_manager_debug(man, &p);
> > + return 0;
> > +}
> > +
> > +static int vmw_ttm_page_pool_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private *vdev = (struct vmw_private *)m->private;
> > +
> > + return ttm_pool_debugfs(&vdev->bdev.pool, m);
> > +}
> > +
> > +static int vmw_ttm_mob_table_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private *vdev = (struct vmw_private *)m->private;
> > + struct ttm_resource_manager *man = ttm_manager_type(&vdev-
> > >bdev,
> > +
> > VMW_PL_MOB);
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + ttm_resource_manager_debug(man, &p);
> > + return 0;
> > +}
> > +
> > +static int vmw_ttm_gmr_table_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private *vdev = (struct vmw_private *)m->private;
> > + struct ttm_resource_manager *man = ttm_manager_type(&vdev-
> > >bdev,
> > +
> > VMW_PL_GMR);
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + ttm_resource_manager_debug(man, &p);
> > + return 0;
> > +}
> > +
> > +static int vmw_ttm_system_table_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private *vdev = (struct vmw_private *)m->private;
> > + struct ttm_resource_manager *man = ttm_manager_type(&vdev-
> > >bdev,
> > +
> > TTM_PL_SYSTEM);
> > + struct drm_printer p = drm_seq_file_printer(m);
> > +
> > + ttm_resource_manager_debug(man, &p);
> > + return 0;
> > +}
> > +
> > +static int vmw_ttm_system_mob_table_show(struct seq_file *m, void
> > *unused)
> > +{
> > + struct vmw_private 

Re: Public patches but non-public development branch

[Paul Menzel]

Dear Alex,


Am 05.04.22 um 15:14 schrieb Alex Deucher:

On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:



Am 05.04.22 um 08:54 schrieb Christian König:

Am 05.04.22 um 08:45 schrieb Paul Menzel:



Am 04.04.22 um 23:42 schrieb Philip Yang:

bo_adev is NULL for system memory mapping to GPU.

Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)


Sorry, where can I find that commit?


Well that's expected, the development branch is not public.


Well obviously, it was unexpected for me. How should I have known? Where
is that documented? If the patches are publicly posted to the mailing
list, why is that development branch not public?

The current situation is really frustrating for non-AMD employees. How
can the current situation be improved?


Our development branch
(https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
is available publicly.  There can be a day or so of lag depending on
when it gets mirrored (e.g., over the weekend).


Thank you for the clarification. As can be seen at hand, it still causes 
confusion though.


commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
Author: Christian König 
AuthorDate: Wed Mar 30 10:53:15 2022 +0200
Commit: Christian König 
CommitDate: Fri Apr 1 11:05:51 2022 +0200

Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.

To avoid this friction in the future, is there an automated way to 
mirror the branches? git hooks should allow that to be done on every 
push for example.



Kind regards,

Paul

Re: [PATCH] i2c: at91: use dma safe buffers

[Michael Walle]

Am 2022-04-05 15:58, schrieb codrin.ciubota...@microchip.com:

On 05.04.2022 14:09, Michael Walle wrote:

Am 2022-04-05 12:02, schrieb codrin.ciubota...@microchip.com:

On 05.04.2022 12:38, Michael Walle wrote:

Am 2022-04-05 11:23, schrieb codrin.ciubota...@microchip.com:

+   if (dev->use_dma) {
+   dma_buf = i2c_get_dma_safe_msg_buf(m_start, 1);


If you want, you could just dev->buf = i2c_get_dma_safe...


But where is the error handling in that case? dev->buf will
be NULL, which is eventually passed to dma_map_single().

Also, I need the dma_buf for the i2c_put_dma_safe_msg_buf()
call anyway, because dev->buf will be modified during
processing.


You still:
  if (!dev->buf) {
  ret = -ENOMEM;
  goto out;
  }

So, at91_do_twi_transfer()/dma_map_single() will not be called.


Ahh, I misunderstood you. Yes, but as I said, I need the dma_buf
temporary variable anyway, because dev->buf is modified, eg. see
at91_twi_read_data_dma_callback().

at91_twi_read_data_dma_callback() is called as callback if
dma_async_issue_pending(dma->chan_rx) is called.
dma_async_issue_pending(dma->chan_rx) is called on
at91_twi_read_data_dma(), which is called in at91_do_twi_transfer(),
which we decided above to skip in case of error.


It is not about errors, you need the exact same pointer you
got from i2c_get_dma_safe_msg_buf() to be passed to
i2c_put_dma_safe_msg_buf(). And because (in some cases, it
isn't really obvious) the dev->buf will be advanced a few
bytes, I cannot pass dev->buf to i2c_put_dma_safe_msg_buf().

-michael

Re: [PATCH] fbdev: Fix unregistering of framebuffers without device

[Javier Martinez Canillas]

Hello Thomas,

On 4/4/22 21:44, Thomas Zimmermann wrote:
> OF framebuffers do not have an underlying device in the Linux
> device hierarchy. Do a regular unregister call instead of hot
> unplugging such a non-existing device. Fixes a NULL dereference.
> An example error message on ppc64le is shown below.
> 
>   BUG: Kernel NULL pointer dereference on read at 0x0060
>   Faulting instruction address: 0xc080dfa4
>   Oops: Kernel access of bad area, sig: 11 [#1]
>   LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
>   [...]
>   CPU: 2 PID: 139 Comm: systemd-udevd Not tainted 5.17.0-ae085d7f9365 #1
>   NIP:  c080dfa4 LR: c080df9c CTR: c0797430
>   REGS: c4132fe0 TRAP: 0300   Not tainted  (5.17.0-ae085d7f9365)
>   MSR:  82009033   CR: 28228282  XER: 
> 2000
>   CFAR: c000c80c DAR: 0060 DSISR: 4000 IRQMASK: 0
>   GPR00: c080df9c c4133280 c169d200 0029
>   GPR04: efff c4132f90 c4132f88 
>   GPR08: c15658f8 c15cd200 c14f57d0 48228283
>   GPR12:  c0003fffe300 2000 
>   GPR16:  000113fc4a40 0005 000113fcfb80
>   GPR20: 01000f7283b0  c0e4a588 c0e4a5b0
>   GPR24: 0001 000a c00800db0168 c21f6ec0
>   GPR28: c16d65a8 c4b36460  c16d64b0
>   NIP [c080dfa4] do_remove_conflicting_framebuffers+0x184/0x1d0
>   [c4133280] [c080df9c] 
> do_remove_conflicting_framebuffers+0x17c/0x1d0 (unreliable)
>   [c4133350] [c080e4d0] 
> remove_conflicting_framebuffers+0x60/0x150
>   [c41333a0] [c080e6f4] 
> remove_conflicting_pci_framebuffers+0x134/0x1b0
>   [c4133450] [c00800e70438] 
> drm_aperture_remove_conflicting_pci_framebuffers+0x90/0x100 [drm]
>   [c4133490] [c00800da0ce4] bochs_pci_probe+0x6c/0xa64 [bochs]
>   [...]
>   [c4133db0] [c002aaa0] system_call_exception+0x170/0x2d0
>   [c4133e10] [c000c3cc] system_call_common+0xec/0x250
> 
> The bug [1] was introduced by commit 27599aacbaef ("fbdev: Hot-unplug
> firmware fb devices on forced removal"). Most firmware framebuffers
> have an underlying platform device, which can be hot-unplugged
> before loading the native graphics driver. OF framebuffers do not
> (yet) have that device. Fix the code by unregistering the framebuffer
> as before without a hot unplug.
>

I believe the assumption that all firmware fb would have an underlying
device was a reasonable one and it's a pity that offb doesn't...

But that is how things are and your patch is the least intrusive fix.
 
Reviewed-by: Javier Martinez Canillas 

-- 
Best regards,

Javier Martinez Canillas
Linux Engineering
Red Hat

[PATCH] drm/arm/malidp: Stop using iommu_present()

[Robin Murphy]

iommu_get_domain_for_dev() is already perfectly happy to return NULL
if the given device has no IOMMU. Drop the unnecessary check.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/arm/malidp_planes.c | 14 +-
 1 file changed, 5 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 0562bdaac00c..81d9f5004025 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -310,17 +310,13 @@ static int malidp_se_check_scaling(struct malidp_plane 
*mp,
 
 static u32 malidp_get_pgsize_bitmap(struct malidp_plane *mp)
 {
-   u32 pgsize_bitmap = 0;
+   struct iommu_domain *mmu_dom;
 
-   if (iommu_present(&platform_bus_type)) {
-   struct iommu_domain *mmu_dom =
-   iommu_get_domain_for_dev(mp->base.dev->dev);
+   mmu_dom = iommu_get_domain_for_dev(mp->base.dev->dev);
+   if (mmu_dom)
+   return mmu_dom->pgsize_bitmap;
 
-   if (mmu_dom)
-   pgsize_bitmap = mmu_dom->pgsize_bitmap;
-   }
-
-   return pgsize_bitmap;
+   return 0;
 }
 
 /*
-- 
2.28.0.dirty

Re: Public patches but non-public development branch

[Alex Deucher]

On Tue, Apr 5, 2022 at 10:03 AM Paul Menzel  wrote:
>
> Dear Alex,
>
>
> Am 05.04.22 um 15:14 schrieb Alex Deucher:
> > On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:
>
> >> Am 05.04.22 um 08:54 schrieb Christian König:
> >>> Am 05.04.22 um 08:45 schrieb Paul Menzel:
> >>
>  Am 04.04.22 um 23:42 schrieb Philip Yang:
> > bo_adev is NULL for system memory mapping to GPU.
> >
> > Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)
> 
>  Sorry, where can I find that commit?
> >>>
> >>> Well that's expected, the development branch is not public.
> >>
> >> Well obviously, it was unexpected for me. How should I have known? Where
> >> is that documented? If the patches are publicly posted to the mailing
> >> list, why is that development branch not public?
> >>
> >> The current situation is really frustrating for non-AMD employees. How
> >> can the current situation be improved?
> >
> > Our development branch
> > (https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
> > is available publicly.  There can be a day or so of lag depending on
> > when it gets mirrored (e.g., over the weekend).
>
> Thank you for the clarification. As can be seen at hand, it still causes
> confusion though.
>
>  commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
>  Author: Christian König 
>  AuthorDate: Wed Mar 30 10:53:15 2022 +0200
>  Commit: Christian König 
>  CommitDate: Fri Apr 1 11:05:51 2022 +0200
>
> Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.
>
> To avoid this friction in the future, is there an automated way to
> mirror the branches? git hooks should allow that to be done on every
> push for example.

It's a bit more complicated than that since we have various CI systems
and IT security policies involved, but we can look into it.

Alex

[PATCH] drm/mediatek: Stop using iommu_present()

[Robin Murphy]

Remove the pointless check. If an IOMMU is providing transparent DMA API
ops for any device(s) we care about, the DT code will have enforced the
appropriate probe ordering already.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 247c6ff277ef..2de31746a308 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -5,7 +5,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -239,9 +238,6 @@ static int mtk_drm_kms_init(struct drm_device *drm)
if (drm_firmware_drivers_only())
return -ENODEV;
 
-   if (!iommu_present(&platform_bus_type))
-   return -EPROBE_DEFER;
-
pdev = of_find_device_by_node(private->mutex_node);
if (!pdev) {
dev_err(drm->dev, "Waiting for disp-mutex device %pOF\n",
-- 
2.28.0.dirty

Re: Public patches but non-public development branch

[Paul Menzel]

Dear Alex,


Am 05.04.22 um 16:13 schrieb Alex Deucher:

On Tue, Apr 5, 2022 at 10:03 AM Paul Menzel  wrote:



Am 05.04.22 um 15:14 schrieb Alex Deucher:

On Tue, Apr 5, 2022 at 3:02 AM Paul Menzel wrote:



Am 05.04.22 um 08:54 schrieb Christian König:

Am 05.04.22 um 08:45 schrieb Paul Menzel:



Am 04.04.22 um 23:42 schrieb Philip Yang:

bo_adev is NULL for system memory mapping to GPU.

Fixes: 05fe8eeca92 (drm/amdgpu: fix TLB flushing during eviction)


Sorry, where can I find that commit?


Well that's expected, the development branch is not public.


Well obviously, it was unexpected for me. How should I have known? Where
is that documented? If the patches are publicly posted to the mailing
list, why is that development branch not public?

The current situation is really frustrating for non-AMD employees. How
can the current situation be improved?


Our development branch
(https://gitlab.freedesktop.org/agd5f/linux/-/commits/amd-staging-drm-next)
is available publicly.  There can be a day or so of lag depending on
when it gets mirrored (e.g., over the weekend).


Thank you for the clarification. As can be seen at hand, it still causes
confusion though.

  commit 05fe8eeca927e29b81f3f2a799e9b9b88b0989a9
  Author: Christian König 
  AuthorDate: Wed Mar 30 10:53:15 2022 +0200
  Commit: Christian König 
  CommitDate: Fri Apr 1 11:05:51 2022 +0200

Today is Tuesday, so it wasn’t mirrored yesterday, on Monday.

To avoid this friction in the future, is there an automated way to
mirror the branches? git hooks should allow that to be done on every
push for example.


It's a bit more complicated than that since we have various CI systems
and IT security policies involved, but we can look into it.


That’d be awesome. Thank you!


Kind regards,

Paul

[PATCH] drm/msm: Stop using iommu_present()

[Robin Murphy]

Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/msm/msm_drv.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index affa95eb05fc..9c36b505daab 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -274,7 +274,7 @@ bool msm_use_mmu(struct drm_device *dev)
struct msm_drm_private *priv = dev->dev_private;
 
/* a2xx comes with its own MMU */
-   return priv->is_a2xx || iommu_present(&platform_bus_type);
+   return priv->is_a2xx || device_iommu_mapped(dev->dev);
 }
 
 static int msm_init_vram(struct drm_device *dev)
-- 
2.28.0.dirty

[PATCH] drm/tegra: Stop using iommu_present()

[Robin Murphy]

Remove the pointless check. host1x_drm_wants_iommu() cannot return true
unless an IOMMU exists for the host1x platform device, which at the moment
means the iommu_present() test could never fail.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/tegra/drm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index 9464f522e257..bc4321561400 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -1149,7 +1149,7 @@ static int host1x_drm_probe(struct host1x_device *dev)
goto put;
}
 
-   if (host1x_drm_wants_iommu(dev) && iommu_present(&platform_bus_type)) {
+   if (host1x_drm_wants_iommu(dev)) {
tegra->domain = iommu_domain_alloc(&platform_bus_type);
if (!tegra->domain) {
err = -ENOMEM;
-- 
2.28.0.dirty

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Dave Stevenson]

Hi Marek.

On Tue, 5 Apr 2022 at 14:49, Marek Vasut  wrote:
>
> On 4/5/22 15:25, Dave Stevenson wrote:
> > On Tue, 5 Apr 2022 at 14:08, Laurent Pinchart
> >  wrote:
> >>
> >> Hi Dave,
> >>
> >> On Tue, Apr 05, 2022 at 01:00:28PM +0100, Dave Stevenson wrote:
> >>> On Tue, 5 Apr 2022 at 12:42, Laurent Pinchart wrote:
>  On Sun, Feb 13, 2022 at 03:26:48AM +0100, Marek Vasut wrote:
> > In rare cases, the bridge may not start up correctly, which usually
> > leads to no display output. In case this happens, warn about it in
> > the kernel log.
> 
>  Do you know what this is caused by ? It's a bit annoying to add a 10+ms
>  delay at start time just to be notified of rare cases.
> >>>
> >>> The datasheet [1] section 7.4.2 Initialization Sequence states in step 2
> >>> "After power is applied and stable, the DSI CLK lanes MUST be in HS
> >>> state and the DSI data lanes MUST be driven
> >>> to LP11 state"
> >>> Data lanes shouldn't go to HS until step 8 after the DSI83 has been 
> >>> configured.
> >>>
> >>> Configuration from the driver is being done from atomic_enable,
> >>> therefore the data lanes are likely in HS mode and sending video, not
> >>> LP11.
> >>>
> >>> Deviate from the specified initialisation sequence at your peril!
> >>>
> >>> The SN65DSI8[3|4|5] is one of the DSI devices that I'd been looking at
> >>> with the DSI ordering patches [2] so that we could initialise it in
> >>> the way specified in the datasheet. I've had no responses to v2 of
> >>> those patches though.
> >>
> >> Sounds like I need to review that :-) It's still in my queue, I'll try
> >> to push it to the top.
> >>
> >> Do you think this patch could then be reverted ?
> >
> > If we can initialise the DSI host before the bridge for the
> > pre_enable, then all the configuration moves to the atomic_pre_enable
> > and there should be no need to have the delay.
> >
> > I can't 100% guarantee that, but one of the folks on the Pi forums is
> > using [1] which does that, and is reporting it working well. (He's
> > also using the DSI85 to take 2 DSI links and drive 2 LVDS single link
> > panels)
>
> It seems to me that checking whether the bridge got correctly
> initialized is orthogonal to the aforementioned patchset though ?

It's the delay that is ugly.
Put the check in atomic_enable which will be slightly later than
configuration in pre_enable? Check that sufficient jiffies have passed
if you needed.
Or wire up the IRQ line from the SN65DSI83 rather than polling the IRQ
Status register. Delayed workqueue if the IRQ isn't wired up.

If I read it right your log message is triggered by any bit being set
in REG_IRQ_STAT. So an inconveniently timed correctable DSI error will
set bit 4 and log the error even though it's been corrected. Likewise
bit 7 / CHA_SYNCH_ERR could get triggered by an H or V sync packet
being received in that 10-12ms window (we're in atomic_enable, so
video is already running).

If it's the PLL being unlocked that is the issue then it should only
be checking bit 0. Or possibly reading the actual PLL lock status from
REG_RC_LVDS_PLL_PLL_EN_STAT. Although as we've already checked that
the PLL is locked via REG_RC_LVDS_PLL_PLL_EN_STAT earlier in the
atomic_enable, I'm now a little confused as to the condition you are
actually wanting to detect.

  Dave

[PATCH] drm/nouveau/tegra: Stop using iommu_present()

[Robin Murphy]

Even if some IOMMU has registered itself on the platform "bus", that
doesn't necessarily mean it provides translation for the device we
care about. Replace iommu_present() with a more appropriate check.

Signed-off-by: Robin Murphy 
---
 drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c 
b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
index 992cc285f2fe..2ed528c065fa 100644
--- a/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
+++ b/drivers/gpu/drm/nouveau/nvkm/engine/device/tegra.c
@@ -123,7 +123,7 @@ nvkm_device_tegra_probe_iommu(struct nvkm_device_tegra 
*tdev)
 
mutex_init(&tdev->iommu.mutex);
 
-   if (iommu_present(&platform_bus_type)) {
+   if (device_iommu_mapped(dev)) {
tdev->iommu.domain = iommu_domain_alloc(&platform_bus_type);
if (!tdev->iommu.domain)
goto error;
-- 
2.28.0.dirty

Re: AMDGPU: regression on 5.17.1

[Alex Deucher]

On Mon, Apr 4, 2022 at 3:39 PM Michele Ballabio  wrote:
>
> On Mon, 4 Apr 2022 13:03:41 -0400
> Alex Deucher  wrote:
>
> > On Sun, Apr 3, 2022 at 10:19 AM Michele Ballabio
> >  wrote:
> > >
> > > Hi,
> > > I've hit a regression on 5.17.1 (haven't tested 5.17.0, but
> > > 5.16-stable didn't have this problem).
> > >
> > > The machine is a Ryzen 5 1600 with AMD graphics (RX 560).
> > >
> > > The regression I hit seems to trigger when the machine is left
> > > idle at boot (I don't boot straight to X, I boot to a tty, login
> > > and then start X). The machine after a while blanks the screen.
> > > Usually, the screen unblanks as the keyboard is hit or the mouse
> > > moves, but with kernel 5.17.1 the screen does not wake up. The
> > > machine seems to run mostly fine: I can login from ssh, but I
> > > cannot reboot or halt it: a sysrq sequence is needed for that. Note
> > > that if the screen goes blank under X, it wakes up fine.
> > >
> > > Below a dmesg and two traces from syslog (they're quite similar).
> >
> > Can you bisect?  Does setting amdgpu.runpm=0 help?
>
> I can try to bisect, should I narrow the search to drivers/gpu/drm/ ?

I would just do a full bisect if possible in case the change happens
to be outside of drm.

>
> Setting amdgpu.runpm=0 works, the display now unblanks without problems.

Thanks,

Alex


>
> Thanks,
> Michele Ballabio

[PATCH] drm/rockchip: Refactor IOMMU initialisation

[Robin Murphy]

Defer the IOMMU domain setup until after successfully binding
components, so we can figure out IOMMU support directly from the VOP
devices themselves, rather than manually inferring it from the DT (which
also fails to account for whether the IOMMU driver is actually loaded).
Although this is somewhat of a logical cleanup, the main motivation is
to prepare for a change in the iommu_domain_alloc() interface.

Signed-off-by: Robin Murphy 
---

Lightly tested on RK3288. This does stand to collide with the in-flight
VOP2 driver a little, if only that that will want an equivalent
rockchip_drm_dma_init_device() call too be able to use its IOMMU. I'm
happy to help sort that out either way, it just depends on what we want
to merge first.

Thanks,
Robin.

 drivers/gpu/drm/rockchip/rockchip_drm_drv.c | 60 +
 drivers/gpu/drm/rockchip/rockchip_drm_drv.h |  3 ++
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  2 +
 3 files changed, 31 insertions(+), 34 deletions(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index 4eaeb430c83a..7efd12312354 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -7,7 +7,6 @@
  */
 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -34,7 +33,6 @@
 #define DRIVER_MAJOR   1
 #define DRIVER_MINOR   0
 
-static bool is_support_iommu = true;
 static const struct drm_driver rockchip_drm_driver;
 
 /*
@@ -48,7 +46,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct rockchip_drm_private *private = drm_dev->dev_private;
int ret;
 
-   if (!is_support_iommu)
+   if (!private->domain)
return 0;
 
ret = iommu_attach_device(private->domain, dev);
@@ -64,12 +62,22 @@ void rockchip_drm_dma_detach_device(struct drm_device 
*drm_dev,
struct device *dev)
 {
struct rockchip_drm_private *private = drm_dev->dev_private;
-   struct iommu_domain *domain = private->domain;
 
-   if (!is_support_iommu)
+   if (!private->domain)
return;
 
-   iommu_detach_device(domain, dev);
+   iommu_detach_device(private->domain, dev);
+}
+
+void rockchip_drm_dma_init_device(struct drm_device *drm_dev,
+ struct device *dev)
+{
+   struct rockchip_drm_private *private = drm_dev->dev_private;
+
+   if (!device_iommu_mapped(dev))
+   private->iommu_dev = ERR_PTR(-ENODEV);
+   else if (!private->iommu_dev)
+   private->iommu_dev = dev;
 }
 
 static int rockchip_drm_init_iommu(struct drm_device *drm_dev)
@@ -78,10 +86,10 @@ static int rockchip_drm_init_iommu(struct drm_device 
*drm_dev)
struct iommu_domain_geometry *geometry;
u64 start, end;
 
-   if (!is_support_iommu)
+   if (IS_ERR_OR_NULL(private->iommu_dev))
return 0;
 
-   private->domain = iommu_domain_alloc(&platform_bus_type);
+   private->domain = iommu_domain_alloc(private->iommu_dev->bus);
if (!private->domain)
return -ENOMEM;
 
@@ -101,7 +109,7 @@ static void rockchip_iommu_cleanup(struct drm_device 
*drm_dev)
 {
struct rockchip_drm_private *private = drm_dev->dev_private;
 
-   if (!is_support_iommu)
+   if (!private->domain)
return;
 
drm_mm_takedown(&private->mm);
@@ -137,24 +145,24 @@ static int rockchip_drm_bind(struct device *dev)
 
drm_dev->dev_private = private;
 
-   ret = rockchip_drm_init_iommu(drm_dev);
-   if (ret)
-   goto err_free;
-
ret = drmm_mode_config_init(drm_dev);
if (ret)
-   goto err_iommu_cleanup;
+   goto err_free;
 
rockchip_drm_mode_config_init(drm_dev);
 
/* Try to bind all sub drivers. */
ret = component_bind_all(dev, drm_dev);
if (ret)
-   goto err_iommu_cleanup;
+   goto err_free;
+
+   ret = rockchip_drm_init_iommu(drm_dev);
+   if (ret)
+   goto err_unbind_all;
 
ret = drm_vblank_init(drm_dev, drm_dev->mode_config.num_crtc);
if (ret)
-   goto err_unbind_all;
+   goto err_iommu_cleanup;
 
drm_mode_config_reset(drm_dev);
 
@@ -170,10 +178,10 @@ static int rockchip_drm_bind(struct device *dev)
return 0;
 err_kms_helper_poll_fini:
drm_kms_helper_poll_fini(drm_dev);
-err_unbind_all:
-   component_unbind_all(dev, drm_dev);
 err_iommu_cleanup:
rockchip_iommu_cleanup(drm_dev);
+err_unbind_all:
+   component_unbind_all(dev, drm_dev);
 err_free:
drm_dev_put(drm_dev);
return ret;
@@ -342,8 +350,6 @@ static int rockchip_drm_platform_of_probe(struct device 
*dev)
return -ENODEV;
 
for (i = 0;; i++) {
-   struct device_node *iommu;
-
port = of_parse_phandle(np, "ports", i);
if (!port

[PATCH v8 0/9] drm/i915/ttm: Evict and restore of compressed object

[Ramalingam C]

On Xe-HP and later devices, we use dedicated compression control
state (CCS) stored in local memory for each surface, to support
the 3D and media compression formats.

The memory required for the CCS of the entire local memory is
1/256 of the local memory size. So before the kernel
boot, the required memory is reserved for the CCS data and a
secure register will be programmed with the CCS base address

So when we allocate a object in local memory we dont need to explicitly
allocate the space for ccs data. But when we evict the obj into the smem
to hold the compression related data along with the obj we need smem
space of obj_size + (obj_size/256).

Hence when we create smem for an obj with lmem placement possibility we
create with the extra space.

When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.

When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the ccs data corresponding to the
lmem main memory. So main memory of lmem will be copied into the initial
pages of the smem and then ccs data corresponding to the main memory
will be copied to the subsequent pages of smem.

Swapin happens exactly in reverse order. First main memory of lmem is
restored from the smem's initial pages and the ccs data will be restored
from the subsequent pages of smem.

Extracting and restoring the CCS data is done through a special cmd called
XY_CTRL_SURF_COPY_BLT

v8:
  New patch for return value fix
  Fix a return error code

Test-with: 20220405141050.16037-1-ramalinga...@intel.com

Ramalingam C (9):
  drm/i915/gt: use engine instance directly for offset
  drm/i915/gt: Use XY_FAST_COLOR_BLT to clear obj on graphics ver 12+
  drm/i915/gt: Optimize the migration and clear loop
  drm/i915/gt: Pass the -EINVAL when emit_pte doesn't update any PTE
  drm/i915/gt: Clear compress metadata for Flat-ccs objects
  drm/i915/selftest_migrate: Consider the possible roundup of size
  drm/i915/selftest_migrate: Check CCS meta data clear
  drm/i915/gem: Add extra pages in ttm_tt for ccs data
  drm/i915/migrate: Evict and restore the flatccs capable lmem obj

 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  30 +-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  21 +
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 385 +--
 drivers/gpu/drm/i915/gt/selftest_migrate.c   | 253 ++--
 4 files changed, 629 insertions(+), 60 deletions(-)

-- 
2.20.1

[PATCH v8 2/9] drm/i915/gt: Use XY_FAST_COLOR_BLT to clear obj on graphics ver 12+

[Ramalingam C]

Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more,
for clearing (Zero out) the pages of the newly allocated object.

XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT.

v2:
  Typo fix at title [Thomas]
v3:
  XY_FAST_COLOR_BLT is used only for FLAT_CCS capable gen12+

Signed-off-by: Ramalingam C 
Signed-off-by: Chris Wilson 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  5 +++
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 43 +---
 2 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 4243be030bc1..d1b8c23f7a9e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -206,6 +206,11 @@
 
 #define COLOR_BLT_CMD  (2 << 29 | 0x40 << 22 | (5 - 2))
 #define XY_COLOR_BLT_CMD   (2 << 29 | 0x50 << 22)
+#define XY_FAST_COLOR_BLT_CMD  (2 << 29 | 0x44 << 22)
+#define   XY_FAST_COLOR_BLT_DEPTH_32   (2 << 19)
+#define   XY_FAST_COLOR_BLT_DW 16
+#define   XY_FAST_COLOR_BLT_MOCS_MASK  GENMASK(27, 21)
+#define   XY_FAST_COLOR_BLT_MEM_TYPE_SHIFT 31
 #define SRC_COPY_BLT_CMD   (2 << 29 | 0x43 << 22)
 #define GEN9_XY_FAST_COPY_BLT_CMD  (2 << 29 | 0x42 << 22)
 #define XY_SRC_COPY_BLT_CMD(2 << 29 | 0x53 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9d852a570400..e81f20266f62 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -613,18 +613,51 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
-static int emit_clear(struct i915_request *rq, u32 offset, int size, u32 value)
+static int emit_clear(struct i915_request *rq, u32 offset, int size,
+ u32 value, bool is_lmem)
 {
-   const int ver = GRAPHICS_VER(rq->engine->i915);
+   struct drm_i915_private *i915 = rq->engine->i915;
+   int mocs = rq->engine->gt->mocs.uc_index << 1;
+   const int ver = GRAPHICS_VER(i915);
+   int ring_sz;
u32 *cs;
 
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
 
-   cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
+   if (HAS_FLAT_CCS(i915) && ver >= 12)
+   ring_sz = XY_FAST_COLOR_BLT_DW;
+   else if (ver >= 8)
+   ring_sz = 8;
+   else
+   ring_sz = 6;
+
+   cs = intel_ring_begin(rq, ring_sz);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   if (ver >= 8) {
+   if (HAS_FLAT_CCS(i915) && ver >= 12) {
+   *cs++ = XY_FAST_COLOR_BLT_CMD | XY_FAST_COLOR_BLT_DEPTH_32 |
+   (XY_FAST_COLOR_BLT_DW - 2);
+   *cs++ = FIELD_PREP(XY_FAST_COLOR_BLT_MOCS_MASK, mocs) |
+   (PAGE_SIZE - 1);
+   *cs++ = 0;
+   *cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
+   *cs++ = offset;
+   *cs++ = rq->engine->instance;
+   *cs++ = !is_lmem << XY_FAST_COLOR_BLT_MEM_TYPE_SHIFT;
+   /* BG7 */
+   *cs++ = value;
+   *cs++ = 0;
+   *cs++ = 0;
+   *cs++ = 0;
+   /* BG11 */
+   *cs++ = 0;
+   *cs++ = 0;
+   /* BG13 */
+   *cs++ = 0;
+   *cs++ = 0;
+   *cs++ = 0;
+   } else if (ver >= 8) {
*cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
@@ -707,7 +740,7 @@ intel_context_migrate_clear(struct intel_context *ce,
if (err)
goto out_rq;
 
-   err = emit_clear(rq, offset, len, value);
+   err = emit_clear(rq, offset, len, value, is_lmem);
 
/* Arbitration is re-enabled between requests. */
 out_rq:
-- 
2.20.1

[PATCH v8 1/9] drm/i915/gt: use engine instance directly for offset

[Ramalingam C]

To make it uniform across copy and clear, use the engine offset directly
to calculate the offset in the cmd forming for emit_clear.

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 950fd6da146c..9d852a570400 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -613,15 +613,13 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
-static int emit_clear(struct i915_request *rq, u64 offset, int size, u32 value)
+static int emit_clear(struct i915_request *rq, u32 offset, int size, u32 value)
 {
const int ver = GRAPHICS_VER(rq->engine->i915);
u32 *cs;
 
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
 
-   offset += (u64)rq->engine->instance << 32;
-
cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -631,17 +629,16 @@ static int emit_clear(struct i915_request *rq, u64 
offset, int size, u32 value)
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
*cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
-   *cs++ = lower_32_bits(offset);
-   *cs++ = upper_32_bits(offset);
+   *cs++ = offset;
+   *cs++ = rq->engine->instance;
*cs++ = value;
*cs++ = MI_NOOP;
} else {
-   GEM_BUG_ON(upper_32_bits(offset));
*cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (6 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
*cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
-   *cs++ = lower_32_bits(offset);
+   *cs++ = offset;
*cs++ = value;
}
 
-- 
2.20.1

[PATCH v8 3/9] drm/i915/gt: Optimize the migration and clear loop

[Ramalingam C]

Move the static calculations out of the loops for copy and clear.

v2:
  Fix the loss of proper error code on emit_pte

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom  (v1)
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index e81f20266f62..e0f1c727662e 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -526,6 +526,7 @@ intel_context_migrate_copy(struct intel_context *ce,
   struct i915_request **out)
 {
struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst);
+   u32 src_offset, dst_offset;
struct i915_request *rq;
int err;
 
@@ -535,8 +536,18 @@ intel_context_migrate_copy(struct intel_context *ce,
 
GEM_BUG_ON(ce->ring->size < SZ_64K);
 
+   src_offset = 0;
+   dst_offset = CHUNK_SZ;
+   if (HAS_64K_PAGES(ce->engine->i915)) {
+   src_offset = 0;
+   dst_offset = 0;
+   if (src_is_lmem)
+   src_offset = CHUNK_SZ;
+   if (dst_is_lmem)
+   dst_offset = 2 * CHUNK_SZ;
+   }
+
do {
-   u32 src_offset, dst_offset;
int len;
 
rq = i915_request_create(ce);
@@ -564,17 +575,6 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
-   src_offset = 0;
-   dst_offset = CHUNK_SZ;
-   if (HAS_64K_PAGES(ce->engine->i915)) {
-   src_offset = 0;
-   dst_offset = 0;
-   if (src_is_lmem)
-   src_offset = CHUNK_SZ;
-   if (dst_is_lmem)
-   dst_offset = 2 * CHUNK_SZ;
-   }
-
len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
   src_offset, CHUNK_SZ);
if (len <= 0) {
@@ -690,6 +690,7 @@ intel_context_migrate_clear(struct intel_context *ce,
 {
struct sgt_dma it = sg_sgt(sg);
struct i915_request *rq;
+   u32 offset;
int err;
 
GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
@@ -697,8 +698,11 @@ intel_context_migrate_clear(struct intel_context *ce,
 
GEM_BUG_ON(ce->ring->size < SZ_64K);
 
+   offset = 0;
+   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
+   offset = CHUNK_SZ;
+
do {
-   u32 offset;
int len;
 
rq = i915_request_create(ce);
@@ -726,10 +730,6 @@ intel_context_migrate_clear(struct intel_context *ce,
if (err)
goto out_rq;
 
-   offset = 0;
-   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
-   offset = CHUNK_SZ;
-
len = emit_pte(rq, &it, cache_level, is_lmem, offset, CHUNK_SZ);
if (len <= 0) {
err = len;
-- 
2.20.1

[PATCH v8 5/9] drm/i915/gt: Clear compress metadata for Flat-ccs objects

[Ramalingam C]

Xe-HP and latest devices support Flat CCS which reserved a portion of
the device memory to store compression metadata, during the clearing of
device memory buffer object we also need to clear the associated
CCS buffer.

XY_CTRL_SURF_COPY_BLT is a BLT cmd used for reading and writing the
ccs surface of a lmem memory. So on Flat-CCS capable platform we use
XY_CTRL_SURF_COPY_BLT  to clear the CCS meta data.

v2: Fixed issues with platform naming [Lucas]
v3: Rebased [Ram]
Used the round_up funcs [Bob]
v4: Fixed ccs blk calculation [Ram]
Added Kdoc on flat-ccs.
v5: GENMASK is used [Matt]
mocs fix [Matt]
Comments Fix [Matt]
Flush address programming [Ram]
v6: FLUSH_DW is fixed
Few coding style fix
v7: Adopting the XY_FAST_COLOR_BLT (Thomas]
v8: XY_CTRL_SURF_COPY_BLT for ccs clearing.
v9: emit_copy_ccs is used.
v10: ctrl_surf cmds are filled in caller itself. [Thomas]
 only one ctrl surf cmd is used as size of lmem is <=8M [Thomas]

Signed-off-by: Ramalingam C 
Signed-off-by: Ayaz A Siddiqui 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  16 +++
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 137 ++-
 2 files changed, 152 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index d1b8c23f7a9e..724ab069ddb6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -154,8 +154,10 @@
 #define   MI_FLUSH_DW_PROTECTED_MEM_EN (1 << 22)
 #define   MI_FLUSH_DW_STORE_INDEX  (1<<21)
 #define   MI_INVALIDATE_TLB(1<<18)
+#define   MI_FLUSH_DW_CCS  (1<<16)
 #define   MI_FLUSH_DW_OP_STOREDW   (1<<14)
 #define   MI_FLUSH_DW_OP_MASK  (3<<14)
+#define   MI_FLUSH_DW_LLC  (1<<9)
 #define   MI_FLUSH_DW_NOTIFY   (1<<8)
 #define   MI_INVALIDATE_BSD(1<<7)
 #define   MI_FLUSH_DW_USE_GTT  (1<<2)
@@ -204,6 +206,20 @@
 #define GFX_OP_DRAWRECT_INFO ((0x3<<29)|(0x1d<<24)|(0x80<<16)|(0x3))
 #define GFX_OP_DRAWRECT_INFO_I965  ((0x7900<<16)|0x2)
 
+#define XY_CTRL_SURF_INSTR_SIZE5
+#define MI_FLUSH_DW_SIZE   3
+#define XY_CTRL_SURF_COPY_BLT  ((2 << 29) | (0x48 << 22) | 3)
+#define   SRC_ACCESS_TYPE_SHIFT21
+#define   DST_ACCESS_TYPE_SHIFT20
+#define   CCS_SIZE_MASK0x3FF
+#define   CCS_SIZE_SHIFT   8
+#define   XY_CTRL_SURF_MOCS_MASK   GENMASK(31, 25)
+#define   NUM_CCS_BYTES_PER_BLOCK  256
+#define   NUM_BYTES_PER_CCS_BYTE   256
+#define   NUM_CCS_BLKS_PER_XFER1024
+#define   INDIRECT_ACCESS  0
+#define   DIRECT_ACCESS1
+
 #define COLOR_BLT_CMD  (2 << 29 | 0x40 << 22 | (5 - 2))
 #define XY_COLOR_BLT_CMD   (2 << 29 | 0x50 << 22)
 #define XY_FAST_COLOR_BLT_CMD  (2 << 29 | 0x44 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index f9f3b0e7ed87..2446ff70ce45 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -17,6 +17,8 @@ struct insert_pte_data {
 
 #define CHUNK_SZ SZ_8M /* ~1ms at 8GiB/s preemption delay */
 
+#define GET_CCS_BYTES(i915, size)  (HAS_FLAT_CCS(i915) ? \
+DIV_ROUND_UP(size, 
NUM_BYTES_PER_CCS_BYTE) : 0)
 static bool engine_supports_migration(struct intel_engine_cs *engine)
 {
if (!engine)
@@ -467,6 +469,123 @@ static bool wa_1209644611_applies(int ver, u32 size)
return height % 4 == 3 && height <= 8;
 }
 
+/**
+ * DOC: Flat-CCS - Memory compression for Local memory
+ *
+ * On Xe-HP and later devices, we use dedicated compression control state (CCS)
+ * stored in local memory for each surface, to support the 3D and media
+ * compression formats.
+ *
+ * The memory required for the CCS of the entire local memory is 1/256 of the
+ * local memory size. So before the kernel boot, the required memory is 
reserved
+ * for the CCS data and a secure register will be programmed with the CCS base
+ * address.
+ *
+ * Flat CCS data needs to be cleared when a lmem object is allocated.
+ * And CCS data can be copied in and out of CCS region through
+ * XY_CTRL_SURF_COPY_BLT. CPU can't access the CCS data directly.
+ *
+ * When we exhaust the lmem, if the object's placements support smem, then we 
can
+ * directly decompress the compressed lmem object into smem and start using it
+ * from smem itself.
+ *
+ * But when we need to swapout the compressed lmem object into a smem region
+ * though objects' placement doesn't support smem, then we copy the lmem 
content
+ * as it is into smem region along with ccs data (using XY_CTRL_SURF_COPY_BLT).
+ * When the object is referred, lmem content will be swaped in along with
+ * restoration of the CCS data (using XY_CTRL_SURF_COPY_BLT) at corresp

[PATCH v8 4/9] drm/i915/gt: Pass the -EINVAL when emit_pte doesn't update any PTE

[Ramalingam C]

When emit_pte doesn't update any PTE with return value as 0, interpret
it as -EINVAL.

Signed-off-by: Ramalingam C 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index e0f1c727662e..f9f3b0e7ed87 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -577,7 +577,9 @@ intel_context_migrate_copy(struct intel_context *ce,
 
len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
   src_offset, CHUNK_SZ);
-   if (len <= 0) {
+   if (!len)
+   err = -EINVAL;
+   if (len < 0) {
err = len;
goto out_rq;
}
-- 
2.20.1

[PATCH v8 7/9] drm/i915/selftest_migrate: Check CCS meta data clear

[Ramalingam C]

Extend the live migrate selftest, to verify the ccs surface clearing
during the Flat-CCS capable lmem obj clear.

v2:
  Look at right places for ccs data [Thomas]

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/selftest_migrate.c | 250 ++---
 1 file changed, 222 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c 
b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index b5da8b8cd039..8cd9a22054f3 100644
--- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
+++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
@@ -132,6 +132,124 @@ static int copy(struct intel_migrate *migrate,
return err;
 }
 
+static int intel_context_copy_ccs(struct intel_context *ce,
+ const struct i915_deps *deps,
+ struct scatterlist *sg,
+ enum i915_cache_level cache_level,
+ bool write_to_ccs,
+ struct i915_request **out)
+{
+   u8 src_access = write_to_ccs ? DIRECT_ACCESS : INDIRECT_ACCESS;
+   u8 dst_access = write_to_ccs ? INDIRECT_ACCESS : DIRECT_ACCESS;
+   struct sgt_dma it = sg_sgt(sg);
+   struct i915_request *rq;
+   u32 offset;
+   int err;
+
+   GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
+   *out = NULL;
+
+   GEM_BUG_ON(ce->ring->size < SZ_64K);
+
+   offset = 0;
+   if (HAS_64K_PAGES(ce->engine->i915))
+   offset = CHUNK_SZ;
+
+   do {
+   int len;
+
+   rq = i915_request_create(ce);
+   if (IS_ERR(rq)) {
+   err = PTR_ERR(rq);
+   goto out_ce;
+   }
+
+   if (deps) {
+   err = i915_request_await_deps(rq, deps);
+   if (err)
+   goto out_rq;
+
+   if (rq->engine->emit_init_breadcrumb) {
+   err = rq->engine->emit_init_breadcrumb(rq);
+   if (err)
+   goto out_rq;
+   }
+
+   deps = NULL;
+   }
+
+   /* The PTE updates + clear must not be interrupted. */
+   err = emit_no_arbitration(rq);
+   if (err)
+   goto out_rq;
+
+   len = emit_pte(rq, &it, cache_level, true, offset, CHUNK_SZ);
+   if (len <= 0) {
+   err = len;
+   goto out_rq;
+   }
+
+   err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
+   if (err)
+   goto out_rq;
+
+   err = emit_copy_ccs(rq, offset, dst_access,
+   offset, src_access, len);
+   if (err)
+   goto out_rq;
+
+   err = rq->engine->emit_flush(rq, EMIT_INVALIDATE);
+
+   /* Arbitration is re-enabled between requests. */
+out_rq:
+   if (*out)
+   i915_request_put(*out);
+   *out = i915_request_get(rq);
+   i915_request_add(rq);
+   if (err || !it.sg || !sg_dma_len(it.sg))
+   break;
+
+   cond_resched();
+   } while (1);
+
+out_ce:
+   return err;
+}
+
+static int
+intel_migrate_ccs_copy(struct intel_migrate *m,
+  struct i915_gem_ww_ctx *ww,
+  const struct i915_deps *deps,
+  struct scatterlist *sg,
+  enum i915_cache_level cache_level,
+  bool write_to_ccs,
+  struct i915_request **out)
+{
+   struct intel_context *ce;
+   int err;
+
+   *out = NULL;
+   if (!m->context)
+   return -ENODEV;
+
+   ce = intel_migrate_create_context(m);
+   if (IS_ERR(ce))
+   ce = intel_context_get(m->context);
+   GEM_BUG_ON(IS_ERR(ce));
+
+   err = intel_context_pin_ww(ce, ww);
+   if (err)
+   goto out;
+
+   err = intel_context_copy_ccs(ce, deps, sg, cache_level,
+write_to_ccs, out);
+
+   intel_context_unpin(ce);
+out:
+   intel_context_put(ce);
+   return err;
+}
+
 static int clear(struct intel_migrate *migrate,
 int (*fn)(struct intel_migrate *migrate,
   struct i915_gem_ww_ctx *ww,
@@ -144,7 +262,8 @@ static int clear(struct intel_migrate *migrate,
struct drm_i915_gem_object *obj;
struct i915_request *rq;
struct i915_gem_ww_ctx ww;
-   u32 *vaddr;
+   u32 *vaddr, val = 0;
+   bool ccs_cap = false;
int err = 0;
int i;
 
@@ -155,7 +274,12 @@ static int clear(struct intel_migrate *migrate,
/* Consider the rounded up memory too */
sz = obj->ba

[PATCH v8 8/9] drm/i915/gem: Add extra pages in ttm_tt for ccs data

[Ramalingam C]

On Xe-HP and later devices, dedicated compression control state (CCS)
stored in local memory is used for each surface, to support the
3D and media compression formats.

The memory required for the CCS of the entire local memory is 1/256 of
the local memory size. So before the kernel boot, the required memory
is reserved for the CCS data and a secure register will be programmed
with the CCS base address

So when an object is allocated in local memory, dont need to explicitly
allocate the space for ccs data. But when the obj is evicted into the
smem, to hold the compression related data along with the obj extra space
is needed in smem. i.e obj_size + (obj_size/256).

Hence when a smem pages are allocated for an obj with lmem placement
possibility we create with the extra pages required for the ccs data for
the obj size.

v2:
  Used imperative wording [Thomas]
v3:
  Inflate the pages only when obj's placement is lmem only
v4:
  GEM_BUG_ON if the ttm->num_pages > obj page size [Thomas]

Signed-off-by: Ramalingam C 
cc: Christian Koenig 
cc: Hellstrom Thomas 
Reviewed-by: Thomas Hellstrom 
Reviewed-by: Nirmoy Das 
---
 drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 30 -
 1 file changed, 29 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
index a878910a563c..4c25d9b2f138 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_ttm.c
@@ -20,6 +20,7 @@
 #include "gem/i915_gem_ttm.h"
 #include "gem/i915_gem_ttm_move.h"
 #include "gem/i915_gem_ttm_pm.h"
+#include "gt/intel_gpu_commands.h"
 
 #define I915_TTM_PRIO_PURGE 0
 #define I915_TTM_PRIO_NO_PAGES  1
@@ -265,12 +266,33 @@ static const struct i915_refct_sgt_ops tt_rsgt_ops = {
.release = i915_ttm_tt_release
 };
 
+static inline bool
+i915_gem_object_needs_ccs_pages(struct drm_i915_gem_object *obj)
+{
+   bool lmem_placement = false;
+   int i;
+
+   for (i = 0; i < obj->mm.n_placements; i++) {
+   /* Compression is not allowed for the objects with smem 
placement */
+   if (obj->mm.placements[i]->type == INTEL_MEMORY_SYSTEM)
+   return false;
+   if (!lmem_placement &&
+   obj->mm.placements[i]->type == INTEL_MEMORY_LOCAL)
+   lmem_placement = true;
+   }
+
+   return lmem_placement;
+}
+
 static struct ttm_tt *i915_ttm_tt_create(struct ttm_buffer_object *bo,
 uint32_t page_flags)
 {
+   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;
struct i915_ttm_tt *i915_tt;
int ret;
@@ -293,7 +315,12 @@ static struct ttm_tt *i915_ttm_tt_create(struct 
ttm_buffer_object *bo,
i915_tt->is_shmem = true;
}
 
-   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, 0);
+   if (HAS_FLAT_CCS(i915) && i915_gem_object_needs_ccs_pages(obj))
+   ccs_pages = DIV_ROUND_UP(DIV_ROUND_UP(bo->base.size,
+ NUM_BYTES_PER_CCS_BYTE),
+PAGE_SIZE);
+
+   ret = ttm_tt_init(&i915_tt->ttm, bo, page_flags, caching, ccs_pages);
if (ret)
goto err_free;
 
@@ -773,6 +800,7 @@ static int __i915_ttm_get_pages(struct drm_i915_gem_object 
*obj,
i915_sg_dma_sizes(rsgt->table.sgl));
}
 
+   GEM_BUG_ON(bo->ttm && ((obj->base.size >> PAGE_SHIFT) < 
bo->ttm->num_pages));
i915_ttm_adjust_lru(obj);
return ret;
 }
-- 
2.20.1

[PATCH v8 9/9] drm/i915/migrate: Evict and restore the flatccs capable lmem obj

[Ramalingam C]

When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.

When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the ccs data corresponding to the
lmem main memory. So main memory of lmem will be copied into the initial
pages of the smem and then ccs data corresponding to the main memory
will be copied to the subsequent pages of smem. ccs data is 1/256 of
lmem size.

Swapin happens exactly in reverse order. First main memory of lmem is
restored from the smem's initial pages and the ccs data will be restored
from the subsequent pages of smem.

Extracting and restoring the CCS data is done through a special cmd called
XY_CTRL_SURF_COPY_BLT

v2: Fixing the ccs handling
v3: Handle the ccs data at same loop as main memory [Thomas]
v4: changes for emit_copy_ccs
v5: handle non-flat-ccs scenario

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 164 +++-
 1 file changed, 160 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 2446ff70ce45..dd7b89589f20 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -633,6 +633,65 @@ static int emit_copy(struct i915_request *rq,
return 0;
 }
 
+static int scatter_list_length(struct scatterlist *sg)
+{
+   int len = 0;
+
+   while (sg && sg_dma_len(sg)) {
+   len += sg_dma_len(sg);
+   sg = sg_next(sg);
+   };
+
+   return len;
+}
+
+static void
+calculate_chunk_sz(struct drm_i915_private *i915, bool src_is_lmem,
+  int *src_sz, int *ccs_sz, u32 bytes_to_cpy,
+  u32 ccs_bytes_to_cpy)
+{
+   if (ccs_bytes_to_cpy) {
+   /*
+* We can only copy the ccs data corresponding to
+* the CHUNK_SZ of lmem which is
+* GET_CCS_BYTES(i915, CHUNK_SZ))
+*/
+   *ccs_sz = min_t(int, ccs_bytes_to_cpy, GET_CCS_BYTES(i915, 
CHUNK_SZ));
+
+   if (!src_is_lmem)
+   /*
+* When CHUNK_SZ is passed all the pages upto CHUNK_SZ
+* will be taken for the blt. in Flat-ccs supported
+* platform Smem obj will have more pages than required
+* for main meory hence limit it to the required size
+* for main memory
+*/
+   *src_sz = min_t(int, bytes_to_cpy, CHUNK_SZ);
+   } else { /* ccs handling is not required */
+   *src_sz = CHUNK_SZ;
+   }
+}
+
+static void get_ccs_sg_sgt(struct sgt_dma *it, u32 bytes_to_cpy)
+{
+   u32 len;
+
+   do {
+   GEM_BUG_ON(!it->sg || !sg_dma_len(it->sg));
+   len = it->max - it->dma;
+   if (len > bytes_to_cpy) {
+   it->dma += bytes_to_cpy;
+   break;
+   }
+
+   bytes_to_cpy -= len;
+
+   it->sg = __sg_next(it->sg);
+   it->dma = sg_dma_address(it->sg);
+   it->max = it->dma + sg_dma_len(it->sg);
+   } while (bytes_to_cpy);
+}
+
 int
 intel_context_migrate_copy(struct intel_context *ce,
   const struct i915_deps *deps,
@@ -644,9 +703,15 @@ intel_context_migrate_copy(struct intel_context *ce,
   bool dst_is_lmem,
   struct i915_request **out)
 {
-   struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst);
+   struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst), it_ccs;
+   struct drm_i915_private *i915 = ce->engine->i915;
+   u32 ccs_bytes_to_cpy = 0, bytes_to_cpy;
+   enum i915_cache_level ccs_cache_level;
+   int src_sz, dst_sz, ccs_sz;
u32 src_offset, dst_offset;
+   u8 src_access, dst_access;
struct i915_request *rq;
+   bool ccs_is_src;
int err;
 
GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
@@ -655,6 +720,38 @@ intel_context_migrate_copy(struct intel_context *ce,
 
GEM_BUG_ON(ce->ring->size < SZ_64K);
 
+   src_sz = scatter_list_length(src);
+   bytes_to_cpy = src_sz;
+
+   if (HAS_FLAT_CCS(i915) && src_is_lmem ^ dst_is_lmem) {
+   src_access = !src_is_lmem && dst_is_lmem;
+   dst_access = !src_access;
+
+   dst_sz = scatter_list_length(dst);
+   if (src_is_lmem) {
+   it_ccs = it_dst;
+   ccs_cache_level = dst_cache_level;
+   ccs_is_src = false;
+   } else if (dst_is_lmem) {
+   bytes_to_cpy = dst_sz;
+   it_ccs = it_src;
+ 

[PATCH v8 6/9] drm/i915/selftest_migrate: Consider the possible roundup of size

[Ramalingam C]

Consider the possible round up happened at obj size alignment to
min_page_size during the obj allocation.

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/selftest_migrate.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/selftest_migrate.c 
b/drivers/gpu/drm/i915/gt/selftest_migrate.c
index c9c4f391c5cc..b5da8b8cd039 100644
--- a/drivers/gpu/drm/i915/gt/selftest_migrate.c
+++ b/drivers/gpu/drm/i915/gt/selftest_migrate.c
@@ -152,6 +152,9 @@ static int clear(struct intel_migrate *migrate,
if (IS_ERR(obj))
return 0;
 
+   /* Consider the rounded up memory too */
+   sz = obj->base.size;
+
for_i915_gem_ww(&ww, err, true) {
err = i915_gem_object_lock(obj, &ww);
if (err)
-- 
2.20.1

Re: [PATCH] drm/format_helper: fix a kernel-doc typo

[Randy Dunlap]

On 4/4/22 23:26, Javier Martinez Canillas wrote:
> On 4/5/22 08:12, Simon Ser wrote:
>> On Monday, April 4th, 2022 at 23:35, Randy Dunlap  
>> wrote:
>>
>>> On 4/4/22 09:04, Simon Ser wrote:
>>>
 Both doc patches pushed, thanks. I had to manually edit them because they
 wouldn't apply cleanly. Next time, please use git-send-email (see
 https://git-send-email.io/ for setup instructions).
>>>
>>> That's odd. I did use 'git send-email' and I don't usually have any
>>> problems (AFAIK). I'll check those setup instructions.
>>
>> Hm, maybe the issue isn't git-send-email, but the way the patch was
>> generated? I had to manually edit these lines for the first patch to work:
>>
>> --- linux-next-20211217.orig/include/drm/drm_file.h
>> +++ linux-next-20211217/include/drm/drm_file.h
>>
>> I changed these to:
>>
>> --- a/include/drm/drm_file.h
>> +++ b/include/drm/drm_file.h
>>
>> This wasn't enough for the second patch, I had to re-do the changes by hand
>> from scratch.
>>
> 
> Yes, I believe the suggestion should be to use git-format-patch instead.
> 
> To make sure that was is posted can be consumed by the git-am command.

Considering that I am not using git, I think it will be difficult
to use git-format-patch.

(git-send-email is independent of git.)

Still, this is the first time in many years that I have heard
of this problem.

Thanks for the info and insights.

-- 
~Randy

Re: [PATCH][RESEND] drm/bridge: ti-sn65dsi83: Check link status register after enabling the bridge

[Marek Vasut]

On 4/5/22 16:20, Dave Stevenson wrote:

Hi,


If we can initialise the DSI host before the bridge for the
pre_enable, then all the configuration moves to the atomic_pre_enable
and there should be no need to have the delay.

I can't 100% guarantee that, but one of the folks on the Pi forums is
using [1] which does that, and is reporting it working well. (He's
also using the DSI85 to take 2 DSI links and drive 2 LVDS single link
panels)


It seems to me that checking whether the bridge got correctly
initialized is orthogonal to the aforementioned patchset though ?


It's the delay that is ugly.


You do need to wait a little after the initialization and before 
checking the status, so that delay is not going away no matter how you 
frob with the DSI bridge.



Put the check in atomic_enable which will be slightly later than
configuration in pre_enable? Check that sufficient jiffies have passed
if you needed.
Or wire up the IRQ line from the SN65DSI83 rather than polling the IRQ
Status register. Delayed workqueue if the IRQ isn't wired up.


Are you able to do such deferred non-atomic operations in atomic_enable 
callback ?



If I read it right your log message is triggered by any bit being set
in REG_IRQ_STAT. So an inconveniently timed correctable DSI error will
set bit 4 and log the error even though it's been corrected. Likewise
bit 7 / CHA_SYNCH_ERR could get triggered by an H or V sync packet
being received in that 10-12ms window (we're in atomic_enable, so
video is already running).


There should be no bits set in the IRQ_STAT register if everything works 
as it should.



If it's the PLL being unlocked that is the issue then it should only
be checking bit 0. Or possibly reading the actual PLL lock status from
REG_RC_LVDS_PLL_PLL_EN_STAT. Although as we've already checked that
the PLL is locked via REG_RC_LVDS_PLL_PLL_EN_STAT earlier in the
atomic_enable, I'm now a little confused as to the condition you are
actually wanting to detect.


Any outstanding errors which are currently hidden and only show up 
sporadically at the worst possible moment.


[...]

[PATCH 0/3] Inherit GPU scheduling priority from process nice

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Current processing landscape seems to be more and more composed of pipelines
where computations are done on multiple hardware devices. Furthermore some of
the non-CPU devices, like in this case many GPUs supported by the i915 driver,
actually support priority based scheduling which is currently rather
inaccessible to the user (in terms of being able to control it from the
outside).

>From these two statements a question arises on how to allow for a simple,
effective and consolidated user experience. In other words why user would not be
able to do something like:

 $ nice ffmmpeg ...transcode my videos...
 $ my-favourite-game

And have the nice hint apply to GPU parts of the transcode pipeline as well?

This would in fact follow the approach taken by kernel's block scheduler where
ionice is by default inherited from process nice.

This series implements the same idea by inheriting context creator and batch
buffer submitted nice value as context nice. To avoid influencing GPU scheduling
aware clients this is done only one for contexts where userspace hasn't
explicitly specified a non-default scheduling priority

With the series applied I simulated the scenario of a background GPU task
running simultaneously with an interactive client, varying the hog's nice value.
These were the results:

   GPU hog (nice) |   TRex fps|   perf drop
   ---+---+
   no hog | 48.9  |- n/a -
  0   | 42.7  | -13%
 10   | 47.9  |  -2%
-10   | 29.0  | -41%

As can be seen running the background GPU task re-niced can restore the
performance of the foreground task to almost the level when it is running alone
on the machine.

The approach is completely compatible with GuC and drm/scheduler since all
support at least low/normal/high priority levels with just the granularity of
available control differing. In other words with GuC scheduling there is no
difference between nice 5 and 10, both would map to low priority, but the
default case of positive or negative nice, versus nice 0, is still correctly
propagated to the firmware scheduler.

v2:
 * Moved notifier outside task_rq_lock.
 * Some improvements and restructuring on the i915 side of the series.

v3:
 * Dropped task nice notifier - inheriting nice on request submit time is good
   enough.

Tvrtko Ursulin (3):
  drm/i915: Make some recently added vfuncs use full scheduling
attribute
  drm/i915: Inherit process nice for context scheduling priority
  drm/i915: Inherit submitter nice when scheduling requests

 drivers/gpu/drm/i915/gem/i915_gem_context.c  |  6 +-
 .../gpu/drm/i915/gt/intel_execlists_submission.c |  6 --
 .../gpu/drm/i915/gt/uc/intel_guc_submission.c|  3 ++-
 drivers/gpu/drm/i915/i915_request.c  |  7 +--
 drivers/gpu/drm/i915/i915_request.h  |  5 +
 drivers/gpu/drm/i915/i915_scheduler.c| 16 ++--
 drivers/gpu/drm/i915/i915_scheduler.h| 14 ++
 drivers/gpu/drm/i915/i915_scheduler_types.h  | 12 ++--
 8 files changed, 55 insertions(+), 14 deletions(-)

-- 
2.32.0

[PATCH 2/3] drm/i915: Inherit process nice for context scheduling priority

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Introduce the concept of context nice value which matches the process
nice.

We do this by extending the struct i915_sched_attr and add a helper
(i915_sched_attr_priority) to be used to convert to effective priority
when used by backend code and for priority sorting.

Context nice is then inherited from the process which creates the GEM
context and utilised secondary to context priority, but only when the
latter has been left at the default setting in order to avoid disturbing
any application made choices of low and high (batch processing and maybe
latency sensitive compositing). In this case nice value adjusts the
effective priority in the narrow band of -19 to +20 around
I915_CONTEXT_DEFAULT_PRIORITY.

This means that userspace using the context priority uapi directly has a
wider range of possible adjustments (in practice that only applies to
execlists platforms - with GuC there are only three priority buckets), but
in all cases nice adjustment has the expected effect: positive nice
lowering the scheduling priority and negative nice raising it.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/gem/i915_gem_context.c|  6 +-
 .../gpu/drm/i915/gt/intel_execlists_submission.c   |  4 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c  |  2 +-
 drivers/gpu/drm/i915/i915_request.c|  2 +-
 drivers/gpu/drm/i915/i915_request.h|  5 +
 drivers/gpu/drm/i915/i915_scheduler.c  | 12 
 drivers/gpu/drm/i915/i915_scheduler.h  | 14 ++
 drivers/gpu/drm/i915/i915_scheduler_types.h|  8 
 8 files changed, 44 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index ab4c5ab28e4d..1d772cc87ae6 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -294,6 +294,7 @@ proto_context_create(struct drm_i915_private *i915, 
unsigned int flags)
if (i915->params.enable_hangcheck)
pc->user_flags |= BIT(UCONTEXT_PERSISTENCE);
pc->sched.priority = I915_PRIORITY_NORMAL;
+   pc->sched.nice = task_nice(current);
 
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
if (!HAS_EXECLISTS(i915)) {
@@ -914,8 +915,11 @@ static int set_proto_ctx_param(struct 
drm_i915_file_private *fpriv,
 
case I915_CONTEXT_PARAM_PRIORITY:
ret = validate_priority(fpriv->dev_priv, args);
-   if (!ret)
+   if (!ret) {
pc->sched.priority = args->value;
+   if (args->value == I915_CONTEXT_DEFAULT_PRIORITY)
+   pc->sched.nice = task_nice(current);
+   }
break;
 
case I915_CONTEXT_PARAM_SSEU:
diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index 8b04c6e4c006..eb035cd73bc5 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -254,7 +254,7 @@ static struct i915_priolist *to_priolist(struct rb_node *rb)
 
 static int rq_prio(const struct i915_request *rq)
 {
-   return READ_ONCE(rq->sched.attr.priority);
+   return i915_request_priority(rq);
 }
 
 static int effective_prio(const struct i915_request *rq)
@@ -3278,8 +3278,8 @@ static void kick_execlists(const struct i915_request *rq,
 {
struct intel_engine_cs *engine = rq->engine;
struct i915_sched_engine *sched_engine = engine->sched_engine;
+   const int prio = i915_sched_attr_priority(attr);
const struct i915_request *inflight;
-   const int prio = attr->priority;
 
/*
 * We only need to kick the tasklet once for the high priority
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index 2d5193a9a1d3..a60118461750 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3523,7 +3523,7 @@ static void guc_bump_inflight_request_prio(struct 
i915_request *rq,
   const struct i915_sched_attr *attr)
 {
struct intel_context *ce = request_to_scheduling_context(rq);
-   const int prio = attr->priority;
+   const int prio = i915_sched_attr_priority(attr);
u8 new_guc_prio = map_i915_prio_to_guc_prio(prio);
 
/* Short circuit function */
diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 582770360ad1..960bfd517ff7 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -2093,7 +2093,7 @@ static int print_sched_attr(const struct i915_sched_attr 
*attr,
return x;
 
x += snprintf(buf + x, len - x,
- " prio=%d", attr->prior

[PATCH 1/3] drm/i915: Make some recently added vfuncs use full scheduling attribute

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to
i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC
priority management") introduced some scheduling related vfuncs which
take integer request priority as argument.

Make them instead take struct i915_sched_attr which is the type
encapsulating this information. This better aligns with the codebase
and enables transparently extending the internal data passed along
the scheduling call chains.

Signed-off-by: Tvrtko Ursulin 
Cc: Matthew Brost 
Cc: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 4 +++-
 drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 3 ++-
 drivers/gpu/drm/i915/i915_scheduler.c| 4 ++--
 drivers/gpu/drm/i915/i915_scheduler_types.h  | 4 ++--
 4 files changed, 9 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c 
b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
index f8749c433b7c..8b04c6e4c006 100644
--- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
+++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
@@ -3273,11 +3273,13 @@ static bool can_preempt(struct intel_engine_cs *engine)
return engine->class != RENDER_CLASS;
 }
 
-static void kick_execlists(const struct i915_request *rq, int prio)
+static void kick_execlists(const struct i915_request *rq,
+  const struct i915_sched_attr *attr)
 {
struct intel_engine_cs *engine = rq->engine;
struct i915_sched_engine *sched_engine = engine->sched_engine;
const struct i915_request *inflight;
+   const int prio = attr->priority;
 
/*
 * We only need to kick the tasklet once for the high priority
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c 
b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
index e1612c393781..2d5193a9a1d3 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
@@ -3520,9 +3520,10 @@ static void guc_init_breadcrumbs(struct intel_engine_cs 
*engine)
 }
 
 static void guc_bump_inflight_request_prio(struct i915_request *rq,
-  int prio)
+  const struct i915_sched_attr *attr)
 {
struct intel_context *ce = request_to_scheduling_context(rq);
+   const int prio = attr->priority;
u8 new_guc_prio = map_i915_prio_to_guc_prio(prio);
 
/* Short circuit function */
diff --git a/drivers/gpu/drm/i915/i915_scheduler.c 
b/drivers/gpu/drm/i915/i915_scheduler.c
index 762127dd56c5..534bab99fcdc 100644
--- a/drivers/gpu/drm/i915/i915_scheduler.c
+++ b/drivers/gpu/drm/i915/i915_scheduler.c
@@ -255,7 +255,7 @@ static void __i915_schedule(struct i915_sched_node *node,
 
/* Must be called before changing the nodes priority */
if (sched_engine->bump_inflight_request_prio)
-   sched_engine->bump_inflight_request_prio(from, prio);
+   sched_engine->bump_inflight_request_prio(from, attr);
 
WRITE_ONCE(node->attr.priority, prio);
 
@@ -280,7 +280,7 @@ static void __i915_schedule(struct i915_sched_node *node,
 
/* Defer (tasklet) submission until after all of our updates. */
if (sched_engine->kick_backend)
-   sched_engine->kick_backend(node_to_request(node), prio);
+   sched_engine->kick_backend(node_to_request(node), attr);
}
 
spin_unlock(&sched_engine->lock);
diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h 
b/drivers/gpu/drm/i915/i915_scheduler_types.h
index b0a1b58c7893..24b9ac1c2ce2 100644
--- a/drivers/gpu/drm/i915/i915_scheduler_types.h
+++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
@@ -177,13 +177,13 @@ struct i915_sched_engine {
 * @kick_backend: kick backend after a request's priority has changed
 */
void(*kick_backend)(const struct i915_request *rq,
-   int prio);
+   const struct i915_sched_attr *attr);
 
/**
 * @bump_inflight_request_prio: update priority of an inflight request
 */
void(*bump_inflight_request_prio)(struct i915_request *rq,
- int prio);
+ const struct i915_sched_attr 
*attr);
 
/**
 * @retire_inflight_request_prio: indicate request is retired to
-- 
2.32.0

[PATCH 3/3] drm/i915: Inherit submitter nice when scheduling requests

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Inherit submitter nice at point of request submission to account for
long running processes getting either externally or self re-niced.

Nice value will only apply to requests which originate from user
contexts and have default context priority.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_request.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_request.c 
b/drivers/gpu/drm/i915/i915_request.c
index 960bfd517ff7..a777f14e4b87 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -1811,8 +1811,11 @@ void i915_request_add(struct i915_request *rq)
/* XXX placeholder for selftests */
rcu_read_lock();
ctx = rcu_dereference(rq->context->gem_context);
-   if (ctx)
+   if (ctx) {
attr = ctx->sched;
+   if (attr.priority == I915_CONTEXT_DEFAULT_PRIORITY)
+   attr.nice = task_nice(current);
+   }
rcu_read_unlock();
 
__i915_request_queue(rq, &attr);
-- 
2.32.0

Re: [PATCH] drm/format_helper: fix a kernel-doc typo

[Simon Ser]

On Tuesday, April 5th, 2022 at 16:39, Randy Dunlap  
wrote:

> On 4/4/22 23:26, Javier Martinez Canillas wrote:
>
> > On 4/5/22 08:12, Simon Ser wrote:
> >
> > > On Monday, April 4th, 2022 at 23:35, Randy Dunlap rdun...@infradead.org 
> > > wrote:
> > >
> > > > On 4/4/22 09:04, Simon Ser wrote:
> > > >
> > > > > Both doc patches pushed, thanks. I had to manually edit them because 
> > > > > they
> > > > > wouldn't apply cleanly. Next time, please use git-send-email (see
> > > > > https://git-send-email.io/ for setup instructions).
> > > >
> > > > That's odd. I did use 'git send-email' and I don't usually have any
> > > > problems (AFAIK). I'll check those setup instructions.
> > >
> > > Hm, maybe the issue isn't git-send-email, but the way the patch was
> > > generated? I had to manually edit these lines for the first patch to work:
> > >
> > > --- linux-next-20211217.orig/include/drm/drm_file.h
> > > +++ linux-next-20211217/include/drm/drm_file.h
> > >
> > > I changed these to:
> > >
> > > --- a/include/drm/drm_file.h
> > > +++ b/include/drm/drm_file.h
> > >
> > > This wasn't enough for the second patch, I had to re-do the changes by 
> > > hand
> > > from scratch.
> >
> > Yes, I believe the suggestion should be to use git-format-patch instead.
> >
> > To make sure that was is posted can be consumed by the git-am command.
>
>
> Considering that I am not using git, I think it will be difficult
> to use git-format-patch.

Ah, okay. Would you consider using Git for you next patches?

(FYI, I'll pass next time I hit a patch which doesn't apply cleanly.
Nothing personal, it's just that I don't have time to deal with broken
patches.)

[PATCH v9 0/9] drm/i915/ttm: Evict and restore of compressed object

[Ramalingam C]

On Xe-HP and later devices, we use dedicated compression control
state (CCS) stored in local memory for each surface, to support
the 3D and media compression formats.

The memory required for the CCS of the entire local memory is
1/256 of the local memory size. So before the kernel
boot, the required memory is reserved for the CCS data and a
secure register will be programmed with the CCS base address

So when we allocate a object in local memory we dont need to explicitly
allocate the space for ccs data. But when we evict the obj into the smem
to hold the compression related data along with the obj we need smem
space of obj_size + (obj_size/256).

Hence when we create smem for an obj with lmem placement possibility we
create with the extra space.

When we are swapping out the local memory obj on flat-ccs capable platform,
we need to capture the ccs data too along with main meory and we need to
restore it when we are swapping in the content.

When lmem object is swapped into a smem obj, smem obj will
have the extra pages required to hold the ccs data corresponding to the
lmem main memory. So main memory of lmem will be copied into the initial
pages of the smem and then ccs data corresponding to the main memory
will be copied to the subsequent pages of smem.

Swapin happens exactly in reverse order. First main memory of lmem is
restored from the smem's initial pages and the ccs data will be restored
from the subsequent pages of smem.

Extracting and restoring the CCS data is done through a special cmd called
XY_CTRL_SURF_COPY_BLT

v8 and v9:
  New patch for return value fix
  Fix a return error code

Test-with: 20220405141050.16037-1-ramalinga...@intel.com

Ramalingam C (9):
  drm/i915/gt: use engine instance directly for offset
  drm/i915/gt: Use XY_FAST_COLOR_BLT to clear obj on graphics ver 12+
  drm/i915/gt: Optimize the migration and clear loop
  drm/i915/gt: Pass the -EINVAL when emit_pte doesn't update any PTE
  drm/i915/gt: Clear compress metadata for Flat-ccs objects
  drm/i915/selftest_migrate: Consider the possible roundup of size
  drm/i915/selftest_migrate: Check CCS meta data clear
  drm/i915/gem: Add extra pages in ttm_tt for ccs data
  drm/i915/migrate: Evict and restore the flatccs capable lmem obj

 drivers/gpu/drm/i915/gem/i915_gem_ttm.c  |  30 +-
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  21 +
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 387 +--
 drivers/gpu/drm/i915/gt/selftest_migrate.c   | 253 ++--
 4 files changed, 631 insertions(+), 60 deletions(-)

-- 
2.20.1

[PATCH v9 1/9] drm/i915/gt: use engine instance directly for offset

[Ramalingam C]

To make it uniform across copy and clear, use the engine offset directly
to calculate the offset in the cmd forming for emit_clear.

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 950fd6da146c..9d852a570400 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -613,15 +613,13 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
-static int emit_clear(struct i915_request *rq, u64 offset, int size, u32 value)
+static int emit_clear(struct i915_request *rq, u32 offset, int size, u32 value)
 {
const int ver = GRAPHICS_VER(rq->engine->i915);
u32 *cs;
 
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
 
-   offset += (u64)rq->engine->instance << 32;
-
cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
if (IS_ERR(cs))
return PTR_ERR(cs);
@@ -631,17 +629,16 @@ static int emit_clear(struct i915_request *rq, u64 
offset, int size, u32 value)
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
*cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
-   *cs++ = lower_32_bits(offset);
-   *cs++ = upper_32_bits(offset);
+   *cs++ = offset;
+   *cs++ = rq->engine->instance;
*cs++ = value;
*cs++ = MI_NOOP;
} else {
-   GEM_BUG_ON(upper_32_bits(offset));
*cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (6 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
*cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
-   *cs++ = lower_32_bits(offset);
+   *cs++ = offset;
*cs++ = value;
}
 
-- 
2.20.1

[PATCH v9 3/9] drm/i915/gt: Optimize the migration and clear loop

[Ramalingam C]

Move the static calculations out of the loops for copy and clear.

v2:
  Fix the loss of proper error code on emit_pte

Signed-off-by: Ramalingam C 
Reviewed-by: Thomas Hellstrom  (v1)
---
 drivers/gpu/drm/i915/gt/intel_migrate.c | 34 -
 1 file changed, 17 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index e81f20266f62..e0f1c727662e 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -526,6 +526,7 @@ intel_context_migrate_copy(struct intel_context *ce,
   struct i915_request **out)
 {
struct sgt_dma it_src = sg_sgt(src), it_dst = sg_sgt(dst);
+   u32 src_offset, dst_offset;
struct i915_request *rq;
int err;
 
@@ -535,8 +536,18 @@ intel_context_migrate_copy(struct intel_context *ce,
 
GEM_BUG_ON(ce->ring->size < SZ_64K);
 
+   src_offset = 0;
+   dst_offset = CHUNK_SZ;
+   if (HAS_64K_PAGES(ce->engine->i915)) {
+   src_offset = 0;
+   dst_offset = 0;
+   if (src_is_lmem)
+   src_offset = CHUNK_SZ;
+   if (dst_is_lmem)
+   dst_offset = 2 * CHUNK_SZ;
+   }
+
do {
-   u32 src_offset, dst_offset;
int len;
 
rq = i915_request_create(ce);
@@ -564,17 +575,6 @@ intel_context_migrate_copy(struct intel_context *ce,
if (err)
goto out_rq;
 
-   src_offset = 0;
-   dst_offset = CHUNK_SZ;
-   if (HAS_64K_PAGES(ce->engine->i915)) {
-   src_offset = 0;
-   dst_offset = 0;
-   if (src_is_lmem)
-   src_offset = CHUNK_SZ;
-   if (dst_is_lmem)
-   dst_offset = 2 * CHUNK_SZ;
-   }
-
len = emit_pte(rq, &it_src, src_cache_level, src_is_lmem,
   src_offset, CHUNK_SZ);
if (len <= 0) {
@@ -690,6 +690,7 @@ intel_context_migrate_clear(struct intel_context *ce,
 {
struct sgt_dma it = sg_sgt(sg);
struct i915_request *rq;
+   u32 offset;
int err;
 
GEM_BUG_ON(ce->vm != ce->engine->gt->migrate.context->vm);
@@ -697,8 +698,11 @@ intel_context_migrate_clear(struct intel_context *ce,
 
GEM_BUG_ON(ce->ring->size < SZ_64K);
 
+   offset = 0;
+   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
+   offset = CHUNK_SZ;
+
do {
-   u32 offset;
int len;
 
rq = i915_request_create(ce);
@@ -726,10 +730,6 @@ intel_context_migrate_clear(struct intel_context *ce,
if (err)
goto out_rq;
 
-   offset = 0;
-   if (HAS_64K_PAGES(ce->engine->i915) && is_lmem)
-   offset = CHUNK_SZ;
-
len = emit_pte(rq, &it, cache_level, is_lmem, offset, CHUNK_SZ);
if (len <= 0) {
err = len;
-- 
2.20.1

[PATCH v9 2/9] drm/i915/gt: Use XY_FAST_COLOR_BLT to clear obj on graphics ver 12+

[Ramalingam C]

Use faster XY_FAST_COLOR_BLT cmd on graphics version of 12 and more,
for clearing (Zero out) the pages of the newly allocated object.

XY_FAST_COLOR_BLT is faster than the older XY_COLOR_BLT.

v2:
  Typo fix at title [Thomas]
v3:
  XY_FAST_COLOR_BLT is used only for FLAT_CCS capable gen12+

Signed-off-by: Ramalingam C 
Signed-off-by: Chris Wilson 
Reviewed-by: Thomas Hellstrom 
---
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |  5 +++
 drivers/gpu/drm/i915/gt/intel_migrate.c  | 43 +---
 2 files changed, 43 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index 4243be030bc1..d1b8c23f7a9e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -206,6 +206,11 @@
 
 #define COLOR_BLT_CMD  (2 << 29 | 0x40 << 22 | (5 - 2))
 #define XY_COLOR_BLT_CMD   (2 << 29 | 0x50 << 22)
+#define XY_FAST_COLOR_BLT_CMD  (2 << 29 | 0x44 << 22)
+#define   XY_FAST_COLOR_BLT_DEPTH_32   (2 << 19)
+#define   XY_FAST_COLOR_BLT_DW 16
+#define   XY_FAST_COLOR_BLT_MOCS_MASK  GENMASK(27, 21)
+#define   XY_FAST_COLOR_BLT_MEM_TYPE_SHIFT 31
 #define SRC_COPY_BLT_CMD   (2 << 29 | 0x43 << 22)
 #define GEN9_XY_FAST_COPY_BLT_CMD  (2 << 29 | 0x42 << 22)
 #define XY_SRC_COPY_BLT_CMD(2 << 29 | 0x53 << 22)
diff --git a/drivers/gpu/drm/i915/gt/intel_migrate.c 
b/drivers/gpu/drm/i915/gt/intel_migrate.c
index 9d852a570400..e81f20266f62 100644
--- a/drivers/gpu/drm/i915/gt/intel_migrate.c
+++ b/drivers/gpu/drm/i915/gt/intel_migrate.c
@@ -613,18 +613,51 @@ intel_context_migrate_copy(struct intel_context *ce,
return err;
 }
 
-static int emit_clear(struct i915_request *rq, u32 offset, int size, u32 value)
+static int emit_clear(struct i915_request *rq, u32 offset, int size,
+ u32 value, bool is_lmem)
 {
-   const int ver = GRAPHICS_VER(rq->engine->i915);
+   struct drm_i915_private *i915 = rq->engine->i915;
+   int mocs = rq->engine->gt->mocs.uc_index << 1;
+   const int ver = GRAPHICS_VER(i915);
+   int ring_sz;
u32 *cs;
 
GEM_BUG_ON(size >> PAGE_SHIFT > S16_MAX);
 
-   cs = intel_ring_begin(rq, ver >= 8 ? 8 : 6);
+   if (HAS_FLAT_CCS(i915) && ver >= 12)
+   ring_sz = XY_FAST_COLOR_BLT_DW;
+   else if (ver >= 8)
+   ring_sz = 8;
+   else
+   ring_sz = 6;
+
+   cs = intel_ring_begin(rq, ring_sz);
if (IS_ERR(cs))
return PTR_ERR(cs);
 
-   if (ver >= 8) {
+   if (HAS_FLAT_CCS(i915) && ver >= 12) {
+   *cs++ = XY_FAST_COLOR_BLT_CMD | XY_FAST_COLOR_BLT_DEPTH_32 |
+   (XY_FAST_COLOR_BLT_DW - 2);
+   *cs++ = FIELD_PREP(XY_FAST_COLOR_BLT_MOCS_MASK, mocs) |
+   (PAGE_SIZE - 1);
+   *cs++ = 0;
+   *cs++ = size >> PAGE_SHIFT << 16 | PAGE_SIZE / 4;
+   *cs++ = offset;
+   *cs++ = rq->engine->instance;
+   *cs++ = !is_lmem << XY_FAST_COLOR_BLT_MEM_TYPE_SHIFT;
+   /* BG7 */
+   *cs++ = value;
+   *cs++ = 0;
+   *cs++ = 0;
+   *cs++ = 0;
+   /* BG11 */
+   *cs++ = 0;
+   *cs++ = 0;
+   /* BG13 */
+   *cs++ = 0;
+   *cs++ = 0;
+   *cs++ = 0;
+   } else if (ver >= 8) {
*cs++ = XY_COLOR_BLT_CMD | BLT_WRITE_RGBA | (7 - 2);
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | PAGE_SIZE;
*cs++ = 0;
@@ -707,7 +740,7 @@ intel_context_migrate_clear(struct intel_context *ce,
if (err)
goto out_rq;
 
-   err = emit_clear(rq, offset, len, value);
+   err = emit_clear(rq, offset, len, value, is_lmem);
 
/* Arbitration is re-enabled between requests. */
 out_rq:
-- 
2.20.1