Re: [PATCH 4/5] drm/vblank: Restoring vblank counts after device PM events.
On Fri, Jan 12, 2018 at 09:57:06PM +, Dhinakaran Pandiyan wrote:
> The HW frame counter can get reset if device enters a low power state after
> vblank interrupts were disabled. This messes up any following vblank count
> update as a negative diff (huge unsigned diff) is calculated from the HW
> frame counter change. We cannot ignore negative diffs altogther as there
> could be legitimate wrap arounds. So, allow drivers to update vblank->count
> with missed vblanks for the time interrupts were disabled. This is similar
> to _crtc_vblank_on() except that vblanks interrupts are not enabled at the
> end as this function is expected to be called from the driver
> _enable_vblank() vfunc.
>
> v2: drm_crtc_vblank_restore should take crtc as arg. (Chris)
> Add docs and sprinkle some asserts.
>
> Cc: Daniel Vetter
> Cc: Chris Wilson
> Cc: Michel Dänzer
> Signed-off-by: Dhinakaran Pandiyan
> ---
> drivers/gpu/drm/drm_vblank.c | 59
>
> include/drm/drm_vblank.h | 2 ++
> 2 files changed, 61 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> index 2559d2d7b907..2690966694f0 100644
> --- a/drivers/gpu/drm/drm_vblank.c
> +++ b/drivers/gpu/drm/drm_vblank.c
> @@ -1237,6 +1237,65 @@ void drm_crtc_vblank_on(struct drm_crtc *crtc)
> }
> EXPORT_SYMBOL(drm_crtc_vblank_on);
>
> +/**
> + * drm_vblank_restore - estimated vblanks using timestamps and update it.
> + *
> + * Power manamement features can cause frame counter resets between vblank
> + * disable and enable. Drivers can then use this function in their
> + * &drm_crtc_funcs.enable_vblank implementation to estimate the vblanks since
> + * the last &drm_crtc_funcs.disable_vblank.
> + *
> + * This function is the legacy version of drm_crtc_vblank_restore().
> + */
> +void drm_vblank_restore(struct drm_device *dev, unsigned int pipe)
> +{
> + ktime_t t_vblank;
> + struct drm_vblank_crtc *vblank;
> + int framedur_ns;
> + u64 diff_ns;
> + u32 cur_vblank, diff = 1;
> + int count = DRM_TIMESTAMP_MAXRETRIES;
> +
> + if (WARN_ON(pipe >= dev->num_crtcs))
> + return;
> +
> + assert_spin_locked(&dev->vbl_lock);
> + assert_spin_locked(&dev->vblank_time_lock);
> +
> + vblank = &dev->vblank[pipe];
> + WARN_ONCE((drm_debug & DRM_UT_VBL) && !vblank->framedur_ns,
do we really only need this warn on debug vlb?
> + "Cannot compute missed vblanks without frame duration\n");
The message seems hard... if we *cannot* why do we move fwd?
> + framedur_ns = vblank->framedur_ns;
> +
> + do {
> + cur_vblank = __get_vblank_counter(dev, pipe);
> + drm_get_last_vbltimestamp(dev, pipe, &t_vblank, false);
> + } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
Based on the commend of drm_update_vblank_count I don't feel that we have to
do the loop here... And if we have maybe we should re-org things to avoid
duplication?
> +
> + diff_ns = ktime_to_ns(ktime_sub(t_vblank, vblank->time));
> + if (framedur_ns)
> + diff = DIV_ROUND_CLOSEST_ULL(diff_ns, framedur_ns);
> +
> +
> + DRM_DEBUG_VBL("missed %d vblanks in %lld ns, frame duration=%d ns,
> hw_diff=%d\n",
> + diff, diff_ns, framedur_ns, cur_vblank - vblank->last);
> + store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
hm... I wonder if the simple store_vblank(... __get_vblank_counter(dev, pipe));
wouldn't work here...
> +}
> +EXPORT_SYMBOL(drm_vblank_restore);
> +
> +/**
> + * drm_crtc_vblank_restore - estimate vblanks using timestamps and update it.
> + * Power manamement features can cause frame counter resets between vblank
> + * disable and enable. Drivers can then use this function in their
> + * &drm_crtc_funcs.enable_vblank implementation to estimate the vblanks since
> + * the last &drm_crtc_funcs.disable_vblank.
> + */
> +void drm_crtc_vblank_restore(struct drm_crtc *crtc)
> +{
> + drm_vblank_restore(crtc->dev, drm_crtc_index(crtc));
> +}
> +EXPORT_SYMBOL(drm_crtc_vblank_restore);
> +
> static void drm_legacy_vblank_pre_modeset(struct drm_device *dev,
> unsigned int pipe)
> {
> diff --git a/include/drm/drm_vblank.h b/include/drm/drm_vblank.h
> index a4c3b0a0a197..16d46e2a6854 100644
> --- a/include/drm/drm_vblank.h
> +++ b/include/drm/drm_vblank.h
> @@ -180,6 +180,8 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc);
> void drm_crtc_vblank_reset(struct drm_crtc *crtc);
> void drm_crtc_vblank_on(struct drm_crtc *crtc);
> u64 drm_crtc_accurate_vblank_count(struct drm_crtc *crtc);
> +void drm_vblank_restore(struct drm_device *dev, unsigned int pipe);
> +void drm_crtc_vblank_restore(struct drm_crtc *crtc);
>
> bool drm_calc_vbltimestamp_from_scanoutpos(struct drm_device *dev,
> unsigned int pipe, int *max_error,
> --
> 2.11.0
>
___
Re: [Intel-gfx] [PATCH 1/5] drm/vblank: Fix return type for drm_vblank_count()
On Fri, Jan 19, 2018 at 04:53:34AM +, Pandiyan, Dhinakaran wrote:
> ping for review.
sorry for not getting back sooner here.
But yey \o/
I finally have dmc and psr working well on my own laptop!
so far so good! :)
>
> Let me know if there's anything that needs to be done, thanks!
>
>
> On Fri, 2018-01-12 at 13:57 -0800, Dhinakaran Pandiyan wrote:
> > drm_vblank_count() has a u32 type returning what is a 64-bit vblank count.
> > The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> > space requested vblank sequence using this clipped 32-bit count(when the
> > value is >= 2^32) as reference, the requested sequence remains a 32-bit
> > value and gets queued like that. However, the code that checks if the
> > requested sequence has passed compares this against the 64-bit vblank
> > count.
> >
> > Cc: Keith Packard
> > Cc: Michel Dänzer
> > Cc: Daniel Vetter
> > Signed-off-by: Dhinakaran Pandiyan
> > ---
> > drivers/gpu/drm/drm_vblank.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c
> > index 32d9bcf5be7f..768a8e44d99b 100644
> > --- a/drivers/gpu/drm/drm_vblank.c
> > +++ b/drivers/gpu/drm/drm_vblank.c
> > @@ -271,7 +271,7 @@ static void drm_update_vblank_count(struct drm_device
> > *dev, unsigned int pipe,
> > store_vblank(dev, pipe, diff, t_vblank, cur_vblank);
> > }
> >
> > -static u32 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > +static u64 drm_vblank_count(struct drm_device *dev, unsigned int pipe)
> > {
> > struct drm_vblank_crtc *vblank = &dev->vblank[pipe];
> >
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104696] line_smooth in the endpoints is not take effect
https://bugs.freedesktop.org/show_bug.cgi?id=104696 Bug ID: 104696 Summary: line_smooth in the endpoints is not take effect Product: Mesa Version: unspecified Hardware: x86 (IA32) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/Gallium/radeonsi Assignee: dri-devel@lists.freedesktop.org Reporter: yhan...@163.com QA Contact: dri-devel@lists.freedesktop.org When use line_smooth, if it's a oblique line and make the wide bigger you will find the line_smooth is effect in the middle of the line but in the end of line it's like a line not use line_smooth, but if we use the swrast the line is look good. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/ttm: add the missed global memory count update
when ttm_mem_global_alloc_page fails, we should call
ttm_mem_global_free_page to update memory count for
the ttm pages which already run ttm_mem_global_alloc_page
successfully
Signed-off-by: Roger He
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 41 ++--
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2b12c55a..9ec2021 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1063,6 +1063,28 @@ void ttm_page_alloc_fini(void)
_manager = NULL;
}
+static void
+ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned mem_count_update)
+{
+ unsigned i;
+
+ if (mem_count_update == 0)
+ goto put_pages;
+
+ for (i = 0; i < mem_count_update; ++i) {
+ if (!ttm->pages[i])
+ continue;
+
+ ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
+PAGE_SIZE);
+ }
+
+put_pages:
+ ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
+ ttm->caching_state);
+ ttm->state = tt_unpopulated;
+}
+
int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
{
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
@@ -1075,8 +1097,7 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct
ttm_operation_ctx *ctx)
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
if (unlikely(ret != 0)) {
- ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
- ttm->caching_state);
+ ttm_pool_unpopulate_helper(ttm, 0);
return ret;
}
@@ -1084,8 +1105,7 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct
ttm_operation_ctx *ctx)
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
PAGE_SIZE, ctx);
if (unlikely(ret != 0)) {
- ttm_put_pages(ttm->pages, ttm->num_pages,
- ttm->page_flags, ttm->caching_state);
+ ttm_pool_unpopulate_helper(ttm, i);
return -ENOMEM;
}
}
@@ -1105,18 +1125,7 @@ EXPORT_SYMBOL(ttm_pool_populate);
void ttm_pool_unpopulate(struct ttm_tt *ttm)
{
- unsigned i;
-
- for (i = 0; i < ttm->num_pages; ++i) {
- if (!ttm->pages[i])
- continue;
-
- ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
-PAGE_SIZE);
- }
- ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
- ttm->caching_state);
- ttm->state = tt_unpopulated;
+ ttm_pool_unpopulate_helper(ttm, ttm->num_pages);
}
EXPORT_SYMBOL(ttm_pool_unpopulate);
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
Am 19.01.2018 um 06:39 schrieb He, Roger:
Basically the idea is right to me.
1. But we need smaller granularity to control the contribution to OOM badness.
Because when the TTM buffer resides in VRAM rather than evict to system
memory, we should not take this account into badness.
But I think it is not easy to implement.
I was considering that as well when I wrote the original patch set, but
then decided against it at least for now.
Basically all VRAM buffers can be swapped to system memory, so they
potentially need system memory as well. That is especially important
during suspend/resume.
2. If the TTM buffer(GTT here) is mapped to user for CPU access, not quite sure
the buffer size is already taken into account for kernel.
If yes, at last the size will be counted again by your patches.
No that isn't accounted for as far as I know.
So, I am thinking if we can counted the TTM buffer size into:
struct mm_rss_stat {
atomic_long_t count[NR_MM_COUNTERS];
};
Which is done by kernel based on CPU VM (page table).
Something like that:
When GTT allocate suceess:
add_mm_counter(vma->vm_mm, MM_ANONPAGES, buffer_size);
When GTT swapped out:
dec_mm_counter from MM_ANONPAGES frist, then
add_mm_counter(vma->vm_mm, MM_SWAPENTS, buffer_size); // or MM_SHMEMPAGES or
add new item.
Update the corresponding item in mm_rss_stat always.
If that, we can control the status update accurately.
What do you think about that?
And is there any side-effect for this approach?
I already tried this when I originally worked on the issue and that
approach didn't worked because allocated buffers are not associated to
the process where they are created.
E.g. most display surfaces are created by the X server, but used by
processes. So if you account the BO to the process who created it we
would start to kill X again and that is exactly what we try to avoid.
Regards,
Christian.
Thanks
Roger(Hongbo.He)
-Original Message-
From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of
Andrey Grodzovsky
Sent: Friday, January 19, 2018 12:48 AM
To: linux-ker...@vger.kernel.org; linux...@kvack.org;
dri-devel@lists.freedesktop.org; amd-...@lists.freedesktop.org
Cc: Koenig, Christian
Subject: [RFC] Per file OOM badness
Hi, this series is a revised version of an RFC sent by Christian König a few
years ago. The original RFC can be found at
https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html
This is the same idea and I've just adressed his concern from the original RFC
and switched to a callback into file_ops instead of a new member in struct file.
Thanks,
Andrey
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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: [RFC] Per file OOM badness
Am 18.01.2018 um 21:01 schrieb Eric Anholt: Michal Hocko writes: [SNIP] But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. Maybe some more context would help the discussion? Thanks for doing this. Wanted to reply yesterday with that information as well, but was unfortunately on sick leave. The struct file in patch 3 is the DRM fd. That's effectively "my process's interface to talking to the GPU" not "a single GPU resource". Once that file is closed, all of the process's private, idle GPU buffers will be immediately freed (this will be most of their allocations), and some will be freed once the GPU completes some work (this will be most of the rest of their allocations). Some GEM BOs won't be freed just by closing the fd, if they've been shared between processes. Those are usually about 8-24MB total in a process, rather than the GBs that modern apps use (or that our testcases like to allocate and thus trigger oomkilling of the test harness instead of the offending testcase...) Even if we just had the private+idle buffers being accounted in OOM badness, that would be a huge step forward in system reliability. Yes, and that's exactly the intention here because currently the OOM killer usually kills X when a graphics related application allocates to much memory and that is highly undesirable. : So question at every one: What do you think about this approach? I thing is just just wrong semantically. Non-reclaimable memory is a pain, especially when there is way too much of it. If you can free that memory somehow then you can hook into slab shrinker API and react on the memory pressure. If you can account such a memory to a particular process and make sure that the consumption is bound by the process life time then we can think of an accounting that oom_badness can consider when selecting a victim. For graphics, we can't free most of our memory without also effectively killing the process. i915 and vc4 have "purgeable" interfaces for userspace (on i915 this is exposed all the way to GL applications and is hooked into shrinker, and on vc4 this is so far just used for userspace-internal buffer caches to be purged when a CMA allocation fails). However, those purgeable pools are expected to be a tiny fraction of the GPU allocations by the process. Same thing with TTM and amdgpu/radeon. We already have a shrinker hock as well and make room as much as we can when needed. But I think Michal's concerns are valid as well and I thought about them when I created the initial patch. One possible solution which came to my mind is that (IIRC) we not only store the usual reference count per GEM object, but also how many handles where created for it. So what we could do is to iterate over all GEM handles of a client and account only size/num_handles as badness for the client. The end result would be that X and the client application would both get 1/2 of the GEM objects size accounted for. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: Michal Hocko writes: On Thu 18-01-18 18:00:06, Michal Hocko wrote: On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struct file. Please add the full description to the cover letter and do not make people hunt links. Here is the origin cover letter text : I'm currently working on the issue that when device drivers allocate memory on : behalf of an application the OOM killer usually doesn't knew about that unless : the application also get this memory mapped into their address space. : : This is especially annoying for graphics drivers where a lot of the VRAM : usually isn't CPU accessible and so doesn't make sense to map into the : address space of the process using it. : : The problem now is that when an application starts to use a lot of VRAM those : buffers objects sooner or later get swapped out to system memory, but when we : now run into an out of memory situation the OOM killer obviously doesn't knew : anything about that memory and so usually kills the wrong process. OK, but how do you attribute that memory to a particular OOM killable entity? And how do you actually enforce that those resources get freed on the oom killer action? : The following set of patches tries to address this problem by introducing a per : file OOM badness score, which device drivers can use to give the OOM killer a : hint how many resources are bound to a file descriptor so that it can make : better decisions which process to kill. But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. Maybe some more context would help the discussion? The struct file in patch 3 is the DRM fd. That's effectively "my process's interface to talking to the GPU" not "a single GPU resource". Once that file is closed, all of the process's private, idle GPU buffers will be immediately freed (this will be most of their allocations), and some will be freed once the GPU completes some work (this will be most of the rest of their allocations). Some GEM BOs won't be freed just by closing the fd, if they've been shared between processes. Those are usually about 8-24MB total in a process, rather than the GBs that modern apps use (or that our testcases like to allocate and thus trigger oomkilling of the test harness instead of the offending testcase...) Even if we just had the private+idle buffers being accounted in OOM badness, that would be a huge step forward in system reliability. OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. I already tried that and the problem with that approach is that some buffers are not created by the application which actually uses them. For example X/Wayland is creating and handing out render buffers to application which want to use OpenGL. So the result is when you always account the application who created the buffer the OOM killer will certainly reap X/Wayland first. And that is exactly what we want to avoid here. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #18 from Christian König --- Please stop attaching more and more dmesg with unrelated information to the bug report. The initial one is perfectly sufficient. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: fix missing parameter change for ttm_bo_cleanup_refs
Am 19.01.2018 um 07:42 schrieb Roger He:
Missed in the patche:
dc94777 drm/ttm: enable swapout for reserved BOs during allocation.
don't unreserve the BO if it is not reserved by itself.
Signed-off-by: Roger He
Reviewed-by: Christian König .
I already wondered if we shouldn't use "locked" somewhere else as well,
Christian.
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 893003f..2fef09a 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1727,7 +1727,7 @@ int ttm_bo_swapout(struct ttm_bo_global *glob, struct
ttm_operation_ctx *ctx)
kref_get(&bo->list_kref);
if (!list_empty(&bo->ddestroy)) {
- ret = ttm_bo_cleanup_refs(bo, false, false, true);
+ ret = ttm_bo_cleanup_refs(bo, false, false, locked);
kref_put(&bo->list_kref, ttm_bo_release_list);
return ret;
}
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm/ttm: add the missed global memory count update
Am 19.01.2018 um 09:11 schrieb Roger He:
when ttm_mem_global_alloc_page fails, we should call
ttm_mem_global_free_page to update memory count for
the ttm pages which already run ttm_mem_global_alloc_page
successfully
Signed-off-by: Roger He
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_page_alloc.c | 41 ++--
1 file changed, 25 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_page_alloc.c
b/drivers/gpu/drm/ttm/ttm_page_alloc.c
index 2b12c55a..9ec2021 100644
--- a/drivers/gpu/drm/ttm/ttm_page_alloc.c
+++ b/drivers/gpu/drm/ttm/ttm_page_alloc.c
@@ -1063,6 +1063,28 @@ void ttm_page_alloc_fini(void)
_manager = NULL;
}
+static void
+ttm_pool_unpopulate_helper(struct ttm_tt *ttm, unsigned mem_count_update)
+{
+ unsigned i;
+
+ if (mem_count_update == 0)
+ goto put_pages;
+
+ for (i = 0; i < mem_count_update; ++i) {
+ if (!ttm->pages[i])
+ continue;
+
+ ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
+PAGE_SIZE);
+ }
+
+put_pages:
+ ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
+ ttm->caching_state);
+ ttm->state = tt_unpopulated;
+}
+
int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
{
struct ttm_mem_global *mem_glob = ttm->glob->mem_glob;
@@ -1075,8 +1097,7 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct
ttm_operation_ctx *ctx)
ret = ttm_get_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
ttm->caching_state);
if (unlikely(ret != 0)) {
- ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
- ttm->caching_state);
+ ttm_pool_unpopulate_helper(ttm, 0);
return ret;
}
@@ -1084,8 +1105,7 @@ int ttm_pool_populate(struct ttm_tt *ttm, struct ttm_operation_ctx *ctx)
ret = ttm_mem_global_alloc_page(mem_glob, ttm->pages[i],
PAGE_SIZE, ctx);
if (unlikely(ret != 0)) {
- ttm_put_pages(ttm->pages, ttm->num_pages,
- ttm->page_flags, ttm->caching_state);
+ ttm_pool_unpopulate_helper(ttm, i);
return -ENOMEM;
}
}
@@ -1105,18 +1125,7 @@ EXPORT_SYMBOL(ttm_pool_populate);
void ttm_pool_unpopulate(struct ttm_tt *ttm)
{
- unsigned i;
-
- for (i = 0; i < ttm->num_pages; ++i) {
- if (!ttm->pages[i])
- continue;
-
- ttm_mem_global_free_page(ttm->glob->mem_glob, ttm->pages[i],
-PAGE_SIZE);
- }
- ttm_put_pages(ttm->pages, ttm->num_pages, ttm->page_flags,
- ttm->caching_state);
- ttm->state = tt_unpopulated;
+ ttm_pool_unpopulate_helper(ttm, ttm->num_pages);
}
EXPORT_SYMBOL(ttm_pool_unpopulate);
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v2 1/1] drm: add kernel doc for exported gem dmabuf_ops
Am 18.01.2018 um 22:44 schrieb Samuel Li:
Signed-off-by: Samuel Li
Reviewed-by: Daniel Vetter
Reviewed-by: Christian König
---
drivers/gpu/drm/drm_prime.c | 88 +
1 file changed, 88 insertions(+)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm/drm_prime.c
index ca09ce7..e82a976 100644
--- a/drivers/gpu/drm/drm_prime.c
+++ b/drivers/gpu/drm/drm_prime.c
@@ -73,6 +73,9 @@
* Drivers should detect this situation and return back the gem object
* from the dma-buf private. Prime will do this automatically for drivers
that
* use the drm_gem_prime_{import,export} helpers.
+ *
+ * GEM struct &dma_buf_ops symbols are now exported. They can be resued by
+ * drivers which implement GEM interface.
*/
struct drm_prime_member {
@@ -180,6 +183,18 @@ static int drm_prime_lookup_buf_handle(struct
drm_prime_file_private *prime_fpri
return -ENOENT;
}
+/**
+ * drm_gem_map_attach - dma_buf attach implementation for GEM
+ * @dma_buf: buffer to attach device to
+ * @target_dev: not used
+ * @attach: buffer attachment data
+ *
+ * Allocates &drm_prime_attachment and calls &drm_driver.gem_prime_pin for
+ * device specific attachment. This can be used as the &dma_buf_ops.attach
+ * callback.
+ *
+ * Returns 0 on success, negative error code on failure.
+ */
int drm_gem_map_attach(struct dma_buf *dma_buf, struct device *target_dev,
struct dma_buf_attachment *attach)
{
@@ -201,6 +216,14 @@ int drm_gem_map_attach(struct dma_buf *dma_buf, struct
device *target_dev,
}
EXPORT_SYMBOL(drm_gem_map_attach);
+/**
+ * drm_gem_map_detach - dma_buf detach implementation for GEM
+ * @dma_buf: buffer to detach from
+ * @attach: attachment to be detached
+ *
+ * Cleans up &dma_buf_attachment. This can be used as the &dma_buf_ops.detach
+ * callback.
+ */
void drm_gem_map_detach(struct dma_buf *dma_buf,
struct dma_buf_attachment *attach)
{
@@ -255,6 +278,18 @@ void drm_prime_remove_buf_handle_locked(struct
drm_prime_file_private *prime_fpr
}
}
+/**
+ * drm_gem_map_dma_buf - map_dma_buf implementation for GEM
+ * @attach: attachment whose scatterlist is to be returned
+ * @dir: direction of DMA transfer
+ *
+ * Calls &drm_driver.gem_prime_get_sg_table and then maps the scatterlist. This
+ * can be used as the &dma_buf_ops.map_dma_buf callback.
+ *
+ * Returns sg_table containing the scatterlist to be returned; returns ERR_PTR
+ * on error. May return -EINTR if it is interrupted by a signal.
+ */
+
struct sg_table *drm_gem_map_dma_buf(struct dma_buf_attachment *attach,
enum dma_data_direction dir)
{
@@ -294,6 +329,12 @@ struct sg_table *drm_gem_map_dma_buf(struct
dma_buf_attachment *attach,
}
EXPORT_SYMBOL(drm_gem_map_dma_buf);
+/**
+ * drm_gem_unmap_dma_buf - unmap_dma_buf implementation for GEM
+ *
+ * Not implemented. The unmap is done at drm_gem_map_detach(). This can be
+ * used as the &dma_buf_ops.unmap_dma_buf callback.
+ */
void drm_gem_unmap_dma_buf(struct dma_buf_attachment *attach,
struct sg_table *sgt,
enum dma_data_direction dir)
@@ -351,6 +392,15 @@ void drm_gem_dmabuf_release(struct dma_buf *dma_buf)
}
EXPORT_SYMBOL(drm_gem_dmabuf_release);
+/**
+ * drm_gem_dmabuf_vmap - dma_buf vmap implementation for GEM
+ * @dma_buf: buffer to be mapped
+ *
+ * Sets up a kernel virtual mapping. This can be used as the &dma_buf_ops.vmap
+ * callback.
+ *
+ * Returns the kernel virtual address.
+ */
void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
{
struct drm_gem_object *obj = dma_buf->priv;
@@ -360,6 +410,14 @@ void *drm_gem_dmabuf_vmap(struct dma_buf *dma_buf)
}
EXPORT_SYMBOL(drm_gem_dmabuf_vmap);
+/**
+ * drm_gem_dmabuf_vunmap - dma_buf vunmap implementation for GEM
+ * @dma_buf: buffer to be unmapped
+ * @vaddr: the virtual address of the buffer
+ *
+ * Releases a kernel virtual mapping. This can be used as the
+ * &dma_buf_ops.vunmap callback.
+ */
void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void *vaddr)
{
struct drm_gem_object *obj = dma_buf->priv;
@@ -369,6 +427,11 @@ void drm_gem_dmabuf_vunmap(struct dma_buf *dma_buf, void
*vaddr)
}
EXPORT_SYMBOL(drm_gem_dmabuf_vunmap);
+/**
+ * drm_gem_dmabuf_kmap_atomic - map_atomic implementation for GEM
+ *
+ * Not implemented. This can be used as the &dma_buf_ops.map_atomic callback.
+ */
void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
unsigned long page_num)
{
@@ -376,6 +439,11 @@ void *drm_gem_dmabuf_kmap_atomic(struct dma_buf *dma_buf,
}
EXPORT_SYMBOL(drm_gem_dmabuf_kmap_atomic);
+/**
+ * drm_gem_dmabuf_kunmap_atomic - unmap_atomic implementation for GEM
+ *
+ * Not implemented. This can be used as the &dma_buf_ops.unmap_atomic callback.
+ */
void drm_gem_dmabuf_kunmap_atomic(struct dma_buf *dma_buf,
Re: [PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs
Hi, Dne četrtek, 18. januar 2018 ob 11:58:41 CET je Maxime Ripard napisal(a): > Hi, > > On Wed, Jan 17, 2018 at 09:14:11PM +0100, Jernej Skrabec wrote: > > This commit changes formula from this: > > > > Freq = (parent_freq * N * K) / (M * P) > > > > to this: > > > > Freq = (parent_freq / M) * N * K / P > > > > This improves situation when N is in the range 1-255. PLL parent clock > > is almost always 24 MHz, which means that for N >= 180 original formula > > overflows and result becomes useless. Situation can be improved if M is > > used as predivider as it can be seen in the second formula. That way at > > least M > 1 is considered, but it still leaves small gap for wrong result > > when M = 1 and N >= 180. > > > > Using M as predivider shouldn't cause any issue, because it is in range > > 1-4 at most, so there is no or only minimal rounding error. > > > > Signed-off-by: Jernej Skrabec > > I'd really prefer to stick to the formula documented and that we've > used so far. NKMP clocks are most notably used for the CPU PLLs and > I've debugged way too many cpufreq bugs already :) > > What about using long long types for the parent * n * k result? Yes, using long long is the best possible solution and covers all cases whereas this patch does not. I thought that do_div() would cause a lot of overhead, but I noticed that it's not big if both numbers fit in 32 bit, which in our case is true most of the time. I will make a helper function for calculating rate, since using long long needs more than one line of code. Best regards, Jernej ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Thu 18-01-18 12:01:32, Eric Anholt wrote: > Michal Hocko writes: > > > On Thu 18-01-18 18:00:06, Michal Hocko wrote: > >> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > >> > Hi, this series is a revised version of an RFC sent by Christian König > >> > a few years ago. The original RFC can be found at > >> > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > >> > > >> > This is the same idea and I've just adressed his concern from the > >> > original RFC > >> > and switched to a callback into file_ops instead of a new member in > >> > struct file. > >> > >> Please add the full description to the cover letter and do not make > >> people hunt links. > >> > >> Here is the origin cover letter text > >> : I'm currently working on the issue that when device drivers allocate > >> memory on > >> : behalf of an application the OOM killer usually doesn't knew about that > >> unless > >> : the application also get this memory mapped into their address space. > >> : > >> : This is especially annoying for graphics drivers where a lot of the VRAM > >> : usually isn't CPU accessible and so doesn't make sense to map into the > >> : address space of the process using it. > >> : > >> : The problem now is that when an application starts to use a lot of VRAM > >> those > >> : buffers objects sooner or later get swapped out to system memory, but > >> when we > >> : now run into an out of memory situation the OOM killer obviously doesn't > >> knew > >> : anything about that memory and so usually kills the wrong process. > > > > OK, but how do you attribute that memory to a particular OOM killable > > entity? And how do you actually enforce that those resources get freed > > on the oom killer action? > > > >> : The following set of patches tries to address this problem by > >> introducing a per > >> : file OOM badness score, which device drivers can use to give the OOM > >> killer a > >> : hint how many resources are bound to a file descriptor so that it can > >> make > >> : better decisions which process to kill. > > > > But files are not killable, they can be shared... In other words this > > doesn't help the oom killer to make an educated guess at all. > > Maybe some more context would help the discussion? > > The struct file in patch 3 is the DRM fd. That's effectively "my > process's interface to talking to the GPU" not "a single GPU resource". > Once that file is closed, all of the process's private, idle GPU buffers > will be immediately freed (this will be most of their allocations), and > some will be freed once the GPU completes some work (this will be most > of the rest of their allocations). > > Some GEM BOs won't be freed just by closing the fd, if they've been > shared between processes. Those are usually about 8-24MB total in a > process, rather than the GBs that modern apps use (or that our testcases > like to allocate and thus trigger oomkilling of the test harness instead > of the offending testcase...) > > Even if we just had the private+idle buffers being accounted in OOM > badness, that would be a huge step forward in system reliability. OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/nouveau/mmu: Fix trailing semicolon
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt
---
Hi,
After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
suggested I fix it treewide [0].
Best regards
Luis
[0]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115410.html
[1]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115390.html
drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
index e35d3e17cd7c..93946dcee319 100644
--- a/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
+++ b/drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmm.c
@@ -642,7 +642,7 @@ nvkm_vmm_ptes_sparse(struct nvkm_vmm *vmm, u64 addr, u64
size, bool ref)
else
block = (size >> page[i].shift) <<
page[i].shift;
} else {
- block = (size >> page[i].shift) << page[i].shift;;
+ block = (size >> page[i].shift) << page[i].shift;
}
/* Perform operation. */
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 09/12] drm/sun4i: Add support for A83T second DE2 mixer
It supports 1 VI and 1 UI plane and HW scaling on both planes.
Acked-by: Maxime Ripard
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun8i_mixer.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun8i_mixer.c
b/drivers/gpu/drm/sun4i/sun8i_mixer.c
index 2cbb2de6d39c..9b0256d31a61 100644
--- a/drivers/gpu/drm/sun4i/sun8i_mixer.c
+++ b/drivers/gpu/drm/sun4i/sun8i_mixer.c
@@ -485,6 +485,13 @@ static const struct sun8i_mixer_cfg sun8i_a83t_mixer0_cfg
= {
.vi_num = 1,
};
+static const struct sun8i_mixer_cfg sun8i_a83t_mixer1_cfg = {
+ .ccsc = 1,
+ .scaler_mask= 0x3,
+ .ui_num = 1,
+ .vi_num = 1,
+};
+
static const struct sun8i_mixer_cfg sun8i_v3s_mixer_cfg = {
.vi_num = 2,
.ui_num = 1,
@@ -498,6 +505,10 @@ static const struct of_device_id sun8i_mixer_of_table[] = {
.compatible = "allwinner,sun8i-a83t-de2-mixer-0",
.data = &sun8i_a83t_mixer0_cfg,
},
+ {
+ .compatible = "allwinner,sun8i-a83t-de2-mixer-1",
+ .data = &sun8i_a83t_mixer1_cfg,
+ },
{
.compatible = "allwinner,sun8i-v3s-de2-mixer",
.data = &sun8i_v3s_mixer_cfg,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/msm/mdp5: Fix trailing semicolon
The trailing semicolon is an empty statement that does no operation.
Removing it since it doesn't do anything.
Signed-off-by: Luis de Bethencourt
---
Hi,
After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
suggested I fix it treewide [0].
Best regards
Luis
[0]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115410.html
[1]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115390.html
drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
index 3e9bba4d6624..6d8e3a9a6fc0 100644
--- a/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
+++ b/drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c
@@ -680,7 +680,7 @@ struct msm_kms *mdp5_kms_init(struct drm_device *dev)
} else {
dev_info(&pdev->dev,
"no iommu, fallback to phys contig buffers for
scanout\n");
- aspace = NULL;;
+ aspace = NULL;
}
pm_runtime_put_sync(&pdev->dev);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > Hi, this series is a revised version of an RFC sent by Christian König > a few years ago. The original RFC can be found at > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > This is the same idea and I've just adressed his concern from the original > RFC > and switched to a callback into file_ops instead of a new member in struct > file. Please add the full description to the cover letter and do not make people hunt links. Here is the origin cover letter text : I'm currently working on the issue that when device drivers allocate memory on : behalf of an application the OOM killer usually doesn't knew about that unless : the application also get this memory mapped into their address space. : : This is especially annoying for graphics drivers where a lot of the VRAM : usually isn't CPU accessible and so doesn't make sense to map into the : address space of the process using it. : : The problem now is that when an application starts to use a lot of VRAM those : buffers objects sooner or later get swapped out to system memory, but when we : now run into an out of memory situation the OOM killer obviously doesn't knew : anything about that memory and so usually kills the wrong process. : : The following set of patches tries to address this problem by introducing a per : file OOM badness score, which device drivers can use to give the OOM killer a : hint how many resources are bound to a file descriptor so that it can make : better decisions which process to kill. : : So question at every one: What do you think about this approach? : : My biggest concern right now is the patches are messing with a core kernel : structure (adding a field to struct file). Any better idea? I'm considering : to put a callback into file_ops instead. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v1 08/15] drm/i2c: tda998x: Remove duplicate NULL check
On Thu, 2018-01-18 at 17:21 +0200, Ville Syrjälä wrote:
> On Tue, Oct 31, 2017 at 05:03:43PM +, Russell King - ARM Linux
> wrote:
> > On Tue, Oct 31, 2017 at 04:21:42PM +0200, Andy Shevchenko wrote:
> > > Since i2c_unregister_device() became NULL-aware we may remove
> > > duplicate
> > > NULL check.
> > >
> > > Cc: Russell King
> >
> > Acked-by: Russell King
>
> commit 7b43dd19c9b1 ("i2c: Make i2c_unregister_device() NULL-aware")
> seems to be the thing that makes this possible. So these three
> patches lgtm -> pushed to drm-misc-next.
>
Thanks, Ville!
> >
> > Thanks.
> >
> > > Cc: David Airlie
> > > Cc: dri-devel@lists.freedesktop.org
> > > Signed-off-by: Andy Shevchenko
> > > ---
> > > drivers/gpu/drm/i2c/tda998x_drv.c | 3 +--
> > > 1 file changed, 1 insertion(+), 2 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > index 4d1f45acf2cd..7a349e85f964 100644
> > > --- a/drivers/gpu/drm/i2c/tda998x_drv.c
> > > +++ b/drivers/gpu/drm/i2c/tda998x_drv.c
> > > @@ -1602,8 +1602,7 @@ static int tda998x_create(struct i2c_client
> > > *client, struct tda998x_priv *priv)
> > > /* if encoder_init fails, the encoder slave is never
> > > registered,
> > >* so cleanup here:
> > >*/
> > > - if (priv->cec)
> > > - i2c_unregister_device(priv->cec);
> > > + i2c_unregister_device(priv->cec);
> > > return -ENXIO;
> > > }
> > >
> > > --
> > > 2.14.2
> > >
> >
> > --
> > RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
> > FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down
> > 630kbps up
> > According to speedtest.net: 8.21Mbps down 510kbps up
> > ___
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
>
--
Andy Shevchenko
Intel Finland Oy
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 07/12] drm/sun4i: Add has_channel_0 TCON quirk
Some TCONs on newer SoCs doesn't support channel 0, since they are meant
to be used only with TV or HDMI encoder.
Prepare support for them with adding has_channel_0 quirk.
Acked-by: Maxime Ripard
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 41 +++---
drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 +
2 files changed, 30 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index b78fed809992..0815c528d08e 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -84,6 +84,7 @@ static void sun4i_tcon_channel_set_status(struct sun4i_tcon
*tcon, int channel,
switch (channel) {
case 0:
+ WARN_ON(!tcon->quirks->has_channel_0);
regmap_update_bits(tcon->regs, SUN4I_TCON0_CTL_REG,
SUN4I_TCON0_CTL_TCON_ENABLE,
enabled ? SUN4I_TCON0_CTL_TCON_ENABLE : 0);
@@ -276,6 +277,8 @@ static void sun4i_tcon0_mode_set_lvds(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 reg, val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 7;
tcon->dclk_max_div = 7;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -344,6 +347,8 @@ static void sun4i_tcon0_mode_set_rgb(struct sun4i_tcon
*tcon,
u8 clk_delay;
u32 val = 0;
+ WARN_ON(!tcon->quirks->has_channel_0);
+
tcon->dclk_min_div = 6;
tcon->dclk_max_div = 127;
sun4i_tcon0_mode_set_common(tcon, mode);
@@ -570,10 +575,12 @@ static int sun4i_tcon_init_clocks(struct device *dev,
}
clk_prepare_enable(tcon->clk);
- tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
- if (IS_ERR(tcon->sclk0)) {
- dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
- return PTR_ERR(tcon->sclk0);
+ if (tcon->quirks->has_channel_0) {
+ tcon->sclk0 = devm_clk_get(dev, "tcon-ch0");
+ if (IS_ERR(tcon->sclk0)) {
+ dev_err(dev, "Couldn't get the TCON channel 0 clock\n");
+ return PTR_ERR(tcon->sclk0);
+ }
}
if (tcon->quirks->has_channel_1) {
@@ -930,10 +937,12 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
goto err_free_clocks;
}
- ret = sun4i_dclk_create(dev, tcon);
- if (ret) {
- dev_err(dev, "Couldn't create our TCON dot clock\n");
- goto err_free_clocks;
+ if (tcon->quirks->has_channel_0) {
+ ret = sun4i_dclk_create(dev, tcon);
+ if (ret) {
+ dev_err(dev, "Couldn't create our TCON dot clock\n");
+ goto err_free_clocks;
+ }
}
ret = sun4i_tcon_init_irq(dev, tcon);
@@ -991,7 +1000,8 @@ static int sun4i_tcon_bind(struct device *dev, struct
device *master,
return 0;
err_free_dotclock:
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
err_free_clocks:
sun4i_tcon_free_clocks(tcon);
err_assert_reset:
@@ -1005,7 +1015,8 @@ static void sun4i_tcon_unbind(struct device *dev, struct
device *master,
struct sun4i_tcon *tcon = dev_get_drvdata(dev);
list_del(&tcon->list);
- sun4i_dclk_free(tcon);
+ if (tcon->quirks->has_channel_0)
+ sun4i_dclk_free(tcon);
sun4i_tcon_free_clocks(tcon);
}
@@ -1102,16 +1113,19 @@ static int sun6i_tcon_set_mux(struct sun4i_tcon *tcon,
}
static const struct sun4i_tcon_quirks sun4i_a10_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun5i_a13_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.set_mux= sun5i_a13_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun6i_a31_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.has_lvds_alt = true,
.needs_de_be_mux= true,
@@ -1119,26 +1133,29 @@ static const struct sun4i_tcon_quirks sun6i_a31_quirks
= {
};
static const struct sun4i_tcon_quirks sun6i_a31s_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
.needs_de_be_mux= true,
};
static const struct sun4i_tcon_quirks sun7i_a20_quirks = {
+ .has_channel_0 = true,
.has_channel_1 = true,
/* Same display pipeline structure as A10 */
.set_mux= sun4i_a10_tcon_set_mux,
};
static const struct sun4i_tcon_quirks sun8i_a33_quirks = {
+ .has_channel_0 = true,
.has_lvds_alt = true,
};
static con
[PATCH v3 08/12] drm/sun4i: Add support for A83T second TCON
This TCON is connected to HDMI encoder.
Acked-by: Maxime Ripard
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index 0815c528d08e..adfa39f372cf 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -1154,6 +1154,10 @@ static const struct sun4i_tcon_quirks
sun8i_a83t_lcd_quirks = {
.has_channel_0 = true,
};
+static const struct sun4i_tcon_quirks sun8i_a83t_tv_quirks = {
+ .has_channel_1 = true,
+};
+
static const struct sun4i_tcon_quirks sun8i_v3s_quirks = {
.has_channel_0 = true,
};
@@ -1167,6 +1171,7 @@ const struct of_device_id sun4i_tcon_of_table[] = {
{ .compatible = "allwinner,sun7i-a20-tcon", .data = &sun7i_a20_quirks },
{ .compatible = "allwinner,sun8i-a33-tcon", .data = &sun8i_a33_quirks },
{ .compatible = "allwinner,sun8i-a83t-tcon-lcd", .data =
&sun8i_a83t_lcd_quirks },
+ { .compatible = "allwinner,sun8i-a83t-tcon-tv", .data =
&sun8i_a83t_tv_quirks },
{ .compatible = "allwinner,sun8i-v3s-tcon", .data = &sun8i_v3s_quirks },
{ }
};
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: amd: Fix trailing semicolons
The trailing semicolon is an empty statement that does no operation.
Removing the two instances of them since they don't do anything.
Signed-off-by: Luis de Bethencourt
---
Hi,
After fixing the same thing in drivers/staging/rtl8723bs/, Joe Perches
suggested I fix it treewide [0].
Best regards
Luis
[0]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115410.html
[1]
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-January/115390.html
drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c | 2 +-
drivers/gpu/drm/amd/powerplay/amd_powerplay.c| 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
index 61e8c3e02d16..33d91e4474ea 100644
--- a/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
+++ b/drivers/gpu/drm/amd/display/dc/core/dc_link_dp.c
@@ -718,7 +718,7 @@ static enum link_training_result
perform_channel_equalization_sequence(
uint32_t retries_ch_eq;
enum dc_lane_count lane_count = lt_settings->link_settings.lane_count;
union lane_align_status_updated dpcd_lane_status_updated = {{0}};
- union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};;
+ union lane_status dpcd_lane_status[LANE_COUNT_DP_MAX] = {{{0}}};
hw_tr_pattern = get_supported_tp(link);
diff --git a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
index fa9d1615a2cc..b98a7a8a22b5 100644
--- a/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
+++ b/drivers/gpu/drm/amd/powerplay/amd_powerplay.c
@@ -162,7 +162,7 @@ static int pp_hw_init(void *handle)
if(hwmgr->smumgr_funcs->start_smu(pp_handle->hwmgr)) {
pr_err("smc start failed\n");
hwmgr->smumgr_funcs->smu_fini(pp_handle->hwmgr);
- return -EINVAL;;
+ return -EINVAL;
}
if (ret == PP_DPM_DISABLED)
goto exit;
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
[removed the broken quoting - please try to use an email client which doesn't mess up the qouted text] On Fri 19-01-18 06:01:26, He, Roger wrote: [...] > I think you are misunderstanding here. > Actually for now, the memory in TTM Pools already has mm_shrink which is > implemented in ttm_pool_mm_shrink_init. > And here the memory we want to make it contribute to OOM badness is not in > TTM Pools. > Because when TTM buffer allocation success, the memory already is removed > from TTM Pools. I have no idea what TTM buffers are. But this smells like something rather specific to the particular subsytem. And my main objection here is that struct file is not a proper vehicle to carry such an information. So whatever the TTM subsystem does it should contribute to generic counters rather than abuse fd because it happens to use it to communicate with userspace. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 03/12] drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a
Allwinner SoCs have dw hdmi controller v1.32a which exhibits same
magenta line issue as i.MX6Q and i.MX6DL. Enable workaround for it.
Tests show that one iteration is enough.
Acked-by: Laurent Pinchart
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index a38db40ce990..7ca14d7325b5 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1634,9 +1634,10 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
* then write one of the FC registers several times.
*
* The number of iterations matters and depends on the HDMI TX revision
-* (and possibly on the platform). So far only i.MX6Q (v1.30a) and
-* i.MX6DL (v1.31a) have been identified as needing the workaround, with
-* 4 and 1 iterations respectively.
+* (and possibly on the platform). So far i.MX6Q (v1.30a), i.MX6DL
+* (v1.31a) and multiple Allwinner SoCs (v1.32a) have been identified
+* as needing the workaround, with 4 iterations for v1.30a and 1
+* iteration for others.
*/
switch (hdmi->version) {
@@ -1644,6 +1645,7 @@ static void dw_hdmi_clear_overflow(struct dw_hdmi *hdmi)
count = 4;
break;
case 0x131a:
+ case 0x132a:
count = 1;
break;
default:
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 02/12] clk: sunxi-ng: Change formula for NKMP PLLs
This commit changes formula from this:
Freq = (parent_freq * N * K) / (M * P)
to this:
Freq = (parent_freq / M) * N * K / P
This improves situation when N is in the range 1-255. PLL parent clock
is almost always 24 MHz, which means that for N >= 180 original formula
overflows and result becomes useless. Situation can be improved if M is
used as predivider as it can be seen in the second formula. That way at
least M > 1 is considered, but it still leaves small gap for wrong result
when M = 1 and N >= 180.
Using M as predivider shouldn't cause any issue, because it is in range
1-4 at most, so there is no or only minimal rounding error.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index a99068a08315..e6c996ad4483 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -33,7 +33,7 @@ static void ccu_nkmp_find_best(unsigned long parent, unsigned
long rate,
for (_p = nkmp->min_p; _p <= nkmp->max_p; _p
<<= 1) {
unsigned long tmp_rate;
- tmp_rate = parent * _n * _k / (_m * _p);
+ tmp_rate = (parent / _m) * _n * _k / _p;
if (tmp_rate > rate)
continue;
@@ -107,7 +107,7 @@ static unsigned long ccu_nkmp_recalc_rate(struct clk_hw *hw,
p = reg >> nkmp->p.shift;
p &= (1 << nkmp->p.width) - 1;
- return (parent_rate * n * k >> p) / m;
+ return (parent_rate / m) * n * k >> p;
}
static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned long rate,
@@ -127,7 +127,7 @@ static long ccu_nkmp_round_rate(struct clk_hw *hw, unsigned
long rate,
ccu_nkmp_find_best(*parent_rate, rate, &_nkmp);
- return *parent_rate * _nkmp.n * _nkmp.k / (_nkmp.m * _nkmp.p);
+ return (*parent_rate / _nkmp.m) * _nkmp.n * _nkmp.k / _nkmp.p;
}
static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned long rate,
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 10/12] drm/sun4i: Implement A83T HDMI driver
A83T has DW HDMI IP block with a custom PHY similar to Synopsys gen2
HDMI PHY.
Only video output was tested, while HW also supports audio and CEC.
Support for them will be added later.
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/sun4i/Kconfig | 9 +
drivers/gpu/drm/sun4i/Makefile | 4 +
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 181
drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 46 +
drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 302 +
5 files changed, 542 insertions(+)
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h
create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c
diff --git a/drivers/gpu/drm/sun4i/Kconfig b/drivers/gpu/drm/sun4i/Kconfig
index 882d85db9053..7327da3bc94f 100644
--- a/drivers/gpu/drm/sun4i/Kconfig
+++ b/drivers/gpu/drm/sun4i/Kconfig
@@ -40,6 +40,15 @@ config DRM_SUN4I_BACKEND
do some alpha blending and feed graphics to TCON. If M is
selected the module will be called sun4i-backend.
+config DRM_SUN8I_DW_HDMI
+ tristate "Support for Allwinner version of DesignWare HDMI"
+ depends on DRM_SUN4I
+ select DRM_DW_HDMI
+ help
+ Choose this option if you have an Allwinner SoC with the
+ DesignWare HDMI controller with custom HDMI PHY. If M is
+ selected the module will be called sun8i_dw_hdmi.
+
config DRM_SUN8I_MIXER
tristate "Support for Allwinner Display Engine 2.0 Mixer"
default MACH_SUN8I
diff --git a/drivers/gpu/drm/sun4i/Makefile b/drivers/gpu/drm/sun4i/Makefile
index 2b37a6abbb1d..a7c47d9aa64d 100644
--- a/drivers/gpu/drm/sun4i/Makefile
+++ b/drivers/gpu/drm/sun4i/Makefile
@@ -9,6 +9,9 @@ sun4i-drm-hdmi-y+= sun4i_hdmi_enc.o
sun4i-drm-hdmi-y += sun4i_hdmi_i2c.o
sun4i-drm-hdmi-y += sun4i_hdmi_tmds_clk.o
+sun8i-drm-hdmi-y += sun8i_dw_hdmi.o
+sun8i-drm-hdmi-y += sun8i_hdmi_phy.o
+
sun8i-mixer-y += sun8i_mixer.o sun8i_ui_layer.o \
sun8i_vi_layer.o sun8i_ui_scaler.o \
sun8i_vi_scaler.o sun8i_csc.o
@@ -26,4 +29,5 @@ obj-$(CONFIG_DRM_SUN4I) += sun6i_drc.o
obj-$(CONFIG_DRM_SUN4I_BACKEND)+= sun4i-backend.o
obj-$(CONFIG_DRM_SUN4I_HDMI) += sun4i-drm-hdmi.o
+obj-$(CONFIG_DRM_SUN8I_DW_HDMI)+= sun8i-drm-hdmi.o
obj-$(CONFIG_DRM_SUN8I_MIXER) += sun8i-mixer.o
diff --git a/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
new file mode 100644
index ..12b73ced9517
--- /dev/null
+++ b/drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c
@@ -0,0 +1,181 @@
+// SPDX-License-Identifier: GPL-2.0+
+/*
+ * Copyright (c) 2018 Jernej Skrabec
+ */
+
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+#include "sun8i_dw_hdmi.h"
+
+static void sun8i_dw_hdmi_encoder_mode_set(struct drm_encoder *encoder,
+ struct drm_display_mode *mode,
+ struct drm_display_mode *adj_mode)
+{
+ struct sun8i_dw_hdmi *hdmi = encoder_to_sun8i_dw_hdmi(encoder);
+
+ sun8i_hdmi_phy_update_clock(hdmi->phy, mode->crtc_clock * 1000);
+}
+
+static const struct drm_encoder_helper_funcs
+sun8i_dw_hdmi_encoder_helper_funcs = {
+ .mode_set = sun8i_dw_hdmi_encoder_mode_set,
+};
+
+static const struct drm_encoder_funcs sun8i_dw_hdmi_encoder_funcs = {
+ .destroy = drm_encoder_cleanup,
+};
+
+static enum drm_mode_status
+sun8i_dw_hdmi_mode_valid(struct drm_connector *connector,
+const struct drm_display_mode *mode)
+{
+ if (mode->clock > 297000)
+ return MODE_CLOCK_HIGH;
+
+ return MODE_OK;
+}
+
+static int sun8i_dw_hdmi_bind(struct device *dev, struct device *master,
+ void *data)
+{
+ struct platform_device *pdev = to_platform_device(dev);
+ struct dw_hdmi_plat_data *plat_data;
+ struct drm_device *drm = data;
+ struct device_node *phy_node;
+ struct drm_encoder *encoder;
+ struct sun8i_dw_hdmi *hdmi;
+ int ret;
+
+ if (!pdev->dev.of_node)
+ return -ENODEV;
+
+ hdmi = devm_kzalloc(&pdev->dev, sizeof(*hdmi), GFP_KERNEL);
+ if (!hdmi)
+ return -ENOMEM;
+
+ plat_data = &hdmi->plat_data;
+ hdmi->dev = &pdev->dev;
+ encoder = &hdmi->encoder;
+
+ encoder->possible_crtcs = drm_of_find_possible_crtcs(drm, dev->of_node);
+ /*
+* If we failed to find the CRTC(s) which this encoder is
+* supposed to be connected to, it's because the CRTC has
+* not been registered yet. Defer probing, and hope that
+* the required CRTC is added later.
+*/
+ if (encoder->possible_crtcs == 0)
+ return -EPROBE_DEFER;
+
+ hdmi->rst_ctrl = devm_re
[PATCH v3 01/12] clk: sunxi-ng: Mask nkmp factors when setting register
Currently, if one of the factors isn't present, bit 0 gets always set to
1. For example, A83T has NMP PLLs modelled as NKMP PLL without K. Since
K is not specified, it's offset, width and shift is 0. Driver assumes
that lowest value possible is 1, otherwise we would get division by 0.
That situation causes that bit 0 is always set, which may change wanted
clock rate.
Fix that by masking every factor according to it's specified width.
Factors with width set to 0 won't have any influence to final register
value.
Signed-off-by: Jernej Skrabec
---
drivers/clk/sunxi-ng/ccu_nkmp.c | 21 -
1 file changed, 12 insertions(+), 9 deletions(-)
diff --git a/drivers/clk/sunxi-ng/ccu_nkmp.c b/drivers/clk/sunxi-ng/ccu_nkmp.c
index e58c95787f94..a99068a08315 100644
--- a/drivers/clk/sunxi-ng/ccu_nkmp.c
+++ b/drivers/clk/sunxi-ng/ccu_nkmp.c
@@ -134,6 +134,7 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned
long rate,
unsigned long parent_rate)
{
struct ccu_nkmp *nkmp = hw_to_ccu_nkmp(hw);
+ u32 n_mask, k_mask, m_mask, p_mask;
struct _ccu_nkmp _nkmp;
unsigned long flags;
u32 reg;
@@ -149,18 +150,20 @@ static int ccu_nkmp_set_rate(struct clk_hw *hw, unsigned
long rate,
ccu_nkmp_find_best(parent_rate, rate, &_nkmp);
+ n_mask = GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
+ k_mask = GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
+ m_mask = GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
+ p_mask = GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
+
spin_lock_irqsave(nkmp->common.lock, flags);
reg = readl(nkmp->common.base + nkmp->common.reg);
- reg &= ~GENMASK(nkmp->n.width + nkmp->n.shift - 1, nkmp->n.shift);
- reg &= ~GENMASK(nkmp->k.width + nkmp->k.shift - 1, nkmp->k.shift);
- reg &= ~GENMASK(nkmp->m.width + nkmp->m.shift - 1, nkmp->m.shift);
- reg &= ~GENMASK(nkmp->p.width + nkmp->p.shift - 1, nkmp->p.shift);
-
- reg |= (_nkmp.n - nkmp->n.offset) << nkmp->n.shift;
- reg |= (_nkmp.k - nkmp->k.offset) << nkmp->k.shift;
- reg |= (_nkmp.m - nkmp->m.offset) << nkmp->m.shift;
- reg |= ilog2(_nkmp.p) << nkmp->p.shift;
+ reg &= ~(n_mask | k_mask | m_mask | p_mask);
+
+ reg |= ((_nkmp.n - nkmp->n.offset) << nkmp->n.shift) & n_mask;
+ reg |= ((_nkmp.k - nkmp->k.offset) << nkmp->k.shift) & k_mask;
+ reg |= ((_nkmp.m - nkmp->m.offset) << nkmp->m.shift) & m_mask;
+ reg |= (ilog2(_nkmp.p) << nkmp->p.shift) & p_mask;
writel(reg, nkmp->common.base + nkmp->common.reg);
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/amdkfd: Use ARRAY_SIZE macro in kfd_build_sysfs_node_entry
Use ARRAY_SIZE instead of dividing sizeof array with sizeof an element.
This issue was detected with the help of Coccinelle.
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/amd/amdkfd/kfd_topology.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
index c6a7609..7783250 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_topology.c
@@ -677,7 +677,7 @@ static int kfd_build_sysfs_node_entry(struct
kfd_topology_device *dev,
}
/* All hardware blocks have the same number of attributes. */
- num_attrs = sizeof(perf_attr_iommu)/sizeof(struct kfd_perf_attr);
+ num_attrs = ARRAY_SIZE(perf_attr_iommu);
list_for_each_entry(perf, &dev->perf_props, list) {
perf->attr_group = kzalloc(sizeof(struct kfd_perf_attr)
* num_attrs + sizeof(struct attribute_group),
--
2.7.4
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 11/12] ARM: dts: sun8i: a83t: Add HDMI display pipeline
This commit adds all bits necessary for HDMI on A83T - mixer1, tcon1,
hdmi, hdmi phy and hdmi pinctrl entries.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +-
1 file changed, 118 insertions(+), 1 deletion(-)
diff --git a/arch/arm/boot/dts/sun8i-a83t.dtsi
b/arch/arm/boot/dts/sun8i-a83t.dtsi
index 7f4955a5fab7..c2638966d338 100644
--- a/arch/arm/boot/dts/sun8i-a83t.dtsi
+++ b/arch/arm/boot/dts/sun8i-a83t.dtsi
@@ -155,7 +155,7 @@
de: display-engine {
compatible = "allwinner,sun8i-a83t-display-engine";
- allwinner,pipelines = <&mixer0>;
+ allwinner,pipelines = <&mixer0>, <&mixer1>;
status = "disabled";
};
@@ -208,6 +208,32 @@
};
};
+ mixer1: mixer@120 {
+ compatible = "allwinner,sun8i-a83t-de2-mixer-1";
+ reg = <0x0120 0x10>;
+ clocks = <&display_clocks CLK_BUS_MIXER1>,
+<&display_clocks CLK_MIXER1>;
+ clock-names = "bus",
+ "mod";
+ resets = <&display_clocks RST_WB>;
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ mixer1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ mixer1_out_tcon1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&tcon1_in_mixer1>;
+ };
+ };
+ };
+ };
+
syscon: syscon@1c0 {
compatible = "allwinner,sun8i-a83t-system-controller",
"syscon";
@@ -256,6 +282,43 @@
};
};
+ tcon1: lcd-controller@1c0d000 {
+ compatible = "allwinner,sun8i-a83t-tcon-tv";
+ reg = <0x01c0d000 0x1000>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_TCON1>, <&ccu CLK_TCON1>;
+ clock-names = "ahb", "tcon-ch1";
+ resets = <&ccu RST_BUS_TCON1>;
+ reset-names = "lcd";
+
+ ports {
+ #address-cells = <1>;
+ #size-cells = <0>;
+
+ tcon1_in: port@0 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <0>;
+
+ tcon1_in_mixer1: endpoint@0 {
+ reg = <0>;
+ remote-endpoint =
<&mixer1_out_tcon1>;
+ };
+ };
+
+ tcon1_out: port@1 {
+ #address-cells = <1>;
+ #size-cells = <0>;
+ reg = <1>;
+
+ tcon1_out_hdmi: endpoint@1 {
+ reg = <1>;
+ remote-endpoint =
<&hdmi_in_tcon1>;
+ };
+ };
+ };
+ };
+
mmc0: mmc@1c0f000 {
compatible = "allwinner,sun8i-a83t-mmc",
"allwinner,sun7i-a20-mmc";
@@ -427,6 +490,11 @@
drive-strength = <40>;
};
+ hdmi_pins: hdmi-pins {
+ pins = "PH6", "PH7", "PH8";
+ function = "hdmi";
+ };
+
i2c0_pins: i2c0-pins {
pins = "PH0", "PH1";
function = "i2c0";
@@ -685,6 +753,55 @@
interrupts = ;
};
+ hdmi: hdmi@1ee {
+ compatible = "allwinner,sun8i-a83t-dw-hdmi";
+ reg = <0x01ee 0x1>;
+ reg-io-width = <1>;
+ interrupts = ;
+ clocks = <&ccu CLK_BUS_HDMI>, <&ccu CLK_HDMI_SLOW>;
+ clock-names = "iahb", "isfr";
+ resets = <&ccu RST_BUS_HDMI1>;
+
OLED Display -- Framebuffer driver to DRM driver conversion required???
Hi, In my project (Arm processor based), we are using 2 displays. Primary display is for Ubuntu 16.04 OS Gui display and secondary display is for status messages, some small OLED display (128x64). This OLED display is framebuffer driver based. My doubt is: 1. Whether I need to convert this framebuffer driver to DRM driver? Is this required? What is the advantages of this? Please provide some inputs on this. -Thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Nouveau] [RFC 0/4] Implement full clockgating for Kepler1 and 2
On 01/16/2018 12:06 AM, Lyude Paul wrote: It's here! After a lot of investigation, rewrites, and traces, I present the patch series to implement all known levels of clockgating for Kepler1 and Kepler2 GPUs. Starting with Fermi GPUs (this is probably present on earlier GPUs as well, but with a far less easy to manage interface), nvidia added two clockgating levels that are handled mostly in firmware (with the exception of course, of the driver initially programming all of the register values containing engine delays and that stuff): - CG_CTRL - Main register for enabling/disabling clockgating for engines and hw blocks - BLCG - "Block-level clockgating", a deeper level of clockgating Starting with kepler2 as well, nvidia also introduced: - SLCG - "??? clockgating" even deeper level of clockgating FWIW, SLCG stands for "second level clock gating". Cheers, Mikko ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [GIT PULL] drm/tegra: Changes for v4.16-rc1
On 08.01.2018 18:49, Thierry Reding wrote: > On Mon, Jan 08, 2018 at 04:47:42PM +0300, Dmitry Osipenko wrote: >> On 08.01.2018 15:39, Thierry Reding wrote: >>> On Mon, Jan 08, 2018 at 08:42:50AM +0100, Thierry Reding wrote: On Fri, Jan 05, 2018 at 05:58:17PM +0300, Dmitry Osipenko wrote: > On 05.01.2018 17:17, Thierry Reding wrote: >> Hi Dave, >> >> The following changes since commit >> 9428088c90b6f7d5edd2a1b0d742c75339b36f6e: >> >> drm/qxl: reapply cursor after resetting primary (2017-12-08 13:37:02 >> +1000) >> >> are available in the Git repository at: >> >> git://anongit.freedesktop.org/tegra/linux tags/drm/tegra/for-4.16-rc1 >> >> for you to fetch changes up to ebae8d07435ae91314f4a28d69b530d09c625815: >> >> drm/tegra: dc: Implement legacy blending (2017-12-21 14:55:55 +0100) >> >> Thanks, >> Thierry >> >> >> drm/tegra: Changes for v4.16-rc1 >> >> The bulk of these changes are preparation work and addition of support >> for Tegra186. Currently only HDMI output (the primary output on Jetson >> TX2) is supported, but the hardware is also capable of doing DSI and >> DisplayPort. >> >> Tegra DRM now also uses the atomic commit helpers instead of the open- >> coded variant that was only doing half its job. As a bit of a byproduct >> of the Tegra186 support the driver also gained HDMI 2.0 as well as zpos >> property support. >> >> Along the way there are also a few patches to clean up a few things and >> fix minor issues. >> >> >> Arnd Bergmann (2): >> drm/tegra: Mark Tegra186 display hub PM functions __maybe_unused >> drm/tegra: Fix non-debugfs builds >> >> Dmitry Osipenko (3): >> drm/tegra: dc: Link DC1 to DC0 on Tegra20 >> drm/tegra: gem: Correct iommu_map_sg() error checking >> drm/tegra: Correct timeout in tegra_syncpt_wait >> >> Thierry Reding (43): >> drm/fourcc: Fix fourcc_mod_code() definition >> drm/tegra: Sanitize format modifiers >> gpu: host1x: Rewrite conditional for better readability >> gpu: host1x: Cleanup on initialization failure >> dt-bindings: display: tegra: Update SOR for Tegra186 >> drm/tegra: dc: Move register definitions into a table >> drm/tegra: dsi: Move register definitions into a table >> drm/tegra: hdmi: Move register definitions into a table >> drm/tegra: sor: Move register definitions into a table >> drm/tegra: dc: Reshuffle some code >> drm/tegra: dc: Register debugfs in ->late_register() >> drm/tegra: dsi: Register debugfs in ->late_register() >> drm/tegra: hdmi: Register debugfs in ->late_register() >> drm/tegra: sor: Root debugfs files at the connector >> drm/tegra: sor: Register debugfs in ->late_register() >> drm/tegra: Do not wrap lines unnecessarily >> drm/tegra: vic: Properly align arguments >> drm/tegra: dc: Support background color >> drm/tegra: Use atomic commit helpers >> drm/tegra: Remove custom page-flip handler >> drm/tegra: dc: Remove tegra_primary_plane_destroy() >> drm/tegra: dc: Remove duplicate plane funcs >> drm/tegra: dc: Remove tegra_overlay_plane_destroy() >> drm/tegra: dc: Remove duplicate plane funcs >> drm/tegra: dc: Move state definition to header >> drm/tegra: Move common plane code to separate file >> drm/tegra: Add Tegra186 display hub support >> drm/tegra: dc: Add Tegra186 support >> drm/tegra: Support ARGB and ABGR formats >> drm/tegra: sor: Parameterize register offsets >> drm/tegra: sor: Add Tegra186 support >> drm/tegra: sor: Support HDMI 2.0 modes >> drm/tegra: dpaux: Implement runtime PM >> drm/tegra: dpaux: Add Tegra186 support >> drm/tegra: fb: Force alpha formats >> drm/tegra: dc: Support more formats >> drm/tegra: dc: Use direct offset to plane registers >> drm/tegra: dc: Remove redundant spinlock >> drm/tegra: Implement zpos property >> gpu: host1x: Use IOMMU groups >> drm/tegra: Use IOMMU groups >> drm/tegra: dpaux: Keep reset defaults for hybrid pad parameters > > >> drm/tegra: dc: Implement legacy blending > > Please hold on this patch. First of all it doesn't work correctly, see my > last > reply to the patch. Secondly, it introduces bug that breaks YUV plane. I thought we had already concluded that this version doesn't cause any regressions. And since this is new functionality I'm not too worried if it do
Re: [PATCH 00/12] Cargo cult cleanup in atomic drivers
Hi Laurent, On Wed, 2018-01-17 at 23:55 +0200, Laurent Pinchart wrote: > Hello, > > This patch series removes a few cargo-cult constructs from a set of atomic > drivers. > > Patches 01/12 and 02/12 remove the unneeded .mode_set() and .mode_set_base() > CRTC handlers from the arc and atmel-hlcdc drivers. > > Patches 03/12 to 12/12 then remove the use of drm_plane_helper_disable() from > the plane .destroy() handlers of atomic drivers, replacing them with the use > of drm_atomic_helper_shutdown() at removal time. Interleaved there are patches > 04/12 and 06/12 that remove unnecessary cleanups in error paths, and patch > 09/12 that adds missing cleanup. > > All this has been compile-tested only. I'd like to test it on ARC boards and so wondering if there's a git tree with these patches so I'm not missing any prerequisites or maybe you may specify what should be used as a base for the series? -Alexey ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 00/12] drm/sun4i: Add A83T HDMI support
This patch series implements support for A83T DW HDMI and PHY. Contrary to v1 series, this one is based on latest linux-next, since all needed patches were merged. While exactly this combination of HDMI controller and PHY is not common in Allwinner SoCs, this patch series nevertheless makes groundwork for other SoCs, which have same DW HDMI IP block, but different PHYs, like H3 and H5. Please take a look. Best regards, Jernej Changes from v2: - Collected ACKs and Review-by tags - patch for deinit callback was replaced with the one which gives control of drvdata to driver - fixed meson driver (renamed reset function) - prototypes for newly exported functions in dw_hdmi.h were reordered Changes from v1: - Collected ACKs - Separated bindings for controller and PHY - Split driver into two parts - controller and PHY - HDMI PHY driver now uses regmap for writes - added defines for PHY registers and bits - updated DT entries to accomodate new bindings - removed already merged clock patch - reworked first clock patch according to comments - added new clock patch which changes NKMP formula - split TCON patch in two, one for quirk and one for new compatible - reworked patch which exports DW HDMI PHY functions: - remove "gen2" from some function names - removed parameter from dw_hdmi_phy_reset() - added address parameter to dw_hdmi_phy_i2c_set_addr() - updated most of commit messages Jernej Skrabec (12): clk: sunxi-ng: Mask nkmp factors when setting register clk: sunxi-ng: Change formula for NKMP PLLs drm/bridge/synopsys: dw-hdmi: Enable workaround for v1.32a drm/bridge/synopsys: dw-hdmi: Export some PHY related functions drm/bridge/synopsys: dw-hdmi: don't clobber drvdata dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline drm/sun4i: Add has_channel_0 TCON quirk drm/sun4i: Add support for A83T second TCON drm/sun4i: Add support for A83T second DE2 mixer drm/sun4i: Implement A83T HDMI driver ARM: dts: sun8i: a83t: Add HDMI display pipeline ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3 .../bindings/display/sunxi/sun4i-drm.txt | 197 +- arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 25 ++ arch/arm/boot/dts/sun8i-a83t.dtsi | 119 +++- drivers/clk/sunxi-ng/ccu_nkmp.c| 27 +- drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 83 +++--- drivers/gpu/drm/imx/dw_hdmi-imx.c | 13 +- drivers/gpu/drm/meson/meson_dw_hdmi.c | 22 +- drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 12 +- drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c| 13 +- drivers/gpu/drm/sun4i/Kconfig | 9 + drivers/gpu/drm/sun4i/Makefile | 4 + drivers/gpu/drm/sun4i/sun4i_tcon.c | 46 +++- drivers/gpu/drm/sun4i/sun4i_tcon.h | 1 + drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c | 181 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h | 46 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c | 302 + drivers/gpu/drm/sun4i/sun8i_mixer.c| 11 + include/drm/bridge/dw_hdmi.h | 24 +- 18 files changed, 1046 insertions(+), 89 deletions(-) create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.c create mode 100644 drivers/gpu/drm/sun4i/sun8i_dw_hdmi.h create mode 100644 drivers/gpu/drm/sun4i/sun8i_hdmi_phy.c -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 06/12] dt-bindings: display: sun4i-drm: Add A83T HDMI pipeline
This commit adds all necessary compatibles and descriptions needed to implement A83T HDMI pipeline. Mixer is already properly described, so only compatible is added. However, A83T TV TCON, which is connected to HDMI, doesn't have channel 0, contrary to all TCONs currently described. Because of that, TCON documentation is extended. A83T features Synopsys DW HDMI controller with a custom PHY which looks like Synopsys Gen2 PHY with few additions. Since there is no documentation, needed properties were found out through experimentation and reading BSP code. At the end, example is added for newer SoCs, which feature DE2 and DW HDMI. Signed-off-by: Jernej Skrabec --- .../bindings/display/sunxi/sun4i-drm.txt | 197 - 1 file changed, 190 insertions(+), 7 deletions(-) diff --git a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt index cd626ee1147a..4fb380f3e53d 100644 --- a/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt +++ b/Documentation/devicetree/bindings/display/sunxi/sun4i-drm.txt @@ -64,6 +64,52 @@ Required properties: first port should be the input endpoint. The second should be the output, usually to an HDMI connector. +DWC HDMI TX Encoder +--- + +The HDMI transmitter is a Synopsys DesignWare HDMI 1.4 TX controller IP +with Allwinner's own PHY IP. It supports audio and video outputs and CEC. + +These DT bindings follow the Synopsys DWC HDMI TX bindings defined in +Documentation/devicetree/bindings/display/bridge/dw_hdmi.txt with the +following device-specific properties. + +Required properties: + + - compatible: value must be one of: +* "allwinner,sun8i-a83t-dw-hdmi" + - reg: base address and size of memory-mapped region + - reg-io-width: See dw_hdmi.txt. Shall be 1. + - interrupts: HDMI interrupt number + - clocks: phandles to the clocks feeding the HDMI encoder +* iahb: the HDMI bus clock +* isfr: the HDMI register clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller + - reset-names: must be "ctrl" + - phys: phandle to the DWC HDMI PHY + - phy-names: must be "phy" + + - ports: A ports node with endpoint definitions as defined in +Documentation/devicetree/bindings/media/video-interfaces.txt. The +first port should be the input endpoint. The second should be the +output, usually to an HDMI connector. + +DWC HDMI PHY + + +Required properties: + - compatible: value must be one of: +* allwinner,sun8i-a83t-hdmi-phy + - reg: base address and size of memory-mapped region + - clocks: phandles to the clocks feeding the HDMI PHY +* bus: the HDMI PHY interface clock +* mod: the HDMI PHY module clock +* tmds: TMDS clock + - clock-names: the clock names mentioned above + - resets: phandle to the reset controller driving the PHY + - reset-names: must be "phy" + TV Encoder -- @@ -94,24 +140,23 @@ Required properties: * allwinner,sun7i-a20-tcon * allwinner,sun8i-a33-tcon * allwinner,sun8i-a83t-tcon-lcd + * allwinner,sun8i-a83t-tcon-tv * allwinner,sun8i-v3s-tcon - reg: base address and size of memory-mapped region - interrupts: interrupt associated to this IP - - clocks: phandles to the clocks feeding the TCON. Three are needed: + - clocks: phandles to the clocks feeding the TCON. One is needed: - 'ahb': the interface clocks - - 'tcon-ch0': The clock driving the TCON channel 0 - resets: phandles to the reset controllers driving the encoder - "lcd": the reset line for the TCON channel 0 - clock-names: the clock names mentioned above - reset-names: the reset names mentioned above - - clock-output-names: Name of the pixel clock created - ports: A ports node with endpoint definitions as defined in Documentation/devicetree/bindings/media/video-interfaces.txt. The first port should be the input endpoint, the second one the output - The output may have multiple endpoints. The TCON has two channels, + The output may have multiple endpoints. TCON can have two channels, usually with the first channel being used for the panels interfaces (RGB, LVDS, etc.), and the second being used for the outputs that require another controller (TV Encoder, HDMI, etc.). The endpoints @@ -119,11 +164,16 @@ Required properties: channel the endpoint is associated to. If that property is not present, the endpoint number will be used as the channel number. +When TCON supports channel 0 (all TCONs except TV TCON on A83T), two +more clocks are needed: + - 'tcon-ch0': The clock driving the TCON channel 0 + - clock-output-names: Name of the pixel clock created + On SoCs other than the A33 and V3s, there is one more clock required: - 'tcon-ch1': The clock driving the TCON channel 1 -On SoCs that support LVDS (all SoCs but the A13, H3, H5 and V3s), you -need one more reset line: +When TCON support L
[PATCH v3 05/12] drm/bridge/synopsys: dw-hdmi: don't clobber drvdata
dw_hdmi shouldn't set drvdata since some drivers might need to store
it's own data there. Rework dw_hdmi in a way to return struct dw_hdmi
instead to store it in drvdata. This way drivers are responsible to
store and pass structure when needed.
Idea was taken from the following commit:
8242ecbd597d ("drm/bridge/synopsys: stop clobbering drvdata")
Cc: p.za...@pengutronix.de
Cc: narmstr...@baylibre.com
Cc: laurent.pinch...@ideasonboard.com
Cc: h...@rock-chips.com
Cc: he...@sntech.de
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 31 -
drivers/gpu/drm/imx/dw_hdmi-imx.c | 13 +---
drivers/gpu/drm/meson/meson_dw_hdmi.c | 14 +
drivers/gpu/drm/rcar-du/rcar_dw_hdmi.c | 12 +--
drivers/gpu/drm/rockchip/dw_hdmi-rockchip.c | 13 +---
include/drm/bridge/dw_hdmi.h| 13 ++--
6 files changed, 60 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7d80f4b56683..f9802399cc0d 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -2543,8 +2543,6 @@ __dw_hdmi_probe(struct platform_device *pdev,
if (hdmi->i2c)
dw_hdmi_i2c_init(hdmi);
- platform_set_drvdata(pdev, hdmi);
-
return hdmi;
err_iahb:
@@ -2594,25 +2592,23 @@ static void __dw_hdmi_remove(struct dw_hdmi *hdmi)
/*
-
* Probe/remove API, used from platforms based on the DRM bridge API.
*/
-int dw_hdmi_probe(struct platform_device *pdev,
- const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_probe(struct platform_device *pdev,
+ const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
drm_bridge_add(&hdmi->bridge);
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_probe);
-void dw_hdmi_remove(struct platform_device *pdev)
+void dw_hdmi_remove(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = platform_get_drvdata(pdev);
-
drm_bridge_remove(&hdmi->bridge);
__dw_hdmi_remove(hdmi);
@@ -2622,31 +2618,30 @@ EXPORT_SYMBOL_GPL(dw_hdmi_remove);
/*
-
* Bind/unbind API, used from platforms based on the component framework.
*/
-int dw_hdmi_bind(struct platform_device *pdev, struct drm_encoder *encoder,
-const struct dw_hdmi_plat_data *plat_data)
+struct dw_hdmi *dw_hdmi_bind(struct platform_device *pdev,
+struct drm_encoder *encoder,
+const struct dw_hdmi_plat_data *plat_data)
{
struct dw_hdmi *hdmi;
int ret;
hdmi = __dw_hdmi_probe(pdev, plat_data);
if (IS_ERR(hdmi))
- return PTR_ERR(hdmi);
+ return hdmi;
ret = drm_bridge_attach(encoder, &hdmi->bridge, NULL);
if (ret) {
- dw_hdmi_remove(pdev);
+ dw_hdmi_remove(hdmi);
DRM_ERROR("Failed to initialize bridge with drm\n");
- return ret;
+ return ERR_PTR(ret);
}
- return 0;
+ return hdmi;
}
EXPORT_SYMBOL_GPL(dw_hdmi_bind);
-void dw_hdmi_unbind(struct device *dev)
+void dw_hdmi_unbind(struct dw_hdmi *hdmi)
{
- struct dw_hdmi *hdmi = dev_get_drvdata(dev);
-
__dw_hdmi_remove(hdmi);
}
EXPORT_SYMBOL_GPL(dw_hdmi_unbind);
diff --git a/drivers/gpu/drm/imx/dw_hdmi-imx.c
b/drivers/gpu/drm/imx/dw_hdmi-imx.c
index b62763aa8706..fe6becdcc29e 100644
--- a/drivers/gpu/drm/imx/dw_hdmi-imx.c
+++ b/drivers/gpu/drm/imx/dw_hdmi-imx.c
@@ -25,6 +25,7 @@
struct imx_hdmi {
struct device *dev;
struct drm_encoder encoder;
+ struct dw_hdmi *hdmi;
struct regmap *regmap;
};
@@ -239,14 +240,18 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
drm_encoder_init(drm, encoder, &dw_hdmi_imx_encoder_funcs,
DRM_MODE_ENCODER_TMDS, NULL);
- ret = dw_hdmi_bind(pdev, encoder, plat_data);
+ platform_set_drvdata(pdev, hdmi);
+
+ hdmi->hdmi = dw_hdmi_bind(pdev, encoder, plat_data);
/*
* If dw_hdmi_bind() fails we'll never call dw_hdmi_unbind(),
* which would have called the encoder cleanup. Do it manually.
*/
- if (ret)
+ if (IS_ERR(hdmi->hdmi)) {
+ ret = PTR_ERR(hdmi->hdmi);
drm_encoder_cleanup(encoder);
+ }
return ret;
}
@@ -254,7 +259,9 @@ static int dw_hdmi_imx_bind(struct device *dev, struct
device *master,
static void dw_hdmi_imx_unbind(struct device
[PATCH] drm/vmwgfx: Return boolean instead of integer in vmw_fence_obj_signaled
Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 6c5c75c..35fd6f9 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -496,7 +496,7 @@ bool vmw_fence_obj_signaled(struct vmw_fence_obj *fence) struct vmw_fence_manager *fman = fman_from_fence(fence); if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->base.flags)) - return 1; + return true; vmw_fences_update(fman); -- 2.7.4 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 12/12] ARM: dts: sun8i: a83t: Enable HDMI on BananaPi M3
BananaPi M3 includes HDMI connector, so add support for it.
Signed-off-by: Jernej Skrabec
---
arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts | 25 +
1 file changed, 25 insertions(+)
diff --git a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
index 6550bf0e594b..00e47423cd07 100644
--- a/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-bananapi-m3.dts
@@ -60,6 +60,17 @@
stdout-path = "serial0:115200n8";
};
+ connector {
+ compatible = "hdmi-connector";
+ type = "a";
+
+ port {
+ hdmi_con_in: endpoint {
+ remote-endpoint = <&hdmi_out_con>;
+ };
+ };
+ };
+
reg_usb1_vbus: reg-usb1-vbus {
compatible = "regulator-fixed";
regulator-name = "usb1-vbus";
@@ -82,6 +93,10 @@
};
};
+&de {
+ status = "okay";
+};
+
&ehci0 {
/* Terminus Tech FE 1.1s 4-port USB 2.0 hub here */
status = "okay";
@@ -100,6 +115,16 @@
status = "okay";
};
+&hdmi {
+ status = "okay";
+};
+
+&hdmi_out {
+ hdmi_out_con: endpoint {
+ remote-endpoint = <&hdmi_con_in>;
+ };
+};
+
&mdio {
rgmii_phy: ethernet-phy@1 {
compatible = "ethernet-phy-ieee802.3-c22";
--
2.15.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Thu 18-01-18 18:00:06, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: > > Hi, this series is a revised version of an RFC sent by Christian König > > a few years ago. The original RFC can be found at > > https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html > > > > This is the same idea and I've just adressed his concern from the original > > RFC > > and switched to a callback into file_ops instead of a new member in struct > > file. > > Please add the full description to the cover letter and do not make > people hunt links. > > Here is the origin cover letter text > : I'm currently working on the issue that when device drivers allocate memory > on > : behalf of an application the OOM killer usually doesn't knew about that > unless > : the application also get this memory mapped into their address space. > : > : This is especially annoying for graphics drivers where a lot of the VRAM > : usually isn't CPU accessible and so doesn't make sense to map into the > : address space of the process using it. > : > : The problem now is that when an application starts to use a lot of VRAM > those > : buffers objects sooner or later get swapped out to system memory, but when > we > : now run into an out of memory situation the OOM killer obviously doesn't > knew > : anything about that memory and so usually kills the wrong process. OK, but how do you attribute that memory to a particular OOM killable entity? And how do you actually enforce that those resources get freed on the oom killer action? > : The following set of patches tries to address this problem by introducing a > per > : file OOM badness score, which device drivers can use to give the OOM killer > a > : hint how many resources are bound to a file descriptor so that it can make > : better decisions which process to kill. But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. > : > : So question at every one: What do you think about this approach? I thing is just just wrong semantically. Non-reclaimable memory is a pain, especially when there is way too much of it. If you can free that memory somehow then you can hook into slab shrinker API and react on the memory pressure. If you can account such a memory to a particular process and make sure that the consumption is bound by the process life time then we can think of an accounting that oom_badness can consider when selecting a victim. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 103370] `vblank_mode=0 DRI_PRIME=1 glxgears` will introduce GPU lock up on Intel Graphics [8086:5917] + AMD Graphics [1002:6665] (rev c3)
https://bugs.freedesktop.org/show_bug.cgi?id=103370 --- Comment #43 from Shih-Yuan Lee --- I can still reduplicate the issue after setting max_sclk to 6 and max_mclk to 8. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v3 04/12] drm/bridge/synopsys: dw-hdmi: Export some PHY related functions
Parts of PHY code could be useful also for custom PHYs. For example,
Allwinner A83T has custom PHY which is probably Synopsys gen2 PHY
with few additional memory mapped registers, so most of the Synopsys PHY
related code could be reused.
Functions exported here are actually not specific to Synopsys PHYs but
to DWC HDMI controller PHY interface. This means that even if the PHY is
completely custom, i.e. not designed by Synopsys, exported functions can
be useful.
Reviewed-by: Laurent Pinchart
Signed-off-by: Jernej Skrabec
---
drivers/gpu/drm/bridge/synopsys/dw-hdmi.c | 44 +--
drivers/gpu/drm/meson/meson_dw_hdmi.c | 8 +++---
include/drm/bridge/dw_hdmi.h | 11
3 files changed, 45 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
index 7ca14d7325b5..7d80f4b56683 100644
--- a/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
+++ b/drivers/gpu/drm/bridge/synopsys/dw-hdmi.c
@@ -1037,19 +1037,21 @@ static void dw_hdmi_phy_enable_svsret(struct dw_hdmi
*hdmi, u8 enable)
HDMI_PHY_CONF0_SVSRET_MASK);
}
-static void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_pddq(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_PDDQ_OFFSET,
HDMI_PHY_CONF0_GEN2_PDDQ_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_pddq);
-static void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
+void dw_hdmi_phy_gen2_txpwron(struct dw_hdmi *hdmi, u8 enable)
{
hdmi_mask_writeb(hdmi, enable, HDMI_PHY_CONF0,
HDMI_PHY_CONF0_GEN2_TXPWRON_OFFSET,
HDMI_PHY_CONF0_GEN2_TXPWRON_MASK);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_gen2_txpwron);
static void dw_hdmi_phy_sel_data_en_pol(struct dw_hdmi *hdmi, u8 enable)
{
@@ -1065,6 +1067,22 @@ static void dw_hdmi_phy_sel_interface_control(struct
dw_hdmi *hdmi, u8 enable)
HDMI_PHY_CONF0_SELDIPIF_MASK);
}
+void dw_hdmi_phy_reset(struct dw_hdmi *hdmi)
+{
+ /* PHY reset. The reset signal is active high on Gen2 PHYs. */
+ hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
+ hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_reset);
+
+void dw_hdmi_phy_i2c_set_addr(struct dw_hdmi *hdmi, u8 address)
+{
+ hdmi_phy_test_clear(hdmi, 1);
+ hdmi_writeb(hdmi, address, HDMI_PHY_I2CM_SLAVE_ADDR);
+ hdmi_phy_test_clear(hdmi, 0);
+}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_i2c_set_addr);
+
static void dw_hdmi_phy_power_off(struct dw_hdmi *hdmi)
{
const struct dw_hdmi_phy_data *phy = hdmi->phy.data;
@@ -1203,16 +1221,11 @@ static int hdmi_phy_configure(struct dw_hdmi *hdmi)
if (phy->has_svsret)
dw_hdmi_phy_enable_svsret(hdmi, 1);
- /* PHY reset. The reset signal is active high on Gen2 PHYs. */
- hdmi_writeb(hdmi, HDMI_MC_PHYRSTZ_PHYRSTZ, HDMI_MC_PHYRSTZ);
- hdmi_writeb(hdmi, 0, HDMI_MC_PHYRSTZ);
+ dw_hdmi_phy_reset(hdmi);
hdmi_writeb(hdmi, HDMI_MC_HEACPHY_RST_ASSERT, HDMI_MC_HEACPHY_RST);
- hdmi_phy_test_clear(hdmi, 1);
- hdmi_writeb(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2,
- HDMI_PHY_I2CM_SLAVE_ADDR);
- hdmi_phy_test_clear(hdmi, 0);
+ dw_hdmi_phy_i2c_set_addr(hdmi, HDMI_PHY_I2CM_SLAVE_ADDR_PHY_GEN2);
/* Write to the PHY as configured by the platform */
if (pdata->configure_phy)
@@ -1251,15 +1264,16 @@ static void dw_hdmi_phy_disable(struct dw_hdmi *hdmi,
void *data)
dw_hdmi_phy_power_off(hdmi);
}
-static enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
- void *data)
+enum drm_connector_status dw_hdmi_phy_read_hpd(struct dw_hdmi *hdmi,
+ void *data)
{
return hdmi_readb(hdmi, HDMI_PHY_STAT0) & HDMI_PHY_HPD ?
connector_status_connected : connector_status_disconnected;
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_read_hpd);
-static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
- bool force, bool disabled, bool rxsense)
+void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi, void *data,
+ bool force, bool disabled, bool rxsense)
{
u8 old_mask = hdmi->phy_mask;
@@ -1271,8 +1285,9 @@ static void dw_hdmi_phy_update_hpd(struct dw_hdmi *hdmi,
void *data,
if (old_mask != hdmi->phy_mask)
hdmi_writeb(hdmi, hdmi->phy_mask, HDMI_PHY_MASK0);
}
+EXPORT_SYMBOL_GPL(dw_hdmi_phy_update_hpd);
-static void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
+void dw_hdmi_phy_setup_hpd(struct dw_hdmi *hdmi, void *data)
{
/*
* Configure the PHY RX SENSE and HPD interrupts polarities and clear
@@ -1291,6 +
Re: [RFC] Per file OOM badness
On 2018-01-19 09:39 AM, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko: >> On Thu 18-01-18 12:01:32, Eric Anholt wrote: >>> Michal Hocko writes: >>> On Thu 18-01-18 18:00:06, Michal Hocko wrote: > On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: >> Hi, this series is a revised version of an RFC sent by Christian >> König >> a few years ago. The original RFC can be found at >> https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html >> >> >> This is the same idea and I've just adressed his concern from the >> original RFC >> and switched to a callback into file_ops instead of a new member >> in struct file. > Please add the full description to the cover letter and do not make > people hunt links. > > Here is the origin cover letter text > : I'm currently working on the issue that when device drivers > allocate memory on > : behalf of an application the OOM killer usually doesn't knew > about that unless > : the application also get this memory mapped into their address > space. > : > : This is especially annoying for graphics drivers where a lot of > the VRAM > : usually isn't CPU accessible and so doesn't make sense to map > into the > : address space of the process using it. > : > : The problem now is that when an application starts to use a lot > of VRAM those > : buffers objects sooner or later get swapped out to system memory, > but when we > : now run into an out of memory situation the OOM killer obviously > doesn't knew > : anything about that memory and so usually kills the wrong process. OK, but how do you attribute that memory to a particular OOM killable entity? And how do you actually enforce that those resources get freed on the oom killer action? > : The following set of patches tries to address this problem by > introducing a per > : file OOM badness score, which device drivers can use to give the > OOM killer a > : hint how many resources are bound to a file descriptor so that it > can make > : better decisions which process to kill. But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. >>> Maybe some more context would help the discussion? >>> >>> The struct file in patch 3 is the DRM fd. That's effectively "my >>> process's interface to talking to the GPU" not "a single GPU resource". >>> Once that file is closed, all of the process's private, idle GPU buffers >>> will be immediately freed (this will be most of their allocations), and >>> some will be freed once the GPU completes some work (this will be most >>> of the rest of their allocations). >>> >>> Some GEM BOs won't be freed just by closing the fd, if they've been >>> shared between processes. Those are usually about 8-24MB total in a >>> process, rather than the GBs that modern apps use (or that our testcases >>> like to allocate and thus trigger oomkilling of the test harness instead >>> of the offending testcase...) >>> >>> Even if we just had the private+idle buffers being accounted in OOM >>> badness, that would be a huge step forward in system reliability. >> OK, in that case I would propose a different approach. We already >> have rss_stat. So why do not we simply add a new counter there >> MM_KERNELPAGES and consider those in oom_badness? The rule would be >> that such a memory is bound to the process life time. I guess we will >> find more users for this later. > > I already tried that and the problem with that approach is that some > buffers are not created by the application which actually uses them. > > For example X/Wayland is creating and handing out render buffers to > application which want to use OpenGL. > > So the result is when you always account the application who created the > buffer the OOM killer will certainly reap X/Wayland first. And that is > exactly what we want to avoid here. FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland anymore. With DRI3 and Wayland, buffers are allocated by the clients and then shared with the X / Wayland server. Also, in all cases, the amount of memory allocated for buffers shared between DRI/Wayland clients and the server should be relatively small compared to the amount of memory allocated for buffers used only locally in the client, particularly for clients which create significant memory pressure. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104683] WebGL crashes the kernel driver and Xorg
https://bugs.freedesktop.org/show_bug.cgi?id=104683 --- Comment #3 from Michel Dänzer --- (In reply to Dieter Nützel from comment #2) > If this is unrelated I'll open my own bug. Please do. -- 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: vga_switcheroo: MIS-using the DIS command on a muxless system
On Fri, Jan 19, 2018 at 08:38:20AM +0100, Enrico Mioso wrote: > I forgot one last question. Is there any way I can force the system > to switch to the ATI card without installing a graphical environment, > just out of curiosity? As you've observed correctly, your particular machine isn't capable of muxing the display, it's a muxless model. Nowadays a mux is only found on MacBook Pros (can switch at runtime) and a few gaming laptops (can only switch in BIOS). On supported (i.e., pre-retina) MacBook Pros, it is indeed possible to switch to the discrete GPU without a graphical environment, in fact no graphical environment is even allowed to run currently. If by "force the system to switch" you're not referring to muxing the display but rather exercising (and thus powering on) the discrete GPU, I believe you do need a graphical environment to start a client with DRI_PRIME. Failing that, you can try to force the GPU out of runtime suspend with "echo on > /sys/bus/pci/devices/:01:00.0/power/control". (Use "echo auto" to re-enable automatic power management.) Kind regards, Lukas ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
Am 19.01.2018 um 10:32 schrieb Michel Dänzer: On 2018-01-19 09:39 AM, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: Michal Hocko writes: On Thu 18-01-18 18:00:06, Michal Hocko wrote: On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struct file. Please add the full description to the cover letter and do not make people hunt links. Here is the origin cover letter text : I'm currently working on the issue that when device drivers allocate memory on : behalf of an application the OOM killer usually doesn't knew about that unless : the application also get this memory mapped into their address space. : : This is especially annoying for graphics drivers where a lot of the VRAM : usually isn't CPU accessible and so doesn't make sense to map into the : address space of the process using it. : : The problem now is that when an application starts to use a lot of VRAM those : buffers objects sooner or later get swapped out to system memory, but when we : now run into an out of memory situation the OOM killer obviously doesn't knew : anything about that memory and so usually kills the wrong process. OK, but how do you attribute that memory to a particular OOM killable entity? And how do you actually enforce that those resources get freed on the oom killer action? : The following set of patches tries to address this problem by introducing a per : file OOM badness score, which device drivers can use to give the OOM killer a : hint how many resources are bound to a file descriptor so that it can make : better decisions which process to kill. But files are not killable, they can be shared... In other words this doesn't help the oom killer to make an educated guess at all. Maybe some more context would help the discussion? The struct file in patch 3 is the DRM fd. That's effectively "my process's interface to talking to the GPU" not "a single GPU resource". Once that file is closed, all of the process's private, idle GPU buffers will be immediately freed (this will be most of their allocations), and some will be freed once the GPU completes some work (this will be most of the rest of their allocations). Some GEM BOs won't be freed just by closing the fd, if they've been shared between processes. Those are usually about 8-24MB total in a process, rather than the GBs that modern apps use (or that our testcases like to allocate and thus trigger oomkilling of the test harness instead of the offending testcase...) Even if we just had the private+idle buffers being accounted in OOM badness, that would be a huge step forward in system reliability. OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. I already tried that and the problem with that approach is that some buffers are not created by the application which actually uses them. For example X/Wayland is creating and handing out render buffers to application which want to use OpenGL. So the result is when you always account the application who created the buffer the OOM killer will certainly reap X/Wayland first. And that is exactly what we want to avoid here. FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland anymore. With DRI3 and Wayland, buffers are allocated by the clients and then shared with the X / Wayland server. Good point, when I initially looked at that problem DRI3 wasn't widely used yet. Also, in all cases, the amount of memory allocated for buffers shared between DRI/Wayland clients and the server should be relatively small compared to the amount of memory allocated for buffers used only locally in the client, particularly for clients which create significant memory pressure. That is unfortunately only partially true. When you have a single runaway application which tries to allocate everything it would indeed work as you described. But when I tested this a few years ago with X based desktop the applications which actually used most of the memory where Firefox and Thunderbird. Unfortunately they never got accounted for that. Now, on my current Wayland based desktop it actually doesn't look much better. Taking a look at radeon_gem_info/amdgpu_gem_info the majority of all memory was allocated either by gnome-shell or Xwayland. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org
Re: [RFC] Per file OOM badness
On 2018年01月19日 16:25, Michal Hocko wrote: [removed the broken quoting - please try to use an email client which doesn't mess up the qouted text] On Fri 19-01-18 06:01:26, He, Roger wrote: [...] I think you are misunderstanding here. Actually for now, the memory in TTM Pools already has mm_shrink which is implemented in ttm_pool_mm_shrink_init. And here the memory we want to make it contribute to OOM badness is not in TTM Pools. Because when TTM buffer allocation success, the memory already is removed from TTM Pools. I have no idea what TTM buffers are. But this smells like something rather specific to the particular subsytem. And my main objection here is that struct file is not a proper vehicle to carry such an information. So whatever the TTM subsystem does it should contribute to generic counters rather than abuse fd because it happens to use it to communicate with userspace. got it. thanks. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On 2018-01-19 10:58 AM, Christian König wrote: > Am 19.01.2018 um 10:32 schrieb Michel Dänzer: >> On 2018-01-19 09:39 AM, Christian König wrote: >>> Am 19.01.2018 um 09:20 schrieb Michal Hocko: On Thu 18-01-18 12:01:32, Eric Anholt wrote: > Michal Hocko writes: > >> On Thu 18-01-18 18:00:06, Michal Hocko wrote: >>> On Thu 18-01-18 11:47:48, Andrey Grodzovsky wrote: Hi, this series is a revised version of an RFC sent by Christian König a few years ago. The original RFC can be found at https://lists.freedesktop.org/archives/dri-devel/2015-September/089778.html This is the same idea and I've just adressed his concern from the original RFC and switched to a callback into file_ops instead of a new member in struct file. >>> Please add the full description to the cover letter and do not make >>> people hunt links. >>> >>> Here is the origin cover letter text >>> : I'm currently working on the issue that when device drivers >>> allocate memory on >>> : behalf of an application the OOM killer usually doesn't knew >>> about that unless >>> : the application also get this memory mapped into their address >>> space. >>> : >>> : This is especially annoying for graphics drivers where a lot of >>> the VRAM >>> : usually isn't CPU accessible and so doesn't make sense to map >>> into the >>> : address space of the process using it. >>> : >>> : The problem now is that when an application starts to use a lot >>> of VRAM those >>> : buffers objects sooner or later get swapped out to system memory, >>> but when we >>> : now run into an out of memory situation the OOM killer obviously >>> doesn't knew >>> : anything about that memory and so usually kills the wrong process. >> OK, but how do you attribute that memory to a particular OOM killable >> entity? And how do you actually enforce that those resources get >> freed >> on the oom killer action? >> >>> : The following set of patches tries to address this problem by >>> introducing a per >>> : file OOM badness score, which device drivers can use to give the >>> OOM killer a >>> : hint how many resources are bound to a file descriptor so that it >>> can make >>> : better decisions which process to kill. >> But files are not killable, they can be shared... In other words this >> doesn't help the oom killer to make an educated guess at all. > Maybe some more context would help the discussion? > > The struct file in patch 3 is the DRM fd. That's effectively "my > process's interface to talking to the GPU" not "a single GPU > resource". > Once that file is closed, all of the process's private, idle GPU > buffers > will be immediately freed (this will be most of their allocations), > and > some will be freed once the GPU completes some work (this will be most > of the rest of their allocations). > > Some GEM BOs won't be freed just by closing the fd, if they've been > shared between processes. Those are usually about 8-24MB total in a > process, rather than the GBs that modern apps use (or that our > testcases > like to allocate and thus trigger oomkilling of the test harness > instead > of the offending testcase...) > > Even if we just had the private+idle buffers being accounted in OOM > badness, that would be a huge step forward in system reliability. OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. >>> I already tried that and the problem with that approach is that some >>> buffers are not created by the application which actually uses them. >>> >>> For example X/Wayland is creating and handing out render buffers to >>> application which want to use OpenGL. >>> >>> So the result is when you always account the application who created the >>> buffer the OOM killer will certainly reap X/Wayland first. And that is >>> exactly what we want to avoid here. >> FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland >> anymore. With DRI3 and Wayland, buffers are allocated by the clients and >> then shared with the X / Wayland server. > > Good point, when I initially looked at that problem DRI3 wasn't widely > used yet. > >> Also, in all cases, the amount of memory allocated for buffers shared >> between DRI/Wayland clients and the server should be relatively small >> compared to the amount of memory allocated for buffers used only locally >> in the client, particularly for clients which create significant memory >> pressure. > > That is unfo
[Bug 103443] [CI] igt@ - success - WARN - no modes for connector 76
https://bugs.freedesktop.org/show_bug.cgi?id=103443 Marta Löfstedt changed: What|Removed |Added Status|RESOLVED|CLOSED -- 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 103443] [CI] igt@ - success - WARN - no modes for connector 76
https://bugs.freedesktop.org/show_bug.cgi?id=103443 Marta Löfstedt changed: What|Removed |Added Resolution|--- |WORKSFORME Status|NEW |RESOLVED --- Comment #5 from Marta Löfstedt --- Last seen: IGT_4069: 2017-12-16 / 158 runs ago -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 1/2] dt-bindings: mipi-dsi: Add info about peripherals with non-DSI control bus
Hi Archit,
Many thanks for this documentation update.
Reviewed-by: Philippe Cornu
Philippe :-)
On 01/18/2018 05:53 AM, Archit Taneja wrote:
> Add a section that describes dt-bindings for peripherals that support
> MIPI DSI, but have a different bus as the primary control bus, or no
> control bus at all. Add an example for a peripheral with a non-DSI
> control bus.
>
> Signed-off-by: Archit Taneja
> ---
> v2:
> - Mentioned what to do if peripheral has no control bus
> - Drop unit-address and #*-cells where applicable.
>
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 71
> +++---
> 1 file changed, 64 insertions(+), 7 deletions(-)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 973c27273772..94fb72cb916f 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -16,7 +16,7 @@ The following assumes that only a single peripheral is
> connected to a DSI
> host. Experience shows that this is true for the large majority of setups.
>
> DSI host
> -
> +
>
> In addition to the standard properties and those defined by the parent bus
> of
> a DSI host, the following properties apply to a node representing a DSI
> host.
> @@ -30,11 +30,16 @@ Required properties:
> different value here. See below.
>
> DSI peripheral
> ---
> +==
>
> -Peripherals are represented as child nodes of the DSI host's node. Properties
> -described here apply to all DSI peripherals, but individual bindings may want
> -to define additional, device-specific properties.
> +Peripherals with DSI as control bus, or no control bus
> +--
> +
> +Peripherals with the DSI bus as the primary control bus, or peripherals with
> +no control bus but use the DSI bus to transmit pixel data are represented
> +as child nodes of the DSI host's node. Properties described here apply to all
> +DSI peripherals, but individual bindings may want to define additional,
> +device-specific properties.
>
> Required properties:
> - reg: The virtual channel number of a DSI peripheral. Must be in the range
> @@ -49,9 +54,25 @@ case two alternative representations can be chosen:
> property is the number of the first virtual channel and the second cell is
> the number of consecutive virtual channels.
>
> -Example
>
> +Peripherals with a different control bus
> +
> +
> +There are peripherals that have I2C/SPI (or some other non-DSI bus) as the
> +primary control bus, but are also connected to a DSI bus (mostly for the data
> +path). Connections between such peripherals and a DSI host can be represented
> +using the graph bindings [1], [2].
> +
> +[1] Documentation/devicetree/bindings/graph.txt
> +[2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> +Examples
> +
> +- (1), (2) and (3) are examples of a DSI host and peripheral on the DSI bus
> + with different virtual channel configurations.
> +- (4) is an example of a peripheral on a I2C control bus connected with to
> + a DSI host using of-graph bindings.
> +
> +1)
> dsi-host {
> ...
>
> @@ -67,6 +88,7 @@ Example
> ...
> };
>
> +2)
> dsi-host {
> ...
>
> @@ -82,6 +104,7 @@ Example
> ...
> };
>
> +3)
> dsi-host {
> ...
>
> @@ -96,3 +119,37 @@ Example
>
> ...
> };
> +
> +4)
> + i2c-host {
> + ...
> +
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + ...
> +
> + port {
> + bridge_mipi_in: endpoint {
> + remote-endpoint =
> <&host_mipi_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> + host_mipi_out: endpoint {
> + remote-endpoint = <&bridge_mipi_in>;
> + };
> + };
> + };
> + };
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 00/10] Add backlight helper functions
Move drm helper functions from tinydrm-helpers to linux/backlight for ease of use by callers in other drivers. changes in v17: -set fb_blank along with clearing the BL_CORE_FBBLANK bit -rebase with drm-misc-next -fix checkpath errors/warnings -Make the gpio_backlight issue appear as a comment in the code and not as part of the docs -rebase with drm-misc-next -convert st7735r callers from tinydrm specific helpers to new generic backlight helpers -remove select BACKLIGHT_LCD_SUPPORT and select BACKLIGHT_CLASS_DEVICE from tinydrm/Kconfig -fix checkpath errors/warnings -rename devm_backlight_put to devm_backlight_release -remove redundant NULL check -remove put_device() to avoid double put as we are using the devm version Meghana Madhyastha (10): video: backlight: Add helpers to enable and disable backlight drm/tinydrm: Convert tinydrm_enable/disable_backlight to backlight_enable/disable video: backlight: Add of_find_backlight helper in backlight.c drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight video: backlight: Add devres versions of of_find_backlight drm/tinydrm: Call devres version of of_find_backlight drm/panel: Use backlight_enable/disable helpers drm/omapdrm: Use backlight_enable/disable helpers drm/panel: Use of_find_backlight helper drm/omapdrm: Use of_find_backlight helper drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 32 ++--- drivers/gpu/drm/panel/panel-innolux-p079zca.c | 29 ++-- drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 +- drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 35 ++--- drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 35 ++--- drivers/gpu/drm/tinydrm/Kconfig | 2 - drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 95 - drivers/gpu/drm/tinydrm/mi0283qt.c | 3 +- drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +- drivers/gpu/drm/tinydrm/st7735r.c | 3 +- drivers/video/backlight/backlight.c | 73 +++ include/drm/tinydrm/tinydrm-helpers.h | 4 -- include/linux/backlight.h | 58 +++ 13 files changed, 164 insertions(+), 215 deletions(-) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 01/10] video: backlight: Add helpers to enable and disable backlight
Add helper functions backlight_enable and backlight_disable to
enable/disable a backlight device. These helper functions can
then be used by different drm and tinydrm drivers to avoid
repetition of code and also to enforce a uniform and consistent
way to enable/disable a backlight device.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-set fb_blank along with clearing the BL_CORE_FBBLANK bit
include/linux/backlight.h | 32
1 file changed, 32 insertions(+)
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index af7003548..ace825e2c 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -130,6 +130,38 @@ static inline int backlight_update_status(struct
backlight_device *bd)
return ret;
}
+/**
+ * backlight_enable - Enable backlight
+ * @bd: the backlight device to enable
+ */
+static inline int backlight_enable(struct backlight_device *bd)
+{
+ if (!bd)
+ return 0;
+
+ bd->props.power = FB_BLANK_UNBLANK;
+ bd->props.fb_blank = FB_BLANK_UNBLANK;
+ bd->props.state &= ~BL_CORE_FBBLANK;
+
+ return backlight_update_status(bd);
+}
+
+/**
+ * backlight_disable - Disable backlight
+ * @bd: the backlight device to disable
+ */
+static inline int backlight_disable(struct backlight_device *bd)
+{
+ if (!bd)
+ return 0;
+
+ bd->props.power = FB_BLANK_POWERDOWN;
+ bd->props.fb_blank = FB_BLANK_POWERDOWN;
+ bd->props.state |= BL_CORE_FBBLANK;
+
+ return backlight_update_status(bd);
+}
+
extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 02/10] drm/tinydrm: Convert tinydrm_enable/disable_backlight to backlight_enable/disable
Remove tinydrm_enable/disable_backlight and let the callers call the
more generic backlight_enable/disable helpers
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-rebase with drm-misc-next
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 55 --
drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +-
include/drm/tinydrm/tinydrm-helpers.h | 2 -
3 files changed, 2 insertions(+), 59 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index bf96072d1..7326e1758 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -276,61 +276,6 @@ struct backlight_device *tinydrm_of_find_backlight(struct
device *dev)
}
EXPORT_SYMBOL(tinydrm_of_find_backlight);
-/**
- * tinydrm_enable_backlight - Enable backlight helper
- * @backlight: Backlight device
- *
- * Returns:
- * Zero on success, negative error code on failure.
- */
-int tinydrm_enable_backlight(struct backlight_device *backlight)
-{
- unsigned int old_state;
- int ret;
-
- if (!backlight)
- return 0;
-
- old_state = backlight->props.state;
- backlight->props.state &= ~BL_CORE_FBBLANK;
- DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
- backlight->props.state);
-
- ret = backlight_update_status(backlight);
- if (ret)
- DRM_ERROR("Failed to enable backlight %d\n", ret);
-
- return ret;
-}
-EXPORT_SYMBOL(tinydrm_enable_backlight);
-
-/**
- * tinydrm_disable_backlight - Disable backlight helper
- * @backlight: Backlight device
- *
- * Returns:
- * Zero on success, negative error code on failure.
- */
-int tinydrm_disable_backlight(struct backlight_device *backlight)
-{
- unsigned int old_state;
- int ret;
-
- if (!backlight)
- return 0;
-
- old_state = backlight->props.state;
- backlight->props.state |= BL_CORE_FBBLANK;
- DRM_DEBUG_KMS("Backlight state: 0x%x -> 0x%x\n", old_state,
- backlight->props.state);
- ret = backlight_update_status(backlight);
- if (ret)
- DRM_ERROR("Failed to disable backlight %d\n", ret);
-
- return ret;
-}
-EXPORT_SYMBOL(tinydrm_disable_backlight);
-
#if IS_ENABLED(CONFIG_SPI)
/**
diff --git a/drivers/gpu/drm/tinydrm/mipi-dbi.c
b/drivers/gpu/drm/tinydrm/mipi-dbi.c
index 75dd65c57..9e903812b 100644
--- a/drivers/gpu/drm/tinydrm/mipi-dbi.c
+++ b/drivers/gpu/drm/tinydrm/mipi-dbi.c
@@ -286,7 +286,7 @@ void mipi_dbi_enable_flush(struct mipi_dbi *mipi)
if (fb)
fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
- tinydrm_enable_backlight(mipi->backlight);
+ backlight_enable(mipi->backlight);
}
EXPORT_SYMBOL(mipi_dbi_enable_flush);
@@ -325,7 +325,7 @@ void mipi_dbi_pipe_disable(struct drm_simple_display_pipe
*pipe)
mipi->enabled = false;
if (mipi->backlight)
- tinydrm_disable_backlight(mipi->backlight);
+ backlight_disable(mipi->backlight);
else
mipi_dbi_blank(mipi);
diff --git a/include/drm/tinydrm/tinydrm-helpers.h
b/include/drm/tinydrm/tinydrm-helpers.h
index d554ded60..f54fae03e 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -47,8 +47,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct
drm_framebuffer *fb,
struct drm_clip_rect *clip);
struct backlight_device *tinydrm_of_find_backlight(struct device *dev);
-int tinydrm_enable_backlight(struct backlight_device *backlight);
-int tinydrm_disable_backlight(struct backlight_device *backlight);
size_t tinydrm_spi_max_transfer_size(struct spi_device *spi, size_t max_len);
bool tinydrm_spi_bpw_supported(struct spi_device *spi, u8 bpw);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 03/10] video: backlight: Add of_find_backlight helper in backlight.c
Add of_find_backlight, a helper function which is a generic version
of tinydrm_of_find_backlight that can be used by other drivers to avoid
repetition of code and simplify things.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-rebase with drm-misc-next
-convert st7735r callers from tinydrm specific helpers
to new generic backlight helpers
-remove select BACKLIGHT_LCD_SUPPORT
and select BACKLIGHT_CLASS_DEVICE from
tinydrm/Kconfig
drivers/video/backlight/backlight.c | 43 +
include/linux/backlight.h | 19
2 files changed, 62 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 8049e7656..553bf5c48 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -580,6 +580,49 @@ struct backlight_device *of_find_backlight_by_node(struct
device_node *node)
EXPORT_SYMBOL(of_find_backlight_by_node);
#endif
+/**
+ * of_find_backlight - Get backlight device
+ * @dev: Device
+ *
+ * This function looks for a property named 'backlight' on the DT node
+ * connected to @dev and looks up the backlight device.
+ *
+ * Call backlight_put() to drop the reference on the backlight device.
+ *
+ * Returns:
+ * A pointer to the backlight device if found.
+ * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
+ * device is found.
+ * NULL if there's no backlight property.
+ */
+struct backlight_device *of_find_backlight(struct device *dev)
+{
+ struct backlight_device *bd = NULL;
+ struct device_node *np;
+
+ if (!dev)
+ return NULL;
+
+ if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
+ np = of_parse_phandle(dev->of_node, "backlight", 0);
+ if (np) {
+ bd = of_find_backlight_by_node(np);
+ of_node_put(np);
+ if (!bd)
+ return ERR_PTR(-EPROBE_DEFER);
+ /*
+* Note: gpio_backlight uses brightness as
+* power state during probe
+*/
+ if (!bd->props.brightness)
+ bd->props.brightness = bd->props.max_brightness;
+ }
+ }
+
+ return bd;
+}
+EXPORT_SYMBOL(of_find_backlight);
+
static void __exit backlight_class_exit(void)
{
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index ace825e2c..ddc9bade4 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -162,6 +162,16 @@ static inline int backlight_disable(struct
backlight_device *bd)
return backlight_update_status(bd);
}
+/**
+ * backlight_put - Drop backlight reference
+ * @bd: the backlight device to put
+ */
+static inline void backlight_put(struct backlight_device *bd)
+{
+ if (bd)
+ put_device(&bd->dev);
+}
+
extern struct backlight_device *backlight_device_register(const char *name,
struct device *dev, void *devdata, const struct backlight_ops *ops,
const struct backlight_properties *props);
@@ -205,4 +215,13 @@ of_find_backlight_by_node(struct device_node *node)
}
#endif
+#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
+struct backlight_device *of_find_backlight(struct device *dev);
+#else
+static inline struct backlight_device *of_find_backlight(struct device *dev)
+{
+ return NULL;
+}
+#endif
+
#endif
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC v2 2/2] dt-bindings: mipi-dsi: Add dual-channel DSI related info
Hi Archit,
Many thanks for this documentation add-on.
I wonder if an extra example of "2 DSI hosts driving a dual-channel DSI
peripheral controlled by the mipi bus" could be useful? well, I am not
really convinced it is necessary and maybe this extra example could be
added later when someone will meet the case... and I should have sent
this comment on v1 (sorry for the delay).
Reviewed-by: Philippe Cornu
Philippe :-)
On 01/18/2018 05:53 AM, Archit Taneja wrote:
> Add binding info for peripherals that support dual-channel DSI. Add
> corresponding optional bindings for DSI host controllers that may
> be configured in this mode. Add an example of an I2C controlled
> device operating in dual-channel DSI mode.
>
> Signed-off-by: Archit Taneja
> ---
> v2:
> - Specify that clock-master is a boolean property.
> - Drop/add unit-address and #*-cells where applicable.
>
> .../devicetree/bindings/display/mipi-dsi-bus.txt | 80
> ++
> 1 file changed, 80 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> index 94fb72cb916f..7a3abbedb3fa 100644
> --- a/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> +++ b/Documentation/devicetree/bindings/display/mipi-dsi-bus.txt
> @@ -29,6 +29,13 @@ Required properties:
> - #size-cells: Should be 0. There are cases where it makes sense to use a
> different value here. See below.
>
> +Optional properties:
> +- clock-master: boolean. Should be enabled if the host is being used in
> + conjunction with another DSI host to drive the same peripheral. Hardware
> + supporting such a configuration generally requires the data on both the
> busses
> + to be driven by the same clock. Only the DSI host instance controlling this
> + clock should contain this property.
> +
> DSI peripheral
> ==
>
> @@ -62,6 +69,16 @@ primary control bus, but are also connected to a DSI bus
> (mostly for the data
> path). Connections between such peripherals and a DSI host can be
> represented
> using the graph bindings [1], [2].
>
> +Peripherals that support dual channel DSI
> +-
> +
> +Peripherals with higher bandwidth requirements can be connected to 2 DSI
> +busses. Each DSI bus/channel drives some portion of the pixel data (generally
> +left/right half of each line of the display, or even/odd lines of the
> display).
> +The graph bindings should be used to represent the multiple DSI busses that
> are
> +connected to this peripheral. Each DSI host's output endpoint can be linked
> to
> +an input endpoint of the DSI peripheral.
> +
> [1] Documentation/devicetree/bindings/graph.txt
> [2] Documentation/devicetree/bindings/media/video-interfaces.txt
>
> @@ -71,6 +88,8 @@ Examples
> with different virtual channel configurations.
> - (4) is an example of a peripheral on a I2C control bus connected with to
> a DSI host using of-graph bindings.
> +- (5) is an example of 2 DSI hosts driving a dual-channel DSI peripheral,
> + which uses I2C as its primary control bus.
>
> 1)
> dsi-host {
> @@ -153,3 +172,64 @@ Examples
> };
> };
> };
> +
> +5)
> + i2c-host {
> + dsi-bridge@35 {
> + compatible = "...";
> + reg = <0x35>;
> +
> + ports {
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
> + port@0 {
> + reg = <0>;
> + dsi0_in: endpoint {
> + remote-endpoint = <&dsi0_out>;
> + };
> + };
> +
> + port@1 {
> + reg = <1>;
> + dsi1_in: endpoint {
> + remote-endpoint = <&dsi1_out>;
> + };
> + };
> + };
> + };
> + };
> +
> + dsi0-host {
> + ...
> +
> + /*
> + * this DSI instance drives the clock for both the host
> + * controllers
> + */
> + clock-master;
> +
> + ports {
> + ...
> +
> + port {
> + dsi0_out: endpoint {
> + remote-endpoint = <&dsi0_in>;
> + };
> + };
> + };
> + };
> +
> + dsi1-host {
> + ...
> +
> + ports {
> + ...
> +
> + port {
> + dsi1_out: endpoint {
> +
[PATCH v17 04/10] drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight
Remove tinydrm_of_find_backlight from tinydrm-helpers.c. We now have
a generic of_find_backlight defined in backlight.c. Let the callers
of tinydrm_of_find_backlight call of_find_backlight. Also, remove
select BACKLIGHT_LCD_SUPPORT and select BACKLIGHT_CLASS_DEVICE from
tinydrm/Kconfig as it is a hack that is no longer needed.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-rebase with drm-misc-next
-convert st7735r callers from tinydrm specific helpers
to new generic backlight helpers
-remove select BACKLIGHT_LCD_SUPPORT
and select BACKLIGHT_CLASS_DEVICE from
tinydrm/Kconfig
drivers/gpu/drm/tinydrm/Kconfig| 2 --
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 40 --
drivers/gpu/drm/tinydrm/mi0283qt.c | 3 +-
drivers/gpu/drm/tinydrm/st7735r.c | 3 +-
include/drm/tinydrm/tinydrm-helpers.h | 2 --
5 files changed, 4 insertions(+), 46 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/Kconfig b/drivers/gpu/drm/tinydrm/Kconfig
index b0e567d41..13339be84 100644
--- a/drivers/gpu/drm/tinydrm/Kconfig
+++ b/drivers/gpu/drm/tinydrm/Kconfig
@@ -3,8 +3,6 @@ menuconfig DRM_TINYDRM
depends on DRM
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
- select BACKLIGHT_LCD_SUPPORT
- select BACKLIGHT_CLASS_DEVICE
help
Choose this option if you have a tinydrm supported display.
If M is selected the module will be called tinydrm.
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index 7326e1758..d1c3ce9ab 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -236,46 +236,6 @@ void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr,
struct drm_framebuffer *fb,
}
EXPORT_SYMBOL(tinydrm_xrgb_to_gray8);
-/**
- * tinydrm_of_find_backlight - Find backlight device in device-tree
- * @dev: Device
- *
- * This function looks for a DT node pointed to by a property named 'backlight'
- * and uses of_find_backlight_by_node() to get the backlight device.
- * Additionally if the brightness property is zero, it is set to
- * max_brightness.
- *
- * Returns:
- * NULL if there's no backlight property.
- * Error pointer -EPROBE_DEFER if the DT node is found, but no backlight device
- * is found.
- * If the backlight device is found, a pointer to the structure is returned.
- */
-struct backlight_device *tinydrm_of_find_backlight(struct device *dev)
-{
- struct backlight_device *backlight;
- struct device_node *np;
-
- np = of_parse_phandle(dev->of_node, "backlight", 0);
- if (!np)
- return NULL;
-
- backlight = of_find_backlight_by_node(np);
- of_node_put(np);
-
- if (!backlight)
- return ERR_PTR(-EPROBE_DEFER);
-
- if (!backlight->props.brightness) {
- backlight->props.brightness = backlight->props.max_brightness;
- DRM_DEBUG_KMS("Backlight brightness set to %d\n",
- backlight->props.brightness);
- }
-
- return backlight;
-}
-EXPORT_SYMBOL(tinydrm_of_find_backlight);
-
#if IS_ENABLED(CONFIG_SPI)
/**
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index 79cb5af5a..a8aafce36 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -9,6 +9,7 @@
* (at your option) any later version.
*/
+#include
#include
#include
#include
@@ -195,7 +196,7 @@ static int mi0283qt_probe(struct spi_device *spi)
if (IS_ERR(mipi->regulator))
return PTR_ERR(mipi->regulator);
- mipi->backlight = tinydrm_of_find_backlight(dev);
+ mipi->backlight = of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
diff --git a/drivers/gpu/drm/tinydrm/st7735r.c
b/drivers/gpu/drm/tinydrm/st7735r.c
index 08b4fb18e..2e6b7b8ec 100644
--- a/drivers/gpu/drm/tinydrm/st7735r.c
+++ b/drivers/gpu/drm/tinydrm/st7735r.c
@@ -5,6 +5,7 @@
* Copyright 2017 David Lechner
*/
+#include
#include
#include
#include
@@ -163,7 +164,7 @@ static int st7735r_probe(struct spi_device *spi)
return PTR_ERR(dc);
}
- mipi->backlight = tinydrm_of_find_backlight(dev);
+ mipi->backlight = of_find_backlight(dev);
if (IS_ERR(mipi->backlight))
return PTR_ERR(mipi->backlight);
diff --git a/include/drm/tinydrm/tinydrm-helpers.h
b/include/drm/tinydrm/tinydrm-helpers.h
index f54fae03e..0a4ddbc04 100644
--- a/include/drm/tinydrm/tinydrm-helpers.h
+++ b/include/drm/tinydrm/tinydrm-helpers.h
@@ -46,8 +46,6 @@ void tinydrm_xrgb_to_rgb565(u16 *dst, void *vaddr,
void tinydrm_xrgb_to_gray8(u8 *dst, void *vaddr, struct drm_framebuffer
*fb,
struct drm_clip_rect *clip);
-struct backlight_device *tinydrm_of_find_backlight
[PATCH v17 05/10] video: backlight: Add devres versions of of_find_backlight
Add devm_of_find_backlight and the corresponding release
function because some drivers use devres versions of functions
for acquiring device resources.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-fix checkpath errors/warnings
-rename devm_backlight_put to
devm_backlight_release
drivers/video/backlight/backlight.c | 30 ++
include/linux/backlight.h | 7 +++
2 files changed, 37 insertions(+)
diff --git a/drivers/video/backlight/backlight.c
b/drivers/video/backlight/backlight.c
index 553bf5c48..deb824bef 100644
--- a/drivers/video/backlight/backlight.c
+++ b/drivers/video/backlight/backlight.c
@@ -623,6 +623,36 @@ struct backlight_device *of_find_backlight(struct device
*dev)
}
EXPORT_SYMBOL(of_find_backlight);
+static void devm_backlight_release(void *data)
+{
+ backlight_put(data);
+}
+
+/**
+ * devm_of_find_backlight - Resource-managed of_find_backlight()
+ * @dev: Device
+ *
+ * Device managed version of of_find_backlight().
+ * The reference on the backlight device is automatically
+ * dropped on driver detach.
+ */
+struct backlight_device *devm_of_find_backlight(struct device *dev)
+{
+ struct backlight_device *bd;
+ int ret;
+
+ bd = of_find_backlight(dev);
+ if (IS_ERR_OR_NULL(bd))
+ return bd;
+ ret = devm_add_action(dev, devm_backlight_release, bd);
+ if (ret) {
+ backlight_put(bd);
+ return ERR_PTR(ret);
+ }
+ return bd;
+}
+EXPORT_SYMBOL(devm_of_find_backlight);
+
static void __exit backlight_class_exit(void)
{
class_destroy(backlight_class);
diff --git a/include/linux/backlight.h b/include/linux/backlight.h
index ddc9bade4..2baab6f38 100644
--- a/include/linux/backlight.h
+++ b/include/linux/backlight.h
@@ -217,11 +217,18 @@ of_find_backlight_by_node(struct device_node *node)
#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
struct backlight_device *of_find_backlight(struct device *dev);
+struct backlight_device *devm_of_find_backlight(struct device *dev);
#else
static inline struct backlight_device *of_find_backlight(struct device *dev)
{
return NULL;
}
+
+static inline struct backlight_device *
+devm_of_find_backlight(struct device *dev)
+{
+ return NULL;
+}
#endif
#endif
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 06/10] drm/tinydrm: Call devres version of of_find_backlight
Call devm_of_find_backlight (the devres version) instead of of_find_backlight. Signed-off-by: Meghana Madhyastha --- changes in v17: -convert st7735r callers from tinydrm specific helpers to new generic backlight helpers drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +- drivers/gpu/drm/tinydrm/st7735r.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c b/drivers/gpu/drm/tinydrm/mi0283qt.c index a8aafce36..d8ed6e6f8 100644 --- a/drivers/gpu/drm/tinydrm/mi0283qt.c +++ b/drivers/gpu/drm/tinydrm/mi0283qt.c @@ -196,7 +196,7 @@ static int mi0283qt_probe(struct spi_device *spi) if (IS_ERR(mipi->regulator)) return PTR_ERR(mipi->regulator); - mipi->backlight = of_find_backlight(dev); + mipi->backlight = devm_of_find_backlight(dev); if (IS_ERR(mipi->backlight)) return PTR_ERR(mipi->backlight); diff --git a/drivers/gpu/drm/tinydrm/st7735r.c b/drivers/gpu/drm/tinydrm/st7735r.c index 2e6b7b8ec..67d197ecf 100644 --- a/drivers/gpu/drm/tinydrm/st7735r.c +++ b/drivers/gpu/drm/tinydrm/st7735r.c @@ -164,7 +164,7 @@ static int st7735r_probe(struct spi_device *spi) return PTR_ERR(dc); } - mipi->backlight = of_find_backlight(dev); + mipi->backlight = devm_of_find_backlight(dev); if (IS_ERR(mipi->backlight)) return PTR_ERR(mipi->backlight); -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 07/10] drm/panel: Use backlight_enable/disable helpers
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-remove redundant NULL check
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 6 ++
drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 ++
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 10 ++
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 10 ++
4 files changed, 8 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 6ba93449f..4c1b29eec 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -45,8 +45,7 @@ static int innolux_panel_disable(struct drm_panel *panel)
if (!innolux->enabled)
return 0;
- innolux->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(innolux->backlight);
+ backlight_disable(innolux->backlight);
err = mipi_dsi_dcs_set_display_off(innolux->link);
if (err < 0)
@@ -151,8 +150,7 @@ static int innolux_panel_enable(struct drm_panel *panel)
if (innolux->enabled)
return 0;
- innolux->backlight->props.power = FB_BLANK_UNBLANK;
- ret = backlight_update_status(innolux->backlight);
+ ret = backlight_enable(innolux->backlight);
if (ret) {
DRM_DEV_ERROR(panel->drm->dev,
"Failed to enable backlight %d\n", ret);
diff --git a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
index 5b2340ef7..0a94ab79a 100644
--- a/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
+++ b/drivers/gpu/drm/panel/panel-jdi-lt070me05000.c
@@ -192,8 +192,7 @@ static int jdi_panel_disable(struct drm_panel *panel)
if (!jdi->enabled)
return 0;
- jdi->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(jdi->backlight);
+ backlight_disable(jdi->backlight);
jdi->enabled = false;
@@ -289,8 +288,7 @@ static int jdi_panel_enable(struct drm_panel *panel)
if (jdi->enabled)
return 0;
- jdi->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(jdi->backlight);
+ backlight_enable(jdi->backlight);
jdi->enabled = true;
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 3cce3ca19..072c0fc79 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -96,10 +96,7 @@ static int sharp_panel_disable(struct drm_panel *panel)
if (!sharp->enabled)
return 0;
- if (sharp->backlight) {
- sharp->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(sharp->backlight);
- }
+ backlight_disable(sharp->backlight);
sharp->enabled = false;
@@ -263,10 +260,7 @@ static int sharp_panel_enable(struct drm_panel *panel)
if (sharp->enabled)
return 0;
- if (sharp->backlight) {
- sharp->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(sharp->backlight);
- }
+ backlight_enable(sharp->backlight);
sharp->enabled = true;
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 3aeb0bda4..8a5137963 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -117,10 +117,7 @@ static int sharp_nt_panel_disable(struct drm_panel *panel)
if (!sharp_nt->enabled)
return 0;
- if (sharp_nt->backlight) {
- sharp_nt->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(sharp_nt->backlight);
- }
+ backlight_disable(sharp_nt->backlight);
sharp_nt->enabled = false;
@@ -203,10 +200,7 @@ static int sharp_nt_panel_enable(struct drm_panel *panel)
if (sharp_nt->enabled)
return 0;
- if (sharp_nt->backlight) {
- sharp_nt->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(sharp_nt->backlight);
- }
+ backlight_enable(sharp_nt->backlight);
sharp_nt->enabled = true;
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 08/10] drm/omapdrm: Use backlight_enable/disable helpers
Use backlight_enable/disable helpers instead of changing
the property and calling backlight_update_status for cleaner
and simpler code and also to avoid repetitions.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-remove redundant NULL check
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 11 ++-
1 file changed, 2 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index e065f7e10..ac9596251 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -87,11 +87,7 @@ static int panel_dpi_enable(struct omap_dss_device *dssdev)
}
gpiod_set_value_cansleep(ddata->enable_gpio, 1);
-
- if (ddata->backlight) {
- ddata->backlight->props.power = FB_BLANK_UNBLANK;
- backlight_update_status(ddata->backlight);
- }
+ backlight_enable(ddata->backlight);
dssdev->state = OMAP_DSS_DISPLAY_ACTIVE;
@@ -106,10 +102,7 @@ static void panel_dpi_disable(struct omap_dss_device
*dssdev)
if (!omapdss_device_is_enabled(dssdev))
return;
- if (ddata->backlight) {
- ddata->backlight->props.power = FB_BLANK_POWERDOWN;
- backlight_update_status(ddata->backlight);
- }
+ backlight_disable(ddata->backlight);
gpiod_set_value_cansleep(ddata->enable_gpio, 0);
regulator_disable(ddata->vcc_supply);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v17 09/10] drm/panel: Use of_find_backlight helper
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-remove put_device() to avoid double put
as we are using the devm version
drivers/gpu/drm/panel/panel-innolux-p079zca.c | 23 ---
drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 25 -
drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 25 -
3 files changed, 12 insertions(+), 61 deletions(-)
diff --git a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
index 4c1b29eec..059f4af1a 100644
--- a/drivers/gpu/drm/panel/panel-innolux-p079zca.c
+++ b/drivers/gpu/drm/panel/panel-innolux-p079zca.c
@@ -230,37 +230,22 @@ static int innolux_panel_add(struct innolux_panel
*innolux)
innolux->enable_gpio = NULL;
}
- np = of_parse_phandle(dev->of_node, "backlight", 0);
- if (np) {
- innolux->backlight = of_find_backlight_by_node(np);
- of_node_put(np);
+ innolux->backlight = devm_of_find_backlight(np);
- if (!innolux->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(innolux->backlight))
+ return PTR_ERR(innolux->backlight);
drm_panel_init(&innolux->base);
innolux->base.funcs = &innolux_panel_funcs;
innolux->base.dev = &innolux->link->dev;
- err = drm_panel_add(&innolux->base);
- if (err < 0)
- goto put_backlight;
-
- return 0;
-
-put_backlight:
- put_device(&innolux->backlight->dev);
-
- return err;
+ return drm_panel_add(&innolux->base);
}
static void innolux_panel_del(struct innolux_panel *innolux)
{
if (innolux->base.dev)
drm_panel_remove(&innolux->base);
-
- put_device(&innolux->backlight->dev);
}
static int innolux_panel_probe(struct mipi_dsi_device *dsi)
diff --git a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
index 072c0fc79..85279d224 100644
--- a/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c
@@ -327,30 +327,16 @@ static int sharp_panel_add(struct sharp_panel *sharp)
if (IS_ERR(sharp->supply))
return PTR_ERR(sharp->supply);
- np = of_parse_phandle(sharp->link1->dev.of_node, "backlight", 0);
- if (np) {
- sharp->backlight = of_find_backlight_by_node(np);
- of_node_put(np);
+ sharp->backlight = devm_of_find_backlight(np);
- if (!sharp->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(sharp->backlight))
+ return PTR_ERR(sharp->backlight);
drm_panel_init(&sharp->base);
sharp->base.funcs = &sharp_panel_funcs;
sharp->base.dev = &sharp->link1->dev;
- err = drm_panel_add(&sharp->base);
- if (err < 0)
- goto put_backlight;
-
- return 0;
-
-put_backlight:
- if (sharp->backlight)
- put_device(&sharp->backlight->dev);
-
- return err;
+ return drm_panel_add(&sharp->base);
}
static void sharp_panel_del(struct sharp_panel *sharp)
@@ -358,9 +344,6 @@ static void sharp_panel_del(struct sharp_panel *sharp)
if (sharp->base.dev)
drm_panel_remove(&sharp->base);
- if (sharp->backlight)
- put_device(&sharp->backlight->dev);
-
if (sharp->link2)
put_device(&sharp->link2->dev);
}
diff --git a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
index 8a5137963..b634ec887 100644
--- a/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
+++ b/drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c
@@ -271,39 +271,22 @@ static int sharp_nt_panel_add(struct sharp_nt_panel
*sharp_nt)
gpiod_set_value(sharp_nt->reset_gpio, 0);
}
- np = of_parse_phandle(dev->of_node, "backlight", 0);
- if (np) {
- sharp_nt->backlight = of_find_backlight_by_node(np);
- of_node_put(np);
+ sharp_nt->backlight = devm_of_find_backlight(np);
- if (!sharp_nt->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(sharp_nt->backlight))
+ return PTR_ERR(sharp_nt->backlight);
drm_panel_init(&sharp_nt->base);
sharp_nt->base.funcs = &sharp_nt_panel_funcs;
sharp_nt->base.dev = &sharp_nt->dsi->dev;
- ret = drm_panel_add(&sharp_nt->base);
- if (ret < 0)
- goto put_backlight;
-
- return 0;
-
-put_backlight:
- if (sharp_nt->backlight)
- put_device(&sharp_nt->backlight->dev);
-
- return ret;
+ return drm_panel_add(&sharp_nt->base);
}
static void sharp_nt_panel_del(struct s
[PATCH v17 10/10] drm/omapdrm: Use of_find_backlight helper
Replace of_find_backlight_by_node and of the code around it
with of_find_backlight helper to avoid repetition of code.
Signed-off-by: Meghana Madhyastha
---
changes in v17:
-remove put_device() to avoid double put
as we are using the devm version
drivers/gpu/drm/omapdrm/displays/panel-dpi.c | 21 +
1 file changed, 5 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
index ac9596251..4d598167f 100644
--- a/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
+++ b/drivers/gpu/drm/omapdrm/displays/panel-dpi.c
@@ -183,19 +183,15 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
if (IS_ERR(ddata->vcc_supply))
return PTR_ERR(ddata->vcc_supply);
- bl_node = of_parse_phandle(node, "backlight", 0);
- if (bl_node) {
- ddata->backlight = of_find_backlight_by_node(bl_node);
- of_node_put(bl_node);
+ ddata->backlight = of_find_backlight(bl_node);
- if (!ddata->backlight)
- return -EPROBE_DEFER;
- }
+ if (IS_ERR(ddata->backlight))
+ return PTR_ERR(ddata->backlight);
r = of_get_display_timing(node, "panel-timing", &timing);
if (r) {
dev_err(&pdev->dev, "failed to get video timing\n");
- goto error_free_backlight;
+ return r;
}
videomode_from_timing(&timing, &ddata->vm);
@@ -203,19 +199,12 @@ static int panel_dpi_probe_of(struct platform_device
*pdev)
in = omapdss_of_find_source_for_first_ep(node);
if (IS_ERR(in)) {
dev_err(&pdev->dev, "failed to find video source\n");
- r = PTR_ERR(in);
- goto error_free_backlight;
+ return PTR_ERR(in);
}
ddata->in = in;
return 0;
-
-error_free_backlight:
- if (ddata->backlight)
- put_device(&ddata->backlight->dev);
-
- return r;
}
static int panel_dpi_probe(struct platform_device *pdev)
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 01/10] video: backlight: Add helpers to enable and disable backlight
On Fri, Jan 19, 2018 at 10:39:16AM +, Meghana Madhyastha wrote:
> Add helper functions backlight_enable and backlight_disable to
> enable/disable a backlight device. These helper functions can
> then be used by different drm and tinydrm drivers to avoid
> repetition of code and also to enforce a uniform and consistent
> way to enable/disable a backlight device.
>
> Signed-off-by: Meghana Madhyastha
Acked-by: Daniel Thompson
BTW Lee J. looks PRs and merges for the backlight tree, I'll leave it
to Lee and whoevers-DRM-tree-this-would-naturally-land-in to decide the
merge path.
Daniel.
> ---
> changes in v17:
> -set fb_blank along with clearing the BL_CORE_FBBLANK bit
>
> include/linux/backlight.h | 32
> 1 file changed, 32 insertions(+)
>
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index af7003548..ace825e2c 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -130,6 +130,38 @@ static inline int backlight_update_status(struct
> backlight_device *bd)
> return ret;
> }
>
> +/**
> + * backlight_enable - Enable backlight
> + * @bd: the backlight device to enable
> + */
> +static inline int backlight_enable(struct backlight_device *bd)
> +{
> + if (!bd)
> + return 0;
> +
> + bd->props.power = FB_BLANK_UNBLANK;
> + bd->props.fb_blank = FB_BLANK_UNBLANK;
> + bd->props.state &= ~BL_CORE_FBBLANK;
> +
> + return backlight_update_status(bd);
> +}
> +
> +/**
> + * backlight_disable - Disable backlight
> + * @bd: the backlight device to disable
> + */
> +static inline int backlight_disable(struct backlight_device *bd)
> +{
> + if (!bd)
> + return 0;
> +
> + bd->props.power = FB_BLANK_POWERDOWN;
> + bd->props.fb_blank = FB_BLANK_POWERDOWN;
> + bd->props.state |= BL_CORE_FBBLANK;
> +
> + return backlight_update_status(bd);
> +}
> +
> extern struct backlight_device *backlight_device_register(const char *name,
> struct device *dev, void *devdata, const struct backlight_ops *ops,
> const struct backlight_properties *props);
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm/panel: otm8009a: Adopt SPDX identifiers
Add SPDX identifiers to OriseTech OTM8009a panel driver. Signed-off-by: Philippe Cornu --- drivers/gpu/drm/panel/panel-orisetech-otm8009a.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c index c189cd6329c8..72530983d55d 100644 --- a/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c +++ b/drivers/gpu/drm/panel/panel-orisetech-otm8009a.c @@ -1,11 +1,11 @@ +// SPDX-License-Identifier: GPL-2.0 /* * Copyright (C) STMicroelectronics SA 2017 * * Authors: Philippe Cornu * Yannick Fertre - * - * License terms: GNU General Public License (GPL), version 2 */ + #include #include #include -- 2.15.1 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 03/10] video: backlight: Add of_find_backlight helper in backlight.c
On Fri, Jan 19, 2018 at 10:42:15AM +, Meghana Madhyastha wrote:
> Add of_find_backlight, a helper function which is a generic version
> of tinydrm_of_find_backlight that can be used by other drivers to avoid
> repetition of code and simplify things.
>
> Signed-off-by: Meghana Madhyastha
Didn't I already ack this one?
> ---
> changes in v17:
> -rebase with drm-misc-next
> -convert st7735r callers from tinydrm specific helpers
> to new generic backlight helpers
> -remove select BACKLIGHT_LCD_SUPPORT
> and select BACKLIGHT_CLASS_DEVICE from
> tinydrm/Kconfig
>
> drivers/video/backlight/backlight.c | 43
> +
> include/linux/backlight.h | 19
> 2 files changed, 62 insertions(+)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 8049e7656..553bf5c48 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -580,6 +580,49 @@ struct backlight_device
> *of_find_backlight_by_node(struct device_node *node)
> EXPORT_SYMBOL(of_find_backlight_by_node);
> #endif
>
> +/**
> + * of_find_backlight - Get backlight device
> + * @dev: Device
> + *
> + * This function looks for a property named 'backlight' on the DT node
> + * connected to @dev and looks up the backlight device.
> + *
> + * Call backlight_put() to drop the reference on the backlight device.
> + *
> + * Returns:
> + * A pointer to the backlight device if found.
> + * Error pointer -EPROBE_DEFER if the DT property is set, but no backlight
> + * device is found.
> + * NULL if there's no backlight property.
> + */
> +struct backlight_device *of_find_backlight(struct device *dev)
> +{
> + struct backlight_device *bd = NULL;
> + struct device_node *np;
> +
> + if (!dev)
> + return NULL;
> +
> + if (IS_ENABLED(CONFIG_OF) && dev->of_node) {
> + np = of_parse_phandle(dev->of_node, "backlight", 0);
> + if (np) {
> + bd = of_find_backlight_by_node(np);
> + of_node_put(np);
> + if (!bd)
> + return ERR_PTR(-EPROBE_DEFER);
> + /*
> + * Note: gpio_backlight uses brightness as
> + * power state during probe
> + */
> + if (!bd->props.brightness)
> + bd->props.brightness = bd->props.max_brightness;
> + }
> + }
> +
> + return bd;
> +}
> +EXPORT_SYMBOL(of_find_backlight);
> +
> static void __exit backlight_class_exit(void)
> {
> class_destroy(backlight_class);
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index ace825e2c..ddc9bade4 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -162,6 +162,16 @@ static inline int backlight_disable(struct
> backlight_device *bd)
> return backlight_update_status(bd);
> }
>
> +/**
> + * backlight_put - Drop backlight reference
> + * @bd: the backlight device to put
> + */
> +static inline void backlight_put(struct backlight_device *bd)
> +{
> + if (bd)
> + put_device(&bd->dev);
> +}
> +
> extern struct backlight_device *backlight_device_register(const char *name,
> struct device *dev, void *devdata, const struct backlight_ops *ops,
> const struct backlight_properties *props);
> @@ -205,4 +215,13 @@ of_find_backlight_by_node(struct device_node *node)
> }
> #endif
>
> +#if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> +struct backlight_device *of_find_backlight(struct device *dev);
> +#else
> +static inline struct backlight_device *of_find_backlight(struct device *dev)
> +{
> + return NULL;
> +}
> +#endif
> +
> #endif
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 05/10] video: backlight: Add devres versions of of_find_backlight
On Fri, Jan 19, 2018 at 10:44:33AM +, Meghana Madhyastha wrote:
> Add devm_of_find_backlight and the corresponding release
> function because some drivers use devres versions of functions
> for acquiring device resources.
>
> Signed-off-by: Meghana Madhyastha
Acked-by: Daniel Thompson
> ---
> changes in v17:
> -fix checkpath errors/warnings
> -rename devm_backlight_put to
> devm_backlight_release
>
> drivers/video/backlight/backlight.c | 30 ++
> include/linux/backlight.h | 7 +++
> 2 files changed, 37 insertions(+)
>
> diff --git a/drivers/video/backlight/backlight.c
> b/drivers/video/backlight/backlight.c
> index 553bf5c48..deb824bef 100644
> --- a/drivers/video/backlight/backlight.c
> +++ b/drivers/video/backlight/backlight.c
> @@ -623,6 +623,36 @@ struct backlight_device *of_find_backlight(struct device
> *dev)
> }
> EXPORT_SYMBOL(of_find_backlight);
>
> +static void devm_backlight_release(void *data)
> +{
> + backlight_put(data);
> +}
> +
> +/**
> + * devm_of_find_backlight - Resource-managed of_find_backlight()
> + * @dev: Device
> + *
> + * Device managed version of of_find_backlight().
> + * The reference on the backlight device is automatically
> + * dropped on driver detach.
> + */
> +struct backlight_device *devm_of_find_backlight(struct device *dev)
> +{
> + struct backlight_device *bd;
> + int ret;
> +
> + bd = of_find_backlight(dev);
> + if (IS_ERR_OR_NULL(bd))
> + return bd;
> + ret = devm_add_action(dev, devm_backlight_release, bd);
> + if (ret) {
> + backlight_put(bd);
> + return ERR_PTR(ret);
> + }
> + return bd;
> +}
> +EXPORT_SYMBOL(devm_of_find_backlight);
> +
> static void __exit backlight_class_exit(void)
> {
> class_destroy(backlight_class);
> diff --git a/include/linux/backlight.h b/include/linux/backlight.h
> index ddc9bade4..2baab6f38 100644
> --- a/include/linux/backlight.h
> +++ b/include/linux/backlight.h
> @@ -217,11 +217,18 @@ of_find_backlight_by_node(struct device_node *node)
>
> #if IS_ENABLED(CONFIG_BACKLIGHT_CLASS_DEVICE)
> struct backlight_device *of_find_backlight(struct device *dev);
> +struct backlight_device *devm_of_find_backlight(struct device *dev);
> #else
> static inline struct backlight_device *of_find_backlight(struct device *dev)
> {
> return NULL;
> }
> +
> +static inline struct backlight_device *
> +devm_of_find_backlight(struct device *dev)
> +{
> + return NULL;
> +}
> #endif
>
> #endif
> --
> 2.11.0
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 00/10] Add backlight helper functions
On Fri, Jan 19, 2018 at 10:37:58AM +, Meghana Madhyastha wrote: > Move drm helper functions from tinydrm-helpers to linux/backlight for > ease of use by callers in other drivers. > > changes in v17: > -set fb_blank along with clearing the BL_CORE_FBBLANK bit > -rebase with drm-misc-next > -fix checkpath errors/warnings > -Make the gpio_backlight issue appear as a comment in the > code and not as part of the docs > -rebase with drm-misc-next > -convert st7735r callers from tinydrm specific helpers > to new generic backlight helpers > -remove select BACKLIGHT_LCD_SUPPORT and select > BACKLIGHT_CLASS_DEVICE from tinydrm/Kconfig > -fix checkpath errors/warnings > -rename devm_backlight_put to > devm_backlight_release > -remove redundant NULL check > -remove put_device() to avoid double put > as we are using the devm version > > Meghana Madhyastha (10): > video: backlight: Add helpers to enable and disable backlight > drm/tinydrm: Convert tinydrm_enable/disable_backlight to > backlight_enable/disable > video: backlight: Add of_find_backlight helper in backlight.c > drm/tinydrm: Replace tinydrm_of_find_backlight with of_find_backlight > video: backlight: Add devres versions of of_find_backlight > drm/tinydrm: Call devres version of of_find_backlight > drm/panel: Use backlight_enable/disable helpers > drm/omapdrm: Use backlight_enable/disable helpers > drm/panel: Use of_find_backlight helper > drm/omapdrm: Use of_find_backlight helper So, I've acked all the backlight bits (if there's a v18 please include the acks in the posting). I've read the other patches and I *like* them. Switching to backlight_enable()/disable() looks like a good way to ensure drivers don't interact with all those flags in unexpected ways (so its a good contribution to eventually cleaning them up). Daniel. > > drivers/gpu/drm/omapdrm/displays/panel-dpi.c| 32 ++--- > drivers/gpu/drm/panel/panel-innolux-p079zca.c | 29 ++-- > drivers/gpu/drm/panel/panel-jdi-lt070me05000.c | 6 +- > drivers/gpu/drm/panel/panel-sharp-lq101r1sx01.c | 35 ++--- > drivers/gpu/drm/panel/panel-sharp-ls043t1le01.c | 35 ++--- > drivers/gpu/drm/tinydrm/Kconfig | 2 - > drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 95 > - > drivers/gpu/drm/tinydrm/mi0283qt.c | 3 +- > drivers/gpu/drm/tinydrm/mipi-dbi.c | 4 +- > drivers/gpu/drm/tinydrm/st7735r.c | 3 +- > drivers/video/backlight/backlight.c | 73 +++ > include/drm/tinydrm/tinydrm-helpers.h | 4 -- > include/linux/backlight.h | 58 +++ > 13 files changed, 164 insertions(+), 215 deletions(-) > > -- > 2.11.0 > ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 198513] [DRM] amdgpu fails to load firmware on boot
https://bugzilla.kernel.org/show_bug.cgi?id=198513 Matt (m.mcn...@gmail.com) changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |CODE_FIX --- Comment #3 from Matt (m.mcn...@gmail.com) --- purged all my 4.15 kernels and reverted to the latest Fedora 4.14, then reinstalled 4.15 - that seems to have regenerated the initrd all good now, resolving -- 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 198513] [DRM] amdgpu fails to load firmware on boot
https://bugzilla.kernel.org/show_bug.cgi?id=198513 Matt (m.mcn...@gmail.com) changed: What|Removed |Added Resolution|CODE_FIX|INVALID -- You are receiving this mail because: You are watching the assignee of the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
Am 19.01.2018 um 11:40 schrieb Michal Hocko: On Fri 19-01-18 09:39:03, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: [...] OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. I already tried that and the problem with that approach is that some buffers are not created by the application which actually uses them. For example X/Wayland is creating and handing out render buffers to application which want to use OpenGL. So the result is when you always account the application who created the buffer the OOM killer will certainly reap X/Wayland first. And that is exactly what we want to avoid here. Then you have to find the target allocation context at the time of the allocation and account it. And exactly that's the root of the problem: The target allocation context isn't known at the time of the allocation. We could add callbacks so that when the memory is passed from the allocator to the actual user of the memory. In other words when the memory is passed from the X server to the client the driver would need to decrement the X servers accounting and increment the clients accounting. But I think that would go deep into the file descriptor handling (we would at least need to handle dup/dup2 and passing the fd using unix domain sockets) and most likely would be rather error prone. The per file descriptor badness is/was just the much easier approach to solve the issue, because the drivers already knew which client is currently using which buffer objects. I of course agree that file descriptors can be shared between processes and are by themselves not killable. But at least for our graphics driven use case I don't see much of a problem killing all processes when a file descriptor is used by more than one at the same time. Regards, Christian. As follow up emails show, implementations might differ and any robust oom solution have to rely on the common counters. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 2/3] dt-bindings: etnaviv: change clocks to be optional
While the clocks were documented as required, the driver always treated them as optional and there are existing Marvell Dove DTs, which would break if changed to required. Accept reality and document the clocks as optional. Signed-off-by: Lucas Stach --- .../devicetree/bindings/display/etnaviv/etnaviv-drm.txt| 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt index c6f4e023c34a..f28aa5735f4f 100644 --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt @@ -30,16 +30,16 @@ Required properties: - reg: should be register base and length as documented in the datasheet - interrupts: Should contain the cores interrupt line + +Optional properties: +- power-domains: a power domain consumer specifier according to + Documentation/devicetree/bindings/power/power_domain.txt - clocks: should contain one clock for entry in clock-names see Documentation/devicetree/bindings/clock/clock-bindings.txt - clock-names: - "bus":AXI/register clock - "core": GPU core clock - - "shader": Shader clock (only required if GPU has feature PIPE_3D) - -Optional properties: -- power-domains: a power domain consumer specifier according to - Documentation/devicetree/bindings/power/power_domain.txt + - "shader": Shader clock (only if GPU has feature PIPE_3D) example: -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm/etnaviv: add generic compatible for the GPU subsystem node
With different SoCs gaining support for etnaviv it doesn't make much sense
to add specific compatibles for the generic GPU subsystem node, which is
only used to find all GPU core nodes.
Add a generic compatible, that can be used by all new implementations.
Signed-off-by: Lucas Stach
---
Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 1 +
drivers/gpu/drm/etnaviv/etnaviv_drv.c | 1 +
2 files changed, 2 insertions(+)
diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
index 05176f1ae108..c6f4e023c34a 100644
--- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
+++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt
@@ -8,6 +8,7 @@ Required properties:
- compatible: Should be one of
"fsl,imx-gpu-subsystem"
"marvell,dove-gpu-subsystem"
+"vivante,gpu-subsystem"
- cores: Should contain a list of phandles pointing to Vivante GPU devices
example:
diff --git a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
index 491eddf9b150..c9fb94f6b976 100644
--- a/drivers/gpu/drm/etnaviv/etnaviv_drv.c
+++ b/drivers/gpu/drm/etnaviv/etnaviv_drv.c
@@ -694,6 +694,7 @@ static int etnaviv_pdev_remove(struct platform_device *pdev)
static const struct of_device_id dt_match[] = {
{ .compatible = "fsl,imx-gpu-subsystem" },
{ .compatible = "marvell,dove-gpu-subsystem" },
+ { .compatible = "vivante,gpu-subsystem" },
{}
};
MODULE_DEVICE_TABLE(of, dt_match);
--
2.11.0
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #40 from wbr...@gmail.com --- Does it still occur with recent distros like Ubuntu 17.10? -- 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/vmwgfx: Return boolean instead of integer in vmw_fence_obj_signaled
On 01/19/2018 01:02 AM, Gustavo A. R. Silva wrote: Return statements in functions returning bool should use true/false instead of 1/0. This issue was detected with the help of Coccinelle. Signed-off-by: Gustavo A. R. Silva Reviewed-by: Thomas Hellström I'll queue this for 4.17. Thanks, Thomas --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c index 6c5c75c..35fd6f9 100644 --- a/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c +++ b/drivers/gpu/drm/vmwgfx/vmwgfx_fence.c @@ -496,7 +496,7 @@ bool vmw_fence_obj_signaled(struct vmw_fence_obj *fence) struct vmw_fence_manager *fman = fman_from_fence(fence); if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, &fence->base.flags)) - return 1; + return true; vmw_fences_update(fman); ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 3/3] dt-bindings: etnaviv: add slave interface clock
Newer GPU cores added a new clock input, which allows to gate the slave (AHB) interface independently from other parts of the GPU. Add it to the supported clocks. Signed-off-by: Lucas Stach --- Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt index f28aa5735f4f..5daee0a3da45 100644 --- a/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt +++ b/Documentation/devicetree/bindings/display/etnaviv/etnaviv-drm.txt @@ -37,7 +37,8 @@ Optional properties: - clocks: should contain one clock for entry in clock-names see Documentation/devicetree/bindings/clock/clock-bindings.txt - clock-names: - - "bus":AXI/register clock + - "bus":AXI/master interface clock + - "reg":AHB/slave interface clock - "core": GPU core clock - "shader": Shader clock (only if GPU has feature PIPE_3D) -- 2.11.0 ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH v17 01/10] video: backlight: Add helpers to enable and disable backlight
On Fri, 19 Jan 2018, Daniel Thompson wrote: > On Fri, Jan 19, 2018 at 10:39:16AM +, Meghana Madhyastha wrote: > > Add helper functions backlight_enable and backlight_disable to > > enable/disable a backlight device. These helper functions can > > then be used by different drm and tinydrm drivers to avoid > > repetition of code and also to enforce a uniform and consistent > > way to enable/disable a backlight device. > > > > Signed-off-by: Meghana Madhyastha > > Acked-by: Daniel Thompson > > BTW Lee J. looks PRs and merges for the backlight tree, I'll leave it > to Lee and whoevers-DRM-tree-this-would-naturally-land-in to decide the > merge path. So the choices are; either I take the set and send out a pull-request which can be subsequently merged into the DRM repo, OR they are applied into an immutable branch in the DRM tree and I can pull that in instead. Don't really mind which. -- Lee Jones Linaro Services Technical Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 98520] System randomly crashes / freezes while playing certain games
https://bugs.freedesktop.org/show_bug.cgi?id=98520 --- Comment #41 from MirceaKitsune --- (In reply to wbrana from comment #40) Hi. I do not run Ubuntu, just openSUSE Tumbleweed. However they finally upgraded to Mesa 17.3.2 recently, so I may test more games soon and see if there are any crashes left. Since I reported this nearly two years ago, the original crash was most certainly lost in all the changes done since... new ones may still exist however. -- 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 104216] Firefox quirks (black and/or white squares)
https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #9 from Germano Massullo --- Created attachment 136846 --> https://bugs.freedesktop.org/attachment.cgi?id=136846&action=edit LIBGL_DEBUG=verbose firefox -- 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 104216] Firefox quirks (black and/or white squares)
https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #10 from Germano Massullo --- Created attachment 136847 --> https://bugs.freedesktop.org/attachment.cgi?id=136847&action=edit Xorg.0.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
Re: [PATCH 00/12] Cargo cult cleanup in atomic drivers
2018-01-17 22:55 GMT+01:00 Laurent Pinchart : > Hello, > > This patch series removes a few cargo-cult constructs from a set of atomic > drivers. > > Patches 01/12 and 02/12 remove the unneeded .mode_set() and .mode_set_base() > CRTC handlers from the arc and atmel-hlcdc drivers. > > Patches 03/12 to 12/12 then remove the use of drm_plane_helper_disable() from > the plane .destroy() handlers of atomic drivers, replacing them with the use > of drm_atomic_helper_shutdown() at removal time. Interleaved there are patches > 04/12 and 06/12 that remove unnecessary cleanups in error paths, and patch > 09/12 that adds missing cleanup. > > All this has been compile-tested only. Sorry but sti patches make the platform crash when removing display module. Benjamin > > Laurent Pinchart (12): > drm: arc: Don't set CRTC .mode_set and .mode_set_base handlers > drm: atmel-hlcdc: Don't set CRTC .mode_set and .mode_set_base handlers > drm: arc: Use drm_atomic_helper_shutdown() to disable planes on > removal > drm: arm: hdlcd: Don't destroy plane manually in hdlcd_setup_crtc() > drm: arm: hdlcd: Use drm_atomic_helper_shutdown() to disable planes on > removal > drm: arm: malidp: Don't destroy planes manually in error handlers > drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes > on removal > drm: msm: Use drm_atomic_helper_shutdown() to disable planes on > removal > drm: sti: Cleanup KMS objects on removal > drm: sti: Use drm_atomic_helper_shutdown() to disable planes on > removal > drm: vc4: Use drm_atomic_helper_shutdown() to disable planes on > removal > drm: zte: Use drm_atomic_helper_shutdown() to disable planes on > removal > > drivers/gpu/drm/arc/arcpgu_crtc.c | 12 ++-- > drivers/gpu/drm/arc/arcpgu_drv.c | 1 + > drivers/gpu/drm/arm/hdlcd_crtc.c | 12 ++-- > drivers/gpu/drm/arm/hdlcd_drv.c| 1 + > drivers/gpu/drm/arm/malidp_crtc.c | 10 ++ > drivers/gpu/drm/arm/malidp_drv.c | 2 +- > drivers/gpu/drm/arm/malidp_drv.h | 1 - > drivers/gpu/drm/arm/malidp_planes.c| 17 + > drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_crtc.c | 2 -- > drivers/gpu/drm/msm/Kconfig| 1 - > drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c | 1 - > drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c | 1 - > drivers/gpu/drm/msm/msm_drv.c | 1 + > drivers/gpu/drm/sti/sti_cursor.c | 10 +- > drivers/gpu/drm/sti/sti_drv.c | 2 ++ > drivers/gpu/drm/sti/sti_gdp.c | 10 +- > drivers/gpu/drm/sti/sti_hqvdp.c| 10 +- > drivers/gpu/drm/vc4/Kconfig| 1 - > drivers/gpu/drm/vc4/vc4_drv.c | 3 +++ > drivers/gpu/drm/vc4/vc4_plane.c| 8 +--- > drivers/gpu/drm/zte/Kconfig| 2 +- > drivers/gpu/drm/zte/zx_drm_drv.c | 1 + > drivers/gpu/drm/zte/zx_plane.c | 8 +--- > 23 files changed, 23 insertions(+), 94 deletions(-) > > -- > Regards, > > Laurent Pinchart > -- Benjamin Gaignard Graphic Study Group Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On 2018-01-19 11:02 AM, Michel Dänzer wrote: > On 2018-01-19 10:58 AM, Christian König wrote: >> Am 19.01.2018 um 10:32 schrieb Michel Dänzer: >>> On 2018-01-19 09:39 AM, Christian König wrote: Am 19.01.2018 um 09:20 schrieb Michal Hocko: > OK, in that case I would propose a different approach. We already > have rss_stat. So why do not we simply add a new counter there > MM_KERNELPAGES and consider those in oom_badness? The rule would be > that such a memory is bound to the process life time. I guess we will > find more users for this later. I already tried that and the problem with that approach is that some buffers are not created by the application which actually uses them. For example X/Wayland is creating and handing out render buffers to application which want to use OpenGL. So the result is when you always account the application who created the buffer the OOM killer will certainly reap X/Wayland first. And that is exactly what we want to avoid here. >>> FWIW, what you describe is true with DRI2, but not with DRI3 or Wayland >>> anymore. With DRI3 and Wayland, buffers are allocated by the clients and >>> then shared with the X / Wayland server. >> >> Good point, when I initially looked at that problem DRI3 wasn't widely >> used yet. >> >>> Also, in all cases, the amount of memory allocated for buffers shared >>> between DRI/Wayland clients and the server should be relatively small >>> compared to the amount of memory allocated for buffers used only locally >>> in the client, particularly for clients which create significant memory >>> pressure. >> >> That is unfortunately only partially true. When you have a single >> runaway application which tries to allocate everything it would indeed >> work as you described. >> >> But when I tested this a few years ago with X based desktop the >> applications which actually used most of the memory where Firefox and >> Thunderbird. Unfortunately they never got accounted for that. >> >> Now, on my current Wayland based desktop it actually doesn't look much >> better. Taking a look at radeon_gem_info/amdgpu_gem_info the majority of >> all memory was allocated either by gnome-shell or Xwayland. > > My guess would be this is due to pixmaps, which allow X clients to cause > the X server to allocate essentially unlimited amounts of memory. It's a > separate issue, which would require a different solution than what we're > discussing in this thread. Maybe something that would allow the X server > to tell the kernel that some of the memory it allocates is for the > client process. Of course, such a mechanism could probably be abused to incorrectly blame other processes for one's own memory consumption... I'm not sure if the pixmap issue can be solved for the OOM killer. It's an X design issue which is fixed with Wayland. So it's probably better to ignore it for this discussion. Also, I really think the issue with DRM buffers being shared between processes isn't significant for the OOM killer compared to DRM buffers only used in the same process that allocates them. So I suggest focusing on the latter. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 2/6] iommu/arm-smmu: Add pm_runtime/sleep ops
From: Sricharan R
The smmu needs to be functional only when the respective
master's using it are active. The device_link feature
helps to track such functional dependencies, so that the
iommu gets powered when the master device enables itself
using pm_runtime. So by adapting the smmu driver for
runtime pm, above said dependency can be addressed.
This patch adds the pm runtime/sleep callbacks to the
driver and also the functions to parse the smmu clocks
from DT and enable them in resume/suspend.
Signed-off-by: Sricharan R
Signed-off-by: Archit Taneja
[vivek: Clock rework to request bulk of clocks]
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 55 ++--
1 file changed, 53 insertions(+), 2 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 78d4c6b8f1ba..21acffe91a1c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -48,6 +48,7 @@
#include
#include
#include
+#include
#include
#include
@@ -205,6 +206,9 @@ struct arm_smmu_device {
u32 num_global_irqs;
u32 num_context_irqs;
unsigned int*irqs;
+ struct clk_bulk_data*clocks;
+ int num_clks;
+ const char * const *clk_names;
u32 cavium_id_base; /* Specific to Cavium */
@@ -1685,6 +1689,25 @@ static int arm_smmu_id_size_to_bits(int size)
}
}
+static int arm_smmu_init_clocks(struct arm_smmu_device *smmu)
+{
+ int i;
+ int num = smmu->num_clks;
+
+ if (num < 1)
+ return 0;
+
+ smmu->clocks = devm_kcalloc(smmu->dev, num,
+ sizeof(*smmu->clocks), GFP_KERNEL);
+ if (!smmu->clocks)
+ return -ENOMEM;
+
+ for (i = 0; i < num; i++)
+ smmu->clocks[i].id = smmu->clk_names[i];
+
+ return devm_clk_bulk_get(smmu->dev, num, smmu->clocks);
+}
+
static int arm_smmu_device_cfg_probe(struct arm_smmu_device *smmu)
{
unsigned long size;
@@ -1897,10 +1920,12 @@ static int arm_smmu_device_cfg_probe(struct
arm_smmu_device *smmu)
struct arm_smmu_match_data {
enum arm_smmu_arch_version version;
enum arm_smmu_implementation model;
+ const char * const *clks;
+ int num_clks;
};
#define ARM_SMMU_MATCH_DATA(name, ver, imp)\
-static struct arm_smmu_match_data name = { .version = ver, .model = imp }
+static const struct arm_smmu_match_data name = { .version = ver, .model = imp }
ARM_SMMU_MATCH_DATA(smmu_generic_v1, ARM_SMMU_V1, GENERIC_SMMU);
ARM_SMMU_MATCH_DATA(smmu_generic_v2, ARM_SMMU_V2, GENERIC_SMMU);
@@ -2001,6 +2026,8 @@ static int arm_smmu_device_dt_probe(struct
platform_device *pdev,
data = of_device_get_match_data(dev);
smmu->version = data->version;
smmu->model = data->model;
+ smmu->clk_names = data->clks;
+ smmu->num_clks = data->num_clks;
parse_driver_options(smmu);
@@ -2099,6 +2126,10 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
smmu->irqs[i] = irq;
}
+ err = arm_smmu_init_clocks(smmu);
+ if (err)
+ return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2197,7 +2228,27 @@ static int __maybe_unused arm_smmu_pm_resume(struct
device *dev)
return 0;
}
-static SIMPLE_DEV_PM_OPS(arm_smmu_pm_ops, NULL, arm_smmu_pm_resume);
+static int __maybe_unused arm_smmu_runtime_resume(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ return clk_bulk_prepare_enable(smmu->num_clks, smmu->clocks);
+}
+
+static int __maybe_unused arm_smmu_runtime_suspend(struct device *dev)
+{
+ struct arm_smmu_device *smmu = dev_get_drvdata(dev);
+
+ clk_bulk_disable_unprepare(smmu->num_clks, smmu->clocks);
+
+ return 0;
+}
+
+static const struct dev_pm_ops arm_smmu_pm_ops = {
+ SET_SYSTEM_SLEEP_PM_OPS(NULL, arm_smmu_pm_resume)
+ SET_RUNTIME_PM_OPS(arm_smmu_runtime_suspend,
+ arm_smmu_runtime_resume, NULL)
+};
static struct platform_driver arm_smmu_driver = {
.driver = {
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Fri 19-01-18 09:39:03, Christian König wrote: > Am 19.01.2018 um 09:20 schrieb Michal Hocko: [...] > > OK, in that case I would propose a different approach. We already > > have rss_stat. So why do not we simply add a new counter there > > MM_KERNELPAGES and consider those in oom_badness? The rule would be > > that such a memory is bound to the process life time. I guess we will > > find more users for this later. > > I already tried that and the problem with that approach is that some buffers > are not created by the application which actually uses them. > > For example X/Wayland is creating and handing out render buffers to > application which want to use OpenGL. > > So the result is when you always account the application who created the > buffer the OOM killer will certainly reap X/Wayland first. And that is > exactly what we want to avoid here. Then you have to find the target allocation context at the time of the allocation and account it. As follow up emails show, implementations might differ and any robust oom solution have to rely on the common counters. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 5/6] iommu/arm-smmu: Add support for qcom,smmu-v2 variant
qcom,smmu-v2 is an arm,smmu-v2 implementation with specific
clock and power requirements. This smmu core is used with
multiple masters on msm8996, viz. mdss, video, etc.
Add bindings for the same.
Signed-off-by: Vivek Gautam
---
.../devicetree/bindings/iommu/arm,smmu.txt | 43 ++
drivers/iommu/arm-smmu.c | 13 +++
2 files changed, 56 insertions(+)
diff --git a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
index 8a6ffce12af5..169222ae2706 100644
--- a/Documentation/devicetree/bindings/iommu/arm,smmu.txt
+++ b/Documentation/devicetree/bindings/iommu/arm,smmu.txt
@@ -17,10 +17,19 @@ conditions.
"arm,mmu-401"
"arm,mmu-500"
"cavium,smmu-v2"
+"qcom,-smmu-v2", "qcom,smmu-v2"
depending on the particular implementation and/or the
version of the architecture implemented.
+ A number of Qcom SoCs use qcom,smmu-v2 version of the IP.
+ "qcom,-smmu-v2" represents a soc specific compatible
+ string that should be present along with the "qcom,smmu-v2"
+ to facilitate SoC specific clocks/power connections and to
+ address specific bug fixes.
+ An example string would be -
+ "qcom,msm8996-smmu-v2", "qcom,smmu-v2".
+
- reg : Base address and size of the SMMU.
- #global-interrupts : The number of global interrupts exposed by the
@@ -71,6 +80,23 @@ conditions.
or using stream matching with #iommu-cells = <2>, and
may be ignored if present in such cases.
+- clock-names:Should be "bus", and "iface" for "qcom,smmu-v2"
+ implementation.
+
+ "bus" clock for "qcom,smmu-v2" is required for downstream
+ bus access and for the smmu ptw.
+
+ "iface" clock is required to access smmu's registers through
+ the TCU's programming interface.
+
+- clocks: Phandles for respective clocks described by clock-names.
+
+- power-domains: Phandles to SMMU's power domain specifier. This is
+ required even if SMMU belongs to the master's power
+ domain, as the SMMU will have to be enabled and
+ accessed before master gets enabled and linked to its
+ SMMU.
+
** Deprecated properties:
- mmu-masters (deprecated in favour of the generic "iommus" binding) :
@@ -137,3 +163,20 @@ conditions.
iommu-map = <0 &smmu3 0 0x400>;
...
};
+
+ /* Qcom's arm,smmu-v2 implementation */
+ smmu4: iommu {
+ compatible = "qcom,msm8996-smmu-v2", "qcom,smmu-v2";
+ reg = <0xd0 0x1>;
+
+ #global-interrupts = <1>;
+ interrupts = ,
+,
+;
+ #iommu-cells = <1>;
+ power-domains = <&mmcc MDSS_GDSC>;
+
+ clocks = <&mmcc SMMU_MDP_AXI_CLK>,
+<&mmcc SMMU_MDP_AHB_CLK>;
+ clock-names = "bus", "iface";
+ };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 33bbcfedb896..2ade214c41bc 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -119,6 +119,7 @@ enum arm_smmu_implementation {
GENERIC_SMMU,
ARM_MMU500,
CAVIUM_SMMUV2,
+ QCOM_SMMUV2,
};
struct arm_smmu_s2cr {
@@ -1971,6 +1972,17 @@ struct arm_smmu_match_data {
ARM_SMMU_MATCH_DATA(arm_mmu500, ARM_SMMU_V2, ARM_MMU500);
ARM_SMMU_MATCH_DATA(cavium_smmuv2, ARM_SMMU_V2, CAVIUM_SMMUV2);
+static const char * const qcom_smmuv2_clks[] = {
+ "bus", "iface",
+};
+
+static const struct arm_smmu_match_data qcom_smmuv2 = {
+ .version = ARM_SMMU_V2,
+ .model = QCOM_SMMUV2,
+ .clks = qcom_smmuv2_clks,
+ .num_clks = ARRAY_SIZE(qcom_smmuv2_clks),
+};
+
static const struct of_device_id arm_smmu_of_match[] = {
{ .compatible = "arm,smmu-v1", .data = &smmu_generic_v1 },
{ .compatible = "arm,smmu-v2", .data = &smmu_generic_v2 },
@@ -1978,6 +1990,7 @@ struct arm_smmu_match_data {
{ .compatible = "arm,mmu-401", .data = &arm_mmu401 },
{ .compatible = "arm,mmu-500", .data = &arm_mmu500 },
{ .compatible = "cavium,smmu-v2", .data = &cavium_smmuv2 },
+ { .compatible = "qcom,smmu-v2", .data = &qcom_smmuv2 },
{ },
};
MODULE_DEVICE_TABLE(of, arm_smmu_of_match);
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: vga_switcheroo: MIS-using the DIS command on a muxless system
Thank you very very much. Sorry for the disturbance, to all. Enrico ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Fri 19-01-18 13:13:51, Michal Hocko wrote: > On Fri 19-01-18 12:37:51, Christian König wrote: > [...] > > The per file descriptor badness is/was just the much easier approach to > > solve the issue, because the drivers already knew which client is currently > > using which buffer objects. > > > > I of course agree that file descriptors can be shared between processes and > > are by themselves not killable. But at least for our graphics driven use > > case I don't see much of a problem killing all processes when a file > > descriptor is used by more than one at the same time. > > Ohh, I absolutely see why you have chosen this way for your particular > usecase. I am just arguing that this would rather be more generic to be > merged. If there is absolutely no other way around we can consider it > but right now I do not see that all other options have been considered > properly. Especially when the fd based approach is basically wrong for > almost anybody else. And more importantly. Iterating over _all_ fd which is what is your approach is based on AFAIU is not acceptable for the OOM path. Even though oom_badness is not a hot path we do not really want it to take a lot of time either. Even the current iteration over all processes is quite time consuming. Now you want to add the number of opened files and that might be quite many per process. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 6/6] drm/msm: iommu: Replace runtime calls with runtime suppliers
While handling the concerned iommu, there should not be a
need to power control the drm devices from iommu interface.
If these drm devices need to be powered around this time,
the respective drivers should take care of this.
Replace the pm_runtime_get/put_sync() with
pm_runtime_get/put_suppliers() calls, to power-up
the connected iommu through the device link interface.
In case the device link is not setup these get/put_suppliers()
calls will be a no-op, and the iommu driver should take care of
powering on its devices accordingly.
Signed-off-by: Vivek Gautam
---
drivers/gpu/drm/msm/msm_iommu.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_iommu.c b/drivers/gpu/drm/msm/msm_iommu.c
index b23d33622f37..1ab629bbee69 100644
--- a/drivers/gpu/drm/msm/msm_iommu.c
+++ b/drivers/gpu/drm/msm/msm_iommu.c
@@ -40,9 +40,9 @@ static int msm_iommu_attach(struct msm_mmu *mmu, const char *
const *names,
struct msm_iommu *iommu = to_msm_iommu(mmu);
int ret;
- pm_runtime_get_sync(mmu->dev);
+ pm_runtime_get_suppliers(mmu->dev);
ret = iommu_attach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
+ pm_runtime_put_suppliers(mmu->dev);
return ret;
}
@@ -52,9 +52,9 @@ static void msm_iommu_detach(struct msm_mmu *mmu, const char
* const *names,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
+ pm_runtime_get_suppliers(mmu->dev);
iommu_detach_device(iommu->domain, mmu->dev);
- pm_runtime_put_sync(mmu->dev);
+ pm_runtime_put_suppliers(mmu->dev);
}
static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
@@ -63,9 +63,9 @@ static int msm_iommu_map(struct msm_mmu *mmu, uint64_t iova,
struct msm_iommu *iommu = to_msm_iommu(mmu);
size_t ret;
-// pm_runtime_get_sync(mmu->dev);
+ pm_runtime_get_suppliers(mmu->dev);
ret = iommu_map_sg(iommu->domain, iova, sgt->sgl, sgt->nents, prot);
-// pm_runtime_put_sync(mmu->dev);
+ pm_runtime_put_suppliers(mmu->dev);
WARN_ON(ret < 0);
return (ret == len) ? 0 : -EINVAL;
@@ -76,9 +76,9 @@ static int msm_iommu_unmap(struct msm_mmu *mmu, uint64_t iova,
{
struct msm_iommu *iommu = to_msm_iommu(mmu);
- pm_runtime_get_sync(mmu->dev);
+ pm_runtime_get_suppliers(mmu->dev);
iommu_unmap(iommu->domain, iova, len);
- pm_runtime_put_sync(mmu->dev);
+ pm_runtime_put_suppliers(mmu->dev);
return 0;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 1/6] base: power: runtime: Export pm_runtime_get/put_suppliers
The device link allows the pm framework to tie the supplier and
consumer. So, whenever the consumer is powered-on the supplier
is powered-on first.
There are however cases in which the consumer wants to power-on
the supplier, but not itself.
E.g., A Graphics or multimedia driver wants to power-on the SMMU
to unmap a buffer and finish the TLB operations without powering
on itself. Some of these unmap requests are coming from the
user space when the controller itself is not powered-up, and it
can be huge penalty in terms of power and latency to power-up
the graphics/mm controllers.
There can be an argument that the supplier should handle this case
on its own and there should not be a need for the consumer to
power-on the supplier. But as discussed on the thread [1] about
ARM-SMMU runtime pm, we don't want to introduce runtime pm calls
in atomic path in arm_smmu_unmap.
[1] https://patchwork.kernel.org/patch/9827825/
Signed-off-by: Vivek Gautam
Acked-by: Rafael J. Wysocki
---
drivers/base/power/runtime.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/base/power/runtime.c b/drivers/base/power/runtime.c
index 6e89b51ea3d9..06a2a88fe866 100644
--- a/drivers/base/power/runtime.c
+++ b/drivers/base/power/runtime.c
@@ -1579,6 +1579,7 @@ void pm_runtime_get_suppliers(struct device *dev)
device_links_read_unlock(idx);
}
+EXPORT_SYMBOL_GPL(pm_runtime_get_suppliers);
/**
* pm_runtime_put_suppliers - Drop references to supplier devices.
@@ -1597,6 +1598,7 @@ void pm_runtime_put_suppliers(struct device *dev)
device_links_read_unlock(idx);
}
+EXPORT_SYMBOL_GPL(pm_runtime_put_suppliers);
void pm_runtime_new_link(struct device *dev)
{
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On Fri 19-01-18 12:37:51, Christian König wrote: [...] > The per file descriptor badness is/was just the much easier approach to > solve the issue, because the drivers already knew which client is currently > using which buffer objects. > > I of course agree that file descriptors can be shared between processes and > are by themselves not killable. But at least for our graphics driven use > case I don't see much of a problem killing all processes when a file > descriptor is used by more than one at the same time. Ohh, I absolutely see why you have chosen this way for your particular usecase. I am just arguing that this would rather be more generic to be merged. If there is absolutely no other way around we can consider it but right now I do not see that all other options have been considered properly. Especially when the fd based approach is basically wrong for almost anybody else. -- Michal Hocko SUSE Labs ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 0/6] iommu/arm-smmu: Add runtime pm/sleep support
This series provides the support for turning on the arm-smmu's
clocks/power domains using runtime pm. This is done using the
recently introduced device links patches, which lets the smmu's
runtime to follow the master's runtime pm, so the smmu remains
powered only when the masters use it.
It also adds support for Qcom's arm-smmu-v2 variant that
has different clocks and power requirements.
Took some reference from the exynos runtime patches [1].
After much discussion [3] over the use of pm_runtime_get/put() in
.unmap op path for the arm-smmu, and after disussing over more than
a couple of approaches to address this, we are putting forward the
changes *without* using pm_runtime APIs in 'unmap'. Rather, letting
the client device take the control of powering on/off the connected
iommu through pm_runtime_get(put)_suppliers() APIs for the scnerios
when the iommu power can't be directly controlled by clients through
device links.
Rafael has agreed to export the suppliers APIs [4].
Hi Robin, Will,
please consider reviewing this series.
[V6]
* Added Ack given by Rafael to first patch in the series.
* Addressed Rob Herring's comment for adding soc specific compatible
string as well besides 'qcom,smmu-v2'.
[V5]
* Dropped runtime pm calls from "arm_smmu_unmap" op as discussed over
the list [3] for the last patch series.
* Added a patch to export pm_runtime_get/put_suppliers() APIs to the
series as agreed with Rafael [4].
* Added the related patch for msm drm iommu layer to use
pm_runtime_get/put_suppliers() APIs in msm_mmu_funcs.
* Dropped arm-mmu500 clock patch since that would break existing
platforms.
* Changed compatible 'qcom,msm8996-smmu-v2' to 'qcom,smmu-v2' to reflect
the IP version rather than the platform on which it is used.
The same IP is used across multiple platforms including msm8996,
and sdm845 etc.
* Using clock bulk APIs to handle the clocks available to the IP as
suggested by Stephen Boyd.
* The first patch in v4 version of the patch-series:
("iommu/arm-smmu: Fix the error path in arm_smmu_add_device") has
already made it to mainline.
[V4]
* Reworked the clock handling part. We now take clock names as data
in the driver for supported compatible versions, and loop over them
to get, enable, and disable the clocks.
* Using qcom,msm8996 based compatibles for bindings instead of a generic
qcom compatible.
* Refactor MMU500 patch to just add the necessary clock names data and
corresponding bindings.
* Added the pm_runtime_get/put() calls in .unmap iommu op (fix added by
Stanimir on top of previous patch version.
* Added a patch to fix error path in arm_smmu_add_device()
* Removed patch 3/5 of V3 patch series that added qcom,smmu-v2 bindings.
[V3]
* Reworked the patches to keep the clocks init/enabling function
separately for each compatible.
* Added clocks bindings for MMU40x/500.
* Added a new compatible for qcom,smmu-v2 implementation and
the clock bindings for the same.
* Rebased on top of 4.11-rc1
[V2]
* Split the patches little differently.
* Addressed comments.
* Removed the patch #4 [2] from previous post
for arm-smmu context save restore. Planning to
post this separately after reworking/addressing Robin's
feedback.
* Reversed the sequence to disable clocks than enabling.
This was required for those cases where the
clocks are populated in a dependent order from DT.
[1] https://lkml.org/lkml/2016/10/20/70
[2] https://patchwork.kernel.org/patch/9389717/
[3] https://patchwork.kernel.org/patch/9827825/
[4] https://patchwork.kernel.org/patch/10102445/
Sricharan R (3):
iommu/arm-smmu: Add pm_runtime/sleep ops
iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
iommu/arm-smmu: Add the device_link between masters and smmu
Vivek Gautam (3):
base: power: runtime: Export pm_runtime_get/put_suppliers
iommu/arm-smmu: Add support for qcom,smmu-v2 variant
drm/msm: iommu: Replace runtime calls with runtime suppliers
.../devicetree/bindings/iommu/arm,smmu.txt | 43 +++
drivers/base/power/runtime.c | 2 +
drivers/gpu/drm/msm/msm_iommu.c| 16 +--
drivers/iommu/arm-smmu.c | 124 -
4 files changed, 171 insertions(+), 14 deletions(-)
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 3/6] iommu/arm-smmu: Invoke pm_runtime during probe, add/remove device
From: Sricharan R
The smmu device probe/remove and add/remove master device callbacks
gets called when the smmu is not linked to its master, that is without
the context of the master device. So calling runtime apis in those places
separately.
Signed-off-by: Sricharan R
[vivek: Cleanup pm runtime calls]
Signed-off-by: Vivek Gautam
---
drivers/iommu/arm-smmu.c | 45 +
1 file changed, 41 insertions(+), 4 deletions(-)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 21acffe91a1c..95478bfb182c 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -914,11 +914,15 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
struct arm_smmu_domain *smmu_domain = to_smmu_domain(domain);
struct arm_smmu_device *smmu = smmu_domain->smmu;
struct arm_smmu_cfg *cfg = &smmu_domain->cfg;
- int irq;
+ int ret, irq;
if (!smmu || domain->type == IOMMU_DOMAIN_IDENTITY)
return;
+ ret = pm_runtime_get_sync(smmu->dev);
+ if (ret)
+ return;
+
/*
* Disable the context bank and free the page tables before freeing
* it.
@@ -933,6 +937,8 @@ static void arm_smmu_destroy_domain_context(struct
iommu_domain *domain)
free_io_pgtable_ops(smmu_domain->pgtbl_ops);
__arm_smmu_free_bitmap(smmu->context_map, cfg->cbndx);
+
+ pm_runtime_put_sync(smmu->dev);
}
static struct iommu_domain *arm_smmu_domain_alloc(unsigned type)
@@ -1408,12 +1414,20 @@ static int arm_smmu_add_device(struct device *dev)
while (i--)
cfg->smendx[i] = INVALID_SMENDX;
- ret = arm_smmu_master_alloc_smes(dev);
+ ret = pm_runtime_get_sync(smmu->dev);
if (ret)
goto out_cfg_free;
+ ret = arm_smmu_master_alloc_smes(dev);
+ if (ret) {
+ pm_runtime_put_sync(smmu->dev);
+ goto out_cfg_free;
+ }
+
iommu_device_link(&smmu->iommu, dev);
+ pm_runtime_put_sync(smmu->dev);
+
return 0;
out_cfg_free:
@@ -1428,7 +1442,7 @@ static void arm_smmu_remove_device(struct device *dev)
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
struct arm_smmu_master_cfg *cfg;
struct arm_smmu_device *smmu;
-
+ int ret;
if (!fwspec || fwspec->ops != &arm_smmu_ops)
return;
@@ -1436,8 +1450,21 @@ static void arm_smmu_remove_device(struct device *dev)
cfg = fwspec->iommu_priv;
smmu = cfg->smmu;
+ /*
+* The device link between the master device and
+* smmu is already purged at this point.
+* So enable the power to smmu explicitly.
+*/
+
+ ret = pm_runtime_get_sync(smmu->dev);
+ if (ret)
+ return;
+
iommu_device_unlink(&smmu->iommu, dev);
arm_smmu_master_free_smes(fwspec);
+
+ pm_runtime_put_sync(smmu->dev);
+
iommu_group_remove_device(dev);
kfree(fwspec->iommu_priv);
iommu_fwspec_free(dev);
@@ -2130,6 +2157,14 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
if (err)
return err;
+ platform_set_drvdata(pdev, smmu);
+
+ pm_runtime_enable(dev);
+
+ err = pm_runtime_get_sync(dev);
+ if (err)
+ return err;
+
err = arm_smmu_device_cfg_probe(smmu);
if (err)
return err;
@@ -2171,9 +2206,9 @@ static int arm_smmu_device_probe(struct platform_device
*pdev)
return err;
}
- platform_set_drvdata(pdev, smmu);
arm_smmu_device_reset(smmu);
arm_smmu_test_smr_masks(smmu);
+ pm_runtime_put_sync(dev);
/*
* For ACPI and generic DT bindings, an SMMU will be probed before
@@ -2212,6 +2247,8 @@ static int arm_smmu_device_remove(struct platform_device
*pdev)
/* Turn the thing off */
writel(sCR0_CLIENTPD, ARM_SMMU_GR0_NS(smmu) + ARM_SMMU_GR0_sCR0);
+ pm_runtime_force_suspend(smmu->dev);
+
return 0;
}
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH v6 4/6] iommu/arm-smmu: Add the device_link between masters and smmu
From: Sricharan R
Finally add the device link between the master device and
smmu, so that the smmu gets runtime enabled/disabled only when the
master needs it. This is done from add_device callback which gets
called once when the master is added to the smmu.
Signed-off-by: Sricharan R
---
drivers/iommu/arm-smmu.c | 11 +++
1 file changed, 11 insertions(+)
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 95478bfb182c..33bbcfedb896 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1367,6 +1367,7 @@ static int arm_smmu_add_device(struct device *dev)
struct arm_smmu_device *smmu;
struct arm_smmu_master_cfg *cfg;
struct iommu_fwspec *fwspec = dev->iommu_fwspec;
+ struct device_link *link;
int i, ret;
if (using_legacy_binding) {
@@ -1428,6 +1429,16 @@ static int arm_smmu_add_device(struct device *dev)
pm_runtime_put_sync(smmu->dev);
+ /*
+* Establish the link between smmu and master, so that the
+* smmu gets runtime enabled/disabled as per the master's
+* needs.
+*/
+ link = device_link_add(dev, smmu->dev, DL_FLAG_PM_RUNTIME);
+ if (!link)
+ dev_warn(smmu->dev, "Unable to create device link between %s
and %s\n",
+dev_name(smmu->dev), dev_name(dev));
+
return 0;
out_cfg_free:
--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member
of Code Aurora Forum, hosted by The Linux Foundation
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104216] Firefox quirks (black and/or white squares)
https://bugs.freedesktop.org/show_bug.cgi?id=104216 --- Comment #11 from Germano Massullo --- Disabling Firefox hardware acceleration seems to work as bug workaround https://support.mozilla.org/en-US/kb/upgrade-graphics-drivers-use-hardware-acceleration#w_turning-off-hardware-acceleration -- 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 07/12] drm: arm: malidp: Use drm_atomic_helper_shutdown() to disable planes on removal
Hi Laurent,
On Wed, Jan 17, 2018 at 11:55:30PM +0200, Laurent Pinchart wrote:
> The plane cleanup handler currently calls drm_plane_helper_disable(),
> which is a legacy helper function. Replace it with a call to
> drm_atomic_helper_shutdown() at removal time.
>
> Signed-off-by: Laurent Pinchart
> ---
> drivers/gpu/drm/arm/malidp_drv.c| 1 +
> drivers/gpu/drm/arm/malidp_planes.c | 4
> 2 files changed, 1 insertion(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/arm/malidp_drv.c
> b/drivers/gpu/drm/arm/malidp_drv.c
> index 0711279e836f..5d037ea576c7 100644
> --- a/drivers/gpu/drm/arm/malidp_drv.c
> +++ b/drivers/gpu/drm/arm/malidp_drv.c
> @@ -276,6 +276,7 @@ static int malidp_init(struct drm_device *drm)
>
> static void malidp_fini(struct drm_device *drm)
> {
> + drm_atomic_helper_shutdown(drm);
> drm_mode_config_cleanup(drm);
> }
>
> diff --git a/drivers/gpu/drm/arm/malidp_planes.c
> b/drivers/gpu/drm/arm/malidp_planes.c
> index d883d28d5d9d..2bc1264ec73a 100644
> --- a/drivers/gpu/drm/arm/malidp_planes.c
> +++ b/drivers/gpu/drm/arm/malidp_planes.c
> @@ -56,10 +56,6 @@ static void malidp_de_plane_destroy(struct drm_plane
> *plane)
> {
> struct malidp_plane *mp = to_malidp_plane(plane);
>
> - if (mp->base.fb)
> - drm_framebuffer_put(mp->base.fb);
> -
> - drm_plane_helper_disable(plane);
> drm_plane_cleanup(plane);
> kfree(mp);
> }
With this change in place I'm getting
[drm:drm_atomic_helper_shutdown [drm_kms_helper]] *ERROR* Disabling all crtc's
during unload failed with -22
when trying to remove the mali-dp module.
Echoing 0x3f into /sys/module/drm/parameters/debug I get this:
[ 332.072080] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4386, diff=1, hw=0 hw_last=0
[ 332.091326] [drm:drm_sysfs_connector_remove [drm]] removing "HDMI-A-1" from
sysfs
[ 332.101255] Console: switching to colour dummy device 80x25
[ 332.105506] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4387, diff=1, hw=0 hw_last=0
[ 332.117772] [drm:drm_atomic_state_init [drm]] Allocated atomic state
35c85576
[ 332.125710] [drm:drm_mode_object_get [drm]] OBJ ID: 62 (3)
[ 332.131302] [drm:drm_atomic_get_plane_state [drm]] Added [PLANE:28:plane-0]
2713c919 state to 35c85576
[ 332.139069] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4388, diff=1, hw=0 hw_last=0
[ 332.152827] [drm:drm_mode_object_get [drm]] OBJ ID: 45 (1)
[ 332.158558] [drm:drm_atomic_get_crtc_state [drm]] Added [CRTC:35:crtc-0]
da10cba0 state to 35c85576
[ 332.169169] [drm:drm_atomic_set_fb_for_plane [drm]] Set [NOFB] for plane
state 2713c919
[ 332.178051] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4389, diff=1, hw=0 hw_last=0
[ 332.188836] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 62 (4)
[ 332.195145] [drm:drm_atomic_set_crtc_for_plane [drm]] Link plane state
2713c919 to [NOCRTC]
[ 332.204373] [drm:drm_atomic_check_only [drm]] checking 35c85576
[ 332.211182] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4390, diff=1, hw=0 hw_last=0
[ 332.221968] [drm:drm_atomic_commit [drm]] committing 35c85576
[ 332.228617] [drm:drm_calc_timestamping_constants [drm]] crtc 35: hwmode:
htotal 2200, vtotal 562, vdisplay 540
[ 332.238787] [drm:drm_calc_timestamping_constants [drm]] crtc 35: clock 74250
kHz framedur 8325925 linedur 29629
[ 332.249039] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4391, diff=1, hw=0 hw_last=0
[ 332.272706] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4392, diff=1, hw=0 hw_last=0
[ 332.306160] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4393, diff=1, hw=0 hw_last=0
[ 332.317030] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 62 (3)
[ 332.323327] [drm:drm_atomic_state_default_clear [drm]] Clearing atomic state
35c85576
[ 332.332041] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 45 (2)
[ 332.338331] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 62 (2)
[ 332.339680] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4394, diff=1, hw=0 hw_last=0
[ 332.355181] [drm:__drm_atomic_state_free [drm]] Freeing atomic state
35c85576
[ 332.363204] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 62 (1)
[ 332.373126] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4395, diff=1, hw=0 hw_last=0
[ 332.395308] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 37 (4)
[ 332.401599] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 37 (3)
[ 332.406566] [drm:drm_update_vblank_count [drm]] updating vblank count on
crtc 0: current=4396, diff=1, hw=0 hw_last=0
[ 332.418489] [drm:drm_mode_object_put.part.0 [drm]] OBJ ID: 0 (2)
[ 332.432903] [drm:drm_atomic_state_in
[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.
https://bugs.freedesktop.org/show_bug.cgi?id=104412 --- Comment #10 from S.H. --- (In reply to Peter Weber from comment #8) > Hello! > > I'm using a LG 27UD88-W, which featurese 1 x DP, 1 x USB-C (DP) and 2 x > HDMI. In my desktop is a Radeon RX 560 which offers DP "1.4" and HDMI "2.0b" > and I also use a ThinkPad X220 which offers DP "1.1". > > USB-C -> No hardware available > DP-> Reserved for ThinkPad, so I can use 3480x2180@30 Hz (probably even > 44 Hz [1]) > HDMI -> RX 560 > > The DP of the RX 560 works fine at 3480x2180@60Hz, but via HDMI it fails > with Fedora 27 and kernel "3.14". Only 1920x1***@30Hz is possible any higher > resolution results in visual garbage on the screen or "NO SIGNAL". Finally I > remembered, that kernel 3.15 will over the new graphics stack "AMDGPU DC". I > booted a live ISO with kernel 3.15 and passed the requried option > "amdgpu.dc=1" and got 3480x2180@30Hz. GNOME also offers 60Hz as option, but > that fails and cannot be used, screen goes blank, until GNOME reverts the > settings. I'm afraid the previous people are right, HDMI2.0b and 4K@60Hz are > broken. > > > > > HINT: Don't used "DEEP COLOR" (LG OPTION for 8/10BIT COLOR?) with HDMI or > everything is busted, but that is a minor issue, as for now. > > > > > > > > > > > > > > > [1] > https://medium.com/@ValdikSS/how-to-use-high-resolutions-with-older-hardware- > 58577d91b1f8 You need at least Kernel-4.15 which is in rc-state at the moment. Afaik, Kernel 3.14 is way too old for amdgpu and amdgpu-dc. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
On 2018-01-19 12:37 PM, Christian König wrote: > Am 19.01.2018 um 11:40 schrieb Michal Hocko: >> On Fri 19-01-18 09:39:03, Christian König wrote: >>> Am 19.01.2018 um 09:20 schrieb Michal Hocko: >> [...] OK, in that case I would propose a different approach. We already have rss_stat. So why do not we simply add a new counter there MM_KERNELPAGES and consider those in oom_badness? The rule would be that such a memory is bound to the process life time. I guess we will find more users for this later. >>> I already tried that and the problem with that approach is that some >>> buffers >>> are not created by the application which actually uses them. >>> >>> For example X/Wayland is creating and handing out render buffers to >>> application which want to use OpenGL. >>> >>> So the result is when you always account the application who created the >>> buffer the OOM killer will certainly reap X/Wayland first. And that is >>> exactly what we want to avoid here. >> Then you have to find the target allocation context at the time of the >> allocation and account it. > > And exactly that's the root of the problem: The target allocation > context isn't known at the time of the allocation. > > We could add callbacks so that when the memory is passed from the > allocator to the actual user of the memory. In other words when the > memory is passed from the X server to the client the driver would need > to decrement the X servers accounting and increment the clients accounting. > > But I think that would go deep into the file descriptor handling (we > would at least need to handle dup/dup2 and passing the fd using unix > domain sockets) and most likely would be rather error prone. > > The per file descriptor badness is/was just the much easier approach to > solve the issue, because the drivers already knew which client is > currently using which buffer objects. > > I of course agree that file descriptors can be shared between processes > and are by themselves not killable. But at least for our graphics driven > use case I don't see much of a problem killing all processes when a file > descriptor is used by more than one at the same time. In that case, accounting a BO as suggested by Michal above, in every process that shares it, should work fine, shouldn't it? The OOM killer will first select the process which has more memory accounted for other things than the BOs shared with another process. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [RFC] Per file OOM badness
Am 19.01.2018 um 13:20 schrieb Michal Hocko: On Fri 19-01-18 13:13:51, Michal Hocko wrote: On Fri 19-01-18 12:37:51, Christian König wrote: [...] The per file descriptor badness is/was just the much easier approach to solve the issue, because the drivers already knew which client is currently using which buffer objects. I of course agree that file descriptors can be shared between processes and are by themselves not killable. But at least for our graphics driven use case I don't see much of a problem killing all processes when a file descriptor is used by more than one at the same time. Ohh, I absolutely see why you have chosen this way for your particular usecase. I am just arguing that this would rather be more generic to be merged. If there is absolutely no other way around we can consider it but right now I do not see that all other options have been considered properly. Especially when the fd based approach is basically wrong for almost anybody else. And more importantly. Iterating over _all_ fd which is what is your approach is based on AFAIU is not acceptable for the OOM path. Even though oom_badness is not a hot path we do not really want it to take a lot of time either. Even the current iteration over all processes is quite time consuming. Now you want to add the number of opened files and that might be quite many per process. Mhm, crap that is a really good argument. How about adding a linked list of callbacks to check for the OOM killer to check for each process? This way we can avoid finding the process where we need to account things on when memory is allocated and still allow the OOM killer to only check the specific callbacks it needs to determine the score of a process? Would still require some changes in the fs layer, but I think that should be doable. Regards, Christian. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 104001] GPU driver hung when start steam client while playback video on Youtube (it occurs on latest staging kernel)
https://bugs.freedesktop.org/show_bug.cgi?id=104001 --- Comment #19 from mikhail.v.gavri...@gmail.com --- I am sorry for misunderstanding. Every time when I see new commits in branch I hope that this issue may be fixed. And every time I rebuild kernel for testing. And after it I every time I reproduce this annoying bug. And I still hope that anybody works on it and improve logging for understanding root cause of this hung. So I every time attach new dmesg 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
[PATCH 0/3] Add R-Car V3M (R8A77970) support to the R-Car LVDS driver
Hello! Here's the set of 3 patches against the 'drm-next' branch of David Airlie's 'linux.git' repo plus the patch fixing LVDS startup for R-Car gen2/3 and Laurent Picnahrt's patches creating the R-Car LVDS bridge driver posted recently. The main purpose of these patches is to add the R-Car V3M (R8A77970) support to the R-Car LVDS driver -- we have to do some refactoring first to achieve this goal... [1/3] drm: rcar-du: lvds: refactor LVDS startup [2/3] DT: display: renesas,lvds: document R8A77970 bindings [3/3] drm: rcar-du: lvds: add R8A77970 support MBR, Sergei ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH 1/3] drm: rcar-du: lvds: refactor LVDS startup
After the recent corrections to the R-Car gen2/3 LVDS startup code, already
similar enough at their ends rcar_lvds_enable_gen{2|3}() started asking for
a merge and it's becoming actually necessary with the addition of the R-Car
V3M (R8A77970) support -- this gen3 SoC has gen2-like LVDPLLCR layout.
BTW, such a merge saves 64 bytes of the object code with AArch64 gcc 4.8.5.
Signed-off-by: Sergei Shtylyov
---
drivers/gpu/drm/rcar-du/rcar_lvds.c | 137 +++-
1 file changed, 59 insertions(+), 78 deletions(-)
Index: linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
===
--- linux.orig/drivers/gpu/drm/rcar-du/rcar_lvds.c
+++ linux/drivers/gpu/drm/rcar-du/rcar_lvds.c
@@ -125,98 +125,46 @@ static const struct drm_connector_funcs
* Bridge
*/
-static void rcar_lvds_enable_gen2(struct rcar_lvds *lvds)
+static u32 rcar_lvds_lvdpllcr_gen2(unsigned int freq)
{
- const struct drm_display_mode *mode = &lvds->display_mode;
- /*
-* FIXME: We should really retrieve this through the state, but how do
-* we get a state pointer?
-*/
- struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
- unsigned int freq = mode->clock;
- u32 lvdcr0;
- u32 pllcr;
+ u32 lvdpllcr;
- /* PLL clock configuration */
if (freq < 39000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_38M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_38M;
else if (freq < 61000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL | LVDPLLCR_PLLDLYCNT_60M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_60M;
else if (freq < 121000)
- pllcr = LVDPLLCR_CEEN | LVDPLLCR_COSEL |
LVDPLLCR_PLLDLYCNT_121M;
+ lvdpllcr = LVDPLLCR_PLLDLYCNT_121M;
else
- pllcr = LVDPLLCR_PLLDLYCNT_150M;
-
- rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
- /* Turn all the channels on. */
- rcar_lvds_write(lvds, LVDCR1, LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
- LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
-
- /*
-* Set the LVDS mode, select the input, enable LVDS operation,
-* and turn bias circuitry on.
-*/
- lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_BEN | LVDCR0_LVEN;
- if (drm_crtc_index(crtc) == 2)
- lvdcr0 |= LVDCR0_DUSEL;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- /*
-* Turn the PLL on, wait for the startup delay, and turn the output
-* on.
-*/
- lvdcr0 |= LVDCR0_PLLON;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return LVDPLLCR_PLLDLYCNT_150M;
- usleep_range(100, 150);
-
- lvdcr0 |= LVDCR0_LVRES;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return lvdpllcr | LVDPLLCR_CEEN | LVDPLLCR_COSEL;
}
-static void rcar_lvds_enable_gen3(struct rcar_lvds *lvds)
+static u32 rcar_lvds_lvdpllcr_gen3(unsigned int freq)
{
- const struct drm_display_mode *mode = &lvds->display_mode;
- unsigned int freq = mode->clock;
- u32 lvdcr0;
- u32 pllcr;
-
- /* PLL clock configuration */
if (freq < 42000)
- pllcr = LVDPLLCR_PLLDIVCNT_42M;
+ return LVDPLLCR_PLLDIVCNT_42M;
else if (freq < 85000)
- pllcr = LVDPLLCR_PLLDIVCNT_85M;
+ return LVDPLLCR_PLLDIVCNT_85M;
else if (freq < 128000)
- pllcr = LVDPLLCR_PLLDIVCNT_128M;
- else
- pllcr = LVDPLLCR_PLLDIVCNT_148M;
-
- rcar_lvds_write(lvds, LVDPLLCR, pllcr);
-
- /* Turn all the channels on. */
- rcar_lvds_write(lvds, LVDCR1, LVDCR1_CHSTBY(3) | LVDCR1_CHSTBY(2) |
- LVDCR1_CHSTBY(1) | LVDCR1_CHSTBY(0) | LVDCR1_CLKSTBY);
+ return LVDPLLCR_PLLDIVCNT_128M;
- /*
-* Turn the PLL on, set it to LVDS normal mode, wait for the startup
-* delay and turn the output on.
-*/
- lvdcr0 = (lvds->mode << LVDCR0_LVMD_SHIFT) | LVDCR0_PLLON;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- lvdcr0 |= LVDCR0_PWD;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
-
- usleep_range(100, 150);
-
- lvdcr0 |= LVDCR0_LVRES;
- rcar_lvds_write(lvds, LVDCR0, lvdcr0);
+ return LVDPLLCR_PLLDIVCNT_148M;
}
static void rcar_lvds_enable(struct drm_bridge *bridge)
{
struct rcar_lvds *lvds = bridge_to_rcar_lvds(bridge);
+ /*
+* FIXME: We should really retrieve this through the state, but how do
+* we get a state pointer?
+*/
+ struct drm_crtc *crtc = lvds->bridge.encoder->crtc;
+ const struct drm_display_mode *mode = &lvds->display_mode;
+ unsigned int gen = lvds->info->gen;
+ u32 lvdcr0 = lvds->mode << LVDCR0_LVMD_SHIFT;
+ u32 lvdpllcr;
u32 lvdhcr;
int ret;
@@ -244,14 +192,47 @@ static void rcar_lvds_en
[PATCH 2/3] DT: display: renesas,lvds: document R8A77970 bindings
Document the R-Car V3M (R8A77970) SoC in the R-Car LVDS bindings. Signed-off-by: Sergei Shtylyov --- Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt |1 + 1 file changed, 1 insertion(+) Index: linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt === --- linux.orig/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt +++ linux/Documentation/devicetree/bindings/display/bridge/renesas,lvds.txt @@ -13,6 +13,7 @@ Required properties: - "renesas,r8a7793-lvds" for R8A7791 (R-Car M2-N) compatible LVDS encoders - "renesas,r8a7795-lvds" for R8A7795 (R-Car H3) compatible LVDS encoders - "renesas,r8a7796-lvds" for R8A7796 (R-Car M3-W) compatible LVDS encoders + - "renesas,r8a77970-lvds" for R8A77970 (R-Car V3M) compatible LVDS encoders - reg: Base address and length for the memory-mapped registers - clocks: A phandle + clock-specifier pair for the functional clock ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
