Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On 04/05/2018 12:03 PM, Daniel Vetter wrote: On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote: On 04/05/2018 09:35 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote: From: Lukasz Spintzyk Optional plane

Re: Fwd: DRM MIPI DSI device and I2C device?

On 05.04.2018 12:28, Laurent Pinchart wrote: > Hi Carsten, > > On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: >>> Hi, >>> >>> I would like to write a DRM bridge driver that is an I2C device and a DRM >>> MIPI DSI device. >>> >>> It looks like that both - 'i2c-core.c:

Re: [Patch v2 5/6] drm/omap: Add virtual plane support to omap_plane

On 26/03/18 19:21, Benoit Parrot wrote: > Add virtual wide plane support by adding an secondary > plane_id so that an "omap_plane" can be composed of up to > two physical planes. > > When at least one 'plane' child node is present in DT then > omap_plane_init will only use the plane described in

Re: [PATCH] drm/sti: Depend on OF rather than selecting it

2018-04-03 7:34 GMT+02:00 Oliver O'Halloran : > Commit cc6b741c6f63 ("drm: sti: remove useless fields from vtg > structure") reworked some code inside of this driver and made it select > CONFIG_OF. This results in the entire OF layer being enabled when > building an allmodconfig

Re: DRM_UDL and GPU under Xserver

On Thu, Apr 5, 2018 at 12:29 PM, Lucas Stach wrote: > Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter: >> On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin >> wrote: >> > Hi Daniel, >> > >> > On Thu, 2018-04-05 at 08:18 +0200,

Re: [PATCH] drm: rcar-du: track dma-buf fences

On Wed, Apr 4, 2018 at 12:59 PM, Ucan, Emre (ADITG/ESB) wrote: > Hello Laurent > > Thank you for your review. > >> -Original Message- >> From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] >> Sent: Dienstag, 3. April 2018 20:53 >> To: Ucan, Emre

Re: [Patch v2 6/6] drm/omap: Allow wider display when a virtual plane is available

On 26/03/18 19:21, Benoit Parrot wrote: > Add an exception case when filtering out display mode so that if > a virtual wide plane is available then display wider than 2048 can be > supported as long as the required timing parameters can also be met. > > Signed-off-by: Benoit Parrot

Re: DRM_UDL and GPU under Xserver

Am Donnerstag, den 05.04.2018, 11:32 +0200 schrieb Daniel Vetter: > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin > wrote: > > Hi Daniel, > > > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: > > > On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin > > >

Re: Fwd: DRM MIPI DSI device and I2C device?

Hi Carsten, On Wednesday, 4 April 2018 11:41:05 EEST Carsten Behling wrote: > > Hi, > > > > I would like to write a DRM bridge driver that is an I2C device and a DRM > > MIPI DSI device. > > > > It looks like that both - 'i2c-core.c: of_i2c_register_devices' and > > 'drm_mipi_dsi.c:

Re: [Patch v2 1/6] drm/omap: Add ability to filter out modes which can't be supported

On 04/04/18 17:23, Laurent Pinchart wrote: + WARN(out_width > dispc.feat->ovl_width_max, + "Requested OVL width (%d) is larger than can be supported (%d).\n", + out_width, dispc.feat->ovl_width_max); >>> >>> Why don't you return an error here? I don't see a need

Re: DRM_UDL and GPU under Xserver

Hi Alexey, Daniel, On 05-04-2018 10:32, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin > wrote: >> Hi Daniel, >> >> On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: >>> On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin >>>

Re: [PATCH libdrm v2 14/23] meson: use simple option handling for omap

