Re: [Intel-gfx] [PATCH 3/6] drm: Verify gamma/degamma LUT size

On Fri, Feb 23, 2018 at 09:25:03PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > While we want to potentially support multiple different gamma/degamma > LUT sizes we can (and should) at least check that the blob length > is a multiple of the LUT entry size.

Re: [Intel-gfx] [PATCH 4/6] drm: Introduce drm_color_lut_size()

On Fri, Feb 23, 2018 at 09:25:04PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Provide a small helper to convert the blob length in bytes > to the number of LUT entries. > > Signed-off-by: Ville Syrjälä > --- >

Re: [PATCH 1/4] drm/uapi: The ctm matrix uses sign-magnitude representation

On Fri, Feb 23, 2018 at 11:26:41AM -0500, Harry Wentland wrote: > On 2018-02-22 04:42 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > The documentation for the ctm matrix suggests a two's complement > > format, but at least the i915 implementation is using

Re: [PATCH 0/4] drm/tilcdc: Add DRM panel support and use it for am335x-evm

On Mon, Mar 05, 2018 at 02:12:16PM +0200, Jyri Sarha wrote: > On 05/03/18 11:29, Jyri Sarha wrote: > >> Since panel drivers are in drm-misc probably simplest if we push these all > >> through that tree? Want commit rights for that? > >> -Daniel > >> > > Sure. However, I already sent a pull request

Re: [RFC PATCH hwc] drm_hwcomposer: set CRTC background color when available

On Thu, Feb 22, 2018 at 04:54:08AM +0100, Stefan Schake wrote: > Android assumes an implicit black background layer is always present > behind all layers it specifies for composition. drm_hwcomposer currently > punts responsibility for this to the kernel/DRM platform and puts layers > with

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On 03/06/2018 09:26 AM, Daniel Vetter wrote: On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote: On 03/05/2018 11:32 AM, Daniel Vetter wrote: On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko

Re: [PATCH 2/3] drm/sun4i: rgb: Fix potential division by zero

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard wrote: > In the case where mode_valid callback of our RGB connector was called > before mode_set was being called, the range of dividers would not be set, > resulting in a division by zero later on in the clk_round_rate

Re: [PATCH 3/3] drm/sun4i: crtc: Call drm_crtc_vblank_on / drm_crtc_vblank_off

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard wrote: > Make sure that the CRTC code will call the enable/disable_vblank hooks. > > Otherwise, since the refcounting will be off, we might end up in a > situation where the vblank management functions are called while the

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Tue, Mar 06, 2018 at 08:29:20AM +0100, Daniel Vetter wrote: > On Wed, Feb 21, 2018 at 04:19:40PM +0100, Maarten Lankhorst wrote: > > Hey, > > > > Op 21-02-18 om 15:37 schreef Rob Clark: > > > Follow the same pattern of locking as with other state objects. This > > > avoids boilerplate in the

Re: [PATCH 1/3] drm/sun4i: tcon: Reduce the scope of the LVDS error a bit

On Wed, Feb 21, 2018 at 8:57 PM, Maxime Ripard wrote: > The current logic to deal with old DT missing the LVDS properties doesn't > take into account whether the LVDS output is supported in the first place, > resulting in spurious error messages on SoCs where it doesn't

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 06:36:54PM +0200, Ville Syrjälä wrote: > On Wed, Feb 21, 2018 at 11:17:21AM -0500, Rob Clark wrote: > > On Wed, Feb 21, 2018 at 10:54 AM, Ville Syrjälä > > wrote: > > > On Wed, Feb 21, 2018 at 10:36:06AM -0500, Rob Clark wrote: > > >> On Wed,

Re: [PATCH v4 15/38] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

Hi All, This is the patch, which introduces the issue I've pointed here: https://lists.freedesktop.org/archives/dri-devel/2018-March/167794.html On 2018-03-05 23:23, Enric Balletbo i Serra wrote: From: Lin Huang When panel is shut down, we should make sure edp can be

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 09:37:21AM -0500, Rob Clark wrote: > Follow the same pattern of locking as with other state objects. This > avoids boilerplate in the driver. > > Signed-off-by: Rob Clark Please also adjust the kernel doc, and I think we can remove the locking

