Re: [PATCH 06/13] drm/exynos: Stop updating plane->crtc

2018년 04월 06일 01:45에 Daniel Vetter 이(가) 쓴 글: > On Thu, Apr 05, 2018 at 06:13:53PM +0300, Ville Syrjala wrote: >> From: Ville Syrjälä >> >> We want to get rid of plane->crtc on atomic drivers. Stop setting it. >> >> Cc: Inki Dae >> Cc:

[Bug 105869] clang crashes when compiling OpenCL kernel

https://bugs.freedesktop.org/show_bug.cgi?id=105869 --- Comment #6 from Lyberta --- I'm 100% sure it is PulseWave because that's the only kernel I use to one of my programs and it still crashes at cl::Program::build. How to upgrade to llvm/clang 6? -- You are receiving

[Bug 101976] glmark2 random blank or background only screen freeze over amdgpu rx550 AMD POLARIS12 due to dpm

https://bugs.freedesktop.org/show_bug.cgi?id=101976 Pablo Estigarribia changed: What|Removed |Added See Also|

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

On Thu, Apr 5, 2018 at 9:30 AM, 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

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

> >>> 1) Expose a dirty (or content_age property) > >>> 2) Attach a clip-rect blob property. > >>> 3) Fake a page-flip by ping-ponging two frame-buffers pointing to the > >>> same > >>> underlying buffer object. > >>> > >>> Are you saying that people are already using 3) and we should keep > using

Re: [RfC PATCH] Add udmabuf misc device

On Thu, Apr 05, 2018 at 10:32:04PM +0200, Daniel Vetter wrote: > Pulling this out of the shadows again. > > We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff > from Matt and Dongwong. > > At least from the intel side there seems to be the idea to just have 1 > special device

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

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

Re: [PATCH v4] drm: Fix downstream dev count read

On Thu, Apr 05, 2018 at 04:04:14AM +0530, Ramalingam C wrote: > > > On Thursday 05 April 2018 12:53 AM, Sean Paul wrote: > > On Wed, Apr 04, 2018 at 12:07:41PM -0700, Rodrigo Vivi wrote: > > > On Wed, Apr 04, 2018 at 11:57:42PM +0530, Ramalingam C wrote: > > > > In both HDMI and DP, device count

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

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

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

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

On Thu, 2018-04-05 at 17:19 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