On Wednesday, 2018-04-04 19:55:18 +0200, Sebastian Reichel wrote: > Hi, > > On Wed, Apr 04, 2018 at 04:38:09PM +0100, Eric Engestrom wrote: > > [...] > > > > -with_omap = false > > -_omap = get_option('omap') > > -if _omap == 'true' > > - if not with_atomics > > -error('libdrm_omap requires

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On Thu, Apr 05, 2018 at 10:49:09AM +0200, Thomas Hellstrom wrote: > On 04/05/2018 09:52 AM, Daniel Vetter wrote: > > On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote: > > > With damage property in drm_plane_state, this patch adds helper iterator > > > to traverse the damage clips.

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On Thu, Apr 05, 2018 at 11:00:15AM +0200, Thomas Hellstrom wrote: > On 04/05/2018 09:35 AM, Daniel Vetter wrote: > > On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote: > > > From: Lukasz Spintzyk > > > > > > Optional plane property to mark damaged

Re: [Intel-gfx] [PATCH v3 09/10] drm/i915/psr: Set DPCD PSR2 enable bit when needed

Quoting Rodrigo Vivi (2018-03-30 18:41:08) > On Wed, Mar 28, 2018 at 03:30:45PM -0700, José Roberto de Souza wrote: > > In the 2 eDP1.4a pannels tested set or not set bit have no effect > > but is better set it and comply with specification. > > > > Signed-off-by: José Roberto de Souza

[Bug 199229] choppy cursor on ryzen 5 2400g

https://bugzilla.kernel.org/show_bug.cgi?id=199229 Michel Dänzer (mic...@daenzer.net) changed: What|Removed |Added CC|

Re: [PATCH libdrm v2 21/23] meson: build exynos by default

On Wednesday, 2018-04-04 14:10:33 -0700, Dylan Baker wrote: > For exynos and omap, are they in active use anymore? I'm pretty sure that > development of omap (the hardware) stopped, and others have told me exynos has > stopped too. I also don't think there's any open source consumer, since there

[Bug 105729] AMD Radeon flickering on HiDPI display with Gnome Wayland after wake from suspend

https://bugs.freedesktop.org/show_bug.cgi?id=105729 --- Comment #4 from Michel Dänzer --- Please attach the corresponding output of dmesg and glxinfo. -- You are receiving this mail because: You are the assignee for the bug.___

Re: [PATCH libdrm 01/11] symbols-check: add new meta-script

On Wednesday, 2018-04-04 18:39:48 +0100, Emil Velikov wrote: > On 4 April 2018 at 17:28, Eric Engestrom wrote: > > On Wednesday, 2018-04-04 16:41:35 +0100, Eric Engestrom wrote: > >> Note: copied from Mesa > >> > >> Signed-off-by: Eric Engestrom

Re: DRM_UDL and GPU under Xserver

On Thu, Apr 5, 2018 at 9:16 AM, Alexey Brodkin wrote: > Hi Daniel, > > On Thu, 2018-04-05 at 08:18 +0200, Daniel Vetter wrote: >> On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin >> wrote: >> > Hello, >> > >> > We're trying to use

[PATCH v2 04/15] v4l: vsp1: Use vsp1_entity.pipe to check if entity belongs to a pipeline

The DRM pipeline handling code uses the entity's pipe list head to check whether the entity is already included in a pipeline. This method is a bit fragile in the sense that it uses list_empty() on a list_head that is a list member. Replace it by a simpler check for the entity pipe pointer.

[PATCH v2 15/15] v4l: vsp1: Rename BRU to BRx

Some VSP instances have two blending units named BRU (Blend/ROP Unit) and BRS (Blend/ROP Sub unit). The BRS is a smaller version of the BRU with only two inputs, but otherwise offers similar features and offers the same register interface. The BRU and BRS can be used exchangeably in VSP pipelines

[PATCH v2 08/15] v4l: vsp1: Replace manual DRM pipeline input setup in vsp1_du_setup_lif

The vsp1_du_setup_lif() function sets up the DRM pipeline input manually. This duplicates the code from the vsp1_du_pipeline_setup_input() function. Replace the manual implementation by a call to the function. As the pipeline has no enabled input in vsp1_du_setup_lif(), the

[PATCH v2 07/15] v4l: vsp1: Setup BRU at atomic commit time

To implement fully dynamic plane assignment to pipelines, we need to reassign the BRU and BRS to the DRM pipelines in the atomic commit handler. In preparation for this setup factor out the BRU source pad code and call it both at LIF setup and atomic commit time. Signed-off-by: Laurent Pinchart

[PATCH v2 11/15] v4l: vsp1: Add per-display list internal completion notification support

Display list completion is already reported to the frame end handler, but that mechanism is global to all display lists. In order to implement BRU and BRS reassignment in DRM pipelines we will need to commit a display list and wait for its completion internally, without reporting it to the DRM

[PATCH v2 12/15] v4l: vsp1: Generalize detection of entity removal from DRM pipeline

When disabling a DRM plane, the corresponding RPF is only marked as removed from the pipeline in the atomic update handler, with the actual removal happening when configuring the pipeline at atomic commit time. This is required as the RPF has to be disabled in the hardware, which can't be done

[PATCH v2 10/15] v4l: vsp1: Turn frame end completion status into a bitfield

We will soon need to return more than a boolean completion status from the vsp1_dlm_irq_frame_end() IRQ handler. Turn the return value into a bitfield to prepare for that. No functional change is introduced here. Signed-off-by: Laurent Pinchart ---

[PATCH v2 13/15] v4l: vsp1: Assign BRU and BRS to pipelines dynamically

The VSPDL variant drives two DU channels through two LIF and two blenders, BRU and BRS. The DU channels thus share the five available VSPDL inputs and expose them as five KMS planes. The current implementation assigns the BRS to the second LIF and thus artificially limits the number of planes for

[PATCH v2 14/15] v4l: vsp1: Add BRx dynamic assignment debugging messages

Dynamic assignment of the BRU and BRS to pipelines is prone to regressions, add messages to make debugging easier. Keep it as a separate commit to ease removal of those messages once the code will deem to be completely stable. Signed-off-by: Laurent Pinchart

[PATCH v2 09/15] v4l: vsp1: Move DRM pipeline output setup code to a function

In order to make the vsp1_du_setup_lif() easier to read, and for symmetry with the DRM pipeline input setup, move the pipeline output setup code to a separate function. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH v2 03/15] v4l: vsp1: Store pipeline pointer in vsp1_entity

