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: [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

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

[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

[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

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

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

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

[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

[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: [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: >>>

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: [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/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

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

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: [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

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

[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: [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 >

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"

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

[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

[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.

[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

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 >

[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

[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: [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

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: [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: GEM allocation for para-virtualized DRM driver

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: On Mon, Mar 20,

[PATCH] gpu: host1x: Refactor/fix channel allocation code

This is largely a rewrite of the Host1x channel allocation code in channel.c, bringing several changes: - The previous code could deadlock due to an interaction between the 'reflock' mutex and CDMA timeout handling. This gets rid of the mutex. - In the future, per-user channel allocation will

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

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 us _not_ > do that, please ? Let's be honest, the OpenBSD is subjecting

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

Am 20.03.2017 18:56, schrieb Colin King: > 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). > >

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

Daniel Vetter writes: > 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 >>

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

[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

[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")

Re: GEM allocation for para-virtualized DRM driver

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 DRM driver for Xen

Re: [PATCH] drm/tegra: add tiling FB modifiers

On Tue, Nov 08, 2016 at 04:50:42PM +0900, Alexandre Courbot wrote: > Add FB modifiers to allow user-space to specify that a surface is in one > of the two tiling formats supported by Tegra chips, and add support in > the tegradrm driver to handle them properly. This is necessary for the > display

Re: [PATCH] drm/vc4: use platform_register_drivers

Emil Velikov writes: > 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 platform_register_drivers

Re: [PATCH] drm/tegra: add tiling FB modifiers

On Tue, Nov 08, 2016 at 06:19:01PM +0900, Alexandre Courbot wrote: > On 11/08/2016 06:07 PM, Erik Faye-Lund wrote: > > On Tue, Nov 8, 2016 at 8:50 AM, Alexandre Courbot > > wrote: > >> Add FB modifiers to allow user-space to specify that a surface is in one > >> of the two

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

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 more >> rockchip-friendly such that we can use the fixed PLLs to >> generate the pixel

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

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 the removal of manual update display support in >>> preparation for DSI

[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

[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

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

[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 Bug ID: 100288 Summary: clover unable to run OpenCL kernels since 03127bb radeonsi: compile all TGSI compute shaders asynchronously Product: Mesa Version: git

[PATCH 1/2] drm/etnaviv: update common.xml.h

Update the common hardware header with new information from rnndb. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/common.xml.h | 150 +-- 1 file changed, 89 insertions(+), 61 deletions(-) diff --git

[PATCH 2/2] drm/etnaviv: update MLCG disables with info from newer Vivante driver

PA clock gating can be enabled when the right bugfix bit is present. There are broken revs of GC4000 and GC2000, which need TX clock gating to be disabled. Signed-off-by: Lucas Stach --- drivers/gpu/drm/etnaviv/etnaviv_gpu.c | 10 -- 1 file changed, 8

[Bug 100212] Implement vload_* and vstore_* to make Theano/libgpuarray working

https://bugs.freedesktop.org/show_bug.cgi?id=100212 --- Comment #2 from Vedran Miletić --- Does https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/vload_half.html https://www.khronos.org/registry/OpenCL/sdk/1.1/docs/man/xhtml/vstore_half.html help? -- You are

Re: [PATCH v3 2/6] media: uapi: Add RGB and YUV bus formats for Synopsys HDMI TX Controller

On 03/07/2017 05:42 PM, Neil Armstrong wrote: > In order to describe the RGB and YUB bus formats used to feed the > Synopsys DesignWare HDMI TX Controller, add missing formats to the > list of Bus Formats. > > Documentation for these formats is added in a separate patch. > > Signed-off-by: Neil

[PULL] drm-intel-next

rm-intel tags/drm-intel-next-2017-03-20 for you to fetch changes up to c5bd2e14e85d180bc7fb3b8b62ac9348bddaf898: drm/i915: Update DRIVER_DATE to 20170320 (2017-03-20 08:21:05 +0100) More in i915 for 4.12: - designware i2c fixes

[Bug 93050] Amdgpu, Tonga "IO_PAGE_FAULT" and "[amdgpu]] *ERROR* amdgpu: ring 0 test failed" result in Kernel Panic

https://bugs.freedesktop.org/show_bug.cgi?id=93050 --- Comment #4 from Vedran Miletić --- (In reply to jk from comment #0) > Created attachment 12 [details] > Logfile > > Switched from catalyst to amdgpu, Kernel 4.2 and Kernel 4.3 with powerplay > fixes crash, wenn

Re: [PATCH v2] dt-bindings: drm: rcar-du: Document optional reset properties

On Thu, Mar 16, 2017 at 09:59:04PM +0100, Geert Uytterhoeven wrote: > Hi Rob, > > On Thu, Mar 16, 2017 at 9:56 PM, Rob Herring wrote: > > On Thu, Mar 16, 2017 at 09:13:16AM +0100, Geert Uytterhoeven wrote: > >> On Wed, Mar 15, 2017 at 6:01 PM, Rob Herring

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: > > 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

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

On 03/17/2017 05:11 PM, Neil Armstrong wrote: > On 03/16/2017 06:01 PM, Archit Taneja wrote: >> >> >> On 3/7/2017 10:12 PM, Neil Armstrong wrote: >>> Add documentation for added Bus Formats to describe RGB and YUS formats used >> >> s/YUS/YUV > > Thanks again > >> >>> as input to the

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

On 03/20/2017 03:27 PM, Russell King - ARM Linux wrote: 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

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

https://bugzilla.kernel.org/show_bug.cgi?id=194949 --- Comment #4 from fin4...@hotmail.com --- (In reply to Alex Deucher from comment #3) > (In reply to fin4478 from comment #0) > > I have the latest firmware from: > > https://people.freedesktop.org/~agd5f/radeon_ucode/polaris/ > > Does it work

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 > --- >

[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 --- Comment #3 from Alex Deucher --- What is the date on your system bios? The core kernel only enables pcie port pm (d3cold) on systems with a date of 2015 or newer, but there have been systems shipping which use those

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

On Thu, Mar 09, 2017 at 11:32:16PM -0500, Sean Paul wrote: > Change the mode for Sharp lq123p1jx31 panel to something more > rockchip-friendly such that we can use the fixed PLLs to > generate the pixel clock > > Cc: Chris Zhong > Cc: Stéphane Marchesin

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

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 responded that "upstream does not care us", which is indicative that we should be more

[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|

[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.

[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 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

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] 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

[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 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 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 >> b/drivers/gpu/drm/i915/selftests/mock_drm.c >> index 113dec05c7dc..18514065c93d 100644

[Bug 98604] [VDPAU, DRI3] Fullscreen flash video fails when hardware acceleration is enabled.

https://bugs.freedesktop.org/show_bug.cgi?id=98604 --- Comment #14 from Dieter Nützel --- Any progress? Michel? DRI2 vs DRI3 Wouldn't it be nice to have this in 7.1? -- You are receiving this mail because: You are the assignee for the

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': >

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 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: [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

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: 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 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: [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

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] 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] 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: [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 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

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

  1   2   >