[PATCH v1] drm/ttm: Clean up page shift operation

[Somalapuram Amaranath]

Remove page shift operations as ttm_resource moved
from num_pages to size_t size in bytes.
v1 -> v2: fix missing page shift to fpfn and lpfn

Signed-off-by: Somalapuram Amaranath 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c |  4 +---
 drivers/gpu/drm/ttm/ttm_range_manager.c| 13 ++---
 2 files changed, 7 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index 974e85d8b6cc..19ad365dc159 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -541,12 +541,10 @@ int amdgpu_bo_create(struct amdgpu_device *adev,
if (bp->domain & (AMDGPU_GEM_DOMAIN_GWS | AMDGPU_GEM_DOMAIN_OA)) {
/* GWS and OA don't need any alignment. */
page_align = bp->byte_align;
-   size <<= PAGE_SHIFT;
-
} else if (bp->domain & AMDGPU_GEM_DOMAIN_GDS) {
/* Both size and alignment must be a multiple of 4. */
page_align = ALIGN(bp->byte_align, 4);
-   size = ALIGN(size, 4) << PAGE_SHIFT;
+   size = ALIGN(size, 4);
} else {
/* Memory should be aligned at least to a page size. */
page_align = ALIGN(bp->byte_align, PAGE_SIZE) >> PAGE_SHIFT;
diff --git a/drivers/gpu/drm/ttm/ttm_range_manager.c 
b/drivers/gpu/drm/ttm/ttm_range_manager.c
index 0a8bc0b7f380..6ac38092dd2a 100644
--- a/drivers/gpu/drm/ttm/ttm_range_manager.c
+++ b/drivers/gpu/drm/ttm/ttm_range_manager.c
@@ -83,9 +83,10 @@ static int ttm_range_man_alloc(struct ttm_resource_manager 
*man,
 
spin_lock(&rman->lock);
ret = drm_mm_insert_node_in_range(mm, &node->mm_nodes[0],
- PFN_UP(node->base.size),
+ node->base.size,
  bo->page_alignment, 0,
- place->fpfn, lpfn, mode);
+ place->fpfn << PAGE_SHIFT,
+ lpfn << PAGE_SHIFT, mode);
spin_unlock(&rman->lock);
 
if (unlikely(ret)) {
@@ -119,11 +120,10 @@ static bool ttm_range_man_intersects(struct 
ttm_resource_manager *man,
 size_t size)
 {
struct drm_mm_node *node = &to_ttm_range_mgr_node(res)->mm_nodes[0];
-   u32 num_pages = PFN_UP(size);
 
/* Don't evict BOs outside of the requested placement range */
-   if (place->fpfn >= (node->start + num_pages) ||
-   (place->lpfn && place->lpfn <= node->start))
+   if ((place->fpfn << PAGE_SHIFT) >= (node->start + size) ||
+   (place->lpfn && (place->lpfn << PAGE_SHIFT) <= node->start))
return false;
 
return true;
@@ -135,10 +135,9 @@ static bool ttm_range_man_compatible(struct 
ttm_resource_manager *man,
 size_t size)
 {
struct drm_mm_node *node = &to_ttm_range_mgr_node(res)->mm_nodes[0];
-   u32 num_pages = PFN_UP(size);
 
if (node->start < place->fpfn ||
-   (place->lpfn && (node->start + num_pages) > place->lpfn))
+   (place->lpfn && (node->start + size) > place->lpfn << PAGE_SHIFT))
return false;
 
return true;
-- 
2.32.0

Re: [6.1][regression] after commit dd80d9c8eecac8c516da5b240d01a35660ba6cb6 some games (Cyberpunk 2077, Forza Horizon 4/5) hang at start

[Christian König]

Am 22.11.22 um 00:42 schrieb Mikhail Gavrilov:

On Mon, Nov 14, 2022 at 6:22 PM Christian König
 wrote:

I've found and fixed a few problems around the userptr handling which
might explain what you see here.

A series of four patches starting with "drm/amdgpu: always register an
MMU notifier for userptr" is under review now.

Going to give that a bit cleanup later today and will CC you when I send
that out. Would be nice if you could give that some testing.

Thanks,
Christian.


Christian, I tested all four patches around week and can say that this
issue is completely gone.
All known broken games working.
Tested-by: Mikhail Gavrilov 


Ah, thanks a lot for this. I've already pushed the patches into our 
internal branch, but getting this confirmation is still great!


This was quite some fundamental bug in the handling and I hope to get 
this completely reworked at some point since it is currently only mitigated.



The only thing I don't like is the flood in the kernel logs of the
message "WARNING message at drivers/gpu/drm/drm_modeset_lock.c:276
drm_modeset_drop_locks+0x63/0x70", but this is not related to the
patches being checked.
All kernel logs uploaded to pastebin [1][2][3][4][5][6][7][8]


No idea what that could be. Modesetting is not something I work on.

The best advice I can give you is to maybe ping Harry and our other 
display people, they should know that stuff better than I do.


Thanks,
Christian.



I wrote a separate bug report about "drm_modeset_lock" [9], it's a
pity that no one paid attention to it. I even found the first bad
commit. It is b261509952bc19d1012cf732f853659be6ebc61e.

[1] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FWZWczupk&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709676882205%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wdVnVqVbQ2Ru1fZRmg6P%2FAvP6n98%2F9lkbFQJMXFX%2BBo%3D&reserved=0
[2] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Ff4i9pvjS&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MnnBdy%2FaxmTwfu28WHgGW7Pu9glPsHDsL6oZ8lQl%2BoI%3D&reserved=0
[3] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FrsDWaMR1&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SOC29d5HCDj1qiLQl2KMTea7K1TCv4WCIi0EDteUwcQ%3D&reserved=0
[4] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FtDNEYJq0&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xNrjwqAUVWYIzsS6zkci09ursNvlufn1dHFJtyx7N40%3D&reserved=0
[5] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FxfZVbm1f&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=B6P5oIjmqQbaet56%2B3eFWM4%2BrYvqLdRxuzG4DvCsrQw%3D&reserved=0
[6] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FVx9gDyKt&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Im0yuNgmRl8kwiAbZD284dp08jyrtIpTzNa9qsTYnfQ%3D&reserved=0
[7] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FXvRkLckV&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sHeQUZGur1kC5PEJV18KwNHha8WUPNj9wgAfNusg4H4%3D&reserved=0
[8] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2Fpd8WBkgx&data=05%7C01%7Cchristian.koenig%40amd.com%7C5df2793e7deb48add3f008dacc1a176d%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046709677038445%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=SWI76x2nLqiI%2BLWSfBo8iU5nYMnIN9gplDdhsg8jrFg%3D&reserved=0
[9] 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.spinics.net%2Flists%2

[PATCH v4] drm/i915/mtl: Media GT and Render GT share common GGTT

[Aravind Iddamsetty]

On XE_LPM+ platforms the media engines are carved out into a separate
GT but have a common GGTMMADR address range which essentially makes
the GGTT address space to be shared between media and render GT. As a
result any updates in GGTT shall invalidate TLB of GTs sharing it and
similarly any operation on GGTT requiring an action on a GT will have to
involve all GTs sharing it. setup_private_pat was being done on a per
GGTT based as that doesn't touch any GGTT structures moved it to per GT
based.

BSPEC: 63834

v2:
1. Add details to commit msg
2. includes fix for failure to add item to ggtt->gt_list, as suggested
by Lucas
3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
it.
4. setup_private_pat moved out of intel_gt_tiles_init

v3:
1. Move out for_each_gt from i915_driver.c (Jani Nikula)

v4: drop using RCU primitives on ggtt->gt_list as it is not an RCU list
(Matt Roper)

Cc: Matt Roper 
Signed-off-by: Aravind Iddamsetty 
---
 drivers/gpu/drm/i915/gt/intel_ggtt.c  | 54 +--
 drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
 drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
 drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
 drivers/gpu/drm/i915/i915_driver.c| 12 ++---
 drivers/gpu/drm/i915/i915_gem.c   |  2 +
 drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
 drivers/gpu/drm/i915/i915_vma.c   |  5 ++-
 drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
 9 files changed, 111 insertions(+), 35 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
b/drivers/gpu/drm/i915/gt/intel_ggtt.c
index 8145851ad23d..7644738b9cdb 100644
--- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
+++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
@@ -8,6 +8,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 
@@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space *vm)
 
 void i915_ggtt_suspend(struct i915_ggtt *ggtt)
 {
+   struct intel_gt *gt;
+
i915_ggtt_suspend_vm(&ggtt->vm);
ggtt->invalidate(ggtt);
 
-   intel_gt_check_and_clear_faults(ggtt->vm.gt);
+   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+   intel_gt_check_and_clear_faults(gt);
 }
 
 void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
@@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt *ggtt)
 
 static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
 {
-   struct intel_uncore *uncore = ggtt->vm.gt->uncore;
struct drm_i915_private *i915 = ggtt->vm.i915;
 
gen8_ggtt_invalidate(ggtt);
 
-   if (GRAPHICS_VER(i915) >= 12)
-   intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
- GEN12_GUC_TLB_INV_CR_INVALIDATE);
-   else
-   intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   if (GRAPHICS_VER(i915) >= 12) {
+   struct intel_gt *gt;
+
+   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+   intel_uncore_write_fw(gt->uncore,
+ GEN12_GUC_TLB_INV_CR,
+ GEN12_GUC_TLB_INV_CR_INVALIDATE);
+   } else {
+   intel_uncore_write_fw(ggtt->vm.gt->uncore,
+ GEN8_GTCR, GEN8_GTCR_INVALIDATE);
+   }
 }
 
 u64 gen8_ggtt_pte_encode(dma_addr_t addr,
@@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
 
ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
 
-   setup_private_pat(ggtt->vm.gt);
-
return ggtt_probe_common(ggtt, size);
 }
 
@@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, struct 
intel_gt *gt)
  */
 int i915_ggtt_probe_hw(struct drm_i915_private *i915)
 {
-   int ret;
+   struct intel_gt *gt;
+   int ret, i;
+
+   for_each_gt(gt, i915, i) {
+   ret = intel_gt_assign_ggtt(gt);
+   if (ret)
+   return ret;
+   }
 
ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
if (ret)
@@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
return 0;
 }
 
+struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
+{
+   struct i915_ggtt *ggtt;
+
+   ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
+   if (!ggtt)
+   return ERR_PTR(-ENOMEM);
+
+   INIT_LIST_HEAD(&ggtt->gt_list);
+
+   return ggtt;
+}
+
 int i915_ggtt_enable_hw(struct drm_i915_private *i915)
 {
if (GRAPHICS_VER(i915) < 6)
@@ -1296,9 +1323,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space *vm)
 
 void i915_ggtt_resume(struct i915_ggtt *ggtt)
 {
+   struct intel_gt *gt;
bool flush;
 
-   intel_gt_check_and_clear_faults(ggtt->vm.gt);
+   list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
+   intel_gt_check_and_clear_faults(gt);
 
flush = i915_ggtt_resume_vm(&ggtt->vm);
 
@@ -1307,9 +1336,6 @@ void 

Re: [PATCH 2/2] drm/gem: Remove BUG_ON in drm_gem_private_object_init

[Arunpravin Paneer Selvam]

On 11/22/2022 10:48 AM, Somalapuram, Amaranath wrote:


On 11/16/2022 2:50 PM, Arunpravin Paneer Selvam wrote:

Hi Amar,

On 11/16/2022 2:20 PM, Somalapuram Amaranath wrote:

ttm_resource allocate size in bytes i.e less than page size.

Signed-off-by: Somalapuram Amaranath 
---
  drivers/gpu/drm/drm_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..a346e3b7f9a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_gem_object_init);
  void drm_gem_private_object_init(struct drm_device *dev,
   struct drm_gem_object *obj, size_t size)
  {
-    BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+    //BUG_ON((size & (PAGE_SIZE - 1)) != 0);

This line is added by mistake?


No this breaks when the size is less than page size.

Now we support size in bytes.


I see the line BUG_ON is commented out


Regards,
Arun

    obj->dev = dev;
  obj->filp = NULL;

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Dave Airlie]

On Tue, 22 Nov 2022 at 09:06, Sonal Santan  wrote:
>
> On 11/19/22 12:44, Oded Gabbay wrote:
> > This is the fourth (and hopefully last) version of the patch-set to add the
> > new subsystem for compute accelerators. I removed the RFC headline as
> > I believe it is now ready for merging.
> >
> > Compare to v3, this patch-set contains one additional patch that adds
> > documentation regarding the accel subsystem. I hope it's good enough for
> > this stage. In addition, there were few very minor fixes according to
> > comments received on v3.
> >
> > The patches are in the following repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> >
> > As in v3, The HEAD of that branch is a commit adding a dummy driver that
> > registers an accel device using the new framework. This can be served
> > as a simple reference.
> >
> > v1 cover letter:
> > https://lkml.org/lkml/2022/10/22/544
> >
> > v2 cover letter:
> > https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
> >
> > v3 cover letter:
> > https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/
>
> Thanks for defining the new accel subsystem. We are currently working on
> DRM based drivers for unannounced acceleration devices. I am fine with
> these changes with the assumption that the choice of using classic DRM
> or accel is left up to the individual driver.

I don't think that decision should be up to any individual driver
author. It will have to be consensus with me/Daniel/Oded and the
driver authors.

Dave.

Re: [PATCH 2/2] drm/gem: Remove BUG_ON in drm_gem_private_object_init

[Somalapuram, Amaranath]

On 11/16/2022 2:50 PM, Arunpravin Paneer Selvam wrote:

Hi Amar,

On 11/16/2022 2:20 PM, Somalapuram Amaranath wrote:

ttm_resource allocate size in bytes i.e less than page size.

