[drm:drm-syncobj 3/8] drivers/gpu//drm/drm_syncobj.c:115:25: error: 'SYNC_FILE_TYPE_SEMAPHORE' undeclared

tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj head: 58ec426a9ee099705987657cfad202b5bd96e363 commit: 0b73d1e7e4168f9c80d3c867d8366057290d82fb [3/8] drm: introduce sync objects as sync file objects with no fd (v2.1) config: i386-randconfig-x070-201715 (attached as .config)

[drm:drm-syncobj 8/8] include/linux/dma-fence.h:194:5: warning: 'old_fence' may be used uninitialized in this function

tree: git://people.freedesktop.org/~airlied/linux.git drm-syncobj head: 58ec426a9ee099705987657cfad202b5bd96e363 commit: 58ec426a9ee099705987657cfad202b5bd96e363 [8/8] amdgpu: use sync file for shared semaphores (v3) config: i386-randconfig-x075-201715 (attached as .config) compiler: gcc-6

RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

Does it means we have to submit command to trigger the semaphore wait/signal? Best Regards, David -Original Message- From: amd-gfx [mailto:amd-gfx-boun...@lists.freedesktop.org] On Behalf Of Dave Airlie Sent: Tuesday, April 11, 2017 11:22 AM To: amd-...@lists.freedesktop.org;

[PATCH 3/8] drm: introduce sync objects as sync file objects with no fd (v2.1)

From: Dave Airlie Sync objects are new toplevel drm object, that have the same semantics as sync_file objects, but without requiring an fd to be consumed to support them. This patch just enables the DRM interface to create these objects, it doesn't actually provide any

[PATCH 5/8] sync_file: add support for a semaphore object (v2)

From: Dave Airlie This object can be used to implement the Vulkan semaphores. The object behaviour differs from fence, in that you can replace the underlying fence, and you cannot merge semaphores. v2: change replace fence API to have a return value, don't allow polling on

[PATCH 8/8] amdgpu: use sync file for shared semaphores (v3)

From: Dave Airlie This creates a new command submission chunk for amdgpu to add wait and signal sync objects around the submission. Sync objects are managed via the drm syncobj ioctls. The command submission interface is enhanced with two new chunks, one for semaphore

[PATCH 7/8] 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. Reviewed-by: Christian König Signed-off-by: Dave Airlie ---

[PATCH 6/8] drm/syncobj: add semaphore support helpers. (v2)

From: Dave Airlie This just adds two helper interfaces to bridge the gap from drivers to sync_file for the semaphore objects. These will be used by the amdgpu driver. v2: drop one of the APIs and replace with a fence lookup to make the amdgpu api more robust.

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

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

drm sync objects (vn+1)

Okay another day, another sync object patchset. In my drm-syncobj branch. This round should: a) address the amdgpu CS ERESTARTSYS failure case, I've reworked the sync_file/syncobj/amdgpu bits to have a lookup and just replace in separate phases and just do the wait lookup and sync, then later

[PATCH 1/8] sync_file: add type/flags to sync file object creation.

From: Dave Airlie This allows us to create sync files with different semantics, and clearly define the interoperation between them it also provides flags to allow for tweaks on those semantics. This provides a validation interface for drivers that accept types from userspace

[PATCH 2/8] sync_file: export some interfaces needed by drm sync objects.

From: Dave Airlie These are just alloc and fdget interfaces needed by the drm sync objects code. Reviewed-by: Christian König Reviewed-by: Daniel Vetter Signed-off-by: Dave Airlie ---

drm-tip/drm-tip boot: 119 boots: 5 failed, 113 passed with 1 offline (v4.11-rc6-1901-gf27f076a9b50)

drm-tip/drm-tip boot: 119 boots: 5 failed, 113 passed with 1 offline (v4.11-rc6-1901-gf27f076a9b50) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1901-gf27f076a9b50/ Full Build Summary:

Re: [PATCH] exynos: change the license to X11/MIT

Hi Emil, Really sorry for late. Forgot this for a long time. 2016년 05월 12일 06:39에 Emil Velikov 이(가) 쓴 글: > Hi Inki, all, > > On 10 May 2016 at 08:18, Inki Dae wrote: >> This patch changes GPL license to X11/MIT. >> > As mentioned by Tobias, the commit messages should

