nouveau-next 4.18

Hey Dave, The main thing here is the addition of support for Volta GV100 GPUs, everything else basically restructuring display / graphics init code to make it possible to fit Volta support in more nicely. There's a bunch of improvements/fixes scattered in there for earlier GPUs too, particularly

[git pull] drm fixes for v4.17-rc6

Hi Linus, Pretty quiet week again, one vmwgfx regression fix, one core buffer overflow fix,one vc4 leak fix and three i915 fixes. Dave. The following changes since commit 76ef6b28ea4f81c3d511866a9b31392caa833126: drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000) are

[PATCH] Fix -WMissing-braces compile warning on android

use "{}" instead of "{0}" in empty struct defination to avoid missing-braces warning: suggest braces around initialization of subobject [-Wmissing-braces] Test: compilation on android with this warning free Signed-off-by: Jenny Cao --- amdgpu/amdgpu_cs.c | 4 ++--

[Bug 101976] glmark2 random blank or background only screen freeze over amdgpu rx550 AMD POLARIS12 due to dpm

https://bugs.freedesktop.org/show_bug.cgi?id=101976 Pablo Estigarribia changed: What|Removed |Added Resolution|FIXED |---

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=96897 --- Comment #14 from Dieter Nützel --- (In reply to Jan Vesely from comment #13) > Initial support for cl_khr_fp16 builtins has been added to libclc in r332677. > It should be enough to run clpeak. > clpeak still takes few

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

On Thu, May 17, 2018 at 6:41 PM, hl wrote: > On Thursday, May 17, 2018 09:51 PM, Sean Paul wrote: >> On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote: >>> DP firmware uses fixed phy config values to do training, but some >>> boards need to adjust these values to fit

Re: [PATCH libdrm 1/1] amdgpu: Take lock before removing devices from fd_tab hash table.

On Thu, 2018-05-10 at 19:33 -0400, Jan Vesely wrote: > Close the file descriptors under lock as well. > > Signed-off-by: Jan Vesely > --- > amdgpu/amdgpu_device.c | 11 +++ > 1 file changed, 7 insertions(+), 4 deletions(-) > > diff --git a/amdgpu/amdgpu_device.c

[Bug 96897] clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI

https://bugs.freedesktop.org/show_bug.cgi?id=96897 Jan Vesely changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553 Bug 99553 depends on bug 96897, which changed state. Bug 96897 Summary: clpeak OpenCL benchmark hangs during compilation on Clover RadeonSI https://bugs.freedesktop.org/show_bug.cgi?id=96897 What|Removed

[PATCH v3 1/4] drm/dp: Define payload size for DP SDP PPS packet

DP 1.4 spec defines DP secondary data packet for DSC picture parameter set. This patch defines its payload size according to the DP 1.4 specification. Signed-off-by: Manasi Navare Cc: Jani Nikula Cc: Ville Syrjala

[PATCH v3 3/4] drm/dsc: Define VESA Display Stream Compression Capabilities

From: Gaurav K Singh This defines all the DSC parameters as per the VESA DSC spec that will be required for DSC encoder/decoder v3: Remove the duplicate define (Harry) (From Manasi) v2: Define this struct in DRM (From Manasi) * Changed the data types to u8/u16 instead

[PATCH v3 4/4] drm/dsc: Add helpers for DSC picture parameter set infoframes

According to Display Stream compression spec 1.2, the picture parameter set metadata is sent from source to sink device using the DP Secondary data packet. An infoframe is formed for the PPS SDP header and PPS SDP payload bytes. This patch adds helpers to fill the PPS SDP header and PPS SDP

[PATCH v3 2/4] drm/dsc: Define Display Stream Compression PPS infoframe

This patch defines a new header file for all the DSC 1.2 structures and creates a structure for PPS infoframe which will be used to send picture parameter set secondary data packet for display stream compression. All the PPS infoframe syntax elements are taken from DSC 1.2 specification from VESA.