Signed-off-by: Somalapuram Amaranath 
---
  drivers/gpu/drm/drm_gem.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index b8db675e7fb5..a346e3b7f9a8 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -152,7 +152,7 @@ EXPORT_SYMBOL(drm_gem_object_init);
  void drm_gem_private_object_init(struct drm_device *dev,
   struct drm_gem_object *obj, size_t size)
  {
-    BUG_ON((size & (PAGE_SIZE - 1)) != 0);
+    //BUG_ON((size & (PAGE_SIZE - 1)) != 0);

This line is added by mistake?


No this breaks when the size is less than page size.

Now we support size in bytes.



Regards,
Arun

    obj->dev = dev;
  obj->filp = NULL;

[PATCH v2] drm/amdgpu: Fix potential double free and null pointer dereference

[Liang He]

In amdgpu_get_xgmi_hive(), we should not call kfree() after
kobject_put() as the PUT will call kfree().

In amdgpu_device_ip_init(), we need to check the returned *hive*
which can be NULL before we dereference it.

Signed-off-by: Liang He 
---
 v1->v2: we need the extra GET to keep *hive* alive, it is
 my fault to remove the GET in v1.


 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 2 --
 2 files changed, 5 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f1e9663b4051..00976e15b698 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2462,6 +2462,11 @@ static int amdgpu_device_ip_init(struct amdgpu_device 
*adev)
if (!amdgpu_sriov_vf(adev)) {
struct amdgpu_hive_info *hive = 
amdgpu_get_xgmi_hive(adev);
 
+   if (WARN_ON(!hive)) {
+   r = -ENOENT;
+   goto init_failed;
+   }
+
if (!hive->reset_domain ||

!amdgpu_reset_get_reset_domain(hive->reset_domain)) {
r = -ENOENT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 47159e9a0884..4b9e7b050ccd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -386,7 +386,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
if (ret) {
dev_err(adev->dev, "XGMI: failed initializing kobject for xgmi 
hive\n");
kobject_put(&hive->kobj);
-   kfree(hive);
hive = NULL;
goto pro_end;
}
@@ -410,7 +409,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
dev_err(adev->dev, "XGMI: failed initializing 
reset domain for xgmi hive\n");
ret = -ENOMEM;
kobject_put(&hive->kobj);
-   kfree(hive);
hive = NULL;
goto pro_end;
}
-- 
2.25.1

[PATCH] drm/amdgpu: Fix Double Free, Null Pointer Dereference and MemLeak

[Liang He]

In amdgpu_get_xgmi_hive(), we should not call kfree() after
kobject_put() as the PUT will call kfree(). Besides, we should
not call kobject_get() again for the new *alloced* as its
refcount will be initialized to 1 for the returned *hive*.

In amdgpu_device_ip_init(), we need to check the returned *hive*
which can be NULL before we dereference it.

Signed-off-by: Liang He 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 5 +
 drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c   | 4 
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index f1e9663b4051..00976e15b698 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -2462,6 +2462,11 @@ static int amdgpu_device_ip_init(struct amdgpu_device 
*adev)
if (!amdgpu_sriov_vf(adev)) {
struct amdgpu_hive_info *hive = 
amdgpu_get_xgmi_hive(adev);
 
+   if (WARN_ON(!hive)) {
+   r = -ENOENT;
+   goto init_failed;
+   }
+
if (!hive->reset_domain ||

!amdgpu_reset_get_reset_domain(hive->reset_domain)) {
r = -ENOENT;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
index 47159e9a0884..26adc7293468 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_xgmi.c
@@ -386,7 +386,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
if (ret) {
dev_err(adev->dev, "XGMI: failed initializing kobject for xgmi 
hive\n");
kobject_put(&hive->kobj);
-   kfree(hive);
hive = NULL;
goto pro_end;
}
@@ -410,7 +409,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
dev_err(adev->dev, "XGMI: failed initializing 
reset domain for xgmi hive\n");
ret = -ENOMEM;
kobject_put(&hive->kobj);
-   kfree(hive);
hive = NULL;
goto pro_end;
}
@@ -437,8 +435,6 @@ struct amdgpu_hive_info *amdgpu_get_xgmi_hive(struct 
amdgpu_device *adev)
list_add_tail(&hive->node, &xgmi_hive_list);
 
 pro_end:
-   if (hive)
-   kobject_get(&hive->kobj);
mutex_unlock(&xgmi_mutex);
return hive;
 }
-- 
2.25.1

Re: [PATCH v1 6/8] drm: rcar-du: Add r8a779g0 support

[Laurent Pinchart]

On Thu, Nov 17, 2022 at 03:08:38PM +, Kieran Bingham wrote:
> Quoting Tomi Valkeinen (2022-11-17 12:25:45)
> > From: Tomi Valkeinen 
> > 
> > Add support for DU on r8a779g0, which is identical to DU on r8a779a0.
> > 
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  drivers/gpu/drm/rcar-du/rcar_du_drv.c | 22 ++
> >  1 file changed, 22 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_drv.c 
> > b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > index d003e8d9e7a2..b1761d4ec4e5 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_drv.c
> > @@ -524,6 +524,27 @@ static const struct rcar_du_device_info 
> > rcar_du_r8a779a0_info = {
> > .dsi_clk_mask =  BIT(1) | BIT(0),
> >  };
> >  
> > +static const struct rcar_du_device_info rcar_du_r8a779g0_info = {
> > +   .gen = 3,
> 
> Given that this is the V4H ... I wonder if this should be bumped
> already. I guess that has knock on effects through the driver though...

rcar_du_group_setup_didsr() would need to be fixed to test gen >= 3
instead of gen == 3. That seems to be the only problematic location. It
could thus fairly easily be done in v2, but we can also delay it.

> Aside from that, Which may need more work to handle correctly:
> 
> Reviewed-by: Kieran Bingham 

Reviewed-by: Laurent Pinchart 

> > +   .features = RCAR_DU_FEATURE_CRTC_IRQ
> > + | RCAR_DU_FEATURE_VSP1_SOURCE
> > + | RCAR_DU_FEATURE_NO_BLENDING,
> > +   .channels_mask = BIT(1) | BIT(0),
> > +   .routes = {
> > +   /* R8A779G0 has two MIPI DSI outputs. */
> > +   [RCAR_DU_OUTPUT_DSI0] = {
> > +   .possible_crtcs = BIT(0),
> > +   .port = 0,
> > +   },
> > +   [RCAR_DU_OUTPUT_DSI1] = {
> > +   .possible_crtcs = BIT(1),
> > +   .port = 1,
> > +   },
> > +   },
> > +   .num_rpf = 5,
> > +   .dsi_clk_mask =  BIT(1) | BIT(0),
> > +};
> > +
> >  static const struct of_device_id rcar_du_of_table[] = {
> > { .compatible = "renesas,du-r8a7742", .data = &rcar_du_r8a7790_info 
> > },
> > { .compatible = "renesas,du-r8a7743", .data = &rzg1_du_r8a7743_info 
> > },
> > @@ -549,6 +570,7 @@ static const struct of_device_id rcar_du_of_table[] = {
> > { .compatible = "renesas,du-r8a77990", .data = 
> > &rcar_du_r8a7799x_info },
> > { .compatible = "renesas,du-r8a77995", .data = 
> > &rcar_du_r8a7799x_info },
> > { .compatible = "renesas,du-r8a779a0", .data = 
> > &rcar_du_r8a779a0_info },
> > +   { .compatible = "renesas,du-r8a779g0", .data = 
> > &rcar_du_r8a779g0_info },
> > { }
> >  };
> >  

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 5/8] arm64: dts: renesas: white-hawk-cpu: Add DP output support

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thu, Nov 17, 2022 at 02:25:44PM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen 
> 
> Add DT nodes needed for the mini DP connector. The DP is driven by
> sn65dsi86, which in turn gets the pixel data from the SoC via DSI.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  .../dts/renesas/r8a779g0-white-hawk-cpu.dtsi  | 94 +++
>  1 file changed, 94 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi 
> b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> index c10740aee9f6..8aab859aac7a 100644
> --- a/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a779g0-white-hawk-cpu.dtsi
> @@ -97,6 +97,15 @@ memory@6 {
>   reg = <0x6 0x 0x1 0x>;
>   };
>  
> + reg_1p2v: regulator-1p2v {
> + compatible = "regulator-fixed";
> + regulator-name = "fixed-1.2V";
> + regulator-min-microvolt = <120>;
> + regulator-max-microvolt = <120>;
> + regulator-boot-on;
> + regulator-always-on;
> + };
> +
>   reg_1p8v: regulator-1p8v {
>   compatible = "regulator-fixed";
>   regulator-name = "fixed-1.8V";
> @@ -114,6 +123,24 @@ reg_3p3v: regulator-3p3v {
>   regulator-boot-on;
>   regulator-always-on;
>   };
> +
> + mini-dp-con {
> + compatible = "dp-connector";
> + label = "CN5";
> + type = "mini";
> +
> + port {
> + mini_dp_con_in: endpoint {
> + remote-endpoint = <&sn65dsi86_out>;
> + };
> + };
> + };
> +
> + sn65dsi86_refclk: clk-x6 {
> + compatible = "fixed-clock";
> + #clock-cells = <0>;
> + clock-frequency = <3840>;
> + };
>  };
>  
>  &avb0 {
> @@ -134,6 +161,23 @@ phy0: ethernet-phy@0 {
>   };
>  };
>  
> +&dsi0 {
> + status = "okay";
> +
> + ports {
> + port@1 {
> + dsi0_out: endpoint {
> + remote-endpoint = <&sn65dsi86_in>;
> + data-lanes = <1 2 3 4>;
> + };
> + };
> + };
> +};
> +
> +&du {
> + status = "okay";
> +};
> +
>  &extal_clk {
>   clock-frequency = <1666>;
>  };
> @@ -172,6 +216,51 @@ eeprom@50 {
>   };
>  };
>  
> +&i2c1 {
> + pinctrl-0 = <&i2c1_pins>;
> + pinctrl-names = "default";
> +
> + status = "okay";
> + clock-frequency = <40>;
> +
> + bridge@2c {
> + compatible = "ti,sn65dsi86";
> + reg = <0x2c>;
> +
> + clocks = <&sn65dsi86_refclk>;
> + clock-names = "refclk";
> +
> + interrupt-parent = <&intc_ex>;
> + interrupts = <0 IRQ_TYPE_LEVEL_HIGH>;
> +
> + enable-gpios = <&gpio1 26 GPIO_ACTIVE_HIGH>;
> +
> + vccio-supply = <®_1p8v>;
> + vpll-supply = <®_1p8v>;
> + vcca-supply = <®_1p2v>;
> + vcc-supply = <®_1p2v>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + sn65dsi86_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + sn65dsi86_out: endpoint {
> + remote-endpoint = <&mini_dp_con_in>;
> + };
> + };
> + };
> + };
> +};
> +
>  &mmc0 {
>   pinctrl-0 = <&mmc_pins>;
>   pinctrl-1 = <&mmc_pins>;
> @@ -221,6 +310,11 @@ i2c0_pins: i2c0 {
>   function = "i2c0";
>   };
>  
> + i2c1_pins: i2c1 {
> + groups = "i2c1";
> + function = "i2c1";
> + };
> +
>   keys_pins: keys {
>   pins = "GP_5_0", "GP_5_1", "GP_5_2";
>   bias-pull-up;

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 4/8] arm64: dts: renesas: r8a779g0: Add display related data

[Laurent Pinchart]

On Thu, Nov 17, 2022 at 03:03:39PM +, Kieran Bingham wrote:
> Quoting Tomi Valkeinen (2022-11-17 12:25:43)
> > From: Tomi Valkeinen 
> > 
> > Add DT nodes for components needed to get the DSI output working:
> > - FCPv
> > - VSPd
> > - DU
> > - DSI
> > 
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  arch/arm64/boot/dts/renesas/r8a779g0.dtsi | 129 ++
> >  1 file changed, 129 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi 
> > b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > index 45d8d927ad26..31d4930c5adc 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a779g0.dtsi
> > @@ -1207,6 +1207,135 @@ prr: chipid@fff00044 {
> > compatible = "renesas,prr";
> > reg = <0 0xfff00044 0 4>;
> > };
> 
> I think these nodes are supposed to be in sort order based on the
> register address in memory.
> 
> Disregarding sort order, I'll review the node contents.
> 
> I would probably s/data/nodes/ in $SUBJECT too.
> 
> > +
> > +   fcpvd0: fcp@fea1 {
> > +   compatible = "renesas,fcpv";
> > +   reg = <0 0xfea1 0 0x200>;
> > +   clocks = <&cpg CPG_MOD 508>;
> > +   power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +   resets = <&cpg 508>;
> > +   };
> > +
> > +   fcpvd1: fcp@fea11000 {
> > +   compatible = "renesas,fcpv";
> > +   reg = <0 0xfea11000 0 0x200>;
> > +   clocks = <&cpg CPG_MOD 509>;
> > +   power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +   resets = <&cpg 509>;
> > +   };
> 
> I'm intrigued at the length of 0x200 as I only see 3 registers up to
> 0x0018 ..
> 
> But all existing platforms with fcpv* set 0x200 ... so lets cargo cult it 
> up... :-)
> 
> > +
> > +   vspd0: vsp@fea2 {
> > +   compatible = "renesas,vsp2";
> > +   reg = <0 0xfea2 0 0x5000>;
> 
> """
> Below are the base addresses of each VSP unit. VSPX has 32Kbyte address
> space. VSPD has 28Kbyte address space.
> """
> 
> Hrm : 28K is 0x7000
> 
> RPf n OSD CLUT Table: H’4000 + H’0400*n to H’43fc + H’0400*n
> 
>  0x43fc+(0x400*5)
>   22524   [0x57fc]
> 
> So this needs to be /at least/ 0x6000 (Would 0x5800 be odd?) and perhaps as 
> it clearly states
> 28k, we should just set it to 0x7000.

I'd go for 0x7000 indeed.

> > +   interrupts = ;
> > +   clocks = <&cpg CPG_MOD 830>;
> > +   power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +   resets = <&cpg 830>;
> > +
> > +   renesas,fcp = <&fcpvd0>;
> > +   };
> > +
> > +   vspd1: vsp@fea28000 {
> > +   compatible = "renesas,vsp2";
> > +   reg = <0 0xfea28000 0 0x5000>;
> 
> Same here of course (reg = <0 0xfea28000 0 0x7000>)
> 
> > +   interrupts = ;
> > +   clocks = <&cpg CPG_MOD 831>;
> > +   power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +   resets = <&cpg 831>;
> > +
> > +   renesas,fcp = <&fcpvd1>;
> > +   };
> > +
> > +   du: display@feb0 {
> > +   compatible = "renesas,du-r8a779g0";
> > +   reg = <0 0xfeb0 0 0x4>;
> > +   interrupts = ,
> > +;
> > +   clocks = <&cpg CPG_MOD 411>;
> > +   clock-names = "du.0";
> > +   power-domains = <&sysc R8A779G0_PD_ALWAYS_ON>;
> > +   resets = <&cpg 411>;
> > +   reset-names = "du.0";
> > +   renesas,vsps = <&vspd0 0>, <&vspd1 0>;
> > +
> > +   status = "disabled";
> > +
> > +   ports {
> > +   #address-cells = <1>;
> > +   #size-cells = <0>;
> > +
> > +   port@0 {
> > +   reg = <0>;
> > +   du_out_dsi0: endpoint {
> > +   remote-endpoint = 
> > <&dsi0_in>;
> > +   };
> > +   };
> > +
> > +   port@1 {
> > +   reg = <1>;
> > +   du_out_dsi1: endpoint {
> > +   remote-endpoint = 
> > <&dsi1_in>;
> > +   };
> > +   };
> > +   };
> > +   };

Re: [PATCH v1 3/8] clk: renesas: r8a779g0: Add display related clocks

[Laurent Pinchart]

On Thu, Nov 17, 2022 at 02:08:57PM +, Kieran Bingham wrote:
> Quoting Tomi Valkeinen (2022-11-17 12:25:42)
> > From: Tomi Valkeinen 
> > 
> > Add clocks related to display which are needed to get the DSI output
> > working.
> > 
> > Extracted from Renesas BSP tree.
> > 
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  drivers/clk/renesas/r8a779g0-cpg-mssr.c | 14 ++
> >  1 file changed, 14 insertions(+)
> > 
> > diff --git a/drivers/clk/renesas/r8a779g0-cpg-mssr.c 
> > b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> > index c6337a408e5e..6937f1aee677 100644
> > --- a/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> > +++ b/drivers/clk/renesas/r8a779g0-cpg-mssr.c
> > @@ -145,6 +145,8 @@ static const struct cpg_core_clk r8a779g0_core_clks[] 
> > __initconst = {
> > DEF_FIXED("viobusd2",   R8A779G0_CLK_VIOBUSD2,  CLK_VIO,2, 
> > 1),
> > DEF_FIXED("vcbus",  R8A779G0_CLK_VCBUS, CLK_VC, 1, 
> > 1),
> > DEF_FIXED("vcbusd2",R8A779G0_CLK_VCBUSD2,   CLK_VC, 2, 
> > 1),
> > +   DEF_FIXED("dsiref", R8A779G0_CLK_DSIREF,CLK_PLL5_DIV4,  48, 
> > 1),
> > +   DEF_DIV6P1("dsiext",R8A779G0_CLK_DSIEXT,CLK_PLL5_DIV4,  
> > 0x884),
> >  
> > DEF_GEN4_SDH("sd0h",R8A779G0_CLK_SD0H,  CLK_SDSRC, 
> > 0x870),
> > DEF_GEN4_SD("sd0",  R8A779G0_CLK_SD0,   R8A779G0_CLK_SD0H, 
> > 0x870),
> > @@ -161,6 +163,14 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[] 
> > __initconst = {
> > DEF_MOD("avb0", 211,R8A779G0_CLK_S0D4_HSC),
> > DEF_MOD("avb1", 212,R8A779G0_CLK_S0D4_HSC),
> > DEF_MOD("avb2", 213,R8A779G0_CLK_S0D4_HSC),
> > +
> > +   DEF_MOD("dis0", 411,R8A779G0_CLK_S0D3),
> 
> dsi0?
> 
> Oh - how curious - it's listed as dis0 in the datasheet.
> Ok - so this is the DU *display* not DSI ;-)
> 
> > +   DEF_MOD("dsitxlink0",   415,R8A779G0_CLK_DSIREF),
> > +   DEF_MOD("dsitxlink1",   416,R8A779G0_CLK_DSIREF),
> > +
> > +   DEF_MOD("fcpvd0",   508,R8A779G0_CLK_S0D3),
> > +   DEF_MOD("fcpvd1",   509,R8A779G0_CLK_S0D3),
> > +
> 
> checks out. I guess the fcpcs is the CSI related FCP ? Anyway, if it's
> not needed it can be ignored for now.
> 
> 
> > DEF_MOD("hscif0",   514,R8A779G0_CLK_SASYNCPERD1),
> > DEF_MOD("hscif1",   515,R8A779G0_CLK_SASYNCPERD1),
> > DEF_MOD("hscif2",   516,R8A779G0_CLK_SASYNCPERD1),
> > @@ -193,6 +203,10 @@ static const struct mssr_mod_clk r8a779g0_mod_clks[] 
> > __initconst = {
> > DEF_MOD("tmu3", 716,R8A779G0_CLK_SASYNCPERD2),
> > DEF_MOD("tmu4", 717,R8A779G0_CLK_SASYNCPERD2),
> > DEF_MOD("tpu0", 718,R8A779G0_CLK_SASYNCPERD4),
> > +
> > +   DEF_MOD("vspd0",830,R8A779G0_CLK_S0D1_VIO),
> > +   DEF_MOD("vspd1",831,R8A779G0_CLK_S0D1_VIO),
> > +
> 
> Reviewed-by: Kieran Bingham 

I can't verify the MSTP clock parents, I assume they come from the BSP,
so

Reviewed-by: Laurent Pinchart 

> > DEF_MOD("wdt1:wdt0",907,R8A779G0_CLK_R),
> > DEF_MOD("cmt0", 910,R8A779G0_CLK_R),
> > DEF_MOD("cmt1", 911,R8A779G0_CLK_R),

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 2/8] dt-bindings: display: bridge: renesas,dsi-csi2-tx: Add r8a779g0

[Laurent Pinchart]

On Thu, Nov 17, 2022 at 04:14:21PM +0100, Geert Uytterhoeven wrote:
> On Thu, Nov 17, 2022 at 1:26 PM Tomi Valkeinen wrote:
> > From: Tomi Valkeinen 
> >
> > Extend the Renesas DSI display bindings to support the r8a779g0 V4H.
> >
> > Signed-off-by: Tomi Valkeinen 
> > ---
> >  .../bindings/display/bridge/renesas,dsi-csi2-tx.yaml   | 3 ++-
> >  1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git 
> > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml 
> > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
> > index afeeb967393d..bc3101f77e5a 100644
> > --- 
> > a/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
> > +++ 
> > b/Documentation/devicetree/bindings/display/bridge/renesas,dsi-csi2-tx.yaml
> > @@ -11,13 +11,14 @@ maintainers:
> >
> >  description: |
> >This binding describes the MIPI DSI/CSI-2 encoder embedded in the Renesas
> > -  R-Car V3U SoC. The encoder can operate in either DSI or CSI-2 mode, with 
> > up
> > +  R-Car V3U/V4H SoC. The encoder can operate in either DSI or CSI-2 mode, 
> > with up
> 
> Perhaps "R-Car Gen4 SoCs", so we stay within 80 chars, and don't have
> to update this when the next member of the family is around the block?

Sounds good.

> Is there anything that might be SoC-specific?
> If not, perhaps the time is ripe for a family-specific compatible value?

That's hard to tell, I have little visibility into what surprises other
SoCs will bring :-S

> >to four data lanes.
> >
> >  properties:
> >compatible:
> >  enum:
> >- renesas,r8a779a0-dsi-csi2-tx# for V3U
> > +  - renesas,r8a779g0-dsi-csi2-tx# for V4H

Reviewed-by: Laurent Pinchart 

> >
> >reg:
> >  maxItems: 1

-- 
Regards,

Laurent Pinchart

Re: [PATCH v1 1/8] dt-bindings: display: renesas,du: Provide bindings for r8a779g0

[Laurent Pinchart]

Hi Tomi,

Thank you for the patch.

On Thu, Nov 17, 2022 at 02:25:40PM +0200, Tomi Valkeinen wrote:
> From: Tomi Valkeinen 
> 
> Extend the Renesas DU display bindings to support the r8a779g0 V4H.
> 
> Signed-off-by: Tomi Valkeinen 

Reviewed-by: Laurent Pinchart 

> ---
>  Documentation/devicetree/bindings/display/renesas,du.yaml | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/Documentation/devicetree/bindings/display/renesas,du.yaml 
> b/Documentation/devicetree/bindings/display/renesas,du.yaml
> index b3e588022082..d4830f52c512 100644
> --- a/Documentation/devicetree/bindings/display/renesas,du.yaml
> +++ b/Documentation/devicetree/bindings/display/renesas,du.yaml
> @@ -40,6 +40,7 @@ properties:
>- renesas,du-r8a77990 # for R-Car E3 compatible DU
>- renesas,du-r8a77995 # for R-Car D3 compatible DU
>- renesas,du-r8a779a0 # for R-Car V3U compatible DU
> +  - renesas,du-r8a779g0 # for R-Car V4H compatible DU
>  
>reg:
>  maxItems: 1
> @@ -762,6 +763,7 @@ allOf:
>contains:
>  enum:
>- renesas,du-r8a779a0
> +  - renesas,du-r8a779g0
>  then:
>properties:
>  clocks:

-- 
Regards,

Laurent Pinchart

linux-next: manual merge of the amdgpu tree with the drm tree

[Stephen Rothwell]

Hi all,

Today's linux-next merge of the amdgpu tree got a conflict in:

  drivers/gpu/drm/amd/amdgpu/amdgpu_job.c

between commits:

  1b2d5eda5ad7 ("drm/amdgpu: move explicit sync check into the CS")
  1728baa7e4e6 ("drm/amdgpu: use scheduler dependencies for CS")

from the drm tree and commit:

  a61bf2f7299a ("drm/amdgpu: fix use-after-free during gpu recovery")

from the amdgpu tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
index ffaac1c21c91,f4a3122352de..
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.c
@@@ -173,8 -166,14 +173,13 @@@ static void amdgpu_job_free_cb(struct d
  
drm_sched_job_cleanup(s_job);
  
 -  amdgpu_sync_free(&job->sync);
 -  amdgpu_sync_free(&job->sched_sync);
 +  amdgpu_sync_free(&job->explicit_sync);
-   dma_fence_put(&job->hw_fence);
+ 
+   /* only put the hw fence if has embedded fence */
+   if (!job->hw_fence.ops)
+   kfree(job);
+   else
+   dma_fence_put(&job->hw_fence);
  }
  
  void amdgpu_job_set_gang_leader(struct amdgpu_job *job,


pgpEu47M69eOV.pgp
Description: OpenPGP digital signature

[GIT PULL FOR v6.2] RZ/G2L DSI Kconfig fix

[Laurent Pinchart]

Hi Dave, Daniel,

The following changes since commit 4e291f2f585313efa5200cce655e17c94906e50a:

  Merge tag 'drm-misc-next-2022-11-10-1' of 
git://anongit.freedesktop.org/drm/drm-misc into drm-next (2022-11-16 07:17:32 
+1000)

are available in the Git repository at:

  git://linuxtv.org/pinchartl/media.git tags/drm-next-20221122

for you to fetch changes up to ff6d979454ee21bf2d21040c8f2996b8f66726f2:

  drm: rcar-du: Fix Kconfig dependency between DRM and RZG2L_MIPI_DSI 
(2022-11-22 02:20:23 +0200)

This commit fixes a Kconfig issue that is in the drm-next branch for
v6.2.


Kconfig fix for RZ/G2L DSI


Biju Das (1):
  drm: rcar-du: Fix Kconfig dependency between DRM and RZG2L_MIPI_DSI

 drivers/gpu/drm/rcar-du/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH] drm: rcar-du: Fix Kconfig dependency between DRM and RZG2L_MIPI_DSI

[Laurent Pinchart]

Hi Biju,

Thank you for the patch.

On Mon, Nov 21, 2022 at 06:11:21PM +, Biju Das wrote:
> When CONFIG_DRM=m and CONFIG_DRM_RZG2L_MIPI_DSI=y, it results in a
> build failure. This patch fixes the build issue by adding dependency
> to DRM.
> 
> Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver")
> Reported-by: kernel test robot 
> Signed-off-by: Biju Das 

Reviewed-by: Laurent Pinchart 

> ---
> Ref:
>  * 
> https://lore.kernel.org/linux-renesas-soc/os0pr01mb592298e75153a52245d789d486...@os0pr01mb5922.jpnprd01.prod.outlook.com/T/#u
> ---
>  drivers/gpu/drm/rcar-du/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
> index 1065dca885ef..b2bddbeca878 100644
> --- a/drivers/gpu/drm/rcar-du/Kconfig
> +++ b/drivers/gpu/drm/rcar-du/Kconfig
> @@ -56,7 +56,7 @@ config DRM_RCAR_MIPI_DSI
>  
>  config DRM_RZG2L_MIPI_DSI
>   tristate "RZ/G2L MIPI DSI Encoder Support"
> - depends on DRM_BRIDGE && OF
> + depends on DRM && DRM_BRIDGE && OF
>   depends on ARCH_RENESAS || COMPILE_TEST
>   select DRM_MIPI_DSI
>   help

-- 
Regards,

Laurent Pinchart

Re: [PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

[Ceraolo Spurio, Daniele]

On 11/21/2022 3:16 PM, Daniele Ceraolo Spurio wrote:

If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.

We perform the FLR as the last action before releasing the MMIO bar, so
that we don't have to care about the consequences of the reset on the
unload flow.

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
---
  drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  9 +
  drivers/gpu/drm/i915/i915_reg.h   |  3 ++
  drivers/gpu/drm/i915/intel_uncore.c   | 45 +++
  drivers/gpu/drm/i915/intel_uncore.h   | 13 +++
  4 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 510fb47193ec..5dad3c19c445 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -173,6 +173,15 @@ int intel_gsc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
  
+	/*

+* Once the GSC FW is loaded, the only way to kill it on driver unload
+* is to do a driver FLR. Given this is a very disruptive action, we
+* want to do it as the last action before releasing the access to the
+* MMIO bar, which means we need to do it as part of the primary uncore
+* cleanup.
+*/
+   intel_uncore_set_flr_on_fini(>->i915->uncore);
+
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
  
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h

index 8e1892d14774..60e55245200b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
  
  #define GU_CNTL_MMIO(0x101010)

  #define   LMEM_INIT   REG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
  
  #define GEN6_STOLEN_RESERVED		_MMIO(0x1082C0)

  #define GEN6_STOLEN_RESERVED_ADDR_MASK(0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8006a6c61466..c1befa33ff59 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,48 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
  }
  
+static void driver_flr(struct intel_uncore *uncore)

+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+   int ret;
+
+   drm_dbg(&i915->drm, "Triggering Driver-FLR\n");
+
+   /*
+* Make sure any pending FLR requests have cleared by waiting for the
+* FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
+* to make sure it's not still set from a prior attempt (it's a write to
+* clear bit).
+* Note that we should never be in a situation where a previous attempt
+* is still pending (unless the HW is totally dead), but better to be
+* safe in case something unexpected happens
+*/
+   ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0, 
flr_timeout_ms);
+   if (ret) {
+   drm_err(&i915->drm,
+   "Failed to wait for Driver-FLR bit to clear! %d\n",
+   ret);
+   return;
+   }
+   intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
+
+   /* Trigger the actual Driver-FLR */
+   intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
+
+   ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
+DRIVERFLR_STATUS, DRIVERFLR_STATUS,
+flr_timeout_ms);
+   if (ret) {
+   drm_err(&i915->drm, "wait for Driver-FLR completion failed! 
%d\n", ret);
+   return;
+   }
+
+   intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
+
+   return;
+}
+
  /* Called via drm-managed action */
  void intel_uncore_fini_mmio(struct drm_device *dev, void *data)
  {
@@ -2716,6 +2758,9 @@ void intel_uncore_fini_mmio(struct drm_device *dev, void 
*data)
intel_uncore_fw_domains_fini(uncore);
iosf_mbi_punit_release();
}
+
+   if (intel_uncore_needs_flr_on_fini(uncore))
+   driver_flr(uncore);
  }
  
  /**

diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 5449146a0624

Re: [6.1][regression] after commit dd80d9c8eecac8c516da5b240d01a35660ba6cb6 some games (Cyberpunk 2077, Forza Horizon 4/5) hang at start

[Mikhail Gavrilov]

On Mon, Nov 14, 2022 at 6:22 PM Christian König
 wrote:
>
> I've found and fixed a few problems around the userptr handling which
> might explain what you see here.
>
> A series of four patches starting with "drm/amdgpu: always register an
> MMU notifier for userptr" is under review now.
>
> Going to give that a bit cleanup later today and will CC you when I send
> that out. Would be nice if you could give that some testing.
>
> Thanks,
> Christian.
>

Christian, I tested all four patches around week and can say that this
issue is completely gone.
All known broken games working.
Tested-by: Mikhail Gavrilov 

The only thing I don't like is the flood in the kernel logs of the
message "WARNING message at drivers/gpu/drm/drm_modeset_lock.c:276
drm_modeset_drop_locks+0x63/0x70", but this is not related to the
patches being checked.
All kernel logs uploaded to pastebin [1][2][3][4][5][6][7][8]

I wrote a separate bug report about "drm_modeset_lock" [9], it's a
pity that no one paid attention to it. I even found the first bad
commit. It is b261509952bc19d1012cf732f853659be6ebc61e.

[1] https://pastebin.com/WZWczupk
[2] https://pastebin.com/f4i9pvjS
[3] https://pastebin.com/rsDWaMR1
[4] https://pastebin.com/tDNEYJq0
[5] https://pastebin.com/xfZVbm1f
[6] https://pastebin.com/Vx9gDyKt
[7] https://pastebin.com/XvRkLckV
[8] https://pastebin.com/pd8WBkgx
[9] https://www.spinics.net/lists/dri-devel/msg367543.html

Thanks.

-- 
Best Regards,
Mike Gavrilov.

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Fix negative value passed as remaining time

[Janusz Krzysztofik]

Hi Andrzej,

Thanks for providing your R-b.

On Monday, 21 November 2022 18:40:51 CET Andrzej Hajda wrote:
> On 21.11.2022 15:56, Janusz Krzysztofik wrote:
> > Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
> > with GuC") extended the API of intel_gt_retire_requests_timeout() with an
> > extra argument 'remaining_timeout', intended for passing back unconsumed
> > portion of requested timeout when 0 (success) is returned.  However, when
> > request retirement happens to succeed despite an error returned by a call
> > to dma_fence_wait_timeout(), that error code (a negative value) is passed
> > back instead of remaining time.  If we then pass that negative value
> > forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
> > will be triggered.
> > 
> > If request retirement succeeds but an error code is passed back via
> > remaininig_timeout, we may have no clue on how much of the initial timeout
> > might have been left for spending it on waiting for GuC to become idle.
> > OTOH, since all pending requests have been successfully retired, that
> > error code has been already ignored by intel_gt_retire_requests_timeout(),
> > then we shouldn't fail.
> > 
> > Assume no more time has been left on error and pass 0 timeout value to
> > intel_uc_wait_for_idle() to give it a chance to return success if GuC is
> > already idle.
> > 
> > v3: Don't fail on any error passed back via remaining_timeout.
> > 
> > v2: Fix the issue on the caller side, not the provider.
> > 
> > Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work 
with GuC")
> > Signed-off-by: Janusz Krzysztofik 
> > Cc: sta...@vger.kernel.org # v5.15+
> 
> Reviewed-by: Andrzej Hajda 

While still open for comments from others, I'm now looking for potential 
committer.

Thanks,
Janusz


> 
> Regards
> Andrzej
> 
> > ---
> >   drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++--
> >   1 file changed, 7 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c b/drivers/gpu/drm/i915/gt/
intel_gt.c
> > index b5ad9caa55372..7ef0edb2e37cd 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> > @@ -677,8 +677,13 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
> > return -EINTR;
> > }
> >   
> > -   return timeout ? timeout : intel_uc_wait_for_idle(>->uc,
> > - 
remaining_timeout);
> > +   if (timeout)
> > +   return timeout;
> > +
> > +   if (remaining_timeout < 0)
> > +   remaining_timeout = 0;
> > +
> > +   return intel_uc_wait_for_idle(>->uc, remaining_timeout);
> >   }
> >   
> >   int intel_gt_init(struct intel_gt *gt)
> 
> 

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Hi Andrzej,

Thanks for providing your R-b, however, I'd still like to convince you that my 
approach, which you accepted anyway, is better justified than if we updated 0 
timeout with -ETIME immediately after returned by dma_fence_wait_timeout().

On Monday, 21 November 2022 13:12:00 CET Andrzej Hajda wrote:
> On 21.11.2022 11:59, Janusz Krzysztofik wrote:
> > On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:
> >> Hi Andrzej,
> >>
> >> Thanks for your comment.
> >>
> >> On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> >>>
> >>> On 21.11.2022 09:30, Janusz Krzysztofik wrote:
>  Hi Nimroy,
> 
>  Thanks for looking at this.
> 
>  On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> > On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> >> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> >> success.  However, we have no protection from passing back 0 
> >> potentially
> >> returned by a call to dma_fence_wait_timeout() when it succedes right
> >> after its timeout has expired.
> >>
> >> Replace 0 with -ETIME before potentially using the timeout value as 
> >> return
> >> code, so -ETIME is returned if there are still some requests not 
> >> retired
> >> after timeout, 0 otherwise.
> >>
> >> v2: Move the added lines down so flush_submission() is not affected.
> >>
> >> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
>  retire_request")
> >> Signed-off-by: Janusz Krzysztofik 
> >> Cc: sta...@vger.kernel.org # v5.5+
> >> ---
> >> drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> >> 1 file changed, 3 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
>  drm/i915/gt/intel_gt_requests.c
> >> index edb881d756309..3ac4603eeb4ee 100644
> >> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >> @@ -199,6 +199,9 @@ out_active:spin_lock(&timelines->lock);
> >>if (remaining_timeout)
> >>*remaining_timeout = timeout;
> >> 
> >> +  if (!timeout)
> >> +  timeout = -ETIME;
> > This will return error, -ETIME when 0 timeout is passed,
> > intel_gt_retire_requests().
>  Yes, but only when active_count is not 0 after we loop through
>  timelines->active_list calling retire_requests() on each and counting up
>  failures in active_count.
> >>>
> >>> Moving this line just after the call to dma_fence_wait_timeout should
> >>> solve the controversy.
> >>
> >> But that would break our need to pass 0, not -ETIME, to flush_submission() 
> >> in
> >> case the initial value of timeout was 0, as pointed out by Chris during our
> >> discussion on v2.
> >>
> >> Maybe an inline comment above the added lines that explains why we are 
> >> doing
> >> this could help?
> > 
> > How about not adding those two lines but modifying the return line instead?
> > 
> > -   return active_count ? timeout : 0;
> > +   return active_count ? timeout ?: -ETIME : 0;
> 
> Personally I would translate ret value from dma_fence* API ASAP, 

I think that would suggest we are trying to fix a problematic 0 response from 
dma_fence_wait_timeout() on success, while we already agreed with Chris' 
opinion that 0 is perfectl OK in that case, and returning 1 should be rather 
considered as problematic, since 0 just means success but no time left, and 
-ETIME means no success within timeout.  That's what had been implemented one 
time in our i915_request_wait_timeuout() backend, regardless of any breakage 
potentially introduced by later patches.

Then, fixing 0 return value from dma_fence_wait_timeout(), which is OK, is not 
what this patch is about.  The real problem is inconsistency between our 
declared API of i915_retire_reqiests_wait_timeout(), which promises to return 
0 on success, and that 0 remaining timeout value from dma_fence_wait_timeout() 
that we can potentially return when not all requests have been retired.  
That's what the patch is trying to fix, regardless of what that 0 timeout 
value can tell us about success or failure of a single call to 
dma_fence_wait_timeout(), not even speaking of a case when the function is 
called with timeout already equal 0.  Focused on success of retire_requests() 
rather than dma_fence_wait_timeout(), we generally ignore error codes from the 
latter, using them only for skipping next calls to that function, based on an 
assumption that no more time has been left.

Then, clearly fixing just our return value in the problematic case of 0 time 
left while not all requests have been retired seems the best option to me.

I've added your R-b to my v3 which implements just what you've accepted -- I 
hope you don't mind.

Thanks,
Janusz

> and 
> call flush_submission conditionally - to limit coexistence of both APIs.
> But 

[PATCH 6/6] drm/i915/mtl: MTL has one GSC CS on the media GT

[Daniele Ceraolo Spurio]

Now that we have the GSC FW support code as a user to the GSC CS, we
can add the relevant flag to the engine mask. Note that the engine will
still be disabled until we define the GSC FW binary file.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_pci.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 6da9784fe4a2..46acbf390195 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -1124,7 +1124,7 @@ static const struct intel_gt_definition xelpmp_extra_gt[] 
= {
.type = GT_MEDIA,
.name = "Standalone Media GT",
.gsi_offset = MTL_MEDIA_GSI_BASE,
-   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
+   .engine_mask = BIT(VECS0) | BIT(VCS0) | BIT(VCS2) | BIT(GSC0),
},
{}
 };
-- 
2.37.3

[PATCH 4/6] drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded

[Daniele Ceraolo Spurio]

If the GSC was loaded, the only way to stop it during the driver unload
flow is to do a driver-FLR.
The driver-FLR is not the same as PCI config space FLR in that
it doesn't reset the SGUnit and doesn't modify the PCI config
space. Thus, it doesn't require a re-enumeration of the PCI BARs.
However, the driver-FLR does cause a memory wipe of graphics memory
on all discrete GPU platforms or a wipe limited to stolen memory
on the integrated GPU platforms.

We perform the FLR as the last action before releasing the MMIO bar, so
that we don't have to care about the consequences of the reset on the
unload flow.

Signed-off-by: Daniele Ceraolo Spurio 
Signed-off-by: Alan Previn 
---
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c |  9 +
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++
 drivers/gpu/drm/i915/intel_uncore.c   | 45 +++
 drivers/gpu/drm/i915/intel_uncore.h   | 13 +++
 4 files changed, 70 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
index 510fb47193ec..5dad3c19c445 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
@@ -173,6 +173,15 @@ int intel_gsc_fw_upload(struct intel_gsc_uc *gsc)
if (err)
goto fail;
 
+   /*
+* Once the GSC FW is loaded, the only way to kill it on driver unload
+* is to do a driver FLR. Given this is a very disruptive action, we
+* want to do it as the last action before releasing the access to the
+* MMIO bar, which means we need to do it as part of the primary uncore
+* cleanup.
+*/
+   intel_uncore_set_flr_on_fini(>->i915->uncore);
+
/* FW is not fully operational until we enable SW proxy */
intel_uc_fw_change_status(gsc_fw, INTEL_UC_FIRMWARE_TRANSFERRED);
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8e1892d14774..60e55245200b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -118,6 +118,9 @@
 
 #define GU_CNTL_MMIO(0x101010)
 #define   LMEM_INITREG_BIT(7)
