Re: [PATCH 01/19] drm: debugfs: Remove all files automatically on cleanup
On Thu, Jan 26, 2017 at 11:56:03PM +0100, Noralf Trønnes wrote:
> Instead of having the drivers call drm_debugfs_remove_files() in
> their drm_driver->debugfs_cleanup hook, do it automatically by
> traversing minor->debugfs_list.
> Also use debugfs_remove_recursive() so drivers who add their own
> debugfs files don't have to keep track of them for removal.
>
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/drm_debugfs.c | 20 +---
> 1 file changed, 17 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 37fd612..04b0af3 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -81,7 +81,8 @@ static const struct file_operations drm_debugfs_fops = {
> * \return Zero on success, non-zero on failure
> *
> * Create a given set of debugfs files represented by an array of
> - * gdm_debugfs_lists in the given root directory.
> + * &drm_info_list in the given root directory. These files will be removed
> + * automatically on drm_debugfs_cleanup().
I'm starting to feel guilty about asking you all this, but you're doing
great work so here we go: I just noticed that the comments here aren't
really kernel-doc, and that the drm_debugfs.[hc] stuff ins't pulled into
the sphinx documentation (which is why it's not checked). Would be really
awesome if you could add a chapter to gpu/drm-uapi.rst about debugfs
interfaces (with a big warning that it's not stable api and for debugging
only), and pull the kerneldoc for it (plus fix it to be properly parsing
kerenldoc)? Strictly optional :-)
-Daniel
> */
> int drm_debugfs_create_files(const struct drm_info_list *files, int count,
>struct dentry *root, struct drm_minor *minor)
> @@ -218,6 +219,19 @@ int drm_debugfs_remove_files(const struct drm_info_list
> *files, int count,
> }
> EXPORT_SYMBOL(drm_debugfs_remove_files);
>
> +static void drm_debugfs_remove_all_files(struct drm_minor *minor)
> +{
> + struct drm_info_node *node, *tmp;
> +
> + mutex_lock(&minor->debugfs_lock);
> + list_for_each_entry_safe(node, tmp, &minor->debugfs_list, list) {
> + debugfs_remove(node->dent);
> + list_del(&node->list);
> + kfree(node);
> + }
> + mutex_unlock(&minor->debugfs_lock);
> +}
> +
> /**
> * Cleanup the debugfs filesystem resources.
> *
> @@ -245,9 +259,9 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> }
> }
>
> - drm_debugfs_remove_files(drm_debugfs_list, DRM_DEBUGFS_ENTRIES, minor);
> + drm_debugfs_remove_all_files(minor);
>
> - debugfs_remove(minor->debugfs_root);
> + debugfs_remove_recursive(minor->debugfs_root);
> minor->debugfs_root = NULL;
>
> return 0;
> --
> 2.10.2
>
> ___
> 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 11/19] drm/omap: Remove omap_debugfs_cleanup()
On 27/01/17 00:56, Noralf Trønnes wrote: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so the drm_driver.debugfs_cleanup callback is not > needed. > > Cc: tomi.valkei...@ti.com > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/omapdrm/omap_debugfs.c | 9 - > drivers/gpu/drm/omapdrm/omap_drv.c | 1 - > drivers/gpu/drm/omapdrm/omap_drv.h | 1 - > 3 files changed, 11 deletions(-) Reviewed-by: Tomi Valkeinen Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 12/19] drm/radeon: Remove drm_debugfs_remove_files() call
Am 26.01.2017 um 23:56 schrieb Noralf Trønnes:
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so it's not necessary to call drm_debugfs_remove_files().
Cc: alexander.deuc...@amd.com
Cc: christian.koe...@amd.com
Signed-off-by: Noralf Trønnes
Great work! I wanted to do this for quite a while as well, but never
found time to look into it.
A good first step, but when we don't have radeon_debugfs_remove_files()
any more we don't need rdev->debugfs and all the related housekeeping
either.
Additional to that we have a couple of entries added/removed to the
minor manually, just grep for "debugfs_remove" in the radeon code. Those
calls can now be removed as well.
But all that can be done in separate patches, this one is Reviewed-by:
Christian König .
Regards,
Christian.
---
drivers/gpu/drm/radeon/radeon_device.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_device.c
b/drivers/gpu/drm/radeon/radeon_device.c
index 8a1df2a..4b0c388 100644
--- a/drivers/gpu/drm/radeon/radeon_device.c
+++ b/drivers/gpu/drm/radeon/radeon_device.c
@@ -1549,8 +1549,6 @@ int radeon_device_init(struct radeon_device *rdev,
return r;
}
-static void radeon_debugfs_remove_files(struct radeon_device *rdev);
-
/**
* radeon_device_fini - tear down the driver
*
@@ -1577,7 +1575,6 @@ void radeon_device_fini(struct radeon_device *rdev)
rdev->rmmio = NULL;
if (rdev->family >= CHIP_BONAIRE)
radeon_doorbell_fini(rdev);
- radeon_debugfs_remove_files(rdev);
}
@@ -1954,16 +1951,3 @@ int radeon_debugfs_add_files(struct radeon_device *rdev,
#endif
return 0;
}
-
-static void radeon_debugfs_remove_files(struct radeon_device *rdev)
-{
-#if defined(CONFIG_DEBUG_FS)
- unsigned i;
-
- for (i = 0; i < rdev->debugfs_count; i++) {
- drm_debugfs_remove_files(rdev->debugfs[i].files,
-rdev->debugfs[i].num_files,
-rdev->ddev->primary);
- }
-#endif
-}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 04/19] drm/amd/amdgpu: Remove drm_debugfs_remove_files() call
Am 26.01.2017 um 23:56 schrieb Noralf Trønnes:
drm_debugfs_cleanup() now removes all minor->debugfs_list entries
automatically, so no need to call drm_debugfs_remove_files().
Also remove empty drm_driver.debugfs_cleanup callback.
Cc: alexander.deuc...@amd.com
Cc: christian.koe...@amd.com
Signed-off-by: Noralf Trønnes
Everything said for Radeon applies here as well.
Just let me know if you want to do the additional cleanup patches or if
we should be taking care of that.
This patch is Reviewed-by: Christian König
for now.
Regards,
Christian.
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 -
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 -
3 files changed, 22 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index f4f371f..73863d4 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1133,7 +1133,6 @@ int amdgpu_debugfs_fence_init(struct amdgpu_device *adev);
#if defined(CONFIG_DEBUG_FS)
int amdgpu_debugfs_init(struct drm_minor *minor);
-void amdgpu_debugfs_cleanup(struct drm_minor *minor);
#endif
int amdgpu_debugfs_firmware_init(struct amdgpu_device *adev);
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
index fe3bb94..2201303 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
@@ -1852,8 +1852,6 @@ int amdgpu_device_init(struct amdgpu_device *adev,
return r;
}
-static void amdgpu_debugfs_remove_files(struct amdgpu_device *adev);
-
/**
* amdgpu_device_fini - tear down the driver
*
@@ -1893,7 +1891,6 @@ void amdgpu_device_fini(struct amdgpu_device *adev)
if (adev->asic_type >= CHIP_BONAIRE)
amdgpu_doorbell_fini(adev);
amdgpu_debugfs_regs_cleanup(adev);
- amdgpu_debugfs_remove_files(adev);
}
@@ -2507,19 +2504,6 @@ int amdgpu_debugfs_add_files(struct amdgpu_device *adev,
return 0;
}
-static void amdgpu_debugfs_remove_files(struct amdgpu_device *adev)
-{
-#if defined(CONFIG_DEBUG_FS)
- unsigned i;
-
- for (i = 0; i < adev->debugfs_count; i++) {
- drm_debugfs_remove_files(adev->debugfs[i].files,
-adev->debugfs[i].num_files,
-adev->ddev->primary);
- }
-#endif
-}
-
#if defined(CONFIG_DEBUG_FS)
static ssize_t amdgpu_debugfs_regs_read(struct file *f, char __user *buf,
@@ -3153,10 +3137,6 @@ int amdgpu_debugfs_init(struct drm_minor *minor)
{
return 0;
}
-
-void amdgpu_debugfs_cleanup(struct drm_minor *minor)
-{
-}
#else
static int amdgpu_debugfs_regs_init(struct amdgpu_device *adev)
{
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 2534ada..51cfea7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -701,7 +701,6 @@ static struct drm_driver kms_driver = {
.get_scanout_position = amdgpu_get_crtc_scanoutpos,
#if defined(CONFIG_DEBUG_FS)
.debugfs_init = amdgpu_debugfs_init,
- .debugfs_cleanup = amdgpu_debugfs_cleanup,
#endif
.irq_preinstall = amdgpu_irq_preinstall,
.irq_postinstall = amdgpu_irq_postinstall,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] virtio-gpu: disable VIRGL with BE kernel
On Di, 2017-01-24 at 14:12 +0100, Laurent Vivier wrote: > VIRTIO_GPU_F_VIRGL is added in features list only > for LE kernel, so we must check for it only on LE kernel, > otherwise virtio_has_feature() calls BUG() and > crashes the kernel. > > Suggested-by: Gerd Hoffmann > Signed-off-by: Laurent Vivier Added to drm-qemu branch. thanks, Gerd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: qxl: Drop misleading comment
On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote:
> No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
> output"). qxl_num_crtc defaults to 4 and is configurable as a module
> parameter.
Picked up patches 1-3 for drm-qemu branch.
Patch 4 doesn't apply and seems to have a dependency on out-of-tree
changes, git am fails to do a 3way merge due to missing commits (trying
to apply to 4.10-rc5).
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99555] LIBGL_ALWAYS_INDIRECT=1 causes all opengl programms to crash on second frame
https://bugs.freedesktop.org/show_bug.cgi?id=99555 Michel Dänzer changed: What|Removed |Added Product|Mesa|xorg QA Contact|dri-devel@lists.freedesktop |xorg-t...@lists.x.org |.org| Assignee|dri-devel@lists.freedesktop |xorg-t...@lists.x.org |.org| Component|Drivers/Gallium/r600|Server/Ext/GLX --- Comment #1 from Michel Dänzer --- This code in __glXForceCurrent: if (cx->wait && (*cx->wait) (cx, cl, error)) return NULL; calls DRI2WaitSwap, which returns TRUE because there is a pending swap. I suspect something to deal with this went missing at a higher level at some point. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable
Am 27.01.2017 um 08:30 schrieb Daniel Vetter: On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: On 01/27/2017 03:29 AM, Michel Dänzer wrote: On 26/01/17 09:46 AM, Sinclair Yeh wrote: On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: On 01/25/2017 09:21 AM, Michel Dänzer wrote: From: Michel Dänzer The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Thomas Hellstrom Reviewed-by: Christian König . Reviewed-by: Sinclair Yeh Thanks for the reviews! Via which tree should we merge this? I don't maintain a TTM tree any longer. Let's check with Daniel if he can merge it through drm-misc. I'm trying very hard not to get volunteered for ttm maintainer :-) Yeah, ok I volunteer. Wanted to take that over for a while anyway. Nominally Alex&Christian have drm-misc commit rights, but they haven't used them yet. But I think merging through drm-misc would make sense, there's regular pull request trains for both -next and -fixes. Completely agree on merging it through drm-misc. Going to give my push rights a try today. Or merge through the amd tree with Dave's ack, but I'd really like to get amd folks into the drm-misc group ... I've got a few more already reviewed TTM changes which are currently waiting to be pushed upstream where amdgpu has dependencies on. Going to sync with Alex so he sends his pull requests with those changes to Dave after the merge of the depending changes. If you want to object that just merging through the AMD tree would be simpler, I agree but I actually want to do this exercise at least once :) Regards, Christian. -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 03/19] drm/atomic: Remove drm_atomic_debugfs_cleanup()
On Thu, Jan 26, 2017 at 11:56:05PM +0100, Noralf Trønnes wrote:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so no need to call drm_debugfs_remove_files().
>
> Signed-off-by: Noralf Trønnes
Merged up to this one to drm-misc, I'll wait with the others for acks to
trickle in.
Thanks a lot, Daniel
> ---
> drivers/gpu/drm/drm_atomic.c| 7 ---
> drivers/gpu/drm/drm_crtc_internal.h | 1 -
> drivers/gpu/drm/drm_debugfs.c | 9 -
> 3 files changed, 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 723392f..861e130 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -1731,13 +1731,6 @@ int drm_atomic_debugfs_init(struct drm_minor *minor)
> ARRAY_SIZE(drm_atomic_debugfs_list),
> minor->debugfs_root, minor);
> }
> -
> -int drm_atomic_debugfs_cleanup(struct drm_minor *minor)
> -{
> - return drm_debugfs_remove_files(drm_atomic_debugfs_list,
> - ARRAY_SIZE(drm_atomic_debugfs_list),
> - minor);
> -}
> #endif
>
> /*
> diff --git a/drivers/gpu/drm/drm_crtc_internal.h
> b/drivers/gpu/drm/drm_crtc_internal.h
> index 724c329..1bdcfd5 100644
> --- a/drivers/gpu/drm/drm_crtc_internal.h
> +++ b/drivers/gpu/drm/drm_crtc_internal.h
> @@ -177,7 +177,6 @@ int drm_mode_dirtyfb_ioctl(struct drm_device *dev,
> #ifdef CONFIG_DEBUG_FS
> struct drm_minor;
> int drm_atomic_debugfs_init(struct drm_minor *minor);
> -int drm_atomic_debugfs_cleanup(struct drm_minor *minor);
> #endif
>
> int drm_atomic_get_property(struct drm_mode_object *obj,
> diff --git a/drivers/gpu/drm/drm_debugfs.c b/drivers/gpu/drm/drm_debugfs.c
> index 04b0af3..2290a74 100644
> --- a/drivers/gpu/drm/drm_debugfs.c
> +++ b/drivers/gpu/drm/drm_debugfs.c
> @@ -243,7 +243,6 @@ static void drm_debugfs_remove_all_files(struct drm_minor
> *minor)
> int drm_debugfs_cleanup(struct drm_minor *minor)
> {
> struct drm_device *dev = minor->dev;
> - int ret;
>
> if (!minor->debugfs_root)
> return 0;
> @@ -251,14 +250,6 @@ int drm_debugfs_cleanup(struct drm_minor *minor)
> if (dev->driver->debugfs_cleanup)
> dev->driver->debugfs_cleanup(minor);
>
> - if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
> - ret = drm_atomic_debugfs_cleanup(minor);
> - if (ret) {
> - DRM_ERROR("DRM: Failed to remove atomic debugfs
> entries\n");
> - return ret;
> - }
> - }
> -
> drm_debugfs_remove_all_files(minor);
>
> debugfs_remove_recursive(minor->debugfs_root);
> --
> 2.10.2
>
> ___
> 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
[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics
https://bugzilla.kernel.org/show_bug.cgi?id=193341 --- Comment #1 from Michel Dänzer --- Same as https://bugzilla.kernel.org/show_bug.cgi?id=193341 . -- 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 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics
https://bugzilla.kernel.org/show_bug.cgi?id=193341 --- Comment #2 from Michel Dänzer --- Sorry, I mean https://bugs.freedesktop.org/show_bug.cgi?id=99387 . -- 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/fourcc: add vivante tiled layout format modifiers
Am Donnerstag, den 26.01.2017, 18:24 +0100 schrieb Daniel Vetter:
> On Thu, Jan 26, 2017 at 04:32:17PM +0100, Philipp Zabel wrote:
> > Vivante GC hardware uses simple 4x4 tiled and nested 64x64 supertiled
> > formats as well as so-called split-tiled variants for dual-pipe
> > hardware, where even and odd tiles start at different base addresses.
> >
> > Signed-off-by: Philipp Zabel
> > ---
> > include/uapi/drm/drm_fourcc.h | 41
> > +
> > 1 file changed, 41 insertions(+)
> >
> > diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
> > index a5890bf44c0af..ec0498cf61756 100644
> > --- a/include/uapi/drm/drm_fourcc.h
> > +++ b/include/uapi/drm/drm_fourcc.h
> > @@ -159,6 +159,7 @@ extern "C" {
> > #define DRM_FORMAT_MOD_VENDOR_NV 0x03
> > #define DRM_FORMAT_MOD_VENDOR_SAMSUNG 0x04
> > #define DRM_FORMAT_MOD_VENDOR_QCOM0x05
> > +#define DRM_FORMAT_MOD_VENDOR_VIVANTE 0x06
> > /* add more to the end as needed */
> >
> > #define fourcc_mod_code(vendor, val) \
> > @@ -233,6 +234,46 @@ extern "C" {
> > */
> > #define DRM_FORMAT_MOD_SAMSUNG_64_32_TILE fourcc_mod_code(SAMSUNG, 1)
> >
> > +/* Vivante framebuffer modifiers */
> > +
> > +/*
> > + * Vivante 4x4 tiling layout
> > + *
> > + * This is a simple tiled layout using tiles of 4x4 pixels in a row-major
> > + * layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_TILED
> > fourcc_mod_code(VIVANTE, 1)
> > +
> > +/*
> > + * Vivante 64x64 super-tiling layout
> > + *
> > + * This is a tiled layout using 64x64 pixel super-tiles, where each
> > super-tile
> > + * contains 8x4 groups of 2x4 tiles of 4x4 pixels (like above) each, all
> > in row-
> > + * major layout.
> > + *
> > + * For more information: see
> > + *
> > https://github.com/etnaviv/etna_viv/blob/master/doc/hardware.md#texture-tiling
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SUPER_TILED fourcc_mod_code(VIVANTE, 2)
> > +
> > +/*
> > + * Vivante 4x4 tiling layout for dual-pipe
> > + *
> > + * Same as the 4x4 tiling layout, except every second 4x4 pixel tile
> > starts at a
> > + * different base address. Offsets from the base addresses are therefore
> > halved
> > + * compared to the non-split tiled layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SPLIT_TILED fourcc_mod_code(VIVANTE, 3)
> > +
> > +/*
> > + * Vivante 64x64 super-tiling layout for dual-pipe
> > + *
> > + * Same as the 64x64 super-tiling layout, except every second 4x4 pixel
> > tile
> > + * starts at a different base address. Offsets from the base addresses are
> > + * therefore halved compared to the non-split super-tiled layout.
> > + */
> > +#define DRM_FORMAT_MOD_VIVANTE_SPLIT_SUPER_TILED fourcc_mod_code(VIVANTE,
> > 4)
>
> Does this mean the dual-pipe stuff has 2 planes? Do you need Ville's
> driver-private format stuff for this?
Nope, it's a single plane, but the pipes using different offsets within
the plane.
As the pipe address registers are freely configurable we could push the
render output into 2 planes, but why make our life hard for no
reason? :)
Regards,
Lucas
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > When writing some testcases for nonblocking modesets. I found out that the > infinite wait on the old fb was causing issues. The crux of the issue here is the locked wait for old dependencies and the inability to inject the intel_prepare_reset disabling of all planes. There are a couple of locked waits on struct_mutex within the modeset locks for intel_overlay and if we happen to be using the display plane for the first time. The first I suggested solving using fences to track dependencies and keep the order between atomic states. Cancelling the outstanding modesets, replacing with a disable and then on restore jumping to the final state look doable. It also requires avoiding the struct_mutex for disabling, which is quite easy. To avoid the wait under struct_mutex, we've talked about switching to mmio, but for starters we could move the wait from inside intel_overlay into the fence for the atomic operation. (But's that a little more surgery than we would like for intel_overlay I guess - dig out Ville's patches for overlay planes?) And to prevent the wait under struct_mutex for pin_to_display_plane, my plane is to move that to an async fenced operation that is then naturally waited upon by the atomic modeset. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup
On Fri, Jan 27, 2017 at 08:49:34AM +0100, Daniel Vetter wrote: > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > > This patchset removes the need for drivers to clean up their debugfs > > files on exit. It is done automatically in drm_debugfs_cleanup(). > > This funtion is also called should the driver error out in it's > > drm_driver.debugfs_init callback. > > > > Two drivers still use drm_debugfs_remove_files(): > > - tegra in it's connectors, not sure if I can remove it. > > I read through them, and they're removed on the component device nodes > stuff. That looks somewhat fishy from a lifetime point of view, and I > think removing all that code would be better, too. What makes you think that's problematic from a lifetime point of view? The component device is tied to the DRM device, so these callbacks are called at the right time. That said, I think it's safe to remove the other debugfs files from Tegra. It might not be possible to remove the cleanup functions altogether, though, because they have to do a special dance involving kmemdup() drm_debugfs_create_files() and kfree() in order to support debugfs files for multiple instances of subdevices. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 14/19] drm/tegra: Remove tegra_debugfs_cleanup()
On Thu, Jan 26, 2017 at 11:56:16PM +0100, Noralf Trønnes wrote: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so the drm_driver.debugfs_cleanup callback is not > needed. > > Cc: thierry.red...@gmail.com > Signed-off-by: Noralf Trønnes > --- > drivers/gpu/drm/tegra/drm.c | 7 --- > 1 file changed, 7 deletions(-) Reviewed-by: Thierry Reding signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: drm-misc for small drivers?
On Fri, Jan 27, 2017 at 07:55:22AM +0100, Daniel Vetter wrote: > On Thu, Jan 26, 2017 at 9:48 PM, Liviu Dudau wrote: > >> I'm not certain number of people is a good metric, TBH. There are cases > >> where a lot of people are working on a driver, but the patches are not > >> being > >> merged to the maintainer tree. In these cases, it makes sense to migrate > >> the > >> driver to -misc and have the community merge the patches. > > > > Sorry, I should've been more explicit: I was referring to the number of > > contributors with public commit rights, not all the engineers involved. In > > Mali DP's case we do most of the development in the open, so all the > > engineers > > are free to merge the patches into the current public git tree after > > internal > > review that tries to catch the evident issues. > > Not sure, but this sounds like you do internal review and then just > push to the public tree. That's not good, since it makes cross-driver > collab harder, and it makes it much harder for external people to > contribute to your driver in general. Upstream is about cross > vendor/user/osv/whomever collaboration in the open, if you really do > review internall I strongly urge you to do all patch submission&review > on dri-devel. That's how all the other drivers work (well > amd/i915/nouveau have their own separate mailing lists because we'd > drown dri-devel), and it's the expectation. It would definitely be the > expectation if arm display is managed in drm-misc :-) Yes, we do some lite internal review for some very simple reasons: people are still getting used to submitting patches to mainline so they make easily fixable mistakes that we can weed out with the internal review; the second reason (and that applies only when we add new functionality to the driver) is to scan for possible patent violations. I'm pretty sure that something similar exists in most companies. Note that this does not exclude the public mailing lists. We have received contributions via dri-devel ML (look at the last pull request, it features one external contributor) and there is no replacement internally for dri-devel. The mal...@foss.arm.com mailing list exists only to allow for a quick response time from any of the contributors in case some of us are travelling or on holiday which you don't get with direct email addresses. I've made that clear in private conversations and I wil re-iterate it here: Mali DP team is mainline first and cross-driver focused. However, we are not operating as a separate entity from the rest of ARM, so we have to obey some internal processes. Best regards, Liviu > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/fourcc: add vivante tiled layout format modifiers
On Thu, 2017-01-26 at 19:29 +0100, Wladimir J. van der Laan wrote: > Reviewed-By: Wladimir J. van der Laan Thank you. > I do wonder whether we'll need the split formats in practice - > e.g. the GC3000 on the i.MX6qp, for which I suppose this is being done because > of tiled buffers support in the PRE, has the "single buffer" feature > which allows rendering to a single buffer with multiple pixel pipes. > This is what the Vivante driver uses. > > But it can't hurt reserving formats for them. I added them in case it later turns out that avoiding the resolve copy is advantageous on GC2000 in combination with USB DisplayLink style outputs, where the CPU could directly process the split-tiled buffers. regards Philipp ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/color: un-inline drm_color_lut_extract()
Hi Jani,
Looks good to me :
Reviewed-by: Lionel Landwerlin
On 23/01/17 09:42, Jani Nikula wrote:
The function is not that big, but it's also not used for anything
performance critical. Make it a normal function.
As a side effect, this apparently makes sparse smarter about what it's
doing, and gets rid of the warning:
./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
type unsigned long
./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
constant value (8000 becomes 0)
Cc: Lionel Landwerlin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 27 ++-
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..5618f60c7690 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,30 @@
*/
/**
+ * drm_color_lut_extract - clamp&round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract);
+
+/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
* @degamma_lut_size: the size of the degamma lut (before CSC)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index c767238ac9d5..bce4a532836d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#include
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
bool has_ctm,
@@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-/**
- * drm_color_lut_extract - clamp&round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-static inline uint32_t drm_color_lut_extract(uint32_t user_input,
-uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-
-
#endif
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 07/19] drm/etnaviv: Remove etnaviv_debugfs_cleanup()
Am Donnerstag, den 26.01.2017, 23:56 +0100 schrieb Noralf Trønnes:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so the drm_driver.debugfs_cleanup callback is not
> needed.
>
> Cc: l.st...@pengutronix.de
> Cc: linux+etna...@armlinux.org.uk
> Cc: christian.gmei...@gmail.com
> Signed-off-by: Noralf Trønnes
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_drv.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> index b92c24e..590be0d 100644
> --- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> +++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
> @@ -258,12 +258,6 @@ static int etnaviv_debugfs_init(struct drm_minor *minor)
>
> return ret;
> }
> -
> -static void etnaviv_debugfs_cleanup(struct drm_minor *minor)
> -{
> - drm_debugfs_remove_files(etnaviv_debugfs_list,
> - ARRAY_SIZE(etnaviv_debugfs_list), minor);
> -}
> #endif
>
> /*
> @@ -509,7 +503,6 @@ static struct drm_driver etnaviv_drm_driver = {
> .gem_prime_mmap = etnaviv_gem_prime_mmap,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = etnaviv_debugfs_init,
> - .debugfs_cleanup= etnaviv_debugfs_cleanup,
> #endif
> .ioctls = etnaviv_ioctls,
> .num_ioctls = DRM_ETNAVIV_NUM_IOCTLS,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 06/19] drm/etnaviv: allow build with COMPILE_TEST
Am Donnerstag, den 26.01.2017, 23:56 +0100 schrieb Noralf Trønnes: > Make it possible to compile test the driver on other platforms. > > Cc: l.st...@pengutronix.de > Cc: linux+etna...@armlinux.org.uk > Cc: christian.gmei...@gmail.com > Signed-off-by: Noralf Trønnes I'm not sure we are pulling in all dependencies on other platforms, but as I have no good way to check right now, lets go with the patch and see if anything blows up: Acked-by: Lucas Stach > --- > 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 656c061..cc1731c 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 > + depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST) > depends on MMU > select SHMEM > select TMPFS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
make fbdev/fbcon switchable per driver?
Hi folks,
Problem at hand: A virtual machine, equipped with two display devices,
one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
There is no easy way for the user to configure which of the two display
devices fbcon should run on. i915 happens to win over bochs-drm or qxl,
so you can't use the emulated gfx device as text console.
One way out would be to add a module option to each driver, to turn off
fbdev emulation. Attached patch does that for i915.
Comments? Better ideas?
cheers,
Gerd
From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
From: Gerd Hoffmann
Date: Fri, 27 Jan 2017 08:05:40 +0100
Subject: [PATCH] drm i915: add fbdev option
Signed-off-by: Gerd Hoffmann
---
drivers/gpu/drm/i915/intel_fbdev.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c b/drivers/gpu/drm/i915/intel_fbdev.c
index 3e3632c..cc0ba3e 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -45,6 +45,11 @@
#include
#include "i915_drv.h"
+static bool enable_fbdev = true;
+module_param_named(fbdev, enable_fbdev, bool, 0600);
+MODULE_PARM_DESC(fbdev,
+ "Enable legacy fbdev emulation [default=true]");
+
static int intel_fbdev_set_par(struct fb_info *info)
{
struct drm_fb_helper *fb_helper = info->par;
@@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
int ret;
+ if (!enable_fbdev)
+ return 0;
+
if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
return -ENODEV;
@@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device *dev)
{
struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
+ if (!ifbdev)
+ return;
ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
}
--
1.8.3.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 15/19] drm/tilcdc: Remove tilcdc_debugfs_cleanup()
On 01/27/17 00:56, Noralf Trønnes wrote: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so the drm_driver.debugfs_cleanup callback is not > needed. Also remove the unused tilcdc_module_ops.debugfs_cleanup() > callback. drm_debugfs_cleanup() removes all debugfs files using > debugfs_remove_recursive(), so there should be no need for such a > callback in the future. > > Cc: jsa...@ti.com > Cc: tomi.valkei...@ti.com > Signed-off-by: Noralf Trønnes Reviewed-by: Jyri Sarha ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/omapdrm: Move commit_modeset_enables() before commit_planes()
Move drm_atomic_helper_commit_modeset_enables() call to before drm_atomic_helper_commit_planes() call and have a omap_atomic_wait_for_completion() call after both. With the current dss dispc implementation we have to enable the new modeset before we can commit planes. The dispc ovl configuration relies on the video mode configuration been written into the HW when the ovl configuration is calculated. This approach is not ideal because after a mode change the plane update is executed only after the first vblank interrupt. The dispc implementation should be fixed so that it is able use uncommitted drm state information. information. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/omapdrm/omap_drv.c | 16 +++- 1 file changed, 15 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 5e55f1b..8c15735 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -96,8 +96,22 @@ static void omap_atomic_complete(struct omap_atomic_state_commit *commit) dispc_runtime_get(); drm_atomic_helper_commit_modeset_disables(dev, old_state); - drm_atomic_helper_commit_planes(dev, old_state, 0); + + /* With the current dss dispc implementation we have to enable +* the new modeset before we can commit planes. The dispc ovl +* configuration relies on the video mode configuration been +* written into the HW when the ovl configuration is +* calculated. +* +* This approach is not ideal because after a mode change the +* plane update is executed only after the first vblank +* interrupt. The dispc implementation should be fixed so that +* it is able use uncommitted drm state information. +*/ drm_atomic_helper_commit_modeset_enables(dev, old_state); + omap_atomic_wait_for_completion(dev, old_state); + + drm_atomic_helper_commit_planes(dev, old_state, 0); omap_atomic_wait_for_completion(dev, old_state); -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] Revert "drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCs"
This reverts commit dadf4659d0608e034b6633f30300c2eff2dafb4c. If planes are not disabled when the they are not on any crtc anymore they will remain active and may show as "ghosts" when the crtc they were last on is active again. Signed-off-by: Jyri Sarha --- drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +--- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +-- 2 files changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/omapdrm/omap_crtc.c b/drivers/gpu/drm/omapdrm/omap_crtc.c index dd47dc1..b68c70e 100644 --- a/drivers/gpu/drm/omapdrm/omap_crtc.c +++ b/drivers/gpu/drm/omapdrm/omap_crtc.c @@ -410,13 +410,7 @@ static void omap_crtc_atomic_flush(struct drm_crtc *crtc, dispc_mgr_set_gamma(omap_crtc->channel, lut, length); } - /* -* Only flush the CRTC if it is currently enabled. CRTCs that require a -* mode set are disabled prior plane updates and enabled afterwards. -* They are thus not active (regardless of what their CRTC core state -* reports) and the DRM core could thus call this function even though -* the CRTC is currently disabled. Do nothing in that case. -*/ + /* Only flush the CRTC if it is currently enabled. */ if (!omap_crtc->enabled) return; diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 00aa214..5e55f1b 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -96,8 +96,7 @@ static void omap_atomic_complete(struct omap_atomic_state_commit *commit) dispc_runtime_get(); drm_atomic_helper_commit_modeset_disables(dev, old_state); - drm_atomic_helper_commit_planes(dev, old_state, - DRM_PLANE_COMMIT_ACTIVE_ONLY); + drm_atomic_helper_commit_planes(dev, old_state, 0); drm_atomic_helper_commit_modeset_enables(dev, old_state); omap_atomic_wait_for_completion(dev, old_state); -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 0/2] drm/omapdrm: Couple of plane related fixes
I hit these two problems while tracking scaling related problems with omapdrm on DSS5 HW. Jyri Sarha (2): Revert "drm: omapdrm: Let the DRM core skip plane commit on inactive CRTCs" drm/omapdrm: Move commit_modeset_enables() before commit_planes() drivers/gpu/drm/omapdrm/omap_crtc.c | 8 +--- drivers/gpu/drm/omapdrm/omap_drv.c | 17 +++-- 2 files changed, 16 insertions(+), 9 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 --- Comment #22 from Dorota Czaplejewicz --- I haven't seen the underlying slowness causing problems anywhere else yet. Perhaps we can close this and reopen if it reappears. -- 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 99130] [IVB] CONFIG_PROVE_LOCKING=y causes igt/gem_exec/basic-wait-all (and possibly others) to fail
https://bugs.freedesktop.org/show_bug.cgi?id=99130 Chris Wilson changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED -- 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/atomic: clear out fence when duplicating state
The fence needs to be cleared out, otherwise the following commit might wait on a stale fence from the previous commit. This was fixed as a side effect of 9626014258a5 (drm/fence: add in-fences support) in kernel 4.10. As this commit introduces new functionality and as such can not be applied to stable, this patch is the minimal fix for the kernel 4.9 stable series. Signed-off-by: Lucas Stach --- drivers/gpu/drm/drm_atomic_helper.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index 21f992605541..8ace20a5bf64 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -3113,6 +3113,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct drm_plane *plane, if (state->fb) drm_framebuffer_reference(state->fb); + + state->fence = NULL; } EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Warning at drivers/gpu/drm/drm_atomic_helper.c
Am Mittwoch, den 25.01.2017, 09:47 -0200 schrieb Fabio Estevam: > On Wed, Jan 25, 2017 at 9:30 AM, Lucas Stach wrote: > > > Kernel 4.10 just moves the fence attach to the plane state. It has > > nothing to do with the used commit function. The issue going away if you > > change that on kernel 4.9 is a red herring. > > > > In any case, can you try the attached patch? It's against 4.10, if you > > want to test it on 4.9 you need to replace dma_fence_put(), with > > fence_put(). > > Just tested it on 4.9 (using fence_put()) and I can still get the > warning sometimes: > http://pastebin.com/p6acMLcY > Okay, after looking more at the 4.9 code, I understand what's going on. I've just sent out a patch to fix this issue for kernel 4.9. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 13/19] drm/sti: Remove drm_debugfs_remove_files() calls
Thank for this patch.
It is working fine with sti driver.
Acked-by: Vincent Abriou
Tested-by: Vincent Abriou
Vincent
On 01/26/2017 11:56 PM, Noralf Trønnes wrote:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so it's not necessary to call
> drm_debugfs_remove_files(). Additionally it uses
> debugfs_remove_recursive() to clean up the debugfs files, so no need
> for adding fake drm_info_node entries.
>
> Cc: benjamin.gaign...@linaro.org
> Cc: vincent.abr...@st.com
> Signed-off-by: Noralf Trønnes
> ---
> drivers/gpu/drm/sti/sti_drv.c | 48
> ++---
> drivers/gpu/drm/sti/sti_dvo.c | 10 -
> drivers/gpu/drm/sti/sti_hda.c | 11 --
> drivers/gpu/drm/sti/sti_hdmi.c | 11 --
> drivers/gpu/drm/sti/sti_tvout.c | 8 ---
> 5 files changed, 6 insertions(+), 82 deletions(-)
>
> diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
> index ff71e25..d3db224 100644
> --- a/drivers/gpu/drm/sti/sti_drv.c
> +++ b/drivers/gpu/drm/sti/sti_drv.c
> @@ -89,38 +89,9 @@ static struct drm_info_list sti_drm_dbg_list[] = {
> {"fps_get", sti_drm_fps_dbg_show, 0},
> };
>
> -static int sti_drm_debugfs_create(struct dentry *root,
> - struct drm_minor *minor,
> - const char *name,
> - const struct file_operations *fops)
> -{
> - struct drm_device *dev = minor->dev;
> - struct drm_info_node *node;
> - struct dentry *ent;
> -
> - ent = debugfs_create_file(name, S_IRUGO | S_IWUSR, root, dev, fops);
> - if (IS_ERR(ent))
> - return PTR_ERR(ent);
> -
> - node = kmalloc(sizeof(*node), GFP_KERNEL);
> - if (!node) {
> - debugfs_remove(ent);
> - return -ENOMEM;
> - }
> -
> - node->minor = minor;
> - node->dent = ent;
> - node->info_ent = (void *)fops;
> -
> - mutex_lock(&minor->debugfs_lock);
> - list_add(&node->list, &minor->debugfs_list);
> - mutex_unlock(&minor->debugfs_lock);
> -
> - return 0;
> -}
> -
> static int sti_drm_dbg_init(struct drm_minor *minor)
> {
> + struct dentry *dentry;
> int ret;
>
> ret = drm_debugfs_create_files(sti_drm_dbg_list,
> @@ -129,10 +100,13 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
> if (ret)
> goto err;
>
> - ret = sti_drm_debugfs_create(minor->debugfs_root, minor, "fps_show",
> + dentry = debugfs_create_file("fps_show", S_IRUGO | S_IWUSR,
> + minor->debugfs_root, minor->dev,
>&sti_drm_fps_fops);
> - if (ret)
> + if (!dentry) {
> + ret = -ENOMEM;
> goto err;
> + }
>
> DRM_INFO("%s: debugfs installed\n", DRIVER_NAME);
> return 0;
> @@ -141,15 +115,6 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
> return ret;
> }
>
> -static void sti_drm_dbg_cleanup(struct drm_minor *minor)
> -{
> - drm_debugfs_remove_files(sti_drm_dbg_list,
> - ARRAY_SIZE(sti_drm_dbg_list), minor);
> -
> - drm_debugfs_remove_files((struct drm_info_list *)&sti_drm_fps_fops,
> - 1, minor);
> -}
> -
> static void sti_atomic_schedule(struct sti_private *private,
> struct drm_atomic_state *state)
> {
> @@ -326,7 +291,6 @@ static struct drm_driver sti_driver = {
> .gem_prime_mmap = drm_gem_cma_prime_mmap,
>
> .debugfs_init = sti_drm_dbg_init,
> - .debugfs_cleanup = sti_drm_dbg_cleanup,
>
> .name = DRIVER_NAME,
> .desc = DRIVER_DESC,
> diff --git a/drivers/gpu/drm/sti/sti_dvo.c b/drivers/gpu/drm/sti/sti_dvo.c
> index 411dc6e..bb23318 100644
> --- a/drivers/gpu/drm/sti/sti_dvo.c
> +++ b/drivers/gpu/drm/sti/sti_dvo.c
> @@ -195,13 +195,6 @@ static struct drm_info_list dvo_debugfs_files[] = {
> { "dvo", dvo_dbg_show, 0, NULL },
> };
>
> -static void dvo_debugfs_exit(struct sti_dvo *dvo, struct drm_minor *minor)
> -{
> - drm_debugfs_remove_files(dvo_debugfs_files,
> - ARRAY_SIZE(dvo_debugfs_files),
> - minor);
> -}
> -
> static int dvo_debugfs_init(struct sti_dvo *dvo, struct drm_minor *minor)
> {
> unsigned int i;
> @@ -514,9 +507,6 @@ static void sti_dvo_unbind(struct device *dev,
> struct device *master, void *data)
> {
> struct sti_dvo *dvo = dev_get_drvdata(dev);
> - struct drm_device *drm_dev = data;
> -
> - dvo_debugfs_exit(dvo, drm_dev->primary);
>
> drm_bridge_remove(dvo->bridge);
> }
> diff --git a/drivers/gpu/drm/sti/sti_hda.c b/drivers/gpu/drm/sti/sti_hda.c
> index 66d37d78..0c0a75b 100644
> --- a/drivers/gpu/drm/sti/sti_hda.c
> +++ b/drivers/gpu/drm/sti/sti_hda.c
> @@ -365,13 +365,6 @@ static struct drm_info_list hda_debugfs_files[] = {
> { "hda", hda_dbg_show, 0, NULL },
> };
>
>
[PATCH] drm/color: Include CTM equations in kerneldoc
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property.
Cc: Ville Syrjälä
Cc: Lionel Landwerlin
Cc: Daniel Vetter
Signed-off-by: Brian Starkey
---
Hi,
This captures the outcome of the discussion on #dri-devel yesterday
(2017-01-26):
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
I'm not sure about the stance on such explicit rst markup in kerneldoc,
but without it the equations are pretty unreadable in the rendered
output.
Cheers,
Brian
drivers/gpu/drm/drm_color_mgmt.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..63f3a7404fa1 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -62,6 +62,16 @@
* unit/pass-thru matrix should be used. This is generally the driver
* boot-up state too.
*
+ * Given an input vector ``in[3]`` and an output vector ``out[3]``, the
+ * transformation applied is:
+ *
+ * | ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2] *
in[2];``
+ * | ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5] *
in[2];``
+ * | ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8] *
in[2];``
+ *
+ * | For RGB formats, the input vector is assumed to be ``{ R, G, B }``.
+ * | For YCbCr formats, the input vector is assumed to be ``{ Y, Cb, Cr
}``.
+ *
* “GAMMA_LUT”:
* Blob property to set the gamma lookup table (LUT) mapping pixel data
* after the transformation matrix to data sent to the connector. The
--
1.7.9.5
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Lionel Landwerlin wrote:
> Hi Jani,
>
> Looks good to me :
>
> Reviewed-by: Lionel Landwerlin
Thanks for the reviews, pushed... to drm-intel-next-queued instead of
drm-misc-next. /o\
Dave, Daniel, please advise, shall I revert or shall we let this flow in
via drm-intel?
Sorry for the mess.
BR,
Jani.
>
> On 23/01/17 09:42, Jani Nikula wrote:
>> The function is not that big, but it's also not used for anything
>> performance critical. Make it a normal function.
>>
>> As a side effect, this apparently makes sparse smarter about what it's
>> doing, and gets rid of the warning:
>>
>> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295)
>> for type unsigned long
>> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
>> constant value (8000 becomes 0)
>>
>> Cc: Lionel Landwerlin
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/drm_color_mgmt.c | 24
>> include/drm/drm_color_mgmt.h | 27 ++-
>> 2 files changed, 26 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>> b/drivers/gpu/drm/drm_color_mgmt.c
>> index 789b4c65cd69..5618f60c7690 100644
>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>> @@ -88,6 +88,30 @@
>>*/
>>
>> /**
>> + * drm_color_lut_extract - clamp&round LUT entries
>> + * @user_input: input value
>> + * @bit_precision: number of bits the hw LUT supports
>> + *
>> + * Extract a degamma/gamma LUT value provided by user (in the form of
>> + * &drm_color_lut entries) and round it to the precision supported by the
>> + * hardware.
>> + */
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
>> +{
>> +uint32_t val = user_input;
>> +uint32_t max = 0x >> (16 - bit_precision);
>> +
>> +/* Round only if we're not using full precision. */
>> +if (bit_precision < 16) {
>> +val += 1UL << (16 - bit_precision - 1);
>> +val >>= 16 - bit_precision;
>> +}
>> +
>> +return clamp_val(val, 0, max);
>> +}
>> +EXPORT_SYMBOL(drm_color_lut_extract);
>> +
>> +/**
>>* drm_crtc_enable_color_mgmt - enable color management properties
>>* @crtc: DRM CRTC
>>* @degamma_lut_size: the size of the degamma lut (before CSC)
>> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>> index c767238ac9d5..bce4a532836d 100644
>> --- a/include/drm/drm_color_mgmt.h
>> +++ b/include/drm/drm_color_mgmt.h
>> @@ -25,6 +25,8 @@
>>
>> #include
>>
>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
>> +
>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> uint degamma_lut_size,
>> bool has_ctm,
>> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>> int gamma_size);
>>
>> -/**
>> - * drm_color_lut_extract - clamp&round LUT entries
>> - * @user_input: input value
>> - * @bit_precision: number of bits the hw LUT supports
>> - *
>> - * Extract a degamma/gamma LUT value provided by user (in the form of
>> - * &drm_color_lut entries) and round it to the precision supported by the
>> - * hardware.
>> - */
>> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
>> - uint32_t bit_precision)
>> -{
>> -uint32_t val = user_input;
>> -uint32_t max = 0x >> (16 - bit_precision);
>> -
>> -/* Round only if we're not using full precision. */
>> -if (bit_precision < 16) {
>> -val += 1UL << (16 - bit_precision - 1);
>> -val >>= 16 - bit_precision;
>> -}
>> -
>> -return clamp_val(val, 0, max);
>> -}
>> -
>> -
>> #endif
>
>
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/atomic: clear out fence when duplicating state
Hi Lucas, On Fri, Jan 27, 2017 at 8:33 AM, Lucas Stach wrote: > The fence needs to be cleared out, otherwise the following commit > might wait on a stale fence from the previous commit. This was fixed > as a side effect of 9626014258a5 (drm/fence: add in-fences support) > in kernel 4.10. > > As this commit introduces new functionality and as such can not be > applied to stable, this patch is the minimal fix for the kernel 4.9 > stable series. > > Signed-off-by: Lucas Stach Excellent: this fixes the kernel warning on 4.9.x. I can now stop kmscube several times without getting any kernel warning: Tested-by: Fabio Estevam ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/19] drm/hdlcd: Remove hdlcd_debugfs_cleanup()
On Thu, Jan 26, 2017 at 11:56:10PM +0100, Noralf Trønnes wrote:
> drm_debugfs_cleanup() now removes all minor->debugfs_list entries
> automatically, so the drm_driver.debugfs_cleanup callback is not
> needed.
>
> Cc: liviu.du...@arm.com
> Signed-off-by: Noralf Trønnes
Acked-by: Liviu Dudau
Thanks!
Liviu
> ---
> drivers/gpu/drm/arm/hdlcd_drv.c | 7 ---
> 1 file changed, 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e5f4f4a..a2e5b04 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -255,12 +255,6 @@ static int hdlcd_debugfs_init(struct drm_minor *minor)
> return drm_debugfs_create_files(hdlcd_debugfs_list,
> ARRAY_SIZE(hdlcd_debugfs_list), minor->debugfs_root, minor);
> }
> -
> -static void hdlcd_debugfs_cleanup(struct drm_minor *minor)
> -{
> - drm_debugfs_remove_files(hdlcd_debugfs_list,
> - ARRAY_SIZE(hdlcd_debugfs_list), minor);
> -}
> #endif
>
> static const struct file_operations fops = {
> @@ -303,7 +297,6 @@ static struct drm_driver hdlcd_driver = {
> .gem_prime_mmap = drm_gem_cma_prime_mmap,
> #ifdef CONFIG_DEBUG_FS
> .debugfs_init = hdlcd_debugfs_init,
> - .debugfs_cleanup = hdlcd_debugfs_cleanup,
> #endif
> .fops = &fops,
> .name = "hdlcd",
> --
> 2.10.2
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] Gpu: drm: rockchip - Fix possible NULL derefrence.
On Fri, Jan 27, 2017 at 04:41:50PM +0530, Shailendra Verma wrote:
> of_match_device could return NULL, and so can cause a NULL
> pointer dereference later.
>
> Signed-off-by: Shailendra Verma
> ---
> drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 13 ++---
> 1 file changed, 10 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> index ca22e5e..dbb99cf 100644
> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> @@ -1082,15 +1082,22 @@ static enum drm_mode_status
> rk3288_mipi_dsi_mode_valid(
> static int dw_mipi_dsi_bind(struct device *dev, struct device *master,
>void *data)
> {
> - const struct of_device_id *of_id =
> - of_match_device(dw_mipi_dsi_dt_ids, dev);
> - const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
> + const struct of_device_id *of_id;
> + const struct dw_mipi_dsi_plat_data *pdata;
> struct platform_device *pdev = to_platform_device(dev);
> struct drm_device *drm = data;
> struct dw_mipi_dsi *dsi;
> struct resource *res;
> int ret;
>
> + of_id = of_match_device(dw_mipi_dsi_dt_ids, dev);
> + if (!of_id) {
> + dev_err(dev, "Error: No device match found\n");
> + return -ENODEV;
> + }
> +
> + pdata = of_id->data;
> +
> dsi = devm_kzalloc(dev, sizeof(*dsi), GFP_KERNEL);
> if (!dsi)
> return -ENOMEM;
Hello
You could use of_device_get_match_data()
Regards
Corentin Labbe
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/color: Include CTM equations in kerneldoc
On Fri, Jan 27, 2017 at 10:47:48AM +, Brian Starkey wrote:
> Explicitly state the expected CTM equations in the kerneldoc for the CTM
> property.
>
> Cc: Ville Syrjälä
> Cc: Lionel Landwerlin
> Cc: Daniel Vetter
> Signed-off-by: Brian Starkey
> ---
>
> Hi,
>
> This captures the outcome of the discussion on #dri-devel yesterday
> (2017-01-26):
> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
>
> I'm not sure about the stance on such explicit rst markup in kerneldoc,
> but without it the equations are pretty unreadable in the rendered
> output.
>
> Cheers,
> Brian
>
> drivers/gpu/drm/drm_color_mgmt.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> b/drivers/gpu/drm/drm_color_mgmt.c
> index 789b4c65cd69..63f3a7404fa1 100644
> --- a/drivers/gpu/drm/drm_color_mgmt.c
> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> @@ -62,6 +62,16 @@
> * unit/pass-thru matrix should be used. This is generally the driver
> * boot-up state too.
> *
> + * Given an input vector ``in[3]`` and an output vector ``out[3]``, the
> + * transformation applied is:
> + *
> + * | ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2] *
> in[2];``
> + * | ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5] *
> in[2];``
> + * | ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8] *
> in[2];``
> + *
> + * | For RGB formats, the input vector is assumed to be ``{ R, G, B }``.
> + * | For YCbCr formats, the input vector is assumed to be ``{ Y, Cb, Cr
> }``.
Talking about formats here could be a little confusing. One might think
this has something to do with the framebuffer pixel format, when in fact
it's only about the internal format used by the crtc.
And actually I don't think we can get away this easily for YCbCr since
there is no way to indicate to userspace whether the pipe is internally
RGB or YCbCr. Until we add a property to indicate RGB vs. YCbCr internal
crtc formt (which userspace could actually set if the hardware allows it)
we shouldn't even mention YCbCr. If there is hardware out there that
always uses YCbCr, then I think those folks need to come up with a
property to indicate that, or they'll just have to do the RGB->YCbCr
conversion in the driver when populating the matrix.
> + *
> * “GAMMA_LUT”:
> * Blob property to set the gamma lookup table (LUT) mapping pixel data
> * after the transformation matrix to data sent to the connector. The
> --
> 1.7.9.5
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[drm-intel:drm-intel-next-queued 0/1] htmldocs: include/drm/drm_color_mgmt.h:1: warning: no structured comments found
tree: git://anongit.freedesktop.org/drm-intel drm-intel-next-queued head: 920bcd1820a6966b6224f62eadcb4e931bb72e8e commit: 2eebe4f2d5f4c91edc37801d828ba29edfbc7722 [0/1] drm/color: un-inline drm_color_lut_extract() reproduce: make htmldocs All warnings (new ones prefixed by >>): make[3]: warning: jobserver unavailable: using -j1. Add '+' to parent make rule. include/linux/init.h:1: warning: no structured comments found include/linux/kthread.h:26: warning: Excess function parameter '...' description in 'kthread_create' kernel/sys.c:1: warning: no structured comments found drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found include/drm/drm_drv.h:441: warning: No description found for parameter 'firstopen' include/drm/drm_drv.h:441: warning: No description found for parameter 'open' include/drm/drm_drv.h:441: warning: No description found for parameter 'preclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'postclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'lastclose' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_ioctl' include/drm/drm_drv.h:441: warning: No description found for parameter 'dma_quiescent' include/drm/drm_drv.h:441: warning: No description found for parameter 'context_dtor' include/drm/drm_drv.h:441: warning: No description found for parameter 'set_busid' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_handler' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_preinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_postinstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'irq_uninstall' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_init' include/drm/drm_drv.h:441: warning: No description found for parameter 'debugfs_cleanup' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_open_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_close_object' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_handle_to_fd' include/drm/drm_drv.h:441: warning: No description found for parameter 'prime_fd_to_handle' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_export' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_pin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_unpin' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_res_obj' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_get_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_import_sg_table' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_vunmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_prime_mmap' include/drm/drm_drv.h:441: warning: No description found for parameter 'vgaarb_irq' include/drm/drm_drv.h:441: warning: No description found for parameter 'gem_vm_ops' include/drm/drm_drv.h:441: warning: No description found for parameter 'major' include/drm/drm_drv.h:441: warning: No description found for parameter 'minor' include/drm/drm_drv.h:441: warning: No description found for parameter 'patchlevel' include/drm/drm_drv.h:441: warning: No description found for parameter 'name' include/drm/drm_drv.h:441: warning: No description found for parameter 'desc' include/drm/drm_drv.h:441: warning: No description found for parameter 'date' include/drm/drm_drv.h:441: warning: No description found for parameter 'driver_features' include/drm/drm_drv.h:441: warning: No description found for parameter 'dev_priv_size' include/drm/drm_drv.h:441: warning: No description found for parameter 'ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'num_ioctls' include/drm/drm_drv.h:441: warning: No description found for parameter 'fops' include/drm/drm_drv.h:441: warning: No description found for parameter 'legacy_dev_list' >> include/drm/drm_color_mgmt.h:1: warning: no structured comments found drivers/media/dvb-core/dvb_frontend.h:677: warning: No description found for parameter 'refcount' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'filp' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'buf' drivers/char/tpm/tpm_vtpm_proxy.c:73: warning: No description found for parameter 'count' drivers
Re: [PATCH v2 11/13] drm/i915: Add intel_uncore_suspend / resume functions
On Mon, Jan 23, 2017 at 10:09:56PM +0100, Hans de Goede wrote:
> Rename intel_uncore_early_sanitize to intel_uncore_resume, dropping the
> (always true) restore_forcewake argument and add a new intel_uncore_resume
> function to replace the intel_uncore_forcewake_reset(dev_priv, false)
> calls done from the suspend / runtime_suspend functions and make
> intel_uncore_forcewake_reset private.
>
> This is a preparation patch for adding PMIC bus access notifier support.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> ---
> drivers/gpu/drm/i915/i915_drv.c | 6 +++---
> drivers/gpu/drm/i915/i915_drv.h | 6 ++
> drivers/gpu/drm/i915/intel_uncore.c | 18 +++---
> 3 files changed, 16 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index aefab9a..5a62d7a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1445,7 +1445,7 @@ static int i915_drm_suspend(struct drm_device *dev)
> opregion_target_state = suspend_to_idle(dev_priv) ? PCI_D1 : PCI_D3cold;
> intel_opregion_notify_adapter(dev_priv, opregion_target_state);
>
> - intel_uncore_forcewake_reset(dev_priv, false);
> + intel_uncore_suspend(dev_priv);
> intel_opregion_unregister(dev_priv);
>
> intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
> @@ -1690,7 +1690,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
> DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
> ret);
>
> - intel_uncore_early_sanitize(dev_priv, true);
> + intel_uncore_resume(dev_priv);
>
> if (IS_GEN9_LP(dev_priv)) {
> if (!dev_priv->suspended_to_idle)
> @@ -2344,7 +2344,7 @@ static int intel_runtime_suspend(struct device *kdev)
> return ret;
> }
>
> - intel_uncore_forcewake_reset(dev_priv, false);
> + intel_uncore_suspend(dev_priv);
Doing one from early_resume and the other from the normal suspend makes
my brain hurt a little. If we do that I think we should at least name
the functions appropriately.
>
> enable_rpm_wakeref_asserts(dev_priv);
> WARN_ON_ONCE(atomic_read(&dev_priv->pm.wakeref_count));
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e9b4ece..c717329 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2976,14 +2976,12 @@ int intel_irq_install(struct drm_i915_private
> *dev_priv);
> void intel_irq_uninstall(struct drm_i915_private *dev_priv);
>
> extern void intel_uncore_sanitize(struct drm_i915_private *dev_priv);
> -extern void intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
> - bool restore_forcewake);
> extern void intel_uncore_init(struct drm_i915_private *dev_priv);
> extern bool intel_uncore_unclaimed_mmio(struct drm_i915_private *dev_priv);
> extern bool intel_uncore_arm_unclaimed_mmio_detection(struct
> drm_i915_private *dev_priv);
> extern void intel_uncore_fini(struct drm_i915_private *dev_priv);
> -extern void intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> - bool restore);
> +extern void intel_uncore_suspend(struct drm_i915_private *dev_priv);
> +extern void intel_uncore_resume(struct drm_i915_private *dev_priv);
> const char *intel_uncore_forcewake_domain_to_str(const enum
> forcewake_domain_id id);
> void intel_uncore_forcewake_get(struct drm_i915_private *dev_priv,
> enum forcewake_domains domains);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index abe0888..3767307 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -250,7 +250,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
> return HRTIMER_NORESTART;
> }
>
> -void intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> +static void __intel_uncore_forcewake_reset(struct drm_i915_private *dev_priv,
> bool restore)
Maybe leave out this rename to keep the diff a little easier to parse.
> {
> unsigned long irqflags;
> @@ -424,13 +424,17 @@ static void __intel_uncore_early_sanitize(struct
> drm_i915_private *dev_priv,
> if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST))
> info->has_decoupled_mmio = false;
>
> - intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
> + __intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
> }
>
> -void intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
> - bool restore_forcewake)
> +void intel_uncore_suspend(struct drm_i915_private *dev_priv)
> {
> - __intel_uncore_early_sanit
Re: [PATCH] drm/color: Include CTM equations in kerneldoc
On Fri, Jan 27, 2017 at 03:27:09PM +0200, Ville Syrjälä wrote:
On Fri, Jan 27, 2017 at 10:47:48AM +, Brian Starkey wrote:
Explicitly state the expected CTM equations in the kerneldoc for the CTM
property.
Cc: Ville Syrjälä
Cc: Lionel Landwerlin
Cc: Daniel Vetter
Signed-off-by: Brian Starkey
---
Hi,
This captures the outcome of the discussion on #dri-devel yesterday
(2017-01-26):
https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
I'm not sure about the stance on such explicit rst markup in kerneldoc,
but without it the equations are pretty unreadable in the rendered
output.
Cheers,
Brian
drivers/gpu/drm/drm_color_mgmt.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..63f3a7404fa1 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -62,6 +62,16 @@
* unit/pass-thru matrix should be used. This is generally the driver
* boot-up state too.
*
+ * Given an input vector ``in[3]`` and an output vector ``out[3]``, the
+ * transformation applied is:
+ *
+ * | ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2] *
in[2];``
+ * | ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5] *
in[2];``
+ * | ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8] *
in[2];``
+ *
+ * | For RGB formats, the input vector is assumed to be ``{ R, G, B }``.
+ * | For YCbCr formats, the input vector is assumed to be ``{ Y, Cb, Cr
}``.
Talking about formats here could be a little confusing. One might think
this has something to do with the framebuffer pixel format, when in fact
it's only about the internal format used by the crtc.
Ah right, yes I see.
Actually, I *was* thinking about the framebuffer format here - but
that is missing the context of us adding a CTM property for each plane
(so that each plane can map the framebuffer format to the CRTC pipe's
internal format).
Our intention (for Mali-DP) is to add CTM on each plane to be used
for framebuffer -> CRTC pipe conversion, and then use the CTM on the
CRTC for CRTC pipe -> output conversion.
Shall I just remove the two lines about pixel formats here, and then
when we land per-plane CTM add some details about plane CTM matrices
being before the CRTC CTM matrix?
Thanks,
-Brian
And actually I don't think we can get away this easily for YCbCr since
there is no way to indicate to userspace whether the pipe is internally
RGB or YCbCr. Until we add a property to indicate RGB vs. YCbCr internal
crtc formt (which userspace could actually set if the hardware allows it)
we shouldn't even mention YCbCr. If there is hardware out there that
always uses YCbCr, then I think those folks need to come up with a
property to indicate that, or they'll just have to do the RGB->YCbCr
conversion in the driver when populating the matrix.
+ *
* “GAMMA_LUT”:
* Blob property to set the gamma lookup table (LUT) mapping pixel data
* after the transformation matrix to data sent to the connector. The
--
1.7.9.5
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/13] drm/i915: Acquire P-Unit access when modifying P-Unit settings
On Mon, Jan 23, 2017 at 10:09:58PM +0100, Hans de Goede wrote:
> Make sure the P-Unit or the PMIC i2c bus is not in use when we send a
> request to the P-Unit by calling iosf_mbi_punit_acquire() / _release()
> around P-Unit write accesses.
Can't we just stuff the calls into the actual punit write function
rather than sprinkling them all over the place?
+ a comment would be nice why it's there.
Do we need a kconfig select/depends on the iosf_mbi thing? Or some
ifdefs?
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> -Adjust for iosf_mbi_punit_lock/_unlock to _acquire/_release rename
> ---
> drivers/gpu/drm/i915/intel_display.c| 6 ++
> drivers/gpu/drm/i915/intel_pm.c | 9 +
> drivers/gpu/drm/i915/intel_runtime_pm.c | 9 +
> 3 files changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 5604701..13e5152 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -47,6 +47,7 @@
> #include
> #include
> #include
> +#include
>
> static bool is_mmio_work(struct intel_flip_work *work)
> {
> @@ -6421,6 +6422,8 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
> cmd = 0;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
> +
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> val &= ~DSPFREQGUAR_MASK;
> val |= (cmd << DSPFREQGUAR_SHIFT);
> @@ -6430,6 +6433,7 @@ static void valleyview_set_cdclk(struct drm_device
> *dev, int cdclk)
>50)) {
> DRM_ERROR("timed out waiting for CDclk change\n");
> }
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
>
> mutex_lock(&dev_priv->sb_lock);
> @@ -6497,6 +6501,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
> cmd = DIV_ROUND_CLOSEST(dev_priv->hpll_freq << 1, cdclk) - 1;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> val &= ~DSPFREQGUAR_MASK_CHV;
> val |= (cmd << DSPFREQGUAR_SHIFT_CHV);
> @@ -6506,6 +6511,7 @@ static void cherryview_set_cdclk(struct drm_device
> *dev, int cdclk)
>50)) {
> DRM_ERROR("timed out waiting for CDclk change\n");
> }
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
>
> intel_update_cdclk(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index 249623d..adff84a 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -32,6 +32,7 @@
> #include "../../../platform/x86/intel_ips.h"
> #include
> #include
> +#include
>
> /**
> * DOC: RC6
> @@ -276,6 +277,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private
> *dev_priv, bool enable)
> u32 val;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DDR_SETUP2);
> if (enable)
> @@ -290,6 +292,7 @@ static void chv_set_memory_dvfs(struct drm_i915_private
> *dev_priv, bool enable)
> FORCE_DDR_FREQ_REQ_ACK) == 0, 3))
> DRM_ERROR("timed out waiting for Punit DDR DVFS request\n");
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -298,6 +301,7 @@ static void chv_set_memory_pm5(struct drm_i915_private
> *dev_priv, bool enable)
> u32 val;
>
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> if (enable)
> @@ -306,6 +310,7 @@ static void chv_set_memory_pm5(struct drm_i915_private
> *dev_priv, bool enable)
> val &= ~DSP_MAXFIFO_PM5_ENABLE;
> vlv_punit_write(dev_priv, PUNIT_REG_DSPFREQ, val);
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -4553,6 +4558,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
>
> if (IS_CHERRYVIEW(dev_priv)) {
> mutex_lock(&dev_priv->rps.hw_lock);
> + iosf_mbi_punit_acquire();
>
> val = vlv_punit_read(dev_priv, PUNIT_REG_DSPFREQ);
> if (val & DSP_MAXFIFO_PM5_ENABLE)
> @@ -4582,6 +4588,7 @@ void vlv_wm_get_hw_state(struct drm_device *dev)
> wm->level = VLV_WM_LEVEL_DDR_DVFS;
> }
>
> + iosf_mbi_punit_release();
> mutex_unlock(&dev_priv->rps.hw_lock);
> }
>
> @@ -4988,7 +4995,9 @@ static void valleyview_set_rps(struct drm_i915_private
> *dev_priv, u8 val)
> I915_WRITE(GEN6_PMINTRMSK, gen6_rps_pm_mask(dev_priv, val));
>
> if (val !=
Re: [PATCH 1/4] drm: qxl: Drop misleading comment
On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote:
> On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote:
> > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
> > output"). qxl_num_crtc defaults to 4 and is configurable as a module
> > parameter.
>
> Picked up patches 1-3 for drm-qemu branch.
>
> Patch 4 doesn't apply and seems to have a dependency on out-of-tree
> changes, git am fails to do a 3way merge due to missing commits (trying
> to apply to 4.10-rc5).
It needs the demidlayer that's already in drm-next ...
-Daniel
--
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 12/13] drm/i915: Listen for PMIC bus access notifications
On Mon, Jan 23, 2017 at 10:09:57PM +0100, Hans de Goede wrote:
> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
> the bus is accessed to avoid needing to do any forcewakes, which need
> PMIC bus access, while the PMIC bus is busy:
>
> This fixes errors like these showing up in dmesg, usually followed
> by a gfx or system freeze:
>
> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake
> ack request.
> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake
> ack request.
> i2c_designware 808622C1:06: punit semaphore timed out, resetting
> i2c_designware 808622C1:06: PUNIT SEM: 2
> i2c_designware 808622C1:06: couldn't acquire bus ownership
>
> Downside of this approach is that it causes wakeups whenever the PMIC
> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
> to go idle when we hit a race, as forcewakes may be done from interrupt
> handlers where we cannot sleep to wait for the i2c PMIC bus access to
> finish.
>
> Note that the notifications and thus the wakeups will only happen on
> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
> P-Unit and host PMIC access (i2c busses with a _SEM method in their
> APCI node), e.g. an axp288 PMIC.
>
> I plan to write some patches for drivers accessing the PMIC bus to
> limit their bus accesses to a bare minimum (e.g. cache registers, do not
> update battery level more often then 4 times a minute), to limit the
> amount of wakeups.
>
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede
> Tested-by: tagorereddy
> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_uncore.c | 35 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c717329..52f7dde 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -721,6 +721,7 @@ struct intel_uncore {
> const struct intel_forcewake_range *fw_domains_table;
> unsigned int fw_domains_table_entries;
>
> + struct notifier_block pmic_bus_access_nb;
> struct intel_uncore_funcs funcs;
>
> unsigned fifo_count;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 3767307..175fe02 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -25,6 +25,7 @@
> #include "intel_drv.h"
> #include "i915_vgpu.h"
>
> +#include
> #include
>
> #define FORCEWAKE_ACK_TIMEOUT_MS 50
> @@ -429,12 +430,16 @@ static void __intel_uncore_early_sanitize(struct
> drm_i915_private *dev_priv,
>
> void intel_uncore_suspend(struct drm_i915_private *dev_priv)
> {
> + iosf_mbi_unregister_pmic_bus_access_notifier(
> + &dev_priv->uncore.pmic_bus_access_nb);
> __intel_uncore_forcewake_reset(dev_priv, false);
> }
>
> void intel_uncore_resume(struct drm_i915_private *dev_priv)
> {
> __intel_uncore_early_sanitize(dev_priv, true);
> + iosf_mbi_register_pmic_bus_access_notifier(
> + &dev_priv->uncore.pmic_bus_access_nb);
> i915_check_and_clear_faults(dev_priv);
> }
The early/normal/late suspend/resume ordering starts to bother me a
little more now. I wonder if we're totally safe wrt. the suspend/resume
order of the devices now.
> @@ -1390,6 +1395,28 @@ static void intel_uncore_fw_domains_init(struct
> drm_i915_private *dev_priv)
> dev_priv->uncore.fw_domains_table_entries = ARRAY_SIZE((d)); \
> }
>
> +static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
> + unsigned long action, void *data)
> +{
> + struct drm_i915_private *dev_priv = container_of(nb,
> + struct drm_i915_private, uncore.pmic_bus_access_nb);
> +
> + switch (action) {
> + case MBI_PMIC_BUS_ACCESS_BEGIN:
> + /*
> + * forcewake all to make sure that we don't need to forcewake
> + * any power-planes while the pmic bus is busy.
> + */
> + intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
I must say I don't really like this stuff at all. But if it helps I gues
we should go for it. I'd like to see the comment elaborate a bit more on
why we think it's is needed.
> + break;
> + case MBI_PMIC_BUS_ACCESS_END:
> + intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
> + break;
> + }
> +
> + return NOTIFY_OK;
> +}
> +
> void intel_uncore_init(struct drm_i915_private *dev_priv)
> {
> i915_check_vgpu(dev_priv);
> @@ -1399,6 +1426,8 @@ void intel_uncore_init(struct drm_i915_private
> *dev_priv)
> __intel_uncore_early_sanitize(dev_priv, false);
>
> dev_priv->uncore.unclaimed_mmio_check = 1;
> + dev_priv->uncore.pmic_bus_access_nb.n
Re: [PATCH v1] drm/prime: Clarify DMA-BUF/GEM Object lifetime
On Fri, Jan 27, 2017 at 09:04:25AM +0200, Oleksandr Andrushchenko wrote: > From: Oleksandr Andrushchenko > > From the description of the "DMA-BUF/GEM Object references > and lifetime overview" it is not clear when exactly > dma_buf gets destroyed and memory freed: only driver > .release function mentioned which makes confusion on the > real buffer's lifetime. > > Add more description so all the paths are covered. > > Cc: Rob Clark > Cc: Dave Airlie > Cc: Daniel Vetter > Signed-off-by: Oleksandr Andrushchenko > --- > drivers/gpu/drm/drm_prime.c | 16 ++-- > 1 file changed, 14 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c > index 8d77b2462594..893a1a6311f0 100644 > --- a/drivers/gpu/drm/drm_prime.c > +++ b/drivers/gpu/drm/drm_prime.c > @@ -40,8 +40,11 @@ > * On the export the dma_buf holds a reference to the exporting GEM > * object. It takes this reference in handle_to_fd_ioctl, when it > * first calls .prime_export and stores the exporting GEM object in > - * the dma_buf priv. This reference is released when the dma_buf > - * object goes away in the driver .release function. > + * the dma_buf priv. This refernce needs to be released when the s/refernce/reference/ > + * final reference to the &dma_buf itself is dropped and its > + * &dma_buf_ops.release function is called. For GEM-based drivers, > + * the dma_buf should be exported using drm_gem_dmabuf_export() and > + * then released by drm_gem_dmabuf_release(). > * > * On the import the importing GEM object holds a reference to the > * dma_buf (which in turn holds a ref to the exporting GEM object). > @@ -51,6 +54,15 @@ > * when the imported object is destroyed, we remove the attachment > * and drop the reference to the dma_buf. > * > + * When all the references to the dma_buf are dropped, e.g. when > + * userspace closes both handles to the imported (fd_to_handle_ioctl) > + * and exported (handle_to_fd_ioctl) dma_buf and closes the corresponding Usualla we call ioctls with uppercase, e.g. HANDLE_TO_FD IOCTL. > + * file descriptor (handle_to_fd), then dma_buf gets destroyed. > + * This can also happen as a part of the clean up procedure in the > + * driver .release function if userspace fails to properly clean up. Extended the references here to full file_ops one. Since this is all tiny, I've done this while applying, thanks a lot for your patch. -Daniel > + * Note that both the kernel and userspace (by keeeping the PRIME file > + * descriptors open) can hold references onto a &dma_buf. > + * > * Thus the chain of references always flows in one direction > * (avoiding loops): importing_gem -> dmabuf -> exporting_gem > * > -- > 2.7.4 > -- 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: make fbdev/fbcon switchable per driver?
On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote:
> Hi folks,
>
> Problem at hand: A virtual machine, equipped with two display devices,
> one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
>
> There is no easy way for the user to configure which of the two display
> devices fbcon should run on. i915 happens to win over bochs-drm or qxl,
> so you can't use the emulated gfx device as text console.
>
> One way out would be to add a module option to each driver, to turn off
> fbdev emulation. Attached patch does that for i915.
>
> Comments? Better ideas?
fbcon can be switched between different fbdev afaik, but don't ask me how.
I'd say if you want to keep fbcon (and not switch to something like
kmscon), then that's where this logic should be. Might even exist already.
Having a per-driver knob won't work, since then the next person complains
about his multi-amd setup using the wrong gpu :-)
-Daniel
>
> cheers,
> Gerd
>
> From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
> From: Gerd Hoffmann
> Date: Fri, 27 Jan 2017 08:05:40 +0100
> Subject: [PATCH] drm i915: add fbdev option
>
> Signed-off-by: Gerd Hoffmann
> ---
> drivers/gpu/drm/i915/intel_fbdev.c | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 3e3632c..cc0ba3e 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -45,6 +45,11 @@
> #include
> #include "i915_drv.h"
>
> +static bool enable_fbdev = true;
> +module_param_named(fbdev, enable_fbdev, bool, 0600);
> +MODULE_PARM_DESC(fbdev,
> + "Enable legacy fbdev emulation [default=true]");
> +
> static int intel_fbdev_set_par(struct fb_info *info)
> {
> struct drm_fb_helper *fb_helper = info->par;
> @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
> struct drm_i915_private *dev_priv = to_i915(dev);
> int ret;
>
> + if (!enable_fbdev)
> + return 0;
> +
> if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
> return -ENODEV;
>
> @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device
> *dev)
> {
> struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
>
> + if (!ifbdev)
> + return;
> ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
> }
>
> --
> 1.8.3.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] drm/atomic: clear out fence when duplicating state
On Fri, Jan 27, 2017 at 11:33:04AM +0100, Lucas Stach wrote: > The fence needs to be cleared out, otherwise the following commit > might wait on a stale fence from the previous commit. This was fixed > as a side effect of 9626014258a5 (drm/fence: add in-fences support) > in kernel 4.10. > > As this commit introduces new functionality and as such can not be > applied to stable, this patch is the minimal fix for the kernel 4.9 > stable series. > > Signed-off-by: Lucas Stach Reviewed-by: Daniel Vetter Stable teams, please apply. Thanks, Daniel > --- > drivers/gpu/drm/drm_atomic_helper.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c > b/drivers/gpu/drm/drm_atomic_helper.c > index 21f992605541..8ace20a5bf64 100644 > --- a/drivers/gpu/drm/drm_atomic_helper.c > +++ b/drivers/gpu/drm/drm_atomic_helper.c > @@ -3113,6 +3113,8 @@ void __drm_atomic_helper_plane_duplicate_state(struct > drm_plane *plane, > > if (state->fb) > drm_framebuffer_reference(state->fb); > + > + state->fence = NULL; > } > EXPORT_SYMBOL(__drm_atomic_helper_plane_duplicate_state); > > -- > 2.11.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: [Intel-gfx] [PATCH] drm/i915: fix use-after-free in page_flip_completed()
On Thu, Jan 26, 2017 at 02:46:20PM +, Chris Wilson wrote:
> On Thu, Jan 26, 2017 at 05:32:11PM +0300, Andrey Ryabinin wrote:
> > page_flip_completed() dereferences 'work' variable after executing
> > queue_work(). This is not safe as the 'work' item might be already freed
> > by queued work:
> >
> > BUG: KASAN: use-after-free in page_flip_completed+0x3ff/0x490 at addr
> > 8803dc010f90
> > Call Trace:
> > __asan_report_load8_noabort+0x59/0x80
> > page_flip_completed+0x3ff/0x490
> > intel_finish_page_flip_mmio+0xe3/0x130
> > intel_pipe_handle_vblank+0x2d/0x40
> > gen8_irq_handler+0x4a7/0xed0
> > __handle_irq_event_percpu+0xf6/0x860
> > handle_irq_event_percpu+0x6b/0x160
> > handle_irq_event+0xc7/0x1b0
> > handle_edge_irq+0x1f4/0xa50
> > handle_irq+0x41/0x70
> > do_IRQ+0x9a/0x200
> > common_interrupt+0x89/0x89
> >
> > Freed:
> > kfree+0x113/0x4d0
> > intel_unpin_work_fn+0x29a/0x3b0
> > process_one_work+0x79e/0x1b70
> > worker_thread+0x611/0x1460
> > kthread+0x241/0x3a0
> > ret_from_fork+0x27/0x40
> >
> > Move queue_work() after trace_i915_flip_complete() to fix this.
> >
> > Fixes: e5510fac98a7 ("drm/i915: add tracepoints for flip requests &
> > completions")
> > Signed-off-by: Andrey Ryabinin
>
> That's old, and indeed does seem to be present from that commit and not
> exposed by something later.
>
> Cc: # v2.6.36+
> Reviewed-by: Chris Wilson
Applied, thanks for patch&review.
-Daniel
--
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/i915: minor corner case fix to respect user's backlight setting
On Fri, 27 Jan 2017, Harry Pan wrote:
> When enabling panel backlight, if the current backlight level
> setting matches the panel's minimal, it would apply default policy to
> override the current level by the panel's maximum until next request
> to update brightness, this leads unexpected user confusion with
> temporary full power backlight.
>
> This odd could be reproduced as commands like these:
> $ xbacklight -set 0
> $ sudo sh -c 'echo mem > /sys/power/state'
> (resume)
>
> To fix this, slightly tinker the backlight level comparison from
> 'less-and-equal-to' to 'less-than'.
>
> Before: (dmesg | grep backlight # with drm.debug=0xe)
> [ 82.249265] [drm:intel_backlight_device_update_status [i915]] updating
> intel_backlight, brightness=0/5273
> [ 82.249282] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
> [ 82.249306] [drm:intel_edp_backlight_power [i915]] panel power control
> backlight disable
> [ 92.066041] [drm:intel_edp_backlight_off [i915]]
> [ 92.270489] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 0
> [ 94.080434] [drm:intel_edp_backlight_on.part.25 [i915]]
> [ 94.080476] [drm:intel_panel_enable_backlight [i915]] pipe A
> [ 94.080539] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 5273
>
> After:
> [ 72.874465] [drm:intel_backlight_device_update_status [i915]] updating
> intel_backlight, brightness=0/5273
> [ 72.874499] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
> [ 72.874540] [drm:intel_edp_backlight_power [i915]] panel power control
> backlight disable
> [ 86.807928] [drm:intel_edp_backlight_off [i915]]
> [ 87.013227] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 0
> [ 89.001829] [drm:intel_edp_backlight_on.part.25 [i915]]
> [ 89.001859] [drm:intel_panel_enable_backlight [i915]] pipe A
> [ 89.001926] [drm:intel_panel_actually_set_backlight [i915]] set backlight
> PWM = 207
>
> Fixes: 13f3fbe827d0 ("fix inconsistent brightness after resume")
That reference is not really true. We've had this policy of setting the
backlight to max at enable if it was previously zero for eons. Yes, it's
policy, not mechanism, but it's basically ABI.
For some reason the expectation is that the sequence:
1. set backlight to 0
2. dpms off
3. dpms on
does not lead to a black screen regardless of the user request to have 0
backlight. Your change breaks this.
> Signed-off-by: Harry Pan ---
>drivers/gpu/drm/i915/intel_panel.c | 2 +- 1 file changed, 1
>insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index 08ab6d7..e882139 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1104,7 +1104,7 @@ void intel_panel_enable_backlight(struct
> intel_connector *connector)
>
> WARN_ON(panel->backlight.max == 0);
>
> - if (panel->backlight.level <= panel->backlight.min) {
> + if (panel->backlight.level < panel->backlight.min) {
> panel->backlight.level = panel->backlight.max;
If we changed this to follow your logic, the sensible thing to do would
be to set the backlight to min, not max, in this case.
But the point is moot. I don't want to deal with the regressions that I
predict the change will inevitably cause.
BR,
Jani.
> if (panel->backlight.device)
> panel->backlight.device->props.brightness =
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup
On Fri, Jan 27, 2017 at 10:36:16AM +0100, Thierry Reding wrote: > On Fri, Jan 27, 2017 at 08:49:34AM +0100, Daniel Vetter wrote: > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > > > This patchset removes the need for drivers to clean up their debugfs > > > files on exit. It is done automatically in drm_debugfs_cleanup(). > > > This funtion is also called should the driver error out in it's > > > drm_driver.debugfs_init callback. > > > > > > Two drivers still use drm_debugfs_remove_files(): > > > - tegra in it's connectors, not sure if I can remove it. > > > > I read through them, and they're removed on the component device nodes > > stuff. That looks somewhat fishy from a lifetime point of view, and I > > think removing all that code would be better, too. > > What makes you think that's problematic from a lifetime point of view? > The component device is tied to the DRM device, so these callbacks are > called at the right time. debugfs is a userspace interface, which should disappear when drm_dev_unregister gets called. I'm not sure at all whether that lines up with the cleanup of all your component nodes, but otoh it's rather academic since you can't hotplug a tegra. > That said, I think it's safe to remove the other debugfs files from > Tegra. It might not be possible to remove the cleanup functions > altogether, though, because they have to do a special dance involving > kmemdup() drm_debugfs_create_files() and kfree() in order to support > debugfs files for multiple instances of subdevices. Hm, that entire "do debugfs on the minor" thing makes almost never sense. All the things we have left in modern drivers are either per-fd, or per-device. Nothing of interest is per-minor. Or do you mean something else? Either way would be nice if we can remove them too, so that drm_debugfs_remove_files could be unexported ... -Daniel -- 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/ttm: Make sure BOs being swapped out are cacheable
On Fri, Jan 27, 2017 at 09:22:47AM +0100, Christian König wrote: > Am 27.01.2017 um 08:30 schrieb Daniel Vetter: > > On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: > > > On 01/27/2017 03:29 AM, Michel Dänzer wrote: > > > > On 26/01/17 09:46 AM, Sinclair Yeh wrote: > > > > > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: > > > > > > Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: > > > > > > > On 01/25/2017 09:21 AM, Michel Dänzer wrote: > > > > > > > > From: Michel Dänzer > > > > > > > > > > > > > > > > The current caching state may not be tt_cached, even though the > > > > > > > > placement contains TTM_PL_FLAG_CACHED, because placement can > > > > > > > > contain > > > > > > > > multiple caching flags. Trying to swap out such a BO would trip > > > > > > > > up the > > > > > > > > > > > > > > > > BUG_ON(ttm->caching_state != tt_cached); > > > > > > > > > > > > > > > > in ttm_tt_swapout. > > > > > > > > > > > > > > > > Cc: sta...@vger.kernel.org > > > > > > > > Signed-off-by: Michel Dänzer > > > > > > > Reviewed-by: Thomas Hellstrom > > > > > > Reviewed-by: Christian König . > > > > > Reviewed-by: Sinclair Yeh > > > > Thanks for the reviews! Via which tree should we merge this? > > > > > > > > > > > I don't maintain a TTM tree any longer. Let's check with Daniel if he > > > can merge it through drm-misc. > > I'm trying very hard not to get volunteered for ttm maintainer :-) > > Yeah, ok I volunteer. Wanted to take that over for a while anyway. I guess you didn't use the dim magic to push it? The test integration tree isn't rebuild ... Quickstart for the tooling: https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html -Daniel -- 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/color: Include CTM equations in kerneldoc
On Fri, Jan 27, 2017 at 01:50:19PM +, Brian Starkey wrote:
> On Fri, Jan 27, 2017 at 03:27:09PM +0200, Ville Syrjälä wrote:
> >On Fri, Jan 27, 2017 at 10:47:48AM +, Brian Starkey wrote:
> >> Explicitly state the expected CTM equations in the kerneldoc for the CTM
> >> property.
> >>
> >> Cc: Ville Syrjälä
> >> Cc: Lionel Landwerlin
> >> Cc: Daniel Vetter
> >> Signed-off-by: Brian Starkey
> >> ---
> >>
> >> Hi,
> >>
> >> This captures the outcome of the discussion on #dri-devel yesterday
> >> (2017-01-26):
> >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
> >>
> >> I'm not sure about the stance on such explicit rst markup in kerneldoc,
> >> but without it the equations are pretty unreadable in the rendered
> >> output.
> >>
> >> Cheers,
> >> Brian
> >>
> >> drivers/gpu/drm/drm_color_mgmt.c | 10 ++
> >> 1 file changed, 10 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> >> b/drivers/gpu/drm/drm_color_mgmt.c
> >> index 789b4c65cd69..63f3a7404fa1 100644
> >> --- a/drivers/gpu/drm/drm_color_mgmt.c
> >> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> >> @@ -62,6 +62,16 @@
> >> *unit/pass-thru matrix should be used. This is generally the
> >> driver
> >> *boot-up state too.
> >> *
> >> + *Given an input vector ``in[3]`` and an output vector
> >> ``out[3]``, the
> >> + *transformation applied is:
> >> + *
> >> + *| ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2]
> >> * in[2];``
> >> + *| ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5]
> >> * in[2];``
> >> + *| ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8]
> >> * in[2];``
> >> + *
> >> + *| For RGB formats, the input vector is assumed to be ``{ R, G,
> >> B }``.
> >> + *| For YCbCr formats, the input vector is assumed to be ``{ Y,
> >> Cb, Cr }``.
> >
> >Talking about formats here could be a little confusing. One might think
> >this has something to do with the framebuffer pixel format, when in fact
> >it's only about the internal format used by the crtc.
>
> Ah right, yes I see.
>
> Actually, I *was* thinking about the framebuffer format here - but
> that is missing the context of us adding a CTM property for each plane
> (so that each plane can map the framebuffer format to the CRTC pipe's
> internal format).
>
> Our intention (for Mali-DP) is to add CTM on each plane to be used
> for framebuffer -> CRTC pipe conversion, and then use the CTM on the
> CRTC for CRTC pipe -> output conversion.
>
> Shall I just remove the two lines about pixel formats here, and then
> when we land per-plane CTM add some details about plane CTM matrices
> being before the CRTC CTM matrix?
We'll need to keep some note about the RGB order here. Userspace needs
to know that to actually use the matrix. Oh and I guess we should really
put this documentation into the uapi header.
>
> Thanks,
> -Brian
> >
> >And actually I don't think we can get away this easily for YCbCr since
> >there is no way to indicate to userspace whether the pipe is internally
> >RGB or YCbCr. Until we add a property to indicate RGB vs. YCbCr internal
> >crtc formt (which userspace could actually set if the hardware allows it)
> >we shouldn't even mention YCbCr. If there is hardware out there that
> >always uses YCbCr, then I think those folks need to come up with a
> >property to indicate that, or they'll just have to do the RGB->YCbCr
> >conversion in the driver when populating the matrix.
> >
> >> + *
> >> * “GAMMA_LUT”:
> >> *Blob property to set the gamma lookup table (LUT) mapping pixel
> >> data
> >> *after the transformation matrix to data sent to the connector.
> >> The
> >> --
> >> 1.7.9.5
> >
> >--
> >Ville Syrjälä
> >Intel OTC
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 00/19] drm: debugfs: Remove all files automatically on cleanup
Den 27.01.2017 08.49, skrev Daniel Vetter: On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: This patchset removes the need for drivers to clean up their debugfs files on exit. It is done automatically in drm_debugfs_cleanup(). This funtion is also called should the driver error out in it's drm_driver.debugfs_init callback. Two drivers still use drm_debugfs_remove_files(): - tegra in it's connectors, not sure if I can remove it. I read through them, and they're removed on the component device nodes stuff. That looks somewhat fishy from a lifetime point of view, and I think removing all that code would be better, too. - qxl because it's debugfs files list is part of struct qxl_device which is freed on unload before drm_minor_unregister() is called cleaning debugfs. In -next qxl is already demidlayered and there's no longer an unload hook. This should be all safe ... why is it not? My bad, I fetched linux-next a few days ago and figured it was up-to-date-enough. Duh, I should have known better after following drm for a year now, it is constantly changing, no pauses. Can you please ping me when you have pulled driver patches and I'll respin msm, tegra and qxl (and others if necessary), and remove the hook. It's much easier for me to do a small patchset, it's really a strain to get everything lined up correctly with big changes. I didn't have that patch juggling class when in school, so I'm late to the game :-) Noralf. Daniel, I was unable to remove the drm_driver.debugfs_cleanup hook completely, since drm/msm uses it to free memory. Maybe it can be freed elsewhere. Well this is definitely a massive step into a good direction, great work. For msm I think we can just move the two calls left in msm_debugfs_cleanup in msm_drm_uninit, right after the call to drm_dev_unregister. -Daniel Note: The driver patches are only compile tested. Noralf. Noralf Trønnes (19): drm: debugfs: Remove all files automatically on cleanup drm: drm_minor_register(): Clean up debugfs on failure drm/atomic: Remove drm_atomic_debugfs_cleanup() drm/amd/amdgpu: Remove drm_debugfs_remove_files() call drm/armada: Remove armada_drm_debugfs_cleanup() drm/etnaviv: allow build with COMPILE_TEST drm/etnaviv: Remove etnaviv_debugfs_cleanup() drm/hdlcd: Remove hdlcd_debugfs_cleanup() drm/msm: Remove drm_debugfs_remove_files() calls drm/nouveau: Remove nouveau_drm_debugfs_cleanup() drm/omap: Remove omap_debugfs_cleanup() drm/radeon: Remove drm_debugfs_remove_files() call drm/sti: Remove drm_debugfs_remove_files() calls drm/tegra: Remove tegra_debugfs_cleanup() drm/tilcdc: Remove tilcdc_debugfs_cleanup() drm/vc4: Remove vc4_debugfs_cleanup() drm/virtio: Remove virtio_gpu_debugfs_takedown() drm/qxl: Remove qxl_debugfs_takedown() drm/i915: Remove i915_debugfs_unregister() drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 -- drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 - drivers/gpu/drm/arm/hdlcd_drv.c| 7 --- drivers/gpu/drm/armada/armada_debugfs.c| 65 +++- drivers/gpu/drm/armada/armada_drm.h| 1 - drivers/gpu/drm/armada/armada_drv.c| 3 - drivers/gpu/drm/drm_atomic.c | 7 --- drivers/gpu/drm/drm_crtc_internal.h| 1 - drivers/gpu/drm/drm_debugfs.c | 29 + drivers/gpu/drm/drm_drv.c | 2 +- drivers/gpu/drm/etnaviv/Kconfig| 2 +- drivers/gpu/drm/etnaviv/etnaviv_drv.c | 7 --- drivers/gpu/drm/i915/i915_debugfs.c| 97 -- drivers/gpu/drm/i915/i915_drv.c| 1 - drivers/gpu/drm/i915/i915_drv.h| 2 - drivers/gpu/drm/i915/intel_drv.h | 1 - drivers/gpu/drm/i915/intel_pipe_crc.c | 68 - drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 7 --- drivers/gpu/drm/msm/msm_debugfs.c | 2 - drivers/gpu/drm/msm/msm_perf.c | 29 + drivers/gpu/drm/msm/msm_rd.c | 31 +- drivers/gpu/drm/nouveau/nouveau_debugfs.c | 62 --- drivers/gpu/drm/nouveau/nouveau_debugfs.h | 6 -- drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - drivers/gpu/drm/omapdrm/omap_debugfs.c | 9 --- drivers/gpu/drm/omapdrm/omap_drv.c | 1 - drivers/gpu/drm/omapdrm/omap_drv.h | 1 - drivers/gpu/drm/qxl/qxl_debugfs.c | 9 --- drivers/gpu/drm/qxl/qxl_drv.c | 1 - drivers/gpu/drm/qxl/qxl_drv.h | 1 - drivers/gpu/drm/radeon/radeon_device.c | 16 - drivers/gpu/drm/sti/sti_drv.c | 48 ++- drivers/gpu/drm/sti/sti_dvo.c | 10 --- drivers/gpu/drm/sti/sti_hda.c | 11 drivers/gpu/drm/sti/sti_hdmi.c | 11 drivers/gpu/drm/sti/sti_tvout.c| 8 --- drivers/gpu/drm/tegra/drm.c
Re: [PATCH 06/19] drm/etnaviv: allow build with COMPILE_TEST
On Fri, Jan 27, 2017 at 10:57:30AM +0100, Lucas Stach wrote: > Am Donnerstag, den 26.01.2017, 23:56 +0100 schrieb Noralf Trønnes: > > Make it possible to compile test the driver on other platforms. > > > > Cc: l.st...@pengutronix.de > > Cc: linux+etna...@armlinux.org.uk > > Cc: christian.gmei...@gmail.com > > Signed-off-by: Noralf Trønnes > > I'm not sure we are pulling in all dependencies on other platforms, but > as I have no good way to check right now, lets go with the patch and see > if anything blows up: There's no other way to validate KConfig patches than to apply them and let 0day beat for a few weeks through all the combinations once it's in linux-next. 0day doesn't do randomized configs on stuff that's not in linux-next unfortunately (probably too much of a cpu waste). > Acked-by: Lucas Stach Thanks, applied. -Daniel > > > --- > > 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 656c061..cc1731c 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 > > + depends on ARCH_MXC || ARCH_DOVE || (ARM && COMPILE_TEST) > > depends on MMU > > select SHMEM > > select TMPFS > > > ___ > 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: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > When writing some testcases for nonblocking modesets. I found out that the > > infinite wait on the old fb was causing issues. > > The crux of the issue here is the locked wait for old dependencies and > the inability to inject the intel_prepare_reset disabling of all planes. > There are a couple of locked waits on struct_mutex within the modeset > locks for intel_overlay and if we happen to be using the display plane > for the first time. > > The first I suggested solving using fences to track dependencies and > keep the order between atomic states. Cancelling the outstanding > modesets, replacing with a disable and then on restore jumping to the > final state look doable. It also requires avoiding the struct_mutex for > disabling, which is quite easy. To avoid the wait under struct_mutex, > we've talked about switching to mmio, but for starters we could move the > wait from inside intel_overlay into the fence for the atomic operation. > (But's that a little more surgery than we would like for intel_overlay I > guess - dig out Ville's patches for overlay planes?) And to prevent the > wait under struct_mutex for pin_to_display_plane, my plane is to move > that to an async fenced operation that is then naturally waited upon by > the atomic modeset. A bit more a hack, but a different idea, and I think hack for gen234.0 is ok: We complete all the requests before we start the hw reset with fence.error = -EIO. But we do this only when we need to get at the display locks. A slightly more elegant solution would be to trylock modeset locks, and if one of them fails (and only then) complete all requests with -EIO to get the concurrent modeset to proceed before we reset the hardware. That's essentially the logic we had before all the reworks, and it worked. But I didn't look at how scary that all would be to make it work again ... -Daniel -- 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 00/19] drm: debugfs: Remove all files automatically on cleanup
On Fri, Jan 27, 2017 at 03:23:43PM +0100, Noralf Trønnes wrote: > > Den 27.01.2017 08.49, skrev Daniel Vetter: > > On Thu, Jan 26, 2017 at 11:56:02PM +0100, Noralf Trønnes wrote: > > > This patchset removes the need for drivers to clean up their debugfs > > > files on exit. It is done automatically in drm_debugfs_cleanup(). > > > This funtion is also called should the driver error out in it's > > > drm_driver.debugfs_init callback. > > > > > > Two drivers still use drm_debugfs_remove_files(): > > > - tegra in it's connectors, not sure if I can remove it. > > I read through them, and they're removed on the component device nodes > > stuff. That looks somewhat fishy from a lifetime point of view, and I > > think removing all that code would be better, too. > > > > > - qxl because it's debugfs files list is part of struct qxl_device which > > >is freed on unload before drm_minor_unregister() is called cleaning > > > debugfs. > > In -next qxl is already demidlayered and there's no longer an unload hook. > > This should be all safe ... why is it not? > > My bad, I fetched linux-next a few days ago and figured it was > up-to-date-enough. Duh, I should have known better after following drm for > a year now, it is constantly changing, no pauses. > > Can you please ping me when you have pulled driver patches and I'll respin > msm, tegra and qxl (and others if necessary), and remove the hook. > It's much easier for me to do a small patchset, it's really a strain to get > everything lined up correctly with big changes. I didn't have that patch > juggling class when in school, so I'm late to the game :-) You're doing great with the patch juggling :-) I've just made a pass through the series and merge what's already reviewed/acked. Thanks, Daniel > > > Noralf. > > > > Daniel, > > > I was unable to remove the drm_driver.debugfs_cleanup hook completely, > > > since drm/msm uses it to free memory. Maybe it can be freed elsewhere. > > Well this is definitely a massive step into a good direction, great work. > > For msm I think we can just move the two calls left in msm_debugfs_cleanup > > in msm_drm_uninit, right after the call to drm_dev_unregister. > > -Daniel > > > > > > > > Note: > > > The driver patches are only compile tested. > > > > > > > > > Noralf. > > > > > > > > > Noralf Trønnes (19): > > >drm: debugfs: Remove all files automatically on cleanup > > >drm: drm_minor_register(): Clean up debugfs on failure > > >drm/atomic: Remove drm_atomic_debugfs_cleanup() > > >drm/amd/amdgpu: Remove drm_debugfs_remove_files() call > > >drm/armada: Remove armada_drm_debugfs_cleanup() > > >drm/etnaviv: allow build with COMPILE_TEST > > >drm/etnaviv: Remove etnaviv_debugfs_cleanup() > > >drm/hdlcd: Remove hdlcd_debugfs_cleanup() > > >drm/msm: Remove drm_debugfs_remove_files() calls > > >drm/nouveau: Remove nouveau_drm_debugfs_cleanup() > > >drm/omap: Remove omap_debugfs_cleanup() > > >drm/radeon: Remove drm_debugfs_remove_files() call > > >drm/sti: Remove drm_debugfs_remove_files() calls > > >drm/tegra: Remove tegra_debugfs_cleanup() > > >drm/tilcdc: Remove tilcdc_debugfs_cleanup() > > >drm/vc4: Remove vc4_debugfs_cleanup() > > >drm/virtio: Remove virtio_gpu_debugfs_takedown() > > >drm/qxl: Remove qxl_debugfs_takedown() > > >drm/i915: Remove i915_debugfs_unregister() > > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu.h| 1 - > > > drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 20 -- > > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c| 1 - > > > drivers/gpu/drm/arm/hdlcd_drv.c| 7 --- > > > drivers/gpu/drm/armada/armada_debugfs.c| 65 +++- > > > drivers/gpu/drm/armada/armada_drm.h| 1 - > > > drivers/gpu/drm/armada/armada_drv.c| 3 - > > > drivers/gpu/drm/drm_atomic.c | 7 --- > > > drivers/gpu/drm/drm_crtc_internal.h| 1 - > > > drivers/gpu/drm/drm_debugfs.c | 29 + > > > drivers/gpu/drm/drm_drv.c | 2 +- > > > drivers/gpu/drm/etnaviv/Kconfig| 2 +- > > > drivers/gpu/drm/etnaviv/etnaviv_drv.c | 7 --- > > > drivers/gpu/drm/i915/i915_debugfs.c| 97 > > > -- > > > drivers/gpu/drm/i915/i915_drv.c| 1 - > > > drivers/gpu/drm/i915/i915_drv.h| 2 - > > > drivers/gpu/drm/i915/intel_drv.h | 1 - > > > drivers/gpu/drm/i915/intel_pipe_crc.c | 68 - > > > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c| 7 --- > > > drivers/gpu/drm/msm/msm_debugfs.c | 2 - > > > drivers/gpu/drm/msm/msm_perf.c | 29 + > > > drivers/gpu/drm/msm/msm_rd.c | 31 +- > > > drivers/gpu/drm/nouveau/nouveau_debugfs.c | 62 --- > > > drivers/gpu/drm/nouveau/nouveau_debugfs.h | 6 -- > > > drivers/gpu/drm/nouveau/nouveau_drm.c | 1 - > > >
Re: [PATCH] drm/color: Include CTM equations in kerneldoc
On Fri, Jan 27, 2017 at 04:13:42PM +0200, Ville Syrjälä wrote:
> On Fri, Jan 27, 2017 at 01:50:19PM +, Brian Starkey wrote:
> > On Fri, Jan 27, 2017 at 03:27:09PM +0200, Ville Syrjälä wrote:
> > >On Fri, Jan 27, 2017 at 10:47:48AM +, Brian Starkey wrote:
> > >> Explicitly state the expected CTM equations in the kerneldoc for the CTM
> > >> property.
> > >>
> > >> Cc: Ville Syrjälä
> > >> Cc: Lionel Landwerlin
> > >> Cc: Daniel Vetter
> > >> Signed-off-by: Brian Starkey
> > >> ---
> > >>
> > >> Hi,
> > >>
> > >> This captures the outcome of the discussion on #dri-devel yesterday
> > >> (2017-01-26):
> > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
> > >>
> > >> I'm not sure about the stance on such explicit rst markup in kerneldoc,
> > >> but without it the equations are pretty unreadable in the rendered
> > >> output.
> > >>
> > >> Cheers,
> > >> Brian
> > >>
> > >> drivers/gpu/drm/drm_color_mgmt.c | 10 ++
> > >> 1 file changed, 10 insertions(+)
> > >>
> > >> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > >> b/drivers/gpu/drm/drm_color_mgmt.c
> > >> index 789b4c65cd69..63f3a7404fa1 100644
> > >> --- a/drivers/gpu/drm/drm_color_mgmt.c
> > >> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > >> @@ -62,6 +62,16 @@
> > >> * unit/pass-thru matrix should be used. This is generally the
> > >> driver
> > >> * boot-up state too.
> > >> *
> > >> + * Given an input vector ``in[3]`` and an output vector
> > >> ``out[3]``, the
> > >> + * transformation applied is:
> > >> + *
> > >> + * | ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2]
> > >> * in[2];``
> > >> + * | ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5]
> > >> * in[2];``
> > >> + * | ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8]
> > >> * in[2];``
> > >> + *
> > >> + * | For RGB formats, the input vector is assumed to be ``{ R, G,
> > >> B }``.
> > >> + * | For YCbCr formats, the input vector is assumed to be ``{ Y,
> > >> Cb, Cr }``.
> > >
> > >Talking about formats here could be a little confusing. One might think
> > >this has something to do with the framebuffer pixel format, when in fact
> > >it's only about the internal format used by the crtc.
> >
> > Ah right, yes I see.
> >
> > Actually, I *was* thinking about the framebuffer format here - but
> > that is missing the context of us adding a CTM property for each plane
> > (so that each plane can map the framebuffer format to the CRTC pipe's
> > internal format).
> >
> > Our intention (for Mali-DP) is to add CTM on each plane to be used
> > for framebuffer -> CRTC pipe conversion, and then use the CTM on the
> > CRTC for CRTC pipe -> output conversion.
> >
> > Shall I just remove the two lines about pixel formats here, and then
> > when we land per-plane CTM add some details about plane CTM matrices
> > being before the CRTC CTM matrix?
>
> We'll need to keep some note about the RGB order here. Userspace needs
> to know that to actually use the matrix. Oh and I guess we should really
> put this documentation into the uapi header.
Atm properties are documented in kernel-doc since they don't exist at all
in the uapi. Well this here is somewhat an exception, since there's
structs in uapi. But since nothing else in uapi thus far is reasonably
documented I still think we should keep it in the kernel-doc for now. At
least until someone starts taggling uapi docs properly ...
-Daniel
--
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: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > When writing some testcases for nonblocking modesets. I found out that the > > > infinite wait on the old fb was causing issues. > > > > The crux of the issue here is the locked wait for old dependencies and > > the inability to inject the intel_prepare_reset disabling of all planes. > > There are a couple of locked waits on struct_mutex within the modeset > > locks for intel_overlay and if we happen to be using the display plane > > for the first time. > > > > The first I suggested solving using fences to track dependencies and > > keep the order between atomic states. Cancelling the outstanding > > modesets, replacing with a disable and then on restore jumping to the > > final state look doable. It also requires avoiding the struct_mutex for > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > we've talked about switching to mmio, but for starters we could move the > > wait from inside intel_overlay into the fence for the atomic operation. > > (But's that a little more surgery than we would like for intel_overlay I > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > that to an async fenced operation that is then naturally waited upon by > > the atomic modeset. > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > ok: > > We complete all the requests before we start the hw reset with fence.error > = -EIO. But we do this only when we need to get at the display locks. A > slightly more elegant solution would be to trylock modeset locks, and if > one of them fails (and only then) complete all requests with -EIO to get > the concurrent modeset to proceed before we reset the hardware. That's > essentially the logic we had before all the reworks, and it worked. But I > didn't look at how scary that all would be to make it work again ... The modeset lock may not just be waiting on our requests (even on pnv we can expect that there are already users celebrating that pnv+nouveau finally works ;) and that the display is not the only user/observer of those requests. Using the requests to break the modeset lock just feels like the wrong approach. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/color: un-inline drm_color_lut_extract()
On Fri, 27 Jan 2017, Jani Nikula wrote:
> On Fri, 27 Jan 2017, Lionel Landwerlin wrote:
>> Hi Jani,
>>
>> Looks good to me :
>>
>> Reviewed-by: Lionel Landwerlin
>
> Thanks for the reviews, pushed... to drm-intel-next-queued instead of
> drm-misc-next. /o\
>
> Dave, Daniel, please advise, shall I revert or shall we let this flow in
> via drm-intel?
>
> Sorry for the mess.
Reverted, there was a conflict in the docs updates as well so this is
easier. I'll post a rebase version of the patch.
BR,
Jani.
>
> BR,
> Jani.
>
>
>
>>
>> On 23/01/17 09:42, Jani Nikula wrote:
>>> The function is not that big, but it's also not used for anything
>>> performance critical. Make it a normal function.
>>>
>>> As a side effect, this apparently makes sparse smarter about what it's
>>> doing, and gets rid of the warning:
>>>
>>> ./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295)
>>> for type unsigned long
>>> ./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
>>> constant value (8000 becomes 0)
>>>
>>> Cc: Lionel Landwerlin
>>> Signed-off-by: Jani Nikula
>>> ---
>>> drivers/gpu/drm/drm_color_mgmt.c | 24
>>> include/drm/drm_color_mgmt.h | 27 ++-
>>> 2 files changed, 26 insertions(+), 25 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
>>> b/drivers/gpu/drm/drm_color_mgmt.c
>>> index 789b4c65cd69..5618f60c7690 100644
>>> --- a/drivers/gpu/drm/drm_color_mgmt.c
>>> +++ b/drivers/gpu/drm/drm_color_mgmt.c
>>> @@ -88,6 +88,30 @@
>>>*/
>>>
>>> /**
>>> + * drm_color_lut_extract - clamp&round LUT entries
>>> + * @user_input: input value
>>> + * @bit_precision: number of bits the hw LUT supports
>>> + *
>>> + * Extract a degamma/gamma LUT value provided by user (in the form of
>>> + * &drm_color_lut entries) and round it to the precision supported by the
>>> + * hardware.
>>> + */
>>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
>>> +{
>>> + uint32_t val = user_input;
>>> + uint32_t max = 0x >> (16 - bit_precision);
>>> +
>>> + /* Round only if we're not using full precision. */
>>> + if (bit_precision < 16) {
>>> + val += 1UL << (16 - bit_precision - 1);
>>> + val >>= 16 - bit_precision;
>>> + }
>>> +
>>> + return clamp_val(val, 0, max);
>>> +}
>>> +EXPORT_SYMBOL(drm_color_lut_extract);
>>> +
>>> +/**
>>>* drm_crtc_enable_color_mgmt - enable color management properties
>>>* @crtc: DRM CRTC
>>>* @degamma_lut_size: the size of the degamma lut (before CSC)
>>> diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
>>> index c767238ac9d5..bce4a532836d 100644
>>> --- a/include/drm/drm_color_mgmt.h
>>> +++ b/include/drm/drm_color_mgmt.h
>>> @@ -25,6 +25,8 @@
>>>
>>> #include
>>>
>>> +uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t
>>> bit_precision);
>>> +
>>> void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>> uint degamma_lut_size,
>>> bool has_ctm,
>>> @@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
>>> int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
>>> int gamma_size);
>>>
>>> -/**
>>> - * drm_color_lut_extract - clamp&round LUT entries
>>> - * @user_input: input value
>>> - * @bit_precision: number of bits the hw LUT supports
>>> - *
>>> - * Extract a degamma/gamma LUT value provided by user (in the form of
>>> - * &drm_color_lut entries) and round it to the precision supported by the
>>> - * hardware.
>>> - */
>>> -static inline uint32_t drm_color_lut_extract(uint32_t user_input,
>>> -uint32_t bit_precision)
>>> -{
>>> - uint32_t val = user_input;
>>> - uint32_t max = 0x >> (16 - bit_precision);
>>> -
>>> - /* Round only if we're not using full precision. */
>>> - if (bit_precision < 16) {
>>> - val += 1UL << (16 - bit_precision - 1);
>>> - val >>= 16 - bit_precision;
>>> - }
>>> -
>>> - return clamp_val(val, 0, max);
>>> -}
>>> -
>>> -
>>> #endif
>>
>>
--
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/color: Include CTM equations in kerneldoc
On Fri, Jan 27, 2017 at 03:31:06PM +0100, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 04:13:42PM +0200, Ville Syrjälä wrote:
> > On Fri, Jan 27, 2017 at 01:50:19PM +, Brian Starkey wrote:
> > > On Fri, Jan 27, 2017 at 03:27:09PM +0200, Ville Syrjälä wrote:
> > > >On Fri, Jan 27, 2017 at 10:47:48AM +, Brian Starkey wrote:
> > > >> Explicitly state the expected CTM equations in the kerneldoc for the
> > > >> CTM
> > > >> property.
> > > >>
> > > >> Cc: Ville Syrjälä
> > > >> Cc: Lionel Landwerlin
> > > >> Cc: Daniel Vetter
> > > >> Signed-off-by: Brian Starkey
> > > >> ---
> > > >>
> > > >> Hi,
> > > >>
> > > >> This captures the outcome of the discussion on #dri-devel yesterday
> > > >> (2017-01-26):
> > > >> https://people.freedesktop.org/~cbrill/dri-log/?channel=dri-devel&date=2017-01-26
> > > >>
> > > >> I'm not sure about the stance on such explicit rst markup in kerneldoc,
> > > >> but without it the equations are pretty unreadable in the rendered
> > > >> output.
> > > >>
> > > >> Cheers,
> > > >> Brian
> > > >>
> > > >> drivers/gpu/drm/drm_color_mgmt.c | 10 ++
> > > >> 1 file changed, 10 insertions(+)
> > > >>
> > > >> diff --git a/drivers/gpu/drm/drm_color_mgmt.c
> > > >> b/drivers/gpu/drm/drm_color_mgmt.c
> > > >> index 789b4c65cd69..63f3a7404fa1 100644
> > > >> --- a/drivers/gpu/drm/drm_color_mgmt.c
> > > >> +++ b/drivers/gpu/drm/drm_color_mgmt.c
> > > >> @@ -62,6 +62,16 @@
> > > >> *unit/pass-thru matrix should be used. This is generally the
> > > >> driver
> > > >> *boot-up state too.
> > > >> *
> > > >> + *Given an input vector ``in[3]`` and an output vector
> > > >> ``out[3]``, the
> > > >> + *transformation applied is:
> > > >> + *
> > > >> + *| ``out[0] = matrix[0] * in[0] + matrix[1] * in[1] + matrix[2]
> > > >> * in[2];``
> > > >> + *| ``out[1] = matrix[3] * in[0] + matrix[4] * in[1] + matrix[5]
> > > >> * in[2];``
> > > >> + *| ``out[2] = matrix[6] * in[0] + matrix[7] * in[1] + matrix[8]
> > > >> * in[2];``
> > > >> + *
> > > >> + *| For RGB formats, the input vector is assumed to be ``{ R, G,
> > > >> B }``.
> > > >> + *| For YCbCr formats, the input vector is assumed to be ``{ Y,
> > > >> Cb, Cr }``.
> > > >
> > > >Talking about formats here could be a little confusing. One might think
> > > >this has something to do with the framebuffer pixel format, when in fact
> > > >it's only about the internal format used by the crtc.
> > >
> > > Ah right, yes I see.
> > >
> > > Actually, I *was* thinking about the framebuffer format here - but
> > > that is missing the context of us adding a CTM property for each plane
> > > (so that each plane can map the framebuffer format to the CRTC pipe's
> > > internal format).
> > >
> > > Our intention (for Mali-DP) is to add CTM on each plane to be used
> > > for framebuffer -> CRTC pipe conversion, and then use the CTM on the
> > > CRTC for CRTC pipe -> output conversion.
> > >
> > > Shall I just remove the two lines about pixel formats here, and then
> > > when we land per-plane CTM add some details about plane CTM matrices
> > > being before the CRTC CTM matrix?
> >
> > We'll need to keep some note about the RGB order here. Userspace needs
> > to know that to actually use the matrix. Oh and I guess we should really
> > put this documentation into the uapi header.
>
> Atm properties are documented in kernel-doc since they don't exist at all
> in the uapi. Well this here is somewhat an exception, since there's
> structs in uapi. But since nothing else in uapi thus far is reasonably
> documented I still think we should keep it in the kernel-doc for now. At
> least until someone starts taggling uapi docs properly ...
Ah. Makes sense to go with the flow for now.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: make fbdev/fbcon switchable per driver?
On Fri, Jan 27, 2017 at 03:02:42PM +0100, Daniel Vetter wrote:
> On Fri, Jan 27, 2017 at 11:00:38AM +0100, Gerd Hoffmann wrote:
> > Hi folks,
> >
> > Problem at hand: A virtual machine, equipped with two display devices,
> > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu).
> >
> > There is no easy way for the user to configure which of the two display
> > devices fbcon should run on. i915 happens to win over bochs-drm or qxl,
> > so you can't use the emulated gfx device as text console.
> >
> > One way out would be to add a module option to each driver, to turn off
> > fbdev emulation. Attached patch does that for i915.
> >
> > Comments? Better ideas?
>
> fbcon can be switched between different fbdev afaik, but don't ask me how.
Hint: Documentation/fb/fbcon.txt says fbcon=map:
Best regards,
Liviu
> I'd say if you want to keep fbcon (and not switch to something like
> kmscon), then that's where this logic should be. Might even exist already.
> Having a per-driver knob won't work, since then the next person complains
> about his multi-amd setup using the wrong gpu :-)
> -Daniel
>
> >
> > cheers,
> > Gerd
> >
>
> > From 19236e412a6f0e9390c1ce77d8702bbdb5511174 Mon Sep 17 00:00:00 2001
> > From: Gerd Hoffmann
> > Date: Fri, 27 Jan 2017 08:05:40 +0100
> > Subject: [PATCH] drm i915: add fbdev option
> >
> > Signed-off-by: Gerd Hoffmann
> > ---
> > drivers/gpu/drm/i915/intel_fbdev.c | 10 ++
> > 1 file changed, 10 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
> > b/drivers/gpu/drm/i915/intel_fbdev.c
> > index 3e3632c..cc0ba3e 100644
> > --- a/drivers/gpu/drm/i915/intel_fbdev.c
> > +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> > @@ -45,6 +45,11 @@
> > #include
> > #include "i915_drv.h"
> >
> > +static bool enable_fbdev = true;
> > +module_param_named(fbdev, enable_fbdev, bool, 0600);
> > +MODULE_PARM_DESC(fbdev,
> > +"Enable legacy fbdev emulation [default=true]");
> > +
> > static int intel_fbdev_set_par(struct fb_info *info)
> > {
> > struct drm_fb_helper *fb_helper = info->par;
> > @@ -706,6 +711,9 @@ int intel_fbdev_init(struct drm_device *dev)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> > int ret;
> >
> > + if (!enable_fbdev)
> > + return 0;
> > +
> > if (WARN_ON(INTEL_INFO(dev)->num_pipes == 0))
> > return -ENODEV;
> >
> > @@ -747,6 +755,8 @@ void intel_fbdev_initial_config_async(struct drm_device
> > *dev)
> > {
> > struct intel_fbdev *ifbdev = to_i915(dev)->fbdev;
> >
> > + if (!ifbdev)
> > + return;
> > ifbdev->cookie = async_schedule(intel_fbdev_initial_config, ifbdev);
> > }
> >
> > --
> > 1.8.3.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
--
---
.oooO
( )
\ ( Oooo.
\_) ( )
) /
(_/
One small step
for me ...
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable
Am 27.01.2017 um 15:12 schrieb Daniel Vetter: On Fri, Jan 27, 2017 at 09:22:47AM +0100, Christian König wrote: Am 27.01.2017 um 08:30 schrieb Daniel Vetter: On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: On 01/27/2017 03:29 AM, Michel Dänzer wrote: On 26/01/17 09:46 AM, Sinclair Yeh wrote: On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: On 01/25/2017 09:21 AM, Michel Dänzer wrote: From: Michel Dänzer The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer Reviewed-by: Thomas Hellstrom Reviewed-by: Christian König . Reviewed-by: Sinclair Yeh Thanks for the reviews! Via which tree should we merge this? I don't maintain a TTM tree any longer. Let's check with Daniel if he can merge it through drm-misc. I'm trying very hard not to get volunteered for ttm maintainer :-) Yeah, ok I volunteer. Wanted to take that over for a while anyway. I guess you didn't use the dim magic to push it? The test integration tree isn't rebuild ... Quickstart for the tooling: Autsch! Do I have to use that or can I just go with my usual tool set? Would probably be a pain to set this up everywhere here. Christian. https://01.org/linuxgraphics/gfx-docs/maintainer-tools/dim.html -Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
On Tue, Jan 24, 2017 at 11:57:58AM +, Chris Wilson wrote: > Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, > however I have a need to manually perform the hw enabling of the > signaling and would like to emit this tracepoint for completeness. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Daniel Vetter Anybody for a quick ack and backmerge? :) > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c > index a1bfc098ea10..d1f1f456f5c4 100644 > --- a/drivers/dma-buf/dma-fence.c > +++ b/drivers/dma-buf/dma-fence.c > @@ -28,6 +28,7 @@ > > EXPORT_TRACEPOINT_SYMBOL(dma_fence_annotate_wait_on); > EXPORT_TRACEPOINT_SYMBOL(dma_fence_emit); > +EXPORT_TRACEPOINT_SYMBOL(dma_fence_enable_signal); > > /* > * fence context counter: each execution context should have its own > -- > 2.11.0 > -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable
On Fri, Jan 27, 2017 at 03:43:18PM +0100, Christian König wrote: > Am 27.01.2017 um 15:12 schrieb Daniel Vetter: > > On Fri, Jan 27, 2017 at 09:22:47AM +0100, Christian König wrote: > > > Am 27.01.2017 um 08:30 schrieb Daniel Vetter: > > > > On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: > > > > > On 01/27/2017 03:29 AM, Michel Dänzer wrote: > > > > > > On 26/01/17 09:46 AM, Sinclair Yeh wrote: > > > > > > > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: > > > > > > > > Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: > > > > > > > > > On 01/25/2017 09:21 AM, Michel Dänzer wrote: > > > > > > > > > > From: Michel Dänzer > > > > > > > > > > > > > > > > > > > > The current caching state may not be tt_cached, even though > > > > > > > > > > the > > > > > > > > > > placement contains TTM_PL_FLAG_CACHED, because placement > > > > > > > > > > can contain > > > > > > > > > > multiple caching flags. Trying to swap out such a BO would > > > > > > > > > > trip up the > > > > > > > > > > > > > > > > > > > > BUG_ON(ttm->caching_state != tt_cached); > > > > > > > > > > > > > > > > > > > > in ttm_tt_swapout. > > > > > > > > > > > > > > > > > > > > Cc: sta...@vger.kernel.org > > > > > > > > > > Signed-off-by: Michel Dänzer > > > > > > > > > Reviewed-by: Thomas Hellstrom > > > > > > > > Reviewed-by: Christian König . > > > > > > > Reviewed-by: Sinclair Yeh > > > > > > Thanks for the reviews! Via which tree should we merge this? > > > > > > > > > > > > > > > > > I don't maintain a TTM tree any longer. Let's check with Daniel if he > > > > > can merge it through drm-misc. > > > > I'm trying very hard not to get volunteered for ttm maintainer :-) > > > Yeah, ok I volunteer. Wanted to take that over for a while anyway. > > I guess you didn't use the dim magic to push it? The test integration tree > > isn't rebuild ... Quickstart for the tooling: > > Autsch! Do I have to use that or can I just go with my usual tool set? > > Would probably be a pain to set this up everywhere here. We use it both for convience (e.g. it auto-adds the sob if need, and the patchwork link by default), and to catch mistakes (e.g. it checks that you're not pushing patches outside of the scope of drm-misc or i915 to the wrong tree). For drm-misc specifically there's also the 3 defconfigs you're supposed to build test before pushing (unfornately not scripted since distros can't even agree on what cross-compiler prefixes work for a given platform). And since 1 month ago we have an arm-soc ttm-based driver, so doing that for ttm patches is kinda a good idea too :-) But right now the main thing is this integration tree magic to regenerate drm-tip, and that's also what intel CI and kernelci from collabora beat on. Long term I'd love to push all this onto the server-side (github makes scipting a lot of this dead easy). But we're still stuck with patches scribbled on stones with emailed patches and all that, so client-side scripts are kinda needed. -Daniel -- 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] dma/fence: Export enable-signaling tracepoint for emission by drivers
Hi Chris, 2017-01-24 Chris Wilson : > Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, > however I have a need to manually perform the hw enabling of the > signaling and would like to emit this tracepoint for completeness. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Daniel Vetter > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) Reviewed-by: Gustavo Padovan Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Christoph Haag changed: What|Removed |Added Depends on||82717 --- Comment #2 from Christoph Haag --- Not to forget my mandelbulber bug 82717. It was actually working with funfunctor's partial image support found at https://cgit.freedesktop.org/~funfunctor/mesa/log/?h=clover-image-support-enabled Currently it fails on llvm-svn 293174 with OpenCL Build log: :0:0: in function fractal3D void (%struct.sClPixel addrspace(1)*, %struct.sClInBuff addrspace(1)*, %struct.sClInConstants addrspace(2)*, %struct.sClReflect addrspace(1)*, %opencl.image2d_ro_t.0 addrspace(2)*, i32): unsupported call to function get_global_id but since it's already been working with this non-mainlined code, it's one that can be crossed off the list maybe very soon already. Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=82717 [Bug 82717] OpenCL support for mandelbulber-opencl -- 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 82717] OpenCL support for mandelbulber-opencl
https://bugs.freedesktop.org/show_bug.cgi?id=82717 Christoph Haag changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 02:31:55PM +, Chris Wilson wrote: > On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > > When writing some testcases for nonblocking modesets. I found out that > > > > the > > > > infinite wait on the old fb was causing issues. > > > > > > The crux of the issue here is the locked wait for old dependencies and > > > the inability to inject the intel_prepare_reset disabling of all planes. > > > There are a couple of locked waits on struct_mutex within the modeset > > > locks for intel_overlay and if we happen to be using the display plane > > > for the first time. > > > > > > The first I suggested solving using fences to track dependencies and > > > keep the order between atomic states. Cancelling the outstanding > > > modesets, replacing with a disable and then on restore jumping to the > > > final state look doable. It also requires avoiding the struct_mutex for > > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > > we've talked about switching to mmio, but for starters we could move the > > > wait from inside intel_overlay into the fence for the atomic operation. > > > (But's that a little more surgery than we would like for intel_overlay I > > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > > that to an async fenced operation that is then naturally waited upon by > > > the atomic modeset. > > > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > > ok: > > > > We complete all the requests before we start the hw reset with fence.error > > = -EIO. But we do this only when we need to get at the display locks. A > > slightly more elegant solution would be to trylock modeset locks, and if > > one of them fails (and only then) complete all requests with -EIO to get > > the concurrent modeset to proceed before we reset the hardware. That's > > essentially the logic we had before all the reworks, and it worked. But I > > didn't look at how scary that all would be to make it work again ... > > The modeset lock may not just be waiting on our requests (even on pnv we > can expect that there are already users celebrating that pnv+nouveau > finally works ;) and that the display is not the only user/observer of > those requests. Using the requests to break the modeset lock just feels > like the wrong approach. It's a cycle, and we need to break it somewhere. Another option might be to break the cycle the same way we do it for gem locks: Wake up everyone and restart the modeset ioctl. Since the trouble only happens for synchronous modesets where we hold the locks while waiting for fences, we can also break out of that and restart. And I also don't think that would leak to other drivers, after all our gem locking restart dances also don't leak to other drivers - it's just our own driver's lock which are affected by these special wakupe semantics. -Daniel -- 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
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Andreas Boll changed: What|Removed |Added Depends on||96296 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=96296 [Bug 96296] clpeak causes a GPU hang -- 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 96296] clpeak causes a GPU hang
https://bugs.freedesktop.org/show_bug.cgi?id=96296 Andreas Boll changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: Make sure BOs being swapped out are cacheable
On Fri, Jan 27, 2017 at 3:22 AM, Christian König wrote: > Am 27.01.2017 um 08:30 schrieb Daniel Vetter: >> >> On Fri, Jan 27, 2017 at 07:23:58AM +0100, Thomas Hellstrom wrote: >>> >>> On 01/27/2017 03:29 AM, Michel Dänzer wrote: On 26/01/17 09:46 AM, Sinclair Yeh wrote: > > On Wed, Jan 25, 2017 at 10:49:33AM +0100, Christian König wrote: >> >> Am 25.01.2017 um 10:25 schrieb Thomas Hellstrom: >>> >>> On 01/25/2017 09:21 AM, Michel Dänzer wrote: From: Michel Dänzer The current caching state may not be tt_cached, even though the placement contains TTM_PL_FLAG_CACHED, because placement can contain multiple caching flags. Trying to swap out such a BO would trip up the BUG_ON(ttm->caching_state != tt_cached); in ttm_tt_swapout. Cc: sta...@vger.kernel.org Signed-off-by: Michel Dänzer >>> >>> Reviewed-by: Thomas Hellstrom >> >> Reviewed-by: Christian König . > > Reviewed-by: Sinclair Yeh Thanks for the reviews! Via which tree should we merge this? >>> I don't maintain a TTM tree any longer. Let's check with Daniel if he >>> can merge it through drm-misc. >> >> I'm trying very hard not to get volunteered for ttm maintainer :-) > > > Yeah, ok I volunteer. Wanted to take that over for a while anyway. > >> Nominally Alex&Christian have drm-misc commit rights, but they haven't >> used them yet. But I think merging through drm-misc would make sense, >> there's regular pull request trains for both -next and -fixes. > > > Completely agree on merging it through drm-misc. Going to give my push > rights a try today. > >> Or merge through the amd tree with Dave's ack, but I'd really like to get >> amd folks >> into the drm-misc group ... > > > I've got a few more already reviewed TTM changes which are currently waiting > to be pushed upstream where amdgpu has dependencies on. > > Going to sync with Alex so he sends his pull requests with those changes to > Dave after the merge of the depending changes. > > If you want to object that just merging through the AMD tree would be > simpler, I agree but I actually want to do this exercise at least once :) I was thinking of including this in my -fixes pull next week, but I don't have a strong preference either way. The other ttm changes are pretty intertwined with amdgpu changes so I think it would be easier to take them in via the amdgpu tree. In the future we can adjust that. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99510] cl_khr_fp64 is reported as supported, but is not, on CAYMAN
https://bugs.freedesktop.org/show_bug.cgi?id=99510 Andreas Boll changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Andreas Boll changed: What|Removed |Added Depends on||99510 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99510 [Bug 99510] cl_khr_fp64 is reported as supported, but is not, on CAYMAN -- 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: [Intel-gfx] [PATCH 0/3] drm/i915: Handle hanging during nonblocking modeset correctly.
On Fri, Jan 27, 2017 at 03:58:08PM +0100, Daniel Vetter wrote: > On Fri, Jan 27, 2017 at 02:31:55PM +, Chris Wilson wrote: > > On Fri, Jan 27, 2017 at 03:21:29PM +0100, Daniel Vetter wrote: > > > On Fri, Jan 27, 2017 at 09:30:50AM +, Chris Wilson wrote: > > > > On Thu, Jan 26, 2017 at 04:59:21PM +0100, Maarten Lankhorst wrote: > > > > > When writing some testcases for nonblocking modesets. I found out > > > > > that the > > > > > infinite wait on the old fb was causing issues. > > > > > > > > The crux of the issue here is the locked wait for old dependencies and > > > > the inability to inject the intel_prepare_reset disabling of all planes. > > > > There are a couple of locked waits on struct_mutex within the modeset > > > > locks for intel_overlay and if we happen to be using the display plane > > > > for the first time. > > > > > > > > The first I suggested solving using fences to track dependencies and > > > > keep the order between atomic states. Cancelling the outstanding > > > > modesets, replacing with a disable and then on restore jumping to the > > > > final state look doable. It also requires avoiding the struct_mutex for > > > > disabling, which is quite easy. To avoid the wait under struct_mutex, > > > > we've talked about switching to mmio, but for starters we could move the > > > > wait from inside intel_overlay into the fence for the atomic operation. > > > > (But's that a little more surgery than we would like for intel_overlay I > > > > guess - dig out Ville's patches for overlay planes?) And to prevent the > > > > wait under struct_mutex for pin_to_display_plane, my plane is to move > > > > that to an async fenced operation that is then naturally waited upon by > > > > the atomic modeset. > > > > > > A bit more a hack, but a different idea, and I think hack for gen234.0 is > > > ok: > > > > > > We complete all the requests before we start the hw reset with fence.error > > > = -EIO. But we do this only when we need to get at the display locks. A > > > slightly more elegant solution would be to trylock modeset locks, and if > > > one of them fails (and only then) complete all requests with -EIO to get > > > the concurrent modeset to proceed before we reset the hardware. That's > > > essentially the logic we had before all the reworks, and it worked. But I > > > didn't look at how scary that all would be to make it work again ... > > > > The modeset lock may not just be waiting on our requests (even on pnv we > > can expect that there are already users celebrating that pnv+nouveau > > finally works ;) and that the display is not the only user/observer of > > those requests. Using the requests to break the modeset lock just feels > > like the wrong approach. > > It's a cycle, and we need to break it somewhere. Another option might be > to break the cycle the same way we do it for gem locks: Wake up everyone > and restart the modeset ioctl. Since the trouble only happens for > synchronous modesets where we hold the locks while waiting for fences, we > can also break out of that and restart. And I also don't think that would > leak to other drivers, after all our gem locking restart dances also don't > leak to other drivers - it's just our own driver's lock which are affected > by these special wakupe semantics. It's a queue of nonblocking modesets that we need to worry about, afaik. Moving the wait for blocking modeset outside of modeset lock is easily achievable (and avoiding the other waits under both the modeset + struct_mutex I have at least an idea for). So the challenge is how to inject all-planes-off for gen3 and then allow the queue to continue again afterwards. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 193341] AMDGPU: kernel NULL pointer dereferenced with hybrid graphics
https://bugzilla.kernel.org/show_bug.cgi?id=193341 Alex Deucher changed: What|Removed |Added CC||alexdeuc...@gmail.com --- Comment #3 from Alex Deucher --- Created attachment 253281 --> https://bugzilla.kernel.org/attachment.cgi?id=253281&action=edit possible fix This patch should fix the crash. -- 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 99387] Kernel 4.9: Kaveri + Hainan choked on boot using amdgpu
https://bugs.freedesktop.org/show_bug.cgi?id=99387 --- Comment #8 from Alex Deucher --- Created attachment 129182 --> https://bugs.freedesktop.org/attachment.cgi?id=129182&action=edit possible fix This patch should fix the crash. -- 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 v2] drm/color: un-inline drm_color_lut_extract()
The function is not that big, but it's also not used for anything
performance critical. Make it a normal function.
As a side effect, this apparently makes sparse smarter about what it's
doing, and gets rid of the warning:
./include/drm/drm_color_mgmt.h:53:28: warning: shift too big (4294967295) for
type unsigned long
./include/drm/drm_color_mgmt.h:53:28: warning: cast truncates bits from
constant value (8000 becomes 0)
v2: rebased
Cc: Lionel Landwerlin
Reviewed-by: Daniel Vetter
Reviewed-by: Lionel Landwerlin
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/drm_color_mgmt.c | 24
include/drm/drm_color_mgmt.h | 27 ++-
2 files changed, 26 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/drm_color_mgmt.c b/drivers/gpu/drm/drm_color_mgmt.c
index 789b4c65cd69..cc23b9a505c0 100644
--- a/drivers/gpu/drm/drm_color_mgmt.c
+++ b/drivers/gpu/drm/drm_color_mgmt.c
@@ -88,6 +88,30 @@
*/
/**
+ * drm_color_lut_extract - clamp and round LUT entries
+ * @user_input: input value
+ * @bit_precision: number of bits the hw LUT supports
+ *
+ * Extract a degamma/gamma LUT value provided by user (in the form of
+ * &drm_color_lut entries) and round it to the precision supported by the
+ * hardware.
+ */
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision)
+{
+ uint32_t val = user_input;
+ uint32_t max = 0x >> (16 - bit_precision);
+
+ /* Round only if we're not using full precision. */
+ if (bit_precision < 16) {
+ val += 1UL << (16 - bit_precision - 1);
+ val >>= 16 - bit_precision;
+ }
+
+ return clamp_val(val, 0, max);
+}
+EXPORT_SYMBOL(drm_color_lut_extract);
+
+/**
* drm_crtc_enable_color_mgmt - enable color management properties
* @crtc: DRM CRTC
* @degamma_lut_size: the size of the degamma lut (before CSC)
diff --git a/include/drm/drm_color_mgmt.h b/include/drm/drm_color_mgmt.h
index d9c2f680f5ae..bce4a532836d 100644
--- a/include/drm/drm_color_mgmt.h
+++ b/include/drm/drm_color_mgmt.h
@@ -25,6 +25,8 @@
#include
+uint32_t drm_color_lut_extract(uint32_t user_input, uint32_t bit_precision);
+
void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
uint degamma_lut_size,
bool has_ctm,
@@ -33,29 +35,4 @@ void drm_crtc_enable_color_mgmt(struct drm_crtc *crtc,
int drm_mode_crtc_set_gamma_size(struct drm_crtc *crtc,
int gamma_size);
-/**
- * drm_color_lut_extract - clamp and round LUT entries
- * @user_input: input value
- * @bit_precision: number of bits the hw LUT supports
- *
- * Extract a degamma/gamma LUT value provided by user (in the form of
- * &drm_color_lut entries) and round it to the precision supported by the
- * hardware.
- */
-static inline uint32_t drm_color_lut_extract(uint32_t user_input,
-uint32_t bit_precision)
-{
- uint32_t val = user_input;
- uint32_t max = 0x >> (16 - bit_precision);
-
- /* Round only if we're not using full precision. */
- if (bit_precision < 16) {
- val += 1UL << (16 - bit_precision - 1);
- val >>= 16 - bit_precision;
- }
-
- return clamp_val(val, 0, max);
-}
-
-
#endif
--
2.1.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests/util: Add support for meson module
On 27 January 2017 at 07:47, Thierry Reding wrote: > On Thu, Jan 26, 2017 at 04:14:56PM +, Emil Velikov wrote: >> On 26 January 2017 at 15:49, Thierry Reding wrote: >> > On Fri, Jan 20, 2017 at 06:28:39PM +, Emil Velikov wrote: >> >> On 20 January 2017 at 16:17, Thierry Reding wrote: >> >> > On Fri, Jan 20, 2017 at 02:13:00PM +, Emil Velikov wrote: >> >> >> On 19 January 2017 at 09:19, Thierry Reding wrote: >> >> >> > On Wed, Jan 18, 2017 at 02:59:21PM +0100, Neil Armstrong wrote: >> >> >> >> Add support for Amlogic Meson DRM driver merged for Linux 4.10. >> >> >> >> >> >> >> >> Signed-off-by: Neil Armstrong >> >> >> >> --- >> >> >> >> tests/util/kms.c | 1 + >> >> >> >> 1 file changed, 1 insertion(+) >> >> >> > >> >> >> > Applied, thanks. >> >> >> > >> >> >> Was going to say "NACK use Thierry's helpers" but you've beat me to it. >> >> >> As a Tl;DR: we _really_ want to stop using drmOpen* for anything >> >> >> that's KMS. >> >> > >> >> > I think it's still useful to have this helper to iterate over all >> >> > supported driver because it enables easy testing with just a simple >> >> > modetest. >> >> > >> >> > That said, for (almost) as long as I remember I've been using the -M >> >> > option to prevent modetest from iterating over the list, which can take >> >> > fairly long if you've got DRM_DEBUG messages enabled. >> >> > >> >> > I'm not sure I understand exactly what you're suggesting by "use >> >> > Thierry's helpers". modetest and other tests use util_open() internally >> >> > now. That in turn uses drmOpen(), though we're of course open to change >> >> > that. Are you suggesting we somehow use drmDevice to locate existing >> >> > devices? >> >> > >> >> Yes using drmDevice is what I had in mind. The only thing that was >> >> stopping me from doing that is the lack of platform devices support. >> >> With that in we can start purging _everything_ that uses drmOpen*. >> >> >> >> > We could implement some heuristic that finds the first device with a >> >> > primary node, but what if we want to support the -M option? There is >> >> > currently no way of getting the driver from drmDevice. Maybe that's >> >> > something we should add anyway. >> >> > >> >> The -M (kernel module name as given by drmGetVersion) is another >> >> interesting topic. Feel free to skip to the Tl;Dr below. >> >> >> >> If doing the ioctl implicitly via drmOpen or drmDevice wakes up the >> >> device, keeping in mind that: >> >> - it can take some time, and >> >> - you don't always need the info >> >> >> >> A couple of elaborate workarounds include: >> >> - use only on demand - add DRM_DEVICE_GET_MODULE_NAME or alike to the >> >> drmDevice2 API >> >> Needs a big "this can be VERY slow" warning in the documentation/man >> >> pages... first we need actual man pages for libdrm ;-) >> >> - deprecate the whole thing and use the compat strings - how do we >> >> handle the PCI devices ? >> >> - use the kernel module name (foo.ko) - kind of making it an ABI, but >> >> iirc we've already have users which depend on it >> >> Neither PCI devices nor platform ones are consistent in their naming - >> >> foo.ko vs the value returned by the IOCTL. >> >> >> >> We might be able to combine the latter two ... need to double-check. >> >> >> >> Tl;Dr: For the moment I'd leave it to the user to call drmGetVersion. >> > >> > Okay, sounds like a plan. The good thing is we can keep adding new >> > module names to the util_open() helper >> The key point is that you do _not_ need any list. Any new and existing >> drivers should just work. If they don't then they're [highly likely] >> broken and should be fixed ;-) > > Yeah, what I was trying to say is that the implementation is now > centralized, so adding module names until we replace the implementation > isn't going to hurt much, while at the same time getting people the > support that they want. > > Once we transition the implementation to using drmDevice, the list will > simply disappear and everyone will be using the new code automatically. > > That said, I have a couple of things on my plate for today, but I'll go > reimplement util_open() when I'm done with those. > Seems like I completely misunderstood you there :-\ Pardon if I came too picky earlier. Thanks Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] tests: Use -pthread in CFLAGS instead of -lpthread
On 27 January 2017 at 07:21, Tomasz Figa wrote: > -lpthread is not always a valid flag to pull pthread support, especially > on Android it will fail to link due to a missing libpthread.so. The more > generic way to build-in pthread support is to use the -pthread CFLAG, so > let's use it instead. > Afaict this might cause an issue on BSD/Solaris platforms, but afaict neither of which builds the code in question. With that said I'll land this shortly. Whist looking through Solaris repos, there's a lot of patches/workarounds many of which should be fine to land - be that on Mesa and/or libdrm side. Randy, Niveditha can I interest you in sending patches upstream as soon as you [others in the team] spot issues ? Even if you think that they're hacks/will be rejected/etc. Please ? Adding note for each patch why it's not in is a very good idea ;-) Note - if you need GNU_MAKE, extra defines, etc. workarounds that's a giveaway that something on our end is broken. Please report and/or send us patches. Thanks ! Emil ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: drm-misc for small drivers?
On Fri, Jan 27, 2017 at 1:32 AM, Daniel Vetter wrote: > On Thu, Jan 26, 2017 at 8:11 PM, Sean Paul wrote: >> On Thu, Jan 26, 2017 at 06:08:42PM +0100, Daniel Vetter wrote: >>> - Should it be an entire separate tree for soc drivers? Problem here >>> is that we lack a volunteer group (and imo it really should be a group >>> to avoid the single-maintainer troubles) to run that. >> >> Big +1. In addition to spreading out the workload, driver maintainers should >> still exercise ownership/stewardship. > > Big +1 on separate driver tree, or that we'll probably can't get it > because no volunteers? Neither :-) I was agreeing that we need a volunteer group (or "review economy") to make this work, as opposed to a single maintainer. Sean > For spreading out the workload, I don't expect > (or want) that this will cause more work for the existing drm-misc > group. Well, a few minutes more for the pull request summaries maybe, > but definitely no expectation that suddenly all of drm-misc helps out > with reviewing driver patches. That won't work. > >>> - Who's elligible? I think we could start small with a few volunteers >>> and their drivers, and then anyone who's willing. >> >> I think we could safely volunteer some drivers we haven't seen pull requests >> from in a while. > > Hm, I didn't think about drivers which aren't well-maintained. But if > there's a volunteer group we can do that ofc, but maybe not start out > with forcing it ... > -Daniel > -- > Daniel Vetter > Software Engineer, Intel Corporation > +41 (0) 79 365 57 48 - http://blog.ffwll.ch -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/4] drm: qxl: Drop misleading comment
Daniel Vetter writes:
> On Fri, Jan 27, 2017 at 09:20:42AM +0100, Gerd Hoffmann wrote:
>> On Do, 2017-01-26 at 23:05 -0200, Gabriel Krisman Bertazi wrote:
>> > No longer true since commit 07f8d9bdb235 ("drm/qxl: add support for > 1
>> > output"). qxl_num_crtc defaults to 4 and is configurable as a module
>> > parameter.
>>
>> Picked up patches 1-3 for drm-qemu branch.
>>
>> Patch 4 doesn't apply and seems to have a dependency on out-of-tree
>> changes, git am fails to do a 3way merge due to missing commits (trying
>> to apply to 4.10-rc5).
>
> It needs the demidlayer that's already in drm-next ...
Thank you guys for the review.
Yes, my patches were based on drm-misc next branch, I should have
mentioned that in the original patch. It actually depends on stuff
already in drm-misc, so I won't be able to rebase just this to drm-qemu
tree.
Do you want to merge from drm-misc or should we push this one
directly via drm-misc?
--
Gabriel Krisman Bertazi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: RFC: drm-misc for small drivers?
On Fri, Jan 27, 2017 at 1:52 AM, Daniel Vetter wrote: > On Thu, Jan 26, 2017 at 8:48 PM, Eric Anholt wrote: >>> - Should we require review or at least acks for patches committed by >>> the author? We have a bunch of drivers with effectively just 1 person >>> working on it, where getting real review is hard. But otoh a few of >>> those 1-person drivers will become popular, and then it's good to >>> start with establishing peer-review early on. I also think that >>> requiring peer-review is good to share best practices and knowledge >>> between different people in our community, not just to make sure the >>> code is correct. For all these reasons I'm leaning towards not making >>> an exception for drivers, and requiring the same amount of review for >>> them if they go in through drm-misc as for any other patch. >> >> This is the only part I'm concerned about. Would anyone review vc4 >> patches? Voluntarily? Actually thinking about the >> functionality/structure of the code, not just style? >> >> It sucks today that as part of the kernel process I send out patches >> "for review", knowing that I won't ever get review, and I just have to >> wait a while until I think people won't complain at me for sending a PR >> too quickly. But if the change is to just start blocking my patches on >> review, I'm concerned I won't be able to get them in at all. >> >> I think there's a middle ground, where you graduate to waiting for >> review once you have multiple involved in that area of the code. This >> is what we do in Mesa -- vc4 and freedreno push directly, but on the >> code we share (tgsi_to_nir, for example), we do review. >> >> (This is also the point at which I'll offer: Any other ARM drivers that >> want to do review exchange with me, let me know and I'll start paying >> attention to your stuff) > > So part of the evil goal here is really to kickstart a tit-for-tat > review economy. That'd would mean we'd need at least 2-3 drivers to > volunteer for starters, and in many cases a full review is not going > to happen (or would just unduly delay things for no gain at all). What > I think would be great though is something much less formal along the > lines of "read your patch, looks all reasonable, seems to use core drm > code&concepts how it's supposed, ack". Maybe a few recommendations how > code can be simplified/clarified, but definitely no multi-round > bikeshedding tour. So not review to ensure code correctness, but just > as an information and best practice sharing tool. Also this should be > a good way to catch good opportunities for subsystem wide refactorings > when someone copypastes the same few lines for the umpteenth time > (that's how we e.g. got rid of all the dummy callback > implementations). And it shouldn't be much work, when I review a new > driver submission it's about 15 minutes to scroll through patches and > drop a few comments/suggestions on it. > > So much less review than for drm core, and I think somehow getting > this off the ground would be really good for the community overall. > But if it doesn't work out, then I'm ok with dropping it, but I think > we really should try first. I think drm core had similar troubles with > review, and with drm-misc collaborations seems to improve already. I like the idea, but I'm concerned it would just be work for the sake of work. I'm not sure how much value it provides. I'm worried it'll just turn into acking for the sake of acking. For core driver changes that are independent of anything shared, I'm not really sure what the ack provides other than a way to slap an ack label on your patch unless the reviewer really digs into the driver. I guess an extra set of eyes never hurts. Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
fwiw, On 27 January 2017 at 20:25, Gustavo Padovan wrote: > Hi Chris, > > 2017-01-24 Chris Wilson : > >> Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, >> however I have a need to manually perform the hw enabling of the >> signaling and would like to emit this tracepoint for completeness. >> >> Signed-off-by: Chris Wilson >> Cc: Sumit Semwal >> Cc: Daniel Vetter >> --- >> drivers/dma-buf/dma-fence.c | 1 + >> 1 file changed, 1 insertion(+) > > Reviewed-by: Gustavo Padovan > Feel free to add my a-b :) > Gustavo > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Thanks and regards, Sumit Semwal Linaro Mobile Group - Kernel Team Lead Linaro.org │ Open source software for ARM SoCs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC PATCH v2 2/5] drm: hdlcd: use vblank hooks in struct drm_crtc_funcs
On Sun, Jan 22, 2017 at 02:09:03PM +0800, Shawn Guo wrote:
> From: Shawn Guo
>
> The vblank hooks in struct drm_driver are deprecated and only meant for
> legacy drivers. For modern drivers with DRIVER_MODESET flag, the hooks
> in struct drm_crtc_funcs should be used instead.
>
> Signed-off-by: Shawn Guo
> Cc: Liviu Dudau
Acked-by: Liviu Dudau
> ---
> drivers/gpu/drm/arm/hdlcd_crtc.c | 20
> drivers/gpu/drm/arm/hdlcd_drv.c | 20
> 2 files changed, 20 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c
> b/drivers/gpu/drm/arm/hdlcd_crtc.c
> index 20ebfb4fbdfa..798a3cc480a2 100644
> --- a/drivers/gpu/drm/arm/hdlcd_crtc.c
> +++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
> @@ -42,6 +42,24 @@ static void hdlcd_crtc_cleanup(struct drm_crtc *crtc)
> drm_crtc_cleanup(crtc);
> }
>
> +static int hdlcd_crtc_enable_vblank(struct drm_crtc *crtc)
> +{
> + struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> + unsigned int mask = hdlcd_read(hdlcd, HDLCD_REG_INT_MASK);
> +
> + hdlcd_write(hdlcd, HDLCD_REG_INT_MASK, mask | HDLCD_INTERRUPT_VSYNC);
> +
> + return 0;
> +}
> +
> +static void hdlcd_crtc_disable_vblank(struct drm_crtc *crtc)
> +{
> + struct hdlcd_drm_private *hdlcd = crtc_to_hdlcd_priv(crtc);
> + unsigned int mask = hdlcd_read(hdlcd, HDLCD_REG_INT_MASK);
> +
> + hdlcd_write(hdlcd, HDLCD_REG_INT_MASK, mask & ~HDLCD_INTERRUPT_VSYNC);
> +}
> +
> static const struct drm_crtc_funcs hdlcd_crtc_funcs = {
> .destroy = hdlcd_crtc_cleanup,
> .set_config = drm_atomic_helper_set_config,
> @@ -49,6 +67,8 @@ static void hdlcd_crtc_cleanup(struct drm_crtc *crtc)
> .reset = drm_atomic_helper_crtc_reset,
> .atomic_duplicate_state = drm_atomic_helper_crtc_duplicate_state,
> .atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
> + .enable_vblank = hdlcd_crtc_enable_vblank,
> + .disable_vblank = hdlcd_crtc_disable_vblank,
> };
>
> static struct simplefb_format supported_formats[] = SIMPLEFB_FORMATS;
> diff --git a/drivers/gpu/drm/arm/hdlcd_drv.c b/drivers/gpu/drm/arm/hdlcd_drv.c
> index e5f4f4a6546d..6598ba4cc958 100644
> --- a/drivers/gpu/drm/arm/hdlcd_drv.c
> +++ b/drivers/gpu/drm/arm/hdlcd_drv.c
> @@ -199,24 +199,6 @@ static void hdlcd_irq_uninstall(struct drm_device *drm)
> hdlcd_write(hdlcd, HDLCD_REG_INT_MASK, irq_mask);
> }
>
> -static int hdlcd_enable_vblank(struct drm_device *drm, unsigned int crtc)
> -{
> - struct hdlcd_drm_private *hdlcd = drm->dev_private;
> - unsigned int mask = hdlcd_read(hdlcd, HDLCD_REG_INT_MASK);
> -
> - hdlcd_write(hdlcd, HDLCD_REG_INT_MASK, mask | HDLCD_INTERRUPT_VSYNC);
> -
> - return 0;
> -}
> -
> -static void hdlcd_disable_vblank(struct drm_device *drm, unsigned int crtc)
> -{
> - struct hdlcd_drm_private *hdlcd = drm->dev_private;
> - unsigned int mask = hdlcd_read(hdlcd, HDLCD_REG_INT_MASK);
> -
> - hdlcd_write(hdlcd, HDLCD_REG_INT_MASK, mask & ~HDLCD_INTERRUPT_VSYNC);
> -}
> -
> #ifdef CONFIG_DEBUG_FS
> static int hdlcd_show_underrun_count(struct seq_file *m, void *arg)
> {
> @@ -285,8 +267,6 @@ static void hdlcd_debugfs_cleanup(struct drm_minor *minor)
> .irq_postinstall = hdlcd_irq_postinstall,
> .irq_uninstall = hdlcd_irq_uninstall,
> .get_vblank_counter = drm_vblank_no_hw_counter,
> - .enable_vblank = hdlcd_enable_vblank,
> - .disable_vblank = hdlcd_disable_vblank,
> .gem_free_object_unlocked = drm_gem_cma_free_object,
> .gem_vm_ops = &drm_gem_cma_vm_ops,
> .dumb_create = drm_gem_cma_dumb_create,
> --
> 1.9.1
>
--
| I would like to |
| fix the world, |
| but they're not |
| giving me the |
\ source code! /
---
¯\_(ツ)_/¯
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
DRM Atomic property for color-space conversion
Hi, We're looking to enable the per-plane color management hardware in Mali-DP with atomic properties, which has sparked some conversation around how to handle YCbCr formats. As it stands today, it's assumed that a driver will implicitly "do the right thing" to display a YCbCr buffer. YCbCr data often uses different gamma curves and signal ranges (e.g. BT.609, BT.701, BT.2020, studio range, full-range), so its desirable to be able to explicitly control the YCbCr to RGB conversion process from userspace. We're proposing adding a "CSC" (color-space conversion) property to control this - primarily per-plane for framebuffer->pipeline CSC, but perhaps one per CRTC too for devices which have an RGB pipeline and want to output in YUV to the display: Name: "CSC" Type: ENUM | ATOMIC; Enum values (representative): "default": Same behaviour as now. "Some kind" of YCbCr->RGB conversion for YCbCr buffers, bypass for RGB buffers "disable": Explicitly disable all colorspace conversion (i.e. use an identity matrix). "YCbCr to RGB: BT.709": Only valid for YCbCr formats. CSC in accordance with BT.709 using [16..235] for (8-bit) luma values, and [16..240] for 8-bit chroma values. For 10-bit formats, the range limits are multiplied by 4. "YCbCr to RGB: BT.709 full-swing": Only valid for YCbCr formats. CSC in accordance with BT.709, but using the full range of each channel. "YCbCr to RGB: Use CTM":* Only valid for YCbCr formats. Use the matrix applied via the plane's CTM property "RGB to RGB: Use CTM":* Only valid for RGB formats. Use the matrix applied via the plane's CTM property "Use CTM":* Valid for any format. Use the matrix applied via the plane's CTM property ... any other values for BT.601, BT.2020, RGB to YCbCr etc. etc. as they are required. *This assumes color-management is enabled per-plane. We're currently working on patches to add this mostly to be able to use per-plane degamma, but it would be analogous to the CRTC color-management code and so also be able to expose a per-plane CTM property. Our hardware implements the color-space conversion as a 3x3 matrix, so we can implement a helper to convert a CSC enum value to a CTM matrix for use by any hardware which has a programmable CSC matrix. For any other hardware, the driver simply needs to map the enum value to whatever selector bits are available. It's expected that the "Use CTM" value(s) are *not* the common case, and most of the time userspace will use one of the provided "standard" enum values. The three different flavours of "Use CTM" allow us to support hardware whose CSC hardware can only be used on e.g. YCbCr data. Drivers can of course filter the enum list to expose whichever subset the hardware can support. Having thrashed this out a bit on IRC with Ville, I think the above approach is flexible enough to support at least Mali-DP and i915, without burdening userspace any more than necessary. It also provides the "default" behaviour which is backwards compatible, and allows for fully custom CSC matrices where that is supported. We can obviously implement this as a Mali-DP driver private property, but it would be good to come up with something to go into the core if possible. I'd be happy to hear any feedback, Thanks, Brian ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-next-4.11
Hi Dave, This is the main feature pull for radeon and amdgpu for 4.11. Highlights: - Power and clockgating improvements - Preliminary SR-IOV support - ttm buffer priority support - ttm eviction fixes - Removal of the ttm lru callbacks - Remove SI DPM quirks due to MC firmware issues - Handle VFCT with multiple vbioses - Powerplay improvements - Lots of driver cleanups The following changes since commit a5b2b6ebf34b20e70a2bdb5214c371744e7fa260: drm/sti: Fix compilation failure for drm_framebuffer.pixel_format (2017-01-27 12:54:15 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.11 for you to fetch changes up to 268c3001842cb179b54a2825dad9b70151bf4de6: drm/amdgpu: fix amdgpu_bo_va_mapping flags (2017-01-27 12:20:45 -0500) Alex Deucher (7): drm/amdgpu: use the num_rings variable for checking vce rings drm/amdgpu: drop pitcairn dpm quirks drm/radeon: drop pitcairn dpm quirks drm/amdgpu: remove unused header si_reg.h drm/amdgpu: move misc si headers into amdgpu drm/radeon: handle vfct with multiple vbios images drm/amdgpu: handle vfct with multiple vbios images Amber Lin (1): drm/amdgpu: PCI I/O bar can be disabled Andrey Grodzovsky (2): drm/amdgpu: Switch error code when bo pin fails. (v3) drm/amdgpu: Refactor flip into prepare submit and submit. (v3) Arindam Nath (1): drm/amd/amdgpu: get maximum and used UVD handles (v4) Arvind Yadav (2): drm/amd/amdgpu/amdgpu_ttm: Handle return NULL error from ioremap_nocache drm: radeon: radeon_ttm: Handle return NULL error from ioremap_nocache Christian König (9): drm/ttm: remove allow_errors parameter from ttm_bo_force_list_clean drm/ttm: add BO priorities for the LRUs drm/amdgpu: user BO priority instead of self coding it (v2) drm/amdgpu: double the priority of kernel allocations drm/ttm: revert "implement LRU add callbacks v2" drm/ttm: revert "add optional LRU removal callback v2" drm/amdgpu: access stolen VRAM directly on KV/KB (v2) drm/amdgpu: access stolen VRAM directly on CZ (v2) drm/amdgpu: fix amdgpu_bo_va_mapping flags Harry Wentland (2): drm/amd/amdgpu: Add HDMI_DATA_SCRAMBLE register definition drm/amd/amdgpu: Add DPHY_SCRAM_CNTL register defines Huang Rui (20): drm/amd/powerplay: add callbacks to move smc firmware request into sw_init phase drm/amd/powerplay: add request_firmware/release_firmware for smu7 drm/amd/powerplay: fix request smc_sk firmware case drm/amdgpu: cleanup useless smu_ucode_xfer_vi.h drm/amdgpu: cleanup useless extern functions drm/amd/powerplay: add prefix for all powerplay pr_* prints drm/amd/powerplay: reshuffle headers to make pr_fmt macro before drm/amd/powerplay: refine print message for amd_powerplay drm/amd/powerplay: update all printk to pr_* on eventmgr drm/amd/powerplay: update all printk to pr_* on hwmgr drm/amd/powerplay: update all printk to pr_* on smumgr drm/amdgpu: introduce an interface to get clock gating status dynamically drm/amdgpu: add parse clock gating state drm/amdgpu: add get clockgating_state method for gfx v8 drm/amdgpu: add get clockgating_state method for gmc v8 drm/amdgpu: add get clockgating_state method for sdma v3 drm/amdgpu: add get clockgating_state method for vi common drm/amdgpu: add get clockgating_state method for uvd v5&v6 drm/amdgpu: add get clockgating_state method for vce v3 drm/amdgpu: fix typo of CGTS Julia Lawall (1): drm/amdgpu/gfx8: fix bugon.cocci warnings Junwei Zhang (1): drm/amd/amdgpu: remove the uncessary parameter for ib scheduler Kees Cook (1): drm/amdgpu: use designated initializers Ken Xue (1): drm/amdgpu: Refine the way to get atom bios Monk Liu (11): drm/amdgpu:new field members for SRIOV drm/amdgpu:add new file for SRIOV drm/amdgpu:invoke CSA functions (v2) drm/amdgpu:add META_DATA struct for CSA/SRIOV v2 drm/amdgpu:implement ring_write_multiple drm/amdgpu:implement CE/DE meta-init routines drm/amdgpu:introduce new flag to identify VM domain for cntx_ctrl drm/amdgpu:in cntx_ctrl we need insert meta-init for CE/DE(V2) drm/amdgpu:set cond_exec polling value to 1 in ring_init drm/amdgpu:Preamble is forbid to be ignored in SRIOV drm/amdgpu:insert switch buffer only for VM submit Nicolai Hähnle (7): drm/ttm: add evict parameter to ttm_bo_driver::move_notify drm/amd/amdgpu: move eviction counting to amdgpu_bo_move_notify drm/amd/amdgpu: add amdgpu_bo_gpu_accessible helper function drm/amd/amdgpu: add check that shadow page directory is GPU-accessible drm/amd/amdgpu: add check that shadow page tables are GPU-accessible drm/amd/amdgpu: lock reservation objec
Re: [PATCH] dma/fence: Export enable-signaling tracepoint for emission by drivers
Hi Chris, 2017-01-24 Chris Wilson : > Currently this tracepoint is solely used by dma_fence_enable_sw_signaling, > however I have a need to manually perform the hw enabling of the > signaling and would like to emit this tracepoint for completeness. > > Signed-off-by: Chris Wilson > Cc: Sumit Semwal > Cc: Daniel Vetter > --- > drivers/dma-buf/dma-fence.c | 1 + > 1 file changed, 1 insertion(+) Applied to drm-misc-next Thanks! Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 --- Comment #3 from Vedran Miletić --- Thanks for contributing. Very glad to hear about Mandelbulber almost working. I have added it to [1] as well. [1] https://en.wikipedia.org/wiki/List_of_OpenCL_applications -- 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] MAINTAINERS: add dma-fence* files to Sync File maintainership
From: Gustavo Padovan As Sync File is highly dependent on dma-fence* tracks it under SYNC FILE_FRAMEWORK as well. Signed-off-by: Gustavo Padovan --- MAINTAINERS | 1 + 1 file changed, 1 insertion(+) diff --git a/MAINTAINERS b/MAINTAINERS index bdc4843..c1c000d 100644 --- a/MAINTAINERS +++ b/MAINTAINERS @@ -3976,6 +3976,7 @@ S:Maintained L: linux-me...@vger.kernel.org L: dri-devel@lists.freedesktop.org F: drivers/dma-buf/sync_* +F: drivers/dma-buf/dma-fence* F: drivers/dma-buf/sw_sync.c F: include/linux/sync_file.h F: include/uapi/linux/sync_file.h -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 16/19] drm/vc4: Remove vc4_debugfs_cleanup()
Noralf Trønnes writes: > drm_debugfs_cleanup() now removes all minor->debugfs_list entries > automatically, so the drm_driver.debugfs_cleanup callback is not > needed. Nice! Reviewed-by: Eric Anholt signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 3/5] drm/dp/mst: change MST detection scheme
On środa, 25 stycznia 2017 12:24:35 CET Alex Deucher wrote: > On Wed, Jan 25, 2017 at 12:16 PM, Krzysztof Nowicki > > wrote: > > Hi, > > > > > > Is this patch still being considered for pulling in? > > > > Recently I've been fighting with a HP UltraSlim docking station with a MST > > hub inside in order to get it working with the amdgpu DAL/DC code. I > > couldn't get it to work until I stumbled upon this patch. Applying it > > solved the issue instantly. > > > > What I have found during debugging is that the MST hub would return SST > > sink port numbers < 8 which resulted in no EDID being retrieved and in > > turn the status of the outputs was 'disconnected'. > > Harry, > > Any chance you could re-spin this against something more recent and re-send? > > Alex Hi, I have actually investigated this problem further and noticed that it's a problem in the amdgpu DAL/DC driver, which makes an incorrect assumption about the presence of a cached EDID. The fact that it started to work was only a side-effect of this patch. I have submitted a patch to amd-gfx with what I believe is the proper fix. Regards Chris ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: make fbdev/fbcon switchable per driver?
On Fri, 27 Jan 2017 11:00:38 +0100 Gerd Hoffmann wrote: > Hi folks, > > Problem at hand: A virtual machine, equipped with two display devices, > one virtual, one physical (using pci pass-through, or kvmgt-based vgpu). > > There is no easy way for the user to configure which of the two display > devices fbcon should run on. i915 happens to win over bochs-drm or qxl, > so you can't use the emulated gfx device as text console. > > One way out would be to add a module option to each driver, to turn off > fbdev emulation. Attached patch does that for i915. > > Comments? Better ideas? The vgaarb code has a concept of a vga_default_device(), it's rather PCI-centric, but maybe better than nothing. This is typically the first VGA class code device found with I/O and MMIO enabled. If fbcon defaulted to running on the vga_default_device(), a user could select which to use by re-ordering the VM hardware. The problem isn't absent on bare metal, though re-ordering hardware isn't always as simple, or necessarily possible. The problem might run deeper there too dealing with vesafb and simplefb, as well as the more device specific drivers. Rerouting legacy resources isn't always an option, but some sort of primary selection for non-encumbered devices would be useful. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #4 from Jan Vesely --- does GIMP use OpenGL other than GEGL library? -- 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 74973] [radeonsi] Gimp OpenCL does not work
https://bugs.freedesktop.org/show_bug.cgi?id=74973 --- Comment #5 from darkbasic --- Not sure, but I don't think so. AFAIK it' only GEGL-related stuff. -- 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 96881] ViennaCL fails dense_blas-bench-opencl benchmark with doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0)
https://bugs.freedesktop.org/show_bug.cgi?id=96881 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||96881 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=96881 [Bug 96881] ViennaCL fails dense_blas-bench-opencl benchmark with doubles on AMD CYPRESS (DRM 2.43.0, LLVM 3.8.0) -- 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 80876] luxrays/slg4 hangs GPU (CEDAR)
https://bugs.freedesktop.org/show_bug.cgi?id=80876 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||80876 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=80876 [Bug 80876] luxrays/slg4 hangs GPU (CEDAR) -- 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 81896] GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests
https://bugs.freedesktop.org/show_bug.cgi?id=81896 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||81896 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=81896 [Bug 81896] GPU reset when running some "John the Ripper" (+ jumbo patch, from Git) OpenCL tests -- 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 99553] Tracker bug for runnning OpenCL applications on Clover
https://bugs.freedesktop.org/show_bug.cgi?id=99553 Jan Vesely changed: What|Removed |Added Depends on||68857 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=68857 [Bug 68857] SNU OpenCL NAS Parallel Benchmarks don't work -- 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 68857] SNU OpenCL NAS Parallel Benchmarks don't work
https://bugs.freedesktop.org/show_bug.cgi?id=68857 Jan Vesely changed: What|Removed |Added Blocks||99553 Referenced Bugs: https://bugs.freedesktop.org/show_bug.cgi?id=99553 [Bug 99553] Tracker bug for runnning OpenCL applications on Clover -- 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
