Re: [RFC PATCH 0/3] Support for Solid Fill Planes

[Pekka Paalanen]

On Wed, 28 Jun 2023 09:40:21 -0700
Jessica Zhang  wrote:

> On 6/28/2023 12:34 AM, Pekka Paalanen wrote:
> > On Tue, 27 Jun 2023 15:10:19 -0700
> > Abhinav Kumar  wrote:
> >   
> >> On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:  
> >>> On 28/06/2023 00:27, Jessica Zhang wrote:  
> 
> 
>  On 6/27/2023 12:58 AM, Pekka Paalanen wrote:  
> > On Mon, 26 Jun 2023 16:02:50 -0700
> > Jessica Zhang  wrote:
> > 
> >> On 11/7/2022 11:37 AM, Ville Syrjälä wrote:  
> >>> On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:  
>  Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
>  properties. When the color fill value is set, and the framebuffer
>  is set
>  to NULL, memory fetch will be disabled.  
> >>>
> >>> Thinking a bit more universally I wonder if there should be
> >>> some kind of enum property:
> >>>
> >>> enum plane_pixel_source {
> >>>  FB,
> >>>  COLOR,
> >>>  LIVE_FOO,
> >>>  LIVE_BAR,
> >>>  ...
> >>> }  
> >>
> >> Reviving this thread as this was the initial comment suggesting to
> >> implement pixel_source as an enum.
> >>
> >> I think the issue with having pixel_source as an enum is how to decide
> >> what counts as a NULL commit.
> >>
> >> Currently, setting the FB to NULL will disable the plane. So I'm
> >> guessing we will extend that logic to "if there's no pixel_source set
> >> for the plane, then it will be a NULL commit and disable the plane".
> >>
> >> In that case, the question then becomes when to set the pixel_source to
> >> NONE. Because if we do that when setting a NULL FB (or NULL solid_fill
> >> blob), it then forces userspace to set one property before the other.  
> >
> > Right, that won't work.
> >
> > There is no ordering between each property being set inside a single
> > atomic commit. They can all be applied to kernel-internal state
> > theoretically simultaneously, or any arbitrary random order, and the
> > end result must always be the same. Hence, setting one property cannot
> > change the state of another mutable property. I believe that doing
> > otherwise would make userspace fragile and hard to get right.
> >
> > I guess there might be an exception to that rule when the same property
> > is set multiple times in a single atomic commit; the last setting in
> > the array prevails. That's universal and not a special-case between two
> > specific properties.
> > 
> >> Because of that, I'm thinking of having pixel_source be represented
> >> by a
> >> bitmask instead. That way, we will simply unset the corresponding
> >> pixel_source bit when passing in a NULL FB/solid_fill blob. Then, in
> >> order to detect whether a commit is NULL or has a valid pixel
> >> source, we
> >> can just check if pixel_source == 0.  
> >
> > Sounds fine to me at first hand, but isn't there the enum property that
> > says if the kernel must look at solid_fill blob *or* FB_ID?
> >
> > If enum prop says "use solid_fill prop", the why would changes to FB_ID
> > do anything? Is it for backwards-compatibility with KMS clients that do
> > not know about the enum prop?
> >
> > It seems like that kind of backwards-compatiblity will cause problems
> > in trying to reason about the atomic state, as explained above, leading
> > to very delicate and fragile conditions where things work intuitively.
> > Hence, I'm not sure backwards-compatibility is wanted. This won't be
> > the first or the last KMS property where an unexpected value left over
> > will make old atomic KMS clients silently malfunction up to showing no
> > recognisable picture at all. *If* that problem needs solving, there
> > have been ideas floating around about resetting everything to nice
> > values so that userspace can ignore what it does not understand. So far
> > there has been no real interest in solving that problem in the kernel
> > though.
> >
> > Legacy non-atomic UAPI wrappers can do whatever they want, and program
> > any (new) properties they want in order to implement the legacy
> > expectations, so that does not seem to be a problem.  
> 
>  Hi Pekka and Dmitry,
> 
>  After reading through both of your comments, I think I have a better
>  understanding of the pixel_source implementation now.
> 
>  So to summarize, we want to expose another property called
>  "pixel_source" to userspace that will default to FB (as to not break
>  legacy userspace).
> 
>  If userspace wants to use solid fill planes, it will set both the
>  solid_fill *and* pixel_source properties to a valid blob and COLOR
>  respectively. If it wants to use FB, it will set FB_ID and
>  pixel_source to a valid FB and FB.
> >>

Re: [RFC v2 0/3] Introduce KUnit tests for TTM subsystem

[Christian König]

Sorry for the delayed response, AMD had some mail server issues and I 
simply missed this through the web access interface.


Going to take a look at this now,
Christian.

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

This series introduces KUnit[1] tests for TTM (Translation Table Manager)
subsystem, a memory manager used by graphics drivers to create and manage
memory buffers across different memory domains, such as system memory
or VRAM.

Unit tests implemented here cover two data structures:
   - ttm_device -- referred as a buffer object device, which stores
 resource managers and page pools
   - ttm_pool -- a struct of pools (ttm_pool_type) of different page
 orders and caching attributes, with pages that can be reused on
 the next buffer allocation

Use kunit_tool script to manually run the tests:

$ ./tools/testing/kunit/kunit.py run --kunitconfig=drivers/gpu/drm/ttm/tests

The kunit tool might not work with older python versions. To fix that,
apply [2] patch.

To build a kernel with TTM KUnit tests, enable CONFIG_DRM_TTM_KUNIT_TEST
symbol.

As for now, tests are architecture-agnostic (i.e. KUnit runner uses UML
kernel), which means that we have limited coverage in some places. For
example, we can't fully test the initialization of global page pools,
such as global_write_combined. It is to be decided if we want to stick
to UML or use CONFIG_X86 (at least to some extent).

These patches are just a beginning of the work to improve the test
coverage of TTM. Feel free to suggest changes, test cases or priorities.

Many thanks,
Karolina

v2:
   - Add missing symbol exports in ttm_kunit_helpers.c
   - Update helpers include to fix compilation issues (didn't catch it as
 KUnit tests weren't enabled in the kernel I tested, an oversight
 on my part)
   - Add checks for ttm_pool fields in ttm_pool_alloc_basic(), including the
 one for NUMA node id
   - Rebase the changes on the top of drm-tip


[1] - https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
[2] - https://lore.kernel.org/lkml/20230610175618.82271-1...@kernel.org/T/

Karolina Stolarek (3):
   drm/ttm: Introduce KUnit tests
   drm/ttm/tests: Add tests for ttm_device
   drm/ttm/tests: Add tests for ttm_pool

  drivers/gpu/drm/Kconfig   |  15 +
  drivers/gpu/drm/ttm/Makefile  |   1 +
  drivers/gpu/drm/ttm/tests/.kunitconfig|   4 +
  drivers/gpu/drm/ttm/tests/Makefile|   6 +
  drivers/gpu/drm/ttm/tests/ttm_device_test.c   | 213 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  88 
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |  34 ++
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 406 ++
  8 files changed, 767 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/.kunitconfig
  create mode 100644 drivers/gpu/drm/ttm/tests/Makefile
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_device_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_pool_test.c

Re: [RFC v2 0/3] Introduce KUnit tests for TTM subsystem

[Karolina Stolarek]

On 29.06.2023 09:39, Christian König wrote:
Sorry for the delayed response, AMD had some mail server issues and I 
simply missed this through the web access interface.


No worries, that gave me an opportunity to fix my series :)

All the best,
Karolina



Going to take a look at this now,
Christian.

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

This series introduces KUnit[1] tests for TTM (Translation Table Manager)
subsystem, a memory manager used by graphics drivers to create and manage
memory buffers across different memory domains, such as system memory
or VRAM.

Unit tests implemented here cover two data structures:
   - ttm_device -- referred as a buffer object device, which stores
 resource managers and page pools
   - ttm_pool -- a struct of pools (ttm_pool_type) of different page
 orders and caching attributes, with pages that can be reused on
 the next buffer allocation

Use kunit_tool script to manually run the tests:

$ ./tools/testing/kunit/kunit.py run 
--kunitconfig=drivers/gpu/drm/ttm/tests


The kunit tool might not work with older python versions. To fix that,
apply [2] patch.

To build a kernel with TTM KUnit tests, enable CONFIG_DRM_TTM_KUNIT_TEST
symbol.

As for now, tests are architecture-agnostic (i.e. KUnit runner uses UML
kernel), which means that we have limited coverage in some places. For
example, we can't fully test the initialization of global page pools,
such as global_write_combined. It is to be decided if we want to stick
to UML or use CONFIG_X86 (at least to some extent).

These patches are just a beginning of the work to improve the test
coverage of TTM. Feel free to suggest changes, test cases or priorities.

Many thanks,
Karolina

v2:
   - Add missing symbol exports in ttm_kunit_helpers.c
   - Update helpers include to fix compilation issues (didn't catch it as
 KUnit tests weren't enabled in the kernel I tested, an oversight
 on my part)
   - Add checks for ttm_pool fields in ttm_pool_alloc_basic(), 
including the

 one for NUMA node id
   - Rebase the changes on the top of drm-tip


[1] - https://www.kernel.org/doc/html/latest/dev-tools/kunit/index.html
[2] - 
https://lore.kernel.org/lkml/20230610175618.82271-1...@kernel.org/T/


Karolina Stolarek (3):
   drm/ttm: Introduce KUnit tests
   drm/ttm/tests: Add tests for ttm_device
   drm/ttm/tests: Add tests for ttm_pool

  drivers/gpu/drm/Kconfig   |  15 +
  drivers/gpu/drm/ttm/Makefile  |   1 +
  drivers/gpu/drm/ttm/tests/.kunitconfig    |   4 +
  drivers/gpu/drm/ttm/tests/Makefile    |   6 +
  drivers/gpu/drm/ttm/tests/ttm_device_test.c   | 213 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  88 
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |  34 ++
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 406 ++
  8 files changed, 767 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/.kunitconfig
  create mode 100644 drivers/gpu/drm/ttm/tests/Makefile
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_device_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_pool_test.c

Re: [RFC v2 1/3] drm/ttm: Introduce KUnit tests

[Christian König]

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Add the initial version of unit tests for ttm_device struct, together
with helper functions.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/Kconfig   | 15 +
  drivers/gpu/drm/ttm/Makefile  |  1 +
  drivers/gpu/drm/ttm/tests/.kunitconfig|  4 ++
  drivers/gpu/drm/ttm/tests/Makefile|  5 ++
  drivers/gpu/drm/ttm/tests/ttm_device_test.c   | 54 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 59 +++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 29 +
  7 files changed, 167 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/.kunitconfig
  create mode 100644 drivers/gpu/drm/ttm/tests/Makefile
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_device_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..53024e44a2d5 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -194,6 +194,21 @@ config DRM_TTM
  GPU memory types. Will be enabled automatically if a device driver
  uses it.
  
+config DRM_TTM_KUNIT_TEST

+tristate "KUnit tests for TTM" if !KUNIT_ALL_TESTS
+default n
+depends on DRM && KUNIT
+select DRM_TTM
+select DRM_EXPORT_FOR_TESTS if m
+select DRM_KUNIT_TEST_HELPERS
+default KUNIT_ALL_TESTS
+help
+  Enables unit tests for TTM, a GPU memory manager subsystem used
+  to manage memory buffers. This option is mostly useful for kernel
+  developers.
+
+  If in doubt, say "N".
+
  config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index f906b22959cf..dad298127226 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -8,3 +8,4 @@ ttm-y := ttm_tt.o ttm_bo.o ttm_bo_util.o ttm_bo_vm.o 
ttm_module.o \
  ttm-$(CONFIG_AGP) += ttm_agp_backend.o
  
  obj-$(CONFIG_DRM_TTM) += ttm.o

+obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += tests/
diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig 
b/drivers/gpu/drm/ttm/tests/.kunitconfig
new file mode 100644
index ..75fdce0cd98e
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_KUNIT_TEST_HELPERS=y
+CONFIG_DRM_TTM_KUNIT_TEST=y
diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
new file mode 100644
index ..7917805f37af
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0 AND MIT
+
+obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
+ttm_device_test.o \
+ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
new file mode 100644
index ..08d7314b1e35
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+static void ttm_device_init_basic(struct kunit *test)
+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   struct ttm_device *ttm_dev;
+   struct ttm_resource_manager *ttm_sys_man;
+   int err;
+
+   ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+   err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   KUNIT_EXPECT_PTR_EQ(test, ttm_dev->funcs, &ttm_dev_funcs);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_dev->wq);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_dev->man_drv[TTM_PL_SYSTEM]);
+
+   ttm_sys_man = &ttm_dev->sysman;
+   KUNIT_ASSERT_NOT_NULL(test, ttm_sys_man);
+   KUNIT_EXPECT_TRUE(test, ttm_sys_man->use_tt);
+   KUNIT_EXPECT_TRUE(test, ttm_sys_man->use_type);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_sys_man->func);
+
+   KUNIT_EXPECT_PTR_EQ(test, ttm_dev->dev_mapping,
+   priv->drm->anon_inode->i_mapping);
+
+   ttm_device_fini(ttm_dev);
+}
+
+static struct kunit_case ttm_device_test_cases[] = {
+   KUNIT_CASE(ttm_device_init_basic),
+   {}
+};
+
+static struct kunit_suite ttm_device_test_suite = {
+   .name = "ttm_device",
+   .init = ttm_test_devices_init,
+   .exit = ttm_test_devices_fini,
+   .test_cases = ttm_device_test_cases,
+};
+
+kunit_test_suites(&ttm_device_test_suite);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
new file mode 100644
index ..d03db0405484
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -0,0 +1,59 @@
+// SPDX-L

Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

[Pekka Paalanen]

On Wed, 28 Jun 2023 19:54:49 +
Zack Rusin  wrote:

> On Wed, 2023-06-28 at 10:54 +0300, Pekka Paalanen wrote:
> > On Wed, 28 Jun 2023 10:41:06 +0300
> > Pekka Paalanen  wrote:
> >   
> > > On Wed, 28 Jun 2023 01:21:27 -0400
> > > Zack Rusin  wrote:
> > >   
> > > > From: Zack Rusin 
> > > > 
> > > > Atomic modesetting code lacked support for specifying mouse cursor
> > > > hotspots. The legacy kms DRM_IOCTL_MODE_CURSOR2 had support for setting
> > > > the hotspot but the functionality was not implemented in the new atomic
> > > > paths.
> > > > 
> > > > Due to the lack of hotspots in the atomic paths userspace compositors
> > > > completely disable atomic modesetting for drivers that require it (i.e.
> > > > all paravirtualized drivers).
> > > > 
> > > > This change adds hotspot properties to the atomic codepaths throughtout
> > > > the DRM core and will allow enabling atomic modesetting for virtualized
> > > > drivers in the userspace.
> > > > 
> > > > Signed-off-by: Zack Rusin 
> > > > Cc: Maarten Lankhorst 
> > > > Cc: Maxime Ripard 
> > > > Cc: Thomas Zimmermann 
> > > > Cc: David Airlie 
> > > > Cc: Daniel Vetter 
> > > > Reviewed-by: Javier Martinez Canillas     
> > > 
> > > Hi Zack,
> > > 
> > > I still do not see any UAPI docs for the new properties in this patch?  
> > 
> > If you are wondering what there could be to write about, maybe this can
> > give a good mindset:
> > 
> > Let's assume that I am a Wayland compositor developer who has never used
> > "hotspots" with KMS UAPI before. As I have never tested anything in a
> > VM, I have no idea why the kernel would ever want to know about cursor
> > hotspots. Display hardware never does anything with that, it just puts
> > the cursor plane where I tell it to and composes a single image to be
> > sent to the sink. The virtual driver VKMS does the same. To me, a
> > cursor plane is just another universal plane that may have weird
> > stacking order, pixel format, and size limitations.
> > 
> > Ideally the doc for HOTSPOT_X and HOTSPOT_Y documents not only their
> > possible existence and allowed/expected values, but also the reasons
> > to have them and what they are used for, and that if the properties
> > are exposed they are mandatory to program in order to use the plane.  
> 
> Instead of resending the entire series maybe I can draft a possible doc below 
> and
> see if we like it (once we're ok with I'll send out v5 which hopefully will be
> good). How about:

Hi Zack,

cool!

> 
> /**
>  * @hotspot_x_property: property to set mouse hotspot x offset.

Hmm, this does not look like the style of
https://www.kernel.org/doc/html/latest/gpu/drm-kms.html#plane-composition-properties

I suspect it's a .rst file somewhere.

It is important to use the userspace visible concepts and names, like
the property name being "HOTSPOT_X", not hotspot_x_property. After all,
"HOTSPOT_X" is the string that userspace must use to find this
property. That's the UAPI.

>  *
>  * Hotspot is the point within the cursor image that's activating
>  * the click e.g. imagine an arrow cursor pointing to bottom right -
>  * the origin coordinate for that image would be top left
>  * but the point which would be propagating the click would be
>  * the bottom right cursor position (crtc_x, crtc_y) + hotspot
>  * coordinates which for bottom right facing arrow would probably
>  * be (cursor_width, cursor_height).

Is it really required that the hotspot coordinates fall inside the
cursor plane? Will the atomic commit be rejected otherwise?

Are they given with respect to the cursor plane top-left corner,
positive directions being right/down? Is the unit in CRTC pixels or FB
pixels? The example does give an indirect answer, but my personal taste
would like it to be more explicit.

>  *
>  * This information is only relevant for drivers working on top
>  * of para-virtualized hardware. The reason for that is that
>  * the hotspot is fairly encapsulated in the system but imagine having
>  * multiple windows with virtual machines running on servers
>  * across the globe, as you move the mouse across the screen
>  * and the cursor moves over those multiple windows you wouldn't
>  * want to be sending those mouse events to those machines, so virtual
>  * machine monitors implement an optimization where unless the mouse
>  * is locked to the VM window (e.g. via a click) instead of propagating
>  * those mouse events to those VM's they change the image of the native
>  * cursor to what's inside the mouse cursor plane and do not interact
>  * with the VM window until mouse is clicked in it.

Surely the mouse events are sent to those machines across the globe
regardless?

The point I believe you want to make is that in addition that, a
virtual machine viewer application independently moves the cursor image
on the viewer window to avoid the roundtrip latency across the globe
between mouse movement and cursor movement.

Why is the locking you mention relevant? Wouldn't you do this
optimiza

Re: [PATCH v4 2/8] drm/atomic: Add support for mouse hotspots

[Pekka Paalanen]

On Wed, 28 Jun 2023 16:26:37 +
Zack Rusin  wrote:

> On Wed, 2023-06-28 at 14:15 +, Simon Ser wrote:
> > I think we should drop the CRTC_X/CRTC_Y properties for hotspot-aware cursor
> > planes.
> > The drivers aren't going to do anything with these, and exposing them to 
> > user-
> > space
> > makes it sound like user-space controls the position of the plane, but it 
> > really
> > doesn't.  
> 
> I think we talked about this before. The CRTC_X/CRTC_Y properties are 
> absolutely
> being used and they're respected when the rendering is done guest-side - the 
> system
> will be pretty broken if the client sets the crtc x/y properties to somewhere 
> where
> the mouse isn't though.

Right, but it would be useful to hear more about the "why".

> An argument could be made that crtc x/y properties should be removed on the 
> cursor
> plane in drivers for para-virtualized hardware and instead replaced with
> mouse_position x/y properties that do exactly what crtc x/y properties do but 
> make
> it explicit what they really are on a cursor plane.

I suppose this is needed to support the guest OS warping the cursor position
while the viewer has a relative-motion pointer locked to it?

When the pointer is not locked to the VM viewer window, the pointer
sends absolute motion events? Which is necessary for the roundtrip
elision that the hotspot is needed for in the first place.

Btw. this is somewhat conflicting with what you wrote as the first UAPI
doc draft. I don't see how the viewer/host could independently position
the cursor image if the related pointer device is not also delivering
absolute motion events in the guest. Delivering relative motion events
would cause the guest and host opinion of pointer position to drift
apart primarily due to different acceleration curves.


Thanks,
pq


pgpl8bM_FgMxg.pgp
Description: OpenPGP digital signature

Re: [PATCH 6/6] drm/amdgpu: use the new drm_exec object for CS v2

[Tatsuyuki Ishi]

On 6/28/23 19:44, Christian König wrote:

@@ -958,18 +904,57 @@ static int amdgpu_cs_parser_bos(struct amdgpu_cs_parser 
*p,
e->user_invalidated = userpage_invalidated;
}
  
-	r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,

-  &duplicates);
-   if (unlikely(r != 0)) {
-   if (r != -ERESTARTSYS)
-   DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
-   goto out_free_user_pages;
+   drm_exec_until_all_locked(&p->exec) {
+   r = amdgpu_vm_lock_pd(&fpriv->vm, &p->exec, 1 + p->gang_size);
+   drm_exec_retry_on_contention(&p->exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+
+   amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+   /* One fence for TTM and one for each CS job */
+   r = drm_exec_prepare_obj(&p->exec, &e->bo->tbo.base,
+1 + p->gang_size);
+   drm_exec_retry_on_contention(&p->exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+
+   e->bo_va = amdgpu_vm_bo_find(vm, e->bo);
+   e->range = NULL;

Still leaking.

+   }
+
+   if (p->uf_bo) {
+   r = drm_exec_prepare_obj(&p->exec, &p->uf_bo->tbo.base,
+1 + p->gang_size);
+   drm_exec_retry_on_contention(&p->exec);
+   if (unlikely(r))
+   goto out_free_user_pages;
+   }
}

Re: [PATCH 4/6] drm/amdgpu: use drm_exec for GEM and CSA handling

[Tatsuyuki Ishi]

On 6/28/23 19:44, Christian König wrote:


diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
index 74055cba3dc9..6811fc866494 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c
@@ -728,36 +723,37 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void 
*data,
return -EINVAL;
}
  
-	INIT_LIST_HEAD(&list);

-   INIT_LIST_HEAD(&duplicates);
if ((args->operation != AMDGPU_VA_OP_CLEAR) &&
!(args->flags & AMDGPU_VM_PAGE_PRT)) {
gobj = drm_gem_object_lookup(filp, args->handle);
if (gobj == NULL)
return -ENOENT;
abo = gem_to_amdgpu_bo(gobj);
-   tv.bo = &abo->tbo;
-   if (abo->flags & AMDGPU_GEM_CREATE_VM_ALWAYS_VALID)
-   tv.num_shared = 1;
-   else
-   tv.num_shared = 0;
-   list_add(&tv.head, &list);
} else {
gobj = NULL;
abo = NULL;
}
  
-	amdgpu_vm_get_pd_bo(&fpriv->vm, &list, &vm_pd);

+   drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);


Sorry, I missed this last time, but this needs to allow duplicates as well or 
mapping
always_valid BOs doesn't work.