Re: [PATCH hwc] drm_hwcomposer: Support assigning planes in ValidateDisplay

Hey Rob, On Fri, May 18, 2018 at 12:08 AM, Rob Herring wrote: > In order to assign planes to layers in ValidateDisplay, testing > compositing with a DRM atomic modeset test is needed as PresentDisplay > is too late. This means most of PresentDisplay needs to be run from >

[PATCH hwc] drm_hwcomposer: Support assigning planes in ValidateDisplay

In order to assign planes to layers in ValidateDisplay, testing compositing with a DRM atomic modeset test is needed as PresentDisplay is too late. This means most of PresentDisplay needs to be run from ValidateDisplay, so refactor PresentDisplay and plumb a test flag down the stack.

Re: [RFC] remoting KMS

On Thu, May 17, 2018 at 11:18 PM, Thomas Hellstrom wrote: > > On 05/17/2018 09:20 PM, Daniel Vetter wrote: >> >> On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom >> wrote: >>> >>> Hi! >>> >>> I'm currently working on a remoting KMS backend, and now I

[radeon-alex:amd-staging-drm-next 114/431] sound/soc/amd/raven/acp3x.h:28:9: error: implicit declaration of function 'readl'; did you mean 'vread'?

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: 100dd4c0f231fce76fa8115ad28d507e311d32bf commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/431] ASoC: AMD: enable ACP3x drivers build config: sparc64-allyesconfig (attached as .config) compiler:

Re: [RFC] remoting KMS

On 05/17/2018 09:20 PM, Daniel Vetter wrote: On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom wrote: Hi! I'm currently working on a remoting KMS backend, and now I thought it would be a good time to get some feedback on a very rough design: The idea is that we want to

Re: [DPU PATCH v2 5/6] drm/msm: hook up DPU with upstream DSI

On Thu, Apr 19, 2018 at 04:52:03PM -0700, Jeykumar Sankaran wrote: > Switch DPU from dsi-staging to upstream dsi driver. To make > the switch atomic, this change includes: > - remove dpu connector layers > - clean up dpu connector dependencies in encoder/crtc > - compile out writeback and display

Re: [Intel-gfx] [drm-tip:drm-tip 711/734] drivers/gpu/drm/rcar-du/rcar_du_vsp.c:317:6: error: 'struct rcar_du_vsp_plane_state' has no member named 'alpha'

Hi Dave, On Thursday, 17 May 2018 08:05:03 EEST Dave Airlie wrote: > On 17 May 2018 at 14:42, Dave Airlie wrote: > > On 16 May 2018 at 01:37, Laurent Pinchart wrote: > >> On Tuesday, 15 May 2018 17:24:52 EEST kbuild test robot wrote: > >>> tree:

[radeon-alex:amd-staging-drm-next 114/432] sound/soc//amd/raven/pci-acp3x.c:58:8: error: implicit declaration of function 'pci_enable_msi'; did you mean 'pci_enable_sriov'?

tree: git://people.freedesktop.org/~agd5f/linux.git amd-staging-drm-next head: d19e8ade9c3b04edf71a7ec439ba53ea2b8c76a3 commit: 2a6630b1095609b26a205b7c537594f3cde99c0a [114/432] ASoC: AMD: enable ACP3x drivers build config: sh-allyesconfig (attached as .config) compiler: sh4-linux-gnu-gcc

Re: [Intel-gfx] [PATCH v2 5/5] media: platform: Add Chrome OS EC CEC driver

Hi Neil, I love your patch! Yet something to improve: [auto build test ERROR on linuxtv-media/master] [also build test ERROR on v4.17-rc5 next-20180517] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux

[tegra-drm:drm/tegra/for-next 27/35] drivers/gpu/host1x/job.c:103:33: error: 'struct host1x_job' has no member named 'num_cmdbufs'