Re: [PATCH] sync_file: get rid of internal reference count.

Hi Dave, [auto build test WARNING on linus/master] [also build test WARNING on v4.11-rc6 next-20170411] [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/Dave-Airlie/sync_file-get-rid-of-internal

RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

=> we'd really want to pass a semaphore between the X server and client to do this perfectly. Do you means that you want X to signal the semaphore that waited by client, through special version of xsync? We use pretty complex tricks to build synchronization logic upon the event and shm fence.

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

On 12 April 2017 at 13:34, Mao, David wrote: > My point is it is reasonable to split the semaphore signal/wait with the > command submission. > For the signal ioctl, we could just pick the last fence in the same schedule > context, and we don't need to ask for a explicit

RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

My point is it is reasonable to split the semaphore signal/wait with the command submission. For the signal ioctl, we could just pick the last fence in the same schedule context, and we don't need to ask for a explicit flush or a dummy submission trick. The spec guarantee the signal always

RE: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

But how to handle the semaphore wait in the vkQueuePresentkHR? Thanks. Best Regards, David -Original Message- From: Dave Airlie [mailto:airl...@gmail.com] Sent: Wednesday, April 12, 2017 10:44 AM To: Mao, David Cc: amd-...@lists.freedesktop.org;

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

On 12 April 2017 at 12:49, Mao, David wrote: > But how to handle the semaphore wait in the vkQueuePresentkHR? The problem here is that really we'd want the presenting process to do the signal once it submits the work for actual presentations (be that the X server DDX or

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

On 12 April 2017 at 12:36, Mao, David wrote: > Does it means we have to submit command to trigger the semaphore wait/signal? Yes, but I think that should be fine, we need to submit a job to the scheduler to get the waits to happen or to have a fence to fill into the signals.

Re: [PATCH 5/8] sync_file: add support for a semaphore object

On 11 April 2017 at 17:50, Chris Wilson wrote: > On Tue, Apr 11, 2017 at 01:22:17PM +1000, Dave Airlie wrote: >> From: Dave Airlie >> >> This object can be used to implement the Vulkan semaphores. >> >> The object behaviour differs from fence, in

Re: [RFC 0/8] drm/exynos: misc fixes and more

Hello Tobias, 2017년 04월 11일 19:52에 Tobias Jakobi 이(가) 쓴 글: > Hello Inki, > > please don't forget to review this series. Thanks for your contribution, and don't worry about that. Will review this series. Just sharing a plan for -next, I plan to have pull-request after reviewing a patch set[1]

[Bug 97861] [amdgpu SI] purple line is visible on left side of the screen connected by HDMI

https://bugs.freedesktop.org/show_bug.cgi?id=97861 --- Comment #10 from James Wagner --- Same purple line on my R9 280X Debian 9.0 (Testing) Linux 4.10.6 with amdgpu for SI and CIK enabled (From kernel.org) X.Org 1.19.2, from Debian. `xrandr --output HDMI-A-0 --auto

Re: [PATCH 8/8] amdgpu: use sync file for shared semaphores (v2.1)

On 11 April 2017 at 22:42, Chris Wilson wrote: > On Tue, Apr 11, 2017 at 01:22:20PM +1000, Dave Airlie wrote: >> +static int amdgpu_sem_lookup_and_sync(struct amdgpu_cs_parser *p, >> + uint32_t handle) >> +{ >> + int r; >> +

Re: [PATCH] drm/exynos: clean up description of exynos_drm_crtc

2017년 04월 11일 17:17에 Tobias Jakobi 이(가) 쓴 글: > Another thing that I noticed. Why wasn't the v2 that ended up in your > git ever submitted to the mailing list? Because it should have, in > particular to spot these obvious errors. Only comment about this. This patch cleans up description of

Re: [PATCH v3] drm/exynos: mixer: document YCbCr magic numbers

2017년 04월 11일 17:01에 Tobias Jakobi 이(가) 쓴 글: > Inki Dae wrote: >> >> >> 2017년 04월 10일 19:27에 Tobias Jakobi 이(가) 쓴 글: >>> Inki Dae wrote: 2017-03-29 20:56 GMT+09:00 Tobias Jakobi : > Hello Daniel, > > same question here. Patch doesn't introduce any

[Bug 100618] Dead Island crash after starting a new game

https://bugs.freedesktop.org/show_bug.cgi?id=100618 --- Comment #9 from Michel Dänzer --- Something like valgrind %command% in the game's Properties -> Launch Options should work. -- You are receiving this mail because: You are the assignee for the

[Bug 98996] Counter Strike: Global Offensive performance on Radeon Polaris

https://bugs.freedesktop.org/show_bug.cgi?id=98996 --- Comment #3 from Michel Dänzer --- Might be worth investigating the buffer waits, e.g. 80 ms corresponds to almost 5 display refresh cycles. -- You are receiving this mail because: You are the assignee for the

[Bug 195295] USB device insertion turns on discrete Radeon GPU

https://bugzilla.kernel.org/show_bug.cgi?id=195295 --- Comment #4 from Michel Dänzer (mic...@daenzer.net) --- It could be Mesa, there was an intermittent regression there which caused it to unnecessarily power up GPUs. -- You are receiving this mail because: You are watching the assignee of the

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1901-gf27f076a9b50)

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1901-gf27f076a9b50) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1901-gf27f076a9b50/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1901-gf27f076a9b50 Git Commit:

[PATCH v7 1/2] drm: Unplug drm device when unregistering it

After unbinding drm, the user space may still owns the drm dev fd, and may still be able to call drm ioctl. We're using an unplugged state to prevent something like that, so let's reuse it here. Signed-off-by: Jeffy Chen Reviewed-by: Sean Paul

[PATCH v3 08/10] drm/nouveau: Use supplied HDMI InfoFrames on GK104 hardware

Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any InfoFrame that is not

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

On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote: > Russell King - ARM Linux writes: > > > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: > >> v5: Move register definitions inside the driver directory, fix build > >> in COMPILE_TEST and !AMBA

[PATCH] drm: Fixup hang when unregistering drm dev with open_count 0

My previous patch (c5d8fac2bf drm: Unplug drm device when unregistering it) calls drm_unplug_dev when unregistering drm dev. But if open_count is 0, the unplug will try to unregister the drm dev again and cause deadlock. Fix it by dropping drm_unplug_dev and use drm_device_set_plug_state

[PATCH v3 01/10] drm/nouveau: Clean up nv50_head_atomic_check_mode() and fix blankus calculation

drm_mode_set_crtcinfo() does compensation for interlace and doublescan timing effects already, so do it first and use the compensated figures instead of the constant "vscan / ilace" terms that we had before. And then it turns out that the hardware model for how the timing parameters are

Re: [PATCH] drm/udl: Fix unaligned memory access in udl_render_hline

On Tue, Apr 11, 2017 at 09:30:53AM -0400, Sean Paul wrote: > On Fri, Apr 07, 2017 at 10:02:29PM +0200, Jonathan Neuschäfer wrote: > > On SPARC, the udl driver filled my kernel log with these messages: > > > > [186668.910612] Kernel unaligned access at TPC[76609c] > > udl_render_hline+0x13c/0x3a0

[PATCH] drm/etnaviv: fix missing unlock on error in etnaviv_gpu_submit()

From: Wei Yongjun Add the missing unlock before return from function etnaviv_gpu_submit() in the error handling case. Fixes: f3cd1b064f11 ("drm/etnaviv: (re-)protect fence allocation with GPU mutex") Signed-off-by: Wei Yongjun ---

Re: [PATCH v6 0/2] drm: rockchip: Fix rockchip drm unbind crash error

Hi Sean, On 04/11/2017 03:26 AM, Sean Paul wrote: On Mon, Apr 10, 2017 at 06:00:43PM +0800, Jeffy Chen wrote: Hi Jeffy, Thanks for sending this up again. Verified on rk3399 chromebook kevin, no more crashes during unbind/bind drm. I'm assuming this is on the chromeos-4.4 kernel? If so,

[PATCH v7 0/2] drm: rockchip: Fix rockchip drm unbind crash error

