[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #16 from Mike Lothian --- Weird it was only showing i915 resumes no amdgpu ones - even though dmesg clearly shows the card powering up -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #2 from SET --- Created attachment 141623 --> https://bugs.freedesktop.org/attachment.cgi?id=141623&action=edit Xorg log -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #3 from SET --- Created attachment 141624 --> https://bugs.freedesktop.org/attachment.cgi?id=141624&action=edit dmesg after reboot -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] [RFC]drm: add syncobj timeline support v5
Am 17.09.2018 um 11:33 schrieb zhoucm1:
[SNIP]
+static struct dma_fence *
+drm_syncobj_point_get(struct drm_syncobj *syncobj, u64 point, u64
flags)
+{
+ struct dma_fence *fence;
+ int ret = 0;
+
+ if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
+ ret = wait_event_timeout(syncobj->syncobj_timeline.wq,
+ point <= syncobj->syncobj_timeline.signal_point,
+ msecs_to_jiffies(1)); /* wait 10s */
Either don't use a timeout or provide the timeout explicitely, but
don't hard code it here.
Additional to that we probably need an incorruptible wait.
Initially, I used interruptible wait, I found it sometimes often
return -ERESTARTSYS without waiting any second when I wrote unit test.
Any ideas for that?
Yeah, that is perfectly normal. The application just received a signal
and we need to abort the IOCTL ASAP.
still need to interruptible wait?
Yes, that should certainly be an interruptible wait.
Otherwise an application could block on this forever when somebody
forgets to supply a signal point.
- for (i = 0; i < args->count_handles; i++)
- drm_syncobj_replace_fence(syncobjs[i], 0, NULL);
-
+ for (i = 0; i < args->count_handles; i++) {
+ if (syncobjs[i]->type == DRM_SYNCOBJ_TYPE_TIMELINE) {
+ DRM_ERROR("timeline syncobj cannot reset!\n");
Why not? I mean that should still work or do I miss anything?
timeline semaphore spec doesn't require reset interface, it says the
timeline value only can be changed by signal operations.
Yeah, but we don't care about the timeline spec in the kernel.
Question is rather if that still makes sense to support that and as far
as I can see it should be trivial to reinitialize the object.
+ ret = -EINVAL;
+ goto out;
+ }
+ drm_syncobj_timeline_fini(syncobjs[i],
+ &syncobjs[i]->syncobj_timeline);
+ drm_syncobj_timeline_init(syncobjs[i],
+ &syncobjs[i]->syncobj_timeline);
+ }
+out:
drm_syncobj_array_free(syncobjs, args->count_handles);
- return 0;
+ return ret;
}
int
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index 0a8d2d64f380..579e91a5858b 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -2137,7 +2137,9 @@ await_fence_array(struct i915_execbuffer *eb,
if (!(flags & I915_EXEC_FENCE_WAIT))
continue;
- fence = drm_syncobj_fence_get(syncobj);
+ drm_syncobj_search_fence(syncobj, 0,
+ DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT,
Not sure if we can make DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT the
default here.
Maybe better if drivers explicitly need to ask for it?
if you don't like the flag used in specific driver, I can wrap it to a
new function.
Yeah, that is probably a good idea.
+ &fence);
if (!fence)
return -EINVAL;
diff --git a/include/drm/drm_syncobj.h b/include/drm/drm_syncobj.h
index 425432b85a87..9535521e6623 100644
--- a/include/drm/drm_syncobj.h
+++ b/include/drm/drm_syncobj.h
@@ -30,6 +30,25 @@
struct drm_syncobj_cb;
+enum drm_syncobj_type {
+ DRM_SYNCOBJ_TYPE_NORMAL,
Does anybody have a better suggestion for _TYPE_NORMAL? That sounds
like timeline would be special.
How about _TYPE_INDIVIDUAL?
Oh, really good idea.
btw: I encounter a problem after removing advanced wait pt, I debug it
two days, but still don't find reason, from log, it's timeount when
wait_event_timeout, that means it don't receive signal operation.
Good question. Maybe a race condition? Have you tried to trace both
threads to the trace buffer, e.g. use trace_printk?
"./deqp-vk -n dEQP-VK*semaphore*" will fail on
'dEQP-VK.synchronization.basic.semaphore.chain' case, but can pass if
only run that one case like "./deqp-vk -n
dEQP-VK.synchronization.basic.semaphore.chain".
Both old and my previous implementation can pass and have no this
problem.
Can you reproduce that as well with the unit tests in libdrm?
Christian.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #4 from SET --- Created attachment 141625 --> https://bugs.freedesktop.org/attachment.cgi?id=141625&action=edit kernel log during problems -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #5 from SET --- Please see attachments. -- 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: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
Quoting José Roberto de Souza (2018-09-17 22:22:44)
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> Cc: Chris Wilson
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_ioctl.c | 3 +++
> drivers/gpu/drm/i915/i915_perf.c | 2 +-
> 2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 60dfbfae6a02..c0de628c194c 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -306,6 +306,9 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> struct drm_set_client_cap *req = data;
>
I liked Daniel's comment suggestion.
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EOPNOTSUPP;
> +
> switch (req->capability) {
> case DRM_CLIENT_CAP_STEREO_3D:
> if (req->value > 1)
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index 664b96bb65a3..c1edd1e69a3e 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2817,7 +2817,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void
> *data,
>
> if (!dev_priv->perf.initialized) {
> DRM_DEBUG("i915 perf interface not available for this
> system\n");
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
Better served as a separate patch, so it can be applied to different
trees.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm: fix drm_drv_uses_atomic_modeset on non modesetting drivers.
On Tue, Sep 18, 2018 at 04:20:18PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> vgem seems to oops on the intel CI due to the vgem debugfs init
> hitting this path now.
>
> Check if we have mode_config funcs before checking one.
>
> Signed-off-by: Dave Airlie
I thought Dave would apply, but I guess too late for him, and since CI is
burning I went ahead and pushed to drm-misc-fixes.
I kinda wonder why we didn't blow up on vgem earlier. I guess not a whole
lot of fuzzing going on ...
-Daniel
> ---
> include/drm/drm_drv.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 8830e3de3a86..3199ef70c007 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -674,7 +674,7 @@ static inline bool drm_core_check_feature(struct
> drm_device *dev, u32 feature)
> static inline bool drm_drv_uses_atomic_modeset(struct drm_device *dev)
> {
> return drm_core_check_feature(dev, DRIVER_ATOMIC) ||
> - dev->mode_config.funcs->atomic_commit != NULL;
> + (dev->mode_config.funcs &&
> dev->mode_config.funcs->atomic_commit != NULL);
> }
>
>
> --
> 2.17.1
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107891] [wine, regression, bisected] RAGE, Wolfenstein The New Order hangs in menu
https://bugs.freedesktop.org/show_bug.cgi?id=107891 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Timothy Arceri --- Should be fixed by: commit 7a992fcfa059b0db0f07bc3eb38050eaab7aaf34 Author: Timothy Arceri Date: Wed Sep 12 20:50:34 2018 +1000 Revert "radeonsi: avoid syncing the driver thread in si_fence_finish" This reverts commit bc65dcab3bc48673ff6180afb036561a4b8b1119. This was manually reverted. Reverting stops the menu hanging in some id tech games such as RAGE and Wolfenstein The New Order. Reviewed-by: Marek Olšák Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107891 Thanks again for the bug report. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #17 from Mike Lothian --- Created attachment 141631 --> https://bugs.freedesktop.org/attachment.cgi?id=141631&action=edit pref report --header -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #18 from Mike Lothian --- Created attachment 141632 --> https://bugs.freedesktop.org/attachment.cgi?id=141632&action=edit Perf data So the --header didn't show anything, however the raw data does seem to do something amdgpu releated -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 Michel Dänzer changed: What|Removed |Added Attachment #141623|text/x-log |text/plain mime type|| -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 Michel Dänzer changed: What|Removed |Added Attachment #141625|text/x-log |text/plain mime type|| -- 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 107693] [wine] Wolfenstein: The Old Blood - can't find GL_EXT_framebuffer_object
https://bugs.freedesktop.org/show_bug.cgi?id=107693 Timothy Arceri changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Timothy Arceri --- Should be fixed by: commit 64ec50d52fa691cc1712df1d7eebea90552b7c2e Author: Timothy Arceri Date: Wed Sep 12 10:52:06 2018 +1000 mesa/st: add force_compat_profile option to driconfig Reviewed-by: Marek Olšák and commit 024abd3534a171ae4ee1532a078f3af68eb6fdea (HEAD -> master) Author: Timothy Arceri Date: Wed Sep 12 10:52:07 2018 +1000 util: use force_compat_profile for Wolfenstein The Old Blood This game is looking for some odd extension after creating a core context such as ARB_vertex_program and EXT_framebuffer_object. Rather then enabling these in core this forces the game to use compat. This allows the game to run and seems to work without issues. All other id tech games/engines use a compat profile. Reviewed-by: Marek Olšák As for the green screen that is a bug with wine staging. Proton and older versions of wine staging were fine. See: https://bugs.winehq.org/show_bug.cgi?id=45826 -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #6 from Michel Dänzer --- Does updating xf86-video-ati to 18.1.0 or using EXA instead of glamor help by any chance? Your system is affected by bug 105381. -- 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 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Mike Lothian changed: What|Removed |Added Attachment #141632|0 |1 is obsolete|| --- Comment #19 from Mike Lothian --- Created attachment 141633 --> https://bugs.freedesktop.org/attachment.cgi?id=141633&action=edit Report of amdgpu:* I've repeated but using -e amdgpu:* -- 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 02/16] dt-bindings: display: renesas: lvds: Document r8a77990 bindings
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > The E3 (r8a77990) supports two LVDS channels. Extend the binding to > support them. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt | 1 + > 1 file changed, 1 insertion(+) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > index 5a4e379bb414..13af7e2ac7e8 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > @@ -15,6 +15,7 @@ Required properties: >- "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders >- "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders >- "renesas,r8a77980-lvds" for R8A77980 (R-Car V3H) compatible LVDS encoders > + - "renesas,r8a77990-lvds" for R8A77990 (R-Car E3) compatible LVDS encoders >- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders > > - reg: Base address and length for the memory-mapped registers Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 2/5] drm/mxsfb: Fix initial corrupt frame when activating display
LCDIF will repeatedly display data from CUR_BUF and set CUR_BUF to
NEXT_BUF when done. Since we are only ever writing to NEXT_BUF the
display will show an initial corrupt frame.
Fix by writing the FB paddr to both CUR_BUF and NEXT_BUF when
activating the CRTC.
Signed-off-by: Leonard Crestez
Tested-by: Philipp Zabel
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 45 +-
1 file changed, 32 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index e4fcbb65b969..24b1f0c1432e 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -191,10 +191,25 @@ static int mxsfb_reset_block(void __iomem *reset_addr)
return ret;
return clear_poll_bit(reset_addr, MODULE_CLKGATE);
}
+static dma_addr_t mxsfb_get_fb_paddr(struct mxsfb_drm_private *mxsfb)
+{
+ struct drm_framebuffer *fb = mxsfb->pipe.plane.state->fb;
+ struct drm_gem_cma_object *gem;
+
+ if (!fb)
+ return 0;
+
+ gem = drm_fb_cma_get_gem_obj(fb, 0);
+ if (!gem)
+ return 0;
+
+ return gem->paddr;
+}
+
static void mxsfb_crtc_mode_set_nofb(struct mxsfb_drm_private *mxsfb)
{
struct drm_display_mode *m = &mxsfb->pipe.crtc.state->adjusted_mode;
const u32 bus_flags = mxsfb->connector.display_info.bus_flags;
u32 vdctrl0, vsync_pulse_len, hsync_pulse_len;
@@ -267,12 +282,22 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
mxsfb->base + LCDC_VDCTRL4);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ dma_addr_t paddr;
+
mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
+
+ /* Write cur_buf as well to avoid an initial corrupt frame */
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ writel(paddr, mxsfb->base + mxsfb->devdata->cur_buf);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ }
+
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
@@ -283,16 +308,12 @@ void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
struct drm_simple_display_pipe *pipe = &mxsfb->pipe;
struct drm_crtc *crtc = &pipe->crtc;
- struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_pending_vblank_event *event;
- struct drm_gem_cma_object *gem;
-
- if (!crtc)
- return;
+ dma_addr_t paddr;
spin_lock_irq(&crtc->dev->event_lock);
event = crtc->state->event;
if (event) {
crtc->state->event = NULL;
@@ -303,14 +324,12 @@ void mxsfb_plane_atomic_update(struct mxsfb_drm_private
*mxsfb,
drm_crtc_send_vblank_event(crtc, event);
}
}
spin_unlock_irq(&crtc->dev->event_lock);
- if (!fb)
- return;
-
- gem = drm_fb_cma_get_gem_obj(fb, 0);
-
- mxsfb_enable_axi_clk(mxsfb);
- writel(gem->paddr, mxsfb->base + mxsfb->devdata->next_buf);
- mxsfb_disable_axi_clk(mxsfb);
+ paddr = mxsfb_get_fb_paddr(mxsfb);
+ if (paddr) {
+ mxsfb_enable_axi_clk(mxsfb);
+ writel(paddr, mxsfb->base + mxsfb->devdata->next_buf);
+ mxsfb_disable_axi_clk(mxsfb);
+ }
}
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 11/24] powerpc/mm: don't use _PAGE_EXEC for calling hash_preload()
Christophe Leroy writes:
> The 'access' parameter of hash_preload() is either 0 or _PAGE_EXEC.
> Among the two versions of hash_preload(), only the PPC64 one is
> doing something with this 'access' parameter.
>
> In order to remove the use of _PAGE_EXEC outside platform code,
> 'access' parameter is replaced by 'is_exec' which will be either
> true of false, and the PPC64 version of hash_preload() creates
> the access flag based on 'is_exec'.
>
Reviewed-by: Aneesh Kumar K.V
> Signed-off-by: Christophe Leroy
> ---
> arch/powerpc/mm/hash_utils_64.c | 3 ++-
> arch/powerpc/mm/mem.c | 9 +
> arch/powerpc/mm/mmu_decl.h | 2 +-
> arch/powerpc/mm/pgtable_32.c| 2 +-
> arch/powerpc/mm/ppc_mmu_32.c| 2 +-
> 5 files changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/arch/powerpc/mm/hash_utils_64.c b/arch/powerpc/mm/hash_utils_64.c
> index f23a89d8e4ce..b8ce0e8cc608 100644
> --- a/arch/powerpc/mm/hash_utils_64.c
> +++ b/arch/powerpc/mm/hash_utils_64.c
> @@ -1482,7 +1482,7 @@ static bool should_hash_preload(struct mm_struct *mm,
> unsigned long ea)
> #endif
>
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> int hugepage_shift;
> unsigned long vsid;
> @@ -1490,6 +1490,7 @@ void hash_preload(struct mm_struct *mm, unsigned long
> ea,
> pte_t *ptep;
> unsigned long flags;
> int rc, ssize, update_flags = 0;
> + unsigned long access = _PAGE_PRESENT | _PAGE_READ | (is_exec ?
> _PAGE_EXEC : 0);
>
> BUG_ON(REGION_ID(ea) != USER_REGION_ID);
>
> diff --git a/arch/powerpc/mm/mem.c b/arch/powerpc/mm/mem.c
> index 31bd9b53c358..0ba0cdb3f759 100644
> --- a/arch/powerpc/mm/mem.c
> +++ b/arch/powerpc/mm/mem.c
> @@ -507,7 +507,8 @@ void update_mmu_cache(struct vm_area_struct *vma,
> unsigned long address,
>* We don't need to worry about _PAGE_PRESENT here because we are
>* called with either mm->page_table_lock held or ptl lock held
>*/
> - unsigned long access, trap;
> + unsigned long trap;
> + bool is_exec;
>
> if (radix_enabled()) {
> prefetch((void *)address);
> @@ -529,16 +530,16 @@ void update_mmu_cache(struct vm_area_struct *vma,
> unsigned long address,
> trap = current->thread.regs ? TRAP(current->thread.regs) : 0UL;
> switch (trap) {
> case 0x300:
> - access = 0UL;
> + is_exec = false;
> break;
> case 0x400:
> - access = _PAGE_EXEC;
> + is_exec = true;
> break;
> default:
> return;
> }
>
> - hash_preload(vma->vm_mm, address, access, trap);
> + hash_preload(vma->vm_mm, address, is_exec, trap);
> #endif /* CONFIG_PPC_STD_MMU */
> #if (defined(CONFIG_PPC_BOOK3E_64) || defined(CONFIG_PPC_FSL_BOOK3E)) \
> && defined(CONFIG_HUGETLB_PAGE)
> diff --git a/arch/powerpc/mm/mmu_decl.h b/arch/powerpc/mm/mmu_decl.h
> index e5d779eed181..dd7f9b951d25 100644
> --- a/arch/powerpc/mm/mmu_decl.h
> +++ b/arch/powerpc/mm/mmu_decl.h
> @@ -82,7 +82,7 @@ static inline void _tlbivax_bcast(unsigned long address,
> unsigned int pid,
> #else /* CONFIG_PPC_MMU_NOHASH */
>
> extern void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap);
> + bool is_exec, unsigned long trap);
>
>
> extern void _tlbie(unsigned long address);
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> index 0bbc7b7d8a05..01f348938328 100644
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -261,7 +261,7 @@ static void __init __mapin_ram_chunk(unsigned long
> offset, unsigned long top)
> map_kernel_page(v, p, ktext ? PAGE_KERNEL_TEXT : PAGE_KERNEL);
> #ifdef CONFIG_PPC_STD_MMU_32
> if (ktext)
> - hash_preload(&init_mm, v, 0, 0x300);
> + hash_preload(&init_mm, v, false, 0x300);
> #endif
> v += PAGE_SIZE;
> p += PAGE_SIZE;
> diff --git a/arch/powerpc/mm/ppc_mmu_32.c b/arch/powerpc/mm/ppc_mmu_32.c
> index bea6c544e38f..38a793bfca37 100644
> --- a/arch/powerpc/mm/ppc_mmu_32.c
> +++ b/arch/powerpc/mm/ppc_mmu_32.c
> @@ -163,7 +163,7 @@ void __init setbat(int index, unsigned long virt,
> phys_addr_t phys,
> * Preload a translation in the hash table
> */
> void hash_preload(struct mm_struct *mm, unsigned long ea,
> - unsigned long access, unsigned long trap)
> + bool is_exec, unsigned long trap)
> {
> pmd_t *pmd;
>
> --
> 2.13.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
On Mon, 2018-09-17 at 15:16 -0400, Sean Paul wrote: > On Mon, Sep 17, 2018 at 04:42:10PM +0300, Leonard Crestez wrote: > > Adding lcdif nodes to a power domain currently doesn't work, it results > > in black/corrupted screens or hangs. While the driver does enable > > runtime pm it does not deal correctly with the block being unpowered. > > > > This series stalled so I reached out to Marek on IRC and he was > > surprised to be listed as maintainer > > Hopefully not too surprised since Marek added themself to MAINTAINERS when > adding the driver :-) > > I suppose we should probably move this to drm-misc since it qualifies as a > "small driver" and needs a home. Looking through git history shows the last > mxsfb-specific change was back in 02/17. Everything else has been drm-wide > refactors. Thoughts? > > Marek/Leonard: Care to sign up to be listed as a reviewers? Since my knowledge of drm is very basic: no thanks. Since this is an imx driver it would make a lot of sense to group this together with the rest of drm/imx somehow. -- Regards, Leonard ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Mon, Sep 17, 2018 at 11:38:43AM +0300, Laurent Pinchart wrote:
> Hi Simon,
>
> On Monday, 17 September 2018 10:50:55 EEST Simon Horman wrote:
> > On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > > supporting VSP and FCP.
> > >
> > > Signed-off-by: Laurent Pinchart
> > >
> > > Tested-by: Jacopo Mondi
> > > ---
> > >
> > > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167 +
> > > 1 file changed, 167 insertions(+)
> > >
> > > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi index
> > > abb14af76c0e..600074ca3ee5 100644
> > > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > > @@ -537,6 +537,173 @@
> > > resets = <&cpg 408>;
> > > };
> >
> > These nodes should be placed after the gic to preserve the sorting
> > of nodes by bus address and then IP block.
>
> Aren't they already ? :-)
Git didn't seem to think so. But its not a big deal,
I can fix this up locally.
> > > + vspb0: vsp@fe96 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe96 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 626>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 626>;
> > > + renesas,fcp = <&fcpvb0>;
> > > + };
> > > +
> > > + fcpvb0: fcp@fe96f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe96f000 0 0x200>;
> > > + clocks = <&cpg CPG_MOD 607>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 607>;
> > > + iommus = <&ipmmu_vp0 5>;
> > > + };
> > > +
> > > + vspi0: vsp@fe9a {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfe9a 0 0x8000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 622>;
> >
> > R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> > that this clock should be <&cpg CPG_MOD 631>. The clock above is
> > (according to my reading of the documentation) correctly
> > used for vspd1 below.
>
> Bad copy and paste, thank you for pointing it out, it will be fixed in v3.
>
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 631>;
> > > + renesas,fcp = <&fcpvi0>;
> > > + };
> > > +
> > > + fcpvi0: fcp@fe9af000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfe9af000 0 0x200>;
> > > + clocks = <&cpg CPG_MOD 611>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 611>;
> > > + iommus = <&ipmmu_vp0 8>;
> > > + };
> > > +
> > > + vspd0: vsp@fea2 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea2 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 623>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 623>;
> > > + renesas,fcp = <&fcpvd0>;
> > > + };
> > > +
> > > + fcpvd0: fcp@fea27000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea27000 0 0x200>;
> > > + clocks = <&cpg CPG_MOD 603>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 603>;
> > > + iommus = <&ipmmu_vi0 8>;
> > > + };
> > > +
> > > + vspd1: vsp@fea28000 {
> > > + compatible = "renesas,vsp2";
> > > + reg = <0 0xfea28000 0 0x7000>;
> > > + interrupts = ;
> > > + clocks = <&cpg CPG_MOD 622>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 622>;
> > > + renesas,fcp = <&fcpvd1>;
> > > + };
> > > +
> > > + fcpvd1: fcp@fea2f000 {
> > > + compatible = "renesas,fcpv";
> > > + reg = <0 0xfea2f000 0 0x200>;
> > > + clocks = <&cpg CPG_MOD 602>;
> > > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > > + resets = <&cpg 602>;
> > > + iommus = <&ipmmu_vi0 9>;
> > > + };
> > > +
> > > + du: display@feb0 {
> > > + compatible = "renesas,du-r8a77990";
> > > + reg = <0 0xfeb0 0 0x8>;
> > > + interrup
Re: [PATCH v2 12/16] arm64: dts: renesas: r8a77990: Add I2C device nodes
On Fri, Sep 14, 2018 at 12:10:42PM +0300, Laurent Pinchart wrote:
> From: Takeshi Kihara
>
> Add device nodes for I2C ch{0,1,2,3,4,5,6,7} to R-Car E3 R8A77990 device
> tree.
>
> Signed-off-by: Takeshi Kihara
> Signed-off-by: Jacopo Mondi
> Tested-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 123
> ++
> 1 file changed, 123 insertions(+)
I believe this duplicates the following patch already queued-up for
v4.20.
Fixes: bc011dfa3065 ("arm64: dts: renesas: r8a77990: Add I2C device nodes")
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 3/5] drm/mxsfb: Add pm_runtime calls to pipe_enable/disable
Adding lcdif nodes to a power domain currently results in
black/corrupted screens or hangs because power is not correctly enabled
when required.
Ensure power is on when display is active by adding
pm_runtime_get/put_sync to mxsfb_pipe_enable/disable.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index ffe5137ccaf8..68d79f5dc0d3 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -101,23 +101,27 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
+ pm_runtime_get_sync(drm->dev);
drm_panel_prepare(mxsfb->panel);
mxsfb_crtc_enable(mxsfb);
drm_panel_enable(mxsfb->panel);
}
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
+ struct drm_device *drm = pipe->plane.dev;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
+ pm_runtime_put_sync(drm->dev);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 03/16] dt-bindings: display: renesas: lvds: Add EXTAL and DU_DOTCLKIN clocks
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > On the D3 and E3 SoCs, the LVDS encoder can derive its internal pixel > clock from an externally supplied clock, either through the EXTAL pin or > through one of the DU_DOTCLKINx pins. Add corresponding clocks to the DT > bindings. > > To retain backward compatibility with DT that don't specify the > clock-names property, the functional clock must always be specified > first, and the clock-names property is optional when only the functional > clock is specified. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Changes since v1: > > - Clarified wording > --- > .../devicetree/bindings/display/bridge/renesas,lvds.txt | 12 > +++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git > a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > index 13af7e2ac7e8..3aeb0ec06fd0 100644 > --- a/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > +++ b/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt > @@ -19,7 +19,17 @@ Required properties: >- "renesas,r8a77995-lvds" for R8A77995 (R-Car D3) compatible LVDS encoders > > - reg: Base address and length for the memory-mapped registers > -- clocks: A phandle + clock-specifier pair for the functional clock > +- clocks: A list of phandles + clock-specifier pairs, one for each entry in > + the clock-names property. > +- clock-names: Name of the clocks. This property is model-dependent. > + - The functional clock, which mandatory for all models, shall be listed > +first, and shall be named "fck". > + - On R8A77990 and R8A77995, the LVDS encoder can use the EXTAL or > +DU_DOTCLKINx clocks. Those clocks are optional. When supplied they must > be > +named "extal" and "dclkin.x" respectively, with "x" being the DU_DOTCLKIN > +numerical index. > + - When the clocks property only contains the functional clock, the > +clock-names property may be omitted. > - resets: A phandle + reset specifier for the module reset > > Required nodes: Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> supporting VSP and FCP.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
> ---
> arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> ++
> 1 file changed, 167 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> index abb14af76c0e..600074ca3ee5 100644
> --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> @@ -537,6 +537,173 @@
> resets = <&cpg 408>;
> };
These nodes should be placed after the gic to preserve the sorting
of nodes by bus address and then IP block.
> + vspb0: vsp@fe96 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe96 0 0x8000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 626>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 626>;
> + renesas,fcp = <&fcpvb0>;
> + };
> +
> + fcpvb0: fcp@fe96f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe96f000 0 0x200>;
> + clocks = <&cpg CPG_MOD 607>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 607>;
> + iommus = <&ipmmu_vp0 5>;
> + };
> +
> + vspi0: vsp@fe9a {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfe9a 0 0x8000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 622>;
R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
that this clock should be <&cpg CPG_MOD 631>. The clock above is
(according to my reading of the documentation) correctly
used for vspd1 below.
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 631>;
> + renesas,fcp = <&fcpvi0>;
> + };
> +
> + fcpvi0: fcp@fe9af000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfe9af000 0 0x200>;
> + clocks = <&cpg CPG_MOD 611>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 611>;
> + iommus = <&ipmmu_vp0 8>;
> + };
> +
> + vspd0: vsp@fea2 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea2 0 0x7000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 623>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 623>;
> + renesas,fcp = <&fcpvd0>;
> + };
> +
> + fcpvd0: fcp@fea27000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea27000 0 0x200>;
> + clocks = <&cpg CPG_MOD 603>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 603>;
> + iommus = <&ipmmu_vi0 8>;
> + };
> +
> + vspd1: vsp@fea28000 {
> + compatible = "renesas,vsp2";
> + reg = <0 0xfea28000 0 0x7000>;
> + interrupts = ;
> + clocks = <&cpg CPG_MOD 622>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 622>;
> + renesas,fcp = <&fcpvd1>;
> + };
> +
> + fcpvd1: fcp@fea2f000 {
> + compatible = "renesas,fcpv";
> + reg = <0 0xfea2f000 0 0x200>;
> + clocks = <&cpg CPG_MOD 602>;
> + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> + resets = <&cpg 602>;
> + iommus = <&ipmmu_vi0 9>;
> + };
> +
> + du: display@feb0 {
> + compatible = "renesas,du-r8a77990";
> + reg = <0 0xfeb0 0 0x8>;
> + interrupts = ,
> + ;
> + clocks = <&cpg CPG_MOD 724>,
> + <&cpg CPG_MOD 723>;
> + clock-names = "du.0", "du.1";
> + vsps = <&vspd0 0 &vspd1 0>;
> + status = "disabled";
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> +
Re: [PATCH v4] gpu/drm/exynos: Convert drm_atomic_helper_suspend/resume()
Hi Inki,
On Tue, Sep 11, 2018 at 2:06 PM Souptick Joarder wrote:
>
> On Thu, Aug 2, 2018 at 9:12 PM Souptick Joarder wrote:
> >
> > convert drm_atomic_helper_suspend/resume() to use
> > drm_mode_config_helper_suspend/resume().
> >
> > exynos_drm_fbdev_suspend/resume can be removed
> > as drm_mode_config_helper_suspend/resume has
> > implement the same in generic way.
> >
> > Remove suspend_state from exynos_drm_private
> > struct as it is no more useful.
> >
> > Signed-off-by: Ajit Negi
> > Signed-off-by: Souptick Joarder
> > Tested-by: Marek Szyprowski
>
> Can we get this patch in queue for 4.20 ? Not yet available in linux-next.
Is this patch queued for 4.20 ?
> > ---
> > v2: Address Inki Dae's comment. Remove ret variable
> > from both suspend/resume function.
> >
> > v3: Tested by Marek. Updated the change log.
> >
> > v4: removing the return as exynos_drm_resume()
> > now returns void.
> >
> > drivers/gpu/drm/exynos/exynos_drm_drv.c | 26 ++
> > drivers/gpu/drm/exynos/exynos_drm_drv.h | 1 -
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.c | 17 -
> > drivers/gpu/drm/exynos/exynos_drm_fbdev.h | 10 --
> > 4 files changed, 2 insertions(+), 52 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > index b599f74..6f76baf 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.c
> > @@ -149,37 +149,15 @@ static void exynos_drm_postclose(struct drm_device
> > *dev, struct drm_file *file)
> > static int exynos_drm_suspend(struct device *dev)
> > {
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > - struct exynos_drm_private *private;
> > -
> > - if (!drm_dev)
> > - return 0;
> > -
> > - private = drm_dev->dev_private;
> > -
> > - drm_kms_helper_poll_disable(drm_dev);
> > - exynos_drm_fbdev_suspend(drm_dev);
> > - private->suspend_state = drm_atomic_helper_suspend(drm_dev);
> > - if (IS_ERR(private->suspend_state)) {
> > - exynos_drm_fbdev_resume(drm_dev);
> > - drm_kms_helper_poll_enable(drm_dev);
> > - return PTR_ERR(private->suspend_state);
> > - }
> >
> > - return 0;
> > + return drm_mode_config_helper_suspend(drm_dev);
> > }
> >
> > static void exynos_drm_resume(struct device *dev)
> > {
> > struct drm_device *drm_dev = dev_get_drvdata(dev);
> > - struct exynos_drm_private *private;
> > -
> > - if (!drm_dev)
> > - return;
> >
> > - private = drm_dev->dev_private;
> > - drm_atomic_helper_resume(drm_dev, private->suspend_state);
> > - exynos_drm_fbdev_resume(drm_dev);
> > - drm_kms_helper_poll_enable(drm_dev);
> > + drm_mode_config_helper_resume(drm_dev);
> > }
> >
> > static const struct dev_pm_ops exynos_drm_pm_ops = {
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > index c737c4b..7349e7c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_drv.h
> > @@ -195,7 +195,6 @@ struct drm_exynos_file_private {
> > */
> > struct exynos_drm_private {
> > struct drm_fb_helper *fb_helper;
> > - struct drm_atomic_state *suspend_state;
> >
> > struct device *g2d_dev;
> > struct device *dma_dev;
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > index 132dd52..918dd2c 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.c
> > @@ -270,20 +270,3 @@ void exynos_drm_fbdev_fini(struct drm_device *dev)
> > private->fb_helper = NULL;
> > }
> >
> > -void exynos_drm_fbdev_suspend(struct drm_device *dev)
> > -{
> > - struct exynos_drm_private *private = dev->dev_private;
> > -
> > - console_lock();
> > - drm_fb_helper_set_suspend(private->fb_helper, 1);
> > - console_unlock();
> > -}
> > -
> > -void exynos_drm_fbdev_resume(struct drm_device *dev)
> > -{
> > - struct exynos_drm_private *private = dev->dev_private;
> > -
> > - console_lock();
> > - drm_fb_helper_set_suspend(private->fb_helper, 0);
> > - console_unlock();
> > -}
> > diff --git a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > index b338472..6840b6a 100644
> > --- a/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > +++ b/drivers/gpu/drm/exynos/exynos_drm_fbdev.h
> > @@ -19,8 +19,6 @@
> >
> > int exynos_drm_fbdev_init(struct drm_device *dev);
> > void exynos_drm_fbdev_fini(struct drm_device *dev);
> > -void exynos_drm_fbdev_suspend(struct drm_device *drm);
> > -void exynos_drm_fbdev_resume(struct drm_device *drm);
> >
> > #else
> >
> > @@ -39,14 +37,6 @@ static inline void exynos_drm_fbdev_restore_mode(struct
> > drm_device *de
[RESEND 0/5] drm/mxsfb: Fix runtime PM for unpowering lcdif block
Adding lcdif nodes to a power domain currently doesn't work, it results in black/corrupted screens or hangs. While the driver does enable runtime pm it does not deal correctly with the block being unpowered. --- All patches in this series have review tags from a while ago and I tested them again on top of next-20180913. No changes since last version: https://lkml.org/lkml/2018/8/27/299 This series stalled so I reached out to Marek on IRC and he was surprised to be listed as maintainer and asked me to resend and add Daniel Vetter. Perhaps it would help to clarify that the pengutronix people should feel free to push patches in this area? Right now drm/imx is mostly for IPUv3 but there are other display output paths on imx, such as the LCDIF supported by this driver. This LCDIF block is included on imx8 so still quite relevant. Leonard Crestez (5): drm/mxsfb: Move axi clk enable/disable to crtc enable/disable drm/mxsfb: Fix initial corrupt frame when activating display drm/mxsfb: Add pm_runtime calls to pipe_enable/disable drm/mxsfb: Add PM_SLEEP support drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 53 +++--- drivers/gpu/drm/mxsfb/mxsfb_drv.c | 40 ++ 2 files changed, 74 insertions(+), 19 deletions(-) -- 2.17.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 13/16] arm64: dts: renesas: r8a77990: Add display output support
On Mon, Sep 17, 2018 at 09:50:55AM +0200, Simon Horman wrote:
> On Fri, Sep 14, 2018 at 12:10:43PM +0300, Laurent Pinchart wrote:
> > The R8A77990 (E3) platform has one RGB output and two LVDS outputs
> > connected to the DU. Add the DT nodes for the DU, LVDS encoders and
> > supporting VSP and FCP.
> >
> > Signed-off-by: Laurent Pinchart
> > Tested-by: Jacopo Mondi
> > ---
> > arch/arm64/boot/dts/renesas/r8a77990.dtsi | 167
> > ++
> > 1 file changed, 167 insertions(+)
> >
> > diff --git a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > index abb14af76c0e..600074ca3ee5 100644
> > --- a/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > +++ b/arch/arm64/boot/dts/renesas/r8a77990.dtsi
> > @@ -537,6 +537,173 @@
> > resets = <&cpg 408>;
> > };
>
> These nodes should be placed after the gic to preserve the sorting
> of nodes by bus address and then IP block.
>
> > + vspb0: vsp@fe96 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe96 0 0x8000>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD 626>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 626>;
> > + renesas,fcp = <&fcpvb0>;
> > + };
> > +
> > + fcpvb0: fcp@fe96f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe96f000 0 0x200>;
> > + clocks = <&cpg CPG_MOD 607>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 607>;
> > + iommus = <&ipmmu_vp0 5>;
> > + };
> > +
> > + vspi0: vsp@fe9a {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfe9a 0 0x8000>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD 622>;
>
> R-Car Series, 3rd Generation, v1.00, Table Table 8A.21 indicates
> that this clock should be <&cpg CPG_MOD 631>. The clock above is
> (according to my reading of the documentation) correctly
> used for vspd1 below.
>
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 631>;
> > + renesas,fcp = <&fcpvi0>;
> > + };
> > +
> > + fcpvi0: fcp@fe9af000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfe9af000 0 0x200>;
> > + clocks = <&cpg CPG_MOD 611>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 611>;
> > + iommus = <&ipmmu_vp0 8>;
> > + };
> > +
> > + vspd0: vsp@fea2 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea2 0 0x7000>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD 623>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 623>;
> > + renesas,fcp = <&fcpvd0>;
> > + };
> > +
> > + fcpvd0: fcp@fea27000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea27000 0 0x200>;
> > + clocks = <&cpg CPG_MOD 603>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 603>;
> > + iommus = <&ipmmu_vi0 8>;
> > + };
> > +
> > + vspd1: vsp@fea28000 {
> > + compatible = "renesas,vsp2";
> > + reg = <0 0xfea28000 0 0x7000>;
> > + interrupts = ;
> > + clocks = <&cpg CPG_MOD 622>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 622>;
> > + renesas,fcp = <&fcpvd1>;
> > + };
> > +
> > + fcpvd1: fcp@fea2f000 {
> > + compatible = "renesas,fcpv";
> > + reg = <0 0xfea2f000 0 0x200>;
> > + clocks = <&cpg CPG_MOD 602>;
> > + power-domains = <&sysc R8A77990_PD_ALWAYS_ON>;
> > + resets = <&cpg 602>;
> > + iommus = <&ipmmu_vi0 9>;
> > + };
> > +
> > + du: display@feb0 {
> > + compatible = "renesas,du-r8a77990";
> > + reg = <0 0xfeb0 0 0x8>;
> > + interrupts = ,
> > +;
> > + clocks = <&cpg CPG_MOD 724>,
> > +<&cpg CPG_MOD 723>;
> > + clock-names = "du.0", "du.1";
> > + vsps = <&vspd0 0 &vspd1 0>;
> > + status = "disabled";
> > +
> > + ports {
>
[RESEND 1/5] drm/mxsfb: Move axi clk enable/disable to crtc enable/disable
The main axi clk is disabled at the end of mxsfb_crtc_mode_set_nofb and
immediately reenabled in mxsfb_enable_controller.
Avoid this by moving the handling of axi clk one level up to
mxsfb_crtc_enable. Do the same for mxsfb_crtc_disable for symmetry.
This shouldn't have any functional effect.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_crtc.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
index 0abe77675b76..e4fcbb65b969 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_crtc.c
@@ -127,11 +127,10 @@ static void mxsfb_enable_controller(struct
mxsfb_drm_private *mxsfb)
u32 reg;
if (mxsfb->clk_disp_axi)
clk_prepare_enable(mxsfb->clk_disp_axi);
clk_prepare_enable(mxsfb->clk);
- mxsfb_enable_axi_clk(mxsfb);
/* If it was disabled, re-enable the mode again */
writel(CTRL_DOTCLK_MODE, mxsfb->base + LCDC_CTRL + REG_SET);
/* Enable the SYNC signals first, then the DMA engine */
@@ -157,12 +156,10 @@ static void mxsfb_disable_controller(struct
mxsfb_drm_private *mxsfb)
reg = readl(mxsfb->base + LCDC_VDCTRL4);
reg &= ~VDCTRL4_SYNC_SIGNALS_ON;
writel(reg, mxsfb->base + LCDC_VDCTRL4);
- mxsfb_disable_axi_clk(mxsfb);
-
clk_disable_unprepare(mxsfb->clk);
if (mxsfb->clk_disp_axi)
clk_disable_unprepare(mxsfb->clk_disp_axi);
}
@@ -206,11 +203,10 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
/*
* It seems, you can't re-program the controller if it is still
* running. This may lead to shifted pictures (FIFO issue?), so
* first stop the controller and drain its FIFOs.
*/
- mxsfb_enable_axi_clk(mxsfb);
/* Mandatory eLCDIF reset as per the Reference Manual */
err = mxsfb_reset_block(mxsfb->base);
if (err)
return;
@@ -267,23 +263,23 @@ static void mxsfb_crtc_mode_set_nofb(struct
mxsfb_drm_private *mxsfb)
SET_VERT_WAIT_CNT(m->crtc_vtotal - m->crtc_vsync_start),
mxsfb->base + LCDC_VDCTRL3);
writel(SET_DOTCLK_H_VALID_DATA_CNT(m->hdisplay),
mxsfb->base + LCDC_VDCTRL4);
-
- mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_crtc_enable(struct mxsfb_drm_private *mxsfb)
{
+ mxsfb_enable_axi_clk(mxsfb);
mxsfb_crtc_mode_set_nofb(mxsfb);
mxsfb_enable_controller(mxsfb);
}
void mxsfb_crtc_disable(struct mxsfb_drm_private *mxsfb)
{
mxsfb_disable_controller(mxsfb);
+ mxsfb_disable_axi_clk(mxsfb);
}
void mxsfb_plane_atomic_update(struct mxsfb_drm_private *mxsfb,
struct drm_plane_state *state)
{
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 5/5] drm/mxsfb: Switch to drm_atomic_helper_commit_tail_rpm
The lcdif block is only powered on when display is active so plane
updates when not enabled are not valid. Writing to an unpowered IP block
is mostly ignored but can trigger bus errors on some chips.
Prevent this situation by switching to drm_atomic_helper_commit_tail_rpm
and having the drm core ensure atomic_plane_update is only called while
the crtc is active. This avoids having to keep track of "enabled" bits
inside the mxsfb driver.
This also requires handling the vblank event for disable from
mxsfb_pipe_disable.
Signed-off-by: Leonard Crestez
Suggested-by: Stefan Agner
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 15 +++
1 file changed, 15 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index d797dfd40d98..5777e730085b 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -96,10 +96,14 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
.fb_create = drm_gem_fb_create,
.atomic_check = drm_atomic_helper_check,
.atomic_commit = drm_atomic_helper_commit,
};
+static const struct drm_mode_config_helper_funcs mxsfb_mode_config_helpers = {
+ .atomic_commit_tail = drm_atomic_helper_commit_tail_rpm,
+};
+
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state,
struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
@@ -113,15 +117,25 @@ static void mxsfb_pipe_enable(struct
drm_simple_display_pipe *pipe,
static void mxsfb_pipe_disable(struct drm_simple_display_pipe *pipe)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
struct drm_device *drm = pipe->plane.dev;
+ struct drm_crtc *crtc = &pipe->crtc;
+ struct drm_pending_vblank_event *event;
drm_panel_disable(mxsfb->panel);
mxsfb_crtc_disable(mxsfb);
drm_panel_unprepare(mxsfb->panel);
pm_runtime_put_sync(drm->dev);
+
+ spin_lock_irq(&drm->event_lock);
+ event = crtc->state->event;
+ if (event) {
+ crtc->state->event = NULL;
+ drm_crtc_send_vblank_event(crtc, event);
+ }
+ spin_unlock_irq(&drm->event_lock);
}
static void mxsfb_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *plane_state)
{
@@ -232,10 +246,11 @@ static int mxsfb_load(struct drm_device *drm, unsigned
long flags)
drm->mode_config.min_width = MXSFB_MIN_XRES;
drm->mode_config.min_height = MXSFB_MIN_YRES;
drm->mode_config.max_width = MXSFB_MAX_XRES;
drm->mode_config.max_height = MXSFB_MAX_YRES;
drm->mode_config.funcs = &mxsfb_mode_config_funcs;
+ drm->mode_config.helper_private = &mxsfb_mode_config_helpers;
drm_mode_config_reset(drm);
pm_runtime_get_sync(drm->dev);
ret = drm_irq_install(drm, platform_get_irq(pdev, 0));
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[RESEND 4/5] drm/mxsfb: Add PM_SLEEP support
Since power to the lcdif block can be lost on suspend implement
PM_SLEEP_OPS using drm_mode_config_helper_suspend/resume to save/restore
the current mode.
Signed-off-by: Leonard Crestez
Reviewed-by: Stefan Agner
---
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 21 +
1 file changed, 21 insertions(+)
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 68d79f5dc0d3..d797dfd40d98 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -416,17 +416,38 @@ static int mxsfb_remove(struct platform_device *pdev)
drm_dev_unref(drm);
return 0;
}
+#ifdef CONFIG_PM_SLEEP
+static int mxsfb_suspend(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_suspend(drm);
+}
+
+static int mxsfb_resume(struct device *dev)
+{
+ struct drm_device *drm = dev_get_drvdata(dev);
+
+ return drm_mode_config_helper_resume(drm);
+}
+#endif
+
+static const struct dev_pm_ops mxsfb_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(mxsfb_suspend, mxsfb_resume)
+};
+
static struct platform_driver mxsfb_platform_driver = {
.probe = mxsfb_probe,
.remove = mxsfb_remove,
.id_table = mxsfb_devtype,
.driver = {
.name = "mxsfb",
.of_match_table = mxsfb_dt_ids,
+ .pm = &mxsfb_pm_ops,
},
};
module_platform_driver(mxsfb_platform_driver);
--
2.17.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/radeon: change function signature to pass full range
On Fri, Apr 13, 2018 at 9:59 AM Huang Rui wrote:
> On Thu, Apr 12, 2018 at 09:33:33PM +0200, Mathieu Malaterre wrote:
> > In function ‘radeon_process_i2c_ch’ a comparison of a u8 value against
> > 255 is done. Since it is always false, change the signature of this
> > function to use an `int` instead, which match the type used in caller:
> > `radeon_atom_hw_i2c_xfer`.
> >
> > Fix the following warning triggered with W=1:
> >
> > CC [M] drivers/gpu/drm/radeon/atombios_i2c.o
> > drivers/gpu/drm/radeon/atombios_i2c.c: In function
> ‘radeon_process_i2c_ch’:
> > drivers/gpu/drm/radeon/atombios_i2c.c:71:11: warning: comparison is
> always false due to limited range of data type [-Wtype-limits]
> >if (num > ATOM_MAX_HW_I2C_READ) {
> >^
> >
> > Signed-off-by: Mathieu Malaterre
>
> Reviewed-by: Huang Rui
>
>
Any chance to be included in the next pull request ? thanks
> > ---
> > drivers/gpu/drm/radeon/atombios_i2c.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/radeon/atombios_i2c.c
> b/drivers/gpu/drm/radeon/atombios_i2c.c
> > index 4157780585a0..9022e9af11a0 100644
> > --- a/drivers/gpu/drm/radeon/atombios_i2c.c
> > +++ b/drivers/gpu/drm/radeon/atombios_i2c.c
> > @@ -35,7 +35,7 @@
> >
> > static int radeon_process_i2c_ch(struct radeon_i2c_chan *chan,
> >u8 slave_addr, u8 flags,
> > - u8 *buf, u8 num)
> > + u8 *buf, int num)
> > {
> > struct drm_device *dev = chan->dev;
> > struct radeon_device *rdev = dev->dev_private;
> > --
> > 2.11.0
> >
> > ___
> > amd-gfx mailing list
> > amd-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH 5/5] ARM: sun8i: dts: drop A64 HDMI PHY fallback compatible from R40 DT
在 2018-09-17一的 16:54 +0200，Maxime Ripard写道：
> On Mon, Sep 10, 2018 at 04:32:30PM +0200, Jernej Škrabec wrote:
> > Dne ponedeljek, 10. september 2018 ob 16:23:54 CEST je Maxime
> > Ripard
> > napisal(a):
> > > On Fri, Sep 07, 2018 at 03:22:34PM +0800, Icenowy Zheng wrote:
> > > > The R40 HDMI PHY seems to be different to the A64 one, the A64
> > > > one
> > > > has no input mux, but the R40 one has.
> > > >
> > > > Drop the A64 fallback compatible from the HDMI PHY node in R40
> > > > DT.
> > > >
> > > > Signed-off-by: Icenowy Zheng
> > > > ---
> > > >
> > > > arch/arm/boot/dts/sun8i-r40.dtsi | 3 +--
> > > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > > >
> > > > diff --git a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > b/arch/arm/boot/dts/sun8i-r40.dtsi index
> > > > ffd9f00f74a4..5f547c161baf
> > > > 100644
> > > > --- a/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > +++ b/arch/arm/boot/dts/sun8i-r40.dtsi
> > > > @@ -800,8 +800,7 @@
> > > >
> > > > };
> > > >
> > > > hdmi_phy: hdmi-phy@1ef {
> > > >
> > > > - compatible = "allwinner,sun8i-r40-hdmi-
> > > > phy",
> > > > -"allwinner,sun50i-a64-
> > > > hdmi-phy";
> > > > + compatible = "allwinner,sun8i-r40-hdmi-
> > > > phy";
> > >
> > > If you could use the A64 phy before, you can still use it now.
> >
> > Not exactly. Given that we don't know how to switch between HDMI
> > PHY clock
> > parents on A64 (if it is actually connected at all, there is no
> > information
> > about that in manual and AW didn't answered our questions, despite
> > asking them
> > through different channels), A64 compatible will be associated with
> > quirk,
> > which will tell that only one clock parent is usable.
> >
> > However, R40 HDMI PHY has definetly two clock parents, as it was
> > tested by me
> > and Icenowy and we know how to switch between them without issues.
> > Technically, we could have A64 compatible there, but that would
> > mean only
> > single PHY parent is considered instead of two.
>
> The DT change above would mean that you can't operate the R40 phy in
> the same way than the A64's. From what you're telling me now, this
> isn't exactly what is going on: you can operate the R40 phy just like
> the A64: with a single PLL instead of two. You operate in a degraded
> and non-optimal mode, but it still works.
The status of R40 HDMI PHY input mux is not determined when use A64
driver, which makes it not working when the bootloader initializes it
to use the second PLL (the A64 driver will assume the parent is the
first PLL).
>
> And it's exactly what the DT is already saying.
>
> Maxime
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/16] drm: rcar-du: lvds: D3/E3 support
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The LVDS encoders in the D3 and E3 SoCs differ significantly from those
> in the other R-Car Gen3 family members:
>
> - The LVDS PLL architecture is more complex and requires computing PLL
> parameters manually.
> - The PLL uses external clocks as inputs, which need to be retrieved
> from DT.
> - In addition to the different PLL setup, the startup sequence has
> changed *again* (seems someone had trouble making his/her mind).
>
> Supporting all this requires DT bindings extensions for external clocks,
> brand new PLL setup code, and a few quirks to handle the differences in
> the startup sequence.
>
> The implementation doesn't support all hardware features yet, namely
>
> - Using the LV[01] clocks generated by the CPG as PLL input.
> - Providing the LVDS PLL clock to the DU for use with the RGB output.
>
> Those features can be added later when the need will arise.
>
> Signed-off-by: Laurent Pinchart
> Tested-by: Jacopo Mondi
> ---
> Changes since v1:
>
> - Don't compile-out debug code based on DEBUG and CONFIG_DYNAMIC_DEBUG
> - Test all three input clocks (DOTCLKIN[01] and EXTAL) and pick the best
> one
> ---
> drivers/gpu/drm/rcar-du/rcar_lvds.c | 355
> +++
> drivers/gpu/drm/rcar-du/rcar_lvds_regs.h | 43 +++-
> 2 files changed, 351 insertions(+), 47 deletions(-)
>
> diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> index ce0eb68c3416..23e7743144c8 100644
> --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> @@ -24,6 +24,8 @@
>
> #include "rcar_lvds_regs.h"
>
> +struct rcar_lvds;
> +
> /* Keep in sync with the LVDCR0.LVMD hardware register values. */
> enum rcar_lvds_mode {
> RCAR_LVDS_MODE_JEIDA = 0,
> @@ -31,14 +33,16 @@ enum rcar_lvds_mode {
> RCAR_LVDS_MODE_VESA = 4,
> };
>
> -#define RCAR_LVDS_QUIRK_LANES(1 << 0)/* LVDS lanes 1 and 3
> inverted */
> -#define RCAR_LVDS_QUIRK_GEN2_PLLCR (1 << 1) /* LVDPLLCR has gen2 layout */
> -#define RCAR_LVDS_QUIRK_GEN3_LVEN (1 << 2) /* LVEN bit needs to be set */
> - /* on R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_LANESBIT(0) /* LVDS lanes 1 and 3
> inverted */
> +#define RCAR_LVDS_QUIRK_GEN3_LVENBIT(1) /* LVEN bit needs to be set on
> R8A77970/R8A7799x */
> +#define RCAR_LVDS_QUIRK_PWD BIT(2) /* PWD bit available (all of
> Gen3 but E3) */
> +#define RCAR_LVDS_QUIRK_EXT_PLL BIT(3) /* Has extended PLL */
> +#define RCAR_LVDS_QUIRK_DUAL_LINKBIT(4) /* Supports dual-link operation
> */
>
> struct rcar_lvds_device_info {
> unsigned int gen;
> unsigned int quirks;
> + void (*pll_setup)(struct rcar_lvds *lvds, unsigned int freq);
> };
>
> struct rcar_lvds {
> @@ -52,7 +56,11 @@ struct rcar_lvds {
> struct drm_panel *panel;
>
> void __iomem *mmio;
> - struct clk *clock;
> + struct {
> + struct clk *mod;/* CPG module clock */
> + struct clk *extal; /* External clock */
> + struct clk *dotclkin[2];/* External DU clocks */
> + } clocks;
> bool enabled;
>
> struct drm_display_mode display_mode;
> @@ -128,33 +136,212 @@ static const struct drm_connector_funcs
> rcar_lvds_conn_funcs = {
> };
>
> /*
> -
> - * Bridge
> + * PLL Setup
> */
>
> -static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen2(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 39000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> - else if (freq < 61000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> - else if (freq < 121000)
> - return LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> + u32 val;
> +
> + if (freq < 3900)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
> + else if (freq < 6100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
> + else if (freq < 12100)
> + val = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_121M;
> else
> - return LVDPLLCR_PLLDLYCNT_150M;
> + val = LVDPLLCR_PLLDLYCNT_150M;
> +
> + rcar_lvds_write(lvds, LVDPLLCR, val);
> }
>
> -static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
> +static void rcar_lvds_pll_setup_gen3(struct rcar_lvds *lvds, unsigned int
> freq)
> {
> - if (freq < 42000)
> - return LVDPLLCR_PLLDIVCNT_42M;
> - else if (freq < 85000)
> - return LVDPLLCR_PLLDIVCNT_85M;
> - else if (freq < 128000)
> - return LVDPLLCR_PLLDIVCNT_
Re: [PATCH v2 01/16] dt-bindings: display: renesas: du: Document r8a77990 bindings
> On September 14, 2018 at 11:10 AM Laurent Pinchart > wrote: > > > Document the E3 (r8a77990) SoC in the R-Car DU bindings. > > Signed-off-by: Laurent Pinchart > Reviewed-by: Jacopo Mondi > --- > Documentation/devicetree/bindings/display/renesas,du.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/devicetree/bindings/display/renesas,du.txt > b/Documentation/devicetree/bindings/display/renesas,du.txt > index caae2348a292..9de67be632d1 100644 > --- a/Documentation/devicetree/bindings/display/renesas,du.txt > +++ b/Documentation/devicetree/bindings/display/renesas,du.txt > @@ -16,6 +16,7 @@ Required Properties: > - "renesas,du-r8a77965" for R8A77965 (R-Car M3-N) compatible DU > - "renesas,du-r8a77970" for R8A77970 (R-Car V3M) compatible DU > - "renesas,du-r8a77980" for R8A77980 (R-Car V3H) compatible DU > +- "renesas,du-r8a77990" for R8A77990 (R-Car E3) compatible DU > - "renesas,du-r8a77995" for R8A77995 (R-Car D3) compatible DU > >- reg: the memory-mapped I/O registers base address and length > @@ -63,6 +64,7 @@ corresponding to each DU output. > R8A77965 (R-Car M3-N) DPAD 0 HDMI 0 LVDS 0 - > R8A77970 (R-Car V3M) DPAD 0 LVDS 0 - - > R8A77980 (R-Car V3H) DPAD 0 LVDS 0 - - > + R8A77990 (R-Car E3)DPAD 0 LVDS 0 LVDS 1 - > R8A77995 (R-Car D3)DPAD 0 LVDS 0 LVDS 1 - > > Reviewed-by: Ulrich Hecht CU Uli ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 04/16] drm: bridge: thc63: Restrict modes based on hardware operating frequency
Thank you for your patch!
> On September 14, 2018 at 11:10 AM Laurent Pinchart
> wrote:
>
>
> The THC63LVD1024 is restricted to a pixel clock frequency in the range
> of 8 to 135 MHz. Implement the bridge .mode_valid() operation
> accordingly.
>
> Signed-off-by: Laurent Pinchart
> Reviewed-by: Andrzej Hajda
> Tested-by: Jacopo Mondi
> ---
> drivers/gpu/drm/bridge/thc63lvd1024.c | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff --git a/drivers/gpu/drm/bridge/thc63lvd1024.c
> b/drivers/gpu/drm/bridge/thc63lvd1024.c
> index c8b9edd5a7f4..63609ba16b6d 100644
> --- a/drivers/gpu/drm/bridge/thc63lvd1024.c
> +++ b/drivers/gpu/drm/bridge/thc63lvd1024.c
> @@ -45,6 +45,23 @@ static int thc63_attach(struct drm_bridge *bridge)
> return drm_bridge_attach(bridge->encoder, thc63->next, bridge);
> }
>
> +static enum drm_mode_status thc63_mode_valid(struct drm_bridge *bridge,
> + const struct drm_display_mode *mode)
> +{
> + /*
> + * The THC63LVD0124 clock frequency range is 8 to 135 MHz in single-in,
That should be THC63LVD1024.
> + * single-out mode.
For the input clock (that's what we're talking about, right?), that also
applies to single-in/dual-out. Maybe just omit the "single-out" clause?
> Note that the limits depends on the mode and will
> + * need to be adjusted accordingly.
> + */
I don't quite understand. Does that refer to the THC63 mode, or the DRM mode?
> + if (mode->clock < 8000)
> + return MODE_CLOCK_LOW;
> +
> + if (mode->clock > 135000)
> + return MODE_CLOCK_HIGH;
> +
> + return MODE_OK;
> +}
> +
> static void thc63_enable(struct drm_bridge *bridge)
> {
> struct thc63_dev *thc63 = to_thc63(bridge);
> @@ -77,6 +94,7 @@ static void thc63_disable(struct drm_bridge *bridge)
>
> static const struct drm_bridge_funcs thc63_bridge_func = {
> .attach = thc63_attach,
> + .mode_valid = thc63_mode_valid,
> .enable = thc63_enable,
> .disable = thc63_disable,
> };
> --
> Regards,
>
> Laurent Pinchart
>
CU
Uli
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Wed, 12 Sep 2018 17:08:52 +0200
Arnd Bergmann wrote:
> The .ioctl and .compat_ioctl file operations have the same prototype so
> they can both point to the same function, which works great almost all
> the time when all the commands are compatible.
>
> One exception is the s390 architecture, where a compat pointer is only
> 31 bit wide, and converting it into a 64-bit pointer requires calling
> compat_ptr(). Most drivers here will ever run in s390, but since we now
> have a generic helper for it, it's easy enough to use it consistently.
>
> I double-checked all these drivers to ensure that all ioctl arguments
> are used as pointers or are ignored, but are not interpreted as integer
> values.
>
> Signed-off-by: Arnd Bergmann
> ---
For IIO part.
Acked-by: Jonathan Cameron
Thanks,
> diff --git a/drivers/iio/industrialio-core.c b/drivers/iio/industrialio-core.c
> index a062cfddc5af..22844b94b0e9 100644
> --- a/drivers/iio/industrialio-core.c
> +++ b/drivers/iio/industrialio-core.c
> @@ -1630,7 +1630,7 @@ static const struct file_operations iio_buffer_fileops
> = {
> .owner = THIS_MODULE,
> .llseek = noop_llseek,
> .unlocked_ioctl = iio_ioctl,
> - .compat_ioctl = iio_ioctl,
> + .compat_ioctl = generic_compat_ioctl_ptrarg,
> };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm: Fix syncobj handing of schedule() returning 0
After schedule() returns 0, we must do one last check of COND to
determine the reason for the wakeup with 0 jiffies remaining before
reporting the timeout -- otherwise we may lose the signal due to
scheduler delays.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106690
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 41 +--
1 file changed, 15 insertions(+), 26 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index e254f97fed7d..5bcb3ef9b256 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -672,7 +672,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
{
struct syncobj_wait_entry *entries;
struct dma_fence *fence;
- signed long ret;
uint32_t signaled_count, i;
entries = kcalloc(count, sizeof(*entries), GFP_KERNEL);
@@ -692,7 +691,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
if (flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_FOR_SUBMIT) {
continue;
} else {
- ret = -EINVAL;
+ timeout = -EINVAL;
goto cleanup_entries;
}
}
@@ -704,12 +703,6 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
}
}
- /* Initialize ret to the max of timeout and 1. That way, the
-* default return value indicates a successful wait and not a
-* timeout.
-*/
- ret = max_t(signed long, timeout, 1);
-
if (signaled_count == count ||
(signaled_count > 0 &&
!(flags & DRM_SYNCOBJ_WAIT_FLAGS_WAIT_ALL)))
@@ -760,18 +753,17 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
goto done_waiting;
if (timeout == 0) {
- /* If we are doing a 0 timeout wait and we got
-* here, then we just timed out.
-*/
- ret = 0;
+ timeout = -ETIME;
goto done_waiting;
}
- ret = schedule_timeout(ret);
+ if (signal_pending(current)) {
+ timeout = -ERESTARTSYS;
+ goto done_waiting;
+ }
- if (ret > 0 && signal_pending(current))
- ret = -ERESTARTSYS;
- } while (ret > 0);
+ timeout = schedule_timeout(timeout);
+ } while (1);
done_waiting:
__set_current_state(TASK_RUNNING);
@@ -788,7 +780,7 @@ static signed long drm_syncobj_array_wait_timeout(struct
drm_syncobj **syncobjs,
}
kfree(entries);
- return ret;
+ return timeout;
}
/**
@@ -829,19 +821,16 @@ static int drm_syncobj_array_wait(struct drm_device *dev,
struct drm_syncobj **syncobjs)
{
signed long timeout = drm_timeout_abs_to_jiffies(wait->timeout_nsec);
- signed long ret = 0;
uint32_t first = ~0;
- ret = drm_syncobj_array_wait_timeout(syncobjs,
-wait->count_handles,
-wait->flags,
-timeout, &first);
- if (ret < 0)
- return ret;
+ timeout = drm_syncobj_array_wait_timeout(syncobjs,
+wait->count_handles,
+wait->flags,
+timeout, &first);
+ if (timeout < 0)
+ return timeout;
wait->first_signaled = first;
- if (ret == 0)
- return -ETIME;
return 0;
}
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm: Use default dma_fence hooks where possible for null syncobj
Both the .enable_signaling and .release of the null syncobj fence
can be replaced by the default callbacks for a small reduction in code
size.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/drm_syncobj.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c
index 497729202bfe..e254f97fed7d 100644
--- a/drivers/gpu/drm/drm_syncobj.c
+++ b/drivers/gpu/drm/drm_syncobj.c
@@ -66,20 +66,9 @@ static const char *drm_syncobj_stub_fence_get_name(struct
dma_fence *fence)
return "syncobjstub";
}
-static bool drm_syncobj_stub_fence_enable_signaling(struct dma_fence *fence)
-{
-return !dma_fence_is_signaled(fence);
-}
-
-static void drm_syncobj_stub_fence_release(struct dma_fence *f)
-{
- kfree(f);
-}
static const struct dma_fence_ops drm_syncobj_stub_fence_ops = {
.get_driver_name = drm_syncobj_stub_fence_get_name,
.get_timeline_name = drm_syncobj_stub_fence_get_name,
- .enable_signaling = drm_syncobj_stub_fence_enable_signaling,
- .release = drm_syncobj_stub_fence_release,
};
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 --- Comment #20 from Mike Lothian --- Created attachment 141635 --> https://bugs.freedesktop.org/attachment.cgi?id=141635&action=edit Using libunwind -- 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 107950] Delayed freeze with DRI_PRIME=1 on Topaz
https://bugs.freedesktop.org/show_bug.cgi?id=107950 --- Comment #7 from SET --- With EXA, sddm login screen does not show up. xf86-video-ati 18.1.0 is in testing branch at Arch repositories. Will test when it'll be available as stable. -- 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 101877] R9 390 with multiple monitors always using highest memory clock
https://bugs.freedesktop.org/show_bug.cgi?id=101877 --- Comment #5 from Alexandre Pereira --- I have a similar problem. I have a Rx 580 with 2 exactly equal monitors. On windows, there is no issue and memory clock is always at 300mhz, except when gaming. When on linux, If using graphical display, memory clock is always MAX. If i am only on the tty's ( text mode only ) I can set it to 300mhz, after changing memory clock pp setting ( echo 1 > pp_mclk_od ). Like the op, drawing 40 watts more power than windows, is very undesirable, besides also running much cooler on windows. Also on windows I never saw any problem whatsoever with it running at minimum 300mhz. -- 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 107953] Screen Corruption (Bisected)
https://bugs.freedesktop.org/show_bug.cgi?id=107953 --- Comment #2 from Nicholas Kazlauskas --- Thanks for the report. This had a Vega specific fix in mind but I guess it extends to Polaris as well. I would imagine the first patch from this thread should fix your issue (ie. the one that's *not* the dce120 one) https://bugzilla.kernel.org/show_bug.cgi?id=201067 If it doesn't, then you should post your full dmesg and Xorg logs. -- 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 107978] [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank)
https://bugs.freedesktop.org/show_bug.cgi?id=107978 Bug ID: 107978 Summary: [amdgpu] Switching to tty fails with DisplayPort monitor going to sleep (REG_WAIT timeout / dce110_stream_encoder_dp_blank) Product: DRI Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: DRM/AMDgpu Assignee: dri-devel@lists.freedesktop.org Reporter: shtetl...@gmail.com After upgrading to Linux 4.19-rc3 (from 4.18.x), I can't switch to tty anymore, the monitor connected over DisplayPort goes into sleep mode. I see this in dmesg when it happens: [37342.777399] [drm:generic_reg_wait [amdgpu]] *ERROR* REG_WAIT timeout 10us * 3000 tries - dce110_stream_encoder_dp_blank line:922 [37342.777477] WARNING: CPU: 4 PID: 14403 at drivers/gpu/drm/amd/amdgpu/../display/dc/dc_helper.c:254 generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777478] Modules linked in: uas usb_storage rfcomm ebtable_filter ebtables devlink ip6table_filter ip6_tables iptable_filter cmac bnep arc4 nls_ascii nls_cp437 vfat amdkfd fat snd_hda_codec_realtek snd_hda_codec_generic edac_mce_amd btusb btrtl amdgpu btbcm snd_hda_codec_hdmi btintel iwlmvm snd_usb_audio snd_hda_intel bluetooth kvm_amd snd_hda_codec snd_usbmidi_lib wmi_bmof mxm_wmi mac80211 snd_hda_core kvm uvcvideo videobuf2_vmalloc snd_hwdep videobuf2_memops snd_rawmidi jitterentropy_rng videobuf2_v4l2 videobuf2_common snd_seq_device chash iwlwifi irqbypass gpu_sched videodev snd_pcm crct10dif_pclmul ttm crc32_pclmul media drbg snd_timer evdev drm_kms_helper cfg80211 ansi_cprng ghash_clmulni_intel efi_pstore pcspkr drm snd k10temp ecdh_generic soundcore efivars rfkill crc16 sp5100_tco sg ccp [37342.777514] rng_core wmi pcc_cpufreq button acpi_cpufreq nct6775 hwmon_vid parport_pc ppdev lp parport efivarfs ip_tables x_tables autofs4 xfs btrfs xor zstd_decompress zstd_compress xxhash raid6_pq libcrc32c crc32c_generic hid_generic usbhid hid sd_mod crc32c_intel ahci xhci_pci libahci aesni_intel xhci_hcd aes_x86_64 crypto_simd libata igb cryptd glue_helper nvme usbcore scsi_mod i2c_piix4 i2c_algo_bit nvme_core dca usb_common gpio_amdpt gpio_generic [37342.777542] CPU: 4 PID: 14403 Comm: kworker/4:1 Tainted: GW 4.19.0-rc3-amd64 #1 Debian 4.19~rc3-1~exp1 [37342.777542] Hardware name: To Be Filled By O.E.M. To Be Filled By O.E.M./X370 Taichi, BIOS L4.64 04/03/2018 [37342.777558] Workqueue: events drm_mode_rmfb_work_fn [drm] [37342.777615] RIP: 0010:generic_reg_wait+0xe7/0x160 [amdgpu] [37342.777617] Code: 44 24 58 8b 54 24 48 89 de 44 89 4c 24 08 48 8b 4c 24 50 48 c7 c7 20 9d b5 c1 e8 64 e6 f0 fe 83 7d 18 01 44 8b 4c 24 08 74 02 <0f> 0b 48 83 c4 10 44 89 c8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 41 0f [37342.777618] RSP: 0018:a2ae81b9ba20 EFLAGS: 00010297 [37342.777620] RAX: RBX: 000a RCX: [37342.777621] RDX: RSI: 93d74eb166a8 RDI: 93d74eb166a8 [37342.777622] RBP: 93d746439180 R08: R09: 00010200 [37342.777623] R10: 0720072007200720 R11: 0720073207320739 R12: 0bb9 [37342.777624] R13: 51e2 R14: 0001 R15: [37342.777625] FS: () GS:93d74eb0() knlGS: [37342.777626] CS: 0010 DS: ES: CR0: 80050033 [37342.777627] CR2: 558f62bfa9d0 CR3: 0003f2c38000 CR4: 003406e0 [37342.777628] Call Trace: [37342.777695] dce110_stream_encoder_dp_blank+0x12c/0x1a0 [amdgpu] [37342.54] core_link_disable_stream+0x54/0x220 [amdgpu] [37342.777813] dce110_reset_hw_ctx_wrap+0xc1/0x1e0 [amdgpu] [37342.777872] dce110_apply_ctx_to_hw+0x45/0x650 [amdgpu] [37342.777928] ? dc_remove_plane_from_context+0x1fc/0x240 [amdgpu] [37342.777985] dc_commit_state+0x2c6/0x520 [amdgpu] [37342.778047] amdgpu_dm_atomic_commit_tail+0x37a/0xd80 [amdgpu] [37342.778052] ? __wake_up_common_lock+0x89/0xc0 [37342.778054] ? _cond_resched+0x15/0x30 [37342.778056] ? wait_for_completion_timeout+0x3b/0x1a0 [37342.778117] ? amdgpu_dm_atomic_commit_tail+0xd80/0xd80 [amdgpu] [37342.778126] commit_tail+0x3d/0x70 [drm_kms_helper] [37342.778133] drm_atomic_helper_commit+0xb4/0x120 [drm_kms_helper] [37342.778148] drm_framebuffer_remove+0x361/0x410 [drm] [37342.778164] drm_mode_rmfb_work_fn+0x4f/0x60 [drm] [37342.778167] process_one_work+0x1a7/0x360 [37342.778169] worker_thread+0x30/0x390 [37342.778171] ? pwq_unbound_release_workfn+0xd0/0xd0 [37342.778173] kthread+0x112/0x130 [37342.778175] ? kthread_bind+0x30/0x30 [37342.778177] ret_from_fork+0x22/0x40 [37342.778179] ---[ end trace 3d987dd66a59ffb4 ]--- OS: Debian testing, kernel 4.19~rc3-1~exp1 GPU: Sapphire Pulse Vega 56. amdgpu firmware: 20180825+dfsg-1 -- You are receiving this mail because: You are the assignee for the bug.
[Bug 107946] AMDGPU regression, multi-head not working on 4.18, 4.19RC3, but does on 4.16
https://bugs.freedesktop.org/show_bug.cgi?id=107946 --- Comment #3 from Nicholas Kazlauskas --- Please post an Xorg log along with what distro/desktop environment you're using. It may also help if you can post another 4.19 dmesg log with drm.debug=6 in your bootline. -- 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 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #13 from Andrey Arapov (andrey.ara...@nixaid.com) --- Could you please try reverting this commit https://github.com/torvalds/linux/commit/e03fd3f300f6184c1264186a4c815e93bf658abb , rebuilding your kernel and let us know if it fixes your issue? Not sure if your problem is related to mine here https://github.com/Dunedan/mbp-2016-linux/issues/73#issuecomment-422397681 But it has helped in my case. -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141631|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141633|0 |1 is obsolete|| -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 107955] AMDGPU driver keeps reloading on hybrid graphics system causing stuttering.
https://bugs.freedesktop.org/show_bug.cgi?id=107955 Michel Dänzer changed: What|Removed |Added Attachment #141635|0 |1 is obsolete|| --- Comment #21 from Michel Dänzer --- Comment on attachment 141635 --> https://bugs.freedesktop.org/attachment.cgi?id=141635 Using libunwind Ransu, please try to get the information from your system the same way Mike did. Looks like he's running into a different issue which only happens using the Xorg modesetting driver. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Convert drm_atomic_helper_suspend/resume()
On Wed, Aug 01, 2018 at 01:37:05AM +0530, Souptick Joarder wrote: > convert drm_atomic_helper_suspend/resume() to use > drm_mode_config_helper_suspend/resume(). > > With this conversion, tegra_drm_fb_suspend() and > tegra_drm_fb_resume() wil not be used anymore. > Both of these functions can be removed. > > Also, in tegra_drm struct's member state will not be > used anymore. So this can be removed forever. > > Fixed one sparse warning. > > Signed-off-by: Souptick Joarder > Signed-off-by: Ajit Negi > --- > drivers/gpu/drm/tegra/drm.c | 20 ++-- > drivers/gpu/drm/tegra/drm.h | 4 > drivers/gpu/drm/tegra/fb.c | 24 +--- > 3 files changed, 3 insertions(+), 45 deletions(-) Applied, thanks. Thierry signature.asc Description: PGP signature ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 200695] Blank screen on RX 580 with amdgpu.dc=1 enabled (no displays detected)
https://bugzilla.kernel.org/show_bug.cgi?id=200695 --- Comment #14 from Claude Heiland-Allen (cla...@mathr.co.uk) --- I checked out linux v4.19-rc4 from git, then reverted that commit - no change, display goes blank about 5 seconds into boot. I noticed something else in the dmesg (it was there in 4.19-rc1,rc2,rc3,rc4,rc4 with reverted commit, but not earlier versions): [5.109572] amdgpu: [powerplay] Failed to retrieve minimum clocks. [5.109577] amdgpu: [powerplay] Error in phm_get_clock_info [5.109627] [drm] DM_PPLIB: values for Engine clock [5.109629] [drm] DM_PPLIB: 30 [5.109631] [drm] DM_PPLIB: 60 [5.109632] [drm] DM_PPLIB: 90 [5.109633] [drm] DM_PPLIB: 1145000 [5.109634] [drm] DM_PPLIB: 1215000 [5.109636] [drm] DM_PPLIB: 1257000 [5.109637] [drm] DM_PPLIB: 130 [5.109638] [drm] DM_PPLIB: 1366000 [5.109640] [drm] DM_PPLIB: Validation clocks: [5.109641] [drm] DM_PPLIB:engine_max_clock: 136600 [5.109642] [drm] DM_PPLIB:memory_max_clock: 20 [5.109644] [drm] DM_PPLIB:level : 8 [5.109646] [drm] DM_PPLIB: values for Memory clock [5.109647] [drm] DM_PPLIB: 30 [5.109648] [drm] DM_PPLIB: 100 [5.109649] [drm] DM_PPLIB: 200 [5.109651] [drm] DM_PPLIB: Validation clocks: [5.109652] [drm] DM_PPLIB:engine_max_clock: 136600 [5.109653] [drm] DM_PPLIB:memory_max_clock: 20 [5.109655] [drm] DM_PPLIB:level : 8 [5.124083] [drm] Display Core initialized with v3.1.59! The last (largest) value for "engine clock" and "memory clock" are 10x the validation values for "engine clock max" and "memory clock max". I see in the amd/powerplay sources some values are in units of 10kHz, some in units of 1kHz(?) - maybe a conversion was missed somewhere? Or maybe the printout is totally normal and I know nothing :) The error message common to all kernels with amdgpu.dc=1 since 4.17 is: [5.256378] [drm] Cannot find any crtc or sizes -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: > Hi, Greg > > Can you pick up the patch? Nope: $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) David Airlie (maintainer:DRM DRIVERS) dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) linux-ker...@vger.kernel.org (open list) why would I take thi when all of those others are the correct maintainers? Also, you only posted this 1 day ago. Please relax and give people time and a chance to review your patch. It is not instant. thanks, greg k-h ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Mon, Aug 27, 2018 at 9:18 AM, Shawn Guo wrote: > On Fri, Aug 17, 2018 at 10:24:06AM +0800, zhong jiang wrote: >> for_each_available_child_of_node will get and put the node properly, >> the following of_node_put will lead to the double put. So just >> remove it. >> >> Signed-off-by: zhong jiang > > Acked-by: Shawn Guo Shawn, I'm assuming you'll push this to drm-misc-next? You're the maintainer with commit rights after all. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On Tue, Sep 18, 2018 at 5:02 PM, Greg KH wrote: > On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: >> Hi, Greg >> >> Can you pick up the patch? > > Nope: > $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c > Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) > David Airlie (maintainer:DRM DRIVERS) > dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) > linux-ker...@vger.kernel.org (open list) > > why would I take thi when all of those others are the correct > maintainers? > > Also, you only posted this 1 day ago. Please relax and give people time > and a chance to review your patch. It is not instant. First submission was in August, acked by Shawn, but somehow they forgot to actually push the patch out. I pinged Shawn. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH libdrm] headers/README: fix/add link to drm-next
Signed-off-by: Eric Engestrom --- include/drm/README | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/drm/README b/include/drm/README index 521630db8b4c52749188..ea2320cc9e7728a9c08b 100644 --- a/include/drm/README +++ b/include/drm/README @@ -71,7 +71,7 @@ Note: One should not do _any_ changes to the files apart from the steps below. In order to update the files do the following: - Switch to a Linux kernel tree/branch which is not rebased. -For example: airlied/drm-next + For example: drm-next (https://cgit.freedesktop.org/drm/drm) - Install the headers via `make headers_install' to a separate location. - Copy the drm header[s] + git add + git commit. - Note: Your commit message must include: -- Cheers, Eric ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH libdrm] headers/README: fix/add link to drm-next
On Tue, Sep 18, 2018 at 04:24:37PM +0100, Eric Engestrom wrote: > Signed-off-by: Eric Engestrom Reviewed-by: Sean Paul > --- > include/drm/README | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/include/drm/README b/include/drm/README > index 521630db8b4c52749188..ea2320cc9e7728a9c08b 100644 > --- a/include/drm/README > +++ b/include/drm/README > @@ -71,7 +71,7 @@ Note: One should not do _any_ changes to the files apart > from the steps below. > > In order to update the files do the following: > - Switch to a Linux kernel tree/branch which is not rebased. > -For example: airlied/drm-next > + For example: drm-next (https://cgit.freedesktop.org/drm/drm) > - Install the headers via `make headers_install' to a separate location. > - Copy the drm header[s] + git add + git commit. > - Note: Your commit message must include: > -- > Cheers, > Eric > > ___ > dri-devel mailing list > dri-devel@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Sean Paul, Software Engineer, Google / Chromium OS ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
RE: [PATCH v3 0/5] drm: add support for Cadence MHDP DPI/DP bridge.
Got it. -depends on EXTCON=y || (EXTCON=m && DRM_ROCKCHIP=m) +depends on DRM_ROCKCHIP=m +select EXTCON Damian -Original Message- From: Heiko Stuebner Sent: Thursday, September 13, 2018 14:32 To: Damian Kos Cc: David Airlie ; Rob Herring ; Mark Rutland ; Archit Taneja ; Andrzej Hajda ; Laurent Pinchart ; Gustavo Padovan ; Maarten Lankhorst ; Sean Paul ; Sandy Huang ; Quentin Schulz ; dri-devel@lists.freedesktop.org; devicet...@vger.kernel.org; linux-ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org; linux-rockc...@lists.infradead.org; Przemyslaw Gaj ; Lukasz Tyrala ; Scott Telford ; Artur Jedrysek ; Piotr Sroka Subject: Re: [PATCH v3 0/5] drm: add support for Cadence MHDP DPI/DP bridge. EXTERNAL MAIL Am Dienstag, 28. August 2018, 12:24:43 CEST schrieb Damian Kos: > Hello! > > This is the series of patches that will add support for the Cadence's > DPI/DP bridge. Please note that this is a preliminary version of the > driver and there will be more patches in the future with updates, fixes and > improvements. > Please keep that in mind when looking at FIXME/TODO/XXX comments. > > Initially, MHDP driver was developed as a DRM bridge driver and was > planed to be placed in drivers/gpu/drm/bridge/mhdp.c. However, there > was already a driver for Cadence's DP controller developed by > RockChip, but that driver uses the different DRM framework and looks like a > part of a bigger system. > Both controllers (including firmware) are quite different internally > (MST/FEC/DSC support, link training done by driver, additional > commands, IRQ's > etc.) but they have similar register map, except for Framer/Streamer > (which is noticeably different), so they appear similar. > > The following patches contain: > - Moving common code to drivers/gpu/drm/bridge/cdns-mhdp-common.* and > modifying it a bit (mostly new prefixes for functions and data types) so it > can be used by two, higher level, drivers. > - Modifying existing RockChip's DP driver to use the common code after changes > made to it (use the new cdns_mhdp_device structure and new function names). > - Modifying DRM helpers a bit. Some are required for new driver, some are > updates from DP 1.2 to 1.3 or 1.4. > - Adding documentation for device tree bindings. > - Adding preliminary Cadence DPI/DP bridge driver. > > Some of the things that will be added later on include (but are not > limited > to): > - Support for Cadence SD0801 PHY (PHY's driver should be on the way by > now) > - MST support > - DSC support > - FEC support > - HDCP support with te Kconfig issue in patch5 fixed, this series tested on rk3288 (analogix-dp) and rk3399 (analogix-dp + cadence-dp) Everything seems to work that worked before. Tested-by: Heiko Stuebner ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
On 2018/9/18 23:02, Greg KH wrote: > On Tue, Sep 18, 2018 at 10:59:08PM +0800, zhong jiang wrote: >> Hi, Greg >> >> Can you pick up the patch? > Nope: > $ ./scripts/get_maintainer.pl --file drivers/gpu/drm/zte/zx_drm_drv.c > Shawn Guo (maintainer:DRM DRIVERS FOR ZTE ZX) > David Airlie (maintainer:DRM DRIVERS) > dri-devel@lists.freedesktop.org (open list:DRM DRIVERS FOR ZTE ZX) > linux-ker...@vger.kernel.org (open list) > > why would I take thi when all of those others are the correct > maintainers? > > Also, you only posted this 1 day ago. Please relax and give people time > and a chance to review your patch. It is not instant. No, I posted the patch a month ago. I have sent a ping. but It do not work. :-( . Thanks, zhong jiang > thanks, > > greg k-h > > . > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/tegra: Convert drm_atomic_helper_suspend/resume()
On Mon, Sep 10, 2018 at 12:16 PM Souptick Joarder wrote:
>
> On Mon, Aug 6, 2018 at 11:42 AM Souptick Joarder wrote:
> >
> > On Wed, Aug 1, 2018 at 1:37 AM, Souptick Joarder
> > wrote:
> > > convert drm_atomic_helper_suspend/resume() to use
> > > drm_mode_config_helper_suspend/resume().
> > >
> > > With this conversion, tegra_drm_fb_suspend() and
> > > tegra_drm_fb_resume() wil not be used anymore.
> > > Both of these functions can be removed.
> > >
> > > Also, in tegra_drm struct's member state will not be
> > > used anymore. So this can be removed forever.
> > >
> > > Fixed one sparse warning.
> > >
> > > Signed-off-by: Souptick Joarder
> > > Signed-off-by: Ajit Negi
> > > ---
> >
> > Any comment on this patch ?
>
> If no comment, can we get this patch in queue for 4.20 ?
David/ Daniel,
is this patch [1] good to go in 4.20 ?
[1] https://lkml.org/lkml/2018/7/31/839
> >
> > > drivers/gpu/drm/tegra/drm.c | 20 ++--
> > > drivers/gpu/drm/tegra/drm.h | 4
> > > drivers/gpu/drm/tegra/fb.c | 24 +---
> > > 3 files changed, 3 insertions(+), 45 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/tegra/drm.c b/drivers/gpu/drm/tegra/drm.c
> > > index a2bd587..9a0efce 100644
> > > --- a/drivers/gpu/drm/tegra/drm.c
> > > +++ b/drivers/gpu/drm/tegra/drm.c
> > > @@ -1212,31 +1212,15 @@ static int host1x_drm_remove(struct host1x_device
> > > *dev)
> > > static int host1x_drm_suspend(struct device *dev)
> > > {
> > > struct drm_device *drm = dev_get_drvdata(dev);
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - drm_kms_helper_poll_disable(drm);
> > > - tegra_drm_fb_suspend(drm);
> > > -
> > > - tegra->state = drm_atomic_helper_suspend(drm);
> > > - if (IS_ERR(tegra->state)) {
> > > - tegra_drm_fb_resume(drm);
> > > - drm_kms_helper_poll_enable(drm);
> > > - return PTR_ERR(tegra->state);
> > > - }
> > >
> > > - return 0;
> > > + return drm_mode_config_helper_suspend(drm);
> > > }
> > >
> > > static int host1x_drm_resume(struct device *dev)
> > > {
> > > struct drm_device *drm = dev_get_drvdata(dev);
> > > - struct tegra_drm *tegra = drm->dev_private;
> > >
> > > - drm_atomic_helper_resume(drm, tegra->state);
> > > - tegra_drm_fb_resume(drm);
> > > - drm_kms_helper_poll_enable(drm);
> > > -
> > > - return 0;
> > > + return drm_mode_config_helper_resume(drm);
> > > }
> > > #endif
> > >
> > > diff --git a/drivers/gpu/drm/tegra/drm.h b/drivers/gpu/drm/tegra/drm.h
> > > index 92d2487..1012335 100644
> > > --- a/drivers/gpu/drm/tegra/drm.h
> > > +++ b/drivers/gpu/drm/tegra/drm.h
> > > @@ -60,8 +60,6 @@ struct tegra_drm {
> > > unsigned int pitch_align;
> > >
> > > struct tegra_display_hub *hub;
> > > -
> > > - struct drm_atomic_state *state;
> > > };
> > >
> > > struct tegra_drm_client;
> > > @@ -186,8 +184,6 @@ struct drm_framebuffer *tegra_fb_create(struct
> > > drm_device *drm,
> > > void tegra_drm_fb_free(struct drm_device *drm);
> > > int tegra_drm_fb_init(struct drm_device *drm);
> > > void tegra_drm_fb_exit(struct drm_device *drm);
> > > -void tegra_drm_fb_suspend(struct drm_device *drm);
> > > -void tegra_drm_fb_resume(struct drm_device *drm);
> > >
> > > extern struct platform_driver tegra_display_hub_driver;
> > > extern struct platform_driver tegra_dc_driver;
> > > diff --git a/drivers/gpu/drm/tegra/fb.c b/drivers/gpu/drm/tegra/fb.c
> > > index 4c22cdd..b947e82 100644
> > > --- a/drivers/gpu/drm/tegra/fb.c
> > > +++ b/drivers/gpu/drm/tegra/fb.c
> > > @@ -356,7 +356,7 @@ static void tegra_fbdev_exit(struct tegra_fbdev
> > > *fbdev)
> > > /* Undo the special mapping we made in fbdev probe. */
> > > if (bo && bo->pages) {
> > > vunmap(bo->vaddr);
> > > - bo->vaddr = 0;
> > > + bo->vaddr = NULL;
> > > }
> > >
> > > drm_framebuffer_remove(fbdev->fb);
> > > @@ -412,25 +412,3 @@ void tegra_drm_fb_exit(struct drm_device *drm)
> > > tegra_fbdev_exit(tegra->fbdev);
> > > #endif
> > > }
> > > -
> > > -void tegra_drm_fb_suspend(struct drm_device *drm)
> > > -{
> > > -#ifdef CONFIG_DRM_FBDEV_EMULATION
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - console_lock();
> > > - drm_fb_helper_set_suspend(&tegra->fbdev->base, 1);
> > > - console_unlock();
> > > -#endif
> > > -}
> > > -
> > > -void tegra_drm_fb_resume(struct drm_device *drm)
> > > -{
> > > -#ifdef CONFIG_DRM_FBDEV_EMULATION
> > > - struct tegra_drm *tegra = drm->dev_private;
> > > -
> > > - console_lock();
> > > - drm_fb_helper_set_suspend(&tegra->fbdev->base, 0);
> > > - console_unlock();
> > > -#endif
> > > -}
> > > --
> > > 1.9.1
> > >
___
dri-devel mailing list
dri-dev
Re: [PATCH] gpu: do not double put device node in zx_drm_probe
Hi, Greg
Can you pick up the patch?
Thanks,
zhong jiang
On 2018/8/17 10:24, zhong jiang wrote:
> for_each_available_child_of_node will get and put the node properly,
> the following of_node_put will lead to the double put. So just
> remove it.
>
> Signed-off-by: zhong jiang
> ---
> drivers/gpu/drm/zte/zx_drm_drv.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/zte/zx_drm_drv.c
> b/drivers/gpu/drm/zte/zx_drm_drv.c
> index 6f4205e8..d7b9870 100644
> --- a/drivers/gpu/drm/zte/zx_drm_drv.c
> +++ b/drivers/gpu/drm/zte/zx_drm_drv.c
> @@ -161,10 +161,8 @@ static int zx_drm_probe(struct platform_device *pdev)
> if (ret)
> return ret;
>
> - for_each_available_child_of_node(parent, child) {
> + for_each_available_child_of_node(parent, child)
> component_match_add(dev, &match, compare_of, child);
> - of_node_put(child);
> - }
>
> return component_master_add_with_match(dev, &zx_drm_master_ops, match);
> }
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v5 0/8] Add Plane Color Properties
On Sun, Sep 16, 2018 at 01:45:23PM +0530, Uma Shankar wrote: > This is how a typical display color hardware pipeline looks like: > +---+ > |RAM| > | +--++-++-+ | > | | FB 1 || FB 2 || FB N| | > | +--++-++-+ | > +---+ >| Plane Color Hardware Block | > ++ > | +---v-+ +---v---+ +---v--+ | > | | Plane A | | Plane B | | Plane N | | > | | DeGamma | | Degamma | | Degamma | | > | +---+-+ +---+---+ +---+--+ | > | | | || > | +---v-+ +---v---+ +---v--+ | > | |Plane A | | Plane B | | Plane N | | > | |CSC/CTM | | CSC/CTM | | CSC/CTM | | > | +---+-+ ++--+ ++-+ | > | | | | | > | +---v-+ +v--+ +v-+ | > | | Plane A | | Plane B | | Plane N | | > | | Gamma | | Gamma | | Gamma| | > | +---+-+ ++--+ ++-+ | > | | | | | > ++ > +--v--v---v---| > || || > || Pipe Blender|| > +++ > ||| > |+---v--+ | > || Pipe DeGamma| | > || | | > |+---+--+ | > ||Pipe Color | > |+---v--+ Hardware| > || Pipe CSC/CTM| | > || | | > |+---+--+ | > ||| > |+---v--+ | > || Pipe Gamma | | > || | | > |+---+--+ | > ||| > +-+ > | > v >Pipe Output > > This patch series adds properties for plane color features. It adds > properties for degamma used to linearize data, CSC used for gamut > conversion, and gamma used to again non-linearize data as per panel > supported color space. These can be utilize by user space to convert > planes from one format to another, one color space to another etc. > > Usersapce can take smart blending decisions and utilize these hardware > supported plane color features to get accurate color profile. The same > can help in consistent color quality from source to panel taking > advantage of advanced color features in hardware. > > These patches just add the property interfaces and enable helper > functions. > > This series adds Intel Gen9 specific plane gamma feature. We can > build up and add other platform/hardware specific implementation > on top of this series > > Note: This is just to get a design feedback whether these interfaces > look ok. Based on community feedback on interfaces, we will implement > IGT tests to validate plane color features. This is un-tested currently. > > Userspace implementation using these properties have been done in drm > hwcomposer by "Alexandru-Cosmin Gheorghe alexandru-cosmin.gheor...@arm.com" > from ARM. A merge request has been opened by Alexandru for drm_hwcomposer, > implementing the property changes for the same. Please review that as well: > https://gitlab.freedesktop.org/drm-hwcomposer/drm-hwcomposer/merge_requests/25 > Just heads-up I just pushed a v2 for that. > v2: Dropped legacy gamma table for plane as suggested by Maarten. Added > Gen9/BDW plane gamma feature and rebase on tot. > > v3: Added a new drm_color_lut_ext structure to accommodate 32 bit precision > entries, pointed to by Brian, Starkey for HDR usecases. Addressed Sean,Paul > comments and moved plane color properties to drm_plane instead of > mode_config. Added property documentation as suggested by Daniel, Vetter. > Fixed a rebase fumble which occurred in v2, pointed by Emil Velikov. > > v4: Rebase > > v5: Added "Display Color Hardware Pipeline" flow to kernel > documentation as suggested by "Ville Syrjala" and "Brian Starkey". > Moved the property creation to drm_color_mgmt.c file to consolidate > all color operations at one place. Addressed Alexandru's review comments. > > Uma Shankar (8): > drm: Add Enhanced Gamma LUT precision structure > drm: Add Plane Degamma properties > drm: Add Plane CTM property > drm: Add Plane Gamma properties > drm: Define helper function for plane color enabling > d
Re: [RFC v5 2/8] drm: Add Plane Degamma properties
Hi,
On Sun, Sep 16, 2018 at 01:45:25PM +0530, Uma Shankar wrote:
> Add Plane Degamma as a blob property and plane degamma size as
> a range property.
>
> v2: Rebase
>
> v3: Fixed Sean, Paul's review comments. Moved the property from
> mode_config to drm_plane. Created a helper function to instantiate
> these properties and removed from drm_mode_create_standard_properties
> Added property documentation as suggested by Daniel, Vetter.
>
> v4: Rebase
>
> v5: Added "Display Color Hardware Pipeline" flow to kernel
> documentation as suggested by "Ville Syrjala" and "Brian Starkey".
> Moved the property creation to drm_color_mgmt.c file to consolidate
> all color operations at one place.
>
> Signed-off-by: Uma Shankar
> Reviewed-by: Alexandru Gheorghe
> ---
> Documentation/gpu/drm-kms.rst | 90
> +
> drivers/gpu/drm/drm_atomic.c| 13 ++
> drivers/gpu/drm/drm_atomic_helper.c | 6 +++
> drivers/gpu/drm/drm_color_mgmt.c| 44 --
> include/drm/drm_plane.h | 24 ++
> 5 files changed, 174 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index f8f5bf1..253d546 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -551,12 +551,102 @@ Plane Composition Properties
> Color Management Properties
> ---
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware blocks
> +can help with this. Once the Data is blended, similar color processing
> +can be done on blended output using pipe color hardware blocks.
> +
> +DRM Properties have been created to define and expose all these
> +hardware blocks to userspace. A userspace application (compositor
> +or any color app) can use these interfaces and define policies to
> +efficiently use the display hardware for such color operations.
> +
> +Pipe Color Management Properties
> +-
> +
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :doc: overview
>
> .. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> :export:
>
> +Plane Color Management Properties
> +-
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: Plane Color Properties
> +
> +.. kernel-doc:: drivers/gpu/drm/drm_color_mgmt.c
> + :doc: export
> +
> Tile Group Property
> ---
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index d0478ab..e716614 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -857,6 +857,8 @@ static int drm_atomic_plane_set_property(struct drm_plane
> *plane,
> {
> struct drm_device *dev = plane->dev;
> struc
[PATCH 1/2] drm/scheduler: add a current job field to scheduler
Which points to the job running on the hardware. This is
useful when we need to access the currently executing job
from the scheduler.
Signed-off-by: Nayan Deshmukh
---
drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
include/drm/gpu_scheduler.h| 2 ++
2 files changed, 13 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 9ca741f3a0bc..0e6ccc8243db 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -189,6 +189,7 @@ static void drm_sched_job_finish(struct work_struct *work)
struct drm_sched_job *s_job = container_of(work, struct drm_sched_job,
finish_work);
struct drm_gpu_scheduler *sched = s_job->sched;
+ struct drm_sched_job *next;
/*
* Canceling the timeout without removing our job from the ring mirror
@@ -201,10 +202,10 @@ static void drm_sched_job_finish(struct work_struct *work)
spin_lock(&sched->job_list_lock);
/* queue TDR for next job */
+ next = list_next_entry(s_job, node);
+ sched->curr_job = next;
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_is_last(&s_job->node, &sched->ring_mirror_list)) {
- struct drm_sched_job *next = list_next_entry(s_job, node);
-
if (!dma_fence_is_signaled(&next->s_fence->finished))
schedule_delayed_work(&next->work_tdr, sched->timeout);
}
@@ -233,10 +234,12 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
spin_lock(&sched->job_list_lock);
list_add_tail(&s_job->node, &sched->ring_mirror_list);
- if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
- list_first_entry_or_null(&sched->ring_mirror_list,
-struct drm_sched_job, node) == s_job)
- schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ if (list_first_entry_or_null(&sched->ring_mirror_list,
+ struct drm_sched_job, node) == s_job) {
+ if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
+ schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ sched->curr_job = s_job;
+ }
spin_unlock(&sched->job_list_lock);
}
@@ -316,6 +319,8 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ if (s_job)
+ sched->curr_job = s_job;
list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, node) {
struct drm_sched_fence *s_fence = s_job->s_fence;
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index daec50f887b3..07e776b1ca42 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -252,6 +252,7 @@ struct drm_sched_backend_ops {
* @timeout: the time after which a job is removed from the scheduler.
* @name: name of the ring for which this scheduler is being used.
* @sched_rq: priority wise array of run queues.
+ * @curr_job: points to the job currently running on the hardware
* @wake_up_worker: the wait queue on which the scheduler sleeps until a job
* is ready to be scheduled.
* @job_scheduled: once @drm_sched_entity_do_release is called the scheduler
@@ -274,6 +275,7 @@ struct drm_gpu_scheduler {
longtimeout;
const char *name;
struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_MAX];
+ struct drm_sched_job*curr_job;
wait_queue_head_t wake_up_worker;
wait_queue_head_t job_scheduled;
atomic_thw_rq_count;
--
2.14.3
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] drm/scheduler: remove timeout work_struct from drm_sched_job
having a delayed work item per job is redundant as we only need one
per scheduler to track the time out the currently executing job.
Signed-off-by: Nayan Deshmukh
Suggested-by: Christian König
---
drivers/gpu/drm/scheduler/sched_main.c | 16 +---
include/drm/gpu_scheduler.h| 6 +++---
2 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/scheduler/sched_main.c
b/drivers/gpu/drm/scheduler/sched_main.c
index 0e6ccc8243db..f213b5c7f718 100644
--- a/drivers/gpu/drm/scheduler/sched_main.c
+++ b/drivers/gpu/drm/scheduler/sched_main.c
@@ -198,7 +198,7 @@ static void drm_sched_job_finish(struct work_struct *work)
* manages to find this job as the next job in the list, the fence
* signaled check below will prevent the timeout to be restarted.
*/
- cancel_delayed_work_sync(&s_job->work_tdr);
+ cancel_delayed_work_sync(&sched->work_tdr);
spin_lock(&sched->job_list_lock);
/* queue TDR for next job */
@@ -207,7 +207,7 @@ static void drm_sched_job_finish(struct work_struct *work)
if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
!list_is_last(&s_job->node, &sched->ring_mirror_list)) {
if (!dma_fence_is_signaled(&next->s_fence->finished))
- schedule_delayed_work(&next->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
}
/* remove job from ring_mirror_list */
list_del(&s_job->node);
@@ -237,7 +237,7 @@ static void drm_sched_job_begin(struct drm_sched_job *s_job)
if (list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node) == s_job) {
if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
sched->curr_job = s_job;
}
spin_unlock(&sched->job_list_lock);
@@ -245,8 +245,10 @@ static void drm_sched_job_begin(struct drm_sched_job
*s_job)
static void drm_sched_job_timedout(struct work_struct *work)
{
- struct drm_sched_job *job = container_of(work, struct drm_sched_job,
-work_tdr.work);
+ struct drm_gpu_scheduler *sched = container_of(work,
+ struct drm_gpu_scheduler,
+ work_tdr.work);
+ struct drm_sched_job *job = sched->curr_job;
job->sched->ops->timedout_job(job);
}
@@ -318,7 +320,7 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler *sched)
s_job = list_first_entry_or_null(&sched->ring_mirror_list,
struct drm_sched_job, node);
if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
- schedule_delayed_work(&s_job->work_tdr, sched->timeout);
+ schedule_delayed_work(&sched->work_tdr, sched->timeout);
if (s_job)
sched->curr_job = s_job;
@@ -389,7 +391,6 @@ int drm_sched_job_init(struct drm_sched_job *job,
INIT_WORK(&job->finish_work, drm_sched_job_finish);
INIT_LIST_HEAD(&job->node);
- INIT_DELAYED_WORK(&job->work_tdr, drm_sched_job_timedout);
return 0;
}
@@ -580,6 +581,7 @@ int drm_sched_init(struct drm_gpu_scheduler *sched,
INIT_LIST_HEAD(&sched->ring_mirror_list);
spin_lock_init(&sched->job_list_lock);
atomic_set(&sched->hw_rq_count, 0);
+ INIT_DELAYED_WORK(&sched->work_tdr, drm_sched_job_timedout);
atomic_set(&sched->num_jobs, 0);
atomic64_set(&sched->job_id_count, 0);
diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
index 07e776b1ca42..9d50d7f3eaa4 100644
--- a/include/drm/gpu_scheduler.h
+++ b/include/drm/gpu_scheduler.h
@@ -175,8 +175,6 @@ struct drm_sched_fence *to_drm_sched_fence(struct dma_fence
*f);
* finished to remove the job from the
* @drm_gpu_scheduler.ring_mirror_list.
* @node: used to append this struct to the
@drm_gpu_scheduler.ring_mirror_list.
- * @work_tdr: schedules a delayed call to @drm_sched_job_timedout after the
timeout
- *interval is over.
* @id: a unique id assigned to each job scheduled on the scheduler.
* @karma: increment on every hang caused by this job. If this exceeds the hang
* limit of the scheduler then the job is marked guilty and will not
@@ -195,7 +193,6 @@ struct drm_sched_job {
struct dma_fence_cb finish_cb;
struct work_struct finish_work;
struct list_headnode;
- struct delayed_work work_tdr;
uint64_tid;
atomic_tkarma;
enum drm_sched_priority s_priority;
@@ -260,6 +257,8 @@ struct
[PATCH v7 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_display.c | 49
drivers/gpu/drm/i915/intel_dp.c | 5
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..75afd53590b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = &connector->base.display_info;
- int bpp = pipe_config->pipe_bpp;
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
- /* Don't use an invalid EDID bpc value */
- if (info->bpc != 0 && info->bpc * 3 < bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
max of %d\n",
- bpp, info->bpc * 3);
- pipe_config->pipe_bpp = info->bpc * 3;
+ if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+ conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+ return;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (info->bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ switch (conn_state->max_bpc) {
+ case 8:
+ case 9:
+ pipe_config->pipe_bpp = 8 * 3;
+ break;
+ case 10:
+ case 11:
+ pipe_config->pipe_bpp = 10 * 3;
+ break;
+ case 12:
+ case 13:
+ case 14:
+ case 15:
+ pipe_config->pipe_bpp = 12 * 3;
+ break;
+ case 16:
+ pipe_config->pipe_bpp = 16 * 3;
+ break;
+ default:
+ break;
}
+
+ DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
}
static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != &crtc->base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ connected_sink_max_bpp(connector_state, pipe_config);
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+ drm_connector_attach_max_bpc_property(connector, 8, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_N
[PATCH v7 1/2] drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 24
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 20
5 files changed, 85 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..49078bb500fd 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
{
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+ struct drm_display_info *info = &connector->display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ if (connector->max_bpc_property) {
+ if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
+ /* Don't use an invalid EDID bpc value */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested "
+"display bpp (was %d) to EDID reported
"
+"max of %d\n", connector->base.id,
+connector->name,
+state->max_requested_bpc, info->bpc);
+ state->max_bpc = info->bpc;
+ } else if (info->bpc != 0) {
+ state->max_bpc = state->max_requested_bpc;
+ } else {
+ /* Clamp bpc to 8 on screens witout EDID 1.4 */
+ DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested "
+"display bpp (was %d) to default limit
"
+"of 24\n", connector->base.id,
+connector->name,
state->max_requested_bpc);
+ state->max_bpc = 8;
+ }
+ } else {
+ state->max_bpc = info->bpc ? info->bpc : 8;
+ }
+
if (state->crtc)
crtc_state = drm_atomic_get_existing_crtc_state(state->state,
state->crtc);
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->max_requested_bpc !=
+ new_connector_state->max_requested_bpc)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return set_out_fence_for_connector(state->state, connector,
fence_ptr);
+ } else if (property == connector->max_bpc_property) {
+ state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(con
Re: [PATCH v6 1/2] drm: Add connector property to limit max bpc
On Mon, Sep 17, 2018 at 09:52:08PM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 24
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 34 ++
> include/drm/drm_connector.h | 20
> 5 files changed, 86 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 7ada75919756..fa9996deb132 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = &connector->display_info;
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -400,6 +401,29 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + if (connector->max_bpc_property) {
> + if (info->bpc != 0 && info->bpc < state->max_requested_bpc) {
> + /* Don't use an invalid EDID bpc value */
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
> + " display bpp (was %d) to EDID
> reported"
> + "max of %d\n", connector->base.id,
> + connector->name,
> + state->max_requested_bpc, info->bpc);
> + state->max_bpc = info->bpc;
> + } else if (info->bpc != 0) {
> + state->max_bpc = state->max_requested_bpc;
> + } else {
> + /* Clamp bpc to 8 on screens witout EDID 1.4 */
> + DRM_DEBUG_ATOMIC("[CONNECTOR:%d:%s] Clamping requested"
> + " display bpp (was %d) to default
> limit"
> + " of 24\n", connector->base.id,
> + connector->name,
> state->max_requested_bpc);
> + state->max_bpc = 8;
> + }
> + } else {
> + state->max_bpc = info->bpc ? info->bpc : 8;
> + }
Something like
max_bpc = info->bpc ?: 8;
if (max_bpc_prop)
max_bpc = min(max_bpc, max_requested_bpc);
for short?
Not quite sure the 8bpc fallback should be here. Maybe it should be in
the edid code instead? Though I guess we want something for edidless
displays too so maybe this is fine.
> +
> if (state->crtc)
> crtc_state = drm_atomic_get_existing_crtc_state(state->state,
> state->crtc);
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -
[PATCH] headers: Sync with drm-next
Generated using make headers_install from the drm-next
tree - git://anongit.freedesktop.org/drm/drm
branch - drm-next
commit - 2dc7bad71cd310dc94d1c9907909324dd2b0618f
The changes were as follows :-
core: (drm.h, drm_fourcc.h, drm_mode.h)
- Added client capabilities for ASPECT_RATIO and WRITEBACK_CONNECTORS
- Added Arm AFBC modifiers
- Added BROADCOM's SAND and UIF modifiers
- Added Qualcomm's modifiers
- Added some picture aspect ratio and content type options
- Added some drm mode flags
- Added writeback connector id
amdgpu:
- Added GEM domain mask
- Added some GEM flags
- Added some hardware ip flags
- Added chunk id and IB fence.
- Added some query ids
i915:
-Added an IOCTL (I915_PARAM_MMAP_GTT_COHERENT)
qxl:
- Minor changes
radeon:
- Removed RADEON_TILING_R600_NO_SCANOUT
sis:
- Changed the data type of some structure members from 'int' to 'long'.
tegra:
- Added some comments about struct drm_tegra* members
- Modified DRM_IOCTL_TEGRA_CLOSE_CHANNEL
vc4:
- Added some members for 'struct drm_vc4_submit_cl'
via:
- Removed inclusion of 'via_drmclient.h'.
vmwgfx:
- Added some DRM_VMW_* macros
- Renamed some structures like 'drm_vmw_dmabuf_rep' to 'drm_vmw_bo_rep', etc
- Added some new DRM_VMW_GB_SURFACE related structures and unions
Signed-off-by: Ayan Kumar halder
---
Dropped changes to nouveau_drm.h as it causes compilation failure
include/drm/amdgpu_drm.h | 47 -
include/drm/drm.h| 16 ++
include/drm/drm_fourcc.h | 215 +
include/drm/drm_mode.h | 35 +++-
include/drm/i915_drm.h | 22 +++
include/drm/qxl_drm.h| 2 -
include/drm/radeon_drm.h | 1 -
include/drm/sis_drm.h| 8 +-
include/drm/tegra_drm.h | 492 ++-
include/drm/vc4_drm.h| 13 +-
include/drm/via_drm.h| 1 -
include/drm/vmwgfx_drm.h | 166
12 files changed, 957 insertions(+), 61 deletions(-)
diff --git a/include/drm/amdgpu_drm.h b/include/drm/amdgpu_drm.h
index c363b67..1ceec56 100644
--- a/include/drm/amdgpu_drm.h
+++ b/include/drm/amdgpu_drm.h
@@ -72,12 +72,41 @@ extern "C" {
#define DRM_IOCTL_AMDGPU_FENCE_TO_HANDLE DRM_IOWR(DRM_COMMAND_BASE +
DRM_AMDGPU_FENCE_TO_HANDLE, union drm_amdgpu_fence_to_handle)
#define DRM_IOCTL_AMDGPU_SCHED DRM_IOW(DRM_COMMAND_BASE +
DRM_AMDGPU_SCHED, union drm_amdgpu_sched)
+/**
+ * DOC: memory domains
+ *
+ * %AMDGPU_GEM_DOMAIN_CPU System memory that is not GPU accessible.
+ * Memory in this pool could be swapped out to disk if there is pressure.
+ *
+ * %AMDGPU_GEM_DOMAIN_GTT GPU accessible system memory, mapped into the
+ * GPU's virtual address space via gart. Gart memory linearizes non-contiguous
+ * pages of system memory, allows GPU access system memory in a linezrized
+ * fashion.
+ *
+ * %AMDGPU_GEM_DOMAIN_VRAM Local video memory. For APUs, it is memory
+ * carved out by the BIOS.
+ *
+ * %AMDGPU_GEM_DOMAIN_GDS Global on-chip data storage used to share data
+ * across shader threads.
+ *
+ * %AMDGPU_GEM_DOMAIN_GWS Global wave sync, used to synchronize the
+ * execution of all the waves on a device.
+ *
+ * %AMDGPU_GEM_DOMAIN_OA Ordered append, used by 3D or Compute engines
+ * for appending data.
+ */
#define AMDGPU_GEM_DOMAIN_CPU 0x1
#define AMDGPU_GEM_DOMAIN_GTT 0x2
#define AMDGPU_GEM_DOMAIN_VRAM 0x4
#define AMDGPU_GEM_DOMAIN_GDS 0x8
#define AMDGPU_GEM_DOMAIN_GWS 0x10
#define AMDGPU_GEM_DOMAIN_OA 0x20
+#define AMDGPU_GEM_DOMAIN_MASK (AMDGPU_GEM_DOMAIN_CPU | \
+AMDGPU_GEM_DOMAIN_GTT | \
+AMDGPU_GEM_DOMAIN_VRAM | \
+AMDGPU_GEM_DOMAIN_GDS | \
+AMDGPU_GEM_DOMAIN_GWS | \
+AMDGPU_GEM_DOMAIN_OA)
/* Flag that CPU access will be required for the case of VRAM domain */
#define AMDGPU_GEM_CREATE_CPU_ACCESS_REQUIRED (1 << 0)
@@ -95,6 +124,10 @@ extern "C" {
#define AMDGPU_GEM_CREATE_VM_ALWAYS_VALID (1 << 6)
/* Flag that BO sharing will be explicitly synchronized */
#define AMDGPU_GEM_CREATE_EXPLICIT_SYNC(1 << 7)
+/* Flag that indicates allocating MQD gart on GFX9, where the mtype
+ * for the second page onward should be set to NC.
+ */
+#define AMDGPU_GEM_CREATE_MQD_GFX9 (1 << 8)
struct drm_amdgpu_gem_create_in {
/** the requested memory size */
@@ -473,7 +506,8 @@ struct drm_amdgpu_gem_va {
#define AMDGPU_HW_IP_UVD_ENC 5
#define AMDGPU_HW_IP_VCN_DEC 6
#define AMDGPU_HW_IP_VCN_ENC 7
-#define AMDGPU_HW_IP_NUM 8
+#define AMDGPU_HW_IP_VCN_JPEG 8
+#define AMDGPU_HW_IP_NUM 9
#define AMDGPU_HW_IP_INSTANCE_MAX_COUNT 1
@@ -482,6 +516,7 @@ struct drm_amdgpu_gem_va {
#defin
Re: [PATCH 1/2] drm/scheduler: add a current job field to scheduler
Am 18.09.2018 um 18:17 schrieb Nayan Deshmukh:
> Which points to the job running on the hardware. This is
> useful when we need to access the currently executing job
> from the scheduler.
That should be identical to
list_first_entry_or_null(&sched->ring_mirror_list), doesn't it?
Regards,
Christian.
>
> Signed-off-by: Nayan Deshmukh
> ---list_first_entry_or_null(&sched->ring_mirror_list
>
> drivers/gpu/drm/scheduler/sched_main.c | 17 +++--
> include/drm/gpu_scheduler.h| 2 ++
> 2 files changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/scheduler/sched_main.c
> b/drivers/gpu/drm/scheduler/sched_main.c
> index 9ca741f3a0bc..0e6ccc8243db 100644
> --- a/drivers/gpu/drm/scheduler/sched_main.c
> +++ b/drivers/gpu/drm/scheduler/sched_main.c
> @@ -189,6 +189,7 @@ static void drm_sched_job_finish(struct work_struct *work)
> struct drm_sched_job *s_job = container_of(work, struct drm_sched_job,
> finish_work);
> struct drm_gpu_scheduler *sched = s_job->sched;
> + struct drm_sched_job *next;
>
> /*
>* Canceling the timeout without removing our job from the ring mirror
> @@ -201,10 +202,10 @@ static void drm_sched_job_finish(struct work_struct
> *work)
>
> spin_lock(&sched->job_list_lock);
> /* queue TDR for next job */
> + next = list_next_entry(s_job, node);
> + sched->curr_job = next;
> if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> !list_is_last(&s_job->node, &sched->ring_mirror_list)) {
> - struct drm_sched_job *next = list_next_entry(s_job, node);
> -
> if (!dma_fence_is_signaled(&next->s_fence->finished))
> schedule_delayed_work(&next->work_tdr, sched->timeout);
> }
> @@ -233,10 +234,12 @@ static void drm_sched_job_begin(struct drm_sched_job
> *s_job)
>
> spin_lock(&sched->job_list_lock);
> list_add_tail(&s_job->node, &sched->ring_mirror_list);
> - if (sched->timeout != MAX_SCHEDULE_TIMEOUT &&
> - list_first_entry_or_null(&sched->ring_mirror_list,
> - struct drm_sched_job, node) == s_job)
> - schedule_delayed_work(&s_job->work_tdr, sched->timeout);
> + if (list_first_entry_or_null(&sched->ring_mirror_list,
> + struct drm_sched_job, node) == s_job) {
> + if (sched->timeout != MAX_SCHEDULE_TIMEOUT)
> + schedule_delayed_work(&s_job->work_tdr, sched->timeout);
> + sched->curr_job = s_job;
> + }
> spin_unlock(&sched->job_list_lock);
> }
>
> @@ -316,6 +319,8 @@ void drm_sched_job_recovery(struct drm_gpu_scheduler
> *sched)
>struct drm_sched_job, node);
> if (s_job && sched->timeout != MAX_SCHEDULE_TIMEOUT)
> schedule_delayed_work(&s_job->work_tdr, sched->timeout);
> + if (s_job)
> + sched->curr_job = s_job;
>
> list_for_each_entry_safe(s_job, tmp, &sched->ring_mirror_list, node) {
> struct drm_sched_fence *s_fence = s_job->s_fence;
> diff --git a/include/drm/gpu_scheduler.h b/include/drm/gpu_scheduler.h
> index daec50f887b3..07e776b1ca42 100644
> --- a/include/drm/gpu_scheduler.h
> +++ b/include/drm/gpu_scheduler.h
> @@ -252,6 +252,7 @@ struct drm_sched_backend_ops {
>* @timeout: the time after which a job is removed from the scheduler.
>* @name: name of the ring for which this scheduler is being used.
>* @sched_rq: priority wise array of run queues.
> + * @curr_job: points to the job currently running on the hardware
>* @wake_up_worker: the wait queue on which the scheduler sleeps until a job
>* is ready to be scheduled.
>* @job_scheduled: once @drm_sched_entity_do_release is called the scheduler
> @@ -274,6 +275,7 @@ struct drm_gpu_scheduler {
> longtimeout;
> const char *name;
> struct drm_sched_rq sched_rq[DRM_SCHED_PRIORITY_MAX];
> + struct drm_sched_job*curr_job;
> wait_queue_head_t wake_up_worker;
> wait_queue_head_t job_scheduled;
> atomic_thw_rq_count;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/2] drm/fourcc: rename Intel modifiers to follow the naming convention
All the other vendors use the format
DRM_FORMAT_MOD_{SAMSUNG,QCOM,VIVANTE,NVIDIA,BROADCOM,ARM}_* for their
modifiers, except Intel.
Suggested-by: Gerd Hoffmann
Signed-off-by: Eric Engestrom
---
include/uapi/drm/drm_fourcc.h | 15 ++-
1 file changed, 10 insertions(+), 5 deletions(-)
diff --git a/include/uapi/drm/drm_fourcc.h b/include/uapi/drm/drm_fourcc.h
index 139632b871816f9e3dad..170a562223387687592a 100644
--- a/include/uapi/drm/drm_fourcc.h
+++ b/include/uapi/drm/drm_fourcc.h
@@ -271,7 +271,8 @@ extern "C" {
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
*/
-#define I915_FORMAT_MOD_X_TILEDfourcc_mod_code(INTEL, 1)
+#define DRM_FORMAT_MOD_INTEL_X_TILED fourcc_mod_code(INTEL, 1)
+#define I915_FORMAT_MOD_X_TILEDDRM_FORMAT_MOD_INTEL_X_TILED
/*
* Intel Y-tiling layout
@@ -286,7 +287,8 @@ extern "C" {
* sharing. It exists since on a given platform it does uniquely identify the
* layout in a simple way for i915-specific userspace.
*/
-#define I915_FORMAT_MOD_Y_TILEDfourcc_mod_code(INTEL, 2)
+#define DRM_FORMAT_MOD_INTEL_Y_TILED fourcc_mod_code(INTEL, 2)
+#define I915_FORMAT_MOD_Y_TILEDDRM_FORMAT_MOD_INTEL_Y_TILED
/*
* Intel Yf-tiling layout
@@ -301,7 +303,8 @@ extern "C" {
* 64 byte blocks of pixels contain four pixel rows of 16 bytes, where the
width
* in pixel depends on the pixel depth.
*/
-#define I915_FORMAT_MOD_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define DRM_FORMAT_MOD_INTEL_Yf_TILED fourcc_mod_code(INTEL, 3)
+#define I915_FORMAT_MOD_Yf_TILED DRM_FORMAT_MOD_INTEL_Yf_TILED
/*
* Intel color control surface (CCS) for render compression
@@ -320,8 +323,10 @@ extern "C" {
* But that fact is not relevant unless the memory is accessed
* directly.
*/
-#define I915_FORMAT_MOD_Y_TILED_CCSfourcc_mod_code(INTEL, 4)
-#define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+#define DRM_FORMAT_MOD_INTEL_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
+#define I915_FORMAT_MOD_Y_TILED_CCSDRM_FORMAT_MOD_INTEL_Y_TILED_CCS
+#define DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
+#define I915_FORMAT_MOD_Yf_TILED_CCS DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS
/*
* Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized macroblocks
--
Cheers,
Eric
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/2] i915: rename modifiers to follow the naming convention
$ sed -i s/I915_FORMAT_MOD_/DRM_FORMAT_MOD_INTEL_/g $(git grep -l
I915_FORMAT_MOD_)
$ git checkout include/uapi/drm/drm_fourcc.h
Signed-off-by: Eric Engestrom
---
drivers/gpu/drm/i915/intel_atomic_plane.c | 12 +-
drivers/gpu/drm/i915/intel_display.c | 128 +++---
drivers/gpu/drm/i915/intel_pm.c | 26 ++---
drivers/gpu/drm/i915/intel_sprite.c | 58 +-
4 files changed, 112 insertions(+), 112 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_atomic_plane.c
b/drivers/gpu/drm/i915/intel_atomic_plane.c
index fa7df5fe154bf06bdfc5..c26f0b25afa2dc8c3a3c 100644
--- a/drivers/gpu/drm/i915/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/intel_atomic_plane.c
@@ -126,8 +126,8 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
if (state->fb && drm_rotation_90_or_270(state->rotation)) {
struct drm_format_name_buf format_name;
- if (state->fb->modifier != I915_FORMAT_MOD_Y_TILED &&
- state->fb->modifier != I915_FORMAT_MOD_Yf_TILED) {
+ if (state->fb->modifier != DRM_FORMAT_MOD_INTEL_Y_TILED &&
+ state->fb->modifier != DRM_FORMAT_MOD_INTEL_Yf_TILED) {
DRM_DEBUG_KMS("Y/Yf tiling required for 90/270!\n");
return -EINVAL;
}
@@ -169,10 +169,10 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
*/
if (state->fb && INTEL_GEN(dev_priv) >= 9 && crtc_state->base.enable &&
adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) {
- if (state->fb->modifier == I915_FORMAT_MOD_Y_TILED ||
- state->fb->modifier == I915_FORMAT_MOD_Yf_TILED ||
- state->fb->modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
- state->fb->modifier == I915_FORMAT_MOD_Yf_TILED_CCS) {
+ if (state->fb->modifier == DRM_FORMAT_MOD_INTEL_Y_TILED ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Yf_TILED ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Y_TILED_CCS ||
+ state->fb->modifier == DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS) {
DRM_DEBUG_KMS("Y/Yf tiling not supported in IF-ID
mode\n");
return -EINVAL;
}
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index b2bab57cd113f2293850..087302d655f9a146846a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -69,7 +69,7 @@ static const uint32_t i965_primary_formats[] = {
};
static const uint64_t i9xx_format_modifiers[] = {
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
@@ -106,19 +106,19 @@ static const uint32_t skl_pri_planar_formats[] = {
};
static const uint64_t skl_format_modifiers_noccs[] = {
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED,
+ DRM_FORMAT_MOD_INTEL_Y_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
static const uint64_t skl_format_modifiers_ccs[] = {
- I915_FORMAT_MOD_Yf_TILED_CCS,
- I915_FORMAT_MOD_Y_TILED_CCS,
- I915_FORMAT_MOD_Yf_TILED,
- I915_FORMAT_MOD_Y_TILED,
- I915_FORMAT_MOD_X_TILED,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS,
+ DRM_FORMAT_MOD_INTEL_Y_TILED_CCS,
+ DRM_FORMAT_MOD_INTEL_Yf_TILED,
+ DRM_FORMAT_MOD_INTEL_Y_TILED,
+ DRM_FORMAT_MOD_INTEL_X_TILED,
DRM_FORMAT_MOD_LINEAR,
DRM_FORMAT_MOD_INVALID
};
@@ -1925,25 +1925,25 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int plane)
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
return cpp;
- case I915_FORMAT_MOD_X_TILED:
+ case DRM_FORMAT_MOD_INTEL_X_TILED:
if (IS_GEN2(dev_priv))
return 128;
else
return 512;
- case I915_FORMAT_MOD_Y_TILED_CCS:
+ case DRM_FORMAT_MOD_INTEL_Y_TILED_CCS:
if (plane == 1)
return 128;
/* fall through */
- case I915_FORMAT_MOD_Y_TILED:
+ case DRM_FORMAT_MOD_INTEL_Y_TILED:
if (IS_GEN2(dev_priv) || HAS_128_BYTE_Y_TILING(dev_priv))
return 128;
else
return 512;
- case I915_FORMAT_MOD_Yf_TILED_CCS:
+ case DRM_FORMAT_MOD_INTEL_Yf_TILED_CCS:
if (plane == 1)
return 128;
/* fall through */
- case I915_FORMAT_MOD_Yf_TILED:
+ case DRM_FORMAT_MOD_INTEL_Yf_TILED:
switch (cpp) {
case 1:
return 64;
@@ -2055,14 +205
[PATCH 01/12] staging: vboxvideo: Let DRM core handle connector registering
Registering the connector explicitly right after creation is not necessary for modesetting drivers, because drm_dev_register already takes care of this on the core side, by calling drm_modeset_register_all. Signed-off-by: Hans de Goede --- drivers/staging/vboxvideo/vbox_mode.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/vboxvideo/vbox_mode.c b/drivers/staging/vboxvideo/vbox_mode.c index e7d70ced5bfd..70701a6054c2 100644 --- a/drivers/staging/vboxvideo/vbox_mode.c +++ b/drivers/staging/vboxvideo/vbox_mode.c @@ -690,7 +690,6 @@ static int vbox_connector_init(struct drm_device *dev, dev->mode_config.suggested_x_property, 0); drm_object_attach_property(&connector->base, dev->mode_config.suggested_y_property, 0); - drm_connector_register(connector); drm_connector_attach_encoder(connector, encoder); -- 2.19.0.rc1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 07/12] staging: vboxvideo: Expose creation of universal primary plane
Let's expose the primary plane initialization inside the vboxvideo driver
in preparation for universal planes and atomic.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 78 +--
1 file changed, 74 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 3beae9d65a09..f35045ce154b 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -382,21 +382,91 @@ static const struct drm_crtc_funcs vbox_crtc_funcs = {
.destroy = vbox_crtc_destroy,
};
+static const uint32_t vbox_primary_plane_formats[] = {
+ DRM_FORMAT_XRGB,
+ DRM_FORMAT_ARGB,
+};
+
+static const struct drm_plane_funcs vbox_primary_plane_funcs = {
+ .update_plane = drm_primary_helper_update,
+ .disable_plane = drm_primary_helper_disable,
+ .destroy= drm_primary_helper_destroy,
+};
+
+static struct drm_plane *vbox_create_plane(struct vbox_private *vbox,
+ unsigned int possible_crtcs,
+ enum drm_plane_type type)
+{
+ const struct drm_plane_helper_funcs *helper_funcs = NULL;
+ const struct drm_plane_funcs *funcs;
+ struct drm_plane *plane;
+ const uint32_t *formats;
+ int num_formats;
+ int err;
+
+ if (type == DRM_PLANE_TYPE_PRIMARY) {
+ funcs = &vbox_primary_plane_funcs;
+ formats = vbox_primary_plane_formats;
+ num_formats = ARRAY_SIZE(vbox_primary_plane_formats);
+ } else {
+ return ERR_PTR(-EINVAL);
+ }
+
+ plane = kzalloc(sizeof(*plane), GFP_KERNEL);
+ if (!plane)
+ return ERR_PTR(-ENOMEM);
+
+ err = drm_universal_plane_init(&vbox->ddev, plane, possible_crtcs,
+ funcs, formats, num_formats,
+ NULL, type, NULL);
+ if (err)
+ goto free_plane;
+
+ drm_plane_helper_add(plane, helper_funcs);
+
+ return plane;
+
+free_plane:
+ kfree(plane);
+ return ERR_PTR(-EINVAL);
+}
+
static struct vbox_crtc *vbox_crtc_init(struct drm_device *dev, unsigned int i)
{
+ struct vbox_private *vbox =
+ container_of(dev, struct vbox_private, ddev);
struct vbox_crtc *vbox_crtc;
+ struct drm_plane *primary;
+ int ret;
vbox_crtc = kzalloc(sizeof(*vbox_crtc), GFP_KERNEL);
if (!vbox_crtc)
- return NULL;
+ return ERR_PTR(-ENOMEM);
+
+ primary = vbox_create_plane(vbox, 1 << i, DRM_PLANE_TYPE_PRIMARY);
+ if (IS_ERR(primary)) {
+ ret = PTR_ERR(primary);
+ goto free_mem;
+ }
vbox_crtc->crtc_id = i;
- drm_crtc_init(dev, &vbox_crtc->base, &vbox_crtc_funcs);
+ ret = drm_crtc_init_with_planes(dev, &vbox_crtc->base, primary, NULL,
+ &vbox_crtc_funcs, NULL);
+ if (ret)
+ goto clean_primary;
+
drm_mode_crtc_set_gamma_size(&vbox_crtc->base, 256);
drm_crtc_helper_add(&vbox_crtc->base, &vbox_crtc_helper_funcs);
return vbox_crtc;
+
+clean_primary:
+ drm_plane_cleanup(primary);
+ kfree(primary);
+free_mem:
+ kfree(vbox_crtc);
+ return ERR_PTR(ret);
}
static void vbox_encoder_destroy(struct drm_encoder *encoder)
@@ -750,8 +820,8 @@ int vbox_mode_init(struct vbox_private *vbox)
/* vbox_cursor_init(dev); */
for (i = 0; i < vbox->num_crtcs; ++i) {
vbox_crtc = vbox_crtc_init(dev, i);
- if (!vbox_crtc) {
- ret = -ENOMEM;
+ if (IS_ERR(vbox_crtc)) {
+ ret = PTR_ERR(vbox_crtc);
goto err_drm_mode_cleanup;
}
encoder = vbox_encoder_init(dev, i);
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 02/12] staging: vboxvideo: Move setup of modesetting from driver_load to mode_init
Move the setup of drm modesetting config from vbox_driver_load() to
vbox_mode_init().
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_main.c | 45 ---
drivers/staging/vboxvideo/vbox_mode.c | 62 ---
2 files changed, 57 insertions(+), 50 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_main.c
b/drivers/staging/vboxvideo/vbox_main.c
index 783a68c0de3b..a1cd29fe98fd 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -173,40 +173,6 @@ int vbox_framebuffer_init(struct drm_device *dev,
return 0;
}
-static struct drm_framebuffer *vbox_user_framebuffer_create(
- struct drm_device *dev,
- struct drm_file *filp,
- const struct drm_mode_fb_cmd2 *mode_cmd)
-{
- struct drm_gem_object *obj;
- struct vbox_framebuffer *vbox_fb;
- int ret = -ENOMEM;
-
- obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
- if (!obj)
- return ERR_PTR(-ENOENT);
-
- vbox_fb = kzalloc(sizeof(*vbox_fb), GFP_KERNEL);
- if (!vbox_fb)
- goto err_unref_obj;
-
- ret = vbox_framebuffer_init(dev, vbox_fb, mode_cmd, obj);
- if (ret)
- goto err_free_vbox_fb;
-
- return &vbox_fb->base;
-
-err_free_vbox_fb:
- kfree(vbox_fb);
-err_unref_obj:
- drm_gem_object_put_unlocked(obj);
- return ERR_PTR(ret);
-}
-
-static const struct drm_mode_config_funcs vbox_mode_funcs = {
- .fb_create = vbox_user_framebuffer_create,
-};
-
static int vbox_accel_init(struct vbox_private *vbox)
{
unsigned int i;
@@ -375,15 +341,6 @@ int vbox_driver_load(struct drm_device *dev)
if (ret)
goto err_hw_fini;
- drm_mode_config_init(dev);
-
- dev->mode_config.funcs = (void *)&vbox_mode_funcs;
- dev->mode_config.min_width = 64;
- dev->mode_config.min_height = 64;
- dev->mode_config.preferred_depth = 24;
- dev->mode_config.max_width = VBE_DISPI_MAX_XRES;
- dev->mode_config.max_height = VBE_DISPI_MAX_YRES;
-
ret = vbox_mode_init(dev);
if (ret)
goto err_drm_mode_cleanup;
@@ -403,7 +360,6 @@ int vbox_driver_load(struct drm_device *dev)
err_mode_fini:
vbox_mode_fini(dev);
err_drm_mode_cleanup:
- drm_mode_config_cleanup(dev);
vbox_mm_fini(vbox);
err_hw_fini:
vbox_hw_fini(vbox);
@@ -417,7 +373,6 @@ void vbox_driver_unload(struct drm_device *dev)
vbox_fbdev_fini(dev);
vbox_irq_fini(vbox);
vbox_mode_fini(dev);
- drm_mode_config_cleanup(dev);
vbox_mm_fini(vbox);
vbox_hw_fini(vbox);
}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 70701a6054c2..2587e6aecca2 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -696,6 +696,40 @@ static int vbox_connector_init(struct drm_device *dev,
return 0;
}
+static struct drm_framebuffer *vbox_user_framebuffer_create(
+ struct drm_device *dev,
+ struct drm_file *filp,
+ const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+ struct drm_gem_object *obj;
+ struct vbox_framebuffer *vbox_fb;
+ int ret = -ENOMEM;
+
+ obj = drm_gem_object_lookup(filp, mode_cmd->handles[0]);
+ if (!obj)
+ return ERR_PTR(-ENOENT);
+
+ vbox_fb = kzalloc(sizeof(*vbox_fb), GFP_KERNEL);
+ if (!vbox_fb)
+ goto err_unref_obj;
+
+ ret = vbox_framebuffer_init(dev, vbox_fb, mode_cmd, obj);
+ if (ret)
+ goto err_free_vbox_fb;
+
+ return &vbox_fb->base;
+
+err_free_vbox_fb:
+ kfree(vbox_fb);
+err_unref_obj:
+ drm_gem_object_put_unlocked(obj);
+ return ERR_PTR(ret);
+}
+
+static const struct drm_mode_config_funcs vbox_mode_funcs = {
+ .fb_create = vbox_user_framebuffer_create,
+};
+
int vbox_mode_init(struct drm_device *dev)
{
struct vbox_private *vbox = dev->dev_private;
@@ -704,24 +738,42 @@ int vbox_mode_init(struct drm_device *dev)
unsigned int i;
int ret;
+ drm_mode_config_init(dev);
+
+ dev->mode_config.funcs = (void *)&vbox_mode_funcs;
+ dev->mode_config.min_width = 64;
+ dev->mode_config.min_height = 64;
+ dev->mode_config.preferred_depth = 24;
+ dev->mode_config.max_width = VBE_DISPI_MAX_XRES;
+ dev->mode_config.max_height = VBE_DISPI_MAX_YRES;
+
/* vbox_cursor_init(dev); */
for (i = 0; i < vbox->num_crtcs; ++i) {
vbox_crtc = vbox_crtc_init(dev, i);
- if (!vbox_crtc)
- return -ENOMEM;
+ if (!vbox_crtc) {
+ ret = -ENOMEM;
+ goto err_drm_mode_cleanup;
+ }
encoder = vbox_encoder_init(dev, i);
- if (!encoder)
-
[PATCH 06/12] staging: vboxvideo: Add fl_flag argument to vbox_fb_pin() helper
Allow specifying where to pin the framebuffer bo, so that this helper can
be used from the cursor code too.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 13696ba19c4f..3beae9d65a09 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -221,7 +221,7 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
return old_single_framebuffer != vbox->single_framebuffer;
}
-static int vbox_fb_pin(struct drm_framebuffer *fb, u64 *addr)
+static int vbox_fb_pin(struct drm_framebuffer *fb, u32 pl_flag, u64 *addr)
{
struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
int ret;
@@ -230,7 +230,7 @@ static int vbox_fb_pin(struct drm_framebuffer *fb, u64
*addr)
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, addr);
+ ret = vbox_bo_pin(bo, pl_flag, addr);
vbox_bo_unreserve(bo);
return ret;
}
@@ -267,7 +267,7 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
int ret;
/* Prepare: pin the new framebuffer bo */
- ret = vbox_fb_pin(new_fb, &gpu_addr);
+ ret = vbox_fb_pin(new_fb, TTM_PL_FLAG_VRAM, &gpu_addr);
if (ret) {
DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
return ret;
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 00/12] staging: vboxvideo: Preparation work for moving to atomic modesetting
Hi Greg, Here is a series of various cleanups and other prep. work for moving the vboxvideo driver over to atomic modesetting so that it can be moved out of staging. Regards, Hans ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 04/12] staging: vboxvideo: Embed drm_device into driver structure
This is the recommended way to create the drm_device structure,
according to DRM documentation.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 110 +++---
drivers/staging/vboxvideo/vbox_drv.h | 17 ++--
drivers/staging/vboxvideo/vbox_fb.c | 19 ++---
drivers/staging/vboxvideo/vbox_irq.c | 8 +-
drivers/staging/vboxvideo/vbox_main.c | 30 +++
drivers/staging/vboxvideo/vbox_mode.c | 36 -
drivers/staging/vboxvideo/vbox_ttm.c | 13 ++-
7 files changed, 111 insertions(+), 122 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index 410a1f35b746..c4290d4b4a53 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -51,35 +51,31 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
- struct vbox_private *vbox = NULL;
- struct drm_device *dev = NULL;
+ struct vbox_private *vbox;
int ret = 0;
if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
return -ENODEV;
- dev = drm_dev_alloc(&driver, &pdev->dev);
- if (IS_ERR(dev))
- return PTR_ERR(dev);
+ vbox = kzalloc(sizeof(*vbox), GFP_KERNEL);
+ if (!vbox)
+ return -ENOMEM;
- ret = pci_enable_device(pdev);
- if (ret)
- goto err_dev_put;
-
- dev->pdev = pdev;
- pci_set_drvdata(pdev, dev);
-
- vbox = devm_kzalloc(&pdev->dev, sizeof(*vbox), GFP_KERNEL);
- if (!vbox) {
- ret = -ENOMEM;
- goto err_pci_disable;
+ ret = drm_dev_init(&vbox->ddev, &driver, &pdev->dev);
+ if (ret) {
+ kfree(vbox);
+ return ret;
}
- dev->dev_private = vbox;
- vbox->dev = dev;
-
+ vbox->ddev.pdev = pdev;
+ vbox->ddev.dev_private = vbox;
+ pci_set_drvdata(pdev, vbox);
mutex_init(&vbox->hw_mutex);
+ ret = pci_enable_device(pdev);
+ if (ret)
+ goto err_dev_put;
+
ret = vbox_hw_init(vbox);
if (ret)
goto err_pci_disable;
@@ -88,7 +84,7 @@ static int vbox_pci_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret)
goto err_hw_fini;
- ret = vbox_mode_init(dev);
+ ret = vbox_mode_init(vbox);
if (ret)
goto err_mm_fini;
@@ -96,22 +92,22 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
if (ret)
goto err_mode_fini;
- ret = vbox_fbdev_init(dev);
+ ret = vbox_fbdev_init(vbox);
if (ret)
goto err_irq_fini;
- ret = drm_dev_register(dev, 0);
+ ret = drm_dev_register(&vbox->ddev, 0);
if (ret)
goto err_fbdev_fini;
return 0;
err_fbdev_fini:
- vbox_fbdev_fini(dev);
+ vbox_fbdev_fini(vbox);
err_irq_fini:
vbox_irq_fini(vbox);
err_mode_fini:
- vbox_mode_fini(dev);
+ vbox_mode_fini(vbox);
err_mm_fini:
vbox_mm_fini(vbox);
err_hw_fini:
@@ -119,110 +115,100 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
struct pci_device_id *ent)
err_pci_disable:
pci_disable_device(pdev);
err_dev_put:
- drm_dev_put(dev);
+ drm_dev_put(&vbox->ddev);
return ret;
}
static void vbox_pci_remove(struct pci_dev *pdev)
{
- struct drm_device *dev = pci_get_drvdata(pdev);
- struct vbox_private *vbox = dev->dev_private;
+ struct vbox_private *vbox = pci_get_drvdata(pdev);
- drm_dev_unregister(dev);
- vbox_fbdev_fini(dev);
+ drm_dev_unregister(&vbox->ddev);
+ vbox_fbdev_fini(vbox);
vbox_irq_fini(vbox);
- vbox_mode_fini(dev);
+ vbox_mode_fini(vbox);
vbox_mm_fini(vbox);
vbox_hw_fini(vbox);
- drm_dev_put(dev);
+ drm_dev_put(&vbox->ddev);
}
-static int vbox_drm_freeze(struct drm_device *dev)
+static int vbox_drm_freeze(struct vbox_private *vbox)
{
- struct vbox_private *vbox = dev->dev_private;
-
- drm_kms_helper_poll_disable(dev);
+ drm_kms_helper_poll_disable(&vbox->ddev);
- pci_save_state(dev->pdev);
+ pci_save_state(vbox->ddev.pdev);
drm_fb_helper_set_suspend_unlocked(&vbox->fbdev->helper, true);
return 0;
}
-static int vbox_drm_thaw(struct drm_device *dev)
+static int vbox_drm_thaw(struct vbox_private *vbox)
{
- struct vbox_private *vbox = dev->dev_private;
-
- drm_mode_config_reset(dev);
- drm_helper_resume_force_mode(dev);
+ drm_mode_config_reset(&vbox->ddev);
+ drm_helper_resume_force_mode(&vbox->ddev);
drm_fb_helper_set_suspend_unlocked(&vbox->fbdev->helper, false);
return 0;
}
-static int vbox_drm_resume(struct drm_device *dev)
+static int vbox_drm_resume(struct vbox_private *vbox
[PATCH 03/12] staging: vboxvideo: Fold driver_load/unload into probe/remove functions
Fold the driver_load / unload functions into the probe / remove functions
now that we are no longer using the deprecated drm_get_pci_dev() mechanism.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 71 +--
drivers/staging/vboxvideo/vbox_drv.h | 6 ++-
drivers/staging/vboxvideo/vbox_main.c | 67 ++---
3 files changed, 63 insertions(+), 81 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index 69cc508af1bc..410a1f35b746 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -51,48 +51,89 @@ MODULE_DEVICE_TABLE(pci, pciidlist);
static int vbox_pci_probe(struct pci_dev *pdev, const struct pci_device_id
*ent)
{
+ struct vbox_private *vbox = NULL;
struct drm_device *dev = NULL;
int ret = 0;
+ if (!vbox_check_supported(VBE_DISPI_ID_HGSMI))
+ return -ENODEV;
+
dev = drm_dev_alloc(&driver, &pdev->dev);
- if (IS_ERR(dev)) {
- ret = PTR_ERR(dev);
- goto err_drv_alloc;
- }
+ if (IS_ERR(dev))
+ return PTR_ERR(dev);
ret = pci_enable_device(pdev);
if (ret)
- goto err_pci_enable;
+ goto err_dev_put;
dev->pdev = pdev;
pci_set_drvdata(pdev, dev);
- ret = vbox_driver_load(dev);
+ vbox = devm_kzalloc(&pdev->dev, sizeof(*vbox), GFP_KERNEL);
+ if (!vbox) {
+ ret = -ENOMEM;
+ goto err_pci_disable;
+ }
+
+ dev->dev_private = vbox;
+ vbox->dev = dev;
+
+ mutex_init(&vbox->hw_mutex);
+
+ ret = vbox_hw_init(vbox);
+ if (ret)
+ goto err_pci_disable;
+
+ ret = vbox_mm_init(vbox);
if (ret)
- goto err_vbox_driver_load;
+ goto err_hw_fini;
+
+ ret = vbox_mode_init(dev);
+ if (ret)
+ goto err_mm_fini;
+
+ ret = vbox_irq_init(vbox);
+ if (ret)
+ goto err_mode_fini;
+
+ ret = vbox_fbdev_init(dev);
+ if (ret)
+ goto err_irq_fini;
ret = drm_dev_register(dev, 0);
if (ret)
- goto err_drv_dev_register;
+ goto err_fbdev_fini;
- return ret;
+ return 0;
- err_drv_dev_register:
- vbox_driver_unload(dev);
- err_vbox_driver_load:
+err_fbdev_fini:
+ vbox_fbdev_fini(dev);
+err_irq_fini:
+ vbox_irq_fini(vbox);
+err_mode_fini:
+ vbox_mode_fini(dev);
+err_mm_fini:
+ vbox_mm_fini(vbox);
+err_hw_fini:
+ vbox_hw_fini(vbox);
+err_pci_disable:
pci_disable_device(pdev);
- err_pci_enable:
+err_dev_put:
drm_dev_put(dev);
- err_drv_alloc:
return ret;
}
static void vbox_pci_remove(struct pci_dev *pdev)
{
struct drm_device *dev = pci_get_drvdata(pdev);
+ struct vbox_private *vbox = dev->dev_private;
drm_dev_unregister(dev);
- vbox_driver_unload(dev);
+ vbox_fbdev_fini(dev);
+ vbox_irq_fini(vbox);
+ vbox_mode_fini(dev);
+ vbox_mm_fini(vbox);
+ vbox_hw_fini(vbox);
drm_dev_put(dev);
}
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 594f84272957..a8e0dd8b57bf 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -126,8 +126,6 @@ struct vbox_private {
#undef CURSOR_PIXEL_COUNT
#undef CURSOR_DATA_SIZE
-int vbox_driver_load(struct drm_device *dev);
-void vbox_driver_unload(struct drm_device *dev);
void vbox_driver_lastclose(struct drm_device *dev);
struct vbox_gem_object;
@@ -177,6 +175,10 @@ struct vbox_fbdev {
#define to_vbox_encoder(x) container_of(x, struct vbox_encoder, base)
#define to_vbox_framebuffer(x) container_of(x, struct vbox_framebuffer, base)
+bool vbox_check_supported(u16 id);
+int vbox_hw_init(struct vbox_private *vbox);
+void vbox_hw_fini(struct vbox_private *vbox);
+
int vbox_mode_init(struct drm_device *dev);
void vbox_mode_fini(struct drm_device *dev);
diff --git a/drivers/staging/vboxvideo/vbox_main.c
b/drivers/staging/vboxvideo/vbox_main.c
index a1cd29fe98fd..815292f1d7e6 100644
--- a/drivers/staging/vboxvideo/vbox_main.c
+++ b/drivers/staging/vboxvideo/vbox_main.c
@@ -228,7 +228,7 @@ static bool have_hgsmi_mode_hints(struct vbox_private *vbox)
return have_hints == VINF_SUCCESS && have_cursor == VINF_SUCCESS;
}
-static bool vbox_check_supported(u16 id)
+bool vbox_check_supported(u16 id)
{
u16 dispi_id;
@@ -242,7 +242,7 @@ static bool vbox_check_supported(u16 id)
* Set up our heaps and data exchange buffers in VRAM before handing the rest
* to the memory manager.
*/
-static int vbox_hw_init(struct vbox_private *vbox)
+int vbox_hw_init(struct vbox_private *vbox)
{
int ret = -ENOMEM;
@@ -309,74 +309,13 @@ static int vbox_hw_init(struct vbox_private *vbox)
[PATCH 05/12] staging: vboxvideo: Fold vbox_drm_resume() into vbox_pm_resume()
vbox_pm_resume() is the only caller of vbox_drm_resume(), so squash the
2 functions into 1.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.c | 28 +++-
1 file changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.c
b/drivers/staging/vboxvideo/vbox_drv.c
index c4290d4b4a53..c6a53b0ad66c 100644
--- a/drivers/staging/vboxvideo/vbox_drv.c
+++ b/drivers/staging/vboxvideo/vbox_drv.c
@@ -152,22 +152,6 @@ static int vbox_drm_thaw(struct vbox_private *vbox)
return 0;
}
-static int vbox_drm_resume(struct vbox_private *vbox)
-{
- int ret;
-
- if (pci_enable_device(vbox->ddev.pdev))
- return -EIO;
-
- ret = vbox_drm_thaw(vbox);
- if (ret)
- return ret;
-
- drm_kms_helper_poll_enable(&vbox->ddev);
-
- return 0;
-}
-
static int vbox_pm_suspend(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
@@ -186,8 +170,18 @@ static int vbox_pm_suspend(struct device *dev)
static int vbox_pm_resume(struct device *dev)
{
struct vbox_private *vbox = dev_get_drvdata(dev);
+ int ret;
- return vbox_drm_resume(vbox);
+ if (pci_enable_device(vbox->ddev.pdev))
+ return -EIO;
+
+ ret = vbox_drm_thaw(vbox);
+ if (ret)
+ return ret;
+
+ drm_kms_helper_poll_enable(&vbox->ddev);
+
+ return 0;
}
static int vbox_pm_freeze(struct device *dev)
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 12/12] staging: vboxvideo: Add vbox_bo_k[un]map helper functions
Add vbox_bo_k[un]map helper functions instead of having code directly
poking struct vbox_bo internals.
While touch neighboring code anyways also fix a return -PTR_ERR(info),
which should be return PTR_ERR(info).
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 2 ++
drivers/staging/vboxvideo/vbox_fb.c | 19 +++
drivers/staging/vboxvideo/vbox_ttm.c | 28 +++-
3 files changed, 36 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index fffde1713101..6c52cbd9e91e 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -269,6 +269,8 @@ static inline void vbox_bo_unreserve(struct vbox_bo *bo)
void vbox_ttm_placement(struct vbox_bo *bo, int domain);
int vbox_bo_push_sysram(struct vbox_bo *bo);
int vbox_mmap(struct file *filp, struct vm_area_struct *vma);
+void *vbox_bo_kmap(struct vbox_bo *bo);
+void vbox_bo_kunmap(struct vbox_bo *bo);
/* vbox_prime.c */
int vbox_gem_prime_pin(struct drm_gem_object *obj);
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index bdc87d02ecc5..b8b42f9aafae 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -108,15 +108,14 @@ static int vboxfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
- ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
- if (ret) {
- DRM_ERROR("failed to kmap fbcon\n");
- return ret;
- }
-
info = drm_fb_helper_alloc_fbi(helper);
if (IS_ERR(info))
- return -PTR_ERR(info);
+ return PTR_ERR(info);
+
+ info->screen_size = size;
+ info->screen_base = (char __iomem *)vbox_bo_kmap(bo);
+ if (IS_ERR(info->screen_base))
+ return PTR_ERR(info->screen_base);
info->par = fbdev;
@@ -150,9 +149,6 @@ static int vboxfb_create(struct drm_fb_helper *helper,
info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
info->fix.smem_len = vbox->available_vram_size - gpu_addr;
- info->screen_base = (char __iomem *)bo->kmap.virtual;
- info->screen_size = size;
-
#ifdef CONFIG_DRM_KMS_FB_HELPER
info->fbdefio = &vbox_defio;
fb_deferred_io_init(info);
@@ -184,8 +180,7 @@ void vbox_fbdev_fini(struct vbox_private *vbox)
if (afb->obj) {
struct vbox_bo *bo = gem_to_vbox_bo(afb->obj);
- if (bo->kmap.virtual)
- ttm_bo_kunmap(&bo->kmap);
+ vbox_bo_kunmap(bo);
if (bo->pin_count)
vbox_bo_unpin(bo);
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
index bd0a1603764e..5ecfa7629173 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -418,8 +418,10 @@ int vbox_bo_push_sysram(struct vbox_bo *bo)
if (bo->pin_count)
return 0;
- if (bo->kmap.virtual)
+ if (bo->kmap.virtual) {
ttm_bo_kunmap(&bo->kmap);
+ bo->kmap.virtual = NULL;
+ }
vbox_ttm_placement(bo, TTM_PL_FLAG_SYSTEM);
@@ -448,3 +450,27 @@ int vbox_mmap(struct file *filp, struct vm_area_struct
*vma)
return ttm_bo_mmap(filp, vma, &vbox->ttm.bdev);
}
+
+void *vbox_bo_kmap(struct vbox_bo *bo)
+{
+ int ret;
+
+ if (bo->kmap.virtual)
+ return bo->kmap.virtual;
+
+ ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
+ if (ret) {
+ DRM_ERROR("Error kmapping bo: %d\n", ret);
+ return NULL;
+ }
+
+ return bo->kmap.virtual;
+}
+
+void vbox_bo_kunmap(struct vbox_bo *bo)
+{
+ if (bo->kmap.virtual) {
+ ttm_bo_kunmap(&bo->kmap);
+ bo->kmap.virtual = NULL;
+ }
+}
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 09/12] staging: vboxvideo: Move pin / unpin of fb out of vbox_crtc_set_base_and_mode
Move pin / unpin of fb out of vbox_crtc_set_base_and_mode() so that it can
be used to implement the atomic_update drm_plane_helper_func for the primary
plane.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 5 +++
drivers/staging/vboxvideo/vbox_mode.c | 52 ++-
drivers/staging/vboxvideo/vbox_ttm.c | 5 ---
3 files changed, 32 insertions(+), 30 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 5034c6bd5445..6a4d3b382e79 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -220,6 +220,11 @@ static inline struct vbox_bo *vbox_bo(struct
ttm_buffer_object *bo)
#define to_vbox_obj(x) container_of(x, struct vbox_gem_object, base)
+static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
+{
+ return bo->bo.offset;
+}
+
int vbox_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args);
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 6d7a89524fbf..1a2416a59fe0 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -255,28 +255,18 @@ static void vbox_fb_unpin(struct drm_framebuffer *fb)
vbox_bo_unreserve(bo);
}
-static int vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
- struct drm_framebuffer *old_fb,
- struct drm_framebuffer *new_fb,
- struct drm_display_mode *mode,
- int x, int y)
+static void vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
+ struct drm_framebuffer *fb,
+ struct drm_display_mode *mode,
+ int x, int y)
{
+ struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
struct vbox_private *vbox = crtc->dev->dev_private;
struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
- u64 gpu_addr;
- int ret;
-
- /* Prepare: pin the new framebuffer bo */
- ret = vbox_fb_pin(new_fb, TTM_PL_FLAG_VRAM, &gpu_addr);
- if (ret) {
- DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
- return ret;
- }
- /* Commit: Update hardware to use the new fb */
mutex_lock(&vbox->hw_mutex);
- vbox_crtc->fb_offset = gpu_addr;
+ vbox_crtc->fb_offset = vbox_bo_gpu_offset(bo);
/* vbox_do_modeset() checks vbox->single_framebuffer so update it now */
if (mode && vbox_set_up_input_mapping(vbox)) {
@@ -299,11 +289,6 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
vbox->input_mapping_height);
mutex_unlock(&vbox->hw_mutex);
-
- /* Cleanup: unpin the old fb */
- vbox_fb_unpin(old_fb);
-
- return 0;
}
static int vbox_crtc_mode_set(struct drm_crtc *crtc,
@@ -311,8 +296,19 @@ static int vbox_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode,
int x, int y, struct drm_framebuffer *old_fb)
{
- return vbox_crtc_set_base_and_mode(crtc, old_fb, CRTC_FB(crtc),
- mode, x, y);
+ int ret;
+
+ ret = vbox_fb_pin(CRTC_FB(crtc), TTM_PL_FLAG_VRAM, NULL);
+ if (ret) {
+ DRM_WARN("Error %d pinning new fb, out of video mem?\n", ret);
+ return ret;
+ }
+
+ vbox_crtc_set_base_and_mode(crtc, CRTC_FB(crtc), mode, x, y);
+
+ vbox_fb_unpin(old_fb);
+
+ return 0;
}
static int vbox_crtc_page_flip(struct drm_crtc *crtc,
@@ -324,9 +320,15 @@ static int vbox_crtc_page_flip(struct drm_crtc *crtc,
unsigned long flags;
int rc;
- rc = vbox_crtc_set_base_and_mode(crtc, CRTC_FB(crtc), fb, NULL, 0, 0);
- if (rc)
+ rc = vbox_fb_pin(fb, TTM_PL_FLAG_VRAM, NULL);
+ if (rc) {
+ DRM_WARN("Error %d pinning new fb, out of video mem?\n", rc);
return rc;
+ }
+
+ vbox_crtc_set_base_and_mode(crtc, fb, NULL, 0, 0);
+
+ vbox_fb_unpin(CRTC_FB(crtc));
spin_lock_irqsave(&crtc->dev->event_lock, flags);
diff --git a/drivers/staging/vboxvideo/vbox_ttm.c
b/drivers/staging/vboxvideo/vbox_ttm.c
index 7b8eac30faca..0e14556dcd6b 100644
--- a/drivers/staging/vboxvideo/vbox_ttm.c
+++ b/drivers/staging/vboxvideo/vbox_ttm.c
@@ -343,11 +343,6 @@ int vbox_bo_create(struct vbox_private *vbox, int size,
int align,
return ret;
}
-static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo)
-{
- return bo->bo.offset;
-}
-
int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr)
{
struct ttm_operation_ctx ctx = { false, false };
--
[PATCH 08/12] staging: vboxvideo: Init fb_info.fix.smem once from fbdev_create
The fbdev compat fb gets pinned into VRAM at creation and then gets pinned
a second time when set as scanout buffer and unpinned when replaced, this
means its pin count never becomes less then 1, so it is always at the same
address and there is no need for the vbox_fbdev_set_base() call.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 1 -
drivers/staging/vboxvideo/vbox_fb.c | 14 +-
drivers/staging/vboxvideo/vbox_mode.c | 3 ---
3 files changed, 5 insertions(+), 13 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 28ffdffe877a..5034c6bd5445 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -201,7 +201,6 @@ int vbox_framebuffer_init(struct vbox_private *vbox,
int vbox_fbdev_init(struct vbox_private *vbox);
void vbox_fbdev_fini(struct vbox_private *vbox);
-void vbox_fbdev_set_base(struct vbox_private *vbox, unsigned long gpu_addr);
struct vbox_bo {
struct ttm_buffer_object bo;
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index 11b6364ed14a..0e5550fa7c57 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -80,6 +80,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
struct drm_gem_object *gobj;
struct vbox_bo *bo;
int size, ret;
+ u64 gpu_addr;
u32 pitch;
mode_cmd.width = sizes->surface_width;
@@ -107,7 +108,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, NULL);
+ ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
if (ret) {
vbox_bo_unreserve(bo);
return ret;
@@ -152,6 +153,9 @@ static int vboxfb_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_var(info, &fbdev->helper, sizes->fb_width,
sizes->fb_height);
+ info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
+ info->fix.smem_len = vbox->available_vram_size - gpu_addr;
+
info->screen_base = (char __iomem *)bo->kmap.virtual;
info->screen_size = size;
@@ -241,11 +245,3 @@ int vbox_fbdev_init(struct vbox_private *vbox)
drm_fb_helper_fini(&fbdev->helper);
return ret;
}
-
-void vbox_fbdev_set_base(struct vbox_private *vbox, unsigned long gpu_addr)
-{
- struct fb_info *fbdev = vbox->fbdev->helper.fbdev;
-
- fbdev->fix.smem_start = fbdev->apertures->ranges[0].base + gpu_addr;
- fbdev->fix.smem_len = vbox->available_vram_size - gpu_addr;
-}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index f35045ce154b..6d7a89524fbf 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -276,9 +276,6 @@ static int vbox_crtc_set_base_and_mode(struct drm_crtc
*crtc,
/* Commit: Update hardware to use the new fb */
mutex_lock(&vbox->hw_mutex);
- if (&vbox->fbdev->afb == to_vbox_framebuffer(new_fb))
- vbox_fbdev_set_base(vbox, gpu_addr);
-
vbox_crtc->fb_offset = gpu_addr;
/* vbox_do_modeset() checks vbox->single_framebuffer so update it now */
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 11/12] staging: vboxvideo: Move bo_[un]resere calls into vbox_bo_[un]pin
We always need to reserve the bo around a pin / unpin, so move the
reservation there.
This allows removing the vbox_fb_[un]pin helpers.
Note this means that we now no longer hold the bo reserved while
k[un]mapping it in vbox_fb.c this is fine as it is not necessary
to hold it reserved for this.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_drv.h | 2 +-
drivers/staging/vboxvideo/vbox_fb.c | 27 --
drivers/staging/vboxvideo/vbox_mode.c | 54 ---
drivers/staging/vboxvideo/vbox_ttm.c | 32 +---
4 files changed, 42 insertions(+), 73 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_drv.h
b/drivers/staging/vboxvideo/vbox_drv.h
index 6a4d3b382e79..fffde1713101 100644
--- a/drivers/staging/vboxvideo/vbox_drv.h
+++ b/drivers/staging/vboxvideo/vbox_drv.h
@@ -245,7 +245,7 @@ int vbox_bo_create(struct vbox_private *vbox, int size, int
align,
int vbox_gem_create(struct vbox_private *vbox,
u32 size, bool iskernel, struct drm_gem_object **obj);
-int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag, u64 *gpu_addr);
+int vbox_bo_pin(struct vbox_bo *bo, u32 pl_flag);
int vbox_bo_unpin(struct vbox_bo *bo);
static inline int vbox_bo_reserve(struct vbox_bo *bo, bool no_wait)
diff --git a/drivers/staging/vboxvideo/vbox_fb.c
b/drivers/staging/vboxvideo/vbox_fb.c
index 0e5550fa7c57..bdc87d02ecc5 100644
--- a/drivers/staging/vboxvideo/vbox_fb.c
+++ b/drivers/staging/vboxvideo/vbox_fb.c
@@ -104,18 +104,11 @@ static int vboxfb_create(struct drm_fb_helper *helper,
bo = gem_to_vbox_bo(gobj);
- ret = vbox_bo_reserve(bo, false);
+ ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM);
if (ret)
return ret;
- ret = vbox_bo_pin(bo, TTM_PL_FLAG_VRAM, &gpu_addr);
- if (ret) {
- vbox_bo_unreserve(bo);
- return ret;
- }
-
ret = ttm_bo_kmap(&bo->bo, 0, bo->bo.num_pages, &bo->kmap);
- vbox_bo_unreserve(bo);
if (ret) {
DRM_ERROR("failed to kmap fbcon\n");
return ret;
@@ -153,6 +146,7 @@ static int vboxfb_create(struct drm_fb_helper *helper,
drm_fb_helper_fill_var(info, &fbdev->helper, sizes->fb_width,
sizes->fb_height);
+ gpu_addr = vbox_bo_gpu_offset(bo);
info->fix.smem_start = info->apertures->ranges[0].base + gpu_addr;
info->fix.smem_len = vbox->available_vram_size - gpu_addr;
@@ -190,17 +184,12 @@ void vbox_fbdev_fini(struct vbox_private *vbox)
if (afb->obj) {
struct vbox_bo *bo = gem_to_vbox_bo(afb->obj);
- if (!vbox_bo_reserve(bo, false)) {
- if (bo->kmap.virtual)
- ttm_bo_kunmap(&bo->kmap);
- /*
-* QXL does this, but is it really needed before
-* freeing?
-*/
- if (bo->pin_count)
- vbox_bo_unpin(bo);
- vbox_bo_unreserve(bo);
- }
+ if (bo->kmap.virtual)
+ ttm_bo_kunmap(&bo->kmap);
+
+ if (bo->pin_count)
+ vbox_bo_unpin(bo);
+
drm_gem_object_put_unlocked(afb->obj);
afb->obj = NULL;
}
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 910ea19931c9..bef99664d030 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -221,40 +221,6 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
return old_single_framebuffer != vbox->single_framebuffer;
}
-static int vbox_fb_pin(struct drm_framebuffer *fb, u32 pl_flag, u64 *addr)
-{
- struct vbox_bo *bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
- int ret;
-
- ret = vbox_bo_reserve(bo, false);
- if (ret)
- return ret;
-
- ret = vbox_bo_pin(bo, pl_flag, addr);
- vbox_bo_unreserve(bo);
- return ret;
-}
-
-static void vbox_fb_unpin(struct drm_framebuffer *fb)
-{
- struct vbox_bo *bo;
- int ret;
-
- if (!fb)
- return;
-
- bo = gem_to_vbox_bo(to_vbox_framebuffer(fb)->obj);
-
- ret = vbox_bo_reserve(bo, false);
- if (ret) {
- DRM_ERROR("Error %d reserving fb bo, leaving it pinned\n", ret);
- return;
- }
-
- vbox_bo_unpin(bo);
- vbox_bo_unreserve(bo);
-}
-
static void vbox_crtc_set_base_and_mode(struct drm_crtc *crtc,
struct drm_framebuffer *fb,
struct drm_display_mode *mode,
@@ -296,17 +262,22 @@ static int vbox_crtc_mode_set(struct drm_crtc *crtc,
struct drm_display_mode *adjusted_mode,
int x, int y, struct drm_framebuff
[PATCH 10/12] staging: vboxvideo: Fix NULL ptr deref in vbox_set_up_input_mapping()
When vbox_set_up_input_mapping() gets called the first crtc might be
disable and not have a fb at all, triggering a NUL ptr deref at:
vbox->input_mapping_width = CRTC_FB(crtci)->width;
Instead of using the fb from the crtc with id 0, just use the fb from
the first crtc with a fb. This is in the single_framebuffer = true path,
so all crtc-s point to the same fb anyways.
Signed-off-by: Hans de Goede
---
drivers/staging/vboxvideo/vbox_mode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/vboxvideo/vbox_mode.c
b/drivers/staging/vboxvideo/vbox_mode.c
index 1a2416a59fe0..910ea19931c9 100644
--- a/drivers/staging/vboxvideo/vbox_mode.c
+++ b/drivers/staging/vboxvideo/vbox_mode.c
@@ -189,17 +189,17 @@ static bool vbox_set_up_input_mapping(struct vbox_private
*vbox)
}
}
if (single_framebuffer) {
+ vbox->single_framebuffer = true;
list_for_each_entry(crtci, &vbox->ddev.mode_config.crtc_list,
head) {
- if (to_vbox_crtc(crtci)->crtc_id != 0)
+ if (!CRTC_FB(crtci))
continue;
- vbox->single_framebuffer = true;
vbox->input_mapping_width = CRTC_FB(crtci)->width;
vbox->input_mapping_height = CRTC_FB(crtci)->height;
- return old_single_framebuffer !=
- vbox->single_framebuffer;
+ break;
}
+ return old_single_framebuffer != vbox->single_framebuffer;
}
/* Otherwise calculate the total span of all screens. */
list_for_each_entry(connectori, &vbox->ddev.mode_config.connector_list,
--
2.19.0.rc1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
All DRM_CLIENT capabilities are tied to KMS support, so returning
-EOPNOTSUPP when KMS is not supported.
v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
in uapi) instead of -ENOTSUPP
v3: adding comments about the feature requirement about capabilities
Cc: Chris Wilson
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/drm_ioctl.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 60dfbfae6a02..94bd872d56c4 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
struct drm_file *file_priv)
{
struct drm_set_client_cap *req = data;
+ /* No render-only settable capabilities for now */
+
+ /* Below caps that only works with KMS drivers */
+ if (!drm_core_check_feature(dev, DRIVER_MODESET))
+ return -EOPNOTSUPP;
+
switch (req->capability) {
case DRM_CLIENT_CAP_STEREO_3D:
if (req->value > 1)
--
2.19.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [virtio-dev] [PATCH 2/2] drm/virtio: add iommu support.
On 09/12/2018 02:25 AM, Gerd Hoffmann wrote: > Hi, > >> I attempted to fix it in the ttm layer and here is the discussion >> https://lore.kernel.org/lkml/b44280d7-eb13-0996-71f5-3fbdeb466...@amd.com/ >> >> The ttm maintainer Christian is suggesting to map and set ttm->pages as >> decrypted >> right after ttm->pages are allocated. >> >> Just checking with you guys maybe there is a better way to handle this in >> the virtio gpu layer instead of the common ttm layer. Could you guys shine >> some >> light on this? Thanks. > > I think the tty layer is the right place to fix this. virtio just calls > down to ttm for mappings. I think virtio should just hint to ttm using > a flag in some struct, probably ttm_buffer_object or > ttm_mem_type_manager, that the objects need decrypted mappings. > > cheers, > Gerd > I tested this patch with non SEV guest. It gives a blank black screen if booting with swiotlb=force. dma_sync is missing if dma op uses swiotlb as bounce buffer. I tried to put a dma_sync_sg_for_device() on virtio_gpu_object obj->pages-sgl before VIRTIO_GPU_CMD_TRANSFER_TO_HOST_2D is sent. This fixes the kernel console path. Once display manger is kicked off for example (sudo systemctl start lightdm.service) and resource id 3 gets created from user space down, it still gives a blank black screen. In addition, I added dma_sync_sg_for_device() before sending VIRTIO_GPU_CMD_RESOURCE_FLUSH and VIRTIO_GPU_CMD_SET_SCANOUT, still blank black screen after display manger is kicked off. Do you know which path I'm still missing as far as VIRTIO_GPU_CMD goes? Thanks - Jiandi ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 05/17] compat_ioctl: move more drivers to generic_compat_ioctl_ptrarg
On Fri, Sep 14, 2018 at 09:57:48PM +0100, Al Viro wrote: > On Fri, Sep 14, 2018 at 01:35:06PM -0700, Darren Hart wrote: > > > Acked-by: Darren Hart (VMware) > > > > As for a longer term solution, would it be possible to init fops in such > > a way that the compat_ioctl call defaults to generic_compat_ioctl_ptrarg > > so we don't have to duplicate this boilerplate for every ioctl fops > > structure? > > Bad idea, that... Because several years down the road somebody will add > an ioctl that takes an unsigned int for argument. Without so much as looking > at your magical mystery macro being used to initialize file_operations. Fair, being explicit in the declaration as it is currently may be preferable then. -- Darren Hart VMware Open Source Technology Center ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH v3] drm: Return -EOPNOTSUPP in drm_setclientcap() when driver do not support KMS
On Tue, Sep 18, 2018 at 10:48:09AM -0700, José Roberto de Souza wrote:
> All DRM_CLIENT capabilities are tied to KMS support, so returning
> -EOPNOTSUPP when KMS is not supported.
>
> v2: returning -EOPNOTSUPP(same value as posix ENOTSUP and available
> in uapi) instead of -ENOTSUPP
>
> v3: adding comments about the feature requirement about capabilities
>
> Cc: Chris Wilson
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/drm_ioctl.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
> index 60dfbfae6a02..94bd872d56c4 100644
> --- a/drivers/gpu/drm/drm_ioctl.c
> +++ b/drivers/gpu/drm/drm_ioctl.c
> @@ -306,6 +306,12 @@ drm_setclientcap(struct drm_device *dev, void *data,
> struct drm_file *file_priv)
> {
> struct drm_set_client_cap *req = data;
>
> + /* No render-only settable capabilities for now */
> +
> + /* Below caps that only works with KMS drivers */
That doesn't seem quite English.
> + if (!drm_core_check_feature(dev, DRIVER_MODESET))
> + return -EOPNOTSUPP;
> +
> switch (req->capability) {
> case DRM_CLIENT_CAP_STEREO_3D:
> if (req->value > 1)
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> intel-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v8 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
Use the newly added "max bpc" connector property to limit pipe bpp.
V3: Use drm_connector_state to access the "max bpc" property
V4: Initialize the drm property, add suuport to DP(Ville)
V5: Use the property in the connector and fix CI failure(Ville)
V6: Use the core function to attach max_bpc property, remove the redundant
clamping of pipe bpp based on connector info
V7: Fix Checkpatch warnings
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Kishore Kadiyala
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/i915/intel_display.c | 49
drivers/gpu/drm/i915/intel_dp.c | 5
drivers/gpu/drm/i915/intel_hdmi.c| 5
3 files changed, 38 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index eb25037d7b38..75afd53590b1 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10845,29 +10845,37 @@ static void
intel_modeset_update_connector_atomic_state(struct drm_device *dev)
}
static void
-connected_sink_compute_bpp(struct intel_connector *connector,
- struct intel_crtc_state *pipe_config)
+connected_sink_max_bpp(struct drm_connector_state *conn_state,
+ struct intel_crtc_state *pipe_config)
{
- const struct drm_display_info *info = &connector->base.display_info;
- int bpp = pipe_config->pipe_bpp;
-
- DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
- connector->base.base.id,
- connector->base.name);
-
- /* Don't use an invalid EDID bpc value */
- if (info->bpc != 0 && info->bpc * 3 < bpp) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
max of %d\n",
- bpp, info->bpc * 3);
- pipe_config->pipe_bpp = info->bpc * 3;
+ if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
+ conn_state->max_bpc = pipe_config->pipe_bpp / 3;
+ return;
}
- /* Clamp bpp to 8 on screens without EDID 1.4 */
- if (info->bpc == 0 && bpp > 24) {
- DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
of 24\n",
- bpp);
- pipe_config->pipe_bpp = 24;
+ switch (conn_state->max_bpc) {
+ case 8:
+ case 9:
+ pipe_config->pipe_bpp = 8 * 3;
+ break;
+ case 10:
+ case 11:
+ pipe_config->pipe_bpp = 10 * 3;
+ break;
+ case 12:
+ case 13:
+ case 14:
+ case 15:
+ pipe_config->pipe_bpp = 12 * 3;
+ break;
+ case 16:
+ pipe_config->pipe_bpp = 16 * 3;
+ break;
+ default:
+ break;
}
+
+ DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
}
static int
@@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
if (connector_state->crtc != &crtc->base)
continue;
- connected_sink_compute_bpp(to_intel_connector(connector),
- pipe_config);
+ connected_sink_max_bpp(connector_state, pipe_config);
}
return bpp;
diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 436c22de33b6..aefca1d9e87b 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
+ if ((IS_G4X(dev_priv) || IS_VALLEYVIEW(dev_priv) ||
+IS_CHERRYVIEW(dev_priv)))
+ drm_connector_attach_max_bpc_property(connector, 8, 10);
+ else if (INTEL_GEN(dev_priv) >= 5)
+ drm_connector_attach_max_bpc_property(connector, 8, 12);
if (intel_dp_is_edp(intel_dp)) {
u32 allowed_scalers;
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c
b/drivers/gpu/drm/i915/intel_hdmi.c
index a2dab0b6bde6..2b432c7e4f8a 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -2109,11 +2109,16 @@ static const struct drm_encoder_funcs
intel_hdmi_enc_funcs = {
static void
intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi, struct drm_connector
*connector)
{
+ struct drm_i915_private *dev_priv = to_i915(connector->dev);
+
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
intel_attach_aspect_ratio_property(connector);
drm_connector_attach_content_type_property(connector);
connector->state->picture_aspect_ratio = HDMI_PICTURE_ASPECT_N
[PATCH v8 1/2] drm: Add connector property to limit max bpc
At times 12bpc HDMI cannot be driven due to faulty cables, dongles
level shifters etc. To workaround them we may need to drive the output
at a lower bpc. Currently the user space does not have a way to limit
the bpc. The default bpc to be programmed is decided by the driver and
is run against connector limitations.
Creating a new connector property "max bpc" in order to limit the bpc.
xrandr can make use of this connector property to make sure that bpc does
not exceed the configured value. This property can be used by userspace to
set the bpc.
V2: Initialize max_bpc to satisfy kms_properties
V3: Move the property to drm_connector
V4: Split drm and i915 components(Ville)
V5: Make the property per connector(Ville)
V6: Compare the requested bpc to connector bpc(Daniel)
Move the attach_property function to core(Ville)
V7: Fix checkpatch warnings
V8: Simplify the connector check code(Ville)
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Kishore Kadiyala
Cc: Rodrigo Vivi
Cc: Manasi Navare
Cc: Stanislav Lisovskiy
Signed-off-by: Radhakrishna Sripada
---
drivers/gpu/drm/drm_atomic.c| 5 +
drivers/gpu/drm/drm_atomic_helper.c | 4
drivers/gpu/drm/drm_atomic_uapi.c | 4
drivers/gpu/drm/drm_connector.c | 33 +
include/drm/drm_connector.h | 20
5 files changed, 66 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index 2870ae205237..dc76e89c04af 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
{
struct drm_crtc_state *crtc_state;
struct drm_writeback_job *writeback_job = state->writeback_job;
+ struct drm_display_info *info = &connector->display_info;
if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
!writeback_job)
return 0;
@@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct drm_connector
*connector,
return -EINVAL;
}
+ state->max_bpc = info->bpc ?: 8;
+ if (connector->max_bpc_property)
+ state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
+
return 0;
}
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 3cf1aa132778..d9ce8077fb6a 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
if (old_connector_state->link_status !=
new_connector_state->link_status)
new_crtc_state->connectors_changed = true;
+
+ if (old_connector_state->max_requested_bpc !=
+ new_connector_state->max_requested_bpc)
+ new_crtc_state->connectors_changed = true;
}
if (funcs->atomic_check)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index d5b7f315098c..86ac33922b09 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
drm_connector *connector,
return set_out_fence_for_connector(state->state, connector,
fence_ptr);
+ } else if (property == connector->max_bpc_property) {
+ state->max_requested_bpc = val;
} else if (connector->funcs->atomic_set_property) {
return connector->funcs->atomic_set_property(connector,
state, property, val);
@@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == config->writeback_out_fence_ptr_property) {
*val = 0;
+ } else if (property == connector->max_bpc_property) {
+ *val = state->max_requested_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 1e40e5decbe9..65e22c1b37a5 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
drm_connector *connector,
EXPORT_SYMBOL(drm_connector_set_link_status_property);
/**
+ * drm_connector_attach_max_bpc_property - attach "max bpc" property
+ * @connector: connector to attach max bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to add support for limiting the bit depth on a connector.
+ *
+
Re: [PATCH v2 1/8] drm/bridge: use bus flags in bridge timings
On 14.09.2018 02:23, Laurent Pinchart wrote:
> Hi Stefan,
>
> Thankk you for the patch.
>
> On Wednesday, 12 September 2018 21:32:15 EEST Stefan Agner wrote:
>> The DRM bus flags conveys additional information on pixel data on
>> the bus. All currently available bus flags might be of interest for
>> a bridge. In the case at hand a dumb VGA bridge needs a specific
>> data enable polarity (DRM_BUS_FLAG_DE_LOW).
>>
>> Replace the sampling_edge field with input_bus_flags and allow all
>> currently documented bus flags.
>>
>> This changes the perspective from sampling side to the driving
>> side for the currently supported flags. We assume that the sampling
>> edge is always the opposite of the driving edge (hence we need to
>> invert the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE flags). This is an
>> assumption we already make for displays. For all we know it is a
>> safe assumption for bridges too.
>
> Please don't, that will get confusing very quickly. Flag names such as
> DRM_BUS_FLAG_PIXDATA_NEGEDGE don't mention sampling or driving. There's only
> a
> small comment next to their definition, which will easily be overlooked. I'd
> rather update the definition to cover both sampling and driving, and document
> the input_bus_flags field to explain that all flags refer to sampling.
>
There is history to that, and I'd really rather prefer to keep that similar
across the kernel. There is already precedence in the kernel, the display
timings (which is a consumer) defines it from the driving perspective too (see
DISPLAY_FLAGS_PIXDATA_POSEDGE).
That is why I introduced the bus flags using the same perspective.
If we _really_ want it from sampling side, we should create new defines which
are explicit about that, e.g.: DRM_BUS_FLAG_PIXDATA_SAMPLE_NEGEDGE.
But again, since even the display flags use the driving perspective, I'd rather
prefer to have it that way also for bridges too.
--
Stefan
>> Signed-off-by: Stefan Agner
>> ---
>> drivers/gpu/drm/bridge/dumb-vga-dac.c | 6 +++---
>> include/drm/drm_bridge.h | 11 +--
>> 2 files changed, 8 insertions(+), 9 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> b/drivers/gpu/drm/bridge/dumb-vga-dac.c index 9b706789a341..d5aa0f931ef2
>> 100644
>> --- a/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> +++ b/drivers/gpu/drm/bridge/dumb-vga-dac.c
>> @@ -234,7 +234,7 @@ static int dumb_vga_remove(struct platform_device *pdev)
>> */
>> static const struct drm_bridge_timings default_dac_timings = {
>> /* Timing specifications, datasheet page 7 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> .setup_time_ps = 500,
>> .hold_time_ps = 1500,
>> };
>> @@ -245,7 +245,7 @@ static const struct drm_bridge_timings
>> default_dac_timings = { */
>> static const struct drm_bridge_timings ti_ths8134_dac_timings = {
>> /* From timing diagram, datasheet page 9 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> /* From datasheet, page 12 */
>> .setup_time_ps = 3000,
>> /* I guess this means latched input */
>> @@ -258,7 +258,7 @@ static const struct drm_bridge_timings
>> ti_ths8134_dac_timings = { */
>> static const struct drm_bridge_timings ti_ths8135_dac_timings = {
>> /* From timing diagram, datasheet page 14 */
>> -.sampling_edge = DRM_BUS_FLAG_PIXDATA_POSEDGE,
>> +.input_bus_flags = DRM_BUS_FLAG_PIXDATA_NEGEDGE,
>> /* From datasheet, page 16 */
>> .setup_time_ps = 2000,
>> .hold_time_ps = 500,
>> diff --git a/include/drm/drm_bridge.h b/include/drm/drm_bridge.h
>> index bd850747ce54..45e90f4b46c3 100644
>> --- a/include/drm/drm_bridge.h
>> +++ b/include/drm/drm_bridge.h
>> @@ -244,14 +244,13 @@ struct drm_bridge_funcs {
>> */
>> struct drm_bridge_timings {
>> /**
>> - * @sampling_edge:
>> + * @input_bus_flags:
>> *
>> - * Tells whether the bridge samples the digital input signal
>> - * from the display engine on the positive or negative edge of the
>> - * clock, this should reuse the DRM_BUS_FLAG_PIXDATA_[POS|NEG]EDGE
>> - * bitwise flags from the DRM connector (bit 2 and 3 valid).
>> + * Additional settings this bridge requires for the pixel data on
>> + * the input bus (e.g. pixel signal polarity). See also
>> + * &drm_display_info->bus_flags.
>> */
>> -u32 sampling_edge;
>> +u32 input_bus_flags;
>> /**
>> * @setup_time_ps:
>> *
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 2/2] drm/i915: Allow "max bpc" property to limit pipe_bpp
On Tue, Sep 18, 2018 at 11:11:15AM -0700, Radhakrishna Sripada wrote:
> Use the newly added "max bpc" connector property to limit pipe bpp.
>
> V3: Use drm_connector_state to access the "max bpc" property
> V4: Initialize the drm property, add suuport to DP(Ville)
> V5: Use the property in the connector and fix CI failure(Ville)
> V6: Use the core function to attach max_bpc property, remove the redundant
> clamping of pipe bpp based on connector info
> V7: Fix Checkpatch warnings
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Rodrigo Vivi
> Cc: Kishore Kadiyala
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/i915/intel_display.c | 49
>
> drivers/gpu/drm/i915/intel_dp.c | 5
> drivers/gpu/drm/i915/intel_hdmi.c| 5
> 3 files changed, 38 insertions(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index eb25037d7b38..75afd53590b1 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -10845,29 +10845,37 @@ static void
> intel_modeset_update_connector_atomic_state(struct drm_device *dev)
> }
>
> static void
> -connected_sink_compute_bpp(struct intel_connector *connector,
> -struct intel_crtc_state *pipe_config)
> +connected_sink_max_bpp(struct drm_connector_state *conn_state,
> +struct intel_crtc_state *pipe_config)
> {
> - const struct drm_display_info *info = &connector->base.display_info;
> - int bpp = pipe_config->pipe_bpp;
> -
> - DRM_DEBUG_KMS("[CONNECTOR:%d:%s] checking for sink bpp constrains\n",
> - connector->base.base.id,
> - connector->base.name);
> -
> - /* Don't use an invalid EDID bpc value */
> - if (info->bpc != 0 && info->bpc * 3 < bpp) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to EDID reported
> max of %d\n",
> - bpp, info->bpc * 3);
> - pipe_config->pipe_bpp = info->bpc * 3;
> + if (pipe_config->pipe_bpp < conn_state->max_bpc * 3) {
> + conn_state->max_bpc = pipe_config->pipe_bpp / 3;
> + return;
This back and forth between max_bpc and pipe_bpp is a bit confusing.
I'd probably leave max_bpc alone here and just update pipe_bpp as
needed.
> }
>
> - /* Clamp bpp to 8 on screens without EDID 1.4 */
> - if (info->bpc == 0 && bpp > 24) {
> - DRM_DEBUG_KMS("clamping display bpp (was %d) to default limit
> of 24\n",
> - bpp);
> - pipe_config->pipe_bpp = 24;
> + switch (conn_state->max_bpc) {
This is missing the 6bpc case at least. I suppose the current code
isn't particuraly robust against unexpected values coming via
info->bpc. The switch statement does seem an improvement in that
regard. Though would be nice to compact it a bit using eg. the gcc
case range extension.
> + case 8:
> + case 9:
> + pipe_config->pipe_bpp = 8 * 3;
> + break;
> + case 10:
> + case 11:
> + pipe_config->pipe_bpp = 10 * 3;
> + break;
> + case 12:
> + case 13:
> + case 14:
> + case 15:
With the proposed min() we'd never get bpc > 12 here.
> + pipe_config->pipe_bpp = 12 * 3;
> + break;
> + case 16:
> + pipe_config->pipe_bpp = 16 * 3;
> + break;
> + default:
> + break;
Maybe just return an error here. I suppose it should never happen unless
there's some bogus displays out there that report < 6 bpc.
> }
> +
> + DRM_DEBUG_KMS("Limiting display bpp to %d\n", pipe_config->pipe_bpp);
Would be nice to include all the relevant information in this debug
print: original pipe_bpp, info->bpc*3, max_requested_bpc.
Maybe something like this would work to keep the code easy to read:
{
bpp = min(pipe_bpp, max_bpc*3);
switch (bpp) {
...
}
if (bpp != pipe_bpp) {
DRM_DEBUG_KMS(...);
pipe_bpp = bpp;
}
}
> }
>
> static int
> @@ -10898,8 +10906,7 @@ compute_baseline_pipe_bpp(struct intel_crtc *crtc,
> if (connector_state->crtc != &crtc->base)
> continue;
>
> - connected_sink_compute_bpp(to_intel_connector(connector),
> -pipe_config);
> + connected_sink_max_bpp(connector_state, pipe_config);
> }
>
> return bpp;
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 436c22de33b6..aefca1d9e87b 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -5719,6 +5719,11 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_force_audio_property(connector)
Re: [PATCH v8 1/2] drm: Add connector property to limit max bpc
On Tue, Sep 18, 2018 at 11:11:14AM -0700, Radhakrishna Sripada wrote:
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
> V7: Fix checkpatch warnings
> V8: Simplify the connector check code(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 5 +
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 33 +
> include/drm/drm_connector.h | 20
> 5 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2870ae205237..dc76e89c04af 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = &connector->display_info;
Can be const.
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + state->max_bpc = info->bpc ?: 8;
> + if (connector->max_bpc_property)
> + state->max_bpc = min(state->max_bpc, state->max_requested_bpc);
Hopefully this logic is generic enough to work for most drivers.
I haven't actually checked what anyone else does with info->bpc.
Reviewed-by: Ville Syrjälä
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
> fence_ptr);
> + } else if (property == connector->max_bpc_property) {
> + state->max_requested_bpc = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == config->writeback_out_fence_ptr_property) {
> *val = 0;
> + } else if (property == connector->max_bpc_property) {
> + *val = state->max_requested_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..65e22c1b37a5 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
Thanks Imre for your review comments. Please find the comments below:
On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > On Icelake, a separate power well PG2 is created for
> > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > display power domain for Power well 2.
> >
> > Cc: Rodrigo Vivi
> > Cc: Imre Deak
> > Signed-off-by: Manasi Navare
> > ---
> > drivers/gpu/drm/i915/intel_display.h| 1 +
> > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > 2 files changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > b/drivers/gpu/drm/i915/intel_display.h
> > index 3fe52788b4cf..bef71d27cdfe 100644
> > --- a/drivers/gpu/drm/i915/intel_display.h
> > +++ b/drivers/gpu/drm/i915/intel_display.h
> > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > POWER_DOMAIN_MODESET,
> > POWER_DOMAIN_GT_IRQ,
> > POWER_DOMAIN_INIT,
> > + POWER_DOMAIN_VDSC_EDP_MIPI,
>
> This is better named VDSC_PIPE_A. The other pipes have also VDSC
> functionality which could be on separate power wells in the future.
>
Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
will use this VDSC power well.
I will change this in the next revision.
> >
> > POWER_DOMAIN_NUM,
> > };
> > diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > index 480dadb1047b..146e2d6cf954 100644
> > --- a/drivers/gpu/drm/i915/intel_runtime_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
> > @@ -146,6 +146,8 @@ intel_display_power_domain_str(enum
> > intel_display_power_domain domain)
> > return "MODESET";
> > case POWER_DOMAIN_GT_IRQ:
> > return "GT_IRQ";
> > + case POWER_DOMAIN_VDSC_EDP_MIPI:
> > + return "VDSC_EDP_MIPI";
> > default:
> > MISSING_CASE(domain);
> > return "?";
> > @@ -1966,18 +1968,16 @@ void intel_display_power_put(struct
> > drm_i915_private *dev_priv,
> > BIT_ULL(POWER_DOMAIN_AUDIO) | \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > /*
> > -* - transcoder WD
> > -* - KVMR (HW control)
> > +* - eDP/MIPI DSI VDSC
>
> We're not changing anything in the PW3 domains list, so why changing
> the above?
These comments are below the PW3 domains define and before the PW2 domains
define.
So I thought they were for PW2 domains define. Is that not the case?
If its for PW3 then I can keep them as is and if its for PW2 then we should have
eDP/DSI VDSC , KVMR since KVMR will enable PW2 and PW3. But why have Transcoder
WD comment
for PW2?
>
> > */
> > #define ICL_PW_2_POWER_DOMAINS ( \
> > - ICL_PW_3_POWER_DOMAINS |\
> > - BIT_ULL(POWER_DOMAIN_INIT))
>
> The above is bogus, both the PW3 domains and the INIT domain should
> stay included in the list of PW2 domains.
Okay I will add the PW2 and INIT domains back
>
> > + BIT_ULL(POWER_DOMAIN_VDSC_EDP_MIPI))
> > /*
> > -* - eDP/DSI VDSC
> > +* - transcoder WD
>
> Why adding here the transcoder WD?
This comment is above PW3 domains so PW3 domain has Transcoder WD as per Bspec
and no eDP/DSI VDSC on PW3, so removed that.
Am I misreading something here in terms of comments?
So the basic question is the comments are for the PW domains defined above the
comment or
for the PW domain defines below the comment?
Manasi
>
> > * - KVMR (HW control)
> > */
> > #define ICL_DISPLAY_DC_OFF_POWER_DOMAINS ( \
> > - ICL_PW_2_POWER_DOMAINS |\
> > + ICL_PW_3_POWER_DOMAINS |\
>
> The PW2 domain list should stay included in the DC_OFF domain list (and
> so no need to add the PW3 domain list either).
>
> > BIT_ULL(POWER_DOMAIN_MODESET) | \
> > BIT_ULL(POWER_DOMAIN_AUX_A) | \
> > BIT_ULL(POWER_DOMAIN_INIT))
> > --
> > 2.18.0
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> Thanks Imre for your review comments. Please find the comments below:
>
> On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > On Icelake, a separate power well PG2 is created for
> > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > display power domain for Power well 2.
> > >
> > > Cc: Rodrigo Vivi
> > > Cc: Imre Deak
> > > Signed-off-by: Manasi Navare
> > > ---
> > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > b/drivers/gpu/drm/i915/intel_display.h
> > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > POWER_DOMAIN_MODESET,
> > > POWER_DOMAIN_GT_IRQ,
> > > POWER_DOMAIN_INIT,
> > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> >
> > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > functionality which could be on separate power wells in the future.
> >
>
> Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> will use this VDSC power well.
> I will change this in the next revision.
Isn't the VDSC in the transcoder for now though? And I guess it's
moving to the pipe later?
If we call it PIPE_A then it's going to a bit confusing when we
use it with pipe B or C. Needs at least clear comments in the code
why we're doing something that looks like nonsense of the first
glance.
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > Thanks Imre for your review comments. Please find the comments below:
> >
> > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > On Icelake, a separate power well PG2 is created for
> > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > display power domain for Power well 2.
> > > >
> > > > Cc: Rodrigo Vivi
> > > > Cc: Imre Deak
> > > > Signed-off-by: Manasi Navare
> > > > ---
> > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > POWER_DOMAIN_MODESET,
> > > > POWER_DOMAIN_GT_IRQ,
> > > > POWER_DOMAIN_INIT,
> > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > >
> > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > functionality which could be on separate power wells in the future.
> > >
> >
> > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > will use this VDSC power well.
> > I will change this in the next revision.
>
> Isn't the VDSC in the transcoder for now though? And I guess it's
> moving to the pipe later?
VDSC engine is attached to the eDP/DSI transcoders and this gets used
for eDP/DSI VDSC on Pipe A.
So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
will use this power well. But may be we should add a comment that
this is only for eDP/DSI on Pipe A since ICL does not support
VDSC on DP on Pipe A
What do you think?
Manasi
>
> If we call it PIPE_A then it's going to a bit confusing when we
> use it with pipe B or C. Needs at least clear comments in the code
> why we're doing something that looks like nonsense of the first
> glance.
>
> --
> Ville Syrjälä
> Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > Thanks Imre for your review comments. Please find the comments below:
> > >
> > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > On Icelake, a separate power well PG2 is created for
> > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > display power domain for Power well 2.
> > > > >
> > > > > Cc: Rodrigo Vivi
> > > > > Cc: Imre Deak
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > POWER_DOMAIN_MODESET,
> > > > > POWER_DOMAIN_GT_IRQ,
> > > > > POWER_DOMAIN_INIT,
> > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > >
> > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > functionality which could be on separate power wells in the future.
> > > >
> > >
> > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > > will use this VDSC power well.
> > > I will change this in the next revision.
> >
> > Isn't the VDSC in the transcoder for now though? And I guess it's
> > moving to the pipe later?
>
> VDSC engine is attached to the eDP/DSI transcoders and this gets used
> for eDP/DSI VDSC on Pipe A.
And what happens when I want to use pipe B instead?
> So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> will use this power well. But may be we should add a comment that
> this is only for eDP/DSI on Pipe A since ICL does not support
> VDSC on DP on Pipe A
>
> What do you think?
>
> Manasi
>
> >
> > If we call it PIPE_A then it's going to a bit confusing when we
> > use it with pipe B or C. Needs at least clear comments in the code
> > why we're doing something that looks like nonsense of the first
> > glance.
> >
> > --
> > Ville Syrjälä
> > Intel
--
Ville Syrjälä
Intel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v8 1/2] drm: Add connector property to limit max bpc
+ Harry, Leo
This would definitely be useful. We ran into a lot of issues when we
enabled >8 bpc support.
On Tue, Sep 18, 2018 at 2:10 PM Radhakrishna Sripada
wrote:
>
> At times 12bpc HDMI cannot be driven due to faulty cables, dongles
> level shifters etc. To workaround them we may need to drive the output
> at a lower bpc. Currently the user space does not have a way to limit
> the bpc. The default bpc to be programmed is decided by the driver and
> is run against connector limitations.
>
> Creating a new connector property "max bpc" in order to limit the bpc.
> xrandr can make use of this connector property to make sure that bpc does
> not exceed the configured value. This property can be used by userspace to
> set the bpc.
>
> V2: Initialize max_bpc to satisfy kms_properties
> V3: Move the property to drm_connector
> V4: Split drm and i915 components(Ville)
> V5: Make the property per connector(Ville)
> V6: Compare the requested bpc to connector bpc(Daniel)
> Move the attach_property function to core(Ville)
> V7: Fix checkpatch warnings
> V8: Simplify the connector check code(Ville)
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Kishore Kadiyala
> Cc: Rodrigo Vivi
> Cc: Manasi Navare
> Cc: Stanislav Lisovskiy
> Signed-off-by: Radhakrishna Sripada
> ---
> drivers/gpu/drm/drm_atomic.c| 5 +
> drivers/gpu/drm/drm_atomic_helper.c | 4
> drivers/gpu/drm/drm_atomic_uapi.c | 4
> drivers/gpu/drm/drm_connector.c | 33 +
> include/drm/drm_connector.h | 20
> 5 files changed, 66 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2870ae205237..dc76e89c04af 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -390,6 +390,7 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> {
> struct drm_crtc_state *crtc_state;
> struct drm_writeback_job *writeback_job = state->writeback_job;
> + struct drm_display_info *info = &connector->display_info;
>
> if ((connector->connector_type != DRM_MODE_CONNECTOR_WRITEBACK) ||
> !writeback_job)
> return 0;
> @@ -417,6 +418,10 @@ static int drm_atomic_connector_check(struct
> drm_connector *connector,
> return -EINVAL;
> }
>
> + state->max_bpc = info->bpc ?: 8;
> + if (connector->max_bpc_property)
> + state->max_bpc = min(state->max_bpc,
> state->max_requested_bpc);
> +
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 3cf1aa132778..d9ce8077fb6a 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -639,6 +639,10 @@ drm_atomic_helper_check_modeset(struct drm_device *dev,
> if (old_connector_state->link_status !=
> new_connector_state->link_status)
> new_crtc_state->connectors_changed = true;
> +
> + if (old_connector_state->max_requested_bpc !=
> + new_connector_state->max_requested_bpc)
> + new_crtc_state->connectors_changed = true;
> }
>
> if (funcs->atomic_check)
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index d5b7f315098c..86ac33922b09 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -740,6 +740,8 @@ static int drm_atomic_connector_set_property(struct
> drm_connector *connector,
>
> return set_out_fence_for_connector(state->state, connector,
>fence_ptr);
> + } else if (property == connector->max_bpc_property) {
> + state->max_requested_bpc = val;
> } else if (connector->funcs->atomic_set_property) {
> return connector->funcs->atomic_set_property(connector,
> state, property, val);
> @@ -804,6 +806,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == config->writeback_out_fence_ptr_property) {
> *val = 0;
> + } else if (property == connector->max_bpc_property) {
> + *val = state->max_requested_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 1e40e5decbe9..65e22c1b37a5 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1583,6 +1583,39 @@ void drm_connector_set_link_status_property(struct
> drm_connector *connector,
> EXPORT_SYMBOL(
Re: [PATCH v4 19/25] drm/i915/dsc: Add a power domain for VDSC on eDP/MIPI DSI
On Tue, Sep 18, 2018 at 10:46:46PM +0300, Ville Syrjälä wrote:
> On Tue, Sep 18, 2018 at 12:31:54PM -0700, Manasi Navare wrote:
> > On Tue, Sep 18, 2018 at 10:12:24PM +0300, Ville Syrjälä wrote:
> > > On Tue, Sep 18, 2018 at 12:04:35PM -0700, Manasi Navare wrote:
> > > > Thanks Imre for your review comments. Please find the comments below:
> > > >
> > > > On Fri, Sep 14, 2018 at 01:55:00PM +0300, Imre Deak wrote:
> > > > > On Tue, Sep 11, 2018 at 05:56:01PM -0700, Manasi Navare wrote:
> > > > > > On Icelake, a separate power well PG2 is created for
> > > > > > VDSC engine used for eDP/MIPI DSI. This patch adds a new
> > > > > > display power domain for Power well 2.
> > > > > >
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Imre Deak
> > > > > > Signed-off-by: Manasi Navare
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/intel_display.h| 1 +
> > > > > > drivers/gpu/drm/i915/intel_runtime_pm.c | 12 ++--
> > > > > > 2 files changed, 7 insertions(+), 6 deletions(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_display.h
> > > > > > b/drivers/gpu/drm/i915/intel_display.h
> > > > > > index 3fe52788b4cf..bef71d27cdfe 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_display.h
> > > > > > +++ b/drivers/gpu/drm/i915/intel_display.h
> > > > > > @@ -256,6 +256,7 @@ enum intel_display_power_domain {
> > > > > > POWER_DOMAIN_MODESET,
> > > > > > POWER_DOMAIN_GT_IRQ,
> > > > > > POWER_DOMAIN_INIT,
> > > > > > + POWER_DOMAIN_VDSC_EDP_MIPI,
> > > > >
> > > > > This is better named VDSC_PIPE_A. The other pipes have also VDSC
> > > > > functionality which could be on separate power wells in the future.
> > > > >
> > > >
> > > > Yea naming it as VDSC_PIPE_A makes sense since eDP/MIPI DSI on Pipe A
> > > > will use this VDSC power well.
> > > > I will change this in the next revision.
> > >
> > > Isn't the VDSC in the transcoder for now though? And I guess it's
> > > moving to the pipe later?
> >
> > VDSC engine is attached to the eDP/DSI transcoders and this gets used
> > for eDP/DSI VDSC on Pipe A.
>
> And what happens when I want to use pipe B instead?
DP VDSC on Pipe B uses the VDSC engine on Pipe B. Same for Pipe C
Can we have a situation where eDP uses Pipe B? Because in case of VDSC
in case of eDP, it will always use the VDSC on transcoder eDP which will
require this power well.
Manasi
>
> > So we could call it VDSC_PIPE_A since VDSC on Pipe A for eDP/DSI
> > will use this power well. But may be we should add a comment that
> > this is only for eDP/DSI on Pipe A since ICL does not support
> > VDSC on DP on Pipe A
> >
> > What do you think?
> >
> > Manasi
> >
> > >
> > > If we call it PIPE_A then it's going to a bit confusing when we
> > > use it with pipe B or C. Needs at least clear comments in the code
> > > why we're doing something that looks like nonsense of the first
> > > glance.
> > >
> > > --
> > > Ville Syrjälä
> > > Intel
>
> --
> Ville Syrjälä
> Intel
> ___
> 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 17/20] drm/tve200: Use drm_fbdev_generic_setup()
On Sat, Sep 8, 2018 at 6:53 AM Noralf Trønnes wrote: > The CMA helper is already using the drm_fb_helper_generic_probe part of > the generic fbdev emulation. This patch makes full use of the generic > fbdev emulation by using its drm_client callbacks. This means that > drm_mode_config_funcs->output_poll_changed and drm_driver->lastclose are > now handled by the emulation code. Additionally fbdev unregister happens > automatically on drm_dev_unregister(). > > The drm_fbdev_generic_setup() call is put after drm_dev_register() in the > driver. This is done to highlight the fact that fbdev emulation is an > internal client that makes use of the driver, it is not part of the > driver as such. If fbdev setup fails, an error is printed, but the driver > succeeds probing. > > Cc: Linus Walleij > Signed-off-by: Noralf Trønnes Acked-by: Linus Walleij Yours, Linus Walleij ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
