Thanks. I tried 5.9.1 and I think there's still a problem, or at least
something different.
Using the same configuration script, I noticed that my cards are running a lot
hotter. For example, here's total power consumption of a two-card system with
two different kernels:
5.8.14: 460W
From: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 128 +++-
drivers/gpu/drm/nouveau/nouveau_bo.c| 106 ++--
drivers/gpu/drm/radeon/radeon_ttm.c | 110 ++--
drivers/gpu/drm/ttm/ttm_bo.c| 44 +++-
4 files
This is an RFC for a hacky idea I had to at least move the converation forward.
The branch with this in it is:
https://github.com/airlied/linux/tree/ttm-bounce
it won't apply to any other tree as it's based on all those patches I posted
and some other refactorings.
The basic idea is if the
On Tue, 20 Oct 2020 at 08:23, Dave Airlie wrote:
>
> From: Dave Airlie
>
> This is stored in the mem field, everywhere that a new mem is
> created, the bo->mem is either copied or this field is copied
> explicitly.
This has a problem with the pipeline gutting path, since it memset
(bo->mem to
On 2020-10-19 3:49 a.m., Pekka Paalanen wrote:
On Fri, 16 Oct 2020 16:50:16 +0300
Ville Syrjälä wrote:
On Mon, Oct 12, 2020 at 10:11:01AM +0300, Pekka Paalanen wrote:
On Fri, 9 Oct 2020 17:20:18 +0300
Ville Syrjälä wrote:
On Fri, Oct 09, 2020 at 04:56:51PM +0300, Pekka Paalanen wrote:
From: Dave Airlie
This just gives the driver control over some of the bind paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 7 ++-
drivers/gpu/drm/nouveau/nouveau_bo.c| 10 +++---
drivers/gpu/drm/radeon/radeon_ttm.c | 11 ---
From: Dave Airlie
This moves the to system move into the drivers, and moves all
the unbinds in the move path under driver control
Note: radeon/nouveau already wait so don't duplicate it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 12 +---
From: Dave Airlie
The drivers now do this in the move callback.
move_notify is still needed in the destroy path.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 13 +--
drivers/gpu/drm/drm_gem_vram_helper.c | 11 +-
From: Dave Airlie
This moves the call to tt binding into the driver move,
and drops the driver callback.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 7 ++-
drivers/gpu/drm/nouveau/nouveau_bo.c | 7 ++-
drivers/gpu/drm/qxl/qxl_ttm.c
From: Dave Airlie
resource free already sets the domain to system, and old_mem
isn't really needed.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
From: Dave Airlie
The drivers now control this, so drop unbinding.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 1 -
drivers/gpu/drm/nouveau/nouveau_bo.c | 1 -
drivers/gpu/drm/qxl/qxl_ttm.c | 7 ---
drivers/gpu/drm/radeon/radeon_ttm.c
From: Dave Airlie
This show the remaining bind callback, which my next series of
patches will aim to remove.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 16 +---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20
include/drm/ttm/ttm_bo_driver.h |
This series is a rebase/cleanup of previous patches.
The goal is to drop the bind/unbind callbacks from the ttm and
have the driver handle it all in it's move function.
This also has the driver do it's own move notifys from within
move as well (move notify is still used for cleanup_memtype_use0.
This fixes some range checks first.
Then drops bo->num_pages in favour of bo->mem.num_pages,
and drops bo->mem.size in favour of bo->mem.num_pages.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
From: Dave Airlie
This was adding size to start, but pfn and start are in pages,
so it should be using num_pages.
Not sure this fixes anything in the real world, just noticed it
during refactoring.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 +-
1 file changed, 1
From: Dave Airlie
We store size and num pages, wrap size so it can be removed.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 8
drivers/gpu/drm/amd/amdgpu/mes_v10_1.c | 2 +-
drivers/gpu/drm/nouveau/nouveau_bo.c | 8
From: Dave Airlie
This is stored in the mem field, everywhere that a new mem is
created, the bo->mem is either copied or this field is copied
explicitly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 4 ++--
drivers/gpu/drm/amd/amdgpu/amdgpu_gmc.c | 2 +-
From: Dave Airlie
start is in page units, so compare with pages.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index
From: Dave Airlie
Just use num_pages and a shift directly.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 2 +-
drivers/gpu/drm/nouveau/nv17_fence.c | 2 +-
drivers/gpu/drm/nouveau/nv50_fence.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo.c | 2 --
if (place->fpfn >= (bo->mem.start + bo->mem.size) ||
(place->lpfn && place->lpfn <= bo->mem.start))
return false;
Should the bo->mem.size there be bo->mem.num_pages?
I was just writing patches to get rid of size and noticed this.
Dave.
From: Rob Clark
Use a SCHED_FIFO kthread_worker for async atomic commits. We have a
hard deadline if we don't want to miss a frame.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_atomic.c | 25 -
drivers/gpu/drm/msm/msm_drv.h| 3 ++-
From: Rob Clark
Add msm_kms_destroy() and add err return from msm_kms_init(). Prep work
for next patch.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/dpu1/dpu_kms.c | 8 +++-
drivers/gpu/drm/msm/disp/mdp4/mdp4_kms.c | 8 +++-
drivers/gpu/drm/msm/disp/mdp5/mdp5_kms.c | 11
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 3 +--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 6 ++---
drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 4 +--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 4 +--
drivers/gpu/drm/msm/msm_gpu.c
From: Rob Clark
In particular, converting the async atomic commit (for cursor updates,
etc) to SCHED_FIFO kthread_worker helps with some cases where we
wouldn't manage to flush the updates within the 1ms-before-vblank
deadline resulting in fps drops when there is cursor movement.
Rob Clark (3):
From: Rob Clark
It cannot be atomically updated with obj->active_count, and the only
purpose is a useless WARN_ON() (which becomes a buggy WARN_ON() once
retire_submits() is not serialized with incoming submits via
struct_mutex)
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 2
From: Rob Clark
Now that the inactive_list is protected by mm_lock, and everything
else on per-obj basis is protected by obj->lock, we no longer depend
on struct_mutex.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 1 -
drivers/gpu/drm/msm/msm_gem_shrinker.c | 54
From: Rob Clark
If there is only a single ring (no-preemption), everything is FIFO order
and there is no need to implicit-sync.
Mesa should probably just always use MSM_SUBMIT_NO_IMPLICIT, as behavior
is undefined when fences are not used to synchronize buffer usage across
contexts (which is
From: Rob Clark
Now that active_list/inactive_list is protected by mm_lock, we no longer
need dev->struct_mutex in the free_object() path.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 8
1 file changed, 8 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
One less place to rely on dev->struct_mutex.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gem_submit.c | 2 ++
drivers/gpu/drm/msm/msm_gpu.c| 37 ++--
drivers/gpu/drm/msm/msm_ringbuffer.c | 1 +
From: Rob Clark
Before adding another lock, give ring->lock a more descriptive name.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 4 ++--
drivers/gpu/drm/msm/adreno/a5xx_preempt.c | 12 ++--
drivers/gpu/drm/msm/adreno/a6xx_gpu.c
From: Rob Clark
The obj->lock is sufficient for what we need.
This *does* have the implication that userspace can try to shoot
themselves in the foot by racing madvise(DONTNEED) with submit. But
the result will be about the same if they did madvise(DONTNEED) before
the submit ioctl, ie. they
From: Rob Clark
Small cleanup, update_fences() is used in the hangcheck path, but also
in the normal retire path.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 28 ++--
1 file changed, 14 insertions(+), 14 deletions(-)
diff
From: Rob Clark
Now that we are not relying on dev->struct_mutex to protect the
ring->submits lists, drop the struct_mutex lock.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git
From: Rob Clark
Now that we don't need struct_mutex in the free path, we can get rid of
the asynchronous free altogether.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_drv.c | 3 ---
drivers/gpu/drm/msm/msm_drv.h | 5 -
drivers/gpu/drm/msm/msm_gem.c | 27
From: Rob Clark
Before we remove dev->struct_mutex from the retire path, we have to deal
with the situation of a submit retiring before the submit ioctl returns.
To deal with this, ring->submits will hold a reference to the submit,
which is dropped when the submit is retired. And the submit
From: Rob Clark
Rather than relying on the big dev->struct_mutex hammer, introduce a
more specific lock for protecting the bo lists.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_debugfs.c | 7 +++
drivers/gpu/drm/msm/msm_drv.c | 7
From: Rob Clark
This will make it easier to transition over to obj->resv locking for
everything that is per-bo locking.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 99 ---
drivers/gpu/drm/msm/msm_gem.h | 28 ++
2 files changed, 74
From: Rob Clark
We'll need to introduce a _locked() version of msm_gem_get_iova(), so we
need to make that name available.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c
From: Rob Clark
It is somewhat redundant with the gpu tracepoints, and anyways not too
useful to justify spamming the log when debug traces are enabled.
Signed-off-by: Rob Clark
Reviewed-by: Jordan Crouse
---
drivers/gpu/drm/msm/msm_gpu.c | 1 -
1 file changed, 1 deletion(-)
diff --git
From: Rob Clark
This doesn't remove *all* the struct_mutex, but it covers the worst
of it, ie. shrinker/madvise/free/retire. The submit path still uses
struct_mutex, but it still needs *something* serialize a portion of
the submit path, and lock_stat mostly just shows the lock contention
there
From: Rob Clark
We cannot switch to using obj->resv for locking without first moving all
the copy_from_user() ahead of submit_lock_objects(). Otherwise in the
mm fault path we aquire mm->mmap_sem before obj lock, but in the submit
path the order is reversed.
Signed-off-by: Rob Clark
---
From: Rob Clark
We only want to use the _unlocked() variant in the unlocked case.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem.c b/drivers/gpu/drm/msm/msm_gem.c
index
From: Rob Clark
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/disp/mdp4/mdp4_crtc.c | 1 +
drivers/gpu/drm/msm/disp/mdp5/mdp5_crtc.c | 1 +
drivers/gpu/drm/msm/dsi/dsi_host.c| 1 +
drivers/gpu/drm/msm/msm_drv.h | 54 --
From: Rob Clark
This also converts the special msm_gem_get_vaddr_active() to expect the
lock to already be held. There are two call-sites for this, one already
has the lock held, so it is more straightforward to just open-code the
locking for the other caller.
Signed-off-by: Rob Clark
---
From: Rob Clark
Unfortunately, due to an dev_pm_opp locking interaction with
mm->mmap_sem, we need to do pm get before aquiring obj locks,
otherwise we can have anger lockdep with the chain:
opp_table_lock --> >mmap_sem --> reservation_ww_class_mutex
For an explicit fencing userspace, the
From: Rob Clark
When we cut-over to using dma_resv_lock/etc instead of msm_obj->lock,
we'll need these for the submit path (where resv->lock is already held).
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 89 +++
drivers/gpu/drm/msm/msm_gem.h |
From: Rob Clark
Move grabbing the bo lock into shrinker, with a msm_gem_trylock() to
skip over bo's that are already locked. This gets rid of the nested
lock classes.
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/msm_gem.c | 24 +
drivers/gpu/drm/msm/msm_gem.h
From: Rob Clark
The microcode bo's should never be madvise(WONTNEED), so these should
not be using msm_gem_get_vaddr_active().
Signed-off-by: Rob Clark
---
drivers/gpu/drm/msm/adreno/a5xx_gpu.c | 2 +-
drivers/gpu/drm/msm/adreno/a6xx_gpu.c | 2 +-
2 files changed, 2 insertions(+), 2
Hi Kevin.
On Mon, Oct 19, 2020 at 09:43:08PM +0200, Kevin Brace wrote:
> Hi Sam,
>
> Thanks for asking the question.
> The current OpenChrome DRM code has these two major issues.
>
> 1) It does not support atomic modesetting
>
> I do internally have working code to support atomic modesetting,
Hi Sam,
Thanks for asking the question.
The current OpenChrome DRM code has these two major issues.
1) It does not support atomic modesetting
I do internally have working code to support atomic modesetting, but it is not
ready for committing into the upstream OpenChrome DRM repository.
In
[Why] the func bios_parser_get_src_obj () is similar to
bios_parser_get_dst_obj () which is fixed by the
commit("drm/amd/display: Banch of smatch error and warning fixes
in DC").
the symbol 'id' is uninitialized and it is not checked before dereference
it,may lead to null pointer
07.10.2020 20:12, Mikko Perttunen пишет:
> +int tegra_drm_ioctl_channel_map(struct drm_device *drm, void *data,
> + struct drm_file *file)
> +{
Hello, Mikko!
Could you please tell what are the host1x clients that are going to be
upstreamed and will need this IOCTL?
19.10.2020 11:13, Mikko Perttunen пишет:
> On 10/19/20 5:21 AM, Dmitry Osipenko wrote:
>> 07.10.2020 20:12, Mikko Perttunen пишет:
>>> +int tegra_drm_ioctl_channel_map(struct drm_device *drm, void *data,
>>> + struct drm_file *file)
>>> +{
>>
>> Hello, Mikko!
>>
>> Could you please
Include in order to avoid following build failure
because of missing declaration of enable_kernel_vsx()
CC [M] drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.o
In file included from
./drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from
Hi Daniel,
On 2020/10/15 下午11:23, Daniel Vetter wrote:
On Wed, Oct 14, 2020 at 09:48:43AM +0800, Kever Yang wrote:
Hi Maintainers,
Does this patch ready to merge?
Would maybe be good to get some acks from other drivers using this, then
Sandy can push to drm-misc-next.
Thanks for your
kmemleak report:
unreferenced object 0x9071c65644e0 (size 96):
comm "systemd-udevd", pid 347, jiffies 4294898424 (age 810.828s)
hex dump (first 32 bytes):
02 01 00 00 00 00 00 00 00 00 10 00 02 04 00 00
00 00 00 00 00 00 a0 86 00 00 00 00 00 00 00 00
Hi Hoegeun,
On Mon, Oct 12, 2020 at 09:25:05PM +0900, Hoegeun Kwon wrote:
> Hi Maxime,
>
> On 10/8/20 8:25 PM, Maxime Ripard wrote:
> > The code that assigns HVS channels during atomic_check is starting to grow
> > a bit big, let's move it into a separate function.
> >
> > Signed-off-by: Maxime
On 2020-10-09 15:05, Rob Herring wrote:
> On Wed, Oct 07, 2020 at 05:49:14PM +, Caleb Connolly wrote:
>> Document the OnePlus 6/T common panel driver, example from
>> arch/arm64/boot/dts/qcom/sdm845-oneplus-common.dtsi
>>
>> Signed-off-by: Caleb Connolly
>> ---
>>
patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base: https://git.kernel.org/pub/scm/linux/kernel/git
The code has been in a irq-disabled context since it is hard IRQ. There
is no necessity to do it again.
Signed-off-by: Tian Tao
---
drivers/gpu/ipu-v3/ipu-image-convert.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/ipu-v3/ipu-image-convert.c
Hi Sam,
Thanks a lot for the feedback! I'll get those issues resolved for the
next revision.
Caleb
On 2020-10-18 14:35, Sam Ravnborg wrote:
> Hi Caleb.
>
> I have missed to provice review feedback so here goes.
> There is some improvements that can be made as the infrastructure has
> evolved
clk_prepare_enable() and clk_disable_unprepare() will check
NULL clock parameter, so It is not necessary to add additional checks.
Signed-off-by: Tian Tao
---
drivers/gpu/drm/msm/msm_gpu.c | 7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/msm/msm_gpu.c
Quoting Rodrigo Vivi (2020-10-19 19:29:36)
>
> I just checked the CI picture and it looks much better indeed.
>
> Only bad case being the gt_pm, which is also failing on other platforms.
Not nearly in the same manner. CI is indicating that there is no RC6
entry and no power saving at all;
I just checked the CI picture and it looks much better indeed.
Only bad case being the gt_pm, which is also failing on other platforms.
So,
Acked-by: Rodrigo Vivi
On Thu, Oct 15, 2020 at 08:41:32AM +, K, SrinivasX wrote:
> Hi Hariom,
>
> With Sunil's help was able to see EHL
On Thu, Oct 15, 2020 at 08:53:08AM +, Kamati Srinivas wrote:
> Removing force probe protection from JSL platform. Did
> not observe warnings, errors, flickering or any visual
> defects while doing ordinary tasks like browsing and
> editing documents in a two monitor setup.
I'm afraid we first
On Sun, Oct 18, 2020 at 4:32 PM Josh Fuhs wrote:
>
> Hello all,
>
> Regarding amdgpu, I've been using some Radeon 5700XTs for compute work with
> kernels through 5.8.14. I recently tried kernel 5.9.0, and found that the
> following is no longer allowed:
>
> echo "m 1 200" | sudo tee
Hi Tom
On Mon, Oct 19, 2020 at 09:31:15AM -0700, t...@redhat.com wrote:
> From: Tom Rix
>
> A break is not needed if it is preceded by a return or break
>
> Signed-off-by: Tom Rix
Looks good and builds with no warnings.
One of the diffs made me - "oh this looks wrong". But after I looked
Hi,
This series adds the DT bindings and a driver for DisplayPort connector.
I have previously sent v1 and v2 with only the bindings. The bindings
are unchanged, but I updated the patch description slightly for eDP and
DP++.
Tomi
Tomi Valkeinen (2):
dt-bindings: dp-connector: add binding
Add DP support to display-connector driver. The driver will support HPD
via a GPIO and DP PWR.
DP PWR will be enabled at probe, which is not optimal, but I'm not sure
what would be a good place to enable and disable DP PWR. Perhaps
attach/detach, but I don't know if enabling HW is something that
Add binding for DisplayPort connector. A few notes:
* Similar to hdmi-connector, it has hpd-gpios as an optional property,
as the HPD could also be handled by, e.g., the DP bridge.
* dp-pwr-supply, which provides 3.3V on DP_PWR pin, is optional, as it
is not strictly required: standard DP
Hi Kevin,
OpenChrome DDX was sending TTM_PL_FLAG_* based flags to OpenChrome DRM.
Ugh, that would be an absolute no-go for upstreaming.
Is it too much to ask for using more BUG_ON null pointer assertions for TTM
callbacks?
I don't think that this is useful at all. See a BUG_ON() has the
From: Tom Rix
A break is not needed if it is preceded by a return or break
Signed-off-by: Tom Rix
---
drivers/gpu/drm/mgag200/mgag200_mode.c | 5 -
drivers/gpu/drm/nouveau/nvkm/subdev/bios/pll.c | 1 -
drivers/gpu/drm/nouveau/nvkm/subdev/clk/mcp77.c | 3 ---
Hi Christian,
I looked into a few more things, and figured out why OpenChrome DRM was not
booting X Server.
Now the situation is under control in my side of the world (OpenChrome
development world), and I got X Server working again with drm-next 5.10 code
and OpenChrome DRM.
Code will be
Hi Nikhil,
On 16/10/2020 13:39, Nikhil Devshatwar wrote:
> This series moves the tidss to using new connectoe model, where the
> SoC driver (tidss) creates the connector and all the bridges are
> attached with the flag DRM_BRIDGE_ATTACH_NO_CONNECTOR
>
> Since the bridges do not create the
On Sun, Oct 18, 2020 at 04:54:01PM -0400, Peilin Ye wrote:
> Recently we added a new 6x8 font in commit e2028c8e6bf9 ("lib/fonts: add
> font 6x8 for OLED display"). Add its name to the "compiled-in fonts"
> list.
>
> Signed-off-by: Peilin Ye
> ---
> Resending +Cc: dri-devel, sorry if I spammed.
On Fri, Oct 16, 2020 at 07:46:41PM +0800, Shawn Guo wrote:
> On Fri, Oct 16, 2020 at 11:30:04AM +0200, Daniel Vetter wrote:
> > On Fri, Oct 16, 2020 at 10:54 AM Shawn Guo wrote:
> > >
> > > On Fri, Oct 16, 2020 at 09:58:46AM +0200, Daniel Vetter wrote:
> > > > On Fri, Oct 16, 2020 at 9:13 AM
On Mon, Oct 19, 2020 at 11:45:05AM +0200, Christian König wrote:
> Hi Thomas,
>
> [SNIP]
> > > > +int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map
> > > > *map)
> > > > +{
> > > > + struct ttm_resource *mem = >mem;
> > > > + int ret;
> > > > +
> > > > + ret =
On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> Hi Guido.
>
> On Sat, Oct 17, 2020 at 11:13:07AM +0200, Guido Günther wrote:
> > Hi Sam,
> > On Fri, Oct 16, 2020 at 04:29:16PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > > On Tue, Oct 13, 2020 at 12:32:45PM +0200, Guido Günther
On 2020-10-19 10:55 a.m., Christian König wrote:
Am 19.10.20 um 16:43 schrieb t...@redhat.com:
From: Tom Rix
A break is not needed if it is preceded by a return or break
Signed-off-by: Tom Rix
Acked-by: Christian König
Reviewed-by: Harry Wentland
Harry
---
On Mon, Oct 19, 2020 at 06:49:18PM +0530, Akhil P Oommen wrote:
> On targets with a6xx gpu, there is a duplicate gpu icc node listed in
> the interconnect summary. On these targets, calling
This first sentence is confusing to me. I think the following few sentences do
a better job of explaining
Am 19.10.20 um 16:43 schrieb t...@redhat.com:
From: Tom Rix
A break is not needed if it is preceded by a return or break
Signed-off-by: Tom Rix
Acked-by: Christian König
---
drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 1 -
On Mon, Oct 19, 2020 at 02:04:22PM +0800, Tian Tao wrote:
> clk_prepare_enable() and clk_disable_unprepare() will check
> NULL clock parameter, so It is not necessary to add additional checks.
Reviewed-by: Jordan Crouse
> Signed-off-by: Tian Tao
> ---
> drivers/gpu/drm/msm/msm_gpu.c | 7
From: Tom Rix
A break is not needed if it is preceded by a return or break
Signed-off-by: Tom Rix
---
drivers/gpu/drm/amd/display/dc/dce/dce_transform.c | 1 -
drivers/gpu/drm/amd/display/dc/dce100/dce100_resource.c | 7 ---
drivers/gpu/drm/amd/display/dc/dce110/dce110_resource.c | 7
Hi,
On Sun, Oct 18, 2020 at 03:38:45PM +0200, Sam Ravnborg wrote:
> Hi Guido
> > On Sun, Oct 18, 2020 at 03:01:22PM +0200, Guido Günther wrote:
> > Hi Sam,
> > On Sat, Oct 17, 2020 at 12:47:36PM +0200, Sam Ravnborg wrote:
> > > Hi Guido.
> > >
> > > On Sat, Oct 17, 2020 at 11:13:07AM +0200,
://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7cf726a59435301046250c42131554d9ccc566b8
On targets with a6xx gpu, there is a duplicate gpu icc node listed in
the interconnect summary. On these targets, calling
dev_pm_opp_of_add_table() api initializes the icc nodes for gpu indirectly.
So we should avoid using of_icc_get() api in the common probe path. To fix
this, we can move
Implement the shutdown callback for adreno gpu platform device
to safely shutdown it before a system reboot. This helps to avoid
futher transactions from gpu after the smmu is moved to bypass mode.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/adreno/adreno_device.c | 6 ++
1 file
Add cooling device support to gpu. A cooling device is bound to a
thermal zone to allow thermal mitigation.
Signed-off-by: Akhil P Oommen
---
Documentation/devicetree/bindings/display/msm/gpu.txt | 7 +++
1 file changed, 7 insertions(+)
diff --git
Add cooling-cells property and the cooling maps for the gpu tzones
to support GPU cooling.
Signed-off-by: Akhil P Oommen
---
The thermal policy should be set as 'step_wise' for gpu tzones from
the userspace during boot up.
arch/arm64/boot/dts/qcom/sc7180.dtsi | 30
Register GPU as a devfreq cooling device so that it can be passively
cooled by the thermal framework.
Signed-off-by: Akhil P Oommen
---
Changes in v2:
1. Update the dt bindings documentation
drivers/gpu/drm/msm/msm_gpu.c | 12
drivers/gpu/drm/msm/msm_gpu.h | 2 ++
2 files
://git-scm.com/docs/git-format-patch]
url:
https://github.com/0day-ci/linux/commits/Christophe-Leroy/drm-amd-display-Fix-missing-declaration-of-enable_kernel_vsx/20201019-174155
base: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
7cf726a59435301046250c42131554d9ccc566b8
On Sun, Oct 18, 2020 at 3:19 PM Sasha Levin wrote:
>
> From: xinhui pan
>
> [ Upstream commit 1545fbf97eafc1dbdc2923e58b4186b16a834784 ]
>
> Remove the private obj from the internal list before we free aconnector.
>
> [ 56.925828] BUG: unable to handle page fault for address: 8f84a870a560
https://bugzilla.kernel.org/show_bug.cgi?id=209673
--- Comment #10 from cornelius.riemenschnei...@googlemail.com ---
Created attachment 293057
--> https://bugzilla.kernel.org/attachment.cgi?id=293057=edit
crashing dmesg #7
--
You are receiving this mail because:
You are watching the assignee
Hi Kevin,
the basic problem you are facing is that ttm_tt_create/destroy is
mandatory (It always was). You need an implementation or otherwise you
won't be able to use the system domain (additional to the optional GTT
domain).
My best guess is that the difference is that we now force to
Am 19.10.20 um 09:13 schrieb Dave Airlie:
From: Dave Airlie
Uninline ttm_bo_move_ttm. Eventually want to unhook the unbind out.
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 15 ---
Am 19.10.20 um 09:13 schrieb Dave Airlie:
From: Dave Airlie
The apis to move old/new are in place everywhere so this is no
longer needed.
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20
include/drm/ttm/ttm_bo_driver.h | 22
Am 19.10.20 um 09:13 schrieb Dave Airlie:
From: Dave Airlie
In all 3 drivers there is a case where the driver knows the
bo is in SYSTEM so don't call the api that checks that.
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
Am 19.10.20 um 09:13 schrieb Dave Airlie:
From: Dave Airlie
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
Maybe just call it ...move_to_system(), but either way Reviewed-by:
Christian König
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ---
1 file
On Sun, Oct 18, 2020 at 11:51:19PM +0200, Daniel Vetter wrote:
> On Sun, Oct 18, 2020 at 10:45 PM Peilin Ye wrote:
> > I'm confused, I see it on LKML in the link above. Sure I'll resend soon.
>
> My brain didn't work, sorry about the confusion.
>
> I'll pick up the patches tomorrow, probably
Am 19.10.20 um 09:13 schrieb Dave Airlie:
From: Dave Airlie
This factors out the code to setup non-system tt.
The same code was used twice in the move paths.
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
Reviewed-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 12
1 - 100 of 118 matches
Mail list logo