Various types of objects subclassing vsp1_entity currently store a pointer to the pipeline. Move the pointer to vsp1_entity to simplify the code and avoid storing the pipeline in more entity subclasses later. Signed-off-by: Laurent Pinchart Reviewed-by:

[PATCH v2 06/15] v4l: vsp1: Move DRM atomic commit pipeline setup to separate function

The DRM pipeline setup code used at atomic commit time is similar to the setup code used when enabling the pipeline. Move it to a separate function in order to share it. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham

[PATCH v2 02/15] v4l: vsp1: Remove unused field from vsp1_drm_pipeline structure

The vsp1_drm_pipeline enabled field is set but never used. Remove it. Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham --- drivers/media/platform/vsp1/vsp1_drm.c | 4

[PATCH v2 01/15] v4l: vsp1: Don't start/stop media pipeline for DRM

The DRM support code manages a pipeline of VSP entities, each backed by a media entity. When starting or stopping the pipeline, it starts and stops the media pipeline through the media API in order to store the pipeline pointer in every entity. The driver doesn't use the pipe pointer in media

[PATCH v2 05/15] v4l: vsp1: Share duplicated DRM pipeline configuration code

Move the duplicated DRM pipeline configuration code to a function and call it from vsp1_du_setup_lif() and vsp1_du_atomic_flush(). Signed-off-by: Laurent Pinchart Reviewed-by: Kieran Bingham ---

[PATCH v2 00/15] R-Car VSP1: Dynamically assign blend units to display pipelines

the expertise of the DRM/KMS community from that point of view. The patches are based on top of the latest Linux media master branch. For convenience their are available from git://linuxtv.org/pinchartl/media.git v4l2-vsp1-bru-brs-v2-20180405 The series passes the DU test suite with the new

Re: [PATCH v3 36/40] drm/i915: Implement gmbus burst read