tree: git://anongit.freedesktop.org/tegra/linux.git drm/tegra/for-next head: b9136bd01841a63b7706db69e1da8843c8622a9f commit: c8d8568a8dbb4dc455ceaca7b95108d85b3d4798 [27/35] gpu: host1x: Use not explicitly sized types config: arm64-defconfig (attached as .config) compiler:

Re: [RFC] remoting KMS

On Thu, May 17, 2018 at 8:23 PM, Thomas Hellstrom wrote: > Hi! > > I'm currently working on a remoting KMS backend, and now I thought it would > be a good time to get some feedback on a very rough design: > > The idea is that we want to be get enough information on the

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

On 05/17/2018 10:48 AM, Michel Dänzer wrote: On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote: Hi Michele and others, I am trying to implement the approach bellow to resolve AMDGPU's hang when commands are stuck in pipe during process exit. I noticed that once I implemented the

Re: [PATCH] drm/scheduler: fix function name prefix in comments

On Wed, May 16, 2018 at 9:24 AM, Nayan Deshmukh wrote: > That got missed while moving the files outside of amdgpu. > > Signed-off-by: Nayan Deshmukh > Reviewed-by: Christian König Applied. thanks! Alex > --- >

[RFC] remoting KMS

Hi! I'm currently working on a remoting KMS backend, and now I thought it would be a good time to get some feedback on a very rough design: The idea is that we want to be get enough information on the backend side of KMS to be able to remote the display system over VNC or something similar.

[Bug 104439] intel_do_flush_locked failed: Invalid argument

https://bugs.freedesktop.org/show_bug.cgi?id=104439 Jani Nikula changed: What|Removed |Added Status|NEW |RESOLVED

[PATCH v7 1/3] drm: Add writeback connector type

From: Brian Starkey Writeback connectors represent writeback engines which can write the CRTC output to a memory framebuffer. Add a writeback connector type and related support functions. Drivers should initialize a writeback connector with drm_writeback_connector_init()

[PATCH v7 2/3] drm: writeback: Add out-fences for writeback connectors

From: Brian Starkey Add the WRITEBACK_OUT_FENCE_PTR property to writeback connectors, to enable userspace to get a fence which will signal once the writeback is complete. It is not allowed to request an out-fence without a framebuffer attached to the connector. A timeline

[PATCH v7 3/3] drm: writeback: Add client capability for exposing writeback connectors

Due to the fact that writeback connectors behave in a special way in DRM (they always report being disconnected) we might confuse some userspace. Add a client capability for writeback connectors that will filter them out for clients that don't understand the capability. Re-requested-by: Sean Paul

[PATCH v7 0/3] drm: Introduce writeback connectors

Hi, This is v7 of the writeback connector series. This is just a refresh of the v6 series in order to get it ready for merging into the kernel, now that the userspace implementation has been reviewed and ACKed by Sean Paul here [1]. For anyone that wants a refresh on what changed in v6, the

[Bug 199693] [bisect 08810a4119aaebf6318f209ec5dd9828e969cba4] (pci runtime) System freeze after resuming from suspend (amdgpu)

https://bugzilla.kernel.org/show_bug.cgi?id=199693 Len Brown (l...@kernel.org) changed: What|Removed |Added CC||l...@kernel.org

Re: [PATCH v11 0/2] Enabling content-type setting for HDMI displays.

On Tue, May 15, 2018 at 04:59:26PM +0300, StanLis wrote: > From: Stanislav Lisovskiy > > Added content type setting property to drm_connector(part 1) > and enabled transmitting it with HDMI AVI infoframes > for i915(part 2). > > Stanislav Lisovskiy (2): > drm:

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

On 2018-05-17 05:33 PM, Andrey Grodzovsky wrote: > > BTW, just out of interest, how the FDs are passed to clients ? Using > sockets ? Yes, via the socket used for the X11 display connection. > Can you point me to the code which does it ? xserver/dri3/dri3_request.c:dri3_send_open_reply() =>

[PATCH 7/7] drm/tegra: Add kerneldoc for UAPI

