[Bug 100288] clover unable to run OpenCL kernels since 03127bb radeonsi: compile all TGSI compute shaders asynchronously

https://bugs.freedesktop.org/show_bug.cgi?id=100288 --- Comment #1 from Marek Olšák --- It should be fixed by: https://cgit.freedesktop.org/mesa/mesa/commit/?id=827ae79b2cQ6cf53e26b3467e4c3965ce6acab3c6 -- You are receiving this mail because: You are the assignee for the

[PATCH v3 3/3] drm: Clarify the role of plane_state argument to drm_simple update().

Like the atomic update hook it's wrapping, the plane_state is the old one, and the new one is in plane->state. Both msxfb and tinydrm use it correctly, but I mistook it for the new state in pl111 due to its naming. Signed-off-by: Eric Anholt ---

[PATCH v3 2/3] drm/pl111: Initial drm/kms driver for pl111

From: Tom Cooksey This is a modesetting driver for the pl111 CLCD display controller found on various ARM platforms such as the Versatile Express. The driver has only been tested on the bcm911360_entphn platform so far, with PRIME-based buffer sharing between vc4 and clcd.

[PATCH v3 1/3] video: ARM CLCD: Move registers to a separate header.

We'd like to reuse these register definitions for the DRM CLCD driver, but there's a bunch of fbdev-specific code in the current header. Signed-off-by: Eric Anholt --- include/linux/amba/clcd-regs.h | 76 ++ include/linux/amba/clcd.h

Re: [PATCH v3 5/9] gpu: ipu-v3: document valid IPUv3 compatibles and extend for i.MX6 QuadPlus

On Tue, Mar 14, 2017 at 11:38:44AM +0100, Philipp Zabel wrote: > From: Lucas Stach > > Document the valid compatible strings for the IPUv3. > > On i.MX6 QuadPlus the IPU needs to know which PRG has to be > used for this IPU instance. Add a "fsl,prg" property containing >

[rfc/repost] amdgpu/sync_file shared semaphores

This is a repost of the file_sync semaphore support. The main difference in this patch is patch1 does a lot better at handling NULL fences in some places. The poll code and ioctls should handle ending up with fence being NULL properly now. Dave. ___

[PATCH 3/4] amdgpu/cs: split out fence dependency checking

From: Dave Airlie This just splits out the fence depenency checking into it's own function to make it easier to add semaphore dependencies. Signed-off-by: Dave Airlie --- drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 86 +++--- 1

[PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

From: Dave Airlie This patch allows the underlying fence in a sync_file to be changed or set to NULL. This isn't currently required but for Vulkan semaphores we need to be able to swap and reset the fence. In order to faciliate this, it uses rcu to protect the fence, along

[PATCH 2/4] sync_file: add replace and export some functionality (v2)

From: Dave Airlie Using sync_file to back vulkan semaphores means need to replace the fence underlying the sync file. This replace function removes the callback, swaps the fence, and returns the old one. This also exports the alloc and fdget functionality for the semaphore

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

On Mon, Mar 20, 2017 at 05:03:04PM +1000, Dave Airlie wrote: > From: Dave Airlie > > This patch allows the underlying fence in a sync_file to be changed > or set to NULL. This isn't currently required but for Vulkan > semaphores we need to be able to swap and reset the fence.

Re: [PATCH] drm: add check for plane functions

On Mon, Mar 20, 2017 at 09:58:01AM +0530, Shirish S wrote: > First of all, thanks for your comments/insights. > > On Sat, Mar 18, 2017 at 12:59 AM, Eric Anholt wrote: > > Ville Syrjälä writes: > > > >> On Fri, Mar 17, 2017 at 05:57:52PM +0100,

Re: linux-next: build failure after merge of the drm tree

On Mon, Mar 20, 2017 at 9:03 AM, Daniel Vetter wrote: > On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell > wrote: >> This cherry picking of fixes from new development back to Linus' tree >> can be a real pain when so many other changes happen in

[PATCH 4/4] amdgpu: use sync file for shared semaphores

From: Dave Airlie This creates a new interface for amdgpu with ioctls to create/destroy/import and export shared semaphores using sem object backed by the sync_file code. The semaphores are not installed as fd (except for export), but rather like other driver internal objects

Re: [PATCH 1/3] drm/etnaviv: submit support for in-fences

On Fri, Mar 17, 2017 at 11:00:44AM -0300, Gustavo Padovan wrote: > 2017-03-16 Philipp Zabel : > > > Hi Gustavo, > > > > On Mon, 2017-03-13 at 14:37 -0300, Gustavo Padovan wrote: > > [...] > > > I was thinking on some function that would iterate over all fences in > > >

Re: linux-next: build failure after merge of the drm tree

On Mon, Mar 20, 2017 at 1:51 AM, Stephen Rothwell wrote: > This cherry picking of fixes from new development back to Linus' tree > can be a real pain when so many other changes happen in the same files. One possible fix for this would be if you reuse our rerere cache. The

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

On Mon, Mar 20, 2017 at 05:03:04PM +1000, Dave Airlie wrote: > From: Dave Airlie > > This patch allows the underlying fence in a sync_file to be changed > or set to NULL. This isn't currently required but for Vulkan > semaphores we need to be able to swap and reset the fence.

[PATCH] drm/i915: use static const array for PICK macro

The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization to shrink the i915 kernel module by around 1000 bytes. However, the downside is a size regression with CONFIG_KASAN, as I found from stack size warnings with gcc-7.0.1: before: drivers/gpu/drm/i915/intel_dpll_mgr.c: In

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 9:55 AM, Emil Velikov wrote: > Seems like we ended up all over the place, so let me try afresh. > > Above all: > - Saying "I don't care" about your users is arrogant - let us _not_ > do that, please ? > Even Linux distribution maintainers have

Re: [PATCH 01/41] drm/panel: simple: Change mode for Sharp lq123p1jx31

On Mon, Mar 20, 2017 at 9:37 AM, Doug Anderson wrote: > Hi, > > On Mon, Mar 20, 2017 at 6:59 AM, Thierry Reding > wrote: > > On Thu, Mar 09, 2017 at 11:32:16PM -0500, Sean Paul wrote: > >> Change the mode for Sharp lq123p1jx31 panel to something

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 20 March 2017 at 18:30, Matt Turner wrote: > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov > wrote: >> Seems like we ended up all over the place, so let me try afresh. >> >> Above all: >> - Saying "I don't care" about your users is arrogant -

Re: [PATCH 01/41] drm/panel: simple: Change mode for Sharp lq123p1jx31

Hi, On Mon, Mar 20, 2017 at 1:01 PM, Stéphane Marchesin wrote: >> 1. We have validated with the panel manufacturer that 266.667 MHz is >> valid and within spec. The panel's datasheet itself says something >> like "if you want to try other values you can, but they might not

[Bug 100270] power usage increase by approx 4W between kernel 4.7.8 and 4.8.5

https://bugs.freedesktop.org/show_bug.cgi?id=100270 brett.hass...@gmail.com changed: What|Removed |Added CC||alexdeuc...@gmail.com ---

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Tue, Mar 21, 2017 at 08:28:22AM +1100, Timothy Arceri wrote: > > > On 21/03/17 06:39, Emil Velikov wrote: > > On 20 March 2017 at 18:30, Matt Turner wrote: > > > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov > > > wrote: > > > > Seems like we

[PATCHv2 2/2] drm/panel: simple: Add support for Winstar WF35LTIACD

This adds support for the Winstar Display Co. WF35LTIACD 3.5" QVGA TFT LCD panel, which can be supported by the simple panel driver. Signed-off-by: Richard Genoud --- Changes since v1: Add power-supply property and an example in documentation

Re: GEM allocation for para-virtualized DRM driver

On 03/20/2017 08:52 PM, Rob Clark wrote: On Mon, Mar 20, 2017 at 2:25 PM, Oleksandr Andrushchenko wrote: On 03/20/2017 08:17 PM, Rob Clark wrote: On Mon, Mar 20, 2017 at 2:01 PM, Oleksandr Andrushchenko wrote: On 03/20/2017 07:38 PM, Rob Clark wrote:

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

On Mon, Mar 20, 2017 at 10:19:35AM +0100, Lucas Stach wrote: > Yes, probably we want to have both at some point. The cooling-device > stuff is about throttling the GPU when the SoC reaches critical > temperatures. > > The devfreq governors are about providing exactly the right performance >

i915 (ivy bridge) + 4.10.3 + gimp = BUG in list_move_tail()

Hi, After a kernel update from v4.9.10 to v4.10.3, any time I bring out the gimp, the i915 driver NULL-pointer dereferences something in list_move_tail(), somewhere in i915_gem_evict_for_vma(). I'm providing the kernel log, if more is needed (say you aren't aware of this regression) I'm

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