Re: [PATCH 1/4] drm/atomic: integrate modeset lock with private objects

On Wed, Feb 21, 2018 at 04:19:40PM +0100, Maarten Lankhorst wrote: > Hey, > > Op 21-02-18 om 15:37 schreef Rob Clark: > > Follow the same pattern of locking as with other state objects. This > > avoids boilerplate in the driver. > I'm afraid this will prohibit any uses of this on i915, since it

Re: [PATCH 7/9] drm/xen-front: Implement KMS/connector handling

On 03/06/2018 09:22 AM, Daniel Vetter wrote: On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote: On 03/05/2018 11:23 AM, Daniel Vetter wrote: On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote: From: Oleksandr Andrushchenko

Re: [PATCH 8/9] drm/xen-front: Implement GEM operations

On Mon, Mar 05, 2018 at 03:46:07PM +0200, Oleksandr Andrushchenko wrote: > On 03/05/2018 11:32 AM, Daniel Vetter wrote: > > On Wed, Feb 21, 2018 at 10:03:41AM +0200, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > Implement GEM

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

On 03/06/2018 08:08 AM, Daniel Vetter wrote: On Mon, Mar 05, 2018 at 11:01:42AM +0100, Thomas Hellstrom wrote: On 03/05/2018 10:39 AM, Daniel Vetter wrote: On Mon, Mar 05, 2018 at 10:22:09AM +0100, Thomas Hellstrom wrote: On 03/05/2018 09:37 AM, Daniel Vetter wrote: On Wed, Feb 28, 2018 at

Re: [PATCH 7/9] drm/xen-front: Implement KMS/connector handling

On Mon, Mar 05, 2018 at 02:59:23PM +0200, Oleksandr Andrushchenko wrote: > On 03/05/2018 11:23 AM, Daniel Vetter wrote: > > On Wed, Feb 21, 2018 at 10:03:40AM +0200, Oleksandr Andrushchenko wrote: > > > From: Oleksandr Andrushchenko > > > > > > Implement kernel

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v3)

Patch looks ok to me, Reviewed-by: Chunming Zhou , and it’s better to get others RB as well. Regards, David Zhou -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Monk Liu Sent: Tuesday, March 06, 2018 3:01 PM To:

Re: [PATCH v3 0/2] Parfait changes

On Mon, Mar 05, 2018 at 11:14:11AM -0500, Joe Moriarty wrote: > On 2/20/2018 2:11 PM, Joe Moriarty wrote: > > The following patch(s) are bugs found by the static compiler > > 'Parfait'. Care was taken to make sure false positive results > > were removed from this patchset. > > > > Parfait

[PATCH] dma-buf/reservation: should keep later one in add fence(v3)

v2: still check context first to avoid warning from dma_fence_is_later apply this fix in add_shared_replace as well v3: use a bool falg to indict if fence is need to insert to new slot and ignore it if it is an eld fence compared with the one with the same context in old->shared Change-Id:

Re: [PATCH v3 1/8] drm/blend: Add a generic alpha property

On Mon, Mar 05, 2018 at 12:08:12PM +0200, Laurent Pinchart wrote: > Hi Daniel, > > On Monday, 5 March 2018 10:58:41 EET Daniel Vetter wrote: > > On Wed, Feb 21, 2018 at 02:07:57PM +0100, Maxime Ripard wrote: > > > On Mon, Feb 19, 2018 at 10:58:40PM +0100, Daniel Vetter wrote: > > >> On Mon, Feb

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

Make sense, will give v3 -Original Message- From: Zhou, David(ChunMing) Sent: 2018年3月6日 14:08 To: Liu, Monk ; Zhou, David(ChunMing) ; dri-de...@freedesktop.org Subject: Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2) On