+#define   DRIVERFLRREG_BIT(31)
+#define GU_DEBUG   _MMIO(0x101018)
+#define   DRIVERFLR_STATUS REG_BIT(31)
 
 #define GEN6_STOLEN_RESERVED   _MMIO(0x1082C0)
 #define GEN6_STOLEN_RESERVED_ADDR_MASK (0xFFF << 20)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 8006a6c61466..c1befa33ff59 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2703,6 +2703,48 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
}
 }
 
+static void driver_flr(struct intel_uncore *uncore)
+{
+   struct drm_i915_private *i915 = uncore->i915;
+   const unsigned int flr_timeout_ms = 3000; /* specs recommend a 3s wait 
*/
+   int ret;
+
+   drm_dbg(&i915->drm, "Triggering Driver-FLR\n");
+
+   /*
+* Make sure any pending FLR requests have cleared by waiting for the
+* FLR trigger bit to go to zero. Also clear GU_DEBUG's DRIVERFLR_STATUS
+* to make sure it's not still set from a prior attempt (it's a write to
+* clear bit).
+* Note that we should never be in a situation where a previous attempt
+* is still pending (unless the HW is totally dead), but better to be
+* safe in case something unexpected happens
+*/
+   ret = intel_wait_for_register_fw(uncore, GU_CNTL, DRIVERFLR, 0, 
flr_timeout_ms);
+   if (ret) {
+   drm_err(&i915->drm,
+   "Failed to wait for Driver-FLR bit to clear! %d\n",
+   ret);
+   return;
+   }
+   intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
+
+   /* Trigger the actual Driver-FLR */
+   intel_uncore_rmw_fw(uncore, GU_CNTL, 0, DRIVERFLR);
+
+   ret = intel_wait_for_register_fw(uncore, GU_DEBUG,
+DRIVERFLR_STATUS, DRIVERFLR_STATUS,
+flr_timeout_ms);
+   if (ret) {
+   drm_err(&i915->drm, "wait for Driver-FLR completion failed! 
%d\n", ret);
+   return;
+   }
+
+   intel_uncore_write_fw(uncore, GU_DEBUG, DRIVERFLR_STATUS);
+
+   return;
+}
+
 /* Called via drm-managed action */
 void intel_uncore_fini_mmio(struct drm_device *dev, void *data)
 {
@@ -2716,6 +2758,9 @@ void intel_uncore_fini_mmio(struct drm_device *dev, void 
*data)
intel_uncore_fw_domains_fini(uncore);
iosf_mbi_punit_release();
}
+
+   if (intel_uncore_needs_flr_on_fini(uncore))
+   driver_flr(uncore);
 }
 
 /**
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index 5449146a0624..a9fa0b11e7e4 100644
--- a/drivers/gpu/drm/i915

[PATCH 3/6] drm/i915/gsc: GSC firmware loading

[Daniele Ceraolo Spurio]

GSC FW is loaded by submitting a dedicated command via the GSC engine.
The memory area used for loading the FW is then re-purposed as local
memory for the GSC itself, so we use a separate allocation instead of
using the one where we keep the firmware stored for reload.

The GSC is not reset as part of GT reset, so we only need to load it on
first boot and S3/S4 exit.

Note that the GSC load takes a lot of time (up to a few hundred ms).
This patch loads it serially as part of driver init/resume, but, given
that GSC is only required for PM and content-protection features
(media C6, PXP, HDCP), we could move the load to a worker thread to unblock
non-CP userspace submissions earlier. This will be done as a follow up
step, because there are extra init steps required to actually make use of
the GSC (including a mei component) and it will be cleaner (and easier to
review) if we implement the async load once all the pieces we need for GSC
to work are in place. A TODO has been added to the code to mark this
intention.

Bspec: 63347, 65346
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/Makefile|   1 +
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 186 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c|  35 +++-
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|   7 +
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  15 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   2 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  20 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   1 +
 13 files changed, 307 insertions(+), 7 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 92d37cf71e16..1d45a6f451fa 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -206,6 +206,7 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
  gt/uc/intel_huc_fw.o \
+ gt/uc/intel_gsc_fw.o \
  gt/uc/intel_gsc_uc.o
 
 # graphics system controller (GSC) support
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_pm.c 
b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
index 0d812f4d787d..f77eb4009aba 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_pm.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_pm.c
@@ -232,10 +232,22 @@ void i915_gem_resume(struct drm_i915_private *i915)
 * guarantee that the context image is complete. So let's just reset
 * it and start again.
 */
-   for_each_gt(gt, i915, i)
+   for_each_gt(gt, i915, i) {
if (intel_gt_resume(gt))
goto err_wedged;
 
+   /*
+* TODO: this is a long operation (up to ~200ms) and we don't
+* need to complete it before driver load/resume is done, so it
+* should be handled in a separate thread to unlock userspace
+* submission. However, there are a couple of other pieces that
+* are required for full GSC support that will complicate things
+* a bit, and it is easier to move everything to a worker at the
+* same time, so keep it here for now.
+*/
+   intel_uc_init_hw_late(>->uc);
+   }
+
ret = lmem_restore(i915, I915_TTM_BACKUP_ALLOW_GPU);
GEM_WARN_ON(ret);
 
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h 
b/drivers/gpu/drm/i915/gt/intel_engine.h
index cbc8b857d5f7..0e24af5efee9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -172,6 +172,8 @@ intel_write_status_page(struct intel_engine_cs *engine, int 
reg, u32 value)
 #define I915_GEM_HWS_MIGRATE   (0x42 * sizeof(u32))
 #define I915_GEM_HWS_PXP   0x60
 #define I915_GEM_HWS_PXP_ADDR  (I915_GEM_HWS_PXP * sizeof(u32))
+#define I915_GEM_HWS_GSC   0x62
+#define I915_GEM_HWS_GSC_ADDR  (I915_GEM_HWS_GSC * sizeof(u32))
 #define I915_GEM_HWS_SCRATCH   0x80
 
 #define I915_HWS_CSB_BUF0_INDEX0x10
diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h 
b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
index f50ea92910d9..49ebda141266 100644
--- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
+++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h
@@ -21,6 +21,7 @@
 #define INSTR_CLIENT_SHIFT  29
 #define   INSTR_MI_CLIENT   0x0
 #define   INSTR_BC_CLIENT   0x2
+#define   INSTR_GSC_CLIENT  0x2 /* MTL+ */
 #define   INSTR_RC_CLIENT   0x3
 #define INSTR_SUBCLIENT_SHIFT   27
 #define INSTR_S

[PATCH 5/6] drm/i915/gsc: Disable GSC engine and power well if FW is not selected

[Daniele Ceraolo Spurio]

From: Jonathan Cavitt 

The GSC CS is only used for communicating with the GSC FW, so no need to
initialize it if we're not going to use the FW. If we're not using
neither the engine nor the microcontoller, then we can also disable the
power well.

IMPORTANT: lack of GSC FW breaks media C6 due to opposing requirements
between CS setup and forcewake idleness. See in-code comment for detail.

Signed-off-by: Jonathan Cavitt 
Signed-off-by: Daniele Ceraolo Spurio 
Cc: Matt Roper 
Cc: John C Harrison 
Cc: Rodrigo Vivi 
Cc: Vinay Belgaumkar 
---
 drivers/gpu/drm/i915/gt/intel_engine_cs.c | 18 ++
 drivers/gpu/drm/i915/intel_uncore.c   |  3 +++
 2 files changed, 21 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c 
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index c33e0d72d670..99c4b866addd 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -894,6 +894,24 @@ static intel_engine_mask_t init_engine_mask(struct 
intel_gt *gt)
engine_mask_apply_compute_fuses(gt);
engine_mask_apply_copy_fuses(gt);
 
+   /*
+* The only use of the GSC CS is to load and communicate with the GSC
+* FW, so we have no use for it if we don't have the FW.
+*
+* IMPORTANT: in cases where we don't have the GSC FW, we have a
+* catch-22 situation that breaks media C6 due to 2 requirements:
+* 1) once turned on, the GSC power well will not go to sleep unless the
+*GSC FW is loaded.
+* 2) to enable idling (which is required for media C6) we need to
+*initialize the IDLE_MSG register for the GSC CS and do at least 1
+*submission, which will wake up the GSC power well.
+*/
+   if (__HAS_ENGINE(info->engine_mask, GSC0) && 
!intel_uc_wants_gsc_uc(>->uc)) {
+   drm_notice(>->i915->drm,
+  "No GSC FW selected, disabling GSC CS and media 
C6\n");
+   info->engine_mask &= ~BIT(GSC0);
+   }
+
return info->engine_mask;
 }
 
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index c1befa33ff59..e63d957b59eb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -2701,6 +2701,9 @@ void intel_uncore_prune_engine_fw_domains(struct 
intel_uncore *uncore,
if (fw_domains & BIT(domain_id))
fw_domain_fini(uncore, domain_id);
}
+
+   if ((fw_domains & BIT(FW_DOMAIN_ID_GSC)) && !HAS_ENGINE(gt, GSC0))
+   fw_domain_fini(uncore, FW_DOMAIN_ID_GSC);
 }
 
 static void driver_flr(struct intel_uncore *uncore)
-- 
2.37.3

[PATCH 2/6] drm/i915/gsc: Skip the version check when fetching the GSC FW

[Daniele Ceraolo Spurio]

The current exectation from the FW side is that the driver will query
the GSC FW version after the FW is loaded, similarly to what the mei
driver does on DG2. However, we're discussing with the FW team if there
is a way to extract the version from the bin file before loading, so we
can keep the code the same as for older FWs.

Since the GSC FW version is not currently required for functionality and
is only needed for debug purposes, we can skip the FW version for now at
fetch time and add it later on when we've agreed on the approach.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 29 +++-
 1 file changed, 23 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c 
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index 5b2e4503aee7..3df52fd59edc 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -564,6 +564,26 @@ static int check_ccs_header(struct intel_gt *gt,
return 0;
 }
 
+static int check_fw_header(struct intel_gt *gt,
+  const struct firmware *fw,
+  struct intel_uc_fw *uc_fw)
+{
+   int err = 0;
+
+   /* GSC FW version is queried after the FW is loaded */
+   if (uc_fw->type == INTEL_UC_FW_TYPE_GSC)
+   return 0;
+
+   if (uc_fw->loaded_via_gsc)
+   err = check_gsc_manifest(fw, uc_fw);
+   else
+   err = check_ccs_header(gt, fw, uc_fw);
+   if (err)
+   return err;
+
+   return 0;
+}
+
 /**
  * intel_uc_fw_fetch - fetch uC firmware
  * @uc_fw: uC firmware
@@ -633,14 +653,11 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
if (err)
goto fail;
 
-   if (uc_fw->loaded_via_gsc)
-   err = check_gsc_manifest(fw, uc_fw);
-   else
-   err = check_ccs_header(gt, fw, uc_fw);
+   err = check_fw_header(gt, fw, uc_fw);
if (err)
goto fail;
 
-   if (uc_fw->file_wanted.major_ver) {
+   if (uc_fw->file_wanted.major_ver && uc_fw->file_selected.major_ver) {
/* Check the file's major version was as it claimed */
if (uc_fw->file_selected.major_ver != 
uc_fw->file_wanted.major_ver) {
drm_notice(&i915->drm, "%s firmware %s: unexpected 
version: %u.%u != %u.%u\n",
@@ -657,7 +674,7 @@ int intel_uc_fw_fetch(struct intel_uc_fw *uc_fw)
}
}
 
-   if (old_ver) {
+   if (old_ver && uc_fw->file_selected.major_ver) {
/* Preserve the version that was really wanted */
memcpy(&uc_fw->file_wanted, &file_ideal, 
sizeof(uc_fw->file_wanted));
 
-- 
2.37.3

[PATCH 1/6] drm/i915/uc: Introduce GSC FW

[Daniele Ceraolo Spurio]

On MTL the GSC FW needs to be loaded on the media GT by the graphics
driver. We're going to treat it like a new uc_fw, so add the initial
defs and init/fini functions for it.

Similarly to the other FWs, the GSC FW path can be overriden via
modparam. The modparam can also be used to disable the GSC FW loading by
setting it to an empty string.

Note that the new structure has been called intel_gsc_uc to avoid
confusion with the existing intel_gsc, which instead represents the heci
gsc interfaces.

Signed-off-by: Daniele Ceraolo Spurio 
Cc: Alan Previn 
Cc: John Harrison 
---
 drivers/gpu/drm/i915/Makefile |  3 +-
 drivers/gpu/drm/i915/gt/intel_gt.h|  5 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c | 70 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h | 36 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c | 17 ++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h |  3 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  | 25 +++-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h  |  7 ++-
 drivers/gpu/drm/i915/i915_params.c|  3 +
 drivers/gpu/drm/i915/i915_params.h|  1 +
 10 files changed, 164 insertions(+), 6 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 01974b82d205..92d37cf71e16 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -205,7 +205,8 @@ i915-y += gt/uc/intel_uc.o \
  gt/uc/intel_guc_submission.o \
  gt/uc/intel_huc.o \
  gt/uc/intel_huc_debugfs.o \
- gt/uc/intel_huc_fw.o
+ gt/uc/intel_huc_fw.o \
+ gt/uc/intel_gsc_uc.o
 
 # graphics system controller (GSC) support
 i915-y += gt/intel_gsc.o
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h 
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e0365d556248..d2f4fbde5f9f 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -39,6 +39,11 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc 
*huc)
return container_of(huc, struct intel_gt, uc.huc);
 }
 
