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
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
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 +-
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
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
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
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
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: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: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: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 ++--
>
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
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 +-
>
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: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
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
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")
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.
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
---
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(+)
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
>
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
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
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
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" ,
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.
> 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:
>
>
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 +-
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
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
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]
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 ++
>
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 |
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
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
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.
> >
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
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
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
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
---
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.
> 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
>
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 +++--
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
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
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
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
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
---
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
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
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
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
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 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
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
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 -
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
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,
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
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) {
...
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
>
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.
>
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
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
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:
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
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
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,
> > >
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
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
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:
>
>
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
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
>
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
---
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
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
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
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
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
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
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
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
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
https://bugzilla.kernel.org/show_bug.cgi?id=207383
Duncan (1i5t5.dun...@cox.net) changed:
What|Removed |Added
Status|NEW |RESOLVED
Kernel
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:
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
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 #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.
___
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.
>
>
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]
> 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
1 - 100 of 120 matches
Mail list logo
