Spent today trying to straighten out some of the ideas I had for
dropping bind/unbind paths into drivers.
https://github.com/airlied/linux/commits/ttm-no-more-bind
I think it mostly trends to the right place, the bind/unbind paths all
end up in drivers, you get a move/invalidate_notify or move_no
On Tue, Sep 22, 2020 at 09:31:58PM +0800, Christian König wrote:
> As an alternative to the placement flag add a
> pin count to the ttm buffer object.
>
> v2: add dma_resv_assert_help() calls
>
> Signed-off-by: Christian König
Series look good for me as well.
Reviewed-by: Huang Rui
Only one
Hi all,
After merging the drm tree, today's linux-next build (x86_64 allmodconfig)
produced this warning:
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c: In function
'cdns_mhdp_fw_activate':
drivers/gpu/drm/bridge/cadence/cdns-mhdp8546-core.c:751:10: warning: conversion
from 'long unsigned
On Fri, 18 Sep 2020 at 00:49, Christian König wrote:
>
> Am 17.09.20 um 16:44 schrieb Michel Dänzer:
> > On 2020-09-17 2:20 p.m., Christian König wrote:
> >> Hi guys,
> >>
> >> Michel once submitted a patch to fix triggering this BUG_ON in
> >> ttm_tt_swapout():
> >>
> >>> BUG_ON(ttm->caching_stat
From: Dave Airlie
Call the driver move function if it exists, otherwise use the
fallback ttm/memcpy paths.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 28 +++-
1 file changed, 19 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
From: Dave Airlie
The core move code currently handles use_tt moves, for radeon
this was being handled also in the driver, but not using the same
paths.
If moving between TT/SYSTEM (all the use_tt paths on radeon) use
the core move function.
Eventually the core will be flipped over to calling t
From: Dave Airlie
The core move code currently handles use_tt moves, for amdgpu
this was being handled also in the driver, but not using the same
paths.
If moving between TT/SYSTEM (all the use_tt paths on amdgpu) use
the core move function.
Eventually the core will be flipped over to calling t
From: Dave Airlie
The idea is to flip the core over to calling the driver always,
so add support for moves here.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/drivers
The first 5 patches are just cleanups to remove unused functions
and handle ttm operation ctx nicer in driver move paths.
The last 5 patches have the goal to invert the operation of the
move driver callback. Currently the core does some tt related moves
itself and pass the drivers the rest. I'd li
From: Dave Airlie
This just consolidates the code making the flow easier to understand
and also helps when moving move to the driver side.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/ttm/ttm_bo.c | 17 +++--
1 file changed, 7 insertions(+), 10 deletions(-)
diff --git a/drivers/
From: Dave Airlie
This just uses the ctx instead of passing bools and recreating it.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +---
1 file changed, 23 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/nouveau/nouveau_bo.c
b/dr
From: Dave Airlie
I'm thinking of pushing the wait into the drivers.
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 4 ++--
drivers/gpu/drm/qxl/qxl_ttm.c| 2 +-
drivers/gpu/drm/radeon/radeon_ttm.c | 2 +-
drivers/gpu/drm/ttm/ttm_bo_util.c| 4 ++--
include/dr
Hi Stanley.Yang,
FYI, the error/warning still remains.
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
confi
From: Dave Airlie
This wasn't used anywheere
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/qxl/qxl_object.h | 23 ---
1 file changed, 23 deletions(-)
diff --git a/drivers/gpu/drm/qxl/qxl_object.h b/drivers/gpu/drm/qxl/qxl_object.h
index c7d79b20622e..09a5c818324d 100644
-
From: Dave Airlie
Just pass it around move, and remove unused pieces
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_ttm.c | 34 +
1 file changed, 15 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/rad
From: Dave Airlie
this is unused
Signed-off-by: Dave Airlie
---
drivers/gpu/drm/radeon/radeon_object.c | 15 ---
drivers/gpu/drm/radeon/radeon_object.h | 3 ---
2 files changed, 18 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_object.c
b/drivers/gpu/drm/radeon/radeon_o
On Tue, 22 Sep 2020 at 23:32, Christian König
wrote:
>
> As an alternative to the placement flag add a
> pin count to the ttm buffer object.
These all look good to me, nice cleanup.
For the series:
Reviewed-by: Dave Airlie
___
dri-devel mailing list
d
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 0b54e1e30e9f201a63922344917e11ab60da0d1b [443/482] drm/amdgpu: Fix
handling of KFD initialization failures
config: x86_64-randconfig-s021-20200920 (attached as .confi
Fixes: 0b54e1e30e9f ("drm/amdgpu: Fix handling of KFD initialization failures")
Signed-off-by: kernel test robot
---
amdgpu_amdkfd.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
in
Sink event notify messages are used for MST CEC IRQs. Add parsing
support for sink event notify messages in preparation for handling MST
CEC IRQs.
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 37 ++-
include/drm/drm_dp_mst
With DP v2.0 errata E5, CEC tunneling can be supported through an MST
topology.
There are some minor differences for CEC tunneling through an MST
topology compared to CEC tunneling to an SST port:
- CEC IRQs are delivered via a sink event notify message
- CEC-related DPCD registers are accessed vi
From: Hans Verkuil
For adapters behind an MST hub use the correct AUX channel.
Signed-off-by: Hans Verkuil
[sa...@chromium.org: rebased, removing redundant changes]
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 36 +++
1
From: Hans Verkuil
These are required for the CEC MST support.
Signed-off-by: Hans Verkuil
Signed-off-by: Sam McNally
---
(no changes since v1)
drivers/gpu/drm/drm_dp_mst_topology.c | 6 ++
include/drm/drm_dp_mst_helper.h | 4
2 files changed, 6 insertions(+), 4 deletions(-)
On Tue, 15 Sep 2020 14:19:10 +0200, Neil Armstrong wrote:
> Simple DSI panels can also have a reset GPIO signal in addition/instead of an
> enable GPIO signal.
>
> This adds an optional reset-gpios property.
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/display/panel/panel-s
On Tue, 15 Sep 2020 14:19:11 +0200, Neil Armstrong wrote:
> This add the bindings for the 1024x600 TFT LCD TL070WSH30 DSI panel to
> panel-simple-dsi.
>
> Signed-off-by: Neil Armstrong
> ---
> .../devicetree/bindings/display/panel/panel-simple-dsi.yaml | 2 ++
> 1 file changed, 2 insertions
On Tue, 15 Sep 2020 14:19:09 +0200, Neil Armstrong wrote:
> Shanghai Top Display Optolelectronics Co., Ltd is a display manufacturer
> from Shanghai.
> Web site of the company: http://www.shtdo.com/
>
> Signed-off-by: Neil Armstrong
> ---
> Documentation/devicetree/bindings/vendor-prefixes.yaml
On Tue, Sep 8, 2020 at 3:46 AM David Hildenbrand wrote:
>
> On 22.08.20 01:21, Andrew Morton wrote:
> > On Wed, 19 Aug 2020 18:53:57 -0700 Dan Williams
> > wrote:
> >
> >>> I think I am missing some important pieces. Bear with me.
> >>
> >> No worries, also bear with me, I'm going to be offline
Acked-by: Guo Ren
On Sat, Sep 19, 2020 at 5:50 PM Thomas Gleixner wrote:
>
> Signed-off-by: Thomas Gleixner
> Cc: Guo Ren
> Cc: linux-c...@vger.kernel.org
> ---
> Note: Completely untested
> ---
> arch/csky/Kconfig |1
> arch/csky/include/asm/highmem.h |4 +-
> arch/csky
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
config: x86_64-randconfig-a014-20200922 (attached as .config
Hi! Since I got dropped from the thread, many responses inline
On Tue, 2020-09-22 at 12:58 -0700, Puthikorn Voravootivat wrote:
> +Lyude
> I notice that Lyude email was somehow dropped from the thread.
> Lyude was the person who submitted the patch for Thinkpad and should
> know the OUI of the pan
On Tue, Sep 22, 2020 at 5:14 PM Lyude Paul wrote:
>
> On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> > Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> > it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
>
> I don't think that display_info.bpc a
On Tue, 2020-09-22 at 17:10 -0400, Ilia Mirkin wrote:
> Can we use 6bpc on arbitrary DP monitors, or is there a capability for
> it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
I don't think that display_info.bpc actually implies a minimum bpc, only a
maximum bpc iirc (Ville
nce commit 818280d5adf1d80e78f95821815148abe9407e14:
>
> Merge v5.9-rc5 into drm-next (2020-09-14 17:19:11 +0200)
>
> are available in the Git repository at:
>
> git://linuxtv.org/pinchartl/media.git
Modelled after the "my dog ate my homework", something ate the t
Hi Marek,
On Tue, 22 Sep 2020, Marek Szyprowski wrote:
> External email: Use caution opening links or attachments
>
>
> Hi Alex,
>
> On 22.09.2020 01:15, Alex Goins wrote:
> > Tested-by: Alex Goins
> >
> > This change fixes a regression with drm_prime_sg_to_page_addr_arrays() and
> > AMDGPU i
Can we use 6bpc on arbitrary DP monitors, or is there a capability for
it? Maybe only use 6bpc if display_info.bpc == 6 and otherwise use 8?
On Tue, Sep 22, 2020 at 5:06 PM Lyude Paul wrote:
>
> While I thought I had this correct (since it actually did reject modes
> like I expected during testin
While I thought I had this correct (since it actually did reject modes
like I expected during testing), Ville Syrjala from Intel pointed out
that the logic here isn't correct. max_clock refers to the max symbol
rate supported by the encoder, so limiting clock to ds_clock using max()
doesn't make se
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: 6fe4a372821db85834f5522d94d25139ff17e414
commit: 4484ea5dfcbb092d856aee77aee01b36ff76d389 [471/482] drm/amdgpu: update
athub interrupt harvesting handle
config: alpha-allyesconfig (attached as .config)
compiler: alp
Hi,
On Tue, Sep 22, 2020 at 12:10 PM Vicente Bergas wrote:
>
> On Tuesday, September 22, 2020 5:26:17 PM CEST, Doug Anderson wrote:
> > Hi,
> >
> > On Tue, Sep 22, 2020 at 7:52 AM Vicente Bergas wrote:
> >> On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson
> >> wrote: ...
> >
> > Here's the code:
>
Quoting Hoegeun Kwon (2020-08-31 21:07:56)
> To use QHD or higher, we need to modify the pixel_bvb_clk value. So
> add register to control this clock.
>
> Signed-off-by: Hoegeun Kwon
> ---
Applied to clk-next
___
dri-devel mailing list
dri-devel@lists.
Hi,
On Tue, 22 Sep 2020 at 19:18, Daniel Vetter wrote:
> + for_each_new_crtc_in_state(state, crtc, old_crtc_state, i)
> + affected_crtc |= drm_crtc_mask(crtc);
> +
> + /*
> +* For commits that allow modesets drivers can add other CRTCs to the
> +* atomic
Hi,
On Tue, 22 Sep 2020 at 17:02, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
> > I think we need a guarantee that this never happens if ALLOW_MODESET
> > is always used in blocking mode, plus in future a cap we can use to
> > detect that we won't be getting spurio
On Tue, 22 Sep 2020 20:52:06 +0300
Ville Syrjälä wrote:
> Mea culpa. My doc test build was foiled by the sphinx 2 vs. 3
> regression and I was too lazy to start downgrading things.
> Any ETA for getting that fixed btw?
There's a fix of sorts in docs-next (and thus linux-next) now, has been
there
Hi Daniel,
Thank you for your review. Keem Bay is developed on kernel 5.45 (Yocto) and I
am working with the program to get a working 5.9 kernel for Keem Bay and will
test this driver when that becomes available.
Thanks,
Anitha
> -Original Message-
> From: Daniel Vetter
> Sent: Thursd
When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
pull in arbitrary other resources, including CRTCs (e.g. when
reconfiguring global resources).
But in nonblocking mode userspace has then no idea this happened,
which can lead to spurious EBUSY calls, both:
- when that other CR
On Tue, 2020-09-22 at 17:25 +0800, Tian Tao wrote:
> This addresses the following gcc warning with "make W=1":
> drivers/gpu/drm/nouveau/dispnv50/disp.c: In function ‘nv50_mstm_prepare’:
> drivers/gpu/drm/nouveau/dispnv50/disp.c:1378:6: warning:
> variable ‘ret’ set but not used [-Wunused-but-set-v
One last change I realized we should do is print the name of the AUX adapter
in question. I don't mind just adding that myself before I push it though so
you don't need to send a respin.
Going to go push this to drm-misc-next, thanks!
On Tue, 2020-09-22 at 14:53 +0800, Koba Ko wrote:
> As per DP-
From: Mauro Carvalho Chehab
The name of the argument is different, causing those warnings:
./drivers/gpu/drm/drm_edid.c:3754: warning: Function parameter or
member 'video_code' not described in 'drm_display_mode_from_cea_vic'
./drivers/gpu/drm/drm_edid.c:3754: warning: Excess fu
From: Mauro Carvalho Chehab
As warned by kernel-doc:
./drivers/gpu/drm/drm_dp_helper.c:385: warning: Function parameter or
member 'type' not described in 'drm_dp_downstream_is_type'
./drivers/gpu/drm/drm_dp_helper.c:886: warning: Function parameter or
member 'dev' not described
On Tue, Sep 22, 2020 at 01:39:41PM -0400, Lyude Paul wrote:
> For patches 2 and 3:
>
> Reviewed-by: Lyude Paul
>
> I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next
> doesn't have these patches in yet, and the commits these fix were originally
> merged through drm-intel-
For patches 2 and 3:
Reviewed-by: Lyude Paul
I'll go ahead and push these to drm-intel-next-queued (since drm-misc-next
doesn't have these patches in yet, and the commits these fix were originally
merged through drm-intel-next-queued anyway). thanks!
On Tue, 2020-09-22 at 13:22 +0200, Mauro Car
On 22/09/2020 17:33, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 05:13:45PM +0100, Tvrtko Ursulin wrote:
void *shmem_pin_map(struct file *file)
{
- const size_t n_pte = shmem_npte(file);
- pte_t *stack[32], **ptes, **mem;
Chris can comment how much he'd miss the 32 pag
On 22/09/2020 15:31, Christoph Hellwig wrote:
On Tue, Sep 22, 2020 at 09:23:59AM +0100, Tvrtko Ursulin wrote:
If I understood this sub-thread correctly, iterating and freeing the pages
via the vmapped ptes, so no need for a
shmem_read_mapping_page_gfp loop in shmem_unpin_map looks plausible to
On Tue, 22 Sep 2020 15:55:08 +0800, Chunfeng Yun wrote:
> Convert HDMI PHY binding to YAML schema mediatek,ufs-phy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> .../display/mediatek/mediatek,hdmi.txt| 17 +---
> .../bindings/phy/mediatek,hdmi-phy.yaml | 90 +++
> 2 f
On Tue, 22 Sep 2020 15:55:07 +0800, Chunfeng Yun wrote:
> Convert phy-mtk-ufs.txt to YAML schema mediatek,ufs-phy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> .../bindings/phy/mediatek,ufs-phy.yaml| 64 +++
> .../devicetree/bindings/phy/phy-mtk-ufs.txt | 38 ---
On Tue, 22 Sep 2020 15:55:06 +0800, Chunfeng Yun wrote:
> Convert phy-mtk-tphy.txt to YAML schema mediatek,tphy.yaml
>
> Signed-off-by: Chunfeng Yun
> ---
> .../bindings/phy/mediatek,tphy.yaml | 260 ++
> .../devicetree/bindings/phy/phy-mtk-tphy.txt | 162 ---
>
On Tue, Sep 22, 2020 at 4:14 PM Daniel Stone wrote:
>
> On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> > On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad
> > wrote:
> > > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > > I've noticed this isn't integrated/added.
> >
>
Applied with subject typo fixed. Thanks!
Alex
On Tue, Sep 22, 2020 at 10:07 AM Ernst Sjöstrand wrote:
>
> There is a typo in your patch subject. ;-)
>
> Regards
> //Ernst
>
> Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing :
>>
>> Modify the comment typo: "definately" -> "definitely".
>>
>> Signe
Applied. Thanks!
Alex
On Tue, Sep 22, 2020 at 3:52 AM Bernard Zhao wrote:
>
> In the function dal_ddc_service_query_ddc_data,
> get rid of dal_ddc_i2c_payloads_destroy, call
> dal_vector_destruct() directly.
> This change is to make the code run a bit fast.
>
> Signed-off-by: Bernard Zhao
> Ch
Applied. Thanks!
Alex
On Tue, Sep 22, 2020 at 9:11 AM Bernard Zhao wrote:
>
> Change the comment typo: "programm" -> "program".
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h | 2 +-
> drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c | 4 ++--
> drivers/gpu/drm/amd/amdgp
Applied. Thanks!
Alex
On Tue, Sep 22, 2020 at 9:11 AM Bernard Zhao wrote:
>
> Change the comment typo: "programm" -> "program".
>
> Signed-off-by: Bernard Zhao
> ---
> drivers/gpu/drm/radeon/uvd_v1_0.c | 4 ++--
> drivers/gpu/drm/radeon/uvd_v2_2.c | 2 +-
> drivers/gpu/drm/radeon/uvd_v4_2.c |
On Tue, 2020-09-22 at 09:39 -0400, Sean Paul wrote:
> On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
> > So if I understand this correctly, it sounds like that some Pixelbooks
> > boot up
> > with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> > panel actually having DPC
On 9/22/20 11:27 AM, Christoph Hellwig wrote:
> On Tue, Sep 22, 2020 at 11:24:20AM -0400, boris.ostrov...@oracle.com wrote:
>> On 9/22/20 10:58 AM, Christoph Hellwig wrote:
>>> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
This will end up incrementing area->ptes
Milo Kim's email in TI bounces with permanent error (550: Invalid
recipient). Last email from him on LKML was in 2017. Move Milo Kim to
credits and add Dan Murphy from TI to look after:
- TI LP855x backlight driver,
- TI LP8727 charger driver,
- TI LP8788 MFD (ADC, LEDs, charger and regulator)
Hi,
On Tue, Sep 22, 2020 at 7:52 AM Vicente Bergas wrote:
>
> On Tue, Sep 22, 2020 at 4:28 PM Doug Anderson wrote:
> >
> > Hi,
> >
> > On Tue, Sep 22, 2020 at 3:13 AM crj wrote:
> > >
> > > Hi, Douglas
> > >
> > > 在 2020/9/22 17:31, Vicente Bergas 写道:
> > > > On Tue, Sep 22, 2020 at 11:24 AM cr
On 9/22/20 10:58 AM, Christoph Hellwig wrote:
> On Mon, Sep 21, 2020 at 04:44:10PM -0400, boris.ostrov...@oracle.com wrote:
>> This will end up incrementing area->ptes pointer. So perhaps something like
>>
>>
>> pte_t **ptes = area->ptes;
>>
>> if (apply_to_page_range(&init_mm, (unsigned long)area
On Tue, Sep 22, 2020 at 3:47 AM Nathan Chancellor
wrote:
>
> Clang warns:
>
> drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_mst_types.c:637:8:
> warning: logical not is only applied to the left hand side of this
> comparison [-Wlogical-not-parentheses]
>
On Fri, Sep 18, 2020 at 11:01 AM Christian König
wrote:
>
> When we swapout/in a BO we try to change the caching
> attributes of the pages before/after doing the copy.
>
> On x86 this is done by calling set_pages_uc(),
> set_memory_wc() or set_pages_wb() for not highmem pages
> to update the linea
The drm_gem_vram_create() function is the only caller of the internal
helper drm_gem_vram_init(). Streamline the code by putting all code into
the create function.
v2:
* rebased onto latest drm-tip
* fixed typo in commit message (Sam)
Signed-off-by: Thomas Zimmermann
Acked-by: Sa
Don't override the GEM object functions unconditionally. If the driver
sets the GEM functions, VRAM helpers will not set them. The idea has been
taken from SHMEM helpers.
v2:
* updated the commit message (Sam)
* document the new feature for drm_gem_vram_create()
Signed-off-by: Tho
Most drivers that use VRAM helpers have only a few MiB of framebuffer
memory available. To reduce fragmentation, new BOs are now put into
system memory by default. Only pin operations are allowed to move BOs
into VRAM.
v2:
* rebased onto latest drm-tip
Signed-off-by: Thomas Zimmermann
--
This is a collection of improvements for GEM VRAM helpers. The patches
were part of other patchsets that didn't make it into upstream, but the
changes are nevertheless useful.
Thomas Zimmermann (3):
drm/vram-helper: Integrate drm_gem_vram_init() into
drm_gem_vram_create()
drm/vram-helper:
Leave the inuse count intact on map failure to keep the accounting
accurate.
Signed-off-by: Akhil P Oommen
---
drivers/gpu/drm/msm/msm_gem_vma.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/msm_gem_vma.c
b/drivers/gpu/drm/msm/msm_gem_vma.c
index 80a
In the case where we have a back-to-back submission that shares the same
BO, this BO will be prematurely moved to inactive_list while retiring the
first submit. But it will be still part of the second submit which is
being processed by the GPU. Now, if the shrinker happens to be triggered at
this p
Hello Zou,
On Tue, 22 Sep 2020 at 18:12, Christian König wrote:
>
> Am 22.09.20 um 09:53 schrieb Zou Wei:
> > This patch fixes below warnings reported by coccicheck
> >
> > ./drivers/dma-buf/heaps/heap-helpers.c:202:5-8: Unneeded variable: "ret".
> > Return "0" on line 215
> >
> > Signed-off-by:
On Mon, Sep 21, 2020 at 11:59 PM Daniel Vetter wrote:
>
> On Mon, Sep 21, 2020 at 5:16 PM Rob Clark wrote:
> >
> > On Mon, Sep 21, 2020 at 2:21 AM Daniel Vetter wrote:
> > >
> > > On Sat, Sep 19, 2020 at 12:37:23PM -0700, Rob Clark wrote:
> > > > From: Rob Clark
> > > >
> > > > The android user
The gamma LUT has to be reloaded after changing the primary plane's
color format. This used to be done implicitly by the CRTC atomic_enable()
helper after updating the primary plane. With the recent reordering of
the steps, the primary plane's setup was moved last and invalidated
the gamma LUT. Fix
On Mon, Sep 21, 2020 at 04:48:05PM +0200, Michel Dänzer wrote:
On 2020-09-21 4:40 p.m., Sasha Levin wrote:
From: Michel Dänzer
[ Upstream commit 2f228aab21bbc74e90e267a721215ec8be51daf7 ]
Don't check drm_crtc_state::active for this either, per its
documentation in include/drm/drm_crtc.h:
*
Hi,
On Tue, Sep 22, 2020 at 3:13 AM crj wrote:
>
> Hi, Douglas
>
> 在 2020/9/22 17:31, Vicente Bergas 写道:
> > On Tue, Sep 22, 2020 at 11:24 AM crj wrote:
> >> Hello Vicente,
> >>
> >> 在 2020/9/22 15:40, Andy Yan 写道:
> >>> Add our HDMI driver owner Algea to list.
> >>>
> >>> On 9/22/20 2:18 AM, Vi
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #11 from Alexander von Gluck (kallis...@unixzen.com) ---
weird... let me move things over to my Ryzen desktop and see what changes.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #10 from Ilia Mirkin (imir...@alum.mit.edu) ---
[ 176.562278] nouveau :08:00.0: bar: one-time init failed, -12
08:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1)
Subsystem: NVIDIA Corporation Device 10
When the GPU's ACE-Lite interface is fully wired up and capable of
snooping CPU caches, it may be described as "dma-coherent" in
devicetree, which will already inform the DMA layer not to perform
unnecessary cache maintenance. However, we still need to ensure that
the GPU uses the appropriate cache
According to a downstream commit I found in the Khadas vendor kernel,
the GPU on G12b is wired up for ACE-lite, so (now that Panfrost knows
how to handle this properly) we should describe it as such. Otherwise
the mismatch leads to all manner of fun with mismatched attributes and
inadvertently snoo
Hi all,
Here's a quick v2 with the tags so far picked up and some inline
commentary about the shareability domains for the pagetable code.
Robin.
Robin Murphy (3):
iommu/io-pgtable-arm: Support coherency for Mali LPAE
drm/panfrost: Support cache-coherent integrations
arm64: dts: meson: De
Midgard GPUs have ACE-Lite master interfaces which allows systems to
integrate them in an I/O-coherent manner. It seems that from the GPU's
viewpoint, the rest of the system is its outer shareable domain, and so
even when snoop signals are wired up, they are only emitted for outer
shareable accesse
On Tue, 22 Sep 2020 at 15:04, Daniel Vetter wrote:
> On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
> > Gentle ping. I've tried out Linus's master tree and, and like Pekka,
> > I've noticed this isn't integrated/added.
>
> Defacto the uapi we have now is that userspace needs to ignore "spurio
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #8 from Alexander von Gluck (kallis...@unixzen.com) ---
rebooted without TB3 enclosure attached. Msnuslly loaded nouveau vis insmod
after the TB3 attachment calmed down, and got something a bit cleaner:
[ 176.083524] nouveau: loadin
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #9 from Alexander von Gluck (kallis...@unixzen.com) ---
better lspci:
08:00.0 3D controller: NVIDIA Corporation GK210GL [Tesla K80] (rev a1)
Subsystem: NVIDIA Corporation Device 106c
Control: I/O- Mem+ BusMaster- SpecC
There is a typo in your patch subject. ;-)
Regards
//Ernst
Den tis 22 sep. 2020 kl 15:11 skrev Wang Qing :
> Modify the comment typo: "definately" -> "definitely".
>
> Signed-off-by: Wang Qing
> ---
> drivers/gpu/drm/radeon/radeon_vm.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
On Tue, Sep 22, 2020 at 3:36 PM Marius Vlad wrote:
>
> On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> > On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > > pull in arbitrary other resources, includin
https://bugzilla.kernel.org/show_bug.cgi?id=209345
--- Comment #7 from Ilia Mirkin (imir...@alum.mit.edu) ---
[ 2460.923220] nouveau :08:00.0: can't change power state from D3hot to D0
(config space inaccessible)
That's just really bad. My guess is that the "big-endian" notice is just due to
On Mon, Sep 21, 2020 at 6:35 PM Lyude Paul wrote:
>
> So if I understand this correctly, it sounds like that some Pixelbooks boot up
> with DP_EDP_BACKLIGHT_BRIGHTNESS_MSB set to a non-zero value, without the
> panel actually having DPCD backlight controls enabled?
It boots with DP_EDP_BACKLIGHT_
On Fri, Jan 31, 2020 at 07:34:00AM +, Daniel Stone wrote:
> On Thu, 5 Jul 2018 at 11:21, Daniel Vetter wrote:
> > When doing an atomic modeset with ALLOW_MODESET drivers are allowed to
> > pull in arbitrary other resources, including CRTCs (e.g. when
> > reconfiguring global resources).
> >
>
Implement in the driver instead since it is the only user of that function.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 42 ++
drivers/gpu/drm/vmwgfx/vmwgfx_cmdbuf.c | 6 ++--
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 +++
driver
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
drivers/gpu/drm/nouveau/nouveau_bo.c | 48 +++---
drivers/gpu/drm/nouveau/nouveau_bo.h | 3 --
drivers/gpu/drm/nouveau/nouveau_chan.c | 2 +-
3 files changed, 13 insertions(+), 40 deletions(-)
diff --g
Not used any more.
Signed-off-by: Christian König
---
drivers/gpu/drm/ttm/ttm_bo.c | 40
include/drm/ttm/ttm_bo_api.h | 24 --
2 files changed, 64 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
Reviewed-by: Gerd Hoffmann
Tested-by: Gerd Hoffmann
---
drivers/gpu/drm/qxl/qxl_debugfs.c | 2 +-
drivers/gpu/drm/qxl/qxl_drv.h | 1 -
drivers/gpu/drm/qxl/qxl_ioctl.c | 4 +--
drivers/gpu/drm/qxl/qxl_object.c | 44 ++
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 5 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_display.c | 8 +---
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 5 ++-
driv
Stop using TTM_PL_FLAG_NO_EVICT.
Signed-off-by: Christian König
---
drivers/gpu/drm/radeon/radeon.h | 1 -
drivers/gpu/drm/radeon/radeon_display.c | 9 ++
drivers/gpu/drm/radeon/radeon_object.c | 37 ++---
drivers/gpu/drm/radeon/radeon_object.h | 2 +-
driver
Just some dead code cleanup.
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 1 -
drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 30 --
2 files changed, 31 deletions(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_drv.h
b/drivers/gpu/drm/vmwgfx/
Stop using TTM_PL_FLAG_NO_EVICT.
v2: fix unconditional pinning
Signed-off-by: Christian König
---
drivers/gpu/drm/vmwgfx/vmwgfx_blit.c | 4 +-
drivers/gpu/drm/vmwgfx/vmwgfx_bo.c | 49 +++---
drivers/gpu/drm/vmwgfx/vmwgfx_cotable.c| 4 +-
drivers/gpu/drm/vmwgf
1 - 100 of 200 matches
Mail list logo