+static inline struct intel_gt *gsc_uc_to_gt(struct intel_gsc_uc *gsc_uc)
+{
+   return container_of(gsc_uc, struct intel_gt, uc.gsc);
+}
+
 static inline struct intel_gt *gsc_to_gt(struct intel_gsc *gsc)
 {
return container_of(gsc, struct intel_gt, gsc);
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
new file mode 100644
index ..65cbf1ce9fa1
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
@@ -0,0 +1,70 @@
+// SPDX-License-Identifier: MIT
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#include 
+
+#include "gt/intel_gt.h"
+#include "intel_gsc_uc.h"
+#include "i915_drv.h"
+
+static bool gsc_engine_supported(struct intel_gt *gt)
+{
+   intel_engine_mask_t mask;
+
+   /*
+* We reach here from i915_driver_early_probe for the primary GT before
+* its engine mask is set, so we use the device info engine mask for it.
+* For other GTs we expect the GT-specific mask to be set before we
+* call this function.
+*/
+   GEM_BUG_ON(!gt_is_root(gt) && !gt->info.engine_mask);
+
+   if (gt_is_root(gt))
+   mask = RUNTIME_INFO(gt->i915)->platform_engine_mask;
+   else
+   mask = gt->info.engine_mask;
+
+   return __HAS_ENGINE(mask, GSC0);
+}
+
+void intel_gsc_uc_init_early(struct intel_gsc_uc *gsc)
+{
+   intel_uc_fw_init_early(&gsc->fw, INTEL_UC_FW_TYPE_GSC);
+
+   /* we can arrive here from i915_driver_early_probe for primary
+* GT with it being not fully setup hence check device info's
+* engine mask
+*/
+   if (!gsc_engine_supported(gsc_uc_to_gt(gsc))){
+   intel_uc_fw_change_status(&gsc->fw, 
INTEL_UC_FIRMWARE_NOT_SUPPORTED);
+   return;
+   }
+}
+
+int intel_gsc_uc_init(struct intel_gsc_uc *gsc)
+{
+   struct drm_i915_private *i915 = gsc_uc_to_gt(gsc)->i915;
+   int err;
+
+   err = intel_uc_fw_init(&gsc->fw);
+   if (err)
+   goto out;
+
+   intel_uc_fw_change_status(&gsc->fw, INTEL_UC_FIRMWARE_LOADABLE);
+
+   return 0;
+
+out:
+   i915_probe_error(i915, "failed with %d\n", err);
+   return err;
+}
+
+void intel_gsc_uc_fini(struct intel_gsc_uc *gsc)
+{
+   if (!intel_uc_fw_is_loadable(&gsc->fw))
+   return;
+
+   intel_uc_fw_fini(&gsc->fw);
+}
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h 
b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
new file mode 100644
index ..ea2b1c0713b8
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h
@@ -0,0 +1,36 @@
+/* SPDX-License-Identifier: MIT */
+/*
+ * Copyright © 2022 Intel Corporation
+ */
+
+#ifndef _INTEL_GSC_UC_H_
+#define _INTEL_GSC_UC_H_
+
+#include "intel_uc_fw.h"
+
+struct intel_gsc_uc {
+   /* Generic

[PATCH 0/6] drm/i915: Add support for GSC FW loading

[Daniele Ceraolo Spurio]

Starting from MTL, the GSC FW is runtime loaded by the driver, instead
of being stored in flash memory. Loading the GSC FW is required to allow
the media GT to go into its C6 state and for content protection features
(PXP, HDCP).

The loading happens via a submission to the GSC engine. All subsequent
communication with the FW will also happen via the engine, although no
further messages are implemented as part of this series. The loading is
currently done serially as part of driver init/resume, but the plan is
to move it to a worker thread in the future to allow non-CP submission
to go through while we wait for GSC FW load to complete. This will be
done once all the pieces required for GSC to fully function are in place
(see further below).

This series also adds the GSC engine flag to the MTL platform, with the
engine being runtime disabled if the FW is not selected, which makes the
FW definition (not included in the series) the ultimate enabler for the
whole GSC block.

Note that just loading the FW is not enough for it to be fully
functional. We'll also need to establish and handle a communication
channel between GSC and CSME (a.k.a. SW proxy). This will require a new
mei component to handle the CSME side of things, so it will be pushed as
a separate series.

Cc: Alan Previn 
Cc: John Harrison 
Cc: Rodrigo Vivi 

Daniele Ceraolo Spurio (5):
  drm/i915/uc: Introduce GSC FW
  drm/i915/gsc: Skip the version check when fetching the GSC FW
  drm/i915/gsc: GSC firmware loading
  drm/i915/gsc: Do a driver-FLR on unload if GSC was loaded
  drm/i915/mtl: MTL has one GSC CS on the media GT

Jonathan Cavitt (1):
  drm/i915/gsc: Disable GSC engine and power well if FW is not selected

 drivers/gpu/drm/i915/Makefile|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_pm.c   |  14 +-
 drivers/gpu/drm/i915/gt/intel_engine.h   |   2 +
 drivers/gpu/drm/i915/gt/intel_engine_cs.c|  18 ++
 drivers/gpu/drm/i915/gt/intel_gpu_commands.h |   7 +
 drivers/gpu/drm/i915/gt/intel_gt.c   |  11 ++
 drivers/gpu/drm/i915/gt/intel_gt.h   |   5 +
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c| 195 +++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h|  13 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c| 103 ++
 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h|  43 
 drivers/gpu/drm/i915/gt/uc/intel_uc.c|  32 +++
 drivers/gpu/drm/i915/gt/uc/intel_uc.h|   5 +
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c |  74 +--
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.h |   8 +-
 drivers/gpu/drm/i915/i915_params.c   |   3 +
 drivers/gpu/drm/i915/i915_params.h   |   1 +
 drivers/gpu/drm/i915/i915_pci.c  |   2 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_uncore.c  |  48 +
 drivers/gpu/drm/i915/intel_uncore.h  |  13 ++
 21 files changed, 585 insertions(+), 19 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_fw.h
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.c
 create mode 100644 drivers/gpu/drm/i915/gt/uc/intel_gsc_uc.h

-- 
2.37.3

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Sonal Santan]

On 11/19/22 12:44, Oded Gabbay wrote:
> This is the fourth (and hopefully last) version of the patch-set to add the
> new subsystem for compute accelerators. I removed the RFC headline as
> I believe it is now ready for merging.
> 
> Compare to v3, this patch-set contains one additional patch that adds
> documentation regarding the accel subsystem. I hope it's good enough for
> this stage. In addition, there were few very minor fixes according to
> comments received on v3.
> 
> The patches are in the following repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> 
> As in v3, The HEAD of that branch is a commit adding a dummy driver that
> registers an accel device using the new framework. This can be served
> as a simple reference.
> 
> v1 cover letter:
> https://lkml.org/lkml/2022/10/22/544
> 
> v2 cover letter:
> https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
> 
> v3 cover letter:
> https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/

Thanks for defining the new accel subsystem. We are currently working on
DRM based drivers for unannounced acceleration devices. I am fine with
these changes with the assumption that the choice of using classic DRM
or accel is left up to the individual driver.

-Sonal

> 
> Thanks,
> Oded.
> 
> Oded Gabbay (4):
>   drivers/accel: define kconfig and register a new major
>   accel: add dedicated minor for accelerator devices
>   drm: initialize accel framework
>   doc: add documentation for accel subsystem
> 
>  Documentation/accel/index.rst |  17 ++
>  Documentation/accel/introduction.rst  | 109 +
>  Documentation/admin-guide/devices.txt |   5 +
>  Documentation/subsystem-apis.rst  |   1 +
>  MAINTAINERS   |   9 +
>  drivers/Kconfig   |   2 +
>  drivers/accel/Kconfig |  24 ++
>  drivers/accel/drm_accel.c | 323 ++
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_drv.c | 102 +---
>  drivers/gpu/drm/drm_file.c|   2 +-
>  drivers/gpu/drm/drm_sysfs.c   |  24 +-
>  include/drm/drm_accel.h   |  97 
>  include/drm/drm_device.h  |   3 +
>  include/drm/drm_drv.h |   8 +
>  include/drm/drm_file.h|  21 +-
>  16 files changed, 711 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/accel/index.rst
>  create mode 100644 Documentation/accel/introduction.rst
>  create mode 100644 drivers/accel/Kconfig
>  create mode 100644 drivers/accel/drm_accel.c
>  create mode 100644 include/drm/drm_accel.h
> 
> --
> 2.25.1
> 

[PATCH] drm/mediatek: Clean dangling pointer on bind error path

[Nícolas F . R . A . Prado]

mtk_drm_bind() can fail, in which case drm_dev_put() is called,
destroying the drm_device object. However a pointer to it was still
being held in the private object, and that pointer would be passed along
to DRM in mtk_drm_sys_prepare() if a suspend were triggered at that
point, resulting in a panic. Clean the pointer when destroying the
object in the error path to prevent this from happening.

Signed-off-by: Nícolas F. R. A. Prado 

---

 drivers/gpu/drm/mediatek/mtk_drm_drv.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c 
b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
index 39a42dc8fb85..a21ff1b3258c 100644
--- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
+++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
@@ -514,6 +514,7 @@ static int mtk_drm_bind(struct device *dev)
 err_deinit:
mtk_drm_kms_deinit(drm);
 err_free:
+   private->drm = NULL;
drm_dev_put(drm);
return ret;
 }
-- 
2.38.1

[PATCH] drm/msm/dpu: Print interrupt index in addition to the mask

[Marijn Suijten]

The mask only describes the `irq_idx % 32` part, making it generally
impossible to deduce what interrupt is being enabled/disabled.  Since
`debug/core_irq` in debugfs (and other prints) also include the full
`DPU_IRQ_IDX()` value, print the same full value here for easier
correlation instead of only adding the `irq_idx / 32` part.

Furthermore, make the dbgstr messages more consistent.

Signed-off-by: Marijn Suijten 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
index cf1b6d84c18a..64589a9c2c51 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_interrupts.c
@@ -252,9 +252,9 @@ static int dpu_hw_intr_enable_irq_locked(struct dpu_hw_intr 
*intr, int irq_idx)
 
cache_irq_mask = intr->cache_irq_mask[reg_idx];
if (cache_irq_mask & DPU_IRQ_MASK(irq_idx)) {
-   dbgstr = "DPU IRQ already set:";
+   dbgstr = "already ";
} else {
-   dbgstr = "DPU IRQ enabled:";
+   dbgstr = "";
 
cache_irq_mask |= DPU_IRQ_MASK(irq_idx);
/* Cleaning any pending interrupt */
@@ -268,7 +268,7 @@ static int dpu_hw_intr_enable_irq_locked(struct dpu_hw_intr 
*intr, int irq_idx)
intr->cache_irq_mask[reg_idx] = cache_irq_mask;
}
 
-   pr_debug("%s MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", dbgstr,
+   pr_debug("DPU IRQ %d %senabled: MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", 
irq_idx, dbgstr,
DPU_IRQ_MASK(irq_idx), cache_irq_mask);
 
return 0;
@@ -301,9 +301,9 @@ static int dpu_hw_intr_disable_irq_locked(struct 
dpu_hw_intr *intr, int irq_idx)
 
cache_irq_mask = intr->cache_irq_mask[reg_idx];
if ((cache_irq_mask & DPU_IRQ_MASK(irq_idx)) == 0) {
-   dbgstr = "DPU IRQ is already cleared:";
+   dbgstr = "already ";
} else {
-   dbgstr = "DPU IRQ mask disable:";
+   dbgstr = "";
 
cache_irq_mask &= ~DPU_IRQ_MASK(irq_idx);
/* Disable interrupts based on the new mask */
@@ -317,7 +317,7 @@ static int dpu_hw_intr_disable_irq_locked(struct 
dpu_hw_intr *intr, int irq_idx)
intr->cache_irq_mask[reg_idx] = cache_irq_mask;
}
 
-   pr_debug("%s MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", dbgstr,
+   pr_debug("DPU IRQ %d %sdisabled: MASK:0x%.8lx, CACHE-MASK:0x%.8x\n", 
irq_idx, dbgstr,
DPU_IRQ_MASK(irq_idx), cache_irq_mask);
 
return 0;
-- 
2.38.1

[linux-next:master] BUILD REGRESSION e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9

[kernel test robot]

tree/branch: 
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: e4cd8d3ff7f9efeb97330e5e9b99eeb2a68f5cf9  Add linux-next specific 
files for 20221121

Error/Warning reports:

https://lore.kernel.org/oe-kbuild-all/202211130053.np70vidn-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211191949.jqnwetuw-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211200417.23auopyc-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211211917.ylicunmb-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211212249.livtpi3y-...@intel.com
https://lore.kernel.org/oe-kbuild-all/202211220547.7jd7qbi7-...@intel.com

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

arch/arm/mach-s3c/devs.c:32:10: fatal error: linux/platform_data/dma-s3c24xx.h: 
No such file or directory
drivers/clk/clk.c:1022:5: error: redefinition of 'clk_prepare'
drivers/clk/clk.c:1268:6: error: redefinition of 'clk_is_enabled_when_prepared'
drivers/clk/clk.c:941:6: error: redefinition of 'clk_unprepare'
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc.c:4939: warning: This comment 
starts with '/**', but isn't a kernel-doc comment. Refer 
Documentation/doc-guide/kernel-doc.rst
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:5075:24: warning: 
implicit conversion from 'enum ' to 'enum dc_status' 
[-Wenum-conversion]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:139:43:
 warning: unused variable 'dmub_outbox_irq_info_funcs' [-Wunused-const-variable]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: 
warning: no previous prototype for 'to_dal_irq_source_dcn201' 
[-Wmissing-prototypes]
drivers/gpu/drm/amd/amdgpu/../display/dc/irq/dcn201/irq_service_dcn201.c:40:20: 
warning: no previous prototype for function 'to_dal_irq_source_dcn201' 
[-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous 
prototype for 'gf100_fifo_nonstall_block' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/gf100.c:451:1: warning: no previous 
prototype for function 'gf100_fifo_nonstall_block' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous 
prototype for 'nvkm_engn_cgrp_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/fifo/runl.c:34:1: warning: no previous 
prototype for function 'nvkm_engn_cgrp_get' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous 
prototype for 'tu102_gr_load' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/engine/gr/tu102.c:210:1: warning: no previous 
prototype for function 'tu102_gr_load' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype 
for 'wpr_generic_header_dump' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/nvfw/acr.c:49:1: warning: no previous prototype 
for function 'wpr_generic_header_dump' [-Wmissing-prototypes]
drivers/gpu/drm/nouveau/nvkm/subdev/acr/lsfw.c:221:21: warning: variable 'loc' 
set but not used [-Wunused-but-set-variable]
include/linux/ftrace.h:126:16: error: implicit declaration of function 
'arch_ftrace_get_regs'; did you mean 'ftrace_get_regs'? 
[-Werror=implicit-function-declaration]
include/linux/ftrace.h:126:16: warning: returning 'int' from a function with 
return type 'struct pt_regs *' makes pointer from integer without a cast 
[-Wint-conversion]
microblaze-linux-ld: (.text+0x158): undefined reference to `drm_bridge_add'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3b4): 
undefined reference to `drm_atomic_helper_bridge_duplicate_state'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3b8): 
undefined reference to `drm_atomic_helper_bridge_destroy_state'
microblaze-linux-ld: drivers/gpu/drm/rcar-du/rzg2l_mipi_dsi.o:(.rodata+0x3c8): 
undefined reference to `drm_atomic_helper_bridge_reset'

Unverified Error/Warning (likely false positive, please contact us if 
interested):

drivers/gpu/drm/nouveau/nouveau_dp.c:237 nouveau_dp_irq() warn: variable 
dereferenced before check 'outp' (see line 232)
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c:116 
nvkm_uoutp_mthd_infoframe() error: we previously assumed 'ior->func->hdmi' 
could be null (see line 114)
drivers/gpu/drm/nouveau/nvkm/engine/disp/uoutp.c:250 nvkm_uoutp_mthd_acquire() 
error: we previously assumed 'outp->ior' could be null (see line 217)
drivers/gpu/drm/nouveau/nvkm/engine/fifo/chan.c:133 nvkm_chan_cctx_get() warn: 
inconsistent returns '&cgrp->mutex'.
drivers/gpu/drm/nouveau/nvkm/engine/gr/gf100.c:480 gf100_gr_chan_new() warn: 
inconsistent returns '&gr

Re: [PATCH] drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"

[Luben Tuikov]

Acked-by: Luben Tuikov 

Regards,
Luben

On 2022-11-21 12:38, Alex Deucher wrote:
> This partially reverts 20543be93ca45968f344261c1a997177e51bd7e1.
> 
> Calling drm_connector_update_edid_property() in
> amdgpu_connector_free_edid() causes a noticable pause in
> the system every 10 seconds on polled outputs so revert this
> part of the change.
> 
> Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2257
> Cc: Claudio Suarez 
> Signed-off-by: Alex Deucher 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> index 491d4846fc02..cfb262911bfc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
> @@ -328,7 +328,6 @@ static void amdgpu_connector_free_edid(struct 
> drm_connector *connector)
>  
>   kfree(amdgpu_connector->edid);
>   amdgpu_connector->edid = NULL;
> - drm_connector_update_edid_property(connector, NULL);
>  }
>  
>  static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)

Re: [PATCH v3 2/6] dt-bindings: Use new video interface bus type macros in examples

[Sakari Ailus]

Hi Laurent,

On Sat, Jul 16, 2022 at 06:12:05PM +0300, Laurent Pinchart wrote:
> Hi Sakari,
> 
> On Sat, Jul 16, 2022 at 12:28:45PM +0300, Sakari Ailus wrote:
> > On Thu, Jun 16, 2022 at 01:14:06AM +0300, Laurent Pinchart wrote:
> > > Now that a header exists with macros for the media interface bus-type
> > > values, replace hardcoding numerical constants with the corresponding
> > > macros in the DT binding examples.
> > > 
> > > Signed-off-by: Laurent Pinchart 
> > > ---
> > > Changes since v2:
> > > 
> > > - Go back to PARALLEL
> > > 
> > > Changes since v1:
> > > 
> > > - Rename PARALLEL to BT601
> > > ---
> > >  .../devicetree/bindings/display/bridge/analogix,anx7625.yaml  | 1 +
> > >  Documentation/devicetree/bindings/media/i2c/mipi-ccs.yaml | 3 ++-
> > >  Documentation/devicetree/bindings/media/i2c/ovti,ov772x.yaml  | 3 ++-
> > >  .../devicetree/bindings/media/marvell,mmp2-ccic.yaml  | 3 ++-
> > >  Documentation/devicetree/bindings/media/microchip,xisc.yaml   | 3 ++-
> > >  Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml| 4 +++-
> > >  6 files changed, 12 insertions(+), 5 deletions(-)
> > > 
> > > diff --git 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > index 35a48515836e..b0e5585f93e2 100644
> > > --- 
> > > a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > +++ 
> > > b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
> > > @@ -118,6 +118,7 @@ additionalProperties: false
> > >  examples:
> > >- |
> > >  #include 
> > > +#include 
> > >  
> > >  i2c0 {
> > >  #address-cells = <1>;
> > 
> > The definition doesn't seem to be used here. Is there a need to include
> > this?
> 
> There was, but the change that added bus-type to this binding got
> reverted in commit 979452fbc430 ("dt-bindings: drm/bridge: anx7625:
> Revert DPI support") and I forgot to drop the header when rebasing.
> 
> > I could drop this chunk while applying. There's just one trivial change
> > elsewhere in this patch to make.
> 
> Please do :-)

Applied with the following diff:

diff --git 
a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml 
b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
index 7fa7a667c764a..4590186c4a0b8 100644
--- a/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
+++ b/Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml
@@ -133,7 +133,6 @@ additionalProperties: false
 examples:
   - |
 #include 
-#include 
 
 i2c0 {
 #address-cells = <1>;
diff --git a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml 
b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
index 285c6075950ad..e80fcdf280f0b 100644
--- a/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
+++ b/Documentation/devicetree/bindings/media/st,stm32-dcmi.yaml
@@ -92,7 +92,7 @@ examples:
 #include 
 #include 
 #include 
-#
+
 dcmi: dcmi@4c006000 {
 compatible = "st,stm32-dcmi";
 reg = <0x4c006000 0x400>;

It seems that there's also bus-type 7 that corresponds to MIPI DPI. Could
you add a macro for this one as well? :-) In particular it's used by
Documentation/devicetree/bindings/display/bridge/analogix,anx7625.yaml .

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v10 18/19] drm/vc4: vec: Add support for more analog TV standards

[Mateusz Kwiatkowski]

Hi Mauro,

As the author of the original version of this commit, and also a person who
argued quite a bit on these descriptions and decisions, let me chip in a bit.

W dniu 17.11.2022 o 16:49, Mauro Carvalho Chehab pisze:
> On Thu, 17 Nov 2022 10:29:01 +0100
> Maxime Ripard  wrote:
>
>> From: Mateusz Kwiatkowski 
>>
>> Add support for the following composite output modes (all of them are
>> somewhat more obscure than the previously defined ones):
>>
>> - NTSC_443 - NTSC-style signal with the chroma subcarrier shifted to
>>   4.43361875 MHz (the PAL subcarrier frequency). Never used for
>>   broadcasting, but sometimes used as a hack to play NTSC content in PAL
>>   regions (e.g. on VCRs).
>
>> - PAL_N - PAL with alternative chroma subcarrier frequency,
>>   3.58205625 MHz. Used as a broadcast standard in Argentina, Paraguay
>>   and Uruguay to fit 576i50 with colour in 6 MHz channel raster.
>
> That's not right. Argentina uses a different standard than Paraguay and
> Uruguai.
>
> See, there are two variants of PAL/N. The original one and PAL/N' - also
> called PAL/NC or PAL/CN (Combination N). Some of the timings are 
> different on /NC variant.
>
> As far as I'm aware, PAL/Nc is used in Argentina, while
> PAL/N is used in Paraguai and Uruguai, but I may be wrong on that,
> as it has been a long time since had to touch on this.

If you say so - maybe that's true. But I tried to find any differences between
PAL-N and PAL-Nc many times and haven't found anything concrete. The only
authoritative source where System N and "Combination N/PAL" seem to be mentioned
as separate entities is BT.1701
. However:

a) the differences are very subtle (with "combination N/PAL" being just a tad
   stricter than what's mentioned for System N)
b) "Combination N/PAL" can be understood as just "System N combined with PAL
   color", as opposed to "raw", black&white System N. This intepretation is also
   what the user calling themselves "Alcahemist" suggests here:
   https://en.wikipedia.org/wiki/Talk:PAL#PAL-N_versus_PAL-Nc

This is of course far from an authoritative source. If you have a definitive
source for PAL-N and PAL-Nc being different, or concrete information on what is
different between them specifically, then so be it. But I tried and haven't
found anything conclusive.

>> - PAL60 - 480i60 signal with PAL-style color at normal European PAL
>>   frequency. Another non-standard, non-broadcast mode, used in similar
>>   contexts as NTSC_443. Some displays support one but not the other.
>
>> - SECAM - French frequency-modulated analog color standard; also have
>>   been broadcast in Eastern Europe and various parts of Africa and Asia.
>>   Uses the same 576i50 timings as PAL.
>
> This is also wrong. just like PAL, there are several variants of SECAM,
> one used in France, and a different one in France overseas and on
> previous France colonies in Africa and Asia. Eastern Europe also used
> different variants of SECAM.

This is true. However, those differed only in RF modulation. For example,
French SECAM-L used positive video modulation and AM sound, while Eastern
European SECAM-D/K used negative video modulation and FM sound. But the
baseband composite signals were identical.

There were several other variants of SECAM, like early SECAM/V vs. SECAM/H
("Field identification" vs. "Line identification") which moved the color
identification signals from VBI to HBI. But that's a change that all SECAM
regions, including both France and Eastern Europe did in the 1980s to
acommodate for teletext. Again, authoritative sources are scarce, but see e.g.
https://web.archive.org/web/20160303232903/http://www.pembers.freeserve.co.uk/World-TV-Standards/Colour-Standards.html
(search for "Synchronisation of SECAM colour transmissions" on the page).

There's also MESECAM, but that only applies to encoding on VHS and Betamax
tapes, not the signals themselves. There was also SECAM-M for 525-line (480i)
signals, but I haven't found any conclusive evidence that it was ever used for
broadcast anywhere

So yeah, SECAM can be a bit confusing, but AFAIK there's only one standard if
we're talking about the composite video layer.

--

Some *really* old (like, 1960s old) versions of CCIR documents also listed more
substantial differences between various 625-line systems, including the number
of active lines varying from 571 to 589. But all revisions from 1974 onward list
the modern value of 575 active lines for all the variants, making them differ
only in RF modulation details. Which is beyond the scope of what the "TV mode"
property is supposed to do.

>> Also added some comments explaining color subcarrier frequency
>> registers.
>>
>> Acked-by: Noralf Trønnes 
>> Signed-off-by: Mateusz Kwiatkowski 
>> Tested-by: Mateusz Kwiatkowski 
>> Signed-off-by: Maxime Ripard 
>>
>> ---
>> Changes in v6:
>> - Support PAL60 again
>> ---
>>  drivers/gpu/drm/vc4/vc4_vec.c | 111 
>> ++

Re: [PATCH v13,2/3] drm: mediatek: Set dpi format in mmsys

[Matthias Brugger]

On 24/10/2022 04:04, xinlei@mediatek.com wrote:

From: Xinlei Lee 

Dpi output needs to adjust the output format to dual edge for MT8186.

Co-developed-by: Jitao Shi 
Signed-off-by: Jitao Shi 
Signed-off-by: Xinlei Lee 
Reviewed-by: CK Hu 
Reviewed-by: AngeloGioacchino Del Regno 

Reviewed-by: Nícolas F. R. A. Prado 


I realized that I took this patch by error. I'll drop it from my tree now.

Regards,
Matthias


---
  drivers/gpu/drm/mediatek/mtk_dpi.c | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/mediatek/mtk_dpi.c 
b/drivers/gpu/drm/mediatek/mtk_dpi.c
index 630a4e301ef6..ad87ecddf58d 100644
--- a/drivers/gpu/drm/mediatek/mtk_dpi.c
+++ b/drivers/gpu/drm/mediatek/mtk_dpi.c
@@ -15,6 +15,7 @@
  #include 
  #include 
  #include 
+#include 
  #include 
  
  #include 

@@ -30,6 +31,7 @@
  #include "mtk_disp_drv.h"
  #include "mtk_dpi_regs.h"
  #include "mtk_drm_ddp_comp.h"
+#include "mtk_drm_drv.h"
  
  enum mtk_dpi_out_bit_num {

MTK_DPI_OUT_BIT_NUM_8BITS,
@@ -67,6 +69,7 @@ struct mtk_dpi {
struct drm_connector *connector;
void __iomem *regs;
struct device *dev;
+   struct device *mmsys_dev;
struct clk *engine_clk;
struct clk *pixel_clk;
struct clk *tvd_clk;
@@ -135,6 +138,7 @@ struct mtk_dpi_yc_limit {
   * @yuv422_en_bit: Enable bit of yuv422.
   * @csc_enable_bit: Enable bit of CSC.
   * @pixels_per_iter: Quantity of transferred pixels per iteration.
+ * @edge_cfg_in_mmsys: If the edge configuration for DPI's output needs to be 
set in MMSYS.
   */
  struct mtk_dpi_conf {
unsigned int (*cal_factor)(int clock);
@@ -153,6 +157,7 @@ struct mtk_dpi_conf {
u32 yuv422_en_bit;
u32 csc_enable_bit;
u32 pixels_per_iter;
+   bool edge_cfg_in_mmsys;
  };
  
  static void mtk_dpi_mask(struct mtk_dpi *dpi, u32 offset, u32 val, u32 mask)

@@ -449,8 +454,12 @@ static void mtk_dpi_dual_edge(struct mtk_dpi *dpi)
mtk_dpi_mask(dpi, DPI_OUTPUT_SETTING,
 dpi->output_fmt == MEDIA_BUS_FMT_RGB888_2X12_LE ?
 EDGE_SEL : 0, EDGE_SEL);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_DDR_CON);
} else {
mtk_dpi_mask(dpi, DPI_DDR_SETTING, DDR_EN | DDR_4PHASE, 0);
+   if (dpi->conf->edge_cfg_in_mmsys)
+   mtk_mmsys_ddp_dpi_fmt_config(dpi->mmsys_dev, 
MTK_DPI_RGB888_SDR_CON);
}
  }
  
@@ -778,8 +787,10 @@ static int mtk_dpi_bind(struct device *dev, struct device *master, void *data)

  {
struct mtk_dpi *dpi = dev_get_drvdata(dev);
struct drm_device *drm_dev = data;
+   struct mtk_drm_private *priv = drm_dev->dev_private;
int ret;
  
+	dpi->mmsys_dev = priv->mmsys_dev;

ret = drm_simple_encoder_init(drm_dev, &dpi->encoder,
  DRM_MODE_ENCODER_TMDS);
if (ret) {

Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()

[Christian König]

Hi Dawei,

from the technical description, coding style etc.. it looks clean to me, 
but I'm the completely wrong person to ask for a background check.


I have a high level understanding of how dma-heaps work, but not a 
single line of this code is from me.


Feel free to add my Acked-by, but Laura, John and others do you have any 
opinion?


Regards,
Christian.

Am 21.11.22 um 16:28 schrieb Dawei Li:

On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:

Hi Christian,
May I have your opinion on this change?

Thanks,
Dawei


Racing conflict could be:
task A task B
list_for_each_entry
strcmp(h->name))
list_for_each_entry
strcmp(h->name)
kzallockzalloc
.. .
device_create  device_create
list_add
list_add

The root cause is that task B has no idea about the fact someone
else(A) has inserted heap with same name when it calls list_add,
so a potential collision occurs.

Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
Signed-off-by: Dawei Li 
---
v1: 
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fall%2FTYCP286MB2323950197F60FC3473123B7CA349%40TYCP286MB2323.JPNP286.PROD.OUTLOOK.COM%2F&data=05%7C01%7Cchristian.koenig%40amd.com%7C1989f31257fc458a27c508dacbd5078e%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C638046413707443203%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=OWPUPrIHGnzwXyQE4WlIthThwSuSK2y3Eq2Wq5zAzbo%3D&reserved=0
v1->v2: Narrow down locking scope, check the existence of heap before
insertion, as suggested by Andrew Davis.
v2->v3: Remove double checking.
v3->v4: Minor coding style and patch formatting adjustment.
---
  drivers/dma-buf/dma-heap.c | 28 +++-
  1 file changed, 15 insertions(+), 13 deletions(-)

diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
index 8f5848aa144f..59d158873f4c 100644
--- a/drivers/dma-buf/dma-heap.c
+++ b/drivers/dma-buf/dma-heap.c
@@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
return ERR_PTR(-EINVAL);
}
  
-	/* check the name is unique */

-   mutex_lock(&heap_list_lock);
-   list_for_each_entry(h, &heap_list, list) {
-   if (!strcmp(h->name, exp_info->name)) {
-   mutex_unlock(&heap_list_lock);
-   pr_err("dma_heap: Already registered heap named %s\n",
-  exp_info->name);
-   return ERR_PTR(-EINVAL);
-   }
-   }
-   mutex_unlock(&heap_list_lock);
-
heap = kzalloc(sizeof(*heap), GFP_KERNEL);
if (!heap)
return ERR_PTR(-ENOMEM);
@@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct 
dma_heap_export_info *exp_info)
err_ret = ERR_CAST(dev_ret);
goto err2;
}
-   /* Add heap to the list */
+
mutex_lock(&heap_list_lock);
+   /* check the name is unique */
+   list_for_each_entry(h, &heap_list, list) {
+   if (!strcmp(h->name, exp_info->name)) {
+   mutex_unlock(&heap_list_lock);
+   pr_err("dma_heap: Already registered heap named %s\n",
+  exp_info->name);
+   err_ret = ERR_PTR(-EINVAL);
+   goto err3;
+   }
+   }
+
+   /* Add heap to the list */
list_add(&heap->list, &heap_list);
mutex_unlock(&heap_list_lock);
  
  	return heap;
  
+err3:

+   device_destroy(dma_heap_class, heap->heap_devt);
  err2:
cdev_del(&heap->heap_cdev);
  err1:
--
2.25.1

Re: [Intel-gfx] [PATCH v2 0/5] Add module oriented dmesg output

[John Harrison]

On 11/18/2022 02:52, Jani Nikula wrote:

On Thu, 17 Nov 2022, john.c.harri...@intel.com wrote:

From: John Harrison 

When trying to analyse bug reports from CI, customers, etc. it can be
difficult to work out exactly what is happening on which GT in a
multi-GT system. So add GT oriented debug/error message wrappers. If
used instead of the drm_ equivalents, you get the same output but with
a GT# prefix on it.

It was also requested to extend this further to submodules in order to
factor out the repeated structure accessing constructs and common
string prefixes. So, add versions for GuC, HuC and GuC CTB as well.

This patch set updates all the gt/uc files to use the new helpers as a
first step. The intention would be to convert all output messages that
have access to a GT structure.

v2: Go back to using lower case names, add more wrapper sets (combined
review feedback). Also, wrap up probe injection and WARN entries.

Signed-off-by: John Harrison 

For adding the wrappers in general, I'm going to disagree and
commit. I'll leave it up to Tvrtko and Joonas.

Regarding the placement of the macros, I insist you add individual
header files for the wrappers and include them only where needed.

We have a fairly serious problem with everything including everything in
i915 that I've been slowly trying to tackle. Touch one thing, rebuild
everything. About a third of our headers cause the rebuild of the entire
driver when modified. We need to reduce the surface of things that cause
rebuilds.

For example, intel_gt.h is included by 97 files, intel_guc.h by 332
files, and intel_huc.h by 329 files (counting recursively).

There's absolutely no reason any of the display code, for example, needs
to have these logging macros in their build. Long term, the headers
should be reorganized to reduce the interdependencies, and this is what
I've been doing in i915_drv.h and display/ in general. But the least we
can do is not make the problem worse.
@Tvrtko/@Michal W, any other review comments or feedback? I'd rather not 
spend time fixing up the header file issue and reposting only to have 
someone point out another issue that could have been resolved at the 
same time.


John.


BR,
Jani.



John Harrison (5):
   drm/i915/gt: Start adding module oriented dmesg output
   drm/i915/huc: Add HuC specific debug print wrappers
   drm/i915/guc: Add GuC specific debug print wrappers
   drm/i915/guc: Add GuC CT specific debug print wrappers
   drm/i915/uc: Update the gt/uc code to use gt_err and friends

  drivers/gpu/drm/i915/gt/intel_gt.c|  96 
  drivers/gpu/drm/i915/gt/intel_gt.h|  35 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc.c|  32 +--
  drivers/gpu/drm/i915/gt/uc/intel_guc.h|  35 +++
  drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c|   8 +-
  .../gpu/drm/i915/gt/uc/intel_guc_capture.c|  48 ++--
  drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 222 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_fw.c |  19 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_log.c|  37 ++-
  drivers/gpu/drm/i915/gt/uc/intel_guc_rc.c |   7 +-
  drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c   |  55 ++---
  .../gpu/drm/i915/gt/uc/intel_guc_submission.c |  62 +++--
  drivers/gpu/drm/i915/gt/uc/intel_huc.c|  31 +--
  drivers/gpu/drm/i915/gt/uc/intel_huc.h|  23 ++
  drivers/gpu/drm/i915/gt/uc/intel_uc.c | 108 -
  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |  98 
  drivers/gpu/drm/i915/gt/uc/selftest_guc.c |  34 +--
  .../drm/i915/gt/uc/selftest_guc_hangcheck.c   |  22 +-
  .../drm/i915/gt/uc/selftest_guc_multi_lrc.c   |  10 +-
  19 files changed, 507 insertions(+), 475 deletions(-)

[PATCH] drm: rcar-du: Fix Kconfig dependency between DRM and RZG2L_MIPI_DSI

[Biju Das]

When CONFIG_DRM=m and CONFIG_DRM_RZG2L_MIPI_DSI=y, it results in a
build failure. This patch fixes the build issue by adding dependency
to DRM.

Fixes: 7a043f978ed1 ("drm: rcar-du: Add RZ/G2L DSI driver")
Reported-by: kernel test robot 
Signed-off-by: Biju Das 
---
Ref:
 * 
https://lore.kernel.org/linux-renesas-soc/os0pr01mb592298e75153a52245d789d486...@os0pr01mb5922.jpnprd01.prod.outlook.com/T/#u
---
 drivers/gpu/drm/rcar-du/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 1065dca885ef..b2bddbeca878 100644
--- a/drivers/gpu/drm/rcar-du/Kconfig
+++ b/drivers/gpu/drm/rcar-du/Kconfig
@@ -56,7 +56,7 @@ config DRM_RCAR_MIPI_DSI
 
 config DRM_RZG2L_MIPI_DSI
tristate "RZ/G2L MIPI DSI Encoder Support"
-   depends on DRM_BRIDGE && OF
+   depends on DRM && DRM_BRIDGE && OF
depends on ARCH_RENESAS || COMPILE_TEST
select DRM_MIPI_DSI
help
-- 
2.25.1

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 16.19, skrev Maxime Ripard:
> On Mon, Nov 21, 2022 at 12:48:52PM +0100, Noralf Trønnes wrote:
>> A couple of years ago my email provider blocked me from using git
>> send-email with their smtp server. So I switched to the one my ISP
>> provides. Now my ISP have outsourced their email service so the first 3
>> emails gets through and the rest looks like it ends up in a tar pit or
>> something, 18 hours later and 5 of 7 emails have gotten through. I have
>> asked them about this, but I fear the answer will be this is not
>> supported since they now don't have the service in-house anymore. I'm
>> waiting for a reply.
>>
>> Today I tried sendinblue.com since they have a free plan, but they
>> insert  in the emails so that didn't work out. They also have some
>> kind of queue, after 1 hour 6 of 7 emails have gotten through.
>>
>> Does anyone have an smtp provider to recommend that works with git
>> send-email and that sends out all the emails at once?
> 
> I'm using fastmail and am very happy about it so far.
> 
> Otherwise, you might consider using:
> https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endpoint
> 

That's an interesting option. I did briefly look at b4 a few months back
but it looked like it was under heavy development so I figured I'd wait
before trying it out. I think I'll give b4 a spin to see how it works, I
wonder how it handles patch changelogs.

Noralf.

Re: [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Sat, 2022-11-19 at 09:02 +0530, Nilawar, Badal wrote:
> 
> 
> On 19-11-2022 00:07, Vivi, Rodrigo wrote:
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >   - Fix review comments (Vinay)
> > >   - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >   - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> As he is original author I will prefer not to change it. You can
> remove 
> his rv-b while merging.

Thanks and pushed.

> 
> Regards,
> Badal
> > 
> > > Reviewed-by: Rodrigo Vivi 
> > > ---
> > >   drivers/gpu/drm/i915/gt/intel_engine_pm.c | 18
> > > ++
> > >   drivers/gpu/drm/i915/gt/intel_gt_regs.h   |  4 
> > >   2 files changed, 22 insertions(+)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index b0a4a2dbe3ee..e971b153fda9 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -15,6 +15,22 @@
> > >   #include "intel_rc6.h"
> > >   #include "intel_ring.h"
> > >   #include "shmem_utils.h"
> > > +#include "intel_gt_regs.h"
> > > +
> > > +static void intel_gsc_idle_msg_enable(struct intel_engine_cs
> > > *engine)
> > > +{
> > > +   struct drm_i915_private *i915 = engine->i915;
> > > +
> > > +   if (IS_METEORLAKE(i915) && engine->id == GSC0) {
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  RC_PSMI_CTRL_GSCCS,
> > > +
> > > _MASKED_BIT_DISABLE(IDLE_MSG_DISABLE));
> > > +   /* hysteresis 0xA=5us as recommended in spec*/
> > > +   intel_uncore_write(engine->gt->uncore,
> > > +  PWRCTX_MAXCNT_GSCCS,
> > > +  0xA);
> > > +   }
> > > +}
> > >   
> > >   static void dbg_poison_ce(struct intel_context *ce)
> > >   {
> > > @@ -275,6 +291,8 @@ void intel_engine_init__pm(struct
> > > intel_engine_cs
> > > *engine)
> > >   
> > >  intel_wakeref_init(&engine->wakeref, rpm, &wf_ops);
> > >  intel_engine_init_heartbeat(engine);
> > > +
> > > +   intel_gsc_idle_msg_enable(engine);
> > >   }
> > >   
> > >   /**
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > index c3cd92691795..80a979e6f6be 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > +++ b/drivers/gpu/drm/i915/gt/intel_gt_regs.h
> > > @@ -917,6 +917,10 @@
> > >   #define  MSG_IDLE_FW_MASK  REG_GENMASK(13, 9)
> > >   #define  MSG_IDLE_FW_SHIFT 9
> > >   
> > > +#defineRC_PSMI_CTRL_GSCCS  _MMIO(0x11a050)
> > > +#define  IDLE_MSG_DISABLE  REG_BIT(0)
> > > +#definePWRCTX_MAXCNT_GSCCS _MMIO(0x11a054)
> > > +
> > >   #define FORCEWAKE_MEDIA_GEN9   _MMIO(0xa270)
> > >   #define FORCEWAKE_RENDER_GEN9  _MMIO(0xa278)
> > >   
> > 

Re: [PATCH v3] drm/i915/mtl: Enable Idle Messaging for GSC CS

[Vivi, Rodrigo]

On Fri, 2022-11-18 at 13:37 -0800, Dixit, Ashutosh wrote:
> On Fri, 18 Nov 2022 10:37:37 -0800, Vivi, Rodrigo wrote:
> > 
> > On Sat, 2022-11-19 at 00:03 +0530, Badal Nilawar wrote:
> > > From: Vinay Belgaumkar 
> > > 
> > > By defaut idle messaging is disabled for GSC CS so to unblock RC6
> > > entry on media tile idle messaging need to be enabled.
> > > 
> > > v2:
> > >  - Fix review comments (Vinay)
> > >  - Set GSC idle hysteresis as per spec (Badal)
> > > v3:
> > >  - Fix review comments (Rodrigo)
> > > 
> > > Bspec: 71496
> > > 
> > > Cc: Daniele Ceraolo Spurio 
> > > Signed-off-by: Vinay Belgaumkar 
> > > Signed-off-by: Badal Nilawar 
> > > Reviewed-by: Vinay Belgaumkar 
> > 
> > He is the author of the patch, no?!
> > or you can remove this or change the author to be you and keep his
> > reviewed-by...
> > 
> > or I can just remove his rv-b while merging.. just let me know..
> 
> Not sure if that is the case here,

yeap, this is too small patch for that to happen.

>  but when multiple people contribute to a
> patch, the original author can review changes by others and add his
> Reviewed-by, no? Or are we saying it is redundant for the author to
> add his
> R-b?
> 
> Similarly, are S-o-b and R-b by the same person ok? I add changes to
> someone's patch so add my S-o-b but also review other's changes so
> add my
> R-b? Sometimes finding a 3rd person to add a R-b is hard. But two
> poeple
> can contribute to a patch and review each other's changes so add both
> their
> S-o-b's and R-b's or no?

Definitely a case by case thing. If that happens it is good to have it
clearly written in the commit message to know who did what, who
reviewed what.

Although I'd say that I'd still prefer the co-authored-by and having a
third one doing the full review.

> 
> :)
> 
> Ashutosh
> 

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 18.06, skrev Simon Ser:
> On Monday, November 21st, 2022 at 18:02, Simon Ser  
> wrote:
> 
>> On Monday, November 21st, 2022 at 17:52, Noralf Trønnes nor...@tronnes.org 
>> wrote:
>>
>>> Den 21.11.2022 14.33, skrev Simon Ser:
>>>
 I think you can apply for a linux.dev mailbox 1.
>>>
>>> Yeah you're right, I didn't know about that possibility.
>>> But it depends on whether or not I can just use their smtp server and
>>> keep my current email address. This looks like what's the problem with
>>> my current ISP, I need to use the email account I have in their email
>>> service (that I've never used) for sending through their smtp server,
>>> but I want to send From: another email address.
>>
>> That's not possible. It breaks DKIM, so your emails will end up in Spam
>> folders or be rejected. You need to use the SMTP server tied to your
>> email address.
> 
> That said, you can send patches from an email address different from
> the one in your patches. IOW, you can send patches committed by
>  from any email account.
> 
> The From in the email header won't match the commit, but the very first
> line of the patch will hold that information.

Thanks that was useful information. I've seen the DKIM abbr. but haven't
looked into the meaning of it.

I tried:

git send-email --from=noralf.tron...@altiboxmail.no
--reply=nor...@tronnes.org

and now I'm getting 'pass' in the Authentication-Results field, so
that's progress. I'm still not getting all the emails through, so I
still have that problem, I'll have to wait and see what the ISP can tell me.

But this means that a linux.dev mailbox is an option for me should my
ISP be a blocker.

Noralf.

Re: [PATCH] [next] drm/amdgpu: Replace remaining 1-element array with flex-array

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Nov 21, 2022 at 2:26 AM Paulo Miguel Almeida
 wrote:
>
> One-element arrays are deprecated, and we are replacing them with
> flexible array members instead. So, replace one-element array with
> flexible-array member in struct GOP_VBIOS_CONTENT and refactor the
> rest of the code accordingly.
>
> Important to mention is that doing a build before/after this patch
> results in no functional binary output differences.
>
> This helps with the ongoing efforts to tighten the FORTIFY_SOURCE
> routines on memcpy() and help us make progress towards globally
> enabling -fstrict-flex-arrays=3 [1].
>
> Link: https://github.com/KSPP/linux/issues/79
> Link: https://github.com/KSPP/linux/issues/238
> Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 [1]
>
> Signed-off-by: Paulo Miguel Almeida 
> ---
> This should be the last one-element array that had references in source
> code. Given the way it was used, no *.c code change was required.
>
> I will move on to the atombios.h in the radeon driver.
> ---
>  drivers/gpu/drm/amd/include/atombios.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/include/atombios.h 
> b/drivers/gpu/drm/amd/include/atombios.h
> index 4dc738c51771..b78360a71bc9 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -9292,7 +9292,7 @@ typedef struct {
>
>  typedef struct {
>VFCT_IMAGE_HEADER   VbiosHeader;
> -  UCHAR   VbiosContent[1];
> +  UCHAR   VbiosContent[];
>  }GOP_VBIOS_CONTENT;
>
>  typedef struct {
> --
> 2.37.3
>

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Fix negative value passed as remaining time

[Andrzej Hajda]

On 21.11.2022 15:56, Janusz Krzysztofik wrote:

Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned.  However, when
request retirement happens to succeed despite an error returned by a call
to dma_fence_wait_timeout(), that error code (a negative value) is passed
back instead of remaining time.  If we then pass that negative value
forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
will be triggered.

If request retirement succeeds but an error code is passed back via
remaininig_timeout, we may have no clue on how much of the initial timeout
might have been left for spending it on waiting for GuC to become idle.
OTOH, since all pending requests have been successfully retired, that
error code has been already ignored by intel_gt_retire_requests_timeout(),
then we shouldn't fail.

Assume no more time has been left on error and pass 0 timeout value to
intel_uc_wait_for_idle() to give it a chance to return success if GuC is
already idle.

v3: Don't fail on any error passed back via remaining_timeout.

v2: Fix the issue on the caller side, not the provider.

Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with 
GuC")
Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.15+


Reviewed-by: Andrzej Hajda 

Regards
Andrzej


---
  drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++--
  1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5ad9caa55372..7ef0edb2e37cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -677,8 +677,13 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
return -EINTR;
}
  
-	return timeout ? timeout : intel_uc_wait_for_idle(>->uc,

- remaining_timeout);
+   if (timeout)
+   return timeout;
+
+   if (remaining_timeout < 0)
+   remaining_timeout = 0;
+
+   return intel_uc_wait_for_idle(>->uc, remaining_timeout);
  }
  
  int intel_gt_init(struct intel_gt *gt)

[PATCH] drm/amdgpu: Partially revert "drm/amdgpu: update drm_display_info correctly when the edid is read"

[Alex Deucher]

This partially reverts 20543be93ca45968f344261c1a997177e51bd7e1.

Calling drm_connector_update_edid_property() in
amdgpu_connector_free_edid() causes a noticable pause in
the system every 10 seconds on polled outputs so revert this
part of the change.

Bug: https://gitlab.freedesktop.org/drm/amd/-/issues/2257
Cc: Claudio Suarez 
Signed-off-by: Alex Deucher 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 491d4846fc02..cfb262911bfc 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -328,7 +328,6 @@ static void amdgpu_connector_free_edid(struct drm_connector 
*connector)
 
kfree(amdgpu_connector->edid);
amdgpu_connector->edid = NULL;
-   drm_connector_update_edid_property(connector, NULL);
 }
 
 static int amdgpu_connector_ddc_get_modes(struct drm_connector *connector)
-- 
2.38.1

Re: [PATCH] drm/amdgpu: fix unused-function error

[Alex Deucher]

Applied.  Thanks!

Alex

On Mon, Nov 21, 2022 at 8:09 AM Ren Zhijie  wrote:
>
> If CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC is not set,
> gcc complained about unused-function :
>
> drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1705:13: error: 
> ‘amdgpu_discovery_set_sriov_display’ defined but not used 
> [-Werror=unused-function]
>  static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
>  ^~
> cc1: all warnings being treated as errors
>
> To fix this error, use CONFIG_DRM_AMD_DC to wrap
> the definition of amdgpu_discovery_set_sriov_display().
>
> Fixes: 25263da37693 ("drm/amdgpu: rework SR-IOV virtual display handling")
> Signed-off-by: Ren Zhijie 
> ---
>  drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> index 6b48178455bc..2509341df92d 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
> @@ -1702,11 +1702,13 @@ static int amdgpu_discovery_set_smu_ip_blocks(struct 
> amdgpu_device *adev)
> return 0;
>  }
>
> +#if defined(CONFIG_DRM_AMD_DC)
>  static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
>  {
> amdgpu_device_set_sriov_virtual_display(adev);
> amdgpu_device_ip_block_add(adev, &amdgpu_vkms_ip_block);
>  }
> +#endif
>
>  static int amdgpu_discovery_set_display_ip_blocks(struct amdgpu_device *adev)
>  {
> --
> 2.17.1
>

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

On Monday, November 21st, 2022 at 18:02, Simon Ser  wrote:

> On Monday, November 21st, 2022 at 17:52, Noralf Trønnes nor...@tronnes.org 
> wrote:
> 
> > Den 21.11.2022 14.33, skrev Simon Ser:
> > 
> > > I think you can apply for a linux.dev mailbox 1.
> > 
> > Yeah you're right, I didn't know about that possibility.
> > But it depends on whether or not I can just use their smtp server and
> > keep my current email address. This looks like what's the problem with
> > my current ISP, I need to use the email account I have in their email
> > service (that I've never used) for sending through their smtp server,
> > but I want to send From: another email address.
> 
> That's not possible. It breaks DKIM, so your emails will end up in Spam
> folders or be rejected. You need to use the SMTP server tied to your
> email address.

That said, you can send patches from an email address different from
the one in your patches. IOW, you can send patches committed by
 from any email account.

The From in the email header won't match the commit, but the very first
line of the patch will hold that information.

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

On Monday, November 21st, 2022 at 17:52, Noralf Trønnes  
wrote:

> Den 21.11.2022 14.33, skrev Simon Ser:
> 
> > I think you can apply for a linux.dev mailbox 1.
> 
> Yeah you're right, I didn't know about that possibility.
> But it depends on whether or not I can just use their smtp server and
> keep my current email address. This looks like what's the problem with
> my current ISP, I need to use the email account I have in their email
> service (that I've never used) for sending through their smtp server,
> but I want to send From: another email address.

That's not possible. It breaks DKIM, so your emails will end up in Spam
folders or be rejected. You need to use the SMTP server tied to your
email address.

Re: git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Den 21.11.2022 14.33, skrev Simon Ser:
> I think you can apply for a linux.dev mailbox [1].
> 

Yeah you're right, I didn't know about that possibility.
But it depends on whether or not I can just use their smtp server and
keep my current email address. This looks like what's the problem with
my current ISP, I need to use the email account I have in their email
service (that I've never used) for sending through their smtp server,
but I want to send From: another email address.

Noralf.

> [1]: https://korg.docs.kernel.org/linuxdev.html

Re: [PATCH v2 3/3] drm/gem-shmem: When drm_gem_object_init failed, should release object

[Thomas Zimmermann]

Hi

Am 19.11.22 um 07:41 schrieb ChunyouTang:

when goto err_free, the object had init, so it should be release when fail.

Signed-off-by: ChunyouTang 


Thanks a lot. I merged the patch into drm-misc-next.

Best regards
Thomas


---
  drivers/gpu/drm/drm_gem.c  | 19 ---
  drivers/gpu/drm/drm_gem_shmem_helper.c |  4 +++-
  include/drm/drm_gem.h  |  1 +
  3 files changed, 20 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 8b68a3c1e6ab..3e2e660717c3 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -169,6 +169,20 @@ void drm_gem_private_object_init(struct drm_device *dev,
  }
  EXPORT_SYMBOL(drm_gem_private_object_init);
  
+/**

+ * drm_gem_private_object_fini - Finalize a failed drm_gem_object
+ * @obj: drm_gem_object
+ *
+ * Uninitialize an already allocated GEM object when it initialized failed
+ */
+void drm_gem_private_object_fini(struct drm_gem_object *obj)
+{
+   WARN_ON(obj->dma_buf);
+
+   dma_resv_fini(&obj->_resv);
+}
+EXPORT_SYMBOL(drm_gem_private_object_fini);
+
  /**
   * drm_gem_object_handle_free - release resources bound to userspace handles
   * @obj: GEM object to clean up.
@@ -930,12 +944,11 @@ drm_gem_release(struct drm_device *dev, struct drm_file 
*file_private)
  void
  drm_gem_object_release(struct drm_gem_object *obj)
  {
-   WARN_ON(obj->dma_buf);
-
if (obj->filp)
fput(obj->filp);
  
-	dma_resv_fini(&obj->_resv);

+   drm_gem_private_object_fini(obj);
+
drm_gem_free_mmap_offset(obj);
drm_gem_lru_remove(obj);
  }
diff --git a/drivers/gpu/drm/drm_gem_shmem_helper.c 
b/drivers/gpu/drm/drm_gem_shmem_helper.c
index 35138f8a375c..db73234edcbe 100644
--- a/drivers/gpu/drm/drm_gem_shmem_helper.c
+++ b/drivers/gpu/drm/drm_gem_shmem_helper.c
@@ -79,8 +79,10 @@ __drm_gem_shmem_create(struct drm_device *dev, size_t size, 
bool private)
} else {
ret = drm_gem_object_init(dev, obj, size);
}
-   if (ret)
+   if (ret) {
+   drm_gem_private_object_fini(obj);
goto err_free;
+   }
  
  	ret = drm_gem_create_mmap_offset(obj);

if (ret)
diff --git a/include/drm/drm_gem.h b/include/drm/drm_gem.h
index bd42f25e449c..9b1feb03069d 100644
--- a/include/drm/drm_gem.h
+++ b/include/drm/drm_gem.h
@@ -405,6 +405,7 @@ int drm_gem_object_init(struct drm_device *dev,
struct drm_gem_object *obj, size_t size);
  void drm_gem_private_object_init(struct drm_device *dev,
 struct drm_gem_object *obj, size_t size);
+void drm_gem_private_object_fini(struct drm_gem_object *obj);
  void drm_gem_vm_open(struct vm_area_struct *vma);
  void drm_gem_vm_close(struct vm_area_struct *vma);
  int drm_gem_mmap_obj(struct drm_gem_object *obj, unsigned long obj_size,


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH] drm: Fix potential null-ptr-deref due to drmm_mode_config_init()

[Thomas Zimmermann]

Hi,

merged into drm-misc-next. Thanks a lot.

Best regards
Thomas

Am 18.11.22 um 03:16 schrieb Shang XiaoJing:

drmm_mode_config_init() will call drm_mode_create_standard_properties()
and won't check the ret value. When drm_mode_create_standard_properties()
failed due to alloc, property will be a NULL pointer and may causes the
null-ptr-deref. Fix the null-ptr-deref by adding the ret value check.

Found null-ptr-deref while testing insert module bochs:
general protection fault, probably for non-canonical address
 0xdc0c:  [#1] SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0060-0x0067]
CPU: 3 PID: 249 Comm: modprobe Not tainted 6.1.0-rc1+ #364
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.15.0-0-g2dd4b9b3f840-prebuilt.qemu.org 04/01/2014
RIP: 0010:drm_object_attach_property+0x73/0x3c0 [drm]
Call Trace:
  
  __drm_connector_init+0xb6c/0x1100 [drm]
  bochs_pci_probe.cold.11+0x4cb/0x7fe [bochs]
  pci_device_probe+0x17d/0x340
  really_probe+0x1db/0x5d0
  __driver_probe_device+0x1e7/0x250
  driver_probe_device+0x4a/0x120
  __driver_attach+0xcd/0x2c0
  bus_for_each_dev+0x11a/0x1b0
  bus_add_driver+0x3d7/0x500
  driver_register+0x18e/0x320
  do_one_initcall+0xc4/0x3e0
  do_init_module+0x1b4/0x630
  load_module+0x5dca/0x7230
  __do_sys_finit_module+0x100/0x170
  do_syscall_64+0x3f/0x90
  entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7ff65af9f839

Fixes: 6b4959f43a04 ("drm/atomic: atomic plane properties")
Signed-off-by: Shang XiaoJing 
---
  drivers/gpu/drm/drm_mode_config.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index 939d621c9ad4..141a5b4042b2 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -402,6 +402,8 @@ static void drm_mode_config_init_release(struct drm_device 
*dev, void *ptr)
   */
  int drmm_mode_config_init(struct drm_device *dev)
  {
+   int ret;
+
mutex_init(&dev->mode_config.mutex);
drm_modeset_lock_init(&dev->mode_config.connection_mutex);
mutex_init(&dev->mode_config.idr_mutex);
@@ -423,7 +425,11 @@ int drmm_mode_config_init(struct drm_device *dev)
init_llist_head(&dev->mode_config.connector_free_list);
INIT_WORK(&dev->mode_config.connector_free_work, 
drm_connector_free_work_fn);
  
-	drm_mode_create_standard_properties(dev);

+   ret = drm_mode_create_standard_properties(dev);
+   if (ret) {
+   drm_mode_config_cleanup(dev);
+   return ret;
+   }
  
  	/* Just to be sure */

dev->mode_config.num_fb = 0;


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

[Bug 216716] [drm:psp_resume [amdgpu]] *ERROR* PSP resume failed on r9 7950x igpu

[bugzilla-daemon]

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

Artem S. Tashkinov (a...@gmx.com) changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |ANSWERED

--- Comment #1 from Artem S. Tashkinov (a...@gmx.com) ---
Please follow the guidelines and file a report here:

https://gitlab.freedesktop.org/drm/amd/-/issues

-- 
You may reply to this email to add a comment.

You are receiving this mail because:
You are watching the assignee of the bug.

Re: [PATCH resend] drm/armada: Fix off-by-one error in armada_overlay_get_property()

[Russell King (Oracle)]

On Mon, Nov 21, 2022 at 04:43:14PM +0100, Geert Uytterhoeven wrote:
> As ffs() returns one more than the index of the first bit set (zero
> means no bits set), the color key mode value is shifted one position too
> much.
> 
> Fix this by using FIELD_GET() instead.

Reviewed-by: Russell King (Oracle) 

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[PATCH resend] drm: mxsfb: DRM_IMX_LCDIF should depend on ARCH_MXC

[Geert Uytterhoeven]

The Freescale/NXP i.MX LCDIFv3 LCD controller is only present on
Freescale/NXP i.MX SoCs.  Hence add a dependency on ARCH_MXC, to prevent
asking the user about this driver when configuring a kernel without
Freescale/NXP i.MX support.

Fixes: 9db35bb349a0ef32 ("drm: lcdif: Add support for i.MX8MP LCDIF variant")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Marek Vasut 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 70e8b01238cf9079..518b533453548630 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -25,6 +25,7 @@ config DRM_IMX_LCDIF
tristate "i.MX LCDIFv3 LCD controller"
depends on DRM && OF
depends on COMMON_CLK
+   depends on ARCH_MXC || COMPILE_TEST
select DRM_MXS
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
-- 
2.25.1

[PATCH resend] drm: mxsfb: DRM_MXSFB should depend on ARCH_MXS || ARCH_MXC

[Geert Uytterhoeven]

Freescale/NXP i.MX LCDIF and eLCDIF LCD controllers are only present on
Freescale/NXP i.MX SoCs.  Hence add a dependency on ARCH_MXS ||
ARCH_MXC, to prevent asking the user about this driver when configuring
a kernel without Freescale/NXP i.MX support.

Fixes: 45d59d704080cc0c ("drm: Add new driver for MXSFB controller")
Signed-off-by: Geert Uytterhoeven 
Reviewed-by: Marek Vasut 
---
v2:
  - Add Reviewed-by.
---
 drivers/gpu/drm/mxsfb/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/mxsfb/Kconfig b/drivers/gpu/drm/mxsfb/Kconfig
index 116f8168bda4ab1b..70e8b01238cf9079 100644
--- a/drivers/gpu/drm/mxsfb/Kconfig
+++ b/drivers/gpu/drm/mxsfb/Kconfig
@@ -8,6 +8,7 @@ config DRM_MXSFB
tristate "i.MX (e)LCDIF LCD controller"
depends on DRM && OF
depends on COMMON_CLK
+   depends on ARCH_MXS || ARCH_MXC || COMPILE_TEST
select DRM_MXS
select DRM_KMS_HELPER
select DRM_GEM_DMA_HELPER
-- 
2.25.1

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Alex Deucher]

On Mon, Nov 21, 2022 at 10:57 AM Alex Deucher  wrote:
>
> On Sat, Nov 19, 2022 at 3:44 PM Oded Gabbay  wrote:
> >
> > This is the fourth (and hopefully last) version of the patch-set to add the
> > new subsystem for compute accelerators. I removed the RFC headline as
> > I believe it is now ready for merging.
> >
> > Compare to v3, this patch-set contains one additional patch that adds
> > documentation regarding the accel subsystem. I hope it's good enough for
> > this stage. In addition, there were few very minor fixes according to
> > comments received on v3.
> >
> > The patches are in the following repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> >
> > As in v3, The HEAD of that branch is a commit adding a dummy driver that
> > registers an accel device using the new framework. This can be served
> > as a simple reference.
> >
> > v1 cover letter:
> > https://lkml.org/lkml/2022/10/22/544
> >
> > v2 cover letter:
> > https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
> >
> > v3 cover letter:
> > https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/
> >
>
> With the understanding that individual drivers can choose to use
> either classic drm or accel, whichever makes the most sense to them,
> this series is:
> Acked-by: Alex Deucher 

and not typo my email:
Acked-by: Alex Deucher 

>
> > Thanks,
> > Oded.
> >
> > Oded Gabbay (4):
> >   drivers/accel: define kconfig and register a new major
> >   accel: add dedicated minor for accelerator devices
> >   drm: initialize accel framework
> >   doc: add documentation for accel subsystem
> >
> >  Documentation/accel/index.rst |  17 ++
> >  Documentation/accel/introduction.rst  | 109 +
> >  Documentation/admin-guide/devices.txt |   5 +
> >  Documentation/subsystem-apis.rst  |   1 +
> >  MAINTAINERS   |   9 +
> >  drivers/Kconfig   |   2 +
> >  drivers/accel/Kconfig |  24 ++
> >  drivers/accel/drm_accel.c | 323 ++
> >  drivers/gpu/drm/Makefile  |   1 +
> >  drivers/gpu/drm/drm_drv.c | 102 +---
> >  drivers/gpu/drm/drm_file.c|   2 +-
> >  drivers/gpu/drm/drm_sysfs.c   |  24 +-
> >  include/drm/drm_accel.h   |  97 
> >  include/drm/drm_device.h  |   3 +
> >  include/drm/drm_drv.h |   8 +
> >  include/drm/drm_file.h|  21 +-
> >  16 files changed, 711 insertions(+), 37 deletions(-)
> >  create mode 100644 Documentation/accel/index.rst
> >  create mode 100644 Documentation/accel/introduction.rst
> >  create mode 100644 drivers/accel/Kconfig
> >  create mode 100644 drivers/accel/drm_accel.c
> >  create mode 100644 include/drm/drm_accel.h
> >
> > --
> > 2.25.1
> >

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Alex Deucher]