Re: [PATCH 1/1] drm: Add dirty_rects atomic blob property for drm_plane

On Mon, Mar 05, 2018 at 11:01:42AM +0100, Thomas Hellstrom wrote: > On 03/05/2018 10:39 AM, Daniel Vetter wrote: > > On Mon, Mar 05, 2018 at 10:22:09AM +0100, Thomas Hellstrom wrote: > > > On 03/05/2018 09:37 AM, Daniel Vetter wrote: > > > > On Wed, Feb 28, 2018 at 09:10:46PM +, Deepak Singh

Re: [PULL] drm-misc-next

On Tue, Mar 6, 2018 at 12:20 AM, Sean Paul wrote: > On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote: >> On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: >>> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote: >>> > >>>

[Bug 105355] [BAT] igt@kms_cursor_legacy@* - fail - general protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000]

https://bugs.freedesktop.org/show_bug.cgi?id=105355 Marta Löfstedt changed: What|Removed |Added Whiteboard||ReadyForDev

[Bug 105355] [BAT] igt@kms_cursor_legacy@* - fail - general protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000]

https://bugs.freedesktop.org/show_bug.cgi?id=105355 Bug ID: 105355 Summary: [BAT] igt@kms_cursor_legacy@* - fail - general protection ip:7f6678e12d13 sp:7ffd689de6e0 error:0 in ld-2.26.so[7f6678e06000+27000] Product: DRI

[radeon-alex:drm-next-4.17-wip 458/469] drivers/gpu/drm/amd/amdgpu/../powerplay/hwmgr/hwmgr.c:897:6: error: implicit declaration of function 'amdgpu_acpi_is_pcie_performance_request_supported'; did yo

tree: git://people.freedesktop.org/~agd5f/linux.git drm-next-4.17-wip head: 7f462340284582c0180384c046ddd6dda03888b1 commit: e1deba285156fb4023bb48f22068de5b60e34e15 [458/469] drm/amd/pp: Use amdgpu acpi helper functions in powerplay config: sparc64-allyesconfig (attached as .config)

Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

