Hi
On 16.10.20 23:01, David Airlie wrote:
> On Fri, Oct 16, 2020 at 6:03 PM KuoHsiang Chou
> wrote:
>>
>> The patch is upstreamed
>> 1. For RHEL7.x, because its native kernel is suggested to update
>>from 3.10 to 4.9 on 2 ODM's platform.
>> 2. For AST2600.
>> 3. For ASTDP.
>> 4. v1.11
>
> Hi
This function post removal of the caching stuff was doing 3 jobs,
moving non system old ttm to system, moving from system to a new TT
and assigning. Instead this series splits it into 3 and only calls
the necessary combination from the drivers.
This is just a cleaned up and rebased version of some
From: Dave Airlie
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 38 ---
1 file changed, 25 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index a36c615b
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
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 4 ++--
drivers/gpu/drm/nouveau/nouveau_bo.c| 3 ++-
drive
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
---
drivers/gpu/drm/ttm/ttm_bo.c | 12 +++
drivers/gpu/drm/ttm/ttm_bo_util.c | 34 +-
From: Dave Airlie
Uninline ttm_bo_move_ttm. Eventually want to unhook the unbind out.
Reviewed-by: Ben Skeggs
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c| 15 ---
drivers/gpu/drm/nouveau/nouveau_bo.c | 11 +--
drivers/gpu/drm/radeon/rad
From: Dave Airlie
The apis to move old/new are in place everywhere so this is no
longer needed.
---
drivers/gpu/drm/ttm/ttm_bo_util.c | 20
include/drm/ttm/ttm_bo_driver.h | 22 --
2 files changed, 42 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_b
Hi
On 14.10.20 10:21, Xu Wang wrote:
> Because clk_enable, clk_disable, clk_prepare, and clk_unprepare already
> checked NULL clock parameter, so the additional checks are unnecessary,
> just remove them.
>
> Signed-off-by: Xu Wang
Sam convinced me to merge this patch as-is with out the additio
To Sirs,
Thanks for your answers about the patch and next upstream to kernel-5.9 must
follow these rules.
This patch based on kernel-4.9.237 is required by our customers, because my
customers said the native kernel of RHEL/CentOS 7.x is 3.10 and is required to
update to 4.9.
BTW, how to veri
Let's define Maximum MST content streams up to four
generically which can be supported by modern display
controllers.
Cc: Sean Paul
Cc: Ramalingam C
Signed-off-by: Anshuman Gupta
---
include/drm/drm_hdcp.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/drm/
Hi Dave,
Yeah, with the workaround I mentioned in my previous e-mail, OpenChrome DRM
does not crash for "ttm_tt_create" member being null.
It is still not able to boot X Server due to some other TTM related memory
allocation issue it is suffering from.
I think making huge changes to TTM during t
Hi
On 19.10.20 09:21, Kuo-Hsiang Chou wrote:
To Sirs,
Thanks for your answers about the patch and next upstream to kernel-5.9 must
follow these rules.
Thanks for wanting to contribute.
This patch based on kernel-4.9.237 is required by our customers, because my
customers said the native k
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:
> > > > On Fri, 9 Oct 2020 16:10
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 tell what are the host1x clients that are going to
To Thomas,
Thanks and got it.
Regards,
Kuo-Hsiang Chou
-Original Message-
From: Thomas Zimmermann [mailto:tzimmerm...@suse.de]
Sent: Monday, October 19, 2020 3:42 PM
To: Kuo-Hsiang Chou ; David Airlie
Cc: Jenmin Yuan ; e...@suse.com; Arc Sung
; dri-devel ; Tommy
Huang
Subje
On 17/10/2020 08:08, Sam Ravnborg wrote:
> Hi Neil.
>
> On Tue, Sep 29, 2020 at 11:25:17AM +0200, Neil Armstrong wrote:
>> Hi Sam,
>>
>> Is there anything more to change ?
> Sorry for taking so long to get back to you on this.
>
> All patches looks good and are:
> Reviewed-by: Sam Ravnborg
>
>
Hi Christian
On 15.10.20 16:08, Christian König wrote:
> Am 15.10.20 um 14:38 schrieb Thomas Zimmermann:
>> The new functions ttm_bo_{vmap,vunmap}() map and unmap a TTM BO in kernel
>> address space. The mapping's address is returned as struct dma_buf_map.
>> Each function is a simplified version
Hi Thomas,
[SNIP]
+int ttm_bo_vmap(struct ttm_buffer_object *bo, struct dma_buf_map *map)
+{
+ struct ttm_resource *mem = &bo->mem;
+ int ret;
+
+ ret = ttm_mem_io_reserve(bo->bdev, mem);
+ if (ret)
+ return ret;
+
+ if (mem->bus.is_iomem) {
+ void __iomem *vaddr_
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 +++
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 not
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 chang
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
---
drivers/gpu/drm/amd/amdgp
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 ---
drivers
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
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 init
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&action=edit
crashing dmesg #7
--
You are receiving this mail because:
You are watching the ass
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
>
d 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/torvalds/linux.git
7cf726a59435301046250c42131554
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
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 +++---
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 a/Documentation/devicetree/bindings/display
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 of_icc_g
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 ch
d 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/torvalds/linux.git
7cf726a59435301046250c42131554
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, Guido
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
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 ++
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 -
drivers/gpu/drm/amd/display/dc/dce100/dce100_res
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 wh
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
---
drivers/gpu/drm/amd/di
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 w
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 = &bo->mem;
> > > > + int ret;
> > > > +
> > > > + ret = ttm_m
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 Shawn
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.
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 conne
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 commit
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 ---
drivers/gpu/drm/no
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 s
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 cab
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 a
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 for
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 agai
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 /sys/class/d
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 achieving
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
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; neithe
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 si
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 b/
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
>> ---
>> .../display/panel/panel-one
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/
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
b/drivers/gp
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 R
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 ...
[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 dereference.
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 t
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
./drivers/g
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 r
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 parti
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, b
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 --> &mm->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 | 6
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 --
drivers/gpu/drm/msm/msm_fbdev
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
---
dri
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 deletions(
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
---
drive
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 a/dri
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 6abcf9fe480d
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 b
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 b/driver
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 insert
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
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 a/dri
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
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 ioc
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 mi
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 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 b/drive
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 +
drivers/gpu/d
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
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
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 the
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
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 ++-
drivers/gpu/drm/msm/msm_
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 ++
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: 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 +-
1 - 100 of 119 matches
Mail list logo