On Sat, Nov 19, 2022 at 3:44 PM Oded Gabbay  wrote:
>
> This is the fourth (and hopefully last) version of the patch-set to add the
> new subsystem for compute accelerators. I removed the RFC headline as
> I believe it is now ready for merging.
>
> Compare to v3, this patch-set contains one additional patch that adds
> documentation regarding the accel subsystem. I hope it's good enough for
> this stage. In addition, there were few very minor fixes according to
> comments received on v3.
>
> The patches are in the following repo:
> https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
>
> As in v3, The HEAD of that branch is a commit adding a dummy driver that
> registers an accel device using the new framework. This can be served
> as a simple reference.
>
> v1 cover letter:
> https://lkml.org/lkml/2022/10/22/544
>
> v2 cover letter:
> https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/
>
> v3 cover letter:
> https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/
>

With the understanding that individual drivers can choose to use
either classic drm or accel, whichever makes the most sense to them,
this series is:
Acked-by: Alex Deucher 

> Thanks,
> Oded.
>
> Oded Gabbay (4):
>   drivers/accel: define kconfig and register a new major
>   accel: add dedicated minor for accelerator devices
>   drm: initialize accel framework
>   doc: add documentation for accel subsystem
>
>  Documentation/accel/index.rst |  17 ++
>  Documentation/accel/introduction.rst  | 109 +
>  Documentation/admin-guide/devices.txt |   5 +
>  Documentation/subsystem-apis.rst  |   1 +
>  MAINTAINERS   |   9 +
>  drivers/Kconfig   |   2 +
>  drivers/accel/Kconfig |  24 ++
>  drivers/accel/drm_accel.c | 323 ++
>  drivers/gpu/drm/Makefile  |   1 +
>  drivers/gpu/drm/drm_drv.c | 102 +---
>  drivers/gpu/drm/drm_file.c|   2 +-
>  drivers/gpu/drm/drm_sysfs.c   |  24 +-
>  include/drm/drm_accel.h   |  97 
>  include/drm/drm_device.h  |   3 +
>  include/drm/drm_drv.h |   8 +
>  include/drm/drm_file.h|  21 +-
>  16 files changed, 711 insertions(+), 37 deletions(-)
>  create mode 100644 Documentation/accel/index.rst
>  create mode 100644 Documentation/accel/introduction.rst
>  create mode 100644 drivers/accel/Kconfig
>  create mode 100644 drivers/accel/drm_accel.c
>  create mode 100644 include/drm/drm_accel.h
>
> --
> 2.25.1
>

