Re: [PATCH] drm/simple-kms: Standardize arguments for callbacks
Hi Daniel,
I love your patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[cannot apply to v5.4-rc4 next-20191022]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-simple-kms-Standardize-arguments-for-callbacks/20191023-073731
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
3b7c59a1950c75f2c0152e5a9cd77675b09233d6
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/xen/xen_drm_front_kms.c:289:23: sparse: sparse: incorrect
>> type in initializer (incompatible argument 1 (different base types)) @@
>> expected int enum drm_mode_status ( *mode_valid )( ... ) @@got int enum
>> drm_mode_status ( *mode_valid )( ... ) @@
>> drivers/gpu/drm/xen/xen_drm_front_kms.c:289:23: sparse:expected int enum
>> drm_mode_status ( *mode_valid )( ... )
>> drivers/gpu/drm/xen/xen_drm_front_kms.c:289:23: sparse:got int enum
>> drm_mode_status ( * )( ... )
vim +289 drivers/gpu/drm/xen/xen_drm_front_kms.c
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 287
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 288 static const struct
drm_simple_display_pipe_funcs display_funcs = {
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 @289 .mode_valid =
display_mode_valid,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 290 .enable =
display_enable,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 291 .disable =
display_disable,
dd388ee1ecbb8c Daniel Vetter 2018-04-09 292 .prepare_fb =
drm_gem_fb_simple_display_pipe_prepare_fb,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 293 .update =
display_update,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 294 };
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 295
:: The code at line 289 was first introduced by commit
:: c575b7eeb89f94356997abd62d6d5a0590e259b7 drm/xen-front: Add support for
Xen PV display frontend
:: TO: Oleksandr Andrushchenko
:: CC: Oleksandr Andrushchenko
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/v3d: Fix memory leak in v3d_submit_cl_ioctl
On Tue, Oct 22, 2019 at 4:36 AM Daniel Vetter wrote:
>
> On Mon, Oct 21, 2019 at 01:52:49PM -0500, Navid Emamdoost wrote:
> > In the impelementation of v3d_submit_cl_ioctl() there are two memory
> > leaks. One is when allocation for bin fails, and the other is when bin
> > initialization fails. If kcalloc fails to allocate memory for bin then
> > render->base should be put. Also, if v3d_job_init() fails to initialize
> > bin->base then allocated memory for bin should be released.
> >
> > Fixes: a783a09ee76d ("drm/v3d: Refactor job management.")
> > Signed-off-by: Navid Emamdoost
> > ---
> > drivers/gpu/drm/v3d/v3d_gem.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/v3d/v3d_gem.c b/drivers/gpu/drm/v3d/v3d_gem.c
> > index 5d80507b539b..19c092d75266 100644
> > --- a/drivers/gpu/drm/v3d/v3d_gem.c
> > +++ b/drivers/gpu/drm/v3d/v3d_gem.c
> > @@ -557,13 +557,16 @@ v3d_submit_cl_ioctl(struct drm_device *dev, void
> > *data,
> >
> > if (args->bcl_start != args->bcl_end) {
> > bin = kcalloc(1, sizeof(*bin), GFP_KERNEL);
> > - if (!bin)
> > + if (!bin) {
> > + v3d_job_put(>base);
>
> The job isn't initialized yet, this doesn't work.
Do you mean we have to release render via kfree() here?
>
> > return -ENOMEM;
> > + }
> >
> > ret = v3d_job_init(v3d, file_priv, >base,
> > v3d_job_free, args->in_sync_bcl);
> > if (ret) {
> > v3d_job_put(>base);
>
> v3d_job_put will call kfree, if you chase the callchain long enough (in
> v3d_job_free). So no bug here, this would lead to a double kfree and
> crash.
Yes, v3d_job_put() takes care of render,
> -Daniel
>
> > + kfree(bin);
but how about leaking bin?
> > return ret;
> > }
> >
> > --
> > 2.17.1
> >
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Navid.
Re: radeon Disabling GPU acceleration (WB disabled?)
On Tue, Oct 22, 2019 at 12:09 PM Michel Dänzer wrote: > > On 2019-10-20 11:21 p.m., Meelis Roos wrote: > > I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated > > Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not > > know if it has been enabled in the past - no old kernels handy at the > > moment. > > > > From dmesg it looks like something with MTRR maybe: WB disabled. > > That's harmless. > > > > [8.535975] [drm] Driver supports precise vblank timestamp query. > > [8.535981] radeon :00:05.0: Disabling GPU acceleration > > This looks like drm_irq_install returns an error in radeon_irq_kms_init. > Check to see that the sbios assigns an irq to the device. There may be an option in the sbios configuration settings. IIRC, some old platforms didn't always assign interrupts to vga devices. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #125 from Shmerl --- Just built 5.4-rc4. I still get these in dmesg when using ksysguard with amdgpu sensors: [ 323.750015] amdgpu: [powerplay] failed send message: TransferTableSmu2Dram (18) param: 0x0006 response 0xfffb [ 323.750018] amdgpu: [powerplay] Failed to export SMU metrics table! However so far it didn't cause a hang like it used to do before, which is an improvement for the powerplay bug. But the message shows that something wrong is still going on. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109955] amdgpu [RX Vega 64] system freeze while gaming
https://bugs.freedesktop.org/show_bug.cgi?id=109955 --- Comment #118 from Rodney A Morris --- (In reply to haro41 from comment #117) > ...are this craches more frequently with VSYNC enabled? > > If yes, it could be the same thing like this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=110777 vsync is defintely on for both Stellaris and Hearts of Iron. I looked over the bug report you linked to. It is very interesting and I will follow with interest. The next time I play Stellaris or Hearts of Iron IV, I will have to see if I can record my memory frequency values to see if they are indeed not moving off the base frequency under low load with v-sync enabled. The problem manifesting under low load would explain why I cannot replicate the problem while running Unigine Superposition. I began to wonder if powerplay and the frequency at which the chip and memory were operating were not the problem after reading the following bug report for Vega 20: https://bugs.freedesktop.org/show_bug.cgi?id=110674 Last Friday, I attempted to capture the operating frequency and temps, but my attempt utterly failed. I will disable v-sync and see if that improves and report back here. If I manage to capture frequency data, I will report back here and may be your thread. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 112104] 2 displays, only 1 hdmi/dp device listed, sound played in both devices if selected
https://bugs.freedesktop.org/show_bug.cgi?id=112104 Bug ID: 112104 Summary: 2 displays, only 1 hdmi/dp device listed, sound played in both devices if selected Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: not set Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: sebastianlacue...@gmail.com When I connect a monitor at one display port (fullhd) and a tv on hdmi (2.0, 4k), gnome control settings only list one dp/hdmi device is listed at sound settings, but audio is played in both devices if this one is selected. This happens if I use kernel 5.3.7-1, no problem if I reboot in 5.2.17-1+b1. I'm using debian image kernels, gpu is vega20 (radeon 7). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Standardize arguments for callbacks
Hi Daniel,
I love your patch! Yet something to improve:
[auto build test ERROR on linus/master]
[cannot apply to v5.4-rc4 next-20191022]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Daniel-Vetter/drm-simple-kms-Standardize-arguments-for-callbacks/20191023-073731
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
3b7c59a1950c75f2c0152e5a9cd77675b09233d6
config: x86_64-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.4.0-14) 7.4.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu//drm/xen/xen_drm_front_kms.c:289:16: error: initialization from
>> incompatible pointer type [-Werror=incompatible-pointer-types]
.mode_valid = display_mode_valid,
^~
drivers/gpu//drm/xen/xen_drm_front_kms.c:289:16: note: (near initialization
for 'display_funcs.mode_valid')
cc1: some warnings being treated as errors
vim +289 drivers/gpu//drm/xen/xen_drm_front_kms.c
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 287
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 288 static const struct
drm_simple_display_pipe_funcs display_funcs = {
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 @289 .mode_valid =
display_mode_valid,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 290 .enable =
display_enable,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 291 .disable =
display_disable,
dd388ee1ecbb8c Daniel Vetter 2018-04-09 292 .prepare_fb =
drm_gem_fb_simple_display_pipe_prepare_fb,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 293 .update =
display_update,
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 294 };
c575b7eeb89f94 Oleksandr Andrushchenko 2018-04-03 295
:: The code at line 289 was first introduced by commit
:: c575b7eeb89f94356997abd62d6d5a0590e259b7 drm/xen-front: Add support for
Xen PV display frontend
:: TO: Oleksandr Andrushchenko
:: CC: Oleksandr Andrushchenko
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: New sysfs interface for privacy screens
On Tue, Oct 22, 2019 at 5:14 PM Rajat Jain wrote: > > Hi Folks, > > On Mon, Oct 7, 2019 at 11:13 PM Jani Nikula > wrote: >> >> On Mon, 07 Oct 2019, Mat King wrote: >> > That makes sense; just to confirm can a property be added or removed >> > after the connector is registered? >> >> You need to create the property before registering the drm device. You >> can attach/detach the property later, but I should think you know by the >> time you're registering the connector whether it supports the privacy >> screen or not. > > I just posted a patch for this here: https://lkml.org/lkml/2019/10/22/967 Would appreciate review and comments. Thanks & Best Regards, Rajat > >> >> >> BR, >> Jani. >> >> -- >> Jani Nikula, Intel Open Source Graphics Center
[PATCH] drm: Add support for integrated privacy screens
Certain laptops now come with panels that have integrated privacy
screens on them. This patch adds support for such panels by adding
a privacy-screen property to the drm_connector for the panel, that
the userspace can then use to control and check the status. The idea
was discussed here:
https://lkml.org/lkml/2019/10/1/786
ACPI methods are used to identify, query and control privacy screen:
* Identifying an ACPI object corresponding to the panel: The patch
follows ACPI Spec 6.3 (available at
https://uefi.org/sites/default/files/resources/ACPI_6_3_final_Jan30.pdf).
Pages 1119 - 1123 describe what I believe, is a standard way of
identifying / addressing "display panels" in the ACPI tables, thus
allowing kernel to attach ACPI nodes to the panel. IMHO, this ability
to identify and attach ACPI nodes to drm connectors may be useful for
reasons other privacy-screens, in future.
* Identifying the presence of privacy screen, and controlling it, is done
via ACPI _DSM methods.
Currently, this is done only for the Intel display ports. But in future,
this can be done for any other ports if the hardware becomes available
(e.g. external monitors supporting integrated privacy screens?).
Also, this code can be extended in future to support non-ACPI methods
(e.g. using a kernel GPIO driver to toggle a gpio that controls the
privacy-screen).
Signed-off-by: Rajat Jain
---
drivers/gpu/drm/Makefile| 1 +
drivers/gpu/drm/drm_atomic_uapi.c | 5 +
drivers/gpu/drm/drm_connector.c | 38 +
drivers/gpu/drm/drm_privacy_screen.c| 176
drivers/gpu/drm/i915/display/intel_dp.c | 3 +
include/drm/drm_connector.h | 18 +++
include/drm/drm_mode_config.h | 7 +
include/drm/drm_privacy_screen.h| 33 +
8 files changed, 281 insertions(+)
create mode 100644 drivers/gpu/drm/drm_privacy_screen.c
create mode 100644 include/drm/drm_privacy_screen.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index 82ff826b33cc..e1fc33d69bb7 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -19,6 +19,7 @@ drm-y :=drm_auth.o drm_cache.o \
drm_syncobj.o drm_lease.o drm_writeback.o drm_client.o \
drm_client_modeset.o drm_atomic_uapi.o drm_hdcp.o
+drm-$(CONFIG_ACPI) += drm_privacy_screen.o
drm-$(CONFIG_DRM_LEGACY) += drm_legacy_misc.o drm_bufs.o drm_context.o
drm_dma.o drm_scatter.o drm_lock.o
drm-$(CONFIG_DRM_LIB_RANDOM) += lib/drm_random.o
drm-$(CONFIG_DRM_VM) += drm_vm.o
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7a26bfb5329c..44131165e4ea 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -30,6 +30,7 @@
#include
#include
#include
+#include
#include
#include
@@ -766,6 +767,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
fence_ptr);
} else if (property == connector->max_bpc_property) {
state->max_requested_bpc = val;
+ } else if (property == config->privacy_screen_property) {
+ drm_privacy_screen_set_val(connector, val);
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -842,6 +845,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == config->privacy_screen_property) {
+ *val = drm_privacy_screen_get_val(connector);
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 4c766624b20d..a31e0382132b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -821,6 +821,11 @@ static const struct drm_prop_enum_list
drm_panel_orientation_enum_list[] = {
{ DRM_MODE_PANEL_ORIENTATION_RIGHT_UP, "Right Side Up" },
};
+static const struct drm_prop_enum_list drm_privacy_screen_enum_list[] = {
+ { DRM_PRIVACY_SCREEN_DISABLED, "Disabled" },
+ { DRM_PRIVACY_SCREEN_ENABLED, "Enabled" },
+};
+
static const struct drm_prop_enum_list drm_dvi_i_select_enum_list[] = {
{ DRM_MODE_SUBCONNECTOR_Automatic, "Automatic" }, /* DVI-I and TV-out */
{ DRM_MODE_SUBCONNECTOR_DVID, "DVI-D" }, /* DVI-I */
@@ -2253,6 +2258,39 @@ static void drm_tile_group_free(struct kref *kref)
kfree(tg);
}
+/**
+ * drm_connector_init_privacy_screen_property -
+ * create and attach the connecter's privacy-screen property.
+ * @connector:
[Bug 110574] System hang after screen power saving
https://bugs.freedesktop.org/show_bug.cgi?id=110574 Joakim changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #3 from Joakim --- Since newer version of XFCE works differently I can no longer test for this bug as it no longer crashes regardless of which option I use for vertical sync (new glx setting or the old one). -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Revert "drm/omap: add OMAP_BO flags to affect buffer allocation"
On Tue, Oct 22, 2019 at 10:47 PM Sean Paul wrote:
>
> From: Sean Paul
>
> This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679.
>
> This patch does not have an acceptable open source userspace
> implementation, and as such it does not meet the requirements for adding
> new UAPI.
>
> Discussion is in the Link.
>
> Link:
> https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html
> Fixes: 23b482252836 ("drm/omap: add OMAP_BO flags to affect buffer
> allocation")
> Cc: Tomi Valkeinen
> Cc: Jean-Jacques Hiblot
> Cc: David Airlie
> Cc: Daniel Vetter
Ack.
-Daniel
> Cc: dri-devel@lists.freedesktop.org
> Signed-off-by: Sean Paul
> ---
> drivers/gpu/drm/omapdrm/omap_gem.c | 54 ++
> include/uapi/drm/omap_drm.h| 9 -
> 2 files changed, 2 insertions(+), 61 deletions(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
> b/drivers/gpu/drm/omapdrm/omap_gem.c
> index bf18dfe2b689..e518d93ca6df 100644
> --- a/drivers/gpu/drm/omapdrm/omap_gem.c
> +++ b/drivers/gpu/drm/omapdrm/omap_gem.c
> @@ -1097,9 +1097,6 @@ void omap_gem_free_object(struct drm_gem_object *obj)
> list_del(_obj->mm_list);
> mutex_unlock(>list_lock);
>
> - if (omap_obj->flags & OMAP_BO_MEM_PIN)
> - omap_gem_unpin_locked(obj);
> -
> /*
> * We own the sole reference to the object at this point, but to keep
> * lockdep happy, we must still take the omap_obj_lock to call
> @@ -1150,19 +1147,10 @@ static bool omap_gem_validate_flags(struct drm_device
> *dev, u32 flags)
> return false;
> }
>
> - if ((flags & OMAP_BO_MEM_CONTIG) && (flags & OMAP_BO_MEM_DMM))
> - return false;
> -
> - if ((flags & OMAP_BO_MEM_DMM) && !priv->usergart)
> - return false;
> -
> if (flags & OMAP_BO_TILED_MASK) {
> if (!priv->usergart)
> return false;
>
> - if (flags & OMAP_BO_MEM_CONTIG)
> - return false;
> -
> switch (flags & OMAP_BO_TILED_MASK) {
> case OMAP_BO_TILED_8:
> case OMAP_BO_TILED_16:
> @@ -1177,34 +1165,7 @@ static bool omap_gem_validate_flags(struct drm_device
> *dev, u32 flags)
> return true;
> }
>
> -/**
> - * omap_gem_new() - Create a new GEM buffer
> - * @dev: The DRM device
> - * @gsize: The requested size for the GEM buffer. If the buffer is tiled
> - * (2D buffer), the size is a pair of values: height and width
> - * expressed in pixels. If the buffers is not tiled, it is expressed
> - * in bytes.
> - * @flags: Flags give additionnal information about the allocation:
> - * OMAP_BO_TILED_x: use the TILER (2D buffers). The TILER container
> - * unit can be 8, 16 or 32 bits. Cache is always disabled for
> - * tiled buffers.
> - * OMAP_BO_SCANOUT: Scannout buffer, consummable by the DSS
> - * OMAP_BO_CACHED: Buffer CPU caching mode: cached
> - * OMAP_BO_WC: Buffer CPU caching mode: write-combined
> - * OMAP_BO_UNCACHED: Buffer CPU caching mode: uncached
> - * OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the
> memory.
> - * This can be used to avoid DMM if the userspace knows it needs
> - * more than 128M of memory at the same time.
> - * OMAP_BO_MEM_DMM: The driver will use DMM to get the memory.
> There's
> - * not much use for this flag at the moment, as on platforms
> with
> - * DMM it is used by default, but it's here for completeness.
> - * OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and
> - * keep it pinned. This can be used to 1) get an error at alloc
> - * time if DMM space is full, and 2) get rid of the constant
> - * pin/unpin operations which may have some effect on
> performance.
> - *
> - * Return: The GEM buffer or NULL if the allocation failed
> - */
> +/* GEM buffer object constructor */
> struct drm_gem_object *omap_gem_new(struct drm_device *dev,
> union omap_gem_size gsize, u32 flags)
> {
> @@ -1232,8 +1193,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev,
> */
> flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
> flags |= tiler_get_cpu_cache_flags();
> - } else if ((flags & OMAP_BO_MEM_CONTIG) ||
> - ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm)) {
> + } else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
> /*
> * If we don't have DMM, we must allocate scanout buffers
> * from contiguous DMA memory.
> @@ -1293,22 +1253,12 @@ struct drm_gem_object *omap_gem_new(struct drm_device
> *dev,
> goto err_release;
> }
>
> - if (flags & OMAP_BO_MEM_PIN) {
> -
Re: UDL device cannot get its own screen
On Tue, Oct 22, 2019 at 11:50 AM Böszörményi Zoltán wrote: > > Hi, > > I have the below configuration for an Intel based POS system that, > while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), > only two are usable. DP1 for the built-in touchscreen and VGA1 for > the external VGA connector. > > I wanted to use an USB DisplayLink device as the 3rd output, with all > three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. > > [...] > > How can I set up 3 different Screens correctly for 3 separate fullscreen > applications? > > I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" > patch from Dave Airlie that at least wakes up the UDL device and makes > it visible without extra magic with providers/sinks. If it's being treated as a GPU, that's your first problem for this kind of setup. You should see modeset(2), in your logs, but I suspect you're seeing modeset(G0) (the "G" indicates "GPU"). > > # cat /etc/X11/xorg.conf.d/videocard.conf > Section "Monitor" > Identifier "Monitor-DP-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "Monitor-HDMI-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "Monitor-VGA-1" > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Monitor" > Identifier "DVI-I-1-1" The others are Monitor-*, this one isn't. You probably want this to be DVI-I-1, as noted below. I guess you get the extra -1 from seeing it as a slaved GPU's output in your current configuration. > Option "AutoServerLayout" "on" > Option "Rotate" "normal" > EndSection > > Section "Device" > Identifier "Intel0" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Screen 0 > Option "Monitor-DP1" "DP-1" > Option "ZaphodHeads" "DP-1" > EndSection > > Section "Device" > Identifier "Intel1" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Screen 1 > Option "Monitor-VGA-1" "VGA-1" > Option "ZaphodHeads" "VGA-1" > EndSection > > # Intentionally not referenced in ServerLayout below > Section "Device" > Identifier "Intel2" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card1" > Option "Monitor-HDMI-1" "HDMI-1" > Option "ZaphodHeads" "HDMI-1" > EndSection > > Section "Device" > Identifier "UDL" > Driver "modesetting" > Option "kmsdev" "/dev/dri/card0" > Screen 2 > Option "Monitor-DVI-I-1-1" "DVI-I-1-1" I think you have an extra -1 in here (and the monitor name doesn't exist as per above). And I think the "Screen" index is wrong -- it's not what one tends to think it is, as I recall. I think you can just drop these lines though. > EndSection > > Section "Screen" > Identifier "SCREEN" > Option "AutoServerLayout" "on" > Device "Intel0" > Monitor "Monitor-DP-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "SCREEN1" > Option "AutoServerLayout" "on" > Device "Intel1" > Monitor "Monitor-VGA-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "Screen" > Identifier "SCREEN2" > Option "AutoServerLayout" "on" > Device "UDL" > Monitor "Monitor-DVI-I-1-1" > SubSection "Display" > Modes "1024x768" > Depth 24 > EndSubSection > EndSection > > Section "ServerLayout" > Identifier "LAYOUT" > Option "AutoServerLayout" "on" > Screen 0 "SCREEN" > Screen 1 "SCREEN1" RightOf "SCREEN" > Screen 2 "SCREEN2" RightOf "SCREEN1" > EndSection > > Best regards, > Zoltán Böszörményi > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] Revert "drm/omap: add OMAP_BO flags to affect buffer allocation"
From: Sean Paul
This reverts commit 23b482252836ab3c5e6b3b20ed3038449cbc7679.
This patch does not have an acceptable open source userspace
implementation, and as such it does not meet the requirements for adding
new UAPI.
Discussion is in the Link.
Link: https://lists.freedesktop.org/archives/dri-devel/2019-October/240586.html
Fixes: 23b482252836 ("drm/omap: add OMAP_BO flags to affect buffer allocation")
Cc: Tomi Valkeinen
Cc: Jean-Jacques Hiblot
Cc: David Airlie
Cc: Daniel Vetter
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Sean Paul
---
drivers/gpu/drm/omapdrm/omap_gem.c | 54 ++
include/uapi/drm/omap_drm.h| 9 -
2 files changed, 2 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_gem.c
b/drivers/gpu/drm/omapdrm/omap_gem.c
index bf18dfe2b689..e518d93ca6df 100644
--- a/drivers/gpu/drm/omapdrm/omap_gem.c
+++ b/drivers/gpu/drm/omapdrm/omap_gem.c
@@ -1097,9 +1097,6 @@ void omap_gem_free_object(struct drm_gem_object *obj)
list_del(_obj->mm_list);
mutex_unlock(>list_lock);
- if (omap_obj->flags & OMAP_BO_MEM_PIN)
- omap_gem_unpin_locked(obj);
-
/*
* We own the sole reference to the object at this point, but to keep
* lockdep happy, we must still take the omap_obj_lock to call
@@ -1150,19 +1147,10 @@ static bool omap_gem_validate_flags(struct drm_device
*dev, u32 flags)
return false;
}
- if ((flags & OMAP_BO_MEM_CONTIG) && (flags & OMAP_BO_MEM_DMM))
- return false;
-
- if ((flags & OMAP_BO_MEM_DMM) && !priv->usergart)
- return false;
-
if (flags & OMAP_BO_TILED_MASK) {
if (!priv->usergart)
return false;
- if (flags & OMAP_BO_MEM_CONTIG)
- return false;
-
switch (flags & OMAP_BO_TILED_MASK) {
case OMAP_BO_TILED_8:
case OMAP_BO_TILED_16:
@@ -1177,34 +1165,7 @@ static bool omap_gem_validate_flags(struct drm_device
*dev, u32 flags)
return true;
}
-/**
- * omap_gem_new() - Create a new GEM buffer
- * @dev: The DRM device
- * @gsize: The requested size for the GEM buffer. If the buffer is tiled
- * (2D buffer), the size is a pair of values: height and width
- * expressed in pixels. If the buffers is not tiled, it is expressed
- * in bytes.
- * @flags: Flags give additionnal information about the allocation:
- * OMAP_BO_TILED_x: use the TILER (2D buffers). The TILER container
- * unit can be 8, 16 or 32 bits. Cache is always disabled for
- * tiled buffers.
- * OMAP_BO_SCANOUT: Scannout buffer, consummable by the DSS
- * OMAP_BO_CACHED: Buffer CPU caching mode: cached
- * OMAP_BO_WC: Buffer CPU caching mode: write-combined
- * OMAP_BO_UNCACHED: Buffer CPU caching mode: uncached
- * OMAP_BO_MEM_CONTIG: The driver will use dma_alloc to get the memory.
- * This can be used to avoid DMM if the userspace knows it needs
- * more than 128M of memory at the same time.
- * OMAP_BO_MEM_DMM: The driver will use DMM to get the memory. There's
- * not much use for this flag at the moment, as on platforms with
- * DMM it is used by default, but it's here for completeness.
- * OMAP_BO_MEM_PIN: The driver will pin the memory at alloc time, and
- * keep it pinned. This can be used to 1) get an error at alloc
- * time if DMM space is full, and 2) get rid of the constant
- * pin/unpin operations which may have some effect on performance.
- *
- * Return: The GEM buffer or NULL if the allocation failed
- */
+/* GEM buffer object constructor */
struct drm_gem_object *omap_gem_new(struct drm_device *dev,
union omap_gem_size gsize, u32 flags)
{
@@ -1232,8 +1193,7 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
*/
flags &= ~(OMAP_BO_CACHED|OMAP_BO_WC|OMAP_BO_UNCACHED);
flags |= tiler_get_cpu_cache_flags();
- } else if ((flags & OMAP_BO_MEM_CONTIG) ||
- ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm)) {
+ } else if ((flags & OMAP_BO_SCANOUT) && !priv->has_dmm) {
/*
* If we don't have DMM, we must allocate scanout buffers
* from contiguous DMA memory.
@@ -1293,22 +1253,12 @@ struct drm_gem_object *omap_gem_new(struct drm_device
*dev,
goto err_release;
}
- if (flags & OMAP_BO_MEM_PIN) {
- ret = omap_gem_pin(obj, NULL);
- if (ret)
- goto err_free_dma;
- }
-
mutex_lock(>list_lock);
list_add(_obj->mm_list, >obj_list);
mutex_unlock(>list_lock);
return obj;
-err_free_dma:
- if (flags &
Re: [PATCH v5 07/14] drm/dp_mst: Don't forget to update port->input in drm_dp_mst_handle_conn_stat()
On Mon, Oct 21, 2019 at 10:36:02PM -0400, Lyude Paul wrote:
> This probably hasn't caused any problems up until now since it's
> probably nearly impossible to encounter this in the wild, however if we
> were to receive a connection status notification from the MST hub after
> resume while we're in the middle of reprobing the link addresses for a
> topology then there's a much larger chance that a port could have
> changed from being an output port to input port (or vice versa). If we
> forget to update this bit of information, we'll potentially ignore a
> valid PDT change on a downstream port because we think it's an input
> port.
>
> So, make sure we read the input_port field in connection status
> notifications in drm_dp_mst_handle_conn_stat() to prevent this from
> happening once we've implemented suspend/resume reprobing.
>
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Signed-off-by: Lyude Paul
> Reviewed-by: Sean Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 52 +++
> 1 file changed, 38 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 7bf4db91ff90..c8e218b902ae 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2079,18 +2079,40 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
> *mstb,
> {
> struct drm_dp_mst_topology_mgr *mgr = mstb->mgr;
> struct drm_dp_mst_port *port;
> - int old_ddps;
> - bool dowork = false;
> + int old_ddps, ret;
> + u8 new_pdt;
> + bool dowork = false, create_connector = false;
>
> port = drm_dp_get_port(mstb, conn_stat->port_number);
> if (!port)
> return;
>
> - /* Locking is only needed if the port's exposed to userspace */
> - if (port->connector)
> + if (port->connector) {
> + if (!port->input && conn_stat->input_port) {
> + /*
> + * We can't remove a connector from an already exposed
> + * port, so just throw the port out and make sure we
> + * reprobe the link address of it's parent MSTB
> + */
> + drm_dp_mst_topology_unlink_port(mgr, port);
> + mstb->link_address_sent = false;
> + dowork = true;
> + goto out;
> + }
> +
> + /*
> + * Locking is only needed if the port's exposed to userspace
> + */
optional nit: this will still fit on one line
> drm_modeset_lock(>base.lock, NULL);
> + } else if (port->input && !conn_stat->input_port) {
> + create_connector = true;
> + /* Reprobe link address so we get num_sdp_streams */
> + mstb->link_address_sent = false;
> + dowork = true;
> + }
>
> old_ddps = port->ddps;
> + port->input = conn_stat->input_port;
> port->mcs = conn_stat->message_capability_status;
> port->ldps = conn_stat->legacy_device_plug_status;
> port->ddps = conn_stat->displayport_device_plug_status;
> @@ -2103,21 +2125,23 @@ drm_dp_mst_handle_conn_stat(struct drm_dp_mst_branch
> *mstb,
> }
> }
>
> - if (!port->input) {
> - int ret = drm_dp_port_set_pdt(port,
> - conn_stat->peer_device_type);
> - if (ret == 1) {
> - dowork = true;
> - } else if (ret < 0) {
> - DRM_ERROR("Failed to change PDT for port %p: %d\n",
> - port, ret);
> - dowork = false;
> - }
> + new_pdt = port->input ? DP_PEER_DEVICE_NONE :
> conn_stat->peer_device_type;
> +
> + ret = drm_dp_port_set_pdt(port, new_pdt);
> + if (ret == 1) {
> + dowork = true;
> + } else if (ret < 0) {
> + DRM_ERROR("Failed to change PDT for port %p: %d\n",
> + port, ret);
> + dowork = false;
> }
>
> if (port->connector)
> drm_modeset_unlock(>base.lock);
> + else if (create_connector)
> + drm_dp_mst_port_add_connector(mstb, port);
>
> +out:
> drm_dp_mst_topology_put_port(port);
> if (dowork)
> queue_work(system_long_wq, >mgr->work);
> --
> 2.21.0
>
--
Sean Paul, Software Engineer, Google / Chromium OS
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 06/14] drm/dp_mst: Protect drm_dp_mst_port members with locking
On Mon, Oct 21, 2019 at 10:36:01PM -0400, Lyude Paul wrote: > This is a complicated one. Essentially, there's currently a problem in the MST > core that hasn't really caused any issues that we're aware of (emphasis on > "that > we're aware of"): locking. > > When we go through and probe the link addresses and path resources in a > topology, we hold no locks when updating ports with said information. The > members I'm referring to in particular are: > > - ldps > - ddps > - mcs > - pdt > - dpcd_rev > - num_sdp_streams > - num_sdp_stream_sinks > - available_pbn > - input > - connector > > Now that we're handling UP requests asynchronously and will be using some of > the struct members mentioned above in atomic modesetting in the future for > features such as PBN validation, this is going to become a lot more important. > As well, the next few commits that prepare us for and introduce suspend/resume > reprobing will also need clear locking in order to prevent from additional > racing hilarities that we never could have hit in the past. > > So, let's solve this issue by using >base.lock, the modesetting > lock which currently only protects >base.state. This works > perfectly because it allows us to avoid blocking connection_mutex > unnecessarily, and we can grab this in connector detection paths since > it's a ww mutex. We start by having drm_dp_mst_handle_up_req() hold this > when updating ports. For drm_dp_mst_handle_link_address_port() things > are a bit more complicated. As I've learned the hard way, we can grab > >lock.base for everything except for port->connector. See, our > normal driver probing paths end up generating this rather obvious > lockdep chain: > > >mode_config.mutex > -> crtc_ww_class_mutex/crtc_ww_class_acquire > -> >mutex > > However, sysfs grabs >mode_config.mutex in order to protect itself > from connector state changing under it. Because this entails grabbing > kn->count, e.g. the lock that the kernel provides for protecting sysfs > contexts, we end up grabbing kn->count followed by > >mode_config.mutex. This ends up creating an extremely rude chain: > > >count > -> >mode_config.mutex > -> crtc_ww_class_mutex/crtc_ww_class_acquire > -> >mutex > > I mean, look at that thing! It's just evil!!! This gross thing ends up > making any calls to drm_connector_register()/drm_connector_unregister() > impossible when holding any kind of modesetting lock. This is annoying > because ideally, we always want to ensure that > drm_dp_mst_port->connector never changes when doing an atomic commit or > check that would affect the atomic topology state so that it can > reliably and easily be used from future DRM DP MST helpers to assist > with tasks such as scanning through the current VCPI allocations and > adding connectors which need to have their allocations updated in > response to a bandwidth change or the like. > > Being able to hold >base.lock throughout the entire link probe > process would have been _great_, since we could prevent userspace from > ever seeing any states in-between individual port changes and as a > result likely end up with a much faster probe and more consistent > results from said probes. But without some rework of how we handle > connector probing in sysfs it's not at all currently possible. In the > future, maybe we can try using the sysfs locks to protect updates to > connector probing state and fix this mess. > > So for now, to protect everything other than port->connector under > >base.lock and ensure that we still have the guarantee that atomic > check/commit contexts will never see port->connector change we use a > silly trick. See: port->connector only needs to change in order to > ensure that input ports (see the MST spec) never have a ghost connector > associated with them. But, there's nothing stopping us from simply > throwing the entire port out and creating a new one in order to maintain > that requirement while still keeping port->connector consistent across > the lifetime of the port in atomic check/commit contexts. For all > intended purposes this works fine, as we validate ports in any contexts > we care about before using them and as such will end up reporting the > connector as disconnected until it's port's destruction finalizes. So, > we just do that in cases where we detect port->input has transitioned > from true->false. We don't need to worry about the other direction, > since a port without a connector isn't visible to userspace and as such > doesn't need to be protected by >base.lock until we finish > registering a connector for it. > > For updating members of drm_dp_mst_port other than port->connector, we > simply grab >base.lock in drm_dp_mst_link_probe_work() for already > registered ports, update said members and drop the lock before > potentially registering a connector and probing the link address of it's > children. > > Finally, we modify drm_dp_mst_detect_port() to take a modesetting lock > acquisition context in
[Bug 112103] Asrock 5700 XT Taichi fails to boot/hangs when a fifth monitor is connected
https://bugs.freedesktop.org/show_bug.cgi?id=112103 Bug ID: 112103 Summary: Asrock 5700 XT Taichi fails to boot/hangs when a fifth monitor is connected Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: not set Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: erik.brandsb...@gmail.com Created attachment 145796 --> https://bugs.freedesktop.org/attachment.cgi?id=145796=edit Screenshot of error on boot Linux Kernel: 5.3.2-050302-generic Mesa: OpenGL version string: 4.5 (Compatibility Profile) Mesa 19.3.0-devel (git-a9a9249 2019-10-21 bionic-oibaf-ppa) Monitors: BenQ XL2420TX (on DP) BenQ XL2420T (on DP) (Two monitors) LG 34UM61-P (on HDMI-1) Sony SDM-HX73 (on HDMI-2 connected to DVI) Attached image has the output when booted clean with all five monitors attached. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/cma-helper: Support DRM_MODE_DUMB_KERNEL_MAP flag
On Tue, Oct 22, 2019 at 6:30 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> > Add support in CMA helpers to handle callers specifying
> > DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> > change. drm_gem_cma_dumb_create() always creates a kernel mapping as
> > before. drm_gem_cma_dumb_create_internal() lets the caller set the flags
> > as desired. Therefore, update all the existing callers of
> > drm_gem_cma_dumb_create_internal() to also set the
> > DRM_MODE_DUMB_KERNEL_MAP flag.
> >
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: "James (Qian) Wang"
> > Cc: Liviu Dudau
> > Cc: Brian Starkey
> > Cc: Neil Armstrong
> > Cc: Kevin Hilman
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: Sandy Huang
> > Cc: "Heiko Stübner"
> > Cc: Yannick Fertre
> > Cc: Philippe Cornu
> > Cc: Benjamin Gaignard
> > Cc: Vincent Abriou
> > Cc: Maxime Coquelin
> > Cc: Alexandre Torgue
> > Cc: Chen-Yu Tsai
> > Cc: linux-amlo...@lists.infradead.org
> > Cc: linux-arm-ker...@lists.infradead.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Cc: linux-rockc...@lists.infradead.org
> > Cc: linux-st...@st-md-mailman.stormreply.com
> > Signed-off-by: Rob Herring
> > ---
> > .../gpu/drm/arm/display/komeda/komeda_kms.c | 1 +
> > drivers/gpu/drm/arm/malidp_drv.c | 1 +
> > drivers/gpu/drm/drm_gem_cma_helper.c | 48 +++
> > drivers/gpu/drm/meson/meson_drv.c | 1 +
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 +
> > drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 +
> > drivers/gpu/drm/stm/drv.c | 1 +
> > drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> > 8 files changed, 36 insertions(+), 19 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > index d49772de93e0..7cf0dc4cbfc1 100644
> > --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> > @@ -31,6 +31,7 @@ static int komeda_gem_cma_dumb_create(struct drm_file
> > *file,
> > u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
> >
> > args->pitch = ALIGN(pitch, mdev->chip.bus_width);
> > + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> >
> > return drm_gem_cma_dumb_create_internal(file, dev, args);
> > }
> > diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> > b/drivers/gpu/drm/arm/malidp_drv.c
> > index 8a76315aaa0f..aeb1a779ecc1 100644
> > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > @@ -465,6 +465,7 @@ static int malidp_dumb_create(struct drm_file
> > *file_priv,
> > u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
> >
> > args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8),
> > alignment);
> > + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> >
> > return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> > }
> > diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> > b/drivers/gpu/drm/drm_gem_cma_helper.c
> > index 4cebfe01e6ea..f91e9e8adeaf 100644
> > --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> > +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> > @@ -78,21 +78,8 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
> > return ERR_PTR(ret);
> > }
> >
> > -/**
> > - * drm_gem_cma_create - allocate an object with the given size
> > - * @drm: DRM device
> > - * @size: size of the object to allocate
> > - *
> > - * This function creates a CMA GEM object and allocates a contiguous chunk
> > of
> > - * memory as backing store. The backing memory has the writecombine
> > attribute
> > - * set.
> > - *
> > - * Returns:
> > - * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded
> > negative
> > - * error code on failure.
> > - */
> > -struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> > - size_t size)
> > +static struct drm_gem_cma_object *
> > +drm_gem_cma_create_flags(struct drm_device *drm, size_t size, u32 flags)
> > {
> > struct drm_gem_cma_object *cma_obj;
> > int ret;
> > @@ -103,6 +90,9 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> > drm_device *drm,
> > if (IS_ERR(cma_obj))
> > return cma_obj;
> >
> > + if (!(flags & DRM_MODE_DUMB_KERNEL_MAP))
> > + cma_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> > +
> > cma_obj->vaddr = dma_alloc_attrs(drm->dev, size, _obj->paddr,
> >GFP_KERNEL | __GFP_NOWARN,
> >cma_obj->dma_attrs);
> > @@ -119,6 +109,25 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> > drm_device *drm,
> > drm_gem_object_put_unlocked(_obj->base);
> > return ERR_PTR(ret);
Re: [PATCH 4/6] drm/cma-helper: Support DRM_MODE_DUMB_KERNEL_MAP flag
On Tue, Oct 22, 2019 at 6:40 AM Geert Uytterhoeven wrote: > > Hi Laurent, > > On Tue, Oct 22, 2019 at 1:30 PM Laurent Pinchart > wrote: > > On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote: > > > > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > > > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c > > > @@ -419,6 +419,7 @@ int rockchip_gem_dumb_create(struct drm_file > > > *file_priv, > > >* align to 64 bytes since Mali requires it. > > >*/ > > > args->pitch = ALIGN(min_pitch, 64); > > > + args->flags = DRM_MODE_DUMB_KERNEL_MAP; > > > args->size = args->pitch * args->height; > > > > My OCD gets triggered by flags appearing in the middle here while it is > > at the end in other drivers :-) > > ... while "flags" appears before "pitch" and "size" in the actual struct > definition... Aaarghl ;-) There was some reasoning here as my CMA helper conversion patch is going to insert code between flags and size. But to keep everyone's OCD in check, I can set flags first. Rob
[PATCH tip/core/rcu 03/10] drivers/gpu: Replace rcu_swap_protected() with rcu_replace()
From: "Paul E. McKenney" This commit replaces the use of rcu_swap_protected() with the more intuitively appealing rcu_replace() as a step towards removing rcu_swap_protected(). Link: https://lore.kernel.org/lkml/CAHk-=wiAsJLw1egFEE=z7-ggtm6wcvtyytxza1+bhqta4gg...@mail.gmail.com/ Reported-by: Linus Torvalds [ paulmck: From rcu_replace() to rcu_replace_pointer() per Ingo Molnar. ] Signed-off-by: Paul E. McKenney Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: David Airlie Cc: Daniel Vetter Cc: Chris Wilson Cc: Tvrtko Ursulin Cc: Cc: --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index 1cdfe05..3f3e803 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1629,7 +1629,7 @@ set_engines(struct i915_gem_context *ctx, i915_gem_context_set_user_engines(ctx); else i915_gem_context_clear_user_engines(ctx); - rcu_swap_protected(ctx->engines, set.engines, 1); + set.engines = rcu_replace_pointer(ctx->engines, set.engines, 1); mutex_unlock(>engines_mutex); call_rcu(>rcu, free_engines_rcu); -- 2.9.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Standardize arguments for callbacks
On Tue, Oct 22, 2019 at 7:16 PM Thomas Zimmermann wrote:
>
> Hi,
>
> there are two types of callbacks in struct
> drm_simple_display_pipe_funcs: functions that are genuine to simple KMS,
> and functions that are merely forwarded from another structure (crtc,
> plane, etc).
>
> In the former category are enable(), disable(), check(), and update().
> Those should probably receive a simple display pipe as their first argument.
mode_valid _very_ much belongs to this category too, since there's
mode_valid hooks also on other objects. But simple pipe helper
condenses that down to one mode_valid hook (we could also put the
mode_valid onto encoder, wouldn't change anything).
> In the latter category are mode_valid(), prepare_fb(), cleanup_fb(),
> enable_vblank(), and disable_vblank(). IMHO those functions should
> receive a pointer to the original structure as their first argument.
> This type provides the context in which the operations make sense. (Even
> their documentation already refers to the original structure.)
Now on those you can maybe make a case that they only exist in one
object. But the entire point of simple helpers was to condense the zoo
of drm types down to one. Only reason you don't also get a
drm_simple_display_pipe_state is that this one would be a bit more
work to make work correctly. If we full on leak all the underlying
objects, then you might as well set them up yourself and set up all
the hooks, it's just a few more lines of code.
Imo for simple pipe we should go more into that direction, not less.
> I admit that not all are as shareable as prepare_fb() and enable_fb().
> But what else than boiler-plate wrappers do we get from simple display
> pipe here?
Boiler plate wrappers is pretty much the entire point of simple pipe
helpers. Anytime you're interested in the things it abstracts away
(crtc, plane, encoder) you probably want your own atomic
implementation. That's why I don't think using simple pipe for fbdev
conversion is a good fit, it's not meant to be useful for all small
drivers. Only for the _really_ simple ones.
Otherwise if we readd all the bells and whistles to simple pipe
helpers, then we just end back where we started. That's also why I
personally think explicit simple wrappers would fit better, instead of
wrestling the prepare/cleanup_fb functions to match full atomic
helpers.
-Daniel
>
> Best regards
> Thomas
>
> Am 22.10.19 um 17:55 schrieb Daniel Vetter:
> > Passing the wrong type feels icky, everywhere else we use the pipe as
> > the first parameter. Spotted while discussing patches with Thomas
> > Zimmermann.
> >
> > Cc: Thomas Zimmermann
> > Cc: Noralf Trønnes
> > Cc: Gerd Hoffmann
> > Cc: Eric Anholt
> > Cc: Emil Velikov
> > Cc: virtualizat...@lists.linux-foundation.org
> > Cc: Linus Walleij
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/cirrus/cirrus.c | 2 +-
> > drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> > drivers/gpu/drm/pl111/pl111_display.c | 4 ++--
> > include/drm/drm_simple_kms_helper.h | 2 +-
> > 4 files changed, 5 insertions(+), 5 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/cirrus/cirrus.c
> > b/drivers/gpu/drm/cirrus/cirrus.c
> > index 7d08d067e1a4..248c9f765c45 100644
> > --- a/drivers/gpu/drm/cirrus/cirrus.c
> > +++ b/drivers/gpu/drm/cirrus/cirrus.c
> > @@ -390,7 +390,7 @@ static int cirrus_conn_init(struct cirrus_device
> > *cirrus)
> > /* -- */
> > /* cirrus (simple) display pipe
> > */
> >
> > -static enum drm_mode_status cirrus_pipe_mode_valid(struct drm_crtc *crtc,
> > +static enum drm_mode_status cirrus_pipe_mode_valid(struct
> > drm_simple_display_pipe *pipe,
> > const struct
> > drm_display_mode *mode)
> > {
> > if (cirrus_check_size(mode->hdisplay, mode->vdisplay, NULL) < 0)
> > diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> > b/drivers/gpu/drm/drm_simple_kms_helper.c
> > index 046055719245..15fb516ae2d8 100644
> > --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> > +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> > @@ -43,7 +43,7 @@ drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> > /* Anything goes */
> > return MODE_OK;
> >
> > - return pipe->funcs->mode_valid(crtc, mode);
> > + return pipe->funcs->mode_valid(pipe, mode);
> > }
> >
> > static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
> > diff --git a/drivers/gpu/drm/pl111/pl111_display.c
> > b/drivers/gpu/drm/pl111/pl111_display.c
> > index 024771a4083e..703ddc803c55 100644
> > --- a/drivers/gpu/drm/pl111/pl111_display.c
> > +++ b/drivers/gpu/drm/pl111/pl111_display.c
> > @@ -48,10 +48,10 @@ irqreturn_t pl111_irq(int irq, void *data)
> > }
> >
> > static enum drm_mode_status
> > -pl111_mode_valid(struct drm_crtc *crtc,
> > +pl111_mode_valid(struct drm_simple_display_pipe *pipe,
> >const
Re: [PATCH 2/2] drm/todo: Add levels
On Tue, Oct 22, 2019 at 7:33 PM Thomas Zimmermann wrote: > > Hi > > Am 22.10.19 um 17:25 schrieb Daniel Vetter: > > Should help new people pick suitable tasks. > > > > Cc: Rodrigo Siqueira > > Cc: Manasi Navare > > Cc: Sean Paul > > Signed-off-by: Daniel Vetter > > --- > > Documentation/gpu/todo.rst | 73 ++ > > 1 file changed, 73 insertions(+) > > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > > index 9ac102922712..73c51b5a0997 100644 > > --- a/Documentation/gpu/todo.rst > > +++ b/Documentation/gpu/todo.rst > > @@ -7,6 +7,22 @@ TODO list > > This section contains a list of smaller janitorial tasks in the kernel DRM > > graphics subsystem useful as newbie projects. Or for slow rainy days. > > > > +Difficulty > > +-- > > + > > +To make it easier task are categorized into different levels: > > + > > +Starter: Good tasks to get started with the DRM subsystem. > > + > > +Intermediate: Tasks which need some experience with working in the DRM > > +subsystem, or some specific GPU/display graphics knowledge. For debugging > > issue > > +it's good to have the relevant hardware (or a virtual driver set up) > > available > > +for testing. > > + > > +Advanced: Tricky tasks that need fairly good understanding of the DRM > > subsystem > > +and graphics topics. Generally need the relevant hardware for development > > and > > +testing. > > I like this idea. > > Acked-by: Thomas Zimmermann > > But please see my comment further below. > > > + > > Subsystem-wide refactorings > > === > > > > @@ -20,6 +36,8 @@ implementations), and then remove it. > > > > Contact: Daniel Vetter, respective driver maintainers > > > > +Level: Intermediate > > + > > Convert existing KMS drivers to atomic modesetting > > -- > > > > @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver > > callbacks. > > > > Contact: Daniel Vetter, respective driver maintainers > > > > +Level: Advanced > > + > > Clean up the clipped coordination confusion around planes > > - > > > > @@ -50,6 +70,8 @@ helpers. > > > > Contact: Ville Syrjälä, Daniel Vetter, driver maintainers > > > > +Level: Advanced > > + > > Convert early atomic drivers to async commit helpers > > > > > > @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these > > bugs is good anyway. > > > > Contact: Daniel Vetter, respective driver maintainers > > > > +Level: Advanced > > + > > Fallout from atomic KMS > > --- > > > > @@ -91,6 +115,8 @@ interfaces to fix these issues: > > > > Contact: Daniel Vetter > > > > +Level: Intermediate > > + > > Get rid of dev->struct_mutex from GEM drivers > > - > > > > @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings > > scheme. Currently only t > > > > Contact: Daniel Vetter, respective driver maintainers > > > > +Level: Advanced > > + > > Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* > > equivalent > > > > > > > > @@ -129,6 +157,8 @@ are better. > > > > Contact: Sean Paul, Maintainer of the driver you plan to convert > > > > +Level: Starter > > + > > Convert drivers to use simple modeset suspend/resume > > > > > > @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic > > modeset drivers. > > > > Contact: Maintainer of the driver you plan to convert > > > > +Level: Intermediate > > + > > Convert drivers to use drm_fb_helper_fbdev_setup/teardown() > > --- > > > > @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown(). > > > > Contact: Maintainer of the driver you plan to convert > > > > +Level: Intermediate > > + > > Clean up mmap forwarding > > > > > > @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still > > needs to be rolled out. > > > > Contact: Daniel Vetter > > > > +Level: Intermediate > > + > > Generic fbdev defio support > > --- > > > > @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this. > > > > Contact: Daniel Vetter, Noralf Tronnes > > > > +Level: Advanced > > + > > idr_init_base() > > --- > > > > @@ -206,6 +244,8 @@ efficient. > > > > Contact: Daniel Vetter > > > > +Level: Starter > > + > > struct drm_gem_object_funcs > > --- > > > > @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that > > doesn't require the > > vmapping to be present (different hook for prime importing). Plus this > > needs to > > be rolled out to all drivers using their own implementations,
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #124 from yam...@yamagi.org --- Interestingly I've got the problem the other way round. My 5700XT was running fine since I got it about two weeks ago. This is Arch Linux, I've run Mesa 19.2.1 and llvm-libs 9.0.0 since day one. The card was stable with 5.4-RC2 and 5.4-RC3, not a single hang in about 10 hours The Witcher 3 under wine + dxvk and Yamagi Quake II with OpenGL 3.2 renderer. After I upgraded to 5.4-RC4 I've seen several GPU hangs. The last one, and the only one that's still in the logs was: [drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring sdma0 timeout, signaled seq=85270, emitted seq=85272 That one was in Yamagi Quake II, but I had hangs on the desktop and in The Witcher 3. I have no umr reports so far. I've just compiled the tool and will see if I can get some. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/todo: Add levels
Hi Am 22.10.19 um 17:25 schrieb Daniel Vetter: > Should help new people pick suitable tasks. > > Cc: Rodrigo Siqueira > Cc: Manasi Navare > Cc: Sean Paul > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 73 ++ > 1 file changed, 73 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 9ac102922712..73c51b5a0997 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -7,6 +7,22 @@ TODO list > This section contains a list of smaller janitorial tasks in the kernel DRM > graphics subsystem useful as newbie projects. Or for slow rainy days. > > +Difficulty > +-- > + > +To make it easier task are categorized into different levels: > + > +Starter: Good tasks to get started with the DRM subsystem. > + > +Intermediate: Tasks which need some experience with working in the DRM > +subsystem, or some specific GPU/display graphics knowledge. For debugging > issue > +it's good to have the relevant hardware (or a virtual driver set up) > available > +for testing. > + > +Advanced: Tricky tasks that need fairly good understanding of the DRM > subsystem > +and graphics topics. Generally need the relevant hardware for development and > +testing. I like this idea. Acked-by: Thomas Zimmermann But please see my comment further below. > + > Subsystem-wide refactorings > === > > @@ -20,6 +36,8 @@ implementations), and then remove it. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Intermediate > + > Convert existing KMS drivers to atomic modesetting > -- > > @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Clean up the clipped coordination confusion around planes > - > > @@ -50,6 +70,8 @@ helpers. > > Contact: Ville Syrjälä, Daniel Vetter, driver maintainers > > +Level: Advanced > + > Convert early atomic drivers to async commit helpers > > > @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs > is good anyway. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Fallout from atomic KMS > --- > > @@ -91,6 +115,8 @@ interfaces to fix these issues: > > Contact: Daniel Vetter > > +Level: Intermediate > + > Get rid of dev->struct_mutex from GEM drivers > - > > @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings > scheme. Currently only t > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent > > > @@ -129,6 +157,8 @@ are better. > > Contact: Sean Paul, Maintainer of the driver you plan to convert > > +Level: Starter > + > Convert drivers to use simple modeset suspend/resume > > > @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset > drivers. > > Contact: Maintainer of the driver you plan to convert > > +Level: Intermediate > + > Convert drivers to use drm_fb_helper_fbdev_setup/teardown() > --- > > @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown(). > > Contact: Maintainer of the driver you plan to convert > > +Level: Intermediate > + > Clean up mmap forwarding > > > @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still > needs to be rolled out. > > Contact: Daniel Vetter > > +Level: Intermediate > + > Generic fbdev defio support > --- > > @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this. > > Contact: Daniel Vetter, Noralf Tronnes > > +Level: Advanced > + > idr_init_base() > --- > > @@ -206,6 +244,8 @@ efficient. > > Contact: Daniel Vetter > > +Level: Starter > + > struct drm_gem_object_funcs > --- > > @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't > require the > vmapping to be present (different hook for prime importing). Plus this needs > to > be rolled out to all drivers using their own implementations, too. > > +Level: Intermediate > + > Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate > - > > @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > >
[Bug 111986] 5700 XT hangs entire system in games
https://bugs.freedesktop.org/show_bug.cgi?id=111986 --- Comment #16 from Daniel Suarez --- (In reply to Sabbie from comment #15) > I'm having the same issue on a 5700 (non-xt). > > It seems to be this bug: > > https://bugs.freedesktop.org/show_bug.cgi?id=111481#c9 Yeah, apologies I have not provided the logs asked I've had a few hard days due to college entrance shit, but it's the exact same issue as the one listed in the bug report you linked, this is completely unacceptable from Amd honestly -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 Daniel Suarez changed: What|Removed |Added Priority|not set |highest -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/21] drm/exynos: Fix potential unbalanced calls to pm_runtime_put
On Fri, 11 Oct 2019 15:54:53 +0200 Andrzej Hajda wrote: > On 26.08.2019 17:26, Boris Brezillon wrote: > > The encoder->enable() can't report errors and is expected to always > > succeed. If we call pm_runtime_put() in the exynos_dsi_enable() error > > path (as currently done) we'll have unbalanced get/put calls when > > encoder->disable() is called. > > > True I just realized this is actually not the case, because the DSIM_STATE_ENABLED flag is cleared in the error path, and exynos_dsi_disable() bails out early when DSIM_STATE_ENABLED is not set. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/6] drm/mediatek: Convert to use CMA helpers
Hi Rob,
On 21/10/2019 23:45, Rob Herring wrote:
> The only reason the Mediatek driver doesn't use the CMA helpers is it
> sets DMA_ATTR_NO_KERNEL_MAPPING and does a vmap() on demand. Using
> vmap() is not even guaranteed to work as DMA buffers may not have a
> struct page. Now that the CMA helpers support setting
> DMA_ATTR_NO_KERNEL_MAPPING as needed or not, convert Mediatek driver to
> use CMA helpers.
>
> Cc: CK Hu
> Cc: Philipp Zabel
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Matthias Brugger
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-media...@lists.infradead.org
> Signed-off-by: Rob Herring
> ---
I tested this on my Chromebook with some patches on top of v5.4-rc1 [1], which
work. If I add your patches on top of that, the system does not boot up.
Unfortunately I don't have a serial console, so I wasn't able to see if there is
any error message.
I checked the config and didn't see any suspicious
I added Uli and some guys from chromium, maybe someone can provide some
logs/insights.
Regards,
Matthias
[1] https://github.com/uli/kernel/tree/elm-working-5.4
> drivers/gpu/drm/mediatek/Makefile| 1 -
> drivers/gpu/drm/mediatek/mtk_drm_crtc.c | 2 +-
> drivers/gpu/drm/mediatek/mtk_drm_drv.c | 28 +--
> drivers/gpu/drm/mediatek/mtk_drm_fb.c| 1 -
> drivers/gpu/drm/mediatek/mtk_drm_gem.c | 289 ---
> drivers/gpu/drm/mediatek/mtk_drm_gem.h | 51
> drivers/gpu/drm/mediatek/mtk_drm_plane.c | 7 +-
> 7 files changed, 15 insertions(+), 364 deletions(-)
> delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.c
> delete mode 100644 drivers/gpu/drm/mediatek/mtk_drm_gem.h
>
> diff --git a/drivers/gpu/drm/mediatek/Makefile
> b/drivers/gpu/drm/mediatek/Makefile
> index 82ae49c64221..50a50e86738f 100644
> --- a/drivers/gpu/drm/mediatek/Makefile
> +++ b/drivers/gpu/drm/mediatek/Makefile
> @@ -8,7 +8,6 @@ mediatek-drm-y := mtk_disp_color.o \
> mtk_drm_ddp_comp.o \
> mtk_drm_drv.o \
> mtk_drm_fb.o \
> - mtk_drm_gem.o \
> mtk_drm_plane.o \
> mtk_dsi.o \
> mtk_mipi_tx.o \
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> index 34a731755791..638d57e8ac12 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_crtc.c
> @@ -11,6 +11,7 @@
>
> #include
> #include
> +#include
> #include
> #include
>
> @@ -18,7 +19,6 @@
> #include "mtk_drm_crtc.h"
> #include "mtk_drm_ddp.h"
> #include "mtk_drm_ddp_comp.h"
> -#include "mtk_drm_gem.h"
> #include "mtk_drm_plane.h"
>
> /**
> diff --git a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> index 352b81a7a670..36f32507e5fb 100644
> --- a/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> +++ b/drivers/gpu/drm/mediatek/mtk_drm_drv.c
> @@ -28,7 +28,6 @@
> #include "mtk_drm_ddp_comp.h"
> #include "mtk_drm_drv.h"
> #include "mtk_drm_fb.h"
> -#include "mtk_drm_gem.h"
>
> #define DRIVER_NAME "mediatek"
> #define DRIVER_DESC "Mediatek SoC DRM"
> @@ -335,16 +334,14 @@ static void mtk_drm_kms_deinit(struct drm_device *drm)
> drm_mode_config_cleanup(drm);
> }
>
> -static const struct file_operations mtk_drm_fops = {
> - .owner = THIS_MODULE,
> - .open = drm_open,
> - .release = drm_release,
> - .unlocked_ioctl = drm_ioctl,
> - .mmap = mtk_drm_gem_mmap,
> - .poll = drm_poll,
> - .read = drm_read,
> - .compat_ioctl = drm_compat_ioctl,
> -};
> +DEFINE_DRM_GEM_CMA_FOPS(mtk_drm_fops);
> +
> +static int mtk_drm_gem_dumb_create(struct drm_file *file_priv,
> +struct drm_device *dev,
> +struct drm_mode_create_dumb *args)
> +{
> + return drm_gem_cma_dumb_create_internal(file_priv, dev, args);
> +}
>
> /*
> * We need to override this because the device used to import the memory is
> @@ -361,18 +358,15 @@ struct drm_gem_object *mtk_drm_gem_prime_import(struct
> drm_device *dev,
> static struct drm_driver mtk_drm_driver = {
> .driver_features = DRIVER_MODESET | DRIVER_GEM | DRIVER_ATOMIC,
>
> - .gem_free_object_unlocked = mtk_drm_gem_free_object,
> .gem_vm_ops = _gem_cma_vm_ops,
> + .gem_create_object = drm_cma_gem_create_object_default_funcs,
> .dumb_create = mtk_drm_gem_dumb_create,
>
> .prime_handle_to_fd = drm_gem_prime_handle_to_fd,
> .prime_fd_to_handle = drm_gem_prime_fd_to_handle,
> .gem_prime_import = mtk_drm_gem_prime_import,
> - .gem_prime_get_sg_table = mtk_gem_prime_get_sg_table,
> - .gem_prime_import_sg_table = mtk_gem_prime_import_sg_table,
> - .gem_prime_mmap = mtk_drm_gem_mmap_buf,
> - .gem_prime_vmap = mtk_drm_gem_prime_vmap,
> - .gem_prime_vunmap = mtk_drm_gem_prime_vunmap,
> + .gem_prime_import_sg_table = drm_gem_cma_prime_import_sg_table_vmap,
> + .gem_prime_mmap =
Re: [PATCH] drm/doc: Drop misleading comment on drm_mode_config_cleanup
On Tuesday, 22 October 2019 17:37:17 BST Daniel Vetter wrote:
> This is not something we'll fix, because failing to clean up stuff (or
> doing it in the wrong order) is a driver bug. The offending FIXME goes
> all the way back to the original modeset merge.
>
> We've added a WARN_ON in
>
> commit 2b677e8c08eed11e4ebe66a7c334f03e389a19a3
> Author: Daniel Vetter
> Date: Mon Dec 10 21:16:05 2012 +0100
>
> drm: reference framebuffers which are on the idr
>
> including a comment blaming drivers on this. Right thing to do is most
> likely drm_atomic_helper_shutdown plus making sure that
> drm_mode_config_cleanup is not called too early (i.e. not in driver
> unload, but only in the final drm_device release callback).
>
> Cc: Mihail Atanassov
> Reported-by: Mihail Atanassov
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_mode_config.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_mode_config.c
> b/drivers/gpu/drm/drm_mode_config.c
> index 7bc03c3c154f..3b570a404933 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -428,8 +428,6 @@ EXPORT_SYMBOL(drm_mode_config_init);
> * Note that since this /should/ happen single-threaded at driver/device
> * teardown time, no locking is required. It's the driver's job to ensure
> that
> * this guarantee actually holds true.
> - *
> - * FIXME: cleanup any dangling user buffer objects too
> */
> void drm_mode_config_cleanup(struct drm_device *dev)
> {
>
Thanks,
Reviewed-by: Mihail Atanassov
--
Mihail
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/simple-kms: Standardize arguments for callbacks
Hi,
there are two types of callbacks in struct
drm_simple_display_pipe_funcs: functions that are genuine to simple KMS,
and functions that are merely forwarded from another structure (crtc,
plane, etc).
In the former category are enable(), disable(), check(), and update().
Those should probably receive a simple display pipe as their first argument.
In the latter category are mode_valid(), prepare_fb(), cleanup_fb(),
enable_vblank(), and disable_vblank(). IMHO those functions should
receive a pointer to the original structure as their first argument.
This type provides the context in which the operations make sense. (Even
their documentation already refers to the original structure.)
I admit that not all are as shareable as prepare_fb() and enable_fb().
But what else than boiler-plate wrappers do we get from simple display
pipe here?
Best regards
Thomas
Am 22.10.19 um 17:55 schrieb Daniel Vetter:
> Passing the wrong type feels icky, everywhere else we use the pipe as
> the first parameter. Spotted while discussing patches with Thomas
> Zimmermann.
>
> Cc: Thomas Zimmermann
> Cc: Noralf Trønnes
> Cc: Gerd Hoffmann
> Cc: Eric Anholt
> Cc: Emil Velikov
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: Linus Walleij
> Signed-off-by: Daniel Vetter
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 2 +-
> drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
> drivers/gpu/drm/pl111/pl111_display.c | 4 ++--
> include/drm/drm_simple_kms_helper.h | 2 +-
> 4 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index 7d08d067e1a4..248c9f765c45 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -390,7 +390,7 @@ static int cirrus_conn_init(struct cirrus_device *cirrus)
> /* -- */
> /* cirrus (simple) display pipe*/
>
> -static enum drm_mode_status cirrus_pipe_mode_valid(struct drm_crtc *crtc,
> +static enum drm_mode_status cirrus_pipe_mode_valid(struct
> drm_simple_display_pipe *pipe,
> const struct
> drm_display_mode *mode)
> {
> if (cirrus_check_size(mode->hdisplay, mode->vdisplay, NULL) < 0)
> diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
> b/drivers/gpu/drm/drm_simple_kms_helper.c
> index 046055719245..15fb516ae2d8 100644
> --- a/drivers/gpu/drm/drm_simple_kms_helper.c
> +++ b/drivers/gpu/drm/drm_simple_kms_helper.c
> @@ -43,7 +43,7 @@ drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
> /* Anything goes */
> return MODE_OK;
>
> - return pipe->funcs->mode_valid(crtc, mode);
> + return pipe->funcs->mode_valid(pipe, mode);
> }
>
> static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
> diff --git a/drivers/gpu/drm/pl111/pl111_display.c
> b/drivers/gpu/drm/pl111/pl111_display.c
> index 024771a4083e..703ddc803c55 100644
> --- a/drivers/gpu/drm/pl111/pl111_display.c
> +++ b/drivers/gpu/drm/pl111/pl111_display.c
> @@ -48,10 +48,10 @@ irqreturn_t pl111_irq(int irq, void *data)
> }
>
> static enum drm_mode_status
> -pl111_mode_valid(struct drm_crtc *crtc,
> +pl111_mode_valid(struct drm_simple_display_pipe *pipe,
>const struct drm_display_mode *mode)
> {
> - struct drm_device *drm = crtc->dev;
> + struct drm_device *drm = pipe->crtc.dev;
> struct pl111_drm_dev_private *priv = drm->dev_private;
> u32 cpp = priv->variant->fb_bpp / 8;
> u64 bw;
> diff --git a/include/drm/drm_simple_kms_helper.h
> b/include/drm/drm_simple_kms_helper.h
> index 4d89cd0a60db..15afee9cf049 100644
> --- a/include/drm/drm_simple_kms_helper.h
> +++ b/include/drm/drm_simple_kms_helper.h
> @@ -49,7 +49,7 @@ struct drm_simple_display_pipe_funcs {
>*
>* drm_mode_status Enum
>*/
> - enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
> + enum drm_mode_status (*mode_valid)(struct drm_simple_display_pipe *pipe,
> const struct drm_display_mode *mode);
>
> /**
>
--
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
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/todo: Add levels
On Tue, Oct 22, 2019 at 05:25:30PM +0200, Daniel Vetter wrote: > Should help new people pick suitable tasks. > > Cc: Rodrigo Siqueira > Cc: Manasi Navare > Cc: Sean Paul Reviewed-by: Sean Paul > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 73 ++ > 1 file changed, 73 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 9ac102922712..73c51b5a0997 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -7,6 +7,22 @@ TODO list > This section contains a list of smaller janitorial tasks in the kernel DRM > graphics subsystem useful as newbie projects. Or for slow rainy days. > > +Difficulty > +-- > + > +To make it easier task are categorized into different levels: > + > +Starter: Good tasks to get started with the DRM subsystem. > + > +Intermediate: Tasks which need some experience with working in the DRM > +subsystem, or some specific GPU/display graphics knowledge. For debugging > issue > +it's good to have the relevant hardware (or a virtual driver set up) > available > +for testing. > + > +Advanced: Tricky tasks that need fairly good understanding of the DRM > subsystem > +and graphics topics. Generally need the relevant hardware for development and > +testing. > + > Subsystem-wide refactorings > === > > @@ -20,6 +36,8 @@ implementations), and then remove it. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Intermediate > + > Convert existing KMS drivers to atomic modesetting > -- > > @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Clean up the clipped coordination confusion around planes > - > > @@ -50,6 +70,8 @@ helpers. > > Contact: Ville Syrjälä, Daniel Vetter, driver maintainers > > +Level: Advanced > + > Convert early atomic drivers to async commit helpers > > > @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs > is good anyway. > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Fallout from atomic KMS > --- > > @@ -91,6 +115,8 @@ interfaces to fix these issues: > > Contact: Daniel Vetter > > +Level: Intermediate > + > Get rid of dev->struct_mutex from GEM drivers > - > > @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings > scheme. Currently only t > > Contact: Daniel Vetter, respective driver maintainers > > +Level: Advanced > + > Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent > > > @@ -129,6 +157,8 @@ are better. > > Contact: Sean Paul, Maintainer of the driver you plan to convert > > +Level: Starter > + > Convert drivers to use simple modeset suspend/resume > > > @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset > drivers. > > Contact: Maintainer of the driver you plan to convert > > +Level: Intermediate > + > Convert drivers to use drm_fb_helper_fbdev_setup/teardown() > --- > > @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown(). > > Contact: Maintainer of the driver you plan to convert > > +Level: Intermediate > + > Clean up mmap forwarding > > > @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still > needs to be rolled out. > > Contact: Daniel Vetter > > +Level: Intermediate > + > Generic fbdev defio support > --- > > @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this. > > Contact: Daniel Vetter, Noralf Tronnes > > +Level: Advanced > + > idr_init_base() > --- > > @@ -206,6 +244,8 @@ efficient. > > Contact: Daniel Vetter > > +Level: Starter > + > struct drm_gem_object_funcs > --- > > @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't > require the > vmapping to be present (different hook for prime importing). Plus this needs > to > be rolled out to all drivers using their own implementations, too. > > +Level: Intermediate > + > Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate > - > > @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already > completed in drm core. > > Contact: Sean Paul, respective driver maintainers > > +Level: Starter > + > Rename CMA helpers to DMA
Re: [PATCH 1/2] drm/todo: Remove i915 device_link task
On Tue, Oct 22, 2019 at 05:25:29PM +0200, Daniel Vetter wrote: > Done with > > commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a > Author: Imre Deak > Date: Tue Oct 23 17:43:10 2018 +0300 > > drm/i915: Ensure proper HDA suspend/resume ordering with a device link > > Cc: Imre Deak > Signed-off-by: Daniel Vetter Reviewed-by: Sean Paul > --- > Documentation/gpu/todo.rst | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 23b3a67794ba..9ac102922712 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -438,13 +438,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks. > > Contact: Harry Wentland, Alex Deucher > > -i915 > - > - > -- Our early/late pm callbacks could be removed in favour of using > - device_link_add to model the dependency between i915 and snd_had. See > - https://dri.freedesktop.org/docs/drm/driver-api/device_link.html > - > Bootsplash > == > > -- > 2.23.0 > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 05/46] ARM: pxa: split up mach/hardware.h
On Fri, Oct 18, 2019 at 05:41:20PM +0200, Arnd Bergmann wrote: > The mach/hardware.h is included in lots of places, and it provides > three different things on pxa: Acked-by: Mark Brown signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/doc: Drop misleading comment on drm_mode_config_cleanup
This is not something we'll fix, because failing to clean up stuff (or
doing it in the wrong order) is a driver bug. The offending FIXME goes
all the way back to the original modeset merge.
We've added a WARN_ON in
commit 2b677e8c08eed11e4ebe66a7c334f03e389a19a3
Author: Daniel Vetter
Date: Mon Dec 10 21:16:05 2012 +0100
drm: reference framebuffers which are on the idr
including a comment blaming drivers on this. Right thing to do is most
likely drm_atomic_helper_shutdown plus making sure that
drm_mode_config_cleanup is not called too early (i.e. not in driver
unload, but only in the final drm_device release callback).
Cc: Mihail Atanassov
Reported-by: Mihail Atanassov
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/drm_mode_config.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 7bc03c3c154f..3b570a404933 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -428,8 +428,6 @@ EXPORT_SYMBOL(drm_mode_config_init);
* Note that since this /should/ happen single-threaded at driver/device
* teardown time, no locking is required. It's the driver's job to ensure that
* this guarantee actually holds true.
- *
- * FIXME: cleanup any dangling user buffer objects too
*/
void drm_mode_config_cleanup(struct drm_device *dev)
{
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 0/8] Add dual-LVDS panel support to EK874
Hi Laurent, Did you have any time to look into this series? Thanks, Fab > From: Fabrizio Castro > Sent: 28 August 2019 19:37 > Subject: [PATCH v3 0/8] Add dual-LVDS panel support to EK874 > > Dear All, > > this series adds support for dual-LVDS panel IDK-2121WR > from Advantech: > https://buy.advantech.eu/Displays/Embedded-LCD-Kits-High-Brightness/model-IDK-2121WR-K2FHA2E.htm > > V3 approaches the problem in a completely different way, we now > have two new properties to mark the ports in the DT as receiving > even pixels and odd pixels: dual-lvds-even-pixels and dual-lvds-odd-pixels, > which means device drivers should not use bridge specific or panel > specific dual_link flags. Also, in this case the DT describes the > connection fully. > > In order for the solution to be generic, I have exported a new helper > (drm_of_lvds_get_dual_link_configuration) to walk the device tree, > and figure out if the connection is dual-LVDS. The same helper gives > information about the configuration of the connection. If Px is connected > to a port expecting even pixels and Py is connected to a port expecting > odd pixels, then the helper returns DRM_LVDS_DUAL_LINK_EVEN_ODD_PIXELS > (like in the example below), otherwise it returns > DRM_LVDS_DUAL_LINK_ODD_EVEN_PIXELS. > > > dual-lvds-even-pixels > || || > || Px |-->| Pn || > || || > | SOURCE | dual-lvds-odd-pixels | SINK | > || || > || Py |-->| Pm || > || || > > > The device driver for the encoder then will work out if with the current > wiring the pixels need swapping or not. > > The same solution works for both panels and bridges. > > Since the DT describes the connection fully, driver > drivers/gpu/drm/panel/panel-lvds.c works out-of-the-box, no changes > required, however, this implementation opens up a problem with the > dt-bindings. > Driver drivers/gpu/drm/panel/panel-lvds.c can still be pleased by > a port node, but also by a ports node. > I have created Documentation/devicetree/bindings/display/bus-timings/lvds.yaml > with the idea of including it from panels and bridges dt-bindings > supporting dual-LVDS (and of course the dt-bindings for the specific > devices should say which port should be marked as what), but file > Documentation/devicetree/bindings/display/panel/lvds.yaml formally > requires property "port", while with this implementation it should require > OneOf "port" and "ports", and unfortunately I can't seem to find a neat way > aroud that, other than creating a new compatible string > (e.g. "panel-dual-lvds"), a new dt-binding document for it, and of course > adding > support for the new compatible string to drivers/gpu/drm/panel/panel-lvds.c. > As a result, this series is missing (at least) a patch necessary to fully > document the new implementation within > Documentation/devicetree/bindings/display/panel/lvds.yaml > > Rob, do you have any suggestions? Do you think this idea works ok from a > documentation point of view? By the way, I don't really know what I am doing > with the yaml dt-bindings, I hope you won't be horrified by this series :-P > > I hope I was able to deliver the concept clearly, if not please just ask. > > Comments are very much appreciated. > > Thanks, > Fab > > Fabrizio Castro (8): > dt-bindings: display: Add bindings for LVDS bus-timings > dt-bindings: display: Add idk-2121wr binding > drm: Add bus timings helper > drm: rcar-du: lvds: Add dual-LVDS panels support > drm: bridge: thc63: Do not report input bus mode through bridge > timings > arm64: dts: renesas: Add EK874 board with idk-2121wr display support > [HACK] arm64: dts: renesas: draak: Enable LVDS > [HACK] arm64: dts: renesas: draak: Enable LVDS dual-link operation > > .../bindings/display/bus-timings/lvds.yaml | 38 +++ > .../display/panel/advantech,idk-2121wr.yaml| 90 > arch/arm64/boot/dts/renesas/Makefile | 3 +- > .../boot/dts/renesas/r8a774c0-ek874-idk-2121wr.dts | 116 > + > arch/arm64/boot/dts/renesas/r8a77990-ebisu.dts | 21 +++- > arch/arm64/boot/dts/renesas/r8a77995-draak.dts | 26 +++-- > drivers/gpu/drm/Makefile | 3 +- > drivers/gpu/drm/bridge/thc63lvd1024.c | 9 +- > drivers/gpu/drm/drm_bus_timings.c | 97 + > drivers/gpu/drm/rcar-du/rcar_lvds.c| 110 +++ > include/drm/drm_bridge.h | 8 -- > include/drm/drm_bus_timings.h | 21 > 12 files changed, 473 insertions(+), 69 deletions(-) > create mode 100644 >
Re: [PATCH 2/2] drm/vc4: Use drm_hdmi_avi_infoframe_bars()
On Tue, Oct 08, 2019 at 07:48:14PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > Use the new drm_hdmi_avi_infoframe_bars() helper instead > of hand rolling it. > > Cc: Eric Anholt > Cc: Boris Brezillon > Signed-off-by: Ville Syrjälä Series pushed to drm-misc-next with Boris's irc rb: 19:03 < vsyrjala> anholt: bbrezillon: thoughts on https://patchwork.freedesktop.org/series/67742/ ? 19:05 < bbrezillon> vsyrjala: R-b Thanks. > --- > drivers/gpu/drm/vc4/vc4_hdmi.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/drivers/gpu/drm/vc4/vc4_hdmi.c b/drivers/gpu/drm/vc4/vc4_hdmi.c > index 0853b980bcb3..1c62c6c9244b 100644 > --- a/drivers/gpu/drm/vc4/vc4_hdmi.c > +++ b/drivers/gpu/drm/vc4/vc4_hdmi.c > @@ -398,10 +398,7 @@ static void vc4_hdmi_set_avi_infoframe(struct > drm_encoder *encoder) > HDMI_QUANTIZATION_RANGE_LIMITED : > HDMI_QUANTIZATION_RANGE_FULL); > > - frame.avi.right_bar = cstate->tv.margins.right; > - frame.avi.left_bar = cstate->tv.margins.left; > - frame.avi.top_bar = cstate->tv.margins.top; > - frame.avi.bottom_bar = cstate->tv.margins.bottom; > + drm_hdmi_avi_infoframe_bars(, cstate); > > vc4_hdmi_write_infoframe(encoder, ); > } > -- > 2.21.0 -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #123 from Sabbie --- I'm having the same problem on an RX 5700, running Arch. - 3.5.7 Kernel - mesa-git 1:19.3.0_devel.116477.3ad6154f4eb-1 - llvm-git 10.0.0_r329841.1c982af0599-1 GPU crashes on various activities and seemingly at random. Happened both while browsing and playing games. Usually it crashes with `ring gfx_0.0.0 timeout`. Sometimes it works for hours, sometimes it crashes every 5 minutes. I can provide logs if needed. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111986] 5700 XT hangs entire system in games
https://bugs.freedesktop.org/show_bug.cgi?id=111986 --- Comment #15 from Sabbie --- I'm having the same issue on a 5700 (non-xt). It seems to be this bug: https://bugs.freedesktop.org/show_bug.cgi?id=111481#c9 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: radeon Disabling GPU acceleration (WB disabled?)
On 2019-10-20 11:21 p.m., Meelis Roos wrote: > I tried 5.2, 5.3 and 5.4-rc4 on my old Fujitsu RX220 with integrated > Radeon RV100. Dmesg tells that GPU acceleration is disabled. I do not > know if it has been enabled in the past - no old kernels handy at the > moment. > > From dmesg it looks like something with MTRR maybe: WB disabled. That's harmless. > [ 8.535975] [drm] Driver supports precise vblank timestamp query. > [ 8.535981] radeon :00:05.0: Disabling GPU acceleration This looks like drm_irq_install returns an error in radeon_irq_kms_init. -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 05/14] drm/dp_mst: Add probe_lock
On Mon, Oct 21, 2019 at 10:36:00PM -0400, Lyude Paul wrote:
> Currently, MST lacks locking in a lot of places that really should have
> some sort of locking. Hotplugging and link address code paths are some
> of the offenders here, as there is actually nothing preventing us from
> running a link address probe while at the same time handling a
> connection status update request - something that's likely always been
> possible but never seen in the wild because hotplugging has been broken
> for ages now (with the exception of amdgpu, for reasons I don't think
> are worth digging into very far).
>
> Note: I'm going to start using the term "in-memory topology layout" here
> to refer to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports.
>
> Locking in these places is a little tougher then it looks though.
> Generally we protect anything having to do with the in-memory topology
> layout under >lock. But this becomes nearly impossible to do from
> the context of link address probes due to the fact that >lock is
> usually grabbed under random various modesetting locks, meaning that
> there's no way we can just invert the >lock order and keep it
> locked throughout the whole process of updating the topology.
>
> Luckily there are only two workers which can modify the in-memory
> topology layout: drm_dp_mst_up_req_work() and
> drm_dp_mst_link_probe_work(), meaning as long as we prevent these two
> workers from traveling the topology layout in parallel with the intent
> of updating it we don't need to worry about grabbing >lock in these
> workers for reads. We only need to grab >lock in these workers for
> writes, so that readers outside these two workers are still protected
> from the topology layout changing beneath them.
>
> So, add the new >probe_lock and use it in both
> drm_dp_mst_link_probe_work() and drm_dp_mst_up_req_work(). Additionally,
> add some more detailed explanations for how this locking is intended to
> work to drm_dp_mst_port->mstb and drm_dp_mst_branch->ports.
This seems like a good solution to me, thanks for working this through!
Any chance we could add a WARN_ON(!mutex_is_locked(>probe_lock)); somewhere
centrally called by all paths modifying the in-memory topology layout?
drm_dp_add_port perhaps? That way we have a fallback in case something else
starts mucking with the topology.
Other than that,
Reviewed-by: Sean Paul
>
> Signed-off-by: Lyude Paul
> Cc: Juston Li
> Cc: Imre Deak
> Cc: Ville Syrjälä
> Cc: Harry Wentland
> Cc: Daniel Vetter
> Cc: Sean Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 28 ++-
> include/drm/drm_dp_mst_helper.h | 32 +++
> 2 files changed, 46 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 08c316a727df..11d842f0bff5 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2147,37 +2147,40 @@ static void drm_dp_check_and_send_link_address(struct
> drm_dp_mst_topology_mgr *m
> struct drm_dp_mst_branch *mstb)
> {
> struct drm_dp_mst_port *port;
> - struct drm_dp_mst_branch *mstb_child;
> +
> if (!mstb->link_address_sent)
> drm_dp_send_link_address(mgr, mstb);
>
> list_for_each_entry(port, >ports, next) {
> - if (port->input)
> - continue;
> + struct drm_dp_mst_branch *mstb_child = NULL;
>
> - if (!port->ddps)
> + if (port->input || !port->ddps)
> continue;
>
> if (!port->available_pbn)
> drm_dp_send_enum_path_resources(mgr, mstb, port);
>
> - if (port->mstb) {
> + if (port->mstb)
> mstb_child = drm_dp_mst_topology_get_mstb_validated(
> mgr, port->mstb);
> - if (mstb_child) {
> - drm_dp_check_and_send_link_address(mgr,
> mstb_child);
> - drm_dp_mst_topology_put_mstb(mstb_child);
> - }
> +
> + if (mstb_child) {
> + drm_dp_check_and_send_link_address(mgr, mstb_child);
> + drm_dp_mst_topology_put_mstb(mstb_child);
> }
> }
> }
>
> static void drm_dp_mst_link_probe_work(struct work_struct *work)
> {
> - struct drm_dp_mst_topology_mgr *mgr = container_of(work, struct
> drm_dp_mst_topology_mgr, work);
> + struct drm_dp_mst_topology_mgr *mgr =
> + container_of(work, struct drm_dp_mst_topology_mgr, work);
> + struct drm_device *dev = mgr->dev;
> struct drm_dp_mst_branch *mstb;
> int ret;
>
> + mutex_lock(>probe_lock);
> +
> mutex_lock(>lock);
> mstb = mgr->mst_primary;
> if (mstb) {
> @@ -2190,6 +2193,7 @@ static void drm_dp_mst_link_probe_work(struct
>
Re: [PATCH v13 0/5] DMA-BUF Heaps (destaging ION)
On 10/22/19 3:21 AM, Neil Armstrong wrote: > Hi John, > > On 21/10/2019 21:03, John Stultz wrote: >> Lucky number 13! :) >> >> Last week in v12 I had re-added some symbol exports to support >> later patches I have pending to enable loading heaps from >> modules. He reminded me that back around v3 (its been awhile!) I >> had removed those exports due to concerns about the fact that we >> don't support module removal. >> >> So I'm respinning the patches, removing the exports again. I'll >> submit a patch to re-add them in a later series enabling moduels >> which can be reviewed indepently. >> >> With that done, lets get on to the boilerplate! >> >> The patchset implements per-heap devices which can be opened >> directly and then an ioctl is used to allocate a dmabuf from the >> heap. >> >> The interface is similar, but much simpler then IONs, only >> providing an ALLOC ioctl. >> >> Also, I've provided relatively simple system and cma heaps. >> >> I've booted and tested these patches with AOSP on the HiKey960 >> using the kernel tree here: >> >> https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > Do you have a 4.19 tree with the changes ? I tried but the xarray idr > replacement > is missing... so I can't test with our android-amlogic-bmeson-4.19 tree. > Just a note, we switched to xarray around v4 time frame of this series, so you may be able to find the IDR based code and plug it in for a 4.19 port. Andrew > If you can provide, I'll be happy to test the serie and the gralloc changes. > > Neil > >> >> And the userspace changes here: >> https://android-review.googlesource.com/c/device/linaro/hikey/+/909436 >> >> Compared to ION, this patchset is missing the system-contig, >> carveout and chunk heaps, as I don't have a device that uses >> those, so I'm unable to do much useful validation there. >> Additionally we have no upstream users of chunk or carveout, >> and the system-contig has been deprecated in the common/andoid-* >> kernels, so this should be ok. >> >> I've also removed the stats accounting, since any such >> accounting should be implemented by dma-buf core or the heaps >> themselves. >> >> New in v13: >> * Re-remove symbol exports, per discussion with Brian. I'll >> resubmit these separately in a later patch so they can be >> independently reviewed >> >> thanks >> -john >> >> Cc: Laura Abbott >> Cc: Benjamin Gaignard >> Cc: Sumit Semwal >> Cc: Liam Mark >> Cc: Pratik Patel >> Cc: Brian Starkey >> Cc: Vincent Donnefort >> Cc: Sudipto Paul >> Cc: Andrew F. Davis >> Cc: Christoph Hellwig >> Cc: Chenbo Feng >> Cc: Alistair Strachan >> Cc: Hridya Valsaraju >> Cc: Hillf Danton >> Cc: dri-devel@lists.freedesktop.org >> >> >> >> Andrew F. Davis (1): >> dma-buf: Add dma-buf heaps framework >> >> John Stultz (4): >> dma-buf: heaps: Add heap helpers >> dma-buf: heaps: Add system heap to dmabuf heaps >> dma-buf: heaps: Add CMA heap to dmabuf heaps >> kselftests: Add dma-heap test >> >> MAINTAINERS | 18 ++ >> drivers/dma-buf/Kconfig | 11 + >> drivers/dma-buf/Makefile | 2 + >> drivers/dma-buf/dma-heap.c| 269 ++ >> drivers/dma-buf/heaps/Kconfig | 14 + >> drivers/dma-buf/heaps/Makefile| 4 + >> drivers/dma-buf/heaps/cma_heap.c | 178 >> drivers/dma-buf/heaps/heap-helpers.c | 268 + >> drivers/dma-buf/heaps/heap-helpers.h | 55 >> drivers/dma-buf/heaps/system_heap.c | 124 >> include/linux/dma-heap.h | 59 >> include/uapi/linux/dma-heap.h | 55 >> tools/testing/selftests/dmabuf-heaps/Makefile | 9 + >> .../selftests/dmabuf-heaps/dmabuf-heap.c | 238 >> 14 files changed, 1304 insertions(+) >> create mode 100644 drivers/dma-buf/dma-heap.c >> create mode 100644 drivers/dma-buf/heaps/Kconfig >> create mode 100644 drivers/dma-buf/heaps/Makefile >> create mode 100644 drivers/dma-buf/heaps/cma_heap.c >> create mode 100644 drivers/dma-buf/heaps/heap-helpers.c >> create mode 100644 drivers/dma-buf/heaps/heap-helpers.h >> create mode 100644 drivers/dma-buf/heaps/system_heap.c >> create mode 100644 include/linux/dma-heap.h >> create mode 100644 include/uapi/linux/dma-heap.h >> create mode 100644 tools/testing/selftests/dmabuf-heaps/Makefile >> create mode 100644 tools/testing/selftests/dmabuf-heaps/dmabuf-heap.c >> > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #122 from Marko Popovic --- (In reply to bugs from comment #121) > I have the same problem using archlinux. I tried mesa+llvm stable > (19.2/9.0), the git-versions with amdgpu and even with plain modesetting. I > have random freezes with xfce (with and without compositor) and nearly > immediatly freezes with Rise of the Tomb Raider. "Freezing" means X11, Magic > SysRQ and SSH still works. > I had to remove the card because the computer was competely unusable with 4 > freezes in 15 minutes. So I can't provide you with more information, sorry. > But if I can give you any information without putting the card back into the > computer (the slot has suffered a bit...) I am here. > > Now I found this bug report and wonder, why it is 8 weeks old, still "new" > and unassigned and severity is not set. In my opinion a freezing computer is > really critical! I kinda wonder that myself. I set it to critical and AMD dev removed the tag critical so they apparently disagree that not being able to use your hardware is a critical bug (thinking). + Bug is present on all systems running LVVM9 and MESA 19.2+... Ubuntu too. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v13 0/5] DMA-BUF Heaps (destaging ION)
On Tue, Oct 22, 2019 at 1:21 AM Neil Armstrong wrote: > > Hi John, > > On 21/10/2019 21:03, John Stultz wrote: > > Lucky number 13! :) > > > > Last week in v12 I had re-added some symbol exports to support > > later patches I have pending to enable loading heaps from > > modules. He reminded me that back around v3 (its been awhile!) I > > had removed those exports due to concerns about the fact that we > > don't support module removal. > > > > So I'm respinning the patches, removing the exports again. I'll > > submit a patch to re-add them in a later series enabling moduels > > which can be reviewed indepently. > > > > With that done, lets get on to the boilerplate! > > > > The patchset implements per-heap devices which can be opened > > directly and then an ioctl is used to allocate a dmabuf from the > > heap. > > > > The interface is similar, but much simpler then IONs, only > > providing an ALLOC ioctl. > > > > Also, I've provided relatively simple system and cma heaps. > > > > I've booted and tested these patches with AOSP on the HiKey960 > > using the kernel tree here: > > > > https://git.linaro.org/people/john.stultz/android-dev.git/log/?h=dev/dma-buf-heap > > Do you have a 4.19 tree with the changes ? I tried but the xarray idr > replacement > is missing... so I can't test with our android-amlogic-bmeson-4.19 tree. > > If you can provide, I'll be happy to test the serie and the gralloc changes. Unfortunately I don't have a 4.19 version of dmabuf heaps (all the work has been done this year, post 4.19). I'm planning to backport to 5.4 for AOSP, but I've not really thought about 4.19. Most likely I won't have time to look at it until after the changes are upstream and the 5.4 backport is done. Is the bmeson tree likely to only stay at 4.19? Or will it move forward? thanks -john ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/simple-kms: Standardize arguments for callbacks
Passing the wrong type feels icky, everywhere else we use the pipe as
the first parameter. Spotted while discussing patches with Thomas
Zimmermann.
Cc: Thomas Zimmermann
Cc: Noralf Trønnes
Cc: Gerd Hoffmann
Cc: Eric Anholt
Cc: Emil Velikov
Cc: virtualizat...@lists.linux-foundation.org
Cc: Linus Walleij
Signed-off-by: Daniel Vetter
---
drivers/gpu/drm/cirrus/cirrus.c | 2 +-
drivers/gpu/drm/drm_simple_kms_helper.c | 2 +-
drivers/gpu/drm/pl111/pl111_display.c | 4 ++--
include/drm/drm_simple_kms_helper.h | 2 +-
4 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
index 7d08d067e1a4..248c9f765c45 100644
--- a/drivers/gpu/drm/cirrus/cirrus.c
+++ b/drivers/gpu/drm/cirrus/cirrus.c
@@ -390,7 +390,7 @@ static int cirrus_conn_init(struct cirrus_device *cirrus)
/* -- */
/* cirrus (simple) display pipe */
-static enum drm_mode_status cirrus_pipe_mode_valid(struct drm_crtc *crtc,
+static enum drm_mode_status cirrus_pipe_mode_valid(struct
drm_simple_display_pipe *pipe,
const struct
drm_display_mode *mode)
{
if (cirrus_check_size(mode->hdisplay, mode->vdisplay, NULL) < 0)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 046055719245..15fb516ae2d8 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -43,7 +43,7 @@ drm_simple_kms_crtc_mode_valid(struct drm_crtc *crtc,
/* Anything goes */
return MODE_OK;
- return pipe->funcs->mode_valid(crtc, mode);
+ return pipe->funcs->mode_valid(pipe, mode);
}
static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 024771a4083e..703ddc803c55 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -48,10 +48,10 @@ irqreturn_t pl111_irq(int irq, void *data)
}
static enum drm_mode_status
-pl111_mode_valid(struct drm_crtc *crtc,
+pl111_mode_valid(struct drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode)
{
- struct drm_device *drm = crtc->dev;
+ struct drm_device *drm = pipe->crtc.dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
u32 cpp = priv->variant->fb_bpp / 8;
u64 bw;
diff --git a/include/drm/drm_simple_kms_helper.h
b/include/drm/drm_simple_kms_helper.h
index 4d89cd0a60db..15afee9cf049 100644
--- a/include/drm/drm_simple_kms_helper.h
+++ b/include/drm/drm_simple_kms_helper.h
@@ -49,7 +49,7 @@ struct drm_simple_display_pipe_funcs {
*
* drm_mode_status Enum
*/
- enum drm_mode_status (*mode_valid)(struct drm_crtc *crtc,
+ enum drm_mode_status (*mode_valid)(struct drm_simple_display_pipe *pipe,
const struct drm_display_mode *mode);
/**
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/scdc: Fix typo in bit definition of SCDC_STATUS_FLAGS
On Tue, Oct 22, 2019 at 11:51 AM Jani Nikula
wrote:
>
> On Tue, 22 Oct 2019, Thierry Reding wrote:
> > On Tue, Oct 22, 2019 at 11:16:51AM +0300, Jani Nikula wrote:
> >> On Wed, 16 Oct 2019, Patrik Jakobsson wrote:
> >> > Fix typo where bits got compared (x < y) instead of shifted (x << y).
> >>
> >> Fixes: 3ad33ae2bc80 ("drm: Add SCDC helpers")
> >> Cc: Thierry Reding
> >
> > I'm not sure we really need the Fixes: tag here. These defines aren't
> > used anywhere, so technically there's no bug.
>
> Yeah well, I just logged it here as I happened to do the drive-by git
> blame.
I think we can skip the fixes tag here. Thanks for review!
Did anyone apply this or can I take it through drm-misc-next?
-Patrik
>
> BR,
> Jani.
>
>
>
> >
> > Thierry
> >
> >>
> >> > Signed-off-by: Patrik Jakobsson
> >> > ---
> >> > include/drm/drm_scdc_helper.h | 6 +++---
> >> > 1 file changed, 3 insertions(+), 3 deletions(-)
> >> >
> >> > diff --git a/include/drm/drm_scdc_helper.h
> >> > b/include/drm/drm_scdc_helper.h
> >> > index f92eb2094d6b..6a483533aae4 100644
> >> > --- a/include/drm/drm_scdc_helper.h
> >> > +++ b/include/drm/drm_scdc_helper.h
> >> > @@ -50,9 +50,9 @@
> >> > #define SCDC_READ_REQUEST_ENABLE (1 << 0)
> >> >
> >> > #define SCDC_STATUS_FLAGS_0 0x40
> >> > -#define SCDC_CH2_LOCK (1 < 3)
> >> > -#define SCDC_CH1_LOCK (1 < 2)
> >> > -#define SCDC_CH0_LOCK (1 < 1)
> >> > +#define SCDC_CH2_LOCK (1 << 3)
> >> > +#define SCDC_CH1_LOCK (1 << 2)
> >> > +#define SCDC_CH0_LOCK (1 << 1)
> >> > #define SCDC_CH_LOCK_MASK (SCDC_CH2_LOCK | SCDC_CH1_LOCK |
> >> > SCDC_CH0_LOCK)
> >> > #define SCDC_CLOCK_DETECT (1 << 0)
> >>
> >> --
> >> Jani Nikula, Intel Open Source Graphics Center
> >> ___
> >> dri-devel mailing list
> >> dri-devel@lists.freedesktop.org
> >> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> --
> Jani Nikula, Intel Open Source Graphics Center
UDL device cannot get its own screen
Hi, I have the below configuration for an Intel based POS system that, while advertises 3 outputs (DP1, VGA1 and HDMI1 with xf86-video-intel), only two are usable. DP1 for the built-in touchscreen and VGA1 for the external VGA connector. I wanted to use an USB DisplayLink device as the 3rd output, with all three output using its own Screen number, i.e. :0.0 :0.1 and :0.2. The first observation is that I can't seem to be able to use the Intel DDX driver in conjunction with the modesetting DDX that the UDL device uses. The symptom is that two modesetting outputs are initialized, one for UDL and one for the disconnected HDMI1 Intel output. At least now the X server don't crash as with Xorg 1.19.x with a similar attempt. The second is that when the modesetting driver is used, the Intel outputs are renamed from VGA1 to VGA-1 and so on, i.e. the outputs get an extra "-" between the output type and the number so it needed extra typing to port the original config from intel to modesetting. The third observation is that while I am using this configuration below, so the UDL device should be assigned to :0.2 (and active!), it is really assigned to :0[.0] as an inactive output. See that there's no "*" indicator set for any of the supported modes on DVI-I-1-1. How can I set up 3 different Screens correctly for 3 separate fullscreen applications? I am using Xorg 1.20.4 patched with the "autobind GPUs to the screen" patch from Dave Airlie that at least wakes up the UDL device and makes it visible without extra magic with providers/sinks. # DISPLAY=:0 xrandr Screen 0: minimum 320 x 200, current 1024 x 768, maximum 8192 x 8192 DP-1 connected primary 1024x768+0+0 (normal left inverted right x axis y axis) 304mm x 228mm 1024x768 60.00*+ DVI-I-1-1 connected (normal left inverted right x axis y axis) 1024x768 75.03 + 60.00 1920x1080 60.00 + 1680x1050 59.88 1280x1024 75.0260.02 1440x900 74.9859.90 1280x720 60.00 800x600 75.0060.32 640x480 75.0072.8166.6759.94 720x400 70.08 1024x768 (0x4a) 65.000MHz -HSync -VSync h: width 1024 start 1048 end 1184 total 1344 skew0 clock 48.36KHz v: height 768 start 771 end 777 total 806 clock 60.00Hz # cat /etc/X11/xorg.conf.d/videocard.conf Section "Monitor" Identifier "Monitor-DP-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "Monitor-HDMI-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "Monitor-VGA-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Monitor" Identifier "DVI-I-1-1" Option "AutoServerLayout" "on" Option "Rotate" "normal" EndSection Section "Device" Identifier "Intel0" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Screen 0 Option "Monitor-DP1" "DP-1" Option "ZaphodHeads" "DP-1" EndSection Section "Device" Identifier "Intel1" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Screen 1 Option "Monitor-VGA-1" "VGA-1" Option "ZaphodHeads" "VGA-1" EndSection # Intentionally not referenced in ServerLayout below Section "Device" Identifier "Intel2" Driver "modesetting" Option "kmsdev" "/dev/dri/card1" Option "Monitor-HDMI-1" "HDMI-1" Option "ZaphodHeads" "HDMI-1" EndSection Section "Device" Identifier "UDL" Driver "modesetting" Option "kmsdev" "/dev/dri/card0" Screen 2 Option "Monitor-DVI-I-1-1" "DVI-I-1-1" EndSection Section "Screen" Identifier "SCREEN" Option "AutoServerLayout" "on" Device "Intel0" Monitor "Monitor-DP-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "Screen" Identifier "SCREEN1" Option "AutoServerLayout" "on" Device "Intel1" Monitor "Monitor-VGA-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "Screen" Identifier "SCREEN2" Option "AutoServerLayout" "on" Device "UDL" Monitor "Monitor-DVI-I-1-1" SubSection "Display" Modes "1024x768" Depth 24 EndSubSection EndSection Section "ServerLayout" Identifier
[Bug 111481] AMD Navi GPU frequent freezes on both Manjaro/Ubuntu with kernel 5.3 and mesa 19.2 -git/llvm9
https://bugs.freedesktop.org/show_bug.cgi?id=111481 --- Comment #121 from b...@thschuetz.de --- I have the same problem using archlinux. I tried mesa+llvm stable (19.2/9.0), the git-versions with amdgpu and even with plain modesetting. I have random freezes with xfce (with and without compositor) and nearly immediatly freezes with Rise of the Tomb Raider. "Freezing" means X11, Magic SysRQ and SSH still works. I had to remove the card because the computer was competely unusable with 4 freezes in 15 minutes. So I can't provide you with more information, sorry. But if I can give you any information without putting the card back into the computer (the slot has suffered a bit...) I am here. Now I found this bug report and wonder, why it is 8 weeks old, still "new" and unassigned and severity is not set. In my opinion a freezing computer is really critical! And I wonder why the bug is only at Arch/Manjaro and Ubuntu. Are all other distris too old to work with Navi completely? I didn't even found a report from Gentoo. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/simple-kms-helper: Pass plane to prepare_fb() and cleanup_fb()
On Tue, Oct 22, 2019 at 4:41 PM Thomas Zimmermann wrote:
>
> Hi
>
> Am 22.10.19 um 16:14 schrieb Daniel Vetter:
> > On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
> >> Passing the plane structure to prepare_fb() and cleanup_fb() of
> >> struct drm_simple_display_pipe_funcs unifies the interface with
> >> struct drm_plane_helper_funcs. Implementations of these functions
> >> can now be shared between simple-pipeline and 'full-pipeline' drivers.
> >>
> >> Before, the functions received the simple display pipeline's structure
> >> as their first argument. Apparently no implementation needed that argument
> >> and anyone interested can still get it from the plane via container_of().
> >>
> >> As a side effect, drm_gem_fb_simple_display_pipe_prepare_fb() has been
> >> removed.
> >>
> >> Signed-off-by: Thomas Zimmermann
> >
> > Hm
> >
> > I see your point, but having a vfunc which takes the wrong type just feels
> > wrong. Imo I'd just have added a simple pipe wrapper for the vram prepare.
>
> There's already mode_valid(), [1] which uses a similar exception. With
> existing 'prior art,' I didn't see the point of adding additional
> wrappers. Removing an existing wrapper function looked tempting, however. :)
Huh I totally missed that one. I guess that should get bikeshedded,
I'll type a patch.
-Daniel
> > But this should also be fine if we tune it at bit:
> > - Add a note to the kerneldoc explaining why the function signature is
> > "wrong".
> > - Add a drm_simple_display_plane_to_pipe helper for upcasting and
> > reference that one in the above note.
>
> Sure, no problem.
>
> Best regards
> Thomas
>
> [1]
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_simple_kms_helper.h#n52
>
> > With that I think we still have a nice design here. Still leaning
> > towards "just add another helper to plug in".
> >
> > Remaining parts of the series look really nice, but lets settle this
> > question here first.
> > -Daniel
> >
> >> ---
> >> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
> >> drivers/gpu/drm/bochs/bochs_kms.c| 4 ++--
> >> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 22
> >> drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
> >> drivers/gpu/drm/mcde/mcde_display.c | 2 +-
> >> drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
> >> drivers/gpu/drm/pl111/pl111_display.c| 2 +-
> >> drivers/gpu/drm/tiny/hx8357d.c | 2 +-
> >> drivers/gpu/drm/tiny/ili9225.c | 2 +-
> >> drivers/gpu/drm/tiny/ili9341.c | 2 +-
> >> drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
> >> drivers/gpu/drm/tiny/repaper.c | 2 +-
> >> drivers/gpu/drm/tiny/st7586.c| 2 +-
> >> drivers/gpu/drm/tiny/st7735r.c | 2 +-
> >> drivers/gpu/drm/tve200/tve200_display.c | 2 +-
> >> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> >> include/drm/drm_gem_framebuffer_helper.h | 4 +---
> >> include/drm/drm_plane.h | 2 +-
> >> include/drm/drm_simple_kms_helper.h | 6 +++---
> >> 19 files changed, 22 insertions(+), 46 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> >> b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> >> index 2184b8be6fd4..0fe72f46f397 100644
> >> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> >> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> >> @@ -219,7 +219,7 @@ static const struct drm_simple_display_pipe_funcs
> >> aspeed_gfx_funcs = {
> >> .enable = aspeed_gfx_pipe_enable,
> >> .disable= aspeed_gfx_pipe_disable,
> >> .update = aspeed_gfx_pipe_update,
> >> -.prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
> >> +.prepare_fb = drm_gem_fb_prepare_fb,
> >> .enable_vblank = aspeed_gfx_enable_vblank,
> >> .disable_vblank = aspeed_gfx_disable_vblank,
> >> };
> >> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> >> b/drivers/gpu/drm/bochs/bochs_kms.c
> >> index 02a9c1ed165b..0891640491eb 100644
> >> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> >> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> >> @@ -69,7 +69,7 @@ static void bochs_pipe_update(struct
> >> drm_simple_display_pipe *pipe,
> >> }
> >> }
> >>
> >> -static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> >> +static int bochs_pipe_prepare_fb(struct drm_plane *plane,
> >> struct drm_plane_state *new_state)
> >> {
> >> struct drm_gem_vram_object *gbo;
> >> @@ -80,7 +80,7 @@ static int bochs_pipe_prepare_fb(struct
> >> drm_simple_display_pipe *pipe,
> >> return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
> >> }
> >>
> >> -static void bochs_pipe_cleanup_fb(struct drm_simple_display_pipe *pipe,
> >> +static void bochs_pipe_cleanup_fb(struct drm_plane *plane,
> >>struct drm_plane_state *old_state)
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On Tue, Oct 22, 2019 at 02:06:22PM +, Harry Wentland wrote:
>
>
> On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling filter capabilities.
> >> - A userspace to pick a desired effect while scaling.
> >>
> >> This option will be particularly useful in the scenarios where
> >> Integer mode scaling is possible, and a UI client wants to pick
> >> filters like Nearest-neighbor applied for non-blurry outputs.
> >>
> >> There was a RFC patch series published, to discus the request to enable
> >> Integer mode scaling by some of the gaming communities, which can be
> >> found here:
> >> https://patchwork.freedesktop.org/series/66175/
> >>
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4
> >> include/drm/drm_crtc.h| 26 ++
> >> include/drm/drm_mode_config.h | 6 ++
> >> 3 files changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 0d466d3b0809..883329453a86 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct
> >> drm_crtc *crtc,
> >>return ret;
> >>} else if (property == config->prop_vrr_enabled) {
> >>state->vrr_enabled = val;
> >> + } else if (property == config->scaling_filter_property) {
> >> + state->scaling_filter = val;
> >>} else if (property == config->degamma_lut_property) {
> >>ret = drm_atomic_replace_property_blob_from_id(dev,
> >>>degamma_lut,
> >> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> >>*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> >>else if (property == config->prop_out_fence_ptr)
> >>*val = 0;
> >> + else if (property == config->scaling_filter_property)
> >> + *val = state->scaling_filter;
> >>else if (crtc->funcs->atomic_get_property)
> >>return crtc->funcs->atomic_get_property(crtc, state, property,
> >> val);
> >>else
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index 5e9b15a0e8c5..94c5509474a8 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -58,6 +58,25 @@ struct device_node;
> >> struct dma_fence;
> >> struct edid;
> >>
> >> +enum drm_scaling_filters {
> >> + DRM_SCALING_FILTER_DEFAULT,
> >> + DRM_SCALING_FILTER_MEDIUM,
> >> + DRM_SCALING_FILTER_BILINEAR,
> >> + DRM_SCALING_FILTER_NN,
> >
> > Please use real words.
> >
> >> + DRM_SCALING_FILTER_NN_IS_ONLY,
> >
> > Not a big fan of this. I'd just add the explicit nearest filter
> > and leave the decision whether to use it to userspace.
> >
> >> + DRM_SCALING_FILTER_EDGE_ENHANCE,
> >> + DRM_SCALING_FILTER_INVALID,
> >
> > That invalid enum value seems entirely pointless.
> >
> > This set of filters is pretty arbitrary. It doesn't even cover all
> > Intel hw. I would probably just leave it at "default+linear+nearest"
> > initially. Exposing more vague hw specific choices needs more though,
> > and I'd prefer not to spend those brain cells until a real use case
> > emerges.
> >
>
> FWIW, AMD HW allows us to specify a number of horizontal and vertical
> taps for scaling. Number of taps are limited by our linebuffer size. The
> default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
> if your're running a large horizontal resolution on some ASICs.
>
> I'm not sure it makes sense to define filters here that aren't used. It
> sounds like default and nearest neighbour would suffice for now in order
> to support integer scaling.
Yeah, even linear is somewhat questionable since we don't have clear
need for it. Although given that it is well defined it's much less
of a problem than a bunch of the other proposed filters.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On Tue, Oct 22, 2019 at 08:51:20PM +0530, Sharma, Shashank wrote:
>
> On 10/22/2019 5:56 PM, Ville Syrjälä wrote:
> > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> >> This patch adds a scaling filter mode porperty
> >> to allow:
> >> - A driver/HW to showcase it's scaling filter capabilities.
> >> - A userspace to pick a desired effect while scaling.
> >>
> >> This option will be particularly useful in the scenarios where
> >> Integer mode scaling is possible, and a UI client wants to pick
> >> filters like Nearest-neighbor applied for non-blurry outputs.
> >>
> >> There was a RFC patch series published, to discus the request to enable
> >> Integer mode scaling by some of the gaming communities, which can be
> >> found here:
> >> https://patchwork.freedesktop.org/series/66175/
> >>
> >> Signed-off-by: Shashank Sharma
> >> ---
> >> drivers/gpu/drm/drm_atomic_uapi.c | 4
> >> include/drm/drm_crtc.h| 26 ++
> >> include/drm/drm_mode_config.h | 6 ++
> >> 3 files changed, 36 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> >> b/drivers/gpu/drm/drm_atomic_uapi.c
> >> index 0d466d3b0809..883329453a86 100644
> >> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> >> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> >> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct
> >> drm_crtc *crtc,
> >>return ret;
> >>} else if (property == config->prop_vrr_enabled) {
> >>state->vrr_enabled = val;
> >> + } else if (property == config->scaling_filter_property) {
> >> + state->scaling_filter = val;
> >>} else if (property == config->degamma_lut_property) {
> >>ret = drm_atomic_replace_property_blob_from_id(dev,
> >>>degamma_lut,
> >> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> >>*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> >>else if (property == config->prop_out_fence_ptr)
> >>*val = 0;
> >> + else if (property == config->scaling_filter_property)
> >> + *val = state->scaling_filter;
> >>else if (crtc->funcs->atomic_get_property)
> >>return crtc->funcs->atomic_get_property(crtc, state, property,
> >> val);
> >>else
> >> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> >> index 5e9b15a0e8c5..94c5509474a8 100644
> >> --- a/include/drm/drm_crtc.h
> >> +++ b/include/drm/drm_crtc.h
> >> @@ -58,6 +58,25 @@ struct device_node;
> >> struct dma_fence;
> >> struct edid;
> >>
> >> +enum drm_scaling_filters {
> >> + DRM_SCALING_FILTER_DEFAULT,
> >> + DRM_SCALING_FILTER_MEDIUM,
> >> + DRM_SCALING_FILTER_BILINEAR,
> >> + DRM_SCALING_FILTER_NN,
> >> + DRM_SCALING_FILTER_NN_IS_ONLY,
> >> + DRM_SCALING_FILTER_EDGE_ENHANCE,
> >> + DRM_SCALING_FILTER_INVALID,
> >> +};
> >> +
> >> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> >> + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> >> + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> >> + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> >> + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> >> + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> >> + { DRM_SCALING_FILTER_INVALID, "Invalid" },
> >> +};
> >> +
> >> static inline int64_t U642I64(uint64_t val)
> >> {
> >>return (int64_t)*((int64_t *));
> >> @@ -283,6 +302,13 @@ struct drm_crtc_state {
> >> */
> >>u32 target_vblank;
> >>
> >> + /**
> >> + * @scaling_filter:
> >> + *
> >> + * Scaling filter mode to be applied
> >> + */
> >> + u32 scaling_filter;
> >> +
> >>/**
> >> * @async_flip:
> >> *
> >> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> >> index 3bcbe30339f0..efd6fd55770f 100644
> >> --- a/include/drm/drm_mode_config.h
> >> +++ b/include/drm/drm_mode_config.h
> >> @@ -914,6 +914,12 @@ struct drm_mode_config {
> >> */
> >>struct drm_property *modifiers_property;
> >>
> >> + /**
> >> + * @scaling_filter_property: CRTC property to apply a particular filter
> >> + * while scaling in panel fitter mode.
> >> + */
> >> + struct drm_property *scaling_filter_property;
> > This needs to per-crtc/plane.
>
> I am not getting this, why ? It's not different than any other CRTC
> property like gamma/CSC etc, where we just attach them to corresponding
> CRTC, isn't it ?
Different crtcs/planes can have different capabilities, and so not all
of them may want to expose all the possible filters.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
* H. Nikolaus Schaller [191022 15:12]: > Hm. How should that work? Some SoC have the sgx544 as single > core and others as dual core. This imho does not fit into > the "img,sgx544-$revision" scheme which could be matched to. Well don't you have then just two separate child nodes, one for each core with their own register range? That is assuming they're really separate instances.. > But maybe we do it the same as with the timer for the moment, > i.e. keep it in some unpublished patch set. Yeah makes sense to me until things get sorted out. > At the moment I have more problems understanding how the yaml > thing works. I understand and fully support the overall goal, > but it is quite difficult to get a start here. And there do not > seem to be tools or scripts to help converting from old style > text format (even if not perfect, this would be helpful) and > I have no yaml editor that helps keeping the indentation > correct. So this slows down a v2 a little bit. Sounds handy to me :) Regards, Tony
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Harry,
Thanks for your comments, please find mine inline.
On 10/22/2019 7:36 PM, Harry Wentland wrote:
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
Please use real words.
+ DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
That invalid enum value seems entirely pointless.
This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.
FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.
I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.
Agree, this seems to be a consistent feedback from the community, I will
probably start with a smaller set of most popular/used ones.
- Shashank
Harry
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
We have an enum so should use it. The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
[PATCH 2/2] drm/todo: Add levels
Should help new people pick suitable tasks. Cc: Rodrigo Siqueira Cc: Manasi Navare Cc: Sean Paul Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 73 ++ 1 file changed, 73 insertions(+) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 9ac102922712..73c51b5a0997 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -7,6 +7,22 @@ TODO list This section contains a list of smaller janitorial tasks in the kernel DRM graphics subsystem useful as newbie projects. Or for slow rainy days. +Difficulty +-- + +To make it easier task are categorized into different levels: + +Starter: Good tasks to get started with the DRM subsystem. + +Intermediate: Tasks which need some experience with working in the DRM +subsystem, or some specific GPU/display graphics knowledge. For debugging issue +it's good to have the relevant hardware (or a virtual driver set up) available +for testing. + +Advanced: Tricky tasks that need fairly good understanding of the DRM subsystem +and graphics topics. Generally need the relevant hardware for development and +testing. + Subsystem-wide refactorings === @@ -20,6 +36,8 @@ implementations), and then remove it. Contact: Daniel Vetter, respective driver maintainers +Level: Intermediate + Convert existing KMS drivers to atomic modesetting -- @@ -38,6 +56,8 @@ do by directly using the new atomic helper driver callbacks. Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Clean up the clipped coordination confusion around planes - @@ -50,6 +70,8 @@ helpers. Contact: Ville Syrjälä, Daniel Vetter, driver maintainers +Level: Advanced + Convert early atomic drivers to async commit helpers @@ -63,6 +85,8 @@ events for atomic commits correctly. But fixing these bugs is good anyway. Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Fallout from atomic KMS --- @@ -91,6 +115,8 @@ interfaces to fix these issues: Contact: Daniel Vetter +Level: Intermediate + Get rid of dev->struct_mutex from GEM drivers - @@ -114,6 +140,8 @@ fine-grained per-buffer object and per-context lockings scheme. Currently only t Contact: Daniel Vetter, respective driver maintainers +Level: Advanced + Convert instances of dev_info/dev_err/dev_warn to their DRM_DEV_* equivalent @@ -129,6 +157,8 @@ are better. Contact: Sean Paul, Maintainer of the driver you plan to convert +Level: Starter + Convert drivers to use simple modeset suspend/resume @@ -139,6 +169,8 @@ of the atomic suspend/resume code in older atomic modeset drivers. Contact: Maintainer of the driver you plan to convert +Level: Intermediate + Convert drivers to use drm_fb_helper_fbdev_setup/teardown() --- @@ -157,6 +189,8 @@ probably use drm_fb_helper_fbdev_teardown(). Contact: Maintainer of the driver you plan to convert +Level: Intermediate + Clean up mmap forwarding @@ -166,6 +200,8 @@ There's drm_gem_prime_mmap() for this now, but still needs to be rolled out. Contact: Daniel Vetter +Level: Intermediate + Generic fbdev defio support --- @@ -196,6 +232,8 @@ Might be good to also have some igt testcases for this. Contact: Daniel Vetter, Noralf Tronnes +Level: Advanced + idr_init_base() --- @@ -206,6 +244,8 @@ efficient. Contact: Daniel Vetter +Level: Starter + struct drm_gem_object_funcs --- @@ -216,6 +256,8 @@ We also need a 2nd version of the CMA define that doesn't require the vmapping to be present (different hook for prime importing). Plus this needs to be rolled out to all drivers using their own implementations, too. +Level: Intermediate + Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate - @@ -231,6 +273,8 @@ As a reference, take a look at the conversions already completed in drm core. Contact: Sean Paul, respective driver maintainers +Level: Starter + Rename CMA helpers to DMA helpers - @@ -241,6 +285,9 @@ no one knows what that means) since underneath they just use dma_alloc_coherent. Contact: Laurent Pinchart, Daniel Vetter +Level: Intermediate (mostly because it is a huge tasks without good partial +milestones, not technically itself that challenging) + Convert direct mode.vrefresh accesses to use drm_mode_vrefresh()
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Mihail,
Thanks for your review, my comments inline.
On 10/22/2019 6:56 PM, Mihail Atanassov wrote:
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
+ DRM_SCALING_FILTER_NN_IS_ONLY,
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
This one looks to be missing a stringified version below.
Oh yes, it did. Thanks for pointing this out.
Just wanted
to jump in early and suggest dropping it from the scaling filter enum.
Edge enhancement is orthogonal to the mode used for scaling, at least
on komeda HW, so we wouldn't be able to make the best use of the
property in its current form.
Yes, Ville also suggested similar, I guess we can start with the smaller
set.
+ DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+ * @scaling_filter:
+ *
+ * Scaling filter mode to be applied
+ */
+ u32 scaling_filter;
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
*/
struct drm_property *modifiers_property;
+ /**
+ * @scaling_filter_property: CRTC property to apply a particular filter
A scaling filter option can also be useful for scaling individual
planes, do you have any plans to extend the property's applications
in that direction?
Yes, the second stage of development should contain the plane level
filtering too, but as you know, that would be a complex thing to handle,
as planes apply filter pre-blending. We need to discus that (in a
parallel thread :)) how should that look like.
- Shashank
+ * while scaling in panel fitter mode.
+ */
+ struct drm_property *scaling_filter_property;
+
/* cursor size */
uint32_t cursor_width, cursor_height;
--
Mihail
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended
[PATCH 1/2] drm/todo: Remove i915 device_link task
Done with commit aef9f33b7658a7489f71df5d6e6ecb47f2521e8a Author: Imre Deak Date: Tue Oct 23 17:43:10 2018 +0300 drm/i915: Ensure proper HDA suspend/resume ordering with a device link Cc: Imre Deak Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 7 --- 1 file changed, 7 deletions(-) diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst index 23b3a67794ba..9ac102922712 100644 --- a/Documentation/gpu/todo.rst +++ b/Documentation/gpu/todo.rst @@ -438,13 +438,6 @@ See drivers/gpu/drm/amd/display/TODO for tasks. Contact: Harry Wentland, Alex Deucher -i915 - - -- Our early/late pm callbacks could be removed in favour of using - device_link_add to model the dependency between i915 and snd_had. See - https://dri.freedesktop.org/docs/drm/driver-api/device_link.html - Bootsplash == -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On 10/22/2019 5:56 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
+ DRM_SCALING_FILTER_NN_IS_ONLY,
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -914,6 +914,12 @@ struct drm_mode_config {
*/
struct drm_property *modifiers_property;
+ /**
+* @scaling_filter_property: CRTC property to apply a particular filter
+* while scaling in panel fitter mode.
+*/
+ struct drm_property *scaling_filter_property;
This needs to per-crtc/plane.
I am not getting this, why ? It's not different than any other CRTC
property like gamma/CSC etc, where we just attach them to corresponding
CRTC, isn't it ?
- Shashank
+
/* cursor size */
uint32_t cursor_width, cursor_height;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
Hello Ville,
Thanks for the comments, mine inline.
On 10/22/2019 5:50 PM, Ville Syrjälä wrote:
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
This patch adds a scaling filter mode porperty
to allow:
- A driver/HW to showcase it's scaling filter capabilities.
- A userspace to pick a desired effect while scaling.
This option will be particularly useful in the scenarios where
Integer mode scaling is possible, and a UI client wants to pick
filters like Nearest-neighbor applied for non-blurry outputs.
There was a RFC patch series published, to discus the request to enable
Integer mode scaling by some of the gaming communities, which can be
found here:
https://patchwork.freedesktop.org/series/66175/
Signed-off-by: Shashank Sharma
---
drivers/gpu/drm/drm_atomic_uapi.c | 4
include/drm/drm_crtc.h| 26 ++
include/drm/drm_mode_config.h | 6 ++
3 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 0d466d3b0809..883329453a86 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return ret;
} else if (property == config->prop_vrr_enabled) {
state->vrr_enabled = val;
+ } else if (property == config->scaling_filter_property) {
+ state->scaling_filter = val;
} else if (property == config->degamma_lut_property) {
ret = drm_atomic_replace_property_blob_from_id(dev,
>degamma_lut,
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->scaling_filter_property)
+ *val = state->scaling_filter;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 5e9b15a0e8c5..94c5509474a8 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -58,6 +58,25 @@ struct device_node;
struct dma_fence;
struct edid;
+enum drm_scaling_filters {
+ DRM_SCALING_FILTER_DEFAULT,
+ DRM_SCALING_FILTER_MEDIUM,
+ DRM_SCALING_FILTER_BILINEAR,
+ DRM_SCALING_FILTER_NN,
Please use real words.
Yes, I saw that coming. It was getting difficult with the 80 char stuff,
it was even more difficult while using it :). But let me see how better
can I do here.
+ DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
Agree, that's also one option. I was thinking to make it convenient for
userspace, For example if a compositor just want to checkout NN only
when its beneficial (like old gaming scenarios) but doesn't have enough
information (or intent), it can leave it to kernel too. But I agree,
this can cause corner cases. Let's discuss and see if we need it at all,
as you mentioned.
+ DRM_SCALING_FILTER_EDGE_ENHANCE,
+ DRM_SCALING_FILTER_INVALID,
That invalid enum value seems entirely pointless.
I was thinking about loops and all, but yeah, we can remove it.
This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.
Sure, lets start with smaller set.
+};
+
+static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
+ { DRM_SCALING_FILTER_DEFAULT, "Default" },
+ { DRM_SCALING_FILTER_MEDIUM, "Medium" },
+ { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
+ { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
+ { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
+ { DRM_SCALING_FILTER_INVALID, "Invalid" },
+};
+
static inline int64_t U642I64(uint64_t val)
{
return (int64_t)*((int64_t *));
@@ -283,6 +302,13 @@ struct drm_crtc_state {
*/
u32 target_vblank;
+ /**
+* @scaling_filter:
+*
+* Scaling filter mode to be applied
+*/
+ u32 scaling_filter;
We have an enum so should use it.
Got it.
The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
The comment is actually with the property, Here I think its clear that
it's for CRTC scaling, as its a part of CRTC state.
+
/**
* @async_flip:
*
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 3bcbe30339f0..efd6fd55770f 100644
---
Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
Hi Tony, > Am 22.10.2019 um 17:02 schrieb Tony Lindgren : > > * H. Nikolaus Schaller [191021 18:08]: >> >>> Am 21.10.2019 um 19:25 schrieb Tony Lindgren : >>> >>> * H. Nikolaus Schaller [191021 15:46]: > Am 21.10.2019 um 17:07 schrieb Rob Herring : > On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller > wrote: >> +Optional properties: >> +- timer: the timer to be used by the driver. > > Needs a better description and vendor prefix at least. I am not yet sure if it is vendor specific or if all SGX implementations need some timer. > > Why is this needed rather than using the OS's timers? Because nobody understands the current (out of tree and planned for staging) driver well enough what the timer is doing. It is currently hard coded that some omap refer to timer7 and others use timer11. >>> >>> Just configure it in the driver based on the compatible >>> value to keep it out of the dts. It's best to stick to >>> standard bindings. >> >> IMHO leads to ugly code... Since the timer is not part of >> the SGX IPR module but one of the OMAP timers it is sort >> of hardware connection that can be chosen a little arbitrarily. >> >> This is the main reason why I think adding it to a device tree >> source so that a board that really requires to use a timer >> for a different purpose, can reassign it. This is not possible >> if we hard-code that into the driver by scanning for >> compatible. In that case the driver must check board compatible >> names... >> >> But if we gain a better understanding of its role in the driver >> (does it really need a dedicated timer and for what and which >> properties the timer must have) we can probably replace it. > > Well how about just leave out the timer from the binding > for now, and just carry a patch for it until it is known > if/why it's really needed? > > If it's needed, yeah I agree a timer property should be > used. Ok, fine. I'll split the bindings into a patch without and keep a private patch to add this for our development tree. Then we either need it or drop it. > >> +- img,cores: number of cores. Defaults to <1>. > > Not discoverable? Not sure if it is. This is probably available in undocumented registers of the sgx. >>> >>> This too, and whatever non-standrd other properities >>> you might have. >> >> Here it is a feature of the SGX IPR of the SoC, i.e. >> describes that the hardware has one or two cores. > > Here you can have a standard dts binding by putting this > into driver struct of_device_id match .data. Then when > somebody figures out how to read that from the hardware, > it can be just dropped. Hm. How should that work? Some SoC have the sgx544 as single core and others as dual core. This imho does not fit into the "img,sgx544-$revision" scheme which could be matched to. But maybe we do it the same as with the timer for the moment, i.e. keep it in some unpublished patch set. At the moment I have more problems understanding how the yaml thing works. I understand and fully support the overall goal, but it is quite difficult to get a start here. And there do not seem to be tools or scripts to help converting from old style text format (even if not perfect, this would be helpful) and I have no yaml editor that helps keeping the indentation correct. So this slows down a v2 a little bit. BR and thanks, Nikolaus
Re: [PATCH 1/7] dt-bindings: gpu: pvrsgx: add initial bindings
* H. Nikolaus Schaller [191021 18:08]: > > > Am 21.10.2019 um 19:25 schrieb Tony Lindgren : > > > > * H. Nikolaus Schaller [191021 15:46]: > >>> Am 21.10.2019 um 17:07 schrieb Rob Herring : > >>> On Fri, Oct 18, 2019 at 1:46 PM H. Nikolaus Schaller > >>> wrote: > +Optional properties: > +- timer: the timer to be used by the driver. > >>> > >>> Needs a better description and vendor prefix at least. > >> > >> I am not yet sure if it is vendor specific or if all > >> SGX implementations need some timer. > >> > >>> > >>> Why is this needed rather than using the OS's timers? > >> > >> Because nobody understands the current (out of tree and > >> planned for staging) driver well enough what the timer > >> is doing. It is currently hard coded that some omap refer > >> to timer7 and others use timer11. > > > > Just configure it in the driver based on the compatible > > value to keep it out of the dts. It's best to stick to > > standard bindings. > > IMHO leads to ugly code... Since the timer is not part of > the SGX IPR module but one of the OMAP timers it is sort > of hardware connection that can be chosen a little arbitrarily. > > This is the main reason why I think adding it to a device tree > source so that a board that really requires to use a timer > for a different purpose, can reassign it. This is not possible > if we hard-code that into the driver by scanning for > compatible. In that case the driver must check board compatible > names... > > But if we gain a better understanding of its role in the driver > (does it really need a dedicated timer and for what and which > properties the timer must have) we can probably replace it. Well how about just leave out the timer from the binding for now, and just carry a patch for it until it is known if/why it's really needed? If it's needed, yeah I agree a timer property should be used. > +- img,cores: number of cores. Defaults to <1>. > >>> > >>> Not discoverable? > >> > >> Not sure if it is. This is probably available in undocumented > >> registers of the sgx. > > > > This too, and whatever non-standrd other properities > > you might have. > > Here it is a feature of the SGX IPR of the SoC, i.e. > describes that the hardware has one or two cores. Here you can have a standard dts binding by putting this into driver struct of_device_id match .data. Then when somebody figures out how to read that from the hardware, it can be just dropped. Regards, Tony
Re: [PATCH 4/5] drm/dsi: rename MIPI_DCS_SET_PARTIAL_AREA to MIPI_DCS_SET_PARTIAL_ROWS
On 10/22/19 5:09 AM, Jani Nikula wrote: The DCS command has been named SET_PARTIAL_ROWS in the DCS spec since v1.02, for more than a decade. Rename the enumeration to match the spec. Cc: David Lechner Cc: Vandita Kulkarni Signed-off-by: Jani Nikula --- I guess all of my documents are old and say set_partial_area, but I will take your word for it. It could be helpful to leave a comment in the code about the renaming so that if people with old docs search for SET_PARTIAL_AREA, they can still find it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
On Tue, Oct 22, 2019 at 03:42:07PM +0100, Russell King - ARM Linux admin wrote: > On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote: > > On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin > > wrote: > > > I had a patches, which is why I raised the problem with the core: > > > > > > 6961edfee26d bridge hacks using device links > > > > > > but it never went further than an experiment at the time because of the > > > problems in the core. As it was a hack, it never got posted. Seems > > > that kernel tree (for the cubox) is still 5.2 based, so has a lot of > > > patches and might need updating to a more recent base before anything > > > can be tested. > > > > > > For reference, the panel patch: > > > > https://patchwork.kernel.org/patch/10364873/ > > > > And the huge discussion around bridges, that resulted in Rafael > > Wyzocki fixing all the core issues: > > > > https://www.spinics.net/lists/dri-devel/msg201927.html > > > > James, do you want to look into this for bridges? > > I can now confirm that it does work. Something like this - it's based off an older kernel, so may be missing some of the bridge drivers, but should be sufficient for people to test with. 8< From: Russell King Subject: [PATCH] drm/bridge: add support for device links to bridge Bridge devices have been a potential for kernel oops as their lifetime is independent of the DRM device that they are bound to. Hence, if a bridge device is unbound while the parent DRM device is using them, the parent happily continues to use the bridge device, calling the driver and accessing its objects that have been freed. This can cause kernel memory corruption and kernel oops. To control this, use device links to ensure that the parent DRM device is unbound when the bridge device is unbound, and when the bridge device is re-bound, automatically rebind the parent DRM device. Signed-off-by: Russell King --- drivers/gpu/drm/bridge/adv7511/adv7511_drv.c | 1 + drivers/gpu/drm/bridge/analogix-anx78xx.c | 1 + drivers/gpu/drm/bridge/dumb-vga-dac.c | 1 + drivers/gpu/drm/bridge/lvds-encoder.c | 1 + .../bridge/megachips-stdp-ge-b850v3-fw.c | 1 + drivers/gpu/drm/bridge/nxp-ptn3460.c | 1 + drivers/gpu/drm/bridge/panel.c| 1 + drivers/gpu/drm/bridge/parade-ps8622.c| 1 + drivers/gpu/drm/bridge/sii902x.c | 1 + drivers/gpu/drm/bridge/sii9234.c | 1 + drivers/gpu/drm/bridge/sil-sii8620.c | 1 + drivers/gpu/drm/bridge/tc358767.c | 1 + drivers/gpu/drm/bridge/ti-tfp410.c| 1 + drivers/gpu/drm/drm_bridge.c | 48 ++- drivers/gpu/drm/i2c/tda998x_drv.c | 1 + include/drm/drm_bridge.h | 4 ++ 16 files changed, 53 insertions(+), 13 deletions(-) diff --git a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c index f6d2681f6927..6a5906da58ea 100644 --- a/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c +++ b/drivers/gpu/drm/bridge/adv7511/adv7511_drv.c @@ -1217,6 +1217,7 @@ static int adv7511_probe(struct i2c_client *i2c, const struct i2c_device_id *id) goto err_unregister_cec; adv7511->bridge.funcs = _bridge_funcs; + adv7511->bridge.device = dev; adv7511->bridge.of_node = dev->of_node; drm_bridge_add(>bridge); diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c b/drivers/gpu/drm/bridge/analogix-anx78xx.c index 3c7cc5af735c..77ff17c38037 100644 --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c @@ -1323,6 +1323,7 @@ static int anx78xx_i2c_probe(struct i2c_client *client, mutex_init(>lock); + anx78xx->bridge.device = >dev; #if IS_ENABLED(CONFIG_OF) anx78xx->bridge.of_node = client->dev.of_node; #endif diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c b/drivers/gpu/drm/bridge/dumb-vga-dac.c index d32885b906ae..40169920560e 100644 --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c @@ -202,6 +202,7 @@ static int dumb_vga_probe(struct platform_device *pdev) } vga->bridge.funcs = _vga_bridge_funcs; + vga->bridge.device = >dev; vga->bridge.of_node = pdev->dev.of_node; vga->bridge.timings = of_device_get_match_data(>dev); diff --git a/drivers/gpu/drm/bridge/lvds-encoder.c b/drivers/gpu/drm/bridge/lvds-encoder.c index 2ab2c234f26c..5012be35a5fb 100644 --- a/drivers/gpu/drm/bridge/lvds-encoder.c +++ b/drivers/gpu/drm/bridge/lvds-encoder.c @@ -115,6 +115,7 @@ static int lvds_encoder_probe(struct platform_device *pdev) * to look up. */ lvds_encoder->bridge.of_node = dev->of_node; + lvds_encoder->bridge.device = dev; lvds_encoder->bridge.funcs = drm_bridge_add(_encoder->bridge); diff --git a/drivers/gpu/drm/bridge/megachips-stdp-ge-b850v3-fw.c
[PATCH v4] drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers
From: Thierry Reding
During the discussion of patches that enhance the drm_dp_link helpers it
was concluded that these helpers aren't very useful to begin with. Start
pushing the equivalent code into individual drivers to ultimately remove
them.
v4: use bulk DPCD writes if possible (Daniel Vetter)
Signed-off-by: Thierry Reding
---
drivers/gpu/drm/bridge/analogix-anx78xx.c | 56 ---
1 file changed, 39 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
b/drivers/gpu/drm/bridge/analogix-anx78xx.c
index 9ddc1f3cf841..274989f96a91 100644
--- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
+++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
@@ -71,7 +71,6 @@ struct anx78xx {
struct i2c_client *client;
struct edid *edid;
struct drm_connector connector;
- struct drm_dp_link link;
struct anx78xx_platform_data pdata;
struct mutex lock;
@@ -748,7 +747,7 @@ static int anx78xx_init_pdata(struct anx78xx *anx78xx)
static int anx78xx_dp_link_training(struct anx78xx *anx78xx)
{
- u8 dp_bw, value;
+ u8 dp_bw, dpcd[2];
int err;
err = regmap_write(anx78xx->map[I2C_IDX_RX_P0], SP_HDMI_MUTE_CTRL_REG,
@@ -801,18 +800,34 @@ static int anx78xx_dp_link_training(struct anx78xx
*anx78xx)
if (err)
return err;
- /* Check link capabilities */
- err = drm_dp_link_probe(>aux, >link);
- if (err < 0) {
- DRM_ERROR("Failed to probe link capabilities: %d\n", err);
- return err;
- }
+ /*
+* Power up the sink (DP_SET_POWER register is only available on DPCD
+* v1.1 and later).
+*/
+ if (anx78xx->dpcd[DP_DPCD_REV] >= 0x11) {
+ err = drm_dp_dpcd_readb(>aux, DP_SET_POWER, [0]);
+ if (err < 0) {
+ DRM_ERROR("Failed to read DP_SET_POWER register: %d\n",
+ err);
+ return err;
+ }
- /* Power up the sink */
- err = drm_dp_link_power_up(>aux, >link);
- if (err < 0) {
- DRM_ERROR("Failed to power up DisplayPort link: %d\n", err);
- return err;
+ dpcd[0] &= ~DP_SET_POWER_MASK;
+ dpcd[0] |= DP_SET_POWER_D0;
+
+ err = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, dpcd[0]);
+ if (err < 0) {
+ DRM_ERROR("Failed to power up DisplayPort link: %d\n",
+ err);
+ return err;
+ }
+
+ /*
+* According to the DP 1.1 specification, a "Sink Device must
+* exit the power saving state within 1 ms" (Section 2.5.3.1,
+* Table 5-52, "Sink Control Field" (register 0x600).
+*/
+ usleep_range(1000, 2000);
}
/* Possibly enable downspread on the sink */
@@ -851,15 +866,22 @@ static int anx78xx_dp_link_training(struct anx78xx
*anx78xx)
if (err)
return err;
- value = drm_dp_link_rate_to_bw_code(anx78xx->link.rate);
+ dpcd[0] = drm_dp_max_link_rate(anx78xx->dpcd);
+ dpcd[0] = drm_dp_link_rate_to_bw_code(dpcd[0]);
err = regmap_write(anx78xx->map[I2C_IDX_TX_P0],
- SP_DP_MAIN_LINK_BW_SET_REG, value);
+ SP_DP_MAIN_LINK_BW_SET_REG, dpcd[0]);
if (err)
return err;
- err = drm_dp_link_configure(>aux, >link);
+ dpcd[1] = drm_dp_max_lane_count(anx78xx->dpcd);
+
+ if (drm_dp_enhanced_frame_cap(anx78xx->dpcd))
+ dpcd[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
+
+ err = drm_dp_dpcd_write(>aux, DP_LINK_BW_SET, dpcd,
+ sizeof(dpcd));
if (err < 0) {
- DRM_ERROR("Failed to configure DisplayPort link: %d\n", err);
+ DRM_ERROR("Failed to configure link: %d\n", err);
return err;
}
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC,3/3] drm/komeda: Allow non-component drm_bridge only endpoints
On Tue, Oct 22, 2019 at 10:50:42AM +0200, Daniel Vetter wrote: > On Tue, Oct 22, 2019 at 10:48 AM Russell King - ARM Linux admin > wrote: > > I had a patches, which is why I raised the problem with the core: > > > > 6961edfee26d bridge hacks using device links > > > > but it never went further than an experiment at the time because of the > > problems in the core. As it was a hack, it never got posted. Seems > > that kernel tree (for the cubox) is still 5.2 based, so has a lot of > > patches and might need updating to a more recent base before anything > > can be tested. > > > For reference, the panel patch: > > https://patchwork.kernel.org/patch/10364873/ > > And the huge discussion around bridges, that resulted in Rafael > Wyzocki fixing all the core issues: > > https://www.spinics.net/lists/dri-devel/msg201927.html > > James, do you want to look into this for bridges? I can now confirm that it does work. -- RMK's Patch system: https://www.armlinux.org.uk/developer/patches/ FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up According to speedtest.net: 11.9Mbps down 500kbps up
Re: [PATCH 1/5] drm/simple-kms-helper: Pass plane to prepare_fb() and cleanup_fb()
Hi
Am 22.10.19 um 16:14 schrieb Daniel Vetter:
> On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
>> Passing the plane structure to prepare_fb() and cleanup_fb() of
>> struct drm_simple_display_pipe_funcs unifies the interface with
>> struct drm_plane_helper_funcs. Implementations of these functions
>> can now be shared between simple-pipeline and 'full-pipeline' drivers.
>>
>> Before, the functions received the simple display pipeline's structure
>> as their first argument. Apparently no implementation needed that argument
>> and anyone interested can still get it from the plane via container_of().
>>
>> As a side effect, drm_gem_fb_simple_display_pipe_prepare_fb() has been
>> removed.
>>
>> Signed-off-by: Thomas Zimmermann
>
> Hm
>
> I see your point, but having a vfunc which takes the wrong type just feels
> wrong. Imo I'd just have added a simple pipe wrapper for the vram prepare.
There's already mode_valid(), [1] which uses a similar exception. With
existing 'prior art,' I didn't see the point of adding additional
wrappers. Removing an existing wrapper function looked tempting, however. :)
>
> But this should also be fine if we tune it at bit:
> - Add a note to the kerneldoc explaining why the function signature is
> "wrong".
> - Add a drm_simple_display_plane_to_pipe helper for upcasting and
> reference that one in the above note.
Sure, no problem.
Best regards
Thomas
[1]
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm/drm_simple_kms_helper.h#n52
> With that I think we still have a nice design here. Still leaning
> towards "just add another helper to plug in".
>
> Remaining parts of the series look really nice, but lets settle this
> question here first.
> -Daniel
>
>> ---
>> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
>> drivers/gpu/drm/bochs/bochs_kms.c| 4 ++--
>> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 22
>> drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
>> drivers/gpu/drm/mcde/mcde_display.c | 2 +-
>> drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
>> drivers/gpu/drm/pl111/pl111_display.c| 2 +-
>> drivers/gpu/drm/tiny/hx8357d.c | 2 +-
>> drivers/gpu/drm/tiny/ili9225.c | 2 +-
>> drivers/gpu/drm/tiny/ili9341.c | 2 +-
>> drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
>> drivers/gpu/drm/tiny/repaper.c | 2 +-
>> drivers/gpu/drm/tiny/st7586.c| 2 +-
>> drivers/gpu/drm/tiny/st7735r.c | 2 +-
>> drivers/gpu/drm/tve200/tve200_display.c | 2 +-
>> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
>> include/drm/drm_gem_framebuffer_helper.h | 4 +---
>> include/drm/drm_plane.h | 2 +-
>> include/drm/drm_simple_kms_helper.h | 6 +++---
>> 19 files changed, 22 insertions(+), 46 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
>> b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
>> index 2184b8be6fd4..0fe72f46f397 100644
>> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
>> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
>> @@ -219,7 +219,7 @@ static const struct drm_simple_display_pipe_funcs
>> aspeed_gfx_funcs = {
>> .enable = aspeed_gfx_pipe_enable,
>> .disable= aspeed_gfx_pipe_disable,
>> .update = aspeed_gfx_pipe_update,
>> -.prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
>> +.prepare_fb = drm_gem_fb_prepare_fb,
>> .enable_vblank = aspeed_gfx_enable_vblank,
>> .disable_vblank = aspeed_gfx_disable_vblank,
>> };
>> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
>> b/drivers/gpu/drm/bochs/bochs_kms.c
>> index 02a9c1ed165b..0891640491eb 100644
>> --- a/drivers/gpu/drm/bochs/bochs_kms.c
>> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
>> @@ -69,7 +69,7 @@ static void bochs_pipe_update(struct
>> drm_simple_display_pipe *pipe,
>> }
>> }
>>
>> -static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
>> +static int bochs_pipe_prepare_fb(struct drm_plane *plane,
>> struct drm_plane_state *new_state)
>> {
>> struct drm_gem_vram_object *gbo;
>> @@ -80,7 +80,7 @@ static int bochs_pipe_prepare_fb(struct
>> drm_simple_display_pipe *pipe,
>> return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
>> }
>>
>> -static void bochs_pipe_cleanup_fb(struct drm_simple_display_pipe *pipe,
>> +static void bochs_pipe_cleanup_fb(struct drm_plane *plane,
>>struct drm_plane_state *old_state)
>> {
>> struct drm_gem_vram_object *gbo;
>> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
>> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
>> index b9bcd310ca2d..c7ea288bef0a 100644
>> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
>> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
>> @@ -300,25 +300,3 @@ int
RE: [PATCH v2] drm/amdgpu: Add DC feature mask to disable fractional pwm
Reviewed-by: Anthony Koo
-Original Message-
From: sunpeng...@amd.com
Sent: Monday, October 21, 2019 3:44 PM
To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;
lskre...@gmail.com
Cc: Koo, Anthony ; Wentland, Harry
; Li, Sun peng (Leo)
Subject: [PATCH v2] drm/amdgpu: Add DC feature mask to disable fractional pwm
From: Leo Li
[Why]
Some LED panel drivers might not like fractional PWM. In such cases, backlight
flickering may be observed.
[How]
Add a DC feature mask to disable fractional PWM, and associate it with the
preexisting dc_config flag.
The flag is only plumbed through the dmcu firmware, so plumb it through the
driver path as well.
To disable, add the following to the linux cmdline:
amdgpu.dcfeaturemask=0x4
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=204957
Signed-off-by: Leo Li
---
v2: Add bugzilla link
drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 3 +++
drivers/gpu/drm/amd/display/dc/dce/dce_abm.c | 4
drivers/gpu/drm/amd/include/amd_shared.h | 1 +
3 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 1cf4beb76835..73f917d4d1e1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -728,6 +728,9 @@ static int amdgpu_dm_init(struct amdgpu_device *adev)
if (amdgpu_dc_feature_mask & DC_MULTI_MON_PP_MCLK_SWITCH_MASK)
init_data.flags.multi_mon_pp_mclk_switch = true;
+ if (amdgpu_dc_feature_mask & DC_DISABLE_FRACTIONAL_PWM_MASK)
+ init_data.flags.disable_fractional_pwm = true;
+
init_data.flags.power_down_display_on_boot = true;
#ifdef CONFIG_DRM_AMD_DC_DCN2_0
diff --git a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
index d759fdca7fdb..b8a3fc505c9b 100644
--- a/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
+++ b/drivers/gpu/drm/amd/display/dc/dce/dce_abm.c
@@ -404,6 +404,10 @@ static bool dce_abm_init_backlight(struct abm *abm)
/* Enable the backlight output */
REG_UPDATE(BL_PWM_CNTL, BL_PWM_EN, 1);
+ /* Disable fractional pwm if configured */
+ REG_UPDATE(BL_PWM_CNTL, BL_PWM_FRACTIONAL_EN,
+ abm->ctx->dc->config.disable_fractional_pwm ? 0 : 1);
+
/* Unlock group 2 backlight registers */
REG_UPDATE(BL_PWM_GRP1_REG_LOCK,
BL_PWM_GRP1_REG_LOCK, 0);
diff --git a/drivers/gpu/drm/amd/include/amd_shared.h
b/drivers/gpu/drm/amd/include/amd_shared.h
index 8889aaceec60..5450ed762b7a 100644
--- a/drivers/gpu/drm/amd/include/amd_shared.h
+++ b/drivers/gpu/drm/amd/include/amd_shared.h
@@ -143,6 +143,7 @@ enum PP_FEATURE_MASK { enum DC_FEATURE_MASK {
DC_FBC_MASK = 0x1,
DC_MULTI_MON_PP_MCLK_SWITCH_MASK = 0x2,
+ DC_DISABLE_FRACTIONAL_PWM_MASK = 0x4,
};
enum amd_dpm_forced_level;
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/5] drm/simple-kms-helper: Pass plane to prepare_fb() and cleanup_fb()
On Tue, Oct 22, 2019 at 12:25:16PM +0200, Thomas Zimmermann wrote:
> Passing the plane structure to prepare_fb() and cleanup_fb() of
> struct drm_simple_display_pipe_funcs unifies the interface with
> struct drm_plane_helper_funcs. Implementations of these functions
> can now be shared between simple-pipeline and 'full-pipeline' drivers.
>
> Before, the functions received the simple display pipeline's structure
> as their first argument. Apparently no implementation needed that argument
> and anyone interested can still get it from the plane via container_of().
>
> As a side effect, drm_gem_fb_simple_display_pipe_prepare_fb() has been
> removed.
>
> Signed-off-by: Thomas Zimmermann
Hm
I see your point, but having a vfunc which takes the wrong type just feels
wrong. Imo I'd just have added a simple pipe wrapper for the vram prepare.
But this should also be fine if we tune it at bit:
- Add a note to the kerneldoc explaining why the function signature is
"wrong".
- Add a drm_simple_display_plane_to_pipe helper for upcasting and
reference that one in the above note.
With that I think we still have a nice design here. Still leaning
towards "just add another helper to plug in".
Remaining parts of the series look really nice, but lets settle this
question here first.
-Daniel
> ---
> drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
> drivers/gpu/drm/bochs/bochs_kms.c| 4 ++--
> drivers/gpu/drm/drm_gem_framebuffer_helper.c | 22
> drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
> drivers/gpu/drm/mcde/mcde_display.c | 2 +-
> drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
> drivers/gpu/drm/pl111/pl111_display.c| 2 +-
> drivers/gpu/drm/tiny/hx8357d.c | 2 +-
> drivers/gpu/drm/tiny/ili9225.c | 2 +-
> drivers/gpu/drm/tiny/ili9341.c | 2 +-
> drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
> drivers/gpu/drm/tiny/repaper.c | 2 +-
> drivers/gpu/drm/tiny/st7586.c| 2 +-
> drivers/gpu/drm/tiny/st7735r.c | 2 +-
> drivers/gpu/drm/tve200/tve200_display.c | 2 +-
> drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
> include/drm/drm_gem_framebuffer_helper.h | 4 +---
> include/drm/drm_plane.h | 2 +-
> include/drm/drm_simple_kms_helper.h | 6 +++---
> 19 files changed, 22 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> index 2184b8be6fd4..0fe72f46f397 100644
> --- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
> @@ -219,7 +219,7 @@ static const struct drm_simple_display_pipe_funcs
> aspeed_gfx_funcs = {
> .enable = aspeed_gfx_pipe_enable,
> .disable= aspeed_gfx_pipe_disable,
> .update = aspeed_gfx_pipe_update,
> - .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
> + .prepare_fb = drm_gem_fb_prepare_fb,
> .enable_vblank = aspeed_gfx_enable_vblank,
> .disable_vblank = aspeed_gfx_disable_vblank,
> };
> diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
> b/drivers/gpu/drm/bochs/bochs_kms.c
> index 02a9c1ed165b..0891640491eb 100644
> --- a/drivers/gpu/drm/bochs/bochs_kms.c
> +++ b/drivers/gpu/drm/bochs/bochs_kms.c
> @@ -69,7 +69,7 @@ static void bochs_pipe_update(struct
> drm_simple_display_pipe *pipe,
> }
> }
>
> -static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
> +static int bochs_pipe_prepare_fb(struct drm_plane *plane,
>struct drm_plane_state *new_state)
> {
> struct drm_gem_vram_object *gbo;
> @@ -80,7 +80,7 @@ static int bochs_pipe_prepare_fb(struct
> drm_simple_display_pipe *pipe,
> return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
> }
>
> -static void bochs_pipe_cleanup_fb(struct drm_simple_display_pipe *pipe,
> +static void bochs_pipe_cleanup_fb(struct drm_plane *plane,
> struct drm_plane_state *old_state)
> {
> struct drm_gem_vram_object *gbo;
> diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> index b9bcd310ca2d..c7ea288bef0a 100644
> --- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> +++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
> @@ -300,25 +300,3 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
> return 0;
> }
> EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
> -
> -/**
> - * drm_gem_fb_simple_display_pipe_prepare_fb - prepare_fb helper for
> - * _simple_display_pipe
> - * @pipe: Simple display pipe
> - * @plane_state: Plane state
> - *
> - * This function uses drm_gem_fb_prepare_fb() to extract the exclusive fence
> - * from _gem_object.resv and attaches it to plane state for the atomic
> - * helper to wait on. This is necessary to correctly implement implicit
> - *
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On 2019-10-22 8:20 a.m., Ville Syrjälä wrote:
> On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
>> This patch adds a scaling filter mode porperty
>> to allow:
>> - A driver/HW to showcase it's scaling filter capabilities.
>> - A userspace to pick a desired effect while scaling.
>>
>> This option will be particularly useful in the scenarios where
>> Integer mode scaling is possible, and a UI client wants to pick
>> filters like Nearest-neighbor applied for non-blurry outputs.
>>
>> There was a RFC patch series published, to discus the request to enable
>> Integer mode scaling by some of the gaming communities, which can be
>> found here:
>> https://patchwork.freedesktop.org/series/66175/
>>
>> Signed-off-by: Shashank Sharma
>> ---
>> drivers/gpu/drm/drm_atomic_uapi.c | 4
>> include/drm/drm_crtc.h| 26 ++
>> include/drm/drm_mode_config.h | 6 ++
>> 3 files changed, 36 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
>> b/drivers/gpu/drm/drm_atomic_uapi.c
>> index 0d466d3b0809..883329453a86 100644
>> --- a/drivers/gpu/drm/drm_atomic_uapi.c
>> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
>> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
>> *crtc,
>> return ret;
>> } else if (property == config->prop_vrr_enabled) {
>> state->vrr_enabled = val;
>> +} else if (property == config->scaling_filter_property) {
>> +state->scaling_filter = val;
>> } else if (property == config->degamma_lut_property) {
>> ret = drm_atomic_replace_property_blob_from_id(dev,
>> >degamma_lut,
>> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
>> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
>> else if (property == config->prop_out_fence_ptr)
>> *val = 0;
>> +else if (property == config->scaling_filter_property)
>> +*val = state->scaling_filter;
>> else if (crtc->funcs->atomic_get_property)
>> return crtc->funcs->atomic_get_property(crtc, state, property,
>> val);
>> else
>> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
>> index 5e9b15a0e8c5..94c5509474a8 100644
>> --- a/include/drm/drm_crtc.h
>> +++ b/include/drm/drm_crtc.h
>> @@ -58,6 +58,25 @@ struct device_node;
>> struct dma_fence;
>> struct edid;
>>
>> +enum drm_scaling_filters {
>> +DRM_SCALING_FILTER_DEFAULT,
>> +DRM_SCALING_FILTER_MEDIUM,
>> +DRM_SCALING_FILTER_BILINEAR,
>> +DRM_SCALING_FILTER_NN,
>
> Please use real words.
>
>> +DRM_SCALING_FILTER_NN_IS_ONLY,
>
> Not a big fan of this. I'd just add the explicit nearest filter
> and leave the decision whether to use it to userspace.
>
>> +DRM_SCALING_FILTER_EDGE_ENHANCE,
>> +DRM_SCALING_FILTER_INVALID,
>
> That invalid enum value seems entirely pointless.
>
> This set of filters is pretty arbitrary. It doesn't even cover all
> Intel hw. I would probably just leave it at "default+linear+nearest"
> initially. Exposing more vague hw specific choices needs more though,
> and I'd prefer not to spend those brain cells until a real use case
> emerges.
>
FWIW, AMD HW allows us to specify a number of horizontal and vertical
taps for scaling. Number of taps are limited by our linebuffer size. The
default is 4 in each dimension but you could have 2 v_taps and 4 h_taps
if your're running a large horizontal resolution on some ASICs.
I'm not sure it makes sense to define filters here that aren't used. It
sounds like default and nearest neighbour would suffice for now in order
to support integer scaling.
Harry
>> +};
>> +
>> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
>> +{ DRM_SCALING_FILTER_DEFAULT, "Default" },
>> +{ DRM_SCALING_FILTER_MEDIUM, "Medium" },
>> +{ DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
>> +{ DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
>> +{ DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
>> +{ DRM_SCALING_FILTER_INVALID, "Invalid" },
>> +};
>> +
>> static inline int64_t U642I64(uint64_t val)
>> {
>> return (int64_t)*((int64_t *));
>> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>> */
>> u32 target_vblank;
>>
>> +/**
>> + * @scaling_filter:
>> + *
>> + * Scaling filter mode to be applied
>> + */
>> +u32 scaling_filter;
>
> We have an enum so should use it. The documentation should probably
> point out that this applies to full crtc scaling only, not plane
> scaling.
>
>> +
>> /**
>> * @async_flip:
>> *
>> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
>> index 3bcbe30339f0..efd6fd55770f 100644
>> --- a/include/drm/drm_mode_config.h
>> +++ b/include/drm/drm_mode_config.h
>> @@ -914,6 +914,12 @@ struct drm_mode_config {
>> */
>> struct drm_property *modifiers_property;
>>
>> +/**
Re: [PATCH v3 06/13] drm/dp: Do not busy-loop during link training
On Mon, Oct 21, 2019 at 04:34:30PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> Use microsecond sleeps for the clock recovery and channel equalization
> delays during link training. The duration of these delays can be from
> 100 us up to 16 ms. It is rude to busy-loop for that amount of time.
>
> While at it, also convert to standard coding style by putting the
> opening braces in a function definition on a new line. Also switch to
> using an unsigned int for the AUX read interval to match the data type
> of the parameters to usleep_range().
>
> v2: use correct multiplier for training delays (Philipp Zabel)
> v3: clarify data type change in commit message
>
> Signed-off-by: Thierry Reding
After you pointing out on irc that the default value isn't the same and me
having flash-backs ...
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_helper.c | 30 ++
> 1 file changed, 18 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index 8f2d7c4850ca..ac802b04f120 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -120,33 +120,39 @@ u8 drm_dp_get_adjust_request_pre_emphasis(const u8
> link_status[DP_LINK_STATUS_SI
> }
> EXPORT_SYMBOL(drm_dp_get_adjust_request_pre_emphasis);
>
> -void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE]) {
> - int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> +void drm_dp_link_train_clock_recovery_delay(const u8
> dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> + DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> rd_interval);
>
> if (rd_interval == 0 || dpcd[DP_DPCD_REV] >= DP_DPCD_REV_14)
> - udelay(100);
> + rd_interval = 100;
> else
> - mdelay(rd_interval * 4);
> + rd_interval *= 4 * USEC_PER_MSEC;
> +
> + usleep_range(rd_interval, rd_interval * 2);
> }
> EXPORT_SYMBOL(drm_dp_link_train_clock_recovery_delay);
>
> -void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> - int rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> - DP_TRAINING_AUX_RD_MASK;
> +void drm_dp_link_train_channel_eq_delay(const u8 dpcd[DP_RECEIVER_CAP_SIZE])
> +{
> + unsigned long rd_interval = dpcd[DP_TRAINING_AUX_RD_INTERVAL] &
> + DP_TRAINING_AUX_RD_MASK;
>
> if (rd_interval > 4)
> - DRM_DEBUG_KMS("AUX interval %d, out of range (max 4)\n",
> + DRM_DEBUG_KMS("AUX interval %lu, out of range (max 4)\n",
> rd_interval);
>
> if (rd_interval == 0)
> - udelay(400);
> + rd_interval = 400;
> else
> - mdelay(rd_interval * 4);
> + rd_interval *= 4 * USEC_PER_MSEC;
> +
> + usleep_range(rd_interval, rd_interval * 2);
> }
> EXPORT_SYMBOL(drm_dp_link_train_channel_eq_delay);
>
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 13/13] drm/tegra: Move drm_dp_link helpers to Tegra DRM
On Mon, Oct 21, 2019 at 04:34:37PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. After
> all other drivers have been converted not to use these helpers anymore,
> move these helpers into the last remaining user: Tegra DRM.
>
> If at some point these helpers are deemed more widely useful, they can
> be moved out into the DRM DP helpers again.
>
> Signed-off-by: Thierry Reding
I didn't check in detail whether you moved it all without changes :-)
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_dp_helper.c | 128 --
> drivers/gpu/drm/tegra/Makefile | 1 +
> drivers/gpu/drm/tegra/dp.c | 133
> drivers/gpu/drm/tegra/dp.h | 26 +++
> drivers/gpu/drm/tegra/dpaux.c | 1 +
> drivers/gpu/drm/tegra/sor.c | 1 +
> include/drm/drm_dp_helper.h | 16
> 7 files changed, 162 insertions(+), 144 deletions(-)
> create mode 100644 drivers/gpu/drm/tegra/dp.c
> create mode 100644 drivers/gpu/drm/tegra/dp.h
>
> diff --git a/drivers/gpu/drm/drm_dp_helper.c b/drivers/gpu/drm/drm_dp_helper.c
> index f567141aff54..2c7870aef469 100644
> --- a/drivers/gpu/drm/drm_dp_helper.c
> +++ b/drivers/gpu/drm/drm_dp_helper.c
> @@ -351,134 +351,6 @@ int drm_dp_dpcd_read_link_status(struct drm_dp_aux *aux,
> }
> EXPORT_SYMBOL(drm_dp_dpcd_read_link_status);
>
> -/**
> - * drm_dp_link_probe() - probe a DisplayPort link for capabilities
> - * @aux: DisplayPort AUX channel
> - * @link: pointer to structure in which to return link capabilities
> - *
> - * The structure filled in by this function can usually be passed directly
> - * into drm_dp_link_power_up() and drm_dp_link_configure() to power up and
> - * configure the link based on the link's capabilities.
> - *
> - * Returns 0 on success or a negative error code on failure.
> - */
> -int drm_dp_link_probe(struct drm_dp_aux *aux, struct drm_dp_link *link)
> -{
> - u8 values[3];
> - int err;
> -
> - memset(link, 0, sizeof(*link));
> -
> - err = drm_dp_dpcd_read(aux, DP_DPCD_REV, values, sizeof(values));
> - if (err < 0)
> - return err;
> -
> - link->revision = values[0];
> - link->rate = drm_dp_bw_code_to_link_rate(values[1]);
> - link->num_lanes = values[2] & DP_MAX_LANE_COUNT_MASK;
> -
> - if (values[2] & DP_ENHANCED_FRAME_CAP)
> - link->capabilities |= DP_LINK_CAP_ENHANCED_FRAMING;
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(drm_dp_link_probe);
> -
> -/**
> - * drm_dp_link_power_up() - power up a DisplayPort link
> - * @aux: DisplayPort AUX channel
> - * @link: pointer to a structure containing the link configuration
> - *
> - * Returns 0 on success or a negative error code on failure.
> - */
> -int drm_dp_link_power_up(struct drm_dp_aux *aux, struct drm_dp_link *link)
> -{
> - u8 value;
> - int err;
> -
> - /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> - if (link->revision < 0x11)
> - return 0;
> -
> - err = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
> - if (err < 0)
> - return err;
> -
> - value &= ~DP_SET_POWER_MASK;
> - value |= DP_SET_POWER_D0;
> -
> - err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> - if (err < 0)
> - return err;
> -
> - /*
> - * According to the DP 1.1 specification, a "Sink Device must exit the
> - * power saving state within 1 ms" (Section 2.5.3.1, Table 5-52, "Sink
> - * Control Field" (register 0x600).
> - */
> - usleep_range(1000, 2000);
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(drm_dp_link_power_up);
> -
> -/**
> - * drm_dp_link_power_down() - power down a DisplayPort link
> - * @aux: DisplayPort AUX channel
> - * @link: pointer to a structure containing the link configuration
> - *
> - * Returns 0 on success or a negative error code on failure.
> - */
> -int drm_dp_link_power_down(struct drm_dp_aux *aux, struct drm_dp_link *link)
> -{
> - u8 value;
> - int err;
> -
> - /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> - if (link->revision < 0x11)
> - return 0;
> -
> - err = drm_dp_dpcd_readb(aux, DP_SET_POWER, );
> - if (err < 0)
> - return err;
> -
> - value &= ~DP_SET_POWER_MASK;
> - value |= DP_SET_POWER_D3;
> -
> - err = drm_dp_dpcd_writeb(aux, DP_SET_POWER, value);
> - if (err < 0)
> - return err;
> -
> - return 0;
> -}
> -EXPORT_SYMBOL(drm_dp_link_power_down);
> -
> -/**
> - * drm_dp_link_configure() - configure a DisplayPort link
> - * @aux: DisplayPort AUX channel
> - * @link: pointer to a structure containing the link configuration
> - *
> - * Returns 0 on success or a negative error code on failure.
> - */
> -int drm_dp_link_configure(struct drm_dp_aux *aux, struct drm_dp_link *link)
> -{
> - u8
Re: [PATCH v3 12/13] drm/rockchip: Avoid drm_dp_link helpers
On Mon, Oct 21, 2019 at 04:34:36PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to ultimately remove
> them.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/rockchip/cdn-dp-core.c | 12 ++--
> drivers/gpu/drm/rockchip/cdn-dp-core.h | 3 ++-
> drivers/gpu/drm/rockchip/cdn-dp-reg.c | 19 +--
> 3 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> index d505ea7d5384..eed594bd38d3 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.c
> @@ -477,8 +477,8 @@ static int cdn_dp_disable(struct cdn_dp_device *dp)
> cdn_dp_set_firmware_active(dp, false);
> cdn_dp_clk_disable(dp);
> dp->active = false;
> - dp->link.rate = 0;
> - dp->link.num_lanes = 0;
> + dp->max_lanes = 0;
> + dp->max_rate = 0;
> if (!dp->connected) {
> kfree(dp->edid);
> dp->edid = NULL;
> @@ -570,7 +570,7 @@ static bool cdn_dp_check_link_status(struct cdn_dp_device
> *dp)
> struct cdn_dp_port *port = cdn_dp_connected_port(dp);
> u8 sink_lanes = drm_dp_max_lane_count(dp->dpcd);
>
> - if (!port || !dp->link.rate || !dp->link.num_lanes)
> + if (!port || !dp->max_rate || !dp->max_lanes)
> return false;
>
> if (cdn_dp_dpcd_read(dp, DP_LANE0_1_STATUS, link_status,
> @@ -952,8 +952,8 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
>
> /* Enabled and connected with a sink, re-train if requested */
> } else if (!cdn_dp_check_link_status(dp)) {
> - unsigned int rate = dp->link.rate;
> - unsigned int lanes = dp->link.num_lanes;
> + unsigned int rate = dp->max_rate;
> + unsigned int lanes = dp->max_lanes;
> struct drm_display_mode *mode = >mode;
>
> DRM_DEV_INFO(dp->dev, "Connected with sink. Re-train link\n");
> @@ -966,7 +966,7 @@ static void cdn_dp_pd_event_work(struct work_struct *work)
>
> /* If training result is changed, update the video config */
> if (mode->clock &&
> - (rate != dp->link.rate || lanes != dp->link.num_lanes)) {
> + (rate != dp->max_rate || lanes != dp->max_lanes)) {
> ret = cdn_dp_config_video(dp);
> if (ret) {
> dp->connected = false;
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> index b85ea89eb60b..83c4586665b4 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-core.h
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-core.h
> @@ -92,9 +92,10 @@ struct cdn_dp_device {
> struct reset_control *core_rst;
> struct audio_info audio_info;
> struct video_info video_info;
> - struct drm_dp_link link;
> struct cdn_dp_port *port[MAX_PHY];
> u8 ports;
> + u8 max_lanes;
> + u8 max_rate;
> u8 lanes;
> int active_port;
>
> diff --git a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> index 077c87021908..7361c07cb4a7 100644
> --- a/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> +++ b/drivers/gpu/drm/rockchip/cdn-dp-reg.c
> @@ -535,8 +535,8 @@ static int cdn_dp_get_training_status(struct
> cdn_dp_device *dp)
> if (ret)
> goto err_get_training_status;
>
> - dp->link.rate = drm_dp_bw_code_to_link_rate(status[0]);
> - dp->link.num_lanes = status[1];
> + dp->max_rate = drm_dp_bw_code_to_link_rate(status[0]);
> + dp->max_lanes = status[1];
>
> err_get_training_status:
> if (ret)
> @@ -560,8 +560,8 @@ int cdn_dp_train_link(struct cdn_dp_device *dp)
> return ret;
> }
>
> - DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->link.rate,
> - dp->link.num_lanes);
> + DRM_DEV_DEBUG_KMS(dp->dev, "rate:0x%x, lanes:%d\n", dp->max_rate,
> + dp->max_lanes);
> return ret;
> }
>
> @@ -639,7 +639,7 @@ int cdn_dp_config_video(struct cdn_dp_device *dp)
> bit_per_pix = (video->color_fmt == YCBCR_4_2_2) ?
> (video->color_depth * 2) : (video->color_depth * 3);
>
> - link_rate = dp->link.rate / 1000;
> + link_rate = dp->max_rate / 1000;
>
> ret = cdn_dp_reg_write(dp, BND_HSYNC2VSYNC, VIF_BYPASS_INTERLACE);
> if (ret)
> @@ -659,14 +659,13 @@ int cdn_dp_config_video(struct cdn_dp_device *dp)
> do {
> tu_size_reg += 2;
> symbol = tu_size_reg * mode->clock * bit_per_pix;
> - do_div(symbol, dp->link.num_lanes * link_rate * 8);
> + do_div(symbol, dp->max_lanes * link_rate * 8);
>
Re: [PATCH v3 11/13] drm/msm: edp: Avoid drm_dp_link helpers
On Mon, Oct 21, 2019 at 04:34:35PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to ultimately remove
> them.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/msm/edp/edp_ctrl.c | 70 +-
> 1 file changed, 49 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> index 7f3dd3ffe2c9..0d9657cc70db 100644
> --- a/drivers/gpu/drm/msm/edp/edp_ctrl.c
> +++ b/drivers/gpu/drm/msm/edp/edp_ctrl.c
> @@ -89,7 +89,6 @@ struct edp_ctrl {
> /* edid raw data */
> struct edid *edid;
>
> - struct drm_dp_link dp_link;
> struct drm_dp_aux *drm_aux;
>
> /* dpcd raw data */
> @@ -403,7 +402,7 @@ static void edp_fill_link_cfg(struct edp_ctrl *ctrl)
> u32 prate;
> u32 lrate;
> u32 bpp;
> - u8 max_lane = ctrl->dp_link.num_lanes;
> + u8 max_lane = drm_dp_max_lane_count(ctrl->dpcd);
> u8 lane;
>
> prate = ctrl->pixel_rate;
> @@ -413,7 +412,7 @@ static void edp_fill_link_cfg(struct edp_ctrl *ctrl)
>* By default, use the maximum link rate and minimum lane count,
>* so that we can do rate down shift during link training.
>*/
> - ctrl->link_rate = drm_dp_link_rate_to_bw_code(ctrl->dp_link.rate);
> + ctrl->link_rate = ctrl->dpcd[DP_MAX_LINK_RATE];
>
> prate *= bpp;
> prate /= 8; /* in kByte */
> @@ -439,7 +438,7 @@ static void edp_config_ctrl(struct edp_ctrl *ctrl)
>
> data = EDP_CONFIGURATION_CTRL_LANES(ctrl->lane_cnt - 1);
>
> - if (ctrl->dp_link.capabilities & DP_LINK_CAP_ENHANCED_FRAMING)
> + if (drm_dp_enhanced_frame_cap(ctrl->dpcd))
> data |= EDP_CONFIGURATION_CTRL_ENHANCED_FRAMING;
>
> depth = EDP_6BIT;
> @@ -701,7 +700,7 @@ static int edp_link_rate_down_shift(struct edp_ctrl *ctrl)
>
> rate = ctrl->link_rate;
> lane = ctrl->lane_cnt;
> - max_lane = ctrl->dp_link.num_lanes;
> + max_lane = drm_dp_max_lane_count(ctrl->dpcd);
>
> bpp = ctrl->color_depth * 3;
> prate = ctrl->pixel_rate;
> @@ -751,18 +750,22 @@ static int edp_clear_training_pattern(struct edp_ctrl
> *ctrl)
>
> static int edp_do_link_train(struct edp_ctrl *ctrl)
> {
> + u8 values[2];
> int ret;
> - struct drm_dp_link dp_link;
>
> DBG("");
> /*
>* Set the current link rate and lane cnt to panel. They may have been
>* adjusted and the values are different from them in DPCD CAP
>*/
> - dp_link.num_lanes = ctrl->lane_cnt;
> - dp_link.rate = drm_dp_bw_code_to_link_rate(ctrl->link_rate);
> - dp_link.capabilities = ctrl->dp_link.capabilities;
> - if (drm_dp_link_configure(ctrl->drm_aux, _link) < 0)
> + values[0] = ctrl->lane_cnt;
> + values[1] = ctrl->link_rate;
> +
> + if (drm_dp_enhanced_frame_cap(ctrl->dpcd))
> + values[1] |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> +
> + if (drm_dp_dpcd_write(ctrl->drm_aux, DP_LINK_BW_SET, values,
> + sizeof(values)) < 0)
> return EDP_TRAIN_FAIL;
>
> ctrl->v_level = 0; /* start from default level */
> @@ -952,6 +955,7 @@ static void edp_ctrl_on_worker(struct work_struct *work)
> {
> struct edp_ctrl *ctrl = container_of(
> work, struct edp_ctrl, on_work);
> + u8 value;
> int ret;
>
> mutex_lock(>dev_mutex);
> @@ -965,9 +969,27 @@ static void edp_ctrl_on_worker(struct work_struct *work)
> edp_ctrl_link_enable(ctrl, 1);
>
> edp_ctrl_irq_enable(ctrl, 1);
> - ret = drm_dp_link_power_up(ctrl->drm_aux, >dp_link);
> - if (ret)
> - goto fail;
> +
> + /* DP_SET_POWER register is only available on DPCD v1.1 and later */
> + if (ctrl->dpcd[DP_DPCD_REV] >= 0x11) {
> + ret = drm_dp_dpcd_readb(ctrl->drm_aux, DP_SET_POWER, );
> + if (ret < 0)
> + goto fail;
> +
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D0;
> +
> + ret = drm_dp_dpcd_writeb(ctrl->drm_aux, DP_SET_POWER, value);
> + if (ret < 0)
> + goto fail;
> +
> + /*
> + * According to the DP 1.1 specification, a "Sink Device must
> + * exit the power saving state within 1 ms" (Section 2.5.3.1,
> + * Table 5-52, "Sink Control Field" (register 0x600).
> + */
> + usleep_range(1000, 2000);
> + }
>
> ctrl->power_on = true;
>
> @@ -1011,7 +1033,19 @@ static void edp_ctrl_off_worker(struct work_struct
> *work)
>
> edp_state_ctrl(ctrl, 0);
>
> - drm_dp_link_power_down(ctrl->drm_aux, >dp_link);
> + /* DP_SET_POWER register is only
Re: [RESEND][PATCH v8 0/5] DMA-BUF Heaps (destaging ION)
On Mon, Oct 21, 2019 at 09:18:07AM +, Brian Starkey wrote:
> On Sat, Oct 19, 2019 at 09:41:27AM -0400, Andrew F. Davis wrote:
> > On 10/18/19 2:57 PM, Ayan Halder wrote:
> > > On Fri, Oct 18, 2019 at 11:49:22AM -0700, John Stultz wrote:
> > >> On Fri, Oct 18, 2019 at 11:41 AM Ayan Halder wrote:
> > >>> On Fri, Oct 18, 2019 at 09:55:17AM +, Brian Starkey wrote:
> > On Thu, Oct 17, 2019 at 01:57:45PM -0700, John Stultz wrote:
> > > On Thu, Oct 17, 2019 at 12:29 PM Andrew F. Davis wrote:
> > >> On 10/17/19 3:14 PM, John Stultz wrote:
> > >>> But if the objection stands, do you have a proposal for an
> > >>> alternative
> > >>> way to enumerate a subset of CMA heaps?
> > >>>
> > >> When in staging ION had to reach into the CMA framework as the other
> > >> direction would not be allowed, so cma_for_each_area() was added. If
> > >> DMA-BUF heaps is not in staging then we can do the opposite, and have
> > >> the CMA framework register heaps itself using our framework. That way
> > >> the CMA system could decide what areas to export or not (maybe based
> > >> on
> > >> a DT property or similar).
> > >
> > > Ok. Though the CMA core doesn't have much sense of DT details either,
> > > so it would probably have to be done in the reserved_mem logic, which
> > > doesn't feel right to me.
> > >
> > > I'd probably guess we should have some sort of dt binding to describe
> > > a dmabuf cma heap and from that node link to a CMA node via a
> > > memory-region phandle. Along with maybe the default heap as well? Not
> > > eager to get into another binding review cycle, and I'm not sure what
> > > non-DT systems will do yet, but I'll take a shot at it and iterate.
> > >
> > >> The end result is the same so we can make this change later (it has
> > >> to
> > >> come after DMA-BUF heaps is in anyway).
> > >
> > > Well, I'm hesitant to merge code that exposes all the CMA heaps and
> > > then add patches that becomes more selective, should anyone depend on
> > > the initial behavior. :/
> >
> > How about only auto-adding the system default CMA region (cma->name ==
> > "reserved")?
> >
> > And/or the CMA auto-add could be behind a config option? It seems a
> > shame to further delay this, and the CMA heap itself really is useful.
> >
> > >>> A bit of a detour, comming back to the issue why the following node
> > >>> was not getting detected by the dma-buf heaps framework.
> > >>>
> > >>> reserved-memory {
> > >>> #address-cells = <2>;
> > >>> #size-cells = <2>;
> > >>> ranges;
> > >>>
> > >>> display_reserved: framebuffer@6000 {
> > >>> compatible = "shared-dma-pool";
> > >>> linux,cma-default;
> > >>> reusable; ---This was
> > >>> missing in our
> > >>> earlier node
> > >>> reg = <0 0x6000 0 0x0800>;
> > >>> };
> > >>
> > >> Right. It has to be a CMA region for us to expose it from the cma heap.
> > >>
> > >>
> > >>> With 'reusable', rmem_cma_setup() succeeds , but the kernel crashes as
> > >>> follows :-
> > >>>
> > >>> [0.450562] WARNING: CPU: 2 PID: 1 at mm/cma.c:110
> > >>> cma_init_reserved_areas+0xec/0x22c
> > >>
> > >> Is the value 0x6000 you're using something you just guessed at? It
> > >> seems like the warning here is saying the pfn calculated from the base
> > >> address isn't valid.
> > > It is a valid memory region we use to allocate framebuffers.
> >
> >
> > But does it have a valid kernel virtual mapping? Most ARM systems (just
> > assuming you are working on ARM :)) that I'm familiar with have the DRAM
> > space starting at 0x8000 and so don't start having valid pfns until
> > that point. Is this address you are reserving an SRAM?
> >
>
> Yeah, I think you've got it.
>
> This region is DRAM on an FPGA expansion tile, but as you have noticed
> its "below" the start of main RAM, and I expect it's not in any of the
> declared /memory/ nodes.
>
> When "reusable" isn't there, I think we'll end up going the coherent.c
> route, with dma_init_coherent_memory() setting up some pages.
>
> If "reusable" is there, then I think we'll end up in contiguous.c and
> that expects us to already have pages.
>
> So, @Ayan, you could perhaps try adding this region as a /memory/ node
> as-well, which should mean the kernel sets up some pages for it as
> normal memory. But, I have some ancient recollection that the arm64
> kernel couldn't handle system RAM at addresses below 0x8000 or
> something. That might be different now, I'm talking about several
> years ago.
>
Thanks a lot for your suggestions.
I added the following node in the dts.
memory@6000 {
device_type = "memory";
reg =
Re: [PATCH v3 09/13] drm/bridge: tc358767: Avoid drm_dp_link helpers
On Mon, Oct 21, 2019 at 04:34:33PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to ultimately remove
> them.
>
> v3: make link rate unsigned int to avoid overflow
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/bridge/tc358767.c | 63 ---
> 1 file changed, 41 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/tc358767.c
> b/drivers/gpu/drm/bridge/tc358767.c
> index da7e35b0893d..9fe4134425a7 100644
> --- a/drivers/gpu/drm/bridge/tc358767.c
> +++ b/drivers/gpu/drm/bridge/tc358767.c
> @@ -229,7 +229,9 @@ static bool tc_test_pattern;
> module_param_named(test, tc_test_pattern, bool, 0644);
>
> struct tc_edp_link {
> - struct drm_dp_link base;
> + u8 dpcd[DP_RECEIVER_CAP_SIZE];
> + unsigned intrate;
> + u8 num_lanes;
> u8 assr;
> boolscrambler_dis;
> boolspread;
> @@ -438,9 +440,9 @@ static u32 tc_srcctrl(struct tc_data *tc)
> reg |= DP0_SRCCTRL_SCRMBLDIS; /* Scrambler Disabled */
> if (tc->link.spread)
> reg |= DP0_SRCCTRL_SSCG;/* Spread Spectrum Enable */
> - if (tc->link.base.num_lanes == 2)
> + if (tc->link.num_lanes == 2)
> reg |= DP0_SRCCTRL_LANES_2; /* Two Main Channel Lanes */
> - if (tc->link.base.rate != 162000)
> + if (tc->link.rate != 162000)
> reg |= DP0_SRCCTRL_BW27;/* 2.7 Gbps link */
> return reg;
> }
> @@ -663,23 +665,35 @@ static int tc_aux_link_setup(struct tc_data *tc)
>
> static int tc_get_display_props(struct tc_data *tc)
> {
> + u8 revision, num_lanes;
> + unsigned int rate;
> int ret;
> u8 reg;
>
> /* Read DP Rx Link Capability */
> - ret = drm_dp_link_probe(>aux, >link.base);
> + ret = drm_dp_dpcd_read(>aux, DP_DPCD_REV, tc->link.dpcd,
> +DP_RECEIVER_CAP_SIZE);
> if (ret < 0)
> goto err_dpcd_read;
> - if (tc->link.base.rate != 162000 && tc->link.base.rate != 27) {
> +
> + revision = tc->link.dpcd[DP_DPCD_REV];
> + rate = drm_dp_max_link_rate(tc->link.dpcd);
> + num_lanes = drm_dp_max_lane_count(tc->link.dpcd);
> +
> + if (rate != 162000 && rate != 27) {
> dev_dbg(tc->dev, "Falling to 2.7 Gbps rate\n");
> - tc->link.base.rate = 27;
> + rate = 27;
> }
>
> - if (tc->link.base.num_lanes > 2) {
> + tc->link.rate = rate;
> +
> + if (num_lanes > 2) {
> dev_dbg(tc->dev, "Falling to 2 lanes\n");
> - tc->link.base.num_lanes = 2;
> + num_lanes = 2;
> }
>
> + tc->link.num_lanes = num_lanes;
> +
> ret = drm_dp_dpcd_readb(>aux, DP_MAX_DOWNSPREAD, );
> if (ret < 0)
> goto err_dpcd_read;
> @@ -697,10 +711,10 @@ static int tc_get_display_props(struct tc_data *tc)
> tc->link.assr = reg & DP_ALTERNATE_SCRAMBLER_RESET_ENABLE;
>
> dev_dbg(tc->dev, "DPCD rev: %d.%d, rate: %s, lanes: %d, framing: %s\n",
> - tc->link.base.revision >> 4, tc->link.base.revision & 0x0f,
> - (tc->link.base.rate == 162000) ? "1.62Gbps" : "2.7Gbps",
> - tc->link.base.num_lanes,
> - (tc->link.base.capabilities & DP_LINK_CAP_ENHANCED_FRAMING) ?
> + revision >> 4, revision & 0x0f,
> + (tc->link.rate == 162000) ? "1.62Gbps" : "2.7Gbps",
> + tc->link.num_lanes,
> + drm_dp_enhanced_frame_cap(tc->link.dpcd) ?
> "enhanced" : "non-enhanced");
> dev_dbg(tc->dev, "Downspread: %s, scrambler: %s\n",
> tc->link.spread ? "0.5%" : "0.0%",
> @@ -740,7 +754,7 @@ static int tc_set_video_mode(struct tc_data *tc,
>*/
>
> in_bw = mode->clock * bits_per_pixel / 8;
> - out_bw = tc->link.base.num_lanes * tc->link.base.rate;
> + out_bw = tc->link.num_lanes * tc->link.rate;
> max_tu_symbol = DIV_ROUND_UP(in_bw * TU_SIZE_RECOMMENDED, out_bw);
>
> dev_dbg(tc->dev, "set mode %dx%d\n",
> @@ -902,7 +916,7 @@ static int tc_main_link_enable(struct tc_data *tc)
> /* SSCG and BW27 on DP1 must be set to the same as on DP0 */
> ret = regmap_write(tc->regmap, DP1_SRCCTRL,
>(tc->link.spread ? DP0_SRCCTRL_SSCG : 0) |
> - ((tc->link.base.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
> + ((tc->link.rate != 162000) ? DP0_SRCCTRL_BW27 : 0));
> if (ret)
> return ret;
>
> @@ -912,7 +926,7 @@ static int tc_main_link_enable(struct tc_data *tc)
>
> /* Setup Main Link */
> dp_phy_ctrl = BGREN | PWR_SW_EN | PHY_A0_EN | PHY_M0_EN;
>
Re: [PATCH v1] drm/mipi_dbi: Use simple right shift instead of double negation
Den 17.10.2019 18.27, skrev Noralf Trønnes: > > > Den 17.10.2019 13.49, skrev Andy Shevchenko: >> GCC complains about dubious bitwise OR operand: >> >> drivers/gpu/drm/drm_mipi_dbi.c:1024:49: warning: dubious: x | !y >> CC [M] drivers/gpu/drm/drm_mipi_dbi.o >> >> As long as buffer is consist of byte (u8) values, we may use >> simple right shift and satisfy compiler. It also reduces amount of >> operations needed. >> >> Signed-off-by: Andy Shevchenko >> --- > > Thanks, it's even more readable now, for me at least. And since I don't > trust my in-head C compiler/parser, I ran a test and > /sys/kernel/debug/dri/0/command returns the same for commands 04H and > 09h which are the ones affected by this change. > > Reviewed-by: Noralf Trønnes > Tested-by: Noralf Trønnes > Applied to drm-misc-next. Noralf. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On Tuesday, 22 October 2019 14:26:38 BST Mihail Atanassov wrote:
> Hi Shashank,
>
> On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> > This patch adds a scaling filter mode porperty
> > to allow:
> > - A driver/HW to showcase it's scaling filter capabilities.
> > - A userspace to pick a desired effect while scaling.
> >
> > This option will be particularly useful in the scenarios where
> > Integer mode scaling is possible, and a UI client wants to pick
> > filters like Nearest-neighbor applied for non-blurry outputs.
> >
> > There was a RFC patch series published, to discus the request to enable
> > Integer mode scaling by some of the gaming communities, which can be
> > found here:
> > https://patchwork.freedesktop.org/series/66175/
> >
> > Signed-off-by: Shashank Sharma
> > ---
> > drivers/gpu/drm/drm_atomic_uapi.c | 4
> > include/drm/drm_crtc.h| 26 ++
> > include/drm/drm_mode_config.h | 6 ++
> > 3 files changed, 36 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> > b/drivers/gpu/drm/drm_atomic_uapi.c
> > index 0d466d3b0809..883329453a86 100644
> > --- a/drivers/gpu/drm/drm_atomic_uapi.c
> > +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> > @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> > *crtc,
> > return ret;
> > } else if (property == config->prop_vrr_enabled) {
> > state->vrr_enabled = val;
> > + } else if (property == config->scaling_filter_property) {
> > + state->scaling_filter = val;
> > } else if (property == config->degamma_lut_property) {
> > ret = drm_atomic_replace_property_blob_from_id(dev,
> > >degamma_lut,
> > @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> > *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> > else if (property == config->prop_out_fence_ptr)
> > *val = 0;
> > + else if (property == config->scaling_filter_property)
> > + *val = state->scaling_filter;
> > else if (crtc->funcs->atomic_get_property)
> > return crtc->funcs->atomic_get_property(crtc, state,
> > property, val);
> > else
> > diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> > index 5e9b15a0e8c5..94c5509474a8 100644
> > --- a/include/drm/drm_crtc.h
> > +++ b/include/drm/drm_crtc.h
> > @@ -58,6 +58,25 @@ struct device_node;
> > struct dma_fence;
> > struct edid;
> >
> > +enum drm_scaling_filters {
> > + DRM_SCALING_FILTER_DEFAULT,
> > + DRM_SCALING_FILTER_MEDIUM,
> > + DRM_SCALING_FILTER_BILINEAR,
> > + DRM_SCALING_FILTER_NN,
> > + DRM_SCALING_FILTER_NN_IS_ONLY,
> > + DRM_SCALING_FILTER_EDGE_ENHANCE,
>
> This one looks to be missing a stringified version below. Just wanted
> to jump in early and suggest dropping it from the scaling filter enum.
> Edge enhancement is orthogonal to the mode used for scaling, at least
> on komeda HW, so we wouldn't be able to make the best use of the
> property in its current form.
>
> > + DRM_SCALING_FILTER_INVALID,
> > +};
> > +
> > +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> > + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> > + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> > + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> > + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> > + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> > + { DRM_SCALING_FILTER_INVALID, "Invalid" },
> > +};
> > +
> > static inline int64_t U642I64(uint64_t val)
> > {
> > return (int64_t)*((int64_t *));
> > @@ -283,6 +302,13 @@ struct drm_crtc_state {
> >*/
> > u32 target_vblank;
> >
> > + /**
> > + * @scaling_filter:
> > + *
> > + * Scaling filter mode to be applied
> > + */
> > + u32 scaling_filter;
> > +
> > /**
> >* @async_flip:
> >*
> > diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> > index 3bcbe30339f0..efd6fd55770f 100644
> > --- a/include/drm/drm_mode_config.h
> > +++ b/include/drm/drm_mode_config.h
> > @@ -914,6 +914,12 @@ struct drm_mode_config {
> >*/
> > struct drm_property *modifiers_property;
> >
> > + /**
> > + * @scaling_filter_property: CRTC property to apply a particular
> > filter
>
> A scaling filter option can also be useful for scaling individual
> planes, do you have any plans to extend the property's applications
> in that direction?
>
> > + * while scaling in panel fitter mode.
> > + */
> > + struct drm_property *scaling_filter_property;
> > +
> > /* cursor size */
> > uint32_t cursor_width, cursor_height;
> >
> >
>
>
> --
> Mihail
>
>
>
> IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
>
Re: [PATCH v3 08/13] drm/bridge: analogix-anx78xx: Avoid drm_dp_link helpers
On Mon, Oct 21, 2019 at 04:34:32PM +0200, Thierry Reding wrote:
> From: Thierry Reding
>
> During the discussion of patches that enhance the drm_dp_link helpers it
> was concluded that these helpers aren't very useful to begin with. Start
> pushing the equivalent code into individual drivers to ultimately remove
> them.
>
> Signed-off-by: Thierry Reding
> ---
> drivers/gpu/drm/bridge/analogix-anx78xx.c | 57 +--
> 1 file changed, 42 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> index 9ddc1f3cf841..8bb4793f382b 100644
> --- a/drivers/gpu/drm/bridge/analogix-anx78xx.c
> +++ b/drivers/gpu/drm/bridge/analogix-anx78xx.c
> @@ -71,7 +71,6 @@ struct anx78xx {
> struct i2c_client *client;
> struct edid *edid;
> struct drm_connector connector;
> - struct drm_dp_link link;
> struct anx78xx_platform_data pdata;
> struct mutex lock;
>
> @@ -801,18 +800,34 @@ static int anx78xx_dp_link_training(struct anx78xx
> *anx78xx)
> if (err)
> return err;
>
> - /* Check link capabilities */
> - err = drm_dp_link_probe(>aux, >link);
> - if (err < 0) {
> - DRM_ERROR("Failed to probe link capabilities: %d\n", err);
> - return err;
> - }
> + /*
> + * Power up the sink (DP_SET_POWER register is only available on DPCD
> + * v1.1 and later).
> + */
> + if (anx78xx->dpcd[DP_DPCD_REV] >= 0x11) {
> + err = drm_dp_dpcd_readb(>aux, DP_SET_POWER, );
> + if (err < 0) {
> + DRM_ERROR("Failed to read DP_SET_POWER register: %d\n",
> + err);
> + return err;
> + }
>
> - /* Power up the sink */
> - err = drm_dp_link_power_up(>aux, >link);
> - if (err < 0) {
> - DRM_ERROR("Failed to power up DisplayPort link: %d\n", err);
> - return err;
> + value &= ~DP_SET_POWER_MASK;
> + value |= DP_SET_POWER_D0;
> +
> + err = drm_dp_dpcd_writeb(>aux, DP_SET_POWER, value);
> + if (err < 0) {
> + DRM_ERROR("Failed to power up DisplayPort link: %d\n",
> + err);
> + return err;
> + }
> +
> + /*
> + * According to the DP 1.1 specification, a "Sink Device must
> + * exit the power saving state within 1 ms" (Section 2.5.3.1,
> + * Table 5-52, "Sink Control Field" (register 0x600).
> + */
> + usleep_range(1000, 2000);
> }
>
> /* Possibly enable downspread on the sink */
> @@ -851,15 +866,27 @@ static int anx78xx_dp_link_training(struct anx78xx
> *anx78xx)
> if (err)
> return err;
>
> - value = drm_dp_link_rate_to_bw_code(anx78xx->link.rate);
> + value = drm_dp_max_link_rate(anx78xx->dpcd);
> + value = drm_dp_link_rate_to_bw_code(value);
> err = regmap_write(anx78xx->map[I2C_IDX_TX_P0],
> SP_DP_MAIN_LINK_BW_SET_REG, value);
> if (err)
> return err;
>
> - err = drm_dp_link_configure(>aux, >link);
> + err = drm_dp_dpcd_writeb(>aux, DP_LINK_BW_SET, value);
> + if (err < 0) {
> + DRM_ERROR("Failed to set link bandwidth: %d\n", err);
> + return err;
> + }
> +
> + value = drm_dp_max_lane_count(anx78xx->dpcd);
> +
> + if (drm_dp_enhanced_frame_cap(anx78xx->dpcd))
> + value |= DP_LANE_COUNT_ENHANCED_FRAME_EN;
> +
> + err = drm_dp_dpcd_writeb(>aux, DP_LANE_COUNT_SET, value);
> if (err < 0) {
> - DRM_ERROR("Failed to configure DisplayPort link: %d\n", err);
> + DRM_ERROR("Failed to set link lane count: %d\n", err);
> return err;
Splits the last two writes into 2 transactions, otherwise looks
equivalent.
Reviewed-by: Daniel Vetter
> }
>
> --
> 2.23.0
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
Hi Shashank,
On Tuesday, 22 October 2019 10:59:44 BST Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the scenarios where
> Integer mode scaling is possible, and a UI client wants to pick
> filters like Nearest-neighbor applied for non-blurry outputs.
>
> There was a RFC patch series published, to discus the request to enable
> Integer mode scaling by some of the gaming communities, which can be
> found here:
> https://patchwork.freedesktop.org/series/66175/
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> include/drm/drm_crtc.h| 26 ++
> include/drm/drm_mode_config.h | 6 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 0d466d3b0809..883329453a86 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> return ret;
> } else if (property == config->prop_vrr_enabled) {
> state->vrr_enabled = val;
> + } else if (property == config->scaling_filter_property) {
> + state->scaling_filter = val;
> } else if (property == config->degamma_lut_property) {
> ret = drm_atomic_replace_property_blob_from_id(dev,
> >degamma_lut,
> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> else if (property == config->prop_out_fence_ptr)
> *val = 0;
> + else if (property == config->scaling_filter_property)
> + *val = state->scaling_filter;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> else
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5e9b15a0e8c5..94c5509474a8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -58,6 +58,25 @@ struct device_node;
> struct dma_fence;
> struct edid;
>
> +enum drm_scaling_filters {
> + DRM_SCALING_FILTER_DEFAULT,
> + DRM_SCALING_FILTER_MEDIUM,
> + DRM_SCALING_FILTER_BILINEAR,
> + DRM_SCALING_FILTER_NN,
> + DRM_SCALING_FILTER_NN_IS_ONLY,
> + DRM_SCALING_FILTER_EDGE_ENHANCE,
This one looks to be missing a stringified version below. Just wanted
to jump in early and suggest dropping it from the scaling filter enum.
Edge enhancement is orthogonal to the mode used for scaling, at least
on komeda HW, so we wouldn't be able to make the best use of the
property in its current form.
> + DRM_SCALING_FILTER_INVALID,
> +};
> +
> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> + { DRM_SCALING_FILTER_INVALID, "Invalid" },
> +};
> +
> static inline int64_t U642I64(uint64_t val)
> {
> return (int64_t)*((int64_t *));
> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>*/
> u32 target_vblank;
>
> + /**
> + * @scaling_filter:
> + *
> + * Scaling filter mode to be applied
> + */
> + u32 scaling_filter;
> +
> /**
>* @async_flip:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3bcbe30339f0..efd6fd55770f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -914,6 +914,12 @@ struct drm_mode_config {
>*/
> struct drm_property *modifiers_property;
>
> + /**
> + * @scaling_filter_property: CRTC property to apply a particular filter
A scaling filter option can also be useful for scaling individual
planes, do you have any plans to extend the property's applications
in that direction?
> + * while scaling in panel fitter mode.
> + */
> + struct drm_property *scaling_filter_property;
> +
> /* cursor size */
> uint32_t cursor_width, cursor_height;
>
>
--
Mihail
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
Re: [PATCH v4] drm/ioctl: Add a ioctl to label GEM objects
Hey, On Tue, 22 Oct 2019 at 11:30, Daniel Vetter wrote: > On Tue, Oct 22, 2019 at 10:58:02AM +0200, Rohan Garg wrote: > > This approach also future proof's us to be able to label any handles, not > > just > > GEM handle. > > I don't expect we'll ever merge any non-gem drivers in the future anymore. > Hence this really only makes sense if vmwgfx wants it, that's the only > use-case for this generic-ism here. If vmwgfx doesn't have a use or jump > on board with this, imo better to just make this specific to gem and be > done. VMware were the exact people who asked it for to be handle-agnostic and not GEM-specific ... Given that we already have handle-agnostic calls like FBs in particular, I think it makes sense to have this one just follow that. It's not much code and doesn't really imply any heavy change for the rest of DRM. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Tue, Oct 22, 2019 at 2:45 PM Mika Westerberg
wrote:
>
> On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> > I think there is something I totally forgot about:
> >
> > When there was never a driver bound to the GPU, and if runtime power
> > management gets enabled on that device, runtime suspend/resume works
> > as expected (I am not 100% sure on if that always works, but I will
> > recheck that).
>
> AFAIK, if there is no driver bound to the PCI device it is left to D0
> regardless of the runtime PM state which could explain why it works in
> that case (it is never put into D3hot).
>
> I looked at the acpidump you sent and there is one thing that may
> explain the differences between Windows and Linux. Not sure if you were
> aware of this already, though. The power resource PGOF() method has
> this:
>
>If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05 {
> ...
>}
>
I think this is the fallback to some older method of runtime
suspending the device, and I think it will end up touching different
registers on the bridge controller which do not show the broken
behaviour.
You'll find references to following variables which all cause a link
to be powered down: Q0L2 (newest), P0L2, P0LD (oldest, I think).
Maybe I remember incorrectly and have to read the code again... okay,
the fallback path uses P0LD indeed. That's actually the only register
of those being documented by Intel afaik.
> If I read it right, the later condition tries to detect Linux which
> fails nowadays but if you have acpi_rev_override in the command line (or
> the machine is listed in acpi_rev_dmi_table) this check passes and does
> some magic which is not clear to me. There is similar in PGON() side
> which is used to turn the device back on.
>
> You can check what actually happens when _ON()/_OFF() is called by
> passing something like below to the kernel command line:
>
> acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10
> acpi.trace_method_name=\_SB.PCI0.PEG0.PG00._ON acpi.trace_state=method
>
> (See also Documentation/firmware-guide/acpi/method-tracing.rst).
>
> Trace goes to system dmesg.
This sounds to be very helpful, I'll give it a try.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag
On Tue, Oct 22, 2019 at 6:14 AM Laurent Pinchart
wrote:
>
> Hi Rob,
>
> Thank you for the patch.
>
> On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> > Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> > drm_mode_create_dumb. This flag is for internal kernel use to indicate
> > if dumb buffer allocation needs a kernel mapping. This is needed only for
> > CMA where creating a kernel mapping or not has to be decided at allocation
> > time because creating a mapping on demand (with vmap()) is not guaranteed
> > to work. Several drivers are using CMA, but not the CMA helpers because
> > they distinguish between kernel and userspace allocations to create a
> > kernel mapping or not.
> >
> > Update the callers of drm_mode_dumb_create() to set
> > drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> > be set to anything by userspace, but is unused within the kernel. Let's
> > force flags to zero (no kernel mapping) for userspace callers by default.
> > For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> > can override this as needed.
> >
> > Cc: David Airlie
> > Cc: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Signed-off-by: Rob Herring
> > ---
> > drivers/gpu/drm/drm_client.c | 1 +
> > drivers/gpu/drm/drm_dumb_buffers.c | 5 -
> > include/uapi/drm/drm_mode.h| 2 ++
> > 3 files changed, 7 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> > index d9a2e3695525..dbfc8061b392 100644
> > --- a/drivers/gpu/drm/drm_client.c
> > +++ b/drivers/gpu/drm/drm_client.c
> > @@ -264,6 +264,7 @@ drm_client_buffer_create(struct drm_client_dev *client,
> > u32 width, u32 height, u
> > dumb_args.width = width;
> > dumb_args.height = height;
> > dumb_args.bpp = info->cpp[0] * 8;
> > + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> > ret = drm_mode_create_dumb(dev, _args, client->file);
> > if (ret)
> > goto err_delete;
> > diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> > b/drivers/gpu/drm/drm_dumb_buffers.c
> > index d18a740fe0f1..74a13f14c173 100644
> > --- a/drivers/gpu/drm/drm_dumb_buffers.c
> > +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> > @@ -97,7 +97,10 @@ int drm_mode_create_dumb(struct drm_device *dev,
> > int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> > void *data, struct drm_file *file_priv)
> > {
> > - return drm_mode_create_dumb(dev, data, file_priv);
> > + struct drm_mode_create_dumb *args = data;
> > +
> > + args->flags = 0;
>
> I would prefer returning an error if flags is set to a non-zero value,
> to catch userspace errors early, but I'm also worried it would break
> existing userspace by uncovering existing bugs. Still, if we later add
> flags that userspace can set, those existing bugs will be triggered, so
> we'll have to deal with them anyway, and we could already give it a try.
I would like that too, but the comment just above this code tells me
that's likely to break things:
/*
* handle, pitch and size are output parameters. Zero them out to
* prevent drivers from accidentally using uninitialized data. Since
* not all existing userspace is clearing these fields properly we
* cannot reject IOCTL with garbage in them.
*/
Maybe userspace does correctly zero out input params.
Rob
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3] pci: prevent putting nvidia GPUs into lower device states on certain intel bridges
On Tue, Oct 22, 2019 at 11:16:14AM +0200, Karol Herbst wrote:
> I think there is something I totally forgot about:
>
> When there was never a driver bound to the GPU, and if runtime power
> management gets enabled on that device, runtime suspend/resume works
> as expected (I am not 100% sure on if that always works, but I will
> recheck that).
AFAIK, if there is no driver bound to the PCI device it is left to D0
regardless of the runtime PM state which could explain why it works in
that case (it is never put into D3hot).
I looked at the acpidump you sent and there is one thing that may
explain the differences between Windows and Linux. Not sure if you were
aware of this already, though. The power resource PGOF() method has
this:
If (((OSYS <= 0x07D9) || ((OSYS == 0x07DF) && (_REV == 0x05 {
...
}
If I read it right, the later condition tries to detect Linux which
fails nowadays but if you have acpi_rev_override in the command line (or
the machine is listed in acpi_rev_dmi_table) this check passes and does
some magic which is not clear to me. There is similar in PGON() side
which is used to turn the device back on.
You can check what actually happens when _ON()/_OFF() is called by
passing something like below to the kernel command line:
acpi.trace_debug_layer=0x80 acpi.trace_debug_level=0x10
acpi.trace_method_name=\_SB.PCI0.PEG0.PG00._ON acpi.trace_state=method
(See also Documentation/firmware-guide/acpi/method-tracing.rst).
Trace goes to system dmesg.
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the scenarios where
> Integer mode scaling is possible, and a UI client wants to pick
> filters like Nearest-neighbor applied for non-blurry outputs.
>
> There was a RFC patch series published, to discus the request to enable
> Integer mode scaling by some of the gaming communities, which can be
> found here:
> https://patchwork.freedesktop.org/series/66175/
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> include/drm/drm_crtc.h| 26 ++
> include/drm/drm_mode_config.h | 6 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 0d466d3b0809..883329453a86 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> return ret;
> } else if (property == config->prop_vrr_enabled) {
> state->vrr_enabled = val;
> + } else if (property == config->scaling_filter_property) {
> + state->scaling_filter = val;
> } else if (property == config->degamma_lut_property) {
> ret = drm_atomic_replace_property_blob_from_id(dev,
> >degamma_lut,
> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> else if (property == config->prop_out_fence_ptr)
> *val = 0;
> + else if (property == config->scaling_filter_property)
> + *val = state->scaling_filter;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> else
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5e9b15a0e8c5..94c5509474a8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -58,6 +58,25 @@ struct device_node;
> struct dma_fence;
> struct edid;
>
> +enum drm_scaling_filters {
> + DRM_SCALING_FILTER_DEFAULT,
> + DRM_SCALING_FILTER_MEDIUM,
> + DRM_SCALING_FILTER_BILINEAR,
> + DRM_SCALING_FILTER_NN,
> + DRM_SCALING_FILTER_NN_IS_ONLY,
> + DRM_SCALING_FILTER_EDGE_ENHANCE,
> + DRM_SCALING_FILTER_INVALID,
> +};
> +
> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> + { DRM_SCALING_FILTER_INVALID, "Invalid" },
> +};
> +
> static inline int64_t U642I64(uint64_t val)
> {
> return (int64_t)*((int64_t *));
> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>*/
> u32 target_vblank;
>
> + /**
> + * @scaling_filter:
> + *
> + * Scaling filter mode to be applied
> + */
> + u32 scaling_filter;
> +
> /**
>* @async_flip:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3bcbe30339f0..efd6fd55770f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -914,6 +914,12 @@ struct drm_mode_config {
>*/
> struct drm_property *modifiers_property;
>
> + /**
> + * @scaling_filter_property: CRTC property to apply a particular filter
> + * while scaling in panel fitter mode.
> + */
> + struct drm_property *scaling_filter_property;
This needs to per-crtc/plane.
> +
> /* cursor size */
> uint32_t cursor_width, cursor_height;
>
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode property
On Tue, Oct 22, 2019 at 10:12:29AM +, Sharma, Shashank wrote: > Hey Daniel, > > > -Original Message- > > From: Daniel Vetter On Behalf Of Daniel Vetter > > Sent: Tuesday, October 22, 2019 3:39 PM > > To: Sharma, Shashank > > Cc: dri-devel@lists.freedesktop.org; intel-...@lists.freedesktop.org > > Subject: Re: [Intel-gfx] [PATCH 1/3] drm: Introduce scaling filter mode > > property > > > > On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote: > > > This patch adds a scaling filter mode porperty to allow: > > > - A driver/HW to showcase it's scaling filter capabilities. > > > - A userspace to pick a desired effect while scaling. > > > > > > This option will be particularly useful in the scenarios where Integer > > > mode scaling is possible, and a UI client wants to pick filters like > > > Nearest-neighbor applied for non-blurry outputs. > > > > > > There was a RFC patch series published, to discus the request to > > > enable Integer mode scaling by some of the gaming communities, which > > > can be found here: > > > https://patchwork.freedesktop.org/series/66175/ > > > > > > Signed-off-by: Shashank Sharma > > > > Two things: > > > > - needs real property docs for this in the kms property chapter > Got it, > > - would be good if we could somehow subsume the panel fitter prop into > > this? Or at least document possible interactions with that. > > > Sure, let me see what can I do here. The scaling mode prop has nothing really to do with the filter being used. The scaling mode prop just provides a bad mechanism for configuring the destination coordinates of the scaler. Trying to shoehorn these things into one prop would be a mistake IMO. -- Ville Syrjälä Intel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: Introduce scaling filter mode property
On Tue, Oct 22, 2019 at 03:29:44PM +0530, Shashank Sharma wrote:
> This patch adds a scaling filter mode porperty
> to allow:
> - A driver/HW to showcase it's scaling filter capabilities.
> - A userspace to pick a desired effect while scaling.
>
> This option will be particularly useful in the scenarios where
> Integer mode scaling is possible, and a UI client wants to pick
> filters like Nearest-neighbor applied for non-blurry outputs.
>
> There was a RFC patch series published, to discus the request to enable
> Integer mode scaling by some of the gaming communities, which can be
> found here:
> https://patchwork.freedesktop.org/series/66175/
>
> Signed-off-by: Shashank Sharma
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> include/drm/drm_crtc.h| 26 ++
> include/drm/drm_mode_config.h | 6 ++
> 3 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 0d466d3b0809..883329453a86 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -435,6 +435,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
> *crtc,
> return ret;
> } else if (property == config->prop_vrr_enabled) {
> state->vrr_enabled = val;
> + } else if (property == config->scaling_filter_property) {
> + state->scaling_filter = val;
> } else if (property == config->degamma_lut_property) {
> ret = drm_atomic_replace_property_blob_from_id(dev,
> >degamma_lut,
> @@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
> *val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
> else if (property == config->prop_out_fence_ptr)
> *val = 0;
> + else if (property == config->scaling_filter_property)
> + *val = state->scaling_filter;
> else if (crtc->funcs->atomic_get_property)
> return crtc->funcs->atomic_get_property(crtc, state, property,
> val);
> else
> diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
> index 5e9b15a0e8c5..94c5509474a8 100644
> --- a/include/drm/drm_crtc.h
> +++ b/include/drm/drm_crtc.h
> @@ -58,6 +58,25 @@ struct device_node;
> struct dma_fence;
> struct edid;
>
> +enum drm_scaling_filters {
> + DRM_SCALING_FILTER_DEFAULT,
> + DRM_SCALING_FILTER_MEDIUM,
> + DRM_SCALING_FILTER_BILINEAR,
> + DRM_SCALING_FILTER_NN,
Please use real words.
> + DRM_SCALING_FILTER_NN_IS_ONLY,
Not a big fan of this. I'd just add the explicit nearest filter
and leave the decision whether to use it to userspace.
> + DRM_SCALING_FILTER_EDGE_ENHANCE,
> + DRM_SCALING_FILTER_INVALID,
That invalid enum value seems entirely pointless.
This set of filters is pretty arbitrary. It doesn't even cover all
Intel hw. I would probably just leave it at "default+linear+nearest"
initially. Exposing more vague hw specific choices needs more though,
and I'd prefer not to spend those brain cells until a real use case
emerges.
> +};
> +
> +static const struct drm_prop_enum_list drm_scaling_filter_enum_list[] = {
> + { DRM_SCALING_FILTER_DEFAULT, "Default" },
> + { DRM_SCALING_FILTER_MEDIUM, "Medium" },
> + { DRM_SCALING_FILTER_BILINEAR, "Bilinear" },
> + { DRM_SCALING_FILTER_NN, "Nearest Neighbor" },
> + { DRM_SCALING_FILTER_NN_IS_ONLY, "Integer Mode Scaling" },
> + { DRM_SCALING_FILTER_INVALID, "Invalid" },
> +};
> +
> static inline int64_t U642I64(uint64_t val)
> {
> return (int64_t)*((int64_t *));
> @@ -283,6 +302,13 @@ struct drm_crtc_state {
>*/
> u32 target_vblank;
>
> + /**
> + * @scaling_filter:
> + *
> + * Scaling filter mode to be applied
> + */
> + u32 scaling_filter;
We have an enum so should use it. The documentation should probably
point out that this applies to full crtc scaling only, not plane
scaling.
> +
> /**
>* @async_flip:
>*
> diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
> index 3bcbe30339f0..efd6fd55770f 100644
> --- a/include/drm/drm_mode_config.h
> +++ b/include/drm/drm_mode_config.h
> @@ -914,6 +914,12 @@ struct drm_mode_config {
>*/
> struct drm_property *modifiers_property;
>
> + /**
> + * @scaling_filter_property: CRTC property to apply a particular filter
> + * while scaling in panel fitter mode.
> + */
> + struct drm_property *scaling_filter_property;
> +
> /* cursor size */
> uint32_t cursor_width, cursor_height;
>
> --
> 2.17.1
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hmm 00/15] Consolidate the mmu notifier interval_tree and locking
On 10/21/2019 12:58 PM, Jason Gunthorpe wrote: On Mon, Oct 21, 2019 at 11:55:51AM -0400, Dennis Dalessandro wrote: On 10/15/2019 2:12 PM, Jason Gunthorpe wrote: This is still being tested, but I figured to send it to start getting help from the xen, amd and hfi drivers which I cannot test here. Sorry for the delay, I never seen this. Was not on Cc list and didn't register to me it impacted hfi. I'll take a look and run it through some hfi1 tests. Hm, you were cc'd on the hfi1 patch of the series: https://patchwork.kernel.org/patch/11191395/ So you saw that, right? I do now. But it seems that git send-email didn't pull all the cc's together? I don't know. I thought it did, at one time I recall trying to get it *not* to do that, when preparing some internal reviews. Haven't used it for a long time though, I've been using stgit. At any rate can you give me a SHA or branch this applies on top of? I have pulled rdma/hmm, rdma/wip/jgg, linus/master but seem to have conflicts. -Denny ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 111244] amdgpu kernel 5.2 blank display after resume from suspend
https://bugs.freedesktop.org/show_bug.cgi?id=111244 --- Comment #34 from Carmen Bianca Bakker --- Created attachment 145793 --> https://bugs.freedesktop.org/attachment.cgi?id=145793=edit failed suspend 5.4.0rc2 Issue still occurs on 5.4rc2. In these logs, on the second suspension. Thinkpad X395, Ryzen 3500U. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/cma-helper: Support DRM_MODE_DUMB_KERNEL_MAP flag
Hi Laurent,
On Tue, Oct 22, 2019 at 1:30 PM Laurent Pinchart
wrote:
> On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> > --- a/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > +++ b/drivers/gpu/drm/rockchip/rockchip_drm_gem.c
> > @@ -419,6 +419,7 @@ int rockchip_gem_dumb_create(struct drm_file *file_priv,
> >* align to 64 bytes since Mali requires it.
> >*/
> > args->pitch = ALIGN(min_pitch, 64);
> > + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
> > args->size = args->pitch * args->height;
>
> My OCD gets triggered by flags appearing in the middle here while it is
> at the end in other drivers :-)
... while "flags" appears before "pitch" and "size" in the actual struct
definition... Aaarghl ;-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 4/6] drm/cma-helper: Support DRM_MODE_DUMB_KERNEL_MAP flag
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:48PM -0500, Rob Herring wrote:
> Add support in CMA helpers to handle callers specifying
> DRM_MODE_DUMB_KERNEL_MAP flag. Existing behavior is maintained with this
> change. drm_gem_cma_dumb_create() always creates a kernel mapping as
> before. drm_gem_cma_dumb_create_internal() lets the caller set the flags
> as desired. Therefore, update all the existing callers of
> drm_gem_cma_dumb_create_internal() to also set the
> DRM_MODE_DUMB_KERNEL_MAP flag.
>
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: "James (Qian) Wang"
> Cc: Liviu Dudau
> Cc: Brian Starkey
> Cc: Neil Armstrong
> Cc: Kevin Hilman
> Cc: Laurent Pinchart
> Cc: Kieran Bingham
> Cc: Sandy Huang
> Cc: "Heiko Stübner"
> Cc: Yannick Fertre
> Cc: Philippe Cornu
> Cc: Benjamin Gaignard
> Cc: Vincent Abriou
> Cc: Maxime Coquelin
> Cc: Alexandre Torgue
> Cc: Chen-Yu Tsai
> Cc: linux-amlo...@lists.infradead.org
> Cc: linux-arm-ker...@lists.infradead.org
> Cc: linux-renesas-...@vger.kernel.org
> Cc: linux-rockc...@lists.infradead.org
> Cc: linux-st...@st-md-mailman.stormreply.com
> Signed-off-by: Rob Herring
> ---
> .../gpu/drm/arm/display/komeda/komeda_kms.c | 1 +
> drivers/gpu/drm/arm/malidp_drv.c | 1 +
> drivers/gpu/drm/drm_gem_cma_helper.c | 48 +++
> drivers/gpu/drm/meson/meson_drv.c | 1 +
> drivers/gpu/drm/rcar-du/rcar_du_kms.c | 1 +
> drivers/gpu/drm/rockchip/rockchip_drm_gem.c | 1 +
> drivers/gpu/drm/stm/drv.c | 1 +
> drivers/gpu/drm/sun4i/sun4i_drv.c | 1 +
> 8 files changed, 36 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> index d49772de93e0..7cf0dc4cbfc1 100644
> --- a/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> +++ b/drivers/gpu/drm/arm/display/komeda/komeda_kms.c
> @@ -31,6 +31,7 @@ static int komeda_gem_cma_dumb_create(struct drm_file *file,
> u32 pitch = DIV_ROUND_UP(args->width * args->bpp, 8);
>
> args->pitch = ALIGN(pitch, mdev->chip.bus_width);
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
>
> return drm_gem_cma_dumb_create_internal(file, dev, args);
> }
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 8a76315aaa0f..aeb1a779ecc1 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -465,6 +465,7 @@ static int malidp_dumb_create(struct drm_file *file_priv,
> u8 alignment = malidp_hw_get_pitch_align(malidp->dev, 1);
>
> args->pitch = ALIGN(DIV_ROUND_UP(args->width * args->bpp, 8),
> alignment);
> + args->flags = DRM_MODE_DUMB_KERNEL_MAP;
>
> return drm_gem_cma_dumb_create_internal(file_priv, drm, args);
> }
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 4cebfe01e6ea..f91e9e8adeaf 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -78,21 +78,8 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
> return ERR_PTR(ret);
> }
>
> -/**
> - * drm_gem_cma_create - allocate an object with the given size
> - * @drm: DRM device
> - * @size: size of the object to allocate
> - *
> - * This function creates a CMA GEM object and allocates a contiguous chunk of
> - * memory as backing store. The backing memory has the writecombine attribute
> - * set.
> - *
> - * Returns:
> - * A struct drm_gem_cma_object * on success or an ERR_PTR()-encoded negative
> - * error code on failure.
> - */
> -struct drm_gem_cma_object *drm_gem_cma_create(struct drm_device *drm,
> - size_t size)
> +static struct drm_gem_cma_object *
> +drm_gem_cma_create_flags(struct drm_device *drm, size_t size, u32 flags)
> {
> struct drm_gem_cma_object *cma_obj;
> int ret;
> @@ -103,6 +90,9 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> if (IS_ERR(cma_obj))
> return cma_obj;
>
> + if (!(flags & DRM_MODE_DUMB_KERNEL_MAP))
> + cma_obj->dma_attrs |= DMA_ATTR_NO_KERNEL_MAPPING;
> +
> cma_obj->vaddr = dma_alloc_attrs(drm->dev, size, _obj->paddr,
>GFP_KERNEL | __GFP_NOWARN,
>cma_obj->dma_attrs);
> @@ -119,6 +109,25 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> drm_gem_object_put_unlocked(_obj->base);
> return ERR_PTR(ret);
> }
> +
> +/**
> + * drm_gem_cma_create - allocate an object with the given size
> + * @drm: DRM device
> + * @size: size of the object to allocate
> + *
> + * This function creates a CMA GEM object and allocates a contiguous chunk of
> + * memory as backing store. The backing memory has the writecombine
Re: [PATCH 3/6] drm/cma-helper: Use the dma_*_attr API variant
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:47PM -0500, Rob Herring wrote:
> In preparation to allow DRM CMA users to adjust the DMA_ATTR_* flags,
> convert the CMA helper code to use the dma_*_attr APIs instead of the
> dma_*_wc variants.
>
> Only the DMA_ATTR_WRITE_COMBINE and DMA_ATTR_NO_WARN attributes are set
> in this commit, so there's no functional change.
Apart from the documentation issue reported by kbuild,
Reviewed-by: Laurent Pinchart
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: David Airlie
> Cc: Daniel Vetter
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/drm_gem_cma_helper.c | 20
> include/drm/drm_gem_cma_helper.h | 1 +
> 2 files changed, 13 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_gem_cma_helper.c
> b/drivers/gpu/drm/drm_gem_cma_helper.c
> index 12e98fb28229..4cebfe01e6ea 100644
> --- a/drivers/gpu/drm/drm_gem_cma_helper.c
> +++ b/drivers/gpu/drm/drm_gem_cma_helper.c
> @@ -70,6 +70,7 @@ __drm_gem_cma_create(struct drm_device *drm, size_t size)
> goto error;
> }
>
> + cma_obj->dma_attrs |= DMA_ATTR_NO_WARN | DMA_ATTR_WRITE_COMBINE;
> return cma_obj;
>
> error:
> @@ -102,8 +103,9 @@ struct drm_gem_cma_object *drm_gem_cma_create(struct
> drm_device *drm,
> if (IS_ERR(cma_obj))
> return cma_obj;
>
> - cma_obj->vaddr = dma_alloc_wc(drm->dev, size, _obj->paddr,
> - GFP_KERNEL | __GFP_NOWARN);
> + cma_obj->vaddr = dma_alloc_attrs(drm->dev, size, _obj->paddr,
> + GFP_KERNEL | __GFP_NOWARN,
> + cma_obj->dma_attrs);
> if (!cma_obj->vaddr) {
> dev_dbg(drm->dev, "failed to allocate buffer with size %zu\n",
> size);
> @@ -184,8 +186,9 @@ void drm_gem_cma_free_object(struct drm_gem_object
> *gem_obj)
> dma_buf_vunmap(gem_obj->import_attach->dmabuf,
> cma_obj->vaddr);
> drm_prime_gem_destroy(gem_obj, cma_obj->sgt);
> } else if (cma_obj->vaddr) {
> - dma_free_wc(gem_obj->dev->dev, cma_obj->base.size,
> - cma_obj->vaddr, cma_obj->paddr);
> + dma_free_attrs(gem_obj->dev->dev, cma_obj->base.size,
> +cma_obj->vaddr, cma_obj->paddr,
> +cma_obj->dma_attrs);
> }
>
> drm_gem_object_release(gem_obj);
> @@ -279,8 +282,9 @@ static int drm_gem_cma_mmap_obj(struct drm_gem_cma_object
> *cma_obj,
> vma->vm_flags &= ~VM_PFNMAP;
> vma->vm_pgoff = 0;
>
> - ret = dma_mmap_wc(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
> - cma_obj->paddr, vma->vm_end - vma->vm_start);
> + ret = dma_mmap_attrs(cma_obj->base.dev->dev, vma, cma_obj->vaddr,
> + cma_obj->paddr, vma->vm_end - vma->vm_start,
> + cma_obj->dma_attrs);
> if (ret)
> drm_gem_vm_close(vma);
>
> @@ -434,8 +438,8 @@ struct sg_table *drm_gem_cma_prime_get_sg_table(struct
> drm_gem_object *obj)
> if (!sgt)
> return ERR_PTR(-ENOMEM);
>
> - ret = dma_get_sgtable(obj->dev->dev, sgt, cma_obj->vaddr,
> - cma_obj->paddr, obj->size);
> + ret = dma_get_sgtable_attrs(obj->dev->dev, sgt, cma_obj->vaddr,
> + cma_obj->paddr, obj->size, cma_obj->dma_attrs);
> if (ret < 0)
> goto out;
>
> diff --git a/include/drm/drm_gem_cma_helper.h
> b/include/drm/drm_gem_cma_helper.h
> index 947ac95eb24a..d042213c3595 100644
> --- a/include/drm/drm_gem_cma_helper.h
> +++ b/include/drm/drm_gem_cma_helper.h
> @@ -24,6 +24,7 @@ struct drm_gem_cma_object {
>
> /* For objects with DMA memory allocated by GEM CMA */
> void *vaddr;
> + unsigned long dma_attrs;
> };
>
> #define to_drm_gem_cma_obj(gem_obj) \
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/6] drm: Introduce DRM_MODE_DUMB_KERNEL_MAP flag
Hi Rob,
Thank you for the patch.
On Mon, Oct 21, 2019 at 04:45:46PM -0500, Rob Herring wrote:
> Introduce a new flag, DRM_MODE_DUMB_KERNEL_MAP, for struct
> drm_mode_create_dumb. This flag is for internal kernel use to indicate
> if dumb buffer allocation needs a kernel mapping. This is needed only for
> CMA where creating a kernel mapping or not has to be decided at allocation
> time because creating a mapping on demand (with vmap()) is not guaranteed
> to work. Several drivers are using CMA, but not the CMA helpers because
> they distinguish between kernel and userspace allocations to create a
> kernel mapping or not.
>
> Update the callers of drm_mode_dumb_create() to set
> drm_mode_dumb_create.flags to appropriate defaults. Currently, flags can
> be set to anything by userspace, but is unused within the kernel. Let's
> force flags to zero (no kernel mapping) for userspace callers by default.
> For in kernel clients, set DRM_MODE_DUMB_KERNEL_MAP by default. Drivers
> can override this as needed.
>
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Signed-off-by: Rob Herring
> ---
> drivers/gpu/drm/drm_client.c | 1 +
> drivers/gpu/drm/drm_dumb_buffers.c | 5 -
> include/uapi/drm/drm_mode.h| 2 ++
> 3 files changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_client.c b/drivers/gpu/drm/drm_client.c
> index d9a2e3695525..dbfc8061b392 100644
> --- a/drivers/gpu/drm/drm_client.c
> +++ b/drivers/gpu/drm/drm_client.c
> @@ -264,6 +264,7 @@ drm_client_buffer_create(struct drm_client_dev *client,
> u32 width, u32 height, u
> dumb_args.width = width;
> dumb_args.height = height;
> dumb_args.bpp = info->cpp[0] * 8;
> + dumb_args.flags = DRM_MODE_DUMB_KERNEL_MAP;
> ret = drm_mode_create_dumb(dev, _args, client->file);
> if (ret)
> goto err_delete;
> diff --git a/drivers/gpu/drm/drm_dumb_buffers.c
> b/drivers/gpu/drm/drm_dumb_buffers.c
> index d18a740fe0f1..74a13f14c173 100644
> --- a/drivers/gpu/drm/drm_dumb_buffers.c
> +++ b/drivers/gpu/drm/drm_dumb_buffers.c
> @@ -97,7 +97,10 @@ int drm_mode_create_dumb(struct drm_device *dev,
> int drm_mode_create_dumb_ioctl(struct drm_device *dev,
> void *data, struct drm_file *file_priv)
> {
> - return drm_mode_create_dumb(dev, data, file_priv);
> + struct drm_mode_create_dumb *args = data;
> +
> + args->flags = 0;
I would prefer returning an error if flags is set to a non-zero value,
to catch userspace errors early, but I'm also worried it would break
existing userspace by uncovering existing bugs. Still, if we later add
flags that userspace can set, those existing bugs will be triggered, so
we'll have to deal with them anyway, and we could already give it a try.
The patch otherwise looks good to me.
> + return drm_mode_create_dumb(dev, args, file_priv);
> }
>
> /**
> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
> index 735c8cfdaaa1..02712f46b94c 100644
> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -796,6 +796,8 @@ struct drm_mode_crtc_page_flip_target {
> __u64 user_data;
> };
>
> +#define DRM_MODE_DUMB_KERNEL_MAP (1<<0) /* For internal kernel use */
> +
> /* create a dumb scanout buffer */
> struct drm_mode_create_dumb {
> __u32 height;
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] video: hyperv: hyperv_fb: Use physical memory for fb on HyperV Gen 1 VMs.
On Hyper-V, Generation 1 VMs can directly use VM's physical memory for
their framebuffers. This can improve the efficiency of framebuffer and
overall performence for VM. The physical memory assigned to framebuffer
must be contiguous. We use CMA allocator to get contiguouse physicial
memory when the framebuffer size is greater than 4MB. For size under
4MB, we use alloc_pages to achieve this.
To enable framebuffer memory allocation from CMA, supply a kernel
parameter to give enough space to CMA allocator at boot time. For
example:
cma=130m
This gives 130MB memory to CAM allocator that can be allocated to
framebuffer. If this fails, we fall back to the old way of using
mmio for framebuffer.
Signed-off-by: Wei Hu
---
drivers/video/fbdev/Kconfig | 1 +
drivers/video/fbdev/hyperv_fb.c | 179 +---
kernel/dma/contiguous.c | 2 +
3 files changed, 147 insertions(+), 35 deletions(-)
diff --git a/drivers/video/fbdev/Kconfig b/drivers/video/fbdev/Kconfig
index aa9541bf964b..f534059461ee 100644
--- a/drivers/video/fbdev/Kconfig
+++ b/drivers/video/fbdev/Kconfig
@@ -2215,6 +2215,7 @@ config FB_HYPERV
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
select FB_DEFERRED_IO
+ select DMA_CMA
help
This framebuffer driver supports Microsoft Hyper-V Synthetic Video.
diff --git a/drivers/video/fbdev/hyperv_fb.c b/drivers/video/fbdev/hyperv_fb.c
index 3f60b7bc8589..ea2fd3481225 100644
--- a/drivers/video/fbdev/hyperv_fb.c
+++ b/drivers/video/fbdev/hyperv_fb.c
@@ -31,6 +31,16 @@
* "set-vmvideo" command. For example
* set-vmvideo -vmname name -horizontalresolution:1920 \
* -verticalresolution:1200 -resolutiontype single
+ *
+ * Gen 1 VMs also support directly using VM's phyiscal memory for framebuffer.
+ * It could improve the efficiency and performance for framebuffer and VM.
+ * This requires to allocate contiguous physical memory from Linux kernel's
+ * CMA memory allocator. To enable this, supply a kernel parameter to give
+ * enough memory space to CMA allocator for framebuffer. For example:
+ *cma=130m
+ * This gives 130MB memory to CMA allocator that can be allocated to
+ * framebuffer. For reference, 8K resolution (7680x4320) takes about
+ * 127MB memory.
*/
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
@@ -42,6 +52,7 @@
#include
#include
#include
+#include
#include
@@ -227,7 +238,6 @@ struct synthvid_msg {
} __packed;
-
/* FB driver definitions and structures */
#define HVFB_WIDTH 1152 /* default screen width */
#define HVFB_HEIGHT 864 /* default screen height */
@@ -256,6 +266,9 @@ struct hvfb_par {
/* If true, the VSC notifies the VSP on every framebuffer change */
bool synchronous_fb;
+ /* If true, need to copy from deferred IO mem to framebuffer mem */
+ bool need_docopy;
+
struct notifier_block hvfb_panic_nb;
/* Memory for deferred IO and frame buffer itself */
@@ -432,7 +445,7 @@ static void synthvid_deferred_io(struct fb_info *p,
maxy = max_t(int, maxy, y2);
/* Copy from dio space to mmio address */
- if (par->fb_ready)
+ if (par->fb_ready && par->need_docopy)
hvfb_docopy(par, start, PAGE_SIZE);
}
@@ -749,12 +762,12 @@ static void hvfb_update_work(struct work_struct *w)
return;
/* Copy the dirty rectangle to frame buffer memory */
- for (j = y1; j < y2; j++) {
- hvfb_docopy(par,
- j * info->fix.line_length +
- (x1 * screen_depth / 8),
- (x2 - x1) * screen_depth / 8);
- }
+ if (par->need_docopy)
+ for (j = y1; j < y2; j++)
+ hvfb_docopy(par,
+ j * info->fix.line_length +
+ (x1 * screen_depth / 8),
+ (x2 - x1) * screen_depth / 8);
/* Refresh */
if (par->fb_ready && par->update)
@@ -799,7 +812,8 @@ static int hvfb_on_panic(struct notifier_block *nb,
par = container_of(nb, struct hvfb_par, hvfb_panic_nb);
par->synchronous_fb = true;
info = par->info;
- hvfb_docopy(par, 0, dio_fb_size);
+ if (par->need_docopy)
+ hvfb_docopy(par, 0, dio_fb_size);
synthvid_update(info, 0, 0, INT_MAX, INT_MAX);
return NOTIFY_DONE;
@@ -938,6 +952,62 @@ static void hvfb_get_option(struct fb_info *info)
return;
}
+/*
+ * Allocate enough contiguous physical memory.
+ * Return physical address if succeeded or -1 if failed.
+ */
+static unsigned long hvfb_get_phymem(unsigned int request_size)
+{
+ struct page *page = NULL;
+ unsigned int request_pages;
+ unsigned long paddr = 0;
+ unsigned int order = get_order(request_size);
+
+ if (request_size == 0)
+ return
[GIT PULL FOR v5.5 - 2nd try] R-Car DU CMM support
Hi Dave, Second attempt. The following changes since commit f1b4a9217efd61d0b84c6dc404596c8519ff6f59: Merge tag 'du-next-20191016' of git://linuxtv.org/pinchartl/media into drm-next (2019-10-22 15:04:07 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20191022 for you to fetch changes up to aad1552f1defd3a5334cd4b2573fae9963d4db57: drm: rcar-du: crtc: Register GAMMA_LUT properties (2019-10-22 13:21:18 +0300) - R-Car DU Color Management Module support Jacopo Mondi (6): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property drm: rcar-du: Add support for CMM drm: rcar-du: kms: Initialize CMM instances drm: rcar-du: crtc: Control CMM operations drm: rcar-du: crtc: Register GAMMA_LUT properties .../devicetree/bindings/display/renesas,cmm.yaml | 67 +++ .../devicetree/bindings/display/renesas,du.txt | 5 + drivers/gpu/drm/rcar-du/Kconfig| 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 + drivers/gpu/drm/rcar-du/rcar_cmm.h | 58 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 +++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_group.c| 10 + drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + 13 files changed, 523 insertions(+) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL FOR v5.5] R-Car DU CMM support
Please ignore this, I've included the DT patch by mistake. I'll drop it and resend. On Tue, Oct 22, 2019 at 01:29:08PM +0300, Laurent Pinchart wrote: > Hi Dave, > > The following changes since commit f1b4a9217efd61d0b84c6dc404596c8519ff6f59: > > Merge tag 'du-next-20191016' of git://linuxtv.org/pinchartl/media into > drm-next (2019-10-22 15:04:07 +1000) > > are available in the Git repository at: > > git://linuxtv.org/pinchartl/media.git tags/du-next-20191022 > > for you to fetch changes up to 153f2971b58764b7238989489bd45ca0f491f74a: > > arm64: dts: renesas: Add CMM units to Gen3 SoCs (2019-10-22 13:21:18 +0300) > > > - R-Car DU Color Management Module support > > > Jacopo Mondi (7): > dt-bindings: display: renesas,cmm: Add R-Car CMM documentation > dt-bindings: display, renesas,du: Document cmms property > drm: rcar-du: Add support for CMM > drm: rcar-du: kms: Initialize CMM instances > drm: rcar-du: crtc: Control CMM operations > drm: rcar-du: crtc: Register GAMMA_LUT properties > arm64: dts: renesas: Add CMM units to Gen3 SoCs > > .../devicetree/bindings/display/renesas,cmm.yaml | 67 +++ > .../devicetree/bindings/display/renesas,du.txt | 5 + > arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 > arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 ++- > arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 ++- > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21 ++ > arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 ++ > drivers/gpu/drm/rcar-du/Kconfig| 7 + > drivers/gpu/drm/rcar-du/Makefile | 1 + > drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 > + > drivers/gpu/drm/rcar-du/rcar_cmm.h | 58 ++ > drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 +++ > drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + > drivers/gpu/drm/rcar-du/rcar_du_group.c| 10 + > drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 + > drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 > drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + > 18 files changed, 664 insertions(+), 2 deletions(-) > create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c > create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[GIT PULL FOR v5.5] R-Car DU CMM support
Hi Dave, The following changes since commit f1b4a9217efd61d0b84c6dc404596c8519ff6f59: Merge tag 'du-next-20191016' of git://linuxtv.org/pinchartl/media into drm-next (2019-10-22 15:04:07 +1000) are available in the Git repository at: git://linuxtv.org/pinchartl/media.git tags/du-next-20191022 for you to fetch changes up to 153f2971b58764b7238989489bd45ca0f491f74a: arm64: dts: renesas: Add CMM units to Gen3 SoCs (2019-10-22 13:21:18 +0300) - R-Car DU Color Management Module support Jacopo Mondi (7): dt-bindings: display: renesas,cmm: Add R-Car CMM documentation dt-bindings: display, renesas,du: Document cmms property drm: rcar-du: Add support for CMM drm: rcar-du: kms: Initialize CMM instances drm: rcar-du: crtc: Control CMM operations drm: rcar-du: crtc: Register GAMMA_LUT properties arm64: dts: renesas: Add CMM units to Gen3 SoCs .../devicetree/bindings/display/renesas,cmm.yaml | 67 +++ .../devicetree/bindings/display/renesas,du.txt | 5 + arch/arm64/boot/dts/renesas/r8a7795.dtsi | 39 arch/arm64/boot/dts/renesas/r8a7796.dtsi | 31 ++- arch/arm64/boot/dts/renesas/r8a77965.dtsi | 31 ++- arch/arm64/boot/dts/renesas/r8a77990.dtsi | 21 ++ arch/arm64/boot/dts/renesas/r8a77995.dtsi | 21 ++ drivers/gpu/drm/rcar-du/Kconfig| 7 + drivers/gpu/drm/rcar-du/Makefile | 1 + drivers/gpu/drm/rcar-du/rcar_cmm.c | 217 + drivers/gpu/drm/rcar-du/rcar_cmm.h | 58 ++ drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 71 +++ drivers/gpu/drm/rcar-du/rcar_du_crtc.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_drv.h | 2 + drivers/gpu/drm/rcar-du/rcar_du_group.c| 10 + drivers/gpu/drm/rcar-du/rcar_du_group.h| 2 + drivers/gpu/drm/rcar-du/rcar_du_kms.c | 76 drivers/gpu/drm/rcar-du/rcar_du_regs.h | 5 + 18 files changed, 664 insertions(+), 2 deletions(-) create mode 100644 Documentation/devicetree/bindings/display/renesas,cmm.yaml create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.c create mode 100644 drivers/gpu/drm/rcar-du/rcar_cmm.h -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/5] drm/hisilicon/hibmc: Use GEM VRAM's prepare_fb() and cleanup_fb() helpers
This patch implements prepare_fb() and cleanup_fb() in hibmc with the
GEM VRAM helpers. In the current code, pinning the BO is performed by
hibmc_plane_atomic_update(), where the operation does not belong.
This patch also fixes a bug where the pinned BO was never unpinned.
Pinning multiple BOs would have exhaused the available VRAM and further
pin operations would have failed, leaving the display in a corrupt
state.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c | 14 --
1 file changed, 4 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
index cc4c41748cfb..6d87648df53c 100644
--- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
+++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c
@@ -96,7 +96,6 @@ static void hibmc_plane_atomic_update(struct drm_plane *plane,
{
struct drm_plane_state *state = plane->state;
u32 reg;
- int ret;
s64 gpu_addr = 0;
unsigned int line_l;
struct hibmc_drm_private *priv = plane->dev->dev_private;
@@ -109,16 +108,9 @@ static void hibmc_plane_atomic_update(struct drm_plane
*plane,
hibmc_fb = to_hibmc_framebuffer(state->fb);
gbo = drm_gem_vram_of_gem(hibmc_fb->obj);
- ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
- if (ret) {
- DRM_ERROR("failed to pin bo: %d", ret);
- return;
- }
gpu_addr = drm_gem_vram_offset(gbo);
- if (gpu_addr < 0) {
- drm_gem_vram_unpin(gbo);
- return;
- }
+ if (WARN_ON_ONCE(gpu_addr < 0))
+ return; /* Bug: we didn't pin the BO to VRAM in prepare_fb. */
writel(gpu_addr, priv->mmio + HIBMC_CRT_FB_ADDRESS);
@@ -157,6 +149,8 @@ static struct drm_plane_funcs hibmc_plane_funcs = {
};
static const struct drm_plane_helper_funcs hibmc_plane_helper_funcs = {
+ .prepare_fb = drm_gem_vram_plane_helper_funcs_prepare_fb,
+ .cleanup_fb = drm_gem_vram_plane_helper_funcs_cleanup_fb,
.atomic_check = hibmc_plane_atomic_check,
.atomic_update = hibmc_plane_atomic_update,
};
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm/vboxvideo: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_plane_helper_funcs. Switch over vboxvideo.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/vboxvideo/vbox_mode.c | 61 ++-
1 file changed, 4 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
b/drivers/gpu/drm/vboxvideo/vbox_mode.c
index b5604d32122e..b93001cfa0e6 100644
--- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
+++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
@@ -334,35 +334,6 @@ static void vbox_primary_atomic_disable(struct drm_plane
*plane,
old_state->src_y >> 16);
}
-static int vbox_primary_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *new_state)
-{
- struct drm_gem_vram_object *gbo;
- int ret;
-
- if (!new_state->fb)
- return 0;
-
- gbo = drm_gem_vram_of_gem(new_state->fb->obj[0]);
- ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
- if (ret)
- DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
-
- return ret;
-}
-
-static void vbox_primary_cleanup_fb(struct drm_plane *plane,
- struct drm_plane_state *old_state)
-{
- struct drm_gem_vram_object *gbo;
-
- if (!old_state->fb)
- return;
-
- gbo = drm_gem_vram_of_gem(old_state->fb->obj[0]);
- drm_gem_vram_unpin(gbo);
-}
-
static int vbox_cursor_atomic_check(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
@@ -492,30 +463,6 @@ static void vbox_cursor_atomic_disable(struct drm_plane
*plane,
mutex_unlock(>hw_mutex);
}
-static int vbox_cursor_prepare_fb(struct drm_plane *plane,
- struct drm_plane_state *new_state)
-{
- struct drm_gem_vram_object *gbo;
-
- if (!new_state->fb)
- return 0;
-
- gbo = drm_gem_vram_of_gem(new_state->fb->obj[0]);
- return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_SYSTEM);
-}
-
-static void vbox_cursor_cleanup_fb(struct drm_plane *plane,
- struct drm_plane_state *old_state)
-{
- struct drm_gem_vram_object *gbo;
-
- if (!plane->state->fb)
- return;
-
- gbo = drm_gem_vram_of_gem(plane->state->fb->obj[0]);
- drm_gem_vram_unpin(gbo);
-}
-
static const u32 vbox_cursor_plane_formats[] = {
DRM_FORMAT_ARGB,
};
@@ -524,8 +471,8 @@ static const struct drm_plane_helper_funcs
vbox_cursor_helper_funcs = {
.atomic_check = vbox_cursor_atomic_check,
.atomic_update = vbox_cursor_atomic_update,
.atomic_disable = vbox_cursor_atomic_disable,
- .prepare_fb = vbox_cursor_prepare_fb,
- .cleanup_fb = vbox_cursor_cleanup_fb,
+ .prepare_fb = drm_gem_vram_plane_helper_funcs_prepare_fb,
+ .cleanup_fb = drm_gem_vram_plane_helper_funcs_cleanup_fb,
};
static const struct drm_plane_funcs vbox_cursor_plane_funcs = {
@@ -546,8 +493,8 @@ static const struct drm_plane_helper_funcs
vbox_primary_helper_funcs = {
.atomic_check = vbox_primary_atomic_check,
.atomic_update = vbox_primary_atomic_update,
.atomic_disable = vbox_primary_atomic_disable,
- .prepare_fb = vbox_primary_prepare_fb,
- .cleanup_fb = vbox_primary_cleanup_fb,
+ .prepare_fb = drm_gem_vram_plane_helper_funcs_prepare_fb,
+ .cleanup_fb = drm_gem_vram_plane_helper_funcs_cleanup_fb,
};
static const struct drm_plane_funcs vbox_primary_plane_funcs = {
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/5] drm/vram-helpers: Add helpers for struct drm_plane_helper_funcs
The new helpers pin and unpin a framebuffer's GEM VRAM objects during
plane updates. This should be sufficient for most drivers prepare_fb and
cleanup_fb implementations.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/drm_gem_vram_helper.c | 81 +++
include/drm/drm_gem_vram_helper.h | 12
2 files changed, 93 insertions(+)
diff --git a/drivers/gpu/drm/drm_gem_vram_helper.c
b/drivers/gpu/drm/drm_gem_vram_helper.c
index dc7942981f4a..3ddb90475178 100644
--- a/drivers/gpu/drm/drm_gem_vram_helper.c
+++ b/drivers/gpu/drm/drm_gem_vram_helper.c
@@ -3,9 +3,11 @@
#include
#include
#include
+#include
#include
#include
#include
+#include
#include
#include
@@ -653,6 +655,85 @@ int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file
*file,
}
EXPORT_SYMBOL(drm_gem_vram_driver_dumb_mmap_offset);
+/*
+ * Helpers for struct drm_plane_helper_funcs
+ */
+
+/**
+ * drm_gem_vram_plane_helper_funcs_prepare_fb() - \
+ * Implements drm_plane_helper_funcs.prepare_fb
+ * @plane: a DRM plane.
+ * @new_state: the plane's new state
+ *
+ * During plane updates, this function pins the GEM VRAM
+ * objects of the plane's new framebuffer to VRAM. Call
+ * drm_gem_vram_plane_helper_funcs_cleanup_fb() to unpin them.
+ *
+ * Returns:
+ * 0 on success, or
+ * a negative errno code otherwise.
+ */
+int
+drm_gem_vram_plane_helper_funcs_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *new_state)
+{
+ size_t i;
+ struct drm_gem_vram_object *gbo;
+ int ret;
+
+ if (!new_state->fb)
+ return 0;
+
+ for (i = 0; i < ARRAY_SIZE(new_state->fb->obj); ++i) {
+ if (!new_state->fb->obj[i])
+ continue;
+ gbo = drm_gem_vram_of_gem(new_state->fb->obj[i]);
+ ret = drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
+ if (ret)
+ goto err_drm_gem_vram_unpin;
+ }
+
+ return 0;
+
+err_drm_gem_vram_unpin:
+ while (i) {
+ --i;
+ gbo = drm_gem_vram_of_gem(new_state->fb->obj[i]);
+ drm_gem_vram_unpin(gbo);
+ }
+ return ret;
+}
+EXPORT_SYMBOL(drm_gem_vram_plane_helper_funcs_prepare_fb);
+
+/**
+ * drm_gem_vram_plane_helper_funcs_cleanup_fb() - \
+ * Implements drm_plane_helper_funcs.cleanup_fb
+ * @plane: a DRM plane.
+ * @old_state: the plane's old state
+ *
+ * During plane updates, this function unpins the GEM VRAM
+ * objects of the plane's old framebuffer from VRAM. Complements
+ * drm_gem_vram_plane_helper_funcs_prepare_fb().
+ */
+void
+drm_gem_vram_plane_helper_funcs_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *old_state)
+{
+ size_t i;
+ struct drm_gem_vram_object *gbo;
+
+ if (!old_state->fb)
+ return;
+
+ for (i = 0; i < ARRAY_SIZE(old_state->fb->obj); ++i) {
+ if (!old_state->fb->obj[i])
+ continue;
+ gbo = drm_gem_vram_of_gem(old_state->fb->obj[i]);
+ drm_gem_vram_unpin(gbo);
+ }
+}
+EXPORT_SYMBOL(drm_gem_vram_plane_helper_funcs_cleanup_fb);
+
/*
* PRIME helpers
*/
diff --git a/include/drm/drm_gem_vram_helper.h
b/include/drm/drm_gem_vram_helper.h
index 354a9cd358a3..19ba5c0a1fd0 100644
--- a/include/drm/drm_gem_vram_helper.h
+++ b/include/drm/drm_gem_vram_helper.h
@@ -13,6 +13,8 @@
#include /* for container_of() */
struct drm_mode_create_dumb;
+struct drm_plane;
+struct drm_plane_state;
struct drm_vram_mm_funcs;
struct filp;
struct vm_area_struct;
@@ -124,6 +126,16 @@ int drm_gem_vram_driver_dumb_mmap_offset(struct drm_file
*file,
struct drm_device *dev,
uint32_t handle, uint64_t *offset);
+/*
+ * Helpers for struct drm_plane_helper_funcs
+ */
+int
+drm_gem_vram_plane_helper_funcs_prepare_fb(struct drm_plane *plane,
+ struct drm_plane_state *new_state);
+void
+drm_gem_vram_plane_helper_funcs_cleanup_fb(struct drm_plane *plane,
+ struct drm_plane_state *old_state);
+
/**
* define DRM_GEM_VRAM_DRIVER - default callback functions for \
drm_driver
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/5] drm/bochs: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers
GEM VRAM provides an implementation for prepare_fb() and cleanup_fb()
of struct drm_simple_display_pipe_funcs. Switch over bochs.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/bochs/bochs_kms.c | 26 ++
1 file changed, 2 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 0891640491eb..d77e17bb43ba 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -69,33 +69,11 @@ static void bochs_pipe_update(struct
drm_simple_display_pipe *pipe,
}
}
-static int bochs_pipe_prepare_fb(struct drm_plane *plane,
-struct drm_plane_state *new_state)
-{
- struct drm_gem_vram_object *gbo;
-
- if (!new_state->fb)
- return 0;
- gbo = drm_gem_vram_of_gem(new_state->fb->obj[0]);
- return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
-}
-
-static void bochs_pipe_cleanup_fb(struct drm_plane *plane,
- struct drm_plane_state *old_state)
-{
- struct drm_gem_vram_object *gbo;
-
- if (!old_state->fb)
- return;
- gbo = drm_gem_vram_of_gem(old_state->fb->obj[0]);
- drm_gem_vram_unpin(gbo);
-}
-
static const struct drm_simple_display_pipe_funcs bochs_pipe_funcs = {
.enable = bochs_pipe_enable,
.update = bochs_pipe_update,
- .prepare_fb = bochs_pipe_prepare_fb,
- .cleanup_fb = bochs_pipe_cleanup_fb,
+ .prepare_fb = drm_gem_vram_plane_helper_funcs_prepare_fb,
+ .cleanup_fb = drm_gem_vram_plane_helper_funcs_cleanup_fb,
};
static int bochs_connector_get_modes(struct drm_connector *connector)
--
2.23.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/5] drm/simple-kms-helper: Pass plane to prepare_fb() and cleanup_fb()
Passing the plane structure to prepare_fb() and cleanup_fb() of
struct drm_simple_display_pipe_funcs unifies the interface with
struct drm_plane_helper_funcs. Implementations of these functions
can now be shared between simple-pipeline and 'full-pipeline' drivers.
Before, the functions received the simple display pipeline's structure
as their first argument. Apparently no implementation needed that argument
and anyone interested can still get it from the plane via container_of().
As a side effect, drm_gem_fb_simple_display_pipe_prepare_fb() has been
removed.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +-
drivers/gpu/drm/bochs/bochs_kms.c| 4 ++--
drivers/gpu/drm/drm_gem_framebuffer_helper.c | 22
drivers/gpu/drm/drm_simple_kms_helper.c | 4 ++--
drivers/gpu/drm/mcde/mcde_display.c | 2 +-
drivers/gpu/drm/mxsfb/mxsfb_drv.c| 2 +-
drivers/gpu/drm/pl111/pl111_display.c| 2 +-
drivers/gpu/drm/tiny/hx8357d.c | 2 +-
drivers/gpu/drm/tiny/ili9225.c | 2 +-
drivers/gpu/drm/tiny/ili9341.c | 2 +-
drivers/gpu/drm/tiny/mi0283qt.c | 2 +-
drivers/gpu/drm/tiny/repaper.c | 2 +-
drivers/gpu/drm/tiny/st7586.c| 2 +-
drivers/gpu/drm/tiny/st7735r.c | 2 +-
drivers/gpu/drm/tve200/tve200_display.c | 2 +-
drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +-
include/drm/drm_gem_framebuffer_helper.h | 4 +---
include/drm/drm_plane.h | 2 +-
include/drm/drm_simple_kms_helper.h | 6 +++---
19 files changed, 22 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
index 2184b8be6fd4..0fe72f46f397 100644
--- a/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
+++ b/drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c
@@ -219,7 +219,7 @@ static const struct drm_simple_display_pipe_funcs
aspeed_gfx_funcs = {
.enable = aspeed_gfx_pipe_enable,
.disable= aspeed_gfx_pipe_disable,
.update = aspeed_gfx_pipe_update,
- .prepare_fb = drm_gem_fb_simple_display_pipe_prepare_fb,
+ .prepare_fb = drm_gem_fb_prepare_fb,
.enable_vblank = aspeed_gfx_enable_vblank,
.disable_vblank = aspeed_gfx_disable_vblank,
};
diff --git a/drivers/gpu/drm/bochs/bochs_kms.c
b/drivers/gpu/drm/bochs/bochs_kms.c
index 02a9c1ed165b..0891640491eb 100644
--- a/drivers/gpu/drm/bochs/bochs_kms.c
+++ b/drivers/gpu/drm/bochs/bochs_kms.c
@@ -69,7 +69,7 @@ static void bochs_pipe_update(struct drm_simple_display_pipe
*pipe,
}
}
-static int bochs_pipe_prepare_fb(struct drm_simple_display_pipe *pipe,
+static int bochs_pipe_prepare_fb(struct drm_plane *plane,
struct drm_plane_state *new_state)
{
struct drm_gem_vram_object *gbo;
@@ -80,7 +80,7 @@ static int bochs_pipe_prepare_fb(struct
drm_simple_display_pipe *pipe,
return drm_gem_vram_pin(gbo, DRM_GEM_VRAM_PL_FLAG_VRAM);
}
-static void bochs_pipe_cleanup_fb(struct drm_simple_display_pipe *pipe,
+static void bochs_pipe_cleanup_fb(struct drm_plane *plane,
struct drm_plane_state *old_state)
{
struct drm_gem_vram_object *gbo;
diff --git a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
index b9bcd310ca2d..c7ea288bef0a 100644
--- a/drivers/gpu/drm/drm_gem_framebuffer_helper.c
+++ b/drivers/gpu/drm/drm_gem_framebuffer_helper.c
@@ -300,25 +300,3 @@ int drm_gem_fb_prepare_fb(struct drm_plane *plane,
return 0;
}
EXPORT_SYMBOL_GPL(drm_gem_fb_prepare_fb);
-
-/**
- * drm_gem_fb_simple_display_pipe_prepare_fb - prepare_fb helper for
- * _simple_display_pipe
- * @pipe: Simple display pipe
- * @plane_state: Plane state
- *
- * This function uses drm_gem_fb_prepare_fb() to extract the exclusive fence
- * from _gem_object.resv and attaches it to plane state for the atomic
- * helper to wait on. This is necessary to correctly implement implicit
- * synchronization for any buffers shared as a struct _buf. Drivers can use
- * this as their _simple_display_pipe_funcs.prepare_fb callback.
- *
- * See drm_atomic_set_fence_for_plane() for a discussion of implicit and
- * explicit fencing in atomic modeset updates.
- */
-int drm_gem_fb_simple_display_pipe_prepare_fb(struct drm_simple_display_pipe
*pipe,
- struct drm_plane_state
*plane_state)
-{
- return drm_gem_fb_prepare_fb(>plane, plane_state);
-}
-EXPORT_SYMBOL(drm_gem_fb_simple_display_pipe_prepare_fb);
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 046055719245..e51f336e67f0 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -173,7 +173,7 @@ static int
[PATCH 0/5] drm/vram: Provide helpers for prepare_fb() and cleanup_fb()
The implementation of the plane's call-back functions prepare_fb() and cleanup_fb() for GEM VRAM helpers are sharable among drivers. The first patch adapts the the interface of simple KSM helpers such that bochs can benefit from the shared code. We add the helper functions in patch #2. Patches #3 to #5 covert several drivers to the new helpers. Patch #4 also fixes two bugs that have been present in hibmc since it was first added. The primary plane's atomic_update() is not responsible for pinning BOs. And it never unpinned unused BOs. VRAM is being exausted over time. The new helpers have been tested to work. The drivers affected by the interface change have been compiled at least. Thomas Zimmermann (5): drm/simple-kms-helper: Pass plane to prepare_fb() and cleanup_fb() drm/vram-helpers: Add helpers for struct drm_plane_helper_funcs drm/bochs: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers drm/hisilicon/hibmc: Use GEM VRAM's prepare_fb() and cleanup_fb() helpers drm/vboxvideo: Replace prepare_fb()/cleanup_fb() with GEM VRAM helpers drivers/gpu/drm/aspeed/aspeed_gfx_crtc.c | 2 +- drivers/gpu/drm/bochs/bochs_kms.c | 26 +- drivers/gpu/drm/drm_gem_framebuffer_helper.c | 22 - drivers/gpu/drm/drm_gem_vram_helper.c | 81 +++ drivers/gpu/drm/drm_simple_kms_helper.c | 4 +- .../gpu/drm/hisilicon/hibmc/hibmc_drm_de.c| 14 +--- drivers/gpu/drm/mcde/mcde_display.c | 2 +- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 2 +- drivers/gpu/drm/pl111/pl111_display.c | 2 +- drivers/gpu/drm/tiny/hx8357d.c| 2 +- drivers/gpu/drm/tiny/ili9225.c| 2 +- drivers/gpu/drm/tiny/ili9341.c| 2 +- drivers/gpu/drm/tiny/mi0283qt.c | 2 +- drivers/gpu/drm/tiny/repaper.c| 2 +- drivers/gpu/drm/tiny/st7586.c | 2 +- drivers/gpu/drm/tiny/st7735r.c| 2 +- drivers/gpu/drm/tve200/tve200_display.c | 2 +- drivers/gpu/drm/vboxvideo/vbox_mode.c | 61 +- drivers/gpu/drm/xen/xen_drm_front_kms.c | 2 +- include/drm/drm_gem_framebuffer_helper.h | 4 +- include/drm/drm_gem_vram_helper.h | 12 +++ include/drm/drm_plane.h | 2 +- include/drm/drm_simple_kms_helper.h | 6 +- 23 files changed, 123 insertions(+), 135 deletions(-) -- 2.23.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v7 3/9] backlight: gpio: explicitly set the direction of the GPIO
On Tue, Oct 22, 2019 at 10:36:24AM +0200, Bartosz Golaszewski wrote:
> From: Bartosz Golaszewski
>
> The GPIO backlight driver currently requests the line 'as is', without
> acively setting its direction. This can lead to problems: if the line
> is in input mode by default, we won't be able to drive it later when
> updating the status and also reading its initial value doesn't make
> sense for backlight setting.
>
> Request the line 'as is' initially, so that we can read its value
> without affecting it but then change the direction to output explicitly
> when setting the initial brightness.
>
> Also: check the current direction and only read the value if it's output.
>
> Signed-off-by: Bartosz Golaszewski
Reviewed-by: Daniel Thompson
> ---
> drivers/video/backlight/gpio_backlight.c | 23 ++-
> 1 file changed, 18 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/video/backlight/gpio_backlight.c
> b/drivers/video/backlight/gpio_backlight.c
> index 3955b513f2f8..52f17c9ca1c3 100644
> --- a/drivers/video/backlight/gpio_backlight.c
> +++ b/drivers/video/backlight/gpio_backlight.c
> @@ -25,9 +25,8 @@ struct gpio_backlight {
> int def_value;
> };
>
> -static int gpio_backlight_update_status(struct backlight_device *bl)
> +static int gpio_backlight_get_next_brightness(struct backlight_device *bl)
> {
> - struct gpio_backlight *gbl = bl_get_data(bl);
> int brightness = bl->props.brightness;
>
> if (bl->props.power != FB_BLANK_UNBLANK ||
> @@ -35,6 +34,14 @@ static int gpio_backlight_update_status(struct
> backlight_device *bl)
> bl->props.state & (BL_CORE_SUSPENDED | BL_CORE_FBBLANK))
> brightness = 0;
>
> + return brightness;
> +}
> +
> +static int gpio_backlight_update_status(struct backlight_device *bl)
> +{
> + struct gpio_backlight *gbl = bl_get_data(bl);
> + int brightness = gpio_backlight_get_next_brightness(bl);
> +
> gpiod_set_value_cansleep(gbl->gpiod, brightness);
>
> return 0;
> @@ -85,7 +92,8 @@ static int gpio_backlight_initial_power_state(struct
> gpio_backlight *gbl)
> return gbl->def_value ? FB_BLANK_UNBLANK : FB_BLANK_POWERDOWN;
>
> /* if the enable GPIO is disabled, do not enable the backlight */
> - if (gpiod_get_value_cansleep(gbl->gpiod) == 0)
> + if (gpiod_get_direction(gbl->gpiod) == 0 &&
> + gpiod_get_value_cansleep(gbl->gpiod) == 0)
> return FB_BLANK_POWERDOWN;
>
> return FB_BLANK_UNBLANK;
> @@ -98,7 +106,7 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> struct backlight_properties props;
> struct backlight_device *bl;
> struct gpio_backlight *gbl;
> - int ret;
> + int ret, init_brightness;
>
> gbl = devm_kzalloc(>dev, sizeof(*gbl), GFP_KERNEL);
> if (gbl == NULL)
> @@ -151,7 +159,12 @@ static int gpio_backlight_probe(struct platform_device
> *pdev)
> bl->props.power = gpio_backlight_initial_power_state(gbl);
> bl->props.brightness = 1;
>
> - backlight_update_status(bl);
> + init_brightness = gpio_backlight_get_next_brightness(bl);
> + ret = gpiod_direction_output(gbl->gpiod, init_brightness);
> + if (ret) {
> + dev_err(>dev, "failed to set initial brightness\n");
> + return ret;
> + }
>
> platform_set_drvdata(pdev, bl);
> return 0;
> --
> 2.23.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
