On Thu, Aug 06, 2020 at 03:43:02PM +0900, Tetsuo Handa wrote:
> As of commit 47ec5303d73ea344 ("Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/netdev/net-next") on linux.git ,
> my VMware environment cannot boot. Do I need to bisect?
That sounds like a good idea, but please start a new thr
On Thu, 6 Aug 2020 at 14:39, Dave Airlie wrote:
>
> From: Dave Airlie
Just realised this is on an unpublished base, I'd had amended one
amdgpu ttm patch to avoid kzalloc, but not sent it out, but hadn't
rebased it either.
Dave.
___
dri-devel mailing l
From: Dave Airlie
This moves the io lru tracking into the driver allocated structure.
Probably need to consider if we can move more stuff in there around the
nouveau only io_lru functionality.
---
drivers/gpu/drm/nouveau/nouveau_ttm.c | 24 +---
drivers/gpu/drm/ttm/ttm_bo.c
From: Dave Airlie
This is a bit more involved that it looked, the range manager
needs accessors adding and amdgpu needs a bit of a refactor.
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gtt_mgr.c | 17 +++
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 5 +++--
drivers/gpu/drm/amd/amdgp
these are just for discussion mostly,
one drop size from the resource manager
the other moves the storage for the io_lru into nouveau.
Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-d
> That was not what I was talking about. Take a look at what those fields
> are used for :)
>
>
> As far as I see the only usage of the size is in
> ttm_resource_manager_debug(). But this size is actually totally opaque
> to TTM, it could be pages, bytes, fried chicken wings or whatever. In
> other
The pull request you sent on Thu, 6 Aug 2020 11:07:02 +1000:
> git://anongit.freedesktop.org/drm/drm tags/drm-next-2020-08-06
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/8186749621ed6b8fc42644c399e8c755a2b6f630
Thank you!
--
Deet-doot-dot, I am a bot.
https://kor
On Thu, 6 Aug 2020 at 11:07, Dave Airlie wrote:
>
> Hi Linus,
>
> This the main drm pull request for 5.9-rc1.
>
> New xilinx displayport driver, AMD support for two new GPUs (more
> header files), i915 initial support for RocketLake and some work on
> their DG1 (discrete chip).
>
> The core also g
When creating a frame buffer, the driver verifies that the pitches for
the chroma planes match the luma plane. This is done incorrectly for
fully planar YUV formats, without taking horizontal subsampling into
account. Fix it.
Signed-off-by: Laurent Pinchart
---
drivers/gpu/drm/rcar-du/rcar_du_km
Hi all,
On Thu, 30 Jul 2020 19:21:10 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the hmm tree got a conflict in:
>
> drivers/gpu/drm/nouveau/nvkm/subdev/mmu/vmmgp100.c
>
> between commit:
>
> 7763d24f3ba0 ("drm/nouveau/vmm/gp100-: fix mapping 2MB sysmem pages")
>
> fro
Hi all,
On Wed, 22 Jul 2020 15:52:39 +1000 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the devicetree tree got a conflict in:
>
> Documentation/devicetree/bindings/display/bridge/ti,sn65dsi86.txt
>
> between commit:
>
> 5a2e9b658cdc ("dt-bindings: drm/bridge: ti-sn65dsi86: Con
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: e1d114658d448b5da11c7925beda241e8b8dd321
commit: 10be8791067fc672e44fcaa7afb886390909a0c0 [628/1313] drm/amdkfd: Support
Sienna_Cichlid KFD v4
config: x86_64-randconfig-s021-20200805 (attached as .config)
compiler
https://bugzilla.kernel.org/show_bug.cgi?id=208825
Bug ID: 208825
Summary: lspci triggers NULL pointer dereference on AMD Renoir
4800H/5600M laptop
Product: Drivers
Version: 2.5
Kernel Version: 5.8.0
Hardware: x86-64
tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next
head: e1d114658d448b5da11c7925beda241e8b8dd321
commit: 3a2b9affb4c366dac8a088156c644cf329701816 [468/1313] drm/amdkfd: Track
SDMA utilization per process
config: x86_64-randconfig-s021-20200805 (attached as .config
the drm-next tree as:
> >
> > commit 4afaa61db9cf5250b5734c2531b226e7b3a3d691
> > Author: Colin Ian King
> > Date: Fri Jul 10 09:37:58 2020 +0100
> >
> > drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
> >
> > There
x spelling mistake "Falied" -> "Failed"
>
> There is a spelling mistake in a DRM_ERROR error message. Fix it.
>
> Signed-off-by: Colin Ian King
> Signed-off-by: Alex Deucher
>
> Alex
>
> > $ git show --oneline -s
> > d15fe4
uot;
>
> There is a spelling mistake in a DRM_ERROR error message. Fix it.
>
> Signed-off-by: Colin Ian King
> Signed-off-by: Alex Deucher
>
> Alex
>
>>
>> $ git show --oneline -s
>> d15fe4ec0435 (HEAD, tag: next-20200805, origin/master, or
250b5734c2531b226e7b3a3d691
Author: Colin Ian King
Date: Fri Jul 10 09:37:58 2020 +0100
drm/amdgpu: fix spelling mistake "Falied" -> "Failed"
There is a spelling mistake in a DRM_ERROR error message. Fix it.
Signed-off-by: Colin Ian King
Signed-off-by:
Reviewed-by: Rodrigo Siqueira
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> So we're not racing with userspace or deadlocking DM.
>
> [How]
> These flags are now stored on dm_plane_state itself and acquried and
> validated during commit_check, so just use those instead.
>
> Cc: Daniel Vetter
Reviewed-by: Rodrigo Siqueira
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> We're racing with userspace as the flags could potentially change
> from when we acquired and validated them in commit_check.
>
> [How]
> We unfortunately can't drop this function in its entirety from
> prepare_planes s
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> Enabling or disable DCC or switching between tiled and linear formats
> can require bandwidth updates.
>
> They're currently skipping all DC validation by being treated as purely
> surface updates.
>
> [How]
> Treat tiling_flag changes (which encode
Reviewed-by: Rodrigo Siqueira
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> Store these in advance so we can reuse them later in commit_tail without
> having to reserve the fbo again.
>
> These will also be used for checking for tiling changes when deciding
> to reset the plane or not.
>
> [Ho
From: Tom Rix
Reviewing this block of code in cdv_intel_dp_init()
ret = cdv_intel_dp_aux_native_read(gma_encoder, DP_DPCD_REV, ...
cdv_intel_edp_panel_vdd_off(gma_encoder);
if (ret == 0) {
/* if this fails, presume the device is a ghost */
DRM_INFO("failed to retrieve link info,
eady fixed.
This fix is not in today's -next.
Perhaps whatever tree it's fixed in should be in -next.
$ git show --oneline -s
d15fe4ec0435 (HEAD, tag: next-20200805, origin/master, origin/HEAD) Add
linux-next specific files for 20200805
$ git grep -i falied drivers
drivers/gpu/drm/
Reviewed-by: Rodrigo Siqueira
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> This was added in the past to solve the issue of not knowing when
> to stall for medium and full updates in DM.
>
> Since DC is ultimately decides what requires bandwidth changes we
> wanted to make use of it directly t
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> MEDIUM or FULL updates can require global validation or affect
> bandwidth. By treating these all simply as surface updates we aren't
> actually passing this through DC global validation.
>
> [How]
> There's currently no way to pass surface updates th
Hi,
I have some minor inline comments, but everything looks fine when I
tested it on Raven; feel free to add
Tested-by: Rodrigo Siqueira
in the whole series.
On 07/30, Nicholas Kazlauskas wrote:
> [Why]
> DM atomic check was structured in a way that we required old DC state
> in order to dyna
On Wed, Aug 05, 2020 at 11:37:11PM +0530, Vaibhav Gupta wrote:
> Drivers using legacy power management .suspen()/.resume() callbacks
> have to manage PCI states and device's PM states themselves. They also
> need to take care of standard configuration registers.
s/using legacy/using legacy PCI/
s/
On Wed, Aug 5, 2020 at 8:15 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a dev_warn message. Fix it.
>
> Signed-off-by: Colin Ian King
Applied. Thanks!
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
> 1 file changed, 1 insertion(+), 1 del
On Wed, Aug 5, 2020 at 7:35 AM Colin King wrote:
>
> From: Colin Ian King
>
> There is a spelling mistake in a DRM_ERROR message. Fix it.
>
> Signed-off-by: Colin Ian King
This is already fixed.
Alex
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
> 1 file changed, 1 insertion(+), 1
https://bugzilla.kernel.org/show_bug.cgi?id=208811
--- Comment #10 from R0b0t1 (s...@aeam.us) ---
Yep, seems obvious in retrospect.
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@l
Hi Anitha.
On Mon, Aug 03, 2020 at 09:02:24PM +, Chrisanthus, Anitha wrote:
> Hi Sam,
> I installed codespell, but the dictionary.txt in
> usr/share/codespell/dictionary.txt
> seems to be different from yours. Mine is version 1.8. Where can I get the
> dictionary.txt
> that you are using?
I
https://bugzilla.kernel.org/show_bug.cgi?id=208811
--- Comment #9 from Alex Deucher (alexdeuc...@gmail.com) ---
Does disabling memory encryption fix the issue?
--
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-de
https://bugzilla.kernel.org/show_bug.cgi?id=208811
--- Comment #8 from Alex Deucher (alexdeuc...@gmail.com) ---
(In reply to R0b0t1 from comment #7)
> Related Bug 204181, related
> https://bugzilla.redhat.com/show_bug.cgi?id=1851855.
Those are unrelated.
--
You are receiving this mail because:
https://bugzilla.kernel.org/show_bug.cgi?id=208811
--- Comment #7 from R0b0t1 (s...@aeam.us) ---
Related Bug 204181, related
https://bugzilla.redhat.com/show_bug.cgi?id=1851855.
--
You are receiving this mail because:
You are watching the assignee of the bug.
On 2020-06-29 5:19 p.m., Christian König wrote:
> We only need the page array when the BO is about to be accessed.
>
> So not only populate, but also create it on demand.
>
> v2: move NULL check into ttm_tt_create()
> v3: fix the occurrence in ttm_bo_kmap_ttm as well
This broke amdgpu userptr fu
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Status|NEW |RESOLVED
Kernel Versi
On Wed, Aug 5, 2020 at 6:34 AM Kalyan Thota wrote:
>
> In TEST_ONLY commit, rm global_state will duplicate the
> object and request for new reservations, once they pass
> then the new state will be swapped with the old and will
> be available for the Atomic Commit.
>
> This patch fixes some of mis
On 05/08/2020 13:20, Colin King wrote:
> From: Colin Ian King
>
> There is a spelling mistake in a pr_err message. Fix it.
>
> Signed-off-by: Colin Ian King
> ---
> drivers/gpu/drm/omapdrm/dss/venc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/omap
From: Tom Rix
Clang static analysis reports this representative error
init.c:2501:18: warning: Array access (from variable 'queuedata') results
in a null pointer dereference
templ |= ((queuedata[i] & 0xc0) << 3);
This is the problem block of code
if(ModeNo > 0x13) {
...
To make sure that the MCDE is in a reasonable state during
set-up, perform a reset by power cycling the block by dropping
the on-chip regulator reference after probe. The display
subsystem (DSS) has no dedicated reset line so dropping
the EPOD regulator is the only real way of resetting it.
We int
Hi Oleksandr,
I love your patch! Perhaps something to improve:
[auto build test WARNING on drm-exynos/exynos-drm-next]
[also build test WARNING on drm-intel/for-linux-next
tegra-drm/drm/tegra/for-next drm-tip/drm-tip linus/master v5.8 next-20200804]
[cannot apply to xen-tip/linux-next drm/drm-ne
The driver was relying on only prepare()/unprepare() to
enable/disable the display.
This does not work because prepare() will be called
before the DSI host/bridge is ready to send any DSI
commands and disable() will be called after the DSI
host/bridge is disabled and thus unable to send any
DSI co
On 7/28/2020 3:04 AM, Daniel Vetter wrote:
On Mon, Jul 27, 2020 at 2:27 PM Michel Dänzer wrote:
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa677
On 7/27/2020 5:57 PM, Michel Dänzer wrote:
On 2020-07-25 1:26 a.m., Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 1fa67700d8f4..95953b393941 100644
--- a/drivers/gpu/drm/i915/i
Virtgpu is modern-only. Use LE accessors for config space.
Signed-off-by: Michael S. Tsirkin
---
drivers/gpu/drm/virtio/virtgpu_kms.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/virtio/virtgpu_kms.c
b/drivers/gpu/drm/virtio/virtgpu_kms.c
On 7/25/2020 4:56 AM, Paulo Zanoni wrote:
Em seg, 2020-07-20 às 17:01 +0530, Karthik B S escreveu:
Add enable/disable flip done functions and the flip done handler
function which handles the flip done interrupt.
Enable the flip done interrupt in IER.
Enable flip done function is called befor
Since gpu is a modern-only device,
tag config space fields as having little endian-ness.
Signed-off-by: Michael S. Tsirkin
Reviewed-by: Cornelia Huck
---
include/uapi/linux/virtio_gpu.h | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/include/uapi/linux/virtio_gpu.h b
From: Colin Ian King
There a handful of spelling mistakes. fix them.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/gma500/mdfld_dsi_output.c | 4 ++--
drivers/gpu/drm/gma500/psb_intel_sdvo.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/gma500/mdf
From: Colin Ian King
There is a spelling mistake in a dev_warn message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_device.c
b/drivers/gpu/drm/amd/amd
Forget what I wrote the -ENOMEM was a type in my local change :)
Sorry for the noise,
Christian.
Am 05.08.20 um 13:55 schrieb Christian König:
Dave, do you have a branch with the latest version somewhere?
I've tested your ttm-refactor-mem-manager branch from fdo today a bit
and that pretty qu
Dave, do you have a branch with the latest version somewhere?
I've tested your ttm-refactor-mem-manager branch from fdo today a bit
and that pretty quickly results in an -ENOMEM.
Looks like a leak somewhere to me.
Christian.
Am 04.08.20 um 04:55 schrieb Dave Airlie:
I've decided to repost t
I don't think we have a uniform mechanism, currently each driver
decides on their own.
For the amdgpu driver we check that the process either has
CAP_SYS_NICE or is the DRM master.
On Wed, Aug 5, 2020 at 9:14 AM Yiwei Zhang wrote:
>
> Hi friends,
>
> For Vulkan/EGL, upon creating gpu contexts, a
From: Colin Ian King
There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_psp.c
b/drivers/gpu/drm/amd/amdgpu/a
From: Colin Ian King
There is a spelling mistake in a DRM_ERROR message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_execbuf.c
b/drivers/gpu/drm/vmwgfx/vmwgf
From: David Woodhouse
This isn't needed in dtsi files.
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623a.dtsi | 1 -
1 file changed, 1 deletion(-)
diff --git a/arch/arm/boot/dts/mt7623a.dtsi b/arch/arm/boot/dts/mt7623a.dtsi
index 0735a1fb8ad9..a96075206cce 100644
--- a/arch/arm/boo
From: David Woodhouse
Based on a patch in OpenWrt from Kristian Evensen
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/Makefile| 1 +
.../boot/dts/mt7623a-unielec-u7623-emmc.dts | 347 ++
2 files changed, 348 insertions(+)
create mode 100644 arch
From: David Woodhouse
The MT7623A doesn't have a GPU; add it only for MT7623N boards.
Fixes: 1f6ed224594 ("arm: dts: mt7623: add Mali-450 device node")
Signed-off-by: David Woodhouse
---
arch/arm/boot/dts/mt7623.dtsi | 24 -
arch/arm/boot/dts/mt7623n-bananapi-bpi-r2
On Wed, 2020-08-05 at 10:49 +0200, Frank Wunderlich wrote:
> > Gesendet: Mittwoch, 05. August 2020 um 10:36 Uhr
> > Von: "David Woodhouse"
> > > mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> > > mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not
> > > existing yet,
> > >
On Wed, Aug 05, 2020 at 06:03:15PM +0800, Huang Jiachai wrote:
> Hi Daniel
>
> 在 2020/8/5 17:36, Daniel Vetter 写道:
> > On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
> > > add this node to get the current true mode.
> > >
> > > Signed-off-by: Sandy Huang
> > Uh what's this for? Since it's s
From: Colin Ian King
There is a spelling mistake in the function name ion_dma_buf_detatch.
Fix it by removing the extraneous t.
Signed-off-by: Colin Ian King
---
drivers/staging/android/ion/ion.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/staging/android/
On 8/4/20 9:11 AM, Jürgen Groß wrote:
> On 31.07.20 14:51, Oleksandr Andrushchenko wrote:
>> From: Oleksandr Andrushchenko
>>
>> It is possible that the scatter-gather table during dmabuf import has
>> non-zero offset of the data, but user-space doesn't expect that.
>> Fix this by failing the imp
On Tue, Aug 04, 2020 at 02:09:13AM +0100, Al Viro wrote:
> On Mon, Aug 03, 2020 at 11:28:31PM +0100, Al Viro wrote:
>
> > IOW, what the hell is that horror for? You do realize, for example, that
> > there's
> > such thing as dup(), right? And dup2() as well. And while we are at it,
> > how
>
On Wed, Aug 5, 2020 at 12:13 PM Mauro Carvalho Chehab
wrote:
>
> Em Wed, 5 Aug 2020 11:34:54 +0200
> Daniel Vetter escreveu:
>
> > On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
> > wrote:
> > >
> > > Hi,
> > >
> > > I've been working to get upstream support for the DRM driver on HiKey 97
Should say [PATCH v2 0/4] instead
Am 05.08.20 um 12:54 schrieb Thomas Zimmermann:
> Since converting the ast driver to atomic modesettting, modesetting
> occationally locks up the graphics hardware and turns the display
> permanently dark. This happens once or twice per 10 mode switches.
> Investi
Duplicates drm_atomic_helper_commit_tail(), so that planes can be
disabled on full mode-setting changes.
Signed-off-by: Thomas Zimmermann
Fixes: 4961eb60f145 ("drm/ast: Enable atomic modesetting")
Cc: Thomas Zimmermann
Cc: Gerd Hoffmann
Cc: Dave Airlie
Cc: Daniel Vetter
Cc: Sam Ravnborg
Cc:
The ast HW cursor requires the primary plane and CRTC to display at
a valid mode and format. This is not the case while switching
display modes, which can lead to the screen turing permanently dark.
As a workaround, the ast driver now disables active planes while the
mode or format switch takes pl
Move the mode-setting code from atomic_flush() to atomic_begin(), and
thus before the plane update. With the CRTC update before the plane
updates, the cursor can be disabled while the mode is being changed.
The patch removes the call ast_open_key() from atomic_begin(), The
function unlocks ast's e
The atomic modesetting code tried to distinguish format changes from
full modesetting operations. But the implementation was buggy and the
format registers were often updated even for simple pageflips.
Fix this problem by distinguishing between format and mode changes; and
handle each in it's own
Since converting the ast driver to atomic modesettting, modesetting
occationally locks up the graphics hardware and turns the display
permanently dark. This happens once or twice per 10 mode switches.
Investigation shows that the ast hardware presumably requires the HW
cursor to be disabled while t
From: Colin Ian King
There is a spelling mistake in a pr_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/video/fbdev/omap2/omapfb/dss/venc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/fbdev/omap2/omapfb/dss/venc.c
b/drivers/video/fbdev/oma
From: Colin Ian King
There is a spelling mistake in a pr_err message. Fix it.
Signed-off-by: Colin Ian King
---
drivers/gpu/drm/omapdrm/dss/venc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/omapdrm/dss/venc.c
b/drivers/gpu/drm/omapdrm/dss/venc.c
index
Em Wed, 5 Aug 2020 11:34:54 +0200
Daniel Vetter escreveu:
> On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
> wrote:
> >
> > Hi,
> >
> > I've been working to get upstream support for the DRM driver on HiKey 970.
> >
> > While the patches are not ready yet for upstream merge, I'm placing
>
drm-misc-next-fixes-2020-08-05:
drm-misc-next-fixes for v5.9-rc1:
- Fix drm_dp_mst_port refcount leaks in drm_dp_mst_allocate_vcpi
- Fix a fbcon OOB read in fbdev, found by syzbot.
- Mark vga_tryget static as it's not used elsewhere.
- Small fixes to xlnx.
- Remove null check for kfree in drm_dev_r
On Wed, Aug 5, 2020 at 10:37 AM Sandy Huang wrote:
>
> add this node to get the current true mode.
>
> Signed-off-by: Sandy Huang
Uh what's this for? Since it's sysfs, I guess there's something
parsing this, which means we'd kinda need to have that piece too.
If it's just for debugging purposes
On Wed, Aug 5, 2020 at 10:51 AM Mauro Carvalho Chehab
wrote:
>
> Hi,
>
> I've been working to get upstream support for the DRM driver on HiKey 970.
>
> While the patches are not ready yet for upstream merge, I'm placing
> what I've sone so far on this repository:
>
> https://github.com/mch
On Tue, Aug 04, 2020 at 12:56:22PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 32 +++
> 1 file changed, 18 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/vmwgfx/vmwgfx_gmr
On Tue, Aug 04, 2020 at 12:56:21PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_thp.c | 32 +++--
> 1 file changed, 21 insertions(+), 11 deletions(-)
>
> diff --git a/dri
On Tue, Aug 04, 2020 at 12:56:15PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 23 +++
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 4 ++--
> drivers/gpu/
On Tue, Aug 04, 2020 at 12:56:06PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 9 -
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 1 +
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c | 11
On Tue, Aug 04, 2020 at 12:56:01PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Don't bother returning EBUSY, nobody cares enough,
> if the driver has a problem, it should deal with it.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 14 +-
> drive
On Tue, Aug 04, 2020 at 12:56:29PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> This converts vmwgfx over to using an interface to set the
> in use and check the in use flag.
>
> Signed-off-by: Dave Airlie
Hm, I think this would be a good candidate to eventually rip out once we
have full
On Tue, Aug 04, 2020 at 12:55:54PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 17 ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 2 +-
> drivers/gpu/drm/vmwgfx/vmwgfx_gmrid_manager.c |
On Tue, Aug 04, 2020 at 12:55:53PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> Split out the vram thp init path vs the range manager init.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.c | 25 +++--
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h | 4
Hi,
I've been working to get upstream support for the DRM driver on HiKey 970.
While the patches are not ready yet for upstream merge, I'm placing
what I've sone so far on this repository:
https://github.com/mchehab/linux/tree/hikey970/to_upstream-2.0-v1.1
The drivers there are a port f
On Wed, 2020-08-05 at 09:27 +0200, Frank Wunderlich wrote:
> or should we split dtsi to have a common part (mt7623.dtsi), and one for
> soc (mt7623n.dtsi/mt7623a.dtsi)?
>
> mt7623.dtsi => mt7623n.dtsi => mt7623n-bananapi-bpi-r2.dts
> mt7623.dtsi => mt7623a.dtsi => mt7623a-unielec-u7623.dts (not ex
On Tue, Aug 04, 2020 at 12:55:35PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> The map one was used once, just inline it, and drop them both.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 2 -
> drivers/gpu/drm/vmwgfx/vmwgfx_ttm_buffer.c | 46 +++---
On Tue, Aug 04, 2020 at 12:55:34PM +1000, Dave Airlie wrote:
> From: Dave Airlie
>
> These two functions has the same code in them, create a common
> helper function instead.
>
> Signed-off-by: Dave Airlie
> ---
> drivers/gpu/drm/vmwgfx/vmwgfx_drv.h| 4 ++
> drivers/gpu/drm/vmwgfx/vmw
On Tue, Aug 04, 2020 at 11:31:17PM +0200, Bas Nieuwenhuizen wrote:
> This sets the DC tiling options from the modifier, if modifiers
> are used for the FB. This patch by itself does not expose the
> support yet though.
>
> There is not much validation yet to limit the scope of this
> patch, but th
On Tue, Aug 04, 2020 at 11:31:14PM +0200, Bas Nieuwenhuizen wrote:
> With modifiers I'd like to support non-dedicated buffers for
> images.
>
> Signed-off-by: Bas Nieuwenhuizen
Uh, I think it'd be really good to preceed this with a bugfix (cc: stable)
which checks that the offset is 0). And then
On Tue, Aug 04, 2020 at 09:56:00PM +0200, Sam Ravnborg wrote:
> Hi Daniel et al.
> On Tue, Aug 04, 2020 at 06:43:30PM +0200, dan...@ffwll.ch wrote:
> > On Sun, Aug 02, 2020 at 01:06:17PM +0200, Sam Ravnborg wrote:
> > > Add get and set operations to incapsualte access to backlight properties.
> > >
On Fri, Jul 31, 2020 at 08:24:58PM -0700, Dan Williams wrote:
> - Fix test_hmm and other compilation fixups (Ralph)
The hmm parts look OK
Acked-by: Jason Gunthorpe
Jason
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedes
The only usage of dcn20_res_pool_funcs is to assign its address to a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/display/dc/dcn20/dcn20_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
> Gesendet: Dienstag, 04. August 2020 um 19:24 Uhr
> Von: "David Woodhouse"
> > + mipi_tx0: mipi-dphy@1001 {
> > + compatible = "mediatek,mt7623-mipi-tx",
> > +"mediatek,mt2701-mipi-tx";
> > + reg = <0 0x1001 0 0x90>;
> > + clocks =
From: Frank Wunderlich
This Patch-Series adds missing Patches/Bugfixes to get hdmi working
on BPI-R2
v2->v3:
- use own mmsys-routing for mt7623 instead of code getting different
routing from dts
- remove ddp routing bls -> dpi from bpir2/rfb dts
- updated some commit-Messages as suggested
Hi,
> Gesendet: Dienstag, 04. August 2020 um 16:34 Uhr
> Von: "Chun-Kuang Hu"
> > -static const enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
> > +static enum mtk_ddp_comp_id mt2712_mtk_ddp_main[] = {
>
> Why do you remove 'const'?
was removed by previous patch and not re-added (revert failed)
sorry, send this accidentally while posting my hdmi series v4 (have not deleted
patch-file)
just ignore this...it's already merged
regards Frank
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dr
From: chunhui dai
disable tmds on phy on mt2701 to support other resolutions like 1280x1024
Signed-off-by: chunhui dai
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_hdmi_phy.c| 3 +++
drivers/gpu/drm/mediatek/mtk_hdmi_phy.h| 1 +
A number of static variables are not modified and can be made const to
allow the compiler to put them in read-only memory.
Signed-off-by: Rikard Falkeborn
---
Perhaps it should be split up? If so, some guidance on how would be
appreciated.
drivers/gpu/drm/sun4i/sun4i_backend.c | 2 +-
drive
The only usage of dcn21_res_pool_funcs is to assign its address to a
const pointer. Make it const to allow the compiler to put it in
read-only memory.
Signed-off-by: Rikard Falkeborn
---
drivers/gpu/drm/amd/display/dc/dcn21/dcn21_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
1 - 100 of 121 matches
Mail list logo
