Hi,
i've printed the mtk_comp_id after the modification-loops...
[5.480848] main:
[5.480851] DDP_COMPONENT_OVL0
[5.482776] DDP_COMPONENT_RDMA0
[5.485827] DDP_COMPONENT_COLOR0
[5.488978] DDP_COMPONENT_BLS
[5.492206] DDP_COMPONENT_DPI0
[5.495170] ext:
[5.498233] DDP_
> Gesendet: Dienstag, 04. August 2020 um 17:00 Uhr
> Von: "Chun-Kuang Hu"
> > + display_components: dispsys@1400 {
> > + compatible = "mediatek,mt7623-mmsys",
> > +"mediatek,mt2701-mmsys";
>
> In mediatek,mmsys.txt [3], this should be:
>
> mmsys
From: Frank Wunderlich
mt7623 uses mt2701/mt8173 for drm, but have own compatibles
Signed-off-by: Frank Wunderlich
---
.../devicetree/bindings/display/mediatek/mediatek,disp.txt| 2 +-
.../devicetree/bindings/display/mediatek/mediatek,dpi.txt | 2 +-
.../devicetree/bindings/display/med
From: Stu Hsieh
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so search
pipeline information to find out the correct possible crtc.
Signed-off-by: Stu H
From: Stu Hsieh
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so search
pipeline information to find out the correct possible crtc.
Signed-off-by: Stu H
From: Landen Chao
in recent kernel versions there are warnings about incorrect MTU size
like these:
eth0: mtu greater than device maximum
mtk_soc_eth 1b10.ethernet eth0: error -22 setting MTU to include DSA
overhead
Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Fixes
Constify a couple of instances of resource_funcs that are never
modified to allow the compiler to put it in read-only memory.
The other drivers in drivers/gpu/drm/amd/display/dc already have
these as const.
Rikard Falkeborn (3):
drm/amd/display: Constify dcn20_res_pool_funcs
drm/amd/display:
From: Jitao Shi
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so call
mtk_drm_find_possible_crtc_by_comp() to find out the correct possible
crtc.
Signed
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 +
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
changed v2->v3:
drop bls to dpi routing
---
arch/arm/boot/dts/m
From: Frank Wunderlich
on BPi-R2/mt7623 main-path have to be routed to DPI0 (hdmi) instead of DSI0
using compatible "mt7623-mmsys" already defined in dts
Signed-off-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 23 +++
1 file changed, 23 insertions(+)
d
Hi
Except mmsys (i added in Patch #1) all mt7623-compatibles are not defined in
code and fallback (mt2701-x/mt8173-x) is used. If i add it in dt-binding, it
should be added in code too, right? or should i remove mt7623 compatibles and
only add documentation for new mmsys?
regards Frank
> Ges
On Tue, Aug 04, 2020 at 03:44:51PM +, Kalesh Singh wrote:
> Hi Al. Thank you for the comments. Ultimately what we need is to identify
> processes
> that hold a file reference to the dma-buf. Unfortunately we can't use only
> explicit dma_buf_get/dma_buf_put to track them because when an FD is
DPU resources reserved in the atomic_check path gets unwinded
during modeset operation before commit happens in a non seamless
transition.
Update the reservations in the commit path to avoid resource
failures. Secondly have dummy reservations in atomic_check path
so that we can gracefully fail the
From: Ryder Lee
Add display subsystem related device nodes for MT7623.
Cc: CK Hu
Signed-off-by: chunhui dai
Signed-off-by: Bibby Hsieh
Signed-off-by: Ryder Lee
Signed-off-by: Frank Wunderlich
Tested-by: Frank Wunderlich
---
changed
v3->v4:
drop display_components which is duplicate of ex
CC Rob Herring and devicetree-list
> Gesendet: Dienstag, 04. August 2020 um 18:55 Uhr
> Von: "Frank Wunderlich"
> An: linux-media...@lists.infradead.org
> Cc: "Frank Wunderlich" , "Chun-Kuang Hu"
> , "Philipp Zabel" , "David
> Airlie" , "Daniel Vetter" , "Matthias
> Brugger" , dri-devel@lists.
From: Jitao Shi
For current mediatek dsi encoder, its possible crtc is fixed in crtc
0, and mediatek dpi encoder's possible crtc is fixed in crtc 1. In
some SoC the possible crtc is not fixed in this case, so call
mtk_drm_find_possible_crtc_by_comp() to find out the correct possible
crtc.
Signed
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(-)
Do you think this approach is acceptable? Or, do we need to modify set_origin()
?
On 2020/07/29 23:57, Tetsuo Handa wrote:
> syzbot is reporting UAF bug in set_origin() from vc_do_resize() [1], for
> vc_do_resize() calls kfree(vc->vc_screenbuf) before calling set_origin().
>
> Unfortunately, in
From: Frank Wunderlich
on BPi-R2/mt7623 main-path have to be routed to DPI0 (hdmi) instead of DSI0
using compatible "mt7623-mmsys" already defined in dts
Signed-off-by: Frank Wunderlich
---
drivers/gpu/drm/mediatek/mtk_drm_drv.c | 25 -
1 file changed, 24 insertions(+),
The only usage of dcn30_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/dcn30/dcn30_resource.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
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
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
From: Frank Wunderlich
This Patch-Series adds missing Patches/Bugfixes to get hdmi working
on BPI-R2
v3->v4:
- fix removed const in "add ddp routing for mt7623"
- change subjects to "drm/mediatek:..."
- add documentation for mt7623-* compatibles
- dropped redundant display_components node (m
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 +
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 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 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 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 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 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
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 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
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: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: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: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: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: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: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 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 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
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
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
>
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
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
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
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
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
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
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
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
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 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
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 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
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,
> > >
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
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
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: 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: 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
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
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
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
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
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
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
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
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/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
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
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
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
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
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) {
...
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Status|NEW |RESOLVED
Kernel Versi
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=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.
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 #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
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 #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
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
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 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/
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 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
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
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/
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,
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
1 - 100 of 121 matches
Mail list logo