[PATCH resend] drm/armada: Fix off-by-one error in armada_overlay_get_property()

[Geert Uytterhoeven]

As ffs() returns one more than the index of the first bit set (zero
means no bits set), the color key mode value is shifted one position too
much.

Fix this by using FIELD_GET() instead.

Fixes: c96103b6c49ff9a8 ("drm/armada: move colorkey properties into overlay 
plane state")
Signed-off-by: Geert Uytterhoeven 
---
Compile-tested only.
---
 drivers/gpu/drm/armada/armada_overlay.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/armada/armada_overlay.c 
b/drivers/gpu/drm/armada/armada_overlay.c
index f21eb8fb76d87285..3b9bd8ecda137f6d 100644
--- a/drivers/gpu/drm/armada/armada_overlay.c
+++ b/drivers/gpu/drm/armada/armada_overlay.c
@@ -4,6 +4,8 @@
  *  Rewritten from the dovefb driver, and Armada510 manuals.
  */
 
+#include 
+
 #include 
 #include 
 #include 
@@ -445,8 +447,8 @@ static int armada_overlay_get_property(struct drm_plane 
*plane,
 drm_to_overlay_state(state)->colorkey_ug,
 drm_to_overlay_state(state)->colorkey_vb, 0);
} else if (property == priv->colorkey_mode_prop) {
-   *val = (drm_to_overlay_state(state)->colorkey_mode &
-   CFG_CKMODE_MASK) >> ffs(CFG_CKMODE_MASK);
+   *val = FIELD_GET(CFG_CKMODE_MASK,
+drm_to_overlay_state(state)->colorkey_mode);
} else if (property == priv->brightness_prop) {
*val = drm_to_overlay_state(state)->brightness + 256;
} else if (property == priv->contrast_prop) {
-- 
2.25.1

Re: [PATCH v4] dma-buf: fix racing conflict of dma_heap_add()

[Dawei Li]

On Sat, Nov 05, 2022 at 12:05:36AM +0800, Dawei Li wrote:

Hi Christian,
May I have your opinion on this change?

Thanks,
Dawei

> Racing conflict could be:
> task A task B
> list_for_each_entry
> strcmp(h->name))
>list_for_each_entry
>strcmp(h->name)
> kzallockzalloc
> .. .
> device_create  device_create
> list_add
>list_add
> 
> The root cause is that task B has no idea about the fact someone
> else(A) has inserted heap with same name when it calls list_add,
> so a potential collision occurs.
> 
> Fixes: c02a81fba74f ("dma-buf: Add dma-buf heaps framework")
> Signed-off-by: Dawei Li 
> ---
> v1: 
> https://lore.kernel.org/all/tycp286mb2323950197f60fc3473123b7ca...@tycp286mb2323.jpnp286.prod.outlook.com/
> v1->v2: Narrow down locking scope, check the existence of heap before
> insertion, as suggested by Andrew Davis.
> v2->v3: Remove double checking.
> v3->v4: Minor coding style and patch formatting adjustment.
> ---
>  drivers/dma-buf/dma-heap.c | 28 +++-
>  1 file changed, 15 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/dma-buf/dma-heap.c b/drivers/dma-buf/dma-heap.c
> index 8f5848aa144f..59d158873f4c 100644
> --- a/drivers/dma-buf/dma-heap.c
> +++ b/drivers/dma-buf/dma-heap.c
> @@ -233,18 +233,6 @@ struct dma_heap *dma_heap_add(const struct 
> dma_heap_export_info *exp_info)
>   return ERR_PTR(-EINVAL);
>   }
>  
> - /* check the name is unique */
> - mutex_lock(&heap_list_lock);
> - list_for_each_entry(h, &heap_list, list) {
> - if (!strcmp(h->name, exp_info->name)) {
> - mutex_unlock(&heap_list_lock);
> - pr_err("dma_heap: Already registered heap named %s\n",
> -exp_info->name);
> - return ERR_PTR(-EINVAL);
> - }
> - }
> - mutex_unlock(&heap_list_lock);
> -
>   heap = kzalloc(sizeof(*heap), GFP_KERNEL);
>   if (!heap)
>   return ERR_PTR(-ENOMEM);
> @@ -283,13 +271,27 @@ struct dma_heap *dma_heap_add(const struct 
> dma_heap_export_info *exp_info)
>   err_ret = ERR_CAST(dev_ret);
>   goto err2;
>   }
> - /* Add heap to the list */
> +
>   mutex_lock(&heap_list_lock);
> + /* check the name is unique */
> + list_for_each_entry(h, &heap_list, list) {
> + if (!strcmp(h->name, exp_info->name)) {
> + mutex_unlock(&heap_list_lock);
> + pr_err("dma_heap: Already registered heap named %s\n",
> +exp_info->name);
> + err_ret = ERR_PTR(-EINVAL);
> + goto err3;
> + }
> + }
> +
> + /* Add heap to the list */
>   list_add(&heap->list, &heap_list);
>   mutex_unlock(&heap_list_lock);
>  
>   return heap;
>  
> +err3:
> + device_destroy(dma_heap_class, heap->heap_devt);
>  err2:
>   cdev_del(&heap->heap_cdev);
>  err1:
> -- 
> 2.25.1
> 

Re: [PATCH v4 4/4] doc: add documentation for accel subsystem

[Jeffrey Hugo]

On 11/21/2022 8:18 AM, Oded Gabbay wrote:

On Mon, Nov 21, 2022 at 12:02 AM Jeffrey Hugo  wrote:


On 11/19/2022 1:44 PM, Oded Gabbay wrote:

Add an introduction section for the accel subsystem. Most of the
relevant data is in the DRM documentation, so the introduction only
presents the why of the new subsystem, how are the compute accelerators
exposed to user-space and what changes need to be done in a standard
DRM driver to register it to the new accel subsystem.

Signed-off-by: Oded Gabbay 
---
   Documentation/accel/index.rst|  17 +
   Documentation/accel/introduction.rst | 109 +++
   Documentation/subsystem-apis.rst |   1 +
   MAINTAINERS  |   1 +
   4 files changed, 128 insertions(+)
   create mode 100644 Documentation/accel/index.rst
   create mode 100644 Documentation/accel/introduction.rst

diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
new file mode 100644
index ..2b43c9a7f67b
--- /dev/null
+++ b/Documentation/accel/index.rst
@@ -0,0 +1,17 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Compute Accelerators
+
+
+.. toctree::
+   :maxdepth: 1
+
+   introduction
+
+.. only::  subproject and html
+
+   Indices
+   ===
+
+   * :ref:`genindex`
diff --git a/Documentation/accel/introduction.rst 
b/Documentation/accel/introduction.rst
new file mode 100644
index ..5a3963eae973
--- /dev/null
+++ b/Documentation/accel/introduction.rst
@@ -0,0 +1,109 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+
+Introduction
+
+
+The Linux compute accelerators subsystem is designed to expose compute
+accelerators in a common way to user-space and provide a common set of
+functionality.
+
+These devices can be either stand-alone ASICs or IP blocks inside an SoC/GPU.
+Although these devices are typically designed to accelerate Machine-Learning
+and/or Deep-Learning computations, the accel layer is not limited to handling


You use "DL" later on as a short form for Deep-Learning.  It would be
good to introduce that here.


+these types of accelerators.
+
+typically, a compute accelerator will belong to one of the following


Typically


+categories:
+
+- Edge AI - doing inference at an edge device. It can be an embedded ASIC/FPGA,
+  or an IP inside a SoC (e.g. laptop web camera). These devices
+  are typically configured using registers and can work with or without DMA.
+
+- Inference data-center - single/multi user devices in a large server. This
+  type of device can be stand-alone or an IP inside a SoC or a GPU. It will
+  have on-board DRAM (to hold the DL topology), DMA engines and
+  command submission queues (either kernel or user-space queues).
+  It might also have an MMU to manage multiple users and might also enable
+  virtualization (SR-IOV) to support multiple VMs on the same device. In
+  addition, these devices will usually have some tools, such as profiler and
+  debugger.
+
+- Training data-center - Similar to Inference data-center cards, but typically
+  have more computational power and memory b/w (e.g. HBM) and will likely have
+  a method of scaling-up/out, i.e. connecting to other training cards inside
+  the server or in other servers, respectively.
+
+All these devices typically have different runtime user-space software stacks,
+that are tailored-made to their h/w. In addition, they will also probably
+include a compiler to generate programs to their custom-made computational
+engines. Typically, the common layer in user-space will be the DL frameworks,
+such as PyTorch and TensorFlow.
+
+Sharing code with DRM
+=
+
+Because this type of devices can be an IP inside GPUs or have similar
+characteristics as those of GPUs, the accel subsystem will use the
+DRM subsystem's code and functionality. i.e. the accel core code will
+be part of the DRM subsystem and an accel device will be a new type of DRM
+device.
+
+This will allow us to leverage the extensive DRM code-base and
+collaborate with DRM developers that have experience with this type of
+devices. In addition, new features that will be added for the accelerator
+drivers can be of use to GPU drivers as well.
+
+Differentiation from GPUs
+=
+
+Because we want to prevent the extensive user-space graphic software stack
+from trying to use an accelerator as a GPU, the compute accelerators will be
+differentiated from GPUs by using a new major number and new device char files.
+
+Furthermore, the drivers will be located in a separate place in the kernel
+tree - drivers/accel/.
+
+The accelerator devices will be exposed to the user space with the dedicated
+261 major number and will have the following convention:
+
+- device char files - /dev/accel/accel*
+- sysfs - /sys/class/accel/accel*/
+- debugfs   - /sys/kernel/debug/accel/accel*/
+
+Getting Started
+===
+
+First, read the DRM documentation. Not onl

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Javier Martinez Canillas]

On 11/21/22 13:27, Noralf Trønnes wrote:
> 
> 
> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
>> drivers vmap/vunmap GEM buffer memory during the atomic commit.
>> Shadow-plane helpers automate this process.
>>
>> Patches 1 to 4 prepare the MIPI code for the change and simplify
>> the restof the patchset.
>>
>> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
>> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
>> helpers and get the update automatically. Only ili9225 and st7586
>> require changes to their source code.
>>
>> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
>> needed, but streamlines the driver code and make sense overall.
>>
>> Testing is welcome, as I don't have any hardware to test these
>> changes myself.
>>
> 
> I can do a test this weekend.
>

I've a ST7735 display so I can also give it a test this weekend.

-- 
Best regards,

Javier Martinez Canillas
Core Platforms
Red Hat

Re: git send-email friendly smtp provider anyone?

[Maxime Ripard]

On Mon, Nov 21, 2022 at 12:48:52PM +0100, Noralf Trønnes wrote:
> A couple of years ago my email provider blocked me from using git
> send-email with their smtp server. So I switched to the one my ISP
> provides. Now my ISP have outsourced their email service so the first 3
> emails gets through and the rest looks like it ends up in a tar pit or
> something, 18 hours later and 5 of 7 emails have gotten through. I have
> asked them about this, but I fear the answer will be this is not
> supported since they now don't have the service in-house anymore. I'm
> waiting for a reply.
> 
> Today I tried sendinblue.com since they have a free plan, but they
> insert  in the emails so that didn't work out. They also have some
> kind of queue, after 1 hour 6 of 7 emails have gotten through.
> 
> Does anyone have an smtp provider to recommend that works with git
> send-email and that sends out all the emails at once?

I'm using fastmail and am very happy about it so far.

Otherwise, you might consider using:
https://b4.docs.kernel.org/en/latest/contributor/send.html#authenticating-with-the-web-submission-endpoint

Maxime


signature.asc
Description: PGP signature

Re: [PATCH v4 4/4] doc: add documentation for accel subsystem

[Oded Gabbay]

On Mon, Nov 21, 2022 at 12:02 AM Jeffrey Hugo  wrote:
>
> On 11/19/2022 1:44 PM, Oded Gabbay wrote:
> > Add an introduction section for the accel subsystem. Most of the
> > relevant data is in the DRM documentation, so the introduction only
> > presents the why of the new subsystem, how are the compute accelerators
> > exposed to user-space and what changes need to be done in a standard
> > DRM driver to register it to the new accel subsystem.
> >
> > Signed-off-by: Oded Gabbay 
> > ---
> >   Documentation/accel/index.rst|  17 +
> >   Documentation/accel/introduction.rst | 109 +++
> >   Documentation/subsystem-apis.rst |   1 +
> >   MAINTAINERS  |   1 +
> >   4 files changed, 128 insertions(+)
> >   create mode 100644 Documentation/accel/index.rst
> >   create mode 100644 Documentation/accel/introduction.rst
> >
> > diff --git a/Documentation/accel/index.rst b/Documentation/accel/index.rst
> > new file mode 100644
> > index ..2b43c9a7f67b
> > --- /dev/null
> > +++ b/Documentation/accel/index.rst
> > @@ -0,0 +1,17 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +
> > +Compute Accelerators
> > +
> > +
> > +.. toctree::
> > +   :maxdepth: 1
> > +
> > +   introduction
> > +
> > +.. only::  subproject and html
> > +
> > +   Indices
> > +   ===
> > +
> > +   * :ref:`genindex`
> > diff --git a/Documentation/accel/introduction.rst 
> > b/Documentation/accel/introduction.rst
> > new file mode 100644
> > index ..5a3963eae973
> > --- /dev/null
> > +++ b/Documentation/accel/introduction.rst
> > @@ -0,0 +1,109 @@
> > +.. SPDX-License-Identifier: GPL-2.0
> > +
> > +
> > +Introduction
> > +
> > +
> > +The Linux compute accelerators subsystem is designed to expose compute
> > +accelerators in a common way to user-space and provide a common set of
> > +functionality.
> > +
> > +These devices can be either stand-alone ASICs or IP blocks inside an 
> > SoC/GPU.
> > +Although these devices are typically designed to accelerate 
> > Machine-Learning
> > +and/or Deep-Learning computations, the accel layer is not limited to 
> > handling
>
> You use "DL" later on as a short form for Deep-Learning.  It would be
> good to introduce that here.
>
> > +these types of accelerators.
> > +
> > +typically, a compute accelerator will belong to one of the following
>
> Typically
>
> > +categories:
> > +
> > +- Edge AI - doing inference at an edge device. It can be an embedded 
> > ASIC/FPGA,
> > +  or an IP inside a SoC (e.g. laptop web camera). These devices
> > +  are typically configured using registers and can work with or without 
> > DMA.
> > +
> > +- Inference data-center - single/multi user devices in a large server. This
> > +  type of device can be stand-alone or an IP inside a SoC or a GPU. It will
> > +  have on-board DRAM (to hold the DL topology), DMA engines and
> > +  command submission queues (either kernel or user-space queues).
> > +  It might also have an MMU to manage multiple users and might also enable
> > +  virtualization (SR-IOV) to support multiple VMs on the same device. In
> > +  addition, these devices will usually have some tools, such as profiler 
> > and
> > +  debugger.
> > +
> > +- Training data-center - Similar to Inference data-center cards, but 
> > typically
> > +  have more computational power and memory b/w (e.g. HBM) and will likely 
> > have
> > +  a method of scaling-up/out, i.e. connecting to other training cards 
> > inside
> > +  the server or in other servers, respectively.
> > +
> > +All these devices typically have different runtime user-space software 
> > stacks,
> > +that are tailored-made to their h/w. In addition, they will also probably
> > +include a compiler to generate programs to their custom-made computational
> > +engines. Typically, the common layer in user-space will be the DL 
> > frameworks,
> > +such as PyTorch and TensorFlow.
> > +
> > +Sharing code with DRM
> > +=
> > +
> > +Because this type of devices can be an IP inside GPUs or have similar
> > +characteristics as those of GPUs, the accel subsystem will use the
> > +DRM subsystem's code and functionality. i.e. the accel core code will
> > +be part of the DRM subsystem and an accel device will be a new type of DRM
> > +device.
> > +
> > +This will allow us to leverage the extensive DRM code-base and
> > +collaborate with DRM developers that have experience with this type of
> > +devices. In addition, new features that will be added for the accelerator
> > +drivers can be of use to GPU drivers as well.
> > +
> > +Differentiation from GPUs
> > +=
> > +
> > +Because we want to prevent the extensive user-space graphic software stack
> > +from trying to use an accelerator as a GPU, the compute accelerators will 
> > be
> > +differentiated from GPUs by using a new major number and new device char 
> > files.
> > +
> > +Furth

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Noralf Trønnes]

Den 21.11.2022 13.41, skrev Thomas Zimmermann:
> Hi
> 
> Am 21.11.22 um 13:27 schrieb Noralf Trønnes:
>>
>>
>> Den 21.11.2022 11.45, skrev Thomas Zimmermann:
>>> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
>>> drivers vmap/vunmap GEM buffer memory during the atomic commit.
>>> Shadow-plane helpers automate this process.
>>>
>>> Patches 1 to 4 prepare the MIPI code for the change and simplify
>>> the restof the patchset.
>>>
>>> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
>>> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
>>> helpers and get the update automatically. Only ili9225 and st7586
>>> require changes to their source code.
>>>
>>> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
>>> needed, but streamlines the driver code and make sense overall.
>>>
>>> Testing is welcome, as I don't have any hardware to test these
>>> changes myself.
>>>
>>
>> I can do a test this weekend.
> 
> Thanks a lot.
> 
>>
>> Btw I've converted drm/gud to the shadow plane helper, I just need to
>> solve an smtp problem[1] so I can send out the patchset.
> 
> How so?  When I looked at it, the vmap/vunmap happened on a separate
> worker than the commit IIRC.
> 

Yes you're right, originally the driver only did flushing asynchronously
in a worker which meant it could access the framebuffer at the same time
as userspace. Later when GNOME got support for one rendering loop per
display, I added a module parameter to enable synchronous flushing
during the commit, it also uses the worker for this but waits for it to
complete.

What I've done in the patchset is to inline the sync flushing and use a
shadow buffer for the async path which still uses the worker, but now it
won't risk reading the framebuffer while userspace writes to it, instead
it reads from the shadow buffer.

Noralf.

> Best regards
> Thomas
> 
>>
>> [1]
>> https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u
>>
>> Noralf.
> 

Re: [PATCH v4 2/4] accel: add dedicated minor for accelerator devices

[Oded Gabbay]

On Sun, Nov 20, 2022 at 11:47 PM Jeffrey Hugo  wrote:
>
> On 11/19/2022 1:44 PM, Oded Gabbay wrote:
> > diff --git a/drivers/accel/drm_accel.c b/drivers/accel/drm_accel.c
> > index fac6ad6ac28e..703d40c4ff45 100644
> > --- a/drivers/accel/drm_accel.c
> > +++ b/drivers/accel/drm_accel.c
> > @@ -8,14 +8,25 @@
> >
> >   #include 
> >   #include 
> > +#include 
>
> Including xarray, but using idr
> This should be linux/idr.h
>
> This seems so minor, I don't think I advise spinning a v5 for it.  If a
> v5 is warranted elsewhere, obviously fix this.  If not, hopefully this
> can be fixed up by whoever applies it, or someone submits a follow up patch.
>
> Hopefully this is the only nit.  I would like to see this merged.
>
> -Jeff
Thanks,
I'll update it before sending the PR.
Oded

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Oded Gabbay]

On Mon, Nov 21, 2022 at 8:26 AM Dave Airlie  wrote:
>
> On Sun, 20 Nov 2022 at 06:44, Oded Gabbay  wrote:
> >
> > This is the fourth (and hopefully last) version of the patch-set to add the
> > new subsystem for compute accelerators. I removed the RFC headline as
> > I believe it is now ready for merging.
> >
> > Compare to v3, this patch-set contains one additional patch that adds
> > documentation regarding the accel subsystem. I hope it's good enough for
> > this stage. In addition, there were few very minor fixes according to
> > comments received on v3.
> >
> > The patches are in the following repo:
> > https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4
> >
> > As in v3, The HEAD of that branch is a commit adding a dummy driver that
> > registers an accel device using the new framework. This can be served
> > as a simple reference.
> >
>
> FIx the nits Jeffery raised and the one I brought up and I think we
> should be good for this to be in a PR.
>
> Reviewed-by: Dave Airlie 
Sure, np.
Oded

Re: [PATCH v4 0/4] new subsystem for compute accelerator devices

[Thomas Zimmermann]

Acked-by: Thomas Zimmermann 

Am 19.11.22 um 21:44 schrieb Oded Gabbay:

This is the fourth (and hopefully last) version of the patch-set to add the
new subsystem for compute accelerators. I removed the RFC headline as
I believe it is now ready for merging.

Compare to v3, this patch-set contains one additional patch that adds
documentation regarding the accel subsystem. I hope it's good enough for
this stage. In addition, there were few very minor fixes according to
comments received on v3.

The patches are in the following repo:
https://git.kernel.org/pub/scm/linux/kernel/git/ogabbay/accel.git/log/?h=accel_v4

As in v3, The HEAD of that branch is a commit adding a dummy driver that
registers an accel device using the new framework. This can be served
as a simple reference.

v1 cover letter:
https://lkml.org/lkml/2022/10/22/544

v2 cover letter:
https://lore.kernel.org/lkml/20221102203405.1797491-1-ogab...@kernel.org/T/

v3 cover letter:
https://lore.kernel.org/lkml/20221106210225.2065371-1-ogab...@kernel.org/T/

Thanks,
Oded.