+   drm_exec_until_all_locked(&exec) {
+   if (gobj) {
+   r = drm_exec_lock_obj(&exec, gobj);
+   drm_exec_retry_on_contention(&exec);
+   if (unlikely(r))
+   goto error;
+   }
  
-	r = ttm_eu_reserve_buffers(&ticket, &list, true, &duplicates);

-   if (r)
-   goto error_unref;
+   r = amdgpu_vm_lock_pd(&fpriv->vm, &exec, 2);
+   drm_exec_retry_on_contention(&exec);
+   if (unlikely(r))
+   goto error;
+   }
  
  	if (abo) {

bo_va = amdgpu_vm_bo_find(&fpriv->vm, abo);
if (!bo_va) {
r = -ENOENT;
-   goto error_backoff;
+   goto error;
}
} else if (args->operation != AMDGPU_VA_OP_CLEAR) {
bo_va = fpriv->prt_va;
@@ -794,10 +790,8 @@ int amdgpu_gem_va_ioctl(struct drm_device *dev, void *data,
amdgpu_gem_va_update_vm(adev, &fpriv->vm, bo_va,
args->operation);
  
-error_backoff:

-   ttm_eu_backoff_reservation(&ticket, &list);
-
-error_unref:
+error:
+   drm_exec_fini(&exec);
drm_gem_object_put(gobj);
return r;
  }

Re: [PATCH v2] drm/edid: Add quirk for OSVR HDK 2.0

[Jani Nikula]

On Tue, 20 Jun 2023, Ralph Campbell  wrote:
> The OSVR virtual reality headset HDK 2.0 uses a different EDID
> vendor and device identifier than the HDK 1.1 - 1.4 headsets.
> Add the HDK 2.0 vendor and device identifier to the quirks table so
> that window managers do not try to display the desktop screen on the
> headset display.
>
> Signed-off-by: Ralph Campbell 
> Tested-by: Ralph Campbell 

Thanks for the patch, pushed to drm-misc-next.

BR,
Jani.

> ---
>  drivers/gpu/drm/drm_edid.c | 1 +
>  1 file changed, 1 insertion(+)
>
> I don't know how many of these VR headsets are still around but I have a
> working one and I saw an entry for HDK 1.x so I thought it would be good
> to add HDK 2.0.
>
> v2: The vendor ID was byte swapped.
> I'm not sure how I missed that in v1.
>
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 0454da505687..3b8cc1fe05e8 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -230,6 +230,7 @@ static const struct edid_quirk {
>  
>   /* OSVR HDK and HDK2 VR Headsets */
>   EDID_QUIRK('S', 'V', 'R', 0x1019, EDID_QUIRK_NON_DESKTOP),
> + EDID_QUIRK('A', 'U', 'O', 0x, EDID_QUIRK_NON_DESKTOP),
>  };
>  
>  /*

-- 
Jani Nikula, Intel Open Source Graphics Center

Re: [PATCH 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

On 28.06.2023 21:28, Mark Brown wrote:
> On Wed, Jun 28, 2023 at 06:29:46PM +0200, Konrad Dybcio wrote:
> 
>> +// SPDX-License-Identifier: GPL-2.0-only
>> +/*
>> + * Copyright (c) 2017, 2019-2020, The Linux Foundation. All rights reserved.
>> + * Copyright (c) 2023, Linaro Limited
>> + */
> 
> Please use a C++ comment for the whole thing for consistency.
Oh that's new!

> 
>> +static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
>> +{
>> +struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>> +
>> +regmap_update_bits(vreg->base, REFGEN_REG_BG_CTRL,
>> +   REFGEN_BG_CTRL_MASK, REFGEN_BG_CTRL_ENABLE);
>> +regmap_write(vreg->base, REFGEN_REG_BIAS_EN, REFGEN_BIAS_EN_ENABLE);
> 
> For the enable and disable operations we use a mix of _update_bits() and
> absolute writes with no FIELD_PREP()...
This absolute write was accidentally fine as the mask began at bit0...

> 
>> +static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
>> +{
>> +struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>> +u32 val;
>> +
>> +regmap_read(vreg->base, REFGEN_REG_BG_CTRL, &val);
>> +if (FIELD_GET(REFGEN_BG_CTRL_MASK, val) != REFGEN_BG_CTRL_ENABLE)
>> +return 0;
>> +
>> +regmap_read(vreg->base, REFGEN_REG_BIAS_EN, &val);
>> +if (FIELD_GET(REFGEN_BIAS_EN_MASK, val) != REFGEN_BIAS_EN_ENABLE)
>> +return 0;
> 
> ...but when we read back the status we use FIELD_GET().  This looks like
> a bug, and given that one of the fields starts at bit 1 it presumably is
> one - FIELD_GET() will do shifting.
...but a 2-bit-wide field will never equal 6.
Looks like I put unshifted values in the defines for REFGEN_BG_CTRL..

Thanks for spotting that!

> 
>> +static int qcom_sm8250_refgen_enable(struct regulator_dev *rdev)
>> +{
>> +struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>> +
>> +regmap_update_bits(vreg->base, REFGEN_REG_PWRDWN_CTRL5,
>> +   REFGEN_PWRDWN_CTRL5_MASK, 
>> REFGEN_PWRDWN_CTRL5_ENABLE);
> 
> This is a single bit in a single register so could use the standard
> helpers rather than open coding, the sdm845 does need custom operations
> due to having two fields to manage.
Forgot that's a thing!

Konrad

Re: [RFC v2 2/3] drm/ttm/tests: Add tests for ttm_device

[Christian König]

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Test initialization and cleanup of the ttm_device struct, including
some error paths. Verify the creation of page pools if use_dma_alloc
param is true.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/ttm/tests/ttm_device_test.c | 159 
  1 file changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
index 08d7314b1e35..67f7ec347a61 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -8,6 +8,13 @@
  
  #include "ttm_kunit_helpers.h"
  
+struct ttm_device_test_case {

+   const char *description;
+   bool use_dma_alloc;
+   bool use_dma32;
+   bool pools_init_expected;
+};
+
  static void ttm_device_init_basic(struct kunit *test)
  {
struct ttm_test_devices_priv *priv = test->priv;
@@ -37,8 +44,160 @@ static void ttm_device_init_basic(struct kunit *test)
ttm_device_fini(ttm_dev);
  }
  
+static void ttm_device_init_multiple(struct kunit *test)

+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   struct ttm_device *ttm_devs;
+   unsigned int i, num_dev = 3;
+   int err;
+
+   ttm_devs = kunit_kcalloc(test, num_dev, sizeof(*ttm_devs), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_devs);
+
+   for (i = 0; i < num_dev; i++) {
+   err = ttm_kunit_helper_alloc_device(test, &ttm_devs[i],
+   false, false);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   KUNIT_EXPECT_PTR_EQ(test, ttm_devs[i].dev_mapping,
+   priv->drm->anon_inode->i_mapping);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_devs[i].wq);
+   KUNIT_EXPECT_PTR_EQ(test, ttm_devs[i].funcs, &ttm_dev_funcs);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_devs[i].man_drv[TTM_PL_SYSTEM]);
+   }
+
+   KUNIT_ASSERT_EQ(test, list_count_nodes(&ttm_devs[0].device_list), 
num_dev);
+
+   for (i = 0; i < num_dev; i++)
+   ttm_device_fini(&ttm_devs[i]);
+}
+
+static void ttm_device_fini_basic(struct kunit *test)
+{
+   struct ttm_device *ttm_dev;
+   struct ttm_resource_manager *man;
+   int err;
+
+   ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+   err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   man = ttm_manager_type(ttm_dev, TTM_PL_SYSTEM);
+   KUNIT_ASSERT_NOT_NULL(test, man);
+
+   ttm_device_fini(ttm_dev);
+
+   KUNIT_ASSERT_FALSE(test, man->use_type);
+   KUNIT_ASSERT_TRUE(test, list_empty(&man->lru[0]));
+   KUNIT_ASSERT_NULL(test, ttm_dev->man_drv[TTM_PL_SYSTEM]);
+}
+
+static void ttm_device_init_no_vma_man(struct kunit *test)
+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   struct drm_device *drm = priv->drm;
+   struct ttm_device *ttm_dev;
+   struct drm_vma_offset_manager *vma_man;
+   int err;
+
+   ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+   /* Let's pretend there's no VMA manager allocated */
+   vma_man = drm->vma_offset_manager;
+   drm->vma_offset_manager = NULL;
+
+   err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+   KUNIT_EXPECT_EQ(test, err, -EINVAL);
+
+   /* Bring the manager back for a graceful cleanup */
+   drm->vma_offset_manager = vma_man;
+}
+
+static const struct ttm_device_test_case ttm_device_cases[] = {
+   {
+   .description = "No DMA allocations, no DMA32 required",
+   .use_dma_alloc = false,
+   .use_dma32 = false,
+   .pools_init_expected = false,
+   },
+   {
+   .description = "DMA allocations, DMA32 required",
+   .use_dma_alloc = true,
+   .use_dma32 = true,
+   .pools_init_expected = true,
+   },
+   {
+   .description = "No DMA allocations, DMA32 required",
+   .use_dma_alloc = false,
+   .use_dma32 = true,
+   .pools_init_expected = false,
+   },
+   {
+   .description = "DMA allocations, no DMA32 required",
+   .use_dma_alloc = true,
+   .use_dma32 = false,
+   .pools_init_expected = true,
+   },
+};
+
+static void ttm_device_case_desc(const struct ttm_device_test_case *t, char 
*desc)
+{
+   strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(ttm_device, ttm_device_cases, ttm_device_case_desc);
+
+static void ttm_device_init_pools(struct kunit *test)
+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   const struct ttm_device_test_case *params = test->param_value;
+   struct ttm_device *ttm_dev;
+   struct 

Re: [RFC v2 3/3] drm/ttm/tests: Add tests for ttm_pool

[Christian König]

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Add KUnit tests that exercise page allocation using page pools
and freeing pages, either by returning them to the pool or
freeing them. Add a basic test for ttm_pool cleanup. Introduce
helpers to create a dummy ttm_buffer_object.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/ttm/tests/Makefile|   1 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  29 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   5 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 406 ++
  4 files changed, 441 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_pool_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile
index 7917805f37af..ec87c4fc1ad5 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -2,4 +2,5 @@
  
  obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \

  ttm_device_test.o \
+ttm_pool_test.o \
  ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
index d03db0405484..6ccd3e858397 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -26,6 +26,35 @@ int ttm_kunit_helper_alloc_device(struct kunit *test,
  }
  EXPORT_SYMBOL_GPL(ttm_kunit_helper_alloc_device);
  
+struct ttm_buffer_object *ttm_kunit_helper_ttm_bo_init(struct kunit *test,

+  size_t size)
+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   struct drm_gem_object *gem_obj;
+   struct ttm_buffer_object *bo;
+
+   gem_obj = kunit_kzalloc(test, sizeof(*gem_obj), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, gem_obj);
+
+   drm_gem_private_object_init(priv->drm, gem_obj, size);
+
+   bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   bo->sg = NULL;
+   bo->base = *gem_obj;


Hui? Why that hack? That is clearly leaking the gem object.

Apart from that looks really good to me,
Christian.


+
+   return bo;
+}
+EXPORT_SYMBOL_GPL(ttm_kunit_helper_ttm_bo_init);
+
+void ttm_kunit_helper_ttm_bo_fini(struct ttm_buffer_object *bo)
+{
+   drm_gem_object_release(&bo->base);
+   ttm_bo_put(bo);
+}
+EXPORT_SYMBOL_GPL(ttm_kunit_helper_ttm_bo_fini);
+
  int ttm_test_devices_init(struct kunit *test)
  {
struct ttm_test_devices_priv *priv;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
index 69fb03b9c4d2..abb8279f18c7 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -7,6 +7,7 @@
  
  #include 

  #include 
+#include 
  
  #include 

  #include 
@@ -23,6 +24,10 @@ int ttm_kunit_helper_alloc_device(struct kunit *test,
  bool use_dma_alloc,
  bool use_dma32);
  
+struct ttm_buffer_object *ttm_kunit_helper_ttm_bo_init(struct kunit *test,

+  size_t size);
+void ttm_kunit_helper_ttm_bo_fini(struct ttm_buffer_object *bo);
+
  int ttm_test_devices_init(struct kunit *test);
  void ttm_test_devices_fini(struct kunit *test);
  
diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c

new file mode 100644
index ..0bc6415c3067
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+struct ttm_pool_test_case {
+   const char *description;
+   unsigned int order;
+   bool use_dma_alloc;
+};
+
+static struct ttm_operation_ctx simple_ctx = {
+   .interruptible = true,
+   .no_wait_gpu = false,
+};
+
+static struct ttm_tt *mock_ttm_tt_init(struct kunit *test,
+  uint32_t page_flags,
+  enum ttm_caching caching,
+  size_t size)
+{
+   struct ttm_tt *tt;
+   struct ttm_buffer_object *bo;
+   int err;
+
+   bo = ttm_kunit_helper_ttm_bo_init(test, size);
+   KUNIT_ASSERT_NOT_NULL(test, bo);
+
+   tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+   KUNIT_ASSERT_NOT_NULL(test, tt);
+
+   err = ttm_tt_init(tt, bo, page_flags, caching, 0);
+   KUNIT_ASSERT_EQ(test, err, 0);
+
+   /* We don't need this BO later, release it */
+   ttm_kunit_helper_ttm_bo_fini(bo);
+
+   return tt;
+}
+
+static struct ttm_pool *ttm_pool_pre_populated(struct kunit *test,
+  size_t size,
+  enum ttm_caching caching)
+{
+   struct ttm_test_devices_priv *priv = test->priv;
+   struct ttm_

Re: [PATCH] drm/arm/komeda: Remove component framework and add a simple encoder

[Liviu Dudau]

Hi Faiz,

Thanks for the patch and for addressing what was at some moment on my "nice to
improve / cleanup" list. Sorry for the delay in responding, I had to revive
the bits of an old setup to be able to test this properly, with 2 encoders
attached.

On Wed, Jun 21, 2023 at 02:11:16PM +0530, Faiz Abbas wrote:
> The Komeda driver always expects the remote connector node to initialize
> an encoder. It uses the component aggregator framework which consists
> of component->bind() calls used to initialize the remote encoder and attach
> it to the crtc. This is different from other drm implementations which expect
> the display driver to supply a crtc and connect an encoder to it.

I think both approaches are valid in DRM. We don't want to remove the component
framework because it is doing the wrong thing, but because we cannot use it
with drivers that implement the drm_bridge API. Given that we usually pair with
a component encoder that also implements a drm_bridge, dropping support for
component framework should not affect the users of the driver.

> 
> Remove all component framework calls from the komeda driver and declare and
> attach an encoder inside komeda_crtc_add().

Unfortunately you haven't removed all component framework calls. The hint for
that is that you have not removed the #include  line from
any of the files. Specifically, komeda_kms_attach()/detach() still calls
component_unbind_all() which will crash with your patch applied.

> 
> The remote connector driver has to implement the DRM bridge APIs which
> can be used to glue the encoder to the remote connector.
> 
> Signed-off-by: Faiz Abbas 
> ---
>  .../gpu/drm/arm/display/komeda/komeda_crtc.c  | 22 +++-
>  .../gpu/drm/arm/display/komeda/komeda_drv.c   | 56 ++-
>  .../gpu/drm/arm/display/komeda/komeda_kms.c   |  4 --
>  .../gpu/drm/arm/display/komeda/komeda_kms.h   |  3 +
>  4 files changed, 30 insertions(+), 55 deletions(-)
> 
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> index cea3fd5772b57..144736a69b0ee 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_crtc.c
> @@ -12,6 +12,8 @@
>  #include 
>  #include 
>  #include 
> +#include 
> +#include 
>  
>  #include "komeda_dev.h"
>  #include "komeda_kms.h"
> @@ -612,9 +614,11 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>  struct komeda_crtc *kcrtc)
>  {
>   struct drm_crtc *crtc = &kcrtc->base;
> + struct drm_device *base = &kms->base;
> + struct drm_bridge *bridge;
>   int err;
>  
> - err = drm_crtc_init_with_planes(&kms->base, crtc,
> + err = drm_crtc_init_with_planes(base, crtc,
>   get_crtc_primary(kms, kcrtc), NULL,
>   &komeda_crtc_funcs, NULL);
>   if (err)
> @@ -626,6 +630,22 @@ static int komeda_crtc_add(struct komeda_kms_dev *kms,
>  
>   drm_crtc_enable_color_mgmt(crtc, 0, true, KOMEDA_COLOR_LUT_SIZE);

I would move this line after the bridges are being initialised, just in case in 
the future
colour management will propagate some info down to the bridges.

>  
> + /* Construct an encoder for each pipeline and attach it to the remote
> +  * bridge
> +  */
> + kcrtc->encoder.possible_crtcs = drm_crtc_mask(crtc);
> + err = drm_simple_encoder_init(base, &kcrtc->encoder,
> +   DRM_MODE_ENCODER_TMDS);
> + if (err)
> + return err;
> +
> + bridge = devm_drm_of_get_bridge(base->dev, kcrtc->master->of_node,
> + KOMEDA_OF_PORT_OUTPUT, 0);
> + if (IS_ERR(bridge))
> + return PTR_ERR(bridge);

I'm a bit undecided on whether to make the absence of a bridge here fatal or 
not.
For the second pipeline it should be possible to act as a slave to the first
pipeline even if it doesn't have a bridge attached, but I need to investigate a
bit more here. The bindings suggest that this is mandatory, so keep it for now.


> +
> + err = drm_bridge_attach(&kcrtc->encoder, bridge, NULL, 0);
> +
>   return err;
>  }
>  
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c 
> b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> index 28f76e07dd958..70b1b693c6eff 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_drv.c
> @@ -28,13 +28,11 @@ struct komeda_dev *dev_to_mdev(struct device *dev)
>   return mdrv ? mdrv->mdev : NULL;
>  }
>  
> -static void komeda_unbind(struct device *dev)
> +static int komeda_platform_remove(struct platform_device *pdev)
>  {
> + struct device *dev = &pdev->dev;
>   struct komeda_drv *mdrv = dev_get_drvdata(dev);
>  
> - if (!mdrv)
> - return;
> -
>   komeda_kms_detach(mdrv->kms);
>  
>   if (pm_runtime_enabled(dev))
> @@ -46,10 +44,13 @@ static void komeda_u

[PULL] drm-intel-next-fixes

[Tvrtko Ursulin]

Hi Dave, Daniel,

A weekly collection of fixes for the drm-next/6.5 merge window.

Mostly small display fixups, one for GuC/SLPC and one header file tidy.

Regards,

Tvrtko

drm-intel-next-fixes-2023-06-29:
- Allow DC states along with PW2 only for PWB functionality [adlp+] (Imre Deak)
- Fix SSC selection for MPLLA [mtl] (Radhakrishna Sripada)
- Use hw.adjusted mode when calculating io/fast wake times [psr] (Jouni 
Högander)
- Apply min softlimit correctly [guc/slpc] (Vinay Belgaumkar)
- Assign correct hdcp content type [hdcp] (Suraj Kandpal)
- Add missing forward declarations/includes to display power headers (Imre Deak)
The following changes since commit 274d4b96b12f78cef4f72a97a4967032233f6cae:

  drm/i915: Fix a NULL vs IS_ERR() bug (2023-06-20 08:54:47 +0100)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-intel 
tags/drm-intel-next-fixes-2023-06-29

for you to fetch changes up to 5b7826355e5b9f48eea29275215fc55165cd17c3:

  drm/i915: Add missing forward declarations/includes to display power headers 
(2023-06-27 09:48:17 +0100)


- Allow DC states along with PW2 only for PWB functionality [adlp+] (Imre Deak)
- Fix SSC selection for MPLLA [mtl] (Radhakrishna Sripada)
- Use hw.adjusted mode when calculating io/fast wake times [psr] (Jouni 
Högander)
- Apply min softlimit correctly [guc/slpc] (Vinay Belgaumkar)
- Assign correct hdcp content type [hdcp] (Suraj Kandpal)
- Add missing forward declarations/includes to display power headers (Imre Deak)


Imre Deak (2):
  drm/i915/adlp+: Allow DC states along with PW2 only for PWB functionality
  drm/i915: Add missing forward declarations/includes to display power 
headers

Jouni Högander (1):
  drm/i915/psr: Use hw.adjusted mode when calculating io/fast wake times

Radhakrishna Sripada (1):
  drm/i915/mtl: Fix SSC selection for MPLLA

Suraj Kandpal (1):
  drm/i915/hdcp: Assign correct hdcp content type

Vinay Belgaumkar (1):
  drm/i915/guc/slpc: Apply min softlimit correctly

 drivers/gpu/drm/i915/display/intel_cx0_phy.c|  3 ++-
 drivers/gpu/drm/i915/display/intel_display_power.h  |  4 
 drivers/gpu/drm/i915/display/intel_display_power_map.c  | 16 
 drivers/gpu/drm/i915/display/intel_display_power_well.h |  2 ++
 drivers/gpu/drm/i915/display/intel_hdcp.c   |  2 +-
 drivers/gpu/drm/i915/display/intel_psr.c|  4 ++--
 drivers/gpu/drm/i915/gt/uc/intel_guc_slpc.c |  2 +-
 7 files changed, 20 insertions(+), 13 deletions(-)

Re: [RFC v2 1/3] drm/ttm: Introduce KUnit tests

[Karolina Stolarek]

Hi Christian,

Thanks a lot for taking a look at my patches.

On 29.06.2023 09:50, Christian König wrote:

Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Add the initial version of unit tests for ttm_device struct, together
with helper functions.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/Kconfig   | 15 +
  drivers/gpu/drm/ttm/Makefile  |  1 +
  drivers/gpu/drm/ttm/tests/.kunitconfig    |  4 ++
  drivers/gpu/drm/ttm/tests/Makefile    |  5 ++
  drivers/gpu/drm/ttm/tests/ttm_device_test.c   | 54 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c | 59 +++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h | 29 +
  7 files changed, 167 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/.kunitconfig
  create mode 100644 drivers/gpu/drm/ttm/tests/Makefile
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_device_test.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h

diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..53024e44a2d5 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -194,6 +194,21 @@ config DRM_TTM
    GPU memory types. Will be enabled automatically if a device 
driver

    uses it.
+config DRM_TTM_KUNIT_TEST
+    tristate "KUnit tests for TTM" if !KUNIT_ALL_TESTS
+    default n
+    depends on DRM && KUNIT
+    select DRM_TTM
+    select DRM_EXPORT_FOR_TESTS if m
+    select DRM_KUNIT_TEST_HELPERS
+    default KUNIT_ALL_TESTS
+    help
+  Enables unit tests for TTM, a GPU memory manager subsystem 
used
+  to manage memory buffers. This option is mostly useful for 
kernel

+  developers.
+
+  If in doubt, say "N".
+
  config DRM_BUDDY
  tristate
  depends on DRM
diff --git a/drivers/gpu/drm/ttm/Makefile b/drivers/gpu/drm/ttm/Makefile
index f906b22959cf..dad298127226 100644
--- a/drivers/gpu/drm/ttm/Makefile
+++ b/drivers/gpu/drm/ttm/Makefile
@@ -8,3 +8,4 @@ ttm-y := ttm_tt.o ttm_bo.o ttm_bo_util.o ttm_bo_vm.o 
ttm_module.o \

  ttm-$(CONFIG_AGP) += ttm_agp_backend.o
  obj-$(CONFIG_DRM_TTM) += ttm.o
+obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += tests/
diff --git a/drivers/gpu/drm/ttm/tests/.kunitconfig 
b/drivers/gpu/drm/ttm/tests/.kunitconfig

new file mode 100644
index ..75fdce0cd98e
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/.kunitconfig
@@ -0,0 +1,4 @@
+CONFIG_KUNIT=y
+CONFIG_DRM=y
+CONFIG_DRM_KUNIT_TEST_HELPERS=y
+CONFIG_DRM_TTM_KUNIT_TEST=y
diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile

new file mode 100644
index ..7917805f37af
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -0,0 +1,5 @@
+# SPDX-License-Identifier: GPL-2.0 AND MIT
+
+obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
+    ttm_device_test.o \
+    ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c

new file mode 100644
index ..08d7314b1e35
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -0,0 +1,54 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+static void ttm_device_init_basic(struct kunit *test)
+{
+    struct ttm_test_devices_priv *priv = test->priv;
+    struct ttm_device *ttm_dev;
+    struct ttm_resource_manager *ttm_sys_man;
+    int err;
+
+    ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+    err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+    KUNIT_ASSERT_EQ(test, err, 0);
+
+    KUNIT_EXPECT_PTR_EQ(test, ttm_dev->funcs, &ttm_dev_funcs);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev->wq);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev->man_drv[TTM_PL_SYSTEM]);
+
+    ttm_sys_man = &ttm_dev->sysman;
+    KUNIT_ASSERT_NOT_NULL(test, ttm_sys_man);
+    KUNIT_EXPECT_TRUE(test, ttm_sys_man->use_tt);
+    KUNIT_EXPECT_TRUE(test, ttm_sys_man->use_type);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_sys_man->func);
+
+    KUNIT_EXPECT_PTR_EQ(test, ttm_dev->dev_mapping,
+    priv->drm->anon_inode->i_mapping);
+
+    ttm_device_fini(ttm_dev);
+}
+
+static struct kunit_case ttm_device_test_cases[] = {
+    KUNIT_CASE(ttm_device_init_basic),
+    {}
+};
+
+static struct kunit_suite ttm_device_test_suite = {
+    .name = "ttm_device",
+    .init = ttm_test_devices_init,
+    .exit = ttm_test_devices_fini,
+    .test_cases = ttm_device_test_cases,
+};
+
+kunit_test_suites(&ttm_device_test_suite);
+
+MODULE_LICENSE("GPL");
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c

new file mode 100644
index ..d03db0405484
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -0,0 +

Re: [RFC v2 2/3] drm/ttm/tests: Add tests for ttm_device

[Karolina Stolarek]

On 29.06.2023 11:14, Christian König wrote:



Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Test initialization and cleanup of the ttm_device struct, including
some error paths. Verify the creation of page pools if use_dma_alloc
param is true.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/ttm/tests/ttm_device_test.c | 159 
  1 file changed, 159 insertions(+)

diff --git a/drivers/gpu/drm/ttm/tests/ttm_device_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_device_test.c

index 08d7314b1e35..67f7ec347a61 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_device_test.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_device_test.c
@@ -8,6 +8,13 @@
  #include "ttm_kunit_helpers.h"
+struct ttm_device_test_case {
+    const char *description;
+    bool use_dma_alloc;
+    bool use_dma32;
+    bool pools_init_expected;
+};
+
  static void ttm_device_init_basic(struct kunit *test)
  {
  struct ttm_test_devices_priv *priv = test->priv;
@@ -37,8 +44,160 @@ static void ttm_device_init_basic(struct kunit *test)
  ttm_device_fini(ttm_dev);
  }
+static void ttm_device_init_multiple(struct kunit *test)
+{
+    struct ttm_test_devices_priv *priv = test->priv;
+    struct ttm_device *ttm_devs;
+    unsigned int i, num_dev = 3;
+    int err;
+
+    ttm_devs = kunit_kcalloc(test, num_dev, sizeof(*ttm_devs), 
GFP_KERNEL);

+    KUNIT_ASSERT_NOT_NULL(test, ttm_devs);
+
+    for (i = 0; i < num_dev; i++) {
+    err = ttm_kunit_helper_alloc_device(test, &ttm_devs[i],
+    false, false);
+    KUNIT_ASSERT_EQ(test, err, 0);
+
+    KUNIT_EXPECT_PTR_EQ(test, ttm_devs[i].dev_mapping,
+    priv->drm->anon_inode->i_mapping);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_devs[i].wq);
+    KUNIT_EXPECT_PTR_EQ(test, ttm_devs[i].funcs, &ttm_dev_funcs);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_devs[i].man_drv[TTM_PL_SYSTEM]);
+    }
+
+    KUNIT_ASSERT_EQ(test, list_count_nodes(&ttm_devs[0].device_list), 
num_dev);

+
+    for (i = 0; i < num_dev; i++)
+    ttm_device_fini(&ttm_devs[i]);
+}
+
+static void ttm_device_fini_basic(struct kunit *test)
+{
+    struct ttm_device *ttm_dev;
+    struct ttm_resource_manager *man;
+    int err;
+
+    ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+    err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+    KUNIT_ASSERT_EQ(test, err, 0);
+
+    man = ttm_manager_type(ttm_dev, TTM_PL_SYSTEM);
+    KUNIT_ASSERT_NOT_NULL(test, man);
+
+    ttm_device_fini(ttm_dev);
+
+    KUNIT_ASSERT_FALSE(test, man->use_type);
+    KUNIT_ASSERT_TRUE(test, list_empty(&man->lru[0]));
+    KUNIT_ASSERT_NULL(test, ttm_dev->man_drv[TTM_PL_SYSTEM]);
+}
+
+static void ttm_device_init_no_vma_man(struct kunit *test)
+{
+    struct ttm_test_devices_priv *priv = test->priv;
+    struct drm_device *drm = priv->drm;
+    struct ttm_device *ttm_dev;
+    struct drm_vma_offset_manager *vma_man;
+    int err;
+
+    ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+    /* Let's pretend there's no VMA manager allocated */
+    vma_man = drm->vma_offset_manager;
+    drm->vma_offset_manager = NULL;
+
+    err = ttm_kunit_helper_alloc_device(test, ttm_dev, false, false);
+    KUNIT_EXPECT_EQ(test, err, -EINVAL);
+
+    /* Bring the manager back for a graceful cleanup */
+    drm->vma_offset_manager = vma_man;
+}
+
+static const struct ttm_device_test_case ttm_device_cases[] = {
+    {
+    .description = "No DMA allocations, no DMA32 required",
+    .use_dma_alloc = false,
+    .use_dma32 = false,
+    .pools_init_expected = false,
+    },
+    {
+    .description = "DMA allocations, DMA32 required",
+    .use_dma_alloc = true,
+    .use_dma32 = true,
+    .pools_init_expected = true,
+    },
+    {
+    .description = "No DMA allocations, DMA32 required",
+    .use_dma_alloc = false,
+    .use_dma32 = true,
+    .pools_init_expected = false,
+    },
+    {
+    .description = "DMA allocations, no DMA32 required",
+    .use_dma_alloc = true,
+    .use_dma32 = false,
+    .pools_init_expected = true,
+    },
+};
+
+static void ttm_device_case_desc(const struct ttm_device_test_case 
*t, char *desc)