Verified on rk3399 chromebook kevin(with cros 4.4 kernel), no more crashes during unbind/bind drm. Changes in v7: Address Sean Paul 's comments. Update commit message. Changes in v6: Address Daniel Vetter 's comments. Changes in v5: Fix wrong git

[PATCH v7 2/2] drm: Prevent release fb after cleanup drm_mode_config

We are freeing all framebuffers in drm_mode_config_cleanup without sync the drm_file's fbs list. So if someone try to unbind drm before release drm dev fd, the fbs list would remain some invalid fb references. And that would cause crash later in drm_fb_release. Add a sanity check to prevent

[PATCH v3 02/10] drm/nouveau: Extend NVKM HDMI power control method to set InfoFrames

The nouveau driver, in the Linux 3.7 days, used to try and set the AVI InfoFrame based on the selected display mode. These days, it uses a fixed set of InfoFrames. Start to correct that, by providing a mechanism whereby InfoFrame data may be passed to the NVKM functions that do the actual

[PATCH v3 07/10] drm/nouveau: Use supplied HDMI InfoFrames on GF119 hardware

Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any InfoFrame that is not

[PATCH v3 09/10] drm/nouveau: Handle frame-packing mode geometry and timing effects

Frame-packing modes add an extra vtotal raster lines to each frame above and beyond what the basic mode description calls for. Account for this during scaler configuration (possibly a bit of a hack), during CRTC configuration (clearly not a hack), and when checking that a mode is valid for a given

Re: [PATCH] gpu: host1x: Fix error handling

On 10.04.2017 23:29, Christophe JAILLET wrote: If 'devm_reset_control_get' returns an error, then we erroneously return success because error code is taken from 'host->clk' instead of 'host->rst'. Fixes: b386c6b73ac6 ("gpu: host1x: Support module reset") Signed-off-by: Christophe JAILLET

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

On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: > v5: Move register definitions inside the driver directory, fix build > in COMPILE_TEST and !AMBA mode. Why is it necessary to move the register definitions there, when they're already available in linux/amba/clcd.h and are

[PATCH 1/1] nouveau_hwmon: migrate to hwmon_device_register_with_info

Hi, this patch replaces the old hwmon_device_register with the new hwmon_device_register_with_info. I've tested it on my laptop with a GeForceGT 425M and it doesn't break anything. --- linux/drivers/gpu/drm/nouveau/nouveau_hwmon.c.orig 2017-04-11 18:27:15.477623009 +0200 +++

[PATCH v3 00/10] drm/nouveau Enable HDMI Stereoscopy

HDMI 3D mode support, round three. Rebased to drm-next as it was on Sunday morning. Overall structure is the same as v2. Substantially rewrote the first patch (nv50_head_atomic_check_mode()) since a recent change to the calculation of m->v.blankus caused a merge conflict and problems with

[PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI

Enable stereoscopic output for HDMI and DisplayPort connectors on NV50+ (G80+) hardware. We do not enable stereoscopy on older hardware in case there is some older board that still has HDMI output but for which we have no logic for setting the Vendor InfoFrame. With this, I get an obvious 3D

Re: [PATCH v6 2/2] drm: Prevent release fb after cleanup mode config

Hi Sean, On 04/11/2017 04:31 AM, Sean Paul wrote: On Mon, Apr 10, 2017 at 06:00:45PM +0800, Jeffy Chen wrote: After unbinding drm, the user space may still owns the drm dev fd, and may trigger fb release after cleanup mode config. Add a sanity check to prevent that. Signed-off-by: Jeffy Chen

[PATCH] drm: i915: Avoid format string expansion from engine names

While highly unlikely, this makes sure that the string built from engine names won't be processed as a format string. Signed-off-by: Kees Cook --- drivers/gpu/drm/i915/intel_hangcheck.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[PATCH v3 04/10] drm/nouveau: Add mechanism to convert HDMI InfoFrames to hardware format

HDMI InfoFrames are passed to NVKM as bags of bytes, but the hardware needs them to be packed into words. Rather than having four (or more) copies of the packing logic introduce a single copy now, in a central place. We currently need these for AVI and Vendor InfoFrames, but we may also expect

Re: [Bug 54381] [drm:radeon_atom_pick_pll] *ERROR* Zsunable to allocate a PPLL

Sent from my iPhone ___ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v4 2/2] crypto: hw_random - Add new Exynos RNG driver

