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

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 for_each

[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(-) diff --git a/drivers/gpu/

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 fen

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 foll

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 ag

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 > > unrelated. Something like t

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

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 a

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 yo

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

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 ++-- 1 file changed, 6 i

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

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 patch

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

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 drm_mode_r

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 array of drm_mode_rect with maxim

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

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 mo

[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 mail because: You are

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 drm.debug=14 module parameter, attach dmes

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 p

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 *dl,

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 a

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 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. The layout of blob data is simply

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 i.e. 256 bytes. S

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

enefit from 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 sui

[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 --- drivers/media/platform/vsp1/vsp1_drm.c | 95 +++--- 1 file changed, 43 i

[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 drivers/media/platform/vsp1/vsp1_drm.h | 2 -- 2 files changed, 6 deletions(-) diff --git a/drivers/media/platf

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

[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 --- drivers/media/platform/vsp1/vsp1_drm.c | 347

[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: Kieran Bingham --- drivers/media/platform

[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 Acked-by: Kieran Bingham --- drivers

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

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

[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 --- drivers/media/platform/vsp1/vsp1_dl.c| 22 +

[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 -- Changes since v1: - Rename vsp1_du_pipeline_setup_input() to

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

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

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

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

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 DisplayLink USB2-to-HDMI adapter to render >> > GPU-accelerated gr

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 > >> --- > >> meson.build | 1 + > >> symbols-c

[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.___ dri-devel mailing list

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 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||harry.wentl...@amd.co

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

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 regions on the plane in > > > framebuf

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

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 a

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 >>> wrote: Hello, We're trying to

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 fo

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

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 > > > wrote: > > > > Hello, > > > > >

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

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 (ADITG/ESB) >> Cc: dri-devel@l

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, Daniel Vetter wrote: >> > > On Wed, Apr 4, 2018 at 10:06

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 on ia64. OF on ia64

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 D

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

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 property to mark damaged regions on t

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

Hi, On 04-04-18 22:49, Ville Syrjälä wrote: On Wed, Apr 04, 2018 at 10:06:29PM +0200, Hans de Goede wrote: Hi, On 04-04-18 17:50, Ville Syrjälä wrote: On Fri, Mar 30, 2018 at 04:26:53PM +0200, Hans de Goede wrote: Hi, On 30-03-18 15:25, Hans de Goede wrote: Hi, On 30-03-18 14:44, Chris Wi

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

Hi Andrzej, On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > On 05.04.2018 12:28, Laurent Pinchart wrote: > > 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 DS

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

On 04/05/2018 12:03 PM, Daniel Vetter wrote: On the topic of input validation: Should the kernel check in shared code that all the clip rects are sensible, i.e. within the dimensions of the fb? Relying on drivers for that seems like a bad idea. I guess we could do that. There seems to be diff

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

Hi, On 05-04-18 09:14, Daniel Vetter wrote: 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

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

On 04/05/2018 12:10 PM, Daniel Vetter wrote: 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

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #4 from Chí-Thanh Christopher Nguyễn --- Created attachment 138620 --> https://bugs.freedesktop.org/attachment.cgi?id=138620&action=edit dmest with cik_support=1 dc=1 dc_log=1 doesn't look all that different from the one without d

[PATCH v5] drm: Fix HDCP downstream dev count read

In both HDMI and DP, device count is represented by 6:0 bits of a register(BInfo/Bstatus) So macro for bitmasking the device_count is fixed(0x3F->0x7F). v3: Retained the Rb-ed. v4: %s/drm\/i915/drm [rodrigo] v5: Added "Fixes:" and HDCP keyword in subject [Rodrigo, Sean Paul] Signed-off-by:

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

Am 05.04.2018 um 00:32 schrieb Eric Anholt: These comments answer all the questions I had for myself when implementing a driver using the GPU scheduler. Signed-off-by: Eric Anholt Reviewed-by: Christian König Already pushed to amd-staging-drm-next as well. Thanks, Christian. --- includ

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 Jan Vesely changed: What|Removed |Added Status|NEW |NEEDINFO --- Comment #3 from Jan Vesely -

[Bug 105880] [dc][kabini] Cannot find any crtc or sizes

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #5 from Alex Deucher --- What physical connectors are on your board and which one(s) are you using? -- You are receiving this mail because: You are the assignee for the bug.___ dri-devel

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

On 04/05/2018 01:05 PM, Benjamin Gaignard wrote: > 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 ena

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

On 05.04.2018 13:51, Carsten Behling wrote: > > > > 2018-04-05 13:39 GMT+02:00 Laurent Pinchart > >: > > Hi Andrzej, > > > > On Thursday, 5 April 2018 14:28:51 EEST Andrzej Hajda wrote: > >> On 05.04.2018 12:28, Laurent Pinchart wrote: > >>> On Wednesday,

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #13 from Sverd Johnsen --- Still seen with 4.15.15 and dc=1. Not sure if this always reproduces or not, havn't tested this in a while. [13342.285357] [drm] amdgpu: finishing device. [13342.288330] amdgpu: [powerplay]

[Bug 104274] Unable to cleanly unload kernel module: BUG: unable to handle kernel NULL pointer dereference at 0000000000000258 (mutex_lock)

https://bugs.freedesktop.org/show_bug.cgi?id=104274 --- Comment #14 from Sverd Johnsen --- I just looked at the comments again and based on Comment 2 this seems like expected behavior for now. So my update was kind of pointless. -- You are receiving this mail because: You are the assignee for t

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

On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: > Hi, > > > On 05-04-18 09:14, Daniel Vetter wrote: >> >> 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

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

On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: > 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 g

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

On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: > On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: >> 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-of

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On 04/04/2018 11:56 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote: On 04/04/2018 10:43 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom wrote: Hi, On 04/04/2018 08:58 AM, Daniel Vetter wrote: On Wed, Apr 4, 2018 a

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

Hi, On 05-04-18 15:26, Daniel Vetter wrote: On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: Hi, On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goede wrote: Before this commit the WaSkipStolenMemoryFirstPage workaround code was skipping the

Re: [RFC] drm/atomic+msm: add helper to implement legacy dirtyfb

On Thu, Apr 5, 2018 at 3:30 PM, Thomas Hellstrom wrote: > On 04/04/2018 11:56 AM, Daniel Vetter wrote: >> >> On Wed, Apr 04, 2018 at 11:10:08AM +0200, Thomas Hellstrom wrote: >>> >>> On 04/04/2018 10:43 AM, Daniel Vetter wrote: On Wed, Apr 04, 2018 at 10:22:21AM +0200, Thomas Hellstrom w

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

On Thu, Apr 5, 2018 at 3:31 PM, Hans de Goede wrote: > Hi, > > > On 05-04-18 15:26, Daniel Vetter wrote: >> >> On Thu, Apr 5, 2018 at 1:47 PM, Hans de Goede wrote: >>> >>> Hi, >>> >>> >>> On 05-04-18 09:14, Daniel Vetter wrote: On Fri, Mar 30, 2018 at 02:27:15PM +0200, Hans de Goed

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

On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: > On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: >> On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: >>> On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: These comments answer all the questions I had for myself when impl

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

On Thu, Apr 5, 2018 at 9:41 AM, Nayan Deshmukh wrote: > On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: >> On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: >>> On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: On Thu, Apr 5, 2018 at 12:32 AM, Eric Anholt wrote: > These comm

Re: DRM_UDL and GPU under Xserver

On Thu, Apr 05, 2018 at 11:10:03AM +, Alexey Brodkin wrote: > Hi Daniel, Lucas, > > On Thu, 2018-04-05 at 12:59 +0200, Daniel Vetter wrote: > > 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, 20

DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

+ Dave for commenting from DRM subsystem perspective. I strongly believe there would be benefit from agreeing on some foundation of DRM subsystem level program GPU niceness [-20,19] and memory limit [0,N] pages. Quoting Matt Roper (2018-03-30 03:43:13) > On Mon, Mar 26, 2018 at 10:30:23AM +0300, J

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

On Thu, Apr 05, 2018 at 01:35:25PM +0200, Thomas Hellstrom wrote: > 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 wr

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

On Thu, Apr 05, 2018 at 01:42:11PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 12:03 PM, Daniel Vetter wrote: > > > > On the topic of input validation: Should the kernel check in shared code > > that all the clip rects are sensible, i.e. within the dimensions of the > > fb? Relying on drivers f

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

On Thursday 05 April 2018 02:42 PM, Jani Nikula wrote: 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

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

On Thu, Apr 05, 2018 at 01:51:49PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 12:10 PM, Daniel Vetter wrote: > > 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 wr

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

On Thu, Apr 05, 2018 at 10:51:42AM +0200, Thomas Hellstrom wrote: > 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. Li

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

On 04/05/2018 03:47 PM, Daniel Vetter wrote: On Thu, Apr 05, 2018 at 01:35:25PM +0200, Thomas Hellstrom wrote: 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

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

On Thu, Apr 5, 2018 at 3:44 PM, Alex Deucher wrote: > On Thu, Apr 5, 2018 at 9:41 AM, Nayan Deshmukh > wrote: >> On Thu, Apr 5, 2018 at 6:59 PM, Daniel Vetter wrote: >>> On Thu, Apr 5, 2018 at 3:27 PM, Alex Deucher wrote: On Thu, Apr 5, 2018 at 2:16 AM, Daniel Vetter wrote: > On Thu,

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

+ Some more Cc's based on IRC discussion Quoting Joonas Lahtinen (2018-04-05 16:46:51) > + Dave for commenting from DRM subsystem perspective. I strongly believe > there would be benefit from agreeing on some foundation of DRM subsystem > level program GPU niceness [-20,19] and memory limit [0,N]

Re: DRM cgroups integration (Was: Re: [PATCH v4 0/8] cgroup private data and DRM/i915 integration)

On Thu, Apr 05, 2018 at 05:15:13PM +0300, Joonas Lahtinen wrote: > + Some more Cc's based on IRC discussion > > Quoting Joonas Lahtinen (2018-04-05 16:46:51) > > + Dave for commenting from DRM subsystem perspective. I strongly believe > > there would be benefit from agreeing on some foundation of

[pull] radeon and amdgpu drm-next-4.17

Hi Dave, A few fixes for 4.17: - Fix a potential use after free in a error case - Fix pcie lane handling in amdgpu SI dpm - sdma pipeline sync fix - A few vega12 cleanups and fixes - Misc other fixes The following changes since commit 694f54f680f7fd8e9561928fbfc537d9afbc3d79: Merge branch 'drm

  1   2   3   >