Oded Gabbay (4):
   drivers/accel: define kconfig and register a new major
   accel: add dedicated minor for accelerator devices
   drm: initialize accel framework
   doc: add documentation for accel subsystem

  Documentation/accel/index.rst |  17 ++
  Documentation/accel/introduction.rst  | 109 +
  Documentation/admin-guide/devices.txt |   5 +
  Documentation/subsystem-apis.rst  |   1 +
  MAINTAINERS   |   9 +
  drivers/Kconfig   |   2 +
  drivers/accel/Kconfig |  24 ++
  drivers/accel/drm_accel.c | 323 ++
  drivers/gpu/drm/Makefile  |   1 +
  drivers/gpu/drm/drm_drv.c | 102 +---
  drivers/gpu/drm/drm_file.c|   2 +-
  drivers/gpu/drm/drm_sysfs.c   |  24 +-
  include/drm/drm_accel.h   |  97 
  include/drm/drm_device.h  |   3 +
  include/drm/drm_drv.h |   8 +
  include/drm/drm_file.h|  21 +-
  16 files changed, 711 insertions(+), 37 deletions(-)
  create mode 100644 Documentation/accel/index.rst
  create mode 100644 Documentation/accel/introduction.rst
  create mode 100644 drivers/accel/Kconfig
  create mode 100644 drivers/accel/drm_accel.c
  create mode 100644 include/drm/drm_accel.h

--
2.25.1



--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH v3 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v3: Use conditional expression, more compact but also better reflecting
intention standing behind the change.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with retire_request")
Signed-off-by: Janusz Krzysztofik 
Reviewed-by: Andrzej Hajda 
Cc: sta...@vger.kernel.org # v5.5+
---
 drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c 
b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
index edb881d756309..1dfd01668c79c 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,7 +199,7 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;
 
-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;
 }
 
 static void retire_work_handler(struct work_struct *work)
-- 
2.25.1

[PATCH v3 0/2] drm/i915: Fix timeout handling when retiring requests

[Janusz Krzysztofik]

Fixes for issues discovered via code review while working on
https://gitlab.freedesktop.org/drm/intel/issues/7349.

v3:
PATCH 1: don't fail on any error passed back via remaining_timeout,
PATCH 2: use conditional expression, more compact but also better
 reflecting intention standing behind the change.

v2:
PATCH 1: fix the issue on the caller side, not the provider,
 reword commit message and description.
PATCH 2: move the added lines down so flush_submission() is not affected,
 reword commit message and description.
PATCH 3: drop -- controversial, not needed.

Janusz Krzysztofik (2):
  drm/i915: Fix negative value passed as remaining time
  drm/i915: Never return 0 if not all requests retired

 drivers/gpu/drm/i915/gt/intel_gt.c  | 9 +++--
 drivers/gpu/drm/i915/gt/intel_gt_requests.c | 2 +-
 2 files changed, 8 insertions(+), 3 deletions(-)

-- 
2.25.1

[PATCH v3 1/2] drm/i915: Fix negative value passed as remaining time

[Janusz Krzysztofik]

Commit b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work
with GuC") extended the API of intel_gt_retire_requests_timeout() with an
extra argument 'remaining_timeout', intended for passing back unconsumed
portion of requested timeout when 0 (success) is returned.  However, when
request retirement happens to succeed despite an error returned by a call
to dma_fence_wait_timeout(), that error code (a negative value) is passed
back instead of remaining time.  If we then pass that negative value
forward as requested timeout to intel_uc_wait_for_idle(), an explicit BUG
will be triggered.

If request retirement succeeds but an error code is passed back via
remaininig_timeout, we may have no clue on how much of the initial timeout
might have been left for spending it on waiting for GuC to become idle.
OTOH, since all pending requests have been successfully retired, that
error code has been already ignored by intel_gt_retire_requests_timeout(),
then we shouldn't fail.

Assume no more time has been left on error and pass 0 timeout value to
intel_uc_wait_for_idle() to give it a chance to return success if GuC is
already idle.

v3: Don't fail on any error passed back via remaining_timeout.

v2: Fix the issue on the caller side, not the provider.

Fixes: b97060a99b01 ("drm/i915/guc: Update intel_gt_wait_for_idle to work with 
GuC")
Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.15+
---
 drivers/gpu/drm/i915/gt/intel_gt.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c 
b/drivers/gpu/drm/i915/gt/intel_gt.c
index b5ad9caa55372..7ef0edb2e37cd 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -677,8 +677,13 @@ int intel_gt_wait_for_idle(struct intel_gt *gt, long 
timeout)
return -EINTR;
}
 
-   return timeout ? timeout : intel_uc_wait_for_idle(>->uc,
- remaining_timeout);
+   if (timeout)
+   return timeout;
+
+   if (remaining_timeout < 0)
+   remaining_timeout = 0;
+
+   return intel_uc_wait_for_idle(>->uc, remaining_timeout);
 }
 
 int intel_gt_init(struct intel_gt *gt)
-- 
2.25.1

Re: [PATCH v10 00/19] drm: Analog TV Improvements

[Daniel Vetter]

On Thu, Nov 17, 2022 at 10:28:43AM +0100, Maxime Ripard wrote:
> Hi,
> 
> Here's a series aiming at improving the command line named modes support,
> and more importantly how we deal with all the analog TV variants.
> 
> The named modes support were initially introduced to allow to specify the
> analog TV mode to be used.
> 
> However, this was causing multiple issues:
> 
>   * The mode name parsed on the command line was passed directly to the
> driver, which had to figure out which mode it was suppose to match;
> 
>   * Figuring that out wasn't really easy, since the video= argument or what
> the userspace might not even have a name in the first place, but
> instead could have passed a mode with the same timings;
> 
>   * The fallback to matching on the timings was mostly working as long as
> we were supporting one 525 lines (most likely NSTC) and one 625 lines
> (PAL), but couldn't differentiate between two modes with the same
> timings (NTSC vs PAL-M vs NSTC-J for example);
> 
>   * There was also some overlap with the tv mode property registered by
> drm_mode_create_tv_properties(), but named modes weren't interacting
> with that property at all.
> 
>   * Even though that property was generic, its possible values were
> specific to each drivers, which made some generic support difficult.
> 
> Thus, I chose to tackle in multiple steps:
> 
>   * A new TV mode property was introduced, with generic values, each driver
> reporting through a bitmask what standard it supports to the userspace;
> 
>   * This option was added to the command line parsing code to be able to
> specify it on the kernel command line, and new atomic_check and reset
> helpers were created to integrate properly into atomic KMS;
> 
>   * The named mode parsing code is now creating a proper display mode for
> the given named mode, and the TV standard will thus be part of the
> connector state;
> 
>   * Two drivers were converted and tested for now (vc4 and sun4i), with
> some backward compatibility code to translate the old TV mode to the
> new TV mode;
> 
> Unit tests were created along the way.
> 
> One can switch from NTSC to PAL now using (on vc4)
> 
> modetest -M vc4  -s 53:720x480i -w 53:'TV mode':1 # NTSC
> modetest -M vc4  -s 53:720x576i -w 53:'TV mode':4 # PAL
> 
> Let me know what you think,
> Maxime

Maxime asked me to drop an Ack-in-principle on this, and I'm not sure I
have any useful input here with my utter lack of understanding for TV
things (I never even had one in my entire life, that's how much I don't
care). But it seems to check all the design boxes around solving annoying
uapi/kms-config issues properly, so

Acked-in-principle-or-something-like-that-by: Daniel Vetter 


Cheers, Daniel

> 
> To: David Airlie 
> To: Daniel Vetter 
> To: Maarten Lankhorst 
> To: Maxime Ripard 
> To: Thomas Zimmermann 
> To: Emma Anholt 
> To: Jani Nikula 
> To: Joonas Lahtinen 
> To: Rodrigo Vivi 
> To: Tvrtko Ursulin 
> To: Ben Skeggs 
> To: Karol Herbst 
> To: Lyude Paul 
> To: Chen-Yu Tsai 
> To: Jernej Skrabec 
> To: Samuel Holland 
> Cc: Geert Uytterhoeven 
> Cc: Mateusz Kwiatkowski 
> Cc: "Noralf Trønnes" 
> Cc: Dave Stevenson 
> Cc: Dom Cobley 
> Cc: Phil Elwell 
> Cc: 
> Cc: linux-ker...@vger.kernel.org
> Cc: intel-...@lists.freedesktop.org
> Cc: nouv...@lists.freedesktop.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-su...@lists.linux.dev
> Cc: Hans de Goede 
> Signed-off-by: Maxime Ripard 
> 
> ---
> Changes in v10:
> - Rebase on top of drm-misc-next-2022-11-17
> - Fix checkpatch issues
> - Add missing MODULE_* macros
> - Link to v9: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v9-0-24b168e5b...@cerno.tech
> 
> Changes in v9:
> - Rename some tests, switch to kunit_test_suite and parameterized tests where
>   relevant
> - Document the valid named modes
> - Link to v8: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v8-0-09ce14669...@cerno.tech
> 
> Changes in v8:
> - Changed slightly the helper API to pass in the features
> - Removed unused tv_mode_support function
> - Removed mode name match in _pick_cmdline_mode
> - Added unit tests to the get_modes helper
> - Collected Noralf and Mateusz tags
> - Rebased on drm-misc-next-2022-11-10
> - Link to v7: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v7-0-7072a478c...@cerno.tech
> 
> Changes in v7:
> - Switch to another implementation of get_modes from Noralf
> - Made more checks in VEC's atomic_check
> - Fixed typo in a commit log
> - Checked for tv_mode_specified in drm_mode_parse_command_line_for_connector
> - Rebased on drm-misc-next-2022-11-03
> - Link to v6: 
> https://lore.kernel.org/r/20220728-rpi-analog-tv-properties-v6-0-e77927341...@cerno.tech
> 
> Changes in v6:
> - Add and convert to a new get_modes helper to create the PAL and NTSC modes 
> in
>   the proper order, with the right preferred mode flag, depending on the 
> driver
>   capabilities

[PATCH] drm/logicvc: Drop obsolete dependency on COMPILE_TEST

[Jean Delvare]

Since commit 0166dc11be91 ("of: make CONFIG_OF user selectable"), it
is possible to test-build any driver which depends on OF on any
architecture by explicitly selecting OF. Therefore depending on
COMPILE_TEST as an alternative is no longer needed.

It is actually better to always build such drivers with OF enabled,
so that the test builds are closer to how each driver will actually be
built on its intended target. Building them without OF may not test
much as the compiler will optimize out potentially large parts of the
code. In the worst case, this could even pop false positive warnings.
Dropping COMPILE_TEST here improves the quality of our testing and
avoids wasting time on non-existent issues.

Signed-off-by: Jean Delvare 
Cc: Paul Kocialkowski 
Cc: David Airlie 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/logicvc/Kconfig |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

--- linux-6.0.orig/drivers/gpu/drm/logicvc/Kconfig
+++ linux-6.0/drivers/gpu/drm/logicvc/Kconfig
@@ -1,7 +1,7 @@
 config DRM_LOGICVC
tristate "LogiCVC DRM"
depends on DRM
-   depends on OF || COMPILE_TEST
+   depends on OF
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER


-- 
Jean Delvare
SUSE L3 Support

[PATCH] i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer

[Wang Yufen]

Fix to return a negative error code from the gi2c->err instead of
0.

Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
Signed-off-by: Wang Yufen 
---
 drivers/i2c/busses/i2c-qcom-geni.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
b/drivers/i2c/busses/i2c-qcom-geni.c
index 84a7751..8fce98b 100644
--- a/drivers/i2c/busses/i2c-qcom-geni.c
+++ b/drivers/i2c/busses/i2c-qcom-geni.c
@@ -626,7 +626,6 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, 
struct i2c_msg msgs[], i
dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d 
addr:0x%x\n",
gi2c->cur->flags, gi2c->cur->addr);
gi2c->err = -ETIMEDOUT;
-   goto err;
}
 
if (gi2c->err) {
-- 
1.8.3.1

[PATCH v2 2/2] drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

[Carlo Caione]

The pixel data for the ILI9486 is always 16-bits wide and it must be
sent over the SPI bus. When the controller is only able to deal with
8-bit transfers, this 16-bits data needs to be swapped before the
sending to account for the big endian bus, this is on the contrary not
needed when the SPI controller already supports 16-bits transfers.

The decision about swapping the pixel data or not is taken in the MIPI
DBI code by probing the controller capabilities: if the controller only
suppors 8-bit transfers the data is swapped, otherwise it is not.

This swapping/non-swapping is relying on the assumption that when the
controller does support 16-bit transactions then the data is sent
unswapped in 16-bits-per-word over SPI.

The problem with the ILI9486 driver is that it is forcing 8-bit
transactions also for controllers supporting 16-bits, violating the
assumption and corrupting the pixel data.

Align the driver to what is done in the MIPI DBI code by adjusting the
tranfer size to the maximum allowed by the SPI controller.

Signed-off-by: Carlo Caione 
---
 drivers/gpu/drm/tiny/ili9486.c | 13 +
 1 file changed, 9 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index bd37dfe8dd05..4d80a413338f 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -43,6 +43,7 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd, 
u8 *par,
 size_t num)
 {
struct spi_device *spi = mipi->spi;
+   unsigned int bpw = 8;
void *data = par;
u32 speed_hz;
int i, ret;
@@ -56,8 +57,6 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 *cmd, 
u8 *par,
 * The displays are Raspberry Pi HATs and connected to the 8-bit only
 * SPI controller, so 16-bit command and parameters need byte swapping
 * before being transferred as 8-bit on the big endian SPI bus.
-* Pixel data bytes have already been swapped before this function is
-* called.
 */
buf[0] = cpu_to_be16(*cmd);
gpiod_set_value_cansleep(mipi->dc, 0);
@@ -71,12 +70,18 @@ static int waveshare_command(struct mipi_dbi *mipi, u8 
*cmd, u8 *par,
for (i = 0; i < num; i++)
buf[i] = cpu_to_be16(par[i]);
num *= 2;
-   speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
data = buf;
}
 
+   /*
+* Check whether pixel data bytes needs to be swapped or not
+*/
+   if (*cmd == MIPI_DCS_WRITE_MEMORY_START && !mipi->swap_bytes)
+   bpw = 16;
+
gpiod_set_value_cansleep(mipi->dc, 1);
-   ret = mipi_dbi_spi_transfer(spi, speed_hz, 8, data, num);
+   speed_hz = mipi_dbi_spi_cmd_max_speed(spi, num);
+   ret = mipi_dbi_spi_transfer(spi, speed_hz, bpw, data, num);
  free:
kfree(buf);
 

-- 
b4 0.10.1

[PATCH v2 0/2] Make ILI9486 driver working with 16-bits SPI controllers

[Carlo Caione]

This patchset is trying to fix problems seen on S905X boards when interfacing
with an ILI9486 equipped SPI panel.

To: Kamlesh Gurudasani 
To: David Airlie 
To: Daniel Vetter 
To: Mark Brown 
To: Neil Armstrong 
To: Kevin Hilman 
To: Jerome Brunet 
To: Martin Blumenstingl 
Cc: dri-devel@lists.freedesktop.org
Cc: linux-ker...@vger.kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: linux-amlo...@lists.infradead.org
Signed-off-by: Carlo Caione 

---
Changes in v2:
- Removed SPICC patch
- Reworked commit message
- Link to v1: 
https://lore.kernel.org/r/20221116-s905x_spi_ili9486-v1-0-630401cb6...@baylibre.com

---
Carlo Caione (2):
  drm/tiny: rpi-lcd-35: Enable driver module autoloading
  drm/tiny: ili9486: Do not assume 8-bit only SPI controllers

 drivers/gpu/drm/tiny/ili9486.c | 14 ++
 1 file changed, 10 insertions(+), 4 deletions(-)
---
base-commit: 147307c69ba4441ee90c1f8ce8edf5df4ea60f67
change-id: 20221116-s905x_spi_ili9486-aed54ff3cb21

Best regards,
-- 
Carlo Caione

[PATCH v2 1/2] drm/tiny: rpi-lcd-35: Enable driver module autoloading

[Carlo Caione]

SPI devices use the spi_device_id for module autoloading even on
systems using device tree.

Add the spi_device_id entry to enable autoloading for the 3.5inch RPi
Display (rpi-lcd-35).

Signed-off-by: Carlo Caione 
---
 drivers/gpu/drm/tiny/ili9486.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/tiny/ili9486.c b/drivers/gpu/drm/tiny/ili9486.c
index 1bb847466b10..bd37dfe8dd05 100644
--- a/drivers/gpu/drm/tiny/ili9486.c
+++ b/drivers/gpu/drm/tiny/ili9486.c
@@ -183,6 +183,7 @@ MODULE_DEVICE_TABLE(of, ili9486_of_match);
 
 static const struct spi_device_id ili9486_id[] = {
{ "ili9486", 0 },
+   { "rpi-lcd-35", 0 },
{ }
 };
 MODULE_DEVICE_TABLE(spi, ili9486_id);

-- 
b4 0.10.1

[PATCH] gpu: vgpu: delete a semicolon

[Li kunyu]

Remove extra semicolons at the end of statements to make them look
cleaner.

Signed-off-by: Li kunyu 
---
 drivers/gpu/drm/i915/gvt/vgpu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gvt/vgpu.c b/drivers/gpu/drm/i915/gvt/vgpu.c
index 56c71474008a..5ccb04e26e6d 100644
--- a/drivers/gpu/drm/i915/gvt/vgpu.c
+++ b/drivers/gpu/drm/i915/gvt/vgpu.c
@@ -325,7 +325,7 @@ int intel_gvt_create_vgpu(struct intel_vgpu *vgpu,
ret = idr_alloc(&gvt->vgpu_idr, vgpu, IDLE_VGPU_IDR + 1, GVT_MAX_VGPU,
GFP_KERNEL);
if (ret < 0)
-   goto out_unlock;;
+   goto out_unlock;
 
vgpu->id = ret;
vgpu->sched_ctl.weight = conf->weight;
-- 
2.18.2

Re: git send-email friendly smtp provider anyone?

[Simon Ser]

I think you can apply for a linux.dev mailbox [1].

[1]: https://korg.docs.kernel.org/linuxdev.html

[PATCH] drm/amdgpu: fix unused-function error

[Ren Zhijie]

If CONFIG_DRM_AMDGPU=y and CONFIG_DRM_AMD_DC is not set,
gcc complained about unused-function :

drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c:1705:13: error: 
‘amdgpu_discovery_set_sriov_display’ defined but not used 
[-Werror=unused-function]
 static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
 ^~
cc1: all warnings being treated as errors

To fix this error, use CONFIG_DRM_AMD_DC to wrap
the definition of amdgpu_discovery_set_sriov_display().

Fixes: 25263da37693 ("drm/amdgpu: rework SR-IOV virtual display handling")
Signed-off-by: Ren Zhijie 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
index 6b48178455bc..2509341df92d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_discovery.c
@@ -1702,11 +1702,13 @@ static int amdgpu_discovery_set_smu_ip_blocks(struct 
amdgpu_device *adev)
return 0;
 }
 
+#if defined(CONFIG_DRM_AMD_DC)
 static void amdgpu_discovery_set_sriov_display(struct amdgpu_device *adev)
 {
amdgpu_device_set_sriov_virtual_display(adev);
amdgpu_device_ip_block_add(adev, &amdgpu_vkms_ip_block);
 }
+#endif
 
 static int amdgpu_discovery_set_display_ip_blocks(struct amdgpu_device *adev)
 {
-- 
2.17.1

Re: [PATCH v3] drm/i915/mtl: Media GT and Render GT share common GGTT

[Iddamsetty, Aravind]

On 19-11-2022 04:22, Matt Roper wrote:
> On Tue, Nov 15, 2022 at 08:34:54PM +0530, Aravind Iddamsetty wrote:
>> On XE_LPM+ platforms the media engines are carved out into a separate
>> GT but have a common GGTMMADR address range which essentially makes
>> the GGTT address space to be shared between media and render GT. As a
>> result any updates in GGTT shall invalidate TLB of GTs sharing it and
>> similarly any operation on GGTT requiring an action on a GT will have to
>> involve all GTs sharing it. setup_private_pat was being done on a per
>> GGTT based as that doesn't touch any GGTT structures moved it to per GT
>> based.
>>
>> BSPEC: 63834
>>
>> v2:
>> 1. Add details to commit msg
>> 2. includes fix for failure to add item to ggtt->gt_list, as suggested
>> by Lucas
>> 3. as ggtt_flush() is used only for ggtt drop i915_is_ggtt check within
>> it.
>> 4. setup_private_pat moved out of intel_gt_tiles_init
>>
>> v3:
>> 1. Move out for_each_gt from i915_driver.c (Jani Nikula)
>>
>> Cc: Matt Roper 
>> Signed-off-by: Aravind Iddamsetty 
>> ---
>>  drivers/gpu/drm/i915/gt/intel_ggtt.c  | 54 +--
>>  drivers/gpu/drm/i915/gt/intel_gt.c| 13 +-
>>  drivers/gpu/drm/i915/gt/intel_gt_types.h  |  3 ++
>>  drivers/gpu/drm/i915/gt/intel_gtt.h   |  4 ++
>>  drivers/gpu/drm/i915/i915_driver.c| 12 ++---
>>  drivers/gpu/drm/i915/i915_gem.c   |  2 +
>>  drivers/gpu/drm/i915/i915_gem_evict.c | 51 +++--
>>  drivers/gpu/drm/i915/i915_vma.c   |  5 ++-
>>  drivers/gpu/drm/i915/selftests/i915_gem.c |  2 +
>>  9 files changed, 111 insertions(+), 35 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c 
>> b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> index 8145851ad23d..7644738b9cdb 100644
>> --- a/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> +++ b/drivers/gpu/drm/i915/gt/intel_ggtt.c
>> @@ -8,6 +8,7 @@
>>  #include 
>>  #include 
>>  
>> +#include 
>>  #include 
>>  #include 
>>  
>> @@ -196,10 +197,13 @@ void i915_ggtt_suspend_vm(struct i915_address_space 
>> *vm)
>>  
>>  void i915_ggtt_suspend(struct i915_ggtt *ggtt)
>>  {
>> +struct intel_gt *gt;
>> +
>>  i915_ggtt_suspend_vm(&ggtt->vm);
>>  ggtt->invalidate(ggtt);
>>  
>> -intel_gt_check_and_clear_faults(ggtt->vm.gt);
>> +list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
>> +intel_gt_check_and_clear_faults(gt);
>>  }
>>  
>>  void gen6_ggtt_invalidate(struct i915_ggtt *ggtt)
>> @@ -225,16 +229,21 @@ static void gen8_ggtt_invalidate(struct i915_ggtt 
>> *ggtt)
>>  
>>  static void guc_ggtt_invalidate(struct i915_ggtt *ggtt)
>>  {
>> -struct intel_uncore *uncore = ggtt->vm.gt->uncore;
>>  struct drm_i915_private *i915 = ggtt->vm.i915;
>>  
>>  gen8_ggtt_invalidate(ggtt);
>>  
>> -if (GRAPHICS_VER(i915) >= 12)
>> -intel_uncore_write_fw(uncore, GEN12_GUC_TLB_INV_CR,
>> -  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> -else
>> -intel_uncore_write_fw(uncore, GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +if (GRAPHICS_VER(i915) >= 12) {
>> +struct intel_gt *gt;
>> +
>> +list_for_each_entry(gt, &ggtt->gt_list, ggtt_link)
>> +intel_uncore_write_fw(gt->uncore,
>> +  GEN12_GUC_TLB_INV_CR,
>> +  GEN12_GUC_TLB_INV_CR_INVALIDATE);
>> +} else {
>> +intel_uncore_write_fw(ggtt->vm.gt->uncore,
>> +  GEN8_GTCR, GEN8_GTCR_INVALIDATE);
>> +}
>>  }
>>  
>>  u64 gen8_ggtt_pte_encode(dma_addr_t addr,
>> @@ -986,8 +995,6 @@ static int gen8_gmch_probe(struct i915_ggtt *ggtt)
>>  
>>  ggtt->vm.pte_encode = gen8_ggtt_pte_encode;
>>  
>> -setup_private_pat(ggtt->vm.gt);
>> -
>>  return ggtt_probe_common(ggtt, size);
>>  }
>>  
>> @@ -1196,7 +1203,14 @@ static int ggtt_probe_hw(struct i915_ggtt *ggtt, 
>> struct intel_gt *gt)
>>   */
>>  int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  {
>> -int ret;
>> +struct intel_gt *gt;
>> +int ret, i;
>> +
>> +for_each_gt(gt, i915, i) {
>> +ret = intel_gt_assign_ggtt(gt);
>> +if (ret)
>> +return ret;
>> +}
>>  
>>  ret = ggtt_probe_hw(to_gt(i915)->ggtt, to_gt(i915));
>>  if (ret)
>> @@ -1208,6 +1222,19 @@ int i915_ggtt_probe_hw(struct drm_i915_private *i915)
>>  return 0;
>>  }
>>  
>> +struct i915_ggtt *i915_ggtt_create(struct drm_i915_private *i915)
>> +{
>> +struct i915_ggtt *ggtt;
>> +
>> +ggtt = drmm_kzalloc(&i915->drm, sizeof(*ggtt), GFP_KERNEL);
>> +if (!ggtt)
>> +return ERR_PTR(-ENOMEM);
>> +
>> +INIT_LIST_HEAD(&ggtt->gt_list);
>> +
>> +return ggtt;
>> +}
>> +
>>  int i915_ggtt_enable_hw(struct drm_i915_private *i915)
>>  {
>>  if (GRAPHICS_VER(i915) < 6)
>> @@ -1296,9 +1323,11 @@ bool i915_ggtt_resume_vm(struct i915_address_space 
>> *vm)
>>  
>>  void i915_ggtt_resume(st

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Thomas Zimmermann]

Hi

Am 21.11.22 um 13:27 schrieb Noralf Trønnes:



Den 21.11.2022 11.45, skrev Thomas Zimmermann:

Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
drivers vmap/vunmap GEM buffer memory during the atomic commit.
Shadow-plane helpers automate this process.

Patches 1 to 4 prepare the MIPI code for the change and simplify
the restof the patchset.

Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
shadow-plane helpers. Most of the affected drivers call MIPI-DBI
helpers and get the update automatically. Only ili9225 and st7586
require changes to their source code.

Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
needed, but streamlines the driver code and make sense overall.

Testing is welcome, as I don't have any hardware to test these
changes myself.



I can do a test this weekend.


Thanks a lot.



Btw I've converted drm/gud to the shadow plane helper, I just need to
solve an smtp problem[1] so I can send out the patchset.


How so?  When I looked at it, the vmap/vunmap happened on a separate 
worker than the commit IIRC.


Best regards
Thomas



[1]
https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u

Noralf.


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Ivo Totev


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 0/8] drm/mipi-dbi: Convert to shadow-plane helpers

[Noralf Trønnes]

Den 21.11.2022 11.45, skrev Thomas Zimmermann:
> Convert the MIPI-DBI-based drivers to shadow-plane helpers. The
> drivers vmap/vunmap GEM buffer memory during the atomic commit.
> Shadow-plane helpers automate this process.
> 
> Patches 1 to 4 prepare the MIPI code for the change and simplify
> the restof the patchset.
> 
> Patches 5 to 7 rework the vmap code in the MIPI-DBI drivers and add
> shadow-plane helpers. Most of the affected drivers call MIPI-DBI
> helpers and get the update automatically. Only ili9225 and st7586
> require changes to their source code.
> 
> Patch 8 simplifies drm_dev_enter() and _exit(). It's not strictly
> needed, but streamlines the driver code and make sense overall.
> 
> Testing is welcome, as I don't have any hardware to test these
> changes myself.
> 

I can do a test this weekend.

Btw I've converted drm/gud to the shadow plane helper, I just need to
solve an smtp problem[1] so I can send out the patchset.

[1]
https://lore.kernel.org/dri-devel/1bc45775-0667-01f8-36e1-9f65d3081...@tronnes.org/T/#u

Noralf.

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Andrzej Hajda]

On 21.11.2022 11:59, Janusz Krzysztofik wrote:

On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:

Hi Andrzej,

Thanks for your comment.

On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:


On 21.11.2022 09:30, Janusz Krzysztofik wrote:

Hi Nimroy,

Thanks for looking at this.

On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:

On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:

Users of intel_gt_retire_requests_timeout() expect 0 return value on
success.  However, we have no protection from passing back 0 potentially
returned by a call to dma_fence_wait_timeout() when it succedes right
after its timeout has expired.

Replace 0 with -ETIME before potentially using the timeout value as return
code, so -ETIME is returned if there are still some requests not retired
after timeout, 0 otherwise.

v2: Move the added lines down so flush_submission() is not affected.

Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with

retire_request")

Signed-off-by: Janusz Krzysztofik 
Cc: sta...@vger.kernel.org # v5.5+
---
drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/

drm/i915/gt/intel_gt_requests.c

index edb881d756309..3ac4603eeb4ee 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
@@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
if (remaining_timeout)
*remaining_timeout = timeout;

+	if (!timeout)

+   timeout = -ETIME;

This will return error, -ETIME when 0 timeout is passed,
intel_gt_retire_requests().

Yes, but only when active_count is not 0 after we loop through
timelines->active_list calling retire_requests() on each and counting up
failures in active_count.


Moving this line just after the call to dma_fence_wait_timeout should
solve the controversy.


But that would break our need to pass 0, not -ETIME, to flush_submission() in
case the initial value of timeout was 0, as pointed out by Chris during our
discussion on v2.

Maybe an inline comment above the added lines that explains why we are doing
this could help?


How about not adding those two lines but modifying the return line instead?

-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;


Personally I would translate ret value from dma_fence* API ASAP, and 
call flush_submission conditionally - to limit coexistence of both APIs.

But this looks correct to me, as well.

Reviewed-by: Andrzej Hajda 

Regards
Andrzej



Would that be self explanatory?

Thanks,
Janusz



Thanks,
Janusz



Regards
Andrzej




We don't want that.

When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
to return 0 unconditionally, or are we rather interested if those calls to
retire_requests() succeeded?


I think you can use a separate variable to store
return val from the dma_fence_wait_timeout()


Regards,

Nirmoy


+
return active_count ? timeout : 0;

If active count is 0, we return 0 regardless of timeout value, and that's OK.
However, if active_count is not 0, we shouldn't return 0, I believe, we should
return either remaining time if some left, or error (-ETIME) if not.  If you
think I'm wrong, please explain why.

Thanks,
Janusz


}

Re: [PATCH] i2c: qcom-geni: fix error return code in geni_i2c_gpi_xfer

[Tommaso Merciai]

Hi Wang,

On Mon, Nov 21, 2022 at 06:17:52PM +0800, Wang Yufen wrote:
> Fix to return a negative error code from the gi2c->err instead of
> 0.
> 
> Fixes: d8703554f4de ("i2c: qcom-geni: Add support for GPI DMA")
> Signed-off-by: Wang Yufen 
> ---
>  drivers/i2c/busses/i2c-qcom-geni.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/drivers/i2c/busses/i2c-qcom-geni.c 
> b/drivers/i2c/busses/i2c-qcom-geni.c
> index 84a7751..8fce98b 100644
> --- a/drivers/i2c/busses/i2c-qcom-geni.c
> +++ b/drivers/i2c/busses/i2c-qcom-geni.c
> @@ -626,7 +626,6 @@ static int geni_i2c_gpi_xfer(struct geni_i2c_dev *gi2c, 
> struct i2c_msg msgs[], i
>   dev_err(gi2c->se.dev, "I2C timeout gpi flags:%d 
> addr:0x%x\n",
>   gi2c->cur->flags, gi2c->cur->addr);
>   gi2c->err = -ETIMEDOUT;
> - goto err;


Looks good to me.
Reviewed-by: Tommaso Merciai 

Regards,
Tommaso

>   }
>  
>   if (gi2c->err) {
> -- 
> 1.8.3.1
> 

-- 
Tommaso Merciai
Embedded Linux Engineer
tommaso.merc...@amarulasolutions.com
__

Amarula Solutions SRL
Via Le Canevare 30, 31100 Treviso, Veneto, IT
T. +39 042 243 5310
i...@amarulasolutions.com
www.amarulasolutions.com

Re: [PATCH 3/5] kobject: kset_uevent_ops: make filter() callback take a const *

[Rafael J. Wysocki]

On Mon, Nov 21, 2022 at 10:47 AM Greg Kroah-Hartman
 wrote:
>
> The filter() callback in struct kset_uevent_ops does not modify the
> kobject passed into it, so make the pointer const to enforce this
> restriction.  When doing so, fix up all existing filter() callbacks to
> have the correct signature to preserve the build.
>
> Cc: "Rafael J. Wysocki" 
> Cc: Sumit Semwal 
> Cc: "Christian König" 
> Cc: linux-me...@vger.kernel.org
> Cc: dri-devel@lists.freedesktop.org
> Cc: linaro-mm-...@lists.linaro.org
> Signed-off-by: Greg Kroah-Hartman 

Acked-by: Rafael J. Wysocki 

> ---
>  drivers/base/bus.c| 2 +-
>  drivers/base/core.c   | 4 ++--
>  drivers/dma-buf/dma-buf-sysfs-stats.c | 2 +-
>  include/linux/kobject.h   | 2 +-
>  kernel/params.c   | 2 +-
>  5 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/base/bus.c b/drivers/base/bus.c
> index 7ca47e5b3c1f..4ec6dbab73be 100644
> --- a/drivers/base/bus.c
> +++ b/drivers/base/bus.c
> @@ -163,7 +163,7 @@ static struct kobj_type bus_ktype = {
> .release= bus_release,
>  };
>
> -static int bus_uevent_filter(struct kobject *kobj)
> +static int bus_uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> diff --git a/drivers/base/core.c b/drivers/base/core.c
> index a79b99ecf4d8..005a2b092f3e 100644
> --- a/drivers/base/core.c
> +++ b/drivers/base/core.c
> @@ -2362,12 +2362,12 @@ static struct kobj_type device_ktype = {
>  };
>
>
> -static int dev_uevent_filter(struct kobject *kobj)
> +static int dev_uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> if (ktype == &device_ktype) {
> -   struct device *dev = kobj_to_dev(kobj);
> +   const struct device *dev = kobj_to_dev(kobj);
> if (dev->bus)
> return 1;
> if (dev->class)
> diff --git a/drivers/dma-buf/dma-buf-sysfs-stats.c 
> b/drivers/dma-buf/dma-buf-sysfs-stats.c
> index 2bba0babcb62..f69d68122b9b 100644
> --- a/drivers/dma-buf/dma-buf-sysfs-stats.c
> +++ b/drivers/dma-buf/dma-buf-sysfs-stats.c
> @@ -132,7 +132,7 @@ void dma_buf_stats_teardown(struct dma_buf *dmabuf)
>
>
>  /* Statistics files do not need to send uevents. */
> -static int dmabuf_sysfs_uevent_filter(struct kobject *kobj)
> +static int dmabuf_sysfs_uevent_filter(const struct kobject *kobj)
>  {
> return 0;
>  }
> diff --git a/include/linux/kobject.h b/include/linux/kobject.h
> index 5a2d58e10bf5..640f59d4b3de 100644
> --- a/include/linux/kobject.h
> +++ b/include/linux/kobject.h
> @@ -135,7 +135,7 @@ struct kobj_uevent_env {
>  };
>
>  struct kset_uevent_ops {
> -   int (* const filter)(struct kobject *kobj);
> +   int (* const filter)(const struct kobject *kobj);
> const char *(* const name)(struct kobject *kobj);
> int (* const uevent)(struct kobject *kobj, struct kobj_uevent_env 
> *env);
>  };
> diff --git a/kernel/params.c b/kernel/params.c
> index 5b92310425c5..d2237209ceda 100644
> --- a/kernel/params.c
> +++ b/kernel/params.c
> @@ -926,7 +926,7 @@ static const struct sysfs_ops module_sysfs_ops = {
> .store = module_attr_store,
>  };
>
> -static int uevent_filter(struct kobject *kobj)
> +static int uevent_filter(const struct kobject *kobj)
>  {
> const struct kobj_type *ktype = get_ktype(kobj);
>
> --
> 2.38.1
>

git send-email friendly smtp provider anyone?

[Noralf Trønnes]

Hi

A couple of years ago my email provider blocked me from using git
send-email with their smtp server. So I switched to the one my ISP
provides. Now my ISP have outsourced their email service so the first 3
emails gets through and the rest looks like it ends up in a tar pit or
something, 18 hours later and 5 of 7 emails have gotten through. I have
asked them about this, but I fear the answer will be this is not
supported since they now don't have the service in-house anymore. I'm
waiting for a reply.

Today I tried sendinblue.com since they have a free plan, but they
insert  in the emails so that didn't work out. They also have some
kind of queue, after 1 hour 6 of 7 emails have gotten through.

Does anyone have an smtp provider to recommend that works with git
send-email and that sends out all the emails at once?

I have a patchset that I want to send out.

Noralf.

[PATCH] drm/i915/selftests: Fix error return code in live_parallel_switch()

[Ziyang Xuan]

In live_parallel_switch(), excute intel_context_create() failed,
the error code should be set before return from error handling path.

Fixes: 50d16d44cce4 ("drm/i915/selftests: Exercise context switching in 
parallel")
Signed-off-by: Ziyang Xuan 
---
 drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c 
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index c6ad67b90e8a..960ad65e5300 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -335,8 +335,10 @@ static int live_parallel_switch(void *arg)
continue;
 
ce = intel_context_create(data[m].ce[0]->engine);
-   if (IS_ERR(ce))
+   if (IS_ERR(ce)) {
+   err = PTR_ERR(ce);
goto out;
+   }
 
err = intel_context_pin(ce);
if (err) {
-- 
2.25.1

Re: [PATCH] drm/vc4: Fix NULL pointer access in vc4_platform_drm_probe()

[Dave Stevenson]

Hi Lino

On Sun, 20 Nov 2022 at 15:26, Lino Sanfilippo  wrote:
>
> From: Lino Sanfilippo 
>
> In vc4_platform_drm_probe() function vc4_match_add_drivers() is called to
> find component matches for the component drivers. If no such match is found
> the passed variable "match" is still NULL after the function returns.

This would imply a very strange device tree that has bothered to add
the drm device but none of the devices that are required to run the
DRM pipeline, but avoiding a NULL deref is certainly preferable.

> Do not pass "match" to component_master_add_with_match() in this case since
> this results in a NULL pointer access as soon as match->num is used to
> allocate a component_match array. Instead return with -ENODEV from the
> drivers probe function.
>
> Fixes: c8b75bca92cb ("drm/vc4: Add KMS support for Raspberry Pi.")
> Cc: sta...@vger.kernel.org
> Signed-off-by: Lino Sanfilippo 

Acked-by: Dave Stevenson 

> ---
>  drivers/gpu/drm/vc4/vc4_drv.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
> index 2027063fdc30..2e53d7f8ad44 100644
> --- a/drivers/gpu/drm/vc4/vc4_drv.c
> +++ b/drivers/gpu/drm/vc4/vc4_drv.c
> @@ -437,6 +437,9 @@ static int vc4_platform_drm_probe(struct platform_device 
> *pdev)
> vc4_match_add_drivers(dev, &match,
>   component_drivers, 
> ARRAY_SIZE(component_drivers));
>
> +   if (!match)
> +   return -ENODEV;
> +
> return component_master_add_with_match(dev, &vc4_drm_ops, match);
>  }
>
>
> base-commit: 30a0b95b1335e12efef89dd78518ed3e4a71a763
> --
> 2.36.1
>

Re: [PATCH 593/606] backlight: tosa: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:27PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 592/606] backlight: lv5207lp: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:26PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 591/606] backlight: lp855x: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:25PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> .probe_new() doesn't get the i2c_device_id * parameter, so determine
> that explicitly in the probe function.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 590/606] backlight: lm3639: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:24PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH AUTOSEL 6.0 38/44] drm/amdgpu: Unlock bo_list_mutex after error handling

[Christian König]

Am 21.11.22 um 10:57 schrieb Michel Dänzer:

On 11/19/22 03:11, Sasha Levin wrote:

From: Philip Yang 

[ Upstream commit 64f65135c41a75f933d3bca236417ad8e9eb75de ]

Get below kernel WARNING backtrace when pressing ctrl-C to kill kfdtest
application.

If amdgpu_cs_parser_bos returns error after taking bo_list_mutex, as
caller amdgpu_cs_ioctl will not unlock bo_list_mutex, this generates the
kernel WARNING.

Add unlock bo_list_mutex after amdgpu_cs_parser_bos error handling to
cleanup bo_list userptr bo.

  WARNING: kfdtest/2930 still has locks held!
  1 lock held by kfdtest/2930:
   (&list->bo_list_mutex){+.+.}-{3:3}, at: amdgpu_cs_ioctl+0xce5/0x1f10 [amdgpu]
   stack backtrace:
dump_stack_lvl+0x44/0x57
get_signal+0x79f/0xd00
arch_do_signal_or_restart+0x36/0x7b0
exit_to_user_mode_prepare+0xfd/0x1b0
syscall_exit_to_user_mode+0x19/0x40
do_syscall_64+0x40/0x80

Signed-off-by: Philip Yang 
Reviewed-by: Christian König 
Signed-off-by: Alex Deucher 
Signed-off-by: Sasha Levin 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
index b7bae833c804..9d59f83c8faa 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -655,6 +655,7 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser *p,
}
mutex_unlock(&p->bo_list->bo_list_mutex);
}
+   mutex_unlock(&p->bo_list->bo_list_mutex);
return r;
  }
  

