[PATCH v2] drm/rockchip: Set line flag config register in vop_crtc_enable
We need to set vop config done after update line flag config, it's a
new requirement for chips newer than rk3368.
Since we would only use line flag irq for vact_end, let's move it to
vop_crtc_enable.
v2: Remove unused check and variables.
Signed-off-by: Jeffy Chen
---
Changes in v2:
Remove unused check and variables.
drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++---
drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +--
drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +---
3 files changed, 13 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
index d8fa7a9..1bccd82 100644
--- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
+++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
@@ -104,26 +104,18 @@ static void analogix_dp_psr_work(struct work_struct *work)
{
struct rockchip_dp_device *dp =
container_of(work, typeof(*dp), psr_work);
- struct drm_crtc *crtc = dp->encoder.crtc;
- int psr_state = dp->psr_state;
- int vact_end;
int ret;
unsigned long flags;
- if (!crtc)
- return;
-
- vact_end = crtc->mode.vtotal - crtc->mode.vsync_start +
crtc->mode.vdisplay;
-
- ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
- PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
+ ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
+PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
if (ret) {
dev_err(dp->dev, "line flag interrupt did not arrive\n");
return;
}
spin_lock_irqsave(&dp->psr_lock, flags);
- if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
+ if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
analogix_dp_enable_psr(dp->dev);
else
analogix_dp_disable_psr(dp->dev);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index a48fcce..47905fa 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -62,8 +62,7 @@ int rockchip_drm_dma_attach_device(struct drm_device *drm_dev,
struct device *dev);
void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
struct device *dev);
-int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
- unsigned int mstimeout);
+int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout);
extern struct platform_driver cdn_dp_driver;
extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 3f7a82d..40a5e6e 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -468,7 +468,7 @@ static bool vop_line_flag_irq_is_enabled(struct vop *vop)
return !!line_flag_irq;
}
-static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
+static void vop_line_flag_irq_enable(struct vop *vop)
{
unsigned long flags;
@@ -477,7 +477,6 @@ static void vop_line_flag_irq_enable(struct vop *vop, int
line_num)
spin_lock_irqsave(&vop->irq_lock, flags);
- VOP_CTRL_SET(vop, line_flag_num[0], line_num);
VOP_INTR_SET_TYPE(vop, clear, LINE_FLAG_INTR, 1);
VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
@@ -981,6 +980,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
VOP_CTRL_SET(vop, vact_st_end, val);
VOP_CTRL_SET(vop, vpost_st_end, val);
+ VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
+
clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
VOP_CTRL_SET(vop, standby, 0);
@@ -1507,19 +1508,16 @@ static void vop_win_init(struct vop *vop)
}
/**
- * rockchip_drm_wait_line_flag - acqiure the give line flag event
+ * rockchip_drm_wait_vact_end
* @crtc: CRTC to enable line flag
- * @line_num: interested line number
* @mstimeout: millisecond for timeout
*
- * Driver would hold here until the interested line flag interrupt have
- * happened or timeout to wait.
+ * Wait for vact_end line flag irq or timeout.
*
* Returns:
* Zero on success, negative errno on failure.
*/
-int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
- unsigned int mstimeout)
+int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int mstimeout)
{
struct vop *vop = to_vop(crtc);
unsigned long jiffies_left;
@@ -1527,14 +1525,14 @@ int rockchip_drm_wait_line_flag(struct drm_crtc *crtc,
unsigned int line_num,
if (!crtc || !vop->is_enabled)
return -ENODEV;
- if (line_num > crtc->mode.vtotal || mstimeout
[Bug 96271] TF2: GPU lockup on HD 7950
https://bugs.freedesktop.org/show_bug.cgi?id=96271 --- Comment #9 from Julien Isorce --- Hi Stephen, if you still have the same machine/setup maybe worth to try the apitrace 1) that I mentioned here https://bugs.freedesktop.org/show_bug.cgi?id=100712#c7 . I wonder if it is the same issue. About "dmesg_after_hard_hang.txt" / "kernel_log_during_gdm_restart.txt" all these exact same backtraces are happening because the ring 0(GFX) is still stuck after gpu reset. So acceleration is marked as disabled. But then mesa clear some buffers being cached before reset and it hits WARN_ON in radeon_ttm_bo_destroy, see https://cgit.freedesktop.org/~agd5f/linux/tree/drivers/gpu/drm/radeon/radeon_object.c?h=amd-staging-4.9#n72. I recently submitted a patch to change it to a WARN_ON_ONCE. But the real problem is the ring 0 stalled in the first place. For me I found that setting R600_DEBUG=nowc workarounds the problem. Also I have not found any full dmesg log in the attachments, especially infos generated at startup. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] drm/amd/amdgpu: get rid of else branch
Am 27.04.2017 um 18:17 schrieb Nikola Pajkovsky:
This is super simple elimination of else branch and I should
probably even use unlikely in
if (ring->count_dw < count_dw) {
However, amdgpu_ring_write() has similar if condition, but does not
return after DRM_ERROR and it looks suspicious. On error, we still
adding v to ring and keeping count_dw-- below zero.
if (ring->count_dw <= 0)
DRM_ERROR("amdgpu: writing more dwords to the ring than
expected!\n");
ring->ring[ring->wptr++] = v;
ring->wptr &= ring->ptr_mask;
ring->count_dw--;
I can obviously be totaly wrong. Hmm?
That's just choosing the lesser evil.
When we write more DW to the ring than expected it is possible (but not
likely) that we override stuff on the ring buffer which is still
executed by the command processor leading to a possible CP crash.
But when we completely drop the write the commands in the ring buffer
will certainly be invalid and so the CP will certainly crash sooner or
later.
Please add the unlikely() as well and then send out the patch with a
signed-of-by line and I will be happy to push it into our upstream branch.
Regards,
Christian.
8<8<8<8<8<8<8<8<8<
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index c1b913541739..c6f4f874ea68 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1596,28 +1596,29 @@ static inline void amdgpu_ring_write_multiple(struct
amdgpu_ring *ring, void *sr
if (ring->count_dw < count_dw) {
DRM_ERROR("amdgpu: writing more dwords to the ring than
expected!\n");
- } else {
- occupied = ring->wptr & ring->ptr_mask;
- dst = (void *)&ring->ring[occupied];
- chunk1 = ring->ptr_mask + 1 - occupied;
- chunk1 = (chunk1 >= count_dw) ? count_dw: chunk1;
- chunk2 = count_dw - chunk1;
- chunk1 <<= 2;
- chunk2 <<= 2;
-
- if (chunk1)
- memcpy(dst, src, chunk1);
-
- if (chunk2) {
- src += chunk1;
- dst = (void *)ring->ring;
- memcpy(dst, src, chunk2);
- }
-
- ring->wptr += count_dw;
- ring->wptr &= ring->ptr_mask;
- ring->count_dw -= count_dw;
+ return;
}
+
+ occupied = ring->wptr & ring->ptr_mask;
+ dst = (void *)&ring->ring[occupied];
+ chunk1 = ring->ptr_mask + 1 - occupied;
+ chunk1 = (chunk1 >= count_dw) ? count_dw: chunk1;
+ chunk2 = count_dw - chunk1;
+ chunk1 <<= 2;
+ chunk2 <<= 2;
+
+ if (chunk1)
+ memcpy(dst, src, chunk1);
+
+ if (chunk2) {
+ src += chunk1;
+ dst = (void *)ring->ring;
+ memcpy(dst, src, chunk2);
+ }
+
+ ring->wptr += count_dw;
+ ring->wptr &= ring->ptr_mask;
+ ring->count_dw -= count_dw;
}
static inline struct amdgpu_sdma_instance *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 0/7] drm: asynchronous atomic plane update
On Thu, Apr 27, 2017 at 03:36:50PM -0300, Gustavo Padovan wrote: > 2017-04-27 Ville Syrjälä : > > > On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote: > > > From: Gustavo Padovan > > > > > > Hi, > > > > > > Second take of Asynchronous Plane Updates over Atomic. Here I looked > > > to msm, vc4 and i915 to identify a common pattern to create atomic helpers > > > for async updates. So in patch 1 drm_atomic_async_check() and > > > drm_atomic_helper_async_commit() are introduced along with driver's plane > > > hooks: > > > ->atomic_async_check() and ->atomic_async_commit(). > > > > > > For now we only support async update for one plane at a time. Also the > > > async > > > update can't modify the CRTC so no modesets are allowed. > > > > > > Then the other patches add support for it in the drivers. I did virtio > > > mostly > > > for testing. i915 have been converted and I've been using it without any > > > problem. IGT tests seems to be fine, but there are somewhat random > > > failures > > > with or without the async update changes. msm and vc4 are only > > > compile-tested. > > > So I think this needs more testing > > > > > > I started IGT changes to test the Atomic IOCTL with the new flag: > > > > > > https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/ > > > > > > v2: > > > > > > Apart from all comments on v1 one extra change I made was to remove the > > > constraint of only updating the plane if the queued state didn't touch > > > that plane. I believe it was a too cautious of a change, furthermore this > > > constraint was affecting throughput negatively on i915. > > > > So you're now allowing reordering the updates? As in update A is > > scheduled before update B, but update B happens before update A. > > That is not a good idea. > > That is what already happens with legacy cursor updates. They jump ahead > the scheduled update and apply the cursor update. Well, that's clearly a bug then. They are supposed to be able to jump ahead of other planes, but not themselves. I think the real problem is having just one timeline for the entire crtc. The proper solution would be to have a timeline for each plane. > What we propose here > is to do this over atomic when DRM_MODE_ATOMIC_ASYNC_UPDATE flag is set. The cursor thing is a hack. Using it as a guideline for something else is not a good idea IMO. Reordering, apart from being totally unexpected would also cause all sorts of problems because the hardware state at the time of the programming the hardware won't match what you checked against in your async check function. > Async PageFlips should use the same infrastructure in the future. I don't quite see why you have to build a parallel infrastructure for this stuff. If the driver would do things properly then it could just as well do this stuff from the normal path as well. So I figured the point of all this was just to unify the hacks to one place pretty much. Expanding the hacks to some kind of big infrastrucure is not something I'd do. -- Ville Syrjälä Intel OTC ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/7] drm/atomic: initial support for asynchronous plane update
On Thu, Apr 27, 2017 at 04:35:37PM -0300, Gustavo Padovan wrote:
> Hi Ville,
>
> 2017-04-27 Ville Syrjälä :
>
> > On Thu, Apr 27, 2017 at 12:15:13PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > In some cases, like cursor updates, it is interesting to update the
> > > plane in an asynchronous fashion to avoid big delays. The current queued
> > > update could be still waiting for a fence to signal and thus block any
> > > subsequent update until its scan out. In cases like this if we update the
> > > cursor synchronously through the atomic API it will cause significant
> > > delays that would even be noticed by the final user.
> > >
> > > This patch creates a fast path to jump ahead the current queued state and
> > > do single planes updates without going through all atomic step in
> > > drm_atomic_helper_commit().
> > >
> > > We take this path for legacy cursor updates. Users can also set the
> > > DRM_MODE_ATOMIC_ASYNC_UPDATE flag on atomic updates.
> > >
> > > For now only single plane updates are supported, but we plan to support
> > > multiple planes updates and async PageFlips through this interface as well
> > > in the near future.
> > >
> > > v2:
> > > - allow updates even if there is a queued update for the same
> > > plane.
> > > - fixes on the documentation (Emil Velikov)
> > > - unconditionally call ->atomic_async_update (Emil Velikov)
> > > - check for ->atomic_async_update earlier (Daniel Vetter)
> > > - make ->atomic_async_check() the last step (Daniel Vetter)
> > > - add ASYNC_UPDATE flag (Eric Anholt)
> > > - update state in core after ->atomic_async_update (Eric Anholt)
> > > - update docs (Eric Anholt)
> > >
> > > Cc: Daniel Vetter
> > > Cc: Rob Clark
> > > Cc: Eric Anholt
> > > Signed-off-by: Gustavo Padovan
> > > ---
> > > drivers/gpu/drm/drm_atomic.c | 50
> > >
> > > drivers/gpu/drm/drm_atomic_helper.c | 48
> > > ++
> > > include/drm/drm_atomic.h | 2 ++
> > > include/drm/drm_atomic_helper.h | 2 ++
> > > include/drm/drm_modeset_helper_vtables.h | 45
> > >
> > > include/uapi/drm/drm_mode.h | 4 ++-
> > > 6 files changed, 150 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > index 30229ab..7b60cf8 100644
> > > --- a/drivers/gpu/drm/drm_atomic.c
> > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > @@ -77,6 +77,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
> > > drm_atomic_state *state)
> > >* setting this appropriately?
> > >*/
> > > state->allow_modeset = true;
> > > + state->async_update = true;
> > >
> > > state->crtcs = kcalloc(dev->mode_config.num_crtc,
> > > sizeof(*state->crtcs), GFP_KERNEL);
> > > @@ -631,6 +632,51 @@ static int drm_atomic_crtc_check(struct drm_crtc
> > > *crtc,
> > > return 0;
> > > }
> > >
> > > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > > +{
> > > + struct drm_crtc *crtc;
> > > + struct drm_crtc_state *crtc_state;
> > > + struct drm_plane *__plane, *plane = NULL;
> > > + struct drm_plane_state *__plane_state, *plane_state = NULL;
> > > + const struct drm_plane_helper_funcs *funcs;
> > > + int i, n_planes = 0;
> > > +
> > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > > + if (drm_atomic_crtc_needs_modeset(crtc_state))
> > > + return false;
> > > + }
> > > +
> > > + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > > + n_planes++;
> > > + plane = __plane;
> > > + plane_state = __plane_state;
> > > + }
> > > +
> > > + /* FIXME: we support single plane updates for now */
> > > + if (!plane || n_planes != 1)
> > > + return false;
> > > +
> > > + funcs = plane->helper_private;
> > > + if (!funcs->atomic_async_update)
> > > + return false;
> > > +
> > > + if (plane_state->fence)
> > > + return false;
> > > +
> > > + if (!plane->state->crtc || (plane->state->crtc != plane_state->crtc))
> > > + return false;
> > > +
> > > + /* No configuring new scaling in the async path. */
> >
> > Those checks aren't really about scaling. Well, they are also about
> > scaling, but they're mainly about changing size.
>
> I just copied the comment from the previous code in the drivers...
> I can fix it.
>
> >
> > What I don't really understand is why we're enforcing these restrictions
> > in the core but leaving other restrictions up to the driver. I don't see
> > size changes as anything really special compared to many of the other
> > restrictions that would now be up to each driver.
>
> Because I extracted what was common between msm, vc4 and i915 on their
> legacy cursor update calls. I didn't want to enforce anything else in
> core for now.
>
> >
> > If you're really af
Re: [RFC v2 3/7] drm/i915: update cursors asynchronously through atomic
On Thu, Apr 27, 2017 at 04:39:47PM -0300, Gustavo Padovan wrote:
> Hi Ville,
>
> 2017-04-27 Ville Syrjälä :
>
> > On Thu, Apr 27, 2017 at 12:15:15PM -0300, Gustavo Padovan wrote:
> > > From: Gustavo Padovan
> > >
> > > Add support to async updates of cursors by using the new atomic
> > > interface for that. Basically what this commit does is do what
> > > intel_legacy_cursor_update() did but through atomic.
> > >
> > > v2: move fb setting to core and use new state (Eric Anholt)
> > >
> > > Cc: Daniel Vetter
> > > Signed-off-by: Gustavo Padovan
> > > ---
> > > drivers/gpu/drm/i915/intel_atomic_plane.c | 52 +++
> > > drivers/gpu/drm/i915/intel_display.c | 147
> > > +-
> > > 2 files changed, 73 insertions(+), 126 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > index cfb4729..c5d0596 100644
> > > --- a/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > +++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
> > > @@ -246,11 +246,63 @@ static void intel_plane_atomic_update(struct
> > > drm_plane *plane,
> > > }
> > > }
> > >
> > > +static int intel_plane_atomic_async_check(struct drm_plane *plane,
> > > + struct drm_plane_state *state)
> > > +{
> > > + struct drm_crtc *crtc = plane->state->crtc;
> > > + struct drm_crtc_state *crtc_state = crtc->state;
> > > +
> > > + if (plane->type != DRM_PLANE_TYPE_CURSOR)
> > > + return -EINVAL;
> > > +
> > > + /*
> > > + * When crtc is inactive or there is a modeset pending,
> > > + * wait for it to complete in the slowpath
> > > + */
> > > + if (!crtc_state->active || to_intel_crtc_state(crtc_state)->update_pipe)
> > > + return -EINVAL;
> > > +
> > > + /* Only changing fb should be in the fastpath. */
> >
> > No, we want cursor movement there as well. It's somewhat impossible
> > to see from this code now that the core has the size checks. But even
> > so the comment should not lie.
>
> Sure, I'll fix the comment.
>
> >
> > > + if (!plane->state->fb != !state->fb)
> > > + return -EINVAL;
> > > +
> > > + return 0;
> > > +}
> > > +
> > > +static void intel_plane_atomic_async_update(struct drm_plane *plane,
> > > + struct drm_plane_state *new_state)
> > > +{
> > > + struct intel_plane *intel_plane = to_intel_plane(plane);
> > > + struct drm_crtc *crtc = plane->state->crtc;
> > > +
> > > + i915_gem_track_fb(intel_fb_obj(plane->state->fb),
> > > + intel_fb_obj(new_state->fb),
> > > + intel_plane->frontbuffer_bit);
> > > +
> > > + *to_intel_plane_state(plane->state) = *to_intel_plane_state(new_state);
> > > + to_intel_plane_state(new_state)->vma =
> > > + to_intel_plane_state(plane->state)->vma;
> > > +
> > > + plane->state->visible = new_state->visible;
> > > +
> > > + if (plane->state->visible) {
> > > + trace_intel_update_plane(plane, to_intel_crtc(crtc));
> > > + intel_plane->update_plane(plane,
> > > + to_intel_crtc_state(crtc->state),
> > > + to_intel_plane_state(new_state));
> > > + } else {
> > > + trace_intel_disable_plane(plane, to_intel_crtc(crtc));
> > > + intel_plane->disable_plane(plane, crtc);
> > > + }
> > > +}
> > > +
> > > const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
> > > .prepare_fb = intel_prepare_plane_fb,
> > > .cleanup_fb = intel_cleanup_plane_fb,
> > > .atomic_check = intel_plane_atomic_check,
> > > .atomic_update = intel_plane_atomic_update,
> > > + .atomic_async_check = intel_plane_atomic_async_check,
> > > + .atomic_async_update = intel_plane_atomic_async_update,
> >
> > NAK. We don't want these "async" updates for anything but cursors.
>
> Yes, we do. Async PageFlips will go through here as well. That seems a
> VR requirement as well.
i915 can't handle this currently. So no, we don't want this.
--
Ville Syrjälä
Intel OTC
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 72680] flightgear crashes on r600 (rs880) with llvm backend
https://bugs.freedesktop.org/show_bug.cgi?id=72680 Marc Dietrich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from Marc Dietrich --- R600_LLVM is gone, so this does not longer apply. -- 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 26887] fence errors with rs785 and kernel 2.6.33
https://bugs.freedesktop.org/show_bug.cgi?id=26887 Marc Dietrich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98307] "st/glsl_to_tgsi: explicitly track all input and output declaration" broke flightgear colors on rs780
https://bugs.freedesktop.org/show_bug.cgi?id=98307 Marc Dietrich changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 25079] poison overwritten in radeon drm
https://bugs.freedesktop.org/show_bug.cgi?id=25079 Marc Dietrich changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |WONTFIX --- Comment #2 from Marc Dietrich --- can't reproduce it anymore. -- 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 3/6] drm: fourcc byteorder: add bigendian support to drm_mode_legacy_fb_format
Hi,
> > So just not using the swapping indeed looks like the only sensible
> > option. Which in turn implies there is no BGRA support for dumb
> > bos. Hmm, I can see the problem. Userspace expectation appears to be
> > that ADDFB configures a native endian framebuffer, which the driver
> > simply can't do on bigendian.
>
> ... with pre-R600 GPUs.
Sure.
> > So, what can/should the driver do here? Throw errors for ADDFB and
> > force userspace to use ADDFB2? From a design point of view the best
> > option, but in the other hand I suspect that could break the xorg radeon
> > driver ...
>
> Yes, it would.
> One thing we could do is provide a way for userspace to query the
> effective format(s) as seen by the GPU and/or CPU.
We already have almost no testing on bigendian. I doubt adding generic
interfaces specifically to handle this case is going to work because
most userspace will simply not implement that correctly (or at all).
Having support for this in the radeon ioctls might work, because only
radeon kernel + xorg driver have to get things right then. But I
suspect we already have that. You've mentioned elsewhere in the thread
that the xorg driver doesn't turn on byteswapping, so the ability to
configure that seems to be somewhere in the API ...
> It might also make sense for the radeon driver to set the
> RADEON_TILING_SWAP_{16,32}BIT flags for dumb BOs.
That could work. But I guess someone with test hardware needs to try,
to make sure we don't miss corner cases here.
cheers,
Gerd
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The CEC pin was always pulled up, making it impossible to use it.
>
> Change to PIN_INPUT so it can be used by the new CEC support.
>
> Signed-off-by: Hans Verkuil
> ---
> arch/arm/boot/dts/omap4-panda-a4.dts | 2 +-
> arch/arm/boot/dts/omap4-panda-es.dts | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/arm/boot/dts/omap4-panda-a4.dts
> b/arch/arm/boot/dts/omap4-panda-a4.dts
> index 78d363177762..f1a6476af371 100644
> --- a/arch/arm/boot/dts/omap4-panda-a4.dts
> +++ b/arch/arm/boot/dts/omap4-panda-a4.dts
> @@ -13,7 +13,7 @@
> /* Pandaboard Rev A4+ have external pullups on SCL & SDA */
> &dss_hdmi_pins {
> pinctrl-single,pins = <
> - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/*
> hdmi_cec.hdmi_cec */
> + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /*
> hdmi_cec.hdmi_cec */
> OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /*
> hdmi_scl.hdmi_scl */
> OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /*
> hdmi_sda.hdmi_sda */
> >;
> diff --git a/arch/arm/boot/dts/omap4-panda-es.dts
> b/arch/arm/boot/dts/omap4-panda-es.dts
> index 119f8e657edc..940fe4f7c5f6 100644
> --- a/arch/arm/boot/dts/omap4-panda-es.dts
> +++ b/arch/arm/boot/dts/omap4-panda-es.dts
> @@ -34,7 +34,7 @@
> /* PandaboardES has external pullups on SCL & SDA */
> &dss_hdmi_pins {
> pinctrl-single,pins = <
> - OMAP4_IOPAD(0x09a, PIN_INPUT_PULLUP | MUX_MODE0)/*
> hdmi_cec.hdmi_cec */
> + OMAP4_IOPAD(0x09a, PIN_INPUT | MUX_MODE0) /*
> hdmi_cec.hdmi_cec */
> OMAP4_IOPAD(0x09c, PIN_INPUT | MUX_MODE0) /*
> hdmi_scl.hdmi_scl */
> OMAP4_IOPAD(0x09e, PIN_INPUT | MUX_MODE0) /*
> hdmi_sda.hdmi_sda */
> >;
>
Reviewed-by: Tomi Valkeinen
Tony, can you queue this? It's safe to apply separately from the rest of
the HDMI CEC work.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 6/8] omapdrm: hdmi4: refcount hdmi_power_on/off_core
On 14/04/17 13:25, Hans Verkuil wrote:
> From: Hans Verkuil
>
> The hdmi_power_on/off_core functions can be called multiple times:
> when the HPD changes and when the HDMI CEC support needs to power
> the HDMI core.
>
> So use a counter to know when to really power on or off the HDMI core.
>
> Also call hdmi4_core_powerdown_disable() in hdmi_power_on_core() to
> power up the HDMI core (needed for CEC).
>
> Signed-off-by: Hans Verkuil
> ---
> drivers/gpu/drm/omapdrm/dss/hdmi4.c | 12 +++-
> 1 file changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> index 4a164dc01f15..e371b47ff6ff 100644
> --- a/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> +++ b/drivers/gpu/drm/omapdrm/dss/hdmi4.c
> @@ -124,14 +124,19 @@ static int hdmi_power_on_core(struct omap_dss_device
> *dssdev)
> {
> int r;
>
> + if (hdmi.core.core_pwr_cnt++)
> + return 0;
> +
How's the locking between the CEC side and the DRM side? Normally these
functions are protected with the DRM modesetting locks, but CEC doesn't
come from there. We have the hdmi.lock, did you check that it's held
when CEC side calls shared functions?
> r = regulator_enable(hdmi.vdda_reg);
> if (r)
> - return r;
> + goto err_reg_enable;
>
> r = hdmi_runtime_get();
> if (r)
> goto err_runtime_get;
>
> + hdmi4_core_powerdown_disable(&hdmi.core);
I'd like to have the powerdown_disable as a separate patch. Also, now
that you call it here, I believe it can be dropped from hdmi4_configure().
Hmm, but in hdmi4_configure we call hdmi_core_swreset_assert() before
hdmi4_core_powerdown_disable(). I wonder what exactly that does, and
whether we end up resetting also the CEC parts when we change the videomode.
Tomi
signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 2/8] omapdrm: encoder-tpd12s015: keep ls_oe_gpio high if CEC is enabled
On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > When the OMAP4 CEC support is enabled the CEC pin should always > be on. So keep ls_oe_gpio high when CONFIG_OMAP4_DSS_HDMI_CEC > is set. > > Background: even if the HPD is low it should still be possible > to use CEC. Some displays will set the HPD low when they go into standby or > when they switch to another input, but CEC is still available and able > to wake up/change input for such a display. > > This is explicitly allowed by the CEC standard. > > Signed-off-by: Hans Verkuil > --- > drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c | 8 > 1 file changed, 8 insertions(+) > > diff --git a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c > b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c > index 58276a48112e..757554e6d62f 100644 > --- a/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c > +++ b/drivers/gpu/drm/omapdrm/displays/encoder-tpd12s015.c > @@ -46,6 +46,9 @@ static int tpd_connect(struct omap_dss_device *dssdev, > dssdev->dst = dst; > > gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 1); > +#ifdef CONFIG_OMAP4_DSS_HDMI_CEC > + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1); > +#endif > /* DC-DC converter needs at max 300us to get to 90% of 5V */ > udelay(300); > > @@ -64,6 +67,7 @@ static void tpd_disconnect(struct omap_dss_device *dssdev, > return; > > gpiod_set_value_cansleep(ddata->ct_cp_hpd_gpio, 0); > + gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); > > dst->src = NULL; > dssdev->dst = NULL; > @@ -146,11 +150,15 @@ static int tpd_read_edid(struct omap_dss_device *dssdev, > if (!gpiod_get_value_cansleep(ddata->hpd_gpio)) > return -ENODEV; > > +#ifndef CONFIG_OMAP4_DSS_HDMI_CEC > gpiod_set_value_cansleep(ddata->ls_oe_gpio, 1); > +#endif > > r = in->ops.hdmi->read_edid(in, edid, len); > > +#ifndef CONFIG_OMAP4_DSS_HDMI_CEC > gpiod_set_value_cansleep(ddata->ls_oe_gpio, 0); > +#endif > > return r; > } > Optimally, we want to enable LS_OE only when needed, which would be when reading EDID, using HDCP, or using CEC. But we don't have good means to convey that information at the moment, and I'd rather leave it for later when we have done the bigger restructuring of omapdrm. For now, instead of the ifdef-confusion, I think we should just enable the LS_OE in tpd_connect and be done with it. Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
> Some crtc's may have restrictions in the mode they can display. In
> this patch a new callback (crtc->mode_valid()) is introduced that
> is called at the same stage of connector->mode_valid() callback.
>
> This shall be implemented if the crtc has some sort of restriction
> so that we don't probe modes that will fail in the commit() stage.
> For example: A given crtc may be responsible to set a clock value.
> If the clock can not produce all the values for the available
> modes then this callback can be used to restrict the number of
> probbed modes to only the ones that can be displayed.
>
> If the crtc does not implement the callback then the behaviour will
> remain the same. Also, for a given set of crtcs that can be bound to
> the connector, if at least one can display the mode then the mode
> will be probbed.
>
> Signed-off-by: Jose Abreu
> Cc: Carlos Palminha
> Cc: Alexey Brodkin
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Dave Airlie
> ---
> drivers/gpu/drm/drm_probe_helper.c | 44
>
> include/drm/drm_modeset_helper_vtables.h | 26 +++
> 2 files changed, 70 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> b/drivers/gpu/drm/drm_probe_helper.c
> index 1b0c14a..61eac30 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -80,6 +80,46 @@
> return MODE_OK;
> }
>
> +static enum drm_mode_status drm_mode_validate_connector_crtc(
> + struct drm_connector *connector,
> + struct drm_display_mode *mode)
Probably more typical way to split the lines would be:
static enum drm_mode_status
drm_mode_validate_connector_crtc(struct drm_connector *connector,
struct drm_display_mode *mode)
Also 'mode' should be const. Looks like the connector->mode_valid()
hook is missing the const as well, so that too should be fixed.
Not sure about the name of the function. It doesn't really reflect what
it does in the best way possible. drm_mode_validate_connector_possible_crtcs()
perhaps? But that is getting quite long so not sure if it' a good idea
either. I guess simply making the name refer to plural crtcs might be
a reasonable compromise, ie. drm_mode_validate_connector_crtcs()?
> +{
> + const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
> + enum drm_mode_status mode_status = MODE_ERROR;
> + struct drm_device *dev = connector->dev;
> + struct drm_encoder *encoder;
> + struct drm_crtc *crtc;
A lot of these can be moved into tighter scope.
> + bool callback_found = false;
I don't think you need this variable at all. See below.
> + int i;
> +
> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> + encoder = drm_encoder_find(dev, connector->encoder_ids[i]);
> +
> + if (!encoder)
> + continue;
> +
> + drm_for_each_crtc(crtc, dev) {
> + crtc_funcs = crtc->helper_private;
> +
> + if (!drm_encoder_crtc_ok(encoder, crtc))
> + continue;
> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> + continue;
> +
> + /* MODE_OK=0 and default mode_status=MODE_ERROR=-1
> + * so if at least one crtc accepts the mode we get
> + * MODE_OK */
> + mode_status &= crtc_funcs->mode_valid(crtc, mode);
> + callback_found |= true;
The need for a comment here tells me that it's probably better
to got for a more straightforward code. Something like:
mode_status = crtc_funcs->mode_valid(crtc, mode);
if (mode_statys == MODE_OK)
return mode_status;
And at the end of the function just return MODE_ERROR, or
some other error value if we have something suitable. Hmm.
Perhaps we should just return the error from the first or last
crtc? Either should be pretty easy, just "ret = mode_status" within
the loop if it didn't return MODE_OK and then 'return ret' at the
end of the function.
> + }
> + }
> +
> + /* We can reach here without calling mode_valid if there is no
> + * registered crtc with this callback, lets return MODE_OK in this
> + * case */
> + return callback_found ? mode_status : MODE_OK;
> +}
> +
> static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
> {
> struct drm_cmdline_mode *cmdline_mode;
> @@ -431,6 +471,10 @@ int drm_helper_probe_single_connector_modes(struct
> drm_connector *connector,
> if (mode->status == MODE_OK && connector_funcs->mode_valid)
> mode->status = connector_funcs->mode_valid(connector,
> mode);
> +
> + if (mode->status == MODE_OK)
> + mode->status = drm_mode_val
[Bug 100865] Unigine Heaven 4 lockups GPU in wireframe mode
https://bugs.freedesktop.org/show_bug.cgi?id=100865 Bug ID: 100865 Summary: Unigine Heaven 4 lockups GPU in wireframe mode Product: Mesa Version: git Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Drivers/Gallium/r600 Assignee: dri-devel@lists.freedesktop.org Reporter: marvi...@gmx.de QA Contact: dri-devel@lists.freedesktop.org Created attachment 131115 --> https://bugs.freedesktop.org/attachment.cgi?id=131115&action=edit dmesg output launched UH4 on RS880 / Kernel 4.10.10 with mesa git demo runs well until you press "F2" in order to activate wireframe mode, which causes GPU lockups tested mesa: 12, 13, 17, 17.1 and git - all same. -- 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 0/8] omapdrm: add OMAP4 CEC support
On 14/04/17 13:25, Hans Verkuil wrote: > From: Hans Verkuil > > This patch series adds support for the OMAP4 HDMI CEC IP core. What is this series based on? It doesn't apply to drm-next, and: fatal: sha1 information is lacking or useless (drivers/gpu/drm/omapdrm/dss/hdmi4.c). Tomi signature.asc Description: OpenPGP digital signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 0/8] omapdrm: add OMAP4 CEC support
On 28/04/17 13:52, Tomi Valkeinen wrote: > On 14/04/17 13:25, Hans Verkuil wrote: >> From: Hans Verkuil >> >> This patch series adds support for the OMAP4 HDMI CEC IP core. > > What is this series based on? It doesn't apply to drm-next, and: > fatal: sha1 information is lacking or useless > (drivers/gpu/drm/omapdrm/dss/hdmi4.c). That patch series was based on the media_tree master since I needed the latest CEC core code that supports CEC while HPD is down. I have rebased my series to the latest media_tree version. It's available in my panda-cec branch from my repo: git://linuxtv.org/hverkuil/media_tree.git. As mentioned, once 4.12-rc1 has been released I'll rebase and repost. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2
Hi Ben, Am Dienstag, den 04.04.2017, 12:41 -0700 schrieb Ben Widawsky: > On 17-04-04 11:07:26, Daniel Stone wrote: > >Hi, > > > >On 1 April 2017 at 19:47, Rob Clark wrote: > >> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen > >> wrote: > >>> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning > >>> information about the modifiers that will work with each format. > >> > >> So, just to toss out a completely different idea.. > >> > >> What if instead of a new ioctl, we had a read-only blob property > >> (which encoded the info basically the same way, plus the fourcc's)? > >> > >> If we do writeback via some sort of OUT_FB_ID property on plane/crtc, > >> we will need the same sort of format information so userspace knows > >> what output formats (and modifiers) are supported. So re-using the > >> same blob property layout (and userspace parsing) seems useful. > > > >I'd definitely be cool with this. It doesn't make our lives any easier > >or more difficult in terms of parsing, and it also avoids a dep on new > >libdrm API/ABI, which is always nice. If anyone types this up, I'll > >happily port the Weston WIP. > > > >Cheers, > >Daniel > > Okay. Sounds like we have consensus. I'm working on it now. I think like Rob > said on IRC, a good amount of it will be reusable from GET_PLANE2. I'm a bit > new > to the binary blob props, so if anyone has a strong opinion on how it should > look, please speak now. Otherwise, I'll just wire up something. > Can you tell me the status of this? I'm looking at adding tiled scanout to imx-drm and just want to know if it's worth to hold my breath for the reworked patch to arrive. Regards, Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
On Fri, Apr 28, 2017 at 01:30:16PM +0100, Jose Abreu wrote:
> Hi Ville,
>
>
> Thanks for the review! My comments inline.
>
>
> On 28-04-2017 12:41, Ville Syrjälä wrote:
> > On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
> >> Some crtc's may have restrictions in the mode they can display. In
> >> this patch a new callback (crtc->mode_valid()) is introduced that
> >> is called at the same stage of connector->mode_valid() callback.
> >>
> >> This shall be implemented if the crtc has some sort of restriction
> >> so that we don't probe modes that will fail in the commit() stage.
> >> For example: A given crtc may be responsible to set a clock value.
> >> If the clock can not produce all the values for the available
> >> modes then this callback can be used to restrict the number of
> >> probbed modes to only the ones that can be displayed.
> >>
> >> If the crtc does not implement the callback then the behaviour will
> >> remain the same. Also, for a given set of crtcs that can be bound to
> >> the connector, if at least one can display the mode then the mode
> >> will be probbed.
> >>
> >> Signed-off-by: Jose Abreu
> >> Cc: Carlos Palminha
> >> Cc: Alexey Brodkin
> >> Cc: Ville Syrjälä
> >> Cc: Daniel Vetter
> >> Cc: Dave Airlie
> >> ---
> >> drivers/gpu/drm/drm_probe_helper.c | 44
> >>
> >> include/drm/drm_modeset_helper_vtables.h | 26 +++
> >> 2 files changed, 70 insertions(+)
> >>
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 1b0c14a..61eac30 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -80,6 +80,46 @@
> >>return MODE_OK;
> >> }
> >>
> >> +static enum drm_mode_status drm_mode_validate_connector_crtc(
> >> + struct drm_connector *connector,
> >> + struct drm_display_mode *mode)
> > Probably more typical way to split the lines would be:
> > static enum drm_mode_status
> > drm_mode_validate_connector_crtc(struct drm_connector *connector,
> > struct drm_display_mode *mode)
>
> Agree.
>
> >
> > Also 'mode' should be const. Looks like the connector->mode_valid()
> > hook is missing the const as well, so that too should be fixed.
>
> Yeah, thats why I didn't use const here. If I change
> connector->mode_valid() then I will need to change every driver
> who uses it. Please don't get me wrong but I'm not fully
> allocated to patch submission, can we focus on getting this patch
> merged first and then change the connector->mode_valid() to const
> when I have the time?
Should be a good coccinelle exercise ;) But it can certainly be done
later.
>
> >
> > Not sure about the name of the function. It doesn't really reflect what
> > it does in the best way possible.
> > drm_mode_validate_connector_possible_crtcs()
> > perhaps? But that is getting quite long so not sure if it' a good idea
> > either. I guess simply making the name refer to plural crtcs might be
> > a reasonable compromise, ie. drm_mode_validate_connector_crtcs()?
>
> Sounds fine by me :)
>
> >
> >> +{
> >> + const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
> >> + enum drm_mode_status mode_status = MODE_ERROR;
> >> + struct drm_device *dev = connector->dev;
> >> + struct drm_encoder *encoder;
> >> + struct drm_crtc *crtc;
> > A lot of these can be moved into tighter scope.
>
> Agree.
>
> >
> >> + bool callback_found = false;
> > I don't think you need this variable at all. See below.
> >
> >> + int i;
> >> +
> >> + for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
> >> + encoder = drm_encoder_find(dev, connector->encoder_ids[i]);
> >> +
> >> + if (!encoder)
> >> + continue;
> >> +
> >> + drm_for_each_crtc(crtc, dev) {
> >> + crtc_funcs = crtc->helper_private;
> >> +
> >> + if (!drm_encoder_crtc_ok(encoder, crtc))
> >> + continue;
> >> + if (!crtc_funcs || !crtc_funcs->mode_valid)
> >> + continue;
> >> +
> >> + /* MODE_OK=0 and default mode_status=MODE_ERROR=-1
> >> + * so if at least one crtc accepts the mode we get
> >> + * MODE_OK */
> >> + mode_status &= crtc_funcs->mode_valid(crtc, mode);
> >> + callback_found |= true;
> > The need for a comment here tells me that it's probably better
> > to got for a more straightforward code. Something like:
> >
> > mode_status = crtc_funcs->mode_valid(crtc, mode);
> > if (mode_statys == MODE_OK)
> > return mode_status;
>
> Actually I was planning to send a new version with "return" in
> the inner loop to avoid unneeded work as the mode would be
> accepted anyway, so thats more than agreed :)
>
> >
> > And at the end of the function just return MODE_ERROR, or
> > some other error value if we have something
Re: [PATCH v2 1/9] dt-bindings: display: sun4i: Add component endpoint ID numbering scheme
On Fri, Apr 21, 2017 at 04:38:49PM +0800, Chen-Yu Tsai wrote: > The Allwinner display pipeline contains many hardware components, some > of which can consume data from one of multiple upstream components. > The numbering scheme of these components must be encoded into the device > tree so the driver can figure out which component out of two or more of > the same type it is supposed to use or program. > > This patch adds the constraint that local endpoint IDs must be the index > or number of the remote endpoint's hardware block, for all components > in the display pipeline up to the TCONs. > > Signed-off-by: Chen-Yu Tsai > --- > Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > index 57a8d0610062..7acdbf14ae1c 100644 > --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt > @@ -4,6 +4,16 @@ Allwinner A10 Display Pipeline > The Allwinner A10 Display pipeline is composed of several components > that are going to be documented below: > > +For the input port of all components up to the TCON in the display > +pipeline, if there are multiple components, the local endpoint IDs > +must correspond to the index of the upstream block. For example, if > +the remote endpoint is Frontend 1, then the local endpoint ID must > +be 1. > + > +Conversely, for the output ports of the same group, the remote endpoint > +ID must be the index of the local hardware block. If the local backend > +is backend 1, then the remote endpoint ID must be 1. It would be clearer if you just explicitly listed IDs and their connections. From how this is worded, it would not work if you had connections like this: DevA 0 DevA 1 DevB 0 DevB 1 These would need to be endpoints 0-3 in TCON, and that doesn't reflect the remote devices' index. Rob ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/7] drm/atomic: initial support for asynchronous plane update
Hi Ville,
2017-04-28 Ville Syrjälä :
> On Thu, Apr 27, 2017 at 04:35:37PM -0300, Gustavo Padovan wrote:
> > Hi Ville,
> >
> > 2017-04-27 Ville Syrjälä :
> >
> > > On Thu, Apr 27, 2017 at 12:15:13PM -0300, Gustavo Padovan wrote:
> > > > From: Gustavo Padovan
> > > >
> > > > In some cases, like cursor updates, it is interesting to update the
> > > > plane in an asynchronous fashion to avoid big delays. The current queued
> > > > update could be still waiting for a fence to signal and thus block any
> > > > subsequent update until its scan out. In cases like this if we update
> > > > the
> > > > cursor synchronously through the atomic API it will cause significant
> > > > delays that would even be noticed by the final user.
> > > >
> > > > This patch creates a fast path to jump ahead the current queued state
> > > > and
> > > > do single planes updates without going through all atomic step in
> > > > drm_atomic_helper_commit().
> > > >
> > > > We take this path for legacy cursor updates. Users can also set the
> > > > DRM_MODE_ATOMIC_ASYNC_UPDATE flag on atomic updates.
> > > >
> > > > For now only single plane updates are supported, but we plan to support
> > > > multiple planes updates and async PageFlips through this interface as
> > > > well
> > > > in the near future.
> > > >
> > > > v2:
> > > > - allow updates even if there is a queued update for the same
> > > > plane.
> > > > - fixes on the documentation (Emil Velikov)
> > > > - unconditionally call ->atomic_async_update (Emil Velikov)
> > > > - check for ->atomic_async_update earlier (Daniel Vetter)
> > > > - make ->atomic_async_check() the last step (Daniel Vetter)
> > > > - add ASYNC_UPDATE flag (Eric Anholt)
> > > > - update state in core after ->atomic_async_update (Eric Anholt)
> > > > - update docs (Eric Anholt)
> > > >
> > > > Cc: Daniel Vetter
> > > > Cc: Rob Clark
> > > > Cc: Eric Anholt
> > > > Signed-off-by: Gustavo Padovan
> > > > ---
> > > > drivers/gpu/drm/drm_atomic.c | 50
> > > >
> > > > drivers/gpu/drm/drm_atomic_helper.c | 48
> > > > ++
> > > > include/drm/drm_atomic.h | 2 ++
> > > > include/drm/drm_atomic_helper.h | 2 ++
> > > > include/drm/drm_modeset_helper_vtables.h | 45
> > > >
> > > > include/uapi/drm/drm_mode.h | 4 ++-
> > > > 6 files changed, 150 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> > > > index 30229ab..7b60cf8 100644
> > > > --- a/drivers/gpu/drm/drm_atomic.c
> > > > +++ b/drivers/gpu/drm/drm_atomic.c
> > > > @@ -77,6 +77,7 @@ drm_atomic_state_init(struct drm_device *dev, struct
> > > > drm_atomic_state *state)
> > > > * setting this appropriately?
> > > > */
> > > > state->allow_modeset = true;
> > > > + state->async_update = true;
> > > >
> > > > state->crtcs = kcalloc(dev->mode_config.num_crtc,
> > > >sizeof(*state->crtcs), GFP_KERNEL);
> > > > @@ -631,6 +632,51 @@ static int drm_atomic_crtc_check(struct drm_crtc
> > > > *crtc,
> > > > return 0;
> > > > }
> > > >
> > > > +static bool drm_atomic_async_check(struct drm_atomic_state *state)
> > > > +{
> > > > + struct drm_crtc *crtc;
> > > > + struct drm_crtc_state *crtc_state;
> > > > + struct drm_plane *__plane, *plane = NULL;
> > > > + struct drm_plane_state *__plane_state, *plane_state = NULL;
> > > > + const struct drm_plane_helper_funcs *funcs;
> > > > + int i, n_planes = 0;
> > > > +
> > > > + for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
> > > > + if (drm_atomic_crtc_needs_modeset(crtc_state))
> > > > + return false;
> > > > + }
> > > > +
> > > > + for_each_new_plane_in_state(state, __plane, __plane_state, i) {
> > > > + n_planes++;
> > > > + plane = __plane;
> > > > + plane_state = __plane_state;
> > > > + }
> > > > +
> > > > + /* FIXME: we support single plane updates for now */
> > > > + if (!plane || n_planes != 1)
> > > > + return false;
> > > > +
> > > > + funcs = plane->helper_private;
> > > > + if (!funcs->atomic_async_update)
> > > > + return false;
> > > > +
> > > > + if (plane_state->fence)
> > > > + return false;
> > > > +
> > > > + if (!plane->state->crtc || (plane->state->crtc !=
> > > > plane_state->crtc))
> > > > + return false;
> > > > +
> > > > + /* No configuring new scaling in the async path. */
> > >
> > > Those checks aren't really about scaling. Well, they are also about
> > > scaling, but they're mainly about changing size.
> >
> > I just copied the comment from the previous code in the
Re: [RFC v2 0/7] drm: asynchronous atomic plane update
2017-04-28 Ville Syrjälä : > On Thu, Apr 27, 2017 at 03:36:50PM -0300, Gustavo Padovan wrote: > > 2017-04-27 Ville Syrjälä : > > > > > On Thu, Apr 27, 2017 at 12:15:12PM -0300, Gustavo Padovan wrote: > > > > From: Gustavo Padovan > > > > > > > > Hi, > > > > > > > > Second take of Asynchronous Plane Updates over Atomic. Here I looked > > > > to msm, vc4 and i915 to identify a common pattern to create atomic > > > > helpers > > > > for async updates. So in patch 1 drm_atomic_async_check() and > > > > drm_atomic_helper_async_commit() are introduced along with driver's > > > > plane hooks: > > > > ->atomic_async_check() and ->atomic_async_commit(). > > > > > > > > For now we only support async update for one plane at a time. Also the > > > > async > > > > update can't modify the CRTC so no modesets are allowed. > > > > > > > > Then the other patches add support for it in the drivers. I did virtio > > > > mostly > > > > for testing. i915 have been converted and I've been using it without any > > > > problem. IGT tests seems to be fine, but there are somewhat random > > > > failures > > > > with or without the async update changes. msm and vc4 are only > > > > compile-tested. > > > > So I think this needs more testing > > > > > > > > I started IGT changes to test the Atomic IOCTL with the new flag: > > > > > > > > https://git.collabora.com/cgit/user/padovan/intel-gpu-tools.git/ > > > > > > > > v2: > > > > > > > > Apart from all comments on v1 one extra change I made was to remove the > > > > constraint of only updating the plane if the queued state didn't touch > > > > that plane. I believe it was a too cautious of a change, furthermore > > > > this > > > > constraint was affecting throughput negatively on i915. > > > > > > So you're now allowing reordering the updates? As in update A is > > > scheduled before update B, but update B happens before update A. > > > That is not a good idea. > > > > That is what already happens with legacy cursor updates. They jump ahead > > the scheduled update and apply the cursor update. > > Well, that's clearly a bug then. They are supposed to be able to jump > ahead of other planes, but not themselves. Right, maybe I didn't checked this correctly. Removing that was a mistake, I blame my lack of knowledge of such a big subsystem :) I'll bring that code back. > > I think the real problem is having just one timeline for the entire > crtc. The proper solution would be to have a timeline for each plane. > > > What we propose here > > is to do this over atomic when DRM_MODE_ATOMIC_ASYNC_UPDATE flag is set. > > The cursor thing is a hack. Using it as a guideline for something else > is not a good idea IMO. Reordering, apart from being totally unexpected > would also cause all sorts of problems because the hardware state at > the time of the programming the hardware won't match what you checked > against in your async check function. > > > Async PageFlips should use the same infrastructure in the future. > > I don't quite see why you have to build a parallel infrastructure for > this stuff. If the driver would do things properly then it could just > as well do this stuff from the normal path as well. So I figured the > point of all this was just to unify the hacks to one place pretty much. > Expanding the hacks to some kind of big infrastrucure is not something > I'd do. The issue I wanted to solve in the first place was to create a way to update cursors over the atomic ioctl as fast (or relatively fast) as the legacy update. Then discussing this with Daniel Vetter he suggested to solve a bigger problem: add generic async plane update that would benefit cursors, async PageFlips (vc4 already has it) and VR (but I don't really know all the needs for VR). Gustavo ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 100865] Unigine Heaven 4 lockups GPU in wireframe mode
https://bugs.freedesktop.org/show_bug.cgi?id=100865 Dieter Nützel changed: What|Removed |Added CC||b...@basnieuwenhuizen.nl, ||hi-an...@yandex.ru --- Comment #1 from Dieter Nützel --- Hello Marc, can you please verify, that it is a _combination_ of wireframe _and_ tessellation? I've got that for ages with r600g, RV730 (HD 4650, 1GB, AGP) and NI/Turks XT (HD 6670, 2 GB PCIe). As 'Heaven' (UH4) start 'normally' with tessellation enabled and 'you' press 'F2' (enable wireframe) it could result in GPU lockup. So please start 'Heaven', press 'F3' (disable tessellation) and last press 'F2' (enable wireframe). This 'version' works fine for me. It seems to be a combination of both. But my systems mostly recover from the GPU lockup. W'll try to get a new backtrace, soon. Tessellation is so awfully _slow_ (hardware or 'only' software implemantation) that I think we have to look/point, there. Bas (Radv) worked on radeonsi tessellation improvements. See related links: https://www.phoronix.com/scan.php?page=news_item&px=R600g-Tessellation-Lands https://www.phoronix.com/scan.php?page=news_item&px=RadeonSI-Tess-G3D-Benchmarks Second: I ran all the time with MESA_GL_VERSION_OVERRIDE=4.1COMPAT and 'Heaven' show display corruption (missing parts), but wireframe works. If I toggle tessellation (F3) missing parts arise but without tessellation, as expected. So for 'Heaven' I have to disable MESA_GL_VERSION_OVERRIDE and get the above boom (GPU lockup). => tessellation / wireframe correlation 'All' old and Mesa git, Kernel 4.11-rc8 (and former) Greetings, Dieter -- 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] drm/rockchip: Set line flag config register in vop_crtc_enable
On Fri, Apr 28, 2017 at 03:37:47PM +0800, Jeffy Chen wrote:
> We need to set vop config done after update line flag config, it's a
> new requirement for chips newer than rk3368.
>
> Since we would only use line flag irq for vact_end, let's move it to
> vop_crtc_enable.
>
> v2: Remove unused check and variables.
Hi Jeffy,
v1 was already applied. Please send a follow-on patch to clean this up.
Sean
>
> Signed-off-by: Jeffy Chen
>
> ---
>
> Changes in v2:
> Remove unused check and variables.
>
> drivers/gpu/drm/rockchip/analogix_dp-rockchip.c | 14 +++---
> drivers/gpu/drm/rockchip/rockchip_drm_drv.h | 3 +--
> drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 20 +---
> 3 files changed, 13 insertions(+), 24 deletions(-)
>
> diff --git a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> index d8fa7a9..1bccd82 100644
> --- a/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> +++ b/drivers/gpu/drm/rockchip/analogix_dp-rockchip.c
> @@ -104,26 +104,18 @@ static void analogix_dp_psr_work(struct work_struct
> *work)
> {
> struct rockchip_dp_device *dp =
> container_of(work, typeof(*dp), psr_work);
> - struct drm_crtc *crtc = dp->encoder.crtc;
> - int psr_state = dp->psr_state;
> - int vact_end;
> int ret;
> unsigned long flags;
>
> - if (!crtc)
> - return;
> -
> - vact_end = crtc->mode.vtotal - crtc->mode.vsync_start +
> crtc->mode.vdisplay;
> -
> - ret = rockchip_drm_wait_line_flag(dp->encoder.crtc, vact_end,
> - PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
> + ret = rockchip_drm_wait_vact_end(dp->encoder.crtc,
> + PSR_WAIT_LINE_FLAG_TIMEOUT_MS);
> if (ret) {
> dev_err(dp->dev, "line flag interrupt did not arrive\n");
> return;
> }
>
> spin_lock_irqsave(&dp->psr_lock, flags);
> - if (psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> + if (dp->psr_state == EDP_VSC_PSR_STATE_ACTIVE)
> analogix_dp_enable_psr(dp->dev);
> else
> analogix_dp_disable_psr(dp->dev);
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> index a48fcce..47905fa 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
> @@ -62,8 +62,7 @@ int rockchip_drm_dma_attach_device(struct drm_device
> *drm_dev,
> struct device *dev);
> void rockchip_drm_dma_detach_device(struct drm_device *drm_dev,
> struct device *dev);
> -int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
> - unsigned int mstimeout);
> +int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsigned int
> mstimeout);
>
> extern struct platform_driver cdn_dp_driver;
> extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
> diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> index 3f7a82d..40a5e6e 100644
> --- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> +++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
> @@ -468,7 +468,7 @@ static bool vop_line_flag_irq_is_enabled(struct vop *vop)
> return !!line_flag_irq;
> }
>
> -static void vop_line_flag_irq_enable(struct vop *vop, int line_num)
> +static void vop_line_flag_irq_enable(struct vop *vop)
> {
> unsigned long flags;
>
> @@ -477,7 +477,6 @@ static void vop_line_flag_irq_enable(struct vop *vop, int
> line_num)
>
> spin_lock_irqsave(&vop->irq_lock, flags);
>
> - VOP_CTRL_SET(vop, line_flag_num[0], line_num);
> VOP_INTR_SET_TYPE(vop, clear, LINE_FLAG_INTR, 1);
> VOP_INTR_SET_TYPE(vop, enable, LINE_FLAG_INTR, 1);
>
> @@ -981,6 +980,8 @@ static void vop_crtc_enable(struct drm_crtc *crtc)
> VOP_CTRL_SET(vop, vact_st_end, val);
> VOP_CTRL_SET(vop, vpost_st_end, val);
>
> + VOP_CTRL_SET(vop, line_flag_num[0], vact_end);
> +
> clk_set_rate(vop->dclk, adjusted_mode->clock * 1000);
>
> VOP_CTRL_SET(vop, standby, 0);
> @@ -1507,19 +1508,16 @@ static void vop_win_init(struct vop *vop)
> }
>
> /**
> - * rockchip_drm_wait_line_flag - acqiure the give line flag event
> + * rockchip_drm_wait_vact_end
> * @crtc: CRTC to enable line flag
> - * @line_num: interested line number
> * @mstimeout: millisecond for timeout
> *
> - * Driver would hold here until the interested line flag interrupt have
> - * happened or timeout to wait.
> + * Wait for vact_end line flag irq or timeout.
> *
> * Returns:
> * Zero on success, negative errno on failure.
> */
> -int rockchip_drm_wait_line_flag(struct drm_crtc *crtc, unsigned int line_num,
> - unsigned int mstimeout)
> +int rockchip_drm_wait_vact_end(struct drm_crtc *crtc, unsig
[Bug 100687] KWin won't draw Aurorae themes under EGL
https://bugs.freedesktop.org/show_bug.cgi?id=100687 --- Comment #6 from MirceaKitsune --- Still an issue in Mesa 17.0.4. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/etnaviv: don't put fence in case of submit failure
If we bail out of the submit before actually adding the cmdstream to the kernel ring there is no valid fence to put. Make sure to skip the fence_put in that case. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c index e1909429837e..de80ee1b71df 100644 --- a/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c +++ b/drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c @@ -44,6 +44,7 @@ static struct etnaviv_gem_submit *submit_create(struct drm_device *dev, /* initially, until copy_from_user() and bo lookup succeeds: */ submit->nr_bos = 0; + submit->fence = NULL; ww_acquire_init(&submit->ticket, &reservation_ww_class); } @@ -294,7 +295,8 @@ static void submit_cleanup(struct etnaviv_gem_submit *submit) } ww_acquire_fini(&submit->ticket); - dma_fence_put(submit->fence); + if (submit->fence) + dma_fence_put(submit->fence); kfree(submit); } -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH RFC 5/7] ASoC: Add Odroid sound DT bindings documentation
On Fri, Apr 21, 2017 at 07:19:49PM +0200, Sylwester Nawrocki wrote:
> This patch adds DT binding documentation for Odroid XU3/4
> sound subsystem.
>
> Signed-off-by: Sylwester Nawrocki
> ---
> .../devicetree/bindings/sound/samsung,odroid.txt | 57
> ++
> 1 file changed, 57 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/sound/samsung,odroid.txt
>
> diff --git a/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> new file mode 100644
> index 000..c1ac70c
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/sound/samsung,odroid.txt
> @@ -0,0 +1,57 @@
> +Samsung Exynos Odroid XU3/XU4 audio complex with MAX98090 codec
> +
> +Required properties:
> +
> + - compatible - "samsung,odroidxu3-audio" - for Odroid XU3 board,
> + "samsung,odroidxu4-audio" - for Odroid XU4 board
> + - model - the user-visible name of this sound complex
ASoC will support "label" soon (see graph support). Use that instead.
> + - 'cpu' subnode with a 'sound-dai' property containing the phandle of the
> I2S
> +controller
> + - 'codec' subnode with a 'sound-dai' property containing list of phandles
> +to the CODEC nodes, first entry must be corresponding to the MAX98090
> +CODEC and the second entry must be the phandle of the HDMI IP block node
These are not properties, so move them to a sub-node section.
> + - clocks - should contain entries matching clock names in the clock-names
> +property
> + - clock-names - should contain following entries:
> +- "epll" - indicating the EPLL output clock
> +- "i2s_rclk" - indicating the RCLK (root) clock of the I2S0 controller
At least the 2nd one should be in the i2s node. This node isn't really a
h/w block, so it shouldn't have clocks IMO.
> + - samsung,audio-widgets - this property specifies off-codec audio elements
> + like headphones or speakers, for details see widgets.txt
> + - samsung,audio-routing - a list of the connections between audio
> + components; each entry is a pair of strings, the first being the
> + connection's sink, the second being the connection's source;
> + valid names for sources and sinks are the MAX98090's pins (as
> + documented in its binding), and the jacks on the board
> +
> + For Odroid X2:
> + "Headphone Jack", "Mic Jack", "DMIC"
> +
> + For Odroid U3, XU3:
> + "Headphone Jack", "Speakers"
> +
> + For Odroid XU4:
> + no entries
> +
> +Example:
> +
> +sound {
> + compatible = "samsung,odroidxu3-audio";
> + samsung,cpu-dai = <&i2s0>;
> + samsung,codec-dai = <&max98090>;
Not documented. Nor needed?
> + model = "Odroid-XU3";
> + samsung,audio-routing =
> + "Headphone Jack", "HPL",
> + "Headphone Jack", "HPR",
> + "IN1", "Mic Jack",
> + "Mic Jack", "MICBIAS";
> +
> + clocks = <&clock CLK_FOUT_EPLL>, <&i2s0 CLK_I2S_RCLK_SRC>;
> + clock-names = "epll", "sclk_i2s";
> +
> + cpu {
> + sound-dai = <&i2s0 0>;
> + };
> + codec {
> + sound-dai = <&hdmi>, <&max98090>;
> + };
> +};
> --
> 1.9.1
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v5 01/11] dt-bindings: add binding for the Allwinner DE2 CCU
On Sun, Apr 23, 2017 at 06:37:44PM +0800, Icenowy Zheng wrote: > Allwinner "Display Engine 2.0" contains some clock controls in it. > > In order to add them as clock drivers, we need a device tree binding. > Add the binding here. > > Also add the device tree binding headers. > > Signed-off-by: Icenowy Zheng > --- > Changes in v5: > - Moved dt-binding headers here. > - Changed dt-binding headers' license header to SPDX license. > Changes in v4: > - Dropped the leading 0 in clock at 100 . > Changes in v3: > - Fill the address space length of DE2 CCU to 0x10, just reach the start > of mixer0. > > .../devicetree/bindings/clock/sun8i-de2.txt| 31 > ++ > include/dt-bindings/clock/sun8i-de2.h | 18 + > include/dt-bindings/reset/sun8i-de2.h | 14 ++ > 3 files changed, 63 insertions(+) > create mode 100644 Documentation/devicetree/bindings/clock/sun8i-de2.txt > create mode 100644 include/dt-bindings/clock/sun8i-de2.h > create mode 100644 include/dt-bindings/reset/sun8i-de2.h Acked-by: Rob Herring ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm: fix splat when userspace is killed with pending atomic update
The ->preclose() hook is a good place to block for pending atomic
updates. We can't do this in ->postclose(), as it needs to happen
before drm_fb_release(). Otherwise, since we have already swapped
state (in the case of a non-blocking atomic update), this means that
the plane_state->fb will be released and cleared before we wait for
fences from the atomic-commit wq.
There are probably more complex solutions possible. But since already
scheduled atomic update, possibly blocking on already scheduled gpu/etc
fences, will complete eventually (assuming nothing catches fire), so
the sanest thing seems to be just block until already scheduled atomic
updates complete before tearing things down.
Fixes:
WARNING: CPU: 1 PID: 69 at ../drivers/gpu/drm/drm_atomic_helper.c:1061
drm_atomic_helper_wait_for_fences+0xe0/0xf8
Modules linked in:
CPU: 1 PID: 69 Comm: kworker/1:1 Tainted: GW 4.11.0-rc8+ #1187
Hardware name: Qualcomm Technologies, Inc. APQ 8016 SBC (DT)
Workqueue: events drm_mode_rmfb_work_fn
task: ffc036560d00 task.stack: ffc03655
PC is at drm_atomic_helper_wait_for_fences+0xe0/0xf8
LR is at complete_commit.isra.1+0x44/0x1c0
pc : [] lr : [] pstate: 2145
sp : ffc036553b60
x29: ffc036553b60 x28: ffc0264e6a00
x27: ffc035659000 x26:
x25: ffc0240e8000 x24: 0038
x23: x22: ff800858f200
x21: ffc0240e8000 x20: ffc02f56a800
x19: x18:
x17: x16:
x15: x14: ffc00a192700
x13: 0004 x12:
x11: ff80089a1690 x10: 08f0
x9 : ffc036553b20 x8 : ffc036561650
x7 : ffc03fe6cb40 x6 :
x5 : 0001 x4 : 0002
x3 : ffc035659000 x2 : ffc0240e8c80
x1 : x0 : ffc02adbe588
---[ end trace 13aeec77c3fb55e2 ]---
Call trace:
Exception stack(0xffc036553990 to 0xffc036553ac0)
3980: 0080
39a0: ffc036553b60 ff80084f6040 4ff0 0038
39c0: ffc0365539d0 ff800857e098 ffc036553a00 ff800857e1b0
39e0: ffc036553a10 ff800857c554 ffc0365e8400 ffc0365e8400
3a00: ffc036553a20 ff8008103358 0001aad7 ff800851b72c
3a20: ffc036553a50 ff80080e9228 ffc02adbe588
3a40: ffc0240e8c80 ffc035659000 0002 0001
3a60: ffc03fe6cb40 ffc036561650 ffc036553b20
3a80: 08f0 ff80089a1690 0004
3aa0: ffc00a192700
[] drm_atomic_helper_wait_for_fences+0xe0/0xf8
[] complete_commit.isra.1+0x44/0x1c0
[] msm_atomic_commit+0x32c/0x350
[] drm_atomic_commit+0x50/0x60
[] drm_atomic_remove_fb+0x158/0x250
[] drm_framebuffer_remove+0x50/0x158
[] drm_mode_rmfb_work_fn+0x40/0x58
[] process_one_work+0x1d0/0x378
[] worker_thread+0x244/0x488
[] kthread+0xfc/0x128
[] ret_from_fork+0x10/0x50
Reported-by: Stanimir Varbanov
Signed-off-by: Rob Clark
---
The hunk that removes the comment about ->preclose() included in this
patch to challenge the assumption that ->preclose() shouldn't exist ;-)
drivers/gpu/drm/msm/msm_drv.c | 10 +-
include/drm/drm_drv.h | 3 ---
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_drv.c b/drivers/gpu/drm/msm/msm_drv.c
index 87b5695..c8763b9 100644
--- a/drivers/gpu/drm/msm/msm_drv.c
+++ b/drivers/gpu/drm/msm/msm_drv.c
@@ -540,6 +540,13 @@ static int msm_open(struct drm_device *dev, struct
drm_file *file)
return 0;
}
+static void msm_preclose(struct drm_device *dev, struct drm_file *file)
+{
+ struct msm_drm_private *priv = dev->dev_private;
+
+ flush_workqueue(priv->atomic_wq);
+}
+
static void msm_postclose(struct drm_device *dev, struct drm_file *file)
{
struct msm_drm_private *priv = dev->dev_private;
@@ -813,7 +820,8 @@ static struct drm_driver msm_driver = {
DRIVER_ATOMIC |
DRIVER_MODESET,
.open = msm_open,
- .postclose = msm_postclose,
+ .preclose = msm_preclose,
+ .postclose = msm_postclose,
.lastclose = msm_lastclose,
.irq_handler= msm_irq,
.irq_preinstall = msm_irq_preinstall,
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 53b9832..a045ada 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -114,9 +114,6 @@ struct drm_driver {
* one &struct drm_file (see &drm_file.is_master and &drm_device.master)
* there should never be a need to tear down any modeset related
Re: [PATCH 1/3 v3] drm/vc4: Turn the V3D clock on at runtime.
On Mon, Apr 24, 2017 at 01:12:09PM -0700, Eric Anholt wrote: > For the Raspberry Pi's bindings, the power domain also implicitly > turns on the clock and deasserts reset, but for the new Cygnus port we > start representing the clock in the devicetree. > > v2: Document the clock-names property, check for -ENOENT for no clock > in DT. > v3: Drop NULL checks around clk calls which embed NULL checks. > > Signed-off-by: Eric Anholt > --- > .../devicetree/bindings/display/brcm,bcm-vc4.txt | 4 +++ > drivers/gpu/drm/vc4/vc4_drv.h | 1 + > drivers/gpu/drm/vc4/vc4_v3d.c | 31 > +- > 3 files changed, 35 insertions(+), 1 deletion(-) > > diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > index ca02d3e4db91..2318266f6481 100644 > --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt > @@ -59,6 +59,10 @@ Required properties for V3D: > - interrupts:The interrupt number > See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt > > +Optional properties for V3D: > +- clocks:The clock the unit runs on > +- clock-names: Must be "v3d_clk" clock-names is pointless for a single clock. > + > Required properties for DSI: > - compatible:Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1" > - reg: Physical base address and length of the DSI block's > registers ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCHv2 1/3] dt-bindings: display: Intel FPGA VIP drm driver Devicetree bindings
On Tue, Apr 25, 2017 at 10:06:44AM +0800, hean.loong@intel.com wrote:
> From: "Ong, Hean Loong"
>
> Device tree binding for Intel FPGA Video and Image
> Processing Suite. The binding involved would be generated
> from the Altera (Intel) Qsys system. The bindings would
> set the max width, max height, buts per pixel and memory
> port width. The device tree binding only supports the Intel
> Arria10 devkit and its variants. Vendor name retained as
> altr.
>
> Signed-off-by: Ong, Hean Loong
> ---
> v2:
> * Moved Device Tree bindings to Documentation/devicetree/bindings/display/
> * Added vendor name altr, to description
> ---
> .../devicetree/bindings/display/altr,vip-fb2.txt | 30
> ++
> 1 file changed, 30 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/display/altr,vip-fb2.txt
>
> diff --git a/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> new file mode 100644
> index 000..bdffefb
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/display/altr,vip-fb2.txt
> @@ -0,0 +1,30 @@
> +Intel Video and Image Processing(VIP) Frame Buffer II bindings
> +
> +Supported hardware: Arria 10 and above with display port IP
> +
> +The drm driver for the Arria 10 devkit would require the display resolution
Bindings describe h/w. DRM driver is a Linux term.
> +and pixel information to be included as these values are generated based
> +on the FPGA design that drives the video connector attached to the drm driver
> +Information the FPGA video IP component can be acquired from
> +https://www.altera.com/content/dam/altera-www/global/en_US/pdfs/literature/ug/ug_vip.pdf
> +
> +Required properties:
> +
> +- compatible: "altr,vip-frame-buffer-2.0"
> +- reg: Physical base address and length of the framebuffer controller's
> + registers.
> +- altr,max-width: The width of the framebuffer in pixels.
> +- altr,max-height: The height of the framebuffer in pixels.
> +- altr,bits-per-symbol: only "8" is currently supported
Supported in the driver or IP? The former isn't relevant to the binding.
In the latter case, you don't need it if that's the only thing
supported.
> +- altr,mem-port-width = the bus width of the avalon master port on the frame
> reader
In bits or bytes?
> +
> +Example:
> +
> + dp_0_frame_buf: vip@10280 {
> + compatible = "altr,vip-frame-buffer-2.0";
> + reg = <0x0001 0x0280 0x0040>;
> + altr,max-width = <1280>;
> + altr,max-height = <720>;
> + altr,bits-per-symbol = <8>;
> + altr,mem-port-width = <128>;
> + };
> --
> 2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Add new DRM_IOCTL_MODE_GETPLANE2
On 17-04-28 14:11:56, Lucas Stach wrote: Hi Ben, Am Dienstag, den 04.04.2017, 12:41 -0700 schrieb Ben Widawsky: On 17-04-04 11:07:26, Daniel Stone wrote: >Hi, > >On 1 April 2017 at 19:47, Rob Clark wrote: >> On Tue, Dec 20, 2016 at 7:12 PM, Kristian H. Kristensen >> wrote: >>> This new ioctl exctends DRM_IOCTL_MODE_GETPLANE, by returning >>> information about the modifiers that will work with each format. >> >> So, just to toss out a completely different idea.. >> >> What if instead of a new ioctl, we had a read-only blob property >> (which encoded the info basically the same way, plus the fourcc's)? >> >> If we do writeback via some sort of OUT_FB_ID property on plane/crtc, >> we will need the same sort of format information so userspace knows >> what output formats (and modifiers) are supported. So re-using the >> same blob property layout (and userspace parsing) seems useful. > >I'd definitely be cool with this. It doesn't make our lives any easier >or more difficult in terms of parsing, and it also avoids a dep on new >libdrm API/ABI, which is always nice. If anyone types this up, I'll >happily port the Weston WIP. > >Cheers, >Daniel Okay. Sounds like we have consensus. I'm working on it now. I think like Rob said on IRC, a good amount of it will be reusable from GET_PLANE2. I'm a bit new to the binary blob props, so if anyone has a strong opinion on how it should look, please speak now. Otherwise, I'll just wire up something. Can you tell me the status of this? I'm looking at adding tiled scanout to imx-drm and just want to know if it's worth to hold my breath for the reworked patch to arrive. Regards, Lucas The agreement was to use a blob property instead of GET_PLANE2. I wrote the patches: https://cgit.freedesktop.org/~bwidawsk/drm-intel/log/?h=blobifier However, my test vehicle, kmscube has broken on i915, so I haven't yet been able to test and therefore I didn't send them yet. Daniel said he'd try to wire it up to weston next week. I can go back and try to make it work with legacy kmscube as well, unless someone wants to fix kmscube/i915/i965 first? -- Ben Widawsky, Intel Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 96271] TF2: GPU lockup on HD 7950
https://bugs.freedesktop.org/show_bug.cgi?id=96271 --- Comment #10 from Marek Olšák --- This old commit should fix the lockups: https://cgit.freedesktop.org/mesa/mesa/commit/?id=6dc96de303290e8d1fc294da478c4f370be98dea -- 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 91880] Radeonsi on Grenada cards (r9 390) exceptionally unstable and poorly performing
https://bugs.freedesktop.org/show_bug.cgi?id=91880 --- Comment #151 from Marek Olšák --- Alfredo, did you try to switch the TDP switch on the side of the card? -- 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: [GIT PULL v2] drm/mali-dp changes for v4.12 (or drm-next)
On 27 April 2017 at 03:01, Liviu Dudau wrote: > Hi Dave, > > Updated pull request to fix the all-modconfig build on 32bit arm > builds. > > This pull request includes the latest updates on Mali DP, adding > support for colour management, plane scaling and power management. > The patches have trickled into the mailing list since February, and > have baked on linux-next for a few weeks (strangely, the 64bit div > was only caught yesterday). I'd have preferred if we could have gotten this before -rc6, though since it was all queued in -next already I should be okay to still pull it with the fix. Dave. > > Please pull. > > Many thanks, > Liviu > > The following changes since commit 6b1462700b4a6a1244c018cdd2fa97ded43090a0: > > Merge tag 'drm-misc-next-fixes-2017-04-20' of > git://anongit.freedesktop.org/git/drm-misc into drm-next (2017-04-21 13:51:59 > +1000) > > are available in the git repository at: > > git://linux-arm.org/linux-ld.git for-upstream/mali-dp > > for you to fetch changes up to 763656d30b3d220a52e4b2bd1fc174a4cd6c0f43: > > drm: mali-dp: use div_u64 for expensive 64-bit divisions (2017-04-26 > 17:54:58 +0100) > > > Arnd Bergmann (2): > drm: mali-dp: remove unused variable > drm: mali-dp: use div_u64 for expensive 64-bit divisions > > Liviu Dudau (3): > drm: mali-dp: Update the state of all planes before re-enabling active > CRTCs. > drm: mali-dp: Enable power management for the device. > drm/mali-dp: Add core_id file to the sysfs interface > > Mihail Atanassov (8): > drm: mali-dp: add atomic_print_state for planes > drm: mali-dp: add custom reset hook for planes > drm: mali-dp: add malidp_crtc_state struct > drm: mali-dp: enable gamma support > drm: mali-dp: Add CTM support > drm: mali-dp: Add plane upscaling support > drm: mali-dp: Enable image enhancement when scaling > drm: mali-dp: Check the mclk rate and allow up/down scaling > > drivers/gpu/drm/arm/malidp_crtc.c | 341 > ++-- > drivers/gpu/drm/arm/malidp_drv.c| 307 +--- > drivers/gpu/drm/arm/malidp_drv.h| 13 ++ > drivers/gpu/drm/arm/malidp_hw.c | 213 ++ > drivers/gpu/drm/arm/malidp_hw.h | 81 + > drivers/gpu/drm/arm/malidp_planes.c | 108 ++-- > drivers/gpu/drm/arm/malidp_regs.h | 72 +++- > 7 files changed, 1073 insertions(+), 62 deletions(-) > > -- > > | I would like to | > | fix the world, | > | but they're not | > | giving me the | > \ source code! / > --- > ¯\_(ツ)_/¯ > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/3 v3] drm/vc4: Turn the V3D clock on at runtime.
Rob Herring writes: > On Mon, Apr 24, 2017 at 01:12:09PM -0700, Eric Anholt wrote: >> For the Raspberry Pi's bindings, the power domain also implicitly >> turns on the clock and deasserts reset, but for the new Cygnus port we >> start representing the clock in the devicetree. >> >> v2: Document the clock-names property, check for -ENOENT for no clock >> in DT. >> v3: Drop NULL checks around clk calls which embed NULL checks. >> >> Signed-off-by: Eric Anholt >> --- >> .../devicetree/bindings/display/brcm,bcm-vc4.txt | 4 +++ >> drivers/gpu/drm/vc4/vc4_drv.h | 1 + >> drivers/gpu/drm/vc4/vc4_v3d.c | 31 >> +- >> 3 files changed, 35 insertions(+), 1 deletion(-) >> >> diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> index ca02d3e4db91..2318266f6481 100644 >> --- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> +++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt >> @@ -59,6 +59,10 @@ Required properties for V3D: >> - interrupts: The interrupt number >>See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt >> >> +Optional properties for V3D: >> +- clocks: The clock the unit runs on >> +- clock-names: Must be "v3d_clk" > > clock-names is pointless for a single clock. I thought the "-names" was the current style of future-proofing against finding another clock to put in the list. If I drop it, is the DT change acked? signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[pull] radeon and amdgpu drm-next-4.12
Hi Dave, Fixes for 4.12. Mostly updates for vega10 which is new for 4.12. Highlights: - Lots of vega10 fixes - fix interruptable wait mixup - misc display fixes for radeon and amdgpu - misc bug fixes The following changes since commit 73ba2d5c2bd4ecfec8fe37f20e962889b8a4c972: Merge tag 'drm-intel-next-fixes-2017-04-27' of git://anongit.freedesktop.org/git/drm-intel into drm-next (2017-04-29 05:50:27 +1000) are available in the git repository at: git://people.freedesktop.org/~agd5f/linux drm-next-4.12 for you to fetch changes up to c81a1a74037f61c578f6b8218b079aa434e300b4: drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup (2017-04-28 17:33:16 -0400) Alex Deucher (3): drm/amdgpu: fix spelling in header comment drm/amdgpu: bump version number to note race fix and new fence functionality Revert "drm/amd/amdgpu: Set VCE/UVD off during late init" Alex Xie (8): drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Real return value can be over-written when clean up drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting drm/amdgpu: Fix use of interruptible waiting Christian König (14): drm/amdgpu: add VMHUB to ring association drm/amdgpu: drop VMID per ring tracking drm/amdgpu: split VMID management by VMHUB drm/amdgpu: invalidate only the currently needed VMHUB v2 drm/amdgpu: assign VM invalidation engine manually v2 drm/amdgpu: allow concurrent VM flushes drm/amdgpu: trace the vmhub in grab_id as well drm/amdgpu: trace vm hub during flush as well v2 drm/radeon: force the UVD DPB into VRAM as well drm/amdgpu: fix coding style and printing in amdgpu_doorbell_init drm/amdgpu: fix amdgpu_vm_clear_freed v2 drm/amdgpu: fix amdgpu_ttm_bo_eviction_valuable drm/amdgpu: fix VM clearing in amdgpu_gem_object_close drm/amdgpu: remove unused and mostly unimplemented CGS functions v2 Chunming Zhou (6): drm/amdgpu: add gtt print like vram when dump mm table V2 drm/amdgpu: increase gtt size to 3GB by default v2 drm/amdgpu: fix no-vmid job drm/amdgpu: fix gpu reset crash drm/amdgpu: fix NULL pointer error drm/amdgpu: fix deadlock of reservation between cs and gpu reset v2 Daniel Wang (2): drm/amdgpu/psp: skip loading SDMA/RLCG under SRIOV VF drm/amdgpu/vce4: fix a PSP loading VCE issue Evan Quan (1): drm/amdgpu: update smu9 driver interface Frank Min (7): drm/amdgpu/vce4: update VCE initialization sequence for SRIOV drm/amdgpu/vce4: enable ring & ib test for sriov drm/amdgpu/vce4: move mm table constructions functions into mmsch header file drm/amdgpu/uvd7: add sriov uvd initialization sequences drm/amdgpu/uvd7: add uvd doorbell initialization for sriov drm/amdgpu/uvd7: add UVD hw init sequences for sriov drm/amdgpu/soc15: enable UVD code path for sriov Huang Rui (14): drm/amdgpu: split psp tmr init function drm/amdgpu: add psp firmware private memory drm/amdgpu: use private memory to store psp firmware data drm/amdgpu: split psp asd function drm/amdgpu: split psp ring init function drm/amdgpu: add hw_start and non-psp firmware loading into resume drm/amd/powerplay: fix suspend error on DPM disabled drm/amdgpu: do not free fence buf when driver probes. drm/amdgpu: fix to clear ASIC INIT COMPLETE bit on resuming phase drm/amdgpu: fix to add buffer funcs check drm/amdgpu: fix dead lock if any ip block resume failed in s3 drm/amdgpu: fix to print incorrect wptr address drm/ttm: cleanup unuse ret value drm/amd/powerplay: add error message to remind user updating firmware Junwei Zhang (3): drm/amdgpu: fix double_offchip_lds_buf for gfx v6 drm/amdgpu: export more gpu info for gfx9 drm/amdgpu: bump version for exporting gpu info for gfx9 Mario Kleiner (3): drm/amdgpu: Add missing lb_vblank_lead_lines setup to DCE-6 path. drm/radeon: Avoid overflows/divide-by-zero in latency_watermark calculations. drm/radeon: Make display watermark calculations more accurate Michel Dänzer (1): drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup Monk Liu (1): drm/amdgpu:fix race condition Pan Bian (2): drm/radeon: check return value of radeon_ring_lock drm/radeon: check return value of radeon_fence_emit Pixel Ding (1): drm/amdgpu/virt: don't check VALID bit for FLR completion message Rex Zhu (16): drm/amd/powerplay: align with VBIOS to support new AVFS structure drm/amdgpu: Remove redundant itermediate return val in sdma_v4_0.c drm/amd/
Re: Proposal for RandR version 1.6, Leases and EDID-based output grabs
Pekka Paalanen writes:
> IMHO, if nothing is providing a picture intended for the HMD, the HMD
> should be off. There is no use in showing an arbitrary image that does
> not look right, is there?
Well, if the HMD is being worn and the application crashes, then
what you want is something that keeps responding to your motion so you
can get the HMD off without falling or running into stuff...
But, yeah, in general, if you don't have an HMD application running, the
HMD can't usefully show anything from a bare window system. The trick is
to make sure existing desktop applications don't try to use it by mistake.
> even if the database was just a bunch of files, you still need code to
> access it, and probably something to ensure the entries are
> well-formed, so that everyone will agree on how to parse them. One
> should probably decide whether the database will only answer the
> question "is it a HMD?" or can it provide other information as well.
Yup, we need a spec for the files that is reasonably sane, and also
extensible so that if we want to add new data, we can. I discussed this
with Eric Anholt at breakfast this morning and we came up with a couple
of ideas:
1) A directory full of files, each file can contain one or more monitor
entries
2) Monitors should be identified (at a minimum) using the EDID
Manufacturer ID and Manufacturer product code. I can imagine
also allowing the use of a serial number and/or date code if we end
up using this for more stuff later.
3) Window system independent. We obviously need this for X, but
other window systems should share the same data.
4) Use an existing format. Both of us would rather use JSON, but
there's already XML in the DRM world, so that might make
sense. These are functionally equivalent, but XML syntax is rough on
the eyes.
5) Allow multiple definitions in each file, but allow for multiple
files too.
Here's a JSON-formatted example:
{
"monitors": [
{
"Manufacturer" : "LGD",
"Product" : 437,
"desktop" : true
}
]
"copyright" : "Copyright © 2017, Keith Packard",
"license" : "GPLv3"
}
One can imagine the same done in XML, but I'm too lazy to type that
here. In any case, as you can see above, I've added a "desktop" field;
if false, the monitor would be hidden to 'normal' desktop applications
and only made visible to others.
Questions:
Q) Where should the directory live.
A) /usr/share/monitors for distribution-provided files, /etc/monitors
for application-provided files.
Q) How about RandR protocol.
A) I'm thinking of just creating a new randr request like
RRGetOutputInfo but which will return even "hidden" outputs with
non-spoofed 'connection' value.
Q) What file names should the entries use.
A) How about just the manufacturer and product of the first entry?
Q) Ranges of product ids?
A) Yeah, we might want this to avoid a lot of duplicate entries.
--
-keith
signature.asc
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 2/3] drm/vc4: Don't try to initialize FBDEV if we're only bound to V3D.
The FBDEV initialization would throw an error in dmesg, when we just
want to silently not initialize fbdev on a V3D-only VC4 instance.
Signed-off-by: Eric Anholt
---
drivers/gpu/drm/vc4/vc4_kms.c | 10 ++
1 file changed, 6 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/vc4/vc4_kms.c b/drivers/gpu/drm/vc4/vc4_kms.c
index ad7925a9e0ea..237a504f11f0 100644
--- a/drivers/gpu/drm/vc4/vc4_kms.c
+++ b/drivers/gpu/drm/vc4/vc4_kms.c
@@ -230,10 +230,12 @@ int vc4_kms_load(struct drm_device *dev)
drm_mode_config_reset(dev);
- vc4->fbdev = drm_fbdev_cma_init(dev, 32,
- dev->mode_config.num_connector);
- if (IS_ERR(vc4->fbdev))
- vc4->fbdev = NULL;
+ if (dev->mode_config.num_connector) {
+ vc4->fbdev = drm_fbdev_cma_init(dev, 32,
+ dev->mode_config.num_connector);
+ if (IS_ERR(vc4->fbdev))
+ vc4->fbdev = NULL;
+ }
drm_kms_helper_poll_init(dev);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v4 1/3] drm/vc4: Turn the V3D clock on at runtime.
For the Raspberry Pi's bindings, the power domain also implicitly
turns on the clock and deasserts reset, but for the new Cygnus port we
start representing the clock in the devicetree.
v2: Document the clock-names property, check for -ENOENT for no clock
in DT.
v3: Drop NULL checks around clk calls which embed NULL checks.
v4: Drop clk-names (feedback by Rob Herring)
Signed-off-by: Eric Anholt
---
.../devicetree/bindings/display/brcm,bcm-vc4.txt | 3 +++
drivers/gpu/drm/vc4/vc4_drv.h | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 31 +-
3 files changed, 34 insertions(+), 1 deletion(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index ca02d3e4db91..bc1756f4f791 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -59,6 +59,9 @@ Required properties for V3D:
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
+Optional properties for V3D:
+- clocks: The clock the unit runs on
+
Required properties for DSI:
- compatible: Should be "brcm,bcm2835-dsi0" or "brcm,bcm2835-dsi1"
- reg: Physical base address and length of the DSI block's registers
diff --git a/drivers/gpu/drm/vc4/vc4_drv.h b/drivers/gpu/drm/vc4/vc4_drv.h
index b0967e2f7e88..92eb7d811bf2 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.h
+++ b/drivers/gpu/drm/vc4/vc4_drv.h
@@ -200,6 +200,7 @@ struct vc4_v3d {
struct vc4_dev *vc4;
struct platform_device *pdev;
void __iomem *regs;
+ struct clk *clk;
};
struct vc4_hvs {
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index a88078d7c9d1..7500820e5cd5 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -16,6 +16,7 @@
* this program. If not, see
[PATCH v4 3/3] drm/vc4: Add specific compatible strings for Cygnus.
Cygnus has V3D 2.6 instead of 2.1, and doesn't use the VC4 display
modules. The V3D can be uniquely identified by the IDENT[01]
registers, and there's nothing to key off of for the display change
other than the lack of DT nodes for the display components, but it's
convention to have new compatible strings anyway.
Signed-off-by: Eric Anholt
Acked-by: Rob Herring
---
Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt | 4 ++--
drivers/gpu/drm/vc4/vc4_drv.c | 1 +
drivers/gpu/drm/vc4/vc4_v3d.c | 1 +
3 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
index bc1756f4f791..284e2b14cfbe 100644
--- a/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
+++ b/Documentation/devicetree/bindings/display/brcm,bcm-vc4.txt
@@ -5,7 +5,7 @@ with HDMI output and the HVS (Hardware Video Scaler) for
compositing
display planes.
Required properties for VC4:
-- compatible: Should be "brcm,bcm2835-vc4"
+- compatible: Should be "brcm,bcm2835-vc4" or "brcm,cygnus-vc4"
Required properties for Pixel Valve:
- compatible: Should be one of "brcm,bcm2835-pixelvalve0",
@@ -54,7 +54,7 @@ Required properties for VEC:
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
Required properties for V3D:
-- compatible: Should be "brcm,bcm2835-v3d"
+- compatible: Should be "brcm,bcm2835-v3d" or "brcm,cygnus-v3d"
- reg: Physical base address and length of the V3D's registers
- interrupts: The interrupt number
See bindings/interrupt-controller/brcm,bcm2835-armctrl-ic.txt
diff --git a/drivers/gpu/drm/vc4/vc4_drv.c b/drivers/gpu/drm/vc4/vc4_drv.c
index 92fb9a41fe7c..754ce76d4b98 100644
--- a/drivers/gpu/drm/vc4/vc4_drv.c
+++ b/drivers/gpu/drm/vc4/vc4_drv.c
@@ -335,6 +335,7 @@ static int vc4_platform_drm_remove(struct platform_device
*pdev)
static const struct of_device_id vc4_of_match[] = {
{ .compatible = "brcm,bcm2835-vc4", },
+ { .compatible = "brcm,cygnus-vc4", },
{},
};
MODULE_DEVICE_TABLE(of, vc4_of_match);
diff --git a/drivers/gpu/drm/vc4/vc4_v3d.c b/drivers/gpu/drm/vc4/vc4_v3d.c
index 7500820e5cd5..c53afec34586 100644
--- a/drivers/gpu/drm/vc4/vc4_v3d.c
+++ b/drivers/gpu/drm/vc4/vc4_v3d.c
@@ -450,6 +450,7 @@ static int vc4_v3d_dev_remove(struct platform_device *pdev)
static const struct of_device_id vc4_v3d_dt_match[] = {
{ .compatible = "brcm,bcm2835-v3d" },
+ { .compatible = "brcm,cygnus-v3d" },
{ .compatible = "brcm,vc4-v3d" },
{}
};
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
On 28/04/17 12:30 AM, Herbert Xu wrote: > You are right. Indeed the existing code looks buggy as they > don't take sg->offset into account when doing the kmap. Could > you send me some patches that fix these problems first so that > they can be easily backported? Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam both do have the sg->offset accounted for. I'll send a patch for the buggy one shortly. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/2] drm: Introduce crtc->mode_valid() callback
Hi Ville,
Thanks for the review! My comments inline.
On 28-04-2017 12:41, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 11:48:34AM +0100, Jose Abreu wrote:
>> Some crtc's may have restrictions in the mode they can display. In
>> this patch a new callback (crtc->mode_valid()) is introduced that
>> is called at the same stage of connector->mode_valid() callback.
>>
>> This shall be implemented if the crtc has some sort of restriction
>> so that we don't probe modes that will fail in the commit() stage.
>> For example: A given crtc may be responsible to set a clock value.
>> If the clock can not produce all the values for the available
>> modes then this callback can be used to restrict the number of
>> probbed modes to only the ones that can be displayed.
>>
>> If the crtc does not implement the callback then the behaviour will
>> remain the same. Also, for a given set of crtcs that can be bound to
>> the connector, if at least one can display the mode then the mode
>> will be probbed.
>>
>> Signed-off-by: Jose Abreu
>> Cc: Carlos Palminha
>> Cc: Alexey Brodkin
>> Cc: Ville Syrjälä
>> Cc: Daniel Vetter
>> Cc: Dave Airlie
>> ---
>> drivers/gpu/drm/drm_probe_helper.c | 44
>>
>> include/drm/drm_modeset_helper_vtables.h | 26 +++
>> 2 files changed, 70 insertions(+)
>>
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index 1b0c14a..61eac30 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -80,6 +80,46 @@
>> return MODE_OK;
>> }
>>
>> +static enum drm_mode_status drm_mode_validate_connector_crtc(
>> +struct drm_connector *connector,
>> +struct drm_display_mode *mode)
> Probably more typical way to split the lines would be:
> static enum drm_mode_status
> drm_mode_validate_connector_crtc(struct drm_connector *connector,
>struct drm_display_mode *mode)
Agree.
>
> Also 'mode' should be const. Looks like the connector->mode_valid()
> hook is missing the const as well, so that too should be fixed.
Yeah, thats why I didn't use const here. If I change
connector->mode_valid() then I will need to change every driver
who uses it. Please don't get me wrong but I'm not fully
allocated to patch submission, can we focus on getting this patch
merged first and then change the connector->mode_valid() to const
when I have the time?
>
> Not sure about the name of the function. It doesn't really reflect what
> it does in the best way possible. drm_mode_validate_connector_possible_crtcs()
> perhaps? But that is getting quite long so not sure if it' a good idea
> either. I guess simply making the name refer to plural crtcs might be
> a reasonable compromise, ie. drm_mode_validate_connector_crtcs()?
Sounds fine by me :)
>
>> +{
>> +const struct drm_crtc_helper_funcs *crtc_funcs = NULL;
>> +enum drm_mode_status mode_status = MODE_ERROR;
>> +struct drm_device *dev = connector->dev;
>> +struct drm_encoder *encoder;
>> +struct drm_crtc *crtc;
> A lot of these can be moved into tighter scope.
Agree.
>
>> +bool callback_found = false;
> I don't think you need this variable at all. See below.
>
>> +int i;
>> +
>> +for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
>> +encoder = drm_encoder_find(dev, connector->encoder_ids[i]);
>> +
>> +if (!encoder)
>> +continue;
>> +
>> +drm_for_each_crtc(crtc, dev) {
>> +crtc_funcs = crtc->helper_private;
>> +
>> +if (!drm_encoder_crtc_ok(encoder, crtc))
>> +continue;
>> +if (!crtc_funcs || !crtc_funcs->mode_valid)
>> +continue;
>> +
>> +/* MODE_OK=0 and default mode_status=MODE_ERROR=-1
>> + * so if at least one crtc accepts the mode we get
>> + * MODE_OK */
>> +mode_status &= crtc_funcs->mode_valid(crtc, mode);
>> +callback_found |= true;
> The need for a comment here tells me that it's probably better
> to got for a more straightforward code. Something like:
>
> mode_status = crtc_funcs->mode_valid(crtc, mode);
> if (mode_statys == MODE_OK)
> return mode_status;
Actually I was planning to send a new version with "return" in
the inner loop to avoid unneeded work as the mode would be
accepted anyway, so thats more than agreed :)
>
> And at the end of the function just return MODE_ERROR, or
> some other error value if we have something suitable. Hmm.
> Perhaps we should just return the error from the first or last
> crtc? Either should be pretty easy, just "ret = mode_status" within
> the loop if it didn't return MODE_OK and then 'return ret' at the
> end of the function.
When I was writing this I also though about what error should be
returned on failure. I left the
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Tomi Valkeinen [170428 04:15]: > On 14/04/17 13:25, Hans Verkuil wrote: > > From: Hans Verkuil > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > Change to PIN_INPUT so it can be used by the new CEC support. ... > Reviewed-by: Tomi Valkeinen > > Tony, can you queue this? It's safe to apply separately from the rest of > the HDMI CEC work. Sure will do. Thanks, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
On Thu, Apr 27, 2017 at 09:45:57AM -0600, Logan Gunthorpe wrote:
>
>
> On 26/04/17 09:56 PM, Herbert Xu wrote:
> > On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
> >> Very straightforward conversion to the new function in the caam driver
> >> and shash library.
> >>
> >> Signed-off-by: Logan Gunthorpe
> >> Cc: Herbert Xu
> >> Cc: "David S. Miller"
> >> ---
> >> crypto/shash.c| 9 ++---
> >> drivers/crypto/caam/caamalg.c | 8 +++-
> >> 2 files changed, 9 insertions(+), 8 deletions(-)
> >>
> >> diff --git a/crypto/shash.c b/crypto/shash.c
> >> index 5e31c8d..5914881 100644
> >> --- a/crypto/shash.c
> >> +++ b/crypto/shash.c
> >> @@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req,
> >> struct shash_desc *desc)
> >>if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
> >>void *data;
> >>
> >> - data = kmap_atomic(sg_page(sg));
> >> - err = crypto_shash_digest(desc, data + offset, nbytes,
> >> + data = sg_map(sg, 0, SG_KMAP_ATOMIC);
> >> + if (IS_ERR(data))
> >> + return PTR_ERR(data);
> >> +
> >> + err = crypto_shash_digest(desc, data, nbytes,
> >> req->result);
> >> - kunmap_atomic(data);
> >> + sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);
> >>crypto_yield(desc->flags);
> >>} else
> >>err = crypto_shash_init(desc) ?:
> >
> > Nack. This is an optimisation for the special case of a single
> > SG list entry. In fact in the common case the kmap_atomic should
> > disappear altogether in the no-highmem case. So replacing it
> > with sg_map is not acceptable.
>
> What you seem to have missed is that sg_map is just a thin wrapper
> around kmap_atomic. Perhaps with a future check for a mappable page.
> This change should have zero impact on performance.
You are right. Indeed the existing code looks buggy as they
don't take sg->offset into account when doing the kmap. Could
you send me some patches that fix these problems first so that
they can be easily backported?
Thanks,
--
Email: Herbert Xu
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 4/4] drm/dp: Track MST link bandwidth
From: "Pandiyan, Dhinakaran"
Use the added helpers to track MST link bandwidth for atomic modesets.
Link bw is acquired in the ->atomic_check() phase when CRTCs are being
enabled with drm_atomic_find_vcpi_slots(). Similarly, link bw is released
during ->atomic_check() with the connector helper callback ->atomic_check()
when CRTCs are disabled.
v6: active_changed does not alter vcpi allocations (Maarten)
v5: Implement connector->atomic_check() in place of atomic_release()
v4: Return an int from intel_dp_mst_atomic_release() (Maarten)
v3:
Handled the case where ->atomic_release() is called more than once
during an atomic_check() for the same state.
v2:
Squashed atomic_release() implementation and caller (Daniel)
Fixed logic for connector-crtc switching case (Daniel)
Fixed logic for suspend-resume case.
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Archit Taneja
Cc: Chris Wilson
Cc: Harry Wentland
Signed-off-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/i915/intel_dp_mst.c | 48 -
1 file changed, 42 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 5af22a7..68c788e 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -39,7 +39,7 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
struct intel_dp *intel_dp = &intel_dig_port->dp;
struct intel_connector *connector =
to_intel_connector(conn_state->connector);
- struct drm_atomic_state *state;
+ struct drm_atomic_state *state = pipe_config->base.state;
int bpp;
int lane_count, slots;
const struct drm_display_mode *adjusted_mode =
&pipe_config->base.adjusted_mode;
@@ -57,20 +57,24 @@ static bool intel_dp_mst_compute_config(struct
intel_encoder *encoder,
* seem to suggest we should do otherwise.
*/
lane_count = intel_dp_max_lane_count(intel_dp);
-
pipe_config->lane_count = lane_count;
pipe_config->pipe_bpp = bpp;
- pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
- state = pipe_config->base.state;
+ pipe_config->port_clock = intel_dp_max_link_rate(intel_dp);
if (drm_dp_mst_port_has_audio(&intel_dp->mst_mgr, connector->port))
pipe_config->has_audio = true;
- mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
+ mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp);
pipe_config->pbn = mst_pbn;
- slots = drm_dp_find_vcpi_slots(&intel_dp->mst_mgr, mst_pbn);
+
+ slots = drm_dp_atomic_find_vcpi_slots(state, &intel_dp->mst_mgr,
+ connector->port, mst_pbn);
+ if (slots < 0) {
+ DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots);
+ return false;
+ }
intel_link_compute_m_n(bpp, lane_count,
adjusted_mode->crtc_clock,
@@ -80,7 +84,38 @@ static bool intel_dp_mst_compute_config(struct intel_encoder
*encoder,
pipe_config->dp_m_n.tu = slots;
return true;
+}
+static int intel_dp_mst_atomic_check(struct drm_connector *connector,
+ struct drm_connector_state *new_conn_state)
+{
+ struct drm_atomic_state *state = new_conn_state->state;
+ struct drm_connector_state *old_conn_state;
+ struct drm_crtc *old_crtc;
+ struct drm_crtc_state *crtc_state;
+ int slots, ret = 0;
+
+ old_conn_state = drm_atomic_get_old_connector_state(state, connector);
+ old_crtc = old_conn_state->crtc;
+ if (!old_crtc)
+ return ret;
+
+ crtc_state = drm_atomic_get_new_crtc_state(state, old_crtc);
+ slots = to_intel_crtc_state(crtc_state)->dp_m_n.tu;
+ if (drm_atomic_crtc_needs_modeset(crtc_state) && slots > 0) {
+ struct drm_dp_mst_topology_mgr *mgr;
+ struct drm_encoder *old_encoder;
+
+ old_encoder = old_conn_state->best_encoder;
+ mgr = &enc_to_mst(old_encoder)->primary->dp.mst_mgr;
+
+ ret = drm_dp_atomic_release_vcpi_slots(state, mgr, slots);
+ if (ret)
+ DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n",
slots, ret);
+ else
+ to_intel_crtc_state(crtc_state)->dp_m_n.tu = 0;
+ }
+ return ret;
}
static void intel_mst_disable_dp(struct intel_encoder *encoder,
@@ -378,6 +413,7 @@ static const struct drm_connector_helper_funcs
intel_dp_mst_connector_helper_fun
.mode_valid = intel_dp_mst_mode_valid,
.atomic_best_encoder = intel_mst_atomic_best_encoder,
.best_encoder = intel_mst_best_encoder,
+ .atomic_check = intel_dp_mst_atomic_check,
};
static void intel_dp_mst_encoder_destroy(struct drm_encoder *encoder)
--
2.7.4
___
dri-devel ma
[PATCH v2 1/2] drm: Introduce crtc->mode_valid() callback
Some crtc's may have restrictions in the mode they can display. In
this patch a new callback (crtc->mode_valid()) is introduced that
is called at the same stage of connector->mode_valid() callback.
This shall be implemented if the crtc has some sort of restriction
so that we don't probe modes that will fail in the commit() stage.
For example: A given crtc may be responsible to set a clock value.
If the clock can not produce all the values for the available
modes then this callback can be used to restrict the number of
probbed modes to only the ones that can be displayed.
If the crtc does not implement the callback then the behaviour will
remain the same. Also, for a given set of crtcs that can be bound to
the connector, if at least one can display the mode then the mode
will be probbed.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
---
Changes v1->v2:
- Correct indentation
- Change function name to drm_validate_connector
- Move connnector->mode_valid() to new function
- Change crtc->mode_valid() "mode" field to const
- Code reogarnization
- Return earlier if crtc accepts mode
drivers/gpu/drm/drm_probe_helper.c | 50 ++--
include/drm/drm_modeset_helper_vtables.h | 26 +
2 files changed, 74 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_probe_helper.c
b/drivers/gpu/drm/drm_probe_helper.c
index 1b0c14a..0741f36 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -80,6 +80,52 @@
return MODE_OK;
}
+static enum drm_mode_status
+drm_mode_validate_connector(struct drm_connector *connector,
+ struct drm_display_mode *mode)
+{
+ const struct drm_connector_helper_funcs *connector_funcs =
+ connector->helper_private;
+ struct drm_device *dev = connector->dev;
+ uint32_t *ids = connector->encoder_ids;
+ enum drm_mode_status ret = MODE_OK;
+ unsigned int i;
+
+ /* Step 1: Validate against connector */
+ if (connector_funcs->mode_valid)
+ ret = connector_funcs->mode_valid(connector, mode);
+
+ if (ret != MODE_OK)
+ return ret;
+
+ /* Step 2: Validate against crtc's */
+ for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
+ struct drm_encoder *encoder = drm_encoder_find(dev, ids[i]);
+ struct drm_crtc *crtc;
+
+ if (!encoder)
+ continue;
+
+ drm_for_each_crtc(crtc, dev) {
+ const struct drm_crtc_helper_funcs *crtc_funcs;
+
+ if (!drm_encoder_crtc_ok(encoder, crtc))
+ continue;
+
+ crtc_funcs = crtc->helper_private;
+ if (!crtc_funcs || !crtc_funcs->mode_valid)
+ return MODE_OK; /* crtc accepts everything */
+
+ ret = crtc_funcs->mode_valid(crtc, mode);
+ if (ret == MODE_OK)
+ return ret;
+ }
+ }
+
+ /* NOTE: If no crtc or encoder is found then we return MODE_OK */
+ return ret;
+}
+
static int drm_helper_probe_add_cmdline_mode(struct drm_connector *connector)
{
struct drm_cmdline_mode *cmdline_mode;
@@ -428,8 +474,8 @@ int drm_helper_probe_single_connector_modes(struct
drm_connector *connector,
if (mode->status == MODE_OK)
mode->status = drm_mode_validate_flag(mode, mode_flags);
- if (mode->status == MODE_OK && connector_funcs->mode_valid)
- mode->status = connector_funcs->mode_valid(connector,
+ if (mode->status == MODE_OK)
+ mode->status = drm_mode_validate_connector(connector,
mode);
}
diff --git a/include/drm/drm_modeset_helper_vtables.h
b/include/drm/drm_modeset_helper_vtables.h
index c01c328..ecb055c 100644
--- a/include/drm/drm_modeset_helper_vtables.h
+++ b/include/drm/drm_modeset_helper_vtables.h
@@ -106,6 +106,32 @@ struct drm_crtc_helper_funcs {
void (*commit)(struct drm_crtc *crtc);
/**
+* @mode_valid:
+*
+* This callback should be implemented if the crtc has some sort of
+* restriction in the modes it can display. For example, a given crtc
+* may be responsible to set a clock value. If the clock can not
+* produce all the values for the available modes then this callback
+* can be used to restrict the number of probbed modes to only the ones
+* that can be displayed.
+*
+* This is directly called at the same stage of connector->mode_valid
+* callback.
+*
+* NOTE:
+*
+
[PATCH v2 2/2] drm: arcpgu: Use crtc->mode_valid() callback
Now that we have a callback to check if crtc supports a given mode
we can use it in arcpgu so that we restrict the number of probbed
modes to the ones we can actually display.
This is specially useful because arcpgu crtc is responsible to set
a clock value in the commit() stage but unfortunatelly this clock
does not support all the needed ranges.
Signed-off-by: Jose Abreu
Cc: Carlos Palminha
Cc: Alexey Brodkin
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Dave Airlie
Cc: Andrzej Hajda
---
Changes v1->v2:
- Reduce code duplication by using helper function
- crtc->mode_valid() "mode" field is now const
drivers/gpu/drm/arc/arcpgu_crtc.c | 28 +---
1 file changed, 25 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a959..631d86d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -32,6 +32,18 @@
{ "r8g8b8", 24, {16, 8}, {8, 8}, {0, 8}, {0, 0}, DRM_FORMAT_RGB888 },
};
+static bool arc_pgu_is_mode_valid(struct arcpgu_drm_private *arcpgu,
+ const struct drm_display_mode *mode)
+{
+ long rate, clk_rate = mode->clock * 1000;
+
+ rate = clk_round_rate(arcpgu->clk, clk_rate);
+ if (rate != clk_rate)
+ return false;
+
+ return true;
+}
+
static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -64,6 +76,17 @@ static void arc_pgu_set_pxl_fmt(struct drm_crtc *crtc)
.atomic_destroy_state = drm_atomic_helper_crtc_destroy_state,
};
+enum drm_mode_status arc_pgu_crtc_mode_valid(struct drm_crtc *crtc,
+const struct drm_display_mode
*mode)
+{
+ struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
+
+ if (!arc_pgu_is_mode_valid(arcpgu, mode))
+ return MODE_NOCLOCK;
+
+ return MODE_OK;
+}
+
static void arc_pgu_crtc_mode_set_nofb(struct drm_crtc *crtc)
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
@@ -134,10 +157,8 @@ static int arc_pgu_crtc_atomic_check(struct drm_crtc *crtc,
{
struct arcpgu_drm_private *arcpgu = crtc_to_arcpgu_priv(crtc);
struct drm_display_mode *mode = &state->adjusted_mode;
- long rate, clk_rate = mode->clock * 1000;
- rate = clk_round_rate(arcpgu->clk, clk_rate);
- if (rate != clk_rate)
+ if (!arc_pgu_is_mode_valid(arcpgu, mode))
return -EINVAL;
return 0;
@@ -158,6 +179,7 @@ static void arc_pgu_crtc_atomic_begin(struct drm_crtc *crtc,
}
static const struct drm_crtc_helper_funcs arc_pgu_crtc_helper_funcs = {
+ .mode_valid = arc_pgu_crtc_mode_valid,
.mode_set = drm_helper_crtc_mode_set,
.mode_set_base = drm_helper_crtc_mode_set_base,
.mode_set_nofb = arc_pgu_crtc_mode_set_nofb,
--
1.9.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
On 28/04/17 11:51 AM, Herbert Xu wrote: > On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: >> >> >> On 28/04/17 12:30 AM, Herbert Xu wrote: >>> You are right. Indeed the existing code looks buggy as they >>> don't take sg->offset into account when doing the kmap. Could >>> you send me some patches that fix these problems first so that >>> they can be easily backported? >> >> Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam >> both do have the sg->offset accounted for. I'll send a patch for the >> buggy one shortly. > > I think they're all buggy when sg->offset is greater than PAGE_SIZE. Yes, technically. But that's a _very_ common mistake. Pretty nearly every case I looked at did not take that into account. I don't think sg's that point to more than one continuous page are all that common. Fixing all those cases without making a common function is a waste of time IMO. Logan ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
On Fri, Apr 28, 2017 at 10:53:45AM -0600, Logan Gunthorpe wrote: > > > On 28/04/17 12:30 AM, Herbert Xu wrote: > > You are right. Indeed the existing code looks buggy as they > > don't take sg->offset into account when doing the kmap. Could > > you send me some patches that fix these problems first so that > > they can be easily backported? > > Ok, I think the only buggy one in crypto is hifn_795x. Shash and caam > both do have the sg->offset accounted for. I'll send a patch for the > buggy one shortly. I think they're all buggy when sg->offset is greater than PAGE_SIZE. Thanks, -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v2 0/2] Introduce crtc->mode_valid() callback
This patchset introduces a new callback for crtc, called mode_valid() that is responsible to limit the number of probbed modes. Just like connector->mode_valid(), this new callback is called at mode probbing stage so that we can validate the mode. This is specially useful because arcpgu crtc is responsible to set a clock value in the commit() stage but unfortunatelly this clock does not support all the needed ranges. This way we can restrict the number of modes that are handed to userspace, so that we dont hand a mode that will fail the commit() stage. I guess this can also happen for other drivers so we introduce the callback in the core. The behaviour remains the same for crtcs that don't have the callback. Also, for a given set of crtcs that can be bound to the connector, if at least one can display the mode then the mode will be probbed. For more info about why this is needed in arcpgu, please refer here [1]. [1] https://patchwork.kernel.org/patch/9694177/ Jose Abreu (2): drm: Introduce crtc->mode_valid() callback drm: arcpgu: Use crtc->mode_valid() callback Cc: Carlos Palminha Cc: Alexey Brodkin Cc: Ville Syrjälä Cc: Daniel Vetter Cc: Dave Airlie Cc: Andrzej Hajda drivers/gpu/drm/arc/arcpgu_crtc.c| 28 -- drivers/gpu/drm/drm_probe_helper.c | 50 ++-- include/drm/drm_modeset_helper_vtables.h | 26 + 3 files changed, 99 insertions(+), 5 deletions(-) -- 1.9.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
* Sebastian Reichel [170428 11:29]: > Hi, > > On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > > * Tomi Valkeinen [170428 04:15]: > > > On 14/04/17 13:25, Hans Verkuil wrote: > > > > From: Hans Verkuil > > > > > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > > > > > Change to PIN_INPUT so it can be used by the new CEC support. > > ... > > > > > Reviewed-by: Tomi Valkeinen > > > > > > Tony, can you queue this? It's safe to apply separately from the rest of > > > the HDMI CEC work. > > > > Sure will do. > > I guess the same patch should be applied to Droid 4? I guess it depends if there is an external pull or not. If there's an external pull, the internal pull needs to be disabled as otherwise the resistors are parallel and pull value is much lower than intended. Looks like on droid 4 we have: $ grep 09a /sys/kernel/debug/pinctrl/4a100040.pinmux/pins pin 45 (PIN45) 4a10009a 0118 pinctrl-single $ grep PULL_ENA ./include/dt-bindings/pinctrl/omap.h #define PULL_ENA(1 << 3) ... So bit 3 is set and internal pull is enabled in pinmux_dss_hdmi_pins for droid 4 also. The pull seems to be enabled in the Android kernel too: # rwmem -s16 0x4a10009a 0x4a10009a = 0x0118 So needs to be tested, what's the simplest test to check the CEC? Hmm I wonder if disabling the internal pull also allows removing the "regulator-always-on" hack for hdmi_regulator there? Without regulator-always-on I noticed that HDMI panel resolutions are not detected. This I can test easily.. Regards, Tony ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 1/8] arm: omap4: enable CEC pin for Pandaboard A4 and ES
Hi, On Fri, Apr 28, 2017 at 08:08:59AM -0700, Tony Lindgren wrote: > * Tomi Valkeinen [170428 04:15]: > > On 14/04/17 13:25, Hans Verkuil wrote: > > > From: Hans Verkuil > > > > > > The CEC pin was always pulled up, making it impossible to use it. > > > > > > Change to PIN_INPUT so it can be used by the new CEC support. > ... > > > Reviewed-by: Tomi Valkeinen > > > > Tony, can you queue this? It's safe to apply separately from the rest of > > the HDMI CEC work. > > Sure will do. I guess the same patch should be applied to Droid 4? -- Sebastian signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [pull] radeon and amdgpu drm-next-4.12
On 29/04/17 06:54 AM, Alex Deucher wrote: > Hi Dave, > > Fixes for 4.12. Mostly updates for vega10 which is new for > 4.12. Highlights: > - Lots of vega10 fixes > - fix interruptable wait mixup > - misc display fixes for radeon and amdgpu > - misc bug fixes [...] > Michel Dänzer (1): > drm/amdgpu: Make amdgpu_bo_reserve use uninterruptible waits for cleanup Maybe 'Revert "drm/amdgpu: Refactor flip into prepare submit and submit. (v2)"' can be picked up for 4.12 as well? It's not technically a fix, but it makes amdgpu_crtc_page_flip_target easier to grok again. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/fb/gf100-: Fix 32 bit wraparound in new ram detection
A missing u64 cast causes a 32-Bit wraparound from
4096 MiB to 0 MiB and therefore total 0 MiB VRAM detected
if card has 4096 Mib per FBP.
Signed-off-by: Mario Kleiner
---
drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
index 53c32fc..c639759 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgf100.c
@@ -589,7 +589,7 @@ gf100_ram_ctor(const struct nvkm_ram_func *func, struct
nvkm_fb *fb,
nvkm_debug(subdev, "FBP %d: %4d MiB, %d LTC(s)\n",
fbp, size, ltcs);
lcomm = min(lcomm, (u64)(size / ltcs) << 20);
- total += size << 20;
+ total += (u64) size << 20;
ltcn += ltcs;
} else {
nvkm_debug(subdev, "FBP %d: disabled\n", fbp);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: Proposal for RandR version 1.6, Leases [v2]
Keith Packard writes:
With the changes to the kernel interface, and discussion about how to
mask HMD outputs from X applications still ongoing, I've ripped the
grabs out of the protocol and will add whatever we come up with back at
some point.
In any case, there are just two requests now, CreateLease and
FreeLease. There are also events delivered when leases are created or
destroyed so a client can see when the lease holder dies. Leases are
named with XIDs so the client can tell lease has died. When the lease
creator frees a lease, the actual lease (may) stay around; you don't get
events on those as they no longer have an XID.
The kernel doesn't (yet) support a lessor terminating a lease; I think
that's something we'll probably want, so I added it to this protocol
as a point of discussion.
Oh, and all of the code is up and running, so this is more real than it
was a couple of weeks ago.
Here's the patch to the protocol and protocol headers. Once this looks
reasonable, I'll send out the xcb and X server patches to match.
From 882cf1f11f3b398b00cb09f49aa7d0714434354f Mon Sep 17 00:00:00 2001
From: Keith Packard
Date: Fri, 28 Apr 2017 22:32:44 -0700
Subject: [PATCH] Add Leases.
A "lease" is a set of crtc and output resources granted to another
application for use outside of X. These will not be usable through the
X protocol until the lease terminates. Leased outputs will be seen as
disconnected, leased CRTCs will be seen as not usable with any output.
Signed-off-by: Keith Packard
---
configure.ac | 2 +-
randr.h| 15 +++--
randrproto.h | 58 +++
randrproto.txt | 96 +++---
4 files changed, 162 insertions(+), 9 deletions(-)
diff --git a/configure.ac b/configure.ac
index 18197e3..4464e88 100644
--- a/configure.ac
+++ b/configure.ac
@@ -22,7 +22,7 @@ dnl
dnl Process this file with autoconf to create configure.
AC_PREREQ([2.60])
-AC_INIT([RandrProto], [1.5.0],
+AC_INIT([RandrProto], [1.6.0],
[https://bugs.freedesktop.org/enter_bug.cgi?product=xorg])
AM_INIT_AUTOMAKE([foreign dist-bzip2])
diff --git a/randr.h b/randr.h
index 6fcda87..e53cd56 100644
--- a/randr.h
+++ b/randr.h
@@ -40,11 +40,11 @@ typedef unsigned long XRandrModeFlags;
#define RANDR_NAME "RANDR"
#define RANDR_MAJOR 1
-#define RANDR_MINOR 5
+#define RANDR_MINOR 6
-#define RRNumberErrors 4
+#define RRNumberErrors 5
#define RRNumberEvents 2
-#define RRNumberRequests 45
+#define RRNumberRequests 47
#define X_RRQueryVersion 0
/* we skip 1 to make old clients fail pretty immediately */
@@ -109,6 +109,10 @@ typedef unsigned long XRandrModeFlags;
#define X_RRSetMonitor 43
#define X_RRDeleteMonitor 44
+/* v1.6 */
+#define X_RRCreateLease 45
+#define X_RRFreeLease 46
+
/* Event selection bits */
#define RRScreenChangeNotifyMask (1L << 0)
/* V1.2 additions */
@@ -119,6 +123,8 @@ typedef unsigned long XRandrModeFlags;
#define RRProviderChangeNotifyMask (1L << 4)
#define RRProviderPropertyNotifyMask (1L << 5)
#define RRResourceChangeNotifyMask (1L << 6)
+/* V1.6 additions */
+#define RRLeaseNotifyMask(1L << 7)
/* Event codes */
#define RRScreenChangeNotify 0
@@ -131,6 +137,8 @@ typedef unsigned long XRandrModeFlags;
#define RRNotify_ProviderChange3
#define RRNotify_ProviderProperty 4
#define RRNotify_ResourceChange5
+/* V1.6 additions */
+#define RRNotify_Lease 6
/* used in the rotation field; rotation and reflection in 0.1 proto. */
#define RR_Rotate_0 1
#define RR_Rotate_90 2
@@ -172,6 +180,7 @@ typedef unsigned long XRandrModeFlags;
#define BadRRCrtc 1
#define BadRRMode 2
#define BadRRProvider 3
+#define BadRRLease 4
/* Conventional RandR output properties */
diff --git a/randrproto.h b/randrproto.h
index 114a624..a0b04d3 100644
--- a/randrproto.h
+++ b/randrproto.h
@@ -51,6 +51,7 @@
#define RRProvider CARD32
#define RRModeFlags CARD32
#define Atom CARD32
+#define RRLease CARD32
#define Rotation CARD16
#define SizeID CARD16
@@ -837,6 +838,46 @@ typedef struct {
#define sz_xRRGetProviderPropertyReply 32
/*
+ * Additions for V1.6
+ */
+
+typedef struct {
+CARD8 reqType;
+CARD8 randrReqType;
+CARD16 length B16;
+Window window B32;
+RRLease lid B32;
+CARD16 nCrtcs B16;
+CARD16 nOutputs B16;
+} xRRCreateLeaseReq;
+#define sz_xRRCreateLeaseReq 16
+
+typedef struct {
+BYTE type;
+CARD8 nfd;
+CARD16 sequenceNumber B16;
+CARD32 length B32;
+CARD32 pad2 B32;
+CARD32 pad3 B32;
+CARD32 pad4 B32;
+CARD32 pad5 B32;
+CARD32 pad6 B32;
+CARD32 pad7 B32;
+} xRRCreateLeaseReply;
+#define sz_xRRCreateLeaseReply 32
+
+typedef struct {
+CARD8 reqType;
+CARD8 randrReqType;
+CARD16 length B16;
+RRLease lid B32;
+BYTE terminate;
+CARD8 pad1;
+CARD16 pad2 B16;
+} xRRFreeLeaseReq;
+#define sz_xRRFreeLeaseReq 12
+
+/*
* event
*/
[PATCH 3/5] drm: Add drm_object lease infrastructure [v2]
This provides new data structures to hold "lease" information about
drm mode setting objects, and provides for creating new drm_masters
which have access to a subset of the available drm resources.
An 'owner' is a drm_master which is not leasing the objects from
another drm_master, and hence 'owns' them.
A 'lessee' is a drm_master which is leasing objects from some other
drm_master. Each lessee holds the set of objects which it is leasing
from the lessor.
A 'lessor' is a drm_master which is leasing objects to another
drm_master. This is the same as the owner in the current code.
The set of objects any drm_master 'controls' is limited to the set of
objects it leases (for lessees) or all objects (for owners).
Objects not controlled by a drm_master cannot be modified through the
various state manipulating ioctls, and any state reported back to user
space will be edited to make them appear idle and/or unusable. For
instance, connectors always report 'disconnected', while encoders
report no possible crtcs or clones.
The full list of lessees leasing objects from an owner (either
directly, or indirectly through another lessee), can be searched from
an idr in the drm_master of the owner.
Changes for v2 as suggested by Daniel Vetter :
* Sub-leasing has been disabled.
* BUG_ON for lock checking replaced with lockdep_assert_held
* 'change' ioctl has been removed.
* Leased objects can always be controlled by the lessor; the
'mask_lease' flag has been removed
* Checking for leased status has been simplified, replacing
the drm_lease_check function with drm_lease_held.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/Makefile | 3 +-
drivers/gpu/drm/drm_auth.c| 22 ++-
drivers/gpu/drm/drm_lease.c | 313 ++
include/drm/drmP.h| 1 +
include/drm/drm_auth.h| 20 +++
include/drm/drm_lease.h | 34 +
include/drm/drm_mode_object.h | 1 +
7 files changed, 392 insertions(+), 2 deletions(-)
create mode 100644 drivers/gpu/drm/drm_lease.c
create mode 100644 include/drm/drm_lease.h
diff --git a/drivers/gpu/drm/Makefile b/drivers/gpu/drm/Makefile
index b9ae4280de9d..c2c6d61d30cf 100644
--- a/drivers/gpu/drm/Makefile
+++ b/drivers/gpu/drm/Makefile
@@ -16,7 +16,8 @@ drm-y :=drm_auth.o drm_bufs.o drm_cache.o \
drm_framebuffer.o drm_connector.o drm_blend.o \
drm_encoder.o drm_mode_object.o drm_property.o \
drm_plane.o drm_color_mgmt.o drm_print.o \
- drm_dumb_buffers.o drm_mode_config.o
+ drm_dumb_buffers.o drm_mode_config.o \
+ drm_lease.o
drm-$(CONFIG_COMPAT) += drm_ioc32.o
drm-$(CONFIG_DRM_GEM_CMA_HELPER) += drm_gem_cma_helper.o
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 6b143514a566..1db4f63860d1 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -31,6 +31,7 @@
#include
#include "drm_internal.h"
#include "drm_legacy.h"
+#include
/**
* DOC: master and authentication
@@ -93,7 +94,7 @@ int drm_authmagic(struct drm_device *dev, void *data,
return file ? 0 : -EINVAL;
}
-static struct drm_master *drm_master_create(struct drm_device *dev)
+struct drm_master *drm_master_create(struct drm_device *dev)
{
struct drm_master *master;
@@ -107,6 +108,14 @@ static struct drm_master *drm_master_create(struct
drm_device *dev)
idr_init(&master->magic_map);
master->dev = dev;
+ /* initialize the tree of output resource lessees */
+ master->lessor = NULL;
+ master->lessee_id = 0;
+ INIT_LIST_HEAD(&master->lessees);
+ INIT_LIST_HEAD(&master->lessee_list);
+ idr_init(&master->leases);
+ idr_init(&master->lessee_idr);
+
return master;
}
@@ -189,6 +198,12 @@ int drm_setmaster_ioctl(struct drm_device *dev, void *data,
goto out_unlock;
}
+ if (file_priv->master->lessor != NULL) {
+ DRM_DEBUG_LEASE("Attempt to set lessee %d as master\n",
file_priv->master->lessee_id);
+ ret = -EINVAL;
+ goto out_unlock;
+ }
+
ret = drm_set_master(dev, file_priv, false);
out_unlock:
mutex_unlock(&dev->master_mutex);
@@ -310,12 +325,17 @@ static void drm_master_destroy(struct kref *kref)
struct drm_master *master = container_of(kref, struct drm_master,
refcount);
struct drm_device *dev = master->dev;
+ drm_lease_destroy(master);
+
if (dev->driver->master_destroy)
dev->driver->master_destroy(dev, master);
drm_legacy_master_rmmaps(dev, master);
idr_destroy(&master->magic_map);
+
+ idr_destroy(&master->lessee_idr);
+
kfree(master->unique);
kfree(master);
}
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
new file mode 100644
index ..12828b8c0bff
--- /dev/null
+++ b/drivers/gpu/drm/drm_lease.
[PATCH 0/5] drm: Add mode resource leasing [v2]
Here's a second try at mode resource leasing. The differences from v1 are mostly deleting functionality that isn't currently useful. There are no more sub-leases; there's the owner, the owner is the only lessor and so the only one who can create leases and hand those out. The lessor can now manipulate all of the resources without restriction. It's up to user space to enforce whatever access control it wants. The lessee can no longer see any resources other than those in the lease. This was a bit tricky as there are various indices into the reported arrays of objects in the form of masks. The query ioctls no longer take lessor or lessee ids; you can query the leases you have granted or query the list of resources in your own lease. The X server uses the former to figure out when lessees close their DRM file and terminate a lease. As I write this, I'm wondering if that latter operation is actually useful though. If not, we can rip that ioctl out easily enough. As suggested by Daniel Vetter, the first patch changes the API to __drm_mode_object_find to include a relevant struct drm_file * pointer so that function can perform any necessary per-file access control. When there isn't a suitable pointer, NULL is passed instead, which is a proxy for the origin DRM master. For leases, this means that no lease permissions checking is done. This is why there are now 5 patches instead of the original 4. Thanks again to everyone who commented on the mailing list or on IRC; I'm pretty happy with the current functionality; I've got kmscube leasing resources from the X server this evening. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 5/5] drm: Add three ioctls for managing drm mode object leases [v2]
drm_mode_create_lease
Creates a lease for a list of drm mode objects, returning an
fd for the new drm_master and a 64-bit identifier for the lessee
drm_mode_list_lesees
List the identifiers of the lessees for a master file
drm_mode_get_lease
List the leased objects for a master file
This should suffice to at least create and query leases.
Changes for v2 as suggested by Daniel Vetter :
* query ioctls only query the master associated with
the provided file.
* 'mask_lease' value has been removed
* change ioctl has been removed.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_ioctl.c | 3 +
drivers/gpu/drm/drm_lease.c | 220
include/drm/drm_lease.h | 9 ++
include/uapi/drm/drm.h | 3 +
include/uapi/drm/drm_mode.h | 55 +++
5 files changed, 290 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index fed22c2b98b6..5189a32ac3e0 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -636,6 +636,9 @@ static const struct drm_ioctl_desc drm_ioctls[] = {
DRM_IOCTL_DEF(DRM_IOCTL_MODE_ATOMIC, drm_mode_atomic_ioctl,
DRM_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATEPROPBLOB, drm_mode_createblob_ioctl,
DRM_CONTROL_ALLOW|DRM_UNLOCKED),
DRM_IOCTL_DEF(DRM_IOCTL_MODE_DESTROYPROPBLOB,
drm_mode_destroyblob_ioctl, DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_CREATE_LEASE, drm_mode_create_lease_ioctl,
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_LIST_LESSEES, drm_mode_list_lessees_ioctl,
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
+ DRM_IOCTL_DEF(DRM_IOCTL_MODE_GET_LEASE, drm_mode_get_lease_ioctl,
DRM_ANY_MASTER|DRM_CONTROL_ALLOW|DRM_UNLOCKED),
};
#define DRM_CORE_IOCTL_COUNT ARRAY_SIZE( drm_ioctls )
diff --git a/drivers/gpu/drm/drm_lease.c b/drivers/gpu/drm/drm_lease.c
index 12828b8c0bff..20a7b869824e 100644
--- a/drivers/gpu/drm/drm_lease.c
+++ b/drivers/gpu/drm/drm_lease.c
@@ -311,3 +311,223 @@ void drm_lease_destroy(struct drm_master *master)
DRM_DEBUG_LEASE("drm_lease_destroy done %d\n", master->lessee_id);
}
+
+/**
+ * drm_mode_create_lease_ioctl - create a new lease
+ * @dev: the drm device
+ * @data: pointer to struct drm_mode_create_lease
+ * @file_priv: the file being manipulated
+ *
+ * The master associated with the specified file will have a lease
+ * created containing the objects specified in the ioctl structure.
+ * A file descriptor will be allocated for that and returned to the
+ * application.
+ */
+int drm_mode_create_lease_ioctl(struct drm_device *dev,
+ void *data, struct drm_file *lessor_priv)
+{
+ struct drm_mode_create_lease *cl = data;
+ size_t object_count;
+ size_t o;
+ int ret = 0;
+ struct idr leases;
+ struct drm_master *lessor = lessor_priv->master;
+ struct drm_master *lessee = NULL;
+ struct file *lessee_file = NULL;
+ struct file *lessor_file = lessor_priv->filp;
+ struct drm_file *lessee_priv;
+ int fd = -1;
+
+ /* Do not allow sub-leases */
+ if (lessor->lessor)
+ return -EINVAL;
+
+ object_count = cl->object_count;
+ idr_init(&leases);
+
+ /* Allocate a file descriptor for the lease */
+ fd = get_unused_fd_flags(cl->flags & (O_CLOEXEC | O_NONBLOCK));
+
+ DRM_DEBUG_LEASE("Creating new lease\n");
+
+ /* Lookup the mode objects and add their IDs to the lease request */
+ for (o = 0; o < object_count; o++) {
+ __u32 object_id;
+
+ if (copy_from_user(&object_id,
+ u64_to_user_ptr(cl->object_ids) + o * sizeof
(__u32),
+ sizeof (__u32))) {
+ ret = -EFAULT;
+ goto out_leases;
+ }
+ DRM_DEBUG_LEASE("Adding object %d to lease\n", object_id);
+
+ ret = idr_alloc(&leases, (void *) 1, object_id, object_id + 1,
GFP_KERNEL);
+ if (ret < 0) {
+ DRM_DEBUG_LEASE("Object %d cannot be inserted into
leases (%d)\n",
+ object_id, ret);
+ goto out_leases;
+ }
+ }
+
+ mutex_lock(&dev->master_mutex);
+
+ DRM_DEBUG_LEASE("Creating lease\n");
+ lessee = drm_lease_create(lessor, &leases);
+
+ if (IS_ERR(lessee)) {
+ ret = PTR_ERR(lessee);
+ mutex_unlock(&dev->master_mutex);
+ goto out_leases;
+ }
+
+ /* Clone the lessor file to create a new file for us */
+ DRM_DEBUG_LEASE("Allocating lease file\n");
+ path_get(&lessor_file->f_path);
+ lessee_file = alloc_file(&lessor_file->f_path,
+lessor_file->f_mode,
+
[PATCH 1/5] drm: Pass struct drm_file * to __drm_mode_object_find
This will allow __drm_mode_object_file to be extended to perform
access control checks based on the file in use.
Suggested-by: Daniel Vetter
Signed-off-by: Keith Packard
---
drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c | 16
drivers/gpu/drm/amd/amdgpu/dce_virtual.c | 4 ++--
drivers/gpu/drm/ast/ast_mode.c | 2 +-
drivers/gpu/drm/bochs/bochs_kms.c| 2 +-
drivers/gpu/drm/cirrus/cirrus_mode.c | 2 +-
drivers/gpu/drm/drm_atomic.c | 8
drivers/gpu/drm/drm_atomic_helper.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_crtc.c | 8
drivers/gpu/drm/drm_crtc_internal.h | 1 +
drivers/gpu/drm/drm_encoder.c| 2 +-
drivers/gpu/drm/drm_framebuffer.c| 9 +
drivers/gpu/drm/drm_mode_object.c| 10 ++
drivers/gpu/drm/drm_plane.c | 14 +++---
drivers/gpu/drm/drm_property.c | 6 +++---
drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_vdac.c | 2 +-
drivers/gpu/drm/i915/intel_display.c | 2 +-
drivers/gpu/drm/i915/intel_overlay.c | 2 +-
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
drivers/gpu/drm/mgag200/mgag200_mode.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_connector.c | 4 ++--
drivers/gpu/drm/radeon/r100.c| 2 +-
drivers/gpu/drm/radeon/r600_cs.c | 2 +-
drivers/gpu/drm/radeon/radeon_connectors.c | 16
drivers/gpu/drm/udl/udl_connector.c | 2 +-
drivers/gpu/drm/vmwgfx/vmwgfx_ioctl.c| 4 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 2 +-
include/drm/drm_connector.h | 3 ++-
include/drm/drm_crtc.h | 5 +++--
include/drm/drm_encoder.h| 3 ++-
include/drm/drm_framebuffer.h| 1 +
include/drm/drm_mode_object.h| 2 ++
include/drm/drm_plane.h | 3 ++-
include/drm/drm_property.h | 3 ++-
35 files changed, 83 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
index 8d1cf2d3e663..a6c17353e57d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_connectors.c
@@ -231,7 +231,7 @@ amdgpu_connector_update_scratch_regs(struct drm_connector
*connector,
if (connector->encoder_ids[i] == 0)
break;
- encoder = drm_encoder_find(connector->dev,
+ encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -256,7 +256,7 @@ amdgpu_connector_find_encoder(struct drm_connector
*connector,
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
if (connector->encoder_ids[i] == 0)
break;
- encoder = drm_encoder_find(connector->dev,
+ encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -374,7 +374,7 @@ amdgpu_connector_best_single_encoder(struct drm_connector
*connector)
/* pick the encoder ids */
if (enc_id)
- return drm_encoder_find(connector->dev, enc_id);
+ return drm_encoder_find(connector->dev, NULL, enc_id);
return NULL;
}
@@ -1079,7 +1079,7 @@ amdgpu_connector_dvi_detect(struct drm_connector
*connector, bool force)
if (connector->encoder_ids[i] == 0)
break;
- encoder = drm_encoder_find(connector->dev,
connector->encoder_ids[i]);
+ encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -1136,7 +1136,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
if (connector->encoder_ids[i] == 0)
break;
- encoder = drm_encoder_find(connector->dev,
connector->encoder_ids[i]);
+ encoder = drm_encoder_find(connector->dev, NULL,
connector->encoder_ids[i]);
if (!encoder)
continue;
@@ -1155,7 +1155,7 @@ amdgpu_connector_dvi_encoder(struct drm_connector
*connector)
/* then check use digitial */
/* pick the first one */
if (enc_id)
- return drm_encoder_find(connector->dev, enc_id);
+ return drm_encoder_find
[PATCH 4/5] drm: Check mode object lease status in all master ioctl paths [v2]
Attempts to modify un-leased objects are rejected with an error.
Information returned about unleased objects is modified to make them
appear unusable and/or disconnected.
Changes for v2 as suggested by Daniel Vetter :
With the change in the __drm_mode_object_find API to pass the
file_priv along, we can now centralize most of the lease-based access
checks in that function.
A few places skip that API and require in-line checks.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_auth.c| 2 +-
drivers/gpu/drm/drm_connector.c | 8 +++---
drivers/gpu/drm/drm_encoder.c | 8 +++---
drivers/gpu/drm/drm_mode_config.c | 52 ---
drivers/gpu/drm/drm_mode_object.c | 22 +
drivers/gpu/drm/drm_plane.c | 6 +++--
6 files changed, 69 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_auth.c b/drivers/gpu/drm/drm_auth.c
index 1db4f63860d1..44c99d12f4c1 100644
--- a/drivers/gpu/drm/drm_auth.c
+++ b/drivers/gpu/drm/drm_auth.c
@@ -303,7 +303,7 @@ void drm_master_release(struct drm_file *file_priv)
*/
bool drm_is_current_master(struct drm_file *fpriv)
{
- return fpriv->is_master && fpriv->master == fpriv->minor->dev->master;
+ return fpriv->is_master && drm_lease_owner(fpriv->master) ==
fpriv->minor->dev->master;
}
EXPORT_SYMBOL(drm_is_current_master);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 670c20d5660c..dbf34f08363b 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1094,7 +1094,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
}
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++)
- if (connector->encoder_ids[i] != 0)
+ if (connector->encoder_ids[i] != 0 &&
+ drm_lease_held(file_priv, connector->encoder_ids[i]))
encoders_count++;
if (out_resp->count_modes == 0) {
@@ -1118,7 +1119,7 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
encoder = drm_connector_get_encoder(connector);
- if (encoder)
+ if (encoder && drm_lease_held(file_priv, encoder->base.id))
out_resp->encoder_id = encoder->base.id;
else
out_resp->encoder_id = 0;
@@ -1156,7 +1157,8 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
copied = 0;
encoder_ptr = (uint32_t __user *)(unsigned
long)(out_resp->encoders_ptr);
for (i = 0; i < DRM_CONNECTOR_MAX_ENCODER; i++) {
- if (connector->encoder_ids[i] != 0) {
+ if (connector->encoder_ids[i] != 0 &&
+ drm_lease_held(file_priv,
connector->encoder_ids[i])) {
if (put_user(connector->encoder_ids[i],
encoder_ptr + copied)) {
ret = -EFAULT;
diff --git a/drivers/gpu/drm/drm_encoder.c b/drivers/gpu/drm/drm_encoder.c
index dbaedd4e12e6..512d0b6cb7d2 100644
--- a/drivers/gpu/drm/drm_encoder.c
+++ b/drivers/gpu/drm/drm_encoder.c
@@ -211,7 +211,7 @@ int drm_mode_getencoder(struct drm_device *dev, void *data,
drm_modeset_lock(&dev->mode_config.connection_mutex, NULL);
crtc = drm_encoder_get_crtc(encoder);
- if (crtc)
+ if (crtc && drm_lease_held(file_priv, crtc->base.id))
enc_resp->crtc_id = crtc->base.id;
else
enc_resp->crtc_id = 0;
@@ -219,8 +219,10 @@ int drm_mode_getencoder(struct drm_device *dev, void *data,
enc_resp->encoder_type = encoder->encoder_type;
enc_resp->encoder_id = encoder->base.id;
- enc_resp->possible_crtcs = encoder->possible_crtcs;
- enc_resp->possible_clones = encoder->possible_clones;
+ enc_resp->possible_crtcs = drm_lease_filter_crtcs(file_priv,
+
encoder->possible_crtcs);
+ enc_resp->possible_clones = drm_lease_filter_encoders(file_priv,
+
encoder->possible_clones);
return 0;
}
diff --git a/drivers/gpu/drm/drm_mode_config.c
b/drivers/gpu/drm/drm_mode_config.c
index 2735a5847ffa..bb6b64e594b7 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -131,14 +131,20 @@ int drm_mode_getresources(struct drm_device *dev, void
*data,
/* mode_config.mutex protects the connector list against e.g. DP MST
* connector hot-adding. CRTC/Plane lists are invariant. */
mutex_lock(&dev->mode_config.mutex);
- drm_for_each_crtc(crtc, dev)
- crtc_count++;
+ drm_for_each_crtc(crtc, dev) {
+ if (drm_lease_held(file_priv, crtc->base.id))
+ crtc_count++;
+ }
- drm_for
[PATCH 2/5] drm: Add new LEASE debug level
Separate out lease debugging from the core.
Signed-off-by: Keith Packard
---
drivers/gpu/drm/drm_drv.c | 3 ++-
include/drm/drmP.h| 4
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index 6594b4088f11..d4a3612655e3 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -57,7 +57,8 @@ MODULE_PARM_DESC(debug, "Enable debug output, where each bit
enables a debug cat
"\t\tBit 2 (0x04) will enable KMS messages (modesetting code)\n"
"\t\tBit 3 (0x08) will enable PRIME messages (prime code)\n"
"\t\tBit 4 (0x10) will enable ATOMIC messages (atomic code)\n"
-"\t\tBit 5 (0x20) will enable VBL messages (vblank code)");
+"\t\tBit 5 (0x20) will enable VBL messages (vblank code)\n"
+"\t\tBit 7 (0x80) will enable LEASE messages (leasing code)");
module_param_named(debug, drm_debug, int, 0600);
static DEFINE_SPINLOCK(drm_minor_lock);
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index 9c4ee144b5f6..304a22c87999 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -137,6 +137,7 @@ struct dma_buf_attachment;
#define DRM_UT_ATOMIC 0x10
#define DRM_UT_VBL 0x20
#define DRM_UT_STATE 0x40
+#define DRM_UT_LEASE 0x80
/***/
/** \name DRM template customization defaults */
@@ -251,6 +252,9 @@ struct dma_buf_attachment;
#define DRM_DEBUG_VBL(fmt, ...)\
drm_printk(KERN_DEBUG, DRM_UT_VBL, fmt, ##__VA_ARGS__)
+#define DRM_DEBUG_LEASE(fmt, ...) \
+ drm_printk(KERN_DEBUG, DRM_UT_LEASE, fmt, ##__VA_ARGS__)
+
#define _DRM_DEV_DEFINE_DEBUG_RATELIMITED(dev, level, fmt, args...)\
({ \
static DEFINE_RATELIMIT_STATE(_rs, \
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
