Re: [PATCH] [DRM][KMS][MODE][MEDIATEK] Using the function drm_display_mode_to_videomode

Hi, Satendra: I've applied this patch to my branch mediatek-drm-next-4.18, and I've added below modification in this patch to prevent build error, diff --git a/drivers/gpu/drm/mediatek/Kconfig b/drivers/gpu/drm/mediatek/Kconfig index 294de45..119ec0a 100644 --- a/drivers/gpu/drm/mediatek/Kconfig

[Bug 104888] DPMS issue w/ GFX8/Polaris10/Ellesmere/Rx-480-8GiB & agd5f's drm-next-4.17-wip

https://bugs.freedesktop.org/show_bug.cgi?id=104888 Robin Kauffman changed: What|Removed |Added Resolution|--- |WORKSFORME

[Bug 105684] Loading amdgpu hits general protection fault: 0000 [#1] SMP NOPTI

https://bugs.freedesktop.org/show_bug.cgi?id=105684 --- Comment #17 from jian-h...@endlessm.com --- Created attachment 139117 --> https://bugs.freedesktop.org/attachment.cgi?id=139117=edit dmesg of loading amdgpu module - tested in 4.17-rc2 I have tried Linux kernel 4.17-rc2 and load amdgpu

Re: [PATCH 0/4] qxl: multihead fixes, cleanups

On 16 February 2018 at 23:28, Gerd Hoffmann wrote: > > > Gerd Hoffmann (4): > qxl: remove qxl_io_log() > qxl: move qxl_send_monitors_config() > qxl: hook monitors_config updates into crtc, not encoder. > qxl: drop dummy functions Reviewed-by: Dave Airlie

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #53 from MirceaKitsune --- (In reply to iive from comment #52) Ah... I do indeed have apitrace 7.1-3.89. I don't know if a newer version exists on https://software.opensuse.org which is

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #52 from i...@yahoo.com --- (In reply to MirceaKitsune from comment #51) > Created attachment 139103 [details] > Output of: systemctl | grep running > > (In reply to iive from comment #50) > > I've preformed many more tests during

Re: [[RFC]DPU PATCH 2/4] dt-bindings: drm/bridge: Document sn65dsi86 bridge bindings

On Wed, Apr 25, 2018 at 7:45 PM, Stephen Boyd wrote: > Quoting Sandeep Panda (2018-04-19 10:56:06) >> Document the bindings used for the sn65dsi86 DSI to eDP bridge. >> >> Changes in v1: >> - Rephrase the dt-binding descriptions to be more inline with existing >>bindings

Re: [PATCH libdrm] intel: add support for ICL 11

On 04/25/2018 05:09 PM, Paulo Zanoni wrote: Add the PCI IDs and the basic code to enable ICL. This is the current PCI ID list in our documentation. Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs") v2: Michel provided a fix to IS_9XX that was broken by rebase bot. v3: Fix

[PATCH libdrm] intel: add support for ICL 11

Add the PCI IDs and the basic code to enable ICL. This is the current PCI ID list in our documentation. Kernel commit: d55cb4fa2cf0 ("drm/i915/icl: Add the ICL PCI IDs") v2: Michel provided a fix to IS_9XX that was broken by rebase bot. v3: Fix double definition of PCI IDs, update IDs according

[Bug 105284] Every boot I get an error in dmesg "WARNING: CPU: 2 PID: 1380 at drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:132 generic_reg_update_ex+0x108/0x150 [amdgpu]"

https://bugs.freedesktop.org/show_bug.cgi?id=105284 --- Comment #7 from Jon --- (In reply to Harry Wentland from comment #6) > Marking resolved as no longer an issue on recent mainline. Which commit fixes this? I merged in agd5f/drm-fixes-4.17 into linus master: Merge:

Re: [PATCH 1/5] dma-buf: use parameter structure for dma_buf_attach

Hi Christian, I love your patch! Yet something to improve: [auto build test ERROR on drm/drm-next] [also build test ERROR on v4.17-rc2 next-20180424] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url:

Re: [PATCH] drm: udl: Destroy framebuffer only if it was initialized

On Tue, Apr 24, 2018 at 6:04 AM, Daniel Vetter wrote: > On Fri, Apr 20, 2018 at 09:55:32AM -0400, Sean Paul wrote: >> On Fri, Apr 20, 2018 at 01:50:01PM +0200, Emil Lundmark wrote: >> > This fixes a NULL pointer dereference that can happen if the UDL >> > driver is unloaded

[Bug 106225] Kernel panic after modesetting (not on every boot) on ryzen 5 2400g

https://bugs.freedesktop.org/show_bug.cgi?id=106225 Francisco Pina Martins changed: What|Removed |Added Attachment #139081|0 |1

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Rob, On Wednesday, 25 April 2018 20:11:23 EEST Rob Herring wrote: > On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: > >> On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > >>> On Wednesday, 25 April 2018

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 5:33 PM, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: >> > Coordinating the backport of a trivial helper in the arm tree is not >> > the end of the world. Really, this cowboy attitude is a good reason >> >

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #13 from Alex Deucher --- Try the patches from this branch: https://cgit.freedesktop.org/~agd5f/linux/log/?h=drm-fixes-4.17 -- You are receiving this mail because: You are the assignee for the

[Bug 199425] BUG: KASAN: use-after-free in drm_atomic_helper_wait_for_flip_done+0x247/0x260

https://bugzilla.kernel.org/show_bug.cgi?id=199425 --- Comment #1 from Johannes Hirte (johannes.hi...@datenkhaos.de) --- (gdb) list *(drm_atomic_helper_wait_for_flip_done+0x247) 0x82043447 is in drm_atomic_helper_wait_for_flip_done (drivers/gpu/drm/drm_atomic_helper.c:1381). 1376

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #12 from Joel Sass --- Created attachment 139112 --> https://bugs.freedesktop.org/attachment.cgi?id=139112=edit The modified file causing the problem in my comment. Looks like there's some missing

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #11 from Joel Sass --- It appears that the patch I manually created isn't working out so hot. During compiling, I'm seeing this error for amdgpu_dm_mst_types.c

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

https://bugs.freedesktop.org/show_bug.cgi?id=104082 ojab changed: What|Removed |Added CC||o...@ojab.ru --- Comment #44 from

[Bug 104082] amdgpu 0000:07:00.0: swiotlb buffer is full (sz: 2097152 bytes)

https://bugs.freedesktop.org/show_bug.cgi?id=104082 --- Comment #43 from ojab --- Same here on ryzen 2400g + asus a320m-k w/ iommu disabled, vanilla kernel 4.16.4. I'm not sure if it's another issue since it happens on driver loading and backtrace looks like: [Wed Apr 25 20:18:50

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Maxime, Il 25/04/2018 20:40, Maxime Ripard ha scritto: Hi Giulio, On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: LiNova1 is not a board with various headers to connect other peripherals such display, pcap etc. It's an HMI that I would consider the same as a Tablet, because

[PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On 25/04/18 02:25, Russell King - ARM Linux wrote: > On Tue, Apr 24, 2018 at 09:25:44PM +0300, Jyri Sarha wrote: >> On 24/04/18 20:06, Russell King - ARM Linux wrote: >>> On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: On 24/04/18 13:14, Peter Rosin wrote: > On 2018-04-24

Re: [PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > For the same reasons we've added dri-devel for all fbdev patches: Most > of the actively developed drivers using this infrastructure are in > drivers/gpu/. It just makes sense to cross-post patches and keep > aligned. And total

Re: [PATCH 1/6] backlight: Nuke unused backlight.props.state states

On Wednesday, April 25, 2018 1:43 PM, Daniel Vetter wrote: > > The backlight power state handling is supremely confusing. We have: > - props.power, using FB_BLANK_* defines > - props.fb_blank, using the same, but deprecated int favour of > props.state > - props.state, using the BL_CORE_*

[PULL] drm-misc-fixes

Hi Dave, Here's the latest from -misc-fixes. Of note, no nasty backmerges as per the thread on dim-tools. We have one regression fix, and two stable fixes, and a couple of regular fixes for your consideration. drm-misc-fixes-2018-04-25: sun41: Fix regression for TBSA711 tablet (Ondrej) qxl: 2

[Bug 54060] X11 crash, kernel panic, ttm_bo_mem_put

https://bugs.freedesktop.org/show_bug.cgi?id=54060 Öyvind Saether changed: What|Removed |Added Resolution|--- |FIXED

Re: [pull] drm/msm: fixes for 4.17

On Wed, Apr 25, 2018 at 2:55 PM, Rob Clark wrote: > Hi Dave, > > A few fixes for 4.17.. thanks to Sean for helping pull together some > of the display related fixes while I was off in compute-land. > > The following changes since commit

[pull] drm/msm: fixes for 4.17

Hi Dave, A few fixes for 4.17.. thanks to Sean for helping pull together some of the display related fixes while I was off in compute-land. The following changes since commit a10beabba213924d876f2d10ca9351aeab93f58a: Merge branch 'drm-next-4.17' of git://people.freedesktop.org/~agd5f/linux

Re: [PATCH 7/7] ARM: dts: sun7i: Add dts file for the A20-linova1-7 HMI

Hi Giulio, On Tue, Apr 24, 2018 at 08:31:44PM +0200, Giulio Benetti wrote: > LiNova1 is not a board with various headers to connect other peripherals > such display, pcap etc. > It's an HMI that I would consider the same as a Tablet, because it has a > plastic enclosure also. > > So I would like

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 10:44 AM, Alex Deucher wrote: > On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: >> On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >>> > It has a non-coherent transaction mode (which the chipset can opt to

Re: [Linaro-mm-sig] [PATCH 4/8] dma-buf: add peer2peer flag

On Wed, Apr 25, 2018 at 2:41 AM, Christoph Hellwig wrote: > On Wed, Apr 25, 2018 at 02:24:36AM -0400, Alex Deucher wrote: >> > It has a non-coherent transaction mode (which the chipset can opt to >> > not implement and still flush), to make sure the AGP horror show >> >

[PATCH 2/6] backlight/generic-bl: remove DRIVER1 state

Nothing in the entire tree ever sets this, which means this is dead code. Remove it. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han Acked-by: Daniel Thompson Signed-off-by: Daniel Vetter

[PATCH 6/6] MAINTAINERS: add dri-devel for backlight subsystem patches

For the same reasons we've added dri-devel for all fbdev patches: Most of the actively developed drivers using this infrastructure are in drivers/gpu/. It just makes sense to cross-post patches and keep aligned. And total activity in the backlight subsystem is miniscule compared to drm overall.

[PATCH 3/6] backlight/pandora: Stop using BL_CORE_DRIVER1

Leaking driver internal tracking into the already massively confusing backlight power tracking is really confusing. Stop that by allocating a tiny driver private data structure instead. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han

[PATCH 5/6] backlight: Also nuke BL_CORE_DRIVER1

Now that the 3 drivers using this are cleaned up we can also remove this final bit of confusion of leaking driver internals into the backlight power interface. The backlight power interface itself is still a massive mess. Cc: Lee Jones Cc: Daniel Thompson

[PATCH 4/6] staging/fbtft: Stop using BL_CORE_DRIVER1

Leaking driver internal tracking into the already massively confusing backlight power tracking is really confusing. Luckily we have already a drvdata structure, so fixing this is really easy. Cc: Lee Jones Cc: Daniel Thompson Cc: Jingoo Han

[PATCH 1/6] backlight: Nuke unused backlight.props.state states

The backlight power state handling is supremely confusing. We have: - props.power, using FB_BLANK_* defines - props.fb_blank, using the same, but deprecated int favour of props.state - props.state, using the BL_CORE_* defines - and finally a bunch of backlight drivers treat brightness == 0 as

Re: [Xen-devel] [PATCH 0/1] drm/xen-zcopy: Add Xen zero-copy helper DRM driver

On Wed, Apr 25, 2018 at 08:34:55AM +0200, Daniel Vetter wrote: > On Wed, Apr 25, 2018 at 09:07:07AM +0300, Oleksandr Andrushchenko wrote: > > On 04/24/2018 11:35 PM, Dongwon Kim wrote: > > > Had a meeting with Daniel and talked about bringing out generic > > > part of hyper-dmabuf to the

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

On Wed, Apr 25, 2018 at 04:17:25PM +0300, Laurent Pinchart wrote: > Hi Philippe, > > On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: > > On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > > > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote: > > >> Add optional power

[pull] amdgpu drm-fixes-4.17

Hi Dave, A few fixes for 4.17: - Fix a hang on CZ boards with EDC enabled - Fix hangs related to DP MST handling - Fix a deadlock in irq handling in DC The following changes since commit 221bda4b5f1abfd74159d7bf3703affa62468030: Merge branch 'drm-next-4.17' of

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 11:29 AM, Eric W. Biederman wrote: Another issue is changing wait_event_killable to wait_event_timeout where I need to understand what TO value is acceptable for all the drivers using the scheduler, or maybe it should come as a property of drm_sched_entity. It would not surprise

Re: [PATCH] drm/todo: Fallout from v3d review

Daniel Vetter writes: > Bunch of ideas from Eric and me on what we could do to make gem gpu > rendering drivers a notch simpler to type. > > Cc: Eric Anholt > Signed-off-by: Daniel Vetter > diff --git

[Bug 199493] no audio over HDMI with amdgpu.dc=1 (on R9 380X)

https://bugzilla.kernel.org/show_bug.cgi?id=199493 --- Comment #1 from har...@gmx.de --- Created attachment 275577 --> https://bugzilla.kernel.org/attachment.cgi?id=275577=edit related part of dmesg, with amdgpu.dc=1 there are some warnings followed by callstacks in dmesg, maybe this is

Re: [PATCH] drm/amdkfd: Integer overflows in ioctl

On 2018-04-25 05:21 AM, Dan Carpenter wrote: > On Tue, Apr 24, 2018 at 02:58:10PM -0400, Felix Kuehling wrote: >> Reviewed-by: Felix Kuehling >> >> We could probably add a sanity check for n_devices to avoid user mode >> causing excessive memory allocations in the kernel.

Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info

Hi all, The patch works: drivers/gpu/drm/drm_edid.c I switch 4K@60 and 4K@30 monitors some times, monitors show correct output. Thanks for your help. What are the steps to close the issue in freedesktop? Append the patch by Ville Syrjälä, then I close it? Antony 2018-04-25 3:36 GMT+08:00

[PATCH] dt-bindings: panel: lvds: Fix path to display timing bindings

Fixes: 14da3ed8dd08c581 ("devicetree/bindings: display: Document common panel properties") Signed-off-by: Geert Uytterhoeven --- Documentation/devicetree/bindings/display/panel/panel-common.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

Re: DRI3 WSEGL plugin for TI SGX

Hi! On 16/04/18 16:49, Tomi Valkeinen wrote: > Hi All, > > I have implemented a WSEGL plugin library for Imagination's PVR driver > for SGX, which allows using SGX via DRI3. In other words, it is one > piece in the puzzle of using SGX with X11. > > The project is not production quality, as I

Re: [PATCH v4 7/8] drm/i2c: tda998x: register as a drm bridge

On 2018-04-24 19:06, Russell King - ARM Linux wrote: > On Tue, Apr 24, 2018 at 07:04:16PM +0300, Jyri Sarha wrote: >> On 24/04/18 13:14, Peter Rosin wrote: >>> On 2018-04-24 10:08, Russell King - ARM Linux wrote: On Tue, Apr 24, 2018 at 08:58:42AM +0200, Peter Rosin wrote: > On 2018-04-23

Re: [PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

On Wed, Apr 25, 2018 at 12:10:51PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can > not opt into but have to explicitly opt out of. This can lead to subtle > bugs that are difficult to track down

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

Andrey Grodzovsky writes: > On 04/25/2018 03:14 AM, Daniel Vetter wrote: >> On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote: >>> >>> On 04/24/2018 05:21 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: >

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #8 from Harry Wentland --- Hi Joel, does the patch fix the issue? Thanks for your bug report and testing. Harry -- You are receiving this mail because: You are the assignee for the

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 12:04:29PM +0200, Daniel Vetter wrote: > > Coordinating the backport of a trivial helper in the arm tree is not > > the end of the world. Really, this cowboy attitude is a good reason > > why graphics folks have such a bad rep. You keep poking into random > > kernel

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

https://bugs.freedesktop.org/show_bug.cgi?id=104412 Harry Wentland changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

On Wed, Apr 25, 2018 at 12:10:47PM +0200, Thierry Reding wrote: > From: Thierry Reding > > Depending on the kernel configuration, early ARM architecture setup code > may have attached the GPU to a DMA/IOMMU mapping that transparently uses > the IOMMU to back the DMA API.

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

https://bugs.freedesktop.org/show_bug.cgi?id=105425 --- Comment #51 from MirceaKitsune --- Created attachment 139103 --> https://bugs.freedesktop.org/attachment.cgi?id=139103=edit Output of: systemctl | grep running (In reply to iive from comment #50)

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #6 from Joel Sass --- Harry, as I had mentioned here https://bugs.freedesktop.org/show_bug.cgi?id=106159 I had to manually apply the patches you'd given me, so I'm including the diff here as well. This has both

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #7 from Joel Sass --- Created attachment 139102 --> https://bugs.freedesktop.org/attachment.cgi?id=139102=edit amdgpu_dm.c patch I had to manually apply -- You are receiving this mail because: You are the

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #10 from Joel Sass --- Created attachment 139101 --> https://bugs.freedesktop.org/attachment.cgi?id=139101=edit amdgpu_dm_mst_types.c patch I had to manually apply -- You are receiving this mail because: You

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #9 from Joel Sass --- Created attachment 139100 --> https://bugs.freedesktop.org/attachment.cgi?id=139100=edit amdgpu_dm.c patch I had to manually apply -- You are receiving this mail because: You are the

[Bug 106159] When connecting or disconnecting a displayport to a DP hub with 4.16.2+ kernel, hard freeze with frozen video output

https://bugs.freedesktop.org/show_bug.cgi?id=106159 --- Comment #8 from Joel Sass --- Alright! First, I appreciate the help with this. I decided to just roll with what I was being given and roll the kernel after applying the patches you'd recommended. I downloaded the

Re: [PATCH v2 3/5] ARM: dma-mapping: Implement arch_iommu_detach_device()

> +void arch_iommu_detach_device(struct device *dev) > +{ > +#ifdef CONFIG_ARM_DMA_USE_IOMMU > + struct dma_iommu_mapping *mapping = to_dma_iommu_mapping(dev); > + const struct dma_map_ops *dma_ops; > + > + if (!mapping) > + return; > + > +

Re: [PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

On Wed, Apr 25, 2018 at 12:10:48PM +0200, Thierry Reding wrote: > From: Thierry Reding > > The dma_iommu_detach_device() API can be used by drivers to forcibly > detach a device from an IOMMU that architecture code might have attached > to. This is useful for drivers that

Re: [PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

The series seems to miss a cover letter. Also I really think this patch original patch shouldn't be in the proper series. ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

On Wed, Apr 25, 2018 at 11:25:11AM +0100, Russell King - ARM Linux wrote: > > config ARM_DMA_USE_IOMMU > > - bool > > + def_bool y > > select ARM_HAS_SG_CHAIN > > select NEED_SG_DMA_LENGTH > > This doesn't work - as has recently been discussed with hch, we can't > globally enable

[Bug 106193] When positioning a monitor output above or below initial configuration with xrandr, hard freeze with graphics artifacts 4.16.2+

https://bugs.freedesktop.org/show_bug.cgi?id=106193 --- Comment #5 from Harry Wentland --- I recommend using drm-next-4.18-wip from Alex's tree: https://cgit.freedesktop.org/~agd5f/linux/?h=amd-staging-drm-next git clone git://people.freedesktop.org/~agd5f/linux cd linux

[Bug 103277] [bisected] Systems hangs on resume from S3 sleep due to "Match actual state during S3 resume" commit

https://bugs.freedesktop.org/show_bug.cgi?id=103277 --- Comment #24 from Harry Wentland --- Thanks for testing Jerry's patches. We tried reproducing this issue many times but never thought to try MST. Those two patches are going into 4.17 and 4.18. -- You are receiving

Re: [[RFC]DPU PATCH 4/4] dt-bindings: Add Innolux TV123WAM panel bindings

On Tue, Apr 24, 2018 at 9:16 PM, wrote: > On 2018-04-24 20:13, Rob Herring wrote: >> >> On Wed, Apr 18, 2018 at 05:50:02PM +0530, Sandeep Panda wrote: >>> >>> The Innolux TV123WAM is a 12.3" eDP display panel >>> with 2160x1440 resolution. >> >> >> Why don't you just

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25, Daniel Vetter wrote: > > On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote: > > On 04/24, Daniel Vetter wrote: > >> > >> wait_event_killabel doesn't check for fatal_signal_pending before calling > >> schedule, so definitely has a nice race there. > > > > This is

Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info

On Wed, Apr 25, 2018 at 07:03:14PM +0800, Antony Chen wrote: > Hi all, > > The patch works: drivers/gpu/drm/drm_edid.c > I switch 4K@60 and 4K@30 monitors some times, monitors show correct output. > Thanks for your help. > > What are the steps to close the issue in freedesktop? Append the patch

Re: [Intel-gfx] [PATCH] drm/edid: Reset more of the display info

On Tue, Apr 24, 2018 at 09:36:29PM +0200, Daniel Vetter wrote: > On Tue, Apr 24, 2018 at 05:26:30PM +0300, Ville Syrjälä wrote: > > On Tue, Apr 24, 2018 at 04:18:37PM +0200, Daniel Vetter wrote: > > > On Tue, Apr 24, 2018 at 04:02:50PM +0300, Ville Syrjala wrote: > > > > From: Ville Syrjälä

Re: [PATCH] drm: rcar-du: Use drm_dev_put

Hi Vaishali, On Wednesday, 25 April 2018 16:42:59 EEST Vaishali Thakkar wrote: > On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote: > >> As specified in drm_drv.c, drm_dev_unref is a compatibility alias > >> for

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24/2018 05:40 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:02:40PM -0400, Andrey Grodzovsky wrote: On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:46:52PM +0200, Michel Dänzer wrote: Adding the dri-devel list, since this is driver independent code. On

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

On Wed, Apr 25, 2018 at 01:27:20PM +0100, Emil Velikov wrote: > On 24 April 2018 at 20:14, Daniel Vetter wrote: > > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov > > wrote: > >> On 13 April 2018 at 11:00, Daniel Vetter

Re: [PATCH] drm: rcar-du: Use drm_dev_put

On Wed, Apr 25, 2018 at 7:02 PM, Laurent Pinchart wrote: > Hi Vaishali, > > Thank you for the patch. > > On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote: >> As specified in drm_drv.c, drm_dev_unref is a compatibility alias >> for drm_dev_put and

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On Wed, Apr 25, 2018 at 3:22 PM, Oleg Nesterov wrote: > On 04/24, Daniel Vetter wrote: >> >> wait_event_killabel doesn't check for fatal_signal_pending before calling >> schedule, so definitely has a nice race there. > > This is fine. See the signal_pending_state() check in

Re: [PATCH] drm: rcar-du: Use drm_dev_put

Hi Vaishali, Thank you for the patch. On Wednesday, 25 April 2018 15:10:36 EEST Vaishali Thakkar wrote: > As specified in drm_drv.c, drm_dev_unref is a compatibility alias > for drm_dev_put and shouldn't be used in new code. So, use > drm_dev_put instead. This looks good to me. However, how

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/24, Daniel Vetter wrote: > > wait_event_killabel doesn't check for fatal_signal_pending before calling > schedule, so definitely has a nice race there. This is fine. See the signal_pending_state() check in __schedule(). And this doesn't differ from wait_event_interruptible(), it too

Re: [PATCH] drm/vmwgfx: Fix scatterlist unmapping

Hi, Robin, Thanks for the patch. It was some time since I put together that code, but I remember hitting something similar to https://www.linuxquestions.org/questions/linux-kernel-70/%27nents%27-argument-of-dma_unmap_sg-4175621964/ Even if it's clear from the documentation that orig_nents

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Philippe, On Wednesday, 25 April 2018 15:20:04 EEST Philippe CORNU wrote: > On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote: > >> Add optional power supplies using the description found in > >> "SiI9022A/SiI9024A HDMI

Re: [PATCH 2/3] drm/scheduler: Don't call wait_event_killable for signaled process.

On 04/25/2018 03:14 AM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at 05:37:08PM -0400, Andrey Grodzovsky wrote: On 04/24/2018 05:21 PM, Eric W. Biederman wrote: Andrey Grodzovsky writes: On 04/24/2018 03:44 PM, Daniel Vetter wrote: On Tue, Apr 24, 2018 at

Re: [PATCH v3 6/6] arm64: dts: rockchip: Specify override mode for kevin panel

On 25 April 2018 at 01:29, Doug Anderson wrote: > Hi, > > On Tue, Apr 24, 2018 at 7:31 AM, Ezequiel Garcia > wrote: >> Hi Doug, Sean: >> >> I would like to move this forward. >> >> On 26 February 2018 at 15:23, Doug Anderson

Re: [Mesa-dev] [PATCH i-g-t] [RFC] CONTRIBUTING: commit rights docs

On 24 April 2018 at 20:14, Daniel Vetter wrote: > On Tue, Apr 24, 2018 at 7:30 PM, Emil Velikov > wrote: >> On 13 April 2018 at 11:00, Daniel Vetter wrote: >>> This tries to align with the X.org communities's

Re: [PATCH v2 1/2] dt-bindings/display/bridge: sii902x: add optional power supplies

Hi Laurent & Rob :-) On 04/25/2018 11:01 AM, Laurent Pinchart wrote: > Hi Philippe, > > Thank you for the patch. > > On Wednesday, 25 April 2018 10:53:13 EEST Philippe Cornu wrote: >> Add optional power supplies using the description found in >> "SiI9022A/SiI9024A HDMI Transmitter Data Sheet

[PATCH] drm: rcar-du: Use drm_dev_put

As specified in drm_drv.c, drm_dev_unref is a compatibility alias for drm_dev_put and shouldn't be used in new code. So, use drm_dev_put instead. Signed-off-by: Vaishali Thakkar --- drivers/gpu/drm/rcar-du/rcar_du_drv.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

On Wed, Apr 25, 2018 at 1:26 PM, Liviu Dudau wrote: > On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote: >> On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote: >> > malidp_pm_suspend_late checks if the runtime status is not suspended >> > and if so,

Re: [PATCH v3 5/5] drm/arm/malidp: Added the late system pm functions

On Wed, Apr 25, 2018 at 09:17:22AM +0200, Daniel Vetter wrote: > On Tue, Apr 24, 2018 at 07:12:47PM +0100, Ayan Kumar Halder wrote: > > malidp_pm_suspend_late checks if the runtime status is not suspended > > and if so, invokes malidp_runtime_pm_suspend which disables the > > display engine/core

[PATCH] drm/todo: Fallout from v3d review

Bunch of ideas from Eric and me on what we could do to make gem gpu rendering drivers a notch simpler to type. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- Documentation/gpu/todo.rst | 18 ++ 1 file changed, 18 insertions(+) diff

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On Monday, April 23, 2018 05:11:14 PM Tomi Valkeinen wrote: > On 23/04/18 16:56, Bartlomiej Zolnierkiewicz wrote: > > > Ideally we should be able to build both drivers in the same kernel > > (especially as modules). > > > > I was hoping that it could be fixed easily but then I discovered > >

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On Monday, April 23, 2018 10:55:57 AM Mauro Carvalho Chehab wrote: > Em Mon, 23 Apr 2018 14:47:28 +0200 > Bartlomiej Zolnierkiewicz escreveu: > > > On Friday, April 20, 2018 01:42:51 PM Mauro Carvalho Chehab wrote: > > > Add stubs for omapfb_dss.h, in the case it is

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

Hi Tomi, On Wednesday, 25 April 2018 13:10:43 EEST Tomi Valkeinen wrote: > On 25/04/18 13:02, Laurent Pinchart wrote: > > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote: > >> On 25/04/18 12:03, Laurent Pinchart wrote: > >>> Could we trim down omapfb to remove support for the

Re: DRI3 WSEGL plugin for TI SGX

On 25/04/18 12:43, Merlijn Wajer wrote: > Hi! > > On 16/04/18 16:49, Tomi Valkeinen wrote: >> Hi All, >> >> I have implemented a WSEGL plugin library for Imagination's PVR driver >> for SGX, which allows using SGX via DRI3. In other words, it is one >> piece in the puzzle of using SGX with X11.

[PATCH v2 5/5] ARM: Unconditionally enable ARM_DMA_USE_IOMMU

From: Thierry Reding The ARM_DMA_USE_IOMMU Kconfig option has side-effects that drivers can not opt into but have to explicitly opt out of. This can lead to subtle bugs that are difficult to track down and not immediately obvious to be related to this Kconfig option. To

Re: [PATCH 5/7] omapfb: omapfb_dss.h: add stubs to build with COMPILE_TEST && DRM_OMAP

On 25/04/18 13:02, Laurent Pinchart wrote: > Hi Tomi, > > On Wednesday, 25 April 2018 12:33:53 EEST Tomi Valkeinen wrote: >> On 25/04/18 12:03, Laurent Pinchart wrote: >>> Could we trim down omapfb to remove support for the devices supported by >>> omapdrm ? >> >> I was thinking about just that.

[PATCH v2 1/5] drm/nouveau: tegra: Detach from ARM DMA/IOMMU mapping

From: Thierry Reding Depending on the kernel configuration, early ARM architecture setup code may have attached the GPU to a DMA/IOMMU mapping that transparently uses the IOMMU to back the DMA API. Tegra requires special handling for IOMMU backed buffers (a special bit in the

[PATCH v2 2/5] dma-mapping: Introduce dma_iommu_detach_device() API

From: Thierry Reding The dma_iommu_detach_device() API can be used by drivers to forcibly detach a device from an IOMMU that architecture code might have attached to. This is useful for drivers that need explicit control over the IOMMU using the IOMMU API directly.

[PATCH v2 3/5] ARM: dma-mapping: Implement arch_iommu_detach_device()

From: Thierry Reding Implement this function to enable drivers from detaching from any IOMMU domains that architecture code might have attached them to so that they can take exclusive control of the IOMMU via the IOMMU API. Signed-off-by: Thierry Reding

[PATCH v2 4/5] drm/nouveau: tegra: Use dma_iommu_detach_device()

From: Thierry Reding Use the new dma_iommu_detach_device() function to replace the open-coded equivalent. Signed-off-by: Thierry Reding --- .../drm/nouveau/nvkm/engine/device/tegra.c| 19 ++- 1 file changed, 2 insertions(+), 17

Re: noveau vs arm dma ops

On Wed, Apr 25, 2018 at 01:54:39AM -0700, Christoph Hellwig wrote: > [discussion about this patch, which should have been cced to the iommu > and linux-arm-kernel lists, but wasn't: > https://www.spinics.net/lists/dri-devel/msg173630.html] > > On Wed, Apr 25, 2018 at 09:41:51AM +0200, Thierry

  1   2   3   >