From: Thierry Reding Document the userspace ABI with kerneldoc to provide some information on how to use it. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/gem.c | 4 +- include/uapi/drm/tegra_drm.h | 480 ++-

[PATCH 5/7] drm/tegra: gr3d: Track interface version

From: Thierry Reding Set the interface version implemented by the gr3d module. This allows userspace to pass the correct command stream when programming the gr3d module. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/gr3d.c | 28

[PATCH 6/7] drm/tegra: vic: Track interface version

From: Thierry Reding Set the interface version implemented by the VIC module. This allows userspace to pass the correct command stream when programming the VIC module. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/vic.c | 5 + 1 file

[PATCH 4/7] drm/tegra: gr2d: Track interface version

From: Thierry Reding Set the interface version implemented by the gr2d module. This allows userspace to pass the correct command stream when programming the gr2d module. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/gr2d.c | 22

[PATCH 0/7] drm/tegra: Preparation work for destaging ABI

From: Thierry Reding These patches are further preparation work to destage the job submission ABI. Patch 1 fixes a typo in the argument to the close channel IOCTL and isn't technically preparation work. Neither are patches 2 and 3 which do some cleanup and add support for the

[PATCH 2/7] drm/tegra: gem: Fill in missing export info

From: Thierry Reding Set the owner and name of the exported DMA-BUF in addition to the already filled-in fields. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/gem.c | 2 ++ 1 file changed, 2 insertions(+) diff --git

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

On 17 May 2018 at 16:26, Russell King - ARM Linux wrote: > On Thu, May 17, 2018 at 02:15:40PM +0100, Daniel Stone wrote: >> On 30 March 2018 at 15:11, Daniel Stone wrote: >> > Since drm_framebuffer can now store GEM objects directly, place them >> >

[PATCH 3/7] drm/tegra: dc: Support rotation property

From: Thierry Reding Currently only the DRM_MODE_REFLECT_Y rotation is supported. The driver already supports reflection on the Y axis via a custom flag which is not very useful because it requires custom userspace. Replace that flag by a standard rotation property that

[PATCH 1/7] drm/tegra: Use proper arguments for DRM_TEGRA_CLOSE_CHANNEL IOCTL

From: Thierry Reding A separate data structure exists for the DRM_TEGRA_CLOSE_CHANNEL IOCTL, but it is currently unused. The IOCTL was using the data structure for the DRM_TEGRA_OPEN_CHANNEL IOCTL. Signed-off-by: Thierry Reding ---

Re: [PATCH] drm/bridge: checkpatch strict minor updates

Hi, Applied on drm-misc-next. Note: patch subject has been renamed "drm/bridge: spelling and coding style minor fixes" to comply with checkpatch (my bad ;-), hope it is better, Many thanks, Philippe :-) On 05/16/2018 11:43 AM, Daniel Vetter wrote: > On Tue, May 15, 2018 at 10:37:36PM +0200,

[PATCH 5/7] gpu: host1x: Rename relocarray -> relocs for consistency

From: Thierry Reding All other array variables use a plural, and this is the only one using the *array suffix. This is confusing, so rename it for consistency. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/drm.c | 4 ++--

[PATCH 2/7] gpu: host1x: Store pointer to client in jobs

From: Thierry Reding Rather than storing some identifier derived from the application context that can't be used concretely anywhere, store a pointer to the client directly so that accesses can be made directly through that client object. Signed-off-by: Thierry Reding

[PATCH 7/7] gpu: host1x: Track client version

From: Thierry Reding Userspace needs to know the version of the interface implemented by a client so it can create the proper command streams. Allow individual drivers to store this version along with the client so that it can be returned to userspace upon opening a channel.

[PATCH 6/7] gpu: host1x: Use not explicitly sized types

From: Thierry Reding The number of words and the offset in a gather don't need to be explicitly sized, so make them unsigned int instead. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/job.c | 13 - drivers/gpu/host1x/job.h | 4 ++--