+{
+    strscpy(desc, t->description, KUNIT_PARAM_DESC_SIZE);
+}
+
+KUNIT_ARRAY_PARAM(ttm_device, ttm_device_cases, ttm_device_case_desc);
+
+static void ttm_device_init_pools(struct kunit *test)
+{
+    struct ttm_test_devices_priv *priv = test->priv;
+    const struct ttm_device_test_case *params = test->param_value;
+    struct ttm_device *ttm_dev;
+    struct ttm_pool *pool;
+    struct ttm_pool_type pt;
+    int err;
+
+    ttm_dev = kunit_kzalloc(test, sizeof(*ttm_dev), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, ttm_dev);
+
+    err = ttm_kunit_helper_alloc_device(test, ttm_dev,
+    params->use_dma_alloc,
+    params->use_dma32);
+    

Re: [RFC v2 3/3] drm/ttm/tests: Add tests for ttm_pool

[Karolina Stolarek]

On 29.06.2023 11:17, Christian König wrote:



Am 27.06.23 um 10:32 schrieb Karolina Stolarek:

Add KUnit tests that exercise page allocation using page pools
and freeing pages, either by returning them to the pool or
freeing them. Add a basic test for ttm_pool cleanup. Introduce
helpers to create a dummy ttm_buffer_object.

Signed-off-by: Karolina Stolarek 
---
  drivers/gpu/drm/ttm/tests/Makefile    |   1 +
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c |  29 ++
  drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h |   5 +
  drivers/gpu/drm/ttm/tests/ttm_pool_test.c | 406 ++
  4 files changed, 441 insertions(+)
  create mode 100644 drivers/gpu/drm/ttm/tests/ttm_pool_test.c

diff --git a/drivers/gpu/drm/ttm/tests/Makefile 
b/drivers/gpu/drm/ttm/tests/Makefile

index 7917805f37af..ec87c4fc1ad5 100644
--- a/drivers/gpu/drm/ttm/tests/Makefile
+++ b/drivers/gpu/drm/ttm/tests/Makefile
@@ -2,4 +2,5 @@
  obj-$(CONFIG_DRM_TTM_KUNIT_TEST) += \
  ttm_device_test.o \
+    ttm_pool_test.o \
  ttm_kunit_helpers.o
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c

index d03db0405484..6ccd3e858397 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.c
@@ -26,6 +26,35 @@ int ttm_kunit_helper_alloc_device(struct kunit *test,
  }
  EXPORT_SYMBOL_GPL(ttm_kunit_helper_alloc_device);
+struct ttm_buffer_object *ttm_kunit_helper_ttm_bo_init(struct kunit 
*test,

+   size_t size)
+{
+    struct ttm_test_devices_priv *priv = test->priv;
+    struct drm_gem_object *gem_obj;
+    struct ttm_buffer_object *bo;
+
+    gem_obj = kunit_kzalloc(test, sizeof(*gem_obj), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, gem_obj);
+
+    drm_gem_private_object_init(priv->drm, gem_obj, size);
+
+    bo = kunit_kzalloc(test, sizeof(*bo), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, bo);
+
+    bo->sg = NULL;
+    bo->base = *gem_obj;


Hui? Why that hack? That is clearly leaking the gem object.


Huh, you're right... I believe that I had some problems with either 
device cleanup or allocs. I'll double-check and see if I can get rid of it.



Apart from that looks really good to me,
Christian.


Thank you. I had some questions around testing > MAX_ORDER in v1 
email[1], could you take a look and see if checks in 
ttm_pool_alloc_basic() are correct?


Many thanks,
Karolina


[1] - message-id: b08037ef-156c-0f5d-1fde-e2c55d765...@intel.com




+
+    return bo;
+}
+EXPORT_SYMBOL_GPL(ttm_kunit_helper_ttm_bo_init);
+
+void ttm_kunit_helper_ttm_bo_fini(struct ttm_buffer_object *bo)
+{
+    drm_gem_object_release(&bo->base);
+    ttm_bo_put(bo);
+}
+EXPORT_SYMBOL_GPL(ttm_kunit_helper_ttm_bo_fini);
+
  int ttm_test_devices_init(struct kunit *test)
  {
  struct ttm_test_devices_priv *priv;
diff --git a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h 
b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h

index 69fb03b9c4d2..abb8279f18c7 100644
--- a/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
+++ b/drivers/gpu/drm/ttm/tests/ttm_kunit_helpers.h
@@ -7,6 +7,7 @@
  #include 
  #include 
+#include 
  #include 
  #include 
@@ -23,6 +24,10 @@ int ttm_kunit_helper_alloc_device(struct kunit *test,
    bool use_dma_alloc,
    bool use_dma32);
+struct ttm_buffer_object *ttm_kunit_helper_ttm_bo_init(struct kunit 
*test,

+   size_t size);
+void ttm_kunit_helper_ttm_bo_fini(struct ttm_buffer_object *bo);
+
  int ttm_test_devices_init(struct kunit *test);
  void ttm_test_devices_fini(struct kunit *test);
diff --git a/drivers/gpu/drm/ttm/tests/ttm_pool_test.c 
b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c

new file mode 100644
index ..0bc6415c3067
--- /dev/null
+++ b/drivers/gpu/drm/ttm/tests/ttm_pool_test.c
@@ -0,0 +1,406 @@
+// SPDX-License-Identifier: GPL-2.0 AND MIT
+/*
+ * Copyright © 2023 Intel Corporation
+ */
+#include 
+
+#include 
+#include 
+
+#include "ttm_kunit_helpers.h"
+
+struct ttm_pool_test_case {
+    const char *description;
+    unsigned int order;
+    bool use_dma_alloc;
+};
+
+static struct ttm_operation_ctx simple_ctx = {
+    .interruptible = true,
+    .no_wait_gpu = false,
+};
+
+static struct ttm_tt *mock_ttm_tt_init(struct kunit *test,
+   uint32_t page_flags,
+   enum ttm_caching caching,
+   size_t size)
+{
+    struct ttm_tt *tt;
+    struct ttm_buffer_object *bo;
+    int err;
+
+    bo = ttm_kunit_helper_ttm_bo_init(test, size);
+    KUNIT_ASSERT_NOT_NULL(test, bo);
+
+    tt = kunit_kzalloc(test, sizeof(*tt), GFP_KERNEL);
+    KUNIT_ASSERT_NOT_NULL(test, tt);
+
+    err = ttm_tt_init(tt, bo, page_flags, caching, 0);
+    KUNIT_ASSERT_EQ(test, err, 0);
+
+    /* We don't need this BO later, release it */
+    ttm_kunit_helper_ttm_bo_fini(bo);
+
+    return tt;
+}

Re: [PATCH 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

On 29.06.2023 10:43, Konrad Dybcio wrote:
> On 28.06.2023 21:28, Mark Brown wrote:
>> On Wed, Jun 28, 2023 at 06:29:46PM +0200, Konrad Dybcio wrote:
>>
>>> +// SPDX-License-Identifier: GPL-2.0-only
>>> +/*
>>> + * Copyright (c) 2017, 2019-2020, The Linux Foundation. All rights 
>>> reserved.
>>> + * Copyright (c) 2023, Linaro Limited
>>> + */
>>
>> Please use a C++ comment for the whole thing for consistency.
> Oh that's new!
> 
>>
>>> +static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
>>> +{
>>> +   struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>>> +
>>> +   regmap_update_bits(vreg->base, REFGEN_REG_BG_CTRL,
>>> +  REFGEN_BG_CTRL_MASK, REFGEN_BG_CTRL_ENABLE);
>>> +   regmap_write(vreg->base, REFGEN_REG_BIAS_EN, REFGEN_BIAS_EN_ENABLE);
>>
>> For the enable and disable operations we use a mix of _update_bits() and
>> absolute writes with no FIELD_PREP()...
> This absolute write was accidentally fine as the mask began at bit0...
> 
>>
>>> +static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
>>> +{
>>> +   struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>>> +   u32 val;
>>> +
>>> +   regmap_read(vreg->base, REFGEN_REG_BG_CTRL, &val);
>>> +   if (FIELD_GET(REFGEN_BG_CTRL_MASK, val) != REFGEN_BG_CTRL_ENABLE)
>>> +   return 0;
>>> +
>>> +   regmap_read(vreg->base, REFGEN_REG_BIAS_EN, &val);
>>> +   if (FIELD_GET(REFGEN_BIAS_EN_MASK, val) != REFGEN_BIAS_EN_ENABLE)
>>> +   return 0;
>>
>> ...but when we read back the status we use FIELD_GET().  This looks like
>> a bug, and given that one of the fields starts at bit 1 it presumably is
>> one - FIELD_GET() will do shifting.
> ...but a 2-bit-wide field will never equal 6.
> Looks like I put unshifted values in the defines for REFGEN_BG_CTRL..
> 
> Thanks for spotting that!
Even worse, I noticed I've been feeding a raw address into regmap
functions.. :) 

Konrad
> 
>>
>>> +static int qcom_sm8250_refgen_enable(struct regulator_dev *rdev)
>>> +{
>>> +   struct qcom_refgen *vreg = rdev_get_drvdata(rdev);
>>> +
>>> +   regmap_update_bits(vreg->base, REFGEN_REG_PWRDWN_CTRL5,
>>> +  REFGEN_PWRDWN_CTRL5_MASK, 
>>> REFGEN_PWRDWN_CTRL5_ENABLE);
>>
>> This is a single bit in a single register so could use the standard
>> helpers rather than open coding, the sdm845 does need custom operations
>> due to having two fields to manage.
> Forgot that's a thing!
> 
> Konrad

Re: [PATCH v2 01/15] drm/msm/dsi: Drop unused regulators from QCM2290 14nm DSI PHY config

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

The regulator setup was likely copied from other SoCs by mistake.  Just
like SM6125 the DSI PHY on this platform is not getting power from a
regulator but from the MX power domain.

Fixes: 572e9fd6d14a ("drm/msm/dsi: Add phy configuration for QCM2290")
Signed-off-by: Marijn Suijten 
---
  drivers/gpu/drm/msm/dsi/phy/dsi_phy_14nm.c | 2 --
  1 file changed, 2 deletions(-)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 05/15] dt-bindings: display/msm: dsi-controller-main: Document SM6125

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

Document general compatibility of the DSI controller on SM6125.

Reviewed-by: Krzysztof Kozlowski 
Signed-off-by: Marijn Suijten 
---
  Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 08/15] drm/msm/dpu: Add SM6125 support

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

Add definitions for the display hardware used on the Qualcomm SM6125
platform.

Signed-off-by: Marijn Suijten 
---
  .../gpu/drm/msm/disp/dpu1/catalog/dpu_5_4_sm6125.h | 230 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c |   6 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h |   1 +
  drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c|   1 +
  4 files changed, 238 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 09/15] drm/msm/mdss: Add SM6125 support

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

SM6125 has an UBWC 3.0 decoder but only an UBWC 1.0 encoder.

Signed-off-by: Marijn Suijten 
---
  drivers/gpu/drm/msm/msm_mdss.c | 8 
  1 file changed, 8 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 10/15] dt-bindings: msm: dsi-phy-14nm: Document SM6125 variant

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

Document availability of the 14nm DSI PHY on SM6125.  Note that this
compatible uses the SoC-suffix variant, intead of postfixing an
arbitrary number without the sm/sdm portion.  The PHY is not powered by
a vcca regulator like on most SoCs, but by the MX power domain that is
provided via the power-domains property and a single corresponding
required-opps.

Acked-by: Krzysztof Kozlowski 
Signed-off-by: Marijn Suijten 
---
  .../devicetree/bindings/display/msm/dsi-phy-14nm.yaml | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
index a43e11d3b00d..183a26f8a6dc 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-phy-14nm.yaml
@@ -19,6 +19,7 @@ properties:
- qcom,dsi-phy-14nm-2290
- qcom,dsi-phy-14nm-660
- qcom,dsi-phy-14nm-8953
+  - qcom,sm6125-dsi-phy-14nm
  
reg:

  items:
@@ -35,6 +36,16 @@ properties:
vcca-supply:
  description: Phandle to vcca regulator device node.
  
+  power-domains:

+description:
+  A phandle and PM domain specifier for an optional power domain.
+maxItems: 1
+
+  required-opps:
+description:
+  A phandle to an OPP node describing an optional performance point.


I'd rephrase this to be something more exact, like 'desribing power 
domain's performance point'.



+maxItems: 1
+
  required:
- compatible
- reg



--
With best wishes
Dmitry

Re: [PATCH v2 11/15] drm/msm/dsi: Reuse QCM2290 14nm DSI PHY configuration for SM6125

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

SM6125 features only a single PHY (despite a secondary PHY PLL source
being available to the disp_cc_mdss_pclk0_clk_src clock), and downstream
sources for this "trinket" SoC do not define the typical "vcca"
regulator to be available nor used.  This, including the register offset
is identical to QCM2290, whose config struct can trivially be reused.

Signed-off-by: Marijn Suijten 
---
  drivers/gpu/drm/msm/dsi/phy/dsi_phy.c | 2 ++
  1 file changed, 2 insertions(+)


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

Re: [PATCH v2 12/15] arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

We have a working RPM XO clock; no other driver except rpmcc should be
parenting directly to the fixed-factor xo_board clock nor should it be
reachable by that global name.  Remove the name to that effect, so that
every clock relation is explicitly defined in DTS.

Reviewed-by: Konrad Dybcio 
Signed-off-by: Marijn Suijten 
---
  arch/arm64/boot/dts/qcom/sm6125.dtsi | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index 722dde560bec..edb03508dba3 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -22,7 +22,6 @@ xo_board: xo-board {
compatible = "fixed-clock";
#clock-cells = <0>;
clock-frequency = <1920>;
-   clock-output-names = "xo_board";


Why? I'd say, leave it.

With that fixed:

Reviewed-by: Dmitry Baryshkov 


};
  
  		sleep_clk: sleep-clk {

@@ -306,6 +305,8 @@ rpm_requests: rpm-requests {
rpmcc: clock-controller {
compatible = "qcom,rpmcc-sm6125", "qcom,rpmcc";
#clock-cells = <1>;
+   clocks = <&xo_board>;
+   clock-names = "xo";
};
  
  			rpmpd: power-controller {

@@ -713,7 +714,7 @@ sdhc_1: mmc@4744000 {
  
  			clocks = <&gcc GCC_SDCC1_AHB_CLK>,

 <&gcc GCC_SDCC1_APPS_CLK>,
-<&xo_board>;
+<&rpmcc RPM_SMD_XO_CLK_SRC>;
clock-names = "iface", "core", "xo";
iommus = <&apps_smmu 0x160 0x0>;
  
@@ -740,7 +741,7 @@ sdhc_2: mmc@4784000 {
  
  			clocks = <&gcc GCC_SDCC2_AHB_CLK>,

 <&gcc GCC_SDCC2_APPS_CLK>,
-<&xo_board>;
+<&rpmcc RPM_SMD_XO_CLK_SRC>;
clock-names = "iface", "core", "xo";
iommus = <&apps_smmu 0x180 0x0>;
  



--
With best wishes
Dmitry

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

Enable and configure the dispcc node on SM6125 for consumption by MDSS
later on.

Signed-off-by: Marijn Suijten 
---
  arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
  1 file changed, 25 insertions(+)

diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index edb03508dba3..a5cc0d43d2d9 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -3,6 +3,7 @@
   * Copyright (c) 2021, Martin Botka 
   */
  
+#include 

  #include 
  #include 
  #include 
@@ -1203,6 +1204,30 @@ sram@469 {
reg = <0x0469 0x1>;
};
  
+		dispcc: clock-controller@5f0 {

+   compatible = "qcom,sm6125-dispcc";
+   reg = <0x05f0 0x2>;
+   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
+<0>,
+<0>,
+<0>,
+<0>,
+<0>,
+<&gcc GCC_DISP_AHB_CLK>,
+<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
+   clock-names = "bi_tcxo",
+ "dsi0_phy_pll_out_byteclk",
+ "dsi0_phy_pll_out_dsiclk",
+ "dsi1_phy_pll_out_dsiclk",
+ "dp_phy_pll_link_clk",
+ "dp_phy_pll_vco_div_clk",
+ "cfg_ahb_clk",
+ "gcc_disp_gpll0_div_clk_src";
+   power-domains = <&rpmpd SM6125_VDDCX>;


Would it be logical to specify the required-opps too?


+   #clock-cells = <1>;
+   #power-domain-cells = <1>;
+   };
+
apps_smmu: iommu@c60 {
compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
"arm,mmu-500";
reg = <0x0c60 0x8>;



--
With best wishes
Dmitry

Re: [PATCH v2 14/15] arm64: dts: qcom: sm6125: Add display hardware nodes

[Dmitry Baryshkov]

On 27/06/2023 23:14, Marijn Suijten wrote:

Add the DT nodes that describe the MDSS hardware on SM6125, containing
one MDP (display controller) together with a single DSI and DSI PHY.  No
DisplayPort support is added for now.

Signed-off-by: Marijn Suijten 
---
  arch/arm64/boot/dts/qcom/sm6125.dtsi | 191 ++-
  1 file changed, 189 insertions(+), 2 deletions(-)

diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
b/arch/arm64/boot/dts/qcom/sm6125.dtsi
index a5cc0d43d2d9..b21fa1256f95 100644
--- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
+++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
@@ -1204,12 +1204,199 @@ sram@469 {
reg = <0x0469 0x1>;
};
  


Reviewed-by: Dmitry Baryshkov 

--
With best wishes
Dmitry

[PULL] drm-misc-next-fixes

[Thomas Zimmermann]

Hi Dave and Daniel,

only one trivial bugfix this week.

Best regards
Thomas

drm-misc-next-fixes-2023-06-29:
Short summary of fixes pull:

 * fbdev: Fix module infos on sparc
The following changes since commit cf683e8870bd4be0fd6b98639286700a35088660:

  fbdev: Use /* */ comment in initializer macro (2023-06-15 10:45:17 +0200)

are available in the Git repository at:

  git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2023-06-29

for you to fetch changes up to 861c249cd782cb9f2d5a881bbb32e8da7f0c1192:

  arch/sparc: Add module license and description for fbdev helpers (2023-06-29 
13:30:02 +0200)


Short summary of fixes pull:

 * fbdev: Fix module infos on sparc


Thomas Zimmermann (1):
  arch/sparc: Add module license and description for fbdev helpers

 arch/sparc/video/fbdev.c | 3 +++
 1 file changed, 3 insertions(+)

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

Re: [RFC] drm/i915: Refactor PAT/cache handling

[Tvrtko Ursulin]

On 29/06/2023 06:39, Yang, Fei wrote:

 > From: Tvrtko Ursulin 
 >
 > Informal commit message for now.
 >
 > I got a bit impatient and curious to see if the idea we discussed would
 > work so sketched something out. I think it is what I was describing back
 > then..

Oops, you beat me on this, shame on me.


Not at all, thanks for a detailed look into my attempt!

You were right with most of the observations and I think I've done most 
of them and now it even passes BAT (trybot).


Because I rushed the v1 to sketch out the idea, indeed the double 
caching abstraction and obj->cache_mode made no sense. It's all ripped 
out now.


Only thing I disagree with is to use hardware bits in the lookup table. 
Maybe in a different table, one which could be used for PAT index to hw 
bits lookup in the PTE encode functions. But for the higher level in the 
driver I need the abstracted view so driver can understand the modes and 
ask questions about them.


Let me go through the individual comments below to see if there is 
something more to cover.



 > So high level idea is to teach the driver what caching modes are hidden
 > behind PAT indices. Given you already had that in static tables, if we
 > just turn the tables a bit around and add a driver abstraction of caching
 > modes this is what happens:
 >
 >  * We can lose the ugly runtime i915_gem_get_pat_index.
 >
 >  * We can have a smarter i915_gem_object_has_cache_level, which now can
 >    use the above mentioned table to understand the caching modes and so
 >    does not have to pessimistically return true for _any_ input when user
 >    has set the PAT index. This may improve things even for MTL.
 >
 >  * We can simplify the debugfs printout to be platform agnostic.
 >
 >  * We are perhaps opening the door to un-regress the dodgy addition
 >    made to i915_gem_object_can_bypass_llc? See QQQ/FIXME in the patch.
 >
 > I hope I did not forget anything, but anyway, please have a read and see
 > what you think. I think it has potential.
 >
 > Proper commit message can come later.
 >
 > Signed-off-by: Tvrtko Ursulin 
 > Cc: Fei Yang 
 > ---
 >  drivers/gpu/drm/i915/Makefile                 |   1 +
 >  drivers/gpu/drm/i915/gem/i915_gem_domain.c    |  34 ++---
 >  .../gpu/drm/i915/gem/i915_gem_execbuffer.c    |  13 +-
 >  drivers/gpu/drm/i915/gem/i915_gem_mman.c      |  10 +-
 >  drivers/gpu/drm/i915/gem/i915_gem_object.c    |  78 ---
 >  drivers/gpu/drm/i915/gem/i915_gem_object.h    |  18 ++-
 >  .../gpu/drm/i915/gem/i915_gem_object_types.h  |  99 +-
 >  drivers/gpu/drm/i915/gem/i915_gem_stolen.c    |   7 +-
 >  drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  26 ++--
 >  .../gpu/drm/i915/gem/selftests/huge_pages.c   |   2 +-
 >  drivers/gpu/drm/i915/gt/gen6_ppgtt.c          |   4 +-
 >  drivers/gpu/drm/i915/gt/gen8_ppgtt.c          |  13 +-
 >  drivers/gpu/drm/i915/gt/intel_ggtt.c          |   9 +-
 >  drivers/gpu/drm/i915/gt/intel_migrate.c       |  11 +-
 >  drivers/gpu/drm/i915/gt/selftest_migrate.c    |   9 +-
 >  drivers/gpu/drm/i915/gt/selftest_reset.c      |  14 +-
 >  drivers/gpu/drm/i915/gt/selftest_timeline.c   |   5 +-
 >  drivers/gpu/drm/i915/gt/selftest_tlb.c        |   5 +-
 >  drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c      |   8 +-
 >  drivers/gpu/drm/i915/i915_cache.c             |  59 
 >  drivers/gpu/drm/i915/i915_cache.h             | 129 ++
 >  drivers/gpu/drm/i915/i915_debugfs.c           |  83 ++-
 >  drivers/gpu/drm/i915/i915_driver.c            |   3 +
 >  drivers/gpu/drm/i915/i915_drv.h               |   3 +
 >  drivers/gpu/drm/i915/i915_gem.c               |  21 +--
 >  drivers/gpu/drm/i915/i915_gpu_error.c         |   7 +-
 >  drivers/gpu/drm/i915/i915_pci.c               |  83 +--
 >  drivers/gpu/drm/i915/intel_device_info.h      |   6 +-
 >  drivers/gpu/drm/i915/selftests/i915_gem.c     |   5 +-
 >  .../gpu/drm/i915/selftests/i915_gem_evict.c   |   4 +-
 >  drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  13 +-
 >  .../drm/i915/selftests/intel_memory_region.c  |   4 +-
 >  .../gpu/drm/i915/selftests/mock_gem_device.c  |  10 +-
 >  33 files changed, 415 insertions(+), 381 deletions(-)
 >  create mode 100644 drivers/gpu/drm/i915/i915_cache.c
 >  create mode 100644 drivers/gpu/drm/i915/i915_cache.h
 >
 > diff --git a/drivers/gpu/drm/i915/Makefile 
b/drivers/gpu/drm/i915/Makefile

 > index 2be9dd960540..2c3da8f0c78e 100644
 > --- a/drivers/gpu/drm/i915/Makefile
 > +++ b/drivers/gpu/drm/i915/Makefile
 > @@ -30,6 +30,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 >  # core driver code
 >  i915-y += i915_driver.o \
 >       i915_drm_client.o \
 > +     i915_cache.o \
 >       i915_config.o \
 >       i915_getparam.o \
 >       i915_ioctl.o \
 > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c 
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c

 > index dfaaa8b66ac3..49bfae45390f 100644
 > --- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
 > +++ b/drivers/gpu/drm/i915/gem/i915_gem_do

Re: [PATCH v2 12/15] arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock

[Marijn Suijten]

On 2023-06-29 13:55:28, Dmitry Baryshkov wrote:
> On 27/06/2023 23:14, Marijn Suijten wrote:
> > We have a working RPM XO clock; no other driver except rpmcc should be
> > parenting directly to the fixed-factor xo_board clock nor should it be
> > reachable by that global name.  Remove the name to that effect, so that
> > every clock relation is explicitly defined in DTS.
> > 
> > Reviewed-by: Konrad Dybcio 
> > Signed-off-by: Marijn Suijten 
> > ---
> >   arch/arm64/boot/dts/qcom/sm6125.dtsi | 7 ---
> >   1 file changed, 4 insertions(+), 3 deletions(-)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
> > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > index 722dde560bec..edb03508dba3 100644
> > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > @@ -22,7 +22,6 @@ xo_board: xo-board {
> > compatible = "fixed-clock";
> > #clock-cells = <0>;
> > clock-frequency = <1920>;
> > -   clock-output-names = "xo_board";
> 
> Why? I'd say, leave it.

The exact reason is explained in the commit message.

> 
> With that fixed:

Hence I don't think it makes sense to "fix" this.

- Marijn

> Reviewed-by: Dmitry Baryshkov 

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Marijn Suijten]

On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:
> On 27/06/2023 23:14, Marijn Suijten wrote:
> > Enable and configure the dispcc node on SM6125 for consumption by MDSS
> > later on.
> > 
> > Signed-off-by: Marijn Suijten 
> > ---
> >   arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
> >   1 file changed, 25 insertions(+)
> > 
> > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
> > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > index edb03508dba3..a5cc0d43d2d9 100644
> > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > @@ -3,6 +3,7 @@
> >* Copyright (c) 2021, Martin Botka 
> >*/
> >   
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -1203,6 +1204,30 @@ sram@469 {
> > reg = <0x0469 0x1>;
> > };
> >   
> > +   dispcc: clock-controller@5f0 {
> > +   compatible = "qcom,sm6125-dispcc";
> > +   reg = <0x05f0 0x2>;
> > +   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> > +<0>,
> > +<0>,
> > +<0>,
> > +<0>,
> > +<0>,
> > +<&gcc GCC_DISP_AHB_CLK>,
> > +<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
> > +   clock-names = "bi_tcxo",
> > + "dsi0_phy_pll_out_byteclk",
> > + "dsi0_phy_pll_out_dsiclk",
> > + "dsi1_phy_pll_out_dsiclk",
> > + "dp_phy_pll_link_clk",
> > + "dp_phy_pll_vco_div_clk",
> > + "cfg_ahb_clk",
> > + "gcc_disp_gpll0_div_clk_src";
> > +   power-domains = <&rpmpd SM6125_VDDCX>;
> 
> Would it be logical to specify the required-opps too?

Perhaps, but barely any other SoC aside from sm8x50 sets it on dispcc.
What should it be, rpmhpd_opp_low_svs?  IIRC we used "svs" for the DSI
PHY despite not having a reference value downstream (it sets a range of
NOM-TURBO_NO_CPR, and RETENTION when it's off).

- Marijn

> 
> > +   #clock-cells = <1>;
> > +   #power-domain-cells = <1>;
> > +   };
> > +
> > apps_smmu: iommu@c60 {
> > compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
> > "arm,mmu-500";
> > reg = <0x0c60 0x8>;
> > 
> 
> -- 
> With best wishes
> Dmitry
> 

[PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Thomas Zimmermann]

The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.

Patch 1 to 4 resolve a number of unnecessary include statements of
. The header should only be included in source
files that access struct screen_info.

Patches 5 to 7 move the declaration of screen_info and edid_info to
. Architectures that provide either set
a Kconfig token to enable them.

Patches 8 to 9 make users of screen_info depend on the architecture's
feature.

Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.

Tested on x86-64. Built for a variety of platforms.

Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.

Thomas Zimmermann (12):
  efi: Do not include  from EFI header
  fbdev/sm712fb: Do not include 
  sysfb: Do not include  from sysfb header
  staging/sm750fb: Do not include 
  arch: Remove trailing whitespaces
  arch: Declare screen_info in 
  arch/x86: Declare edid_info in 
  drivers/firmware: Remove trailing whitespaces
  drivers: Add dependencies on CONFIG_ARCH_HAS_SCREEN_INFO
  fbdev/core: Use fb_is_primary_device() in fb_firmware_edid()
  fbdev/core: Protect edid_info with CONFIG_ARCH_HAS_EDID_INFO
  fbdev/core: Define empty fb_firmware_edid() in 

 arch/Kconfig  | 12 +++
 arch/alpha/Kconfig|  1 +
 arch/arm/Kconfig  |  1 +
 arch/arm/kernel/efi.c |  2 ++
 arch/arm64/Kconfig|  1 +
 arch/arm64/kernel/efi.c   |  1 +
 arch/csky/Kconfig |  1 +
 arch/hexagon/Kconfig  |  1 +
 arch/ia64/Kconfig |  5 +--
 arch/loongarch/Kconfig|  1 +
 arch/mips/Kconfig |  1 +
 arch/nios2/Kconfig|  1 +
 arch/powerpc/Kconfig  |  1 +
 arch/riscv/Kconfig|  1 +
 arch/sh/Kconfig   |  7 ++--
 arch/sparc/Kconfig|  1 +
 arch/x86/Kconfig  |  2 ++
 arch/xtensa/Kconfig   |  1 +
 drivers/firmware/Kconfig  |  3 +-
 drivers/firmware/efi/Kconfig  |  1 +
 drivers/firmware/efi/libstub/efi-stub-entry.c |  2 ++
 drivers/firmware/efi/libstub/screen_info.c|  2 ++
 drivers/gpu/drm/Kconfig   |  1 +
 drivers/hv/Kconfig|  1 +
 drivers/staging/sm750fb/sm750.c   |  1 -
 drivers/staging/sm750fb/sm750_accel.c |  1 -
 drivers/staging/sm750fb/sm750_cursor.c|  1 -
 drivers/staging/sm750fb/sm750_hw.c|  1 -
 drivers/video/console/Kconfig |  2 ++
 drivers/video/fbdev/Kconfig   |  4 +++
 drivers/video/fbdev/core/fbmon.c  | 34 ++-
 drivers/video/fbdev/i810/i810-i2c.c   |  2 +-
 drivers/video/fbdev/intelfb/intelfbdrv.c  |  2 +-
 drivers/video/fbdev/nvidia/nv_i2c.c   |  2 +-
 drivers/video/fbdev/savage/savagefb-i2c.c |  2 +-
 drivers/video/fbdev/sm712fb.c |  9 +++--
 include/asm-generic/Kbuild|  1 +
 include/asm-generic/screen_info.h | 18 ++
 include/linux/efi.h   |  3 +-
 include/linux/fb.h| 10 +-
 include/linux/screen_info.h   |  2 +-
 include/linux/sysfb.h |  3 +-
 include/video/edid.h  |  3 --
 43 files changed, 105 insertions(+), 47 deletions(-)
 create mode 100644 include/asm-generic/screen_info.h


base-commit: d2f0af8472494398a42153684b790b723a79f143
-- 
2.41.0

[PATCH 01/12] efi: Do not include from EFI header

[Thomas Zimmermann]

The header file  does not need anything from
. Declare struct screen_info and remove
the include statements. Update a number of source files that
require struct screen_info's definition.

Signed-off-by: Thomas Zimmermann 
Cc: Ard Biesheuvel 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm/kernel/efi.c | 2 ++
 arch/arm64/kernel/efi.c   | 1 +
 drivers/firmware/efi/libstub/efi-stub-entry.c | 2 ++
 drivers/firmware/efi/libstub/screen_info.c| 2 ++
 include/linux/efi.h   | 3 ++-
 5 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/arch/arm/kernel/efi.c b/arch/arm/kernel/efi.c
index e2b9d2618c672..e94655ef16bb3 100644
--- a/arch/arm/kernel/efi.c
+++ b/arch/arm/kernel/efi.c
@@ -5,6 +5,8 @@
 
 #include 
 #include 
+#include 
+
 #include 
 #include 
 #include 
diff --git a/arch/arm64/kernel/efi.c b/arch/arm64/kernel/efi.c
index baab8dd3ead3c..3afbe503b066f 100644
--- a/arch/arm64/kernel/efi.c
+++ b/arch/arm64/kernel/efi.c
@@ -9,6 +9,7 @@
 
 #include 
 #include 
+#include 
 
 #include 
 #include 
diff --git a/drivers/firmware/efi/libstub/efi-stub-entry.c 
b/drivers/firmware/efi/libstub/efi-stub-entry.c
index cc4dcaea67fa6..2f1902e5d4075 100644
--- a/drivers/firmware/efi/libstub/efi-stub-entry.c
+++ b/drivers/firmware/efi/libstub/efi-stub-entry.c
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0-only
 
 #include 
+#include 
+
 #include 
 
 #include "efistub.h"
diff --git a/drivers/firmware/efi/libstub/screen_info.c 
b/drivers/firmware/efi/libstub/screen_info.c
index 4be1c4d1f922b..a51ec201ca3cb 100644
--- a/drivers/firmware/efi/libstub/screen_info.c
+++ b/drivers/firmware/efi/libstub/screen_info.c
@@ -1,6 +1,8 @@
 // SPDX-License-Identifier: GPL-2.0
 
 #include 
+#include 
+
 #include 
 
 #include "efistub.h"
diff --git a/include/linux/efi.h b/include/linux/efi.h
index 571d1a6e1b744..360895a5572c0 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -24,10 +24,11 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
+struct screen_info;
+
 #define EFI_SUCCESS0
 #define EFI_LOAD_ERROR ( 1 | (1UL << (BITS_PER_LONG-1)))
 #define EFI_INVALID_PARAMETER  ( 2 | (1UL << (BITS_PER_LONG-1)))
-- 
2.41.0

[PATCH 11/12] fbdev/core: Protect edid_info with CONFIG_ARCH_HAS_EDID_INFO

[Thomas Zimmermann]

Guard usage of edid_info with CONFIG_ARCH_HAS_EDID_INFO instead
of CONFIG_X86. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: Randy Dunlap 
---
 drivers/video/fbdev/core/fbmon.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 35be4431f649a..9ae063021e431 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1480,17 +1480,19 @@ int fb_validate_mode(const struct fb_var_screeninfo 
*var, struct fb_info *info)
-EINVAL : 0;
 }
 
-#if defined(CONFIG_FIRMWARE_EDID) && defined(CONFIG_X86)
+#if defined(CONFIG_FIRMWARE_EDID)
 const unsigned char *fb_firmware_edid(struct fb_info *info)
 {
unsigned char *edid = NULL;
 
+#if defined(CONFIG_ARCH_HAS_EDID_INFO)
/*
 * We need to ensure that the EDID block is only
 * returned for the primary graphics adapter.
 */
if (fb_is_primary_device(info))
edid = edid_info.dummy;
+#endif
 
return edid;
 }
-- 
2.41.0

[PATCH 07/12] arch/x86: Declare edid_info in

[Thomas Zimmermann]

The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
.

Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.

Signed-off-by: Thomas Zimmermann 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Kees Cook 
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: Andrew Morton 
Cc: Frederic Weisbecker 
Cc: Nicholas Piggin 
Cc: Ard Biesheuvel 
Cc: Sami Tolvanen 
Cc: Juerg Haefliger 
---
 arch/Kconfig  | 6 ++
 arch/x86/Kconfig  | 1 +
 drivers/video/Kconfig | 3 ---
 include/asm-generic/screen_info.h | 6 ++
 include/video/edid.h  | 3 ---
 5 files changed, 13 insertions(+), 6 deletions(-)

diff --git a/arch/Kconfig b/arch/Kconfig
index 2f58293fd7bcb..ee9866e4df2b0 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
  address translations. Page table walkers that clear the accessed bit
  may use this capability to reduce their search space.
 
+config ARCH_HAS_EDID_INFO
+   bool
+   help
+ Selected by architectures that provide a global instance of
+ edid_info.
+
 config ARCH_HAS_SCREEN_INFO
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index d7c2bf4ee403d..ee81855116be7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -76,6 +76,7 @@ config X86
select ARCH_HAS_DEBUG_VM_PGTABLEif !X86_PAE
select ARCH_HAS_DEVMEM_IS_ALLOWED
select ARCH_HAS_EARLY_DEBUG if KGDB
+   select ARCH_HAS_EDID_INFO
select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_FAST_MULTIPLIER
select ARCH_HAS_FORTIFY_SOURCE
diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
index d4a72bea56be0..8b2b9ac37c3df 100644
--- a/drivers/video/Kconfig
+++ b/drivers/video/Kconfig
@@ -21,9 +21,6 @@ config STI_CORE
 config VIDEO_CMDLINE
bool
 
-config ARCH_HAS_SCREEN_INFO
-   bool
-
 config VIDEO_NOMODESET
bool
default n
diff --git a/include/asm-generic/screen_info.h 
b/include/asm-generic/screen_info.h
index 6fd0e50fabfcd..5efc99c296b40 100644
--- a/include/asm-generic/screen_info.h
+++ b/include/asm-generic/screen_info.h
@@ -5,6 +5,12 @@
 
 #include 
 
+#include 
+
+#if defined(CONFIG_ARCH_HAS_EDID_INFO)
+extern struct edid_info edid_info;
+#endif
+
 #if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
 extern struct screen_info screen_info;
 #endif
diff --git a/include/video/edid.h b/include/video/edid.h
index f614371e9116a..52aabb7060321 100644
--- a/include/video/edid.h
+++ b/include/video/edid.h
@@ -4,7 +4,4 @@
 
 #include 
 
-#ifdef CONFIG_X86
-extern struct edid_info edid_info;
-#endif
 #endif /* __linux_video_edid_h__ */
-- 
2.41.0

[PATCH 03/12] sysfb: Do not include from sysfb header

[Thomas Zimmermann]

The header file  does not need anything from
. Declare struct screen_info and remove
the include statements.

Signed-off-by: Thomas Zimmermann 
Cc: Ard Biesheuvel 
Cc: Hans de Goede 
Cc: Javier Martinez Canillas 
---
 include/linux/sysfb.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/include/linux/sysfb.h b/include/linux/sysfb.h
index c1ef5fc60a3cb..19cb803dd5ecd 100644
--- a/include/linux/sysfb.h
+++ b/include/linux/sysfb.h
@@ -9,7 +9,8 @@
 
 #include 
 #include 
-#include 
+
+struct screen_info;
 
 enum {
M_I17,  /* 17-Inch iMac */
-- 
2.41.0

[PATCH 08/12] drivers/firmware: Remove trailing whitespaces

[Thomas Zimmermann]

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/firmware/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index b59e3041fd627..0432737bbb8b4 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -99,7 +99,7 @@ config EFI_PCDP
  You must also enable the appropriate drivers (serial, VGA, etc.)
 
  See DIG64_HCDPv20_042804.pdf available from
-  
+ 
 
 config DMIID
 bool "Export DMI identification via sysfs to userspace"
-- 
2.41.0

[PATCH 09/12] drivers: Add dependencies on CONFIG_ARCH_HAS_SCREEN_INFO

[Thomas Zimmermann]

Various files within drivers/ depend on the declaration of the
screen_info variable. Add this information to Kconfig.

In the case of the dummy console, the dependency exists only
on ARM. Ignore it on !ARM platforms.

Signed-off-by: Thomas Zimmermann 
Cc: Ard Biesheuvel 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: "K. Y. Srinivasan" 
Cc: Haiyang Zhang 
Cc: Wei Liu 
Cc: Dexuan Cui 
Cc: Greg Kroah-Hartman 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Javier Martinez Canillas 
Cc: Randy Dunlap 
Cc: Andy Shevchenko 
---
 drivers/firmware/Kconfig  | 1 +
 drivers/firmware/efi/Kconfig  | 1 +
 drivers/gpu/drm/Kconfig   | 1 +
 drivers/hv/Kconfig| 1 +
 drivers/video/console/Kconfig | 2 ++
 drivers/video/fbdev/Kconfig   | 4 
 6 files changed, 10 insertions(+)

diff --git a/drivers/firmware/Kconfig b/drivers/firmware/Kconfig
index 0432737bbb8b4..65bbf7422f1db 100644
--- a/drivers/firmware/Kconfig
+++ b/drivers/firmware/Kconfig
@@ -228,6 +228,7 @@ config QCOM_SCM_DOWNLOAD_MODE_DEFAULT
 
 config SYSFB
bool
+   depends on ARCH_HAS_SCREEN_INFO
select BOOT_VESA_SUPPORT
 
 config SYSFB_SIMPLEFB
diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
index 043ca31c114eb..963d305421e50 100644
--- a/drivers/firmware/efi/Kconfig
+++ b/drivers/firmware/efi/Kconfig
@@ -225,6 +225,7 @@ config EFI_DISABLE_PCI_DMA
 config EFI_EARLYCON
def_bool y
depends on SERIAL_EARLYCON && !ARM && !IA64
+   depends on ARCH_HAS_SCREEN_INFO
select FONT_SUPPORT
select ARCH_USE_MEMREMAP_PROT
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f4253..63dfc3391d2ff 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -366,6 +366,7 @@ source "drivers/gpu/drm/sprd/Kconfig"
 config DRM_HYPERV
tristate "DRM Support for Hyper-V synthetic video device"
depends on DRM && PCI && MMU && HYPERV
+   depends on ARCH_HAS_SCREEN_INFO
select DRM_KMS_HELPER
select DRM_GEM_SHMEM_HELPER
help
diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
index 00242107d62e0..3730c9b42a9bd 100644
--- a/drivers/hv/Kconfig
+++ b/drivers/hv/Kconfig
@@ -6,6 +6,7 @@ config HYPERV
tristate "Microsoft Hyper-V client drivers"
depends on (X86 && X86_LOCAL_APIC && HYPERVISOR_GUEST) \
|| (ACPI && ARM64 && !CPU_BIG_ENDIAN)
+   depends on ARCH_HAS_SCREEN_INFO
select PARAVIRT
select X86_HV_CALLBACK_VECTOR if X86
select OF_EARLY_FLATTREE if OF
diff --git a/drivers/video/console/Kconfig b/drivers/video/console/Kconfig
index a2a88d42edf0c..b39e2ae039783 100644
--- a/drivers/video/console/Kconfig
+++ b/drivers/video/console/Kconfig
@@ -10,6 +10,7 @@ config VGA_CONSOLE
depends on !4xx && !PPC_8xx && !SPARC && !M68K && !PARISC &&  !SUPERH 
&& \
(!ARM || ARCH_FOOTBRIDGE || ARCH_INTEGRATOR || ARCH_NETWINDER) 
&& \
!ARM64 && !ARC && !MICROBLAZE && !OPENRISC && !S390 && !UML
+   depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS if (DRM || FB || VFIO_PCI_CORE)
default y
help
@@ -48,6 +49,7 @@ config SGI_NEWPORT_CONSOLE
 
 config DUMMY_CONSOLE
bool
+   depends on ARCH_HAS_SCREEN_INFO || !ARM
default y
 
 config DUMMY_CONSOLE_COLUMNS
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index cecf15418632d..e11d85e802bc7 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -655,6 +655,7 @@ config FB_UVESA
 config FB_VESA
bool "VESA VGA graphics support"
depends on (FB = y) && X86
+   depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -669,6 +670,7 @@ config FB_VESA
 config FB_EFI
bool "EFI-based Framebuffer Support"
depends on (FB = y) && !IA64 && EFI
+   depends on ARCH_HAS_SCREEN_INFO
select APERTURE_HELPERS
select DRM_PANEL_ORIENTATION_QUIRKS
select FB_CFB_FILLRECT
@@ -1089,6 +1091,7 @@ config FB_CARILLO_RANCH
 config FB_INTEL
tristate "Intel 830M/845G/852GM/855GM/865G/915G/945G/945GM/965G/965GM 
support"
depends on FB && PCI && X86 && AGP_INTEL && EXPERT
+   depends on ARCH_HAS_SCREEN_INFO
select FB_MODE_HELPERS
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
@@ -2185,6 +2188,7 @@ config FB_BROADSHEET
 config FB_HYPERV
tristate "Microsoft Hyper-V Synthetic Video support"
depends on FB && HYPERV
+   depends on ARCH_HAS_SCREEN_INFO
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-- 
2.41.0

[PATCH 05/12] arch: Remove trailing whitespaces

[Thomas Zimmermann]

Fix coding style. No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: Andrew Morton 
Cc: Geert Uytterhoeven 
Cc: Arnd Bergmann 
Cc: "Kirill A. Shutemov" 
Cc: Anshuman Khandual 
Cc: Niklas Schnelle 
Cc: Zi Yan 
Cc: "Mike Rapoport (IBM)" 
Cc: Peter Zijlstra 
---
 arch/ia64/Kconfig | 4 ++--
 arch/sh/Kconfig   | 6 +++---
 2 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/arch/ia64/Kconfig b/arch/ia64/Kconfig
index 21fa63ce5ffc0..e79f15e32a451 100644
--- a/arch/ia64/Kconfig
+++ b/arch/ia64/Kconfig
@@ -260,7 +260,7 @@ config PERMIT_BSP_REMOVE
default n
help
Say Y here if your platform SAL will support removal of BSP with 
HOTPLUG_CPU
-   support. 
+   support.
 
 config FORCE_CPEI_RETARGET
bool "Force assumption that CPEI can be re-targeted"
@@ -335,7 +335,7 @@ config IA64_PALINFO
 config IA64_MC_ERR_INJECT
tristate "MC error injection support"
help
- Adds support for MC error injection. If enabled, the kernel 
+ Adds support for MC error injection. If enabled, the kernel
  will provide a sysfs interface for user applications to
  call MC error injection PAL procedures to inject various errors.
  This is a useful tool for MCA testing.
diff --git a/arch/sh/Kconfig b/arch/sh/Kconfig
index 9652d367fc377..04b9550cf0070 100644
--- a/arch/sh/Kconfig
+++ b/arch/sh/Kconfig
@@ -234,7 +234,7 @@ config CPU_SUBTYPE_SH7201
select CPU_SH2A
select CPU_HAS_FPU
select SYS_SUPPORTS_SH_MTU2
- 
+
 config CPU_SUBTYPE_SH7203
bool "Support SH7203 processor"
select CPU_SH2A
@@ -496,7 +496,7 @@ config CPU_SUBTYPE_SH7366
 endchoice
 
 source "arch/sh/mm/Kconfig"
- 
+
 source "arch/sh/Kconfig.cpu"
 
 source "arch/sh/boards/Kconfig"
@@ -647,7 +647,7 @@ config GUSA
  This is the default implementation for both UP and non-ll/sc
  CPUs, and is used by the libc, amongst others.
 
- For additional information, design information can be found 
+ For additional information, design information can be found
  in .
 
  This should only be disabled for special cases where alternate
-- 
2.41.0

[PATCH 04/12] staging/sm750fb: Do not include

[Thomas Zimmermann]

The sm750fb driver does not need anything from .
Remove the include statements.

Signed-off-by: Thomas Zimmermann 
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
---
 drivers/staging/sm750fb/sm750.c| 1 -
 drivers/staging/sm750fb/sm750_accel.c  | 1 -
 drivers/staging/sm750fb/sm750_cursor.c | 1 -
 drivers/staging/sm750fb/sm750_hw.c | 1 -
 4 files changed, 4 deletions(-)

diff --git a/drivers/staging/sm750fb/sm750.c b/drivers/staging/sm750fb/sm750.c
index 55e302a27847d..c260f73cf570a 100644
--- a/drivers/staging/sm750fb/sm750.c
+++ b/drivers/staging/sm750fb/sm750.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 
 #include "sm750.h"
diff --git a/drivers/staging/sm750fb/sm750_accel.c 
b/drivers/staging/sm750fb/sm750_accel.c
index 24b9077a634a6..44b9e3fe3a41d 100644
--- a/drivers/staging/sm750fb/sm750_accel.c
+++ b/drivers/staging/sm750fb/sm750_accel.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "sm750.h"
 #include "sm750_accel.h"
diff --git a/drivers/staging/sm750fb/sm750_cursor.c 
b/drivers/staging/sm750fb/sm750_cursor.c
index 43e6f52c2551f..eea4d1bd36ce7 100644
--- a/drivers/staging/sm750fb/sm750_cursor.c
+++ b/drivers/staging/sm750fb/sm750_cursor.c
@@ -14,7 +14,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include "sm750.h"
 #include "sm750_cursor.h"
diff --git a/drivers/staging/sm750fb/sm750_hw.c 
b/drivers/staging/sm750fb/sm750_hw.c
index 55cb00e8b0d1c..71247eaf26eef 100644
--- a/drivers/staging/sm750fb/sm750_hw.c
+++ b/drivers/staging/sm750fb/sm750_hw.c
@@ -17,7 +17,6 @@
 #include 
 #endif
 #include 
-#include 
 #include 
 
 #include "sm750.h"
-- 
2.41.0

[PATCH 02/12] fbdev/sm712fb: Do not include

[Thomas Zimmermann]

Sm712fb's dependency on  is artificial in that
it only uses struct screen_info for its internals. Replace the use of
struct screen_info with a custom data structure and remove the include
of .

Signed-off-by: Thomas Zimmermann 
Cc: Sudip Mukherjee 
Cc: Teddy Wang 
Cc: Helge Deller 
---
 drivers/video/fbdev/sm712fb.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/video/fbdev/sm712fb.c b/drivers/video/fbdev/sm712fb.c
index b7ad3c644e138..f929091da4e77 100644
--- a/drivers/video/fbdev/sm712fb.c
+++ b/drivers/video/fbdev/sm712fb.c
@@ -27,12 +27,17 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 
 #include "sm712.h"
 
+struct smtcfb_screen_info {
+   u16 lfb_width;
+   u16 lfb_height;
+   u16 lfb_depth;
+};
+
 /*
  * Private structure
  */
@@ -829,7 +834,7 @@ static const struct modeinit vgamode[] = {
},
 };
 
-static struct screen_info smtc_scr_info;
+static struct smtcfb_screen_info smtc_scr_info;
 
 static char *mode_option;
 
-- 
2.41.0

[PATCH 06/12] arch: Declare screen_info in

[Thomas Zimmermann]

The variable screen_info does not exist on all architectures. Declare
it in . All architectures that do declare it
will provide it via .

Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
architectures that don't provide screen_info.

Signed-off-by: Thomas Zimmermann 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Guo Ren 
Cc: Brian Cain 
Cc: Huacai Chen 
Cc: WANG Xuerui 
Cc: Thomas Bogendoerfer 
Cc: Dinh Nguyen 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Kees Cook 
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: Sami Tolvanen 
Cc: Juerg Haefliger 
Cc: Geert Uytterhoeven 
Cc: Anshuman Khandual 
Cc: Niklas Schnelle 
Cc: "Russell King (Oracle)" 
Cc: Linus Walleij 
Cc: Sebastian Reichel 
Cc: "Mike Rapoport (IBM)" 
Cc: "Kirill A. Shutemov" 
Cc: Zi Yan 
---
 arch/Kconfig  |  6 ++
 arch/alpha/Kconfig|  1 +
 arch/arm/Kconfig  |  1 +
 arch/arm64/Kconfig|  1 +
 arch/csky/Kconfig |  1 +
 arch/hexagon/Kconfig  |  1 +
 arch/ia64/Kconfig |  1 +
 arch/loongarch/Kconfig|  1 +
 arch/mips/Kconfig |  1 +
 arch/nios2/Kconfig|  1 +
 arch/powerpc/Kconfig  |  1 +
 arch/riscv/Kconfig|  1 +
 arch/sh/Kconfig   |  1 +
 arch/sparc/Kconfig|  1 +
 arch/x86/Kconfig  |  1 +
 arch/xtensa/Kconfig   |  1 +
 drivers/video/Kconfig |  3 +++
 include/asm-generic/Kbuild|  1 +
 include/asm-generic/screen_info.h | 12 
 include/linux/screen_info.h   |  2 +-
 20 files changed, 38 insertions(+), 1 deletion(-)
 create mode 100644 include/asm-generic/screen_info.h

diff --git a/arch/Kconfig b/arch/Kconfig
index 205fd23e0cada..2f58293fd7bcb 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
  address translations. Page table walkers that clear the accessed bit
  may use this capability to reduce their search space.
 
+config ARCH_HAS_SCREEN_INFO
+   bool
+   help
+ Selected by architectures that provide a global instance of
+ screen_info.
+
 source "kernel/gcov/Kconfig"
 
 source "scripts/gcc-plugins/Kconfig"
diff --git a/arch/alpha/Kconfig b/arch/alpha/Kconfig
index a5c2b1aa46b02..d749011d88b14 100644
--- a/arch/alpha/Kconfig
+++ b/arch/alpha/Kconfig
@@ -4,6 +4,7 @@ config ALPHA
default y
select ARCH_32BIT_USTAT_F_TINODE
select ARCH_HAS_CURRENT_STACK_POINTER
+   select ARCH_HAS_SCREEN_INFO
select ARCH_MIGHT_HAVE_PC_PARPORT
select ARCH_MIGHT_HAVE_PC_SERIO
select ARCH_NO_PREEMPT
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index 0fb4b218f6658..a9d01ee67a90e 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -15,6 +15,7 @@ config ARM
select ARCH_HAS_MEMBARRIER_SYNC_CORE
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_SPECIAL if ARM_LPAE
+   select ARCH_HAS_SCREEN_INFO
select ARCH_HAS_SETUP_DMA_OPS
select ARCH_HAS_SET_MEMORY
select ARCH_STACKWALK
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 343e1e1cae10a..21addc4715bb3 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -36,6 +36,7 @@ config ARM64
select ARCH_HAS_NON_OVERLAPPING_ADDRESS_SPACE
select ARCH_HAS_PTE_DEVMAP
select ARCH_HAS_PTE_SPECIAL
+   select ARCH_HAS_SCREEN_INFO
select ARCH_HAS_SETUP_DMA_OPS
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
diff --git a/arch/csky/Kconfig b/arch/csky/Kconfig
index 4df1f8c9d170b..28444e581fc1f 100644
--- a/arch/csky/Kconfig
+++ b/arch/csky/Kconfig
@@ -10,6 +10,7 @@ config CSKY
select ARCH_USE_QUEUED_RWLOCKS
select ARCH_USE_QUEUED_SPINLOCKS
select ARCH_HAS_CURRENT_STACK_POINTER
+   select ARCH_HAS_SCREEN_INFO
select ARCH_INLINE_READ_LOCK if !PREEMPTION
select ARCH_INLINE_READ_LOCK_BH if !PREEMPTION
select ARCH_INLINE_READ_LOCK_IRQ if !PREEMPTION
diff --git a/arch/hexagon/Kconfig b/arch/hexagon/Kconfig
index 54eadf2651786..cc683c0a43d34 100644
--- a/arch/hexagon/Kconfig
+++ b/arch/hexagon/Kconfig
@@ -5,6 +5,7 @@ comment "Linux Kernel Configuration for Hexagon"
 config HEXAGON
def_bool y
select ARCH_32BIT_OFF_T
+   select ARCH_HAS_SCREEN_INFO
select ARCH_HAS_SYNC_DMA_FOR_DEVICE
select ARC

[PATCH 12/12] fbdev/core: Define empty fb_firmware_edid() in

[Thomas Zimmermann]

Move the empty declaration of fb_firmware_edid() to .
Follow common style and avoid the overhead of exporting the symbol.
No functional changes.

Signed-off-by: Thomas Zimmermann 
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: Randy Dunlap 
---
 drivers/video/fbdev/core/fbmon.c |  7 +--
 include/linux/fb.h   | 10 +-
 2 files changed, 10 insertions(+), 7 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 9ae063021e431..d45bd8a18c2f2 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -1496,13 +1496,8 @@ const unsigned char *fb_firmware_edid(struct fb_info 
*info)
 
return edid;
 }
-#else
-const unsigned char *fb_firmware_edid(struct fb_info *info)
-{
-   return NULL;
-}
-#endif
 EXPORT_SYMBOL(fb_firmware_edid);
+#endif
 
 EXPORT_SYMBOL(fb_parse_edid);
 EXPORT_SYMBOL(fb_edid_to_monspecs);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 5ffd2223326bf..e949532ffc109 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -761,7 +761,6 @@ extern int fb_get_mode(int flags, u32 val, struct 
fb_var_screeninfo *var,
 extern int fb_validate_mode(const struct fb_var_screeninfo *var,
struct fb_info *info);
 extern int fb_parse_edid(unsigned char *edid, struct fb_var_screeninfo *var);
-extern const unsigned char *fb_firmware_edid(struct fb_info *info);
 extern void fb_edid_to_monspecs(unsigned char *edid,
struct fb_monspecs *specs);
 extern void fb_destroy_modedb(struct fb_videomode *modedb);
@@ -774,6 +773,15 @@ extern int of_get_fb_videomode(struct device_node *np,
 extern int fb_videomode_from_videomode(const struct videomode *vm,
   struct fb_videomode *fbmode);
 
+#if defined(CONFIG_FIRMWARE_EDID)
+const unsigned char *fb_firmware_edid(struct fb_info *info);
+#else
+static inline const unsigned char *fb_firmware_edid(struct fb_info *info)
+{
+   return NULL;
+}
+#endif
+
 /* drivers/video/modedb.c */
 #define VESA_MODEDB_SIZE 43
 #define DMT_SIZE 0x50
-- 
2.41.0

[PATCH 10/12] fbdev/core: Use fb_is_primary_device() in fb_firmware_edid()

[Thomas Zimmermann]

Detect the primary VGA device with fb_is_primary_device() in the
implementation of fb_firmware_edid(). Remove the existing code.

Adapt the function to receive an instance of struct fb_info and
update all callers.

Signed-off-by: Thomas Zimmermann 
Cc: Daniel Vetter 
Cc: Helge Deller 
Cc: Antonino Daplas 
Cc: Maik Broemme 
Cc: Randy Dunlap 
---
 drivers/video/fbdev/core/fbmon.c  | 25 +++
 drivers/video/fbdev/i810/i810-i2c.c   |  2 +-
 drivers/video/fbdev/intelfb/intelfbdrv.c  |  2 +-
 drivers/video/fbdev/nvidia/nv_i2c.c   |  2 +-
 drivers/video/fbdev/savage/savagefb-i2c.c |  2 +-
 include/linux/fb.h|  2 +-
 6 files changed, 12 insertions(+), 23 deletions(-)

diff --git a/drivers/video/fbdev/core/fbmon.c b/drivers/video/fbdev/core/fbmon.c
index 79e5bfbdd34c2..35be4431f649a 100644
--- a/drivers/video/fbdev/core/fbmon.c
+++ b/drivers/video/fbdev/core/fbmon.c
@@ -28,7 +28,6 @@
  */
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -1482,31 +1481,21 @@ int fb_validate_mode(const struct fb_var_screeninfo 
*var, struct fb_info *info)
 }
 
 #if defined(CONFIG_FIRMWARE_EDID) && defined(CONFIG_X86)
-
-/*
- * We need to ensure that the EDID block is only returned for
- * the primary graphics adapter.
- */
-
-const unsigned char *fb_firmware_edid(struct device *device)
+const unsigned char *fb_firmware_edid(struct fb_info *info)
 {
-   struct pci_dev *dev = NULL;
-   struct resource *res = NULL;
unsigned char *edid = NULL;
 
-   if (device)
-   dev = to_pci_dev(device);
-
-   if (dev)
-   res = &dev->resource[PCI_ROM_RESOURCE];
-
-   if (res && res->flags & IORESOURCE_ROM_SHADOW)
+   /*
+* We need to ensure that the EDID block is only
+* returned for the primary graphics adapter.
+*/
+   if (fb_is_primary_device(info))
edid = edid_info.dummy;
 
return edid;
 }
 #else
-const unsigned char *fb_firmware_edid(struct device *device)
+const unsigned char *fb_firmware_edid(struct fb_info *info)
 {
return NULL;
 }
diff --git a/drivers/video/fbdev/i810/i810-i2c.c 
b/drivers/video/fbdev/i810/i810-i2c.c
index 7db17d0d8a8cf..b605e96620c1f 100644
--- a/drivers/video/fbdev/i810/i810-i2c.c
+++ b/drivers/video/fbdev/i810/i810-i2c.c
@@ -161,7 +161,7 @@ int i810_probe_i2c_connector(struct fb_info *info, u8 
**out_edid, int conn)
if (conn < par->ddc_num) {
edid = fb_ddc_read(&par->chan[conn].adapter);
} else {
-   const u8 *e = fb_firmware_edid(info->device);
+   const u8 *e = fb_firmware_edid(info);
 
if (e != NULL) {
DPRINTK("i810-i2c: Getting EDID from BIOS\n");
diff --git a/drivers/video/fbdev/intelfb/intelfbdrv.c 
b/drivers/video/fbdev/intelfb/intelfbdrv.c
index a81095b2b1ea5..4633a75e3a613 100644
--- a/drivers/video/fbdev/intelfb/intelfbdrv.c
+++ b/drivers/video/fbdev/intelfb/intelfbdrv.c
@@ -1024,7 +1024,7 @@ static int intelfb_init_var(struct intelfb_info *dinfo)
   sizeof(struct fb_var_screeninfo));
msrc = 5;
} else {
-   const u8 *edid_s = fb_firmware_edid(&dinfo->pdev->dev);
+   const u8 *edid_s = fb_firmware_edid(dinfo->info);
u8 *edid_d = NULL;
 
if (edid_s) {
diff --git a/drivers/video/fbdev/nvidia/nv_i2c.c 
b/drivers/video/fbdev/nvidia/nv_i2c.c
index 0b48965a6420c..632e7d622ebfa 100644
--- a/drivers/video/fbdev/nvidia/nv_i2c.c
+++ b/drivers/video/fbdev/nvidia/nv_i2c.c
@@ -159,7 +159,7 @@ int nvidia_probe_i2c_connector(struct fb_info *info, int 
conn, u8 **out_edid)
 
if (!edid && conn == 1) {
/* try to get from firmware */
-   const u8 *e = fb_firmware_edid(info->device);
+   const u8 *e = fb_firmware_edid(info);
 
if (e != NULL)
edid = kmemdup(e, EDID_LENGTH, GFP_KERNEL);
diff --git a/drivers/video/fbdev/savage/savagefb-i2c.c 
b/drivers/video/fbdev/savage/savagefb-i2c.c
index 80fa87e2ae2ff..cf9c376f76526 100644
--- a/drivers/video/fbdev/savage/savagefb-i2c.c
+++ b/drivers/video/fbdev/savage/savagefb-i2c.c
@@ -227,7 +227,7 @@ int savagefb_probe_i2c_connector(struct fb_info *info, u8 
**out_edid)
 
if (!edid) {
/* try to get from firmware */
-   const u8 *e = fb_firmware_edid(info->device);
+   const u8 *e = fb_firmware_edid(info);
 
if (e)
edid = kmemdup(e, EDID_LENGTH, GFP_KERNEL);
diff --git a/include/linux/fb.h b/include/linux/fb.h
index 1d5c13f34b098..5ffd2223326bf 100644
--- a/include/linux/fb.h
+++ b/include/linux/fb.h
@@ -761,7 +761,7 @@ extern int fb_get_mode(int flags, u32 val, struct 
fb_var_screeninfo *var,
 extern int fb_validate_mode(const struct fb_var_screeninfo *var,
struct fb_info *info);
 extern int fb_parse_edid(unsigne

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Dmitry Baryshkov]

On Thu, 29 Jun 2023 at 15:14, Marijn Suijten
 wrote:
>
> On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:
> > On 27/06/2023 23:14, Marijn Suijten wrote:
> > > Enable and configure the dispcc node on SM6125 for consumption by MDSS
> > > later on.
> > >
> > > Signed-off-by: Marijn Suijten 
> > > ---
> > >   arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
> > >   1 file changed, 25 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
> > > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > index edb03508dba3..a5cc0d43d2d9 100644
> > > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > @@ -3,6 +3,7 @@
> > >* Copyright (c) 2021, Martin Botka 
> > >*/
> > >
> > > +#include 
> > >   #include 
> > >   #include 
> > >   #include 
> > > @@ -1203,6 +1204,30 @@ sram@469 {
> > > reg = <0x0469 0x1>;
> > > };
> > >
> > > +   dispcc: clock-controller@5f0 {
> > > +   compatible = "qcom,sm6125-dispcc";
> > > +   reg = <0x05f0 0x2>;
> > > +   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
> > > +<0>,
> > > +<0>,
> > > +<0>,
> > > +<0>,
> > > +<0>,
> > > +<&gcc GCC_DISP_AHB_CLK>,
> > > +<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
> > > +   clock-names = "bi_tcxo",
> > > + "dsi0_phy_pll_out_byteclk",
> > > + "dsi0_phy_pll_out_dsiclk",
> > > + "dsi1_phy_pll_out_dsiclk",
> > > + "dp_phy_pll_link_clk",
> > > + "dp_phy_pll_vco_div_clk",
> > > + "cfg_ahb_clk",
> > > + "gcc_disp_gpll0_div_clk_src";
> > > +   power-domains = <&rpmpd SM6125_VDDCX>;
> >
> > Would it be logical to specify the required-opps too?
>
> Perhaps, but barely any other SoC aside from sm8x50 sets it on dispcc.
> What should it be, rpmhpd_opp_low_svs?  IIRC we used "svs" for the DSI
> PHY despite not having a reference value downstream (it sets a range of
> NOM-TURBO_NO_CPR, and RETENTION when it's off).

Then for DSI PHY the required-opps should be rpmpd_opp_nom.

For the dispcc I think the rpmpd_opp_ret, the lowest possible vote,
should be enough.

>
> - Marijn
>
> >
> > > +   #clock-cells = <1>;
> > > +   #power-domain-cells = <1>;
> > > +   };
> > > +
> > > apps_smmu: iommu@c60 {
> > > compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
> > > "arm,mmu-500";
> > > reg = <0x0c60 0x8>;
> > >
> >
> > --
> > With best wishes
> > Dmitry
> >



-- 
With best wishes
Dmitry

Re: [PATCH v2 12/15] arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock

[Dmitry Baryshkov]

On Thu, 29 Jun 2023 at 15:09, Marijn Suijten
 wrote:
>
> On 2023-06-29 13:55:28, Dmitry Baryshkov wrote:
> > On 27/06/2023 23:14, Marijn Suijten wrote:
> > > We have a working RPM XO clock; no other driver except rpmcc should be
> > > parenting directly to the fixed-factor xo_board clock nor should it be
> > > reachable by that global name.  Remove the name to that effect, so that
> > > every clock relation is explicitly defined in DTS.
> > >
> > > Reviewed-by: Konrad Dybcio 
> > > Signed-off-by: Marijn Suijten 
> > > ---
> > >   arch/arm64/boot/dts/qcom/sm6125.dtsi | 7 ---
> > >   1 file changed, 4 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
> > > b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > index 722dde560bec..edb03508dba3 100644
> > > --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
> > > @@ -22,7 +22,6 @@ xo_board: xo-board {
> > > compatible = "fixed-clock";
> > > #clock-cells = <0>;
> > > clock-frequency = <1920>;
> > > -   clock-output-names = "xo_board";
> >
> > Why? I'd say, leave it.
>
> The exact reason is explained in the commit message.

Usually we do no not kill the xo_board name for the sake of anybody
still looking for the old name. Weak argument, I know.

>
> >
> > With that fixed:
>
> Hence I don't think it makes sense to "fix" this.
>
> - Marijn
>
> > Reviewed-by: Dmitry Baryshkov 



-- 
With best wishes
Dmitry

Re: [PATCH 07/12] arch/x86: Declare edid_info in

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> The global variable edid_info contains the firmware's EDID information
> as an extension to the regular screen_info on x86. Therefore move it to
> .
>
> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
> architectures that don't provide edid_info. Select it on x86.

I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?

  Arnd

Re: [PATCH 07/12] arch/x86: Declare edid_info in

[Thomas Zimmermann]

Hi

Am 29.06.23 um 14:35 schrieb Arnd Bergmann:

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:

The global variable edid_info contains the firmware's EDID information
as an extension to the regular screen_info on x86. Therefore move it to
.

Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
architectures that don't provide edid_info. Select it on x86.


I'm not sure we need another symbol in addition to
CONFIG_FIRMWARE_EDID. Since all the code behind that
existing symbol is also x86 specific, would it be enough
to just add either 'depends on X86' or 'depends on X86 ||
COMPILE_TEST' there?


FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO 
announces an architecture feature. They do different things.


Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA 
systems. In the future, I want to add support for EDID data from EFI and 
OF as well. It would be stored in edid_info. I assume that the new 
symbol will become useful then.


Before this patchset, I originally wanted to make use of edid_info in 
the simpledrm graphics driver. But I found that the rsp code could use 
some work first. Maybe the patchset are already tailored towards the 
future changes.


Best regards
Thomas



   Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 06/12] arch: Declare screen_info in

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:

> diff --git a/include/asm-generic/screen_info.h 
> b/include/asm-generic/screen_info.h
> new file mode 100644
> index 0..6fd0e50fabfcd
> --- /dev/null
> +++ b/include/asm-generic/screen_info.h
> @@ -0,0 +1,12 @@
> +/* SPDX-License-Identifier: GPL-2.0 */
> +
> +#ifndef _ASM_GENERIC_SCREEN_INFO_H
> +#define _ASM_GENERIC_SCREEN_INFO_H
> +
> +#include 
> +
> +#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
> +extern struct screen_info screen_info;
> +#endif
> +
> +#endif /* _ASM_GENERIC_SCREEN_INFO_H */
> diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
> index eab7081392d50..c764b9a51c24b 100644
> --- a/include/linux/screen_info.h
> +++ b/include/linux/screen_info.h
> @@ -4,6 +4,6 @@
> 
>  #include 
> 
> -extern struct screen_info screen_info;
> +#include 
> 

What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the
#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.

  Arnd

Re: [PATCH 06/12] arch: Declare screen_info in

[WANG Xuerui]

On 2023/6/29 19:45, Thomas Zimmermann wrote:

The variable screen_info does not exist on all architectures. Declare
it in . All architectures that do declare it
will provide it via .

Add the Kconfig token ARCH_HAS_SCREEN_INFO to guard against access on
architectures that don't provide screen_info.

Signed-off-by: Thomas Zimmermann 
Cc: Richard Henderson 
Cc: Ivan Kokshaysky 
Cc: Matt Turner 
Cc: Russell King 
Cc: Catalin Marinas 
Cc: Will Deacon 
Cc: Guo Ren 
Cc: Brian Cain 
Cc: Huacai Chen 
Cc: WANG Xuerui 
Cc: Thomas Bogendoerfer 
Cc: Dinh Nguyen 
Cc: Michael Ellerman 
Cc: Nicholas Piggin 
Cc: Christophe Leroy 
Cc: Paul Walmsley 
Cc: Palmer Dabbelt 
Cc: Albert Ou 
Cc: Yoshinori Sato 
Cc: Rich Felker 
Cc: John Paul Adrian Glaubitz 
Cc: "David S. Miller" 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: Borislav Petkov 
Cc: Dave Hansen 
Cc: x...@kernel.org
Cc: "H. Peter Anvin" 
Cc: Chris Zankel 
Cc: Max Filippov 
Cc: Helge Deller 
Cc: Arnd Bergmann 
Cc: Kees Cook 
Cc: "Paul E. McKenney" 
Cc: Peter Zijlstra 
Cc: Frederic Weisbecker 
Cc: Andrew Morton 
Cc: Ard Biesheuvel 
Cc: Sami Tolvanen 
Cc: Juerg Haefliger 
Cc: Geert Uytterhoeven 
Cc: Anshuman Khandual 
Cc: Niklas Schnelle 
Cc: "Russell King (Oracle)" 
Cc: Linus Walleij 
Cc: Sebastian Reichel 
Cc: "Mike Rapoport (IBM)" 
Cc: "Kirill A. Shutemov" 
Cc: Zi Yan 
---
  arch/Kconfig  |  6 ++
  arch/alpha/Kconfig|  1 +
  arch/arm/Kconfig  |  1 +
  arch/arm64/Kconfig|  1 +
  arch/csky/Kconfig |  1 +
  arch/hexagon/Kconfig  |  1 +
  arch/ia64/Kconfig |  1 +
  arch/loongarch/Kconfig|  1 +
  arch/mips/Kconfig |  1 +
  arch/nios2/Kconfig|  1 +
  arch/powerpc/Kconfig  |  1 +
  arch/riscv/Kconfig|  1 +
  arch/sh/Kconfig   |  1 +
  arch/sparc/Kconfig|  1 +
  arch/x86/Kconfig  |  1 +
  arch/xtensa/Kconfig   |  1 +
  drivers/video/Kconfig |  3 +++
  include/asm-generic/Kbuild|  1 +
  include/asm-generic/screen_info.h | 12 
  include/linux/screen_info.h   |  2 +-
  20 files changed, 38 insertions(+), 1 deletion(-)
  create mode 100644 include/asm-generic/screen_info.h

diff --git a/arch/Kconfig b/arch/Kconfig
index 205fd23e0cada..2f58293fd7bcb 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -1466,6 +1466,12 @@ config ARCH_HAS_NONLEAF_PMD_YOUNG
  address translations. Page table walkers that clear the accessed bit
  may use this capability to reduce their search space.
  
+config ARCH_HAS_SCREEN_INFO

+   bool
+   help
+ Selected by architectures that provide a global instance of
+ screen_info.
+
  source "kernel/gcov/Kconfig"
  
  source "scripts/gcc-plugins/Kconfig"

[snip]
diff --git a/arch/loongarch/Kconfig b/arch/loongarch/Kconfig
index d38b066fc931b..6aab2fb7753da 100644
--- a/arch/loongarch/Kconfig
+++ b/arch/loongarch/Kconfig
@@ -13,6 +13,7 @@ config LOONGARCH
select ARCH_HAS_FORTIFY_SOURCE
select ARCH_HAS_NMI_SAFE_THIS_CPU_OPS
select ARCH_HAS_PTE_SPECIAL
+   select ARCH_HAS_SCREEN_INFO
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_INLINE_READ_LOCK if !PREEMPTION
select ARCH_INLINE_READ_LOCK_BH if !PREEMPTION
[snip]


Acked-by: WANG Xuerui  # loongarch

Thanks!

--
WANG "xen0n" Xuerui

Linux/LoongArch mailing list: https://lore.kernel.org/loongarch/

Re: [PATCH v5 1/1] drm/doc: Document DRM device reset expectations

[André Almeida]

Em 27/06/2023 18:17, André Almeida escreveu:

Em 27/06/2023 14:47, Christian König escreveu:

Am 27.06.23 um 15:23 schrieb André Almeida:

Create a section that specifies how to deal with DRM device resets for
kernel and userspace drivers.

Acked-by: Pekka Paalanen 
Signed-off-by: André Almeida 
---

v4: 
https://lore.kernel.org/lkml/20230626183347.55118-1-andrealm...@igalia.com/


Changes:
  - Grammar fixes (Randy)

  Documentation/gpu/drm-uapi.rst | 68 ++
  1 file changed, 68 insertions(+)

diff --git a/Documentation/gpu/drm-uapi.rst 
b/Documentation/gpu/drm-uapi.rst

index 65fb3036a580..3cbffa25ed93 100644
--- a/Documentation/gpu/drm-uapi.rst
+++ b/Documentation/gpu/drm-uapi.rst
@@ -285,6 +285,74 @@ for GPU1 and GPU2 from different vendors, and a 
third handler for

  mmapped regular files. Threads cause additional pain with signal
  handling as well.
+Device reset
+
+
+The GPU stack is really complex and is prone to errors, from 
hardware bugs,
+faulty applications and everything in between the many layers. Some 
errors
+require resetting the device in order to make the device usable 
again. This

+sections describes the expectations for DRM and usermode drivers when a
+device resets and how to propagate the reset status.
+
+Kernel Mode Driver
+--
+
+The KMD is responsible for checking if the device needs a reset, and 
to perform
+it as needed. Usually a hang is detected when a job gets stuck 
executing. KMD
+should keep track of resets, because userspace can query any time 
about the

+reset stats for an specific context.


Maybe drop the part "for a specific context". Essentially the reset 
query could use global counters instead and we won't need the context 
any more here.




Right, I wrote like this to reflect how it's currently implemented.

If follow correctly what you meant, KMD could always notify the global 
count for UMD, and we would move to the UMD the responsibility to manage 
the reset counters, right? This would also simplify my 
DRM_IOCTL_GET_RESET proposal. I'll apply your suggestion to the next doc 
version.




Actually, if we drop the context identifier we would lose the ability to 
track which is the guilty context. Vulkan API doesn't seem to care about 
this, but OpenGL does.



Apart from that this sounds good to me, feel free to add my rb.

Regards,
Christian.

Re: [PATCH 06/12] arch: Declare screen_info in

[Thomas Zimmermann]

Hi

Am 29.06.23 um 15:03 schrieb Arnd Bergmann:

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:


diff --git a/include/asm-generic/screen_info.h
b/include/asm-generic/screen_info.h
new file mode 100644
index 0..6fd0e50fabfcd
--- /dev/null
+++ b/include/asm-generic/screen_info.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef _ASM_GENERIC_SCREEN_INFO_H
+#define _ASM_GENERIC_SCREEN_INFO_H
+
+#include 
+
+#if defined(CONFIG_ARCH_HAS_SCREEN_INFO)
+extern struct screen_info screen_info;
+#endif
+
+#endif /* _ASM_GENERIC_SCREEN_INFO_H */
diff --git a/include/linux/screen_info.h b/include/linux/screen_info.h
index eab7081392d50..c764b9a51c24b 100644
--- a/include/linux/screen_info.h
+++ b/include/linux/screen_info.h
@@ -4,6 +4,6 @@

  #include 

-extern struct screen_info screen_info;
+#include 



What is the purpose of adding a file in asm-generic? If all
architectures use the same generic file, I'd just leave the
declaration in include/linux/. I wouldn't bother adding the


That appears a bit 'un-clean' for something that is defined in 
architecture? But OK, I would not object.



#ifdef either, but I can see how that helps turn a link
error into an earlier compile error.


Yes, that's intentional. If there's a Kconfig token anyway, we can also 
fail early during the build.


Best regards
Thomas



   Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature

Re: [PATCH 07/12] arch/x86: Declare edid_info in

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 15:01, Thomas Zimmermann wrote:
> Am 29.06.23 um 14:35 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> The global variable edid_info contains the firmware's EDID information
>>> as an extension to the regular screen_info on x86. Therefore move it to
>>> .
>>>
>>> Add the Kconfig token ARCH_HAS_EDID_INFO to guard against access on
>>> architectures that don't provide edid_info. Select it on x86.
>> 
>> I'm not sure we need another symbol in addition to
>> CONFIG_FIRMWARE_EDID. Since all the code behind that
>> existing symbol is also x86 specific, would it be enough
>> to just add either 'depends on X86' or 'depends on X86 ||
>> COMPILE_TEST' there?
>
> FIRMWARE_EDID is a user-selectable feature, while ARCH_HAS_EDID_INFO 
> announces an architecture feature. They do different things.

I still have trouble seeing the difference.

> Right now, ARCH_HAS_EDID_INFO only works on the old BIOS-based VESA 
> systems. In the future, I want to add support for EDID data from EFI and 
> OF as well. It would be stored in edid_info. I assume that the new 
> symbol will become useful then.

I don't see why an OF based system would have the same limitation
as legacy BIOS with supporting only a single monitor, if we need
to have a generic representation of EDID data in DT, that would
probably be in a per device property anyway.

I suppose you could use FIRMWARE_EDID on EFI or OF systems without
the need for a global edid_info structure, but that would not
share any code with the current fb_firmware_edid() function.

 Arnd

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
> The variables screen_info and edid_info provide information about
> the system's screen, and possibly EDID data of the connected display.
> Both are defined and set by architecture code. But both variables are
> declared in non-arch header files. Dependencies are at bease loosely
> tracked. To resolve this, move the global state screen_info and its
> companion edid_info into arch/. Only declare them on architectures
> that define them. List dependencies on the variables in the Kconfig
> files. Also clean up the callers.
>
> Patch 1 to 4 resolve a number of unnecessary include statements of
> . The header should only be included in source
> files that access struct screen_info.
>
> Patches 5 to 7 move the declaration of screen_info and edid_info to
> . Architectures that provide either set
> a Kconfig token to enable them.
>
> Patches 8 to 9 make users of screen_info depend on the architecture's
> feature.
>
> Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
> data to make use of existing helpers and the refactored edid_info.
>
> Tested on x86-64. Built for a variety of platforms.

This all looks like a nice cleanup!

> Future directions: with the patchset in place, it will become possible
> to provide screen_info and edid_info only if there are users. Some
> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
> etc. A more uniform approach would be nice. We should also attempt
> to minimize access to the global screen_info as much as possible. To
> do so, some drivers, such as efifb and vesafb, would require an update.
> The firmware's EDID data could possibly made available outside of fbdev.
> For example, the simpledrm and ofdrm drivers could provide such data
> to userspace compositors.

I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.

We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.

  Arnd

Re: [PATCH 6/6] drm/amdgpu: use the new drm_exec object for CS v2

[Christian König]

Am 29.06.23 um 10:20 schrieb Tatsuyuki Ishi:

On 6/28/23 19:44, Christian König wrote:
@@ -958,18 +904,57 @@ static int amdgpu_cs_parser_bos(struct 
amdgpu_cs_parser *p,

  e->user_invalidated = userpage_invalidated;
  }
  -    r = ttm_eu_reserve_buffers(&p->ticket, &p->validated, true,
-   &duplicates);
-    if (unlikely(r != 0)) {
-    if (r != -ERESTARTSYS)
-    DRM_ERROR("ttm_eu_reserve_buffers failed.\n");
-    goto out_free_user_pages;
+    drm_exec_until_all_locked(&p->exec) {
+    r = amdgpu_vm_lock_pd(&fpriv->vm, &p->exec, 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    amdgpu_bo_list_for_each_entry(e, p->bo_list) {
+    /* One fence for TTM and one for each CS job */
+    r = drm_exec_prepare_obj(&p->exec, &e->bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+
+    e->bo_va = amdgpu_vm_bo_find(vm, e->bo);
+    e->range = NULL;

Still leaking.


Scratching my head, I though I fixed this.

Thanks for pointing this out,
Christian.


+    }
+
+    if (p->uf_bo) {
+    r = drm_exec_prepare_obj(&p->exec, &p->uf_bo->tbo.base,
+ 1 + p->gang_size);
+    drm_exec_retry_on_contention(&p->exec);
+    if (unlikely(r))
+    goto out_free_user_pages;
+    }
  }

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Thomas Zimmermann]

Hi

Am 29.06.23 um 15:31 schrieb Arnd Bergmann:

On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:

The variables screen_info and edid_info provide information about
the system's screen, and possibly EDID data of the connected display.
Both are defined and set by architecture code. But both variables are
declared in non-arch header files. Dependencies are at bease loosely
tracked. To resolve this, move the global state screen_info and its
companion edid_info into arch/. Only declare them on architectures
that define them. List dependencies on the variables in the Kconfig
files. Also clean up the callers.

Patch 1 to 4 resolve a number of unnecessary include statements of
. The header should only be included in source
files that access struct screen_info.

Patches 5 to 7 move the declaration of screen_info and edid_info to
. Architectures that provide either set
a Kconfig token to enable them.

Patches 8 to 9 make users of screen_info depend on the architecture's
feature.

Finally, patches 10 to 12 rework fbdev's handling of firmware EDID
data to make use of existing helpers and the refactored edid_info.

Tested on x86-64. Built for a variety of platforms.


This all looks like a nice cleanup!


I guess that patches 1 to 4 are uncontroversial and could be landed 
quickly. Patches 10 to 12 are probably as well.





Future directions: with the patchset in place, it will become possible
to provide screen_info and edid_info only if there are users. Some
architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
etc. A more uniform approach would be nice. We should also attempt
to minimize access to the global screen_info as much as possible. To
do so, some drivers, such as efifb and vesafb, would require an update.
The firmware's EDID data could possibly made available outside of fbdev.
For example, the simpledrm and ofdrm drivers could provide such data
to userspace compositors.


I suspect that most architectures that provide a screen_info only
have this in order to compile the framebuffer drivers, and provide
hardcoded data that does not even reflect any real hardware.


That's quite possible. Only x86's bootparam and EFI code sets 
screen_info from external data. The rest is hardcoded. A number of 
architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE, 
etc. In a later patchset, I wanted to change this such that these users 
of screen_info would enable the feature via select in their Kconfig.


Do you know the reason for this branch in dummycon:

https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21

What is special about arm that dummycon uses the screeninfo?



We can probably reduce the number of architectures that do this
a lot, especially if we get EFI out of the picture.


Can you elaborate?

Best regards
Thomas



   Arnd


--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)


OpenPGP_signature
Description: OpenPGP digital signature

[PATCH v2] drm/i915: Refactor PAT/cache handling

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Informal commit message for now.

I got a bit impatient and curious to see if the idea we discussed would
work so sketched something out. I think it is what I was describing back
then..

So high level idea is to teach the driver what caching modes are hidden
behind PAT indices. Given you already had that in static tables, if we
just turn the tables a bit around and add a driver abstraction of caching
modes this is what happens:

 * We can lose the ugly runtime i915_gem_get_pat_index.

 * We can have a smarter i915_gem_object_has_cache_level, which now can
   use the above mentioned table to understand the caching modes and so
   does not have to pessimistically return true for _any_ input when user
   has set the PAT index. This may improve things even for MTL.

 * We can simplify the debugfs printout to be platform agnostic.

 * We are perhaps opening the door to un-regress the dodgy addition
   made to i915_gem_object_can_bypass_llc? See QQQ/FIXME in the patch.

I hope I did not forget anything, but anyway, please have a read and see
what you think. I think it has potential.

Proper commit message can come later.

Signed-off-by: Tvrtko Ursulin 
Cc: Fei Yang 
---
 drivers/gpu/drm/i915/Makefile |   1 +
 drivers/gpu/drm/i915/display/intel_dpt.c  |   2 +-
 drivers/gpu/drm/i915/display/intel_fb_pin.c   |   2 +-
 .../drm/i915/display/intel_plane_initial.c|   4 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.c|  66 +-
 drivers/gpu/drm/i915/gem/i915_gem_domain.h|   7 +-
 .../gpu/drm/i915/gem/i915_gem_execbuffer.c|  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_internal.c  |   6 +-
 drivers/gpu/drm/i915/gem/i915_gem_mman.c  |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_object.c| 116 +
 drivers/gpu/drm/i915/gem/i915_gem_object.h|   9 +-
 .../gpu/drm/i915/gem/i915_gem_object_types.h  | 117 +++---
 drivers/gpu/drm/i915/gem/i915_gem_shmem.c |  10 +-
 drivers/gpu/drm/i915/gem/i915_gem_stolen.c|  13 +-
 drivers/gpu/drm/i915/gem/i915_gem_ttm_move.c  |  43 ---
 drivers/gpu/drm/i915/gem/i915_gem_userptr.c   |   2 +-
 .../drm/i915/gem/selftests/huge_gem_object.c  |   6 +-
 .../gpu/drm/i915/gem/selftests/huge_pages.c   |   8 +-
 drivers/gpu/drm/i915/gt/gen6_ppgtt.c  |   4 +-
 drivers/gpu/drm/i915/gt/gen8_ppgtt.c  |  19 +--
 drivers/gpu/drm/i915/gt/intel_engine_cs.c |   2 +-
 drivers/gpu/drm/i915/gt/intel_ggtt.c  |  33 ++---
 drivers/gpu/drm/i915/gt/intel_ggtt_gmch.c |   4 +-
 drivers/gpu/drm/i915/gt/intel_gtt.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_gtt.h   |   3 +-
 drivers/gpu/drm/i915/gt/intel_migrate.c   |  11 +-
 drivers/gpu/drm/i915/gt/intel_ppgtt.c |   6 +-
 .../gpu/drm/i915/gt/intel_ring_submission.c   |   2 +-
 drivers/gpu/drm/i915/gt/intel_timeline.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_hangcheck.c  |   2 +-
 drivers/gpu/drm/i915/gt/selftest_migrate.c|   9 +-
 drivers/gpu/drm/i915/gt/selftest_reset.c  |  14 +--
 drivers/gpu/drm/i915/gt/selftest_timeline.c   |   1 +
 drivers/gpu/drm/i915/gt/selftest_tlb.c|   5 +-
 .../gpu/drm/i915/gt/selftest_workarounds.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_guc.c|   2 +-
 drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c  |   8 +-
 drivers/gpu/drm/i915/i915_cache.c |  72 +++
 drivers/gpu/drm/i915/i915_cache.h |  49 
 drivers/gpu/drm/i915/i915_debugfs.c   |  65 +++---
 drivers/gpu/drm/i915/i915_driver.c|   5 +
 drivers/gpu/drm/i915/i915_drv.h   |   3 +
 drivers/gpu/drm/i915/i915_gem.c   |  21 +---
 drivers/gpu/drm/i915/i915_gpu_error.c |   7 +-
 drivers/gpu/drm/i915/i915_pci.c   |  83 +++--
 drivers/gpu/drm/i915/i915_perf.c  |   2 +-
 drivers/gpu/drm/i915/intel_device_info.h  |   6 +-
 drivers/gpu/drm/i915/selftests/i915_gem.c |   5 +-
 .../gpu/drm/i915/selftests/i915_gem_evict.c   |   8 +-
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  13 +-
 drivers/gpu/drm/i915/selftests/igt_spinner.c  |   2 +-
 .../drm/i915/selftests/intel_memory_region.c  |   4 +-
 .../gpu/drm/i915/selftests/mock_gem_device.c  |  12 +-
 drivers/gpu/drm/i915/selftests/mock_region.c  |   2 +-
 54 files changed, 440 insertions(+), 485 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/i915_cache.c
 create mode 100644 drivers/gpu/drm/i915/i915_cache.h

diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 2be9dd960540..2c3da8f0c78e 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -30,6 +30,7 @@ subdir-ccflags-y += -I$(srctree)/$(src)
 # core driver code
 i915-y += i915_driver.o \
  i915_drm_client.o \
+ i915_cache.o \
  i915_config.o \
  i915_getparam.o \
  i915_ioctl.o \
diff --git a/drivers/gpu/drm/i915/display/intel_dpt.c 
b/drivers/gpu/drm/i915/display/intel_dpt.c

Re: Why does kgd2kfd_interrupt() have to schedule work on a specific CPU?

[Philip Yang]

  
This was to fix application long event wait latency, when app
  shader generates lots of event interrupts in short period, the
  scheduled work no chance to execute on the same CPU core, this
  causes event cannot post/return to app thread which are waiting
  the event. To schedule work on the core of same NUMA node is to
  optimize cache usage in general.

Regards
Philip

On 2023-06-27 11:42, Alex Deucher
  wrote:


  +Felix, Philip

On Tue, Jun 27, 2023 at 4:42 AM Philipp Stanner  wrote:

  

Hello folks,

I'm currently trying to learn more about DRM and discovered the
following code sequence:


drivers/gpu/drm/amd/amdkfd/kfd_device.c, Line 824 on 6.4-rc7

static inline void kfd_queue_work(struct workqueue_struct *wq,
  struct work_struct *work)
{
int cpu, new_cpu;

cpu = new_cpu = smp_processor_id();
do {
new_cpu = cpumask_next(new_cpu, cpu_online_mask) % nr_cpu_ids;
if (cpu_to_node(new_cpu) == numa_node_id())
break;
} while (cpu != new_cpu);

queue_work_on(new_cpu, wq, work);
}

/* This is called directly from KGD at ISR. */
void kgd2kfd_interrupt(struct kfd_dev *kfd, const void *ih_ring_entry)
{
uint32_t patched_ihre[KFD_MAX_RING_ENTRY_SIZE];
bool is_patched = false;
unsigned long flags;

if (!kfd->init_complete)
return;

if (kfd->device_info.ih_ring_entry_size > sizeof(patched_ihre)) {
dev_err_once(kfd_device, "Ring entry too small\n");
return;
}

spin_lock_irqsave(&kfd->interrupt_lock, flags);

if (kfd->interrupts_active
&& interrupt_is_wanted(kfd, ih_ring_entry,
   patched_ihre, &is_patched)
&& enqueue_ih_ring_entry(kfd,
 is_patched ? patched_ihre : ih_ring_entry))
kfd_queue_work(kfd->ih_wq, &kfd->interrupt_work);

spin_unlock_irqrestore(&kfd->interrupt_lock, flags);
}


These functions seem to be exclusively invoked by amdgpu_irq_dispatch()
in amdgpu_irq.c
At first glance it seems to me that it's just a typical scenario taking
place here: Interrupt arises, interrupt submits work to wq, then jumps
back to sleep / former process execution context again.

What I don't understand is why it's apparently important to schedule
the work on a particular CPU.

It seems that the do-while in kfd_queue_work() is searching for a CPU
within the same NUMA-Node. Thus I suspect that this is done because
either
a) performance requires it or
b) the work-function needs access to something that's only available
   within the same node.

I suspect there is an interrupt-related reason why that particular work
should be enqueued on a specific CPU. Just by reading the code alone I
can't really figure out why precisely that's necessary, though.

Does someone have any hints for me? :)

Cheers,
Philipp



  

  

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 15:31, Arnd Bergmann wrote:
> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>
>> Future directions: with the patchset in place, it will become possible
>> to provide screen_info and edid_info only if there are users. Some
>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>> etc. A more uniform approach would be nice. We should also attempt
>> to minimize access to the global screen_info as much as possible. To
>> do so, some drivers, such as efifb and vesafb, would require an update.
>> The firmware's EDID data could possibly made available outside of fbdev.
>> For example, the simpledrm and ofdrm drivers could provide such data
>> to userspace compositors.
>
> I suspect that most architectures that provide a screen_info only
> have this in order to compile the framebuffer drivers, and provide
> hardcoded data that does not even reflect any real hardware.
>
> We can probably reduce the number of architectures that do this
> a lot, especially if we get EFI out of the picture.

I tried to have another look at who uses what, and here are
some observations:

- EFIFB and hyperv are the only ones that are relevant on modern
  systmes, and they are only used on systems using EFI, so they
  could use a separate data structure that is defined as part of
  drivers/firmware/efi. This would likely mean we don't have to
  define a separate screen_info for arm64, loongarch, ia64 and
  riscv, and could separate the legacy vgacon/vesafb stuff on
  arm32 from the efi side.

- FB_SIS can likely be marked 'depends on X86' like FB_INTEL,
  it seems to depend on x86 BOOT_VESA_SUPPORT.

- FB_VGA16 is currently support on powerpc and enabled on
  one defconfig (pasemi), which I'm fairly sure is a mistake,
  so this could be made x86 specific as well.

- VGA_CONSOLE has a complicated Kconfig dependency list that
  lists platforms without VGA support but I think this is better
  expressed with a positive list. It looks like csky, hexagon,
  nios2 and xtensa should be excluded here and not provide
  screen_info.

- arm and mips only need to provide screen_info on machines
  with VGA_CONSOLE. On Arm we have a dependency on
  footbridge/integrator/netwinder, while on mips the
  dependency can be added to the platforms that fill
  the info (mips, malta, sibyte, sni).

- DUMMY_CONSOLE only uses screen_info on arm, and this should
  likely be limited to the three obsolete machines that
  support VGACON. Almost all Arm machines use DT these days
  and won't ever fill the screen info dynamically.

  Arnd

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Sui Jingfeng]

Hi,


Humble ping !


Please share some bandwidth to help reviewing this series, OK ?


As this series is useful for all architecture, I have tested on my X86, 
mips and LoongArch computer.


Questions and comments is also welcome.

If no one response within three days,

I'm going to send a updated version with another trivial improvement, OK?

On 2023/6/13 11:01, Sui Jingfeng wrote:

From: Sui Jingfeng 

The vga_is_firmware_default() function is arch-dependent, it's probably
wrong if we simply remove the arch guard. As the VRAM BAR which contains
firmware framebuffer may move, while the lfb_base and lfb_size members of
the screen_info does not change accordingly. In short, it should take the
re-allocation of the PCI BAR into consideration.

With the observation that device drivers or video aperture helpers may
have better knowledge about which PCI bar contains the firmware fb,
which could avoid the need to iterate all of the PCI BARs. But as a PCI
function at pci/vgaarb.c, vga_is_firmware_default() is not suitable to
make such an optimization since it is loaded too early.

There are PCI display controllers that don't have a dedicated VRAM bar,
this function will lose its effectiveness in such a case. Luckily, the
device driver can provide an accurate workaround.

Therefore, this patch introduces a callback that allows the device driver
to tell the VGAARB if the device is the default boot device. This patch
only intends to introduce the mechanism, while the implementation is left
to the device driver authors. Also honor the comment: "Clients have two
callback mechanisms they can use"

Cc: Alex Deucher 
Cc: Christian Konig 
Cc: Pan Xinhui 
Cc: David Airlie 
Cc: Daniel Vetter 
Cc: Jani Nikula 
Cc: Joonas Lahtinen 
Cc: Rodrigo Vivi 
Cc: Tvrtko Ursulin 
Cc: Ben Skeggs 
Cc: Karol Herbst 
Cc: Lyude Paul 
Cc: Bjorn Helgaas 
Cc: Alex Williamson 
Cc: Maarten Lankhorst 
Cc: Maxime Ripard 
Cc: Thomas Zimmermann 
Cc: Hawking Zhang 
Cc: Mario Limonciello 
Cc: Lijo Lazar 
Cc: YiPeng Chai 
Cc: Bokun Zhang 
Cc: Likun Gao 
Cc: Ville Syrjala 
Cc: Jason Gunthorpe 
CC: Kevin Tian 
Cc: Cornelia Huck 
Cc: Yishai Hadas 
Cc: Abhishek Sahu 
Cc: Yi Liu 
Signed-off-by: Sui Jingfeng 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_device.c |  2 +-
  drivers/gpu/drm/i915/display/intel_vga.c   |  3 +--
  drivers/gpu/drm/nouveau/nouveau_vga.c  |  2 +-
  drivers/gpu/drm/radeon/radeon_device.c |  2 +-
  drivers/pci/vgaarb.c   | 21 -
  drivers/vfio/pci/vfio_pci_core.c   |  2 +-
  include/linux/vgaarb.h |  8 +---
  7 files changed, 30 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index 5c7d40873ee2..7a096f2d5c16 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -3960,7 +3960,7 @@ int amdgpu_device_init(struct amdgpu_device *adev,
/* this will fail for cards that aren't VGA class devices, just
 * ignore it */
if ((adev->pdev->class >> 8) == PCI_CLASS_DISPLAY_VGA)
-   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode);
+   vga_client_register(adev->pdev, amdgpu_device_vga_set_decode, 
NULL);
  
  	px = amdgpu_device_supports_px(ddev);
  
diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c

index 286a0bdd28c6..98d7d4dffe9f 100644
--- a/drivers/gpu/drm/i915/display/intel_vga.c
+++ b/drivers/gpu/drm/i915/display/intel_vga.c
@@ -115,7 +115,6 @@ intel_vga_set_decode(struct pci_dev *pdev, bool 
enable_decode)
  
  int intel_vga_register(struct drm_i915_private *i915)

  {
-
struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
int ret;
  
@@ -127,7 +126,7 @@ int intel_vga_register(struct drm_i915_private *i915)

 * then we do not take part in VGA arbitration and the
 * vga_client_register() fails with -ENODEV.
 */
-   ret = vga_client_register(pdev, intel_vga_set_decode);
+   ret = vga_client_register(pdev, intel_vga_set_decode, NULL);
if (ret && ret != -ENODEV)
return ret;
  
diff --git a/drivers/gpu/drm/nouveau/nouveau_vga.c b/drivers/gpu/drm/nouveau/nouveau_vga.c

index f8bf0ec26844..162b4f4676c7 100644
--- a/drivers/gpu/drm/nouveau/nouveau_vga.c
+++ b/drivers/gpu/drm/nouveau/nouveau_vga.c
@@ -92,7 +92,7 @@ nouveau_vga_init(struct nouveau_drm *drm)
return;
pdev = to_pci_dev(dev->dev);
  
-	vga_client_register(pdev, nouveau_vga_set_decode);

+   vga_client_register(pdev, nouveau_vga_set_decode, NULL);
  
  	/* don't register Thunderbolt eGPU with vga_switcheroo */

if (pci_is_thunderbolt_attached(pdev))
diff --git a/drivers/gpu/drm/radeon/radeon_device.c 
b/drivers/gpu/drm/radeon/radeon_device.c
index afbb3a80c0c6..71f2ff39d6a1 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -

Re: [PATCH 00/12] arch,fbdev: Move screen_info into arch/

[Arnd Bergmann]

On Thu, Jun 29, 2023, at 16:15, Thomas Zimmermann wrote:
> Am 29.06.23 um 15:31 schrieb Arnd Bergmann:
>> On Thu, Jun 29, 2023, at 13:45, Thomas Zimmermann wrote:
>>> Future directions: with the patchset in place, it will become possible
>>> to provide screen_info and edid_info only if there are users. Some
>>> architectures do this by testing for CONFIG_VT, CONFIG_DUMMY_CONSOLE,
>>> etc. A more uniform approach would be nice. We should also attempt
>>> to minimize access to the global screen_info as much as possible. To
>>> do so, some drivers, such as efifb and vesafb, would require an update.
>>> The firmware's EDID data could possibly made available outside of fbdev.
>>> For example, the simpledrm and ofdrm drivers could provide such data
>>> to userspace compositors.
>> 
>> I suspect that most architectures that provide a screen_info only
>> have this in order to compile the framebuffer drivers, and provide
>> hardcoded data that does not even reflect any real hardware.
>
> That's quite possible. Only x86's bootparam and EFI code sets 
> screen_info from external data. The rest is hardcoded. A number of 
> architectures protect screen_info with CONFIG_VT, CONFIG_DUMMY_CONSOLE, 
> etc. In a later patchset, I wanted to change this such that these users 
> of screen_info would enable the feature via select in their Kconfig.
>
> Do you know the reason for this branch in dummycon:
>
> https://elixir.bootlin.com/linux/v6.4/source/drivers/video/console/dummycon.c#L21
>
> What is special about arm that dummycon uses the screeninfo?

I can only guess myself, but I see that the values are only ever
set from the old ATAGS data, and not from DT on any of the
modern ones, and my interpretation is that this is meant to
match whatever the vga console was set to on the three
platforms that support vgacon.
 
I see this was added in linux-2.1.111, just before the
corresponding sparc specific hack was removed, but I don't have
patch descriptions from that era. Russell might remember, or know
if that is actually still needed.

   Arnd

RE: [PATCH v2 0/3] Checksum Region with new CRTC properties

[Liu, HaoPing (Alan)]

[AMD Official Use Only - General]

Dear DRM development community,

I also developed an IGT for testing this checksum_region feature.
Please check it at: https://patchwork.freedesktop.org/series/120017/
Thank you and welcome any feedback.

Best Regards,
Alan

-Original Message-
From: Alan Liu 
Sent: Sunday, June 18, 2023 6:39 PM
To: dri-devel@lists.freedesktop.org
Cc: Wentland, Harry ; Gong, Lili (Sophia) 
; Lin, Wayne ; Liu, HaoPing (Alan) 
; Liu, HaoPing (Alan) 
Subject: [PATCH v2 0/3] Checksum Region with new CRTC properties

Dear DRM development community,

We'd like to introduce the implementation of the new crtc properties.

First of all, please let me introduce the problem we try to address. With the 
popularity of electric vehicles, the car vendors have increasing requirement 
for ensuring the integrity of the critical content on the display. For example, 
tell-tales are icons to indicate malfunction or operation on a car system. For 
safty concern, car vendors always want to make sure these icons are not 
tampered and can be correctly displayed on the instrument cluster.

To address this problem, since modern display control hardware is able to 
calculate the CRC checksum of the display content, we are thinking of a feature 
to let userspace specify a region on display, and we can utilize the hardware 
to calculate the CRC checksum as frames scanned out, and finally, provide the 
checksum for userspace for validation purpose.
In this case, since the icons themselves are often fixed over static 
backgrounds, the CRC of the pixels in the region can be known in advance. So 
one of the usage of the region and corresponding CRC result is that as users 
know the CRC checksum of the tell-tales in advance, at runtime they can 
retrieve the CRC value from kernel for validation as frames are scanned out.

We implement this feature and call it checksum region. To let userspace set a 
region and retrieve the corresponding CRC value, we provide 2 new properties, 
CHECKSUM_REGION and CHECKSUM_CRC. Both of them are blob properties under CRTC, 
and the detailed struct of the two properties are listed below. One for 
userspace to set the region to kernel, and the other for userspace to retrieve 
CRC values from kernel. Upon userspace submitting the 4 coordinate values with 
checksum_region_enable true, kernel instructs DC hardware to calculate the CRC 
value accordingly as frames scanned out. The result CRC value of RGB colors are 
then stored in CHECKSUM_CRC property, with a reference frame count for 
userspace to know which frame the CRCs are calculated at.

/**
 * struct drm_checksum_region - The enablement and region of checksum_region
 * @x_start: Horizontal starting coordinate of the region.
 * @y_start: Vertical starting coordinate of the region.
 * @x_end: Horizontal ending coordinate of the region.
 * @y_end: Vertical ending coordinate of the region.
 * @checksum_region_enable: To enable or disable checksum_region.
 *
 * Userspace uses this structure to configure the region and enablement for
 * checksum_region. Userspace should not submit a region out of the displayable
 * region because there is nothing to display and need protection.
 */
struct drm_checksum_region {
__u32 x_start;
__u32 y_start;
__u32 x_end;
__u32 y_end;
__u8 checksum_region_enable;
__u8 pad[7];
};

/**
 * struct drm_checksum_crc - The CRC value of the corresponding checksum region.
 * @crc_r: CRC value of red color.
 * @crc_g: CRC value of green color.
 * @crc_b: CRC value of blue color.
 * @frame_count: a referenced frame count to indicate which frame the CRC values
 *  are generated at.
 *
 * Userspace uses this structure to retrieve the CRC values of the current
 * checksum region. @frame_count will be reset once a new region is updated or
 * it reaches a maximum value. Currently these CRC values are designed to
 * be validated with pre-saved CRC values, so userspace doesn't need to concern
 * about the algorithm used to compute the CRC.
 */
struct drm_checksum_crc {
__u32 crc_r;
__u32 crc_g;
__u32 crc_b;
__u32 frame_count;
};

To better introduce the usage of this feature, we also have a paired Weston 
application as an reference app to use secure display via the properties. 
Please check the Weston application and see how the application set the region 
and validate the content from the CRC here: 
https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/1236
This application can draw patterns on the display, and allow users to set the 
region and submit it to kernel via properties. With kernel keeping calculating 
the CRC, this example application takes the first CRC as source CRC, and keeps 
retrieving the new CRCs at each frame later. By comparing source CRC with the 
following CRC value, the application can validate if the display content got 
changed down the road.

Finally, let me briefly introduce the patches. There are 3 patches i

Re: [PATCH v2 03/15] dt-bindings: clock: qcom, dispcc-sm6125: Require GCC PLL0 DIV clock

[Rob Herring]

On Tue, 27 Jun 2023 22:14:18 +0200, Marijn Suijten wrote:
> The "gcc_disp_gpll0_div_clk_src" clock is consumed by the driver, will
> be passed from DT, and should be required by the bindings.
> 
> Fixes: 8397c9c0c26b ("dt-bindings: clock: add QCOM SM6125 display clock 
> bindings")
> Signed-off-by: Marijn Suijten 
> ---
>  Documentation/devicetree/bindings/clock/qcom,dispcc-sm6125.yaml | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
> 

Reviewed-by: Rob Herring 

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Bjorn Helgaas]

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> Hi,
> 
> 
> A nouveau developer(Lyude) from redhat send me a R-B,
> 
> Thanks for the developers of nouveau project.
> 
> 
> Please allow me add a link[1] here.
> 
> 
> [1] 
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
   please pick up Lyude's Reviewed-by and include it in the relevant
   patches (as long as you haven't made significant changes to the
   code Lyude reviewed).  Whoever applies this should automatically
   pick up Reviewed-by/Ack/etc that are replies to the version being
   applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
   apply this on v6.4-rc1, but it doesn't apply cleanly.

3) Thanks for including cover letters in your postings.  Please
   include a little changelog in the cover letter so we know what
   changed between v6 and v7, etc.

4) Right now we're in the middle of the v6.5 merge window, so new
   content, e.g., this series, is too late for v6.5.  Most
   maintainers, including me, wait to merge new content until the
   merge window closes and a new -rc1 is tagged.  This merge window
   should close on July 9, and people will start merging content for
   v6.6, typically based on v6.5-rc1.

Bjorn

Re: [PATCH v2 06/15] dt-bindings: display/msm: sc7180-dpu: Describe SM6125

[Rob Herring]

On Tue, 27 Jun 2023 22:14:21 +0200, Marijn Suijten wrote:
> SM6125 is identical to SM6375 except that while downstream also defines
> a throttle clock, its presence results in timeouts whereas SM6375
> requires it to not observe any timeouts.  This is represented by
> reducing the clock array length to 6 so that it cannot be passed.  Note
> that any SoC other than SM6375 (currently SC7180 and SM6350) are
> unconstrained and could either pass or leave out this "throttle" clock.
> 
> Signed-off-by: Marijn Suijten 
> ---
>  .../devicetree/bindings/display/msm/qcom,sc7180-dpu.yaml   | 14 
> ++
>  1 file changed, 14 insertions(+)
> 

Reviewed-by: Rob Herring 

Re: [PATCH 1/4] dt-bindings: regulator: Describe Qualcomm REFGEN regulator

[Rob Herring]

On Wed, Jun 28, 2023 at 06:29:45PM +0200, Konrad Dybcio wrote:
> Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
> regulator, providing reference voltage to on-chip IP, like PHYs.
> It's controlled through MMIO and we can toggle it or read its state back.
> 
> Describe it.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../regulator/qcom,sdm845-refgen-regulator.yaml| 56 
> ++
>  1 file changed, 56 insertions(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
>  
> b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
> new file mode 100644
> index ..19d3eb9db98f
> --- /dev/null
> +++ 
> b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
> @@ -0,0 +1,56 @@
> +# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
> +%YAML 1.2
> +---
> +$id: 
> http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: Qualcomm Technologies, Inc. REFGEN Regulator
> +
> +maintainers:
> +  - Konrad Dybcio 
> +
> +description: |

Don't need '|'.

> +The REFGEN (reference voltage renegator) regulator provides reference

renegator?

> +voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
> +
> +allOf:
> +  - $ref: regulator.yaml#
> +
> +properties:
> +  compatible:
> +oneOf:
> +  - items:
> +  - enum:
> +  - qcom,sc7180-refgen-regulator
> +  - qcom,sc8180x-refgen-regulator
> +  - qcom,sm8150-refgen-regulator
> +  - const: qcom,sdm845-refgen-regulator
> +
> +  - items:
> +  - enum:
> +  - qcom,sc7280-refgen-regulator
> +  - qcom,sc8280xp-refgen-regulator
> +  - qcom,sm6350-refgen-regulator
> +  - qcom,sm6375-refgen-regulator
> +  - qcom,sm8350-refgen-regulator
> +  - const: qcom,sm8250-refgen-regulator
> +
> +  - enum:
> +  - qcom,sdm845-refgen-regulator
> +  - qcom,sm8250-refgen-regulator
> +
> +  reg: true

Need to define how many.

> +
> +required:
> +  - compatible
> +  - reg
> +
> +unevaluatedProperties: false
> +
> +examples:
> +  - |
> +regulator@162f000 {
> +  compatible = "qcom,sm8250-refgen-regulator";
> +  reg = <0 0x0162f000 0 0x84>;

Default cell size is 1.

> +};
> +...
> 
> -- 
> 2.41.0
> 

Re: [PATCH 3/4] dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply

[Rob Herring]

On Wed, 28 Jun 2023 18:29:47 +0200, Konrad Dybcio wrote:
> DSI host needs REFGEN to be enabled (if it's present on a given platform).
> Allow consuming it.
> 
> Signed-off-by: Konrad Dybcio 
> ---
>  .../devicetree/bindings/display/msm/dsi-controller-main.yaml  | 4 
> 
>  1 file changed, 4 insertions(+)
> 

Acked-by: Rob Herring 

Re: [PATCH v3] drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN

[Teres Alexis, Alan Previn]

On Wed, 2023-06-28 at 21:44 +, Brost, Matthew wrote:
> On Wed, Jun 28, 2023 at 11:17:18AM -0700, Alan Previn wrote:
> > In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
> > GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
> > where all command formats are defined in units of dwords so that '1'
> > is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
> > dwords). However, h2g_write was incorrectly assuming that
> > GUC_CTB_MSG_MAX_LEN was in bytes. Fix this.
> 
alan:snip
> > diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
> > index 22bc9ce846db..aa04b5c4822f 100644
> > --- a/drivers/gpu/drm/xe/xe_guc_ct.c
> > +++ b/drivers/gpu/drm/xe/xe_guc_ct.c
> > @@ -401,19 +401,21 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
> > *action, u32 len,
> >  {
> > struct xe_device *xe = ct_to_xe(ct);
> > struct guc_ctb *h2g = &ct->ctbs.h2g;
> > -   u32 cmd[GUC_CTB_MSG_MAX_LEN / sizeof(u32)];
> > -   u32 cmd_len = len + GUC_CTB_HDR_LEN;
> > -   u32 cmd_idx = 0, i;
> > +#define H2G_CT_HEADERS (GUC_CTB_HDR_LEN + 1) /* one DW CTB header and one 
> > DW HxG header */
> 
> Hate to nit pick but again this should be above the h2g_write per
> feedback from Oden on Xe in general.
> 
> Otherwise LGTM.
> 
> With the nit addressed:
> 
> Reviewed-by: Matthew Brost 

Thanks for reviewing. My bad on the #define - you mentioned that before.
Will fix that now.
...alan

Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Sui Jingfeng]

Hi,

On 2023/6/29 23:54, Bjorn Helgaas wrote:

On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:

Hi,


A nouveau developer(Lyude) from redhat send me a R-B,

Thanks for the developers of nouveau project.


Please allow me add a link[1] here.


[1] 
https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca...@redhat.com/

1) Thanks for this.  If you post another version of this series,
please pick up Lyude's Reviewed-by and include it in the relevant
patches (as long as you haven't made significant changes to the
code Lyude reviewed).


Yes, no significant changes. Just fix typo.

I also would like to add support for other DRM drivers.

But I think this deserve another patch.


  Whoever applies this should automatically
pick up Reviewed-by/Ack/etc that are replies to the version being
applied, but they won't go through previous revisions to find them.

2) Please mention the commit to which the series applies.  I tried to
apply this on v6.4-rc1, but it doesn't apply cleanly.


Since I'm a graphic driver developer, I'm using drm-tip.

I just have already pulled, it still apply cleanly on drm-tip.


3) Thanks for including cover letters in your postings.  Please
include a little changelog in the cover letter so we know what
changed between v6 and v7, etc.


No change between v6 and v7,

it seems that it is because the mailbox don't allow me to sending too 
many mails a day.


so some of the patch is failed to delivery because out of quota.



4) Right now we're in the middle of the v6.5 merge window, so new
content, e.g., this series, is too late for v6.5.  Most
maintainers, including me, wait to merge new content until the
merge window closes and a new -rc1 is tagged.  This merge window
should close on July 9, and people will start merging content for
v6.6, typically based on v6.5-rc1.


I'm wondering

Would you will merge all of the patches in this series (e.g. including 
the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?


Or just part of them?

Emm, I don't know because my patch seems across different subsystem of 
Linux kernel.


There is also a developer for AMDGPU (Mario) give me a R-B for the 
patch-0002 of this series.


So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-0006 
are already OK(got reviewed by).


Those 5 patch are already qualified to be merged, I think.

I means that if you could merge those 5 patch first, then there no need 
to send another version again.


I will refine the rest patch with more details and description.

I'm fear of making too much noise.


Bjorn

[PATCH] drm/i915/quirk: Add quirk for devices that cannot be dimmed

[Allen Ballway]

Cybernet T10C cannot be dimmed without the backlight strobing. Create a
new quirk to lock the minimum brightness to the highest supported value.
This aligns the device with its behavior on Windows, which will not
lower the brightness below maximum.

Signed-off-by: Allen Ballway 
---
V2 -> V3: Fix typo.
V1 -> V2: Fix style issue.

.../gpu/drm/i915/display/intel_backlight.c|  5 
 drivers/gpu/drm/i915/display/intel_quirks.c   | 27 +++
 drivers/gpu/drm/i915/display/intel_quirks.h   |  1 +
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/i915/display/intel_backlight.c 
b/drivers/gpu/drm/i915/display/intel_backlight.c
index 2e8f17c045222..f015563d3ebd5 100644
--- a/drivers/gpu/drm/i915/display/intel_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_backlight.c
@@ -1192,6 +1192,11 @@ static u32 get_backlight_min_vbt(struct intel_connector 
*connector)

drm_WARN_ON(&i915->drm, panel->backlight.pwm_level_max == 0);

+   if (intel_has_quirk(i915, QUIRK_NO_DIM)) {
+   /* Cannot dim backlight, set minimum to highest value */
+   return panel->backlight.pwm_level_max - 1;
+   }
+
/*
 * XXX: If the vbt value is 255, it makes min equal to max, which leads
 * to problems. There are such machines out there. Either our
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.c 
b/drivers/gpu/drm/i915/display/intel_quirks.c
index a280448df771a..910c95840a539 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.c
+++ b/drivers/gpu/drm/i915/display/intel_quirks.c
@@ -65,6 +65,12 @@ static void quirk_no_pps_backlight_power_hook(struct 
drm_i915_private *i915)
drm_info(&i915->drm, "Applying no pps backlight power quirk\n");
 }

+static void quirk_no_dim(struct drm_i915_private *i915)
+{
+   intel_set_quirk(i915, QUIRK_NO_DIM);
+   drm_info(&i915->drm, "Applying no dim quirk\n");
+}
+
 struct intel_quirk {
int device;
int subsystem_vendor;
@@ -90,6 +96,12 @@ static int intel_dmi_no_pps_backlight(const struct 
dmi_system_id *id)
return 1;
 }

+static int intel_dmi_no_dim(const struct dmi_system_id *id)
+{
+   DRM_INFO("No dimming allowed on %s\n", id->ident);
+   return 1;
+}
+
 static const struct intel_dmi_quirk intel_dmi_quirks[] = {
{
.dmi_id_list = &(const struct dmi_system_id[]) {
@@ -136,6 +148,20 @@ static const struct intel_dmi_quirk intel_dmi_quirks[] = {
},
.hook = quirk_no_pps_backlight_power_hook,
},
+   {
+   .dmi_id_list = &(const struct dmi_system_id[]) {
+   {
+   .callback = intel_dmi_no_dim,
+   .ident = "Cybernet T10C Tablet",
+   .matches = {DMI_EXACT_MATCH(DMI_BOARD_VENDOR,
+   "Cybernet 
Manufacturing Inc."),
+   DMI_EXACT_MATCH(DMI_BOARD_NAME, 
"T10C Tablet"),
+   },
+   },
+   { }
+   },
+   .hook = quirk_no_dim,
+   },
 };

 static struct intel_quirk intel_quirks[] = {
@@ -218,6 +244,7 @@ void intel_init_quirks(struct drm_i915_private *i915)
 q->subsystem_device == PCI_ANY_ID))
q->hook(i915);
}
+
for (i = 0; i < ARRAY_SIZE(intel_dmi_quirks); i++) {
if (dmi_check_system(*intel_dmi_quirks[i].dmi_id_list) != 0)
intel_dmi_quirks[i].hook(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_quirks.h 
b/drivers/gpu/drm/i915/display/intel_quirks.h
index 10a4d163149fd..b41c7bbf0a5e3 100644
--- a/drivers/gpu/drm/i915/display/intel_quirks.h
+++ b/drivers/gpu/drm/i915/display/intel_quirks.h
@@ -17,6 +17,7 @@ enum intel_quirk_id {
QUIRK_INVERT_BRIGHTNESS,
QUIRK_LVDS_SSC_DISABLE,
QUIRK_NO_PPS_BACKLIGHT_POWER_HOOK,
+   QUIRK_NO_DIM,
 };

 void intel_init_quirks(struct drm_i915_private *i915);
--
2.41.0.255.g8b1d071c50-goog

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders

[Abhinav Kumar]

On 6/22/2023 4:37 PM, Abhinav Kumar wrote:



On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:

On 23/06/2023 01:37, Abhinav Kumar wrote:



On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:

On 22/06/2023 02:01, Abhinav Kumar wrote:



On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:

On 21/06/2023 18:17, Marijn Suijten wrote:

On 2023-06-20 14:38:34, Jessica Zhang wrote:


+    if (phys_enc->hw_intf->ops.enable_widebus)
+ phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf);


No. Please provide a single function which takes necessary
configuration, including compression and wide_bus_enable.



There are two ways to look at this. Your point is coming from 
the
perspective that its programming the same register but just a 
different

bit. But that will also make it a bit confusing.


My point is to have a high-level function that configures the 
INTF for

the CMD mode. This way it can take a structure with necessary
configuration bits.


Hi Dmitry,

After discussing this approach with Abhinav, we still have a few
questions about it:

Currently, only 3 of the 32 bits for INTF_CONFIG2 are being used 
(the
rest are reserved with no plans of being programmed in the 
future). Does

this still justify the use of a struct to pass in the necessary
configuration?


No.  The point Dmitry is making is **not** about this concidentally
using the same register, but about adding a common codepath to 
enable

compression on this hw_intf (regardless of the registers it needs to
touch).


Actually to setup INTF for CMD stream (which is equal to setting 
up compression at this point).




Yes it should be setup intf for cmd and not enable compression.

Widebus and compression are different features and we should be 
able to control them independently.


We just enable them together for DSI. So a separation is necessary.

But I am still not totally convinced we even need to go down the 
path for having an op called setup_intf_cmd() which takes in a 
struct like


struct dpu_cmd_intf_cfg {
 bool data_compress;
 bool widebus_en;
};

As we have agreed that we will not touch the video mode timing 
engine path, it leaves us with only two bits.


And like I said, its not that these two bits always go together. We 
want to be able to control them independently which means that its 
not necessary both bits program the same register one by one. We 
might just end up programming one of them if we just use widebus.


Thats why I am still leaning on keeping this approach.


I do not like the idea of having small functions being called 
between modules. So, yes there will a config of two booleans, but it 
is preferable (and more scalable) compared to separate callbacks.




I definitely agree with the scalable part and I even cross checked 
that the number of usable bitfields of this register is going up from 
one chipset to the other although once again that depends on whether 
we will use those features.


For that reason I am not opposed to the struct idea.

But there is also another pattern i am seeing which worries me. 
Usable bitfields sometimes even reduce. For those cases, if we go 
with a pre-defined struct it ends up with redundant members as those 
bitfields go away.


With the function op based approach, we just call the op if the 
feature bit / core revision.


So I wanted to check once more about the fact that we should consider 
not just expansion but also reduction.


As we have to support all generations, there is no actual reduction. 
Newer SoCs do not have particular feature/bit, but older ones do. By 
having multiple optional ops we just move this knowledge from 
ops->complex_callback() to _setup_block_ops(). But more importantly 
the caller gets more complicated. Instead of just calling 
ops->set_me_up(), it has to check all the optional callbacks and call 
the one by one.




Alright, I am thinking that perhaps because this register is kind of 
unique that its actually controlling a specific setting in the datapath, 
downstream also has separate ops for this.


But thats fine, we can go ahead with the struct based approach.



As data_compress has already landed, let me introduced the struct along 
with the core_revision based approach in the core_revision series and 
this series will expand that struct to include widebus too.

Re: [GIT PULL] fbdev fixes for v6.5-rc1

[pr-tracker-bot]

The pull request you sent on Tue, 27 Jun 2023 08:17:50 +0200:

> http://git.kernel.org/pub/scm/linux/kernel/git/deller/linux-fbdev.git 
> tags/fbdev-for-6.5-rc1

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/675285ad819293844018aa8096ba9a6d7c77b90b

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [Freedreno] [PATCH 2/3] drm/msm/dpu: Set DATABUS_WIDEN on command mode encoders

[Jessica Zhang]

On 6/29/2023 10:26 AM, Abhinav Kumar wrote:



On 6/22/2023 4:37 PM, Abhinav Kumar wrote:



On 6/22/2023 4:14 PM, Dmitry Baryshkov wrote:

On 23/06/2023 01:37, Abhinav Kumar wrote:



On 6/21/2023 4:46 PM, Dmitry Baryshkov wrote:

On 22/06/2023 02:01, Abhinav Kumar wrote:



On 6/21/2023 9:36 AM, Dmitry Baryshkov wrote:

On 21/06/2023 18:17, Marijn Suijten wrote:

On 2023-06-20 14:38:34, Jessica Zhang wrote:


+    if (phys_enc->hw_intf->ops.enable_widebus)
+ phys_enc->hw_intf->ops.enable_widebus(phys_enc->hw_intf);


No. Please provide a single function which takes necessary
configuration, including compression and wide_bus_enable.



There are two ways to look at this. Your point is coming 
from the
perspective that its programming the same register but just 
a different

bit. But that will also make it a bit confusing.


My point is to have a high-level function that configures the 
INTF for

the CMD mode. This way it can take a structure with necessary
configuration bits.


Hi Dmitry,

After discussing this approach with Abhinav, we still have a few
questions about it:

Currently, only 3 of the 32 bits for INTF_CONFIG2 are being 
used (the
rest are reserved with no plans of being programmed in the 
future). Does

this still justify the use of a struct to pass in the necessary
configuration?


No.  The point Dmitry is making is **not** about this concidentally
using the same register, but about adding a common codepath to 
enable
compression on this hw_intf (regardless of the registers it 
needs to

touch).


Actually to setup INTF for CMD stream (which is equal to setting 
up compression at this point).




Yes it should be setup intf for cmd and not enable compression.

Widebus and compression are different features and we should be 
able to control them independently.


We just enable them together for DSI. So a separation is necessary.

But I am still not totally convinced we even need to go down the 
path for having an op called setup_intf_cmd() which takes in a 
struct like


struct dpu_cmd_intf_cfg {
 bool data_compress;
 bool widebus_en;
};

As we have agreed that we will not touch the video mode timing 
engine path, it leaves us with only two bits.


And like I said, its not that these two bits always go together. 
We want to be able to control them independently which means that 
its not necessary both bits program the same register one by one. 
We might just end up programming one of them if we just use widebus.


Thats why I am still leaning on keeping this approach.


I do not like the idea of having small functions being called 
between modules. So, yes there will a config of two booleans, but 
it is preferable (and more scalable) compared to separate callbacks.




I definitely agree with the scalable part and I even cross checked 
that the number of usable bitfields of this register is going up 
from one chipset to the other although once again that depends on 
whether we will use those features.


For that reason I am not opposed to the struct idea.

But there is also another pattern i am seeing which worries me. 
Usable bitfields sometimes even reduce. For those cases, if we go 
with a pre-defined struct it ends up with redundant members as those 
bitfields go away.


With the function op based approach, we just call the op if the 
feature bit / core revision.


So I wanted to check once more about the fact that we should 
consider not just expansion but also reduction.


As we have to support all generations, there is no actual reduction. 
Newer SoCs do not have particular feature/bit, but older ones do. By 
having multiple optional ops we just move this knowledge from 
ops->complex_callback() to _setup_block_ops(). But more importantly 
the caller gets more complicated. Instead of just calling 
ops->set_me_up(), it has to check all the optional callbacks and call 
the one by one.




Alright, I am thinking that perhaps because this register is kind of 
unique that its actually controlling a specific setting in the 
datapath, downstream also has separate ops for this.


But thats fine, we can go ahead with the struct based approach.



As data_compress has already landed, let me introduced the struct along 
with the core_revision based approach in the core_revision series and 
this series will expand that struct to include widebus too.


Acked. Will rebase on top of the core_revision series and add widebus to 
the config struct.


Thanks,

Jessica Zhang

RE: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function callback to vga_client_register

[Limonciello, Mario]

[Public]

> -Original Message-
> From: 15330273...@189.cn <15330273...@189.cn>
> Sent: Thursday, June 29, 2023 12:00 PM
> To: Bjorn Helgaas ; Sui Jingfeng
> 
> Cc: Bjorn Helgaas ; linux-fb...@vger.kernel.org;
> Cornelia Huck ; Karol Herbst ;
> nouv...@lists.freedesktop.org; Joonas Lahtinen
> ; dri-devel@lists.freedesktop.org; Chai,
> Thomas ; Limonciello, Mario
> ; Gao, Likun ; David
> Airlie ; Ville Syrjala ; Yi 
> Liu
> ; k...@vger.kernel.org; amd-...@lists.freedesktop.org;
> Jason Gunthorpe ; Ben Skeggs ; linux-
> p...@vger.kernel.org; Kevin Tian ; Lazar, Lijo
> ; Thomas Zimmermann ;
> Zhang, Bokun ; intel-...@lists.freedesktop.org;
> Maarten Lankhorst ; Jani Nikula
> ; Alex Williamson
> ; Abhishek Sahu ;
> Maxime Ripard ; Rodrigo Vivi ;
> Tvrtko Ursulin ; Yishai Hadas
> ; Pan, Xinhui ; linux-
> ker...@vger.kernel.org; Daniel Vetter ; Deucher, Alexander
> ; Koenig, Christian
> ; Zhang, Hawking 
> Subject: Re: [PATCH v7 6/8] PCI/VGA: Introduce is_boot_device function
> callback to vga_client_register
>
> Hi,
>
> On 2023/6/29 23:54, Bjorn Helgaas wrote:
> > On Thu, Jun 22, 2023 at 01:08:15PM +0800, Sui Jingfeng wrote:
> >> Hi,
> >>
> >>
> >> A nouveau developer(Lyude) from redhat send me a R-B,
> >>
> >> Thanks for the developers of nouveau project.
> >>
> >>
> >> Please allow me add a link[1] here.
> >>
> >>
> >> [1]
> https://lore.kernel.org/all/0afadc69f99a36bc9d03ecf54ff25859dbc10e28.ca
> m...@redhat.com/
> > 1) Thanks for this.  If you post another version of this series,
> > please pick up Lyude's Reviewed-by and include it in the relevant
> > patches (as long as you haven't made significant changes to the
> > code Lyude reviewed).
>
> Yes, no significant changes. Just fix typo.
>
> I also would like to add support for other DRM drivers.
>
> But I think this deserve another patch.
>
> >   Whoever applies this should automatically
> > pick up Reviewed-by/Ack/etc that are replies to the version being
> > applied, but they won't go through previous revisions to find them.
> >
> > 2) Please mention the commit to which the series applies.  I tried to
> > apply this on v6.4-rc1, but it doesn't apply cleanly.
>
> Since I'm a graphic driver developer, I'm using drm-tip.
>
> I just have already pulled, it still apply cleanly on drm-tip.
>
> > 3) Thanks for including cover letters in your postings.  Please
> > include a little changelog in the cover letter so we know what
> > changed between v6 and v7, etc.
>
> No change between v6 and v7,
>
> it seems that it is because the mailbox don't allow me to sending too
> many mails a day.
>
> so some of the patch is failed to delivery because out of quota.
>
>
> > 4) Right now we're in the middle of the v6.5 merge window, so new
> > content, e.g., this series, is too late for v6.5.  Most
> > maintainers, including me, wait to merge new content until the
> > merge window closes and a new -rc1 is tagged.  This merge window
> > should close on July 9, and people will start merging content for
> > v6.6, typically based on v6.5-rc1.
>
> I'm wondering
>
> Would you will merge all of the patches in this series (e.g. including
> the patch for drm/amdgpu(7/8) and drm/radeon(8/8)) ?
>
> Or just part of them?
>
> Emm, I don't know because my patch seems across different subsystem of
> Linux kernel.
>
> There is also a developer for AMDGPU (Mario) give me a R-B for the
> patch-0002 of this series.
>
> So, at least, PATCH-0001, PATCH-0002, PATCH-0003, PATCH-0004, PATCH-
> 0006
> are already OK(got reviewed by).
>
> Those 5 patch are already qualified to be merged, I think.

I think what you can do is pick up all the tags in your next version.  Once the
whole series has tags we can discuss how it merges.

>
> I means that if you could merge those 5 patch first, then there no need
> to send another version again.
>
> I will refine the rest patch with more details and description.
>
> I'm fear of making too much noise.
>
> > Bjorn

Re: [git pull] drm for 6.5-rc1

[pr-tracker-bot]

The pull request you sent on Thu, 29 Jun 2023 11:28:02 +1000:

> git://anongit.freedesktop.org/drm/drm tags/drm-next-2023-06-29

has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/1b722407a13b7f8658d2e26917791f32805980a2

Thank you!

-- 
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html

Re: [RFC PATCH 0/3] Support for Solid Fill Planes

[Jessica Zhang]

On 6/27/2023 3:10 PM, Abhinav Kumar wrote:



On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:

On 28/06/2023 00:27, Jessica Zhang wrote:



On 6/27/2023 12:58 AM, Pekka Paalanen wrote:

On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang  wrote:


On 11/7/2022 11:37 AM, Ville Syrjälä wrote:

On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:

Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer 
is set

to NULL, memory fetch will be disabled.


Thinking a bit more universally I wonder if there should be
some kind of enum property:

enum plane_pixel_source {
FB,
COLOR,
LIVE_FOO,
LIVE_BAR,
...
}


Reviving this thread as this was the initial comment suggesting to
implement pixel_source as an enum.

I think the issue with having pixel_source as an enum is how to decide
what counts as a NULL commit.

Currently, setting the FB to NULL will disable the plane. So I'm
guessing we will extend that logic to "if there's no pixel_source set
for the plane, then it will be a NULL commit and disable the plane".

In that case, the question then becomes when to set the 
pixel_source to

NONE. Because if we do that when setting a NULL FB (or NULL solid_fill
blob), it then forces userspace to set one property before the other.


Right, that won't work.

There is no ordering between each property being set inside a single
atomic commit. They can all be applied to kernel-internal state
theoretically simultaneously, or any arbitrary random order, and the
end result must always be the same. Hence, setting one property cannot
change the state of another mutable property. I believe that doing
otherwise would make userspace fragile and hard to get right.

I guess there might be an exception to that rule when the same property
is set multiple times in a single atomic commit; the last setting in
the array prevails. That's universal and not a special-case between two
specific properties.

Because of that, I'm thinking of having pixel_source be represented 
by a

bitmask instead. That way, we will simply unset the corresponding
pixel_source bit when passing in a NULL FB/solid_fill blob. Then, in
order to detect whether a commit is NULL or has a valid pixel 
source, we

can just check if pixel_source == 0.


Sounds fine to me at first hand, but isn't there the enum property that
says if the kernel must look at solid_fill blob *or* FB_ID?

If enum prop says "use solid_fill prop", the why would changes to FB_ID
do anything? Is it for backwards-compatibility with KMS clients that do
not know about the enum prop?

It seems like that kind of backwards-compatiblity will cause problems
in trying to reason about the atomic state, as explained above, leading
to very delicate and fragile conditions where things work intuitively.
Hence, I'm not sure backwards-compatibility is wanted. This won't be
the first or the last KMS property where an unexpected value left over
will make old atomic KMS clients silently malfunction up to showing no
recognisable picture at all. *If* that problem needs solving, there
have been ideas floating around about resetting everything to nice
values so that userspace can ignore what it does not understand. So far
there has been no real interest in solving that problem in the kernel
though.

Legacy non-atomic UAPI wrappers can do whatever they want, and program
any (new) properties they want in order to implement the legacy
expectations, so that does not seem to be a problem.


Hi Pekka and Dmitry,

After reading through both of your comments, I think I have a better 
understanding of the pixel_source implementation now.


So to summarize, we want to expose another property called 
"pixel_source" to userspace that will default to FB (as to not break 
legacy userspace).


If userspace wants to use solid fill planes, it will set both the 
solid_fill *and* pixel_source properties to a valid blob and COLOR 
respectively. If it wants to use FB, it will set FB_ID and 
pixel_source to a valid FB and FB.


Here's a table illustrating what I've described above:

+-+-+-+
| Use Case    | Legacy Userspace    | solid_fill-aware    |
| | | Userspace   |
+=+=+=+
| Valid FB    | pixel_source = FB   | pixel_source = FB   |
| | FB_ID = valid FB    | FB_ID = valid FB    |
+-+-+-+
| Valid   | pixel_source = COLOR    | N/A |
| solid_fill blob | solid_fill = valid blob | |


Probably these two cells were swapped.



Ack, yes they were swapped.


+-+-+-+
| NULL commit | pixel_source = FB   | pixel_source = FB   |
| 

Re: [Freedreno] [RFC PATCH 0/3] Support for Solid Fill Planes

[Jessica Zhang]

On 6/29/2023 12:29 AM, Pekka Paalanen wrote:

On Wed, 28 Jun 2023 09:40:21 -0700
Jessica Zhang  wrote:


On 6/28/2023 12:34 AM, Pekka Paalanen wrote:

On Tue, 27 Jun 2023 15:10:19 -0700
Abhinav Kumar  wrote:
   

On 6/27/2023 2:59 PM, Dmitry Baryshkov wrote:

On 28/06/2023 00:27, Jessica Zhang wrote:



On 6/27/2023 12:58 AM, Pekka Paalanen wrote:

On Mon, 26 Jun 2023 16:02:50 -0700
Jessica Zhang  wrote:
 

On 11/7/2022 11:37 AM, Ville Syrjälä wrote:

On Fri, Oct 28, 2022 at 03:59:49PM -0700, Jessica Zhang wrote:

Introduce and add support for COLOR_FILL and COLOR_FILL_FORMAT
properties. When the color fill value is set, and the framebuffer
is set
to NULL, memory fetch will be disabled.


Thinking a bit more universally I wonder if there should be
some kind of enum property:

enum plane_pixel_source {
  FB,
  COLOR,
  LIVE_FOO,
  LIVE_BAR,
  ...
}


Reviving this thread as this was the initial comment suggesting to
implement pixel_source as an enum.

I think the issue with having pixel_source as an enum is how to decide
what counts as a NULL commit.

Currently, setting the FB to NULL will disable the plane. So I'm
guessing we will extend that logic to "if there's no pixel_source set
for the plane, then it will be a NULL commit and disable the plane".

In that case, the question then becomes when to set the pixel_source to
NONE. Because if we do that when setting a NULL FB (or NULL solid_fill
blob), it then forces userspace to set one property before the other.


Right, that won't work.

There is no ordering between each property being set inside a single
atomic commit. They can all be applied to kernel-internal state
theoretically simultaneously, or any arbitrary random order, and the
end result must always be the same. Hence, setting one property cannot
change the state of another mutable property. I believe that doing
otherwise would make userspace fragile and hard to get right.

I guess there might be an exception to that rule when the same property
is set multiple times in a single atomic commit; the last setting in
the array prevails. That's universal and not a special-case between two
specific properties.
 

Because of that, I'm thinking of having pixel_source be represented
by a
bitmask instead. That way, we will simply unset the corresponding
pixel_source bit when passing in a NULL FB/solid_fill blob. Then, in
order to detect whether a commit is NULL or has a valid pixel
source, we
can just check if pixel_source == 0.


Sounds fine to me at first hand, but isn't there the enum property that
says if the kernel must look at solid_fill blob *or* FB_ID?

If enum prop says "use solid_fill prop", the why would changes to FB_ID
do anything? Is it for backwards-compatibility with KMS clients that do
not know about the enum prop?

It seems like that kind of backwards-compatiblity will cause problems
in trying to reason about the atomic state, as explained above, leading
to very delicate and fragile conditions where things work intuitively.
Hence, I'm not sure backwards-compatibility is wanted. This won't be
the first or the last KMS property where an unexpected value left over
will make old atomic KMS clients silently malfunction up to showing no
recognisable picture at all. *If* that problem needs solving, there
have been ideas floating around about resetting everything to nice
values so that userspace can ignore what it does not understand. So far
there has been no real interest in solving that problem in the kernel
though.

Legacy non-atomic UAPI wrappers can do whatever they want, and program
any (new) properties they want in order to implement the legacy
expectations, so that does not seem to be a problem.


Hi Pekka and Dmitry,

After reading through both of your comments, I think I have a better
understanding of the pixel_source implementation now.

So to summarize, we want to expose another property called
"pixel_source" to userspace that will default to FB (as to not break
legacy userspace).

If userspace wants to use solid fill planes, it will set both the
solid_fill *and* pixel_source properties to a valid blob and COLOR
respectively. If it wants to use FB, it will set FB_ID and
pixel_source to a valid FB and FB.

Here's a table illustrating what I've described above:

+-+-+-+
| Use Case    | Legacy Userspace    | solid_fill-aware    |
| | | Userspace   |
+=+=+=+
| Valid FB    | pixel_source = FB   | pixel_source = FB   |
| | FB_ID = valid FB    | FB_ID = valid FB    |
+-+-+-+
| Valid   | pixel_source = COLOR    | N/A |
| solid_fill blob | solid_fill = valid blob | |


Probably these two cells were swapped.
  


Ack, yes th

[PATCH AUTOSEL 6.3 12/17] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2

[Sasha Levin]

From: Jeff Layton 

[ Upstream commit 54d217406afe250d7a768783baaa79a035f21d38 ]

I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:

amdgpu :30:00.0: [drm] Failed to create MST payload for port 
6d3a3885: -5

...followed by an Oops due to a NULL pointer dereference.

Switch to using mgr->dev instead of state->dev since "state" can be
NULL in some cases.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
Suggested-by: Jani Nikula 
Signed-off-by: Jeff Layton 
Reviewed-by: Jani Nikula 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230419112447.18471-1-jlay...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..e2e21ce79510e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct 
drm_dp_mst_topology_mgr *mgr,
 
/* Skip failed payloads */
if (payload->vc_start_slot == -1) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
-- 
2.39.2

[PATCH AUTOSEL 6.1 09/12] drm: use mgr->dev in drm_dbg_kms in drm_dp_add_payload_part2

[Sasha Levin]

From: Jeff Layton 

[ Upstream commit 54d217406afe250d7a768783baaa79a035f21d38 ]

I've been experiencing some intermittent crashes down in the display
driver code. The symptoms are ususally a line like this in dmesg:

amdgpu :30:00.0: [drm] Failed to create MST payload for port 
6d3a3885: -5

...followed by an Oops due to a NULL pointer dereference.

Switch to using mgr->dev instead of state->dev since "state" can be
NULL in some cases.

Link: https://bugzilla.redhat.com/show_bug.cgi?id=2184855
Suggested-by: Jani Nikula 
Signed-off-by: Jeff Layton 
Reviewed-by: Jani Nikula 
Reviewed-by: Lyude Paul 
Signed-off-by: Lyude Paul 
Link: 
https://patchwork.freedesktop.org/patch/msgid/20230419112447.18471-1-jlay...@kernel.org
Signed-off-by: Sasha Levin 
---
 drivers/gpu/drm/display/drm_dp_mst_topology.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/display/drm_dp_mst_topology.c 
b/drivers/gpu/drm/display/drm_dp_mst_topology.c
index 38dab76ae69ea..e2e21ce79510e 100644
--- a/drivers/gpu/drm/display/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/display/drm_dp_mst_topology.c
@@ -3404,7 +3404,7 @@ int drm_dp_add_payload_part2(struct 
drm_dp_mst_topology_mgr *mgr,
 
/* Skip failed payloads */
if (payload->vc_start_slot == -1) {
-   drm_dbg_kms(state->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
+   drm_dbg_kms(mgr->dev, "Part 1 of payload creation for %s 
failed, skipping part 2\n",
payload->port->connector->name);
return -EIO;
}
-- 
2.39.2

Re: [PATCH v2 12/15] arm64: dts: qcom: sm6125: Switch fixed xo_board clock to RPM XO clock

[Konrad Dybcio]

On 29.06.2023 14:26, Dmitry Baryshkov wrote:
> On Thu, 29 Jun 2023 at 15:09, Marijn Suijten
>  wrote:
>>
>> On 2023-06-29 13:55:28, Dmitry Baryshkov wrote:
>>> On 27/06/2023 23:14, Marijn Suijten wrote:
 We have a working RPM XO clock; no other driver except rpmcc should be
 parenting directly to the fixed-factor xo_board clock nor should it be
 reachable by that global name.  Remove the name to that effect, so that
 every clock relation is explicitly defined in DTS.

 Reviewed-by: Konrad Dybcio 
 Signed-off-by: Marijn Suijten 
 ---
   arch/arm64/boot/dts/qcom/sm6125.dtsi | 7 ---
   1 file changed, 4 insertions(+), 3 deletions(-)

 diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
 b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 index 722dde560bec..edb03508dba3 100644
 --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
 +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 @@ -22,7 +22,6 @@ xo_board: xo-board {
 compatible = "fixed-clock";
 #clock-cells = <0>;
 clock-frequency = <1920>;
 -   clock-output-names = "xo_board";
>>>
>>> Why? I'd say, leave it.
>>
>> The exact reason is explained in the commit message.
> 
> Usually we do no not kill the xo_board name for the sake of anybody
> still looking for the old name. Weak argument, I know.
The only users are (rg -l '"xo_board"' drivers):

drivers/clk/qcom/mmcc-msm8974.c
drivers/clk/qcom/a53-pll.c
drivers/clk/qcom/gcc-msm8974.c
drivers/clk/qcom/clk-smd-rpm.c
drivers/clk/qcom/mmcc-msm8996.c
drivers/clk/qcom/gcc-msm8916.c
drivers/clk/qcom/gcc-apq8084.c
drivers/clk/qcom/gcc-msm8996.c
drivers/clk/qcom/mmcc-apq8084.c
drivers/clk/qcom/clk-rpmh.c
drivers/gpu/drm/msm/hdmi/hdmi_phy_8996.c

This platform only binds clk-smd-rpm, but patch 11 provides a
direct reference in the DT.

Konrad

> 
>>
>>>
>>> With that fixed:
>>
>> Hence I don't think it makes sense to "fix" this.
>>
>> - Marijn
>>
>>> Reviewed-by: Dmitry Baryshkov 
> 
> 
> 

[PATCH v2 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.

Signed-off-by: Abhinav Kumar 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
to_dpu_encoder_phys_cmd(phys_enc);
struct dpu_hw_ctl *ctl;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
 
ctl = phys_enc->hw_ctl;
if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
phys_enc->hw_pp->idx);
 
-   if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-   phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+   if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 0x7) {
+   struct intf_dpu_datapath_cfg datapath_cfg = { 0 };
+
+   datapath_cfg.data_compress = true;
+   phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);
+   }
 }
 
 static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void dpu_hw_intf_disable_autorefresh(struct 
dpu_hw_intf *intf,
 
 }
 
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+struct intf_dpu_datapath_cfg 
*datapath_cfg)
 {
u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
 
-   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+   if (datapath_cfg->data_compress)
+   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
 
DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
 }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
 
-   if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-   ops->enable_compression = dpu_hw_intf_enable_compression;
+   ops->program_datapath = dpu_hw_intf_program_datapath;
 }
 
 struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -48,6 +48,11 @@ struct intf_status {
u32 line_count; /* current line count including blanking */
 };
 
+struct intf_dpu_datapath_cfg {
+   u8 data_compress;   /* enable data compress between dpu and dsi */
+   /* can be expanded for other programmable bits */
+};
+
 /**
  * struct dpu_hw_intf_ops : Interface to the interface Hw driver functions
  *  Assumption is these functions will be called after clocks are enabled
@@ -70,7 +75,7 @@ struct intf_status {
  * @get_autorefresh:Retrieve autorefresh config from hardware
  *  Return: 0 on success, -ETIMEDOUT on timeout
  * @vsync_sel:  Select vsync signal for tear-effect 
configuration
- * @enable_compression: Enable data compression
+ * @program_datapath:   Program the DPU to interface datapath for 
relevant chipsets
  */
 struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -108,7 +113,14 @@ struct dpu_hw_intf_ops {
 */
void (*disable_autorefresh)(struct dpu_hw_intf *intf, uint32_t 
encoder_id, u16 vdisplay);
 
-   void (*enable_compression)(struct dpu_hw_intf *intf);
+   /**
+* Program the DPU to intf datapath by specifying
+* which of the settings need to be programmed for
+* use-cases which need DPU-intf handshake such as
+* widebus, compression etc.
+

[PATCH v2 3/3] drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog

[Abhinav Kumar]

Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0de507d4d7b7..35994e676450 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -105,7 +105,7 @@
 BIT(DPU_INTF_STATUS_SUPPORTED) | \
 BIT(DPU_DATA_HCTL_EN))
 
-#define INTF_SC7280_MASK (INTF_SC7180_MASK | BIT(DPU_INTF_DATA_COMPRESS))
+#define INTF_SC7280_MASK (INTF_SC7180_MASK)
 
 #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
 BIT(DPU_WB_UBWC) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8b900be3ea90..572e618150b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -181,7 +181,6 @@ enum {
  * @DPU_DATA_HCTL_ENAllows data to be transferred at different 
rate
  *  than video timing
  * @DPU_INTF_STATUS_SUPPORTED   INTF block has INTF_STATUS register
- * @DPU_INTF_DATA_COMPRESS  INTF block has DATA_COMPRESS register
  * @DPU_INTF_MAX
  */
 enum {
@@ -189,7 +188,6 @@ enum {
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
DPU_INTF_STATUS_SUPPORTED,
-   DPU_INTF_DATA_COMPRESS,
DPU_INTF_MAX
 };
 
-- 
2.40.1

[PATCH v2 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
   enable the bit;

Also, add some of the useful macros back to be able to use dpu core
revision effectively.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v2:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
 16 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+   .core_major_version = 0x3,
+   .core_minor_version = 0x0,
.caps = &msm8998_dpu_caps,
.ubwc = &msm8998_ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+   .core_major_version = 0x4,
+   .core_minor_version = 0x0,
.caps = &sdm845_dpu_caps,
.ubwc = &sdm845_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x0,
.caps = &sm8150_dpu_caps,
.ubwc = &sm8150_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x1,
.caps = &sc8180x_dpu_caps,
.ubwc = &sc8180x_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..e446af90767e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sm8250_perf_data = {
 };
 
 con

[PATCH v3 2/3] drm/msm/dpu: use dpu core's major version to enable data compress

[Abhinav Kumar]

Instead of using a feature bit to decide whether to enable data
compress or not for DSC use-cases, use dpu core's major version instead.
This will avoid defining feature bits for every bit level details of
registers.

Also, rename the intf's enable_compression() op to program_datapath()
and allow it to accept a struct intf_dpu_datapath_cfg to program
all the bits at once. This can be re-used by widebus later on as
well as it touches the same register.

Signed-off-by: Abhinav Kumar 
---
 .../gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c |  9 +++--
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c  |  9 +
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h  | 16 ++--
 3 files changed, 26 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
index b856c6286c85..f4e15b4c4cc9 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder_phys_cmd.c
@@ -50,6 +50,7 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
to_dpu_encoder_phys_cmd(phys_enc);
struct dpu_hw_ctl *ctl;
struct dpu_hw_intf_cfg intf_cfg = { 0 };
+   struct dpu_kms *dpu_kms = phys_enc->dpu_kms;
 
ctl = phys_enc->hw_ctl;
if (!ctl->ops.setup_intf_cfg)
@@ -68,8 +69,12 @@ static void _dpu_encoder_phys_cmd_update_intf_cfg(
phys_enc->hw_intf,
phys_enc->hw_pp->idx);
 
-   if (intf_cfg.dsc != 0 && phys_enc->hw_intf->ops.enable_compression)
-   phys_enc->hw_intf->ops.enable_compression(phys_enc->hw_intf);
+   if (intf_cfg.dsc != 0 && dpu_kms->catalog->core_major_version >= 0x7) {
+   struct intf_dpu_datapath_cfg datapath_cfg = { 0 };
+
+   datapath_cfg.data_compress = true;
+   phys_enc->hw_intf->ops.program_datapath(phys_enc->hw_intf, 
&datapath_cfg);
+   }
 }
 
 static void dpu_encoder_phys_cmd_pp_tx_done_irq(void *arg, int irq_idx)
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
index 5b0f6627e29b..85333df08fbc 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.c
@@ -513,11 +513,13 @@ static void dpu_hw_intf_disable_autorefresh(struct 
dpu_hw_intf *intf,
 
 }
 
-static void dpu_hw_intf_enable_compression(struct dpu_hw_intf *ctx)
+static void dpu_hw_intf_program_datapath(struct dpu_hw_intf *ctx,
+struct intf_dpu_datapath_cfg 
*datapath_cfg)
 {
u32 intf_cfg2 = DPU_REG_READ(&ctx->hw, INTF_CONFIG2);
 
-   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
+   if (datapath_cfg->data_compress)
+   intf_cfg2 |= INTF_CFG2_DCE_DATA_COMPRESS;
 
DPU_REG_WRITE(&ctx->hw, INTF_CONFIG2, intf_cfg2);
 }
@@ -543,8 +545,7 @@ static void _setup_intf_ops(struct dpu_hw_intf_ops *ops,
ops->disable_autorefresh = dpu_hw_intf_disable_autorefresh;
}
 
-   if (cap & BIT(DPU_INTF_DATA_COMPRESS))
-   ops->enable_compression = dpu_hw_intf_enable_compression;
+   ops->program_datapath = dpu_hw_intf_program_datapath;
 }
 
 struct dpu_hw_intf *dpu_hw_intf_init(const struct dpu_intf_cfg *cfg,
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
index 99e21c4137f9..f736dca38463 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_intf.h
@@ -48,6 +48,11 @@ struct intf_status {
u32 line_count; /* current line count including blanking */
 };
 
+struct intf_dpu_datapath_cfg {
+   u8 data_compress;   /* enable data compress between dpu and dsi */
+   /* can be expanded for other programmable bits */
+};
+
 /**
  * struct dpu_hw_intf_ops : Interface to the interface Hw driver functions
  *  Assumption is these functions will be called after clocks are enabled
@@ -70,7 +75,7 @@ struct intf_status {
  * @get_autorefresh:Retrieve autorefresh config from hardware
  *  Return: 0 on success, -ETIMEDOUT on timeout
  * @vsync_sel:  Select vsync signal for tear-effect 
configuration
- * @enable_compression: Enable data compression
+ * @program_datapath:   Program the DPU to interface datapath for 
relevant chipsets
  */
 struct dpu_hw_intf_ops {
void (*setup_timing_gen)(struct dpu_hw_intf *intf,
@@ -108,7 +113,14 @@ struct dpu_hw_intf_ops {
 */
void (*disable_autorefresh)(struct dpu_hw_intf *intf, uint32_t 
encoder_id, u16 vdisplay);
 
-   void (*enable_compression)(struct dpu_hw_intf *intf);
+   /**
+* Program the DPU to intf datapath by specifying
+* which of the settings need to be programmed for
+* use-cases which need DPU-intf handshake such as
+* widebus, compression etc.
+

[PATCH v3 1/3] drm/msm/dpu: re-introduce dpu core revision to the catalog

[Abhinav Kumar]

With [1] dpu core revision was dropped in favor of using the
compatible string from the device tree to select the dpu catalog
being used in the device.

This approach works well however also necessitates adding catalog
entries for small register level details as dpu capabilities and/or
features bloating the catalog unnecessarily. Examples include but
are not limited to data_compress, interrupt register set, widebus etc.

Introduce the dpu core revision back as an entry to the catalog so that
we can just use dpu revision checks and enable those bits which
should be enabled unconditionally and not controlled by a catalog
and also simplify the changes to do something like:

if (dpu_core_revision > x && dpu_core_revision < x)
   enable the bit;

Since dpu's major and minor versions are now separate fields, lets
drop all the DPU_HW_VER macros.

[1]: https://patchwork.freedesktop.org/patch/530891/?series=113910&rev=4

changes in v3:
- drop DPU step version as features are not changing across steps
- add core_major_version / core_minor_version to avoid conflicts
- update the commit text to drop references to the dpu macros

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_2_sc7180.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_3_sm6115.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_4_sm6350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_5_qcm2290.h  | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_9_sm6375.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_0_sm8350.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_7_2_sc7280.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_0_sc8280xp.h | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_8_1_sm8450.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_9_0_sm8550.h   | 2 ++
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h   | 8 ++--
 16 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
index 7d0d0e74c3b0..a5d486783c3f 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_3_0_msm8998.h
@@ -190,6 +190,8 @@ static const struct dpu_perf_cfg msm8998_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_msm8998_cfg = {
+   .core_major_version = 0x3,
+   .core_minor_version = 0x0,
.caps = &msm8998_dpu_caps,
.ubwc = &msm8998_ubwc_cfg,
.mdp_count = ARRAY_SIZE(msm8998_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
index b6098141bb9b..1fdb89a4b7a6 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_4_0_sdm845.h
@@ -194,6 +194,8 @@ static const struct dpu_perf_cfg sdm845_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sdm845_cfg = {
+   .core_major_version = 0x4,
+   .core_minor_version = 0x0,
.caps = &sdm845_dpu_caps,
.ubwc = &sdm845_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sdm845_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
index b5f751354267..129c62cf450d 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_0_sm8150.h
@@ -208,6 +208,8 @@ static const struct dpu_perf_cfg sm8150_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sm8150_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x0,
.caps = &sm8150_dpu_caps,
.ubwc = &sm8150_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sm8150_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
index 8ed2b263c5ea..ca037b070f44 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_5_1_sc8180x.h
@@ -214,6 +214,8 @@ static const struct dpu_perf_cfg sc8180x_perf_data = {
 };
 
 const struct dpu_mdss_cfg dpu_sc8180x_cfg = {
+   .core_major_version = 0x5,
+   .core_minor_version = 0x1,
.caps = &sc8180x_dpu_caps,
.ubwc = &sc8180x_ubwc_cfg,
.mdp_count = ARRAY_SIZE(sc8180x_mdp),
diff --git a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h 
b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
index daebd2170041..e446af90767e 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/catalog/dpu_6_0_sm8250.h
@@ -2

[PATCH v3 3/3] drm/msm/dpu: drop DPU_INTF_DATA_COMPRESS from dpu catalog

[Abhinav Kumar]

Now that all usages of DPU_INTF_DATA_COMPRESS have been replaced
with the dpu core's major revision lets drop DPU_INTF_DATA_COMPRESS
from the catalog completely.

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c | 2 +-
 drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h | 2 --
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
index 0de507d4d7b7..35994e676450 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.c
@@ -105,7 +105,7 @@
 BIT(DPU_INTF_STATUS_SUPPORTED) | \
 BIT(DPU_DATA_HCTL_EN))
 
-#define INTF_SC7280_MASK (INTF_SC7180_MASK | BIT(DPU_INTF_DATA_COMPRESS))
+#define INTF_SC7280_MASK (INTF_SC7180_MASK)
 
 #define WB_SM8250_MASK (BIT(DPU_WB_LINE_MODE) | \
 BIT(DPU_WB_UBWC) | \
diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h 
b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
index 8b900be3ea90..572e618150b8 100644
--- a/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
+++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_hw_catalog.h
@@ -181,7 +181,6 @@ enum {
  * @DPU_DATA_HCTL_ENAllows data to be transferred at different 
rate
  *  than video timing
  * @DPU_INTF_STATUS_SUPPORTED   INTF block has INTF_STATUS register
- * @DPU_INTF_DATA_COMPRESS  INTF block has DATA_COMPRESS register
  * @DPU_INTF_MAX
  */
 enum {
@@ -189,7 +188,6 @@ enum {
DPU_INTF_TE,
DPU_DATA_HCTL_EN,
DPU_INTF_STATUS_SUPPORTED,
-   DPU_INTF_DATA_COMPRESS,
DPU_INTF_MAX
 };
 
-- 
2.40.1

Re: [PATCH v2 13/15] arm64: dts: qcom: sm6125: Add dispcc node

[Konrad Dybcio]

On 29.06.2023 14:24, Dmitry Baryshkov wrote:
> On Thu, 29 Jun 2023 at 15:14, Marijn Suijten
>  wrote:
>>
>> On 2023-06-29 13:56:25, Dmitry Baryshkov wrote:
>>> On 27/06/2023 23:14, Marijn Suijten wrote:
 Enable and configure the dispcc node on SM6125 for consumption by MDSS
 later on.

 Signed-off-by: Marijn Suijten 
 ---
   arch/arm64/boot/dts/qcom/sm6125.dtsi | 25 +
   1 file changed, 25 insertions(+)

 diff --git a/arch/arm64/boot/dts/qcom/sm6125.dtsi 
 b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 index edb03508dba3..a5cc0d43d2d9 100644
 --- a/arch/arm64/boot/dts/qcom/sm6125.dtsi
 +++ b/arch/arm64/boot/dts/qcom/sm6125.dtsi
 @@ -3,6 +3,7 @@
* Copyright (c) 2021, Martin Botka 
*/

 +#include 
   #include 
   #include 
   #include 
 @@ -1203,6 +1204,30 @@ sram@469 {
 reg = <0x0469 0x1>;
 };

 +   dispcc: clock-controller@5f0 {
 +   compatible = "qcom,sm6125-dispcc";
 +   reg = <0x05f0 0x2>;
 +   clocks = <&rpmcc RPM_SMD_XO_CLK_SRC>,
 +<0>,
 +<0>,
 +<0>,
 +<0>,
 +<0>,
 +<&gcc GCC_DISP_AHB_CLK>,
 +<&gcc GCC_DISP_GPLL0_DIV_CLK_SRC>;
 +   clock-names = "bi_tcxo",
 + "dsi0_phy_pll_out_byteclk",
 + "dsi0_phy_pll_out_dsiclk",
 + "dsi1_phy_pll_out_dsiclk",
 + "dp_phy_pll_link_clk",
 + "dp_phy_pll_vco_div_clk",
 + "cfg_ahb_clk",
 + "gcc_disp_gpll0_div_clk_src";
 +   power-domains = <&rpmpd SM6125_VDDCX>;
>>>
>>> Would it be logical to specify the required-opps too?
>>
>> Perhaps, but barely any other SoC aside from sm8x50 sets it on dispcc.
>> What should it be, rpmhpd_opp_low_svs?  IIRC we used "svs" for the DSI
>> PHY despite not having a reference value downstream (it sets a range of
>> NOM-TURBO_NO_CPR, and RETENTION when it's off).
> 
> Then for DSI PHY the required-opps should be rpmpd_opp_nom.
Yes

> 
> For the dispcc I think the rpmpd_opp_ret, the lowest possible vote,
> should be enough.
I'm not 100% sure but not specifying an opp and turning on the domain
***probably*** just sticks with the lowest vote

Konrad
> 
>>
>> - Marijn
>>
>>>
 +   #clock-cells = <1>;
 +   #power-domain-cells = <1>;
 +   };
 +
 apps_smmu: iommu@c60 {
 compatible = "qcom,sm6125-smmu-500", "qcom,smmu-500", 
 "arm,mmu-500";
 reg = <0x0c60 0x8>;

>>>
>>> --
>>> With best wishes
>>> Dmitry
>>>
> 
> 
> 

[PATCH v2 0/4] Qualcomm REFGEN regulator

[Konrad Dybcio]

Recent Qualcomm SoCs have a REFGEN (reference voltage generator) regulator
responsible for providing a reference voltage to some on-SoC IPs (like DSI
or PHYs). It can be turned off when unused to save power.

This series introduces the driver for it and lets the DSI driver
consume it.

Signed-off-by: Konrad Dybcio 
---
Changes in v2:
- Remove "|" from bindings description
- fix 'renegator' typo
- define number of 'reg'
- adjust reg= to size/address-cells = 1
- fix regmap usage
- use C++ comments for the header
- remove now-unused struct qcom_refgen
- use common helpers for sm8250 refgen (simple bit ops)
- add missing FIELD_PREPs (small brain forgot regmap_update_bits
  doesn't do shifting)
- pick up tags
- Link to v1: 
https://lore.kernel.org/r/20230628-topic-refgen-v1-0-126e59573...@linaro.org

---
Konrad Dybcio (4):
  dt-bindings: regulator: Describe Qualcomm REFGEN regulator
  regulator: Introduce Qualcomm REFGEN regulator driver
  dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply
  drm/msm/dsi: Hook up refgen regulator

 .../bindings/display/msm/dsi-controller-main.yaml  |   4 +
 .../regulator/qcom,sdm845-refgen-regulator.yaml|  57 
 drivers/gpu/drm/msm/dsi/dsi_cfg.c  |   2 +
 drivers/regulator/Kconfig  |  10 ++
 drivers/regulator/Makefile |   1 +
 drivers/regulator/qcom-refgen-regulator.c  | 154 +
 6 files changed, 228 insertions(+)
---
base-commit: 5c875096d59010cee4e00da1f9c7bdb07a025dc2
change-id: 20230628-topic-refgen-14fb0b762115

Best regards,
-- 
Konrad Dybcio 

[PATCH v2 1/4] dt-bindings: regulator: Describe Qualcomm REFGEN regulator

[Konrad Dybcio]

Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
regulator, providing reference voltage to on-chip IP, like PHYs.
It's controlled through MMIO and we can toggle it or read its state back.

Describe it.

Signed-off-by: Konrad Dybcio 
---
 .../regulator/qcom,sdm845-refgen-regulator.yaml| 57 ++
 1 file changed, 57 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml 
b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
new file mode 100644
index ..f02f97d4fdd2
--- /dev/null
+++ 
b/Documentation/devicetree/bindings/regulator/qcom,sdm845-refgen-regulator.yaml
@@ -0,0 +1,57 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/regulator/qcom,sdm845-refgen-regulator.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Qualcomm Technologies, Inc. REFGEN Regulator
+
+maintainers:
+  - Konrad Dybcio 
+
+description:
+  The REFGEN (reference voltage generator) regulator provides reference
+  voltage for on-chip IPs (like PHYs) on some Qualcomm SoCs.
+
+allOf:
+  - $ref: regulator.yaml#
+
+properties:
+  compatible:
+oneOf:
+  - items:
+  - enum:
+  - qcom,sc7180-refgen-regulator
+  - qcom,sc8180x-refgen-regulator
+  - qcom,sm8150-refgen-regulator
+  - const: qcom,sdm845-refgen-regulator
+
+  - items:
+  - enum:
+  - qcom,sc7280-refgen-regulator
+  - qcom,sc8280xp-refgen-regulator
+  - qcom,sm6350-refgen-regulator
+  - qcom,sm6375-refgen-regulator
+  - qcom,sm8350-refgen-regulator
+  - const: qcom,sm8250-refgen-regulator
+
+  - enum:
+  - qcom,sdm845-refgen-regulator
+  - qcom,sm8250-refgen-regulator
+
+  reg:
+maxItems: 1
+
+required:
+  - compatible
+  - reg
+
+unevaluatedProperties: false
+
+examples:
+  - |
+regulator@162f000 {
+  compatible = "qcom,sm8250-refgen-regulator";
+  reg = <0x0162f000 0x84>;
+};
+...

-- 
2.41.0

[PATCH v2 3/4] dt-bindings: display/msm: dsi-controller-main: Allow refgen-supply

[Konrad Dybcio]

DSI host needs REFGEN to be enabled (if it's present on a given platform).
Allow consuming it.

Acked-by: Rob Herring 
Signed-off-by: Konrad Dybcio 
---
 .../devicetree/bindings/display/msm/dsi-controller-main.yaml  | 4 
 1 file changed, 4 insertions(+)

diff --git 
a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml 
b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
index 01848bdd5873..76270992305a 100644
--- a/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
+++ b/Documentation/devicetree/bindings/display/msm/dsi-controller-main.yaml
@@ -166,6 +166,10 @@ properties:
 description:
   Phandle to vdd regulator device node
 
+  refgen-supply:
+description:
+  Phandle to REFGEN regulator device node
+
   vcca-supply:
 description:
   Phandle to vdd regulator device node

-- 
2.41.0

[PATCH v2 4/4] drm/msm/dsi: Hook up refgen regulator

[Konrad Dybcio]

Consume the refgen supply on configurations that may use it.

Signed-off-by: Konrad Dybcio 
---
 drivers/gpu/drm/msm/dsi/dsi_cfg.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_cfg.c 
b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
index 8a5fb6df7210..1f98ff74ceb0 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_cfg.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_cfg.c
@@ -160,6 +160,7 @@ static const char * const dsi_v2_4_clk_names[] = {
 
 static const struct regulator_bulk_data dsi_v2_4_regulators[] = {
{ .supply = "vdda", .init_load_uA = 21800 },/* 1.2 V */
+   { .supply = "refgen" },
 };
 
 static const struct msm_dsi_config sdm845_dsi_cfg = {
@@ -191,6 +192,7 @@ static const struct msm_dsi_config sm8550_dsi_cfg = {
 
 static const struct regulator_bulk_data sc7280_dsi_regulators[] = {
{ .supply = "vdda", .init_load_uA = 8350 }, /* 1.2 V */
+   { .supply = "refgen" },
 };
 
 static const struct msm_dsi_config sc7280_dsi_cfg = {

-- 
2.41.0

[PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
regulator, providing reference voltage to on-chip IP, like PHYs.

Add a driver to support toggling that regulator.

Signed-off-by: Konrad Dybcio 
---
 drivers/regulator/Kconfig |  10 ++
 drivers/regulator/Makefile|   1 +
 drivers/regulator/qcom-refgen-regulator.c | 154 ++
 3 files changed, 165 insertions(+)

diff --git a/drivers/regulator/Kconfig b/drivers/regulator/Kconfig
index 2c2405024ace..ea5549d62825 100644
--- a/drivers/regulator/Kconfig
+++ b/drivers/regulator/Kconfig
@@ -978,6 +978,16 @@ config REGULATOR_PWM
  This driver supports PWM controlled voltage regulators. PWM
  duty cycle can increase or decrease the voltage.
 
+config REGULATOR_QCOM_REFGEN
+   tristate "Qualcomm REFGEN regulator driver"
+   depends on REGMAP
+   help
+ This driver supports the MMIO-mapped reference voltage regulator,
+ used internally by some PHYs on many Qualcomm SoCs.
+
+ Say M here if you want to include support for this regulator as
+ a module. The module will be named "qcom-refgen-regulator".
+
 config REGULATOR_QCOM_RPM
tristate "Qualcomm RPM regulator driver"
depends on MFD_QCOM_RPM
diff --git a/drivers/regulator/Makefile b/drivers/regulator/Makefile
index ebfa75379c20..a044ad20e202 100644
--- a/drivers/regulator/Makefile
+++ b/drivers/regulator/Makefile
@@ -107,6 +107,7 @@ obj-$(CONFIG_REGULATOR_MT6380)  += mt6380-regulator.o
 obj-$(CONFIG_REGULATOR_MT6397) += mt6397-regulator.o
 obj-$(CONFIG_REGULATOR_MTK_DVFSRC) += mtk-dvfsrc-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_LABIBB) += qcom-labibb-regulator.o
+obj-$(CONFIG_REGULATOR_QCOM_REFGEN) += qcom-refgen-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPM) += qcom_rpm-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_RPMH) += qcom-rpmh-regulator.o
 obj-$(CONFIG_REGULATOR_QCOM_SMD_RPM) += qcom_smd-regulator.o
diff --git a/drivers/regulator/qcom-refgen-regulator.c 
b/drivers/regulator/qcom-refgen-regulator.c
new file mode 100644
index ..4c442fa3f552
--- /dev/null
+++ b/drivers/regulator/qcom-refgen-regulator.c
@@ -0,0 +1,154 @@
+// SPDX-License-Identifier: GPL-2.0-only
+// Copyright (c) 2017, 2019-2020, The Linux Foundation. All rights reserved.
+// Copyright (c) 2023, Linaro Limited
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define REFGEN_REG_BIAS_EN 0x08
+#define REFGEN_BIAS_EN_MASKGENMASK(2, 0)
+ #define REFGEN_BIAS_EN_ENABLE 0x7
+ #define REFGEN_BIAS_EN_DISABLE0x6
+
+#define REFGEN_REG_BG_CTRL 0x14
+#define REFGEN_BG_CTRL_MASKGENMASK(2, 1)
+ #define REFGEN_BG_CTRL_ENABLE 0x3
+ #define REFGEN_BG_CTRL_DISABLE0x2
+
+#define REFGEN_REG_PWRDWN_CTRL50x80
+#define REFGEN_PWRDWN_CTRL5_MASK   BIT(0)
+ #define REFGEN_PWRDWN_CTRL5_ENABLE0x1
+
+static int qcom_sdm845_refgen_enable(struct regulator_dev *rdev)
+{
+   regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, 
REFGEN_BG_CTRL_MASK,
+  FIELD_PREP(REFGEN_BG_CTRL_MASK, 
REFGEN_BG_CTRL_ENABLE));
+
+   regmap_write(rdev->regmap, REFGEN_REG_BIAS_EN,
+FIELD_PREP(REFGEN_BIAS_EN_MASK, REFGEN_BIAS_EN_ENABLE));
+
+   return 0;
+}
+
+static int qcom_sdm845_refgen_disable(struct regulator_dev *rdev)
+{
+   regmap_write(rdev->regmap, REFGEN_REG_BIAS_EN,
+FIELD_PREP(REFGEN_BIAS_EN_MASK, REFGEN_BIAS_EN_DISABLE));
+
+   regmap_update_bits(rdev->regmap, REFGEN_REG_BG_CTRL, 
REFGEN_BG_CTRL_MASK,
+  FIELD_PREP(REFGEN_BG_CTRL_MASK, 
REFGEN_BG_CTRL_DISABLE));
+
+   return 0;
+}
+
+static int qcom_sdm845_refgen_is_enabled(struct regulator_dev *rdev)
+{
+   u32 val;
+
+   regmap_read(rdev->regmap, REFGEN_REG_BG_CTRL, &val);
+   if (FIELD_GET(REFGEN_BG_CTRL_MASK, val) != REFGEN_BG_CTRL_ENABLE)
+   return 0;
+
+   regmap_read(rdev->regmap, REFGEN_REG_BIAS_EN, &val);
+   if (FIELD_GET(REFGEN_BIAS_EN_MASK, val) != REFGEN_BIAS_EN_ENABLE)
+   return 0;
+
+   return 1;
+}
+
+static struct regulator_desc sdm845_refgen_desc = {
+   .enable_time = 5,
+   .name = "refgen",
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+   .ops = &(struct regulator_ops) {
+   .enable = qcom_sdm845_refgen_enable,
+   .disable= qcom_sdm845_refgen_disable,
+   .is_enabled = qcom_sdm845_refgen_is_enabled,
+   },
+};
+
+static struct regulator_desc sm8250_refgen_desc = {
+   .enable_reg = REFGEN_REG_PWRDWN_CTRL5,
+   .enable_mask = REFGEN_PWRDWN_CTRL5_MASK,
+   .enable_val = REFGEN_PWRDWN_CTRL5_ENABLE,
+   .disable_val = 0,
+   .enable_time = 5,
+   .name = "refgen",
+   .owner = THIS_MODULE,
+   .type = REGULATOR_VOLTAGE,
+  

[PATCH v3] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

[Alan Previn]

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. While implementing this,
use an table of function pointers so its scalable to add additional
waiter functions for future such "wait on dependency" cases that.

Difference from prior versions:
   v3: Rebase to latest drm-tip.
   v2: Based on internal testing, increase the timeout for gsc-proxy
   specific case to 8 seconds.

Signed-off-by: Alan Previn 
Reviewed-by: Zhanjun Dong 

---
 .../gpu/drm/i915/selftests/i915_selftest.c| 61 +++
 1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..a74b7e264d92 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
 #include 
 
 #include "gt/intel_gt_pm.h"
+#include "gt/uc/intel_gsc_fw.h"
+
 #include "i915_driver.h"
 #include "i915_drv.h"
 #include "i915_selftest.h"
@@ -127,6 +129,63 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
 }
 
+static int
+__wait_gsc_proxy_completed(struct drm_i915_private *i915,
+  unsigned long timeout_ms)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw));
+
+   /*
+* For gsc proxy component loading + init, we need a much longer timeout
+* than what CI selftest infrastrucutre currently uses. This longer wait
+* period depends on the kernel config and component driver load 
ordering
+*/
+   if (timeout_ms < 8000)
+   timeout_ms = 8000;
+
+   if (need_to_wait &&
+   (wait_for(intel_gsc_uc_fw_proxy_init_done(&i915->media_gt->uc.gsc, 
true),
+   timeout_ms)))
+   return -ETIME;
+
+   return 0;
+}
+
+struct __startup_waiter {
+   const char *name;
+   int (*wait_to_completed)(struct drm_i915_private *i915, unsigned long 
timeout_ms);
+};
+
+static struct __startup_waiter all_startup_waiters[] = { \
+   {"gsc_proxy", __wait_gsc_proxy_completed} \
+   };
+
+static int __wait_on_all_system_dependencies(struct drm_i915_private *i915)
+{
+   struct __startup_waiter *waiter = all_startup_waiters;
+   int count = ARRAY_SIZE(all_startup_waiters);
+   int ret;
+
+   if (!waiter || !count || !i915)
+   return 0;
+
+   for (; count--; waiter++) {
+   if (!waiter->wait_to_completed)
+   continue;
+   ret = waiter->wait_to_completed(i915, i915_selftest.timeout_ms);
+   if (ret) {
+   pr_info(DRIVER_NAME ": Pre-selftest waiter %s failed 
with %d\n",
+   waiter->name, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
 static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
 {
int err = 0;
 
+   __wait_on_all_system_dependencies(data);
+
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
 

base-commit: 6f8963ce33be65c67e53b16fa18325e12ab76861
-- 
2.39.0

Re: [PATCH v2 2/4] regulator: Introduce Qualcomm REFGEN regulator driver

[Konrad Dybcio]

On 29.06.2023 22:35, Konrad Dybcio wrote:
> Modern Qualcomm SoCs have a REFGEN (reference voltage generator)
> regulator, providing reference voltage to on-chip IP, like PHYs.
> 
> Add a driver to support toggling that regulator.
> 
> Signed-off-by: Konrad Dybcio 
> ---
Ugh. Missed the 'const' here and below. LMK if that warrants a resend
(or.. perhaps you just have other comments)

Konrad
> + .ops = &(struct regulator_ops) {
> + .enable = qcom_sdm845_refgen_enable,
> + .disable= qcom_sdm845_refgen_disable,
> + .is_enabled = qcom_sdm845_refgen_is_enabled,
> + },
> +};
> +
> +static struct regulator_desc sm8250_refgen_desc = {
> + .enable_reg = REFGEN_REG_PWRDWN_CTRL5,
> + .enable_mask = REFGEN_PWRDWN_CTRL5_MASK,
> + .enable_val = REFGEN_PWRDWN_CTRL5_ENABLE,
> + .disable_val = 0,
> + .enable_time = 5,
> + .name = "refgen",
> + .owner = THIS_MODULE,
> + .type = REGULATOR_VOLTAGE,
> + .ops = &(struct regulator_ops) {
> + .enable = regulator_enable_regmap,
> + .disable= regulator_disable_regmap,
> + .is_enabled = regulator_is_enabled_regmap,
> + },
> +};
> +
> +static const struct regmap_config qcom_refgen_regmap_config = {
> + .reg_bits = 32,
> + .reg_stride = 4,
> + .val_bits = 32,
> + .fast_io = true,
> +};
> +
> +static int qcom_refgen_probe(struct platform_device *pdev)
> +{
> + struct regulator_init_data *init_data;
> + struct regulator_config config = {};
> + const struct regulator_desc *rdesc;
> + struct device *dev = &pdev->dev;
> + struct regulator_dev *rdev;
> + struct regmap *regmap;
> + void __iomem *base;
> +
> + rdesc = of_device_get_match_data(dev);
> + if (!rdesc)
> + return -ENODATA;
> +
> + base = devm_platform_ioremap_resource(pdev, 0);
> + if (IS_ERR(base))
> + return PTR_ERR(base);
> +
> + regmap = devm_regmap_init_mmio(dev, base, &qcom_refgen_regmap_config);
> + if (IS_ERR(regmap))
> + return PTR_ERR(regmap);
> +
> + init_data = of_get_regulator_init_data(dev, dev->of_node, rdesc);
> + if (!init_data)
> + return -ENOMEM;
> +
> + config.dev = dev;
> + config.init_data = init_data;
> + config.of_node = dev->of_node;
> + config.regmap = regmap;
> +
> + rdev = devm_regulator_register(dev, rdesc, &config);
> + if (IS_ERR(rdev))
> + return PTR_ERR(rdev);
> +
> + return 0;
> +}
> +
> +static const struct of_device_id qcom_refgen_match_table[] = {
> + { .compatible = "qcom,sdm845-refgen-regulator", .data = 
> &sdm845_refgen_desc },
> + { .compatible = "qcom,sm8250-refgen-regulator", .data = 
> &sm8250_refgen_desc },
> + { }
> +};
> +
> +static struct platform_driver qcom_refgen_driver = {
> + .probe = qcom_refgen_probe,
> + .driver = {
> + .name = "qcom-refgen-regulator",
> + .of_match_table = qcom_refgen_match_table,
> + },
> +};
> +module_platform_driver(qcom_refgen_driver);
> +
> +MODULE_LICENSE("GPL");
> +MODULE_DESCRIPTION("Qualcomm REFGEN regulator driver");
> 

[PATCH v3] drm/xe/guc: Fix h2g_write usage of GUC_CTB_MSG_MAX_LEN

[Alan Previn]

In the ABI header, GUC_CTB_MSG_MIN_LEN is '1' because
GUC_CTB_HDR_LEN is 1. This aligns with H2G/G2H CTB specification
where all command formats are defined in units of dwords so that '1'
is a dword. Accordingly, GUC_CTB_MSG_MAX_LEN is 256-1 (i.e. 255
dwords). However, h2g_write was incorrectly assuming that
GUC_CTB_MSG_MAX_LEN was in bytes. Fix this.

v3: Fix nit on #define location.(Matt)
v2: By correctly treating GUC_CTB_MSG_MAX_LEN as dwords, it causes
a local array to consume 4x the stack size. Rework the function
to avoid consuming stack even if the action size is large. (Matt)

Signed-off-by: Alan Previn 
Reviewed-by: Matthew Brost 

---
 drivers/gpu/drm/xe/xe_guc_ct.c | 31 ++-
 1 file changed, 18 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/xe/xe_guc_ct.c b/drivers/gpu/drm/xe/xe_guc_ct.c
index 22bc9ce846db..aa04b5c4822f 100644
--- a/drivers/gpu/drm/xe/xe_guc_ct.c
+++ b/drivers/gpu/drm/xe/xe_guc_ct.c
@@ -401,19 +401,21 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
*action, u32 len,
 {
struct xe_device *xe = ct_to_xe(ct);
struct guc_ctb *h2g = &ct->ctbs.h2g;
-   u32 cmd[GUC_CTB_MSG_MAX_LEN / sizeof(u32)];
-   u32 cmd_len = len + GUC_CTB_HDR_LEN;
-   u32 cmd_idx = 0, i;
+#define H2G_CT_HEADERS (GUC_CTB_HDR_LEN + 1) /* one DW CTB header and one DW 
HxG header */
+   u32 cmd[H2G_CT_HEADERS];
u32 tail = h2g->info.tail;
+   u32 full_len;
struct iosys_map map = IOSYS_MAP_INIT_OFFSET(&h2g->cmds,
 tail * sizeof(u32));
 
+   full_len = len + GUC_CTB_HDR_LEN;
+
lockdep_assert_held(&ct->lock);
-   XE_BUG_ON(len * sizeof(u32) > GUC_CTB_MSG_MAX_LEN);
+   XE_BUG_ON(full_len > (GUC_CTB_MSG_MAX_LEN - GUC_CTB_HDR_LEN));
XE_BUG_ON(tail > h2g->info.size);
 
/* Command will wrap, zero fill (NOPs), return and check credits again 
*/
-   if (tail + cmd_len > h2g->info.size) {
+   if (tail + full_len > h2g->info.size) {
xe_map_memset(xe, &map, 0, 0,
  (h2g->info.size - tail) * sizeof(u32));
h2g_reserve_space(ct, (h2g->info.size - tail));
@@ -428,30 +430,33 @@ static int h2g_write(struct xe_guc_ct *ct, const u32 
*action, u32 len,
 * dw1: HXG header (including action code)
 * dw2+: action data
 */
-   cmd[cmd_idx++] = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
+   cmd[0] = FIELD_PREP(GUC_CTB_MSG_0_FORMAT, GUC_CTB_FORMAT_HXG) |
FIELD_PREP(GUC_CTB_MSG_0_NUM_DWORDS, len) |
FIELD_PREP(GUC_CTB_MSG_0_FENCE, ct_fence_value);
if (want_response) {
-   cmd[cmd_idx++] =
+   cmd[1] =
FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_REQUEST) |
FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
   GUC_HXG_EVENT_MSG_0_DATA0, action[0]);
} else {
-   cmd[cmd_idx++] =
+   cmd[1] =
FIELD_PREP(GUC_HXG_MSG_0_TYPE, GUC_HXG_TYPE_EVENT) |
FIELD_PREP(GUC_HXG_EVENT_MSG_0_ACTION |
   GUC_HXG_EVENT_MSG_0_DATA0, action[0]);
}
-   for (i = 1; i < len; ++i)
-   cmd[cmd_idx++] = action[i];
+
+   /* H2G header in cmd[1] replaces action[0] so: */
+   --len;
+   ++action;
 
/* Write H2G ensuring visable before descriptor update */
-   xe_map_memcpy_to(xe, &map, 0, cmd, cmd_len * sizeof(u32));
+   xe_map_memcpy_to(xe, &map, 0, cmd, H2G_CT_HEADERS * sizeof(u32));
+   xe_map_memcpy_to(xe, &map, H2G_CT_HEADERS * sizeof(u32), action, len * 
sizeof(u32));
xe_device_wmb(ct_to_xe(ct));
 
/* Update local copies */
-   h2g->info.tail = (tail + cmd_len) % h2g->info.size;
-   h2g_reserve_space(ct, cmd_len);
+   h2g->info.tail = (tail + full_len) % h2g->info.size;
+   h2g_reserve_space(ct, full_len);
 
/* Update descriptor */
desc_write(xe, h2g, tail, h2g->info.tail);

base-commit: 2ec46ad7578ebba3048d6031c1a75c21920f0e19
-- 
2.39.0

ttm_bo and multiple backing store segments

[Welty, Brian]

Hi Christian / Thomas,

Wanted to ask if you have explored or thought about adding support in 
TTM such that a ttm_bo could have more than one underlying backing store 
segment (that is, to have a tree of ttm_resources)?

We are considering to support such BOs for Intel Xe driver.

Some of the benefits:
 * devices with page fault support can fault (and migrate) backing store
   at finer granularity than the entire BO
 * BOs can support having multiple backing store segments, which can be
   in different memory domains/regions
 * BO eviction could operate on smaller granularity than entire BO

Or is the thinking that workloads should use SVM/HMM instead of 
GEM_CREATE if they want above benefits?


Is this something you are open to seeing an RFC series that starts 
perhaps with just extending ttm_bo_validate() to see how this might 
shape up?


-Brian

Re: [Intel-gfx] [PATCH v3] drm/i915/selftest/gsc: Ensure GSC Proxy init completes before selftests

[Tvrtko Ursulin]

On 29/06/2023 21:42, Alan Previn wrote:

On MTL, if the GSC Proxy init flows haven't completed, submissions to the
GSC engine will fail. Those init flows are dependent on the mei's
gsc_proxy component that is loaded in parallel with i915 and a
worker that could potentially start after i915 driver init is done.

That said, all subsytems that access the GSC engine today does check
for such init flow completion before using the GSC engine. However,
selftests currently don't wait on anything before starting.

To fix this, add a waiter function at the start of __run_selftests
that waits for gsc-proxy init flows to complete. While implementing this,
use an table of function pointers so its scalable to add additional
waiter functions for future such "wait on dependency" cases that.

Difference from prior versions:
v3: Rebase to latest drm-tip.
v2: Based on internal testing, increase the timeout for gsc-proxy
specific case to 8 seconds.

Signed-off-by: Alan Previn 
Reviewed-by: Zhanjun Dong 

---
  .../gpu/drm/i915/selftests/i915_selftest.c| 61 +++
  1 file changed, 61 insertions(+)

diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c 
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 39da0fb0d6d2..a74b7e264d92 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -24,6 +24,8 @@
  #include 
  
  #include "gt/intel_gt_pm.h"

+#include "gt/uc/intel_gsc_fw.h"
+
  #include "i915_driver.h"
  #include "i915_drv.h"
  #include "i915_selftest.h"
@@ -127,6 +129,63 @@ static void set_default_test_all(struct selftest *st, 
unsigned int count)
st[i].enabled = true;
  }
  
+static int

+__wait_gsc_proxy_completed(struct drm_i915_private *i915,
+  unsigned long timeout_ms)
+{
+   bool need_to_wait = (IS_ENABLED(CONFIG_INTEL_MEI_GSC_PROXY) &&
+i915->media_gt &&
+HAS_ENGINE(i915->media_gt, GSC0) &&
+
intel_uc_fw_is_loadable(&i915->media_gt->uc.gsc.fw));
+
+   /*
+* For gsc proxy component loading + init, we need a much longer timeout
+* than what CI selftest infrastrucutre currently uses. This longer wait
+* period depends on the kernel config and component driver load 
ordering
+*/


How is a CI timeout value relevant?

Plus from the commit message it sounds like the point of wait is so 
submission to gsc does not fail if loading is still in progress, not 
that the CI times out. So what is the main problem?



+   if (timeout_ms < 8000)
+   timeout_ms = 8000;
+
+   if (need_to_wait &&
+   (wait_for(intel_gsc_uc_fw_proxy_init_done(&i915->media_gt->uc.gsc, 
true),
+   timeout_ms)))
+   return -ETIME;
+
+   return 0;
+}
+
+struct __startup_waiter {
+   const char *name;
+   int (*wait_to_completed)(struct drm_i915_private *i915, unsigned long 
timeout_ms);
+};
+
+static struct __startup_waiter all_startup_waiters[] = { \
+   {"gsc_proxy", __wait_gsc_proxy_completed} \
+   };
+
+static int __wait_on_all_system_dependencies(struct drm_i915_private *i915)
+{
+   struct __startup_waiter *waiter = all_startup_waiters;
+   int count = ARRAY_SIZE(all_startup_waiters);
+   int ret;
+
+   if (!waiter || !count || !i915)
+   return 0;


Ugh.

If it ever becomes an empty array just zap this whole code and not have 
these checks.


Also, no i915 is a possibility?

But actually.. please don't add the function table generalization unless 
it is already known something else is coming to be plugged into it.



+
+   for (; count--; waiter++) {
+   if (!waiter->wait_to_completed)
+   continue;
+   ret = waiter->wait_to_completed(i915, i915_selftest.timeout_ms);
+   if (ret) {
+   pr_info(DRIVER_NAME ": Pre-selftest waiter %s failed with 
%d\n",
+   waiter->name, ret);
+   return ret;
+   }
+   }
+
+   return 0;
+}
+
  static int __run_selftests(const char *name,
   struct selftest *st,
   unsigned int count,
@@ -134,6 +193,8 @@ static int __run_selftests(const char *name,
  {
int err = 0;
  
+	__wait_on_all_system_dependencies(data);


Why does this need to be top level selftests and not just a wait for 
intel_gsc_uc_fw_proxy_init_done in the tests where it is relevant, via 
some helper or something?


Regards,

Tvrtko


+
while (!i915_selftest.random_seed)
i915_selftest.random_seed = get_random_u32();
  


base-commit: 6f8963ce33be65c67e53b16fa18325e12ab76861

[PATCH drm-next v6 00/13] [RFC] DRM GPUVA Manager & Nouveau VM_BIND UAPI

[Danilo Krummrich]

This patch series provides a new UAPI for the Nouveau driver in order to
support Vulkan features, such as sparse bindings and sparse residency.

Furthermore, with the DRM GPUVA manager it provides a new DRM core feature to
keep track of GPU virtual address (VA) mappings in a more generic way.

The DRM GPUVA manager is indented to help drivers implement userspace-manageable
GPU VA spaces in reference to the Vulkan API. In order to achieve this goal it
serves the following purposes in this context.

1) Provide infrastructure to track GPU VA allocations and mappings,
   making use of the maple_tree.

2) Generically connect GPU VA mappings to their backing buffers, in
   particular DRM GEM objects.

3) Provide a common implementation to perform more complex mapping
   operations on the GPU VA space. In particular splitting and merging
   of GPU VA mappings, e.g. for intersecting mapping requests or partial
   unmap requests.

The new VM_BIND Nouveau UAPI build on top of the DRM GPUVA manager, itself
providing the following new interfaces.

1) Initialize a GPU VA space via the new DRM_IOCTL_NOUVEAU_VM_INIT ioctl
   for UMDs to specify the portion of VA space managed by the kernel and
   userspace, respectively.

2) Allocate and free a VA space region as well as bind and unbind memory
   to the GPUs VA space via the new DRM_IOCTL_NOUVEAU_VM_BIND ioctl.

3) Execute push buffers with the new DRM_IOCTL_NOUVEAU_EXEC ioctl.

Both, DRM_IOCTL_NOUVEAU_VM_BIND and DRM_IOCTL_NOUVEAU_EXEC, make use of the DRM
scheduler to queue jobs and support asynchronous processing with DRM syncobjs
as synchronization mechanism.

By default DRM_IOCTL_NOUVEAU_VM_BIND does synchronous processing,
DRM_IOCTL_NOUVEAU_EXEC supports asynchronous processing only.

The new VM_BIND UAPI for Nouveau makes also use of drm_exec (execution context
for GEM buffers) by Christian König. Since the patch implementing drm_exec was
not yet merged into drm-next it is part of this series, as well as a small fix
for this patch, which was found while testing this series.

This patch series is also available at [1].

There is a Mesa NVK merge request by Dave Airlie [2] implementing the
corresponding userspace parts for this series.

The Vulkan CTS test suite passes the sparse binding and sparse residency test
cases for the new UAPI together with Dave's Mesa work.

There are also some test cases in the igt-gpu-tools project [3] for the new UAPI
and hence the DRM GPU VA manager. However, most of them are testing the DRM GPU
VA manager's logic through Nouveau's new UAPI and should be considered just as
helper for implementation.

However, I absolutely intend to change those test cases to proper kunit test
cases for the DRM GPUVA manager, once and if we agree on it's usefulness and
design.

[1] https://gitlab.freedesktop.org/nouvelles/kernel/-/tree/new-uapi-drm-next /
https://gitlab.freedesktop.org/nouvelles/kernel/-/merge_requests/1
[2] https://gitlab.freedesktop.org/nouveau/mesa/-/merge_requests/150/
[3] https://gitlab.freedesktop.org/dakr/igt-gpu-tools/-/tree/wip_nouveau_vm_bind

Changes in V2:
==
  Nouveau:
- Reworked the Nouveau VM_BIND UAPI to avoid memory allocations in fence
  signalling critical sections. Updates to the VA space are split up in 
three
  separate stages, where only the 2. stage executes in a fence signalling
  critical section:

1. update the VA space, allocate new structures and page tables
2. (un-)map the requested memory bindings
3. free structures and page tables

- Separated generic job scheduler code from specific job implementations.
- Separated the EXEC and VM_BIND implementation of the UAPI.
- Reworked the locking parts of the nvkm/vmm RAW interface, such that
  (un-)map operations can be executed in fence signalling critical sections.

  GPUVA Manager:
- made drm_gpuva_regions optional for users of the GPUVA manager
- allow NULL GEMs for drm_gpuva entries
- swichted from drm_mm to maple_tree for track drm_gpuva / drm_gpuva_region
  entries
- provide callbacks for users to allocate custom drm_gpuva_op structures to
  allow inheritance
- added user bits to drm_gpuva_flags
- added a prefetch operation type in order to support generating prefetch
  operations in the same way other operations generated
- hand the responsibility for mutual exclusion for a GEM's
  drm_gpuva list to the user; simplified corresponding (un-)link functions

  Maple Tree:
- I added two maple tree patches to the series, one to support custom tree
  walk macros and one to hand the locking responsibility to the user of the
  GPUVA manager without pre-defined lockdep checks.

Changes in V3:
==
  Nouveau:
- Reworked the Nouveau VM_BIND UAPI to do the job cleanup (including page
  table cleanup) within a workqueue rather than the job_free() callback of
  the sch

[PATCH drm-next v6 01/13] drm: execution context for GEM buffers v5

[Danilo Krummrich]

From: Christian König 

This adds the infrastructure for an execution context for GEM buffers
which is similar to the existing TTMs execbuf util and intended to replace
it in the long term.

The basic functionality is that we abstracts the necessary loop to lock
many different GEM buffers with automated deadlock and duplicate handling.

v2: drop xarray and use dynamic resized array instead, the locking
overhead is unecessary and measurable.
v3: drop duplicate tracking, radeon is really the only one needing that.
v4: fixes issues pointed out by Danilo, some typos in comments and a
helper for lock arrays of GEM objects.
v5: some suggestions by Boris Brezillon, especially just use one retry
macro, drop loop in prepare_array, use flags instead of bool

Signed-off-by: Christian König 
---
 Documentation/gpu/drm-mm.rst |  12 ++
 drivers/gpu/drm/Kconfig  |   6 +
 drivers/gpu/drm/Makefile |   2 +
 drivers/gpu/drm/drm_exec.c   | 330 +++
 include/drm/drm_exec.h   | 120 +
 5 files changed, 470 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_exec.c
 create mode 100644 include/drm/drm_exec.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a79fd3549ff8..a52e6f4117d6 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -493,6 +493,18 @@ DRM Sync Objects
 .. kernel-doc:: drivers/gpu/drm/drm_syncobj.c
:export:
 
+DRM Execution context
+=
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+   :doc: Overview
+
+.. kernel-doc:: include/drm/drm_exec.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_exec.c
+   :export:
+
 GPU Scheduler
 =
 
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index afb3b2f5f425..c2f3d234c89e 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -194,6 +194,12 @@ config DRM_TTM
  GPU memory types. Will be enabled automatically if a device driver
  uses it.
 
+config DRM_EXEC
+   tristate
+   depends on DRM
+   help
+ Execution context for command submissions
+
 config DRM_BUDDY
tristate
depends on DRM
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 7a09a89b493b..414855e2a463 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -78,6 +78,8 @@ obj-$(CONFIG_DRM_PANEL_ORIENTATION_QUIRKS) += 
drm_panel_orientation_quirks.o
 #
 # Memory-management helpers
 #
+#
+obj-$(CONFIG_DRM_EXEC) += drm_exec.o
 
 obj-$(CONFIG_DRM_BUDDY) += drm_buddy.o
 
diff --git a/drivers/gpu/drm/drm_exec.c b/drivers/gpu/drm/drm_exec.c
new file mode 100644
index ..285bf80740b5
--- /dev/null
+++ b/drivers/gpu/drm/drm_exec.c
@@ -0,0 +1,330 @@
+/* SPDX-License-Identifier: GPL-2.0 OR MIT */
+
+#include 
+#include 
+#include 
+
+/**
+ * DOC: Overview
+ *
+ * This component mainly abstracts the retry loop necessary for locking
+ * multiple GEM objects while preparing hardware operations (e.g. command
+ * submissions, page table updates etc..).
+ *
+ * If a contention is detected while locking a GEM object the cleanup procedure
+ * unlocks all previously locked GEM objects and locks the contended one first
+ * before locking any further objects.
+ *
+ * After an object is locked fences slots can optionally be reserved on the
+ * dma_resv object inside the GEM object.
+ *
+ * A typical usage pattern should look like this::
+ *
+ * struct drm_gem_object *obj;
+ * struct drm_exec exec;
+ * unsigned long index;
+ * int ret;
+ *
+ * drm_exec_init(&exec, DRM_EXEC_INTERRUPTIBLE_WAIT);
+ * drm_exec_until_all_locked(&exec) {
+ * ret = drm_exec_prepare_obj(&exec, boA, 1);
+ * drm_exec_retry_on_contention(&exec);
+ * if (ret)
+ * goto error;
+ *
+ * ret = drm_exec_prepare_obj(&exec, boB, 1);
+ * drm_exec_retry_on_contention(&exec);
+ * if (ret)
+ * goto error;
+ * }
+ *
+ * drm_exec_for_each_locked_object(&exec, index, obj) {
+ * dma_resv_add_fence(obj->resv, fence, DMA_RESV_USAGE_READ);
+ * ...
+ * }
+ * drm_exec_fini(&exec);
+ *
+ * See struct dma_exec for more details.
+ */
+
+/* Dummy value used to initially enter the retry loop */
+#define DRM_EXEC_DUMMY (void*)~0
+
+/* Unlock all objects and drop references */
+static void drm_exec_unlock_all(struct drm_exec *exec)
+{
+   struct drm_gem_object *obj;
+   unsigned long index;
+
+   drm_exec_for_each_locked_object(exec, index, obj) {
+   dma_resv_unlock(obj->resv);
+   drm_gem_object_put(obj);
+   }
+
+   drm_gem_object_put(exec->prelocked);
+   exec->prelocked = NULL;
+}
+
+/**
+ * drm_exec_init - initialize a drm_exec object
+ * @exec: the drm_exec object to initialize
+ * @flags: controls locking behavior, see DRM_EXEC_* defines
+ *
+ * Initialize the object and make sure t

[PATCH drm-next v6 02/13] drm: manager to keep track of GPUs VA mappings

[Danilo Krummrich]

Add infrastructure to keep track of GPU virtual address (VA) mappings
with a decicated VA space manager implementation.

New UAPIs, motivated by Vulkan sparse memory bindings graphics drivers
start implementing, allow userspace applications to request multiple and
arbitrary GPU VA mappings of buffer objects. The DRM GPU VA manager is
intended to serve the following purposes in this context.

1) Provide infrastructure to track GPU VA allocations and mappings,
   making use of the maple_tree.

2) Generically connect GPU VA mappings to their backing buffers, in
   particular DRM GEM objects.

3) Provide a common implementation to perform more complex mapping
   operations on the GPU VA space. In particular splitting and merging
   of GPU VA mappings, e.g. for intersecting mapping requests or partial
   unmap requests.

Tested-by: Donald Robson 
Reviewed-by: Boris Brezillon 
Suggested-by: Dave Airlie 
Signed-off-by: Danilo Krummrich 
---
 Documentation/gpu/drm-mm.rst|   36 +
 drivers/gpu/drm/Makefile|1 +
 drivers/gpu/drm/drm_gem.c   |3 +
 drivers/gpu/drm/drm_gpuva_mgr.c | 1743 +++
 include/drm/drm_drv.h   |6 +
 include/drm/drm_gem.h   |   52 +
 include/drm/drm_gpuva_mgr.h |  756 ++
 7 files changed, 2597 insertions(+)
 create mode 100644 drivers/gpu/drm/drm_gpuva_mgr.c
 create mode 100644 include/drm/drm_gpuva_mgr.h

diff --git a/Documentation/gpu/drm-mm.rst b/Documentation/gpu/drm-mm.rst
index a52e6f4117d6..3d5dc9dc1bfe 100644
--- a/Documentation/gpu/drm-mm.rst
+++ b/Documentation/gpu/drm-mm.rst
@@ -466,6 +466,42 @@ DRM MM Range Allocator Function References
 .. kernel-doc:: drivers/gpu/drm/drm_mm.c
:export:
 
+DRM GPU VA Manager
+==
+
+Overview
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Overview
+
+Split and Merge
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Split and Merge
+
+Locking
+---
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Locking
+
+Examples
+
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :doc: Examples
+
+DRM GPU VA Manager Function References
+--
+
+.. kernel-doc:: include/drm/drm_gpuva_mgr.h
+   :internal:
+
+.. kernel-doc:: drivers/gpu/drm/drm_gpuva_mgr.c
+   :export:
+
 DRM Buddy Allocator
 ===
 
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 414855e2a463..6d6c9dec66e8 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -45,6 +45,7 @@ drm-y := \
drm_vblank.o \
drm_vblank_work.o \
drm_vma_manager.o \
+   drm_gpuva_mgr.o \
drm_writeback.o
 drm-$(CONFIG_DRM_LEGACY) += \
drm_agpsupport.o \
diff --git a/drivers/gpu/drm/drm_gem.c b/drivers/gpu/drm/drm_gem.c
index 1a5a2cd0d4ec..cd878ebddbd0 100644
--- a/drivers/gpu/drm/drm_gem.c
+++ b/drivers/gpu/drm/drm_gem.c
@@ -164,6 +164,9 @@ void drm_gem_private_object_init(struct drm_device *dev,
if (!obj->resv)
obj->resv = &obj->_resv;
 
+   if (drm_core_check_feature(dev, DRIVER_GEM_GPUVA))
+   drm_gem_gpuva_init(obj);
+
drm_vma_node_reset(&obj->vma_node);
INIT_LIST_HEAD(&obj->lru_node);
 }
diff --git a/drivers/gpu/drm/drm_gpuva_mgr.c b/drivers/gpu/drm/drm_gpuva_mgr.c
new file mode 100644
index ..4414990c05cc
--- /dev/null
+++ b/drivers/gpu/drm/drm_gpuva_mgr.c
@@ -0,0 +1,1743 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright (c) 2022 Red Hat.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * THE COPYRIGHT HOLDER(S) OR AUTHOR(S) BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ *
+ * Authors:
+ * Danilo Krummrich 
+ *
+ */
+
+#include 
+
+#include 
+#include 
+
+/**
+ * DOC: Overview
+ *
+ * The DRM GPU VA Manager, represented by struct drm_gpuva_manager keeps track
+ * of a GPU's virtual address (VA) space and manages the corresponding virtual
+ * mappings represented by &drm_gpuva objects. It a