Looks doubtful that this is a correct backport — there's an identical 
mutex_unlock call just above.



Oh, yes good point. This patch doesn't needs to be backported at all 
because it just fixes a problem introduced in the same cycle:


commit 4953b6b22ab9d7f64706631a027b1ed1130ce4c8
Author: Christian König 
Date:   Tue Sep 13 09:52:13 2022 +0200

    drm/amdgpu: cleanup error handling in amdgpu_cs_parser_bos

    Return early on success and so remove all those "if (r)" in the error
    path.

    Signed-off-by: Christian König 
    Reviewed-by: Alex Deucher 
    Signed-off-by: Alex Deucher 

Regards,
Christian.

Re: [PATCH v3 0/6] dt-bindings: Add macros for video interface bus types

[Laurent Pinchart]

Hi Sakari,

On Mon, Nov 21, 2022 at 10:54:01AM +, Sakari Ailus wrote:
> On Sat, Nov 19, 2022 at 09:15:04PM +0200, Laurent Pinchart wrote:
> > On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> > > On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wrote:
> > > > Folks,
> > > > 
> > > > > Laurent Pinchart (6):
> > > > >   dt-bindings: media: Add macros for video interface bus types
> > > > >   dt-bindings: Use new video interface bus type macros in examples
> > > > >   ARM: dts: freescale: Use new media bus type macros
> > > > >   ARM: dts: omap: Use new media bus type macros
> > > > >   ARM: dts: renesas: Use new media bus type macros
> > > > >   ARM: dts: stm32: Use new media bus type macros
> > > > 
> > > > What's the preference on the tree through which these would be merged?
> > > > 
> > > > The two first should probably go through the media tree but what about 
> > > > the
> > > > DTS? There's a dependency to the first patch. I can take these all if
> > > > people are fine with that.
> > > 
> > > How is this going?
> > 
> > Sakari, if there's a concern taking patches 3/6 to 6/6 in the media
> > tree, could you merge 1/6 and 2/6 ? If they can still be included in a
> > pull request for v6.2, I'll work on getting the dts changes in v6.3
> > through their respective trees.
> 
> I think I was expecting v4 from you. But I can address the comments, too,
> they were minor matters.

That would be nice :-) Could it still be done for v6.2 ?

> For applying the DTS patches I'd like to have ack from respective
> treemaintainers it's fine to take these through the media tree.

Works for me, this can be done in v6.3.

-- 
Regards,

Laurent Pinchart

Re: [PATCH 589/606] backlight: lm3630a: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:23PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH 588/606] backlight: bd6107: Convert to i2c's .probe_new()

[Daniel Thompson]

On Fri, Nov 18, 2022 at 11:45:22PM +0100, Uwe Kleine-König wrote:
> From: Uwe Kleine-König 
>
> The probe function doesn't make use of the i2c_device_id * parameter so it
> can be trivially converted.
>
> Signed-off-by: Uwe Kleine-König 

Reviewed-by: Daniel Thompson 


Daniel.

Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

On Monday, 21 November 2022 11:51:15 CET Janusz Krzysztofik wrote:
> Hi Andrzej,
> 
> Thanks for your comment.
> 
> On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> > 
> > On 21.11.2022 09:30, Janusz Krzysztofik wrote:
> > > Hi Nimroy,
> > >
> > > Thanks for looking at this.
> > >
> > > On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> > >> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> > >>> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> > >>> success.  However, we have no protection from passing back 0 potentially
> > >>> returned by a call to dma_fence_wait_timeout() when it succedes right
> > >>> after its timeout has expired.
> > >>>
> > >>> Replace 0 with -ETIME before potentially using the timeout value as 
> > >>> return
> > >>> code, so -ETIME is returned if there are still some requests not retired
> > >>> after timeout, 0 otherwise.
> > >>>
> > >>> v2: Move the added lines down so flush_submission() is not affected.
> > >>>
> > >>> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
> > > retire_request")
> > >>> Signed-off-by: Janusz Krzysztofik 
> > >>> Cc: sta...@vger.kernel.org # v5.5+
> > >>> ---
> > >>>drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> > >>>1 file changed, 3 insertions(+)
> > >>>
> > >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
> > > drm/i915/gt/intel_gt_requests.c
> > >>> index edb881d756309..3ac4603eeb4ee 100644
> > >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> > >>> @@ -199,6 +199,9 @@ out_active: spin_lock(&timelines->lock);
> > >>> if (remaining_timeout)
> > >>> *remaining_timeout = timeout;
> > >>>
> > >>> +   if (!timeout)
> > >>> +   timeout = -ETIME;
> > >> This will return error, -ETIME when 0 timeout is passed,
> > >> intel_gt_retire_requests().
> > > Yes, but only when active_count is not 0 after we loop through
> > > timelines->active_list calling retire_requests() on each and counting up
> > > failures in active_count.
> > 
> > Moving this line just after the call to dma_fence_wait_timeout should 
> > solve the controversy.
> 
> But that would break our need to pass 0, not -ETIME, to flush_submission() in 
> case the initial value of timeout was 0, as pointed out by Chris during our 
> discussion on v2.
> 
> Maybe an inline comment above the added lines that explains why we are doing 
> this could help?

How about not adding those two lines but modifying the return line instead?

-   return active_count ? timeout : 0;
+   return active_count ? timeout ?: -ETIME : 0;

Would that be self explanatory?

Thanks,
Janusz

> 
> Thanks,
> Janusz
> 
> > 
> > Regards
> > Andrzej
> > 
> > >
> > >> We don't want that.
> > > When 0 timeout is passed to intel_gt_retire_requests(), do we really want 
> > > it
> > > to return 0 unconditionally, or are we rather interested if those calls to
> > > retire_requests() succeeded?
> > >
> > >> I think you can use a separate variable to store
> > >> return val from the dma_fence_wait_timeout()
> > >>
> > >>
> > >> Regards,
> > >>
> > >> Nirmoy
> > >>
> > >>> +
> > >>> return active_count ? timeout : 0;
> > > If active count is 0, we return 0 regardless of timeout value, and that's 
> > > OK.
> > > However, if active_count is not 0, we shouldn't return 0, I believe, we 
> > > should
> > > return either remaining time if some left, or error (-ETIME) if not.  If 
> > > you
> > > think I'm wrong, please explain why.
> > >
> > > Thanks,
> > > Janusz
> > >
> > >>>}
> > >>>
> > >
> > >
> > >
> > 
> > 
> 
> 

Re: [PATCH v3 0/6] dt-bindings: Add macros for video interface bus types

[Sakari Ailus]

Hi Laurent,

On Sat, Nov 19, 2022 at 09:15:04PM +0200, Laurent Pinchart wrote:
> Hello,
> 
> On Fri, Nov 18, 2022 at 06:23:38PM +0900, Paul Elder wrote:
> > Hi Sakari,
> > 
> > Gentle ping.
> > 
> > On Sun, Jul 17, 2022 at 06:54:00AM +, Sakari Ailus wrote:
> > > Folks,
> > > 
> > > > Laurent Pinchart (6):
> > > >   dt-bindings: media: Add macros for video interface bus types
> > > >   dt-bindings: Use new video interface bus type macros in examples
> > > >   ARM: dts: freescale: Use new media bus type macros
> > > >   ARM: dts: omap: Use new media bus type macros
> > > >   ARM: dts: renesas: Use new media bus type macros
> > > >   ARM: dts: stm32: Use new media bus type macros
> > > 
> > > What's the preference on the tree through which these would be merged?
> > > 
> > > The two first should probably go through the media tree but what about the
> > > DTS? There's a dependency to the first patch. I can take these all if
> > > people are fine with that.
> > 
> > How is this going?
> 
> Sakari, if there's a concern taking patches 3/6 to 6/6 in the media
> tree, could you merge 1/6 and 2/6 ? If they can still be included in a
> pull request for v6.2, I'll work on getting the dts changes in v6.3
> through their respective trees.

I think I was expecting v4 from you. But I can address the comments, too,
they were minor matters.

For applying the DTS patches I'd like to have ack from respective
treemaintainers it's fine to take these through the media tree.

-- 
Kind regards,

Sakari Ailus

Re: [PATCH v2 2/2] drm/i915: Never return 0 if not all requests retired

[Janusz Krzysztofik]

Hi Andrzej,

Thanks for your comment.

On Monday, 21 November 2022 11:17:42 CET Andrzej Hajda wrote:
> 
> On 21.11.2022 09:30, Janusz Krzysztofik wrote:
> > Hi Nimroy,
> >
> > Thanks for looking at this.
> >
> > On Friday, 18 November 2022 20:56:50 CET Das, Nirmoy wrote:
> >> On 11/18/2022 11:42 AM, Janusz Krzysztofik wrote:
> >>> Users of intel_gt_retire_requests_timeout() expect 0 return value on
> >>> success.  However, we have no protection from passing back 0 potentially
> >>> returned by a call to dma_fence_wait_timeout() when it succedes right
> >>> after its timeout has expired.
> >>>
> >>> Replace 0 with -ETIME before potentially using the timeout value as return
> >>> code, so -ETIME is returned if there are still some requests not retired
> >>> after timeout, 0 otherwise.
> >>>
> >>> v2: Move the added lines down so flush_submission() is not affected.
> >>>
> >>> Fixes: f33a8a51602c ("drm/i915: Merge wait_for_timelines with
> > retire_request")
> >>> Signed-off-by: Janusz Krzysztofik 
> >>> Cc: sta...@vger.kernel.org # v5.5+
> >>> ---
> >>>drivers/gpu/drm/i915/gt/intel_gt_requests.c | 3 +++
> >>>1 file changed, 3 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/gt/intel_gt_requests.c b/drivers/gpu/
> > drm/i915/gt/intel_gt_requests.c
> >>> index edb881d756309..3ac4603eeb4ee 100644
> >>> --- a/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >>> +++ b/drivers/gpu/drm/i915/gt/intel_gt_requests.c
> >>> @@ -199,6 +199,9 @@ out_active:   spin_lock(&timelines->lock);
> >>>   if (remaining_timeout)
> >>>   *remaining_timeout = timeout;
> >>>
> >>> + if (!timeout)
> >>> + timeout = -ETIME;
> >> This will return error, -ETIME when 0 timeout is passed,
> >> intel_gt_retire_requests().
> > Yes, but only when active_count is not 0 after we loop through
> > timelines->active_list calling retire_requests() on each and counting up
> > failures in active_count.
> 
> Moving this line just after the call to dma_fence_wait_timeout should 
> solve the controversy.

But that would break our need to pass 0, not -ETIME, to flush_submission() in 
case the initial value of timeout was 0, as pointed out by Chris during our 
discussion on v2.

Maybe an inline comment above the added lines that explains why we are doing 
this could help?

Thanks,
Janusz

> 
> Regards
> Andrzej
> 
> >
> >> We don't want that.
> > When 0 timeout is passed to intel_gt_retire_requests(), do we really want it
> > to return 0 unconditionally, or are we rather interested if those calls to
> > retire_requests() succeeded?
> >
> >> I think you can use a separate variable to store
> >> return val from the dma_fence_wait_timeout()
> >>
> >>
> >> Regards,
> >>
> >> Nirmoy
> >>
> >>> +
> >>>   return active_count ? timeout : 0;
> > If active count is 0, we return 0 regardless of timeout value, and that's 
> > OK.
> > However, if active_count is not 0, we shouldn't return 0, I believe, we 
> > should
> > return either remaining time if some left, or error (-ETIME) if not.  If you
> > think I'm wrong, please explain why.
> >
> > Thanks,
> > Janusz
> >
> >>>}
> >>>
> >
> >
> >
> 
>