[PATCH 1/7] gpu: host1x: Remove wait check support

From: Thierry Reding The job submission userspace ABI doesn't support this and there are no plans to implement it, so all of this code is dead and can be removed. Signed-off-by: Thierry Reding --- drivers/gpu/drm/tegra/drm.c| 62 +--

[PATCH 0/7] gpu: host1x: Preparation work for destaging ABI

From: Thierry Reding These couple of patches clean up some things in the host1x driver and prepares the way for adding a revamped job submission ABI in a future patch series. The ultimate goal is to destage the job submission ABI, so that it is enabled in default builds of

[PATCH 3/7] gpu: host1x: Cleanup loop variable usage

From: Thierry Reding Use unsigned int where possible and don't unnecessarily initialize the loop variable. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/debug.c | 2 +- drivers/gpu/host1x/intr.c | 2 +- drivers/gpu/host1x/job.c| 4 ++--

[PATCH 4/7] gpu: host1x: Drop unnecessary host1x argument

From: Thierry Reding Functions taking a pointer to a host1x syncpoint as an argument don't need to specify a pointer to a host1x instance because it can be obtained from the syncpoint. Signed-off-by: Thierry Reding --- drivers/gpu/host1x/hw/channel_hw.c

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

Thanks Michel, will give it a try. BTW, just out of interest, how the FDs are passed to clients ? Using sockets ? Can you point me to the code which does it ? Andrey On 05/17/2018 10:48 AM, Michel Dänzer wrote: On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote: Hi Michele and others, I am

RE: linux-next: Signed-off-by missing for commits in the drm tree

Hi Stephen, Changes are Signed-off-by: Anthony Koo Thanks, Anthony -Original Message- From: Stephen Rothwell [mailto:s...@canb.auug.org.au] Sent: Tuesday, May 15, 2018 7:19 PM To: Dave Airlie ; DRI Cc: Linux-Next

Re: [PATCH 24/24] drm/amdgpu: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:38PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 23/24] drm/radeon: radeon_framebuffer -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:37PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 22/24] drm/radeon: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:36PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:35PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle function the same as the GEM framebuffer helper, we > can reuse that. > >

Re: [PATCH 20/24] drm/gma500: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:34PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:33PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote: > Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can > just delete it. > > Signed-off-by: Daniel Stone > Cc: CK Hu > Cc: Philipp Zabel > --- >

Re: [PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH] efi/fb: Convert PCI bus address to resource if translated by the bridge

On Thu, May 17, 2018 at 09:22:23AM -0400, Sinan Kaya wrote: > A host bridge is allowed to remap BAR addresses using _TRA attribute in > _CRS windows. > > pci_bus :00: root bus resource [mem 0x8010010-0x8011fff window] > (bus address [0x0010-0x1fff]) > pci :02:00.0: reg