Re: [Intel-gfx] [PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

On Thu, 2018-04-05 at 17:19 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

Re: [Freedreno] [PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

On Thu, Apr 05, 2018 at 04:00:47PM -0600, Jordan Crouse wrote: > The i915 DRM driver very cleverly used ascii85 encoding for their > GPU state file. Move the encode functions to a general header file to > support other drivers that might be interested in the same > functionality. In a previous

[PATCH 06/10] drm/msm/gpu: Capture the GPU state on a GPU hang

Capture the GPU state on a GPU hang and store it for later playback via the devcoredump facility. Only one crash state is stored at a time on the assumption that the first hang is usually the most interesting. The existing crash state can be cleared after capturing it and then a new one will be

[PATCH 04/10] drm/msm/gpu: Convert the GPU show function to use the GPU state

Convert the existing GPU show function to use the GPU state to dump the information rather than reading it directly from the hardware. This will require an additional step to capture the state before dumping it for the existing nodes but it will greatly facilitate reusing the same code for dumping

[PATCH 07/10] drm/msm/adreno: Convert the show/crash file format

Convert the format of the 'show' debugfs file and the crash dump to a format resembling YAML. This should be easier to parse and be more flexible for future changes and expansions. Signed-off-by: Jordan Crouse --- Documentation/gpu/drm-msm-crash-dump.txt | 30

[PATCH 08/10] drm/msm/adreno: Add ringbuffer data to the GPU state

Add the contents of each ringbuffer to the GPU state and dump the data in the crash file encoded with ascii85. To save space only the used portions of the ringbuffer are dumped. Signed-off-by: Jordan Crouse --- Documentation/gpu/drm-msm-crash-dump.txt | 5

[PATCH 02/10] drm: drm_printer: Add printer for devcoredump

Add a drm printer suitable for use with the read callback for devcoredump or any other file operation read() function that isn't otherwise covered by seq_file. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/drm_print.c | 54 +

[PATCH 10/10] drm/msm/gpu: Add the buffer objects from the submit to the crash dump

On a hang copy out the contents of the buffer objects attached to the guilty submission and print them in the crash dump report. Signed-off-by: Jordan Crouse --- Documentation/gpu/drm-msm-crash-dump.txt | 7 + drivers/gpu/drm/msm/adreno/adreno_gpu.c | 54

[v4 00/10] drm/msm: GPU crash state

This is revision 4 implementing a GPU crash state for drm/msm (https://patchwork.freedesktop.org/series/36097/). I think its mature enough to pull out of RFC status and think about merging. The goal is to store and provide enough information to debug software and hardware issues on the Adreno

[PATCH 09/10] drm/msm/adreno: Add a5xx specific registers for the GPU state

HLSQ, SP and TP registers are only accessible from a special aperture and to make matters worse the aperture is blocked from the CPU on targets that can support secure rendering. Luckily the GPU hardware has its own purpose built register dumper that can access the registers from the aperture.

[PATCH 03/10] drm/msm/gpu: Capture the state of the GPU

Add the infrastructure to capture the state current state of the GPU and store it in memory. This is useful for storing the state of a hung GPU so it can be dumped later. For now grab the same basic ringbuffer information and registers that are provided by the debugfs 'gpu' node but obviously

[PATCH 01/10] include: Move ascii85 functions from i915 to linux/ascii85.h

The i915 DRM driver very cleverly used ascii85 encoding for their GPU state file. Move the encode functions to a general header file to support other drivers that might be interested in the same functionality. Reviewed-by: Chris Wilson Signed-off-by: Jordan Crouse

[PATCH 05/10] drm/msm/gpu: Rearrange the code that collects the task during a hang

Do a bit of cleanup to prepare for upcoming changes to pass the hanging task comm and cmdline to the crash dump function. Signed-off-by: Jordan Crouse --- drivers/gpu/drm/msm/msm_gpu.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) diff --git

[Bug 105869] clang crashes when compiling OpenCL kernel

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

[Bug 104412] RX 460 HDMI 4k 60fps not working, DisplayPort is.

https://bugs.freedesktop.org/show_bug.cgi?id=104412 --- Comment #16 from S.H. --- (In reply to S.H. from comment #15) > (In reply to Harry Wentland from comment #13) > > The problem with 4k60 being blocked due to a BIOS bit should be fixed now. I > > recommend trying the

Re: [PATCH v6 1/3] dt-bindings: display: bridge: Document THC63LVD1024 LVDS decoder

On Thu, Apr 5, 2018 at 1:53 PM, Laurent Pinchart wrote: > Hi Rob, > > On Thursday, 5 April 2018 19:33:33 EEST Rob Herring wrote: >> On Mon, Apr 2, 2018 at 8:36 AM, Laurent Pinchart wrote: >> > On Tuesday, 27 March 2018 14:03:25 EEST Vladimir Zapolskiy wrote: >>

[PATCH v3] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

Re: [PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

On Thu, 2018-04-05 at 16:36 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would sometimes be possible for the initial power_up_phy() to start > timing out. This would only be observed in the last action before the > sink went into D3 mode

Re: [PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

Actually - ignore this patch, I'm going to do a v3 because i just noticed there is something very silly and broken I just introduced into the disable codepath On Thu, 2018-04-05 at 16:36 -0400, Lyude Paul wrote: > When doing a modeset where the sink is transitioning from D3 to D0 , it > would

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

On Thu, Apr 05, 2018 at 11:19:44PM +0300, Ville Syrjälä wrote: > On Thu, Apr 05, 2018 at 10:08:57PM +0200, Daniel Vetter wrote: > > On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote: > > > From: Ville Syrjälä > > > > > > We want to stop using plane->fb

Re: [PATCH 7/7] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

On Thu, Apr 05, 2018 at 10:50:35PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > plane->fb/old_fb/crtc should no longer be used by atomic > drivers. Stop messing about with them. > > TODO: Squash with the core/helper patch? Not possible, because the core

[Bug 105912] [IGT] gem_exec_reloc@cpu-30 iwlwifi 0000:00:14.3: Scan failed! ret -110 dmesg-warn

https://bugs.freedesktop.org/show_bug.cgi?id=105912 Chris Wilson changed: What|Removed |Added Status|NEW |RESOLVED

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

Quoting Eric Engestrom (2018-04-05 02:48:50) > 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

RE: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

> > On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote: > > > > > > > > From: Ville Syrjälä > > > > > > Instead of looking at plane->fb let's look at the proper new > > > plane state. > > > > > > Not that the code makes a ton of sense. It's only

Re: DRM_UDL and GPU under Xserver

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, 2018 at 9:16 AM, Alexey Brodkin > > >

[PATCH v6 12/30] drm/bridge: analogix_dp: Reset aux channel if an error occurred

From: Lin Huang AUX errors are caused by many different reasons. We may not know what happened in aux channel on failure, so let's reset aux channel if some errors occurred. Cc: 征增 王 Cc: Douglas Anderson Signed-off-by: Lin Huang

[PATCH v6 00/30] DRM Rockchip rk3399 (Kevin)

Hi, This patchset includes cleanups, improvements, and bug fixes for Rockchip DRM driver and PSR support. This new version is the same as before removing some of the patches already applied and fixing the Exynos issue due patch '[v4 15/38] drm/bridge: analogix_dp: Ensure edp is disabled when

[PATCH v6 26/30] drm/rockchip: psr: Avoid redundant calls to .set() callback

From: Tomasz Figa The first time after we call rockchip_drm_do_flush() after rockchip_drm_psr_register(), we go from PSR_DISABLE to PSR_FLUSH. The difference between PSR_DISABLE and PSR_FLUSH is whether or not we have a delayed work pending - PSR is off in either state.

[PATCH v6 29/30] drm/rockchip: Disallow PSR for the whole atomic commit

From: Tomasz Figa Currently PSR flush is triggered from CRTC's .atomic_begin() callback, which is executed after modeset disables and enables and before plane updates are committed. Since PSR flush and re-enable can be triggered asynchronously by external sources (input

[PATCH v6 21/30] drm/rockchip: pre dither down when output bpc is 8bit

From: Mark Yao Some encoder have a crc verification check, crc check fail if input and output data is not equal. That means encoder input and output need use same color depth, vop can output 10bit data to encoder, but some panel only support 8bit depth, that would make

GPU/DRM issue with DSI commands on msm 8916

Hi, I'm having issues with the GPU/DRM drivers on a msm8916 based platform which is very similar to the DragonBoard 410c. In my setup, a DSI display is directly connected to the SoC, and the video link is stable. However, when the host sends DCS commands down to the DSI panel (for instance to

[PATCH v6 13/30] drm/rockchip: Restore psr->state when enable/disable psr failed

From: zain wang If we failed disable psr, it would hang the display until next psr cycle coming. So we should restore psr->state when it failed. Cc: Tomasz Figa Signed-off-by: zain wang Signed-off-by: Douglas Anderson

[PATCH v6 23/30] drm/rockchip: analogix_dp: Do not call Analogix code before bind

From: Tomasz Figa Driver callbacks, such as system suspend or resume can be called any time, specifically they can be called before the component bind callback. Let's use dp->adp pointer as a safeguard and skip calling Analogix entry points if it is an ERR_PTR().

[PATCH 1/2] drm/msm: remove unbalanced mutex unlock

This regression stems from 0e08270a1f01 ("drm/msm: Separate locking of buffer resources from struct_mutex"). Signed-off-by: Daniel Mack Cc: Sushmita Susheelendra Cc: Rob Clark Fixes: 0e08270a1f01 ("drm/msm: Separate locking of

[PATCH v6 18/30] drm/bridge: analogix_dp: Reorder plat_data->power_off to happen sooner

From: Douglas Anderson The current user of the analogix power_off is "analogix_dp-rockchip". That driver does this: - deactivate PSR - turn off a clock Both of these things (especially deactive PSR) should be done before we turn the PHY power off and turn off analog

Re: DRM_UDL and GPU under Xserver

Hi Daniel, all, On Thu, 2018-04-05 at 15:44 +0200, Daniel Vetter wrote: > 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

[PATCH v2 15/19] omap2: omapfb: allow building it with COMPILE_TEST

This driver builds cleanly with COMPILE_TEST, and it is needed in order to allow building drivers/media omap2 driver. So, change the logic there to allow building it. Signed-off-by: Mauro Carvalho Chehab --- drivers/video/fbdev/omap2/Kconfig | 2 +- 1 file changed, 1

[PATCH v6 20/30] drm/bridge: analogix_dp: Properly disable aux chan retries on rockchip

From: Douglas Anderson The comments in analogix_dp_init_aux() claim that we're disabling aux channel retries, but then right below it for Rockchip it sets them to 3. If we actually need 3 retries for Rockchip then we could adjust the comment, but it seems more likely that

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

On Thursday 05 April 2018 12:25 PM, 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 presumably

[PATCH v6 14/30] drm/bridge: analogix_dp: Don't use ANALOGIX_DP_PLL_CTL to control pll

From: zain wang There is no register named ANALOGIX_DP_PLL_CTL in Rockchip edp phy reg list. We should use BIT_4 in ANALOGIX_DP_PD to control the pll power instead of ANALOGIX_DP_PLL_CTL. Cc: Douglas Anderson Signed-off-by: zain wang

[PATCH 00/16] Make all drivers under drivers/media to build with COMPILE_TEST

The current media policy has been for a while to only accept new drivers that compile with COMPILE_TEST. However, there are still several drivers under drivers/media that doesn't build with COMPILE_TEST. So, this series makes the existing ones also compatible with it. Not building with

[PATCH v6 15/30] drm/bridge: analogix_dp: Fix timeout of video streamclk config

From: zain wang The STRM_VALID bit in register ANALOGIX_DP_SYS_CTL_3 may be unstable, so we may hit the error log "Timeout of video streamclk ok" since checked this unstable bit. In fact, we can go continue and the streamclk is ok if we wait enough time, it does no effect on

[PATCH v6 10/30] drm/bridge: analogix_dp: Check dpcd write/read status

From: Lin Huang We need to check the dpcd write/read return value to see whether the write/read was successful Cc: Kristian H. Kristensen Signed-off-by: Lin Huang Signed-off-by: zain wang Signed-off-by:

[PATCH v6 22/30] drm/bridge: analogix_dp: Split the platform-specific poweron in two parts

From: Douglas Anderson Some of the platform-specific stuff in rockchip_dp_poweron() needs to happen before the generic code. Some needs to happen after. Let's split the callback in two. Specifically we can't start doing PSR work until _after_ the whole controller is up,

[PATCH v6 03/30] drm/bridge: analogix_dp: Don't use fast link training when panel just powered up

From: zain wang Panel would reset its setting when it powers down. It would forget the last succeeded link training setting. So we can't use the last successful link training setting to do fast link training. Let's reset fast_train_enable in analogix_dp_bridge_disable();

[PATCH v6 17/30] drm/bridge: analogix_dp: Move fast link training detect to set_bridge

From: zain wang It's too early to detect fast link training, if other step after it failed, we will set fast_link flag to 1, and retry set_bridge again. In this case we will power down and power up panel power supply, and we will do fast link training since we have set

[PATCH v6 11/30] drm/bridge: analogix_dp: Fix AUX_PD bit for Rockchip

From: zain wang There are some different bits between Rockchip and Exynos in register "AUX_PD". This patch fixes the incorrect operations about it. Cc: Douglas Anderson Signed-off-by: zain wang Signed-off-by: Sean Paul

[PATCH v6 16/30] drm/bridge: analogix_dp: Fix incorrect operations with register ANALOGIX_DP_FUNC_EN_1

From: zain wang Register ANALOGIX_DP_FUNC_EN_1(offset 0x18), Rockchip is different to Exynos: on Exynos edp phy, BIT 7 MASTER_VID_FUNC_EN_N BIT 6 reserved BIT 5 SLAVE_VID_FUNC_EN_N on Rockchip edp phy, BIT 7 reserved BIT 6

[PATCH v6 06/30] drm/bridge: analogix_dp: Set PD_INC_BG first when powering up edp phy

From: zain wang Following the correct power up sequence: dp_pd=ff => dp_pd=7f => wait 10us => dp_pd=00 Cc: Stéphane Marchesin Signed-off-by: zain wang Signed-off-by: Sean Paul Signed-off-by: Thierry

Re: [PATCH] drm/virtio: fix vq wait_event condition

Hi. [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: 97.5752) The bot has tested the following trees:

[PATCH v6 27/30] drm/rockchip: psr: Sanitize semantics of allow/disallow API

From: Tomasz Figa Currently both rockchip_drm_psr_activate() and _deactivate() only set the boolean "active" flag without actually making sure that hardware state complies with it. Since we are going to extend the usage of this API to properly lock PSR for the duration of

Re: DRM_UDL and GPU under Xserver

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 graphics. > > Hardware setup is as

[PATCH v6 08/30] drm/bridge: analogix_dp: Extend hpd check time to 100ms

From: Lin Huang There was a 1ms delay to detect the hpd signal, which is too short to detect a short pulse. This patch extends this delay to 100ms. Cc: Stéphane Marchesin Cc: 征增 王 Signed-off-by: Lin Huang

[PATCH v6 02/30] drm/bridge: analogix_dp: Check AUX_EN status when doing AUX transfer

From: Lin Huang We should check AUX_EN bit to confirm the AUX CH operation is completed. Cc: Stéphane Marchesin Signed-off-by: Lin Huang Signed-off-by: zain wang Signed-off-by: Sean Paul

[PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

Add stubs for omapfb_dss.h, in the case it is included by some driver when CONFIG_FB_OMAP2 is not defined. That allows building such driver(s) with COMPILE_TEST. Signed-off-by: Mauro Carvalho Chehab --- include/video/omapfb_dss.h | 54

[PATCH v6 04/30] drm/bridge: analogix_dp: Retry bridge enable when it failed

From: zain wang When we enable bridge failed, we have to retry it, otherwise we would get the abnormal display. Cc: Stéphane Marchesin Signed-off-by: zain wang Signed-off-by: Sean Paul Signed-off-by:

[PATCH v6 07/30] drm/bridge: analogix_dp: Ensure edp is disabled when shutting down the panel

From: Lin Huang When panel is shut down, we should make sure edp can be disabled to avoid undefined behavior. Cc: Stéphane Marchesin Signed-off-by: Lin Huang Signed-off-by: zain wang Signed-off-by: Sean Paul

[PATCH v6 30/30] drm/rockchip: psr: Remove flush by CRTC

From: Tomasz Figa It is not used anymore after last changes and it was not even correct to begin with as it assumed a 1:1 relation between a CRTC and encoder, while in fact a CRTC can be attached to multiple encoders. Signed-off-by: Tomasz Figa

[PATCH 2/2] drm/msm: use correct aspace pointer in msm_gem_put_iova()

Even though msm_gem_put_iova() is currently a NOP function, the caller should pass in the address space pointer it used to obtain the object. Other call sites were changed in 8bdcd949bbe7e ("drm/msm: pass address-space to _get_iova() and friends"), but this one seems to have been forgotten.

[PATCH v6 28/30] drm/rockchip: Disable PSR from reboot notifier

From: Tomasz Figa It looks like the driver subsystem detaches devices from power domains at shutdown without consent of the drivers. This means that we might have our power domain turned off behind our back and the only way to avoid problems is to stop doing any hardware

[PATCH v6 19/30] drm/bridge: analogix_dp: Properly log AUX CH errors

From: Douglas Anderson The code in analogix_dp_transfer() that was supposed to print out: AUX CH error happened Was actually dead code. That's because the previous check (whether the interrupt status indicated any errors) would have hit for all errors anyway. Let's

[PATCH v6 24/30] drm/rockchip: Disable PSR on input events

From: "Kristian H. Kristensen" To improve PSR exit latency, we speculatively start exiting when we receive input events. Occasionally, this may lead to false positives, but most of the time we get a head start on coming out of PSR. Depending on how userspace takes to

[PATCH v6 25/30] drm/rockchip: Cancel PSR enable work before changing the state

From: Tomasz Figa If we change the state first and reschedule later, we might have the work executed according to previous scheduled time and end up with PSR re-enabled instantly. Let's cancel the work before changing the state. While at it, consolidate psr_disable_handler()

Re: [PATCH 15/16] media: omapfb_dss.h: add stubs to build with COMPILE_TEST

Em Thu, 05 Apr 2018 21:41:18 +0300 Laurent Pinchart escreveu: > Hi Mauro, > > Thank you for the patch. > > On Thursday, 5 April 2018 20:54:15 EEST Mauro Carvalho Chehab wrote: > > Add stubs for omapfb_dss.h, in the case it is included by > > some driver when

[PATCH v6 05/30] drm/bridge: analogix_dp: Wait for HPD signal before configuring link

From: zain wang According to DP spec v1.3 chap 3.5.1.2 Link Training, Link Policy Maker must first detect that the HPD signal is asserted high by the Downstream Device before establishing a link with it. Cc: Stéphane Marchesin Signed-off-by: zain wang

[PATCH v6 09/30] drm/bridge: analogix_dp: Fix incorrect usage of enhanced mode

From: zain wang Enhanced mode is required by the eDP 1.2 specification, and not doing it early could result in a period of time where we have a link transmitting idle packets without it. Since there is no reason to disable it, we just enable it at the beginning of link

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

> 2018-04-05 13:39 GMT+02:00 Laurent Pinchart < laurent.pinch...@ideasonboard.com>: > 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, >

[PATCH v6 01/30] drm/bridge: analogix_dp: Move enable video into config_video()

From: Lin Huang We need to enable video before analogix_dp_is_video_stream_on(), so we can get the right video stream status. We needed to increase the delay in the timeout loop because there is random "Timeout of video streamclk ok" message happen when debug edp panel,

[PATCH v2] drm/i915/dp: Send DPCD ON for MST before phy_up

When doing a modeset where the sink is transitioning from D3 to D0 , it would sometimes be possible for the initial power_up_phy() to start timing out. This would only be observed in the last action before the sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We originally thought

[Bug 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c

https://bugs.freedesktop.org/show_bug.cgi?id=105913 Chris Wilson changed: What|Removed |Added Resolution|--- |NOTABUG

[PATCH v2 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

From: Ville Syrjälä Instead of plane->fb (which we're going to deprecate for atomic drivers) we need to look at plane->state->fb. The maze of code leading to vmw_kms_helper_dirty() wasn't particularly clear, but my analysis concluded that the calls originating from

Re: [RfC PATCH] Add udmabuf misc device

Pulling this out of the shadows again. We now also have xen-zcopy from Oleksandr and the hyper dmabuf stuff from Matt and Dongwong. At least from the intel side there seems to be the idea to just have 1 special device that can handle cross-gues/host sharing for all kinds of hypervisors, so I

Re: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

On Thu, Apr 05, 2018 at 08:15:05PM +, Deepak Singh Rawat wrote: > > > > > From: Ville Syrjälä > > > > Instead of looking at plane->fb let's look at the proper new > > plane state. > > > > Not that the code makes a ton of sense. It's only going through the >

[Bug 105915] [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement / cursor-256x256-rapid-movement igt-debugfs-WARNING: Warning on condition crc->crc[i] == 0xffffffff in function crc_sanity_checks, f

https://bugs.freedesktop.org/show_bug.cgi?id=105915 Bug ID: 105915 Summary: [IGT] igt@kms_cursor_crc@cursor-128x128-rapid-movement / cursor-256x256-rapid-movement igt-debugfs-WARNING: Warning on condition crc->crc[i] == 0x in

Re: [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

On Thu, Apr 05, 2018 at 10:15:57PM +0200, Thomas Hellstrom wrote: > On 04/05/2018 09:50 PM, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Instead of plane->fb (which we're going to deprecate for atomic drivers) > > we need to look at plane->state->fb. The

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

On Thu, Apr 05, 2018 at 10:08:57PM +0200, Daniel Vetter wrote: > On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > We want to stop using plane->fb with atomic driver, so stop looking at > > it. > > > > I have no idea

Re: [PATCH 3/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_helper_dirty()

On 04/05/2018 09:50 PM, Ville Syrjala wrote: From: Ville Syrjälä Instead of plane->fb (which we're going to deprecate for atomic drivers) we need to look at plane->state->fb. The maze of code leading to vmw_kms_helper_dirty() wasn't particularly clear, but my

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

https://bugs.freedesktop.org/show_bug.cgi?id=105883 --- Comment #6 from Harry Wentland --- On Ubuntu the kernel log keeps appending to /var/log/kern.log, but that might look different on different distros. If you have a luxury of a second system you might be able to ssh

RE: [PATCH 2/7] drm/vmwgfx: Stop using plane->fb in vmw_kms_atomic_check_modeset()

> > From: Ville Syrjälä > > Instead of looking at plane->fb let's look at the proper new > plane state. > > Not that the code makes a ton of sense. It's only going through the > crtcs in the atomic state, so assuming not all of them are included > we're not even

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

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #7 from Chí-Thanh Christopher Nguyễn --- The notebook also has HDMI and VGA connectors, but I do not use them currently. -- You are receiving this mail because: You are the assignee for the

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

https://bugs.freedesktop.org/show_bug.cgi?id=105880 --- Comment #6 from Chí-Thanh Christopher Nguyễn --- It is a notebook and I am using the internal LVDS panel. -- You are receiving this mail because: You are the assignee for the

Re: [PATCH 1/7] drm/arc: Stop consulting plane->fb

On Thu, Apr 05, 2018 at 10:50:29PM +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to stop using plane->fb with atomic driver, so stop looking at > it. > > I have no idea what this code is trying to achieve. There is no > corresponding check in the

[Bug 105913] [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c

https://bugs.freedesktop.org/show_bug.cgi?id=105913 Bug ID: 105913 Summary: [IGT] igt@gem_shrink@pread Test assertion failure function gem_read, file ioctl_wrappers.c Product: DRI Version: DRI git Hardware: x86-64 (AMD64)

Re: [PATCH v2 05/13] drm/i915: Stop updating plane->fb/crtc

On Thu, Apr 5, 2018 at 7:02 PM, Ville Syrjala wrote: > From: Ville Syrjälä > > We want to get rid of plane->fb/crtc on atomic drivers. Stop setting > them. > > v2: Fix up the comment in intel_crtc_active() and > nuke the rest of

Re: [PATCH 1/9] drm/vmwgfx: Remove no-op prepare/cleanup_fb callbacks

On Thu, Apr 5, 2018 at 7:06 PM, Thomas Hellstrom wrote: > On 04/05/2018 05:44 PM, Daniel Vetter wrote: >> >> Less hits to go through when I git grep over all drivers. These >> callbacks are optional. >> >> Signed-off-by: Daniel Vetter >> Cc: VMware

[PATCH 6/7] drm/vmwgfx: Stop using plane->fb in atomic_enable()

From: Ville Syrjälä Instead of looking at the (soon to be deprecated) plane->fb we'll examing plane->state->fb instead. We can do this because vmw_du_crtc_atomic_check() prevents us from enabling a crtc without the primary plane also being enabled. Due to that

[PATCH 5/7] drm/vmwgfx: Stop updating plane->fb

From: Ville Syrjälä We want to get rid of plane->fb on atomic drivers. Stop setting it. Cc: Thomas Hellstrom Cc: Sinclair Yeh Cc: VMware Graphics Cc: Daniel Vetter

[PATCH 7/7] drm/vmwgfx: Stop messing about with plane->fb/old_fb/crtc

From: Ville Syrjälä plane->fb/old_fb/crtc should no longer be used by atomic drivers. Stop messing about with them. TODO: Squash with the core/helper patch? Cc: Thomas Hellstrom Cc: Sinclair Yeh Cc: VMware Graphics

  1   2   3   >