Re: [PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait rename

Hi Laurent, [auto build test ERROR on next-20170710] [cannot apply to drm/drm-next drm-exynos/exynos-drm/for-next drm-intel/for-linux-next v4.12 v4.12-rc7 v4.12-rc6 v4.12] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https

Re: [PATCH v2 2/3] dt-bindings: display: panel: Add support for Orise Tech otm8009a dsi panel

On Mon, Jul 10, 2017 at 11:02:12AM +0200, Philippe CORNU wrote: > The Orise Tech OTM8009A is a 3.97" 480x800 TFT LCD panel connected using > a MIPI-DSI video interface. Its backlight is managed through the DSI link. > > Signed-off-by: Philippe CORNU > --- >

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On 11/07/17 06:09 AM, Jason Ekstrand wrote: > On Mon, Jul 10, 2017 at 9:15 AM, Christian König > > wrote: > > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: >> On Mon, Jul 10, 2017 at 8:45 AM, Christian König >>

[Bug 101749] sclk scales badly in war thunder

https://bugs.freedesktop.org/show_bug.cgi?id=101749 Bug ID: 101749 Summary: sclk scales badly in war thunder Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal

[Bug 101748] war thunder crash with mesa_glthread enabled

https://bugs.freedesktop.org/show_bug.cgi?id=101748 higu...@gmx.net changed: What|Removed |Added Summary|war thunder crash with |war thunder crash with

[Bug 101748] war thunder crash with glthreaded enabled

https://bugs.freedesktop.org/show_bug.cgi?id=101748 Bug ID: 101748 Summary: war thunder crash with glthreaded enabled Product: Mesa Version: git Hardware: Other OS: All Status: NEW Severity: normal

Re: [PATCH] drm/msm: unlock on error in msm_gem_get_iova()

Thanks for the catch! -Sushmita On 2017-07-10 01:20, Dan Carpenter wrote: We recently added locking to this function but there was a direct return that was overlooked where we need to unlock. Fixes: 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from struct_mutex")

Re: VT console blank ignored by DRM drivers on QEMU

On 07/10/2017 11:37 AM, Takashi Iwai wrote: On Mon, 10 Jul 2017 11:27:01 +0200, Daniel Vetter wrote: On Mon, Jul 10, 2017 at 10:53 AM, Takashi Iwai wrote: we've casually found a weird behavior of DRM drivers on QEMU (cirrus, bochs, virtio) via openQA: namely, VT console blank

Re: [PATCH v2 1/7] dt-bindings: display: renesas: Add R-Car M3-W HDMI TX DT bindings

On Mon, Jun 26, 2017 at 10:56:42AM -0500, Rob Herring wrote: > On Wed, Jun 21, 2017 at 12:31:27PM +0300, Laurent Pinchart wrote: > > The M3-W HDMI TX controller seems to be compatible for the H3. No > > extension to the DT bindings are needed, add an SoC-specific compatible > > string in case

Re: [linux-sunxi] [PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Hey Jonathan, since I reported this to you on IRC, it's only fair that you can have my: Tested-by: Olliver Schinagl For those interessted, I've tested it on an Olimex OLinuXino Lime2 with their 4.3 LCD. Olliver On 10-07-17 08:55, Jonathan Liu wrote: The drm_driver

Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core

On Mon, Jul 10, 2017 at 08:00:37PM +0200, Daniel Vetter wrote: > On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise > <00moses.alexande...@gmail.com> wrote: > > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote: > >> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote: > >> >

Re: [PATCH] drm/tegra: vic: add NULL check on of_match_device() return value

Hi Thierry, Quoting Thierry Reding : On Fri, Jul 07, 2017 at 01:16:26AM -0500, Gustavo A. R. Silva wrote: Check return value from call to of_match_device() in order to prevent a NULL pointer dereference. In case of NULL print error message and return.

Re: [PATCH v8 1/6] PCI: add a define for the PCI resource type mask v2

If you post this again, you can drop the "v2", "v5", etc at the end of the subject lines. I don't think it's useful to merge those. On Mon, Jul 10, 2017 at 04:59:49PM +0200, Christian König wrote: > From: Christian König > > We use this mask multiple times in the bus

Re: [PATCH v2] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

Hi Maxime, On 10 July 2017 at 16:44, Maxime Ripard wrote: > On Sun, Jul 09, 2017 at 11:11:07PM +0800, Chen-Yu Tsai wrote: >> On Sun, Jul 9, 2017 at 3:59 PM, Jonathan Liu wrote: >> > The drm_driver lastclose callback is called when the last

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

On Fri 07-07-17 11:39:18, Sergey Senozhatsky wrote: [...] > > void drm_modeset_lock_all(struct drm_device *dev) > > { > > struct drm_mode_config *config = >mode_config; > > struct drm_modeset_acquire_ctx *ctx; > > int ret; > > > > ctx = kzalloc(sizeof(*ctx),

Re: [PATCH v8 6/6] drm/amdgpu: resize VRAM BAR for CPU access v4

On Mon, Jul 10, 2017 at 04:59:54PM +0200, Christian König wrote: > From: Christian König > > Try to resize BAR0 to let CPU access all of VRAM. > > v2: rebased, style cleanups, disable mem decode before resize, > handle gmc_v9 as well, round size up to power of two.

[PATCH v3] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

The drm_driver lastclose callback is called when the last userspace DRM client has closed. Call drm_fbdev_cma_restore_mode to restore the fbdev console otherwise the fbdev console will stop working. Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support") Cc: sta...@vger.kernel.org

Re: [PATCH] dt-bindings: display: sunxi: Improve endpoint ID scheme readability

On Sun, Jun 18, 2017 at 10:05 PM, Rob Herring wrote: > On Wed, Jun 14, 2017 at 02:30:16PM +0800, Chen-Yu Tsai wrote: >> The explanation for the endpoint ID numbering scheme is convoluted >> and hard to understand. >> >> This patch aims to improve the readability of it by

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

Hello, On (07/08/17 22:30), Tetsuo Handa wrote: > Hmm... should we consider addressing console_sem problem before > introducing printing kernel thread and offloading to that kernel > thread? printk-kthread addresses a completely different set of problems. console_sem is hard to fix quickly,

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

On Sat 2017-07-08 22:30:47, Tetsuo Handa wrote: > What I want to mention here is that messages which were sent to printk() > were not printed to not only /dev/tty0 but also /dev/ttyS0 (I'm passing > "console=ttyS0,115200n8 console=tty0" to kernel command line.) I don't care > if output to

Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core

On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote: > On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote: > > If the DRM core fails to init for whatever reason, ensure that > > no driver ever calls drm_dev_register(). > > > > This is best done at drm_dev_init() as it

Re: [PATCH] drm/rockchip: fix NULL check on devm_kzalloc() return value

On 2017年07月11日 03:04, Sean Paul wrote: On Fri, Jul 07, 2017 at 08:56:28AM +0800, Mark yao wrote: On 2017年07月07日 05:58, Gustavo A. R. Silva wrote: The right variable to check here is port, not dp. This issue was detected using Coccinelle and the following semantic patch: @@ expression x;

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #12 from Olaf H B (o...@seldiame.net) --- Got it. I have the evidence with simbols. Video output is frozen but cursor is moveable. Although I can't go to a tty via CTR+ALT+fn I can use the computer via ssh. This is the error in

[PATCH] drm: compat: Fix compilation breakage due to drm_vblank_wait rename

The drm_vblank_wait() function was renamed to drm_vblank_wait_ioctl() in the DRM tree in commit b6dcaaac4474 ("drm/vblank: _ioctl posfix for ioctl handler"), while the DRM compat code was changed independently in commit d5288c88c67c ("switch compat_drm_wait_vblank() to drm_ioctl_kernel()") to call

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 9:13 AM, Christian König wrote: > Am 10.07.2017 um 17:58 schrieb Xie, AlexBin: > > I understand this discussion from closes source driver terminology. > > > > If a process is killed before it sends out the signaling command, will > some part of

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Mon, Jul 10, 2017 at 2:18 PM, Sean Paul wrote: > On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: >> Currently the hikey dsi logic cannot generate accurate byte >> clocks values for all pixel clock values. Thus if a mode clock >> is selected that cannot match

[Bug 196273] Loss of video output and system freezes *ERROR* Couldn't read SADs: 0

https://bugzilla.kernel.org/show_bug.cgi?id=196273 --- Comment #11 from Olaf H B (o...@seldiame.net) --- (In reply to Alex Deucher from comment #10) > Can you get a log with symbols? I have recompiled the kernel with simbols, but at this time I have been unable to reproduce the error. Last

Re: [RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

On Mon, Jul 10, 2017 at 01:48:02PM -0700, John Stultz wrote: > Currently the hikey dsi logic cannot generate accurate byte > clocks values for all pixel clock values. Thus if a mode clock > is selected that cannot match the calculated byte clock, the > device will boot with a blank screen. > >

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 9:15 AM, Christian König wrote: > Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: > > On Mon, Jul 10, 2017 at 8:45 AM, Christian König > wrote: > >> Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: >> >> On Wed, Jul 5, 2017

[Bug 101747] Steam-Game Turmoil, Segfault on start

https://bugs.freedesktop.org/show_bug.cgi?id=101747 Bug ID: 101747 Summary: Steam-Game Turmoil, Segfault on start Product: Mesa Version: 13.0 Hardware: Other OS: All Status: NEW Severity: normal

[RFC][PATCH] drm: kirin: Restrict modes to known good mode clocks

Currently the hikey dsi logic cannot generate accurate byte clocks values for all pixel clock values. Thus if a mode clock is selected that cannot match the calculated byte clock, the device will boot with a blank screen. This patch uses the new mode_valid callback (many thanks to Jose Abreu for

Re: [PATCH v2] drm: bridge: synopsys/dw-hdmi: Provide default configuration function for HDMI 2.0 PHY

Hi Jose, On Friday 23 Jun 2017 10:36:44 Jose Abreu wrote: > Currently HDMI 2.0 PHYs do not have a default configuration function. > > As *some* of the HDMI 2.0 PHYs have the same register layout as the 3D > PHYs we can provide the same default configuration function for both > and still let user

[Bug 101723] hdmi unplug not changing connector status

https://bugs.freedesktop.org/show_bug.cgi?id=101723 Aki Lemmetyinen changed: What|Removed |Added Keywords||patch

Re: [PATCH] fbcon: Perform generic blank unconditionally

Hi Takashi, [auto build test WARNING on linus/master] [also build test WARNING on v4.12 next-20170710] [if your patch is applied to the wrong git tree, please drop us a note to help improve the system] url: https://github.com/0day-ci/linux/commits/Takashi-Iwai/fbcon-Perform-generic-blank

[PULL] drm-misc-next-fixes

Hi Dave, Here's an updated pull request that encapsulates my earlier -next-fixes PR. I've included the summary below for completeness. The vblank timestamp patch fixes a quite noticable regression, so it'd be nice to sneak this in before rc1 is cut. The other 2 patches in this pull will only be

RE: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

I understand this discussion from closes source driver terminology. If a process is killed before it sends out the signaling command, will some part of the GPU be in a waiting situation forever? Alex Bin Xie From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Jason

[Bug 101736] Enabling disabled working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #10 from Indie --- If I Use this commands there are about one frame per 20-30 seconds. Previously, everything worked at a speed of 15-20 frames per second. So using these commands isn't an option. -- You are

[Bug 101746] radeonsi: Kernel syscall lockup caused probably by GPU crash

https://bugs.freedesktop.org/show_bug.cgi?id=101746 --- Comment #1 from Christian König --- For reference, checking on the fence status it looks like one of the SDMA engines is hung. -- You are receiving this mail because: You are the assignee for the

[Bug 196291] amdgpu: Freeze because of syscall not returning

https://bugzilla.kernel.org/show_bug.cgi?id=196291 --- Comment #4 from Tobias Auerochs (tobi291...@gmail.com) --- Submitted on freedesktop.org bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101746 -- You are receiving this mail because: You are watching the assignee of the bug.

[Bug 101746] radeonsi: Kernel syscall lockup caused probably by GPU crash

https://bugs.freedesktop.org/show_bug.cgi?id=101746 Bug ID: 101746 Summary: radeonsi: Kernel syscall lockup caused probably by GPU crash Product: Mesa Version: 17.1 Hardware: x86-64 (AMD64) OS: Linux (All)

[Bug 101736] Enabling disabled working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #9 from Indie --- (In reply to Emil Velikov from comment #8) > As said above: this must be the actual binary name - no path, no script. > Take a look inside the script for the details. Inside this file a lot of

Re: [PATCH] drm/rockchip: fix NULL check on devm_kzalloc() return value

On Fri, Jul 07, 2017 at 08:56:28AM +0800, Mark yao wrote: > On 2017年07月07日 05:58, Gustavo A. R. Silva wrote: > > The right variable to check here is port, not dp. > > > > This issue was detected using Coccinelle and the following semantic patch: > > > > @@ > > expression x; > > identifier fld; >

[Bug 100443] DMESG: [powerplay] Can't find requested voltage id in vdd_dep_on_sclk table!

https://bugs.freedesktop.org/show_bug.cgi?id=100443 --- Comment #13 from Gjorgji Jankovski --- No change with kernel 4.12 for me. -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

[Bug 196291] amdgpu: Freeze because of syscall not returning

https://bugzilla.kernel.org/show_bug.cgi?id=196291 --- Comment #3 from Christian König (christian.koe...@amd.com) --- That isn't related to any system call. The problem is simply that the hardware has crashed and some task is trying to push new commands to it, waiting for previous commands to end

[Bug 196291] amdgpu: Freeze because of syscall not returning

https://bugzilla.kernel.org/show_bug.cgi?id=196291 --- Comment #2 from Tobias Auerochs (tobi291...@gmail.com) --- Created attachment 257449 --> https://bugzilla.kernel.org/attachment.cgi?id=257449=edit /sys/kernel/debug/dri/0/amdgpu_fence_info after being frozen for a few minutes Got the

Re: printk: Should console related code avoid __GFP_DIRECT_RECLAIM memory allocations?

On Mon, Jul 10, 2017 at 2:59 PM, Petr Mladek wrote: > On Sat 2017-07-08 22:30:47, Tetsuo Handa wrote: >> What I want to mention here is that messages which were sent to printk() >> were not printed to not only /dev/tty0 but also /dev/ttyS0 (I'm passing >> "console=ttyS0,115200n8

Re: [PATCH v2] drm/sun4i: Implement drm_driver lastclose to restore fbdev console

On Mon, Jul 10, 2017 at 8:44 AM, Maxime Ripard wrote: > On Sun, Jul 09, 2017 at 11:11:07PM +0800, Chen-Yu Tsai wrote: >> On Sun, Jul 9, 2017 at 3:59 PM, Jonathan Liu wrote: >> > The drm_driver lastclose callback is called when the last

Re: [PATCH] drm: inhibit drm drivers register to uninitialized drm core

On Mon, Jul 10, 2017 at 9:14 AM, Alexandru Moise <00moses.alexande...@gmail.com> wrote: > On Mon, Jul 10, 2017 at 08:52:46AM +0200, Daniel Vetter wrote: >> On Sat, Jul 08, 2017 at 11:43:52PM +0200, Alexandru Moise wrote: >> > If the DRM core fails to init for whatever reason, ensure that >> > no

[Bug 101736] Enabling disabled working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #8 from Emil Velikov --- (In reply to Indie from comment #5) > As said above: this must be the actual binary name - no path, no script. Take a look inside the script for the details. If you have

Re: DRM_STM breaks fbdev mmap on ARCH_MULTIPLATFORM

Benjamin Gaignard writes: > 2017-07-10 12:53 GMT+02:00 Noralf Trønnes : >> Hi >> >> DRM_STM is 'default y' on ARCH_MULTIPLATFORM and it selects >> FB_PROVIDE_GET_FB_UNMAPPED_AREA. This breaks fbdev mmap for me on >> Raspberry Pi. mmap returns

[Bug 101736] Enabling disabled working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 Indie changed: What|Removed |Added Summary|Disabling working OpenGL|Enabling disabled working

Re: [PATCH] fbdev: make get_fb_unmapped_area depends of !MMU

On Monday, 2017-07-10 16:48:55 +0200, Benjamin Gaignard wrote: > Even if CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA flag is selected > do not compile and use get_fb_unmapped_area() if CONFIG_MMU is > also set. This will avoid mmap errors when compiling multi > architectures at same time. > >

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #7 from Indie --- Important information: As far as I can tell, I used to have a gallium i915 driver installed earlier. But now the developer of this repository has switched to classic version of these drivers. But

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:52 schrieb Jason Ekstrand: On Mon, Jul 10, 2017 at 8:45 AM, Christian König > wrote: Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:58 schrieb Xie, AlexBin: I understand this discussion from closes source driver terminology. If a process is killed before it sends out the signaling command, will some part of the GPU be in a waiting situation forever? Yes, exactly that's the problem here and the

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Mon, Jul 10, 2017 at 8:45 AM, Christian König wrote: > Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: > > On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: > >> From: Dave Airlie >> >> This interface will allow sync object to

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #6 from Indie --- Before this ill-fated update, these two programs worked without significant problems. There was one bug when changing the size of application window working with these OpenGL 2.1 graphics

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

Am 10.07.2017 um 17:28 schrieb Jason Ekstrand: On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie > wrote: From: Dave Airlie > This interface will allow sync object to be used to back Vulkan

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #5 from Indie --- (In reply to Emil Velikov from comment #4) > Have you actually tried it? Admittedly I'm not expert in i915 code (despite > being around a few times) although the suggestion should just work. Yes

Re: [PATCH] drm/syncobj: add sync obj wait interface. (v6)

On Wed, Jul 5, 2017 at 6:04 PM, Dave Airlie wrote: > From: Dave Airlie > > This interface will allow sync object to be used to back > Vulkan fences. This API is pretty much the vulkan fence waiting > API, and I've ported the code from amdgpu. > > v2:

Re: [PATCH] drm: stm: remove "default y" in Kconfig

On 10 July 2017 at 16:07, Benjamin Gaignard wrote: > To do not force stm driver to be build by default > > Signed-off-by: Benjamin Gaignard Yes, please. You might want to double-check the default board config has it set. Reviewed-by:

[PATCH] drm: stm: remove "default y" in Kconfig

To do not force stm driver to be build by default Signed-off-by: Benjamin Gaignard --- drivers/gpu/drm/stm/Kconfig | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/gpu/drm/stm/Kconfig b/drivers/gpu/drm/stm/Kconfig index 2c4817f..8fe5b18 100644 ---

Re: [Intel-gfx] [PATCH 1/5] drm/i915/fbdev: Always forward hotplug events

On Mon, Jul 10, 2017 at 2:15 PM, Jani Nikula wrote: > On Thu, 06 Jul 2017, Daniel Vetter wrote: >> With deferred fbdev setup we always need to forward hotplug events, >> even if fbdev isn't fully set up yet. Otherwise the deferred setup >>

Re: DRM_STM breaks fbdev mmap on ARCH_MULTIPLATFORM

On Mon, Jul 10, 2017 at 2:23 PM, Emil Velikov wrote: > In parallel to the actual fix - perhaps one should drop the default line? > From a quick look, I cannot see another DRM driver that sets it. Yes, default y is considered very much not cool. Default for drivers

[PATCH v8 6/6] drm/amdgpu: resize VRAM BAR for CPU access v4

From: Christian König Try to resize BAR0 to let CPU access all of VRAM. v2: rebased, style cleanups, disable mem decode before resize, handle gmc_v9 as well, round size up to power of two. v3: handle gmc_v6 as well, release and reassign all BARs in the driver. v4:

[PATCH v8 3/6] PCI: add functionality for resizing resources v7

From: Christian König This allows device drivers to request resizing their BARs. The function only tries to reprogram the windows of the bridge directly above the requesting device and only the BAR of the same type (usually mem, 64bit, prefetchable). This is done to

[PATCH v8 4/6] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v4

From: Christian König Most BIOS don't enable this because of compatibility reasons. Manually enable a 64bit BAR of 64GB size so that we have enough room for PCI devices. v2: style cleanups, increase size, add resource name, set correct flags, print message that

[PATCH v8 5/6] drm/amdgpu: move hw generation check into amdgpu_doorbell_init v2

From: Christian König This way we can safely call it on SI as well. v2: fix type in commit message Signed-off-by: Christian König Reviewed-by: Andy Shevchenko --- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 17

[PATCH v8 2/6] PCI: add resizeable BAR infrastructure v5

From: Christian König Just the defines and helper functions to read the possible sizes of a BAR and update it's size. See https://pcisig.com/sites/default/files/specification_documents/ECN_Resizable-BAR_24Apr2008.pdf and PCIe r3.1, sec 7.22. This is useful for

[PATCH v8 1/6] PCI: add a define for the PCI resource type mask v2

From: Christian König We use this mask multiple times in the bus setup. v2: fix some style nit picks Signed-off-by: Christian König Reviewed-by: Andy Shevchenko --- drivers/pci/pci.h | 3 +++

Resizeable PCI BAR support V8

Hi everyone, This is the eighth incarnation of this set of patches. It enables device drivers to resize and most likely also relocate the PCI BAR of devices they manage to allow the CPU to access all of the device local memory at once. This is very useful for GFX device drivers where the

[PATCH v2 04/22] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

From: Ville Syrjälä Eliminate plane->state and crtc->state usage from intel_plane_atomic_check_with_state() and its callers. Instead pass the proper states in or dig them up from the top level atomic state. Note that intel_plane_atomic_check_with_state() itself

Re: VT console blank ignored by DRM drivers on QEMU

On Mon, Jul 10, 2017 at 4:41 PM, Takashi Iwai wrote: > diff --git a/drivers/video/console/fbcon.c b/drivers/video/console/fbcon.c > index 12ded23f1aaf..65169a5a1bca 100644 > --- a/drivers/video/console/fbcon.c > +++ b/drivers/video/console/fbcon.c > @@ -2347,8 +2347,8 @@ static int

Re: VT console blank ignored by DRM drivers on QEMU

On Mon, Jul 10, 2017 at 11:37 AM, Takashi Iwai wrote: >> DPMS should be an error anyway, we want that to be able to properly >> thread the acquire_ctx EDEADLK backoff stuff through that we need for >> atomic. That would be the best long-term plan I think. > > So it implies the

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #4 from Emil Velikov --- (In reply to Indie from comment #2) > The method you proposed doesn't work, because the system doesn't have a > working version of OpenGL 2.1 libraries. See the attachment. I need a

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #3 from Indie --- Where can I find them? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel mailing list

Re: VT console blank ignored by DRM drivers on QEMU

On Mon, Jul 10, 2017 at 1:47 PM, Gerd Hoffmann wrote: > Hi, > >> But aside from that, can't we just teach these drivers to properly do >> dpms? With the atomic framework dpms is implement as simply turning >> the screen off, any driver should be able to support that properly.

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #2 from Indie --- The method you proposed doesn't work, because the system doesn't have a working version of OpenGL 2.1 libraries. See the attachment. I need a version of the drivers in which the OpenGL 2.1

[PATCH] fbdev: make get_fb_unmapped_area depends of !MMU

Even if CONFIG_FB_PROVIDE_GET_FB_UNMAPPED_AREA flag is selected do not compile and use get_fb_unmapped_area() if CONFIG_MMU is also set. This will avoid mmap errors when compiling multi architectures at same time. Signed-off-by: Benjamin Gaignard ---

Re: [Intel-gfx] [PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

On Mon, Jul 10, 2017 at 3:26 PM, Maarten Lankhorst wrote: >>> The real fix is not taking struct_mutex during atomic commit, which will >>> mean >>> no deadlock can happen. >>> >>> Is this the bug being fixed here or am I missing something? >> This would avoid

Re: VT console blank ignored by DRM drivers on QEMU

On Mon, 10 Jul 2017 13:47:57 +0200, Gerd Hoffmann wrote: > > Hi, > > > But aside from that, can't we just teach these drivers to properly do > > dpms? With the atomic framework dpms is implement as simply turning > > the screen off, any driver should be able to support that properly. > >

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

https://bugs.freedesktop.org/show_bug.cgi?id=101739 Bug ID: 101739 Summary: An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly Product: Mesa Version: git Hardware:

Re: [Intel-gfx] [PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

On Mon, Jul 10, 2017 at 03:26:18PM +0200, Maarten Lankhorst wrote: > Op 10-07-17 om 14:18 schreef Ville Syrjälä: > > On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote: > >> Op 10-07-17 om 08:43 schreef Daniel Vetter: > >>> On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä

Re: [Intel-gfx] [PATCH 04/22] drm/i915: Pass proper old/new states to intel_plane_atomic_check_with_state()

On Mon, Jul 10, 2017 at 11:04:31AM +0200, Maarten Lankhorst wrote: > Op 06-07-17 om 22:24 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > Eliminate plane->state and crtc->state usage from > > intel_plane_atomic_check_with_state() and its

Re: [Intel-gfx] [PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

Op 10-07-17 om 14:18 schreef Ville Syrjälä: > On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote: >> Op 10-07-17 om 08:43 schreef Daniel Vetter: >>> On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrote: On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote:

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 --- Comment #1 from Emil Velikov --- Afaict the drirc bits were left so that people can override them based on their liking. Something like the following should do it. Do enhance to your liking. Note that separate

[PATCH] drm/bridge: tc358767: fix probe without attached output node

The output node of the TC358767 is only used if another bridge is chained behind it. Panels attached to the TC358767 can be detected using the usual DP AUX probing. This restores the old behavior of ignoring the output if no endpoint is found. Fixes: ebc944613567 (drm: convert drivers to use

[Bug 76382] Mesa Gallium egllog _eglLog

https://bugs.freedesktop.org/show_bug.cgi?id=76382 Emil Velikov changed: What|Removed |Added Status|NEW |RESOLVED

[Bug 101736] Disabling working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 Indie changed: What|Removed |Added Summary|Disabling the working |Disabling working OpenGL

[Bug 101736] Disabling the working OpenGL 2.1 in the i915 driver

https://bugs.freedesktop.org/show_bug.cgi?id=101736 Bug ID: 101736 Summary: Disabling the working OpenGL 2.1 in the i915 driver Product: Mesa Version: 17.1 Hardware: x86 (IA32) OS: Linux (All) Status: NEW

Re: DRM_STM breaks fbdev mmap on ARCH_MULTIPLATFORM

On 10 July 2017 at 12:49, Benjamin Gaignard wrote: > 2017-07-10 12:53 GMT+02:00 Noralf Trønnes : >> Hi >> >> DRM_STM is 'default y' on ARCH_MULTIPLATFORM and it selects >> FB_PROVIDE_GET_FB_UNMAPPED_AREA. This breaks fbdev mmap for me on >>

Re: [Intel-gfx] [PATCH v3 21/22] drm/atomic: Introduce drm_atomic_helper_duplicate_commited_state()

On Mon, Jul 10, 2017 at 11:31:55AM +0200, Maarten Lankhorst wrote: > Op 10-07-17 om 08:43 schreef Daniel Vetter: > > On Fri, Jul 07, 2017 at 06:18:12PM +0300, Ville Syrjälä wrote: > >> On Fri, Jul 07, 2017 at 04:05:28PM +0200, Daniel Vetter wrote: > >>> On Fri, Jul 7, 2017 at 3:21 PM, Ville

Re: [Intel-gfx] [PATCH 1/5] drm/i915/fbdev: Always forward hotplug events

On Thu, 06 Jul 2017, Daniel Vetter wrote: > With deferred fbdev setup we always need to forward hotplug events, > even if fbdev isn't fully set up yet. Otherwise the deferred setup > will neer happen. > > Originally this check was added in > > commit

Re: DRM_STM breaks fbdev mmap on ARCH_MULTIPLATFORM

2017-07-10 12:53 GMT+02:00 Noralf Trønnes : > Hi > > DRM_STM is 'default y' on ARCH_MULTIPLATFORM and it selects > FB_PROVIDE_GET_FB_UNMAPPED_AREA. This breaks fbdev mmap for me on > Raspberry Pi. mmap returns -ENOMEM. > > Disabling DRM_STM gives me working mmap. > > Noralf. >

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #15 from Julien Isorce --- Created attachment 132581 --> https://bugs.freedesktop.org/attachment.cgi?id=132581=edit cs.log Output when adding 'cs' to R600_DEBUG. -- You are receiving this mail because:

Re: VT console blank ignored by DRM drivers on QEMU

Hi, > But aside from that, can't we just teach these drivers to properly do > dpms? With the atomic framework dpms is implement as simply turning > the screen off, any driver should be able to support that properly. Well, the virtual hardware simply has no dpms support, except maybe for cirrus

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #14 from Julien Isorce --- Created attachment 132579 --> https://bugs.freedesktop.org/attachment.cgi?id=132579=edit ddebug_mono_500ms_hang.log The gpu hang can be reproduced very quickly when using

[Bug 101325] UE4Editor crash after pressing "play" with radeon southern island card (7850 HD)

https://bugs.freedesktop.org/show_bug.cgi?id=101325 --- Comment #13 from Julien Isorce --- apitrace dump: 94 glShaderSource(shader = 2, count = 2, string = {"#version 150 #define PLATFORM_USES_ES2 0 #define PLATFORM_LINUX 1 ", " #if PLATFORM_USES_ES2 precision highp

[PATCH 16/20] drm: add function to read vendor OUI

This patch adds a helper function in DP dual mode layer to read the vendor's IEEE OUI signature from a Dual mode adapter. This will be used to differentiate between different LSPCON vendors, to address their custom programming requirements. Cc: Ville Syrjälä Cc:

[PATCH 20/20] drm/i915: write AVI infoframes for LSPCON

LSPCON chips can't pick the HDMI AVI infoframes from direct link. In order to pass AVI infoframes from display controller to LSPCON, we have to write infoframe packets into vendor specified AUX address. Also, LSPCON vendors provide AUX offsets, to inform the LSPCON chip that the AVI IF packets

  1   2   >