Re: [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

On Thu, May 17, 2018 at 09:58:19AM -0400, Sean Paul wrote: > On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote: > > A FB with no object is something we should be shouting very loudly > > about, not quietly logging as debug. > > > > Signed-off-by: Daniel Stone >

Re: [PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote: > drm_framebuffer already holds per-plane pitch and offsets, which is > filled out for us when we create the framebuffer. Nuke our local copy in > the plane struct. > > Signed-off-by: Daniel Stone > Cc: Tomi

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

On 2018-05-17 01:18 PM, Andrey Grodzovsky wrote: > Hi Michele and others, I am trying to implement the approach bellow to > resolve AMDGPU's hang when commands are stuck in pipe during process exit. > > I noticed that once I implemented the file_operation.flush callback  > then during run of X, i

Re: [PATCH 06/24] drm/omap: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:20PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote: > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > can remove it. > > Signed-off-by: Daniel Stone > Cc: Sandy Huang > Cc: Heiko Stübner > --- >

[Bug 106548] Failed GfxDrv_DriverAcceptanceQuery.GL_GPU_FREQ_OVERRIDE_MDAPI

https://bugs.freedesktop.org/show_bug.cgi?id=106548 Joonas Lahtinen changed: What|Removed |Added Status|NEW

[PATCH] drm/vc4: Define a DRM format modifier for SAND tiling.

From: Dave Stevenson This is the format generated by VC4's H.264 engine, and preferred by the ISP as well. By displaying SAND buffers directly, we can avoid needing to use the ISP to rewrite the SAND H.264 output to linear before display. Signed-off-by: Dave

Re: [PATCH v2] drm/vc4: plane: Expand the lower bits by repeating the higher bits

Maxime Ripard writes: > The vc4 HVS uses an internal RGB888 representation of the frames, and will > by default expand formats using a lower depth using zeros. > > This causes an issue when we try to use other compositing software such as > pixman that fill the missing

Re: [PATCH 03/24] drm/virtio: Place GEM BOs in drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:17PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 02/24] drm/cirrus: cirrus_framebuffer -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:16PM +0100, Daniel Stone wrote: > Now cirrus_framebuffer is just an empty wrapper around drm_framebuffer, > we can drop it. > > Signed-off-by: Daniel Stone > Cc: Dave Airlie > Cc: Gerd Hoffmann > Cc:

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

Hi Heiko, On 17 May 2018 at 14:42, Heiko Stübner wrote: > Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone: >> On 30 March 2018 at 15:11, Daniel Stone wrote: >> > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we >> >

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:24PM +0100, Daniel Stone wrote: > Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can > just delete it. > > Signed-off-by: Daniel Stone > Cc: CK Hu > Cc: Philipp Zabel

Re: [PATCH 09/24] drm/mtk: Move GEM BO to drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:23PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 08/24] drm/mtk: Promote impossible internal error to WARN_ON

On Fri, Mar 30, 2018 at 03:11:22PM +0100, Daniel Stone wrote: > A FB with no object is something we should be shouting very loudly > about, not quietly logging as debug. > > Signed-off-by: Daniel Stone > Cc: CK Hu > Cc: Philipp Zabel

Re: [PATCH 04/24] drm/rockchip: Place GEM BOs in drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:18PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:19PM +0100, Daniel Stone wrote: > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > can remove it. > > Signed-off-by: Daniel Stone Reviewed-by: Sean Paul > Cc: Sandy Huang >

Re: [PATCH 01/24] drm/cirrus: Place GEM BOs in drm_framebuffer

On Fri, Mar 30, 2018 at 03:11:15PM +0100, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer > helper, we can reuse

Re: [PATCH v5 4/4] drm/rockchip: support dp training outside dp firmware

On Thu, May 17, 2018 at 05:18:00PM +0800, Lin Huang wrote: > DP firmware uses fixed phy config values to do training, but some > boards need to adjust these values to fit for their unique hardware > design. So get phy config values from dts and use software link training > instead of relying on