On Sun, Mar 19, 2017 at 01:03:42PM -0700, Chris Healy wrote: > I don't have any input on this binary divider subject but I do want to > bring up some observations regarding Etnaviv GPU power management that > seems relevant. GPU cooling isn't really to do with GPU power management, it's more to

[PATCH] drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

Vendor specific infoframe is mandatory for 4K2K resolution. Without this, the HDMI protocol compliance fails. Signed-off-by: Nickey Yang --- drivers/gpu/drm/bridge/dw-hdmi.c | 50 drivers/gpu/drm/bridge/dw-hdmi.h | 4 2

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 11:30:25AM -0700, Matt Turner wrote: > On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov > wrote: > > Seems like we ended up all over the place, so let me try afresh. > > > > Above all: > > - Saying "I don't care" about your users is arrogant - let

Re: [PATCH v2] drm/exynos/dsi: make te-gpios optional

2017년 03월 15일 20:20에 Andrzej Hajda 이(가) 쓴 글: > DSI forwards te-gpios interrupts to display controller, but if display > controller works in HW-TRIGGER mode this interrupt is not necessary. > Making te-gpios property optional allows to avoid generating spare > interrupts. > With this patch we can

Re: [PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

* Tomi Valkeinen [170320 09:38]: > On 20/03/17 18:14, Tony Lindgren wrote: > > * Tomi Valkeinen [170320 04:10]: > >> On 05/03/17 02:43, Sebastian Reichel wrote: > >>> This reverts commit 5a35876e2830511cb8110667fc426c6a6165a593. > >>> > >>> Revert

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On 21/03/17 06:39, Emil Velikov wrote: On 20 March 2017 at 18:30, Matt Turner wrote: On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov wrote: Seems like we ended up all over the place, so let me try afresh. Above all: - Saying "I don't care"

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Mar 20, 2017 at 02:26:16PM +, Russell King - ARM Linux wrote: > On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > > From: Hans Verkuil > > > > Add support for video hotplug detect and EDID/ELD notifiers, which is used > > to convey information

Re: [PATCH v2] drm/bridge: dw_hdmi: support i2c extended read mode

Hi Nickey, On 20-03-2017 02:57, Nickey Yang wrote: > "I2C Master Interface Extended Read Mode" implements a segment > pointer-based read operation using the Special Register configuration. > > This patch fix >

[Bug 100288] clover unable to run OpenCL kernels since 03127bb radeonsi: compile all TGSI compute shaders asynchronously

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

Re: [PATCH v2] drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

Hi Nickey, On 20-03-2017 11:39, Nickey Yang wrote: > Vendor specific infoframe is mandatory for 4K2K resolution. > Without this, the HDMI protocol compliance fails. > > Signed-off-by: Nickey Yang Reviewed-by: Jose Abreu Best regards, Jose

Re: [PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

* Tomi Valkeinen [170320 04:10]: > On 05/03/17 02:43, Sebastian Reichel wrote: > > This reverts commit 5a35876e2830511cb8110667fc426c6a6165a593. > > > > Revert the removal of manual update display support in > > preparation for DSI command mode panels. > > I think it's

[PATCH v2] drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

Vendor specific infoframe is mandatory for 4K2K resolution. Without this, the HDMI protocol compliance fails. Signed-off-by: Nickey Yang --- drivers/gpu/drm/bridge/dw-hdmi.c | 47 drivers/gpu/drm/bridge/dw-hdmi.h | 4 2

[PATCH v2] drm/bridge: dw_hdmi: support i2c extended read mode

"I2C Master Interface Extended Read Mode" implements a segment pointer-based read operation using the Special Register configuration. This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned "The current implementation does not support "I2C Master Interface Extended Read Mode" to read

Re: [PATCHv2 1/4] video: add hotplug detect notifier support

On Mon, Jan 02, 2017 at 03:19:04PM +0100, Hans Verkuil wrote: > From: Hans Verkuil > > Add support for video hotplug detect and EDID/ELD notifiers, which is used > to convey information from video drivers to their CEC and audio counterparts. > > Based on an earlier

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

I don't have any input on this binary divider subject but I do want to bring up some observations regarding Etnaviv GPU power management that seems relevant. I've done some comparisons between the Freescale Vivante GPU driver stack (1) and the Marvell PXA1928 Vivante GPU driver stack (2) and see

Re: GEM allocation for para-virtualized DRM driver

On 03/20/2017 07:38 PM, Rob Clark wrote: On Mon, Mar 20, 2017 at 1:18 PM, Oleksandr Andrushchenko wrote: On 03/18/2017 02:22 PM, Rob Clark wrote: On Fri, Mar 17, 2017 at 1:39 PM, Oleksandr Andrushchenko wrote: Hello, I am writing a para-virtualized

[PATCH v6] drm/rockchip: Refactor the component match logic.

Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by: Jeffy Chen Reviewed-by: Andrzej Hajda Acked-by:

Re: [PATCH] drm: bridge: dw-hdmi: add HDMI vendor specific infoframe config

Hi Nickey, On 20-03-2017 06:10, Nickey Yang wrote: > Vendor specific infoframe is mandatory for 4K2K resolution. > Without this, the HDMI protocol compliance fails. > > Signed-off-by: Nickey Yang > --- > drivers/gpu/drm/bridge/dw-hdmi.c | 50 >

Re: GEM allocation for para-virtualized DRM driver

On 03/20/2017 08:17 PM, Rob Clark wrote: On Mon, Mar 20, 2017 at 2:01 PM, Oleksandr Andrushchenko wrote: On 03/20/2017 07:38 PM, Rob Clark wrote: On Mon, Mar 20, 2017 at 1:18 PM, Oleksandr Andrushchenko wrote: On 03/18/2017 02:22 PM, Rob Clark wrote:

Re: [Mesa-dev] [RFC libdrm 0/2] Replace the build system with meson

On Mon, Mar 20, 2017 at 2:28 PM, Timothy Arceri wrote: > > > On 21/03/17 06:39, Emil Velikov wrote: > >> On 20 March 2017 at 18:30, Matt Turner wrote: >> >>> On Mon, Mar 20, 2017 at 6:55 AM, Emil Velikov >>> wrote: >>>

etnviv drm WARNING with Kernel 4.10

Greeetings, All We moved from a 4.7 kernel to 4.10, and now regularly see the below oops at boot. Specific platform is imx6q-evi (Uniwest Evi) running X. There are no ill effects, as far as I can tell, except for the scary kernel warning. I tried disabling CONFIG_DRM_FBDEV_EMULATION, to no

Re: GEM allocation for para-virtualized DRM driver

On 03/18/2017 02:22 PM, Rob Clark wrote: On Fri, Mar 17, 2017 at 1:39 PM, Oleksandr Andrushchenko wrote: Hello, I am writing a para-virtualized DRM driver for Xen hypervisor and it now works with DRM CMA helpers, but I would also like to make it work with non-contigous

linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi Dave, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/gvt/cmd_parser.c between commit: 695fbc08d80f ("drm/i915/gvt: replace the gvt_err with gvt_vgpu_err") from the drm-intel-fixes tree and commit: 73dec95e6ba3 ("drm/i915: Emit to ringbuffer

linux-next: manual merge of the drm-intel tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm-intel tree got a conflict in: drivers/gpu/drm/i915/gvt/scheduler.c between commit: 3cd23b828b37 ("drm/i915/gvt: GVT pin/unpin shadow context") from the drm-intel-fixes tree and commit: e642c85b03de ("drm/i915: Remove superfluous

[Bug 100242] radeon buffer allocation failure during startup of Factorio

https://bugs.freedesktop.org/show_bug.cgi?id=100242 Michel Dänzer changed: What|Removed |Added Status|NEW |RESOLVED

Re: [PATCH] drm/fb-helper: Only reject FB changes if FB_MISC_USER_EVENT is set

On 17/03/17 08:13 PM, Ville Syrjälä wrote: > On Fri, Mar 17, 2017 at 07:19:27PM +0900, Michel Dänzer wrote: >> On 17/03/17 07:01 PM, Ville Syrjälä wrote: >>> On Fri, Mar 17, 2017 at 06:01:41PM +0900, Michel Dänzer wrote: On 16/03/17 07:09 PM, Ville Syrjälä wrote: > On Thu, Mar 16, 2017 at

Re: [PATCH 1/3] drm/i915: allocate mock file pointer dynamically

On Mon, Mar 20, 2017 at 1:02 PM, Arnd Bergmann wrote: > On Mon, Mar 20, 2017 at 1:00 PM, Joonas Lahtinen > wrote: >> On ma, 2017-03-20 at 10:40 +0100, Arnd Bergmann wrote: > >>> diff --git a/drivers/gpu/drm/i915/selftests/mock_drm.c >>>

Re: [PATCH 1/3] drm/i915: allocate mock file pointer dynamically

On ma, 2017-03-20 at 10:40 +0100, Arnd Bergmann wrote: > A struct file is a bit too large to put on the kernel stack in general > and triggers a warning for low settings of CONFIG_FRAME_WARN: > > drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': >

[Bug 194949] New: Amdgpu: RX 460 idle temp is 45C

https://bugzilla.kernel.org/show_bug.cgi?id=194949 Bug ID: 194949 Summary: Amdgpu: RX 460 idle temp is 45C Product: Drivers Version: 2.5 Kernel Version: 4.12-wip Hardware: x86-64 OS: Linux Tree: Mainline

Re: [PATCH v2] drm/bridge: dw_hdmi: support i2c extended read mode

Hi Nickey, On 03/20/2017 04:57 AM, Nickey Yang wrote: > "I2C Master Interface Extended Read Mode" implements a segment > pointer-based read operation using the Special Register configuration. > > This patch fix https://patchwork.kernel.org/patch/7098101/ mentioned > "The current implementation

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

Op 20-03-17 om 11:22 schreef Chris Wilson: > On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote: >> Op 20-03-17 om 09:59 schreef Daniel Vetter: >>> But my idea was kinda that we'd do the same for probe -> modeset data >>> flows like here for the other way round: Just a bunch of

Re: [PATCH v2 0/2] drm/panel: Add support for the Sitronix ST7789V

Hi Thierry, On Thu, Feb 09, 2017 at 02:14:26PM +0100, Maxime Ripard wrote: > Hi, > > Here is an attempt at supporting the ST7789V LCD controller from Sitronix. > > It is controlled through an SPI bus, with a twist, since each byte sent > must be prefixed by a bit, which needs an 9-bits-per-word

[Bug 194949] Amdgpu: RX 460 idle temp is 45C

https://bugzilla.kernel.org/show_bug.cgi?id=194949 --- Comment #1 from fin4...@hotmail.com --- There is following errors in dmesg: [5.175777] amdgpu: [powerplay] failed to send message 260 ret is 0 [5.176128] [drm:amdgpu_set_powergating_state [amdgpu]] *ERROR*

Re: [PATCH] drm/vc4: use platform_register_drivers

On Sun, 2017-03-19 at 11:28 +, Emil Velikov wrote: > Hi Philipp, > > I think you patch is OK, just a small question about the existing code. > It might be better suited for Eric... not sure. > > On 17 March 2017 at 17:00, Philipp Zabel wrote: > > Use

Re: [PATCH] drm: bochs: Don't remove uninitialized fbdev framebuffer

On Fr, 2017-03-17 at 15:14 -0300, Gabriel Krisman Bertazi wrote: > In the same spirit of the fix for QXL in commit 861078381ba5 ("drm: > qxl: > Don't alloc fbdev if emulation is not supported"), prevent the Oops in > the unbind path of Bochs if fbdev emulation is disabled. pushed to drm-misc-next

[Bug 194949] Amdgpu: RX 460 idle temp is 45C

https://bugzilla.kernel.org/show_bug.cgi?id=194949 --- Comment #2 from fin4...@hotmail.com --- Created attachment 255365 --> https://bugzilla.kernel.org/attachment.cgi?id=255365=edit dmesg output -- You are receiving this mail because: You are watching the assignee of the bug.

Re: [PATCH v2 3/8] dt-bindings: add bindings for DE2 on V3s SoC

On Fri, Mar 17, 2017 at 04:47:43AM +0800, Icenowy Zheng wrote: > Allwinner V3s SoC have a display engine which have a different pipeline > with older SoCs. > > Add document for it (new compatibles and the new "mixer" part). > > The paragraph of TCON is also refactored, for furtherly add TCONs in

Re: [PATCH] drm/msm: for array in-fences, check if all backing fences are from our own context before waiting

On Sat, 2017-03-18 at 08:48 -0400, Rob Clark wrote: > On Fri, Mar 17, 2017 at 2:38 PM, Philipp Zabel wrote: > > Use the dma_fence_match_context helper to check if all backing fences > > are from our own context, in which case we don't have to wait. > > > > Signed-off-by:

Re: [PATCHv2 00/10] Nokia N950 basic display support

Hi, On 05/03/17 01:50, Sebastian Reichel wrote: > Hi, > > Some of you may remember, that I sent a series for the N950 display > some time ago. N950 has command mode DSI panel, so the main part of > the patchset takes care of adding manual display update support in > omapdrm. > > The N950 also

Re: [PATCH 2/2] drm/pl111: Initial drm/kms driver for pl111

On Fri, Mar 17, 2017 at 03:47:42PM -0700, Eric Anholt wrote: > From: Tom Cooksey > > This is a modesetting driver for the pl111 CLCD display controller > found on various ARM platforms such as the Versatile Express. The > driver has only been tested on the bcm911360_entphn

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

Op 20-03-17 om 09:18 schreef Daniel Vetter: > On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote: >> Op 16-03-17 om 21:15 schreef Daniel Vetter: >>> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst >>> wrote: Op 16-03-17 om 16:52 schreef

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

Am Sonntag, den 19.03.2017, 13:03 -0700 schrieb Chris Healy: > I don't have any input on this binary divider subject but I do want to > bring up some observations regarding Etnaviv GPU power management that > seems relevant. > > I've done some comparisons between the Freescale Vivante GPU driver

[PATCH 1/3] drm/i915: allocate mock file pointer dynamically

A struct file is a bit too large to put on the kernel stack in general and triggers a warning for low settings of CONFIG_FRAME_WARN: drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': drivers/gpu/drm/i915/selftests/mock_drm.c:46:1: error: the frame size of 1328 bytes is larger

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote: > Op 16-03-17 om 21:15 schreef Daniel Vetter: > > On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst > > wrote: > >> Op 16-03-17 om 16:52 schreef Daniel Vetter: > >>> The vblank code really wants

[PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization to shrink the i915 kernel module by around 1000 bytes. However, the downside is a size regression with CONFIG_KASAN, as I found from stack size warnings with gcc-7.0.1: before: drivers/gpu/drm/i915/intel_dpll_mgr.c: In

[PATCH 2/3] drm/i915: split out check for noncontiguous pfn range

We get a warning with gcc-7 about a pointless comparison when using a linear memmap: drivers/gpu/drm/i915/selftests/scatterlist.c: In function 'alloc_table': drivers/gpu/drm/i915/selftests/scatterlist.c:219:66: error: self-comparison always evaluates to false [-Werror=tautological-compare]

Re: [PATCH] drm/msm: add stubs for msm_{perf,rd}_debugfs_cleanup

On Mon, Mar 20, 2017 at 10:39:25AM +0100, Arnd Bergmann wrote: > We now call those two functions even when they are not defined > or declared anywhere because DEBUG_FS is disabled: > > drivers/gpu/drm/msm/msm_drv.c: In function 'msm_drm_uninit': > drivers/gpu/drm/msm/msm_drv.c:244:2: error:

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

On Mon, 20 Mar 2017, Arnd Bergmann wrote: > The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization > to shrink the i915 kernel module by around 1000 bytes. To be clear, it was not at all intended to be an optimization, nothing of the sort. The intention was to

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

On Mon, Mar 20, 2017 at 11:01:59AM +0100, Maarten Lankhorst wrote: > Op 20-03-17 om 09:59 schreef Daniel Vetter: > > But my idea was kinda that we'd do the same for probe -> modeset data > > flows like here for the other way round: Just a bunch of READ_ONCE and > > maybe lookup the edid with rcu

Re: [PATCH v2 4/8] drm/sun4i: add support for sun8i DE2 mixers and display engines

Hi, On Fri, Mar 17, 2017 at 04:47:44AM +0800, Icenowy Zheng wrote: > Allwinner have a new "Display Engine 2.0" in there new SoCs, which comes > in a new "Display Engine" (mixers instead of old backends and > frontends). > > Add support for the mixer on Allwinner V3s SoC; it's the simplest one. >

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

On Mon, Mar 20, 2017 at 11:08 AM, Jani Nikula wrote: > On Mon, 20 Mar 2017, Arnd Bergmann wrote: >> The varargs macro trick in _PIPE3/_PHY3/_PORT3 was meant as an optimization >> to shrink the i915 kernel module by around 1000 bytes. > > To be clear,

Re: [PATCHv2 03/10] Revert "drm: omapdrm: Remove manual update display support"

On 05/03/17 02:43, Sebastian Reichel wrote: > This reverts commit 5a35876e2830511cb8110667fc426c6a6165a593. > > Revert the removal of manual update display support in > preparation for DSI command mode panels. I think it's much better to just add the manual update support from scratch rather

Re: [PATCH 3/3] [RFC] Revert "drm/i915: use variadic macros and arrays to choose port/pipe based registers"

On Mon, 20 Mar 2017, Arnd Bergmann wrote: > I don't know how to generate a URL for it, but after adding this to the > command line for gcc-7, > > -fsanitize=kernel-address -fasan-shadow-offset=0xdfff9000 > --param asan-stack=1 --param asan-globals=1 --param >

Re: [PATCH] drm/etnaviv: add etnaviv cooling device

Am Mittwoch, den 15.03.2017, 14:05 + schrieb Russell King - ARM Linux: > On Wed, Mar 15, 2017 at 02:03:09PM +0100, Lucas Stach wrote: > > Am Sonntag, den 12.03.2017, 19:00 + schrieb Russell King: > > > Each Vivante GPU contains a clock divider which can divide the GPU clock > > > by 2^n,

Re: [PATCH] drm: add check for plane functions

On Mon, Mar 20, 2017 at 1:51 PM, Daniel Vetter wrote: > On Mon, Mar 20, 2017 at 09:58:01AM +0530, Shirish S wrote: >> First of all, thanks for your comments/insights. >> >> On Sat, Mar 18, 2017 at 12:59 AM, Eric Anholt wrote: >> > Ville Syrjälä

Re: [PATCH 1/3] drm/i915: allocate mock file pointer dynamically

On Mon, Mar 20, 2017 at 10:40:27AM +0100, Arnd Bergmann wrote: > A struct file is a bit too large to put on the kernel stack in general > and triggers a warning for low settings of CONFIG_FRAME_WARN: > > drivers/gpu/drm/i915/selftests/mock_drm.c: In function 'mock_file': >

Re: DRM Atomic property for color-space conversion

On 03/17/2017 03:09 PM, Ville Syrjälä wrote: > On Fri, Mar 17, 2017 at 10:33:15AM +, Brian Starkey wrote: >> For not-programmable hardware, would a second "DEGAMMA_FIXED" property >> make sense, which is an enum type exposing what curves are supported? >> (with analogous GAMMA_FIXED as well) >

Re: [PATCH 1/4] sync_file: add a mutex to protect fence and callback members. (v3)

On Mon, Mar 20, 2017 at 08:16:36AM +, Chris Wilson wrote: > On Mon, Mar 20, 2017 at 05:03:04PM +1000, Dave Airlie wrote: > > From: Dave Airlie > > > > This patch allows the underlying fence in a sync_file to be changed > > or set to NULL. This isn't currently required but

Re: [rfc/repost] amdgpu/sync_file shared semaphores

On Mon, Mar 20, 2017 at 05:03:03PM +1000, Dave Airlie wrote: > This is a repost of the file_sync semaphore support. > > The main difference in this patch is patch1 does a lot > better at handling NULL fences in some places. The poll code > and ioctls should handle ending up with fence being NULL

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

On Mon, Mar 20, 2017 at 09:38:52AM +0100, Maarten Lankhorst wrote: > Op 20-03-17 om 09:18 schreef Daniel Vetter: > > On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote: > >> Op 16-03-17 om 21:15 schreef Daniel Vetter: > >>> On Thu, Mar 16, 2017 at 5:09 PM, Maarten Lankhorst > >>>

[PATCH] drm/msm: add stubs for msm_{perf,rd}_debugfs_cleanup

We now call those two functions even when they are not defined or declared anywhere because DEBUG_FS is disabled: drivers/gpu/drm/msm/msm_drv.c: In function 'msm_drm_uninit': drivers/gpu/drm/msm/msm_drv.c:244:2: error: implicit declaration of function 'msm_perf_debugfs_cleanup';did you mean

Re: [PATCH v2 1/8] dt-bindings: add binding for the Allwinner DE2 CCU

On Fri, Mar 17, 2017 at 04:47:41AM +0800, Icenowy Zheng wrote: > Allwinner "Display Engine 2.0" contains some clock controls in it. > > Add them as a clock driver, and make a device tree binding. > > Signed-off-by: Icenowy Zheng > --- >

Re: [PATCH] drm/atomic: protect crtc|connector->state with rcu

Op 20-03-17 om 09:59 schreef Daniel Vetter: > On Mon, Mar 20, 2017 at 09:38:52AM +0100, Maarten Lankhorst wrote: >> Op 20-03-17 om 09:18 schreef Daniel Vetter: >>> On Fri, Mar 17, 2017 at 05:52:32PM +0100, Maarten Lankhorst wrote: Op 16-03-17 om 21:15 schreef Daniel Vetter: > On Thu, Mar

Re: [PATCHv2 09/10] drm: omapdrm: crtc: get manual mode displays working

On 05/03/17 02:43, Sebastian Reichel wrote: > From: Tony Lindgren > > With manual mode displays we need to flush the panel manually. > > Let's add flushing so we get Tomi's fbtest, kmstest, kmstest --flip, > and X and wayland working. > > Signed-off-by: Tony Lindgren

[PATCH] drm/gma500: fix memory leak on edid

From: Colin Ian King edid is allocated on the call to psb_intel_sdvo_get_edid but not kfree'd at all, causing a memory leak. Fix this by kfree'ing the edid. (This may be null, but kfree can handle null frees). Detected by CoverityScan, CID#1090730 ("Resource Leak")

[Bug 100289] 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor

https://bugs.freedesktop.org/show_bug.cgi?id=100289 Bug ID: 100289 Summary: 'flip queue failed in radeon_scanout_flip: Invalid argument' error and small frame buffer allocated on turning off and on new monitor Product: DRI

Re: GEM allocation for para-virtualized DRM driver

On Mon, Mar 20, 2017 at 2:01 PM, Oleksandr Andrushchenko wrote: > On 03/20/2017 07:38 PM, Rob Clark wrote: >> >> On Mon, Mar 20, 2017 at 1:18 PM, Oleksandr Andrushchenko >> wrote: >>> >>> >>> On 03/18/2017 02:22 PM, Rob Clark wrote: On Fri, Mar

[PATCH v2 2/2] drm/omap: Major omap_modeset_init() cleanup

Cleanup overly complex omap_modeset_init(). The function is trying to support many unusual configuration, that have never been tested and are not supported by other parts of the dirver. After cleanup the init function creates exactly one connector, encoder, crtc, and primary plane per each

[Bug 194949] Amdgpu: RX 460 idle temp is 45C

https://bugzilla.kernel.org/show_bug.cgi?id=194949 Alex Deucher (alexdeuc...@gmail.com) changed: What|Removed |Added CC|

Re: [PATCH v3 3/6] documentation: media: Add documentation for new RGB and YUV bus formats

On 03/07/2017 05:42 PM, Neil Armstrong wrote: > Add documentation for added Bus Formats to describe RGB and YUS formats used > as input to the Synopsys DesignWare HDMI TX Controller. > > Signed-off-by: Neil Armstrong > --- >

Re: [PATCH v6] drm/rockchip: Refactor the component match logic.

Am Montag, 20. März 2017, 11:42:40 CET schrieb Jeffy Chen: > Currently we are adding all components from the dts, if one of their > drivers been disabled, we would not be able to bring up others. > > Refactor component match logic, follow exynos drm. > > Signed-off-by: Jeffy Chen

[PATCH v2 0/2] drm/omapdrm: Remove CONFIG_DRM_OMAP_NUM_CRTCS and cleanup

The first patch removes CONFIG_DRM_OMAP_NUM_CRTCS config option. The rest cleans up the unnecessary complexity from omap_modeset_init(). Changes since first version: - drm/omapdrm: Get rid of DRM_OMAP_NUM_CRTCS config option - drm/omapdrm: -> drm/omap: - Drop: - drm/omapdrm: Change

[PATCH v2 1/2] drm/omap: Get rid of DRM_OMAP_NUM_CRTCS config option

Allocate one CRTC for each connected output and get rid of DRM_OMAP_NUM_CRTCS config option. We still can not create more CRTCs than we have DSS display managers. We also reserve one overlay per CRTC for primary plane so we can not have more CRTCs than we have overlays either. Signed-off-by: Jyri

  1   2   >