On Tue, 03 Apr 2018, Daniel Vetter wrote: > On Tue, Apr 03, 2018 at 07:27:49PM +0530, Ramalingam C wrote: >> Implements a interface for single burst read of data that is larger >> than 512 Bytes through gmbus. Where does 512 come from? Current code chunks at GMBUS_BYTE_COUNT_MAX

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On 04/05/2018 09:35 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote: From: Lukasz Spintzyk Optional plane property to mark damaged regions on the plane in framebuffer coordinates of the framebuffer attached to the plane.

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On 04/05/2018 09:52 AM, Daniel Vetter wrote: TYPE_PLANE I have no idea who needs that. I suggest we just drop it. I'm assuming CRTC plane coordinates here. They are used for uploading contents of hardware planes. Like, in the simplest case, cursor images. /Thomas

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On 04/05/2018 09:52 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote: With damage property in drm_plane_state, this patch adds helper iterator to traverse the damage clips. Iterator will return the damage rectangles in framebuffer, plane or crtc coordinates

Re: [PATCH 11/15] v4l: vsp1: Add per-display list completion notification support

Hi Laurent, On 04/04/18 22:43, Laurent Pinchart wrote: > Hi Kieran, > > On Wednesday, 4 April 2018 19:16:46 EEST Kieran Bingham wrote: >> On 26/02/18 21:45, Laurent Pinchart wrote: >>> >>> -void vsp1_dl_list_commit(struct vsp1_dl_list *dl) >>> +void vsp1_dl_list_commit(struct vsp1_dl_list

Re: Closing and repoening laptop lid causes scanout corruption (regression since 4.15.12)

On Wed, 04 Apr 2018, Wolfgang Draxinger wrote: > ever since I upgraded my system to kernel version 4.15.12 I'm > experiencing a kind of interesting problem with my laptop's graphics > output. Please file a bug at [1], including the description below. Add

Re: [PATCH] drm/omap: fix crash if there's no video PLL

Hi Tomi, On Thursday, 5 April 2018 09:55:37 EEST Tomi Valkeinen wrote: > Commit 8a7eda7686675b73d74c22c0d5b83059f9d783f6 ("drm: omapdrm: dispc: > Pass DISPC pointer to remaining dispc API functions") made dpi.c use > ctx->pll even when there's no PLL, causing a crash at modeset on AM4 > EVM, and

[Bug 105883] booting with kernel using amd-staging-drm-next on 2400G hangs

https://bugs.freedesktop.org/show_bug.cgi?id=105883 --- Comment #5 from Joshua Lee --- (In reply to Edward Kigwana from comment #4) > Try > > options amdgpu dpm=0 dc=1 and seee if it still locks up. That's in /etc/modconf.d or the like, right? -- You are receiving this

Re: [RFC 3/3] drm: Add helper to validate damage during modeset_check

On Wed, Apr 04, 2018 at 04:49:08PM -0700, Deepak Rawat wrote: > This patch adds a helper which should be called by driver which enable > damage (by calling drm_plane_enable_damage_clips) from atomic_check > hook. This helper for now set the damage to NULL for the planes on crtc > which need full

Re: [RFC 2/3] drm: Add helper iterator functions to iterate over plane damage.

On Wed, Apr 04, 2018 at 04:49:07PM -0700, Deepak Rawat wrote: > With damage property in drm_plane_state, this patch adds helper iterator > to traverse the damage clips. Iterator will return the damage rectangles > in framebuffer, plane or crtc coordinates as need by driver > implementation. > >

Re: [RFC 1/3] drm: Add DAMAGE_CLIPS property to plane

On Wed, Apr 04, 2018 at 04:49:06PM -0700, Deepak Rawat wrote: > From: Lukasz Spintzyk > > Optional plane property to mark damaged regions on the plane in > framebuffer coordinates of the framebuffer attached to the plane. > > The layout of blob data is simply an

Re: [RFC 0/3] drm: page-flip with damage

On Wed, Apr 04, 2018 at 04:49:05PM -0700, Deepak Rawat wrote: > Hi All, > > This is extension to Lukasz Spintzyk earlier draft of damage interface for > drm. > Bascially a new plane property is added called "DAMAGE_CLIPS" which is simply > an array of drm_rect (exported to userspace as

Re: [PATCH 5/5] drm/msm/A6xx: Add support for using system cache(llc)

Hi Sharat, On 3/23/2018 12:49 PM, Sharat Masetty wrote: The last level system cache can be partitioned to 32 different slices of which GPU has two slices preallocated. The "gpu" slice is used for caching GPU buffers and the "gpuhtw" slice is used for caching the GPU SMMU pagetables. This

Re: [Intel-gfx] [PATCH] drm/i915: Do NOT skip the first 4k of stolen memory for pre-allocated buffers

On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: > Before this commit the WaSkipStolenMemoryFirstPage workaround code was > skipping the first 4k by passing 4096 as start of the address range passed > to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and >

Re: [PATCH libdrm v2 14/23] meson: use simple option handling for omap

Hi, On Wed, Apr 04, 2018 at 04:38:09PM +0100, Eric Engestrom wrote: > [...] > > -with_omap = false > -_omap = get_option('omap') > -if _omap == 'true' > - if not with_atomics > -error('libdrm_omap requires atomics.') > - endif > - with_omap = true > +with_exynos = false > +_exynos =

RE: [PATCH] drm: rcar-du: track dma-buf fences

Hello Laurent, Thank you for your review. Actually I sent this email yesterday. But I don't see it in mailing list archives because of some reason. > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Dienstag, 3. April 2018 20:53 > To:

Re: [PATCH 2/5] arm64:dts:sdm845: Add support for GPU LLCC

Hi Sharat, On 3/23/2018 12:49 PM, Sharat Masetty wrote: Add client side bindings required for the GPU to use the last level system cache. Also add a register range in the GPU CX domain. Signed-off-by: Sharat Masetty --- arch/arm64/boot/dts/qcom/sdm845.dtsi | 8

DRM_UDL and GPU under Xserver

Hello, We're trying to use DisplayLink USB2-to-HDMI adapter to render GPU-accelerated graphics. Hardware setup is as simple as a devboard + DisplayLink adapter. Devboards we use for this experiment are: * Wandboard Quad (based on IMX6 SoC with Vivante GPU) or * HSDK (based on Synopsys ARC HS38

Re: Signal handling in a page fault handler

On Wed, Apr 04, 2018 at 11:32:54AM +0200, Daniel Vetter wrote: > So we've done some experiments for the case where the fault originated > from kernel context (copy_to|from_user and friends). The fixup code seems > to retry the copy once after the fault (in copy_user_handle_tail), if that > fails

Re: Signal handling in a page fault handler

On Wed, Apr 04, 2018 at 05:15:46PM +0200, Daniel Vetter wrote: > On Wed, Apr 4, 2018 at 4:39 PM, Matthew Wilcox wrote: > > I actually have plans to allow mutex_lock_{interruptible,killable} to > > return -EWOULDBLOCK if a flag is set. So this doesn't seem entirely > >

[PATCH v2] drm: rcar-du: track dma-buf fences

We have to check dma-buf reservation objects of our framebuffers before we use them. Otherwise, another driver might be writing on the same buffer which we are using. This would cause visible tearing effects on display. We can use existing atomic helper functions to solve this problem. v2

Re: [PATCH 4/5] drm/msm: Pass mmu features to generic layers

Hi Sharat, On 3/23/2018 12:49 PM, Sharat Masetty wrote: Allow different Adreno targets the ability to pass specific mmu features to the generic layers. This will help conditionally configure certain iommu features for certain Adreno targets. Also Add a few simple support functions to support

Re: [PATCH v2 0/5] allow override of bus format in bridges

On 2018-04-04 11:07, Laurent Pinchart wrote: > Hi Daniel, > > On Wednesday, 4 April 2018 09:34:41 EEST Daniel Vetter wrote: >> On Wed, Apr 4, 2018 at 12:28 AM, Laurent Pinchart wrote: >>> On Wednesday, 28 March 2018 10:08:26 EEST Daniel Vetter wrote: On Mon, Mar 26, 2018 at 11:24:42PM +0200,

Re: [PATCH v2 2/5] drm: bridge: add API to query the expected input formats of bridges

On 2018-04-04 15:07, Laurent Pinchart wrote: > First of all, thank you for the patch. This generates more discussion than I > had anticipated, which is both good and bad. I'll comment through the e-mail, > and try to explain both my initial idea, and also where it could lead us. *snip* Thank

Re: [PATCH] drm/vc4: Fix memory leak during BO teardown

Hi Daniel J Blueman. [This is an automated email] This commit has been processed because it contains a -stable tag. The stable tag indicates that it's relevant for the following trees: all The bot has also determined it's probably a bug fixing patch. (score: 85.0720) The bot has tested the

RE: [PATCH] drm: rcar-du: track dma-buf fences

Hello Laurent Thank you for your review. > -Original Message- > From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] > Sent: Dienstag, 3. April 2018 20:53 > To: Ucan, Emre (ADITG/ESB) > Cc: dri-devel@lists.freedesktop.org > Subject: Re: [PATCH] drm: rcar-du: track dma-buf

Fwd: DRM MIPI DSI device and I2C device?

> Hi, > > I would like to write a DRM bridge driver that is an I2C device and a DRM MIPI DSI device. > > It looks like that both - 'i2c-core.c: of_i2c_register_devices' and 'drm_mipi_dsi.c: mipi_dsi_host_register' are registering their devices by iterating over devicetree child nodes with

[PATCH 1/1] drm/i915: Do not use kfree() to free kmem_cache_alloc() return value

In eb_lookup_vmas(), the return value of kmem_cache_alloc() is freed with kfree(). I think the expected paired function is kmem_cahce_free(). Signed-off-by: Xidong Wang --- drivers/gpu/drm/i915/i915_gem_execbuffer.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

[PATCH] uapi: fix linux/kfd_ioctl.h userspace compilation errors

Consistently use types provided by via to fix the following linux/kfd_ioctl.h userspace compilation errors: /usr/include/linux/kfd_ioctl.h:266:2: error: unknown type name 'uint64_t' uint64_t tba_addr; /* to KFD */ /usr/include/linux/kfd_ioctl.h:267:2: error: unknown type name 'uint64_t'

[PATCH] drm/omap: fix crash if there's no video PLL

Commit 8a7eda7686675b73d74c22c0d5b83059f9d783f6 ("drm: omapdrm: dispc: Pass DISPC pointer to remaining dispc API functions") made dpi.c use ctx->pll even when there's no PLL, causing a crash at modeset on AM4 EVM, and presumably all OMAP2/3 boards. Fix this by having struct dpi_data pointer in

Re: ww-mutex performance tests?

Am 04.04.2018 um 20:02 schrieb Daniel Vetter: On Tue, Apr 3, 2018 at 10:37 AM, Maarten Lankhorst wrote: Op 02-04-18 om 19:49 schreef Thomas Hellstrom: Maarten, Daniel, Do we have any ww-mutex performance tests somewhere that can be used to test the impact

Re: DRM_UDL and GPU under Xserver

On Wed, Apr 4, 2018 at 10:06 PM, Alexey Brodkin wrote: > Hello, > > We're trying to use DisplayLink USB2-to-HDMI adapter to render > GPU-accelerated graphics. > Hardware setup is as simple as a devboard + DisplayLink adapter. > Devboards we use for this experiment

Re: [PATCH] drm/sched: Extend the documentation.

On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: > These comments answer all the questions I had for myself when > implementing a driver using the GPU scheduler. > > Signed-off-by: Eric Anholt Pulling all these comments into the generated kerneldoc would be

<    1   2   3