On 2018年03月06日 13:59, Liu, Monk wrote: - if (check->context == fence->context || + if ((check->context == fence->context && + dma_fence_is_later(fence, check)) || We still need do more for !dma_fence_is_later(fence, check) case, in which, we will

RE: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

> > - if (check->context == fence->context || > + if ((check->context == fence->context && > + dma_fence_is_later(fence, check)) || We still need do more for !dma_fence_is_later(fence, check) case, in which, we will don't need add new fence to resv

Re: [PATCH] dma-buf/reservation: should keep later one in add fence(v2)

On 2018年03月06日 11:53, Monk Liu wrote: v2: still check context first to avoid warning from dma_fence_is_later apply this fix in add_shared_replace as well Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 Signed-off-by: Monk Liu --- drivers/dma-buf/reservation.c | 6

[Bug 105354] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105354 --- Comment #1 from mikhail.v.gavri...@gmail.com --- Created attachment 137811 --> https://bugs.freedesktop.org/attachment.cgi?id=137811=edit dmesg -- You are receiving this mail because: You are the assignee for the

[PATCH] dma-buf/reservation: should keep later one in add fence(v2)

v2: still check context first to avoid warning from dma_fence_is_later apply this fix in add_shared_replace as well Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 Signed-off-by: Monk Liu --- drivers/dma-buf/reservation.c | 6 -- 1 file changed, 4 insertions(+), 2

[Bug 105354] RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu]

https://bugs.freedesktop.org/show_bug.cgi?id=105354 Bug ID: 105354 Summary: RIP: dm_update_crtcs_state+0x36b/0x3f0 [amdgpu] Product: DRI Version: XOrg git Hardware: Other OS: All Status: NEW Severity:

RE: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

Yeah, right -Original Message- From: Zhou, David(ChunMing) Sent: 2018年3月6日 11:38 To: Liu, Monk ; dri-devel@lists.freedesktop.org Subject: Re: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace On 2018年03月06日 11:09, Monk Liu wrote: >

Re: [PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

On 2018年03月06日 11:09, Monk Liu wrote: Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 Signed-off-by: Monk Liu --- drivers/dma-buf/reservation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/reservation.c

[PATCH] dma-buf/reservation: should keep the new fence in add_shared_inplace

Change-Id: If6a979ba9fd6c923b82212f35f07a9ff31c86767 Signed-off-by: Monk Liu --- drivers/dma-buf/reservation.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c index 314eb10..29b7e45 100644 ---

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

On Mon, Mar 5, 2018 at 10:15 PM, Eric Anholt wrote: > Stefan Schake writes: > >> We allow alpha formats on the primary plane but a partially transparent >> framebuffer will cause a corrupted display. With this change black pixels >> are output instead, in

Re: [DPU PATCH 05/11] drm/msm: Mark the crtc->state->event consumed

On 2018-02-28 11:19, Sean Paul wrote: Don't leave the event != NULL once it's consumed, this is used a signal to the atomic helpers that the event will be handled by the driver. Change-Id: Ib934fb2e97bacbb4a1f9c780cc7369c2bb98ed50 Signed-off-by: Sean Paul Reviewed-by:

RE: [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

Patch 1: Acked-by: Roger He Patch 2~5: Reviewed-by: Roger He -Original Message- From: dri-devel [mailto:dri-devel-boun...@lists.freedesktop.org] On Behalf Of Christian K?nig Sent: Monday, March 05, 2018 8:07 PM To: dri-devel@lists.freedesktop.org;

[PATCH 0/3] drm/vc4: Improve alpha format plane support

This series improves the handling of alpha formats with the VC4 HVS compositor. Alpha formats are marked as premultiplied as is standard for DRM. Further fix a display corruption issue when planes with per-pixel alpha try blending from the (nonexistent) background by selectively enabling a black

[PATCH 3/3] drm/vc4: Enable background color fill when necessary

Using the hint from the plane state, we turn on the background color to avoid display corruption from planes blending with the background. Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_crtc.c | 22 ++ 1 file changed, 22 insertions(+) diff

[PATCH 2/3] drm/vc4: Check if plane requires background fill

Considering a single plane only, we have to enable background color when the plane has an alpha format and could be blending from the background or when it doesn't cover the entire screen. Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_drv.h | 6 ++

[PATCH 1/3] drm/vc4: Set premultiplied for alpha formats

Alpha formats in DRM are assumed to be premultiplied, so we should be setting the PREMULT bit in the plane configuration for HVS. Signed-off-by: Stefan Schake --- drivers/gpu/drm/vc4/vc4_plane.c | 3 ++- drivers/gpu/drm/vc4/vc4_regs.h | 1 + 2 files changed, 3

Re: [PATCH 3/4] drm/pl111: Handle the RealView variant separately

Linus Walleij writes: > We want to cut down the default bpp to 16 on the RealView so > we can have a 1024x768 framebuffer console by default. The > memory bandwidth limitations makes this not work with the > PL111 default of 32bpp. > > This builds on top of the earlier

Re: [PATCH 2/4] drm/pl111: Use max memory bandwidth for resolution

Linus Walleij writes: > We were previously selecting 1024x768 and 32BPP as the default > set-up for the PL111 consumers. > > This does not work on elder systems: the device tree bindings > support a property "max-memory-bandwidth" in bytes/second that > states that if

linux-next: manual merge of the mali-dp tree with the drm-misc tree

Hi Liviu, Today's linux-next merge of the mali-dp tree got a conflict in: drivers/gpu/drm/arm/malidp_planes.c between commit: 81af63a4af82 ("drm: Don't pass clip to drm_atomic_helper_check_plane_state()") from the drm-misc tree and commit: 4968211e7b8f ("drm: mali-dp: Uninitialized

[Bug 98974] Can't see borders/empires in Stellaris

https://bugs.freedesktop.org/show_bug.cgi?id=98974 --- Comment #21 from John --- I now see borders with versions: Stellaris v2.0.1 Linux 4.15.6 mesa 17.3.6 xorg 1.19.6 -- You are receiving this mail because: You are the assignee for the

Re: [PULL] drm-misc-next

On Mon, Mar 5, 2018 at 12:10 AM, Daniel Vetter wrote: > On Fri, Mar 02, 2018 at 04:22:15PM -0500, Sean Paul wrote: >> On Wed, Feb 28, 2018 at 3:34 PM, Sean Paul wrote: >> > >> > Hi Dave, >> > Here's this weeks pull, relatively small when you pull out the

Re: [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

On Mon, Mar 05, 2018 at 02:51:46PM -0800, Rafael Antognolli wrote: > This is matching both the kernel and the spec. > > Reviewed-by: Rafael Antognolli . pushed, thanks > > On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote: > > Let's sync CNL ids with

[Bug 105352] [r600g] OpenGL ES fails to start on RV730

https://bugs.freedesktop.org/show_bug.cgi?id=105352 Eugene changed: What|Removed |Added CC||ken20...@ukr.net

[Bug 105352] [r600g] OpenGL ES fails to start on RV730

https://bugs.freedesktop.org/show_bug.cgi?id=105352 Bug ID: 105352 Summary: [r600g] OpenGL ES fails to start on RV730 Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

Ville Syrjälä writes: > On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > To make life easier for drivers, let's have the core

[PATCH v8 4/4] drm: rcar-du: Convert LVDS encoder code to bridge driver

The LVDS encoders used to be described in DT as part of the DU. They now have their own DT node, linked to the DU using the OF graph bindings. This allows moving internal LVDS encoder support to a separate driver modelled as a DRM bridge. Backward compatibility is retained as legacy DT is patched

[PATCH v8 3/4] drm: rcar-du: Fix legacy DT to create LVDS encoder nodes

The internal LVDS encoders now have their own DT bindings. Before switching the driver infrastructure to those new bindings, implement backward-compatibility through live DT patching. Patching is disabled and will be enabled along with support for the new DT bindings in the DU driver.

[PATCH v8 2/4] dt-bindings: display: renesas: Deprecate LVDS support in the DU bindings

The internal LVDS encoders now have their own DT bindings, representing them as part of the DU is deprecated. Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring Reviewed-by: Niklas Söderlund

[PATCH v8 0/4] R-Car DU: Convert LVDS code to bridge driver

Hello, This patch series addresses a design mistake that dates back from the initial DU support. Support for the LVDS encoders, which are IP cores separate from the DU, was bundled in the DU driver. Worse, both the DU and LVDS were described through a single DT node. To fix the, patches 1/4 and

[PATCH v8 1/4] dt-bindings: display: renesas: Add R-Car LVDS encoder DT bindings

The Renesas R-Car Gen2 and Gen3 SoCs have internal LVDS encoders. Add corresponding device tree bindings. Signed-off-by: Laurent Pinchart Reviewed-by: Rob Herring Reviewed-by: Niklas Söderlund

Re: [PATCH libdrm] intel/intel_chipset.h: Sync Cannonlake IDs.

This is matching both the kernel and the spec. Reviewed-by: Rafael Antognolli . On Wed, Feb 14, 2018 at 05:42:24PM -0800, Rodrigo Vivi wrote: > Let's sync CNL ids with Spec and kernel. > > Sync with kernel commit '3f43031b1693 ("drm/i915/cnl: > Add Cannonlake PCI

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On 2018-03-05 04:33 PM, Alex Deucher wrote: > On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä > wrote: >> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >>> Ville Syrjala writes: >>> From: Ville Syrjälä

Re: [PATCH] drm/atomic: Add new reverse iterator over all plane state (V2)

On 2018-03-01 02:56 AM, S, Shirish wrote: > From: Shirish S > > Add reverse iterator for_each_oldnew_plane_in_state_reverse to compliment the > for_each_oldnew_plane_in_state way or reading plane states. > > The plane states are required to be read in reverse order for amd

Re: [PATCH v5 1/6] dt-bindings: add bindings for USB physical connector

On Tue, Feb 27, 2018 at 08:11:29AM +0100, Andrzej Hajda wrote: > These bindings allow to describe most known standard USB connectors > and it should be possible to extend it if necessary. > USB connectors, beside USB can be used to route other protocols, > for example UART, Audio, MHL. In such

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

https://bugs.freedesktop.org/show_bug.cgi?id=102553 --- Comment #6 from Alex Deucher --- See if you can find out where it's crashing. See: https://stackoverflow.com/questions/13468286/how-to-read-understand-analyze-and-debug-a-linux-kernel-panicand -- You are receiving

[Bug 103234] KWin crashed when Alt+Tab-ing through open windows

https://bugs.freedesktop.org/show_bug.cgi?id=103234 --- Comment #14 from Roman Gilg --- I have a RFC with a potential fix on the mailing list: https://lists.freedesktop.org/archives/mesa-dev/2018-March/187675.html -- You are receiving this mail because: You are the assignee

[PATCH v2 2/3] drm/i915: Eliminate the horrendous format check code

From: Ville Syrjälä Now that the core makes sure that the pixel format is supported by at least one plane, we can eliminate the hand rolled code for the same thing in i915. The way we were doing was extremely inconvenient because not only did you have to add the

[PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

From: Ville Syrjälä To make life easier for drivers, let's have the core check that the requested pixel format is supported by at least one plane when creating a new framebuffer. v2: Accept anyformat if the driver doesn't do planes (Eric)

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä wrote: > On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: >> Ville Syrjala writes: >> >> > From: Ville Syrjälä >> > >> > To make life easier for

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #30 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Using UMR please provide following data: sudo umr -O many,bits -r *.gfx80.mmGRBM_STATUS sudo umr -O many,bits -r *.gfx80.HEADER_DUMP sudo umr -O many,bits -r

Re: [PATCH v2 0/7] Modernize vga_switcheroo by using device link for HDA

Hi Lukas, Sorry for the delay, I finally found some time to reviewd and test the patches and found some issues (some of them might already be present in v4.15 without your patches though, I did not try). Test environment: - Branch switcheroo_devlink_v2 (commit v4.15-20-gb33d50c5c6ad) - Laptop:

Re: [PATCH] drm/vc4: Ignore alpha on primary plane

Stefan Schake writes: > We allow alpha formats on the primary plane but a partially transparent > framebuffer will cause a corrupted display. With this change black pixels > are output instead, in line with the behavior for other DRM drivers. > > Signed-off-by: Stefan Schake

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: > Ville Syrjala writes: > > > From: Ville Syrjälä > > > > To make life easier for drivers, let's have the core check that the > > requested pixel format is supported by at

[ANNOUNCE] libdrm 2.4.91

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andrey Grodzovsky (1): amdgpu: Fix mistake in initial hole size calculation. Christian König (3): amdgpu: mostly revert "use the high VA range if possible v2" amdgpu: add AMDGPU_VA_RANGE_HIGH amdgpu: fix "add

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

Ville Syrjala writes: > From: Ville Syrjälä > > To make life easier for drivers, let's have the core check that the > requested pixel format is supported by at least one plane when creating > a new framebuffer. > > Signed-off-by:

Re: [PATCH 4/5] drm/ttm: add ttm_sg_tt_init

On Mon, Mar 5, 2018 at 10:06 PM, Christian König wrote: > Ping? On a quick look, it looks like both are used sometimes. I believe this had something to do with the addition of Tegra support, but I'll need some time to look into the details of why/how these things are

[Bug 105083] Random blinking display

https://bugs.freedesktop.org/show_bug.cgi?id=105083 --- Comment #14 from denisgolo...@yandex.ru --- (In reply to Harry Wentland from comment #13) > (In reply to denisgolovan from comment #11) > > (In reply to Harry Wentland from comment #10) > > Some areas just > > stay not affected as if gamma

Re: [PATCH 1/2] dt-bindings: Document qcom,adreno-gmu

On Fri, Mar 2, 2018 at 3:56 PM, Jordan Crouse wrote: > Document the device tree bindings for the Adreno GMU device > available on Adreno a6xx targets. > > Change-Id: I3cfd5fb35ab0045e39905ff12393006e60f1a124 Gerrit! > Signed-off-by: Jordan Crouse

Re:

Den 05.03.2018 18.06, skrev Meghana Madhyastha: linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul ,ker...@martin.sperl.org Cc: Bcc: Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers Reply-To: In-Reply-To:

[Bug 105262] [R600] [BISECTED] ttf fonts are invisible in many programs

https://bugs.freedesktop.org/show_bug.cgi?id=105262 Roland Scheidegger changed: What|Removed |Added Resolution|--- |FIXED

Re: [PATCH 4/5] drm/armada: Use drm_mode_get_hv_timing() to populate plane clip rectangle

On Mon, Mar 05, 2018 at 09:41:43AM +0100, Daniel Vetter wrote: > On Tue, Jan 23, 2018 at 07:08:56PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Use drm_mode_get_hv_timing() to fill out the plane clip rectangle. > > > > Since armada isn't atomic

[Bug 101900] No HDMI HBR audio on Polaris (no TrueHD, no Atmos, no Neo:X, no HD Master audio) and static noise in sound when LPCM on amdgpu Xorg driver

https://bugs.freedesktop.org/show_bug.cgi?id=101900 --- Comment #32 from Direx --- (In reply to Andrew Nelson from comment #31) > I have been running into the same issue. The problem seems to be that AMDGPU > is reporting that it supports 7 speakers instead of 8 in the

Re: [PATCH] drm: vc4_hdmi: Replace long udelay with usleep_range

Stefan Wahren writes: > Since we aren't in atomic context replace this long udelay with a > usleep_range. Reviewed and pushed to drm-misc-next. Thanks! signature.asc Description: PGP signature ___ dri-devel mailing list

Re: [PATCH v2] drm/vc4: Advertise supported modifiers for planes

Daniel Stone writes: > The IN_FORMATS blob allows the kernel to advertise to userspace which > format/modifier combinations are supported, per plane. Use this to > advertise that we support both T_TILED and linear. > > v2: > - Only advertise T_TILED for RGB (Eric) > -

[PATCH v3] drm/mali-dp: Fix malidp_atomic_commit_hw_done() for event sending.

Mali DP hardware has a 'go' bit (config_valid) for making the new scene parameters active at the next page flip. The problem with the current code is that the driver first sets this bit and then proceeds to wait for confirmation from the hardware that the configuration has been updated before

Re: [PATCHv2 0/7] cec: add error injection support

Hans, > Special thanks go to Wolfram Sang since his i2c error injection > presentation at the Embedded Linux Conference Europe 2017 inspired > me to switch to debugfs for this instead of using ioctls. You are very welcome! I am glad the presentation did inspire you. Happy hacking, Wolfram

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #29 from Andrey Grodzovsky (andrey.grodzov...@amd.com) --- Thanks for the logs, just to clear things out, you keep saying 'crash', but you actually mean hang, right ? Or do observe actual Xorg process crash ? To answer for sure check

Re: [PATCH v2 2/2] drm: rcar-du: lvds: add R8A77970 support

Hi Sergei, Thank you for the patch. On Thursday, 1 March 2018 20:10:16 EET Sergei Shtylyov wrote: > Add support for the R-Car V3M (R8A77970) SoC to the LVDS encoder driver. > Note that there are some differences with the other R-Car gen3 SoCs, e.g. > LVDPLLCR has the same layout as in the R-Car

[Bug 104608] [r600, RV635] Removing radeon module results in BUG: unable to handle kernel NULL pointer dereference at 0000000000000258

https://bugs.freedesktop.org/show_bug.cgi?id=104608 Vedran Miletić changed: What|Removed |Added Status|NEW |RESOLVED

[no subject]

linux-...@vger.kernel.org,Noralf Trønnes ,Sean Paul ,ker...@martin.sperl.org Cc: Bcc: Subject: Re: [PATCH v2 0/2] Chunk splitting of spi transfers Reply-To: In-Reply-To: On Sun, Mar 04, 2018 at

[Bug 103953] [DC] Polaris10: Missing modes when enabling DC

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

Re: [PATCH v3 0/2] Parfait changes

On 2/20/2018 2:11 PM, Joe Moriarty wrote: The following patch(s) are bugs found by the static compiler 'Parfait'. Care was taken to make sure false positive results were removed from this patchset. Parfait Overview

Re: [PATCH] drm/bridge: sii902x: Retry status read after DDI I2C

On Mon, Mar 05, 2018 at 11:17:02AM +0100, Linus Walleij wrote: > The following happens when connection a DVI output driven > from the SiI9022 using a DVI-to-VGA adapter plug: > > i2c i2c-0: sendbytes: NAK bailout. > i2c i2c-0: sendbytes: NAK bailout. > > Then no picture. Apparently the I2C

Re: [PATCH 2/2] arm64: dts: sdm845: Support GPU/GMU

On Mon, Mar 05, 2018 at 10:12:21AM +0530, Viresh Kumar wrote: > On 02-03-18, 14:56, Jordan Crouse wrote: > > Add the nodes and other bits to describe the Adreno GPU and GMU > > devices. > > > > Change-Id: Ibf4dc0ebb0ac03d8b6b8e65747e142c440e70b0a > > Remove it ? * Shakes fist at Gerrit * > >

Re: [PATCH 3/3] drm/msm: Add A6XX device support

On Mon, Mar 05, 2018 at 10:09:38AM +0530, Viresh Kumar wrote: > On 02-03-18, 14:43, Jordan Crouse wrote: > > +static int a6xx_gmu_build_freq_table(struct device *dev, unsigned long > > *freqs, > > + u32 size) > > +{ > > + int count = dev_pm_opp_get_opp_count(dev); > > + struct

Re: [PATCH 1/3] PM / OPP: Add dev_pm_opp_get_np()

On Mon, Mar 05, 2018 at 10:07:08AM +0530, Viresh Kumar wrote: > On 02-03-18, 14:43, Jordan Crouse wrote: > > Add a function to return the device node associated with a > > specific opp which will facilitate detailing with custom > > properties in client drivers. > > > > Signed-off-by: Jordan

[PATCH 3/3] drm: Fix some coding style issues

From: Ville Syrjälä Put an empty line between the variable declarations and the code, and use tabs for alignment. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/drm_framebuffer.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[PATCH 2/3] drm/i915: Eliminate the horrendous format check code

From: Ville Syrjälä Now that the core makes sure that the pixel format is supported by at least one plane, we can eliminate the hand rolled code for the same thing in i915. The way we were doing was extremely inconvenient because not only did you have to add the

[PATCH 1/3] drm: Make sure at least one plane supports the fb format

From: Ville Syrjälä To make life easier for drivers, let's have the core check that the requested pixel format is supported by at least one plane when creating a new framebuffer. Signed-off-by: Ville Syrjälä ---

[Bug 105083] Random blinking display

https://bugs.freedesktop.org/show_bug.cgi?id=105083 --- Comment #13 from Harry Wentland --- (In reply to denisgolovan from comment #11) > (In reply to Harry Wentland from comment #10) > Some areas just > stay not affected as if gamma change specifically disabled for them.

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #28 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Here you go! umr dump 0 is a crash just after starting X umr dump 1 is a crash after running dmesg inside xterm just after starting X Thanks! -- You are receiving this mail

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

https://bugzilla.kernel.org/show_bug.cgi?id=198883 --- Comment #27 from Ricardo Ribalda (ricardo.riba...@gmail.com) --- Created attachment 274537 --> https://bugzilla.kernel.org/attachment.cgi?id=274537=edit umr dump 1 -- You are receiving this mail because: You are watching the assignee of

  1   2   >