Re: [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

On Thu, May 17, 2018 at 02:11:16PM +0100, Daniel Stone wrote: > Hi Thierry, > > On 30 March 2018 at 15:11, Daniel Stone wrote: > > Since tegra_fb is now the same as drm_framebuffer, we can just replace > > the type completely. > > > > Signed-off-by: Daniel Stone

[bug report] drm/amd/pp: Change voltage/clk range for OD feature on VI

Hello Rex Zhu, The patch d389d607e608: "drm/amd/pp: Change voltage/clk range for OD feature on VI" from Apr 18, 2018, leads to the following static checker warning: drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/smu7_hwmgr.c:872 smu7_setup_voltage_range_from_vbios() error:

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

Hi Daniel, Am Donnerstag, 17. Mai 2018, 15:08:15 CEST schrieb Daniel Stone: > On 30 March 2018 at 15:11, Daniel Stone wrote: > > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > > can remove it. > > > > Signed-off-by: Daniel Stone

Re: [PATCH v3 27/40] drm/i915: Implement HDCP2.2 link integrity check

On Monday 14 May 2018 03:15 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

[PATCH v2] drm/vc4: plane: Expand the lower bits by repeating the higher bits

The vc4 HVS uses an internal RGB888 representation of the frames, and will by default expand formats using a lower depth using zeros. This causes an issue when we try to use other compositing software such as pixman that fill the missing bits by repeating the higher significant bits. As such, we

[bug report] drm/exynos: Add driver for Exynos Scaler module

Hello Andrzej Pietrasiewicz, The patch 01fb9185dc18: "drm/exynos: Add driver for Exynos Scaler module" from May 9, 2018, leads to the following static checker warning: drivers/gpu/drm/exynos/exynos_drm_scaler.c:402 scaler_task_done() warn: signedness bug returning '(-22)'

Re: [PATCH v3 26/40] drm/i915: Implement HDCP2.2 En/Dis-able

On Monday 14 May 2018 03:00 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

On Thursday 17 May 2018 06:31 PM, Ramalingam C wrote: On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To:

[PATCH] drm/vc4: Introduce tracepoints for CL execution.

This has been useful for debugging the window movement lag in X11, and I have patches to sysprof that watch these to produce nice visualizations. Signed-off-by: Eric Anholt --- drivers/gpu/drm/vc4/vc4_gem.c | 4 +++ drivers/gpu/drm/vc4/vc4_irq.c | 4 +++

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Move GEM BO inside drm_framebuffer

Hi Ville, On 23 March 2018 at 14:49, Daniel Stone wrote: > On 23 March 2018 at 14:42, Ville Syrjälä > wrote: >> Hmm. I'm thinking we can stick to the single reference per fb. >> IIRC this counter is there just to prevent changes of the obj

Re: [PATCH 19/24] drm/armada: Move GEM BO to drm_framebuffer

Hi Russell, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle and destroy functions the same as the GEM framebuffer >

Re: [PATCH 10/24] drm/mtk: mtk_drm_fb -> drm_framebuffer

Hi CK, Philipp, On 30 March 2018 at 15:11, Daniel Stone wrote: > Now that mtk_drm_fb is an empty wrapper around drm_framebuffer, we can > just delete it. Did you get a chance to look at these three patches for Mediatek? Cheers, Daniel

Re: [PATCH 07/24] drm/omap: Move buffer pitch/offset to drm_framebuffer

On 30 March 2018 at 21:53, Sebastian Reichel wrote: > On Fri, Mar 30, 2018 at 03:11:21PM +0100, Daniel Stone wrote: >> drm_framebuffer already holds per-plane pitch and offsets, which is >> filled out for us when we create the framebuffer. Nuke our local copy in

Re: [PATCH 21/24] drm/msm: Move GEM BOs to drm_framebuffer

Hi Rob, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since drm_framebuffer can now store GEM objects directly, place them > there rather than in our own subclass. As this makes the framebuffer > create_handle function the same as the GEM framebuffer helper, we > can

Re: [PATCH 13/24] drm/tegra: tegra_fb -> drm_framebuffer

Hi Thierry, On 30 March 2018 at 15:11, Daniel Stone wrote: > Since tegra_fb is now the same as drm_framebuffer, we can just replace > the type completely. > > Signed-off-by: Daniel Stone > Cc: Thierry Reding > Cc:

Re: [PATCH v3 25/40] drm/i915: Enable and Disable HDCP2.2 port encryption

On Monday 14 May 2018 02:53 PM, Shankar, Uma wrote: -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Ramalingam C Sent: Tuesday, April 3, 2018 7:28 PM To: intel-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org;

Re: [PATCH 05/24] drm/rockchip: rockchip_drm_fb -> drm_framebuffer

On 30 March 2018 at 15:11, Daniel Stone wrote: > Now that rockchip_drm_fb is just a wrapper around drm_framebuffer, we > can remove it. > > Signed-off-by: Daniel Stone > Cc: Sandy Huang > Cc: Heiko Stübner

  1   2   >