dri-devel@lists.freedesktop.org
tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.21-wip
head: 364c6471cc8cca8dbaa558077597c525b3d7f9e6
commit: 2c5acb77e1ad3dfa5658f6c8b769e264b53728b4 [79/110] drm/amdgpu: Add sysfs
file for PCIe usage v5
New smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:2138 amdgpu_pm_sysfs_init() warn: maybe
use && instead of &
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:2138 amdgpu_pm_sysfs_init() warn:
bitwise AND condition is false here
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:2184 amdgpu_pm_sysfs_fini() warn: maybe
use && instead of &
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:2184 amdgpu_pm_sysfs_fini() warn:
bitwise AND condition is false here
Old smatch warnings:
drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c:593 amdgpu_set_pp_od_clk_voltage()
error: uninitialized symbol 'ret'.
git remote add radeon-alex git://people.freedesktop.org/~agd5f/linux.git
git remote update radeon-alex
git checkout 2c5acb77e1ad3dfa5658f6c8b769e264b53728b4
vim +2138 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c
d38ceaf99 Alex Deucher 2015-04-20 2034
d38ceaf99 Alex Deucher 2015-04-20 2035 int amdgpu_pm_sysfs_init(struct
amdgpu_device *adev)
d38ceaf99 Alex Deucher 2015-04-20 2036 {
0624e145f Evan Quan2019-01-07 2037 struct pp_hwmgr *hwmgr =
adev->powerplay.pp_handle;
d38ceaf99 Alex Deucher 2015-04-20 2038 int ret;
d38ceaf99 Alex Deucher 2015-04-20 2039
c86f5ebfb Alex Deucher 2015-10-23 2040 if (adev->pm.sysfs_initialized)
c86f5ebfb Alex Deucher 2015-10-23 2041 return 0;
c86f5ebfb Alex Deucher 2015-10-23 2042
d2f52ac80 Rex Zhu 2017-09-22 2043 if (adev->pm.dpm_enabled == 0)
d2f52ac80 Rex Zhu 2017-09-22 2044 return 0;
d2f52ac80 Rex Zhu 2017-09-22 2045
d38ceaf99 Alex Deucher 2015-04-20 2046 adev->pm.int_hwmon_dev =
hwmon_device_register_with_groups(adev->dev,
d38ceaf99 Alex Deucher 2015-04-20 2047
DRIVER_NAME, adev,
d38ceaf99 Alex Deucher 2015-04-20 2048
hwmon_groups);
d38ceaf99 Alex Deucher 2015-04-20 2049 if
(IS_ERR(adev->pm.int_hwmon_dev)) {
d38ceaf99 Alex Deucher 2015-04-20 2050 ret =
PTR_ERR(adev->pm.int_hwmon_dev);
d38ceaf99 Alex Deucher 2015-04-20 2051 dev_err(adev->dev,
d38ceaf99 Alex Deucher 2015-04-20 2052 "Unable to
register hwmon device: %d\n", ret);
d38ceaf99 Alex Deucher 2015-04-20 2053 return ret;
d38ceaf99 Alex Deucher 2015-04-20 2054 }
d38ceaf99 Alex Deucher 2015-04-20 2055
d38ceaf99 Alex Deucher 2015-04-20 2056 ret =
device_create_file(adev->dev, &dev_attr_power_dpm_state);
d38ceaf99 Alex Deucher 2015-04-20 2057 if (ret) {
d38ceaf99 Alex Deucher 2015-04-20 2058 DRM_ERROR("failed to
create device file for dpm state\n");
d38ceaf99 Alex Deucher 2015-04-20 2059 return ret;
d38ceaf99 Alex Deucher 2015-04-20 2060 }
d38ceaf99 Alex Deucher 2015-04-20 2061 ret =
device_create_file(adev->dev, &dev_attr_power_dpm_force_performance_level);
d38ceaf99 Alex Deucher 2015-04-20 2062 if (ret) {
d38ceaf99 Alex Deucher 2015-04-20 2063 DRM_ERROR("failed to
create device file for dpm state\n");
d38ceaf99 Alex Deucher 2015-04-20 2064 return ret;
d38ceaf99 Alex Deucher 2015-04-20 2065 }
f3898ea12 Eric Huang 2015-12-11 2066
6d07fe7bc Rex Zhu 2017-09-25 2067
f3898ea12 Eric Huang 2015-12-11 2068 ret =
device_create_file(adev->dev, &dev_attr_pp_num_states);
f3898ea12 Eric Huang 2015-12-11 2069 if (ret) {
f3898ea12 Eric Huang 2015-12-11 2070 DRM_ERROR("failed to
create device file pp_num_states\n");
f3898ea12 Eric Huang 2015-12-11 2071 return ret;
f3898ea12 Eric Huang 2015-12-11 2072 }
f3898ea12 Eric Huang 2015-12-11 2073 ret =
device_create_file(adev->dev, &dev_attr_pp_cur_state);
f3898ea12 Eric Huang 2015-12-11 2074 if (ret) {
f3898ea12 Eric Huang 2015-12-11 2075 DRM_ERROR("failed to
create device file pp_cur_state\n");
f3898ea12 Eric Huang 2015-12-11 2076 return ret;
f3898ea12 Eric Huang 2015-12-11 2077 }
f3898ea12 Eric Huang 2015-12-11 2078 ret =
device_create_file(adev->dev, &dev_attr_pp_force_state);
f3898ea12 Eric Huang 2015-12-11 2079 if (ret) {
f3898ea12 Eric Huang 2015-12-11 2080 DRM_ERROR("failed to
create device file pp_force_state\n");
f3898ea12 Eric Huang 2015-12-11 2081 return ret;
f3898ea12 Eric Huang 2015-12-11 2082 }
f3898ea12 Eric Huang 2015-12-11 2083 ret =
device_create_file(adev->dev, &dev_attr_pp_table);
f3898ea12 Eric Huang 2015-12-11 2084 if (ret) {
f3898ea12 Eric Huang 2015-12-11 2085
Re: [PATCH] MAINTAINERS: unify reference to xen-devel list
On 12/01/2019 10:07, Lukas Bulwahn wrote: > In the linux kernel MAINTAINERS file, largely > "xen-de...@lists.xenproject.org (moderated for non-subscribers)" > is used to refer to the xen-devel mailing list. > > The DRM DRIVERS FOR XEN section entry mentions > xen-de...@lists.xen.org instead, but that is just the same > mailing list as the mailing list above. > > Signed-off-by: Lukas Bulwahn Reviewed-by: Juergen Gross Juergen ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #3 from Rafał Miłecki --- This problem also occurs when using drm/drm branch drm-next (5.0.0-rc1) with: [PATCH v7 00/20] MST refcounting/atomic helpers cleanup on top of it. The only difference I've noticed is xrandr complaining about MIT-MAGIC-COOKIE-1: > xrandr Invalid MIT-MAGIC-COOKIE-1 keyxrandr: Output DisplayPort-0 is not disconnected but has no modes Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 16384 x 16384 eDP connected primary 1920x1080+0+0 (normal left inverted right x axis y axis) 309mm x 174mm 1920x1080 60.02*+ 40.00 1680x1050 60.02 1280x1024 60.02 1440x900 60.02 1280x800 60.02 1280x720 60.02 1024x768 60.02 800x600 60.02 640x480 60.02 DisplayPort-0 connected (normal left inverted right x axis y axis) DisplayPort-1 disconnected (normal left inverted right x axis y axis) DisplayPort-2 disconnected (normal left inverted right x axis y axis) DisplayPort-3 disconnected (normal left inverted right x axis y axis) DisplayPort-4 disconnected (normal left inverted right x axis y axis) DisplayPort-5 disconnected (normal left inverted right x axis y axis) -- 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
[PATCH] drm: drop DRM_AUTH requirement from AUTH_MAGIC ioctl
From: Emil Velikov
Currently only an authenticated master can authenticate another client.
In practise the client can only be master if CAP_SYS_ADMIN is present,
although having the CAP also sets the client as authenticated.
Thus DRM_AUTH in AUTH_MAGIC's "DRM_AUTH | DRM_MASTER" is superfluous.
Notices while working on IGT tests.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_ioctl.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index b07c3d147c29..dae841b07365 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -582,7 +582,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_invalid_op,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
- DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
DRM_AUTH|DRM_UNLOCKED|DRM_MASTER),
+ DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
DRM_UNLOCKED|DRM_MASTER),
DRM_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl,
DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
DRM_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl, DRM_AUTH),
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: factor out drm_close_helper() function
From: Emil Velikov
Will be used to plug an existing memory leak.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index ffa8dc35515f..149506a20bdc 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -262,6 +262,18 @@ void drm_file_free(struct drm_file *file)
kfree(file);
}
+static void drm_close_helper(struct file *filp)
+{
+ struct drm_file *file_priv = filp->private_data;
+ struct drm_device *dev = file_priv->minor->dev;
+
+ mutex_lock(&dev->filelist_mutex);
+ list_del(&file_priv->lhead);
+ mutex_unlock(&dev->filelist_mutex);
+
+ drm_file_free(file_priv);
+}
+
static int drm_setup(struct drm_device * dev)
{
int ret;
@@ -473,11 +485,7 @@ int drm_release(struct inode *inode, struct file *filp)
DRM_DEBUG("open_count = %d\n", dev->open_count);
- mutex_lock(&dev->filelist_mutex);
- list_del(&file_priv->lhead);
- mutex_unlock(&dev->filelist_mutex);
-
- drm_file_free(file_priv);
+ drm_close_helper(filp);
if (!--dev->open_count) {
drm_lastclose(dev);
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: plug memory leak on drm_setup() failure
From: Emil Velikov
Currently we fail to free and detach the drm_file when drm_setup() fails.
Use the drm_close_helper to do address that.
Signed-off-by: Emil Velikov
---
drivers/gpu/drm/drm_file.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
index 149506a20bdc..871dcd8c7545 100644
--- a/drivers/gpu/drm/drm_file.c
+++ b/drivers/gpu/drm/drm_file.c
@@ -330,8 +330,10 @@ int drm_open(struct inode *inode, struct file *filp)
goto err_undo;
if (need_setup) {
retcode = drm_setup(dev);
- if (retcode)
+ if (retcode) {
+ drm_close_helper(filp);
goto err_undo;
+ }
}
return 0;
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/2] drm: annotate drm_core_check_feature() dev arg. as const
From: Emil Velikov
This static inline function doesn't modify any state.
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
Reviewed-by: Daniel Vetter
---
include/drm/drm_drv.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 3199ef70c007..211d2bfd0b94 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -658,7 +658,7 @@ static inline bool drm_dev_is_unplugged(struct drm_device
*dev)
*
* Returns true if the @feature is supported, false otherwise.
*/
-static inline bool drm_core_check_feature(struct drm_device *dev, u32 feature)
+static inline bool drm_core_check_feature(const struct drm_device *dev, u32
feature)
{
return dev->driver->driver_features & dev->driver_features & feature;
}
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 2/2] drm: allow render capable master with DRM_AUTH ioctls
From: Emil Velikov
There are cases (in mesa and applications) where one would open the
primary node without properly authenticating the client.
Sometimes we don't check if the authentication succeeds, but there's
also cases we simply forget to do it.
The former was a case for Mesa where it did not not check the return
value of drmGetMagic() [1]. That was fixed recently although, there's
the question of older drivers or other apps that exbibit this behaviour.
While omitting the call results in issues as seen in [2] and [3].
In the libva case, libva itself doesn't authenticate the DRM client and
the vaGetDisplayDRM documentation doesn't mention if the app should
either.
As of today, the official vainfo utility doesn't authenticate.
To workaround issues like these, some users resort to running their apps
under sudo. Which admittedly isn't always a good idea.
Since any DRIVER_RENDER driver has sufficient isolation between clients,
we can use that, for unauthenticated [primary node] ioctls that require
DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW.
v2:
- Rework/simplify if check (Daniel V)
- Add examples to commit messages, elaborate. (Daniel V)
[1]
https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136
[2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html
[3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1
Testcase: igt/core_unauth_vs_render
Cc: intel-...@lists.freedesktop.org
Signed-off-by: Emil Velikov
---
Daniel, the if conditionals did not work exactly as you put them.
This is the closest thing that I can think of.
---
drivers/gpu/drm/drm_ioctl.c | 20
1 file changed, 16 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 94bd872d56c4..08a0b4cc3a76 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -507,6 +507,13 @@ int drm_version(struct drm_device *dev, void *data,
return err;
}
+static inline bool
+drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags)
+{
+ return drm_core_check_feature(dev, DRIVER_RENDER) &&
+ (flags & DRM_RENDER_ALLOW);
+}
+
/**
* drm_ioctl_permit - Check ioctl permissions against caller
*
@@ -521,14 +528,19 @@ int drm_version(struct drm_device *dev, void *data,
*/
int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
{
+ const struct drm_device *dev = file_priv->minor->dev;
+
/* ROOT_ONLY is only for CAP_SYS_ADMIN */
if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)))
return -EACCES;
- /* AUTH is only for authenticated or render client */
- if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) &&
-!file_priv->authenticated))
- return -EACCES;
+ /* AUTH is only for master ... */
+ if ((flags & DRM_AUTH) && drm_is_primary_client(file_priv)) {
+ /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */
+ if (unlikely(!file_priv->authenticated) &&
+ unlikely(!drm_render_driver_and_ioctl(dev, flags)))
+ return -EACCES;
+ }
/* MASTER is only for master or control clients */
if (unlikely((flags & DRM_MASTER) &&
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Sat, Jan 12, 2019 at 01:03:05PM -0600, Shiraz Saleem wrote: > Well I was trying convert the RDMA drivers to use your new iterator variant > and saw the need for it in locations where we need virtual address of the > pages > contained in the SGEs. As far as i can tell that pg_arr[i] value is only ever used for the case where we do an explicit dma coherent allocation, so you should not have to fill it out at all. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] lib/scatterlist: Provide a DMA page iterator
On Thu, Jan 10, 2019 at 04:42:18PM -0700, Jason Gunthorpe wrote: > > Changes since the RFC: > > - Rework vmwgfx too [CH] > > - Use a distinct type for the DMA page iterator [CH] > > - Do not have a #ifdef [CH] > > ChristophH: Will you ack? This looks generally fine. > > Are you still OK with the vmwgfx reworking, or should we go back to > the original version that didn't have the type safety so this driver > can be left broken? I think the map method in vmgfx that just does virt_to_phys is pretty broken. Thomas, can you check if you see any performance difference with just doing the proper dma mapping, as that gets the driver out of interface abuse land? While we're at it I think we need to merge my series in this area for 5.0, because without that the driver is already broken. Where should we merge it? ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/drm_vblank: Change EINVAL by the correct errno
Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira: > Hi, > > I resend this patch for CI via “intel-...@lists.freedesktop.org” as > Daniel suggested, and I got a feedback that reported an issue as can be > seen here: > >https://patchwork.freedesktop.org/series/51147/ > > After a careful analysis of what happened, I concluded that the problem > is related to the function “igt_wait_for_vblank_count()” in “igt_kms.c”. > This function has the following assert: > >igt_assert(drmWaitVBlank(drm_fd, &wait_vbl) == 0) > > This function only checks if everything went well with the > drmWaitVBlank() operation and does not make any other validation. IMHO > the patch is correct, and the problem pointed out by CI is not related > to this change. Hey, Thanks for finding the root cause. Before upstreaming can you send a fix for i-g-t so we don't lose CI coverage after changing the behavior? ~Maarten ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108592] [CI][DRMTIP] igt@gem_exec_whisper@normal - timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108592 Chris Wilson changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED QA Contact|intel-gfx-bugs@lists.freede | |sktop.org | Component|DRM/Intel |IGT Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop |sktop.org |.org --- Comment #2 from Chris Wilson --- commit d9cd03c887a5f46bc002280d70a6716bb2bf8d43 (upstream/master, origin/master, origin/HEAD) Author: Chris Wilson Date: Mon Jan 14 09:13:54 2019 + i915/gem_exec_whisper: Limit to a maximum of 150s Each individual pass is as effective at spotting an error using the Chinese whisper as any other, so the effectiveness of adding more passes rapidly diminishes. To keep the tests bounded within time, limit a subtest to a mere 150s! Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108592 Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin -- 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 v4 3/8] drm/stm: prepare for drmP.h removal from drm_modeset_helper.h
Le sam. 12 janv. 2019 à 20:33, Sam Ravnborg a écrit : > > The use of drmP.h is discouraged and removal of it from > drm_modeset_helper.h caused drm/stm to fail to build. > > This patch introduce the necessary fixes to prepare for the > drmP.h removal from drm_modeset_helper.h. > > Build tested on arm and x86 allmodconfig > Acked-by: Benjamin Gaignard > Signed-off-by: Sam Ravnborg > Cc: Yannick Fertre > Cc: Philippe Cornu > Cc: Benjamin Gaignard > Cc: Vincent Abriou > Cc: David Airlie > Cc: Daniel Vetter > --- > drivers/gpu/drm/stm/drv.c | 4 > drivers/gpu/drm/stm/ltdc.c | 7 +++ > 2 files changed, 11 insertions(+) > > diff --git a/drivers/gpu/drm/stm/drv.c b/drivers/gpu/drm/stm/drv.c > index 8dec001b9d37..58bf8bae789c 100644 > --- a/drivers/gpu/drm/stm/drv.c > +++ b/drivers/gpu/drm/stm/drv.c > @@ -9,15 +9,19 @@ > */ > > #include > +#include > +#include > #include > > #include > #include > #include > +#include > #include > #include > #include > #include > +#include > > #include "ltdc.h" > > diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c > index 61dd661aa0ac..de29f4713140 100644 > --- a/drivers/gpu/drm/stm/ltdc.c > +++ b/drivers/gpu/drm/stm/ltdc.c > @@ -10,18 +10,25 @@ > > #include > #include > +#include > +#include > +#include > #include > #include > +#include > #include > > #include > #include > #include > +#include > #include > +#include > #include > #include > #include > #include > +#include > > #include > > -- > 2.12.0 > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND] MAINTAINERS: Add entry for VKMS
On Sun, Jan 13, 2019 at 06:40:38PM -0200, Rodrigo Siqueira wrote: > Add maintainers and reviewers for VKMS driver > > Signed-off-by: Rodrigo Siqueira Reviewed-by: Daniel Vetter Since you have commit rights for drm-misc already I think best if you push this yourself using the dim tooling: https://drm.pages.freedesktop.org/maintainer-tools/getting-started.html Cheers, Daniel > --- > Changes in v2: > - Insert the section in alphabetical order > > Resend: > - Update patch due to changes in MAINTAINER file > > MAINTAINERS | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/MAINTAINERS b/MAINTAINERS > index 163c8f76a1c8..6e1cef2f21d9 100644 > --- a/MAINTAINERS > +++ b/MAINTAINERS > @@ -4925,6 +4925,16 @@ S: Odd Fixes > F: drivers/gpu/drm/udl/ > T: git git://anongit.freedesktop.org/drm/drm-misc > > +DRM DRIVER FOR VIRTUAL KERNEL MODESETTING (VKMS) > +M: Rodrigo Siqueira > +R: Haneen Mohammed > +R: Daniel Vetter > +T: git git://anongit.freedesktop.org/drm/drm-misc > +S: Maintained > +L: dri-devel@lists.freedesktop.org > +F: drivers/gpu/drm/vkms/ > +F: Documentation/gpu/vkms.rst > + > DRM DRIVER FOR VMWARE VIRTUAL GPU > M: "VMware Graphics" > M: Thomas Hellstrom > -- > 2.20.1 -- 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 v4 8/8] drm: remove drmP.h from drm_modeset_helper.h
On Sat, Jan 12, 2019 at 08:32:51PM +0100, Sam Ravnborg wrote: > With the removal of drmP.h from drm_modeset_helper.h > the drmP.h are no longer included by any include files > in include/drm. > The drmP.h file is thus only included explicit > either in .c files or in local .h files. > This makes the process of deleting the drmP.h includes easier > as we have a more local dependency chain. > > Include build failures fixes in drm files after the drmP.h removal. > > Signed-off-by: Sam Ravnborg > Cc: Maarten Lankhorst > Cc: Maxime Ripard > Cc: Sean Paul > Cc: David Airlie > Cc: Daniel Vetter Note that as soon as drm-intel-next lands in drm-misc-next this won't be enough. I have a patch which I think toghether with yours here should take care of things though. I merged the first 2 patches, I'll wait with the driver ones for a few more acks first. Thanks for respinning. -Daniel > --- > drivers/gpu/drm/drm_damage_helper.c | 1 + > drivers/gpu/drm/drm_modeset_helper.c | 2 ++ > include/drm/drm_modeset_helper.h | 6 +- > 3 files changed, 8 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_damage_helper.c > b/drivers/gpu/drm/drm_damage_helper.c > index 31032407254d..b575a768f51c 100644 > --- a/drivers/gpu/drm/drm_damage_helper.c > +++ b/drivers/gpu/drm/drm_damage_helper.c > @@ -32,6 +32,7 @@ > > #include > #include > +#include > > /** > * DOC: overview > diff --git a/drivers/gpu/drm/drm_modeset_helper.c > b/drivers/gpu/drm/drm_modeset_helper.c > index 9150fa385bba..9bc1ef788c77 100644 > --- a/drivers/gpu/drm/drm_modeset_helper.c > +++ b/drivers/gpu/drm/drm_modeset_helper.c > @@ -23,8 +23,10 @@ > #include > #include > #include > +#include > #include > #include > +#include > > /** > * DOC: aux kms helpers > diff --git a/include/drm/drm_modeset_helper.h > b/include/drm/drm_modeset_helper.h > index efa337f03129..995fd981cab0 100644 > --- a/include/drm/drm_modeset_helper.h > +++ b/include/drm/drm_modeset_helper.h > @@ -23,7 +23,11 @@ > #ifndef __DRM_KMS_HELPER_H__ > #define __DRM_KMS_HELPER_H__ > > -#include > +struct drm_crtc; > +struct drm_crtc_funcs; > +struct drm_device; > +struct drm_framebuffer; > +struct drm_mode_fb_cmd2; > > void drm_helper_move_panel_connectors_to_head(struct drm_device *); > > -- > 2.12.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 3/4] drm/rockchip: add missing of_node_put
On Sun, Jan 13, 2019 at 07:48:49PM +0100, Heiko Stuebner wrote:
> Am Sonntag, 13. Januar 2019, 09:47:43 CET schrieb Julia Lawall:
> > The device node iterators perform an of_node_get on each iteration, so a
> > jump out of the loop requires an of_node_put.
> >
> > The semantic patch that fixes this problem is as follows
> > (http://coccinelle.lip6.fr):
> >
> > //
> > @@
> > expression root,e;
> > local idexpression child;
> > iterator name for_each_child_of_node;
> > @@
> >
> > for_each_child_of_node(root, child) {
> >... when != of_node_put(child)
> >when != e = child
> > + of_node_put(child);
> > ? break;
> >...
> > }
> > ... when != child
> > //
> >
> > Signed-off-by: Julia Lawall
>
> I've added a fixes+stable tag and applied it to drm-misc-fixes
All of them or just this one here? These cleanup patches have a high
chance of falling through cracks, so taking them all usually works out
better ...
-Daniel
>
> Thanks for catching that
> Heiko
>
>
--
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] drm: drop DRM_AUTH requirement from AUTH_MAGIC ioctl
On Mon, Jan 14, 2019 at 08:43:05AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently only an authenticated master can authenticate another client.
>
> In practise the client can only be master if CAP_SYS_ADMIN is present,
> although having the CAP also sets the client as authenticated.
>
> Thus DRM_AUTH in AUTH_MAGIC's "DRM_AUTH | DRM_MASTER" is superfluous.
>
> Notices while working on IGT tests.
>
> Signed-off-by: Emil Velikov
Yup, drm_new_set_master guarantees that any master (whether the current
one or inactive master) is authenticated. So active master implies
authenticated.
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index b07c3d147c29..dae841b07365 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -582,7 +582,7 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
> DRM_IOCTL_DEF(DRM_IOCTL_SET_UNIQUE, drm_invalid_op,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF(DRM_IOCTL_BLOCK, drm_noop,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF(DRM_IOCTL_UNBLOCK, drm_noop,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> - DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
> DRM_AUTH|DRM_UNLOCKED|DRM_MASTER),
> + DRM_IOCTL_DEF(DRM_IOCTL_AUTH_MAGIC, drm_authmagic,
> DRM_UNLOCKED|DRM_MASTER),
>
> DRM_IOCTL_DEF(DRM_IOCTL_ADD_MAP, drm_legacy_addmap_ioctl,
> DRM_AUTH|DRM_MASTER|DRM_ROOT_ONLY),
> DRM_IOCTL_DEF(DRM_IOCTL_RM_MAP, drm_legacy_rmmap_ioctl, DRM_AUTH),
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 3/4] drm/rockchip: add missing of_node_put
Am Montag, 14. Januar 2019, 11:05:56 CET schrieb Daniel Vetter:
> On Sun, Jan 13, 2019 at 07:48:49PM +0100, Heiko Stuebner wrote:
> > Am Sonntag, 13. Januar 2019, 09:47:43 CET schrieb Julia Lawall:
> > > The device node iterators perform an of_node_get on each iteration, so a
> > > jump out of the loop requires an of_node_put.
> > >
> > > The semantic patch that fixes this problem is as follows
> > > (http://coccinelle.lip6.fr):
> > >
> > > //
> > > @@
> > > expression root,e;
> > > local idexpression child;
> > > iterator name for_each_child_of_node;
> > > @@
> > >
> > > for_each_child_of_node(root, child) {
> > >... when != of_node_put(child)
> > >when != e = child
> > > + of_node_put(child);
> > > ? break;
> > >...
> > > }
> > > ... when != child
> > > //
> > >
> > > Signed-off-by: Julia Lawall
> >
> > I've added a fixes+stable tag and applied it to drm-misc-fixes
>
> All of them or just this one here? These cleanup patches have a high
> chance of falling through cracks, so taking them all usually works out
> better ...
That is the only one I got, so right now I only applied this one in my inbox.
Weekend and such resulted in me not going looking for other ones.
Heiko
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm: plug memory leak on drm_setup() failure
On Mon, Jan 14, 2019 at 08:44:10AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> Currently we fail to free and detach the drm_file when drm_setup() fails.
> Use the drm_close_helper to do address that.
>
> Signed-off-by: Emil Velikov
> ---
> drivers/gpu/drm/drm_file.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_file.c b/drivers/gpu/drm/drm_file.c
> index 149506a20bdc..871dcd8c7545 100644
> --- a/drivers/gpu/drm/drm_file.c
> +++ b/drivers/gpu/drm/drm_file.c
> @@ -330,8 +330,10 @@ int drm_open(struct inode *inode, struct file *filp)
> goto err_undo;
> if (need_setup) {
> retcode = drm_setup(dev);
> - if (retcode)
> + if (retcode) {
> + drm_close_helper(filp);
I freaked out mildly because drm_open_helper already adds the drm_file to
the filelist (hence publishes it), and publishing objects before they're
fully set up is a Bad Idea :-)
But drm_setup only does legacy setup, so who cares. On both patches:
Reviewed-by: Daniel Vetter
And if you feel like doing an s/drm_setup()/drm_legacy_setup()/, with or
w/o changing the condition to if (need_setup &&
drm_core_check_feature(dev, DRIVER_LEGACY)), then that patch would also
have my
Reviewed-by: Daniel Vetter
> goto err_undo;
> + }
> }
> return 0;
>
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 v2 2/2] drm: allow render capable master with DRM_AUTH ioctls
On Mon, Jan 14, 2019 at 08:54:08AM +, Emil Velikov wrote:
> From: Emil Velikov
>
> There are cases (in mesa and applications) where one would open the
> primary node without properly authenticating the client.
>
> Sometimes we don't check if the authentication succeeds, but there's
> also cases we simply forget to do it.
>
> The former was a case for Mesa where it did not not check the return
> value of drmGetMagic() [1]. That was fixed recently although, there's
> the question of older drivers or other apps that exbibit this behaviour.
>
> While omitting the call results in issues as seen in [2] and [3].
>
> In the libva case, libva itself doesn't authenticate the DRM client and
> the vaGetDisplayDRM documentation doesn't mention if the app should
> either.
>
> As of today, the official vainfo utility doesn't authenticate.
>
> To workaround issues like these, some users resort to running their apps
> under sudo. Which admittedly isn't always a good idea.
>
> Since any DRIVER_RENDER driver has sufficient isolation between clients,
> we can use that, for unauthenticated [primary node] ioctls that require
> DRM_AUTH. But only if the respective ioctl is tagged as DRM_RENDER_ALLOW.
>
> v2:
> - Rework/simplify if check (Daniel V)
> - Add examples to commit messages, elaborate. (Daniel V)
>
> [1]
> https://gitlab.freedesktop.org/mesa/mesa/blob/2bc1f5c2e70fe3b4d41f060af9859bc2a94c5b62/src/egl/drivers/dri2/platform_wayland.c#L1136
> [2] https://lists.freedesktop.org/archives/libva/2016-July/004185.html
> [3] https://gitlab.freedesktop.org/mesa/kmscube/issues/1
> Testcase: igt/core_unauth_vs_render
> Cc: intel-...@lists.freedesktop.org
> Signed-off-by: Emil Velikov
> ---
> Daniel, the if conditionals did not work exactly as you put them.
> This is the closest thing that I can think of.
> ---
> drivers/gpu/drm/drm_ioctl.c | 20
> 1 file changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 94bd872d56c4..08a0b4cc3a76 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -507,6 +507,13 @@ int drm_version(struct drm_device *dev, void *data,
> return err;
> }
>
> +static inline bool
> +drm_render_driver_and_ioctl(const struct drm_device *dev, u32 flags)
> +{
> + return drm_core_check_feature(dev, DRIVER_RENDER) &&
> + (flags & DRM_RENDER_ALLOW);
> +}
> +
> /**
> * drm_ioctl_permit - Check ioctl permissions against caller
> *
> @@ -521,14 +528,19 @@ int drm_version(struct drm_device *dev, void *data,
> */
> int drm_ioctl_permit(u32 flags, struct drm_file *file_priv)
> {
> + const struct drm_device *dev = file_priv->minor->dev;
> +
> /* ROOT_ONLY is only for CAP_SYS_ADMIN */
> if (unlikely((flags & DRM_ROOT_ONLY) && !capable(CAP_SYS_ADMIN)))
> return -EACCES;
>
> - /* AUTH is only for authenticated or render client */
> - if (unlikely((flags & DRM_AUTH) && !drm_is_render_client(file_priv) &&
> - !file_priv->authenticated))
> - return -EACCES;
> + /* AUTH is only for master ... */
> + if ((flags & DRM_AUTH) && drm_is_primary_client(file_priv)) {
> + /* authenticated ones, or render capable on DRM_RENDER_ALLOW. */
> + if (unlikely(!file_priv->authenticated) &&
> + unlikely(!drm_render_driver_and_ioctl(dev, flags)))
The double-unlikely looks a bit strange, I'd move it out so there's only
one. But this is correct too (because unlikely() && unlikely == unlikely(
&& )). Either way:
Reviewed-by: Daniel Vetter
> + return -EACCES;
> + }
>
> /* MASTER is only for master or control clients */
> if (unlikely((flags & DRM_MASTER) &&
> --
> 2.20.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 v2] drm/drm_vblank: Change EINVAL by the correct errno
On 01/14, Maarten Lankhorst wrote: > Op 13-01-2019 om 21:23 schreef Rodrigo Siqueira: > > Hi, > > > > I resend this patch for CI via “intel-...@lists.freedesktop.org” as > > Daniel suggested, and I got a feedback that reported an issue as can be > > seen here: > > > >https://patchwork.freedesktop.org/series/51147/ > > > > After a careful analysis of what happened, I concluded that the problem > > is related to the function “igt_wait_for_vblank_count()” in “igt_kms.c”. > > This function has the following assert: > > > >igt_assert(drmWaitVBlank(drm_fd, &wait_vbl) == 0) > > > > This function only checks if everything went well with the > > drmWaitVBlank() operation and does not make any other validation. IMHO > > the patch is correct, and the problem pointed out by CI is not related > > to this change. > > Hey, Hi, Thanks for the feedback :) > Thanks for finding the root cause. Before upstreaming can you send a fix for > i-g-t so we don't lose CI coverage after changing the behavior? I'm just confused on my next step, should I fix the IGT test and then resend the patch? Additionally, I noticed that tests related to vblank wait have others issues as I pointed out here (see my last message): https://patchwork.freedesktop.org/patch/245784/ Is it enough if I handling EINVAL and EOPNOTSUPP in the tests? I'm afraid, that the tests will still fail if I consider these two case; however, I suppose that handling only EOPNOTSUPP can fix the problem, but I'm not sure if it is the best solution. Best Regards > ~Maarten > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #4 from Michel Dänzer --- Please attach the corresponding Xorg log file, preferably captured after reproducing the problem. -- 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 109345] drm-next-2018-12-14 -Linux PPC
https://bugs.freedesktop.org/show_bug.cgi?id=109345 --- Comment #1 from Michel Dänzer --- Please attach the output of dmesg corresponding to the problem. Somebody will probably need to isolate the exact commit which introduced the problem using git bisect. -- 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
[PATCH] drm/etnaviv: NULL vs IS_ERR() buf in etnaviv_core_dump()
The etnaviv_gem_get_pages() never returns NULL. It returns error
pointers on error.
Fixes: a8c21a5451d8 ("drm/etnaviv: add initial etnaviv DRM driver")
Signed-off-by: Dan Carpenter
---
drivers/gpu/drm/etnaviv/etnaviv_dump.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
index 3fbb4855396c..33854c94cb85 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_dump.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_dump.c
@@ -215,7 +215,7 @@ void etnaviv_core_dump(struct etnaviv_gpu *gpu)
mutex_lock(&obj->lock);
pages = etnaviv_gem_get_pages(obj);
mutex_unlock(&obj->lock);
- if (pages) {
+ if (!IS_ERR(pages)) {
int j;
iter.hdr->data[0] = bomap - bomap_start;
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109234] amdgpu random hangs with 5.0-rc2/4.21+
https://bugs.freedesktop.org/show_bug.cgi?id=109234 --- Comment #16 from Sibren Vasse --- @bmilreu: No, Michel beat me to it. See thread here: https://lists.linuxfoundation.org/pipermail/iommu/2019-January/032528.html -- 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 106470] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugs.freedesktop.org/show_bug.cgi?id=106470 --- Comment #2 from Hans de Goede --- Hi Dominik, I found this bug using google since I was checking to see if your DMI BIOS version is unique :) Given that you've filed: https://bugzilla.redhat.com/show_bug.cgi?id=1601623 Now, I guess this bug is fixed with recent kernels and can be closed? Regards, Hans -- 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 109332] xf86-video-amdgpu - commit 0d60233d introduced stuttering with mouse cursor operations
https://bugs.freedesktop.org/show_bug.cgi?id=109332 Michel Dänzer changed: What|Removed |Added QA Contact|xorg-t...@lists.x.org | Component|Driver/AMDgpu |DRM/AMDgpu Assignee|xorg-driver-...@lists.x.org |dri-devel@lists.freedesktop ||.org Version|git |unspecified CC||harry.wentl...@amd.com, ||nicholas.kazlaus...@amd.com Product|xorg|DRI --- Comment #1 from Michel Dänzer --- Still a DC issue. This is perfectly normal usage of the cursor UAPI, Wayland compositors such as gnome-shell use it similarly. -- 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 106175] amdgpu.dc=1 shows performance issues with Xorg compositors when moving windows
https://bugs.freedesktop.org/show_bug.cgi?id=106175 --- Comment #94 from Michel Dänzer --- (In reply to tempel.julian from comment #88) > (TearFree however doesn't work well in general without amdgpu.dc=1). Can you elaborate on that? Maybe file another report on it. -- 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 106470] [gma500] BUG: unable to handle kernel NULL pointer dereference at 0000000000000081
https://bugs.freedesktop.org/show_bug.cgi?id=106470 Dominik 'Rathann' Mierzejewski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Dominik 'Rathann' Mierzejewski --- Yes, let's close this. I don't know which version has the fix though. -- 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 01/49] drm/atomic: Constify mode argument to mode_valid_path()
On 11/01/19 05:50, Laurent Pinchart wrote: > The mode_valid_path() function validates the mode it receives without > ever modifying it. Constify the mode pointer argument to make that > explicit. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_atomic_helper.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109315] [CI] igt@amdgpu/* - skip - Test requirement: fd >= 0, Last errno: 2, No such file or directory / Test requirement: err == 0 Last errno: 9, Bad file descriptor
https://bugs.freedesktop.org/show_bug.cgi?id=109315 Chris Wilson changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #2 from Chris Wilson --- commit c3aef507e1dfe1e483787d501e9907dab67f6bca (HEAD, upstream/master) Author: Chris Wilson Date: Fri Jan 11 16:19:29 2019 + amd: Use drm_open_driver(AMDGPU) Just use the normal library function, with the normal warning message for an unmatched GPU so that CI buglog can filter it. References: https://bugs.freedesktop.org/show_bug.cgi?id=109315 Signed-off-by: Chris Wilson Cc: Martin Peres Reviewed-by: Petri Latvala Which at least reduces it to a common problem. -- 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 97639] Intermittent flickering artifacts with AMD R7 260x
https://bugs.freedesktop.org/show_bug.cgi?id=97639 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #14 from Michel Dänzer --- Thanks for the follow-up. Resolving as WONTFIX, since we can't know if it's fixed. -- 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 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #5 from Rafał Miłecki --- Created attachment 143103 --> https://bugs.freedesktop.org/attachment.cgi?id=143103&action=edit Xorg.0.log I'm attaching Xorg.0.log at requested with my actions commented properly -- 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 v3 1/5] drm/hisilicon/kirin: Use drm_fbdev_generic_setup()
Den 28.11.2018 22.27, skrev Noralf Trønnes:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> struct kirin_drm_private can be removed now that driver doesn't have to
> store the fbdev pointer.
>
> Cc: Xinliang Liu
> Cc: Rongrong Zou
> Cc: Xinwei Kong
> Cc: Chen Feng
> Signed-off-by: Noralf Trønnes
> Acked-by: Sam Ravnborg
> ---
Applied to drm-misc-next.
Noralf.
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c | 38
> ++---
> drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h | 4 ---
> 2 files changed, 3 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> index e6a62d5a00a3..15e32e5d9101 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.c
> @@ -22,6 +22,7 @@
> #include
> #include
> #include
> +#include
> #include
> #include
> #include
> @@ -33,32 +34,15 @@ static struct kirin_dc_ops *dc_ops;
>
> static int kirin_drm_kms_cleanup(struct drm_device *dev)
> {
> - struct kirin_drm_private *priv = dev->dev_private;
> -
> - if (priv->fbdev) {
> - drm_fbdev_cma_fini(priv->fbdev);
> - priv->fbdev = NULL;
> - }
> -
> drm_kms_helper_poll_fini(dev);
> dc_ops->cleanup(to_platform_device(dev->dev));
> drm_mode_config_cleanup(dev);
> - devm_kfree(dev->dev, priv);
> - dev->dev_private = NULL;
>
> return 0;
> }
>
> -static void kirin_fbdev_output_poll_changed(struct drm_device *dev)
> -{
> - struct kirin_drm_private *priv = dev->dev_private;
> -
> - drm_fbdev_cma_hotplug_event(priv->fbdev);
> -}
> -
> static const struct drm_mode_config_funcs kirin_drm_mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> - .output_poll_changed = kirin_fbdev_output_poll_changed,
> .atomic_check = drm_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> };
> @@ -76,14 +60,8 @@ static void kirin_drm_mode_config_init(struct drm_device
> *dev)
>
> static int kirin_drm_kms_init(struct drm_device *dev)
> {
> - struct kirin_drm_private *priv;
> int ret;
>
> - priv = devm_kzalloc(dev->dev, sizeof(*priv), GFP_KERNEL);
> - if (!priv)
> - return -ENOMEM;
> -
> - dev->dev_private = priv;
> dev_set_drvdata(dev->dev, dev);
>
> /* dev->mode_config initialization */
> @@ -117,26 +95,14 @@ static int kirin_drm_kms_init(struct drm_device *dev)
> /* init kms poll for handling hpd */
> drm_kms_helper_poll_init(dev);
>
> - priv->fbdev = drm_fbdev_cma_init(dev, 32,
> - dev->mode_config.num_connector);
> -
> - if (IS_ERR(priv->fbdev)) {
> - DRM_ERROR("failed to initialize fbdev.\n");
> - ret = PTR_ERR(priv->fbdev);
> - goto err_cleanup_poll;
> - }
> return 0;
>
> -err_cleanup_poll:
> - drm_kms_helper_poll_fini(dev);
> err_unbind_all:
> component_unbind_all(dev->dev, dev);
> err_dc_cleanup:
> dc_ops->cleanup(to_platform_device(dev->dev));
> err_mode_config_cleanup:
> drm_mode_config_cleanup(dev);
> - devm_kfree(dev->dev, priv);
> - dev->dev_private = NULL;
>
> return ret;
> }
> @@ -199,6 +165,8 @@ static int kirin_drm_bind(struct device *dev)
> if (ret)
> goto err_kms_cleanup;
>
> + drm_fbdev_generic_setup(drm_dev, 32);
> +
> return 0;
>
> err_kms_cleanup:
> diff --git a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> index 56cb62df065c..ad027d1cc826 100644
> --- a/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> +++ b/drivers/gpu/drm/hisilicon/kirin/kirin_drm_drv.h
> @@ -19,10 +19,6 @@ struct kirin_dc_ops {
> void (*cleanup)(struct platform_device *pdev);
> };
>
> -struct kirin_drm_private {
> - struct drm_fbdev_cma *fbdev;
> -};
> -
> extern const struct kirin_dc_ops ade_dc_ops;
>
> #endif /* __KIRIN_DRM_DRV_H__ */
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v3 2/5] drm/mxsfb: Use drm_fbdev_generic_setup()
Den 28.11.2018 22.27, skrev Noralf Trønnes:
> The CMA helper is already using the drm_fb_helper_generic_probe part of
> the generic fbdev emulation. This patch makes full use of the generic
> fbdev emulation by using its drm_client callbacks. This means that
> drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are
> now handled by the emulation code. Additionally fbdev unregister happens
> automatically on drm_dev_unregister().
>
> The drm_fbdev_generic_setup() call is put after drm_dev_register() in the
> driver. This is done to highlight the fact that fbdev emulation is an
> internal client that makes use of the driver, it is not part of the
> driver as such. If fbdev setup fails, an error is printed, but the driver
> succeeds probing.
>
> Cc: Marek Vasut
> Signed-off-by: Noralf Trønnes
> Acked-by: Sam Ravnborg
> ---
Applied to drm-misc-next.
Noralf.
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 26 ++
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 1 -
> 2 files changed, 2 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index 88ba003979e6..13e778825098 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -263,23 +263,12 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> long flags)
>
> drm_kms_helper_poll_init(drm);
>
> - mxsfb->fbdev = drm_fbdev_cma_init(drm, 32,
> - drm->mode_config.num_connector);
> - if (IS_ERR(mxsfb->fbdev)) {
> - ret = PTR_ERR(mxsfb->fbdev);
> - mxsfb->fbdev = NULL;
> - dev_err(drm->dev, "Failed to init FB CMA area\n");
> - goto err_cma;
> - }
> -
> platform_set_drvdata(pdev, drm);
>
> drm_helper_hpd_irq_event(drm);
>
> return 0;
>
> -err_cma:
> - drm_irq_uninstall(drm);
> err_irq:
> drm_panel_detach(mxsfb->panel);
> err_vblank:
> @@ -290,11 +279,6 @@ static int mxsfb_load(struct drm_device *drm, unsigned
> long flags)
>
> static void mxsfb_unload(struct drm_device *drm)
> {
> - struct mxsfb_drm_private *mxsfb = drm->dev_private;
> -
> - if (mxsfb->fbdev)
> - drm_fbdev_cma_fini(mxsfb->fbdev);
> -
> drm_kms_helper_poll_fini(drm);
> drm_mode_config_cleanup(drm);
>
> @@ -307,13 +291,6 @@ static void mxsfb_unload(struct drm_device *drm)
> pm_runtime_disable(drm->dev);
> }
>
> -static void mxsfb_lastclose(struct drm_device *drm)
> -{
> - struct mxsfb_drm_private *mxsfb = drm->dev_private;
> -
> - drm_fbdev_cma_restore_mode(mxsfb->fbdev);
> -}
> -
> static void mxsfb_irq_preinstall(struct drm_device *drm)
> {
> struct mxsfb_drm_private *mxsfb = drm->dev_private;
> @@ -347,7 +324,6 @@ static struct drm_driver mxsfb_driver = {
> .driver_features= DRIVER_GEM | DRIVER_MODESET |
> DRIVER_PRIME | DRIVER_ATOMIC |
> DRIVER_HAVE_IRQ,
> - .lastclose = mxsfb_lastclose,
> .irq_handler= mxsfb_irq_handler,
> .irq_preinstall = mxsfb_irq_preinstall,
> .irq_uninstall = mxsfb_irq_preinstall,
> @@ -412,6 +388,8 @@ static int mxsfb_probe(struct platform_device *pdev)
> if (ret)
> goto err_unload;
>
> + drm_fbdev_generic_setup(drm, 32);
> +
> return 0;
>
> err_unload:
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> index 5d0883fc805b..bedd6801edca 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.h
> @@ -37,7 +37,6 @@ struct mxsfb_drm_private {
> struct drm_simple_display_pipe pipe;
> struct drm_connectorconnector;
> struct drm_panel*panel;
> - struct drm_fbdev_cma*fbdev;
> };
>
> int mxsfb_setup_crtc(struct drm_device *dev);
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH] drm/ttm: force cached mappings for system RAM on ARM
Am 14.01.19 um 11:53 schrieb Ard Biesheuvel: > On Thu, 10 Jan 2019 at 10:34, Michel Dänzer wrote: >> On 2019-01-10 8:28 a.m., Ard Biesheuvel wrote: >>> ARM systems do not permit the use of anything other than cached >>> mappings for system memory, since that memory may be mapped in the >>> linear region as well, and the architecture does not permit aliases >>> with mismatched attributes. >>> >>> So short-circuit the evaluation in ttm_io_prot() if the flags include >>> TTM_PL_SYSTEM when running on ARM or arm64, and just return cached >>> attributes immediately. >>> >>> This fixes the radeon and amdgpu [TBC] drivers when running on arm64. >>> Without this change, amdgpu does not start at all, and radeon only >>> produces corrupt display output. >>> >>> Cc: Christian Koenig >>> Cc: Huang Rui >>> Cc: Junwei Zhang >>> Cc: David Airlie >>> Reported-by: Carsten Haitzler >>> Signed-off-by: Ard Biesheuvel >>> --- >>> drivers/gpu/drm/ttm/ttm_bo_util.c | 5 + >>> 1 file changed, 5 insertions(+) >>> >>> diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c >>> b/drivers/gpu/drm/ttm/ttm_bo_util.c >>> index 046a6dda690a..0c1eef5f7ae3 100644 >>> --- a/drivers/gpu/drm/ttm/ttm_bo_util.c >>> +++ b/drivers/gpu/drm/ttm/ttm_bo_util.c >>> @@ -530,6 +530,11 @@ pgprot_t ttm_io_prot(uint32_t caching_flags, pgprot_t >>> tmp) >>>if (caching_flags & TTM_PL_FLAG_CACHED) >>>return tmp; >>> >>> +#if defined(__arm__) || defined(__aarch64__) >>> + /* ARM only permits cached mappings of system memory */ >>> + if (caching_flags & TTM_PL_SYSTEM) >>> + return tmp; >>> +#endif >>> #if defined(__i386__) || defined(__x86_64__) >>>if (caching_flags & TTM_PL_FLAG_WC) >>>tmp = pgprot_writecombine(tmp); >>> >> Apart from Christian's concerns, I think this is the wrong place for >> this, because other TTM / driver code will still consider the memory >> uncacheable. E.g. the amdgpu driver will program the GPU to treat the >> memory as uncacheable, so it won't participate in cache coherency >> protocol for it, which is unlikely to work as expected in general if the >> CPU treats the memory as cacheable. >> > Will and I have spent some time digging into this, so allow me to > share some preliminary findings while we carry on and try to fix this > properly. > > - The patch above is flawed, i.e., it doesn't do what it intends to > since it uses TTM_PL_SYSTEM instead of TTM_PL_FLAG_SYSTEM. Apologies > for that. > - The existence of a linear region mapping with mismatched attributes > is likely not the culprit here. (We do something similar with > non-cache coherent DMA in other places). This is still rather problematic. The issue is that we often don't create a vmap for a page, but rather access the page directly using the linear mapping. So we would use the wrong access type here. > - The reason remapping the CPU side as cacheable does work (which I > did test) is because the GPU's uncacheable accesses (which I assume > are made using the NoSnoop PCIe transaction attribute) are actually > emitted as cacheable in some cases. >. On my AMD Seattle, with or without SMMU (which is stage 2 only), I > must use cacheable accesses from the CPU side or things are broken. > This might be a h/w flaw, though. >. On systems with stage 1+2 SMMUs, the driver uses stage 1 > translations which always override the memory attributes to cacheable > for DMA coherent devices. This is what is affecting the Cavium > ThunderX2 (although it appears the attributes emitted by the RC may be > incorrect as well.) > > The latter issue is a shortcoming in the SMMU driver that we have to > fix, i.e., it should take care not to modify the incoming attributes > of DMA coherent PCIe devices for NoSnoop to be able to work. > > So in summary, the mismatch appears to be between the CPU accessing > the vmap region with non-cacheable attributes and the GPU accessing > the same memory with cacheable attributes, resulting in a loss of > coherency and lots of visible corruption. Actually it is the other way around. The CPU thinks some data is in the cache and the GPU only updates the system memory version because the snoop flag is not set. > To be able to debug this further, could you elaborate a bit on > - How does the hardware emit those uncached/wc inbound accesses? Do > they rely on NoSnoop? The GPU has a separate page walker in the MC and the page tables there have a bits saying if the access should go to the PCIe bus and if yes if the snoop bit should be set. > - Christian pointed out that some accesses must be uncached even when > not using WC. What kind of accesses are those? And do they access > system RAM? On some hardware generations we have a buggy engine which fails to forward the snoop bit and because of this the system memory page used by this engine must be uncached. But this only applies if you use ROCm in a specific configuration. Regards, Christian. ___
Re: [PATCH v2 03/49] drm/omap: dsi: Fix OF platform depopulate
On 11/01/19 05:50, Laurent Pinchart wrote:
> From: Tomi Valkeinen
>
> Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> bind to probe") moved the of_platform_populate() call from dsi_bind() to
> dsi_probe(), but failed to move the corresponding
> of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results
> in OF child devices being potentially removed multiple times. Fix it by
> placing the of_platform_depopulate() call where it belongs.
>
> Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from bind
> to probe")
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
I'm not sure if you want my signed-off-by or reviewed-by for this and
the next, but you've got it.
Tomi
--
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/49] drm/omap: Remove declaration of nonexisting function
On 11/01/19 05:50, Laurent Pinchart wrote: > The omap_connector_attached_encoder() doesn't exist anymore, remove its > declaration from omap_connector.h. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > Tested-by: Sebastian Reichel > --- > drivers/gpu/drm/omapdrm/omap_connector.h | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 06/49] drm/omap: Remove unused kobj field from struct omap_dss_device
On 11/01/19 05:50, Laurent Pinchart wrote: > The kobj field from struct omap_dss_device is not used. Remove it. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > Tested-by: Sebastian Reichel > --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 -- > 1 file changed, 2 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/49] drm/omap: venc: Remove wss_data field from venc_device structure
On 11/01/19 05:50, Laurent Pinchart wrote: > The venc_device structure wss_data field is set to 0 and never otherwise > modified, remove it. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > Tested-by: Sebastian Reichel > --- > drivers/gpu/drm/omapdrm/dss/venc.c | 11 +-- > 1 file changed, 1 insertion(+), 10 deletions(-) Hmm, I think wss_data served some purpose, but possibly not all of the wss code was upstreamed at Nokia time... Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109340] HDMI output (DisplayPort-0) stops listing modes after using docking station DP output
https://bugs.freedesktop.org/show_bug.cgi?id=109340 --- Comment #6 from Rafał Miłecki --- Created attachment 143104 --> https://bugs.freedesktop.org/attachment.cgi?id=143104&action=edit Xorg.0.log using xf86-video-modesetting Michel has suggested trying xf86-video-modesetting. A difference from user perspective is minimal. 1) With both drivers I can use HDMI output port just fine after booting (without a docking station) 2) After that I connect docking station, connect DP, disconnect DP, disconnect docking station 3) Finally I try connecting monitor to the HDMI output again: a) With xorg-xf86-video-amdgpu I get "Output DisplayPort-0 is not disconnected but has no modes" b) With xf86-video-modesetting I get "xrandr: Configure crtc 1 failed" -- 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
[PATCH v3] drm/cma-helper: Remove unused fbdev code
CMA helper drivers have been converted to drm_fbdev_generic_setup()
so the fbdev code can be removed.
v3: Remove CMA specific conditional in the generic fbdev client
v2: Clean up the includes some more (Laurent)
Cc: Laurent Pinchart
Signed-off-by: Noralf Trønnes
Acked-by: Sam Ravnborg
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/Kconfig | 4 -
drivers/gpu/drm/drm_fb_cma_helper.c | 137 +---
drivers/gpu/drm/drm_fb_helper.c | 12 +--
include/drm/drm_fb_cma_helper.h | 22 -
4 files changed, 4 insertions(+), 171 deletions(-)
diff --git a/drivers/gpu/drm/Kconfig b/drivers/gpu/drm/Kconfig
index 4385f00e1d05..bd943a71756c 100644
--- a/drivers/gpu/drm/Kconfig
+++ b/drivers/gpu/drm/Kconfig
@@ -170,10 +170,6 @@ config DRM_KMS_CMA_HELPER
bool
depends on DRM
select DRM_GEM_CMA_HELPER
- select DRM_KMS_FB_HELPER
- select FB_SYS_FILLRECT
- select FB_SYS_COPYAREA
- select FB_SYS_IMAGEBLIT
help
Choose this if you need the KMS CMA helper functions
diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c
index 5b516615881a..5f8074ffe7d9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -17,20 +17,13 @@
* GNU General Public License for more details.
*/
-#include
-#include
-#include
+#include
#include
#include
#include
-#include
-#include
+#include
#include
-struct drm_fbdev_cma {
- struct drm_fb_helperfb_helper;
-};
-
/**
* DOC: framebuffer cma helper functions
*
@@ -39,16 +32,8 @@ struct drm_fbdev_cma {
*
* drm_gem_fb_create() is used in the &drm_mode_config_funcs.fb_create
* callback function to create a cma backed framebuffer.
- *
- * An fbdev framebuffer backed by cma is also available by calling
- * drm_fb_cma_fbdev_init(). drm_fb_cma_fbdev_fini() tears it down.
*/
-static inline struct drm_fbdev_cma *to_fbdev_cma(struct drm_fb_helper *helper)
-{
- return container_of(helper, struct drm_fbdev_cma, fb_helper);
-}
-
/**
* drm_fb_cma_get_gem_obj() - Get CMA GEM object for framebuffer
* @fb: The framebuffer
@@ -119,121 +104,3 @@ dma_addr_t drm_fb_cma_get_gem_addr(struct drm_framebuffer
*fb,
return paddr;
}
EXPORT_SYMBOL_GPL(drm_fb_cma_get_gem_addr);
-
-/**
- * drm_fb_cma_fbdev_init() - Allocate and initialize fbdev emulation
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device.
- * @dev->mode_config.preferred_depth is used if this is zero.
- * @max_conn_count: Maximum number of connectors.
- * @dev->mode_config.num_connector is used if this is zero.
- *
- * Returns:
- * Zero on success or negative error code on failure.
- */
-int drm_fb_cma_fbdev_init(struct drm_device *dev, unsigned int preferred_bpp,
- unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
-
- /* dev->fb_helper will indirectly point to fbdev_cma after this call */
- fbdev_cma = drm_fbdev_cma_init(dev, preferred_bpp, max_conn_count);
- return PTR_ERR_OR_ZERO(fbdev_cma);
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_init);
-
-/**
- * drm_fb_cma_fbdev_fini() - Teardown fbdev emulation
- * @dev: DRM device
- */
-void drm_fb_cma_fbdev_fini(struct drm_device *dev)
-{
- if (dev->fb_helper)
- drm_fbdev_cma_fini(to_fbdev_cma(dev->fb_helper));
-}
-EXPORT_SYMBOL_GPL(drm_fb_cma_fbdev_fini);
-
-static const struct drm_fb_helper_funcs drm_fb_cma_helper_funcs = {
- .fb_probe = drm_fb_helper_generic_probe,
-};
-
-/**
- * drm_fbdev_cma_init() - Allocate and initializes a drm_fbdev_cma struct
- * @dev: DRM device
- * @preferred_bpp: Preferred bits per pixel for the device
- * @max_conn_count: Maximum number of connectors
- *
- * Returns a newly allocated drm_fbdev_cma struct or a ERR_PTR.
- */
-struct drm_fbdev_cma *drm_fbdev_cma_init(struct drm_device *dev,
- unsigned int preferred_bpp, unsigned int max_conn_count)
-{
- struct drm_fbdev_cma *fbdev_cma;
- struct drm_fb_helper *fb_helper;
- int ret;
-
- fbdev_cma = kzalloc(sizeof(*fbdev_cma), GFP_KERNEL);
- if (!fbdev_cma)
- return ERR_PTR(-ENOMEM);
-
- fb_helper = &fbdev_cma->fb_helper;
-
- ret = drm_client_init(dev, &fb_helper->client, "fbdev", NULL);
- if (ret)
- goto err_free;
-
- ret = drm_fb_helper_fbdev_setup(dev, fb_helper,
&drm_fb_cma_helper_funcs,
- preferred_bpp, max_conn_count);
- if (ret)
- goto err_client_put;
-
- drm_client_add(&fb_helper->client);
-
- return fbdev_cma;
-
-err_client_put:
- drm_client_release(&fb_helper->client);
-err_free:
- kfree(fbdev_cma);
-
- return ERR_PTR(ret);
-}
-EXPORT_SYMBOL_GPL(drm_fbdev_cma_init);
-
-/**
- * drm_fbdev_cma_fini() - Free drm_fbdev_cma struct
- * @fbdev_cma: The drm_fbdev_cma struct
Re: [PATCH v2 08/49] drm/omap: Use atomic suspend/resume helpers
On 11/01/19 05:50, Laurent Pinchart wrote: > Instead of rolling out custom suspend/resume implementations based on > state information stored in the driver's data structures, use the atomic > suspend/resume helpers that rely on a DRM atomic state object. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > Tested-by: Sebastian Reichel > --- > Changes since v1: > > - Use drm_mode_config_helper_suspend() > --- > drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 -- > drivers/gpu/drm/omapdrm/omap_drv.c| 50 ++- > 2 files changed, 2 insertions(+), 51 deletions(-) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 42/49] dt-bindings: Add vendor prefix for OSD Displays
On 11/01/19 05:51, Laurent Pinchart wrote: > OSD Displays is a panel manufacturer. It has been acquired by New Vision > Displays in 2015 but continues to operate under its own brand name. > > Signed-off-by: Laurent Pinchart > --- > Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt > b/Documentation/devicetree/bindings/vendor-prefixes.txt > index 389508584f48..8b10a323a334 100644 > --- a/Documentation/devicetree/bindings/vendor-prefixes.txt > +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt > @@ -293,6 +293,7 @@ oranthShenzhen Oranth Technology Co., Ltd. > ORCL Oracle Corporation > orisetechOrise Technology > ortustechOrtus Technology Co., Ltd. > +osddisplays OSD Displays > ovti OmniVision Technologies > oxsemi Oxford Semiconductor, Ltd. > panasonicPanasonic Corporation > Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 43/49] dt-bindings: display: Add OSD Displays OSD070T1718-19TS panel binding
On 11/01/19 05:51, Laurent Pinchart wrote: > The OSD Displays OSD070T1718-19TS is a 7" WVGA (800x480) 24bit RGB panel > and is compatible with the simple-panel bindings. > > Signed-off-by: Laurent Pinchart > --- > .../display/panel/osddisplays,osd070t1718-19ts.txt | 7 +++ > 1 file changed, 7 insertions(+) > create mode 100644 > Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > > diff --git > a/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > > b/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > new file mode 100644 > index ..ae7011820231 > --- /dev/null > +++ > b/Documentation/devicetree/bindings/display/panel/osddisplays,osd070t1718-19ts.txt > @@ -0,0 +1,7 @@ > +OSD Displays OSD070T1718-19TS 7" WVGA TFT LCD panel > + > +Required properties: > +- compatible: should be "osddisplays,osd070t1718-19ts" > + > +This binding is compatible with the simple-panel binding, which is specified > +in simple-panel.txt in this directory. > Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 44/49] drm/panel: simple: Add OSD070T1718-19TS panel support
On 11/01/19 05:51, Laurent Pinchart wrote: > Add support for the OSD070T1718-19TS 7" 800x480 panel from One Stop > Displays to the panel-simple driver. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Sebastian Reichel > --- > drivers/gpu/drm/panel/panel-simple.c | 29 > 1 file changed, 29 insertions(+) Reviewed-by: Tomi Valkeinen Tomi -- Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation
On Fri, 11 Jan 2019, Liviu Dudau wrote: > On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote: >> Hi Liviu, >> >> On Mon, 2018-12-03 at 11:31 +, Ayan Halder wrote: >> > From: Brian Starkey >> > >> > AFBC is a flexible, proprietary, lossless compression protocol and >> > format, with a number of defined DRM format modifiers. To facilitate >> > consistency and compatibility between different AFBC producers and >> > consumers, document the expectations for usage of the AFBC DRM format >> > modifiers in a new .rst chapter. >> > >> > Signed-off-by: Brian Starkey >> > Reviewed-by: Liviu Dudau >> > --- >> >> I can't find this commit anywhere. Did you decide to reject >> this or perhaps it just fell thru the cracks? > > Cracks have opened wide enough to let this through, sorry about that! > > I've now sent a pull request to get it merged. Okay, so this is a very late comment, so feel free to ignore or, perhaps, add a change on top. Documentation/gpu mostly contains files that document high level stuff, mostly one file per driver (with names matching the directories under drivers/gpu/drm) or one file per drm core functional area. Perhaps start an arm.rst, or at least name it more descriptively, say arm-fbc.rst? Contrast msm-crash-dump.rst. BR, Jani. > > Best regards, > Liviu > >> >> Thanks! >> Ezequiel >> >> >> > Documentation/gpu/afbc.rst| 233 >> > ++ >> > Documentation/gpu/drivers.rst | 1 + >> > MAINTAINERS | 1 + >> > include/uapi/drm/drm_fourcc.h | 3 + >> > 4 files changed, 238 insertions(+) >> > create mode 100644 Documentation/gpu/afbc.rst >> > >> > diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst >> > new file mode 100644 >> > index 000..922d955 >> > --- /dev/null >> > +++ b/Documentation/gpu/afbc.rst >> > @@ -0,0 +1,233 @@ >> > +=== >> > + Arm Framebuffer Compression (AFBC) >> > +=== >> > + >> > +AFBC is a proprietary lossless image compression protocol and format. >> > +It provides fine-grained random access and minimizes the amount of >> > +data transferred between IP blocks. >> > + >> > +AFBC can be enabled on drivers which support it via use of the AFBC >> > +format modifiers defined in drm_fourcc.h. See DRM_FORMAT_MOD_ARM_AFBC(*). >> > + >> > +All users of the AFBC modifiers must follow the usage guidelines laid >> > +out in this document, to ensure compatibility across different AFBC >> > +producers and consumers. >> > + >> > +Components and Ordering >> > +=== >> > + >> > +AFBC streams can contain several components - where a component >> > +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). >> > +The assignment of input/output color channels must be consistent >> > +between the encoder and the decoder for correct operation, otherwise >> > +the consumer will interpret the decoded data incorrectly. >> > + >> > +Furthermore, when the lossless colorspace transform is used >> > +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for >> > +maximum compression efficiency), the component order must be: >> > + >> > + * Component 0: R >> > + * Component 1: G >> > + * Component 2: B >> > + >> > +The component ordering is communicated via the fourcc code in the >> > +fourcc:modifier pair. In general, component '0' is considered to >> > +reside in the least-significant bits of the corresponding linear >> > +format. For example, COMP(bits): >> > + >> > + * DRM_FORMAT_ABGR >> > + >> > + * Component 0: R(8) >> > + * Component 1: G(8) >> > + * Component 2: B(8) >> > + * Component 3: A(8) >> > + >> > + * DRM_FORMAT_BGR888 >> > + >> > + * Component 0: R(8) >> > + * Component 1: G(8) >> > + * Component 2: B(8) >> > + >> > + * DRM_FORMAT_YUYV >> > + >> > + * Component 0: Y(8) >> > + * Component 1: Cb(8, 2x1 subsampled) >> > + * Component 2: Cr(8, 2x1 subsampled) >> > + >> > +In AFBC, 'X' components are not treated any differently from any other >> > +component. Therefore, an AFBC buffer with fourcc DRM_FORMAT_XBGR >> > +encodes with 4 components, like so: >> > + >> > + * DRM_FORMAT_XBGR >> > + >> > + * Component 0: R(8) >> > + * Component 1: G(8) >> > + * Component 2: B(8) >> > + * Component 3: X(8) >> > + >> > +Please note, however, that the inclusion of a "wasted" 'X' channel is >> > +bad for compression efficiency, and so it's recommended to avoid >> > +formats containing 'X' bits. If a fourth component is >> > +required/expected by the encoder/decoder, then it is recommended to >> > +instead use an equivalent format with alpha, setting all alpha bits to >> > +'1'. If there is no requirement for a fourth component, then a format >> > +which doesn't include alpha can be used, e.g. DRM_FORMAT_BGR888. >> > + >> > +Number of Planes >> > + >> > + >> > +Formats which are typically multi-planar in linear layouts (e.g. YUV >> > +420),
[Bug 109315] [CI] igt@amdgpu/* - skip - Test requirement: fd >= 0, Last errno: 2, No such file or directory / Test requirement: err == 0 Last errno: 9, Bad file descriptor
https://bugs.freedesktop.org/show_bug.cgi?id=109315 --- Comment #3 from CI Bug Log --- The CI Bug Log issue associated to this bug has been updated. ### New filters associated * ICL: all tests - skip - No known gpu found for chipset flags 0x16 (amdgpu) - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@query-info.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@memory-alloc.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@cs-gfx.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@cs-compute.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@cs-multi-fence.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@cs-sdma.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_ba...@semaphore.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@nop-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@nop-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@sync-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@sync-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@fork-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@sync-fork-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_pr...@i915-to-amd.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u2/igt@amdgpu/amd_pr...@amd-to-i915.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@query-info.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@memory-alloc.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@userptr.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@cs-gfx.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@cs-compute.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@cs-multi-fence.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@cs-sdma.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_ba...@semaphore.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@nop-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@nop-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@sync-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@sync-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@fork-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@fork-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@sync-fork-compute0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_cs_...@sync-fork-gfx0.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_pr...@i915-to-amd.html - https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_5415/fi-icl-u3/igt@amdgpu/amd_pr...@amd-to-i915.html -- 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 109315] [CI] igt@amdgpu/* - skip - Test requirement: fd >= 0, Last errno: 2, No such file or directory / Test requirement: err == 0 Last errno: 9, Bad file descriptor
https://bugs.freedesktop.org/show_bug.cgi?id=109315
--- Comment #4 from CI Bug Log ---
A CI Bug Log filter associated to this bug has been updated:
{- ICL: all tests - skip - No known gpu found for chipset flags 0x16 (amdgpu)
-}
{+ ICL: all tests - skip - No known gpu found for chipset flags 0x(16|32) +}
No new failures caught with the new filter
--
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: Armada DRM: bridge with componentized devices
On Fri, Jan 11, 2019 at 3:49 PM Russell King - ARM Linux wrote: > > On Fri, Jan 11, 2019 at 03:36:28PM +0100, Rafael J. Wysocki wrote: > > On Fri, Jan 11, 2019 at 3:32 PM Russell King - ARM Linux > > wrote: > > > > > > On Fri, Jan 11, 2019 at 03:26:44PM +0100, Rafael J. Wysocki wrote: > > > > On Fri, Jan 11, 2019 at 3:20 PM Daniel Vetter wrote: > > > > > > > > > > On Wed, Jan 9, 2019 at 10:31 AM Russell King - ARM Linux > > > > > wrote: > > > > > > On Wed, Jan 09, 2019 at 10:24:01AM +0100, Rafael J. Wysocki wrote: > > > > > > > On Wed, Jan 9, 2019 at 10:13 AM Andrzej Hajda > > > > > > > wrote: > > > > > > > > > > > > > > > > +CC: Rafael J. Wysocki > > > > > > > > > > > > > > > > On 08.01.2019 16:07, Russell King - ARM Linux wrote: > > > > > > > > > On Tue, Jan 08, 2019 at 03:33:54PM +0100, Andrzej Hajda wrote: > > > > > > > > >> On 08.01.2019 14:21, Russell King - ARM Linux wrote: > > > > > > > > >>> On Tue, Jan 08, 2019 at 01:27:56PM +0100, Andrzej Hajda > > > > > > > > >>> wrote: > > > > > > > > On 08.01.2019 12:38, Russell King - ARM Linux wrote: > > > > > > > > > On Tue, Jan 08, 2019 at 12:25:34PM +0100, Andrzej Hajda > > > > > > > > > wrote: > > > > > > > > >> Issues with device links have nothing to do with > > > > > > > > >> hotplugging, they are > > > > > > > > >> generic - lifetime of the objects (drm_bridge, > > > > > > > > >> drm_panel) is just > > > > > > > > >> slightly different of lifetime of device links, and this > > > > > > > > >> is racy even if > > > > > > > > >> you do not want hotplugging. Moreover since drm_dev is > > > > > > > > >> not device (has > > > > > > > > >> no associated struct device) assuming we can reuse its > > > > > > > > >> parent to create > > > > > > > > >> device link results in circular dependencies. > > > > > > > > > How about having the device links created depending on > > > > > > > > > whether the > > > > > > > > > main drm driver wants them or not - that would mean that > > > > > > > > > Exynos > > > > > > > > > could continue avoiding them, but others that want them > > > > > > > > > can have > > > > > > > > > the links? > > > > > > > > That should be OK for Exynos. But regardless of Exynos > > > > > > > > device_links at > > > > > > > > the current state will not work correctly with > > > > > > > > bridges/panels as I > > > > > > > > described earlier. > > > > > > > > >>> However, I'm not sure you're correct with your > > > > > > > > >>> interpretation of the > > > > > > > > >>> documentation. Firstly, the documentation says: > > > > > > > > >>> > > > > > > > > >>>Another example for an inconsistent state would be a > > > > > > > > >>> device link that > > > > > > > > >>>represents a driver presence dependency, yet is added > > > > > > > > >>> from the consumer's > > > > > > > > >>>->probe callback while the supplier hasn't probed yet: > > > > > > > > >>> Had the driver core > > > > > > > > >>>known about the device link earlier, it wouldn't have > > > > > > > > >>> probed the consumer > > > > > > > > >>>in the first place. The onus is thus on the consumer to > > > > > > > > >>> check presence of > > > > > > > > >>>the supplier after adding the link, and defer probing on > > > > > > > > >>> non-presence. > > > > > > > > >>> > > > > > > > > >>> This is fine - if we add the device link from > > > > > > > > >>> of_drm_find_bridge(), we > > > > > > > > >>> will be in the consumer's ->probe function, and the > > > > > > > > >>> supplier must have > > > > > > > > >>> been probed for us to find the struct drm_bridge. > > > > > > > > >> > > > > > > > > >> Supplier usually is registered in it's probe time, so there > > > > > > > > >> is short > > > > > > > > >> period of time when supplier is available, but the probe is > > > > > > > > >> not yet > > > > > > > > >> finished - quite unsafe, but not impossible, especially if > > > > > > > > >> there exists > > > > > > > > >> some kind of notifications about resource appearance > > > > > > > > >> (MIPI-DSI case). > > > > > > > > > At some point during the supplier probe, the resource becomes > > > > > > > > > available > > > > > > > > > to consumers. At that point, device links can be setup > > > > > > > > > before the > > > > > > > > > supplier has finished probing. So any driver that provides > > > > > > > > > resources > > > > > > > > > to another driver will, at some point during the provider's > > > > > > > > > probe, > > > > > > > > > make resources available, and therefore be a candidate for > > > > > > > > > device links > > > > > > > > > to be created _before_ the probe function has returned. > > > > > > > > > > > > > > > > > > What is a problem is if the provider publishes resources, and > > > > > > > > > then fails > > > > > > > > > its probe function, causing the resource to disappear. > > > > > > > > > > > > > > > > > > > > > > > > Bu
[Bug 109315] [CI] igt@amdgpu/* / igt@v3d_* - skip - incompatible chipset
https://bugs.freedesktop.org/show_bug.cgi?id=109315 Martin Peres changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |intel-gfx-bugs@lists.freede |.org|sktop.org Component|IGT |DRM/Intel CC||intel-gfx-bugs@lists.freede ||sktop.org Resolution|WORKSFORME |NOTABUG Summary|[CI] igt@amdgpu/* - skip - |[CI] igt@amdgpu/* / |Test requirement: fd >= 0, |igt@v3d_* - skip - |Last errno: 2, No such file |incompatible chipset |or directory / Test | |requirement: err == 0 Last | |errno: 9, Bad file | |descriptor | Status|RESOLVED|CLOSED QA Contact||intel-gfx-bugs@lists.freede ||sktop.org --- Comment #5 from Martin Peres --- (In reply to Chris Wilson from comment #2) > commit c3aef507e1dfe1e483787d501e9907dab67f6bca (HEAD, upstream/master) > Author: Chris Wilson > Date: Fri Jan 11 16:19:29 2019 + > > amd: Use drm_open_driver(AMDGPU) > > Just use the normal library function, with the normal warning message > for an unmatched GPU so that CI buglog can filter it. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=109315 > Signed-off-by: Chris Wilson > Cc: Martin Peres > Reviewed-by: Petri Latvala > > Which at least reduces it to a common problem. Thanks Chris! Moving the bug back to drm/Intel now and making it a generic one for incompatible chipset :) -- 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 109342] Display is frozen in X, but mouse cursor moves when using fcitx with nouveau.
https://bugs.freedesktop.org/show_bug.cgi?id=109342 Sih Sîng-hông changed: What|Removed |Added QA Contact||xorg-t...@lists.x.org Component|DRM/other |Driver/nouveau Assignee|dri-devel@lists.freedesktop |nouveau@lists.freedesktop.o |.org|rg Version|XOrg git|unspecified Product|DRI |xorg -- 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/2] drm/ttm: add lru notify to bo driver v2
Am 14.01.19 um 08:02 schrieb Chunming Zhou:
> allow driver do somethings when lru changed.
> v2:
> address Michel's comments.
>
> Change-Id: Ie82053da49272881d4b52b1c406f7c221a3fcadf
> Signed-off-by: Chunming Zhou
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 11 +++
> include/drm/ttm/ttm_bo_driver.h | 9 +
> 2 files changed, 16 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 0ec08394e17a..de088c8070fb 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -198,19 +198,22 @@ static void ttm_bo_ref_bug(struct kref *list_kref)
>
> void ttm_bo_del_from_lru(struct ttm_buffer_object *bo)
> {
> + struct ttm_bo_device *bdev = bo->bdev;
> + bool notify = false;
> +
> if (!list_empty(&bo->swap)) {
> list_del_init(&bo->swap);
> kref_put(&bo->list_kref, ttm_bo_ref_bug);
> + notify = true;
> }
> if (!list_empty(&bo->lru)) {
> list_del_init(&bo->lru);
> kref_put(&bo->list_kref, ttm_bo_ref_bug);
> + notify = true;
> }
>
> - /*
> - * TODO: Add a driver hook to delete from
> - * driver-specific LRU's here.
> - */
> + if (notify && bdev->driver->del_from_lru_notify)
> + bdev->driver->del_from_lru_notify(bo);
> }
>
> void ttm_bo_del_sub_from_lru(struct ttm_buffer_object *bo)
> diff --git a/include/drm/ttm/ttm_bo_driver.h b/include/drm/ttm/ttm_bo_driver.h
> index 1021106438b2..15829b24277c 100644
> --- a/include/drm/ttm/ttm_bo_driver.h
> +++ b/include/drm/ttm/ttm_bo_driver.h
> @@ -381,6 +381,15 @@ struct ttm_bo_driver {
>*/
> int (*access_memory)(struct ttm_buffer_object *bo, unsigned long offset,
>void *buf, int len, int write);
> +
> + /**
> + * struct ttm_bo_driver member del_from_lru_notify
> + *
> + * @bo: the buffer object deleted from lru
> + *
> + * notify driver that a BO was deleted from LRU.
> + */
> + void (*del_from_lru_notify)(struct ttm_buffer_object *bo);
> };
>
> /**
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/2] drm/amdgpu: set bulk_moveable to false when lru changed v2
Am 14.01.19 um 08:02 schrieb Chunming Zhou:
> if lru is changed, we cannot do bulk moving.
> v2:
> root bo isn't bulk moving, skip its change.
>
> Change-Id: Ide0fe920295cc25f7cabcf41a6400519e5783f2a
> Signed-off-by: Chunming Zhou
We could now remove all other cases where we set bulk_movable to false,
but that can also be a follow up patch.
Reviewed-by: Christian König
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 22 ++
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 ++
> 3 files changed, 26 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> index c91ec3101d00..b852abb9db0f 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
> @@ -1546,7 +1546,8 @@ static struct ttm_bo_driver amdgpu_bo_driver = {
> .io_mem_reserve = &amdgpu_ttm_io_mem_reserve,
> .io_mem_free = &amdgpu_ttm_io_mem_free,
> .io_mem_pfn = amdgpu_ttm_io_mem_pfn,
> - .access_memory = &amdgpu_ttm_access_memory
> + .access_memory = &amdgpu_ttm_access_memory,
> + .del_from_lru_notify = &amdgpu_vm_del_from_lru_notify
> };
>
> /*
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> index e73d152659a2..ef012d47cbeb 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
> @@ -623,6 +623,28 @@ void amdgpu_vm_get_pd_bo(struct amdgpu_vm *vm,
> list_add(&entry->tv.head, validated);
> }
>
> +void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo)
> +{
> + struct amdgpu_bo *abo;
> + struct amdgpu_vm_bo_base *bo_base;
> +
> + if (!amdgpu_bo_is_amdgpu_bo(bo))
> + return;
> +
> + if (bo->mem.placement & TTM_PL_FLAG_NO_EVICT)
> + return;
> +
> + abo = ttm_to_amdgpu_bo(bo);
> + if (!abo->parent)
> + return;
> + for (bo_base = abo->vm_bo; bo_base; bo_base = bo_base->next) {
> + struct amdgpu_vm *vm = bo_base->vm;
> +
> + if (abo->tbo.resv == vm->root.base.bo->tbo.resv)
> + vm->bulk_moveable = false;
> + }
> +
> +}
> /**
>* amdgpu_vm_move_to_lru_tail - move all BOs to the end of LRU
>*
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> index e8dcfd59fc93..81ff8177f092 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h
> @@ -363,4 +363,6 @@ int amdgpu_vm_add_fault(struct
> amdgpu_retryfault_hashtable *fault_hash, u64 key)
>
> void amdgpu_vm_clear_fault(struct amdgpu_retryfault_hashtable *fault_hash,
> u64 key);
>
> +void amdgpu_vm_del_from_lru_notify(struct ttm_buffer_object *bo);
> +
> #endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109332] xf86-video-amdgpu - commit 0d60233d introduced stuttering with mouse cursor operations
https://bugs.freedesktop.org/show_bug.cgi?id=109332 --- Comment #2 from Nicholas Kazlauskas --- In this case it's not actually the mouse operations themselves causing the stuttering but the framebuffer change. This is a known limitation with the async plane updates API in DRM and not something we can really fix in DC until there's a better API for async updates. The page-flip IOCTL advertises itself as non-blocking but in reality it's not - if there's any commit work touching the plane it's going to be blocked until that finishes and that'll be any non asynchronous cursor update, gamma update, property update, or anything else that occurs. This is what the stuttering comes from. So while it's a valid use of the cursor UAPI to double buffer cursors it's not something I'd really recommend doing for an atomic driver with how DRM is currently setup. Maybe this can be a configurable option in the meantime? I'm not sure how much work that would be to add and maintain, though. -- 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: [RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation
Hi Jani, On Mon, Jan 14, 2019 at 02:23:46PM +0200, Jani Nikula wrote: > On Fri, 11 Jan 2019, Liviu Dudau wrote: > > On Thu, Jan 03, 2019 at 05:44:26PM -0300, Ezequiel Garcia wrote: > >> Hi Liviu, > >> > >> On Mon, 2018-12-03 at 11:31 +, Ayan Halder wrote: > >> > From: Brian Starkey > >> > > >> > AFBC is a flexible, proprietary, lossless compression protocol and > >> > format, with a number of defined DRM format modifiers. To facilitate > >> > consistency and compatibility between different AFBC producers and > >> > consumers, document the expectations for usage of the AFBC DRM format > >> > modifiers in a new .rst chapter. > >> > > >> > Signed-off-by: Brian Starkey > >> > Reviewed-by: Liviu Dudau > >> > --- > >> > >> I can't find this commit anywhere. Did you decide to reject > >> this or perhaps it just fell thru the cracks? > > > > Cracks have opened wide enough to let this through, sorry about that! > > > > I've now sent a pull request to get it merged. > > Okay, so this is a very late comment, so feel free to ignore or, > perhaps, add a change on top. > > Documentation/gpu mostly contains files that document high level stuff, > mostly one file per driver (with names matching the directories under > drivers/gpu/drm) or one file per drm core functional area. > > Perhaps start an arm.rst, or at least name it more descriptively, say > arm-fbc.rst? Contrast msm-crash-dump.rst. I did deliberately put it at the top-level, as AFBC is implemented by IPs from many different vendors. The intention of this file is to try and ensure interop between those different vendors' drivers. I fear that if we namespace it 'arm' then it will be regarded as Arm-specific, whereas it's meant to set the standard for the AFBC implementations in all vendors' DRM drivers. That only applies if they use the AFBC modifiers Arm has defined, but IMO that's what we should be pushing for instead of having each vendor define their own local AFBC modifiers, because that will make interop a nightmare. The Arm definitions should cover all conformant implementations. AFBC is a relatively well-established name, whereas arm-fbc is not a term anyone will be familiar with. We could name the file "arm-afbc.rst", though I am slightly against namespacing it that way for the reason mentioned above - it does/will/should apply to more than just the gpu/drm/arm tree. Best regards, -Brian > > BR, > Jani. > > > > > > Best regards, > > Liviu > > > >> > >> Thanks! > >> Ezequiel > >> > >> > >> > Documentation/gpu/afbc.rst| 233 > >> > ++ > >> > Documentation/gpu/drivers.rst | 1 + > >> > MAINTAINERS | 1 + > >> > include/uapi/drm/drm_fourcc.h | 3 + > >> > 4 files changed, 238 insertions(+) > >> > create mode 100644 Documentation/gpu/afbc.rst > >> > > >> > diff --git a/Documentation/gpu/afbc.rst b/Documentation/gpu/afbc.rst > >> > new file mode 100644 > >> > index 000..922d955 > >> > --- /dev/null > >> > +++ b/Documentation/gpu/afbc.rst > >> > @@ -0,0 +1,233 @@ > >> > +=== > >> > + Arm Framebuffer Compression (AFBC) > >> > +=== > >> > + > >> > +AFBC is a proprietary lossless image compression protocol and format. > >> > +It provides fine-grained random access and minimizes the amount of > >> > +data transferred between IP blocks. > >> > + > >> > +AFBC can be enabled on drivers which support it via use of the AFBC > >> > +format modifiers defined in drm_fourcc.h. See > >> > DRM_FORMAT_MOD_ARM_AFBC(*). > >> > + > >> > +All users of the AFBC modifiers must follow the usage guidelines laid > >> > +out in this document, to ensure compatibility across different AFBC > >> > +producers and consumers. > >> > + > >> > +Components and Ordering > >> > +=== > >> > + > >> > +AFBC streams can contain several components - where a component > >> > +corresponds to a color channel (i.e. R, G, B, X, A, Y, Cb, Cr). > >> > +The assignment of input/output color channels must be consistent > >> > +between the encoder and the decoder for correct operation, otherwise > >> > +the consumer will interpret the decoded data incorrectly. > >> > + > >> > +Furthermore, when the lossless colorspace transform is used > >> > +(AFBC_FORMAT_MOD_YTR, which should be enabled for RGB buffers for > >> > +maximum compression efficiency), the component order must be: > >> > + > >> > + * Component 0: R > >> > + * Component 1: G > >> > + * Component 2: B > >> > + > >> > +The component ordering is communicated via the fourcc code in the > >> > +fourcc:modifier pair. In general, component '0' is considered to > >> > +reside in the least-significant bits of the corresponding linear > >> > +format. For example, COMP(bits): > >> > + > >> > + * DRM_FORMAT_ABGR > >> > + > >> > + * Component 0: R(8) > >> > + * Component 1: G(8) > >> > + * Component 2: B(8) > >> > + * Component 3: A(8) > >> > + > >> > + * DRM_FORMAT_BGR
[Bug 109206] Kernel 4.20 amdgpu fails to load firmware on Ryzen 2500U
https://bugs.freedesktop.org/show_bug.cgi?id=109206 Nicola Orlando changed: What|Removed |Added CC||niki.o...@yahoo.it --- Comment #5 from Nicola Orlando --- Created attachment 143105 --> https://bugs.freedesktop.org/attachment.cgi?id=143105&action=edit Kernel log on 5.0.0-rc2 showing firmware loading crash I'm getting the exact same issue on 5.0.0 rc2; kernel log attached. Both the list of files in /lib/firmware/amdgpu/ and the raven_dmcu.bin are identical to the ones already 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
[Bug 202261] New: general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue
https://bugzilla.kernel.org/show_bug.cgi?id=202261 Bug ID: 202261 Summary: general protection fault: [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue Product: Drivers Version: 2.5 Kernel Version: 5.0.0-rc2 Hardware: All OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: johannes.hi...@datenkhaos.de Regression: No first seen with kernel 5.0.0-rc1, now again with 5.0.0-rc2 Jan 14 15:05:49 probook kernel: general protection fault: [#1] PREEMPT SMP Jan 14 15:05:50 probook kernel: CPU: 1 PID: 3697 Comm: kworker/1:2 Not tainted 5.0.0-rc2 #66 Jan 14 15:05:50 probook kernel: Hardware name: HP HP ProBook 645 G2/80FE, BIOS N77 Ver. 01.15 03/26/2018 Jan 14 15:05:50 probook kernel: Workqueue: events ttm_bo_delayed_workqueue Jan 14 15:05:50 probook kernel: RIP: 0010:__memcpy+0x12/0x20 Jan 14 15:05:50 probook kernel: Code: e2 20 48 09 c2 48 31 d3 e9 79 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 0f 1f 44 00 00 48 89 f8 48 89 d1 48 c1 e9 03 83 e2 07 48 a5 89 d1 f3 a4 c3 66 0f 1f 44 00 00 48 89 f8 48 89 d1 f3 a4 Jan 14 15:05:50 probook kernel: RSP: 0018:a16a03bd3d78 EFLAGS: 00010246 Jan 14 15:05:50 probook kernel: RAX: bdff99d92e158d48 RBX: 99027000 RCX: 0200 Jan 14 15:05:50 probook kernel: RDX: RSI: 967919027000 RDI: bdff99d92e158d48 Jan 14 15:05:50 probook kernel: RBP: 967cacd550b0 R08: R09: 0507 Jan 14 15:05:50 probook kernel: R10: 8080808080808080 R11: R12: 1000 Jan 14 15:05:50 probook kernel: R13: R14: 0001 R15: 0001 Jan 14 15:05:50 probook kernel: FS: () GS:967caf28() knlGS: Jan 14 15:05:50 probook kernel: CS: 0010 DS: ES: CR0: 80050033 Jan 14 15:05:50 probook kernel: CR2: 7f74431d3000 CR3: 000408d6c000 CR4: 001406e0 Jan 14 15:05:50 probook kernel: Call Trace: Jan 14 15:05:50 probook kernel: dma_direct_unmap_page+0x68/0x70 Jan 14 15:05:50 probook kernel: ttm_unmap_and_unpopulate_pages+0xd6/0xf0 Jan 14 15:05:50 probook kernel: ttm_tt_destroy.part.11+0x44/0x50 Jan 14 15:05:50 probook kernel: ttm_bo_cleanup_memtype_use+0x29/0x70 Jan 14 15:05:50 probook kernel: ttm_bo_cleanup_refs+0x10d/0x1d0 Jan 14 15:05:50 probook kernel: ttm_bo_delayed_delete+0xa3/0x1e0 Jan 14 15:05:50 probook kernel: ttm_bo_delayed_workqueue+0x12/0x40 Jan 14 15:05:50 probook kernel: process_one_work+0x1f8/0x420 Jan 14 15:05:50 probook kernel: worker_thread+0x28/0x3c0 Jan 14 15:05:50 probook kernel: ? rescuer_thread+0x330/0x330 Jan 14 15:05:50 probook kernel: kthread+0x10d/0x130 Jan 14 15:05:50 probook kernel: ? kthread_create_on_node+0x60/0x60 Jan 14 15:05:50 probook kernel: ret_from_fork+0x22/0x40 Jan 14 15:05:50 probook kernel: Modules linked in: rfcomm bnep joydev kvm_amd btusb ccp btrtl btbcm btintel bluetooth kvm irqbypass hp_wmi wmi_bmof ecdh_generic uvcvideo crc32_pclmul videobuf2_vmalloc iwlmvm videobuf2_memops videobuf2_v4l2 videode v mac80211 videobuf2_common snd_hda_codec_conexant hid_logitech_hidpp snd_hda_codec_generic aesni_intel snd_hda_codec_hdmi aes_x86_64 snd_hda_intel crypto_simd cryptd snd_hda_codec glue_helper iwlwifi psmouse snd_hwdep i2c_piix4 k10temp fam15h_pow er snd_hda_core snd_pcm cfg80211 realtek snd_timer rfkill snd r8169 soundcore libphy wmi hp_wireless hid_logitech_dj rtsx_pci_sdmmc mmc_core xhci_pci ehci_pci xhci_hcd ehci_hcd rtsx_pci efivarfs autofs4 Jan 14 15:05:50 probook kernel: ---[ end trace 06764c6abeba2453 ]--- -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC AFBC 03/12] drm/afbc: Add AFBC modifier usage documentation
On Mon, 14 Jan 2019, Brian Starkey wrote: > AFBC is a relatively well-established name, whereas arm-fbc is not a > term anyone will be familiar with. First time I ever heard of AFBC. ;) > We could name the file "arm-afbc.rst", though I am slightly against > namespacing it that way for the reason mentioned above - it > does/will/should apply to more than just the gpu/drm/arm tree. Fair enough. It's not like the name is part of the ABI, so I guess let's go with this, and we can rename later if we come up with a better name. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue
https://bugzilla.kernel.org/show_bug.cgi?id=202261 --- Comment #1 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- Hardware is an AMD PRO A10-8700B R6 CARRIZO -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue
https://bugzilla.kernel.org/show_bug.cgi?id=202261 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #2 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your dmesg output and xorg log (if using X). Is there a trigger for this or is it random? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/49] drm/omap: dsi: Fix OF platform depopulate
Hi Tomi,
On Monday, 14 January 2019 13:40:36 EET Tomi Valkeinen wrote:
> On 11/01/19 05:50, Laurent Pinchart wrote:
> > From: Tomi Valkeinen
> >
> > Commit edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> > bind to probe") moved the of_platform_populate() call from dsi_bind() to
> > dsi_probe(), but failed to move the corresponding
> > of_platform_depopulate() from dsi_unbind() to dsi_remove(). This results
> > in OF child devices being potentially removed multiple times. Fix it by
> > placing the of_platform_depopulate() call where it belongs.
> >
> > Fixes: edb715dffdee ("drm/omap: dss: dsi: Move initialization code from
> > bind to probe") Signed-off-by: Laurent Pinchart
> > ---
> >
> > drivers/gpu/drm/omapdrm/dss/dsi.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
>
> I'm not sure if you want my signed-off-by or reviewed-by for this and
> the next, but you've got it.
Author SoB is always nice to have :-) Thanks.
--
Regards,
Laurent Pinchart
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3] drm: rcar-du: add missing of_node_put
Hi Julia,
Thank you for the patch,
On 13/01/2019 09:44, Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
>
> The semantic match that finds this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @r exists@
> local idexpression e;
> expression x;
> @@
> e = of_graph_get_remote_port_parent(...);
> ... when != x = e
> when != true e == NULL
> when != of_node_put(e)
> when != of_fwnode_handle(e)
> (
> return e;
> |
> *return ...;
> )
> //
>
For this part at least:
Reviewed-by: Kieran Bingham
But a little discussion below:
> Signed-off-by: Julia Lawall
This does indeed look like a missing of_node_put() but I don't think it
will be the only one in that code. It gets a bit tangled - and I think
there's possibly another missing put on the error path of
if (!encoder) {
dev_warn(rcdu->dev,
"no encoder found for endpoint %pOF, skipping\n",
ep->local_node);
return -ENODEV;
}
because that implies that no encoder was found, and thus -
encoder = entity;
was not executed, and the tail of that function calls:
of_node_put(encoder);
which would have been the final of_node_put(entity)
I think that part could be considered separate to this patch, but it's
also quite closely related. Either way - I think it needs a second pair
of eyes to see if I'm not crazy :)
Regards
Kieran
>
> ---
> drivers/gpu/drm/rcar-du/rcar_du_kms.c |1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> index 9c7007d..bc3fcb3 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct
> rcar_du_device *rcdu,
> dev_dbg(rcdu->dev,
> "connected entity %pOF is disabled, skipping\n",
> entity);
> + of_node_put(entity);
> return -ENODEV;
> }
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb
Den 14.01.2019 03.15, skrev David Lechner: > On 1/13/19 3:19 PM, David Lechner wrote: >> On 1/11/19 2:12 PM, Noralf Trønnes wrote: >>> This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty >>> handler. All flushing will now happen in the pipe functions. >>> >>> Also enable the damage plane property for all except repaper which can >>> only do full updates. >>> >>> ili9225: >>> This change made ili9225_init() equal to mipi_dbi_init() so use it. >>> >>> v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL >>> (kbuild test robot) >>> >>> Cc: David Lechner >>> Cc: Eric Anholt >>> Signed-off-by: Noralf Trønnes >>> Acked-by: Sam Ravnborg >>> Acked-by: Daniel Vetter >>> --- >> >> Tested-by: David Lechner >> Reviewed-by: David Lechner >> >> Tested with ST7586 on LEGO MINDSTORMS EV3 and ILI9225 on >> BeagleBone Green. (FWIW, I encounter other issues that had to >> be fixed to make things work on both of these, but none were >> actually related to this series.) >> > > Actually, I have to take this back. It appears that the problems > that I had on LEGO MINDSTORMS EV3 are actually caused by this > series. I did a git bisect to be sure and ended up with this > patch as the bad commit. I'm guessing that the damage helper > must be causing some kind of memory corruption. Here is the > crash I am getting: > > Unable to handle kernel NULL pointer dereference at virtual address > 0004 > pgd = (ptrval) > [0004] *pgd= > Internal error: Oops: 5 [#1] PREEMPT ARM > Modules linked in: > CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0-rc1-00125-ge9acadba5409 #1389 > Hardware name: Generic DA850/OMAP-L138/AM18x > PC is at rb_insert_color+0x1c/0x1a4 > LR is at kernfs_link_sibling+0x94/0xcc > pc : [] lr : [] psr: 6013 > sp : c2831b38 ip : fp : c06b762c > r10: r9 : c06b835c r8 : > r7 : c2963f00 r6 : c066b028 r5 : c2016cc0 r4 : > r3 : r2 : c2983010 r1 : c2963f2c r0 : c2016cd0 > Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > Control: 0005317f Table: c0004000 DAC: 0053 > Process swapper (pid: 1, stack limit = 0x(ptrval)) > Stack: (0xc2831b38 to 0xc2832000) > 1b20: > c2016cc0 > 1b40: c066b028 c014bfdc c2016cc0 c2963f00 c066b028 c014c768 c2963f00 > c014c448 > 1b60: c2016cc0 c2963f00 c066b028 c2963f00 c014c860 > 0001 > 1b80: c0589938 c2b4b408 c014ec70 c2b4b408 > c04c4cb0 > 1ba0: 070f 9fd04dd9 c2b4b408 c066b028 > > 1bc0: c293ac98 c04b58f8 c059081c c2b4b408 c066b028 > > 1be0: c04b5d64 c2831c08 9fd04dd9 c2b4b3c0 c293ac80 c2bd16c0 > c2b4b408 > 1c00: c00d650c c059081c c2bd16c0 c28e3a80 c2b4b3c0 c2b4b3c0 > > 1c20: c06b7634 0002 c06b835c c00d72f8 c00b0c24 > 0074 > 1c40: c0590728 c0590728 c2b4b3c0 0074 c0590728 0002 > > 1c60: c06b762c c00b0958 00380bc6 c06bbf1c c2bd9c00 > c2bfe000 > 1c80: c06bbf14 000c c2831e0c c00b0a90 > > 1ca0: 003b2580 c017d6e4 > c2bfe000 > 1cc0: c2bd9c00 003b2580 c01971a0 1103 > > 1ce0: c2bd8400 0400 0400 9fd04dd9 000a 0002 > > 1d00: 0001 0a04 > 0032 > 1d20: 000c 0004 c00af550 c2bd9ecc 9fd04dd9 c2404480 > c2bd9eb4 > 1d40: c2bd8400 c2404480 0002 0001 0001 > > 1d60: 0001 > > 1d80: 00380bc6 003b257f 0077 0200 > 0002 > 1da0: 0001 0401 c2bfe22c > > 1dc0: c2012400 c24be100 1000 c2404480 > > 1de0: 4003 9fd04dd9 c2bd9c00 c2404480 0083 c24044fc > 8000 > 1e00: 0020 8000 c00e4d88 c2404480 > c0190afc > 1e20: c2bd0be0 c0692898 c0692898 0020 c0190b10 c0194f48 > c2bd0be0 > 1e40: c066b370 c00e568c c29f5380 c01002d4 c29f5380 c2bd0be0 8000 > c0100488 > 1e60: c0692898 c066b028 c2bd0be0 c2bd0bc0 c01033ec > ff00 > 1e80: 0a00 c0575ff4 c2bd0be0 c281a010 c2417098 c2bd0be0 000a > > 1ea0: 000a 9fd04dd9 000a c2bd0be0 c2bd0bc0 c0575ff8 > 8000 > 1ec0: c066b028 8000 c0575ff4 c0104178 c2014000 > c2014005 > 1ee0: c0575ff8 c3fb1280 c0652868 c062b1ec c01013d8 c24c3558 > > 1f00: 6180 c24c3558 c00f17c4 e10c76ac 0b32 c2858015 > c281a010 > 1f20: c2415da8 9fd04dd9 0002 c06ad310 c066b028 c066da68 > > 1f40: c062b478 c0037200 00306b6c > 9fd0
[Bug 202263] New: AMDGPU: DRM couldn't schedule ib on ring (-22)
https://bugzilla.kernel.org/show_bug.cgi?id=202263 Bug ID: 202263 Summary: AMDGPU: DRM couldn't schedule ib on ring (-22) Product: Drivers Version: 2.5 Kernel Version: 4.19.12-1-default Hardware: Intel OS: Linux Tree: Mainline Status: NEW Severity: high Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: e.isi...@gmail.com Regression: No Hello everyone! I have some troubles with the amdgpu driver. I'm getting some errors from the kernel when I force to use the discrete GPU. By the way, I have a hybrid GPU System. (Lenovo Laptop: Intel HD & AMD Radeon 530) First of all I cleared the dmesg logs. Then I executed: DRI_PRIME=1 glxinfo | grep OpenGL and then I got this errors: https://pastebin.com/iaejbQ2t (for full dmesg) [ 422.628116] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628146] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628147] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628182] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628185] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628212] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628214] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628241] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628243] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628271] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628273] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628300] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628301] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628328] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.628330] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628357] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) [ 422.629694] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.629743] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) But when I set the DRI_PRIME value to 0, this errors doesn't appear. I also tried with DRI_PRIME=1 glxgears. There I get TONS of errors like this here: [ 422.628301] amdgpu :01:00.0: couldn't schedule ib on ring [ 422.628328] [drm:amdgpu_job_run [amdgpu]] *ERROR* Error scheduling IBs (-22) I am using the latest version of OpenSUSE tumbleweed. Kernel: 4.19.12-1-default amdgpu is installed & kernel-firmware, too. Thanks!! -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109332] xf86-video-amdgpu - commit 0d60233d introduced stuttering with mouse cursor operations
https://bugs.freedesktop.org/show_bug.cgi?id=109332 --- Comment #3 from Michel Dänzer --- (In reply to Nicholas Kazlauskas from comment #2) > Maybe this can be a configurable option in the meantime? > I'm not sure how much work that would be to add and maintain, though. Yeah, I'm afraid I'm not really hot on adding an option for this. We can't ask Wayland compositors to work around this, either. -- 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 202263] AMDGPU: DRM couldn't schedule ib on ring (-22)
https://bugzilla.kernel.org/show_bug.cgi?id=202263 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #1 from Alex Deucher (alexdeuc...@gmail.com) --- Please attach your full dmesg output form boot (so it doesn't get lost when the pastebin goes away) and xorg log (if using X). -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/meson: Fix atomic mode switching regression
Hi Martin,
On 09/01/2019 23:18, Martin Blumenstingl wrote:
> Hi Neil,
>
> On Wed, Jan 9, 2019 at 2:36 PM Neil Armstrong wrote:
>>
>> Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
>> example) the display gets blurry, looking like an invalid framebuffer width.
>>
>> This commit fixed atomic crtc modesetting but didn't update the display
>> parameters when changing mode, but only when starting a mode setting after
>> a crtc disable.
>>
>> This commit setups the crctc parameter in _begin() and _enable() to
>> take in account the current ctrc parameters.
>>
>> Reported-by: Tony McKahan
>> Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
>> Signed-off-by: Neil Armstrong
>> ---
>> drivers/gpu/drm/meson/meson_crtc.c | 16 +---
>> 1 file changed, 13 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/meson/meson_crtc.c
>> b/drivers/gpu/drm/meson/meson_crtc.c
>> index 75d97f1b2e8f..5bb432021caf 100644
>> --- a/drivers/gpu/drm/meson/meson_crtc.c
>> +++ b/drivers/gpu/drm/meson/meson_crtc.c
>> @@ -82,14 +82,12 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
>>
>> };
>>
>> -static void meson_crtc_enable(struct drm_crtc *crtc)
>> +static void meson_crtc_setup(struct drm_crtc *crtc)
>> {
>> struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> struct drm_crtc_state *crtc_state = crtc->state;
>> struct meson_drm *priv = meson_crtc->priv;
>>
>> - DRM_DEBUG_DRIVER("\n");
>> -
>> if (!crtc_state) {
>> DRM_ERROR("Invalid crtc_state\n");
>> return;
>> @@ -98,6 +96,16 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
>> /* Enable VPP Postblend */
> nit-pick: this "enable" comment is now in meson_crtc_setup().
> I would drop it because my interpretation of the following lines is
> now "setting VPP_POSTBLEND_H_SIZE enables the VPP postblend"
>
>> writel(crtc_state->mode.hdisplay,
>>priv->io_base + _REG(VPP_POSTBLEND_H_SIZE));
>> +}
>> +
>> +static void meson_crtc_enable(struct drm_crtc *crtc)
>> +{
>> + struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
>> + struct meson_drm *priv = meson_crtc->priv;
>> +
>> + DRM_DEBUG_DRIVER("\n");
>> +
>> + meson_crtc_setup(crtc);
>>
>> /* VD1 Preblend vertical start/end */
>> writel(FIELD_PREP(GENMASK(11, 0), 2303),
>> @@ -121,6 +129,8 @@ static void meson_crtc_atomic_enable(struct drm_crtc
>> *crtc,
>>
>> if (!meson_crtc->enabled)
>> meson_crtc_enable(crtc);
>> + else
>> + meson_crtc_setup(crtc);
> it's probably only personal preference, but have you thought about
> re-ordering this:
> meson_crtc_setup(crtc);
>
> if (!meson_crtc->enabled)
> meson_crtc_enable(crtc);
>
> with that you could get rid of the meson_crtc_setup() call in
> meson_crtc_enable(), leaving only one code-path (instead of two) which
> calls meson_crtc_setup()
All of this is wrong, I only needed to use `atomic_commit_tail =
drm_atomic_helper_commit_tail_rpm`
in meson_drv for the fbdev.
This fix is wrong, pushing a right one.
Neil
>
>
> Regards
> Martin
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] [RFC] drm_hwcomposer: Add support for Arm Framebuffer Compression (AFBC) modifiers.
One needs to translate the Gralloc buffer flags for AFBC (eg
MALI_GRALLOC_INTFMT_AFBC_BASIC) to the corresponding linux kernel drm modifiers.
This gets passed to libdrm via drmModeAddFB2WithModifiers.
Signed-off-by: Ayan Kumar Halder
/-- Note for reviewer
I was able to get this working for Android P on Juno with Mali DP650 and Mali
T860 gpu(with some additional hacks). I have not yet validated this hikey960.
I have used the following components:-
1. Gralloc (from
https://android.googlesource.com/device/linaro/hikey/+/master/gralloc960)
- Built with MALI_MMSS=1
2. Libdrm (from git://anongit.freedesktop.org/mesa/drm)
- You would need drm_fourcc.h and gralloc_handle.h
--/
---
platformdrmgeneric.cpp | 42 ++
platformdrmgeneric.h | 2 ++
platformhisi.cpp | 14 --
3 files changed, 56 insertions(+), 2 deletions(-)
diff --git a/platformdrmgeneric.cpp b/platformdrmgeneric.cpp
index 503c04a..a520224 100644
--- a/platformdrmgeneric.cpp
+++ b/platformdrmgeneric.cpp
@@ -18,6 +18,7 @@
#include "platformdrmgeneric.h"
#include "drmdevice.h"
+#include "mali_gralloc_formats.h"
#include "platform.h"
#include
@@ -83,6 +84,31 @@ uint32_t DrmGenericImporter::ConvertHalFormatToDrm(uint32_t
hal_format) {
}
}
+uint64_t DrmGenericImporter::ConvertGrallocFormatToDrmModifiers(uint64_t flags,
+bool is_rgb) {
+ uint64_t features = 0;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_BASIC)
+features |= AFBC_FORMAT_MOD_BLOCK_SIZE_16x16;
+
+ if (is_rgb)
+features |= AFBC_FORMAT_MOD_YTR;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_SPLITBLK)
+features |= (AFBC_FORMAT_MOD_SPLIT | AFBC_FORMAT_MOD_SPARSE);
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_WIDEBLK)
+features |= AFBC_FORMAT_MOD_BLOCK_SIZE_32x8;
+
+ if (flags & MALI_GRALLOC_INTFMT_AFBC_TILED_HEADERS)
+features |= AFBC_FORMAT_MOD_TILED;
+
+ if (features)
+return DRM_FORMAT_MOD_ARM_AFBC(features);
+ else
+return 0;
+}
+
uint32_t DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
switch (drm_format) {
case DRM_FORMAT_ARGB:
@@ -101,6 +127,22 @@ uint32_t
DrmGenericImporter::DrmFormatToBitsPerPixel(uint32_t drm_format) {
}
}
+bool DrmGenericImporter::IsDrmFormatRgb(uint32_t drm_format) {
+ switch (drm_format) {
+case DRM_FORMAT_ARGB:
+case DRM_FORMAT_XBGR:
+case DRM_FORMAT_ABGR:
+case DRM_FORMAT_BGR888:
+case DRM_FORMAT_BGR565:
+ return true;
+case DRM_FORMAT_YVU420:
+ return false;
+default:
+ ALOGE("Unsupported format %u assuming rgb?", drm_format);
+ return true;
+ }
+}
+
int DrmGenericImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo)
{
gralloc_handle_t *gr_handle = gralloc_handle(handle);
if (!gr_handle)
diff --git a/platformdrmgeneric.h b/platformdrmgeneric.h
index 233ba55..43cb618 100644
--- a/platformdrmgeneric.h
+++ b/platformdrmgeneric.h
@@ -36,6 +36,8 @@ class DrmGenericImporter : public Importer {
bool CanImportBuffer(buffer_handle_t handle) override;
uint32_t ConvertHalFormatToDrm(uint32_t hal_format);
+ uint64_t ConvertGrallocFormatToDrmModifiers(uint64_t flags, bool is_rgb);
+ bool IsDrmFormatRgb(uint32_t drm_format);
uint32_t DrmFormatToBitsPerPixel(uint32_t drm_format);
private:
diff --git a/platformhisi.cpp b/platformhisi.cpp
index 76fe1e7..1cb7e2c 100644
--- a/platformhisi.cpp
+++ b/platformhisi.cpp
@@ -71,6 +71,9 @@ int HisiImporter::Init() {
}
int HisiImporter::ImportBuffer(buffer_handle_t handle, hwc_drm_bo_t *bo) {
+ bool is_rgb;
+ uint64_t modifiers[4] = {0};
+
memset(bo, 0, sizeof(hwc_drm_bo_t));
private_handle_t const *hnd = reinterpret_cast(
@@ -94,6 +97,10 @@ int HisiImporter::ImportBuffer(buffer_handle_t handle,
hwc_drm_bo_t *bo) {
if (fmt < 0)
return fmt;
+ is_rgb = IsDrmFormatRgb(fmt);
+ modifiers[0] = ConvertGrallocFormatToDrmModifiers(hnd->internal_format,
+is_rgb);
+
bo->width = hnd->width;
bo->height = hnd->height;
bo->hal_format = hnd->req_format;
@@ -129,8 +136,11 @@ int HisiImporter::ImportBuffer(buffer_handle_t handle,
hwc_drm_bo_t *bo) {
break;
}
- ret = drmModeAddFB2(drm_->fd(), bo->width, bo->height, bo->format,
- bo->gem_handles, bo->pitches, bo->offsets, &bo->fb_id,
0);
+ ret = drmModeAddFB2WithModifiers(drm_->fd(), bo->width, bo->height,
+ bo->format, bo->gem_handles, bo->pitches,
+ bo->offsets, modifiers, &bo->fb_id,
+ modifiers[0] ? DRM_MODE_FB_MODIFIERS : 0);
+
if (ret) {
ALOGE("could not create drm fb %d", ret);
return ret;
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/meson: Fix atomic mode switching regression
Since commit 2bcd3ecab773 when switching mode from X11 (ubuntu mate for
example) the display gets blurry, looking like an invalid framebuffer width.
This commit fixed atomic crtc modesetting in a totally wrong way and
introduced a local unnecessary ->enabled crtc state.
This commit reverts the crctc _begin() and _enable() changes and simply
adds drm_atomic_helper_commit_tail_rpm as helper.
Reported-by: Tony McKahan
Suggested-by: Daniel Vetter
Fixes: 2bcd3ecab773 ("drm/meson: Fixes for drm_crtc_vblank_on/off support")
Signed-off-by: Neil Armstrong
---
drivers/gpu/drm/meson/meson_crtc.c | 23 ++-
drivers/gpu/drm/meson/meson_drv.c | 6 ++
2 files changed, 8 insertions(+), 21 deletions(-)
Changes since v1:
- drop the unecessary local ->enabled logic
- use drm_atomic_helper_commit_tail_rpm as atomic_commit_tail helper
diff --git a/drivers/gpu/drm/meson/meson_crtc.c
b/drivers/gpu/drm/meson/meson_crtc.c
index 75d97f1b2e8f..4f5c67f70c4d 100644
--- a/drivers/gpu/drm/meson/meson_crtc.c
+++ b/drivers/gpu/drm/meson/meson_crtc.c
@@ -46,7 +46,6 @@ struct meson_crtc {
struct drm_crtc base;
struct drm_pending_vblank_event *event;
struct meson_drm *priv;
- bool enabled;
};
#define to_meson_crtc(x) container_of(x, struct meson_crtc, base)
@@ -82,7 +81,8 @@ static const struct drm_crtc_funcs meson_crtc_funcs = {
};
-static void meson_crtc_enable(struct drm_crtc *crtc)
+static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
+struct drm_crtc_state *old_state)
{
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
struct drm_crtc_state *crtc_state = crtc->state;
@@ -108,20 +108,6 @@ static void meson_crtc_enable(struct drm_crtc *crtc)
drm_crtc_vblank_on(crtc);
- meson_crtc->enabled = true;
-}
-
-static void meson_crtc_atomic_enable(struct drm_crtc *crtc,
-struct drm_crtc_state *old_state)
-{
- struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
- struct meson_drm *priv = meson_crtc->priv;
-
- DRM_DEBUG_DRIVER("\n");
-
- if (!meson_crtc->enabled)
- meson_crtc_enable(crtc);
-
priv->viu.osd1_enabled = true;
}
@@ -153,8 +139,6 @@ static void meson_crtc_atomic_disable(struct drm_crtc *crtc,
crtc->state->event = NULL;
}
-
- meson_crtc->enabled = false;
}
static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
@@ -163,9 +147,6 @@ static void meson_crtc_atomic_begin(struct drm_crtc *crtc,
struct meson_crtc *meson_crtc = to_meson_crtc(crtc);
unsigned long flags;
- if (crtc->state->enable && !meson_crtc->enabled)
- meson_crtc_enable(crtc);
-
if (crtc->state->event) {
WARN_ON(drm_crtc_vblank_get(crtc) != 0);
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index 3ee4d4a4ecba..a74d861ddceb 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -75,6 +75,11 @@ static const struct drm_mode_config_funcs
meson_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
};
+
+static const struct drm_mode_config_helper_funcs meson_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
static irqreturn_t meson_irq(int irq, void *arg)
{
struct drm_device *dev = arg;
@@ -266,6 +271,7 @@ static int meson_drv_bind_master(struct device *dev, bool
has_components)
drm->mode_config.max_width = 3840;
drm->mode_config.max_height = 2160;
drm->mode_config.funcs = &meson_mode_config_funcs;
+ drm->mode_config.helper_private = &meson_mode_config_helpers;
/* Hardware Initialization */
--
2.20.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/3] drm/meson: add missing of_node_put
Hi Julia,
On 13/01/2019 10:44, Julia Lawall wrote:
> Add an of_node_put when the result of of_graph_get_remote_port_parent is
> not available.
>
> An of_node_put is also needed when meson_probe_remote completes. This was
> present at the recursive call, but not in the call from meson_drv_probe.
>
> The semantic match that finds this problem is as follows
> (http://coccinelle.lip6.fr):
>
> //
> @r exists@
> local idexpression e;
> expression x;
> @@
> e = of_graph_get_remote_port_parent(...);
> ... when != x = e
> when != true e == NULL
> when != of_node_put(e)
> when != of_fwnode_handle(e)
> (
> return e;
> |
> *return ...;
> )
> //
>
> Signed-off-by: Julia Lawall
Acked-by: Neil Armstrong
And applied to drm-misc-fixes.
Neil
>
> ---
> drivers/gpu/drm/meson/meson_drv.c |9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_drv.c
> b/drivers/gpu/drm/meson/meson_drv.c
> index 3ee4d4a4e..b59c757 100644
> --- a/drivers/gpu/drm/meson/meson_drv.c
> +++ b/drivers/gpu/drm/meson/meson_drv.c
> @@ -388,8 +388,10 @@ static int meson_probe_remote(struct platform_device
> *pdev,
> remote_node = of_graph_get_remote_port_parent(ep);
> if (!remote_node ||
> remote_node == parent || /* Ignore parent endpoint */
> - !of_device_is_available(remote_node))
> + !of_device_is_available(remote_node)) {
> + of_node_put(remote_node);
> continue;
> + }
>
> count += meson_probe_remote(pdev, match, remote, remote_node);
>
> @@ -408,10 +410,13 @@ static int meson_drv_probe(struct platform_device *pdev)
>
> for_each_endpoint_of_node(np, ep) {
> remote = of_graph_get_remote_port_parent(ep);
> - if (!remote || !of_device_is_available(remote))
> + if (!remote || !of_device_is_available(remote)) {
> + of_node_put(remote);
> continue;
> + }
>
> count += meson_probe_remote(pdev, &match, np, remote);
> + of_node_put(remote);
> }
>
> if (count && !match)
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RESEND] drm/meson: remove firmware framebuffers
On 12/12/2018 13:39, Neil Armstrong wrote:
> On 12/12/2018 13:22, Maxime Jourdan wrote:
>> Hi Neil,
>> On Wed, Dec 12, 2018 at 10:55 AM Neil Armstrong
>> wrote:
>>>
>>> Hi Maxime,
>>>
>>> On 10/12/2018 10:28, Maxime Jourdan wrote:
In case we are using simplefb or another conflicting framebuffer, make
the call to drm_fb_helper_remove_conflicting_framebuffers()
Signed-off-by: Maxime Jourdan
---
drivers/gpu/drm/meson/meson_drv.c | 20
1 file changed, 20 insertions(+)
diff --git a/drivers/gpu/drm/meson/meson_drv.c
b/drivers/gpu/drm/meson/meson_drv.c
index d3443125e661..afbb3d707d15 100644
--- a/drivers/gpu/drm/meson/meson_drv.c
+++ b/drivers/gpu/drm/meson/meson_drv.c
@@ -159,6 +159,23 @@ static void meson_vpu_init(struct meson_drm *priv)
writel_relaxed(0x2, priv->io_base + _REG(VPU_WRARB_MODE_L2C1));
}
+static void meson_remove_framebuffers(void)
+{
+ struct apertures_struct *ap;
+
+ ap = alloc_apertures(1);
+ if (!ap)
+ return;
+
+ /* The framebuffer can be located anywhere in RAM */
+ ap->ranges[0].base = 0;
+ ap->ranges[0].size = ~0;
+
+ drm_fb_helper_remove_conflicting_framebuffers(ap, "meson-drm-fb",
+ false);
>>>
>>> I always wondered, where does the "meson-drm-fb" comes from ???
>>>
>>> Neil
>>>
>>
>> This name ultimately ends up in a printk and has no functional impact.
>> See drivers/video/fbdev/core/fbmem.c:1613 :
>>
>> printk(KERN_INFO "fb%d: switching to %s from %s\n", i, name,
>> registered_fb[i]->fix.id);
>>
>> I just picked one that was similar to the names of other drm drivers
>> calling drm_fb_helper_remove_conflicting_framebuffers().
>
> Ok Cool !
>
>>
>> Maxime
>>
>
> Acked-by: Neil Armstrong
>
> I'll push it when the bindings are acked and when v4.21-rc1 is tagged !
>
> Neil
>
Applied to drm-misc-next.
Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported
https://bugs.freedesktop.org/show_bug.cgi?id=109135 --- Comment #16 from Alex Deucher --- Does removing amdgpu.dpm=1 from the kernel command line fix the issue? -- 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 v3 3/7] drm: meson: Cleanup on drm_display_mode print str
Hi Shayenne,
On 10/01/2019 18:16, Shayenne Moura wrote:
> This patch adjust the print string of drm_display_mode object
> to remove drm_mode_object dependency in meson files.
>
> Signed-off-by: Shayenne Moura
Totally missed this one... please respect MAINTAINERS and CC the linux-amlogic
ML otherwise I'll miss it again.
> ---
> Changes in v2:
> - Use DRM_MODE_FMT/ARG macros (Daniel)
> - Make the commit message more clear
>
> Changes in v3:
> - No changes
>
> drivers/gpu/drm/meson/meson_dw_hdmi.c | 12 +++-
> 1 file changed, 3 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> index d8c5cc34e22e..0b6c29cdd934 100644
> --- a/drivers/gpu/drm/meson/meson_dw_hdmi.c
> +++ b/drivers/gpu/drm/meson/meson_dw_hdmi.c
> @@ -365,7 +365,7 @@ static int dw_hdmi_phy_init(struct dw_hdmi *hdmi, void
> *data,
> unsigned int wr_clk =
> readl_relaxed(priv->io_base + _REG(VPU_HDMI_SETTING));
>
> - DRM_DEBUG_DRIVER("%d:\"%s\"\n", mode->base.id, mode->name);
> + DRM_DEBUG_DRIVER("\"%s\"\n", mode->name);
>
> /* Enable clocks */
> regmap_update_bits(priv->hhi, HHI_HDMI_CLK_CNTL, 0x, 0x100);
> @@ -555,12 +555,7 @@ dw_hdmi_mode_valid(struct drm_connector *connector,
> int vic = drm_match_cea_mode(mode);
> enum drm_mode_status status;
>
> - DRM_DEBUG_DRIVER("Modeline %d:\"%s\" %d %d %d %d %d %d %d %d %d %d 0x%x
> 0x%x\n",
> - mode->base.id, mode->name, mode->vrefresh, mode->clock,
> - mode->hdisplay, mode->hsync_start,
> - mode->hsync_end, mode->htotal,
> - mode->vdisplay, mode->vsync_start,
> - mode->vsync_end, mode->vtotal, mode->type, mode->flags);
> + DRM_DEBUG_DRIVER("Modeline " DRM_MODE_FMT "\n", DRM_MODE_ARG(mode));
>
> /* Check against non-VIC supported modes */
> if (!vic) {
> @@ -650,8 +645,7 @@ static void meson_venc_hdmi_encoder_mode_set(struct
> drm_encoder *encoder,
> struct meson_drm *priv = dw_hdmi->priv;
> int vic = drm_match_cea_mode(mode);
>
> - DRM_DEBUG_DRIVER("%d:\"%s\" vic %d\n",
> - mode->base.id, mode->name, vic);
> + DRM_DEBUG_DRIVER("\"%s\" vic %d\n", mode->name, vic);
>
> /* VENC + VENC-DVI Mode setup */
> meson_venc_hdmi_mode_set(priv, vic, mode);
>
Anyway it's ok for me.
Reviewed-by: Neil Armstrong
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd: fix typo
Applied. thanks.
Alex
On Mon, Jan 7, 2019 at 8:06 AM Matteo Croce wrote:
>
> Fix spelling mistake: "lenght" -> "length"
>
> Signed-off-by: Matteo Croce
> ---
> drivers/gpu/drm/amd/include/atombios.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/include/atombios.h
> b/drivers/gpu/drm/amd/include/atombios.h
> index 7931502fa54f..8ba21747b40a 100644
> --- a/drivers/gpu/drm/amd/include/atombios.h
> +++ b/drivers/gpu/drm/amd/include/atombios.h
> @@ -4106,7 +4106,7 @@ typedef struct _ATOM_LCD_MODE_CONTROL_CAP
> typedef struct _ATOM_FAKE_EDID_PATCH_RECORD
> {
>UCHAR ucRecordType;
> - UCHAR ucFakeEDIDLength; // = 128 means EDID lenght is 128 bytes,
> otherwise the EDID length = ucFakeEDIDLength*128
> + UCHAR ucFakeEDIDLength; // = 128 means EDID length is 128 bytes,
> otherwise the EDID length = ucFakeEDIDLength*128
>UCHAR ucFakeEDIDString[1];// This actually has ucFakeEdidLength
> elements.
> } ATOM_FAKE_EDID_PATCH_RECORD;
>
> --
> 2.20.1
>
> ___
> 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
Re: [PATCH v2 4/5] drm/tinydrm: Use damage helper for dirtyfb
Den 14.01.2019 16.00, skrev Noralf Trønnes: > > > Den 14.01.2019 03.15, skrev David Lechner: >> On 1/13/19 3:19 PM, David Lechner wrote: >>> On 1/11/19 2:12 PM, Noralf Trønnes wrote: This switches to drm_atomic_helper_dirtyfb() as the framebuffer dirty handler. All flushing will now happen in the pipe functions. Also enable the damage plane property for all except repaper which can only do full updates. ili9225: This change made ili9225_init() equal to mipi_dbi_init() so use it. v2: Remove fb check in mipi_dbi_enable_flush() it can't be NULL (kbuild test robot) Cc: David Lechner Cc: Eric Anholt Signed-off-by: Noralf Trønnes Acked-by: Sam Ravnborg Acked-by: Daniel Vetter --- >>> >>> Tested-by: David Lechner >>> Reviewed-by: David Lechner >>> >>> Tested with ST7586 on LEGO MINDSTORMS EV3 and ILI9225 on >>> BeagleBone Green. (FWIW, I encounter other issues that had to >>> be fixed to make things work on both of these, but none were >>> actually related to this series.) >>> >> >> Actually, I have to take this back. It appears that the problems >> that I had on LEGO MINDSTORMS EV3 are actually caused by this >> series. I did a git bisect to be sure and ended up with this >> patch as the bad commit. I'm guessing that the damage helper >> must be causing some kind of memory corruption. Here is the >> crash I am getting: >> >> Unable to handle kernel NULL pointer dereference at virtual address >> 0004 >> pgd = (ptrval) >> [0004] *pgd= >> Internal error: Oops: 5 [#1] PREEMPT ARM >> Modules linked in: >> CPU: 0 PID: 1 Comm: swapper Not tainted 5.0.0-rc1-00125-ge9acadba5409 #1389 >> Hardware name: Generic DA850/OMAP-L138/AM18x >> PC is at rb_insert_color+0x1c/0x1a4 >> LR is at kernfs_link_sibling+0x94/0xcc >> pc : [] lr : [] psr: 6013 >> sp : c2831b38 ip : fp : c06b762c >> r10: r9 : c06b835c r8 : >> r7 : c2963f00 r6 : c066b028 r5 : c2016cc0 r4 : >> r3 : r2 : c2983010 r1 : c2963f2c r0 : c2016cd0 >> Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none >> Control: 0005317f Table: c0004000 DAC: 0053 >> Process swapper (pid: 1, stack limit = 0x(ptrval)) >> Stack: (0xc2831b38 to 0xc2832000) >> 1b20: >> c2016cc0 >> 1b40: c066b028 c014bfdc c2016cc0 c2963f00 c066b028 c014c768 c2963f00 >> c014c448 >> 1b60: c2016cc0 c2963f00 c066b028 c2963f00 c014c860 >> 0001 >> 1b80: c0589938 c2b4b408 c014ec70 c2b4b408 >> c04c4cb0 >> 1ba0: 070f 9fd04dd9 c2b4b408 c066b028 >> >> 1bc0: c293ac98 c04b58f8 c059081c c2b4b408 c066b028 >> >> 1be0: c04b5d64 c2831c08 9fd04dd9 c2b4b3c0 c293ac80 c2bd16c0 >> c2b4b408 >> 1c00: c00d650c c059081c c2bd16c0 c28e3a80 c2b4b3c0 c2b4b3c0 >> >> 1c20: c06b7634 0002 c06b835c c00d72f8 c00b0c24 >> 0074 >> 1c40: c0590728 c0590728 c2b4b3c0 0074 c0590728 0002 >> >> 1c60: c06b762c c00b0958 00380bc6 c06bbf1c c2bd9c00 >> c2bfe000 >> 1c80: c06bbf14 000c c2831e0c c00b0a90 >> >> 1ca0: 003b2580 c017d6e4 >> c2bfe000 >> 1cc0: c2bd9c00 003b2580 c01971a0 1103 >> >> 1ce0: c2bd8400 0400 0400 9fd04dd9 000a 0002 >> >> 1d00: 0001 0a04 >> 0032 >> 1d20: 000c 0004 c00af550 c2bd9ecc 9fd04dd9 c2404480 >> c2bd9eb4 >> 1d40: c2bd8400 c2404480 0002 0001 0001 >> >> 1d60: 0001 >> >> 1d80: 00380bc6 003b257f 0077 0200 >> 0002 >> 1da0: 0001 0401 c2bfe22c >> >> 1dc0: c2012400 c24be100 1000 c2404480 >> >> 1de0: 4003 9fd04dd9 c2bd9c00 c2404480 0083 c24044fc >> 8000 >> 1e00: 0020 8000 c00e4d88 c2404480 >> c0190afc >> 1e20: c2bd0be0 c0692898 c0692898 0020 c0190b10 c0194f48 >> c2bd0be0 >> 1e40: c066b370 c00e568c c29f5380 c01002d4 c29f5380 c2bd0be0 8000 >> c0100488 >> 1e60: c0692898 c066b028 c2bd0be0 c2bd0bc0 c01033ec >> ff00 >> 1e80: 0a00 c0575ff4 c2bd0be0 c281a010 c2417098 c2bd0be0 000a >> >> 1ea0: 000a 9fd04dd9 000a c2bd0be0 c2bd0bc0 c0575ff8 >> 8000 >> 1ec0: c066b028 8000 c0575ff4 c0104178 c2014000 >> c2014005 >> 1ee0: c0575ff8 c3fb1280 c0652868 c062b1ec c01013d8 c24c3558 >> >> 1f00: 6180 c24c3558 c00f17c4 e10c76ac 0b32 c2858015 >> c28
[Bug 108493] Unigine Heaven at 4K crashes amdgpu and causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=108493 --- Comment #17 from Timur Kristóf --- Hi Everyone, I've just tested Linux 5.0-rc1 and have not encountered the problem so far. Looking into it more, I think the same patch set that fixed the Sapphire RX 590 for Michael @ Phoronix also fixed my Sapphire RX 570. Assuming this is the main patch that fixed the issue: https://github.com/torvalds/linux/commit/816b6931315b641c5864cf33a9363cb89da05d0b (specifically the line that sets ucEnableApplyAVFS_CKS_OFF_Voltage). Looking at the code, it seems a bunch other GPUs are affected (besides the RX 590 and RX 570). Could you guys please send this patch series for inclusion into the stable kernel? Since it fixes a huge stability issue I think it is a reasonable request. -- 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/3] drm: rcar-du: add missing of_node_put
On Mon, 14 Jan 2019, Kieran Bingham wrote:
> Hi Julia,
>
> Thank you for the patch,
>
> On 13/01/2019 09:44, Julia Lawall wrote:
> > Add an of_node_put when the result of of_graph_get_remote_port_parent is
> > not available.
> >
> > The semantic match that finds this problem is as follows
> > (http://coccinelle.lip6.fr):
> >
> > //
> > @r exists@
> > local idexpression e;
> > expression x;
> > @@
> > e = of_graph_get_remote_port_parent(...);
> > ... when != x = e
> > when != true e == NULL
> > when != of_node_put(e)
> > when != of_fwnode_handle(e)
> > (
> > return e;
> > |
> > *return ...;
> > )
> > //
> >
>
> For this part at least:
>
> Reviewed-by: Kieran Bingham
>
> But a little discussion below:
>
>
> > Signed-off-by: Julia Lawall
>
> This does indeed look like a missing of_node_put() but I don't think it
> will be the only one in that code. It gets a bit tangled - and I think
> there's possibly another missing put on the error path of
>
> if (!encoder) {
> dev_warn(rcdu->dev,
> "no encoder found for endpoint %pOF, skipping\n",
> ep->local_node);
> return -ENODEV;
> }
>
> because that implies that no encoder was found, and thus -
> encoder = entity;
>
> was not executed, and the tail of that function calls:
>
> of_node_put(encoder);
>
> which would have been the final of_node_put(entity)
Looking at it again, I agree. I can just extend this patch.
julia
>
>
> I think that part could be considered separate to this patch, but it's
> also quite closely related. Either way - I think it needs a second pair
> of eyes to see if I'm not crazy :)
>
> Regards
>
> Kieran
>
> >
> > ---
> > drivers/gpu/drm/rcar-du/rcar_du_kms.c |1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > index 9c7007d..bc3fcb3 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c
> > @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct
> > rcar_du_device *rcdu,
> > dev_dbg(rcdu->dev,
> > "connected entity %pOF is disabled, skipping\n",
> > entity);
> > + of_node_put(entity);
> > return -ENODEV;
> > }
> >
> >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: stop always moving BOs on the LRU on page fault
On 2019-01-11 8:12 p.m., Christian König wrote:
> Am 11.01.19 um 15:17 schrieb Michel Dänzer:
>> On 2019-01-11 2:15 p.m., Christian König wrote:
>>> Move the BO on the LRU only when it is actually moved by a DMA
>>> operation.
>>>
>>> [...]
>>>
>>> @@ -177,6 +175,13 @@ static vm_fault_t ttm_bo_vm_fault(struct
>>> vm_fault *vmf)
>>> ret = VM_FAULT_SIGBUS;
>>> goto out_unlock;
>>> }
>>> +
>>> + if (bo->moving != moving) {
>> Hmm, could a driver just update the existing fence instead of attaching
>> a new one?
>
> Mhm, not as far as I know. That would violate similar checks elsewhere.
Makes sense, my R-b stands.
--
Earthling Michel Dänzer | http://www.amd.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
[PATCH] etnaviv: allow to build on ARC
ARC HSDK SoC has Vivante GPU IP so allow build etnaviv for ARC. Signed-off-by: Eugeniy Paltsev --- drivers/gpu/drm/etnaviv/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/Kconfig b/drivers/gpu/drm/etnaviv/Kconfig index 342591a1084e..49a9957c3373 100644 --- a/drivers/gpu/drm/etnaviv/Kconfig +++ b/drivers/gpu/drm/etnaviv/Kconfig @@ -2,7 +2,7 @@ config DRM_ETNAVIV tristate "ETNAVIV (DRM support for Vivante GPU IP cores)" depends on DRM - depends on ARCH_MXC || ARCH_DOVE || ARM || COMPILE_TEST + depends on ARCH_MXC || ARCH_DOVE || ARM || ARC || COMPILE_TEST depends on MMU select SHMEM select SYNC_FILE -- 2.14.5 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v10 1/2] drm/fourcc: Add new P010, P016 video format
On Thu, Jan 10, 2019 at 03:57:09AM +0800, Randy Li wrote:
> P010 is a planar 4:2:0 YUV with interleaved UV plane, 10 bits per
> channel video format.
>
> P012 is a planar 4:2:0 YUV 12 bits per channel
>
> P016 is a planar 4:2:0 YUV with interleaved UV plane, 16 bits per
> channel video format.
>
> V3: Added P012 and fixed cpp for P010.
> V4: format definition refined per review.
> V5: Format comment block for each new pixel format.
> V6: reversed Cb/Cr order in comments.
> v7: reversed Cb/Cr order in comments of header files, remove
> the wrong part of commit message.
> V8: reversed V7 changes except commit message and rebased.
> v9: used the new properties to describe those format and
> rebased.
>
> Cc: Daniel Stone
> Cc: Ville Syrj??l??
>
> Signed-off-by: Randy Li
> Signed-off-by: Clint Taylor
> ---
> drivers/gpu/drm/drm_fourcc.c | 9 +
> include/uapi/drm/drm_fourcc.h | 21 +
> 2 files changed, 30 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_fourcc.c b/drivers/gpu/drm/drm_fourcc.c
> index d90ee03a84c6..ba7e19d4336c 100644
> --- a/drivers/gpu/drm/drm_fourcc.c
> +++ b/drivers/gpu/drm/drm_fourcc.c
> @@ -238,6 +238,15 @@ const struct drm_format_info *__drm_format_info(u32
> format)
> { .format = DRM_FORMAT_X0L2,.depth = 0,
> .num_planes = 1,
> .char_per_block = { 8, 0, 0 }, .block_w = { 2, 0, 0 },
> .block_h = { 2, 0, 0 },
> .hsub = 2, .vsub = 2, .is_yuv = true },
> + { .format = DRM_FORMAT_P010,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> + .hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P012,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> +.hsub = 2, .vsub = 2, .is_yuv = true},
> + { .format = DRM_FORMAT_P016,.depth = 0,
> .num_planes = 2,
> + .char_per_block = { 2, 4, 0 }, .block_w = { 1, 0, 0 },
> .block_h = { 1, 0, 0 },
> + .hsub = 2, .vsub = 2, .is_yuv = true},
> };
>
> unsigned int i;
> diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> index 0b44260a5ee9..8dd1328bc8d6 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -195,6 +195,27 @@ extern "C" {
> #define DRM_FORMAT_NV24 fourcc_code('N', 'V', '2', '4') /*
> non-subsampled Cr:Cb plane */
> #define DRM_FORMAT_NV42 fourcc_code('N', 'V', '4', '2') /*
> non-subsampled Cb:Cr plane */
>
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [10:6] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [10:6:10:6] little endian
> + */
> +#define DRM_FORMAT_P010 fourcc_code('P', '0', '1', '0') /* 2x2
> subsampled Cr:Cb plane 10 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y:x [12:4] little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:x:Cb:x [12:4:12:4] little endian
> + */
> +#define DRM_FORMAT_P012 fourcc_code('P', '0', '1', '2') /* 2x2
> subsampled Cr:Cb plane 12 bits per channel */
> +
> +/*
> + * 2 plane YCbCr MSB aligned
> + * index 0 = Y plane, [15:0] Y little endian
> + * index 1 = Cr:Cb plane, [31:0] Cr:Cb [16:16] little endian
> + */
> +#define DRM_FORMAT_P016 fourcc_code('P', '0', '1', '6') /* 2x2
> subsampled Cr:Cb plane 16 bits per channel */
> +
looks good to me.
Reviewed by:- Ayan Kumar Halder
We are using P010 format for our mali display driver. Our AFBC patch
series(https://patchwork.freedesktop.org/series/53395/) is dependent
on this patch. So, that's why I wanted to know when you are planning to
merge this. As far as I remember, Juha wanted to implement some igt
tests
(https://lists.freedesktop.org/archives/intel-gfx/2018-September/174877.html)
, so is that done now?
My apologies if I am pushing hard on this.
> /*
> * 3 plane YCbCr
> * index 0: Y plane, [7:0] Y
> --
> 2.20.1
>
> ___
> 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
Re: [PATCH 07/10] drm/mxsfb: Signal mode changed when bpp changed
Hi,
On Wed, Jan 09, 2019 at 02:13:47PM +, Robert Chiras wrote:
> From: Mirela Rabulea
>
> Add mxsfb_atomic_helper_check to signal mode changed when bpp changed.
> This will trigger the execution of disable/enable on
> a modeset with different bpp than the current one.
>
> Signed-off-by: Mirela Rabulea
> ---
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 48
> ++-
> 1 file changed, 47 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> index d3fb3a8..f528a37 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
> @@ -115,9 +115,55 @@ void mxsfb_disable_axi_clk(struct mxsfb_drm_private
> *mxsfb)
> clk_disable_unprepare(mxsfb->clk_axi);
> }
>
> +/**
> + * mxsfb_atomic_helper_check - validate state object
> + * @dev: DRM device
> + * @state: the driver state object
> + *
> + * On top of the drm imlementation drm_atomic_helper_check,
> + * check if the bpp is changed, if so, signal mode_changed,
> + * this will trigger disable/enable
> + *
> + * RETURNS:
> + * Zero for success or -errno
> + */
> +static int mxsfb_atomic_helper_check(struct drm_device *dev,
> + struct drm_atomic_state *state)
> +{
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + int i, ret;
> +
> + ret = drm_atomic_helper_check(dev, state);
> + if (ret)
> + return ret;
> +
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
This does not exist anymore in recent drm, see
9ba29fcb76a559078491adffc74f66bf92b9dbea.
Cheers,
-- Guido
> + struct drm_plane_state *primary_state;
> + int old_bpp = 0;
> + int new_bpp = 0;
> +
> + if (!crtc->primary || !crtc->primary->old_fb)
> + continue;
> + primary_state =
> + drm_atomic_get_plane_state(state, crtc->primary);
> + if (!primary_state || !primary_state->fb)
> + continue;
> + old_bpp = crtc->primary->old_fb->format->depth;
> + new_bpp = primary_state->fb->format->depth;
> + if (old_bpp != new_bpp) {
> + crtc_state->mode_changed = true;
> + DRM_DEBUG_ATOMIC(
> + "[CRTC:%d:%s] mode changed, bpp %d->%d\n",
> + crtc->base.id, crtc->name, old_bpp, new_bpp);
> + }
> + }
> + return ret;
> +}
> +
> static const struct drm_mode_config_funcs mxsfb_mode_config_funcs = {
> .fb_create = drm_gem_fb_create,
> - .atomic_check = drm_atomic_helper_check,
> + .atomic_check = mxsfb_atomic_helper_check,
> .atomic_commit = drm_atomic_helper_commit,
> };
>
> --
> 2.7.4
>
> ___
> 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
Re: [PATCH 04/10] drm/mxsfb: Update mxsfb with additional pixel formats
Hi,
On Wed, Jan 09, 2019 at 02:13:43PM +, Robert Chiras wrote:
> Since version 4 of eLCDIF, there are some registers that can do
> transformations on the input data, like re-arranging the pixel
> components. By doing that, we can support more pixel formats.
> This patch adds support for X/ABGR and RGBX/A. Although, the local alpha
> is not supported by eLCDIF, the alpha pixel formats were added to the
> supported pixel formats but it will be ignored. This was necessary since
> there are systems (like Android) that requires such pixel formats.
>
> Signed-off-by: Robert Chiras
> ---
> drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 108
> -
> drivers/gpu/drm/mxsfb/mxsfb_drv.c | 27 +++---
> drivers/gpu/drm/mxsfb/mxsfb_drv.h | 4 +-
> drivers/gpu/drm/mxsfb/mxsfb_regs.h | 100 --
> 4 files changed, 169 insertions(+), 70 deletions(-)
>
> diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> index f0648ce..6aa8804 100644
> --- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> +++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
> @@ -48,15 +48,35 @@ static u32 set_hsync_pulse_width(struct mxsfb_drm_private
> *mxsfb, u32 val)
> mxsfb->devdata->hs_wdth_shift;
> }
>
> +/* Print Four-character-code (FOURCC) */
> +static char *fourcc_to_str(u32 fmt)
> +{
> + /* Use 10 chars so we can simultaneously print two codes */
> + static char code[10], *c = &code[0];
> +
> + if (c == &code[10])
> + c = &code[0];
> +
> + *(c++) = (unsigned char)(fmt & 0xff);
> + *(c++) = (unsigned char)((fmt >> 8) & 0xff);
> + *(c++) = (unsigned char)((fmt >> 16) & 0xff);
> + *(c++) = (unsigned char)((fmt >> 24) & 0xff);
> + *(c++) = '\0';
> +
> + return (c - 5);
> +}
> +
> /* Setup the MXSFB registers for decoding the pixels out of the framebuffer
> */
> -static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb)
> +static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private *mxsfb, bool update)
> {
> struct drm_crtc *crtc = &mxsfb->pipe.crtc;
> struct drm_device *drm = crtc->dev;
> const u32 format = crtc->primary->state->fb->format->format;
> - u32 ctrl, ctrl1;
> + u32 ctrl = 0, ctrl1 = 0;
> + bool bgr_format = true;
>
> - ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
> + if (!update)
> + ctrl = CTRL_BYPASS_COUNT | CTRL_MASTER;
>
> /*
>* WARNING: The bus width, CTRL_SET_BUS_WIDTH(), is configured to
> @@ -65,31 +85,69 @@ static int mxsfb_set_pixel_fmt(struct mxsfb_drm_private
> *mxsfb)
>* to arbitrary value. This limitation should not pose an issue.
>*/
>
> - /* CTRL1 contains IRQ config and status bits, preserve those. */
> - ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> - ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + if (!update) {
> + /* CTRL1 contains IRQ config and status bits, preserve those. */
> + ctrl1 = readl(mxsfb->base + LCDC_CTRL1);
> + ctrl1 &= CTRL1_CUR_FRAME_DONE_IRQ_EN | CTRL1_CUR_FRAME_DONE_IRQ;
> + }
> +
> + DRM_DEV_DEBUG_DRIVER(drm->dev, "Setting up %s mode\n",
> + fourcc_to_str(format));
> +
> + /* Do some clean-up that we might have from a previous mode */
> + ctrl &= ~CTRL_SHIFT_DIR(1);
> + ctrl &= ~CTRL_SHIFT_NUM(0x3f);
> + if (mxsfb->devdata->ipversion >= 4)
> + writel(CTRL2_ODD_LINE_PATTERN(0x7) |
> +CTRL2_EVEN_LINE_PATTERN(0x7),
> +mxsfb->base + LCDC_V4_CTRL2 + REG_CLR);
>
> switch (format) {
> case DRM_FORMAT_RGB565:
> - dev_dbg(drm->dev, "Setting up RGB565 mode\n");
> ctrl |= CTRL_SET_WORD_LENGTH(0);
> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0xf);
> break;
> + case DRM_FORMAT_RGBX:
> + case DRM_FORMAT_RGBA:
> + /* RGBX - > 0RGB */
> + ctrl |= CTRL_SHIFT_DIR(1);
> + ctrl |= CTRL_SHIFT_NUM(8);
> + bgr_format = false;
> + /* Fall through */
> + case DRM_FORMAT_XBGR:
> + case DRM_FORMAT_ABGR:
> + if (bgr_format) {
> + if (mxsfb->devdata->ipversion < 4)
> + goto err;
> + writel(CTRL2_ODD_LINE_PATTERN(0x5) |
> +CTRL2_EVEN_LINE_PATTERN(0x5),
> +mxsfb->base + LCDC_V4_CTRL2 + REG_SET);
> + }
> + /* Fall through */
> case DRM_FORMAT_XRGB:
> - dev_dbg(drm->dev, "Setting up XRGB mode\n");
> + case DRM_FORMAT_ARGB:
> ctrl |= CTRL_SET_WORD_LENGTH(3);
> /* Do not use packed pixels = one pixel per word instead. */
> ctrl1 |= CTRL1_SET_BYTE_PACKAGING(0x7);
> break;
> default:
> - dev_err(drm->dev, "Unhandled pixel format %0
[Bug 108592] [CI][DRMTIP] igt@gem_exec_whisper@normal - timeout
https://bugs.freedesktop.org/show_bug.cgi?id=108592 Martin Peres changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #3 from Martin Peres --- (In reply to Chris Wilson from comment #2) > commit d9cd03c887a5f46bc002280d70a6716bb2bf8d43 (upstream/master, > origin/master, origin/HEAD) > Author: Chris Wilson > Date: Mon Jan 14 09:13:54 2019 + > > i915/gem_exec_whisper: Limit to a maximum of 150s > > Each individual pass is as effective at spotting an error using the > Chinese whisper as any other, so the effectiveness of adding more passes > rapidly diminishes. To keep the tests bounded within time, limit a > subtest to a mere 150s! > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108592 > Signed-off-by: Chris Wilson > Reviewed-by: Tvrtko Ursulin Thanks, it did the trick! -- 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
[PATCH 1/3 v2] drm: rcar-du: add missing of_node_put
Add an of_node_put when the result of of_graph_get_remote_port_parent is not available. Add a second of_node_put if no encoder is selected (encoder remains NULL). The semantic match that finds the first problem is as follows (http://coccinelle.lip6.fr): // @r exists@ local idexpression e; expression x; @@ e = of_graph_get_remote_port_parent(...); ... when != x = e when != true e == NULL when != of_node_put(e) when != of_fwnode_handle(e) ( return e; | *return ...; ) // Signed-off-by: Julia Lawall --- v2: Add the second of_node_put(entity);, as suggested by Kieran Bingham. drivers/gpu/drm/rcar-du/rcar_du_kms.c |2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 9c7007d..f9a90ff 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu, dev_dbg(rcdu->dev, "connected entity %pOF is disabled, skipping\n", entity); + of_node_put(entity); return -ENODEV; } @@ -366,6 +367,7 @@ static int rcar_du_encoders_init_one(struct rcar_du_device *rcdu, dev_warn(rcdu->dev, "no encoder found for endpoint %pOF, skipping\n", ep->local_node); + of_node_put(entity); return -ENODEV; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #4 from Tom Seewald --- Created attachment 143107 --> https://bugs.freedesktop.org/attachment.cgi?id=143107&action=edit amd-drm-staging-next dmesg as of January 14th 2019 -- 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 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #5 from Tom Seewald --- Created attachment 143108 --> https://bugs.freedesktop.org/attachment.cgi?id=143108&action=edit UMR wave dump as of January 14th 2019 -- 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 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #6 from Tom Seewald --- Created attachment 143109 --> https://bugs.freedesktop.org/attachment.cgi?id=143109&action=edit UMR gfx ring dump as of January 14th 2019 -- 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 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #7 from Tom Seewald --- Created attachment 143110 --> https://bugs.freedesktop.org/attachment.cgi?id=143110&action=edit UMR gpu info -- 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
[PATCH] drm/fourcc: Add modifier defininitions for AFBC 1.3
From: Matteo Franchin
This commit adds definitions of format modifiers for version 1.3 of the
Arm Framebuffer Compression (AFBC).
Signed-off-by: Matteo Franchin
---
include/uapi/drm/drm_fourcc.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 8dd1328..d6a20d4 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -602,10 +602,18 @@ extern "C" {
* Indicates the superblock size(s) used for the AFBC buffer. The buffer
* size (in pixels) must be aligned to a multiple of the superblock size.
* Four lowest significant bits(LSBs) are reserved for block size.
+ *
+ * Where one superblock size is specified, it applies to all planes of the
+ * buffer (e.g. 16x16, 32x8). When multiple superblock sizes are specified,
+ * the first applies to the Luma plane and the second applies to the Chroma
+ * plane(s). e.g. (32x8_64x4 means 32x8 Luma, with 64x4 Chroma).
+ * Multiple superblock sizes are only valid for multi-plane YCbCr formats.
*/
#define AFBC_FORMAT_MOD_BLOCK_SIZE_MASK 0xf
#define AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 (1ULL)
#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8 (2ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_64x4 (3ULL)
+#define AFBC_FORMAT_MOD_BLOCK_SIZE_32x8_64x4 (4ULL)
/*
* AFBC lossless colorspace transform
@@ -665,6 +673,21 @@ extern "C" {
*/
#define AFBC_FORMAT_MOD_SC (1ULL << 9)
+/*
+ * AFBC double-buffer
+ *
+ * Indicates that the buffer is allocated in a layout safe for front-buffer
+ * rendering.
+ */
+#define AFBC_FORMAT_MOD_DB (1ULL << 10)
+
+/*
+ * AFBC buffer content hints
+ *
+ * Indicates that the buffer includes per-superblock content hints.
+ */
+#define AFBC_FORMAT_MOD_BCH (1ULL << 11)
+
#if defined(__cplusplus)
}
#endif
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #8 from Tom Seewald --- I've reproduced this issue on amd-staging-drm-next and have attached a UMR wave and gfx ring dump, along with a new dmesg. To clarify, this issue also prevents me from rebooting/shutting down my computer, and I am forced to hold the power button. Here are the version strings of the relevant software I'm running: Kernel: amd-staging-drm-next (commit: d2d07f246b126b23d02af0603b83866a3c3e2483) Mesa: 18.3.1 Xorg: 1.19.6 UMR: 016bc2e93af2cac7a9bd790f7fcacb1ffdadc819 This is my first attempt at using UMR to get information about this system hang. I'm essentially just copying what Andrey Grodzovsky suggested in a previous thread[0]. Here are the umr commands used to gather the information: Waves dump: umr -i 1 -O verbose,halt_waves -wa GFX ring dump: umr -i 1 -O verbose,follow -R gfx[.] GFX info: umr -i 1 -e I've attached the output of these to the bugzilla report. [0] https://lists.freedesktop.org/archives/amd-gfx/2018-December/029790.html -- 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 202261] general protection fault: 0000 [#1] PREEMPT SMP Workqueue: events ttm_bo_delayed_workqueue
https://bugzilla.kernel.org/show_bug.cgi?id=202261 Michel Dänzer (mic...@daenzer.net) changed: What|Removed |Added CC||h...@lst.de --- Comment #3 from Michel Dänzer (mic...@daenzer.net) --- Looks like https://bugs.freedesktop.org/109234 => https://lists.freedesktop.org/archives/dri-devel/2019-January/202909.html and follow-ups. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code
On 2019-01-10 3:48 p.m., Christoph Hellwig wrote: > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote: >>> From the trace it looks like we git the case where swiotlb tries >>> to copy back data from a bounce buffer, but hits a dangling or NULL >>> pointer. So a couple questions for the submitter: >>> >>> - does the system have more than 4GB memory and thus use swiotlb? >>> (check /proc/meminfo, and if something SWIOTLB appears in dmesg) >>> - does the device this happens on have a DMA mask smaller than >>> the available memory, that is should swiotlb be used here to start >>> with? >> >> Rather unlikely. The device is an AMD GPU, so we can address memory up to >> 1TB. > > So we probably somehow got a false positive. > > For now I'like the reported to confirm that the dma_direct_unmap_page+0x92 > backtrace really is in the swiotlb code (I can't think of anything else, > but I'd rather be sure). > > Second it would be great to print what the contents of io_tlb_start > and io_tlb_end are, e.g. by doing a printk_once in is_swiotlb_buffer, > maybe that gives a clue why we are hitting the swiotlb code here. Any progress? https://bugzilla.kernel.org/show_bug.cgi?id=202261 was also filed about this. I hope everyone's clear that this needs to be resolved one way or another by 5.0 final (though the sooner, the better :). -- Earthling Michel Dänzer | http://www.amd.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
[Bug 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #9 from Tom Seewald --- I temporarily upgraded to Xorg 1.20, and the issue still occurs. -- 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 108854] [polaris11] - Failed GPU reset after hang
https://bugs.freedesktop.org/show_bug.cgi?id=108854 --- Comment #10 from Tom Seewald --- Created attachment 143113 --> https://bugs.freedesktop.org/attachment.cgi?id=143113&action=edit dmesg with xorg 1.20, kernel 5.0-rc2 -- 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 109135] R9 390 hangs at boot with DPM/DC enabled for kernels 4.19.x and above, says KMS not supported
https://bugs.freedesktop.org/show_bug.cgi?id=109135 --- Comment #17 from rmuncr...@humanavance.com --- Yes, As I said in the beginning if you don't set amdgpu.dpm=1 the system boots but resume doesn't work. I presume it's because power management isn't working. All kernels before 4.19.x work great, and have no problem with resume so long as dpm is enabled. -- 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
[PATCH v1 1/1] drm: fix alpha build after drm_util.h change
0-DAY reported the following bug:
tree: git://anongit.freedesktop.org/drm/drm-misc drm-misc-next
head: 21376e2c3c5bad5e87ba700c055c8a8235c2bfd5
commit: e9eafcb589213395232084a2378e2e90f67feb29 [1/2] drm: move
drm_can_sleep() to drm_util.h
config: alpha-allmodconfig (attached as .config)
...
In file included from include/linux/irqflags.h:16:0,
from include/drm/drm_util.h:35,
from drivers/gpu/drm/qxl/qxl_cmd.c:28:
>> arch/alpha/include/asm/irqflags.h:58:15: error: unknown type name 'bool'
static inline bool arch_irqs_disabled_flags(unsigned long flags)
^~~~
...
So we have a situation where we do not pull in
when building for alpha.
An quick grep shows that roughly half of the declarations of
arch_irqs_disabled_flags() uses int as return type, the other half bool.
Two invasive fixes where considered:
- Change all declarations of arch_irqs_disabled_flags() to use bool
- Add include of to all files that uses bool for
arch_irqs_disabled_flags
To invases with a too high pain/benefit ratio, so dropped.
Some less invasive fixes was also considered:
- Add include of to irqflags.h
- Add include of to qxl_cmd.c
- Add include of to drm_util.h
The first was dropped as irqflags.h did not use bool, so no need for the
types.h header file.
The latter was considered the best option as there could
be other similar cases and we would like the header files below
include/drm/ to be selfcontained.
It turns out that using the standard alphabetical order did not work
well as we then included irqflags.h before types.h.
It was considered just to pull in interrupt.h but that would
pull in a lot of unused stuff.
So in the end types.h was included with a comment that it must be first.
Build tested with alpha allmodconfig.
Fixes: 733748ac37b45 ("drm: move drm_can_sleep() to drm_util.h")
Signed-off-by: Sam Ravnborg
Cc: Maarten Lankhorst
Cc: Maxime Ripard
Cc: Sean Paul
Cc: David Airlie
Cc: Daniel Vetter
---
include/drm/drm_util.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/drm/drm_util.h b/include/drm/drm_util.h
index 0500da65b1d1..0f550bc91db1 100644
--- a/include/drm/drm_util.h
+++ b/include/drm/drm_util.h
@@ -32,6 +32,8 @@
* Macros and inline functions that does not naturally belong in other places
*/
+#include /* Due to header dependencies this must be first */
+
#include
#include
#include
--
2.12.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code
On Thu, Jan 10, 2019 at 06:52:26PM +0100, Sibren Vasse wrote:
> On Thu, 10 Jan 2019 at 15:48, Christoph Hellwig wrote:
> >
> > On Thu, Jan 10, 2019 at 03:00:31PM +0100, Christian König wrote:
> > >> From the trace it looks like we git the case where swiotlb tries
> > >> to copy back data from a bounce buffer, but hits a dangling or NULL
> > >> pointer. So a couple questions for the submitter:
> > >>
> > >> - does the system have more than 4GB memory and thus use swiotlb?
> > >> (check /proc/meminfo, and if something SWIOTLB appears in dmesg)
> > >> - does the device this happens on have a DMA mask smaller than
> > >> the available memory, that is should swiotlb be used here to start
> > >> with?
> > >
> > > Rather unlikely. The device is an AMD GPU, so we can address memory up to
> > > 1TB.
> >
> > So we probably somehow got a false positive.
> >
> > For now I'like the reported to confirm that the dma_direct_unmap_page+0x92
> > backtrace really is in the swiotlb code (I can't think of anything else,
> > but I'd rather be sure).
> I'm not sure what you want me to confirm. Could you elaborate?
Please open the vmlinux file for which this happend in gdb,
then send the output from this command
l *(dma_direct_unmap_page+0x92)
to this thread.
> > Second it would be great to print what the contents of io_tlb_start
> > and io_tlb_end are, e.g. by doing a printk_once in is_swiotlb_buffer,
> > maybe that gives a clue why we are hitting the swiotlb code here.
>
> diff --git a/include/linux/swiotlb.h b/include/linux/swiotlb.h
> index 7c007ed7505f..042246dbae00 100644
> --- a/include/linux/swiotlb.h
> +++ b/include/linux/swiotlb.h
> @@ -69,6 +69,7 @@ extern phys_addr_t io_tlb_start, io_tlb_end;
>
> static inline bool is_swiotlb_buffer(phys_addr_t paddr)
> {
> +printk_once(KERN_INFO "io_tlb_start: %llu, io_tlb_end: %llu",
> io_tlb_start, io_tlb_end);
> return paddr >= io_tlb_start && paddr < io_tlb_end;
> }
>
> Result on boot:
> [ 11.405558] io_tlb_start: 3782983680, io_tlb_end: 3850092544
So this is a normal swiotlb location, and it does defintively exist.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3 v2] drm: rcar-du: add missing of_node_put
Hi Julia, Thank you for the patch. On Monday, 14 January 2019 18:44:56 EET Julia Lawall wrote: > Add an of_node_put when the result of of_graph_get_remote_port_parent is > not available. > > Add a second of_node_put if no encoder is selected (encoder remains NULL). > > The semantic match that finds the first problem is as follows > (http://coccinelle.lip6.fr): > > // > @r exists@ > local idexpression e; > expression x; > @@ > e = of_graph_get_remote_port_parent(...); > ... when != x = e > when != true e == NULL > when != of_node_put(e) > when != of_fwnode_handle(e) > ( > return e; > > *return ...; > ) > // > > Signed-off-by: Julia Lawall Reviewed-by: Laurent Pinchart and applied to my tree. > --- > v2: Add the second of_node_put(entity);, as suggested by Kieran Bingham. > > drivers/gpu/drm/rcar-du/rcar_du_kms.c |2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 9c7007d..f9a90ff 100644 > --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c > +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c > @@ -331,6 +331,7 @@ static int rcar_du_encoders_init_one(struct > rcar_du_device *rcdu, dev_dbg(rcdu->dev, > "connected entity %pOF is disabled, skipping\n", > entity); > + of_node_put(entity); > return -ENODEV; > } > > @@ -366,6 +367,7 @@ static int rcar_du_encoders_init_one(struct > rcar_du_device *rcdu, dev_warn(rcdu->dev, >"no encoder found for endpoint %pOF, skipping\n", >ep->local_node); > + of_node_put(entity); > return -ENODEV; > } -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: amdgpu/TTM oopses since merging swiotlb_dma_ops into the dma_direct code
Hmm, I wonder if we are not actually using swiotlb in the end, can you check if your dmesg contains this line or not? PCI-DMA: Using software bounce buffering for IO (SWIOTLB) If not I guess we found a bug in swiotlb exit vs is_swiotlb_buffer, and you can try this patch: diff --git a/kernel/dma/swiotlb.c b/kernel/dma/swiotlb.c index d6361776dc5c..1fb6fd68b9c7 100644 --- a/kernel/dma/swiotlb.c +++ b/kernel/dma/swiotlb.c @@ -378,6 +378,8 @@ void __init swiotlb_exit(void) memblock_free_late(io_tlb_start, PAGE_ALIGN(io_tlb_nslabs << IO_TLB_SHIFT)); } + io_tlb_start = 0; + io_tlb_end = 0; io_tlb_nslabs = 0; max_segment = 0; } ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
