[Bug 198745] Blank screen on RX 580 with AMDGPU Display Core enabled
https://bugzilla.kernel.org/show_bug.cgi?id=198745 Kyle De'Vir (kyle.de...@mykolab.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |UNREPRODUCIBLE -- 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 199157] New: BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
https://bugzilla.kernel.org/show_bug.cgi?id=199157 Bug ID: 199157 Summary: BUG: unable to handle kernel NULL pointer dereference at Product: Drivers Version: 2.5 Kernel Version: 4.15.10 Hardware: x86-64 OS: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) Assignee: drivers_video-...@kernel-bugs.osdl.org Reporter: kyle.de...@mykolab.com Regression: No Created attachment 274831 --> https://bugzilla.kernel.org/attachment.cgi?id=274831&action=edit AMDGPU Display Core NULL pointer dereference bug Output attached. -- 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 89713] [radeon]GPU lockup in World of Tanks with gallium nine
https://bugs.freedesktop.org/show_bug.cgi?id=89713 redearth...@gmail.com changed: What|Removed |Added Attachment #114681|0 |1 is obsolete|| -- 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] [RFC] drm: rcar-du: keep temporary dtb files around during build
On Tue, Mar 20, 2018 at 9:15 PM, Laurent Pinchart wrote: > Hi Arnd, > > On Friday, 16 March 2018 10:25:25 EET Arnd Bergmann wrote: >> On Fri, Mar 16, 2018 at 2:39 AM, wrote: >> > On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote: >> >> The *.dtb and *.dtb.S files get removed by 'make' during the build >> >> process, >> >> and later seem to be missed during the 'modpost' stage: >> >> >> >> rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S >> >> WARNING: could not open >> >> drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or >> >> directory >> >> >> >> As a workaround, this adds all those files to the 'extra-y' target list, >> >> but that's really ugly. Any ideas for a better fix? >> > >> > Does this work for you (untested, but the way it is done in >> > drivers/of/unittest-data/Makefile): >> > >> > .PRECIOUS: \ >> > >> > $(obj)/%.dtb.S \ >> > $(obj)/%.dtb >> >> Yes, that works and looks much better than my version. > > Thank you for your patch, and sorry for breaking the build. Do you plan to > submit a new version based on Frank's approach ? I'm currently at Linaro Connect and won't be able to send a tested patch before mid next week. If you want it earlier, feel free to apply that patch with my original description and 'Reported-by: Arnd Bergmann '. Arnd ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] i916/gvt: throw error on unhandled vfio ioctls
On unknown/unhandled ioctls the driver should return an error, so userspace knows it tried to use something unsupported. Cc: linux-sta...@vger.kernel.org Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 021f722e24..be881d53c2 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd, } - return 0; + return -EINVAL; } static ssize_t -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: > Am 20.03.2018 um 15:08 schrieb Daniel Vetter: > > [SNIP] > > For the in-driver reservation path (CS) having a slow-path that grabs a > > temporary reference, drops the vram lock and then locks the reservation > > normally (using the acquire context used already for the entire CS) is a > > bit tricky, but totally feasible. Ttm doesn't do that though. > > That is exactly what we do in amdgpu as well, it's just not very efficient > nor reliable to retry getting the right pages for a submission over and over > again. > > > [SNIP] > > Note that there are 2 paths for i915 userptr. One is the mmu notifier, the > > other one is the root-only hack we have for dubious reasons (or that I > > really don't see the point in myself). > > Well I'm referring to i915_gem_userptr.c, if that isn't what you are > exposing then just feel free to ignore this whole discussion. They're both in i915_gem_userptr.c, somewhat interleaved. Would be interesting if you could show what you think is going wrong in there compared to amdgpu_mn.c. > > > For coherent usage you need to install some lock to prevent concurrent > > > get_user_pages(), command submission and > > > invalidate_range_start/invalidate_range_end from the MMU notifier. > > > > > > Otherwise you can't guarantee that you are actually accessing the right > > > page > > > in the case of a fork() or mprotect(). > > Yeah doing that with a full lock will create endless amounts of issues, > > but I don't see why we need that. Userspace racing stuff with itself gets > > to keep all the pieces. This is like racing DIRECT_IO against mprotect and > > fork. > > First of all I strongly disagree on that. A thread calling fork() because it > wants to run a command is not something we can forbid just because we have a > gfx stack loaded. That the video driver is not capable of handling that > correct is certainly not the problem of userspace. > > Second it's not only userspace racing here, you can get into this kind of > issues just because of transparent huge page support where the background > daemon tries to reallocate the page tables into bigger chunks. > > And if I'm not completely mistaken you can also open up quite a bunch of > security problems if you suddenly access the wrong page. I get a feeling we're talking past each another here. Can you perhaps explain what exactly the race is you're seeing? The i915 userptr code is fairly convoluted and pushes a lot of stuff to workers (but then syncs with those workers again later on), so easily possible you've overlooked one of these lines that might guarantee already what you think needs to be guaranteed. We're definitely not aiming to allow userspace to allow writing to random pages all over. > > Leaking the IOMMU mappings otoh means rogue userspace could do a bunch of > > stray writes (I don't see anywhere code in amdgpu_mn.c to unmap at least > > the gpu side PTEs to make stuff inaccessible) and wreak the core kernel's > > book-keeping. > > > > In i915 we guarantee that we call set_page_dirty/mark_page_accessed only > > after all the mappings are really gone (both GPU PTEs and sg mapping), > > guaranteeing that any stray writes from either the GPU or IOMMU will > > result in faults (except bugs in the IOMMU, but can't have it all, "IOMMU > > actually works" is an assumption behind device isolation). > Well exactly that's the point, the handling in i915 looks incorrect to me. > You need to call set_page_dirty/mark_page_accessed way before the mapping is > destroyed. > > To be more precise for userptrs it must be called from the > invalidate_range_start, but i915 seems to delegate everything into a > background worker to avoid the locking problems. Yeah, and at the end of the function there's a flush_work to make sure the worker has caught up. The set_page_dirty is also there, but hidden very deep in the call chain as part of the vma unmapping and backing storage unpinning. But I do think we guarantee what you expect needs to happen. > > > Felix and I hammered for quite some time on amdgpu until all of this was > > > handled correctly, see drivers/gpu/drm/amd/amdgpu/amdgpu_mn.c. > > Maybe we should have more shared code in this, it seems to be a source of > > endless amounts of fun ... > > > > > I can try to gather the lockdep splat from my mail history, but it > > > essentially took us multiple years to get rid of all of them. > > I'm very much interested in specifically the splat that makes it > > impossible for you folks to remove the sg mappings. That one sounds bad. > > And would essentially make mmu_notifiers useless for their primary use > > case, which is handling virtual machines where you really have to make > > sure the IOMMU mapping is gone before you claim it's gone, because there's > > no 2nd level of device checks (like GPU PTEs, or command checker) catching > > stray writes. > > Well to be more precise the problem is not that we can't
Re: [Outreachy kernel] [PATCH] drm/qxl: Replace drm_gem_object_reference/unreference() with _get/put()
On Tue, Mar 20, 2018 at 11:29:27AM -0700, Santha Meena Ramamoorthy wrote:
> Replace drm_gem_object_reference/unreference function with *_get/put()
> suffixes, because it is shorter and consistent with the kernel
> kref_get/put() functions. The following Coccinelle script was used:
>
> @@
> expression e;
> @@
>
> (
> -drm_gem_object_reference(e);
> +drm_gem_object_get(e);
> |
> -drm_gem_object_unreference(e);
> +drm_gem_object_put(e);
> |
> -drm_gem_object_unreference_unlocked(e);
> +drm_gem_object_put_unlocked(e);
> )
>
> Signed-off-by: Santha Meena Ramamoorthy
lgtm, thanks for your patch. Applied to drm-misc-next.
-Daniel
> ---
> drivers/gpu/drm/qxl/qxl_display.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_dumb.c| 2 +-
> drivers/gpu/drm/qxl/qxl_fb.c | 6 +++---
> drivers/gpu/drm/qxl/qxl_gem.c | 2 +-
> drivers/gpu/drm/qxl/qxl_ioctl.c | 4 ++--
> drivers/gpu/drm/qxl/qxl_object.c | 6 +++---
> 6 files changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_display.c
> b/drivers/gpu/drm/qxl/qxl_display.c
> index 9a9214a..ecb35ed 100644
> --- a/drivers/gpu/drm/qxl/qxl_display.c
> +++ b/drivers/gpu/drm/qxl/qxl_display.c
> @@ -309,7 +309,7 @@ void qxl_user_framebuffer_destroy(struct drm_framebuffer
> *fb)
> struct qxl_bo *bo = gem_to_qxl_bo(qxl_fb->obj);
>
> WARN_ON(bo->shadow);
> - drm_gem_object_unreference_unlocked(qxl_fb->obj);
> + drm_gem_object_put_unlocked(qxl_fb->obj);
> drm_framebuffer_cleanup(fb);
> kfree(qxl_fb);
> }
> @@ -1215,7 +1215,7 @@ qxl_user_framebuffer_create(struct drm_device *dev,
> ret = qxl_framebuffer_init(dev, qxl_fb, mode_cmd, obj, &qxl_fb_funcs);
> if (ret) {
> kfree(qxl_fb);
> - drm_gem_object_unreference_unlocked(obj);
> + drm_gem_object_put_unlocked(obj);
> return NULL;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_dumb.c b/drivers/gpu/drm/qxl/qxl_dumb.c
> index 11085ab..c666b89 100644
> --- a/drivers/gpu/drm/qxl/qxl_dumb.c
> +++ b/drivers/gpu/drm/qxl/qxl_dumb.c
> @@ -82,6 +82,6 @@ int qxl_mode_dumb_mmap(struct drm_file *file_priv,
> return -ENOENT;
> qobj = gem_to_qxl_bo(gobj);
> *offset_p = qxl_bo_mmap_offset(qobj);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return 0;
> }
> diff --git a/drivers/gpu/drm/qxl/qxl_fb.c b/drivers/gpu/drm/qxl/qxl_fb.c
> index 23af3e3..3388914 100644
> --- a/drivers/gpu/drm/qxl/qxl_fb.c
> +++ b/drivers/gpu/drm/qxl/qxl_fb.c
> @@ -95,7 +95,7 @@ static void qxlfb_destroy_pinned_object(struct
> drm_gem_object *gobj)
> qxl_bo_kunmap(qbo);
> qxl_bo_unpin(qbo);
>
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> }
>
> int qxl_get_handle_for_primary_fb(struct qxl_device *qdev,
> @@ -316,11 +316,11 @@ static int qxlfb_create(struct qxl_fbdev *qfbdev,
> qxl_bo_unpin(qbo);
> }
> if (fb && ret) {
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> drm_framebuffer_cleanup(fb);
> kfree(fb);
> }
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_gem.c b/drivers/gpu/drm/qxl/qxl_gem.c
> index 85f5467..f5c1e78 100644
> --- a/drivers/gpu/drm/qxl/qxl_gem.c
> +++ b/drivers/gpu/drm/qxl/qxl_gem.c
> @@ -98,7 +98,7 @@ int qxl_gem_object_create_with_handle(struct qxl_device
> *qdev,
> return r;
> /* drop reference from allocate - handle holds it now */
> *qobj = gem_to_qxl_bo(gobj);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_ioctl.c b/drivers/gpu/drm/qxl/qxl_ioctl.c
> index e8c0b10..e238a1a 100644
> --- a/drivers/gpu/drm/qxl/qxl_ioctl.c
> +++ b/drivers/gpu/drm/qxl/qxl_ioctl.c
> @@ -121,7 +121,7 @@ static int qxlhw_handle_to_bo(struct drm_file *file_priv,
> uint64_t handle,
> qobj = gem_to_qxl_bo(gobj);
>
> ret = qxl_release_list_add(release, qobj);
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> if (ret)
> return ret;
>
> @@ -343,7 +343,7 @@ static int qxl_update_area_ioctl(struct drm_device *dev,
> void *data,
> qxl_bo_unreserve(qobj);
>
> out:
> - drm_gem_object_unreference_unlocked(gobj);
> + drm_gem_object_put_unlocked(gobj);
> return ret;
> }
>
> diff --git a/drivers/gpu/drm/qxl/qxl_object.c
> b/drivers/gpu/drm/qxl/qxl_object.c
> index f6b80fe..e9fb0ab 100644
> --- a/drivers/gpu/drm/qxl/qxl_object.c
> +++ b/drivers/gpu/drm/qxl/qxl_object.c
> @@ -211,13 +211,13 @@ void qxl_bo_unref(struct qxl_bo **bo)
> if ((*bo) == NULL)
> return;
>
> - drm_gem_object_unreference_unlocke
Re: [PATCH 1/6] Revert "drm/atomic-helper: Fix leak in disable_all"
On Tue, Mar 20, 2018 at 09:17:52PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Currently we're leaking fbs on load detect on account of nothing setting
> up plane->old_fb for the drm_atomic_clean_old_fb() call in
> drm_atomic_helper_commit_duplicated_state(). Removing the
> drm_atomic_clean_old_fb() call seems like the right call to me here.
> This does mean we end up leaking something via
> drm_atomic_helper_shutdown() though, but we'll fix that up in a
> different way.
>
> This reverts commit 49d70aeaeca8f62b72b7712ecd1e29619a445866.
So the reason I went this way and not what you're suggesting in this patch
series is that i915 is the one and only driver noodling around with load
detect and gpu reset that needs this.
Imo it'd be better to fix up our load detect code to also set the old_fb
stuff up correctly, and add at least a long-term task to todo.rst to get
rid of all this. Inflicting a new parameter on all the other drives (like
you do in patch 2) is imo the wrong way round - we have 31 other atomic
drivers than i915.ko.
-Daniel
>
> Cc: martin.pe...@free.fr
> Cc: ch...@chris-wilson.co.uk
> Cc: Dave Airlie (v1)
> Cc: Maarten Lankhorst
> Cc: Daniel Vetter
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/drm_atomic_helper.c | 18 ++
> 1 file changed, 2 insertions(+), 16 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index c35654591c12..c48f187d08de 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -2914,7 +2914,6 @@ int drm_atomic_helper_disable_all(struct drm_device
> *dev,
> struct drm_plane *plane;
> struct drm_crtc_state *crtc_state;
> struct drm_crtc *crtc;
> - unsigned plane_mask = 0;
> int ret, i;
>
> state = drm_atomic_state_alloc(dev);
> @@ -2957,14 +2956,10 @@ int drm_atomic_helper_disable_all(struct drm_device
> *dev,
> goto free;
>
> drm_atomic_set_fb_for_plane(plane_state, NULL);
> - plane_mask |= BIT(drm_plane_index(plane));
> - plane->old_fb = plane->fb;
> }
>
> ret = drm_atomic_commit(state);
> free:
> - if (plane_mask)
> - drm_atomic_clean_old_fb(dev, plane_mask, ret);
> drm_atomic_state_put(state);
> return ret;
> }
> @@ -3095,16 +3090,11 @@ int drm_atomic_helper_commit_duplicated_state(struct
> drm_atomic_state *state,
> struct drm_connector_state *new_conn_state;
> struct drm_crtc *crtc;
> struct drm_crtc_state *new_crtc_state;
> - unsigned plane_mask = 0;
> - struct drm_device *dev = state->dev;
> - int ret;
>
> state->acquire_ctx = ctx;
>
> - for_each_new_plane_in_state(state, plane, new_plane_state, i) {
> - plane_mask |= BIT(drm_plane_index(plane));
> + for_each_new_plane_in_state(state, plane, new_plane_state, i)
> state->planes[i].old_state = plane->state;
> - }
>
> for_each_new_crtc_in_state(state, crtc, new_crtc_state, i)
> state->crtcs[i].old_state = crtc->state;
> @@ -3112,11 +3102,7 @@ int drm_atomic_helper_commit_duplicated_state(struct
> drm_atomic_state *state,
> for_each_new_connector_in_state(state, connector, new_conn_state, i)
> state->connectors[i].old_state = connector->state;
>
> - ret = drm_atomic_commit(state);
> - if (plane_mask)
> - drm_atomic_clean_old_fb(dev, plane_mask, ret);
> -
> - return ret;
> + return drm_atomic_commit(state);
> }
> EXPORT_SYMBOL(drm_atomic_helper_commit_duplicated_state);
>
> --
> 2.16.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: Reject getfb for multi-plane framebuffers
On Tue, Mar 20, 2018 at 09:01:11PM -0400, Rob Clark wrote:
> On Tue, Mar 20, 2018 at 6:58 PM, Daniel Stone wrote:
> > getfb can only return a single plane, so reject attempts to use it with
> > multi-plane framebuffers.
> >
>
> yeah, this seems like a pretty good idea,
>
> Reviewed-by: Rob Clark
>
> > Signed-off-by: Daniel Stone
> > Reported-by: Daniel van Vugt
> > Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel
> > format v5")
> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105518
Cc: sta...@vger.kernel.org # v3.3+
Reviewed-by: Daniel Vetter
Please push to drm-misc-fixes and poke Gustavo to do a pull so it's not
lost.
-Daniel
> > ---
> > drivers/gpu/drm/drm_framebuffer.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_framebuffer.c
> > b/drivers/gpu/drm/drm_framebuffer.c
> > index 7df025669067..ad67203de715 100644
> > --- a/drivers/gpu/drm/drm_framebuffer.c
> > +++ b/drivers/gpu/drm/drm_framebuffer.c
> > @@ -462,6 +462,12 @@ int drm_mode_getfb(struct drm_device *dev,
> > if (!fb)
> > return -ENOENT;
> >
> > + /* Multi-planar framebuffers need getfb2. */
> > + if (fb->format->num_planes > 1) {
> > + ret = -EINVAL;
> > + goto out;
> > + }
> > +
> > r->height = fb->height;
> > r->width = fb->width;
> > r->depth = fb->format->depth;
> > @@ -485,6 +491,7 @@ int drm_mode_getfb(struct drm_device *dev,
> > ret = -ENODEV;
> > }
> >
> > +out:
> > drm_framebuffer_put(fb);
> >
> > return ret;
> > --
> > 2.16.2
> >
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote: > Am 20.03.2018 um 15:08 schrieb Daniel Vetter: > > [SNIP] > > For the in-driver reservation path (CS) having a slow-path that grabs a > > temporary reference, drops the vram lock and then locks the reservation > > normally (using the acquire context used already for the entire CS) is a > > bit tricky, but totally feasible. Ttm doesn't do that though. > > That is exactly what we do in amdgpu as well, it's just not very efficient > nor reliable to retry getting the right pages for a submission over and over > again. Out of curiosity, where's that code? I did read the ttm eviction code way back, and that one definitely didn't do that. Would be interesting to update my understanding. -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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #65 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Hi IOMMU is disabled: root@qt5122:~# ls /sys/class/iommu ls: cannot access '/sys/class/iommu': No such file or directory root@qt5122:~# dmesg | grep -i iommu root@qt5122:~# -- 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 RESEND v2 1/2] drm/xen-front: Add support for Xen PV display frontend
On 03/20/2018 03:47 PM, Daniel Vetter wrote: On Tue, Mar 20, 2018 at 01:58:01PM +0200, Oleksandr Andrushchenko wrote: On 03/19/2018 05:28 PM, Daniel Vetter wrote: There should be no difference between immediate removal and delayed removal of the drm_device from the xenbus pov. The lifetimes of the front-end (drm_device) and backend (the xen bus thing) are entirely decoupled: Well, they are not decoupled for simplicity of handling, please see below So for case 2 you only have 1 case: - drm_dev_unplug - tear down the entire xenbus backend completely - all xenbus access will be caught with drm_dev_entre/exit (well right now drm_dev_is_unplugged) checks, including any access to your private drm_device data - once drm_device->open_count == 0 the core will tear down the drm_device instance and call your optional drm_driver->release callback. So past drm_dev_unplug the drm_device is in zombie state and the only thing that will happen is a) it rejects all ioctls and anything else userspace might ask it to do and b) gets releases once the last userspace reference is gone. I have re-worked the driver with this in mind [1] So, I now use drm_dev_unplug and destroy the DRM device on drm_driver.release. In context of unplug work I also merged xen_drm_front_drv.c and xen_drm_front.c as these are too coupled together now. Could you please take a look and tell me if this is what you mean? If the backend comes up again, you create a _new_ drm_device instance (while the other one is still in the process of eventually getting released). We only have a single xenbus instance, so this way I'll need to handle list of such zombies. For that reason I prefer to wait until the DRM device is destroyed, telling the backend to hold on until then (via going into XenbusStateReconfiguring state). Why exactly do you need to keep track of your drm_devices from the xenbus? Once unplugged, there should be no connection with the "hw" for your device, in neither direction. Maybe I need to look again, but this still smells funny and not like something you should ever do. Ok, probably new reworked code will make things cleaner and answer your concerns. I also removed some obsolete stuff, e.g. platform device, so this path became even cleaner now ;) Another drawback of such approach is that I'll have different minors at run-time, e.g. card0, card1, etc. For software which has /dev/dri/card0 hardcoded it may be a problem. But this is minor, IMO Fix userspace :-) But yeah unlikely this is a problem, hotplugging is fairly old thing. In short, your driver code should never have a need to look at drm_device->open_count. I hope this explains it a bit better. -Daniel Yes, you are correct: at [1] I am not touching drm_device->open_count anymore and everything just happens synchronously [1] https://github.com/andr2000/linux/commits/drm_tip_pv_drm_v3 Please just resend, makes it easier to comment inline. I need to wait for Xen community reviewers before resending, so this is why I hoped you can take a look before that, so I have a chance to address more of your comments in v4 -Daniel Thank you, Oleksandr ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2] drm/i915/gvt: throw error on unhandled vfio ioctls
On unknown/unhandled ioctls the driver should return an error, so userspace knows it tried to use something unsupported. Cc: sta...@vger.kernel.org Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 021f722e24..be881d53c2 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd, } - return 0; + return -EINVAL; } static ssize_t -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
linux-next: Signed-off-by missing for commits in the drm tree
Hi all,
A series of commits
a82f034765fa ("drm: omapdrm: Split init and cleanup from probe and remove
functions")
to
663ac57b285d ("drm: omapdrm: venc: Allocate the venc private data structure
dynamically")
are missing a Signed-off-by from their commiter.
--
Cheers,
Stephen Rothwell
pgp5NFbWDapHi.pgp
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/2] dma-mapping: move dma configuration to bus infrastructure
On Wed, Mar 21, 2018 at 12:25:22PM +0530, Nipun Gupta wrote:
> It's bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces '/dma_configure/' as bus callback
> giving flexibility to busses for implementing its own dma
> configuration function.
>
> The change eases the addition of new busses w.r.t. adding the dma
> configuration functionality.
>
> This patch also updates the PCI, Platform, ACPI and host1x bus to
> use new introduced callbacks.
>
> Suggested-by: Christoph Hellwig
> Signed-off-by: Nipun Gupta
> ---
> - The patches are based on the comments on:
>https://patchwork.kernel.org/patch/10259087/
>
> Changes in v2:
> - Do not have dma_deconfigure callback
> - Have '/dma_common_configure/' API to provide a common DMA
> configuration which can be used by busses if it suits them.
> - Platform and ACPI bus to use '/dma_common_configure/' in
> '/dma_configure/' callback.
> - Updated commit message
> - Updated pci_dma_configure API with changes suggested by Robin
>
> drivers/amba/bus.c | 7 +++
> drivers/base/dma-mapping.c | 35 +++
> drivers/base/platform.c | 6 ++
> drivers/gpu/host1x/bus.c| 9 +
> drivers/pci/pci-driver.c| 32
> include/linux/device.h | 4
> include/linux/dma-mapping.h | 1 +
> 7 files changed, 74 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 594c228..2fa1e8b 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -20,6 +20,7 @@
> #include
> #include
> #include
> +#include
>
> #include
>
> @@ -171,6 +172,11 @@ static int amba_pm_runtime_resume(struct device *dev)
> }
> #endif /* CONFIG_PM */
>
> +static int amba_dma_configure(struct device *dev)
> +{
> + return dma_common_configure(dev);
> +}
> +
> static const struct dev_pm_ops amba_pm = {
> .suspend= pm_generic_suspend,
> .resume = pm_generic_resume,
> @@ -194,6 +200,7 @@ struct bus_type amba_bustype = {
> .dev_groups = amba_dev_groups,
> .match = amba_match,
> .uevent = amba_uevent,
> + .dma_configure = amba_dma_configure,
> .pm = &amba_pm,
> .force_dma = true,
> };
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 3b11835..48f9af0 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -331,38 +331,33 @@ void dma_common_free_remap(void *cpu_addr, size_t size,
> unsigned long vm_flags)
> #endif
>
> /*
> - * Common configuration to enable DMA API use for a device
> + * Common configuration to enable DMA API use for a device.
> + * A bus can use this function in its 'dma_configure' callback, if
> + * suitable for the bus.
> */
> -#include
> -
> -int dma_configure(struct device *dev)
> +int dma_common_configure(struct device *dev)
> {
> - struct device *bridge = NULL, *dma_dev = dev;
> enum dev_dma_attr attr;
> int ret = 0;
>
> - if (dev_is_pci(dev)) {
> - bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> - dma_dev = bridge;
> - if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> - dma_dev->parent->of_node)
> - dma_dev = dma_dev->parent;
> - }
> -
> - if (dma_dev->of_node) {
> - ret = of_dma_configure(dev, dma_dev->of_node);
> - } else if (has_acpi_companion(dma_dev)) {
> - attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
> if (attr != DEV_DMA_NOT_SUPPORTED)
> ret = acpi_dma_configure(dev, attr);
> }
>
> - if (bridge)
> - pci_put_host_bridge_device(bridge);
> -
> return ret;
> }
>
> +int dma_configure(struct device *dev)
> +{
> + if (dev->bus->dma_configure)
> + return dev->bus->dma_configure(dev);
> +
> + return 0;
> +}
> void dma_deconfigure(struct device *dev)
Empty line after this new function? Sorry, couldn't help it :)
> {
> of_dma_deconfigure(dev);
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f1bf7b3..d2d5891 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1130,6 +1130,11 @@ int platform_pm_restore(struct device *dev)
>
> #endif /* CONFIG_HIBERNATE_CALLBACKS */
>
> +static int platform_dma_configure(struct device *dev)
> +{
> + return dma_common_configure(dev);
> +}
> +
> static const struct dev_pm_ops platform_dev_pm_ops = {
> .runtime_suspend = pm_generic_runtime_suspend,
> .runtime_resume = pm_generic_runtime_resume,
> @@ -
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
Am 21.03.2018 um 09:18 schrieb Daniel Vetter:
[SNIP]
They're both in i915_gem_userptr.c, somewhat interleaved. Would be
interesting if you could show what you think is going wrong in there
compared to amdgpu_mn.c.
i915 implements only one callback:
static const struct mmu_notifier_ops i915_gem_userptr_notifier = {
.invalidate_range_start =
i915_gem_userptr_mn_invalidate_range_start,
};
For correct operation you always need to implement invalidate_range_end
as well and add some lock/completion work Otherwise get_user_pages() can
again grab the reference to the wrong page.
The next problem seems to be that cancel_userptr() doesn't prevent any
new command submission. E.g.
i915_gem_object_wait(obj, I915_WAIT_ALL, MAX_SCHEDULE_TIMEOUT, NULL);
What prevents new command submissions to use the GEM object directly
after you finished waiting here?
I get a feeling we're talking past each another here.
Yeah, agree. Additional to that I don't know the i915 code very well.
Can you perhaps explain what exactly the race is you're seeing? The i915
userptr code is
fairly convoluted and pushes a lot of stuff to workers (but then syncs
with those workers again later on), so easily possible you've overlooked
one of these lines that might guarantee already what you think needs to be
guaranteed. We're definitely not aiming to allow userspace to allow
writing to random pages all over.
You not read/write to random pages, there still is a reference to the
page. So that the page can't be reused until you are done.
The problem is rather that you can't guarantee that you write to the
page which is mapped into the process at that location. E.g. the CPU and
the GPU might see two different things.
Leaking the IOMMU mappings otoh means rogue userspace could do a bunch of
stray writes (I don't see anywhere code in amdgpu_mn.c to unmap at least
the gpu side PTEs to make stuff inaccessible) and wreak the core kernel's
book-keeping.
In i915 we guarantee that we call set_page_dirty/mark_page_accessed only
after all the mappings are really gone (both GPU PTEs and sg mapping),
guaranteeing that any stray writes from either the GPU or IOMMU will
result in faults (except bugs in the IOMMU, but can't have it all, "IOMMU
actually works" is an assumption behind device isolation).
Well exactly that's the point, the handling in i915 looks incorrect to me.
You need to call set_page_dirty/mark_page_accessed way before the mapping is
destroyed.
To be more precise for userptrs it must be called from the
invalidate_range_start, but i915 seems to delegate everything into a
background worker to avoid the locking problems.
Yeah, and at the end of the function there's a flush_work to make sure the
worker has caught up.
Ah, yes haven't seen that.
But then grabbing the obj->base.dev->struct_mutex lock in
cancel_userptr() is rather evil. You just silenced lockdep because you
offloaded that into a work item.
So no matter how you put it i915 is clearly doing something wrong here :)
I know. i915 gem has tons of fallbacks and retry loops (we restart the
entire CS if needed), and i915 userptr pushes the entire get_user_pages
dance off into a worker if the fastpath doesn't succeed and we run out of
memory or hit contended locks. We also have obscene amounts of
__GFP_NORETRY and __GFP_NOWARN all over the place to make sure the core mm
code doesn't do something we don't want it do to do in the fastpaths
(because there's really no point in spending lots of time trying to make
memory available if we have a slowpath fallback with much less
constraints).
Well I haven't audited the code, but I'm pretty sure that just mitigates
the problem and silenced lockdep instead of really fixing the issue.
We're also not limiting ourselves to GFP_NOIO, but instead have a
recursion detection&handling in our own shrinker callback to avoid these
deadlocks.
Which if you ask me is absolutely horrible. I mean the comment in
linux/mutex.h sums it up pretty well:
* This function should not be used, _ever_. It is purely for
hysterical GEM
* raisins, and once those are gone this will be removed.
Regards,
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105651] Vega64 doesn't output properly onto dell up2715k at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=105651 spgle...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=99801 -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote: > With each bus implementing its own DMA configuration callback, > there is no need for bus to explicitly have force_dma in its > global structure. This patch modifies of_dma_configure API to > accept an input parameter which specifies if implicit DMA > configuration is required even when it is not described by the > firmware. Having to "remember" what that bool variable means on the end of the function call is a royal pain over time, right? Why not just create a new function: dma_common_configure_force(dma) that always does this? Leave "dma_common_configure()" alone, and then wrap the old code with these two helper functions that call the 'core' code with the bool set properly? That way you do not have to "know" what that parameter is, the function name just documents it automatically, so when you see it in the bus-specific code, no need to go and have to hunt for anything. And if you are reading the dma core code, it's obvious what is happening as the functions are all right there. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105651] Vega64 doesn't output properly onto dell up2715k at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=105651 Bug ID: 105651 Summary: Vega64 doesn't output properly onto dell up2715k at 5120x2880 Product: DRI Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: spgle...@gmail.com I have tested 4.16 and drm-next-4.17 both under wayland and xorg. All only show the monitor as 2 displays with 2560x2880 side by side. (I previously had an nvidia gpu using their binary blob on this display without issue) -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 99801] Rx480 doesn't output properly onto z27q at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=99801 spgle...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105651 -- 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 105651] Vega64 doesn't output properly onto dell up2715k at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=105651 spgle...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=105198 -- 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 105651] Vega64 doesn't output properly onto dell up2715k at 5120x2880
https://bugs.freedesktop.org/show_bug.cgi?id=105651 spgle...@gmail.com changed: What|Removed |Added See Also||https://bugs.freedesktop.or ||g/show_bug.cgi?id=97244 -- 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 105619] Kernel DC oops on dce81_create_resource_pool with kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105619 --- Comment #4 from freedesk...@kp-tech.hu --- Created attachment 138236 --> https://bugs.freedesktop.org/attachment.cgi?id=138236&action=edit Xorg log when using the 4.15 kernel Thank you for your help! Sorry for the delay, the Xorg log attached I use the 4.15 kernel. The motherboard is an ASUS A88XM-A, from this page (it has a picture about the connectors direct url may or may not work): https://www.asus.com/Motherboards/A88XMA/ Direct link: https://www.asus.com/websites/global/products/zDRJFj2HfjDphY4C/line.jpg I have a monitor (AL2623W) connected to DVI-D and a projector (usually turned off) connected to the VGA connector. -- 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 105619] Kernel DC oops on dce81_create_resource_pool with kernel 4.15
https://bugs.freedesktop.org/show_bug.cgi?id=105619 --- Comment #5 from freedesk...@kp-tech.hu --- Created attachment 138237 --> https://bugs.freedesktop.org/attachment.cgi?id=138237&action=edit Xorg log when running on kernel 4.13 (ubuntu) Here is the Xorg log when running on kernel 4.13. it has the following lines in the log lines when the output is enumerated: [26.851] (II) AMDGPU(0): glamor detected, initialising EGL layer. [26.851] (II) AMDGPU(0): KMS Pageflipping: enabled [26.899] (II) AMDGPU(0): Output DVI-D-0 has no monitor section [26.900] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section [26.961] (II) AMDGPU(0): Output VGA-0 has no monitor section [26.995] (II) AMDGPU(0): EDID for output DVI-D-0 running on kernel 4.15 the output enumeration log entries looks like this: [23.921] (II) AMDGPU(0): glamor detected, initialising EGL layer. [23.921] (II) AMDGPU(0): KMS Pageflipping: enabled [23.921] (II) AMDGPU(0): Output DVI-D-0 has no monitor section [23.921] (II) AMDGPU(0): Output HDMI-A-0 has no monitor section [23.923] (II) AMDGPU(0): EDID for output DVI-D-0 Thanks for your help! -- 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/vmwgfx: Fix black screen and device errors when running without fbdev
When we are running without fbdev, transitioning from the login screen to
X or gnome-shell/wayland will cause a vt switch and the driver will disable
svga mode, losing all modesetting resources. However, the kms atomic state
does not reflect that and may think that a crtc is still turned on, which
will cause device errors when we try to bind an fb to the crtc, and the
screen will remain black.
Fix this by turning off all kms resources before disabling svga mode.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 13 +
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 11 +++
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 -
4 files changed, 25 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
index 184340d486c3..86d25f18aa99 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.c
@@ -1337,6 +1337,19 @@ static void __vmw_svga_disable(struct vmw_private
*dev_priv)
*/
void vmw_svga_disable(struct vmw_private *dev_priv)
{
+ /*
+* Disabling SVGA will turn off device modesetting capabilities, so
+* notify KMS about that so that it doesn't cache atomic state that
+* isn't valid anymore, for example crtcs turned on.
+* Strictly we'd want to do this under the SVGA lock (or an SVGA mutex),
+* but vmw_kms_lost_device() takes the reservation sem and thus we'll
+* end up with lock order reversal. Thus, a master may actually perform
+* a new modeset just after we call vmw_kms_lost_device() and race with
+* vmw_svga_disable(), but that should at worst cause atomic KMS state
+* to be inconsistent with the device, causing modesetting problems.
+*
+*/
+ vmw_kms_lost_device(dev_priv->dev);
ttm_write_lock(&dev_priv->reservation_sem, false);
spin_lock(&dev_priv->svga_lock);
if (dev_priv->bdev.man[TTM_PL_VRAM].use_type) {
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
index d08753e8fd94..9116fe8baebc 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
@@ -938,6 +938,7 @@ int vmw_kms_present(struct vmw_private *dev_priv,
int vmw_kms_update_layout_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void vmw_kms_legacy_hotspot_clear(struct vmw_private *dev_priv);
+void vmw_kms_lost_device(struct drm_device *dev);
int vmw_dumb_create(struct drm_file *file_priv,
struct drm_device *dev,
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index ead61015cd79..b3d62aa01a9b 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -2851,3 +2851,14 @@ int vmw_kms_set_config(struct drm_mode_set *set,
return drm_atomic_helper_set_config(set, ctx);
}
+
+
+/**
+ * vmw_kms_lost_device - Notify kms that modesetting capabilities will be lost
+ *
+ * @dev: Pointer to the drm device
+ */
+void vmw_kms_lost_device(struct drm_device *dev)
+{
+ drm_atomic_helper_shutdown(dev);
+}
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index cd9da2dd79af..948362c43c73 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -439,5 +439,4 @@ int vmw_kms_stdu_dma(struct vmw_private *dev_priv,
int vmw_kms_set_config(struct drm_mode_set *set,
struct drm_modeset_acquire_ctx *ctx);
-
#endif
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/vmwgfx: Fix a destoy-while-held mutex problem.
When validating legacy surfaces, the backup bo might be destroyed at
surface validate time. However, the kms resource validation code may have
the bo reserved, so we will destroy a locked mutex. While there shouldn't
be any other users of that mutex when it is destroyed, it causes a lock
leak and thus throws a lockdep error.
Fix this by having the kms resource validation code hold a reference to
the bo while we have it reserved. We do this by introducing a validation
context which might come in handy when the kms code is extended to validate
multiple resources or buffers.
Cc:
Signed-off-by: Thomas Hellstrom
Reviewed-by: Brian Paul
Reviewed-by: Sinclair Yeh
---
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 28 +++-
drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 12 +---
drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c | 5 +++--
drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c | 5 +++--
4 files changed, 34 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
index b3d62aa01a9b..3c824fd7cbf3 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.c
@@ -31,7 +31,6 @@
#include
#include
-
/* Might need a hrtimer here? */
#define VMWGFX_PRESENT_RATE ((HZ / 60 > 0) ? HZ / 60 : 1)
@@ -2517,9 +2516,12 @@ void vmw_kms_helper_buffer_finish(struct vmw_private
*dev_priv,
* Helper to be used if an error forces the caller to undo the actions of
* vmw_kms_helper_resource_prepare.
*/
-void vmw_kms_helper_resource_revert(struct vmw_resource *res)
+void vmw_kms_helper_resource_revert(struct vmw_validation_ctx *ctx)
{
- vmw_kms_helper_buffer_revert(res->backup);
+ struct vmw_resource *res = ctx->res;
+
+ vmw_kms_helper_buffer_revert(ctx->buf);
+ vmw_dmabuf_unreference(&ctx->buf);
vmw_resource_unreserve(res, false, NULL, 0);
mutex_unlock(&res->dev_priv->cmdbuf_mutex);
}
@@ -2536,10 +2538,14 @@ void vmw_kms_helper_resource_revert(struct vmw_resource
*res)
* interrupted by a signal.
*/
int vmw_kms_helper_resource_prepare(struct vmw_resource *res,
- bool interruptible)
+ bool interruptible,
+ struct vmw_validation_ctx *ctx)
{
int ret = 0;
+ ctx->buf = NULL;
+ ctx->res = res;
+
if (interruptible)
ret = mutex_lock_interruptible(&res->dev_priv->cmdbuf_mutex);
else
@@ -2558,6 +2564,8 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource
*res,
res->dev_priv->has_mob);
if (ret)
goto out_unreserve;
+
+ ctx->buf = vmw_dmabuf_reference(res->backup);
}
ret = vmw_resource_validate(res);
if (ret)
@@ -2565,7 +2573,7 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource
*res,
return 0;
out_revert:
- vmw_kms_helper_buffer_revert(res->backup);
+ vmw_kms_helper_buffer_revert(ctx->buf);
out_unreserve:
vmw_resource_unreserve(res, false, NULL, 0);
out_unlock:
@@ -2581,11 +2589,13 @@ int vmw_kms_helper_resource_prepare(struct vmw_resource
*res,
* @out_fence: Optional pointer to a fence pointer. If non-NULL, a
* ref-counted fence pointer is returned here.
*/
-void vmw_kms_helper_resource_finish(struct vmw_resource *res,
-struct vmw_fence_obj **out_fence)
+void vmw_kms_helper_resource_finish(struct vmw_validation_ctx *ctx,
+ struct vmw_fence_obj **out_fence)
{
- if (res->backup || out_fence)
- vmw_kms_helper_buffer_finish(res->dev_priv, NULL, res->backup,
+ struct vmw_resource *res = ctx->res;
+
+ if (ctx->buf || out_fence)
+ vmw_kms_helper_buffer_finish(res->dev_priv, NULL, ctx->buf,
out_fence, NULL);
vmw_resource_unreserve(res, false, NULL, 0);
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
index 948362c43c73..3d2ca280eaa7 100644
--- a/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
+++ b/drivers/gpu/drm/vmwgfx/vmwgfx_kms.h
@@ -240,6 +240,11 @@ struct vmw_display_unit {
int set_gui_y;
};
+struct vmw_validation_ctx {
+ struct vmw_resource *res;
+ struct vmw_dma_buffer *buf;
+};
+
#define vmw_crtc_to_du(x) \
container_of(x, struct vmw_display_unit, crtc)
#define vmw_connector_to_du(x) \
@@ -296,9 +301,10 @@ void vmw_kms_helper_buffer_finish(struct vmw_private
*dev_priv,
struct drm_vmw_fence_rep __user *
user_fence_rep);
int vmw_kms_helper_resource_prepare(struct vmw_resource *res,
- bool interruptible);
-void vmw_kms_helper_resource_revert(struct vmw_resource *res);
-void vmw_kms_helper_resource_finish(struct vmw_resource *res,
+
Re: [PATCH] [RFC] drm: rcar-du: keep temporary dtb files around during build
Hi Arnd, On Wednesday, 21 March 2018 09:38:35 EET Arnd Bergmann wrote: > On Tue, Mar 20, 2018 at 9:15 PM, Laurent Pinchart wrote: > > On Friday, 16 March 2018 10:25:25 EET Arnd Bergmann wrote: > >> On Fri, Mar 16, 2018 at 2:39 AM, wrote: > >>> On Thursday, March 15, 2018 8:37 AM, Arnd Bergmann wrote: > The *.dtb and *.dtb.S files get removed by 'make' during the build > process, and later seem to be missed during the 'modpost' stage: > > rm drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7791.dtb.S > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7795.dtb.S > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7796.dtb.S > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7793.dtb.S > WARNING: could not open > drivers/gpu/drm/rcar-du/rcar_du_of_lvds_r8a7790.dtb.S: No such file or > directory > > As a workaround, this adds all those files to the 'extra-y' target > list, but that's really ugly. Any ideas for a better fix? > >>> > >>> Does this work for you (untested, but the way it is done in > >>> drivers/of/unittest-data/Makefile): > >>> > >>> .PRECIOUS: \ > >>> $(obj)/%.dtb.S \ > >>> $(obj)/%.dtb > >> > >> Yes, that works and looks much better than my version. > > > > Thank you for your patch, and sorry for breaking the build. Do you plan to > > submit a new version based on Frank's approach ? > > I'm currently at Linaro Connect and won't be able to send a tested patch > before mid next week. If you want it earlier, feel free to apply that patch > with my original description and 'Reported-by: Arnd Bergmann > '. I was about to do so, but realized I can't reproduce the problem here. If you don't mind I'll let you submit a v2. Alternatively I can work on it if you give me instruction to reproduce the issue. -- Regards, Laurent Pinchart ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 1/6] drm/omap: Allocate drm_device earlier and unref it as last step
If we allocate the drm_device earlier we can just return the error code
without the need to use goto.
Do the unref of the drm_device as a last step when cleaning up. This will
make the drm_device available longer for us and makes sure that we only
free up the memory when all other cleanups have been already done.
Signed-off-by: Peter Ujfalusi
Reviewed-by: Laurent Pinchart
---
drivers/gpu/drm/omapdrm/omap_drv.c | 29 +
1 file changed, 13 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index ef3b0e3571ec..aeef9e8e6932 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -530,6 +530,14 @@ static int omapdrm_init(struct omap_drm_private *priv,
struct device *dev)
priv->dispc = dispc_get_dispc(priv->dss);
priv->dispc_ops = dispc_get_ops(priv->dss);
+ /* Allocate and initialize the DRM device. */
+ ddev = drm_dev_alloc(&omap_drm_driver, priv->dev);
+ if (IS_ERR(ddev))
+ return PTR_ERR(ddev);
+
+ priv->ddev = ddev;
+ ddev->dev_private = priv;
+
omap_crtc_pre_init(priv);
ret = omap_connect_dssdevs();
@@ -543,16 +551,6 @@ static int omapdrm_init(struct omap_drm_private *priv,
struct device *dev)
spin_lock_init(&priv->list_lock);
INIT_LIST_HEAD(&priv->obj_list);
- /* Allocate and initialize the DRM device. */
- ddev = drm_dev_alloc(&omap_drm_driver, priv->dev);
- if (IS_ERR(ddev)) {
- ret = PTR_ERR(ddev);
- goto err_destroy_wq;
- }
-
- priv->ddev = ddev;
- ddev->dev_private = priv;
-
/* Get memory bandwidth limits */
if (priv->dispc_ops->get_memory_bandwidth_limit)
priv->max_bandwidth =
@@ -563,7 +561,7 @@ static int omapdrm_init(struct omap_drm_private *priv,
struct device *dev)
ret = omap_modeset_init(ddev);
if (ret) {
dev_err(priv->dev, "omap_modeset_init failed: ret=%d\n", ret);
- goto err_free_drm_dev;
+ goto err_gem_deinit;
}
/* Initialize vblank handling, start with all CRTCs disabled. */
@@ -599,14 +597,13 @@ static int omapdrm_init(struct omap_drm_private *priv,
struct device *dev)
err_cleanup_modeset:
drm_mode_config_cleanup(ddev);
omap_drm_irq_uninstall(ddev);
-err_free_drm_dev:
+err_gem_deinit:
omap_gem_deinit(ddev);
- drm_dev_unref(ddev);
-err_destroy_wq:
destroy_workqueue(priv->wq);
omap_disconnect_dssdevs();
err_crtc_uninit:
omap_crtc_pre_uninit();
+ drm_dev_unref(ddev);
return ret;
}
@@ -630,12 +627,12 @@ static void omapdrm_cleanup(struct omap_drm_private *priv)
omap_drm_irq_uninstall(ddev);
omap_gem_deinit(ddev);
- drm_dev_unref(ddev);
-
destroy_workqueue(priv->wq);
omap_disconnect_dssdevs();
omap_crtc_pre_uninit();
+
+ drm_dev_unref(ddev);
}
static int pdev_probe(struct platform_device *pdev)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/6] drm/omap: Module parameter for display order configuration
Hi, Changes since v1: - rebased it on drm-next - Dropped the devm_kzalloc conversion patch Changes since RFC: - Comments from Laurent have been addressed: - Get alias ID once and store it for later use in sorting - Commit message updated for 'drm/omap: Manage the usable omap_dss_device list within omap_drm_private' patch - I have kept the first patch to convert to use devm_kzalloc for the private struct as I still think it is as correct as the way Laurent is proposing. The series adds support for changing the order of the displays defined by DT display aliases. The motivation to do such a thing is that for example the fb emulation is treating the first display/crtc as the 'main' display and will create the fb emulation based on the first display's properties. There are many custom applications using DRM directly and they assume that the first connector is the 'main' display. Afaik weston provides no means either to change the 'main/preferred' display. It should be the work of user space application (except the fb emulation) to somehow deal with the 'main' display selection for their needs, but unfortunately they are not capable of diong so for some reason. We have boards with LCD panel and HDMI for example and in DT the LCD is set as display0, but in certain useage scenarios it is desired to have the HDMI as the 'main' display instead of the LCD. With the kernel cmd line parameter it is possible to change the pre defined order without recompiling the kernel/DT. If the board have two active displays: 0 - LCD 1 - HDMI then: omapdrm.displays=0,1 - represents the original order (LCD, HDMI) omapdrm.displays=1,0 - represents reverse order (HDMI, LCD) omapdrm.displays=0 - only the LCD is enabled omapdrm.displays=1 - only the HDMI is enabled omapdrm.displays=-1 - disable all displays The first 6 patch of the series is doing some generic clean up and prepares the code so the display ordering is going to be easy to add. Regards, Peter --- Peter Ujfalusi (6): drm/omap: Allocate drm_device earlier and unref it as last step drm/omap: Manage the usable omap_dss_device list within omap_drm_private drm/omap: Separate the dssdevs array setup from the connect function drm/omap: Do dss_device (display) ordering in omap_drv.c drm/omap: dss: Remove display ordering from dss/display.c drm/omap: Add kernel parameter to specify the desired display order drivers/gpu/drm/omapdrm/dss/display.c | 15 +-- drivers/gpu/drm/omapdrm/dss/omapdss.h | 3 +- drivers/gpu/drm/omapdrm/omap_drv.c| 225 +- drivers/gpu/drm/omapdrm/omap_drv.h| 3 + 4 files changed, 176 insertions(+), 70 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 4/6] drm/omap: Do dss_device (display) ordering in omap_drv.c
Sort the dssdev array based on DT aliases.
With this change we can remove the panel ordering from dss/display.c and
have all sorting related to dssdevs in one place.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/display.c | 2 ++
drivers/gpu/drm/omapdrm/dss/omapdss.h | 1 +
drivers/gpu/drm/omapdrm/omap_drv.c| 18 ++
3 files changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
b/drivers/gpu/drm/omapdrm/dss/display.c
index 424143128cd4..3ef99f344bd3 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -52,6 +52,8 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
if (id < 0)
id = disp_num_counter++;
+ dssdev->alias_id = id;
+
snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
/* Use 'label' property for name, if it exists */
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index 14d74adb13fb..d1056d0d32c2 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -467,6 +467,7 @@ struct omap_dss_device {
/* alias in the form of "display%d" */
char alias[16];
+ int alias_id;
enum omap_display_type type;
enum omap_display_type output_type;
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 2cd2349622a9..65666e946799 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -15,6 +15,8 @@
* this program. If not, see
[PATCH v5 0/6] drm: zpos normalization cleanup and omapdrm to use it
Hi, Changes since v4: - rebased the series on drm-next NOTE on the tegra patch: since the v4 series the atomic check of tegra got additional call to tegra_display_hub_atomic_check(). Based on the code the order, placement of the hub check is not strict, it can be done as the last step as well. But if the hub check needs to be called in certain step, then I can drop the tegra patch. Changes since v3: - Moved the new normalize_zpos bool to be around another bools - Extended the commit message for sti that the drm_atomic_helper_check() is going to ask for async_update due to the legacy cursor usage. Changes since v2: - Fixed commit messages (s/drm_device/drm_mode_config) - Added ack from Benjamin Gaignard to drm/sti patch Changes since v1: - normalize_zpos flag moved to drm_mode_config - Added comment to note the side effect of normalization and updated the comment for normalized_zpos in the header file as well. - Added Acked-by from Daniel to patch 2-6 but not for patch 1 as I'm not sure if the comments I have added matches with what is expected to be. The first patch is adding a flag to drm_device that drivers can set if they want the zpos to be normalized. Then convert exynos, tegra, sti and rcar-du to use this flag instead of re-implementing the drm_atomic_helper_check() locally just to add the call to drm_atomic_normalize_zpos(). The last patch is moving omapdrm to use the zpos normalization as well to comply with the UAPI documentation regarding to zpos. Laurent's note in an earlier thread: https://marc.info/?l=dri-devel&m=151567355225029&w=2 "The problem is that zpos normalization requires accessing the state of all enabled planes for a CRTC in order to compute (and store) the normalized zpos values. This thus forces all planes to be added to the commit state, even when the commit doesn't touch the zpos property. I assume this caused issues (possibly performance issues) in drivers that then performed hardware setup of all planes as a result." can be addressed later in the core for all users of drm_atomic_normalize_zpos() Regards, Peter --- Peter Ujfalusi (6): drm: Add drm_mode_config->normalize_zpos boolean drm/exynos: Let core take care of normalizing the zpos drm/tegra: Let core take care of normalizing the zpos drm/sti: Let core take care of normalizing the zpos drm: rcar-du: Let core take care of normalizing the zpos drm/omap: Use normalized zpos for plane placement drivers/gpu/drm/drm_atomic_helper.c | 11 +++ drivers/gpu/drm/exynos/exynos_drm_drv.c | 20 drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 - drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ drivers/gpu/drm/omapdrm/omap_plane.c| 2 +- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++- drivers/gpu/drm/sti/sti_drv.c | 24 +++- drivers/gpu/drm/tegra/drm.c | 21 - include/drm/drm_mode_config.h | 8 include/drm/drm_plane.h | 4 ++-- 11 files changed, 37 insertions(+), 72 deletions(-) -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 3/6] drm/tegra: Let core take care of normalizing the zpos
Set the drm_mode_config->normalize_zpos and call the generic
drm_atomic_helper_check() instead of duplicating it within
tegra_atomic_check().
Call tegra_display_hub_atomic_check() after the drm_atomic_helpre_check()
returned without error.
Signed-off-by: Peter Ujfalusi
CC: Thierry Reding
---
Thierry,
since the v4 series the atomic check of tegra got additional call to
tegra_display_hub_atomic_check().
Based on the code the order, placement of the hub check is not strict, it can
be done as the last step as well.
But if the hub check needs to be called in certain step, then I can drop the
tegra patch.
Can you check if this patch is OK or not?
Regards,
Peter
drivers/gpu/drm/tegra/drm.c | 21 -
1 file changed, 4 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
index e20e013151f0..ac1121172dc9 100644
--- a/drivers/gpu/drm/tegra/drm.c
+++ b/drivers/gpu/drm/tegra/drm.c
@@ -38,26 +38,11 @@ static int tegra_atomic_check(struct drm_device *drm,
{
int err;
- err = drm_atomic_helper_check_modeset(drm, state);
+ err = drm_atomic_helper_check(drm, state);
if (err < 0)
return err;
- err = tegra_display_hub_atomic_check(drm, state);
- if (err < 0)
- return err;
-
- err = drm_atomic_normalize_zpos(drm, state);
- if (err < 0)
- return err;
-
- err = drm_atomic_helper_check_planes(drm, state);
- if (err < 0)
- return err;
-
- if (state->legacy_cursor_update)
- state->async_update = !drm_atomic_helper_async_check(drm,
state);
-
- return 0;
+ return tegra_display_hub_atomic_check(drm, state);
}
static const struct drm_mode_config_funcs tegra_drm_mode_config_funcs = {
@@ -151,6 +136,8 @@ static int tegra_drm_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.allow_fb_modifiers = true;
+ drm->mode_config.normalize_zpos = true;
+
drm->mode_config.funcs = &tegra_drm_mode_config_funcs;
drm->mode_config.helper_private = &tegra_drm_mode_config_helpers;
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 4/6] drm/sti: Let core take care of normalizing the zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Note: the drm_atomic_helper_check() now includes
if (state->legacy_cursor_update)
state->async_update = !drm_atomic_helper_async_check(drm, state);
which was added after the driver moved away from using it
(38d868e41c4b9250d5a115c049dc2d48f4909581 drm: Don't force all planes to
be added to the state due to zpos)
Signed-off-by: Peter Ujfalusi
CC: Benjamin Gaignard
CC: Vincent Abriou
Acked-by: Daniel Vetter
Acked-by: Benjamin Gaignard
---
drivers/gpu/drm/sti/sti_drv.c | 24 +++-
1 file changed, 3 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/sti/sti_drv.c b/drivers/gpu/drm/sti/sti_drv.c
index 55b6967d27e1..90c46b49c931 100644
--- a/drivers/gpu/drm/sti/sti_drv.c
+++ b/drivers/gpu/drm/sti/sti_drv.c
@@ -119,30 +119,10 @@ static int sti_drm_dbg_init(struct drm_minor *minor)
return ret;
}
-static int sti_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int ret;
-
- ret = drm_atomic_helper_check_modeset(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_normalize_zpos(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_check_planes(dev, state);
- if (ret)
- return ret;
-
- return ret;
-}
-
static const struct drm_mode_config_funcs sti_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
- .atomic_check = sti_atomic_check,
+ .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -160,6 +140,8 @@ static void sti_mode_config_init(struct drm_device *dev)
dev->mode_config.max_height = STI_MAX_FB_HEIGHT;
dev->mode_config.funcs = &sti_mode_config_funcs;
+
+ dev->mode_config.normalize_zpos = true;
}
DEFINE_DRM_GEM_CMA_FOPS(sti_driver_fops);
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 1/6] drm: Add drm_mode_config->normalize_zpos boolean
Instead of drivers duplicating the drm_atomic_helper_check() code to be
able to normalize the zpos they can use the normalize_zpos flag to let the
drm core to do it.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/drm_atomic_helper.c | 11 +++
include/drm/drm_mode_config.h | 8
include/drm/drm_plane.h | 4 ++--
3 files changed, 21 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 00c78c1c9681..a2d06ca1570c 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -875,6 +875,11 @@ EXPORT_SYMBOL(drm_atomic_helper_check_planes);
* functions depend upon an updated adjusted_mode.clock to e.g. properly
compute
* watermarks.
*
+ * Note that zpos normalization will add all enable planes to the state which
+ * might not desired for some drivers.
+ * For example enable/disable of a cursor plane which have fixed zpos value
+ * would trigger all other enabled planes to be forced to the state change.
+ *
* RETURNS:
* Zero for success or -errno
*/
@@ -887,6 +892,12 @@ int drm_atomic_helper_check(struct drm_device *dev,
if (ret)
return ret;
+ if (dev->mode_config.normalize_zpos) {
+ ret = drm_atomic_normalize_zpos(dev, state);
+ if (ret)
+ return ret;
+ }
+
ret = drm_atomic_helper_check_planes(dev, state);
if (ret)
return ret;
diff --git a/include/drm/drm_mode_config.h b/include/drm/drm_mode_config.h
index 7569f22ffef6..33b3a96d66d0 100644
--- a/include/drm/drm_mode_config.h
+++ b/include/drm/drm_mode_config.h
@@ -795,6 +795,14 @@ struct drm_mode_config {
*/
bool allow_fb_modifiers;
+ /**
+* @normalize_zpos:
+*
+* If true the drm core will call drm_atomic_normalize_zpos() as part of
+* atomic mode checking from drm_atomic_helper_check()
+*/
+ bool normalize_zpos;
+
/**
* @modifiers_property: Plane property to list support modifier/format
* combination.
diff --git a/include/drm/drm_plane.h b/include/drm/drm_plane.h
index f7bf4a48b1c3..d6da26d66a4b 100644
--- a/include/drm/drm_plane.h
+++ b/include/drm/drm_plane.h
@@ -51,8 +51,8 @@ struct drm_modeset_acquire_ctx;
* plane with a lower ID.
* @normalized_zpos: normalized value of zpos: unique, range from 0 to N-1
* where N is the number of active planes for given crtc. Note that
- * the driver must call drm_atomic_normalize_zpos() to update this before
- * it can be trusted.
+ * the driver must set drm_mode_config.normalize_zpos or call
+ * drm_atomic_normalize_zpos() to update this before it can be trusted.
* @src: clipped source coordinates of the plane (in 16.16)
* @dst: clipped destination coordinates of the plane
* @state: backpointer to global drm_atomic_state
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 5/6] drm: rcar-du: Let core take care of normalizing the zpos
Set the drm_mode_config->normalize_zpos and call drm_atomic_helper_check() from rcar_du_atomic_check() instead of re implementing the function locally. Signed-off-by: Peter Ujfalusi CC: Laurent Pinchart Acked-by: Daniel Vetter --- drivers/gpu/drm/rcar-du/rcar_du_kms.c | 11 ++- 1 file changed, 2 insertions(+), 9 deletions(-) diff --git a/drivers/gpu/drm/rcar-du/rcar_du_kms.c b/drivers/gpu/drm/rcar-du/rcar_du_kms.c index 0329b354bfa0..ab59d2061e06 100644 --- a/drivers/gpu/drm/rcar-du/rcar_du_kms.c +++ b/drivers/gpu/drm/rcar-du/rcar_du_kms.c @@ -233,15 +233,7 @@ static int rcar_du_atomic_check(struct drm_device *dev, struct rcar_du_device *rcdu = dev->dev_private; int ret; - ret = drm_atomic_helper_check_modeset(dev, state); - if (ret) - return ret; - - ret = drm_atomic_normalize_zpos(dev, state); - if (ret) - return ret; - - ret = drm_atomic_helper_check_planes(dev, state); + ret = drm_atomic_helper_check(dev, state); if (ret) return ret; @@ -529,6 +521,7 @@ int rcar_du_modeset_init(struct rcar_du_device *rcdu) dev->mode_config.min_height = 0; dev->mode_config.max_width = 4095; dev->mode_config.max_height = 2047; + dev->mode_config.normalize_zpos = true; dev->mode_config.funcs = &rcar_du_mode_config_funcs; dev->mode_config.helper_private = &rcar_du_mode_config_helper; -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 2/6] drm/exynos: Let core take care of normalizing the zpos
Instead of re-implementing the drm_atomic_helper_check() locally with just
adding drm_atomic_normalize_zpos() into it, set the
drm_mode_config->normalize_zpos.
Signed-off-by: Peter Ujfalusi
CC: Inki Dae
CC: Joonyoung Shim
CC: Seung-Woo Kim
CC: Kyungmin Park
Acked-by: Daniel Vetter
---
drivers/gpu/drm/exynos/exynos_drm_drv.c | 20
drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
drivers/gpu/drm/exynos/exynos_drm_fb.c | 4 +++-
3 files changed, 3 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
b/drivers/gpu/drm/exynos/exynos_drm_drv.c
index a518e9c6d6cc..39284bb7c2c2 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
@@ -37,26 +37,6 @@
#define DRIVER_MAJOR 1
#define DRIVER_MINOR 0
-int exynos_atomic_check(struct drm_device *dev,
- struct drm_atomic_state *state)
-{
- int ret;
-
- ret = drm_atomic_helper_check_modeset(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_normalize_zpos(dev, state);
- if (ret)
- return ret;
-
- ret = drm_atomic_helper_check_planes(dev, state);
- if (ret)
- return ret;
-
- return ret;
-}
-
static int exynos_drm_open(struct drm_device *dev, struct drm_file *file)
{
struct drm_exynos_file_private *file_priv;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
b/drivers/gpu/drm/exynos/exynos_drm_drv.h
index df2262f70d91..075957cb6ba1 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
+++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
@@ -275,7 +275,6 @@ static inline int exynos_dpi_bind(struct drm_device *dev,
int exynos_atomic_commit(struct drm_device *dev, struct drm_atomic_state
*state,
bool nonblock);
-int exynos_atomic_check(struct drm_device *dev, struct drm_atomic_state
*state);
extern struct platform_driver fimd_driver;
diff --git a/drivers/gpu/drm/exynos/exynos_drm_fb.c
b/drivers/gpu/drm/exynos/exynos_drm_fb.c
index 0faaf829f5bf..2379d732da67 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_fb.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_fb.c
@@ -206,7 +206,7 @@ static struct drm_mode_config_helper_funcs
exynos_drm_mode_config_helpers = {
static const struct drm_mode_config_funcs exynos_drm_mode_config_funcs = {
.fb_create = exynos_user_fb_create,
.output_poll_changed = drm_fb_helper_output_poll_changed,
- .atomic_check = exynos_atomic_check,
+ .atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
@@ -227,4 +227,6 @@ void exynos_drm_mode_config_init(struct drm_device *dev)
dev->mode_config.helper_private = &exynos_drm_mode_config_helpers;
dev->mode_config.allow_fb_modifiers = true;
+
+ dev->mode_config.normalize_zpos = true;
}
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v5 6/6] drm/omap: Use normalized zpos for plane placement
Planes with identical zpos value will result undefined behavior: disappearing planes, screen flickering and it is not supported by the hardware. Use normalized zpos to make sure that we don't encounter invalid configuration. Signed-off-by: Peter Ujfalusi CC: Tomi Valkeinen Acked-by: Daniel Vetter Reviewed-by: Tomi Valkeinen --- drivers/gpu/drm/omapdrm/omap_drv.c | 3 +++ drivers/gpu/drm/omapdrm/omap_plane.c | 2 +- 2 files changed, 4 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c b/drivers/gpu/drm/omapdrm/omap_drv.c index 3632854c2b91..ef3b0e3571ec 100644 --- a/drivers/gpu/drm/omapdrm/omap_drv.c +++ b/drivers/gpu/drm/omapdrm/omap_drv.c @@ -319,6 +319,9 @@ static int omap_modeset_init(struct drm_device *dev) dev->mode_config.max_width = 8192; dev->mode_config.max_height = 8192; + /* We want the zpos to be normalized */ + dev->mode_config.normalize_zpos = true; + dev->mode_config.funcs = &omap_mode_config_funcs; dev->mode_config.helper_private = &omap_mode_config_helper_funcs; diff --git a/drivers/gpu/drm/omapdrm/omap_plane.c b/drivers/gpu/drm/omapdrm/omap_plane.c index 2899435cad6e..161233cbc9a0 100644 --- a/drivers/gpu/drm/omapdrm/omap_plane.c +++ b/drivers/gpu/drm/omapdrm/omap_plane.c @@ -65,7 +65,7 @@ static void omap_plane_atomic_update(struct drm_plane *plane, info.rotation_type = OMAP_DSS_ROT_NONE; info.rotation = DRM_MODE_ROTATE_0; info.global_alpha = 0xff; - info.zorder = state->zpos; + info.zorder = state->normalized_zpos; /* update scanout: */ omap_framebuffer_update_scanout(state->fb, state, &info); -- Peter Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Freedreno] [DPU PATCH 2/2] drm/msm: Add hardware catalog file for SDM845
On 2018-03-20 20:47, Sean Paul wrote:
On Tue, Mar 20, 2018 at 07:13:38PM +0530, skoll...@codeaurora.org
wrote:
On 2018-03-19 19:29, Sean Paul wrote:
> On Wed, Mar 14, 2018 at 11:21:38AM +0530, Sravanthi Kollukuduru wrote:
> > This change adds the hardware catalog information in driver source
> > for SDM845. This removes the current logic of dt based parsing
> > of target catalog information.
> >
> > Signed-off-by: Sravanthi Kollukuduru
> > +{
> > + /* Layer capability */
> > + static const struct dpu_sspp_sub_blks vig_sblk_0 = {
> > + .maxlinewidth = 2560,
> > + .pixel_ram_size = 50 * 1024,
> > + .maxdwnscale = 4,
> > + .maxupscale = 20,
> > + .maxhdeciexp = DECIMATION_40X_MAX_H,
> > + .maxvdeciexp = DECIMATION_40X_MAX_V,
> > + .smart_dma_priority = 5,
> > + .src_blk = {.name = "sspp_src_0", .id = DPU_SSPP_SRC,
> > + .base = 0x00, .len = 0x150,},
> > + .scaler_blk = {.name = "sspp_scaler0",
> > + .id = DPU_SSPP_SCALER_QSEED3,
> > + .base = 0xa00, .len = 0xa0,},
> > + .csc_blk = {.name = "sspp_csc0", .id = DPU_SSPP_CSC_10BIT,
> > + .base = 0x1a00, .len = 0x100,},
> > + .format_list = plane_formats_yuv,
> > + .virt_format_list = plane_formats,
> > + };
>
> Instead of locating all of these parameters in one file, these should be
> located in their respective driver file. It also seems like you could
> separate
> out the common stuff such as line width, ram size, scaling, format, etc
> parameters from the pipeline setup.
>
> The same comments apply to the other blocks. Move things into the
> drivers,
> use compatibility string to determine the version, and then associate
> the common
> parameters with of_device_id.data.
>
> Sean
>
>
Thanks Sean for the feedback.
The idea behind this approach is to maintain a one point access for
all the
target specific information, analogous to the current dpu dtsi file.
This also ensures easy maintenance for different hardware versions, as
all
it
takes is to add another file instead of updating across individual sub
block
files.
I am not convinced this is what we should optimize for. This file is
basically
unreadable, and it's abstracting relevant details away from the block
code. There
are also a TON of duplicated parameters/values which is error-prone.
Lastly,
this is not the type of file that you want to copy/paste multiple
times, it would
be much better to simply add the new structs to the block drivers
where applicable.
Also, i'm not quite clear on how compatibility strings is applicable
to sub
blocks.
Consider the following example from rockchip:
https://gitlab.freedesktop.org/seanpaul/dpu-staging/blob/for-next/drivers/gpu/drm/rockchip/rockchip_vop_reg.c#L538
Each time the vop is changed, it gets a new compatible string in the
dt bindings.
This compatible string is tied to a parameters that describe the
features of
that version of vop. This data is tied to the driver data during probe
and used
whe needed throughout the driver.
So all of your catalog data should be broken up into structs specific
to the
various sub-blocks of the dpu driver and associated with compatible
strings.
When a new chip comes out with different parameters, a new struct
should be
defined along with a new compatible string.
Make sense?
Sean
Yes Sean, thanks for sharing the rockchip_vop reference.
Based on the discussions so far, there are two main points to be
addressed:
1. Associate catalog information with hardware versions using compatible
strings
2. Create sub block structures that various hardware versions can
reuse.
The intent of Point 1. is present in the current implementation.
The hardware version is read from register to extract the relevant
catalog information.
Hence, we don't plan to define new DT compatible strings for this
purpose.
(Upstream reference for similar implementation :
https://gitlab.freedesktop.org/seanpaul/dpu-staging/blob/for-next/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c#L556)
Point 2. however, is a valid concern and needs to be thoroughly looked
into.
The challenge here is to assess the code impact if we plan to modify the
present
catalog structures (for instance, create a new common structure).
Will get back to you on this after internal review.
Thanks,
Sravanthi
Please clarify.
Thanks,
Sravanthi
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 199123] kernel 4.16rc5 doesnt boot on ryzen 5 2400g due to an amdgpu change
https://bugzilla.kernel.org/show_bug.cgi?id=199123 --- Comment #11 from david becerra (davidbecerrapor...@gmail.com) --- issue still present in 4.16rc6 -- 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
[PATCH v2 5/6] drm/omap: dss: Remove display ordering from dss/display.c
The previous patch implements the ordering of the dss_devices based on DT
aliases in omap_drm.c, so there is no need to do the ordering in
dss/display.c anymore.
At the same time remove the alias member of the omap_dss_device struct
since it is no longer needed. The only place it was used is in the
omapdss_register_display() function.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/dss/display.c | 15 +++
drivers/gpu/drm/omapdrm/dss/omapdss.h | 2 --
2 files changed, 3 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/display.c
b/drivers/gpu/drm/omapdrm/dss/display.c
index 3ef99f344bd3..7840837f4325 100644
--- a/drivers/gpu/drm/omapdrm/dss/display.c
+++ b/drivers/gpu/drm/omapdrm/dss/display.c
@@ -41,7 +41,6 @@ static int disp_num_counter;
int omapdss_register_display(struct omap_dss_device *dssdev)
{
struct omap_dss_driver *drv = dssdev->driver;
- struct list_head *cur;
int id;
/*
@@ -54,26 +53,18 @@ int omapdss_register_display(struct omap_dss_device *dssdev)
dssdev->alias_id = id;
- snprintf(dssdev->alias, sizeof(dssdev->alias), "display%d", id);
-
/* Use 'label' property for name, if it exists */
of_property_read_string(dssdev->dev->of_node, "label", &dssdev->name);
if (dssdev->name == NULL)
- dssdev->name = dssdev->alias;
+ dssdev->name = devm_kasprintf(dssdev->dev, GFP_KERNEL,
+ "display%d", id);
if (drv && drv->get_timings == NULL)
drv->get_timings = omapdss_default_get_timings;
mutex_lock(&panel_list_mutex);
- list_for_each(cur, &panel_list) {
- struct omap_dss_device *ldev = list_entry(cur,
-struct omap_dss_device,
-panel_list);
- if (strcmp(ldev->alias, dssdev->alias) > 0)
- break;
- }
- list_add_tail(&dssdev->panel_list, cur);
+ list_add_tail(&dssdev->panel_list, &panel_list);
mutex_unlock(&panel_list_mutex);
return 0;
}
diff --git a/drivers/gpu/drm/omapdrm/dss/omapdss.h
b/drivers/gpu/drm/omapdrm/dss/omapdss.h
index d1056d0d32c2..d22212fd2f2a 100644
--- a/drivers/gpu/drm/omapdrm/dss/omapdss.h
+++ b/drivers/gpu/drm/omapdrm/dss/omapdss.h
@@ -465,8 +465,6 @@ struct omap_dss_device {
struct list_head panel_list;
- /* alias in the form of "display%d" */
- char alias[16];
int alias_id;
enum omap_display_type type;
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 6/6] drm/omap: Add kernel parameter to specify the desired display order
omapdrm.displays (int array) can be used to reorder the displays by id if
needed. It can be also used to disable display.
If the board have two active displays:
0 - LCD
1 - HDMI
then:
omapdrm.displays=0,1 - represents the original order (LCD, HDMI)
omapdrm.displays=1,0 - represents reverse order (HDMI, LCD)
omapdrm.displays=0 - only the LCD is enabled
omapdrm.displays=1 - only the HDMI is enabled
omapdrm.displays=-1 - disable all displays
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 55 +++---
1 file changed, 51 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 65666e946799..645674d4be71 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -34,6 +34,14 @@
#define DRIVER_MINOR 0
#define DRIVER_PATCHLEVEL 0
+#define MAX_NR_DISPLAYS8
+static int display_order[MAX_NR_DISPLAYS];
+static int display_order_nelm;
+module_param_array_named(displays, display_order, int, &display_order_nelm,
+0444);
+MODULE_PARM_DESC(displays,
+"ID array to specify the order of the active displays");
+
/*
* mode config funcs
*/
@@ -182,12 +190,21 @@ static int omap_compare_dssdevs(const void *a, const void
*b)
static void omap_collect_dssdevs(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
+ struct omap_dss_device *dssdevs[ARRAY_SIZE(priv->dssdevs)];
struct omap_dss_device *dssdev = NULL;
+ int num_dssdevs = 0;
+ unsigned long dssdev_mask = 0;
+ int i;
+
+ /* No displays should be enabled */
+ if (display_order_nelm == 1 && display_order[0] < 0)
+ return;
for_each_dss_dev(dssdev) {
omap_dss_get_device(dssdev);
- priv->dssdevs[priv->num_dssdevs++] = dssdev;
- if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ set_bit(num_dssdevs, &dssdev_mask);
+ dssdevs[num_dssdevs++] = dssdev;
+ if (num_dssdevs == ARRAY_SIZE(dssdevs)) {
/* To balance the 'for_each_dss_dev' loop */
omap_dss_put_device(dssdev);
break;
@@ -195,8 +212,38 @@ static void omap_collect_dssdevs(struct drm_device *ddev)
}
/* Sort the list by DT aliases */
- sort(priv->dssdevs, priv->num_dssdevs, sizeof(priv->dssdevs[0]),
-omap_compare_dssdevs, NULL);
+ sort(dssdevs, num_dssdevs, sizeof(dssdevs[0]), omap_compare_dssdevs,
+NULL);
+
+ /* Do ordering based on the display_order parameter array */
+ for (i = 0; i < display_order_nelm; i++) {
+ int old_index = display_order[i];
+
+ if ((old_index >= 0 && old_index < num_dssdevs) &&
+ (dssdev_mask & BIT(old_index))) {
+ priv->dssdevs[priv->num_dssdevs++] = dssdevs[old_index];
+ clear_bit(old_index, &dssdev_mask);
+ } else {
+ dev_err(ddev->dev,
+ "Ignoring invalid displays module parameter\n");
+ priv->num_dssdevs = 0;
+ break;
+ }
+ }
+
+ /* if the target list is empty, copy the collected dssdevs, if any */
+ if (priv->num_dssdevs == 0) {
+ for (i = 0; i < num_dssdevs; i++)
+ priv->dssdevs[i] = dssdevs[i];
+
+ priv->num_dssdevs = num_dssdevs;
+ } else {
+ u32 idx;
+
+ /* check if we have dssdev which is not carried over */
+ for_each_set_bit(idx, &dssdev_mask, ARRAY_SIZE(dssdevs))
+ omap_dss_put_device(dssdevs[idx]);
+ }
}
static int omap_connect_dssdevs(struct drm_device *ddev)
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Linaro-mm-sig] [PATCH 1/5] dma-buf: add optional invalidate_mappings callback v2
Am 21.03.2018 um 09:28 schrieb Daniel Vetter:
On Tue, Mar 20, 2018 at 06:47:57PM +0100, Christian König wrote:
Am 20.03.2018 um 15:08 schrieb Daniel Vetter:
[SNIP]
For the in-driver reservation path (CS) having a slow-path that grabs a
temporary reference, drops the vram lock and then locks the reservation
normally (using the acquire context used already for the entire CS) is a
bit tricky, but totally feasible. Ttm doesn't do that though.
That is exactly what we do in amdgpu as well, it's just not very efficient
nor reliable to retry getting the right pages for a submission over and over
again.
Out of curiosity, where's that code? I did read the ttm eviction code way
back, and that one definitely didn't do that. Would be interesting to
update my understanding.
That is in amdgpu_cs.c. amdgpu_cs_parser_bos() does a horrible dance
with grabbing, releasing and regrabbing locks in a loop.
Then in amdgpu_cs_submit() we grab an lock preventing page table updates
and check if all pages are still the one we want to have:
amdgpu_mn_lock(p->mn);
if (p->bo_list) {
for (i = p->bo_list->first_userptr;
i < p->bo_list->num_entries; ++i) {
struct amdgpu_bo *bo = p->bo_list->array[i].robj;
if
(amdgpu_ttm_tt_userptr_needs_pages(bo->tbo.ttm)) {
amdgpu_mn_unlock(p->mn);
return -ERESTARTSYS;
}
}
}
If anything changed on the page tables we restart the whole IOCTL using
-ERESTARTSYS and try again.
Regards,
Christian.
-Daniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105530] Stuttering on Raven Ridge when TearFree is on
https://bugs.freedesktop.org/show_bug.cgi?id=105530 --- Comment #6 from txtsd --- Also, is there an older kernel I should try? Give me a branch/commit, and I'll compile and see if the issue exists. -- 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: Reject getfb for multi-plane framebuffers
Hi,
On 21 March 2018 at 08:27, Daniel Vetter wrote:
> On Tue, Mar 20, 2018 at 09:01:11PM -0400, Rob Clark wrote:
>> On Tue, Mar 20, 2018 at 6:58 PM, Daniel Stone wrote:
>> > getfb can only return a single plane, so reject attempts to use it with
>> > multi-plane framebuffers.
>> >
>>
>> yeah, this seems like a pretty good idea,
>>
>> Reviewed-by: Rob Clark
>>
>> > Signed-off-by: Daniel Stone
>> > Reported-by: Daniel van Vugt
>> > Fixes: 308e5bcbdb10 ("drm: add an fb creation ioctl that takes a pixel
>> > format v5")
>> > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105518
>
> Cc: sta...@vger.kernel.org # v3.3+
> Reviewed-by: Daniel Vetter
>
> Please push to drm-misc-fixes and poke Gustavo to do a pull so it's not
> lost.
Thanks both, I've pushed now. I suspect Gustavo is still on a plane
somewhere, but poked nevertheless.
Cheers,
aniel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/6] Revert "drm/atomic-helper: Fix leak in disable_all"
On Wed, Mar 21, 2018 at 09:25:06AM +0100, Daniel Vetter wrote:
> On Tue, Mar 20, 2018 at 09:17:52PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Currently we're leaking fbs on load detect on account of nothing setting
> > up plane->old_fb for the drm_atomic_clean_old_fb() call in
> > drm_atomic_helper_commit_duplicated_state(). Removing the
> > drm_atomic_clean_old_fb() call seems like the right call to me here.
> > This does mean we end up leaking something via
> > drm_atomic_helper_shutdown() though, but we'll fix that up in a
> > different way.
> >
> > This reverts commit 49d70aeaeca8f62b72b7712ecd1e29619a445866.
>
> So the reason I went this way and not what you're suggesting in this patch
> series is that i915 is the one and only driver noodling around with load
> detect and gpu reset that needs this.
>
> Imo it'd be better to fix up our load detect code to also set the old_fb
> stuff up correctly,
Feels a bit silly to just set plane->old_fb = plane->fb and immediately
follow it up with inc(plane->fb)+dec(plane->old_fb) and old_fb=NULL.
> and add at least a long-term task to todo.rst to get
> rid of all this.
I have a series that stops using plane->fb/old_fb entirely on atomic
drivers. That removes the entire clean_old_fbs() thing. Not sure all
drivers are ready for that though. I think I'll post it as an rfc
anyway.
> Inflicting a new parameter on all the other drives (like
> you do in patch 2) is imo the wrong way round - we have 31 other atomic
> drivers than i915.ko.
None of them use disable_all() directly.
But if we want to avoid the new parameter being visible too drivers I
could just squash in:
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 76424dd961d7..cdf10b9e5177 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -2881,33 +2881,9 @@ int __drm_atomic_helper_set_config(struct drm_mode_set
*set,
return 0;
}
-/**
- * drm_atomic_helper_disable_all - disable all currently active outputs
- * @dev: DRM device
- * @ctx: lock acquisition context
- * @clean_old_fbs: update the plane->fb/old_fb pointers?
- *
- * Loops through all connectors, finding those that aren't turned off and then
- * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
- * that they are connected to.
- *
- * This is used for example in suspend/resume to disable all currently active
- * functions when suspending. If you just want to shut down everything at e.g.
- * driver unload, look at drm_atomic_helper_shutdown().
- *
- * Note that if callers haven't already acquired all modeset locks this might
- * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
- *
- * Returns:
- * 0 on success or a negative error code on failure.
- *
- * See also:
- * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
- * drm_atomic_helper_shutdown().
- */
-int drm_atomic_helper_disable_all(struct drm_device *dev,
- struct drm_modeset_acquire_ctx *ctx,
- bool clean_old_fbs)
+static int __drm_atomic_helper_disable_all(struct drm_device *dev,
+ struct drm_modeset_acquire_ctx *ctx,
+ bool clean_old_fbs)
{
struct drm_atomic_state *state;
struct drm_connector_state *conn_state;
@@ -2973,7 +2949,34 @@ int drm_atomic_helper_disable_all(struct drm_device *dev,
drm_atomic_state_put(state);
return ret;
}
-
+/**
+ * drm_atomic_helper_disable_all - disable all currently active outputs
+ * @dev: DRM device
+ * @ctx: lock acquisition context
+ *
+ * Loops through all connectors, finding those that aren't turned off and then
+ * turns them off by setting their DPMS mode to OFF and deactivating the CRTC
+ * that they are connected to.
+ *
+ * This is used for example in suspend/resume to disable all currently active
+ * functions when suspending. If you just want to shut down everything at e.g.
+ * driver unload, look at drm_atomic_helper_shutdown().
+ *
+ * Note that if callers haven't already acquired all modeset locks this might
+ * return -EDEADLK, which must be handled by calling drm_modeset_backoff().
+ *
+ * Returns:
+ * 0 on success or a negative error code on failure.
+ *
+ * See also:
+ * drm_atomic_helper_suspend(), drm_atomic_helper_resume() and
+ * drm_atomic_helper_shutdown().
+ */
+int drm_atomic_helper_disable_all(struct drm_device *dev,
+ struct drm_modeset_acquire_ctx *ctx)
+{
+ return __drm_atomic_helper_disable_all(dev, ctx, false);
+}
EXPORT_SYMBOL(drm_atomic_helper_disable_all);
/**
@@ -2996,7 +2999,7 @@ void drm_atomic_helper_shutdown(struct drm_device *dev)
while (1) {
ret = drm_modeset_lock_all_ctx(dev, &ctx);
if (!ret)
- ret = drm_atomic_helper_disable_all(dev, &ctx, true);
+
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #66 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Ricardo Ribalda from comment #65) > Hi > > IOMMU is disabled: > > root@qt5122:~# ls /sys/class/iommu > ls: cannot access '/sys/class/iommu': No such file or directory > root@qt5122:~# dmesg | grep -i iommu > root@qt5122:~# To be sure, is it disabled in BIOS ? -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2] drm/i915/gvt: throw error on unhandled vfio ioctls
On Wed, 21 Mar 2018 10:08:03 +0100 Gerd Hoffmann wrote: > On unknown/unhandled ioctls the driver should return an error, so > userspace knows it tried to use something unsupported. > > Cc: sta...@vger.kernel.org > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c > b/drivers/gpu/drm/i915/gvt/kvmgt.c > index 021f722e24..be881d53c2 100644 > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c > @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, > unsigned int cmd, > > } > > - return 0; > + return -EINVAL; > } > > static ssize_t Absolutely, but I'd prefer to continue the standard behavior among other vfio drivers, and adopted from elsewhere in the kernel, to use -ENOTTY for an unhandled ioctl, reserving -EINVAL as an error in options for a supported ioctl. Thanks, Alex ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105633] [amdgpu][bisected] PRIME stuttering tearing
https://bugs.freedesktop.org/show_bug.cgi?id=105633 Christian König changed: What|Removed |Added CC||ckoenig.leichtzumerken@gmai ||l.com Status|NEW |NEEDINFO Assignee|dri-devel@lists.freedesktop |ckoenig.leichtzumerken@gmai |.org|l.com --- Comment #1 from Christian König --- Created attachment 138243 --> https://bugs.freedesktop.org/attachment.cgi?id=138243&action=edit Possible fix Thanks for the report and yes I mixed up exporter and importer in the check. Please test the attached patch. -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #67 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- I have coreboot. So I do not have the typical menu. I have an FPGA writing to the main memory, and that could not happen if iommu is enabled without extra configuration. If you can tell me which register to look for we can be 100% sure. -- 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: [Freedreno] [DPU PATCH 2/2] drm/msm: Add hardware catalog file for SDM845
On Wed, Mar 21, 2018 at 04:05:31PM +0530, skoll...@codeaurora.org wrote:
> On 2018-03-20 20:47, Sean Paul wrote:
> > On Tue, Mar 20, 2018 at 07:13:38PM +0530, skoll...@codeaurora.org wrote:
> > > On 2018-03-19 19:29, Sean Paul wrote:
> > > > On Wed, Mar 14, 2018 at 11:21:38AM +0530, Sravanthi Kollukuduru wrote:
> > > > > This change adds the hardware catalog information in driver source
> > > > > for SDM845. This removes the current logic of dt based parsing
> > > > > of target catalog information.
> > > > >
> > > > > Signed-off-by: Sravanthi Kollukuduru
> >
> >
> >
> > > > > +{
> > > > > + /* Layer capability */
> > > > > + static const struct dpu_sspp_sub_blks vig_sblk_0 = {
> > > > > + .maxlinewidth = 2560,
> > > > > + .pixel_ram_size = 50 * 1024,
> > > > > + .maxdwnscale = 4,
> > > > > + .maxupscale = 20,
> > > > > + .maxhdeciexp = DECIMATION_40X_MAX_H,
> > > > > + .maxvdeciexp = DECIMATION_40X_MAX_V,
> > > > > + .smart_dma_priority = 5,
> > > > > + .src_blk = {.name = "sspp_src_0", .id = DPU_SSPP_SRC,
> > > > > + .base = 0x00, .len = 0x150,},
> > > > > + .scaler_blk = {.name = "sspp_scaler0",
> > > > > + .id = DPU_SSPP_SCALER_QSEED3,
> > > > > + .base = 0xa00, .len = 0xa0,},
> > > > > + .csc_blk = {.name = "sspp_csc0", .id =
> > > > > DPU_SSPP_CSC_10BIT,
> > > > > + .base = 0x1a00, .len = 0x100,},
> > > > > + .format_list = plane_formats_yuv,
> > > > > + .virt_format_list = plane_formats,
> > > > > + };
> > > >
> > > > Instead of locating all of these parameters in one file, these should be
> > > > located in their respective driver file. It also seems like you could
> > > > separate
> > > > out the common stuff such as line width, ram size, scaling, format, etc
> > > > parameters from the pipeline setup.
> > > >
> > > > The same comments apply to the other blocks. Move things into the
> > > > drivers,
> > > > use compatibility string to determine the version, and then associate
> > > > the common
> > > > parameters with of_device_id.data.
> > > >
> > > > Sean
> > > >
> > > >
> > >
> > > Thanks Sean for the feedback.
> > > The idea behind this approach is to maintain a one point access for
> > > all the
> > > target specific information, analogous to the current dpu dtsi file.
> > > This also ensures easy maintenance for different hardware versions,
> > > as all
> > > it
> > > takes is to add another file instead of updating across individual
> > > sub block
> > > files.
> >
> > I am not convinced this is what we should optimize for. This file is
> > basically
> > unreadable, and it's abstracting relevant details away from the block
> > code. There
> > are also a TON of duplicated parameters/values which is error-prone.
> > Lastly,
> > this is not the type of file that you want to copy/paste multiple
> > times, it would
> > be much better to simply add the new structs to the block drivers
> > where applicable.
> >
> > >
> > > Also, i'm not quite clear on how compatibility strings is applicable
> > > to sub
> > > blocks.
> >
> > Consider the following example from rockchip:
> > https://gitlab.freedesktop.org/seanpaul/dpu-staging/blob/for-next/drivers/gpu/drm/rockchip/rockchip_vop_reg.c#L538
> >
> > Each time the vop is changed, it gets a new compatible string in the
> > dt bindings.
> > This compatible string is tied to a parameters that describe the
> > features of
> > that version of vop. This data is tied to the driver data during probe
> > and used
> > whe needed throughout the driver.
> >
> > So all of your catalog data should be broken up into structs specific to
> > the
> > various sub-blocks of the dpu driver and associated with compatible
> > strings.
> > When a new chip comes out with different parameters, a new struct should
> > be
> > defined along with a new compatible string.
> >
> > Make sense?
> >
> > Sean
> >
>
> Yes Sean, thanks for sharing the rockchip_vop reference.
> Based on the discussions so far, there are two main points to be addressed:
> 1. Associate catalog information with hardware versions using compatible
> strings
> 2. Create sub block structures that various hardware versions can reuse.
>
> The intent of Point 1. is present in the current implementation.
> The hardware version is read from register to extract the relevant catalog
> information.
> Hence, we don't plan to define new DT compatible strings for this purpose.
> (Upstream reference for similar implementation :
> https://gitlab.freedesktop.org/seanpaul/dpu-staging/blob/for-next/drivers/gpu/drm/msm/disp/mdp5/mdp5_cfg.c#L556)
Yeah, if you can get the version from a register and avoid a new dt binding,
that's even better.
>
>
> Point 2. however, is a valid concern and needs to be thoroughly looked into.
> The challenge here is to assess the code impact if we p
Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
On Tue, Mar 20, 2018 at 11:35:40PM -0400, Rob Clark wrote: > On Tue, Mar 20, 2018 at 11:16 AM, Alexandru-Cosmin Gheorghe > wrote: > > On Tue, Mar 20, 2018 at 10:00:17AM -0400, Sean Paul wrote: > >> On Tue, Mar 13, 2018 at 04:21:20PM +, Alexandru Gheorghe wrote: > >> > This patchset tries to add support for using writeback connector to > >> > flatten a scene when it doesn't change for a while. This idea had > >> > been floated around on IRC here [1] and here [2]. > >> > > >> > Developed on top of the latest writeback series, sent by Liviu here > >> > [3]. > >> > > >> > Probably the patch should/could be broken in more patches, but since I > >> > want to put this out there to get feedback, I kept them as a single > >> > patch for now. > >> > > >> > This change could be summarize as follow: > >> > - Attach a writeback connector to the CRTC that's controlling a > >> > display. > >> > - Detect the scene did not change for a while(60 vblanks). > >> > - Re-commit scene and get the composited scene through the writeback > >> > connector. > >> > - Commit the whole scene as a single plane. > >> > > >> > Some areas that I consider important and I could use some > >> > feedback/ideas: > >> > > >> > 1. Building the pipeline. > >> > Currently, drm_hwcomposer allows to connect just a single connector > >> > to a crtc. For now, I decided to treat the writeback connector as a > >> > separate field inside DrmCrtc. I'm not sure if it's a good idea to try > >> > to handle this in a unified way, since the writeback connector is such > >> > a special connector. Regarding the allocation of writeback connectors, > >> > my idea was to allocate writeback connector to the primary display > >> > first and then continue allocating while respecting the display number. 0 > >> > gets a writeback before 1 and so on. > >> > > >> > 2. Heuristic for triggering the flattening. > >> > I just created a VSyncWorker which will trigger the flattening of the > >> > scene if it doesn't change for 60 consecutive vsyncs. The countdown > >> > gets reset every time ValidateDisplay is called. This is a relatively > >> > basic heuristic, so I'm open to suggestions. > >> > > >> > 3. Locking scheme corner cases. > >> > The Vsynworker is a separate thread which will contend with > >> > SurfaceFlinger for showing things on the screen. I tried to limit the > >> > race window by resetting the countdown on ValidateDisplay and > >> > explicitely checking that we still need to use the flatten scene before > >> > commiting to get the writeback result or before applying the flattened > >> > scene. > >> > >> What are the consequences of the race? It seems like it might be possible > >> that > >> stale content will be shown over fresh? > >> I think it'd be fine to serialize > >> vsyncworker and "normal" commits such that the race window is closed > >> instead of > >> reduced. I think you could do the writeback operation asynchronously and > >> then > >> commit the result once it's ready, that shouldn't block things up too much. > >> > > > > Just, to make sure we are on the same page, for Mali DP650 the pipeline > > looks like this, I didn't see how it looks for the other hardware. > > > > CRTC encoder display connector > > |--- writeback enc -- writeback connector. > > > > There is no asynchronously writeback operation, the scene that you > > do writeback for will be shown on the display as well. > > > > fwiw, the msm/mdp5 writeback support I implemented was using a > different CRTC (ie. output going either to display or to wb).. (which > unfortunately implies using different planes).. not sure how much this > case is worth supporting in drm-hwc. Yeah, I wonder whether this is the method of operation we should focus on. It's unclear whether the restrictions Alex describes above are HW or SW limited, my impression was SW. Of course, this means we'll need to disable WB if we are using all crtcs (ie: external display connected), but that seems like a rare usecase of Android, and one might argue that power savings are not as important in this case. Further, if we enable compositing with a dedicated WB pipe, we can also use it for virtual displays. Sean > > (I think I can do the single CRTC and multiple encoder cases, but it > wasn't really obvious how to get that working with a video mode > display and the hw I was working on didn't have a DSI cmd mode panel) > > BR, > -R > > > Flattening thread: > > 1) Commit original scene + writeback buffer > > 2) Wait for writeback fence. > > 3) Commit flattened scene. > > > > Before 1) and 3) I'm doing a locked check where I verify if flattened > > scene is still needed and then I release the lock and commit. > > > > Now, I can see a crazy race where immediately after I decided that we > > need the flattened scene the flattening thread doesn't get any CPU and > > the SurfaceFlinger comes ahead and commits it's new scene followed by > > a commit of the old scene. > > That's the limitted race
[PATCH v3] drm/i915/gvt: throw error on unhandled vfio ioctls
On unknown/unhandled ioctls the driver should return an error, so userspace knows it tried to use something unsupported. Cc: sta...@vger.kernel.org Signed-off-by: Gerd Hoffmann --- drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c index 021f722e24..f34d7f1e6c 100644 --- a/drivers/gpu/drm/i915/gvt/kvmgt.c +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, unsigned int cmd, } - return 0; + return -ENOTTY; } static ssize_t -- 2.9.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH DRM] drm/zte: Replace include drmP.h with drm_print.h
On Tue, Mar 20, 2018 at 07:43:20AM -0400, Haneen Mohammed wrote: > Remove drmP.h as it is not needed anymore since nothing it defines is > used in these files and use drm_print.h instead as these files are using > the debug macros defined there. > > Signed-off-by: Haneen Mohammed Thanks for the patch, Haneen, this lgtm. Reviewed-by: Sean Paul > --- > drivers/gpu/drm/zte/zx_drm_drv.c | 2 +- > drivers/gpu/drm/zte/zx_hdmi.c| 2 +- > drivers/gpu/drm/zte/zx_plane.c | 2 +- > drivers/gpu/drm/zte/zx_tvenc.c | 2 +- > drivers/gpu/drm/zte/zx_vga.c | 2 +- > drivers/gpu/drm/zte/zx_vou.c | 2 +- > 6 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c > b/drivers/gpu/drm/zte/zx_drm_drv.c > index 6f4205e8..f375cb0 100644 > --- a/drivers/gpu/drm/zte/zx_drm_drv.c > +++ b/drivers/gpu/drm/zte/zx_drm_drv.c > @@ -24,7 +24,7 @@ > #include > #include > #include > -#include > +#include > > #include "zx_drm_drv.h" > #include "zx_vou.h" > diff --git a/drivers/gpu/drm/zte/zx_hdmi.c b/drivers/gpu/drm/zte/zx_hdmi.c > index 13ea90f..4cc9ebd 100644 > --- a/drivers/gpu/drm/zte/zx_hdmi.c > +++ b/drivers/gpu/drm/zte/zx_hdmi.c > @@ -23,7 +23,7 @@ > #include > #include > #include > -#include > +#include > > #include > > diff --git a/drivers/gpu/drm/zte/zx_plane.c b/drivers/gpu/drm/zte/zx_plane.c > index 68fd2e2..a99 100644 > --- a/drivers/gpu/drm/zte/zx_plane.c > +++ b/drivers/gpu/drm/zte/zx_plane.c > @@ -14,7 +14,7 @@ > #include > #include > #include > -#include > +#include > > #include "zx_common_regs.h" > #include "zx_drm_drv.h" > diff --git a/drivers/gpu/drm/zte/zx_tvenc.c b/drivers/gpu/drm/zte/zx_tvenc.c > index 0de1a71..355b7fb 100644 > --- a/drivers/gpu/drm/zte/zx_tvenc.c > +++ b/drivers/gpu/drm/zte/zx_tvenc.c > @@ -15,7 +15,7 @@ > > #include > #include > -#include > +#include > > #include "zx_drm_drv.h" > #include "zx_tvenc_regs.h" > diff --git a/drivers/gpu/drm/zte/zx_vga.c b/drivers/gpu/drm/zte/zx_vga.c > index 3e7e33c..9d18e8a 100644 > --- a/drivers/gpu/drm/zte/zx_vga.c > +++ b/drivers/gpu/drm/zte/zx_vga.c > @@ -14,7 +14,7 @@ > > #include > #include > -#include > +#include > > #include "zx_drm_drv.h" > #include "zx_vga_regs.h" > diff --git a/drivers/gpu/drm/zte/zx_vou.c b/drivers/gpu/drm/zte/zx_vou.c > index 7491813..7f49c1f 100644 > --- a/drivers/gpu/drm/zte/zx_vou.c > +++ b/drivers/gpu/drm/zte/zx_vou.c > @@ -21,7 +21,7 @@ > #include > #include > #include > -#include > +#include > > #include "zx_common_regs.h" > #include "zx_drm_drv.h" > -- > 2.7.4 > -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #68 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Ricardo Ribalda from comment #67) > I have coreboot. So I do not have the typical menu. > > I have an FPGA writing to the main memory, and that could not happen if > iommu is enabled without extra configuration. > > If you can tell me which register to look for we can be 100% sure. I took a bettong board here in office, booted it while pressing ESC, goes into BIOS, then choosing Chipest->GFX Configuration->IOMMU En/Dis But i guess you mean you have coreboot INSTEAD of standard BIOS like i have, So at least you sure you have the following disabled as in this link - https://wiki.gentoo.org/wiki/IOMMU_SWIOTLB IOMMU Hardware Support disabled in make menuconfig and also you boot the kernel with iommu=off ? If so I assume you indeed have IOMMU disabled and then I will try later to again reproduce your issue with Bettong board I just found because before I was reproducing with a different CZ board. Andrey -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #69 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- This is my kernel configuration: ricardo@neopili:~/curro/kernel-upstream$ cat .config | grep -i IOMMU CONFIG_GART_IOMMU=y # CONFIG_CALGARY_IOMMU is not set CONFIG_IOMMU_HELPER=y CONFIG_IOMMU_SUPPORT=y # Generic IOMMU Pagetable Support # CONFIG_AMD_IOMMU is not set # CONFIG_INTEL_IOMMU is not set # CONFIG_IOMMU_DEBUG is not set Tomorrow I will try bootig with iommu=off, but my understanding was that if /sys/class/iommu was missing, iommu was disabled. Thans! -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #71 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- (In reply to Ricardo Ribalda from comment #69) > This is my kernel configuration: > > > ricardo@neopili:~/curro/kernel-upstream$ cat .config | grep -i IOMMU > CONFIG_GART_IOMMU=y > # CONFIG_CALGARY_IOMMU is not set > CONFIG_IOMMU_HELPER=y > CONFIG_IOMMU_SUPPORT=y > # Generic IOMMU Pagetable Support > # CONFIG_AMD_IOMMU is not set > # CONFIG_INTEL_IOMMU is not set > # CONFIG_IOMMU_DEBUG is not set > > > Tomorrow I will try bootig with iommu=off, but my understanding was that if > /sys/class/iommu was missing, iommu was disabled. Agreed. > > Thans! -- 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 198883] amdgpu: carrizo: Screen stalls after starting X
https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #70 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Just another while guess also , try mod probing amdgpu with power and clock gating disabled to see if it makes a difference sudo modprobe amdgpu cg_mask=0 pg_mask=0 -- 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
[PULL] drm-misc-next
Hi Dave,
Here's the last PR for 4.17 from -misc-next, we'll move over to -misc-next-fixes
once this is pulled. We have 2 weeks of work here, since I dropped the ball when
I was out sick last week.
2 things to point out: Lukas' device link work on vga_switcheroo is pretty
awesome, and lots of panel activity, which pumped up the diffstat a bit.
drm-misc-next-2018-03-21:
drm-misc-next for 4.17:
Cross-subsystem Changes:
dt-bindings: Add emtrion vendor prefix (Jan)
Core Changes:
drm_print: More object size reductions (Joe)
Driver Changes:
vc4: Fix alpha blending on bottom plane (Stefan)
panel: Add Raydium RM68200 panel support (Phillipe)
panel: Add AUO G104SN02 V2 panel support (Christoph)
panel: Add KEO TX31D200VM0BAA panel support (Jagan)
vga_switcheroo: Use device link to bookkeep HDA runtime pm (Lukas)
rockchip: More CrOS kevin patches trickling in (various
sun4i: Add A80 support (Chen-Yu)
sun4i: Add YUV plane support (Maxime)
meson: Multiple (mostly error-path) fixups (Christophe/Wei)
Cc: Stefan Schake
Cc: Philippe CORNU
Cc: jan.tu...@emtrion.com
Cc: Christoph Fritz
Cc: Jagan Teki
Cc: Lukas Wunner
Cc: Joe Perches
Cc: Chen-Yu Tsai
Cc: Christophe JAILLET
Cc: Wei Yongjun
Cheers, Sean
The following changes since commit 78230c46ec0a91dd4256c9e54934b3c7095a7ee3:
Merge tag 'omapdrm-4.17' of
git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux into drm-next
(2018-03-21 14:07:03 +1000)
are available in the Git repository at:
git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-03-21
for you to fetch changes up to 1c7095d2836baafd84e596dd34ba1a1293a4faa9:
Merge airlied/drm-next into drm-misc-next (2018-03-21 09:40:55 -0400)
drm-misc-next for 4.17:
Cross-subsystem Changes:
dt-bindings: Add emtrion vendor prefix (Jan)
Core Changes:
drm_print: More object size reductions (Joe)
Driver Changes:
vc4: Fix alpha blending on bottom plane (Stefan)
panel: Add Raydium RM68200 panel support (Phillipe)
panel: Add AUO G104SN02 V2 panel support (Christoph)
panel: Add KEO TX31D200VM0BAA panel support (Jagan)
vga_switcheroo: Use device link to bookkeep HDA runtime pm (Lukas)
rockchip: More CrOS kevin patches trickling in (various
sun4i: Add A80 support (Chen-Yu)
sun4i: Add YUV plane support (Maxime)
meson: Multiple (mostly error-path) fixups (Christophe/Wei)
Cc: Stefan Schake
Cc: Philippe CORNU
Cc: jan.tu...@emtrion.com
Cc: Christoph Fritz
Cc: Jagan Teki
Cc: Lukas Wunner
Cc: Joe Perches
Cc: Chen-Yu Tsai
Cc: Christophe JAILLET
Cc: Wei Yongjun
Arnd Bergmann (1):
drm/panel: rm68200: Add backlight dependency
Baruch Siach (1):
drm/panel: lvds: Fix driver description heading
Chen-Yu Tsai (5):
drm/sun4i: Add compatible strings for A80 TCONs
drm/sun4i: Add DT binding for Detail Enhancement Unit in Allwinner A80 SoC
drm/sun4i: Add support for A80 TCONs
drm/sun4i: Add compatible strings for the A80 display pipeline
drm/sun4i: Add driver support for A80 display pipeline
Chris Zhong (1):
drm/rockchip: cdn-dp: remove the DP phy switch
Christoph Fritz (1):
drm/panel: Add support for AUO G104SN02 V2 panel
Christophe JAILLET (3):
drm/meson: Fix an un-handled error path in 'meson_drv_bind_master()'
drm/meson: Use drm_dev_put() instead of drm_dev_unref()
drm/meson: Fix some error handling paths in 'meson_drv_bind_master()'
Daniel Vetter (1):
drm/doc: Put all driver docs into a separate chapter
Eric Anholt (1):
drm/panel: simple: Fix the bus format for the Ontat panel
Fabio Estevam (1):
drm/bridge: dw-hdmi: Remove unused hdmi_enable_overflow_interrupts()
Giulio Benetti (3):
drm/sun4i: move rgb mode_valid from connector to encoder
drm/sun4i: add lvds mode_valid function
drm/sun4i: Handle DRM_BUS_FLAG_PIXDATA_*EDGE
Gustavo A. R. Silva (1):
drm/vc4_validate: Remove VLA usage
Haneen Mohammed (2):
drm/vmwgfx: replace drm_*_unreference with drm_*_put
drm: remove drm_mode_object_{un/reference} aliases
Jagan Teki (1):
drm/panel: simple: Add support for KEO TX31D200VM0BAA
Joe Perches (2):
drm: Reduce object size of DRM_ERROR and DRM_DEBUG uses
drm: Reduce object size of DRM_DEV_ uses
José Roberto de Souza (1):
drm: Add PSR version 3 macro
Lukas Wunner (6):
PCI: Make pci_wakeup_bus() & pci_bus_set_current_state() public
vga_switcheroo: Update PCI current_state on power change
vga_switcheroo: Deduplicate power state tracking
vga_switcheroo: Use device link for HDA controller
vga_switcheroo: Let HDA autosuspend on mux change
drm/nouveau: Runtime suspend despite HDA being unbound
Marc Zyngier (3):
drm/rockchip: Clear all interrupts before requesting the IRQ
drm/rockchip: Do not use memcpy for MMIO addresses
drm/rockchip: Don't use s
[Bug 105664] AMD HAINAN (Radeon R5 M330) Clock frequency is 750MHz while it is supposed to be 1030MHz
https://bugs.freedesktop.org/show_bug.cgi?id=105664 Bug ID: 105664 Summary: AMD HAINAN (Radeon R5 M330) Clock frequency is 750MHz while it is supposed to be 1030MHz Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/Radeon Assignee: dri-devel@lists.freedesktop.org Reporter: yassine10s...@gmail.com Kernel source: /drivers/gpu/drm/radeon/si_dpm.c line 2985: max_sclk = 75000; instead of max_sclk = 103000; Why is that? I changed it and rebuilt the kernel, and I can say that there are absolutely no issues when using the 1030MHz clock, **which is the default frequency this GPU is designed for**. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm/xen-front: Add support for Xen PV display frontend
From: Oleksandr Andrushchenko Hello! This patch series adds support for Xen [1] para-virtualized frontend display driver. It implements the protocol from include/xen/interface/io/displif.h [2]. Accompanying backend [3] is implemented as a user-space application and its helper library [4], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [5]. *** * Driver limitations *** 1. Configuration options 1.1 (contiguous display buffers) and 2 (backend allocated buffers) below are not supported at the same time. 2. Only primary plane without additional properties is supported. 3. Only one video mode supported which resolution is configured via XenStore. 4. All CRTCs operate at fixed frequency of 60Hz. *** * Driver modes of operation in terms of display buffers used *** Depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. *** * 1. Buffers allocated by the frontend driver. *** The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. *** * 2. Buffers allocated by the backend *** This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. I would like to thank at least, but not at last the following people/communities who helped this driver to happen ;) 1. My team at EPAM for continuous support 2. Xen community for answering tons of questions on different modes of operation of the driver with respect to virtualized environment. 3. Rob Clark for "GEM allocation for para-virtualized DRM driver" [6] 4. Maarten Lankhorst for "Atomic driver and old remove FB behavior" [7] 5. Ville Syrjälä for "Questions on page flips and atomic modeset" [8] Changes since v2: *** - no changes to Xen related code (shared buffer handling, event channels etc.) - rework DRM driver release with hotplug (Daniel) - squash xen_drm_front and xen_drm_front_drv as they depend on each other too heavily now - remove platform driver and instantiate DRM device from xenbus driver directly - have serializing mutex per connector, not a single one, so we don't introduce a bottle neck for multiple connectors - minor comments addressed (Daniel) Changes since v1: *** - use SPDX license identifier, set license to GPLv2 OR MIT - changed midlayers to direct function calls, removed: - front_ops - gem_ops - renamed xenbus_driver callbacks to align with exisi
[PATCH v3] drm/xen-front: Add support for Xen PV display frontend
From: Oleksandr Andrushchenko Add support for Xen para-virtualized frontend display driver. Accompanying backend [1] is implemented as a user-space application and its helper library [2], capable of running as a Weston client or DRM master. Configuration of both backend and frontend is done via Xen guest domain configuration options [3]. Driver limitations: 1. Only primary plane without additional properties is supported. 2. Only one video mode supported which resolution is configured via XenStore. 3. All CRTCs operate at fixed frequency of 60Hz. 1. Implement Xen bus state machine for the frontend driver according to the state diagram and recovery flow from display para-virtualized protocol: xen/interface/io/displif.h. 2. Read configuration values from Xen store according to xen/interface/io/displif.h protocol: - read connector(s) configuration - read buffer allocation mode (backend/frontend) 3. Handle Xen event channels: - create for all configured connectors and publish corresponding ring references and event channels in Xen store, so backend can connect - implement event channels interrupt handlers - create and destroy event channels with respect to Xen bus state 4. Implement shared buffer handling according to the para-virtualized display device protocol at xen/interface/io/displif.h: - handle page directories according to displif protocol: - allocate and share page directories - grant references to the required set of pages for the page directory - allocate xen balllooned pages via Xen balloon driver with alloc_xenballooned_pages/free_xenballooned_pages - grant references to the required set of pages for the shared buffer itself - implement pages map/unmap for the buffers allocated by the backend (gnttab_map_refs/gnttab_unmap_refs) 5. Implement kernel modesetiing/connector handling using DRM simple KMS helper pipeline: - implement KMS part of the driver with the help of DRM simple pipepline helper which is possible due to the fact that the para-virtualized driver only supports a single (primary) plane: - initialize connectors according to XenStore configuration - handle frame done events from the backend - create and destroy frame buffers and propagate those to the backend - propagate set/reset mode configuration to the backend on display enable/disable callbacks - send page flip request to the backend and implement logic for reporting backend IO errors on prepare fb callback - implement virtual connector handling: - support only pixel formats suitable for single plane modes - make sure the connector is always connected - support a single video mode as per para-virtualized driver configuration 6. Implement GEM handling depending on driver mode of operation: depending on the requirements for the para-virtualized environment, namely requirements dictated by the accompanying DRM/(v)GPU drivers running in both host and guest environments, number of operating modes of para-virtualized display driver are supported: - display buffers can be allocated by either frontend driver or backend - display buffers can be allocated to be contiguous in memory or not Note! Frontend driver itself has no dependency on contiguous memory for its operation. 6.1. Buffers allocated by the frontend driver. The below modes of operation are configured at compile-time via frontend driver's kernel configuration. 6.1.1. Front driver configured to use GEM CMA helpers This use-case is useful when used with accompanying DRM/vGPU driver in guest domain which was designed to only work with contiguous buffers, e.g. DRM driver based on GEM CMA helpers: such drivers can only import contiguous PRIME buffers, thus requiring frontend driver to provide such. In order to implement this mode of operation para-virtualized frontend driver can be configured to use GEM CMA helpers. 6.1.2. Front driver doesn't use GEM CMA If accompanying drivers can cope with non-contiguous memory then, to lower pressure on CMA subsystem of the kernel, driver can allocate buffers from system memory. Note! If used with accompanying DRM/(v)GPU drivers this mode of operation may require IOMMU support on the platform, so accompanying DRM/vGPU hardware can still reach display buffer memory while importing PRIME buffers from the frontend driver. 6.2. Buffers allocated by the backend This mode of operation is run-time configured via guest domain configuration through XenStore entries. For systems which do not provide IOMMU support, but having specific requirements for display buffers it is possible to allocate such buffers at backend side and share those with the frontend. For example, if host domain is 1:1 mapped and has DRM/GPU hardware expecting physically contiguous memory, this allows implementing zero-copying use-cases. Note, while using this scenario the following should be considered: a) If guest domain dies
Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
Hi Sean & Rob, On Wed, Mar 21, 2018 at 10:01:07AM -0400, Sean Paul wrote: > On Tue, Mar 20, 2018 at 11:35:40PM -0400, Rob Clark wrote: > > On Tue, Mar 20, 2018 at 11:16 AM, Alexandru-Cosmin Gheorghe > > wrote: > > > On Tue, Mar 20, 2018 at 10:00:17AM -0400, Sean Paul wrote: > > >> On Tue, Mar 13, 2018 at 04:21:20PM +, Alexandru Gheorghe wrote: > > >> > This patchset tries to add support for using writeback connector to > > >> > flatten a scene when it doesn't change for a while. This idea had > > >> > been floated around on IRC here [1] and here [2]. > > >> > > > >> > Developed on top of the latest writeback series, sent by Liviu here > > >> > [3]. > > >> > > > >> > Probably the patch should/could be broken in more patches, but since I > > >> > want to put this out there to get feedback, I kept them as a single > > >> > patch for now. > > >> > > > >> > This change could be summarize as follow: > > >> > - Attach a writeback connector to the CRTC that's controlling a > > >> > display. > > >> > - Detect the scene did not change for a while(60 vblanks). > > >> > - Re-commit scene and get the composited scene through the writeback > > >> > connector. > > >> > - Commit the whole scene as a single plane. > > >> > > > >> > Some areas that I consider important and I could use some > > >> > feedback/ideas: > > >> > > > >> > 1. Building the pipeline. > > >> > Currently, drm_hwcomposer allows to connect just a single connector > > >> > to a crtc. For now, I decided to treat the writeback connector as a > > >> > separate field inside DrmCrtc. I'm not sure if it's a good idea to try > > >> > to handle this in a unified way, since the writeback connector is such > > >> > a special connector. Regarding the allocation of writeback connectors, > > >> > my idea was to allocate writeback connector to the primary display > > >> > first and then continue allocating while respecting the display > > >> > number. 0 > > >> > gets a writeback before 1 and so on. > > >> > > > >> > 2. Heuristic for triggering the flattening. > > >> > I just created a VSyncWorker which will trigger the flattening of the > > >> > scene if it doesn't change for 60 consecutive vsyncs. The countdown > > >> > gets reset every time ValidateDisplay is called. This is a relatively > > >> > basic heuristic, so I'm open to suggestions. > > >> > > > >> > 3. Locking scheme corner cases. > > >> > The Vsynworker is a separate thread which will contend with > > >> > SurfaceFlinger for showing things on the screen. I tried to limit the > > >> > race window by resetting the countdown on ValidateDisplay and > > >> > explicitely checking that we still need to use the flatten scene before > > >> > commiting to get the writeback result or before applying the flattened > > >> > scene. > > >> > > >> What are the consequences of the race? It seems like it might be > > >> possible that > > >> stale content will be shown over fresh? > > >> I think it'd be fine to serialize > > >> vsyncworker and "normal" commits such that the race window is closed > > >> instead of > > >> reduced. I think you could do the writeback operation asynchronously and > > >> then > > >> commit the result once it's ready, that shouldn't block things up too > > >> much. > > >> > > > > > > Just, to make sure we are on the same page, for Mali DP650 the pipeline > > > looks like this, I didn't see how it looks for the other hardware. > > > > > > CRTC encoder display connector > > > |--- writeback enc -- writeback connector. > > > > > > There is no asynchronously writeback operation, the scene that you > > > do writeback for will be shown on the display as well. > > > > > > > fwiw, the msm/mdp5 writeback support I implemented was using a > > different CRTC (ie. output going either to display or to wb).. (which > > unfortunately implies using different planes).. not sure how much this > > case is worth supporting in drm-hwc. Which case? With the same CRTC or different CRTCs, I think both could prove useful. > > Yeah, I wonder whether this is the method of operation we should focus on. > It's > unclear whether the restrictions Alex describes above are HW or SW limited, my > impression was SW. Of course, this means we'll need to disable WB if we are > using all crtcs (ie: external display connected), but that seems like a rare > usecase of Android, and one might argue that power savings are not as > important > in this case. > > Further, if we enable compositing with a dedicated WB pipe, we can also use it > for virtual displays. > > Sean For Mali DP-650 this is a HW requirement, we don't have any way of individually controlling just the writeback functionality without affecting what's sent to the display. > > > > > (I think I can do the single CRTC and multiple encoder cases, but it > > wasn't really obvious how to get that working with a video mode > > display and the hw I was working on didn't have a DSI cmd mode panel) > > > > BR, > > -R > > > > > Flatteni
Re: [PATCH libdrm 1/2] intel: Do not use libpciaccess on Android
On 20 March 2018 at 18:47, Eric Engestrom wrote:
> On Tuesday, 2018-03-20 17:36:51 +, Emil Velikov wrote:
>> From: Tomasz Figa
>>
>> This patch makes the code not rely anymore on libpciaccess when compiled
>> for Android to eliminate ioperm() and iopl() syscalls required by that
>> library. As a side effect, the mappable aperture size is hardcoded to 64
>> MiB on Android, however nothing seems to rely on this value anyway, as
>> checked be grepping relevant code in drm_gralloc and Mesa.
>>
>> Cc: John Stultz
>> Cc: Rob Herring
>> Cc: John Stultz
>> Cc: Tomasz Figa
>> Signed-off-by: Tomasz Figa
>> [Emil Velikov: rebase against master]
>> Signed-off-by: Emil Velikov
>> ---
>> Tomasz, I've taken the liberty of pulling the patch from the Android
>> tree. Hope you don't mind.
>> ---
>> intel/Android.mk | 3 +--
>> intel/intel_bufmgr.c | 12
>> 2 files changed, 13 insertions(+), 2 deletions(-)
>>
>> diff --git a/intel/Android.mk b/intel/Android.mk
>> index 3f9db785..dd881688 100644
>> --- a/intel/Android.mk
>> +++ b/intel/Android.mk
>> @@ -33,8 +33,7 @@ LOCAL_MODULE := libdrm_intel
>> LOCAL_SRC_FILES := $(LIBDRM_INTEL_FILES)
>>
>> LOCAL_SHARED_LIBRARIES := \
>> - libdrm \
>> - libpciaccess
>> + libdrm
>>
>> include $(LIBDRM_COMMON_MK)
>> include $(BUILD_SHARED_LIBRARY)
>> diff --git a/intel/intel_bufmgr.c b/intel/intel_bufmgr.c
>> index a2853400..42f5f62c 100644
>> --- a/intel/intel_bufmgr.c
>> +++ b/intel/intel_bufmgr.c
>> @@ -36,7 +36,9 @@
>> #include
>> #include
>> #include
>> +#ifndef __ANDROID__
>> #include
>> +#endif
>> #include "libdrm_macros.h"
>> #include "intel_bufmgr.h"
>> #include "intel_bufmgr_priv.h"
>> @@ -326,6 +328,7 @@ drm_intel_get_pipe_from_crtc_id(drm_intel_bufmgr
>> *bufmgr, int crtc_id)
>> return -1;
>> }
>>
>> +#ifndef __ANDROID__
>> static size_t
>> drm_intel_probe_agp_aperture_size(int fd)
>> {
>> @@ -351,6 +354,15 @@ err:
>> pci_system_cleanup ();
>> return size;
>> }
>> +#else
>> +static size_t
>> +drm_intel_probe_agp_aperture_size(int fd)
>> +{
>> + /* Nothing seems to rely on this value on Android anyway... */
>> + fprintf(stderr, "%s: Mappable aperture size hardcoded to 64MiB\n");
>
> Guessing there's a __func__ missing at the end there ^
>
Indeed - fixed locally. Can resent if the Android related people are
keen on the overall idea.
-Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
On Wed, Mar 21, 2018 at 10:01:07AM -0400, Sean Paul wrote: > On Tue, Mar 20, 2018 at 11:35:40PM -0400, Rob Clark wrote: > > On Tue, Mar 20, 2018 at 11:16 AM, Alexandru-Cosmin Gheorghe > > wrote: > > > On Tue, Mar 20, 2018 at 10:00:17AM -0400, Sean Paul wrote: > > >> On Tue, Mar 13, 2018 at 04:21:20PM +, Alexandru Gheorghe wrote: > > >> > This patchset tries to add support for using writeback connector to > > >> > flatten a scene when it doesn't change for a while. This idea had > > >> > been floated around on IRC here [1] and here [2]. > > >> > > > >> > Developed on top of the latest writeback series, sent by Liviu here > > >> > [3]. > > >> > > > >> > Probably the patch should/could be broken in more patches, but since I > > >> > want to put this out there to get feedback, I kept them as a single > > >> > patch for now. > > >> > > > >> > This change could be summarize as follow: > > >> > - Attach a writeback connector to the CRTC that's controlling a > > >> > display. > > >> > - Detect the scene did not change for a while(60 vblanks). > > >> > - Re-commit scene and get the composited scene through the writeback > > >> > connector. > > >> > - Commit the whole scene as a single plane. > > >> > > > >> > Some areas that I consider important and I could use some > > >> > feedback/ideas: > > >> > > > >> > 1. Building the pipeline. > > >> > Currently, drm_hwcomposer allows to connect just a single connector > > >> > to a crtc. For now, I decided to treat the writeback connector as a > > >> > separate field inside DrmCrtc. I'm not sure if it's a good idea to try > > >> > to handle this in a unified way, since the writeback connector is such > > >> > a special connector. Regarding the allocation of writeback connectors, > > >> > my idea was to allocate writeback connector to the primary display > > >> > first and then continue allocating while respecting the display > > >> > number. 0 > > >> > gets a writeback before 1 and so on. > > >> > > > >> > 2. Heuristic for triggering the flattening. > > >> > I just created a VSyncWorker which will trigger the flattening of the > > >> > scene if it doesn't change for 60 consecutive vsyncs. The countdown > > >> > gets reset every time ValidateDisplay is called. This is a relatively > > >> > basic heuristic, so I'm open to suggestions. > > >> > > > >> > 3. Locking scheme corner cases. > > >> > The Vsynworker is a separate thread which will contend with > > >> > SurfaceFlinger for showing things on the screen. I tried to limit the > > >> > race window by resetting the countdown on ValidateDisplay and > > >> > explicitely checking that we still need to use the flatten scene before > > >> > commiting to get the writeback result or before applying the flattened > > >> > scene. > > >> > > >> What are the consequences of the race? It seems like it might be > > >> possible that > > >> stale content will be shown over fresh? > > >> I think it'd be fine to serialize > > >> vsyncworker and "normal" commits such that the race window is closed > > >> instead of > > >> reduced. I think you could do the writeback operation asynchronously and > > >> then > > >> commit the result once it's ready, that shouldn't block things up too > > >> much. > > >> > > > > > > Just, to make sure we are on the same page, for Mali DP650 the pipeline > > > looks like this, I didn't see how it looks for the other hardware. > > > > > > CRTC encoder display connector > > > |--- writeback enc -- writeback connector. > > > > > > There is no asynchronously writeback operation, the scene that you > > > do writeback for will be shown on the display as well. > > > > > > > fwiw, the msm/mdp5 writeback support I implemented was using a > > different CRTC (ie. output going either to display or to wb).. (which > > unfortunately implies using different planes).. not sure how much this > > case is worth supporting in drm-hwc. > > Yeah, I wonder whether this is the method of operation we should focus on. > It's > unclear whether the restrictions Alex describes above are HW or SW limited, my > impression was SW. Of course, this means we'll need to disable WB if we are > using all crtcs (ie: external display connected), but that seems like a rare > usecase of Android, and one might argue that power savings are not as > important > in this case. When I've inquired on #dri-devel about possible usecase that makes use of the writeback functionality in the kernel, the flattening of layers was the one suggested by Sean and this is what Alex has implemented here. While we could re-focus on virtual displays I feel like this should be better tackled in a different patchset. Rob, how is any userspace supposed to drive your implementation? The framework patches pose no restriction in terms of how the connector gets attached to a CRTC. Are you saying that for msm/mdp5 we need to have an atomic commit where only the writeback connector is attached to one of the possible CRTCs and all the planes are
Re: [PATCH v3] drm/i915/gvt: throw error on unhandled vfio ioctls
On Wed, 21 Mar 2018 15:08:47 +0100 Gerd Hoffmann wrote: > On unknown/unhandled ioctls the driver should return an error, so > userspace knows it tried to use something unsupported. > > Cc: sta...@vger.kernel.org > Signed-off-by: Gerd Hoffmann > --- > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c > b/drivers/gpu/drm/i915/gvt/kvmgt.c > index 021f722e24..f34d7f1e6c 100644 > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c > @@ -1284,7 +1284,7 @@ static long intel_vgpu_ioctl(struct mdev_device *mdev, > unsigned int cmd, > > } > > - return 0; > + return -ENOTTY; > } > > static ssize_t Reviewed-by: Alex Williamson ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: udl: Properly check framebuffer mmap offsets
The memmap options sent to the udl framebuffer driver were not being
checked for all sets of possible crazy values. Fix this up by properly
bounding the allowed values.
Reported-by: Eyal Itkin
Cc: stable
Signed-off-by: Greg Kroah-Hartman
diff --git a/drivers/gpu/drm/udl/udl_fb.c b/drivers/gpu/drm/udl/udl_fb.c
index b5b335c9b2bb..2ebdc6d5a76e 100644
--- a/drivers/gpu/drm/udl/udl_fb.c
+++ b/drivers/gpu/drm/udl/udl_fb.c
@@ -159,10 +159,15 @@ static int udl_fb_mmap(struct fb_info *info, struct
vm_area_struct *vma)
{
unsigned long start = vma->vm_start;
unsigned long size = vma->vm_end - vma->vm_start;
- unsigned long offset = vma->vm_pgoff << PAGE_SHIFT;
+ unsigned long offset;
unsigned long page, pos;
- if (offset + size > info->fix.smem_len)
+ if (vma->vm_pgoff > (~0UL >> PAGE_SHIFT))
+ return -EINVAL;
+
+ offset = vma->vm_pgoff << PAGE_SHIFT;
+
+ if (offset > info->fix.smem_len || size > info->fix.smem_len - offset)
return -EINVAL;
pos = (unsigned long)info->fix.smem_start + offset;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH hwc v1] [RFC] drm_hwcomposer: Flatten composition using writeback connector
Rob Clark writes: > On Tue, Mar 20, 2018 at 11:16 AM, Alexandru-Cosmin Gheorghe > wrote: >> On Tue, Mar 20, 2018 at 10:00:17AM -0400, Sean Paul wrote: >>> On Tue, Mar 13, 2018 at 04:21:20PM +, Alexandru Gheorghe wrote: >>> > This patchset tries to add support for using writeback connector to >>> > flatten a scene when it doesn't change for a while. This idea had >>> > been floated around on IRC here [1] and here [2]. >>> > >>> > Developed on top of the latest writeback series, sent by Liviu here >>> > [3]. >>> > >>> > Probably the patch should/could be broken in more patches, but since I >>> > want to put this out there to get feedback, I kept them as a single >>> > patch for now. >>> > >>> > This change could be summarize as follow: >>> > - Attach a writeback connector to the CRTC that's controlling a >>> > display. >>> > - Detect the scene did not change for a while(60 vblanks). >>> > - Re-commit scene and get the composited scene through the writeback >>> > connector. >>> > - Commit the whole scene as a single plane. >>> > >>> > Some areas that I consider important and I could use some >>> > feedback/ideas: >>> > >>> > 1. Building the pipeline. >>> > Currently, drm_hwcomposer allows to connect just a single connector >>> > to a crtc. For now, I decided to treat the writeback connector as a >>> > separate field inside DrmCrtc. I'm not sure if it's a good idea to try >>> > to handle this in a unified way, since the writeback connector is such >>> > a special connector. Regarding the allocation of writeback connectors, >>> > my idea was to allocate writeback connector to the primary display >>> > first and then continue allocating while respecting the display number. 0 >>> > gets a writeback before 1 and so on. >>> > >>> > 2. Heuristic for triggering the flattening. >>> > I just created a VSyncWorker which will trigger the flattening of the >>> > scene if it doesn't change for 60 consecutive vsyncs. The countdown >>> > gets reset every time ValidateDisplay is called. This is a relatively >>> > basic heuristic, so I'm open to suggestions. >>> > >>> > 3. Locking scheme corner cases. >>> > The Vsynworker is a separate thread which will contend with >>> > SurfaceFlinger for showing things on the screen. I tried to limit the >>> > race window by resetting the countdown on ValidateDisplay and >>> > explicitely checking that we still need to use the flatten scene before >>> > commiting to get the writeback result or before applying the flattened >>> > scene. >>> >>> What are the consequences of the race? It seems like it might be possible >>> that >>> stale content will be shown over fresh? >>> I think it'd be fine to serialize >>> vsyncworker and "normal" commits such that the race window is closed >>> instead of >>> reduced. I think you could do the writeback operation asynchronously and >>> then >>> commit the result once it's ready, that shouldn't block things up too much. >>> >> >> Just, to make sure we are on the same page, for Mali DP650 the pipeline >> looks like this, I didn't see how it looks for the other hardware. >> >> CRTC encoder display connector >> |--- writeback enc -- writeback connector. >> >> There is no asynchronously writeback operation, the scene that you >> do writeback for will be shown on the display as well. >> > > fwiw, the msm/mdp5 writeback support I implemented was using a > different CRTC (ie. output going either to display or to wb).. (which > unfortunately implies using different planes).. not sure how much this > case is worth supporting in drm-hwc. This is also how VC4's writeback would work. signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 08/10] drm/fourcc: Add definitions for Allwinner vendor and MB32 tiled format
Hi Paul, On 21 March 2018 at 15:29, Paul Kocialkowski wrote: > +/* > + * Allwinner "MB32" tiled format > + * > + * This is the primary layout coming out of the VPU, where pixels are tiled > + * 32x32. > + */ Can you please be a bit more specific here, following the other examples? In particular, it should list whether the tile order is row- or column-major. Cheers, Daniel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105426] [regression] Mesa-18.0rc4 - black screen in some Valve games when run under Wine
https://bugs.freedesktop.org/show_bug.cgi?id=105426 --- Comment #7 from Tapani Pälli --- (In reply to iive from comment #6) > > It looks like the same problem as bug 104668 and bug 104777. > > 4195eed961ccfe404ae81b9112189fc93a254ded fixes the problem. > > Well, this is kind of expected, because the current git master does not have > that bug. > > However, the real bug I am reporting here is that > the above fix is not ported to the Mesa3D-18.0 branch. > > You definitely do not want to make a release containing that bug. Mentioned commit is in 18.0.0-rc5, please test. -- 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 3/6] drm/omap: Separate the dssdevs array setup from the connect function
In order to ease up on the logic, break the current code to gather the
dssdevs:
first get all available dssdevs, then call connect on each dssdev. As the
last step remove the dssdevs which failed to connect from the available
dssdev list.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 54 --
1 file changed, 40 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index 52cb8df04551..2cd2349622a9 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -165,34 +165,60 @@ static void omap_disconnect_dssdevs(struct drm_device
*ddev)
priv->num_dssdevs = 0;
}
-static int omap_connect_dssdevs(struct drm_device *ddev)
+static void omap_collect_dssdevs(struct drm_device *ddev)
{
struct omap_drm_private *priv = ddev->dev_private;
struct omap_dss_device *dssdev = NULL;
- int r;
+
+ for_each_dss_dev(dssdev) {
+ omap_dss_get_device(dssdev);
+ priv->dssdevs[priv->num_dssdevs++] = dssdev;
+ if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ /* To balance the 'for_each_dss_dev' loop */
+ omap_dss_put_device(dssdev);
+ break;
+ }
+ }
+}
+
+static int omap_connect_dssdevs(struct drm_device *ddev)
+{
+ struct omap_drm_private *priv = ddev->dev_private;
+ u32 working = 0;
+ int r, i, j;
if (!omapdss_stack_is_ready())
return -EPROBE_DEFER;
- for_each_dss_dev(dssdev) {
+ omap_collect_dssdevs(ddev);
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
+
r = dssdev->driver->connect(dssdev);
- if (r == -EPROBE_DEFER) {
- omap_dss_put_device(dssdev);
+ if (r == -EPROBE_DEFER)
goto cleanup;
- } else if (r) {
+ else if (r)
dev_warn(dssdev->dev, "could not connect display: %s\n",
- dssdev->name);
+dssdev->name);
+ else
+ working |= BIT(i);
+ }
+
+ /* Remove the dssdevs if their connect failed */
+ j = 0;
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ if (working & BIT(i)) {
+ if (j != i)
+ priv->dssdevs[j] = priv->dssdevs[i];
+ j++;
} else {
- omap_dss_get_device(dssdev);
- priv->dssdevs[priv->num_dssdevs++] = dssdev;
- if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
- /* To balance the 'for_each_dss_dev' loop */
- omap_dss_put_device(dssdev);
- break;
- }
+ omap_dss_put_device(priv->dssdevs[i]);
}
}
+ priv->num_dssdevs = j;
+
return 0;
cleanup:
--
Peter
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 2/2] drivers: remove force dma flag from buses
On Wed, Mar 21, 2018 at 04:28:46PM +, Nipun Gupta wrote: > > > > -Original Message- > > From: Greg KH [mailto:gre...@linuxfoundation.org] > > Sent: Wednesday, March 21, 2018 15:05 > > To: Nipun Gupta > > Cc: robin.mur...@arm.com; h...@lst.de; li...@armlinux.org.uk; > > m.szyprow...@samsung.com; bhelg...@google.com; zaj...@gmail.com; > > andy.gr...@linaro.org; david.br...@linaro.org; dan.j.willi...@intel.com; > > vinod.k...@intel.com; thierry.red...@gmail.com; robh...@kernel.org; > > frowand.l...@gmail.com; jarkko.sakki...@linux.intel.com; > > rafael.j.wyso...@intel.com; dmitry.torok...@gmail.com; jo...@kernel.org; > > msucha...@suse.de; linux-ker...@vger.kernel.org; iommu@lists.linux- > > foundation.org; linux-wirel...@vger.kernel.org; linux-arm- > > m...@vger.kernel.org; linux-...@vger.kernel.org; dmaeng...@vger.kernel.org; > > dri-devel@lists.freedesktop.org; linux-te...@vger.kernel.org; > > devicet...@vger.kernel.org; linux-...@vger.kernel.org; Bharat Bhushan > > ; Leo Li > > Subject: Re: [PATCH v2 2/2] drivers: remove force dma flag from buses > > > > On Wed, Mar 21, 2018 at 12:25:23PM +0530, Nipun Gupta wrote: > > > With each bus implementing its own DMA configuration callback, > > > there is no need for bus to explicitly have force_dma in its > > > global structure. This patch modifies of_dma_configure API to > > > accept an input parameter which specifies if implicit DMA > > > configuration is required even when it is not described by the > > > firmware. > > > > Having to "remember" what that bool variable means on the end of the > > function call is a royal pain over time, right? > > > > Why not just create a new function: > > dma_common_configure_force(dma) > > that always does this? Leave "dma_common_configure()" alone, and then > > wrap the old code with these two helper functions that call the 'core' > > code with the bool set properly? > > > > That way you do not have to "know" what that parameter is, the function > > name just documents it automatically, so when you see it in the > > bus-specific code, no need to go and have to hunt for anything. And if > > you are reading the dma core code, it's obvious what is happening as the > > functions are all right there. > > How about we do not pass any flag in 'dma_common_configure()', and inside this > API we pass "true" to 'of_dma_configure()'? I am saying this because currently > both the busses (platform and AMBA) which uses 'dma_common_configure()' passes > "true" value. If we create additional 'dma_common_configure_force()', then > 'dma_common_configure()' will not be used anytime and will become redundant. > > If someday new busses come and they needs to use similar functionality which > 'dma_common_configure()' provides, but with passing "false" to > 'of_dma_configure()', > then what you suggests of having two separate such API's will be more > reasonable > and can be implemented? If that makes things "simple", yes, sounds good. greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 105240] GPU lock-up when running QT5 based celestia
https://bugs.freedesktop.org/show_bug.cgi?id=105240 Hleb Valoshka <375...@gmail.com> changed: What|Removed |Added Version|unspecified |17.3 Product|DRI |Mesa Component|DRM/AMDgpu |Drivers/Gallium/radeonsi -- 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 105240] GPU lock-up when running QT5 based celestia
https://bugs.freedesktop.org/show_bug.cgi?id=105240 Hleb Valoshka <375...@gmail.com> changed: What|Removed |Added Assignee|dri-devel@lists.freedesktop |mesa-dev@lists.freedesktop. |.org|org -- 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 2/6] drm/omap: Manage the usable omap_dss_device list within omap_drm_private
Instead of reaching back to DSS to iterate through the dss_devices every
time, use an internal array where we store the available and usable
dss_devices.
At the same time remove the omapdss_device_is_connected() check from
omap_modeset_init() as it became irrelevant: We are not adding dssdevs
if their connect failed.
Signed-off-by: Peter Ujfalusi
---
drivers/gpu/drm/omapdrm/omap_drv.c | 95 +++---
drivers/gpu/drm/omapdrm/omap_drv.h | 3 ++
2 files changed, 62 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/omap_drv.c
b/drivers/gpu/drm/omapdrm/omap_drv.c
index aeef9e8e6932..52cb8df04551 100644
--- a/drivers/gpu/drm/omapdrm/omap_drv.c
+++ b/drivers/gpu/drm/omapdrm/omap_drv.c
@@ -149,18 +149,27 @@ static int get_connector_type(struct omap_dss_device
*dssdev)
}
}
-static void omap_disconnect_dssdevs(void)
+static void omap_disconnect_dssdevs(struct drm_device *ddev)
{
- struct omap_dss_device *dssdev = NULL;
+ struct omap_drm_private *priv = ddev->dev_private;
+ unsigned int i;
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
- for_each_dss_dev(dssdev)
dssdev->driver->disconnect(dssdev);
+ priv->dssdevs[i] = NULL;
+ omap_dss_put_device(dssdev);
+ }
+
+ priv->num_dssdevs = 0;
}
-static int omap_connect_dssdevs(void)
+static int omap_connect_dssdevs(struct drm_device *ddev)
{
- int r;
+ struct omap_drm_private *priv = ddev->dev_private;
struct omap_dss_device *dssdev = NULL;
+ int r;
if (!omapdss_stack_is_ready())
return -EPROBE_DEFER;
@@ -173,6 +182,14 @@ static int omap_connect_dssdevs(void)
} else if (r) {
dev_warn(dssdev->dev, "could not connect display: %s\n",
dssdev->name);
+ } else {
+ omap_dss_get_device(dssdev);
+ priv->dssdevs[priv->num_dssdevs++] = dssdev;
+ if (priv->num_dssdevs == ARRAY_SIZE(priv->dssdevs)) {
+ /* To balance the 'for_each_dss_dev' loop */
+ omap_dss_put_device(dssdev);
+ break;
+ }
}
}
@@ -183,7 +200,7 @@ static int omap_connect_dssdevs(void)
* if we are deferring probe, we disconnect the devices we previously
* connected
*/
- omap_disconnect_dssdevs();
+ omap_disconnect_dssdevs(ddev);
return r;
}
@@ -208,7 +225,7 @@ static int omap_modeset_init(struct drm_device *dev)
int num_ovls = priv->dispc_ops->get_num_ovls(priv->dispc);
int num_mgrs = priv->dispc_ops->get_num_mgrs(priv->dispc);
int num_crtcs, crtc_idx, plane_idx;
- int ret;
+ int ret, i;
u32 plane_crtc_mask;
drm_mode_config_init(dev);
@@ -225,11 +242,7 @@ static int omap_modeset_init(struct drm_device *dev)
* configuration does not match the expectations or exceeds
* the available resources, the configuration is rejected.
*/
- num_crtcs = 0;
- for_each_dss_dev(dssdev)
- if (omapdss_device_is_connected(dssdev))
- num_crtcs++;
-
+ num_crtcs = priv->num_dssdevs;
if (num_crtcs > num_mgrs || num_crtcs > num_ovls ||
num_crtcs > ARRAY_SIZE(priv->crtcs) ||
num_crtcs > ARRAY_SIZE(priv->planes) ||
@@ -247,15 +260,13 @@ static int omap_modeset_init(struct drm_device *dev)
crtc_idx = 0;
plane_idx = 0;
- for_each_dss_dev(dssdev) {
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
struct drm_connector *connector;
struct drm_encoder *encoder;
struct drm_plane *plane;
struct drm_crtc *crtc;
- if (!omapdss_device_is_connected(dssdev))
- continue;
-
encoder = omap_encoder_init(dev, dssdev);
if (!encoder)
return -ENOMEM;
@@ -335,11 +346,14 @@ static int omap_modeset_init(struct drm_device *dev)
/*
* Enable the HPD in external components if supported
*/
-static void omap_modeset_enable_external_hpd(void)
+static void omap_modeset_enable_external_hpd(struct drm_device *ddev)
{
- struct omap_dss_device *dssdev = NULL;
+ struct omap_drm_private *priv = ddev->dev_private;
+ int i;
+
+ for (i = 0; i < priv->num_dssdevs; i++) {
+ struct omap_dss_device *dssdev = priv->dssdevs[i];
- for_each_dss_dev(dssdev) {
if (dssdev->driver->enable_hpd)
dssdev->driver->enable_hpd(dssdev);
}
@@ -348,11 +362,14 @@ static void omap_modeset_enable_externa
[PATCH] drm/amd/pp: use mlck_table.count for array loop index limit
From: Colin Ian King
The for-loops process data in the mclk_table but use slck_table.count
as the loop index limit. I believe these are cut-n-paste errors from
the previous almost identical loops as indicated by static analysis.
Fix these.
Detected by CoverityScan, CID#1466001 ("Copy-paste error")
Fixes: 5d97cf39ff24 ("drm/amd/pp: Add and initialize OD_dpm_table for CI/VI.")
Fixes: 5e4d4fbea557 ("drm/amd/pp: Implement edit_dpm_table on smu7")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index df2a312ca6c9..d1983273ec7c 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -855,7 +855,7 @@ static int smu7_odn_initial_default_setting(struct pp_hwmgr
*hwmgr)
odn_table->odn_memory_clock_dpm_levels.num_of_pl =
data->golden_dpm_table.mclk_table.count;
- for (i=0; igolden_dpm_table.sclk_table.count; i++) {
+ for (i=0; igolden_dpm_table.mclk_table.count; i++) {
odn_table->odn_memory_clock_dpm_levels.entries[i].clock =
data->golden_dpm_table.mclk_table.dpm_levels[i].value;
odn_table->odn_memory_clock_dpm_levels.entries[i].enabled =
true;
@@ -4735,7 +4735,7 @@ static void smu7_check_dpm_table_updated(struct pp_hwmgr
*hwmgr)
}
}
- for (i=0; idpm_table.sclk_table.count; i++) {
+ for (i=0; idpm_table.mclk_table.count; i++) {
if (odn_table->odn_memory_clock_dpm_levels.entries[i].clock !=
data->dpm_table.mclk_table.dpm_levels[i].value) {
data->need_update_smu7_dpm_table |=
DPMTABLE_OD_UPDATE_MCLK;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/amd/pp: use mlck_table.count for array loop index limit
On Wed, 2018-03-21 at 18:26 +, Colin King wrote:
> From: Colin Ian King
>
> The for-loops process data in the mclk_table but use slck_table.count
> as the loop index limit. I believe these are cut-n-paste errors from
> the previous almost identical loops as indicated by static analysis.
> Fix these.
Nice tool.
> diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
> b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
[]
> @@ -855,7 +855,7 @@ static int smu7_odn_initial_default_setting(struct
> pp_hwmgr *hwmgr)
>
> odn_table->odn_memory_clock_dpm_levels.num_of_pl =
>
> data->golden_dpm_table.mclk_table.count;
> - for (i=0; igolden_dpm_table.sclk_table.count; i++) {
> + for (i=0; igolden_dpm_table.mclk_table.count; i++) {
> odn_table->odn_memory_clock_dpm_levels.entries[i].clock =
>
> data->golden_dpm_table.mclk_table.dpm_levels[i].value;
> odn_table->odn_memory_clock_dpm_levels.entries[i].enabled =
> true;
Probably more sensible to use temporaries too.
Maybe something like the below (also trivially reduces object size)
---
drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c | 19 ++-
1 file changed, 10 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index df2a312ca6c9..339b897146af 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -834,6 +834,7 @@ static int smu7_odn_initial_default_setting(struct pp_hwmgr
*hwmgr)
struct phm_ppt_v1_clock_voltage_dependency_table *dep_sclk_table;
struct phm_ppt_v1_clock_voltage_dependency_table *dep_mclk_table;
+ struct phm_odn_performance_level *entries;
if (table_info == NULL)
return -EINVAL;
@@ -843,11 +844,11 @@ static int smu7_odn_initial_default_setting(struct
pp_hwmgr *hwmgr)
odn_table->odn_core_clock_dpm_levels.num_of_pl =
data->golden_dpm_table.sclk_table.count;
+ entries = odn_table->odn_core_clock_dpm_levels.entries;
for (i=0; igolden_dpm_table.sclk_table.count; i++) {
- odn_table->odn_core_clock_dpm_levels.entries[i].clock =
-
data->golden_dpm_table.sclk_table.dpm_levels[i].value;
- odn_table->odn_core_clock_dpm_levels.entries[i].enabled = true;
- odn_table->odn_core_clock_dpm_levels.entries[i].vddc =
dep_sclk_table->entries[i].vddc;
+ entries[i].clock =
data->golden_dpm_table.sclk_table.dpm_levels[i].value;
+ entries[i].enabled = true;
+ entries[i].vddc = dep_sclk_table->entries[i].vddc;
}
smu7_get_voltage_dependency_table(dep_sclk_table,
@@ -855,11 +856,11 @@ static int smu7_odn_initial_default_setting(struct
pp_hwmgr *hwmgr)
odn_table->odn_memory_clock_dpm_levels.num_of_pl =
data->golden_dpm_table.mclk_table.count;
- for (i=0; igolden_dpm_table.sclk_table.count; i++) {
- odn_table->odn_memory_clock_dpm_levels.entries[i].clock =
-
data->golden_dpm_table.mclk_table.dpm_levels[i].value;
- odn_table->odn_memory_clock_dpm_levels.entries[i].enabled =
true;
- odn_table->odn_memory_clock_dpm_levels.entries[i].vddc =
dep_mclk_table->entries[i].vddc;
+ entries = odn_table->odn_memory_clock_dpm_levels.entries;
+ for (i=0; igolden_dpm_table.mclk_table.count; i++) {
+ entries[i].clock =
data->golden_dpm_table.mclk_table.dpm_levels[i].value;
+ entries[i].enabled = true;
+ entries[i].vddc = dep_mclk_table->entries[i].vddc;
}
smu7_get_voltage_dependency_table(dep_mclk_table,
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
From: Colin Ian King
The pointer workload is dereferenced before it is null checked, hence
there is a potential for a null pointer dereference on workload. Fix
this by only dereferencing workload after it is null checked.
Detected by CoverityScan, CID#1466017 ("Dereference before null check")
Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 068126404151..f3010e365a48 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
static void sr_oa_regs(struct intel_vgpu_workload *workload,
u32 *reg_state, bool save)
{
- struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
- u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
- u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+ struct drm_i915_private *dev_priv;
+ u32 ctx_oactxctrl;
+ u32 ctx_flexeu0;
int i = 0;
u32 flex_mmio[] = {
i915_mmio_reg_offset(EU_PERF_CNTL0),
@@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
if (!workload || !reg_state || workload->ring_id != RCS)
return;
+ dev_priv = workload->vgpu->gvt->dev_priv;
+ ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
+ ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
+
if (save) {
workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> From: Colin Ian King
>
> The pointer workload is dereferenced before it is null checked, hence
> there is a potential for a null pointer dereference on workload. Fix
> this by only dereferencing workload after it is null checked.
>
> Detected by CoverityScan, CID#1466017 ("Dereference before null check")
Maybe true, but is it possible for workload to be null?
Maybe the null test should be removed instead.
> Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
> b/drivers/gpu/drm/i915/gvt/scheduler.c
> index 068126404151..f3010e365a48 100644
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
> static void sr_oa_regs(struct intel_vgpu_workload *workload,
> u32 *reg_state, bool save)
> {
> - struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> - u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> - u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> + struct drm_i915_private *dev_priv;
> + u32 ctx_oactxctrl;
> + u32 ctx_flexeu0;
> int i = 0;
> u32 flex_mmio[] = {
> i915_mmio_reg_offset(EU_PERF_CNTL0),
> @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload
> *workload,
> if (!workload || !reg_state || workload->ring_id != RCS)
> return;
>
> + dev_priv = workload->vgpu->gvt->dev_priv;
> + ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> + ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> +
> if (save) {
> workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
On 21/03/18 19:09, Joe Perches wrote:
> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
>> From: Colin Ian King
>>
>> The pointer workload is dereferenced before it is null checked, hence
>> there is a potential for a null pointer dereference on workload. Fix
>> this by only dereferencing workload after it is null checked.
>>
>> Detected by CoverityScan, CID#1466017 ("Dereference before null check")
>
> Maybe true, but is it possible for workload to be null?
> Maybe the null test should be removed instead.
From what I understand from the static analysis, there may be a
potential for workload to be null, I couldn't rule it out so I went with
the more paranoid stance of keeping the null check in.
>
>> Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
>> Signed-off-by: Colin Ian King
>> ---
>> drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
>> 1 file changed, 7 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
>> b/drivers/gpu/drm/i915/gvt/scheduler.c
>> index 068126404151..f3010e365a48 100644
>> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
>> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
>> @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
>> static void sr_oa_regs(struct intel_vgpu_workload *workload,
>> u32 *reg_state, bool save)
>> {
>> -struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
>> -u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>> -u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>> +struct drm_i915_private *dev_priv;
>> +u32 ctx_oactxctrl;
>> +u32 ctx_flexeu0;
>> int i = 0;
>> u32 flex_mmio[] = {
>> i915_mmio_reg_offset(EU_PERF_CNTL0),
>> @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload
>> *workload,
>> if (!workload || !reg_state || workload->ring_id != RCS)
>> return;
>>
>> +dev_priv = workload->vgpu->gvt->dev_priv;
>> +ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
>> +ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
>> +
>> if (save) {
>> workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
>>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
Quoting Colin Ian King (2018-03-21 19:18:28)
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> >> From: Colin Ian King
> >>
> >> The pointer workload is dereferenced before it is null checked, hence
> >> there is a potential for a null pointer dereference on workload. Fix
> >> this by only dereferencing workload after it is null checked.
> >>
> >> Detected by CoverityScan, CID#1466017 ("Dereference before null check")
> >
> > Maybe true, but is it possible for workload to be null?
> > Maybe the null test should be removed instead.
>
> From what I understand from the static analysis, there may be a
> potential for workload to be null, I couldn't rule it out so I went with
> the more paranoid stance of keeping the null check in.
Not sr_oa_regs() problem if workload is NULL, that's the callers. I
reviewed the identical patch yesterday, and we ended up with removing
the NULL checks, just keeping the workload->id != RCS.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
On Wed, 2018-03-21 at 19:18 +, Colin Ian King wrote:
> On 21/03/18 19:09, Joe Perches wrote:
> > On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
> > > From: Colin Ian King
> > >
> > > The pointer workload is dereferenced before it is null checked, hence
> > > there is a potential for a null pointer dereference on workload. Fix
> > > this by only dereferencing workload after it is null checked.
> > >
> > > Detected by CoverityScan, CID#1466017 ("Dereference before null check")
> >
> > Maybe true, but is it possible for workload to be null?
> > Maybe the null test should be removed instead.
>
> From what I understand from the static analysis, there may be a
> potential for workload to be null, I couldn't rule it out so I went with
> the more paranoid stance of keeping the null check in.
workload cannot be null here.
Look at the uses of sr_oa_regs and see that
workload has already been dereferenced.
> >
> > > Fixes: fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
> > > Signed-off-by: Colin Ian King
> > > ---
> > > drivers/gpu/drm/i915/gvt/scheduler.c | 10 +++---
> > > 1 file changed, 7 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > index 068126404151..f3010e365a48 100644
> > > --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> > > +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> > > @@ -60,9 +60,9 @@ static void set_context_pdp_root_pointer(
> > > static void sr_oa_regs(struct intel_vgpu_workload *workload,
> > > u32 *reg_state, bool save)
> > > {
> > > - struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> > > - u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> > > - u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> > > + struct drm_i915_private *dev_priv;
> > > + u32 ctx_oactxctrl;
> > > + u32 ctx_flexeu0;
> > > int i = 0;
> > > u32 flex_mmio[] = {
> > > i915_mmio_reg_offset(EU_PERF_CNTL0),
> > > @@ -77,6 +77,10 @@ static void sr_oa_regs(struct intel_vgpu_workload
> > > *workload,
> > > if (!workload || !reg_state || workload->ring_id != RCS)
> > > return;
> > >
> > > + dev_priv = workload->vgpu->gvt->dev_priv;
> > > + ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> > > + ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> > > +
> > > if (save) {
> > > workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
> > >
>
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/i915/gvt: don't dereference 'workload' before null checking it
On 21/03/18 19:23, Chris Wilson wrote:
> Quoting Colin Ian King (2018-03-21 19:18:28)
>> On 21/03/18 19:09, Joe Perches wrote:
>>> On Wed, 2018-03-21 at 19:06 +, Colin King wrote:
From: Colin Ian King
The pointer workload is dereferenced before it is null checked, hence
there is a potential for a null pointer dereference on workload. Fix
this by only dereferencing workload after it is null checked.
Detected by CoverityScan, CID#1466017 ("Dereference before null check")
>>>
>>> Maybe true, but is it possible for workload to be null?
>>> Maybe the null test should be removed instead.
>>
>> From what I understand from the static analysis, there may be a
>> potential for workload to be null, I couldn't rule it out so I went with
>> the more paranoid stance of keeping the null check in.
>
> Not sr_oa_regs() problem if workload is NULL, that's the callers. I
> reviewed the identical patch yesterday, and we ended up with removing
> the NULL checks, just keeping the workload->id != RCS.
> -Chris
>
Ah, OK, thanks for the clarification Chris.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/7] drm/panel: add panel CDTech S043WQ26H-CT7 to panel-simple
Signed-off-by: Giulio Benetti
---
.../display/panel/cdtech,s043wq26h-ct7.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 28 ++
2 files changed, 35 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
new file mode 100644
index 000..a22af85
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s043wq26h-ct7.txt
@@ -0,0 +1,7 @@
+CDTech(H.K.) Electronics Limited 4.3" 480x272 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s043wq26h-ct7"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 714fbdd..5e0c6d9 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -764,6 +764,31 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode cdtech_s043wq26h_ct7_mode = {
+ .clock = 9000,
+ .hdisplay = 480,
+ .hsync_start = 480 + 5,
+ .hsync_end = 480 + 5 + 5,
+ .htotal = 480 + 5 + 5 + 40,
+ .vdisplay = 272,
+ .vsync_start = 272 + 8,
+ .vsync_end = 272 + 8 + 8,
+ .vtotal = 272 + 8 + 8 + 8,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc cdtech_s043wq26h_ct7 = {
+ .modes = &cdtech_s043wq26h_ct7_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 95,
+ .height = 54,
+ },
+ .bus_flags = DRM_BUS_FLAG_PIXDATA_POSEDGE,
+};
+
static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
.clock = 35000,
.hdisplay = 800,
@@ -2091,6 +2116,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
+ .compatible = "cdtech,s043wq26h-ct7",
+ .data = &cdtech_s043wq26h_ct7,
+ }, {
.compatible = "cdtech,s070wv95-ct16",
.data = &cdtech_s070wv95_ct16,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/7] dt-bindings: add micronova vendor prefix
This adds a vendor prefix "micronova" for Micronova srl Signed-off-by: Giulio Benetti --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index 9854399..b07d1fc 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -217,6 +217,7 @@ micrel Micrel Inc. microchip Microchip Technology Inc. microcrystal Micro Crystal AG micron Micron Technology Inc. +micronova Micronova srl minix MINIX Technology Ltd. miramems MiraMEMS Sensing Technology Co., Ltd. mitsubishi Mitsubishi Electric Corporation -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 4/7] ARM: dts: sun7i: Add pinmux settings for LCD0 RGB888 output.
The A20 supports RGB888 with H/V sync from LCD0. Add a pinmux setting
for the needed pins.
Signed-off-by: Giulio Benetti
---
arch/arm/boot/dts/sun7i-a20.dtsi | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index efb5607..bfe6728 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -922,6 +922,14 @@
pins = "PI20", "PI21";
function = "uart7";
};
+
+ lcd0_rgb888_pins: lcd0-rgb888-pins {
+ pins = "PD0", "PD1", "PD2", "PD3", "PD4",
"PD5", "PD6", "PD7",
+ "PD8", "PD9", "PD10", "PD11", "PD12",
"PD13", "PD14", "PD15",
+ "PD16", "PD17", "PD18", "PD19", "PD20",
"PD21", "PD22", "PD23",
+ "PD24", "PD25", "PD26", "PD27";
+ function = "lcd0";
+ };
};
timer@1c20c00 {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/7] drm/panel: add panel CDTech S070_WV95_CT16 to panel-simple
Signed-off-by: Giulio Benetti
---
.../display/panel/cdtech,s070wv95-ct16.txt | 7 ++
drivers/gpu/drm/panel/panel-simple.c | 27 ++
2 files changed, 34 insertions(+)
create mode 100644
Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
diff --git
a/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
new file mode 100644
index 000..b00d6c7
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/panel/cdtech,s070wv95-ct16.txt
@@ -0,0 +1,7 @@
+CDTech(H.K.) Electronics Limited 7" 800x480 color TFT-LCD panel
+
+Required properties:
+- compatible: should be "cdtech,s070wv95-ct16"
+
+This binding is compatible with the simple-panel binding, which is specified
+in simple-panel.txt in this directory.
diff --git a/drivers/gpu/drm/panel/panel-simple.c
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984..714fbdd 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -764,6 +764,30 @@ static const struct panel_desc boe_nv101wxmn51 = {
},
};
+static const struct drm_display_mode cdtech_s070wv95_ct16_mode = {
+ .clock = 35000,
+ .hdisplay = 800,
+ .hsync_start = 800 + 40,
+ .hsync_end = 800 + 40 + 40,
+ .htotal = 800 + 40 + 40 + 48,
+ .vdisplay = 480,
+ .vsync_start = 480 + 29,
+ .vsync_end = 480 + 29 + 13,
+ .vtotal = 480 + 29 + 13 + 3,
+ .vrefresh = 60,
+ .flags = DRM_MODE_FLAG_NHSYNC | DRM_MODE_FLAG_NVSYNC,
+};
+
+static const struct panel_desc cdtech_s070wv95_ct16 = {
+ .modes = &cdtech_s070wv95_ct16_mode,
+ .num_modes = 1,
+ .bpc = 8,
+ .size = {
+ .width = 154,
+ .height = 85,
+ },
+};
+
static const struct drm_display_mode chunghwa_claa070wp03xg_mode = {
.clock = 66770,
.hdisplay = 800,
@@ -2067,6 +2091,9 @@ static const struct of_device_id platform_of_match[] = {
.compatible = "boe,nv101wxmn51",
.data = &boe_nv101wxmn51,
}, {
+ .compatible = "cdtech,s070wv95-ct16",
+ .data = &cdtech_s070wv95_ct16,
+ }, {
.compatible = "chunghwa,claa070wp03xg",
.data = &chunghwa_claa070wp03xg,
}, {
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 6/7] ARM: dts: sun7i: Add dts file for the A20-linova1-4_3 HMI
The A20-Linova1-4_3 HMI, also called Q027_2_A which is printed on
production label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 4.3" 24-bits Tft 480x272 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti
---
.../devicetree/bindings/arm/micronova.txt | 6 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts | 192 +
3 files changed, 199 insertions(+)
create mode 100644 Documentation/devicetree/bindings/arm/micronova.txt
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
diff --git a/Documentation/devicetree/bindings/arm/micronova.txt
b/Documentation/devicetree/bindings/arm/micronova.txt
new file mode 100644
index 000..35c4127
--- /dev/null
+++ b/Documentation/devicetree/bindings/arm/micronova.txt
@@ -0,0 +1,6 @@
+Micronova Device Tree Bindings
+---
+
+A20-LiNova1-4_3 HMI
+Required root node properties:
+- compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index ade7a38..c45a4f25 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -941,6 +941,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-lamobo-r1.dtb \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
+ sun7i-a20-linova1-ctp-4_3i.dtb\
sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
new file mode 100644
index 000..cd4ac73
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-4_3i.dts
@@ -0,0 +1,192 @@
+/*
+ * This is based on sun7i-a20-linova1-ctp-4_3i.dts
+ *
+ * Copyright 2014 - Hans de Goede
+ * Copyright (c) 2014 FUKAUMI Naoki
+ * Copyright (c) 2018 Giulio Benetti
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Micronova srl LiNova1 CTP 4.3i";
+ compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+ panel: panel {
+ co
[PATCH 1/7] dt-bindings: add cdtech vendor prefix
This adds a vendor prefix "cdtech" for CDTech(H.K.) Electronics Limited Signed-off-by: Giulio Benetti --- Documentation/devicetree/bindings/vendor-prefixes.txt | 1 + 1 file changed, 1 insertion(+) diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt b/Documentation/devicetree/bindings/vendor-prefixes.txt index ae850d6..9854399 100644 --- a/Documentation/devicetree/bindings/vendor-prefixes.txt +++ b/Documentation/devicetree/bindings/vendor-prefixes.txt @@ -61,6 +61,7 @@ capella Capella Microsystems, Inc cascodaCascoda, Ltd. cavium Cavium, Inc. cdns Cadence Design Systems Inc. +cdtech CDTech(H.K.) Electronics Limited ceva Ceva, Inc. chipidea Chipidea, Inc chiponeChipOne -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI
The A20-Linova1-7 HMI, also called Q027_2_F which is printed on production
label, is an industrial Human Machine Interface.
It features:
- 512MB DDR RAM
- 1 Sd-card >= 4GB
- 1 Usb otg(programmable via software) with A-Usb Connector
- 1 Usb host
- 1 Buzzer
- 1 Input for LiPo
- 1 Relay to signal absence of power supply
- 1 External Rtc with 56 bytes of ram + CR2032 battery
- 1 7" 24-bits Tft 800x480 with PCap on
- 1 Mono audio 1-watt amplifier
- 1 RS485 port
- 1 Power On Line through +12Vdc reaching 57.600baud,
from where it can be supplied and placed in a network of 50 units
- exposed jtag pins
HMI is supplied from +12Vdc.
Ethernet is absent, so for debugging, need to enable rndis on Usb otg
port through an A-A usb cable.
It comes in different flavours for connector types and can be found with
umounted features as requested by customers.
Signed-off-by: Giulio Benetti
---
.../devicetree/bindings/arm/micronova.txt | 4 +
arch/arm/boot/dts/Makefile | 1 +
arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts | 192 +
3 files changed, 197 insertions(+)
create mode 100644 arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
diff --git a/Documentation/devicetree/bindings/arm/micronova.txt
b/Documentation/devicetree/bindings/arm/micronova.txt
index 35c4127..9f5ac72 100644
--- a/Documentation/devicetree/bindings/arm/micronova.txt
+++ b/Documentation/devicetree/bindings/arm/micronova.txt
@@ -4,3 +4,7 @@ Micronova Device Tree Bindings
A20-LiNova1-4_3 HMI
Required root node properties:
- compatible = "micronova,a20-linova1-ctp-4_3i", "allwinner,sun7i-a20";
+
+A20-LiNova1-7 HMI
+Required root node properties:
+- compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index c45a4f25..eafa7cb 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -942,6 +942,7 @@ dtb-$(CONFIG_MACH_SUN7I) += \
sun7i-a20-m3.dtb \
sun7i-a20-mk808c.dtb \
sun7i-a20-linova1-ctp-4_3i.dtb\
+ sun7i-a20-linova1-ctp-7i.dtb\
sun7i-a20-olimex-som-evb.dtb \
sun7i-a20-olinuxino-lime.dtb \
sun7i-a20-olinuxino-lime2.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
new file mode 100644
index 000..7fd0d98
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-linova1-ctp-7i.dts
@@ -0,0 +1,192 @@
+/*
+ * This is based on sun7i-a20-linova1-ctp-7i.dts
+ *
+ * Copyright 2014 - Hans de Goede
+ * Copyright (c) 2014 FUKAUMI Naoki
+ * Copyright (c) 2018 Giulio Benetti
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ * a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ * b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include
+#include
+
+/ {
+ model = "Micronova srl LiNova1 CTP 7i";
+ compatible = "micronova,a20-linova1-ctp-7i", "allwinner,sun7i-a20";
+
+ aliases {
+ serial0 = &uart0;
+ };
+
+ chosen {
+ stdout-path = "serial0:115200n8";
+ };
+
+
Re: drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type
On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote: > Hi, Ville, > > On 11/14/2017 07:32 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Currently userspace is allowed to feed in any king of garbage in the > > high bits of the mode flags/type, as are drivers when probing modes. > > Reject any mode with bogus flags/type. > > > > Hopefully this won't break any current userspace... > > Unfortunately this breaks xf86-video-vmware which currently leaves the > mode->type uninitialized :(. > That code is inherited from the old gallium xorg state tracker. I don't > know whether it has spread elsewhere but the symptoms are that the X > server frequently dies failing to set screen resources, a very > uninformative error. > > I'll fix the xf86-video-vmware driver, but I guess we need to back out > the mode->type check. Dang. So the flags check is fine but type check is not? -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type
Hi, Ville, On 11/14/2017 07:32 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently userspace is allowed to feed in any king of garbage in the high bits of the mode flags/type, as are drivers when probing modes. Reject any mode with bogus flags/type. Hopefully this won't break any current userspace... Unfortunately this breaks xf86-video-vmware which currently leaves the mode->type uninitialized :(. That code is inherited from the old gallium xorg state tracker. I don't know whether it has spread elsewhere but the symptoms are that the X server frequently dies failing to set screen resources, a very uninformative error. I'll fix the xf86-video-vmware driver, but I guess we need to back out the mode->type check. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm-next xf86-video-vmware breakage Was [PATCH 02/10] drm/uapi: Validate the mode flags/type
On 03/21/2018 09:51 PM, Ville Syrjälä wrote: On Wed, Mar 21, 2018 at 09:45:09PM +0100, Thomas Hellstrom wrote: Hi, Ville, On 11/14/2017 07:32 PM, Ville Syrjala wrote: From: Ville Syrjälä Currently userspace is allowed to feed in any king of garbage in the high bits of the mode flags/type, as are drivers when probing modes. Reject any mode with bogus flags/type. Hopefully this won't break any current userspace... Unfortunately this breaks xf86-video-vmware which currently leaves the mode->type uninitialized :(. That code is inherited from the old gallium xorg state tracker. I don't know whether it has spread elsewhere but the symptoms are that the X server frequently dies failing to set screen resources, a very uninformative error. I'll fix the xf86-video-vmware driver, but I guess we need to back out the mode->type check. Dang. So the flags check is fine but type check is not? Yes, we copy the flags field untranslated from xorg's DisplayModePtr::Flags field which seems to be what xf86-video-modesetting does as well, so I guess we should be OK there. /Thomas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: Fix uabi regression by allowing garbage mode->type from userspace
From: Ville Syrjälä
Apparently xf86-video-vmware leaves the mode->type uninitialized
when feeding the mode to the kernel. Thus we have no choice but
to accept the garbage in. We'll just ignore any of the bits we
don't want. The mode type is just a hint anyway, and more
useful for the kernel->userspace direction.
Reported-by: Thomas Hellstrom
CC: Thomas Hellstrom
Cc: Adam Jackson
Cc: Alex Deucher
Fixes: c6ed6dad5cfb ("drm/uapi: Validate the mode flags/type")
References:
https://lists.freedesktop.org/archives/dri-devel/2018-March/170213.html
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_modes.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c
index f6b7c0e36a1a..e82b61e08f8c 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -1611,7 +1611,13 @@ int drm_mode_convert_umode(struct drm_device *dev,
out->vscan = in->vscan;
out->vrefresh = in->vrefresh;
out->flags = in->flags;
- out->type = in->type;
+ /*
+* Old xf86-video-vmware (possibly others too) used to
+* leave 'type' unititialized. Just ignore any bits we
+* don't like. It's a just hint after all, and more
+* useful for the kernel->userspace direction anyway.
+*/
+ out->type = in->type & DRM_MODE_TYPE_ALL;
strncpy(out->name, in->name, DRM_DISPLAY_MODE_LEN);
out->name[DRM_DISPLAY_MODE_LEN-1] = 0;
--
2.16.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=104064 --- Comment #40 from taij...@posteo.de --- OK, I hate to be necrobumping this, but I've continued to follow and test drm-next-4.17-wip and it seems that not only has the backlight patch from #34 not made it in yet, but also that the forced atpx option from #14 has also disappeared after all of the vega12 additions. S, are these things going to come back? -- 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
[trivial PATCH V2] treewide: Align function definition open/close braces
Some functions definitions have either the initial open brace and/or
the closing brace outside of column 1.
Move those braces to column 1.
This allows various function analyzers like gnu complexity to work
properly for these modified functions.
Signed-off-by: Joe Perches
Acked-by: Andy Shevchenko
Acked-by: Paul Moore
Acked-by: Alex Deucher
Acked-by: Dave Chinner
Reviewed-by: Darrick J. Wong
Acked-by: Alexandre Belloni
Acked-by: Martin K. Petersen
Acked-by: Takashi Iwai
Acked-by: Mauro Carvalho Chehab
---
git diff -w still shows no difference.
This patch was sent but December and not applied.
As the trivial maintainer seems not active, it'd be nice if
Andrew Morton picks this up.
V2: Remove fs/xfs/libxfs/xfs_alloc.c as it's updated and remerge the rest
arch/x86/include/asm/atomic64_32.h | 2 +-
drivers/acpi/custom_method.c | 2 +-
drivers/acpi/fan.c | 2 +-
drivers/gpu/drm/amd/display/dc/core/dc.c | 2 +-
drivers/media/i2c/msp3400-kthreads.c | 2 +-
drivers/message/fusion/mptsas.c | 2 +-
drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c | 2 +-
drivers/net/wireless/ath/ath9k/xmit.c| 2 +-
drivers/platform/x86/eeepc-laptop.c | 2 +-
drivers/rtc/rtc-ab-b5ze-s3.c | 2 +-
drivers/scsi/dpt_i2o.c | 2 +-
drivers/scsi/sym53c8xx_2/sym_glue.c | 2 +-
fs/locks.c | 2 +-
fs/ocfs2/stack_user.c| 2 +-
fs/xfs/xfs_export.c | 2 +-
kernel/audit.c | 6 +++---
kernel/trace/trace_printk.c | 4 ++--
lib/raid6/sse2.c | 14 +++---
sound/soc/fsl/fsl_dma.c | 2 +-
19 files changed, 28 insertions(+), 28 deletions(-)
diff --git a/arch/x86/include/asm/atomic64_32.h
b/arch/x86/include/asm/atomic64_32.h
index 46e1ef17d92d..92212bf0484f 100644
--- a/arch/x86/include/asm/atomic64_32.h
+++ b/arch/x86/include/asm/atomic64_32.h
@@ -123,7 +123,7 @@ static inline long long arch_atomic64_read(const atomic64_t
*v)
long long r;
alternative_atomic64(read, "=&A" (r), "c" (v) : "memory");
return r;
- }
+}
/**
* arch_atomic64_add_return - add and return
diff --git a/drivers/acpi/custom_method.c b/drivers/acpi/custom_method.c
index b33fba70ec51..a07fbe999eb6 100644
--- a/drivers/acpi/custom_method.c
+++ b/drivers/acpi/custom_method.c
@@ -97,7 +97,7 @@ static void __exit acpi_custom_method_exit(void)
{
if (cm_dentry)
debugfs_remove(cm_dentry);
- }
+}
module_init(acpi_custom_method_init);
module_exit(acpi_custom_method_exit);
diff --git a/drivers/acpi/fan.c b/drivers/acpi/fan.c
index 6cf4988206f2..3563103590c6 100644
--- a/drivers/acpi/fan.c
+++ b/drivers/acpi/fan.c
@@ -219,7 +219,7 @@ fan_set_cur_state(struct thermal_cooling_device *cdev,
unsigned long state)
return fan_set_state_acpi4(device, state);
else
return fan_set_state(device, state);
- }
+}
static const struct thermal_cooling_device_ops fan_cooling_ops = {
.get_max_state = fan_get_max_state,
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc.c
b/drivers/gpu/drm/amd/display/dc/core/dc.c
index 8394d69b963f..e934326a95d3 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc.c
@@ -588,7 +588,7 @@ static void disable_dangling_plane(struct dc *dc, struct
dc_state *context)
**/
struct dc *dc_create(const struct dc_init_data *init_params)
- {
+{
struct dc *dc = kzalloc(sizeof(*dc), GFP_KERNEL);
unsigned int full_pipe_count;
diff --git a/drivers/media/i2c/msp3400-kthreads.c
b/drivers/media/i2c/msp3400-kthreads.c
index 4dd01e9f553b..dc6cb8d475b3 100644
--- a/drivers/media/i2c/msp3400-kthreads.c
+++ b/drivers/media/i2c/msp3400-kthreads.c
@@ -885,7 +885,7 @@ static int msp34xxg_modus(struct i2c_client *client)
}
static void msp34xxg_set_source(struct i2c_client *client, u16 reg, int in)
- {
+{
struct msp_state *state = to_state(i2c_get_clientdata(client));
int source, matrix;
diff --git a/drivers/message/fusion/mptsas.c b/drivers/message/fusion/mptsas.c
index 439ee9c5f535..231f3a1e27bf 100644
--- a/drivers/message/fusion/mptsas.c
+++ b/drivers/message/fusion/mptsas.c
@@ -2967,7 +2967,7 @@ mptsas_exp_repmanufacture_info(MPT_ADAPTER *ioc,
mutex_unlock(&ioc->sas_mgmt.mutex);
out:
return ret;
- }
+}
static void
mptsas_parse_device_info(struct sas_identify *identify,
diff --git a/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
b/drivers/net/ethernet/qlogic/netxen/netxen_nic_init.c
index 3dd973475125..
[Bug 104064] (DC 4.15-rc2) WARNING: CPU: 4 PID: 75 at drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm.c:601 dm_suspend+0x4e/0x60 [amdgpu]
https://bugs.freedesktop.org/show_bug.cgi?id=104064 --- Comment #41 from Alex Deucher --- (In reply to taijian from comment #40) > OK, I hate to be necrobumping this, but I've continued to follow and test > drm-next-4.17-wip and it seems that not only has the backlight patch from > #34 not made it in yet, but also that the forced atpx option from #14 has > also disappeared after all of the vega12 additions. S, are these things > going to come back? Sorry, my impression from comment 29 was that messing the the OSI string fixed the issue. Is that not the case? Do you still need to force ATPX? If we, we can just add a quirk so the driver does it automatically. -- 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 104880] No sound via DP on R9 Fury (4.16 + drm-next-4.17-wip)
https://bugs.freedesktop.org/show_bug.cgi?id=104880 Konstantin A. Lepikhov changed: What|Removed |Added Summary|No sound via DP on R9 Fury |No sound via DP on R9 Fury |(4.15 + amd-staging-4.15|(4.16 + drm-next-4.17-wip) |patches)| --- Comment #9 from Konstantin A. Lepikhov --- Still no sound with recent v4.16-rc6 + amdgpu-dc/drm-next-4.17-wip up to v4.16-rc1-1338-g46b27ee [lakostis@lks ~]$ cat /proc/asound/HDMI/eld#0.4 monitor_present 0 eld_valid 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
Re: [trivial PATCH V2] treewide: Align function definition open/close braces
On Wed, Mar 21, 2018 at 11:09 PM, Joe Perches wrote: > Some functions definitions have either the initial open brace and/or > the closing brace outside of column 1. > > Move those braces to column 1. > > This allows various function analyzers like gnu complexity to work > properly for these modified functions. > > Signed-off-by: Joe Perches > Acked-by: Andy Shevchenko > Acked-by: Paul Moore > Acked-by: Alex Deucher > Acked-by: Dave Chinner > Reviewed-by: Darrick J. Wong > Acked-by: Alexandre Belloni > Acked-by: Martin K. Petersen > Acked-by: Takashi Iwai > Acked-by: Mauro Carvalho Chehab > --- > > git diff -w still shows no difference. > > This patch was sent but December and not applied. > > As the trivial maintainer seems not active, it'd be nice if > Andrew Morton picks this up. > > V2: Remove fs/xfs/libxfs/xfs_alloc.c as it's updated and remerge the rest > > arch/x86/include/asm/atomic64_32.h | 2 +- > drivers/acpi/custom_method.c | 2 +- > drivers/acpi/fan.c | 2 +- For the ACPI changes: Acked-by: Rafael J. Wysocki ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-fixes-4.16
Hi Dave, A few more fixes for 4.16. Mostly for displays: - A fix for DP handling on radeon - Fix banding on eDP panels - Fix HBR audio - Fix for disabling VGA mode on Raven that leads to a corrupt or blank display on some platforms The following changes since commit 67f1976665900c86989cfe99b884dc51bddfb0e9: Merge tag 'drm-intel-fixes-2018-03-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-03-15 09:26:11 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-fixes-4.16 for you to fetch changes up to 731a373698c9675d5aed8a30d8c9861bea9c41a2: drm/amd/display: Add one to EDID's audio channel count when passing to DC (2018-03-21 00:24:47 -0500) Clark Zheng (1): drm/amd/display: Refine disable VGA Harry Wentland (2): drm/amd/display: We shouldn't set format_default on plane as atomic driver drm/amd/display: Add one to EDID's audio channel count when passing to DC Michel Dänzer (1): drm/radeon: Don't turn off DP sink when disconnected Mikita Lipski (3): drm/amdgpu: Use atomic function to disable crtcs with dc enabled drm/amd/display: Allow truncation to 10 bits drm/amd/display: Fix FMT truncation programming Shirish S (1): drm/amd/display: fix dereferencing possible ERR_PTR() drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 9 --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 5 ++-- .../drm/amd/display/amdgpu_dm/amdgpu_dm_helpers.c | 2 +- drivers/gpu/drm/amd/display/dc/dce/dce_hwseq.h | 8 +- drivers/gpu/drm/amd/display/dc/dce/dce_opp.c | 9 +++ .../drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 20 ++ drivers/gpu/drm/radeon/radeon_connectors.c | 31 +- 7 files changed, 48 insertions(+), 36 deletions(-) ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4.5 0/8] cgroup private data and DRM/i915 integration
This version of the patch series just contains some minor updates to address checkpatch and sparse warnings. There are no serious design or implementation changes since v4. You can find the previous versions of this series (and more detailed cover letters) here: (v1) https://lists.freedesktop.org/archives/intel-gfx/2018-January/153156.html (v2) https://www.mail-archive.com/dri-devel@lists.freedesktop.org/msg208170.html (v3) https://lists.freedesktop.org/archives/intel-gfx/2018-March/157928.html (v4) https://lists.freedesktop.org/archives/intel-gfx/2018-March/159222.html Matt Roper (8): cgroup: Allow registration and lookup of cgroup private data (v3) cgroup: Introduce task_get_dfl_cgroup() (v2) cgroup: Introduce cgroup_priv_get_current drm/i915: Adjust internal priority definitions (v2) drm/i915: cgroup integration (v4) drm/i915: Introduce 'priority offset' for GPU contexts (v4) drm/i915: Introduce per-cgroup display boost setting drm/i915: Add context priority & priority offset to debugfs (v2) drivers/gpu/drm/i915/Makefile | 1 + drivers/gpu/drm/i915/i915_cgroup.c | 207 drivers/gpu/drm/i915/i915_debugfs.c | 3 + drivers/gpu/drm/i915/i915_drv.c | 8 ++ drivers/gpu/drm/i915/i915_drv.h | 46 ++- drivers/gpu/drm/i915/i915_gem_context.c | 12 +- drivers/gpu/drm/i915/i915_gem_context.h | 9 ++ drivers/gpu/drm/i915/i915_request.h | 18 ++- drivers/gpu/drm/i915/intel_display.c| 5 +- include/linux/cgroup-defs.h | 8 ++ include/linux/cgroup.h | 37 ++ include/uapi/drm/i915_drm.h | 14 +++ kernel/cgroup/cgroup.c | 206 ++- 13 files changed, 561 insertions(+), 13 deletions(-) create mode 100644 drivers/gpu/drm/i915/i915_cgroup.c -- 2.14.3 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