On Mon, Apr 10, 2017 at 12:55 PM, Herbert Xu wrote: > On Sat, Apr 08, 2017 at 03:32:45PM +0200, Krzysztof Kozlowski wrote: >> >> +static struct rng_alg exynos_rng_alg = { >> + .generate = exynos_rng_generate, >> + .seed =

Re: [Nouveau] [PATCH 1/1] nouveau_hwmon: migrate to hwmon_device_register_with_info

thanks for the work, but could you please split that patch? It looks like you are doing several things at once and it isn't really easy to review like this. And it isn't bisectable. If there are clean ups here, please do it in a seperate patch. I highly doubt that it all has to be done within one

[PATCH v5 1/2] linux/kernel.h: Add ALIGN_DOWN macro

Few parts of kernel define their own macro for aligning down so provide a common define for this, with the same usage and assumptions as existing ALIGN. Convert also three existing implementations to this one. Signed-off-by: Krzysztof Kozlowski --- The metag change was not

[PATCH v5 2/2] crypto: hw_random - Add new Exynos RNG driver

Replace existing hw_ranndom/exynos-rng driver with a new, reworked one. This is a driver for pseudo random number generator block which on Exynos4 chipsets must be seeded with some value. On newer Exynos5420 chipsets it might seed itself from true random number generator block but this is not

[PATCH v3 03/10] drm/nouveau: Pass mode-dependent AVI and Vendor HDMI InfoFrames to NVKM

Now that we have mechanism by which to pass mode-dependent HDMI InfoFrames to the low-level hardware driver, it is incumbent upon us to do so. Signed-off-by: Alastair Bridgewater --- drivers/gpu/drm/nouveau/nv50_display.c | 30 +- 1

[PATCH v3 05/10] drm/nouveau: Use supplied HDMI InfoFrames on G84 hardware

Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic"?) InfoFrame. Also don't enable any AVI or Vendor

[PATCH v3 06/10] drm/nouveau: Use supplied HDMI InfoFrames on GT215 hardware

Now that we have the InfoFrame data being provided, for the most part, program the hardware to use it. While we're here, and since the functionality will come in handy for supporting 3D stereoscopy, implement setting the Vendor ("generic") InfoFrame. Also don't enable any AVI or Vendor InfoFrame

[PATCH v5 0/2] crypto: hw_random - Add new Exynos RNG driver

Hi, This is a follow up of my questions around exynos-rng [1]. Changes since v4: = 1. Patch 2/2: Use "stdrng" name, as suggested by Herbert. 2. Patch 2/2: Add Bartlomiej's reviewed-by. Changes since v3: = 1. New patch: 1/2 for ALIGN_DOWN macro. The change in

[PATCH 1/1] drm/vmwgfx: remove an unnecessary check

commit e7e11f995642 ("drm/vmwgfx: fix integer overflow in vmw_surface_define_ioctl()") ensures that each req->mip_levels[i] <= DRM_VMW_MAX_MIP_LEVELS, It would be easy to conclude that the sum of req->mip_levels[i] (i = 0, ..., DRM_VMW_MAX_SURFACE_FACES - 1) is less than or equal to

Re: [PATCH] sync_file: get rid of internal reference count.

On Wed, Apr 12, 2017 at 09:37:02AM +1000, Dave Airlie wrote: > From: Dave Airlie > > sync_file uses the reference count of the file, the internal > kref was never getting moved past 1. > > We can reintroduce this if we decide we need it later. > > Signed-off-by: Dave Airlie

[PATCH] sync_file: get rid of internal reference count.

From: Dave Airlie sync_file uses the reference count of the file, the internal kref was never getting moved past 1. We can reintroduce this if we decide we need it later. Signed-off-by: Dave Airlie --- drivers/dma-buf/sync_file.c | 13 ++---

Re: [PATCH] drm/etnaviv: implement cooling support for new GPU cores

Hi Lucas, [auto build test ERROR on drm/drm-next] [also build test ERROR on next-20170411] [cannot apply to v4.11-rc6] [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/Lucas-Stach/drm-etnaviv

[Bug 93341] Semi-random GPU lockups on radeonsi with a RadeonHD 7770 (when playing videos, running OpenGL games, WebGL apps, or after extended periods of time)

https://bugs.freedesktop.org/show_bug.cgi?id=93341 --- Comment #26 from Jean-François Fortin Tam --- OK, I've got good news... Julien, thanks to the crazy furry donut "torture test" you suggested, I was able to finally pinpoint the real trigger for this bug. My understanding

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

Linus Walleij writes: > On Tue, Apr 11, 2017 at 3:18 AM, Eric Anholt wrote: > >> From: Tom Cooksey > > Well that can be debated at this point. I think it should have > your Author: tag and just Tom in the Signed-off-by, then

Re: [PATCH] drm: Fixup hang when unregistering drm dev with open_count 0

On Wed, Apr 12, 2017 at 04:57:54AM +0800, Jeffy Chen wrote: > My previous patch (c5d8fac2bf drm: Unplug drm device when unregistering > it) calls drm_unplug_dev when unregistering drm dev. But if open_count > is 0, the unplug will try to unregister the drm dev again and cause > deadlock. > > Fix

[Bug 195295] USB device insertion turns on discrete Radeon GPU

https://bugzilla.kernel.org/show_bug.cgi?id=195295 --- Comment #3 from Eugene Shalygin (eugene.shaly...@gmail.com) --- Tried 4.10.6, which was free of this bug at the time I used it, but now it show the same behaviour. Here is a part from dmesg: [ 21.074717] usb 3-1: new high-speed USB device

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

Russell King - ARM Linux writes: > On Tue, Apr 11, 2017 at 09:06:31AM -0700, Eric Anholt wrote: >> Russell King - ARM Linux writes: >> >> > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: >> >> v5: Move register definitions inside the

Re: [PATCH v5 04/10] drm/stm: Add STM32 LTDC driver

On Tue, Apr 11, 2017 at 01:45:01PM -0700, Eric Anholt wrote: > Yannick Fertre writes: > > +static void ltdc_crtc_disable(struct drm_crtc *crtc) > > +{ > > + struct ltdc_device *ldev = crtc_to_ltdc(crtc); > > + struct drm_pending_vblank_event *event = crtc->state->event;

Re: [PATCH v5 04/10] drm/stm: Add STM32 LTDC driver

Yannick Fertre writes: > This controller provides output signals to interface directly a variety > of LCD and TFT panels. These output signals are: RGB signals > (up to 24bpp), vertical & horizontal synchronisations, data enable and > the pixel clock. > > Signed-off-by:

Re: [RFC 7/7] drm/vc4: update cursors asynchronously through atomic

On Mon, Apr 10, 2017 at 01:06:46PM -0700, Eric Anholt wrote: > Gustavo Padovan writes: > > > From: Gustavo Padovan > > > > Add support to async updates of cursors by using the new atomic > > interface for that. Basically what this commit does

Re: [RFC 1/7] drm/atomic: initial support for asynchronous plane update

On Mon, Apr 10, 2017 at 12:55:33PM -0700, Eric Anholt wrote: > Gustavo Padovan writes: > > > From: Gustavo Padovan > > > > In some cases, like cursor updates, it is interesting to update the > > plane in an asynchronous fashion to avoid big

[PULL] drm-misc-fixes for 4.11

Hi Dave, I have a lonely pull request for you. Just the patch you asked me to pick up this morning. drm-misc-fixes-2017-04-11: Core changes: - None Driver changes - udl: Fix unaligned memory access on SPARC (Jonathan) Cheers, Sean The following changes since commit

drm-tip/drm-tip boot: 122 boots: 4 failed, 117 passed with 1 offline (v4.11-rc6-1898-g1a8653e657e1)

drm-tip/drm-tip boot: 122 boots: 4 failed, 117 passed with 1 offline (v4.11-rc6-1898-g1a8653e657e1) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1898-g1a8653e657e1/ Full Build Summary:

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

On Mon, Apr 10, 2017 at 2:27 PM, Dave Airlie wrote: > On 10 April 2017 at 19:03, Laurent Pinchart > wrote: >> Hi Thierry, >> >> On Monday 10 Apr 2017 09:17:59 Thierry Reding wrote: >>> On Sun, Apr 09, 2017 at 01:31:40PM +0100, Emil Velikov

[Bug 98996] Counter Strike: Global Offensive performance on Radeon Polaris

https://bugs.freedesktop.org/show_bug.cgi?id=98996 --- Comment #2 from Christoph Haag --- Created attachment 130804 --> https://bugs.freedesktop.org/attachment.cgi?id=130804=edit performance with amd-staging-4.9 and mesa git Screenshot with out of the box performance on

Re: Static inline DRM functions calling into GPL-only code

On 2017-04-11 12:37 PM, James Jones wrote: On 04/11/2017 09:09 AM, Harry Wentland wrote: On 2017-04-11 11:15 AM, James Jones wrote: On 04/10/2017 11:20 PM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 6:14 AM, Nikhil

drm-tip/drm-tip boot: 120 boots: 3 failed, 117 passed (v4.11-rc6-1889-g328f79e8c2dc)

drm-tip/drm-tip boot: 120 boots: 3 failed, 117 passed (v4.11-rc6-1889-g328f79e8c2dc) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1889-g328f79e8c2dc/ Full Build Summary:

Re: [PATCH 3/3] drm/vc4: Add support for dma-buf fencing.

Chris Wilson writes: > On Mon, Apr 10, 2017 at 06:44:14PM -0700, Eric Anholt wrote: >> This is needed for proper synchronization with display on another DRM >> device (pl111 or tinydrm) with buffers produced by vc4 V3D. Fixes the >> new igt vc4_dmabuf_poll testcase,

Re: [Nouveau] [PATCH v3 10/10] drm/nouveau: Enable stereoscopic 3D output over HDMI

On Tue, Apr 11, 2017 at 1:11 PM, Alastair Bridgewater wrote: > Enable stereoscopic output for HDMI and DisplayPort connectors on > NV50+ (G80+) hardware. We do not enable stereoscopy on older > hardware in case there is some older board that still has HDMI >

Re: [PATCH] drm: Document code of conduct

2017-04-11 Daniel Vetter : > freedesktop.org has adopted a formal code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes >

Re: [PATCH] drm: Document code of conduct

On Tue, Apr 11, 2017 at 12:09 PM, Daniel Vetter wrote: > On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote: >> On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter >> wrote: >>> freedesktop.org has adopted a formal code of

Re: [PATCH] drm: panels: Add MAINTAINERS entry for LVS panel driver

On Fri, Apr 7, 2017 at 12:33 PM, Thierry Reding wrote: > On Fri, Apr 07, 2017 at 05:44:15AM +1000, Dave Airlie wrote: >> On 5 April 2017 at 16:51, Laurent Pinchart >> wrote: >> > As the DRM LVDS panel driver uses a different approach

drm-tip/drm-tip boot: 128 boots: 5 failed, 121 passed with 2 offline (v4.11-rc6-1886-g20c20ad1f78a)

drm-tip/drm-tip boot: 128 boots: 5 failed, 121 passed with 2 offline (v4.11-rc6-1886-g20c20ad1f78a) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1886-g20c20ad1f78a/ Full Build Summary:

Re: [PATCHv3 13/22] staging: android: ion: Use CMA APIs directly

On 04/10/2017 11:47 PM, Laurent Pinchart wrote: > Hi Laura, > > Thank you for the patch. > > On Monday 03 Apr 2017 11:57:55 Laura Abbott wrote: >> When CMA was first introduced, its primary use was for DMA allocation >> and the only way to get CMA memory was to call dma_alloc_coherent. This >>

[PATCH] drm/vc4: Add runtime PM support to the HDMI encoder driver

The HDMI driver is currently enabling all clks and probe time and keep the power-domain connected to the HDMI encoder enabled. Move all activation code to vc4_hdmi_encoder_enable() and make sure the clks and power domain are released when the HDMI encoder is not used by adding deactivation steps

Re: Static inline DRM functions calling into GPL-only code

On 04/11/2017 09:09 AM, Harry Wentland wrote: On 2017-04-11 11:15 AM, James Jones wrote: On 04/10/2017 11:20 PM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale wrote: My name is

Re: [PATCH] drm/panel: simple: Add support for Seiko 43WVF1G

On Sat, Apr 8, 2017 at 3:45 PM, Fabio Estevam wrote: > Thierry/Rob, > > On Tue, Feb 7, 2017 at 10:48 PM, Fabio Estevam wrote: >> On Tue, Feb 7, 2017 at 9:36 PM, Rob Herring wrote: >> >>> Except I have no way of knowing whether: a) you

[PATCH] drm/etnaviv: implement cooling support for new GPU cores

GPU cores with the DYNAMIC_FREQUENCY_SCALING feature bit set expect the platform to provide the clock scaling and ignore any requests to use the internal FSCALE divider. Writes to this register still work, but don't have any effect on the GPU clock frequency. Save the initial core and shader

Re: [PATCH] drm: Document code of conduct

Daniel Vetter writes: > freedesktop.org has adopted a formal code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't think this changes > anything for

drm-tip/drm-tip boot: 135 boots: 5 failed, 129 passed with 1 offline (v4.11-rc6-1880-g52e53d64fa4a)

drm-tip/drm-tip boot: 135 boots: 5 failed, 129 passed with 1 offline (v4.11-rc6-1880-g52e53d64fa4a) Full Boot Summary: https://kernelci.org/boot/all/job/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1880-g52e53d64fa4a/ Full Build Summary:

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

Linus Walleij writes: > On Tue, Apr 11, 2017 at 3:18 AM, Eric Anholt wrote: > >> From: Tom Cooksey > > Well that can be debated at this point. I think it should have > your Author: tag and just Tom in the Signed-off-by, then

Re: [PATCH] drm: Document code of conduct

On Tue, Apr 11, 2017 at 5:50 PM, Alex Deucher wrote: > On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: >> freedesktop.org has adopted a formal code of conduct: >> >> https://www.fooishbar.org/blog/fdo-contributor-covenant/ >>

Re: Static inline DRM functions calling into GPL-only code

On 2017-04-11 11:15 AM, James Jones wrote: On 04/10/2017 11:20 PM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 7:52 AM, Daniel Vetter wrote: On Tue, Apr 11, 2017 at 6:14 AM, Nikhil Mahale wrote: My name is Nikhil Mahale, and I work at NVIDIA in the

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

Russell King - ARM Linux writes: > On Mon, Apr 10, 2017 at 06:18:01PM -0700, Eric Anholt wrote: >> v5: Move register definitions inside the driver directory, fix build >> in COMPILE_TEST and !AMBA mode. > > Why is it necessary to move the register definitions there,

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1898-g1a8653e657e1)

drm-tip/drm-tip build: 207 builds: 1 failed, 206 passed, 45 warnings (v4.11-rc6-1898-g1a8653e657e1) Full Build Summary: https://kernelci.org/build/drm-tip/branch/drm-tip/kernel/v4.11-rc6-1898-g1a8653e657e1/ Tree: drm-tip Branch: drm-tip Git Describe: v4.11-rc6-1898-g1a8653e657e1 Git Commit:

Re: [PATCH] drm: Document code of conduct

On Tue, Apr 11, 2017 at 2:48 AM, Daniel Vetter wrote: > freedesktop.org has adopted a formal code of conduct: > > https://www.fooishbar.org/blog/fdo-contributor-covenant/ > https://www.freedesktop.org/wiki/CodeOfConduct/ > > Besides formalizing things a bit more I don't

Re: [PATCH] drm: Document code of conduct

On Tue, Apr 11, 2017 at 11:14 AM, Luc Verhaegen wrote: > On Tue, Apr 11, 2017 at 04:58:51PM +0300, Jani Nikula wrote: >> On Tue, 11 Apr 2017, Luc Verhaegen wrote: >> > On Tue, Apr 11, 2017 at 03:36:32PM +0200, Daniel Vetter wrote: >> >> On Tue, Apr 11, 2017 at

  1   2   >